bft blockchain consensus consistency cryptocurrency cryptography db distributed-systems go

History

William Banfield c8c248d733 docs: add an overview of the proposer-based timestamps algorithm (#8058 ) This change adds an overview of the proposer-based timestamps algorithm. The goal of this documentation is to give a plain enough explanation of the algorithm so that application developers and validators can understand both the utility of the algorithm and understand how the new constrains may affect their network and topology. I'm blanking on the scheme we decided on for docs linking, so if anyone could remind me what link format we decided on, I'll go clean that up ASAP. Once this is merged, I intend to create a runbook for chains that see slower block-times or higher nil prevotes and link that runbook to this document to provide a higher-level overview. closes: #8046		3 years ago
..
README.md	spec: merge spec repo into tendermint repo (#7804)	3 years ago
proposer-based-timestamps.md	docs: add an overview of the proposer-based timestamps algorithm (#8058)	3 years ago
reactor.md	docs: add reactor sections (#6510)	3 years ago

README.md

order	parent
1	[{title Consensus} {order 6}]

Consensus

Tendermint Consensus is a distributed protocol executed by validator processes to agree on the next block to be added to the Tendermint blockchain. The protocol proceeds in rounds, where each round is a try to reach agreement on the next block. A round starts by having a dedicated process (called proposer) suggesting to other processes what should be the next block with the ProposalMessage. The processes respond by voting for a block with VoteMessage (there are two kinds of vote messages, prevote and precommit votes). Note that a proposal message is just a suggestion what the next block should be; a validator might vote with a VoteMessage for a different block. If in some round, enough number of processes vote for the same block, then this block is committed and later added to the blockchain. ProposalMessage and VoteMessage are signed by the private key of the validator. The internals of the protocol and how it ensures safety and liveness properties are explained in a forthcoming document.

For efficiency reasons, validators in Tendermint consensus protocol do not agree directly on the block as the block size is big, i.e., they don't embed the block inside Proposal and VoteMessage. Instead, they reach agreement on the BlockID (see BlockID definition in Blockchain section) that uniquely identifies each block. The block itself is disseminated to validator processes using peer-to-peer gossiping protocol. It starts by having a proposer first splitting a block into a number of block parts, that are then gossiped between processes using BlockPartMessage.

Validators in Tendermint communicate by peer-to-peer gossiping protocol. Each validator is connected only to a subset of processes called peers. By the gossiping protocol, a validator send to its peers all needed information (ProposalMessage, VoteMessage and BlockPartMessage) so they can reach agreement on some block, and also obtain the content of the chosen block (block parts). As part of the gossiping protocol, processes also send auxiliary messages that inform peers about the executed steps of the core consensus algorithm (NewRoundStepMessage and NewValidBlockMessage), and also messages that inform peers what votes the process has seen (HasVoteMessage, VoteSetMaj23Message and VoteSetBitsMessage). These messages are then used in the gossiping protocol to determine what messages a process should send to its peers.

We now describe the content of each message exchanged during Tendermint consensus protocol.