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:

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 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/
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 #


Footnotes #


  1. 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. ↩︎

  2. 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.) ↩︎

Calendar First posted April 12, 2023
Last modified by Benjamin Chan on May 30, 2025