元のタイトル「私たちはみんな同じものを築いている」を転送

紹介

この投稿は、以下を分析しています

• 非同期実行-高性能統合ブロックチェーン（例：ソラナそしてモナド実行を合意から切り離し、順序付け（シーケンシング）から切り離します。
• レイジーシーケンシング - 彼らはレイジーシーケンサーのデザインをミラーリングする方法（例：、@astriaorg/hj6ccpp9t">astria)です。
• イーサリアムL1およびベースのロールアップでの事前確認 - 事前確認
• ベース対非ベース-ベースロールアップ+事前構成対非ベースロールアップ+基本レイヤーフォールバックを比較する。
• ユニバーサル同期コンポーザビリティ - 共有シーケンサーからのアトミックインクルージョン+暗号化セーフティ（例：AggLayerおよび/またはリアルタイムの証明)。
• 高速ベースロールアップ - ベースロールアップは単に高速なベースレイヤーを持つべきです。
• タイミングゲーム -時間はお金ですそして、それがソラナ対イーサリアムの相違するエンドゲームの根底にある方法です。
• 検閲耐性のための分散化 - どのようにアテスター・プロポーザーの分離経由実行オークション分散化された検証者を保護し、検閲抵抗力を強化することができます。インクルージョンリスト.

最後に、そして最も重要なことに、なぜ私たちは見るのかを見てみましょう私たちはみんな同じくそったれのものを作っているだから、たぶん私たちは単に...

状態マシンレプリケーション（SMR）の最適化

基本から構築して、高性能ブロックチェーンの最終目標を見ていきます（例えば、Solana、モナド、@patrickogradymitigation-strategy-enable-profit-maximizing-builders-to-minimize-invalidtps">hypersdk) approaches that of a怠惰なシーケンサー (e.g., @astriaorg/hj6ccpp9t">astria). それから、後でそれらをイーサリアムベースのロールアップとプリコンフスと比較します。

シーケンシング対実行

ブロックチェーンは複製された状態マシン分散ノードは、システムの状態の各自のコピーを保持し、更新します。チェーンを進めるために、ノードは現在の状態+新しい入力（例えば、新しいトランザクション）に対して状態遷移関数（STF）を実行します。これにより新しい状態が生成されます。

このセクション全体で以下の用語を使用します:

• 構文的に有効 - トランザクションは適切なトランザクション構造と署名を持つ正しい形式で構成されています。
• 意味的に有効-トランザクションは有効な状態遷移を行います（たとえば、必要な手数料を支払います）。
• シーケンス-データの順序と含まれる内容を決定する。
• 実行 - データを解釈し、stfに従って行動する。
• ブロックを構築し、ローカルに保存されているトランザクションからブロック（または部分的なブロックチャンク/シュレッド）を作成します。
• 検証-ブロック（または部分ブロックチャンク/シュレッド）の必要な構文および/または意味の検証を実行します。
• 他のバリデータにブロック（または部分ブロックチャンク/シュレッド）を複製して配布する。

シーケンスと実行に焦点を当ててみましょう。なぜなら、これらがチェーンの状態を計算するために必要な中核サブタスクだからです。

さらに、ノードはデータを検証し、ネットワーク全体でデータを複製します。ノードはコンセンサスに達し、チェーンの一貫したビューを維持します。

ただし、異なるチェーンアーキテクチャは、これらのタスクを担当する責任者とそのタイミングが意味のある意味で異なります（例えば、ブロックの構築と検証に実行が含まれる場合と含まれない場合があります）。フルのエンドツーエンド時間ステートマシンレプリケーション（SMR）ループはシステムの遅延の下限を決定します。異なる構造は非常に変動する時間を生み出すことができますので、効率的なsmrプロセスはパイプラインこれらのタスクは低レイテンシと高スループットのパフォーマンスに必要です。

以下のセクションでは、効率的なパイプライン化の核心的な洞察は、実行結果ではなく実行入力に対する合意を達成することに焦点を当てることです。これには、含めることができるトランザクションに関して一部の制約を緩和する必要があります。そして、システムが有用で攻撃に対して強靭であることを保証するために、いくつかのより弱い制約を再導入する必要があります（たとえば、手数料を支払わないトランザクションからのdosベクターを回避するなど）。

伝統的なSMR

従来のSMR（例：イーサリアム）は、シーケンシングと実行を密接に結びつけています。フルノードは、ベースレイヤートランザクションを連続的にシーケンス化および実行する必要があります。ノードがコンセンサスに到達するための前提条件は、両方の操作が必要です。すべてのブロックデータが利用可能であることを検証するだけでなく（およびシーケンス化する）、ノードはブロックを実行して検証する必要があります。

• すべてのトランザクションは構文的にも意味的にも正当です
• 新しい状態の計算はリーダーによって提供されたものと一致します

バリデータは、その状態を独立して検証した後、ブロックに投票し、その上に構築します。これは、合意に達するまでに少なくとも2回実行されることを意味します（つまり、ブロックプロデューサーが構築中に実行され、受信バリデータが再度実行して検証します）。

この伝統的なモデルでは、ビルディングと検証の両方が実行を含んでいます。

source: @patrickogrady/rys8mdl5p#デカップル状態マシンレプリケーション（DSMR）のケースを作成する

ストリーミングSMR

ストリーミングsmr（例：solana）は、パイプライン処理の効率的な形態です。ブロックプロデューサーは、連続してブロックの断片を「ストリーム」します(called シュレッドまた、ブロックが構築される際に、ノードは（実行を含む）これらの断片を連続的に受信し、検証します。これにより、次のリーダーは自分のブロックの構築をより早く開始できます。

source: @patrickogrady/rys8mdl5p#分離された状態マシンレプリケーション（DSMR）の強化：vryx

このストリーミングモデルでは、構築と検証の両方には、シーケンスと実行が含まれています。これにより、すべての含まれているトランザクションが意味的にも文法的にも有効であるという制約を緩和せずに、従来のSMRに比べてSMRの効率が向上しています。

非同期実行

統合アプローチ

今、それらの制約を緩和すれば、さらに良いパフォーマンスを得ることはできるのでしょうか？

非同期実行は、コンセンサスのホットパスから実行を削除します。ノードは、データの実行を先に行わずに、データの順序について合意します。これはより効率的であるため、そうするのです。ソラナとモナド両方の計画は非同期実行を実装する予定です。

リーダーは、実行せずにブロック（またはシュレッド）を構築し、複製することができます。その後、他の検証者も実行せずにそれに投票します。ノードはトランザクションの順序と利用可能性についての合意にのみ到達します。これは十分です。なぜなら、決定論的なSTFが与えられた場合、誰もが最終的に同じ状態を計算するからです。実行は合意を待つ必要はありません-非同期で実行できます。これにより、ノードの実行予算が開放され（実行に費やす時間が増える）、必要なステップ（および時間）が減少します。

順序が真実を決定します。実行は単にそれを明らかにします。順序が確定した後、誰でもデータを実行して真実を明らかにできます。

だからおそらくキオネは、結局のところ、すべてのブロックチェーンが非同期実行を利用すると信じています。、そしてそれは重要な部分ですTolyのSolanaに対する最終目標ビジョン:

同期実行には、投票およびブロックの作成を行うすべてのノードが、どのブロックでも最悪の実行時間に対応するために過剰に用意されている必要があります... 合意ノードは投票する前に少ない作業を行うことができます。 作業はaggreGate.iodされてバッチ処理され、キャッシュミスなしに効率的に実行されます。 それは合意ノードやリーダーとは別のマシンでさえ実行できます。 同期実行を希望するユーザーは、ネットワークの残りを待たずにすべての状態遷移をリアルタイムで実行するために十分なハードウェアリソースを割り当てることができます。

現在、バリデータはブロックごとに可能な限り高速にすべてのトランザクションを再生し、ブロックの完全な状態が計算された後にのみ投票します。この提案の目的は、フォークに投票する決定をブロックの完全な状態遷移から分離することです。

重要なのは、私たちもユーザーが真実を簡単に知ることができるようにすることであり、それは軽量クライアントの堅牢なサポートを意味します。実行を大幅に遅らせるいくつかのデザインは、これを困難にする可能性があります（例：Solanaはエポックごとに1回だけ必要とすることを検討しています) vs. 他の一部のプラットフォームでは、状態ルートをより短い遅延で提供します（たとえば、ハイパースディーケーのように）。

モジュラーアプローチ

シーケンスと実行の切り離しが非常に馴染み深いと聞こえるのは、これが「モジュラー」アプローチであるためです！さまざまなタスクに特化したさまざまなレイヤーをミックスしてマッチさせます。シーケンスと実行の切り離しは、怠惰なシーケンサー（例：astria）の主要な設計原則です。

• シーケンシング-シーケンサーノードは、ロールアップデータの順序と可用性についてのみ合意します（つまり、シーケンスを作成しますが、実行はしません）。
• 実行 - ロールアップノードは、シーケンサがそれにコミットした後に、それぞれのデータを実行します。

ここでの主な違いは、統合されたチェーンノードがシーケンシングの後に実行されることであり、怠惰なシーケンサーはそれを完全に異なる多様なアクターのセットにプッシュします。怠惰なシーケンサーは、ロールアップの状態マシンを完全に無視します。彼らはこれらのトランザクションを実行しません。ロールアップは非同期実行を処理します。

統合アプローチは、実行環境のユーザー間のよりシームレスな相互運用性を提供しますが、アプリ開発者（例：カスタムVM、異なるスロット時間など）に対して柔軟性を方向性で低下させます。コンセンサスに基づくアプリ固有のトランザクションの価格設定と注文ルール, などモジュラーアプローチは、開発者がカスタマイズされたドメインを所有するために、より柔軟性と主権を提供しますが、それらの間で統一したエクスペリエンスを得ることは難しいです。

どちらの場合でも、データを注文するための本当に大きくて高速なパイプが必要です:

ただし、技術的には、遅延シーケンサとしてほぼすべてのチェーンを使用できることに注意する必要があります。結局のところ、それはただの大きなデータパイプにすぎません。ロールアップは、任意のデータを選択したベースレイヤー（イーサリアム、ビットコイン、モナドなど）に投げて、シーケンサとして暗黙的に使用することができます。ロールアップノードは、その後に非同期的にデータを実行できます。

実際の違いは、実際に「怠惰なシーケンサー」と呼ぶチェーンがこのタスクに特化していることですが、これは言うほど簡単ではありません（例：必要なトランザクションタイプのサポート、簡単なインターフェースの公開、MEVインフラの実装、高速なスロット時間、信頼性のあるトランザクションの含有、高帯域幅など）。その結果、統合チェーンのノードは最終的に含むデータのほとんどを実行し、怠惰なシーケンサーはそれを主にロールアップに任せます。

だから、「なぜSolana（またはそれ以外のチェーン）を単なるロールアップシーケンサーとして使わないのか？」というのはそう簡単なことではありません。

• ロールアップ専用に設計された必要なMEVインフラストラクチャが不足している(例:必要なPBSインフラストラクチャ、クロスチェーン相互運用性メカニズム、ベースレイヤーガストークンでロールアップユーザーの料金支払いを抽象化するコンポーザーなど)
• ロールアップ用に設計されたネイティブトランザクションタイプが不足しており、データの投稿ができません。
• ネイティブ実行環境と競合する（例：提供されるデータを可能な限り消費するように明示的に設計されているため、信頼性の高いトランザクションの含有率が低くなるなど）
• 一般的な開発者サポートとアップグレードの優先順位付けをめぐって競合しています。おそらく、コミュニティのほとんどがロールアップをちょっと馬鹿げていると思っているプロトコルよりも、ロールアップの立ち上げを支援し、特にあなたを念頭に置いてプロトコルを設計することを専門とするプロトコルとチームに行く傾向があります。

強化されたデカップルSMR

さて、これらの制約を緩和することで発生する問題に取り組むことができますか？ 簡単に言えば、はい、単純な実装では無効なトランザクションの手数料を支払えない問題（単純な実装ではdosベクトルになる可能性があります）などの問題が発生しますが、これらの問題は解決可能です。

