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:
- The fee is sufficiently high
- The contract wallet fits a template that shows that it can accept the encoding
- The contract has enough funds to pay the fee
- 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.
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:
target,calldataandgaslimit(or an array of each, if they want to make multiple calls)fee, a quantity of ETH that the wallet sends to theblock.coinbase(post-EIP-1559 this could be extended tomax_total_feeandminer_bribe)There is a lot of room for creativity in what those verification rules could be. One simple option is to check for four conditions:
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.