Multi-party execution
What is decentralized is execution and testimony, not judgment. The reason: disagreement in opinion carries no information; disagreement in execution does. This path tolerates at most ⌊(k−1)/2⌋ corrupted executors; past a majority, the result flips.
#Why "run each other, don't review each other"
An early design that was abandoned was "decentralized mutual review." Multi-party execution rewrote it as running each other's work instead of reviewing it: what is decentralized is execution and testimony, not judgment.
The reason fits in one sentence:
Disagreement in opinion carries no information; disagreement in execution does.
Acceptance is a deterministic program, so honest executors necessarily get the same result. If a disagreement appears, the only possibilities are that someone didn't really run it, or that someone signed content different from their own execution result — both are attributable faults.
#Three things
- Execute and attest: each executor runs acceptance with its own renderer and sandbox, and signs into its own event chain the hashes of the task, the candidate, the suite and the rendered result, along with the visible acceptance result.
- Tally: first check whether the suite passed the gauge, then verify the testimony one entry at a time. If the same executor signs two testimonies with different content for the same event, that is treated as a proof-grade fault and voided.
- Vote and name: the rest is decided by majority. If the votes fall short of a quorum or tie, the result is undecided, and the shipping rule treats undecided as not passed. The minority is listed by name, with its event hash and signature attached.
#Tolerance limit
⌊ (k − 1) / 2 ⌋When a majority colludes, the result flips: the honest parties get named instead, and the mechanism itself does not know which side of the threshold it is on.
| Sweep batch | False-accusation rate past a majority |
|---|---|
| r446 (371 tasks × 5 candidates) | 0.175 |
| r443 (91 tasks × 5 candidates) | 0.374 |
#Simulation sweep: changing the rule beats adding people
A 200-cell sweep (r446 371 tasks × 5, r443 91 tasks × 5, k ∈ {1, 3, 5, 7}, corruption share 0–70%, five kinds of attack):
| Finding | Figures |
|---|---|
| At a fixed corruption share, as k goes from 1 to 7, the delivery rate does not change at all | Collusion 67.39%, sabotage 0% |
| k=3 / quorum=2, one vote missing | 1-1 tie → undecided, no one named |
#Real runs: R453 and R454
#R453 Cross-machine consistency
| Scale | 368 tasks × 5 candidates = 1,840 candidates |
| Environment | macOS + Linux (k=2) |
| Result | Visible acceptance labels agreed on 1,840 / 1,840 across the two machines; both chains verify |
| Limitation | Windows excluded (the sandbox can't be built) |
#R454 Naming a liar
k=3, with 1 controlled lying key:
| Cell | Result |
|---|---|
| Lying cells that named K3 | 273 / 273 |
| Honest keys falsely accused | 0 / 1,840 |
| Contradictory-signature cells ruled correctly | 58 / 58 |
| Total testimonies | 5,519, with 0 signature-verification failures |
#Fixed point: suite corruption
If the suite is swapped for "passes as soon as it loads," then every vote is honest, every chain verifies, and the system is still delivering garbage.}}
#The limit of the offline viewer
R455 found a structural limit of the single-file offline viewer:
An attacker re-mints the whole chain with their own key, then edits the embedded receipts to match, and it still verifies.
The mitigation is printing the three vacant_ids on a physical label, so that outside the chain there is an anchor that can't be re-minted along with it.
This is not a vulnerability — a signature identifies a key, not a principal. Stating that clearly matters more than fixing it.
#Next
- Details of signatures and the chain: Receipts
- The full results of this line: Records and multi-party execution
