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 \(n\) people communicating over an unreliable network, all trying to agree on the ordering of a set of transactions (for example, financial transactions, or database writes). Each player receives transactions over time, and wants to output the same transactions in the same order as everyone else does.

Different players may see the transactions in different orders, but in the end they should all agree on the order. Importantly, \(f\) out of the \(n\) players may be faulty. Depending on the model, faulty players may crash (and otherwise behave correctly), or worse, they may be malicious and deviate from the protocol. The protocol must also be able to withstand a unreliable network that sometimes drops messages, or is partitioned (such as when Armenia lost Internet for 5 hours when a woman accidentally cut a cable with a shovel).

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 protocols¹ in the Byzantine setting, under a theoretical analysis². 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/ Jolteon	1600 ms
Chained Tendermint/ Casper FFG	1840 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 #