Why is it said that the abstraction of the entire chain account is the final piece of the puzzle for EIP-4337?

Why is the abstraction of the entire chain account considered the crucial missing element in EIP-4337?

Author: Peter LianGuain, Co-founder and CTO of LianGuairticle Network &Faust, Geek Web3

Since 2022, account abstraction has been a widely discussed topic, and the framework of the account abstraction field centered around EIP-4337 seems to have become an industry consensus. The popularity of the intent concept has prompted people to pay more attention to such low-threshold user interaction components.

However, EIP-4337 still faces pain points such as Smart Account fragmentation and a highly fragmented user experience across different chains. This article takes projects like Biconomy, Safe Core, and LianGuairticle Network as examples to explore how to further promote the development of the account abstraction field under the EIP-4337 framework.

Understanding the concept of “account abstraction” from the perspective of transaction flow abstraction

Vitalik has repeatedly pointed out that account abstraction is a necessary condition for lowering the threshold for Ethereum users and achieving mass adoption. Its core vision is to allow users to customize signature verification methods and enjoy gas payments, enabling transactions on the chain without any assets (commonly known as gasless transactions). Only by achieving these prerequisites can the conversion rate of new users to Web3 applications be improved.

• DTCC pours cold water on the hot speculation, Bitcoin spot ETF still subject to SEC’s decision.
• Bitcoin is rising like a rocket, why is Ethereum moving like a tractor?
• Aave’s Innovations and Challenges From Aave V3’s High Growth to GHO’s Liquidity Strategy

Previous non-account abstraction proposals or smart contract wallets, although capable of providing similar experiences, are not flexible and efficient enough, for example, Gnosis Safe still requires an EOA address to trigger transactions, and the gas cost is extremely high.

The intention of account abstraction is to optimize from the underlying structure of smart contract accounts and pave the way for the next-generation intelligent account system.

However, 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 like EIP-86, EIP-4337, and EIP-6900 focus on abstracting/modularizing the entire set of processing flows of a transaction, from initiation to node reception, signature verification, and gas payment, rather than truly abstracting the account structure. Therefore, it seems more appropriate to call these various proposals “transaction abstraction”.

If we understand those well-known account abstraction proposals from the perspective of “transaction processing flow abstraction”, we can easily grasp the main points: this kind of transaction abstraction is actually trying to bring the user experience of Web2-level users entering and using products into the Ethereum system, such as blacklists/whitelists, no identity verification required for transaction initiation within a certain period, gasless transactions, fiat currency payment for transaction fees, etc.

But someone may ask: couldn’t these things be achieved with previous smart contract wallets? What is the value of account abstraction schemes like EIP-4337?

The essence of EIP-4337: Account abstraction as a localized optimal solution for Ethereum ecosystem

As mentioned above, although past smart wallets could achieve the functions mentioned, the implementation method was generally crude, and often relied on highly centralized third-party facilities. For example, the past Gas sponsorship scheme required the introduction of a third-party Relayer node (EIP-2771). Moreover, there was a lack of unified standards between different smart wallets, which hindered the development and deployment of compatible components.

Various account abstraction-related EIPs aim to solve these defects present in different wallet projects by using a standardized framework specifically designed for smart contract wallets. This will transform the account structure within the Ethereum ecosystem from a basic functional structure to a higher-level intelligent structure.

This is similar to the situation before ERC-20 or ERC-721 emerged. Many tokens had inconsistent implementation methods, features, and provided functions/interfaces. Inconsistencies hindered the development of compatible third-party facilities and code audits (it’s hard to imagine the current level of DeFi prosperity without the ERC-20 protocol).

Standardized protocol/feature implementation standards are a prerequisite for modularized narratives, and modular development is almost a prerequisite for vigorous development in any field (division of labor is the first principle of efficiency improvement).

In the end, EIP-4337 stands out.

EIP-4337 is a local optimal solution, but there are several aspects within its framework that need urgent optimization

EIP-4337 defines a set of interface standards, specifying which modules a smart wallet following the 4337 protocol should have, and which functions/interfaces each module should implement, such as Bundler, EntryPoint, and LianGuaiymaster, and the callable functions they should provide to the outside world.

