Everything We Care about Account Abstraction- Ethereum Account Evolution Brought by ERC4337

By @Rui, Investor of SevenX Ventures

As many have said, Account Abstraction technology, especially ERC-4337, promises to revolutionize the user experience of self-custodial wallets and enable their scaling for mass adoption. However, as we approach May 2023, it is crucial to recognize that the standard is in its early stage, and opportunities and risks coexist.

*Please note that this content may soon be outdated as the upgrade is rapidly evolving, and the content presented is based on my personal opinion.

TL;DR

On ERC4337:

The AA standard is still in its early stages, but many innovative builders are working to further develop it. With the support of the ecosystem and adoption by large products such as MetaMask, we can expect the process of pushing AA to accelerate and yield exciting developments.

On L2s:

Adoption of Account Abstraction (AA) varies among L2 solutions. Larger L2s such as Optimism and Arbitrum do not natively support AA, while ZKSync and Starknet do.

On Bundler service:

If we are bullish on Account Abstration(AA), and all the EVM equivalent L2s in line with Ethereum — does not support native AA, then bundler service is a must need to support AA in the network.
Open source nature make Bundler service non-exclusive, making monetization difficult. Different bundler services will be adopted for network security and stability.
Private bundler could be possible a way for monetization through customizing the privacy, secure and other features for specific demand.

On Paymaster service:

Paymaster service is relatively centralized (compared to bundler service) with open-sourced contracts but closed backend.
Paymaster service has profit-making model, and can enhance payment scenarios by combining with fiat deposit, swaps, bridges, auto-payments, sessions, sponsored fees, and other features to improve dApp usability.

About AA wallet and SDKs:

AA wallets can be evaluated from a product perspective, including key management systems, social recovery, gas sponsorship, multi-chain account sync, and supported blockchains, etc.
The advantage of AA is not only smooth login (as Web3 Auth can achieve using custodial way), but in complex and customized on-chain interactions where AA can provide more benefits to dApps.
BD is the key in this fierce competition. Most of wallets are targeting Defi, GameFi and working on getting ecosystem supports, persuading big dApps, finding breaking points.
Monetization models need to be further explored. A To Business(ToB) models may not make much profit or accumulate their own users, while a To Customer(ToC) models need to find high-value scenarios to profit based on volume. Integrating swap and bridging functions can be profitable, but finding a sustainable model is crucial.

👀 Understand crypto wallet

👋 Proposal of ERC4337: Problem of CA, 4337 Mechanism, Pros n Cons

🔗 L2s: Adoption, Insights

⚙️ AA Infrastructure: Bundler and paymaster service, Evaluation

🛠️ AA Wallet& SDKs: Modular services, Evaluation

👀 Understanding crypto wallet

Classification

There’re two types accounts existing in the Ethereum network: EOA- Externally Owned Account wallets like MetaMask, and CA -Contract Account like Safe.

The main difference between EOA wallets and contract wallets is the way in which they are controlled. EOA wallets are controlled by individual users through the private key, while contract wallets are controlled by smart contracts. While EOA wallets are simpler and used for managing personal cryptocurrency holdings, contract wallets can have more complex rules and are used for specific purposes.

From Bitcoin Insider

Painpoints

Using an Externally Owned Account (EOA) wallet puts the burden of protecting private keys on users. Any mistake or error can lead to the loss of funds, making it a costly and high-risk option. Even experienced cryptocurrency users have lost control of their accounts due to a single wrong or careless move. The complexity of operations, the inability to skip or outsource gas payments, and the limited functionality of wallets are all sources of frustration for users.

Smart contract wallets offer a solution to some of these issues, but Ethereum currently requires all operations to be packaged in a transaction from an ECDSA-secured EOA. This adds an extra transaction fee and 21000 gas overhead, as well as the potential for centralization and complexity: Users need to either manage two accounts and have ETH in a separate EOA to pay for gas, or rely on centralized relay systems.

These pain points motivate the creation of ERC-4337, the new standard of Account Abstraction.

👋 Proposal of ERC4337:

Problem of CA

It is possible to do all of these things with contract wallets today, but the Ethereum itself requires everything to be packaged in a transaction originating from an ECDSA-secured externally-owned account (EOA), that will lead:

Extra transaction fee: Every user operation needs to be wrapped in a transaction from an EOA, adding 21000 gas overhead.
Complexity and centralization: The user needs to either have ETH in a separate EOA to pay for gas, and manage balances in two accounts, or rely on a relay system, which are typically centralized.

Over the years, there have been various attempts to implement account abstraction on Ethereum-based blockchains, such as EIP-86 and EIP-2938. However, these approaches were not feasible because they needed modifications to the consensus layer, which was difficult to achieve.

