原作者: ヴィタリック・ブテリン
オリジナル編集: Karen、Foresight News
Justin Drake、Francesco、Hsiao-wei Wang、@antonttc、Georgios Konstantopoulos に心より感謝いたします。
当初、イーサリアムのロードマップには 2 つのスケーリング戦略がありました。 1 つは (2015 年の以前の論文を参照) 「シャーディング」です。各ノードは、チェーン内のすべてのトランザクションを検証して保存するのではなく、トランザクションのごく一部を検証して保存するだけで済みます。他のピアツーピア ネットワーク (BitTorrent など) もこのように動作するため、もちろんブロックチェーンも同じように動作させることができます。もう 1 つはレイヤー 2 プロトコルです。これらのネットワークはイーサリアムの最上位に位置し、データと計算の大部分をメイン チェーンの外側に保ちながら、そのセキュリティの恩恵を最大限に受けられるようになります。レイヤ 2 プロトコルは、2015 年にはステート チャネル、2017 年にはプラズマ、そして 2019 年にはロールアップを指します。ロールアップはステート チャネルやプラズマよりも強力ですが、大量のオンチェーン データ帯域幅を必要とします。幸いなことに、シャーディングの研究により、2019 年までに「データの可用性」を大規模に検証するという問題が解決されました。その結果、2 つの道が収束し、現在もイーサリアムのスケーリング戦略となっているロールアップ中心のロードマップが得られました。
The Surge、2023 年ロードマップ版
ロールアップ中心のロードマップは、シンプルな分業を提案しています。イーサリアム L1 は強力で分散化されたベースレイヤーであることに重点を置き、L2 はエコシステムのスケールを支援する役割を果たします。このモデルは社会に遍在しています。裁判所制度 (L1) は、超高速性と効率性を追求するためではなく、契約と財産権を保護するために存在し、起業家 (L2) はこの強固な基盤層の上に構築され、人類を構築し導くために (文字通り、比喩的に）火星。
今年、ロールアップ中心のロードマップは重要な成果を達成しました。EIP-4844 BLOB の開始により、イーサリアム L1 のデータ帯域幅が大幅に増加し、複数のイーサリアム仮想マシン (EVM) ロールアップが第 1 フェーズに入りました。各 L2 は、独自の内部ルールとロジックを備えた「シャード」として存在し、シャーディングの実装方法の多様性と多様化が現実になりました。しかし、これまで見てきたように、この道を進むには特有の課題もいくつか伴います。したがって、私たちの現在の課題は、イーサリアム L1 の特徴である堅牢性と分散化を維持しながら、ロールアップ中心のロードマップを完成させ、これらの問題を解決することです。
サージ: 主要な目標
1. 将来的には、イーサリアムは L2 経由で 100,000 TPS 以上に達する可能性があります。
2. L1 の分散化と堅牢性を維持します。
3. 少なくとも一部の L2 はイーサリアムの中核的属性 (トラストレス、オープン、検閲耐性) を完全に継承します。
4. イーサリアムは、34 の異なるブロックチェーンではなく、統一されたエコシステムのように感じられるべきです。
この章の内容
スケーラビリティのトライアングル
データ可用性サンプリングのさらなる進歩
データ圧縮
一般化されたプラズマ
成熟した L2 プルーフ システム
L2 間の相互運用性の向上
L1 での実行の延長
スケーラビリティのトライアングル
スケーラビリティ トライアングルは 2017 年に提案されたアイデアで、ブロックチェーンの 3 つの特性、つまり分散化 (より具体的にはノードの実行コストの低さ)、スケーラビリティ (多数のトランザクションの処理)、およびセキュリティ (攻撃者は大規模なトランザクションを侵害する必要がある) 間の矛盾を考慮しています。ネットワーク内のノードの一部が原因で単一のトランザクションが失敗します)。
三角パラドックスは定理ではなく、三角パラドックスを紹介する投稿には数学的証明が付属していないことに注意してください。これはヒューリスティックな数学的議論を提供します。分散化に適したノード (消費者のラップトップなど) が 1 秒あたり N 個のトランザクションを検証でき、1 秒あたり k*N 個のトランザクションを処理するチェーンがある場合、(i) 各トランザクションは次のとおりです。これは、攻撃者が悪意のあるトランザクションを通過させるために数個のノードを侵害するだけで済むことを意味します。そうでない場合、(ii) ノードが強力になり、チェーンが分散化されなくなります。この記事の目的は、トライアングル パラドックスを打破することが不可能であることを証明することではなく、むしろ、トリレンマを打破することは困難であり、議論の枠組みの外である程度の思考が必要であることを示すことを目的としていました。
長年にわたり、一部の高性能チェーンは、アーキテクチャを根本的に変更することなく、多くの場合ソフトウェアエンジニアリング技術を適用してノードを最適化することで、トリレンマを解決したと主張してきました。これは常に誤解を招きますが、これらのチェーン上でノードを実行することは、イーサリアム上でノードを実行するよりもはるかに困難です。この記事では、なぜそうなるのか、そしてなぜ L1 クライアント ソフトウェア エンジニアリングだけではイーサリアムを拡張できないのかを探ります。
ただし、データ可用性サンプリングと SNARK を組み合わせることで、三角パラドックスは解決されます。これにより、クライアントは、少量のデータをダウンロードして実行するだけで、一定量のデータが利用可能であり、一定数の計算ステップが利用可能であることを検証できます。非常に少量の計算が正しく実行されました。 SNARK はトラストレスです。データ可用性サンプリングには、N 個の微妙な信頼モデルがありますが、スケーラブルでないチェーンの基本特性は保持されています。つまり、51% 攻撃であっても不良ブロックをネットワークに強制的に受け入れることはできません。
トリレンマに対するもう 1 つの解決策は、Plasma アーキテクチャです。これは、賢明な技術を使用して、インセンティブと互換性のある方法でデータの可用性を監視する責任をユーザーに押し付けます。 2017 年から 2019 年の時点では、コンピューティング能力を拡張する手段として不正行為の証明しかなかったとき、Plasma はセキュリティの実行という点で非常に限られていましたが、SNARK (ゼロ知識の簡潔な非対話型引数) の人気により、Plasmaアーキテクチャがより広範囲になり、より幅広いユースケースが実現可能になりました。
データ可用性サンプリングのさらなる進歩
私たちはどんな問題を解決しているのでしょうか？
2024 年 3 月 13 日に Dencun のアップグレードがオンラインになったとき、イーサリアム ブロックチェーンには 12 秒スロットあたり約 125 KB、つまりスロットあたり約 375 KB のデータ利用可能な帯域幅の 3 つのブロブがありました。トランザクション データがチェーン上で直接公開されると仮定すると、ERC 20 転送は約 180 バイトであるため、イーサリアム上のロールアップの最大 TPS は次のようになります: 375000 / 12 / 180 = 173.6 TPS
Ethereum のコールデータ (理論上の最大値: スロットあたり 3,000 万ガス / バイトあたり 16 ガス = スロットあたり 1,875,000 バイト) を追加すると、607 TPS になります。 PeerDAS を使用すると、BLOB の数を 8 ～ 16 に増やすことができ、これにより通話データに 463 ～ 926 TPS が提供されます。
これはイーサリアム L1 に比べて大幅な改善ですが、それだけでは十分ではありません。さらなる拡張性が必要です。私たちの中期目標はスロットあたり 16 MB で、ロールアップ データ圧縮の改善と組み合わせると、最大 58,000 TPS になります。
それは何ですか？どのように機能するのでしょうか?
PeerDAS は、「1D サンプリング」の比較的単純な実装です。イーサリアムでは、各ブロブは 253 ビットの素体上の 4096 次の多項式です。多項式シェアをブロードキャストします。各シェアには、合計 8192 個の座標のうち 16 個の隣接する座標で 16 個の評価が含まれます。これら 8192 の評価のうち、任意の 4096 (現在提案されているパラメーターによると、128 の可能なサンプルのうちの任意の 64) でブロブを回復できます。
PeerDAS は、各クライアントに少数のサブネットをリッスンさせることで機能し、i 番目のサブネットが任意の BLOB の i 番目のサンプルをブロードキャストし、異なるサブネットでリッスンするグローバル P2P ネットワーク内のピアに BLOB を要求するように依頼します。必要な他のサブネット。 SubnetDAS のより保守的なバージョンでは、ピア層の追加の問い合わせを行わずに、サブネット メカニズムのみを使用します。現在の提案は、Proof of Stake に参加するノードに SubnetDAS を使用させ、他のノード (つまりクライアント) には PeerDAS を使用させるというものです。
理論的には、「1D サンプリング」をかなり拡張できます。BLOB の最大数を 256 (ターゲット 128) に増やせば、ノードあたり 16 サンプル * 128 BLOB * 512 をサンプリングすることで、データ可用性なしで 16 MB の目標を達成できます。 BLOB あたりのサンプルあたりのバイト数 = スロットあたり 1 MB のデータ帯域幅。これは、かろうじて許容範囲内です。実行可能ですが、帯域幅に制約のあるクライアントはサンプリングできないことを意味します。 BLOB の数を減らし、BLOB サイズを増やすことでこれをある程度最適化できますが、再構築のコストが高くなります。
したがって、最終的にはさらに一歩進んで、ブロブ内だけでなくブロブ間でもランダムにサンプリングする 2D サンプリングを実行したいと考えています。 KZG コミットメントの線形特性を利用して、ブロック内の BLOB のセットは、同じ情報を冗長的にエンコードする仮想 BLOB の新しいセットによって拡張されます。
したがって、最終的にはさらに一歩進めて、ブロブ内だけでなくブロブ間でもランダムにサンプリングする 2D サンプリングを実行したいと考えています。 KZG コミットメントの線形特性は、同じ情報を冗長的にエンコードする新しい仮想 BLOB のリストを含むブロック内の BLOB のセットを拡張するために使用されます。
2Dサンプリング。出典: a16z 暗号
重要なのは、コミットメントのスケーリングの計算には BLOB が必要ないため、このスキームは基本的に分散ブロックの構築に適しています。実際にブロックを構築するノードには、BLOB KZG コミットメントのみが必要であり、データ可用性サンプリング (DAS) を利用してデータ ブロックの可用性を検証できます。 1 次元データ可用性サンプリング (1D DAS) も本質的に分散ブロック構築に適しています。
既存の研究とのつながりは何ですか?
データの可用性に関する元の投稿 (2018): https://github.com/ethereum/research/wiki/A-note-on-data-availability-and-erasure-coding
フォローアップ論文: https://arxiv.org/abs/1809.09044
DAS、パラダイムに関する解説記事: https://www.paradigm.xyz/2022/08/das
KZG コミットメントによる 2D の可用性: https://ethresear.ch/t/2d-data-availability-with-kate-commitments/8081
ethresear.ch の PeerDAS: https://ethresear.ch/t/peerdas-a-simpler-das-approach-using-battle-tested-p2p-components/16541 および論文: https://eprint.iacr.org / 2024/1362
EIP-7594: https://eips.ethereum.org/EIPS/eip-7594
ethresear.ch の SubnetDAS: https://ethresear.ch/t/subnetdas-an-intermediate-das-approach/17169
2D サンプリングにおけるデータ回復のニュアンス: https://ethresear.ch/t/nuances-of-data-recoverability-in-data-availability-sampling/16256
他に何をする必要がありますか?トレードオフは何ですか?
次のステップは、PeerDAS の実装とロールアウトを完了することです。その後、ネットワークを注意深く観察し、セキュリティを確保するためにソフトウェアを改善しながら、PeerDAS 上の BLOB の数を徐々に増やしていきました。その一方で、私たちは、PeerDAS や DAS の他のバージョンの標準化、およびフォーク選択ルールのセキュリティなどの問題との相互作用を標準化する学術研究がさらに増えることを期待しています。
将来のさらなる段階では、2D DAS の理想的なバージョンを特定し、そのセキュリティ特性を証明するためにさらなる作業を行う必要があります。また、最終的には KZG から、量子的に安全で信頼できるセットアップを必要としない代替手段に移行したいと考えています。現時点では、どの候補者が分散ブロック構築に適しているかはわかりません。高価な「総当り」手法を使用したり、再帰的な STARK を使用して行と列を再構成するための妥当性証明を生成したりしても十分ではありません。技術的には STARK は O(log(n ) * log(log(n)) のハッシュ値であるためです ( STIR)、しかし実際には、STARK はブロブ全体とほぼ同じ大きさです。
私の長期的な現実的な道筋は次のとおりです。
理想的な 2D DAS を実装します。
1D DAS を使用し、サンプリング帯域幅の効率を犠牲にし、シンプルさと堅牢性のために低いデータ上限を受け入れます
(ハードピボット) DA を放棄し、私たちが重点を置く主要なレイヤー 2 アーキテクチャとして Plasma を完全に受け入れます。
このオプションは、L1 レイヤーで直接実行をスケールすることにした場合でも存在することに注意してください。これは、L1 層が多数の TPS を処理する場合、L1 ブロックが非常に大きくなり、クライアントがその正確性を検証する効率的な方法を必要とするため、ロールアップ (ZK など) を使用する必要があるためです。 L1 層 (EVM および DAS) と同じテクノロジー。
ロードマップの他の部分と対話するにはどうすればよいですか?
データ圧縮が実装されれば、2D DAS の必要性は減少するか、少なくとも遅れることになります。また、プラズマが広く使用されれば、その必要性はさらに減少します。 DAS は、分散ブロック構築のプロトコルとメカニズムにも課題をもたらします。DAS は理論的には分散再構築に適していますが、実際には、これを包含リストの提案とそれに基づくフォーク選択メカニズムと組み合わせる必要があります。
データ圧縮
私たちはどんな問題を解決しているのでしょうか？
Rollup の各トランザクションは、多くのオンチェーン データ スペースを占有します。ERC 20 転送には約 180 バイトが必要です。理想的なデータ可用性サンプリングを行ったとしても、これによりレイヤー プロトコルのスケーラビリティが制限されます。スロットあたり 16 MB の場合、次の結果が得られます。
16000000 / 12 / 180 = 7407 TPS
ロールアップ内の各トランザクションがチェーン上で占めるバイト数を少なくするために、分子の問題だけでなく分母の問題も解決できたらどうなるでしょうか?
それは何ですか?またどのように機能しますか?
私の考えでは、最も分かりやすい説明は 2 年前のこの写真です。
ゼロバイト圧縮では、ゼロバイトの長いシーケンスが 2 バイトに置き換えられ、ゼロバイトが何個あるかが示されます。さらに一歩進んで、トランザクション固有のプロパティを活用します。
署名の集約: ECDSA 署名から BLS 署名に切り替えます。BLS 署名の特徴は、複数の署名を 1 つの署名に結合して、すべての元の署名の正当性を証明できることです。 L1 層では、集約を使用した場合でも検証の計算コストが高いため、BLS 署名は考慮されません。ただし、L2 のようなデータが不足している環境では、BLS 署名を使用するのが合理的です。 ERC-4337 の集約の性質により、この機能を実現する方法が提供されます。
アドレスをポインタに置き換える: アドレスが以前に使用されていた場合、20 バイトのアドレスを履歴内の場所を指す 4 バイトのポインタに置き換えることができます。
トランザクション値のカスタムシリアル化 - ほとんどのトランザクション値の桁数は非常に少なく、たとえば、0.25 ETH は 250, 000, 000, 000, 000, 000 wei として表されます。基本手数料および優先手数料の上限も同様です。したがって、カスタムの 10 進浮動小数点形式を使用して、ほとんどの金額を表すことができます。
既存の研究とのつながりは何ですか?
sequence.xyz を探索します: https://sequence.xyz/blog/compressing-calldata
L2 Calldata 最適化契約: https://github.com/ScopeLift/l2-optimizooooors
有効性証明に基づくロールアップ (別名 ZK ロールアップ) は、トランザクションの代わりに状態の差異を公開します: https://ethresear.ch/t/rollup-diff-compression-application-level-compression-strategies-to-reduce-the-l2 -data -l1/9975 上のフットプリント
BLS ウォレット - ERC-4337 による BLS 集約: https://github.com/getwax/bls-wallet
他に何をする必要がありますか?また、トレードオフは何ですか?
次に行うべき主なことは、上記のソリューションを実際に実装することです。主なトレードオフは次のとおりです。
1. BLS 署名への切り替えには多大な労力が必要であり、セキュリティを強化できる信頼できるハードウェア チップとの互換性が低下します。代わりに、他の署名スキームの ZK-SNARK ラッパーを使用できます。
2. 動的圧縮 (アドレスをポインターで置き換えるなど) により、クライアント コードが複雑になります。
3. ステータスの違いをトランザクションではなくチェーンに公開すると、監査可能性が低下し、多くのソフトウェア (ブロック エクスプローラーなど) が動作できなくなります。
ロードマップの他の部分と対話するにはどうすればよいですか?
ERC-4337 を採用し、最終的にはその一部を L2 EVM に組み込むことで、統合テクノロジーの導入を大幅にスピードアップできます。 ERC-4337 の一部を L1 に配置すると、L2 での展開を高速化できます。
一般化されたプラズマ
私たちはどんな問題を解決しているのでしょうか？
16 MB の BLOB とデータ圧縮を使用しても、58,000 TPS では、消費者の支払い、分散型ソーシャル、またはその他の高帯域幅領域のニーズを完全に満たすには十分ではない可能性があり、特にプライバシーへの配慮を考慮し始めると、スケーラビリティが低下する可能性があります。 3〜8倍。トランザクション量が多く、価値の低いアプリケーションのシナリオの場合、現在のオプションの 1 つは、データをオフチェーンに保持し、興味深いセキュリティ モデルを採用する Validium を使用することです。オペレーターはユーザーの資金を盗むことはできませんが、すべてのユーザーの資金を一時的または永久に凍結する可能性があります。しかし、もっと良くできるはずです。
それは何ですか?またどのように機能しますか?
Plasma は、オペレーターがオフチェーンでブロックを公開し、それらのブロックのマークル ルートをオンチェーンに置くスケーリング ソリューションです (完全なブロックをオンチェーンに置くロールアップとは異なります)。ブロックごとに、オペレーターは各ユーザーにマークル ブランチを送信し、ユーザーの資産が変更されたか、何も変更されていないことを証明します。ユーザーは Merkle フォークを提供することで資産を引き出すことができます。重要なのは、このブランチは最新の状態でルート化されている必要はないということです。したがって、データの可用性に問題がある場合でも、ユーザーは利用可能な最新のステータスを取得することで資産を回復できます。ユーザーが無効なブランチをコミットした場合（たとえば、すでに他の人に送信したアセットを引き出したり、オペレーター自身が何もないところからアセットを作成したりする場合）、アセットの法的所有権はオンチェーンチャレンジを通じて決定できます。機構。
プラズマキャッシュのチェーン図。コイン i のコストがかかるトランザクションは、ツリーの i 番目の位置に配置されます。この例では、以前のツリーがすべて有効であると仮定すると、現在イブがトークン 1 を所有し、デイビッドがトークン 4 を所有し、ジョージがトークン 6 を所有していることがわかります。
初期のプラズマ バージョンは支払いのユースケースのみを処理でき、それ以上効果的に推進することはできませんでした。ただし、各ルートを SNARK で検証する必要がある場合、Plasma はさらに強力になります。オペレーターが不正行為をする可能性のある経路をほとんど排除しているため、各チャレンジ ゲームは大幅に簡素化できます。同時に、Plasma テクノロジーをより広範囲の資産クラスに拡張できるようにするための新しい道も開かれます。最後に、オペレーターが不正行為をしていなければ、ユーザーは 1 週間のチャレンジ期間を待つことなく、すぐに資金を引き出すことができます。
EVM プラズマ チェーンを作成する 1 つの方法 (唯一の方法ではありません): ZK-SNARK を使用して、EVM によって行われたバランス変更を反映し、履歴の異なる時点で「同じトークン」を定義する並列 UTXO ツリーを構築します。 。その後、その上にプラズマ構造を構築できます。
重要な洞察は、プラズマ システムは完璧である必要はないということです。たとえ資産のサブセット（例：過去 1 週間に移動していないトークン）しか保護できなかったとしても、ハイパースケーラブルな EVM（Validium など）の現在の最先端技術を大幅に改善したことになります。
別のタイプの構造は、Intmax などのハイブリッド Plasma/Rollup です。これらの構造は、ユーザーごとに非常に少量のデータをオンチェーンに置きます (例: 5 バイト)。これにより、Plasma と Rollup の間のいくつかのプロパティが得られます。Intmax の場合、非常に高いスケーラビリティとプライバシーが得られます。 16 MB の容量では、理論的には約 16,000,000 / 12 / 5 = 266,667 TPS に制限されます。
既存の研究とのつながりは何ですか?
オリジナルのプラズマ論文: https://plasma.io/plasma-deprecated.pdf
プラズマキャッシュ: https://ethresear.ch/t/plasma-cash-plasma-with-much-less-per-user-data-checking/1298
プラズマ キャッシュフロー: https://hackmd.io/DgzmJIRjSzCYvl4lUjZXNQ?view#🚪-Exit
Intmax (2023): https://eprint.iacr.org/2023/1082
他に何をする必要がありますか?トレードオフは何ですか?
残りの主な課題は、プラズマ システムを実際の生産アプリケーションに導入することです。上で述べたように、Plasma と Validium は二者択一ではありません。どの Validium も、Plasma 機能を終了メカニズムに組み込むことで、セキュリティ特性を少なくともある程度向上させることができます。研究の焦点は、EVM 特性の最適化を実現することです。 (信頼要件、最悪の場合の L1 ガスのコスト、および DoS 攻撃に耐える能力の観点から考慮されます)、さらに、プラズマは概念的に、ロールアップよりも複雑です。より良い一般的なフレームワークを研究し、構築すること。
Plasma 設計を使用する場合の主なトレードオフは、ハイブリッド Plasma/Rollup 設計では多くの場合、この弱点を回避できますが、Plasma 設計はオペレータへの依存性が高く、ベースにするのが難しいことです。
ロードマップの他の部分と対話するにはどうすればよいですか?
Plasma ソリューションが効率的であればあるほど、L1 に高性能のデータ可用性機能を持たせるというプレッシャーが少なくなります。アクティビティを L2 に移動すると、L1 に対する MEV のプレッシャーも軽減されます。
成熟した L2 プルーフ システム
私たちはどんな問題を解決しているのでしょうか？
現在、ほとんどのロールアップは実際にはトラストレスではありません。システムの動作をオーバーライド (楽観的または検証) できる安全委員会があります。場合によっては、認証システムがまったく動作しなかったり、動作したとしても「助言」機能しかない場合もあります。最先端のロールアップには、(i) Fuel などの一部のトラストレス アプリケーション固有のロールアップ、(ii) この記事の執筆時点では、Optimism と Arbitrum の 2 つが「フェーズ 1」として知られる部分的なトラストレス マイルストーンを達成しています。完全な EVM ロールアップ。 Rollup がそれ以上の進歩を遂げられなかった理由は、コードのバグに対する懸念によるものでした。トラストレスロールアップが必要なので、この問題に正面から向き合って解決する必要があります。
それは何ですか?またどのように機能しますか?
まずは、この記事で紹介した「ステージ」システムについておさらいしてみましょう。
フェーズ 0: ユーザーはノードを実行し、チェーンを同期できる必要があります。検証が完全に信頼されているか一元化されている場合は、問題ありません。
フェーズ 1: 有効なトランザクションのみが受け入れられることを保証する (トラストレスな) 証明システムが必要です。安全委員会は認証システムを無効にすることができますが、75% の基準投票が必要です。さらに、委員会の定足数をブロックしている部分 (つまり 26% 以上) は、ロールアップを作成している主要な会社の外部にある必要があります。より弱いアップグレード メカニズム (DAO など) は許可されますが、悪意のあるアップグレードが承認された場合に、資金がオンラインになる前にユーザーが資金を引き出すことができる十分な長い遅延が必要です。
フェーズ 2: 有効なトランザクションのみが受け入れられることを保証する (トラストレスな) 証明システムが必要です。安全委員会は、たとえばコードに明らかなバグがある場合にのみ介入を許可されます。 2 つの冗長な証明システムが互いに矛盾している場合、または 1 つの証明システムが同じブロックに対して 2 つの異なる事後状態ルートを受け入れる (または、1 週間などの十分な期間にわたって何も受け入れない) 場合。アップグレード メカニズムは許可されますが、長い遅延が発生する必要があります。
私たちの目標はフェーズ 2 に到達することです。ステージ 2 に到達する際の主な課題は、システムが実際に十分に信頼できることを証明するのに十分な信頼を得ることです。これを行うには主に 2 つの方法があります。
正式な検証: 最新の数学とコンピューティング技術を使用して、システムが EVM 仕様に合格したブロックのみを受け入れることを (楽観的かつ有効に) 証明できます。これらのテクノロジーは何十年も前から存在していますが、最近の進歩 (リーン 4 など) によりより実用的なものになり、AI 支援証明の進歩によりこの傾向がさらに加速する可能性があります。
マルチ証明者: 複数の証明システムを作成し、セキュリティ委員会 (または TEE などの信頼を前提とした他のガジェット) を備えたこれらの証明システムに資金を投資します。証明システムが同意する場合、安全委員会には権限はありませんが、同意しない場合、安全委員会はどちらかを選択することしかできず、一方的に独自の答えを押し付けることはできません。
楽観的証明システム、妥当性証明システム、安全委員会を組み合わせた複数の証明者の様式化されたグラフ。
既存の研究とのつながりは何ですか?
EVM K セマンティクス (2017 年からの正式な検証作業): https://github.com/runtimeverification/evm-semantics
多重証明の考え方に関する講義（2022年）：https://www.youtube.com/watch?v=6hfVzCWT6YI
Taiko はマルチプルーフの使用を計画しています: https://docs.taiko.xyz/core-concepts/multi-proofs/
他に何をする必要がありますか?トレードオフは何ですか?
正式な検証の場合、作業負荷は膨大です。 EVM の SNARK 証明者全体の正式に検証されたバージョンを作成する必要があります。これは非常に複雑なプロジェクトですが、私たちはすでに取り組み始めています。このタスクを大幅に簡素化するトリックがあります。最小限の仮想マシン (RISC-V や Cairo など) に対して正式に検証された SNARK 証明器を作成し、この最小限の仮想マシンに EVM を実装します (そして、その等価性の正式な証明を行うことができます)。他のイーサリアム仮想マシン仕様に準拠します)。
マルチプルーフには、まだ完了していない 2 つの主要な部分があります。まず、少なくとも 2 つの異なる証明システムに十分な信頼を置く必要があります。これは、それぞれが合理的に安全であることを確認することと、問題がある場合には、その問題は異なるもので無関係であることを確認するためです (したがって、それらが同時に発生することはありません)。問題が発生します）。第 2 に、マージプルーフ システムの基礎となるロジックに対して非常に高い信頼性を持つ必要があります。コードのこの部分ははるかに少ないです。各証明システムを署名者として表す契約を含む安全なマルチシグ契約に資金を保管するだけで、資金を非常に小さくする方法がありますが、これによりチェーン上のガスコストが増加します。効率とセキュリティの間のバランスを見つける必要があります。
ロードマップの他の部分と対話するにはどうすればよいですか?
アクティビティを L2 に移動すると、L1 に対する MEV のプレッシャーが軽減されます。
L2 間の相互運用性の向上
私たちはどんな問題を解決しているのでしょうか？
今日の L2 エコシステムが直面している大きな課題は、ユーザーがそのエコシステム内を移動することが難しいことです。さらに、最も簡単なアプローチでは、集中型クロスチェーン、RPC クライアントなど、信頼の前提が再導入されることがよくあります。 L2 エコシステムを、統合されたイーサリアム エコシステムを使用しているように感じられるようにする必要があります。
どういう仕組みですか?
L2 間の相互運用性の向上には多くのカテゴリがあります。理論的には、ロールアップ中心のイーサリアムはシャード L1 を実行することと同じです。現在のイーサリアム L2 エコシステムには、実際の理想的な状態からは次のような欠点がまだあります。
1. 特定のチェーンのアドレス: アドレスにはチェーン情報 (L1、Optimism、Arbitrum...) が含まれている必要があります。これが完了すると、「送信」フィールドにアドレスを入力するだけでクロス L2 送信プロセスを実装でき、その時点でウォレットがバックグラウンドで独自に送信方法を処理できるようになります (クロスチェーン プロトコルの使用を含む)。 。
2. チェーン固有の支払いリクエスト: 「チェーン Z 上のタイプ Y のトークンを X 個送ってください」という形式のメッセージを作成するのは簡単かつ標準化されるべきです。これには主に 2 つのアプリケーション シナリオがあります。(i) 人々間の支払いか、または人々と販売者サービスの間の支払いか。(ii) DApp が資金を要求する。
3. クロスチェーン交換とガス支払い: 「Arbitrum (Optimism) で 0.9999 Ethereum を送ってくれた人に 1 Ethereum を送ります」、「 Arbitrum でこの取引を含めた人に 0.0001 イーサ (Optimism で) を送ります。」 ERC-7683 は前者に対する試みであり、RIP-7755 は後者に対する試みですが、どちらもこれらの特定の使用例よりも幅広い用途があります。
4. ライト クライアント: ユーザーは、単に RPC プロバイダーを信頼するのではなく、対話しているチェーンを実際に検証できる必要があります。 a16z 暗号の Helios はこれを (イーサリアム自体に対して) 行うことができますが、このトラストレス性を L2 に拡張する必要があります。 ERC-3668 (CCIP-read) は、この目標を達成するための 1 つの戦略です。
ライトクライアントがイーサリアムヘッダーチェーンのビューを更新する方法。ヘッダー チェーンを取得したら、マークル証明を使用して状態オブジェクトを検証できます。正しい L1 状態オブジェクトを取得したら、マークル証明 (および事前確認を確認したい場合は署名) を使用して、L2 上の状態オブジェクトを検証できます。 Helios は前者を実現しました。後者への拡張は標準化の課題です。
1. キーストア ウォレット: 現在、スマート コントラクト ウォレットを制御するキーを更新したい場合は、ウォレットが存在するすべての N チェーンでキーを更新する必要があります。キーストア ウォレットは、キーを 1 か所 (L1 上か、場合によっては L2 以降) にのみ存在させるテクノロジーで、ウォレットのコピーを持つ L2 はそこからキーを読み取ることができます。つまり、更新は 1 回だけ行う必要があります。効率を向上させるために、キーストア ウォレットでは、L2 が L1 の情報を無料で読み取るための標準化された方法を必要とします。これには、L1S LOAD と REMOTESTATICCALL という 2 つの提案があります。
キーストアウォレットの仕組み
2. より急進的な「共有トークン ブリッジ」の概念: すべての L2 が有効性証明ロールアップであり、すべてのスロットがイーサリアムに送信される世界を想像してください。このような世界でも、ネイティブ状態である L2 から別の L2 に資産を移すには依然として引き出しと入金が必要であり、多額の L1 ガス料金を支払う必要があります。この問題を解決する 1 つの方法は、共有ミニマリスト ロールアップを作成することです。このロールアップの唯一の機能は、どの L2 が各タイプのトークンを所有しているか、およびそれぞれの残高を維持し、これらの残高が L2 送信操作によって開始される一連のトランザクションを通過できるようにすることです。バッチ更新のために L2 全体で。これにより、転送ごとに L1 ガス料金を支払う必要がなく、ERC-7683 などの流動性プロバイダーベースのテクノロジーを使用することなく、クロス L2 転送が可能になります。
3. 同期構成性: 特定の L2 と L1 間、または複数の L2 間で同期コールを発生できるようにします。これは、DeFi プロトコルの財務効率の向上に役立ちます。前者は L2 間の調整なしで実装できますが、後者は共有順序付けが必要です。ロールアップ ベースのテクノロジは、これらすべてのテクノロジと自動的に連携します。
既存の研究とのつながりは何ですか?
チェーン固有のアドレス:
ERC-3770: https://eips.ethereum.org/EIPS/eip-3770
ERC-7683: https://eips.ethereum.org/EIPS/eip-7683
RIP-7755: https://github.com/wilsoncusack/RIPs/blob/cross-l2-call-standard/RIPS/rip-7755.md
スクロールキーストアウォレットの設計: https://hackmd.io/@haichen/keystore
ヘリオス: https://github.com/a16z/helios
ERC-3668 (CCIP 読み取りとも呼ばれます): https://eips.ethereum.org/EIPS/eip-3668
Justin Drake によって提案された「ベース (共有) 事前確認」提案: https://ethresear.ch/t/based-preconfirmations/17353
L1S ロード (RIP-7728): https://ethereum-magicians.org/t/rip-7728-l1sload-precompile/20388
Optimism の REMOTESTATICCALL: https://github.com/ethereum-optimism/ecosystem-contributions/issues/76
共有トークンブリッジのアイデアを含む AggLayer: https://github.com/AggLayer
他に何をする必要がありますか?トレードオフは何ですか?
上記の例の多くは、いつ標準化するか、どのレイヤーを標準化するかという標準のジレンマに直面しています。標準化が早すぎると、不十分なソリューションが定着する危険があります。標準化が遅すぎると、不必要な断片化が生じる可能性があります。場合によっては、特性は弱いものの実装が容易な短期的な解決策と、「最終的には正しい」が実装に何年もかかる長期的な解決策が存在することがあります。
これらのタスクは単なる技術的な問題ではなく、L1 だけでなく L2 とウォレットの間の協力を必要とする (おそらく主に) 社会的な問題でもあります。
ロードマップの他の部分と対話するにはどうすればよいですか?
これらの提案のほとんどは「上位レベル」の構造であるため、L1 レベルの考慮事項にはほとんど影響しません。例外の 1 つは共有順序であり、これは最大抽出可能値 (MEV) に大きな影響を与えます。
L1 での実行の延長
私たちはどんな問題を解決しているのでしょうか？
L2 が非常にスケーラブルで成功しても、L1 が依然として非常に少量のトランザクション量しか処理できない場合、イーサリアムに多くのリスクが発生する可能性があります。
1. ETH資産の経済的状況はさらに不安定になり、ネットワークの長期的なセキュリティに影響を及ぼします。
2. 多くの L2 は、L1 上の高度に発達した金融エコシステムとの密接な関係から恩恵を受けています。このエコシステムが大幅に弱体化すると、(独立した L1 になるのではなく) L2 になるインセンティブが弱まります。
3. L2 が L1 と同じセキュリティ保証を達成するには、長い時間がかかります。
4. L2 に障害が発生した場合（たとえば、オペレーターの悪意のある行動や失踪により）、ユーザーは引き続き L1 を通じて資産を回復する必要があります。したがって、L1 は、L2 の非常に複雑で厄介な仕上げ作業を少なくとも時々実際に処理できるほど強力である必要があります。
これらの理由から、L1 自体を拡張し続け、より多くのユースケースに対応できるようにすることは非常に価値があります。
それは何ですか？どのように機能するのでしょうか?
スケールする最も簡単な方法は、ガス制限を直接増やすことです。ただし、これにより L1 が集中化され、イーサリアム L1 を非常に強力にするもう 1 つの重要な機能、つまり堅牢なベースレイヤーとしての信頼性が損なわれる可能性があります。単純にガス制限を増やすことがどこまで持続可能であるかについてはまだ議論があり、これは、より大きなブロックの検証を容易にするために他のどのような技術が実装されているかにも依存します (履歴の有効期限、ステートレス、L1 EVM 有効性証明など)。改善を続ける必要があるもう 1 つの重要な点は、イーサリアム クライアント ソフトウェアの効率です。現在、5 年前に比べてはるかに効率的になっています。効果的な L1 ガスキャッピング戦略には、これらの検証テクノロジーの開発を加速することが含まれます。
EOF: 静的分析により適しており、より迅速な実装を可能にする新しい EVM バイトコード形式。これらの効率向上を考慮すると、EOF バイトコードはガスコストの削減を実現できます。
多次元のガス価格設定: コンピューティング、データ、ストレージに異なる基本料金と制限を設定することで、最大容量を増やさずにイーサリアム L1 の平均容量を増やすことができます (これにより、新たなセキュリティ リスクの発生を回避できます)。
特定のオペコードとプリコンパイルのガス コストの削減 – これまで、サービス拒否攻撃を回避するために、特定の低価格の操作についてガス コストを繰り返し増加させてきました。もっとできることの 1 つは、高価なオペコードのガスコストを削減することです。たとえば、加算は乗算よりはるかに安価ですが、現在、ADD オペコードと MUL オペコードのコストは同じです。 ADD をより安くすることができ、PUSH のようなより単純なオペコードをさらに安くすることができます。この点において、EOF は全体的により最適化されています。
EVM-MAX と SIMD: EVM-MAX は、EVM の別個のモジュールとして、より効率的なネイティブ大数アナログ数学を可能にする提案です。意図的にエクスポートしない限り、EVM-MAX 計算によって計算された値には、他の EVM-MAX オペコードからのみアクセスできます。これにより、これらの値を最適化された形式で保存するためのより多くのスペースが可能になります。 SIMD (単一命令複数データ) は、値の配列に対して同じ命令を効率的に実行できるようにする提案です。この 2 つを組み合わせることで、EVM と並行して強力なコプロセッサが作成され、暗号化操作をより効率的に実装するために使用できます。これはプライバシー プロトコルと L2 防御システムに特に役立つため、L1 および L2 のスケーリングに役立ちます。
これらの改善点については、今後の Splurge の記事で詳しく説明します。
最後に、3 番目の戦略はネイティブ ロールアップ (または祀られているロールアップ) です。基本的には、並行して実行される EVM のコピーを多数作成します。その結果、ロールアップが提供できるものと同等のモデルが得られますが、よりネイティブにプロトコルに統合されます。
既存の研究とのつながりは何ですか?
Polynya のイーサリアム L1 拡張ロードマップ: https://polynya.mirror.xyz/epju72rsymfB-JK52_uYI7HuhJ-W_zM735NdP7alkAQ
多次元ガス価格: https://vitalik.eth.limo/general/2024/05/09/multidim.html
EIP-7706: https://eips.ethereum.org/EIPS/eip-7706
EOF: https://evmobjectformat.org/
EVM-MAX: https://ethereum-magicians.org/t/eip-6601-evm-modular-arithmetic-extensions-evmmax/13168
SIMD: https://eips.ethereum.org/EIPS/eip-616
ネイティブ ロールアップ: https://mirror.xyz/ohotties.eth/P1qSCcwj2FZ9cqo3_6kYI4S2chW5K5tmEgogk6io1GE
L1 のスケーリングの価値に関する Max Resnick のインタビュー: https://x.com/BanklessHQ/status/1831319419739361321
Justin Drake が SNARK とネイティブ ロールアップによるスケーリングについて語ります: https://www.reddit.com/r/ethereum/comments/1f81ntr/comment/llmfi28/
他に何をする必要がありますか?また、トレードオフは何ですか?
L1 拡張には 3 つの戦略があり、個別にまたは並行して実行できます。
L1 の検証を容易にするためにテクノロジー (クライアント コード、ステートレス クライアント、履歴の有効期限など) を改善し、ガス制限を増やします。
最悪の場合のリスクを増加させることなく、特定の運用のコストを削減し、平均容量を増加します。
ネイティブ ロールアップ (つまり、EVM の N 個の並列コピーを作成します)。
これらのさまざまなテクノロジーを理解すると、さまざまなトレードオフがあることがわかります。たとえば、ネイティブ ロールアップには、プレーン ロールアップと同じ構成可能性の多くの弱点があります。同じ L1 (または L2) のコントラクト内で実行できるように、単一のトランザクションを送信して複数のロールアップ間で同期的に操作を実行することはできません。方法。ガスキャップを増やすと、検証ノードを実行するユーザーの割合の増加やソロステーカーの数の増加など、L1 検証の簡素化によって達成できる他の利点が弱まります。実装によっては、EVM (イーサリアム仮想マシン) での特定の操作を安価にすると、EVM 全体の複雑さが増加する可能性があります。
L1 スケーリング ロードマップで答える必要がある大きな質問は、「L1 と L2 の最終的なビジョンは何ですか?」です。明らかに、すべてを L1 に置くのはばかげています。潜在的なユースケースには 1 秒あたり数十万のトランザクションが含まれる可能性があり、その場合、L1 は完全に検証できなくなります (ネイティブのロールアップ アプローチを採用しない限り)。しかし、ガスキャップが10倍に増加し、イーサリアムL1の分散化に深刻な悪影響を与える状況に陥らないようにするには、いくつかのガイドラインが必要です。
L1 と L2 の役割分担の図
ロードマップの他の部分と対話するにはどうすればよいですか?
より多くのユーザーを L1 に取り込むことは、スケーリングを改善するだけでなく、L1 の他の側面も改善することを意味します。これは、(単に L2 の問題ではなく) より多くの MEV が L1 に残ることを意味するため、MEV を明示的に処理する必要性がより緊急になります。これにより、L1 の高速スロット時間の値が大幅に増加します。同時に、これはL1（the Verge）検証が順調に進むことにも大きく依存します。
