﻿---
title: "ナカモト・コンセンサス：有効性、チェーンワーク、承認、再編成"
description: "ナカモト・コンセンサスは、各ノードが独立して適用する有効性規則、許可不要の proof of work によるブロック生成、伝播、累積作業量が最大の有効チェーンの選択を組み合わせる。ローカルビュー、チェーンワーク、承認、再編成、共通接頭辞の仮定、インセンティブ、ネットワーク攻撃を分けて分析する。"
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>

## 直接の答え

ナカモト・コンセンサスとは、ノードがコンセンサス有効性規則を独立して適用し、許可制の参加者名簿なしに proof of work の生成者がブロックを延長し、ブロックが P2P ネットワークを伝播し、各ノードが累積作業量最大の有効な枝を選ぶ Bitcoin 型のプロセスである。ノードが観測したビューのもとでプロトコル上有効な取引を順序付けるが、無効な取引を有効にしたり、台帳外の真実を確定したり、即時の決定論的ファイナリティを作ったりはしない。

有効性はチェーン選択より先である。ヘッダー、proof of work、取引、スクリプト、使用済み出力、coinbase 額、ブロック制限のいずれかが無効な枝は、主張する高さや作業量にかかわらず拒否される。ノードの規則に合格しデータが利用可能な枝の間では、ブロック数だけでなく累積チェーンワークがアクティブチェーンを決める。「最長チェーン」は、proof of work の投入量が最大の有効チェーンを指す非公式な略称である。

アクティブな先端は暫定的である。競合する有効ブロックにより、接続状態の良い誠実なノード同士でも一時的に異なるローカルビューを持ち得る。追加作業が通常フォークを解消し、ノードはチェーン再編成で一方を切断して他方を接続することがある。取引の承認数は、観測者の現在のアクティブチェーン内での深さを示す。指定したハッシュレートとネットワークモデルでは深さが追いつく確率を下げ得るが、普遍的に最終となる承認数はない。

この用語はハッシュ計算だけを意味しない。安全性の議論は、ブロックと取引の有効性、P2P 伝播、最多作業量の有効チェーンを誠実に採用すること、十分な誠実側の実効採掘力、経済行動、利用者が意図したネットワークとソフトウェアを独立して観測することにも依存する。共通接頭辞、チェーン成長、チェーン品質は、明示されたモデル内でのみ証明される形式的性質であり、実運用される全 proof-of-work チェーンの無条件の事実ではない。

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

## ナカモト・コンセンサスの分析方法

1. **識別子と観測範囲を固定する。** `chain`、`network`、`genesis hash`、`client version`、コンセンサス規則、チェックポイントまたは assume-valid 設定、観測者、ピア、時刻を記録する。`bestblockhash`、`height`、`chainwork` を保存する。メッセージ伝播中は、二つのノードが誠実に異なる先端を報告し得る。
2. **作業量比較の前に検証する。** ヘッダー連結、時刻制約、復号したターゲット、proof of work、Merkle と witness のコミットメント、取引、スクリプト、UTXO 使用、coinbase、ブロック資源制限を検証する。`invalid` な枝が、高さや作業量の主張だけで候補になることはない。
3. **観測したブロック木を再構成する。** 前ブロックハッシュで各候補を既知の祖先へ結び、完全なブロックとヘッダーのみを区別する。`active`、`valid-fork`、`valid-headers`、`headers-only`、`invalid` の状態を `getchaintips` などで照合し、見えるすべての先端を有効な競合チェーンと呼ばない。
4. **累積作業量を再計算する。** 各ヘッダーの `nBits` ターゲットを復号し、実装の整数規則に従って、概念上 `work = floor(2^256 / (target + 1))` で表される作業量を計算する。祖先に沿って合計し、共通祖先から有効な枝を比較する。高さ、推定ハッシュ数、プール名はチェーンワークの代替ではない。
5. **選択と再編成を追跡する。** ノードによる最多作業量候補の選択、同作業量でのローカルな順序、到着状態を再現する。より良い有効枝が現れたら、分岐点を特定し、旧接尾部を切断し、新接尾部を接続し、`UTXO set` を更新して `mempool` とアプリケーション記録の取引を照合する。
6. **リスクに基づく承認方針を設ける。** 現在のアクティブチェーン上のブロックだけに `confirmations = tip_height - block_height + 1` を計算する。リスク額、可逆性、攻撃者比率、伝播、eclipse リスク、観測 stale 率、承認深度、対応計画を明示する。6 承認は慣行であり、プロトコルのファイナリティ閾値ではない。
7. **安全性の議論全体をストレステストする。** 分断、遅延、ブロック秘匿、selfish mining、eclipse 攻撃、プールとハードウェアの集中、急なハッシュレート変化、手数料と補助金の誘因、クライアント不一致、深い再編成、復旧方針を試す。共通接頭辞、チェーン成長、チェーン品質、永続性、ライブネスへの対応付けは、引用モデルの仮定内だけで行う。

