Through intents, users can easily express their expected results, which contrasts sharply with the current imperative transaction.

Written by: Bastian Wetzel

Translated by: Deep Tide TechFlow

It has been proven that using various existing systems in Web3 is a complex and time-consuming task. It involves specifying execution paths between different infrastructures, which requires a comprehensive understanding. Therefore, users face continuous frustration in achieving their end goals and are susceptible to exploitation by more complex participants.

This situation arises because the mainstream standard method for interacting with Ethereum requires creating and signing transactions in a specific format that provides all the necessary information for the Ethereum Virtual Machine (EVM) to execute state transitions.

The introduction of Intents aims to alleviate the burden on users. Essentially, intents are a set of declarative constraints that allow users to delegate transaction creation to specialized third-party participant networks while retaining complete control over the process. In simple terms, if a transaction specifies "how" to perform an operation, intents define "what the expected result of that operation is."

This declarative approach brings exciting progress in user experience and efficiency. Through intents, users can easily express their expected results. This contrasts sharply with the current imperative transactions, where every parameter must be explicitly specified by the user.

Tx (Transaction) is a dead end for end users

The current Tx-based methods in Web3 have proven to be complex, leading to poor user experience and efficiency loss, as users are forced to make decisions without sufficient access to information or using complex execution strategies.

To illustrate this complexity, consider the following scenario: You want to interact with a decentralized application (dApp) on the Arbitrum network, but your funds are currently stored on the Ethereum blockchain:

Visit the dApp website
Attempt to connect your wallet to Arbitrum, but find no available funds
Open a new tab to explore the best way to transfer your funds across chains
Go to the cross-chain bridge
Connect your wallet to another blockchain (Ethereum)
Transfer funds from Ethereum to Arbitrum
Wait for the cross-chain transfer to complete
Return to the original tab
Switch your wallet back to Arbitrum
Now, you can finally use the bridged funds on Arbitrum to interact with the dApp.

Even before the user has the opportunity to interact with the dApp itself, they may already feel frustrated. These issues become even more apparent in a future world with millions of Rollups.

So, how do we transition from an imperative paradigm to a declarative paradigm? To understand the basic principles, let me first briefly summarize the concept of Account Abstraction (AA).

Brief review of Account Abstraction

In Ethereum, there are two types of addresses: smart contracts and externally owned accounts (EOA).

EOAs have the ability to initiate transactions, while smart contracts do not. Therefore, most Ethereum wallets used today are EOAs. Although there are smart contract wallets (SCWs), such as Safe, they require an EOA to trigger any transactions, as smart contracts themselves cannot initiate transactions. Nevertheless, SCWs have significant advantages as they can execute complex logic, providing various new applications for wallets, while EOAs are limited to signing.

To meet the demand for SCWs without the need for a separate EOA, ERC-4337 introduced a new type of transaction called User Operation (UserOp) and introduced a new role called "Bundlers." In addition, ERC-1271 (a standard signature verification method for contracts) introduced a standard method for verifying the signatures of a given contract. These updates improve the user experience of SCWs, providing a smoother process for users. The specific process is as follows:

The user signs a UserOp, specifying the required operation. The UserOp is not sent directly to the main memory pool, but multiple users send it to an alternate memory pool. Here, the executor and Bundlers come into play, bundling these UserOps together and submitting them as a bundle to the entry contract. Then, the entry contract communicates with the smart contract wallet.
Once the SCW receives the bundled UserOp, it undergoes a two-step process. First, it executes ValidateOp, which involves checking the appropriate signers, access control, and rate limits to ensure that the operation is legal and secure. Upon successful validation, the SCW proceeds to execute the operation using the ExecuteOp function. These operations may include transferring funds, executing exchanges, or purchasing NFTs, among other tasks.

A key advantage of Account Abstraction is Gas Abstraction, which simplifies the user's gas payment process. This is where the payer comes in. The payer contract acts as another entity. When a user sends a transaction, the UserOp is sent to the payer contract. The payer contract verifies and ensures that it will pay the gas cost of the transaction. It refunds the corresponding amount of native gas tokens to the Bundlers, acting as a refund mechanism. The UserOp goes through the ValidateOp and ExecuteOp stages only after this gas payment process is completed.

The payer contract also allows users to perform additional operations after executing the UserOp, providing further flexibility and control. By leveraging the payer contract and Gas Abstraction, users can conduct transactions without worrying about managing gas costs directly, making the process smoother and more user-friendly.

One limitation of AA is that it cannot support cross-chain payers. Let's consider a scenario: a user has USDC on an SCW on the Ethereum network but wants to use a payer contract to pay for transaction fees on the Arbitrum network. When the payer contract attempts to transfer USDC from the user to the payer during the post-operation function, a problem arises. USDC is stored on Ethereum, while the payer contract is located on Arbitrum. Essentially, Account Abstraction is primarily designed for single-domain use and lacks the inherent capability to seamlessly operate across multiple chains.

