Account Abstraction 2023 Recap (2)

1. ERC-4337 is Not the End Solution

1.1. Current Issues with ERC-4337

ERC-4337 has successfully met its initial goal of implementing account abstraction without necessitating changes to the protocol. However, as highlighted in the first part of our 2023 account abstraction series, the deployment and integration of account abstraction and ERC-4337 remain inadequate. One of the reasons is that ERC-4337 has not yet emerged as a complete solution. Currently, ERC-4337 faces the following three significant challenges

1.1.1. High Cost of User Operations

The cost associated with User Operations (UserOp), which are used instead of transactions in ERC-4337, is significantly higher—approximately 2 to 3 times more than regular transactions. This increased cost is attributed to the need for performing actions such as signature and nonce verification in a separate mempool, which were traditionally handled at the protocol level. The process of handling User Operations demands a complex verification procedure, as you can see in the following flowchart.

Thus, within the Ethereum ecosystem, the utilization of ERC-4337 has been minimal due to the aforementioned cost issue, with the total number of UserOps occurring within the Ethereum network since the introduction of ERC-4337 hovering around 20,000.

Furthermore, the issue of transaction cost structures has become prominent among optimistic rollups that have set up Ethereum as Layer 1. Typically, the transaction costs for optimistic rollups are divided into two parts

• L2 Execution Costs: The charges for executing a transaction on L2, recording state changes, and, in the case of ZK rollups, generating ZK proofs.
• L1 Security Costs: The costs associated with submitting the transaction to L1 (Ethereum) in the form of calldata. These costs are proportional to the length of the calldata.

The UserOps of ERC-4337 incur significant expenses in the latter category of costs. The calldata for UserOps is notably longer compared to regular transactions, which explains the higher associated costs.

If traditional transactions followed a direct path from [User → Contract A], in the case of ERC-4337, the transaction flow becomes significantly more complex, resembling [Bundler → EntryPoint Contract → User's Contract Account → Contract A]. Moreover, if there's a desire to use a Paymaster, information regarding this must also be included within the transaction. Consequently, these additional layers of information necessitate an increase in the length of the transaction. Observing the average gas fees for User Operations on Arbitrum illustrates that the costs incurred due to this complexity are higher than one might expect.

Even for the contract accounts deployed by Biconomy, which perform the simple action of transferring ETH, there have been instances on Arbitrum where the cost for a User Operation exceeded 1 dollar. Moreover, when User Operations involve interactions with external contracts, such as ERC20 tokens, the costs become even higher.

Regarding the transfer of ERC20 tokens, as of December last year, the accounts of both Biconomy and ZeroDev required an average cost of over 1 dollar per User Operation. While the Dencun update and the implementation of EIP-4844 might reduce the absolute gas fees, User Operations would still consume a cost equivalent to 2 to 3 times the average gas fee of a regular transaction.

If the cost of User Operations is high, it not only becomes a burden for the users of contract accounts but also for applications that offer to subsidize gas fees through paymasters. Therefore, regardless of whether it's on Layer 1 (L1) or Layer 2 (L2), there's a clear need for alternatives that can reduce the cost of User Operations.

1.1.2. MEV Centralization and Censorship

Ethereum validators have the authority to arrange the order of transactions within a block, enabling them to profit from arbitrage, front-running, and sandwich attacks through what is known as MEV(Maximal Extractable Value). If the power to adjust transaction order is concentrated among certain validators, it could lead to monopolization of the MEV market by these validators, as well as issues like transaction censorship.

To combat this, Ethereum is attempting to ensure decentralization within the MEV market and resistance to censorship through solutions such as PBS(Proposer-Builder Separation) and crList(censorship resistance lists). However, since the mempool used in ERC-4337 exists off-chain and undergoes separate verification, the effectiveness of PBS and crList implemented within the protocol is nullified. Consequently, there's a risk that Bundlers could monopolize MEV profits or that a user's User Operations could be censored. Although it's theoretically possible to implement a separate PBS and crList specifically for ERC-4337 within this mempool, this would introduce additional complexity and is therefore not ideal.

Furthermore, the current structure of Bundlers is not permissionless, exacerbating this issue. To date, none of the Bundler providers have implemented a public mempool that allows anyone to participate in the bundling process. Thus, the ERC-4337 ecosystem currently relies on centralized Bundlers, with the submission of User Operations predicated on the trust that a single Bundler will not maliciously extract MEV or engage in censorship.

1.1.3. Low Migration Rate to Contract Accounts

Although an increasing number of wallets compatible with ERC-4337 are being released, and various experiments are being conducted within the dApp ecosystem through ERC-4337, user retention for those utilizing it remains unsatisfactory.

From the data, it's observed that after a month (4 weeks) of creating a wallet, the rate at which these wallets are reused does not surpass 1%.

This issue can be attributed to two main factors.

1) Absence of a Killer App If we seek the root cause of the above results within applications, possible reasons include

