ヴィタリック：なぜトリレンマを破るのは難しいのですか？

原題：当初、イーサリアムのロードマップは次のようなものでした。当初、イーサリアムのロードマップには2つのスケーリング戦略がありました。そのうちの1つは「シャーディング」で、各ノードはチェーン内のすべてのトランザクションを検証して保存するのではなく、トランザクションのごく一部だけを検証して保存すればよいというものでした。これは他のピアツーピアネットワーク（BitTorrentなど）がどのように機能するかということであり、ブロックチェーンも同じように機能させることができる。もう1つはレイヤー2プロトコルです。 ネットワークはイーサの上に位置し、イーサのセキュリティの恩恵を十分に受けながら、データや計算のほとんどをメインチェーンから遠ざけることができます。 「レイヤー2プロトコル」とは、2015年のステートチャネル、2017年のプラズマ、2019年のロールアップを指す。ロールアップはステートチャネルやプラズマよりも強力だが、オンチェーンデータ帯域幅を多く必要とする。幸いなことに、2019年までにシャーディングの研究は、スケールにおける「データの可用性」を検証する問題を解決している。その結果、2つの道は収束し、アグリゲーション中心のロードマップができ、それは現在もイーサのスケーリング戦略となっている。

『サージ、2023ロードマップ版』。

ロールアップ中心のロードマップは、単純な役割分担を提案しています。イーサリアムL1は強力で分散化されたベースレイヤーであることに重点を置き、L2はエコシステムの規模拡大を支援する役割を担っています。裁判制度（L1）は超高速で効率的であることではなく、契約と財産権を保護することであり、起業家（L2）はその基盤の上に頑丈なベースレイヤーを構築し、人類を（比喩的にも文字通りの意味でも）火星に連れて行く必要がある。

今年はアグリゲーション中心のロードマップにおいて重要な成功が見られました。イーサリアムL1のデータ帯域幅はEIP-4844ブロブを介して劇的に増加し、複数のEVMアグリゲーションがフェーズ1に入りました。各L2が独自の内部ルールとロジックを持つ「シャード」として機能する、非常に異種かつ多様なシャーディングの実装が現実のものとなっている。しかし、これまで見てきたように、この道を進むには独自の課題があります。そのため、ロールアップ中心のロードマップを完成させ、イーサL1の特徴である堅牢性と分散性を維持しながら、これらの問題に対処することが、今の私たちの仕事です。

急増：重要な目標

L1+L2で100,000?+ TPS

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

L2が完全に継承したイーサの中核的属性の少なくとも一部を維持する（非信頼、オープン、censorship-resistant）

L2間の相互運用性を最大化する。イーサネットは、34の異なるブロックチェーンではなく、1つのエコシステムのように感じられるべきです。

The Scalability Trilemma

The Scalability Trilemma（スケーラビリティのトリレンマ）とは、2017年に提唱されたアイデアで、ブロックチェーンの3つの属性である、分散化（より具体的には、ノードを運営するコストが低いこと）、スケーラビリティ（より具体的には、大量のトランザクションを処理すること）、セキュリティ（より具体的には、攻撃者は34の異なるブロックチェーンではなく、1つのエコシステムを使用する必要があること）の間の緊張を仮定しています。(攻撃者が1つの取引を失敗させるには、ネットワーク全体のノードの大部分を破壊する必要がある）。

注目すべきは、トリレンマは定理ではないということで、トリレンマを紹介した投稿には数学的な証明が添えられていません。分散化された友好的なノード（例えば消費者のラップトップ）が1秒間にN件のトランザクションを検証でき、1秒間にk*N件のトランザクションを処理するチェーンがある場合、(i)各トランザクションはノードの1/kしか見ることができないため、攻撃者は悪いトランザクションを押し通すために数台のノードを壊すだけでよい。チェーンは分散化されていない。この投稿の目的は、トリレンマを破ることが不可能であることを示すことではありません。むしろ、トリレンマを破ることは困難であることを示すことでした。

何年もの間、一部のハイパフォーマンスチェーンは、インフラストラクチャーレベルで巧妙なステップを踏むことなく、通常はソフトウェアエンジニアリングのトリックを使ってノードを最適化することで、トリレンマを解決したと日常的に主張してきました。これは常に誤解を招くものであり、そのようなチェーンでノードを稼働させるのは、Etherよりもはるかに難しい。この記事では、なぜそうなるのか（そしてなぜL1クライアントソフトウェアエンジニアリングだけではEther自体をスケールさせることができないのか）について、多くの微妙な点を探ります。

しかし、データ可用性サンプリングとSNARKの組み合わせは、このトリレンマを解決します。クライアントは、ある一定量のデータが利用可能であること、およびある一定数の計算ステップが正しく実行されたことを検証することができますが、その一方で、そのデータのごく一部をダウンロードし、はるかに少ない量の計算を実行するだけです。 SNARKは信頼できない。データ可用性サンプリングは、微妙な数Nの信頼モデルを持ちますが、51%の攻撃でもネットワークに不良ブロックを受け入れさせることはできないという、スケーラブルでないチェーンが持つ基本的な特性は保持しています。

このトリレンマに対する代替的な解決策がPlasmaアーキテクチャであり、これは巧妙なテクニックを使って、データの可用性を監視する責任を、インセンティブに適合した方法でユーザーに押し付けるものです。2017年から2019年にかけて、計算をスケールさせるために必要なのは不正の証明だけだったころ、Plasmaのセキュリティ機能は非常に限られていましたが、SNARKの主流化によって、Plasmaアーキテクチャは以前よりも幅広いユースケースに適用できるようになりました。

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

私たちが解決しようとしている問題とは？

Dencunのアップグレードが本稼働する2024年3月13日の時点で、イーサリアムのブロックチェーンには、12秒のセッションあたり～125キロバイトの「ブロブ」が3つ、つまりセッションあたり～375キロバイトのデータ利用可能帯域幅があります。取引データがチェーンに直接投稿されると仮定すると、ERC20の転送は約180バイトなので、イーサでのロールアップの最大TPSは次のようになります:

375,000 / 12 / 180 = 173.6 TPS

イーサのcalldata（理論上の最大値: 1スロットあたり3,000万ガス/1バイトあたり16ガス）を追加すると、イーサでのロールアップの最大TPSは12秒スロットあたり約3,125キロバイト、1スロットあたり約375キロバイトのデータが利用可能であることがわかります。Gas=1,875,000バイト/スロット)、これは607TPSになります。PeerDASでは、ブロブカウントのターゲットを8-16に増やす計画で、これによりcalldataの463-926TPSが得られます。

