紹介

MEV(Maximal Extractable Value)への対応は、イーサリアムにとって継続的な課題でした。バリューサプライチェーンは、多くの場合、小売ユーザーを犠牲にして、さまざまなレベルの洗練された多様な戦略を持つアービトラージャーからの絶え間ない活動を奨励します。多くの研究者がプロトコルレベルの変更を通じてMEVに対処しようとしてきましたが、これらの取り組みはまだ満足のいく解決策を提供していません。現在使用されている標準的なインフラとオークションメカニズムは、一括払いのMEVをブロックで競争的に捕捉することができますが、公平な再分配を伴わない捕獲は不十分です:アプリケーションごとにより効果的に捕捉し、内部化できるのに、なぜMEVの価値をネットワークバリデーターに蓄積する必要があるのでしょうか?

そこで登場したのが、特定用途向けシーケンシング (ASS) です。ASS では、プロトコル レベルでルールを書き換えるのではなく、個々のアプリがトランザクションの順序付け方法を制御できるようになります。そうすることで、ASSはオンチェーンアプリケーションがMEVの有害な影響からユーザーと流動性を保護すると同時に、イーサリアムバリデーターが失う価値を獲得する機会を提供します。

潜在能力を想像してください：高頻度トレーダーが各ユーザーとの最大限の裁定取引を競い合う代わりに（裁定価値のほとんどがバリデーターとしたがって基礎となるチェーンに漏れ出てしまう）、各アプリはトランザクションの順序に関する独自のルールを定義することができ、独自のユーザーにとってより適した、効率的で公正なシステムを作り出すことができます。これはMEVをネットワークレベルで解決しようとするのではなく、最も重要な場所でそれに対処するという転換点です-アプリケーション自体です。

背景

アプリケーション固有のシーケンシング（ASS）の背後にあるコンセプトは、Matheusの仕事から発展しました。分散型取引所（DEXes）のための検証可能なシーケンシングルール（VSR）.Matheusは、VSRが取引注文に対するマイナーの影響力を減らすことで、取引執行とmitiGate MEVを改善できることを実証しました。タルン後このアイデアを発展させましたユーザー、バリデータ、シーケンサなどのプロトコル参加者のペイオフ関数に、アプリ特有のシーケンスルールがどのように影響するかを示すことによって、

ここで、ペイオフ関数は、特定の取引順序の経済的価値を表す。この値は、プロトコル参加者が得た利益や効用を反映しており、トランザクションの順序付けが財務結果にどのように影響するかを示しています。ペイオフ機能には、次の 2 つの重要な特性があります。

1. ノンスムースなペイオフ: 順序のわずかな変更がMEVに大きな変化をもたらす可能性があります。
2. 単調でないペイオフ: 順序のわずかな変更はMEVを増やすことも減らすこともできますが、一貫して一方向には限定されません。

ペイオフ関数がこれらの特性の両方を示す場合、シーケンス戦略の最適化は非常に複雑になります。このような場合、ユーザーに公平な結果と持続可能なDeFiエコシステムを確保するために、より洗練された、特注のアプローチがアプリケーションレベルで必要となります。

ASSはどのように機能しますか？

ASSを理解するために、まず既存の取引供給チェーンを復習しましょう。

現在のシステムでは：

1. トランザクションは公共またはプライベートのメンプールに送信されます。
2. ビルダーはこれらの取引を集め、ブロックにパッケージ化します。
3. ビルダーは次にブロックオークションで競争します。
4. 優勝したビルダーのブロックはブロックチェーンに含まれ、入札した価値は選択されたブロックの提案者に支払われます。

下の図はこのプロセスを示し、トランザクションがメンプールからビルダーや信頼できるリレーを経由してブロックチェーンに流れる様子を示しています。

現在の取引サプライチェーンの図

一方、ASSによって可能になるアプリケーションは、以下の特性を持っています:

