LibraryConsensus2013Design paperCorpus record
There Is More Consensus in Egalitarian Parliaments
EPaxos. Iulian Moraru, David G. Andersen and Michael Kaminsky.
Any replica can propose. Commands that do not conflict commit in one round. Commands that conflict take a second round that records the dependency.
A reading of the public document. Not a copy of it, and not a claim about a later network that reused the name.
A blockchain that orders every transaction globally has refused the only win this paper offers.
The five-minute read
The defect
Multi-Paxos sends every command through one leader. Wide-area clients pay that leader's round trip.
The rule
Any replica can propose. Commands that do not conflict commit in one round. Commands that conflict take a second round that records the dependency.
How it is put together
A command carries the dependencies the proposer knew. A fast quorum is larger than a classic majority. Conflict is defined by the application, not by the log index.
Where the claim stops
EPaxos is crash fault tolerant, not Byzantine.
One action, walked through
- A client sends to the nearest replica.
- That replica asks a fast quorum to accept the command and its dependencies.
- If the quorum disagrees about dependencies, a second round settles the order.
- What is a conflict for this state machine?
The argument, unpacked
Why it is still on the desk
A blockchain that orders every transaction globally has refused the only win this paper offers.
After the text
EPaxos influenced later leaderless logs. Public chains mostly kept a total order because smart-contract state conflicts are hard to see in advance.
What has to be true
- EPaxos is crash fault tolerant, not Byzantine.
- The fast path dies if the workload conflicts on every key.
- It assumes replicas can evaluate interference.
What happened after the paper
EPaxos influenced later leaderless logs. Public chains mostly kept a total order because smart-contract state conflicts are hard to see in advance.
What to check before you use the idea
- What is a conflict for this state machine?
- How big is the fast quorum?
- What is the slow path when dependencies disagree?
Terms
- Dependency
- Another command that must be ordered relative to this one.
- Fast quorum
- A larger quorum that lets a command commit in one round.
The problem the paper names
Multi-Paxos sends every command through one leader. Wide-area clients pay that leader's round trip.
What the design proposes
- A command carries the dependencies the proposer knew.
- A fast quorum is larger than a classic majority.
- Conflict is defined by the application, not by the log index.
How the mechanism is specified
- A client sends to the nearest replica.
- That replica asks a fast quorum to accept the command and its dependencies.
- If the quorum disagrees about dependencies, a second round settles the order.
What this page does not treat as proven
- EPaxos is crash fault tolerant, not Byzantine.
- The fast path dies if the workload conflicts on every key.
- It assumes replicas can evaluate interference.
Why a venture studio still reads it
A blockchain that orders every transaction globally has refused the only win this paper offers.
This is Blockchain Lab's reading of a public design paper. It is not the paper, not a copy of it, and not an offer of tokens, equity, custody or a partnership. Later network behaviour can diverge from the text. Nothing here is investment, legal or technical advice.
Research status: Design paper. Last reviewed: 1 October 2026. This is a reading of a public paper, not investment, legal or security advice.