• Apps utilizing account abstraction have failed to significantly attract users.
• Applications have employed account abstraction only for short-term events.

For instance, apps like ZTX have used ERC-4337 wallets exclusively for events, resulting in an average number of User Operations per wallet being close to 1.

2) Contract Accounts Trapped within Apps A commonality among apps that utilize account abstraction is their support for only a single wallet provider. This leads users to create different contract wallets for different apps instead of using a single contract wallet across multiple applications. Consequently, users find it challenging to continuously use a wallet created in one app in another context.

The lack of a contract wallet standard can be identified as a cause of these issues. If the accounts from Biconomy and ZeroDev were compatible with each other, it would be much easier for applications to integrate both wallet SDKs. Unfortunately, the current wallet providers are not interoperable. This underscores the need for a standardization of contract wallets.

2. Improvements Within ERC-4337

Efforts to address these issues within ERC-4337 are ongoing, and they can be broadly divided into three categories.

2.1. Bundler Standard and Public Mempool

Currently, production-level Bundlers such as Pimlico, Biconomy, and Alchemy each utilize their own UserOp mempools. This means that all UserOps are processed by a centralized single Bundler, and every user with a contract account must trust that the Bundler will not act maliciously when sending transaction requests.

To mitigate this problem, the eth-infinitism team, composed of the authors of ERC-4337, has proposed a Bundler standard and is encouraging the formation of a public mempool. A Bundler standard is necessary because if Bundlers have differing specifications, they cannot share the same mempool. This standard can be found on the GitHub of eth-infinitism, which is composed of the authors of ERC-4337.

Several Bundler providers are also collaborating for a public UserOp mempool. Currently, three types of Bundlers—Voltaire created by Candide, Skandha by Etherspot, and Silius by Vid Kersid—are forming a public mempool on the Sepolia testnet to test the public mempool.

In addition to these developments, Alchemy and Stackup, which currently operate Bundlers on the mainnet, are planning to implement a Peer-to-Peer (P2P) interface. Once the P2P interface is implemented, communication between Bundlers will be possible, allowing them to share the same public mempool and perform UserOp Bundling in a decentralized manner. After experiments on the testnet confirm stability and efficiency, public mempools for Bundlers are expected to be created not only on Ethereum but also on other mainnets such as Polygon and Arbitrum. This will help prevent the centralization of Bundlers and enhance resistance to censorship within the ERC-4337 architecture.

2.2. Cost Reduction through BLS Wallets

Using BLS wallets, which can aggregate signatures from different entities into a single signature, could significantly reduce the cost of UserOps. However, none of the wallets currently at the production level utilize the BLS signature mechanism. The only experiment in this direction has been a BLS wallet demo created by WAX, a team from the Ethereum Foundation's PSE(Privacy & Scaling Explorations).

