LibraryConsensus2014Design paperCorpus record
In Search of an Understandable Consensus Algorithm
Raft. Diego Ongaro and John Ousterhout.
A strong leader accepts entries, replicates them in order, and commits only when a majority of the current term has stored them.
A reading of the public document. Not a copy of it, and not a claim about a later network that reused the name.
Most 'our own consensus' pitches are a broken Raft. Ask about the election restriction and the commit rule for entries from an older term.
The five-minute read
The defect
Paxos was correct and routinely mis-implemented. Raft separates leader election, log replication and safety so a reader can see which rule prevents a split brain.
The rule
A strong leader accepts entries, replicates them in order, and commits only when a majority of the current term has stored them.
How it is put together
Terms are numbered epochs. At most one leader per term. A follower rejects a log that does not continue its own. A candidate must have an up-to-date log to win an election.
Where the claim stops
Raft assumes a known set, or an explicit membership change.
One action, walked through
- Heartbeats keep the leader. Their absence starts an election.
- The leader appends a command and waits for a majority of matching stores.
- A new leader forces followers to match its log before taking new commands.
- Can a candidate with a stale log win?
The argument, unpacked
Why it is still on the desk
Most 'our own consensus' pitches are a broken Raft. Ask about the election restriction and the commit rule for entries from an older term.
After the text
etcd, Consul and many orderers ship Raft. A blockchain that needs Byzantine faults has left this paper.
What has to be true
- Raft assumes a known set, or an explicit membership change.
- It is not Byzantine. A malicious leader can lie to clients.
- Randomised timeouts are a liveness trick, not a safety proof.
What happened after the paper
etcd, Consul and many orderers ship Raft. A blockchain that needs Byzantine faults has left this paper.
What to check before you use the idea
- Can a candidate with a stale log win?
- Is commit delayed for entries from previous terms?
- How does membership change avoid two majorities?
Terms
- Term
- A numbered epoch with at most one leader.
- Log matching
- If two logs share an index and term, they share every earlier entry.
The problem the paper names
Paxos was correct and routinely mis-implemented. Raft separates leader election, log replication and safety so a reader can see which rule prevents a split brain.
What the design proposes
- Terms are numbered epochs. At most one leader per term.
- A follower rejects a log that does not continue its own.
- A candidate must have an up-to-date log to win an election.
How the mechanism is specified
- Heartbeats keep the leader. Their absence starts an election.
- The leader appends a command and waits for a majority of matching stores.
- A new leader forces followers to match its log before taking new commands.
What this page does not treat as proven
- Raft assumes a known set, or an explicit membership change.
- It is not Byzantine. A malicious leader can lie to clients.
- Randomised timeouts are a liveness trick, not a safety proof.
Why a venture studio still reads it
Most 'our own consensus' pitches are a broken Raft. Ask about the election restriction and the commit rule for entries from an older term.
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.