ここでは細かいことにはあまりこだわりませんが、参照できますパトリック・オーグラディの素晴らしい仕事@patrickogrady/rys8mdl5p#デカップル状態マシンレプリケーション（DSMR）のためのケースを作ること">vryxを強化するために、tolyの非同期実行エンドゲーム、とMonadの運賃負担の実装これらの問題に対処する方法。繰り返しになりますが、これらの問題に対する解決策は、当然のことながら、モジュール側と統合側の両方でほぼ同じように見えます。

要するに、同期実行と完全検証と比較してかなり弱い制約を再導入することができます。これにより、ほとんどの性能上の利点を維持しつつ、攻撃の余地を残さないようにします。

プロトコル内 vs プロトコル外のアクター

重要なことは、上記のプロセスは素朴にプロトコル内のアクターしか考慮していないことを認識する必要があるということです。実際には、プロトコル外のアクターは、これらのトランザクションのサプライチェーンで大きな役割を果たしています。これは、従来のSMRの(プロトコル内の)バリデーターについて以前に見たものです。

ソース：@patrickogrady/rys8mdl5p#making-the-case-for-decoupled-state-machine-replication-dsmr">vryx: 分離されたステートマシンのレプリケーションを強化する

実際には、ほとんどすべてのイーサリアムの検証者は、MEVブーストを介してブロックの構築を外部委託していますトップ3のビルダー（ビーバー、タイタン、rsync）がほとんどのこれらのブロックを構築していることに注意してください。ビーバーとrsyncはOFAC取引を検閲していますが、タイタンは検閲しません。

ソース: mevboost.picsさん

リレーは、これらのブロックをネットワークの残りに複製することを担当します。また、上位4つのオペレーター（超音波、bloxroute、agnostic、およびflashbots）は、ほとんどのブロックをリレーしています。bloxrouteとflashbotsはofacトランザクションを検閲しますが、agnosticとultra soundはそうしません。

ソース:mevboost.picsさん

ここでも、私たちが前述したように、レイテンシー最適化のトレンドは非常に類似していることが驚くべきではないということがわかります。トレンドは〜に向かっています。楽観的なリレーブロックの複製前にブロック検証を行わなくなったため、それが単に高速になったからです。怠惰なシーケンサーは、インセンティブ付きリレーネットワークと見なすことができます。

これらの例は、MEVがこれらのシステムにおける利益のインセンティブを歪める方法を示しています。バリデータはブロックの製造を外部委託します。なぜなら、洗練されたビルダーの方が単純なシーケンスされたブロックよりも価値をより多く捕捉できるからです。

非同期実行でも、価値を最大化するために、ビルド中にトランザクションを実行するプロトコル外のブロックプロデューサーがいることがよくあります。たとえば、怠惰なシーケンサーには、何らかの形のPBSで利益を最大化するビルダーがある可能性が非常に高いです。外部ブロックプロデューサーは、ブロックの値を完全に実行して最適化するように常にインセンティブが与えられているという事実は、非同期実行の制約を緩和する設定で実際に役立ちます。それでも、他のバリデーターは投票前に再実行する必要はありません。

ユニバーサル同期コンポーザビリティ

定義

今、モジュラーチェーンが提供する主権と柔軟性を得ることができますが、それらを統合されたチェーンのように感じさせることはできますか？ケーキを手に入れて食べることはできますか、それとも単に余分なステップを踏んだ Solana を構築することになりますか？

ロールアップの断片化修正について人々が話すのを聞くと、おそらく大きなバズワードについて聞いたことがあるでしょう。ユニバーサル同期コンポーザビリティ（USC）。 ただし、おそらくこれがあなたの反応でした:

これらの用語はすべて異なる意味で使われ、一部の用語はしばしば誤って同じ意味で使用されます。私たちは具体的な定義を設定する必要があります。以下に、クロスチェーン相互運用の文脈で必要な用語を定義します。

このレポートの残りでは「ロールアップ」について説明しますが、バリディアムなどの他のタイプの「L2」にも同じコンセプトが適用されます。注意してください。再びL2とは何かをめぐって戦いたくないだけです.

次の例では、

• r_ア= ロールアップする
• r_b= ロールアップ B
• t_a1= r上のトランザクション1_ある
• t_B1のrにおけるトランザクション1_b
• b_a1 = ブロック1 on r_ある
• b_b1= ブロック1 on r_b
  

ここで「時間」という用語は「スロットの高さ」と定義されることに注意してください。時間は観察者に対して純粋に相対的です。唯一の客観的な時間の概念は、共有の観察者による相対的な順序付け、つまり共有の合意（「合意」が単一のアクターまたは分散型のメカニズムである場合がある）です。

両方のロールアップには、順序付けを提供するコンセンサスメカニズムがある場合、私たちは主張することができます:

• b_a1bの前です_a2
• b_b1bの前です_b2

しかしながら、主張する唯一の方法は:

• b_a1同時にbにいます_B1の、したがって
• t_a1と t_B1の同期して発生することがある場合
• それらは、指定されたスロットのための共有された合意によって提供される順序を共有しています。

したがって、クロスチェーン同期コンポサビリティの定義上は、そのスロットの高さに共有シーケンサーのいずれかのタイプが必要です。それを持たないチェーンは、常に非同期のコンポサビリティしか持つことができません。

ただし、非同期原子的組み合わせ可能性もあることに注意してください。残念ながら、私はしばしば人々が「原子的」と「同期的」を同じ意味で使っていることに気付きますが、実際には異なる用語です。

それを片付けたので、モジュラーチェーンに同期合成性を再導入できるかどうかを見てみましょう。 もしそうなら、それは統合チェーンの価値をneGate.ioするように思えるかもしれません。 これが私たちが深く掘り下げるtldrです。

• 共有シーケンシングは単独で同期的なアトミックインクルージョンを提供することができます（これは合成性よりもはるかに弱いです）。
• 共有シーケンサーと暗号的な安全性のメカニズム（たとえば、agglayer）を組み合わせることで、この包括性の保証を実際の組み合わせに強化することができます。
• クロスチェーンの安全性のためにAgglayerが提供する安全保証は、共有シーケンサーなしで(つまり、非同期設定で)使用することもできます。
• 同期的な合成可能性の効果をシミュレートする方法についても説明しますが、これは資本効率が低い方法で、暗号経済学（クロスチェーントランザクションの直接担保）を使用します。

アトミックインクルージョン - シェアードシーケンシング

共有シーケンシングは、特定のスロットの高さに対して、単一のエンティティ（「シーケンサー」または「提案者」とも呼ばれる）が複数のチェーンのシーケンス（つまり、ブロックの提案）に対して独占的な権利を持っていることを意味します。再び言及すると、一般的に言及されるこれらの共有シーケンサーは、怠惰なシーケンサー. 彼らはロールアップデータの順序と利用可能性について合意しますが、それを実行しません。 彼らはロールアップのステートマシンについて完全に無知です。

以前に書いたようにこれは、怠惰な共有シーケンサーがクロスチェーンバンドル（つまり、一連の取引）を含めるという信頼性のあるコミットメントを提供できることを意味します。

• アトミックに - すべての取引が含まれるか、含まれないか、
• 同期的に - 同時に（スロットの高さ）

これにより、より効率的なMEVの抽出が可能になりますスーパービルダー（つまり、クロスチェーンビルダー）がクロスチェーンアクションを実行する際に、クロスチェーンバンドルの1つのレッグが失敗するリスクの価格設定を行う必要がなくなります。ここでの同期性は、暗黙的に彼らに原子性を提供することができます。

クロスチェーンのアンバンドリング

共有シーケンサーのビルダーやアクティブ提案者を完全に信頼せずに、どのようにこれを行うのですか？単純に独立して署名された2つのトランザクションを送信するだけでは、₁とt₂) 各ロールアップごとに、共有シーケンサーはまだ片方またはもう片方を含めることを決めることができます。

例えば、現在のEVMにはネイティブバンドル形式の概念がないため、サーチャーはビルダー/リレーに完全に信頼してバンドルを解除しないようにします。現在のリーダーによるコミット前に、独立して署名されたトランザクションのバンドルを見ることができる人は、それらを解除することができます。これは一般的には問題ありませんが、ビルダーやリレーは自分たちの評判を維持し、サーチャーバンドルを保護するためのインセンティブを持っているためですが、その信頼が崩れた場合（または不正な参加者によってトランザクションが明らかにされた場合）、分割は非常に利益をもたらす可能性があります.

本当のクロスチェーン相互運用性を実現するために、ここではより強力なセキュリティ保証が必要です。私たちは単にサーチャーからお金を取ることについて話しているわけではありません。クロスチェーンのDeFi契約がクロスチェーンバンドルが尊重されるという前提で設計されているとしましょう。しかし、この信頼が崩れると、それらのプロトコルにとっては壊滅的な結果になります（たとえば、バーンアンドミントのクロスチェーンブリッジバンドルの場合、バーンを省略しても他の側で資金をミントできます）。

クロスチェーンの相互運用性を実現するためには、確固たる安全保証が必要です。つまり、クロスチェーンバンドル内の複数のトランザクションが一緒に含まれることを保証するトランザクション形式を定義する必要があります。もし一方だけが含まれている場合、それが無効であることを保証する安全保証が必要です。

これは、私たちが作成する必要があることを意味します。クロスチェーンバンドルのための新しいトランザクション構造はできませんアンバンドル単純な解決策は「これらのロールアップに新しいトランザクションタイプを作成しましょう」というものですが、それはそんなに簡単なことではありません。これらのロールアップにはVMの変更が必要であり、後方互換性を失います。また、それらのロールアップを緊密に結合することになり、各トランザクションが他のトランザクションと一緒にのみ有効であるように状態機械を変更する必要があります。

ただし、これを行うよりもきれいな方法があります. バンドル内の各トランザクションもバンドルハッシュに署名し、そのハッシュダイジェストをフリートランザクションフィールド（例：EVMのcalldata）に追加することができます。ロールアップはこれらをチェックするために派生パイプラインを修正する必要がありますが、VMは変更せずにそのままでいいです。これが実現すれば、ロールアップのユーザーは解除できないと確信できるクロスチェーンバンドルを提出することができます。解除しようとすることでそれが無効化されるでしょう。

ソース：ベン・フィッシュ

インクルージョン保証 vs. 国家保証

上記の内容を整えることで、怠惰な共有シーケンサーの構築方法が確立されました:

• クロスチェーンバンドルのための信頼性のあるアトミック同期インクルージョンの確約を提供することができます（つまり、すべてのトランザクションが含まれるか、含まれないか）
• そのような取引が含まれることから、信頼性のあるコミットメントは提供できません（たとえば、両方の取引が含まれる可能性がありますが、それより前に他の取引が行われて、取引が取り消される可能性があります）。

残念ながら、アトミックインクルージョンそのものははるかに弱い保証です。アトミックインクルージョンへのこのコミットメントは、ビルダーがクロスロールアップブロックを作成した場合に望ましい結果の状態を作成するという高い信頼を持つために十分です。ビルダーは、確認された場合に望ましい結果の状態を作成するためにブロックを実行したため、必然的にそのブロックの結果の状態を知っています。

ただし、問題はまだ残っています-他の人が状態を確実に知る方法は何ですか？

例を考えてみましょう:

• 同じ遅延シーケンサを共有する2つのロールアップ（raとrb）があります
• 私はra → rb間でのバーンアンドミントブリッジを使用したいです。これにより、raで燃やし、rbでミントします。
• rb上の鋳造ブリッジ契約には、ra上での状態遷移の保証が必要です（燃やすため）、しかし契約はra上で実行時に実際にトークンが燃やされたかどうかを知ることができません、なぜならraの状態にアクセスできないからです

正しいバンドルを提出した場合、怠惰なシーケンサーは ra のトランザクションストリームにバーントランザクションが含まれていることを保証できますが、おそらくそれの前に別のトランザクションが着陸し、それを無効にする可能性があるため（つまり、トークンが実際には燃やされなかったことを意味する）、それはわかりません。

