---
title: "マークルツリー"
description: "マークルツリーは単一のルートハッシュで順序付きデータをコミットし、全データを転送せずに簡潔な包含証明を可能にします。"
image: "https://wiki.fcontext.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.
# マークルツリー
> 教育目的に限ります。投資助言ではなく、投資によって損失が生じる可能性があります。
## 直接回答
マークルツリーは各データをハッシュして葉にし、隣接するハッシュを繰り返し結合してマークルルートを作ります。ルートは葉と、構築に使った順序およびハッシュ規則のコンパクトなコミットメントです。
マークル証明は、ある葉について各レベルの兄弟ハッシュを含みます。検証者は葉からルートまでを再計算し、信頼したルートと一致した場合だけ包含を受け入れます。他の葉や全データセットは不要です。
このコミットメントが示すのはデータ表現であり、真実性ではありません。一致するルートだけでは、元データの正確さ、データの可用性、コントラクト・ブリッジ・オラクル・市場の安全性は証明できません。検証者は認証済みプロトコルからルートと葉を取得し、ドメイン分離、順序、奇数葉の規則を理解する必要があります。
マークルツリーは複数の設計で使われます。ビットコインは各ブロックヘッダーに取引のルートを置き、イーサリアムは状態などに修正版マークル・パトリシア・トライを使います。符号化、証明形式、更新規則、安全性の前提は異なるため、証明は互換ではありません。
## 仕組み
まず決定的な葉の符号化とハッシュ関数を定義します。各葉をハッシュし、子のペアを親としてハッシュし、一つのルートになるまで繰り返します。位置を推測できないプロトコルでは、証明に葉の位置または方向も必要です。
平衡二分木では、1024 枚の葉のうち一枚の証明に約 10 個の兄弟ハッシュが必要です。各レベルで対象範囲が倍になるためです。実際のサイズは木の形、ハッシュ長、重複葉の規則、複数証明や圧縮形式に依存します。
基本関係は `parent = Hash(left || right)` および `root = fold(parent, leaves)` と書けます。これは概念図であり、接頭辞、別の分岐数、トライでのキー符号化を使うプロトコルもあります。証明は指定構造との整合性を示しますが、独立に信頼していないルートを認証するものではありません。
ブロックチェーンでは、ルートをブロックヘッダー、状態記録、コントラクトがコミットします。ライトクライアントは葉と認証パスを取得してルートを再計算し、確認、ファイナリティ、鮮度、可用性の規則を適用します。ハッシュ検証だけでこれらの規則を置き換えることはできません。
## 例
1024 件の取引を二分木に入れたブロックを考えます。取引には残りの 1023 件を送らず、約 10 個の兄弟ハッシュを添付できます。検証者には該当ブロックヘッダーと符号化・位置の規則も必要です。
証明が失敗したら、取引がないと判断する前に葉のバイト列、バイト順、パディング、ルートの出所、ブロック状態を調べます。未確定または古いルートの証明は技術的に正しくても、正規チェーンの状態を表さない場合があります。
残高や報酬を表示するアプリでは、証明の有効性と経済的結果を分けて考えます。手数料、価格変動、スリッページ、コントラクト権限、出金制限、データ源の停止が金額を変えることがあります。証明が保証するのはコミットメントへの所属であり、換金可能額ではありません。
## リスク
主な技術リスクは、曖昧な符号化、ハッシュの誤用、第二原像または衝突の弱点、兄弟順序の誤り、信頼できない古いルートの受け入れです。葉と内部ノードのドメイン分離も一貫して実装する必要があります。
運用リスクはハッシュ計算の外側にあります。ブリッジ、オラクル、シーケンサー、取引所、管理者がルートを公開・遅延・検閲・置換できます。可用性障害で葉や証明を取得できず、チェーン再編で古いブロックに結び付いた証明が無効になることもあります。
証明を利用する前に、誰がルートを認証し、鮮度とファイナリティをどう確認し、欠落・奇数葉をどう扱い、ユーザーが独立してデータを復元できるかを確認します。損失上限を定められない場合は、権限とエクスポージャーを制限します。
## よくある誤解
### 誤解 1：一致するルートはデータの真実を証明する
指定構造の下で、提供された葉がコミットされたルートと整合することだけを示します。オラクルが誤った値をコミットすれば、その誤値を正しく検証します。
### 誤解 2：マークル証明でシステム全体が信頼不要になる
検証者はハッシュ、符号化、ルートの認証経路、データ提供システムを依然として信頼します。コンセンサス、ファイナリティ、可用性、ガバナンスは別の問題です。
### 誤解 3：すべてのブロックチェーンが同じマークルツリーを使う
ビットコインの取引木、イーサリアムのトライ、アプリ固有の木は配置と証明規則が異なります。証明形式を別プロトコルへそのまま適用できません。
### 誤解 4：短い証明なら安く安全な取引になる
転送量は減りますが、検証ガス、ストレージ読み出し、混雑、コントラクトのバグ、出金や清算のリスクが結果を左右します。
## 関連トピック
- [ブロックチェーン](/ja/crypto/blockchain/)
- [暗号学的ハッシュ](/ja/crypto/cryptographic-hash/)
- [ライトクライアント](/ja/crypto/light-client/)
- [イーサリアム](/ja/crypto/ethereum/)
- [データ可用性](/ja/crypto/data-availability/)
## 参考資料
- [Blockchain Technology Overview](https://doi.org/10.6028/NIST.IR.8202) - NIST（参照日：2026-08-21）
- [Merkle Trees](https://developer.bitcoin.org/devguide/block_chain.html#merkle-trees) - Bitcoin.org（参照日：2026-08-21）
- [Merkle Patricia Trie](https://ethereum.org/developers/docs/data-structures-and-encoding/patricia-merkle-trie/) - Ethereum Foundation（参照日：2026-08-21）
Source: https://wiki.fcontext.com/ja/crypto/merkle-tree/index.mdx