The Revolution of Ethereum Wallet: Account Abstraction and ERC-4337 Opportunities and Challenges

Original author: Yuxing, SevenX Ventures

This article is for learning and communication purposes only and does not constitute any investment reference.

With the continuous expansion and extension of Ethereum application scenarios, the disadvantages of the traditional Ethereum wallets Externally Owned Accounts (EOA) solution are gradually revealed. Its functions are simple and its performance is average, it does not support concurrent transactions, and there are key management problems. problem. The smart contract wallet uses Contract Accounts (CA) as the wallet address. It is a relatively new Ethereum wallet solution that 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 keys and enjoy almost the same level of security; you can also enjoy the convenience of current centralized exchanges in decentralized exchanges, but At the same time, the funds are always in your own hands, so you don’t have to worry about the possibility of thunderstorms 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 switch to smart contract wallets. So, what exactly is a smart contract wallet, and what is the relationship between account abstraction and smart contract wallets, how are they implemented, what is its future development form, and what are the opportunities and challenges?

Ethereum account types

Ethereum has two types of accounts: Externally Owned Accounts (EOA) and Contract Accounts (CA). External accounts are Ethereums native wallet account addresses that record user balances. Contract accounts were not initially designed to record user wallet address balances.

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 wallet uses external accounts. This type of wallet is also called EOA wallet and is controlled by the users private key. Its generation rules are:
Private key → Public key → Keccak 256 Hash → Last 20 Bytes → Hex string (EOA address)

This generation rule is completely derived from mathematical transformation, 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 using the above rules) address → Compare the address to be operated

If the verification passes, continue the subsequent process, otherwise 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 follow a transaction, it must be initiated by an EOA at the beginning and enough gas must be paid. conduct. The transaction process of an EOA address is shown in the figure below.

Simplified EOA trading mechanism Source: Nethermind

External account issues

Currently, EOA accounts are the absolutely mainstream wallet type used by users. The Ethereum community has expressed a number of concerns about 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 an asset. For users, once the private key is lost or stolen, it means a loss of assets.
• Reliance on ECDSA signatures: Simpler and quantum-resistant digital signatures are a clear improvement over current ECDSA.
• Transactions are one-to-one with operations: not being able to perform multiple operations at once 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, etc. 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 also applications are in many applications due to the simplicity of EOA wallets. The scene is limited.

There are many wallet solutions that try to solve these problems:
• Around single points 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 wallet and smart contract wallet 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 that uses multi-party secure computing technology. It is equivalent to hiring M stewards for your asset vault. Each steward cannot open the vault independently, and using the Threshold Signature Scheme (TSS) is equivalent to giving Your vault is set up 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 stewards among the M stewards need to provide the keys they manage at the same time. Ability to open vaults.

Contract account

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

Unlike 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 DeFi With a lending contract, you can get back the pledged assets as long as you repay the money.

All assets on Ethereum except ETH are carried by CA, and business logic such as DeFi is all implemented by CA. However, the setting that CA cannot actively operate and pay gas also limits its capabilities. As early as 2016,proposalHopefully, the CA will be able to pay for the gas itself.

Smart contract wallet transaction source: Nethermind

Since transactions can only start from EOA, in order to improve user experience, smart contract wallets usually provide relay services to obtain signed messages from users and submit the EOA from the service provider to the chain. Its custom fee mechanism can Returning ETH to the users EOA wallet realizes no gas fee.

Currently, there is no operating standard for smart contract wallets (EIP-4337 is expected to become a standard), so every project must use a meta-transaction solution like the Ethereum Gas Station Network (GSN), or work towards 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. It is characterized by internal logic. Smart contract wallets can implement many functions that EOA cannot achieve, such as gas payment, batch transactions, multiple Signatures, rights management, offline authorization, social recovery, and more.

A contract account is a smart contract separate from the signer (authorizer) and can have its own signing and recovery logic. This means that if you lose access to Signer, it does not necessarily mean that 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 enter quickly. We need a solution that allows users to use smart contract wallets that contain arbitrary verification logic. This solution is called Account Abstract (AA).

