Why is it said that full-chain account abstraction is the final piece of the puzzle for EIP-4337?

TL;DR

Since 2022, account abstraction has been widely discussed in the field, and the framework centered around EIP-4337 seems to have become a general consensus in the industry. The popularity of the abstraction concept has prompted people to pay more attention to such low-threshold user interaction components.

However, EIP-4337 still faces pain points such as Smart Account fragmentation and highly fragmented user experiences across chains. This article takes projects like Biconomy, Safe Core, and Particle Network as examples to explore how to further promote the development of the account abstraction field within the EIP-4337 framework.

From the perspective of transaction process abstraction, understanding the concept of “account abstraction”

Regarding account abstraction, Vitalik has repeatedly pointed out that it is a necessary condition to reduce the user threshold for Ethereum and achieve mass adoption. Its core vision is to allow users to customize signature verification methods + enjoy gas payment, and initiate transactions on-chain without any assets (commonly known as gas-free transactions). Only by achieving these prerequisites can the conversion rate of new users to Web3 applications be improved.

Previous non-account abstraction proposals or smart contract wallets, although they can achieve similar experiences, are still not flexible and efficient enough. For example, Gnosis Safe still requires an EOA address to trigger transactions, and the gas cost is extremely high.

Account abstraction intends to optimize from the underlying structure of smart contract accounts, paving the way for the next generation of intelligent account systems.

However, if we look at the actual account abstraction proposals, we will find that their focus is not on the account model itself. For example, account abstraction-related proposals such as EIP-86, EIP-4337, and EIP-6900 focus on abstracting/modularizing the entire processing flow of a transaction from initiation to being received by nodes, signature verification, gas payment, etc., rather than truly focusing on abstracting the account structure. Therefore, it seems more appropriate to refer to these various proposals as “transaction abstraction”.

If we understand the well-known account abstraction proposals from the perspective of “abstraction of transaction processing flow”, we can more easily understand their key points: this kind of transaction abstraction actually aims to bring the experience of Web2-level users entering and using products into the Ethereum system, such as blacklists/whitelists, transactions initiated within a period without identity verification, gas-free transactions, fiat currency payment of fees, etc.

Some may question: Couldn’t these functionalities be achieved in the past with existing smart contract wallets? What is the value of account abstraction schemes like EIP-4337?

The Essence of EIP-4337: Account Abstraction as a Local Optimal Solution in the Ethereum Ecosystem

As the question suggests, while past smart wallets could indeed achieve the mentioned functionalities, their implementation methods were often crude and frequently relied on highly centralized third-party facilities. For instance, previous gas payment schemes required the introduction of third-party Relayer nodes (EIP-2771). Furthermore, the lack of unified standards among different smart wallet implementations hindered the development and deployment of complementary components.

The core objective of various EIPs related to account abstraction is to address these shortcomings present in different wallet projects by introducing a standardized framework specifically designed for smart contract wallets. This framework aims to transition the account structure within the Ethereum ecosystem from a basic functional structure to a more sophisticated intelligent structure, thus enhancing the efficiency and scalability of the overall ecosystem.

This is analogous to the situation before ERC-20 or ERC-721 emerged, where the implementation methods, functionalities, and provided functions/interfaces of many tokens were inconsistent. Such inconsistency was not conducive to the development of complementary third-party facilities and code auditing (it’s hard to imagine the extent to which DeFi applications could have flourished without the ERC-20 protocol).

Standardized protocols/functional implementation standards are prerequisites for modular narratives, and modular development approaches are almost prerequisites for vibrant development in any field (division of labor being the first principle of efficiency improvement).

In the end, EIP-4337 emerged.

EIP-4337 is a local optimal solution, but there are multiple angles within its framework that urgently need optimization.

EIP-4337 defines a complete set of interface standards, clarifying which modules a smart wallet following the 4337 protocol should have, and which functions/interfaces each module should implement, such as Bundler, EntryPoint, and Paymaster, and what callable functions these components should provide.

Once these specifications are clearly defined, the interaction between different components becomes clearer, making it easier to introduce modular design thinking into the design of account abstraction and smart wallets, greatly benefiting wallet module developers.

Of course, purely from the user’s perspective, the value brought by the modular smart wallet development paradigm is not yet clear because users may not feel much change in the account abstraction wallet itself in the short term. However, in the medium to long term, the value of protocols like EIP-4337 is similar to ERC-20 and ERC-721. It lays the foundation for the long-term development of account abstraction wallets and is a milestone of epoch-making significance.

However, EIP-4337 still has many unresolved issues, such as:

