レッスン1 — Slashing 検知とオフライン validator

問い

Validator が stake を失う方法は厳密に 2 通り。高くつくほう: 矛盾する 2 メッセージに署名（slashing、1 回で stake の大部分消失）。じわじわ来るほう: ネットワークが必要とするときにオフライン（inactivity ペナルティ、数日で少しずつ削られる）。運用判断はこの 2 損失の小さい方を選ぶことに帰着 — どの判断軸か？

原理（最小モデル）

Stake を失う 2 経路. 能動的（slashing、暗号的に証明可能、壊滅的）+ 受動的（inactivity、緩やか、時間と共に少額）。
3 種の slashable 違反. Double voting（同 height で別ブロック）+ Surround voting（Casper FFG、後の票が前の票を包含）+ BFT equivocation（同 height/round で別 pre-commit）。
Slashing-protection DB が標準. 署名前に (H, R) で異なる署名済みメッセージをチェック → 存在すれば拒否 → 存在しなければ署名 + 記録。
DB は永続化 + 再起動耐性 + ソフト更新耐性 + バックアップ要.
DB と署名は atomic 操作. ネットワーク越しリモート DB は atomicity が崩れる窓を作る → 同マシン上必須。
リモート signer + DB で defense in depth. Validator ノード bug でも remote signer DB が最後の砦。
Whistleblower 報酬. Ethereum で slashed の ~1/512、$1M slashing で ~$2k = watcher を経済的に動機づけ。
Inactivity leak. >1/3 オフラインで finality 問題発生 → 1 epoch ごとオフライン stake を削る → chain が >2/3 オンラインに自己回復。
ネットワーク分断時は fail-closed が正解. 続けて slashing リスク vs 停止して小さな inactivity → 停止が常に正解。

具体例

Stake を失う 2 経路:

経路	何が起きるか	なぜ
能動的（slashing）	矛盾する 2 メッセージに署名	暗号的に証明可能、主要ペナルティ
受動的（inactivity）	まったく署名しない	分断中にじわじわ削られる

Ethereum 2026 概算:

Slashing: 最小 ~1 ETH、correlated slashing で増加
Inactivity leak: 非参加 1 日 ~0.1% / stake

3 種の slashable 違反:

Double voting:

Vote1: { height: 1000, block: 0xA..., signature: SigA }
Vote2: { height: 1000, block: 0xB..., signature: SigB }

両 valid + V 署名 → V slashable。両署名を持つ者なら誰でも slashing proof 構築可能。

Surround voting（Casper FFG）:

Vote1: source A → target B
Vote2: source C → target D
C < A AND D > B → 2 つ目が 1 つ目を「surround」→ slashable

BFT equivocation（Tendermint、HotStuff）:

同 height/round で別ブロックに 2 つの pre-commit
Logic は double voting と同、slashing-protection DB で捕捉

Slashing-protection DB ロジック:

Height H、round R でメッセージ M に署名する前に:
  (H, R) で内容の異なる署名済みメッセージが既に存在するなら:
    署名を拒否する  → slashing イベントを起こさない
  そうでなければ:
    M に署名する
    M をデータベースに記録する

DB 要件:

再起動を跨いで永続化
ソフトウェア更新を生き延びる
バックアップを取る（新規 DB だと現実に追いつかない）

代表実装:

EIP-3076 フォーマット（Ethereum 標準）
CometBFT priv_validator_state.json（Cosmos）
カスタムファイル（chain 固有）

リモート signer + DB:

[Validator ノード]  --署名要求-->  [Remote Signer]
                                            |
                                            +- Slashing-protection DB をチェック
                                            +- 安全なら: 署名して記録
                                            +- 危険なら: 拒否

Defense in depth: Validator ノードが double-sign を試みても remote signer DB が拒否。

Whistleblower watcher:

ブロックチェーン走査 → attestation 収集
(validator, height, round) でインデックス
衝突検知 → slashing tx 提出
報酬獲得（Ethereum で ~1/512）

Inactivity leak の動作:

通常運用中: 報酬取り逃し（日次小損失）
Finality 問題（>1/3 オフライン）: inactivity leak 発動
epoch ごとオフライン validator が stake 失う、finality 遅延長いほど率上昇
Chain は自己回復: 最終的にオンライン >2/3 回復 → finality 再開 → オフライン validator が削減後で残る

ネットワーク分断シナリオ:

分断で validator set が二分
各分断が自分を majority と誤認の可能性
各々が別 fork で署名継続
分断解消で fork 跨ぐ大規模 slashing

