Multimmit: The Best of Both Worlds
For users, the only blockchain speed that matters is the time from submitting a transaction to seeing it finalize.
In a “traditional” leader-based protocol, this means sending a transaction to an API, the API sending that transaction to the leader (wherever it may be in the world), and then landing in a finalized block (unless you just missed the leader’s proposal and land in the next one). The throughput of all of this is bound by the leader’s egress (which bounds the rate they can push their block, erasure coded or not, to other validators).
Decoupling transaction dissemination from consensus removes the scale bottleneck (at least). Instead of one leader sequencing all transaction data, many independent producers each sequence and stream their own chain of transaction blocks in parallel. Consensus then orders small references from those chains into one log (or uses the broadcast directly as consensus in a DAG).
However, decoupling often increases the latency of finality (the number we just said is the only thing users care about). Consensus cannot finalize a reference to data that the network cannot recover. Existing protocols either certify each block before it can be referenced or reference blocks immediately. The first approach adds certificate round trips to every transaction. The second is faster until data is missing, at which point voters must fetch it or the protocol finalizes only the prefix before the gap.
Today, we’re revealing Multimmit, a construction that avoids both delays. Producers (validators and optionally API nodes) each build their own chain of transaction blocks. Consensus references these blocks as soon as they arrive, and votes already being cast establish availability. No block waits for a certificate, no voter waits to fetch missing data, and a withheld block delays finality only on a producer’s own chain. Votes can also include blocks the leader missed (or censored), allowing blocks from every producer chain to enter the finalized log in each view.
With Multimmit, a block from any honest producer chain can finalize 2\delta after broadcast, even when up to f non-leader producers are faulty (assuming n \geq 5f+1). Two message delays is the theoretical minimum for fault-tolerant consensus. Existing protocols, including DAG protocols such as BlueBottle, reach it only for designated leaders (or anchors), and everything else waits for a later one. Multimmit extends it to every honest producer chain at once without giving up concurrent dissemination: the best of both worlds.
The Ride to the Leader
Consider a typical consensus protocol with one proposer at a time and Simplex-style notarize and finalize rounds. A transaction travels from the user to an API node, is forwarded to a leader that is ready to propose, and is broadcast in the leader’s block.
Figure 1: A transaction’s path through a single-proposer protocol, measured in message delays (\delta) since submission. Figures 1, 3, 5, and 6 use the same axis and omit the wait for the next proposal or producer block, which Figure 2 draws. Here, the transaction reaches the leader just as it is ready to propose.
From the “block” marker (when the leader’s block is broadcast), finality takes two rounds of voting (or one round when n \geq 5f+1). The user’s clock, however, started at submission. The transaction spends \delta reaching an API node and another \delta reaching the leader, where Figure 1 had it arrive exactly as the next block went out.
Blocks are emitted when the leader is ready to propose, so the same two hops can just as easily land the moment after one, leaving the transaction to wait out the rest of the interval: as long as 2\delta, and \delta on average (a shorter interval between blocks shrinks both numbers, which is why Minimmit optimizes for view latency).
Figure 2: The same inbound hops as Figure 1, drawn on the same axis, for two submissions. Transaction A is Figure 1’s: it reaches the leader exactly as a block goes out. Transaction B spends the same 2\delta on the wire but lands just after a block and waits almost the full interval for the next one. Nothing about the network changed. Only where the submission fell in the leader’s schedule.
Removing the Leader Bottleneck
Autobahn removes the leader’s egress bottleneck. Every producer builds its own lane of transaction batches and streams each batch to all validators as it is produced, so transaction data crosses the network only once. The leader still proposes a block, but it now contains references to lane tips instead of transactions. When the leader block finalizes, so does everything below those tips.
The node accepting a transaction is also a producer, so submission begins dissemination immediately. Lanes continue growing during failed consensus views, and the first successful proposal commits the accumulated backlog. Autobahn calls this property seamlessness.
The catch is that a leader may only reference a certified tip. Validators return data-availability votes (DA-votes) to the producer, the producer aggregates them into a proof of availability (PoA), and the PoA must reach the leader before its next proposal. Certification guarantees that a referenced batch can be recovered, but it adds three message delays between dissemination and the earliest possible proposal (plus any wait for that proposal). Sending DA-votes to every validator would save one delay by allowing the leader to assemble the PoA, but would require cubic communication per height of lane growth (n voters sending to n validators for each of n lanes).
Figure 3: Producer lanes with certified tips, using the same Simplex-style two-round consensus as Figure 1. Like Autobahn’s fast path, finality takes three message delays after the proposal. The transaction batch (green) crosses the network once. Its PoA arrives two message delays after the batch does, after which the leader’s block may reference it. The leader block remains red but now contains only references.
Why not reference blocks before they are certified? Autobahn suggests exactly that for lanes that have historically been reliable, at the cost of seamlessness: a voter that does not hold the tip holds off and fetches it from the leader. Raptr instead avoids the certificate round trip by having voters signal the longest prefix of a proposal for which they hold data. The protocol then finalizes the prefix supported by a quorum.
One missing batch, however, spoils everything after it. Even if all later batches are available, they cannot finalize. By taking turns, k faulty producers can deny the fast path for k consecutive proposals. Raptr uses reputation to limit this attack. Voters blame the authors of missing batches, and a producer blamed by f+1 validators is restricted to certified references. This only helps after the producer has spoiled a proposal. Any policy that eventually readmits slow-but-honest producers also gives a faulty producer another chance to spoil.
Figure 4: Easy spoiling. A Raptr leader block carries one sequence of batches from many producers, and each voter supports the longest prefix whose data it holds. When P2 withholds its batch, almost every vote stops at the gap. The proposal finalizes prefix 1 even though the batches from P3 through P6 are available. These batches eventually land through the certified slow path. Multimmit votes (Figure 7) report a position for each chain, so a withheld block only lowers the position reported for its own chain.
Mysticeti makes the same tradeoff for a DAG by referencing uncertified vertices. Dropping just 1% of egress traffic at 5 of 100 validators has been observed to increase its median latency by an order of magnitude at moderate load. DAG deployments use reputation for the same reason and have scored anchors (their leader equivalents) since Shoal. We return to DAGs below.
Erasure coding takes a different approach: keep the leader on the data path, but send each validator a smaller fragment of each block. A stable leader can then pipeline proposals without gaps between them. Together, these techniques let a leader-based protocol approach line-rate throughput. The tradeoff is that every transaction must still reach that leader before dissemination begins, and the leader can censor transactions throughout its tenure. We explain the coding in Deliver Us in Pieces and establish its limits in The Carnot Bound.
Multimmit: Checkpoint First, Certify in the Background
Multimmit keeps producer lanes, each a chain as in Autobahn. Every producer signs its own sequence of transaction blocks, with each block referencing its parent by hash. DA-votes and PoAs still form for every block, as in Figure 3, but consensus does not wait for them. A producer may run up to d blocks ahead of its last certified block, leaving a short uncertified tail while everything below it remains recoverable.
Multimmit is designed around one rule: a faulty participant other than the leader should only be able to significantly delay the finalization of blocks in its own chain. Its votes have two parts, proposal-relative positions and extensions.
Proposal-relative voting. The leader checkpoints one tip for every chain, whether it is certified or not. Each reference costs one hash. A validator does not fetch missing blocks. Its vote reports how far it can support each chain in the proposal (the blocks it holds and has DA-voted). A chain finalizes through the highest position supported by 3f+1 votes, and the next leader must extend the highest position supported by f+1 votes. If a producer withholds a block, only its own reported position falls. Other chains do not wait or fetch, and the proposal is not spoiled. Supporting every proposed tip takes constant space. Lower positions are encoded only as deviations from full support.
Figure 5: Transaction block b (green, like the batch in Figure 3) reaches the leader before its proposal and is checkpointed before a PoA forms. Minimmit’s single voting round finalizes b 3\delta after its broadcast. DA-votes and the PoA (faint arrows) form in the background. The dashed markers show the finality times from Figures 1 and 3. No transaction data passes through the leader.
Extension votes. A vote may also attest to as many as e fresh blocks beyond the proposed tip on each chain, anchored at the voter’s reported position for that chain. A block that misses the leader’s proposal (or is censored) can still finalize in the same view if it reaches voters before they vote. A faulty participant can fill a proposal or vote with junk or stale entries, but each extension is anchored at its own voter’s reported position, so correct voters can always attach recent blocks. A leader cannot finalize its own block while excluding a well-disseminated honest block. It must settle that block’s membership in the ledger or prevent the entire view from finalizing.
Figure 6: Transaction block b crosses the leader block on the wire and misses the proposal, but reaches validators before they vote. Extension votes attest b directly, finalizing it 2\delta after its broadcast. Certification continues in the background (faint arrows) and finishes after b has already finalized.
From the user’s perspective, both paths are simple: submit to an API node (a producer with no weight in consensus), let its next block carry the transaction to every validator, and wait one round of votes for finality. The producer can pre-confirm the transaction as soon as it arrives, potentially before it could reach a leader an ocean away. Nothing needs to reach the leader before dissemination begins. Including the wait for the next vote event, a block sent at time t finalizes at t+3\delta in expectation, and at t+2\delta with favorable timing (broadcast concurrently with the leader’s block). Raptr, measured the same way, takes 5\delta.
How does one round of votes produce a single ordering? Each Multimmit vote carries an independent position for every chain. Voters do not vote on how blocks from different chains are interleaved. That ordering is computed afterwards from the finalized tips, which prevents a gap in one chain from limiting any other chain’s finalization.
An L-QC (a quorum certificate on the leader block) aggregates any n-f votes for it. For each chain, sort the positions reported by those votes. Discarding the top 3f positions gives the finalized tip. Discarding only the top f gives the tip that the next leader must extend. Those rules cover the proposed positions. An extension finalizes in the same view only when its chain’s position result is the proposed tip and every vote in the L-QC attests it, which the good case delivers. Quorum intersection ensures that the extend tip derived from any L-QC is at least as high as the tip finalized by any other L-QC for the same view. After applying these rules independently to every chain, the finalized blocks enter the log in a fixed sweep.
Figure 7: Converting votes into an ordering at n=11, f=2. The leader block (left) contains one coordinate for each producer chain. Chain 1 is expanded below it, from the previous tip 1A through proposed blocks 1B-1E. An L-QC contains n-f=9 votes, each reporting its highest supported block on every chain. Dropping the top 3f=6 positions finalizes 1D (gold) with 3f+1=7 votes. Voters missing newer chain 1 blocks lower only this result. Dropping the top f=2 positions gives the safe-to-extend tip 1E (blue), which prevents the next leader from orphaning 1D. These rules run independently for every chain. The resulting tips enter the log (right) in a fixed sweep, with each chain’s first new block ordered before any chain’s second. Gray cells were ordered previously.
At n=5f+1, these thresholds provide three other properties:
- A faulty producer can withhold blocks, equivocate, or disclose blocks selectively, but any resulting delay is confined to its own chain (other chains wait at most one view for their position in the total ordering).
- A leader cannot finalize its own block while censoring someone else’s. If a fresh honest block reaches the honest validators before they vote, its membership in the ledger is settled in that view unless the view finalizes nothing.
- Consensus messages stay tens of kilobytes per view when votes agree, independent of transaction volume.
Why Not a DAG?
DAG-based protocols (Narwhal, Bullshark, Mysticeti) popularized the idea of having every validator disseminate transactions in parallel. The costs of this approach motivated designs like Autobahn and Raptr. In a DAG, the transaction-carrying structure is also the consensus structure. Every validator’s vertex carries transactions and references n-f vertices from the previous round. Consensus determines finality by interpreting this pattern of references.
Figure 8: How a DAG mempool is built. Each round, every validator emits a vertex referencing n-f vertices of the previous round. The references are the protocol: they carry availability and voting information, so the ordering logic can read finality out of the lattice.
A reference does not provide finality on its own. The ordering logic designates periodic anchor vertices, and an anchor commits only after later rounds show that enough validators built on top of it. Committing the anchor orders every vertex in its causal history. The remaining vertices wait for a later anchor. Some DAGs add a fast path around this: Mysticeti finalizes transactions that touch only single-owner state by reliable broadcast, without waiting for an anchor, though their position in the total ordering still waits for one.
Figure 9: Finality in a Mysticeti-style three-round pattern. Anchor A enters in round r, gathers support (gold references) in r+1, and commits when round r+2 arrives. Its causal history (gold) is ordered with it. In a certified DAG, each round also requires a certificate round trip.
This coupling also controls production. A validator may only create a round-r+1 vertex after receiving n-f round-r vertices, so the network produces in lockstep (deployments add round timeouts to keep the DAG well connected). In certified DAGs like Narwhal, a certificate round trip separates each pair of consecutive vertices. Uncertified DAGs like Mysticeti remove that round trip but reintroduce fetching. Because every referenced vertex is a dependency, a validator must fetch a missing vertex before it can process anything built on top of it.
Figure 10: The fetch problem. Validator 3 sends its round-(r+1) vertex only to validator 2, whose next vertex references it (red edge). Validators 1 and 4 cannot use validator 2’s vertex without its full ancestry, leaving them with only two of the n-f=3 round-(r+2) vertices needed to enter round r+3. They must fetch the withheld vertex first, delaying the next round for everyone. Larger DAGs can route around an isolated gap, but each gap still puts a fetch on someone’s critical path. At real block rates, sustained loss creates gaps in nearly every round (producing the order-of-magnitude slowdown measured above). A Multimmit reference never puts a fetch on a critical path. Voters report how far they can support each chain and vote on schedule.
The coupling also fixes who may produce. A vertex is a vote, so contributing transaction data means being a validator. Multimmit keeps the two structures apart, and a transaction block is never itself the subject of a consensus vote, so a producer does not have to be a validator and a deployment can run a different number of chains than it has voters.
Whether the protocol waits for fetches or certificates, a collective step limits every producer’s output. Figure 11 compares that pace with a Multimmit producer paying the same certificate round trips.
Figure 11: One producer with identical 2\delta certificate round trips. The DAG producer waits for the previous round’s certificates before creating its next vertex (assuming every other producer’s certificate arrives with its votes, since spreading them costs a certified DAG a third delay per round). The Multimmit producer runs as many as d blocks ahead of certification, shown here filling a d=3 window under load.
Figure 2 showed the cost of coupling production to consensus: a transaction that misses a proposal waits for the next one, \delta on average when blocks leave every 2\delta. Multimmit separates block production from that schedule. Each producer controls when a transaction enters its own block, and its chain contains no cross-producer references, so it can run as many as d blocks ahead of certification. Under sustained load, a chain grows by d blocks per certificate round trip instead of one, cutting that wait to \delta/d. Producers keep building through leader failures and view changes, and the first successful view checkpoints the backlog.
Figure 12: Two consensus views time out in the shaded interval. The producer keeps emitting blocks and forming certificates without the leader. The first successful view carries the backlog, and one round of votes finalizes it. Blocks emitted after that proposal wait for the next view.
Every Producer, Every View
Multimmit runs transaction dissemination and consensus concurrently. Blocks enter the ordering process as soon as they reach validators, consensus votes establish their availability, and a faulty producer only delays its own chain. Submit a transaction to any producer. One round of votes later, it is final.
Check out the (draft) specification for proofs of consistency and liveness. Follow GitHub for an MIT/Apache-2 implementation over the coming weeks.