1. The functionality of account abstraction is not sufficiently plug-and-play, making it easy for different developers to reinvent the wheel.

2. Poor compatibility of account modules leads to a fragmented ecosystem of account systems.

3. The highly fragmented account abstraction ecosystem between different chains makes it difficult to provide end-users and developers with a unified and high-quality experience to achieve better UX.

In the following sections, we will discuss solutions to these problems.

Optimization Direction One: Plug-and-play Functionality Modularization of Account Abstraction Will Become Basic Configuration

It can be said that one of the current core discussion points related to account abstraction is how to better achieve modularization of account abstraction wallets and make the division of each module more refined.

For example, Biconomy, based on EIP-4337 (and will introduce the finer-grained EIP-6900 in the future), proposes the narrative of plug-and-play functionality modularization of account abstraction to further promote the modular development of the account abstraction ecosystem.

The so-called plug-and-play functionality modularization of account abstraction is essentially achieved through a protocol that explicitly outlines the key modules involved in smart contract wallets, what interfaces/functions these modules should implement, and how these interfaces are named and called. Subsequently, third-party developers will develop components with varying details according to their own ideas, but these components will all comply with the requirements outlined in the protocol.

Biconomy’s V2 version, based on EIP-4337 as the protocol framework, has established more detailed standards and added a batch of interfaces not mentioned in 4337. While specifying the functionalities that Bundler, Smart Contract Wallet, Paymaster, and other modules should have, Biconomy allows third-party developers to implement modules with different code details but similar features and different versions, as long as they comply with the protocol rules predefined by Biconomy (compatible with EIP-4337).

Meanwhile, Biconomy has also introduced the slogan of the “Module Store.” While actively launching the account abstraction module SDK, Biconomy encourages developers to submit their own designed account abstraction modules and initiates “Module as a Service,” allowing all wallet projects that comply with the EIP-4337 protocol to directly adopt these third-party-written account abstraction modules. When users create smart accounts through the front-end interface, they will also have a more diverse selection of modules to choose from.

Modularization not only facilitates division of labor but also enables users to quickly switch, add, or remove specific features in smart wallets (in simpler terms, it breaks down granularity into finer components).

Biconomy points out that the higher the degree of modularization in smart contract wallets, the fewer changes are required when updating or upgrading (there is no need to update users’ existing Smart Contract Wallet contracts or use DelegateCall, only certain external modules need to be updated), making it easier for different users or developers to replace certain components.

In Biconomy’s future version of the new account abstraction solution, it will also reference EIP-6900, which is more conducive to modularization than EIP-4337.

Optimization Direction Two: Finer-grained Module Segmentation to Address Account Fragmentation Issues

Regarding the EIP-6900 proposal, Safe (formerly Gnosis Safe) actually released a Safe Core Protocol whitepaper related to it in August of this year, which draws heavily from EIP-6900.

EIP-6900 points out that a current issue with modularized account abstraction is the “fragmentation” or “island” problem of accounts. For example, while different account abstraction module providers or different DApp applications may be compatible with EIP-4337, the abstraction level of EIP-4337 for different modules is not high enough, and the granularity is relatively coarse. This leaves “excessive” freedom to Smart Account module developers (smart accounts store user information and record the core part of custom transaction verification and gas payment logic).

As a result, different wallet projects tend to design Smart Account modules with unique attributes. Over time, other account abstraction module providers must prioritize compatibility with whose Smart Account module is provided, leading to the emergence of a fixed upstream and downstream supply chain. This inevitably leads to fragmentation and disconnection in the account abstraction module ecosystem. (This is similar to in the early days of the computer industry when operating system developers had to consider compatibility with hardware devices from different computer hardware manufacturers.)

To address the issue of ecosystem fragmentation and improve compatibility between account abstraction modules developed by different providers, the best approach is to further abstract the smart contract wallet accounts and make the module segmentation granularity finer.

After drawing on the ideas of EIP-6900, the Safe Core Protocol whitepaper made more detailed optimizations to Smart Account (users’ smart contract wallet accounts). The Safe Core Protocol splits each callable module of a smart contract wallet account into various categories such as Plugins, Hooks, signature validators, and function processors.

Smart account modules are made as lightweight as possible, with the account contract storing only the most basic data and functions, while functions that can be moved outside are implemented by specialized modules such as “function processors” or “Plugins.” This adheres to the principle of Occam’s Razor: “Entities should not be multiplied unnecessarily.”

If the smart account itself is lightweight enough and does not involve too many intricate details, smart accounts developed by different manufacturers will be more similar in internal structure, and compatibility will also be higher.

