Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Byzantine Consensus Algorithm
NOTE: this wiki is mostly deprecated and left for archival purposes. Please see the documentation website which is built from the docs directory. Additional information about the specification can also be found in that directory.
- The network is composed of optionally connected nodes. Nodes directly connected to a particular node are called peers.
- The consensus process in deciding the next block (at some height
H) is composed of one or many rounds.
Commitrepresent state machine states of a round. (aka
RoundStepor just "step").
- A node is said to be at a given height, round, and step, or at
(H,R,S), or at
(H,R)in short to omit the step.
- To prevote or precommit something means to broadcast a prevote vote or precommit vote for something.
- A vote at
(H,R)is a vote signed with the bytes for
Rincluded in its
- +2/3 is short for "more than 2/3"
- 1/3+ is short for "1/3 or more"
- A set of +2/3 of prevotes for a particular block or
(H,R)is called a proof-of-lock-change or PoLC for short.
State Machine Overview
At each height of the blockchain a round-based protocol is run to determine
the next block. Each round is composed of three steps (
Precommit), along with two special steps
In the optimal scenario, the order of steps is:
NewHeight -> (Propose -> Prevote -> Precommit)+ -> Commit -> NewHeight ->...
(Propose -> Prevote -> Precommit) is called a round. There may be more than one round required to commit a block at a given height. Examples for why more rounds may be required include:
- The designated proposer was not online.
- The block proposed by the designated proposer was not valid.
- The block proposed by the designated proposer did not propagate in time.
- The block proposed was valid, but +2/3 of prevotes for the proposed block were not received in time for enough validator nodes by the time they reached the
Precommitstep. Even though +2/3 of prevotes are necessary to progress to the next step, at least one validator may have voted
<nil>or maliciously voted for something else.
- The block proposed was valid, and +2/3 of prevotes were received for enough nodes, but +2/3 of precommits for the proposed block were not received for enough validator nodes.
Some of these problems are resolved by moving onto the next round & proposer. Others are resolved by increasing certain round timeout parameters over each successive round.
State Machine Diagram
+-------------------------------------+ v |(Wait til `CommmitTime+timeoutCommit`) +-----------+ +-----+-----+ +----------> | Propose +--------------+ | NewHeight | | +-----------+ | +-----------+ | | ^ |(Else, after timeoutPrecommit) v | +-----+-----+ +-----------+ | | Precommit | <------------------------+ Prevote | | +-----+-----+ +-----------+ | |(When +2/3 Precommits for block found) | v | +--------------------------------------------------------------------+ | Commit | | | | * Set CommitTime = now; | | * Wait for block, then stage/save/commit block; | +--------------------------------------------------------------------+
A node may not have a corresponding validator private key, but it nevertheless plays an active role in the consensus process by relaying relevant meta-data, proposals, blocks, and votes to its peers. A node that has the private keys of an active validator and is engaged in signing votes is called a validator-node. All nodes (not just validator-nodes) have an associated state (the current height, round, and step) and work to make progress.
Between two nodes there exists a
Connection, and multiplexed on top of this connection are fairly throttled
Channels of information. An epidemic gossip protocol is implemented among some of these channels to bring peers up to speed on the most recent state of consensus. For example,
- Nodes gossip
PartSetparts of the current round's proposer's proposed block. A LibSwift inspired algorithm is used to quickly broadcast blocks across the gossip network.
- Nodes gossip prevote/precommit votes. A node NODE_A that is ahead of NODE_B can send NODE_B prevotes or precommits for NODE_B's current (or future) round to enable it to progress forward.
- Nodes gossip prevotes for the proposed PoLC (proof-of-lock-change) round if one is proposed.
- Nodes gossip to nodes lagging in blockchain height with block commits for older blocks.
- Nodes opportunistically gossip
HasVotemessages to hint peers what votes it already has.
- Nodes broadcast their current state to all neighboring peers. (but is not gossiped further)
There's more, but let's not get ahead of ourselves here.
A proposal is signed and published by the designated proposer at each round. The proposer is chosen by a deterministic and non-choking round robin selection algorithm that selects proposers in proportion to their voting power. (see implementation)
A proposal at
(H,R) is composed of a block and an optional latest
PoLC-Round < R which is included iff the proposer knows of one. This hints the network to allow nodes to unlock (when safe) to ensure the liveness property.
State Machine Spec
Propose Step (height:H,round:R)
- The designated proposer proposes a block at
Propose step ends:
Propose. --> goto
- After receiving proposal block and all prevotes at
PoLC-Round. --> goto
- After common exit conditions
Prevote Step (height:H,round:R)
Prevote, each validator broadcasts its prevote vote.
- First, if the validator is locked on a block since
LastLockRoundbut now has a PoLC for something else at round
LastLockRound < PoLC-Round < R, then it unlocks.
- If the validator is still locked on a block, it prevotes that.
- Else, if the proposed block from
Propose(H,R)is good, it prevotes that.
- Else, if the proposal is invalid or wasn't received on time, it prevotes
Prevote step ends:
- After +2/3 prevotes for a particular block or
<nil>. --> goto
timeoutPrevoteafter receiving any +2/3 prevotes. --> goto
- After common exit conditions
Precommit Step (height:H,round:R)
Precommit, each validator broadcasts its precommit vote.
- If the validator has a PoLC at
(H,R)for a particular block
B, it (re)locks (or changes lock to) and precommits
LastLockRound = R.
- Else, if the validator has a PoLC at
<nil>, it unlocks and precommits
- Else, it keeps the lock unchanged and precommits
A precommit for
<nil> means "I didn’t see a PoLC for this round, but I did get +2/3 prevotes and waited a bit".
The Precommit step ends:
- After +2/3 precommits for
<nil>. --> goto
timeoutPrecommitafter receiving any +2/3 precommits. --> goto
- After common exit conditions
common exit conditions
- After +2/3 precommits for a particular block. --> goto
- After any +2/3 prevotes received at
(H,R+x). --> goto
- After any +2/3 precommits received at
(H,R+x). --> goto
Commit Step (height:H)
CommitTime = now()
- Wait until block is received. --> goto
NewHeight Step (height:H)
LastCommitand increment height.
StartTime = CommitTime+timeoutCommit
- Wait until
StartTimeto receive straggler commits. --> goto
Proof of Safety
Assume that at most -1/3 of the voting power of validators is byzantine. If a validator commits block
B at round
R, it's because it saw +2/3 of precommits at round
R. This implies that 1/3+ of honest nodes are still locked at round
R' > R. These locked validators will remain locked until they see a PoLC at
R' > R, but this won't happen because 1/3+ are locked and honest, so at most -2/3 are available to vote for anything other than
Proof of Liveness
If 1/3+ honest validators are locked on two different blocks from different rounds, a proposers'
PoLC-Round will eventually cause nodes locked from the earlier round to unlock. Eventually, the designated proposer will be one that is aware of a PoLC at the later round. Also,
timeoutProposalR increments with round
R, while the size of a proposal are capped, so eventually the network is able to "fully gossip" the whole proposal (e.g. the block & PoLC).
Proof of Fork Accountability
Define the JSet (justification-vote-set) at height
H of a validator
V1 to be all the votes signed by the validator at
H along with justification PoLC prevotes for each lock change. For example, if
V1 signed the following precommits:
Precommit(B1 @ round 0),
Precommit(<nil> @ round 1),
Precommit(B2 @ round 4) (note that no precommits were signed for rounds 2 and 3, and that's ok),
Precommit(B1 @ round 0) must be justified by a PoLC at round 0, and
Precommit(B2 @ round 4) must be justified by a PoLC at round 4; but the precommit for
<nil> at round 1 is not a lock-change by definition so the JSet for
V1 need not include any prevotes at round 1, 2, or 3 (unless
V1 happened to have prevoted for those rounds).
Further, define the JSet at height
H of a set of validators
VSet to be the union of the JSets for each validator in
VSet. For a given commit by honest validators at round
R for block
B we can construct a JSet to justify the commit for
We say that a JSet justifies a commit at
(H,R) if all the committers (validators in the commit-set) are each justified in the JSet with no duplicitous vote signatures (by the committers).
- Lemma: When a fork is detected by the existence of two conflicting commits, the union of the JSets for both commits (if they can be compiled) must include double-signing by at least 1/3+ of the validator set. Proof: The commit cannot be at the same round, because that would immediately imply double-signing by 1/3+. Take the union of the JSets of both commits. If there is no double-signing by at least 1/3+ of the validator set in the union, then no honest validator could have precommitted any different block after the first commit. Yet, +2/3 did. Reductio ad absurdum.
As a corollary, when there is a fork, an external process can determine the blame by requiring each validator to justify all of its round votes. Either we will find 1/3+ who cannot justify at least one of their votes, and/or, we will find 1/3+ who had double-signed.
Alternatively, we can take the JSet of a commit to be the "full commit". That is, if light clients and validators do not consider a block to be committed unless the JSet of the commit is also known, then we get the desirable property that if there ever is a fork (e.g. there are two conflicting "full commits"), then 1/3+ of the validators are immediately punishable for double-signing.
There are many ways to ensure that the gossip network efficiently share the JSet of a commit. One solution is to add a new message type that tells peers that this node has (or does not have) a +2/3 majority for B (or ) at (H,R), and a bitarray of which votes contributed towards that majority. Peers can react by responding with appropriate votes.
We will implement such an algorithm for the next iteration of the Tendermint consensus protocol.
Other potential improvements include adding more data in votes such as the last known PoLC round that caused a lock change, and the last voted round/step (or, we may require that validators not skip any votes). This may make JSet verification/gossip logic easier to implement.
Due to the definition of a block commit, any 1/3+ coalition of validators can halt the blockchain by not broadcasting their votes. Such a coalition can also censor particular transactions by rejecting blocks that include these transactions, though this would result in a significant proportion of block proposals to be rejected, which would slow down the rate of block commits of the blockchain, reducing its utility and value. The malicious coalition might also broadcast votes in a trickle so as to grind blockchain block commits to a near halt, or engage in any combination of these attacks.
If a global active adversary were also involved, it can partition the network in such a way that it may appear that the wrong subset of validators were responsible for the slowdown. This is not just a limitation of Tendermint, but rather a limitation of all consensus protocols whose network is potentially controlled by an active adversary.
Overcoming Forks and Censorship Attacks
For these types of attacks, a subset of the validators through external means should coordinate to sign a reorg-proposal that chooses a fork (and any evidence thereof) and the initial subset of validators with their signatures. Validators who sign such a reorg-proposal forego its collateral on all other forks. Clients should verify the signatures on the reorg-proposal, verify any evidence, and make a judgement or prompt the end-user for a decision. For example, a phone wallet app may prompt the user with a security warning, while a refrigerator may accept any reorg-proposal signed by +½ of the original validators.
No non-synchronous Byzantine fault-tolerant algorithm can come to consensus when ⅓+ of validators are dishonest, yet a fork assumes that ⅓+ of validators have already been dishonest by double-signing or lock-changing without justification. So, signing the reorg-proposal is a coordination problem that cannot be solved by any non-synchronous protocol (i.e. automatically, and without making assumptions about the reliability of the underlying network). It must be provided by means external to the weakly-synchronous Tendermint consensus algorithm. For now, we leave the problem of reorg-proposal coordination to human coordination via internet media. Validators must take care to ensure that there are no significant network partitions, to avoid situations where two conflicting reorg-proposals are signed.
Assuming that the external coordination medium and protocol is robust, it follows that forks are less of a concern than censorship attacks.
0.6 -> 0.7 (current)
- Reduced the minimum number of signature steps from 3 to 2 by removing the "commit" vote and step.
- The protocol is more asynchronous: instead of each round taking a predetermined duration of time, each step of a round progresses after +2/3 of the step's votes are found and a timeout is reached, or immediately after +2/3 of matching votes (e.g. a PoLC for prevotes, or a commit for precommits).