原題:「インテントに関する不完全な入門書」

作者: 0xemperor.eth

編集者: Qianwen、ChainCatcher

インテントは、暗号化分野の最近の研究議論で一般的になり、さまざまなプロトコルでこの概念が利用されており、Anoma や Essential などのプロトコルがこの概念を利用しています。

この記事は、さまざまな観点について予備的な紹介を提供し、最後に自然言語で意図を表現する場合の意図解決アーキテクチャの表現形式を紹介することを目的としています。インテントの概念が成功すれば、あらゆるレベルでアプリケーション アーキテクチャに革命を起こす可能性があります。

どういう意図があるのでしょうか？

インテントを使用すると、ユーザーは正確なメッセージ呼び出しを行うことなく、特定の取引条件や好みを指定できるため、柔軟性が向上し、オンチェーンの複雑さが軽減されます。

「インテントベースのアーキテクチャとそのリスク」の記事では、インテントの定義は次のとおりです。 インテントとは、ユーザーがトランザクション パーティの完全な制御を放棄することなく、トランザクションの作成をサード パーティにアウトソーシングできるようにする一連の宣言的な制限です。

ポッドキャストの中で、Anoma の Chris Goes 氏は、これを 2 つの側面から定義しました。意図とは、「特定のシステム状態の設定に対する信頼できるコミットメント」と「情報フロー制限に対する信頼できるコミットメント」を指します。

意図について直感的に考えると、意図は基本的に望ましい結果を表すということになります。意図を表明するとき、定義するのは望む結果だけであり、そこに至るまでのプロセスは定義しません。

たとえば、テザー (USDT) を ETH に交換したい場合、取引所の選択、アカウントの設定/トランザクションの署名、送金の処理 (または仮想通貨のゴミの除去など) プロセス全体を自分で管理する必要はありません。あなたのウォレット）など、1 ETH を 2,000 USDT に交換したい旨の意向表明書を提出するだけです。別のエンティティ (ソルバーと呼ばれます) がユーザーの意図を受け取り、それを実装する方法を見つけ出します。ソルバーは厄介な詳細を処理し、最適な結果を最適化するために一生懸命働きます。

重要なのは、意図がプロセスではなく結果に焦点を当てていることです。ユーザーが望ましい結果を定義し、他のユーザーがプロセスを通じてその結果を達成します。インテントを使用すると、手順を気にせずに結果を指定できるため、ほとんどのユーザーが使用する暗号通貨のトランザクション プロセスが大幅に簡素化されます。

より高次元の考え方は、ユーザーがどの契約から取引を開始するかを指定することなく、必要なものを定義できるということです (計算されたパスまたは単に取引パスと呼ぶことができます)。ユーザーは、特定のパスまたは契約を優先することを示すことで、これを制限することもできます。

例

カウスワップ

Cowswap は、中核となる価格発見メカニズムとしてバッチ オークションを使用します。 Cowswap は AMM のようにトランザクションを即座に実行するのではなく、オフチェーンで注文を集約し、バッチで決済します。これにより、全取引の統一決済価格を一括で決定することが可能となり、即時約定モデルにありがちなフロントランニングなどの問題を解消します。バッチ オークションでは、多くの取引を同時に決済することもでき、ガス料金を最適化できます。ソルバーは、取引の各バッチに関与する当事者の利益が最大化されることを保証するために注文決済ソリューションを提案するために、ソルバー間でオープンな競争を実施します。最適なソリューションが最終的な均一価格を決定します。全体として、バッチ オークションは、即時実行モデルでは達成できない公平性、効率性、および MEV 保護を実現します。

Cowswap のバッチ オークション モデルの重要な革新は、注文間のウォンツの一致 (CoW) を見つける機能です。 CoW は、相互需要のあるトランザクション間の直接ピアツーピア決済です。この流動性の共有は、これらの取引を促進するために外部の流動性プロバイダーが必要ないことを意味します。 CoW では、リング トランザクションに複数のアセットを同時に含めることもできます。 CoW を最大限に活用することで、バッチ オークションは個別の資金プールよりも高い流動性を実現できます。許可されている場合、決済には CoW が利用され、残りはオンチェーン流動性を通じて実行されます。バッチ オークションと CoW 流動性共有を組み合わせることで、トレーダーはより適切な価格設定と約定を実現できます。

CoWswap モデルはインテント モデルに似ています。ユーザーは指値注文の形式で取引の意図を表現します。取引の意図はオーダー ブックに入力されます。ソルバーはオーダー ブックのステータスを使用して、リング トランザクションの形式でそれらを照合するか、ルーティングします。 AMM 経由 (つまり、ユーザーは計算されたパスや実行したい特定の場所ではなく、価格のみを言及します)。

ユニスワップX

Uniswap Xの論文では、ダッチオークションを介したオンチェーン決済で署名されたオフチェーン注文を使用する分散型交換プロトコルを提案しています。ユーザーは注文に署名し、入出力トークン、数量、価格制限などのパラメーターを指定します。これらの注文は、最良の執行価格を競う「フィラー」に分配されます。

Uniswap Xは、オフチェーン照会システムを通じてダッチオークションの初期価格を設定することを推奨しています。ユーザーはフィラーネットワークから価格をリクエストすることができ、誠実な価格設定を奨励するために最良の入札に対して短い独占期間が設けられており、その後、注文はオランダの公開オークションに掛けられます。

Uniswap X と Cowswap の類似点

意図の正式な定義

ユーザーは「X 資産を Y 資産と交換したい」などの意図を表現するだけで、ソルバーはその意図を最適に実装し、バックグラウンドでブロックチェーン関連の詳細をすべて処理する方法を見つけ出します。ソルバーは、意図が実現されたという証拠を提供し、分散型で意図を実現するためのオークションやその他のメカニズムに参加できます。

このブログでは、いくつかの定義を検討します。

最初のモデル: インテント i はタプル (B、E、T) として定義されます。

意図が状態 q0∈B で開始され、トランザクション シーケンス t∈T を介して状態 qn∈E で終了する場合、意図は満たされたと見なされます。

インテントのクリア: セット B、E、T に空でない交差がある場合、インテントのセット to、...、tm をクリアでき、これらの交差を使用してメタインテント t' を作成できるようになります。

前に述べたように、インテントはユーザーによって発行され、ソルバーによって解決されます。インテントが表現される形式に関係なく、インテントはソルバーにとっての最適化問題です。平たく言えば、ユーザーが「4 ETH 相当の BTC を購入したい」などの意図を提示すると、ソルバーは通常、この注文を約定または交換する場所を見つけます。しかし、その意図はそこにとどまらず、「可能な限り低いスリッページ」や「米国ユーザーの取引を禁止する DEX で取引しない」などの制約を追加することも可能であり、これらはソルバーが守らなければならない追加の制約になります。心。

課題には次のようなものがあります。

課題には次のようなものがあります。

目標は、ユーザーの意図の好みを明確に把握することと、計算効率とユーザー エクスペリエンスに関する実際的な考慮事項のバランスを取ることです。

インテント検索のラグランジュ解釈もここで言及されています。

私にとって、意向表明はマルコフの意思決定プロセスのように見えます。ただし、マルコフ決定プロセスの状態遷移は確率的であるのに対し、これは絶対的な状態遷移値を持つ決定論的な MDP であり、値の反復、ポリシーの反復、または MCTS (モンテカルロ ツリー検索) を使用して解決できます (最後の部分も使用されます) Alphago の Go 部分を解決します)。

インテントはユーザーエクスペリエンスを促進することができます

インテントは、オンチェーン ユーザー エクスペリエンスの進化における次の段階となる可能性があります。現在のチェーン上のユーザー エクスペリエンス方法は主にトランザクション レベルに焦点を当てており、ユーザーは各トランザクションに署名しますが、これも操作の一部です。したがって、チェーンの各ステップはトランザクションを通じて表現されます。非常に簡単に言うと、インテントはメタトランザクションであり、アクティビティは非常に抽象的なレベルで表現され、ユーザーのインテントのニーズを満たすかどうかはソルバー次第です。これには、数セントの価格で ETH を購入し、その後 ETH を購入することが含まれる可能性があります (手数料も計算する必要があります)。

USDC から ETH への単純なスワップ トランザクションには、現在、ユーザーがトークンの制限を承認し、トークン タイプを承認してからトランザクションを承認する必要がありますが、インテント中心の世界では、ユーザーはこれらの詳細を抽象化し、単純に何でも実行できます。あなたはすることに興味があります。 Web デザインには、3 回以上のクリックではアクションを実行できないという非公式のルールがあります。現在、ユーザーがスワップを取引したい場合は、コインも選択し、おそらくスリッページと取引を調整する必要がありますが、これは 1 回の取引の場合です。ワークロードは最初は大きくないように見えますが、何度も繰り返すと、ユーザー エクスペリエンスが非常に煩雑になります。