1. 制限されたシーケンシング権限：この制限により、指定されたシーケンサーまたはステークされた検証者のみが、アプリケーションのコントラクトとやり取りできるようになり、アプリケーションのロジックを悪用して内部価値の再分配を防ぎます。
2. アプリ固有のMempools：ユーザーはトランザクションをパブリックなmempoolに送信する代わりに、意図を表す署名付きメッセージをアプリ固有のmempoolに送信します。これらの意図は、アプリ固有のシーケンサーによって収集および処理されます。
3. 順序に依存しない結果:順序付けルールを適用し、ターゲットユーザーに最適な経済的利益を提供するために、ASSトランザクションは、ブロックの残りの部分のビルダーのトランザクション順序に依存しない必要があります。これは、アプリケーションの状態がコンセンサスメカニズムによってゲートされていることを確認することで実現されます。その後、ASS の注文は 1 つのバンドルに統合され、ビルダーに送られて含められます。このバンドルは、他のアプリケーションによってアクセスされる状態と競合しないため、ブロック内の位置に依存しません。

ASSは、任意のチェーン上のアプリケーションが、その実行および契約状態に関して主権を取り戻すことを可能にするため、主権アプリケーションを実現しています。

これらの基本的な原則を考慮して、主権アプリケーションの実践的な例としてAngstromを使用しましょう。Angstromは、CEX-DEXアービトラージャーによる不利な選択から流動性提供者を保護するUniswapV4フックであり、同時にスワッパーをサンドイッチ攻撃からも保護します。Angstromノードのネットワークは、Ethereumと並行して、次のブロックで実行される取引のセットについて合意します。一般的なフローは次のとおりです:

1. CEX-DEXアービトラージャーは、AMMを介して最初の取引として入札し、手数料なしでスワップする権利を得ます。一方、ユーザーは、アングストロームメモリプールに署名済みのリミット注文として意図したスワップを送信します。
2. Angstrom Networkは、その合意プロトコルを実行し、最初のスワップが最も高い入札価格のアービトラージャートランザクションであるバンドルを形成します。その後、入札金額はスワップの範囲内の基礎となるLPに比例して分配されます。その他の有効なリミットオーダーと基礎となるAMMの流動性は、同じ一様な清算価格で実行されます。
3. このバンドルは、提案されたアンガストロームノードによってイーサリアムのビルダーやパブリックメンプールに送信されます。
4. ビルダーは、ブロックの任意の位置にアングストロームバンドルを含めることができます。バンドルは順序に関係なく構築されているため、基本料金を支払うだけで含めることができます。

次の図は、ソブリン アプリケーションの動作を示しています。

アングストロームの取引供給チェーン

ライブネスと信頼の前提条件

ASSは、主権アプリケーションが規定されたシーケンスルールに従ってシーケンス化権を分散型ネットワークのオペレータに委任する部分ブロック構築の形態です。そのため、ASSには必然的に外部の関係者が関与し、追加のライブネスと信頼の前提条件が導入されます。

リブネス仮定

主権アプリケーションは、プロトコルを正しくフォローし、タイムリーな状態の更新を提供するために、アプリケーション固有のシーケンサに依存しています。ライブネスの違反などの場合には、ネットワークの分割では、有効なコンセンサスが復元されるまで、ユーザーはアプリケーションの一部を操作できない場合があります。

ソブリン アプリケーションでは、更新がシーケンサーに依存するコントラクト状態の範囲を制限することもできます。これにより、コントラクトの外部依存関係が最小限に抑えられ、シーケンサーに障害が発生した場合でも、預け入れられた流動性などの重要な状態にアクセスできるようになります。

信頼の前提

