jonnify·echd /echd/overview/impossibility/the-proof-in-two-writes

echd — Echo on Encore · E0.2 · dive

The Proof in Two Writes

Partition the servers, lose the messages, write two different values — and from the far side the two histories are one world. The whole theorem is that collapse.

Vision · real substrate

echd speaks in the present tense over a build ladder. Every module, verb, key, and port named on this page is real; the composition into one standing platform is the vision the ladder builds.

§1

The dive

echd.course.md §2 · Gilbert & Lynch (2002)

The proof fits in a paragraph. Partition the servers into {p1} and {p2 … pn} and lose every message between the halves. In execution A, a client writes v1 to p1 and p1 acknowledges. In execution B, the client writes v2 instead, and again p1 acknowledges — both are legitimate histories of a correct register. Now a client reads from p2. Here is the trap: from p2's side of the cut, execution A and execution B are byte-for-byte identical — the only thing that differs, the write to p1, is on the far side of the partition and nothing about it ever arrives. No amount of waiting resolves the two worlds into one, because the information that would distinguish them cannot cross.

So p2 has exactly two exits, and they point opposite ways. Wait forever and the register stays consistent but is no longer available — the liveness break. Answer, and it is available but may return v1 when the true value is v2 — the safety break. That is the entire theorem: one register, one cut, one forced choice. And the obvious escape — "only give up consistency during a real partition" — is closed by the sharper reading: under asynchrony, a message delayed long enough is indistinguishable from one lost forever, so p2 can never be sure whether it is partitioned or merely waiting on a slow link. The dilemma arrives even on a network that never actually parts.

§2

The two writes

hover a step
Two writes, one cut, one read · the whole proof, collapsed · hover to read
two writes, one cut, one indistinguishable read execution A write v1 · p1 acks ok execution B write v2 · p1 acks ok the cut — or a slow message p2 reads A ≡ B from here wait → no liveness answer → no safety one register is enough — everything richer inherits the bill
Two writes — the setup. Execution A writes v1 to p1 and is acknowledged; execution B writes v2. Both are legal histories of a correct register, and only p1's side of the cut knows which one actually happened.
The cut — and its ghost. Every message between the halves is lost. The sharper clause: with no bound on delivery, a sufficiently late message is indistinguishable from a lost one — so the same dilemma arrives on a network that never parts. Delay is a partition you cannot rule out.
The read — indistinguishability. A client asks p2 for the register. From p2's side, execution A and execution B are the same world down to the byte; the fact that would tell them apart is on the far side of the cut, and no wait brings it across.
The choice — the only two exits. Wait forever and the register is consistent but not available; answer and it is available but possibly wrong. There is no third door: the theorem is exactly the observation that these two are all a partition leaves.

Hover or focus a step to read it; click to pin. Without scripting, all four read in sequence.

§3

The asynchrony clause

echd.course.md §2 — the closed escape hatch

The tempting design is a system that is consistent while connected and only inconsistent while genuinely partitioned — pay the CAP bill exactly when the network fails, never otherwise. The asynchrony clause is what makes that impossible to build, and it turns on a single missing quantity: a bound on delivery. On a synchronous network — every message delivered within a fixed, known time — p2 could wait out the bound and, hearing nothing, correctly conclude no write reached it. Remove the bound, as every real wide-area network does, and that inference dies: any silence might only need a little longer. p2 cannot decide, from the inside, whether it is partitioned or slow, so it cannot restrict its risk to "real" partitions. Consistency cannot even be guaranteed conditionally.

This is precisely why the platform never writes code that asks "are we partitioned?" — the question is undecidable at the point it would be asked. Instead every tier is handed a stance that is correct without the answer: the ledger blocks under conflict because blocking is safe whether or not a partition is real; the cache answers from last-known because answering is available whether or not the link is merely slow. The proof's ghost — delay wearing a partition's mask — is not an edge case the platform patches; it is the reason each tier's trade is chosen once, in advance, and never made to depend on a network fact no server can observe.

§4

The rule

one line to carry

The indistinguishability rule — when two executions look identical from where you stand, no protocol can answer both correctly: wait and lose liveness, or answer and risk safety. And because a slow enough message draws the same cut a partition would, the choice is forced even when the network never breaks — so a correct tier chooses its side in advance, never asking a question no server can answer.

§5

Doors

the proof, deeper
§6

References

sources · related

Sources

Related