//STORE enables these computing, economic, and governance primitives

Zero-fee settlement-layer enables

Zero-fee, peer-to-peer value transfer

Fast transactions

Scalable transactions

Democratic and 2/3 censorship resistant governance (one entity, one vote)

Tokenized Data enables

Data to be open and tradable

Data to be programmable by third party apps and devices

Data to have a monetary premium (like $STORE, $BTC, $ETH, $EOS, and gold)

Datacoin revenue to be shared with users, citizens, more

…which enables these high-level use cases

Zero-fee settlement-layer enabled

Tokenized data enabled (p2p cloud)

High-level Use Cases

Fast, zero-fee, programmable payments for the public internet

Voting on the global rules of a decentralized, zero-fee digital asset

Zero-fee, 2/3 censorship resistant value transfer of data as a digital asset

Voting on the global rules of decentralized, open, and programmable data

A web2 app developer opening APIs for other developers to build with (for $STORE)

An IoT device developer live streaming datasets for anyone to access (for $STORE)

A health care system making a prized and rare dataset available (for $STORE)

An autonomous car or drone opening its ML-ready, live data streams (for $STORE)

A local government streaming IoT device data for anyone to access (for $STORE)

(If we publish, we’ll award you with 100,000 $STORE – enough to compete in founding mining auctions.)

While STORE transactions are zero-fee for both end users and developers, if STORE is initially deployed as n ERC20 token on Ethereum, applicable gas fees apply on Ethereum. All settlement transactions on Ethereum incur gas fees. When the ERC20 STORE tokens are swapped with native STORE token tokens, transactions will be settled on the STORE network and at that time, zero-fee transactions are resumed.

April 21, 2018 . 4 min read

Open-Source Proposal has Potential to Raise Tendermint’s Consensus Throughput

STORE’s idea would improve software’s ability to run consensus with constant time, even when many validators participate in the process

STORE’s idea would improve software’s ability to run consensus with constant time, even when many validators participate in the process

Highlights

  • STORE opens an issue with Tendermint on GitHub, suggesting an improvement to “minimize peer-to-peer communication overload.”
  • Image 1 — Submission of Project Basil by STORE on GitHub.

  • Novel idea results in throughput unaffected by the size of the network.
  • Proposal eliminates replication of a “holding area” for transactions on each individual peer’s system.
  • Shared transaction repository solves problem of peer-to-peer communication and opens the possibility of parallel consensus rounds by multiple block producers.

Figure 1 — The outcome of the Project Basil proposal. Transactions are taken from a shared mempool.

Background

While STORE’s engineering team worked on developing BlockFin, its dynamic, fork-tolerant, and auditable consensus algorithm, early versions of the Dynamic Proof of Stake (DyPoS) protocol were built and tested on top of Tendermint.

Open-source software, Tendermint core implements the blockchain consensus engine, which ensures that the same transactions are recorded on every machine in the same order. However, when a large number of machines are involved in the consensus, Tendermint is unable to handle the burden, making it unsuitable for large deployments with thousands of peers, a situation that STORE expects to encounter when it achieves its mission of becoming zero-fee payment infrastructure for users around the globe.

Project Basil

After studying its research results, STORE was able to proposed an open-source idea, called Project Basil, to ensure that throughput is not affected by the size of the network.

Specifically, STORE proposes two enhancements to Tendermint core:

  1. Eliminate the need for relaying the incoming transactions to other peers by devising a shared mempool that guarantees total order of transactions
  2. Use the shared mempool to build the new block during consensus round

Since peer-to-peer communication is eliminated by this proposal, the consensus throughput remains unaffected by the number of peers.

Tendermint is designed so that validators pick transactions from a storage area called a mempool. Each validator has a mempool. The elected block proposer takes the transactions from its local mempool to build the new block and proposes the new block for voting.

Figure 2— Traditional interaction between Tendermint core and its associated ABCI app.

The proposer needs to grab a list of validated transactions to propose the new block for voting. Since transaction validation is offloaded to the ABCI app, maintaining the list of validated transactions can be too, calling for a shared mempool with the following properties.

  1. Transaction order must be guaranteed as multiple peers submit validated transactions to the shared mempool
  2. It must be secure, so the peers can trust the entries in the shared mempool during consensus rounds
  3. The entries in the shared mempool must be consistent, so it offers the same view to all the peers
  4. The shared mempool must have high availability because the progress of consensus rounds depends on it

The creation of a shared mempool means that the peers:

  1. don’t add the transaction to their local mempool, but use SequenceTx() to store the signed transaction in the shared mempool
  2. don’t relay it to other peers

Since the transactions are ordered in the shared mempool, multiple block producers can propose multiple blocks for voting. The prevote and pre-commit phases of multiple proposed blocks can be pipelined, so the voting happens in parallel. Only the commit phase needs to be serial, so the block proposed by the current block producer is committed first, followed by the block proposed by the next producer, and so on.

Figure 3 — Validators take signed transactions from a shared mempool.

Maintaining a shared mempool of ordered transactions eliminates the need for relaying the incoming transactions to all the peers. This approach adds 3 APIs to the ABCI interface and offloads the consistency and availability responsibilities to the ABCI app. This should not be perceived as a weakness, because the Tendermint core is not a standalone consensus engine and is always used in association with an ABCI app.

Thanks for your email address! You'll start receiving updates soon.

Loading...

KYC/AML checks are required for securities law compliance. This will be a Reg D and Reg S global offering.

DISCLAIMER

Nothing herein is intended to be an offer to sell or solicitation of offer to buy, STORE tokens or rights to receive STORE tokens in the future. In the event that STORE conducts an offering of STORE tokens (or rights to receive STORE tokens in the future), STORE will do so in compliance with all applicable laws which may include the Securities Act of 1933 and the rules and regulations promulgated thereunder, as well as applicable state and foreign law. Any offering for sale to US Persons in a regulated transaction will be pursuant to a registration statement qualified by the Securities and Exchange Commission, or an applicable exemption from the registration requirements.