Evolution of Ethereum Wallets: Account Abstraction and the Opportunities and Challenges of ERC-4337

Summary:

The future wallet model is more likely to be a B2B2C model. While the wallet exists as a C-end product, it is more important to provide a set of mature SDK solutions for other applications to be integrated as in-app wallets, and then for C-end users. Among them, the packer and aggregator were mainly built in a centralized way in the early stage, and it is possible to form a modular network later, but since this is the core of value capture, the wallet uses a packer network built by others to go through a game of economic benefits .

With the continuous expansion and extension of Ethereum application scenarios, the disadvantages of the Externally Owned Accounts (EOA) scheme of traditional Ethereum wallets are gradually revealed. Its functions are simple and its performance is average. problem. The smart contract wallet uses contract accounts (Contract Accounts, CA) as the wallet address. It is a relatively new Ethereum wallet solution, which can solve the shortcomings of the EOA wallet and bring more powerful functions. In the future, you will be able to choose not to carefully protect your private key, and you will be able to enjoy almost the same level of security; you can also enjoy the convenience of the current centralized exchange in the decentralized exchange, but At the same time, the funds are always in their own hands, so there is no need to worry about the possibility of a thunderstorm on the exchange...

In the new version of the Ethereum roadmap released some time ago, the account abstraction smart contract specification ERC-4337 was written into The Splurge as a key element for EOA wallets to smart contract wallets. So, what exactly is a smart contract wallet, and what is the relationship between account abstraction and smart contract wallet, how are they realized, what is their future development form, and what opportunities and challenges exist?

Ethereum Account Types

There are two types of accounts in Ethereum: Externally Owned Accounts (EOA) and Contract Accounts (CA). The external account is the wallet account address that Ethereum originally records the user's balance. The contract account was not originally designed to record the balance of the user's wallet address.

external account

EOA is a concept unique to Ethereum and other EVM-compatible chains (or EVM-like chains). Strictly speaking, mainstream non-EVM chains including BTC do not have this setting. Metamask wallets use external accounts. This type of wallet is also called "EOA wallet" and is controlled by the user's private key. The generation rules are:

Private key → public key → Keccak256 hash → last 20 Bytes → hexadecimal string (EOA address)

This generation rule is completely transformed by mathematics, and this address does not correspond to any smart contract. When using this type of address for transactions, the node verification rules are:

Transaction signature → ec_recover → public key → (generated with the above rules) address → compare the address to be operated

If the verification is passed, the subsequent process will continue, and if it is not passed, the transaction will be rejected. The core setting of EOA in Ethereum is to act as the initiator of the transaction and pay gas, that is, the trigger of the transaction. No matter how many contract calls are made in the future, a transaction must be initiated by an EOA at the beginning and pay enough gas to proceed. The transaction flow of an EOA address is shown in the figure below.

Simplified EOA transaction mechanism Source: Nethermind

Problems with external accounts

At present, the EOA account is the absolute mainstream wallet form for users to use the wallet type. The Ethereum community has expressed a number of concerns about the EOA, including:

• Key management: The only way to obtain funds is to know the private key. The biggest problem is the single point of failure. For users, the private key is the asset. For users, once the private key is lost or stolen, it means asset loss.
• Rely on ECDSA signatures: Simpler and quantum-resistant tax signatures are a clear improvement over current ECDSA.
• Transactions are one-to-one with operations: not being able to execute more than one at a time creates unnecessary cost and a poor user experience.

With the continuous expansion of blockchain application scenarios, users manage not only their own on-chain assets on the blockchain, but also on-chain identities, social relationships, and even on-chain credits. At present, most of these contents are simply mapped to pseudo-anonymous individuals through wallets. Not only are users struggling with the mnemonic-based EOA wallet private key management solution, but the application is also used in many applications due to the simplicity of the EOA wallet. The scene is limited.

There are many wallet solutions trying to solve these problems:

• Around the single point of failure, the MPC wallet provides a better private key management solution by using the threshold signature scheme (TSS), while the smart contract wallet can solve this problem through social recovery, multi-signature and other solutions.
• Better user experience, more powerful functions and scalability, such as batch transactions, custom verification logic, etc., are mainly brought by smart contract wallets.

MPC wallets and smart contract wallets are not completely independent solutions. Smart contract wallets can also use MPC+TSS technology to manage smart contract wallets. Unipass is a good example.

Note: MPC wallet refers to a wallet using multi-party secure computing technology, which is equivalent to hiring M housekeepers for your asset vault, each of which cannot open the vault independently, and using the threshold signature scheme (TSS) is equivalent to giving Your vault is set with a lock that requires N keys to open, then the MPC + TSS wallet solution is equivalent to providing a multi-role vault management solution. N of the M housekeepers need to provide the keys they manage at the same time. Able to open the vault.

