イーサリアムの可能な未来：The Surge

サージ：重要な目標

1. 将来のイーサリアムはL2を通じて10万以上のTPSに達することができます；

2. L1 の分散化と堅牢性を維持する；

3. 少なくともいくつかのL2はイーサリアムのコア特性（信頼不要、オープン、検閲耐性）を完全に継承しています；

4. イーサリアムは34の異なるブロックチェーンではなく、統一されたエコシステムのように感じるべきです。

! ヴィタリックニュース:イーサリアムの可能な未来、急上昇

この章の内容

1. スケーラビリティの三角矛盾
2. データ可用性サンプリングのさらなる進展
3. データ圧縮
4. 一般化されたプラズマ
5. 成熟した L2 プルーフシステム
6. クロスL2相互運用性の改善
7. L1での実行の拡張

スケーラビリティのトリレンマ

スケーラビリティの三角パラドックスは2017年に提唱された考え方で、ブロックチェーンの3つの特性の間に矛盾が存在するとしています：非中央集権（より具体的には、ノードを運営するコストが低い）、スケーラビリティ（処理する取引の数が多い）、およびセキュリティ（攻撃者は単一の取引を失敗させるためにネットワーク内のかなりの部分のノードを破壊する必要がある）。

注意すべきは、三角パラドックスは定理ではなく、三角パラドックスを紹介する投稿にも数学的証明は付随していないということです。確かに、次のようなヒューリスティックな数学的議論を提供しています：もし、分散型フレンドリーなノード（例えば、消費者向けのノートパソコン）が1秒あたりN件の取引を検証でき、あなたが1秒あたりk*N件の取引を処理するチェーンを持っている場合、（i）各取引は1/kのノードによってのみ見ることができる、つまり攻撃者は悪意のある取引を通過させるために少数のノードを破壊すればよい、または（ii）あなたのノードは強力になり、あなたのチェーンは去中心化しなくなる。この論文の目的は、三角パラドックスを破ることが不可能であることを証明することではありません。むしろ、三元パラドックスを打破することが困難であり、ある程度その議論が暗示する思考フレームワークから飛び出す必要があることを示すことです。

! Vitalik新記事:イーサリアムの可能な未来、急上昇

長年にわたり、一部の高性能チェーンは、根本的なアーキテクチャを変更することなくトリレンマを解決したと主張していますが、通常はソフトウェアエンジニアリングの技術を用いてノードを最適化しています。これは常に誤解を招くもので、これらのチェーン上でノードを運営することは、イーサリアム上でノードを運営するよりもはるかに困難です。本記事では、なぜそうなのか、また、L1クライアントソフトウェアエンジニアリング自体だけではイーサリアムをスケールさせることができない理由について探ります。

しかし、データ可用性サンプリングとSNARKの組み合わせは、確かに三角パラドックスを解決します：クライアントは、少量のデータをダウンロードし、非常に少ない計算を実行するだけで、一定量のデータが利用可能であり、一定の計算ステップが正しく実行されたことを検証できます。SNARKは信頼のないものです。データ可用性サンプリングは微妙なfew-of-N信頼モデルを持っていますが、51％攻撃でさえ悪意のあるブロックがネットワークに受け入れられることを強制できないという、非拡張チェーンが持つ基本的な特性を保持しています。

三つの難題を解決する別の方法は、Plasmaアーキテクチャであり、これは巧妙な技術を使用して、ユーザーに監視データの可用性の責任をインセンティブに適合する方法で押し付けます。2017年から2019年にかけて、詐欺証明のみを使用して計算能力を拡張する手段があったとき、Plasmaは安全な実行に関して非常に制限されていましたが、SNARKs（ゼロ知識簡潔非対話証明）の普及に伴い、Plasmaアーキテクチャは以前よりも広範な使用シナリオに対してより実行可能になりました。

データの可用性サンプリングのさらなる進展

私たちはどのような問題を解決していますか？

