Vitalikが定めるイーサリアムの今後5年：実行効率化、データシャーディング、状態の階層化

2026年2月27日、Vitalik ButerinはEthereum Researchに「Hyper-scaling state by creating new forms of state（新たな形式の状態を作成することによる状態のハイパースケーリング）」というタイトルの長文を投稿しました。

この記事の中で、Vitalik Buterinはイーサリアムのスケーリングパスをさらに整理しています。この記事は単に技術的な観点からイーサリアムのスケーリングについて論じるだけでなく、全体的なアーキテクチャの観点から、段階的に推進するスケーリングソリューションを提供し、今後数年間にわたってイーサリアムがネットワーク容量を継続的に拡大するための基盤を提供することを目的としています。

同時に、彼はX（旧Twitter）にも投稿を行い、この記事についてさらに説明しました。私たちは、Vitalikが今回新たに提案したスケーリングソリューションが一体何であり、なぜこのようなことをする必要があるのかを、分かりやすく理解しようと試みます。

実行リソースとデータリソースの短期および長期拡張

Vitalikは長文の冒頭で、「今後5年間でイーサリアムをスケールさせるためには、3種類のリソースを拡張する必要がある」と指摘しています：

- 実行リソース：EVM計算、署名検証など

- データリソース：トランザクションの送信者、受信者、署名など

- 状態リソース：アカウント残高、コード、ストレージ

最初の2つには、短期および長期の拡張ソリューションがあります。

実行リソースについては、短期的にはブロックアクセスリスト（BAL）、ePBS、およびガス料金の再価格設定により約10〜30倍の増加を実現し、長期的にはZK-EVMにより約1000倍の増加を実現します。また、特定のタイプの計算（署名、SNARK/STARK）については、オフチェーン集約により約10000倍のパフォーマンス向上が可能です。

データリソースについては、短期的にはP2Pの改良と多次元ガスにより約10〜20倍の増加を実現し、長期的にはBlobs + PeerDASにより約500倍の増加を実現します。

短期的な拡張は、イーサリアムをより速く動作させることに焦点を当てています。現在のイーサリアムが遅いのは、現在の検証方法がシリアル（直列）であるためです——取引を一つずつチェックします。ある取引が詰まると、検証プロセス全体が詰まってしまいます。

そこで、今年予定されているGlamsterdamアップグレードでは、ブロックアクセスリスト（BAL）とePBSが導入されます。

ブロックアクセスリストにより、ブロックバンドラーはバリデータに対して事前に「このブロック内の取引は、これらのアカウントとストレージ位置にアクセスします」と伝えることができます。この情報があれば、バリデータは事前に準備し、これらのデータをハードディスクからメモリにロードできます。そして、バリデータは取引を一つずつチェックするのではなく、複数の取引を並行してチェックできるようになります。工場の組立ラインのようなものです：以前は一人の作業者が製品全体を担当していましたが、今は複数の作業者が異なる部分を同時に処理します。

ePBSは、ブロックのバンドルと検証プロセスを分離します——ブロックビルダーは取引のバンドルを担当し、プロポーザーはブロックの提案を担当し、バリデータはブロックの検証を担当します。各役割がそれぞれの仕事を適切に行えば、ブロックビルダーはセキュリティの問題を心配することなく、より積極的に多くの取引をバンドルできるようになります。なぜなら、プロポーザーとバリデータがチェックしてくれるからです。

ガス料金の再価格設定 + 多次元ガスは、いわば「核心的な手法」と言えるかもしれません。現在、イーサリアムではすべての操作が同じガス料金で行われています。しかし、Vitalikの考え方は、異なる操作には異なる価格があるべきだというものです。

特に、新しい状態の作成（例えば、新しいアカウントの作成、新しいコントラクトのデプロイ）には、特別な「状態作成料」がかかるべきです。なぜなら、新しい状態を作成することが最もコストのかかる操作だからです。これは計算リソースだけでなく、ストレージリソースも消費します。そして、このコストは永続的です——一度作成されると、その状態は永久に存在し続けます。

したがって、Vitalikの考え方は次の通りです：新しい状態の作成をより高価にし、通常の取引をより安くする。

これを実現する方法が「貯水池メカニズム」です。2つのバケツを想像してください。1つは「状態作成料」用、もう1つは「通常のガス料」用です。コントラクトが互いに呼び出し合うとき、ガスは自動的に2つの貯水池から借用され、混乱が生じないように保証されます。

一般ユーザーの取引は、これらの取引が「状態作成料」を支払う必要がないため、より安くなります。一方、新しい状態を作成したい開発者は、より高い料金を支払う必要があります。これにより、ネットワーク全体の容量は大幅に増加しますが、状態の増加は抑制され、フルノードのハードディスクが爆発することはありません。

長期的な拡張は、メインネット自体を大きく強くし、Layer 2への依存を減らすことです。これには、Blobs + PeerDASとZK-EVMの段階的なロールアウトが含まれます。

Blobsは、一時的な大容量ファイルストレージであり、現在は主にLayer 2で使用されています。将来的には、イーサリアムメインネット自体もBlobsを使用してデータを保存するようになります。しかし、問題も生じます——すべてのノードがすべてのBlobsをダウンロードしなければならない場合、ネットワークは圧迫されてしまいます。

