The Way to Web3 #4, Ethereum wallets tomorrow and ERC-4337

September 20th, 2022

Account abstraction is an extremely powerful solution to give web3 application great UX, I wish this article can give you a better insights about it!

The beginning of the story

The user experience of mainstream Ethereum wallets (i mean EOA) today is very poor, all of the following smart functionalities can only be done with smart contract wallets (some off-chain solutions can offer more convenience but with more external risks, we don’t cover them in this article)

No need to remember the private key and backup phrase & Social recovery(e.g. Argent, Unipass)
Batch transactions (e.g. Safe)
The key solution for a fully on-chain game (Session Key)

Fortunately, we are very close to a general applicable smart contract standard, which means users can have a 100x better Ethereum wallet experience soon!

Smart Contract Wallet, Account Abstraction, and ERC-4337

Smart Contract Wallet is one of two types of wallets on Ethereum, another type is Externally Owned Account (EOA).

As the name said, the magic behind great features is from smart contracts:

Smart Contract accounts are controlled by their code. And within the code, you can deploy arbitrary logic.
As compared, EOA wallets (most of your familiar wallets are this type, e.g. metamask) are addresses on the blockchain controlled by a private key. With the private key, you can sign transactions from said address. But the key is **the account: you can’t authorize another key to sign for a given address and you can’t code custom logic on top of it. Governance and spending logic have to be implemented outside of the blockchain.
It’s important to understand that smart contracts can be programmed to behave exactly like EOAs (only one signing key, no upgradability, etc.) but the opposite is not true.

Account Abstraction (explanation of Abstraction in computer science) is the process of making all Ethereum accounts nearly indistinguishable, effectively removing the need for EOAs and special handling for smart contract wallets, but offering all of the great features mentioned before or even more!

ERC-4337 is one way to achieve enhanced user experience in Ethereum. (you can also call it account abstraction):

Give standard EOA functionality to smart contract wallets. (ERC-4337**,** Available recently)
Give EOA wallets smart functionality. (EIP-3074, long-term plan in EVM / almost done in Starkware/zksync)

Comparison between EOA, Current Smart Contract Wallet, and ERC-4337 frameworks

(if don’t want to go deep into technical part, you can jump to the benefits of ERC-4337 directly)

Dividing lines divide evey framework into three parts: User signs, Intermediate part（before miner broadcast）, and Final Execution（after miner broadcast）. Hope this can make it easier to understand.

Some assistive interpretation:

EOA（e.g. Metamask）

To execute transactions, users use their private key to sign them with a standard ECDSA signature and then send them to the Ethereum network for miners to include in a block.

Current smart contract wallet:

The biggest difference between EOA and this design is: For some network security concerns and better UX needs, current smart contract wallet design needs an external relayer to send the user’s message to the final smart contract wallet.

Current solutions on Ethereum Layer1 like Safe or Argent are designed with a similar framework ‘Current Smart Contract Wallet’. Among them, there’s no standard for smart contract wallets to operate on, so each project has to take on the effort of creating and managing its own relayer service, as well as managing the fee mechanism and auditing their complex smart contracts.

ERC-4337

The biggest differences between current smart contract wallet and ERC-4337 frameworks are:

Establishing user-operation mempool and bundler to replace the non-generic relayer service.
Add an Entry Point Smart Contract to smooth the creating new wallet process and user’s message validation process.

ERC-4337 achieves account abstraction by replicating the functionality of the transactions mempool in a higher-level system. Compared with current smart contract wallets, ERC-4337 uses a public and standard module——UserOperation Mempool and Bundler to replace the relayer:

Instead of transactions, users send UserOperation objects to Ethereum bundlers, and they package a set of these objects into a single bundle transaction that gets included in the Ethereum chain.

Also, these bundle transactions are handled by an “Entry point” contract that handles the deployment of the user’s wallets and takes care of User Operation object verification by querying the deployed wallet.The UserOperation is ultimately handled by the smart contract wallet the user chooses, given that it includes the necessary logic to interact with EntryPoint.

The benefits of ERC-4337 when compared with the current smart contract wallet:

No need to operate a relayer for every individual smart contract wallet.
Great smart functionalities could be universal, no need to reinvent the wheel.
User’s cost can be lower through bundler’s bundling.

How far are we from standard smart contract wallet?

Within EVM chains

(Great helps from @ERC4337)

The answer is Soon. The main contracts are almost ready, and several great teams are close to releasing production-grade ERC-4337 native client wallet!

To deploy ERC-4337——a universal standard for the whole EVM eco-system, several main modules need to be developed(as redpoints showed above):