2024年3月13日にDencunがアップグレードしてオンラインになると、12秒ごとのスロットには約125 kBのblobが3つあり、各スロットのデータ利用可能帯域幅は約375 kBです。取引データが直接チェーン上に公開されると仮定すると、ERC20の送金は約180バイトですので、Rollup上の最大TPSは：375000 / 12 / 180 = 173.6 TPS

もし私たちが加えた calldata（理論的最大値：各スロット 3000 万 Gas / 各バイト 16 gas = 各スロット 1,875,000 バイト）であれば、607 TPS になります。PeerDAS を使用すると、blob の数は 8-16 に増える可能性があり、これにより calldata に対して 463-926 TPS を提供します。

これはL1に対する重大な改善ですが、まだ不十分です。私たちはより多くのスケーラビリティを求めています。私たちの中期目標は、各スロット16 MBであり、Rollupデータ圧縮の改善と組み合わせることで、約58000 TPSを実現します。

! Vitalik News:イーサリアムの可能な未来、急増

それは何ですか？どのように機能しますか？

PeerDASは"1D sampling"の相対的に簡単な実装です。ここでは、各blobが253ビット素数体（prime field）上の4096次多項式（polynomial）です。私たちは多項式のシェアをブロードキャストします。その中で、各シェアは合計8192個の座標から隣接する16個の座標の16個の評価値を含みます。この8192個の評価値の中で、任意の4096個（現在提案されているパラメータに基づいて：128個の可能なサンプルからの任意の64個）がblobを復元することができます。

PeerDASの動作原理は、各クライアントが少数のサブネットを監視し、i番目のサブネットが任意のblobのi番目のサンプルをブロードキャストし、グローバルp2pネットワーク内のピア（異なるサブネットを監視する人々）に対して必要な他のサブネットのblobを要求することです。より保守的なバージョンのSubnetDASは、追加のピア層の問い合わせなしにサブネットメカニズムのみを使用します。現在の提案は、ステークプルーフに参加しているノードがSubnetDASを使用し、他のノード（つまりクライアント）がPeerDASを使用することです。

理論的には、「1Dサンプリング」の規模をかなり大きく拡張できます：もし私たちがblobの最大数を256に増やす（目標は128）と、16MBの目標を達成でき、データ可用性サンプリングでは各ノードが16サンプル * 128 blob * 各blobの各サンプル512バイト = 各スロット1MBのデータ帯域幅を持ちます。これは私たちの許容範囲のぎりぎりです：これは実行可能ですが、帯域幅が制限されたクライアントはサンプリングできません。blobの数を減らし、blobのサイズを増やすことで、ある程度の最適化を行うことができますが、これは再構築コストを高めることになります。

したがって、私たちは最終的にさらに進んで、2Dサンプリング（2D sampling）を行いたいと考えています。この方法は、blob 内でのランダムサンプリングだけでなく、blob 間でのランダムサンプリングも行います。KZGコミットメントの線形特性を利用して、一つのブロック内のblobセットを新しい仮想blobのセットを用いて拡張し、これらの仮想blobは同じ情報を冗長的にエンコードしています。

したがって、最終的に私たちはさらに進み、2Dサンプリングを行いたいと考えています。これは blob 内だけでなく、blob 間でもランダムサンプリングを行います。KZG のコミットメントの線形特性を使用して、同じ情報を冗長にエンコードした新しい仮想 blob リストを含むブロック内の blob 集を拡張します。

! Vitalik新記事:イーサリアムの可能な未来、急上昇

重要なのは、コミットメントの拡張に blob が必要ないため、このスキームは根本的に分散型ブロック構築に対してフレンドリーであるということです。実際にブロックを構築するノードは、blob KZG コミットメントを持っているだけでよく、データの可用性サンプリング（DAS）に依存してデータブロックの可用性を検証できます。一次元データ可用性サンプリング（1D DAS）も本質的に分散型ブロック構築にフレンドリーです。