シーケンサーが所定のシーケンシングルールに準拠していることを確認するために、ソブリンアプリケーションは暗号経済ソリューション(PoSなど)または暗号手法(TEEやMPCなど)を活用できます。具体的なアプローチは、アプリケーションのニーズによって大きく異なる場合があります。実行の最適性に関するコンセンサスを必要とするものもあれば、暗号化メカニズムを通じて実行前のプライバシーを確保することに重点を置いたものもあります。シーケンサーの信頼オーバーヘッドを削減し、各ソブリンアプリケーション固有の目的を満たすために利用できるツールは多数あります。

検閲耐性

Ethereumエコシステムには、さまざまなタイプの検閲がある:

1. 規制に基づく検閲：ビルダーやリレーは、OFAC制裁リストに基づいてトランザクションを検閲します。これは現在のEthereumにおいて最も顕著な検閲形態の1つです。中継によって主に強制される.
2. 経済的な検閲：意図的な攻撃者はブロック提案者に賄賂を贈り、被害者の取引を検閲させる.
3. ノードレベルの検閲：P2Pネットワークのノードは、着信トランザクションの伝搬を拒否する場合があります。これは、プロトコルが着信トランザクションの大部分のノードが同じビューを共有しているという前提のもとで最適に動作する場合に、大きな問題となる可能性があります。さらに、このようなプロトコルでは、敵対者は正直なノードのローカルなビューを分割することに対してインセンティブを持つ場合があります（スロットの最後にトランザクションを半分のノードにのみ送信するなど）、その結果、プロトコルを停止させることができます。

多くの研究者が、イーサリアム上でより良い検閲耐性メカニズムの必要性を訴えています。いくつかの提案、例えば複数の同時提案者（MCP）そしてFork-Choice enforced Inclusion List (FOCIL)が表面化し、現在進行中の議論の中心となっています。

センシャーシップ耐性は、主権アプリケーションにとっても重要な懸念事項です。アプリケーション固有のシーケンサーは、さまざまな利害関係を持つ外部エンティティであり、追加のプライベートトランザクションとオーダーフローを受け取ることに関心を持っています。たとえば、市場メーカーであるアプリケーション固有のバリデータは、競合する市場メーカーが送信したトランザクションを検閲するインセンティブがあります。したがって、基本プロトコルが検閲しない場合でも、上位の主権アプリケーションはローカルな検閲に悩む可能性があります。

ASSの検閲耐性メカニズムの一例として、Angstromがあります。次のスロットにすべての有効な注文が含まれるようにするために、Angstromノードは確認済みの受信注文をブロードキャストし、提案されたトランザクションバンドルへの組み込みについて合意を形成する必要があります。ネットワークの大多数が観測した注文がバンドルに欠けている場合、提案者はペナルティを受けます。以下はAngstromの検閲耐性メカニズムのイラストです。

分散化された主権アプリケーションにおける検閲耐性

コンポーザビリティのジレンマ

ソブリン アプリケーションが直面する大きな課題の 1 つは、外部のコントラクト状態と対話するトランザクションとのコンポーザビリティを確保することです。アプリ固有のトランザクションを任意の外部トランザクションと単純にバンドルするだけでは、ソブリン アプリケーションとそのユーザーを保護するために必要な順序に依存しない特性が損なわれます。1 つの無効な非 ASS トランザクションは、アプリ固有のトランザクションで構成されている場合、バンドル全体を元に戻すという二次的な効果を持つ可能性があります。これが発生すると、ソブリンアプリケーションは、(有効なコンセンサスに達しているにもかかわらず)割り当てられたスロット中にユーザーの注文を実行できないため、ユーザーエクスペリエンスと全体的な福祉が損なわれます。

ただし、コンポーザビリティの問題に対する潜在的な解決策がいくつか存在し、様々なチームによって探求されています。これらには、インクルージョン事前確認、共有アプリケーション固有のシーケンサー、ビルダーコミットメントなどの概念が含まれ、それぞれがコンポーザビリティの程度と信頼オーバーヘッドのトレードオフを提供しています。

包含の事前確認

