Chapter: Simplex

This post is a map of the Simplex line of posts on Decentralized Thoughts. It is meant to be read as a chapter: first the core Simplex idea, then some of the main ways to vary it.

A salient property of Simplex is that parties leave a view only with a value certificate or a skip certificate. This is in contrast to protocols like PBFT, HotStuff, Casper, and Tendermint, where a view may end without an explicit certificate for that view.

This insistence on explicit certificates for values and for skipped views gives a $3\delta$ good-case at $n=3f+1$ with a worst-case view latency of $3\Delta+\delta$. From there, the Simplex family splits along several axes: same resilience but better worst-case view latency, more validators for a two round good-case, fixed view schedules, and variants that control certificate growth.

The Core Simplex Idea

If you are familiar with Tendermint, then from Tendermint to Simplex is the best entry point. That post starts from a Tendermint style protocol and changes it into Simplex. The important change is having either a value certificate or a skip certificate for view $v$ and using the fact that a skip certificate for view $v$ proves that no decision certificate can form in that view.

This is what removes the Tendermint leader wait. In Tendermint, a leader waits because some party may hold a hidden lock from the previous view. In Simplex, a proposal can instead include a value certificate from the highest relevant view and skip certificates for the intervening views. A party that verifies those certificates can vote without waiting for the leader to collect every hidden lock.

The original sources around this point are:

Simplex Consensus, Ben Chan and Rafael Pass’s presentation of the protocol.
Simplex Consensus: A Simple and Fast Consensus Protocol, the paper.
Sing a Song of Simplex, Victor Shoup’s follow up with DispersedSimplex, stable leaders, and implementation optimizations.
Commonware’s Simplex module, an implementation oriented reference.

Two later DT posts give a second path into the same protocol: Benign Simplex and From Benign Simplex to Byzantine Simplex. The benign post isolates the explicit NoVote message under omission failures: if enough parties report that they did not see a value in a view, then parties can skip that view. The Byzantine post turns this into signed bottom votes, Byzantine quorum intersection, external validity, and the exact Simplex skip property:

if a view has $n-f$ bottom votes, then no decision certificate can form in that view.

This pair is useful because it makes the authenticated Simplex proof feel like a small change to a simpler omission failure protocol.

The benign presentation also connects Simplex to earlier DT posts on Benign HotStuff, Chained Raft, and Log Paxos. Those posts are not Simplex variants, but they explain the rotating leader and chain based viewpoint behind the benign construction.

The Modular View

Deconstructing Simplex turns the protocol into two pieces:

an outer proposal rule that says when a proposal is valid based on previous value certificates and skip certificates;
an inner Graded Broadcast instance that produces a regular certificate, a strong certificate, or a skip certificate for each view.

We will use this decomposition in the rest of the chapter. Many Simplex variants leave the outer proposal rule essentially unchanged and replace the inner certificate structure.

The same decomposition also explains how to move from single-shot Simplex to a chained protocol. From Single-Shot Simplex to Chained Simplex shows how to run the Simplex logic as a state machine replication protocol, where each decided block extends a previous decided prefix. The construction can be applied to Simplex variants that keep the same outer proposal structure and the same inner certificate properties. This is the bridge from the single-shot protocols in the chapter to blockchain style executions with a growing chain of blocks.

The decomposition post also explains the relationship with the earlier DT post on PBFT via Locked Broadcast and Recover Max Lock. PBFT style protocols prove safety by collecting enough locks. Simplex proves safety by showing skip certificates for the views that might otherwise hide a decision. The inner Graded Broadcast is also close in spirit to authenticated Reliable Broadcast with external validity, in the framework of Cachin, Kursawe, Petzold, and Shoup.

Better Worst-Case View Latency at $3f+1$

The first direction keeps the same authenticated $n=3f+1$ setting and tries to reduce worst case view latency.

C-Simplex and Kuplex contains two variants:

C-Simplex improves silent views. If the leader is silent, parties can send a bottom final message after $2\Delta$, so the silent view ends within $2\Delta+\delta$. The worst case view latency remains $3\Delta+\delta$.
Kuplex improves the worst case view latency when the actual delay $\delta$ is much smaller than the timeout parameter $\Delta$. It uses an early negative vote and a second value vote, obtaining worst case view latency $2\Delta+2\delta$ and silent view latency $2\Delta+\delta$.

These protocols are best understood as local changes to the Simplex inner protocol.

This section is also where Kudzu enters the picture. Kudzu is designed around a fast path and high throughput. The Kuplex post extracts the $3f+1$ view latency aspect into a Simplex style variant.

Two Round Good Case With More Validators

The second direction asks for a different improvement: can an honest leader decide after one proposal and one vote round?

At optimal resilience, the answer is no. The post Why BFT Needs Three Rounds explains the lower bound: for $n\leq 5f-2$, Byzantine broadcast in partial synchrony needs at least three rounds in the good case. This is why PBFT, Tendermint, Casper FFG, HotStuff, and Simplex all have the familiar proposal plus two voting rounds at $n=3f+1$.

