Author: Rui

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

*Please note that with the rapid development of upgrades, the content of this article may quickly become outdated, and this article 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. With the support of the ecosystem and the popularity of large products such as MetaMask, we can anticipate that AA will accelerate its development process and produce exciting results.

L2:

The adoption of AA differs in L2 solutions. Larger L2s (such as Optimism and Arbitrum) do not inherently support AA, while ZKSync and Starknet do support it.

Bundler service:

• If we are optimistic about AA and if all EVM-equivalent L2s consistent with Ethereum do not support native AA, then Bundler service is a necessary condition for supporting AA in the network.
• The open-source nature of Bundler services makes monetization difficult. To ensure network security and stability, different Bundler services need to be used.
• Private Bundlers can profit by customizing privacy, security, and other features for specific needs.

Paymaster service:

• Paymaster services are relatively centralized (compared to Bundler services), with open-source contracts but closed backends.
• Paymaster services have a profit model that can enhance payment scenarios by combining with fiat deposits, exchanges, bridging, automatic payments, sessions, sponsorship fees, and more, 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 advantage of AA is not only to provide a smooth login experience (Web3 Auth can be achieved through custody). In complex and customized on-chain interactions, AA can also provide many benefits for dApps.
• Business development is key in this battle. Most wallets target Defi, GameFi, and strive to gain ecosystem support, convince large dApps, and find breakthroughs.
• Monetization models need further exploration. The To Business (To B) model may not make much money or accumulate its own users, while the To Customer (To C) model needs to find high-value scenarios to profit based on volume. Integrating exchange and bridging functions can be profitable, but the key is to find sustainable models.

Understanding Cryptocurrency Wallets

Classification

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

The main difference between EOA wallets and contract wallets lies in their control. 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 to manage personal cryptocurrency holdings, contract wallets can have more complex rules and can be used for specific purposes.

FromBitcoin Insider

Pain Points

EOA wallet users need to be careful in protecting their private keys. Any mistakes or negligence in handling private keys can lead to fund loss, making the use of EOA wallets costly and risky. Even experienced cryptocurrency users may lose control of their accounts due to a single mistake or carelessness. Complex operations, inability to bypass gas fees, inability to pay gas fees on behalf of others, and limited wallet functionality are all issues that trouble users.

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

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

ERC4337 Proposal:

Issues with CA

Currently, these issues can be resolved with contract wallets, but Ethereum itself requires all content to be bundled into transactions originating from EOA protected by ECDSA, leading to:

• Additional transaction fees: Each user operation must be initiated by EOA, requiring an additional consumption of 21000 gas.
• Complexity and centralization: Users need to deposit ETH into a separate EOA to pay gas fees and manage balances in two accounts, or rely on relay systems, which are often centralized.

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

4337 Mechanism

ERC-4337 achieves account abstraction by introducing a higher-level pseudo-transaction object called UserOperation, which is similar to the bundling concept. 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 multiple ports:

**Bundler** :

• Bundler is essentially an EOA. With Bundler, users can trigger smart contract wallet transactions without creating and remembering EOA private keys, as all transactions must be initiated by EOA.
• Bundler's role: verify UserOperation, bundle a set of UserOperation objects into a single "bundled transaction," and broadcast the verified UserOperation content to a public or private memory pool.
• Bundler can also profit by: pocketing the difference between the highest priority fee and the actual gas fee after executing UserOperation. Similar to relayers for regular transactions, Bundler can profit from MEV by sorting UserOperation in bundled transactions.

**Entry point**:

• The entry point is a global contract that all Bundlers need to call to execute UserOperation. The entry point acts as an intermediary between Bundler and the smart contract wallet.
• Validation and execution with handleOp: The handleOp function takes UserOperation as input and first verifies the UserOperation on-chain, checks if it is signed by the specified smart contract wallet address, and ensures that the wallet has enough gas fees to compensate the Bundler. If the validation is successful, it executes the input parameters based on the function signature.

Token deposits needed in the smart contract wallet to pay gas fees to the Bundler: When the Bundler triggers handleOp using EOA, gas fees are incurred. The smart contract wallet can use its own balance to pay the gas fees or request payment from Paymaster. Possible failures include insufficient gas fees and validation step failures; even with enough gas fees, the execution of UserOperation may fail, such as runtime errors. Regardless of the success of the execution, the entry point contract will pay gas fees 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, Bundler can verify UserOperation off-chain to filter out malicious transactions without paying gas fees.

The validateOp function defines the validation steps: the first call to validateOp involves Bundler simulating off-chain validation, verifying the signature in UserOperation, and ensuring that the smart contract wallet has enough gas balance; the second call to validateOp is made by the entry point contract to perform on-chain validation before executing UserOperation.

Paymaster:

• Paymaster defines the gas abstraction logic for the smart contract wallet, including using ERC20 fungible tokens to pay Ethereum gas fees and transactions without gas fees. Paymaster is a smart contract deployed by dApps and can trigger validatePaymasterOp.

