イーサリアムの可能な未来、パート2: ザ・サージ
最初、Ethereumにはロードマップで2つのスケーリング戦略がありました。1つは（例：この早い論文2015年に発表されたもう一つのアイデアは「シャーディング」でした：チェーン内のすべての取引を検証し保存する代わりに、各ノードは取引のほんの一部を検証し保存するだけでした。これは他のどんなピア・ツー・ピア・ネットワーク（例：BitTorrent）も同じように機能するので、ブロックチェーンも同じように機能させることができるはずです。もう一つはレイヤー2プロトコルでした：これは、Ethereumの上に位置し、そのセキュリティを十分に活用しながら、ほとんどのデータと計算をメインチェーンから外に保持することができるネットワークでした。"レイヤー2プロトコル"とはステートチャネル2015年、プラズマ2017年に、そしてロールアップ2019年には、Rollupsはステートチャネルやプラズマよりも強力ですが、大量のオンチェーンデータ帯域幅が必要です。幸いなことに、2019年までには、シャーディングの研究によって問題が解決されていました。スケールでの「データの可用性」の検証問題。その結果、2つの道は交わり、私たちはロールアップ中心のロードマップ今日もイーサリアムのスケーリング戦略として続いています。
The Surge, 2023ロードマップエディション。
ロールアップ中心のロードマップは、労働の単純な分割を提案しています：Ethereum L1は堅牢で分散型の基本層に焦点を当て、一方L2はエコシステムのスケーリングを支援する役割を果たします。これは、社会の至る所で繰り返されるパターンです：裁判所（L1）は超高速で効率的である必要はありません。契約と財産権を守るためにあり、それを基にするのは起業家（L2）の役割です。頑丈ベースレイヤーそして、人類を（比喩的であり、文字通りの）火星に連れて行く。
今年、ロールアップ中心のロードマップは重要な成功を収めています：Ethereum L1のデータ帯域が大幅に増加しましたEIP-4844 blobs, そして複数のEVMロールアップが今ステージ 1. とても シャーディングの異質性と多元性の実装, それぞれの L2 が独自のルールとロジックを持つ「シャード」として機能するロールアップは、現実のものとなりました。しかし、この道を進むことには独自の課題があることが分かっています。そして、今私たちの課題は、ロールアップ中心のロードマップを完成させ、これらの問題を解決することであり、同時に、イーサリアム L1 を特別なものにする頑丈さと分散性を保持することです。
サージ：主な目標
- L1+L2での100,000以上のTPS
- L1の分散化と堅牢性を維持する
- 少なくとも一部のL2は、イーサリアムのコアプロパティ（信頼性、オープン性、検閲耐性）を完全に受け継いでいます
- L2間の最大の相互運用性。イーサリアムは34つの異なるブロックチェーンではなく、1つのエコシステムのように感じるはずです。
この章で
余談: スケーラビリティの三すくみ
スケーラビリティの三難問題はアイデアでした2017年に導入されました, それは、ブロックチェーンの3つの特性の間に緊張があると主張しています: 分散化（より具体的には、ノードを実行するコストが低いこと）、スケーラビリティ（より具体的には、処理されるトランザクションの数が多いこと）、およびセキュリティ（より具体的には、攻撃者が全ネットワークの大部分を破損する必要があること、単一のトランザクションを失敗させるために）。
特にトリレンマは定理ではなく、トリレンマを紹介した投稿には数学的な証明が付いていませんでした。ヒューリスティックな数学的議論を示しました。分散型フレンドリーノード（例：消費者向けノートパソコン）が秒間Nトランザクションを検証できる場合、およびk*Nトランザクションを処理するチェーンがある場合、次のいずれかが成り立ちます。それぞれのトランザクションが1/kのノードにしか見られない、これは攻撃者がわずかなノードを破損するだけで悪いトランザクションを通過させる必要があることを意味します。または、あなたのノードは強力であり、あなたのチェーンは分散されていない。投稿の目的は、トリレンマを破ることが不可能であることを示すことではありませんでした。むしろ、トリレンマを破ることは難しいことを示すことでした。その議論が暗示する枠組みの外側の考え方が何らかの方法で必要だということを示すことでした。
長年、いくつかの高性能チェーンは、基本的なアーキテクチャレベルで賢明なことを何もせずにトライレンマを解決すると主張することが一般的でした。通常、ソフトウェアエンジニアリングのトリックを使用してノードを最適化します。これは常に誤解を招き、そのようなチェーンでのノードの実行は常にEthereumよりもはるかに困難になります。この投稿多くの微妙な点について触れることで、なぜそうなのか（つまり、なぜL1クライアントソフトウェアエンジニアリングだけではイーサリアム自体をスケーリングすることができないのか）
しかし、データ可用性サンプリングとSNARKの組み合わせは、トリレンマを解決します:クライアントは、そのデータのごく一部しかダウンロードせず、はるかに少ない量の計算を実行しながら、ある程度の量のデータが利用可能であり、いくつかの計算ステップが正しく実行されたことを検証できます。SNARKはトラストレスです。データ可用性サンプリングには微妙な違いがありますfew-of-N 信頼モデル, しかし、それは非拡張可能なチェーンが持つ基本的な特性を保持しており、つまり、51%攻撃でも悪いブロックをネットワークに受け入れさせることはできないという点です。
トリレンマを解決する別の方法は、Plasmaアーキテクチャを使用することであり、データの利用可能性を監視する責任をユーザーにインセンティブ互換な方法で押し付ける巧妙な技術を使用しています。2017年から2019年にかけて、計算をスケーリングするために持っていたものが詐欺の証明だけだったとき、Plasmaは安全に行うことができることに非常に制限されていましたが、SNARKsの主流化によりPlasmaアーキテクチャは非常に制限されていました。はるかに実現可能これまで以上に幅広い用途に対応しています。
データの利用可能性サンプリングにおけるさらなる進展
我々は何の問題を解決しているのでしょうか？
2024年3月13日時点で、Dencun upgrade実際には、Ethereumブロックチェーンは、12秒間のスロットあたり約125kBの「ブロブ」が3つあり、またはデータ可用性帯域幅のスロットあたり約375kBあります。取引データが直接オンチェーンで公開されると仮定すると、ERC20転送は約180バイトであり、したがってEthereum上のロールアップの最大TPSは次のとおりです:
375000 / 12 / 180 = 173.6 TPS
イーサリアムのcalldata（理論上の最大値：1スロットあたり30百万ガス/1バイトあたり16ガス=1,875,000バイト/スロット）を追加すると、これは607TPSになります。PeerDASでは、blobの数を8〜16に増やす予定で、これによりcalldataでは463〜926 TPSが得られます。
これはイーサリアムL1よりも大幅に増加していますが、それだけでは不十分です。私たちははるかにスケーラビリティを求めています。私たちの中期目標はスロットあたり16 MBで、これはロールアップデータ圧縮の改善と組み合わせると、約58,000 TPSを実現します。
それは何ですか、そしてどのように機能しますか？
PeerDASは、「1Dサンプリング」の比較的単純な実装です。 Ethereumの各ブロブは、253ビットの素体上の度4096の多項式です。 多項式の「シェア」をブロードキャストし、各シェアは、合計8192の座標から取られた隣接する16座標での16評価から構成されています。 現在提案されているパラメーターでは、8192の評価のうちの4096つ（現在の提案されているパラメーターでは、128つの可能なサンプルのうちの64つ）でブロブを回復することができます。
PeerDASは、各クライアントがいくつかのサブネットでリスンすることによって機能します。第iサブネットは、任意のブロブのi番目のサンプルをブロードキャストし、さらに、必要な他のサブネットのブロブを要求するために、グローバルP2Pネットワーク内のピアに尋ねます（異なるサブネットをリスンしている可能性があります）。より保守的なバージョン、サブネットDAS, 追加のピアに尋ねる層を持たずに、サブネットメカニズムのみを使用します。現在の提案は、ステークプルーフに参加するノードがSubnetDASを使用し、他のノード（つまり「クライアント」）がPeerDASを使用することです。
理論的には、1Dサンプリングをかなりスケーリングすることができます。ブロブ数の最大値を256に増やすと（つまり、ターゲットを128にすると）、データ可用性サンプリングによる各ノードのコストはわずか16サンプルになります。16 MBのターゲットに到達します。128 blobs1つのブロブあたり512バイト=1つのスロットあたり1MBのデータ帯域幅。これはわずかに容認範囲内です：可能ですが、帯域幅に制約のあるクライアントはサンプリングできません。ブロブの数を減らし、ブロブのサイズを増やすことで、これをある程度最適化できますが、これにより再構築がより高価になります。
そして最終的に私たちはさらに進み、そして2Dサンプリング、ブロブ内だけでなく、ブロブ間でもランダムサンプリングによって機能する。 KZGコミットメントの線形特性は、ブロック内のブロブのセットを新しい「仮想ブロブ」のリストで「拡張」するために使用され、同じ情報を冗長に符号化する。
2Dサンプリング。ソース: a16z crypto
重要なのは、コミットメントの拡張を計算する際にはブロブが必要ないため、このスキームは基本的に分散型ブロック構築に対して友好的です。実際にブロックを構築しているノードは、ブロブ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
- 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
- フランチェスコによるPeerDASに関するプレゼンテーション: https://www.youtube.com/watch?v=WOdpO1tH_Us
- EIP-7594: https://eips.イーサリアム.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から量子耐性のある、信頼できるセットアップフリーの代替手段に移行したいと考えています。現在、分散型ブロック構築に対応する候補がわかっていません。再帰的なSTARKsを使用して行と列の再構築のための妥当性の証明を生成する「総当たり」テクニックでさえ、十分ではありません。なぜなら、技術的にはSTARKがO(log(n) * log(log(n))のハッシュサイズであるためです。STIR), 実際には、STARKはほぼ全体のブロブと同じくらい大きいです。
私が長期的に見ている現実的な道は次のとおりです:
- 理想的な2D DASを実装します
- 1D DASにこだわり、サンプリング帯域幅の効率を犠牲にし、シンプルさと堅牢性のためにデータ上限を低く抑える
- （ハードピボット）DAを放棄し、プラズマを第2層アーキテクチャの主要なものとして完全に受け入れることに焦点を当てています
これらはトレードオフスペクトルを通して表示できます。
L1を直接スケーリングすることに決定した場合でも、この選択肢が存在することに注意してください。なぜなら、L1が多くのTPSを処理する必要がある場合、L1ブロックは非常に大きくなり、クライアントはそれらが正しいことを効率的に検証したいと思うため、L1でロールアップ（ZK-EVMとDASの技術を使用することになるからです。
他の部分とどのように連携しますか？
2D DASの必要性は、データ圧縮（以下参照）が実装されていれば多少軽減されるか、少なくとも遅延されるか、また、Plasmaが広く使用されている場合はさらに軽減されます。DASは、分散型ブロック構築プロトコルやメカニズムにも課題を提起します。DASは理論的に分散再構築に適していますが、これを実践で組み合わせる必要があります。包含リスト提案とそれに囲まれたフォーク選択メカニズム。
データ圧縮
私たちは何の問題を解決していますか？
ロールアップ内の各トランザクションは、オンチェーンで大量のデータスペースを使用します：ERC20の転送には約180バイトかかります。理想的なデータ可用性サンプリングでも、これによりレイヤー2プロトコルのスケーラビリティに上限が設定されます。1つのスロットあたり16 MBの場合、以下を得ます。
16000000 / 12 / 180 = 7407 TPS
分母に取り組むだけでなく、ロールアップ内の各トランザクションをより少ないバイトでオンチェーンに取り組むことができたらどうでしょうか？
それは何ですか？ それはどのように機能しますか？
私の意見では、最良の説明はこの図2年前から:
最も単純な利益はゼロバイト圧縮だけです。ゼロバイトの長いシーケンスを、ゼロバイトの数を表す2バイトで置き換えることです。さらに進むために、取引の特定の特性を活用します。
- 署名の集約 - ECDSA署名からBLS署名に切り替えますが、BLS署名は、多くの署名を1つの署名に組み合わせて、元のすべての署名の有効性を証明することができるという特性を持っています。L1 では、集計を使用しても検証の計算コストが高くなるため、これは考慮されませんが、L2 のようなデータが少ない環境では、間違いなく理にかなっています。の集計機能ERC-4337これを実装するための1つの方法を示しています。
- アドレスをポインターで置き換える- 以前にアドレスが使用されていた場合、20バイトのアドレスを履歴の場所を指す4バイトのポインターで置き換えることができます。これは最大の利益を得るために必要ですが、実装するのに努力が必要です。なぜなら、（少なくとも一部の）ブロックチェーンの履歴が実質的に状態の一部になる必要があるからです。
- トランザクション値のカスタムシリアル化 - ほとんどのトランザクション値は非常に少ない桁数を持っており、たとえば、0.25 ETH は 250,000,000,000,000,000 wei として表されます。ガスの最大ベース手数料や優先手数料も同様に機能します。したがって、カスタムの10進浮動小数点形式、または特に一般的な値の辞書を使用して、ほとんどの通貨値を非常にコンパクトに表現することができます。
既存の研究へのリンクは何ですか？
- sequence.xyzからの探査: https://sequence.xyz/blog/compressing-calldataは、シーケンスのブログです
- ScopeLiftからのL2向けのCalldata最適化された契約:https://github.com/ScopeLift/l2-optimizoooors
- 代替戦略 - 有効性証明ベースのロールアップ（ZKロールアップとも呼ばれる）は、取引ではなく状態の差分を投稿します：https://ethresear.ch/t/rollup-diff-compression-application-level-compression-strategies-to-reduce-the-l2-data-footprint-on-l1/9975
- BLSウォレット - ERC-4337を通じたBLS集約の実装:https://github.com/getwax/bls-wallet
何が残っていて、どんなトレードオフがありますか？
実際に上記のスキームを実装することが残されている主要な作業です。主なトレードオフは次のとおりです。
- BLS署名への切り替えにはかなりの労力が必要で、セキュリティを向上させることができる信頼できるハードウェアチップとの互換性が低下します。他の署名方式の周囲にZK-SNARKラッパーを配置することで、これを置き換えることができます。
- 動的圧縮 (アドレスをポインターに置き換えるなど) は、クライアント コードを複雑にします。
- トランザクションではなくチェーンに状態の差分を投稿すると、監査可能性が低下し、多くのソフトウェア（例：ブロックエクスプローラー）が動作しなくなります。
他の部分のロードマップとのやり取りはどのようになりますか？
ERC-4337の採用、そして最終的にL2 EVMの一部を確立することは、集約技術の展開を大幅に促進することができます。 ERC-4337の一部をL1に確立することで、L2上での展開を促進することができます。
一般化プラズマ
私たちはどの問題を解決していますか？
16 MBのブロブやデータ圧縮を使用しても、58,000 TPSであっても、消費者支払い、分散型ソーシャル、その他の高帯域セクターを完全に引き継ぐには必ずしも十分とは限らず、特にプライバシーを考慮し始めると、スケーラビリティが3-8倍に低下する可能性があります。高ボリュームで低価値なアプリケーション向けには、現在、1つの選択肢があります。バリデウム, データをオフチェーンに保持し、オペレーターはユーザーの資金を盗むことはできませんが、彼らは消えることができ、一時的または永久的にすべてのユーザーの資金を凍結することができます。しかし、私たちはより良いことができます。
それは何ですか？ どのように機能しますか？
Plasmaは、オペレーターがオフチェーンでブロックを公開し、それらのブロックのMerkleルートをオンチェーンに配置するスケーリングソリューションであり（ロールアップとは異なり、完全なブロックがオンチェーンに配置される）、オペレーターは各ブロックに対して、ユーザーごとに何が起こったか、または起こらなかったかを証明するMerkleブランチを送信します。ユーザーは、Merkleブランチを提供することで、自分の資産を引き出すことができます。重要なのは、このブランチが最新の状態に根ざしている必要はないことです。そのため、データの可用性が失敗した場合でも、ユーザーは利用可能な最新の状態を引き出すことで、依然として自分の資産を回復することができます。ユーザーが無効なブランチを提出した場合（例：他の誰かに送信済みの資産を退出した、またはオペレーター自体が空気から資産を作成した）、オンチェーンのチャレンジメカニズムが資産が正当に誰に属するかを裁定できます。
Plasma Cashチェーンのダイアグラム。コインiを消費する取引は、木構造のi番目の位置に配置されます。この例では、すべての前の木構造が有効であると仮定すると、Eveが現在コイン1を所有していること、Davidがコイン4を所有していること、Georgeがコイン6を所有していることがわかります。
Plasmaの初期バージョンは支払いのユースケースのみを処理でき、それ以上の一般化ができませんでした。ただし、各ルートをSNARKで検証する必要がある場合、Plasmaははるかに強力になります。各チャレンジゲームは、オペレーターが不正を行う可能性のある経路を大幅に取り除くため、大幅に簡素化されます。新しい経路も開かれ、Plasma技術をより一般的なアセットクラスに拡張することができます。最後に、オペレーターが不正を行わない場合、ユーザーは1週間のチャレンジ期間を待つ必要なく、即座に資金を引き出すことができます。
EVMプラズマチェーンを作成するための1つの方法（唯一の方法ではない）：ZK-SNARKを使用してEVMによって行われた残高の変更を反映する並列UTXOツリーを構築し、「同じコイン」が歴史の異なる時点で何であるかを定義します。その上にPlasma構造を構築することができます。
重要な洞察の1つは、プラズマシステムが完璧である必要はないということです。資産のサブセット(たとえば、過去1週間に動いていないコインだけ)しか保護できない場合でも、バリデウムである超スケーラブルEVMの現状をすでに大幅に改善しています。
もう1つの構築クラスは、ハイブリッドプラズマ/ロールアップ、Intmaxこれらの構築は、ユーザーごとに非常に少量のデータ（例：5バイト）をオンチェーンに配置し、その結果、プラズマとロールアップの中間に位置するプロパティを取得します。 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
何を残すか、そしてどんなトレードオフがありますか？
メインの残りのタスクは、プラズマシステムを本番環境に導入することです。上記のように、「プラズマ vs バリディウム」はバイナリではありません: 任意のバリディウムは、出口メカニズムにプラズマの機能を追加することで、少なくとも少しはその安全性を向上させることができます。研究の一部は、EVMの信頼要件、最悪のケースでのL1ガスコスト、DoSへの脆弱性に関する最適な特性（および代替のアプリケーション固有の構築）を取得することです。また、ロールアップに比べてプラズマの概念的複雑さが直接対処される必要があります。これは、研究とより良い汎用フレームワークの構築の両方を通じて行われます。
Plasmaデザインを使用する際の主なトレードオフは、オペレーターに依存しやすく、「作り込むのが難しい」という点です。ベース「ハイブリッドプラズマ/ロールアップデザインでは、この弱点を回避することができることが多い」と言える。
他の部分とどのようにやり取りしますか？
より効果的なプラズマソリューションがあれば、L1に高性能なデータ可用性機能が必要な圧力が少なくなります。活動をL2に移すことで、L1へのMEV圧力も軽減されます。
L2プルーフシステムの成熟
何の問題を解決していますか？
今日、ほとんどのロールアップは実際にはまだ信頼できません。セキュリティ委員会が（楽観的または有効性に関する）振る舞いを上書きする能力があります。プルーフシステム.場合によっては、プルーフシステムがまったく稼働していないか、稼働していても「アドバイザリー」機能しかありません。最も進んでいるのは、(i)トラストレスなFuelなどのアプリケーション固有のロールアップと、(ii)この記事の執筆時点では、「ステージ1」として知られる部分的なトラストレスのマイルストーンを達成した2つのフルEVMロールアップであるOptimismとArbitrumです。ロールアップが進まない理由は、コードのバグに対する懸念です。トラストレスなロールアップが必要なので、この問題に正面から取り組む必要があります。
それは何であり、どのように機能しますか?
ますは、最初に、元〇〇に導入された「ステージ」システムを振り返ってみましょう。この投稿.より詳細な要件がありますが、要約は次のとおりです。
- ステージ 0: ユーザーがノードを実行し、チェーンを同期できる必要があります。検証が完全に信頼/集中化されていれば問題ありません。
- ステージ1：有効なトランザクションのみが受け入れられることを保証する（信頼できる）証明システムが必要です。証明システムを上書きできるセキュリティ評議会が存在することを許可しますが、75％の閾値投票のみが許可されます。さらに、評議会のクォーラムブロッキング部分（つまり、26％以上）は、ロールアップを構築する主要企業の外にある必要があります。より弱い機能を持つアップグレードメカニズム（例：DAOなど）は許可されますが、悪意のあるアップグレードを承認した場合、ユーザーがオンライン化される前に自分の資金を引き出せるように、十分な遅延が必要です。
- 段階2：有効なトランザクションのみが受け入れられることを保証する（信頼できる）証明システムが存在する必要があります。セキュリティ委員会は、たとえば2つの冗長な証明システムが互いに異なる意見を持つ場合や、1つの証明システムが同じブロックのために2つの異なるポスト状態のルートを受け入れる場合（または十分に長い期間、例えば1週間何も受け入れない場合）など、コードに証明されたバグが発生した場合にのみ介入することが許可されています。アップグレードメカニズムは許可されていますが、非常に長い遅延を持っていなければなりません。
Stage 2に到達することが目標です。Stage 2に到達する上での主な課題は、実際に証明システムが信頼できるという自信を持つことです。これを行う主な方法には2つの大きな方法があります。
- フォーマル検証：最新の数学的および計算手法を使用して、(楽観的または妥当性)証明システムがEVM仕様を満たすブロックのみを受け入れることを証明できます。これらの手法は数十年前から存在していますが、最近の進歩により、リーン 4それらをはるかに実用的にし、AI支援証明の進歩によってこのトレンドをさらに加速させる可能性があります。
- マルチプルーバー:複数のプルーフシステムを作成し、それらのプルーフシステムとセキュリティカウンシル(および/または信頼を前提とするその他のガジェット)との間の2-of-3(またはそれ以上)のマルチシグに資金を投入します。TEEs)です。証明制度が合意すれば、安全保障理事会はいかなる権限も持たない。もし彼らが同意しない場合、安保理はどちらか一方しか選べず、一方的に独自の答えを押し付けることはできない。
楽観的な証明システム、有効性証明システム、セキュリティ評議会を組み合わせたマルチプルーバーのスタイル化された図
既存の研究へのリンクはありますか？
- EVM Kセマンティクス（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証明者の完全に検証されたバージョンを作成する必要があります。これは非常に複雑なプロジェクトですが、Gate.ioの製品名の1つです。私たちはすでに始めています.この作業を大幅に簡素化するトリックが1つあります:最小VMの正式に検証されたSNARK証明者を作ることができます。RISC-Vまたはカイロ、その後、その最小VMでEVMの実装を書き、（他のEVM仕様との同等性を形式的に証明する）。
マルチプルーバーにとって、残っている主な2つの部分があります。まず、少なくとも2つの異なる証明システムについて、個々に安全であり、もし壊れた場合は異なる無関係な理由で壊れるという点について、十分な信頼を得る必要があります（そしてそれらが同時に壊れないようになります）。第二に、証明システムを統合する基礎となるロジックに非常に高い信頼レベルを得る必要があります。これはコードのずっと小さな部分です。非常に小さくする方法があります - 単に資金を保管するだけです。安全なマルチシグコントラクトサインする人は、個々の証明システムを表す契約です - ただし、これにはオンチェーンのガスコストが高いというトレードオフがあります。効率と安全性の間には、適切なバランスが見つけられなければなりません。
他のロードマップの部分とどのように連携しますか？
L2への活動の移行は、L1のMEV圧力を軽減します。
Cross-L2相互運用性の改善
私たちはどんな問題を解決していますか？
現在のL2エコシステムの主要な課題の1つは、ユーザーがナビゲートしにくいということです。さらに、その最も簡単な方法は、しばしば信頼の前提条件を再導入します：中央集権的なブリッジ、RPCクライアントなど。もしL2がイーサリアムの一部であるというアイデアを真剣に受け止めるのであれば、L2エコシステムを使用することが統一されたイーサリアムエコシステムを使用するような感覚になるようにする必要があります。
病的に悪い（そして危険すぎる：私はここでチェーン選択のミスで$100を失いました）クロスL2 UXの例−これはPolymarketの責任ではありませんが、クロスL2の相互運用性はウォレットとEthereumスタンダード（ERC）コミュニティの責任であるべきです。機能が良いEthereumエコシステムでは、L1からL2へのコインの送信、または1つのL2から別のL2へのコインの送信は、同じL1内でコインを送信するのと同じように感じるはずです。
それは何ですか？ そして、それはどのように機能しますか？
クロス-L2相互運用性改善の多くのカテゴリがあります。一般的に、これらを考える方法は、理論上、ロールアップ中心のイーサリアムは、L1実行シャーディングと同じものです, そして、現在のEthereum L2バースが実践上でその理想にどこで欠けているかを尋ねます。 ここにいくつかあります:
- チェーン固有アドレス：チェーン（L1、Optimism、Arbitrumなど）はアドレスの一部であるべきです。これが実装されると、クロスL2送信フローは、アドレスを単に「送信」フィールドに入力するだけで実装することができます。その時点で、ウォレットは（ブリッジングプロトコルを使用することを含めて）バックグラウンドで送信する方法を把握できます。
- 特定チェーンの支払いリクエスト：フォーム“チェーンZ上でタイプYのXトークンを送ってください”のメッセージを簡単かつ標準化することが重要です。これには主に2つの使用ケースがあります：(i) 支払い、個人間または個人対商人サービス、および(ii) dappが資金を要求する場合、たとえば上記のPolymarketの例。
- クロスチェーンスワップとガス支払い：「私はOptimism上で1 ETHを送金して、代わりにArbitrumで私に0.9999 ETHを送金する人」などのクロスチェーン操作を表現するための標準化されたオープンプロトコルが必要です。そして、「私はOptimism上で0.0001 ETHを送金して、このトランザクションをArbitrumに含める人」なども必要です。ERC-7683前者の試みの一つであり、Gate.ioはもう一つの試みです。のRIP-7755後者への1つの試みですが、どちらもこれら特定の用途に限らず、より一般的でもあります。
- ライトクライアント:ユーザーは、RPCプロバイダーを信頼するだけでなく、対話しているチェーンを実際に検証できる必要があります。A16zクリプトのヘリオスこれはイーサリアム自体に対して行われますが、この信頼性をL2にも拡張する必要があります。ERC-3668 (CCIP-read)これを行うための1つの戦略です。
軽量クライアントがイーサリアムヘッダーチェーンのビューを更新する方法。ヘッダーチェーンを取得すると、Merkle証明を使用して任意のステートオブジェクトを検証できます。そして、正しいL1ステートオブジェクトを取得すると、Merkle証明（おそらく署名も含む、事前確認をチェックする場合）を使用して、L2上の任意のステートオブジェクトを検証できます。Heliosは既に前者を行っています。後者への拡張は標準化の課題です。
- キーストアウォレット:現在、スマートコントラクトウォレットを制御するキーを更新する場合は、そのウォレットが存在するすべてのNチェーンで更新する必要があります。キーストアウォレットは、キーを1つの場所(L1、または後でL2)に存在させ、ウォレットのコピーを持つ任意のL2から読み取ることができる手法です。つまり、更新は一度だけ行う必要があります。効率を上げるために、キーストアウォレットでは、L2がコストをかけずにL1を読み取るための標準化された方法を持っている必要があります。これに対する2つの提案は次のとおりですL1SLOADそしてREMOTESTATICCALL.
キーストアウォレットがどのように動作するかを示したスタイライズされた図。
- より過激な「共有トークンブリッジ」のアイデア:すべてのL2が有効性証明ロールアップであり、すべてのスロットをイーサリアムにコミットする世界を想像してみてください。この世界でも、あるL2から別のL2に資産を「ネイティブ」に移動するには、引き出しと預金が必要であり、かなりの量のL1ガスを支払う必要があります。これを解決する方法の 1 つは、共有最小ロールアップを作成することであり、その唯一の機能は、どのタイプのトークンがどの L2 によって所有されているかという残高を維持し、いずれかの L2 によって開始された一連のクロス L2 送信操作によってそれらの残高を一括で更新できるようにすることです。これにより、送金ごとにL1ガスを支払う必要がなく、ERC-7683のような流動性プロバイダーベースの手法を必要とせずに、L2間の送金が可能になります。
- 同期可能性：特定の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
- スクロールキーストアウォレットデザイン：@haichen/keystore"">https://hackmd.io/@haichen/keystore
- ヘリオス：https://github.com/a16z/helios
- ERC-3668(CCIP読み取りと呼ばれることもあります):https://eips.ethereum.org/EIPS/eip-3668
- ジャスティン・ドレイクによる「ベース（共有）の事前承認」に関する提案:https://ethresear.ch/t/based-preconfirmations/17353
- L1SLOAD（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
何が残っていて、どんなトレードオフがありますか？
上記の多くの例は、いつ標準化するか、どのレイヤを標準化するかという標準的なジレンマに直面しています。早すぎると標準化すると、劣った解決策を固定化するリスクがあります。遅すぎると標準化すると、不要な断片化を生むリスクがあります。一部のケースでは、弱い特性を持つ短期的な解決策と、実装が容易ながら「究極的に正しい」とされる長期的な解決策の両方が存在することがありますが、そちらに到達するにはかなりの年数がかかります。
このセクションがユニークな点の1つは、これらのタスクが単なる技術的な問題でないことです：それらはまた（おそらくは主に！）社会的な問題でもあります。L2とウォレット、L1が協力することが必要です。この問題を成功裏に処理する能力は、コミュニティとして団結する能力の試金石です。
他の部分とどのようにやり取りしますか？
これらの提案のほとんどは「上位層」の構築物であり、したがってL1の考慮事項には大きな影響を与えません。共有シーケンスが例外であり、MEVに重大な影響を与えます。
L1での実行スケーリング
私たちは何の問題を解決していますか？
L2が非常にスケーラブルで成功する一方、L1は取引のボリューム処理しかできない場合、イーサリアムには多くのリスクが生じる可能性があります:
- ETH資産の経済状況がよりリスクを伴うものになり、それがネットワークの長期的なセキュリティに影響を与える。
- 多くのL2は、L1の高度に発展した金融エコシステムに密接に結びついていることから利益を得ており、このエコシステムが大幅に弱体化すると、独立したL1である代わりにL2になる動機が弱まります
- L2がL1とまったく同じセキュリティ保証を持つようになるには、かなりの時間がかかるでしょう。
- L2が失敗した場合（例：悪意のあるまたは消えたオペレーターのため）、ユーザーは資産を回収するために引き続きL1を経由する必要があります。したがって、L1は少なくとも時折、実際に高度で複雑なL2の縮小を処理できるほど強力である必要があります。
これらの理由から、L1そのもののスケーリングを継続し、成長する利用者数に対応できるようにすることが重要です。
それは何であり、どのように機能しますか?
スケーリングする最も簡単な方法は、単にガスリミットを増やすことです。 ただし、これによりL1の中央集権化のリスクが生じ、エーテリアムのL1を強力な基盤としている他の重要な特性が弱体化します。 単純なガスリミットの増加が持続可能であるかどうかについての議論が続いており、これは他の技術が実装されてブロックの検証を容易にする場合にも変化します（例：履歴の有効期限切れ、状態の無効化、L1 EVM有効性証明）。 改善し続ける重要な点は、単純にエーテリアムクライアントソフトウェアの効率であり、今日の方が5年前よりもはるかに最適化されています。 効果的なL1ガスリミット増加戦略には、これらの検証技術の加速が含まれます。
別のスケーリング戦略には、ネットワークの分散化やセキュリティ特性を損なうことなく、より安くすることができる特定の機能や計算タイプを特定することが含まれます。これには、次のような例があります:
- EOF- 静的解析により、より高速な実装が可能になる新しいEVMバイトコード形式。 EOFバイトコードは、これらの効率を考慮に入れて、より低いガスコストが与えられる可能性があります。
- 多次元ガス価格設定- 計算、データ、およびストレージ用の別々のベース料金と制限を設定することにより、Ethereum L1の平均容量を増やすことができますが、最大容量を増やさず（したがって新しいセキュリティリスクを作成しないで）います。
- 特定のオペコードとプリコンパイルのガスコストを削減する－歴史的に、私たちは持っていましたいくつか ラウンズの増加ガスコストサービス拒否攻撃を回避するために過小価格で行われている特定の操作のためには、それほど少なくありませんでしたが、それをより多く行うことができるのは、過大価格で行われている操作のガスコストを削減することです。たとえば、加算は乗算よりもはるかに安価ですが、ADDおよびMULオペコードのコストは現在同じです。ADDをより安くすることができ、PUSHなどのより単純なオペコードをさらに安くすることができます。
- EVM-MAXそしてSIMDEVM-MAX（「モジュラー算術拡張」）は、EVMの別のモジュールとしてより効率的なネイティブなビッグナンバーモジュラー数学を許可する提案です。EVM-MAXの計算によって計算された値は、意図的にエクスポートされない限り、他のEVM-MAXオペコードからのみアクセスできます。これにより、これらの値を保管するための余地が大きくなります。最適化されたフォーマット. SIMD (“single instruction multiple data”)は、値の配列で同じ命令を効率的に実行する提案です。この2つを組み合わせると、強力なものが作成されます。コプロセッサ暗号操作をより効率的に実装するために使用できるEVMの横に配置されます。これは特にプライバシープロトコルやL2証明システムにとって非常に役立ちますので、L1およびL2のスケーリングの両方に役立ちます。
これらの改善点については、将来のSplurgeの投稿で詳しく説明されます。
最後に、第三の戦略はネイティブ・ロールアップ（または“確立されたロールアップ”）です：基本的には、並行して実行されるEVMの多くのコピーを作成し、ロールアップが提供できるものと同等のモデルに至ることで、プロトコルによりネイティブに統合されています。
既存の調査に関連するリンクは何ですか？
- PolynyaのEthereum 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
- スケーリングにおけるSNARKsとネイティブロールアップの使用についてのJustin Drakehttps://www.reddit.com/r/ethereum/comments/1f81ntr/comment/llmfi28/
何が残っていて、どんなトレードオフがありますか？
L1スケーリングのための3つの戦略があり、個別にまたは並行して追求することができます。
- L1をより簡単に検証できるようにするために、技術（例：クライアントコード、ステートレスクライアント、履歴の有効期限）を改善し、その後ガスリミットを引き上げる
- 特定の操作をより安くすることで、最悪のリスクを増やさずに平均容量を増やす
- ネイティブロールアップ（すなわち、「EVMのN個の並列コピーを作成する」、ただし、開発者には展開するコピーのパラメータに関して多くの柔軟性を与える可能性がある）
これらは異なるトレードオフを持つ異なるテクニックであることを理解する価値があります。たとえば、ネイティブロールアップは通常のロールアップと同様のコンポーザビリティの弱点を持っています: 同期的に複数のロールアップ間で操作を行う単一のトランザクションを送信することはできません。1つのL1（またはL2）上の契約と同様にできます。 ガスリミットを引き上げると、L1を検証しやすくすることによって達成できる他の利点から取り上げられます。たとえば、検証ノードを実行するユーザーの割合を増やしたり、個別のステークホルダーを増やしたりすることができます。 EVM内の特定の操作を安くすることは、それがどのように行われるかによって、合計EVMの複雑さを増加させることができます。
L1スケーリングロードマップに必要な大きな問題は、L1に何が属するか、L2に何が属するかという究極のビジョンは何かということです。明らかに、すべてがL1に行くのはばかげています：潜在的なユースケースは数十万のトランザクション/秒に及び、それによってL1を検証することが完全不可能になります（ネイティブロールアップルートに行くまで）。しかし、私たちは何らかの原則を必要としています。それによって、ガスリミットを10倍に増やし、Ethereum L1の分散化を大幅に損ない、活動の99%がL2にある代わりに、90%がL2にある世界になり、その結果はほとんど同じに見える状況を作り出していないことを確認できます。そうでないと、Ethereum L1が特別になっている部分の多くを不可逆的に失ってしまいます。
L1とL2の「分業」の提案された見方の1つは、ソース.
他のロードマップの部分とどのように対話しますか？
L1へのユーザーの増加は、スケールだけでなく、L1の他の側面も向上させることを意味します。これは、より多くのMEVがL1に残ることを意味し（L2だけの問題になるのではなく）、それゆえ、それを明示的に処理する必要性がさらに高まります。L1での高速スロット時間の重要性が大幅に高まります。また、L1の検証（“ザ・ヴァージ”）がうまくいくことに大きく依存しています。
免責事項：
- この記事は[から転載されていますヴィタリック・ブテリン], すべての著作権は元の著者に帰属します[ヴィタリック・ブテリン]. If there are objections to this reprint, please contact the ゲートラーンチーム、そして彼らは迅速に対処します。
- 責任の免責事項：この記事で表現されている意見や見解は、著者個人のものであり、投資アドバイスを構成するものではありません。
- 記事の翻訳はGate Learnチームによって行われます。特に言及されていない限り、翻訳された記事のコピー、配布、または盗用は禁止されています。
関連記事
Polygon 2.0 (POL)とは何ですか？MATICからPOLへの移行（2025）
Neiroとは何ですか？2025年にNEIROETHについて知っておくべきすべて
ラップイーサリアム(WETH)とは何ですか?
ガスレス取引とは?
トルネードキャッシュのすべて
イーサリアムの可能な未来、パート2: ザ・サージ
サージ：主な目標
この章で
スケーラビリティの三角論法
データ利用可能性サンプリングにおけるさらなる進展
データ圧縮
一般化されたプラズマ
L2プルーフシステムの成熟
クロス-L2相互運用性の改善
L1での実行スケーリング
最初、Ethereumにはロードマップで2つのスケーリング戦略がありました。1つは（例：この早い論文2015年に発表されたもう一つのアイデアは「シャーディング」でした：チェーン内のすべての取引を検証し保存する代わりに、各ノードは取引のほんの一部を検証し保存するだけでした。これは他のどんなピア・ツー・ピア・ネットワーク（例：BitTorrent）も同じように機能するので、ブロックチェーンも同じように機能させることができるはずです。もう一つはレイヤー2プロトコルでした：これは、Ethereumの上に位置し、そのセキュリティを十分に活用しながら、ほとんどのデータと計算をメインチェーンから外に保持することができるネットワークでした。"レイヤー2プロトコル"とはステートチャネル2015年、プラズマ2017年に、そしてロールアップ2019年には、Rollupsはステートチャネルやプラズマよりも強力ですが、大量のオンチェーンデータ帯域幅が必要です。幸いなことに、2019年までには、シャーディングの研究によって問題が解決されていました。スケールでの「データの可用性」の検証問題。その結果、2つの道は交わり、私たちはロールアップ中心のロードマップ今日もイーサリアムのスケーリング戦略として続いています。
The Surge, 2023ロードマップエディション。
ロールアップ中心のロードマップは、労働の単純な分割を提案しています：Ethereum L1は堅牢で分散型の基本層に焦点を当て、一方L2はエコシステムのスケーリングを支援する役割を果たします。これは、社会の至る所で繰り返されるパターンです：裁判所（L1）は超高速で効率的である必要はありません。契約と財産権を守るためにあり、それを基にするのは起業家（L2）の役割です。頑丈ベースレイヤーそして、人類を（比喩的であり、文字通りの）火星に連れて行く。
今年、ロールアップ中心のロードマップは重要な成功を収めています：Ethereum L1のデータ帯域が大幅に増加しましたEIP-4844 blobs, そして複数のEVMロールアップが今ステージ 1. とても シャーディングの異質性と多元性の実装, それぞれの L2 が独自のルールとロジックを持つ「シャード」として機能するロールアップは、現実のものとなりました。しかし、この道を進むことには独自の課題があることが分かっています。そして、今私たちの課題は、ロールアップ中心のロードマップを完成させ、これらの問題を解決することであり、同時に、イーサリアム L1 を特別なものにする頑丈さと分散性を保持することです。
サージ：主な目標
- L1+L2での100,000以上のTPS
- L1の分散化と堅牢性を維持する
- 少なくとも一部のL2は、イーサリアムのコアプロパティ（信頼性、オープン性、検閲耐性）を完全に受け継いでいます
- L2間の最大の相互運用性。イーサリアムは34つの異なるブロックチェーンではなく、1つのエコシステムのように感じるはずです。
この章で
余談: スケーラビリティの三すくみ
スケーラビリティの三難問題はアイデアでした2017年に導入されました, それは、ブロックチェーンの3つの特性の間に緊張があると主張しています: 分散化（より具体的には、ノードを実行するコストが低いこと）、スケーラビリティ（より具体的には、処理されるトランザクションの数が多いこと）、およびセキュリティ（より具体的には、攻撃者が全ネットワークの大部分を破損する必要があること、単一のトランザクションを失敗させるために）。
特にトリレンマは定理ではなく、トリレンマを紹介した投稿には数学的な証明が付いていませんでした。ヒューリスティックな数学的議論を示しました。分散型フレンドリーノード（例：消費者向けノートパソコン）が秒間Nトランザクションを検証できる場合、およびk*Nトランザクションを処理するチェーンがある場合、次のいずれかが成り立ちます。それぞれのトランザクションが1/kのノードにしか見られない、これは攻撃者がわずかなノードを破損するだけで悪いトランザクションを通過させる必要があることを意味します。または、あなたのノードは強力であり、あなたのチェーンは分散されていない。投稿の目的は、トリレンマを破ることが不可能であることを示すことではありませんでした。むしろ、トリレンマを破ることは難しいことを示すことでした。その議論が暗示する枠組みの外側の考え方が何らかの方法で必要だということを示すことでした。
長年、いくつかの高性能チェーンは、基本的なアーキテクチャレベルで賢明なことを何もせずにトライレンマを解決すると主張することが一般的でした。通常、ソフトウェアエンジニアリングのトリックを使用してノードを最適化します。これは常に誤解を招き、そのようなチェーンでのノードの実行は常にEthereumよりもはるかに困難になります。この投稿多くの微妙な点について触れることで、なぜそうなのか（つまり、なぜL1クライアントソフトウェアエンジニアリングだけではイーサリアム自体をスケーリングすることができないのか）
しかし、データ可用性サンプリングとSNARKの組み合わせは、トリレンマを解決します:クライアントは、そのデータのごく一部しかダウンロードせず、はるかに少ない量の計算を実行しながら、ある程度の量のデータが利用可能であり、いくつかの計算ステップが正しく実行されたことを検証できます。SNARKはトラストレスです。データ可用性サンプリングには微妙な違いがありますfew-of-N 信頼モデル, しかし、それは非拡張可能なチェーンが持つ基本的な特性を保持しており、つまり、51%攻撃でも悪いブロックをネットワークに受け入れさせることはできないという点です。
トリレンマを解決する別の方法は、Plasmaアーキテクチャを使用することであり、データの利用可能性を監視する責任をユーザーにインセンティブ互換な方法で押し付ける巧妙な技術を使用しています。2017年から2019年にかけて、計算をスケーリングするために持っていたものが詐欺の証明だけだったとき、Plasmaは安全に行うことができることに非常に制限されていましたが、SNARKsの主流化によりPlasmaアーキテクチャは非常に制限されていました。はるかに実現可能これまで以上に幅広い用途に対応しています。
データの利用可能性サンプリングにおけるさらなる進展
我々は何の問題を解決しているのでしょうか？
2024年3月13日時点で、Dencun upgrade実際には、Ethereumブロックチェーンは、12秒間のスロットあたり約125kBの「ブロブ」が3つあり、またはデータ可用性帯域幅のスロットあたり約375kBあります。取引データが直接オンチェーンで公開されると仮定すると、ERC20転送は約180バイトであり、したがってEthereum上のロールアップの最大TPSは次のとおりです:
375000 / 12 / 180 = 173.6 TPS
イーサリアムのcalldata（理論上の最大値：1スロットあたり30百万ガス/1バイトあたり16ガス=1,875,000バイト/スロット）を追加すると、これは607TPSになります。PeerDASでは、blobの数を8〜16に増やす予定で、これによりcalldataでは463〜926 TPSが得られます。
これはイーサリアムL1よりも大幅に増加していますが、それだけでは不十分です。私たちははるかにスケーラビリティを求めています。私たちの中期目標はスロットあたり16 MBで、これはロールアップデータ圧縮の改善と組み合わせると、約58,000 TPSを実現します。
それは何ですか、そしてどのように機能しますか？
PeerDASは、「1Dサンプリング」の比較的単純な実装です。 Ethereumの各ブロブは、253ビットの素体上の度4096の多項式です。 多項式の「シェア」をブロードキャストし、各シェアは、合計8192の座標から取られた隣接する16座標での16評価から構成されています。 現在提案されているパラメーターでは、8192の評価のうちの4096つ（現在の提案されているパラメーターでは、128つの可能なサンプルのうちの64つ）でブロブを回復することができます。
PeerDASは、各クライアントがいくつかのサブネットでリスンすることによって機能します。第iサブネットは、任意のブロブのi番目のサンプルをブロードキャストし、さらに、必要な他のサブネットのブロブを要求するために、グローバルP2Pネットワーク内のピアに尋ねます（異なるサブネットをリスンしている可能性があります）。より保守的なバージョン、サブネットDAS, 追加のピアに尋ねる層を持たずに、サブネットメカニズムのみを使用します。現在の提案は、ステークプルーフに参加するノードがSubnetDASを使用し、他のノード（つまり「クライアント」）がPeerDASを使用することです。
理論的には、1Dサンプリングをかなりスケーリングすることができます。ブロブ数の最大値を256に増やすと（つまり、ターゲットを128にすると）、データ可用性サンプリングによる各ノードのコストはわずか16サンプルになります。16 MBのターゲットに到達します。128 blobs1つのブロブあたり512バイト=1つのスロットあたり1MBのデータ帯域幅。これはわずかに容認範囲内です：可能ですが、帯域幅に制約のあるクライアントはサンプリングできません。ブロブの数を減らし、ブロブのサイズを増やすことで、これをある程度最適化できますが、これにより再構築がより高価になります。
そして最終的に私たちはさらに進み、そして2Dサンプリング、ブロブ内だけでなく、ブロブ間でもランダムサンプリングによって機能する。 KZGコミットメントの線形特性は、ブロック内のブロブのセットを新しい「仮想ブロブ」のリストで「拡張」するために使用され、同じ情報を冗長に符号化する。
2Dサンプリング。ソース: a16z crypto
重要なのは、コミットメントの拡張を計算する際にはブロブが必要ないため、このスキームは基本的に分散型ブロック構築に対して友好的です。実際にブロックを構築しているノードは、ブロブ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
- 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
- フランチェスコによるPeerDASに関するプレゼンテーション: https://www.youtube.com/watch?v=WOdpO1tH_Us
- EIP-7594: https://eips.イーサリアム.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から量子耐性のある、信頼できるセットアップフリーの代替手段に移行したいと考えています。現在、分散型ブロック構築に対応する候補がわかっていません。再帰的なSTARKsを使用して行と列の再構築のための妥当性の証明を生成する「総当たり」テクニックでさえ、十分ではありません。なぜなら、技術的にはSTARKがO(log(n) * log(log(n))のハッシュサイズであるためです。STIR), 実際には、STARKはほぼ全体のブロブと同じくらい大きいです。
私が長期的に見ている現実的な道は次のとおりです:
- 理想的な2D DASを実装します
- 1D DASにこだわり、サンプリング帯域幅の効率を犠牲にし、シンプルさと堅牢性のためにデータ上限を低く抑える
- （ハードピボット）DAを放棄し、プラズマを第2層アーキテクチャの主要なものとして完全に受け入れることに焦点を当てています
これらはトレードオフスペクトルを通して表示できます。
L1を直接スケーリングすることに決定した場合でも、この選択肢が存在することに注意してください。なぜなら、L1が多くのTPSを処理する必要がある場合、L1ブロックは非常に大きくなり、クライアントはそれらが正しいことを効率的に検証したいと思うため、L1でロールアップ（ZK-EVMとDASの技術を使用することになるからです。
他の部分とどのように連携しますか？
2D DASの必要性は、データ圧縮（以下参照）が実装されていれば多少軽減されるか、少なくとも遅延されるか、また、Plasmaが広く使用されている場合はさらに軽減されます。DASは、分散型ブロック構築プロトコルやメカニズムにも課題を提起します。DASは理論的に分散再構築に適していますが、これを実践で組み合わせる必要があります。包含リスト提案とそれに囲まれたフォーク選択メカニズム。
データ圧縮
私たちは何の問題を解決していますか？
ロールアップ内の各トランザクションは、オンチェーンで大量のデータスペースを使用します：ERC20の転送には約180バイトかかります。理想的なデータ可用性サンプリングでも、これによりレイヤー2プロトコルのスケーラビリティに上限が設定されます。1つのスロットあたり16 MBの場合、以下を得ます。
16000000 / 12 / 180 = 7407 TPS
分母に取り組むだけでなく、ロールアップ内の各トランザクションをより少ないバイトでオンチェーンに取り組むことができたらどうでしょうか？
それは何ですか？ それはどのように機能しますか？
私の意見では、最良の説明はこの図2年前から:
最も単純な利益はゼロバイト圧縮だけです。ゼロバイトの長いシーケンスを、ゼロバイトの数を表す2バイトで置き換えることです。さらに進むために、取引の特定の特性を活用します。
- 署名の集約 - ECDSA署名からBLS署名に切り替えますが、BLS署名は、多くの署名を1つの署名に組み合わせて、元のすべての署名の有効性を証明することができるという特性を持っています。L1 では、集計を使用しても検証の計算コストが高くなるため、これは考慮されませんが、L2 のようなデータが少ない環境では、間違いなく理にかなっています。の集計機能ERC-4337これを実装するための1つの方法を示しています。
- アドレスをポインターで置き換える- 以前にアドレスが使用されていた場合、20バイトのアドレスを履歴の場所を指す4バイトのポインターで置き換えることができます。これは最大の利益を得るために必要ですが、実装するのに努力が必要です。なぜなら、（少なくとも一部の）ブロックチェーンの履歴が実質的に状態の一部になる必要があるからです。
- トランザクション値のカスタムシリアル化 - ほとんどのトランザクション値は非常に少ない桁数を持っており、たとえば、0.25 ETH は 250,000,000,000,000,000 wei として表されます。ガスの最大ベース手数料や優先手数料も同様に機能します。したがって、カスタムの10進浮動小数点形式、または特に一般的な値の辞書を使用して、ほとんどの通貨値を非常にコンパクトに表現することができます。
既存の研究へのリンクは何ですか？
- sequence.xyzからの探査: https://sequence.xyz/blog/compressing-calldataは、シーケンスのブログです
- ScopeLiftからのL2向けのCalldata最適化された契約:https://github.com/ScopeLift/l2-optimizoooors
- 代替戦略 - 有効性証明ベースのロールアップ（ZKロールアップとも呼ばれる）は、取引ではなく状態の差分を投稿します：https://ethresear.ch/t/rollup-diff-compression-application-level-compression-strategies-to-reduce-the-l2-data-footprint-on-l1/9975
- BLSウォレット - ERC-4337を通じたBLS集約の実装:https://github.com/getwax/bls-wallet
何が残っていて、どんなトレードオフがありますか？
実際に上記のスキームを実装することが残されている主要な作業です。主なトレードオフは次のとおりです。
- BLS署名への切り替えにはかなりの労力が必要で、セキュリティを向上させることができる信頼できるハードウェアチップとの互換性が低下します。他の署名方式の周囲にZK-SNARKラッパーを配置することで、これを置き換えることができます。
- 動的圧縮 (アドレスをポインターに置き換えるなど) は、クライアント コードを複雑にします。
- トランザクションではなくチェーンに状態の差分を投稿すると、監査可能性が低下し、多くのソフトウェア（例：ブロックエクスプローラー）が動作しなくなります。
他の部分のロードマップとのやり取りはどのようになりますか？
ERC-4337の採用、そして最終的にL2 EVMの一部を確立することは、集約技術の展開を大幅に促進することができます。 ERC-4337の一部をL1に確立することで、L2上での展開を促進することができます。
一般化プラズマ
私たちはどの問題を解決していますか？
16 MBのブロブやデータ圧縮を使用しても、58,000 TPSであっても、消費者支払い、分散型ソーシャル、その他の高帯域セクターを完全に引き継ぐには必ずしも十分とは限らず、特にプライバシーを考慮し始めると、スケーラビリティが3-8倍に低下する可能性があります。高ボリュームで低価値なアプリケーション向けには、現在、1つの選択肢があります。バリデウム, データをオフチェーンに保持し、オペレーターはユーザーの資金を盗むことはできませんが、彼らは消えることができ、一時的または永久的にすべてのユーザーの資金を凍結することができます。しかし、私たちはより良いことができます。
それは何ですか？ どのように機能しますか？
Plasmaは、オペレーターがオフチェーンでブロックを公開し、それらのブロックのMerkleルートをオンチェーンに配置するスケーリングソリューションであり（ロールアップとは異なり、完全なブロックがオンチェーンに配置される）、オペレーターは各ブロックに対して、ユーザーごとに何が起こったか、または起こらなかったかを証明するMerkleブランチを送信します。ユーザーは、Merkleブランチを提供することで、自分の資産を引き出すことができます。重要なのは、このブランチが最新の状態に根ざしている必要はないことです。そのため、データの可用性が失敗した場合でも、ユーザーは利用可能な最新の状態を引き出すことで、依然として自分の資産を回復することができます。ユーザーが無効なブランチを提出した場合（例：他の誰かに送信済みの資産を退出した、またはオペレーター自体が空気から資産を作成した）、オンチェーンのチャレンジメカニズムが資産が正当に誰に属するかを裁定できます。
Plasma Cashチェーンのダイアグラム。コインiを消費する取引は、木構造のi番目の位置に配置されます。この例では、すべての前の木構造が有効であると仮定すると、Eveが現在コイン1を所有していること、Davidがコイン4を所有していること、Georgeがコイン6を所有していることがわかります。
Plasmaの初期バージョンは支払いのユースケースのみを処理でき、それ以上の一般化ができませんでした。ただし、各ルートをSNARKで検証する必要がある場合、Plasmaははるかに強力になります。各チャレンジゲームは、オペレーターが不正を行う可能性のある経路を大幅に取り除くため、大幅に簡素化されます。新しい経路も開かれ、Plasma技術をより一般的なアセットクラスに拡張することができます。最後に、オペレーターが不正を行わない場合、ユーザーは1週間のチャレンジ期間を待つ必要なく、即座に資金を引き出すことができます。
EVMプラズマチェーンを作成するための1つの方法（唯一の方法ではない）：ZK-SNARKを使用してEVMによって行われた残高の変更を反映する並列UTXOツリーを構築し、「同じコイン」が歴史の異なる時点で何であるかを定義します。その上にPlasma構造を構築することができます。
重要な洞察の1つは、プラズマシステムが完璧である必要はないということです。資産のサブセット(たとえば、過去1週間に動いていないコインだけ)しか保護できない場合でも、バリデウムである超スケーラブルEVMの現状をすでに大幅に改善しています。
もう1つの構築クラスは、ハイブリッドプラズマ/ロールアップ、Intmaxこれらの構築は、ユーザーごとに非常に少量のデータ（例：5バイト）をオンチェーンに配置し、その結果、プラズマとロールアップの中間に位置するプロパティを取得します。 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
何を残すか、そしてどんなトレードオフがありますか？
メインの残りのタスクは、プラズマシステムを本番環境に導入することです。上記のように、「プラズマ vs バリディウム」はバイナリではありません: 任意のバリディウムは、出口メカニズムにプラズマの機能を追加することで、少なくとも少しはその安全性を向上させることができます。研究の一部は、EVMの信頼要件、最悪のケースでのL1ガスコスト、DoSへの脆弱性に関する最適な特性（および代替のアプリケーション固有の構築）を取得することです。また、ロールアップに比べてプラズマの概念的複雑さが直接対処される必要があります。これは、研究とより良い汎用フレームワークの構築の両方を通じて行われます。
Plasmaデザインを使用する際の主なトレードオフは、オペレーターに依存しやすく、「作り込むのが難しい」という点です。ベース「ハイブリッドプラズマ/ロールアップデザインでは、この弱点を回避することができることが多い」と言える。
他の部分とどのようにやり取りしますか？
より効果的なプラズマソリューションがあれば、L1に高性能なデータ可用性機能が必要な圧力が少なくなります。活動をL2に移すことで、L1へのMEV圧力も軽減されます。
L2プルーフシステムの成熟
何の問題を解決していますか？
今日、ほとんどのロールアップは実際にはまだ信頼できません。セキュリティ委員会が（楽観的または有効性に関する）振る舞いを上書きする能力があります。プルーフシステム.場合によっては、プルーフシステムがまったく稼働していないか、稼働していても「アドバイザリー」機能しかありません。最も進んでいるのは、(i)トラストレスなFuelなどのアプリケーション固有のロールアップと、(ii)この記事の執筆時点では、「ステージ1」として知られる部分的なトラストレスのマイルストーンを達成した2つのフルEVMロールアップであるOptimismとArbitrumです。ロールアップが進まない理由は、コードのバグに対する懸念です。トラストレスなロールアップが必要なので、この問題に正面から取り組む必要があります。
それは何であり、どのように機能しますか?
ますは、最初に、元〇〇に導入された「ステージ」システムを振り返ってみましょう。この投稿.より詳細な要件がありますが、要約は次のとおりです。
- ステージ 0: ユーザーがノードを実行し、チェーンを同期できる必要があります。検証が完全に信頼/集中化されていれば問題ありません。
- ステージ1：有効なトランザクションのみが受け入れられることを保証する（信頼できる）証明システムが必要です。証明システムを上書きできるセキュリティ評議会が存在することを許可しますが、75％の閾値投票のみが許可されます。さらに、評議会のクォーラムブロッキング部分（つまり、26％以上）は、ロールアップを構築する主要企業の外にある必要があります。より弱い機能を持つアップグレードメカニズム（例：DAOなど）は許可されますが、悪意のあるアップグレードを承認した場合、ユーザーがオンライン化される前に自分の資金を引き出せるように、十分な遅延が必要です。
- 段階2：有効なトランザクションのみが受け入れられることを保証する（信頼できる）証明システムが存在する必要があります。セキュリティ委員会は、たとえば2つの冗長な証明システムが互いに異なる意見を持つ場合や、1つの証明システムが同じブロックのために2つの異なるポスト状態のルートを受け入れる場合（または十分に長い期間、例えば1週間何も受け入れない場合）など、コードに証明されたバグが発生した場合にのみ介入することが許可されています。アップグレードメカニズムは許可されていますが、非常に長い遅延を持っていなければなりません。
Stage 2に到達することが目標です。Stage 2に到達する上での主な課題は、実際に証明システムが信頼できるという自信を持つことです。これを行う主な方法には2つの大きな方法があります。
- フォーマル検証：最新の数学的および計算手法を使用して、(楽観的または妥当性)証明システムがEVM仕様を満たすブロックのみを受け入れることを証明できます。これらの手法は数十年前から存在していますが、最近の進歩により、リーン 4それらをはるかに実用的にし、AI支援証明の進歩によってこのトレンドをさらに加速させる可能性があります。
- マルチプルーバー:複数のプルーフシステムを作成し、それらのプルーフシステムとセキュリティカウンシル(および/または信頼を前提とするその他のガジェット)との間の2-of-3(またはそれ以上)のマルチシグに資金を投入します。TEEs)です。証明制度が合意すれば、安全保障理事会はいかなる権限も持たない。もし彼らが同意しない場合、安保理はどちらか一方しか選べず、一方的に独自の答えを押し付けることはできない。
楽観的な証明システム、有効性証明システム、セキュリティ評議会を組み合わせたマルチプルーバーのスタイル化された図
既存の研究へのリンクはありますか？
- EVM Kセマンティクス（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証明者の完全に検証されたバージョンを作成する必要があります。これは非常に複雑なプロジェクトですが、Gate.ioの製品名の1つです。私たちはすでに始めています.この作業を大幅に簡素化するトリックが1つあります:最小VMの正式に検証されたSNARK証明者を作ることができます。RISC-Vまたはカイロ、その後、その最小VMでEVMの実装を書き、（他のEVM仕様との同等性を形式的に証明する）。
マルチプルーバーにとって、残っている主な2つの部分があります。まず、少なくとも2つの異なる証明システムについて、個々に安全であり、もし壊れた場合は異なる無関係な理由で壊れるという点について、十分な信頼を得る必要があります（そしてそれらが同時に壊れないようになります）。第二に、証明システムを統合する基礎となるロジックに非常に高い信頼レベルを得る必要があります。これはコードのずっと小さな部分です。非常に小さくする方法があります - 単に資金を保管するだけです。安全なマルチシグコントラクトサインする人は、個々の証明システムを表す契約です - ただし、これにはオンチェーンのガスコストが高いというトレードオフがあります。効率と安全性の間には、適切なバランスが見つけられなければなりません。
他のロードマップの部分とどのように連携しますか？
L2への活動の移行は、L1のMEV圧力を軽減します。
Cross-L2相互運用性の改善
私たちはどんな問題を解決していますか？
現在のL2エコシステムの主要な課題の1つは、ユーザーがナビゲートしにくいということです。さらに、その最も簡単な方法は、しばしば信頼の前提条件を再導入します：中央集権的なブリッジ、RPCクライアントなど。もしL2がイーサリアムの一部であるというアイデアを真剣に受け止めるのであれば、L2エコシステムを使用することが統一されたイーサリアムエコシステムを使用するような感覚になるようにする必要があります。
病的に悪い（そして危険すぎる：私はここでチェーン選択のミスで$100を失いました）クロスL2 UXの例−これはPolymarketの責任ではありませんが、クロスL2の相互運用性はウォレットとEthereumスタンダード（ERC）コミュニティの責任であるべきです。機能が良いEthereumエコシステムでは、L1からL2へのコインの送信、または1つのL2から別のL2へのコインの送信は、同じL1内でコインを送信するのと同じように感じるはずです。
それは何ですか？ そして、それはどのように機能しますか？
クロス-L2相互運用性改善の多くのカテゴリがあります。一般的に、これらを考える方法は、理論上、ロールアップ中心のイーサリアムは、L1実行シャーディングと同じものです, そして、現在のEthereum L2バースが実践上でその理想にどこで欠けているかを尋ねます。 ここにいくつかあります:
- チェーン固有アドレス：チェーン（L1、Optimism、Arbitrumなど）はアドレスの一部であるべきです。これが実装されると、クロスL2送信フローは、アドレスを単に「送信」フィールドに入力するだけで実装することができます。その時点で、ウォレットは（ブリッジングプロトコルを使用することを含めて）バックグラウンドで送信する方法を把握できます。
- 特定チェーンの支払いリクエスト：フォーム“チェーンZ上でタイプYのXトークンを送ってください”のメッセージを簡単かつ標準化することが重要です。これには主に2つの使用ケースがあります：(i) 支払い、個人間または個人対商人サービス、および(ii) dappが資金を要求する場合、たとえば上記のPolymarketの例。
- クロスチェーンスワップとガス支払い：「私はOptimism上で1 ETHを送金して、代わりにArbitrumで私に0.9999 ETHを送金する人」などのクロスチェーン操作を表現するための標準化されたオープンプロトコルが必要です。そして、「私はOptimism上で0.0001 ETHを送金して、このトランザクションをArbitrumに含める人」なども必要です。ERC-7683前者の試みの一つであり、Gate.ioはもう一つの試みです。のRIP-7755後者への1つの試みですが、どちらもこれら特定の用途に限らず、より一般的でもあります。
- ライトクライアント:ユーザーは、RPCプロバイダーを信頼するだけでなく、対話しているチェーンを実際に検証できる必要があります。A16zクリプトのヘリオスこれはイーサリアム自体に対して行われますが、この信頼性をL2にも拡張する必要があります。ERC-3668 (CCIP-read)これを行うための1つの戦略です。
軽量クライアントがイーサリアムヘッダーチェーンのビューを更新する方法。ヘッダーチェーンを取得すると、Merkle証明を使用して任意のステートオブジェクトを検証できます。そして、正しいL1ステートオブジェクトを取得すると、Merkle証明（おそらく署名も含む、事前確認をチェックする場合）を使用して、L2上の任意のステートオブジェクトを検証できます。Heliosは既に前者を行っています。後者への拡張は標準化の課題です。
- キーストアウォレット:現在、スマートコントラクトウォレットを制御するキーを更新する場合は、そのウォレットが存在するすべてのNチェーンで更新する必要があります。キーストアウォレットは、キーを1つの場所(L1、または後でL2)に存在させ、ウォレットのコピーを持つ任意のL2から読み取ることができる手法です。つまり、更新は一度だけ行う必要があります。効率を上げるために、キーストアウォレットでは、L2がコストをかけずにL1を読み取るための標準化された方法を持っている必要があります。これに対する2つの提案は次のとおりですL1SLOADそしてREMOTESTATICCALL.
キーストアウォレットがどのように動作するかを示したスタイライズされた図。
- より過激な「共有トークンブリッジ」のアイデア:すべてのL2が有効性証明ロールアップであり、すべてのスロットをイーサリアムにコミットする世界を想像してみてください。この世界でも、あるL2から別のL2に資産を「ネイティブ」に移動するには、引き出しと預金が必要であり、かなりの量のL1ガスを支払う必要があります。これを解決する方法の 1 つは、共有最小ロールアップを作成することであり、その唯一の機能は、どのタイプのトークンがどの L2 によって所有されているかという残高を維持し、いずれかの L2 によって開始された一連のクロス L2 送信操作によってそれらの残高を一括で更新できるようにすることです。これにより、送金ごとにL1ガスを支払う必要がなく、ERC-7683のような流動性プロバイダーベースの手法を必要とせずに、L2間の送金が可能になります。
- 同期可能性：特定の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
- スクロールキーストアウォレットデザイン：@haichen/keystore"">https://hackmd.io/@haichen/keystore
- ヘリオス：https://github.com/a16z/helios
- ERC-3668(CCIP読み取りと呼ばれることもあります):https://eips.ethereum.org/EIPS/eip-3668
- ジャスティン・ドレイクによる「ベース（共有）の事前承認」に関する提案:https://ethresear.ch/t/based-preconfirmations/17353
- L1SLOAD（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
何が残っていて、どんなトレードオフがありますか？
上記の多くの例は、いつ標準化するか、どのレイヤを標準化するかという標準的なジレンマに直面しています。早すぎると標準化すると、劣った解決策を固定化するリスクがあります。遅すぎると標準化すると、不要な断片化を生むリスクがあります。一部のケースでは、弱い特性を持つ短期的な解決策と、実装が容易ながら「究極的に正しい」とされる長期的な解決策の両方が存在することがありますが、そちらに到達するにはかなりの年数がかかります。
このセクションがユニークな点の1つは、これらのタスクが単なる技術的な問題でないことです：それらはまた（おそらくは主に！）社会的な問題でもあります。L2とウォレット、L1が協力することが必要です。この問題を成功裏に処理する能力は、コミュニティとして団結する能力の試金石です。
他の部分とどのようにやり取りしますか？
これらの提案のほとんどは「上位層」の構築物であり、したがってL1の考慮事項には大きな影響を与えません。共有シーケンスが例外であり、MEVに重大な影響を与えます。
L1での実行スケーリング
私たちは何の問題を解決していますか？
L2が非常にスケーラブルで成功する一方、L1は取引のボリューム処理しかできない場合、イーサリアムには多くのリスクが生じる可能性があります:
- ETH資産の経済状況がよりリスクを伴うものになり、それがネットワークの長期的なセキュリティに影響を与える。
- 多くのL2は、L1の高度に発展した金融エコシステムに密接に結びついていることから利益を得ており、このエコシステムが大幅に弱体化すると、独立したL1である代わりにL2になる動機が弱まります
- L2がL1とまったく同じセキュリティ保証を持つようになるには、かなりの時間がかかるでしょう。
- L2が失敗した場合（例：悪意のあるまたは消えたオペレーターのため）、ユーザーは資産を回収するために引き続きL1を経由する必要があります。したがって、L1は少なくとも時折、実際に高度で複雑なL2の縮小を処理できるほど強力である必要があります。
これらの理由から、L1そのもののスケーリングを継続し、成長する利用者数に対応できるようにすることが重要です。
それは何であり、どのように機能しますか?
スケーリングする最も簡単な方法は、単にガスリミットを増やすことです。 ただし、これによりL1の中央集権化のリスクが生じ、エーテリアムのL1を強力な基盤としている他の重要な特性が弱体化します。 単純なガスリミットの増加が持続可能であるかどうかについての議論が続いており、これは他の技術が実装されてブロックの検証を容易にする場合にも変化します（例：履歴の有効期限切れ、状態の無効化、L1 EVM有効性証明）。 改善し続ける重要な点は、単純にエーテリアムクライアントソフトウェアの効率であり、今日の方が5年前よりもはるかに最適化されています。 効果的なL1ガスリミット増加戦略には、これらの検証技術の加速が含まれます。
別のスケーリング戦略には、ネットワークの分散化やセキュリティ特性を損なうことなく、より安くすることができる特定の機能や計算タイプを特定することが含まれます。これには、次のような例があります:
- EOF- 静的解析により、より高速な実装が可能になる新しいEVMバイトコード形式。 EOFバイトコードは、これらの効率を考慮に入れて、より低いガスコストが与えられる可能性があります。
- 多次元ガス価格設定- 計算、データ、およびストレージ用の別々のベース料金と制限を設定することにより、Ethereum L1の平均容量を増やすことができますが、最大容量を増やさず（したがって新しいセキュリティリスクを作成しないで）います。
- 特定のオペコードとプリコンパイルのガスコストを削減する－歴史的に、私たちは持っていましたいくつか ラウンズの増加ガスコストサービス拒否攻撃を回避するために過小価格で行われている特定の操作のためには、それほど少なくありませんでしたが、それをより多く行うことができるのは、過大価格で行われている操作のガスコストを削減することです。たとえば、加算は乗算よりもはるかに安価ですが、ADDおよびMULオペコードのコストは現在同じです。ADDをより安くすることができ、PUSHなどのより単純なオペコードをさらに安くすることができます。
- EVM-MAXそしてSIMDEVM-MAX（「モジュラー算術拡張」）は、EVMの別のモジュールとしてより効率的なネイティブなビッグナンバーモジュラー数学を許可する提案です。EVM-MAXの計算によって計算された値は、意図的にエクスポートされない限り、他のEVM-MAXオペコードからのみアクセスできます。これにより、これらの値を保管するための余地が大きくなります。最適化されたフォーマット. SIMD (“single instruction multiple data”)は、値の配列で同じ命令を効率的に実行する提案です。この2つを組み合わせると、強力なものが作成されます。コプロセッサ暗号操作をより効率的に実装するために使用できるEVMの横に配置されます。これは特にプライバシープロトコルやL2証明システムにとって非常に役立ちますので、L1およびL2のスケーリングの両方に役立ちます。
これらの改善点については、将来のSplurgeの投稿で詳しく説明されます。
最後に、第三の戦略はネイティブ・ロールアップ（または“確立されたロールアップ”）です：基本的には、並行して実行されるEVMの多くのコピーを作成し、ロールアップが提供できるものと同等のモデルに至ることで、プロトコルによりネイティブに統合されています。
既存の調査に関連するリンクは何ですか？
- PolynyaのEthereum 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
- スケーリングにおけるSNARKsとネイティブロールアップの使用についてのJustin Drakehttps://www.reddit.com/r/ethereum/comments/1f81ntr/comment/llmfi28/
何が残っていて、どんなトレードオフがありますか？
L1スケーリングのための3つの戦略があり、個別にまたは並行して追求することができます。
- L1をより簡単に検証できるようにするために、技術（例：クライアントコード、ステートレスクライアント、履歴の有効期限）を改善し、その後ガスリミットを引き上げる
- 特定の操作をより安くすることで、最悪のリスクを増やさずに平均容量を増やす
- ネイティブロールアップ（すなわち、「EVMのN個の並列コピーを作成する」、ただし、開発者には展開するコピーのパラメータに関して多くの柔軟性を与える可能性がある）
これらは異なるトレードオフを持つ異なるテクニックであることを理解する価値があります。たとえば、ネイティブロールアップは通常のロールアップと同様のコンポーザビリティの弱点を持っています: 同期的に複数のロールアップ間で操作を行う単一のトランザクションを送信することはできません。1つのL1（またはL2）上の契約と同様にできます。 ガスリミットを引き上げると、L1を検証しやすくすることによって達成できる他の利点から取り上げられます。たとえば、検証ノードを実行するユーザーの割合を増やしたり、個別のステークホルダーを増やしたりすることができます。 EVM内の特定の操作を安くすることは、それがどのように行われるかによって、合計EVMの複雑さを増加させることができます。
L1スケーリングロードマップに必要な大きな問題は、L1に何が属するか、L2に何が属するかという究極のビジョンは何かということです。明らかに、すべてがL1に行くのはばかげています：潜在的なユースケースは数十万のトランザクション/秒に及び、それによってL1を検証することが完全不可能になります（ネイティブロールアップルートに行くまで）。しかし、私たちは何らかの原則を必要としています。それによって、ガスリミットを10倍に増やし、Ethereum L1の分散化を大幅に損ない、活動の99%がL2にある代わりに、90%がL2にある世界になり、その結果はほとんど同じに見える状況を作り出していないことを確認できます。そうでないと、Ethereum L1が特別になっている部分の多くを不可逆的に失ってしまいます。
L1とL2の「分業」の提案された見方の1つは、ソース.
他のロードマップの部分とどのように対話しますか？
L1へのユーザーの増加は、スケールだけでなく、L1の他の側面も向上させることを意味します。これは、より多くのMEVがL1に残ることを意味し（L2だけの問題になるのではなく）、それゆえ、それを明示的に処理する必要性がさらに高まります。L1での高速スロット時間の重要性が大幅に高まります。また、L1の検証（“ザ・ヴァージ”）がうまくいくことに大きく依存しています。
免責事項：
- この記事は[から転載されていますヴィタリック・ブテリン], すべての著作権は元の著者に帰属します[ヴィタリック・ブテリン]. If there are objections to this reprint, please contact the ゲートラーンチーム、そして彼らは迅速に対処します。
- 責任の免責事項：この記事で表現されている意見や見解は、著者個人のものであり、投資アドバイスを構成するものではありません。
- 記事の翻訳はGate Learnチームによって行われます。特に言及されていない限り、翻訳された記事のコピー、配布、または盗用は禁止されています。
関連記事
Polygon 2.0 (POL)とは何ですか？MATICからPOLへの移行（2025）
Neiroとは何ですか？2025年にNEIROETHについて知っておくべきすべて
ラップイーサリアム(WETH)とは何ですか?
ガスレス取引とは?
トルネードキャッシュのすべて