Applications specific to Intents

Account Abstraction is often simplified as "gasless transactions," "mnemonic-free transactions," and potential "rate limits." Yes, these features are indeed interesting, but they may not fully capture the truly remarkable nature of AA. The most remarkable aspect of Account Abstraction lies in its architecture, which transforms wallets into gateways for intents.

So, what are intents?

In a standard transaction process, when validators receive a transaction signature, they follow specific computation paths based on a particular state. Additionally, fees serve as an incentive to encourage validators to operate in this manner. However, the situation is different when using intents. Intents do not prescribe a fixed computation path but allow any path that meets specific conditions. When users sign and share intents, they authorize recipients to choose computation paths on their behalf. This distinction makes intents more precisely defined as signed messages, facilitating a series of state transitions starting from a given initial point.

It is worth noting that a single transaction can contain multiple intents, significantly improving gas and economic efficiency. For example, in an order book maintained by builders, two orders can be efficiently offset against each other before reaching the market. Additionally, intents allow more flexible user gas payments, such as allowing third-party gas sponsorship or accepting payments in different tokens.

Therefore, UserOps are not intents, as they are essentially Txs. However, AA turns wallets into gateways for intents, which is achieved through validation logic within smart contract wallets. This validation logic allows for the expression and execution of simple intents related to user accounts. However, SCWs lack the ability to reason about global state.

Account Abstraction fundamentally serves "specific intents." In this case, users can specify and implement simplified intents through their SCWs, as long as these intents meet certain restrictive requirements:

They focus on a single domain;
They only use and execute information related to user accounts;
They involve gas compensation.

Examples of intent-specific applications

Therefore, Account Abstraction primarily caters to user-centric goals. However, there are many examples of "intent-specific" applications that can be implemented using AA, as emphasized by Paradigm:

Limit orders: Users can specify that they can only withdraw 100 X tokens from their account when they receive at least 200 Y tokens.
Gas sponsorship: Users can choose to pay transaction fees using USDC instead of ETH and allocate USDC in their accounts to pay the gas fees for the payer.
Delegations: Interactions with specific accounts can be restricted in a pre-authorized manner. For example, ETH can be specified for purchasing NFTs listed on OpenSea, or a specific address can be restricted to interacting only with Uniswap and Sushiswap.
Transaction batching: Users can allow multiple intents to be batched into a single transaction to improve gas efficiency.
Aggregators: Users can specify using the "best" price or yield for specific operations. This intent can be achieved by providing proof of aggregation and selecting the best path across multiple venues.

While AA and intent-specific applications represent significant advancements, they also have limitations in a multi-chain environment. Let's consider a scenario: I own ETH and want to maximize my purchase of token XYZ by leveraging liquidity on different Rollups. With AA, I can easily and quickly use my preferred DEX aggregator on any Rollup. However, the challenge lies in manually discovering the best DEX aggregator available on all Rollups.

Therefore, in a multi-chain world, a comprehensive and flexible intent language is needed to effectively enhance scalability.

General solution

In an intent-centric world, users declare or sign their preferences, and the network relies on third-party participants (solvers/executioners) to execute these preferences on their behalf.

It is important to emphasize that the current transaction-based methods also allow users to outsource transactions, but the difference lies in who the third party is. Currently, applications build transactions on behalf of users, and they do so without optimizing for the best results. Therefore, the innovation of intents lies not in outsourcing transaction creation to a third party, but in adding a specialized third-party network that can provide better results.

This can improve execution efficiency because these solvers can integrate more information about the state of other chains without the need to communicate with the users.

To illustrate this point, let's revisit the scenario where I own ETH and my goal is to purchase as much XYZ token as possible by leveraging liquidity between different Rollups. In an intent-centric world, I can inform the memory pool that I have ETH and wish to obtain the maximum possible amount of XYZ token. A highly sophisticated solver will efficiently find a solution. The incentives for these solvers should lead to fairly optimized results. In this multi-chain environment, even basic tasks become impractical, such as a single company running a DEX aggregator to integrate with all new Rollups and domains. Therefore, intent-specific applications lack scalability in such a multi-chain environment. However, for intents, a flexible and universal language can effectively scale, as it operates as a permissionless system. There is no need for a single company to act as a full-chain DEX aggregator covering every chain. Instead, a set of solvers can compete to serve users, with some specialized for specific categories of Rollups and others for different domains. This approach demonstrates the significant practicality and capability of cross-chain intents, surpassing ordinary account abstraction, even for simple use cases.

The ideal infrastructure for expressing, conveying, and executing intents should minimize miner-extractable value (MEV), maximize censorship resistance, and optimize for cross-domain interactions. Additionally, it should carefully consider the balance between conveying fine user intents and user experience, as this decision has a significant impact on the architecture of the intent protocol. Furthermore, there are many unanswered questions, such as how to determine what is optimal, where cross-domain intents will be published, and how solvers will determine what to search for.