The use of BLS signature aggregation represents a significantly meaningful solution in reducing the gas fees paid by users. However, the adoption of this technology is not straightforward due to the inherent characteristics of BLS signatures. Compared to traditional ECDSA signatures, BLS requires somewhat more resources for verification. Nonetheless, BLS can be efficient because it allows for the verification of multiple signatures simultaneously. This means that without several signatures, BLS could demand higher costs than the existing signature systems.

For BLS to achieve efficiency within ERC-4337, a bundle must contain about 10 or more UserOps. Given the nascent stage of account abstraction adoption, it is challenging for Bundlers to gather more than 10 UserOps in a single bundle, making the adoption of BLS difficult. However, as the number of UserOps increases in the future, the prospects for the commercialization of BLS wallets may rise.

2.3. Cost Reduction in Rollups: Calldata Compression

As mentioned in issue 1, one of the problems in optimistic rollups is the substantial gas fees incurred from uploading the transaction's calldata to L1. One of the solutions being explored to address this issue involves compressing the calldata of UserOps. Recently, Pimlico and Daimo have collaborated to release a solution for this.

If a Bundler receives a user's User Operation (UserOp) and creates a transaction through an EntryPoint contract, the necessity for substantial data in this call results in lengthy calldata for the UserOp transaction, thereby incurring higher costs. However, what if there were a kind of Inflator contract that receives compressed calldata at the front end of the call to the EntryPoint, decompresses it into the correct calldata format, and then sends the call to the EntryPoint?

Sending UserOp in the structure mentioned above allows for significantly cheaper gas fees through compressed calldata. Although decompressing it incurs a slight increase in gas fees, the reduction in gas fees due to calldata compression far outweighs this, resulting in a substantial decrease in overall gas fees.

This data is part of the research results conducted by the PSE team, illustrating how much gas fees can be saved through BLS signature aggregation and calldata compression. According to the research, gas fees for UserOp can decrease by about 82% to a maximum of 90%, which is approximately more than twice smaller than the gas fees originating from EOAs.

If wallet providers support such calldata compression and BLS signature aggregation, it would enable the very affordable use of ERC-4337 in optimistic rollups like Arbitrum or Optimism.

However, as shown in the image above, calldata compression for UserOp actually results in increased costs in Layer 1. To reduce costs in Layer 1, solutions like the Native Account Abstraction introduced below must be implemented.

3. Implementing Native Account Abstraction in Rollups: RIP-7560

3.1. Why Native Account Abstraction?

One way to solve the cost, complexity, and account retention issues of ERC-4337 is to introduce "Native account abstraction." This means supporting account abstraction within the protocol, similar to EIP-2938 and EIP-3074. Bringing account abstraction into the protocol can provide the following benefits.

• Gas Savings
  • Users send UserOps instead of transactions, which are verified and forwarded by Bundlers
  • In return, Bundlers receive fees from users. Each process of sending fees to Bundlers or modifying nonces consumes a significant amount of gas
  • The current process of sending UserOps, as illustrated and described above, is complex. Embedding it into the protocol could enable gas savings generated by sending UserOps
• Development Resource Savings and Protocol Stability Improvement
  • Solutions such as PBS and crList, newly applied to the protocol, can be implemented in UserOps
  • This reduces the research and development resources required for solutions to be applied to ERC-4337 and contributes to improving protocol stability

Previously, proposals like EIP-3074 were rejected due to the complex protocol changes they required. However, such discussions are now becoming more tangible. Then, why did we not initially implement account abstraction within the protocol and instead use off-chain mechanisms like ERC-4337?

Since 2022, Ethereum's roadmap has included the ‘Implementation of Native Account Abstraction' However, this process is highly complex and requires substantial engineering resources. At the time, Ethereum needed to implement relatively more critical features first, such as proto-danksharding, PBS, and Verkle trie, so Native Account Abstraction was a lower priority, which remains the case.

ERC-4337 emerged as an interim solution. About a year after the release of ERC-4337, with the system's stability somewhat verified, discussions on native account abstraction within the protocol have begun. Among the most prominent movements in this regard is "RIP-7560".

3.2. What is RIP?

