Original Title: An Incomplete Primer on Intents
Original Author: 0xemperor.eth
Translation: Qianwen, ChainCatcher

In recent research discussions in the crypto field, the concept of intents has become popular, and various protocols are utilizing this concept, such as Anoma and Essential.

This article aims to provide a preliminary introduction to various viewpoints and ultimately present the form of intent resolution architecture when expressing intents in natural language. If the concept of intent can succeed, it is expected to completely change application architecture at various levels.

What is Intent?

Intent allows users to specify certain transaction conditions or preferences without needing to provide exact message calls, thereby increasing flexibility and reducing on-chain complexity.

In the article "Intent-Based Architecture and Its Risks", the definition of intent is: Intent is a set of declarative constraints that allow users to outsource transaction creation to third parties without relinquishing complete control over the transaction parties.

In a podcast, Chris Goes from Anoma defined it from two aspects: Intent refers to "trusted commitments to certain system state preferences" and "trusted commitments to information flow restrictions."

One intuitive way to understand intent is that it basically represents the expected outcome. When you express an intent, you are simply defining the result you want, rather than the process of achieving the goal.

For example, if you want to exchange Tether (USDT) for ETH, you don't need to manage the entire process yourself—selecting an exchange, setting up an account/signing the transaction, handling transfers (or cleaning up cryptocurrency dust in your wallet), etc. You just need to submit an intent stating that you want to exchange 1 ETH for 2000 USDT. Another entity (referred to as a Solver) will accept your intent and find a way to implement it. The Solver will handle the messy details and strive to optimize the best outcome for you.

The key is that intent focuses on the result rather than the process. Users define the desired result, and others implement it through the process. Intent allows you to specify the result without worrying about the steps, greatly simplifying the transaction process used by most users in cryptocurrency.

A higher-level idea is that users can define what they want without specifying from which contracts they want to start trading (we can call it a computation path or a simple trading path). Users can also indicate their preference for certain paths or contracts, thereby imposing restrictions on them.

Use Cases

Cowswap

Cowswap utilizes batch auctions as its core price discovery mechanism. Cowswap does not execute transactions immediately like AMMs, but instead aggregates orders off-chain and settles them in batches. This allows a unified settlement price to be determined for all transactions in a batch, eliminating common issues such as front-running in immediate execution mode. Batch auctions also enable the simultaneous settlement of many transactions, optimizing gas fees. Solvers openly compete with each other to submit order settlement solutions, ensuring that the parties to each batch of transactions can maximize their benefits. The best solution will determine the final unified price. Overall, batch auctions achieve fairness, efficiency, and MEV protection, which immediate execution mode cannot achieve.

A key innovation of Cowswap's batch auction model is the ability to find coincidences of wants (CoW) between orders. CoW is the direct peer-to-peer settlement of trades with reciprocal demands. This liquidity sharing means that there is no need for external liquidity providers to facilitate these trades. CoW can also include multiple assets in circular trades simultaneously. By maximizing the use of CoW, batch auctions can obtain more liquidity than isolated liquidity pools. Settlement will utilize CoW where possible, and the remaining portion will be executed through on-chain liquidity. Combining batch auctions with CoW liquidity sharing can provide traders with better pricing and execution.

The CoWswap model is similar to the intent model, where users express their trading intent in the form of limit orders, which are input into the order book. Solvers use the order book state to match them in the form of circular trades or route them through AMM (where users only mention the price, not the computation path or specific locations they want to execute).

Uniswap X

The Uniswap X paper proposes a decentralized trading protocol that uses signed off-chain orders and settles them through Dutch auctions on-chain. Users sign orders, specifying input/output tokens, quantities, and price limits, among other parameters. These orders are distributed to "Fillers," who compete for the best execution price.

Uniswap X suggests setting the initial Dutch auction price through an off-chain inquiry system. Users can inquire with the Filler network and provide a brief exclusive period for the best quote, incentivizing honest pricing, before the orders enter a public Dutch auction.

Similarities between Uniswap X and Cowswap

