Skip to content

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

  1. A client sends to the nearest replica.
  2. That replica asks a fast quorum to accept the command and its dependencies.
  3. If the quorum disagrees about dependencies, a second round settles the order.
  4. 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.