Before diving into RIP-7560, let's understand what RIP is. RIP stands for Rollup Improvement Proposal, signifying proposals for discussing compatibility or cooperation among rollups with Ethereum as L1. The Ethereum Foundation started discussing this in RollCall since last October.

Rollups strive to bring Ethereum's security in their own ways, offering different tools and features. Starknet and zkSync support native account abstraction, unlike other rollups.

This leads to the issue of dApp developers having to implement different codes for each chain. For instance, a dApp wanting to integrate L1-L2 bridges must base its code on different codes for each rollup, as each rollup has different bridge interfaces.

Collaboration among rollups is necessary to solve this. RIP aims to provide a neutral forum for this discussion. Although differences among rollups are inevitable, the goal is to minimize incompatible aspects. Moreover, participation in RIP is not mandatory, meaning not every topic in RIP necessarily requires implementation by each rollup.

3.3. RIP-7560: Native Account Abstraction for L2s

RIP-7560 proposes a new transaction type for implementing Native Account Abstraction in rollups. While zkSync and Starknet have implemented native account abstraction, they are not compatible with ERC-4337. RIP-7560 aims to implement Account Abstraction within the protocol while maintaining compatibility with ERC-4337, facilitating smooth integration for wallet providers based on ERC-4337.

RIP-7560 introduces a new transaction type, "AA_TX_TYPE," which leads to the following changes.

1) Separate nonce management Traditionally, nonces in contracts only increase when the CREATE opcode is used, i.e., when deploying other contracts from a contract. If RIP-7560 is applied, allowing contract accounts to send AA_TX_TYPE transactions, the nonce must increase with each transaction to prevent signature replay attacks and potential fund theft.

One method to maintain non-overlapping nonces for contract accounts is to use the nonce mechanism of EOAs. Since every EOA has a nonce that increases by one with each transaction, applying the same to contract accounts allows distinguishing signatures for each transaction and checking for signature reuse, thereby preventing vulnerabilities like signature replay attacks.

However, there are various edge cases. If an account is operated by multiple users, overlapping nonces could lead to confusion. RIP-7560 introduces a NonceManager contract to handle separate nonces for transactions coming from contract accounts, meaning the sequence of nonces for EOAs and contract accounts will not align.

2) New fee structure Traditional transactions are set to consume 21,000 gas. However, the introduction of AA_TX_TYPE allows for the design of verification mechanisms as desired by applications, considering interactions with paymasters. RIP-7560 introduces new fees (e.g., paymasterGasLimit), with transaction fees calculated based on a specific logic.

Additionally, RPC methods like eth_sendTransaction will be modified to accept AA_TX_TYPE transactions.

3) Separate Mempool AA_TX_TYPE transactions, due to their distinct validation and execution logic from traditional transactions, are processed in a separate mempool. However, the protocol-level block builder aggregates these for inclusion in blocks alongside regular transactions.

4) Separation of Validation and Execution In the context of ERC-4337, the role previously played by Bundlers is now assumed by block builders. Block builders divide the validation and execution of AA_TX_TYPE transaction batches within a single transaction for inclusion in a block. This approach is similar to how multiple UserOperations were included within a single transaction in the original ERC-4337 implementation.

5) Builder Fees In this process, block builders expend more computing resources than they would for handling traditional transactions. What if block builders refuse to process AA_TX_TYPE transactions due to this increased resource demand?

To prevent such scenarios, senders of AA_TX_TYPE transactions can attach a builder fee to their transaction. This compensates for the additional resources required and can prioritize their transaction for inclusion in a block, akin to the priorityFee concept in EIP-1559.

RIP-7560 is still in the feedback stage before becoming an official RIP. Additionally, there needs to be further RIPs discussing how AA_TX_TYPE transactions will be validated in the mempool and how signature aggregation supported by ERC-4337 will be implemented.

While discussions on Native Account Abstraction in rollups are still in the early stages, the potential value it could offer users has garnered significant interest. Notably, Coinbase's development of the Base chain includes support for contract wallets in its 2024 roadmap.

