Twin-Turbo Consensus
Intelligent Block Propagation
Once a full node receives a transaction from a user, it must broadcast that to other nodes in the network. Full nodes will randomly gossip this transaction to other nodes in the network. Once a transaction is received by a validator, it verifies the validity of the transaction, and adds that transaction to that validators local mempool.
Block proposers will look at the current state of their mempool and propose a block to be committed.Since most, if not all, transactions will already have been received by validators through the transaction dissemination approach discussed above, proposers will include unique transaction identifiers in the block proposal, along with a reference to the full block. Proposers will first disseminate the proposal to other validators in the network, followed by the entire block (containing the full contents of each transaction). The proposal will get sent as one message, whereas the entire block will get broken up in parts and gossiped to the network. If a validator has all of the transactions from the proposal in its local mempool, it will reconstruct the entire block from its mempool rather than waiting for all block parts to arrive. If it doesn’t have all transactions, it will wait to receive all of the block parts from the network, and will construct the block with all of its transactions.
This process significantly decreases the overall amount of time that a validator waits to receive a block.
Once validators have all of the transactions as part of the block proposal, they will follow the Tendermint BFT consensus to agree on the transaction ordering. In particular, there will be a prevote step, a precommit step, and a commit step before the block and the associated state changes have been committed to the blockchain.
Optimistic Block Processing
As part of Tendermint consensus, validators will receive a block proposal, verify the validity of the block, and then proceed to the prevote steps.
Rather than waiting until after the precommit step to begin transaction processing (figure 2a), validators will start a process concurrently to optimistically process the first block proposal they receive for any height. The optimistic block processing will write the candidate state to a cache.
If that block gets accepted by the network, then the data from the cache will get committed. If the network rejects the block, then the data from the cache will get discarded, and future rounds for that height will not use optimistic block processing.The theoretical improvement in latency due to optimistic block processing is
where Tprevote is the prevote latency, Tprecommit is the precommit latency, N is the number of transactions and T is the average latency of a single transaction.
Last updated