---
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.
# ブロックチェーンのファイナリティ：証拠、前提、決済レイヤー
> プロトコルを学ぶための資料です。「confirmed」「safe」「committed」「finalized」といった表示は、チェーン、規則、証拠、障害前提、レイヤー、アプリ方針と併せて初めて意味を持ちます。
## 要点
ファイナリティとは、受理されたブロック、チェックポイント、状態コミットメントなどの決定が、明示された安全性の前提に違反するか例外的な復旧手続きを行わない限り置き換わらない、というプロトコル固有の保証です。トランザクションのバイト列が持つ物理的性質でも、「実行に成功した」という意味でもありません。主張には対象、ネットワーク、プロトコル版、証拠、障害・時刻モデル、信頼する起点、観測者が必要です。
妥当性、正規性、ファイナリティは別物です。有効なブロックは状態遷移と認可規則を満たします。フォーク選択は有効な候補から現在の正規ヘッドを選びます。確定処理は、コミット証明書や確定済みチェックポイントなど、追加の述語をその祖先に適用します。有効ブロックで成功した取引が後にフォーク選択で敗れることも、正規ヘッドが未確定なことも、確定した送信元チェーンの事象がブリッジや取引所、アプリで失敗することもあります。
PoW は通常、明示的な確定ビットではなく確率的決済を与えます。ブロックの上に有効な累積作業量が増えるほど、所定のハッシュ能力・ネットワーク前提の下で置換は起こりにくく高コストになります。BFT 型は条件付きの決定論的ファイナリティを与えられます。有効なコミット証明書の後、故障投票重みが証明済み限界未満なら、競合する二つの決定はともにコミットできません。PoS では競合票からスラッシュ可能な重みを特定できるため、説明責任型・経済的とも表現されます。これらは異なる証拠であり、同義ではありません。
歴史を絶対に不変にするプロトコルはありません。大規模な鍵漏えい、障害限界の超過、クライアントの不具合、実装が受理した無効遷移、ガバナンス介入、社会的復旧はモデルの境界を越えます。「確定済み」とは「この前提の下で通常の再編経路ではこの決定の置き換えが許されない」という意味に限定し、例外復旧とその権限は別に記録すべきです。
## ファイナリティの分析方法
1. **対象と範囲を特定する。** 取引、ブロック、チェックポイント、状態ルート、クロスチェーンメッセージ、出金のどれかを定め、チェーン、ネットワーク、レイヤー、プロトコル版、高さまたはスロット、ハッシュ、信頼するチェックポイントを記録します。
2. **状態より先に妥当性を検証する。** 関連する状態遷移と祖先関係を再実行などで検証します。実際の規則上、クォーラム、作業スコア、画面のバッジで無効な対象を確定することはできません。
3. **ヘッド選択と確定を分ける。** フォーク選択と現在の正規経路を再構築し、プロトコルの確定済み・コミット済み祖先を探します。観測、確認、正当化、安全、コミット、確定のどれなのかを記録します。
4. **証拠を再現する。** PoW ではヘッダー、ターゲット、対象ブロック以降の累積 chainwork を検証します。投票型では署名者資格、重みのスナップショット、メッセージ領域、送信元と宛先、高さ、ラウンド、クォーラム不等式、署名、ロック、証明書の祖先関係を検証します。
5. **安全性と活性の前提を示す。** ビザンチンまたはオフライン重み、同期性、遅延、二重投票、鍵漏えい、クライアント相関、構成員変更、スラッシング可能性、確定停止時の挙動を明記します。停止中も安全性を保ちながら活性を失う場合があります。
6. **全決済レイヤーを対応付ける。** シーケンサー受領、L2 実行、データ公開、L1 取り込み、L1 確定、証明・異議完了、ブリッジ実行、取引所入金、アプリ動作を追います。別レイヤーの似た名称が同じ述語とは限りません。
7. **アプリ方針を設定し監視する。** 価値と影響に応じて証拠を定め、独立ノードを照合し、再編・競合確定アラームを処理します。前提が崩れたら不可逆な後続処理を止め、復旧承認者を記録します。
確認数は観測値であって普遍的な確定規則ではありません。Bitcoin Core ではブロックの `confirmations` は現在のアクティブチェーン上の位置に依存し、`chainwork` は期待累積作業量を記録します。Ethereum では LMD-GHOST のヘッド選択と Casper FFG のチェックポイント正当化・確定は別の状態遷移です。CometBFT では、同じ高さ・ラウンドの同じブロックに投票力の 3 分の 2 超が precommit する必要があります。各状態はそのプロトコルの文脈で解釈します。
## 計算例
### 1. 確率的な PoW 決済
Bitcoin ホワイトペーパーは、ハッシュ能力比 `q=0.10` の攻撃者が、正直なチェーンに `z=6` ブロック先行された後に追いつく状況をモデル化します。独立したハッシュ試行とポアソン分布の前提では、追いつく確率は次のとおりです。
`P=0.0002428 = 0.02428%`
小さい値ですがゼロではなく、普遍的な「6 確認保証」でもありません。実際の方針では取引価値、観測 chainwork、ハッシュ能力の集中、エクリプス・分断リスク、手数料誘因、一定シェアというモデル前提の妥当性も考えます。
### 2. Ethereum の正当化と確定
総アクティブ有効残高を `100` とする連続チェックポイントを簡略化します。正当化済み `C_0` から対象 `C_1` への `67/100` の票は 3 分の 2 以上を満たし、`C_1` を正当化します。その後 `C_1` から直下の子 `C_2` へ適格な `67/100` のリンクができれば、該当する Casper FFG 規則により `C_1` を確定できます。
ヘッドは `C_2` より先へ進んでも、新しい部分は未確定のことがあります。残高 `34` がオフラインなら残りは `66` で、フォーク選択やブロック生成が続いても即時確定は停止します。4 epoch を超えて確定しないと、Ethereum の inactivity leak が不参加者を罰し始め、アクティブな超多数が最終的に確定を回復できるようにします。
### 3. CometBFT の安全性と活性
総投票力を `100` とし、同じ高さ・ラウンドの同じブロックへの `>2/3` precommit をコミット条件とします。整数投票力 `67` でコミットできます。67 の二つのコミット集合は少なくとも `67 + 67 - 100 = 34` の重みで交差します。ビザンチン重みが 3 分の 1 未満で、正直な検証者がロック規則に従えば競合コミットは二つ作れません。
重み `34` が利用不能なら投票できるのは `66` だけで、コミットは成立しません。確定が止まっても安全性は保たれ得ます。「競合する確定ブロックがない」と「新ブロックが確定し続ける」は別の保証です。
### 4. OP Stack の状態と出金時計
OP Stack のシーケンサーは L2 ブロックをまず `unsafe` として公開できます。現在の正規 L1 上のデータから完全に導出できれば、ロールアップノードは `safe` と表示できます。対応する L1 入力が L1 の確定シグナルを受けると、導出 L2 ブロックは `finalized` になります。
この状態は確定入力からの導出に関するものです。Optimistic Rollup の出力や L2 から L1 への出金には別の証明・異議手続きがあり、challenge 条件を満たした後にだけ「finalized」と呼ぶことがあります。シーケンサー確認、L1 データ取り込み、L1 コンセンサス確定、出金実行を一つの時刻にまとめるアプリは、価値を早く解放しすぎる恐れがあります。
## リスクとレビュー上の失敗
### 定義と証拠
- 成功した実行、レシート、確認、チェックポイント、画面バッジをすべて「確定」と呼ぶ。
- チェーン、ネットワーク、版、対象ハッシュ、高さ・スロット、レイヤー、観測者を省く。
- 現在のフォーク選択ヘッドを確定済み祖先とみなす、または確定処理が最新ヘッドを選ぶと思う。
- 祖先、ターゲット、作業量、票、証明書を検証せずブロック数や時間だけを数える。
- 証拠と障害モデルが異なるプロトコル間で「2 確認」「10 分確定」を比較する。
- 署名者資格、重み、領域、送信元、宛先、高さ、ラウンドを見ず署名だけを検証する。
- 経済コスト、スラッシュ可能な証拠、実際の罰則執行を同じ保証とみなす。
- 確率リスクをゼロと表現し、条件付き決定論的安全性を無条件の不可逆性と表現する。
### プロトコルと運用の障害
- 証明済みビザンチン限界を超える、活性に必要なオンライン重みを失う、分断を隠す。
- 実装間で妥当性、フォーク選択、チェックポイント遷移、丸め、証明書祖先が一致しない。
- 古い、再送、別ネットワークの票、コミット、チェックポイント、弱主観性データを受け入れる。
- 名目上別の主体に、鍵、ステーク、ハッシュ能力、クライアント、中継、クラウド、RPC 視点を集中させる。
- inactivity leak、タイムアウト、view change が即時かつ無コストで進行を回復すると考える。
- 確定遅延、競合証明書、深い再編、二重投票、確定ルート不一致を警告しない。
- 権限、調整、クライアント公開、影響する保証を記録せず緊急統治や社会的復旧を使う。
### レイヤーとアプリの不一致
- シーケンサー取り込みを L2 安全性、L1 公開・確定、証明受理、出金完了の全部とみなす。
- 送信元事象とブリッジ自身の検証経路が方針を満たす前に資産を解放する。
- 一つの RPC の状態だけで入金を計上し、不可逆取引を実行する。
- チェーン確定が oracle の真実、コントラクトの正しさ、データ可用性、取引所の支払能力、法的決済を保証すると思う。
- 価値、相手、攻撃誘因、復旧費用によらず固定確認数を使う。
## よくある誤解
- **成功した取引は確定済みである。** 実行成功は候補履歴一つの状態遷移だけを示し、正規性と確定には追加証拠が必要です。
- **PoW は確認を増やせばリスクが厳密にゼロになる。** モデル上の確率は急減し得ますが前提付きであり、論理的不可能にはなりません。
- **3 分の 2 は常にファイナリティを意味する。** 不等式、メッセージ型、重み、高さ、ラウンド、送信元・宛先関係、ロック規則はプロトコル固有です。
- **ファイナリティはネットワークの進行を保証する。** 参加や接続が不足して新たな確定が止まっても、安全性は保たれ得ます。
- **L1 の確定で全 L2・ブリッジ処理が完了する。** データ導出、妥当性・不正証明、challenge 期間、宛先実行には別の時計と障害経路があります。
## 関連トピック
- [ブロック確認](/ja/crypto/block-confirmation/)
- [チェーン再編成](/ja/crypto/chain-reorg/)
- [コンセンサスメカニズム](/ja/crypto/consensus-mechanism/)
- [フォーク選択規則](/ja/crypto/fork-choice-rule/)
- [弱主観性](/ja/crypto/weak-subjectivity/)
## 出典
- [Blockchain Technology Overview](https://doi.org/10.6028/NIST.IR.8202) - NIST（参照日：2026-08-19）
- [Bitcoin: A Peer-to-Peer Electronic Cash System](https://bitcoin.org/bitcoin.pdf) - Bitcoin.org（参照日：2026-08-19）
- [Bitcoin Core RPC: getblockheader](https://developer.bitcoin.org/reference/rpc/getblockheader.html) - Bitcoin Project（参照日：2026-08-19）
- [Ethereum Proof-of-Stake Consensus](https://ethereum.org/developers/docs/consensus-mechanisms/pos/) - Ethereum.org（参照日：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）
- [Ethereum Proof-of-Stake Rewards and Penalties](https://ethereum.org/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/) - Ethereum.org（参照日：2026-08-19）
- [CometBFT Byzantine Consensus Algorithm](https://docs.cometbft.com/v0.38/spec/consensus/consensus) - CometBFT（参照日：2026-08-19）
- [OP Stack Derivation Specification](https://specs.optimism.io/protocol/derivation.html) - Optimism（参照日：2026-08-19）
Source: https://wiki.fcontext.com/ja/crypto/finality/index.mdx