これはイーサネットL1と比較して大きなブーストですが、十分ではありません。もっとスケーラビリティが欲しいのです。私たちの中期的な目標は、1スロットあたり16MBで、データ圧縮の改善と合わせると、約58,000TPSになります。

それは何であり、どのように機能するのか？

PeerDASは「1次元サンプリング」の比較的単純な実装です。Etherの各blobは、253ビットの素数フィールド上の4096次の多項式です。多項式の「共有」をブロードキャストし、各共有は合計8192個の座標セットから取り出した隣接する16個の座標における16回の評価から構成される。 8192個の評価のうち4096個（現在提案されているパラメータを使用：128個の可能なサンプルのうち64個）がブロブを復元します。

PeerDASは、各クライアントが少数のサブサーバーをリッスンすることによって動作します。ここで、1つのサブネットは任意のBlobの1番目のサンプルをブロードキャストし、さらに（異なるサブネットをリッスンしている）グローバルp2pネットワーク内のピアに問い合わせることで、他のサブネットに希望のBlobを要求します。より保守的なバージョンの SubnetDAS は、サブネット メカニズムのみを使用し、ピアを要求する追加のレイヤーはありません。現在の提案は、Proof-of-entitlementに関わるノードにはSubnetDASを使い、それ以外のノード（つまり「クライアント」）にはPeerDASを使うというものです。span>

理論的には、1Dサンプリングはかなり遠くまで拡張できます。最大ブロブカウントを256（したがって、ターゲットは128）に増やすと、16MBのターゲットに到達し、データ可用性のためのサンプリングは、ノードあたり16サンプル* 128ブロブ*サンプルあたりブロブあたり512バイト=スロットあたり1MBのデータ帯域幅しかかかりません。スロットあたり1MBのデータ帯域幅。実現可能ですが、帯域幅に制約のあるクライアントはサンプリングできないことになります。blobの数を減らしてblobサイズを大きくすることで最適化することもできますが、そうすると再構築のコストが高くなります。

そこで最終的には、さらに一歩進んで、ブロブ内だけでなくブロブ間もランダムにサンプリングする2Dサンプリングを行いたいと考えました。 KZGによって約束された線形特性は、同じ情報を冗長にエンコードする「仮想blob」の新しいリストによって、ブロック内のblobのセットを「拡張」するために使用されます。

2Dサンプリング。

決定的に、計算約束のスケーリングはブロブを必要としません。は分散ブロック構築に基本的に友好的です。実際にブロックを構築するノードは、ブロブKZGコミットメントを持つ必要があるだけで、ブロブの可用性を検証するためにDASに依存することができます。 また、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

KZG2Dアベイラビリティ・ウィズ・ケイト・コミットメント：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のブロブ数を増やしていくのは、セキュリティを確保するためにネットワークを注意深く観察し、ソフトウェアを改善しながら、少しずつ進めていくことになります。その間、私たちはPeerDASや他のバージョンのDAS形式論や、フォーク選択ルールのセキュリティなどの問題との相互作用について、より学術的な研究を行いたいと考えています。

