One consensus lineage from HotStuff to AptosBFT, with the cost each change carried and the measured effect where one was published.
Wisdom||6 min read
This article traces one consensus lineage: HotStuff (2019) to LibraBFT (2019) to DiemBFT v4 (2021) to AptosBFT in production (2022 to today). Each section states what changed, the artifact that documents it, the cost the change carried, and the measured effect where one was published. Superscript numerals key each claim to the reference list at the end. Every reference was opened and confirmed to resolve on 15 May 2025.
A blockchain has no central sequencer, so its validators must agree on the order of transactions before anyone can trust the ledger. The property that makes this survivable is Byzantine fault tolerance. In this protocol family the system is sized at n validators tolerating f Byzantine validators where f is less than n/3, and a block is certified when 2f+1 validators vote for it, forming a quorum certificate.1 Aptos weights that quorum by stake rather than by validator count.2 Once a block is committed under the rules below, no competing history can replace it, which is what irreversibility means here rather than a probability that decays with depth.
The path of a transaction through this machinery is short. A client submits it, validators collect it into their mempools and check it, a round leader proposes a block, validators verify and vote, and the certificate commits it.
LibraBFT was the consensus protocol of Facebook's Libra.1 It is based on HotStuff,3 whose defining property is linearity: in the common case, deciding a block costs no more communication than spreading the decision to every validator. LibraBFT refined HotStuff by adding explicit liveness mechanisms and a concrete latency analysis, and it carries a formal safety proof from which criteria for detecting validator misbehaviour are derived, along with a reward and punishment mechanism built on those criteria.1
The system is a state-machine-replication engine. Validators agree on a sequence of transactions and apply them deterministically to a replicated ledger state. Configuration changes travel inside that same sequence: an epoch-change command carrying special credentials can alter any part of the algorithm, from the validator set to the protocol itself, without a fork.1 Safety holds while fewer than one third of validators are Byzantine and does not depend on network timing; liveness requires partial synchrony, meaning progress is guaranteed only after an unknown global stabilisation time.14 The deployment, though not the protocol, was permissioned, with validators admitted by the Association.1
Libra was renamed Diem, and the Diem team published DiemBFT v4, revised 18 August 2021.4 Three changes matter, and each carries a cost stated in the paper itself.
| Change | What it does | What it costs |
|---|---|---|
| Two-chain commit rule, drawing on Jolteon5 | A block commits once its direct child in the next round is certified, two steps instead of HotStuff's three.4 | The view change becomes quadratic rather than linear. DiemBFT keeps HotStuff's linear cost while the leader is alive and pays a quadratic cost per round during instability, up to a cubic worst case comparable to PBFT.4 |
| Timeout certificates with Bracha-style boosting | A validator that gives up on a round broadcasts a signed timeout; 2f+1 of these form a timeout certificate that advances the round without a proposal, so a failed leader cannot stall the chain.4 | Rounds retired by timeout carry the quadratic message cost above. |
| Leader reputation | Leaders are chosen from validators that signed recent committed blocks, excluding the authors of the last few committed blocks, with round-robin as the fallback when the reputation state is unavailable. Crashed leaders stop being elected, which is the leader-utilisation property.4 | Validators can disagree on the leader's identity for a bounded number of rounds after stabilisation, and the paper bounds that number rather than eliminating it.4 |
A fourth change is structural rather than performance-related. The voting rules that guard safety are isolated in a module holding two counters and a constant memory footprint, which allows it to run inside a secure hardware enclave. This admits a third validator class between honest and Byzantine: a compromised validator, whose code the adversary controls everywhere except inside that module. Safety holds for any number of compromised validators so long as fewer than one third are fully Byzantine.4
None of this ran on a public network. The Diem Association announced the sale of its assets on 31 January 2022 and wound down,6 so the first production test of the design happened elsewhere.
Aptos Labs, founded by former Diem engineers, open-sourced the codebase and launched mainnet in October 2022 with 102 validator nodes across 22 countries.7 AptosBFT is a Jolteon variant carrying the DiemBFT v4 design forward: leader rotation with reputation, the two-chain commit rule, and the pacemaker. Two production changes since launch matter most.
Quorum Store, deployed by AIP-26 in the v1.5 upgrade on 18 July 2023, is the first production implementation of Narwhal-style data dissemination.8 Before it, every transaction crossed the network twice, once through the mempool and once inside the leader's proposal, and the leader's bandwidth capped the throughput of the whole network. Quorum Store has validators batch and certify transaction data in parallel, so consensus orders batch proofs rather than raw transactions. Aptos Labs' tests reported a 12x throughput gain in consensus-only benchmarks and 3x end to end on a mainnet-like network of over 100 nodes.8 The AIP states the limit alongside the gain: the full benefit of decoupled dissemination is not realised under a leader-based protocol, which is the argument for the DAG work below.8
The second change is the shape of the pipeline. Mempool, Quorum Store, consensus, execution via Block-STM,9 and storage run as separate stages, each optimised on its own. Zaptos overlaps those stages and reports sub-second end-to-end latency at 20k TPS in a geo-distributed deployment.10
The published direction is towards DAG-based ordering, where every validator proposes concurrently rather than one leader per round. Shoal, a pipelining and leader-reputation framework for Narwhal-based protocols such as Bullshark, reports latency reductions of up to 40% in failure-free runs and up to 80% under failures against the vanilla Bullshark implementation.11 Protocol changes on Aptos ship through on-chain governance, the mechanism that deployed Quorum Store,8 rather than through hard forks, so the upgrade path for a future ordering protocol already exists and has been exercised.
The claims in this lineage are of two kinds and deserve different confidence. The safety properties, the one-third fault bound and deterministic finality, are proofs, and they hold wherever their assumptions hold: partial synchrony for liveness, and an adversary that cannot reach inside the safety module for the compromised-validator case. The performance figures are benchmarks, each measured under stated conditions on test networks. The number that matters to an application is its own end-to-end latency on mainnet under its own workload, and that is a number to measure rather than quote. The trigger for revisiting this article is a DAG-based ordering protocol reaching Aptos mainnet with published production figures.
Baudet et al. (2019). State Machine Replication in the Libra Blockchain. developers.diem.com
Aptos Labs (2022). The Aptos Blockchain: Safe, Scalable, and Upgradeable Web3 Infrastructure. aptosfoundation.org
Yin et al. (2019). HotStuff: BFT Consensus with Linearity and Responsiveness. PODC 2019. arxiv.org
The Diem Team (2021). DiemBFT v4: State Machine Replication in the Diem Blockchain, revised 18 August 2021. developers.diem.com
Gelashvili et al. (2021). Jolteon and Ditto: Network-Adaptive Efficient Consensus with Asynchronous Fallback. arXiv:2106.10362. arxiv.org
Diem Association (2022). Statement by Diem CEO Stuart Levey on the Sale of the Diem Group's Assets to Silvergate. prnewswire.com
Aptos Foundation (2022). Aptos 2022 End-of-Year Community Update. aptosfoundation.org
Aptos Foundation (2023). AIP-26: Quorum Store. github.com
Gelashvili et al. (2022). Block-STM: Scaling Blockchain Execution by Turning Ordering Curse to a Performance Blessing. arXiv:2203.06871. arxiv.org
Xiang et al. (2025). Zaptos: Towards Optimal Blockchain Latency. arXiv:2501.10612. arxiv.org
Spiegelman et al. (2023). Shoal: Improving DAG-BFT Latency and Robustness. arXiv:2306.03058. arxiv.org