The Simplex Consensus Protocol #
The simplest—and fastest—consensus protocol.
Simplex is a new consensus protocol that is faster than the state-of-the-art, and even easier to understand. It has both Byzantine and Crash-fault variants. It is suitable for both teaching and for implementation in practice. We hope that Simplex makes consensus more accessible to a wider audience. In particular, it has the easiest liveness proof known.
For protocol details, see [Protocol In a Nutshell].
Where It’s Being Used / Implementations #
Simplex is being actively implemented and deployed in production systems:
- Commonware Library - An optimized, open implementation in Rust [demo] [src]
- Solana Alpenglow - Upcoming deployment in Solana’s next-generation consensus (with modifications to support fast-path consensus) [talk]
- Ava Labs - An implementation in Go [src]
Academic References #
The protocol is peer-reviewed by the academic community.
Main Paper - Benjamin Y. Chan and Rafael Pass. “Simplex Consensus: A Simple and Fast Consensus Protocol”. Theory of Cryptography (TCC), 2023.
Potential Optimizations - Victor Shoup. “Sing a Song of Simplex”. 38th International Symposium on Distributed Computing (DISC), 2024.
What is Simplex Consensus? #
Simplex is a consensus protocol that is faster than the state-of-the-art (on paper), yet easier to understand (in our eyes). It solves Fault-Tolerant Consensus, also known as the blockchain problem: there are
Different players may see the transactions in different orders, but in the end they should all agree on the order.
Importantly,
Paxos, PBFT, and Blockchains
Simplex is designed for the same network and fault-tolerance setting as for the seminal PBFT protocol, as well as for protocols such as Algorand Agreement, Hotstuff, Tendermint, and Streamlet. The famous Paxos protocol, as well as Raft, is for a similar setting, but where nodes can only crash and do not deviate from the protocol (i.e. “crash faults” vs “byzantine faults”). Paxos in particular has found widespread deployment in Internet infrastructure ranging from Apache Zookeeper to Google’s Chubby Lock Service, playing a key role in every distributed system.
In the last decade, Byzantine Consensus has found its way into the heart of most “Proof-of-Stake” blockchains, where byzantine fault tolerance (BFT) is necessary because validators may be malicious in nature. Protocols such as Ethereum and Algorand use a byzantine consensus protocol under the hood to reach agreement on transactions. Unlike Bitcoin, the consensus protocols used tolerate extended periods of network failure without sacrificing security, do not require Proof-of-Work, and offer much faster finality. Unlike PBFT, the underlying consensus protocols typically require each block to be proposed by a different player, for fairness. Despite these widespread applications, the underlying consensus protocols remain complex.
Not only is Simplex easier to understand than the state-of-the-art, it also matches or improves latency compared with essentially all competing protocols1 in the Byzantine setting, under a theoretical analysis2. This makes the protocol an ideal candidate for both teaching and for deployment.
The Fastest Protocol Yet (BFT)
For the sake of demonstration, imagine a situation where
\(1/3\) of block proposers are missing or slow, and where every message takes exactly 80 ms to be delivered. Suppose that we are considering a blockchain setting, where leaders are randomly rotated, and that a transaction is submitted right before the next opportunity to mine or propose a new block. How long (on average) does it take the transaction to be confirmed or finalized?
Algorithm Expected Confirmation time Simplex (this post) 400 ms Algorand Agreement 480 ms ICC 560 ms PaLa 1200 ms Pipelined Fast-Hotstuff/
Jolteon1600 ms Chained Tendermint/
Casper FFG1840 ms Hotstuff 2480 ms Streamlet 2880 ms Note that we can think of the base Algorand agreement protocol and Fast-Hotstuff as versions of PBFT adapted to the blockchain setting. (For Jolteon, Fast-Hotstuff, and Hotstuff, which don’t specify concrete leader selection mechanisms, we assume that the leader is chosen randomly. For Chained Tendermint and Casper FFG, we consider the version specified in this post.)
Of course, such pessimism on leader quality may be unrealistic. Simplex also has great performance in optimistic conditions without faults, matching the state-of-the-art. See the paper for a more thorough analysis for both the pessimistic and optimistic case, as well as for a deep-dive comparison of popular protocols.
Note that our protocol has no relation to the famous Simplex Method for linear programming.
Sitemap #
- Introduction - You are here.
- Protocol in a Nutshell - Click here for a description of the protocol logic.
- Simplex for Crash Faults - Click here for the crash fault variant.
Footnotes #
-
In certain cases, classic protocols like PBFT may still offer slightly better latency than protocols designed for blockchains. This is because, when a transaction is sent to the system, it doesn’t need to wait for the next block proposal, unlike in blockchain systems. However, PBFT achieves this by having the same player propose every block (as long as it does not detectably misbehave). In other words, PBFT adopts a “stable-leader policy.” However, this is unsuitable for a blockchain application, where for fairness we require that a different player propose each block (see problems with miner extractable value in the Ethereum blockchain, for instance). Simplex can also be modified to use “stable leaders”, to match the optimistic latency of PBFT at the expense of fairness. ↩︎
-
The real-world latency of Simplex is also very promising, see this [demo] built by the amazing folks at Commonware. (They’ve done some serious engineering/research work on top of it.) ↩︎