Wallet Factory:

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

Signature Aggregator:

• The 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 and need to aggregate UserOperations using the same signature algorithm before on-chain verification.
• Gas fee savings: Aggregated signature schemes (such as BLS) can save gas fees during on-chain verification, as on-chain cryptographic computations consume a significant amount of gas fees.
• Bundler uses multiple signature aggregator contracts to generate multiple aggregated signatures instead of verifying one UserOperation at a time.
• Bundler passes the UserOperation array, aggregated signature, and aggregator address to the entry point, and each UserOperation group calls the validateSignature function of its corresponding signature aggregator.
• After successful verification, Bundler executes this set of UserOperation on the smart contract wallet.
• The aggregator also needs to stake Ethereum on the entry point contract and maintain a good record of UserOperation service.

Advantages of AA

• Gas Abstraction:

Gas abstraction includes transactions without gas fees and using any ERC20 tokens to pay gas fees. This logic can be executed in the Paymaster contract or through relayers. For AA, many smart contract wallets themselves 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 new keys as legitimate wallet owners. The logic for social login and social recovery is generally defined in the wallet's main contract. Various methods can be used, such as email, multi-signature, MPC, or SWIE (used for 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 be further integrated with the payment contract (Paymaster) in gas abstraction.

• Modular Design:

One of the biggest advantages of AA may be its modular services, where Bundler, Paymaster, and other parts can be flexibly combined.

Disadvantages of AA

From stackup

• Potentially Higher Fees:

The cost of simple transfers using ERC-4337 is much higher than using traditional wallets (usually referred to as EOA) because the former requires calling a contract.

However, on Rollup networks, using ERC-4337 for simple transfers may be cheaper than EOA because it can aggregate signatures to reduce data volume on the mainnet.

• Standard Not Yet Finalized:

Expanded transaction scalability leads to increased attack vectors, 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 has three OVM opcodes to implement account abstraction for smart contract wallets. However, for consistency and security reasons, version 2 removed these opcodes and there is no official statement about supporting account abstraction.

Arbitrum: ❌

Although there are some smart contract wallets being built on Arbitrum, there is no official statement about supporting account abstraction.

Starknet: ✅

Starknet only has smart contract accounts with validation and execution capabilities, and all accounts must implement these functions to verify signatures and ensure gas fees. Starknet prohibits the validation function from calling external contract states to prevent unexecuted transactions. However, Starknet differs from Ethereum in some aspects, such as the absence 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 validated transaction fails, Starknet's sequencer cannot collect gas fees, while Ethereum can.

zkSync: ✅

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

AA Infrastructure:

Currently, some excellent projects such as Stackup, Etherspot, Candide, Infinistism, 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 most Bundlers makes them non-exclusive and non-competitive. Any RPC endpoint can run a Bundler by replicating the open-source code.

• Difficult to Monetize

Even if RPC endpoints running Bundlers charge for service usage through API keys, Bundler services are more difficult to monetize compared to other infrastructure (such as the Paymaster payment contract) because Paymaster can easily earn fees by collaborating with third-party deposit and withdrawal providers or DeFi protocol aggregators.

• Critical Infrastructure

As many Bundlers as possible are needed for the validation and execution of UserOperation to achieve better decentralization. Currently, there are only Stackup and eth-infinitism as third-party Bundler service providers, so more of such providers are indeed needed.

• Mechanisms

Bundlers pass messages and propagate user actions similar to a shared memory pool without the need for specific agreements on specific matters. Bundlers play a crucial role in filtering out spam messages, and for their own economic reasons, they aim 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 Bundlers, 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, and provide customization options for private memory pools.

Paymaster Services

• Compared to Bundler services, Paymaster services are relatively centralized, with open-source contracts but closed backends.
• Paymaster services have a profit model and can improve dApp usability by combining with fiat deposit, exchange, bridging, automatic payments, sessions, sponsorship fees, and other functions.

AA Wallets and SDKs:

Product Evaluation

• Key Management System:
  • Multi-signature logic (security): capable of implementing multi-signature logic such as 2/3 and 3/5.
  • Simple permission management (sequential): can set weights for keys and then set thresholds for operational accounts.
  • Role-based permission management (Unipass): can set weights and roles for keys. Different roles can perform different operations, each with its corresponding threshold. If the threshold is exceeded, the corresponding role's permissions can be executed.
• Social recovery methods
• Gas fee sponsorship: self-built relayer or Bundler + Paymaster setup
• Multi-chain account synchronization
• Unified multi-chain addresses
• Supported blockchains

Business

• Business model: To B / To B+To C / To C
• Collaboration with dApps: Collaboration with infrastructure-type dApps of giants on various chains, such as stablecoins or DeFi.
• Practicality: Integration with NFT markets, launchpads, etc.
• External support: From the Ethereum Foundation or other well-known venture capital firms.

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。