The Final Piece of ERC-4337: Omnichain Account Abstraction

–credits to Particle Network's Co-Founder and CTO, Peter Pan, and Faust.

Understanding the concept of Account Abstraction from the perspective of Transaction Flow Abstraction

Multiple thought leaders in the field of account abstraction (AA), including Vitalik Buterin, agree that, to achieve mass adoption, it is a pressing necessity to lower UX and entry barriers for Ethereum users. AA’s core vision is to do precisely this by allowing users to customize their signature verification methods and enjoy gas payments made on their behalf for “free” (commonly known as gasless) on-chain transactions. It's a common understanding that, by achieving these prerequisites, Web3 applications can improve their conversion rates, consequently helping the industry grow.

However, previous proposals for account abstraction or smart contract wallets, although they can achieve similar experiences, are still not flexible and efficient enough. For example, many solutions still require an EOA address to trigger transactions, and gas costs for this approach are extremely high.

Account Abstraction should aim for optimizations to begin from the underlying structure of smart accounts, laying the foundation for the next generation of intelligent account systems.  When we look at current account abstraction proposals, it’s clear that their focus is not on the account model itself, but on transactions.

For example, leading account abstraction-related proposals such as EIP-86, ERC-4337, and ERC-6900 focus on abstracting/modularizing the entire processing flow of a transaction from initiation to being received by nodes (focusing on signature verifications, gas payments, etc.), rather than truly abstracting the account structure. Therefore, it seems more appropriate to call these various proposals "transaction flow abstraction."

If we understand these well-known account abstraction proposals from the perspective of transaction flow abstraction, we can easily grasp their key points: transaction flow abstraction actually aims to bring the user experience of Web2-level entry and product usage into the Ethereum ecosystem. This might take the form of blacklists/whitelists, transactions without identity verification for a period of time, gasless transactions, fiat currency payments for transaction fees, etc.

But one might ask: Couldn't these things be achieved on previous smart contract wallets? What is the value of account abstraction proposals like ERC-4337?

The essence of ERC-4337: Account abstraction as an optimal solution to implement in the Ethereum ecosystem

As mentioned above, although previous smart wallets were able to achieve the functionalities mentioned earlier, their implementation methods were generally crude and often relied on highly centralized third-party facilities. For example, in the past, the gas relay solution required the introduction of a third-party Relayer node (EIP-2771). Furthermore, there was a lack of unified standards among different smart wallets, which hindered the development and deployment of complementary components.

The core demand of various AA EIPs is to address the flaws present in different wallet projects by introducing a standardized framework specifically designed for smart contract wallets. This framework aims to transform the account structure within the Ethereum ecosystem from a basic functional structure to a more sophisticated smart structure with higher capabilities.

The state of AA is similar to the situation before ERC-20 or ERC-721 appeared, where the implementation methods, functionalities, and provided functions/interfaces of many tokens were inconsistent. This inconsistency hindered the development of supporting third-party infrastructure and made code audits difficult. Presently, it is hard to imagine the current prosperity of DeFi applications without the ERC-20 protocol.

Standardized protocols/function implementations are a prerequisite for the modular narrative, and modular development is almost a prerequisite for vigorous development in every field, as division of labor is the first principle to improve efficiency.

In the end, ERC-4337 stood out as the most viable short-term solution with long-term positive repercussions.

ERC-4337 is an optimum solution, but multiple aspects within its framework need to be improved

ERC-4337 defines a set of interface standards that specify the modules required for a smart wallet following the 4337 protocol and the functions/interfaces each module should implement, such as Bundlers, EntryPoints, and Paymasters.

Once these specifications are established, the interaction between different components becomes clear, making it easier to incorporate a modular approach into the design of AA and smart wallets, greatly benefiting wallet module developers.

Of course, from a user's perspective, the value of the modular smart wallet development paradigm may not be clear, as they may not immediately perceive significant changes in the AA wallet itself. However, in the medium to long term, the value of protocols like ERC-4337 is similar to what we described for ERC-20 and ERC-721’s, as it lays the foundation for the long-term development of AA wallets and represents a milestone of epoch-making significance.

Nonetheless, ERC-4337 still has many unresolved issues, such as:

1. AA is not sufficiently easy to integrate, making it easy for different developers to try to “reinvent the wheel”.
2. Account module compatibility is poor, resulting in a fragmented ecosystem.
3. The AA ecosystem is highly fragmented between different chains, making it difficult to provide end-users and developers with a unified and high-quality experience, resulting in subpar UX implementations.

In the following sections, we will showcase different proposed solutions to these problems.

Optimization direction 1: AA Plug-on features as basic configuration

It can be said that one of the core discussion points when it comes to AA is how to better modularize AA wallets, and further refine the granularity of each module.

For example, Biconomy proposes the narrative of AA functional modularization based on ERC-4337 (in the future, a finer-grained ERC-6900 will be introduced) to further promote the modular development of the account abstraction ecosystem.

The so-called modularization of AA is actually a set of protocols that clearly define the key modules involved in smart contract wallets. These modules should implement specific interfaces/functions and have specific names and invocation methods. Third-party developers can then develop components with different specifications according to their own ideas, but these components must comply with the requirements outlined in the protocol.

Biconomy's V2 version uses ERC-4337 as the protocol framework and has established more detailed standards. It has also added a batch of interfaces that were not mentioned in ERC-4337. While specifying the functionalities that Bundler, Smart Contract Wallet, and Paymaster modules should have, Biconomy allows third-party developers to implement modules with the same features but different versions using different code details –as long as they comply with the protocol guidelines (compatible with ERC-4337) declared by Biconomy.

At the same time, Biconomy has also put forward the slogan of the "Module Store" while launching its Account Abstraction Module SDK, encouraging developers to submit their own designed AA modules. This initiative aims to promote "Module-as-a-Service" so that all wallet projects that comply with the ERC-4337 protocol can directly adopt these externally developed AA modules. When users create smart accounts through the front-end interface, this results in a more diverse selection of modules to choose from.

Modularization facilitates division of work and enables users to quickly switch or add/remove certain functions in a smart wallet. In other words, it allows for finer granularity. Biconomy also points out that the higher the degree of modularity in a smart contract wallet, the fewer changes are required when updating or upgrading it. With high modularity, there is no need to update the existing Smart Contract Wallet contract or use DelegateCall; only certain external modules need to be updated, making it easier for different users or developers to replace specific components.

Biconomy's future version of the AA scheme will also consider the ERC-6900 proposal, which is more conducive to modularity, in addition to referencing ERC-4337.

Optimization direction 2: Finer-grained module segmentation to solve the fragmentation problem of accounts

In light of ERC-6900, Safe (formerly Gnosis Safe) released the whitepaper for its Safe Core Protocol in August this year, drawing inspiration mostly from this proposal.

ERC-6900 states that a current issue with modular AA is the "fragmentation" or "island problem” of accounts. For example, different AA module providers or different decentralized applications may be compatible with ERC-4337, but ERC-4337 does not provide a high enough level of abstraction for different modules. The granularity of the divisions is relatively coarse, leaving "excessive" freedom for smart account module developers --the smart account being the core component that stores user information, records custom transaction validation, and handles gas payment logic).

As a result, different wallet projects tend to design smart account modules with unique attributes. It also leads to, over time, other account abstraction module providers needing to prioritize compatibility with the provider of the Smart Account module, resulting in the formation of a fixed upstream and downstream supply chain. This inevitably gives way to fragmentation and isolation of the AA module ecosystem. To exemplify the implications of this, consider how, in the early days of the computer industry, operating system developers had to consider compatibility with the hardware devices provided by different computer manufacturers.

To address the ecosystem’s fragmentation and improve the compatibility of AA modules developed by different providers, the best approach is to further abstract the smart contract wallet accounts and make the module division more granular.

Drawing inspiration from ERC-6900, the Safe Core protocol whitepaper provides more detailed optimizations for users' smart accounts. Safe Core divides the modules callable by each smart account into various categories, such as Plugins, Hooks, signature validators, and function processors.

In this implementation, the smart account module itself needs to be as lightweight as possible, with the account contract only storing essential data and functions. Functions that can be moved outside are implemented by the function processor or Plugin modules. This follows the principle of Occam's Razor – "entities should not be multiplied unnecessarily."