今後の展望としては、2D DASの理想的なバージョンを見つけ、そのセキュリティ特性を証明するために、より多くの作業を行う必要があります。また、最終的にはKZGから、量子耐性があり、信頼できるセットアップを必要としない代替に移行したいと考えています。現在、私たちは分散ブロック構築に適した候補を知りません。STARKのハッシュは技術的にO(log(n) * log(log(n))(対STIR)であり、実際にはSTARKはパッチ全体とほぼ同じ大きさであるためです。

長い目で見ると、現実的な道は次のようなものだと思います:

• 理想的な2D DASツール;

• 1D DASにこだわる。

• サンプリング帯域幅の効率を犠牲にし、シンプルさと堅牢性のために低いデータ上限を受け入れる。

• (ハードピボット)DAを放棄し、我々が注力する主要なレイヤー2アーキテクチャとしてPlasmaを完全に受け入れる。

L1で実行を直接スケールすることにしても、この選択肢はまだ存在することに注意してください。これは、L1 が多くの TPS を処理する場合、L1 ブロックは非常に大きくなり、顧客はそれらが正しいことを検証する効率的な方法が必要になるため、アグリゲーション (ZK-EVM および DAS) と L1 をサポートする同じテクノロジーを使用しなければならないからです。

ロードマップの残りの部分とどのように相互作用するのでしょうか?

データ圧縮が実装されれば (下記参照)、2D DAS の必要性は減少するか、少なくとも遅れるでしょう。 DAS はまた、分散ブロック構築プロトコルおよびメカニズムに課題をもたらします。DAS は理論的には分散再構成に友好的ですが、実際には、インクルード リストの提案とその周辺のフォーク選択メカニズムと組み合わせる必要があります。

データ圧縮

私たちはどのような問題を解決しようとしているのでしょうか?

Rollupの各トランザクションは、多くのオンチェーンデータスペースを占有します: ERC20の転送には約180バイトかかります。理想的なデータ可用性のサンプリングであっても、これはレイヤー2プロトコルのスケーラビリティを制限します。スロットあたり16MBの場合、

16000000 / 12 / 180 = 7407 TPS

分子を解決することに加えて、分母を解決し、アグリゲーションの各トランザクションがチェーン上で占めるバイト数を少なくすることができたらどうでしょうか？

それはどのようなもので、どのように機能するのでしょうか？

2年前のこのチャートが一番わかりやすいと思います。

最も単純な利得は、ゼロバイト圧縮です。ゼロバイトの各長いシーケンスを、ゼロバイトの数を表す2バイトで置き換えます。

• Signature Aggregation - ECDSA署名からBLS署名に切り替えます。BLS署名は、多くの署名を組み合わせて、すべての元の署名の有効性を証明する単一の署名を形成できるという特性を持っています。 L1では、検証の計算コストが（アグリゲーションであっても）高くなるため、この点は考慮されていないが、L2のようなデータが乏しい環境では、議論の余地なく理にかなっている。 ERC-4337のアグリゲーション機能は、これを実現する方法を提供します。

• アドレスをポインタに置き換える - アドレスが以前に使用されたことがある場合、20バイトのアドレスを過去の場所への4バイトのポインタに置き換えることができます。これは、ブロックチェーンの（少なくとも一部の）履歴を事実上状態の一部とする必要があるため、実現には努力が必要ですが、最大の利益を実現するために必要です。

• 取引値のカスタムシリアライゼーション - ほとんどの取引値は桁数が非常に少ないです。 その結果、ほとんどの通貨値を非常にコンパクトに表現するために、カスタムの10進浮動小数点フォーマット、あるいは特に一般的な値の辞書を使用することができます。

既存の研究とのつながりは何ですか?

sequence.xyzからの探索：https://sequence.xyz/blog/compressing-calldata

L2のためのカルデータ最適化契約、ScopeLiftから：https://github.com/ScopeLift/l2-optimizoooors

別の戦略 - Proof-of-Validity-based aggregation (別名ZK aggregation)は、トランザクションの代わりに状態の違いを公表する！https://ethresear.ch/t/rollup-diff-compression-application-level-compression-strategies-to-reduce-the-l2-data-footprint-on-l1/9975 on-l2-data-footprint

BLSウォレット - ERC-4337経由のBLSアグリゲーション: https://github.com/getwax/bls-wallet

他に何が必要か、トレードオフは何か？

残された主なことは、上記のオプションを実践することです。主なトレードオフは次のとおりです:

• BLS 署名に切り替えるには多大な労力が必要であり、セキュリティを向上できる信頼できるハードウェアチップとの互換性が低下します。他の署名スキーム用のZK-SNARKラッパーで置き換えることは可能です。

• 動的圧縮（アドレスをポインタに置き換えるなど）はクライアントコードを複雑にします。

• トランザクションの代わりにチェーンに状態の違いをポストすることは、監査可能性を低下させ、ブロックブラウザのような多くのソフトウェアの動作を妨げます。

ロードマップの他の部分とどのように関わっているのでしょうか？

ERC-4337が採用され、最終的にその一部がL2 EVMに組み込まれることで、アグリゲーション技術の展開が大幅に加速される可能性があります。ERC-4337の一部をL1に組み込むことで、L2への展開が加速される可能性があります。

Generalised Plasma

私たちはどのような問題を解決しようとしているのでしょうか?

16MBのブロブとデータ圧縮を使っても、58,000TPSでは消費者決済や分散型ソーシャル、その他の高帯域幅の領域を完全に引き継ぐには不十分かもしれません。 大量で価値の低いアプリの場合、今日の選択肢の1つはvalidiumは、データをオフチェーンに保持し、興味深いセキュリティモデルを持っている。しかし、我々はそれよりも良いことができる。

それは何であり、どのように機能するのですか？

Plasmaは、オペレーターがブロックをオフチェーンに投稿し、そのブロックのメルクルの根をオンチェーンに配置するスケーリングソリューションです（ブロック全体をオンチェーンに配置するロールアップとは対照的です）。各ブロックについて、オペレーターは各ユーザーにMerkleブランチを送信し、そのユーザーの資産に何が起こったか、起こらなかったかを証明する。ユーザーは、Merkleブランチを提供することで、資産を引き出すことができる。重要なのは、ブランチは最新の状態をルートとする必要はないということである。したがって、データの可用性に失敗しても、利用可能な最新の状態を引き出すことで、ユーザーは資産を回復することができる。ユーザーが無効なブランチを提出した場合（例えば、すでに誰かに送ったアセットを引き出したり、オペレーターが何もないところからアセットを作成したりした場合）、オンチェーンチャレンジメカニズムによって、そのアセットが誰のものかを正しく判断することができます。

プラズマキャッシュチェーン図。コインiの取引はツリーのiの位置に置かれます。この例では、以前のツリーがすべて有効であると仮定すると、Eveは現在コイン1を所有し、Davidはコイン4を所有し、Georgeはコイン6を所有していることがわかります。

以前のバージョンのPlasmaでは、支払いユースケースしか処理できず、それ以上効率的に拡張できませんでした。しかし、すべてのルートがSNARKで検証されることを要求すれば、Plasmaははるかに強力になります。オペレーターが不正を働く可能性のある経路のほとんどを排除できるため、あらゆるチャレンジゲームが大幅に簡素化されます。また、新たな道も開けるため、Plasmaテクノロジーはより幅広いアセットクラスに対応できるようになる。最後に、オペレーターの不正行為がない場合、ユーザーはチャレンジ期間の1週間を待つことなく、すぐに資金を引き出すことができます。

EVMを作る。プラズマチェーンを作る1つの方法(唯一の方法ではない): ZK-SNARKを使用して、EVMによるバランスの変更を反映した並列UTXOツリーを構築し、何が「同じコイン」であるかを定義し、歴史の違いを一意にマッピングします。そして、この上にプラズマ構造を構築することができます。

重要な洞察は、プラズマシステムは完璧である必要はないということです。資産のほんの一部しか保護できなくても（たとえば、過去1週間に動かなかったトークンだけでも）、超スケーラブルなEVMの現状をすでに大幅に改善しており、これは検証です。

構造のもう1つのクラスは、IntmaxのようなハイブリッドPlasma/rollups構造です。これらはユーザーごとに非常に少量のデータ（たとえば5バイト）をチェーン上に置き、そうすることでPlasmaと集約の中間のような特性を得ます。16MBの世界では、理論的な容量の上限も約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

他に何をすべきか、何を量る必要があるのか？

残された主な仕事は、プラズマシステムを生産体制に入れることだ。前述したように、「プラズマ対バリディウム」は二項対立ではありません。どんなバリディウムでも、出口メカニズムにプラズマ機能を追加することで、少なくとも少しは安全性を高めることができます。研究の一環として、EVMの最良の特性（信頼要件、ワーストケースのL1ガスコスト、DoS脆弱性の観点）と代替のアプリケーション固有のアーキテクチャを得ることがある。さらに、Plasmaとロールアップの概念の複雑さについては、研究とより良い汎用フレームワークの構築を通じて直接対処する必要があります。

プラズマ設計を使用する主な欠点は、よりオペレーターに依存し、「ベース」にするのが難しいことですが、プラズマ/ロールアップのハイブリッド設計はこの弱点を回避できることがよくあります。

ロードマップの他の部分とどのように影響し合いますか？

Plasmaソリューションがより効果的であればあるほど、L1に高性能なデータ可用性機能を求めるプレッシャーは少なくなります。また、活動を L2 に移すことで、L1 の MEV に対するプレッシャーも軽減されます。

Mature L2 Proven Systems

私たちはどのような問題を解決しようとしているのでしょうか?

今日、ほとんどのアグリゲーションは実際には信頼されていません。プルーフシステムの振る舞いを（楽観的または妥当な形で）上書きする能力を持つセキュリティ評議会があります。場合によっては、証明システムが存在しないか、存在しても「助言」の機能しか持たないこともある。最前線にあるのは、(i)Fuelのような非信頼化されたいくつかのアプリケーション固有のアグリゲート、(ii)OptimismとArbitrumの2つの完全なEVMアグリゲートで、この記事を書いている時点で「ステージ1」として知られる部分的な非信頼化のマイルストーンを達成している。 Rollupsがこれ以上進んでいないのは、コードのバグが懸念されるためであり、信頼されていないアグリゲートが必要である以上、この問題に正面から取り組む必要があります。

それは何であり、どのように機能するのか？

まず、この記事で最初に紹介した「ステージ」システムについておさらいしましょう。

• Stage 0:ユーザーはノードを実行し、チェーンを同期させることができなければなりません。バリデーションが完全に信頼/集中化されていれば問題ありません。

• ステージ1：有効なトランザクションのみが受け入れられることを保証する（信頼されない）証明システムがなければなりません。証明システムを上書きできるセキュリティ評議会の存在は認められるが、投票しきい値は75%に限られる。さらに、評議会の定足数ブロック部分（すなわち26％以上）は、アグリゲーションを構築する主要企業の外部に位置していなければならない。あまり強力でないアップグレードメカニズム（DAOなど）も認められていますが、悪意のあるアップグレードが承認された場合、アップグレードが本稼働する前にユーザーが資金を引き出せるよう、十分な遅延が必要です。

• 第2段階：有効なトランザクションだけが受け入れられるように、（信頼できない）証明システムがなければなりません。評議会の介入は、たとえばコードに証明可能なエラーがある場合にのみ許可されます。2つの冗長なプルーフシステムが互いに矛盾している場合、あるいはプルーフシステムが同じピースの2つの異なるポストステート・ルートを受け入れる場合（あるいは1週間など十分長い期間何も受け入れない場合）。アップグレードメカニズムは許されるが、長い遅延がある場合に限る。

私たちの目標はステージ2に到達することです。ステージ2に到達するための主な課題は、証明システムが実際に十分に信頼に足るものであることを実証するのに十分な信頼を得ることです。

• Formal validation:私たちは、最新の数学的・計算的テクニックを使って、証明システムが実際に十分信頼できるものであることを証明することができます。妥当性)を証明することができます。これらのテクニックは何十年も前からありましたが、最近の進歩(リーン4など)によってより実用的になり、AI支援証明の進歩はこの傾向をさらに加速させるかもしれません。