まだ何をする必要がありますか？どんなトレードオフがありますか？

次に、PeerDAS の実施と導入を完了させます。その後、PeerDAS 上の blob の数を増やし続けながら、ネットワークを注意深く観察し、安全を確保するためにソフトウェアを改善することは、段階的なプロセスです。また、同時に、PeerDAS および他のバージョンの DAS とそのフォーク選択ルールの安全性などの問題との相互作用を規定するために、より多くの学術研究を期待しています。

将来的な段階では、2D DAS の理想的なバージョンを特定し、その安全属性を証明するために、さらに多くの作業を行う必要があります。また、最終的には KZG から量子安全で信頼できる設定を必要としない代替手段に移行できることを望んでいます。現在、分散型ブロック構築に対して友好的な候補がどれかは不明です。高価な "暴力的" 技術を使用しても、再帰的 STARK を使用して行や列を再構築するための有効性証明を生成するだけでは、需要を満たすには不十分です。技術的には、STARK のサイズは O(log(n) * log(log(n)) ハッシュ値（STIR を使用）ですが、実際には STARK はほぼ全体の blob と同じ大きさです。

私が考える長期的な現実の道筋は：

1. 理想的な 2D DAS を実装します。
2. 1D DASを使用し続け、サンプリング帯域幅の効率を犠牲にし、シンプルさと堅牢性のために低いデータ上限を受け入れる。
3. DAを放棄し、Plasmaを私たちの主要なLayer2アーキテクチャとして完全に受け入れる。

注意してください。たとえ私たちが L1 層での直接的な拡張実行を決定した場合でも、その選択肢は存在します。これは、L1 層が大量の TPS を処理する必要がある場合、L1 ブロックが非常に大きくなり、クライアントがそれらの正確性を検証するための効率的な方法を希望するためです。そのため、私たちは L1 層で Rollup（ZK-EVM や DAS など）と同じ技術を使用する必要があります。

どのようにロードマップの他の部分と相互作用しますか？

データ圧縮が実現されれば、2D DAS の需要は減少するか、少なくとも遅延するでしょう。Plasma が広く使用されると、需要はさらに減少します。DAS は分散型ブロック構築プロトコルやメカニズムにも挑戦をもたらします：DAS は理論的には分散型再構築に友好的ですが、これは実際にはパッケージインクルージョンリスト提案とその周囲のフォーク選択メカニズムと組み合わせる必要があります。

! Vitalik新記事:イーサリアムの可能な未来、急上昇

データ圧縮

私たちは何の問題を解決していますか？

Rollup の各取引は大量のオンチェーンデータスペースを占有します：ERC20 の転送には約 180 バイトが必要です。理想的なデータ可用性サンプリングがあっても、これにより Layer プロトコルのスケーラビリティが制限されます。各スロットは 16 MB で、私たちは次のようになります：

16000000 / 12 / 180 = 7407 TPS

もし私たちが分子の問題だけでなく、分母の問題も解決でき、各Rollupのトランザクションがチェーン上でより少ないバイトを占有できるなら、どうなるでしょうか？

それは何ですか、どのように機能しますか？

私の考えでは、最良の説明は2年前のこの図です：

! Vitalik新記事:イーサリアムの可能な未来、急増

ゼロバイト圧縮では、各長いゼロバイトシーケンスを2バイトで置き換え、ゼロバイトがいくつあるかを表します。さらに、私たちは取引の特定の属性を利用しました：

署名の集約：私たちはECDSA署名からBLS署名に切り替えました。BLS署名の特性は、複数の署名が一つの署名に組み合わさることができ、その署名はすべての元の署名の有効性を証明できることです。L1レイヤーでは、集約を行っても検証の計算コストが高いため、BLS署名の使用は考慮されていません。しかし、L2のようにデータが不足している環境では、BLS署名を使用することは意味があります。ERC-4337の集約機能は、この機能を実現するための道を提供します。