How does understanding account abstraction ERC4337 lead to the evolution of Ethereum accounts?

Author: Rui

As many have said, account abstraction (AA) technology, especially ERC-4337, promises to revolutionize the user experience of self-custody Wallet and allow it to scale for mass adoption. However, as May 2023 draws closer, we must recognize that the standard is still in its early stages, with both opportunities and risks.

Please note that the content of this article may quickly become outdated as upgrades evolve rapidly, and this article is based solely on my personal opinion.

TL; DR

ERC4337：

The AA standard is still in its early stages, but many innovation builders are working to develop it further. With the support of the ecosystem and the popularity of large products such as MetaMask, we can expect AA to accelerate its development process and produce exciting results.

L2：

The adoption of AA varies in L2 solutions. Larger L2s (e.g. Optimism and Arbitrum) do not natively support AA, while ZKSync and Starknet do.

Bundler Service:

• If we are bullish on AA and all Ethereum-aligned EVM equivalent L2 does not support native AA, then the Bundler service is necessary to support AA in the network.
• The Open Source feature makes the Bundler service non-exclusive, which makes monetization difficult. In order to ensure the stability of the network, different Bundler services need to be used.
• Private Bundlers can be monetized by customizing privacy, security, and other features to specific needs.

Paymaster Service:

• The Paymaster service is relatively centralized (compared to the Bundler service), the contract is Open Source, but the backend is closed.
• The Paymaster service has a monetization model that can be combined with features such as Fiat Currency deposits, exchanges, bridges, automatic payments, sessions, sponsorship fees, etc. to enhance payment scenarios and thus improve dApp usability.

AA Wallet and SDK:

• AA Wallet can be evaluated from a product perspective, including Secret Key Management System, Social Recovery, Gas Fee Sponsorship, Multi-Chain Account Sync, and Supported Blockchain.
• The benefits of AA go beyond providing a smooth login experience (Web3 Auth is hosted). AA can also provide a number of benefits to dApps in complex and customized on-chain interactions.
• BD is the key to this battle. Most Wallets target Defi, GameFi, and aim to gain ecosystem support, convince large dApps, and find breakthroughs.
• Monetization models need to be further explored. The To Business (To B) model may not make much money and will not accumulate its own users, while the To Customer (To C) model needs to find high-value scenarios and make profits based on volume. Integrating switching and bridging capabilities can be profitable, but the key is to find a sustainable model.

Learn about crypto Wallet

Classification

There are two types of accounts on the Ethereum network: Externally Owned Account (EOA) Wallet, such as MetaMask, and Contract Account (CA), such as Safe.

The main difference between an EOA Wallet and a Contract Wallet is how it is controlled. EOA Wallets are controlled by individual users through Private Keys, while Contract Wallets are controlled by Smart Contracts. While EOA Wallets are simpler and are used to manage personal Crypto Assets holdings, contract Wallets can have more complex rules and can be used for specific purposes.

FromBitcoin Insider

Pain points

EOA Wallet users need to pay attention to protecting Private Keys. Any mistakes or omissions made on the Private Key can result in the loss of funds, so the use of EOA Wallet is more expensive and risky. Even experienced Crypto Assets users can lose control of their accounts due to a single mistake or careless move. The complexity of the operation, the inability to skip the gas fee or make gas fee payment, and the limited functionality of the Wallet are all problems that plague users.

Smart ContractWallet provides a solution to some of these problems, but Ethereum currently requires all operations to be packaged in transactions from ECDSA-protected EOAs. This incurs additional transaction fees and an additional 21,000 gas fees, and with it potential centralization risks and complications: users need to manage two accounts and deposit ETH in separate EOAs to pay for gas fees, or rely on a centralized relay system to pay.

These pain points gave birth to a new AA standard, ERC-4337.

ERC4337 proposals:

CA’s problem

Nowadays, these things can all be solved with contract Wallet, but Ethereum itself requires everything to be packaged in transactions derived from ECDSA-protected EOA, which will result:

Additional Transaction Fee: Each user action must be initiated by EOA, resulting in an additional 21,000 gas fee. Complexity and centralization: Users need to deposit ETH in separate EOAs to pay gas fees and manage balances in both accounts, or rely on Relay systems to pay, Relay which are often centralized.

Over the years, there have been several attempts to implement account abstraction on Ethereum-based Blockchain such as EIP-86 and EIP-2938. However, none of these approaches work, as they all require changes to the Consensus layer, which is difficult to implement.

4337 mechanism

ERC-4337 implements account abstraction by introducing a higher-level pseudo-transaction object called UserOperation, which is similar to rollups in terms of bundling concepts. Fortunately, this standard allows us to build account abstractions without changing the Consensus layer.

The modular design of EIP 4337 divides the Smart ContractWallet account abstraction into multiple ports:

Bundler :

