﻿---
title: "Nothing at Stake：二重署名、スラッシング、ファイナリティ、旧鍵リスク"
description: "Nothing at Stake は、競合する履歴を支持する限界費用が低くなり得るプルーフ・オブ・ステークのインセンティブ問題です。スラッシュ可能なメッセージ、期待利得、クォーラムの交差、証拠の執行、フォーク選択、弱い主観性の前提を分けて分析します。"
image: "https://wiki.fcontext.com/og.png"
---

> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Nothing at Stake：二重署名、スラッシング、ファイナリティ、旧鍵リスク

> プロトコル分析の教育目的に限られ、投資、ステーキング、バリデーター運用、セキュリティに関する助言ではありません。スラッシングとファイナリティの規則はプロトコルやバージョンによって異なり、実装、鍵管理、ネットワーク状況、ガバナンス、弱い主観性の前提も破綻し得ます。

<a id="answer"></a>

## 直接の答え

Nothing at Stake はプルーフ・オブ・ステークのインセンティブ問題です。追加署名の作成が安価で、互いに両立しない支持にプロトコルが実効的な費用を課さない場合、バリデーターは一つを選ぶより、競合するすべての履歴を支援する方が多く稼げる可能性があります。多くのバリデーターがこの私的インセンティブに従えば、フォークへの支持が残り、収束が弱まり、攻撃者はプルーフ・オブ・ワークなら再現に費用がかかる署名を集められます。

この表現は、すべてのプルーフ・オブ・ステークにセキュリティ予算がない、または敗れたフォークへの投票がすべて不正だという意味ではありません。拘束資本、逸失報酬、スラッシング、出金待機、フォーク選択規則、ファイナリティ規則は利得を変えます。処罰対象となる署名済みメッセージと競合はプロトコルおよびバージョン固有であり、通常の投票更新、遅延メッセージ、一時的な正直なフォークは許容される場合があります。

三つの問いを分ける必要があります。第一に、現在も担保を拘束されているバリデーターが最近のブランチ間で安価に二重署名できるか。第二に、利用不能または敵対的な投票ウェイトが、二つの確定履歴を作らずに進行を停止できるか。第三に、ステークが出金可能になった後、旧鍵が長い代替履歴を偽造できるか。これらは関連するインセンティブおよびコンセンサスのリスクですが、証拠、閾値、防御は異なります。

Ethereum は有用な例ですが、普遍的なひな型ではありません。そのコンセンサス仕様では、同じスロットに対する二つの異なる提案、ならびに二重投票または囲い込み投票となるアテステーションがスラッシュ可能です。フォーク選択は二重署名者の影響を無視でき、ファイナリティは超多数投票とペナルティを使います。他のプルーフ・オブ・ステーク系統は、異なるリーダー選出、チェーン選択、チェックポイント、可用性の前提、形式的セキュリティモデルを採用します。

<a id="mechanism"></a>

## Nothing at Stake の分析方法

1. **プロトコルの文脈を固定する。** `protocol`、`version`、`network`、`epoch`、`slot`、`validator set`、観測時刻を記録します。有効な `fork choice`、`finality gadget`、`reward rule`、`penalty rule`、`withdrawal delay` を特定してください。「PoS」という名称だけでは、いずれも決まりません。
2. **署名対象の行為を定義する。** ブロック提案、アテステーション、prevote、precommit、証明書その他のメッセージとドメインを列挙します。異なる子孫を支持するだけの二つのメッセージと、参照規則上スラッシュ可能な `double proposal`、`double vote`、`surround vote` を区別してください。
3. **無罰時の利得をモデル化する。** ブランチ確率、正規ブランチの報酬、追加署名と伝播の費用、賄賂、機会損失、競合メッセージの報酬を見積もります。電力消費が少ないことから逸脱が有利だと決めつけず、`EV(honest)` と `EV(equivocate)` を比較してください。
4. **執行可能な損失をモデル化する。** 拘束残高、検出確率、証拠の有効期間、報告経路、取り込みと検閲のリスク、初期ペナルティ、相関ペナルティ、強制退出、出金時期、将来収益の喪失を特定します。文書にあるペナルティは、`slashing evidence` が確実に執行されることと同じではありません。
5. **フォーク選択とファイナリティを分ける。** 最新投票、二重署名、メッセージ時系列がヘッドに与える影響を再構成し、チェックポイントの正当化または確定に必要なウェイトを計算します。`safety threshold` と `liveness threshold` は別々に分析してください。投票の留保は、競合ファイナリティを作らずにファイナリティを止められます。
6. **旧鍵と同期の前提を検証する。** 退出済みステークがいつ処罰不能になるか、オンラインノードがどの確定履歴を拒否するか、新規または長期オフラインのノードが `weak-subjectivity checkpoint` をどう取得するか、その鮮度と出所をどう検証するかを確認します。これは長距離問題であり、最近の二重投票だけの問題ではありません。
7. **運用と支配にストレスをかける。** 鍵の重複、フェイルオーバーノード、リモート署名機、データベースのロールバック、クライアントの不具合、共通ホスティング、ステーキングプール、委託保管、ネットワーク分断、eclipse 攻撃、証拠検閲を試験します。バリデーター識別子の数だけでなく、独立した支配経路とソフトウェア経路を数えてください。

