4D がロールアップソーターの分散化への道を議論

Foresight News

特邀专栏作者

2023-03-25 02:00

この記事は約19261文字で、全文を読むには約28分かかります

「Rollup」が本当の Rollup になるためには、ソーターの分散化が重要なステップです。

AI要約

展開

「Rollup」が本当の Rollup になるためには、ソーターの分散化が重要なステップです。

原作者：Jon Charbonneau

原作者：

オリジナル編集: 0x11、Foresight Newsケルビンは「ZK ロールアップ」は本物の ZK ロールアップではないと考えています、私はすべて「ロールアップ」だと思います本物のロールアップではありません

、少なくともまだです。そこで問題は、それらを真のロールアップにするにはどうすればよいでしょうか?

最新のロールアップのほとんどには信頼と許可が必要です。

出典: L2 Beat https://l 2b Eat.com/scaling/risk

以下の分野の状況を概説します。
強制トランザクション包含メカニズム: ロールアップオペレーターがユーザーを検閲している場合でも、ユーザーは検閲に抵抗するために自分のトランザクションを強制的に含めることができる必要があります。
L2 シーケンサーの分散化と (オプション) コンセンサス: 単一シーケンサー、PoA、PoS リーダーの選択、PoS コンセンサス、MEV オークション、ロールアップベース、効率性の証明など。
共有シーケンサーと X チェーンのアトミック性: これは本当に興味深い新しいものです。

MEV を意識した設計: FCFS のいくつかの亜種について簡単に説明します。暗号化されたメモリプールについては、私の最近の記事を参照してください。

ロールアップはどのように機能しますか?

スマートコントラクトロールアップ (SCR)

まず、SCR の簡単なレビュー動作原理動作原理

。現在イーサリアムで使用されているロールアップはすべて SCR です。大まかに言うと、SCR は基本的に次のとおりです。
入力の順序付けされた配列 (L1 上なので、トランザクションデータはデータ可用性レイヤーで公開される必要があります)
入力に基づいた確定的な出力 (ロールアップブロックチェーン)

画像の説明

出典: ロールアップの実際の仕組み - Kelvin Fichter https://www.youtube.com/watch?v=NKQz 9 jU 0 ftg

より具体的には、従来の注文者は、ステートルートと呼び出しデータを関連する L1 スマートコントラクトに公開することによってロールアップブロックを送信し、新しいブロックがロールアップの上に追加されます。オンチェーンコントラクトは Rollup のライトクライアントを実行し、ブロックヘッダーハッシュを保存します。契約は、有効性証明の受領時、または不正行為防止期間の終了後に決済が確認されます。未確定の ORU ブロックが無効な場合、ロールバックチェーンの不正行為の証拠を提出することで、そのブロック (および後続のすべてのブロック) を孤立させることができます。クロスチェーンブリッジの安全性を確保するのに役立つことが証明されています。

トランザクションパッケージの送信には、悪意のある動作を防ぐために、何らかの種類の保証金が必要です。不正なトランザクションパッケージ (無効なステートルートなど) が送信された場合、デポジットは焼かれ、その一部が証明を騙した挑戦者に分配されます。SCRには「コンセンサスのマージ

」 - オンチェーンの検証可能なコンセンサスプロトコル。ロールアップコンセンサスは、完全に L1 スマートコントラクト内で実行できます。メインチェーンのコンセンサスメカニズムには影響せず、メインチェーンのコンセンサスメカニズムからのサポートも必要ありません。

分散型コンセンサスプロトコルは通常、次の 4 つの主要な機能で構成されます (これは簡略化したものであり、リーダーレスなど、完全なコンセンサスプロトコルを明確に示しているわけではないことに注意してください)。
ブロック有効性関数 - 状態遷移関数。ブロックの有効性は、有効性証明または不正行為証明を通じてオフチェーンで強制されます。
フォーク選択ルール - 有効な 2 つのチェーンから選択する方法。ロールアップは構造上フォークの自由度を実現するように設計されているため、フォーク選択ルールは厳密には必要ありません。
リーダー選択アルゴリズム - ブロックチェーンに新しいブロックを追加できる人。

アンチシビル攻撃 - PoW、PoS など

1 と 2 がまだ議論の余地があることを考慮すると、分散型発注者の最小要件は、何らかの形のシビル抵抗 + リーダー選挙です。 Fuel Labs はこれに取り組んでおり、PoS について次のように主張しています。
完全なコンセンサスプロトコルを備えたロールアップには適用しないでください（バリデーター/発注者がブロックに投票する場合）

ロールアップでの引出線の選択にのみ使用してください。

L2 ローカルのコンセンサスが必要である理由についても十分な議論があります。これについては後ほど詳しく説明します。

ソブリンロールアップ (SR)

ソブリンロールアップは、データ (DA) の可用性とコンセンサスのためにトランザクションデータを L1 に公開しますが、クライアント側の「決済」はロールアップで処理されます。 DA レイヤーはデータの存在を示しますが、ロールアップの正規チェーンは定義しません。
SR - 「正規の」ロールアップチェーンを決定する L1 スマートコントラクトはありません。正規ロールアップチェーンは、ロールアップノード自体によって決定できます (L1 DA を確認し、フォーク選択ルールをローカルで確認します)。

画像の説明

ここここ。

分散型ソーター

ユーザーによって開始された強制トランザクションには次のものがあります。

スマートコントラクトロールアップ

上で述べたように、シーケンサーは通常、トランザクションをバッチ処理し、L1 スマートコントラクトに発行する責任を負います。ただし、ユーザー自身がいくつかのトランザクションをコントラクトに直接挿入することもできます。

もちろん、これは非効率的でコストがかかるため、注文者はトランザクションをパックしてまとめてコミットします。これにより、多くのトランザクションにわたって固定コストが償却され、より優れたデータ圧縮が可能になります。

シーケンサーは最終的にこれらのトランザクションを L1 で公開することを約束しますが、ソフトな確認のための出力を計算できます。

シーケンサーがこれらのトランザクションを L1 に発行すると、出力はさらに統合されます。

通常、ユーザーは L1 から L2 に資金をブリッジするときにのみトランザクション自体を含めます。これは L1 コントラクトへの入力として機能し、L1 にロックされている資産を裏付けとする L2 上の資産を鋳造できることを L2 に伝えます。

L1 にお金を返したい場合は、L2 でそれを破棄し、L1 にお金を返すように指示できます。 L1 は L2 に何が起こったのかを知りません。そのため、L1 で私の資金のロックを解除するための証拠とリクエストを送信する必要があります。

私は L2 から来たため、ソーターはこの引き出しリクエストを開始して L1 に送信できます。しかし、今では L2 ソーターの検閲耐性 (CR) を信頼するようになりました。 L1 と同じ保証はもうありません。おそらく気に入らないか、注文者がシャットダウンして、あなたの資産は永久に L2 に残ります。Rollup は、さまざまな手段を通じて独自の検閲耐性をローカルに追加できます。これには、高いステーク値で L2 コンセンサスを設定することが含まれる場合があります。インクルードリスト

の一部の亜種では、L2 ユーザー検閲の可能性を最小限に抑えるために、しきい値暗号化などを追加します。これらはすべて良い実践ですが、理想的には、L2 ユーザーにも L1 と同じ検閲耐性の保証を提供したいと考えています。

ユーザーが検閲されている場合は、ロールアップを強制的に終了するか、トランザクションを L2 に強制的に移行する何らかの方法が必要です。このため、L2 ユーザーは、たとえば、L2 トランザクションを L1 契約に直接強制的に含める機能を保持する必要があります。たとえば、検閲されたユーザーは、単一操作のトランザクションパッケージを L1 自体に直接送信できる可能性があります。