The Safe Core protocol also introduces a registry, similar to the iPhone App Store, which contains all approved and available modules. Users can choose which modules to activate, and each time a new module is activated, it must be processed through the Manger contract.

In general, the UserOperation will first trigger a specific Plugin, and then the Manager contract will check if the Plugin’s status is normal (recorded in the registry). If it is normal, the Manager contract will allow the Plugin’s request to proceed. If necessary, the Plugin may call certain functionalities provided by some Hooks, or it may not. Afterwards, the state of the smart account involved in the UserOperation will be modified.

Through the above-mentioned fine-grained module segmentation and scheduling process, the Safe Core Protocol attempts to promote an open-source account abstraction module interoperability protocol. Its core idea is to lightweight Smart Accounts as much as possible, making them as simple as EOA accounts, in order to improve compatibility between Smart Account modules developed by different manufacturers.

Optimize Direction Three: Unified Account Abstraction across Chains, Achieving Consistent Accounts on Different Chains

However, even with the aforementioned solutions, there is still a major unresolved issue: different chains and different Layer 2 solutions are advancing various account abstraction implementation schemes with conflicting forms, many of which conflict with EIP-4337, such as zkSync Era, Starknet, Flow, etc. This fragmentation in wallet UX, for example, makes it impossible to unify a user’s smart wallet address on Starknet with that on Arbitrum.

Moreover, in a multi-chain environment, users have independently deployed Smart Accounts on different chains, and their corresponding user data is often stored in these contracts. If user data such as keys needs to be updated, transactions must be repeated across multiple chains, making it difficult to ensure the consistency of Smart Accounts.

Vitalik himself previously proposed a unified and easily manageable smart account solution across all chains. This solution uses Ethereum or a highly secure ZKRollup as the source chain, deploys a Keystore contract to store users’ global keys, and then all smart contract accounts on Layer 2 share the global keys stored in the Keystore contract。

However, this solution comes with extremely high costs. Whenever there is a change in the global keys recorded by the Keystore contract on the source chain, each account on the L2/target chain needs to synchronize the new keys through cross-chain interactions. However, the cost of cross-chain interactions between Ethereum and L2 is too high for users to afford. Additionally, it’s important to note that smart contract accounts are different from EOA accounts. While the latter, due to their unique address generation method, are naturally unified across multiple chains (within the EVM ecosystem), smart contract accounts are completely different, making it difficult for users to obtain smart contract accounts with the same address on different chains.

In response to this, Particle Network has proposed its own approach. Although the general idea aligns with Vitalik’s concept of separating the Storage and Code of smart accounts, Particle Network plans to use a separate chain—the Particle Network Chain—as the full-chain Storage database for smart accounts. Through third-party cross-chain messaging solutions (such as LayerZero, CCIP, Axelar, Connext, etc.), Particle Network intends to synchronize changes to an account’s Storage to other chains’ local Accounts.

(Particle Network’s Multi-Chain Account Abstraction Structure)

Specifically, Particle Network’s full-chain account abstraction system aims to provide users with a unified smart contract account address across different EVM chains. This requires deploying a set of Deployer Contracts on different chains. Users must trigger the generation of a new account on the Particle Network Chain, after which Particle Chain will trigger all Deployer Contracts on various chains to ensure that the smart contract account addresses generated for users on different chains are consistent. Alternatively, users can complete multi-chain interactions through contracts on the Particle chain without being aware of other chains, and they can use Unified Gas Token as a unified fee payment method.

Full-chain account abstraction also enables Cross-Chain User Operations, allowing users to trigger transactions on the target chain through User Operations and pay the corresponding gas on the source chain. For example, it allows the purchase of NFTs on Base using Polygon’s USDC.

However, Particle Network’s solution requires highly coordinated efforts between Deployer Contracts and cross-chain messaging components to synchronize multi-chain accounts and source chain Storage. This places high demands on the oracle or cross-chain messaging bridge used (a challenge that seems to exist in all solutions related to full-chain interoperability).

Nevertheless, users’ cross-chain account synchronization can be flexibly configured with different combinations of Message Bridges, rather than relying on a single Bridge. For example, it can be configured with a 2/3 policy, where changes to Storage on the target chain are confirmed only after any two of LayerZero, Axelar, or Connext confirm the change, which can mitigate the issue of single-point dependency.

