ビットコインの​ストレージ設計 — ブロック​データベース、​UTXOセット、​チェーン状態管理

はじめに

本ページは設計文書シリーズのL1 #7「ストレージ設計」である。ストレージ層を扱う: Bitcoin Coreノードが検証済みデータをディスクにどう永続化するか、使用可能なコインをメモリーとディスク上でどう追跡するか、状態をどう復旧またはブートストラップするか。

トランザクション設計ページではUTXOとは何かを説明した。ブロックとチェーン設計ページではブロックがチェーンにどう連結されるかを説明した。本ページは一段階下に移る: これらの抽象概念を耐久的かつ検索可能にするディスク上およびメモリー内の構造。

4つの設問が内容を構成する:

1. ブロックはどこに保存されるか? ディスク上のフラットファイル（blk*.dat）に保存され、再編成を可能にする付随の取り消しファイル（rev*.dat）を伴う。
2. UTXOセットはどこにあるか? LevelDBデータベース（コインデータベース）に置かれ、パフォーマンスのためにメモリー内にライトバックキャッシュを持つ。
3. ノードはブロックをどう素早く見つけるか? ブロックハッシュをファイル位置にマッピングするLevelDBブロックインデックスを通じて。
4. ノードはすべてを永久に保存することをどう回避するか? 剪定（古いブロックファイルの破棄）とassumeUTXO（信頼されたUTXOスナップショットからのブートストラップ）によって。

サトシ時代の実装（v0.1、2009年1月）と現代のBitcoin Core（v27以降を基準）で挙動が異なる箇所は、双方を記載する。

1. ストレージアーキテクチャの概要

以下の図はフルノード内部のすべての永続データストアとそれらの間のデータフローを示す。

2. ブロックファイル

検証済みブロックは、データディレクトリのblocks/ サブディレクトリに保存されるblk00000.dat、blk00001.dat等の名前の一連のフラットバイナリーファイルに順次書き込まれる。各ファイルは新しいファイルが開かれるまでにおよそ128 MiBまでの生のブロックデータを保持する。

ブロックファイルのレイアウト

ファイル内の各ブロックエントリーは、4バイトのネットワークマジックナンバー（メインネット・テストネット等、ネットワークを識別する）で始まり、4バイトのリトルエンディアンサイズフィールドが続き、その後に完全なシリアライズされたブロック（ヘッダー + トランザクション + 証人データ）が格納される。v0.1の直列化境界を扱う分析は、このマジックナンバーとサイズによる枠組みを元のソースのCBlock::WriteToDiskまで遡っている。この枠組みは以来変わっていないが、Bitcoin Core 28.0からは、ブロックのディレクトリに置いた鍵で、ファイルがディスク上で既定でXORされる。

取り消しファイル (rev*.dat)

各ブロックファイルblk0NNNN.datに対して、対応するrev0NNNN.datが存在する。取り消しファイルは、対応するブロック内のすべてのトランザクションが消費したすべてのUTXOの以前の状態を保存する。このデータはチェーン再編成時のブロックの切断に不可欠である: ノードは使用されたUTXOを復元し、作成されたUTXOを除去しなければならない。

取り消しデータがなければ、再編成にはジェネシスブロックからチェーン全体を再検証する必要があり、現代のハードウェアでも数時間を要する作業になる。

3. UTXOセット（コインデータベース）

UTXOセットはBitcoin Coreで最もパフォーマンスが重要なデータ構造である。すべてのトランザクション検証において、参照された入力が存在し未使用であるかの検索が必要となる。コインデータベースはchainstate/ サブディレクトリにあるLevelDBキーバリューストアにすべての未使用トランザクション出力を格納する。

UTXO検索フロー

キーバリュー構造

コインデータベースの各エントリーはアウトポイント（トランザクションハッシュ + 出力インデックス）をキーとし、コインのサトシ単位の額面、作成されたブロック高、コインベース出力かどうか、出力のロックスクリプトを保存する。

コインキャッシュ

トランザクション入力ごとにディスク上のLevelDBから読み取るのでは遅すぎる。Bitcoin Coreは読み取りを吸収し書き込みをバッチ処理するメモリー内ライトバックキャッシュ（コインキャッシュ）を維持する。ブロックが接続されると、使用済みコインはキャッシュ内で消費済みとマークされ、新しいコインが追加される。蓄積された変更は、定期的に、あるいはキャッシュがサイズ上限に達した時点で、ディスク上のLevelDBへ単一のバッチ書き込みとしてフラッシュされる。

初期ブロックダウンロード（IBD）のパフォーマンス。IBD中、ノードは数十万のブロックを連続して高速に処理する。-dbcacheを大きく設定する（例: 4096 MiB以上）と、UTXOセットのより多くの部分がメモリーに保持され、ディスク読み取りとバッチ書き込み頻度が最小化されるため、IBD時間が劇的に短縮される。

4. ブロックインデックス

