分散台帳とブロック構造
ブロックのヘッダ・ボディ・ハッシュリンク構造、Merkle 木・SPV・Merkle Patricia Trie、台帳タイプ(permissionless / permissioned / consortium)、world state と UTXO セットの状態モデルを体系化。
article technology ja ブロックのヘッダ・ボディ・ハッシュリンク構造、Merkle 木・SPV・Merkle Patricia Trie、台帳タイプ(permissionless / permissioned / consortium)、world state と UTXO セットの状態モデルを体系化。分散台帳とブロック構造
ブロックチェーンの「不変性」と「検証可能性」は、ブロックのハッシュリンク構造と Merkle 木という二種類のデータ構造によって実現されている。本記事は、ブロックの物理的構造(ヘッダ / ボディ / prev-hash チェーン)・Merkle 木の原理と応用(SPV / Ethereum の Merkle Patricia Trie)・台帳タイプの分類(permissionless vs permissioned)・状態モデル(world state と UTXO セット)を体系化する。コンセンサスの理論基盤は tech-203、トランザクションの処理モデルは tech-211 を参照。情報カットオフ ~2025-08、confidence: medium 固定(2026-06 時点での外部再検証は未実施)。
ブロックの物理構造 — ヘッダ・ボディ・ハッシュリンク
一つのブロックはヘッダとボディに分かれる。ボディはトランザクションのリストを格納し、ヘッダはブロック全体を識別し前後のブロックと接続するための制御情報を持つ。
ブロックヘッダの主要フィールド(Bitcoin / Ethereum 共通概念):
| フィールド | 役割 |
|---|---|
prev_hash | 直前ブロックのヘッダハッシュ。チェーンを形成する核心フィールド |
merkle_root | ボディ内の全トランザクションを Merkle 木で集約したルートハッシュ |
timestamp | ブロック生成時刻(UNIX epoch) |
difficulty / bits | PoW 難易度ターゲット(Bitcoin)またはブロック構成の複雑度メタデータ |
nonce | PoW で有効なハッシュを探すためのカウンタ(Bitcoin: 32 bit) |
state_root | 全アカウント状態を格納する Merkle Patricia Trie のルート(Ethereum 固有) |
receipts_root | トランザクションレシート(ガス消費・ログ)の Merkle ルート(Ethereum) |
ハッシュリンクによる改ざん検知: 各ブロックヘッダには直前ブロックのヘッダハッシュ(prev_hash)が埋め込まれる。あるブロックを改ざんすると、そのブロックのハッシュ値が変わり、後続ブロックが参照する prev_hash と不一致になる。結果として「改ざんされたブロック以降のすべてのブロック」を再計算しなければ整合性が取れなくなる。これがチェーンとしての改ざん困難性の物理的根拠であり、ブロックチェーン全体の信頼性の土台だ。
Merkle 木 — 包含証明と軽量クライアント
Merkle 木(ハッシュ木)はブロックチェーンにおける「コンパクトな検証」の基盤技術だ。全トランザクション(リーフ)を底辺に置き、隣接するペアを再帰的にハッシュして一本のMerkle root(ルートハッシュ)に圧縮する。Merkle 木についての詳細な比較分析は tech-27 で論じている。
包含証明(Merkle proof): あるトランザクション T がブロック内に存在することを証明するには、T からルートまでの「兄弟ハッシュのパス」だけで十分だ。全トランザクションを保持せずとも O(log n) 個のハッシュで検証できる。これがブロックチェーンの軽量検証を可能にする仕組みの核心だ。
SPV(Simplified Payment Verification): Bitcoin ホワイトペーパーで提案された軽量クライアント方式。モバイルウォレット等がブロック全体をダウンロードせず、ブロックヘッダ列(PoW の蓄積)と Merkle proof だけで「自分宛てのトランザクションが確かに採掘されたブロックに含まれる」ことを検証できる。フルノードへの信頼が不要という点でブロックチェーンの自己検証性を体現している。
Merkle Patricia Trie(MPT)— Ethereum の状態管理: Ethereum はシンプルな Merkle 木を拡張した MPT を採用する。Patricia(Radix)Trie で key-value の探索効率を上げ、ハッシュリンクで改ざん耐性を持たせた構造だ。アカウントアドレス(鍵)→ アカウント状態(値:残高・nonce・コードハッシュ・ストレージルート)を格納する state trie のルートが state_root としてブロックヘッダに埋め込まれる。同様の MPT がトランザクション trie・レシート trie にも使われる。MPT により Ethereum は「特定アカウントの残高を light node が証明付きで確認できる」という性質を持つ。
台帳タイプの分類 — permissionless / permissioned / public / private
台帳の設計空間は「参加資格」と「データ公開範囲」の二軸で整理できる。
参加資格軸:
- Permissionless(無許可型): 誰でもノードを立て、バリデータとして参加できる。Bitcoin・Ethereum が代表例。Sybil 耐性はコンセンサス自体(PoW・PoS)が担保する。匿名参加が可能なため検閲耐性が高い。
- Permissioned(許可型): 参加には管理者の認証が必要。Hyperledger Fabric・R3 Corda が代表例。参加者が信頼できる前提で、コンセンサスは軽量 BFT(PBFT 変形等)を採用できる。スループットが高く最終性が確定的だが、参加者の信頼モデルが必要。
データ公開範囲軸:
- Public: トランザクションデータを全員が閲覧できる(Bitcoin・Ethereum)
- Private: データアクセスを参加者に限定(Hyperledger Fabric の Channel 機能等)
- Consortium: 複数企業・組織が共同運営し、外部からのアクセスを制限(金融コンソーシアム型 DLT)
この二軸を組み合わせると「Public Permissionless(Bitcoin・Ethereum)」「Public Permissioned(一部金融 DLT)」「Private Permissioned(Hyperledger Fabric)」「Private Consortium Permissioned(R3 Corda)」の 4 象限になる。どの象限を選ぶかは信頼モデルとガバナンス要件によって決まる。
状態モデル — World State と UTXO セット
ブロックチェーンが「現在のネットワーク状態」を表現する方法は大きく二つある。詳細は tech-211 で論じており、ここでは構造と台帳との関係を概説する。
World State(Ethereum アカウントモデル): アカウントアドレスを鍵、アカウント状態(残高・nonce・コードハッシュ・ストレージルート)を値とする key-value ストア。ブロックを適用するたびに world state が更新され、その MPT のルートが state_root としてブロックヘッダに記録される。「現在の状態」が常に最新ブロックの state_root に対応するため、ノードはヘッダを検証するだけで状態の整合性を確認できる。スマートコントラクトのストレージも個別の MPT として管理され、そのルートがアカウント状態の一部となっている。
UTXO セット(Bitcoin): 「未使用トランザクション出力(Unspent Transaction Output)」の全集合が現在の状態を表す。アカウントの「残高」は概念的には存在せず、ウォレットは自分が所有する UTXO を合算して残高を計算する。UTXO セット全体は Bitcoin の全フルノードが保持するが、ブロックヘッダに直接 UTXO 集合のルートハッシュは埋め込まれない(Bitcoin Core は内部で UTXO コミットメントを管理するが、標準ヘッダフィールドではない)。UTXO モデルはステートレスな並列検証を可能にし、プライバシー的にもアカウントモデルより有利だ。
ブロックサイズとスループットのトレードオフ
ブロックサイズ(または gas limit)はトランザクション処理量とネットワーク分散性のトレードオフを決める重要なパラメータだ。ブロックが大きいほど一度に処理できるトランザクションが増えるが、ブロック伝播に時間がかかりオーファンブロック率が上昇する(ネットワーク詳細は tech-210 参照)。Bitcoin は 2017 年の SegWit により実質ブロック容量を約 2〜4 MB 相当に拡大した。Ethereum は各ブロックの gas limit を徐々に引き上げており、2025 年時点では約 3,000 万 gas / ブロックを標準とし、EIP-4844 が blob データのオフチェーン格納を導入して L2 コストを大幅に削減した。これらの最適化は blockchain トリレンマ(tech-203)の現実的な緩和策として位置づけられる。
Backlinks
- has_parts Layer-1 Blockchains(L1 チェーン総覧)
- related ブロックチェーンの暗号技術
- related ブロックチェーンのネットワークとノード
- related トランザクションモデル(UTXO と Account)