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ユーザーがその恩恵を受けるという意味合いがあります。