The way around the lower bound is to use more validators.

2-round BFT in Simplex style gives the clean $n=5f+1$ version. A decision requires $n-f$ votes for one value. A small value certificate has size $n-3f$. If a party sees $n-f$ votes but no small value certificate, that collection proves that no decision certificate formed in the view; it can be used to produce a no commit (skip) certificate for that view.

This is the same Simplex idea with different thresholds. The proposal rule still uses the highest previous value certificate and skip certificates for the intervening views. What changes is the per-view certificate arithmetic.

The two round Simplex post also places the result in the older fast BFT line: FaB Paxos, Kursawe’s optimistic Byzantine agreement, Zyzzyva, and later fixes such as SBFT. It also points to current Simplex like systems, including Minimmit, the Minimmit paper, ChonkyBFT, and Tempo’s Minimmit post.

The next step is to combine the two round and three round paths. Concurrent 2-round and 3-round Simplex-style BFT uses $n=3f+2p+1$. It keeps safety and liveness for $f$ Byzantine faults, gives a three round good case with $f$ Byzantine faults, and gives a two round good case when the execution has at most $p$ Byzantine faults. The key point is to order certificates first by view and then by fast before slow, and to complete each view with both the fast and slow certificates.

The follow-up 2-round BFT in Simplex style for $n=5f-1$ tightens the $5f+1$ threshold to $5f-1$. The trick is to treat leader equivocation as a separate case. If the leader does not equivocate, a special certificate combines votes for $x$ and votes for $\bot$. If the leader does equivocate, parties ignore the leader’s own vote and use only non-leader votes. The same idea extends the concurrent protocol to $n=3f+2p-1$.

Other protocols in this neighborhood include Banyan, Kudzu, Alpenglow, and Hydrangea. They make different choices about fast paths, fallback paths, leader equivocation, data dissemination, and mixed Byzantine and crash faults. The Simplex style posts are useful because they isolate the quorum arithmetic in a very small protocol.

Granular Synchrony

The post Concurrent 2-round and 3-round BFT protocols under granular synchrony belongs with the two round line. It asks how much timing structure is needed to get the $n=3f+2p+1$ numbers when the leader may equivocate.

Under plain partial synchrony, the protocol must sometimes wait for $n-f$ votes to know that a fast commit did not happen. If the leader cannot equivocate, or if granular synchrony bounds how many honest messages can be late to each recipient, then the protocol can wait for fewer votes and still infer that a fast certificate would have appeared. This gives another way to understand the relationship among the Simplex style concurrent protocol, Alpenglow, and Hydrangea.

Fixed View Schedules

The fixed view schedule direction starts with a different question. Modern systems often have good clocks, and fixed view boundaries are operationally attractive. Can Simplex run with predetermined view start times instead of event driven view advancement?

Synchronized Clocks, Fixed View Schedules, and Simultaneous Agreement overviews the advantages and disadvantages of having a fixed view schedule.

Simplex on a Fixed View Schedule shows how Simplex can be put on a fixed view schedule with view length $3\Delta$. A new catch up claim says that after GST, every previous view eventually yields either a value certificate or a skip certificate.

Fast Simplex on a Fixed View Schedule pushes this fixed view schedule line through the two round Simplex certificate structure. It uses $n=5f+1$ and view length $2\Delta$.

Harsh Partial Synchrony and Complex

The post Partial Synchrony variants explains a subtle cost of Simplex. In bounded partial synchrony, messages sent before GST are delayed but eventually arrive by $GST+\Delta$. In unbounded or lossy partial synchrony, old skip certificates may be delayed for an unbounded time or lost. This matters because a Simplex proposal may need skip certificates for many intervening views.

That model distinction connects directly to From Simplex to Complex. Simplex has better worst case view latency than Tendermint, but it may need a growing number of certificates in a proposal. Tendermint keeps certificate state bounded, but pays an extra wait. Complex is the middle point: it keeps the Simplex view latency $3\Delta+\delta$ while requiring only a constant number of certificates per view.

The way Complex does this is to keep the Simplex inner Graded Broadcast and change the outer proposal rule toward a Tendermint style lock rule. A proposal uses a recent lock certificate, and if the lock is not from the immediately previous view, it also includes a skip certificate for the previous view. This turns the long Simplex list of intervening skips into a constant size check.

Reading Map

For the core Simplex path, read:

For background on partial synchrony BFT, read:

For same resilience latency variants, read:

C-Simplex and Kuplex

For two round good case variants, read:

For fixed view schedules, read:

For harsh partial synchrony and certificate growth, read:

For external Simplex and Simplex like resources, see:

Acknowledgments

Thanks to Ling Ren, Kartik Nayak, Tim Roughgarden, Yuval Efron, Gilad Stern, Neil Giridharan, Andrew Lewis-Pye, Joachim Neu, Ertem Nusret Tas, and Alejandro Ranchal-Pedrosa for insightful discussions and feedback across the Simplex series and beyond.

Your thoughts on X.

Tags: consensus