4337 Mechanism

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

The Modularization design of EIP 4337 divides the account abstraction function of the smart contract wallet into multiple ports:

Bundler :

Bundler is an EOA, since all transactions must be triggered by the EOA, Bundlers enable users to trigger smart contract wallet transactions without creating and memorizing the private key of the EOA.
Bundler’s duty: Verify the UserOperation, Package up a set of UserOperation objects into a single “bundle transaction”. Broadcasting the verified UserOperation to public or private mempool.
Bundlers can also gain economic benefits by: Pocket the difference between the maximum priority fee and the actual gas cost after performing the UserOperation . Similar to the relayer of ordinary transactions, Bundler can obtain MEV by sorting the UserOperation in the bundle.

Entry Point :

Entry point is a global contract that all bundlers need to call to perform a UserOperation. It acts as an intermediary between bundler and smart contract wallet.
Use handleOp to verify and execute: handleOp function accepts UserOperation as an input parameter, first verifies the UserOperation on-chain, checking that is signed by specified smart contract wallet address and wallet has enough gas to compensate the bundler, if successful, executes according to the function signature and input parameters.
Needs deposit token of a smart contract wallet to pay gas fees to bundlers: When Bundler triggers the handleOp function using EOA, a gas fee is incurred. The smart contract wallet can pay gas with its own balance or request a Pymaster to pay. Possible fail: Without enough gas fails the verification step; Even with enough gas, the UserOperation may fail in execution steps, such as a runtime error. Regardless of whether the execution is successful or not, the entry point contract will pay the gas fee to the Bundler to trigger the handleOp function. The entry point contract provides the smart contract wallet with the function to add or withdraw tokens as collateral.

Smart wallet itself:

Smart contract wallet master contract separates the verification and execution steps of UserOperation. By separating it, a bundler can verify the UserOperation off-chain, so malicious transactions can be filtered out without paying gas.
Verification steps are defined in the validateOp function: 1st time to call validateOp is bundler to simulate the verification off-chain, verify the signature in the UserOperation , and ensure that the smart contract wallet has sufficient gas balance; 2nd time to call validateOp is entry point contract to perform on-chain verification before executing the UserOperation

Paymaster :

Paymaster defines the logic of the gas abstraction for smart contract wallets, including paying for Ethereum gas with ERC20 homogenized tokens and transactions without gas.
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 a smart contract wallet. When the initCode is populated with the wallet factory address and the parameters of the new smart contract wallet, Bundler will trigger the corresponding Wallet Factory to create a smart contract with the specified parameters. Popular Wallet Factory undergoes a comprehensive code audit, safer for user to create wallet.
Wallet Factory need to stake ETH on Entry Point and consistently serve UserOperations well in order to get more traffic from Bundler.
Users can request Bundler to create a CA wallet by submitting a UserOperation populated with initCode.
Users can customize their CA wallet by selecting Wallet Factory with specific customization parameters.

Signature Aggregator :

Signature Aggregator is used to aggregate the signatures of multiple transactions into bytes for faster verification and execution of transactions. Different smart contract wallets use different signature algorithms, it is necessary to aggregate the UserOperations using the same signature algorithm first.
Save gas: since on-chain cryptographic calculations consume a lot of gas, aggregated signature schemes (such as BLS) can save gas during on-chain verification.
Bundler uses multiple signature aggregator contracts to generate multiple aggregate signatures instead of validating one UserOperation at a time.
Bundler passes the UserOperation array, aggregate signature and aggregator address to Entry Point, and each UserOperation group meeting calls the validateSignature function of its corresponding signature aggregator.
After the verification is passed, Bundler will execute this set of UserOperations on the smart contract wallet.
Aggregators also need to stake Ethereum on entry-point contracts and maintain a track record of serving UserOperations well.

Pros of AA

Gas abstraction:

Gas abstraction contains gas-free transactions and pays for gas with any ERC20 token. The logic could be implemented in a Paymaster contract or through a Relayer. In terms of AA, Many smart contract wallets implement EIP 4337-compatible Paymaster contracts themselves and pledge tokens on entry point contracts to help users pay for gas.
Social Recovery:

In the event a private key is lost or compromised, users can authorize a new key as a legitimate wallet owner. The logic of social login and social recovery is generally defined in the main contract of the wallet. Multiple apporoad could be used like email, muti-signature, MPC or SWIE(Sign in with Ethereum) and so on.
Batching transaction:

Transaction batching is a feature unique to smart contract wallets that allows wallet users to execute multiple transactions in a single on-chain transaction.
Ramps and bridges integration:

