Understanding Principles, Applications, and Risk Mitigation Strategies of Intent

Recently, there has been a heated discussion in the Ethereum community about intent and its applications. This article aims to provide a brief overview of the principles behind intent, its current applications, potential risks, and methods to address them.

If the transaction explicitly refers to how a behavior is executed, then intent refers to the expected result of that behavior.

For instance, if a transaction’s instructions are:

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

The corresponding intent would be:

“I can afford to pay and I want to get a D.”

Intent-centric protocols can significantly improve user experience and efficiency. Transactions require users to explicitly specify each parameter, raising the entry barrier. In contrast, using Intent, users can simply express the expected outcome while outsourcing the task of optimally achieving the results to a mature third party.

While intent provides more possibilities for the ecosystem, intent-based designs on the Ethereum chain may significantly impact off-chain infrastructures. Activities related to MEV and market control are crucially linked to on-chain intent-based designs.

How Intent Works

Currently, the standard method for users to interact with Ethereum involves formulating and signing transactions and messages in a specific format that provides the EVM with all the necessary information to perform state transitions. However, creating transactions can involve quite complex operations, which requires substantial intricate operations concerning smart contracts and nonce management, while holding specific assets to pay gas fees. The intricacies lead 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 users’ burden. Intents allow users to outsource transaction creation to a third party without relinquishing 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 intents, the user effectively grants the recipient permission to choose the computational path on their behalf (as shown in the figure 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, allowing third-party sponsorship of gas or payment using alternative tokens.

As shown in the figure, when submitting a transaction, users specify the exact computational path, while when submitting intent, users specify the objective and some constraint conditions, with matchmaking determining the computational path to be taken.

Current Applications 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:

Limit orders: If a user receives at least 200 B tokens, they can withdraw 100 A tokens from their account.

Cowswap-style auction: Similar to limit orders but relies on third parties or mechanisms to match multiple orders to optimize 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: Allows interaction with specific accounts only in certain pre-authorized ways. An intent can only be fulfilled if the final transaction follows the access control list specified in the intent.

Batch transaction processing: Allows the batch processing of multiple intents to improve gas efficiency.

Aggregators: Operates only on the best price/yields. Fulfill the intent by proving aggregation of multiple scenarios and taking the optimal path.

Currently, intent has found new applications in cross-chain MEV (such as SUAVE), ERC4337 account abstractions, and Seaport order scenarios. As ERC4337 evolves, exploration into other new applications, like cross-domain intent, is also underway.

In all intent-based applications, there needs to be at least one group that understands intent and is incentivized to execute 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.

Intermediaries and Mempool

The most obvious way to get intents into the hands of willing intermediaries is Ethereum Mempool. However, the current design of Mempool does not support the propagation of intent. Long-term prospects suggest a minimal likelihood of widespread support for intent within Ethereum Mempool, considering the vulnerability of DOS attacks. The open and permissionless nature of Ethereum Mempool present a barrier to the adoption of intent.

In the absence of Ethereum Mempool, designers of intent systems face some challenges. The current dilemma revolves around whether to propagate intent to permissioned parties or to do it in a permissionless manner so that any party can execute the intent.

As shown in the figure above, 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-chain through MEV Boost auctions.

Permissionless Mempool

One design being experimented is a decentralized API that allows various nodes in the system to broadcast intents through gossip, thereby granting permissionless access to executors.

For example, in the 0x Protocol relayers, gossip broadcasting is facilitated for limit orders, being pushed on-chain upon finding matches. 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 some challenges, inclujding:

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

Propagation 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 “sandwich attacks” in Ethereum Mempool, which will be a common problem for Defi-related intents. A potential improvement could be creating a permissionless but encrypted Intentpool.

Permissioned 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, incentivizing serious execution.

Therefore, permissioned Intentpools are attractive to intent-based application developers in the short term. However, strong trust assumptions inherently have flaws and to some extent contradict the original design of blockchain.

Hybrid Solutions

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 order flow auctions.

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 more favorable prices. The design process typically involves a trusted party who obtains the intent (or transaction) from the user and facilitates auctions on the user’s behalf. No permission is required to participate in the auction. However, these designs also have downsides, in that they are susceptible to various disturbances within the permissioned 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 peer discovery mechanisms in the form of alternatives to Mempool. 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 Mitigation Strategies

While intents are an exciting new paradigm for transactions, their widespread adoption may imply an acceleration of a larger trend of user activity shifting to alternative mempools. If improperly managed, 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: Several intent architectures compromise users’ control over their on-chain assets and permissioned mempool, introducing a level of opacity. This opacity poses a risk that the system being built might be opaque. In this case, it is unclear about how user expectations are met and whether there are undetected threats to the ecosystem. Even the middleware and mempool ecosystem evolving between users and the blockchain could become opaque as well.

So, how to reduce these risks? We know that the space of Ethereum Mempool is limited. For some applications, risks arise due to their lack of privacy, preventing them from supporting 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. This requires the wider community to pay special attention to the off-chain ecosystems around Ethereum.

Conclusion

Due to the obvious market demand for intent-based applications, many intent-based applications have been widely used for several years. The increasing adoption of intent, partly driven by ERC4337, might expedite the shift from Ethereum Mempool to new spaces. The adoption of intent represents a shift for users from a “forced operation” paradigm to a “descriptive” one, promising significant enhancements in user experience and efficiency.

Ebunker official website:https://www.ebunker.io

For more discussions, please join: https://t.me/ebunkerio

Ebunker Twitter: https://twitter.com/ebunker_eth

Disclaimer：

1. This article is reprinted from [Medium]. All copyrights belong to the original author [EbunkerChinese]. If there are objections to this reprint, please contact the Gate Learn team, and they will handle it promptly.
2. Liability Disclaimer: The views and opinions expressed in this article are solely those of the author and do not constitute any investment advice.
3. Translations of the article into other languages are done by the Gate Learn team. Unless mentioned, copying, distributing, or plagiarizing the translated articles is prohibited.