緩和策:

Liveness watchdog: 分断検知（peer から最近ブロックなし）→ 署名停止
ネットワーク heartbeat: 署名前に他 validator 接続性確認
強制 sync: ネットワーク追いつくまで署名拒否

失敗例（誤解）

「リモート DB（ネットワーク経由）で slashing-protection」— 間違い。DB 書き込みと署名は atomic 操作。ネットワーク失敗 → 署名だけ記録なしで残る → 再試行で同 height に再署名 → slashed。同マシン上必須。

「冗長化バックアップ DB のメリット」— 半分間違い。バックアップは持つべきだが アクティブ DB はそのまま使う（新規 DB だと現実に追いつかない、過去署名を知らない）。バックアップは復旧時の 最後の手段。

「Slashing は技術的問題、経済層は別」— 間違い。Slashing 自体が 経済的セキュリティ。検知メカニズムは暗号、執行は経済。Whistleblower 報酬で検知の経済的インセンティブも組み込まれる。

🛑 予測。 Validator が DC1 にある。DC1 がインターネット接続を 30 分失った。署名を続けるべきか？続けた場合と止めた場合の失敗モードは？（答え: 止めるべき。続けた場合 = 自分が分断側にいて、ネットワークの残りが目にしないブロックを生成しうる → 回復時に自 chain が間違いと判明 → double-sign 等価で slashed → 数百万 ETH 損失。止めた場合 = 30 分の inactivity ペナルティ（小さい）+ 接続戻ったら sync 再開可能。slashing > inactivity が常に成立、「不確実なら fail-closed」が validator の正しいデフォルト。Validator software は自動で検知して停止すべき。）

ステップで組み立てる

Step 1: Stake を失う 2 経路

能動的（slashing、壊滅的）+ 受動的（inactivity、緩やか）。

Step 2: 3 種 slashable 違反

Double voting / Surround voting（Casper FFG）/ BFT equivocation。

Step 3: Slashing-protection DB の擬似コード

(H, R) で既存メッセージチェック → 同 height/round で異なるなら拒否、なければ署名 + 記録。

Step 4: DB の atomicity 要件

DB 書き込みと署名は単一 atomic 操作 → 同マシン上必須、リモート不可。

Step 5: リモート signer + DB の defense in depth

Validator ノード bug でも remote signer DB が最後の砦。

Step 6: Whistleblower 報酬の経済設計

slashed の ~1/512 → watcher を経済的に動機づけ、市場が形成。

Step 7: ネットワーク分断時の fail-closed

「不確実なら署名停止」= slashing > inactivity が常に成立。

答え合わせ

DB と署名の atomicity 必要性: 署名してから記録の順なら → ネットワーク失敗で記録なし → 再試行で同 height に再署名 → slashing。「両方成功するか両方失敗するか」しかない atomic 操作必要。ネットワーク越しの DB は atomicity 窓を作る → 同マシン上必須。
Inactivity leak の自己回復メカニズム: >1/3 オフラインで finality 問題 → epoch ごとオフライン stake を削る（finality 遅延長いほど率上昇）→ 最終的にオンライン >2/3 回復（オフラインが削られて active 比率上昇 / オフラインが復旧）→ finality 再開 → オフライン validator が stake 削減後で残る。chain は永久 halt せず緩やかに回復。
「不確実なら停止」が正しい理由: slashing ペナルティ（壊滅的、~1 ETH 最小～数 ETH）vs inactivity ペナルティ（日 0.1% / stake、30 分なら ~0.002%）→ オーダー桁違い。続けて slashing リスク vs 停止して inactivity → 期待値で停止が圧倒的。Validator software は自動 fail-closed すべき。

合格基準

Stake を失う 2 経路を即答できる。
3 種 slashable 違反を例で言える。
Slashing-protection DB の擬似コードを書ける。
DB と署名の atomicity 必要性を 1 文で説明できる。
Inactivity leak の自己回復を 4 段で辿れる。

まとめ（3行）

Stake を失う 2 経路（slashing 壊滅的 / inactivity 緩やか）、3 種 slashable 違反（double voting / surround voting / BFT equivocation）、slashing-protection DB が標準防御。
DB と署名は atomic 操作（同マシン上必須）、リモート signer + DB で defense in depth、whistleblower 報酬（~1/512）で検知市場形成。
Inactivity leak が >1/3 オフラインから chain を自己回復、ネットワーク分断時は fail-closed が正解（slashing > inactivity が常に成立）。