2026年2月27日、Vitalik ButerinはEthereum Researchに「Hyper-scaling state by creating new forms of state（通过创建新形式的状态来超级扩展状态）」という長文を投稿した。
この記事でVitalik Buterinは、イーサリアムのスケーリングパスウェイをさらに整理しました。この記事は、イーサリアムのスケーリングを技術的な観点からだけではなく、全体的なアーキテクチャの観点から、今後数年間におけるネットワーク容量の継続的な拡大のための段階的なスケーリングソリューションを提供しています。
同時に、彼はX上でツイートを投稿し、この記事をさらに説明しました。私たちは、Vitalikが今回新たに提案した拡張方案が何であり、なぜそのような対応を取ったのかを、わかりやすく深く理解しようと試みています。
短期および長期におけるリソースとデータリソースの拡張
Vitalikは長文の冒頭で、「今後5年間でイーサリアムを拡張するには、3つのリソースを拡張する必要がある」と指摘した。
- 実行リソース：EVM計算、署名検証など
- データリソース：送信者、受信者、署名など
- 状態リソース：アカウント残高、コード、ストレージ
前者と後者は、短期および長期の拡張計画を持っています。
リソース実行については、短期的にはブロックアクセスリスト（BAL）、ePBS、ガス料金の再定価によって約10～30倍の向上を実現し、長期的にはZK-EVMによって約1000倍の向上を実現します。また、特定の計算タイプ（署名、SNARK/STARK）については、オフチェーン集約によりパフォーマンスが約10000倍向上します。
データリソースについては、短期的にはP2Pの改善とマルチディメンショナルGasにより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年分の履歴データを確認する必要があることを意味し、新しいアカウントの作成が複雑で高コストになります。
ビタリックの最終的な方法は、这两种方案を組み合わせて、イーサリアムの状態リソースアーキテクチャ全体の変更となるいくつかの新しい状態形式を提案することです：
- 一時保存：自動的に有効期限が切れる保存方式です。たとえば、毎月自動的にリセットされる新しいツリーを作成できます。この保存方式は、注文簿、流動性プール、一時的なカウンターなどの一時的なデータに使用できます。これらのデータは通常、永続的に保存する必要がなく、1か月後には古い注文が期限切れになり、新しい流動性プールが作成されます。
- サイクルストレージ：一時ストレージと同様ですが、サイクルがより長く、例えば1年です。
- 制限付きストレージ：一部のストレージは特定の方法でのみアクセス可能です。たとえば、ERC20トークンの残高ストレージは、特定のインターフェースでのみアクセスできる場合があります。これにより、システムはこのようなストレージを最適化できます。
同時に、既存の状態形式を保持します。これにより、実行は最大1000倍安くなる可能性があります（ZK-EVM経由）、しかし新しい状態の作成は最大20倍しか安くなりません。
Vitalikは、新しい状態形式が導入されることで、開発者は選択肢を持つことになると述べています。既存の状態形式をそのまま使い、より高い手数料を支払うか、新しい状態形式を活用してアプリケーションを再設計し、手数料を削減するかです。一般的なユースケース（例：ERC20残高、NFT）には標準化されたワークフローが用意されますが、より複雑なユースケース（例：DeFi）では、開発者が自ら最適化策を考案する必要があります。
この戦略は非常に興味深く、開発者が頭を働かせてコストを削減し、広範なイーサリアムユーザーが恩恵を受けるような雰囲気があります。
律動 BlockBeats 公式コミュニティへようこそ：
Telegram サブスクリプショングループ：https://t.me/theblockbeats
Telegram コミュニティ：https://t.me/BlockBeats_App
Twitter公式アカウント：https://twitter.com/BlockBeatsAsia