• 複数の証明：複数の証明システムを作成し、これらの証明システムとセキュリティ・カウンシル（および/またはTEEのような信頼前提の他のガジェット）の間の2/3（またはそれ以上）の複数署名に資金を投入する。もし証明システムが合意すれば、安全保障理事会には何の力もない。同意しない場合、理事会はそのうちの1つを選ぶことしかできず、一方的に独自の答えを押し付けることはできません。

楽観的証明システム（optimistic proof system）、有効性証明システム（validity proof system）、証明システム（validity proof system）を組み合わせた、複数の証明者のプログラムされたグラフ。妥当性証明システムと安全委員会を組み合わせた、複数の証明者のプログラムされたグラフ。

既存の研究とのつながりは？

EVM K Semantics（2017年以降の形式的検証作業）:https://github.com/runtimeverification/evm-semantics

複数証明者のアイデアに関するデモンストレーション（2022年）: https://www.youtube.com/watch?v=6hfVzCWT6YI

太鼓判は多重証明を使う予定です:https://docs.taiko.xyz/core-concepts/multi-proofs/

他に何が必要か、何を量る必要があるか？

正式な検証については、たくさんあります。EVM用のSNARKプローバー全体の形式検証バージョンを作成する必要があります。これは非常に複雑なプロジェクトですが、すでに着手しています。この作業を大幅に簡略化できるトリックがある。例えば、最小のVM用の形式検証済みSNARKプローバーを作ることができる。 例えば、RISC-VやCairoのような最小のVMに対して正式に検証されたSNARK証明器を作成し、その最小のVMでEVMの実装を書きます（そして、他のEVM仕様との等価性を正式に証明します）。

