はじめに
本ページは設計文書シリーズのL1 #4「コンセンサス設計」である。ブロック・チェーン設計ページの直接の後続である。前ページがヘッダー、マークルツリー、ハッシュの連鎖といったデータ構造を記述したのに対し、本ページはどのチェーンが有効でどのチェーン先端が勝つかを決定する規則を記述する。
合意形成は、ビットコインにおいて中央集権的な権威に代わるものである。すべてのフルノードがすべてのブロックを同一の決定論的規則集に対して独立に評価する。信頼に基づいてブロックを受理することはなく、他のノードの判断に委ねることもない。その結果、数千の機械が調整、投票、リーダー選出なしに単一の取引履歴に収束するシステムが実現する。
本ページは5つの領域を扱う。ブロック生成を計算上高コストにするプルーフ・オブ・ワークパズル、ブロック頻度を調節する難易度調整、合法なブロックを定義する検証規則、競合するチェーンを解決するフォーク処理ロジック、承認の安全性を定量化するファイナリティモデル。Forensicxsによる2024年のコードウォークスルーは、これらの規則がv0.1のソースコードに最初にどう実装されていたか（2,016ブロックごとの難易度調整窓を含む）を記録している。
これらの概念がはじめての方は、マイナーたちは実際、何を競っているのかとなぜ誰も台帳をごまかせないのかが、採掘競争とそれを誠実に保つ規則を事前知識ゼロで紹介している。本ページは同じ仕組みを設計文書として扱う。
サトシ時代の実装（v0.1、2009年1月）と現行のBitcoin Core（v27以降基準）で挙動が異なる場合は、両方を記す。
1. プルーフ・オブ・ワーク
プルーフ・オブ・ワークはブロック生成を計算上高コストにするメカニズムである。マイナーは80バイトのブロックヘッダーのSHA-256dハッシュがネットワーク全体のターゲット値を下回るようなナンス（およびその他の可変ヘッダーフィールド）を見つけなければならない。SHA-256は一方向関数であるため、既知の唯一の戦略は総当たり反復である。このパズル自体はビットコインの発明ではない。ホワイトペーパーが直接引用するサイファーパンクのスパム対策手法、アダム・バックの1997年Hashcashを再利用したものであり、メール1通あたりのコスト関数を、ここで扱うブロック1個あたりのコスト関数へと転用している。設計系譜の分析が、一般的な計算機科学知識の借用でも新規の統合でもなく「同時代からの直接再利用」として扱う暗号学的要素は、これがただ一つである。
マイニングループ
コードの手順で言えば、このループはブロックヘッダー（前ハッシュ、マークルルート、タイムスタンプ、難易度ビット）を組み立て、そのSHA-256dを計算し、結果がターゲット以下かどうかを確かめる。合格すればブロックを配信し、不合格ならナンスをインクリメント（またはextra-ナンス用にコインベースを変更）して再度ハッシュを計算する。
二重SHA-256 (SHA-256d) 演算はSHA-256を2回連続で適用する: SHA-256(SHA-256(header))。2回かける利点としてよく挙げられるのは、単一パスのSHA-256が許す長さ拡張攻撃を防ぐことである。
プルーフ・オブ・ワークのパラメーター
| パラメーター | 値 | 備考 |
|---|---|---|
| ハッシュ関数 | SHA-256d (二重SHA-256) | v0.1から不変 |
| 入力 | 80バイトのブロックヘッダー | バージョン、前ハッシュ、マークルルート、タイムスタンプ、ビット、ナンス |
| ナンスフィールド | 32ビット (4バイト) | ヘッダー構成ごとに約43億の候補を提供 |
| 追加ナンス | コインベーストランザクションデータ | コインベースを変更するとマークルルートが変わり、ナンス探索空間が更新される |
| ターゲット表現 | nBitsコンパクト形式 (4バイト) | 256ビットターゲットを3バイトの仮数と1バイトの指数で符号化 |
| 難易度1ターゲット | 0x00000000FFFF...（切り詰め） | すべての難易度値がこれとの比率で表される基準ターゲット |
| 有効ハッシュ基準 | ハッシュ ≤ ターゲット | ターゲットが低い = 難易度が高い = 有効なハッシュを見つけるのが困難 |
2. 難易度調整
ビットコインはブロック間の平均間隔を10分に目標設定する。ネットワーク全体のハッシュレートは、新しいマイナーの参入、旧ハードウェアの退役、エネルギーコストの変化などにより変動するため、プロトコルは2,016ブロックごと（約2週間ごと）にターゲット値を調整する。
再ターゲットサイクル
計算式で言えば、2,016ブロック窓の最初と最後のブロックの経過時間を、想定時間（2,016 × 600秒）で割って比率を出し、その比率を [1/4, 4] にクランプし、旧ターゲットにクランプ後の比率を掛けて、次の窓に適用する新ターゲットを得る。
調整パラメーター
| パラメーター | 値 | 備考 |
|---|---|---|
| 目標ブロック時間 | 600秒 (10分) | サトシはのちに、伝播に1分かかるなら「良い推測だった」と書いた。ノードが失う仕事は1割で済む |
| 再ターゲット期間 | 2,016ブロック | 目標レートでは正確に14日間 |
| 期待ウィンドウ時間 | 1,209,600秒 (14日間) | 2,016 × 600 |
| 最大上方調整 | 4倍（ターゲットが4倍容易に） | ハッシュレートの急激な低下がチェーンを無期限に停滞させることを防止 |
| 最大下方調整 | 1/4倍（ターゲットが4倍困難に） | ハッシュレートの急増がブロックを危険なほど高速にすることを防止 |
| 調整粒度 | 256ビットターゲットに対する整数算術 | 浮動小数点なし。すべての実装で決定論的 |
難易度はジェネシスブロックの1から、2026年10月3日の調整（ブロック969,696）で約1.33 × 10¹⁴ まで上昇した。この上昇はおよそ130兆倍にあたり、ネットワークハッシュレートの積み重ねによるものである。
サトシ時代のバグ
元の難易度調整コードには2つの既知の問題があり、ネットワークの全歴史を通じて合意規則として残存している:
-
一つ違い誤差。再ターゲット計算はブロックN（ウィンドウの最初のブロック）とブロックN+2,015（最後のブロック）のタイムスタンプを使用し、2,016ではなく2,015の間隔を測定する。したがって実際の再ターゲットウィンドウは意図より1ブロック短い。10分の目標では、これは約0.05% の系統的偏りを生む。
-
時間歪曲脆弱性。調整アルゴリズムは2つのブロック（ウィンドウの最初と最後）のタイムスタンプのみを検査するため、ある窓の最後のブロックから次の窓の最初のブロックまでの間隔は測られない。そのため、過半数のハッシュレートを持つマイナーは、大半のタイムスタンプをほとんど進めず、各ウィンドウの最後のブロックだけを現実の時刻にし、次のウィンドウの最初のブロックをまた過去に戻すことで、チェーンを実際より遅く見せかけ、目標レートより速くブロックを生成しながら徐々に難易度を下げることができる。この攻撃は正直な多数派に対しては理論的だが、持続的に50% 超を占める攻撃者には実行可能になる。ソフトフォークによる修正（「時間歪曲攻撃緩和」）がGreat Consensus Cleanupの一部として提案されているが、有効化に必要な運用者の合意はまだ得られていない。詳しい仕組みは時間歪曲攻撃の分析を参照。
3. ブロック検証規則
ノードが新規ブロックを受信すると、ローカルチェーン状態に受理する前に決定論的な一連の検査を適用する。すべての検査に合格しなければならず、1つでも失敗するとブロック全体が拒否される。
検証判定ツリー
上の各関所は個別の検査に対応する: プルーフ・オブ・ワーク（ヘッダーハッシュ ≤ ターゲット）、タイムスタンプ（許容範囲内）、サイズ（ブロックウェイト ≤ 4 MWU）、マークルルート（再計算値に一致）、コインベース（1件のみ、報酬 ≤ 新規発行分 + 手数料）、トランザクション（署名が有効、参照するUTXOが存在、ブロック内に二重支払いなし）。すべての関所を通過して初めて、チェーン状態が更新される。
検証項目
| 検査 | 規則 | 導入時期 |
|---|---|---|
| ヘッダーのプルーフ・オブ・ワーク | ヘッダーのSHA-256dハッシュ ≤ nBitsに符号化されたターゲット | v0.1 |
| タイムスタンプ範囲 | 直前11ブロックの中央値 (MTP) より大きく、かつノードのローカル時刻 + 2時間未満 | v0.1（GetMedianTimePast()） |
| ブロック重量 | ≤ 4,000,000重量単位 (4 MWU) | BIP 141 (2017年)。v0.1時代の1 MBバイトサイズ上限に置換 |
| マークルルート | ヘッダーのマークルルートがブロックのトランザクションリストから再計算したルートと一致 | v0.1 |
| コインベースの有効性 | コインベースは正確に1つ。出力値 ≤ 新規発行分 + トランザクション手数料合計。scriptSigにブロック高を含む (BIP 34) | v0.1。BIP 34は2013年追加 |
| トランザクションの有効性 | すべての入力が既存の未使用出力を参照。すべてのスクリプトが真に評価。ブロック内で入力が二重に使用されていない | v0.1 |
| 署名操作回数 | 全トランザクション横断の署名操作合計 ≤ 上限（従来型: 20,000、SegWit: 重量加重） | v0.1に上限なし。2010年9月に20,000追加。SegWitで計算方法を改訂 |
| トランザクションの確定性 | すべてのトランザクションがロックタイムとシーケンスの制約を満たす | v0.1。BIP 68/112で相対的タイムロック、BIP 113でロックタイムの基準を過去の中央値時刻に |
4. フォーク種別と処理
フォークは、2つ以上のブロックが同じ親を共有するたびに発生し、チェーンが競合する分岐に分裂する。フォークは3つの異なる原因から生じ、それぞれ異なる特性と解決メカニズムを持つ。
フォーク比較
最も多いフォークは意図された設計ではなく偶然の産物で、2人のマイナーがほぼ同時に有効なブロックを見つけることで起きる。
この自然フォークが解決した後も、生き残った規則自体は次の2方向のどちらかへ変わりうる。
| ソフトフォーク(規則の厳格化) | ハードフォーク(規則の緩和または変更) | |
|---|---|---|
| 旧規則への影響 | 新規則により従来有効だったブロックの一部が無効化 | 新規則により従来無効だったブロックの一部が有効化 |
| 未更新ノード | 引き続き全新ブロックを受理 — 後方互換 | 更新済みノードが受理するブロックを拒否 |
| 分裂リスク | ハッシュレート多数派が更新すればなし | 全ノードが更新しない限り恒久的 |
注目すべきフォーク
| 出来事 | 年 | 種別 | メカニズム | 結果 |
|---|---|---|---|---|
| バリュー・オーバーフロー事件 | 2010 | 緊急ソフトフォーク | CheckTransactionを修正し2,100万BTC超の出力を拒否 | チェーン再編成。無効なブロックは数時間以内に孤立化 |
| BIP 66 (厳密なDER) | 2015 | ソフトフォーク | IsSuperMajority (1,000ブロック中750で有効化、950で旧バージョンブロックを拒否) | 正規の署名符号化を強制 |
| SegWit (BIP 141) | 2017 | ソフトフォーク | BIP 9バージョンビット | 証人ディスカウント導入、改ざん性修正、スクリプトバージョニング有効化 |
| ブロックサイズ → ビットコインキャッシュ | 2017 | ハードフォーク | スケーリング方針の対立 | ビットコインキャッシュが分裂。非互換の8 MBブロックサイズ規則が恒久的チェーン分岐を生む |
| Taproot (BIP 341) | 2021 | ソフトフォーク | Speedy Trial（修正BIP 9） | シュノア署名、Tapscript、MASTを追加 |
上表のバリュー・オーバーフロー事件は、この緊急ソフトフォークという仕組みが実際に機能した最も明確な事例である。パッチが配信され無効なブロックが数時間で孤立化するに至った経緯は事件の詳細記事に譲る。
上表に挙げた2017年8月のビットコインキャッシュ分裂は、本節で述べたハードフォークのパターンを体現する具体例であり、そのブロック高やローンチ仕様、その後の経緯はビットコインキャッシュのフォークのエントリーで詳しく扱っている。
チェーン選択規則
ノードが競合するチェーン先端に遭遇した場合、累積プルーフ・オブ・ワークが最大のチェーン（内部的にnChainWorkとして追跡）、すなわち最大作業量チェーンを選択する。これは一般に不正確にも「最長チェーン」と称される。実際には、難易度の高いブロックを持つ短いチェーンが難易度の低いブロックを持つ長いチェーンよりも多くの総作業量を持ちうる。最大作業量規則は、最大の計算エネルギー支出に裏付けられたチェーンが勝利することを保証する。
5. 合意規則の進化
ビットコインの合意規則は静的ではない。すべての参加者の同時的な調整を必要とせずにネットワークが新規則を採用できるよう、慎重に段階的な有効化メカニズムを通じて進化する。
有効化メカニズムの沿革
有効化パラメーターの比較
| メカニズム | シグナル方法 | 閾値 | タイムアウト時の挙動 | 使用例 |
|---|---|---|---|---|
| フラグデー | なし（ハードコードされた高さ/時刻） | 該当なし | 指定時点で無条件に有効化 | 1 MB上限、初期パッチ |
| IsSuperMajority | ブロックnVersion ≥ N | 1,000ブロック中750で有効化、950で旧バージョンブロックを拒否 | 明示的タイムアウトなし。閾値到達まで保留 | BIP 34、BIP 66、BIP 65 |
| BIP 9バージョンビット | nVersionの個別ビット | 再ターゲット期間の95% (2,016中1,916) | 終了日までにロックインされなければ失敗。ビットは再利用可能に | CSV (BIP 68/112/113)、SegWit (BIP 141) |
| BIP 8 (LOT=true) | nVersionの個別ビット | 再ターゲット期間の95% | タイムアウト時に強制ロックイン（マイナーは有効化を阻止できない） | Taproot起動の議論で提案されたが、最終的に採用された機構ではない |
| BIP 8 (LOT=false) | nVersionの個別ビット | 再ターゲット期間の95% | タイムアウト時に失敗（BIP 9と同様） | 提案されたが単独ではデプロイされず |
| Speedy Trial | nVersionの個別ビット | 再ターゲット期間の90% | 短いシグナリング期間。タイムアウト時の強制ロックインなし | Taproot (BIP 341) |
6. ファイナリティモデル
ビットコインは確率的ファイナリティを提供し、絶対的ファイナリティは提供しない。承認済みトランザクションは後続のブロックごとに覆すのが指数関数的に困難になるが、有限の承認数では数学的に覆しを不可能にすることはない。
承認深度と攻撃成功確率
以下の表はホワイトペーパー第11節の式を当てはめ、ネットワークハッシュレートの一定割合を持つ攻撃者が、トランザクションが一定の承認深度に達した後に正直なチェーンに追いつき追い越す確率を示す。ホワイトペーパー自体が載せているのは、q = 10% の列（z = 0〜10）と、q = 30% の深さ0、5、10から50までの値で、ほかの値は同じ式で計算し、小数第4位に丸めた。
| 承認数 | q = 10% | q = 15% | q = 20% | q = 25% | q = 30% |
|---|---|---|---|---|---|
| 1 | 0.2046 | 0.3097 | 0.4159 | 0.5223 | 0.6277 |
| 2 | 0.0510 | 0.1150 | 0.2039 | 0.3154 | 0.4457 |
| 3 | 0.0132 | 0.0442 | 0.1032 | 0.1961 | 0.3246 |
| 4 | 0.0035 | 0.0173 | 0.0530 | 0.1235 | 0.2391 |
| 5 | 0.0009 | 0.0068 | 0.0274 | 0.0784 | 0.1774 |
| 6 | 0.0002 | 0.0027 | 0.0143 | 0.0499 | 0.1321 |
6承認（約1時間）の時点で、ネットワークハッシュレートの10% を制御する攻撃者がトランザクションを覆す確率は0.02% である。30% の攻撃者に対しては、同じ深度でも覆し確率は依然13.2% であり、高額トランザクションがより多くの承認を待つ理由である。
ビットコインに絶対的ファイナリティがない理由
TendermintやHotStuffのようなビザンチン障害耐性 (BFT) 合意システムでは、検証者の過半数（通常2/3）がブロックに署名すると確定とみなされる。その時点以降、プロトコルの安全性保証に違反しなければブロックを覆すことはできない。
ビットコインの設計は根本的に異なるトレードオフを行う:
| 特性 | ビットコイン（ナカモト・コンセンサス） | BFTシステム |
|---|---|---|
| ファイナリティの種別 | 確率的 — 覆し確率が深度とともに指数関数的に減少 | 決定論的 — 過半数投票後に確定 |
| 参加者集合 | 開放的 — 許可なくどの機械でもマイニング可能 | 閉鎖的 — 検証者集合が既知で有界 |
| 耐障害性 | 敵対的ハッシュレート50% 未満を許容 | 敵対的検証者1/3未満を許容 |
| 分断下の活性 | ブロック生成を継続（一時的にフォークする可能性あり） | 過半数が再接続するまで停止 |
| 覆しコスト | トランザクションの上に埋まった累積プルーフ・オブ・ワークに比例 | 検証者集合の1/3以上の買収が必要 |
ビットコインが確率的ファイナリティを選んだのは、開放的で許可不要の参加者集合を可能にするためであり、これがシステムを検閲耐性にする決定的な特性である。閉鎖的メンバーシップのBFTシステムは即時ファイナリティを提供できるが、参加者が誰かを知ることが前提となり、ビットコインが排除するように設計された信頼の前提を、再び持ち込むことになる。この表の反対側を実際に走らせている例がソラナのTower BFTだ。境界の定まった検証者集合が即時に近いファイナリティへ投票するが、それが成り立つのは共有された暗号学的な時計が全検証者に同一の投票締切を与えているからにすぎない。ビットコインの設計はそもそも共有の時計を前提にしなかったため、この問題自体を解く必要がなかった。この取引条件をプルーフ・オブ・ステークや他の方式と、日付つきの数字で軸ごとに突き合わせた結果は、プルーフ・オブ・ワークとプルーフ・オブ・ステークの比較にある。
7. 二時代比較
| 機能 | サトシ時代 (v0.1、2009年1月) | 現行Bitcoin Core、v27以降基準 |
|---|---|---|
| ハッシュ関数 | SHA-256d (二重SHA-256) | 同一 |
| チェーン選択 | ブロック高の単純比較 (nBestHeight)。累積作業量の追跡なし | 最大作業量チェーン (nChainWork、v0.3.3で導入、2010年7月) が高さ比較を置換 |
| 難易度調整 | 2,016ブロックごと。一つ違い誤差あり | 同一アルゴリズム。一つ違い誤差は合意として保存（修正にはハードフォークが必要） |
| ブロックサイズ上限 | v0.1になし。2010年半ばに1 MB追加 | 4 MWU重量上限 (BIP 141) |
| コインベース成熟 | 100ブロックの成熟規則 | 同一 |
| ソフトフォーク有効化 | コード直接変更（フラグデー） | BIP 9バージョンビット。TaprootはSpeedy Trial（BIP 9の変形） |
| スクリプト検証 | scriptSig + scriptPubKeyを結合して実行 | 分離された評価。SegWit証人プログラム。Taprootスクリプトパス支払い |
| タイムスタンプ検証 | 中央値時刻経過 (MTP) 規則: 直前11ブロックの中央値より大きいこと (GetMedianTimePast()、nMedianTimeSpan = 11) | 同一規則。v0.1から不変 |
| チェックポイント | v0.1になし。2010年7月（v0.3.2）にDoS対策としてハードコードされたチェックポイントを追加 | assumevalid（信頼されたブロックハッシュ以下のスクリプト検証を省略）が大半のチェックポイント機能に置換 |
| ヘッダー先行同期 | 利用不可。ブロックを逐次ダウンロード・検証 | ヘッダー先行同期（全ヘッダーをダウンロードし、ブロックを並列要求） |
| 暗号ライブラリー | SHA-256採掘パスは同梱のCrypto++。ECDSAとその他のハッシュはOpenSSL | 内部SHA-256（ハードウェアアクセラレーション対応）。ECDSA/シュノアにlibsecp256k1 |
8. 本ページの範囲
本ページは合意形成層を独立して扱う。以下のトピックは本ページの範囲外であり、設計文書シリーズ内のそれぞれのドメインページで扱う:
- ブロックデータ構造: ヘッダー形式、マークルツリー構築、コインベース配置。ブロック・チェーン設計ページで扱う。
- マイニング経済学: ブロックテンプレート構築、手数料市場の動態、プールプロトコル、発行計画。マイニング報酬枯渇分析が手数料のみのセキュリティ予算への長期的移行を検討する。
- トランザクション検証の詳細: UTXO照合、スクリプト評価、署名検証。トランザクション設計ページで扱う。
- ネットワーク層のブロック伝播: ブロックがP2Pネットワーク上を伝播する仕組み、コンパクトブロック中継 (BIP 152)、エクリプス/シビル耐性。
- セキュリティモデル: 51% 攻撃の経済学、利己的マイニング、完全な脅威モデル。L2セキュリティモデル深掘りに委ねる。
隣接する四つのページが、合意形成の規則を別々の角度から扱う。P2Pネットワーク設計はその規則を運ぶ伝送路を、貨幣設計は発行と難易度を検証ではなく通貨政策として、セキュリティモデルの深掘りは規則が攻撃されたときに何が起きるか、すなわち二重支払いの抑止、51% 攻撃の経済、利己的マイニングを扱う。そしてストレージ設計ページは、ブロックがこれらの規則を通過した後に何が起きるか、すなわち受理されたチェーンとUTXO集合が実際にどうディスクへ書き込まれるかを扱う。