① Production Grade ERC-4337 Native Client Wallet

While the ERC-4337 does not specify a signature scheme, dapps relying on MetaMask to use an ERC-191 or ERC-712 signature for the UserOperation is not an optimal user experience. Market needs the Client Wallets to support Proxy Wallet addresses and their UserOperation transactions natively with a dedicated standard signature scheme.

Implementations:

② UserOperation Block Builder Bundler

The main mode of operation for ERC-4337 network requires at least some share of network Block Builders (Miners, Validators, Sequencers etc.) to natively support UserOps into their public P2P mempool and using those UserOps to create a bundle and include an EntryPoint transaction in the block.

Implementations:

③ EntryPoint Smart Contract

The main contract of the ERC-4337.

Implementations:

④ Production Grade ERC-4337 ECDSA Proxy Wallet Smart Contract

The main mode of operation for ERC-4337 assumes each user will get their identity represented by a Proxy Wallet. This means that having a secure implementation for such wallet is critical. This also implies that we must guarantee that users’ Proxy Wallet addresses will be deterministic and consistent across networks, same as with EOAs.

Implementations:

⑤ ERC-4337 Client SDK

This part aims to make the integration of ERC-4337 into various wallets and dapps to be as simple as possible, e.g. reuse MetaMask, while still benefiting from ERC-4337.

Implementations:

⑥⑦⑧⑨… Social Recovery, Paymaster, and all smart functionalities you can imagin

These are not necessary parts of a ERC-4337 wallet, but the value of ERC-4337 wallet depends on it.

Implementations:

Within No-EVM layer2 (e.g. starknet)

I don’t want to cover a lot about this part, since it’s not the focus today.

The answer is sooner than EVM chain 😎. Until now, developer can already code with it in testnet, and many great functionalities has come into production grade.

As a non- EVM equivalence blockchain(e.g. Starkware), it can deploy account abstraction easier with some modifications on the protocol level (compared to Ethereum and 100% EVM equivalence chains).

Basic transaction flow of Account Abstraction on StarkNet

Until now, the basic flow of account abstraction is very close to a final production grade while Starkware release StarkNet Alpha 0.10.0 with Account Abstraction Improvements (In spirit of ERC-4337)

Some great things has already happened during DevConnect StarkNet hackathon

Session key: By creating a one-time signing key stored in the browser a user only has to sign once during a game session.This removes the need for the player to sign repeat transactions. (By Briq & Realms)
Dead man’s Switch: It allows trusted accounts to access the assets in your wallet in case your wallet has not been used for a long period of time. You decide who gets your inheritance and how much much time has to elapse before the dead man's switch triggers. (By deadman)
Multisig for Guild: Mechanisms within it allow token owners to benefit from sharing their NFTs securely and use others within the guild even if they do not hold them by using a role-based system with permissive controlled token usage.(By Guildly)

Product Form and Value Capture

Product Form: finally, it might be totally different from what we have seen now

Recall the previous information, the main contracts of ERC-4337 and even the wallet Client SDK are open-sourced, it will be very easy to make a basic wallet under account abstraction. Then, there are already many great smart functionalities under the same standard, and will be more and more.

Then, the product form should be like this: Anyone could build a front-end on top of a hypothetical plugin registry to help users choose which plugins they’d like to use, and showcase which are currently being used. (I’m not a PM or Design, pls be kind if the sample looks are not pretty)

Value Capture: we need to address the charging model for public goods

If the basic interface gonna become an underline infrastructure, and most of the smart functionalities will be open-sourced, then, how to capture the value?

We can still charge the swap fee.
But if there no incentives on smart functionalities, nobody would invent and operate new & good smart functionalities. And those are the most valuable parts of such a great wallet solution.
People might need to get used to pay-per-use for public goods.

Final thoughts

As i mentioned at the beginning of this article, account abstraction is really powerful to make Web3 mainstream, and hope you can have a better understanding about it.

Although many practical limitations are still there, like plenty of dapps out there that don't support EIP-1271(which means smart contract wallets can’t sign with those dapps), and it can’t fit multi-chain scenarios. But just like L2 is the future of Ethereum, I believe that Account Abstraction is the future of Ethereum Wallet!

I also encourage you to try MPC wallets in multi-chain use-case, it should be one of the best methods in the near future. If you have any idea about cross-chain account abstraction-based wallet, pls DM me!

Special thanks for @沙漏时间 @cejay @kristofgazso help on building this.

Email: t@capitalant.com; Twitter: @toddz_crypto