トランザクションがアクションを「どのように」実行するかを明示的に指す場合、インテントはそのアクションの期待される結果がどうあるべきかを指します。トランザクションの内容が「最初に A を実行し、次に B を実行し、X を得るために C を支払う」である場合、意図は「X が欲しいので、C を支払うつもりです」です。
信頼できる集中型 API は DoS 攻撃に対する耐性が高く、意図を伝播する必要がありません。信頼モデルは、MEV の問題に対する基礎も提供します。信頼の前提が維持される限り、実行の品質は保証されるはずです。信頼できる仲介者には評判が関連付けられている場合もあり、それがうまく実行する動機となります。したがって、許可されたインテント プールは、短期的にはインテント ベースのアプリケーション開発者にとって魅力的です。しかし、強い信頼の前提には欠陥があり、ブロックチェーンの精神の多くとは相反するものであることは誰もがよく知っています。これらの問題については以下で説明します。
パラダイム: インテントベースのアーキテクチャとそのリスク
執筆者: クインタス キルボーン、ゲオルギオス コンスタントプロス 編集者: ケイト、マースビット
＃＃ 導入
「インテント」とその応用に関する議論が、最近イーサリアム コミュニティで話題になっています。
トランザクションがアクションを「どのように」実行するかを明示的に指す場合、インテントはそのアクションの期待される結果がどうあるべきかを指します。トランザクションの内容が「最初に A を実行し、次に B を実行し、X を得るために C を支払う」である場合、意図は「X が欲しいので、C を支払うつもりです」です。
この宣言型パラダイムは、ユーザー エクスペリエンスと効率に素晴らしい改善をもたらします。インテントを使用すると、ユーザーは単に望ましい結果を表現するだけで、その結果を最適に達成するタスクを経験豊富なサードパーティにアウトソーシングできます。インテントの概念は、各パラメーターがユーザーによって明示的に指定される今日の命令型トランザクション パラダイムとは対照的です。
これらの改善が期待されることで、エコシステムにとって待望の前進がもたらされますが、イーサリアム上のインテントベースの設計は、オフチェーンのインフラストラクチャにも重大な影響を与える可能性があります。特に、MEV 関連の活動と市場管理の間には重要なつながりがあります。この記事は、意図とその利点の簡単な定義を提供し、その実装に伴うリスクを調査し、潜在的な緩和策について説明することを目的としています。
インテントとは何ですか?
ユーザーがイーサリアムと対話する現在の標準的な方法は、イーサリアム仮想マシン (EVM) が状態遷移を実行するために必要なすべての情報を特定の形式で提供するトランザクションを作成して署名することです。ただし、トランザクションの作成は複雑な作業となる場合があります。トランザクションを作成するには、ガス料金を支払うために特定の資産を保持しながら、スマート コントラクトやノンス管理の広大なネットワークなどの詳細について推論する必要があります。この複雑さにより、ユーザーは情報や複雑な適用ポリシーに適切にアクセスできないまま意思決定を強いられるため、ユーザー エクスペリエンスが最適ではなくなり、効率が低下します。
こうした負担を軽減する狙いがある。非公式には、インテントは一連の宣言的制約として署名され、ユーザーがトランザクション当事者の完全な制御を手放すことなく、トランザクションの作成をサードパーティにアウトソーシングできるようになります。
標準のトランザクションベースのプロセスでは、トランザクション署名により、バリデーターは状態の 1 つの計算パスをたどることができ、ヒントによってバリデーターがそうするように動機づけられます。一方、インテントは、取るべき計算パスを指定しませんが、特定の制約を満たす任意の計算パスを許可します。インテントに署名して共有することで、ユーザーは受信者に自分に代わって計算パスを選択する権限を効果的に付与します (以下の図を参照)。この区別により、署名付きメッセージとしてのインテントの少し厳密な定義が可能になり、特定の開始状態からの一連の状態遷移が許可されます。特殊なケースとしては、一意の遷移が許可されるトランザクションが挙げられます。そうは言っても、私たちは引き続き「意図」とトランザクションを区別していきます。
*図 1: トランザクションを送信するとき、ユーザーは正確な計算パスを指定します。インテントを送信するとき、ユーザーは目標といくつかの制約を指定し、マッチング プロセスによって実行する計算パスが決定されます。 *
重要なのは、多くのインテントを 1 つのトランザクションに含めることができるため、重複するインテントを照合できるため、ガス効率と経済効率が向上します。たとえば、ビルダーが管理する注文帳では、2 つの注文が市場に参入する前に互いに打ち消し合う可能性があります。他のアプリケーションには、異なるドメインでの複数のトランザクションではなく単一のメッセージに署名するクロスドメイン インテント、さまざまなリプレイ耐性スキームを使用したもの、およびサードパーティによるガスのスポンサーや異なるトークン支払いでのガスの支払いを許可するなど、より柔軟なユーザー ガス支払いが含まれます。 。
過去と未来は意図です
この目的は、ブロックチェーンとのやり取りの複雑さをアウトソーシングしながら、ユーザーが自分の資産と暗号化された ID を管理できるようにするために作成されました。
これらのアイデアの多くは、長年運用されてきたシステムに対応していることに気づくかもしれません。
今後、クロスチェーン MEV (SUAVE など)、ERC4337 スタイルのアカウント抽象化、さらには Seaport オーダーのコンテキストで意図が再活性化されます。 ERC4337 は全速力で前進していますが、クロスドメイン インテントなどの他の新しいアプリケーションについては、依然としてさらなる研究が必要です。インテントとそのアプリケーションの詳細については、この講演で説明します。
重要なのは、新旧のすべてのインテントベースのアプリケーションでは、インテントを理解し、それを実行する意欲があり、インテントをタイムリーに実行できる相手が少なくとも 1 人必要です。これらの当事者が誰であるか、実行がどのように行われるか、その動機は何であるかは、インテント駆動型システムの有効性、信頼の前提、およびより広範な影響を判断するために尋ねる必要がある質問です。
仲介者とそのメンバープール
最も明白なチャネルはイーサリアム メンプールです。残念ながら、現在の設計ではインテントの伝播はサポートされていません。 DoS 攻撃に関する懸念は、たとえ長期的に見ても、イーサリアム メンプールにおける完全に汎用的なインテントの一般的なサポートが不可能であることを意味する可能性があります。以下で説明するように、イーサリアム メンプールのオープンでパーミッションレスな性質は、採用意図に対するさらなる障壁となります。
イーサリアム メンプールが存在しないため、インテント システム設計者は現在、いくつかの設計上の問題に直面しています。大まかな決定は、インテントを許可されたセットに伝播するか、またはどちらかの当事者がインテントを実行できるように許可のない方法で提供するかどうかです。
図 2: インテントはユーザーから許可/許可なしおよびパブリック/プライベート インテント プールに流れ、マッチメーカーによってトランザクションに変換され、最終的にパブリック メモリ プールに送られるか、MEV ブースト スタイルのオークションを介して直接オンチェーンに送られます
ライセンスのないメモリ プール
目指すべき設計の 1 つは、システム内のノード間で意図を伝播させ、実行者に許可のないアクセスを提供する分散型 API です。これは以前にも行われたことがある。たとえば、0x プロトコルでは、中継者同士がリミットオーダーをチャットし、一致した場合にオンチェーンに配置します。このアイデアは、集中化と検閲のリスクに対抗するために、共有 ERC4337 メモリプールのコンテキストでも検討されました。ただし、このようなパーミッションレスな「インテント プール」の設計は、いくつかの重大な課題に直面しています。
許可された「メモリ プール」
信頼できる集中型 API は DoS 攻撃に対する耐性が高く、意図を伝播する必要がありません。信頼モデルは、MEV の問題に対する基礎も提供します。信頼の前提が維持される限り、実行の品質は保証されるはずです。信頼できる仲介者には評判が関連付けられている場合もあり、それがうまく実行する動機となります。したがって、許可されたインテント プールは、短期的にはインテント ベースのアプリケーション開発者にとって魅力的です。しかし、強い信頼の前提には欠陥があり、ブロックチェーンの精神の多くとは相反するものであることは誰もがよく知っています。これらの問題については以下で説明します。
ハイブリッド ソリューション
いくつかの溶液は上記の混合物です。たとえば、伝播する権限はあるが、実行する権限がない場合もあります (信頼の仮定が成り立つと仮定します)。またその逆も同様です。ハイブリッド ソリューションの一般的な例は、オーダー フロー オークションです。
これらの設計の背後にある大まかな考え方は、取引相手を必要とするユーザーは、より良い取引相手とより悪い取引相手 (たとえば、有利な価格で取引を受け入れる相手) を区別する必要があるかもしれないということです。通常、設計フローには、ユーザーからインテント (またはトランザクション) を受け取り、ユーザーに代わってオークションを促進する信頼できる当事者が含まれます。オークションへの参加には（場合によっては）許可が必要ありません。
これらのタイプの設計には独自の欠点があり、多くのパーミッション インテント プールに関係する可能性がありますが、後で明らかになる重要な違いがいくつかあります。
結論: インテントベースのアプリケーションには、スマート コントラクトと対話するための新しいメッセージ形式が含まれるだけでなく、代替メモリプールの形式での伝播および敵対者発見メカニズムも含まれます。インセンティブと互換性があり、同時に分散化されたインテントの検出とマッチングのメカニズムを設計することは簡単ではありません。
どこを間違えればよいでしょうか?
インテントはエキサイティングな新しいトランザクション パラダイムですが、その広範な採用は、ユーザー アクティビティを他のメモリプールに移すというより大きな傾向を加速することを意味する可能性があります。適切に管理されなければ、この変化は家賃を求める仲介業者の集中化と定着につながる可能性があります。
注文の流れ
インテントの実行が許可されており、権限セットが慎重に選択されていない場合、パブリック メモリプールから移行すると、イーサリアムのブロック生成が集中化される可能性があります。
インテントの実行が許可されているが、許可セットが慎重に選択されていない場合、パブリック メモリプールから移行すると、イーサリアムでのブロック生成を一元化できます。
現在、イーサリアム上のブロック生成の大部分は、プロポーザーとビルダーの分離 (PBS) のオフプロトコル実装である MEV-Boost 経由で行われており、現在のロードマップでは、このインターフェイスがすぐに変更される兆候は示されていません。 PBS は、ブロック ビルダーが MEV をバリデータ セットに誘導するための競争市場の存在に依存しています。 PBS の主な問題は、ブロック ビルダーが貴重なブロック、トランザクションと意図、別名「注文フロー」を生成するために必要な原材料に独占的にアクセスできることです。 PBS 用語では、インテントへの許可されたアクセスは排他的オーダー フロー (EOF) として知られています。このペーパーで説明したように、注文フローの独占性は競争力に対する堀を意味するため、EOF が間違った当事者の手に渡れば、PBS が依存する市場構造が脅かされます。
イーサリアムの注文フローの大部分を制御するブロックビルダー（または協力団体）は、メインネットブロックの大部分を生成できるようになり、検閲への道が開かれます。ネットワークは、バリデーターに価値を渡す（または将来バーンされる）ためにビルダー間の競争に依存しているため、単一のビルダーの優位性は、イーサリアムからビルダーへの価値の移転を構成します。もちろん、家賃の徴収と検閲はプロトコルに対する重要な脅威です。
＃＃＃ 信頼
多くのソリューションは仲介者への信頼を必要とするため、新しいインテントベースのアーキテクチャの開発は高い参入障壁によって妨げられています。これは、実行の品質を確保するためのイノベーションと競争の割合が低いことを意味します。
最悪の場合、ユーザーは、前のセクションの独占ブロック ビルダーのように、一方の当事者だけが意図を実行する立場に陥ることになります。そのような世界では、独占ブロックの建設業者が賃料を搾り取ることができ、意図を処理する方法に関する新しい提案は建設業者が採用しなければ拒否されることになります。独占に直面すると、個々のユーザーは交渉力を失います。ユーザーが仲介者に余分な自由度を与えようとすると、その影響はさらに悪化します。
残念ながら、インフラの一元化による市場の停滞には、建設業者の市場に関する懸念は含まれていません。ノンブロック建築事業の場合でも、参入障壁が高く、競争がほとんどない仲介業者が有利な立場に置かれる可能性があります。たとえば、オーダーフローオークション市場の現状を考えてみましょう。 Flashbots や CoWswap などの少数のエンティティが、OFA に流れる注文のほとんどを受け取ります。注文の流れが分散しているのは主に、これらの事業体が長年存在しているか、評判の良い事業体と提携しているためであり、これは、ある程度の社会的信頼を得ることができたことを意味します。新しいOFA設計が市場に参入しようとすると、新しいOFAを運営している人は、そのOFAが評判が良く、権力を乱用しないことをユーザーとウォレットに説得するために多くの時間を費やす必要があります。この信頼を獲得する必要性は、確かに参入にとって大きな障壁となります。
オーダーフローオークション市場は最近になって勢いを増し始めたばかりで、競争がどのように発展するかはまだ分からないが、この市場は、許可された信頼できるメンプールに少数の強力な参加者が含まれている可能性があり、それによって市場に悪影響を与える可能性があるという実例を提供している。ユーザーの最善の利益。
EIP4337 インテント フォーマットは、可能なメカニズムの別の例を提供します。 4337 インテントをサポートするために信頼できるアーキテクチャが導入されている世界を考えてみましょう。別のインテント形式が提案された場合、クロスオリジン機能などの他のユースケースに役立つ可能性がありますが、確立された信頼できる仲介者はこの新しい形式を採用しません（結局のところ、あまり採用されず、ビジネスモデルと競合します）。新しい形式の場合は、新しいエンティティに対する信頼を確立する必要があります。私たちは再び、イノベーションと現状への挑戦が信頼に基づく参入障壁にぶつかる状況に陥っています。
不透明度
多くのインテント アーキテクチャでは、ユーザーがオンチェーン アセットに対する制御の一部を放棄する必要があり、許可されたメモリプールは外部からのある程度の不透過性を暗示しているため、ユーザーが何を期待しているか、またはそれが満たされているかどうかが不明確な不透明なシステムを構築するリスクがあります。 、そして生態系への脅威は検出されないままです。
上記のセクションでは、オーダーフロー市場における電力の不均衡がユーザーとプロトコルにもたらすリスクについて説明します。関連する問題は、ユーザーとブロックチェーンの間で開発されるミドルウェアとメンプールのエコシステムが、熱心な観察者にとってさえ不透明になることです。この問題は、注文のルーティングなどの重要な決定をユーザーにアウトソーシングできるようにしようとするインテントベースのアプリケーションに特に当てはまります。
MEV がユーザーの実行に悪影響を与える状況は、多くの場合、トランザクションが実行者に高い自由度 (スリッページ制限など) を放棄していることが原因です。したがって、より大きな自由度を放棄するインテントベースのアプリケーションは、実行するシステムをより慎重に設計する必要があると主張するのは、論理の大きな飛躍ではありません。この点での最悪の結果は、インテントベースのアプリケーションを使用するには、消えるインテント (お望みなら暗い森の中に) に署名する必要があり、そのインテントが、作成された方法や作成者が明らかでないまま、何らかの形でトランザクションとして実装されることです。もちろん、このようなエコシステムを監視できるかどうかは、EOF や信頼ベースの防御に関する懸念にも関連しています。このエコシステムが最も熱心な観察者にとって曖昧である場合、イーサリアムコミュニティはブロック生産エコシステムの健全性に対する脅威をどのように監視することになっているのでしょうか?
リスクを軽減する
イーサリアムのメンプールには制限があります。一部のアプリケーションでは、これはプライバシーの欠如 (真ん中に挟まれている) が原因であり、他のアプリケーションでは、より広範囲のメッセージ形式をサポートできないことが原因です。これにより、ウォレットとアプリケーションの開発者は、前述の危険を回避しながらユーザーをブロックチェーンに接続する何らかの方法を見つける必要があるため、窮地に陥ります。
上記の質問を検討すると、理想的なシステムの特定の特性を推測できます。そのようなシステムはこうあるべきです
パーミッションレスなので、実行品質をあまり犠牲にすることなく、誰でもインテントを照合して実行できます。
汎用なので、新しいアプリケーションをデプロイするときに新しいメモリ プールを作成する必要がありません。
透明性があるため、プライバシーの保証が許可される場合、インテントの実行を報告するプロセスが公的に報告され、品質監査を実行するためのデータが提供されます。
Flashbots や Anoma などのチームは、プライバシーと非許可性を組み合わせて上記の要件を満たす一般的なソリューションに取り組んでいますが、理想的なシステムはすぐには完成しない可能性があります。したがって、異なるソリューションでは、異なるアプリケーションに最適な独自のトレードオフが発生します。 crlist のようなメカニズムは、トランザクションベースのアプリケーションを取り巻く同じ問題の多くに対応して発生したものであり、意図に適用できない可能性がありますが、ユーザーが可能な限りトランザクションにフォールバックできるガジェットは、最悪のケースを改善するのに適しています。同様に、許可されていない場合でもインテント プールを開始したいアプリケーションは、共通性を探すのが適切であり、共通性を探す場合は仲介者を慎重に選択します。
大まかに言うと、私たちはインテントベースのアプリケーション設計者に対し、アプリケーションのオフチェーンへの影響を十分に考慮するよう求めています。これは、アプリケーションがユーザー ベースだけでなく、より広範なコミュニティに影響を与える可能性があるためです。また、より広範なコミュニティに対しては、オフチェーンに重点を置くよう求めています。イーサリアムを中心としたエコシステム。
＃＃ 結論は
インテントの採用は、命令型から宣言型パラダイムへの移行を表しており、MEV リークによるユーザー エクスペリエンスと効率損失が大幅に改善されることが期待されます。これらのアプリケーションの必要性は明らかであり、多くのインテントベースのアプリケーションが長年にわたって広く使用されてきました。
ERC4337 によって推進される採用意向の高まりにより、イーサリアム メンプールの新しい会場への移転が加速する可能性があります。この変化は合理的かつ避けられないものですが、インテントベースのアプリケーション設計者には、堅牢なインフラストラクチャを開発する際にシステムのオフチェーン コンポーネントを慎重に設計する十分な理由があります。
この初期のトランザクション パラダイムや、プライバシーを可能にする意図表現言語の設計など、本稿で取り上げなかった領域では、やるべき研究とエンジニアリングがまだたくさんあります。これまたはその他のインテント関連の研究トピックに興味がある場合は、0xquintus georgios@paradigm.xyz までご連絡ください。
*この記事に対するフィードバックをくださった Dan Robinson 氏、Charlie Noyes 氏、Matt Huang 氏、John gu 氏、Xinyuan Sun 氏、Elijah Fox 氏、およびグラフィック デザインを担当してくださった Achal Srinivasan 氏に多大な感謝を申し上げます。 *