Rollup の分散化への道の解釈: イーサリアムに基づく共有ソートとジレンマ

原作者：Taiko Labs

オリジナル編集: Deep Chao TechFlow

重要なポイントのまとめ

ロールアップ中心のロードマップにより、ブロックチェーンの断片化と分離が生じました。この断片化により、ロールアップ間での値の転送ができなくなります。この問題を解決するために、Espresso、Astria、Radius などの共有並べ替えメカニズムが登場しました。ただし、そのような層には独自のセキュリティ セットが必要なため、このソリューションには本質的に新しい信頼の前提が必要です。

ロールアップ用の共有順序層を構築したい場合、イーサリアムは構築または使用できる最も信頼できる中立層です。イーサリアムに基づくロールアップ (つまり、ベース ロールアップ) は、本質的にイーサリアムおよび他のベース ロールアップと完全に組み合わせることができます。ただし、Based Rollup ソリューションにはいくつかの課題もあります。最も重要な課題は、ブロック時間がイーサリアムと同じで 12 秒に制限されていることです。解決策は、集中シーケンサーなどの高速確認メカニズムを提供するか、イーサリアムのブロック時間を短縮することです。テストネットでは、事前確認に基づく速度が現在の集中シーケンサよりも高速です。

交差点

記事の冒頭を振り返ると、イーサリアムが選択する方向性は非常に重要です。イーサリアムは設立当初から分散化を最優先事項として受け入れてきました。この優先順位により、ユーザー エクスペリエンスにいくつかの制限が生じます。これらの制限は、分散分散システムの設計の課題 (グローバル状態の処理、逐次実行など) から生じています。これがイーサリアムと他の L1 の違いです。彼らは異なる道を選びました。他の L1 は、分散化をある程度犠牲にして、高速かつ安価であることを選択します。これらは実績のある歴史、より大きなブロック サイズ、並列処理により高速かつ安価です。これらの概念により、高速かつ安価なトランザクションが可能になりますが、バリデーターの負担も増加します。これが、他の L1 バリデーターがイーサリアムよりもハードウェア要件が高い理由です。

イーサリアム自体が履歴の有効期限、ステートレス、Verkle ツリーなどのアップグレードを通じてスケールするまで、タスクはロールアップに任せます。

4 年前、イーサリアムはロールアップ中心のロードマップを採用し、改善が得られるまでよりユーザーフレンドリーな環境にするために実行をアウトソーシングしました。このおかげで、イーサリアム全体で 1 日平均 250 TPS を達成しました。

ロールアップ.wtf

前述したように、イーサリアムがロールアップ中心のロードマップを採用することを決定してから 4 年が経過しました。この期間中、イーサリアム自体がどうあるべきかについて、L2 上で多くの実験が行われていました。 AltVM (Fuel、Fluent)、zkVM (Aztec、Starknet)、zkEVM (Scroll、Linea、zkSync)、パラレル EVM (MegaETH) など。これらはイーサリアムの将来のアイデアを提供します。しかし、それらはまた、互いに接続すらしていない多くの独立したブロックチェーンも作成します。これが、断片化の問題を解決するために共有順序層が登場した理由です。

共有並べ替えレイヤー

現在、Rollup には集中型シーケンサーがあります。これにより、重大な検閲、生存性、および MEV 抽出のリスクが生じます。 Rollup が分散化したい場合は、注文者を共有することを選択できます。共有オーダラーを使用することにより、Rollup はファイナリティ、分散化、高速トランザクション、クロスチェーンの原子性を活用できます。 Vitalik 氏が述べたように、「分散型ロールアップには、新しい L1 の開発に労力の 90% が必要です。」したがって、共有シーケンサーを選択することで、分散型エンジニアリングの労力が回避されます。

共有ランキング層は基本的に、ロールアップに参加するランキング権を単一のシーケンサー ネットワークに接続する層です。この層は、(コンセンサス プロトコルの設計制限内で) 誰でも参加できる BFT などのコンセンサス プロトコルを実行します。したがって、複数のロールアップには、トランザクションの順序を決定する共通のメカニズムがあります。このメカニズムは、参加するすべてのロールアップ間で高速な L2 ファイナリティと構成可能性も提供します。

共有ソート レイヤーはソーターのマーケットプレイスです。この市場では、Rollup はブロック スペース (およびプロポーザル権) をスロットごとに上位入札者に販売できます。これにより、参加するすべてのロールアップ間で MEV を再配布するレイヤーも作成されます。

集中

