SevenX Ventures: Understanding Account Abstraction in One Article - How ERC4337 Brings Evolution to Ethereum Accounts?

Author: Rui

As many have said, Account Abstraction (AA) technology, especially ERC-4337, is expected to revolutionize the user experience of self-custody wallets and enable scalability for mass adoption. However, as we approach May 2023, we must recognize that this standard is still in its early stages, with both opportunities and risks.

Please note that due to the rapid development of upgrades, the content of this article may soon become outdated, and it is based solely on my personal views.

TL;DR

ERC4337:

The AA standard is still in its early stages, but many innovative builders are working hard to further develop it. Against the backdrop of ecosystem support and the popularity of large products like MetaMask, we can foresee that AA will accelerate its development process and yield exciting results.

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

Bundler Services:

• If we are optimistic about AA, and all EVM-equivalent L2s that are Ethereum-compatible do not support native AA, then Bundler services are a necessary condition for supporting AA in the network.
• The open-source nature makes Bundler services non-exclusive, which complicates monetization. To ensure network security and stability, different Bundler services must be utilized.
• Private Bundlers can achieve profitability by customizing privacy, security, and other features for specific needs.

Paymaster Services:

• Paymaster services are relatively centralized (compared to Bundler services), with open-source contracts but a closed backend.
• Paymaster services have a monetization model that can enhance payment scenarios by combining with fiat deposits, exchanges, bridging, automatic payments, sessions, sponsorship fees, and other functions, thereby improving dApp usability.

AA Wallets and SDKs:

• AA wallets can be evaluated from a product perspective, including key management systems, social recovery, gas fee sponsorship, multi-chain account synchronization, and supported blockchains.
• The advantages of AA are not limited to providing a smooth login experience (Web3 Auth can achieve this through custodial means). In complex and customized on-chain interactions, AA can also provide numerous benefits for dApps.
• Business Development (BD) is key in this battle. Most wallets target DeFi and GameFi and are committed to gaining ecosystem support, persuading large dApps, and finding breakthrough points.
• Monetization models are yet to be explored in depth. The To Business (To B) model may not generate much revenue and will not accumulate its own users, while the To Customer (To C) model needs to find high-value scenarios to profit based on scale. Integrating exchange and bridging functions can be profitable, but the key lies in finding a sustainable model.

Understanding Crypto Wallets

Classification

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

The main difference between EOA wallets and contract wallets lies in their control mechanisms. EOA wallets are controlled by individual users through private keys, while contract wallets are controlled by smart contracts. Although EOA wallets are simpler and used for managing personal cryptocurrency holdings, contract wallets can have more complex rules and be used for specific purposes.

Pain Points

EOA wallet users need to be cautious about protecting their private keys. Any mistakes or negligence regarding the private key can lead to the loss of funds, making the use of EOA wallets costly and risky. Even experienced cryptocurrency users can lose control of their accounts due to a single mistake or careless action. Complex operations, inability to skip gas fees or pay gas fees on behalf of users, and limited wallet functionalities are issues that trouble users.

Smart contract wallets provide solutions to some of these problems, but Ethereum currently requires all operations to be bundled in transactions originating from ECDSA-protected EOAs. This incurs additional transaction fees and consumes an extra 21,000 gas, along with potential centralization risks and complex operations: users need to manage two accounts and deposit ETH in a separate EOA to pay for gas fees or rely on centralized relay systems for payment.

These pain points have led to the emergence of the new AA standard—ERC-4337.

ERC4337 Proposal

Issues with CA

Today, these issues can be resolved with contract wallets, but Ethereum itself requires everything to be bundled in transactions originating from ECDSA-protected EOAs, leading to:

• Additional Transaction Fees: Each user operation must be initiated by an EOA, which requires an extra consumption of 21,000 gas.
• Complexity and Centralization: Users need to deposit ETH in a separate EOA to pay for gas fees and manage balances across two accounts, or rely on relay systems that are often centralized.

Over the years, there have been multiple attempts to achieve account abstraction on Ethereum-based blockchains, such as EIP-86 and EIP-2938. However, these methods have failed because they require modifications to the consensus layer, which is difficult to implement.

4337 Mechanism

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

The modular design of EIP 4337 divides the account abstraction functionality of smart contract wallets into several components:

Bundler:

• The Bundler is an EOA. Since all transactions must be initiated by an EOA, with the Bundler, users can trigger smart contract wallet transactions without creating and remembering an EOA private key.
• The role of the Bundler: to validate UserOperation, bundle a set of UserOperation objects into a single "bundled transaction," and broadcast the validated UserOperation content to a public or private memory pool.
• The Bundler can also gain economic benefits by pocketing the difference between the highest priority fee and the actual gas fee after executing the UserOperation. Similar to regular transaction relayers, the Bundler can obtain MEV by ordering UserOperations within the bundled transaction.

