▼目次
前提
本レポートでは、暗号資産イーサリアム（ETH）をネイティブ通貨とするイーサリアムネットワークの2025年以降のロードマップについて、Vitalik Buterin（ヴィタリック・ブテリン）が2024年10月頃に自身のブログで公開した「Possible futures of the Ethereum protocol」シリーズに沿って解説します。
このシリーズは高度な専門用語を多く含んでいますが、本レポートではできる限りわかりやすく噛み砕いて説明します。
「Possible futures of the Ethereum protocol」シリーズは全6部構成であり、本レポートも3本に分けて公開しています。
残りのレポートはこちらからご覧いただけます。
イーサリアム（ETH）の2025年以降ロードマップの概要｜わかりやすく解説
イーサリアム（ETH）の2025年以降のロードマップの概要｜パージ（The Purge）＆スプラージ（The Splurge）
イーサリアムは、分散性やセキュリティを維持しつつ、システムのスケーラビリティ（拡張性）を高めることを目指しています。
イーサリアムのロードマップは、こうした目標達成に向けて解決すべき課題を段階的に分け、それぞれの課題に対するアップグレードを段階的に進めることで最終的なゴールを目指しています。
まずは、全体のロードマップの概要について説明します。
https://x.com/VitalikButerin/status/1741190491578810445
- マージ（The Merge）: 2022年9月に完了。イーサリアムはこのアップデートによってPoS（プルーフ・オブ・ステーク）への移行を達成し、エネルギー消費量を大幅に削減しました
- サージ（The Surge）: ロールアップやEIP-4844の導入を通じてスケーラビリティの向上に焦点を当て、秒間100,000件の取引処理を目指す段階です
- スカージ（The Scourge）: 経済的な中央集権化のリスクを低減し、バリデータノードの管理やブロック検証プロセスの改善に取り組みます
- バージ（The Verge）: レイヤー1のガスリミットを増やすことなくブロック検証効率を高め、ネットワークのスケーラビリティをサポートすることを目的とします
- パージ（The Purge）: プロトコルを簡素化し、技術的負債を削減することで、ネットワークへの参加コストを抑える取り組みです
- スプラージ（The Splurge）: エコシステム全体の成長やイーサリアムユーザーコミュニティの拡大に重点を置き、より広範な開発の促進を図ります
以前、ブロックチェーンのコンセンサスにおける主な懸念点は「中央集権化」でした。
しかし、最近ではMEV（Maximal Extractable Value）に関する理解や研究が進んできており、MEVによって得られる利益がどのように正しく公平に分配されるべきかという問題も新たな課題として浮上しています。
さらに、バリデータの分散化を促進するために、イーサリアムチェーンにおける検証作業を効率化する手法として「ステートレスな検証」も注目されています。
イーサリアムが長い間稼働するにつれて、今まではだれも気付かなかったイーサリアムの側面が明らかになりつつあります。
さらに、進化を続ける暗号技術を駆使して、ウェアラブル端末でのチェーン検証を実現することが目指されています。
こうした未解決の課題に挑むイーサリアムの取り組みは、他のブロックチェーンが直面していない問題に対する解決策を提供する可能性があり、その解決策を学ぶことは、イーサリアムへの投資判断や他のブロックチェーンの課題解決においても重要な参考となるでしょう。
本題に入る前に、まずは事前知識としてMEVとは何かについて簡単に説明します。
MEV（Maximal Extractable Value）の概要
MEV（Maximal Extractable Value）とは、ブロックを構築するマイナーやバリデータが、トランザクションを選択したり、その順番を任意に並べ替えることで得られる最大の利益を指します。
イーサリアムはThe Merge以降、暗号資産イーサリアム（ETH）の供給量が大幅に削減され、流通量も減少しています。
一般的に、ブロックチェーンのブロック作成に携わるバリデータは、トークン発行による報酬をインセンティブとして動いています。
しかし、ブロック生成報酬が大幅に減少したにもかかわらず、イーサリアムのバリデータが正常に稼働し続けている理由は何でしょうか？
その理由は、バリデータがMEVを活用することで、ユーザーから集めた資金を収益に変えているからです。
MEV自体は悪い行為ではなく、トランザクションを自由に並べ替えたり選択したりできるバリデータにとって、利益を最大化するために任意の順番でトランザクションを含めることは十分なインセンティブとなります。
ただし、イーサリアムとしては、MEVの中でもユーザーから過剰に価値を奪うような悪質な行為を排除し、MEVの分散化を進める必要があります。
イーサリアムのアップグレード・スカージ（The Scourge）
ここでは、イーサリアムにおけるMEVとステーキングプールにおける中央集権化リスクをどのように最小化していくか、また過剰なMEVを抑制するための具体的な方法について解説します。
MEV対策としてのPBSとAPS
MEV対策の基本方針は、ブロックに含めるトランザクションの選択や順番決定というタスクを分割することで、特定のアクターが過度な権限を持つことを防ぎ、過剰な利益の抽出を制限することです。
現在、MEV-Boostを活用してPBS（Proposer-Builder Separation）を部分的に実現しています。
PBSとは、バリデータがブロック提案の機会を得た際に、ブロックの内容の選定を「ビルダー」と呼ばれる専門のアクターにオークションで委託する仕組みです。
この分離により、バリデータはトランザクションの順番を決めたり、どのトランザクションを含めるかを選択したりする権限を持ちません。
ビルダーは、その選択を通じて収益を最大化することができます。
筆者作成
ブロック内容を選択して収益を最大化する作業は、規模の経済に強く依存しています。
ビルダーは特定のアルゴリズムを使用して、オンチェーンの金融ガジェットや関連するトランザクションから最大限の価値を引き出します。
バリデータはただ入札を開いて、ビルダーからの最高入札を受け入れる役割です。
他にも、APS（Attester-Proposer Separation）というアプローチもあります。
APSは、実行ブロックに関連するトランザクションやデータの処理に適用され、PBSとは異なり、ブロック全体の構築をビルダーが行い、バリデータはそのブロックの検証のみを担当します。
つまり、バリデータはブロックの提案や構築プロセスから完全に切り離され、ビルダーが作成したブロックをそのまま提案する形になります。
筆者作成
APSの利点は、バリデータがビルダーが提供したブロックをそのまま提出するだけであるため、バリデータがビルダーの選択に影響を与えることが難しくなり、バリデータとビルダーが結託するリスクがPBSよりも低くなる点です。
問題点：ビルダーの中央集権化
ビルダーの役割は、MEVを最大化するためにトランザクションの順序や挿入を決定することです。このような高度な作業を行うソフトウェアが中央集権化するリスクがあります。
https://mevboost.pics/
現在、約88%のイーサリアムブロックは、2つのビルダーソフトウェアによって選ばれています。
もしこれらのビルダーが、他のビルダーが不利益を被るようなブロックを構築するために検閲を行うようになった場合どうなるでしょう。
この場合でも、ブロックの再構成（リオーグ）はできないので、特定のトランザクションを完全に排除するためには、51%の検閲では不十分で、100%の検閲が必要になります。
すると、ユーザーはそのトランザクションがブロックに含まれるまで、平均して9スロット（約114秒）待つことになります。
通常のブロック生成時間が6秒であることと比較すると、この遅延はかなり長く、取引の迅速性に大きな影響を及ぼすことになります。
インクルージョンリスト
ビルダーの中央集権化問題を解決するためには、ブロック生成タスクをさらに分割し、異なる主体に割り当てることで、特定のアクターがタスク全体を独占できないようにする必要があります。
このアプローチでは、各タスク（例えば、トランザクションの選択、ペイロードの構築、ブロックの提案）が異なる主体に割り当てられます。
https://vitalik.eth.limo/general/2024/10/20/futures3.html
インクルージョンリストでは、ブロックに含めるべきトランザクションのリストを提案者が指定し、ビルダーはそのリストに基づいてトランザクションの順序を決定します。
これにより、提案者がブロックの基本的な内容を管理し、ビルダーはその内容を元に最適な順序でトランザクションを並べる役割を担います。
ここでの「提案者」としての役割はバリデータが担当します。
この方法により、トランザクション選択権がビルダーに偏るのを防ぎ、ブロック生成の分散化を実現します。
以下に、インクルージョンリストを活用したブロック生成の分散化手法を紹介します。
FOCIL（Fork-choice-enforced inclusion lists）＋ APS
FOCILは、ブロック内容を構成する過程で、特定の取引を「含めるべき」というルールを設け、そのリストを複数のリスト作成者によって確認・強制する仕組みです。
この仕組みでは、トランザクションを1ブロック遅らせるには、インクルージョンリストを作成するすべてのリスト作成者がそのトランザクションを検閲しなければなりません。
FOCILとAPSを組み合わせたものは、「FOCIL + APS」と呼ばれ、より高度な分散化と検閲耐性を実現します。
BRAID
ブロックを作成するタスクを、トランザクションを選定してインクルージョンリストに含める比較的だれでも行えるような規模の経済が小さい部分と、トランザクションの順序付けなどの高度なアルゴリズムが必要な規模の経済が大きい部分に分けるのではなく、ブロック生成プロセス自体を多くの参加者に分散させることを目指しています。
つまり、BRAIDは、1人のブロック提案者がブロックを作成するのではなく、複数の提案者が並行してトランザクションリストを生成します。
例えば、作成された複数のトランザクションのリストを手数料の高い順で並べて一番手数料が高いものを採用する、というような決定論的なアルゴリズムで選択するというような方法が考えられます。
BRAIDによるブロック生成がイーサリアムに組み込まれた場合、デフォルトで最適なブロック提案を行うことができるようになります。
ただし、ブロックをそのまま提案するだけのシンプルな役割の提案者には、いくつかの攻撃リスクが考えられます。
例えば、「ラストムーバー・アービトラージ攻撃」では、最後に提出されたブロック提案者が市場の変動を利用して利益を得ることが可能です。
また、提案者が自分の取引を優先的にブロックに含めるためにインセンティブを提供することができます。
これにより、特定の提案者や取引所が独占的な取引フローを確立し、利益を最大化することになります。
ビルダーから提案されたブロックを提出するだけの単純なブロック提案者と、高度なアルゴリズムを使ってブロックを構築する専門化されたビルダーという異なる権限を持つ2つの極端な方法の間で、いくつものデザインの選択肢があります。
例えば、ブロックへの追加権のみをオークションで販売し、順序の変更やブロックの先頭への追加を制限することが考えられます。
また、ブロックの先頭への追加は可能にしても、中間の挿入や再配置はできないようにすることも可能です。
暗号化mempool（メモリ プール）
BRAIDやAPSを実現するのに重要となってくる技術として暗号化mempoolがあります。
mempoolとは、まだブロックに含まれていないが、承認されるのを待っているトランザクションを一時的に格納する領域のことです。
ユーザーがトランザクションを暗号化された形で送信し、有効性を証明します。トランザクションは暗号化されたままブロックに含まれ、ブロックビルダーは内容を知ることなく処理を行います。トランザクションの内容は後で公開されます。
暗号化mempoolの主な課題は、すべてのトランザクションが後に確実に公開されるように設計することです。
暗号を用いた「コミット＆リビール」方式では、情報を最初に「コミット」した後、後でその情報を公開して「リビール」するというプロセスが行われます。
しかし、公開の選択が任意の場合、公開タイミングがブロックに影響を与える「ラストムーバー」的な操作が悪用されるリスクがあります。
このため、暗号化mempoolの設計には慎重な配慮が必要です。
課題とトレードオフ
ここまで述べてきたブロック生成スキームは、単純なブロック提案者と完全に専門化されたビルダーの間でバランスを取るようなものでした。
具体的には、ブロック生成に関わる権限をブロック生成の権限を、シンプルな方法から高度に専門化された方法へと規模の経済に基づく範囲で位置付け、それらの権限をどのように分割するかを検討することで、各スキームの特徴と問題点を理解できます。
https://vitalik.eth.limo/general/2024/10/20/futures3.html
上の図における「Attesting」とは、ブロックが正当であることを確認し、そのブロックに対して承認を与えるプロセスを指します。
これにより、ブロックの正当性がネットワーク全体で認められます。
「Ensuring inclusion of txs」は、特定のトランザクションが生成されるブロックに必ず含まれるようにするためのプロセスです。
これにより、すべての必要なトランザクションが指定されたブロック内に確実に組み込まれます。
「Statistical influence over ordering」は、ブロック内でトランザクションの順序を決定する際に、単純な指標（例えば手数料）だけでなく、統計的な手法やアルゴリズムを利用して、より高度で複雑な方法で順序を決定するプロセスを指します。
「Last-look append or insert」は、ブロック生成がほぼ完了した段階で、最終的なトランザクションを挿入または追加するプロセスです。
具体的には、ブロックがほぼ完成した後に、最終的な調整を行うアクター（通常はプロポーザーやビルダー）が、最終的なトランザクション挿入の権限を持つことを指します。
「Choose top of block」は、ブロックの先頭に配置されるトランザクションを選択するプロセスを指します。
最初に配置されるトランザクションは、特に重要視されています。
上の図では、ブロック生成に関わる権限がどのように分布しているかを示しています。
2021年以前は、これらの権限がすべて一つのアクターに任されていたため、MEVを好き放題行うことができました。
これに対して、目標はできるだけ多くの権限を分散化されたアクターに移すことです。
具体的には、
- ステーカーの手に多くの権限を持たせること
- ステーカーができるだけ分散化され、中央集権化するインセンティブが少ないこと
の2つが重要です。しかし、これらを両立させるのは非常に困難です。
FOCIL + APS
https://vitalik.eth.limo/general/2024/10/20/futures3.html
FOCIL + APSは、インクルージョンリストとオークションを用いてブロックを作成する方法です。
具体的には、ステーカーがインクルージョンリストの作成を担当し、その後の高度な部分（例えば、取引の順序決定など）はオークションを通じて譲渡されます。
これにより、ブロック生成における権限を適切に分割し、ビルダーが過度に集中するのを防ぎます。
BRAID
https://vitalik.eth.limo/general/2024/10/20/futures3.html
BRAIDは、ブロック生成プロセスそのものを多くの参加者に分散させることを目指しています。
具体的には、ステーク量に応じて与えられる権限が分かれ、ライトステーカーは比較的軽い役割（例えば、簡単な確認作業やブロック提案のシンプルな部分）を担当し、ヘビーステーカーは取引の選定やMEVの最大化に関する高度な戦略的判断を行います。
さらに、トランザクションは優先手数料の高い順に並べられるため、ブロックの最上部に配置されるトランザクションの選択は、事実上、手数料市場を通じたオークション形式になります。
ただし、ブロック最上部に配置するトランザクションは手数料市場を通じてオークション形式で選択されるため、ストラテジースティーリング攻撃（他人の取引をコピーして手数料を少しだけ上げて送信する攻撃）に対して脆弱性があります。
FOCIL + APS の「積極的」なバージョン
https://vitalik.eth.limo/general/2024/10/20/futures3.html
ここで言う「積極的」なバージョンとは、APSにおいて、ブロックの先頭以外を決定する方式です。
この方式では、ブロック提案者が完全にブロックを構築するのではなく、先頭以外の部分（例えば、最終的なトランザクションの選定や順序付けなど）だけを担当することになります。
このアプローチは、より多くの権限を分散化し、ビルダーによる集中的な力の行使を抑制することが目的です。
残された課題
現在残されている主な課題は、(i) 各提案の詳細な部分を確定させ、その影響を十分に分析すること、そして (ii) それらの分析結果をイーサリアムコミュニティが定める「中央集権化に対する許容範囲」とすり合わせることです。
また、これらの提案が必ずしも互いに排他的な選択肢ではありません。
例えば、FOCIL + APS の実装は、将来的な BRAID 実装への移行ステップとしても機能する可能性があります。
このため、まずは慎重に「様子見」のアプローチを採り、ステーキングにおける権限を一部制限し、他の権限をオークションで分配する形で解決策を実装することが妥当です。
その上で、実ネットワークでの MEV市場 の運用に関する知見を深めながら、徐々にステーカーの権限を拡大していく方法が効果的と考えられます。
また、特にステーキングにおける中央集権化のボトルネックとして、以下の4つの課題が挙げられます：
- ブロック構築の中央集権化（本節で詳述）
- 経済的要因によるステーキングの中央集権化（次節で説明）
- 32 ETH の最低ステーキング額による中央集権化（Orbitやその他の技術によって解決が期待される。詳細は「イーサリアム（ETH）の2025年以降ロードマップの概要｜わかりやすく解説」の「イーサリアムの大型アップグレード・The Merge」を参照）
- ハードウェア要件によるステーキングの中央集権化（Vergeの中で、ステートレスクライアントやZK-EVMが解決策となる）
これらのいずれかの課題を解決するだけでも、他の課題の解決に大きな効果をもたらす可能性があります。
ステーキングエコノミクス
解決すべき問題
現在、イーサリアムの供給量の約30％がステーキングされています。
この割合は、イーサリアムを51％攻撃から守るには十分ですが、ステーキングされる暗号資産イーサリアム（ETH）の割合がさらに増加した場合、以下のリスクが懸念されます：
- ステーキングの義務化:ステーキングが専門家たちの収益活動から、すべてのイーサリアム（ETH）保有者に課される義務へと変わる可能性があります。その結果、多くのユーザーが集中管理型のオペレーターにイーサリアム（ETH）を委任することになり、中央集権化が進行する恐れがあります。
- スラッシングメカニズムの信頼性低下:ステーキングされるイーサリアム（ETH）の割合が増えると、スラッシング（罰則）メカニズムの信頼性が低下する可能性があります。これにより、システムのセキュリティが脅かされるリスクがあります。
- 流動性ステーキングトークンの支配:単一の流動性ステーキングトークン（LST）がネットワークの支配的な存在となり、これがイーサリアム（ETH）自体の「通貨」としての価値に影響を与える恐れがあります。
- 不必要なイーサリアム（ETH）の発行:現在の仕組みでは、年間約100万ETHが不必要に追加発行されている可能性があり、特にLSTが支配的なネットワーク効果を得ることで、これらの追加ETHの大部分がLSTに吸収されるリスクがあります。
解決策とそのメカニズム
これらのリスクを解決するためには、流動性ステーキングトークン（LST）の設計を見直し、より分散化された中立的なものにする必要があります。具体的な解決策として、以下の方法が考えられます：
- スラッシング罰則の制限: スラッシング罰則を最大で 1/8 に制限することで、ステーキングされたETHの7/8 を保護し、これをLSTに統合する方法です。これにより、より多くのイーサリアム（ETH）がリスクをあまり気にせずにステーキング可能になります。
- 二層ステーキングモデル: リスクを伴うステーキング（スラッシングの対象となるもの）を全体の 1/8 に制限し、残りの 7/8 は「リスクフリー」のステーキングにする方法です。これにより、誰でも参加しやすく、安定したステーキングが可能になります。
ただし、このアプローチに対しては 発行量の削減 と同等の結果をもたらすとの指摘もあります。
例えば、リスクを伴う層のリターンが3.4％、リスクフリー層のリターンが2.6％ の場合、実質的に ステーキングのリターンは（3.4 - 2.6 =）0.8％ に低下し、イーサリアム（ETH）を保持するインセンティブが低くなる可能性があります。
MEV（最大抽出可能価値）の問題
現在、MEVは、主に ブロックプロポーザー（ステーカー） に流れていますが、この収益はプロトコルにとって不透明です。
MEV収益には以下の問題点があります：
- 収益の不安定性:MEVは非常に不安定で、各ステーカーが収益を得るのは ブロックを提案したときだけ であり、通常は 4か月に1回程度 となります。これにより、安定した収入を求めるステーカーがプールに参加するインセンティブが強まります。
- インセンティブの不均衡:MEVによる収益は主にブロックプロポーザーに集中し、アテスターへの報酬が相対的に少ない状況になります。
- ステーキング上限設定の困難性:MEV収益があるため、ステーキングのリターンがゼロでも、MEV収益だけでステーキングを行う動機が生まれます。そのため、ステーキングの上限設定は非常に難しく、現実的にはリターンが負の無限大に近づく必要があるという問題も抱えています。
解決策：MEV収益の回収
これらの問題を解決するためには、MEV収益をプロトコルで読み取り、回収する方法 を導入することが有効です。
初期の提案としては 「MEVスムージング」 がありましたが、現在では、ブロックプロポーザー権限を事前にオークション する仕組みが、同様の目的を達成する方法として広く認識されています。
このアプローチでは、MEV収益を事前に取り込む ことで、ステーキングの収益性を安定させ、ネットワーク全体の経済バランスを改善することができます。
イーサリアムのアップグレード・バージ（The Verge）
ブロックチェーンの最大の特徴の一つは、誰でもチェーンが正しく更新されているかを確認できることです。
仮に、チェーンのコンセンサス（PoWやPoSなど）を実行しているノードの95%が合意してルールを変更し、新しいルールに基づいてブロックを生成し始めたとしても、完全に検証可能なノードを実行しているユーザーはそのチェーンを受け入れません。
代わりに、旧ルールを遵守するチェーンに収束し、そのチェーンを構築し続けます。
そして、完全な検証を行うユーザーもそのチェーンに追随します。
このような特徴を実現するためには、より多くのユーザーが検証できることが必要です。
しかし、現在のところ、ノードの運用はノートパソコンでも可能ですが、簡単に実行できるわけではありません。
そこで、バージ（The Verge」は、チェーンの検証を非常に計算負荷の少ないものにすることを目指しています。
これにより、モバイルウォレットやブラウザウォレット、さらにはスマートウォッチでもデフォルトで検証を行えるようにすることを目標としています。
以下では、スマートウォッチでチェーンを完全に検証できるようにするために、データを少しダウンロードし、SNARKやSTARK（Scalable Transparent Argument of Knowledge）を検証するだけで完了する方法について解説します。
ステートレスな検証
現在、イーサリアムクライアントはブロックを検証するために数百GBの状態データを保存する必要があります。
この状態データの大きさは年々増加し、毎年約30GBが増加し続けています。
個々のクライアントは状態を効率的に更新するために追加のデータを保存する必要があり、このデータ量はノードのセットアップの難易度を上げるとともに、運用にかかる時間も増加させています。
そこで、ノードが保持すべき状態データを一部だけ保持し、それを元に検証を行えるようにすることを目指すアプローチが「ステートレス検証」です。これにより、従来のように全ての状態を保持することなく、ブロックチェーンの検証が可能になります。
https://vitalik.eth.limo/general/2024/10/23/futures4.html
Merkle Patricia tree（マークル・パトリシア・ツリー）では実現できない理由
現在、イーサリアムでは状態データをMerkle Patricia treeという構造で管理しています。
しかし、このツリー構造は暗号学的証明スキームとして非常に不向きであるとされています。
主な理由は以下の2点です。
- 証明サイズの大きさ：現在のMerkle Patricia treeは16分岐ツリーであり、各ノードに16個の子ノードが存在します。これにより証明のサイズが非常に大きくなります。例えば、アイテム数が2^32（約43億）の場合、証明サイズは約3840バイトになります。対照的に、バイナリツリー（2分岐ツリー）の場合、同じアイテム数であれば証明サイズは約1024バイトで済みます。従って、証明サイズが大きすぎることが問題となります。
- アカウントコードへのアクセス証明の難しさ：現時点では、イーサリアムのコードは、木構造で分割して扱うことができません。そのため、アカウントコードへのアクセスを証明するには、コード全体を提供する必要があります。イーサリアムでは、コードの最大サイズが24000バイトに制限されており、この要件が証明データのオーバーヘッドを増加させる要因となっています。
実際、最悪の場合を考えてみると、1スロット内でダウンロードするには現実的ではないデータ量です。
では、もしこのMerkle Patricia treeの検証をzk-STARKというゼロ知識証明を用いて行おうとすると、以下の問題が発生します：
- KECCAKがSTARKに適していないこと
- Merkle Patricia treeを用いて証明する場合、KECCAKのラウンド関数を500万回呼び出す必要があること。これを証明するのは、最も高性能な一般向けハードウェアでも非常に困難です。
もし16分岐ツリーをバイナリツリーに置き換え、コードを分割してMerkle化することができれば、証明のコストは約30倍削減できる可能性があります。
ただし、これにはコードの各チャンクへのアクセスごとにガス代がかかるよう変更する必要があり、この変更はEIP-4762で行われています。
結果として大幅に改善はされますが、それでも多くのノードが1スロット内にダウンロードするには大きすぎます。
したがって、さらに強力な技術が求められます。
主に考えられる解決策としては、Verkle treeとSTARKを用いたbinary hash treeがあります。
Verkle tree（バークルツリー）
Verkle treeは、楕円曲線ベースのベクターコミットメントを利用することで、非常に短い証明を可能にする新しいツリー構造です。
この技術の特徴的なポイントは、親子関係ごとに証明部分のサイズがツリーの幅に関わらず常に32バイトに保たれるという点です。
ツリーの幅が大きくなると証明の計算効率が低下する可能性があるため、イーサリアム向けの実装ではツリーの幅が256に設定されています。
https://vitalik.eth.limo/general/2024/10/23/futures4.html
Verkleツリーにおける最悪のケースは、攻撃者が意図的にツリー内で共通の長い接頭辞を持つ2つのアドレスを「マイニング」し、そのうちの1つを読み取る場合です。
この場合、共通の接頭辞を持つアドレスは木構造において近くに配置されるので、最悪のブランチの長さが約2倍に拡張される可能性があります。
これに対処するため、一つ工夫を行います。
それは、隣接するストレージへのアクセスを非常に安価にすることです。
これは、同一コントラクト内の多数のコードチャンクや隣接するストレージスロットへのアクセスを指します。
EIP-4762では、隣接アクセスには200ガスのみが課されるように定義されています。
隣接アクセスを考慮しても、最悪ケースの証明サイズは許容範囲内に収まっています。
隣接するデータへのアクセスが安価になることで、より多くのデータが証明の対象になりやすくなるため、証明サイズが大きくなっています。
もし証明サイズを減少させたい場合、隣接アクセスに対するコストを若干増加させることで対応可能です。
STARKを用いたbinary hash tree（バイナリハッシュツリー）
まず、バイナリツリーを構築し、その中で証明すべき値が存在することを証明するために最大10.4MBの証明を作成します。
この証明はSTARKによって作成され、証明自体は証明対象のデータとSTARKから生じる約100〜300KBの固定オーバーヘッドで構成されます。
この方法の主な課題は、証明者の処理速度です。
例えば、10.4MBのブロックを証明するためには約330,000ハッシュを計算する必要があります。
攻撃者が長い共通接頭辞を持つアドレスを「マイニング」する場合、最悪のケースでは約660,000ハッシュを計算する必要があります。
したがって、毎秒200,000ハッシュを証明できれば十分です。
現在、Poseidonハッシュ関数を用いることで、消費者向けラップトップでも毎秒200,000ハッシュの処理が可能ですが、Poseidon（ポセイドン）はまだ比較的新しい技術であり、その安全性については完全に確立されていません。
したがって、今後の選択肢としては次の2つが考えられます：
- Poseidonの安全性を徹底的に分析し、その信頼性を高めてL1で導入する。
- SHA256やBLAKE2bのようなより保守的なハッシュ関数を採用する。
現在、StarkwareのCircle STARK証明者を用いた場合、保守的なハッシュ関数であっても毎秒10,000〜30,000ハッシュを処理できますが、STARK技術は急速に進化しており、GKRベースの技術により、処理速度は毎秒100,000〜200,000ハッシュに向上する可能性があります。
コンセンサスの有効性証明
イーサリアムのブロックをzk-SNARKを用いて検証する際、EVMの実行だけでなく、コンセンサスの証明も行う必要があります。
具体的には、デポジット、引き出し、署名、バリデータの残高更新、そしてイーサリアムのPoSに関連するその他の要素についても証明が求められます。
イーサリアムにおけるコンセンサスレイヤーとして動作するBeacon Chainは、EVMと同様に状態遷移関数として定義されています。
その状態遷移関数でよく使われる操作には、以下の3つがあります。
- ECADD（楕円曲線加算）：BLS署名の検証に使用される
- ペアリング演算：BLS署名の検証に使用される
- SHA256ハッシュ：状態の読み取りおよび更新に使用される
これらの操作に関して、どのような課題があり、どのように解決できるかについて詳しく見ていきましょう。
ECADD（楕円曲線加算）
現在、イーサリアムではブロックごとに、バリデータが1回から最大16回のECADD（楕円曲線加算）を行う必要があります。
さらに、ネットワーク全体では約30,000人のバリデータが署名を行っています。
もしシングルスロットファイナリティ（SSF）が実現した場合、ネットワークの規模は「ブルートフォース」アプローチで1スロットあたり100万人のバリデータにまで増加する可能性があります。
逆に、Orbit SSFのような手法を採用すれば、バリデータ数は32,768人に留まり、さらには8,192人にまで減少する可能性があります。
現在のスケールでは、30,000のECADDを証明する必要があり、依然として計算量が多いという課題があります。
これを改善するための方法が求められています。
BLS12-381のペアリング
次に、ペアリング演算に関する問題です。
イーサリアムのコンセンサスにおいて、1つのスロットで最大128個のアテステーション（署名の検証）が行われます。
これにより、128個のペアリングを検証する必要があります。ただし、EIP-7549などの変更により、スロットごとの検証数は16個程度に削減できる可能性があります。
ペアリング自体の数は少なくなりますが、それぞれの計算（または証明）はECADDよりも数千倍の時間がかかるため、非常に高コストです。
解決策：署名集約＆署名スキームの変更
ECADDやペアリングを効率的に処理するためには、署名集約や署名スキームの変更が有効です。
具体的には、ネットワーク内のノードが部分的な署名セットの中間証明を生成し、それらについて再帰的に証明を行うアプローチが有効です。
これにより、証明作業をネットワーク全体で分散させ、一から証明を作成するよりも負担を大幅に軽減することができます。
また、Lamport+Merkle署名の場合、署名を検証するために256+32回のハッシュ計算が必要となり、署名者数が32,768人に達する場合、9,437,184回のハッシュ計算が求められます。
このため、署名スキームの最適化によって計算量を減らすことが可能です。
さらに、Poseidonというzk-SNARKフレンドリーなハッシュ関数を使用すれば、証明の処理がより効率的に行えます。
現実的には、再帰的な集約スキームを使用することで、署名検証の高速化が可能となり、1スロット内での証明処理を短縮できます。
SHA256
次に、最も多く呼び出されるハッシュ関数であるSHA256についてです。
特に、エポック遷移を表すブロックでは、バリデータ全員の残高を反映した状態ツリーが更新され、各バリデータのデータは1バイトずつ追加されます。
これにより、約1MBのデータがリハッシュされることになります。これは32,768回のSHA256呼び出しに相当します。
解決策：ハッシュ関数の変更
現状では、SHA256を使用する際にデータ長に基づいて圧縮関数を2回呼び出していますが、この部分を最適化し、SHA256の呼び出しを直接圧縮関数に変更するだけでも、計算効率が2倍向上します。
さらに、Poseidonというzk-SNARKフレンドリーなハッシュ関数に切り替えることで、約100倍の効率化が期待できます。
Poseidonでは、1秒間に最大170万回（54MB）のハッシュ計算が可能であり、100万人のバリデータ記録も数秒以内に「証明」に取り込むことができます。
Beam Chain（ビームチェーン）・提案された次世代コンセンサスレイヤーが与える影響
イーサリアムの研究者であるJustin Drake（ジャスティン・ドレイク）は、Devcon 7で新たなコンセンサスレイヤーとしてBeam Chainを提案しました。
Beam Chainは、ゼロ知識仮想マシン（zkVM）を活用し、ステート遷移を検証することで、コンセンサスと実行レイヤーを完全に分離することを目指しています。
これにより、コンセンサスアルゴリズムを柔軟に設計・実装できる仕組みを提供します。
また、量子コンピュータに耐性を持つハッシュベースの署名やハッシュベースのSNARKを採用し、将来の量子コンピュータ時代にも対応可能な安全性を備えています。
さらに、BLS署名ではできないような署名の集約の集約を可能にすることで、トランザクション処理の効率化も期待されています。
ただし、上述したイーサリアムコンセンサスの有効性証明を実現するには数年の時間が必要と予想されます。
これは、シングルスロットファイナリティ、Orbit、署名アルゴリズムの変更、Poseidonのようなハッシュ関数の導入に伴うセキュリティ分析など、関連する技術的な取り組みとともに実現されるでしょう。
ここで重要な点は、イーサリアムコンセンサスレイヤーの改革において、より段階的なアプローチを取るべきか、それとも「一度に多くの変更を行う」ような急進的なアプローチを取るべきかという選択です。
EVMの場合、後方互換性への影響を最小限に抑えるため、段階的なアプローチが理にかなっています。
一方、コンセンサスレイヤーでは後方互換性の懸念が小さいため、Beam Chainのように、SNARKフレンドリー性を最適化するための大規模な変更を一度に実行する強いメリットがあります。
Beam Chainの実装のタイムラインを確認しつつ、2029年ごろの実現を見据えて、その前に実現可能な解決策を前倒しで取り入れるきっかけが生まれるかもしれません。
総論
本レポートでは、「Possible futures of the Ethereum protocol」シリーズのPart 3およびPart 4に基づき、イーサリアムのスケーリングに関する技術的な選択肢と、それぞれの課題について解説しました。
全てのスケーリング手法を網羅的に解説することはできず、例えばアプリケーションレイヤーからのMEVの解決策などは割愛しました。
詳細に興味のある方は、本レポートの参照元を参照してください。
今まで見えていなかったMEVやそれに対する課題が次々と明らかになり、イーサリアムエコシステムにおける新たな技術的挑戦が浮き彫りになっています。
特に、ステートレスな検証という一見不可能に思える課題に対して、技術的な解決策が次々と提案されている点は非常に興味深い進展です。これらの解決策が実現すれば、イーサリアムはさらなるスケーラビリティや効率性を達成し、より多くのノードやユーザーが参加できる真に分散化されたネットワークへと進化するでしょう。
「Possible futures of the Ethereum protocol」シリーズは全6部構成であり、本レポートも3本に分けて公開しています。
残りのレポートはこちらからご覧いただけます。
イーサリアム（ETH）の2025年以降ロードマップの概要｜わかりやすく解説
イーサリアム（ETH）の2025年以降のロードマップの概要｜パージ（The Purge）＆スプラージ（The Splurge）
【ご注意事項】
本記事は執筆者の見解です。本記事の内容に関するお問い合わせは、株式会社HashHub（https://hashhub.tokyo/）までお願いいたします。また、HashHub Researchの各種レポート（https://hashhub-research.com/）もご参照ください。
提供：HashHub Research
執筆者：HashHub Research
