The principle, application status and risk response of Intent

Recently, in the Ethereum community, there has been a heated discussion about Intent and its applications. This article will briefly introduce the principle, application status, potential risks and countermeasures of Intent.

If the transaction explicitly refers to how to operate the behavior, the intent refers to the expected result of the behavior.

If the Transaction instruction is:

“Do A then do B, then pay C to get D.”

Then the corresponding Intent is:

"I can afford to pay and I want to get a D."

Intent-centric protocols can significantly improve user experience and efficiency. Transaction requires the user to explicitly specify each parameter, and the operation threshold is high. In contrast, using Intents, users can simply express the desired results, while outsourcing the task of optimally achieving the results to a mature third party.

Although Intents provide more possibilities for the ecosystem, Intent-based designs on the Ethereum chain may also have a significant impact on off-chain infrastructure, and there are also important connections with MEV-related activities and market control.

How Intent works

How Intent Works

Currently, the standard way for users to interact with Ethereum is to formulate and sign transactions and messages in a specific format that provides the EVM with all the necessary information to perform state transitions. However, creating a transaction can involve quite complex operations. Creating a transaction requires a lot of details about smart contracts and nonce management, while holding a specific asset to pay gas fees. This complexity leads to poor user experience and reduced efficiency as users need to make decisions without sufficient information or involving complex execution strategies.

The goal of Intent is to reduce the user's burden. Intents allow users to outsource transaction creation to a third party without assigning full control by signing a set of descriptive constraints.

In a standard transaction-based process, when validators are incentivized to verify, transaction signatures allow validators to accurately follow the computational path for a specific state. In contrast, an Intent does not specify exactly which computational paths must be taken, but allows any action that satisfies specific constraints. By signing and sharing an Intent, the user effectively grants the recipient permission to choose the calculation path on their behalf (as shown in the image below). It is worth noting that multiple Intents can be included in a single transaction, allowing overlapping Intents to be matched, saving gas fees and improving economic efficiency. In addition, users can pay gas fees more flexibly, such as allowing third parties to sponsor gas or pay with other tokens.

As shown in the figure, when submitting a transaction, the user specifies the exact calculation path; when submitting the Intent, the user specifies the goal and some constraints, and Matchmaking determines the calculation path to be taken.

Intent application status

The current application status of Intent

Creating Intents outsources the complexities of interacting with the blockchain while allowing users to maintain custody of their assets and cryptographic identities. In fact, many concepts about Intent correspond to systems that have been running for several years, such as the following scenarios:

Restricted order: If the user receives at least 200 B tokens, 100 A tokens can be withdrawn from the user's account.

Cowswap style auction: Same as restricted orders, but relies on a third party or mechanism to match multiple orders to maximize execution quality.

Gas Sponsorship: Users can choose to pay transaction fees in USDC instead of ETH, and there is USDC in the account to pay for gas fees.

Delegated Authorization: Only allows interaction with specific accounts in certain pre-authorized ways. An Intent can only be fulfilled if the final transaction follows the access control list specified in the Intent.

Merge transaction processing: Allows multiple Intents to be merged to improve gas efficiency.

Aggregator: Operates only with the best price/yield, by proving to perform aggregation of multiple scenarios and taking the best path to the Intent.

Currently, Intent has new applications in cross-chain MEV (such as SUAVE), ERC4337 type account abstraction, and Seaport order scenarios. While ERC4337 is developing, other new applications (such as cross-domain Intents) are also entering the exploration stage.

In all Intent-based applications, there needs to be at least one group that understands the Intent and is incentivized to execute the Intent in a timely manner. As for who plays this role, how it is implemented, and its incentives, further exploration and practice are needed to determine the effectiveness, trust, and other impacts of Intent-driven systems.

Intermediary and Mempool

Mediation and Mempool

The most obvious way to get Intents into the hands of willing intermediaries is Ethereum’s Mempool. However, the current Mempool design does not support the propagation of Intents. In the long run, considering the hidden dangers of DOS attacks, the possibility of widespread support for spreading Intents in Ethereum Mempool is extremely low. It can be said that the open and permissionless nature of Ethereum Mempool poses a barrier to the adoption of inten.

In the absence of Ethereum Mempool, Intent system designers face several problems. The choice currently faced is to propagate the Intent to the licensor, or to do it in a permissionless manner so that any party can execute the Intent.

As shown in the figure, the Intent first flows from the user to the permissioned/permissionless public/private Intentpool, and then converts it into a transaction through matchmaker, and finally converts it into a public Mempool, or directly displays it on the chain through an MEV Boost type auction. superior.

Mempool without permission

Mempool without license

One design being attempted is a decentralized API that allows various nodes in the system to broadcast Intents through gossip, thereby providing permissionless access to the executor.

For example, in the 0x protocol relayer, restricted orders are gossip broadcasted to each other and uploaded to the chain when a match is found. This approach is also being explored in the context of shared ERC4337 Mempool to combat centralization and censorship risks. However, the design of this permissionless Intentpool also faces the following challenges:

