レッスン9 — バリデータ経済（slashing、報酬、攻撃ベクター）

問い

暗号だけでは PoS chain を守れない。バリデータが double-sign したことを証明することはできる — だが、バリデータがそれに対して何の代償も払わないなら、その証明は無価値だ。不正のコストが不正によって引き出せる現金を上回って初めてプロトコルは安全になる。これがなければ、優雅な 3f+1 quorum の数学は「double-sign しないでください、お願いします」へと崩れ落ちる。

原理（最小モデル）

セキュリティ条件 = 必要 stake > 抽出可能価値. 攻撃コスト > 攻撃利益。Ethereum 例: 約 330 億ドルの stake 必要 + slashing で全額焼失 → 経済的に非合理。
2 違反 = double-signing + surround voting. どちらも 暗号的に証明可能（署名 2 つあれば proof）。oracle 不要、パーミッションレス検出。
相関 slashing. 同じ window 内で何人が slash されたかに比例して罰則を上げる。1 人だけなら 1 ETH、33% 協調攻撃なら full stake = 壊滅的。
Inactivity leak が 1/3+ 攻撃を救う. stake の 35% が投票拒否 → finality 停止 + ~13 日後に非参加 stake が徐々に焼かれる → 参加 stake が 2/3+ に戻る → finality 再開。

具体例

Double-signing（equivocation）:

バリデータ V が Vote(block_A, round_5) に署名
バリデータ V が Vote(block_B, round_5) に署名

両方とも同じラウンドで V によって署名。暗号的に証明可能 — 2 つの署名を持つ者なら誰でも slashing proof を構築できる。

Surround voting:

バリデータ V が Vote(source: epoch_3, target: epoch_5) に署名
バリデータ V が Vote(source: epoch_4, target: epoch_6) に署名

2 つ目の票が 1 つ目を surround している（より後ろの source、より後ろの target）。Casper FFG では特に safety 違反。

Slashing proof 提出フロー:

sequenceDiagram
    participant Watcher as Slashing Watcher
    participant Chain as Reth EL
    participant State as State

    Watcher->>Watcher: V からの 2 つの署名済み票を観測
    Watcher->>Watcher: 両方の署名を検証
    Watcher->>Chain: SlashTransaction(vote_a, vote_b)
    Chain->>State: on-chain で proof を検証
    State->>State: V の stake を slash
    State->>Watcher: 内部告発者報酬を支払う (小さな割合)

相関 slashing 公式:

slash_amount = (slashed_stake / total_stake) * stake * multiplier

slashed_stake は直近 window 内で slash された全バリデータの stake。1 バリデータ単独 → 罰則小。バリデータの 33% が同時に slash → 壊滅的（全 stake）。

攻撃ベクター:

攻撃	効果	防御
Double-sign	同じ高さで 2 ブロックに署名し fork choice を混乱	Slashing
Surround vote	矛盾する 2 つの checkpoint を finalize に投票	Slashing
Long-range attack	古い期間のバリデータを買収して履歴を書き換え	弱い主観性（クライアントは最近の状態を信頼）
2/3 finality attack	stake の 2/3+ を握り全部で署名	ETH 換算で >330 億ドル、不可能
Liveness attack	stake の 1/3+ で投票拒否	chain 停止、safety は維持

失敗例（誤解）

「Slashing は懲罰」— 間違い。Slashing は 経済的セキュリティ。攻撃者は stake を取得（数百万 ETH）→ それを失う必要 → 攻撃コスト > 抽出可能価値 → 経済的に非合理。Stake がセキュリティの担保。

「Long-range attack は slashing で防げる」— 間違い。古いバリデータは引退済み = stake はすでに取り戻せる場所にある。Slashing で防げない。代わりに 弱い主観性（new client は信頼できる checkpoint から同期、古い chain は無視）で防ぐ。

🛑 予測。 Ethereum mainnet には約 500 億ドル以上がステークされている。finality に対する 2/3 攻撃を試みる際の、ドル単位のコストは？（答え: stake の 2/3+ が必要 = ~330 億ドル分の ETH を取得。slashing で 最大で全損級の損失 が発生しうる（条件依存）。これが PoS のセキュリティ議論。経済的に非合理 → 攻撃者が存在しにくい。）

ステップで組み立てる

Step 1: セキュリティ条件を 1 行で

必要 stake > 抽出可能価値。

Step 2: 2 違反 + slashing 公式

Double-sign: 同 epoch で 2 checkpoint に署名
Surround vote: 1 つ目を「囲む」票を 2 つ目に署名

slash = (slashed/total) × stake × multiplier の相関設計が協調攻撃を経済的に潰す。

Step 3: 3 つの提出条件

検出はパーミッションレス — 監視している人なら誰でも proof 提出可能
検証は暗号的 — chain が 2 つの署名を検証、oracle 不要
報酬は小さい — 監視のインセンティブには十分だが、虚偽報告を誘発するほどは大きくない

Step 4: 5 攻撃ベクターと防御

double-sign / surround → slashing long-range → 弱い主観性 51% finality → 経済コスト >330 億ドル liveness（1/3+） → inactivity leak で復元

Step 5: 自分の L1 向け slashing 設計

設計パラメータ	考慮
Validator set サイズ	小さいほど協調容易 → より厳しい slashing
Slash 額	理論的最大抽出可能価値を上回るべき
内部告発者報酬	1-5% が標準
Inactivity 罰則	検閲耐性が欲しいなら必要

Step 6: 計算演習

仮想 L1:

Validator set: 50
Stake/バリデータ: 1000 万ドル
総 stake: 5 億ドル
最大抽出可能価値: 2 億ドル

必要 slash 割合: ? （抽出可能価値を上回る必要 → 50% 以上の stake を slash する設計が必要）。

抽出可能価値が 4 億ドル（大規模取引決済）に急騰したら？ → 単一攻撃で stake の 80% を要求する必要 = 設計を見直す（より厳しい slashing or より大きな validator stake 要求）。

答え合わせ

35% liveness attack の結末: Ethereum は finalization 停止 + LMD-GHOST は動き続ける（tip 生成） + ~13 日後 inactivity leak で非参加 stake が徐々に焼かれる + 参加 stake が 2/3+ に戻ったら finality 再開。1/3+ 攻撃でも 一時停止に留まる、永続破壊ではない。
Surround vote の構造的違い: 2 つ目の票が 1 つ目を時間的に包含 = fork なしで両方有効にできない。連続する epoch の通常投票は包含関係がない（独立）→ slash 不可。
slashing が経済的基盤である理由: 暗号証明だけでは攻撃を止められない、コストを上げて初めて止まる。攻撃コスト > 利益 = 経済合理的攻撃者は存在しない。

合格基準

セキュリティ条件「必要 stake > 抽出可能価値」を即答できる。
2 違反（double-sign / surround vote）の図を書ける。
相関 slashing 公式が協調攻撃を潰す理由を 1 文で言える。
5 攻撃ベクター（double / surround / long-range / 51% / liveness）と防御を表で言える。
仮想 L1 の必要 slash 割合を計算できる。

まとめ（3行）

セキュリティ条件 = 必要 stake > 抽出可能価値。暗号だけでは不十分、経済層が荷重を担う。
2 違反（double-sign / surround vote）は暗号的に検出可能 + 相関 slashing で協調攻撃を経済的に潰す。
1/3+ liveness attack は inactivity leak で復元、51% finality attack は経済コストで阻止 — 設計の美しさが両方を救う。