• Both use off-chain signed orders and settle them in batches on-chain, which can save gas fees compared to on-chain orders.
• Both aim to promote competition among liquidity providers to find the best execution price (liquidity providers are called Solvers in Cowswap and Fillers in Uniswap X).
• Cowswap emphasizes using CoW to drive direct peer-to-peer trades, while Uniswap X focuses more on integrating off-chain and on-chain liquidity sources.
• The RFQ (Request for Quote) system and signing mode (users expressing intent and then having other users fill orders) in Uniswap X are similar to the intent architecture.

Formal Definition of Intent

Users only need to express their intent, such as "I want to exchange X asset for Y asset," and the Solver will find the best way to implement that intent and handle all blockchain-related details behind the scenes. The Solver provides proof of the intent being implemented, which can participate in auction mechanisms, achieving intent in a decentralized manner.

This blog discusses some definitions:
The first model: Intent i is defined as a tuple (B, E, T):

• B represents the set of supported "start" states.
• E represents the set of supported "end" states.
• T is a set of preferred transaction sequences.
• The state transition function s: Q×T→ T moves from the initial state to the end state through a series of transactions t.

If an intent starts with a transaction sequence t∈T at state q0∈B and ends at state qn∈E, the intent is considered achieved.

Intent Clearance: If the sets B, E, and T have non-empty intersections, a set of intents to, …, tm can be cleared, allowing the creation of a meta-intent t' using these intersections.

As we mentioned earlier, intents are issued by users and then resolved by Solvers; regardless of how they are expressed, intents are an optimization problem for Solvers. In simple terms, a user might express an intent like "I want to purchase BTC worth 4 ETH," and a Solver would typically find a place to fill or execute this order. But intents go beyond this; they also allow for additional constraints such as "minimize slippage as much as possible" and "do not trade on DEXs that prohibit US users," which become additional constraints that Solvers must keep in mind.

Challenges include:

• Need for simplifying intent expression.
• Specific intents may impact user welfare, such as zero slippage in DEX.
• Execution tracking may need to be mindful of risks or legal considerations.

The goal is to strike a balance between capturing user intent preferences clearly and the practical considerations of computational efficiency and user experience.

Here also mentions a Lagrangian interpretation of intent search.

For me, the expression of intent looks like a Markov decision process. However, the state transitions in a Markov decision process are random, whereas this would be a deterministic MDP with absolute state transition values, which can be solved using value iteration, policy iteration, or MCTS (Monte Carlo Tree Search) (the latter also used to solve the Go part in Alphago).

Intents Can Enhance User Experience

Intents may be the next stage in the development of on-chain user experience. Currently, on-chain user experience is primarily transaction-centric, with users signing on every transaction, which is also part of the operation. Therefore, every step on-chain is expressed through transactions. In very simple terms, intents are meta-transactions where activities are expressed at a very abstract level, and Solvers strive to fulfill the user's intent. This could include buying some ETH at the price of X, wanting to get the best possible trade, which could be done in a single large swap trade on Uniswap on Ethereum, or split on a roll-up and then buy ETH (also considering fees).

Currently, a simple swap trade from USDC to ETH involves the user approving token allowances, approving token types, and then approving the transaction, whereas in an intent-centric world, users can abstract away from these details and simply execute the operation of interest. In web design, there's an unofficial rule that any action should not take more than three clicks; currently, if a user wants to make a swap trade, they have to select tokens simultaneously, perhaps adjust slippage and trade, which may not seem like much work for a single trade, but it becomes a tedious user experience after multiple repetitions.

Unibot presents a pattern of intent-centric architecture in a very basic way. It removes the complex parts of transactions and provides a simple and user-friendly experience for traders, but it also imposes some limitations on potential flexibility. Although the app is claimed to have risks in key handling, potentially leading to attacks, it still has a stable user base with fee collection, indicating opportunities for improvement in user experience in the cryptocurrency world.

Conversational Intent Flow