Entry Point:

• The entry point is a global contract that all Bundlers need to call to execute UserOperation. It acts as an intermediary between the Bundler and the smart contract wallet.
• Validation and execution with handleOp: The handleOp function takes UserOperation as an input parameter, first validating the UserOperation on-chain, checking if it is signed by the specified smart contract wallet address and if the wallet has enough gas to compensate the Bundler. If validation is successful, it executes the input parameters based on the function signature. Tokens to be deposited into the smart contract wallet pay the gas fee to the Bundler: when the Bundler triggers handleOp using an EOA, gas fees are incurred. The smart contract wallet can pay gas fees with its own balance or request the Paymaster to pay. Possible failures include insufficient gas fees, failed validation steps; even with sufficient gas fees, the execution step of UserOperation may fail, such as runtime errors. Regardless of whether the execution is successful, the entry point contract pays the gas fee to the Bundler to trigger the handleOp function. The entry point contract provides the smart contract wallet with the ability to add or withdraw tokens as collateral.

Smart Wallet:

The main contract of the smart contract wallet separates the validation and execution steps of UserOperation. By separating them, the Bundler can validate UserOperation off-chain, filtering out malicious transactions without incurring gas fees.

The validation step is defined in the validateOp function: the first call to validateOp simulates off-chain validation by the Bundler, verifying the signature in UserOperation and ensuring that the smart contract wallet has sufficient gas balance; the second call to validateOp is made by the entry point contract, performing on-chain validation before executing UserOperation.

Paymaster:

• The Paymaster defines the gas abstraction logic for the smart contract wallet, including paying Ethereum gas fees with ERC20 fungible tokens and transactions without gas fees.
• The Paymaster is a smart contract deployed by dApps that can trigger the Paymaster's validatePaymasterOp.

Wallet Factory:

• The Wallet Factory is a public contract for creating smart contract wallets. When the wallet factory address and parameters for the new smart contract wallet are embedded in the initCode, the Bundler triggers the corresponding Wallet Factory to create a smart contract with the specified parameters. Popular Wallet Factory code is thoroughly audited, making it safer to create wallets using the Wallet Factory.
• The Wallet Factory needs to stake ETH on the entry point and continuously provide good service for UserOperations to attract more traffic from the Bundler.
• Users can submit UserOperations filled with initCode to request the Bundler to create CA wallets.
• Users can choose Wallet Factories with specific custom parameters to customize their CA wallets.

Signature Aggregator:

• The signature aggregator is used to aggregate the signatures of multiple transactions into bytes for faster verification and execution. Different smart contract wallets use different signature algorithms, requiring the same signature algorithm to aggregate UserOperations.
• Saving gas fees: Since on-chain cryptographic computations consume a lot of gas fees, aggregation signature schemes (like BLS) can save gas fees during on-chain verification.
• The Bundler uses multiple signature aggregator contracts to generate multiple aggregated signatures instead of verifying one UserOperation at a time.
• The Bundler passes the UserOperation array, aggregated signatures, and aggregator addresses to the entry point, where each UserOperation group calls the corresponding signature aggregator's validateSignature function.
• Once verified, the Bundler executes this set of UserOperation on the smart contract wallet.
• Aggregators also need to stake Ethereum on the entry point contract and maintain a good service record for UserOperation.

Advantages of AA

• Gas Abstraction:
  Gas abstraction includes gas-free transactions and uses any ERC20 tokens to pay gas fees. This logic can be executed in the Paymaster contract or through relayers. Many smart contract wallets can implement EIP 4337 compatible Paymaster contracts and stake tokens on the entry point contract to help users pay gas fees.

• Social Recovery:
  In the event of lost or leaked private keys, users can authorize a new key as the legitimate wallet owner. The logic for social login and social recovery is generally defined in the main contract of the wallet. Various methods can be used, such as email, multi-signature, MPC, or SWIE (Ethereum login).

• Transaction Batching:
  Transaction batching is a unique feature of smart contract wallets that allows wallet users to execute multiple transactions in a single on-chain transaction.

• Cross-Chain Bridging and Connection Bridge Integration:
  Currently, many wallets collaborate with third-party providers to integrate fiat deposit and withdrawal channels and cross-chain bridging into the wallet. These deposit and withdrawal channels and cross-chain bridging can further integrate with the payment contracts (Paymaster) in gas abstraction.

• Modular Design:
  One of the biggest advantages of AA may be its modular services, allowing Bundler, Paymaster, and other components to be flexibly combined.

Disadvantages of AA