If the smart account itself is lightweight enough and does not involve overly complex details, smart accounts developed by different manufacturers will have closer internal structures and higher compatibility.

In the Safe Core protocol, a registry is introduced, similar to Apple’s App Store, which contains all approved available modules. Users can choose to activate specific modules, and every time a new module is activated, it has to go through the Manager contract for processing.

In general, each UserOperation triggers a specific plugin first, and then the Manager contract checks if the plugin is active (recorded in the registry). If it is, the plugin's request will be allowed. If necessary, the Plugin may also invoke certain functionalities provided by the Hook. Afterward, the state of the smart account involved in the UserOperation will be modified.

Through its fine-grained module segmentation and scheduling process mentioned above, the Safe Core Protocol attempts to promote an open-source account abstraction module interoperability protocol. The core idea is to lightweight Smart Accounts and make them as simple as EOA accounts to improve compatibility with Smart Account modules developed by different vendors.

Optimization direction 3: Omnichain account abstraction with cross-chain abilities

Even with the aforementioned solutions, there is still a major problem to be solved: different chains and different Layer-2 solutions are advancing their own account abstraction implementations with different specifications, many of them conflicting with ERC-4337 (such as zkSync Era, Starknet, Flow, etc.) This fragments wallet UX for users, as smart wallet addresses on Starknet, for example, cannot be unified with smart wallet addresses on Arbitrum.

Additionally, in a multi-chain environment, users independently deploy smart accounts on different chains, and their corresponding user data is often scattered across these contracts. Even with a central controller, if user data (such as keys) needs to be updated, multiple transactions must be initiated across multiple chains, making it difficult to ensure the consistency of smart accounts.

Vitalik Buterin himself has previously proposed a unified and easily manageable smart account solution across chains. This solution uses Ethereum or a highly secure zk-rollup as the source chain and deploys a Keystore contract to store users' global keys. Users' smart contract accounts on L2s then share the global keys stored in the Keystore contract.

Nonetheless, this solution comes at a very high cost. Whenever the global key recorded in the Keystore contract on the source chain changes, every account on the L2/target chain needs to synchronize it through cross-chain interaction. However, the cost of cross-chain interactions between Ethereum and L2s is too high for users to afford  (not to mention set-up costs). Additionally, it is important to note that smart contract accounts are different from EOA accounts. The latter, due to their specific address generation method, are inherently unified across multiple EVM chains. However, smart contract accounts are completely different, and it is difficult for users to obtain smart contract accounts with the same address on different chains.

In response to this, Particle Network proposes its own Omnichain Account Abstraction method. Although the general idea is similar to Vitalik's, separating the Storage and Code of smart accounts, Particle Network plans to use an independent chain –the Particle Chain– as the full-chain Storage database for smart accounts. Through third-party cross-chain messaging solutions (such as LayerZero, CCIP, Axelar, Connext, etc.), changes to an account's Storage by a user will be synchronized to the Account's local storage on other chains.

Specifically, Particle Network's Omnichain Account Abstraction system allows users to have a unified smart contract account address on different EVM chains. To achieve this, our design involves deploying a set of Deployer Contracts on each chain. Users must trigger the generation of a new account on the Particle Chain, which will cause it to trigger all Deployer Contracts on different chains. This ensures that the generated smart contract account addresses are consistent across them. Alternatively, users can interact with multiple chains through contracts on the Particle Chain without being aware of other chains, and they can use Particle’s Unified Gas Token as a unified fee payment method.

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 $USDC.

However, Particle Network's solution requires a high level of coordination between the Deployer Contracts and cross-chain message-passing components to achieve synchronization between multi-chain accounts and source chain storage. This places high demands on the oracle or cross-chain message bridge used –which seems to be a common issue in all solutions related to full-chain interoperability. However, synchronizing the user's cross-chain account can be flexibly configured with different combinations of Message Bridges, rather than relying on a single bridge. For example, this setup can be configured with a 2/3 strategy, where confirmation from any two of LayerZero, Axelar, and Connext is required to confirm the storage change on the target chain. This can approximate a solution to the single-point-of-dependency problem.

Seamless interoperability across EVM and non-EVM chains: Further optimization of Omnichain Account Abstraction within the Ethereum ecosystem

