Author: Jerry Luo, Kernel Ventures
Reviewed by: Mandy, Kernel Ventures, Joshua, Kernel Ventures
TLDR：
Currently, the mainstream wallet types on Ethereum are EOA and SCW, but both face the problems of low execution efficiency and inability to initiate transactions independently. After several explorations, Ethereum developers have found that the best solution at this stage is account abstraction implemented through ERC4337.
The ERC4337 wallet uses Bundler to separate private keys from account entities, batch process transactions, and actively initiate transactions. At the same time, through the built-in code of the smart contract wallet, transactions can be automatically processed based on external information.
However, this proposal still faces challenges from other solutions such as protocol layer account abstraction and native account abstraction wallets. At the same time, the ERC4337 entry contract was only launched on the Ethereum mainnet in March this year, and many problems remain to be explored, and there is great uncertainty about the final solution. Finally, due to the single point nature of the Entry Point contract, ERC4337 is greatly restricted in its upgrade.
In order to solve these problems, ERC4337 developers also supplemented the EIP proposal to optimize without changing the entry contract. In the case of incompatibility between EOA-era Dapp and ERC4337, ERC4337 supporters have built a large number of ERC4337 wallet projects and Dapp projects focusing on ERC4337 wallet interaction. These projects provide various interactions that EOA accounts in DeFi and SocialFi can enjoy and optimize operability.
In general, ERC4337 is still the optimal solution for achieving account abstraction at this stage. Through Paymaster's compensation contract, the threshold for users to participate in DeFi is lowered, and project parties can provide 0 gas or low gas transactions to attract more users to participate. By packaging and batching transactions, the user experience in SocialFi and GameFi is greatly optimized, providing more diverse interaction options for participants in SocialFi and GameFi.
1. Background
The trade-off between decentralization and convenience has always been a major problem that has troubled crypto participants. If you want to embrace decentralization, you must abandon the convenient Web2 operation mode. The receiving operation changes from a simple click of a button to a series of processes such as keeping mnemonics, signing private keys, and setting nonce values. If you want to pursue convenience, the collapse of a series of centralized institutions such as FTX and JPEX makes it impossible for us to ignore the importance of account ownership. To solve this problem, Ethereum developers have made a series of attempts to make Web3 accounts have the convenience of Web2 - account abstraction. At this year's ETHCC conference, Ethereum founder Vitalik Buterin summarized these attempts, among which the ERC4337 standard received the greatest consensus from developers.
2. ERC4337 Account Abstraction Principle
ERC4337 mainly involves three objects in the process of separating control and ownership from the account subject: UserOperation, Bundler and on-chain contracts. UserOperation mainly includes user input, Bundler completes the process of packaging and triggering transactions, and the on-chain contract consists of Entry Point, Paymaster Contract and Wallet Contract, which mainly implements complex verification and execution logic.
UserOperation: UserOperation contains all transaction-related information submitted by the user. The following figure shows the parameters required to be entered in UserOperation and the input parameters required to initiate a transaction with a normal EOA account.
Image source: Kernel Ventures
The biggest difference between the two is that the sender can be specified in the ERC4337 wallet, unlike the default ECDSA decryption address as the transaction initiator in EOA, so the ERC4337 wallet realizes the separation of account subject and ownership. Secondly, the paymasterAndData parameter is added in ERC4337 to set the specific information of the payment contract. The specific role of the payment contract will also be explained later.
Bundler: Bundler is essentially an EOA account. For incoming UserOperation, it first verifies the code logic in calldata that involves interaction with the validateOp function of Wallet Contract. If it contains codes such as TIMESTAMP, BLOCKHASH, or access outside the wallet storage, Bundler will reject the UserOperation to prevent a form of attack called malicious simulation. After verification, Bundler will package multiple incoming UserOperations and broadcast them to the public or private mempool after verification. At the same time, since smart contracts in Ethereum must be triggered by EOA accounts, Bundler will subsequently interact with Entry Point Contract to execute UserOperation. In this process, Bundler can use the difference between the maximum priority fee and the actual gas, as well as the MEV income in the sorted bundled transactions. Therefore, the rise of ERC4337 may also bring a new mining method for Bundler miners to Ethereum.
Entry Point: Entry Point is a smart contract used to verify and execute the content in UserOperation. It is triggered by Bundler, which realizes the separation of Bundler and smart contract wallet. At the same time, Entry Point is a singleton contract in ERC4337. Each Wallet Contract in ERC4337 will give the Entry Point contract address a special authentication when it is created, which grants special permissions in the interaction process. When Bundler calls the Entry Point contract, it will trigger the handleOps function in the contract. This function will first check whether the wallet has enough gas to compensate Bundler. If not, the transaction will be rolled back directly. In addition, the smart contract wallet can also choose to have the Paymaster contract pay for the gas on its behalf, which we will mention in the subsequent content. If all the verifications are passed, the _executeUserOp internal function in the contract will gradually execute the content in the calldata of UserOperation and call the corresponding function in the smart contract wallet. After everything is over, the remaining gas will be compensated to Bundler.
Wallet Contract: Wallet Contract is essentially a smart contract wallet. There is a multiCall function in the contract that can batch process the data in the calldata from UserOperation, thereby greatly reducing gas consumption. However, one point that is very different from the execution process of ordinary smart contracts is that in the multiCall function, the content in UserOperation is not executed directly, but is divided into the processes of validateOp and executeOp. If the content in UserOperation cannot pass validateOp, the execution will be automatically terminated, and the gas consumption generated during the whole process will be borne by the Bundler itself. Once the executeOp function is executed, no matter what the reason is for the termination of the contract execution, the gas consumption generated will be borne by the Wallet Contract. This mechanism not only effectively ensures that the Bundler can obtain legitimate benefits through its own packaging behavior, but also prevents Dos attacks initiated by malicious Bundlers, which waste the eth stored in the Wallet Contract.
Paymaster: Paymaster is not required in ERC4337. When the paymasterAndData parameter in UserOperation is not empty, the specified Paymaster contract will pay gas for Bundler. During this process, Bundler will trigger the validatePaymasterOp function in Paymaster. The function of this function is to pay gas for the specified UserOperation according to the user's customized requirements after checking whether there is enough balance in Paymaster to support the payment of gas. It is worth noting that ERC4337 itself does not specify a standard to sort the priority of Paymaster use. Bundler needs to select the best Paymaster based on the off-chain record of Paymaster's past payment and eliminate the Paymaster of lower quality. This process forms competition among Paymasters, which helps to improve the efficiency of network operation.
Signature Aggregator: Since ERC4337 supports non-ECDSA signature algorithms, we first need to classify UserOperations that use different signature algorithms, and then Bundler generates an aggregate signature for similar transactions through Signature Aggtegator. All transactions contained in it can be verified once, which greatly reduces the consumption of gas fees.
Overall, in this process, the user first sends a UserOperation containing user-defined parameters to the Bundler. If there is a paymasterAndData parameter, the payment contract will be called to pay the gas fee. If there is an initCode parameter, the user will create a new smart contract wallet according to the code logic inside. Finally, in order to reduce the gas consumption of the signature verification process, ERC4337 adopts a batch packaging transaction method, using Signature Aggregator to package the same UserOperation to generate an aggregate signature, which is only verified once. When the off-chain Bundler's simulated verification and the actual verification on the chain are passed, the smart contract wallet successfully executes the user's customized function in the UserOperation and returns the excess gas to the Bundler as a reward.
Image source: Kernel Ventures
In comparison, it is extremely simple to initiate a transaction using an EOA account. It only requires an EOA account to sign the transaction data and then broadcast it to the entire network. The broadcasted transaction will be packaged after being verified by the node, and finally recorded on the chain by the node with accounting rights selected by the POS mechanism. This process is very simple, and there is no middleman Bundler and Entry Point entry point contract because there will be relatively small gas consumption. At the same time, security is only related to the ECDSA encryption algorithm, and there is no inherent security risk caused by complex contract logic. However, in this process, the private key and account control are uniquely bound and cannot be changed, and all transactions must be signed and verified one by one, and cannot be processed automatically.
Image source: Kernel Ventures
In summary, ERC4337 realizes the separation of private keys and account ownership, reduces the gas consumption of complex transaction processes through batch transactions, eliminates the Ethereum balance entry threshold of wallets through payment contracts, and realizes the diversification of signature methods and customization of account functions through smart contract wallets. These improvements have made great progress in the convenience of use and functional diversification of Web3 accounts.
3. Current types of Ethereum wallets and their advantages and disadvantages
EOA (External Account): Ethereum EOA accounts are controlled by private key signatures, and the private key is generated by a mnemonic consisting of 12 words. Although EOA accounts are operationally active and can be traded actively. However, to ensure the ownership of EOA accounts, a 64-bit string of hexadecimal numbers or 12 mnemonics must be properly preserved, which brings a lot of inconvenience to users. At the same time, transactions involving identity authentication in EOA accounts need to be signed one by one, which is extremely inconvenient, equivalent to a separate confirmation for each state rewrite and permission change behind a confirmation. Finally, using an EOA account to initiate a transaction requires pre-transfer of Ethereum into the account, which also raises the threshold for using the wallet.
SCW (Smart Contract Wallet): Smart Contract Wallet has greatly improved the convenience and automation of operation compared to EOA Wallet. Through the built-in code of smart contracts, transactions can be packaged and complex operations can be automatically executed according to user intentions. However, SCW has far lower permissions than EOA and cannot automatically execute transactions. The initiation of transactions requires an EOA account to trigger.
MPC (Multi-party Computation Wallet): MPC wallet breaks up the private key and gives it to multiple entities for safekeeping, and then splices it when a signature is needed. This sounds very similar to a multi-signature wallet, but there are many differences between the two in essence. First, there is only one private key in MPC, and we just keep the private key in shards. Second, the verification of multi-signatures is completely through smart contracts on the chain, while the threshold setting and signature generation of MPC are all performed off-chain. MPC wallet effectively avoids single point failure, and there is no need to worry about losing the private key in EOA and thus losing account ownership. However, the generation process of signatures off-chain is a centralized process, and a strict review system is required to prevent possible evil. At the same time, MPC is now mostly customized products and is not open source, so it is difficult to embed modularly in the development process, which increases the development cost. But one point that needs to be emphasized is that there is no competition between MPC wallet and AA wallet mentioned later. The pain point solved by MPC is the preservation of private keys, while the pain point solved by AA is to improve the flexibility of the transaction process. The two can be used in combination in future development.
AA (Account Abstraction): The possibility of account abstraction can be traced back to EIP86 in 2017. The proposal proposed to turn all accounts into contracts, allowing users to freely define their own security models. However, this proposal involves changes to the Ethereum consensus layer, which is relatively difficult and has a series of possible security issues. Therefore, EIP86 and subsequent proposals involving changes to the Ethereum consensus layer or protocol layer represented by EIP86 have been shelved indefinitely. Until the proposal of EIP2938, the changes to the underlying Ethereum were greatly reduced, and the security problem was solved by setting the node's memory pool rules. The overall solution idea of account abstraction has shifted to how to achieve account abstraction on the basis of only changing the smart contract layer. In 2021, ERC4337 was proposed to completely realize account abstraction on the premise of only making changes at the smart contract layer. In March of this year, the Entry Point entry contract of ERC4337 was deployed on Ethereum, and account abstraction entered the ERC4337 era.
4. Challenges and Responses
4.1 Account abstraction standards are undetermined
Consensus layer account abstraction: First of all, ERC4337 is not the only solution for account abstraction on Layer1 of Ethereum. The consensus layer account abstraction led by EIP2938 is only temporarily shelved rather than completely rejected. Perhaps from the current stage, the benefits brought by account abstraction cannot drive developers to make changes at the bottom of Ethereum. But as the development of ERC4337-style account abstraction reaches a bottleneck, people will pursue a better user experience. At this time, the consensus layer account abstraction solution that can increase the permissions of the contract account so that it can actively initiate transactions, remove the Bundler and reduce transaction costs and transaction complexity may re-enter everyone's consideration.
EIP proposals to be determined: Secondly, ERC4337 has been officially implemented for less than a year, and problems are still being discovered and improved. Because the Entry Point cannot be changed, the EIP proposals for optimizing ERC4337 are mostly related to the optimization of Bundler and opcodes, such as the endorser contract in EIP-1589 that can prevent MEV attacks, and the opcode added in EIP-3974 involving consensus layer changes to entrust the control of EOA accounts to smart contract accounts. Whether these proposals can be passed remains to be discussed by the Ethereum development community.
Layer2 native account abstraction: Finally, there are various native account abstraction wallets on Layer2, such as Starknet and zkSync Era. Starknet uses ECDSA signatures, which are different from Ethereum, which greatly reduces the cost of the signature and verification process, thereby greatly reducing gas consumption. At the same time, there are only contract accounts in Starknet, which are top-level accounts by default. Contract accounts can directly initiate transactions without complex contract layer operations, providing developers with a more flexible and rich application design environment.
In summary, although ERC4337 is the most widely recognized option for account abstraction on Ethereum today, it is not the only option.
4.2 ERC4337’s own defects
Higher fixed gas cost: The gas consumption for basic operations in ERC4337 wallets is 42,000 gas, which is twice that of ordinary EOA accounts. The specific reasons are as follows:
Image source: Kernel Ventures
It can be seen that due to the introduction of smart contracts, huge gas consumption is generated in the process of executing contract business (unpacking UserOperation, executing condition verification, on-chain hashing, etc.) and triggering events and publishing logs on Ethereum. At the same time, the transaction batching proposed in ERC4337 to reduce transaction costs has been proven to be impractical in actual transactions. Most users often do not need to package a large number of transactions in one call. The advantages of ERC4337 batch transactions can only be brought into play in very few scenarios such as project parties issuing airdrops. In addition, once the UserOperation, which was originally intended to share transaction costs, fails to execute on the chain, it will also bring higher losses to the wallet account or Bundler.
High upgrade cost: In the Entry Point smart contract, the entryPoint() function can return a parameter that conforms to the EntryPoint interface. In the Wallet Contract, this parameter can be used to determine whether the external transaction comes from the function call in the entryPoint contract. However, this requires that the address of EntryPoint must be hard-coded in each generated smart contract account body. If the EntryPoint contract is to be upgraded, all smart contract account bodies must agree. When ERC4337 is widely accepted, the difficulty of this change will be no less than that of the consensus layer. Therefore, the deployment of ERC4337 must be very cautious, and security audits must be carried out in all aspects. And if performance optimization is to be carried out in the future, it will also be a very difficult task.
Contract security issues: In the original EOA account, the transaction process is simple, and transaction security is ensured by cryptography and consensus mechanisms at the consensus layer. The encryption algorithm and the consensus mechanism of the distributed system are technologies that have been tested for a long time and certified by the academic community, and the possibility of vulnerabilities is extremely low. However, the ERC4337 wallet changes many operations that were originally verified by the blockchain consensus mechanism to contract function judgments, which places extremely high demands on the security of the contract itself. As the transaction logic becomes more complicated, the security risk also rises sharply.
4.3 ERC4337 update cost
Traditional wallet giants wait and see:
According to ChainCatcher, Alex Jupiter, head of MetaMask products, said in an interview with Decrypt that although various technologies for optimizing user experience such as account abstraction and EOA were mentioned many times during the EthCC, MetaMask will adopt these technologies very cautiously.
As a traditional wallet provider, MetaMask can help users create EOA accounts conveniently and charge fees by providing decentralized Swap services. For traditional wallet giants that have already formed a stable profit model, most of them are unwilling to take risks and make changes. At present, they are mostly taking a wait-and-see attitude towards account abstraction. Although they are actively exploring, they always remain cautious in their attempts.
Dapp update costs
Existing Dapps on Ethereum include Opensea, Uniswap, MetaMask Swap, etc., all of which use EOA accounts as the default service objects. If these Dapps are to be fully compatible with ERC4337 wallets, the review mechanism for Dapp-wallet interaction and the token staking mechanism need to be changed. To complete this change, the smart contract code of mainstream Dapps today needs to be modified, and the security risks and update costs that may arise in this process are immeasurable. In addition, considering the large number of transaction resistances to contract accounts by Dapps caused by the previous Tornado contract, the workload of this update will be even greater.
4.4 ERC4337 and cross-chain
In the cross-chain bridge that interacts between Ethereum and Layer2, the default payment address of the receiving network is often the payment address on the sending network. This is completely fine in traditional EOA accounts, because the same private key can achieve the same control effect on the addresses on both networks through signing. However, in the ERC4337 wallet, the transfer initiation address is the contract address, which is not controlled by the private key, so the payment address cannot be set to the same address as the sending network. Therefore, there are incompatibility issues between the ERC4337 wallet and almost all cross-chain bridges between Ethereum Layer1 and Layer2 today.
4.5 Improvements to ERC4337
EIP proposal improvement: Although the ERC4337 standard itself is difficult to change, we can supplement ERC4337 by proposing new EIP supplementary proposals, such as EIP5189 proposed in June 22, which reduces the risk of the Bundler screening process by introducing the endoser contract and further prevents malicious attacks by MEV robots. In addition, there are a large number of 4337-related proposals awaiting review, such as EIP3074 and EIP5003.
Supplement of cross-chain protocol: The most fundamental solution to the cross-chain problem of Ethereum Layer1 and Layer2 is to start from the bottom layer of the cross-chain bridge. Users can set the receiving address on the receiving network by themselves, but the cost of this improvement is high, and it involves the redeployment of the cross-chain bridge and the security of the new contract. At present, the ideal solution is to set up a trusted third-party EOA account to act as an intermediary between the ERC4337 wallet and the cross-chain bridge. This requires the intermediary to have a large amount of ETH or Layer2 token pledged. Each time before helping to execute a cross-chain transaction, the excess assets are pledged first, and the smart contract wallet that receives the payment returns the pledged tokens after receiving the transfer, and gives a certain reward.
ERC4337 self-built Dapp: Since the entry point contract was deployed in March this year, a large number of wallet projects developed based on ERC4337 have landed on Ethereum. These projects are compatible with ERC4337 wallets, such as the highly scalable smart contract wallet project ZeroDev Kernel, and the wallet abstraction project MynaWallet in official cooperation with the Japanese government... These projects have formed a huge account abstraction wallet ecosystem. It can be seen that even though traditional wallet vendors are mostly on the sidelines, the use of UserOperation on Ethereum has continued to rise since March this year and is in a state of rapid expansion.
Image source: Dune
5. Opportunities brought by ERC4337
Image source: Kernel Ventures
5.1 ERC4337 Miner Bundler
Bundler was introduced in ERC4377 to separate the account subject from the account control rights. Only an EOA account with a certain amount of Ethereum stored can act as a Bundler. Compared with the mining machine mining under the traditional POW mechanism, this new mining method has almost zero investment cost and no possible legal risks. Compared with the pledge mining under the POS mechanism, Bundler has a very low participation threshold. It does not require staking 32 Ethereums, and only requires retaining the gas that can interact with the Entry Point contract once. The essential reason for this difference is that it is much more difficult for Bundler to do evil than the verification node, and the benefits of doing evil are much less than those of the verification node. Therefore, it is not necessary to stake a large amount of Ethereum to ensure the balance of rewards and punishments in the overall operation of the ERC4377 protocol. Finally, compared with the staking income in the liquidity pool, Bundler has a shorter lock-up time, which makes the assets more liquid. When Ethereum faces a large selling pressure, users can withdraw in time to reduce losses. Given the above advantages, Bundler is likely to become a new investment method on Ethereum in the future, and further derive Bundler pools similar to Bitcoin mining pools and Ethereum staking pools, with the characteristics of low cost, stable returns, and high liquidity.
5.2 Intent Centric under ERC4337
Intent Centric is centered on "intention", which means that users do not need to understand the specific execution steps when performing operations, but the program automatically performs modular operations at the bottom layer according to user needs. For investors who are new to Web3, the various signatures and gas settings in transactions are very unfriendly, so even if they are interested in crypto, they can only invest with the help of CEX and cannot enter the real Web3 world. The essential reason for this phenomenon lies in the difference in operation intentions between DEX and CEX. For example, if someone wants to use DEX to exchange USDT for ETH in a way that makes the most profit to himself, then he must first select from many trading pools, select the best one, then sign to authorize the Dapp to have certain permissions, then sign to confirm that USDT is pledged into the liquidity pool, and finally sign to confirm that the equivalent ETH is extracted from the liquidity pool. Each of the above steps is a behavior-based operation, and one operation corresponds to a behavior at the bottom layer. But in CEX, all operations are intention-based operations. In order to realize the intention of exchanging the USDT held by the user for ETH in the most favorable solution, only a market order is needed, and the user does not need to set the specific order price. Although some people have proposed that by completing this series of processes by themselves, they can have a more specific understanding of the transaction process and prevent the inherent problems that may exist in the modular process. But in general, there are still very few people who have this ability. Most people only need a modular process that can realize their intentions, and they are not willing to understand the specific operations behind it. At the same time, the manual operation process is also more risky than the modular process that has been tested for a long time. Before the birth of ERC4337 account abstraction, EOA account execution efficiency was low, and transactions needed to be signed and confirmed one by one. Therefore, the Intent Centric application that needs to modularly process transactions according to user intentions has been developing slowly on Ethereum. In ERC4337, by introducing UserOperation and Bundler, users do not sign a transaction every time, and then put it into the main memory pool after verification and wait for it to be put on the chain. Instead, the transaction (UserOperation in ERC4337) is first sent to the backup memory pool and mixed with its own or other users' UserOperations, waiting for the Bundler to bundle these UserOperations and submit them to the entry contract for verification and execution.In this process, users only need to declare or sign their preferences, and the specific process is selected and executed by Bundlers according to the existing consensus layer or contract layer logic, without the need for users to participate in any specific process. In Dapp, we can design the Intent Centric logic. When users want to complete a certain goal, they only need to sign their intentions, without having to choose transaction behaviors and sign them one by one as before. It can be expected that with the full promotion of ERC4337, Intent Centric Dapp will be popularized on Ethereum, thereby greatly reducing the entry threshold of Web3.
5.3 DeFi under ERC4337
DeFi was closely integrated with EOA accounts in the last bull market, which improved the diversity of crypto investors' on-chain interaction functions, provided various financial methods such as staking, market makers, and lending, and ultimately led to DeFi Summer. However, DeFi's complex transaction process and on-chain losses set a huge threshold for ordinary users to participate, hindering the further promotion of DeFi. ERC4337 wallets combined with DeFi can provide an Intent Centric interaction method, allowing users to get an experience close to CEX. At the same time, gas-free transactions can be achieved through Paymaster in ERC4337. Some operators can also use this method to lower the threshold of DeFi and attract more people to participate. However, unlike tracks such as SocialFi and GameFi, DeFi involves the transfer and staking of a large number of tokens, which has extremely high requirements for security. The contract layer of account abstraction is relatively complex, and it is easy to have security vulnerabilities that cause losses to users' encrypted assets. At the same time, since the US government issued a ban on many money laundering contracts such as Tornado, many DeFis will strictly review the contract addresses or even suspend interaction with them. As a result, there are many incompatibilities between smart contract wallets and the current DeFi system. In the process of interacting with DeFi contracts, there is even the possibility of being mistakenly judged and blacklisted, which also brings many obstacles to the promotion of ERC4337 wallets in DeFi.
5.4 Full-chain games under ERC4337
Different from the "semi-chain" games in the early GameFi, only the game assets and props were processed on the chain, and the asset security was ensured in a decentralized form. The full-chain game writes the core logic and economic model of the game into smart contracts on the chain, and conducts game interactions on the chain, realizing the decentralization and high security of the whole process. However, the current Web3 games have also paid a huge price to achieve the full chain. The first is the surge in gas fees. The interaction of on-chain games, props, and scenes needs to be recorded on the chain at every step, which has caused a surge in game costs. In order to solve this problem, the interaction logic of the full-chain game is often very simple at this stage, but this also limits the user's transaction experience. At the same time, if the traditional EOA account is used, the interaction process of the full-chain game must endure an extremely cumbersome signature verification process to confirm each interaction, which greatly reduces the game experience. After the introduction of account abstraction, the transaction cost is greatly reduced. The transaction confirmation link only needs to perform BLS aggregate signatures and one signature verification, which greatly saves the gas consumption of the cryptographic verification process. In addition, by batch packaging transactions, the original confirmation process can be shortened. At the same time, the introduction of personalized smart contract accounts can facilitate the modular construction of full-chain games, thereby improving development efficiency. However, so far, the combination of account abstraction and full-chain games has appeared more on Layer2 such as StarkNet, which has implemented native account abstraction, such as Loot Realms, Cartridge and other projects. However, the reason is not that Ethereum is not suitable for the combination of full-chain games and ERC4337 wallets, but because the Entry Point contract was only completed on the chain in March this year, most full-chain games based on ERC4337 on Ethereum are still under development. It can be foreseen that many full-chain games based on ERC4337 will be launched on Ethereum in the near future, which will greatly improve the interactive experience of full-chain games on it and reduce the interactive costs. Some existing large full-chain games on Ethereum, such as Dark Forest, Wolf Games, etc., may also consider making changes to the contract layer to be compatible with the interaction with ERC4337 accounts.
5.5 SocialFi under ERC4337
Trapped in the bundling mechanism of private key accounts and the limited interactive functions of EOA accounts themselves, SocialFi has long faced the problems of high participation barriers and difficult account management. Poor user experience has greatly limited the development ceiling of the SocialFi project. The introduction of account abstraction will completely change this situation, but the trade-off between convenience, recoverability and security must be weighed according to the importance of SocialFi's specific Web3 account. The first is the separation of private keys and account control rights. Users no longer need to keep complex and disordered private keys or mnemonics, and can dynamically adjust account passwords. For example, the ERC4337 project Ambire, launched at the end of 2021, realized the creation of Web3 accounts and private key recovery via email. Secondly, the batch transactions provided by ERC4337 solve the Web3 threshold problem raised at the beginning of this article. The problem that can be solved by a button in Web2 can also be solved by a button in Web3. Finally, the introduction of custom code logic in ERC4337 accounts is also closer to the personalized design of accounts in Web2, allowing each SocialFi account to introduce different account functions according to its own preferences, similar to the choice of whether to open a channel function in QQ based on user preferences.
6. Future Outlook
As of press time, the number of Web3 users is about 300 million, accounting for only about 4% of the world's population. Compared with the 6 billion Internet users in the world, there is still a lot of room for development. Web3 wants to catch up with the size of Web2 and cross the 1 billion mark. Lower participation thresholds and more account customization functions are prerequisites. Among all the options currently available to achieve this goal, ERC4337 has relatively low risks, a relatively mature framework, and has been recognized by the Ethereum Foundation and major developers. Therefore, since the Entry Point entry contract was deployed on Ethereum, the number of account abstraction users has also ushered in explosive growth.
Image source: Dune
Although ERC4337 has now been widely recognized and promoted by the Ethereum community, it still faces many problems in its actual implementation. The first is the pending standard itself. Since many supplementary proposals of ERC4377 are still under review, the final overall implementation form cannot be determined now, which has brought great obstacles to the development of ERC4377 ecological projects. Secondly, there is the update cost of ERC4377. Once the entry point contract is deployed, most wallets in the entire network need to uniformly cover the original address to complete the update, which is extremely costly. Finally, there is the incompatibility problem with existing Dapps and cross-chain bridges. If ERC4337 is to be fully implemented, Ethereum's existing Dapps need to be upgraded on a large scale, facing extremely high security risks and costs.
However, ERC4377 has also made positive responses to the above problems, such as improving the packaging efficiency of Bundler by adding external smart contracts, increasing the permissions of smart contract accounts by adding opcodes, and supplementing EIP proposals to solve the problem of difficulty in upgrading Entry Point. At the same time, in the face of the incompatibility of traditional Dapps, ERC4337 actively builds its own ecosystem to promote the wider application of account abstract wallets on Ethereum. The full implementation of ERC4337 wallets can realize EVM Intent-Centric at the Ethereum virtual machine level, and further abstraction of EVM Intent-Centric in Dapps can make the operations in Web3 reach the simplicity of user intent-centered in Web2. If Intent Centric can be fully implemented in Ethereum Dapps, DeFi, GameFi and almost all tracks that require ease of operation and automation will greatly optimize the user experience, thereby attracting more outsiders to participate. However, the increment of tracks such as DeFi that directly involve token transfers will be relatively conservative because it has more stringent requirements for security. Tracks such as SocialFi and GameFi are more concerned about user experience and relatively weaken security. However, due to the limitations of EOA accounts, complex interactive designs have not been possible. Through ERC4337, these tracks can solve the two major problems of high user thresholds and poor user experience, thus ushering in a large-scale growth in the number of users, and may even serve as the main outbreak point in the next round of bull market.
Kernel Ventures is a crypto venture capital fund driven by the research and development community, with more than 70 early-stage investments, focusing on infrastructure, middleware, dApps, especially ZK, Rollup, DEX, modular blockchain, and verticals that will carry billions of future crypto users, such as account abstraction, data availability, scalability, etc. Over the past seven years, we have been committed to supporting the development of core development communities and university blockchain associations around the world.
References
ERC4337 official documentation: https://github.com/eth-infinitism/account-abstraction/blob/develop/eip/EIPS/eip-4337.md
Implementation of contracts for ERC-4337 account abstraction via alternative mempool：https://github.com/eth-infinitism/account-abstraction