contract account

CA is an Ethereum account with internal logic, which can be either business logic (Token contract is used for bookkeeping, pledge contract is used for lending and liquidation), or account logic (such as the multi-signature logic of gnosis safe), and the latter is Smart Contract Wallet/Account (SCW). The Argent wallet uses a smart contract wallet, which creates a model of social recovery. The contract is controlled by the internal logic code, and its generation rules include CREATE and CREATE2, which will not be expanded here.

Different from EOA, there is no necessary correspondence between CA and public key. For example, the CA created by gnosis safe can set any number of public keys to unlock the assets corresponding to its address; of course, the CA can also not set any keys, but the logic of other CAs determines whether it can be unlocked, such as the DeFi loan contract , As long as the money is repaid, the pledged assets can be retrieved.

All assets on Ethereum except ETH are carried by CA, and business logic such as DeFi is all realized by CA. However, CA's inability to take the initiative to operate and pay gas also limits its ability. As early as 2016, there was a proposal to allow CA to pay gas itself.

Smart contract wallet transaction source: Nethermind

Since the transaction can only start from the EOA, in order to improve the user experience, usually the smart contract wallet will provide a relay (Relayer) service, obtain the signed message from the user and submit it to the chain from the service provider's EOA, and its custom fee mechanism can Returning ETH to the user's EOA wallet is free of Gas fees.

Currently, there is no operating standard for smart contract wallets (EIP-4337 is expected to be a standard), so every project must use a meta-transaction solution like the Ethereum Gas Station Network (GSN), or strive to Create and manage your own relay services, as well as manage fee mechanisms and audit their complex smart contracts.

Smart Contract Wallet

As the name suggests, Smart Contract Wallet/Account (SCW) is a wallet solution that uses CA as the address. Signatures, rights management, offline authorization and social recovery, and more.

A contract account is a smart contract separate from the signer (authorizer), which can have its own signing and recovery logic. This means that if you lose access to Signer, it doesn't necessarily mean you lose access to your account. Again, this is where the name Account Abstraction comes from. Accounts are abstracted from signers.

account abstraction

The current status of Ethereum is that the vast majority of people are using EOA wallets, because currently all transactions in Ethereum must start with EOA, and EOA must have some ETH to pay for gas, which makes it impossible for new users to quickly enter. We need a solution that allows users to use smart contract wallets that contain arbitrary verification logic. This solution is called Account Abstract (AA). In simple terms, the account abstraction results in:

• In the past, you stored money in the Ethereum EOA wallet address, and enjoyed the simplicity and convenience of owning assets with a private key while being restricted by various EOA addresses;
• Now you store money on the Ethereum smart contract address, you can control your wallet assets by not managing the private key, the separation of the signer and the account itself allows you to conduct transactions at a lower security level, and will The account itself is placed at a higher security level.

The goal of "account abstraction" is to reduce the number of account types from 2 (EOA and contract) to 1 (only contract), and move functions such as signature verification, gas payment and replay attack protection from the core protocol to the EVM . For a long time, the realization of account abstraction has been the direction of efforts of many Ethereum developers, which can be seen from the history of EIP.

EIP History

The concept of account abstraction was first proposed by Vitalik in 2016, and he initiated the first proposal in 2017. Over the years, there have been many proposals related to account abstraction, among which the most important solutions are EIP-3074 and EIP-4337. EIP-3074 was proposed a year earlier than EIP-4337, but EIP-4337 was included in the new version of Ethereum's roadmap. The main reason is that the implementation of EIP-4337 is lighter and does not need to modify the core of Ethereum. protocol, and there is no security risk like EIP-3074. However, EIP-4337 has the problems of user migration, excessive gas, and potential smart contract security issues, which are common problems of smart contract wallets. Vitalik believes that the best realistic way to account abstraction is to support ERC-4337 in the short term, and then follow the EIP was added over time to compensate for its weaknesses.

Account abstraction EIP history

EIP-86 : In 2017, Vitalik proposed EIP-86, trying to introduce a smart contract wallet that can be regarded as a "forwarding contract". These forwarding contracts will only accept transactions from "entry point" addresses, from which anyone can send transactions as long as the transactions follow a specific format.

EIP-1014 : These forwarding contracts will be deployed to a specific address based on their code, introducing the idea that later evolved into EIP-1014, which proposed the CREATE2 opcode. EIP-86 was not merged because it required major changes to the protocol, while EIP-1014 was merged in 2018.