マルチプル・プローバに残された部分は主に2つあります。まず第一に、少なくとも2つの異なる証明システムにおいて、それぞれが合理的に安全であり、クラッシュした場合は異なる無関係な理由でクラッシュする（つまり同時にクラッシュしない）ことを十分に確信する必要があります。第二に、マージされた証明システムの基礎となるロジックについて、非常に高いレベルの保証が必要である。これは小さなコードの一部である。これを非常に小さくする方法は複数ある。安全なマルチシグネチャ・コントラクトに資金を保管し、その署名者を個々の証明システムを表すコントラクトにするのだ。効率とセキュリティの間で何らかのバランスを見つける必要がある。

ロードマップの他の部分とはどのような関係があるのでしょうか？

活動をL2に移すことで、L1のMEVへの圧力を減らすことができます。

Trans-L2 相互運用性の向上

私たちはどのような問題を解決しようとしているのでしょうか?

今日のL2エコシステムにおける大きな課題の1つは、ユーザーが操作するのが難しいということです。加えて、最も単純なアプローチは、中央集権的なブリッジ、RPCクライアントなど、信頼の前提をしばしば再導入します。もし私たちがL2がEtherの一部であるという考えに真剣に取り組んでいるのであれば、L2エコシステムを統一されたEtherエコシステムを使用しているように感じられるようにする必要があります。

