Intent-Execution Separation

What is intent-execution separation, and how does it differ from the simulation-execution gap discussed earlier in this series?

The simulation-execution gap discussed earlier in this series addresses a deviation that can arise between simulation and actual execution for an already-decided-on specific operation — this problem's premise is that the specific operational steps to execute have already been determined. Intent-execution separation addresses a more upstream architectural question: what a user originally expresses — is it an abstract goal ("I want to swap asset A for asset B at the lowest cost," say), or a series of specific operational steps ("execute the swap on this specific exchange via this specific route," say)?

This means the simulation-execution gap happens after specific operational steps have already been determined, while intent-execution separation is an architectural question about who determines the specific operational steps themselves, and when they get determined — if an intent-layer architecture is adopted, the specific steps often only get determined in real time by the system after the user declares their goal, which also means the simulation-execution gap risk shows up at a different point in time and in a different form.

Why does a direction like intent-execution separation exist, and what problem does it solve?

A traditional architecture requiring a user to specify the specific operational steps themselves puts the responsibility of finding the best execution path onto the user (or the user's agent) — if the market has multiple possible execution paths, the user has to compare them themselves or through a tool to find the one with the lowest cost and lowest risk, a process that's itself both time-consuming and requires the user to have a certain judgment capability.

An intent-execution separation architecture shifts this burden away — the user just needs to declare the result they want, leaving which path to take to achieve it to the system itself (or the multiple execution parties the system connects to behind the scenes, decided through some bidding or optimization mechanism). This design's motivation is letting a user obtain a near-optimal execution result without needing professional path-selection capability — fundamentally shifting the work of finding the optimal solution from the user onto the system design.

意図層と実行層の分離のアーキテクチャは実際どのように機能し、このアーキテクチャはどんな新しいリスクをもたらしますか？

典型的な動作方法は次の通りである：ユーザーが意図の宣言を送信し（「特定のスリッページを超えない条件で資産Aを資産Bに交換したい」など）、この意図はブロードキャストされ、複数の独立した実行当事者（時に「ソルバー」と呼ばれる）が互いに競争し、誰が最良の実行結果を提供できるかを競う。ユーザーの意図は最終的にシステムによって勝ち残った実行当事者の一人にマッチングされ、この実行当事者が具体的な取引ステップを完了する責任を負う。

このアーキテクチャがもたらす新しいリスクは、ユーザーが元々直接コントロールできた具体的な実行の詳細が、今やシステムによってマッチングされたサードパーティの実行当事者の責任になることである。このマッチングメカニズムの設計が不十分である場合、あるいは競争に参加している実行当事者同士が実際には秘密裏に結託している場合（本当に独立して競争しているのではなく）、ユーザーが宣言した意図が自分に不利な方法で実行される可能性があるが、具体的な実行プロセスが見えないため、タイムリーに気づくのが難しい。これはまた、本シリーズで前述したソルバーの結託リスクが、この種のアーキテクチャの下で特に現れやすい理由でもある。

意図層と実行層の分離は一般ユーザーにどのような実際の影響を与えますか？DeFAI製品の評価にどう応用すればいいですか？

意図層アーキテクチャを採用しているDeFAI製品を使っている場合、それは最良の実行経路を自分で判断する必要がないという利便性を享受していることを意味するが、同時に「実行プロセスが本当に公平で最適か」という判断の責任を、背後にあるシステムのマッチングメカニズムに委ねていることも意味する——これは、この種の製品を評価する際、重点はもはや自分自身が経路の優劣を判断する能力を持っているかではなく、このシステムのマッチングメカニズム自体に十分な透明性と競争メカニズムがあり、マッチング結果が本当にあなたに有利であることを確保しているか、少数の実行当事者に独占操作されていないかを検証することにあることを意味する。

実際に応用する際は、この種の製品のチームに直接尋ねる価値がある：競争に参加する実行当事者の数はおおよそどれくらいか、これらの実行当事者は互いに本当に独立しているか、システムは事後に検証可能な実行結果を提供しており、自分が本当にその時点での最適（または最適に近い）結果を得たことを確認でき、システムに密かに利益を犠牲にされていないことを確認できるか。