成果物は、用語だけで下す判定ではなく、バージョンを明示したインセンティブとコンセンサスの評価です。鍵が署名できる正確なメッセージ、客観的に検証できる競合証拠、担保を回収できる期間、安全性を守る閾値、進行を可能にする閾値、同期ノードが必要とする信頼済み状態を示します。

<a id="example"></a>

## 計算例

### 1. 無罰の戦略は両ブランチを有利にし得る

二つのブランチのうち正規になるのは一つだけで、ブランチ A の確率が `0.55`、ブランチ B が `0.45` だとします。正規ブランチ上の署名は `1.00 unit` を得て、敗れたブランチ上の署名はゼロです。すべてのペナルティと追加運用費を無視すると、A だけへの署名は `EV(A only) = 0.55 * 1.00 = 0.55 units`、両方への署名は `EV(sign both) = (0.55 + 0.45) * 1.00 = 1.00 unit` になります。

この計算はインセンティブ問題の説明であり、ステーキング利回りの予測ではありません。どちらが勝っても両署名のうち正規ブランチの署名に報酬が払い出され、行為が許可されるか罰則が執行されず、ブランチの結果が相互排他的で、価格、評判、遅延、将来収益の損失がないと仮定しています。

### 2. 執行可能なスラッシングは利得を逆転させ得る

正規ブランチの総報酬を `1.00 unit` とし、二重署名への賄賂 `0.02 unit` を加えます。有効な証拠が `0.80` の確率でペナルティ機構に到達し、帰属可能な総損失が `5.00 units` だとします。単純化した利得は `EV(equivocate) = 1.00 + 0.02 - (0.80 * 5.00) = -2.98 units` で、A だけに署名する `0.55 units` を下回ります。

検出、取り込み、回収可能な担保、将来収益が異なれば結果も変わります。実際のペナルティは、有効残高、相関した違反、時刻、プロトコル状態に左右されます。運用者は結果の分布をモデル化して実装経路を確認すべきであり、選んだ三つの数を掛けるだけでは、稼働中のシステムがインセンティブ整合的だとは証明できません。

### 3. クォーラムの交差は安全性を守るがライブネスを損ない得る

`100 stake units` があり、ファイナリティ投票に少なくとも `67 units` を必要とする規則を考えます。このような二つのクォーラムは少なくとも `67 + 67 - 100 = 34 units` 重なります。したがって二つの競合する確定には、少なくとも 34 単位が両方のクォーラム証明書に参加する必要があり、説明責任を備えたプロトコルはこの交差をスラッシュ可能な証拠にできます。

同じ閾値はライブネスに別の意味を持ちます。`34 units` が有効投票を留保すると、残りは `66 units` で 67 を下回るため、ファイナリティは停止し得ます。この 34 単位だけでは二つのブランチを確定できません。安全性の破綻、説明責任の証拠、進行不能を同じ事象として説明してはいけません。

### 4. 旧鍵は別の同期問題を作る

オンラインノードがチェックポイント `epoch 39,900` を確定済みで、新規ノードには信頼済み状態がないとします。攻撃者は `epoch 10,000` 付近で十分なステークを支配していた鍵を取得しますが、そのバリデーターは退出して担保も回収不能です。そして `epoch 40,000` まで代替履歴を偽造します。安価な過去署名は関係しますが、現在のバリデーター向けスラッシングでは旧鍵を抑止できない場合があります。

オンラインノードは、自身の確定済みビューと競合する履歴を拒否します。新規ノードは、履歴を識別して客観的検証を続ける前に、最近の認証済みチェックポイントまたは同等のプロトコル規則を必要とします。そのため弱い主観性と出金時期を評価に含めますが、担保拘束中のバリデーターによるライブな二重署名とは分けて分析します。

<a id="risks"></a>

## リスクとレビュー上の誤り

### プロトコルと証拠の誤り

- 正確な署名フィールドとドメインを確認せず、非正規フォークへの投票をすべてスラッシュ可能と呼ぶ。
- フォーク、再編成、提案漏れ、遅延投票、証明可能な二重署名を同じ事象として扱う。
- Ethereum の提案者およびアテスター条件を、メッセージやファイナリティ規則が異なるプロトコルに適用する。
- 競合するとされる署名の比較で、チェーン識別子、フォークバージョン、epoch、slot を省く。
- バリデーター識別子、ドメイン、祖先関係、有効な暗号検証なしに、二つの署名だけで違反を証明できると考える。
- フォーク選択への影響と、正当化、確定、アプリケーションレベルの決済を混同する。
- 同期性、正直性、可用性、敵対者の前提を読まずに、仕様の安全性定理だけを引用する。