成果物は、どの有効な履歴をノードが現在選び、その理由は何かを、観測者ごとに再現できる説明である。コンセンサス規則が候補資格を定め、proof of work が代替履歴を高価にし、伝播が他ノードに作業を見せ、フォーク選択が現在の履歴を選び、承認方針がアプリケーションの行動時点を決める。すべてを「ネットワーク承認」という一語にまとめると、失敗し得る条件が隠れる。

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

## 計算例

### 1. 無効な作業は勝たない

枝 A が `valid_A = false` と `chainwork_A = 1,200 units` を報告し、枝 B が `valid_B = true` と `chainwork_B = 1,000 units` を持つとする。ノードは A を拒否して B を選ぶ。作業量は適格な候補間だけで比較され、proof of work は過大な coinbase、無効署名、二重支払いを許可できない。

ある観測者が A のヘッダーだけを持ち、別の観測者が完全なブロックデータを持つなら、ダウンロードと検証が終わるまで状態が異なり得る。ヘッダーが有効な枝は、全取引と状態遷移が完全検証済みという証拠ではない。

### 2. 高さは累積作業量ではない

ターゲットが変わる簡略例で、枝 C が各 100 作業単位のブロックを六つ追加すると `6 * 100 = 600 units` となる。枝 D が各 130 単位のブロックを五つ追加すると `5 * 130 = 650 units` となる。両方が有効で開始時の作業量が同じなら、D は一ブロック短くても最多作業量の枝である。

二つの有効な先端が正確に `650 units` なら、同じ作業量だけで全ノードが直ちに同じ先端を見るとは限らない。到着順序やローカル実装状態は、次の有効ブロックが一方を重くするまで異なり得る。一時的な同作業量ビューを決定論的なグローバルファイナリティと表現してはいけない。

### 3. 承認は取り消され得る

高さ `100` のブロックに入った取引について、アクティブ先端が高さ `105` なら、承認数は `tip_height - block_height + 1 = 105 - 100 + 1 = 6 confirmations` である。別の有効枝が高さ 99 の後から分岐し、その取引を含まず高さ 106 で最多作業量になったとする。再編成は旧ブロック `100 through 105` を切断する。その取引はアクティブチェーン上の 6 承認を失い、mempool に戻る、競合支払いと衝突する、または含まれないままになる。

アプリケーションは数字の 6 だけを保存せず、ブロックハッシュと祖先関係を照合しなければならない。取引所の入金、引き渡した商品、ブリッジメッセージ、デリバティブ決済は、元チェーン履歴が可変でも経済的に不可逆になり得る。

### 4. 追いつき確率はモデル依存である

Bitcoin ホワイトペーパーの例示モデルで、攻撃者のハッシュ比率を `q = 0.10`、誠実側を `p = 0.90`、誠実チェーンのリードを `z = 6` とする。Poisson 近似は `lambda = z * (q / p) = 0.6666667` と `P(catch up) = 0.0002428027 = 0.02428027%` を与える。同じ深さで `q = 0.30` なら `P(catch up) = 0.1321111687 = 13.21111687%` に上がる。

これは現在の Bitcoin の保証値ではない。計算は安定した独立ハッシュ試行とモデル内の競争条件を仮定し、eclipse 隔離、伝播優位、selfish 戦略、価格とレンタルの反応、実装バグ、アプリケーション対応を含まない。方針はモデルを開示し、6 承認だけを引用せず、より悪い条件も試すべきである。

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

## リスクとレビュー上の失敗

### プロトコルと測定の誤り

