Account Abstraction: Unveiling Ethereum's Adaptive Alchemy

Take a moment and think about what the following line could mean :

0x661635442479673b5d861127940600519842996d

If you are a blockchain enthusiast you would have probably guessed that this is an account address, which is correct. Now this 42-character address could refer to one of the following two things: either a wallet address or a smart contract address. And thus these are the two types of accounts that we have in the Ethereum network :

Externally Owned Account (EOA) - an account capable of initiating and signing transactions
Smart Contract Account - an account capable of implementing logic

For a long, EOAs have been the gateway to the world of blockchain tech. Any interaction in the ecosystem has to be initiated and signed off by an EOA. It has become the point of contact for any user to participate and add to the ecosystem. This single-fail point is also its very own sparkling drawback, for every EOA is defined by its public and private keys. We have a public key that we can use to receive transactions and a private key to sign off transactions from our wallet.

And they who owns the private key owns the wallet, and hence the assets!

If the past headlines have taught us anything, it's that now is always the best time to root for self custody of wallets. We cannot risk our private keys falling into the wrong hands, and it's hard to keep it that way. And even if we somehow manage to do so, there is still the need to remember the recovery seed phrase (ugh, the pain!)

Honestly, none of these are appealing to any user and for a tech that is in its blooming era, these surely are off-putting to any new user who wants to come in. When the idea of Bitcoin was proposed back in 2008, it promised to push open the door for a decentralized banking(transaction) system. Several Layer01 blockchains have been experimenting to make this a reality and suffice it to say many have progressed in their mission, on the decentralization part (argumentative !?). But, how close are we to that real-world banking experience, where we do not have to worry about any of these ? How nice it would be if these wallet accounts just act like our bank accounts (ofc without their centralization part )?

Turns out we may have a solution from Walletcon Denver 2023 — ERC 4337

ERC 4337

“It gives you the same features a bank would without having to trust a bank” — Yoav Weiss

Did we just get lucky !? But what is ERC 4337.

Let's get to where it all started. Before there ever is an ERC 4337, there was an EIP 4337. Here EIP stands for Ethereum Improvement Proposal, which describes standards for the Ethereum platform. An ERC is Ethereum Request for Comment, which is a distinct classification of EIP, encompassing modification that can impact the majority of Ethereum implementations. Every technical change in the Ethereum ecosystem gets introduced as an EIP, which upon acceptance and authorization by the on-chain governance model, becomes an ERC. As for ERC 4337, it was initially proposed as EIP 4337 in 2021 and got authorized to ERC standard in 2023. Its purpose — supercharge user accounts into smart accounts by means of account abstraction.

ERC 4337: Account Abstraction

Concept: turning wallet accounts into smart contracts with their own logic to determine what is a valid transaction

or as in Vitalik’s words :

“Instead of the EVM code being used only to implement the application logic, it will also be used to implement the validation logic of individual users’ wallets.” — Vitalik Buterin

Account abstraction proposes to decouple the signer(private key) from the account and bring smart contract functionality into wallets, enabling it to perform multiple tasks, handle MFAs, initiate and sustain crypto subscriptions, and many more, all via code. This just cracks open endless possibilities and amazing use cases for every Ethereum account.

A little bit of history. There had been several other proposals all aiming to implement a similar if not the same functionality :

EIP 86 (2016) - introduces ‘forwarding contract’ to abstract signature, verification and nonce
EIP 2938 (2020) - allowing smart contracts to function as top-level accounts (EOAs)
EIP 3074 (2020) - improve the efficiency of execution of smart contracts through new opcodes

All these EIPs have, on some level, required making changes to the consensus layer of Ethereum, until we have EIP 4337.

https://twitter.com/ProbablyNoam/status/1648080101932937218?s=20

The WHY - reasons why ERC 4337 is needed

ERC 4337 essentially wants Ethereum wallet users to ditch wallets, onboard to smart accounts and enjoy the bank-like experience. Further, it also enables the possibility to :