単に怠惰なシーケンサを共有するだけでは、バンドルの実行中にチェーンがお互いの状態にアクセスするための十分な機能がありません。同期可能性のある合成性には、各チェーンの状態マシンが他のチェーンの状態（例えば、rbのブリッジ契約自体がraの状態を知る必要がある）にアクセスできる能力が必要です。その機能こそが、単一の統合チェーン内での完全な合成性を可能にするものです。

ビルダーは、契約に「信じて、それはうまくいく」と言うことはできません。私たちは、原子的包含が、バンドルを適切に実行するためにビルダーを信頼する検索者にとって良いツールであることを見ていますが、クロスチェーン相互運用性を抽象化するには不十分です。

これを修正するには、共有シーケンシングに加えて他のメカニズムを追加する必要があります:

前述したように、ビルダーは、バンドルがアトミックにインクルードされた場合に結果の状態がどうなるかを個人的に知っています。では、どうすれば信頼できるコミットメントを提供し、取引が含まれた場合に結果としてどのような状態になるかについて、他の全員を納得させることができるのでしょうか?

彼らには大まかに2つの選択肢があります:

• 暗号経済 - ビルダーは、クロスチェーンアクションを完全担保するために大量の資本をステークすることができます。これはしばしば効率的でなく、議論の余地がある模擬的な合成性です。ですが、これは機能を示すのに便利な例です。
• 暗号化-暗号化された取引が所望の状態を生み出すことを保証するメカニズムがある可能性があります。

暗号経済の安全性 - ビルダーボンド

仮想通貨経済学が同期可能性の効果をシミュレートする方法を理解するために、例を見てみましょう。古典的な例として使われるのは、クロスチェーンフラッシュローン. 私はraでフラッシュローンを借りて、rbで裁定取引に使い、同じスロットでraに返済したいと思っています。これは、ここにあるDeFiプロトコルが各側に「銀行契約」と呼ぶカスタマイズされたクロスチェーン機能を展開する場合に可能です。

さて、その安全性の問題ですが、raおよびrbの契約は、これを安全に行うためにお互いのチェーン状態を知る必要がありますが、これについては何も対処していません。さて、ここでの暗号経済的な「解決策」は実際にはかなり無理矢理です - スーパービルダーが流動性提供者として機能し、フラッシュローンの完全な価値を提供することです。取引が失敗した場合、貸付プロトコルはそのステークを保持します。なぜこれが最も満足のいく「解決策」でないかがわかります。

暗号化の安全性 - Agglayer

それは何ですか

ザ AggLayerは、3つの主要な利点を提供する分散型プロトコルです。

1. 高速なクロスチェーンの相互運用性のための安全性 - zk証明を生成し、aggchainsに暗号学的な安全性を提供します。非同期または同期動作時に、イーサリアムのブロックよりも高速に原子的なクロスチェーンの相互運用性を実現します。この設計は、チェーンの障害をユニークに分離するため、任意の実行環境と検証者をサポートできます。
2. クロスチェーン資産の交換可能性-それは資産交換可能性を確保する共有ブリッジを持っており、それを使用するチェーン全体でユーザーがラップされた資産を持たないようにします。ブリッジ契約はイーサリアムにあります。決済層.(異なるチェーンは、実装のために異なるセキュリティの仮定を持つことができることに注意してください、これについては以下で詳しく説明します。
3. ガス最適化 - それはaggchainsのための証明をaggreGate.ioし、多くのチェーンに固定コストを分散するための最適化方法です。共有デポジット契約も、L1に触れることなく直接L2間の転送を許可することで、ガスコストを最適化します。

ソース：ブレンダン・ファーマー、集約されたブロックチェーン

agglayerについての一般的な誤解を２つ明確にするために、以下の点について説明します:

• アグロレイヤーは、プルーフ aggreGate.io だけのサービスではありません - これは混乱していますが、実際にはAggreGate.ioの証明を行い、その名前に「aggregation」を付けています。ただし、AggLayerの目的はチェーンの集約です。この投稿の目的において重要な違いは、証明の集約のみではここで必要な安全性の保証を得ることはできないことです。
• アグレイヤーと共有シーケンサーは対立する設計ではありません- それらは一緒に使用する必要はありませんが、実際には完璧な相補体です異なる保証を提供する異なるチェーン。 Agglayerは、aggchainsがどのようにシーケンスされるかについて完全に無関心です。 チェーン間のメッセージングを処理しないため、実際にはフリーマーケットの調整インフラストラクチャ（リレー、ビルダー、分離されたシーケンサー、共有シーケンサーなど）に明示的に依存しています。 チェーンを構成するため。

今、それがどのように機能するかを見てみましょう。

bridging sucks

今日のロールアップ間の橋渡しは大変です。例えば、2つのイーサリアム楽観的なロールアップ間でイーサリアムを橋渡ししたいとしましょう。_aそして oru_b:

• ネイティブブリッジ経由 - 高額なイーサリアムL1ガス手数料がかかります（つまり、オルからのブリッジング_a→ イーサリアム+イーサリアム→oru_b)、ラウンドトリップには1週間以上かかります（障害証明ウィンドウのため）。
• ダイレクト・ロールアップ → ロールアップ - Gate.ioで受け取るETHの包まれたもの_b実際には、ネイティブのethとは非交換可能ではありません。_a.異なる橋を通る経路依存性は、交換可能性を損ないます。例えば、もしも ORU が_aブリッジが排水された場合、ブリッジングされたETHがOrubにバックアップされなくなります。Oru上のネイティブETHは影響を受けません。_bいいと思います。流動性の分断は嫌ですから、ユーザーはこれを望んでいません。実際には、ユーザーは直接流動性プロバイダーを介してブリッジを行います。誰かがETHを提供してくれます。_bそして資金をオルに保管してください_a.ネイティブブリッジ経由で撤退して待つこともできますが、発生するリスクと高い資本コストに対して高額な手数料を請求します。

ZKロールアップはこれをすぐに解決すると思うかもしれませんが、実際にはそうではありません。ナイーブな実装でも、L1トランザクションを送信する必要がありますが、これもまたコストがかかり、通常は非常に遅くなります(例えば、イーサリアムのファイナリティ時間、プルーフの生成時間、実際にプルーフが投稿される頻度など)。

ユーザーはこれに対処したくありません。単に資金を持ち、アプリを使用したいだけです。ブリッジングは完全に抽象化されるべきです - 資産は交換可能で、迅速かつ安価かつ安全に移動する必要があります。

これが共有ブリッジ契約の役割です。共有ブリッジ契約を使用することで、L1を経由せずにチェーン同士が直接ブリッジすることが可能になります。

トークンは結果としてaggchains全体で同質性を持つこともできます。rからethをブリッジする_ある → r_bまたはr_c→ r_b同じトークンを燃やしたり作成したりします。これはロックアンドミントされたアセットではありません。ネイティブのethです。これはすべてのアセットが一緒にエスクローされ、統合ブリッジを介して決済されるため可能です。これはL2sの大きな問題点であり、解決する必要があります。

ただし、RでETHを保有しているユーザーは、_avs. r_b異なるチェーンが異なる検証者を使用する場合、異なるリスクプロファイルを持つ可能性があります(たとえば、セーフチェーンから回路バグのあるチェーンに移動した可能性があります)。リスクプロファイルは、ここで共通の基準を使用するチェーン間で変更されません(実際には今日では標準です)。より統一された標準と形式的な検証は、異種ドメインが追加されても、時間の経過とともに改善されるだけです。

悲観的な証拠

aggチェーンは、状態の更新と証明をagglayerのステークノードに提出し、それらを整理し、すべてのメッセージに対するコミットメントを生成し、再帰的な証明を作成します。その後、agglayerは1つのAggreGate.iod zk証明を生成します（彼らはそれを「と呼んでいます）。悲観的な証明すべてのaggchainsに清算するためにイーサリアムに決済するために（"）。証明の集約はここでコストを任意の多くのチェーンに分散させるため、コストの観点から見て、それをすぐにイーサリアムに投稿することが実用的です。悲観的な証明プログラムは通常のRustコードで書かれており、それをできるだけ早く決済するためにイーサリアムに投稿することが実用的です。Succinctのzkvm sp1開発の容易さと高いパフォーマンスのため。

これらの悲観的な証拠は強制されます:

• インターチェーン会計-すべてのブリッジの不変条件が尊重されていることを証明します（つまり、どのチェーンも、それに預けられたトークンよりも多くのトークンを引き出すことはできません）。
• aggchainsの有効性 - 各チェーンが状態を正確に更新し、チェーンの曖昧さや無効なブロックはありません。
• クロスチェーンセーフティ - イーサリアムの遅延よりも低いクロスチェーントランザクションの結果としての状態更新が一貫しており、イーサリアムL1に安全に決済されることを証明します。これには、クロスチェーンバンドルの成功したアトミック実行が同期および非同期の両方で含まれます。

これにより、agglayerは上記の条件が満たされた場合にのみ、決済がEthereum上で発生することを保証します。条件が満たされない場合、対応するチェーンは決済できません。そのため、agglayerは、安全性のために協調者（例：共有シーケンサーまたはビルダー）を信頼することなく、低レイテンシでチェーン間でメッセージをやり取りすることができます。

高速で安全なクロスチェーン相互運用

aggチェーンは、非同期および同期の相互運用性の設定の両方で、他のロールアップに対するブロックの妥当性に関する制約を表現するためにここで提供される保証を使用できます。

これにより、ユーザーは両方の側で原子的に正常に実行されなければならないクロスチェーンバンドルを提出することができます。単なる原子的なインクルージョンだけではありません。実際には、それらの結果の状態が成功することを強制しています。これは、共有シーケンサーだけの原子的なインクルージョン保証に欠けていると言われていたものを正確に補完するのに最適です。

ソース：ブレンダン農夫、集約されたブロックチェーン

先ほどの例を引き継いで、

• 私たちには2つのロールアップがあります（r_aそして r_b)同じ怠惰なシーケンサーとアグレイヤーを共有しています
• クロスチェーンバンドルを提出して、同時にEthを燃やします_aそしてrでethをミントします_b
• スーパービルダーは、共有シーケンサーがコミットする両方のチェーンのためにブロックを構築します。
• R上の鋳造ブリッジ契約_brの状態に応じて、ETHを楽観的にマイントすることができます_a（この場合、ETHのバーンを正常に実行する）
• これらのブロックと証明はアグリレイヤーに提出され、両方のチェーンが有効な方法で(独立して、および互いに)機能し、共有ブリッジが安全に使用されたことが証明されます

これがイーサリアムに正常に決済されるためには、バンドルの両方のレッグが正しく実行されている必要があります。どちらかの側が失敗した場合、ブロックは無効になり、決済できません。つまり、たとえば、共有シーケンサーが R で ETH がバーンされていないブロックでサインオフした場合、_aが発行されたEthについて_bの場合、そのブロックは再編成されます。これにより、すべてのチェーンの安全性が確保され、不正なクロスチェーンアクションが解決されるのを防ぎます。

これらの再編成に関して留意すべき点が 2 つあります。

• 彼らは信じられないほど短いだろう、なぜなら即座に検出され、証明されるからです。
• それらは、あなたが接続しているチェーンのコーディネータ（シーケンサーと/またはビルダーなど）が積極的に悪意を持っている場合にのみ発生することがあります。

これらの再編成は、上記のポイントにより非常に稀で最小限であるべきですが、これにより、アグチェーンは、どのチェーンを原子的に構成し、どの信頼前提の下で行うかを完全に制御することができます。例えば、_あるrからチェーンの状態を受け入れることができるかもしれません_b彼らのシーケンサーのコンセンサスに基づいて作曲するために、彼らが使うことができるようになりましたが、_c証明の提出も必要になる場合があり、r_Dおそらく、彼らはすべてのクロスチェーン原子依存関係を暗号経済的に安全にすることを望んでいます。各チェーンは、ここで低レイテンシとリブネスのために独自のカスタマイズ可能なトレードオフを行うことができます。Agglayerは、チェーンが安全なクロスチェーン相互作用を持つための最大限に柔軟で最小限に意見のある基盤を提供します。