出典: Starknet 脱出ハッチ調査L2 ユーザーにとってトランザクションを直接 L1 に強制することしか選択肢がない場合、これは理想的ではありません。これは、特に L1 との対話がますます高価になるため、多くの価値の低いユーザーにとっては好ましくありません。より高度な設計では、ロールアップ間のアトミックトランザクションを強制することで、この制限を回避できる場合があります。ここでカルマン・ライコは魅力的な演奏を指揮します。を読むことを強くお勧めします。共有証明者と DA 層を備えたシステムでクロスロールアップ強制トランザクションを可能にすることを期待しています。

ソブリンロールアップ

ソブリンロールアップSovereign Rollup の強制包含メカニズムは動作が異なり、前述したように、SCR とは異なる方法でフォーク選択ルールを適用します (Sovereign Labs は、）。

素晴らしい投稿

SCR では、L1 スマートコントラクトは Rollup のフォーク選択ルールを強制します。 ZK プルーフの検証に加えて、そのプルーフが (他のフォークとは対照的に) 以前のプルーフの上に構築されていること、および L1 で送信されたすべての関連する必須トランザクションを処理したこともチェックします。

SR は、(L1 が検証しない場合でも) ZK 証明を L1 DA レイヤーに公開して、すべての人が calldata/blob として表示できるようにすることができます。次に、以前に有効なプルーフが存在する場合にのみ、新しいプルーフが有効になるというルールを追加するだけです。このルールはクライアント側で強制できますが、ユーザーがチェーンの履歴をスキャンする必要があります。

呼び出しデータは L1 ブロックヘッダーにバインドして戻すことができ、「DA 層の証明 (ブロック X で始まりブロック Y で終わる) をスキャンしました。この証明は最新の有効な証明に基づいています」というステートメントを追加できます。証拠"。これは、フォーク選択ルールをクライアント側で強制するのではなく、証明の中で直接証明します。

すでにプルーフをスキャンしているため、強制取引をスキャンしたことを証明することもできます。必要に応じて、誰でも強制トランザクションを L1 DA レイヤーに直接送信できます。

トランザクションファイナリティとZK Fastファイナリティの階層

イーサリアムでのオンチェーン証明検証は通常非常に高価であるため、現在の ZKR (StarkEx など) は数時間ごとに STARK をイーサリアムにリリースする傾向があります。プルーフはトランザクション数に比べて非常にゆっくりと増加する傾向があるため、このバッチ処理により大幅なコスト削減が可能になります。ただし、このような長いファイナライズ時間は理想的なユーザーエクスペリエンスではありません。

ロールアップが (完全なトランザクションデータではなく) オンチェーン上の状態の違いのみを公開する場合、完全なノードであっても証明がなければファイナリティを保証できません。 Rollup の完全なトランザクションデータがオンチェーンにポストされる場合、少なくともすべての完全なノードが L1 でそれを行うことができます。

通常、ライトノードはソフト確認に関しては集中発注者のみに依存します。ただし、ZKR は、L1 速度でファイナリティを提供しながら、すべてのライトクライアントがリアルタイムで確認できるように、p2p レイヤーで ZK プルーフを迅速に生成および配布できます。後で、これらの証明を再帰的にパッケージ化し、L1 に公開できます。

これが Sovereign Labs が計画していることであり、同様に、Scroll は中間の ZK 証明をオンチェーンで公開する (ただし検証はしない) ことを計画しているため、ライトクライアントはかなり迅速に同期できます。どちらの方法でも、ロールアップはガスコストの節約を待つ代わりに、L1 速度でファイナリティの完了を開始できます。どちらの場合も、ファイナライズ時間を絶対最小値 (L1 速度) まで短縮しているだけであることに注意してください。

L1 よりも早くファイナリティを達成できるソーターはありません。異なる順序付け者の設計でできる最善のことは、さまざまなレベルの確実性で、L1 よりも高速に事前確認を提供することです (たとえば、分散型コンセンサスセットを使用した L2 の事前確認は、単一の信頼できる順序付け者デバイスよりも高速であり、信頼性が高くなります)。パトリック・マッコーリーも最近ロールアップとトレードしたファイナリティのレベル

概要をわかりやすく説明します。
トランザクションの「ファイナリティ」には、誰がコミットするか (およびロールアップ構造が何であるか) に応じて、さまざまなレベルがあります。

異なるアクターは、特定の時点で異なる方法で「真実」を認識します (たとえば、L2 ライトクライアント、フルノード、および L1 スマートコントラクトは、異なる時点で同じ「真実」を認識します)

シングルソーター

現在のほとんどのロールアップには、トランザクションバンドルを送信するためのシーケンサーが備わっています。効率は向上しますが、リアルタイム性や検閲への耐性も低下します。適切な保護策が講じられていれば、これは多くのユースケースで許容される可能性があります。
検閲への抵抗: 前述したように、ユーザーが強制的にトランザクションを含めるためのメカニズム。

Liveness: プライマリ発注者が失敗した場合、ある種のホットバックアップオプションが利用可能です (同様に ZKR 証明者にバックアップを提供しますが、ORU 不正証明者は許可を必要としません)。バックアップシーケンサーにも障害が発生した場合は、誰でも介入できるようにする必要があります。

たとえば、ロールアップガバナンスメカニズムによって代替注文者を選出することができ、ユーザーはセキュリティ、検閲耐性、および稼働性を得ることができます。長期的に見ても、単一のアクティブシーケンサーが実行可能なオプションです。

Baseは新たなトレンドの始まりとなるかもしれない。企業はエンタープライズブロックチェーンのたわごとに興奮しているのと同じくらい自社の製品を管理し、最適化できるようになりましたが、実際には許可不要で安全で相互運用可能なチェーンになる可能性があります。

Base は最終的にはソーターのセットを分散化する予定ですが、重要なのは、厳密にこれを行う必要はない (あるいは、非常に限られた範囲 (例: 小規模なソーターセット) で行うこともできる) ということです。明確にしておきますが、これにはロールアップが実際に安全であることを確認し、検閲耐性を維持するために必要な手順を実装する必要があります（即時アップグレードの削除、堅牢性証明の強制、トランザクションの包含の強制、MEV オークションなど）。

これは、最大規模の分散型サービスに代わるものではなく、集中型/管理型サービスに比べて大幅な改善となります。ロールアップはデザインスペースを単純に拡張します。これは、ほとんどのロールアップチームが注文者の分散化を最優先事項としない主な理由でもあります。他のプロジェクトでは、ユーザーのセキュリティ、検閲への耐性が重視され、ロールアップオペレーターへの信頼が低くなります。

ただし、これは、ユーザーや他の関係者が存続して「リアルタイム検閲耐性」を維持するために介入する必要がある場合には、依然として理想的ではありません（L1 を介したトランザクションの強制など、「最終的に検閲耐性がある」ことに対して）。必須のトランザクション包含メカニズムによっては、価値の低いユーザーの介入はコストがかかるか、非現実的になる可能性があります。リアルタイムの検閲耐性とライブ性の最大限の保証を重視するロールアップは、分散化を目指すことになります。単一のライセンスを取得したシーケンサーを操作する場合には、規制上の考慮事項が存在する場合もあります。

権限証明 (PoA)

単一のソーターをすぐに改善できるのは、地理的に分散した少数のソーターを使用できることです。仕分け者は単にローテーションするだけでよく、仕分け者間のつながりを作ることで、誠実な行動を奨励するのに役立ちます。

この概念はそれほど馴染みのないものではありません。通常、マルチシグネチャブリッジには少数の信頼できる企業、または Arbitrum の AnyTrust DA などの同様の委員会が存在します。しかし重要なのは、ここでは彼らの権限がはるかに低いということです（マルチシグネチャのクロスチェーンブリッジオペレーターがロックされた資金を引き出す方法とは異なり、セキュリティのためにロールアップ注文者に依存する必要はありません）。全体として、このスキームは単一オーダーよりも検閲耐性と生存性の点で優れていますが、それでも完全ではありません。

ソーターオークション、別名 MEV オークション (MEVA)

Rollup は、ステークに基づいてランカーの権利を割り当てるのではなく、スマートコントラクトを介して MEV オークション (MEVA) を直接実行することもできます。誰でも取引の発注権を入札することができ、オークション契約により最高額入札者に発注権が与えられます。これは、ブロックごとに行うことも、長期間にわたって行うこともできます（たとえば、翌日の注文者になる権利の入札）。勝利したシーケンサーは、その後故障したり悪意のある行為をした場合のペナルティを保証する保証金を提出する必要があります。

出典: ZK ロールアップの分散化

実際には、オークションがプロトコルに直接組み込まれていない場合、プロトコル外の MEVA が最も自然な結果になります。ソート権がステークウェイトに基づいて決定される場合、現在 L1 イーサリアムで見られるものと同様の、何らかの形式の MEV-Boost/PBS スタイルのオークションシステムが登場するでしょう。この場合、手数料/MEV がステーカーに分配される場合があります。オークションがプロトコルに組み込まれた場合、手数料/MEV は何らかの形式のロールアップ DAO 財務省に送られる可能性があります。

リーダー選出のための許可のない PoS

許可なくシーケンサーとして参加できますが、トークン (おそらく L2 のネイティブトークン) をステークする必要があります。ステーキングメカニズムは、スマートコントラクトを通じて、またはロールアップで直接ベースレイヤーの上に構築できます。他の L1 とほぼ同じように、この PoS を何らかの形式のオンチェーンランダム性と組み合わせてリーダー選択に使用できます。ブロックを注文する確率 = 総賭け金の割合。間違った/悪意のあるシーケンサに対しては、スラッシュなどを通じてペナルティを課すことができます。

上記の理由により、発注者間の合意を必要とするものではないことに注意してください。ロールアップではコンセンサスに L1 を使用するため、ローカルのコンセンサスは必要ありません。ステーキングにより、どの注文者がブロックを提案できるかが決まりますが、他の注文者が提案したブロックに投票する必要はありません。

Dymension

発注権は任意の期間付与することもできます。連続する 100 個のロールアップブロック、または 1000 個などを並べ替えるアクセス権がある場合があります。サイクルが長いほど効率が良く、一度に必要なシーケンサーは 1 つだけです。しかし、拡大独占の許可には別の外部性がある可能性があります。

Dymensionはこれらのアイデアを実践するプロジェクトです。 Dymension Hub は、Cosmos の典型的な正直多数 PoS L1 になります。その L2 (「ロールアップ」) は決済とコンセンサスにこれを使用し、DA として Celestia に依存します (つまり、これらの L2 は実際には「ロールアップ」ではなく「オプティミスティックチェーン」です)。Litepaper彼らによると

, 分散型 RollApp ソートでは、Dymension Hub 上の DYM (Dymension のネイティブ資産) を抵当にする必要があります。リーダーの選択は、DYM ステーキングの相対量に応じて決まります。これらのシーケンサーは、それぞれのロールアップから収益 (手数料およびその他の MEV) を受け取り、関連するコストを Dymension Hub と Celestia に支払います。

このメカニズムの結果、このスタックにキャプチャされたほぼすべての値が DYM トークンに直接蓄積されます。 (StarkNet が STRK で行うつもりのように) 独自のネイティブトークンを使用して並べ替えるロールアップは、独自のトークンに価値を追加します。この設定は次のような疑問を引き起こします: Ethereum Rollup はソーターの選択に ETH のみを使用できますか?

私の意見では、これにより、そのような決済層に L2 を展開するインセンティブが大幅に減少します。ほとんどの L2 チームは、当然のことながら、独自のトークンが (単に手数料として使用されるのではなく) 意味のある価値を生み出すことを望んでいます。

リーダー選出と L2 コンセンサスのためのパーミッションレス PoS

L2 ステーキングは、必要に応じて注文者の選出やローカルの合意にも使用できます。これはまさに StarkNet (STRK) プランのトークンモデルです。
PoS コンセンサス: L2 バリデーターが、L1 の最終決定の前に一時的な L2 コンセンサスに達するよう奨励し、より強力な事前確認を提供します。これは厳密な要件ではありませんが、魅力的なオプションです。

さらに、STRK は次の目的で何らかの形式で使用できます。

さらに、STRK は次の目的で何らかの形式で使用できます。
証明: 証明者に STARK を作成するよう奨励します。

取引プロセスは次のとおりです。

取引プロセスは次のとおりです。
ソート: ソーターはトランザクションをソートし、ブロックをコミットします。
L2 コンセンサス: StarkNet コンセンサスプロトコルが提案されたブロックに署名
証明の生成: 証明者は、コンセンサスで合意されたブロックの証明を生成します。

L1 状態更新: 状態更新のためにプルーフが L1 に送信されますStarkNet プログラムの詳細については、この記事を参照してください。。

役職

L2 コンセンサスですか、それとも単に L1 コンセンサスですか?

L2 は、独自のローカルコンセンサスを実装する場合と実装しない場合があります (つまり、L2 バリデータは、最終的なコンセンサスを得るためにデータを L1 に送信する前にブロックに署名します)。たとえば、L1 スマートコントラクトは、そのルールから次のことを学習できます。
リーダー選出とコンセンサスの PoS: 「L2 コンセンサスによって署名されたブロックのみを受け入れることができます。」

リーダー選出の PoS: 「これが選択された順序付け者であり、現時点ではブロックのコミットが許可されています。」

ロールアップローカルのコンセンサスがない場合は、次のことを行う必要があります。
ロールアップブロックプロポーザルを許可なしにします。
特定の高さで構築するのに最適なブロックを選択するための基準を作成します。
ノードまたは決済コントラクトにフォーク選択ルールを強制させる

L1 からのコンセンサスとファイナリティの継承

どちらの場合でも、L2 の値はロールアップトークンに蓄積できることに注意してください。 L2 トークンは、何らかの形式のリーダー選択 (コンセンサス投票ではなく) にのみ使用されますが、順序付け権限の価値は依然として L2 トークンに蓄積されます。

L2 コンセンサスの欠点

次に、L1 の前にローカルのコンセンサスがあるかどうかのトレードオフについて説明します。Fuel Labs チームによる提案口論L2 コンセンサスは検閲への抵抗を軽減すると考えられています。「これにより、大多数のバリデーターが新しいブロックをレビューできるようになり、ユーザーの資金が凍結される可能性があります。ロールアップはイーサリアムによって保護されるため、ロールアップを保護するためにPoSは必要ありません。」これは議論の余地があります。前述したように、検閲命令者であっても、検閲抵抗を提供することができます (たとえば、トランザクションを強制的に L1 に直接送信する、またはより複雑なデザインKalman Lajkó、例えば

デザインは検討中）。

これを別の言い方で言えば、完全な合意に達することは「非効率的」であるということです。たとえば、以下の前者の場合は簡単に見えます。
1 台のマスターシーケンサーがすべてを一度に実行します。

一定期間、マスター順序付け者がすべてを実行し、その後、他のすべてのノードが投票して同意する必要があります。

そしてここそしてここここ

前述したように、発注者の分散化における PoS の使用について懸念を表明する人もいます。 L1 と L2 の複雑さにより、特定の種類の攻撃への対処がより困難になる可能性があります。

L2コンセンサスのメリット

おそらくシーケンサーの最大の目標は、L1 の完全な安全性とセキュリティの前に、より迅速なソフト確認をユーザーに提供することです。 StarkNet の仕組みを確認してください。

「強力かつ高速な L2 ファイナリティ - StarkNet の状態は、トランザクションパケットが L1 で証明された後にのみ最終状態になります (これには数時間かかる場合があります)。したがって、意味のあるコミットメントを行うためには、次のトランザクションパケットが証明される前に L2 分散プロトコルを実行する必要があります。」複数の発注者の経済的安全に裏付けられたコンセンサスは、：

より強力な保証

「参加者の一部（悪意のある多数派を含む）と同様に、安全性と生存性の侵害は罰せられるため、スタークネットのコンセンサスは責任を負わなければなりません。」

ロールアップには、最終的には常にイーサリアム L1 の安全性と動的な可用性にフォールバックできるため、コンセンサスメカニズムのオプションの範囲内でさまざまなトレードオフを実験できる柔軟性もあります。

L1 でソートされたロールアップ

上記のロールアップはすべて、何らかの形式でロールアップブロックを作成するための特定のソーターを構築します。たとえば、PoS は許可なく参加できますが、特定のスロットでは、選出された L2 発注者のみがブロックを送信できます。 L2 ソーターに依存せず、L1 自体を通じてトランザクションをソートする関連スキームもあります。

完全な無政府状態ヴィタリックはこれを提案した」完全な無政府状態

” という思い。誰でもいつでもトランザクションパッケージを送信できます。これは、上で説明した分散型ソーターの 2 つの最小要件を満たしています。
シビル耐性: シビル耐性 (つまり、トランザクション手数料とブロックサイズ/ガス制限) は L1 によって提供されます。

リーダーの選択: リーダーの選択は事後的に行われます。

L1 はすでにセキュリティを提供しているため、これで十分です。 L2 ブロックが L1 にパブリッシュされた場合、それらが無効であるか、無効なブロック上に構築されている場合にのみ孤立します (ロールバックされます)。それらが有効で L1 に公開されている場合、L1 自体と同じセキュリティが適用されます。

Based Rollup

Vitalik 氏は、非効率性という重要な問題を指摘しました。複数の参加者がトランザクションバンドルを並行して送信する可能性がありますが、正常に含めることができるのは 1 つだけです。これにより、プルーフの生成に多くの労力が無駄になったり、トランザクションパッケージをチェーンに公開するときにガスが無駄になったりします。

しかし、PBS はこのアナーキーな設計を実現できるようになりました。これにより、L1 ブロックごとに最大 1 つのロールアップブロックを使用して、より規則的な順序付けが可能になり、Gas を無駄にすることはありません (ただし、コンピューティングリソースは浪費される可能性があります)。 L1 ブロックビルダーは、他の L1 ブロックと同様に、最高値のロールアップブロックのみを含めることができ、検索者が入力した入札に基づいてブロックを構築できます。計算の無駄を避けるために、Z がデフォルトで ZK 証明を許可するのは合理的かもしれません。Justin DrakeこれはBased Rollups最近提案されたのは「

「提案の背後にある中心的なアイデア。彼は、トランザクションが L1 (「ベース」レイヤー) によって順序付けされるロールアップを指すためにこの用語を使用しています。 L1 提案者は、L1 ブロックにロールアップブロックが含まれていることを確認するだけで済みます。この単純なスキームにより、L1 の活性化と分散化が瞬時に実現されます。これらは、L2 オーダラー検閲の場合の強制的なトランザクションの包含の解決など、難しい問題を回避します。また、ソーターの署名検証が必要ないため、ガスのオーバーヘッドの一部が削除されます。

興味深い疑問は、これらの L2 トランザクションがどこで処理されるかということです。 L2 クライアントは、L1 サーチャー/ビルダーがトランザクションを受信してブロックを作成できるように、これらのトランザクションをどこかに送信する必要があります。送信先は次のとおりです。

L1 Mempool - 「情報を持った」検索者/構築者が解釈できる特別なメタデータとともに送信できます。ただし、これにより、L1 メモリプールの負荷が増加する可能性があります。

L2 の p2p Mempools - この考え方のほうが説得力があるようです。検索者/構築者は、通常のチャネルに加えて、これらのチェックと解釈を開始します。

ここでの明らかな欠点は、Based Rollup がソーターの柔軟性を制限することです。例えば：

MEV の削減: FCFS のバリアント、暗号化されたメモリプールなどを使用して、ロールアップを創造的にすることができます。事前確認: L2 ユーザーは、迅速なトランザクションの「確認」を好みます。ベースドロールアップトランザクションの「確認」時間は、L1 と同じレベル (12 秒) に戻るか、より長い時間待機してから。

完全なトランザクションパッケージを公開する

興味深いことに、これはまさに初期のロールアップチームが行っていたことです。

これらは、少なくともその分野では、EigenLayer を取り巻く研究分野です。白書白書

で言及されています。このような解決策が実際に問題を解決するかどうかは不明です。再ステーキングでこれらの欠点を効果的に改善するには、すべてのステーカーが再ステーキングを実行することを選択することが望ましい場合があります。これを行うことを希望するステーカーに別の共有注文層を入力させることで、このアイデアをエミュレートする方が論理的と思われます (これについては後で詳しく説明します)。

昨年、Polygon Hermez は PoE と呼ばれるプロジェクトを提案しました。提案。これは、L1 ソートに特化した ZK Rollup の別のバリエーションです。ここでのコーディネーターは、誰でもトランザクションパッケージを送信できる完全にオープンな役割です (つまり、完全なアナーキー)。 PoE には 2 つの関係者がおり、プロセスは 2 つのステップに分かれています。

仕分け機

シーケンサーは、L2 ユーザートランザクションを収集し、選択されたすべての L2 トランザクションデータを含む L1 トランザクションを送信することでトランザクションバンドルを作成します。注文者は、受け取った経済的価値に基づいてブロックを送信するか、ユーザーにより良いサービスを実現するためにブロックを送信します (たとえば、L2 トランザクションがより高価になるが、ユーザーはより高速なトランザクションを望んでいる場合でも、L1 ブロックごとにトランザクションのパッケージを公開します)。

ソーターは、トランザクションバンドルを公開するために L1 ガス料金を支払います。プロトコルでは、MATIC で支払わなければならない追加料金が定義されています。公開されると、勝者のトランザクションパッケージは直ちにチェーンの新しいトップを定義し、どのノードでも現在の状態を確定的に計算できます。次に、ライトクライアント (L1 スマートコントラクトを含む) の状態を確定するには、有効性の証明が必要です。

アグリゲーター

ここのアグリゲーターは ZK 証明者です。繰り返しますが、これは誰でも参加できる権限のない役割です。それは簡単です：
トランザクションデータを含むソートされたトランザクションパケットは、L1 上の発生位置によって L1 上でソートされます。

PoE スマートコントラクトは、まだ証明されていない提案されたトランザクションの 1 つ以上のバンドルを含む、有効状態を更新するための最初の有効性証明を受け入れます。

アグリゲーターは費用対効果分析を実施して、プルーフを発行する正しい頻度を把握できます。勝った場合、手数料の一部を受け取りますが、新しい証明の発行までに時間がかかると、固定検証コストがより多くの取引に分散されます。アグリゲーターが証明の公開を遅らせた場合 (新しい状態を証明していない場合)、コントラクトは元に戻す操作を実行します。証明者は計算リソースを無駄にしますが、ガスのほとんどを節約します。

料金は次のように割り当てられます。
L2 トランザクションからの料金は、有効性の証明を作成するアグリゲーターによって処理および分配されます。
トランザクションバンドルを作成するための注文者のステーキング料金はアグリゲーターに送信され、アグリゲーターはこのトランザクションバンドルを有効性の証明に含めます。

ピュアフォーク選択ルール

RollkitSRにも同様の「ピュアフォーク選択ルール「次のような概念ここここ

と、特権シーケンサーを持たないロールアップについて言及しました。ノードは DA 層に従ってソートされ、「先着順」のフォーク選択ルールが適用されます。

L1 ソートの経済性

L2 トランザクションの MEV が L1 ブロックプロデューサーレベルでキャプチャされるようになるため、これらの L1 順序付け設計は重要な経済的意味を持ちます。「従来の」L2 順序付けモデルでは、L2 トランザクションの MEV は、L2 順序付け者/コンセンサス参加者/オークションメカニズムによって取得されます。この場合、どれだけの MEV が L1 に漏れるかは不明です。

これが良いことなのか悪いことなのかを判断するのは難しいです。良いこと: 「」を好む人もいます。L1 経済連合
” (例: ETH の価値が高まります)。悪いこと：他人心配

ベースレイヤーでのインセンティブ（例：ビットコインマイナーの集中化リスク）。

このタイプのスキームは、特に簡単なロールアップブートストラップ方法としては理にかなっているかもしれませんが、ほとんどのロールアップがこれほど多くの MEV を L1 に放棄することは考えにくいです。ロールアップの大きな利点の 1 つは、確かに経済的利益です。DA が拡張を開始し、コストが低下すると、L1 に支払う必要があるのはごくわずかだけになります。単純な MEV アプローチの遅いブロック時間と落とし穴も、ユーザーにとって最適ではないように思えます。

インセンティブ ZK プルーフ

前述の PoE 競争では、最速のアグリゲータが争われる可能性があることに注意してください。 ZK プルーバー市場には、解決すべき 2 つの経済的問題があります。
証明者に証明を作成するよう促す方法

証明書の提出をライセンスフリーにし、競争力のある堅固な市場にする方法

ZK 証明者市場の 2 つの単純なモデルを考えてみましょう。

競争市場

証明者がロールアップコレーター/コンセンサスによって生成されたブロックの証明を作成するために競う、許可のないマーケット。最初に証明を作成した人は、証明者に指定された報酬を受け取ることができます。このモデルは、ジョブに最適な証明者を効率的に見つけます。

これは PoW マイニングに非常によく似ています。ただし、ここには独特の違いがあります。証明は決定論的な計算です。その結果、他の証明者に対して小さいながらも一貫した利点を持つ証明者がほぼ常に勝ちます。そして、この市場は集中化する傾向があります。

PoW マイニングでは、ランダム性の点でより良い結果が得られます。マイニングパワーが 1% あれば、1% の報酬が得られるはずです。

この競争的証明モデルは、計算の冗長性の点でも最適ではありません。多くの証明者が競争し、証明を作成するためにリソースを費やしますが、勝つのは 1 つだけです (PoW マイニングと同様)。

ターンベースの証明

証明は、証明者の間でローテーションで作成できます (たとえば、ステークされたトークンまたは評判に基づいて)。このアプローチは潜在的により分散化されていますが、証明のレイテンシーの点で効率が低くなります (ある証明者がより速く効率的に証明を作成できる場合、別の「遅い」証明者も同様に証明を作成する機会があります)。ただし、証明を作成できる証明者が 1 人だけである場合に、計算リソースが無駄になることを防ぎます。

さらに、証明者がラウンド内で証明を提供できなかった場合（悪意があるか意図せずに）、ネットワークに問題が発生します。これらのラウンドが長くなり（たとえば、特定の証明者が数時間独占を獲得した場合）、証明者がダウンした場合、プロトコルは回復するのが困難になります。証明者を切り替える時間が短い場合は、他の証明者が代役を務めることができます。

誰でも証明を発行できるようにすることもできますが、指定された証明者のみが一定時間内に報酬を受け取ることができます。したがって、現在の証明者が失敗した場合、別の証明者が証明を発行できますが、報酬は得られません。これは、何も見返りを得ることなく計算にリソースを費やす利他的な行為です。

Scroll は、よりターンベースのアプローチを検討しており、ランダムに選択された「ローラー」(証明者) に実行を分配します。

スクロールワークフロー

また、ソート時にユーザーレベルのプルーフにどのように課金されるべきかなど、興味深い質問もたくさんあります。これらのトピックに関する詳細な議論はここでご覧いただけます。スクロールのイェ・チャン「」分散型 ZK ロールアップ
《MEVA のステーキング + 注文に基づくこのようなターンベースのネットワークの可能性については、記事で説明されています「ローラーモデルの詳細を提供します」
Starknet Decentralized Protocol IV - Proofs in the Protocol
Starknet Decentralized Protocol VI - The Buffer Problem

共有ソート

初期のソリューションのほとんどは、各ロールアップがソーターを分散化する方法を自分で理解する必要があると想定していました。 L1 ソート方式で見たように、そうではありません。多くのロールアップは共有シーケンサー (SS) を選択できます。これを行うことの利点は次のとおりです。
労力の節約: シーケンサーの分散化について心配する必要はなく、検証者の採用と管理も必要ありません。これは非常に「モジュール式」のアプローチであり、トランザクションの順序を取り除きます。 SS は文字通り SaaS (Sequencer as a Service) 企業です。
セキュリティと分散化の組み合わせ: 個別のロールアップごとに複数の小さな委員会を作成するのではなく、注文層に強力な経済セキュリティ (より強力な事前確認) とリアルタイム CR を構築させます。
高速トランザクション: 他の単一のロールアップ注文者もこれを行うことができますが、ここでも超高速の事前確認が得られることに注意してください。

クロスチェーンのアトミック性 - トランザクションはチェーン A とチェーン B で同時に実行されます。 (これは複雑なので、後ほど詳しく説明します)。

前述したように、単純にネイティブ L1 を L2 のソーターとして使用することには、基本的にいくつかの欠点があります。
L1 データとトランザクション順序付けのスループットによって依然として制限されています

L2 ユーザーに L1 ブロック時間未満の高速トランザクションを提供する機能の喪失

L1 順序付けでできる最善のことは、L1 の計算ボトルネック (トランザクションの実行がスループットボトルネックの場合) を除去し、通信の複雑性を改善することです。

では、L1 に任せるのではなく、より効率的な専用の SS を設計できるでしょうか...

Metro - アストリア向けの共有仕分け機Metro は SS 層の方式です。 Evan Forbes の記事を参照してください。、Modular Insights talk研究ポストShared Security Summit talkそして

もっと詳しく知る。 Josh Bowen 氏が率いる Astria チームは、Metro ソリューションに取り組んでいます。

実行と注文の分離

現在の Rollup ノードは実際に次の 3 つのことを行います。

ここで重要なのは、実行と注文を分離することです。共有並べ替えでは次のことができます。
注文レイヤーとして使用することを選択した多くのチェーンの注文トランザクション

これらのトランザクションを実行 (または証明) せず、結果の状態を生成しません。

並べ替えはステートレスです。 SS ノードは、すべての異なるロールアップの完全な状態を保存する必要がなくなり、実行計算が不要になり、従来のソーターが直面していた大きなボトルネックがなくなりました。

実行がコンセンサスから取り除かれると、効率が非常に高くなります。すべてのノードがトランザクションの順序付けされたブロックを生成し、すべてを実行せずにそのブロックに同意するだけであれば、ノードは非常に効率的になるでしょう。実行と証明は、異なる当事者によって事後に行われる可能性があります。

シーケンサーのセキュリティと分散化の両方

SS ノードは比較的軽量なままであり、水平方向に拡張することもできます (コンセンサスノードのランダムなサブセットを選択して、トランザクションの異なるサブセットを順序付けることによって)。ソート層は、チェーンの複雑な状態を把握し、実行を担当する必要がある従来のソーターよりも分散化されています。

さらに、PoS コンセンサスを複数のロールアップに分割するのではなく、複数のチェーンにまたがってリソースをプールすることで、それらはすべて 1 か所に集約されます。独自のソーターセットを実装する多くのロールアップと比較して、このスキームは、大量のステークアセットを必要としない、より分散化されたソーターセットを実現する可能性があります。これは次の理由から重要です。
ランキング: リアルタイム検閲耐性 (CR) とロールアップユーザーの活性度の第一線。

実行と証明: 分散化を強く必要とせずに事後的に実行できます。

トランザクションの順序付けが合意されると、実行 (および証明) を事後的にまったく別のチェーンに延期できます。
ソフトコンセンサスと注文: 共有注文者はユーザーに迅速な事前確認を提供します
コンセンサスとデータの可用性: トランザクションデータは DA レイヤーで最終的に決定され、全員が確認できるようになります。

後続の実行層は、CR の起源ではないため、分散化する必要はありません。単一の注文者は CR の理想的な候補者ではありませんが、執行者としての役割のためではなく、トランザクションを注文して含めるためです。ここで、SS はすでに順序付けされたトランザクション入力を提供しているため、CR となります。その後、国家のコミットメントの計算と比較を分散化する必要はありません。

ソフト実行

ユーザーは高速なソフト実行を好みます。

優れたユーザーエクスペリエンスを提供するには、何らかの形でのコンセンサス (または集中的な注文者) が必要です。

Celestia のようなベースレイヤーのコンセンサスだけに依存している場合、順序付けと包含に関するこれらの甘い約束を実現することはできません。 SS に高額資産を賭けた分散型委員会がある場合、高速ブロック (L1 ブロック時間未満) に対してかなり強力なコミットメントを提供できます。

Lazy Rollup

したがって、SS がブロックを作成する限り、ユーザーはソフトな確認を得ることができます。この確認の強さは、SS の構築 (分散化、経済安全保障、フォーク選択ルールなど) によって異なります。データが実際にベースレイヤーに公開されると、これらのトランザクションを真に最終的なトランザクションとして扱うことができます。その後、状態ルートと関連する証明の最終計算を生成して送信できます。

「Lazy Rollup」はとても簡単です。これらのトランザクションは、すべてのトランザクションが順序付けされて DA レイヤーに公開されるまで待機し、その後それらのトランザクションをダウンロードし、オプションでフォーク選択ルールを適用してトランザクションのサブセットを選択し、トランザクション処理を実行して、トランザクションステータスを決定します。その後、ブロックヘッダーを生成できます。

SS は完全な状態へのアクセスを必要とする方法でブロックを生成できないため、無効な状態遷移をチェックしないことに注意してください。したがって、SS を使用する「Lazy Rollup」ステートマシンは、無効なトランザクションを処理できなければなりません。ノードが順序付けされたトランザクションを実行して結果の状態を計算する場合、ノードは無効または取り消されたトランザクションを単純に削除できます。すぐに実行される従来のロールアップにはこの制限はありません。

トランザクションをオンチェーンに含める前にトランザクションを処理するために状態アクセスが必要なロールアップは、ここでは機能しません。たとえば、ロールアップにブロック有効性ルールがある場合、ブロックに含まれるすべてのトランザクションは失敗しない有効なトランザクションになります。ロールアップが状態アクセスではなくトランザクションの鍛造を必要とする場合、このタイプのロールアップ専用に特別な SS を作成できます (たとえば、Fuel v2 やプライベートメモリプールを使用したロールアップと同様)。

SS が機能するためには、ユーザーがトランザクションの料金を支払うための何らかのメカニズムが必要です。ほとんどのロールアップトランザクションタイプに既に含まれている既存の署名とアドレスを使用して、SS レイヤーでガスの支払いを行うことができます。あるいは、支払いには SS 上でラップされたトランザクションが含まれる可能性があり、誰でも含まれる任意のデータに対して支払いを行うことができます。オープンなデザイン空間です。

フォーク選択のルール

ロールアップは、使用している SS のフォーク選択ルールを継承できます。 Rollup のフルノードは実際には SS のライトクライアントであり、いくつかのコミットをチェックして、特定の高さでどの Rollup ブロックが正しいかを示します。

MEV

ただし、SS のフォーク選択ルールの継承はオプションです。基本レイヤーに公開するすべてのトランザクションデータを処理する (必ずしも実行する必要はありません) ように Rollup に依頼するだけです。基本レイヤーの CR と活性度は効果的に継承されますが、ユーザーが好む SS 機能の多くが犠牲になります。

ロールアップが SS のフォーク選択ルールを継承し、高速なソフト実行を取得したいと仮定すると、SS は当然 MEV の非常に中心的な位置になります。これにより、ロールアップトランザクションの包含と順序が決定されます。

ただし、Rollup は必ずしも SS によって提供されたトランザクションを実行する必要はなく、また提供された順序でトランザクションを実行する必要もありません。技術的には、実行後に SS によって発行されたトランザクションを並べ替えるために、独自のロールアップで 2 回目の処理を実行できるようにすることができます。ただし、上で述べたように、これでは SS を使用する利点のほとんどが失われます。

この場合でも、SS 層にはトランザクションを含める権利があるため、MEV が依然として存在する可能性があります。本当に必要であれば、ロールアップで 2 回目の処理で特定のトランザクションを除外することもできますが、そうすると面倒になり、CR が減少し、SS の利点のほとんどが失われます。

共有ソーターを交換する

ブロックチェーンでフォークするのが難しいのは、あらゆる形式の共有された価値の状態です。 ETH対ETC、あるいは同様にETH対ETH POWを見てみると、「真のイーサリアム」が何であるかは社会的合意によって決まります。私たち全員が同意できる「真実」の状態には価値があります。

ただし、SS は実際には単なるサービスプロバイダーであり、価値のある状態は関連付けられていません。特定の SS を使用するロールアップは、他のソートメカニズムをサポートするためにそれをフォークする機能を保持しており、必要なハードフォークはわずかです (SS が抽出する値が多すぎる場合など)。

エスプレッソシーケンサー (ESQ): EigenLayer によって保証されています

EigenLayer 白書白書

再ステーキングの潜在的なユースケースの 1 つとして、分散型 SS が挙げられました。この SS は、多くの異なる L2 トランザクションの順序を処理する ETH 再ステークによって保護できます。

さて、Espresso は共有シーケンサープログラムでこれを発表しました。コンセンサスを確保するために、EigenLayer の再ステーキングを利用できます。優れた視覚化を提供するために、現在のロールアップは次のようになります。

エスプレッソのような SS を使用すると次のようになります。

エスプレッソシーケンサー (ESQ) は、一般に Metro とアイデアが非常に似ています。これらは、トランザクションの実行を注文から切り離すという同じ基本原則に基づいて機能します。これに加えて、ESQ はトランザクションのデータ可用性も提供します。

HotShot コンセンサスと Espresso DA (データの可用性)

背景として、イーサリアムは現在コンセンサスに Gasper を使用しています (ファイナライゼーションツールとして Casper FFG + フォーク選択ルールとして LMD GHOST)。ここで関連する TLDR は、大部分のノードがオフラインになる可能性がある状況下でも存続できる Gasper の能力 (動的可用性) です。これは、最終プレフィックスを持つ動的に利用可能なチェーンを維持する 2 つのプロトコル (Casper FFG と LMD Ghost) を効果的に実行します。ギャスパーは、迅速な決定論をトレードオフにします。

全体として、ESQ には次のものが含まれます。
HotShot: ESQ は HotShot コンセンサスプロトコルの上に構築されており、Gasper とは異なり、動的な可用性よりも高速なファイナリティを優先します。イーサリアムのように、より多くのバリデーターをサポートするように拡張することもできます。
Espresso DA: ESQ はオプトインチェーン用の DA も提供します。このメカニズムは、一般的なコンセンサスを拡大するためにも使用されます。
Sequencer Contract: HotShot コンセンサスを検証し、チェックポイントを記録するライトクライアントとして機能するスマートコントラクト。さらに、ESQ の HotShot PoS コンセンサスのステーカーを管理します。
ネットワーク層: HotShot と Espresso DA に参加するノード間のトランザクションとコンセンサスメッセージの通信

Rollup REST API - Espresso シーケンサーと統合するための L2 Rollup の API。

このシステムは拡張性を考慮して構築されているため、ESQ は L2 に安価な DA を提供したいと考えています。彼らは引き続き証明と状態の更新を L1 イーサリアムに解決しますが、これにより、デフォルトで ESQ を使用するチェーンが完全な「ロールアップ」ではなくなることに注意してください (イーサリアム L1 は DA を保証しません)。これは、データ可用性委員会 (DAC) の単純な実装よりも強力ですが、その保証は真のロールアップよりも弱いです。

取引の流れ

取引の流れ
シーケンサーコントラクト: HotShot は、L1 シーケンサーコントラクトと直接対話します。 HotShot コンセンサスを検証し、他の参加者が順序付けされたブロックを表示するためのインターフェイスを提供します。コントラクトには、完全なブロックではなくブロック送信の追加ログが保存され、送信された情報に基づいて誰でもブロックを検証できます。

L2 コントラクト: ESQ を使用する各 L2 には、依然として独自のイーサリアム L1 ロールアップコントラクトがあります。各ロールアップに送信された状態更新を (有効性/不正証明によって) 検証するには、各ロールアップコントラクトが、要求された状態更新をもたらした認証されたブロックのシーケンスにアクセスできる必要があります。これらはソーターコントラクトと対話してこれらをクエリします。

トランザクションフローの全体像:

クロスチェーンの原子性

Espresso の投稿で述べたように、SS はクロスチェーンのアトミック性に関するいくつかの興味深いユースケースを提供できます。

複数のロールアップ間で共有される順序層により、クロスチェーンメッセージングとブリッジングがより安く、より速く、より安全になることが約束されています。別のチェーンのソーター用にライトクライアントを構築する必要がなくなり、コストが節約されます。クロスロールアップブリッジングにより、特定のロールアップを他のロールアップからのリアルタイムのコンセンサスから独立させる必要がなくなるため、さらなるコスト削減も実現できます。共有オーダラーは、ブリッジングの安全上の利点も提供します。共有オーダラーは、トランザクションが別のロールアップで完了する場合に限り、トランザクションが 1 つのロールアップで完了することを保証します。さらに、共有オーダラーにより、異なるロールアップにわたるトランザクション間のアトミックな依存関係を表現するユーザーの能力が強化されます。慣例により、アリスはボブのロールアップ B トランザクション t' とは独立して、自分のロールアップ A トランザクション t' に署名して公開します。この場合、アリスのトランザクションはボブのトランザクションよりずっと前に注文される可能性があり、ボブには長期的に中止するオプションが残されます。このオプションの不均衡は、共有注文者によって緩和されます。共有注文者では、アリスとボブは 2 つのトランザクションを 1 つの署名付きパッケージとして一緒に送信できます (つまり、注文者は 2 つのトランザクションを 1 つのトランザクションとして扱う必要があります)。

オンチェーンのアクティビティは最終的に成長するため、これはクロスチェーン MEV に影響を及ぼします。代表的な例は「アトミック・アービトラージ」です。同じ資産が 2 つの異なるチェーンで 2 つの異なる価格で取引されます。シーカーは、リスクを負わずに 2 つのトランザクションを同時に実行することで裁定取引を行いたいと考えています。例えば：
Trade 1 (T 1 ) - ロールアップ 1 (R 1 ) で ETH を低価格で購入する

Trade 2 (T 2 ) - ロールアップ 2 (R 2 ) で ETH を高価格で販売します。

T 1 は、次の場合にのみ R 1 の命令ストリームに含まれます。
T 2 は R 2 への命令ストリームにも含まれます

T 2 は R 2 への命令ストリームにも含まれます

T 1 は、次の場合にのみ R 1 上で実行されます。
T 2 は R 2 上でも実行されます

T 2 は R 2 上でも実行されます

ただし、共有ステートマシン (たとえば、完全にイーサリアム L1 上) でトランザクションを実行している場合、これはまだ保証されません。前述したように、SS はこれらのロールアップの状態を保持せず、トランザクションを実行しません。 ( R 1 または R 2 上の) トランザクションの 1 つが実行時に元に戻らないことを完全に保証することはできません。

これの上に高レベルのプリミティブを直接構築することには問題があります。たとえば、この SS の上にインスタントバーンアンドミントクロスチェーンブリッジを構築しようとすると、まったく同じブロックの高さで次の処理が同時に実行されます。
R1 の入力を破棄します。

R2 で出力を生成する

次のような状況が発生する可能性があります。
R 1 での Destroy は予期しないエラーをスローする可能性がありますが、

R2 の出力は何らかの理由で無効化されないため、完全に実行されます。

これは大きな問題になります。

場合によっては、両方のトランザクションが入力ストリームに含まれて実行されている限り、両方のトランザクションの期待される結果を確実に得ることができますが、多くの場合、そうではありません。
保証: T 1 と T 2 はそれぞれのストリームに含まれ、(おそらく) 両方とも実行されます。

トランザクションが正常に実行され、その結果として期待される状態が得られるかどうかは保証されません。

これらの「保証」は、シーカーが各チェーンでこれらのトランザクションを実行するために必要な資産をすでに所有しているアトミック・アービトラージのようなものには十分かもしれませんが、これは明らかに共有ステートマシンの同期構成可能性ではありません。クロスチェーンのフラッシュローンのようなものでは、それ自体では十分な保証を提供できません。

他のクロスチェーンメッセージングプロトコルと組み合わせた場合にも役立つ可能性があります。クロスロールアップメッセージングプロトコルと併用した場合に、NFT のクロスチェーンアトミックスワップがどのように促進されるかを見てみましょう。
T 1 は、R 1 上で ETH を U 1 (ユーザー 1 ) から SC 1 (スマートコントラクト 1 ) に転送します。
T 2 は、R 2 上で U 2 (ユーザー 2 ) から SC 2 (スマートコントラクト 2 ) に NFT を転送します。
SC 1は、NFTが入金されたことを確認するSC 2からのメッセージを受信した場合に限り、U 2がETHを引き出すことを許可します。
SC 2は、ETHが入金されたことを確認するSC 1からのメッセージを受信した場合に限り、U 1がNFTを引き出すことを許可します。

両方のスマートコントラクトはタイムロックを実装しているため、どちらかの当事者が失敗した場合でも、両方の当事者が資産を回復できます。

ここでの SS では、ステップ 1 で 2 人のユーザーがアトミックにコミットできます。次に、何らかの形式のクロスチェーンメッセージングを使用して、結果の状態を相互に確認し、資産のロックを解除して交換を実行します。

SS を使用せずにアトミックに実行される場合、2 つの当事者が価格について合意できます。ただし、U 1 がトランザクションを送信した後、U 2 は待機してトランザクションを中止するかどうかを決定できます。 SS では、トランザクションにロックされます。

これは、SS クロスチェーンのアトミック性のユースケースにほぼ近づいています。要約:
ここで提供される保証の正確な強度と有用性はまだ証明されていません
これは、クロスチェーンのアトミックアービトラージだけでなく、クロスチェーンスワップや NFT トランザクションなどの他のアプリケーションにも非常に役立つ可能性があります。
特定の種類のクロスチェーン取引を引き受けるために、追加の暗号経済セキュリティを提供する（担保として債券を提供するなど）と役立つ場合があります。

ただし、トランザクションの結果を無条件に保証することはできません (共有ステートマシン上でトランザクションをアトミックに実行することで保証できます)。

Optimism's Superchain- OP チェーンでの SS の使用を検討しました。
Anoma - Heterogeneous PaxosそしてTyphonそして
は非常に異なるアプローチです。Cross Rollup Forced Transactions。

前述のカルマンの

共用ソーターの概要

全体として、SS の基本的な考え方は次のとおりです。

明らかに、この図面は科学的ではありません。すべては非常に主観的であり、正確なビルドに大きく依存します。 TLDR は次のとおりです。
集中シーケンサー - システムを完全に制御できる場合は、通常、必要な機能を簡単に実装できます。ただし、事前確認機能には最適とは言えない保証があり、強制終了は望ましくない可能性があり、ライブ性は最適とは言えません。
分散型 L2 ソーター: 分散型プレッジソーターを使用したロールアップは、単一のソーターを使用したロールアップよりも堅牢です。ただし、設計が異なると、遅延などの点でトレードオフが発生します (たとえば、多くの L2 ノードがロールアップブロックを確認する前に投票する必要がある場合など)。
L1 での並べ替え: 分散化、検閲防止、活動などを最大限に保証します。ただし、高速事前確認応答やデータスループット制限などの機能はありません。

共有ソーター: 独自のソーターセットをブートストラップすることなく、分散型ソーターの機能を備えています。ただし、この方式では、L1 順序付けと比較して、L1 ファイナライゼーション前の移行期間の保証が弱くなります。さらに、共有レイヤーは、多くのロールアップの委員会、経済安全保障などを 1 か所に集約できます (おそらく、単一のロールアップに独自の委員会がある場合よりも強力です)。

SUAVE

L1 が確定すると、すべてのロールアップは 100% の L1 セキュリティを達成します。 L1 決済の完全な安全性とセキュリティが得られるまで、ほとんどの発注者の設計は優れた機能を提供しようとするだけで、移行期間中の保証は弱められます。

分散型ビルダーと共有ソーターSUAVE他の多くのチェーンからのトランザクションを処理しようとするこれらの共有レイヤーについて話していると、その違いが非常に混乱する可能性があります。特に、SUAVE が「順序層」または「ロールアップ用の分散ブロックビルダー」などの他の用語で呼ばれることがよくあります。明確に言うと、

上記SSのデザインとは大きく異なります。

SUAVE がどのようにイーサリアムと対話するかを観察してみましょう。 SUAVE はいかなる形でもイーサリアムプロトコルに組み込まれることはありません。ユーザーはトランザクションを暗号化されたメモリプールに送信するだけです。次に、SUAVE エグゼキュータのネットワークは、イーサリアム (または同様に他のチェーン) のブロック (またはブロックの一部) を出力します。これらのブロックは、従来の集中型イーサリアムビルダーのブロックと競合します。イーサリアムの提案者はそれらの中から選択します。

同様に、SUAVE は Rollup のブロック選択メカニズムを置き換えるものではありません。たとえば、Rollup は、イーサリアム L1 が動作するのとほぼ同じ方法で動作する PoS コンセンサスセットを実装できます。これらの発注者/検証者は、SUAVE が生成するブロックを選択できます。

これは、Rollup によって分散型ソーターの必要性を完全に排除できる上記の SS とは大きく異なります。 Metro や ESQ などを選択してソート機能を外部委託し、SS のフォーク選択ルールを継承することも選択できます。 Ethereum、Arbitrum、Optimism などは、SUAVE トランザクション順序を選択するため、フォーク選択ルールを変更しません。

SUAVE は、チェーンのフォーク選択ルールやブロックの選択方法を気にしません。あらゆるチェーンにとって最も収益性の高い仕分けを提供できます。前述の SS ノードとは異なり、SUAVE エグゼキュータは通常、完全な状態を持っていることに注意してください (ただし、状態を必要としない特定の設定も満たす場合もあります)。最適なシーケンスを作成するには、さまざまなトランザクションの結果をシミュレートする必要があります。

違いを理解するために、ユーザーがアトミックなクロスチェーンアービトラージを実行したい例を考えてみましょう。 SUAVE に提出する場合と SS に提出する場合、得られる保証の違いは何ですか:

SUAVE + 共有シーケンサーここで考えてみましょう。SUAVE はロールアップ並べ替えとどのように連携するのでしょうか? SSと交流することもできるかも？エスプレッソは信じているようだスワーブとエスク

互換性がある。 ESQ は、ビルダーとして機能できる SUAVE などのプライベートメモリプールサービスと互換性があるように設計されています。現在イーサリアムで使用している PBS に似ています。
共有提案者 = 共有注文者

共有ビルダー = SUAVE

PBS と同様に、ビルダーはプロポーザー (ここでは注文者) からブラインドコミットを取得して、特定のブロックを提案できます。提案者は、提案されたブロックからの合計ユーティリティ (建設者の入札) のみを知り、内容は知りません。

要約すると、クロスチェーンアービトラージを行おうとするサーチャーを振り返ってみましょう。 SUAVE 自体は、次の 2 つの異なるロールアップを構築して送信できます。
Trade 1 (T 1 ) を含むブロック 1 (B 1 ) - ロールアップ 1 (R 1 ) で ETH を低価格で購入

ブロック 2 (B 2 ) には、トランザクション 2 (T 2 ) - ロールアップ 2 (R 2 ) で ETH を高価格で販売することが含まれます。

しかし、B 1 がオークションに勝ち、B 2 が負ける (またはその逆) 可能性は十分にあります。これら 2 つのロールアップを同じ SS に選択するとどうなりますか。

SS ノードはトランザクションが実際に何をしているのかを知りません。そのため、効率的にしたい場合は、完全なブロックを構築してくれる人 (SUAVE や別の MEV 対応ビルダーなど) が必要です。 SUAVE エグゼキュータは、両方のブロックが満たされるか強制終了される (両方ともアトミックに実行または削除される) 場合に、B1 と B2 の両方を SS にコミットできます。