﻿---
title: "フォールトプルーフ（不正証明）"
description: "楽観的なフォールトプルーフについて、係争中の主張、トレース二分、単一ステップ検証、クロック、ボンド、データ可用性、出金の確定性、運用検証をデプロイ単位で解説します。"
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.

# フォールトプルーフ（不正証明）

> 教育目的の情報であり、投資またはセキュリティに関する助言ではありません。フォールトプルーフの安全性は、対象デプロイ、データ可用性、チャレンジャーの権限と稼働性、クロック、ボンド、検証ソフトウェア、ガバナンス、決済のファイナリティ、出金コントラクトに依存します。

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

## 直接の答え

フォールトプルーフは、不正証明とも呼ばれ、計算や状態に関する楽観的な主張に異議を申し立てるプロトコル手続です。主張者は受理前にすべての遷移を証明しません。適格なチャレンジャーが定められたクロック内に矛盾するトレースを提示し、決済コントラクトが指定された検証器に基づいて争いを裁定します。多くの対話型設計では、長いトレースを一つの係争命令まで繰り返し絞り込み、その基本ケースをオンチェーンで実行します。

名称だけでは、デプロイ済みシステムがパーミッションレスで、稼働し、安全だとは証明できません。安全性には、正確な導出データが利用可能であること、少なくとも一人の正しいチャレンジャーが主張を再構築して期限内に行動できること、決済チェーンへのアクセスとガスが十分であること、証明プログラムとコントラクトが正しいこと、ガバナンスが結果を迂回できないことが必要です。ゲームを生き残った主張は、そのデプロイの規則に従って出金を認める場合がありますが、すべての L2 トランザクション、フロントエンドの説明、経済的結果を遡及的に証明するものではありません。

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

## 仕組み

1. デプロイを固定します。L1・L2 のチェーン ID、ロールアップとフォールトプルーフのバージョン、ブロックハッシュ、ファクトリ、ポータルまたはブリッジ、証明プログラム、VM、ゲーム型、実装・管理者アドレス、権限モデル、ボンド、最大深度、クロック、成熟遅延、停止状態、ファイナリティ方針を記録します。`fraud proof` という名称は、ロールアップ横断の仕様ではありません。
2. 認証済み入力から主張を再構築します。アンカー状態、L1 ヘッド、係争対象の L2 ブロックまたは出力ルート、バッチと blob データ、チェーン・ロールアップ設定、事前状態、出金ルート、正確な導出規則を記録します。状態ルートだけでは遷移を再現できず、データが利用不能なら本来開かれた異議申立経路も機能しません。
3. ゲームが作成済みで、対象に影響できることを確認します。ルート主張、主張者、作成ブロックと時刻、ゲーム型、承認・ブラックリスト状態、ボンド、チャレンジャー資格、ポータルが実際に用いる受理規則を確認します。保留中の主張、ゲーム結果、出金可能な出力を区別します。
4. 独立ノードとフォールトプルーフ実装で再実行します。正しいトレースを各係争主張と比較し、プリイメージ、状態証人、クライアント版を保存します。対話型ゲームでは、最大深度で一つの命令を特定するまで正しい区間を攻撃または防御し、基本ケースの証人をオンチェーン VM 検証器に提出します。
5. 各チームのクロックとすべてのトランザクションを追跡します。残り時間、延長、L1 収録・再編成リスク、calldata、ガス、置換、ボンド露出、並行主張、応答義務者を記録します。チャレンジ期間は必ずしも単一の固定カウントダウンではなく、正しい側も手の遅延や検閲で敗れ得ます。
6. 裁定をプロトコル上の結果に対応付けます。反論された主張、勝者、ボンドと費用の配分、無効出力の除外、依存する出力・証明・出金の再構築要否を確定します。没収ボンドは誘因であり、あらゆるブリッジ損失の補償ではありません。
7. ファイナリティと出金を別々に照合します。ゲーム裁定、必要な証明成熟期間と裁定後遅延、承認ゲーム型、ブラックリスト・停止検査、出金包含証明、確定レシート、L1 ファイナリティを検証します。データと証拠を保存し、更新を監視して、チャレンジャー、強制収録、再証明、緊急退出を演習します。

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

## 計算例