クロスL2 UXの病的な悪い例です（危険ですらあります。の相互運用性はウォレットとEtherCard (ERC) ) コミュニティの責任であるべきです。うまく運営されているイーサネットエコシステムでは、L1からL2へ、またはあるL2から別のL2へトークンを送信することは、同じL1でトークンを送信するのと同じであるべきです。

それは何であり、どのように機能するのか？

クロスL2相互運用性の改善には多くのカテゴリーがあります。一般的に、これらの質問をする方法は、理論上、集約中心のEtherはL1実行シャーディングと同じであることに注意し、現在のEther L2バージョンは実際にはどのような点で理想から外れているのかを質問することです。

• Chain-specific address:チェーン（L1、Optimism、Arbitrum...）。アドレスの一部でなければなりません。一旦実装されれば、クロスL2送信プロセスは単に "send "フィールドにアドレスを置くことで実現でき、ウォレットはバックグラウンドでそれを行う方法を見つけ出すことができます（ブリッジングプロトコルの使用を含む）。

• チェーン固有の支払いリクエスト：「ZチェーンのYタイプのXトークンを送ってください」という形式のメッセージを作成することは、シンプルで標準化されるべきです。これには主に2つのユースケースがある：(i)個人間または個人から商人へのサービスのための支払い、(ii)例えば資金を要求するDapps。上記のPolymarketの例。

• クロスチェーン交換とガス決済：クロスチェーン操作を表現するための標準化されたオープンなプロトコルがあるべきです！"、"Arbitrumでこのトランザクションを含む人にOptimismで0.0001 ETHを送ります "といった具合です。 ERC-7683は前者の試みであり、RIP-7755は後者の試みですが、どちらもこれらの特定のユースケースよりも汎用的です。

• ライトクライアント：ユーザーは、RPCプロバイダーを信頼するだけでなく、やりとりしているチェーンを実際に検証できるべきです。 ERC-3668（CCIP-read）は、これを達成するための1つの戦略です。

ライトクライアントがイーサースカラチェーンのビューを更新する方法。ヘッダーチェーンを手に入れたら、Merkle証明を使ってステートオブジェクトを検証することができる。L1のステートオブジェクトが正しくなれば、L2のステートオブジェクトを検証するために、Merkle証明（事前確認をチェックしたい場合は署名も可能）を使うことができる。Helios はすでに前者を行っている。後者への拡張は標準化の課題です。