DoS Resistance: Developers may have to limit the functionality of Intents to avoid potential DoS attacks.

Spread Incentives: For many applications, executing Intents is a profitable activity. Therefore, theoretically, nodes operating the Intentpool have an incentive not to propagate Intents to reduce competition for executing Intents.

MEV: Since the execution quality of Intents relies on the good behavior of off-chain participants, there are some difficulties faced when using public, permissionless Intentpools. If execution is profitable, a permissionless Intentpool may attempt to arbitrage against users. This is similar to the current "sandwich attack" in Ethereum Mempool, which will be a common problem for Defi-related Intents. A future improvement might be to create a permissionless but encrypted Intentpool.

License Mempool

Licensed Mempool

Trusted centralized APIs are more resistant to DOS attacks and do not need to propagate intents. This trust model provides some footing for MEV concerns. As long as the trust assumption holds, execution quality can be guaranteed. Trusted intermediaries may also have a reputation associated with them, providing some incentive to perform operations conscientiously.

Therefore, permissioned IntentPools will be attractive to Intent-based application developers in the short term. However, the assumption of strong trust is naturally flawed and violates the original blockchain spirit to a certain extent.

Hybrid Solution

hybrid solution

There are also solutions that are a mixture of the two situations mentioned above. For example, there is a situation where the propagation process is permissioned but the execution is permissionless, and vice versa. A common example of a hybrid solution is an order flow auction.

The idea behind this type of design is that users in need of counterparties may need to differentiate between better and worse counterparties in order to trade at a more favorable price. The design process typically involves a trusted party who obtains the intent (or transaction) from the user and facilitates the auction on the user's behalf. No permission is required to participate in the auction. There are also disadvantages to this type of design, in that they are likely to be subject to various interferences in a licensed Intentpool.

The bottom line of this approach is that Intent-based applications involve not only new message formats for interacting with smart contracts, but also propagation and adversary discovery mechanisms in the form of alternatives to mempools. The most critical thing at present is to design an Intent discovery and matching mechanism that is compatible with incentives while maintaining decentralization.

Risks and how to deal with them

Risks and their response methods

While Intents are an exciting new paradigm for transactions, their widespread adoption also means an accelerated trend of greater user activity moving to alternative Mempools. If not managed properly, this shift could harm Ethereum’s decentralization and lead to excessive power of trusted parties. The potential risks include the following:

Order flow: If Intent execution is permissioned, but users choose it carelessly and migrate it from the public Mempool, Ethereum block production may become centralized.

Trust: Since many solutions require trust in intermediaries, in order to ensure the execution quality of Intents, this high barrier to entry will hinder the development of new Intent-based architectures and reduce the speed of innovation and competition.

Transparency: Since many Intent architectures require users to hand over some control over their chain assets and permissioned Mempool as a compromise, which means there is a degree of impenetrability from the outside, there is a risk of the system being built being opaque, In this case, it is unclear how user expectations are met and whether there are undetected threats to the ecosystem. Even the middleware and Mempool’s ecosystem that develops between users and the blockchain will become opaque.

So, how to reduce the above risks? We know that the space of Ethereum Mempool is limited. For some applications, the risk is due to their lack of privacy and therefore their inability to support a wider range of message formats. This puts wallet and application developers in a difficult position, as they must find some way to allow users to connect to the blockchain while avoiding the risks mentioned above.

The ideal system should be permissionless so that anyone can match and execute Intents without sacrificing too much execution quality. The system should be versatile so that new applications can be deployed without the need to create new Mempools. Systems should be transparent, allowing for public reporting of the process of executing intents, and providing data for performing quality audits when privacy guarantees allow.

Although teams like FlashBots and Anoma are working hard to meet the above requirements for a universal solution by combining privacy and permissionlessness, it will be difficult to create such a perfect system in the near future. Therefore, users need to make trade-offs and choose different solutions for different applications. Likewise, applications initiating Intentpools need to seek ubiquity without permission and choose intermediaries carefully where permission is available.

Designers of Intent-based applications need to fully consider the off-chain implications of their applications as they concern not just their user base, but the wider community, which requires the wider community to have an understanding of the off-chain implications surrounding Ethereum. The ecosystem remains attentive.

summary

brief summary

Due to the obvious market demand for Intent applications, many Intent-based applications have been widely used for several years. Increasing Intent adoption, driven in part by ERC4337, may accelerate the move away from Ethereum Mempool and into new venues. The adoption of Intent represents the user's shift from a "forced operation" paradigm to a "descriptive" paradigm, which is expected to greatly improve user experience and efficiency.

Ebunker, a long-term Ethereum believer, pays close attention to Ethereum technology development, proposal upgrades and community changes at the first time, and shares research and opinions on key Ethereum tracks such as Staking, L2, and DeFi.

Currently, Ebunker includes Ebunker Pool (funded non-custodial Ethereum Staking mining pool) and Ebunker Venture (Ethereum maximized venture capital) and other businesses.

Ebunker official website: