ヴィタリック 新記事:イーサリアムの未来の可能性、サージ

著者: ヴィタリック・ブテリン

コンパイラ: Karen, Foresight News

Justin Drake氏、Francesco氏、Hsiao-wei Wang氏、@antonttc氏、Georgios Konstantopoulos氏に感謝します。

イーサリアム坊のロードマップでは、最初、2つのスケーリングストラテジーがありました。1つは（2015年の初期の論文を参照）、シャーディング：各ノードはすべてのトランザクションを検証および保存するのではなく、一部のトランザクションのみを検証および保存する必要があります。他の任意のピアツーピアネットワーク（たとえばBitTorrent）も同じように機能するため、ブロックチェーンも同じ方式で機能させることができます。もう1つはLayer2プロトコルです：これらのネットワークはイーサリアム坊の上に位置し、そのセキュリティを十分に活用しながら、大部分のデータと計算をメインチェーンの外に保持します。Layer2プロトコルは、2015年のステートチャネル、2017年のプラズマ、そして2019年のロールアップを指します。ロールアップはステートチャネルやプラズマよりも強力ですが、大量のオンチェーンデータ帯域幅が必要です。幸いなことに、2019年までに、シャーディング研究は大規模な検証の「データ可用性」の問題を解決しました。その結果、2つのパスが統合され、私たちは今日もなおイーサリアム坊の拡張戦略の中心であるロールアップ中心のロードマップを得ました。

The Surge、2023年のロードマップ版

Rollup中心のロードマップは、シンプルな役割分担を提案しています：ETH坊L1は、強力で分散化された基盤層としての役割に注力し、L2はエコシステムの拡大を支援する役割を担います。このモデルは社会に普遍的に存在しており、裁判所システム（L1）は超高速で高効率なものではなく、契約や財産権を保護するために存在しており、起業家（L2）はこの堅固な基盤層の上に建設を行い、人類を（文字通りまたは比喩的に）火星に導いています。

今年、Rollupを中心としたロードマップは重要な成果を上げました：EIP-4844 blobsの導入により、ETH坊 L1のデータ帯域が大幅に増加し、複数のETH坊仮想マシン（EVM）Rollupが第一段階に進入しました。各L2はそれぞれ独自のルールとロジックを持つ「シャーディング」として存在し、シャーディングの実現方法の多様性と多元化は今や現実となっています。しかし、この道を進むには独自の課題も存在します。そのため、Rollupを中心としたロードマップを完成させ、これらの問題を解決し、同時にETH坊 L1の安定性と分散性を維持することが現在の課題です。

The Surge：キーポイント

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

2、L1の分散化とロバスト性を維持する；

3、少なくともいくつかのL2は、イーサリアムの核心的な特性（トラストレス、オープン、検閲耐性）を完全に継承しています。

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

章目次

1. 拡張性の三角形パラドックス
2. データ可用性サンプリングのさらなる進展
3. データ圧縮
4. 普遍化されたプラズマ
5. 成熟した L2 構成証明システム
6. クロス L2 相互運用性の改善
7. L1での実行の拡張

スケーラビリティの三角形のパラドックス

可扩展性三角悖论は2017年に提案されたアイデアで、ブロックチェーンの三つの特性が矛盾していると考えられています：分散化（具体的には、ノードの運営コストが低いこと）、スケーラビリティ（処理するトランザクションの量が多いこと）、セキュリティ（攻撃者は大部分のノードを破壊する必要があるため、単一のトランザクションの失敗を引き起こすことができます）。

三角悖论は定理ではなく、三角悖论を紹介する投稿には数学的証明が付属していません。それは確かに啓示的な数学的論拠を提供しています：分散化フレンドリーなノード（例えば消費者向けノートパソコン）は、1秒あたりN件の取引を検証でき、1秒あたりk*N件の取引を処理するチェーンを持っている場合、（i）各取引は1/kのノードのみが見ることができ、これは攻撃者が少数のノードを破壊するだけで悪意のある取引を通過させることができることを意味し、または（ii）あなたのノードは強力になるが、あなたのチェーンは分散化しない。この記事の目的は、三角悖论を破ることが不可能であることを証明することではなく、代わりに三元悖论を破ることは困難であり、この論証に含まれる思考枠組みからある程度飛び出す必要があることを示すことです。