EIP-2938 : In September 2020, Vitalik Buterin, Ansgar Dietrichs, and Matt Garnett proposed EIP-2938, which requires that special smart contracts identified as smart contract wallets will only accept account abstract transactions. This new type of transaction is supported by EIP- Introduced in 2718 . They will programmatically set the transaction's maximum gas and implement arbitrary validation methods. EIP-2938 requires two new opcodes to be added to the EVM to make transactions feasible. These opcodes significantly change the core protocol, and the process of including such changes can be lengthy.

EIP-3074 : In October 2020, Ansgar Dietrichs and Matt Garnett et al proposed EIP-3074, which introduced two new opcodes: AUTH and AUTHCALL. When used together, they allow smart contracts to send transactions on behalf of the EOA, which enables things like multisig, batch and sponsored transactions, key recovery, and more accessible CeFi exchange deposits. However, the EIP has some security risks and has received some criticism . The new opcode will also modify the core protocol. Researchers began to think about a better solution, which was eventually proposed as EIP-4337.

EIP-3074 Transaction Flow Source: Nethermind

Layer 2: Later, since L2 does not have the technical debt of Ethereum L1, account abstraction can be introduced out of the box. Both Optimism and Starknet have their own implementation of account abstraction. ArgentX is Argent’s version of the wallet on Starknet, using it inspired by EIP-4337 A custom account abstraction implementation. The most recent example is Visa Crypto Auto Payments on StarkNet , Visa's Ethereum automated payment solution is to use the account abstraction concept and create a new type of account contract-delegable account, the main idea is to extend the programmable validity rules of transactions to include Pre-approved allow list. In simple terms, the account abstraction can delegate the automatic payment operation initiated by the user account to the pre-approved automatic payment smart contract. StarkNet's account model is what Visa is currently calling an account abstraction, with an implementation inspired by ERC-4337 , where an account abstraction checks whether a transaction originates from a given address.

Visa Implements Account Abstraction on StarkNet

EIP-4337 : In September 2021, Vitalik Buterin, together with Ethereum researchers from OpenGSN and Nethermind, drew lessons from previous efforts and proposed EIP-4337 . EIP-4337 adds a new UserOperation mempool hoping to completely replace the current transaction mempool to enable account abstraction. Instead of transactions, users send UserOperation objects to Ethereum nodes, they package a set of these objects into a transaction that is included in the Ethereum chain. This wrapped transaction is called the " entry point " smart contract, which processes the UserOperation object and deploys the smart contract wallet for it.

ERC-4337 transaction process source: Nethermind

EIP-5003 : In March 2022, Dan Finlay and Sam Wilson proposed EIP-5003, hoping to allow migration from ECDSA by deploying code instead of external accounts. This EIP introduces a new opcode that authorizes the deployment of code at address AUTHUSURP in EIP-3074 . For externally owned accounts (EOAs), together with EIP-3607 , this effectively revokes the original signing key's authority. This is in addition to EIP-3074, which could only grant additional participant permissions, but not revoke them.

