スケーリングについて。
短期と長期、2つの側面があります。
短期的なスケーリングについては他で解説していますが、主なポイントは以下です:
ブロックレベルのアクセスリスト(Glamsterdamで導入予定)により、ブロックの並列検証が可能になります。
ePBS(Glamsterdamで導入予定)は多くの機能を備えており、その1つとして、各スロットの大部分を安全にブロック検証に利用できるようになります(従来は数百ミリ秒のみ)。
ガス価格の再設定によって、操作ごとのガスコストが実際の処理時間や負担に合わせて調整されます。多次元ガスの初期導入も進めており、リソースごとに上限を分けることで、特異なケースを恐れずスロットの大部分を使ってブロック検証できるようになります。
多次元ガスには段階的なロードマップがあります。
まずGlamsterdamでは、「状態作成」コストと「実行・calldata」コストを分離します。現在、SSTOREで非ゼロから非ゼロへ変更すると5,000ガス、ゼロから非ゼロへ変更すると20,000ガスですが、Glamsterdamの再設定でこの差分が大幅に増加します(例:60,000ガス)。この施策とガス上限の増加により、状態サイズ容量よりも実行容量を大きく拡張することが目的です。詳細は過去記事(
g-state-by-creating-new-forms-of-state/24052
)をご参照ください。Glamsterdamでは、SSTOREは「通常」ガス5,000と「状態作成ガス」55,000(例)を請求します。
状態作成ガスは約1,600万txガス上限には含まれないため、従来より大きなコントラクト作成が可能です。
課題は、これをEVMでどう扱うかです。EVMのオペコード(GAS、CALLなど)は1次元を前提としていますが、私たちのアプローチは次の通りです。2つの不変条件を維持します:
XガスでCALLを行う場合、そのCALLは「通常」や「状態作成」、将来の他次元にも使えるXガスを持ちます。
GASオペコードでYガスと表示され、XガスでCALLを行っても、CALL後には最低でもY-Xガスが残り、どの機能にも利用可能です(CALL後の後処理にも使えます)。
私たちはN+1「次元」のガスを設定します。デフォルトではN=1(状態作成)で、追加の次元を「リザーバ」と呼びます。EVM実行は、特化次元を優先して消費し、残りはリザーバから消費します。例えば、状態作成ガス100,000・リザーバ100,000の場合、新しい状態をSSTOREで3回作成すると残ガスは(100,000,100,000)→(45,000,95,000)→(0,80,000)→(0,20,000)となります。GASはリザーバを返し、CALLはリザーバから指定ガス量とすべての非リザーバガスを渡します。
今後、多次元の価格設定に移行し、各次元ごとに異なる変動ガス価格を設定できるようになります。これにより長期的な経済的持続性と最適化が実現します(詳細は
vitalik.eth.limo/general/2024/0
)。リザーバの仕組みは記事末尾のサブコール問題を解決します。
長期的なスケーリングでは、ZK-EVMとblobの2つがあります。
blobについては、PeerDASの継続的な改良を進め、最終的には約8MB/秒のデータ処理が可能な状態を目指します。これはEthereumのニーズには十分ですが、グローバルなデータレイヤーを目指すものではありません。現在、blobはL2用ですが、将来的にはEthereumブロックデータが直接blobに格納される予定です。これにより、Ethereumチェーンをハイパースケールで検証する際、個人的なダウンロードや再実行が不要になります。ZK-SNARKによって再実行が不要となり、PeerDASによるblobで個人のダウンロードなしにデータの可用性を検証できます。
ZK-EVMについては、段階的に「信頼度」を高めていくことが目標です:
2026年にはZK-EVMでアテスターとして参加できるクライアントが登場します。これだけではネットワーク運用に十分な安全性はありませんが、ネットワークの5%程度が依存するなら問題ありません(ZK-EVMが壊れてもスラッシュされず、無効ブロック上に構築して収益を失うリスクのみ)。
2027年にはネットワークのより大きな少数派がZK-EVMで運用することを推奨し、同時に正式な検証やセキュリティ最大化に注力します。ネットワークの20%がZK-EVMを利用するだけでもガスリミットを大幅に増やせます。これはソロステーカー(20%未満)が安価なパスを得られるためです。
準備が整えば、3-of-5の強制証明方式に移行します。ブロックが有効であるためには、異なる証明システムから5種類中3種類の証明を含める必要があります。この段階では、全ノード(インデックスが必要なノードを除く)がZK-EVM証明に依存することが期待されます。
ZK-EVMの改良を続け、堅牢性や正式検証などを最大限に高めます。これにはVM変更(例:RISC-V)も含まれます。