また、このような設計が実際にフォールトプルーフベースの設計と互換性がない理由もここでわかります。理論的には可能ですが、その場合、信じられないほど深い再編成を経験する可能性があります。すべてのチェーンを迅速に証明して解決することで、最悪のケースは非常に短くなり、悪意のある試みに対する自然な抑止力としても機能します。

異質証明者の障害分離

重要なことに、AggLayerは完全に異種のチェーンをユニークに可能にします。あなたは、カスタムVM、プルーバー、DAレイヤーなどを持つAggChainを安全に誰とでも共有することができます。

しかし、これはどのように可能なのでしょうか?これが通常受け入れられない理由は、1 人の欠陥のある参加者 (たとえば、回路のバグ) が通常、ブリッジを騙してすべての資金を枯渇させる可能性があるためです。そこで、上記のチェーン間アカウンティング証明の出番です。これらの証明により、ブリッジの不変量がすべて尊重されることが保証されるため、不健全な証明者の場合でも、影響を受けるチェーンに預けられた資金のみが排出される可能性があります。障害は完全に分離されています。

信頼性のある中立性

この種のインフラストラクチャは信頼性のある中立性に大きな恩恵を受けているため、それが理由です。完全なオープンソースコードiFor agglayerは中立地帯です。同様の精神で、Agglayerは証明集約の手数料を支払うために唯一のガストークンとしてETHを使用します。

しかし、完璧ではありません。特に最初の段階では、完全に信頼できる中立性はありません。最終的な不変性と公共財としての確立に至る道のりには、契約のアップグレード可能性がある可能性があります。

それは言うまでもなく、完全に信頼性のある中立的なものである必要はありません。何もありません。(後でベースのロールアップでこれを再度見るでしょう。)実際には、おそらく最も魅力的な技術的な競争ビジョンを提供し、ロックインとレント抽出に対して意図的に最小限の態度を取ります。目標は、アグチェーンが可能な限り主権を維持できるようにすることですが、信頼性の低いクロスチェーンの組み合わせ性を抽象化することもできます。

aggchainsには特定のvm、実行環境、シーケンサー、da層、ステーキングトークン、ガストークン、または共通のガバナンスが必要ありません。チェーンは好きな時に出ることができます。収益共有の要件はありません。他人のチェーン上でL3として展開する必要はありません。

一般的なL2の上にL3を立ち上げる理由は、私の見解では、アグレイヤーと同様のアーキテクチャが構築される間の応急処置です。ただし、それは今日それらを立ち上げる完全に正当な理由です。v1のアグレイヤーは単なる共有ブリッジ契約です。証明集約と安全な低遅延相互運用性を持つv2はまだ稼働していません。最速の配布を得るために今日物を出荷する緊急性がある場合、人々が数年間待つことを期待することはできません。

リアルタイム検証

低レイテンシーの設定で実用化されるのは数年先ですが、リアルタイム証明は、クロスチェーンの安全性のために共有シーケンシングと一緒に使用できる可能性があることに注意する必要があります。また、とにかくかっこいいので、簡単に説明します。より具体的には、「リアルタイム」証明とは、問題のチェーンのスロット時間よりも短い証明時間を指します。クロスチェーンのMint-and-Burnブリッジの例をもう一度考えてみましょう。

• 2 つのロールアップ (r_aと r_b)は、同じレイジーシーケンサーを共有しています
• ra → rb間のバーンアンドミントブリッジを使用し、raで同時にバーンし、rbでミントしたいと思います
• スーパービルダーは、これらのクロスチェーントランザクションのバンドルを含むクロスチェーンブロックを作成します。ブロック内には、ビルダーは、他のロールアップに含まれている状態遷移の証明を含めます。

私たちはすでに共有シーケンサーの同期原子バンドルの包含を保証していましたが、今では各契約は他のチェーンの状態の証明を検証して、正常に実行されることを知ることができます。

リアルタイムの証明のために、理想的には証明時間をトータルスロット時間のほんの一部にすることで、「同期ウィンドウ」を最大化したいです。これは、クロスチェーンで同期的に動作するトランザクションを処理することができるスロット時間の部分であり、スロットに十分な時間を予算として割り当ててプルーフを作成し、ブロックに配置する必要があります。

源：ジャスティン・ドレイク、リアルタイム証明

ここで、ビルダーと証明者が暗黙的にマージまたは配置されることになることに注意してください。ビルダーには、可能な限り最後の瞬間までビルドしてブロックにできるだけ多くのものを収めるために、証明速度を最適化する明確なインセンティブがあります。

源：ジャスティン・ドレイク、リアルタイム証明

今後数年間で、リアルタイム証明に対するこの高いインセンティブが実現するのであれば、もちろん、これは分散型証明にまったく友好的ではないことにも注意する必要があります。プルーバーは、ビルダーと合併または併置する際に、比較的集中化する必要があります。

概要

ユニバーサル同期合成可能性は本当にクールですが、実際にどの程度価値があるのかはあまり明確ではありません。インターネットはすべて非同期であり、誰もそれを知りません。それは速くて複雑さが抽象化されているからです。それがユーザーが望むすべてです。

私は、Agglayerのようなものを使用することの価値のほとんどは同期設定ではなく、クロスロールアップチェーン抽象化の形態として機能することです。ユーザーに重要なユーザーインターフェースの側面により、多くのチェーンが1つのように感じられるようにします（例：より交換可能なネイティブアセット、ネイティブクロスチェーンアプリの機能、高速な相互運用性など）

シンクロナス・コンポーザビリティは、明らかに財務的に価値があります(例えば、清算の許可、より効率的な裁定取引、フラッシュローンを使用したより効率的な借り換えなど)。しかし、インターネットが非同期で問題なく動作するのと同様に、Tradfi はもちろん非同期です。Tradfi よりもさらに優れていることを望むのは当然ですが、普遍的なシンクロニシティは優れた実行の要件ではないことを明確にする必要があります。また、同期インフラストラクチャの構築と提供には実質的なコストがかかります。

個人的には、USCが必要であるという最も説得力のある議論は、実際にはより良いUXとDevExにつながるということです。これがSolanaなどのエコシステムにとってどれほど大きな利益となっているかを否定することは不可能です。ただし、これは今日の問題であって、永遠の問題ではないことを願っています。

実際のところ、現時点では誰にとっても理解することがやや困難であるというのが単純な事実です。これはバイナリの「すべての暗号通貨は同期的である」というものでも、「すべてが非同期的である」というものでもありません。私たちは基本的に後者に向けて解決する必要があると考えていますが、両方がアドホックな基盤で存在することができます。

イーサリアムベースのロールアップ

OK、では、今、私たちはロールアップの断片化に対処するための解決策空間について良いアイデアを持っているはずです。次の質問は、このすべてに基本レイヤーをどのように関与させるべきかということです。ここでイーサリアムの役割は何ですか？

以下の省略形を使用します:

• bl - ベースレイヤー
• br - ベースのロールアップ
• preconfs - プリコンファーメーション

特に断りのない限り、ここで議論する問題のBLはイーサリアムであり、BRはイーサリアムBRです。ただし、BRSはどこでも起動できるため、基本的な概念は広く適用されます。

バニラベースのロールアップ

実際には、数年前の最初のロールアップの実装は計画されたbrs、しかし、低遅延と高効率のための集中型シーケンサを支持して放棄今私たちがベースと呼んでいるシーケンシングは、Vitalikは「と呼んでいました。トータルアナーキー「当時はそれが比較的非現実的で効率的ではなかった。それは、イーサリアムのPBSインフラストラクチャ（洗練されたビルダーを備えた）の進化以前でした。」

その後、BRSは2023年3月に再び注目されました。それらは次のように定義されました：

「ロールアップがベースである、またはL1シーケンスであるとは、そのシーケンシングがベースのL1によって駆動されると言われています。より具体的には、ベースのロールアップは、次のL1提案者が、L1探索者やビルダーと協力して、次のL1ブロックの一部として次のロールアップブロックを許可なく含めることができるものです。」

彼らは以下の利点を提供するべきです：

「そのようなロールアップのシーケンス化は、最大限にシンプルであり、L1の生存性と分散化を継承しています。さらに、ベースとなるL1に特に経済的に整合しています。」

具体的には、あなたはイーサリアムのリアルタイムセキュリティを得ます：

「あなたはイーサリアムの検閲耐性とライブネスを受け継ぎます。つまり、イーサリアムの決済保証だけでなく、検閲耐性も持っており、遅延のない、逃げ口のないリアルタイムの検閲耐性を持っています。」

ベースのロールアップを選択したら、論理的な設計が重要です:

「イーサリアムは、これら2つの特性、セキュリティと信頼性の中で最大化しています。これはまさにロールアップの定義です...ロールアップはすでにイーサリアムのセキュリティ前提を受け入れたものです。新しいセキュリティ前提を追加していません。最も弱いリンクに落ちることもありません。既存のセキュリティ前提を再利用するだけです。そして、イーサリアムを信頼性のある中立的なプラットフォームとして受け入れています。そうでなければ他のチェーンを選択していたでしょう。そして今、あなた自身に問うことができます。なぜ誰もがレイヤーワンのシーケンスを使わないのでしょうか？」

最も単純な形で、brsは確かに上記の設計目標を達成できます。ロールアップが独自のシーケンサーを実装していない場合、暗黙的に現在のイーサリアムの提案者が12秒ごと（イーサリアムのスロット時間）に含まれる内容を決定します。

ただし、ベースのシーケンシングにはまだトレードオフがあります。なぜロールアップは通常、独自のシーケンサを実装するのか:

• ファストプリコンフ - ロールアップユーザーはイーサリアムブロックの12秒以上待ちたくありません。
• 安全な事前設定 - イーサリアムが再編成をブロックすることがあるため、ユーザーは安全を確保するためにさらに長く待たなければなりませんが、これもユーザーが好まないことです。シーケンサーは、ファイナライズされていないイーサリアムブロックに依存しないため、イーサリアム自体が短い再編成を経験しても再編成する必要がないpreconfを提供できます。
• 効率的なバッチ投稿 - シーケンサーは、大量のデータをバッチ処理し、圧縮し、コストを最適化した方法で定期的に BL に投稿できます (たとえば、BLOB を完全に使用するなど)。

ベースのロールアップ+事前設定

だから、私たちはケーキを持ちながら食べることができますか？入力するベースの事前設定.

ここでは、比較的短時間でbrs + preconfsと従来のロールアップを比較するために、ベースのpreconfsの背後にある直感を説明します。後で、より一般的に（つまり、イーサリアムL1トランザクションの両方のbr preconfsとbl preconfsの両方について）、より詳細にpreconfsを分析するために戻ってきます。

コアのアイデアは、BRプリコンフはBLプロポーザから提供されなければならないということです。プリコンフを提供するために、これらのプロポーザは一定の担保（例：再ステーキング）を提供し、追加のスラッシング条件に参加する必要があります（つまり、提供されるプリコンフが約束どおりにオンチェーンになること）。これを行う意思のあるいかなるプロポーザでもBRシーケンサとして機能し、プリコンフを提供することができます。

提案者（つまり、バリデータ）は、実際には、より専門化されたエンティティである「Gate.ioways」にプリコンフを提供する役割をデリゲートすることが期待されていることに注意する必要があります。プリコンフの提供には、比較的高度なエンティティが必要であり、イーサリアムは提案者を非熟練者のままにしたいと考えています。

ただし、既存の中継器がこの役割を引き継ぐことが予想されています。Gate.iowayはユーザーと中継器の間のインターフェイスのみであり、別の独立した実体を追加することは複雑さと遅延をもたらすだけです（ただし、遅延は共同利用によっても対処できます）。中継器はすでにビルダーや提案者から信頼されているため、ここでユーザーから彼らに対する別の信頼要件を追加することになります。

現在、バリデータはイーサリアムのブロック提案者として機能していますが、プロトコル自体が提案権を直接オークションにかけるアップグレードの検討が行われています。実行オークション.これにより、洗練されたエンティティがプロポーザルの権利を直接購入できるようになり、バリデーター(現在の提案者)がここで考えているようにプロポーザルに deleGate.io する必要がなくなります。

