§34: the four-party protocol - killing distributed transactions

docs/architecture/CALCULATIONS.md

@@ -943,3 +943,80 @@ Rules that make it real:
 
 This is Law 48 made executable. The four parties stop being a
 documentation convention and become the shape of memory itself.
+
+## 34. THE FOUR-PARTY PROTOCOL — killing distributed transactions
+
+The claim: 2PC and its descendants (sagas, coordinators, distributed
+locks) exist to answer one question — "did we BOTH do it?" — with
+infrastructure. Four-party records answer it with epistemology.
+
+### Why distributed transactions die
+
+2PC's fatal shape: a COORDINATOR holds LOCKS while asking everyone
+to promise. If any node dies mid-promise, locks stay held and the
+whole system blocks. Sagas avoid blocking by adding compensation
+logic — manual undo for every step. Both pay heavily to fake one
+thing: a single moment when reality flipped from not-done to done.
+
+Four-party records refuse the premise. THERE IS NO SHARED MOMENT.
+Each party commits locally, always, immediately. "Done" is not an
+instant — it is a STATE OF AGREEMENT, reached asynchronously:
+
+    STATES OF AN OPERATION:
+      INTENDED    → recorded locally: {what, why, prior_hash}
+      PERFORMED   → executed; outcome appended w/ before/after hashes
+      PROPOSED    → signed offer sent to counterparty(ies)
+      MUTUAL      → all counterparties countersign (proof-of-possession)
+      WITHDRAWN / AMENDED → supersede record appended, never delete
+
+### The guarantee mapping
+
+    ATOMICITY   → replaced by VISIBILITY RULES:
+                  only MUTUAL records may present themselves as
+                  fact to third parties. Partial work exists as
+                  PROPOSED — real, recorded, but claiming nothing.
+    CONSISTENCY → chain verification at sign time; divergence =
+                  fork = loud alarm (never silent corruption).
+    ISOLATION   → competing proposals to the same object create
+                  rival forks; resolved by deterministic rule
+                  (first-MUTUAL wins) or explicit resolution
+                  record. Loser remains in history, superseded.
+    DURABILITY  → local append-only + §26 fallback cascade.
+
+### Failure analysis — where 2PC dies, this shrugs
+
+    Coordinator dies        → there IS no coordinator. Each party
+                              owns its own ledger; nothing blocks.
+    Counterparty dies       → operation sits PROPOSED: visible,
+                              pending, retryable, amendable. Other
+                              work continues untouched.
+    Party lies              → transcript mismatch = fork alarm;
+                              honest majority out-votes by hash
+                              (the little blockchain, §33).
+    Network partitions      → both sides keep recording truth
+                              locally; on heal, forks surface and
+                              reconcile by signed resolution.
+    "Undo" needed           → AMENDMENT: a forward operation that
+                              references what it corrects. Rollback-
+                              by-deletion is undefined, as designed.
+                              History cannot be unbuilt, only
+                              outgrown.
+
+### Finality = common knowledge
+
+An operation is FINAL exactly when witness-status reaches MUTUAL:
+signed by all parties, hashed into both chains, eligible for seals.
+This is sunrise-finality (§26/§33): not "a coordinator declared it"
+but "everyone knows, and everyone knows everyone knows." No lie can
+be coordinated against finality of this kind.
+
+### Cost, stated honestly
+
+Every operation carries its own receipt-chain: more bytes, more
+hashing, slower absolute throughput than a single-node transaction.
+What you buy: zero coordinators, zero held locks, zero blocked
+systems, total auditability, and recovery that is a property of the
+data rather than a procedure run by operators.
+
+Formal status: protocol sketch complete; state machine above is the
+implementation contract for semantic.ts storage layer (after R1-R3).