2026年2月27日、Vitalik ButerinはEthereum Researchに「Hyper-scaling state by creating new forms of state」というタイトルの長文を投稿した。
本記事でヴィタリク・ブテリンは、イーサリアムのスケーリングパスウェイをさらに整理した。この記事は、技術的な観点からイーサリアムのスケーリングを論じるだけでなく、全体的なアーキテクチャの観点から、今後数年間におけるイーサリアムのネットワーク容量の持続的な拡大を支えるための段階的なスケーリング戦略を提供している。
同時に、彼はX上でツイートを投稿し、この記事をさらに説明しました。私たちは、Vitalikが今回新たに提案した拡張方案が何であり、なぜそのような措置を取ろうとしているのかを、わかりやすく深く理解しようと試みています。
短期および長期におけるリソースとデータリソースの拡張
ビタリックは長文の冒頭で、「今後5年間でイーサリアムを拡張するには、3つのリソースを拡張する必要がある」と指摘した。
- 実行リソース：EVM計算、署名検証など
- データリソース：送信者、受信者、署名など
- 状態リソース：アカウント残高、コード、ストレージ
前者と後者は、短期および長期の拡張計画を持っています。
リソース実行については、短期的にはブロックアクセスリスト（BAL）、ePBS、ガス料金の再定価によって約10～30倍の向上を実現し、長期的にはZK-EVMによって約1000倍の向上を達成します。また、特定の計算タイプ（署名、SNARK/STARK）については、オフチェーン集約により性能が約10000倍向上します。
データリソースに関して、短期的にはP2Pの改善と多次元ガスにより10〜20倍の成長を実現し、長期的にはBlobs + PeerDASにより約500倍の成長を実現します。
短期的な拡張は、イーサリアムの処理速度を向上させることに焦点を当てています。現在、イーサリアムの処理が遅いのは、検証方式が直列であるためです——取引を1つずつ確認します。ある取引が詰まると、全体の検証プロセスが停止してしまいます。
したがって、今年のGlamsterdamアップグレードでは、ブロックアクセスリスト（BAL）とePBSが導入されます。
ブロックアクセスリストにより、ブロック構築者はバリデーターに事前に通知できます：「このブロック内の取引は、これらのアカウントとストレージ位置にアクセスします」。この情報により、バリデーターは事前にこれらのデータをハードディスクからメモリに読み込む準備ができます。その後、バリデーターは取引を1つずつ確認するのではなく、複数の取引を並列で確認できます。工場の生産ラインのように、以前は1人の作業者が製品全体を担当していましたが、今は複数の作業者が異なる部分を同時に処理します。
ePBSは、ブロックのパッキングと検証のプロセスを分離します——ブロック構築者が取引をパッキングし、プロポーザーがブロックを提案し、バリデーターがブロックを検証します。各役割がそれぞれの責任を果たせば、ブロック構築者はプロポーザーとバリデーターがセキュリティをチェックしてくれるため、安全性を気にすることなく、より積極的に多くの取引をパッキングできます。
ガス料金の再定価 + 多次元ガスは、「核となる技」と言えるでしょう。現在、イーサリアムのすべての操作は同じガス料金を使用していますが、ビタリクの考えでは、異なる操作には異なる価格が適用されるべきです。
特に、新状態の作成（たとえば、新規アカウントの作成や新規コントラクトのデプロイ）には、特別な「状態作成手数料」が必要です。なぜなら、新状態の作成は最もコストのかかる操作だからです。これは計算リソースだけでなく、ストレージリソースも消費します。さらに、このコストは永続的です——一度作成されると、その状態は永久に存在し続けます。
したがって、Vitalikの考えは、新しい状態を作成することをより高価にし、通常の取引をより安価にすることです。
実装方法は「貯水池メカニズム」です。二つのバケツを想像してください。一つは「ステータス作成料」を格納し、もう一つは「通常のガス料」を格納します。コントラクトが相互に呼び合う際、ガスは自動的にこの二つの貯水池から借りられ、混乱を防ぎます。
一般ユーザーの取引は「ステータス作成料」がかからないため、より安くなります。一方、新しいステータスを作成したい開発者は、より高い料金を支払う必要があります。これにより、ネットワーク全体の容量が大幅に増加し、ステータスの増加は制御され、フルノードのハードディスクが過負荷になることを防ぎます。
長期的な拡張は、メインネット自体を強化し、Layer 2への依存を減らすことです。これには、Blobs + PeerDASとZK-EVMの段階的なロールアウトが含まれます。
Blobsは一時的な大容量ファイルストレージで、現在は主にLayer 2で使用されています。今後、イーサリアムメインネット自体もBlobsを使ってデータを格納するようになります。しかし、その一方で問題も生じます——すべてのノードがすべてのBlobsをダウンロードすると、ネットワークが過負荷になります。
ここで活躍するのがPeerDASです。すべてのデータをダウンロードするのではなく、一部だけをダウンロードすれば済みます。サンプリング調査のように、全員に質問するのではなく、一部の人々に質問するだけで、全体の状況を推測できます。ZK証明と組み合わせることで、すべてのデータの1/16だけをダウンロードしても、データの整合性を確認できます。
次に、ZK-EVM の段階的なロールアウトにより、ブロックの検証にあたってブロック内のすべてのトランザクションを再実行する必要がなくなり、ノードはZK証明をそのまま信頼するだけでよくなりました。これにより、検証コストは「すべてのトランザクションを実行する」から「1つのZK証明を検証する」へと削減されました。
ヴィタリックの計画では、2026年に一部のノードでZK検証を試験的に導入し、2027年にはより多くのノードの使用を促進します。最終的には、有効なブロックには、異なる証明システムからの5種類の証明のうち3種類が含まれる必要があります。彼は、すべてのノード（インデックスノードを除く）が最終的にZK-EVM証明に依存すると予想しています。
状態の拡張には「万能薬」はありません
では、短期と長期の拡張においてまだ触れていない「ステータスリソース」を見てみましょう。短期的には、ブロックアクセスリストとの同期やP2Pの改善、データベースの最適化などにより、約5〜30倍の向上が可能ですが、長期的にはどうでしょうか？
ビタリックの答えは、いいえです。
なぜステータスリソースの拡張がこれほど難しいのか？イーサリアムのステータスは、巨大なデータベースのようなものである。このデータベースには、すべてのアカウントの残高、すべてのスマートコントラクトのコード、すべてのストレージ位置のデータが格納されている。
現在このデータベースはまだ小さく、約100GBですが、状態を20倍に拡張すると2TBになります。さらに時間が経つとどうなるでしょうか？8TB？
問題はハードディスクが容量不足であることにではなく、
- データベースの効率が影響を受ける：現代のデータベースは、データを整理するためにツリー構造（例：Merkleツリー）を使用しています。新しいデータを書き込む際には、ツリー全体を更新する必要があります。つまり、X回の更新を行うと、データベースレベルでもX回の操作が発生し、1回の更新でデータベース操作が1回で済むわけではありません。更新が増えるほど操作が増え、書き込み速度が急激に遅くなります。
同期の難しさ：新しいイーサリアムネットワークノードは、新しいブロックを検証するために、全体のステートをダウンロードする必要があります。データ量が8TBに達すると、現在のほとんどのネットワーク速度では非常に長い時間がかかります。
解決策は存在するが、Vitalikはそれらすべてに問題があると考えている：
- 「強状態非状態性」：ノードは完全な状態を保存する必要はなく、ユーザーがMerkle証明を提供すればよい。Vitalikは、このソリューションには状態保存の中心化、動的ストレージアクセスによるトランザクション失敗、および帯域幅コストの問題があると考えている。
- 「状態の有効期限切れ」：頻繁にアクセスされない状態は、自動的にアクティブ状態から削除されます。ノードは最近アクセスされた状態のみを保存すれば、ストレージスペースを大幅に削減できます。ヴィタリックは、根本的な「問題」、すなわち新しい状態を作成する際に、ある状態が「かつて存在しなかった」ことをどう証明するかという問題が存在すると考えています。たとえば、新しいアカウントを作成する場合、そのアカウントのアドレスがイーサリアム上でかつて作成されたことがないことを証明する必要があります。これは、新しいアカウントの作成ごとに10年分の履歴データを確認する必要があることを意味し、新しいアカウントの作成が複雑で高コストになります。
ビタリックの最終的な方法は、この2つの案を組み合わせて、イーサリアムのステートリソースアーキテクチャ全体の変更となるいくつかの新しいステート形式を提案することである：
一時保存：自動的に有効期限が切れる保存方式です。たとえば、毎月自動的にリセットされる新しいツリーを作成できます。この保存方式は、注文簿、流動性プール、一時カウンターなどの一時的なデータに適しています。これらのデータは通常、永続的な保存を必要とせず、1か月後には古い注文が期限切れになり、新しい流動性プールが作成されます。
- サイクルストレージ：一時ストレージと同様ですが、サイクルがより長く、例えば1年です。
制限付きストレージ：一部のストレージは特定の方法でのみアクセス可能です。たとえば、ERC20トークンの残高ストレージは、特定のインターフェースからのみアクセスできる場合があります。これにより、システムはこのようなストレージを最適化できます。
同時に、既存の状態形式を維持します。これにより、実行は最大1000倍安くなる可能性があります（ZK-EVMを通じて）、しかし新しい状態の作成は最大20倍しか安くなりません。
Vitalikは、新しい状態形式により、開発者は選択肢を得たと述べています。既存の状態形式をそのまま使用してより高い手数料を支払うか、アプリケーションを再設計して新しい状態形式を使用し、手数料を削減するかです。一般的なユースケース（例：ERC20残高、NFT）には標準化されたワークフローが用意されますが、より複雑なユースケース（例：DeFi）では、開発者が自ら最適化の方法を考える必要があります。
この戦略は非常に興味深く、開発者が頭を働かせてコストを削減し、広範なイーサリアムユーザーが恩恵を受けるような印象です。