Paradigm: The intents paradigm of Ethereum transactions - architecture and risks

Authors: Quintus Kilbourn, Georgios Konstantopoulos, Paradigm; Translation: Golden Finance 0xxz

Introduction

Discussions around “intents” and their applications have become a hot topic in the Ethereum community recently.

Where transactions specifically refer to "how" an action should be performed, intents refer to "what" the expected outcome of that action should be. If a transaction says "do A first, then B, pay C in full to get X", intents say "I want X, and I'm willing to pay up to C".

This declarative paradigm unlocks exciting user experience and efficiency improvements. Through intents, users can simply express a desired outcome while outsourcing the optimal task of achieving that outcome to an experienced third party. The concept of intents is in contrast to today's imperative transaction paradigm, where each parameter is explicitly specified by the user.

While these promises of improvements provide much-needed steps for the ecosystem, the intent-based design on Ethereum could also have significant implications for off-chain infrastructure. In particular, there are important links to MEV-related activities and market control. This post aims to provide a brief definition of intents and their benefits, an exploration of the risks involved in their implementation, and some discussion of potential mitigations.

What are intents?

The current standard way for users to interact with Ethereum is to craft and sign a transaction, a message in a specific format that provides all the necessary information for the Ethereum Virtual Machine (EVM) to perform state transitions. However, creating transactions can be a complicated affair. Creating a transaction requires reasoning about details such as a vast network of smart contracts and nonce management, while holding specific assets to pay for gas fees. This complexity results in a suboptimal user experience and loss of efficiency as users are forced to make decisions without adequate access to information or complex enforcement policies.

Intents are designed to ease these burdens on the user. Informally, intents sign a set of declarative constraints that allow users to outsource transaction creation to third parties without giving up full control of the transaction parties.

In standard transaction-based processes, transaction signatures allow verifiers to follow exactly one computational path for a particular state, and hints incentivize verifiers to do so. Intents, on the other hand, do not explicitly specify the computational path that must be taken, but allow any computational path that satisfies certain constraints. By signing and sharing intents (intents), users effectively grant recipients permission to choose computation paths on their behalf (see diagram below). This distinction allows for a somewhat stricter definition of intents as signed messages that allow a set of state transitions from a given starting state, with a special case being transactions that allow unique transitions. Having said that, we will continue to distinguish "intents" from transactions.

*Figure 1: When submitting a transaction, the user specifies the exact calculation path. When submitting intents, the user specifies a goal and some constraints, and the matching process determines the computational path to be taken. *

Importantly, many intents (intents) can be included in a single transaction, allowing matching of overlapping intents (intents), increasing gas and economic efficiency, for example in the order book maintained by the builder, two orders can be mutually exchanged before entering the market offset. Other applications include cross-domain intents (intents) - signing a message instead of multiple transactions on different domains - using different replay resistance (replay resistance) schemes, and more flexible user gas payments, such as allowing the first 3 parties sponsor gas or pay in different tokens.

past and future of intents

Intents have been created that outsource the complexity of interacting with the blockchain, while allowing users to maintain custody of their assets and cryptographic identities.

You may notice that many of these ideas correspond to systems that have been in operation for many years:

• Limit Order: May withdraw 100X from my account if I receive at least 200Y.
• CowSwap-styleAuctions: Same as above, but relies on a third party or mechanism to match many orders to maximize execution quality.
• **Gas Sponsorship: **Pay gas in USDC instead of ETH. Intents (intentions) can only be realized by matching intents, and the fee is paid in ETH.
• Delegation: Only allow interaction with certain accounts in certain pre-authorized ways. Intents can only be implemented if the resulting transaction respects the access control list specified in the intent.
• **Batch transaction: **Allow batch processing of intents to improve Gas efficiency.
• ** Aggregators: ** Only operate with the "best" price/yield. This intent can be achieved by proving that aggregation of multiple venues is performed and the best path is taken.

Going forward, in the context of cross-chain MEVs (such as SUAVE), ERC4337-style account abstractions, and even Seaport orders, people's intents are being reinvigorated! While ERC4337 is moving full speed ahead, other novel applications such as cross-domain intents still require further research.

Crucially, in all intent-based applications, old and new, there needs to be at least one other party that understands the intent, is motivated to execute the intent, and is able to do so in a timely manner. Questions of who these parties are, how they perform, and what their motivations are must be asked to determine the efficacy, trust assumptions, and wider implications of intent-driven systems.

The middleman and its mempool

The most obvious channel for intents to get into the hands of middlemen is the Ethereum mempool. Unfortunately, the current design does not support the propagation of intents. Concerns about DoS attacks may mean that universal support for fully generic intents in the Ethereum mempool is impossible even in the long run. As we will see below, the open and permissionless nature of Ethereum mempools creates additional barriers to the adoption of intents.

