Understanding Ethereum's ERC4337 Standard — What Opportunities Lie Ahead
Author: Kernel Ventures Jerry Luo
Editor(s): Kernel Ventures Mandy, Joshua
TLDR:
There are two wallet types on Ethereum: EOA and SCW, facing the problems of low execution efficiency and the inability to initiate transactions independently. Ethereum developers have gone through several explorations, and the best solution they have found at this stage is account abstraction implemented through ERC4337.
- ERC4337 wallet realizes the separation of private keys and account subjects through Bundler, batch packaging transactions, and the ability to launch transactions. What's more, through the built-in code of the smart contract wallet, transactions can be automatically processed based on external information.
- But ERC4377 still faces challenges from other solutions such as consensus layer's account abstraction and native account abstraction wallets. Additionally, the ERC4337 entry contract was only launched on the Ethereum main network in March this year with problems to be explored and uncertainty in the decisive solution. Finally, due to the single-point of the Entry Point contract, ERC4337 is greatly limited to upgrades.
- In order to solve these problems, the developers of ERC4337 have also supplemented the EIP proposal to optimize without changing the entry contract. At the same time, they have built a large number of ERC4337 wallet projects and Dapp projects focusing on ERC4337 wallet interaction to cope with resistance from EOA.
In general, ERC4337 is still the bset solution for achieving account abstraction at this stage. Through Paymaster's compensation contract, the sill for DeFi can be greatly optimized snice community can provide 0 gas or low gas transactions to attract more users to participate in. Through packaging and batch processing of transactions, users' participation experience in SocialFi and GameFi can be greatly improved, which will provide more diverse interaction options for participants in SocialFi and GameFi.
Background
Trade-off between decentralization and convenience has always been a major dilemma for crypto participants. To embrace decentralization, a series of complex processes should be accepted such as storing mnemonics, private key signatures, and setting nonce values. To pursue convenience, the thunderstorms of a series of centralized institutions such as FTX and JPEX make it impossible for us to ignore the importance of account ownership. Up to now, Ethereum developers have made a series of attempts to achieve accounts with the convenience of Web2 in Web3 - account abstraction. At this year's ETHCC conference, Ethereum founder Vitalik Buterin summarized these attempts. Among them, ERC4337 standard gained the greatest consensus among developers.
The Principle of ERC4337
ERC4337 mainly involves three objects: UserOperation, Bundler and on-chain contract in the process of separating control and ownership from the account subject. UserOperation is consisted of user input, while Bundler completes the process of packaging and sending transactions. The contract on chain has three parts: 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 needed in both UserOperation and a normal EOA account.
The biggest difference between the two is that the ERC4337 wallet can specify the sender instead of regarding the default ECDSA decryption address in EOA as the transaction initiator. Therefore, the ERC4337 wallet achieves the separation of the account subject and ownership. Secondly, paymasterAndData is also added to ERC4337 to set the payment contract. We will also explain the specific function of the payment contract later.
- Bundler: Bundler is an EOA account, which can verify the code logic in the calldata of UserOperation that interacts with the vaBundler: Bundler is an EOA account, which can verify the code logic in the calldata of UserOperation that interacts with the validateOp function of the Wallet Contract. If the calldata contains codes like TIMESTAMP, BLOCKHASH or the wallet storage for external access, Bundler will discard this UserOperation to prevent attack called malicious impersonation. After passing the verification, Bundler will package the UserOperations passed in and broadcast them to the public or private mempool after passing the verification. At the same time, since smart contracts in Ethereum must be triggered by the EOA account, Bundler must subsequently interact with the Entry Point Contract to execute UserOperation. In this process, Bundler can take advantages of the agio between the maximum priority fee and the actual gas, as well as the MEV income in the transaction sorting. Therefore, the rise of ERC4337 may also bring a new mining method to Ethereum.
- Entry Point: Entry Point is a smart contract used to verify and execute content in UserOperation which is triggered by Bundler. What's more, Entry Point is a singleton contract in ERC4337 with the completion of the separation between Bundler and smart contract wallet. Each Wallet Contract in ERC4337 will grant the Entry Point contract address some special permissions during the interaction process when it is created. 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 the gas, which will be mentioned in the subsequent content. After all verifications have passed, the _executeUserOp function in the contract will gradually execute the contents of UserOperation's calldata and call the corresponding function in the smart contract wallet. With all things done, 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 process the transactions in the calldata from UserOperation in batches, thereby greatly reducing gas consumption. However, in the multiCall function, the content in UserOperation is not executed directly, but divided into the processes of validateOp and executeOp. If the content in UserOperation can not pass validateOp, the execution will be automatically terminated with all gas consumption generated during the entire process borne by Bundler. Once getting inside executeOp, no matter what reason causes the contract execution to terminate, the gas consumption generated will be bore by the Wallet Contract. This mechanism not only effectively ensures that Bundler can obtain legitimate benefits through its own packaging behavior, but also prevents DoS attacks initiated by malicious Bundler from consuming the eth stored in the Wallet Contract. Finally, the wallet account development in ERC4337 adopts a modular design. Wallet providers have a large number of contract modules for users to expand and implement customized functions.
- Paymaster: Paymaster is not necessary 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 is to pay gas for the specified UserOperation according to user-defined requirements after confirm that there is sufficient balance in Paymaster to support gas payment. It is worth noting that ERC4337 itself does not stipulate a standard to prioritize the use of Paymaster. Bundler needs to select the best Paymaster and eliminate the lower quality Paymaster based on off-chain records of Paymaster’s past payment situations. This process creates competition among Paymasters, which helps improve network operating efficiency.
- Signature Aggregator: Since non-ECDSA signature algorithms are supported in ERC4337. So we need to classify UserOperations that use different signature algorithms firstly. Then, Bundler will generate an aggregate signature for similar transactions through the Signature Aggtegator. All transactions contained in it can be verified with one signature verification which greatly reduces gas fees. consumption.
Overall, in this process, the user first sends a UserOperation containing self-defined parameters to 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 in the signature verification process, ERC4337 adopts the method of batch packaging transactions, using Signature Aggregator to package similar UserOperations to generate an aggregate signature, which is verified only once. When both the off-chain Bundler's simulation verification and the on-chain actual verification pass, the smart contract wallet successfully executes the user-defined function in UserOperation and returns the excess gas to Bundler as a reward.
In comparison, using an EOA account to launch a transaction is extremely simple,signing the transaction data and broadcasting it to the entire network are the only processes needed. The broadcast transaction will be packaged after being verified by the node, and finally wrote on chain by the node selected by the POS mechanism. This process is very simple, without middleman Bundler or Entry Point contract, greatly reducing gas consumption. At the same time, security is only related to the ECDSA encryption algorithm, and there are no endogenous security risks caused by complex contract logic. However, in this process, the private key and account control rights are uniquely bound and can not be changed. All transactions must be signed and verified one by one, making the whole process inefficient.
All in all, ERC4337 achieves the separation of private keys and account ownership, reduces the gas consumption of complex transaction processes through batch transactions, eliminates the Ethereum balance access threshold for wallets through payment contracts, and implements signature methods through smart contract wallets. These improvements have made great progress in convenience and practicality of Web3 accounts.
Types, Pros and Cons of Current Ethereum Wallets
- EOA(externally owned account): Ethereum's EOA accounts are controlled through private key signatures, which are generated from a 12-word mnemonic phrase. Although the EOA account has operational initiative and can actively trade. To ensure the ownership of the EOA account, a 64-bit string of hexadecimal numbers or 12 mnemonic words must be properly preserved, which makes a lot of troubles to the users. Additionally, transactions involving identity authentication in EOA accounts need to be signed one by one, which is extremely inconvenient. It is equivalent to requiring separate confirmation for each status rewrite and permission change behind one confirmation. Finally, using an EOA account to initiate transactions requires pre-transfer of Ethereum into the account, which is very unfriendly to beginners.
- SCW(smart contract wallet): Comparing with the EOA wallet, the smart contract wallet has improved the convenience and automation of operation. Through the built-in code of smart contracts, transactions can be packaged and complex operations can be automated according to users' intents. However, SCW does not have the same authority as EOA, which can automatically execute transactions. The initiation of transactions in SCW requires an EOA account to be triggered.
- MPC(Multi-Party Computation): The MPC wallet breaks up the private keys and seperates them to multiple entities for safekeeping, and then splices them together when signatures are required. This sounds similar to a multi-signature wallet, but there are many differences between them. First of all, multi-signature verification is entirely excuted through smart contracts on the blockchain, while MPC’s threshold setting and signature generation are performed off-chain. The MPC wallet effectively avoids failure of single points, without the worry about losing the private key in EOA and thus losing ownership of the account. However, the generation process of signatures off-chain is a centralized process which requires a strict review system to prevent possible evil. At the same time, most MPCs are now customized products without opening to the public, so it is difficult to embed modules in the developing process, which increases development costs. But one thing that needs to be emphasized is that there is no competition between the MPC wallet and the AA wallet we mentioned later. The pain point that MPC solves is the preservation of private keys, while the pain point that AA solves is improving the flexibility of the transaction process. The two can be combined in future development.
- AA(abstract account): 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 represented by EIP86 involving changes to the Ethereum consensus layer or protocol layer have been shelved indefinitely. Until the proposal of EIP2938, changes to the bottom layer of Ethereum were greatly reduced with security issues solved by setting memory pool rules for nodes after which, the overall solution to account abstraction has changed to how to implement account abstraction based on the change of smart contract layer. In 2021, ERC4337 was proposed, completely realizing account abstraction only on the premise of making changes to the smart contract layer. In March this year, the ERC4337 Entry Point entry contract was deployed on Ethereum, and account abstraction entered the ERC4337 era.
Challenges and Solutions
The Ambiguous Methods of Abstract Account
- 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 just temporarily shelved . At this stage, the benefits brought by account abstraction cannot drive developers to make changes at the consensus of Ethereum. But as the development of ERC4337 account abstraction reaches bottleneck, a better user experience. At this time, the authority of the contract account can be increased so that it can actively initiate transactions. The consensus layer account abstraction solution that removes Bundler and reduces transaction costs and transaction complexity may once again enter the scope of everyone's consideration.
- EIP proposals to be determined: ERC4337's Entry Point contract is on chain for less than one year, whose problems are still being discovered and improved. Due to the difficulty of changing Entry Point contract, most of the EIP proposals temporarily put forward to optimize ERC4337 involve optimization of Bundler and opcodes, such as the endorser contract in EIP-1589 that can prevent MEV attacks, and EIP-3974 that involves changes to the consensus layer. Whether these proposals can be adopted for the added opcodes that escrow EOA account control to smart contract accounts 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 an ECDSA signature that is different from Ethereum, which greatly reduces the cost of the signature and signature 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 going through complicated contract layer operations, providing developers with a more flexible and rich application design environment.
All in all, ERC4337 is not the only choice of account abstraction on Ethereum.
ERC4337's Inner Defects
- Higher gas cost: The gas consumption for basic operations in an ERC4337 wallet is 42,000 gas, twice than that of a normal EOA account. Reasons are as follows:
As we can see, due to the introduction of smart contracts, huge gas consumption is generated in the process of executing contract services (unpacking UserOperation, executing condition verification, on-chain hashing, etc.) and triggering events to publish logs on Ethereum. At the same time, batch processing in ERC4337 has been proven to be impractical in real transactions to reduce transaction costs since users seldom need to package a large number of transactions in one call. In addition, once the UserOperation originally designed to share transaction costs fails to be executed 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 be used to return a parameter that conforms to the IEntryPoint interface. In the Wallet Contract, this parameter can be used to determine whether the external transaction comes from a function call in the entryPoint contract. However, this requires that the EntryPoint address must be written in each generated smart contract account subject. If the EntryPoint contract is to be upgraded, all smart contract account subjects must agree. When ERC4337 is widely accepted, this change will be no less difficult than changes to the consensus layer. Therefore, the deployment of ERC4337 must be very cautious and security audits must be carried out in all aspects. And if you want to optimize performance in the future, it will be a very difficult thing.
- Security of contract: The transaction in EOA account was simple, ensured through cryptography and the consensus mechanism of the consensus layer. Encryption algorithms and consensus mechanisms of distributed systems have been tested for a long time and certified by academic circles, with low possibility of failures over them. The ERC4337 wallet changes many verification from the blockchain consensus mechanism to contract function judgments, which places extremely high requirements on the security of the contract. As the transaction logic becomes more complicated, security risks also rise sharply.
Cost of the Promotion of ERC4337
- Exclusion from traditional wallet giants:
ChainCatcher: MetaMask product lead Alex Jupiter said in an interview with Decrypt that although account abstraction, EOA and other technologies to optimize user experience have been mentioned many times during EthCC, MetaMask will adopt these technologies very cautiously.
As a traditional wallet provider, MetaMask can help users easily create EOA accounts and collect handling fees by providing decentralized Swap services. For these traditional wallet giants who have formed a stable profit model, most of them are unwilling to take risks and make changes. By now, they often adopt a wait-and-see approach to account abstraction.
- Cost of Dapp's update
Existing Dapps on Ethereum include Opensea, Uniswap, MetaMask Swap,etc all use EOA accounts as their default service objects. To make Dapps be fully compatible with ERC4337 wallets, you need to change the review mechanism for the interaction between Dapps and wallets and the token pledge mechanism. To complete this change, the smart contract codes of all current mainstream Dapps need to be modified. The security risks and update costs that may arise from this process are immeasurable. In addition, considering the large number of Dapp transaction resistance to contract accounts caused by the previous Tornado contract, the workload of this update will be even greater.
ERC4337 and Cross-Chain
In cross-chain bridges where Ethereum interacts with Layer 2, it is often defaulted that the payment address on the receiving network is the same as the payment address on the sending network. This is no problem at all in traditional EOA accounts, because the same private key can achieve the same control effect on addresses on both networks through signatures. However, in the ERC4337 wallet, the transfer initiation address is the contract address and is not controlled by the private key. Therefore, the receiving address can not be set to the same address as the sending network. Therefore, there are incompatibility issues between ERC4337 wallets and almost all cross-chain bridges between Layer1 and Layer2 of Ethereum today.
The Improvement of ERC4337
- Improving EIP proposal: Although the ERC4337 itself is difficult to change, supplementing ERC4337 by proposing new EIP supplementary proposals, such as EIP5189 proposed on June 22, which reduces the risk of the Bundler screening process and further prevents it by introducing the endoser contract malicious attacks by MEV robots. In addition, there are a large number of 4337-related proposals pending review such as EIP3074 and EIP5003.
- Supplement to the cross-chain protocol: The most fundamental solution to the cross-chain problem between Ethereum Layer 1 and Layer 2 is to start from the bottom layer of the cross-chain bridge. enabling users to set the receiving address on receiving network by themselves, which is costly. , designing the redeployment of cross-chain bridges and the security issues of new contracts. Because the current ideal solution is to set up a trusted third-party EOA account to play the role of a middleman between the ERC4337 wallet and the cross-chain bridge, and this requires the middleman to have a large amount of ETH or Layer2 token pledge. For the first time, excess assets are pledged before helping to execute a cross-chain transaction. After smart contract wallet receives the transfer, the pledged token will be returned and a certain reward will be given.
- ERC4337's self-built Dapp: Since the entry point contract was deployed in March this year, a large number of wallet projects based on ERC4337 have been launched on Ethereum. These projects themselves are compatible with ERC4337 wallets, such as the highly scalable smart contract wallet project ZeroDev Kernel, and MynaWallet, a wallet abstraction project officially cooperated by the Japanese government…. These projects form an abstract wallet ecosystem on their own and do not rely on cooperation with traditional wallet developers. It can be seen that even when traditional wallet vendors hold a wait-and-see attitude, the usage of UserOperation on Ethereum has continued to rise since March this year and is in a state of rapid expansion.
ERC4337 Opportunities
New Coinbase——Bundler
Bundler was introduced in ERC4377 to separate the account subject from the account control rights. All you need is an EOA account that stores a certain amount of Ethereum to act as a Bundler. Compared with mining with expensive mining machines in POW mechanism, bundler mining has almost zero investment cost and is not subject to possible restrictions by laws. Compared with staking mining under the POS mechanism, Bundler has an extremely low threshold for participation. There is no need to pledge 32 Ethereums, only the gas that can be used to interact with the Entry Point contract is needed. The reason is that it is much more difficult for Bundler to do evil than for verification nodes and the income generated by doing evil is also much lower than that for verification nodes. Therefore, there is no need to pledge a large amount of Ethereum to ensure the balance of rewards and punishments in the overall operation of the ERC4377 protocol. Finally, compared to the staking income in liquidity pool, it has a shorter lock-up time, which makes the assets more flexible. When Ethereum faces selling pressure, users can withdraw their funds in time to reduce losses. In view of the above advantages, Bundler is likely to become a new investment method on Ethereum in the future, and even derive Bundler pools similar to Bitcoin mining pools and Ethereum pledge pools.
Intent centric's Appearance
Intent centric is centered on "intent", which means that users do not need to know the specific execution steps when performing operations, but the program automatically designs the modular operations that need to be performed at the bottom based on user needs. For new Web3 investors, the various signatures and gas settings in transactions are very unfriendly, so the one interested in crypto can only invest with the help of CEX without entering the real Web3 world. The essential reason for this phenomenon lies in the difference in operating intentions between DEX and CEX. For example, if someone wants to use DEX to exchange the USDT for ETH in the most profitable way, he must choose from many trading pools to select the best one, then sign to authorize the Dapp to have certain permissions. Next, sign to confirm that USDT will be pledged into the liquidity pool, and finally sign to confirm that the equivalent amount of ETH will be withdrawn from the liquidity pool. Each of the above operations is a behavior-based operation, and one operation corresponds to an underlying behavior. CEX's operations are intent-based which achieve the most profitable solution to replace the USDT held by the user with ETH only by a market price order, without the need to set a specific order price. Although it has been suggested that completing this series of processes yourself can provide a more transparent understanding of the transaction process and prevent problems that may be inherent in modular processes. But in general, there are still very few people with this ability. Most people just need a modular process that can achieve their intentions, without desire to understand the specific operations behind it. At the same time, manual processes also carry higher risks than modular processes that have 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, intent-centric applications that required modular processing of transactions according to user intentions have been developing slowly on Ethereum. In ERC4337, by introducing UserOperation and Bundler, every time a user signs a transaction, it will be put into the main memory pool after verification and wait to be uploaded to the chain. Instead, the transaction (UserOperation in ERC4337) is first sent to the backup memory pool and mixed with the UserOperation of its own or other users, waiting for Bundler to bundle these UserOperations and then 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 to participate in any specific process. In Dapp, we can design intent-centric logic. When users want to accomplish a certain goal, they only need to sign their intentions, instead of choosing their own transaction behavior and signing one by one. It can be expected that with the full promotion of ERC4337, intent-centric Dapps will become popular on Ethereum, thus greatly reducing the entry barrier for Web3.
ERC4337 and Defi
DeFi was closely integrated with EOA accounts in the last bull market, which greatly improved the diversity of interactive functions on the crypto investor chain and provided a variety of financial methods such as pledges, market makers, and loans, which ultimately led to a round of DeFi Summer. However, DeFi’s complex transaction process and on-chain losses have set a huge threshold for ordinary users to participate, and have also hindered the further promotion of DeFi. However, the ERC4337 wallet combined with DeFi can provide an intent-centric interaction method, allowing users to obtain an experience close to CEX. At the same time, gas-free transactions can also be achieved through Paymaster in ERC4337. Some operators can also attract more people to participate in DeFi through this method. However, unlike verticals such as SocialFi and GameFi, DeFi involves the transfer and pledge of a large number of tokens and has extremely high requirements for security. The contract layer of account abstraction involves relatively high complexity and is prone to security vulnerabilities causing losses to users' encrypted assets. At the same time, since the US government issued a ban on many coin laundering contracts such as tornado, many DeFi contracts will strictly review or even suspend interaction with smart contract addresses. Therefore, there are a lot of incompatibilities between smart contract wallets and the current DeFi system. This will also bring obstacles to the promotion of ERC4337 wallets in DeFi.
ERC4337 and Multi-Chain Game
Different from the "half-chain" games in early GameFi, only game assets and props are uploaded to the chain to ensure the security of their assets in a decentralized manner. Multi-chain games write the core logic and economic model of the game into smart contracts on the chain, and interact with the game on the chain, achieving decentralization and high security in the entire process. However, Web3 games at this stage also pay a huge price to achieve multi-chain. The first is the surge in gas fees. Every step of the interaction between on-chain games, props, and scenes needs to be recorded on the chain, which has caused a surge in game costs. In order to solve this problem, the interaction logic of multi-chain games at this stage is often extremely simple, but this also limits the user's transaction experience. At the same time, if you use a traditional EOA account, you must endure an extremely cumbersome verification process to confirm each interaction during the entire game interaction process. This process greatly reduces the game experience. The introduction of account abstraction first greatly reduces transaction costs. The transaction confirmation process only requires BLS aggregate signature and one-time signature verification, which greatly saves gas consumption in the cryptographic verification process. In addition, by packaging transactions in batches, the original process of confirmation again and again can be eliminated. At the same time, the introduction of personalized smart contract accounts can facilitate the modular construction of multi-chain games, thereby improving development efficiency. At present, on the Starknet network with native account abstraction, we have seen many successful cases of combining multi-chain games with account abstraction, such as Loot Realms, Cartridges, etc.
ERC4337 and SocialFi
Trapped in the bundling mechanism of private key accounts and the limited interactive functions of EOA accounts themselves, SocialFi has long faced the problem of high participation thresholds and difficult account management. Poor user experience has greatly limited the development limit of the SocialFi project. The introduction of account abstraction will completely change this situation. However, the choice between convenience, recoverability and security depends on the importance of the specific Web3 account of SocialFi. sex trade-off. 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 enables the creation of Web3 accounts and private key recovery through 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 QQ, where users can choose whether to open channel functions or not.
The Future Prospects
As of press time, the number of Web3 users is about 300 million, accounting for only about 4% of the global population. Compared with the 6 billion Internet users in the world, there is still a big room for development. To catch up with the size of Web2 and cross the 1 billion user mark, lower participation thresholds and more account customization functions are prerequisites for Web3. Of all the current options to achieve this goal, ERC4337 is relatively risk-reduced, has a relatively mature framework, and is recognized by the Ethereum Foundation and major developers. Therefore, since the Entry Point entry contract was deployed on Ethereum, the number of account abstract users has also experienced explosive growth.
Although ERC4337 has been widely recognized and promoted by Ethereum community, it still faces many problems during its actual implementation. The first is its own pending standards. Since many supplementary proposals for ERC4377 are still under review, the final form can not be determined yet, which has brought great obstacles to the development of ERC4377 ecological projects. The second is the update cost of ERC4377. Once the entry point contract is deployed, most wallets in the entire network need to cover the original address to complete the update, which is extremely diffficult. Finally, there is the issue of incompatibility with existing Dapps and cross-chain bridges. If ERC4337 is to be fully implemented, Ethereum’s existing Dapps will need to be extensively upgraded, facing security risks and costs.
However, ERC4377 has also made positive responses to the above problems, such as improving Bundler's packaging efficiency by adding external smart contracts, adding opcodes to improve smart contract account permissions, and supplementing EIP proposals to solve the problem of difficulty in upgrading Entry Point. At the same time, faced with the incompatibility issues of traditional Dapps, ERC4337 actively builds its own ecosystem to promote the application of account abstract wallets on Ethereum. The full implementation of the ERC4337 wallet can realize EVM intent-centric at the Ethereum Virtual Machine level, and further abstraction of EVM intent-centric in Dapp can make operations in Web3 reach the level of user-intent-centric simplicity in Web2. If intent centric can be fully realized in Ethereum Dapp, DeFi, GameFi and almost all verticals that require ease of operation and automation will greatly optimize the user experience, thereby attracting more outsiders to participate. However, DeFi, a trace that directly involves token transfer, will be relatively conservative because its stringent requirements for security. Vertical such as SocialFi and GameFi which pay more attention to user experience and relatively weaken security,unabling to carry out complex interaction design due to the limitations of the EOA account. Through ERC4337, these verticals can solve the original two major problems of high user threshold and poor user experience, thereby ushering in a large-scale growth in user volume, and may even serve as a major flash point in the next round of bull market.
References
- ERC4337 官方说明文档: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
Ethereum
DeFi