After clarifying these guidelines, the interaction between different components becomes clearer, making it easier to incorporate modular design concepts into account abstraction and smart wallet design, greatly benefiting wallet module developers.

Of course, from a user’s perspective, the value brought by the modularized smart wallet development paradigm is not immediately apparent because people cannot feel the significant changes in abstract account wallets in the short term. However, in the medium to long term, the value of protocols like EIP-4337 is similar to ERC-20 and ERC-721. It lays the foundation for the long-term development of abstract account wallets and is a milestone with epoch-making significance.

However, EIP-4337 still has many unresolved issues: For example:

1. The functionality of account abstraction is not sufficiently pluginized, making it easy for different developers to reinvent the wheel;

2. Account module compatibility is poor, and the entire account system tends to be fragmented in an ecological sense;

3. The account abstraction ecosystem between different chains is highly fragmented, making it difficult to provide a unified and high-quality experience for end users and developers to achieve a better UX.

In the following sections, we will discuss solutions to these problems.

Optimization Direction 1: Account abstraction function modularization 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 modularity of account abstraction wallets and divide the granularity of each module more finely.

For example, Biconomy based on EIP-4337 (which will introduce finer-grained EIP-6900 in the future) proposes the narrative of account abstraction function modularization to further promote the modular development of the account abstraction ecosystem.

The so-called account abstraction function modularization actually refers to a protocol that clearly indicates which key modules related to smart contract wallets are involved, what interfaces/functions these modules should implement, and what the names and invocation methods of these interfaces are. Then, third-party developers can develop components with different details according to their own ideas, but these components will comply with the requirements outlined in the protocol.

Biconomy’s V2 version adopts EIP-4337 as the protocol framework and establishes more detailed standards, adding a batch of interfaces not mentioned in 4337. While specifying the functionalities that Bundler, Smart Contract Wallet, and LianGuaiymaster should have, Biconomy allows third-party developers to implement modules with the same characteristics but different versions, as long as they follow the protocol rules declared by Biconomy (compatible with EIP-4337).

At the same time, Biconomy has also proposed the slogan of “Module Store,” and while launching the Account Abstraction Module SDK in practice, it encourages developers to submit their own designed account abstraction modules, initiating “Module as a service,” so that all wallet projects complying with the EIP-4337 protocol can directly adopt these account abstraction modules written by outsiders. When users create smart accounts through the frontend, they have more diversified choices for which modules to adopt.

Modularization facilitates division of labor, while also allowing users to quickly switch or add/remove certain functionalities in their smart wallets (in simpler terms, it breaks down the granularity into finer parts).

Biconomy points out that the higher the level of modularity in smart contract wallets, the fewer changes need to be made during updates or upgrades (there’s no need to update the existing Smart Contract Wallet contracts or use DelegateCall, only some external modules need to be updated), making it easy for different users or developers to replace certain components.

In Biconomy’s future version of the account abstraction scheme, they will also refer to the EIP-6900 proposal, which is more conducive to modularity than EIP-4337.

Optimization Direction 2: Finer granularity of module division to solve the issue of fragmented accounts

Regarding the EIP-6900 proposal, Safe (formerly Gnosis Safe) actually released a whitepaper called the Safe Core Protocol in August of this year, which draws the most inspiration from EIP-6900.

EIP-6900 points out that one problem with modular account abstractions is the fragmentation or isolation of accounts. For example, although different account abstraction module suppliers or different DAPP applications are compatible with EIP-4337, EIP-4337 does not abstract different modules to a high enough degree; the division granularity is relatively coarse, leaving “excessive” freedom to smart account module developers (smart accounts store user information and record the most vital parts of custom transaction verification and gas payment logic).

Because of this, different wallet projects tend to design smart account modules with unique attributes.As a result, other account abstraction module suppliers must prioritize compatibility with the supplier of the Smart Account module, which gradually leads to a fixed upstream and downstream supply chain, inevitably causing fragmentation and disconnection in the account abstraction module ecosystem. (This is similar to how early computer operating system developers had to consider compatibility with hardware devices from different computer manufacturers.)

To solve the problem of ecosystem fragmentation and improve the compatibility of account abstraction modules developed by different suppliers, the best approach is to further abstract smart contract wallet accounts and make the module division granularity finer.

