Simplex, Pipelined
Simplex can now produce blocks as fast as its leader can build them.
Today, we’re introducing Stable Leader and Optimistic Validation, two features that pipeline Simplex views. Stable Leader keeps one proposer for many views in a row, reducing handoff overhead. Optimistic Validation lets that leader keep proposing and validators keep voting without waiting for the previous view’s notarization. Together, they turn Simplex into a high-frequency decentralized sequencer, with several views moving through the network at once. For users, more frequent proposals mean less time waiting for a transaction to enter the next block.
In a global deployment with 50 validators, this Simplex variant sustained 200 blocks per second with 300ms finality to your browser. At 5ms per block, Simplex moves faster than most monitors refresh.
Figure 1: Each square represents one 5ms target interval. Alto sustained 200 blocks per second.
Two Network Waits Between Views
A view is one opportunity for a leader to propose a block. Validators verify the proposal and vote. Once a quorum votes for the same proposal, it is notarized.
Traditionally, two network hops separate consecutive views: the next leader must receive the previous proposal, then votes must cross the network to form its notarization. Within a term, Stable Leader removes the first wait from the critical path. Optimistic Validation removes the second.
Wait One: The Proposer Handoff
With rotating leaders, each view has a new proposer. The next proposer must first receive the previous proposal. Even then, the next proposer cannot safely build until a notarization forms: a Byzantine leader may have sent conflicting proposals.
Stable Leader groups consecutive views into a term, as explored in both Sing a Song of Simplex and Commonware’s Carnot. One leader proposes throughout the term, reducing proposer handoffs from one per view to one per term. Within the term, the leader already knows the previous block and its ancestry before a single network message arrives. An honest leader also knows it did not equivocate, so it can begin building and distributing the next proposal’s data early. This cuts the wait between views from two network hops to one: the hop that forms the parent notarization.
Figure 2: Round-robin spaces views two network hops apart. With four-view terms, Stable Leader spaces them one hop apart within each term and two hops apart at each leader handoff.
Wait Two: The Parent Notarization
Without Optimistic Validation, validators wait for the parent to be notarized before voting to notarize its child. Network latency still paces each view.
With Optimistic Validation, validators can vote to notarize the child as soon as its proposal arrives, provided they already voted for the parent. They do not need to receive the parent’s notarization first.
The child can therefore be proposed and voted on while the parent’s notarization is still forming. The same rule can carry the pipeline across several views within the stable-leader term. Consecutive proposals can begin less than one network round trip apart, limited by local work and network capacity rather than latency alone. These waits for network messages can overlap, but every validator still performs the local verification and application work for each block.
Figure 3: Without optimism, validators wait for the parent notarization before voting in the next view. Optimistic Validation starts three views during the same network interval.
How Optimism Stays Safe
Optimistic means a participant can vote to notarize a proposal before receiving notarizations for every ancestor in the term.
Notarization is not finalization. After a block is notarized, each validator asks its application whether the payload is safe to commit. This decision is called certification and happens before the validator votes to finalize the block. Certification lets an application finish any checks required before commit, such as confirming data availability or validating application-specific block and transaction rules.
A participant only votes optimistically when every earlier proposal in the term is consistent with the chain it has already supported. A validator still waits for the parent to be certified before certifying the child. Once the child is certified, the validator broadcasts its finalize vote. It can certify later views without waiting for the child to finalize, so certification and finalization continue in parallel. If any proposal fails to notarize or certify, later optimistic votes in the term cannot be used. Validators can then vote to abandon the rest of the term through Simplex’s normal nullification path.
The term boundary is also a leader handoff, so optimistic work stops there. The first view of a new term must start from certified ancestry. Together, these rules let Simplex views pipeline without changing the evidence required for finalization.
The consensus configuration also sets a bound on how many views validators can work ahead at once. A value of zero disables Optimistic Validation. A larger bound can keep the pipeline full when notarizations fall behind, at the cost of more CPU and memory for work that could be discarded if an earlier view fails.
Figure 4: When v3 times out, validators nullify it. Later proposals are discarded, and the rest of the term is skipped. In the next term, v9 builds on v2 and the pipeline resumes.
Where the Pipeline Fits
The benchmark used header-only blocks with no transactions or execution, so it measured consensus cadence rather than transaction throughput. The 300ms measurement includes indexer and WebSocket delivery.
Pipelining overlaps network waits, but every validator still performs the verification, execution, and storage required for each block. A higher block rate therefore puts more pressure on validator compute, storage, and network bandwidth. Pipelining does not shorten the time from proposal to finalization, but it does shorten the wait before a transaction can enter the next proposal.
Longer terms reduce handoff overhead but give one leader more consecutive proposals. With 5ms views, a 10,000-view term lasts roughly 50 seconds. If a leader goes offline, nullifying its first stalled view skips the rest of the term and rotates to the next leader. One timeout therefore covers the offline leader’s entire term.
A Byzantine leader could still finalize blocks while selectively censoring transactions. This risk also exists with rotating leaders, but longer terms can increase inclusion delay because the same leader proposes more consecutive blocks. Selective censorship can be difficult to detect when the leader otherwise performs well.
This pipeline fits networks with reliable connectivity and enough CPU and memory for many in-flight views. Networks that prioritize proposer rotation as a censorship defense may prefer shorter terms.
A High-Frequency Decentralized Sequencer
Each 5ms view gives applications another opportunity to order new data. That finer schedule means orderbooks, batchers, and games respond to new input as fast as a traditional web page.
This design maintains a single proposal chain. Within a stable term, the leader knows the parent it is extending, so applications can evaluate stateful transitions against a predictable pending state. Multiple Concurrent Proposer constructions address a different bottleneck. Multimmit lets many producers disseminate transactions in parallel, then derives one order across their chains. The two designs offer different tradeoffs between predictable state and concurrent production.
Stable Leader and Optimistic Validation are part of Simplex
and will be available in the next
commonware-consensus release.