共有順序層には、アトミックな構成可能性と、参加するすべてのロールアップ間での共有 MEV を作成するネットワーク効果があります。ロールアップはネットワークに参加して、(注文者を分散しながら) ブロックの価値を高めます。

ただし、共有シーケンサーのシステム設計によれば、参加するロールアップの数はできるだけ多くする必要があります。参加しているロールアップ X がチェーンから離れると、この MEV 配布が中断され、ネットワーク効果に直接影響します。したがって、共有ソートは、参加者が常にゲームに留まらなければならない終わりのないゲームです。 Rushi さんが言ったように、これは純粋な B2B モデルです。

共有注文層は、共有注文者市場と並行して BFT などのプロトコルを実行して、高速な L2 ファイナリティを達成し、誠実性の仮定を導入します。バリデーターの半数が正直であることを前提としています。何らかの理由でバリデーターの半数がオフラインになったり不正な場合、チェーンはアクティビティを失う可能性があります (ブロックチェーンに基づくフォールバック スキームを使用できます)。 BFT プロトコルがアクティビティを失うと、参加しているロールアップは BFT プロトコルからファイナリティ認定を取得する必要があるため、高速ファイナリティを利用できなくなります。この層からの出金も一時停止されます。ただし、BFT プロトコルがクラッシュしても、たとえば Espresso では MEV の再割り当てが BFT プロトコルから分離されているため、MEV の再割り当ては続行されます。比較すると、イーサリアムは、暗号経済のセキュリティとアクティビティの点で常に最強の BFT プロトコルです。

さらに、多額の担保を利用する場合には、多額の担保が適用されるリスクもあります。バリデーターのハードウェア要件が高い場合、独占につながります。再ステーキング サービスが失敗した場合、大規模なスラッシュが発生する可能性もあります。詳細については、Eigenlayer のリスク FAQを参照してください。共有シーケンサーにおける再担保アプローチについては、Nethermind と Fourpillar による共同研究を参照してください。

共有シーケンサーが事前確認を使用することを考慮すると、このプロセスは L1 で (つまり、事前確認に基づいて) 実行できるため、新しい層の必要性がなくなることに注意することが重要です。また、共有シーケンサーは引き続き L1 パイプを経由する必要があることにも注意してください。したがって、「迅速なファイナリティ」はここでは意味がありません。

結論として、共有シーケンサー層が分散化されておらず堅牢でない場合、それらは単一障害点になると考えられます。これらは、オプトイン ロールアップの中で最も弱いリンクになります。

ニュートラルな構成可能性はもはや冗談ではありません。ベースとなる必要があります。

前述したように、イーサリアムはさまざまなアプリケーションを構築するための最も信頼できる中立層です。 Rollup は、バッチとプルーフをイーサリアムに送信し、イーサリアムをデータ可用性レイヤーとして利用することでこれを実現します。現在、ほとんどのロールアップは集中シーケンサーによって管理されており、すべてのトランザクションはロールアップ チームによって順序付けされています。これらのチームの中には、アステカのFernetなど、ネットワークを分散化する方法の設計に今も取り組んでいるチームもあります。多くのエンジニアリング リソースを費やさずにネットワークを分散化する別の方法、それはランキングベースのアプローチです。

Taikoは、イーサリアムを注文レイヤーとして使用する最初のベースド ロールアップです。ブロックの構築は完全にイーサリアムに依存しています。誰でもブロックを提案でき、そのプロセスは完全に許可を必要としません。各ロールアップは、新しいレイヤーを追加するのではなく、イーサリアムに基づいて構成可能です。 Ethereum と Based Rollup のスロットは同期して移動するため、相互に完全な互換性があります。これは、L1 でフラッシュ ローンを実行し、同じスロットでベース ロールアップで何らかのアクティビティを実行できることを意味します (BBR 設計のおかげで、詳細は こちら)。ただし、イーサリアムベースのアプローチにはある程度のコストも伴います。

出典: L2ビート

この問題については「事前確認を踏まえたロールアップセンターの考え方」でも触れましたが、簡単にまとめてみましょう。前述したように、Based Rollup のブロック時間はイーサリアムと同じ 12 秒です。これは、Based Rollup が 12 秒ごとに BLOB (または calldata) 経由でデータを L1 に送信する必要があることを意味します。 L1 料金をカバーするのに十分な L2 トランザクションで BLOB を埋めることができない場合、損失が発生します。これをユーザーに転嫁しないために、当初は自分たちでコストを負担し、多額の費用を費やしました。現在、提案者は収益性を達成するためにブロック時間を 12 秒 (約 20 秒) を超えています。