インクルージョンの事前確認を説明するには、まず、ベースの事前確認がどのように機能するかを理解することが重要です。ベースの事前確認は、提案者が現在のエポック内のスロットに先立って特定の取引セットを含めることを保証するために、賭けられた担保を提示していることを確認することにより、暗号経済のセキュリティを活用します。この保証は、参加提案者によって掲示された債券のサイズによって制限されます。

インクルージョンプリコンファーメーションは、トランザクションのインクルージョンが任意の契約状態に依存しない、特殊な形式のベースプリコンファーメーションです。インクルージョンプリコンファーメーションを要求するトランザクションは、ステートに関係なく、論争を起こさない必要があります。つまり、ブロック内の位置によってその実行が影響を受けないということです。インクルージョンプリコンファーメーションを利用することで、プロポーザーは、ASSバンドルが同じブロックに含まれる場合にのみ、非ASSトランザクションを含めることを確約することができます。このアプローチにより、論争のないトランザクションとASSバンドルの間で暗号経済的に強制されたコンポーザビリティが提供されます。

ASSを使用した事前検証の包含のイラスト

しかし、この解決策が提供する限られた合成性を考慮すると、追加される複雑さと信頼のオーバーヘッドは、特定の主権アプリケーションにとって利益よりも重くなる可能性があります。その結果、シンプルさと機能性のより効果的なバランスを提供できる代替のアプローチを探ることが重要です。

共有アプリケーション固有シーケンサー＆ビルダーコミットメント

提案者のコミットメントに頼る代わりに、主権アプリケーションはアプリ固有のシーケンサを使用して、複数のアプリケーション間のトランザクションの順序付けを管理することができます。たとえば、いくつかの主権アプリケーションのトランザクションを処理するシーケンサは、それぞれのシーケンスルールに従っている限り、それらの間での原子的な合成可能性を容易にします。この共有のアプリ固有のシーケンサのアプローチにより、主権アプリケーション間のシームレスな合成可能性と調整が実現されます。

ただし、非ソブリン アプリケーションの場合は、別のソリューションが必要です。ソブリンアプリケーションのシーケンス処理に参加するブロックビルダーからのトランザクションインクルージョンコミットメントは、非ソブリンアプリケーションとソブリンアプリケーションの間にアトミックなコンポーザビリティを生み出す可能性があります。Builder は、両方のタイプのアプリケーションで指定されたトランザクション順序を保証します。このようなビルダーのコミットメントは、ASSのコンポーザビリティのギャップを埋めることができます。

主権と非主権のdApps間の原子的な組み合わせ可能性を示したビルダーのコミットメントのイラスト（右）と主権アプリ間の原子的な組み合わせ可能性を示した共有アプリ固有シーケンサー（左）のイラスト

ビルダーコミットメントの経済的なダイナミクス、事前確認の包括性の実現可能性、および潜在的な2次効果に関する疑問は残っていますが、私たちはASSの相互運用性の課題が時間とともに解決されると確信しています。 このようなチームは、ディーエフアイのようなものです。アストリアそしてPrimevは、共有シーケンスとビルダーコミットメントの改善フレームワークの研究と開発を積極的に行っています。これらの進展が進むにつれて、相互運用性は主権アプリケーションにとってもはや問題ではなくなります。

ASS vs アプリケーション固有のL2およびL1

現在、dAppsはトランザクションのシーケンス制御を取得したい場合、アプリケーション固有のチェーンを構築する必要があります。 DeFiのようなコンセプトや、Gate.ioの製品名など、翻訳の際には特別な注意を払ってください。プロトコル所有ビルダー（PoB）Cosmos L1は、MEVをキャプチャしてアプリケーションに再配布するのに役立つ、より表現力豊かなシーケンスルールを持つことができます。同様に、VSRを備えたL2シーケンサもこのような操作を実行できます。どちらのソリューションも、アプリケーションによるMEVのより表現力豊かなシーケンシングとキャプチャを可能にしますが、ASSは次の特性により独特です。