After adopting the ideas from EIP-6900, the Safe Core Protocol whitepaper provides more detailed optimizations for Smart Accounts (users’ smart wallet accounts). The Safe Core Protocol splits each callable module of the smart wallet account into various categories such as Plugins, Hooks, Signature Validators, and Function Processors.

The smart account module is kept as lightweight as possible, with the account contract only storing basic data and functions, and any functions that can be moved outside are all given to “Function Processors” or “Plugins” as specialized 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 cumbersome 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’s app store, which contains all approved 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, the UserOperation will trigger a certain plugin first, and then the Manager contract will check if the plugin’s status is normal (recorded in the registry). If it is normal, the plugin’s request will be allowed. If necessary, the plugin may or may not call certain functionalities provided by the Hooks. Then, the state of the smart account involved in the UserOperation will be updated.

Through the fine-grained module segmentation method and scheduling process mentioned above, the Safe Core protocol attempts to promote an open-source account abstraction module interoperability protocol, whose core idea is to lightweight the Smart Account and make it as simple as possible, similar to an EOA account, in order to improve compatibility of Smart Account modules developed by different manufacturers.

Optimization Direction 3: Full Chain Account Abstraction, achieving unified account across different chains

However, even with the aforementioned solutions, there is still a major problem that has not been solved: different chains and different Layer2 are advancing account abstraction implementation solutions with varying details, and many have adopted forms that conflict with EIP-4337, such as zkSync Era, Starknet, Flow, etc. This creates a fragmentation in wallet UX for users, for example, the smart wallet address on Starknet cannot be unified with the smart wallet address on Arbitrum.

In a multi-chain environment, users have independently deployed Smart Accounts on different chains, and the corresponding user data, such as keys, is often scattered among these contracts. If user data such as keys needs to be updated, transactions need to be repeated on multiple chains, making it difficult to ensure the consistency of the Smart Account.

Vitalik himself had previously proposed a unified and easy-to-manage smart account solution across chains, which uses Ethereum or a highly secure ZKRollup as the source chain, deploys the Keystore contract, and stores the user’s global keys, and then all smart contract accounts on L2 share the global keys stored in the Keystore contract.

But this solution is extremely expensive, whenever the global key recorded in the Keystore contract on the source chain changes, every account on L2/target chain needs to synchronize the new key through cross-chain interactions. The cross-chain interaction cost between Ethereum and L2 is too high, and users simply cannot afford it. Furthermore, it is worth noting that smart contract accounts are different from externally owned accounts (EOA accounts). The latter, due to its unique address generation method, is inherently unified across multiple chains (EVM chains), but smart contract accounts are completely different, making it difficult for users to obtain smart contract accounts with the same address on different chains.

In response to this, LianGuairticle Network has proposed its own method. Although the overall idea is consistent with Vitalik’s idea, which is to separate the storage and code of smart accounts, LianGuairticle Network plans to use an independent chain called LianGuairticle Network Chain as the full-chain storage database for smart accounts. They will synchronize the changes made by a user to the account storage to the local Account on other chains through third-party cross-chain messaging solutions (LayerZero, CCIP, Axelar, Connext, etc.).