3.4. ERC-4337 Is Not the Only Solution: EIP-3074

As the shortcomings of ERC-4337 become apparent and discussions about bringing account abstraction into the protocol itself become more concrete, previously proposed methods of protocol-level account abstraction are being revisited. In particular, there is ongoing discussion about incorporating EIP-3074 into various chains.

EIP-3074 proposes allowing EOAs, like those used with MetaMask, to 'delegate' some of their account permissions to contracts. To facilitate this, EIP-3074 suggests the introduction of two new opcodes: AUTH and AUTHCALL. When applied, the user's call flow would proceed as follows.

Initially, a user signs a message with their private key that includes the contract they wish to delegate their wallet to and sends this to a relayer. The relayer forwards this signature to a contract referred to as an Invoker, which verifies the signature using the AUTH opcode. Once verified, the Invoker contract gains the authority to send transactions on behalf of the user's wallet. When sending transactions, the Invoker contract uses the AUTHCALL opcode, setting the transaction's sender to the delegating user's wallet address.

One of the most significant benefits of EIP-3074 is that it eliminates the need for users to pay gas fees for transactions that include AUTHCALL, as these fees are covered by the relayer. This setup is akin to the default paymaster configuration in ERC-4337, ensuring that the gas costs for executing transactions via AUTHCALL are supported externally.

EIP-3074 can encompass most functionalities that ERC-4337 supports, depending on the design of the Invoker contract. This flexibility allows for a range of features to be implemented, including transaction batching, session keys, and social recovery. Additionally, EIP-3074 offers the advantage of allowing existing users to access the various functionalities that contract accounts provide without needing to migrate from EOAs, often at a lower gas cost due to its simpler architecture.

However, EIP-3074 does have its set of drawbacks. It requires protocol changes, including the addition of new opcodes, which means that adoption across multiple chains is necessary for multi-chain support. Moreover, since it relies on EOAs, users must meticulously manage their private keys, and it is limited to ECDSA signatures. Although EIP-5003 has been proposed to facilitate the migration of EIP-3074 enabled wallets to contract accounts, further discussions are needed to address security concerns during the migration process.

Despite these challenges, EIP-3074 provides a powerful feature set that enables EOAs to function like contract wallets. This capability has prompted significant discussions alongside proposals like RIP-7560 to bring account abstraction into the protocol. More detailed information on these discussions will be provided later.

4. Account Abstraction: ERC-6900 & ERC-7579

To solve the problem of low retention rates for contract accounts, discussions about standardizing contract accounts themselves have been gaining traction. Standardizing accounts would allow users to continuously use the same wallet across various applications. Toward this goal, two ERC proposals are currently on the table.

4.1. ERC-6900: Modular Smart Contract Account and Plugins

ERC-6900, proposed by Alchemy, is a standard for contract accounts that allows for the flexible installation and removal of apps on an account, much like one would with a smartphone. In this standard, the apps installed on an account are referred to as Plugins.

A representative example of a Plugin is a session key function needed by a contract account used in a game, where certain permissions of the account need to be temporarily delegated. Unlike traditional contract accounts that include such functionalities from deployment, ERC-6900 allows for the creation of a Plugin that performs the session key function and can be installed onto the account as needed.

By enabling users to freely add and remove functionalities from their accounts, ERC-6900 enhances account reusability and simplifies the integration of contract accounts into apps.

For instance, consider an on-chain game that requires session keys. In the current landscape, integrating a contract wallet into the game means choosing a single wallet provider due to varying implementations of session keys across wallets, resulting in inconsistencies in transaction handling. Developing logic to interact with each session key variant could increase app complexity, which is not ideal.

The standardization of contract wallets and modules (plugins), as proposed by ERC-6900, offers a solution to this problem. Applications could develop their preferred session key plugin and allow users to install it into their wallets, streamlining the process.

