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

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

同時に、彼はXにおいてこの文章をさらに説明するツイートを発表しました。私たちは、Vitalikが今回新たに提案したスケーリングプランが一体何であり、なぜそれを行う必要があるのかを分かりやすく理解しようと試みます。

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

Vitalikは長文の冒頭で、「今後5年間でEthereumを拡張するためには、3種類のリソースを拡張する必要がある」と指摘しました：

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

• データリソース：取引の送信者、受信者、署名など

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

前者2つには短期および長期の拡張プランがあります。

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

データリソースについては、短期的にはp2pの改善と多次元ガスを通じて約10-20倍の成長を実現し、長期的にはBlobs + PeerDASを通じて約500倍の成長を実現します。

短期的な拡張は、Ethereumをより速く動かすことに焦点を当てています。現在Ethereumが遅いのは、現在の検証方法が直列的であり、取引を一つずつチェックするためです。もしある取引が詰まると、全体の検証プロセスが詰まってしまいます。

したがって、今年のGlamsterdamアップグレードでは、ブロックアクセスリスト（BAL）とePBSが導入されます。

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

ePBSは、ブロックのパッキングと検証プロセスを分けるもので、ブロックビルダーが取引をパッキングし、提案者がブロックを提案し、検証者がブロックを検証します。それぞれの役割が自分の仕事をしっかりと行うことで、ブロックビルダーはより積極的に多くの取引をパッキングできるようになります。なぜなら、提案者と検証者が彼を助けてくれるからです。

ガス料金の再価格設定 + 多次元ガスは「核心技術」と言えるでしょう。現在、Ethereumのすべての操作は同じガス料金を使用しています。しかし、Vitalikの考えは、異なる操作には異なる価格が必要だということです。

特に、新しい状態を作成すること（例えば新しいアカウントを作成することや新しい契約を展開すること）は特別な「状態作成費」が必要です。なぜなら、新しい状態を作成することは最も高価な操作だからです。それは計算リソースだけでなく、ストレージリソースも占有します。そして、このコストは永続的です。作成されると、その状態はずっと存在し続けます。

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

実現方法は「貯水池メカニズム」です。2つのバケツを想像してください。一つは「状態作成費」を貯め、もう一つは「通常のガス費」を貯めます。契約が相互に呼び出すとき、ガスは自動的に2つのバケツから借りられ、混乱が起こらないようにします。

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

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

Blobsは、一時的な大ファイルストレージで、現在は主にLayer 2に使用されています。将来的には、Ethereumメインネット自身もBlobsを使用してデータを保存します。しかし、問題も発生します。すべてのノードがすべてのBlobsをダウンロードする必要がある場合、ネットワークは圧迫されてしまいます。

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

次に、ZK-EVMの段階的なロールアウトがあり、これによりブロックを検証するためにすべての取引を再実行する必要がなくなります。ノードは直接ZK証明を信じるだけでよく、検証コストは「すべての取引を実行する」から「ZK証明を検証する」に低下します。

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

「特効薬」のない状態拡張

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

Vitalikの答えは、ありません。

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

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

問題はハードディスクに収まるかどうかではなく、以下の点です：

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

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

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

• 「強い状態の無状態性」：ノードは完全な状態を保存する必要はなく、ユーザーがMerkle証明を提供すればよい。Vitalikは、この解決策には状態保存の中央集権化、動的ストレージアクセスによる取引の失敗、帯域幅コストの問題があると考えています。

• 「状態の期限切れ」：あまりアクセスされない状態は、アクティブな状態から自動的に削除されます。ノードは最近アクセスされた状態のみを保存することで、ストレージスペースを大幅に削減できます。Vitalikは、新しい状態を作成する際に「存在しなかったことを証明する」根本的な「存在問題」があると考えています。新しいアカウントを作成する場合、その新しいアカウントのアドレスがEthereum上で一度も作成されていないことを証明する必要があります。これは、各新しいアカウントの作成に対して10年分の履歴データをチェックする必要があり、新しいアカウントの作成が複雑で高価になることを意味します。

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

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

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

• 制限付きストレージ：特定の方法でのみアクセスできるストレージ。例えば、ERC20トークンの残高ストレージは、特定のインターフェースを通じてのみアクセスできるかもしれません。こうすることで、システムはこのストレージを最適化できます。

同時に、既存の状態形式を保持します。こうすることで、実行が1000倍安くなる可能性があります（ZK-EVMを通じて）が、新しい状態の作成は20倍安くなる可能性があります。

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

この戦略は非常に興味深く、開発者がコストを削減するために頭を使い、広範なEthereumユーザーがその恩恵を受けるという意味合いがあります。