Transaction = you specify how to do it; Intent = specify what you want, but don't care how to achieve it.
Original title: " Account Abstraction and SUAVE: How far are we from an Intent-Centric Ethereum? "
Written by: StanleyH, Researcher at MetaWebVentures
Compiled by: Yvonne
"Intent" has recently become the core topic of discussion among Ethereum enthusiasts, and related content such as account abstraction, SUAVE, order flow auctions, etc. have also been connected in series. This article will discuss how we complete the transformation from "transaction-based swap" to "intent-based swap", and what unexpected results may occur during the process, completely changing the form of MEV.
intent
Talking about "Intent" without mentioning Anoma is not justified. They started building an Intent-centric blockchain architecture from the beginning. So what is Intent? Thankfully, this article is based on Paradigm, so I can borrow their definitions:
"An Intent is a signed, declarative set of constraints that allows users to outsource transaction creation to a third party, while relinquishing full control over the parties to the transaction."
Let's look at a real example. Alice has 10,000 USDT on Ethereum, and she wants to use this money to get as much GLP (on Arbitrum) as possible. Today, Alice needs to first bridge her funds from Ethereum to Arbitrum, which requires choosing an optimal Cross-chain bridge. Fortunately, this can be done with a bridge aggregator like Bungee. After connecting USDT to Arbitrum, Alice now needs to decide which asset she will use to buy GLP - since GMX imposes dynamic fees on different assets to balance the pool when buying GLP, this means that if the USDT fee is too high, Alice may Will exchange USDT to another asset (ie ETH) and use ETH to buy GLP. To make a decision, Alice needs to compare the difference in fees on GMX and the transaction slippage between multiple assets. It's a lot of work, and her calculations may not be available by the time she signs the deal -- rates, prices and slippages change all the time.
With Intents, the process looks completely different. Alice only needs to express her Intent "I want to get as many GLPs as possible, at least 100,000, and there are 10,000 USDT on Ethereum", the Intent solver will complete all calculations and transactions for her, and only give her the final Results: GLP on Arbitrum.
In short, transaction = you specify how to do it; Intent = specify what you want, but don't care how to achieve it.
In fact, we already express Intents on Ethereum. Every swap using a DEX aggregator like 1INCH is an Intent: you just specify the input amount and slippage, and let the routing contract find the best route for you. We call it "simple Intent". There is also something I call a "searcher Intent", like a searcher's preference for transaction order in a Flashbots auction. This is important when we delve into the implementation of Intents later. Then there is "arbitrary Intent", that is, the user can express any Intent and complete the Intent.
UX Revolution
Blockchain has long been criticized for its poor user experience, which many believe is one of the obstacles preventing mass adoption of Web3. Now we have Intents, an interaction paradigm that can make blockchain user experiences not only comparable to Web2, but actually better than Web2. With the current Web2 setup, the user with the end goal still needs to know the path, i.e. if you want to buy stocks/items/food, you need to know which app to use...but Intents can work without knowing the path achieve the ultimate goal. The native composability of blockchain Dapp further makes this model scalable compared to siled Web2 applications.
Intent layer
This vision sounds good, but first we need an intent layer where users can express their intents and solvers can compete to resolve those intents. Anoma and SUAVE are the ultimate intents for Flashbots, both trying to be the intent layer of the blockchain while using completely different approaches. It's too early to compare them (no one knows what an Intent layer should look like), but one thing is for sure: building an Intent layer is hard. Many of its design principles are actually contradictory, as reflected in SUAVE's blueprint:
1. Credible commitment and decentralization
A simple p2p network of Intents (i.e., an "Intent mempool") is unlikely to work because it cannot guarantee the commitment of users and solvers to Intents - for example, we need to ensure that a user will pay the amount she promised, Once her Intent is resolved, the solver must obey the constraints set by the user. A centralized solution would work, but of course we want a decentralized solution, which leaves us with one option: the blockchain. Yes, that's why SUAVE is a blockchain itself.
2. Privacy
We want solvers to provide the best possible execution for user intents, which requires as much information as possible, but at the same time don't want malicious actors to exploit them, which requires at least some intent information to be hidden. There are currently two problems: First, it is technically difficult to keep computable information on the blockchain private. Limited choices: TEE, ZKP, MPC. None are perfect, and Flashbots proposes to use Intel's Trusted Execution Environment (TEE), which has already drawn some criticism for its security (and elegance compared to encrypted solutions). . Second, it's unclear whether there will be an "right balance" of privacy. Flashbots' latest product, MEV-Share, or "proto-SUAVE," can disclose some of a user's transaction data to a searcher. Whether this actually benefits both users and seekers remains to be seen: backruns are only optimized if seekers know exactly the size and slippage of the swap, and zero information leakage makes it impossible to extract any value. Anything in between reduces the maximum possible surplus.
3. intent language/protocol
Users also need a language to express Intents. We want this language to be able to express arbitrary intents, that's why SUAVE will use EVM/Solidity - it's Turing complete. But we also need a protocol that standardizes Intents, possibly restricting the language, for two reasons: First, Intents with infinite expressions may not be resolved or verifiable on-chain. Second, expressiveness enables ambiguous intents, which generate more MEV, which we want to minimize. This is another difficult balance to strike.
4. Cross-chain settlement & oracle
Since SUAVE is an independent blockchain, in order to handle Intents from external domains (ie Ethereum), Cross-chain settlement is involved. Ethereum users must deposit funds into SUAVE and commit to unlocking those funds when their Intent is resolved. For smart contracts on SUAVE, an oracle is required to verify this. Therefore, SUAVE will face all the problems we encounter in Cross-chain bridges today: security, speed, user experience, trust assumptions, etc.
To sum up: we want to use blockchain to decentralize the Intent layer, which introduces the problem of Cross-chain settlement; we hope to provide users with more value returns, which may also bring more fines; express their wishes, but also need to ensure that what they express is solvable.
Intent layer requires account abstraction
Account abstraction (AA) is often reduced to "gas-free transactions", "keyless recovery", and perhaps "rate limits". Yes, these are cool, but not cool enough. The coolest thing about AA is its architecture, which makes the wallet the entrance of Intent.
A brief recap of AA:
There are two types of addresses on Ethereum: smart contracts and external accounts (EOAs). EOA can initiate transactions, but smart contracts cannot. Therefore, most of the Ethereum wallets we use today are EOA. There are smart contract wallets (SCW) like Gnosis Safe, but since smart contracts cannot initiate transactions, you need the EOA to tip the SCW. SCW advantage: As a smart contract, the wallet can execute arbitrary logic, opening countless new applications for the wallet, while EOA can only sign transactions.
To enable users to use SCW without a separate EOA, EIP-4337 introduces a new transaction type called User Operation and a new role called Bundlers. After passing EIP-4337, the user flow of SCW is:
Users send UserOps (indicating the action they want the wallet to do) to the UserOp mempool → bundler verifies and "bundles" UserOps together, executes them (signs, pays gas fee), sends the transaction to the EntryPoint contract → the EntryPoint contract puts the transaction Passed to SCW, prompting SCW to do what user asked → bundler gets gas fee refund from EntryPoint contract (for simplicity, we will skip PayMaster).
So, why does the Intent layer need AA? We still take SUAVE as an example. There are two cases:
1. SUAVE directly handles user Intent
In this case, as we mentioned, users need to deposit funds on SUAVE and check and write smart contracts. This greatly degrades the user experience. This is very counterintuitive - why would I need to move funds to and interact with another chain just to do something on Ethereum? Here, AA and SCW come into play: you can put SUAVE All the interaction logic of is packaged into the Ethereum wallet. Funds are deposited, verification is performed, everything works. This doesn't solve any of the fundamental challenges facing SUAVE - we still need a trustless bridge, an Intent protocol, etc. But at least the user experience itself can be largely saved with SCW. EOA simply cannot do this.
2. SUAVE only handles the searcher's Intent
It's clear that Flashbots will iteratively build SUAVE on top of its existing products, namely MEV-Boost and MEV-Share. Given the difficulty of building a viable protocol for arbitrary intents, SUAVE likely won't touch user intents for a long time. Instead, it will look more like current Flashbots, which mostly deal with transaction order preferences, or what I call "searcher Intents". In this case, someone must first convert the user's Intent into a transaction, and then submit the transaction to SUAVE, which means that Intent resolution will happen before SUAVE.
So who is the Intent layer in this case? Currently Dapp, like DEX aggregators resolve simple Intents. As AA matures, SCW may become the de facto intent layer and steal lunch from Dapp and SUAVE. The reasons are as follows:
Currently, MEV is a reordering of existing transactions. However, with Intents, most of the value is extracted before transactions are created, and MEV (if we still call it that) will be about creating transactions from Intents. After the solver receives the Intent, it can adjust the execution as it likes (as long as the constraints are met), insert its own transaction into the transaction generated by the Intent, and bundle them together as an atomic transaction.
The most immediate example is a sandwich attack: now, a sandwich attacker needs inventory to adjust prices based on user transactions, and must trust relayers, builders, and proposers not to unbundle their sandwiches (otherwise they will be completely destroyed ). But an intent solver can sandwich a user intent risk-free and capital-free: he just needs to accept the Flash Loan, change the price before the user swaps, swap after the user swaps, repay the Flash Loan and make a profit, all at once The transaction is done because all the steps involved are technically HIS.
Wait, does this sound familiar? Let's take another look at this wonderful painting:
Indeed, Bundlers are very much like Intent solvers. They take UserOps, convert them into transactions, and leverage them at will because technically, those transactions belong to them.
So Bundlers will be the next searchers. What does this have to do with wallets? The point is, UserOps are not Intents. UserOps are pseudo-Ethereum transactions whose use of the nonce and signature fields is not defined by the protocol, but by each account implementation. Therefore, there must be a process of "Intent to user action". This is exactly what the Intent layer does.
If we believe that SCW will dominate, there is only one logical outcome: the wallet becomes the Intent layer. The Intent and order flow that entered the Dapp before will be intercepted by the front end of the wallet. The user flow will look like this:
Note that Intent solvers on the SCW frontend are likely to act as Bundlers at the same time, and Bundlers may also be block builders. This vertical integration leads to the so-called "Exclusive Intent Flow (EIF)", like the EOF (Exclusive Order Flow) widely discussed in the MEV community. In my last post, I argued that EOF is not an issue because users can easily switch actuators if they find themselves stuck. But this time the Intent will be different: the user no longer owns the transaction. Of course, they can also switch the Intent layer, but the cost will be much higher than switching RPC now.
So (unsurprisingly), Intent will further centralize MEV. The good news is that building a fully functional Intent layer is difficult for Flashbots, and for any wallet, so we won't see a full EIF for a long time. The bad news is that wallets can also be iterated. Remember, Dapp today are Intent solvers, SCW can have plugins, or Dapp inside wallets. Installing a wallet plugin in your wallet is as easy as installing an app from Google Play on your Android phone. These wallet plugins will act as the earliest intent solvers, and all intents they attract will be funneled into the wallet first. An Intent layer built from the bottom up.
Now we can answer the questions in this thread: we are still far from Intent-centric Ethereum, but Intent will start to play a bigger role in user traffic, which will inevitably change the MEV landscape permanently, smart contracts The wallet will be a powerful value extractor. Users sacrifice ownership of transactions for a better user experience, hoping that a well-designed Intent layer will fairly reward them for the value generated by their Intents.
