SevenX Ventures: Understanding Account Abstraction in One Article - How does ERC4337 bring about the evolution of Ethereum accounts?

CN
链捕手
Follow
1 year ago

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 the 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 opinion.

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 major products such as MetaMask, we can anticipate that AA will accelerate its development process and produce exciting results.

L2: Adoption of AA differs in L2 solutions. Larger L2 solutions (such as Optimism and Arbitrum) do not inherently support AA, while ZKSync and Starknet do.

Bundler Service:

  • If we are optimistic about AA and if all EVM-equivalent L2s that are 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 Wallet and SDK:

  • 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 Crypto Wallets

Categories

There are two types of accounts in the Ethereum network: Externally Owned Account (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. While 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.

Pain Points

EOA wallet users need to be mindful of protecting their private keys. Any mistakes or negligence with the private key could 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 careless action. Complex operations, inability to bypass gas fees or delegate gas payments, and limited wallet functionality are all issues that trouble users.

While smart contract wallets provide solutions to some of these problems, Ethereum currently requires all operations to be bundled into transactions originating from an EOA protected by ECDSA. This incurs additional transaction fees, requires an extra 21,000 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 proposal of the new AA standard — ERC-4337.

ERC4337 Proposal

Issues with CA

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

  • Additional transaction fees: Each user operation must be initiated by an EOA, requiring an additional 21,000 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 been successful as 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, similar to rollups in 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:

  • The Bundler acts as an EOA. With the Bundler, users can trigger smart contract wallet transactions without creating and remembering EOA private keys.
  • The role of the Bundler: to verify UserOperations, bundle a set of UserOperation objects into a single "bundled transaction," and broadcast the verified UserOperation content to a public or private mempool.
  • The Bundler can also gain economic benefits by pocketing the difference between the highest priority fee and the actual gas fee after executing UserOperations. Similar to relayers for regular transactions, Bundlers can profit from MEV by sorting UserOperations in bundled transactions.

Entry Points:

  • 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 an input parameter, first verifies 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, the input parameters are executed based on the function signature. Tokens need to be deposited into 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 gas fees or request payment from Paymaster. Possible failures include insufficient gas fees, failed validation steps, or runtime errors even with sufficient gas fees. 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, Bundlers 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 off-chain validation by the Bundler, 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 smart contract wallets, including paying Ethereum gas fees with ERC20 tokens and transactions without gas fees.
    • Paymaster is a smart contract deployed by dApps and can trigger the validatePaymasterOp function of Paymaster.
  • Wallet Factory:

    • 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 will trigger 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 Bundlers.
    • Users can submit UserOperations with filled initCode to request the 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.
    • 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.
    • Bundlers use multiple signature aggregator contracts to generate multiple aggregated signatures, rather than 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, the Bundler executes this set of UserOperations on the smart contract wallet.
    • The aggregator also needs to stake Ethereum on the entry point contract and maintain a good record of UserOperation services.

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 cases 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, allowing 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

  • Potentially Higher Fees: The cost of simple transfers using ERC-4337 is much higher than using traditional wallets (usually called EOA) because the former requires calling contracts. However, on Rollup networks, simple transfers using ERC-4337 may be cheaper than EOA, as it can aggregate signatures to reduce data volume on the mainnet.

  • Not Yet Finalized Standard: Expanded transaction scalability leads to increased attack vectors, potential unknown errors or security risks when migrating to a new standard, 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 support for native AA.

Optimism: ❌

Optimism version 1 has 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 about supporting account abstraction.

Arbitrum: ❌

While 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 verification and execution capabilities, and all accounts must implement these capabilities to verify signatures and ensure gas fees. Starknet prohibits calls to external contract state in the verification function 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 need for accounts with 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 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 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:

  • Golang implementation by Stackup - link
  • Python implementation by Candide - link
  • TypeScript implementation by Infinitism - link
  • Skandha by Etherspot - TypeScript implementation - link

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 their services using API keys, Bundler services are more difficult to monetize compared to other infrastructure (such as Paymaster) because Paymaster can easily earn fee differentials by collaborating with third-party deposit and withdrawal providers or DeFi protocol aggregators.

  • Critical Infrastructure
    To achieve decentralization, as many Bundlers as possible are needed for the verification and execution of UserOperations. 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 individual 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 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, and provide customization options for private memory pools.

Paymaster Services

  • Compared to Bundler services, Paymaster services are more 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 features.

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 own 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 stablecoins or DeFi giants on various chains
  • Practicality: Integration with NFT markets, launchpads, etc.
  • External support: From the Ethereum Foundation or other well-known venture capital firms

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

OKX:交易+Web3一站式体验!注册返佣20%,福利立享!
Ad
Share To
APP

X

Telegram

Facebook

Reddit

CopyLink