The Final Piece of EIP-4337: Omnichain Account Abstraction

Since 2022, account abstraction has been a widely discussed topic, and the framework in the field of account abstraction centered around EIP-4337 seems to have become an industry consensus. The popularity of the concept of intent has underscored the importance of these low-threshold user interaction components.

However, EIP-4337 still has the pain points like smart account fragmentation and highly fragmented user experience of cross-chain account abstraction. This article explores how to further promote the development of the account abstraction field under the EIP-4337 framework, taking projects such as Biconomy, Safe Core, and Particle Network as examples.

Understanding the Concept of Account Abstraction from the Perspective of Transaction Flow Abstraction

Regarding account abstraction, Vitalik has pointed out many times that it is a necessary condition to lower the threshold of Ethereum users and achieve mass adoption. Its core vision is to allow users to customize the signature verification method and enjoy gas payment, and can initiate a transaction on-chain without any assets (commonly known as a gasless transaction). Only by realizing these prerequisites can Web3 applications improve their user conversion rates. Although previous non-account abstract proposals or smart contract wallets can achieve similar experiences, they are far from flexible and efficient enough. For example, Gnosis Safe still requires an EOA address to trigger transactions, and the gas costs it involves are extremely high. The account abstraction aims to optimize the underlying structure of smart contract accounts, paving the way for the next generation of intelligent account systems. But 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 the abstraction/modularization of the entire processing process of a transaction from initiation to being received by nodes, as well as the signature verification, gas payment, etc., rather than focusing on the abstraction of the account structure per se.. An abstraction of the account structure. Therefore, it seems more appropriate to call the various current proposals “transaction flow abstractions.” If we understand those well-known account abstraction proposals from the perspective of transaction flow abstraction, we can more easily grasp their main points: this kind of transaction abstraction actually aims to bring the user experience of Web2-level entry and product usage into the Ethereum system. This might take the form of blacklists/whitelists, initiating trasactions without identity verification within a certain period of time, gasless transactions, fiat currency payments, etc.

(Image source: Zengo)

However, some might ask: Couldn’t these things be achieved with existing smart contract wallets in the past? What is the value of account abstraction solutions such as EIP-4337 lie in?

Essence of EIP-4337: Local Optimal Solutions for Account Abstraction in the Ethereum Ecosystem

As the above question points out, while previous smart wallets could indeed achieve the functionalities mentioned, the implementation methods were generally rudimentary and often relied on highly centralized third-party infrastructures. For instance, in the past, the gas relay solution required the introduction of third-party relayer nodes (EIP-2771). Additionally, there was a lack of unified standards between different smart wallets, which hindered the development and deployment of complementary components. The core demand of various account abstraction-related EIPs is to address these deficiencies present in different wallet projects by introducing a standardized framework designed specifically for smart contract wallets. This advancement aims to shift the account structure within the Ethereum ecosystem from a basic functional structure to a more sophisticated smart structure with higher capabilities.

(Image source: Springer Link)

This is akin to the situation before ERC-20 or ERC-721, where the implementation methods, functionalities, and provided functions/interfaces of many tokens were inconsistent. Such inconsistencies hindered the development of complementary third-party infrastructures and code audits (it’s hard to imagine how DeFi applications could have thrived to their current level without the ERC-20 protocol).

Implementation standards for standardized protocols/features are prerequisites for modular design, and modular development is almost a prerequisite for any field aiming for vibrant growth (division of labor being the first principle to improve efficiency).

Ultimately, EIP-4337 stands out.

EIP-4337 is a local optimal solution, but several perspectives within its framework need to be optimized

EIP-4337 defines a complete set of interface standards, clarifying the modules expected in smart wallets that adhers to the 4337 protocol and the functions/interfaces each module should implement. For example, what callable functions should components like bundler, entrypoints, and paymaster offer externally. With these guidelines in place, the interactions between different components become clearer, facilitating the integration of modular design ideas into the design of account abstraction and smart wallets. Developers working on wallet modules also benefit significantly. However, looking purely from a user’s standpoint, the value brought by the modular smart wallet development paradigm might not be immediately evident since the changes in account abstraction wallets themselves might not be palpable in the short term. However, looking into the medium to long term, the value of protocols like EIP-4337 resembles that of ERC-20 and ERC-721. It lays the foundation for the long-term development of account abstraction wallets, marking a significant milestone. Nevertheless, EIP-4337 still has numerous unresolved issues, such as:

