The final piece of the puzzle for EIP-4337 Full Chain Account Abstraction

Unlocking the Last Piece Achieving Full Chain Account Abstraction with 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 based on EIP-4337 seems to have become a consensus within the industry. The popularity of the intent concept has prompted people to pay more attention to such low-barrier user interaction components.

However, EIP-4337 still faces the pain points of Smart Account account fragmentation and a highly fragmented user experience in cross-chain account abstraction. This article uses 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 process abstraction

Vitalik has repeatedly pointed out that account abstraction is a necessary condition for reducing the user barriers of Ethereum and achieving mass adoption. Its core vision is to allow users to customize their verification methods and enjoy gas fee payment, enabling them to initiate transactions on-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.

• Breaking Blocks and Fuzzing All Night: The Dramatic Life of an Ethereum Security Researcher
• Crypto Showdown: Coinbase vs. SEC – Who Will Prevail?
• Crypto speculations heat up as users decode cryptic posts on X

Previous non-account abstraction proposals or smart contract wallets, although they can achieve similar experiences, are still not flexible and efficient enough, such as Gnosis Safe, which still requires EOA addresses to trigger transactions, and the gas costs are extremely high.

Account abstraction intends to optimize from the underlying structure of smart contract accounts and pave 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 handling process of a transaction, from initiation to being received, verified, and gas paid by nodes. They do not actually focus on 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 process abstraction”, we can easily understand their key points: this type of transaction abstraction actually aims to bring the user experience of Web2-level users entering and using products into the Ethereum system, such as blacklisting/whitelisting, no need for identity verification for a period of time when initiating transactions, gasless transactions, fiat currency payment of fees, etc.

(Image source: Zengo)

But someone might ask: couldn’t these things already be achieved with past smart contract wallets? What is the value of account abstraction solutions like EIP-4337?

The essence of EIP-4337: a local optimum solution for the implementation of account abstraction in the Ethereum ecosystem

As mentioned above, although past smart wallets could achieve the functionalities mentioned above, the implementation methods were generally rough and often relied on highly centralized third-party facilities. For example, the past gas fee payment solutions required the introduction of third-party relay nodes (EIP-2771). Moreover, different smart wallets lack unified standards, which is not conducive to the development and deployment of supporting components.

The core demand of various account abstractions related EIPs is to solve the defects existing in different wallet projects through a standardized framework designed specifically for smart contract wallets, and promote the transformation of the account structure within the Ethereum ecosystem from a basic functional structure to a higher-level intelligent structure.

(Image source: Springer Link)

It’s like before ERC-20 or ERC-721 came into existence, the implementation methods, functionalities, and functions/interfaces provided externally by many tokens were not consistent. And this inconsistency is not conducive to the development of supporting third-party infrastructure, nor to code audits (it’s hard to imagine how Defi applications could have developed to their current level of prosperity without the ERC-20 protocol).

Standardization of protocols/functional implementations is a prerequisite for modular narratives, and modular development is almost a prerequisite for any field to thrive (division of labor is the first principle for improving efficiency).

In the end, EIP-4337 emerged.

EIP-4337 is a locally optimal solution, but there are several perspectives within its framework that need further optimization

EIP-4337 defines a complete set of interface standards, specifying which modules a smart wallet following the 4337 protocol should have, and which functions/interfaces each module should implement. For example, the components like Bundler, EntryPoint, and LianGuaiymaster should provide callable functions.

Once these frameworks are clearly defined, the interaction between different components becomes clearer, making it easier to introduce modular design concepts into the design of account abstractions and smart wallets, greatly benefiting wallet module developers.

Of course, from a user’s perspective, the value brought by the modular smart wallet development paradigm is not yet clear, because in the short term, people may not feel much change in the account abstraction wallet itself. But in the medium and long term, the value of protocols like EIP-4337 is similar to that of ERC-20 and ERC-721, as it lays the foundation for the long-term development of account abstraction wallets, marking a milestone with epoch-making significance.

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

1. Account abstraction functionalities are not modular enough, and different developers are prone to reinventing the wheel;

2. Poor compatibility of account modules results in a fragmented ecosystem of the entire account system;

3. High fragmentation of account abstraction ecosystems between different chains makes it difficult to provide end users and developers with a unified and high-quality experience to achieve better UX.

In the following text, we will explore solutions to these problems.

Optimization direction 1: Making account abstraction functionalities more modular 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 modularity in account abstraction wallets, and divide the granularity of each module even finer.

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

(Image source: Biconomy)

The so-called modular narrative for account abstraction is actually a set of protocols that clearly define the key modules involved in the smart contract wallet and what interfaces/functions these modules should implement, as well as the names and calling methods of these interfaces. Then, third-party developers can develop components with different details according to their own ideas, but these components will all comply with the requirements proposed in the protocol.

The V2 version of Biconomy is based on EIP-4337 as the protocol framework and has formulated more detailed standards, adding a batch of interfaces not mentioned in EIP-4337. While declaring the functions that Bundler, Smart Contract Wallet, and LianGuaiymaster modules should have, Biconomy allows third-party developers to implement modules with the same characteristics but different versions using different code details, as long as they comply with the protocol rules declared by Biconomy (compatible with EIP-4337).