Examples of General Solutions

While this vision is promising, the first step is to establish an intent layer where users can express their intents and solvers can compete to resolve these intents. Projects like Anoma, SUAVE, Essential, and CoW Protocol are all vying to become the intent layer of blockchain, each adopting different approaches.

However, as the concept of the intent layer is evolving and many of its design principles seem to be contradictory, it is still too early to make comparisons. Establishing such a layer faces significant challenges.

Anoma is a unified architecture for full-stack decentralized applications. It is designed from the ground up for applications involving an infinite number of users, issuing an infinite number of intents, each with varying complexity. Anoma follows the principles of intent-centricity and homogenous architecture/heterogeneous security, collectively constituting the declarative paradigm for building decentralized applications. Intents are submitted to intent propagation nodes, which form the intent pool. Matchmakers analyze these pools to find intents that can be combined and mutually satisfied when combined. The protocol's state machine achieves progressive execution and decoupled verification through effective predicates as invariants on user accounts. Anoma makes it easy to build novel applications that may be cumbersome, limited, or impossible to build on existing Ethereum (EVM) and similar Ethereum-like protocols.

SUAVE is a unified auction protocol for value expression. SUAVE aims to empower users and achieve maximum decentralization of public blockchains. SUAVE decouples memory pools and block-building roles from existing blockchains and provides a highly specialized and decentralized plug-and-play alternative. Sharing the same sorting layer keeps cryptocurrencies decentralized, block builders can capture cross-domain MEV, validators can maximize income, and users can execute optimal transactions while reducing economic centralization pressure in each domain. SUAVE is an integrated environment that promotes decentralized collaboration in expressing, executing, and settling preferences. The core concept is preferences, where user-signed messages are used to express goals, enabling simple transfers or complex sequences across multiple blockchains. Solvers compete to provide optimal execution, including capturing MEV and providing decentralized order flow value.

Essential is developing a suite of products to drive the blockchain ecosystem from value extraction to intent fulfillment. They are creating a domain-specific language (DSL) for expressing intents, an intent-centric account abstraction standard for Ethereum, and a modular intent layer. The DSL allows standardized intent expression and optimized solving, enhancing the composability and development of intent-based applications. The intent-centric account abstraction standard empowers solvers to construct efficient transactions based on user intents, introducing intent functionality to existing EVM chains. The modular intent layer ensures an intent-only architecture, aggregated order flow, MEV resistance, and the possibility of cross-chain intent execution. Essential's mission is to empower users, eliminate exploitation, and promote a user-centric and fair blockchain future.

CoW Protocol builds a network for traders and solvers, achieving trustless and efficient peer-to-peer transactions. CoW Protocol uniquely positions itself as the native transaction infrastructure for discrete-time settlement layers (such as Ethereum) by using batch auctions and provides fair and accessible transactions for users. Transactions can settle directly through on-chain AMMs or through DEX aggregators, depending on which pool/path offers the best price. Essentially, it is a Dex Aggregator's Dex Aggregator. CoW Protocol achieves batch auctions through Coincidence of Wants (CoWs) to maximize liquidity and leverage all available on-chain liquidity when needed. The protocol continuously runs batch auctions as solvers, responsible for finding the optimal batch settlement, compete to resolve it.

Overview of Intent Experiment Projects

The following illustration provides a non-exhaustive overview of intent experiment projects. However, it should be acknowledged that there may be some overlap between different categories, and this presentation is simplified. Typical examples of intent-specific applications that have garnered significant attention are 1inch Fusion or UniswapX. As this field is still young and rapidly evolving, this illustration may undergo significant changes in just a few months.

Conclusion

For end users, the current transaction-based methods in Web3 have proven to be complex and time-consuming. It involves specifying execution paths between various infrastructures, leading to frustrating user experiences and potential exploitation by more complex participants. Intent-based applications offer a promising shift from an imperative paradigm to a declarative paradigm, enhancing user experience and minimizing MEV. While Account Abstraction (AA) and intent-specific applications bring exciting progress, they also have some limitations, especially in a multi-chain world.

Building an intent layer entirely centered around intents faces significant challenges, as we need to overcome the complexity of current systems and create a user-friendly, efficient, and decentralized infrastructure for expressing and executing intents. Therefore, we have a long way to go to achieve this paradigm. However, several projects are dedicated to this effort, and we expect to see more projects emerge in the future.

As the adoption of intents continues to grow (driven by ERC4337), users may turn to alternative memory pools. Prudent management is crucial to prevent centralization risks and the rise of rent-seeking intermediaries.

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

Breaking the dilemma of poor user experience: How does "intent computing" change Web3 interaction?