＃＃＃ 序章さまざまなロールアップ ソリューションのビジョンとロードマップを見ると、ほとんどすべてのロールアップには最終的な目標があることがわかります。この目標を一文に要約すると、テクノロジ スタックを構築し、コミュニティに提供し、ソリューションの拡張を解決します。ブロックチェーン、そして最終的には運用とガバナンスのテクノロジースタックの分散化です。これは、分散ロールアップという用語につながります。では、分散化とは一体何でしょうか?ロールアップ システムのさまざまな部分の役割分担は何ですか?分散化とは、システム運用参加者を最大化することを意味しますか?集中仕分け機はどのような影響を与えるのでしょうか?共有順序付け者と L2 ローカル コンセンサスはどのように設計されるべきですか? ZK-Rollup のユニーク証明者の機能は何ですか?オープンな分散型証明者ネットワークはどのようなものになるでしょうか? zk ハードウェア アクセラレーションが必要な理由は何ですか?データ可用性の問題の解決策は何ですか? ....コミュニティでは分散型ロールアップに関する議論が絶え間なく行われているため、ECN は「分散型ロールアップ」をテーマにした一連のポッドキャスト インタビューを企画し、この分野の優れた創設者や研究者を招待して分散型ロールアップについての理解を語ってもらいました。レイヤ 2 プラットフォームに流動性がますます流入するにつれて、汎用ロールアップ ソリューション、アプリケーション固有のロールアップ チェーンだけでなく、サービスとしてのロールアップ プラットフォームなど、ロールアップ サービス プロバイダーがますます登場しています。したがって、ほとんどすべてのロールアップにおける非常に重要な役割である「シーケンサ」が依然として集中化されているのではないかと懸念する人が増えています。集中仕分け機にはどのようなリスクがありますか?分散型仕分け機は緊急の仕事ですか？**第 2 のエピソードでは、AltLayer Network の創設者である Yaoqi Jia、Scroll の研究者である Toghrul Maharramov、Starknet Exploration Lead の Abdelhamid Bakhta を招待し、分散型ソーターのテーマに関するラウンドテーブル ディスカッションを実施しました。現在の分散型仕分け機の進歩とジレンマを理解できる。 ****今回のゲスト:*** AltLayer Network 創設者 Yaoqi Jia、twitter @jiayaoqi* 巻物研究者トグルル・マハラモフ、twitter @toghrulmaharram* スタークネット探査リーダー、アブデルハミド・バフタ氏、twitter @dimahledba**過去**問題 1: ロールアップを分散化するにはどうすればよいですか?* アービトラム研究者パトリック・マッコーリー**プレビュー**問題 3: Prover ネットワークと zk ハードウェア アクセラレーション* Ye Zhang、Scroll 共同創設者* レオ・ファン、Cysic 共同創設者問題 4: データの可用性と分散ストレージ* Qi Zhou、EthStorage 創設者**聞く**詳細については、クリックしてポッドキャストを購読してください:ユーチューブ：小宇宙：**タイムスタンプ**- 00:49 ヤオチーの自己紹介- 01:37 アブデルハミドの自己紹介- 02:50 トグルルの自己紹介- 04:03 ロールアップにおけるソーターの役割- 08:37 分散型注文者: ユーザー エクスペリエンスを向上させ、ライブネスと検閲の問題に対処する- 19:43 Starknet がソーターをどのように分散化するか- 22:59 Scroll がソーターをどのように分散化するか- 26:34 オプティミスティックロールアップとzkRollupのコンテキストにおけるL2コンセンサスの違い- 32:28 zkRollup はソーターを分散化し、証明者も考慮する必要がある- 36:01 ベースロールアップとは何ですか?- 40:53 共有シーケンサーとベース ロールアップの欠点とその適用シナリオ- 49:02 分散型発注者は MEV にどのような影響を与えますか?### ゲスト紹介**ヤオチー**私は AltLayer の創設者です。 AltLayer は、開発者がいくつかのボタンをクリックしてパラメータを設定するだけで「サービスとしてロールアップ」プラットフォームを構築しています。ランチパッドまたはコントロール パネルを使用すると、アプリケーション固有のロールアップを数分で迅速に起動できます。したがって、開発者に共通の実行環境と機能を提供することが私たちが現在やろうとしていることです。また、開発者が選択できる複数のシーケンサー、複数の仮想マシン システム、およびさまざまなプルーフ システムも提供します。**アブデルハミド**私は Starkware で働いており、探索チームのリーダーです。このグループの目標は基本的に、研究に似ているがエンジニアリングに重点を置いたオープンソース プロジェクトを立ち上げることです。私たちの目標は、コミュニティや他のエコシステムの人々と緊密に連携してオープンソース プロジェクトに取り組むことです。そのようなプロジェクトの 1 つが Madara で、実際には Starknet ソーターです。これは、Starknet パブリック ネットワークの候補であるだけでなく、Starknet アプリケーション チェーンと Layer3 のシーケンサーでもあります。これは前のゲストが言ったこととも関連しますが、サービス機能としてロールアップを提供することも考えています。ユーザーは Starknet アプリケーション チェーンを展開し、ある程度モジュール化された方法でさまざまなデータ可用性ソリューションを選択できます。その前は、イーサリアムのコア開発者として 4 年間働き、主に EIP-1559 の作業を担当していました。**選択**私は Scroll の研究者で、Scroll での主な業務はプロトコル設計、ブリッジ設計、分散化、インセンティブなどです。そのため、ツイートしていないときは、ほとんどの場合、プロトコルや注文者、証明者などを分散化する方法に取り組んでいます。 Starkware と同様に、私たちが取り組んでいるものの 1 つはロールアップ SDK です。したがって、スクロールに基づいてロールアップを発行し、さまざまなデータ可用性オプションなどをモジュール的に使用できます。私たちは、Scroll SDK に基づくロールアップが Scroll のソーターを使用して、各ロールアップがそれ自体で分散化を処理する必要がなく、分散化を実現できるオプションをまだ検討しています。もちろん、計画はまだ最終決定されていません。しかし、これは私たちが取り組んでいる方向でもあります。### インタビューセクション**トピック 1**ロールアップのソーターについて説明してください。**アブデルハミド**ソーターはレイヤー 2 アーキテクチャの非常に重要なコンポーネントです。このコンポーネントはユーザーからトランザクションを受け取り、それらをブロックにパッケージ化してバンドルし、トランザクションを実行します。 Layer2 もトランザクション ブロックを備えたブロックチェーンであるため、これはブロックの作成を担当するコンポーネントであるため、これは非常に重要です。注文者はこれらのブロックを作成し、証明者はこれらのブロックを証明します。**ヤオチー**アブデル氏が述べたように、注文者はブロックチェーン内の多くの機能の組み合わせです。したがって、現在、一般的なパブリックブロックチェーンと比較して、実際には注文者に過大な責任を与えている可能性があります。まずユーザーからのすべてのトランザクションを集計し、次にそれらのトランザクションをガソリン価格または先着順に基づいて並べ替える必要があります。その後、シーケンサーはこれらのトランザクションを実行する必要があります。現在と同様に、一部の Layer2 は EVM を使用します (Starware には別の仮想マシンがあります) が、基本的にシーケンサーはトランザクションの実行と状態の生成に専用の仮想マシンを使用する必要があります。その後、トランザクションは事前確認段階に到達します。つまり、確認時間が 1 ～ 2 秒、あるいはそれ未満の場合、それは基本的にシーケンサーによって完了した事前確認状態であることを意味します。次に、ほとんどのソーターでは、チェックポイントまたは状態ハッシュを L1 にアップロードまたは公開する必要もあります。これは L1 レベルでの確認であり、これをデータ可用性と呼びます。このように、ロールアップ システムにおいて仕分け機は実際には多くの役割を担っています。しかし、一般的に、これはロールアップ システムの最も重要なコンポーネントだと思います。** トピック 2 **分散型ソーターがなぜ重要なのでしょうか?集中型ソーターを使用する場合、ユーザーとシステムに対する隠れた危険は何でしょうか?**選択**まず第一に、現段階では Fuel V1 を除いて、他のロールアップにはまだ補助輪があるため、実際のロールアップは存在しないことを知っておく必要があります。ただし、ロールアップとして分類されると、マルチシグは削除されるなどと言えます。そうなると、ソーターの分散化の問題は、セキュリティの問題ではなく、ユーザー エクスペリエンスの問題になります。したがって、人々が、たとえば L1 の分散化について話すとき、問題はまったく異なります。 L1 は注文クライアントとライトクライアントに保証を提供する必要があるためです。したがって、ライト クライアントが状態が正しいことを確認したい場合は、L1 バリデータを信頼する必要があります。ロールアップの場合、これは当てはまりません。ソーターは一時的なソートのみを提供し、その後 L1 によって最終的にソートが行われるためです。また、ロールアップは検閲耐性も保証されているため、これを実現するために分散化は必要ありません。したがって、分散型ソーターが必要な理由はいくつかあります。まず、L1 ファイナライズが遅い場合 (提出された有効性証明が遅すぎるため、または楽観的ロールアップ不正証明のチャレンジ期間メカニズムのいずれかが原因で)、トランザクションの迅速な確認を達成するために何かに依存する必要があります。迅速な確認のこの段階では、Starkware や Scroll は騙されないと信頼できますが、ブロックが確認された後は再編成は行われないことが示されています。これは信頼の前提です。そして、地方分権化により、経済的保証などが追加される可能性があります。ただし、これに基づくと、ロールアップにはリアルタイムのファイナリティ保証もありません。基本的に、L1 経由でトランザクションのパッケージ化を強制できますが、そのトランザクションのパッケージ化には数時間かかります。たとえば、更新を担当するオラクルがあり、時間が変動する場合、基本的にオラクルが 1 時間以上更新されると、ロールアップ内のアプリケーションは使用できなくなります。基本的に、分散化により、強力なリアルタイム検閲耐性の保証を提供できるようになります。その場合、敵対者は、1 つのエンティティまたは少数のエンティティだけでなく、注文者のネットワーク全体を侵害する必要があるからです。したがって、私たちにとって分散化は、ユーザーエクスペリエンスを向上させたり、オラクルの更新などの特殊なケースを修正したりするためのソリューションです。基本的なセキュリティ保証を提供する代わりに、これが L1 の機能です。**アブデルハミド**はい、あなたが言及した分散型ソーターに関する質問は、分散型 L1 とまったく同じではありません。これは非常に重要だと思います。なぜなら、一部のL1が集中型ソーターを批判しているのを見ると、彼らは集中型ソーターがもたらすトレードオフを適切に見ていないからです。これに基づいて、ユーザーエクスペリエンス、アクティビティに関連するものを追加したいと思います。ソーターが 1 台しかない場合、ソーターがクラッシュするリスクが高くなるからです。したがって、分散型発注者はネットワーク上の回復力と活性性も高めます。しかし、一元化された環境であっても、セキュリティに関しては優れたセキュリティを備えています。 L1 経由でパッケージ トランザクションを強制できる場合、この 2 つの違いはタイムラインだけであるためです。また、Toghrul 氏が述べたように、分散型ソーターを使用すると、迅速な検閲耐性を保証できます。したがって、注文者の分散型ネットワークを持つことも活性化にとって重要であることを付け加えておきたいと思います。**ヤオチー**何か付け加えたいと思います。おそらく、この段階で考慮する必要がある最も重要なことはアクティビティです。 Optimism や Arbitrum など、最も人気のある L2 でのエアドロップの最新のケースでは、一定期間のダウンタイムが発生しました。したがって、解決する必要があるのは、ソーターが 1 台しかない場合に、1 秒あたり数千件のトランザクション リクエストをどのように処理するかということだと思います。理論上でも、ノードが 1 つしかない場合、それほど多くのリクエストを同時に処理することはできません。ですから、活力に関しては、複数の選別機が必ず必要になります。単一障害点は実際の障害であり、Web3 だけでなく、Web2 でも大きな問題になります。さらに、検閲の問題もあります。コーディネーターが 1 人しかいない場合、チームで実行できることがわかったとしても、チームが実際にトランザクションをレビューしないことを証明する必要があります。場合によっては、悪意のある当事者が特定の取引をブラックリストに登録することが可能であり、その可能性があります。これは分散型注文者システムであり、他の注文者を通じてトランザクションの送信を試みることもできます。最近シングルソーターに関して多くの批判を受けているのはそのためです。それ以外にも、MEV や初期の実行など、他にもいくつかの問題があります。集中型ソーターを備えたシステム、特に DeFi プロトコルでは、メモリプールを簡単にチェックできる可能性があります。おそらく最有力候補というわけではないが、彼らは取引を追跡して仲裁する可能性が高い。L2 が L1 とは大きく異なることがわかっているにもかかわらず、これらの問題の多くはさまざまな理由から発生します。しかし最終的には、可能な限り分散化する必要があります。したがって、パブリックブロックチェーンやL1で発生するのと同様の問題のいくつかに直面する必要があります。**アブデルハミド**はい、分散型仕分け機が重要であることに同意します。しかし、誰もが知っているように、これは簡単な問題ではないことも言いたいです。また、**ロールアップは複数のエンティティを含む非常に特殊なアーキテクチャを持っているためです。私たちが話している注文者は 1 人ですが、証明者もおり、両方を分散化する必要があります。 **ネットワークを運営するにはさまざまな要素が必要となるため、トランザクションの価格設定にはいくつかのトレードオフや困難が伴います。では、どのようにして取引の価格を設定するのでしょうか?ソーターとプルーバーには異なるハードウェア要件があり、プルーバーには超強力なマシンが必要です。したがって、分散型世界における取引の価格設定も非常に難しい問題であり、ゆっくりと前進する時間が必要な理由です。すぐに分散化したい場合は、いくつかの補助輪を使用して徐々に分散化する必要があるかもしれません。完璧なアーキテクチャを直接望むのであれば、数年かかるからです。したがって、私たちは現実的なアプローチをとり、徐々に分散化を図ろうと考えています。少なくともそれが私たちの現在の計画です。単純な BFT コンセンサス メカニズムから始めて、短期的に別のコンセンサス メカニズムを追加するなどです。だから私が言いたいのは、それは簡単な質問ではないということです。なぜなら、開発速度とアーキテクチャが分散環境にどれだけ適用できるかの間には明らかにトレードオフがあるからです。**トピック 3**ソーターを分散化するにはどうすればよいですか?**アブデルハミド**分散化したい機能はたくさんありますが、それらのすべてに異なるトレードオフがあります。たとえば、分散化する場合、何らかのコンセンサスメカニズムを導入する必要があります。ただし、コンセンサスメカニズムには複数の部分があります。 1 つ目はリーダーの選出です。つまり、誰がブロックを作成するか、誰が特定のスロットまたは特定の時間内にブロックを作成する責任を負う順序付け者になるかを選択する方法です。 **Starknet チームが計画しているのは、レイヤー 1 を可能な限り利用することです。つまり、リーダー選出アルゴリズムでは、レイヤー 1 に賭けたいと考えています。たとえば、トークンがあり、プレッジはリーダー選出メカニズムを決定するために使用されるレイヤー 1 イーサリアムのスマート コントラクト上で行われます。 **これは、L2 注文者がイーサリアム スマート コントラクトにクエリを実行して、次のリーダーなどが誰になるかを知る何らかの対話が必要であることを意味します。したがって、明らかに、ある種のランダム性などが必要です。したがって、それは単純な質問ではありません。しかし、それは最初の部分です。次に、コンセンサスそのもののメカニズムが必要になります。最長チェーン メカニズムまたは BFT、または 2 つのハイブリッドのいずれかという複数のオプションがあります。イーサリアムと同様に、ファイナリティとして LMG Ghost と Casper FFG があります。したがって、私たちは実用的なアプローチを採用し、最初に BFT から始めるかもしれません。なぜ？レイヤー 2 が分散化を考慮する場合、私たちの目標はレイヤー 1 のような大規模なソーターの規模を持つことではありません。たとえば、イーサリアムでは、何百万人ものバリデーターが参加することが目標です。この場合、効率が非常に悪く、非常に大きな問題を引き起こすため、BFT メカニズムをそのまま使用することはできません。たとえば、ビットコインネットワークに問題が発生した場合、それがBFTメカニズムであればチェーンは完全に停止します。しかし、これは事実ではなく、ビットコインネットワークはブロックを作成し続け、ファイナリティメカニズムのみが攻撃されます。ただし、レイヤー 2 で、ターゲットが数百から 1000 台のソーターである場合は、BFT メカニズムから始めるのが良いかもしれません。したがって、リーダー選出メカニズム、次にコンセンサス、そしてその他 2 つの部分がありますが、それについては他のゲストに引き続き追加してもらうことにします。ただし、他の 2 つの部分は状態の更新と証明の生成です。**選択**まず、L2 では、アブデル氏が説明したように、分散化は多面的な問題です。特に zkRollup では、証明者と発注者が存在するため、それらの間で調整する必要があり、両方を分散化する必要があります。この問題は L1 とはまったく異なります。もう 1 つの違いは、L2 では、すべての設計は、基礎となるブリッジにコンセンサスが正しいことを納得させることだけであり、他の多数のノードを納得させることではないということです。もちろん同じことを行う必要がありますが、主な焦点は橋そのものである必要があります。現在、私たちは 2 つの異なる方向に取り組んでいます。第一に、他の皆さんと同じように、私たちは BFT プロトコルに取り組んでいると思います。これはあまり効率的ではなく、解決する必要のある問題がいくつかあります。大まかな解決策は思いつきましたが、まだ最適ではありません。たとえば、質問の 1 つは、仕分け者と証明者の間でインセンティブのバランスをどのように取るかということです。発注者は MEV を制御し、証明者は MEV にアクセスできないため、人々には証明者の代わりに発注者を実行するインセンティブが生じます。しかし実際には、注文者よりも多くの証明者が必要となるため、この 2 つのインセンティブのバランスをどのように取るのでしょうか?これはそれらの問題の 1 つです。私たちが取り組んでいる 2 番目のソリューションは、別の方向です。状況が変わる可能性があることを覚えておいてください。日々新しい提案が出てきます。たとえば、最近ではベース ロールアップや、並べ替えを完全に L1 にアウトソーシングする方法について多くの話題が集まっています。 2 番目の方向は、基本的にソーターを完全に廃止し、外部ビルダーを使用することです。たとえば、イーサリアムビルダーやフラッシュボット SUAVE などは、順序付けされたブロックを提案し、証明者内でコンセンサスを実行します。ここでの利点は、基本的にプロトコル内で PBS を使用でき、より単純なプロトコルが作成されるため、インセンティブに対処する必要がないことです。しかし、欠点は、多数の証明者が必要なため (並列に証明できるため)、それらの証明者を使用して古典的な BFT プロトコルを実行するのが非常に難しいことです。したがって、問題は、既存の BFT プロトコルを、数百、あるいは数千の証明者で実行できるようにどのように最適化するかということです。そして、それは簡単に答えられる質問ではありません。L2コンセンサスの導入は分散型発注者にとって必要ですか?**ヤオチー**このようなものを最近リリースしたばかりなので、この質問には大まかに答えることができます。したがって、コンセンサスを導入するかどうかは、私たちが望むか望まないかによって決まるわけではありません。多数の注文者、または単なるノードが存在する場合は、それらの注文者に同意してもらう必要があります。それは本当にあなたの仮定に依存します。それがビザンチンの仮定である場合は、BFT または既存のビザンチン コンセンサス プロトコルを使用できます。たとえば、非ビザンチン設定の場合、ノードはオンラインとオフラインのみであり、悪意のある動作はできないと仮定するだけであれば、Raft プロトコルまたはその他のより高速なコンセンサス プロトコルを使用できます。しかし、とにかく、注文者または証明者のグループがあり、それらをまとめて一定期間にわたってブロックを生成したい場合は、それらを中心としたコンセンサスプロトコルが必要です。したがって、Toghrul と Abdel が先ほど述べたように、分散型の注文システムや証明システムをどのように実装できるかについては、多くの提案や研究テーマがあると思います。そのため、私たちはマルチソーター ロールアップ システムのテストネットを立ち上げたばかりなので (現在はオプティミスティック ロールアップの不正証明のみをサポートしています)、設計と実装の経験に基づいて、困難について共有できることがいくつかあります。先ほどToghrulさんがおっしゃったように、難しいのはコンセンサスプロトコルそのものではなく、それ以外の部分、例えば証明の部分にあるのです。単一のソーターであれば、多くのノードは必要ないからです。これは EVM、つまり仮想マシンと考えることができます。したがって、トランザクションをフェッチして実行し、状態遷移を行うだけです。証明者は、前の一連のトランザクションの状態遷移の証明を生成する責任があります。ただし、ロールアップ時に照合者と証明者に対してコンセンサス プロトコルを実行する場合は、そこに追加のコンセンサス ロジックを導入する必要があります。これに加えて、コンセンサスプロトコルの証明システムも必要です。したがって、これにより、証明システムが生成する多くの作業が発生します。証明を生成したら、L1 イーサリアムで簡単に検証できます。これが、私たちが最初のマルチオーダーラー テストネットを立ち上げたとき、ある意味、オプティミスティック ロールアップにはその点でいくつかの利点があった理由です。一般に、有効性証明の部分を考慮しないなど、多くのことを簡素化できます。私たちと同じように、私たちは基本的にすべてを WASM と比較します。つまり、最終的には WASM 命令になります。したがって、これらの WASM 命令を検証することにより、Solidity コードを使用して検証することが比較的簡単になります。すべての WASM 命令解釈を Ethereum 上で再実装した場合。しかし一般に、問題は単一ではありません。問題の解決策があれば、それに応じて、同時に解決する必要のある他のフォローアップ作業も発生します。もちろん、MEV を公平に配布するにはどうすればよいかなど、MEV の問題はあるでしょう。ブロックを生成したか、ブロックを検証したかに基づいて、すべての順序付け者と証明者を割り当てることができます。しかし、最終的には、技術的な問題だけでなく、経済的なインセンティブも含めた多くの問題が組み合わさったものになります。そして、ガスコストを大幅に削減したいために L2 が提案されていることを覚えておく必要があります。したがって、それほど多くのノードを持つことはできません。プルーフを生成する場合でも、L2 は L1 よりも高価になる可能性があります。したがって、私たちはこの種の問題に対してバランスの取れたアプローチを考え出す必要があります。**アブデルハミド**もう1点追加させていただきたいと思います。まず、現時点では、楽観的ロールアップに対する実際の許可なしの不正行為の証拠は存在しません。そして、比較する際にはこれについて正直であることが重要であるため、私は機会があるたびにこれを強調し続けています。したがって、それらはまったく L2 ではありません。それが第一です。次に、並べ替えと証明の間の非同期性について、非常に重要なので追加したいと思います。おっしゃるとおり、現時点ではこれがすべてのソリューションのボトルネックになっているため、並べ替えを最適化したいと考えています。しかし、集中型ソートのコンテキストでは問題ありません。ソーターは値の遷移のみを生成し、それを検証できることがわかっているからです。しかし、分散ソートのコンテキストでは、おそらくソーターが検証できないものを生成する可能性があるため、これはより困難になります。その後、後で対処する必要があります。集中型並べ替えのコンテキストでは、並べ替えを最適化するために、並べ替えプロセス中にプルーフを生成する必要がないため、ローカル速度で並べ替えを試みることができ、これが私たちがやりたいことです。 Cairo を LLVM などの低レベルの機械語に変換し、ソーター上で超高速に実行します。その後、非同期で証明できます。そして、証明の最も優れた点は、証明を並行して実行できることです。大規模な並列化可能性は、再帰が可能であることを証明することによって達成されます。だからこそ仕分け機のスピードに追いつくことができるのです。しかし、分散型の場合は、順序付け者が有効な状態遷移のみを生成するようにする必要があるため、これは困難です。**選択**Starknet がここで何をしているのかはよくわからないことを付け加えておきます。しかし、私たちにとって、ソーターを分散化する場合、証明システムは無効なバッチを処理できなければならないというのが、すべての zkRollup の一般的な仮定だと思います。したがって、基本的には、たとえば無効な署名を持つバッチを送信した場合、結果の状態が開始時の状態と同等であることを証明できなければなりません。したがって、どちらの方法でもオーバーヘッドが発生します。重要なのは、このようなことが起こる可能性をいかに最小限に抑えるかです。**アブデルハミド**はい、そうです。そのため、すべてを検証可能にするために Cairo 1 に Sierra を導入しました。この中間表現により、すべての Cairo 1 プログラムが検証可能であることが保証され、元に戻すトランザクションを含めることができます。ベースロールアップとは何ですか?**ヤオチー**ベースのロールアップはもともと、イーサリアム フォーラムの Justin Drake によるブログ投稿から来ました。彼のアイデアの 1 つは、ロールアップ トランザクションを検証するためにいくつかのイーサリアム検証ツールを再利用できるため、さまざまなロールアップ トランザクションを検証するために別個のノード グループを必要としないというものです。特に、将来的には、汎用ロールアップや多くのアプリケーション固有のロールアップなど、多くのロールアップが提供される予定です。したがって、この場合、これらのトランザクションを検証するためのイーサリアムバリデータープールのような共通の場所を見つけることができれば素晴らしいでしょう。もちろん、これは単なるアイデアであり、多くの技術的な問題も伴います。たとえば、理論的には、ロールアップ トランザクションを検証するためにイーサリアム バリデータを要求することはできますが、ロールアップを検証するロジックをイーサリアム プロトコル自体にバンドルまたは埋め込むことは非常に困難です。これをプロトコル内検証と呼びますが、これにはイーサリアム ノードのハード フォークが必要です。もちろん、この場合、いくつかのロールアップ トランザクションを検証できます。しかし、そうすると問題が発生します。これは、L2 のロールアップにイーサリアムの圧力を共有してもらいたいようなものですが、最終的には、L2 にオフロードされた作業の一部をイーサリアムバリデーターに引き受けるよう依頼します。そのため、多くの人がこれをどうやって実現できるかについて話しています。次に、イーサリアム財団の研究者で現在 PBS に取り組んでいる Barnabe 氏に話を聞きました。これはイーサリアムの提案で、バリデーターのタスクを構築者と提案者という複数の役割に分割するというものです。現在、PBS でビルダーの役割を担う Flashbot があり、すべてのブロックを構成してイーサリアム提案者に送信します。したがって、これらのブロックがイーサリアムネットワークにパッケージ化されると、構築者はいくつかの報酬も得ることができます。この場合、イーサリアムネットワークからこれらのバリデータに報酬を与えるにはどうすればよいでしょうか?また、ロールアップ検証も担当します。解決策の 1 つは「再ステーキング」です。これは、EigenLayer やその他のプロトコルでよく耳にしたことがあるかもしれません。ユーザーは他の仕分けネットワークでETHを再ステーキングできます。または、ロールアップの検証作業を行うためにソフトウェアを実際に実行したイーサリアム検証者に報酬を与えます。この場合、L2 と再ステーキング プロトコルの両方から報酬を受け取ることができます。これについてはこれまでに多くの提案がありましたが、一般的には、既存のイーサリアムバリデーターをどのように再利用できるかというアイデアです。既存の ETH を再利用して、ロールアップまたは L2 システムの新時代を迎えるにはどうすればよいでしょうか?つまり、基本的にはロールアップ プロジェクトの多くのことを簡素化しようとしているのです。ロールアップが新しいソーターを必要とする場合、新しい担保ソースが必要な場合は、既存のインフラストラクチャまたは既存の担保を再利用できます。そのため、イーサリアム上に構築されており、さらなるインフラストラクチャとステーキングはロールアップと L2 にも再利用できます。共有シーケンサーとベース ロールアップの欠点とそのアプリケーション シナリオ。**選択**この提案について文句を言いたいのですが、共有シーケンサに関する提案には納得できません。もちろん、まだ初期段階にあるので、将来的にこれらのデザインが改善されれば、私がそれらをサポートする可能性は十分にあります。ただ、今の形では納得がいきません。理由はたくさんあります。まず、私にとって、共有ソーターの主な価値提案は、ユーザーが Scroll や Starknet のような汎用ロールアップ間でアトミックな構成可能性を獲得できるようにすることです。しかし、問題は、アトミックな構成可能性がある場合、ロールアップは結合した最も遅いロールアップと同じくらい最終的なものになることです。したがって、Scroll が Optimistic Rollup と組み合わされると仮定すると、Scroll の最終期限は 7 日になります。 ZKRollup の主な価値提案は比較的迅速にファイナリティを達成することですが、ユーザーは数分以内に L1 に撤退できます。そしてこの場合、基本的には諦めてください。もう 1 つの欠点は、オフチェーンのファイナリティが必要な場合は、L2 ノードを実行する必要があり、チェーンに送信されたデータが L1 によってファイナライズされる限り、L2 でローカルにファイナリティが得られることです。結合された各 L2 が完全なノードを実行しない場合、ローカルでのファイナライゼーションを達成することは事実上不可能です。これは、複数のフル ノードを同時に実行し、それぞれ独自のオーバーヘッドなどがあるため、このシステムの実行は Solana のようなシステムを実行するよりもコストが高くなる可能性があることを意味します。これらの理由から、L2 については意味がないと思います。 L3 の場合は少し異なります。アプリケーション固有のチェーンを構築したいが、分散化には対処したくない場合です。私がゲームを構築していて、ゲームの構築だけを処理したいとします。その後、分散作業をアウトソーシングできます。しかし、現時点ではL2については意味がないと思います。ベースロールアップに関しては、私も懸念しています。たとえば、MEV の利益を証明者とどのように共有しますか?なぜなら、配分の問題を考慮しなければ、基本的には L1 がすべての MEV 利益を得ることができるからです。もう 1 つの小さな点は、その確認時間が L1 の確認時間 (12 分) と同じであることです。これより速いことはありません。もう 1 つの問題は、パーミッションレスであるため、複数の Seeker が同時にトランザクション バッチを送信でき、結果が集中化される可能性があることです。なぜなら、ある検索者が他の検索者よりも簡単に接続できる場合、ビルダーはトランザクションを含める動機になるからです。したがって、最終的には 1 つの Seeker だけが L2 のバッチを提案することになる可能性がありますが、これはあまり良い解決策ではありません。これが発生すると、基本的に振り出しに戻ることになるからです。**ヤオチー**興味深いことに、私は実は先週、Espresso の創設者である Ben と電話したところです。これについては、共有ソーターのトピックでよく議論します。 Toghrul さんがおっしゃったように、共有発注システムの利用シナリオについては不確実性があると思います。これは主に、汎用 L2 の場合、効率、複雑さ、経済性を考慮して、通常は多数のソーターを備えていないためです。そして、共有シーケンサー、ベースのロールアップ、またはレストテイクのいずれであっても、最良の使用例は主に RAS (Rollup as a Service) など、大量のロールアップをロールアウトできるプラットフォームであると私は今でも感じています。正直に言うと、ロールアップがそれほど多くない場合、大規模な並べ替えネットワークは必要ありません。これらのロールアップには、汎用 L2 がいくつかしかない場合、すでに独自のソーター システムがあり、独自のコミュニティまたはパートナーが存在します。実際には、別個のサードパーティ ネットワークを持つ必要はありません。また、L2 ごとにカスタマイズする必要があり、L2 ごとに異なるテスト スタックがあるため、これはサードパーティ ネットワークにとっても負担になります。これには、独自のネットワークに多くの変更を加える必要があります。しかし同時に、Toghrul 氏が述べたように、いくつかの特殊な使用例でも同様です。たとえば、ソーター レベルで相互運用性を確保したい場合は、共有ソーターが有力な手段となる可能性があります。たとえば、複数のロールアップに同じソーターが使用されます。この場合、このソーターは基本的にいくつかのクロスロールアップ トランザクションを処理して、ロールアップ A、B、C 間のクロスチェーン アトミック性を確保できます。しかし、状況を説明すると、ここにも問題があることがわかります。実際にこれらの共有シーケンサーが多数存在する場合、それらは再びボトルネックとなり、新たな単一障害点となるでしょう。私たちはこれらのいわゆる共有発注者に過大な権限を与えすぎています。それらはよりネットワークに近くなり、多くのロールアップを制御します。最後に、この共有ソーターを分散化する方法を再度考え出す必要があります。とにかく、人々が徐々により多くの問題を発見し、より多くの解決策を考え出すのは良いことだと思います。全体として、この分野の最新情報を毎日見るのはとても楽しいです。これらすべての新しいソリューションにより、少なくともロールアップ スペース全体を真に分散化する正しい軌道に乗っています。**アブデル**はい、お二人の意見に同意します。 Layer3 と Lisk にとっては、分散型ネットワークを奨励する責任をもう負いたくないので、ソーターなどを開始するパートナーを見つける必要があるため、これはより理にかなっていると思います。したがって、Liskにとって、それは理にかなっていると思います。しかし、Toghrul と同様に、Layer2 にとってはまだあまり意味がないと思います。**トピック 4**分散型発注者は MEV にどのような影響を及ぼしますか?**アブデル**Starknet の場合、一元化の観点から、いかなるタイプの MEV も実行せず、先着順モデルを採用します。つまり、分散化の文脈では、当然、後でさらに多くの MEV が導入されます。しかし、それはコンセンサスメカニズムの設計やその他の側面にも依存するため、どの比率であるかを言うのは時期尚早です。**選択**しかし問題は、たとえ MEV を行わなかったとしても、Starknet ではまだ MEV が行われている可能性があるということです。まあ、分散化自体は実際には MEV を減らしたり増やしたりしません。もちろん、たとえば、ある種の公平な順序付けプロトコルやしきい値暗号化を適用すると、はい、MEV が最小限に抑えられます。しかし、それを完全になくすことはできません。私の哲学は、「MEV を排除することはできない」です。しかし、BFT コンセンサスを作成しているだけ、または BFT コンセンサスの上に何かを構築しているとします。これは実際には MEV にはまったく影響しません。 MEV はまだ存在しますが、サーチャーがソーターとどのように連携してその MEV を抽出するかが問題となります。**ヤオチー**問題は、先着モデルにも難しい部分があるということです。メンプールを一部のシーカーに公開しても、彼らにはさらにプレイできる利点があります。たとえば、シーケンサーの場合、オフィスのドアの前で待っているのと同じです。したがって、この場合、フロントランニングやサンドイッチ攻撃だけでなく、何らかの裁定取引の機会を見つけると、ユーザーがトランザクションを送信するとすぐに、それをメモリプール内ですぐに確認できます。そのため、他の人よりも早く取引を行うことができます。したがって、彼らは他の検索者よりも有利です。しかし、分散化の話に戻りますが、最初に議論したように、それは主に検閲への抵抗に関するものだと思います。シーケンサーはチームによって管理されます。チームは誰に対しても公平であることがわかります。しかし、これはコードでは防止できません。したがって、P2P ネットワークができれば、これらのノードが私のトランザクションを精査し、他のノードに送信できるようになれば素晴らしいでしょう。したがって、実際には、L2 でのトランザクション処理の公平性が重要になります。MEV に関しては、最近では、単一のロールアップ内で生成される MEV に加えて、ブリッジを越えて生成される MEV もいくつかあります。この比較的分散化された分類ネットワークでは、MEV を抽出する機会がさらに多くなります。共有注文ネットワークがあると仮定すると、共有注文者に何らかの影響を与えてトランザクションを再注文することができれば、基本的に他の人よりも大きなアドバンテージが得られます。共有シーケンサー ネットワークには利点と欠点があります。プラスの面としては、ランカー システムをさらに分散化できることです。しかし、裏を返せば、誰もが仕分け人になるチャンスがあります。つまり、彼らは基本的にやりたいことを何でもすることができ、再び暗い森になります。そこで、分散化を導入しましたが、イーサリアムで直面したのと同様の問題に直面する必要がありました。だからこそ、Flashbot とイーサリアム財団の人々は PBS を進め、提案者と構築者を分離し、構築者側で単一のソリューションを用意しようとしているのです。したがって、問題に目を向けると、それは単一の問題ではありません。それはもはや 1 対 1 の問題ではなく、1 対 6 などの問題です。
AltLayer、Scroll、Starknet チームとの対話: 共有シーケンサーと L2 コンセンサス
＃＃＃ 序章
さまざまなロールアップ ソリューションのビジョンとロードマップを見ると、ほとんどすべてのロールアップには最終的な目標があることがわかります。この目標を一文に要約すると、テクノロジ スタックを構築し、コミュニティに提供し、ソリューションの拡張を解決します。ブロックチェーン、そして最終的には運用とガバナンスのテクノロジースタックの分散化です。これは、分散ロールアップという用語につながります。
では、分散化とは一体何でしょうか?ロールアップ システムのさまざまな部分の役割分担は何ですか?分散化とは、システム運用参加者を最大化することを意味しますか?集中仕分け機はどのような影響を与えるのでしょうか?共有順序付け者と L2 ローカル コンセンサスはどのように設計されるべきですか? ZK-Rollup のユニーク証明者の機能は何ですか?オープンな分散型証明者ネットワークはどのようなものになるでしょうか? zk ハードウェア アクセラレーションが必要な理由は何ですか?データ可用性の問題の解決策は何ですか? ....
コミュニティでは分散型ロールアップに関する議論が絶え間なく行われているため、ECN は「分散型ロールアップ」をテーマにした一連のポッドキャスト インタビューを企画し、この分野の優れた創設者や研究者を招待して分散型ロールアップについての理解を語ってもらいました。
レイヤ 2 プラットフォームに流動性がますます流入するにつれて、汎用ロールアップ ソリューション、アプリケーション固有のロールアップ チェーンだけでなく、サービスとしてのロールアップ プラットフォームなど、ロールアップ サービス プロバイダーがますます登場しています。したがって、ほとんどすべてのロールアップにおける非常に重要な役割である「シーケンサ」が依然として集中化されているのではないかと懸念する人が増えています。集中仕分け機にはどのようなリスクがありますか?分散型仕分け機は緊急の仕事ですか？
**第 2 のエピソードでは、AltLayer Network の創設者である Yaoqi Jia、Scroll の研究者である Toghrul Maharramov、Starknet Exploration Lead の Abdelhamid Bakhta を招待し、分散型ソーターのテーマに関するラウンドテーブル ディスカッションを実施しました。現在の分散型仕分け機の進歩とジレンマを理解できる。 **
今回のゲスト:
過去
問題 1: ロールアップを分散化するにはどうすればよいですか?
プレビュー
問題 3: Prover ネットワークと zk ハードウェア アクセラレーション
問題 4: データの可用性と分散ストレージ
聞く
詳細については、クリックしてポッドキャストを購読してください:
ユーチューブ：
小宇宙：
タイムスタンプ
00:49 ヤオチーの自己紹介
01:37 アブデルハミドの自己紹介
02:50 トグルルの自己紹介
04:03 ロールアップにおけるソーターの役割
08:37 分散型注文者: ユーザー エクスペリエンスを向上させ、ライブネスと検閲の問題に対処する
19:43 Starknet がソーターをどのように分散化するか
22:59 Scroll がソーターをどのように分散化するか
26:34 オプティミスティックロールアップとzkRollupのコンテキストにおけるL2コンセンサスの違い
32:28 zkRollup はソーターを分散化し、証明者も考慮する必要がある
36:01 ベースロールアップとは何ですか?
40:53 共有シーケンサーとベース ロールアップの欠点とその適用シナリオ
49:02 分散型発注者は MEV にどのような影響を与えますか?
ゲスト紹介
ヤオチー
私は AltLayer の創設者です。 AltLayer は、開発者がいくつかのボタンをクリックしてパラメータを設定するだけで「サービスとしてロールアップ」プラットフォームを構築しています。ランチパッドまたはコントロール パネルを使用すると、アプリケーション固有のロールアップを数分で迅速に起動できます。したがって、開発者に共通の実行環境と機能を提供することが私たちが現在やろうとしていることです。また、開発者が選択できる複数のシーケンサー、複数の仮想マシン システム、およびさまざまなプルーフ システムも提供します。
アブデルハミド
私は Starkware で働いており、探索チームのリーダーです。このグループの目標は基本的に、研究に似ているがエンジニアリングに重点を置いたオープンソース プロジェクトを立ち上げることです。私たちの目標は、コミュニティや他のエコシステムの人々と緊密に連携してオープンソース プロジェクトに取り組むことです。そのようなプロジェクトの 1 つが Madara で、実際には Starknet ソーターです。これは、Starknet パブリック ネットワークの候補であるだけでなく、Starknet アプリケーション チェーンと Layer3 のシーケンサーでもあります。これは前のゲストが言ったこととも関連しますが、サービス機能としてロールアップを提供することも考えています。ユーザーは Starknet アプリケーション チェーンを展開し、ある程度モジュール化された方法でさまざまなデータ可用性ソリューションを選択できます。その前は、イーサリアムのコア開発者として 4 年間働き、主に EIP-1559 の作業を担当していました。
選択
私は Scroll の研究者で、Scroll での主な業務はプロトコル設計、ブリッジ設計、分散化、インセンティブなどです。そのため、ツイートしていないときは、ほとんどの場合、プロトコルや注文者、証明者などを分散化する方法に取り組んでいます。 Starkware と同様に、私たちが取り組んでいるものの 1 つはロールアップ SDK です。したがって、スクロールに基づいてロールアップを発行し、さまざまなデータ可用性オプションなどをモジュール的に使用できます。私たちは、Scroll SDK に基づくロールアップが Scroll のソーターを使用して、各ロールアップがそれ自体で分散化を処理する必要がなく、分散化を実現できるオプションをまだ検討しています。もちろん、計画はまだ最終決定されていません。しかし、これは私たちが取り組んでいる方向でもあります。
インタビューセクション
トピック 1
ロールアップのソーターについて説明してください。
アブデルハミド
ソーターはレイヤー 2 アーキテクチャの非常に重要なコンポーネントです。このコンポーネントはユーザーからトランザクションを受け取り、それらをブロックにパッケージ化してバンドルし、トランザクションを実行します。 Layer2 もトランザクション ブロックを備えたブロックチェーンであるため、これはブロックの作成を担当するコンポーネントであるため、これは非常に重要です。注文者はこれらのブロックを作成し、証明者はこれらのブロックを証明します。
ヤオチー
アブデル氏が述べたように、注文者はブロックチェーン内の多くの機能の組み合わせです。したがって、現在、一般的なパブリックブロックチェーンと比較して、実際には注文者に過大な責任を与えている可能性があります。まずユーザーからのすべてのトランザクションを集計し、次にそれらのトランザクションをガソリン価格または先着順に基づいて並べ替える必要があります。その後、シーケンサーはこれらのトランザクションを実行する必要があります。現在と同様に、一部の Layer2 は EVM を使用します (Starware には別の仮想マシンがあります) が、基本的にシーケンサーはトランザクションの実行と状態の生成に専用の仮想マシンを使用する必要があります。その後、トランザクションは事前確認段階に到達します。つまり、確認時間が 1 ～ 2 秒、あるいはそれ未満の場合、それは基本的にシーケンサーによって完了した事前確認状態であることを意味します。次に、ほとんどのソーターでは、チェックポイントまたは状態ハッシュを L1 にアップロードまたは公開する必要もあります。これは L1 レベルでの確認であり、これをデータ可用性と呼びます。このように、ロールアップ システムにおいて仕分け機は実際には多くの役割を担っています。しかし、一般的に、これはロールアップ システムの最も重要なコンポーネントだと思います。
** トピック 2 **
分散型ソーターがなぜ重要なのでしょうか?集中型ソーターを使用する場合、ユーザーとシステムに対する隠れた危険は何でしょうか?
選択
まず第一に、現段階では Fuel V1 を除いて、他のロールアップにはまだ補助輪があるため、実際のロールアップは存在しないことを知っておく必要があります。
ただし、ロールアップとして分類されると、マルチシグは削除されるなどと言えます。そうなると、ソーターの分散化の問題は、セキュリティの問題ではなく、ユーザー エクスペリエンスの問題になります。したがって、人々が、たとえば L1 の分散化について話すとき、問題はまったく異なります。 L1 は注文クライアントとライトクライアントに保証を提供する必要があるためです。したがって、ライト クライアントが状態が正しいことを確認したい場合は、L1 バリデータを信頼する必要があります。ロールアップの場合、これは当てはまりません。ソーターは一時的なソートのみを提供し、その後 L1 によって最終的にソートが行われるためです。また、ロールアップは検閲耐性も保証されているため、これを実現するために分散化は必要ありません。
したがって、分散型ソーターが必要な理由はいくつかあります。まず、L1 ファイナライズが遅い場合 (提出された有効性証明が遅すぎるため、または楽観的ロールアップ不正証明のチャレンジ期間メカニズムのいずれかが原因で)、トランザクションの迅速な確認を達成するために何かに依存する必要があります。迅速な確認のこの段階では、Starkware や Scroll は騙されないと信頼できますが、ブロックが確認された後は再編成は行われないことが示されています。これは信頼の前提です。そして、地方分権化により、経済的保証などが追加される可能性があります。
ただし、これに基づくと、ロールアップにはリアルタイムのファイナリティ保証もありません。基本的に、L1 経由でトランザクションのパッケージ化を強制できますが、そのトランザクションのパッケージ化には数時間かかります。たとえば、更新を担当するオラクルがあり、時間が変動する場合、基本的にオラクルが 1 時間以上更新されると、ロールアップ内のアプリケーションは使用できなくなります。基本的に、分散化により、強力なリアルタイム検閲耐性の保証を提供できるようになります。その場合、敵対者は、1 つのエンティティまたは少数のエンティティだけでなく、注文者のネットワーク全体を侵害する必要があるからです。
したがって、私たちにとって分散化は、ユーザーエクスペリエンスを向上させたり、オラクルの更新などの特殊なケースを修正したりするためのソリューションです。基本的なセキュリティ保証を提供する代わりに、これが L1 の機能です。
アブデルハミド
はい、あなたが言及した分散型ソーターに関する質問は、分散型 L1 とまったく同じではありません。これは非常に重要だと思います。なぜなら、一部のL1が集中型ソーターを批判しているのを見ると、彼らは集中型ソーターがもたらすトレードオフを適切に見ていないからです。
これに基づいて、ユーザーエクスペリエンス、アクティビティに関連するものを追加したいと思います。ソーターが 1 台しかない場合、ソーターがクラッシュするリスクが高くなるからです。したがって、分散型発注者はネットワーク上の回復力と活性性も高めます。しかし、一元化された環境であっても、セキュリティに関しては優れたセキュリティを備えています。 L1 経由でパッケージ トランザクションを強制できる場合、この 2 つの違いはタイムラインだけであるためです。また、Toghrul 氏が述べたように、分散型ソーターを使用すると、迅速な検閲耐性を保証できます。したがって、注文者の分散型ネットワークを持つことも活性化にとって重要であることを付け加えておきたいと思います。
ヤオチー
何か付け加えたいと思います。おそらく、この段階で考慮する必要がある最も重要なことはアクティビティです。 Optimism や Arbitrum など、最も人気のある L2 でのエアドロップの最新のケースでは、一定期間のダウンタイムが発生しました。したがって、解決する必要があるのは、ソーターが 1 台しかない場合に、1 秒あたり数千件のトランザクション リクエストをどのように処理するかということだと思います。理論上でも、ノードが 1 つしかない場合、それほど多くのリクエストを同時に処理することはできません。ですから、活力に関しては、複数の選別機が必ず必要になります。単一障害点は実際の障害であり、Web3 だけでなく、Web2 でも大きな問題になります。
さらに、検閲の問題もあります。コーディネーターが 1 人しかいない場合、チームで実行できることがわかったとしても、チームが実際にトランザクションをレビューしないことを証明する必要があります。場合によっては、悪意のある当事者が特定の取引をブラックリストに登録することが可能であり、その可能性があります。これは分散型注文者システムであり、他の注文者を通じてトランザクションの送信を試みることもできます。最近シングルソーターに関して多くの批判を受けているのはそのためです。
それ以外にも、MEV や初期の実行など、他にもいくつかの問題があります。集中型ソーターを備えたシステム、特に DeFi プロトコルでは、メモリプールを簡単にチェックできる可能性があります。おそらく最有力候補というわけではないが、彼らは取引を追跡して仲裁する可能性が高い。
L2 が L1 とは大きく異なることがわかっているにもかかわらず、これらの問題の多くはさまざまな理由から発生します。しかし最終的には、可能な限り分散化する必要があります。したがって、パブリックブロックチェーンやL1で発生するのと同様の問題のいくつかに直面する必要があります。
アブデルハミド
はい、分散型仕分け機が重要であることに同意します。しかし、誰もが知っているように、これは簡単な問題ではないことも言いたいです。
また、**ロールアップは複数のエンティティを含む非常に特殊なアーキテクチャを持っているためです。私たちが話している注文者は 1 人ですが、証明者もおり、両方を分散化する必要があります。 **ネットワークを運営するにはさまざまな要素が必要となるため、トランザクションの価格設定にはいくつかのトレードオフや困難が伴います。では、どのようにして取引の価格を設定するのでしょうか?ソーターとプルーバーには異なるハードウェア要件があり、プルーバーには超強力なマシンが必要です。したがって、分散型世界における取引の価格設定も非常に難しい問題であり、ゆっくりと前進する時間が必要な理由です。
すぐに分散化したい場合は、いくつかの補助輪を使用して徐々に分散化する必要があるかもしれません。完璧なアーキテクチャを直接望むのであれば、数年かかるからです。したがって、私たちは現実的なアプローチをとり、徐々に分散化を図ろうと考えています。少なくともそれが私たちの現在の計画です。単純な BFT コンセンサス メカニズムから始めて、短期的に別のコンセンサス メカニズムを追加するなどです。だから私が言いたいのは、それは簡単な質問ではないということです。なぜなら、開発速度とアーキテクチャが分散環境にどれだけ適用できるかの間には明らかにトレードオフがあるからです。
トピック 3
ソーターを分散化するにはどうすればよいですか?
アブデルハミド
分散化したい機能はたくさんありますが、それらのすべてに異なるトレードオフがあります。
たとえば、分散化する場合、何らかのコンセンサスメカニズムを導入する必要があります。ただし、コンセンサスメカニズムには複数の部分があります。 1 つ目はリーダーの選出です。つまり、誰がブロックを作成するか、誰が特定のスロットまたは特定の時間内にブロックを作成する責任を負う順序付け者になるかを選択する方法です。 **Starknet チームが計画しているのは、レイヤー 1 を可能な限り利用することです。つまり、リーダー選出アルゴリズムでは、レイヤー 1 に賭けたいと考えています。たとえば、トークンがあり、プレッジはリーダー選出メカニズムを決定するために使用されるレイヤー 1 イーサリアムのスマート コントラクト上で行われます。 **これは、L2 注文者がイーサリアム スマート コントラクトにクエリを実行して、次のリーダーなどが誰になるかを知る何らかの対話が必要であることを意味します。したがって、明らかに、ある種のランダム性などが必要です。したがって、それは単純な質問ではありません。しかし、それは最初の部分です。次に、コンセンサスそのもののメカニズムが必要になります。最長チェーン メカニズムまたは BFT、または 2 つのハイブリッドのいずれかという複数のオプションがあります。イーサリアムと同様に、ファイナリティとして LMG Ghost と Casper FFG があります。
したがって、私たちは実用的なアプローチを採用し、最初に BFT から始めるかもしれません。なぜ？レイヤー 2 が分散化を考慮する場合、私たちの目標はレイヤー 1 のような大規模なソーターの規模を持つことではありません。たとえば、イーサリアムでは、何百万人ものバリデーターが参加することが目標です。この場合、効率が非常に悪く、非常に大きな問題を引き起こすため、BFT メカニズムをそのまま使用することはできません。たとえば、ビットコインネットワークに問題が発生した場合、それがBFTメカニズムであればチェーンは完全に停止します。しかし、これは事実ではなく、ビットコインネットワークはブロックを作成し続け、ファイナリティメカニズムのみが攻撃されます。
ただし、レイヤー 2 で、ターゲットが数百から 1000 台のソーターである場合は、BFT メカニズムから始めるのが良いかもしれません。したがって、リーダー選出メカニズム、次にコンセンサス、そしてその他 2 つの部分がありますが、それについては他のゲストに引き続き追加してもらうことにします。ただし、他の 2 つの部分は状態の更新と証明の生成です。
選択
まず、L2 では、アブデル氏が説明したように、分散化は多面的な問題です。特に zkRollup では、証明者と発注者が存在するため、それらの間で調整する必要があり、両方を分散化する必要があります。この問題は L1 とはまったく異なります。
もう 1 つの違いは、L2 では、すべての設計は、基礎となるブリッジにコンセンサスが正しいことを納得させることだけであり、他の多数のノードを納得させることではないということです。もちろん同じことを行う必要がありますが、主な焦点は橋そのものである必要があります。
現在、私たちは 2 つの異なる方向に取り組んでいます。第一に、他の皆さんと同じように、私たちは BFT プロトコルに取り組んでいると思います。これはあまり効率的ではなく、解決する必要のある問題がいくつかあります。大まかな解決策は思いつきましたが、まだ最適ではありません。たとえば、質問の 1 つは、仕分け者と証明者の間でインセンティブのバランスをどのように取るかということです。発注者は MEV を制御し、証明者は MEV にアクセスできないため、人々には証明者の代わりに発注者を実行するインセンティブが生じます。しかし実際には、注文者よりも多くの証明者が必要となるため、この 2 つのインセンティブのバランスをどのように取るのでしょうか?これはそれらの問題の 1 つです。
私たちが取り組んでいる 2 番目のソリューションは、別の方向です。状況が変わる可能性があることを覚えておいてください。日々新しい提案が出てきます。たとえば、最近ではベース ロールアップや、並べ替えを完全に L1 にアウトソーシングする方法について多くの話題が集まっています。 2 番目の方向は、基本的にソーターを完全に廃止し、外部ビルダーを使用することです。たとえば、イーサリアムビルダーやフラッシュボット SUAVE などは、順序付けされたブロックを提案し、証明者内でコンセンサスを実行します。ここでの利点は、基本的にプロトコル内で PBS を使用でき、より単純なプロトコルが作成されるため、インセンティブに対処する必要がないことです。しかし、欠点は、多数の証明者が必要なため (並列に証明できるため)、それらの証明者を使用して古典的な BFT プロトコルを実行するのが非常に難しいことです。したがって、問題は、既存の BFT プロトコルを、数百、あるいは数千の証明者で実行できるようにどのように最適化するかということです。そして、それは簡単に答えられる質問ではありません。
L2コンセンサスの導入は分散型発注者にとって必要ですか?
ヤオチー
このようなものを最近リリースしたばかりなので、この質問には大まかに答えることができます。
したがって、コンセンサスを導入するかどうかは、私たちが望むか望まないかによって決まるわけではありません。多数の注文者、または単なるノードが存在する場合は、それらの注文者に同意してもらう必要があります。それは本当にあなたの仮定に依存します。それがビザンチンの仮定である場合は、BFT または既存のビザンチン コンセンサス プロトコルを使用できます。たとえば、非ビザンチン設定の場合、ノードはオンラインとオフラインのみであり、悪意のある動作はできないと仮定するだけであれば、Raft プロトコルまたはその他のより高速なコンセンサス プロトコルを使用できます。しかし、とにかく、注文者または証明者のグループがあり、それらをまとめて一定期間にわたってブロックを生成したい場合は、それらを中心としたコンセンサスプロトコルが必要です。
したがって、Toghrul と Abdel が先ほど述べたように、分散型の注文システムや証明システムをどのように実装できるかについては、多くの提案や研究テーマがあると思います。そのため、私たちはマルチソーター ロールアップ システムのテストネットを立ち上げたばかりなので (現在はオプティミスティック ロールアップの不正証明のみをサポートしています)、設計と実装の経験に基づいて、困難について共有できることがいくつかあります。先ほどToghrulさんがおっしゃったように、難しいのはコンセンサスプロトコルそのものではなく、それ以外の部分、例えば証明の部分にあるのです。単一のソーターであれば、多くのノードは必要ないからです。これは EVM、つまり仮想マシンと考えることができます。したがって、トランザクションをフェッチして実行し、状態遷移を行うだけです。証明者は、前の一連のトランザクションの状態遷移の証明を生成する責任があります。ただし、ロールアップ時に照合者と証明者に対してコンセンサス プロトコルを実行する場合は、そこに追加のコンセンサス ロジックを導入する必要があります。これに加えて、コンセンサスプロトコルの証明システムも必要です。したがって、これにより、証明システムが生成する多くの作業が発生します。証明を生成したら、L1 イーサリアムで簡単に検証できます。
これが、私たちが最初のマルチオーダーラー テストネットを立ち上げたとき、ある意味、オプティミスティック ロールアップにはその点でいくつかの利点があった理由です。一般に、有効性証明の部分を考慮しないなど、多くのことを簡素化できます。私たちと同じように、私たちは基本的にすべてを WASM と比較します。つまり、最終的には WASM 命令になります。したがって、これらの WASM 命令を検証することにより、Solidity コードを使用して検証することが比較的簡単になります。すべての WASM 命令解釈を Ethereum 上で再実装した場合。
しかし一般に、問題は単一ではありません。問題の解決策があれば、それに応じて、同時に解決する必要のある他のフォローアップ作業も発生します。もちろん、MEV を公平に配布するにはどうすればよいかなど、MEV の問題はあるでしょう。ブロックを生成したか、ブロックを検証したかに基づいて、すべての順序付け者と証明者を割り当てることができます。しかし、最終的には、技術的な問題だけでなく、経済的なインセンティブも含めた多くの問題が組み合わさったものになります。
そして、ガスコストを大幅に削減したいために L2 が提案されていることを覚えておく必要があります。したがって、それほど多くのノードを持つことはできません。プルーフを生成する場合でも、L2 は L1 よりも高価になる可能性があります。したがって、私たちはこの種の問題に対してバランスの取れたアプローチを考え出す必要があります。
アブデルハミド
もう1点追加させていただきたいと思います。まず、現時点では、楽観的ロールアップに対する実際の許可なしの不正行為の証拠は存在しません。そして、比較する際にはこれについて正直であることが重要であるため、私は機会があるたびにこれを強調し続けています。したがって、それらはまったく L2 ではありません。それが第一です。
次に、並べ替えと証明の間の非同期性について、非常に重要なので追加したいと思います。おっしゃるとおり、現時点ではこれがすべてのソリューションのボトルネックになっているため、並べ替えを最適化したいと考えています。しかし、集中型ソートのコンテキストでは問題ありません。ソーターは値の遷移のみを生成し、それを検証できることがわかっているからです。しかし、分散ソートのコンテキストでは、おそらくソーターが検証できないものを生成する可能性があるため、これはより困難になります。その後、後で対処する必要があります。
集中型並べ替えのコンテキストでは、並べ替えを最適化するために、並べ替えプロセス中にプルーフを生成する必要がないため、ローカル速度で並べ替えを試みることができ、これが私たちがやりたいことです。 Cairo を LLVM などの低レベルの機械語に変換し、ソーター上で超高速に実行します。その後、非同期で証明できます。そして、証明の最も優れた点は、証明を並行して実行できることです。大規模な並列化可能性は、再帰が可能であることを証明することによって達成されます。だからこそ仕分け機のスピードに追いつくことができるのです。しかし、分散型の場合は、順序付け者が有効な状態遷移のみを生成するようにする必要があるため、これは困難です。
選択
Starknet がここで何をしているのかはよくわからないことを付け加えておきます。しかし、私たちにとって、ソーターを分散化する場合、証明システムは無効なバッチを処理できなければならないというのが、すべての zkRollup の一般的な仮定だと思います。したがって、基本的には、たとえば無効な署名を持つバッチを送信した場合、結果の状態が開始時の状態と同等であることを証明できなければなりません。したがって、どちらの方法でもオーバーヘッドが発生します。重要なのは、このようなことが起こる可能性をいかに最小限に抑えるかです。
アブデルハミド
はい、そうです。そのため、すべてを検証可能にするために Cairo 1 に Sierra を導入しました。この中間表現により、すべての Cairo 1 プログラムが検証可能であることが保証され、元に戻すトランザクションを含めることができます。
ベースロールアップとは何ですか?
ヤオチー
ベースのロールアップはもともと、イーサリアム フォーラムの Justin Drake によるブログ投稿から来ました。彼のアイデアの 1 つは、ロールアップ トランザクションを検証するためにいくつかのイーサリアム検証ツールを再利用できるため、さまざまなロールアップ トランザクションを検証するために別個のノード グループを必要としないというものです。特に、将来的には、汎用ロールアップや多くのアプリケーション固有のロールアップなど、多くのロールアップが提供される予定です。したがって、この場合、これらのトランザクションを検証するためのイーサリアムバリデータープールのような共通の場所を見つけることができれば素晴らしいでしょう。
もちろん、これは単なるアイデアであり、多くの技術的な問題も伴います。たとえば、理論的には、ロールアップ トランザクションを検証するためにイーサリアム バリデータを要求することはできますが、ロールアップを検証するロジックをイーサリアム プロトコル自体にバンドルまたは埋め込むことは非常に困難です。これをプロトコル内検証と呼びますが、これにはイーサリアム ノードのハード フォークが必要です。もちろん、この場合、いくつかのロールアップ トランザクションを検証できます。しかし、そうすると問題が発生します。これは、L2 のロールアップにイーサリアムの圧力を共有してもらいたいようなものですが、最終的には、L2 にオフロードされた作業の一部をイーサリアムバリデーターに引き受けるよう依頼します。そのため、多くの人がこれをどうやって実現できるかについて話しています。
次に、イーサリアム財団の研究者で現在 PBS に取り組んでいる Barnabe 氏に話を聞きました。これはイーサリアムの提案で、バリデーターのタスクを構築者と提案者という複数の役割に分割するというものです。現在、PBS でビルダーの役割を担う Flashbot があり、すべてのブロックを構成してイーサリアム提案者に送信します。したがって、これらのブロックがイーサリアムネットワークにパッケージ化されると、構築者はいくつかの報酬も得ることができます。この場合、イーサリアムネットワークからこれらのバリデータに報酬を与えるにはどうすればよいでしょうか?また、ロールアップ検証も担当します。
解決策の 1 つは「再ステーキング」です。これは、EigenLayer やその他のプロトコルでよく耳にしたことがあるかもしれません。ユーザーは他の仕分けネットワークでETHを再ステーキングできます。または、ロールアップの検証作業を行うためにソフトウェアを実際に実行したイーサリアム検証者に報酬を与えます。この場合、L2 と再ステーキング プロトコルの両方から報酬を受け取ることができます。これについてはこれまでに多くの提案がありましたが、一般的には、既存のイーサリアムバリデーターをどのように再利用できるかというアイデアです。既存の ETH を再利用して、ロールアップまたは L2 システムの新時代を迎えるにはどうすればよいでしょうか?つまり、基本的にはロールアップ プロジェクトの多くのことを簡素化しようとしているのです。ロールアップが新しいソーターを必要とする場合、新しい担保ソースが必要な場合は、既存のインフラストラクチャまたは既存の担保を再利用できます。そのため、イーサリアム上に構築されており、さらなるインフラストラクチャとステーキングはロールアップと L2 にも再利用できます。
共有シーケンサーとベース ロールアップの欠点とそのアプリケーション シナリオ。
選択
この提案について文句を言いたいのですが、共有シーケンサに関する提案には納得できません。もちろん、まだ初期段階にあるので、将来的にこれらのデザインが改善されれば、私がそれらをサポートする可能性は十分にあります。ただ、今の形では納得がいきません。理由はたくさんあります。
まず、私にとって、共有ソーターの主な価値提案は、ユーザーが Scroll や Starknet のような汎用ロールアップ間でアトミックな構成可能性を獲得できるようにすることです。しかし、問題は、アトミックな構成可能性がある場合、ロールアップは結合した最も遅いロールアップと同じくらい最終的なものになることです。したがって、Scroll が Optimistic Rollup と組み合わされると仮定すると、Scroll の最終期限は 7 日になります。 ZKRollup の主な価値提案は比較的迅速にファイナリティを達成することですが、ユーザーは数分以内に L1 に撤退できます。そしてこの場合、基本的には諦めてください。
もう 1 つの欠点は、オフチェーンのファイナリティが必要な場合は、L2 ノードを実行する必要があり、チェーンに送信されたデータが L1 によってファイナライズされる限り、L2 でローカルにファイナリティが得られることです。結合された各 L2 が完全なノードを実行しない場合、ローカルでのファイナライゼーションを達成することは事実上不可能です。これは、複数のフル ノードを同時に実行し、それぞれ独自のオーバーヘッドなどがあるため、このシステムの実行は Solana のようなシステムを実行するよりもコストが高くなる可能性があることを意味します。
これらの理由から、L2 については意味がないと思います。 L3 の場合は少し異なります。アプリケーション固有のチェーンを構築したいが、分散化には対処したくない場合です。私がゲームを構築していて、ゲームの構築だけを処理したいとします。その後、分散作業をアウトソーシングできます。しかし、現時点ではL2については意味がないと思います。
ベースロールアップに関しては、私も懸念しています。たとえば、MEV の利益を証明者とどのように共有しますか?なぜなら、配分の問題を考慮しなければ、基本的には L1 がすべての MEV 利益を得ることができるからです。もう 1 つの小さな点は、その確認時間が L1 の確認時間 (12 分) と同じであることです。これより速いことはありません。もう 1 つの問題は、パーミッションレスであるため、複数の Seeker が同時にトランザクション バッチを送信でき、結果が集中化される可能性があることです。なぜなら、ある検索者が他の検索者よりも簡単に接続できる場合、ビルダーはトランザクションを含める動機になるからです。したがって、最終的には 1 つの Seeker だけが L2 のバッチを提案することになる可能性がありますが、これはあまり良い解決策ではありません。これが発生すると、基本的に振り出しに戻ることになるからです。
ヤオチー
興味深いことに、私は実は先週、Espresso の創設者である Ben と電話したところです。これについては、共有ソーターのトピックでよく議論します。 Toghrul さんがおっしゃったように、共有発注システムの利用シナリオについては不確実性があると思います。これは主に、汎用 L2 の場合、効率、複雑さ、経済性を考慮して、通常は多数のソーターを備えていないためです。そして、共有シーケンサー、ベースのロールアップ、またはレストテイクのいずれであっても、最良の使用例は主に RAS (Rollup as a Service) など、大量のロールアップをロールアウトできるプラットフォームであると私は今でも感じています。正直に言うと、ロールアップがそれほど多くない場合、大規模な並べ替えネットワークは必要ありません。これらのロールアップには、汎用 L2 がいくつかしかない場合、すでに独自のソーター システムがあり、独自のコミュニティまたはパートナーが存在します。実際には、別個のサードパーティ ネットワークを持つ必要はありません。また、L2 ごとにカスタマイズする必要があり、L2 ごとに異なるテスト スタックがあるため、これはサードパーティ ネットワークにとっても負担になります。これには、独自のネットワークに多くの変更を加える必要があります。
しかし同時に、Toghrul 氏が述べたように、いくつかの特殊な使用例でも同様です。たとえば、ソーター レベルで相互運用性を確保したい場合は、共有ソーターが有力な手段となる可能性があります。たとえば、複数のロールアップに同じソーターが使用されます。この場合、このソーターは基本的にいくつかのクロスロールアップ トランザクションを処理して、ロールアップ A、B、C 間のクロスチェーン アトミック性を確保できます。
しかし、状況を説明すると、ここにも問題があることがわかります。実際にこれらの共有シーケンサーが多数存在する場合、それらは再びボトルネックとなり、新たな単一障害点となるでしょう。私たちはこれらのいわゆる共有発注者に過大な権限を与えすぎています。それらはよりネットワークに近くなり、多くのロールアップを制御します。最後に、この共有ソーターを分散化する方法を再度考え出す必要があります。
とにかく、人々が徐々により多くの問題を発見し、より多くの解決策を考え出すのは良いことだと思います。全体として、この分野の最新情報を毎日見るのはとても楽しいです。これらすべての新しいソリューションにより、少なくともロールアップ スペース全体を真に分散化する正しい軌道に乗っています。
アブデル
はい、お二人の意見に同意します。 Layer3 と Lisk にとっては、分散型ネットワークを奨励する責任をもう負いたくないので、ソーターなどを開始するパートナーを見つける必要があるため、これはより理にかなっていると思います。したがって、Liskにとって、それは理にかなっていると思います。しかし、Toghrul と同様に、Layer2 にとってはまだあまり意味がないと思います。
トピック 4
分散型発注者は MEV にどのような影響を及ぼしますか?
アブデル
Starknet の場合、一元化の観点から、いかなるタイプの MEV も実行せず、先着順モデルを採用します。つまり、分散化の文脈では、当然、後でさらに多くの MEV が導入されます。しかし、それはコンセンサスメカニズムの設計やその他の側面にも依存するため、どの比率であるかを言うのは時期尚早です。
選択
しかし問題は、たとえ MEV を行わなかったとしても、Starknet ではまだ MEV が行われている可能性があるということです。まあ、分散化自体は実際には MEV を減らしたり増やしたりしません。もちろん、たとえば、ある種の公平な順序付けプロトコルやしきい値暗号化を適用すると、はい、MEV が最小限に抑えられます。しかし、それを完全になくすことはできません。私の哲学は、「MEV を排除することはできない」です。しかし、BFT コンセンサスを作成しているだけ、または BFT コンセンサスの上に何かを構築しているとします。これは実際には MEV にはまったく影響しません。 MEV はまだ存在しますが、サーチャーがソーターとどのように連携してその MEV を抽出するかが問題となります。
ヤオチー
問題は、先着モデルにも難しい部分があるということです。メンプールを一部のシーカーに公開しても、彼らにはさらにプレイできる利点があります。たとえば、シーケンサーの場合、オフィスのドアの前で待っているのと同じです。したがって、この場合、フロントランニングやサンドイッチ攻撃だけでなく、何らかの裁定取引の機会を見つけると、ユーザーがトランザクションを送信するとすぐに、それをメモリプール内ですぐに確認できます。そのため、他の人よりも早く取引を行うことができます。したがって、彼らは他の検索者よりも有利です。
しかし、分散化の話に戻りますが、最初に議論したように、それは主に検閲への抵抗に関するものだと思います。シーケンサーはチームによって管理されます。チームは誰に対しても公平であることがわかります。しかし、これはコードでは防止できません。したがって、P2P ネットワークができれば、これらのノードが私のトランザクションを精査し、他のノードに送信できるようになれば素晴らしいでしょう。したがって、実際には、L2 でのトランザクション処理の公平性が重要になります。
MEV に関しては、最近では、単一のロールアップ内で生成される MEV に加えて、ブリッジを越えて生成される MEV もいくつかあります。この比較的分散化された分類ネットワークでは、MEV を抽出する機会がさらに多くなります。共有注文ネットワークがあると仮定すると、共有注文者に何らかの影響を与えてトランザクションを再注文することができれば、基本的に他の人よりも大きなアドバンテージが得られます。
共有シーケンサー ネットワークには利点と欠点があります。プラスの面としては、ランカー システムをさらに分散化できることです。しかし、裏を返せば、誰もが仕分け人になるチャンスがあります。つまり、彼らは基本的にやりたいことを何でもすることができ、再び暗い森になります。そこで、分散化を導入しましたが、イーサリアムで直面したのと同様の問題に直面する必要がありました。だからこそ、Flashbot とイーサリアム財団の人々は PBS を進め、提案者と構築者を分離し、構築者側で単一のソリューションを用意しようとしているのです。
したがって、問題に目を向けると、それは単一の問題ではありません。それはもはや 1 対 1 の問題ではなく、1 対 6 などの問題です。