非常に基本的な方法で、Unibot を使用すると、アーキテクチャが意図として提示するパターンを人々が見ることができます。これは取引の複雑な部分を取り除き、トレーダーにシンプルで使いやすいユーザーエクスペリエンスを提供しますが、可能な柔軟性にはいくつかの制限もあります。このアプリには、攻撃につながる可能性のある主要な処理リスクがあるとされていますが、税金が課されているにもかかわらず、安定したユーザーベースがあり、暗号通貨の世界でのユーザーエクスペリエンスに未開発の機会があることを示しています。

会話の意図の流れ

インテント中心のブロックチェーンの世界では、人工知能はどのように介入するのでしょうか?意図認識の概念は、自然言語処理の分野で何十年も前から存在しており、会話において盛んに研究されてきました。たとえば、ユーザーが旅行 Web サイトにアクセスしてチャットボットと会話するとします。最初はフライトを予約したり、予約やステータスを確認したりするため、その後ユーザーはさまざまな詳細を入力します。フライトを予約する場合、ユーザーは目的地、時刻、日付、および興味のある航空券クラスを指定する必要があります。場合によっては、空港を選択する必要がある場合もあります。この例では、ユーザーの目的は会話の意図であり、ユーザーが指定するさまざまな詳細は、この意図を達成するために埋める必要があるスペース/詳細 (スロット) です。

会話内の注釈付き会話ステータス

意図認識と詳細の埋め込みのもう 1 つの例は、曲を再生するつもりで、曲名や曲の歌手など、その曲に関連するさまざまなスペース (詳細) が文中に現れる場合です。

会話の世界では、会話が複数のターンにまたがることがあり、グローバルな意図とローカルな意図が存在し、多数の状態を追跡する必要があるため、意図の分類と空白の埋め込みは非常に複雑な問題です。 Siri や Google アシスタントを使用してアラームをスケジュールしたり、カレンダーや誕生日に何かを記録したりするたびに、その背後にはある程度の意図の分類とスペースの埋め込みが行われます。

会話の世界では、会話が複数のターンにまたがることがあり、グローバルな意図とローカルな意図が存在し、多数の状態を追跡する必要があるため、意図の分類と空白の埋め込みは非常に複雑な問題です。 Siri や Google アシスタントを使用してアラームをスケジュールしたり、カレンダーや誕生日に何かを記録したりするたびに、その背後にはある程度の意図の分類とスペースの埋め込みが行われます。

これはブロックチェーンとどのように関係するのでしょうか?私たちはトランザクション中心の世界から意図中心の世界に移行していますが、意図からトランザクションに至るまでの詳細はまだ一般的な議論にはなっていません。インテント プールとメモリ プール間のインターフェイスは存在しません。オンチェーン モデルにアクセスし、それをインテント認識と空白の埋め込みに使用すると、インテント プールとソルバーに自然言語インターフェイス (私の意見では最も自然なインターフェイス) が提供されます。

一般的なアイデアは、チェーン上の一連のモデルにアクセスし、各意図を DSL (ドメイン固有言語) に還元することです。このドメイン固有言語には、中心となる意図 (購入、販売、ブリッジ、借用/ローン) などの詳細が含まれます。 、アドレス、サイズ、スリッページ設定などのその他の詳細が含まれます（インテントのタイプに応じて）。グローバル DSL を使用すると、誰でもモデルをデプロイできるようになり、特定の DSL への意図が簡素化されます。このようなモデルが複数ある場合、投票されたモデルがモデルのコレクションに取り込まれます。

オンチェーン モデルの利用可能性は、このインターフェイスを安全かつ証明可能に開発するのに役立ち、あらゆる意図/ソリューションの計算による証明が可能になります。場合によっては、さまざまなモデルにわたる多数決の結果を取得することで、インテントがどのように選択されるかについての洞察が得られる場合があり、個々のケースでは、ソルバーがそれらのインテントをより適切に解決するのに役立つこともあります。

