Using flashbots as a backdoor path to account abstraction

[vbuterin]

One of the long-running desires of many in the Ethereum protocol community is to add some form of account abstraction. Account abstraction (see also: this video where I talk about the concept) is the idea that instead of every transaction needing to start from an "externally-owned account" (EOA) controlled by a private key, transactions could start directly from contracts (and EOAs could eventually even be deprecated entirely).

There are many use cases for this: smart contract wallets (eg. see here where I make the case for social recovery wallets), privacy-preserving tools like Tornado Cash, etc. Today, smart contract wallets are difficult to use because a transaction must start from an EOA, and the EOA must pay the gas fees, so someone using a smart contract wallet must have some of their ETH in an EOA to pay for gas, adding significant complexity (and wasted gas). Centralized relayers can mitigate this to some extent, but some inefficiency ultimately still remains.

Flashbots can solve this! Flashbots is basically a very powerful and more efficient generalized and decentralized relayer protocol, and it should be possible to build a plugin to turn it into a relayer for smart contract wallets:

• When a user wants to make an action with a smart contract wallet, they generate the ABI encoding of the function call to their wallet. This ABI encoding contains:
  • The target, calldata and gaslimit (or an array of each, if they want to make multiple calls)
  • A fee, a quantity of ETH that the wallet sends to the block.coinbase (post-EIP-1559 this could be extended to max_total_fee and miner_bribe)
  • The signature (or multiple signatures), which the contract wallet verifies
• The user publishes a package containing this ABI encoding and their smart contract wallet address to a specialized p2p subnet, which only rebroadcasts encodings if they follow some rules that guarantee that they actually will pay a sufficient fee if included.
• Specialized flashbots relayers that "speak" this sub-protocol would live on this network and package proposals consisting of these packages. To save gas, they could simply make a single wrapper transaction that includes all of the calls.

There is a lot of room for creativity in what those verification rules could be. One simple option is to check for four conditions:

1. The fee is sufficiently high
2. The contract wallet fits a template that shows that it can accept the encoding
3. The contract has enough funds to pay the fee
4. If you execute the contract, the execution gets past the signature verification stage

Another option is more limited but simpler: if the total gaslimit is low enough (eg. under 400000?), the system could simply check that the block.coinbase's balance increases by a sufficient amount during transaction execution. This could allow the privacy-preserving use cases as well as smart contract wallet creation.

This could give us most of the benefits of account abstraction without needing to make deep changes to the Ethereum protocol itself (eg. EIP 2938), and so it seems worth making a serious effort to explore and implement.

[PhiMarHal]

the idea that _ every transaction needing to start from an "externally-owned account" (EOA) controlled by a private key,

This might be missing "instead of" or "rather than".

[vbuterin]

Thanks! Fixed.

[adietrichs]

Ah, really interesting! Most of our work on EIP-2938 was on creating the mempool rules for identifying "safe" transactions. I think those could potentially be adapted to this new use case. In addition to these safe rules, flashbot relayers could also offer to accept packages with more complex payment behaviour, similar to the general MEV case.

[zhous]

Wow, so everyone owns a machine gun! That's an incredible excited spectacle!

[Multimyst]

Wow,This is a brand new attempt！

[amanusk]

Some thoughts on this since I had a very similar idea. Basically described here: https://twitter.com/amanusk_/status/1370642493621080071

The interesting part for me was that by using flashbots, no extra contracts were needed. This means that anyone can be the relayer, including the EOA itself that had no ETH.

This solution has downsides. In this simple scenario, the bundle had to be executed to its completion, otherwise, the account would not have enough ETH to cover the costs of the transaction. If a third-party relayer (with ETH) would have sent the bundle on behalf of the EOA, the miner could theoretically only mine the Tx that pays them, without doing all the actual work. This must be taken into consideration, even if currently miners execute bundles as-is. (Edit: it is also true that Txs in this case could only execute in-order because of the nonce, but it is still true that this would not have been the case if a third party executed these on the EOA's behalf)

Wrapping and executing the bundle in a smart contract wallet, and only paying the block.coinbase would solve this, but solutions similar to that already exist (e.g. any.sender -> ITX)

Another limitation here that is currently in place is that there is currently only one bundle in each block. "Regular" txs would find it hard to compete with other bots that use the bundles to extract MEV (e.g. by sandwiching DEX trades). This can make more sense once multiple independent bundle can be included in each block. Correct and fair ordering of bundles in a block is an interesting problem to solve.

[ErikBjare]

How is this affected by EIP-1559? Specifically what @koeppelmann mentioned here: https://twitter.com/koeppelmann/status/1381922898617757696

[livingrock7]

If a third-party relayer (with ETH) would have sent the bundle on behalf of the EOA, the miner could theoretically only mine the Tx that pays them, without doing all the actual work. This must be taken into consideration, even if currently miners execute bundles as-is.

@amanusk can you elaborate more on this Also, could you pay to particular pool address instead of block.coinbase and relay bundles to them?

[sidutta]

If a third-party relayer (with ETH) would have sent the bundle on behalf of the EOA, the miner could theoretically only mine the Tx that pays them, without doing all the actual work. This must be taken into consideration, even if currently miners execute bundles as-is.

@amanusk can you elaborate more on this Also, could you pay to particular pool address instead of block.coinbase and relay bundles to them?

A bundle is a set of txns. If the miner bribe comes from a 3rd party relayer with its txn nonce not being dependent on the rest, a miner can only execute the bribe txn while dropping the rest of the txns in the bundle.