多年にわたり、いくつかの高性能チェーンは、アーキテクチャを根本的に変更せずに三重の逆説を解決していると主張してきました。通常、ノードの最適化をソフトウェアエンジニアリングの技術を用いて行います。しかし、これは常に誤解を招くものであり、これらのオンチェーンでのノードの実行はETHノードでの実行よりもはるかに困難です。本記事では、なぜそうなのか、そしてなぜL1クライアントソフトウェアエンジニアリング自体だけではETHノードをスケーリングすることはできないのかについて考察します。

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

三つの困難な課題を解決する別の方法は、Plasmaアーキテクチャです。Plasmaは、データの可用性を監視する責任をユーザーに委ねるための巧妙な技術を使用しています。2017年から2019年にかけて、計算能力を拡張する手段として詐欺証明しかなかった時期には、Plasmaは安全な実行に制約がありましたが、SNARKs（ゼロ知識証明）の普及により、Plasmaアーキテクチャは以前よりも広範な使用シナリオでより実現可能になりました。

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

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

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

ETHブロックチェーンのcalldata（理論上の最大値：スロットごとに3000万ガス/バイトあたり16ガス=スロットごとに1875000バイト）が追加されると、TPSは607になります。PeerDASを使用すると、ブロブの数は8〜16に増加し、これによりcalldataのTPSが463〜926になります。

これはETH坊 L1の重要なアップグレードですが、まだ不十分です。 より多くのスケーラビリティを望んでいます。 中期目標は各スロットが16 MBで、ロールアップデータ圧縮の改善と組み合わせると、約58000 TPSになります。

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

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

PeerDASの動作原理は、各クライアントが少量のサブネットをリッスンすることで、i番目のサブネットがブロブのi番目のサンプルをブロードキャストし、他のサブネット上のブロブを要求するためにグローバルp2pネットワーク上のピア（異なるサブネットをリッスンする）に問い合わせることです。より保守的なバージョンのSubnetDASは、サブネットメカニズムのみを使用し、追加のピアレベルの問い合わせは行いません。現在の提案は、プルーフオブステークのノードがSubnetDASを使用し、他のノード（つまりクライアント）がPeerDASを使用することです。

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

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

したがって、最終的には、さらに2Dサンプリングを行いたいと考えています。これにより、ブロック内だけでなく、ブロック間でもランダムにサンプリングが行われます。KZGが約束する線形特性は、同じ情報を冗長に符号化する新しい仮想ブロブリストを含むブロック内のブロブセットを拡張するために使用されます。

2D サンプリング。データソース：a16z crypto

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

既存の研究との関連はありますか？

1. データの利用可能性に関する元の投稿（2018年）:
2. フォローアップ論文：
3. DASに関する説明記事、パラダイム：
4. KZGコミットメント付きの2D可用性：
5. PeerDAS on ethresear.ch: and Papers:
6. EIP-7594:
7. ethresear.ch 上のSubnetDAS:
8. 2D サンプリングでの復元可能な微小な違い：

まだ何をすべきですか？ どんなバランスを取る必要がありますか？

次に、PeerDASの実装と展開を完了します。その後、PeerDAS上のblobの数を増やし続け、ネットワークを注意深く監視し、ソフトウェアを改善して安全性を確保するための進行中のプロセスです。同時に、PeerDASおよび他のバージョンのDASとフォーク選択ルールの相互作用に関連するセキュリティの問題を規範化するためのさらなる学術的な取り組みを期待しています。