いずれにせよ、重要な点は、イーサリアムのコンセンサス(12秒)よりも速いプレコンフィケーションには、信頼できる第三者(TTP)が必要であるということです。TTPが再発行されたバリデーターであるか、ステーキングされているか実行オークションwinner、deleGate.iod、Gate.iowayなど、基本的にリアルタイムのイーサリアムセキュリティを提供することはできません。Coinbaseがイーサリアムの提案者として「ベースのPreConf」を提供している場合でも、ロールアップシーケンサーとして「従来のPreConf」を提供している場合でも、Coinbaseを信頼しています。同様に、ETHの債券を建てることもできますが、いずれの場合も、これはイーサリアムのコンセンサスのセキュリティとは無関係です。

したがって、任意のベースのプリコンフィグデザインは、我々が最初に始めたブロックチェーンの目標（シンプルさとセキュリティ）から必然的に逸脱することに留意すべきです。ベースの事前設定はますます複雑になっていますまた、彼らはイーサリアムのリアルタイムセキュリティ保証を提供することはできません。

ただし、これらの前提条件がオフラインになったり検閲を始めた場合には、blトランザクションを介して直接トランザクションを強制する能力を維持する必要があります。イーサリアムからのこれらの保証は、さらに強化されるはずです。インクルージョンリスト実装されます。

BRの場合 - TTPは高速な事前設定を提供し、BLは最終的なセキュリティを提供します。

ノンベースのロールアップ + ベースのフォールバック

さて、伝統的な（つまり、ベースとしていない）ロールアップについて考えてみましょう。その独自のシーケンサー（集中型または非集中型）は高速な事前確認を提供します。後で、ユーザーは遅れて完全なイーサリアムのセキュリティを取得します。これには、ある種のリアルタイム性（台帳の成長+検閲耐性）も含まれます。強制的な包摂またはBL フォールバックメカニズム。

私が指摘したように、ロールアップはセキュリティを継承しますか？:

ロールアップは、ホストチェーンと同等のセキュリティ特性を持つ確認ルールを公開する能力を持っています。彼らは最良の場合、ホストチェーンのコンセンサスの速度でこれらの特性を受け取ることができます（実際には、ロールアップがホストチェーンに投稿する頻度によって多少遅くなることがよくあります）。

ロールアップは、より良いユーザーエクスペリエンスのために「ハッピーパス」より緩い確認ルール（つまり、シーケンサ）を提供することもできますが、失敗した場合にはフォールバックを保持します。シーケンサが停止した場合でも、続けることができます。

注意してください最終的なセキュリティへの時間ここで最適化するのは主要な変数です:

Rollupユーザーがホストチェーンと同等のライブネスにフォールバックできるという前提は、ホストチェーンのブロックと完全に同じ速度で強制的なインクルージョンを取得できるということを前提としています（例：Rollupシーケンサーがあなたを検閲している場合、次のEthereumブロックでトランザクションを強制的に含めることができるということです）。

実際には、通常、短い遅延があります。即時の強制的な包括を許可した場合、利益を上げる検閲MEV他の複雑さの中でしかしながら、あります。リアルタイムの生体認証保証を提供する可能性がある設計ホストチェーンから（例えば、1ブロックではなく数ブロックのホストチェーンブロックの速度で）

この精神で、Sovereign labs has a design以下のことを行います:

• パーミッション付きシーケンシング - ロールアップは許可されたシーケンサーを設定し、そのトランザクションはブロックに含まれるとすぐに処理されます。ロールアップの状態に書き込みロックがあるため、ブロックチェーンのブロック時間よりも信頼性の高い事前確認を迅速に提供できます。
• ベースシーケンス - ユーザーはトランザクションをBLに直接送信することもできますが、Nブロック遅延(Nは十分に小さい)で処理されます。これにより、「最終的なセキュリティまでの時間」が大幅に短縮され、実際、この設計は「ソフトコンファメーションによるベースのシーケンシング」とさえ呼ばれています。(brsのこの定義は、前に提供した定義、つまり、bl提案者はbrをシーケンスするか、またはそれらによってdeleGate.iodされる権利を持っている必要があるという定義と矛盾することに注意してください。

non-brsの場合- ttpsは高速な事前確認を提供し、blは最終的なセキュリティを提供します。

なぜですか？

上記のように、両方の経路は同じ効果的な結果を生み出します。

これらの事前確認があるブロックリレーは、もはやイーサリアムのシンプルさやリアルタイムのセキュリティを提供していません。では、このすべての意味は何ですか？なぜ「伝統的な」ロールアップのフォールバックを強化しないのでしょうか？今の時点で「ベースド・ロールアップ」とは何ですか？

これは実際に私のガバナンスの証明昨年の投稿で、イーサリアム固有の再ステーキングの基本的なユースケースについて議論しました。

1) 技術的（提案者のコミットメント）- これには避けられないことがあります - イーサリアムブロックの順序への信頼性のあるコミットメントを望むのであれば、それはイーサリアムのバリデータから提供されなければなりません。MEV-Boost++これはこのバケツに入る可能性がある仮想アプリケーションの1つの例です。

2）ソーシャル - 私は、ほとんどのリステーキングアプリケーションにおいて、経済的なセキュリティや分散化のプーリングではなく、イーサリアムのアライメントを主要なユースケースと見なしています。それは「と言うことができる」となっています。見て、私たちはイーサリアムプロジェクトですそれは同じ理由で、チェーンが自分自身をイーサリアムL2と呼び続けるのとほぼ同じです。アーキテクチャに関係なく.

「br + preconfs」の価値は、「traditional rollup + fast fallback」に対してどれくらいの価値があるかを尋ねる文脈で、私たちはこれを近代化することができますか？

1）技術的（提案者のコミットメント）- Ethereum BRSによる事前確認付きは、現在のEthereum提案者からEthereumブロックの内容と順序の含まれることについて信頼できるコミットメントを得ることができるという、根本的な技術的利点があります。これは、ロールアップの一揃いがシーケンサを共有することを望む理由とまったく同じ理由で潜在的に価値があります。 BL提案者がBR提案者（つまり、シーケンサ）である場合、彼らは任意のロールアップ間でシーケンサを共有する場合と同じ原子的な含有保証をBLで提供できます。彼らは両方のチェーンに独占権を持っています。さて、これはどのくらい価値があるのでしょうか？すぐに戻ってきます。

2) ソーシャル（アライメント/信頼性中立性）-好きでも嫌いでも、イーサリアムの整列BRになるためのセールスポイントです。正直言って、太鼓については「彼らはBRの人たちだ」ということ以外は何も知りませんし、彼らがBRの人たちでなければ、私は彼らを知らなかったでしょう。良い共同マーケティングが必要です。ここでの先駆者であることに価値がありますが、これは持続的な価値提供ではなく、将来の潜在的なBRには適用されないと思われます。同様に、最初の数人のAVSについてはみんなが聞いたことがあるでしょうが、現在のすべてのAVSを名前で挙げることができますか？私にはできません。

より高いレベルでは、すべてのイーサリアム・ロールアップが（仮想的な）「Optimism Shared Sequencer」または「Arbitrum Shared Sequencer」に参加するわけではありませんが、「Ethereum Shared Sequencer」に参加するように説得するチャンスがあります。新しいトークンもブランドもコンセンサスもありません。すべてのイーサリアムL2がシーケンシングで統合することが価値があると考えるなら、この信頼性のある中立性は、その目標を達成するための最も強力なシェリングポイントになる可能性があります。

この信頼性のある中立性は、クロスエコシステムのユーザー（たとえば、ensのような基本的なインフラストラクチャを持つアプリケーション）を引き付けようとするロールアップの開発者にとって、おそらく最も価値があります。彼らは、オプティミズムシーケンサを使用することでアービトラムのユーザーを排除する可能性がある場合、またはその逆の場合、躊躇するかもしれません。

それぞれについて、以下で詳しく説明します。

信頼性のある中立性

ソーシャルポイントについてさらに深く掘り下げると、BRはしばしば最大限に「イーサリアムに合致した」オプションと見なされています。これについての誰かの価値判断は置いておくとしても、重要なポイントは、どのBRデザインにおいても高い度の信頼性のある中立性が前提とされているということです。

信頼できるニュートラルなBRは、バニラの場合に設計するのは簡単ですが、前述したように、誰もそれを本当に望んでいません。事前設定では、提案者が追加のスラッシング条件を選択することを必然的に要求します。これらの追加のスラッシング条件は、提案者が何らかの追加システム(例えば、潜在的に固有層のリスタキング、共生または他の標準）を作成するためにコミットすることができます。ロールアップは、抽象的には信頼性のある「イーサリアムシーケンサー」に参加することができるかもしれませんが、私的資金で資金提供されたプロジェクトを使用している場合、おそらく信頼性のある中立性は失われる可能性があります。たぶん、彼ら自身のトークンを使用しています。

担保物に関していくつか未解決の問題があります。

担保サイズ

早期の設計では、提案者は個人的に1000 ETHのように非常に高額な担保を提供する必要があると仮定していました。問題は、基本的に提案者が常に約束を破棄し、自己でブロックを構築し、事前の確認を曖昧にすることができることです。これは非常に価値があり、1000 ETHはMEV-Boostの発足以来、通過した最高の支払い額よりも十分に高いです。欠点は、これが小規模な提案者にとって参入のハードルを非常に高く作り出すということですが、一方で大規模な提案者（例：コインベース）は比較的に1000 ETHを提供し、自分のステークウェイト全体で報酬を得ることができます。総ETHステークの13%)登録者は、すべてのバリデーターに対して単一の保証金を提供できるため、その理由で、より小さな保証金を持つ提案者を許すための他のアイデアただし、もちろんトレードオフが伴います。ここでの設計空間は不確定性に満ちています。

それは注目に値することです実行オークションそうすれば、すべての提案者は、これを容易に行うことができる洗練されたアクターであると想定できるため、この懸念は和らぎます。

ソース：Barnabé Monnot、Mev-BoostからEpbs、Apsへ

しかし、大手のオペレーターでさえ、大量の資金を提供することに躊躇しています。なぜなら、潜在的なライブネスの問題があり、スラッシング（オペレーターのライブネスの失敗、私たちのプレコンフが含まれる前にブロック内に含まれる前に落ちることは、ユーザーにとっても同じように安全上の問題であり、厳しく罰せられる必要がある）が発生する可能性があるからです。

担保タイプ

バニラETHはおそらくこの状況では唯一の信頼性のある中立的な担保です。ただし、より資本効率の良い資産（例：stETH）を使用したいという欲求は自然に生じます。この変換を担当するアンダーライターがいるアイデアもあります。mteam ここ.

プラットフォーム

「イーサリアムベースのプレコンフ」が「固有レイヤーベースのプレコンフ」や「共生ベースのプレコンフ」のようになれば、あまり「信頼できる中立性」とは言えません。 この方向に進むことを計画しているチームもありますが、そのようなプラットフォームを使用することは厳密な要件ではありません。誰もが使用できる一般的で中立的な標準を作成することは可能であり、そのようなシステムは、最も根拠のあるオプションとして、一般的に採用するのに適しているように思われます。

「信頼できる中立性」を実現するには、ベースとなるプレコンフィグデザインに対して公共の利益基準の採用が必要となるでしょう。

事前確認

インクルージョン対ステートプレコンフス

今後、プリコンフについてより詳しく説明します。前述したように、特定のタイプのプリコンフ（state上のbrプリコンフ）を取り上げましたが、それらは完全に一般的な概念であることに注意する必要があります。BRだけでなく、BLトランザクションに対してもプリコンフを提供することができ、プリコンフの強度を異なるものにすることができます。

• インクルージョンプレコンフス-トランザクションが最終的にオンチェーンに含まれるという弱いコミットメント。
• state preconfs - トランザクションが最終的にオンチェーンに含まれ、その結果の状態が保証される最も強力なコミットメント。