(LianGuairticle Network's multi-chain account abstraction structure)

Specifically, LianGuairticle Network’s full-chain account abstraction system aims to provide users with a unified smart contract account address on different EVM chains. This requires deploying a set of Deployer Contracts on different chains.

Users must trigger the generation of new accounts on the LianGuairticle Network Chain, and then the LianGuairticle Chain will trigger all the Deployer Contracts on each chain to ensure that the smart contract account addresses generated for users on different chains are unified. Alternatively, users can complete the multi-chain interaction process through contracts on the LianGuairticle chain without being aware of other chains, and they can use Unified Gas Token as a unified fee payment method.

Full-chain account abstraction also makes cross-chain user operations possible, where user operations and payments on the source chain trigger transactions on the target chain. For example, it is possible to use Polygon’s USDC to purchase an NFT on Base.

However, LianGuairticle Network’s solution requires a high level of coordination between Deployer Contracts and cross-chain messaging components to achieve synchronization between multi-chain accounts and the source chain’s storage. This actually poses high requirements on the oracle or cross-chain messaging bridge used (this seems to be a problem that exists in all solutions related to full-chain interoperability).

However, users can flexibly configure the synchronization of their cross-chain accounts using combinations of different message bridges, instead of relying on just one bridge. For example, it can be configured with a 2/3 strategy, where confirmation of the storage change on the target chain depends on the confirmation from any two of LayerZero, Axelar, and Connext, thereby approximately solving the issue of single-point dependency.

Seamless interoperability across EVM and non-EVM chains takes the full-chain account abstraction within the Ethereum ecosystem to the next level.

Despite the key management and unified accounts that span EVM chains, there is still room for optimization in the full-chain account abstraction. Chains that are not compatible 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. Similarly, non-EVM chains will have difficulty adopting the concept of full-chain account abstraction proposed by Vitalik and LianGuairticle Network in the previous article, unless they implement an equivalent solution for the EIP-4337 protocol.

In addition, there is also room for improvement in wallet projects that are compatible with EIP-4337. Most smart wallets use bundler nodes that are independently operated by the official entities, without interconnectivity. Many smart wallet projects operate as standalone chains, which introduces various risks in terms of censorship resistance and availability. Building a unified front-end interface that spans most chains is a challenging endeavor. One solution is to introduce intent-centric design, adding a layer on top of the full-chain account abstraction, where Ethereum’s EIP-4337 ecosystem and the native account abstraction facilities of other chains (such as zkSync) are considered as specific instances under the Solver/Reactor type, and the task is to choose the appropriate Solver at a higher level.

Using LianGuairticle Network as an example, it proposes a concise abstract implementation of Intent-Centric, where different account abstraction projects are merely included in the Solver category as specific instances within the Intent solution.

Firstly, the user interface will be responsible for converting natural language requests or any user interactions into specific programmatic descriptions, including input constraints and output constraints. These constraints define the acceptable input conditions and output result ranges to satisfy user requirements. Subsequently, one or more Solvers in the Solver network will forward Transactions containing the precise input/output constraints to Solver contracts deployed on the chain (Solver encompasses both node facilities and on-chain contract components). The Solver contract will transmit the Intent instructions to the Reactor contract (which manages user accounts on-chain), and delegate the latter to invoke other modules to complete the final interaction.

User requests are first known by the Solver network, so users do not need to have a detailed understanding of the underlying chains or the construction of different account abstraction schemes. This part is left for the Solver to construct specific solutions.

Of course, these concepts are currently just a theoretical framework, and the implementation details are yet to be laid out by the official LianGuairticle Network.

What is clear is that there will definitely be a competitive Solver market in the future, where users can initiate auctions for multiple Solvers to produce different solutions. By simulating local transactions, the optimal solution can be selected and the corresponding Solver rewarded. The form of the incentive depends on the considerations of the protocol designers of the Solver network (LianGuairticle Network plans to use PNT tokens as incentive tokens for its Solver auction market).

The current essence of Intent is to shield the underlying complex details and abstract a higher layer. Such a layered design with TCP/IP protocol nature is a necessary condition for seamless interoperability and user experience for the entire chain.

Embracing the widespread adoption of account abstraction

After optimizing the 4337 framework within the Ethereum ecosystem from various angles and promoting seamless interoperability between Ethereum and non-Ethereum ecosystems, in order to support the widespread adoption of account abstraction, we believe that a product spanning the supply and demand sides is still needed. It can reduce the threshold for end users to use various Web3 product services while focusing on service developers and lowering the developer barrier.

One of the best products playing this role is the modular account abstraction wallet-as-a-service (Modular Smart Wallet-as-a-Service) product of the LianGuairticle Network:

• The 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 the modular account abstraction wallet-as-a-service (Modular Smart Wallet-as-a-Service) product of the LianGuairticle Network has built an open ecosystem based on signature computation in the account abstraction field for developers. In addition to providing self-developed account abstraction product modules, it integrates various types of account abstraction products and services, which can quickly promote the adoption of products and services from developers in the entire account abstraction field.

Let technology serve the needs. After addressing the limitations of the ERC-4337 framework from various angles, the improvement of developer experience will promote the emergence of more products with excellent user experience, accelerating the transformation of the Web3 industry from a crypto-friendly finance industry to a consumer-friendly industry.

We will continue to update Blocking; if you have any questions or suggestions, please contact us!