Multiple Concurrent Leaders (MCL)

Summary

Multiple Concurrent Leaders (MCL) is a protocol designed by Pranav Garimidi (a16z) that allows multiple simultaneous block proposers to collectively commit to a transaction set, achieving both censorship resistance and transaction hiding. Unlike single-proposer designs where one leader can unilaterally censor or observe transactions, MCL requires an adversary to skip the entire slot to censor a single transaction. The protocol uses hiding erasure-correcting codes — a cryptographic primitive that conceals transaction content from any T-out-of-N subset of relays.

Problem

Single-leader block production has two weaknesses:

Censorship: a single proposer can exclude any transaction from the block without cryptographic recourse. Even with FOCIL, the proposer retains meaningful discretion over ordering.
Transaction visibility: the leader (or co-located parties) can observe transaction content before commitment and extract MEV. Even with encrypted mempools, the eventual decryptor learns content before ordering is finalized.

MCL addresses both simultaneously without requiring a central trusted party.

Protocol Design

MCL runs in four phases per slot. All validators and block proposers participate.

Phase 1: Proposal

Each user with a transaction:

Erasure-codes the transaction into N shares.
Encrypts share i under relay i’s public key.
Broadcasts all N encrypted shares to the relay network.

Each relay i receives and decrypts only its own share.

Key property: with parameters (K, T, N):

Any T shares → zero information about the original transaction
Any K + T shares → full reconstruction of the original transaction
N is the total number of relays; T is the security threshold; K is the reconstruction threshold

Phase 2: Relay Attestation

Each relay i:

Signs an attestation: “I received share i for transaction txid”
Broadcasts the attestation to all validators

Relays do not reveal share content during this phase.

Phase 3: Consensus

A designated leader for this slot:

Collects attestations from relays
Proposes a block of attestations (not a block of transactions): “This slot’s block is defined by the set of attested transaction shares”
Validators run BFT consensus on this block of attestations

The consensus output is a commitment to which transactions are in the block — before any transaction content is known.

Phase 4: Reconstruction

After consensus finalizes:

All relays broadcast their shares openly
Anyone with K + T shares can reconstruct each transaction
The block is executed in reconstruction order

Cryptographic Foundation: Hiding Erasure-Correcting Codes

Standard erasure codes (Reed-Solomon) allow reconstruction from K of N shares but reveal partial information from fewer shares.

Hiding erasure-correcting codes solve this: parameterized by (K, T, N):

The encoder adds T “random” shares (noise) to the K information shares
Any subset of T shares is statistically indistinguishable from random — zero information
Any K + T shares allow perfect reconstruction via Gaussian elimination over a finite field

Concretely: K=1 (one transaction), T=3 (hide from up to 3 relays), N=10 (total relays) → any 3 relays learn nothing; any 4 reconstruct.

This is a stronger primitive than secret sharing (Shamir): secret sharing reveals nothing until reconstruction threshold, but also requires a trusted dealer. Hiding erasure codes can be applied by the user directly.

Security Properties

Censorship Resistance

Theorem: to censor a transaction, an adversary controlling fewer than N/5 relays must skip the entire slot.

Proof sketch:

The transaction enters the block as soon as one honest relay attests to its share.
An adversary controlling fewer than N/5 relays has fewer than T shares (by parameter choice T ≥ N/5) → cannot reconstruct the transaction and thus cannot prove the transaction is invalid.
To exclude the transaction from the attestation set, the adversary must control a majority of the consensus round — which requires >50% of validators.
Therefore, to censor while controlling <50% of validators, the adversary’s only option is to force a missed slot.

This is strictly stronger than FOCIL’s 1-out-of-N honesty assumption. MCL requires the censor to disrupt the entire slot, not just overpower one inclusion list committee member.

Transaction Hiding

Theorem: an adversary controlling fewer than T relays learns nothing about a transaction’s content until Phase 4 (post-consensus reconstruction).

Proof sketch:

In Phase 1, each relay sees only its encrypted share.
In Phase 2, relay attestations contain only txid (a hash commitment), not content.
The adversary’s view is T ciphertext shares → by the hiding property, statistically indistinguishable from T random values.

Byzantine Threshold

The protocol is secure against Byzantine failures with threshold N/5:

Up to N/5 Byzantine relays → both censorship resistance and hiding hold
Above N/5 Byzantine relays → hiding may be compromised (T shares no longer sufficient)

Setting T = N/5 and K = 4N/5 gives the recommended parameter configuration.

MCL vs. FOCIL

Property	FOCIL	MCL
Censorship resistance	1-of-17 honest needed	Must skip whole slot
Transaction hiding	No (builders see content)	Yes (until Phase 4)
Protocol changes	EIP-7805 (Hegotá)	Full protocol redesign
Complexity	Low	High
Byzantine threshold	N/17 honest	N/5 honest
Current status	Planned for Hegotá (H2 2026)	Research/prototype

MCL subsumes FOCIL’s censorship resistance guarantee and adds transaction hiding. The cost is significantly higher protocol complexity.

Connection to Geographic Decentralization

MCL’s censorship resistance relies on relay diversity: an adversary needs to control enough relays to reconstruct transactions (and then selectively censor). Geographically distributed relays in different legal jurisdictions make coordinated censorship much harder.

From the Cannes MEV-SBC geographic decentralization panel:

TEEs reduce communication rounds → reduce co-location incentive
MCL provides a cryptographic layer on top of this: even if relays are monitored, their shares reveal nothing individually
Convergent with MCL: dev sharding, sub-slots, and rollups all trend toward local-finality + global-settlement hierarchies

Relationship to Encrypted Mempools

MCL and LUCID address overlapping but distinct problems:

LUCID: hides transaction content from builders during block construction; uses threshold decryption post-ordering
MCL: hides transaction content from proposers during ordering; uses hiding erasure codes

They could be combined: use MCL for censorship-resistant ordering, then LUCID for pre-execution privacy during builder execution. The open question is whether the latency overhead is compatible with Ethereum’s 12-second slot.

Open Questions

❓ Can MCL be deployed without a full protocol redesign, e.g., as a relay-layer protocol on top of MEV-Boost?

❓ What are the concrete network assumptions required for Phase 3 (BFT consensus) to work within a single Ethereum slot?

❓ How do hiding erasure codes interact with transaction validity checks? Relays attest to having a share without knowing the transaction is valid.

❓ What is the latency overhead of the 4-phase protocol compared to today’s MEV-Boost single-phase submission?

Timeline

2025-08-08 — MCL presented by Pranav Garimidi (a16z) at MEV-SBC 2025