1. トランザクションの実行に信頼のオーバーヘッドはありません-ASSはシーケンス化されたトランザクションを実行または決済しません。シーケンス化のみが委任されます。ベースラインの信頼の前提は、イーサリアムや他のL2などのネイティブな実行環境から拡張されます。
2. 流動性とオーダーフローへのアクセス-ユーザーはブリッジが必要ありません。dAppsはチェーン内のフローと流動性を直接活用できます。
3. 資産はネイティブの実行環境にとどまり、凍結することはできません – L2とは異なり、ほとんどのASSでは、ユーザーがつなぎ契約で資金をロックする必要はありません。この設計の選択により、セキュリティが向上します:アプリ固有のシーケンサーが失敗した場合、シーケンサーはスマートコントラクトによって設定された境界内でのみトランザクションを制御できるため、潜在的な損害は制限されます。一部のL2ソリューションには、脱出ハッチや強制的な包括性–これらの対策は、実際には使用が難しいことがよくあります。ユーザーは、L2 更新プログラムへの接続を失った後、避難ハッチをアクティブ化できるようになるまで数日待つ必要がある場合があります。同様に、L1 を介した強制的な包含には、通常、少なくとも一日の遅延。おそらく最も重要なのは、これらの安全対策は通常、ほとんどのユーザーが持っていない技術的な専門知識を必要とするため、一般の人にとっては実用的ではないことです。
4. 強力なLiveness仮定- L2のLivenessは実行ノードに依存し、通常はロールアップシーケンサーであり、シークエンスに基づいていない場合を除きます。 L1のLivenessは、対応する状態遷移関数を再実行するノードの誠実な大多数に依存します。主権アプリケーションのLivenessは主に基礎となる実行環境に依存し、スマートコントラクトはアプリケーション固有のシーケンサーに依存する必要がある部分を指定できます。

ソブリン アプリケーション、L2、ベース L2、L1 の比較表

結論

ASSは、トランザクションの順序付けに対する完全な主権をアプリケーションに提供し、実行管理の複雑さを伴わずにカスタムルールを定義できるようにします。この主権により、アプリケーションはその実行を制御して、ユーザーの結果を最適化できます。例えば、オングストロームでは、LPとスワッパーはファーストクラスの参加者として扱われ、彼らの経済的見返りはカスタムシーケンスルールによって直接強化されます。

さらに、ASSはユーザーのペイオフの最適性を強制し、堅牢な検閲耐性メカニズムを実装するために、さまざまな暗号経済学的および暗号化ツールを活用することができます。ステーキングやスラッシングなどの暗号経済学的なソリューションは、シーケンサー間での正直な行動を促進する一方、TEEやMPCのような暗号化手法はプライバシーとセキュリティを向上させます。これらのツールにより、ASSの設計の可能性は広範であり、より安全で効率的でユーザーセントリックな主権アプリケーションの作成が可能となります。

ASSが提供する機会にもかかわらず、ネイティブコンポーザビリティの欠如などの課題は依然として存在します。しかし、インクルージョンの事前確認、ASSの共有、ビルダーコミットメントなどのソリューションは、これらのハードルを克服するための有望な方法を提示します。いくつかの疑問は残っていますが、よりスムーズで構成可能な ASS エクスペリエンスを提供するために、これらのアプローチを洗練させることをお約束します。

私たちは、DeFiをより持続可能なものにするためにここにいます。一度に一つのASSです。

免責事項：

1. この記事は[から転載されました。sorella]. すべての著作権は元の著者に帰属します [湯木由美長].この転載に異議がある場合は、Gate Learnチームは速やかに対応いたします。
2. 責任の免責事項：この記事に表現されている意見は、著者個人のものであり、投資アドバイスを構成するものではありません。
3. 記事の翻訳は、Gate Learn チームによって他の言語に翻訳されます。特に言及されていない限り、翻訳された記事の複製、配布、盗用は禁止されています。