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