LibraryConsensus1985Design paperCorpus record
Impossibility of Distributed Consensus with One Faulty Process
FLP. Michael J. Fischer, Nancy A. Lynch and Michael S. Paterson.
No deterministic protocol does all three. Any protocol that is always safe has an execution that never decides.
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 designer promises deterministic termination with no timing and one crash, they have claimed to overturn this paper.
The five-minute read
The defect
People wanted a finite protocol that always terminates, tolerates one crash, and never forks, in a network with no clocks.
The rule
No deterministic protocol does all three. Any protocol that is always safe has an execution that never decides.
How it is put together
The result is about deterministic asynchronous consensus. Randomness, clocks, or failure detectors are how later systems step around it. It is not a claim that blockchains cannot exist.
Where the claim stops
Quoting FLP against a partially synchronous protocol is a category error.
One action, walked through
- The proof builds a bivalent state, one that could still decide either way.
- A single message can be delayed to keep the state bivalent.
- A crash of one process is enough to force that delay.
- Is the protocol deterministic?
The argument, unpacked
Why it is still on the desk
If a designer promises deterministic termination with no timing and one crash, they have claimed to overturn this paper.
After the text
Paxos, Raft and PBFT all give up guaranteed termination in the fully asynchronous case. Nakamoto gives up deterministic finality.
What has to be true
- Quoting FLP against a partially synchronous protocol is a category error.
- The paper does not rank coins.
- It does not say liveness is unimportant.
What happened after the paper
Paxos, Raft and PBFT all give up guaranteed termination in the fully asynchronous case. Nakamoto gives up deterministic finality.
What to check before you use the idea
- Is the protocol deterministic?
- Does it assume a bound on message delay?
- What does it do in the execution the proof says never decides?
Terms
- Bivalent
- A state from which both decisions are still possible.
- Asynchronous
- Messages may be delayed arbitrarily.
The problem the paper names
People wanted a finite protocol that always terminates, tolerates one crash, and never forks, in a network with no clocks.
What the design proposes
- The result is about deterministic asynchronous consensus.
- Randomness, clocks, or failure detectors are how later systems step around it.
- It is not a claim that blockchains cannot exist.
How the mechanism is specified
- The proof builds a bivalent state, one that could still decide either way.
- A single message can be delayed to keep the state bivalent.
- A crash of one process is enough to force that delay.
What this page does not treat as proven
- Quoting FLP against a partially synchronous protocol is a category error.
- The paper does not rank coins.
- It does not say liveness is unimportant.
Why a venture studio still reads it
If a designer promises deterministic termination with no timing and one crash, they have claimed to overturn this paper.
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.