### インセンティブと執行の誤り

- 署名が安価だというだけで、拘束資本の損失、逸失報酬、将来収益を価格に含めない。
- 名目上の最大スラッシング額を、すべての状態で回収できる期待損失として扱う。
- 証拠が出金前に必ず観測、伝播、取り込み、処理されると仮定する。
- 提案者による検閲、ネットワーク分断、eclipse 隔離、証拠期間の満了を無視する。
- 確率、賄賂、損失が未計測なのに、例示的な期待値を証明として使う。
- 相関ペナルティ、トークン価格変動、ヘッジ、外部賄賂、攻撃側の利得を無視する。
- 退出済みバリデーターの旧鍵が、現在もスラッシュ可能な担保で裏付けられると仮定する。

### 運用、集中、復旧の誤り

- 永続的に共有されるスラッシング保護なしで、フェイルオーバーノードに同じ署名鍵を置く。
- 署名機またはスラッシングデータベースを古いバックアップから復元し、過去に署名した競合を再作成する。
- 保管、クライアント、クラウド、ガバナンスの支配が共通なのに、バリデーター鍵を独立運用者として数える。
- 委任ステーカーは、運用者、プール、リステーキング依存による損失を負わないと仮定する。
- 長期オフラインノードの復旧時に、一つのエクスプローラー、プロバイダー、同梱チェックポイントだけを信頼する。
- ステーク分布、閾値、支配を分析せず、高いステーキング参加率だけで安全性を主張する。

<a id="misconceptions"></a>

## よくある誤解

- **プルーフ・オブ・ステークには文字どおり何もリスクがない。** 適切に設計されたシステムは、拘束資本、報酬、将来参加を損失にさらせます。問題は、その費用が対象の逸脱に対して十分かつ執行可能かです。
- **二つのフォーク上のバリデーターメッセージはすべて二重投票である。** スラッシュ可能性はプロトコルのメッセージフィールド、ドメイン、競合規則に依存し、正直なフォーク選択更新には許容範囲が必要です。
- **スラッシングはコンセンサスを保証する。** スラッシングは説明責任とインセンティブを与えますが、安全性とライブネスは閾値、ネットワーク、実装、鍵管理、正直な行動の前提にも依存します。
- **3 分の 1 のステークだけで二つのブランチを確定できる。** 3 分の 2 のファイナリティ設計では、およそ 3 分の 1 は通常進行を止められますが、競合ファイナリティには交差する超多数と、その交差部分によるスラッシュ可能な参加が必要です。
- **Nothing at Stake と長距離攻撃は同一である。** どちらも安価な署名を利用しますが、前者は競合するブランチへの現在の支持、後者は最近の信頼済み状態を持たないノードに対する過去鍵の利用です。

<a id="related"></a>

## 関連トピック

- [プルーフ・オブ・ステーク](/ja/crypto/proof-of-stake/)
- [スラッシング](/ja/crypto/slashing/)
- [フォーク選択規則](/ja/crypto/fork-choice-rule/)
- [ファイナリティ](/ja/crypto/finality/)
- [長距離攻撃](/ja/crypto/long-range-attack/)

<a id="sources"></a>

## 出典

- [Blockchain Technology Overview](https://doi.org/10.6028/NIST.IR.8202) - NIST（参照日：2026-08-19）
- [Formal Barriers to Longest-Chain Proof-of-Stake Protocols](https://economics.princeton.edu/working-papers/formal-barriers-to-longest-chain-proof-of-stake-protocols/) - Princeton University（参照日：2026-08-19）
- [Ethereum Consensus Specifications: Validator](https://github.com/ethereum/consensus-specs/blob/master/specs/phase0/validator.md) - Ethereum Foundation（参照日：2026-08-19）
- [Ethereum Consensus Specifications: Beacon Chain](https://github.com/ethereum/consensus-specs/blob/master/specs/phase0/beacon-chain.md) - Ethereum Foundation（参照日：2026-08-19）
- [Casper the Friendly Finality Gadget](https://eips.ethereum.org/assets/eip-2982/arxiv-1710.09437-Casper-the-Friendly-Finality-Gadget.pdf) - Ethereum Improvement Proposals（参照日：2026-08-19）
- [Ethereum Proof-of-Stake Attack and Defense](https://ethereum.org/developers/docs/consensus-mechanisms/pos/attack-and-defense/) - Ethereum.org（参照日：2026-08-19）
- [Weak Subjectivity](https://ethereum.org/developers/docs/consensus-mechanisms/pos/weak-subjectivity/) - Ethereum.org（参照日：2026-08-19）
- [Ouroboros: A Provably Secure Proof-of-Stake Blockchain Protocol](https://eprint.iacr.org/2016/889) - IACR Cryptology ePrint Archive（参照日：2026-08-19）

Source: https://wiki.fcontext.com/ja/crypto/nothing-at-stake/index.mdx
