Simplifying Facebook LibraBFT Consensus Protocol

Libra BFT consensus

When Facebook announced the Libra Blockchain, I was keen to learn about the LibraBFT—the consensus protocol that would power this cryptocurrency and its distributed infrastructure.

Having extensively gone through their released developer documentation, I’d like to present a technical simplification of the Facebook LibraBFT consensus.

Before we can delve into the analysis, we need to understand why the choice of a consensus algorithm is a critical decision for protocol developers to make. On any open distributed ledger network a consensus mechanism functions to:

  • Prevent double spend and even store transaction data in distributed ledgers.
  • Ensure transaction validation by endorsing, ordering and validating transactions.
  • Facilitate the decision-making model between network participants (developers, miners, exchanges, users)

Above all, the network consensus mechanism ensures that critical participant agreement activity is written and validated. Thus, a consensus algorithm is responsible for securely updating the state of the data across a distributed network.

Libra Consensus

Similar to all Byzantine Fault Tolerance (BFT) based networks, LibraBFT nodes (or Validators) collectively decide which transactions will be added to the Libra Blockchain. Each BFT node has a designated validator called a Leader responsible for proposing new blocks and obtaining signed votes from the other validators on their proposals.

Moreover, these Validator nodes use a consensus algorithm that can tolerate the presence of malicious (Byzantine) validators by maintaining the history of all the transactions on the blockchain. They also keep the current state to execute transactions and can calculate the next state.

Quoting Libra Consensus white paper:

The Libra protocol uses a variant of the HotStuff consensus protocol, a recent Byzantine fault-tolerant (BFT) consensus protocol, called LibraBFT. It provides safety (all honest validators agree on commits and execution) and liveness (commits are continually produced) in the partial synchrony model defined in the paper “Consensus in the Presence of Partial Synchrony” by Dwork, Lynch, and Stockmeyer (DLS) and mentioned in the paper “Practical Byzantine Fault Tolerance” (PBFT) by Castro and Liskov, as well as newer protocols such as Tendermint.

The HotStuff consensus algorithm, in particular, is a leader-based Byzantine fault-tolerant replication protocol. It was proposed by VMware Research in March 2018 and is being officially published at the 2019 ACM Symposium on Principles of Distributed Computing.

HotStuff attempts to address the complexity of practical BFT. To maintain its liveness property, non-faulty replicas run commands identically and produce similar responses for each command. In this model, N ≥ 3f + 1 (3 honest, 1 faulty node) is required for non-faulty replicas to agree on the same commands, in the same order and progress can be ensured deterministically.

Features of LibraBFT

Facebook LibraBFT consensus essentially assumes that at any point in time 3f + 1 votes are distributed among a set of validators that may be honest or Byzantine (faulty). The aim is to ensure that LibraBFT remains safe—preventing attacks such as double spends and forks when at most f (one) votes are controlled by malicious validators. Besides the model ensures that the total amount of malicious nodes on the network do not exceed more than 1/3 of the total number of network nodes.

That said, LibraBFT remains live, committing transactions from clients, as long as there exists a global stabilization time (GST). Beyond the GST, all messages between honest validators are delivered to other honest validators within a maximal network delay. In addition to traditional guarantees, Facebook LibraBFT maintains safety during its block generation and confirmation following more of a “Commander and Lieutenant” format.

When a client sends a request to the primary node the request is processed as follows:

  1. Leader block proposals are organized into a chain using cryptographic hashes.
  2. If the proposal is valid and timely, each honest node will sign it and send a vote back to the leader.
  3. After the leader has received enough votes to reach a quorum, it aggregates the votes into a Quorum Certificate (QC) that extends the same chain again.
  4. The QC is broadcast to every node.
  5. If the leader fails to assemble a QC, participants will timeout and move to the next round.
  6. Eventually, enough blocks and QCs will extend the chain in a timely manner, and a block will match the commit rule of the protocol.
  7. When this happens, the chain of uncommitted blocks up to the matching block become committed.

According to the Facebook Libra whitepaper, the choice for the HotStuff protocol as the basis for LibraBFT is based on: (i) simplicity and modularity; (ii) ability to easily integrate consensus with execution; and (iii) promising performance in early experiments.

The HotStuff protocol decomposes into modules for safety (voting and commit rules) and liveness (pacemaker). This decoupling provides the ability to develop and experiment independently and on different modules in parallel.


BFT is not something new as there are many blockchain projects using it today BFT e.g Hyperledger. Hopefully, this short article can help you understand Facebook LibraBFT consensus and how HotStuff implementation will be deployed to secure the Libra Network.

Share this story:

About the author

Sonia John

Sonia John

Sonia John (realchainlife) is an independent BOT & PROTOCOL DEVELOPER, WRITER and SPEAKER from Africa. Sonia writes, tweets, speaks and share code about building distributed & decentralized systems.