1. Account abstraction is not sufficiently easy to integrate, leading different developers to inadvertently “reinvent the wheel”.

2. Poor compatibility among account modules, resulting in a fragmented ecosystem.

3. High fragmentation of account abstraction ecosystems across different chains, making it challenging to offer a unified and high-quality experience for end-users and developers.

Below, we’ll delve into solutions for these issues.

Optimization Solution 1: Account Abstraction Plugin Will Become the Basic Configuration

One of the core focal points in current discussions regarding account abstraction is to enhance the modularization of account abstraction wallets and further refine the granularity of each module. For instance, Biconomy, based on EIP-4337 (the finer-grained EIP-6900 will be introduced in the future), proposes the plug-and-play account abstraction to further propel the modular development of the account abstraction ecosystem.

(Image source: Biconomy)

The so-called account abstraction plugin is actually to establish a protocol that explicitly defines the key modules involved in a smart contract wallet, outlining the interfaces/functions these modules should implement, and specifying the names and calling methods of these interfaces. Third-party developers will then create components with varying details based on their ideas, ensuring that these components comply with the requirements set forth in the protocol.

Biconomy’s v2, building upon EIP-4337 as the protocol framework, has devised more detailed standards and introduced a set of interfaces not mentioned in EIP-4337. While declaring the functionalities that bundlers, smart contract wallets, paymaster, and other modules should possess, Biconomy allows third-party developers to implement modules with the same features but different versions using different code details, as long as they adhere to the protocol guidelines established by Biconomy (compatible with EIP-4337).

(The interface standards proposed by Biconomy indicate which functions third-party module developers should implement within their modules for external calls). Besides, Biconomy introduced the slogan of “Module Store.” actively promoting the launch of an account abstraction module SDK while encouraging developers to submit their own designed account abstraction modules. This initiative aims to promote “module as a service,” allowing all wallet projects adhering to the EIP-4337 protocol to directly adopt these externally developed account abstraction modules. Users now have more diverse choices about which modules to use when creating smart accounts through the frontend.

Modularity not only facilitates the division of labor, but also facilitates users to quickly switch or add/remove certain functions in a smart wallet. To put it bluntly, it allows refining the granularity of components. Biconomy points out that the higher the degree of modularity in a smart contract wallet, the fewer changes it will need to make when updating or upgrading it. There is no need to update the user’s existing Smart Contract Wallet contract or use DelegateCall, only some external modules need to be updated, making it convenient for different users or developers to replace certain components.

In Biconomy’s forthcoming updated account abstraction scheme, they will also consider EIP-6900, which is more conducive to modularization than EIP-4337.

Optimization Solution 2: More Granular Module Segmentation to Address Account Fragmentation Issues

Regarding EIP-6900, Safe (formerly Gnosis Safe) released a Safe Core Protocol whitepaper in August this year, which draws heavily from EIP-6900.

(EIP-6900 Schematic) EIP-6900 highlights a prevalent issue in the current modular account abstraction, that is the “fragmentation” of accounts, or the island problem. For instance, while different account abstraction module providers or various DApps may be compatible with EIP-4337, its level of abstraction across different modules is insufficient, with a relatively low granularity. This scenario allows “excessive” freedom for smart account module developers (the smart account is the core component that stores user information, records custom transaction validation, and handles gas payment logic) to create modules with unique attributes. As a result, over time, different wallet projects tend to design smart account modules with distinct properties. This trend compels other account abstraction module providers to prioritize compatibility with specific smart account module providers, gradually forming fixed upstream-downstream supply chains. This inevitably leads to the fragmentation and isolation of the account abstraction module ecosystem (similar to early days in the computer industry, where operating system developers had to consider compatibility with hardware from different manufacturers). To address the issue of ecosystem fragmentation and enhance compatibility among account abstraction modules developed by various providers, the optimal approach is to further abstract smart contract wallet accounts and refine the granularity of module segmentation. Following the principles outlined in EIP-6900, the Safe Core Protocol whitepaper has made detailed optimizations to Smart Accounts (users’ intelligent wallet accounts). The Safe Core Protocol breaks down the callable modules within each smart wallet account into various categories such as plugins, hooks, signature validators, function processors, and more. Smart account modules aim to be as lightweight as possible, storing only essential data and functions, while delegating moveable functions to “function processors” or similar segmented modules. This approach aligns with the principle of Occam’s Razor – “entities should not be multiplied unnecessarily.” If smart accounts themselves are sufficiently lightweight and does not involve too complicated details, smart accounts developed by different providers will exhibit closer internal structures and higher compatibility.

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.