(The interface standards proposed by Biconomy specify which functions should be implemented in the module for external calling)

At the same time, Biconomy has also proposed the slogan of “Module Store”. While actively launching the account abstraction module SDK, it encourages developers to submit their own designed account abstraction modules and carry out “Module as a service”, so that all wallet projects compatible with the EIP-4337 protocol can directly adopt these account abstraction modules written by outsiders. When users create smart accounts through the front-end page, they also have more diversified choices for which modules to use.

Modularization facilitates division of labor and also facilitates quick switching, addition, or removal of certain functionalities in smart wallets (in other words, finer-grained granulation).

Biconomy points out that the higher the modularity of smart contract wallets, the fewer changes they need to make when updating or upgrading (no need to update existing Smart Contract Wallet contracts or use DelegateCall, only need to update certain external modules), making it easier for different users or developers to replace certain components.

In Biconomy’s future account abstraction solution, it will also refer to EIP-6900, which is more conducive to modularity.

Optimization Direction 2: Finer-grained module division to solve the problem of fragmented accounts

Regarding the EIP-6900 proposal, Safe (formerly Gnosis Safe) actually released a Safe Core Protocol white paper related to it in August this year, which borrowed the most from EIP-6900.

(EIP-6900 schematic)

EIP-6900 points out that a problem with the current modular account abstraction is the “fragmentation” of accounts, or what we can call the island problem. For example, different account abstraction module suppliers, or different DAPP applications, although they may be compatible with EIP-4337, the abstraction level of EIP-4337 for different modules is not high enough, the granularity is relatively coarse, which gives the Smart Account module developers too much freedom. (The smart account is where user information is stored and the core part for recording custom transaction verification and gas payment logic).

In this way, different wallet projects tend to design smart account modules with unique attributes. Over time, other account abstraction module suppliers will have to consider compatibility with the Smart Account modules provided by someone else, and gradually a fixed upstream and downstream supply chain will be formed, which will inevitably lead to the fragmentation and disconnection of the account abstraction module ecosystem. (This is similar to early days in the computer industry, where operating system developers had to consider compatibility with the hardware devices provided by different computer manufacturers).

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

After drawing on the ideas of EIP-6900, the Safe Core protocol whitepaper made more detailed optimizations to the Smart Account (the user’s smart wallet account). The Safe Core protocol separates the callable modules of each smart wallet account into various categories such as plugins, hooks, signature validators, and function processors.

The smart account module itself should be 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 “function processors” or “plugins”, these specialized modules. This conforms to the principle of Occam’s razor – “Entities should not be multiplied unnecessarily.”

If the smart account itself is lightweight enough and does not involve too cumbersome details, smart accounts developed by different manufacturers will be closer in terms of internal structure, and their compatibility will also be higher.

The Safe Core protocol also introduces a registry, similar to the iPhone’s app store, which includes all approved modules. Users can choose which modules to activate, and each time a new module is activated, it must go through the Manager contract for processing.

Usually, 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), and if so, it will allow the plugin’s request. If necessary, the Plugin plugin may call certain functions provided by Hooks, or not. After that, the status of the smart account involved in the UserOperation will be changed.

Through the above fine-grained module slicing method and scheduling process, Safe Core Protocol attempts to promote an open source account abstraction module interoperability protocol. The core idea is to lightweight the Smart Account, making it as simple as possible, like an EOA account, in order to improve the compatibility of Smart Account modules developed by different vendors.

Optimization Direction 3: Full Chain Account Abstraction, Achieving Unified Account on Different Chains

However, even with the aforementioned solution, there is still a major problem that has not been solved: different chains and different Layer2 are pushing forward account abstraction implementation with different details, and many of them adopt a form that conflicts with EIP-4337, such as zkSync Era, Starknet, Flow, etc. This brings about fragmentation in wallet user experience, for example, 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 in these contracts in a scattered manner. If user data such as keys needs to be updated, multiple transactions need to be initiated on multiple chains, making it difficult to ensure the consistency of Smart Account.

Vitalik himself previously proposed a unified and easy-to-manage smart account solution, which uses Ethereum or a highly secure ZKRollup as the source chain, deploys the Keystore contract, and stores the user’s global key, and then all the 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)

But this solution is extremely expensive, whenever the global key recorded in the Keystore contract on the source chain changes, each account on L2/target chain needs to synchronize the new key through cross-chain interaction. However, the cost of cross-chain interaction between Ethereum and L2 is too high, and users simply cannot afford it. Also, it should be noted that smart contract accounts are different from EOA accounts. The latter is inherently unified across multiple chains (EVM chains) due to its unique address generation method, 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 this regard, LianGuairticle Network has proposed its own method. Although the general idea is consistent with Vitalik’s ideas, it also separates the Storage and Code of smart accounts. However, LianGuairticle Network intends to use an independent chain — the LianGuairticle Network Chain — as the full-chain Storage database for smart accounts, and synchronize the changes in a user’s 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, the full-chain account abstraction system of LianGuairticle Network 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 a new account on the LianGuairticle Network Chain, and then the LianGuairticle Chain will trigger the Deployer Contracts on all chains to ensure that the smart contract account addresses generated for users on different chains are consistent. Alternatively, users can interact with multiple chains through contracts on the LianGuairticle chain without being aware of other chains, and can use Unified Gas Token as a unified fee payment method.