Simply put, the result of account abstraction is:

1. In the past, you stored money in the Ethereum EOA wallet address. While being restricted by various EOA addresses, you also enjoyed the simplicity and convenience of owning assets with the private key;

2. Now that you store money on an Ethereum smart contract address, you can control your wallet assets without managing private keys. The separation of the signer and the account itself allows you to perform transaction operations at a lower security level. 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 (contract only), and move functions such as signature verification, gas payment, and replay attack protection from the core protocol to the EVM . Implementing account abstraction has always been the endeavor of many Ethereum developers, as 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, the most important of which are EIP-3074 and EIP-4337. EIP-3074 was proposed one year earlier than EIP-4337, but EIP-4337 has been included in the new version of Ethereums roadmap. The main reason is that the implementation of EIP-4337 needs to be more lightweight and does not need to modify the core of Ethereum. protocol, and there are no security risks like EIP-3074. The user migration issues, excessive gas issues, and potential smart contract security issues in EIP-4337 are common problems for smart contract wallets. Vitalik believes that the best realistic way to account abstraction is to start vigorously supporting ERC-4337 in the short term, and then as the Over time EIP was added to compensate for its weaknesses.

Account Abstract EIP History

EIP-86: In 2017, Vitalik proposed EIP-86 in an attempt to introduce smart contract wallets that can be regarded as forwarding contracts. These forwarding contracts will only accept transactions from an entry point address, from which anyone can send transactions as long as they follow a specific format.

EIP-1014: These forwarding contracts would be deployed to a specific address based on their code, introducing the idea that later evolved into EIP-1014, which proposed the CREATE 2 opcode. Because EIP-86 required significant changes to the protocol, it was ultimately not merged, 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- 2718 introduced. They will programmatically set the maximum gas for transactions and implement arbitrary verification methods. EIP-2938 Two new opcodes need to be added to the EVM to make transactions feasible. These opcodes significantly change the core protocol, and the process of incorporating such changes can be lengthy.

EIP-3074: In October 2020, Ansgar Dietrichs, Matt Garnett and others proposed EIP-3074, which introduced two new opcodes: AUTH and AUTHCALL. When used together, they allow smart contracts to send transactions on behalf of EOA, making possible, for example, multi-signatures, batched and sponsored transactions, key recovery, and more accessible deposits on CeFi exchanges. However, this EIP had some security risks and received some criticism. The new operation code would also modify the core protocol. Researchers began to think about a better solution, which was eventually proposed as EIP-4337.

EIP-3074 transaction process source: Nethermind

Layer 2: Subsequently, 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 account abstraction implementations. ArgentX is Argent’s wallet version on Starknet, using a version affected by EIP-4337 Inspired custom account abstraction implementation. The most recent example is Visa Crypto Auto Payments on StarkNet. Visas Ethereum automated payment solution leverages the account abstraction concept and creates a new type of account contract - a delegated account. The main idea is to extend the programmable validity rules of transactions to Includes pre-approved allow lists. Simply put, the account abstraction can delegate automatic payment operations initiated by user accounts to pre-approved automatic payment smart contracts. StarkNets account model is what Visa currently calls account abstraction. Its implementation is inspired by ERC-4337. The abstract account checks whether the transaction comes from a given address.

Visa implements account abstraction on StarkNet

EIP-4337: In September 2021, Vitalik Buterin and Ethereum researchers from OpenGSN and Nethermind learned from the lessons of previous efforts and proposed EIP-4337. EIP-4337 adds a new UserOperation memory pool in the hope of completely replacing the current transaction memory pool to achieve account abstraction. Users send UserOperation objects to Ethereum nodes, and instead of transactions, they package a set of these objects into a transaction that is included in the Ethereum chain. This packaged transaction is called an entry point smart contract, which handles the UserOperation object and deploys the smart contract wallet to it.

ERC-4337 transaction process source: Nethermind

