Astria のセットアップでは、ソーターは順序付けされたブロックを DA レイヤーとロールアップ ノードに送信します。ロールアップは、発注者からソフト ファイナリティ保証を取得し、(ブロックがファイナライズされた後) DA 層からハード ファイナリティ保証を取得し、有効なトランザクションを実行します。
ユーザーが期待するユーザー エクスペリエンスを提供するために、ロールアップ ノードは順序付けされたブロックを受け取ります (これは DA レイヤーにも送信されます)。これにより、ロールアップにソフトな決定性の保証を提供できます。これは、ブロックが最終的に DA 層で順番に並べられることを保証し、その時点でロールアップ ノードがトランザクションを実行し、新しい状態ルートを提供します。
リレーに関しては、Frontier Research の Ankit Chiplunkar と Ethereum Foundation の Mike Neuder による記事「Optimistic Relays and where to find them」を読むことを強くお勧めします。この投稿では、MEV ブーストのリレーがどのように機能するか、現在のトレードオフと運用コスト、および効率を向上させる可能性のあるいくつかの変更について詳しく説明します。興味深いことに、Flashbot の見積もりによれば、MEV-Boost でリレーを実行するには現在、年間約 10 万ドルの費用がかかります。
これは、ジョシュとジョーダンが以前アストリアにあった会社である Google を考慮すると、より理にかなっています。 Google 製品は、創設以来、AT のアイデア、特に Google 検索のアイデアからインスピレーションを受けてきました。AT は、個々のページや記事をモジュール化し、グローバル検索ウィンドウから直接アクセスできるようにすることで作成されています。
4D 詳細共有ソーター: 動作原理、集計理論、垂直統合
原題:「The Shared Sequencer」
作者: MAVEN11
コンパイル: Kxp、BlockBeats
Rollup が「すぐに使える」高度な検閲耐性、展開の容易さ、相互運用性、高速なファイナリティ、ライブ性、および MEV の民主化を達成できたらどうなるかを想像してみてください。それは壮大な目標のように思えるかもしれませんが、共有シーケンサーの出現により、すぐに現実になるかもしれません。ただし、すべてのロールアップが同じであるわけではないため、共有シーケンサー ネットワーク上で報酬と MEV を配布する方法を検討する必要があります。このペーパーでは、共有ランカー ネットワークがどのように実装されるか、および達成できる特性について検討します。
Shared Sequencer Networks は主に Alex Beckett によって紹介され、その後 Celestia チームと Espresso チームの Evan Forbes (および Radius) によって紹介され、このトピックをさらに詳しく取り上げた Jon Charbonneau による新しい記事も紹介されました。 Josh、Jordan、および Astria チームは、実稼働対応の初の共有シーケンサー ネットワークを構築しています。 Astria の Shared Orderer Network は、Rollup のトランザクションを実行せずに集約して注文するモジュール式ブロックチェーンです。
Astria のセットアップでは、ソーターは順序付けされたブロックを DA レイヤーとロールアップ ノードに送信します。ロールアップは、発注者からソフト ファイナリティ保証を取得し、(ブロックがファイナライズされた後) DA 層からハード ファイナリティ保証を取得し、有効なトランザクションを実行します。
共有シーケンサー ネットワークは、その名前が示すように、本質的にロールアップ互換シーケンサーのグループであり、さまざまなロールアップにサービスを提供できます。これには、後で詳しく説明するさまざまなトレードオフと特性があります。まず、ソーター (またはソーターのセット) の最も重要なプロパティを説明する必要があります。ロールアップでは、シーケンサーまたはシーケンサーのグループの主な要件は、検閲耐性またはライブ性です (セキュリティだけでなく、ベース層からもたらされるものもあります)。これは、注文者に送信された有効なトランザクションが、有限の時間内 (タイムアウト パラメーター) にチェーンに含まれなければならないことを意味します。共有順序付けグループは、トランザクションがブロック (つまり crList) に含まれていることを確認するだけで済みます。
モジュラー MEV パート II で概説したように、検閲耐性と即時性を同時に満たすことは非常に困難です。 Tendermint などのコンセンサス アルゴリズムでは、攻撃後の回復を確実に行うことができます。ただし、攻撃が発生した場合は即時性が失われます。基本的に、カスタム マスターノードを選択するのではなく、他のすべての照合者にブロックへの署名を要求することは、おそらく最適ではありません。これにより検閲耐性は向上しますが、「集中化」と単一マスターノードへの MEV 抽出というコストがかかります。利用可能な別のソート メカニズムは、Duality の Multiplicity と比較できます。これは、非マスターノード (またはソーター) が他のトランザクションをブロックに含めるための小さなツールです。全体として、ほとんどのコンセンサスプロトコルでは、検閲への耐性と攻撃後の即時性を達成するのが困難です。
使用できるもう 1 つのコンセンサス アルゴリズムは HotStuff 2 で、攻撃が発生した場合の即時性を保証します。
これにより、検閲または未署名の場合に、新しいマスターノードを選択するために最大のネットワーク遅延 (タイムアウト) を待つ必要がなくなります。これが分散型の注文者セットにとって興味深いコンセンサス アルゴリズムとなり得る理由は、追加のステージを追加することなくコンセンサスにおける即時性の問題を解決できるためです。マスターノードが最高のロック (特定の出力に同意する参加者の最高数) を知っていて、正直な当事者を説得できれば、問題は解決します。そうでない場合は、ある時点以降の正直なマスターノードがプッシュを担当し、次のマスターノードを支援します。たとえば、Hotstuff ノードは、新しいマスターに通知する前に切り替えメッセージを確認する必要はありませんが、新しいビューに直接切り替えて新しいマスターに通知できます。
Tendermint との違いは、どちらも 2 フェーズ (Hotstuff1 には 3 つ、Hotstuff2 には 2 つ) であるが、Tendermint は線形通信を行うが応答性がないのに対し、Hotstuff2 はリアクティブであることです。正直なマスターノードのチェーンが存在する場合、最初のマスターノードの提案を除くすべてのステップは前のステップからの情報量の取得に依存しているため、プロトコルは肯定的に応答します。共有オーダラー設定では、これにより、プロトコルは最下層にフォールバックすることなく、より優れた即時性を達成できるようになりますが、この可能性はキャンセルされません。
共有ソーターグループの構築
一連の注文者は、決済レイヤー (ロールアップが存在するレイヤー) にトランザクションを送信できます。特定の要件が満たされており、必要なブロック プロデューサーの数に達していない場合は、このコレーター グループに参加できます。これにより、レイテンシーやスループットなどが最適化されます。これらの要件は、ブロックチェーンのバリデーターになるために必要な要件と似ています。たとえば、特に財務状況を確実にしたい場合は、特定のハードウェア要件や初回デポジットを満たす必要があります。
共有注文者グループ (または分散型注文者グループ) は、トランザクションの正しい処理を保証するために連携して機能する次のようないくつかのコンポーネントで構成されます。
ノードにトランザクションを送信するためのロールアップ (フル ノード以外のオペレーターの場合) ごとに JSON-RPC をメモリ プールとして提供し、ビルドして並べ替えます。 mempool では、ブロックを効率的に構築するために、トランザクション選択プロセスだけでなくキューを決定するための何らかのメカニズムが必要です。
ブロック/バッチ構築アルゴリズム。キュー内のトランザクションを処理し、それらをブロックまたはバッチに変換します。このステップには、結果のブロック サイズを減らすための圧縮 (データ圧縮と呼ばれる) が含まれる場合もあります。前述したように、これは提案者 (本質的には PBS) とは別のものである必要があります。データは、次のようなさまざまな方法で圧縮できます。
データ フィールドの省略: データ フィールドは単純な転送には必要ありませんが、より複雑なトランザクションには必要です。
個々の署名を BLS 集約署名に置き換えます: 署名はイーサリアム トランザクションの最大のコンポーネントです。各署名を保存する代わりに、特定の数のトランザクションの BLS 集約署名を保存できます。また、メッセージ セットおよび送信者セットに対して BLS 集約署名をチェックして、その有効性を確認することもできます。
From フィールドをインデックスとして使用する: To フィールドと同様に、From フィールドをマッピングのインデックスとして使用できます。
「モジュール式」設計の興味深い概念は、ロールアップで機能させるために必要に応じて調整やトレードオフを行うことができることです。
共有順序付けセットのマスター ローテーション アルゴリズム (単一マスター選出の場合はコンセンサスは必要ありません)。マスター ノードのローテーション アルゴリズムのみを設定することも、Duality が提案する複数の同時ブロック プロデューサーのルートを選択することもできます。
前述の Tendermint や Hotstuff2 などのコンセンサス アルゴリズムは、ロールアップ ノードが台帳によって提案されたシーケンスと一致していることを保証できます。
ブロック/バッチを基礎となる DA+ コンセンサス層に送信するための RPC クライアント。これにより、ブロック/バッチを DA 層に安全に追加できるようになり、「最終的な」ファイナリティが保証され、すべてのトランザクション データがオンチェーンで利用可能になります。
公平性と一貫性を確保し、MEV の盗難を回避するために、ビルダーとブロックプロデューサーの役割を分離します。また、実行されたソートも削除されます。これは、効率を最適化し、PGA を削減し、CR を増加させるために重要です。
*ロールアップ ノードは、ソフト送信の場合はソーターから順序付けされたブロックを受け取り、ハード送信の場合は順序付けされた DA 層ブロックを受け取ります。 *
Calldata は最初にベース ネットワークに公開され、そこでコンセンサスが実行されてユーザーとロールアップ トランザクションが保証されます。次に、Rollup ノードはトランザクションを実行し、状態遷移関数を正規の Rollup チェーンに送信します。共有注文者のネットワークにより、Rollup は即時性と検閲耐性を備えています。ロールアップは、すべてのトランザクション データが基本レイヤーに保存されているため、いつでも共有注文者からフォークできるため、主権が維持されます。ロールアップ状態遷移関数 (STF) の状態ルートは、共有順序付け者から DA 層に送信されたトランザクション ルート (入力) から計算されます。 Celestia では、データがチェーンに追加され、コンセンサスに達すると、ステート ルートが生成されます。トランザクション ルート (および利用可能なすべてのデータ) がすでにあるため、Celestia はライト クライアント (Celestia 上で実行されているロールアップ ノード) に小規模な包含証明を提供できます。
ユーザーが期待するユーザー エクスペリエンスを提供するために、ロールアップ ノードは順序付けされたブロックを受け取ります (これは DA レイヤーにも送信されます)。これにより、ロールアップにソフトな決定性の保証を提供できます。これは、ブロックが最終的に DA 層で順番に並べられることを保証し、その時点でロールアップ ノードがトランザクションを実行し、新しい状態ルートを提供します。
ブロックの作成とスロット
ブロックの作成時間を決定するために、シーケンサーはスロットを設定する必要があります。シーケンサーは、固定間隔 (通常は X 秒) でバッチを送信する必要があります。X はスロット時間です。これにより、トランザクションが迅速かつ効率的に処理されることが保証されます。そうしないと、特定のスロットのマスターノードがタイムアウトになり、署名報酬 (および実行報酬) を失うことになるからです。たとえば、Celestia のブロック時間 (GitHub 仕様による) は約 15 秒です。これは既知であるため、共有コータのセットから DA 層までの「スロット/ブロック」の数と、ロールアップ ノードが最終的なブロックにロードされる可能性がある数についていくつかの仮定を立てることができます。この点に関しては、最適化された Tendermint または Hotstuff2 を参照できます。
同じスロット内で、トランザクションの複数のバッチを送信できます。ただし、設計にロールアップ フル ノードが (その期間およびタイムアウト パラメーター内で) 単一のブロックに効率的に処理するためのメカニズムが含まれている必要があります。これにより、ブロック作成がさらに最適化され、トランザクションが迅速に処理されるようになります。さらに、スロットを使用して、ソーター マスター ノードの選択を容易にすることもできます。たとえば、ステーキングの重みに基づいて、ステーキング プールからスロット マスター ノードをランダムに選択できます。これを機密性を維持する方法で行い、検閲を最小限に抑えるために秘密のリーダー選挙などを採用することが最善の選択肢です。あるいは、Obol/SSV などのソリューションなどの分散型バリデーター テクノロジのセットアップも最適です。レイテンシーとスロット時間は、ブロックの送信とプロトコルへのビルドに大きな影響を与えます。したがって、これがシステムにどのような影響を与えるかを調べる必要があります。 Bloxroute には、特にイーサリアムに関する優れた研究とデータ ポイントがいくつかあります。 MEV-Boost では、参加しているブロック プロデューサー (ロールアップの場合はバリデータまたはシーケンサー) がリレーから GetHeader を要求します。これにより、特定のブロックの値であるブロック入札値が得られます。これは、毎回受信される最高値のブロックである可能性があります。スロットごとに、バリデーターは通常、スロットの開始後約 400 ミリ秒で GetHeader をリクエストします。バリデーターの数が多いため、リレーは多くのリクエストを送信する必要があることがよくあります。これは、大規模な共有ソーター グループでも発生する可能性があります。これは、このプロセスを促進するためのインフラストラクチャが必要であることを意味します。
リレーは、ビルダーとブロックプロデューサーの分離を容易にすると同時に、ビルダーが正しいブロックを構築したかどうかを検証するのにも役立ちます。また、料金が正しく支払われているかどうかもチェックし、DoS 保護として機能します。また、彼らは基本的にブロックの管理者であり、バリデーターの登録を処理します。これは、誰が参加し、誰が参加しなかったかを追跡する必要があるため、無制限のシーケンサーのアーキテクチャでは特に重要です (たとえば、前に説明した同期層)。
ブロック時間 (つまり、作成者によって送信されたブロック) に関しては、通常は約 200 ミリ秒かかります。これらは主に約 200 ミリ秒の前後で実行を開始しますが、GetHeader と同様にかなりのばらつきがあります。ビルダーが複数のリレーにブロックを送信すると、かなりの遅延が発生します。 Bloxroute は、ブロックが複数のリレーに送信されたときに何が起こるかも調べました。ご想像のとおり、より多くのリレーへのブロック伝播の遅延は大きくなります。平均すると、2 番目のリレーがブロックに費やすのに 99 ミリ秒、3 番目は 122 ミリ秒、4 番目は 342 ミリ秒かかりました。
おそらく過去数か月で私たちが学んだことは、RPC がブロックチェーンにとって非常に重要であるということです。適切なインフラストラクチャがなければこれは大きな負担となり、適切な RPC オプションを持つことも重要です。この場合、RPC は、トランザクションを RPC (およびパブリック メモリプール) に送信する個人投資家にとって重要です。 Bloxroute は、さまざまな RPC に送信される 20 トランザクションの小規模なテストを実行し、各トランザクションがブロックに含まれるのにかかる時間を測定しました。
出典: Bloxroute Labs
興味深いことに、一部の RPC には、次のブロックでどのビルダーが勝つかに応じて、数ブロック後までトランザクションが含まれません。 RPC がトランザクションをより多くのビルダーに送信する場合、高速インクルードの可能性が高くなります。ただし、トランザクションの発信者が独自の立場を利用して、フローが特定のビルダーをターゲットにしたり、独自のブロックを構築したりすることは可能です。
彼らのパフォーマンスは、イーサリアムのリレーパフォーマンス統計でも興味深いものです。これは、複数のバリデーター/ビルダー/リレーの世界で PBS がどのように機能するかをより深く理解するのに役立ちます。これは、ロールアップ アップグレードで達成したいことです。 Metrika にはこれに関する素晴らしい統計があり、すべてのデータ ポイントはそれらに基づいています。
入札の失敗は、中継者が入札することが期待されていたにもかかわらず入札しなかった場合に発生することに注意することが重要です。ターゲットの期待値は、特定のスロットの特定のリレーに登録されているバリデータから得られます。これはリレーの障害そのものではなく、プロトコル レベルでそのように処理されることもありません。
出典: app.metrika.co
障害 (無効なブロックを提供するリレーなど) が発生し、それが原因である場合、それは障害としてカウントされます。これらは通常、まれであり、ほとんどは登録設定の失敗です (つまり、特定のバリデーターの登録と一致しないガス制限または料金)。さらにまれに、不正なスロットや前のブロックと一致しない親ハッシュなど、イーサリアムのコンセンサス レイヤーのルールと矛盾するコンセンサス レイヤーの障害が発生します。
レイテンシ (ビルダーによって構築されたブロック ヘッダーをバリデーターが受信するのにかかる時間など) の観点から見ると、データは非常に一貫しています。ただし、要求されたリレーが選択されたバリデーターとは異なる地理的場所にあるなど、外れ値がいくつかあります。
出典: app.metrika.co
ビルダーに関しては、MEV-boost のビルダーの総数は約 84 で、上位 3 つのビルダーが構築済みブロックの約 65% を構築しています。ただし、これらは最も長く続いているビルダーでもあるため、これは多少誤解を招くかもしれません。時間枠が短縮された場合でも、結果は同様になります。実際にアクティブなビルダーの数はこれよりはるかに少なく、過去 30 日間で 35 人、過去 1 週間で 24 人です。競争は熾烈で、通常は最も強いビルダーが勝ちます。排他的な注文フローがすでに存在している可能性がありますが、これは状況を悪化させるだけです。セットアップに大きな変更を加えない限り、ビルダーの配布は比較的集中化されたままになると予想されます (これは最適な注文フローとハードウェアの最適化をめぐる競争であるため)。根本的な問題ではありませんが、依然としてスタック内での集中力が影響しており、現状を打破する方法についてのアイデアをぜひお聞きしたいと考えています。この (深刻な) 問題をさらに深く掘り下げることに興味がある場合は、注文フロー、オークション、集中化に関する Quintus の記事を読むことを強くお勧めします。
将来のモジュール性スタックの Builder ロールについては、(少なくとも Cosmos SDK セットアップでは) Skip/Mekatek のような Builder Modules セットアップが登場すると確信しています。もう 1 つの解決策は、PBS を確保するために任意の数のチェーンにブロック構築および入札優先サービスを提供する特定のグローバル ビルダー チェーンなどの SUAVE タイプのセットアップです。このソリューションについては後でさらに詳しく説明し、ここで取り上げられていない質問に対する回答をいくつか提供します。
リレーに関しては、Frontier Research の Ankit Chiplunkar と Ethereum Foundation の Mike Neuder による記事「Optimistic Relays and where to find them」を読むことを強くお勧めします。この投稿では、MEV ブーストのリレーがどのように機能するか、現在のトレードオフと運用コスト、および効率を向上させる可能性のあるいくつかの変更について詳しく説明します。興味深いことに、Flashbot の見積もりによれば、MEV-Boost でリレーを実行するには現在、年間約 10 万ドルの費用がかかります。
決定論的
モジュラーブロックチェーンの決定論（現在の姿）について話す前に、前回の「モジュラー MEV」の記事を見てみましょう。これはファイナリティの「公式」または包括的な見解ではありませんが、理解しやすいようにロールアップ ファイナリティの微妙なニュアンスを最も正確に表していると考えられます。
Pending_On_L2: ロールアップ オーダラーは、ユーザーのトランザクションが最終的にそのセキュリティの基本層でコミットされ、完了するというソフト コミットメントを表します。
Finality_On_L2: シーケンサーはロールアップの状態遷移関数にコミットし、ブロックはロールアップの正規チェーンに追加されました。
Pending_On_L1: トランザクションの入力または出力/状態遷移関数は L1 に公開されましたが、有効性証明がまだ発行されていない、または調停期間がまだ終了していません。これには、連続する 2 つのエポックでイーサリアムが必要です。これは、ほとんどのオプティミスティック ロールアップがファイナリティに達したと言っているポイントですが、仕様のクロスチェーン ブリッジによると、この時点ではまだ任意の 7 日間のチャレンジ期間が存在します。
Finality_On_L1: オプティミスティック ロールアップの場合、仲裁期間が終了したか、公開および検証された有効性の証明が 2 つの連続したエポックで超過半数によって確認されました。
さて、ソブリン共有並べ替えロールアップでは、これは少し異なって見えます。図を使って説明してみましょう。
この場合、理論的には、L2 よりも先に L1 で決定性を得ることができますか?はい、この場合、結局のところ L2 はソブリンです。これは、不正行為の証明や異議申し立て期間がないこと、または有効性の証明を使用していることを前提としています。
では、これらのレベルのファイナリティをどのように達成するのでしょうか?ブロックのファイナリティは、ブロックが正規チェーンに追加されるときに達成されますが、これを取り出すことはできません。ただし、フル ノードかライト ノードに応じて、いくつかのニュアンスが異なります。順序付きブロックの場合、DA 層ブロックに含まれると決定的になります。ブロック (状態ルートを含む) は、ロールアップ フル ノード/バリデータによって強制され、ベース レイヤーの順序付けされたブロックから導出される有効な状態ルートが保証されます。フル ノードを超える決定性 (ライト クライアントやクロスチェーン ブリッジなど) を実現するには、この状態ルートの有効性を確認する必要があります。ここでは、以下で説明するいずれかの方法を使用できます。また、もう 1 つのアプローチは、保証金とその後の不正行為の証明を通じて、バリデーターにステート ルートの正しい証明 (楽観的ルート) の責任を負わせることです。さらに、有効性証明 (ZK) を提供することもできます。
ブロックのファイナリティを達成するためのさまざまな方法:
プルーフ・オブ・ワーク (PoW)、LMD+ゴースト、金魚、ウロボロス (PoS)、およびその他の確率的手法による。
ブロックに署名する十分な委員会メンバーによる証明可能な方法。 (例: Tendermint 2/3、Hotshot2、またはその他の PBFT タイプ)
DA 層上のトランザクション/ブロックの順序とそのルール、つまり正規のチェーンとフォークの選択ルールに依存します。
さまざまなメカニズムを通じて、さまざまなタイプのファイナリティを実現できます。
ファイナリティの 1 つのタイプは「ソフト ファイナリティ」(保留中など) で、これは 1 回のリーダー選挙によって達成できます。この場合、各スロットには 1 つまたはゼロのブロック (コミットされているかどうか) のみが含まれ、同期層はこれらのブロック内のトランザクションのシーケンスを安全に想定できます。
ファイナリティの別のタイプは「証明可能なファイナリティ」で、これはソフト ファイナリティよりも強力な保証 (本質的に最終的な) を提供します。証明可能な最終性を達成するには、注文者の大多数がブロックに署名し、それによってブロックが正規であるという同意を表明する必要があります。このアプローチは優れていますが、単一のリーダー選挙が実装されている場合は、基本的にブロックの順序付けが保証されるため、必要ない可能性があります。明らかに、これは実装されている特定のリーダー選出アルゴリズムに依存します。たとえば、51% の実装、66% の実装、または単一のリーダー (できればランダム (VRF) および秘密選挙) ですか。イーサリアムの決定論についてさらに詳しく知りたい場合は、強くお勧めするこの記事と、後で無制限のソーター セットについてお勧めする記事を読んでください。
ライセンス付き、セミライセンス付き、または無許可
潜在的な DoS 攻撃を防ぐには、発注者グループに参加し、発注者層にトランザクションを送信するために経済的障壁を設定する必要があります。制限付き (ソーターの数が制限されている) グループと制限なし (ソーターの数が無制限) のグループでは、同期層 (ソーター間でブロックを伝播する) を防ぐために、DA 層にバッチを送信するために経済的障壁を設ける必要があります。速度が遅くなったり、DDoS 攻撃を受けたりする。ただし、DA レイヤーへのデータの送信にはコスト (da_fee) が必要となるため、DA レイヤー自体もある程度の保護を提供します。無制限のグループに参加するために必要な保証金は、同期層がスパム送信されるのを防ぐために必要な追加コストをカバーする必要があります。一方、制限されたグループに参加するために必要なマージンは、需要に依存します (コストと収益の観点からバランスが取れています)。
制限のないソーターのセットの場合、ソーター層で証明可能な最終性を達成することはできません (アクティブな投票者/署名者が何人いるのか正確にわからないため)。一方、境界のあるコータのグループでは、大多数のコータがブロックに署名することで証明可能な最終性を達成できます。これには、同期層がシーケンサー層と、常にアクティブなシーケンサーの数を認識する必要があり、追加のオーバーヘッドが発生します。ソーターの制限されたセット (例: 最大 100) では、分散化と検閲への耐性を犠牲にしてでも、ソーターの数を最適化して「パフォーマンス」を向上させることもできます。 「迅速な」証明可能な確実性を提供するための、限定されたグループと経済的保証の重要性も決定論的です。
Unbounded sorterとBounded Sorterの種類は従来のブロックチェーンにも反映されており、例えばEthereumのPoS(Casper+LMD-GHOST)はUnbounded型を採用しているのに対し、Cosmos SDK/TendermintベースのチェーンはBounded型を採用しています。興味深い考えは、プルーフ・オブ・ステークのような経済性や共有注文者のコミュニティからのオプションが期待できるかということです。この点で、一部のエンティティを集中化する動きが見られました (したがって、既に大規模なプルーフ オブ ステーク プロバイダー/プールがある場合、無制限であることはあまり問題になりません)。たとえ集中化を「隠し」たとしても、結局のところ、必要に応じてマイニングすることができます。イデオロギー的な観点から見ると、選択肢にはほとんどの場合制限がないはずですが、いずれにせよ、経済原則によりそれらの選択肢は非常に似通ったものになることに注意してください。参加者が誰であっても、DA のコストやハードウェアのコストなど、支払うものの経済性は同じである必要があります (ただし、これは、割り当てて経験するプルーフ オブ ステークの数によって削減される可能性があり、効率的です)インフラストラクチャの運用）。制限された PoS の世界でも、インフラストラクチャプロバイダーのグループが、ほぼすべてのチェーンで最大かつ最も一般的なバリデーターになるのを私たちは見てきました。ほとんどの Cosmos チェーンでは、バリデーター間の依存関係がすでに非常に大きくなっており、これは確かに前記チェーンの分散化と検閲への抵抗に危険をもたらします。それでも、非常に異なる事実は、個人投資家は、自分が選択したバリデーターで任意の金額を賭けることができるということです。残念ながら、これは通常、リストの一番上に割り当てられ、人生は続いていきます。私たちはもう一度問います。モジュール式の世界でも同様の経済モデルが期待できるでしょうか?そうでなければいいのにと思うかもしれませんが、特化すると最適な人材が必要になることが多く、彼らはプロのプルーフ・オブ・ステークプロバイダーであることが多いです。これらの経済問題については、後ほど別の章で説明します。
ただし、これらすべての問題で覚えておくべき重要なことの 1 つは、最も重要なことはエンド ユーザー認証であるということです。エンド ユーザー認証は、ライト クライアントと DAS ピラミッドを通じて、どこにいても (ギザであっても) 誰でも利用できます。
出典: @JosephALChami
有界ソーターと無制限ソーターのトレードオフと利点は次のとおりです。
無制限のソーターセット:
*十分な債券/ステーキングを持っている人なら誰でも選別者になれる = 高度な分散化
ソーターの境界セット:
これは、単一スロットの決定論と超「多数」の委員会を持つイーサリアムのソリューションの 1 つです。
これらのソーター セットを監視し、新しいメンバーを追加または削除する方法については、かなりの設計の余地があります。たとえば、これはトークン所有者のガバナンスを通じて達成されるでしょうか (では、コレクションを使用する多くの異なるトークンとロールアップはどうでしょうか?)。これは、オフチェーンでの変更のシグナリングが社会的合意を通じて可能になる可能性があることを意味します（例としてイーサリアムを取り上げます）。ただし、実際のオンチェーンのコンセンサスは明確に確立されており、コンセンサスルールに違反した場合の罰則はすでに存在することに注意してください。
共用仕分け機の経済メカニズム
シーケンサーのネットワークを共有する経済性により、いくつかの興味深いオプションが可能になります。前に説明したように、共有注文者ネットワークのバリデーターは、一般的な L1 バリデーターとそれほど変わりません。参加するネットワークは、インテント (以前は PBS) を受信し、トランザクションを提案して注文するという 1 つのタスクを実行するように単純に最適化されています。 「通常の」バリデーターと同様に、収益とコストのコンポーネントがあります。方程式の両側において、通常の L1 と同様に、バリデーターが参加するネットワークには大きな柔軟性があります。
収益は、最終的に対話を希望するユーザーまたはロールアップから得られ、共有シーケンサーの使用に対して一定の料金を支払います。この料金は、引き出した MEV の割合 (数字の入力は概算が難しい場合があります)、クロスチェーン価値の転送、ガス、またはインタラクションごとの定額料金である可能性があります。最も適切な収益ソリューションは、共有セキュリティと流動性の利点とともに、ロールアップ共有注文者を通じて得られる追加価値よりも少ない価値を共有注文者に支払うことかもしれません。しかし、この欠点は、スタックの別の部分による分散化のメリットを定量化するのが難しいことです。ただし、共有注文者ネットワークが独自のエコシステムに成長するにつれて、手数料を抽出する能力が高まる可能性があります。これは主に、一定の規模のメリットをもたらし、簡単に集約できる固有の能力によるものです。より多くのロールアップとアプリケーションがネットワークに参加するにつれて、より多くのクロスドメイン MEV が抽出できるようになります。
コストの点では、共有注文ネットワークにも競合するオプションがあります。 DA レイヤーでの公開コストや、ロールアップでのアプリケーションとの対話コストを資金提供することで、ネットワーク使用量を簡単に賄うことができます。これは、Web 2.0 企業が使用する戦略に似ています。ユーザー獲得 (またはロールアップ) での初期損失を負担し、長期的な収益が料金を上回ることを期待します。もう 1 つのより斬新な、または暗号ネイティブな方法は、Rollup がそのネイティブ トークンを使用して DA 料金を支払うことを許可することです。ここで、共有ソーター層は、DA 層でデータを公開するために必要なトークンとロールアップのネイティブ トークンとの間の価格リスクを負います。本質的には、これも共有ソーターの初期費用ですが、「サプライヤー」のトークン (つまり、ロールアップ) を取得することでエコシステムの一貫性を生み出します。これは、AppChain の論文で説明した倉庫の構築に似ており、さまざまな形式の DA を使用してコストを削減できます。異なる DA 層では、使用率、ライト クライアントを通じて簡単に検証できるユーザーの機能、または単純に異なるブロック サイズの選択に応じて、異なる価格設定が提供されます。最後に、共有順序付け者は、DA レイヤーに公開する前にトランザクションをバッチ処理することもできます。 ZKR の場合、これにより一定数のトランザクション残高を通じてトランザクション コストを削減でき、ORU に関しては、現在さまざまなロールアップで確認できるさまざまなバッチ処理ガスの最適化を実行できます。これにより、DA 層に公開する必要があるデータの量が減り、それによって共有シーケンサー ネットワークのコストが削減され、ネットワーク全体の収益性が向上します。これには、相互運用性の制限とブロックのファイナリティ時間の変更 (前述の L1 での決定性) という代償が伴います。
全体として、シーケンサーのネットワークを共有することの経済性により、興味深い実験やブートストラップ戦略が可能になります。主な違いはエコシステムのサイズであるため、クロスドメイン MEV の数はコストの面よりも大きいと推定しています。また、共有注文者に関する Espresso チームのブログ投稿をチェックすることを強くお勧めします。これらのタイプのネットワークの経済的トレードオフ (および利点) についても取り上げています。 Rollup が (経済性以外に) 共有ソーターを活用しようとする理由を示すために、集計理論の観点から考察することができます。
集計理論と共有ソーター
共有ソーターによってもたらされる特性を説明するもう 1 つの方法は、集約理論のレンズを通してです。アグリゲーション理論とは、プラットフォームまたはアグリゲーターが他のプラットフォームとそのユーザーを体系的な方法で統合し、ユーザーの注目を集める方法の概念を指します。基本的に、ゲームを希少なリソース (ブロック スペースなど) の割り当てから、豊富なリソースを制御する必要性へと移行させています (この例でも、ブロック スペースは意味を成しています)。集約理論は、実際にサプライヤーと製品 (つまり、ロールアップとブロックスペース) をスーパー ユーザー エクスペリエンスに集約し、集約されたユーザー ベースにサービスを提供します。これらのアグリゲーターのネットワーク効果が増大するにつれて、この関係はますます排他的になっていきます。そうなると、ユーザー エクスペリエンスが同様のセットアップ間での重要な差別化要因になります。新しいユーザーを引き付けるインセンティブ (優れたユーザー エクスペリエンスや相互運用性の向上など) がある場合、ネットワーク効果により新しいサプライヤーと新しいユーザーの参加が促進されるため、Rollup が独自のネットワークまたは別のセットアップに移行する可能性は低くなります。これは、プロバイダーとユーザーの観点からだけでなく、総合的な検閲耐性の観点からもフライホイール効果を生み出します。
出典: Aggregation Theory 2015、Ben Thompson
共有ソーターの領域では、集計理論はさまざまなロールアップの「組み合わせ」およびフェデレーションとして見なすことができ、すべてスタックの同様の垂直方向を利用し、ユーザーが同じエクスペリエンスを得ることができるようにしながら、自分自身と他の人に権限を与えます。
プロバイダー (ロールアップなど) は、理論的には共有コーター セット専用ではありませんが、実際には、共有コーター セット、そのロールアップ、およびユーザーは、これらのロールアップの使用量の増加につながるネットワーク効果の一連のループから恩恵を受けます。これらの利点により、ロールアップとユーザーは共有スタックに簡単に統合できます。参加しないと失うものが多くなるからです。単一のシーケンサー セットを共有するロールアップが 2 つだけの場合、これらのメリットはわかりにくいかもしれませんが、ロールアップとユーザーを方程式にどんどん追加すると、より明確になります。共有ソーター セットは、ユーザー自身が共有ソーター セットと対話していることを知らなくても、トランザクションを注文するときにユーザーと直接の関係を持ちます。ユーザーの観点からすると、対話する理由があるロールアップを使用しているだけだからです (これは、発注/仕分け担当者が排他的になることを意味します)。これらのソーターのコストは、ブロック スペースとそれを保護するトークンがエンド ユーザーにとって価値がある限り、実際にかかるソーターを実行するためのハードウェア コストだけです。取引手数料はデジタル化され、ユーザーのウォレットから支払われ、おそらく将来的には、アカウント抽象化における支払いホストなどの進歩によって抽象化することも可能になります（ただし、DA、注文、実行のコストは誰かが負担する必要があります）。
これは、ジョシュとジョーダンが以前アストリアにあった会社である Google を考慮すると、より理にかなっています。 Google 製品は、創設以来、AT のアイデア、特に Google 検索のアイデアからインスピレーションを受けてきました。AT は、個々のページや記事をモジュール化し、グローバル検索ウィンドウから直接アクセスできるようにすることで作成されています。
共有ソーター セットの場合、ロールアップを使用するユーザー (ソーター セットを共有するユーザー) の取得コストはますます低くなります。これは、サプライヤー (ロールアップ) の数が増加するにつれて、そのセットに惹かれる可能性が高いためです。 。これは、サプライヤーの数に応じてアグリゲーターの価値が増加するため、ほとんどの場合、アグリゲーター (またはマルチアグリゲーター) には双方にとって有利な効果がある可能性があることを意味します (もちろん、ユーザー エクスペリエンスが良好である限り)。対照的に、単一のシリアル ネットワークでは、顧客の獲得は単一のネットワークとそのアプリケーションに限定されます。ユーザーが別のロールアップでロールアップ アプリケーションを使用したい場合は、(現在の制限内で) ネットワークから完全にログアウトする必要があります。これは、ユーザーの粘着性と価値がそれほど高くないことを意味し、また、別のロールアップ エコシステムが高く評価されている (またはより多くのインセンティブがある) 場合には、いつでも資本が失われる可能性があることを意味します。
属性とトレードオフの概要
属性
共有ソーター セットは、複数のロールアップのトランザクションを集約して並べ替えるロールアップ ネットワークです。これらのロールアップは同じソーターを共有します。このリソースのプールは、ロールアップがより強力な経済的セキュリティと検閲防止機能を獲得し、高速でソフトな決定論的な保証と条件付きクロスロールアップトランザクションを提供できることを意味します。
現在、同じソーターのセットを共有するロールアップ間でアトミック性について多くのノイズが発生しています。主にデフォルトでアトミックであるかどうか、つまりアトミックではないという点です。ただし、問題のロールアップが条件付きトランザクションを含む相互の状態遷移関数 (STF) を依存関係として実装している場合、(共有ソーター セットの場合と同様に) スロット/ブロックタイムのアライメントが続く限り、ロールアップ間のアトミック性を実際に達成できます。この場合、アトミックな相互運用性を実現するには、チェーン A 上でチェーン B のライト クライアントを実行するだけでよく、その逆も同様です (IBC の仕組みと同様)。 (単一のフル ノードをライト ノードとして信頼するだけでなく) セキュリティ対策の相互運用性をさらに強化するには、ZKP (Proof of State) を実装して、状態の正確性を確保するという「神託の問題」を解決できます。これにより、条件付きトランザクションなどがそれらの間の正規のクロスチェーンブリッジにヒットしたかどうかをより明確に確認できるようになります。不正行為を証明する可能性もありますが、明らかに異議申し立て期間が残されることになります（つまり、このリスクのコストをカバーするために第三者が現れることになります）。また、ライト クライアント (フル ノードではなく) の場合、署名ヘッダーと不正防止ウィンドウ (存在する場合) を待機するため、少なくとも 1 ブロック遅れます。
私たちは、「クロスチェーン ブリッジ」問題は、軽量クライアントとゼロ知識証明によって解決される可能性が最も高いと考えています。この場合に (スマート コントラクトではなく) 軽量クライアントを使用する場合の課題は、ロールアップ ノード側のハード フォーク (アップグレードなど) がブリッジの実行を維持するために相互に調整する必要があることです (IBC が有効にする必要があるのと同じです)。同じ状態モジュール)。この特定のトピック (およびそれに取り組む方法) についてさらに詳しく知りたい場合は、このプレゼンテーションをチェックすることを強くお勧めします。
共有オーダラーが非常にうまく拡張できる理由は、共有オーダラーが (今日の集中型オーダラーのように) 状態を実行したり保存したりしないためです。同じことがロールアップ ノード自体にも当てはまります (ノード間でアトミック性が必要な場合を除く - 例: ライト クライアント/状態証明)。これらのノードは、ロールアップに対して有効なトランザクションと、それらに対して有効な条件付きクロスドメイン トランザクションのみを実行します。ロールアップ ノードが複数のロールアップの状態を実行して保存する必要がある場合、スケーラビリティが妨げられ、分散化 (したがって検閲への耐性) が低下します。これは、ブロックプロデューサーとビルダーの分離 (PBS) の概念も強化します。ただし、ビルダーとブロックプロデューサーを完全に分離する必要はまだあります。現在の設定では、オーダーラーは基本的にビルダーおよびブロックプロデューサーです (ただし、トランザクションは実行しません)。理想的なセットアップは、注文者が、高度に最適化されたビルダー セットアップからのブロックに盲目的に署名し、ブロックが正しく実装されていることを保証するためだけに存在するセットアップです (同時に、その証明書に対する高度な経済的確実性と検閲への耐性を提供します)。このようにして、高度なセキュリティとロールアップ ノードへのソフト ファイナリティを保証するコミットメントを提供できます。
クロスロールアップ条件付きトランザクションの場合、ロールアップ ノード (エグゼキューター) が中間状態ルートを提供できるようにするためにも存在し、ロールアップ間のアトミック性を可能にします。
＃＃＃ トレード・オフ
前述のタイムアウト パラメーターは、オーダーラー セットのマスターノード/コンセンサス メカニズムに応じて、MEV とトランザクションの包含にいくつかの興味深い影響を与えます。たとえば、アプリケーション固有のチェーンに関する論文でタイムアウト パラメーターが比較的短いと説明されている場合、分散された順序付け者のセットのブロックプロデューサーができるだけ早くデータを公開することが重要です。そのような世界では、マスターノードになるために競い合い、利益が得られなくなるまでブロックスペースを求めて DA レイヤーに入札する「バリデーター」間の競争が見られます。
Evan が Celestia フォーラムに投稿した Lazy Orderer の投稿で取り上げたように、トランザクションが基本層 (この場合は Celestia) に公開されるのを待ってから実行するのは非常に非効率的です。これからは、ベースレイヤーのブロック時間によって制限されます。これは、ユーザーエクスペリエンスを待つには長すぎます。より良いユーザー エクスペリエンスを実現するために、共有注文者は (前述したように) ソフトな決定論的なコミットメントを備えたロールアップを提供します。これにより、(分散化と高い検閲耐性を維持しながら) 既存の集中型ロールアップで慣れ親しんだユーザー エクスペリエンスがユーザーに提供されます。ソフトコミットメントは本質的には取引の最終注文に対する単なるコミットメントですが、重い経済的保証とリリース後の迅速な完了に裏付けられています。これは（冒頭で述べたように）不正行為の証明でもカバーされます。実際のハード ファイナリティは、すべてのトランザクション データがベース レイヤに公開された後に達成されます (つまり、L1 が実際にはより高速なファイナリティを達成します)。それは、Rollup が主権証明の検証に詐欺証明を使用するか、ゼロ知識証明を使用するかによって異なります。これは Rollup で行われます。この分離が必要な理由は、ソーターからの状態遷移の大きなボトルネックを取り除くためです。代わりに、ロールアップ ノードは、それらのノードにとって有効なノードのみを処理します (つまり、適切な相互運用性のために、条件付きトランザクション、状態証明、またはライト ノード検証を追加する必要があります)。ハード決定論は依然としてベース レイヤに依存します (ただし、これは Celestia では 15 秒に達する可能性があり、Tendermint でも決定論的です)。これにより、ロールアップでは比較的高速なハード決定論が保証されます。
ネットワーク内でゼロ知識証明を使用して、検証とトランザクション サイズを最適化します (たとえば、状態の違いのみを公開します。ただし、これにより、ZKP が公開されるまで、より高いレベルの信頼が追加されます)。前述したように、これらの状態証明を使用すると、接続されたチェーン/ロールアップの相互運用性が (チャレンジ ウィンドウを待たずに) 簡単かつ高速になります。
これらの条件付きトランザクションの欠点は、より高価になる可能性が高く、より高い検証および発行コスト (Cosmos チェーンで補助されている Tendermint ブロック ヘッダー検証のコストなど) が必要となり、システムに多少の待ち時間が追加されることです (ただし、それでも分離ロールアップよりもはるかに高速です)。垂直共有統合によって達成されるアトミック性は、これらの問題を補うことができます。
新しいロールアップのブートストラップ段階では、コレーターの共有セットを使用することは非常に合理的であり、プロバイダーとして得られるメリットは、堀レベルで「強制」される可能性のあるトレードオフの一部を上回る可能性があります。ただし、すでに成熟したロールアップでは、多くのトランザクションと経済活動が行われているため、外堀の一部を放棄することはおそらく意味がありません。
このため、すでに成熟したロールアップを共有セットに参加させるために、抽出された MEV の同様の経済的/トランザクション的な (ロールアップごとの) 重み付け再配布が必要なのか、あるいは、非常に成熟したロールアップが独自のネットワークを生成しないようにする必要があるのかという疑問が生じます。これはすべてかなり理論的なものですが、さまざまなレベルのアクティビティを持つ多くのロールアップ間で、共有垂直世界の MEV がどのように表現されるかに関して、興味深い思考プロセスであることは間違いありません。たとえば、価値を推進する独自のロールアップが、シーケンサー セットを介して他のロールアップと利益の一部を共有する場合 (おそらくあまり「価値」をもたらさない)、独自のサイロ化されたシステムに移行する理由がさらにあるはずです。これについては、EigenLayr の Sreeram にもいくつかの考えがあるので、併せて読むことをお勧めします。
検索者が新しいチェーンを開発するにはかなりの技術的コストがかかることを考慮すると、これはますます重要になるため、標準化して「彼らの」MEV に対するある程度の主権を提供することから始めるのが良いかもしれません。実際には、MEV では支配的なインターフェイス (またはソフトウェア) が勝つ可能性がありますが、インフラストラクチャの重要な部分を実行してそのソフトウェアを収益化することは実際には非常に困難です (集中化につながります)。市場レベルでは、共有注文者が提供するものは基本的に複数のプロバイダーに共通のメモリプールであり、集中オークションが行われるため、より健全な競争につながる可能性があります。
ここでの懸念は、共有セット内で 2 つのロールアップがソーターを実行している場合、「経済性の低い」値 (A) のロールアップが選択され、ロールアップからの多額の MEV + 手数料を伴うロールアップ (B) が提案される可能性があることです。 。ロールアップ B の観点から見ると、孤立したアプローチでは自分たちのために保持していたはずの価値を本質的に逃していることになります。
相互運用性のトレードオフへの対処
相互運用性によってもたらされるトレードオフに関する別の注意事項と、いくつかの問題を解決する別の方法は次のとおりです。
共有注文者ネットワークの目的は、複数のチェーンに正規の保証を提供することであり、これは明らかにこのケースでは大きな利点です。これを、ロールアップ間の効率的な状態遷移を保証するメカニズムと組み合わせることができます。これは、委員会ベースのアプローチ (例: PoS)、安全な証明 (楽観的アプローチ)、または私たちが推奨するアプローチ、つまり委員会の署名に裏付けられた ZKP の可能性があります。共有ソーターは「遅延」であるため、複数のロールアップのトランザクションをソートするためのスーパー ブロックのみを作成し、特定のトランザクションの実行は特定のロールアップに任せられます。 Proof of State (つまり、Lagrange、Axiom、Herodotus など) はすべて、ソブリン ロールアップ全体でファイナリティの証明を取得する可能性がある解決策です。ステーキングプールやEigenLayrなどを通じて、経済的に保証されたファイナリティの証明を追加することもできます。基本的な考え方は、共有ソーターが順序付けの経済的保証を提供し、このソートから生成される有効性証明が決定的であるということです。基本的な考え方は、ロールアップは互いに同期してトランザクションを実行できるということです。たとえば、2 つのロールアップ ノードからなるネットワークは、ZKP と利用可能なデータ (効率的な DA レイヤーに公開されたデータ) を介して、両方のロールアップ履歴が有効であることを条件付きで知ることができます。ネットワーク A と B の両方から 1 つのロールアップ ブロック プレフィックスを発行することにより、ロールアップ ノードは 2 つのロールアップを同時に決済できます。注意すべき点の 1 つは、条件付きクロスロールアップ トランザクションは共有実行を通じて 2 つの別個のシステムからリソースを消費するため、クロスロールアップ アトミック (または同期) トランザクションは単一ロールアップ イントラ トランザクションよりもコストが高くなる可能性が高いということです。
また、Succinct では、Optimism ハイパーチェーン エコシステム内の共有注文者 (および共有不正証明者) とのロールアップ間のクロスチェーン「アトミック」トランザクションについても取り上げました。これについては、こちらでご覧いただけます。また、Polymer の Bo Du 氏は次のように述べています。「クロスチェーンのアトミック トランザクションは、書き込み時にデータベース シャード間のロックを取得するようなものです。」
垂直統合の未来
SUAVE チェーンの内部動作の可能性については、Jon Charbonneau らによってすでに詳しく調査されているため、あまり詳しく説明しません。さらに詳しい説明が必要な場合は、彼の記事をチェックしてください。それにもかかわらず、私たちは、垂直統合がどのようにモジュール化できるか (およびその理由) を強調し、垂直統合に関連するいくつかの問題と懸念事項を紹介するために、垂直統合については個別に紹介する価値があると考えています。
Astria、Espresso、Radius の現在の共有オーダラー スキームは非常にモジュール化されていますが、オーダラーは依然としてビルダーおよびブロック プロデューサーとして機能します (ただし、Astria の場合、トランザクションは実行されません)。 Astria はまた、当初から積極的に PBS を自社のアーキテクチャに組み込んできました。
PBS がプロトコルに組み込まれていない場合、PBS を実装する方法がいくつかあります (分散化の程度は異なりますが)。 SUAVE などの製品は、MEV-Boost などのオフライン モデルを使用するか、Mekatek や Skip によって構築された Cosmos SDK モジュールなどのビルダー モジュールを実装します。
これらの方法はいずれも相互に排他的ではないことに注意してください。いくつかの異なる方法を使用して、誰でも自分の好みを表現できる柔軟性があります。そうすれば、欠員を埋めるために執行者を競わせることができます。オプションを追加することは常に良いことです (そして、モジュール性に対する私たちの信念と一致しています)。それでも、実装が異なれば、トレードオフも異なります。たとえば、SUAVE のようなケースでは、完全に信頼できる集中 PBS ビルダーに依存する代わりに、SGX または暗号技術を通じてプライバシー保護を追加し、真実に暗号の経済的安全性を追加できます。 (フィードバックをくださった Jon Charbonneau に感謝します)。
ビルダー チェーンへの垂直統合により、近道を実行したり、遅延が追加されたり、パフォーマンスが低下したりすることなく、公平性が確保されます。したがって、ビルダー チェーンは高度に最適化する必要があり、高価で強力なハードウェアが必要になる場合があります (集中化につながります)。これは、エンド ユーザーの検証を取得するには、おそらく何らかのライト ノードが必要になるか (フル ノードを信頼する必要があるが)、状態証明タイプのセットアップを利用して、チェーンとユーザーが入札設定の証拠を確実に持つことを意味します。が埋められており、ブロックは正しい構造になっています。
このようなチェーンは非常に状態が重い可能性があります (これは避けたいと考えています) が、これらの状態が重いトランザクションはスマート コントラクトによって優先されます。優先入札の場合、入札は通常、好みに応じて短期間のみ有効であるため、入札が満たされるか、（短期間）満たされないかのどちらかになります。これは、非常に効率的な (そして早期の) 入札の状態有効期限を実装できる可能性があることを意味します。これにより、データをプルーニングしてチェーンを「クリーン」に保つことができます。この有効期限は、入札が最初に満たされるのに十分な長さである必要がありますが、期限を下げすぎると、フォワードブロックスペース先物を達成することがほぼ不可能になります。期限切れの入札契約は (アプリケーションとは異なり) 永久に存在する必要がないため、更新したり取得したりする必要はありません。これは、入札が満たされたときに状態/ストレージの証明を提供するか、DAS ストレージ ソリューション (提案されているものなど) によって行うことができます。 Joachim Neu によるソリューション) を使用して、より「安全」で信頼できるものにします。
前述したように、SUAVE のほとんどのユーザーおよび顧客は SUAVE から高い経済的利益を得ることができるため、SUAVE の「真正性」を検証する必要性はプラットフォームの「上級ユーザー」に限定される可能性があります。このため、検証したい場合にのみフルノードを実行できるようにする必要があるかもしれません。ただし、これにより大多数の人が除外されます (検証する必要がないとも言えます)。これは (私たちの意見では) Crypto の逆であり、私たちは状態証明または軽量のクライアントフレンドリーな実装を通じて「トラストレスな」SUAVE 検証を実装することを好みます。
これが必要な理由は、入札優先順位が正しく入力されていること、および支払い時にブロックに正しい情報が入力されていることを確認するためです (リバンドルやその他のバグを避けるため)。これは本質的にオラクルの問題です。実際、状態証明で解決できます (すべての SUAVE の場合と同様)。しかし、これらの状態証明は、チェーンを横断するときに別の問題を引き起こします。それは、この情報を改ざんまたは隠蔽されない方法でチェーン間でどのように中継するかということです。これには、強力な経済的ファイナリティ (Lagrangian によって提案されたものなど) を通過する必要がある場合があります。その場合、EigenLayr の再ステーキング バリデータを使用してチェーンのファイナリティと信頼性を証明でき、非常に強力な経済的制約を持つことができます。これにより、別の問題が生じます（たとえば、入札契約では、「オラクルマシン」（この場合は再質権者）が質権されたトークンを指定し、経済的拘束力を提供したと規定されています）が、これを外部との間でどのように合意形成するのでしょうか?スラッシュ基準を書くことはできますが、これはコンセンサスが取れていないため、ソーシャル スラッシュがスマート コントラクトを介して悪用されることになります (これは「公平」であることはほとんどなく、問題が発生する可能性があります)。これは現在、EigenLayr のケースです。 。
さて、これで私たちはどうなるでしょうか?おそらく、コンセンサスを超えたオンチェーンの「トラストレス」スラッシュが実現するまで、SUAVE のようなチェーンは、入札優先順位を証明し、ブロックの確実性を構築するために、独自のコンセンサス アルゴリズムと暗号経済的セキュリティを必要とするかもしれません。ただし、これは、特にロールアップの場合、より多くの暗号経済的攻撃ベクトルを追加することを意味します。その構成要素の価値は、独自の暗号経済的安全性よりもはるかに高くなります。
さらに、SUAVE タイプのチェーンとクロスドメイン MEV にはまだ多くの設計余地があり、考えられる研究の方向性は次のとおりです。
プリファレンス表現に関して、EVM でスマート コントラクトと対話するには、実行命令を含むデプロイされたコードのアドレスにある特定の関数にコントラクト呼び出し (メッセージ) を送信する必要があります。ユーザーは入力を提供しますが、ステートフルである可能性があるため、出力を制御できない場合があります。
対照的に、好み表現設計システム (SUAVE や Anoma など) では、ユーザーが保証金で設定に署名することのみが必要です。保証金は、検索者の設定が満たされた場合にビルダーとブロックプロデューサーに支払われます。 MEV サーチャーやビルダーのトランザクション シーケンスなど、複雑な組み合わせロジックの場合は、異なる言語や仮想マシンの実装が必要になる場合があります。これは、最近特に Anoma アーキテクチャで多くの注目を集めている新しいデザイン空間です。また、この短い記事も強くお勧めします。