ここで使用されるオンチェーン モデルは、この目的のために正確にトレーニングされた BERT などの標準的な深層学習モデル、またはアンサンブル内の大規模な言語モデル推論である可能性があり、この詳細はさまざまなアクターまたはソルバーに依存する可能性があります。暗号化されたインテント プールの場合、準同型暗号化またはプライベート推論方法を使用して、データの計算を可能にしながらデータのプライバシーを確​​保する必要があります。エポックごと、または数エポックごとに、モデルがバリデーターであるチェーン上でプルーフを発行できます。バリデーターは、モデルの有効性に関するステートメントを発行する人間または別のモデルにすることができます。モデルが意図を正確に処理するかどうかに関係なく、プロセスのこの最後の部分では、モデルのライフサイクルが確実に考慮されます。場合によっては、バリデーターが成熟した参加者である場合、その参加者がモデル内の欠陥を発見し、迅速に対処して更新されたモデルに置き換えることができます。

以下の図に示すように、「ウォレットにあるステーブルコインとダストで購入する」というアクション/アイデアの場合、インテント プールに入ると、さまざまなモデルを通過して DSL に解析されます。DSL には、次のようなさまざまな詳細が含まれます。インテント、サブアクション、および入力する必要がある詳細。 DSL の解析は、可能な限り詳細に行うことも、抽象化することもできます。ダストしきい値を決定する必要があるため、インテントの会話は数ラウンド続く場合があります。 DSL が設定されると、ソルバーはこれらの残高を ETH に変換し、トランザクションをメモリプールに渡すための最適なパスを選択できます。

意図解決モデルの例

もう 1 つの DSL アーキテクチャ - 必須

アカウントの抽象化により、すべてのアカウントがスマート コントラクトに変わり、イーサリアムの署名者からアカウントが切り離されます。これにより、アカウントはユーザーのニーズに基づいてさまざまな認証ロジックをカスタマイズできます。ただし、アカウントの完全な抽象化を実現するには、イーサリアムのコア プロトコルを大幅に調整する必要があります。

EIP 4337 は、コンセンサス層を変更せずにアカウント抽象化の利点を実現するために、異なるアプローチを採用しています。これは、バックアップ メモリ プールに送信され、EntryPoint スマート コントラクトを呼び出すトランザクションに「バンドラー」によってバンドルされる疑似トランザクションである「ユーザー オペレーション」を導入します。

これにより、ソーシャル リカバリ、任意のトークンでの料金の支払い、バッチ処理されたトランザクションなどの機能が可能になります。開発者は、さまざまなユースケースに合わせてカスタム アカウントを設定できます。 EIP 4337 は、プロトコルの変更を回避することで、これらの利点をイーサリアムに迅速にもたらすことができます。ただし、新たな複雑性や、バンドラーや支払者などの主体も導入されます。その結果、複数のメモリ プール、インセンティブ、透明性の間のダイナミクスを注意深く管理する必要があります。

インテントを使用すると、ユーザーは特定のアクションではなく、望ましい結果を指定できます。ソルバーは、ユーザーが可能な限り最良の方法でこの結果を達成できるように支援します。ただし、現在の実装には限界があり、集中化、構成可能性の欠如、およびソルバー間の競争が不十分です。

インテントを使用すると、ユーザーは特定のアクションではなく、望ましい結果を指定できます。ソルバーは、ユーザーが可能な限り最良の方法でこの結果を達成できるように支援します。ただし、現在の実装には限界があり、集中化、構成可能性の欠如、およびソルバー間の競争が不十分です。

Essential が提案する EIP はそれを変えるでしょう。 EIP 4337 などの取り組みによるアカウントの抽象化により、従来の外部所有アカウント (EOA) の代わりにスマート コントラクト ベースのアカウントを有効にすることができます。これにより、ユーザーは単純なトランザクションを送信せずに、一般的なインテントを送信できるようになります。インテントはユーザーが望む結果を表し、参加者の満足度を最大化するためにソルバーによって補完できます。

EIP 7521 は、スマート コントラクト ウォレットを継続的にアップグレードすることなく、進化するインテント標準をサポートするフレームワークを提案しています。ユーザーは「ユーザー インテント」に署名し、そのインテントを処理する必要がある「インテント標準」コントラクトを指定します。これらのインテントは、EIP 4337 と同様に署名検証を処理する EntryPoint コントラクトに送信されます。ユーザー インテント メモリ プールは ERC 4337 メモリ プールと同時に存在し、ソルバーがインテントを処理します。

