The final piece of the puzzle for EIP-4337: Full-chain account abstraction
Author: Peter Pan, Co-founder and CTO of Particle Network & Faust, Geek Web3
Since 2022, account abstraction has been a widely discussed topic, with the framework centered around EIP-4337 seemingly becoming a common consensus in the industry. The heated interest in the concept has prompted people to pay more attention to low-barrier user interaction components. However, EIP-4337 still faces pain points such as the fragmentation of Smart Account accounts and the highly fragmented user experience of account abstraction across chains. This article takes projects like Biconomy, Safe Core, and Particle Network as examples to explore how to further promote the development of account abstraction under the EIP-4337 framework.
Understanding the Concept of "Account Abstraction" from the Perspective of Transaction Process Abstraction
Regarding account abstraction, Vitalik has repeatedly pointed out that it is a necessary condition for lowering the threshold for Ethereum users and achieving mass adoption. Its core vision is to allow users to customize verification methods + enjoy gas payment, enabling transactions on-chain without any assets (commonly known as gasless transactions). Only by achieving these prerequisites can the new user conversion rate for Web3 applications be improved. Previous non-account abstraction proposals or smart contract wallets, while capable of providing similar experiences, are still far from flexible and efficient. For example, Gnosis Safe still requires an EOA address to trigger transactions, and the gas costs incurred are extremely high. Account abstraction aims to optimize the underlying structure of smart contract accounts, paving the way for the next generation of intelligent account systems. However, looking at actual account abstraction proposals, we find that their focus is not on the account model itself. Proposals related to account abstraction, such as EIP-86, EIP-4337, and EIP-6900, focus on abstracting/module-izing the entire processing flow of a transaction from initiation to receipt by nodes, verification, and gas payment, rather than genuinely addressing the abstraction of account structures. Therefore, it seems more appropriate to refer to the various proposals currently as "transaction abstraction." If we understand those well-known account abstraction proposals from the perspective of "transaction processing flow abstraction," we can more easily grasp their key points: this transaction abstraction essentially aims to bring the Web2-level user experience of entering and using products into the Ethereum system, such as blacklists/whitelists, initiating transactions without identity verification for a period, gasless transactions, and fiat payment of fees. 
* (Image source: Zengo)* But some may ask: weren't these things achievable with past smart contract wallets? What is the value of account abstraction solutions like EIP-4337?
The Essence of EIP-4337: A Local Optimal Solution for Account Abstraction in the Ethereum Ecosystem
As mentioned in the above question, while past smart wallets could achieve the functions discussed above, their implementation methods were generally quite crude and often relied on highly centralized third-party facilities. For example, past gas payment solutions required the introduction of third-party relayer nodes (EIP-2771). Moreover, there is a lack of unified standards among different smart wallets, which is not conducive to the development and deployment of supporting components. The core demand of various account abstraction-related EIPs is to solve the defects present in different wallet projects through a standardized framework specifically designed for smart contract wallets, promoting the transformation of account structures within the Ethereum ecosystem from basic functional structures to more advanced intelligent structures. 
* (Image source: Springer Link)* This is akin to the situation before the emergence of ERC-20 or ERC-721, where many token implementations, functionalities, and external functions/interfaces were inconsistent, and "inconsistency" hindered the development of supporting third-party facilities and code audits (it is hard to imagine how DeFi applications could have developed to their current level of prosperity without the ERC-20 protocol). Standardized protocols/functionality implementation standards are prerequisites for modular narratives, and modular development approaches are almost prerequisites for thriving in every field (division of labor is the first principle of improving efficiency). Ultimately, EIP-4337 stands out.
EIP-4337 is a Local Optimal Solution, but Multiple Aspects Within Its Framework Need Optimization
EIP-4337 defines a complete set of interface standards, clarifying what modules smart wallets adhering to the 4337 protocol must have and what functions/interfaces each module should implement, such as what callable functions Bundler, EntryPoint, and Paymaster components should provide. Once these rules are clarified, the interaction relationships between different components become clearer, facilitating the introduction of modular design thinking into the design of account abstraction and smart wallets, greatly benefiting wallet module developers. Of course, from a purely user perspective, the value brought by the modular smart wallet development paradigm is still unclear, as users may not perceive significant changes in account abstraction wallets in the short term. However, from a medium to long-term perspective, the value of protocols like EIP-4337 is similar to that of 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: For example: 1. The functionality of account abstraction is not sufficiently plugin-based, making it easy for different developers to reinvent the wheel; 2. The compatibility of account modules is poor, leading to a tendency for the entire account system to present a fragmented ecological state; 3. The account abstraction ecosystem across different chains is highly fragmented, making it difficult to provide a unified and high-quality experience for end users and developers, resulting in a better UX. In the following text, we will explore solutions to these issues.
Optimization Direction One: Plugin-based Functionality of Account Abstraction Will Become Basic Configuration
It can be said that one of the core discussion points related to account abstraction now is how to better achieve the modularization of account abstraction wallets, making the granularity of each module's division finer. For example, Biconomy has proposed a narrative of plugin-based functionality for account abstraction based on EIP-4337 (and will introduce the finer-grained EIP-6900 in the future) to further promote the modular development of the account abstraction ecosystem. 
* (Image source: Biconomy)* The so-called plugin-based functionality of account abstraction is essentially about clearly defining the key modules involved in smart contract wallets through a set of protocols, specifying what interfaces/functions these modules should implement, and how the names and calling methods of these interfaces are structured. Then, third-party developers can create components with varying details according to their ideas, but these components will comply with the requirements set forth in the protocol. Biconomy's V2 version uses EIP-4337 as the protocol backbone, establishing more detailed standards and adding a batch of interfaces not mentioned in 4337. While stating what functions 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 adhere to the protocol details declared by Biconomy (compatible with EIP-4337). 
* (The interface standards proposed by Biconomy indicate which functions third-party module developers should implement for external calls within the module)* At the same time, Biconomy has also proposed the slogan "Module Store," actively launching an SDK for account abstraction modules while encouraging developers to submit their designed account abstraction modules, initiating "Module as a Service," allowing all wallet projects adhering to the EIP-4337 protocol to directly adopt these account abstraction modules created by outsiders. Users have more diverse choices regarding which modules to adopt when creating smart accounts through the front-end page. 
Modularization not only facilitates division of labor but also allows users to quickly switch, add, or remove certain functionalities in their smart wallets (essentially making the granularity finer). Biconomy points out that the higher the modularity of smart contract wallets, the fewer changes are required during updates or upgrades (there is no need to update 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 account abstraction solution, it will also reference EIP-6900, which is more conducive to modularization.
Optimization Direction Two: Finer Granularity of Module Division to Solve Account Fragmentation Issues
Regarding the EIP-6900 proposal, Safe (formerly Gnosis Safe) actually launched a white paper related to it in August this year, which draws heavily from EIP-6900. 
* (EIP-6900 Schematic Diagram)* EIP-6900 points out that one issue with modular account abstraction is the "fragmentation" of accounts, or the island problem. For instance, different account abstraction module providers or different DAPP applications may be compatible with EIP-4337, but EIP-4337 does not abstract different modules to a sufficiently high degree, and the granularity of division is relatively coarse, leaving Smart Account module developers with "excessive" freedom (the smart account is the core part that stores user information and records custom transaction verification and gas payment logic). As a result, different wallet project parties tend to design smart account modules with unique attributes. Over time, other account abstraction module providers must prioritize compatibility with the Smart Account modules provided by certain vendors, gradually leading to a fixed upstream and downstream supply chain, which will inevitably result in fragmentation and disconnection of the account abstraction module ecosystem. (This is akin to the early days of the computer industry, where operating system developers had to consider compatibility with hardware vendors first.) To solve the problem of ecological fragmentation and improve the compatibility of account abstraction modules developed by different providers, the best approach is to further abstract smart contract wallet accounts and make the granularity of module division finer. After borrowing ideas from EIP-6900, the Safe Core protocol white paper has made more detailed optimizations to Smart Accounts (user smart wallet accounts). The Safe Core protocol breaks down each callable module of a smart wallet account into various categories such as Plugin, Hooks, signature verifiers, and function processors. The smart account module is kept as lightweight as possible, with the account contract only storing the most basic data and functions, delegating any functions that can be moved outside to "function processors" or "Plugins." This aligns with the so-called Occam's Razor principle—"entities should not be multiplied beyond necessity." If the smart account itself is lightweight enough and does not involve overly complicated details, smart accounts developed by different vendors will be closer in internal structure, leading to higher compatibility. 
The Safe Core protocol also introduces a registry, similar to the iPhone App Store, containing all approved available modules. Users can choose which modules to activate, and each time a new module is activated, it must be processed by the Manager contract. 
Generally, the UserOperation will first trigger a certain Plugin, and then the Manager contract will check whether the status of that Plugin is normal (recorded in the registry); if normal, it will allow the Plugin's request. If necessary, the Plugin may call functions provided by certain Hooks or not. It will then change the status of the smart account involved in the UserOperation. 
Through the above fine-grained module division and scheduling process, the Safe Core Protocol attempts to promote a set of open-source account abstraction module interoperability protocols, with the core idea being to make Smart Accounts lightweight and as simple as EOA accounts to improve the compatibility of Smart Account modules developed by different vendors.
Optimization Direction Three: Full-Chain Account Abstraction to Achieve Unified Accounts Across Different Chains
However, even with the aforementioned solutions, there is still a significant unresolved issue: different chains and Layer 2s are advancing account abstraction implementation solutions with varying details, many of which adopt forms that conflict with EIP-4337, such as zkSync Era, Starknet, and Flow. This leads to fragmentation in wallet UX for users, as the smart wallet address on Starknet cannot be unified with the smart wallet address on Arbitrum. Moreover, in a multi-chain environment, users have independently deployed Smart Accounts on different chains, and the corresponding user data is often stored separately in these contracts. If user data, such as keys, needs to be updated, transactions must be initiated repeatedly across chains, making it difficult to ensure the consistency of Smart Accounts. Vitalik himself previously proposed a unified and easily manageable smart account solution across chains, which uses Ethereum or a highly secure ZKRollup as the source chain, deploying a Keystore contract to store the user's global key, and then all smart contract accounts on L2 share the global key stored in the Keystore contract. 
* (Image source: https://vitalik.ca/general/2023/06/20/deeperdive.html)* However, this solution is extremely costly, as whenever the global key recorded in the Keystore contract on the source chain changes, each account on L2/target chains needs to synchronize the new key through cross-chain interactions. The cross-chain interaction costs between Ethereum and L2 are too high for users to bear. Moreover, it is important to note that smart contract accounts are different from EOA accounts; the latter, due to their unique address generation method, are inherently multi-chain unified (unified across EVM chains), but smart contract accounts are entirely different, making it difficult for users to obtain the same smart contract account address across different chains. In response, Particle Network has proposed its own method. Although the general idea is similar to Vitalik's, also separating the Storage and Code of smart accounts, Particle Network intends to use an independent chain—Particle Network Chain—as the full-chain Storage database for smart accounts, synchronizing any changes a user makes to their account Storage to local Accounts on other chains through third-party cross-chain messaging solutions (LayerZero, CCIP, Axelar, Connext, etc.). 
* (Particle Network's multi-chain account abstraction structure)* Specifically, Particle Network's full-chain account abstraction system aims to allow users to have a unified smart contract account address across different EVM chains, which requires deploying a set of Deployer Contracts on different chains; users must trigger the creation of new accounts on Particle Network Chain, after which the Particle Chain will trigger the Deployer Contracts on all chains to ensure that the smart contract account addresses generated for users across different chains are unified, or users can complete the multi-chain interaction process through contracts on the Particle chain without being aware of other chains, and can use Unified Gas Token as a unified fee payment method. Full-chain account abstraction also makes Cross-Chain User Operations possible, triggering Transactions on the target chain through User Operations on the source chain and paying the corresponding gas, such as using Polygon's USDC to purchase NFTs on Base. However, Particle Network's solution requires the Deployer Contract and cross-chain messaging components to work in high coordination to synchronize multi-chain Accounts and source chain Storage, which actually places high demands on the oracles or cross-chain messaging bridges used (this issue seems to exist in all solutions related to full-chain interoperability). However, users' cross-chain account synchronization can flexibly configure different combinations of Message Bridges, rather than relying solely on one Bridge; for example, it can be configured to a 2/3 strategy, requiring confirmation from any two of LayerZero, Axelar, or Connext before confirming the Storage changes on the target chain, which can approximately solve this single-point dependency issue. Seamless interoperability across EVM and non-EVM chains is a further advancement of full-chain account abstraction within the Ethereum ecosystem. Although there is key management and unified accounts across EVM chains, full-chain account abstraction still has room for optimization: non-EVM chains, such as Aptos, Solana, and Sui, cannot guarantee that the smart contract account addresses generated by users will be consistent with those on EVM chains; at the same time, if non-EVM chains do not implement the EIP-4337 protocol with equivalent solutions, it will be difficult to carry forward the full-chain account abstraction concepts proposed by Vitalik and Particle Network. Furthermore, wallet projects compatible with EIP-4337 also have room for improvement. Most smart wallets use Bundler nodes that are independently operated by the official, and they do not even communicate with each other; many smart wallet projects effectively operate as separate chains, which brings many risks (censorship resistance, availability). Building a unified single front-end interface across the vast majority of chains would be very challenging. One solution is to introduce intent-centric design, adding a layer above full-chain account abstraction, viewing the EIP-4337 ecosystem of Ethereum or the native account abstraction facilities of other chains (such as zkSync) as specific instances under the Solver/Reactor type, while how to choose the appropriate Solver is a higher-level task. Taking Particle Network as an example, it proposes a simple abstracted Intent-Centric implementation scheme, where different account abstraction projects are merely instances included in the Solver category of the Intent scheme. First, the user front end will be responsible for transforming natural language requests or any user interactions into specific programmatic descriptions, which include input constraints and output constraints (essentially defining the input conditions and output result ranges that meet user requirements). Subsequently, one or more Solvers in the Solver network will forward the Transactions containing specific input and output constraints to the Solver contracts deployed on the chain (Solvers not only include node facilities but also have on-chain contract components). The Solver contract will transmit the Intent instructions to the Reactor contract (which manages user accounts on-chain), allowing the latter to call other modules to complete the final interaction. The user's request is first known to the Solver network, so users do not need to be overly aware of the underlying chains or the structures of different account abstraction schemes; this part is left to the Solver to construct specific solutions. Of course, these ideas are currently just a theoretical framework, and the subsequent implementation details await further elaboration from Particle Network. What is currently clear is that a competitive Solver market will inevitably emerge in the future, where users can initiate auctions for multiple Solvers to propose different solutions, and through local simulated transactions, the optimal solution can be selected and corresponding incentives provided to the Solver. As for the form of incentives, it will depend on the considerations of the protocol designers of the Solver network (Particle Network intends to use PNT tokens as the incentive tokens for its Solver auction market). The current Intent effectively shields the complex details of the lower layers, abstracting a higher layer, and such a layered design with TCP/IP protocol characteristics is a necessary condition for user experience and developer experience under seamless full-chain interoperability. Embracing the Large-scale Adoption of Account Abstraction After optimizing the EIP-4337 framework within the Ethereum ecosystem from various angles, while also promoting seamless interoperability across Ethereum and non-Ethereum ecosystems, we believe that a product spanning both the supply and demand sides is still needed to support the large-scale adoption of account abstraction. This product should reduce the barriers for end users to use various Web3 products and services while focusing on service developers and lowering the developer threshold. One of the best products playing this role is Particle Network's modular account abstraction wallet as a service (Modular Smart Wallet-as-a-Service) product: 
- This service provides a set of easy-to-use APIs, enabling developers to easily integrate modular account abstraction functionalities into their applications;
- Developers can use this service to create and manage full-chain accounts, conduct cross-chain interactions, and utilize a unified fee payment method;
- Such a service 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 important characteristic is that Particle Network's modular account abstraction wallet as a service (Modular Smart Wallet-as-a-Service) product builds an open ecosystem in the account abstraction field based on signature computation, integrating various types of account abstraction products and services in addition to providing self-developed account abstraction product modules, which can rapidly advance the adoption of products and services from various developers in the entire account abstraction field. 
* (Modular Design of Particle Network's Smart Wallet-as-a-Service)* Letting technology serve demand, after addressing the various limitations of the ERC-4337 framework, the enhancement of developer experience will encourage the emergence of more products with excellent user experiences, accelerating the transformation of the Web3 industry from a crypto-punk-friendly financial sector to a consumer-friendly mainstream industry.