後者（状態の事前確認）はもちろん、ユーザーがウォレットに表示して欲しいものです:

私は1ETHを$4000のUSDCに交換し、手数料として0.0001ETHを支払いました。

含まれていないプリコンフス:

1 ETHを$4000 USDCに交換し、手数料として最大0.0001 ETHを支払おうとする私の取引は最終的にオンチェーンで完了しますが、成功するか失敗するかはわかりません。見てみましょう。

ただし、非論争のステート（たとえば、ユーザー自身がトランザクションを無効にすることができるシンプルな転送）に対してユーザーが行ったアクションの場合、インクルージョンプリコンフは事実上ステートプリコンフと交換可能であることに注意する必要があります。この場合、「アリスのUSDC転送が次の数ブロックに含まれる」という約束は、ウォレットがユーザーに「USDCをボブに送信しました」と表示するために十分です。

驚くべきことに、より強いコミットメント（州の事前確認）を得るのは難しいです。基本的に、それらはを必要とします信頼できるコミットメント現在ブロックの提案に独占権を持っているエンティティ（つまり、チェーンステートの書き込みロック）から

価格設定の事前設定

もう一つ大きな違いは、これらの preconf がどのような状態に触れているのかということです。

• 非論争の状態 - 他の誰もこの状態にアクセスする必要はありません（例：アリスはUSDCをボブに転送したい）
• 論争のある状態 - 他の人はこの状態にアクセスしたい（例：eth/usdcのammプールでのスワップ）

preconf は、最終的にどのブロックが生成されるかについての制約です。他の条件がすべて同じであれば、ビルダーの検索空間を制約することは、本質的に、それを注文することで獲得できる潜在的な価値を減らすことしかできません。つまり、提案者に返される価値は少なくなります。インセンティブと互換性を持たせるために、Gate.iowayは、結果を制約することで失われる可能性のあるMEV≥プレカンファレンス料金を請求する必要があります。

これは十分に単純です。 MEVの損失が~0（例：USDCの転送時）の場合は、いくらかの名目的な一律料金を請求することが合理的です。しかし、大きな問題があります-争議のある状態での事前確認の価格をどのように設定するかですか？事前確認の価格設定と直前確認の価格設定を比較すると、後者の方が低くなる可能性があります。他の要素がすべて同じである場合、ビルダーにとって最も利益が出るのは、可能な限り最後の瞬間まで待ち、MEVの価格を正確に設定することです。

しかし、（洗練された検索者と普通のユーザーを考慮に入れて）争議のある状態に対する迅速なプリコンフが十分なユーザーデマンドがあると仮定すると、時折、皆にとって有益な清算価格が存在する可能性があります。では、次の12秒の任意の時点で含めることができる争議のある状態のトランザクションのプリコンフをどのように価格設定するのでしょうか？これにより、もはや可能ではなくなるよりも利益が高い機会を見逃す可能性があります。

コンテストされた状態のpreconfsがブロック全体でストリーミングされると、ビルダーがブロックを作成する方法と競合する可能性があります。preconfsの価格を正確に見積もるには、それを今すぐに含めることのMEV影響をリアルタイムで推定する必要があります。これは実行して可能な結果をシミュレートすることを意味します。つまり、Gate.ioの方法は、高度に洗練されたサーチャー/ビルダーである必要があります。

私たちはすでにGate.iowayとリレーが合併することを前提としていました。もし彼らが継続的に価格をプリコンフに設定する必要があるなら、彼らはビルダーとも合併するでしょう。また、私たちはUSCがビルダーとプルーバーの合併を加速させることも受け入れました。それもそうに思えます。実行オークション提案者の権利を、価格を設定できる洗練されたアクター(おそらくビルダー)に直接販売します。

これにより、イーサリアムL1およびBRトランザクション供給チェーン全体が1つのボックスに入り、その期間のすべてのチェーンの状態に対する独占ライトロックがあります。

プレコンフサービスの注文ポリシーは明確ではありません（例：常にFCFSで実行するのか、別の方法で順序付けするのか）。また、Gate.iowayがすべてのプレコンフでオークションを行うことも可能です（例：検索者がプレコンフに入札できるようにする）。ただし、そのような設計がどのようになるかは明確ではなく、必ずしもレイテンシが高くなることを意味します。

公正な交換の問題

Gate.iowayがプレコンフをリリースする直接的なインセンティブを与えていないという、プレコンフには公平な交換の問題があります。

次の例を考えてみてください:

• 現在のGate.iowayは12秒の独占を持っています
• ユーザーは、スロットの開始時点（t = 0）で事前確認トランザクションリクエストを提出します
• Gate.iowayは、スロット中に作成したすべての事前確認を11.5秒まで待機し、それらをすべてブロックに取り込むための500msのバッファを残します。その時点で、収益性のある事前確認を含めるかどうか、除外するかどうかを決定できます。

このシナリオでは、ユーザーはスロットの最後まで実際に受け取らないにもかかわらず、事前に支払いをすることがあります。Gate.iowayは、収益性がないと判断した場合、スロットの最後にそれをドロップすることもあります。Gate.iowayによるこの保留は客観的に帰属可能な過失ではありません。しかし、それは主観的に帰属する可能性があります。.

実際には、Gate.ioはプレコンフを最後まで保留するためのインセンティブが実際にあります。情報の非対称性があるところには、mev があります.取引を非公開にすることで、建設業者は世界の状況をより最新の視点で把握することができ、リスクの価格設定を改善し、MEVを獲得することができます。ユーザーに与えられる一連の事前設定についてコンセンサスが得られていないため、Gate.iowayはここで説明責任を負わない。

基準が必要ですそして、preconfirmerがすぐにすべてのpreconfsを公開的にゴシップすることを期待しています。これにより、ユーザーはすぐに望んでいるものを手に入れることができ、他の人もGate.iowayが期待されるサービスを提供していることがわかります。将来的にそれを行わない場合、ユーザーは彼らを信頼せず、preconfsのために彼らに支払いを行いません。Gate.iowayの評判には価値があります。とは言っても、それはまた、非常に貴重ここで不正行為を行い、予約に反することはありません。

l1ベースレイヤープリコンフス

一般的な事前設定のポイントを片付けたところで、L1の事前設定のニュアンスについて話しましょう。先には触れませんでしたが、これらを構築しているプロジェクトがあり、それらとBRの事前設定の相互作用が重要になります。

例えば、ボルトは、イーサリアムの提案者がブロックの内容について信頼できるコミットメントを行えるようにしたいプロトコルの1つです。登録された提案者は、Boltサイドカーを実行してユーザーからの事前設定リクエストを受信し、確認してから、これらの制約を尊重するブロックを返すことができるリレーとビルダーにこの情報を送信することができます(つまり、提案者が事前設定を行ったトランザクションを含むブロックを返すことができます)。

ここで重要なのは、Bolt v1ここで説明されているのは、ユーザーのみがプリコンフを無効にできる非論争的な状態のための単純なトランザクションの含有プリコンフのみをサポートしています。先に話したように、これらは提供する最も単純で弱いコミットメントです。

これらのプレコンフチームはすべて、より大きな野心(例:州のプレコンフ、部分ブロックオークション、スロットまたは部分スロットオークション)を持っていますが、何が彼らを妨げているのでしょうか?

• アカウンタビリティ - コミットメントの違反は、客観的なスラッシングのためにオンチェーンで証明可能であるべきです。トランザクションの含有を証明するのは比較的容易ですが、スロットオークションなどの他のコミットメントをどのように強制するかは明確ではありません。
• 資本要件-任意のコミットメントを提供することは、コミットメントの違反価値が任意に高くなる可能性があることを意味します。 Gate.iowaysはおそらくこれらを提供するために莫大な額（例：数千ETH）をステークする必要があるでしょう。これらはおそらくプールされ、最大のエンティティ（例：大手取引会社やコインベース）に利益をもたらし、小規模なエンティティを置き去りにする可能性が高いです。
• 価格設定 - 継続的にストリーミングされる州の事前会議のようなものについて、実現可能で価値があると判断したとしても、どのように価格を設定するかについては、多くの未解決の問題があります。
• ネットワークへの参加 - これはおそらく最も重要で基本的なポイントです。前述したように、State PreConfs のようなコミットメントを提供できるのは、State に書き込みロックをかけている現在の提案者だけです。理論的には、提案者の100%がこのシステムを選択し、これを模倣することができます。実際には、それは起こりません。

運営に非常に利益が出る数年間の実績を持つ、非常に利益性の高い簡単な製品mev-boostがあります>92％の参加文脈によっては（おそらくもう少し高いかもしれませんが、これは考慮されていません）最低入札). 新しい事前設定サービスは確かに参加率がはるかに低くなるでしょう。しかし、それが約90％の範囲に達するとしても、これは通常のユーザーにとっては有用な製品ではないように思えます。ユーザーに10％の時間を「ああ、ごめんなさい、ただ今は事前設定は利用できません。少し後で再度確認してください」と伝えることはできません。

最高でも、これは国家プレコンフスが洗練された検索者やトレーダーのためのオプションツールにしか感じられず、そのスロットが提案者に参加することを望む場合にブロック内で早期にコミットメントを得たい場合があります。それは価値があるかもしれませんが、ここではフラグメンテーションやUXのアンロックはありません。

L2ベースのロールアップの事前設定

br事前確認はbl提案者から提供されなければならず（それが「ベース」と呼ばれる理由です）。これには一定の担保を預け、追加のスラッシング条件（つまり、提供された事前確認が約束通りにチェーン上に届くこと）に参加する必要があります。これを行う意志のある提案者は、brシーケンサーとして機能し、事前確認を提供することができます。

重要なことに、これらのbr preconfsは単なるinclusion peconfsではなく、状態preconfsです。これは、brが、Gate.iowaysに登録することをサインアップするbl proposersに回転するシーケンサーの独占を与えるデザインに参加しているために可能です。

現在、1人のイーサリアムバリデーターが各スロットの提案者として機能し、提案者のスケジュールは常に現在のエポックと次のエポックで知られています。エポックは 32 スロットなので、特定の時間に次の 32 から 64 の提案者が常にわかっています。この設計は、次のアクティブなシーケンサー(つまり、先読みの次のシーケンサー)に、この事前会議システムにオプトインされたBRのトランザクションをシーケンスする独占権限を付与することで機能します。Gate.iowaysは、brチェーンの状態を進めるために署名する必要があります。

すべての提案者（Gate.iowayに参加していない提案者も含む）は、シーケンサーによって事前に確認されたトランザクションを含める権利を持っていますが、義務はありません（つまり、Gate.iowayに参加している提案者）。彼らは、その時点までに事前に確認されたトランザクションの完全なリストを持っている限り、インクルーダーとして機能することができます（シーケンサーは、brトランザクションを含むblブロブを作成し、それらをゴシップできます）。

ソース:イーサリアムシーケンシング、ジャスティン・ドレイク

トランザクションフローは次のように機能します。

1. brユーザーは、次のシーケンサーにトランザクションを提出します（下の画像のスロットn+1の提案者）。
2. シーケンサーは、結果の状態の事前確認を即座に提供します(例:ユーザーがBRで1ETHを4000ドルUSDCに交換し、0.0001ETHの手数料を支払いました)
3. この時点で、任意のインクルーダはシーケンスされたトランザクションを含めることができます（スロットn提案者は以下の画像でそうします）

ソース: イーサリアムのシーケンシング、ジャスティンドレイク

他のインクルーダーがプレコンフを含まない場合、それらを与えたシーケンサーは単に次にブロック提案者としてそれらをチェーン上に含めることができます。例えば、上の画像でスロットnのインクルーダーがスロットn + 1シーケンサーが出したプレコンフを含めないことに決めた場合、スロットn + 1シーケンサーは、nスロットとn + 1スロットの間に与えたすべてのプレコンフをn + 1のBLブロックを提出するときに含める責任があります。これにより、シーケンサーは、彼らと最後のシーケンサーの間の完全な期間にわたってプレコンフを自信を持って与えることができます。