A significant advantage of ERC-6900, which also doubles as a potential downside, is its emphasis on security. A look at ERC-6900’s reference implementation reveals measures put in place to mitigate risks associated with malicious plugins, indicating a design that can somewhat handle security threats. However, the rigorous security checks within the contract lead to higher gas costs for users compared to traditional wallets and a complexity in structure that increases development difficulty.

4.2. ERC-7579: Minimal Modular Smart Accounts

ERC-7579 is a proposed ERC, developed through collaboration between Rhinestone, ZeroDev, Biconomy, and OKX, aimed at standardizing contract wallets. It employs a mechanism that allows users to install and remove modules in their wallets as desired. In this respect, it shares similarities with ERC-6900, but the most significant differences lie in security and cost.

As its name suggests, ERC-7579 proposes a minimal standard for contract accounts. It focuses on compatibility and interoperability, offering specifications that do not compromise the autonomy of each wallet. Consequently, ERC-7579 presents the advantage of allowing for easy development while adhering to minimal restrictions. This leads to the potential for a wide range of implementations. Despite being in the demo phase, ERC-7579 implementations have already demonstrated their efficiency, particularly in 'Native transfer' and 'ERC20 transfer', showing only a marginal difference in gas fees compared to production-level wallets optimized for these functions.

However, compared to ERC-6900, ERC-7579 allows for elements that could be considered risky in terms of security. The most significant risk in a modular architecture is the installation of malicious modules in an account. Accordingly, ERC-6900 implements various methods to ensure account security, including the ability to restrict the external contracts that installed plugins (modules) can access. On the other hand, ERC-7579 does not check for such issues. Although the reference implementation of ERC-7579 suggests the introduction of ERC-7484, which involves setting up a module registry where predefined developers and auditors can check whether a module is malicious or has security flaws, this solution ultimately depends on a pre-established committee, which is not a definitive resolution.

In conclusion, both ERC-6900 and ERC-7579 propose standards for modular contract accounts. Personally, I believe these two standards will coexist. Wallets adhering to the ERC-6900 standard may be more suitable for areas where security, such as DeFi or payments, is paramount, while the ERC-7579 standard may be more appropriate for sectors requiring high levels of interaction, like gaming or social media.

These standards have undergone extensive development and feedback, with contract accounts utilizing them either gearing up for launch or already available in the market. Recently, ZeroDev released a wallet SDK compatible with ERC-7579, allowing users and application developers to develop modules compliant with the ERC-7579 standard or to test these wallets on the mainnet. Moreover, ERC-6900 is currently undergoing community feedback and is expected to be released for production-level use after auditing. As these standards become increasingly commercialized, it is anticipated that instead of using different wallets for different applications, a single contract account could be utilized across multiple apps.

5. Account Abstraction + Intent: ERC-7521

5.1. Definition of Intent and Issues

To send a transaction on Ethereum, it's necessary to specify various details, such as the recipient, the amount of ETH to be sent, and the gas limit. This process can be quite complex, particularly for transactions involving token swaps on Decentralized Exchanges (DEXs), where considerations like Miner Extractable Value (MEV) must be factored into the gas and swap amounts.

The concept of "Intent" has emerged to mitigate this complexity and enhance the user experience (UX) in Web3 applications. Apps implementing Intent allow users to initiate transactions without specifying the exact details, such as the recipient or the amount of tokens to be sent. Instead, users express their 'intentions', and the application configures the transaction on their behalf. For example, in the context of a token swap, Intent would define the minimum amount of tokens the user expects to receive as a result of the swap. The entity responsible for assembling transactions based on these Intents is referred to as a Solver.

Intent has been gaining attention within the blockchain ecosystem over the past year, enabling a range of use cases, such as placing limit orders. For instance, a user might say, "Convert 1 ETH to USDC by tomorrow, ensuring I receive at least 2000 USDC." Protocols like CoWSwap, UniswapX, Flashbot, and Anoma are developing features that utilize Intent.

