This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
イーサリアム拡張の新たな章：The Surge ロードマップデプス解析
イーサリアムの可能性のある未来：The Surge
イーサリアムのロードマップは、最初に2つのスケーリング戦略を含んでいました: シャーディングとLayer2プロトコル。この2つの方法は最終的に統合され、Rollupを中心にしたロードマップが形成され、これは今でもイーサリアムの現在の拡張戦略です。
Rollupを中心にしたロードマップは、シンプルな役割分担を提案しています: イーサリアムL1は強力で分散化された基盤層になることに焦点を当て、L2はエコシステムの拡張を助ける役割を担います。このモデルは社会でよく見られるものです: 裁判所システム(L1)の存在は契約や財産権を保護するためのものであり、起業家(L2)はその基盤の上に構築し、人類の発展を促進します。
今年、Rollupを中心としたロードマップは重要な進展を遂げました: EIP-4844 blobsの導入により、イーサリアムL1のデータ帯域幅が大幅に増加し、複数のイーサリアム仮想マシン(EVM) Rollupが第一段階に入りました。各L2は独自の内部ルールとロジックを持つ「シャーディング」として存在し、シャーディング実装方式の多様性と多元化は今や現実となっています。しかし、この道は独自の課題にも直面しています。したがって、現在の私たちの任務は、Rollupを中心としたロードマップを完成させ、これらの問題を解決しつつ、イーサリアムL1特有の堅牢性と分散化を維持することです。
! ヴィタリックニュース:イーサリアムの可能な未来、急上昇
ザ・サージ: 重要な目標
未来イーサリアムはL2を通じて10万以上のTPSに達することができます;
L1の分散化とロバスト性を維持する;
少なくともいくつかのL2はイーサリアムのコア属性(を完全に継承しており、信頼性があり、オープンで、検閲に抵抗します);
イーサリアムは34の異なるブロックチェーンではなく、統一されたエコシステムのように感じるべきです。
チャプター内容
スケーラビリティの三角悖論
スケーラビリティ三角の逆説は、ブロックチェーンの3つの特性の間に矛盾が存在することを示しています: 非中央集権(、運営ノードのコストが低い)、スケーラビリティ(、処理できる取引の数が多い)、そしてセキュリティ(。攻撃者は、単一の取引を失敗させるために、ネットワーク内の非常に大きな部分のノードを破壊する必要があります)。
! Vitalik新記事:イーサリアムの可能な未来、急上昇
注目すべきは、三角パラドックスは定理ではなく、数学的証明もないということです。それは、分散型の友好的なノードが毎秒N件のトランザクションを検証でき、あなたが毎秒k*N件のトランザクションを処理するチェーンを持っている場合、(i)各トランザクションは1/kのノードにしか見えないという直感的な数学的議論を示しています。これは、攻撃者が悪意のあるトランザクションを通過させるために少数のノードを破壊するだけで済むことを意味し、また(ii)あなたのノードは強力になり、あなたのチェーンは非中央集権的でなくなることを意味します。この論文の目的は、三角パラドックスを破ることが不可能であることを証明することではありません。むしろ、三元パラドックスを破ることが困難であり、この議論が暗示する思考の枠組みからある程度は抜け出す必要があることを示すことを目的としています。
長年にわたり、一部の高性能チェーンは、根本的なアーキテクチャを変更することなく三元悖論を解決したと主張していますが、通常はソフトウェア工学の技術を用いてノードを最適化しています。これは常に誤解を招くものであり、これらのチェーン上でノードを運営することは、イーサリアム上でノードを運営するよりもはるかに困難です。本記事では、その理由と、L1クライアントソフトウェア工学自体だけではイーサリアムをスケールアップできない理由を探ります。
しかし、データ可用性サンプリングとSNARKsの組み合わせは、確かに三角の逆説を解決しました：クライアントが少量のデータをダウンロードし、極めて少ない計算を実行するだけで、一定の量のデータが利用可能であること、そして一定の計算ステップが正しく実行されていることを検証することができます。SNARKsは信頼不要です。データ可用性サンプリングには微妙なfew-of-N信頼モデルがありますが、それは51％攻撃でさえも悪質なブロックがネットワークに受け入れられることを強制できないという、非拡張チェーンが持つ基本的な特性を保持しています。
三つの難題を解決する別の方法は、Plasmaアーキテクチャであり、巧妙な技術を使用して、監視データの可用性の責任をユーザーに推し進める互換性のある方法で動機づけています。2017年から2019年の間、私たちが拡張計算能力の手段として詐欺証明しか持っていなかった時、Plasmaは安全な実行に関して非常に制限されていましたが、SNARKs(の普及に伴い、Plasmaアーキテクチャは以前よりも広範な使用シーンに対してより実行可能になりました。
データ可用性サンプリングのさらなる進展
) 私たちは何の問題を解決していますか？
2024年3月13日、Dencunアップグレードがオンラインになると、イーサリアムブロックチェーンの12秒ごとのスロットに3つの約125 kBのblobがあり、各スロットのデータ利用可能帯域幅は約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:イーサリアムの可能な未来、急増])https://img-cdn.gateio.im/webp-social/moments-40311fde406a2b6c83ba590c35e23a7c.webp(
) それは何ですか？どのように動作しますか？
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は冗長に同じ情報をエンコードしています。
! [Vitalik新記事:イーサリアムの可能な未来、急上昇])https://img-cdn.gateio.im/webp-social/moments-5d1a322bd6b6dfef0dbb78017226633d.webp(
したがって、最終的にはさらに進んで2Dサンプリングを行いたいと思います。これは、blob内だけでなく、blob間でのランダムサンプリングも行います。KZGコミットメントの線形特性は、同じ情報に対して冗長エンコードされた新しい仮想blobリストを含む、1つのブロック内の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と同じ大きさです。
私が考える長期的な現実の道筋は:
注意してください。たとえ私たちがL1層で直接実行を拡張することを決定したとしても、この選択肢は存在します。なぜなら、L1層が大量のTPSを処理する必要がある場合、L1ブロックは非常に大きくなり、クライアントはそれらの正当性を検証する効率的な方法を望むからです。したがって、私たちはL1層でRollup)と同じ技術、例えばZK-EVMやDAS(を使用する必要があります。
) どのようにロードマップの他の部分と相互作用しますか?
データ圧縮を実現すれば、2D DASの需要は減少するか、少なくとも遅れるでしょう。また、Plasmaが広く使用される場合、需要はさらに減少します。DASは分散型ブロック構築プロトコルとメカニズムにも課題を提起します。理論的にはDASは分散型再構築に友好的ですが、実際にはパッケージインクルージョンリスト提案とその周囲のフォーク選択メカニズムと組み合わせる必要があります。
データ圧縮
私たちは何の問題を解決していますか?
Rollupの各取引は大量のオンチェーンデータスペースを占有します:ERC20の転送には約180バイトが必要です。理想的なデータ可用性サンプリングがあっても、これによりLayerプロトコルのスケーラビリティが制限されます。各スロットは16 MBで、私たちは得ます:
16000000 / 12 / 180 = 7407 TPS
もし私たちが分子の問題だけでなく、分母の問題も解決でき、各Rollup内の取引がチェーン上でより少ないバイトを占有することができるとしたら、どうなるでしょうか？
それは何ですか、どのように機能しますか？
私の見解では、最良の説明は2年前のこの図です:
! [Vitalik新記事:イーサリアムの可能な未来、急上昇]###https://img-cdn.gateio.im/webp-social/moments-71424e26868ad99f2adda7a27447820a.webp(
ゼロバイト圧縮中、各長いゼロバイトシーケンスを2バイトで置き換え、ゼロバイトの数を表します。さらに、特定の取引属性を利用しました:
署名の集約:私たちはECDSA署名からBLS署名に切り替えました。BLS署名の特性は、複数の署名を単一の署名にまとめることができ、その署名がすべての元の署名の有効性を証明できることです。L1層では、たとえ集約を行っても検証の計算コストが高いため、BLS署名の使用は考慮されていません。