Notes on Ethereum Account Abstraction
It’s going to simplify over 5 years of workarounds.
Future Proof Notebook, Volume 1Written by Val, Co-Founder of Future ProofAugust 7, 2023Conclusions
Account Abstraction is going to standardize and simplify a lot of workarounds that web3 developers have been doing for the past 5 years. For example, multi-signature wallets. Gnosis Safe was an entire project dedicated to this. Now I expect it to be copy paste. We’ll also be able to pay gas on users’ behalf without setting up insecure hot wallets. Users will have a wallet recovery mechanism so that the security of their assets are not tied to a single keypair. Operations like token swaps that take multiple signed transactions from users today will be performed in a single call from the user.
There’s one big thing still missing for me: How can I get cron like behavior?
Thanks for reading Future Proof Notebook! Subscribe for free to receive new posts and support my work.
I’d like to trigger some action after X amount of blocks. The Account Abstraction explainers I’ve read (below) so far say that wallets will be able to “initiate” transactions instead of EOAs (externally owned accoutns, i.e. user accounts that require the user to click buttons to sign and send a transaction), however it is not clear to me that this is truly the case as they don’t go into much detail about this.
In any case I look forward to having a reason to do more Ethereum development and build a 4337 wallet. There are multiple Ethereum Improvement Proposals for Account Abstraction but 4337 is the most mature—I think that’s because it doesn’t require a fork and was co-authored by Vitalik. So it seems that it would be the fastest to get done but this is probably a bit self-fulfilling as well. People thought it would be the fastest so they put more energy into it than the others and now it is the fastest.
I haven’t actually read the EIP. I’m sure my lingering questions will be answered when I do. But it’s late now and I’d like to finish watching Legend of Korra. You should read it here though! https://eips.ethereum.org/EIPS/eip-4337
Notes
Account abstraction
https://ethereum.org/en/roadmap/account-abstraction/
Today users interact with Ethereum via externally owned accounts. These are a representation of a public/private keypair and can initiate transactions in Ethereum based on a private key signature. This means that anything that happens on Ethereum through a smart contract or ETH transfer must be triggered by someone’s EOA. For example, I’ve implemented hot wallet systems to periodically send ETH to a wallet stored on a server. The idea is to not keep too much ETH there in case the keys are compromised but it requires some human intervention to manually send funds when the wallet gets low so that the bulk of the treasury is controlled by keys that are offline and much more secure.
Account abstraction is meant to make things like this much easier because it will give smart contracts the ability to initiate transactions themselves, without human intervention or the need for a triggering transaction by an EOA.
It’s also supposed to give us wallets where we can customize the security properties and introduce systems like account recovery so that if you lose a keypair you don’t lose control of a wallet, which is the case today with EOAs.
Beyond Seed Phrases
Account abstraction will still have the user of public/private keypairs, but instead of using an EOA, users will have a wallet that is a smart contract. That contract can be controlled by a primary and backup keypair, have allowlists for allowed accounts to interact with, have different security requirements for different transaction amounts, and generally give users the ability to customize how the assets the wallet owns are controlled.
Examples
multisigs with n of m logic based on the type of transaction
locking/freezing an account from one device if one of the keypairs is lost on another device
account recovery via pre-approved 2 factor auth
account transaction limits to prevent your wallet from being drained by an attacker
allowlist accounts to transact with and multsig on the allowlist
Better user experience
It’s all the stuff that we are currently doing with smart contracts but more core to the protocol and abstracted from the user. They give the example of doing a swap where it takes two transactions: one to approve and one to transfer. Account abstraction would allow these to be bundled into one click for the user and even add revoking approval after it is complete.
The other thing is gas. This would allow an app to pay a user’s gas fees or even let uses pay for gas with other tokens by doing a swap in the contract.
Trusted sessions would be an app getting approval for a series of transactions in a limited time frame so users don’t have to keep triggering transactions when there are many of them. For example in a gaming context when users want to do a bunch of stuff quickly, approving an app to execute on the user’s behalf is a better experience and safety mechanisms could be built in so users are not given up too much control.
How will account abstraction be implemented?
There are 4 proposals to get this behavior to be native to the ETH protocol so we don’t have to implement convoluted and sometimes unsafe workarounds to get this behavior (like the hot wallet top-up I mentioned before):
EIP-2771, EIP-4337, EIP-2938, EIP-3074
They also say this will make ETH more decentralized because people won’t have to rely on relayers but I’d like to understand that claim more.
Current progress
4337 Doesn’t require changes to the ETH protocol and it is the most mature so it seems like the one that is going to win.
As I understand it today, “protocol changes” means a fork which is more work because it requires node operators to get on board and upgrade.
ERC 4337: account abstraction without Ethereum protocol changes
BTW this Medium article is from September 2021.
EVM code is for logic of applications and account abstraction would allow it to also be used for the verification logic of user wallets.
He’s saying this would allow simpler and more efficient signature algorithms (e.g. Schnorr—key aggregation to do an efficient form of multi signature, which was apparently under a patent that prevented its use from 1990 to 2008) and quantum-resistant signatures (e.g. Lamport, which I don’t really know anything about but here’s some info).
So everything we want to do with account abstraction is possible today with a combo of your EOA, smart contracts, and some relayer type systems (i.e. servers doing stuff) and it has gas overhead for end users and the idea is that the relayer doing some logic to perform these actions is a centralized system so some of the compute is being centralized. Ethereum wants all compute to be decentralized via the EVM and node operators running it.
EIP-2938 gives smart contracts the ability to initiate transactions but it requires large protocol changes so 4337 is the alternative that achieves the same thing without needing protocol changes.
How does this proposal work?
4337 creates another mempool called the UserOperation mempool. So it basically mimics the way regular transactions work in the Ethereum mempool today. Users send their UserOperations to nodes that bundle these into a single transaction which can then be put into an Ethereum block.
The UserOperation calls a wallet (and first creates it if one doesn’t exist yet) to do an action. The wallet must have two functions: the first is validateUserOp that should be implemented to validate that the user can take the operation. The second is the execution function that actually tells the wallet what to do.
The entrypoint contract is a global contract used by all 4337 wallets. When bundlers get their UserOperations they send those through the entrypoint. After the validateUserOp step succeeds the entrypoint contract actually calls the 4337 wallet on the user’s behalf.
The thing that I don’t understand here is how this actually helps wallets initiate transactions. It still seems like a user must send a UserOperation with their own signature for the wallet to do anything. Gas is also still required and it’s not yet clear how someone would pay for someone else’s UserOperation.
Looking at the linked 4337 EIP I see a field called “paymaster” which is where you put the address of the person paying. But still unclear how the gas payment actually happens.
What properties does this design add, maintain and sacrifice compared to the regular Ethereum transaction mempool?
This part is already summarized but one thing stood out.
Sufficient to make the execution layer quantum-safe
There’s a line under this bullet that I don’t at all understand: “Even the wrapper transaction is safe, as the miner can use a new freshly created and hence hash-protected EOA for each bundle transaction and not publish the transaction before it is added in a block.” I don’t know what this has to do with quantum safety.
Sponsorship with paymasters
This answers my question about gas. Paymasters must stake to the entrypoint contract and also confirm that they are willing to pay for the UserOperation.
A postOp function is called after the wallet execution function where the paymaster can pay on a user’s behalf and the user pays the paymaster in the postOp. So the paymaster can pay in ETH upfront and then get some ERC20 from the user to cover the charge.
There’s a lot of videos on this on the ERC 4337 website: https://www.erc4337.io/
