Module linera_chain::manager

source ·
Expand description

§Chain manager

This module contains the consensus mechanism for all microchains. Whenever a block is confirmed, a new chain manager is created for the next block height. It manages the consensus state until a new block is confirmed. As long as less than a third of the validators are faulty, it guarantees that at most one ConfirmedBlock certificate will be created for this height.

The protocol proceeds in rounds, until it reaches a round where a block gets confirmed.

There are four kinds of rounds:

  • In Round::Fast, only super owners can propose blocks, and validators vote to confirm a block immediately. Super owners must be careful to make only one block proposal, or else they can permanently block the microchain. If there are no super owners, Round::Fast is skipped.
  • In cooperative mode (Round::MultiLeader), all chain owners can propose blocks at any time. The protocol is guaranteed to eventually confirm a block as long as no chain owner continuously actively prevents progress.
  • In leader rotation mode (Round::SingleLeader), chain owners take turns at proposing blocks. It can make progress as long as at least one owner is honest, even if other owners try to prevent it.
  • In fallback/public mode (Round::Validator), validators take turns at proposing blocks. It can always make progress under the standard assumption that there is a quorum of honest validators.

§Safety, i.e. at most one block will be confirmed

In all modes this is guaranteed as follows:

  • Validators (honest ones) never cast a vote if they have already cast any vote in a later round.
  • Validators never vote for a ValidatedBlock A in round r if they have voted for a different ConfirmedBlock B in an earlier round s ≤ r, unless there is a ValidatedBlock certificate (with a quorum of validator signatures) for A in some round between s and r included in the block proposal.
  • Validators only vote for a ConfirmedBlock if there is a ValidatedBlock certificate for the same block in the same round. (Or, in the Fast round, if there is a valid proposal.)

This guarantees that once a quorum votes for some ConfirmedBlock, there can never be a ValidatedBlock certificate (and thus also no ConfirmedBlock certificate) for a different block in a later round. So if there are two different ConfirmedBlock certificates, they may be from different rounds, but they are guaranteed to contain the same block.

§Liveness, i.e. some block will eventually be confirmed

In Round::Fast, liveness depends on the super owners coordinating, and proposing at most one block.

If they propose none, and there are other owners, Round::Fast will eventually time out.

In cooperative mode, if there is contention, the owners need to agree on a single owner as the next proposer. That owner should then download all highest-round certificates and block proposals known to the honest validators. They can then make a proposal in a round higher than all previous proposals. If there is any ValidatedBlock certificate they must include the highest one in their proposal, and propose that block. Otherwise they can propose a new block. Now all honest validators are allowed to vote for that proposal, and eventually confirm it.

If the owners fail to cooperate, any honest owner can initiate the last multi-leader round by making a proposal there, then wait for it to time out, which starts the leader-based mode:

In leader-based and fallback/public mode, an honest participant should subscribe to notifications from all validators, and follow the chain. Whenever another leader’s round takes too long, they should request timeout votes from the validators to make the next round begin. Once the honest participant becomes the round leader, they should update all validators, so that they all agree on the current round. Then they download the highest ValidatedBlock certificate known to any honest validator and include that in their block proposal, just like in the cooperative case.

Structs§

  • ChainManager
    The state of the certification process for a chain’s next block.
  • ChainManagerInfo
    Chain manager information that is included in ChainInfo sent to clients.

Enums§

  • LockingBlock
    The latest block that validators may have voted to confirm: this is either the block proposal from the fast round or a validated block certificate. Validators are allowed to vote for this even if they have locked (i.e. voted to confirm) a different block earlier.
  • Outcome
    The result of verifying a (valid) query.

Type Aliases§