· 記録と多者実行 · 成立
嘘をつく鍵は 273 回すべて名指しされ、誠実な側の誣告は 0 回
k=3、制御下にある嘘をつく鍵が 1 本、証言 5,519 件。嘘のセルの名指しは 273/273、誠実な鍵の誣告は 0/1,840、矛盾した署名のセルの判定は 58/58 で正解でした。この数字がどれほど厳しいかは、⌊(k−1)/2⌋ という数学的な上限を知っているかどうかで決まります。
多者実行名指しEd25519レシートチェーン
#三つのこと
- 実行と署名：各実行者は自分のレンダラーとサンドボックスで受け入れ検査を実行し、タスク、候補、スイート、レンダリング結果のハッシュと、可視の受け入れ結果を、自分のイベントチェーンに署名して書き込みます。
- 票の集約：まずスイートがゲージを通るかを検査し、次に証言を一件ずつ検証します。同じ実行者が同じイベントについて内容の異なる二つの証言に署名した → 証明レベルの過失として無効にします。
- 表決と名指し：多数決で決めます。票数が定足数に満たないか同数 → 未決で、出荷規則は未決を不合格として扱います。少数側は、イベントハッシュと署名を添えて名前を挙げて列記されます。
#R454 の結果
k = 3、制御下にある嘘をつく鍵が 1 本（K3）：
| 検査 | 結果 |
|---|
| 嘘のセルが K3 を名指し | 273 / 273 |
| 誠実な鍵が誣告される | 0 / 1,840 |
| 矛盾した署名のセルで判定が正しい | 58 / 58 |
| 証言の総数 | 5,519 件 |
| 署名検証の失敗 | 0 |
#マシン間の一致（R453）
| |
|---|
| 規模 | 368 タスク × 5 候補 = 1,840 個の候補 |
| 環境 | macOS + Linux（k = 2） |
| 可視の受け入れラベルの一致 | 1,840 / 1,840 |
| レシートチェーン | 二本とも検証を通る |
| Windows | 除外（サンドボックスを構築できない） |
#シミュレーションのスキャン：直感に反する二つの結果
200 セル（r446 371 問 × 5 候補、r443 91 問 × 5、k ∈ {1,3,5,7}、腐敗比率 0–70%、五種類の攻撃）：
#① マシンを増やしても何も買えない
| 条件 | 納品率 |
|---|
| 腐敗比率を固定して、k を 1 から 7 に | 一字も変わらない |
| 共謀 | 67.39% |
| 破壊 | 0% |
#② k = 3 で一票欠けると名指ししない
| |
|---|
| k = 3、定足数 = 2、一票が欠席または提出拒否 | 1-1 の同数 → 未決、名指ししない |
これは意図的な設計上の選択です。その意味はこうです。
名指しが前提とするのは「誠実な多数がその場にいること」であって、「署名が存在すること」ではない。
#数学的な上限
容忍上限 = ⌊ (k − 1) / 2 ⌋
過半数が共謀すると結果は反転し、誠実な側が名指しされます。しかも仕組み自体は、自分が閾値のどちら側にいるかを知りません。
| スキャンのバッチ | 過半数を超えた後の誣告率 |
|---|
| r446（371 問 × 5） | 0.175 |
| r443（91 問 × 5） | 0.374 |
#この仕組みが解決できないこと
受け入れスイートそのものの腐敗です。 スイートが「読み込めば合格」に差し替えられたら：
どの票も誠実で、どのチェーンも検証を通り、それでもシステムはごみを納品し続ける。
| 段階 | 結果 |
|---|
| スイートを commit に結びつける、平凡なスイート | 371 / 371 すべて拒否（正常） |
| 状態を持つゲージの変種 | 納品率が 75.20 pp 下がり、ゲージは ok を報告 |
| 修正：SuiteSpec | exec の密輸 368 / 371 → 0 / 371 |
| 残余：generic_gauged | +2.72 pp |
| 上限：weak_oracle | +4.35 pp |
直し方は審判を替えることで、実行者を増やすことではない
#誠実な限界
