---
title: "Verkle ツリー"
description: "Verkle ツリーは多分岐木とベクトルコミットメントを組み合わせ、小さな状態 witness を実現する一方、証明・移行・暗号面のトレードオフを伴います。"
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.
# Verkle ツリー
> 教育目的に限ります。投資助言ではなく、投資では損失が生じる可能性があります。
## 要点
Verkle ツリーは、内部ノードにベクトルコミットメントを使う認証付きキー・バリュー木です。名称は「vector commitment」と「Merkle tree」の合成語です。多数の値を1つのルートにコミットしつつ、通常のハッシュ型 Merkle ツリーと違い、全 sibling 値を示さずに指定位置の子を証明できます。
この性質により多分岐化と複数 opening の集約が可能になり、状態 witness を同等の Merkle-Patricia Trie より小さくできます。ただし witness には、実行に必要な値と、それを認証済み状態ルートへ結び付ける暗号学的証拠が必要です。
小さな witness により、ノードは現在状態全体を保持せず、ブロックに添付された witness で再実行できます。「stateless」は誰も状態を保存しない、または consensus が不要という意味ではありません。2026-08-22 時点で Ethereum のロードマップはテストネットと未完のクライアント作業を挙げ、EIP-6800 は Stagnant です。
## 仕組み
プロトコルは決定的なキー・値エンコード、ベクトルコミットメント方式、空ノード規則を定めます。各内部ノードが順序付き子ベクトルにコミットし、上へ繰り返して位置と内容を拘束するルートを作ります。
証明者は各階層の該当位置を opening します。複数キーでは multiproof が opening を集約し共有経路を再利用できます。検証者はキー、値、経路コミットメント、証明を受け取り、信頼するルートに照合してから状態遷移を検証します。
EIP-6800 の設計では 32-byte キーを 31-byte stem と 1-byte suffix に分け、内部ノード幅を 256 とします。同じ stem の値は証明材料を共有できます。これは提案固有の配置です。幅を広げると経路は短くなりますが、楕円曲線演算と事前計算が増えます。
## 例
1つの 31-byte stem に 256 個の suffix 位置があるとします。同じ stem の 2 値を読むブロックは、2 組の独立した Merkle sibling hash の代わりに共有経路と集約 opening を使えます。それでも検証者は両キー、両値、証明、プロトコルが選んだルートを確認します。
値が変わると suffix グループのコミットメントからルートまで更新が必要です。旧ルートの証明は旧状態には正しくても新ルートを証明しません。削減量はアクセス形態次第であり、小さな証明は帯域、証明コスト、データ可用性をゼロにはしません。
## リスク
実装ミスは binding を壊すか、正しい証明を拒否させます。キー導出、byte order、位置 binding、domain separation、曲線点検証、scalar 変換、空と保存済みゼロの区別を、test vector とクライアント間試験で一致させる必要があります。
小さな証明はデータ可用性や liveness を解決しません。提案者が値や witness を隠せば実行できず、ルート認証や finality の誤りは誤った履歴を受け入れさせます。証明生成が資源ボトルネックや censorship 点になる場合もあります。
稼働中チェーンの移行は状態配置、同期、証明形式、データベース、Gas 計算、履歴証明の前提を変えます。提案や devnet は本番準備完了の証明ではありません。関連する楕円曲線コミットメントは一般に post-quantum secure とみなされず、小ささは全脅威モデルでの強さを意味しません。
## よくある誤解
### 誤解 1: Verkle ツリーは子が多い Merkle ツリーにすぎない
短い経路だけでなく、全 sibling を列挙せず選んだ子を opening できるベクトルコミットメントが本質です。
### 誤解 2: どんな workload でも証明全体は一定サイズである
opening は小さく集約できますが、witness はアクセス値、別経路、metadata に応じて増えます。
### 誤解 3: stateless 検証では誰も状態を保存しない
完全なローカル状態の代わりに witness で検証できるだけで、誰かが状態を保持または再構築して配信します。
### 誤解 4: Ethereum mainnet は既に Verkle ツリーを使う
資料は研究・仕様・テストネットを説明しており、事実確認日時点で EIP-6800 は Stagnant です。
## 関連トピック
- [Merkle ツリー](/ja/crypto/merkle-tree/)
- [ライトクライアント](/ja/crypto/light-client/)
- [状態ルート](/ja/crypto/state-root/)
- [Ethereum](/ja/crypto/ethereum/)
- [データ可用性](/ja/crypto/data-availability/)
## 出典
- [Verkle Trees](https://math.mit.edu/research/highschool/primes/materials/2018/Kuszmaul.pdf) - MIT PRIMES (参照日: 2026-08-22)
- [EIP-6800: Ethereum state using a unified verkle tree](https://eips.ethereum.org/EIPS/eip-6800) - Ethereum Improvement Proposals (参照日: 2026-08-22)
- [Verkle tree structure](https://blog.ethereum.org/2021/12/02/verkle-tree-structure) - Ethereum Foundation (参照日: 2026-08-22)
- [Verkle trees](https://ethereum.org/roadmap/verkle-trees/) - Ethereum.org (参照日: 2026-08-22)
Source: https://wiki.fcontext.com/ja/crypto/verkle-tree/index.mdx