How to solve problems such as the fragmentation of the Smart Account ecosystem and the highly fragmented UX of full-chain account abstraction?
Written by: Peter Pan, Co-founder and CTO of Particle Network & Faust, Geek Web3
Account abstraction has been a widely discussed topic since 2022, and the framework in the field of account abstraction with EIP-4337 as the core seems to have become a general consensus in the industry. The popularity of the concept of intention has prompted people to pay more attention to such low-threshold user interaction components.
However, EIP-4337 still has the pain points of fragmented Smart Account accounts and highly fragmented user experience of cross-chain account abstraction. This article takes projects such as Biconomy, Safe Core and Particle Network as examples to discuss how to further promote the development of the account abstraction field under the EIP-4337 framework.
Understand the concept of "account abstraction" from the perspective of transaction process abstraction
Regarding account abstraction, Vitalik has pointed out many times that it is a necessary condition for lowering the user threshold of Ethereum and achieving mass adoption. Its core vision is to allow users to customize the signature verification method + enjoy gas payment, and can be on the chain without any assets. Initiate a transaction (commonly known as a gas-free transaction). Only by realizing these prerequisites can the new user conversion rate of Web3 applications be improved.
Although previous non-account abstract proposals or smart contract wallets can achieve a similar experience, they are far from flexible and efficient enough . For example, Gnosis Safe still requires an EOA address to trigger transactions, and the Gas cost is extremely high.
The account abstraction is intended to be optimized from the bottom layer of the smart contract account structure to pave 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 node reception, signature verification, gas payment, etc., but do not really focus on An abstraction of the account structure. Therefore, it seems more appropriate to call the various current proposals "transaction abstractions."
If we understand those well-known account abstraction proposals from the perspective of "abstraction of transaction processing processes", we can more easily understand the main point: this kind of transaction abstraction is actually to allow Web2-level users to enter and use the product experience. Brought into the Ethereum system, such as blacklist/whitelist, no identity verification required for initiating transactions within a period of time, no Gas transactions, legal currency payment fees, etc.
(Image source: Zengo)
But some people may ask: Couldn’t these things have been implemented in smart contract wallets in the past? EIP-4337 What is the value of this type of account abstraction solution?
The essence of EIP-4337: the local optimal solution of account abstraction in the Ethereum ecosystem
As mentioned in the above question, although smart wallets in the past can achieve the functions mentioned above, the implementation methods are generally rough and often rely on highly centralized third-party facilities. For example, the past Gas payment solution 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 layout of supporting components.
The core appeal of EIPs related to various account abstractions is to solve these shortcomings in different wallet projects through a standardized framework designed for smart contract wallets, and promote the account structure in the Ethereum ecosystem from a basic functional structure Transform into a smart structure with a higher ceiling.
(Image source: Springer Link)
This is just like, before the emergence of ERC-20 or ERC-721, the implementation methods, functions, and externally provided functions/interfaces of many Tokens were inconsistent, and "inconsistency" was not conducive to the development of supporting third-party facilities, and it was not conducive to the development of supporting third-party facilities. Conducive to code auditing (it is difficult to imagine how Defi applications could develop to the current level of prosperity without the ERC-20 protocol).
Standardized protocols/function implementation standards are a prerequisite for modular narrative, and modular development methods are a prerequisite for almost every field to thrive (division of labor is the first principle to improve efficiency).
Ultimately, EIP-4337 stood out.
EIP-4337 is a local optimal solution, but there are many angles within its framework that need to be optimized.
EIP-4337 defines a complete set of interface standards, clarifying what modules a smart wallet that follows the 4337 protocol must have at least, and what functions/interfaces each module should implement, such as what callable components such as Bundler, EntryPoint, and Paymaster should provide to the outside world. function.
After clarifying these rules and regulations, the interactive relationship between different components will be clearer, making it easier to introduce modular design ideas into the design of account abstraction and smart wallets, and developers of wallet modules will also benefit greatly.
Of course, purely from a user perspective, the value brought by the modular smart wallet development paradigm is still unclear, because people will not feel much change in the account abstract wallet itself in the short term. But in the medium to long term, the value of protocols such as EIP-4337 is similar to ERC-20 and ERC-721. It lays the foundation for the long-term development of account abstract wallets and is an epoch-making milestone.
But EIP-4337 still has many unresolved problems: such as:
1. The account abstraction function is not plug-in enough, and it is easy for different developers to reinvent the wheel;
2. The account module has poor compatibility, and the entire account system tends to be fragmented;
3. The account abstraction ecology between different chains is highly fragmented, making it difficult to provide end users and developers with a unified and high-quality experience to achieve a better UX.
Below, we will explore solutions to these problems.
Optimization direction one: Account abstraction function plug-in will become the basic configuration
It can be said that one of the core discussion points related to account abstraction is how to better implement the modularization of account abstraction wallets and cut the granularity of each module into finer parts.
For example, Biconomy proposed a plug-in narrative for account abstraction functions based on EIP-4337 (the finer-grained EIP-6900 will be introduced in the future) to further promote the modular development of the account abstraction ecosystem.
(Image source: Biconomy)
The so-called plug-in of account abstraction function is actually to use a set of protocols to clarify to the outside world what key modules are involved in the smart contract wallet, what interfaces/functions these modules should implement, and what are the names and calling methods of these interfaces. Third-party developers will then develop components with varying details according to their own ideas, but these components will all comply with the requirements set forth in the agreement.
Biconomy's V2 version uses EIP-4337 as the protocol skeleton, formulates more detailed standards, and adds a number of interfaces not mentioned in 4337. While declaring what functions these modules such as Bundler, Smart Contract Wallet, and Paymaster should have, Biconomy allows third-party developers to use different code details to implement modules with the same characteristics and different versions , as long as they follow Biconomy's pre-declared agreement details ( Compatible with EIP-4337).
(The interface standard proposed by Biconomy specifies which functions third-party module developers should implement within the module for external calls)
At the same time, Biconomy also proposed the slogan "Module Store". While actively launching the account abstraction module SDK, it also encourages developers to submit their own designed account abstraction modules and launch "Module as a service" so that all developers who comply with the EIP-4337 protocol can All wallet projects can directly use these account abstraction modules written by outsiders. When users create smart accounts through the front-end page, they also have more diverse choices about which modules to use.
Modularity not only facilitates the division of labor, but also facilitates users to quickly switch or add or delete certain functions in the smart wallet (to put it bluntly, it means dividing the granularity into finer parts).
Biconomy pointed out that the higher the modularity of the smart contract wallet, the fewer changes required when updating or upgrading it (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). It is convenient for different users or developers to replace certain components.
In Biconomy's future new version of the account abstraction scheme, the EIP-6900 proposal, which is more modular than EIP-4337, will also be referred to.
Optimization direction two: more fine-grained module segmentation to solve the problem of account fragmentation
Regarding the EIP-6900 proposal , Safe (formerly Gnosis Safe) actually launched a related Safe Core Protocol white paper in August this year, and the most referenced one is EIP-6900.
(EIP-6900 schematic)
EIP-6900 pointed out that one of the current problems with modular account abstraction is the "fragmentation" of accounts, or the island problem. For example, although different account abstraction module suppliers or different DAPP applications will be compatible with EIP-4337, EIP-4337 does not abstract the different modules high enough, and the granularity of division is relatively rough, leaving Smart Account module developers with " Too high degree of freedom ( smart account is the core part of storing user information, recording customized transaction verification, and gas payment logic ).
As a result, different wallet projects tend to design smart account modules with unique properties. If things go on like this, other account abstraction module suppliers must give priority to being compatible with the Smart Account module provided by others, and gradually a fixed upstream and downstream supply chain will be formed, which will inevitably lead to the fragmentation and separation of the account abstraction module ecology. (This is just like in the early days of the computer industry, operating system developers had to first consider which computer hardware manufacturers provided compatible equipment)
To solve the problem of ecological fragmentation and improve the compatibility of account abstraction modules developed by different suppliers, the best way is to further abstract the smart contract wallet account and make the module segmentation granularity more fine.
After drawing on the ideas of EIP-6900, the Safe Core protocol white paper makes more detailed optimizations for Smart Account (user's smart wallet account). The Safe Core protocol splits the modules that can be called by each smart wallet account into various categories such as Plugins, Hooks, signature verifiers, and function processors.
The smart account module is as lightweight as possible. The account contract only stores the most basic data and functions. All functions that can be moved outside are implemented by subdivided modules such as "function processor" or "Plugin". This is in line with the so-called Occam's razor principle - "Don't add entities unless necessary."
If the smart account itself is lightweight enough and does not involve too complicated details, smart accounts developed by different manufacturers will be closer in internal structure and have 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 contract.
Under normal circumstances, UserOperation will first trigger a plug-in, and then the Manger contract will check whether the status of the plug-in is normal (there is a record in the registry). If it is normal, the plug-in's request will be released. If necessary, the Plugin plug-in will call some functions provided by Hook, or not. Later, the status of the smart account involved in UserOperation will be changed.
Through the above-mentioned fine-grained module segmentation method and scheduling process, 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 facilitate improvement. Improved compatibility of Smart Account modules from different manufacturers.
Optimization direction three: full-chain account abstraction to achieve unified accounts on different chains
But even with the aforementioned solutions, there is still a big problem that has not been solved: different chains and different Layer2 are promoting account abstraction implementation solutions with different details, and many of them adopt forms that conflict with EIP-4337, such as zkSync Era, Starknet, Flow, etc. This has brought about a fragmentation in the wallet UX for users. For example, the user's smart wallet address on Starknet and the smart wallet address on Arbitrum cannot be unified at all.
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 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 himself has previously proposed a unified and easy-to-manage smart account solution for the entire chain. This solution uses Ethereum or a highly secure ZKRollup as the source chain, deploys the Keystore contract, stores the user's global key, and then the user 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, that is, every time the global key recorded by the Keystore contract on the source chain changes, each account on the L2/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, and users simply cannot afford it. It should also be noted that smart contract accounts are different from EOA accounts. The latter is inherently multi-chain unified (unified between EVM chains) due to its unique address generation method, but 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 this regard, Particle Network has proposed an approach of its own. Although the general idea is consistent with Vitalik's idea, which is to separate the storage and code of smart accounts, Particle Network plans to use an independent chain - Particle Network Chain as the full-chain storage database of smart accounts, through a third-party cross-chain messaging solution (LayerZero, CCIP, Axelar, Connext, etc.) Synchronize a user's changes to the account storage to the local account on other chains.
(Particle Network’s multi-chain account abstract structure)
Specifically, Particle Network's full-chain account abstraction system allows users to have a unified smart contract account address on different EVM chains, which requires deploying a set of Deployer Contracts on different chains;
The user must trigger the generation of a new account on the Particle Network Chain, and then the Particle Chain will trigger the Deployer Contract on all chains to ensure that the smart contract account addresses generated for users on different chains are unified, or the user can trigger the generation of new accounts on other chains. In the case of perception, the multi-chain interaction process is completed through the contract on the Particle chain, and Unified Gas Token can be used as a unified fee payment method.
The full-chain account abstraction also makes Cross-Chain's User Operation possible. Through the User Operation of the source chain and the corresponding Gas for payment, the Transaction of the target chain can be triggered. For example, Polygon's USDC can be used to purchase NFTs on Base.
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 (this issue It 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, instead of just relying on a certain Bridge. For example, it can be configured as a 2/3 strategy, relying on the confirmation of any two of LayerZero, Axelar, and Connext to be on the target chain. Confirming the change of Storage can approximately solve this single point dependency problem.
Seamless full-chain interoperability across EVM and non-EVM is a further step towards full-chain account abstraction within the Ethereum ecosystem.
Although there is key management and unified accounts across the EVM chain, there is still room for optimization in the full-chain account abstraction: chains that are not compatible with EVM, such as Aptos, Solana, Sui, etc., cannot guarantee that the user-generated smart contract account address is consistent with EVM Consistency on the chain; at the same time, if the non-EVM chain does not implement the EIP-4337 protocol with an equivalent solution, it will be difficult to follow the concept of full-chain account abstraction proposed by Vitalik and Particle Network in the previous article.
In addition, there is room for improvement in the EIP-4337 compatible wallet project itself. The Bundler nodes used by most smart wallets are officially run independently and do not even communicate with each other. Many smart wallet projects actually form their own chain, which will bring many risks (censorship resistance, availability). Building a single front-end interface that is unified across most chains will be very difficult. One solution is to introduce an intent-centered design, add a layer above the full-chain account abstraction , and treat Ethereum's EIP-4337 ecosystem or other chain's native account abstraction facilities (such as zkSync) as Solver/ Specific instances under the Reactor type, and how to choose the appropriate Solver is a higher-level task.
Taking Particle Network as an example, it proposes a set of concise abstract Intent-Centric implementation solutions, and different account abstraction projects are just a type of instance included in the Solver category in the Intent solution.
First of all, the user front-end will be responsible for converting natural language requests or arbitrary user interactions into specific programmatic descriptions, which include input constraints and output constraints (to put it bluntly, the input conditions and output result ranges that meet user requirements) , then one or some Solvers in the Solver network will forward the Transaction containing specific input and output constraints to the Solver contract deployed on the chain (Solver not only has node facilities, but also has on-chain contract parts). The Solver contract will send the Intent instruction to the Reactor contract (which manages the user's account on the chain), and the latter will call other modules to complete the final interaction.
The user's request is first known by the Solver network, so that the user does not need to know too much about the underlying chain or the construction of different account abstraction solutions. This part can be left to the Solver to construct a specific solution.
Of course, these ideas are currently only a theoretical framework, and the subsequent implementation details have yet to be officially laid out by Particle Network.
What is relatively clear at present is that a competitive Solver market will definitely emerge in the future, and users can initiate auctions and let multiple Solvers come up with different solutions. The best solution can be selected through local simulated transactions. And provide incentives to the corresponding Solver. As for the form of incentives, it depends on the considerations of the protocol designers of the Solver network (Particle Network plans to use PNT tokens as the incentive tokens for its Solver auction market).
The current Intent essentially shields the complex details of the lower layer and abstracts a higher layer. Such a layered design with the nature of the TCP/IP protocol is essential for user experience and development under seamless interoperability across the entire chain. experience is a necessary condition.
Bracing for mass adoption of account abstraction
After we optimized the 4337 framework in the Ethereum ecosystem from all angles, we also promoted seamless interoperability across the entire Ethereum and non-Ethereum ecosystem. In order to support the large-scale adoption of account abstraction, we feel that we still need a Products that span the supply side and the demand side. While reducing the need for end users to use various Web3 products and services, it can also focus on serving developers and lower the threshold for developers.
One of the best products to fill this role is Particle Network’s Modular Smart Wallet-as-as- Service product:
(Particle Network's Smart Wallet-as-a-Service Architecture)
- The service provides an easy-to-use API that enables developers to easily integrate modular account abstraction capabilities into their applications;
- Developers can use this service to create and manage full-chain 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 important feature is Particle Network's Modular Smart Wallet-as-as- Service product, which builds a developer-oriented account abstraction field based on signature calculations. Its open ecosystem, in addition to providing self-developed account abstraction product modules, integrates various types of account abstraction products and services, which can quickly promote the adoption of products and services by developers in the entire account abstraction field.
(Modular Design of Particle Network's Smart Wallet-as-a-Service)
Let technology serve needs. After solving the limitations of the ERC-4337 framework from all angles, the improvement of developer experience will promote the production of more products with excellent user experience and accelerate the transformation of the Web3 industry from a cypherpunk-friendly financial industry to the public Friendly consumer-grade industry.
