トランザクションが動作の操作方法を明示的に参照する場合、インテントは動作の期待される結果を参照します。
トランザクション命令が次の場合:
「A を実行してから B を実行し、C を支払って D を取得します。」
対応するインテントは次のようになります。
「お金を払う余裕があるので、D評価を獲得したいです。」
インテント中心のプロトコルにより、ユーザー エクスペリエンスと効率が大幅に向上します。トランザクションではユーザーが各パラメーターを明示的に指定する必要があり、操作のしきい値は高くなります。対照的に、インテントを使用すると、ユーザーは目的の結果を単に表現するだけで、結果を最適に達成するタスクを成熟したサードパーティに委託できます。
インテントはエコシステムにより多くの可能性をもたらしますが、イーサリアム チェーン上のインテント ベースの設計はオフチェーン インフラストラクチャにも大きな影響を与える可能性があり、MEV 関連の活動や市場管理との重要な関係もあります。
インテントの仕組み
現在、ユーザーがイーサリアムと対話する標準的な方法は、状態遷移を実行するために必要なすべての情報を EVM に提供する特定の形式でトランザクションとメッセージを作成して署名することです。ただし、トランザクションの作成には非常に複雑な操作が必要になる場合があります。トランザクションを作成するには、ガス料金を支払うために特定の資産を保持しながら、スマート コントラクトとノンス管理に関する多くの詳細が必要です。この複雑さは、ユーザーエクスペリエンスの低下と効率の低下につながります。これは、ユーザーが十分な情報なしで、または複雑な実行戦略を必要とせずに意思決定を行う必要があるためです。
Intentの目的は、ユーザーの負担を軽減することです。インテントを使用すると、ユーザーは一連の記述的な制約に署名することで完全な制御を割り当てることなく、トランザクションの作成をサードパーティにアウトソーシングできます。
標準的なトランザクションベースのプロセスでは、バリデーターが検証する動機を与えられている場合、トランザクション署名により、バリデーターは特定の状態の計算パスを正確にたどることができます。対照的に、インテントはどの計算パスを取る必要があるかを正確に指定しませんが、特定の制約を満たすあらゆるアクションを許可します。インテントに署名して共有することで、ユーザーは受信者に、自分に代わって計算パスを選択する許可を事実上付与します (下の図を参照)。単一のトランザクションに複数のインテントを含めることができるため、重複するインテントを照合できるようになり、ガス料金が節約され、経済効率が向上することは注目に値します。さらに、ユーザーは、サードパーティがガスのスポンサーになったり、他のトークンで支払ったりすることを許可するなど、より柔軟にガス料金を支払うことができます。
図に示すように、トランザクションを送信するとき、ユーザーは正確な計算パスを指定します。インテントを送信するとき、ユーザーは目標といくつかの制約を指定し、マッチメイキングが実行する計算パスを決定します。
インテントの適用状況
インテントを作成すると、ブロックチェーンとのやり取りの複雑さがアウトソーシングされる一方で、ユーザーは自分の資産と暗号化された ID を管理できるようになります。実際、インテントに関する多くの概念は、次のシナリオなど、数年間稼働しているシステムに対応しています。
制限付き順序: ユーザーが少なくとも 200 B トークンを受け取った場合、100 A トークンをユーザーのアカウントから引き出すことができます。
制限付き順序: ユーザーが少なくとも 200 B トークンを受け取った場合、100 A トークンをユーザーのアカウントから引き出すことができます。
カウスワップ スタイル オークション: 制限付き注文と同じですが、執行品質を最大化するために複数の注文を照合するサードパーティまたはメカニズムに依存します。
ガススポンサーシップ: ユーザーは取引手数料を ETH ではなく USDC で支払うことを選択でき、アカウントにはガス料金を支払うための USDC が存在します。
委任された承認: 事前に承認された特定の方法でのみ、特定のアカウントとの対話を許可します。インテントは、最終トランザクションがインテントで指定されたアクセス制御リストに従う場合にのみ実行できます。
マージされたトランザクション処理: 複数のインテントをマージしてガス効率を向上させることができます。
アグリゲーター: 複数のシナリオの集約を実行し、インテントへの最適なパスを選択することによって、最良の価格/利回りのみを使用して動作します。
現在、Intent には、クロスチェーン MEV (SUAVE など)、ERC4337 タイプのアカウント抽象化、およびシーポート注文シナリオにおける新しいアプリケーションがあります。 ERC4337 が開発中である一方で、他の新しいアプリケーション (クロスドメイン インテントなど) も探索段階に入っています。
すべてのインテントベースのアプリケーションでは、インテントを理解し、タイムリーにインテントを実行するよう動機づけられるグループが少なくとも 1 つ存在する必要があります。この役割を誰が担うのか、どのように実装されるのか、そしてそのインセンティブについては、インテント駆動型システムの有効性、信頼性、その他の影響を判断するために、さらなる調査と実践が必要です。
仲介者とメンプール
インテントを積極的な仲介者の手に渡す最も明白な方法は、イーサリアムの Mempool です。ただし、現在の Mempool 設計はインテントの伝播をサポートしていません。長期的には、DOS 攻撃の隠れた危険性を考慮すると、イーサリアム メンプールでインテントの拡散が広範にサポートされる可能性は非常に低いです。イーサリアム メンプールのオープンでパーミッションレスな性質が、インテンの採用に対する障壁となっていると言えます。
Ethereum Mempool が存在しない場合、Intent システムの設計者はいくつかの問題に直面します。現在直面している選択は、インテントをライセンサーに伝播するか、許可のない方法でどの当事者もインテントを実行できるようにするかです。
図に示すように、インテントはまずユーザーから許可/許可なしのパブリック/プライベート Intentpool に流れ、次に matchmaker を介してトランザクションに変換され、最後にパブリック Mempool に変換されるか、または を通じてチェーン上に直接表示されます。 MEV Boostタイプのオークションです。
許可なくメンプール
試みられている設計の 1 つは、システム内のさまざまなノードがゴシップ経由でインテントをブロードキャストできるようにする分散型 API で、これにより実行者への許可のないアクセスが提供されます。
たとえば、0x プロトコル リレーラーでは、制限された命令が相互にゴシップ ブロードキャストされ、一致が見つかるとチェーンにアップロードされます。このアプローチは、集中化と検閲のリスクに対抗するために、共有 ERC4337 Mempool のコンテキストでも検討されています。ただし、このパーミッションレスな Intentpool の設計は次の課題にも直面しています。
DoS 耐性: 開発者は、潜在的な DoS 攻撃を回避するために、インテントの機能を制限する必要がある場合があります。
インセンティブの拡散: 多くのアプリケーションにとって、インテントの実行は収益性の高いアクティビティです。したがって、理論的には、インテントプールを操作するノードには、インテントを実行するための競争を減らすために、インテントを伝播しないインセンティブがあります。
DoS 耐性: 開発者は、潜在的な DoS 攻撃を回避するために、インテントの機能を制限する必要がある場合があります。
インセンティブの拡散: 多くのアプリケーションにとって、インテントの実行は収益性の高いアクティビティです。したがって、理論的には、インテントプールを操作するノードには、インテントを実行するための競争を減らすために、インテントを伝播しないインセンティブがあります。
MEV: インテントの実行品質はオフチェーン参加者の善良な行動に依存するため、パブリックでパーミッションレスなインテントプールを使用する場合にはいくつかの困難に直面します。実行が利益を生む場合、権限のない Intentpool はユーザーに対して裁定取引を試みる可能性があります。これは、イーサリアム・メンプールにおける現在の「サンドイッチ攻撃」に似ており、Defi関連のインテントにとって一般的な問題となります。将来の改善としては、権限はなくても暗号化された Intentpool を作成することが考えられます。
ライセンス付きメンプール
信頼できる集中型 API は DOS 攻撃に対する耐性が高く、インテントを伝播する必要がありません。この信頼モデルは、MEV の懸念にある程度の根拠を提供します。信頼の仮定が維持される限り、実行の品質は保証されます。信頼できる仲介者には評判もあり、誠実に業務を遂行するインセンティブが得られる場合もあります。
したがって、許可された IntentPool は、短期的にはインテントベースのアプリケーション開発者にとって魅力的になるでしょう。ただし、強い信頼の前提には当然のことながら欠陥があり、元のブロックチェーンの精神にある程度違反します。
ハイブリッドソリューション
上記の 2 つの状況を組み合わせた解決策もあります。たとえば、伝播プロセスは許可されているが実行は許可されていない、またはその逆の状況が考えられます。ハイブリッド ソリューションの一般的な例は、オーダー フロー オークションです。
このタイプの設計の背後にある考え方は、取引相手を必要とするユーザーが、より有利な価格で取引するために、より良い取引相手と悪い取引相手を区別する必要があるかもしれないということです。通常、設計プロセスには、ユーザーから意図 (またはトランザクション) を取得し、ユーザーに代わってオークションを促進する信頼できる当事者が関与します。オークションに参加するのに許可は必要ありません。このタイプの設計には、ライセンスされた Intentpool でさまざまな干渉を受ける可能性が高いという欠点もあります。
このアプローチの要点は、インテント ベースのアプリケーションには、スマート コントラクトと対話するための新しいメッセージ形式だけでなく、mempool に代わる形式での伝播および敵対者発見メカニズムも含まれるということです。現時点で最も重要なことは、分散化を維持しながらインセンティブと両立するインテントの発見とマッチングのメカニズムを設計することです。
リスクとその対処方法
インテントはトランザクションにとってエキサイティングな新しいパラダイムですが、インテントが広く採用されるということは、より多くのユーザー アクティビティが代替 Mempool に移行する傾向が加速することも意味します。適切に管理されない場合、この変化はイーサリアムの分散化に悪影響を及ぼし、信頼できる当事者の過剰な権力につながる可能性があり、潜在的なリスクには以下が含まれます。
注文フロー: インテントの実行が許可されているにもかかわらず、ユーザーがそれを不用意に選択し、パブリック Mempool から移行した場合、イーサリアム ブロックの生成が集中化される可能性があります。
信頼: 多くのソリューションでは、インテントの実行品質を確保するために仲介者に対する信頼が必要となるため、この高い参入障壁は、新しいインテントベースのアーキテクチャの開発を妨げ、イノベーションと競争の速度を低下させます。
透明性: 多くのインテント アーキテクチャでは、妥協策としてチェーン アセットと許可された Mempool に対する制御をユーザーに引き渡す必要があるため、外部からの侵入がある程度不可能になるため、構築されるシステムが不透明になるリスクがあります。ケース ユーザーの期待がどのように満たされるのか、またエコシステムに対する未検出の脅威があるかどうかは不明です。ユーザーとブロックチェーンの間で発展するミドルウェアやMempoolのエコシステムさえも不透明になるだろう。
では、上記のリスクを軽減するにはどうすればよいでしょうか?イーサリアム メンプールのスペースが限られていることは承知しています。一部のアプリケーションでは、プライバシーが欠如しているため、より広範囲のメッセージ形式をサポートできないことがリスクの原因となります。これにより、ウォレットとアプリケーションの開発者は、上記のリスクを回避しながらユーザーがブロックチェーンに接続できるようにする何らかの方法を見つけなければならないため、難しい立場に置かれます。
理想的なシステムは、実行品質をあまり犠牲にすることなく、誰でもインテントを照合して実行できるように、パーミッションレスである必要があります。新しい Mempool を作成せずに新しいアプリケーションをデプロイできるように、システムは多用途である必要があります。システムは透明性が高く、インテントの実行プロセスの公開レポートを可能にし、プライバシーの保証が許す場合には品質監査を実行するためのデータを提供する必要があります。
FlashBots や Anoma などのチームは、プライバシーと非許可性を組み合わせることにより、上記の普遍的なソリューションの要件を満たすために懸命に取り組んでいますが、近い将来、そのような完璧なシステムを作成することは困難になるでしょう。したがって、ユーザーはトレードオフを検討し、アプリケーションごとに異なるソリューションを選択する必要があります。同様に、Intentpool を開始するアプリケーションは、許可なく遍在性を追求し、許可が得られる場合は仲介者を慎重に選択する必要があります。
インテントベースのアプリケーションの設計者は、アプリケーションのオフチェーンへの影響を十分に考慮する必要があります。アプリケーションはユーザー ベースだけでなく、より広範なコミュニティに関係するため、より広範なコミュニティがイーサリアムを取り巻くオフチェーンへの影響を理解する必要があります。生態系は引き続き注意を払っています。
インテントベースのアプリケーションの設計者は、アプリケーションのオフチェーンへの影響を十分に考慮する必要があります。アプリケーションはユーザー ベースだけでなく、より広範なコミュニティに関係するため、より広範なコミュニティがイーサリアムを取り巻くオフチェーンへの影響を理解する必要があります。生態系は引き続き注意を払っています。
まとめ
インテント アプリケーションに対する市場の需要は明らかであるため、ここ数年、多くのインテント ベースのアプリケーションが広く使用されてきました。 ERC4337 によって部分的に推進されるインテントの採用の増加により、イーサリアム メンプールから新しい場所への移行が加速する可能性があります。 Intent の採用は、ユーザーが「強制操作」パラダイムから「記述的」パラダイムへ移行することを意味し、ユーザー エクスペリエンスと効率性が大幅に向上することが期待されます。
全てのコメント