In an intent-centric blockchain world, how can artificial intelligence be involved? The concept of intent recognition has been around for decades in natural language processing and has been extensively researched in conversations. For example, suppose a user visits a travel website and interacts with a chatbot; initially, they may want to book a flight or check a reservation or status, and then the user would provide various detailed information. If it's about booking a flight, the user needs to provide the destination, time, date, and the class of interest, and in some cases, the user may also need to select an airport. In this example, the user's purpose is the intent of the conversation, and the various details provided by the user are the slots to be filled to achieve this intent.

Intent classification and slot filling in conversations is a very complex problem because your conversation may span multiple turns, sometimes with global intents and local intents, and you have to track numerous states. Every time you use Siri and Google Assistant to set an alarm or record something in a calendar or birthday, there is some level of intent classification and slot filling behind it.

How does this relate to blockchain? As we transition from a transaction-centric world to an intent-centric world, the discussion of how to go from intent to transaction details has not yet appeared in public discussions. The interface between the intent pool and the memory pool does not exist. Accessing on-chain models and using them for intent recognition and slot filling provides a natural language interface (in my view, the most natural interface) for the intent pool and Solvers.

The general idea is to access a set of models on-chain and reduce each intent to a domain-specific language (DSL); this DSL will include core intents (buy, sell, bridge, lend/borrow) and details such as addresses, amounts, slippage preferences, and other details (depending on the intent type). The global DSL allows anyone to deploy models to simplify intents into specific DSLs. In the case of multiple such models, the model with the most votes will be selected from the model set.

The availability of on-chain models helps us develop this interface securely and verifiably, with computational proofs for each intent/solution. In some cases, capturing the results of the majority of models may provide insights into how intents are selected, and in some individual cases, it may even help Solvers better solve these intents.

The on-chain models used here can be a standard deep learning model like BERT, which is trained for this purpose, or large language model inference in the collection; this detail may depend on different participants or Solvers. In the case of encrypted intent pools, we need to ensure data privacy using homomorphic encryption or private inference methods while still being able to compute on it. A proof can be published on-chain by the model for validators every epoch or every few epochs. Validators can be humans or another model, publishing statements about the validity of the model. Whether the model can accurately handle intents, this part of the process ensures the consideration of the model's lifecycle. Sometimes, when the validator is a mature participant, they may find flaws in the model, which can be quickly addressed and replaced with an updated model.

As shown in the diagram below, for the action/idea of "buying with stablecoins and dust in my wallet," once it enters the intent pool, it will be parsed through various models into a DSL containing various details such as intents, sub-actions, and details to be filled. The parsing of the DSL can be as detailed as possible or as abstract as possible; the intent conversation may last several turns, as the threshold for dust may need to be determined. Once the DSL is in place, Solvers can choose the best path to convert these balances into ETH and then pass the transaction to the memory pool.

Example of an Intent Resolution Model

Another DSL Architecture - Essential

Account abstraction turns all accounts into smart contracts, separating accounts from signers in Ethereum. This allows accounts to have different authorization logic customized to user needs. However, achieving full account abstraction requires significant changes to the core protocol of Ethereum.

EIP 4337 takes a different approach to achieve account abstraction benefits without changing the consensus layer. It introduces "user operations" - pseudo-transactions submitted to an alternate memory pool and bundled by "bundlers" into transactions calling the EntryPoint smart contract.

This enables social recovery, fee payment in any token, and batch transactions. Developers can set up custom accounts to suit different use cases. By avoiding protocol changes, EIP 4337 can bring these benefits to Ethereum faster. However, it also introduces new complexities and actors, such as bundlers and payers. The resulting dynamic changes between multiple memory pools, incentive mechanisms, and transparency will require careful management.

Intents allow users to specify an expected outcome rather than a specific operation. Then, Solvers help users achieve this outcome in the best way possible. However, the current implementation has limitations, showing centralization, lack of composability, and insufficient competition among Solvers.

An EIP proposal by Essential aims to change this. By achieving account abstraction through measures like EIP 4337, it can enable account-based on smart contracts rather than traditional Externally Owned Accounts (EOA). This allows users to submit general intents without the need for simple transactions. Intents represent the desired outcome for users, which can be supplemented by Solvers to maximize participant satisfaction.