ERC-4337 アカウント抽象化におけるユーザーの意図

アノマ

Anoma はインテント中心のアーキテクチャであり、その中核でトランザクションではなくプログラミング インテントを使用してインフラストラクチャ層を構築します。インテントは、完全な状態変更トランザクションではなく、プリファレンスを表現するユーザーによって署名された部分的な状態変更です。この意図中心の設計により、分散型の取引相手の発見と解決が可能になります。 Anoma は命令型パラダイムから命令型パラダイムに移行しようとしています。

インテント中心のアプリケーションに関する Adrian Brink の講演からの抜粋

ユーザーは意図をブロードキャストし、その意図は意図ゴシップ ネットワーク内で伝播されます。さまざまなノードは、独自のコンピューティング リソースとサービスを提供したいインテントの種類に基づいて、特定のインテントの伝播に特化できます。ソルバーはインテントを観察し、互換性のあるインテントをオンチェーンで決済できる有効なトランザクションに結合しようとします。トランザクションは、しきい値暗号化を使用して暗号化されたメモリプールに送信されるため、フロントランニングは不可能です。 Anoma には、インテントの合成を可能にする部分的なインテント モデルもあります。

Chris が Intent x Rollup - Anoma Partial Intent Model について講演します

Anoma がプライバシーに重点を置くのは、ユーザーが意図する情報を柔軟に開示したり、何を開示するかを選択できる「ユーザーレベルの選択」にあります。

アーキテクチャは複数のコンポーネントで構成されます。 Tiger 実行エンジンは、ZKP と準同型暗号化テクノロジを使用して、透明で保護されたプライベート データを処理します。 Typhon はコンセンサス アルゴリズムです。コンパイラ スタックには、Juvix 言語、AnomaVM、および VampIR が含まれています。

このアーキテクチャには、同種のプロトコルと異種のセキュリティ モデルがあります。スタンドアロンのブロックチェーンとして、またはイーサリアム上でアプリケーションを分散分散するための ZK ロールアップまたは分散オーダーブックとして展開できます。異なるセキュリティ ニーズを持つユーザーは、ニーズに基づいてセキュリティのトレードオフを行いながら、同じプロトコルを利用できます。

Anoma を使用すると、トランザクション中心のモデルと比較して、分散型アプリケーションの構築が容易になります。これは、ロールアップ、マルチバーター トランザクション、プライベート DAO などの新しいアプリケーションの実行をサポートすることを目的としています。要約すると、Anoma は、現代の分散型アプリケーションの要件を満たす柔軟なモジュラー アーキテクチャを提供します。トランザクションではなく意図に焦点を当て、プライバシーを保護しながら取引相手の発見と調整の問題を解決します。

Anoma には、意図を「情報フロー」および「制限された/プライベートな情報フロー」として扱い、それに応じてアーキテクチャとデザインの選択を行うという独自の設計哲学があります。これは、Anoma の意図構成モデルが一般化された意図モデルにつながるという事実も示しています。これは、効率性のトレードオフによって秘密にできる情報の量が制限されるため、プライバシーの制約の下では解決するのが技術的に難しい可能性があります。

まとめ

研究およびエンジニアリングの問題としての意図は、現在、暗号化において非常に興味深い分野です。

インテント ドメインで対処する必要がある未解決の質問:

一般的な意図は大きすぎて解決できない場合があり、イーサリアムほど大きな状態空間では、これは手に負えない問題になります。これは、意図の問題を解決するにはいくつかの制約を設けて行うのが最善であり、意図を結合する試みも (共通の意図がある場合には) 制約されるべきであることを示唆しています。私の意見では、ユニバーサル インテントを実際に実装するのは非常に難しく、インテント中心のアーキテクチャは本質的にアプリケーション固有のものになります。

これらは研究上の課題ですが、目的を達成するための設計の選択により、さまざまなエンジニアリング上の問題も生じます。これは（許可された）仲介者への過度の依存につながる可能性があり、異なるスタックにインフラストラクチャが集中する危険があります（UniswapXの場合、取引高の77％はオフチェーンの在庫充填です）。また、信頼できる仲介業者の地位を固定化し、参加への障壁を高め、イノベーションを抑制することになります。これはすでに MEV に反映されています。インテント プロトコルの設計では、パーミッションレス、プライバシー、透明性、分散化の間でバランスを取る必要があります。