In the absence of an Ethereum mempool, intents system designers now face some design issues. A high-level decision is whether to propagate intents to the permission set or to provide them in a permissionless manner so that either party can execute the intents.

Figure 2: Intents flow from users to permissioned/non-permissioned and public/private intents (intentions) pools, converted to transactions by intermediaries, and finally enter the public memory pool or go directly to the chain via MEVBoost-style auctions

Permissionless mempool

One design that one might strive for is a decentralized API that allows intents to be propagated across nodes in the system, providing permissionless access to actors. This has been done before. For example, gossip limit orders between 0x protocol relayers and put them on-chain when matched. This idea is also explored in the context of a shared ERC4337 mempool to combat centralization and censorship risks. However, the design of such a permissionless "intents pool" faces some significant challenges:

• ** Anti-DoS: ** It may be necessary to limit the functionality of intents (intent) to avoid attacks.
• Propagate Incentives: For many applications, executing intents is a profitable activity. Therefore, nodes operating a pool of intents have an incentive not to propagate, in order to reduce contention when executing intents.
• **MEV: **intents rely on good behavior from off-chain actors to improve execution quality, and using a public, permissionless pool of intents may encounter difficulties. If poor execution is profitable, then an unauthorized pool of intents is likely to lead to that outcome. This is similar to being caught in the Ethereum mempool today and is expected to be a common problem for DeFi-related intents. One possible path forward could be permissionless but encrypted intent pools.

Permitted "memory pool"

Trusted centralized APIs are more resistant to DoS and don't need to propagate intents. Credible models also provide some footing for MEV problems. As long as the trust assumption holds, the quality of execution should be guaranteed. A trusted intermediary may also have a reputation associated with it, providing some incentive to provide good execution. Because of this, permissioned pools of intents are attractive to developers of intent-based applications in the short term. However, as we all know, the strong trust assumption is flawed and somewhat antithetical to much of the blockchain ethos. These issues will be dealt with below.

mixed solution

Some solutions are mixtures of the above. For example, there can be permission to propagate, but no permission to execute (assuming the trust assumption holds), and vice versa. A common example of a hybrid solution is an order flow auction.

The high-level idea behind these designs is that a user who needs a counterparty may need to distinguish between better and worse counterparties (e.g., the other party that accepts a trade at a favorable price). The design process typically includes a trusted party that receives user intent (or transactions) and facilitates the auction on their behalf. Participating in auctions is (sometimes) unauthorized.

These types of designs have their own drawbacks and are likely to suffer from many of the concerns surrounding permissioned intent pools, but there are some important distinctions that will become apparent later.

Bottom line: Intents-based applications not only involve new message formats for interacting with smart contracts, they also involve alternative mempool-style propagation and counterparty discovery mechanisms. Designing an intent discovery and matching mechanism that is both incentive-compatible and decentralized is non-trivial.

Where can I go wrong?

While intents are an exciting new transaction paradigm, their widespread adoption could mean that the larger trend of user activity shifting to alternative mempools is accelerating. If not managed properly, this shift could lead to the centralization and entrenching of rent-seeking middlemen.

Order Flow

• Migration from the public mempool could lead to centralization of Ethereum block production if intents execute with permission, but the permission set is not chosen carefully. *

The vast majority of block production on Ethereum currently occurs via MEV-Boost, an off-protocol implementation of proposer-builder separation (PBS), and the current roadmap gives no indication that this interface will be anytime soon Change. PBS relies on the existence of a competitive market for block builders to direct MEV to the validator set. A major problem in PBS is the ability of block builders to gain exclusive access to the raw materials needed to produce valuable blocks—transactions and intents, also known as “order flow.” In PBS parlance, permissioned access to intents will be referred to as "Exclusive Order Flow" (EOF). As discussed in this article, EOF in the wrong hands threatens the market structure on which PBS relies, as exclusivity in order flow means a moat against competitive forces.

Block builders (or collaborating entities) that control the majority of Ethereum’s order flow will be able to produce the majority of mainnet blocks, opening a vector for censorship. Since the network relies on competition among builders to pass value to validators (or be destroyed in the future), the dominance of a single builder will constitute a transfer of value from Ethereum to builders. Rent-seeking and censorship are undoubtedly significant threats to the protocol.

trust

• As many solutions require trust in intermediaries, the development of new intents-based architectures is hindered by high barriers to entry, which means lower rates of innovation and competition to ensure quality of execution. *

In the worst case, users can find themselves in a position where only one party executes intents, such as the block building monopoly in the previous section. In such a world, block building monopolies would be able to extract rents, and any new proposals for how to handle intents would be rejected if not adopted by builders. Individual users lose negotiating power in the face of a monopoly—an effect that is exacerbated when users use intents to provide additional degrees of freedom to intermediaries.

