はじめに
本ページは設計文書シリーズのL1 #3「ブロック・チェーン設計」である。ブロック・チェーン層を扱う。トランザクションがブロックにバッチされる方法、ブロックがチェーンにリンクされる方法、ノードが権威あるチェーン先端を選択する方法を解説する。
これらの概念がはじめての方は、取引はどうやって共有台帳になるのかがブロックとチェーンを事前知識ゼロで紹介している。本ページは同じ構造を設計文書として扱う。
トランザクション設計ページは個々のトランザクション（入力、出力、スクリプト、署名）を扱った。本ページはそこから1段上がり、それらのトランザクションを永続的かつ全体的に順序付ける構造を扱う。
3つの設問で素材を整理する:
- ブロックとは何か? タイムスタンプ付きのコンテナであり、一連のトランザクションを単一のプルーフ・オブ・ワークの封印の下にコミットする。
- チェーンとは何か? 各ブロックが前のブロックのハッシュを参照するブロックの連鎖であり、追記専用台帳を形成する。
- どのチェーンが勝つか? 累積プルーフ・オブ・ワークが最大のチェーンであり、ブロック数が最多のチェーンではない。
サトシ時代の実装（v0.1、2009年1月）と現行のBitcoin Core（v27以降基準）で挙動が異なる場合は、両方を記す。
ブロックヘッダーハッシュ、マークルルート、完全なブロック直列化のv0.1における正確な境界は、ソースレベルの直列化分析で確認できる。
1. ブロック構造
ブロックは2つの部分で構成される。ブロックを要約するコンパクトな80バイトのヘッダーと、ブロックに含まれるすべてのトランザクションを収めるトランザクションリストである。チェーンレベルの検証にはヘッダーのみが必要で、内容レベルの検証には完全なトランザクションリストが必要となる。
ブロックの構造
直列化の観点では、上のヘッダー6フィールドは図の順番どおり（バージョン、前ハッシュ、マークルルート、タイムスタンプ、nBits、ナンス）に隙間なく並び、その直後にトランザクション件数とトランザクションリスト本体が続く。
ヘッダーフィールドの詳細
| フィールド | サイズ | 説明 |
|---|---|---|
| バージョン | 4バイト | ブロック形式のバージョン。v27以降基準ではソフトフォークシグナリングビット (BIP 9) を符号化。 |
| 前ブロックハッシュ | 32バイト | 前のブロックヘッダーのSHA-256dハッシュ。このブロックをチェーンにリンクする。ジェネシスブロックはゼロハッシュを使用。 |
| マークルルート | 32バイト | ブロック内の全トランザクションから構築されたマークルツリーのルートハッシュ。トランザクション集合をヘッダーにコミットする。 |
| タイムスタンプ | 4バイト | マイナーが設定するUnixエポック時刻。直前11ブロックの中央値より大きく、かつノードの時計（v27より前はネットワーク調整時刻）より2時間を超えて先であってはならない。 |
| nBits | 4バイト | ターゲット閾値のコンパクト符号化。ブロックヘッダーのハッシュはこのターゲット以下でなければならない。2,016ブロックごとに再計算。 |
| ナンス | 4バイト | マイナーが有効なプルーフ・オブ・ワークを探索するために反復する任意の値。4バイト空間（2³² 値）は頻繁に枯渇し、探索空間を更新するためにコインベースやタイムスタンプの変更が必要になる。 |
ブロックバージョンの進化
| 時代 | バージョン | 意義 |
|---|---|---|
| サトシv0.1 | 1 | 唯一のバージョン。シグナリング機構なし。 |
| BIP 34 (2013年) | 2 | コインベースにブロック高が必須。バージョンを用いた合意規則強制の初使用。 |
| BIP 66 (2015年) | 3 | 厳密なDER署名符号化。 |
| BIP 65 (2015年) | 4 | OP_CHECKLOCKTIMEVERIFYを有効化。 |
| BIP 9 (2016年〜) | 上位3ビット = 001、残り29ビットで個別提案をシグナル | バージョンビット方式: 複数のソフトフォークを同時にシグナル可能。SegWit (ビット1)、Taproot (ビット2) 等で使用。 |
| v27以降基準 | バージョンビット標準 | 現行のすべてのブロックがBIP 9バージョンビットシグナリングを使用。基底値は0x20000000 + 提案固有のビット。 |
2. マークルツリー
ブロックヘッダーのマークルルートは、ブロック内の全トランザクションに対する暗号学的コミットメントである。二分ハッシュ木として構築される。リーフノードがトランザクションのハッシュであり、各内部ノードは2つの子を連結したSHA-256dハッシュである。マークルツリーも、以下で扱うハッシュ連鎖のブロック構造も、ビットコイン独自の発明ではない。どちらも計算機科学一般の構成要素であり、ホワイトペーパーは引用・再利用しただけで新規に考案したわけではないことを、設計系譜の分析がマークルの1980年のツリーと1990年代のハーバー・ストルネッタによる連結タイムスタンプの文献にまで遡って跡付けている。
マークルツリーの構築
奇数ノード規則。ツリーの各レベルでノード数が奇数の場合、最後のノードが複製されてペアを形成する。これによりツリーは常に完全二分木となる。
マークルツリーの意義
| 利点 | 仕組み |
|---|---|
| SPV証明 | 軽量クライアントが、全n件のトランザクションをダウンロードせずlog₂(n) 個のハッシュ（マークルパス）の検査のみでトランザクションのブロック内包含を検証できる。 |
| 効率的な検証 | 単一のトランザクションを変更するとマークルルートが無効になる。ノードは全トランザクションをゼロから再検証せずに、改竄・破損したブロックを検出できる。変更されたリーフからルートへのパスが一致しなくなるためだ。 |
| コンパクトなコミットメント | トランザクション集合全体が単一の32バイトハッシュとしてヘッダーにコミットされる。ブロックに1件のトランザクションが含まれても10,000件が含まれてもヘッダーは80バイトのまま。 |
SegWit証人コミットメント
現行のBitcoin Core（v27以降基準）は第2のマークルツリーを追加する。証人マークルツリーであり、そのルートはコインベーストランザクションのOP_RETURN出力 (BIP 141) 内にコミットされる。これは主マークルルートが除外する証人データ（署名、スクリプト）をコミットする。サトシのv0.1には証人の概念がなく、単一のマークルツリーが署名を含む完全に直列化されたトランザクションをコミットしていた。
3. チェーン構造
ブロックチェーンはブロックの単方向連結リストであり、各ブロックのヘッダーに前のブロックヘッダーのSHA-256dハッシュが含まれる。このハッシュの連鎖が台帳を追記専用にする。いかなる過去のブロックを変更してもそのハッシュが変わり、次のブロックからのリンクが切れ、チェーン先端までのすべての後続ブロックに波及する。
ブロックの連鎖
ハッシュの連鎖による不変性。各ヘッダーハッシュはprevBlockHashを含むヘッダー全80バイトに対して計算される。ブロック2のトランザクションリスト内の1バイトを変更すると、ブロック2のマークルルートが変わり、ブロック2のヘッダーハッシュが変わり、ブロック3のprevBlockHashが無効になり、以降同様に連鎖する。過去のブロックを改ざんする攻撃者は、そのブロックとすべての後続ブロックのプルーフ・オブ・ワークをやり直さなければならず、そのコストは指数関数的に増大する。
フォークのシナリオ
| シナリオ | 原因 | 解決 |
|---|---|---|
| 自然フォーク（失効ブロック） | 2人のマイナーがほぼ同じブロック高で有効なブロックを発見し、ネットワークの異なる部分に送信する。 | ネットワークが一時的に分裂する。ノードは累積プルーフ・オブ・ワークが最大のチェーンに従う。敗れたブロックは失効し、そのトランザクションはメモリープールに戻る。 |
| 孤児ブロック | 親ブロックより先にブロックが到着する。ハッシュの連鎖が不完全なため検証できない。 | ノードが一時保存する。親が到着し検証されると、孤児ブロックが再接続される。v27以降基準では「孤児」は親が不明なブロックを特に指し、失効ブロックとは区別される。 |
| 意図的フォーク（ソフト/ハードフォーク） | プロトコルアップグレードが合意規則を変更し、異なるソフトウェアを実行するノードがブロックの有効性について不一致になる。 | ソフトフォーク: 旧ノードは新規則のブロックをなお受理する。ハードフォーク: 一方がフォークを放棄しない限り、チェーンが恒久的に分裂する。 |
チェーン先端争いにブロックが敗れた実例が記録されている。2009年1月、ダスティン・トランメルは採掘した4ブロックが「Generated (not accepted)」と表示されたと報告した。v0.1.0の通信バグにより、勝ち残ったチェーンを争うのに間に合うタイミングで彼のノードがブロックをブロードキャストできなかったためである。
4. チェーン選択規則
ビットコインのチェーン選択規則は最大作業量チェーン規則である。ノードが認識しているすべての有効なチェーンの中から、累積プルーフ・オブ・ワークが最大のチェーンに従う。これは一般に「最長チェーン規則」と呼ばれるが、正確な呼称ではない。チェーンの長さ（ブロック数）とチェーンの作業量は同一ではない。難易度がブロック間で調整される場合、同じ高さの2つのチェーンが異なる総作業量を持ちうる。プロトコルは高さではなく作業量で選択する。
チェーン選択の判定プロセス
コードで言えば、FindMostWorkChain() が常に最初に走り、有効性が確認済みで完全にダウンロード済みのチェーン先端の候補集合（setBlockIndexCandidates）の中からnChainWorkを比較して唯一の最良候補を選ぶ。ActivateBestChainStep() はその候補まで現在の先端から辿り、現在の先端より手前に分岐点があればまずDisconnectTip() で巻き戻し、その後ConnectTip() で勝った分岐のブロックを接続する。「先端を直接延長する」というのは、分岐点がちょうど現在の先端自身になる特殊ケースにすぎず、その場合DisconnectTip() は一度も呼ばれない。
チェーン選択とフォーク解決の比較
| 側面 | チェーン選択 | フォーク解決 |
|---|---|---|
| 契機 | 新規ブロック受信のたびに | 2つ以上の競合するチェーン先端が同時に存在する場合 |
| 指標 | 累積プルーフ・オブ・ワーク (nChainWork) | 同一の指標。フォークはチェーン選択によって解決 |
| 範囲 | 全体的: 既知のすべての有効なチェーンを常に比較 | フォークポイントに局所的: フォークからどの分岐がより多くの作業量を持つか |
| 結果 | ノードの最良チェーン先端が更新される（またはされない） | 一方の分岐が勝利。もう一方は失効。失効分岐のトランザクションはなお有効であればメモリープールに戻る |
| 速度 | 通常1〜2ブロック以内に解決 | 同様。大半の自然フォークは次のブロックが一方の分岐を伸長した時点で解決 |
「最大ブロック数」ではなく「最大作業量」である理由。難易度ターゲットは2,016ブロックごとに調整される。攻撃者が低い難易度でブロックを生成した場合（例: 難易度調整が反映される前の少数派フォーク上で）、それらのブロックのブロック当たりのプルーフ・オブ・ワーク寄与は少ない。ブロック数は少ないがブロック当たりの難易度が高いチェーンがより多くの総作業量を持つ可能性があり、プロトコルはそれを正しく選択する。Bitcoin CoreはこれをnChainWork（各ブロックの作業量寄与を累積する256ビット整数）として追跡する。
5. ブロックサイズと重量
サトシのv0.1には明示的なブロックサイズ上限がなかった。2010年に1 MBの最大ブロックサイズが追加された（当初はスパム対策として）。
SegWit (BIP 141、2017年8月有効化) はバイトサイズの上限を証人データにディスカウントを適用する重量システムに置き換え、後方互換性を保ちつつ最大ブロック容量を実質的に引き上げた。この変更に先立つ数年にわたる論争はブロックサイズ戦争総括で記録されている。
従来のサイズとSegWit重量の比較
| 指標 | 従来型 (SegWit以前) | SegWit (v27以降基準) |
|---|---|---|
| 上限 | 1,000,000バイト (1 MB) ハードキャップ | 4,000,000重量単位 (4 MWU) |
| 計算 | サイズ = 直列化バイト総数 | 重量 = (非証人バイト × 4) + (証人バイト × 1) |
| 実効最大 | ブロックあたり1 MB | 証人と非証人の比率により変動。ブロック774,628（2023年2月）は3,955,272バイト |
| 理論最大 | 1 MB | 約4 MB（ほぼ全体が証人データで構成されるブロック） |
| コインベースのみのブロック | 約250バイト | 約1,000重量単位 |
| 手数料市場への効果 | すべてのバイトがブロック空間内で同一コスト | 証人バイトは75% 安価であり、SegWit採用を促進 |
サトシ時代とv27以降基準の比較。
| 側面 | サトシ時代 | v27以降基準 |
|---|---|---|
| ブロックサイズ上限 | v0.1に明示的上限なし。2010年7月に1 MBをコミット、ブロック79,400（2010年9月）から適用 | 4 MWU重量上限 (BIP 141) に置換 |
| サイズ強制 | MAX_BLOCK_SIZE定数を生バイト数と照合 | MAX_BLOCK_WEIGHTを計算された重量と照合 |
| 証人データ | 存在しない | 1バイトあたり1 WUでディスカウント（非証人は4 WU） |
| 署名操作上限 | v0.1になし; 2010年9月に20,000追加 | ブロックあたり80,000署名操作（重量でスケール）。Tapscriptは異なる計算方法 |
6. コインベーストランザクション
各ブロックの最初のトランザクションはコインベーストランザクションであり、新しいビットコインを作成する唯一のトランザクション型である。以前のUTXOを参照する入力を持たず、代わりにヌルの前トランザクションハッシュと任意のデータフィールドを持つ単一の入力がある。
構造:
- 入力: ヌルprevout（32バイトのゼロ + インデックス
0xFFFFFFFF）、加えてcoinbaseデータフィールド（2〜100バイト）。マイナーはここに任意のデータを書き込める。BIP 34以降、先頭バイトにブロック高を符号化することが必須。 - 出力: ブロック報酬（新規発行分 + 手数料）をマイナーの選択したアドレスに分配する1つ以上の出力。
ブロック報酬スケジュール:
| 半減期 | ブロック | 新規発行分 | 期間 |
|---|---|---|---|
| 0 | 0 – 209,999 | 50 BTC | 2009〜2012年 |
| 1 | 210,000 – 419,999 | 25 BTC | 2012〜2016年 |
| 2 | 420,000 – 629,999 | 12.5 BTC | 2016〜2020年 |
| 3 | 630,000 – 839,999 | 6.25 BTC | 2020〜2024年 |
| 4 | 840,000 – 1,049,999 | 3.125 BTC | 2024〜2028年 |
新規発行分は210,000ブロックごと（約4年ごと）に半減し、漸近的にゼロに近づく。総供給量は20,999,999.9769 BTC（一般に2,100万枚に丸められる）を上限とする。
コインベース成熟。コインベース出力はその上に100ブロックが採掘されるまで支払いに使用できない。この規則はチェーン再編成によりコインベースが無効化され、下流のトランザクションが有効な入力を失う事態から保護する。
注目すべきコインベースデータ。サトシはジェネシスブロックのコインベースにテキストThe Times 03/Jan/2009 Chancellor on brink of second bailout for banksを埋め込んだ。これはタイムズ紙の見出しへの参照であり、タイムスタンプの証明と、ビットコインが迂回するように設計された金融システムに対する声明、その両方として機能する。上記の成熟規則にはただ一つの例外があり、それがこのジェネシスブロック自身のコインベースだ。AddToBlockIndex() 内の分岐処理によりConnectBlock() を一度も通過せず、恒久的に使用不能のままになっている。その仕組みをソースコードレベルで跡付けたのがジェネシスブロックのハードコード分析である。
7. 二時代比較
| 機能 | サトシ時代 (v0.1、2009年1月) | 現行Bitcoin Core、v27以降基準 |
|---|---|---|
| ヘッダー形式 | 80バイト、バージョン1 | 80バイト、同一構造。バージョンフィールドにBIP 9シグナリングビットを搭載 |
| ブロックバージョン | 常に1 | BIP 9バージョンビット（0x20000000基底 + シグナルビット） |
| マークルツリー | 完全に直列化されたトランザクションの単一ツリー | 主ツリー（証人除去トランザクション）+ コインベース内の証人コミットメント |
| チェーン選択 | ブロック高の比較（nBestHeight） | 最大作業量チェーン。nChainWork（256ビット整数）で追跡、v0.3.3以降 |
| ブロックサイズ上限 | v0.1に上限なし。2010年に1 MB追加 | 4 MWU重量上限 (BIP 141) |
| コインベースデータ | 最大100バイトの任意データ | BIP 34: ブロック高プレフィックスが必須。残りバイトは任意 |
| コインベース成熟 | 100ブロック | 同一 |
| 証人コミットメント | 該当なし | コインベースのOP_RETURN出力で証人マークルルートをコミット (BIP 141) |
| 署名操作上限 | v0.1になし; 2010年に20,000追加 | ブロックあたり80,000（重量調整済み）。Tapscriptは異なる計算方法 |
| ブロック中継 | すべてのピアへの完全ブロック送信 | コンパクトブロック (BIP 152): ヘッダー + 短縮トランザクションID。受信ノードがメモリープールから再構築 |
8. 本ページの範囲
本ページはブロック・チェーン層を独立して扱う。以下のトピックは本ページの範囲外であり、設計文書シリーズ内のそれぞれのドメインページで扱う:
- トランザクション構造とUTXOモデル: 各ブロック内のトランザクションがどのように構築、検証、連鎖されるか。トランザクション設計ページで扱う。
- マイニングとプルーフ・オブ・ワーク: 有効なブロックを生成するハッシュパズル、難易度調整アルゴリズム、ブロックテンプレート構築。
- チェーン選択を超えた合意規則: ソフトフォーク有効化メカニズム (BIP 9、BIP 8)、合意形成とポリシーの境界、ブロック有効性規則の全体。
- ネットワーク層のブロック中継:
inv、getdata、headers、block、cmpctblockメッセージがP2Pネットワーク上でブロックを伝播させる仕組み。 - ストレージとチェーン状態: 検証済みブロックのディスクへの永続化方法（ブロックファイル、取消データ）とUTXO集合のLevelDBでの管理方法。
- SPVクライアントの実装: 軽量ウォレットによるマークル証明の実用的な使用（本ページはマークルツリー構造を記述する。SPVプロトコル自体はネットワーク層のトピック）。
ストレージ設計は、このチェーンがどうディスクに書かれるかを扱う。コンセンサス設計は、ここで文書化した構造の上で動く最大作業量チェーン規則を扱う。