上記の説明を簡単にするために、私たちは単にL1提案者がこの事前設定の役割を果たすと仮定しました。しかし、前述のように、これはおそらくそうではないでしょう。プレコンフの価格設定、すべてのBRのためのフルノードの実行、すべてのBRトランザクションのDoS保護と十分な帯域幅など、高度なエンティティが必要とされるでしょう。 Ethereumはバリデータを非常に複雑にしたくないため、提案者はおそらくMEV-Boostを介して現在完全なL1ブロックの生産をアウトソースしているのと同様の方法でプレコンフをアウトソースすることになるでしょう。

提案者は、オンチェーンまたはオフチェーンのメカニズムを介してGate.ioをGate.iowaysに委任することができ、スロット直前まで行うことができます。前述のように、この役割は実際にはリレーに引き継がれる可能性が高いです。また、彼らがビルダーとも統合する必要がある可能性があります。

源：ベースドシーケンシング、ジャスティンドレイク

前述のように、一度には1つのエンティティのみがデリゲートされることができます。これは信頼性のあるステートプレコンフを提供するために必要です。ユーザーインターフェース（Metamaskなどのウォレット）は次のゲートウェイが誰であるかを確認し、ユーザートランザクションをそこに送信します。

イーサリアムのロールアップ - どの程度のベースになるのか?

十分な背景が整いましたが、イーサリアムロールアップはどうなるべきでしょうか？実際には2つの埋め込まれた質問があります。

1. 多くのEthereumロールアップはシーケンサーを共有すべきですか？
2. もしそうなら、それはベースのシーケンサー(つまり、イーサリアムBLの提案者と周囲のMEVインフラストラクチャを含む)であるべきですか?

まず、他のチェーンとの間でシーケンサをアドホックに共有できることが重要です。たとえば、イーサリアムの提案者は、最も入札が高い場合に1つのブロックをシーケンスできます。次のブロックは、最も入札が高い場合に他のBFTコンセンサスがシーケンスできます。ただし、これにはまだ完全に参加するチェーンが必要であり、これらの他のチェーンと同期して実行できる一元共有オークションに関しては、制御や柔軟性に関するトレードオフが存在します（共有ブロック時間など）。ただし、勝利したシーケンサエンティティがシフトするだけです。

とにかく、条件1が満たされたと仮定しましょう。この時点で、分散型の共有シーケンサーの使用に十分な需要が存在するという説得力のある証拠があると思います。彼らが「共有の側面」にあまり興味を持っていなくても、棚から買える分散型シーケンサーサービスを購入できることには非常に高い価値があると思います（実際、これが最も価値があると思います）。

今、この共有シーケンサーはイーサリアムベースのシーケンサーであるべきですか？

技術的な（提案者のコミットメント）

イーサリアムベースのシーケンサーを使用するための強力な技術的な議論は見当たりません。ブロックリレーションシップとイーサリアムL1の間の相互運用性は非常に制限されます。L1での信頼性のある実行ができない（つまり、L1状態に対して一貫して書き込みロックを持っていない）、長いブロック時間（12秒）、そしてL1と一緒に再編成する必要がある場合、L1と対話するためにBRトランザクションが行われることになります。ここには無料の昼食はありません。これによって他の外部共有シーケンサーと比較して、貴重なユーザー向け製品はロック解除されません。

私が見る主な価値は、このより大きな組み合わせオークションにEthereum L1を追加することで、より高いaggreGate.io価値が生み出される可能性があることです。l1がより多くの価値を捉えることを許可する.この論理を極端にまで進めると、おそらく世界中のすべてを同じオークションに入れるべきです。このユニバーサルオークションには、テイラー・スウィフトのコンサートチケットも順番に入れるべきです。私はまだそこまでは行っていません。

これは、実際には技術的および社会的な複雑さがあり、誰もがこの共有オークションに参加することを選択することの実際のコストがあることを強調するためだけです。私の考えでは、ここで生み出される理論上の追加価値を上回る可能性が高いです。イーサリアムL1の上にそれを取り付けることを試みていない場合、最初の原則からこれを実行するためのはるかに優れた技術的設計を簡単に構築できます（例えば、この目的のために構築された単純で高速なコンセンサスメカニズムを持っています）。また、このような組み合わせオークションは、指数関数的な複雑さを生み出すことになることは言うまでもありません。

実際には、私にとって重要なリスクがあり、イーサリアムにとっては深刻な反生産的な影響を与える可能性があります。このベースの事前構成アーキテクチャは、既にいくぶん脆弱なイーサリアムの供給チェーンにとって、MEVインフラストラクチャを加速する可能性があります。これにより、ネットワークの分散化と検閲耐性が危険にさらされることになります。それらが最初に価値のあるものになるのです。

ソーシャル（信頼性のある中立性）

私は、イーサリアムベースのシーケンサーに対して有効な社会的な議論があると考えています。

早期のBRにとって「アラインメント」というのは確かに魅力的なセールスポイントであることは間違いありません。ただ、これは持続的なものではないと思います。1番目のBRであることはカッコいいですが、8番目であることはカッコよくありません。何か他のバリューアドが必要です。

イーサリアムベースのシーケンサーの信頼できる中立性は、潜在的にその価値だと思います。これは、少なくともそのような設計を支持する最も強力な議論です。分散型シーケンサーを既製品にしたいと思っているチェーンはたくさんあります。最終的に、クロスチェーンのUXを向上させるのに十分なインフラストラクチャを設計することができれば、さらに良いでしょう。しかし、そのような設計を望んでいるプロジェクトの多くは、サードパーティのプロトコルに「味方を選ぶ」ことを躊躇していると思います。前述したように、ENS のような基本的な汎用インフラストラクチャを備えたアプリ チェーンで、ロールアップが必要だとします。(仮定の)Arbitrum共有シーケンサーを選択して楽観主義の群衆をオフにしたり、その逆をしたりしたくありません。

おそらく、ここでの社会的調整の問題に対する唯一の解決策は、信頼できる中立的な共有シーケンサーを持つことであり、イーサリアムは明らかにその最有力候補です。これは、信頼できる中立性に関して私が以前に述べた点にさらに重点を置いていることに注意してください - これがそのようなサービスの主要な付加価値であるならば、それはそれを作成する上で信じられないほど優先度の高い設計目標でなければなりません。独自の利益目的を持つサードパーティのプロトコルのペットプロジェクトのように見えてしまうと、うまくいきません。それは実際にイーサリアム共有シーケンサーでなければなりません。

値することに注意すべきは、「中立」という言葉は実際には「イーサリアム」を指すコードであるという合理的な批判もあるということです。つまり、その主な動機はイーサリアムとその周辺インフラの利益になるということです。もちろん、そのようなシステムはこれらの関係者に利益をもたらします。これはethという資産により多くの価値をもたらし、イーサリアムの開発者、中継者、および検索者により多くの利益をもたらすことを意味します。

高速ベースのロールアップ

高速なベースレイヤー

今私たちは、Ethereumのような遅いブロックチェーン上でbrsを持つことができ、より高速なuxのための信頼できる事前確認を追加することができ、また、暗号経済学的または暗号的な保証を介してチェーン間を移動する際の安全性を確保することができることを理解する必要があります。

ただし、もしも私たちがこのものを最初から設計する場合はどうでしょう。既存のチェーンの技術的な負債や意思決定に関わらずに。ものを構築するための明白な方法は何でしょうか...

以前、私たちは、特定のブロックチェーン（例：イーサリアム）に事前確認を伴うブロックリレー（BR）である唯一の技術的な理由は、その提案者がブロックチェーンと同期したアトミックなインクルージョンに関して信頼性のあるコミットメントを提供するためであることを話し合いました。

ただ、私たちは事前確認なしでブロックリレーになる能力について真剣に議論していなかった。イーサリアムは遅く、ユーザーは我慢できないため、この考えはほとんど捨てられました。

なぜ私たちは単に速いblを使用しないのですか？

これにより、以前に持っていたほとんどすべての複雑なエッジケースと懸念が解決されます。Gate.ioにおけるライブネスの失敗（ここでは安全性の失敗と同じ結果）のような奇妙なエッジケースを避けたいし、約束された事前確認（つまり、安全性の失敗）を取り消したくないし、イーサリアムの再編も望みません。これが一貫性が存在する理由です。

レイヤーは死んで、シーケンスレイヤー万歳です！

怠惰なシーケンサーに関するほとんどの会話は、それらをロールアップシーケンサーとして考え、そのデータを他のデータレイヤーにダンプすることを検討しています。たとえば、Astriaの最初の2つのロールアップ（フォルマとフレーム)は、彼らのDAレイヤーとしてCelestiaを使用します。Astriaのコンセンサスはこれらのロールアップをシーケンスし、そのデータをCelestiaに中継します。

この組み合わせは特に素晴らしいものです。なぜなら、Astriaはすべてのシーケンスインフラストラクチャを提供し、Celestiaは信頼度の最小化された検証を提供するからです。データ可用性サンプリング（DAS）.

ただし、Astriaは同様に、イーサリアム、ビットコイン、ソラナ、またはその他の希望するものに固有のロールアップをシーケンスするために使用することができます。例えば、それはイーサリアムの「BRS with preconfs」のように設定されることさえあります（つまり、中央集権化されたGate.iowayの代わりに、怠惰なシーケンサーは基本的にインセンティブ付きの分散型リレーです）。

ただし、すべてのチェーンはDAレイヤーです。フルノードは常にDAをチェックできます。データが利用可能であることは、すべてのチェーンの妥当性条件の一部であるため、コンセンサスは常にデータが利用可能であることを署名します。自己署名を確認する軽量ノードは正直な多数派を前提としています。唯一の違いは、チェーンがDAを直接サンプリングするための別のオプションを軽量クライアントに提供するかどうかです。

しかし、私が注記したようにロールアップはセキュリティを継承しますか？, astriaのような高速チェーンは、技術的にはdasのための遅いパスを追加することができます（検証性の向上のため）、そしてcelestiaのような遅いチェーンはシーケンシングのための高速パスを追加することができます（多数派の信頼の前提条件とdasなし）。このようなものを、「高速なブロック、遅い四角。

特定のレイヤー（例：シーケンシングやDAS）を垂直統合すると、モジュラーと統合されたブロックチェーンの違いがさらに狭まることになります。これは、垂直統合が同様に適用されます。決済層追加することによりZK検証アカウントは、セレスティアのベースレイヤーにあります.

ただし、これらのサービスをまとめるのではなく、それらを別々に保つことには意味のある価値があります。これは、ロールアップが棚から欲しい機能を選択できるモジュール化アプローチです（例：分散型シーケンシングと高速ブロックを購入したいが、DASの支払いはしたくない、またはその逆）。研究者はDASが欲しいと示していますが、ユーザーはこれまでに高速ブロックが欲しいと示しています。

"バンドリングサービスとしての"速いブロック、遅いスクエア「非常に意見がはっきりしており、統合されているでしょう。これにより必然的に複雑さとコストが増えます。スロットの長さがもたらす効果については、」タイミングゲーム（そしてしたがって分散化の可能性）は今、イーサリアム上で普及しているので、考慮すべきです。

高速なベースレイヤー対遅い+事前確認

ただし、astriaを単にロールアップのblとして使用することもできます。共有シーケンサは、自分自身のbrsに最適化されたblsと考えることができます。

あなたのblが速いと、あなたのbrは事前確認が必要ないので、そのまま高速な確認を得ることができます！その後、あなたのロールアップは実際にはあなたのblのリアルタイムセキュリティを得ることができますが、brs + preconfsでは必然的にこれを失います。

事前確認なしでのbrsは実際にはロールアップを構築する最も論理的な方法です。それが今日のロールアップがすべてそこから始まった理由です:

明らかに、高速ブロックを持つブロックレイヤーは、「ベースロールアップ + プレコンフ」のほとんどの問題を解決します。共有シーケンサーは、自然に「アプリ開発者は単に高速で信頼性のある分散型チェーンを立ち上げたい - それをどのように提供するか？」というファーストプリンシプルアプローチからより構築されます。イーサリアムのような遅いベースレイヤーにプレコンフを後から追加しようとすることは、上記で説明した複雑さをもたらします。