Unfortunately, market stagnation due to centralized infrastructure does not include concerns about a market for builders. Even for non-block building businesses, high barriers to entry put middlemen in a strong position, as they face little competition. For example, consider the current state of the order flow auction market. A few entities such as Flashbots and CoWswap receive most of the order flow to OFA. Order flow is distributed in large part because these entities have been around for years or are associated with reputable entities, meaning they have managed to gain some level of public trust. If a new OFA design tries to enter the market, whoever is running the new OFA will have to spend a lot of time convincing users and wallets that they are reputable and will not abuse their power. The need for such a credible campaign certainly constitutes a substantial barrier to entry.

The order-flow auction market has only recently begun to gain traction, and it remains to be seen how competition will develop, but the market does provide an illustrative example where permissioned, trusted mempools may enshrine a small number of powerful participants, thereby harming the best interests of users.

The EIP4337 intent format provides another example of a mechanism that is possible for us. Consider a world where a trusted architecture is already in place to support 4337 intents. If another format for intents is proposed - perhaps serving additional use cases like cross-origin functionality - but established trusted intermediaries don't adopt this new format (after all, it doesn't have much adoption and is not relevant to their business model competition), the implementation of new formats requires building trust in new entities. Likewise, we find ourselves in a position to innovate and challenge the status quo, but encounter barriers to entry based on trust.

Opacity

• Since many intents architectures require users to relinquish some control over their on-chain assets, and permissioned mempools imply a degree of external impenetrability, we run the risk of building an opaque system where, It is not clear how or whether user expectations will be met, and the threat to the ecosystem remains undiscovered. *

The above sections deal with the risks to users and protocols that power imbalances in the order flow market pose. A related problem is that the ecosystem of middleware and mempools that develop between users and the blockchain becomes opaque, even to astute observers. This concern is especially relevant to intents-based applications that seek to allow users to outsource important decisions such as order routing.

Situations where MEV negatively impacts user execution are often due to enforcers forgoing a high degree of freedom in trading (e.g. slippage limits). So it's not a huge leap of logic to assert that intents-based applications that give up greater degrees of freedom should design their execution systems more carefully. The worst outcome in this regard is a world where using an intent-based app requires signing a disappearing intent (into a dark forest, if you will) and then somehow Implemented as transactions, but it's not clear how or by whom transactions are created. Of course, the ability to monitor such ecosystems is also related to concerns about EOF and trust-based defenses.

Mitigate risk

The Ethereum mempool is limited. For some applications this is due to its lack of privacy (sandwich clips), for others it is due to its inability to support a wider range of message formats. This puts wallet and application developers in a bind, as they must find some way to connect users to the blockchain while avoiding the aforementioned dangers.

When examining the above questions, we can infer certain properties of ideal systems. Such a system should be permissionless, so that anyone can match and execute intents without sacrificing too much execution quality; generic, so that deploying new applications does not require building new memory pools; transparent, so that it is public Report on the process of executing intents and, where privacy guarantees allow, provide data for performing quality audits.

While teams like Flashbots and Anoma are working on general solutions that meet the above requirements by combining privacy and permissionlessness, the ideal system may not be ready anytime soon. So different solutions making their own tradeoffs may best serve different applications. While mechanisms like crlists arose in response to many of the same issues surrounding transaction-based apps, perhaps not for intents, gadgets that allow users to fall back to transactions whenever possible would be nice Improving worst-case scenarios Again, apps looking to start pools of intents are better off seeking generality when they're not permissioned, and choosing a middleman carefully when they're permissioned.

Broadly speaking, we ask designers of intents-based applications to thoroughly consider the off-chain impact of their applications, as these may touch wider communities than just their user base, we ask that The community pays close attention to the off-chain ecosystem surrounding Ethereum.

in conclusion

The adoption of intents represents a shift from imperative to declarative paradigms, which promises to significantly improve user experience and efficiency losses due to MEV. The need for these applications is clear, and many intent-based applications have been in widespread use for many years.

The increased adoption of intents, driven by ERC4337, may accelerate the move from Ethereum mempools to new venues. While the move is reasonable and inevitable, intents-based application designers have good reason to be careful in designing the off-chain components of their systems when developing a robust infrastructure.

There is still a lot of research and engineering to be done in this nascent transaction paradigm and in areas we haven't covered in this article, such as designing an expression language for intents that allows privacy.

Many thanks to DanRobinson, CharlieNoyes, MattHuang, JohnGuibas, XinyuanSun, and ElijahFox for their feedback on this article, and AchalSrinivasan for the piece.