イーサリアムの可能性のある未来：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） あなたのノードは強力になる一方で、あなたのチェーンは去中心化しなくなるということです。この記事の目的は三角パラドックスを打破することが不可能であることを証明することではなく、むしろ三元パラドックスを打破することが困難であり、そのためにはこの議論が暗示する思考の枠組みをある程度超える必要があることを示すことです。

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

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

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

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

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

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

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

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

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

それは何ですか？どのように動作しますか？

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

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

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

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

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

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

重要なのは、コミットメントの拡張を計算するために 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 News:イーサリアムの可能な未来、急増

データ圧縮

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

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

16000000 / 12 / 180 = 7407 TPS

もし私たちが分子の問題だけでなく、分母の問題も解決でき、各ロールアップの取引がチェーン上でより少ないバイトを占めることができたら、どうなるでしょうか？

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

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

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

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

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

アドレスをポインタに置き換える：以前に使用したアドレスがある場合、20バイトのアドレスを履歴のある位置を指す4バイトのポインタに置き換えることができます。

取引値のカスタムシリアライズ------ほとんどの取引値の桁数は非常に少ない。例えば、0.25 ETHは250,000,000,000,000,000 weiとして表される。最大ベースハンド