マークルツリーの計算ステップは何か、なぜすべての取引を一度にハッシュするより効率的か？マークルツリーの計算は4つの取引（A、B、C、D）で説明できます。ステップ1、リーフノード：各取引のハッシュ値を個別に計算。ステップ2、中間ノード：隣接する2つのハッシュをペアにして再ハッシュ。ステップ3、ルートノード（マークルルート）：最終レイヤーで繰り返して1つのハッシュのみが残るまで。なぜより効率的か：取引Aがこのブロックにあるかを検証するには、Hash(B)とHash(CD)とルートハッシュだけで3ステップ以内に検証できます。1,000件の取引があっても、任意の取引の検証には約10個のハッシュ値（log₂ 1000）のみが必要です。
マークルツリーのビットコインとイーサリアムでの具体的な応用は何か、どんな違いがあるか？ビットコインでは：各ブロックのブロックヘッダーにTransaction Merkle Rootが含まれます。ビットコインのライトノード（SPVノード）はブロック全体（数MB）でなくブロックヘッダー（約80バイト）のみをダウンロードして、Merkle Proofパスで特定の取引がオンチェーンかを検証できます。イーサリアムでは：より複雑な構造でMerkle Patricia Trie（MPT）の3つのバリアントを使用：Transaction Trie、Receipts Trie、最も重要なState Trie（状態ツリー）。応用の拡張：Proof of Reserves（取引所の準備金証明）がマークルツリーを広く使用しています——取引所はすべてのユーザーのアカウント残高をマークルツリーに入れて、他のユーザーの残高を見せることなくユーザーが総準備金に自分の残高が含まれているかを検証できます。
マークル証明（Merkle Proof）とは何か、どうしてライトノードがブロック全体をダウンロードせずに取引を検証できるか？マークル証明（マークルインクルージョン証明とも呼ばれる）は、特定のブロックに取引が本当に存在することを最小限のデータで証明できる暗号学的ツールです。4つの取引（A、B、C、D）があるブロックで取引Aがブロックにあるかを検証するには：Hash(A)とMerkle Rootを持ちます。ノードはフルノードにMerkle Proofを要求し、フルノードはHash(B)とHash(CD)を返します。Hash(A)とHash(B)からHash(AB)を計算し、Hash(AB)とHash(CD)から再構成されたルートを計算——既知のMerkle Rootと一致すれば取引Aはこのブロックにある。1,000万件の取引があるブロックでも、マークル証明の長さはlog₂(1,000万)≈23個のハッシュ値に過ぎません。
なぜマークルツリーはZKロールアップとProof of Reservesの両方でそんなに重要か？ZKロールアップでは：ZKロールアップの有効性証明は本質的にバッチ取引の実行正確性に関する数学的ステートメントです。このステートメントを構築するにはマークルツリー（具体的にはMerkle Patricia Trieまたは類似の構造）を通じて達成される検証可能な取引集合の要約が必要です。Proof of Reservesでは：FTXの崩壊後、業界は取引所の準備金透明性証明にマークルツリーを広く使い始めました——各ユーザーのアカウント残高をリーフノードとして、すべてのユーザーの残高マークルルートが公開されて任意のユーザーが自分のアカウントが取引所の発表した総準備金に含まれているかをマークルインクルージョン証明で確認できます。
ビットコインのライトノード（SPVウォレット）を使ってマークルツリーの実際の意義を説明しましょう。モバイルのビットコインライトノードウォレット（一部のビットコインウォレットアプリなど）を使用します。このウォレットはビットコインのブロックチェーン全体（600GB以上）をダウンロードせず、ブロックヘッダーのみ（各約80バイト、ビットコイン歴史全体で約60MB）をダウンロードします。特定の取引が確認されたかを確認したい場合、ライトノードウォレットはフルノードにMerkle Proofを要求します。フルノードは約30〜40個のハッシュ値を返し（ブロックに数千件の取引があっても、Merkle証明の長さはlog₂(数千)≈12〜13個のハッシュ値に過ぎない）、あなたのスマートフォンがこれらのハッシュで再構成されたルートが既知のブロックヘッダーと一致するかを確認します。
マークルツリーの核心的なトレードオフは「検証効率」と「更新オーバーヘッド」の間にあります。読み取り効率（特定の取引が存在するかの検証）は非常に高く——ツリー内のデータ量に関わらず、検証にはlog n個のハッシュ値のみが必要です。しかし書き込み/更新のオーバーヘッドはゼロでありません：リーフノードのデータを変更するには、そのノードからルートまでのパス上のすべてのハッシュ値を再計算する必要があります。ビットコインの静的ブロックではこれは問題ありませんが、イーサリアムの状態ツリーは頻繁な更新が必要なため、より複雑なMerkle Patricia Trie（マークルツリーとPatriciaトライの特性を組み合わせたもの）を採用して読み取り効率と更新オーバーヘッドをより良くバランスさせています。