Title: An Incomplete Primer on Intents

Author: 0xemperor.eth

Translation: Qianwen, ChainCatcher

Recently, in the research and discussion in the field of cryptography, the concept of intent has become popular, and various protocols are utilizing this concept. For example, protocols such as Anoma and Essential are drawing on this concept.

This article aims to provide a preliminary introduction to various viewpoints, and finally introduces the presentation form of intent resolution architecture when expressing intent 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 the need to provide precise 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 result. 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, establishing an account/signing a transaction, processing transfers (or cleaning up cryptocurrency dust in your wallet), etc. You just need to submit an intent statement, indicating that you want to exchange 1 ETH for 2000 USDT. Another entity (called 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 result for you.

The key point 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 cryptocurrencies.

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 computing path or a simple trading path). Users can also indicate their preference for certain paths or contracts, thereby restricting them.

Use Cases

Cowswap

Cowswap uses batch auctions as its core price discovery mechanism. Cowswap does not execute transactions immediately like AMM, but aggregates orders off-chain and settles them in batches. This allows for a unified settlement price for all transactions in a batch, eliminating common issues such as front-running in immediate execution mode. Batch auctions can also settle many transactions at the same time, 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 a direct point-to-point settlement between 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. By maximizing the use of CoW, batch auctions can obtain more liquidity than isolated liquidity pools. Settlement will use 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 computing path or the specific location 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 to incentivize honest pricing, after which 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. This 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 point-to-point trades, while Uniswap X focuses more on integrating off-chain and on-chain sources of liquidity.
• The RFQ (Request for Quote) system and signing mode in Uniswap X (where users express intent and let other users fill orders) 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 realized, 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 supported "start" state set.
• E represents the supported "end" state set.
• 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 realized.

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 mentioned earlier, intents are issued by users and then resolved by Solvers; regardless of how they are represented, intents are an optimization problem for Solvers. In simple terms, a user might propose an intent like "I want to purchase BTC worth 4 ETH," and the Solver would typically find a place to fill or swap this order. But intents go beyond this; they also allow for additional constraints that Solvers must remember, such as "as low slippage as possible" and "not trading on DEXs that prohibit US users."

Challenges include:

• The need to simplify intent expression.
• Specific intents may impact user welfare, such as zero slippage in DEXs.
• Execution tracking may need attention due to risks or legal reasons.

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

Lagrangian interpretation of intent search is also mentioned here.

Session-Based Intent Flow

In a blockchain world centered around intent, how can artificial intelligence be involved? The concept of intent recognition has existed in the field of natural language processing for decades 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 provides 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 recognition and slot filling is another example when you intend to play a song, and the sentence contains various slots related to the song, such as the song title and the artist.

In the world of conversations, intent classification and slot filling is a very complex problem because your conversation may span multiple rounds, 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 your 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 move 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 translate each intent into a domain-specific language (DSL); this domain-specific language will include core intents (buy, sell, bridge, borrow/lend), as well as other details such as addresses, amounts, slippage preferences, etc. (depending on the intent type). The global DSL allows anyone to deploy models to simplify intents into specific DSLs. In the presence of multiple such models, the model elected in the model collection will be used.

The availability of on-chain models helps us develop this interface securely and verifiably, with a computational proof for each intent/solution. Capturing the results of the majority vote of various models in some cases may help us understand 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, such as BERT, 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 use homomorphic encryption or private inference methods to ensure data privacy while still being able to compute on it. A proof can be published on-chain by the model as a validator every epoch or every few epochs. The validator can be a human or another model, making a statement about the validity of the model. Whether the model can accurately handle intents or not, this part of the process ensures that the model's lifecycle is considered. 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 figure below, for the action/idea of "purchasing 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 the intent, 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 rounds, as the threshold for dust may need to be determined. Once the DSL is in place, the Solver can choose the best path to convert these balances into ETH and then pass the transaction to the memory pool.

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 tailored to user needs. However, achieving full account abstraction requires significant adjustments to the core Ethereum protocol.

EIP 4337 takes a different approach to achieve the benefits of account abstraction 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, payment of fees in any token, and batch transactions, among other features. Developers can set up custom accounts to suit different use cases. By avoiding protocol changes, EIP 4337 can bring these benefits to Ethereum more quickly. However, it also introduces new complexities and actors, such as bundlers and payers. The dynamic changes between multiple memory pools, incentive mechanisms, and transparency will require careful management.

Intent allows users to specify an expected result rather than a specific operation. Then, Solvers help users achieve this result in the best way. However, the current implementation has limitations, showing centralization, lack of composability, and insufficient competition between Solvers.

The EIP proposed by Essential aims to change this situation. Through measures such as EIP 4337, account abstraction can be achieved, allowing for contract-based accounts instead of traditional Externally Owned Accounts (EOA). This allows users to submit general intents without the need to submit simple transactions. Intents represent the expected results of users and can be supplemented by Solvers to maximize participant satisfaction.

EIP 7521 introduces a framework to support evolving intent standards without the need for continuous 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 the intents.

Anoma

Anoma is an intent-centric architecture that builds the infrastructure layer based on programming intent rather than transactions. Intent is a part of the state change that expresses user preferences, rather than a complete state change transaction. This intent-centric design achieves decentralized discovery and resolution of trading counterparties. Anoma is attempting to transition from a declarative paradigm to an imperative paradigm.

Excerpt from Adrian Brink's speech on intent-centric applications

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 for intent composition.

Chris on Intent x Rollup - Anoma Partial Intent Model speech

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 technology 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 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 utilize 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 intent rather than transactions, addressing the issues of discovering and coordinating trading counterparties while protecting privacy.

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

Conclusion

Intent, as a research and engineering problem, is currently a very interesting area in cryptography.

Open problems in the intent domain:

• Formal definition of intent
• What does an intent-centric application architecture look like apart from DEX?
• 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.
• What is the most basic knowledge required to solve intent problems?
• If avenues for obtaining other knowledge are to be cut off, what trade-offs do you have to make?
• How to express the trade-offs 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 can become an intractable problem. This indicates that it is best to have some constraints when solving intent problems, and there should also be limitations when attempting to combine intents (when common intents exist). In my view, a generalized intent is extremely difficult to achieve in practice, and an intent-centric architecture is fundamentally application-specific.

While these are research problems, the design choices for implementing intent also raise various engineering issues. It may lead to over-reliance on (licensed) intermediaries, potentially leading 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，本平台相关工作人员将会进行核查。