ブロックインデックスはblocks/index/ に保存される独立したLevelDBデータベースで、古くなったブランチのものも含め、ノードがこれまでに受信したすべてのブロックヘッダーのカタログとして機能する。各ブロックハッシュに対して、インデックスは以下を保存する:

ブロック取得パス

ブロックインデックスにより、ノードはフラットファイルを走査することなくハッシュで任意のブロックを特定できる。また、チェーン選択に必要なデータも提供する: ノードはディスクからフルブロックを読み込まずに、ブランチ先端間でnChainWork値を比較して最も仕事量の多いチェーンを判定できる。

5. メモリープールストレージ

メモリープールは、検証とポリシーチェックに合格したがまだブロックに掲載されていない未承認トランザクションのメモリー内プールである。合意形成データベースには永続化されず、各ノードが独立に維持するローカルで一時的な構造である。

メモリープールのライフサイクル

ネットワークまたはウォレットから到着したトランザクションは、まずポリシー検査と合意検証を通過してからメモリープールに受理される。どちらかの検査に失敗すれば、受理される前に破棄される。

メモリープールと合意形成。メモリープールはポリシーレベルの構造であり、合意形成レベルのものではない。2つのノードが全く異なるメモリープールを持っていても、どのブロックが有効かについては合意できる。トランザクションがメモリープールに存在しても、ブロックへの掲載が保証されるわけではない。意味するのは、ローカルノードがそれを有効と見なし、中継する意思があることだけである。

6. 剪定

フルアーカイブノードはこれまでに生成されたすべてのブロックを保存しており、2026年10月に約774 GBで、その前の2年はそれぞれ約80 GBずつ増えた。剪定により、ノードは古いブロックファイルと取り消しファイルを破棄しつつ、完全なUTXOセットと新規ブロック検証能力を保持できる。

要点。剪定ノードはフル検証ノードである。アーカイブノードとまったく同じように、すべての新規ブロックにすべての合意規則を適用する。唯一失われる能力は、初期ブロックダウンロードを行うピアに古いブロックを提供することである。剪定は -prune=<MiB>（最小550）で設定する。

7. assumeUTXO

ジェネシスブロックから現在のチップまですべてのブロックを検証する初期ブロックダウンロード（IBD）は、ハードウェアとネットワーク速度に応じて数時間から1日以上かかる。assumeUTXO（loadtxoutset RPCはv26.0で導入; メインネットのスナップショットパラメーター（高さ840,000）はv28.0で追加）は代替のブートストラップパスを提供する: ノードは事前計算されたUTXOスナップショットを読み込み、スナップショット高から即座に新規ブロックの検証を開始し、バックグラウンドで完全な過去のチェーンを検証する。

assumeUTXOのブートストラッププロセス

信頼モデル

assumeUTXOは合意規則を変更しない。検証が行われる順序を変更する: 新規ブロックが最初（即座に有用）、過去のブロックが二番目（バックグラウンド検証）。最終状態は従来のIBDを実行したノードと同一である。

8. 二つの時代の比較

BDB → LevelDB移行（v0.8、2013年3月）。サトシのオリジナル実装は、トランザクションインデックスとUTXO状態を単一のBerkeley DBデータベースに保存していた。ただし生のブロックデータはその対象になく、当初からフラットファイル（blk*.dat）に置かれていた。この選択について、サトシは2009年1月に初期ユーザーへ直接説明していた。「トランザクション対応のデータベースDBMに保存されているから、クラッシュや停電が起きても失われないはずだ」と。チェーンの成長に伴い、BDBのロック制限とメモリー特性がボトルネックとなった。v0.8リリースはUTXOセットとブロックインデックスのBDBをLevelDBに置き換えた。ブロックデータはv0.1以来使われてきたフラットファイル形式のままだった。

この移行は事件を伴った: 2013年3月11日、v0.7（BDB）を実行するノードとv0.8（LevelDB）を実行するノードが、LevelDBにはないBDBのロックカウント制限に起因してブロックの有効性について不一致となり、合意形成の分裂フォークが発生した。フォークはマイナーの協調行動により、長いv0.8チェーンを放棄する形で解決された。

9. 本ページの範囲

本ページはストレージ層を単独で扱う。以下のトピックは範囲外であり、設計文書シリーズ内のそれぞれの専門ページで扱う:

• トランザクション構造とUTXOモデル — UTXOがどう作成、使用、検証されるか。トランザクション設計ページで扱う。
• ブロック構造とチェーン選択 — ブロックがどう構成され、最も仕事量の多いチェーンがどう選択されるか。ブロックとチェーン設計ページで扱う。
• 合意規則 — ブロックがストレージ層に到達する前に受け入れるかどうかを決定する検証規則。合意形成設計ページで扱う。
• ネットワーク層のブロックリレー — ブロックがディスクに書き込まれる前にノード間でどう伝送されるか。P2Pネットワーク設計ページで扱う。
• ウォレットストレージ — 鍵導出、記述子データベース、ウォレットバックアップはここで記述した合意データとは別のストレージパスを使用する。ウォレット設計ページで扱う。