Generally, UserOperation will first trigger a plugin, and then the Manger will check whether the status of the plugin is normal (recorded in the registry). If normal, the plugin’s request will be allowed. If necessary, the plugin will call some functions provided by Hook or choose not to. Later, the status of the smart account involved in UserOperation will be changed.

Through the fine-grained module segmentation method and scheduling process mentioned above, Safe Core Protocol attempts to implement a set of open-source account abstraction module interoperability protocols. The core idea is to make smart account lightweight and as simple as an EOA account to enhance compatibility among smart account modules from different providers.

Optimization Solution 3: Omnichain Account Abstraction for Unified Accounts Across Different Chains

However, despite the aforementioned solutions, there remains a significant issue yet to be resolved: different chains and various Layer 2 solutions are advancing divergent account abstraction implementation details, many of which conflict with EIP-4337, such as zkSync Era, Starknet, Flow, etc. This fragments wallet UX for users. For example, smart wallet addresses on Starknet cannot be unified with those on Arbitrum. Additionally, in a multi-chain environment, users have independently deployed smart accounts on different chains, and their corresponding user data is often scattered across these contracts. If user data such as keys need to be updated, transactions need to be initiated repeatedly on multiple chains, making it difficult to ensure the consistency of the Smart Account. Vitalik has previously proposed a smart account solution that is unified across the entire chain and easy to manage. This solution uses Ethereum or a highly secure ZK-Rollup as the source chain and deploy the Keystore contract to store the user’s global key. Then, all smart contract accounts on Layer 2 share the global key stored in the Keystore contract.