However, the development of proprietary Intent standards by various protocols can lead to interoperability issues and fragmentation among users of different Intent services. A key concern in the mechanism of using Intent is the decentralization of Solvers, as centralization can significantly impact users.

Consider a scenario where a DEX implements an Intent mechanism, but there's only one Solver. Even if the current price of ETH is 2400 USDC, the Solver could fulfill the user's Intent of exchanging 1 ETH for at least 2300 USDC, pocketing a $100 difference.

To prevent such situations and ensure that Solvers act in the users' best interests, applications utilizing Intent typically adopt an auction structure among decentralized Solvers. This approach aims to prevent a monopoly on profits by centralized Solvers.

The challenge of compatibility between different protocols' Intent standards arises from each protocol operating its own separate Intent mempool. If Solvers across protocols worked from a unified mempool, it would reduce the risk of centralization. Thus, there's a pressing need for a standardized approach to Intent.

5.2. ERC-7521 & Essential

Founded in May 2023, Essential aims to provide infrastructure for Intent using ERC-4337 as a foundation for an Intent standard. While ERC-4337 and account abstraction are not mechanisms specifically for Intent, they create favorable conditions for its integration.

In the context of Intent, Solvers and ERC-4337 Bundlers perform very similar roles, as both transform data containing user signatures (Intent/UserOperation) off-chain into transaction formats. Leveraging the existing ERC-4337 infrastructure allows Solvers to apply the effects of Intent to contract accounts without significant changes, offering a clear advantage.

A crucial aspect of the Intent architecture is ensuring that the user's signature on the Intent is valid and that the conditions of the Intent are correctly verified and executed at the time of transaction execution. ERC-7521, inspired by the verification and execution processes of ERC-4337, suggests enabling the handling of Intent through an entry point contract.

When users send their Intent along with a signature to the UserIntent mempool, Solvers construct a Solution (transaction) based on this information.

Next, Solvers call the handleIntents function within the entry point contract. This function verifies the user's signature included in the Intent and checks if the Solution constructed by the Solver matches the conditions set forth by the user's Intent. If everything aligns, the Solution is executed, fulfilling the user's requested action.

A critical consideration here is the form that each Intent takes. Given that Intents can serve various purposes, imposing a fixed structure in the contract would significantly limit flexibility. ERC-7521 addresses this issue by allowing for the registration of Intent standards, thus accommodating different forms of Intents.

Through this approach, ERC-7521 facilitates the easy use of Intents in contract accounts and establishes a standard for processing Intents, preventing fragmentation within the Solver network.

However, several drawbacks exist with this method. Firstly, ERC-7521 requires modifications to the ERC-4337 specification. It necessitates the addition of functions for Intent verification, execution, and the registration of Intent standards to the entry point. This process requires agreement from the community and developers on these updates. Additionally, existing ERC-4337 compatible wallets must be upgraded to support these Intent standards. Implementing this standard will require discussions with various stakeholders and the community, which, given the nature of the Ethereum community, could be a lengthy process.

6. Conclusion and Outlook

Through the two parts on account abstraction we've examined, we've explored the development and future directions of the account abstraction ecosystem over the past year. Based on this, we've speculated on its potential evolution, including technical advancements and challenges.

6.1. Emergence of Killer Apps Utilizing Account Abstraction

The true potential of technologies like account abstraction or ERC-4337 hinges on their adoption by applications. So far, applications incorporating account abstraction have either lacked appeal or used it for simplistic, event-based purposes. However, with improvements such as calldata compression reducing costs, it's anticipated that ERC-4337's usability will significantly enhance, leading to a surge in applications adopting it.

The gaming sector, in particular, stands to benefit immensely from the application of ERC-4337. The interruption of gameplay for transaction signatures is a UX issue that can be addressed through features supported by ERC-4337, such as session keys. Yet, the Web3 gaming sector has seen few applications leveraging account abstraction to create UserOps extensively. Although the game appchain Xai on Arbitrum Orbit is generating buzz, its ability to sustain transaction volume and achieve success remains to be seen.