The full-chain account abstraction also enables Cross-Chain User Operations by triggering transactions on the target chain through User Operations and paying the corresponding Gas on the source chain. For example, it allows purchasing NFTs on Base using USDC on Polygon.

However, the solution of LianGuairticle Network requires tight coordination between the Deployer Contracts and the cross-chain messaging component to synchronize the multi-chain account and the source chain’s storage. This imposes high requirements on the oracle or cross-chain messaging bridge used (which seems to be a common issue in all solutions related to full-chain interoperability).

Nevertheless, the synchronization of cross-chain accounts for users can be flexibly configured using combinations of different Message Bridges, rather than relying solely on one Bridge. For example, it can be configured with a 2/3 strategy, where confirmation from any two out of LayerZero, Axelar, and Connext is required to confirm the storage change on the target chain, approximating a solution to single-point dependence.

Seamless interoperability across EVM and non-EVM chains is a further advancement of full-chain account abstraction in the Ethereum ecosystem.

Despite the cross-EVM chain key management and unified accounts, there is still room for improvement in full-chain account abstraction: incompatible chains with EVM, such as Aptos, Solana, Sui, etc., cannot guarantee that the smart contract account addresses generated by users are consistent with those on EVM chains. Likewise, non-EVM chains without an equivalent solution to implement the EIP-4337 protocol would struggle to adopt the concept of full-chain account abstraction proposed by Vitalik and LianGuairticle Network.

In addition, there is also room for improvement in wallet projects that are compatible with EIP-4337. Most smart wallet Bundler nodes are independent and not interoperable, resulting in many risks (censorship resistance, availability). Building a unified frontend interface across most chains is very challenging. One solution is to introduce an intent-centric design, adding an additional layer on top of full-chain account abstraction, treating Ethereum’s EIP-4337 ecosystem or other chains’ native account abstraction facilities (e.g., zkSync) as specific instances under Solver/Reactor types, with the task of selecting suitable Solvers being at a higher level.

Using LianGuairticle Network as an example, it proposes a concise abstracted Intent-Centric implementation solution, and different account abstraction projects are just a category of instances included in the Solver category within the Intent framework.

First, the user interface will be responsible for converting natural language requests or any user interaction into specific programmatic descriptions, which include input constraints and output constraints (in simple terms, the conditions for acceptable input and the range of possible output results that meet the user’s requirements). Then, one or more solvers in the Solver network will forward the Transaction containing the specific input-output constraints to the Solver contract deployed on the blockchain (the Solver not only includes node infrastructure but also on-chain contract components). The Solver contract will transmit the Intent instructions to the Reactor contract (which manages user accounts on the blockchain), allowing the latter to call other modules to complete the final interaction.

The user’s request is initially known by the Solver network, so the user does not need to have a deep understanding of the underlying blockchain or the construction of different account abstraction schemes. This part is handled by the Solver, which constructs the specific solution.

Of course, these ideas are currently just a theoretical framework, and the implementation details will be revealed by the official exposition of the LianGuairticle Network.

What is clear is that there will definitely be a competitive Solver market in the future, where users can initiate bidding to have multiple Solvers present different solutions. Through local simulated transactions, the best solution can be selected and corresponding incentives can be given to the respective Solver. The form of incentives will depend 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 Intent concept essentially shields the complex underlying details and abstracts a higher level. This hierarchical design, similar to the TCP/IP protocol, is a necessary condition for seamless user and developer experiences in a fully interconnected chain.

 Embracing the widespread adoption of account abstraction

When we optimize the 4337 framework within the Ethereum ecosystem from various angles and promote seamless interoperability across both Ethereum and non-Ethereum ecosystems, in order to support the widespread adoption of account abstraction, we believe that there still needs to be a product that spans the supply and demand sides. This product aims to reduce the end users’ use of various Web3 product services while focusing on service developers and lowering the entry barrier for developers.

One of the best products that plays this role is LianGuairticle Network’s modular Smart Wallet-as-a-Service (Modular Smart Wallet-as-as-Service) product:

(LianGuairticle Network’s Smart Wallet-as-a-Service Architecture)

• This service provides an easy-to-use set of APIs that allows developers to easily integrate modular account abstraction functionality into their applications;
• Developers can use this service to create and manage cross-chain accounts, perform cross-chain interactions, and use a unified fee payment method;
• This 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 characteristic is the modular smart wallet-as-a-service (LianGuairticle Network) that has built an open ecosystem for developer-oriented account abstractions based on signature computation. In addition to providing self-developed account abstraction product modules, it integrates various types of account abstraction products and services, thereby accelerating the adoption of products and services by developers in the entire account abstraction field.

(Modular Design of LianGuairticle Network’s Smart Wallet-as-a-Service)

By serving the demands through technology, after addressing the limitations of the ERC-4337 framework from various aspects, 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.

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