• Transaction Fees (Perhaps) Relatively High:
  The cost of simple transfers using ERC-4337 is much higher than using traditional wallets (commonly referred to as EOAs) because the former requires calling contracts.
  However, on Rollup networks, using ERC-4337 for simple transfers may be cheaper than EOAs because it can aggregate signatures to reduce the amount of data on the mainnet.

• Standards Not Yet Finalized:
  Extended transaction scalability leads to increased attack vectors, potential unknown errors or security risks when migrating to new standards, and the need for a robust and secure global entry point contract to ensure all transactions are properly signed and verified, among other challenges.

Layer 2

✅ and ❌ indicate whether native AA is supported.

Optimism: ❌

Optimism version 1 had three OVM opcodes to achieve account abstraction for smart contract wallets. However, for consistency and security reasons, version 2 removed these opcodes and there is no official statement regarding support for account abstraction.

Arbitrum: ❌

While there are currently some smart contract wallets built on Arbitrum, there is no official statement regarding support for account abstraction.

Starknet: ✅

Starknet only has smart contract accounts with verification and execution capabilities, and all accounts must implement these functions to verify signatures and ensure gas fees. Starknet prohibits verification functions from calling external contract states to prevent unexecuted transactions. However, Starknet differs from Ethereum in some aspects, such as the lack of UserOperations, a transaction fee abstraction protocol similar to Paymaster, and the requirement for accounts to have token balances to create new contracts. Additionally, if a verified transaction fails, Starknet's sequencer cannot collect gas fees, while Ethereum can.

zkSync: ✅

zkSync does not differentiate between EOAs and contract accounts. Its account model is similar to EIP 4337 and includes separate validateTransaction and executeTransaction functions. The Paymaster interface also includes validateAndPayForPaymasterTransaction and postOp functions. However, there are still differences, such as the ability to call deployed external contracts and external storage during the verification process. The Paymaster can also call external storage during transaction verification.

AA Infrastructure:

Currently, some excellent projects like Stackup, Etherspot, Candide, Infinitism, and Pimlico are attempting to build infrastructure.

Bundler Services:

Builders:

• Stackup's Golang implementation
• Candide's Python implementation
• Infinitism's TypeScript implementation
• Etherspot's Skandha --- TypeScript implementation

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 a Bundler by copying the open-source code.

• Difficult to Monetize
  Even if the RPC endpoint running the Bundler charges service usage fees through API keys, Bundler services are harder to monetize than other infrastructures (like the Paymaster payment contract) because Paymaster can easily earn fee differentials by collaborating with third-party deposit providers or DeFi protocol aggregators.

• Important Infrastructure
  Verifying and executing UserOperations requires as many Bundlers as possible to better achieve decentralization. Since currently, the only third-party Bundler service providers are Stackup and eth-infinitism, we indeed need more such Bundler service providers.

• Mechanism
  The Bundler itself passes messages and propagates user actions, similar to a shared memory pool, without needing to reach consensus on specific matters. The Bundler has an important function of filtering out junk information, and for its own economic reasons, the Bundler wants to monitor as much as possible to ensure the security of the memory pool.

Differences in Bundler Services:

• Bundler services can be general infrastructure or specifically built for wallets. Wallet projects may prioritize building the most basic Bundler, while third-party providers must build modular Bundlers for various scenarios.
• Similar to Ethereum nodes, Bundler services are implemented in different programming languages to prevent single points of failure and benefit the ecosystem.
• Bundler services support private memory pools and public memory pools, providing customization options for private memory pools.

Paymaster Services

• Compared to Bundler services, Paymaster services are more centralized, with contracts being open-source but the backend being closed.
• Paymaster services have a monetization model that can improve dApp usability by combining with fiat deposits, exchanges, bridging, automatic payments, sessions, sponsorship fees, and other functions.

AA Wallets and SDKs:

Product Evaluation

• Key Management Systems:
• Multi-signature logic (secure): Can only implement multi-signature logic like 2/3 and 3/5;
• Simple permission management (sequential): Can set weights for keys and then set thresholds for operations on accounts.
• Role-based permission management (Unipass): Can set weights and roles for keys. Different roles can perform different operations. Each role also has corresponding thresholds. If exceeded, the permissions of the corresponding role can be executed.
• Social recovery methods
• Gas fee sponsorship: self-built relayers, or set up Bundler + Paymaster
• Multi-chain account synchronization
• Unified multi-chain addresses
• Supported blockchains

Business

• Business models: To B / To B + To C / To C
• Collaboration with dApps: Partnering with major infrastructure dApps like stablecoins or DeFi across chains
• Practicality: Integrating NFT marketplaces, launchpads, etc.
• External support: From the Ethereum Foundation or other well-known venture capital institutions