• Bundler is an EOA. Since all transactions must be initiated by an EOA, Bundler allows users to trigger Smart ContractWallet transactions without having to create and remember an EOA Private Key.
• What the Bundler does: Validate the UserOperation, package a set of UserOperation objects into a single “bundle transaction”. Broadcast the authenticated UserOperation content to a public or private memory pool.
• Bundler also benefits financially by pocketing the difference between the highest priority fee and the actual gas fee after the UserOperation is executed. Similar to the relay of a normal transaction, the Bundler obtains MEV by sorting the UserOperation in the bundled transaction.

Entry Point:

• The entry point is a global contract that all Bundlers need to call to execute a UserOperation. The entry point acts as an intermediary between the Bundler and the Smart ContractWallet.
• Validate and execute with handleOp: The handleOp function uses UserOperation as an input parameter to first validate the UserOperation on-chain, check if it is signed by the specified Smart ContractWalletAddress, and Wallet enough gas fees to compensate the Bundler. If the validation is successful, the input parameters are executed based on the function signature.

Token that need to deposit Smart ContractWallet pay gas fees to the Bundler: When the Bundler triggers a handleOp using EOA, a gas fee is incurred. Smart ContractWallet can pay the gas fee with their own balance, or ask Pymaster to pay it. Possible Failure: The gas fee is insufficient, the validation step fails, and even if the gas fee is sufficient, the UserOperation execution step may fail, such as a runtime error. Regardless of whether the execution is successful or not, the entry point contract will pay a gas fee to the Bundler to trigger the handleOp function. The entry point contract provides Smart ContractWallet with the ability to add or withdraw Token as a Collateral.

Smart Wallet:

Smart ContractWallet main contract separates the validation and execution steps of the UserOperation. By decoupling it, the Bundler can validate the UserOperation off-chain, filtering out malicious transactions without having to pay gas fees.

The validation steps are defined in the validateOp function: the first call to validateOp, the Bundler simulates off-chain validation, verifies the signature in the UserOperation, and ensures that the Smart ContractWallet has sufficient gas balance, and the second call to validateOp is the entry point contract, which performs on-chain verification before executing the UserOperation.

Paymaster :

• Paymaster defines Smart ContractWallet gas abstraction logic, including the use of ERC20 Fungible Token to pay Ethereum gas fees as well as transactions without gas fees.
• Paymaster is a Smart Contract deployed by a dApp that can trigger Paymaster’s validatePaymasterOp.

Wallet Factory :

• Wallet Factory is a public contract that creates Smart ContractWallet. When the Wallet factory Address and newly Smart ContractWallet parameters are implanted in the initCode, the Bundler will trigger the corresponding Wallet Factory to create a Smart Contract with the specified parameters. Popular Wallet Factory codes are fully vetted, so it’s safer to create a Wallet with Wallet Factory.
• Wallet Factory needs to stake ETH at the entry point and continue to serve UserOperations well in order to get more traffic from Bundler.
• Users can submit a UserOperation filled with initCode and request the Bundler to create a CA Wallet.
• Users can choose Wallet Factory with specific custom parameters to customize their CA Wallet.

Signature aggregators:

• Signature aggregators are used to aggregate the signatures of multiple transactions into bytes for faster verification and execution of transactions. Different Smart ContractWallet use different Signature Algorithm and need to use the same Signature Algorithm aggregate UserOperations first.
• Save gas fees: Since on-chain cryptographic computation consumes a lot of gas fees, aggregate signature schemes (such as BLS) can save gas fees when verifying on-chain.
• Bundler uses multiple signature aggregator contracts to generate multiple aggregate signatures, rather than validating one UserOperations at a time.
• The Bundler passes the UserOperation array, aggregate signature, and aggregator Address to the entry point, and each UserOperation group meeting calls the validateSignature function of its corresponding signature aggregator.
• After validation, the Bundler will execute this set of UserOperations on the Smart ContractWallet.
• Aggregators also need to stake Ethereum on the entry point contract and maintain a good UserOperation service record.

Advantages of AA

Gas Abstraction:

The gas abstraction contains no gas fee transactions and pays gas fees with any ERC20 Token. The logic can be executed in the Paymaster contract or through a relay. For AA, many Smart ContractWallet themselves can implement EIP 4337-compliant Paymaster contracts and stake Token on the entry point contract to help users pay gas fees.

Social Recovery:

In the event that the Private Key is lost or compromised, the user can authorize the new Secret Key as the legitimate Wallet owner. The logic of social login and social recovery is generally defined in the main contract of the Wallet. It can be done in a variety of ways, such as email, Multisig, MPC, or SWIE (login with Ethereum).

Transaction Batch:

Transaction batching is a feature unique to Smart ContractWallet that allows Wallet users to execute multiple transactions in a single on-chain transaction.

Cross-Chain Interaction and Connection Bridge Integration:

Currently, many wallets are working with third-party vendors to integrate Fiat Currency deposit and withdrawal channels and Cross-Chain Interaction bridges into wallets. These deposit and withdrawal channels and cross-chain interaction bridges can be further integrated with the payment contract (Paymaster) in the gas abstraction.

Modular Design:

Perhaps one of AA’s biggest strengths is its modular service, where Bundler, Paymaster, and other parts can be flexibly combined.

