The Libra blockchain development team is excited to share version 3 of the Libra consensus whitepaper with the community. This whitepaper features two important advances:
It moves the whitepaper close to the released open-source codebase. Moving on, the Libra blockchain development team is committed to continue maintaining close affinity between the whitepaper and the codebase.
It includes roadmap items shared by the Libra blockchain development team concerning several coming enhancements and extensions.
The whitepaper provides a high-level overview of the Libra network algorithmic core, LBFT. It starts with background on classic BFT solutions. It then outlines the algorithmic core of the Libra network; illustrated using detailed examples and artwork that explain tricky Byzantine attack scenarios.
The whitepaper explains the basic structure of the core 3-round consensus protocol, which is based on HotStuff, and the manner in which it spreads three rounds across three consecutive blocks in the chain. For example, a simple chain is depicted on the right. (Curious to know what QC means? then you should read the whitepaper!)
The whitepaper walks the reader through sophisticated scenarios as shown below, illustrating how LBFT maintains safety against Byzantine attacks. On the left is a forking scenario created by a single Byzantine leader. On the right is a scenario that forks from a commit branch, right after the committed block, abandoning all but the committed block. The whitepaper discusses the commits resulting in these scenarios.
The whitepaper serves as a high-level code walkthrough. It includes an accurate and detailed pseudo-code that reflects the code structure and key parts, with slight deviations driven only by brevity or encapsulation considerations. Names of API methods and modules reflect actual codebase names as much as possible.
The description breaks down the code into the following modules:
Ledger module: stores a local, forkable speculative ledger state.
Block-tree module : creates proposal blocks and votes. It keeps track of a tree of blocks pending commitment with votes and QC's on them.
Safety module: implements the core consensus safety rules.
Pacemaker module: is the liveness keeper that advances rounds.
ProposerElection module: maps rounds to leaders.
A Main module is the glue that dispatches messages and timer event handlers.
Take one module as an example, the Pacemaker. The whitepaper describes the implementation details materialized in the Libra blockchain for guaranteeing liveness. A requisite for progress is round synchronization, a mechanism for bringing all honest validators to execute the same round for sufficient overlap.
Round synchronization is governed by the Pacemaker module. The Pacemaker keeps track of votes and of time. In a "happy path", the Pacemaker module at each validator observes progress (a leader proposal for the current round) and advances to the next round. In a "recovery path", the Pacemaker observes lack of progress in a round. Upon a local round timeout, the Pacemaker broadcasts a TimeoutMsg notification.
Whenever the Pacemaker receives a certificate, either a quorum certificate (QC) or a timeout certificate (TC), it instructs the validator to advance to the next round. It additionally instructs the validator to forward the QC/TC to the leader of the round. This guarantees that upon entering a round with an honest leader, all validators will synchronize to within two network transmission delays.
These sub-algorithms and others are explained in the whitepaper, accompanied by detailed pseudocode and correctness proof arguments.
The whitepaper touches on some roadmap topics that the Libra blockchain will include in the future. More details about each topic will appear in supplemental documents in the near future.
Briefly, the Libra blockchain development team is sharing in this whitepaper high level notes on epoch-change and reconfiguration; on deploying TCB to increase validator security; on two performance enhancements, "nil-block" and "alternate-proposer", devised in order to cope with faulty validators acting in leader role; and on increasing BFT beyond one-third via flexibility approaches.