eliminate the reliance on seed-phrases
simplify and enhance the user onboarding experience
reduce the chance of human errors by transferring specific functionalities to smart contract
easy implementation on EVM-supported chains
compatibility with future upgrades (quantum resistance, BLS scheme)

The HOW - how transactions happen!

Stage_01: ERC 4337 circumvents consensus layer changes by introducing a higher-layer pseudo-transaction object called UserOperation, which could be considered a package encompassing the user’s intent, their signature and further data for verification. These objects are like unconfirmed transactions.

Stage_02: Users can send UserOperation objects to an alternate mempool, which is like a waiting pool for ERC 4337 powered transactions (different from the standard mempool) until it gets picked up by Bundlers.

Stage_03: Bundlers are the validators who move the transaction forward and earn incentives for doing so. Bundlers would bundle up these objects into a single ‘bundle transaction’, which is then delivered to a globally available singleton ‘Entry Point’ smart contract

Stage_04: The Entry Point smart contract serves as a security gate for the execution of these transactions. The EntryPoint’s handleOps function presides over the verification and execution loop of each transaction.The handleOps makes an arbitrary call validateUserOp with the UserOperation input, to the wallet smart contract. If the wallet smart contract does not exist yet, the initial call would create a wallet smart contract for the user wrt to the data(init) from UserOperation object. If the validation is successful, handleOps would call the wallet smart contract account with calldata from the UserOperation object.

Stage_05: The wallet smart contract account would implement the Execute function to execute the task as requested in the UserOperation object. It’s up to the account to choose how to parse the calldata.

ERC 4337 transaction flow | Ref-link

The GOALS -promises of ERC 4337

Some of the targets that ERC 4337 aims to achieve include :

Account abstraction: enabling smart contract functionality to wallet accounts
Decentralization: allowing anyone to participate and earn incentives as a bundler in the transaction flow
Avoid consensus changes: eliminating the need for consensus changes by introducing higher-layer pseudo-transaction objects and thus focusing on scalability upgrades
Saving time and gas: by bundling of UserOperations into a package, bundlers can save time and gas amount.

The USE CASES - applications of ERC 4337

Account recovery: through a special implementation called ‘Group Access’, ERC 4337 allows users who lost their seed phrase to reach out to previously designated guardians for retrieving access to the account.
Pre-approved transactions: the wallet smart contract can be programmed to pre-approve specific transactions across sessions.
Paymasters - sponsored transactions: Paymasters - a specific implementation, allows gas fees to be extracted from a different address, during transaction execution
Gas abstraction: by paying gas from our wallet smart contract, AA functionality allows us to pay gas in any ERC 20 tokens. On top of that, adopting the services of Paymasters would enable users to pay gas fees even in fiat.
Subscriptions: the wallet smart contract can be programmed to enable periodic spending and subscribing to particular web3 services
Multifactor authentication: users can place specific guardrails, by customizing the wallet smart contract. This would mean, users can even go ahead to use their fingerprint scan and face IDs are MFAs, as the wallet code works seamlessly with mobile devices as well.
Custom spending and usage limit: the wallets can be programmed to notify the user if any subscription/transaction is requesting amounts more than a set limit.

https://twitter.com/erc4337/status/1631087958949531648?s=20

Account abstraction, although initially confusing, involves abstracting accounts from the network rather than the users themselves. Users still utilize wallets, but these wallets have become significantly smarter with the inclusion of smart contract functionality. This opens up a realm of possibilities for developers to redefine and enhance the concept of wallets as we know them today. However, achieving this extended functionality without modifying the consensus has been a subject of extensive debate. Fortunately, we have now reached a stage where this remarkable idea has been successfully implemented on the Ethereum mainnet and various other EVM-supported chains like Polygon, Optimism, Arbitrum, BNB Smart Chain, Avalanche, and Gnosis Chain. The ongoing experiments and research conducted by platforms such as StarkNet and ZKSync, among others, further fuel excitement as they explore and expand the use cases of smart contract wallets. The adoption of this concept by these platforms signifies a promising and rewarding future for the crypto ecosystem.

/footnote: published for Alchemy