ここでPeerDASが役立ちます——すべてのデータをダウンロードする必要はなく、ほんの一部だけをダウンロードすればよいのです。サンプル調査のようなもので、全員に聞く必要はなく、ほんの一部の人に聞くだけで、集団全体の状況を推測できます。ZK証明と組み合わせることで、全データの1/16しかダウンロードしていなくても、データの完全性を確認できます。

次に、ZK-EVMの段階的なロールアウトです。これにより、ブロック内のすべての取引を再実行することなくブロックを検証できるようになり、ノードは単にZK証明を信頼すればよくなります。検証コストは「すべての取引を実行する」ことから「1つのZK証明を検証する」ことに低下します。

Vitalikの計画は、2026年に一部のノードがZK検証を試用し、2027年にはより多くのノードが使用するよう奨励するというものです。最終的に、ブロックが有効であるためには、異なる証明システムからの5種類の証明タイプのうち3種類を含める必要があります。彼は、すべてのノード（インデックスノードを除く）が最終的にZK-EVM証明に依存するようになると予想しています。

「万能薬」のない状態拡張

次に、短期および長期の拡張でまだ議論されていない「状態リソース」を見てみましょう。短期的には、ブロックアクセスリストとの同期、P2Pの改良、データベースの最適化などを通じて約5〜30倍の向上が可能ですが、長期的にはどうでしょうか？

Vitalikの答えは、「ない」です。

なぜ状態リソースはこれほど拡張が難しいのでしょうか？イーサリアムの状態は、巨大なデータベースのようなものです。このデータベースには、すべてのアカウントの残高、すべてのコントラクトのコード、すべてのストレージ位置のデータが保存されています。

現在、このデータベースはまだ大きくなく、約100 GBですが、状態を20倍に拡張すると2 TBになります。さらに時間が経てばどうなるでしょうか？8 TB？

問題は、ハードディスクに収まらないことではありません：

- データベースの効率が影響を受ける：現代のデータベースは、データを整理するためにツリー構造（例えばMerkle木）を使用しています。新しいデータを書き込むときは、ツリー全体を更新する必要があります。これは、X回の更新を行う場合、データベースレベルではX回の操作が必要になることを意味します。更新が多いほど操作が多くなり、書き込みは爆発的に遅くなります。

- 同期が困難：イーサリアムネットワークに新しく参加するノードは、新しいブロックを検証するために状態全体をダウンロードする必要があります。データ規模が8 TBになると、現在のほとんどの人のインターネット速度では、非常に長い時間がかかります。

解決策はありますが、Vitalikはどれにも問題があると考えています：

- 「強状態ステートレス性」：ノードは完全な状態を保存する必要はなく、ユーザーがMerkle証明を提供するだけで済みます。Vitalikは、このソリューションには状態ストレージの中央集権化、動的ストレージアクセスによる取引失敗、および帯域幅コストの問題があると考えています。

- 「状態の有効期限切れ」：頻繁にアクセスされない状態は、アクティブな状態から自動的に削除されます。ノードは最近アクセスされた状態だけを保存すればよく、ストレージスペースを大幅に削減できます。Vitalikは、根本的な「存在証明問題」があると考えています。つまり、新しい状態を作成するとき、ある状態が「決して存在しなかった」ことをどのように証明するかです。新しいアカウントを作成すると仮定すると、その新しいアカウントアドレスがイーサリアム上で一度も作成されたことがないことを証明する必要があります。これは、新しいアカウントを作成するたびに10年分の履歴データをチェックする必要があることを意味し、新しいアカウントの作成は複雑で高価になります。

Vitalikの最終的な方法は、これら2つのソリューションを組み合わせ、いくつかの新しい状態形式を提案することです。これは、イーサリアムの状態リソースアーキテクチャ全体の変更です：

- 一時ストレージ：自動的に期限切れになるストレージ。例えば、毎月自動的にリセットされる新しいツリーを作成できます。このストレージは、オーダーブック、流動性プール、一時カウンターなどの一時データに使用できます。これらのデータは通常、永続的に保存する必要はなく、1か月後には古い注文は期限切れになり、新しい流動性プールが作成されます。

- 周期的ストレージ：一時ストレージに似ていますが、周期が長く、例えば1年です。

- 制限付きストレージ：特定のストレージは特定の方法でのみアクセスできます。例えば、ERC20トークンの残高ストレージは、特定のインターフェースを介してのみアクセスできる可能性があります。これにより、システムはこのようなストレージを最適化できます。

同時に、既存の状態形式は保持されます。これにより、実行は（ZK-EVMを通じて）1000倍安くなる可能性がありますが、新しい状態の作成は20倍安くなるだけかもしれません。

Vitalikは、新しい状態形式があれば、開発者は選択肢を持つことができると考えています。既存の状態形式を引き続き使用して高い料金を支払うか、アプリケーションを再設計して新しい状態形式を使用し、より低い料金を得るかです。一般的なユースケース（例えばERC20残高、NFT）には標準化されたワークフローがあり、より複雑なユースケース（例えばDeFi）については、開発者が最適化する方法を自分で考え出す必要があります。

この戦略は非常に興味深く、開発者が頭を使ってコストを削減し、広範なイーサリアムユーザーが恩恵を受けるという意味合いがあります。