- **トレースの二分。** 教学用トレースに `1,048,576 = 2^20 instructions` があるとします。各ラウンドで係争区間を半分にすれば、`20 bisections` で一命令に到達します。これは `2^20 / 2^20 = 1` だからです。実際のゲームは出力・実行トレースを分け、DAG に分岐し、追加の手を要求し得るため、これは複雑性の例であって固定ラウンド数ではありません。
- **独立したゲームクロック。** 仮想ゲームが各チームに `84 hours` を与えるとします。ディフェンダーが `30 hours`、チャレンジャーが `22 hours` を使えば、残りはそれぞれ `54 hours` と `62 hours` です。経過実時間を単純に `84 hours` とみなせません。該当チームのクロックだけが進み、規定の延長、収録遅延、並行主張も期限を変え得ます。
- **ボンドとガスの台帳。** 明示的な仮想規則で、無効ルートに `2 ETH` のボンドがあるとします。勝ったチャレンジャーは `0.5 ETH` を預け、その元本と `1.4 ETH` の報酬を受け取り、L1 ガスに `0.08 ETH` を使いました。敗者ボンドの `0.6 ETH` は基金に入ります。純利益は `1.4 - 0.08 = 1.32 ETH` で、返却された `0.5 ETH` は利益ではなく元本です。また `1.4 + 0.6 = 2 ETH` です。実際の受取人とフリーライダー処理はコントラクト固有です。
- **出金クロック。** 出金を `2026-08-01 12:00 UTC` に証明し、証明成熟遅延が `7 days`、関連ゲームの裁定が `2026-08-06 18:00 UTC`、裁定後の待機が `1 day` とします。二つの条件は `2026-08-08 12:00 UTC` と `2026-08-07 18:00 UTC` に満たされ、両方を満たす最早時刻は `2026-08-08 12:00 UTC` です。さらに L1 ファイナリティ方針が `20 minutes` を求めれば、経済的完了は `2026-08-08 12:20 UTC` です。ただし停止、ブラックリスト、再証明、再編成がないものとします。

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

## リスク

- 誤った L1、L2、デプロイ、ゲーム型、コントラクト版を監査すること。
- 古い、非正規、または誤ったアンカーと L1 ヘッドから再構築すること。
- バッチ、blob、プリイメージ、状態証人、設定データが欠けること。
- コミットメントや証明入力の存在を、すべての導出データの可用性とみなすこと。
- クライアント不具合によりチャレンジャーが異なる正解トレースを導出すること。
- 証明プログラム、VM、プリイメージオラクル、オンチェーン単一ステップ検証器の不具合。
- 権限付き提案者、チャレンジャー、ゲーム作成経路が利用不能または掌握されること。
- 正しい監視者が期限までに争いを検出・開始しないこと。
- 検閲、L1 混雑、再編成、ガス高騰で適時の手が妨げられること。
- チェスクロック、延長、最大深度、収録時刻を誤読すること。
- 誤った主張、区間、位置、命令を攻撃または防御すること。
- ボンド要件や運転資金でパーミッションレス参加が実質困難になること。
- ボンド配分、フリーライダー、誘因が安全性の前提から外れること。
- 複数ゲーム、重複主張、競合実装が予期せず裁定されること。
- ガバナンスが承認ゲーム型、検証器、閾値、遅延を変えること。
- Guardian の停止・ブラックリスト権限が正当な出金を阻むこと。
- ゲーム裁定を即時出金または決済ファイナリティとみなすこと。
- 無効化ゲームに対する出金証明を再証明できないこと。
- 無効出力の排除で全下流アプリ・ブリッジ効果も修復されると仮定すること。
- 一つの楽観的ロールアップの証明・確定モデルを別システムへ外挿すること。

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

## よくある誤解

- 異議がなかった楽観的主張は暗号学的に正しさを証明済みである。
- 誰でも許可、資本、基盤なしにすべてのデプロイを争える。
- 導出データが利用不能でもフォールトプルーフは機能する。
- 勝訴すれば依存する全出金が直ちに確定し、全損失が補償される。
- 7 日間、二分ゲーム、一人の正直な監視者は普遍的な定数である。

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

## 関連トピック

- [データ可用性](/ja/crypto/data-availability/)
- [オプティミスティックロールアップ](/ja/crypto/optimistic-rollup/)
- [妥当性証明](/ja/crypto/validity-proof/)

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

## 出典

- [Optimistic Rollups](https://ethereum.org/developers/docs/scaling/optimistic-rollups/) - Ethereum.org（参照日：2026-08-12）
- [Fault Proof](https://specs.optimism.io/fault-proof/index.html) - OP Stack Specification（参照日：2026-08-12）
- [Fault Dispute Game](https://specs.optimism.io/fault-proof/stage-one/fault-dispute-game.html) - OP Stack Specification（参照日：2026-08-12）
- [Honest Challenger (Fault Dispute Game)](https://specs.optimism.io/fault-proof/stage-one/honest-challenger-fdg.html) - OP Stack Specification（参照日：2026-08-12）
- [Bridge Integration](https://specs.optimism.io/fault-proof/stage-one/bridge-integration.html) - OP Stack Specification（参照日：2026-08-12）
- [Optimism Portal](https://specs.optimism.io/fault-proof/stage-one/optimism-portal.html) - OP Stack Specification（参照日：2026-08-12）
- [Data availability](https://ethereum.org/developers/docs/data-availability/) - Ethereum.org（参照日：2026-08-12）
- [Arbitrum Nitro: A Second-Generation Optimistic Rollup](https://docs.arbitrum.io/nitro-whitepaper.pdf) - Offchain Labs（参照日：2026-08-12）

Source: https://wiki.fcontext.com/ja/crypto/fraud-proof/index.mdx
