イーサリアムの Hegotá フォーク：Verkle Tree がノードストレージを 90 % 削減し、ステートレスクライアントを実現する方法
2026 年にイーサリアム・フルノードを運用するには、4～8 TB の NVMe SSD ストレージ、32～64 GB の RAM、そして最新の 8 コア CPU が必要になります。このハードウェアコストはホビーユーザーを排除し、バリデーターの権限を資金力のあるオペレーターに集中させ、ネットワーク全体の存在意義である分散化の約束を静かに損なっています。2026 年後半に予定されている Hegotá（ヘゴタ）ハードフォークは、15 年前のメルクル・パトリシア・トライ（Merkle Patricia Trie）を、ノードのストレージ要件を最大 90% 削減し、「ステートレス」なイーサリアム・クライアントを初めて本番環境で実現可能にする暗号データ構造「Verkle Trees（バークル・ツリー）」に置き換えることで、この状況を変えようとしています。
イーサリアムがもはや無視できないステート肥大化の問題
イーサリアムの「ステート（状態）」——すべての口座残高、コントラクトのストレージスロット、ナンスの完全な記録——は 200 GB を超えて膨れ上がり、Geth におけるフルチェーンデータ（履歴を含む）は現在 3 TB を超えています。アーカイブノードには 18～20 TB が必要です。すべてのトランザクションがこの負担を増大させますが、現在のアーキテクチャにはそれを削減する仕組みがありません。
その影響は数字に表れています。2026 年初頭の時点で、Etherscan は世界中に約 14,339 のフルノードを検出しています。そのうち米国が 38.96%、ドイツが 14.53%、中国が 14.01% を占めています。自宅で運用されるノードは前年比で 18% 増加しましたが、参入障壁は上がり続けています。2022 年に 2 TB の SSD を購入したソロステーカーは、すでにアップグレードを余儀なくされるか、運用を断念せざるを得ない状況にあります。
これはイーサリアムのロードマップにおける「Verge（バージ）」フェーズが解決すべき課題であり、Verkle Trees はその技術的な中心要素です。
Verkle Trees が実際に変えるもの
根本的な部分では、Verkle Tree は現在のイーサリアムのメルクル・パトリシア・トライに似ています。どちらも、各ノードが空であるか、リーフ（キーと値のペアを保持）、または子を持つ中間ノードであるツリー状のデータ構造です。決定的な違いは、データがツリー内に存在することを証明する方法にあります。
メルクル・パトリシア・トライ（Merkle Patricia Trees） は、ハッシュベースのプルーフ（証明）を使用します。一つの値を証明するには、リーフからルートまでのパスに沿ったすべての兄弟ノード（「シスターノード」の完全なセット）を提供する必要があります。イーサリアムの 16 分岐（hexary）トライでは、プルーフサイズは 1 回につき約 150 KB になります。ステートが大きくなるにつれ、これらのプルーフはより重くなります。
バークル・ツリー（Verkle Trees） は、多項式暗号に基づくベクトル・コミットメントを使用します。各兄弟を個別にハッシュ化する代わりに、証明者はパス全体のすべての親子関係をカバーする単一のコンパクトな証明を生成します。提案されているイーサリアムの実装では 256 分岐を使用しており（一部の研究者は 1,024 分岐を提唱）、これによりツリーが浅くなり、プルーフが劇的に小さくなります。
その差は歴然です：
| 指標 | メルクル・パトリシア・トライ | バークル・ツリー |
|---|---|---|
| 値あたりのプルーフサイズ | 約 150 KB | 約 1-2 KB |
| ブロックのウィットネスデータ | 数メガバイト | 数キロバイト |
| ツリーの幅 | 16 (hexary) | 256 |
| プルーフ構造 | すべての兄弟ノードのハッシュ | 単一の多項式コミットメント |
Verkle Tree を使えば、10 億個のデータポイントを持つツリーのメンバーシップを 150 バイト未満で証明できます。現在のシステムでは理想的な条件でも約 1 KB 必要であり、イーサリアムのパトリシア・トライは理想とは程遠い状態です。
ステートレス・クライアント：最終目標
本当のメリットは、プルーフが小さくなることだけではありません。それは「ステートレス検証（stateless validation）」の実現です。
今日、すべてのイーサリアム・フルノードは、完全なステート・トライをダウンロード、保存、維持する必要があります。新しいブロックが届くと、ノードはローカルにあるステートのコピーに対してすべてのトランザクションを再実行し、正当性を検証します。ステートがなければ、検証はできません。
Verkle Trees はこの方程式を変えます。プルーフがブロック内に含められるほどコンパクトであるため、「ステートレス・クライアント」は、ステートを一切保存することなく、添付された Verkle プルーフをチェックするだけでブロックを検証できます。バリデーターはブロックを受け取り、ルート・コミットメントに対してプルーフを照合し、数ミリ秒で正当性を確認します。
これが実務面で意味すること：
- バリデーターのストレージがほぼゼロに: ステーキングノードは最小限のディスク容量（おそらく 1 GB 未満）で運用可能になります。
- インスタント同期: 新規ノードは 200 GB 以上のステートをダウンロードする必要がありません。ブロックが届いた瞬間に検証を開始できます。
- 参加者の拡大: ハードウェアの壁が「専用サーバー」から「帯域幅の広い Raspberry Pi」レベルにまで下がります。
- 分散化の強化: ノードが増えることは、地理的な分散、クライアントの多様性、そして検閲に対する耐性が高まることを意味します。
ヴィタリック・ブテリン（Vitalik Buterin）氏は、Verkle Trees を「ほぼ瞬時の同期を実現するステートレス・バリデーター・クライアント」を可能にする鍵であると説明しています。このビジョンが実現すれば、イーサリアムのバリデーターノードの運用は、ブロックごとに数キロバイトのデータをチェックするのと同じくらい簡単になるかもしれません。
避けて通れない量子コンピューティングの問題
誰もが Verkle Trees の導入に賛成しているわけではありません。最も深刻な反対意見は、量子コンピューティングのコミュニティから出ています。
Verkle Trees は楕円曲線ベースの多項式コミットメントに依存しています。これは、ショアのアルゴリズム（Shor's algorithm）を実行する量子コンピュータが理論的に突破できる暗号のクラスと同じです。もし今後 10 年以内に十分に強力な量子コンピュータが登場すれば、イーサリアム上のすべての Verkle プルーフは信頼できなくなり、ネットワークはさらなる移行を余儀なくされます。
この懸念は、イーサリアムの開発者コミュニティ内で 2 つの陣営による活発な議論を引き起こしています。
今すぐ Verkle Trees を導入すべき。 メリットは即座に得られ、十分に理解されています。楕円曲線暗号を破ることができる量子コンピュータの登場は、10～15 年先になる可能性が高いです。イーサリアムは今 Verkle Trees を採用し、後で耐量子構造に移行すればよいという考えです。
STARK 化されたバイナリ・ハッシュ・ツリーへ直接移行すべき。 EIP-7864 は、現在のトライを効率的なハッシュ関数（Blake3 または Poseidon）を使用したバイナリツリーに置き換えることを提案しています。STARK プルーフと組み合わせることで、このアプローチは初日から耐量子性を備えることになります。バイナリツリーは、今日の構造よりも 4 倍短いメルクルブランチを生成し、ハッシュ関数の変更によって証明効率がさらに 3～100 倍向上する可能性があります。
現実的な妥協案であり、現在の方向性は、量子コンピューティングの進展と STARK プルーフのパフォー マンスを監視しつつ、Hegotá で Verkle Trees を導入することのようです。もし STARK ベースの代替案が十分に早く成熟すれば、将来のフォークでステート移行を繰り返すことなく、コミットメント・スキームを差し替えることができるでしょう。
文脈における Hegotá：イーサリアム 2026 年のアップグレード・ケイデンス
Hegotá は、2026 年上半期の Glamsterdam に続く、同年 2 つ目の主要なハードフォークを象徴しています。この年 2 回のフォークというケイデンス（周期）は、イーサリアムの開発哲学における意図的な転換を反映しています。それは、初期の時代を特徴づけていた大規模で遅延しがちなリリースではなく、より小規模で頻繁なアップグレードへの移行です。
Glamsterdam（2026 年上半期） は、実行レイヤーの改善に焦点を当てています。具体的には、ガスの最適化、ブロックレベルのアクセスリスト（Access Lists）、そしてプロトコル内に組み込まれた Proposer-Builder Separation（ePBS）です。これらは漸進的ではありますが、L1 のスループット向上と MEV 処理の改善において重要な変更です。
Hegotá（2026 年下半期） は、ステートレイヤー自体をターゲットとしていま す。Verkle Tree（バークルツリー）が「目玉」機能の筆頭候補ですが、ステートおよび履歴の有効期限（expiry）メカニズムについても議論されています。
これらはいずれも、PeerDAS を提供しロールアップ向けのブロブ（blob）容量を拡張した 2025 年のアップグレード — Pectra および Fusaka — に続くものです。これら 4 つのフォークを合わせると、一貫した流れが見えてきます。L2 のためのブロブ空間、L1 のためのガス効率、そして今回のノードオペレーターのためのステート圧縮です。
命名規則もこの継続性を反映しています。「Hegotá」は、「Bogotá」（2022 年の Devcon 開催都市にちなんだ実行レイヤーのコードネーム）と「Heze」（恒星にちなんだコンセンサスレイヤーのコードネーム）を組み合わせたものです。The Merge 以降のすべてのイーサリアムのフォークは、この「都市名 ＋ 恒星名」のパターンに従っています。
ノードオペレーター、ステーカー、開発者にとっての変化
ソロスステーカー は、最も大きな恩恵を受ける立場にあります。現在の最小ハードウェア要件 — 32 GB RAM、2 TB 以上の SSD、専用インターネット回線 — は経済的な障壁となっており、多くの人々をリキッドステーキングプロトコル（Lido、Rocket Pool）や中央集権型 取引所へと追いやっています。もし Verkle Tree によってストレージ要件が 100 GB 未満に削減されれば、ソロスステーキングの経済性は根本的に変化します。
ノードインフラプロバイダー は、異なる計算に直面します。数百から数千のノードを運用する企業は、ハードウェアコストの低下を実感するでしょうが、クライアントのアップデートや移行テストに投資する必要があります。Patricia Tree（パトリシアトライ）から Verkle Tree への移行には、失敗の許されない一度限りのステート変換が必要です。移行プロセスにバグがあれば、イーサリアムのステートデータベース全体が破損する恐れがあります。
DApp 開発者 は、スマートコントラクトのコードにおいて違いを感じることはないはずです。ステートトライはインフラレイヤーの関心事であり、クライアントの実装によって抽象化されています。ただし、イーサリアムのステートを直接クエリするツール（ブロックエクスプローラー、分析プラットフォーム、MEV サーチャーなど）を構築している開発者は、証明の検証ロジックを更新する必要があります。
L2 ロールアップ は間接的な恩恵を受けます。L1 でのステート証明が小さくなることは、イーサリアムに証明を投稿するロールアップにとってステート検証コストが安くなることを意味します。これは EIP-4844 のブロブによってすでに達成されたコスト削減をさらに加速させ、L2 の 1 トランザクションあたりのコストを 0.0001 ドル未満に抑える可能性があります。
移行のリスク
Verkle Tree において最も困難なのは、暗号技術ではなく「移行」そのものです。
イーサリアムは、単一のブロックでデータ構造を単純に入れ替えることはできません。すべてのアカウント、すべてのコントラクト、すべてのストレージスロットを含むステートトライ全体を、Merkle Patricia 形式から Verkle 形式に変換する必要があります。これは数ギガバイトに及ぶ大規模な変換であり、ハードフォーク中にすべてのクライアント、すべてのバリデーター、すべてのノードで同時かつアトミック（不可分）に行われなければなりません。
過去のイーサリアムのアップグレードでもデータの処理方法は変更されてきましたが、これほど根本的なレベルでデータの保存構造を再構築したものはありません。最も近い例は The Merge 自体であり、コンセンサスメカニズムをプルーフ・オブ・ワークからプルーフ・オブ・ステークに入れ替えましたが、The Merge でさえステートトライには手を加えませんでした。
クライアントチーム（Geth、Nethermind、Besu、Erigon、Reth）は、すでに移行ツールの構築とテストネットでの変換作業を進めています。Hegotá のタイムラインでは、機能が確定してから約 6 〜 9 か月のテスト期間が設けられています。その重要性を考慮すると、これはイーサリアム史上、最も厳格に監査されたアップグレードになる可能性があります。
先を見据えて：Verge から Purge へ
Verkle Tree は最終目的地ではありません。それらはイーサリアムのロードマップの次のフェーズである「The Purge（パージ）」を実現するための要素技術です。
ステートレスクライアントが稼働すれば、イーサリアムはネットワークのセキュリティを損なうことなく、古いステートデータを安全に失効（expire）させることができます。ノードはもはや何年分もの履歴ステートを保持する必要はなく、現在のステートルートと Verkle 証明（Verkle Proof）のみを使用して新しいブロックを検証できるようになります。この「ステートエクスパイアリー（ステートの有効期限）」メカニズムは、ネットワークがどれほど多くのトランザクションを処理しても、イーサリアムのストレージ要件を恒久的に制限することになります。
ノードが設定可能な閾値より古いブロック本体やレシートを破棄できるようにする履歴の有効期限（EIP-4444）と組み合わせることで、Verge から Purge へのパイプライン全体が完成し、イーサリアムノードの要件をスマートフォンに収まる程度まで削減できる可能性があります。
それはまだ数年先の話です。しかし、Hegotá が計画通りに進めば、最も重要な一歩を踏み出すことになります。それは、イーサリアムがネットワークを壊すことなく、そのステートレイヤーを根本的に再構築できることを証明することです。
BlockEden.xyz は、高性能な Ethereum RPC ノードと API インフラを運営しており、Hegotá のようなアップグレードを通じて進化するネ ットワークへの信頼性の高いアクセスを開発者に提供しています。Ethereum API サービスを探索する して、次世代のために設計されたインフラ上で構築を開始しましょう。