未来のさらなる段階では、2D DASの理想的なバージョンを特定し、その安全性を証明するためにさらなる作業が必要です。また、KZGから量子安全で信頼設定が不要な代替案に移行できることを期待しています。現時点では、分散ブロック構築にとって友好的な候補案がどれかはまだはっきりしていません。「蛮力」技術を使用しても、再帰的STARKを使用して行と列を再構築するための有効性の証明を生成しても、要件を満たすには不十分です。なぜなら、技術的にはSTARKのサイズはO(log(n) * log(log(n))ハッシュ値（STIRを使用）であり、実際にはSTARKはほぼブロブ全体と同じくらい大きいからです。

私の長期的な現実の道筋は、と考えています。

1.理想的な2D DASを実装します。 2. 1D DASを使用し続けて、サンプリング帯域効率を犠牲にして、単純さと頑健性のためにより低いデータ上限を受け入れる 3. DAを放棄し、Plasmaを完全に採用して、フォローの主要なLayer2アーキテクチャとして受け入れる。

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

他のロードマップの部分との対話方法は？

データ圧縮を実現すると、2D DASの需要が減少するか、少なくともレイテンシーが減少します。また、Plasmaが広く使用される場合、需要はさらに減少します。DASは分散ブロック構築プロトコルとメカニズムにも課題を提起しています。DASは理論的には分散再構築に適していますが、実際にはパケットインクルージョンリストの提案とその周囲のフォーク選択メカニズムと組み合わせる必要があります。

データ圧縮

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

Rollup 中のすべての取引は大量のオンチェーンデータスペースを使用します：ERC20 の転送には約180バイトが必要です。理想的なデータ可用性サンプリングがあっても、これはLayerプロトコルの拡張性を制限します。各スロット16 MB、私たちは得ます：01928374656574839201

16000000 / 12 / 180 = 7407 TPS

もし分子の問題だけでなく分母の問題も解決し、それによってそれぞれのRollup内の取引がより少ないバイト数でオンチェーンに配置されるようになったら、どうなるでしょうか？

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

私の見解では、最も適切な説明は2年前のこの図です：

ゼロバイト圧縮中に、長いゼロバイトシーケンスごとに2バイトを使用して、ゼロバイトがいくつあるかを示します。さらに、私たちは取引の特定の属性を利用しました：

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

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

取引値のカスタムシリアル化-多くの取引値は桁数が少なく、例えば、0.25 ETH は 250,000,000,000,000,000 ウェイとして表されます。最大基本手数料と優先手数料も同様です。したがって、多くの通貨値を表すために、カスタムの10進浮動小数点形式を使用できます。

既存の研究との関連はありますか？

1.sequence.xyz を探索します。 2. L2コールデータ最適化契約: 3. 有効性の証明に基づくロールアップ（またはZKロールアップとも呼ばれる）は、トランザクションではなく、状態の差異に基づいてリリースされます： 4. BLSウォレット - ERC-4337によるBLSアグリゲーション:

何をする必要があり、どのようなバランスが必要ですか？

次に行う主なことは、上記の計画を実際に実現することです。主なバランスの取れる点には、次のものが含まれます：

1、BLS署名に切り替えるには多大な努力が必要であり、信頼できるハードウェアチップとの互換性がドロップする可能性があります。代わりに、他の署名スキームであるZK-SNARKのパッケージ化を使用することができます。

2、ダイナミックな圧縮（例えば、ポインタを使ってアドレスを置き換える）は、クライアントコードを複雑にする。

3、状態の違いをトランザクションではなくオンチェーンに公開すると、アウディタビリティが低下し、多くのソフトウェア（例えばブロックチェーンエクスプローラー）の動作が不可能になります。

他のロードマップの部分との対話方法は？

ERC-4337を採用し、一部をL2 EVMに統合することで、アグリゲーション技術の展開を大幅に高速化することができます。ERC-4337の一部をL1に配置することで、L2上での展開をより速くすることができます。

一般化プラズマ

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

16 MB のブロブとデータの圧縮を使用しても、58,000 TPS では消費者の支払い、分散化されたソーシャル、または他の高帯域幅領域の要件を完全に満たすことはできません。特にプライバシーの要素を考慮し始めると、これは可用性が3-8倍低下する可能性があります。高い取引量と低い価値のアプリケーションシナリオでは、現在の選択肢の1つはValidiumを使用することです。これはデータをオフチェーンに保存し、興味深いセキュリティモデルを採用しています：オペレーターはユーザーの資金を盗むことはできませんが、一時的または永久的にすべてのユーザーの資金を凍結することができます。しかし、私たちはより良いことができます。

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

Plasmaは、オペレータがブロックをオフチェーンに公開し、これらのブロックのMerkleルートをオンチェーンに配置するスケーリングソリューションであり（Rollupとは異なり、Rollupは完全なブロックをオンチェーンに配置します）、オペレータは各ブロックに対して、各ユーザーに対して、そのユーザーの資産に何が起こったか、または何も起こらなかったかを証明するMerkleブランチを送信します。ユーザーは、Merkleブランチを提供することで、自分の資産を引き出すことができます。重要なのは、このブランチが常に最新の状態を根とする必要はないことです。したがって、データの可用性に問題がある場合でも、ユーザーは利用可能な最新の状態を引き出すことで資産を回復することができます。ユーザーが無効なブランチ（たとえば、彼らが他の人に送信した資産を引き出すか、またはオペレータが自分で資産を作成する）を提出した場合、オンチェーンのチャレンジメカニズムを使用して資産の権利確定を判断することができます。

Plasma Cashチェーンの図。コインiを使ったトランザクションは、ツリーのi番目の位置に配置されます。この例では、以前のすべてのツリーが有効であることを前提としています。私たちは現在、イブがトークン1を持っていること、デビッドがトークン4を持っていること、ジョージがトークン6を持っていることを知っています。

初期のPlasmaバージョンは支払いユースケースのみを処理でき、さらなる普及が困難でした。ただし、すべてのルートにSNARKを使用するように要求すると、Plasmaははるかに強力になります。すべてのチャレンジゲームは大幅に簡素化され、オペレーターの不正行為の可能性が排除されます。同時に、新しい経路が開かれ、Plasmaテクノロジーがより広範な資産カテゴリに拡張されることが可能になります。最後に、オペレーターが不正を行わない場合、ユーザーは即座に資金を引き出すことができ、1週間のチャレンジ期間を待つ必要はありません。

EVM Plasma チェーンを作る方法の一つ（唯一の方法ではありません）：ZK-SNARK を使用して並列の UTXO ツリーを構築し、このツリーは EVM の残高変化を反映し、異なる時点の「同一トークン」のユニークなマッピングを定義します。その後、この上に Plasma 構造を構築することができます。

重要なポイントは、Plasmaシステムは完璧である必要がないということです。資産のサブセット（たとえば、過去1週間に移動していないトークンに限定される場合でも）、現在の超スケーラブルEVM（つまり、Validium）の状況を大幅に改善できます。

もう1つのタイプの構造は、Plasma/Rollupのハイブリッドであり、Intmaxなどの例が挙げられます。これらの構造は、各ユーザーのごく少量のデータ（例：5バイト）をオンチェーンに配置することで、PlasmaとRollupの間の特定の特性を得ることができます。Intmaxの場合、16MBの容量でも理論上は約16,000,000 / 12 / 5 = 266,667 TPSに制限されますが、非常に高いスケーラビリティとプライバシーを実現することができます。

現在の研究に関連するリンクは何ですか？

1. オリジナルプラズマ論文：
2. プラズマキャッシュ：
3. プラズマキャッシュフロー： 4.イントマックス(2023年):

まだ何をすべきですか？どのようなジレンマがありますか？

残りの主なタスクは、Plasmaシステムを実際の製品に組み込むことです。前述のように、PlasmaとValidiumは単なるこのかそのの選択肢ではありません: 任意のValidiumは、その脱退メカニズムにPlasmaの特性を組み込むことで、少なくともある程度安全性を向上させることができます。研究の焦点は、EVMが最適な特性を獲得すること（信頼要件、L1ガスコストの最悪の場合、およびDoS攻撃への耐性などを考慮）と、代替特定のアプリケーション構造です。さらに、Rollupに比べて、Plasmaの概念上の複雑さが高く、これを直接的に解決するために、研究とより良い汎用フレームワークの構築が必要です。

Plasmaを使用したデザインの主な利点は、それらがよりオペレーターに依存しており、より困難であるということですが、ハイブリッドPlasma/Rollupデザインでは通常この弱点を回避できます。

他のロードマップの部分との対話方法は？

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

成熟した L2 構成証明システム

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

現在、ほとんどのRollupは実際にはトラストレスではありません。セキュリティ委員会が存在し、（楽観的または有効性）プルーフシステムの動作をオーバーライドする能力を持っています。一部の場合、プルーフシステムはまったく動作せず、または動作しても「助言」機能のみを持っています。最も先進的なRollupには、（i）Fuelなどのアプリケーション固有のトラストレスRollup、および（ii）OptimismとArbitrumが含まれます。これらはEVM Rollupの「第一段階」と呼ばれるトラストレスの一部のマイルストーンを実現した、本文作成時点でのものです。Rollupがさらなる進展を遂げられない理由は、コードにバグが存在することに対する懸念です。信頼できるRollupが必要なので、この問題に直面し、解決しなければなりません。

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

まず、この記事で最初に紹介された「stage」システムを振り返ってみましょう。

段階0：ユーザーはノードを実行し、チェーンを同期できる必要があります。検証が完全に信頼できる/集中的である場合も問題ありません。

ステージ1：信頼しない（トラストレスな）証明システムが必要であり、有効なトランザクションのみが受け入れられることを保証します。セキュリティ委員会による証明システムの覆すことが許可されますが、75％の閾値投票が必要です。さらに、委員会のクオーラムブロッキングの一部（つまり26％以上）は、Rollupの主要企業の外にある必要があります。より弱いアップグレードメカニズム（たとえばDAO）を使用することが許可されますが、それには十分なレイテンシーが必要であり、悪意のあるアップグレードが承認された場合、ユーザーは資金がオンラインになる前に資金を撤回できます。

段階2：信頼を必要としない証明システムが必要であり、有効なトランザクションのみが受け入れられることを保証する必要があります。セキュリティ委員会は、コード内に証明可能なエラーが存在する場合にのみ介入を許可し、例えば、2つの冗長な証明システムが互いに一致しない場合、または1つの証明システムが同じブロックの2つの異なる後の post-state ルートを受け入れる場合（または十分に長い時間が経過した後に何も受け入れない場合、例えば1週間）。アップグレードメカニズムを使用することができますが、レイテンシーが非常に長くなければなりません。

私たちの目標は第2段階に到達することです。第2段階に到達する主な課題は、十分な信頼を得てシステムが実際に信頼に値することを証明することです。これを実行するためには、主に2つの方法があります：

1. 形式的認証：現代数学とコンピューティング技術を使用して（楽観的および有効性）検証システムが EVM 仕様に合致するブロックのみを受け入れることを証明することができます。これらの技術は数十年前から存在していますが、最近の進歩（Lean 4など）により、より実用的になりました。AIによる補助的な検証の進歩により、この傾向がさらに加速される可能性があります。
2. マルチプルーフ（Multi-provers）：複数のプルーフシステムを作成し、これらのプルーフシステムとセキュリティコミュニティ（または信頼仮定を持つ他のツール、例えばTEE）に資金を投入します。プルーフシステムが同意した場合、セキュリティコミュニティには権限はありません。プルーフシステムが同意しない場合、セキュリティコミュニティはそのうちの1つを選択するしかありません。セキュリティコミュニティは独自の回答を一方的に押し付けることはできません。

複数のプルーフオブステークを組み合わせたプログラム図には、楽観的なプルーフシステム、有効性の証明システム、およびセキュリティ委員会が含まれています。

既存の研究との関連はありますか？

1. EVM Kセマンティクス（2017年の形式的検証作業）：
2. 多重証明のアイデアに関するプレゼンテーション(2022):
3. Taiko プランでは、マルチプルプルーフを使用します：

まだ何をすべきですか？どのようなジレンマがありますか？

形式的認証にとって、作業量は非常に多いです。私たちはEVMの全体的なSNARKプルーバーの正式な検証版を作成する必要があります。これは非常に複雑なプロジェクトですが、既に開始しています。このタスクを大幅に簡略化するためのトリックがあります：最小限の仮想マシン（たとえばRISC-VまたはCairoなど）の形式的認証済みのSNARKプルーバーを作成し、その後、その最小限の仮想マシン内でEVMを実装することができます（および他のETH仮想マシンの仕様との等価性を形式化的に証明する）。

多重証明に関する場合、まだ2つの主要なパートが完了していません。まず、少なくとも2つの異なる証明システムに対してそれぞれがかなり安全であり、かつそれらに問題が発生した場合には異なり、かつ関連性がないことを確実にするために、信頼を置く必要があります（それらが同時に問題が発生しないように）。次に、マージ証明システムの基本ロジックに非常に高い信頼を置く必要があります。この部分のコードははるかに少なくなければなりません。それを非常に小さくするための方法がいくつかありますが、各証明システムを代表する契約者として機能する安全なマルチシグ（Safe multisig）契約に資金を保管するだけで済むものもありますが、これにはオンチェーンのガスコストがかかります。効率と安全性の間でバランスを見つける必要があります。

他のロードマップの部分との対話方法は？

活動をL2に移動すると、L1上のMEV圧力が緩和されます。

L2 インターオペラビリティの向上

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

現在のL2エコシステムが直面している主要な課題の1つは、ユーザーがそこでナビゲートするのが難しいことです。さらに、最も簡単な方法はしばしば信頼の前提を再導入します: 中央集権化されたクロスチェーンインタラクション、RPCクライアントなどです。L2エコシステムを使用する感覚を、まるで統一されたイーサリアムブロックチェーンエコシステムを使用しているかのようにする必要があります。

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

L2間の相互運用性の改善には、多くの種類があります。理論的には、Rollupを中心としたETH坊と実行シャーディングL1は同じものです。しかし、現在のETH坊L2エコシステムは、理想的な状態にはまだ遠く、以下のような問題があります：

1、特定のチェーンのアドレス：アドレスにはチェーンの情報（L1、Optimism、Arbitrumなど）を含める必要があります。これが実現されると、アドレスを「送信」フィールドに簡単に入れることで、L2間の送信プロセスを実現することができます。この場合、ウォレットはバックグラウンドで送信方法（クロスチェーンインタラクションプロトコルの使用を含む）を自動的に処理することができます。

2、特定のチェーンの支払いリクエスト：「チェーンZで私にX個のYタイプの代を送ってください」という形式のメッセージを簡単かつ標準化して作成できる必要があります。主な2つのアプリケーションシナリオがあります：（i）個人間の支払いや個人と商業サービスの支払い；（ii）DAppsが資金を要求する。

3、クロスチェーンインタラクション兑换和 ガス 支払い：クロスチェーンインタラクション操作を表現するために標準化されたオープンなプロトコルが必要です。「私は Arbitrum 上で私に 0.9999 イーサを送信する人に 1 イーサを送ります（Optimism 上で）」、「私はこの取引を含む Arbitrum 上の人に 0.0001 イーサを送ります（Optimism 上で）」。ERC-7683 は前者の試みであり、RIP-7755 は後者の試みですが、これらの適用範囲は特定のユースケースよりも広いです。

4、ライトクライアント：ユーザーは、単にRPCプロバイダに依存するのではなく、実際に彼らが対話しているチェーンを検証できる必要があります。a16z cryptoのHeliosはこれを実現できます（ETH本体に対して）。ただし、この信頼性をL2に拡張する必要があります。ERC-3668（CCIP-read）は、この目標を達成するための戦略の一つです。

ライトクライアントは、Ethereumヘッダーチェーンのビューをどのように更新しますか。ヘッダーチェーンを持っていると、Merkle証明を使用して任意の状態オブジェクトを検証することができます。正しいL1の状態オブジェクトを持っている場合、Merkle証明（事前確認をチェックしたい場合は署名も使用できます）を使用して、L2上の任意の状態オブジェクトを検証することができます。Heliosは前者を実現しています。後者への拡張は標準化の課題です。

1、Keystoreウォレット：現在、あなたがあなたのスマートコントラクトウォレットを制御する秘密鍵を更新したい場合、あなたはそのウォレットが存在するすべてのNチェーンで更新する必要があります。Keystoreウォレットは、秘密鍵が1つの場所にしか存在しない（L1上にあるか、将来的にはL2上にある）技術であり、ウォレットのコピーを持つすべてのL2が秘密鍵を読み取ることができます。これは更新が1回だけで済むことを意味します。効率を上げるために、Keystoreウォレットは、L2がL1上の情報を無償で読み取るための標準化された方法を必要とします。これには、L1SLOADとREMOTESTATICCALLの2つの提案があります。

キーストアウォレットの仕組み

2、より積極的な「共有トークンブリッジ」の考え方：L2がすべて有効性の証明のRollupであり、それぞれのスロットがETHに提出される世界を想像してみてください。このような世界でも、L2の資産をネイティブの状態で別のL2に移動するには、引き出しと預け入れが必要であり、これには多額のL1ガス料が必要です。この問題を解決する方法の1つは、共有のシンプルなRollupを作成し、各種類のトークンがどのL2が所有し、それぞれがどれだけの残高を持っているかを維持し、それらの残高を任意のL2から発信される一連のクロスL2送信操作によって一括更新できるようにすることです。これにより、クロスL2送金がL1ガス料を支払う必要がなくなり、ERC-7683などの流動性プロバイダーに基づく技術を使用する必要もありません。

3、同期的な組み合わせ：特定のL2とL1、または複数のL2間で同期呼び出しが発生することを許可します。これにより、分散型金融プロトコルの財務効率が向上します。前者は、L2を横断する調整なしに実現できますが、後者はソートの共有が必要です。Rollupベースの技術は、これらすべての技術に自動的に適用されます。

既存の研究との関連はありますか？

**链特定アドレス：ERC-3770：

**ERC-7683:

**RIP-7755:

**Scroll keystore ウォレットデザインスタイル：

**ヘリオス：

**ERC-3668（時にはCCIPリーダとも呼ばれる）：

**Justin Drake氏の「(共有)事前確認に基づく」という提案:

**L1SLOAD (RIP-7728):

**楽観主義のREMOTESTATICCALL:

AggLayer、共有トークンブリッジを含むアイデア：

まだ何をすべきですか？どのようなジレンマがありますか？

多くの例は、標準化のタイミングとどのレベルを標準化すべきかという標準化のジレンマに直面しています。早すぎる標準化は、より悪い解決策を確立する可能性があります。逆に、遅すぎる標準化は不要な断片化を引き起こす可能性があります。一部の場合、弱いが実装しやすい短期的な解決策と、数年かかるが「最終的に正しい」長期的な解決策の両方が存在します。

これらのタスクは技術的な問題にとどまらず、むしろ（おそらく主に）社会的な問題であり、L2とウォレット、さらにL1の協力が必要です。

他のロードマップの部分との対話方法は？

これらの提案のほとんどは「より上位の」構造であり、そのためL1レベルの考慮はほとんど影響を受けません。共有ソートは例外であり、最大抽出値（MEV）に重要な影響を与えます。

L1 でのスケーリング実行

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

L2が非常に拡張可能で成功する一方で、L1が非常に少ない取引量しか処理できない場合、ETH坊は多くのリスクに直面する可能性があります:

1、ETH資産の経済状況がより不安定になることで、ネットワークの長期的な安全性にも影響を与えることがあります。

2. 多くのL2は、L1で高度に発展した金融エコシステムとの緊密なつながりによって恩恵を受けています。このエコシステムが大幅に弱体化すると、L2になる（独立したL1になるのではなく）動機が弱まる可能性があります。

3、L2 は L1 と完全に同じセキュリティ保証を実現するには、まだまだ時間がかかります。

4、もしL2が失敗した場合（たとえば、悪意のある運営者の行動や消失のために）、ユーザーはそれでもL1を介して彼らの資産を回復する必要があります。したがって、L1は十分に強力であり、少なくとも時々L2の高度に複雑で混乱した最終処理を実際に処理できる必要があります。

これらの理由から、L1自体を拡張し続け、ますます多くのユースケースを収容できるようにすることは非常に価値があります。

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

最も簡単な拡張方法は、Gasの上限を直接増やすことです。しかし、これはL1を中心化に傾斜させる可能性があり、ETHブロックチェーンL1の信頼性という重要な特性を弱める可能性があります。 Gasの上限をどの程度まで単純に増やすことが持続可能かについては、現在も議論があり、また、より大きなブロックの検証を容易にするためにどのような他の技術が実装されるかによっても異なります（例：過去の期限切れ、ステートレス、L1 EVMの有効性の証明）。もう一つ改善が必要な重要な点は、ETHブロックチェーンクライアントソフトウェアの効率です。現在の効率は5年前よりもはるかに向上しています。効果的なL1 Gas上限の増加戦略には、これらの検証技術の開発を加速することが含まれます。

1. EOF：新しいEVMバイトコード形式であり、静的解析により友好的であり、より高速な実装が可能です。これらの効率向上を考慮すると、EOFバイトコードはより低いガス料金を得ることができます。
2. 多次元ガス価格設定：計算、データ、およびストレージにそれぞれ異なる基本料金と制限を設定し、ETH坊L1の平均容量を増やすことができます（最大容量を増やさずに新しいセキュリティリスクを回避します）。
3. 特定のオペコードと事前にコンパイルされたガスコストをドロップ - 歴史的に、サービス拒否攻撃を回避するために、いくつかの価格設定が低すぎる操作のガスコストを何度か増やしてきました。もう少しできることは、高すぎる価格設定のオペコードのガス費用をドロップすることです。たとえば、加算は乗算よりもはるかに安いですが、現在のADDおよびMULオペコードのコストは同じです。ADDのコストをドロップしたり、PUSHなどのよりシンプルなオペコードのコストをさらに低くすることさえできます。全体的にこの点をさらに最適化することができます。
4. EVM-MAXおよびSIMD：EVM-MAXは、EVMの独立したモジュールとしてより効率的なネイティブの大数モジュラ演算を可能にする提案です。 EVM-MAXが計算した値は、他のEVM-MAXオペコードからのみアクセスできるように意図的にエクスポートされない限り、アクセスできません。これにより、これらの値を効率的に格納するためのより大きなスペースが利用できるようになります。SIMD（シングルインストラクションマルチデータ）は、値の配列に対して同じ命令を効率的に実行することを可能にする提案です。両方を組み合わせると、EVMの隣にパワフルなコプロセッサを作成し、暗号化操作をより効率的に実行することができます。これはプライバシープロトコルやL2保護システムに特に有用であり、L1とL2のスケーリングに役立ちます。

これらの改善点については、今後のSplurge記事で詳しく取り上げます。

最後、第三の戦略はネイティブRollups（またはenrolledロールアップ）です：本質的には、多くの並行して実行されるEVMコピーを作成し、Rollupが提供できるモデルに等しいものを生み出すが、プロトコルによりネイティブに統合されています。

既存の研究との関連はありますか？

1. PolynyaのイーサリアムL1スケーリングロードマップ: 2.多次元ガス価格:
2. EIP-7706:
3. EOF(環境終了):
4. EVM-MAX:
5. SIMD(シムド):
6. Native ロールアップ:
7. Max Resnick が L1 拡張の価値についてのインタビュー中に
8. Justin DrakeがSNARKとネイティブRollupsを使用してスケーリングについて話す：

何をする必要があり、どのようなバランスが必要ですか？

L1拡張には、単独または並行して行うことができる3つの戦略があります:

1. L1をより検証しやすくするために、改善された技術（例：クライアントコード、ステートレスクライアント、過去の有効期限）を採用し、Gas制限を引き上げます。
2. 特定操作のコストを下げ、最悪の状況リスクを増やさずに平均容量を増やす；
3. ネイティブ・ロールアップ(EVMのN個の並列コピーを作成)

これらの異なる技術を理解すると、それぞれに異なるトレードオフがあることがわかります。たとえば、ネイティブRollupsは、組み合わせの面で通常のRollupsと同じような弱点が多数存在します。それは、1つのトランザクションで複数のRollupを横断して操作を同期させることはできないことです。L1（またはL2）の同じコントラクト内で実行できるようになるものと同じように。Gas上限を上げることは、L1の検証を単純化することで実現できる他の利点、例えば検証ノードのユーザーの割合を増やしたり、soloステーキング者の数を増やしたりすることを弱める可能性があります。実装方法によっては、EVM（イーサリアム仮想マシン）内の特定の操作をより安価にすることが、EVM全体の複雑さを増すことがあります。

任意のL1スケーリングロードマップには、重要な問題があります：L1とL2の最終的なビジョンはそれぞれ何ですか？明らかに、すべてのコンテンツをL1に配置することはばかげています：潜在的なアプリケーションシナリオでは、数十万トランザクションを秒ごとに処理する可能性がありますが、これはL1の検証が不可能になるでしょう（ネイティブなロールアップ方式を採用しない限り）。ただし、私たちはETHの分散化を大きく損なうことなく、Gasの上限を10倍に引き上げるなどのガイドラインが必要です。

L1とL2の間の分業の一つの見方

他のロードマップの部分との対話方法は？

L1へのより多くのユーザーの導入は、スケーリングの向上だけでなく、L1の他の側面の改善も意味します。これにより、より多くのMEVがL1に残ることになります（L2の問題になるだけでなく）。したがって、MEVの処理ニーズを明確にすることがますます重要になります。これにより、L1上の高速スロットの価値が大幅に向上します。同時に、これはL1（the Verge）の順調な検証にも大いに依存しています。

(推奨読書: ヴィタリックの新しい記事:イーサリアムの可能な未来、マージ)