イーサリアムがスケーリングロードマップを公開、今回は何が違うのか?

原作者: @VitalikButerin
翻訳：ペギー、ブロックビーツ

編集者注:Ethereum エコシステムが成長を続けるにつれ、セキュリティと分散化を犠牲にすることなくネットワークのスケーラビリティを実現することが重要な課題となっています。この記事では、Vitalik Buterin が Ethereum のスケーラビリティ パスについてさらに詳しく説明しています。短期的には、ガス メカニズムの最適化、ブロック検証の並列化、その他の技術的アップグレードを通じて実行効率を向上させ、長期的には、ZK-EVM と BLOB データ構造に依存してネットワークのスケーラビリティを推進します。

全体として、このロードマップは、今後数年間にイーサリアムがネットワーク容量を継続的に拡大するための基盤を築くように設計された段階的なスケーラビリティ プランを提供します。

以下は原文です。

それではスケーリングについてお話ししましょう。主に短期スケーリングと長期スケーリングの 2 つの部分に分けられます。

短期的なスケーリング

短期的なスケーリングに関しては、他の場所で書きました。核となる考え方はおおよそ次のとおりです。

· ブロック レベルのアクセス リスト (Glamsterdam アップグレードで導入される予定) により、ブロック検証の並列化が可能になります。

· ePBS (Glamsterdam でも導入予定) には複数の機能があり、その 1 つは、現在のように数百ミリ秒だけを使用するのではなく、各スロットでブロックを検証するためにより長い時間を安全に使用できることです。

· ガス価格の再設定により、さまざまな操作のガス コストが実際の実行時間 (および発生するその他のコスト) と一致するようになります。また、私たちは、異なるリソースに個別の制限を持たせることができる多次元ガスメカニズムの調査の初期段階にあります。これら 2 つを組み合わせることで、極端なシナリオを心配することなく、ブロック検証にスロット時間のより大きな割合を使用できるようになります。

多次元ガスに関しては、段階的なロードマップを策定しました。最初のフェーズは Glamsterdam アップグレードで、「状態セットアップ コスト」が「実行および呼び出しデータ コスト」から分離されます。

たとえば、現在、SSTORE 操作では、ストレージ スロットがゼロ以外からゼロ以外に変更されると 5000 GAS かかります。ゼロからゼロ以外に変更されると 20000 GAS かかります。

グラムスターダムでのガス価格再設定イベントでは、この追加コストが大幅に増加します（例：60000 に増加）。その目的は、実行能力の拡大率を状態規模の拡大率よりも大幅に高くしながらコストを上げることです。

理由については、以前にも書きました： https://ethresear.ch/t/hyper-scaling-state-by-creating-new-forms-of-state/24052

したがって、Glamsterdamでは、この SSTORE 操作では、5000 の「ベース ガス」、たとえば 55000 の「状態作成ガス」が消費されます。

以下の点に注意することが重要です。ステート作成ガスは、約 1,600 万のトランザクション ガス制限にはカウントされません。

これはつまり：現在よりも大規模な契約の作成が可能になります。

EVM では多次元ガスはどのように実現されるのでしょうか?

ここに問題があります:EVM の設計では、ガスは 1 次元のみであると想定されています。たとえば、GAS、CALL、およびその他のオペコードはすべてこの想定に基づいています。

私たちの解決策は、2 つの不変条件を維持することです。

X ガスを使用して呼び出しを開始すると、その呼び出しでは「基本操作」、「状態の作成」、または将来の潜在的な追加ディメンションに X ガスが使用できるようになります。

GAS オペコードによって現在 Y ガスがあることが示され、その後 X ガスを消費する呼び出しを開始した場合、呼び出しが戻った後も、後続の操作に使用できるガスが少なくとも Y − X 残っています。

具体的な実装は次のとおりです。N+1 ガス次元を導入します。デフォルトでは、N = 1 (状態の作成) であり、追加の次元はリザーバーと呼ばれます。

EVM の実行ロジックは次のとおりです。

可能であれば、専用のディメンションからのガス消費を優先してください。

足りない場合は貯水タンクから消費してください。

たとえば、次のような場合です。（100000状態生成ガス、100000貯留層）

SSTORE を使用して 3 つの新しい状態を作成する場合、ガス変換プロセスは次のようになります。(100000, 100000) → (45000, 95000) → (0, 80000) → (0, 20000)

このデザインでは:

GASオペコードはリザーバーを返す

CALLは、貯留層から指定された量のガスと貯留層外のガスをすべて通過させます。

多次元ガス価格設定

今後は、さらに多次元の価格設定を導入し、異なるリソース次元に異なる変動ガス価格を設定できるようにします。

これにより、次のことが実現します。

長期的な経済の持続可能性の向上

最適化されたリソース割り当て効率

詳細はこちらをご覧ください: https://vitalik.eth.limo/general/2024/05/09/multidim.html

リザーバー メカニズムにより、この記事の最後で説明したサブ呼び出しの問題が適切に解決されます。

長期的なスケーリング

長期的なスケーリングには主に 2 つの方向が含まれます。ZK-EVM と Blob。

ブロブ

BLOB については、PeerDAS の反復作業を継続し、最終的に約 8 MB/秒のデータ スループットを達成することを目指します。

このスケール:

イーサリアム自身のニーズを満たすのに十分である

また、「グローバル データ レイヤー」になることを意図したものではありません。

現在、BLOB は主に L2 に使用されています。将来の計画では、Ethereum ブロックデータ自体を BLOB に直接書き込む予定です。

これを行う目的は、チェーン全体をダウンロードして再実行することなく、高度にスケーラブルな Ethereum ネットワークを検証できるようにすることです。

ZK-SNARKは再実行の必要性を排除します

PeerDAS + BLOB により、すべてのデータをダウンロードせずにデータの可用性を検証できます。

ZK-EVM

ZK-EVM に関しては、ネットワークの ZK-EVM への依存を徐々に高めていくことを目標としています。

2026年:ZK-EVM をサポートするクライアントが登場し、ノードが ZK-EVM による認証に参加できるようになります。ただし、ネットワーク全体の運用をこれらに依存できるほど十分に安全ではありません。ただし、ネットワークの約 5% が使用している場合は許容範囲です。(ZK-EVM に問題がある場合、スラッシングでペナルティは課せられませんが、無効なブロック上に構築され、収益が失われる可能性があります。)

2027年:形式検証とセキュリティ強化に重点を置きながら、より多くのノードで ZK-EVM を実行することを推奨する予定です。ネットワークの 20% のみが ZK-EVM を使用する場合でも、ソロ ステーカーに低コストの検証パスが提供され、ソロ ステーカーの割合が 20% 未満であるため、ガス制限を大幅に増やすことができます。

技術的成熟度後:3/5 の強制証明メカニズムを導入します。つまり、ブロックが有効と見なされるには、5 つの異なる証明システムからの少なくとも 3 つの証明が含まれている必要があります。その時までに、インデックス作成が必要なノードを除いて、ほとんどのノードが ZK-EVM 証明に依存するようになると予想されます。

長期的:ZK-EVM をさらに堅牢なものにし、より厳格な形式検証を実施できるよう、引き続き改善していきます。この段階では、RISC-V の方向性など、仮想マシン レベルでの変更も含まれる可能性があります。

参照: https://ethresear.ch/t/hyper-scaling-state-by-creating-new-forms-of-state/24052

[元記事リンク]