The Tezos Consensus Algorithm
- Tenderbake is tailored to match the Tezos architecture by using only communication primitives and network assumptions which Tezos supports.
- Tenderbake makes weaker network assumptions than Tendermint, at the price of adding the extra assumption that participants have loosely synchronized clocks — which is fine, because Tezos already uses them.
Tenderbake is executed for each new block level by a “committee” whose members are called validators, which are delegates selected at random based on their stake, in the same way as endorsers are selected in Emmy*. We let
CONSENSUS_COMMITTEE_SIZEbe the number of validator slots per level. Furthermore, we use
CONSENSUS_THRESHOLDto denote two thirds of
For each level, Tenderbake proceeds in rounds. Each round represents an attempt by the validators to agree on the content of the block for the current level, that is, on the sequence of non-consensus operations the block contains. We call this sequence the block’s payload.
Each round has an associated duration. Round durations are set to increase so that for any possible message delay, there is a round that is sufficiently long for all required messages to be exchanged. Round durations depend on protocol parameters
DELAY_INCREMENT_PER_ROUND. These parameters specify round durations as follows:
Round durations thus increase linearly with
Schematically, a round consists in the following steps:
- a validator designated for that round injects a candidate block (representing a proposal) and consensus operations (representing votes) into the node to which it is attached, which then
- diffuses those blocks and consensus operations to other nodes of the network, and thus
- communicates them to the validators attached to those nodes, to carry out voting on which block to accept.
Unlike Emmy*, Tenderbake has two types of votes: before endorsing a block
b, a validator preendorses
b. Furthermore, to be able to endorse, a validator must have observed a preendorsement quorum, that is a set of preendorsements from validators having at least
CONSENSUS_THRESHOLDvalidator slots. Similarly, to be able to decide, a validator must have observed an endorsement quorum, that is, a set of endorsements from validators having at least
CONSENSUS_THRESHOLDvalidator slots. The endorsement quorum for a block
bis included in a block
b'on top of
b, serving as a certification that
bhas been agreed upon. We also say that block
The validator’s whose turn is to inject a candidate block at a given round is called the proposer at that round. Proposers in Tenderbake are selected similarly to bakers in Emmy*: the proposer at round
ris the validator who has the validator slot
r. A proposer who has observed a preendorsement quorum for a candidate block in a previous round, is required to propose a block with the same payload as the initial block. We talk about a re-proposal in this case. For more information please see: https://tezos.gitlab.io/active/consensus.html