原文作者:@VitalikButerin
翻訳:Peggy,BlockBeats
エディター注:イーサリアムエコシステムが拡大していく中で、安全性と分散性を犠牲にすることなくネットワークのスケーリングを実現する方法が中心的なテーマとなっています。本文では、Vitalik Buterin がイーサリアムのスケーリングパスについてさらに詳細に説明し、Gas メカニズムの最適化、ブロック検証の並列化などの技術改良による実行効率の向上を短期的な手段とし、長期的には ZK-EVM と blobs データ構造によるネットワークのスケールアップを推進することを述べています。
全体として、このロードマップは段階的なスケーリングソリューションを提供し、将来数年間にわたってイーサリアムのネットワーク容量拡大の基盤を提供することを目的としています。
以下は原文です:
では、スケーリングについて話しましょう。ここでは、主に短期的なスケーリングと長期的なスケーリングに分けます。
短期的なスケーリングに関しては、すでに他の場所でいくつか書いてきました。主なアイデアは以下の通りです:
・ブロックレベルのアクセスリスト(block-level access lists)(Glamsterdam アップグレードで導入予定)は、ブロック検証を並列化することが可能になります。
・ePBS(これも Glamsterdam で導入予定)には複数の機能があり、そのうちの1つは、各スロットでブロックの検証により大きな割合の時間を安全に使用できるようにし、現在の数百ミリ秒だけではなくなりました。
・Gas の再定価(gas repricing)は、さまざまな操作のガスコストが実際の実行時間(およびその他のコスト)と一致するようにします。また、多次元ガス(multidimensional gas)メカニズムの初期段階の探索も行っており、異なるリソースにそれぞれ上限を設定できるようにしています。これらのアプローチを組み合わせることで、極端なケースを心配することなく、ブロックの検証時にスロット時間の大割合を使用できます。
多次元ガスに関して、段階的なロードマップを策定しています。最初の段階は、Glamsterdam アップグレードで、「状態生成コスト」と「実行および calldata コスト」を分離することです。
たとえば、現在:SSTORE 操作は、ゼロから非ゼロになる場合のコストが 5000 gas、非ゼロから非ゼロになる場合のコストが 20000 gas です。
Glamsterdam でのガスの再評価では、この追加コストが著しく増加します(たとえば、60000 に増加)。この目的は、ガス上限を引き上げる一方で、実行能力の拡張速度を状態規模の拡張速度よりもはるかに高く保つことです。
理由に関しては、以前に書いたことがあります:https://ethresear.ch/t/hyper-scaling-state-by-creating-new-forms-of-state/24052
したがって、Glamsterdam では:この SSTORE 操作には5000 の「通常のガス」が消費され、たとえば55000 の「状態作成ガス」があります
注意すべき点:状態作成ガスは、約 16 ミリオンのトランザクションガス上限に含まれません。
これはつまり:現在よりも大きなコントラクトを作成することが可能になります。
ここで問題が生じます:EVM の設計では、ガスはデフォルトで単一の次元しかないため、GAS、CALL などの opcode はすべてこの仮定に基づいています。
私たちの解決策は、2 つの不変量を維持することです:
X ガスを使用して call を行うと、その call は X ガスを持ち、「通常の操作」や「状態作成」、または将来追加されるかもしれない他の次元に使用できます。
GAS opcode が現在のガス量を Y と示し、X ガスを消費する call を行った場合、call が返された後も、少なくとも Y − X ガスを保持し、後続の操作に使用できます。
具体的な実装方法は:私たちは N+1 個のガス次元を導入します。デフォルトでは N = 1(状態作成)、追加の次元は reservoir(貯蓄プール)と呼ばれます。
EVM の実行ロジックは:
可能な場合は、特定の次元のガスを優先的に消費します
不足的情况下,再从 reservoir 中消费。
例如,如果您拥有:(100,000 状态创建 gas,100,000 reservoir)
如果您使用 SSTORE 创建三个新状态,则 gas 的变化如下:(100,000,100,000)→(45,000,95,000)→(0,80,000)→(0,20,000)
在这种设计中:
GAS 操作码返回的是 reservoir
CALL 会从 reservoir 中传递指定数量的 gas,并同时传递所有非 reservoir gas
之后,我们将引入多维定价(multi-dimensional pricing),使不同资源维度具有不同的浮动 gas 价格。
这将带来:
更好的长期经济可持续性
更优的资源配置效率
详见:https://vitalik.eth.limo/general/2024/05/09/multidim.html
而 reservoir 机制恰好解决了该文最后提到的子调用(sub-call)问题。
长期扩展主要包括两个方向:ZK-EVM 和 Blobs。
对于 blobs,我们计划持续迭代 PeerDAS,最终希望达到大约每秒 8 MB 的数据吞吐能力。
这一规模:
足以满足以太坊自身需求
并非旨在成为“全球数据层”。
現在、blobs は主に L2 で使用されています。将来の計画は、イーサリアムブロックのデータ自体を blobs に直接書き込むことです。
この取り組みの目的は、イーサリアムネットワークの高度にスケーラブルな状態を検証する際に、ユーザーが全体のチェーンをダウンロードして再実行する必要がないようにすることです:
ZK-SNARK により再実行が不要になりました
PeerDAS + blobs により、データの可用性を検証するためにすべてのデータをダウンロードする必要はありません
ZK-EVM に関して、我々の目標は徐々にそのネットワークへの依存度を高めることです。
2026 年:ZK-EVM をサポートするクライアントが登場し、ノードが ZK-EVM を使用してアテステーションに参加できるようになります。しかし、それらはまだ十分に安全ではなく、ネットワーク全体を依存させることはできません。ただし、そのようなクライアントを約 5% のネットワークが使用することは許容されます。(ZK-EVM に問題がある場合、あなたは罰せられず、賭け金を失う可能性がありますが、無効なブロックに構築される可能性があります。)
2027 年:より多くのノードが ZK-EVM を実行することを推奨し始めます。同時に、形式検証とセキュリティの向上に焦点を当てます。ネットワークの約 20% が ZK-EVM を使用している場合でも、solo staker に低コストな検証パスが提供されるため、ガスリミットを大幅に引き上げることができます。また、実際の solo staker の割合も 20% 未満です。
技術が成熟した後:3-of-5 強制証明メカニズムを導入します。つまり、ブロックは 5 つの異なる証明システムのうち少なくとも 3 つの証明を含んでいる必要があります。その時点で、索引を作成する必要があるノード以外のほとんどのノードは ZK-EVM 証明に依存すると予想されます。
長期的には、ZK-EVM をさらに改善し、より堅牢なものにし、より厳格な形式検証を行います。この段階では、RISC-V などの方向性など、仮想マシンレベルでの変更も考慮される可能性があります。
詳細はこちら: https://ethresear.ch/t/hyper-scaling-state-by-creating-new-forms-of-state/24052
BlockBeats の公式コミュニティに参加しよう:
Telegram 公式チャンネル:https://t.me/theblockbeats
Telegram 交流グループ:https://t.me/BlockBeats_App
Twitter 公式アカウント:https://twitter.com/BlockBeatsAsia