Original author:Rui
As many have said, Account Abstraction (AA) technology, especially ERC-4337, promises to revolutionize the user experience of self-hosted wallets and enable it to scale for mass adoption. However, as May 2023 draws closer, we must recognize that it is still early days for the standard and that opportunities and risks exist.
*Please note that with the rapid development of upgrades, the content of this article may soon become outdated, and this article is only based on my personal opinion.
TL;DR
ERC 4337 ：
The AA standard is still in its early stages, but many innovative builders are working to further develop it. Against the backdrop of ecosystem support and the popularity of large-scale products like MetaMask, we can expect AA to accelerate its development and produce exciting results.
L2：
The adoption of AA differs among L2 solutions. Larger L2s such as Optimism and Arbitrum do not natively support AA, while ZKSync and Starknet do.
Bundler service:
If we are bullish on AA, and all Ethereum-consistent EVM equivalent L2s do not support native AA, then the Bundler service is necessary to support AA in the network.
The open source nature makes the Bundler service non-exclusive, which makes the road to monetization difficult. In order to ensure network security and stability, different Bundler services are used.
Private Bundlers can make money by tailoring privacy, security, and other features to specific needs.
Paymaster Services:
Paymaster service is relatively centralized (compared to Bundler service), the contract is open source, but the backend is closed.
The Paymaster service has a profit model that can be combined with functions such as fiat deposits, exchanges, bridging, automatic payments, sessions, sponsorship fees, etc. to enhance payment scenarios and thereby improve 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, supported blockchains, etc.
The benefits of AA go beyond providing a smooth login experience (Web3 Auth is available via hosting). AA can also provide many benefits to dApps in complex and customized on-chain interactions.
BD is the key to this battle. Most wallets are targeting Defi and GameFi, and are committed to gaining ecosystem support, convincing large dApps, and finding breakthrough points.
The monetization model needs to be explored in depth. The To Business (To B) model may not make much money, nor will it 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 finding a sustainable model.
Learn about crypto wallets
Classification
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 is how they are 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 cryptocurrency holdings, contract wallets can have more complex rules and be used for specific purposes.
From Bitcoin Insider
Pain points
EOA wallet users need to pay attention to protecting private keys. Any mistakes or omissions made on the private key may result in the loss of funds, so the cost of using the EOA wallet is relatively high and the risks are high. Even experienced cryptocurrency users can lose control of their accounts due to one mistake or careless move. Complex operations, the inability to skip gas fees or the inability to pay gas fees, and limited wallet functions are all problems that plague users.
Smart contract wallets provide a solution to some of the problems, but Ethereum currently requires all operations to be packaged in transactions from ECDSA-protected EOAs. This will incur additional transaction fees and consume an additional 21,000 gas fees, along with potential centralization risks and complex operations: users need to manage two accounts and deposit ETH in a separate EOA to pay gas fees, or rely on a centralized relay system to pay.
These pain points gave birth to a new AA standard - ERC-4337.
ERC 4337 proposal:
CA problem
Today, these things can all be solved with contract wallets, but Ethereum itself requires that everything be wrapped in transactions originating from an ECDSA-protected EOA, which results in:
Additional transaction fees:Each user operation must be initiated by EOA, which requires an additional 21,000 gas fees.
Complexity and Centralization:Users need to deposit ETH in a separate EOA to pay gas fees and manage balances in both accounts, or rely on relay systems for payment, which are usually centralized.
There have been several attempts over the years to implement account abstraction on Ethereum-based blockchains, such as EIP-86 and EIP-2938. However, none of these methods work because they all require modifications 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 account abstraction function of the smart contract wallet into multiple ports:
Bundler:
Bundler is an EOA. Since all transactions must be initiated by EOA, with Bundler, users can trigger smart contract wallet transactions without creating and remembering EOA private keys.
Bundlers role: verify UserOperation, package a set of UserOperation objects into a single bundled transaction. Broadcast the contents of the authenticated UserOperation 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 executing a UserOperation. Similar to a relayer for a normal transaction, Bundler can obtain the MEV by ordering the UserOperation in the bundled transaction.
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.
Verification and execution with handleOp: The handleOp function uses UserOperation as an input parameter. First, the UserOperation is verified on the chain, checking whether it is signed by the specified smart contract wallet address, and the wallet has enough gas fees to compensate Bundler. If the verification is successful, the input parameters are executed based on the function signature.
Tokens that need to be deposited into the smart contract wallet pay gas fees to Bundler: When Bundler uses EOA to trigger handleOp, gas fees will be generated. Smart contract wallets can pay gas fees with their own balances, or request payment from Pymaster. Possible failure: Insufficient gas fee, verification step fails; even if there is sufficient gas fee, UserOperation execution step may fail, such as runtime error. Regardless of whether the execution is successful or not, the entry point contract will pay the gas fee to Bundler to trigger the handleOp function. The entry point contract provides the smart contract wallet with the functionality to add or withdraw tokens as collateral.
Smart Wallet:
The smart contract wallet main contract separates the verification and execution steps of UserOperation. By decoupling it, Bundler can verify UserOperation off-chain, filtering out malicious transactions without paying gas fees.
The validation steps are defined in the validateOp function: the first time validateOp is called, Bundler simulates off-chain verification, verifies the signature in UserOperation, and ensures that the smart contract wallet has sufficient gas balance; the second time validateOp is called, the entry point contract is executed. Perform on-chain verification before UserOperation.
Paymaster:
Paymaster defines the gas abstraction logic of smart contract wallets, including the use of ERC 20 fungible tokens to pay Ethereum gas fees and transactions without gas fees.
Paymaster is a smart contract deployed by dApp that can trigger Paymasters validatePaymasterOp.
Wallet Factory:
Wallet Factory is a public contract for creating smart contract wallets. When the wallet factory address and the parameters of the new smart contract wallet are implanted in the initCode, Bundler will trigger the corresponding Wallet Factory to create a smart contract with the specified parameters. The popular Wallet Factory code is fully audited, so creating wallets with Wallet Factory is safer.
Wallet Factory needs to stake ETH on the entry point and continue to provide good service to UserOperations in order to get more traffic from Bundler.
Users can submit a UserOperation with initCode filled in to request Bundler to create a CA wallet.
Users can choose Wallet Factory with specific customization parameters to customize their CA wallet.
Signature aggregator:
Signature aggregators are used to aggregate signatures of multiple transactions into bytes for faster verification and execution of transactions. Different smart contract wallets use different signature algorithms, and UserOperations need to be aggregated using the same signature algorithm first.
Saving gas fees: Since on-chain encryption calculations consume a lot of gas fees, aggregate signature schemes (such as BLS) can save gas fees during on-chain verification.
Bundler uses multiple signature aggregator contracts to generate multiple aggregate signatures instead of validating UserOperations one at a time.
Bundler passes the UserOperation array, aggregate signature, and aggregator address to the entry point, and each UserOperation group session calls its corresponding signature aggregators validateSignature function.
After passing the verification, Bundler will execute this set of UserOperation on the smart contract wallet.
Aggregators are also required to stake Ethereum on the entry point contract and maintain a good UserOperation service record.
Advantages of AA
Gas abstraction:
The Gas abstraction includes gas-free transactions and uses any ERC 20 token to pay gas fees. This logic can be performed in the Paymaster contract or via a relayer. For AA, many smart contract wallets themselves can implement EIP 4337-compliant Paymaster contracts and stake tokens 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 key as the legitimate wallet owner. The logic of 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 (Login with Ethereum), etc.
Transaction batching:
Transaction batching is a feature unique to smart contract wallets that allows wallet users to execute multiple transactions within a single on-chain transaction.
Cross-chain bridging and connection bridge integration:
Currently, many wallets are working with third-party providers to integrate fiat currency deposit and withdrawal channels and cross-chain bridges into the wallet. These deposit and withdrawal channels and cross-chain 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 pieces can be flexibly combined together.
Disadvantages of AA
from stackup
The handling fee is (maybe) relatively high:
The cost of making a simple transfer using ERC-4337 is much higher than using a traditional wallet (often called EOA) because it requires calling a contract.
However, on the Rollup network, simple transfers using ERC-4337 may be cheaper than EOA, as it aggregates signatures together to reduce the amount of data on mainnet.
Standards that have not yet been finalized:
Challenges include increased attack vectors due to expanded transaction scalability, the potential for unknown errors or security risks when migrating to new standards, and the need for strong and secure global entry point contracts to ensure that all transactions are properly signed and verified.
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, version 2 removed these opcodes for consistency and security reasons, and there has been no official announcement about supporting account abstraction.
Arbitrum: ❌
While there are currently a few smart contract wallets built on Arbitrum, there are no official announcements about supporting account abstraction.
Starknet: ✅
Starknet only has smart contract accounts with verification and execution functions, and all accounts must implement these functions to verify signatures and ensure gas fees. Starknet prohibits verification functions from calling external contract state to prevent unexecuted transactions. However, Starknet still has some differences from Ethereum, such as the lack of UserOperations, a Paymaster-like transaction fee abstraction protocol, and the need for an account with a token balance to create new contracts. Additionally, Starknets orderer cannot charge gas fees if a verified transaction fails, whereas 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 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 verification process. Paymaster can also call external storage during transaction verification.
AA infrastructure:
Currently, some excellent projects such as Stackup, Etherspot, Candide, Infinistism, and Pimlico are trying to build infrastructure.
Bundler service:
Builder:
StackupGolang implementation
CandidesPython implementation
InfinitismTypeScript implementation
Skandha by Etherspot —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 Bundler by copying the open source code.
Difficult to realize
Even though the RPC endpoint running Bundler charges service usage fees via API keys, the Bundler service is more difficult to monetize than other infrastructure (such as the payment contract Paymaster), because Paymaster can be used by third-party recharge providers or DeFi protocol aggregator providers. Cooperate and easily earn the difference in fees.
critical infrastructure
Validating and executing UserOperations requires as many Bundlers as possible for better decentralization. Because the only third-party Bundler service providers currently are Stackup and eth-infinitism, we really need more such Bundler service providers.
mechanism
Bundler delivers messages and propagates user actions itself, similar to a shared memory pool, without having to agree on specifics. Bundler has an important function of filtering spam, and for its own economic reasons, Bundler wants to monitor as much as possible to ensure the safety of the memory pool.
The difference between Bundler services:
Bundler services can be general-purpose infrastructure or built specifically 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.
The Bundler service supports private memory pools and public memory pools, and provides customization options for private memory pools.
Paymaster service
Compared with the Bundler service, the Paymaster service is relatively centralized. The contract is open source, but the backend is closed.
The Paymaster service has a monetization model that improves dApp usability by integrating with fiat deposits, exchanges, bridging, autopayments, sessions, sponsorship fees, and other features.
AA wallet and SDK:
product evaluation
Key management system:
Multi-signature logic (security): Only multi-signature logic such as 2/3 and 3/5 can be implemented;
Simple permission management (sequential): You can set weights for keys and then set thresholds for operating accounts.
Role-based permission management (Unipass): weights and roles can be set for keys. Different roles can perform different operations. Each role also has corresponding thresholds. 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
Unified multi-chain addresses
Supported blockchains
business
Business model: To b/To B+To C/ToC
Cooperate with dApps: Cooperate with stablecoins on various chains or giant infrastructure dApps such as DeFi
Utility: Integrate NFT marketplace, launchpad, etc.
External support: from the Ethereum Foundation or other well-known venture capital institutions
Original English reportFirst released in May 2023. For more Chinese investment research content, please follow the public account [SevenXVentures].
This article is original by the SevenX research team and is for communication and learning purposes only and does not constitute any investment reference. If you need to cite, please indicate the source.