Many existing wallets, already integrate fiat deposit and withdrawal channels and cross-chain bridges into wallets by working with third-party providers. These deposit and withdrawal channels and cross-chain bridges can be further integrated with the payment contract (Paymaster) in gas abstraction.
Modular design:

One of the biggest advantage of AA could be the modular service that each part of bundler, paymaster and many could be flexibly combine.

Cons of AA

From stackup

Fees can be relative higher(maybe):

Simple transfers with ERC-4337 is much more expensive than simple transfers with a traditional wallet (often called an EOA) because a contract call has to be made with ERC-4337.

However, ERC4337 can be cheaper than EOAs on rollups because it can aggregating signatures together to reduce the amount of data on mainnet.
Standard now not yet finalized:

Some challenges like increased attack vectors due to the extended transaction extensibility, potential for unforeseen bugs or security risks when migrating to the new standard, the need for a robust and secure global entry point contract to ensure the appropriate signing and validation of all transactions.

🔗 L2s

✅ and ❌ mean whether support native AA.

Optimism: ❌

Optimism’s first version had three OVM OpCodes to enable account abstraction for smart contract wallets. However, the second version removed them for consistency and security reasons, and there’s no official statement about supporting account abstraction.

Arbitrum: ❌

While there are currently a few smart contract wallets being built on Arbitrum, there is no official statement about supporting account abstraction.

Starknet: ✅

Starknet only has smart contract accounts with validate and execute functions, which must be implemented in all accounts to verify signatures and ensure gas fees. Starknet prohibits the validate function from calling external contract state to prevent unexecuted transactions. However, there are differences from Ethereum, such as the lack of UserOperations, Paymaster-like transaction fee abstraction protocol, and the need for accounts with token balances to create new contracts. Also, if a verified transaction fails, Starknet’s sequencer cannot draw gas fees, which Ethereum does not have.

zkSync: ✅

zkSync does not distinguish between EOA 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 differences, such as the ability to call deployed external contracts and external storage during verification. Paymaster can also call external storage during transaction verification.

⚙️ AA Infrastructure:

Now we see great projects like Stackup, Etherspot, Candide, Infinistism, Pimlico are trying to build infrastructure

Bundler Service:

Builders:

Golang Implementation by Stackup
Python Implementation by Candide
TypeScript Implementation by Infinitism
Skandha — Typescript Implementation by Etherspot

Some consensus:

Public-good 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 Bundler collects service usage fees through API keys, Bundler services are also harder to monetize than other infrastructure such as the payment contract Paymaster, because the Paymaster can easily earn the fee difference by partnering with a third-party deposit and withdrawal or DeFi protocol aggregator provider.
Important infrastructure: Verification and execution of UserOperation requires as many Bundlers as possible to better decentralize. Because Stackup and eth-infinitism are the only third-party Bundler service providers currently available, we definitely need more of these Bundler service providers
Mechanism: Bundlers themselves pass messages and propagate user actions, similar to shared memory pools, without having to agree on specific things. Bundlers have an important function of filtering spam, and for their own economic reasons, they want to monitor as much as possible to make mempool safe.

Differences between bundler services:

The Bundler service can be either general infrastructure or built specifically for a wallet. Wallet projects may prioritize building the most basic Bundler, while third-party providers must build modular Bundlers for various scenarios.
The Bundler service is implemented in different languages, similar to Ethereum nodes, to prevent single points of failure and benefit the ecosystem.
The Bundler service supports private and public mempools and offers customization options for private memory pools.

Paymaster Service:

Paymaster service is relatively centralized (compared to bundler service) with open-sourced contracts but closed backend.
Paymaster service has profit-making model, and can enhance payment scenarios by combining with fiat deposit, swaps, bridges, auto-payments, sessions, sponsored fees, and other features to improve dApp usability.

🛠️ AA Wallet& SDKs:

Product evaluation:

Key management system:

-Multi-Sign Logic(Safe): Can only achieve multi-signature logic such as 2/3 and 3/5;

-Simple Rights Management(Sequence): You can set the weight to the key, and then there is a threshold for the operation account.

-RBAC, role-based rights management(Unipass): You can set weights and roles for key. Different roles can perform different operations. Each role also has a corresponding threshold. If you exceed this threshold, you can perform the permissions of the corresponding role.
Social recovery method
Gas sponsor: Self-built Relayer, or set up Bundler + PayMaster
Multi-chain account synchronization
Multi-chain address unification
Supported blockchain

Business

Business model: Tob/ ToB+ToC / ToC
Collaborate with dApps: Collaborate with giant infra-like dApps on each chain, like stablecoin or Defi
Utility: Integrate NFT marketplace, launchpad, etc.
External support: From Ethereum Foundation or other giant VCs

Shout-out to amazing builders that helped me with this article:

Reference: