Author: Peter Pan, Co-founder and CTO of Particle Network & _Faust, Geek Web3
Since 2022, account abstraction has been widely discussed, and the framework of account abstraction with EIP-4337 at its core seems to have become a general consensus in the industry. The popularity of the intent concept has prompted people to pay more attention to such low-threshold user interaction components.
However, EIP-4337 still has pain points such as Smart Account account fragmentation and highly fragmented user experience across chains. This article takes projects such as 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.
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 to lower the threshold for Ethereum users and achieve mass adoption. Its core vision is to allow users to customize the verification method + enjoy gas payment, and initiate transactions on the chain without any assets (commonly known as gas-free transactions). Only by achieving these prerequisites can the new user conversion rate of 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, when 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 process of a transaction from initiation to node reception, verification, gas payment, etc., rather than truly focusing on the abstraction of 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", we can more easily understand their key points: this kind of transaction abstraction actually aims to bring the user experience of Web2-level users entering and using products into the Ethereum system, such as blacklists/whitelists, transactions initiated without identity verification for a period of time, gas-free transactions, fiat currency payment of fees, etc.
(Image source: Zengo)
But some may ask: Couldn't these things have been achieved with past smart contract wallets? What is the value of account abstraction solutions like EIP-4337?
The Essence of EIP-4337: Local Optimal Solution for the Implementation of Account Abstraction in the Ethereum Ecosystem
As mentioned above, although past smart wallets could achieve the functionalities mentioned earlier, the implementation methods were generally 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 was a lack of unified standards between different smart wallets, which was not conducive to the development and deployment of supporting components.
The core demand of various account abstraction-related EIPs is to solve these deficiencies existing in different wallet projects within the Ethereum ecosystem through a standardized framework specifically designed for smart contract wallets, and to transform the account structure in the Ethereum ecosystem from a basic functional structure to a higher-level intelligent structure.
(Image source: Springer Link)
This is similar to the situation before the appearance of ERC-20 or ERC-721, where the implementation methods, functionalities, and interfaces provided to the outside world for many tokens were inconsistent, and "inconsistency" is not conducive to the development of supporting third-party facilities, nor is it conducive to code auditing (it is hard to imagine how DeFi applications would have developed to their current level of prosperity without the ERC-20 protocol).
Standardized protocol/functional implementation standards are a prerequisite for modularized narratives, and modular development is almost a prerequisite for the vigorous development of every field (division of labor is the first principle to improve efficiency).
In the end, EIP-4337 emerged.
EIP-4337 is a Local Optimal Solution, but There Are Multiple Aspects Within Its Framework That Urgently Need Optimization
EIP-4337 defines a complete set of interface standards, clearly stating which modules smart wallets following the 4337 protocol should have, and which functions/interfaces each module should implement, such as Bundler, EntryPoint, Paymaster, etc.
After clarifying these requirements, the interaction between different components becomes clearer, making it easier to introduce a modular design approach into the design of account abstraction and smart wallets, greatly benefiting wallet module developers.
Of course, from the user's perspective, the value of the modular smart wallet development paradigm is not yet clear, because in the short term, people cannot feel how much the account abstraction wallet itself has changed. However, in the medium to long term, the value of protocols such as 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: such as:
- The functionality of account abstraction is not sufficiently modular, and different developers are prone to reinventing the wheel;
- Poor compatibility of account modules, leading to a fragmented state of the account ecosystem;
- Highly fragmented account abstraction ecosystem between different chains, making it difficult to provide users and developers with a unified and high-quality experience to achieve better UX.
In the following text, we will discuss the solutions to these problems.
Optimization Direction One: Modularization of Account Abstraction Functionality Will Become the Basic Configuration
It can be said that one of the core points of discussion related to account abstraction now is how to better achieve the modularization of account abstraction wallets, with finer division of each module.
For example, Biconomy is based on EIP-4337 (and will introduce the finer-grained EIP-6900 in the future), proposing the modularization of account abstraction functionality to further promote the modular development of the account abstraction ecosystem.
(Image source: Biconomy)
The so-called modularization of account abstraction functionality is actually to clearly define through a protocol which key modules are involved in smart contract wallets, which interfaces/functions these modules should implement, and what the names and calling methods of these interfaces are. Then, third-party developers will develop components with different details according to their own ideas, but these components will all comply with the requirements set out in the protocol.
Biconomy's V2 version, based on EIP-4337, has established more detailed standards, added a batch of interfaces not mentioned in 4337, and while declaring the functions that Bundler, Smart Contract Wallet, Paymaster, and other modules should have, Biconomy allows third-party developers to implement modules with different code details but with similar features and different versions, as long as they comply with the protocol rules declared by Biconomy (compatible with EIP-4337).
(Interface standards proposed by Biconomy, specifying which functions should be implemented within the module for external calls)
At the same time, Biconomy has also proposed the slogan "Module Store". While actively launching the account abstraction module SDK, it encourages developers to submit their own designed account abstraction modules, initiating "Module as a service", allowing all wallet projects that comply with the EIP-4337 protocol to directly adopt these account abstraction modules written by third parties. Users now have a more diverse selection of modules when creating smart accounts through the front-end page.
Modularization not only facilitates division of labor but also enables users to quickly switch, add, or remove certain functions in smart wallets (in other words, it makes the division of granularity finer).
Biconomy points out that the higher the level of modularization of smart contract wallets, the fewer changes are needed when updating or upgrading (there is no need to update the user's 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 certain components.
In Biconomy's future new account abstraction solution, it will also refer to the EIP-6900 proposal, which is more conducive to modularization than EIP-4337.
Optimization Direction Two: Finer-Grained Module Division to Solve the Problem of Account Fragmentation
Regarding the EIP-6900 proposal, Safe (formerly Gnosis Safe) actually released a Safe Core Protocol whitepaper in August of this year, which is most closely related to EIP-6900.
(EIP-6900 schematic)
EIP-6900 points out that one problem with modular account abstraction is the "fragmentation" of accounts, or the island problem. For example, although different account abstraction module providers or different DAPP applications are compatible with EIP-4337, the level of abstraction of EIP-4337 for different modules is not high enough, and the division granularity is relatively coarse, giving Smart Account module developers "excessive" freedom (smart account is the most core part that stores user information and records 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 the Smart Account modules provided by others, gradually leading to a fixed upstream and downstream supply chain, which will inevitably lead to the fragmentation and isolation of the account abstraction module ecosystem. (This is similar to in the early days of the computer industry, where operating system developers had to consider compatibility with devices provided by different computer hardware manufacturers)
To solve the problem of ecosystem fragmentation and improve the compatibility of account abstraction modules developed by different providers, the best way is to further abstract the smart contract wallet accounts and make the module division granularity finer.
After drawing inspiration from EIP-6900, the Safe Core Protocol whitepaper made more detailed optimizations to Smart Account (the user's smart wallet account). The Safe Core Protocol divides each callable module of a smart wallet account into various categories such as Plugin plugins, Hooks, signature validators, function processors, etc.
The smart account module is made as lightweight as possible, with the account contract only storing the most basic data and functions, and any functions that can be moved outside are all implemented by the "function processor" or "Plugin" modules. This aligns with the principle of Occam's razor—"entities should not be multiplied without necessity".
If the smart account itself is lightweight enough and does not involve too many intricate details, smart account modules developed by different manufacturers will be more similar in internal structure and have higher compatibility.
The Safe Core Protocol also introduces a registry, similar to the iPhone's 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 through the Manager contract.
In general, UserOperation will first trigger a certain Plugin plugin, and then the Manager contract will check whether the plugin's status is normal (recorded in the registry). If it is normal, the plugin's request will be approved. If necessary, the Plugin plugin will call certain functions provided by some Hooks, or not. Then, the state of the smart account involved in UserOperation will be changed.
Through the above-mentioned finer-grained module division and scheduling process, the Safe Core Protocol attempts to promote an open-source account abstraction module interoperability protocol, with the core idea of lightweighting Smart Account to make it as simple as possible, similar to an EOA account, to improve the compatibility of Smart Account modules developed by different manufacturers.
Optimization Direction Three: Cross-Chain Account Abstraction, Achieving Unified Accounts on Different Chains
However, even with the aforementioned solutions, there is still a major problem that has not been solved: different chains and different Layer2s are all advancing account abstraction implementation solutions with different details, and many of them conflict with EIP-4337, such as zkSync Era, Starknet, Flow, etc. This has led to fragmented wallet UX, where a user's smart wallet address on Starknet cannot be unified with their 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 scattered and stored in these contracts. If user data such as keys needs to be updated, transactions need to 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, which uses Ethereum or a highly secure ZKRollup as the source chain, deploys a Keystore contract, and stores the user's global key, then all smart contract wallet 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 every time the global key recorded in the Keystore contract on the source chain changes, each account on L2/the target chain needs to synchronize the new key through cross-chain interaction. The cost of cross-chain interaction between Ethereum and L2 is too high for users to bear. It is also important to note that smart contract accounts are different from EOA accounts; the latter, due to their unique address generation method, are naturally unified across multiple chains (EVM chains), but smart contract accounts are completely different, making it difficult for users to obtain the same smart contract account address on different chains.
Particle Network has proposed its own method in response to this. While the general idea is consistent with Vitalik's concept of 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, and synchronize a user's changes to the account Storage 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 provide users with a unified smart contract account address on different EVM chains, which 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 the Particle Chain will trigger all Deployer Contracts on different chains to ensure that the smart contract account addresses generated for users on different chains are consistent. Alternatively, users can interact across multiple chains through contracts on the Particle chain without being aware of other chains, and can use the Unified Gas Token as a unified fee payment method.
Full-chain account abstraction also enables Cross-Chain User Operations, allowing the triggering of transactions on the target chain through User Operations and payment of corresponding Gas on the source chain, such as using Polygon's USDC to purchase NFTs on Base.
However, Particle Network's solution requires high coordination between Deployer Contracts and cross-chain messaging components to achieve synchronization of multi-chain Accounts and source chain Storage. This places high demands on the oracle or cross-chain messaging bridge used by Particle Network (this issue seems to exist in all solutions related to full-chain interoperability).
However, the synchronization of cross-chain accounts for users can be flexibly configured with different combinations of Message Bridges, rather than relying on a single Bridge. For example, it can be configured as a 2/3 strategy, requiring confirmation from any two of LayerZero, Axelar, or Connext before confirming the change in Storage on the target chain, which can approximately solve the issue of single-point dependency.
Seamless interoperability across EVM and non-EVM chains is a further advancement of full-chain account abstraction within the Ethereum ecosystem.
Despite the key management and unified account across EVM chains, there is still room for optimization in full-chain account abstraction: non-EVM compatible chains, such as Aptos, Solana, Sui, cannot guarantee the generation of smart contract account addresses consistent with those on EVM chains. Additionally, non-EVM chains would find it difficult to adopt the full-chain account abstraction concept proposed by Vitalik and Particle Network if they do not implement an equivalent solution to the EIP-4337 protocol.
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 entities, and they are not interconnected. Many smart wallet projects essentially operate as separate chains, which brings many risks (censorship resistance, availability). Building a unified front-end interface across most chains would be very challenging. One solution is to introduce an intent-centric design, adding a layer on top of full-chain account abstraction, treating 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, and the selection of the appropriate Solver is a higher-level task.
Taking Particle Network as an example, it has proposed a concise abstracted Intent-Centric implementation, where different account abstraction projects are included in the Solver category within the Intent scheme.
First, the user interface will be responsible for transforming natural language requests or any user interactions into specific programmatic descriptions, including input constraints and output constraints (in other words, conditions for acceptable input and output results). Subsequently, a certain Solver or Solvers in the Solver network will forward the Transaction containing specific input and output constraints to the Solver contract deployed on the chain (Solvers not only have node facilities but also have on-chain contract components). The Solver contract will then send the Intent command to the Reactor contract (which manages the user's on-chain accounts), and the Reactor will call other modules to complete the final interaction.
The user's request is first known by the Solver network, so users do not need to be overly aware of the underlying chains or the construction of different account abstraction schemes; this part is handled by the Solver to construct specific solutions.
Of course, these ideas are currently only a theoretical framework, and the implementation details are still pending the official elaboration from Particle Network.
It is clear that in the future, there will definitely be a competitive Solver market, where users can initiate auctions for multiple Solvers to propose different solutions. Through local simulated trading, the best solution can be selected and the corresponding Solver can be incentivized. The form of incentives will depend on the considerations of the protocol designers of the Solver network (Particle Network intends to use the PNT token as the incentive token for its Solver auction market).
The essence of the current Intent is to shield the underlying complex details and abstract a higher layer, such a layered design with TCP/IP protocol characteristics is a necessary condition for the user experience and developer experience under seamless interoperability across the entire chain.
Embracing the widespread adoption of account abstraction
After optimizing the ERC-4337 framework from various angles and promoting seamless interoperability across Ethereum and non-Ethereum ecosystems, in order to support the widespread adoption of account abstraction, we believe that a product that spans the supply and demand sides is still needed. It 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 to play this role is Particle Network's Modular Smart Wallet-as-a-Service product:
(Particle Network’s Smart Wallet-as-a-Service Architecture)
This service provides an easy-to-use API that allows developers to easily integrate modular account abstraction functionality into their applications;
Developers can use this service to create and manage full-chain accounts, perform cross-chain interactions, and use 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 developer-friendly features mentioned above, the most important feature is that Particle Network's Modular Smart Wallet-as-a-Service product has built an open ecosystem for account abstraction aimed at developers, integrating various types of account abstraction products and services. This can quickly advance the adoption of products and services from various developers in the account abstraction field.
(Modular Design of Particle Network’s Smart Wallet-as-a-Service)
By letting technology serve the needs, after addressing the limitations of the ERC-4337 framework from various angles, the improvement in developer experience will lead to the emergence of more products with excellent user experience, accelerating the transformation of the Web3 industry from a crypto-friendly financial industry to a consumer-friendly industry.
免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。