みんなが同じものを作っています

モジュラリティは避けられない

したがって、我々は、モジュラーチェーンを再集約する方法を見てきました。これにより、普遍的な同期可能性（usc）が提供されます。 もちろん、トレードオフはありますが、1つの状態機械を使用するよりもはるかに柔軟性を保ちながら、意味のある程度の統一性を再導入します。 大多数のユースケースには非同期の可能性が必要です。 低遅延、パフォーマンス、および優れたuxが必要です。 インターネットは非同期であり、それはかなり素晴らしい機能を提供しています。 可能性は暗号の大きな価値ですが、可能性≠同期です。

柔軟性と主権の利点はさておき、ほとんどの人はいずれにしてもスケールのために多くのチェーンが必要になると同意するでしょう。これはつまり、統一する必要のある多くのシステムができるということであり、モジュラーな方向性はここでは避けられないということです。

ethereum + preconfs → solana?

さて、ここでエンドゲームを比較しましょう。特に、Solanaのエンドゲームと、ベースのロールアップ+事前設定を使用したEthereumのエンドゲームを比較します。

このビジョンでは、私たちはEthereumベースのシーケンサーを使用するこれらのbrsの束を持っています。Gate.iowaysは、低レイテンシでユーザーに提案されたプロムプト（つまり、どの合意重量もない）のpreconfsを連続的にストリーミングし、Ethereum提案者が一定間隔でそれらを完全なブロックにコミットする。これは、ShredストリーミングでSolanaについて以前に説明したものとほぼ同じに聞こえるかもしれません！

だから、これは単なるより複雑なソラナなのですか？大きな違いはスロットの時間にあります：

イーサリアムは、遅いチェーンの上にこれを追加しようとすることは、一見すると問題があります。

• ユーザーにとっては、イーサリアムのコンセンサスは非常に遅いため、信頼性のある中立的な高速なユーザーエクスペリエンスを得る唯一の方法は、オプトインベースでのプロポーザープロミスドプリコンフです。現在の主なボトルネックは、巨大なバリデータセットのサイズによる署名集約です。MaxEBそして、改善された署名集約がここで役立つかもしれません)。
• これにより、提案者の独占がより長期化し、不正行為（例：事前確認の保留）によるMEVのキャプチャをより多く行うためのインセンティブと自由が向上します。
• Gate.ioが先行確認を遅らせたり、保留したりする場合、ユーザーの最悪の場合はイーサリアムのスロット時間に依存することに戻ります。たとえソラナブロックプロデューサーがそれぞれの独占的な地位内での連続的なブロックビルディングとストリーミングを停止したとしても、同じ理由である可能性が高いため、彼らにとってある程度合理的である可能性が高いと考えられますその後、最悪の場合は、迅速に回転するコンセンサスに依存することになります。ネットワークの信頼性のためには、今日も4つのスロットの独占が必要です.
• 実際には、最初は非常に少数のGate.iowaysが存在する可能性があり、Solanaのようなチェーンよりもより中央集権的なオペレーターセットが生まれる可能性があります。
• 提案者にとって潜在的に非常に高い担保要件（設計スペースがまだ進行中であることに注意）
• ここでは、生存性の問題が非常に高価であることに対する懸念があります（オペレータの生存性の問題が事前コンフィグのドロップにつながり、それによってユーザーの安全故障が発生するため、重度にスラッシュ可能でなければなりません）。

すべては迅速なコンセンサスで解決されます。 これらすべてのシステムがまさに私たちがまず最初にBFTシステムを作る理由です。 では、なぜイーサリアムはそのコンセンサスをより速くするべきではないのでしょうか？ スーパーローレイテンシのベースレイヤーブロックタイムを持つことには、あまり明らかでないトレードオフがあるのでしょうか？

幸いなことに、私には短いブロック時間が良いかどうかについてエッセイを書くほどの暇があります。短いスロット時間に関する主な懸念は、バリデーターおよびオペレーターの中央集権化に関するものです。具体的には、短いスロット時間との相互作用に関する懸念があります。タイミングゲーム：

イーサリアム上でタイミングゲームがすでに進行中であることがわかります。提案者は自分のスロットで後にブロックを提案し、他者の犠牲になってもっとお金を稼いでいます。リレーも提供しています。タイミングゲームをサービスとして提供する「それによって、彼らは同様にスロットの後のブロックを遅延させます：」

ソース:データは常に

タイミングゲームは、やや悪名高い話題になっていました。Justin vs. Tolyバンクレスポッドキャスト数週間前から:

例えば、他の人より100ミリ秒早いとします

1つのスロットがあるなら、他の人よりも10%多く稼げます

10秒のスロットがある場合、他の誰よりも1%多く稼ぐことができます

—ジョン・シャルボノー（@jon_charb)2024年6月4日

ジャスティンは主に、タイミングゲームが問題になると主張し、増分報酬が常に関連すると主張しました。トリーは主に、タイミングゲームは問題にならないと主張し、追加のMEV抽出から得られる増分報酬には十分な懸念がないと主張しました。

私は個人的には、ここでのゲームのタイミングの重要性を無視するのが難しいと感じています。

• 今日、私たちはすでにイーサリアム上でそれらを実践しているのを見ています。ソラナの議論これは、これがイーサリアムでMEVが以前から社会的に正当化されていたためだけで起こるものですが、これは説得力がありません。タイミングゲームに対する強い一般市民の抗議が早期に行われました それ以来、それは受容に変わりましたこの新しい現実の設計の周りに
• MEVリワードはかなり大きいです - 既に話が進んでいますMEV支払いは数十億ドルあります、ソファのクッションの下のペニーではありません。これで「ほんの数%多く」稼ぐだけでも、莫大な金額です。
• たとえステーカーが十分に収益感応的でないと信じていなくても、実際のオペレーターはビジネスを運営していますそれは彼らの最下部に直接つながります。
• Solanaは、利他的な大口利害関係者に頼る方が簡単です。（例：基金和大型投资者）在其生命周期的早期ネットワークがさらに分散化すると、それは持続可能ではありません.

私は明確に、ソラナとイーサリアムの両方が取り組んでいる方向に非常に多くの価値があると考えています。何もしない場合でも、実際にそれがすべて実践されるのを見ることができます。戦略的には、イーサリアムがここで異なる要素に注力することは合理的だとも思います。敵対的な状況下で検閲耐性を達成する手段として分散化を最大化すること。イーサリアムは非常に分散化されたプロトコルを維持するために多くの犠牲を払ってきましたが、それは長期的なゲームにとって必要なことです。類を見ないクライアントの多様性、ネットワークの所有分散、エコシステムの関係者、オペレーターの分散化などがあります。将来的に（そしておそらくいつか）ソラナが深刻な検閲圧力に直面すると、イーサリアムが自らの意思決定をした理由がますます明らかになるでしょう。

preconf.wtfは先週のzuberlinで起こり、おそらく驚くことではありませんが、みんながpreconfsとベースのロールアップについて話していました。それは本当にクールでしたが、私は個人的にはヴィタリックの話オンワンビット毎アタスター含有リストそして、バルナベの話実行提案者を過負荷させるのではなく（mev-boostからepbsからapsに）イーサリアムの将来にとって最も重要な存在になることです。

ソース：Barnabé monnot、mev-boostからepbsまで、apsまで

最近、事前の議論と基本的なロールアップの話が急速に勢いを増してきましたが、私は確かに慎重な方針を取っています。有名なVitalikは以下を設定しましたエンドゲーム：

ただし、私たちはまだ含蓄リストのようなより強力な反検閲保護を実装していないまま、「中央集権的な生産」にかなり深く入り込んでいます。基本的に、イーサリアムは、この下の画像の最下段の半分にいます。（半分と言うのは、検閲が実際には白黒ではないためで、イーサリアムには「弱い検閲」があり、つまり、ほとんどすべてのブロックが検閲されますが、すべてではないため、少し待つかもしれませんが、その後には含まれるでしょう）

source: ガバナンスの証明

経験的に、イーサリアムL1 MEVサプライチェーンは現在、集中型シーケンサーを持つこれらのL2よりもリアルタイムにより多くのブロックを検閲しています。

l2はすでにl1の最終的なcr(それでも非常に良い)をベースにせずに取得できます。ベースのプレコンフでは、イーサリアムプロトコルのリアルタイムセキュリティではなく、比較的集中したインフラプロバイダーのリアルタイムセキュリティを取得します。より良いリアルタイムcrのためには、シンプルなbftコンセンサスを実行する分散型シーケンサーにシーケンシングをアウトソーシングするのが最善の選択肢でしょう。これは、多くのチェーンを現在比較的集中したボトルネックに集中するよりもはるかに堅牢です。この状況は、実行オークションやインクルージョンリストなどの変更によって改善する可能性がありますが、まさに目の前にあるわけではありません。

これを考慮すると、イーサリアムL1のMEVインフラストラクチャに依存を拡大し、それをL2に定着させることが、今の段階で素晴らしい考えだとはっきりとは思えません。現時点で、ほとんどのイーサリアムの無検閲ブロックは、一つのビルダー（タイタン）に依存しており、CRツールはまだプロトコルに実装されていません。これは脆弱な状況で積極的に加速主義的に感じます。イーサリアムは確かにL2のUXを改善するために取り組むべきですが、最初に求めたすべての基本的な特性を犠牲にするべきではありません。

結論

私たちはみな同じものを建設しています。

まあ、そんな感じです。もちろん、これらはすべて文字通りまったく同じものではありません。これらのシステムの間には、常に実用的な違いがあります。しかし、暗号資産の包括的なメガトレンドは、私たち全員がますます類似したアーキテクチャに収束していることは明らかです。

それらの微妙な技術的な違いは、実際には彼らが最終的にどこに行くかに意味のある影響を与えることができます。これらのシステムが似たような最終目標に向かって収束しているとしても、それらのシステムのパス依存性が果たす役割の大きさを過小評価することはできません。

また、これらのことについては非常に理解するのがほとんど不可能です。ビタリックが言ったように:

「APSに対する注意点として、純粋に技術的な観点から見ると、実際にはかなり軽量であり、技術的なエラーの可能性は非常に低いと思います。しかし、経済的な観点から見ると、何かがうまくいかない可能性がはるかに高くなります...」

eip-1559のように、私たちは理論で解決できました。いくつかの素敵な経済学の会議に参加し、最初の価格オークションの危険性とその不利な点について学び、2番目の価格オークションは信頼できないことを理解しました。そして、それから、ブロックごとに局所的に固定された価格のメカニズムを使用しようと発見しました。そして、私たちはミクロ経済学で多くを成し遂げることができました。

しかし、apsはそうではありません。apsがシタデル、ジェイン・ストリート、ジャスティン・サン、または誰かがすべてのイーサリアムブロックの1％を生産するのか、99％を生産するのかという問題は、最初の原理から理解するのは非常に非常に難しいでしょう。おそらく不可能です。

ですから、私が今見たいのは、ライブの実験です。個人的には、今日と私がAPSに本当に深く満足していると感じることの間の差は、基本的に、中程度の価値、活動、コミュニティ、および実際の競合が発生し、それが1年間、場合によっては1年間長く続くイーサリアムL2で正常に動作し、実際にいくつかのライブ結果を見ることができることです。

ええ、私も何が起こるかわかりません。ただ待って見るしかありません。とにかく、私たちがこのゲームの結末にどのように集まろうとも、共通点は多いです。だから、どうか...

免責事項：

1. この記事は[から転載されましたdba].元のタイトル「みんな同じものを作っている」を転送します。すべての著作権は元の著者[jon charbonneau]に帰属しますこの転載に異議がある場合は、Gate.ioの学習チームに任せ、迅速に対処します。
2. 責任の免責事項：この記事で表現されている意見や考えは、著者個人のものであり、投資アドバイスを構成するものではありません。
3. 記事の翻訳はGate.ioの学習チームによって行われます。特に言及されていない限り、翻訳された記事のコピー、配布、盗作は禁止されています。