By 2024, it's hoped that a variety of apps, including games, will emerge, utilizing account abstraction to offer users an enhanced UX.

6.2. Reuse of Contract Accounts

If standardization of accounts, represented by ERC-6900 and ERC-7579, is achieved, it will create an environment where users can use multiple apps with a single contract account, rather than using different contract accounts for each app.

Recently, ZeroDev announced a modular account architecture based on ERC-7579. Going forward, accounts are expected to be modular and interoperable, facilitating easy reuse. This will allow users to continue using a single contract account.

To accelerate this, an SDK that easily integrates various contract accounts into apps is needed. For existing EOA wallets, tools like RainbowKit exist, enabling dApp developers to easily integrate various wallets, such as MetaMask and Coinbase Wallet, into their apps.

However, such SDKs are virtually nonexistent for contract accounts. Currently, permissionless.js by Pimlico is one of the few, aiming to offer functionality similar to RainbowKit for contract accounts.

Permissionless.js currently supports ZeroDev, Safe, and the SimpleAccount from the ERC-4337 reference implementation, making it easier for applications to integrate these wallets. If this SDK supports more wallets, it will likely make it easier for applications to adopt contract accounts.

6.3. Native Account Abstraction within the Protocol

Ethereum's roadmap released earlier this year by Vitalik Buterin provides insight into the Ethereum Foundation's perspective on account abstraction, prominently featured in the roadmap section titled "The Splurge.”

Currently, following the rollout of ERC-4337, the next steps involve the voluntary conversion of user accounts to contract accounts (Voluntary EOA conversion) and eventually, the implementation of Native Account Abstraction.

Considering this roadmap, the recent proposal of RIP-7560 can also be seen as intending to facilitate Voluntary EOA conversion. Unlike the typically lengthy process of Ethereum protocol updates, updates to rollups are often expedited by centralized foundations. This approach enables rollups with EVM compatibility to quickly provide native account abstraction, encouraging a swift migration of many users to contract accounts.

With RIP-7560, introducing account abstraction directly into rollups could lead to gas savings and, consequently, more affordable costs for various functionalities. In 2024, we expect an increase in rollups aiming to provide native account abstraction as proposed by RIP-7560.

6.4. The Advancement of EIP-3074

EIP-3074 is a powerful proposal that adds the functionalities of contract accounts to EOAs. Despite its downside of keeping users dependent on EOAs, discussions related to EIP-3074 have been growing in recent months, with a growing consensus towards its implementation. For instance, Polygon proposed bringing EIP-3074 into its protocol through PIP-22 last September, and extensive discussions about including EIP-3074 in Ethereum's upcoming Prague update occurred during the Ethereum Core Dev Meeting after Dencun.

Although no chains or service providers currently support EIP-3074, a new ecosystem based on it could emerge across Ethereum or EVM-compatible chains as support grows.

Furthermore, since EIP-3074 and ERC-4337 do not overlap in their approaches, solutions utilizing both are conceivable. A notable example is using EIP-3074's Invoker as an ERC-4337 account. By designing the Invoker contract like an ERC-4337 account and sending AUTH signatures to it, one can use ERC-4337 functionalities at a much lower cost.

By 2024, we hope to see multiple chains supporting EIP-3074 and the emergence of innovative use cases and applications leveraging it.

6.5. The Early Stages of Combining Account Abstraction and Intent

Both account abstraction and Intent are technologies proposed to improve the inconvenient UX of blockchain, and the recent proposal of ERC-7521 introduces a standard for easily supporting Intent within ERC-4337. This combination could lead to applications offering exceptionally high levels of UX.

However, discussions on this topic remain in the early stages. Currently, Intent is only applied in specific use cases, such as swaps, with platforms like CowSwap and UniswapX. The environment for more general applications of Intent, through projects like Anoma and SUAVE, needs to be established. Additionally, further discussions on how to incorporate ERC-7521 into the current ERC-4337 architecture are necessary.