• Keystore wallets:今日、スマートコントラクトのウォレットを制御するキーを更新したい場合、ウォレットが存在するすべてのN個のチェーン上でこれを実行しなければなりません。そのウォレットが存在するすべてのN個のチェーン上で行う必要があります。キーストア・ウォレットは、鍵を1つの場所（L1か、場合によってはL2）に存在させ、ウォレットのコピーを持っているL2から読み取ることを可能にする技術です。つまり、更新は一度だけで済む。効率化のために、キーストアウォレットはL2がコストをかけずにL1を読み取る標準化された方法を持つ必要があります。そのための2つの提案は、L1SLOADとREMOTESTATICCALLです。watermarknone.png" title="7309019" alt="PCHEpEQ3ya9wcyPDfJzf0aZw1DAgpjc9XProgmsK.jpeg">

  キーストア・ウォレットがどのように動作するかのプログラム図。

  • 「共有トークン・ブリッジ」のより急進的なアイデア：すべてのLCNが「共有トークン・ブリッジ」である世界を想像してみてください。すべてのL2が有効性の証明の集合体であり、すべてのスロットがイーサ専用である世界を想像してみてください。この世界でも、あるL2から別のL2へ「ローカルに」資産を転送するには、引き出しと預け入れが必要になり、大量のL1ガスが必要になります。 この問題を解決する1つの方法は、共有の最小集合体を作成することです。これらの残高は、一連の交差を通じてまとめて更新される。L2送信操作はどのL2からでも開始できる。これにより、送金ごとにL1 Gasを支払う必要がなく、流動性プロバイダーベースの技術（ERC-7683など）を必要とせずに、L2間の送金が可能になる。

  • Synchronisation Composability:特定の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

  Rolling keystore wallet design:https://hackmd.io/@haichen/keystore

  ヘリオス: https://github.com/a16z/helios

  ERC-3668 (CCIP-readと呼ばれることもあります。CCIP-readと呼ばれることもある）：https://eips.ethereum.org/EIPS/eip-3668

  ジャスティン・ドレイク。left;">Justin Drakeの「（共有された）事前確認に基づく」という提案：https://ethresear.ch/t/based-preconfirmations/17353

  L1SLOAD (RIP-7728):  https://ethereum-magicians.org/t/rip-7728-l1sload-precompile/20388

  楽天のリモートコール：https://github.com/ethereum-optimism/ecosystem-contributions/issues/76

  共有トークンブリッジのアイデアを含むAggLayer: https://github.com/AggLayer

  他にやるべきこと、重くすべきことは？

  上記の例の多くは、いつ標準化するか、どのレイヤーを標準化するかという標準的なジレンマに直面しています。標準化が早すぎると、劣ったソリューションになる危険性がある。標準化が遅すぎれば、不必要に断片化する危険性がある。場合によっては、弱くても実装しやすい短期的な解決策もあれば、「最終的には正しい」が実現にはかなりの時間がかかる長期的な解決策もある。

  このセクションの特徴は、これらの課題が単なる技術的な問題ではなく、（おそらく第一義的には!）社会的な問題でもあります。L1だけでなく、L2やウォレットも協力する必要があるのです。私たちがこの問題にうまく取り組めるかどうかは、コミュニティとして団結できるかどうかが試されるのです。

  ロードマップの他の部分とはどのように関わっているのでしょうか？

  これらの提案のほとんどは「より上位の」構造であるため、L1の検討にはあまり影響しません。1つの例外は、MEVに大きな影響を与える共有順序です。

  L1 上での実行の拡張

  私たちはどのような問題を解決しようとしているのでしょうか?

  • ETH Asset

  • L2が非常にスケーラブルになり成功しても、L1がまだ非常に少数のトランザクションしか処理できない場合、イーサには多くのリスクが発生する可能性があります。経済の危険性が高まり、ネットワークの長期的な安全性に影響します。

  • 多くのL2は、L1の高度に発達した金融エコシステムとの強いつながりから利益を得ており、そのエコシステムが著しく弱まれば、（スタンドアロンのL1ではなく）L2になるインセンティブは低下します。

  • L2がL1とまったく同じセキュリティ保証を得るには、長い時間がかかるでしょう。

  • L2に障害が発生した場合（たとえば、悪意のある操作やオペレーターの失踪が原因）、ユーザーは資産を回復するためにL1を経由する必要があります。したがって、L1は、少なくとも時折、L2の非常に複雑で混沌とした終端を実際に処理するのに十分堅牢である必要があります。

  これらの理由から、L1自体を拡張し続け、増加する用途に適応し続けることを保証することは価値があります。

  L1とは何か、どのように機能するのか？

  L1を拡張する最も簡単な方法は、単にガス制限を追加することである。しかし、これはL1を中央集権化する危険性があり、それによってEther L1を強力にしているもう1つの重要な属性、つまり強力なベースレイヤーとしての信頼性が損なわれます。単純なGas制限をどの程度増やすことが持続可能かについては議論が続いており、より大きなブロックを検証しやすくするために実装される他の技術（履歴の有効期限、ステートレス、L1 EVMの有効性の証明など）によっても変わってくるでしょう。常に改善する必要があるもう1つの重要な点は、イーサネット・クライアント・ソフトウェアの効率性である。効果的なL1ガス上限増加戦略には、これらの検証技術の高速化が含まれます。

  もう1つのスケーリング戦略には、ネットワークの分散化やセキュリティ特性を損なうことなく、より安価にできる特定の機能やタイプの計算を特定することが含まれます。

  • EOF - 新しいEVMバイトコード形式です。実装を高速化します。これらの効率性を考えると、EOF バイトコードはより低いガス・コストを与えることができます。

  • Multidimensional Gas Pricing - コンピュート、データ、ストレージに別々の基本コストと上限を設定することで、最大容量を増やすことなく、Ether L1の平均容量を増やすことができます（したがって、新たなセキュリティリスクを生み出します）。

  • 特定のオペコードとプリコンパイルに対するガスコストの削減 - 歴史的に、私たちはサービス拒否攻撃を避けるために、特定の価格の低いオペレーションに対するガスコストの値上げを何度か行ってきました。これまであまり行ってきませんでしたが、もっと行うことができるのは、過剰価格の操作のガス コストを削減することです。例えば、足し算は掛け算よりはるかに安いが、ADDとMULの演算コードは現在同じコストである。ADDをもっと安くし、さらに単純なオペコード（PUSHなど）をもっと安くすることができる。 EOFは全体的にもっとです。

  • EVM-MAXとSIMD: EVM-MAX ("Modular Arithmetic Extension") は、EVMの独立したモジュールとして、ネイティブの大きな数のより効率的なモジュール演算を可能にする提案です。EVM-MAXの計算によって計算された値は、意図的にエクスポートされない限り、他のEVM-MAXのオペコードによってのみアクセスすることができます。 SIMD（「Single Instruction Multiple Data」）は、値の配列に対して同じ命令を効率的に実行できるようにするための提案である。この2つをEVMと併用することで、暗号演算をより効率的に実装できる強力なコプロセッサを実現できる。これは特にプライバシー・プロトコルやL2証明システムに有用なので、L1やL2の拡張に役立つでしょう。

  これらの改良点については、今後のSplurgeの記事で詳しく説明します。

  最後に、3つ目の戦略はネイティブアグリゲーション(または「ビルトインアグリゲーション」)です。基本的に、並列に実行されるEVMのコピーを多数作成することで、アグリゲーションによって提供されるものと同等の、よりネイティブにプロトコルに統合されたモデルが得られます。

  既存の研究とのつながりは？

  イーサネット L1 拡張のためのポリニヤのロードマップ: https://polynya.mirror.xyz/epju72rsymfB-JK52_uYI7HuhJ-W_zM735NdP7alkAQ

  Polynya's Gas Pricing: https://vitalik.eth.limo/general/2024/05/09/multidim.html

  Polynya's Gas Pricing: https://vitalik.eth.limo/general/2024/05/09/multidim.htmlalign: left;">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

  Native Summary: https://mirror.xyz/ohotties.eth/P1qSCcwj2FZ9cqo3_6kYI4S2chW5K5tmEgogk6io1GE

  Native Summary: L1延長の価値についてのマックス・レズニックへのインタビュー：https://x.com/BanklessHQ/status/1831319419739361321

  SNARKとネイティブアグリゲーションによるスケーリングについてのジャスティン・ドレイク:https://www.reddit.com/r/ethereum/comments/1f81ntr/comment/llmfi28/

  また何をすべきか、何を量るべきか？

  • 技術の向上（例：クライアント側のコード、ステートレスクライアント、履歴の有効期限）により、より簡単にL1バリデーションを行い、ガス制限を増やします

  • 特定の操作のコストを削減し、ワーストケースリスクを増やすことなく平均容量を増やします

  • ネイティブアグリゲーション(つまり、「EVMのN個の並列コピーを作成する」こと。ただし、これはレプリカを展開するためのパラメーターという点で、開発者に大きな利点をもたらすかもしれません)。レプリカを展開するためのパラメーター)

  これらはトレードオフの異なる手法であることを理解する価値があります。たとえば、ネイティブ集約は、コンポーザビリティの点で通常の集約と同じ弱点を多く持っています。同じL1（またはL2）上でコントラクトを処理できるのと同じように、複数のトランザクションにわたって操作の実行を同期させるために単一のトランザクションを送信することはできません。Gasの上限を増やすと、検証済みノードを実行するユーザーの割合を増やしたり、個別のコラテライザーを追加したりするなど、L1を検証しやすくすることで達成できる他のメリットが失われる。EVMの特定の操作を(どのように行うかによって)安くすることは、EVMの全体的な複雑さを増加させる可能性があります。

  どのようなL1拡張ロードマップでも答える必要がある大きな疑問の1つは、「L1とL2の最終的なビジョンは何か」ということです。明らかに、L1ですべてを行うのは馬鹿げています。1秒間に何十万ものトランザクションがある潜在的なユースケースは、L1を完全に検証不可能なものにしてしまうでしょう（ネイティブアグリゲーションルートに行かない限り）。しかし、Gasの上限を10倍に引き上げ、Ether L1の非中央集権性を著しく損ない、99%の活動がL2で行われる代わりに90%の活動がL2で行われるような状況に陥らないよう、いくつかの指針が必要です。ほとんど不可逆的な損失だ。

  

  L1とL2の「役割分担」についての提案

  ロードマップの他の部分との相互作用は？

  ロードマップの他の部分とどのように関わっているのか？

  より多くのユーザーをL1に参加させることは、スケールだけでなく、L1の他の側面も改善することを意味します。これは、より多くのMEVが（L2だけの問題ではなく）L1に残ることを意味し、明示的に対処することがより緊急に必要となります。これはL1での高速タイムスロットの価値を大きく高めるものである。また、L1の検証（「The Verge」）がうまくいくかどうかにも大きく依存している。