- ヘッダー、ブロック本体、祖先を独立検証する前に作業量を比較する。
- 累積チェーンワークを計算せず、最も高い枝や最初に見た枝を勝者と呼ぶ。
- ブロック数、公称ハッシュレート、プール比率、エクスプローラー表示をチェーンワークの代理にする。
- mainnet、testnet、signet、フォーク、クライアント版、チェックポイント、genesis の識別を混ぜる。
- ヘッダーのみ、データ不在、楽観状態を完全検証済み履歴として扱う。
- ターゲット復号、整数作業量算術、前ハッシュ連結、共通祖先を無視する。
- ハッシュ、高さ、時刻、ピアの文脈なしに一つの RPC やエクスプローラーを全体ビューとする。

### ネットワーク、誘因、制御の誤り

- 伝播が即時で、全ノードの取引とブロック到着順が同じと仮定する。
- 同作業量の競合を一つのグローバルな決定状態とし、一時的ローカルビューとして扱わない。
- stale ブロック、遅延、秘匿、selfish mining、伝播優位を無視する。
- プール名から独立した採掘者を、プール比率から物理ハードウェア所有を推測する。
- プール、firmware、製造業者、hosting、energy、地域、network の集中を無視する。
- 報酬を、誠実な延長が常に全参加者の最適戦略である証拠とする。
- eclipse、partition、Sybil、peer poisoning、DoS、時刻操作のリスクを省く。

### 決済とセキュリティの誤り

- 承認をプロトコルファイナリティと呼び、6 承認は取り消せないと約束する。
- あらゆる金額、相手方、可逆性、脅威モデルに同じ承認数を使う。
- ホワイトペーパーの確率例を現在測定された攻撃確率に変える。
- 過半数ハッシュが署名を偽造し、任意のコインを奪い、無効な発行を有効にできると述べる。
- 少数ハッシュでは有利な逸脱、再編成、検閲が一切不可能と述べる。
- 現在の最多作業量先端を、正しい外部事実、法的所有、アプリケーション決済と同一視する。

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

## よくある誤解

- **最長チェーンは常にブロック数が最多である。** Bitcoin ノードは累積作業量最大の有効チェーンを選ぶ。ターゲットが異なる場合、高さだけでは不十分である。
- **採掘者が有効なプロトコル規則を決める。** 採掘者はブロックを提案し、各フルノードが設定されたコンセンサス規則を独立適用する。
- **6 承認で絶対的ファイナリティになる。** 6 はアプリケーション上の慣行であり、再編成確率はモデル、深さ、攻撃者、伝播、観測の完全性に依存する。
- **51% の攻撃者は誰のコインでも使える。** ハッシュ力は再編成、二重支払い、検閲を支え得るが、他人の秘密鍵署名を与えず、未変更のフルノードに無効発行を受け入れさせない。
- **総ハッシュレートが高ければ分散性と安全性が証明される。** 実効支配、ネットワーク可視性、ハードウェア入手、プール協調、クライアント多様性、誘因、攻撃期間も重要である。

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

## 関連トピック

- [Proof of work](/ja/crypto/proof-of-work/)
- [フォーク選択規則](/ja/crypto/fork-choice-rule/)
- [ブロック承認](/ja/crypto/block-confirmation/)
- [チェーン再編成](/ja/crypto/chain-reorg/)
- [Selfish mining](/ja/crypto/selfish-mining/)

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

## 出典

- [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 Developer Guide: Block Chain](https://developer.bitcoin.org/devguide/block_chain.html) - Bitcoin Project（参照日：2026-08-19）
- [Bitcoin Core RPC: getchaintips](https://developer.bitcoin.org/reference/rpc/getchaintips.html) - Bitcoin Project（参照日：2026-08-19）
- [Bitcoin Core: validation.cpp](https://github.com/bitcoin/bitcoin/blob/master/src/validation.cpp) - Bitcoin Core（参照日：2026-08-19）
- [The Bitcoin Backbone Protocol: Analysis and Applications](https://eprint.iacr.org/2014/765) - IACR Cryptology ePrint Archive（参照日：2026-08-19）
- [Majority Is Not Enough: Bitcoin Mining Is Vulnerable](https://www.cs.cornell.edu/~ie53/publications/btcProcArXiv.pdf) - Cornell University（参照日：2026-08-19）
- [Eclipse Attacks on Bitcoin's Peer-to-Peer Network](https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/heilman) - USENIX Association（参照日：2026-08-19）

Source: https://wiki.fcontext.com/ja/crypto/nakamoto-consensus/index.mdx