EIP-5003: In March 2022, Dan Finlay, 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 deploys code at the EIP-3074 authorization address AUTHUSURP. For externally owned accounts (EOA), along with EIP-3607, this effectively revokes the permissions of the original signing key. This is in addition to EIP-3074, which can only grant additional participant permissions but cannot revoke them.

EIP-5792: In October 2022, Moody Salem proposed EIP-5792, which adds a JSON-RPC method for sending multiple function calls from the user wallet and checking its 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 supporting 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 packages (e.g. EIP-20 #approve followed by a contract call).

• EIP-4337 detailed explanation

In EIP-4337, there are a total of 6 components: EntryPoint contract, Paymaster contract, UserOperation, Bundler, Sender Contract and Aggregator ( Aggregator).

1. EntryPoint: The entry point contract handles the execution and verification of transaction operations passed to it. The global entry point contract receives packaged transactions from various Bundlers and runs validation and execution loops through each UserOperations.

2. Paymaster: This is an optional contract that can pay gas for transactions on behalf of the user. Instead of relying on their wallets, users receive transaction fees sponsored by the teller.

3. UserOperations: These are transaction objects created to perform transactions on behalf of users. Execution occurs after Sender Contract confirmation. These operations are generated by Dapp.

4. Bundlers: Bundler gets UserOperations from the memory pool and packages them together to send them to the EntryPoint contract for execution.

5. Sender Contract: These are user wallet accounts in the form of smart contracts.

6. Aggregator: The aggregator is an auxiliary contract trusted by the wallet and used to verify aggregate signatures.

The entire ERC-4337 standard operating logic includes two loops: the verification loop and the execution loop, which are combined to complete the account abstraction logic.

Verification loop:The entry point contract goes through each UserOperation and calls the check function in the Sender Contract. Sender Contract runs this function to check the signature of UserOperation and compensate the Bunder who packaged these transactions.

Execution loop:Send the call data in each UserOperation to the Sender Contract. The wallet runs the execution operation to perform the transactions specified in the operation. The Sender Contract will then return the remaining gas after the operation is executed.
 

Validation loop and execution loop Source: EIP-4337

The introduced Cashier role allows application developers to subsidize fees for their users. When the paymaster is not equal to the zero address, the entry point executes a different process:

Introducing Validation Loop and Execution Loop for Tellers Source: EIP-4337

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

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

Vitalik concluded that ERC-4337 can do a lot as a purely voluntary ERC. However, it is weaker than a true in-protocol solution in some key areas:

1. User migration issue, existing users cannot upgrade without moving all their assets and activities to new accounts;

2. Additional gas overhead (basic UserOperation user operation is about 42 k, while basic transaction is about 21 k);

3. Smart contract security issues, which benefit less from in-protocol censorship-resistant techniques (such as crLists), which target transactions and ignore user operations

A realistic way to achieve the best results is to start strongly supporting ERC-4337 in the short term, and then add EIP over time to compensate for its weaknesses. This does not necessarily require a specific commitment to comply with ERC-4337. Instead, the in-protocol support could be designed to be more general and support ERC-4337 and its alternatives and improvements. The current ERC-4337 implementation solutions include Biconomy, Soul Wallet and eth-infinitism. They have all written their own entry point contract implementation solutions, and the entry point contract is the core of smart contract security under this standard.

Vitalik proposed the possibility of account abstractionroute map 。

short term

1. Bringing ERC-4337 into full production. Ideally, this could be extended using signature aggregation capabilities to achieve rollup friendliness.

2. There should be easy-to-use browser wallets that interface with ERC-4337.

3. Consider implementing signature aggregation and compression to make ERC-4337 more L2 friendly;

4. Guide the ERC-4337 ecosystem in the L2 protocol, where gas cost issues will be less;

medium term

1. Implement Verkle tree and add EIP to reduce gas cost;

2. Add optional EOA-to-ERC-4337 conversion;

3. Add crList logic at the same time or soon after Proposer/Builder Separation (PBS) rollout;

long

Consider casting, performing irregular state transitions, deploying bytecode to every account that may be EOA, but the disadvantages of this approach are the need to modify the core protocol and the high cost for miners/validators.

Project Scan

SevenX Ventures conducted a simple scan of the smart contract wallets on the market and collected some of the more mainstream smart contract wallet projects on the market. The comprehensive situation is as follows:

Implementation case

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, while Candide Wallet is a typical representative of wallets that use the ERC-4337 standard. They have rich public documents that explain their product function implementation in detail.

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 within the product, thereby quickly attracting a large number of Web2 users. Its features are: private key-free, censorship-resistant, gas-free, email recovery, privacy protection, multi-platform and multi-chain support.

The features of no private key, censorship resistance, email recovery and privacy protection are mainly brought by Unipasss key management solution. UniPass Wallets contract account supports users to set multiple types of keys. Already supported key types include:

1. The external addresses we often use are contract accounts that support the EIP-1271 protocol (a standard signature verification method for contracts).

2. UniPass users can also use their email address as a key. The smart contracts we deploy on the chain can cryptographically verify the users ownership of an Internet mailbox through DKIM (Domain Name Key Identified Mail)

3. During the verification process, UniPass uses zero-knowledge proof technology to ensure the privacy and security of user email information.

In the future, UniPass Wallet will also consider supporting more efficient and simpler signature algorithms than secp 256 k 1 (such as Schnorr, BLS), post-quantum secure signature algorithms (such as Lamport, Winternitz), etc.

Secret keys have three main roles:

1. Owner is the owner of the account. The Owner controls the deployment, upgrade, destruction and other core functions of the account, and is the highest authority controller of the account.

2. Operator is the executor of account assets. Operator is responsible for the accounts asset transfer, contract invocation, authorization and other functions, and is the key used by users every day.

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 guardian can be used to restore the account. A major feature 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 the secure multi-party computation (MPC) scheme, users can also set many other types of keys. Each key has a corresponding role and weight. A user can only obtain authorization for this role after collecting keys whose total role weight threshold exceeds the requirements.

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

The gas-free feature is implemented 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, relayer can support users to use any token to pay gas, and can even completely help users pay gas on their behalf, achieving 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.

Candide

CANDIDE is a public product built collaboratively and openly by a group of contributors, with no single entity or company controlling 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 ERC-4337 implementation of the Stackup fork and the open source framework of Gnosis Safe. Its features include wordless words, social recovery, batch transactions, and no gas fees.

Among them, the implementation logic of features such as no-note words, batch transactions, and no gas fees is the same as that of ERC-4337, and is completed using the entry point contract developed by eth-infinitism. Candide runs its own packager and packages UserOperation as a service for its own wallet. In this solution, most of the security lies in 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 leverage the most trusted DAO contract 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. This social recovery module has the same logic as Unipass, except that Unipass is mainly for email 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 wallets

Early smart contract wallets were developed based on very specific issues, such as Gnosis Safes multi-signature and Argents social recovery function. These early products were complex in design, often not open and transparent, and did not form unified standards, making it difficult to insert them into other applications as middleware. For this type of product, the judgment criteria need to be more based on the usage scenario and whether it captures the core needs of users. For example, Safes multi-signature function captures 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 words, batch transactions, and no gas fees. The unified standard also makes the development kit built based on this standard composable and can serve as an intermediate software plugs into different applications and remains interoperable.

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

1. Technology: How to build entry point contracts, packers and aggregators (if any), and how to build features beyond what ERC-4337 brings, such as social recovery features

2. Operations: How to build a community, go to market, and gain users

3. Experience: Whether the user experience of using the wallet is good enough, such as smoothness, stability, etc.

4. And the main inspection logic of some other to C products

The future wallet model is more likely to be similar to the B2B2C model. While the wallet exists as a C-end product, it is more important to provide a mature SDK solution for other applications to be integrated into in-app wallets and then targeted at C-end users. Among them, packers and aggregators are mainly built in a centralized manner in the early days. It is possible to form a modular network later. However, since this part is the core of value capture, wallets using packer networks built by others need to go through the game of economic benefits. .