Seamless interoperability across both EVM and non-EVM chains represents a further step in full-chain account abstraction within the Ethereum ecosystem. Despite advancements in key management and unified accounts across EVM chains, there is still room for optimization in full-chain account abstraction. Chains that are not EVM-compatible, such as Aptos, Solana, and Sui, cannot guarantee the consistency of smart contract account addresses generated by users with those on EVM chains. Additionally, non-EVM chains may struggle to adopt the concept of full-chain account abstraction proposed by Vitalik and Particle Network without implementing equivalent solutions to the EIP-4337 protocol.

Furthermore, there is room for improvement in wallet projects compatible with EIP-4337. Most smart wallets use Bundler nodes operated independently by the respective platforms, which are often not interconnected. This isolation poses risks such as censorship resistance and availability. Building a unified frontend interface across most chains would be extremely challenging. One approach to address this is to introduce intent-centric design, adding a layer on top of full-chain account abstraction, treating Ethereum’s EIP-4337 ecosystem or other chains’ native account abstraction facilities (such as zkSync) as specific instances under the Solver/Reactor category, with the selection of suitable Solvers being a higher-level task.

Taking Particle Network as an example, it proposes a concise abstraction of Intent-Centric implementation, where different account abstraction projects are simply instances included in the Solver category within the Intent scheme.

First, the user interface is responsible for translating natural language requests or any user interactions into specific programmatic descriptions, which include input constraints and output constraints (in other words, conditions for acceptable inputs and ranges for acceptable output results). Subsequently, one or more Solvers in the Solver network will forward the Transaction containing specific input-output constraints to the Solver contracts deployed on the chain (Solver encompasses not only node facilities but also on-chain contract components). The Solver contract will then pass the Intent instructions to the Reactor contract (which manages the user’s on-chain accounts), delegating the execution to complete the final interaction.

The user’s request is initially received by the Solver network, allowing users to not have to be overly concerned with the underlying chains or the construction of different account abstraction schemes, as this part is handled by the Solver to construct specific solutions.

Of course, these ideas are currently just a theoretical framework, and the implementation details are still pending official deployment by Particle Network. What is clear is that there will inevitably emerge a competitive Solver market in the future, where users can initiate auctions for multiple Solvers to propose different solutions. Through local simulated transactions, the optimal solution can be selected and the corresponding Solver can be rewarded. As for the form of incentives, it depends on the considerations of the protocol designers of the Solver network (Particle Network intends to use PNT tokens as incentives for its Solver auction market).

The current Intent essentially shields the underlying complex details and abstracts a higher layer. Such a layered design resembling the TCP/IP protocol is necessary for both user and developer experiences in seamless interoperability across chains.

Embracing widespread adoption of account abstraction

When we optimize the 4337 framework within the Ethereum ecosystem from various angles and simultaneously promote seamless interoperability across Ethereum and non-Ethereum ecosystems, in order to support the widespread adoption of account abstraction, we believe that there is still a need for a product that spans both the supply and demand sides. It should not only reduce the barriers for end-users to use various Web3 product services but also focus on service developers to lower their threshold.

One of the best products to play this role is Particle Network’s Modular Smart Wallet-as-a-Service (Modular Smart Wallet-as-a-Service) product:

The service provides an easy-to-use API that allows developers to seamlessly integrate modular account abstraction functionality into their applications. Developers can use this service to create and manage accounts across chains, perform cross-chain interactions, and utilize a unified fee payment method. Such a service will offer developers a more flexible and convenient way to build multi-chain applications, thereby promoting the widespread adoption of account abstraction.

In addition to the developer-friendly features mentioned above, the most significant aspect is that Particle Network’s Modular Smart Wallet-as-a-Service (Modular Smart Wallet-as-a-Service) product has built an open ecosystem for account abstraction in the developer community, based on signature computation. Apart from providing self-developed account abstraction product modules, it integrates various types of account abstraction products and services, facilitating the rapid adoption of products and services from various developers in the entire account abstraction domain.

By aligning technology with demand and addressing the limitations of the ERC-4337 framework from all angles, the improvement in developer experience will catalyze the emergence of more products with outstanding user experiences. This will accelerate the transition of the Web3 industry from being crypto-enthusiast-friendly finance-oriented to consumer-friendly and mainstream.

Disclaimer：

1. This article is reprinted from[腾讯网], All copyrights belong to the original author [Peter Pan, Co-founder and CTO of Particle Network &Faust，极客Web3]. If there are objections to this reprint, please contact the Gate Learn team, and they will handle it promptly.
2. Liability Disclaimer: The views and opinions expressed in this article are solely those of the author and do not constitute any investment advice.
3. Translations of the article into other languages are done by the Gate Learn team. Unless mentioned, copying, distributing, or plagiarizing the translated articles is prohibited.