EIP-5792 : In October 2022, Moody Salem proposed EIP-5792, which adds JSON-RPC methods for sending multiple function calls from user wallets and checking their status. The new approach is more abstract in terms of underlying transactions than the existing transaction sending API to allow for differences between wallet implementations, such as smart contract wallets using EIP-4337 or EOA wallets that support bundled transactions via EIP-3074. Dapps can use this more abstract interface to support different types of wallets without extra work and provide a better user experience for sending function call packets (e.g. EIP-20 #approve followed by a contract call).

EIP-4337 Detailed Explanation

In EIP-4337, there are a total of 6 components: entry point contract (EntryPoint contract), cashier contract (Paymaster contract), user operation (UserOperation), packager (Bundler), sender contract (Sender Contract) and aggregator ( Aggregator).

• EntryPoint: The entry point contract handles the execution and validation of transaction operations passed to it. The global entry point contract receives packaged transactions from various Bundlers and runs a validation and execution loop through each UserOperations.
• Paymaster: This is an optional contract that pays gas for transactions on behalf of users. Instead of relying on their wallets, users can earn transaction fees sponsored by tellers.
• UserOperations: These are transaction objects created to perform transactions on behalf of users. Execution occurs after Sender Contract confirmation. These actions are generated by Dapps.
• Bundlers: Bundler fetches UserOperations from memory pool and bundles them together to send them to EntryPoint contract for execution.
• Sender Contract: These are user wallet accounts in the form of smart contracts.
• Aggregator: The aggregator is an auxiliary contract trusted by the wallet to verify the aggregated signature.

The operating logic of the entire ERC-4337 standard includes two cycles: the execution cycle of the verification cycle, and they are combined to complete the account abstraction logic.

Validation cycle: The entry point contract goes through each UserOperation and calls the "check function" in the Sender Contract. The Sender Contract runs this function to check the UserOperation's signature and compensates the Bunder that wraps those transactions.

Execution loop: Send the call data in each UserOperation to Sender Contract. The wallet runs the execute action to execute the transaction specified in the action. Sender Contract will then refund the remaining gas after the operation has been performed.

Validation Loop and Execution Loop Source: EIP-4337

The introduced teller role allows app developers to subsidize fees for their users. When the paymaster is not equal to the zero address, the entry point performs a different flow:

Introduce teller's validation loop and execution loop Source: EIP-4337

In the verification cycle, in addition to calling the "check function", the entry point contract must also check whether the paymaster is pledged, and there is enough ETH deposited in the entry point contract to pay the operation fee, and then call the "check function" on the paymaster to Check if paymaster is willing to pay.

In the execution loop, the entry point contract must call the Post- OP on paymaster after the main execution call. It must guarantee the execution of the Post- OP by doing the main execution in the internal calling environment, and if the internal calling environment rolls back, try to call the Post- OP again in the external calling environment (even if the user operation rolls back, the gas should be paid cost).

Vitalik concluded that ERC-4337 can do many things as a purely voluntary ERC. However, it is weaker than true in-protocol solutions in a few key areas:

1. User migration issues where existing users cannot upgrade without moving all their assets and activities to the new account;
2. Additional gas overhead (basic UserOperation user operation is about 42k, while basic transaction is about 21k);
3. Smart contract security issues, which benefit less from in-protocol censorship-resistant technologies (such as crLists), which target transactions and ignore user operations

A realistic path to achieve the best results is to start with strong support for ERC-4337 in the short term, and then add EIPs over time to compensate for its weaknesses. This does not necessarily require everyone to specifically commit to complying with ERC-4337. Instead, in-protocol support can be designed to be more general and support ERC-4337 and its alternatives and improvements. Currently, ERC-4337 implementations include Biconomy, Soul Wallet, and ETH-infinitism, all of which have written their own implementations of entry point contracts, and entry point contracts are the core of smart contract security under this standard.

Vitalik proposed a possible roadmap for account abstraction.

possible roadmap

short term

1. Put ERC-4337 into full production. Ideally, this could be extended with a signature aggregation function for Rollup friendliness.
2. There should be an easy-to-use browser wallet that interfaces with ERC-4337.
3. Consider implementing signature aggregation and compression to make ERC-4337 more L2-friendly;
4. Guide the ERC-4337 ecology in the L2 protocol, where the gas cost problem will be less;

mid term

1. Implement Verkle tree, add EIP to reduce gas cost;
2. Add optional EOA-to-ERC-4337 conversion;
3. Add crList logic at the same time as or shortly after Proposer/Builder Separation (PBS) rolls out;

long

Consider forcing transitions, performing irregular state transitions, deploying bytecode to every account that might be an EOA, but this approach has the disadvantage of requiring core protocol modifications and being costly for miners/validators.

project scan

SevenX conducted a simple scan of the smart contract wallets on the market, and collected and sorted out some mainstream smart contract wallet projects on the market. The overall situation is as follows:

We selected two projects for case introduction, and analyzed their functions and corresponding implementation principles. Among them, Unipass is a typical representative of traditional smart contract wallets, and Candide Wallet is a typical representative of wallets using the ERC-4337 standard. They have rich public documents and explain their product function implementation in detail.

Implementation Case——Unipass

UniPass Wallet is a smart contract wallet solution that supports email social recovery. Through UniPass Wallet, developers can provide a smooth private key-free and gas-free user experience in the product, thereby quickly attracting a large number of Web2 users. Its features are: free private key, anti-censorship, free gas, email recovery, privacy protection, multi-platform and support for multi-chain.

The features of free private key, anti-censorship, email recovery and privacy protection are mainly brought by Unipass' key management scheme. The contract account of UniPass Wallet supports users to set various types of keys. Already supported key types include:

1. The external address we often use is a contract account that supports the EIP-1271 protocol (a standard signature verification method for a contract).
2. UniPass users can also use their email address as a key. The smart contract we deploy on the chain can cryptographically verify the user's ownership of an Internet mailbox through DKIM ( Domain Key Identified Mail ). During the verification process, UniPass uses zero-knowledge proof technology to ensure the privacy and security of user email information.
3. In the future, UniPass Wallet will also consider supporting signature algorithms that are more efficient and concise than secp256k1 (such as: Schnorr, BLS), post-quantum security signature algorithms (such as: Lamport, Winternitz), etc.

The secret key has three main roles:

1. Owner is the owner of the account. Owner controls core functions such as account deployment, upgrade, and destruction, and is the highest authority controller of the account.
2. Operator is the executor of account assets. Operator is responsible for asset transfer, contract call, authorization and other functions of the account, and is the key for users' daily use.
3. Guardian is the guardian of the account. When the key in the account is damaged or lost, and the user loses control of the account, the account can be recovered through the guardian. One of the unique features provided by UniPass is: on-chain email social recovery.

In the smart contract of UniPass Wallet, users manage their accounts through a series of keys with role weights. In addition to the Master key implemented in a secure multi-party computation (MPC) scheme, users can also set a variety of other types of keys. Each key has a corresponding role and weight. The user can obtain the authorization of the role only after collecting the keys whose total role weight threshold exceeds the requirement.

A key can be assigned single or multiple roles. When a key is assigned to a certain role, the corresponding weight will be set at the same time. When a user wants to perform operations related to a certain identity, he needs to sign with a single or multiple keys whose total weight of the role reaches 100 or more. For example, when initially registering for an account, users can skip Guardian setup. The relevant parameters can be set as follows:

The gas-free feature is realized through a third-party relayer. When a user initiates a transaction, the relayer is needed to help the user initiate the transaction. In this process, the relayer can support users to use any token to pay for gas, and even completely help users to pay for gas to achieve a gas-free experience. Relayer is an open source server program. UniPass will run the default relayer, and partners or any third party can also run the relayer.

Implementation Case——Candide

CANDIDE is a group of contributors who openly collaborate to build a public product where no single entity or company controls its development. Candide Wallet Beta is a self-hosted mobile smart contract wallet. It is currently deployed on the Goerli testnet. It is now available on Android Test and IOS Testflight.

The technical basis of Candide Beta is the forked ERC-4337 implementation of Stackup and the open source framework of Gnosis Safe. Its features include no mnemonic, social recovery, batch transactions, and free gas fees.

Among them, the implementation logic of features such as no mnemonic, batch transactions, and gas fee-free is the same as that of ERC-4337, and the entry point contract developed by ETH-infinitism is used to complete. Candide runs its own packager to package UserOperation as a service of its own wallet. In this scheme, most of the security depends on the entry point contract, rather than the construction of the wallet itself.

Additionally, the social recovery feature comes from Candide's use of Safe for its base wallet contract. This allows Candide to utilize the most trusted DAO contracts to manage digital tokens. Candide will use the Gnosis Safe modular design to deliver its core functionality, including social recovery, as well as future features such as time locks and withdrawal limits. The logic of this social recovery module is the same as that of Unipass, the difference is that Unipass is mainly for mail recovery, but the guardian of Candide can be any signer with a public address, such as family, friends, institutions and hardware wallets.

Thoughts on Contract Wallet

Early smart contract wallets were developed for contracts based on very specific problems, such as Gnosis Safe's multi-sig and Argent's social recovery functions. The designs of these early products were complex, often not open and transparent, and did not form a unified standard, so it was difficult to insert them into other applications as middleware. For this type of product, the judgment criteria need to start from the usage scenario, whether it has captured the core needs of users, for example, Safe’s multi-signature function has captured one of the core needs of users.

With the birth of ERC-4337, it has become very convenient to quickly build a wallet with no mnemonic, batch transactions, and no gas fee. The unified standard also makes the development kit based on this standard composable and can be used as an intermediate components into different applications and maintain interoperability.

Therefore, it is very important to be ERC-4337 compatible when considering early smart wallet solutions. As for ERC-4337-based solutions, since most of the technologies are open source, the considerations are suggested around the following points:

1. Technology: the construction scheme of entry point contract, packer and aggregator (if any), and the construction scheme of functions other than those brought by ERC-4337, such as social recovery function;
2. Operation: how to build a community, market and win users;
3. Experience: Whether the user experience of using the wallet is good enough, such as smooth, stable, etc.;
4. And the main investigation logic of some other to C products.

The future wallet model is more likely to be a B2B2C model. While the wallet exists as a C-end product, it is more important to provide a set of mature SDK solutions for other applications to be integrated as in-app wallets, and then for C-end users. Among them, the packer and aggregator were mainly built in a centralized way in the early stage, and it is possible to form a modular network later, but since this is the core of value capture, the wallet uses a packer network built by others to go through a game of economic benefits .