Defects in AA

From stackup

Relatively high processing fee:

Using ERC-4337 to make a simple transfer is much more expensive than using a traditional Wallet (often referred to as EOA) because the former requires a call to the contract.

However, on the Rollup network, a simple transfer using ERC-4337 may be cheaper than EOA because it aggregates signatures together to reduce the amount of data on Mainnet.

Criteria not yet finalized:

Challenges such as increased Attack Vector due to expanded transaction scalability, the potential for unknown bugs or security risks when migrating to new standards, the need for a robust and secure global entry point contract to ensure that all transactions are properly signed and verified, and so on.

Layer 2

• ✅ and ❌ indicate whether native AA is supported. *

Optimism: ❌

Optimism version 1 has three OVM Operation Code to achieve Smart ContractWallet account abstraction. However, for consistency and security reasons, version 2 removes these Operation Codes, and there is no official statement about supporting account abstraction.

Arbitrum: ❌

While there are currently some Smart ContractWallet built on top of Arbitrum, there is no official statement about supporting account abstraction.

Starknet: ✅

Starknet only has Smart Contract accounts with verification and execution functions, and all accounts must implement these features to verify signatures and ensure gas fees. Starknet prohibits the verification function from calling the external contract state to prevent unexecuted transactions. However, there are some differences between Starknet and Ethereum, such as the lack of UserOperations, a transaction fee abstraction protocol similar to Paymaster, and the need for an account with a Token balance to create new contracts. Also, Starknet’s sequencer can’t charge gas fees if a verified transaction fails, while Ethereum can.

zkSync: ✅

zkSync does not distinguish between EOA and contract accounts. Its account model is similar to EIP 4337 and includes separate validateTransactiom and uteTransaction functions. The Paymaster interface also includes the validateAndPayForPaymasterTransaction and postOp functions. However, there are some differences, such as the ability to call deployed external contracts and external storage during the validation process. Paymaster can also invoke external storage during transaction validation.

AA Infrastructure:

Currently, some excellent projects such as Stackup, Etherspot, Candide, Infinistism, and Pimlico are trying to build infrastructure.

Bundler Service:

Builder:

• Golang implementation of Stackup
• Candide’s Python implementation
• Type implementation of Infinitism
• Skandha - Type implementation of Etherspot

Some Consensus:

Public Service

The Open Source nature of the vast majority of Bundlers makes them non-exclusive and non-competitive. Any RPC endpoint can run Bundler by copying Open Source code.

• Difficult to monetize

Even if the RPC endpoint running Bundler charges service usage fees through API secret keys, Bundler services are more difficult to monetize than other infrastructures such as Paymaster, a payment contract, because Paymaster can easily earn the difference in fees by partnering with third-party deposit and withdrawal providers or Decentralized Finance protocol aggregator providers.

Critical Infrastructure

Validating and executing UserOperations requires as many Bundlers as possible for better Decentralization. Since the only third-party Bundler service providers currently are Stackup and eth-infinitism, we do need more such Bundler service providers.

*Mechanism

Bundlers deliver messages and propagate user actions on their own, similar to shared memory pools, without having to agree on specific matters. Bundler has an important feature for filtering spam, and for its own financial reasons, Bundler wants to monitor as much as possible to ensure the safety of the mempool.

Differences between Bundler services:

• The Bundler service can be a general infrastructure or built specifically for Wallet. Wallet projects may prioritize building the most basic bundler, while third-party providers must build modular bundlers for various scenarios.
• Similar to EthereumNode, the Bundler service is implemented in a different programming language to prevent single points of failure and benefit the ecosystem.
• The Bundler service supports both private and public mempools, and provides customization options for private mempools.

Paymaster service

• Compared with the Bundler service, the Paymaster service is more centralized, the contract is Open Source, but the backend is closed.
• The Paymaster service has a monetization model that can improve the usability of dApps by combining with Fiat Currency deposits, exchanges, bridging, automatic payments, sessions, sponsorship fees, and other features.

AA Wallet and SDK:

Product Evaluation

• Secret Key Management System:
  • Multisig logic (secure): Only 2/3 and 3/5 Multisig logic can be implemented;
  • Simple Permission Management (Sequential): You can set weights for secret keys and then set thresholds for operating accounts.
  • Role-based permission management (Unipass): You can set weights and roles for secret keys. Different roles can perform different actions. Each role also has a corresponding threshold. If this threshold is exceeded, the permissions of the corresponding role can be enforced.
• Social recovery methods
• Gas fee sponsorship: build your own Relay, or set up Bundler + Paymaster
• Multi-chain account synchronization
• Multi-chain Address unity
• Supported Blockchain

Business

• Business model: To b/ To B + To C / ToC
• Partnering with dApps: Partnering with giant infrastructure dApps such as Stable Coin or Decentralized Finance on each chain
• Utility: Integrate Non-fungible Token marketplaces, launchpads, etc.
• External support: from the Ethereum Foundation or other well-known venture capital institutions