これらは、Based Rollup がTaiko の例を通じて経験した困難の例です。要約すると、主な問題はブロック時間と基本料金の収入制限であり、集中注文者ではありません。ソートは完全に許可を必要とせず、MEV は完全にイーサリアムに流れ、トランザクションから価値を取得できないため、収益が犠牲になります ( Spire Labs は、Based Rollup を改善するフレームワークに基づいた収益モデルを開発しています)。

ユーザー エクスペリエンスとブロック時間の問題を解決するには、次の 2 つのオプションがあります。

• 事前確認に基づき

• L1 でのブロック時間の短縮

事前確認に基づいて

いくつかの L1 バリデーターを使用して、事前確認に基づいて L2 ユーザーに事前確認を提供するだけです。現在 Helder テストネットで正常に実行されており、事前確認に基づいて Taiko で超高速トランザクション (Gattaca のデモでは 20 ミリ秒、Arbitrum では約260 ミリ秒) が可能になりました。

Titanをベースにした事前確認デモ

事前確認では、イーサリアムのすべての稼働性とセキュリティを継承するわけではありません。 Ethereum バリデータ セットのサブセットのみを信頼します。しかし、ここで言及する価値があるのは、現在のイーサリアム提案者から信頼できるコミットメントを得ているということです。登録された契約に一定量のETHをステーキングすることで、誰でも事前確認プロバイダーになることができます。事前確認の詳細については、以前のブログ投稿で説明しました。こちらを参照してください。

事前確認ベースのスペースはまだ初期段階にあり、発展段階にあります。イーサリアムブロック構築の集中化などのいくつかの脅威に直面していますが、新しい手法と研究により、より合理的なアーキテクチャが設計されるでしょう。事前確認済みのデザインを近日中に共有する予定です。

より速いブロック?

イーサリアムをよりユーザーフレンドリーにすることに抵抗できる人は誰もいません。最終確認の高速化、ブロック時間の短縮、トランザクション処理の高速化は、ベース ロールアップにとって最も好ましいシナリオです。前述したように、ベース ロールアップになるための唯一の障害は L1 ブロック時間です。 L1 ブロックが高速であるということは、Based Rollup ブロックが高速であることを意味します。

より高速な L1 の主なアイデアは、本質的にスロット時間を短縮できるコンセンサス メカニズムを採用することです。シングル スロット ファイナリティ(SSF) は検討中のコンセンサス メカニズムであり、特にOrbit SSFでは各スロットを数秒でファイナライズできます。現在の Gasper プロトコルでは、最終確認時間は 2 サイクル、つまり 13 分です。ただし、SSF の欠点は、33% の不活性リークの影響を受けやすいことです。

ここでの主な疑問は、より高速な L1 が常に必要である場合、なぜ Rollup に費やした 4 年間のエンジニアリング努力が L1 自体の高速化に使用されなかったのかということです。私たちは Rollup に多大な研究開発努力を注ぎ、さまざまなアプローチを実現しました。現在、ブロック時間の短縮が実現したとしても、開発には最大 2 ～ 3 年かかるでしょう。

イーサリアムは非常に明確な道を選択しました。この道は、分散化に関して一切の妥協を許さず、「個人の利害関係者」には一切触れないことを意味します。明らかに、ブロックを高速化するにはイーサリアムのコンセンサスを変更する必要があり、そのような変更により配布されるバリデーターが現在よりも少なくなるでしょう。これはイーサリアムコミュニティにとって重要な決定です。

結論は

Rollup の開発と普及に伴い、断片化と分離が深刻な問題になりました。したがって、Based Rollup になることと、共有ソーター レイヤーを追加することは重要な違いです。共有順序層は、迅速な最終確認とクロスチェーンの構成可能性のために使用できますが、新しい信頼の前提が必要であり、失敗してネットワーク効果が失われる可能性があります。 Based Rollup は、イーサリアムの既存のインフラストラクチャをブロック構築に利用しますが、ブロック時間と収益モデルの点で課題に直面しています。それにもかかわらず、その機能を通じて流動性の断片化に対する解決策を提供し、L1 と完全に組み合わせ可能です。

今後の解決策は、Based Rollup の欠点を克服するための、事前確認と L1 ブロック時間の高速化に基づく新しいソリューションにあるかもしれません。これらの目標は、イーサリアムの連携を損なうことなくユーザーエクスペリエンスを向上させることです。私たちの目標は、イーサリアムのビジョンに忠実な、スケーラブルで分散型のユーザーフレンドリーなエコシステムを作成することです。

イーサリアムに基づくかどうかの選択は、単なる技術的な決定ではなく、分散型ロールアップ「フレームワーク」の方向性に関するものです。