(Image source: https://vitalik.ca/general/2023/06/20/deeperdive.html)

However, this solution incurs significant costs. Whenever the global keys recorded in the Keystore contract on the source chain change, each account on L2/the target chain needs to synchronize the new keys through cross-chain interactions. The overhead of cross-chain interactions between Ethereum and Layer 2 is too high for users to bear. Furthermore, it’s crucial to note that smart contract accounts differ from EOAs. The latter, due to their unique address generation approach, are inherently unified across multiple EVM chains. But smart contract accounts are entirely different, making it challenging for users to obtain smart contract accounts with the same addresses on different chains. In response, Particle Network has proposed its own method. While the general idea of their method aligns with Vitalik’s concept, focusing on separating the Storage and Code of smart accounts, Particle Network intends to utilize an independent chain—Particle Network Chain—as the complete Storage database for smart accounts. They plan to synchronize changes to an account’s Storage to the Account’s local storage on other chains via third-party cross-chain messaging solutions (such as LayerZero, CCIP, Axelar, Connext, etc.).

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

Particularly, Particle Network’s Omnichain Account Abstraction system allows users to have a unified smart contract account address on different EVM chains. This requires deploying a set of Deployer Contracts on different chains; users must trigger the generation of new accounts on Particle Network Chain, and then Particle Chain will trigger Deployer Contracts on all chains to ensure the smart contract account addresses generated for users on different chains are consistent. Alternatively, users can engage in multi-chain interactions through contracts on the Particle chain without being aware of other chains, and can utilize the Unified Gas Token as a universal payment method for transaction fees.

Omnichain Account Abstraction also enables cross-chain user operations by initiating transactions on the target chain through user operations and paying the corresponding gas on the source chain. For example, this allows users to purchase NFTs on Base using Polygon’s $USDC.

However, Particle Network’s solution requires a high degree of collaboration between the Deployer Contract and the cross-chain messaging component to achieve synchronization of multi-chain accounts and source chain storage. This actually places higher requirements on the oracle or cross-chain message bridge used (which seems to be a common issue in all solutions related to omnichain interoperability). However, the user’s cross-chain account synchronization can flexibly configure the combination of different Message Bridges, instead of relying on a single bridge. For example, it can be configured as a 2/3 strategy, relying on the confirmation of any two of LayerZero, Axelar, and Connext for confirming storage changes on the target chain. This might be a potential solution to the single-point dependency issue.

Seamless Omnichain Interoperability across EVM and non-EVM is a Further Step Towards Omnichain Account Abstraction within the Ethereum Ecosystem

Despite having key management and unified accounts across EVM chains, there are still areas for optimization within omnichain account abstraction. Non-EVM-compatible chains like Aptos, Solana, Sui, etc., cannot guarantee smart contract account addresses are consistent with those on EVM chains. Moreover, non-EVM chains would find it challenging to adopt the concept of cross-chain account abstraction proposed in the previous discussion if they do not implement the ERC-4337 protocol with an equivalent solution. Additionally, there is room for improvement within wallet projects compatible with EIP-4337. The Bundler nodes used by most smart wallets are officially run independently, sometimes even in isolation from each other, creating various risks (such as risks related to censorship resistance and availability). Constructing a unified frontend interface spanning across a majority of chains proves to be immensely challenging. One potential solution is to introduce an intent-centric design, adding an additional layer on top of omnichain account abstraction. This layer incorporates Ethereum’s EIP-4337 ecosystem or other chains’ native account abstraction facilities (e.g., zkSync) as specific instances under the Solver/Reactor type, with the task of selecting the appropriate Solver being an upper-level responsibility. Taking Particle Network as an example, it proposes a concise and abstracted intent-centric implementation. Different account abstraction projects are merely instances included in the Solver category within the intent scheme. Firstly, the user frontend transforms natural language requests or any user interaction into specific programmatic descriptions encompassing input and output constraints (In other words, these are conditions that allow for inputs that satisfy user requirements and output results falling within a specific range). Subsequently, within the Solver network, specific Solver(s) forward transactions containing precise input and output constraints to Solver contracts deployed on the chain (Solvers encompass not only node infrastructure but also on-chain contract components). The Solver contract transmits the Intent directive to the Reactor contract (managing user accounts on-chain), delegating the latter to call other modules to fulfill the final interaction. This framework allows user requests to be initially processed by the Solver network, alleviating the need for users to comprehend underlying chains or different account abstraction schemes, a task delegated to the Solver for constructing specific solutions. However, these conceptualizations are still theoretical frameworks, with implementation details awaiting further elaboration by Particle Network. It’s apparent that a competitive Solver market will emerge in the future, enabling users to initiate bidding where multiple Solvers propose distinct solutions. Through locally simulated transactions, the optimal solution can be selected and corresponding incentives can be provided to their Solver. The incentive structure will be shaped by the protocol designers of the Solver network (Particle Network aims to use PNT tokens as incentive tokens for its Solver auction market). At present, the essence of intent shields complex details of the lower layers and abstract a higher layer. This layered design, which resembles the TCP/IP protocol, is essential for improving both user experience and developer experience in seamless interoperability across chains.

Embracing Mass Adoption of Account Abstraction

After optimizing the EIP-4337 framework within the Ethereum ecosystem from various aspects and advancing seamless interoperability across Ethereum and non-Ethereum ecosystems, we believe that, to support the mass adoption of account abstraction, we still need a product that spans the supply and demand sides. This product should reduce the complexity for end-users utilizing various Web3 product services while focusing on lowering developer’s entry barriers. One of the optimal products fulfilling this role is Particle Network’s Modular Smart Wallet-as-a-Service Stack:

（Particle Network’s Smart Wallet-as-a-Service Architecture）

• The service offers a user-friendly API, enabling developers to seamlessly integrate modular account abstraction functionalities into their applications.
• Developers can use this service to create and manage omnichain accounts, conduct cross-chain interactions, and use a unified fee payment method.
• Such services will provide developers with a more flexible and convenient way to build multi-chain applications and promote the widespread adoption of account abstraction.

In addition to the above developer-friendly features, the most crucial aspect of Particle Network’s Modular Smart Wallet-as-a-Service stack is that it built an open ecosystem for the account abstraction domain, based on signature computation and oriented toward developers. Alongside their in-house account abstraction product modules, Particle Network integrates various types of account abstraction products and services. This integration accelerates the adoption of products and services across the entire account abstraction domain for developers.

（Modular Design of Particle Network’s Smart Wallet-as-a-Service）Let technology serves users’ needs. After solving the limitations of the ERC-4337 framework, the improve of developer experience will lead to the emergence of more products with excellent user experiences, accelerating the transition of Web3 from a crypto-punk-friendly financial industry to a consumer-friendly industry for the masses.

Disclaimer：

1. This article is reprinted from [极客 Web3]. 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.