Despite the possibility for key management solutions and unified accounts across EVM chains, there is still room for improvement in the abstraction of cross-chain accounts. Chains that are incompatible with EVM (such as Aptos, Solana, and Sui) cannot guarantee that the addresses of smart contract accounts generated by users are consistent with those on EVM chains. Additionally, 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.

Furthermore, there is also room for improvement in wallet projects that are compatible with ERC-4337. Most smart wallets use Bundler nodes that run independently, with no interoperability between them. In fact, many smart wallet projects operate as separate chains, which introduces various risks related to censorship and availability, among others. Building a unified frontend interface that spans across the majority of chains, however, would be quite difficult. One potential solution is to introduce intent-centric design, adding an additional layer on top of cross-chain account abstraction. Within this layer, Ethereum’s ERC-4337 ecosystem and the native account abstraction facilities of other chains (such as zkSync) would be regarded as specific instances under the Solver/Reactor types, with the task of selecting the appropriate Solver being an upper-level responsibility.

Particle Network proposes a concise and abstracted Intent-Centric implementation approach, and different AA projects are merely a category of instances included within the Solver's scope.

In Particle’s design, the user interface is responsible for transforming natural language requests or any user interactions into specific programmatic descriptions, including input and output constraints –in other words, conditions that allow for inputs that satisfy user requirements and output results falling within a specific range. Afterward, one or more Solvers in the Solver network forward the transaction containing the specific input and output constraints to the Solver contract deployed on-chain (Solvers include both node facilities and on-chain contract components). The Solver contract will then send the intent instructions to the Reactor contract responsible for user accounts on the chain, allowing the latter to invoke other modules to complete the final interaction.

In this setup, the user's request is initially processed by the Solver network, so the user does not need to have extensive knowledge of the underlying chains or the construction of different account abstraction schemes. The Solver handles this part to construct the specific solution.

Of course, these ideas are currently only a theoretical framework, and the implementation details are still pending official elaboration by Particle Network. What is certain is that, in the future, a competitive Solver market will undoubtedly emerge. Within this market, users will be able to initiate bids to have multiple Solvers propose different solutions. Through local simulated trading, the optimal solution can be selected, and corresponding incentives can be provided to their Solver. As for the form of these incentives, it will depend on the considerations of the protocol designers of the Solver network. Particle Network plans to use its native token to incentivize activity in its own Solver auction market.

Intents essentially shield the complex details of the lower layers and abstract a higher layer. This layered design, which resembles the TCP/IP protocol, is essential for both user experience and developer experience in seamless interoperability across chains.

Embracing the mass adoption of Account Abstraction

After optimizing the 4337 framework within the Ethereum ecosystem from various perspectives, and promoting seamless interoperability across both Ethereum and non-Ethereum ecosystems, we believe that, to support the mass adoption of AA, we still need a product that spans the supply and demand sides. This product should reduce the complexity for end users in using various Web3 services and focus on developers, lowering the entry barriers for them.

One of the best products playing this role is Particle Network's Modular Smart Wallet-as-a-Service. This service:

• Provides an easy-to-use API allowing developers to easily integrate modular AA functionalities into their dApps.
• Can be used to create and manage full-chain accounts, perform cross-chain interactions, and rely on a unified fee payment method.
• Can provide developers with a more flexible and convenient way to build multi-chain applications, promoting the widespread adoption of AA.

In addition to the developer-friendly features mentioned above, the most important feature is that Particle Network's Modular Smart Wallet-as-a-Service has built an open ecosystem for the AA domain, based on signature computation and oriented toward developers. In addition to providing self-developed AA product modules, it integrates various types of AA services to quickly promote the adoption of products from developers across the entire domain.

Let technology serve users’ needs. After addressing the various limitations of the ERC-4337 framework, the improvement of developer experience will lead to the emergence of more products with excellent user experience, accelerating the transformation of Web3 from a crypto-punk-friendly financial industry to a consumer-friendly industry for the masses.

About Particle Network

Particle Network powers chain abstraction, addressing Web3's fragmentation of users and liquidity. This is enabled by Particle's Universal Accounts, which give users a unified account and balance across all chains.

Website | Docs | Discord | Twitter