LibraryConsensus2014Design paperCorpus record
Consensus: Bridging Theory and Practice
Raft membership. Diego Ongaro.
Membership changes one server at a time, or through joint consensus, so there is never a moment when two disjoint majorities can both commit.
A reading of the public document. Not a copy of it, and not a claim about a later network that reused the name.
If a cluster can be grown by editing a config file and restarting, it is not this procedure.
The five-minute read
The defect
The Raft paper left membership change as a sketch. Changing who is in the majority while a log is live is where implementations fork the brain.
The rule
Membership changes one server at a time, or through joint consensus, so there is never a moment when two disjoint majorities can both commit.
How it is put together
A cold server does not vote until it has caught up. Joint consensus overlaps the old set and the new set. Leadership and membership are different decisions.
Where the claim stops
The dissertation is the careful version. Blog posts often skip the overlap.
One action, walked through
- Add or remove one voter.
- Commit the configuration entry under the rules of the overlapping sets.
- Only then start using the new majority alone.
- Can two configurations both hold a majority at once?
The argument, unpacked
Why it is still on the desk
If a cluster can be grown by editing a config file and restarting, it is not this procedure.
After the text
etcd and Consul spent years on this chapter. The bugs were in membership, not in the log-matching property everyone quotes.
What has to be true
- The dissertation is the careful version. Blog posts often skip the overlap.
- It is still crash fault tolerance, not Byzantine.
- A chain that restakes every epoch is a different membership protocol.
What happened after the paper
etcd and Consul spent years on this chapter. The bugs were in membership, not in the log-matching property everyone quotes.
What to check before you use the idea
- Can two configurations both hold a majority at once?
- Does a new server vote before it has the log?
- Is the configuration itself a log entry?
Terms
- Joint consensus
- A majority that must include both the old set and the new set.
- Configuration entry
- A log entry whose payload is the set of voters.
The problem the paper names
The Raft paper left membership change as a sketch. Changing who is in the majority while a log is live is where implementations fork the brain.
What the design proposes
- A cold server does not vote until it has caught up.
- Joint consensus overlaps the old set and the new set.
- Leadership and membership are different decisions.
How the mechanism is specified
- Add or remove one voter.
- Commit the configuration entry under the rules of the overlapping sets.
- Only then start using the new majority alone.
What this page does not treat as proven
- The dissertation is the careful version. Blog posts often skip the overlap.
- It is still crash fault tolerance, not Byzantine.
- A chain that restakes every epoch is a different membership protocol.
Why a venture studio still reads it
If a cluster can be grown by editing a config file and restarting, it is not this procedure.
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.