EIP 7521 proposes a framework to support evolving intent standards without the need for constant upgrades to smart contract wallets. Users sign "user intents," specifying which "intent standard" contract should handle the intent. These intents are submitted to the EntryPoint contract, which handles signature verification similar to EIP 4337. The user intent memory pool coexists with the ERC 4337 memory pool, and Solvers handle intents.

User Intent under ERC-4337 Account Abstraction

Anoma

Anoma is an intent-centric architecture that focuses on building the infrastructure layer based on programming intent rather than transactions. Intents are part of the state changes signed by users expressing preferences, rather than complete state-changing transactions. This intent-centric design achieves decentralized transaction counterpart discovery and resolution. Anoma is attempting to shift from a declarative to an imperative paradigm.

Users broadcast intents, and intents propagate in the intent gossip network. Different nodes can specialize in propagating certain intents based on their computational resources and the types of intents they want to serve. Solvers observe intents and attempt to combine compatible intents into valid transactions that can be settled on-chain. Transactions are submitted to the encrypted memory pool using threshold encryption, preventing frontrunning. Anoma also has a partial intent model, allowing intent combinations.

Extract from Adrian Brink's talk on intent-centric applications

Anoma's privacy focus is on "user-level choice," allowing users to flexibly disclose their intent information and choose which parts to disclose.

The architecture consists of multiple components. The Tiger execution engine uses ZKP and homomorphic encryption to handle transparent, protected private data. Typhon is the consensus algorithm. The compiler stack includes the Juvix language, AnomaVM, and VampIR.

The architecture has a homogeneous protocol and a heterogeneous security model. It can be deployed as a standalone blockchain or used as a ZK roll-up or decentralized order book for decentralized distribution of applications on Ethereum. Users with different security requirements can use the same protocol while making security trade-offs according to their needs.

Compared to a transaction-centric model, Anoma makes it easier to build decentralized applications. Intents support new applications such as rollups, multi-asset trading, and private DAOs. In summary, Anoma provides a flexible modular architecture to meet the requirements of modern decentralized applications. It focuses on intents rather than transactions, addressing the issues of transaction counterpart discovery and coordination while protecting privacy.

Anoma has a unique design concept, considering intents as "information flows" and "restricted/privacy-preserving information flows," and has made architectural and design choices based on this. This also indicates a fact that Anoma's intent composition model brings about generalized intent models, which may be technically challenging under privacy constraints, as trade-offs in efficiency would limit the amount of information that can be kept confidential.

Conclusion

As a research and engineering problem, intent is currently a very interesting area in cryptography.

Open questions that the intent domain needs to address:

l Formal definition of intent

l What does an intent-centric application architecture look like apart from DEX?

l When solving any optimization problem, the design trade-offs between privacy and utility require as much information as possible. If privacy intents are to be achieved, a certain amount of information must be disclosed to solve the intent problem.

l What is the most basic knowledge required to solve intent problems?

l If you are to cut off avenues for obtaining other knowledge, what trade-offs are you making?

l How to express this trade-off between privacy and efficiency in a general way.

A generalized intent may be too large to solve, and for a large state space like Ethereum, this would evolve into a difficult problem to solve. This indicates that it is best to have some constraints on solving intent problems, and also to be restricted when attempting to combine intents (when there are common intents). In my view, a generalized intent is extremely difficult to achieve in practice, and an intent-centric architecture will be inherently application-specific.

While these are all research problems, the design choices for implementing intent can also lead to various engineering problems. It may lead to over-reliance on (permitted) intermediaries, which could lead to infrastructure centralization in different stacks (in the case of UniswapX, 77% of the trading volume is off-chain inventory filling). It also consolidates the position of trusted intermediaries, raises the barrier to entry, and stifles innovation, as seen in MEV. The design of any intent protocol must strike a balance between permissionless, privacy, transparency, and decentralization.

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。