📘 Academy原文準拠 ｜ Phase 1 · Unit 2 · Lesson 2.2 Blockchain Data Structures 内容に忠実な日本語版です。原文（英語）・図・動画は公式 Academy（外部リンク・別タブで開きます）を正本に。
ブロックチェーンが「どうやって合意して、どうやって安全を保つか」は前のレッスンで見ました。では、たくさんのデータを実際にどう整理して・どう保存しているのでしょう。データ構造を知ることは、建物の設計図を見るのに似ています。バラバラだった部品が組み合わさって、丈夫で信頼できる1つのものになる様子が見えてきます。
ここでは、ブロックチェーンが安全性・効率・検証しやすさを実現するために、データをどんな形にしているかを順に見ていきます。
マークル木（Merkle Trees）
たくさんの取引（数千件）が入った1つのブロックの中に、ある特定の取引が「ちゃんと入っているか」を確かめたいとします。そのために全部をダウンロードして全部チェックしないといけないのでしょうか。マークル木のおかげで、必要なのはほんの数個のハッシュだけです。これがあるから、スマホの軽いウォレットがブロックチェーン全体を持たずに動けます。
マークル木は二分木（binary tree）です。
- すべての葉（leaf）ノード＝1件の取引のハッシュ
- すべての葉でないノード＝その2つの子のハッシュ
- 木のいちばん上の根（マークルルート / Merkle root と呼ぶ）＝すべての取引をたった1個のハッシュで表したもの
たとえば、ある取引（Transaction 2）がブロックに入っていることを示すには、H1・H34・ルートの3個のハッシュがあれば足ります。取引4件を全部見る必要はありません。取引が 10,000件 あるブロックでも、必要なハッシュは約14個だけ。これは約99.86%のデータ削減です。
こうして、スマホは 500GB のブロックチェーンデータを全部落とさなくても、ビットコインの支払いを検証できるのです。
UTXO モデル と 口座モデル（Account Model）
ブロックチェーンは「誰が何を持っているか」を記録する必要があります。そのやり方には、根本から違う2つのアプローチがあります。
UTXO モデル（ビットコイン方式）
UTXO は Unspent Transaction Output（未使用の取引出力）の略です。
UTXO の世界には「残高」という考え方がありません。代わりに、特定のかたまりのビットコインを持ちます。財布の中のお札1枚1枚のようなイメージです。0.5 ビットコインを受け取ったら、それは残高に足し込まれるのではなく、0.5 BTC ぶんの「未使用の出力」が1つできるということです。
誰かに 0.3 BTC を送りたいとき、残高から引き算するわけにはいきません。0.5 BTC の出力をまるごと使い切って、新しい出力を2つ作ります。相手に 0.3 BTC、自分にお釣りとして 0.2 BTC。3ドルのコーヒーを5ドル札で払う、あの感じとまったく同じです。
ウォレットは、この見えない「お札」を常にやりくりしています。大きな支払いには小さいお札をまとめ、お釣りが必要なら大きいお札を崩す。ビットコインの取引でたまにへんな端数になるのは、ウォレットが「ちょうどの金額」ではなく「手持ちの UTXO」で組み立てているからです。
長所はいろいろあります。たとえばプライバシーが高い（取引どうしを結びつけにくい）こと、自然に並列化できる（ロックすべき口座が存在しない）こと。短所は、スマートコントラクトの実装がとても大変になること、ウォレットがバラバラのかたまりを全部追いかける必要があることです。
口座モデル（イーサリアム方式）
こちらは、みんなが思い浮かべるとおりのやり方です。各アドレスが残高（balance）を持ち、受け取れば増え、送れば減ります。ふだんの銀行口座とまったく同じ感覚です。
理解しやすいので、イーサリアムはこちらを選びました。スマートコントラクトとも相性がよく、残高を直接チェックして更新するだけで済みます。ただし、同じ口座に複数の取引が同時に来るとボトルネックになります。また、すべてが1つの続く残高に結びつくため、プライバシーは難しくなります。
UTXO と口座モデルの違いが分かると、なぜビットコインは複雑な処理だとぎこちないのに単純な送金は得意で、逆にイーサリアムはスマートコントラクトが書きやすいのに単純な送金が高くつくのか、その理由が見えてきます。
state tree と取引プール（mempool）
state tree（状態の木）
ブロックチェーンが保存するのが歴史（history）だとすると、state tree（状態の木）が保存するのは今この瞬間の状態です。たとえば、すべての口座の残高や、スマートコントラクトのデータなど。多くの最近のブロックチェーンは Patricia Merkle Tree（キーと値の保存に最適化した、ちょっと豪華なマークル木）を使います。
これにより、ノードは「Alice の今の残高はいくら？」という問いに、genesis（最初のブロック）からの全取引を再生し直さなくても即座に答えられます。スマホが、イーサリアムの状態すべてを落とさなくても特定のデータだけ検証できるのも、この仕組みのおかげです。
取引プール（mempool）
取引はブロックに入る前、いったん宙ぶらりんの待機場所＝mempoolで待ちます。これは「順番待ちの待合室」で、まだ確定していない取引が「選ばれますように」と待っている場所です。
マイナーやバリデータは、人気クラブの入口に立つ用心棒のようなもの。次のような基準で取引を選びます。
- 手数料（fee）の大きさ：手数料が高いほど、列の前に行ける
- 取引のサイズ：小さい取引ほど、1ブロックにたくさん詰められる
- 古さ（age）：低い手数料の取引でも、いずれは選ばれる（飢餓＝starvation を防ぐため）
混雑時に手数料が跳ね上がるのはこのためです。あなたは「ネットワークにお金を払っている」のではなく、限られたブロックの空きをめぐって他の人と競り合っているのです。賞品は「自分の取引が確定すること」、それを奪い合うオークションだと思ってください。
ここはまた MEV が起きる場所でもあります。バリデータが取引の順番を並べ替えて利益を抜き取る現象です。ただ、これは別のレッスンで掘り下げる深い穴（rabbit hole）です。
ブロックはどうデータを保存するか
ブロックは「取引をただ積み上げた山」ではありません。書類整理用のキャビネットのような構造になっています。
ヘッダーにはマークルルートが入っています。だから、小さなヘッダーとマークル証明（Merkle proof）さえあれば、「ある取引がそのブロックに属している」ことを検証できるのです。
全部を組み合わせると
これらのデータ構造は、こんなふうに連携して働きます。
- 取引が mempool に入る
- マイナー／バリデータが取引を選び、マークル木を作る
- マークルルートがブロックヘッダーに入る
- ブロックが state tree（口座残高）を更新する
- そのブロックのハッシュが次のブロックにつながり、チェーンができる
それぞれの構造が1つの役割を担い、組み合わさることで、安全で・検証でき・スマホからデータセンターまで動くほど効率的なシステムが生まれます。スイスの時計のように、どの部品にも1つの仕事があり、それを完璧にこなし、合わさると「ちゃんと動く」何かになる、というわけです。
開発者として押さえる点
- マークル木＝二分木。葉が取引ハッシュ、根が Merkle root。証明には全件でなく少数のハッシュだけ（1万件でも約14個）。軽量クライアントの土台
- UTXO（残高なし・お札型・並列化＆プライバシーに有利・契約は大変）と口座モデル（残高型・契約は簡単・同一口座で詰まりやすい）の根本的な違いを理解する
- state tree（多くは Patricia Merkle Tree）＝今の状態を保持し、genesis から再生せずに残高などを即答できる。history（歴史）とは別物
- mempool＝確定前の待合室。採用基準は fee / サイズ / age。混雑時の手数料高騰は「空きスペースの競り（オークション）」。順序操作で利益を抜くのが MEV
- ブロック＝ヘッダー（約80バイト・Merkle root を含む）＋ボディ（取引）＋メタデータ。ヘッダー＋Merkle proof だけで取引の所属を検証できる
やさしい版・公式へ
- やさしい版：ZKの部品箱（マークル木やハッシュが ZK でどう使われるか）
- 公式：Academy Courses（外部リンク・別タブで開きます）（Phase 1 / Unit 2 / 2.2 Blockchain Data Structures）
- 関連 docs：Midnight の概要（外部リンク・別タブで開きます） ／ Compact リファレンス（外部リンク・別タブで開きます）（マークル木やハッシュは Compact 側でも登場します）
つぎに読むページ
➡️ 原文準拠コースの入口へ戻る。このコースについて（次のレッスンは順次追加します）