Behind the diverse account abstractions, how can we move towards a unified "user-centric" abstraction?

Author: Haotian

Seeing that Particle Network has released a full-chain account abstraction, it feels like they are adding a "middle layer" on top of the existing ERC4337 standard. Why do this? It's puzzling yet understandable; if you are familiar with the current state of account abstraction, the answer becomes clear:

• Currently, various EVM-equivalent chains, including Layer1, Layer2, and Layer3 application chains, have entirely different methods, and this type of abstraction is chain-centric rather than user-centric;
• To truly achieve a user-centric model, for instance, allowing a user to connect all associated chains through a single entry point and address, thereby creating a more coherent and global interaction experience, a "middle layer" that can define intent and unify standards and execution becomes essential;

Why is the current market's practice of "account abstraction" so fragmented? How does Particle Network's full-chain account abstraction technically achieve this? How much further do we have to go for mass adoption of intent-centric abstraction? Let's analyze these one by one:

The unified account abstraction AA solution is consistent at the "engineering" level, but the practical level varies greatly

In simple technical terms, account abstraction allows users to push a series of intents into the UserOP memory pool, which are then packaged and sent to the Entrypoint contract for execution by the Bundler. During this process, transactions can be aggregated and signed through an Aggregator, with the Paymaster handling the details of gas fee payments.

This is a standard defined by ERC4337, and the backend implementation logic is also unified, but it is essentially a chain-centric abstraction of EVM, and the frontend that connects to users does not necessarily have to be "unified."

For example, zkSync uses EOA address binding for accounts, where users only see a transferable shadow address, and the frontend hardly feels the presence of an AA account; Starknet, on the other hand, adopts an upgradable contract account model, requiring users to constantly upgrade contracts to update account functionalities. Additionally, Argent employs a Guardian mechanism for social recovery, while Unipass's account abstraction solution tends to apply in non-EVM heterogeneous multi-chain environments, and so on.

Wait, this lack of uniformity at the entry point seems like a form of personalization, but it undoubtedly raises the user barrier. How can abstraction, which aims to simplify, actually increase the barriers in a "user-centric" manner? This is reflected in the fact that a user in a multi-chain and multi-Layer2 environment cannot interact with just one chain; crossing multiple wallets and chains inherently creates a learning cost. A user on different EVM chains will generate multiple different contract addresses, posing challenges for unified asset management.

How can such a fragmented multi-chain ERC4337 standard implementation lead to mass adoption from a user-centric perspective?

What are the challenges in unifying account abstraction practice logic? Using full-chain account abstraction as an example

As mentioned earlier, the current account abstraction is only chain-centric for EVM, but EOA addresses can still maintain uniformity across EVM chains. Why is that?

Because EOA addresses are derived from public keys, as long as the algorithms are consistent across different chains and the private keys are the same, the derived addresses will also be the same. However, contract addresses are calculated from the Creator address and Nonce, and since each chain has different Nonces, the resulting contract addresses will also differ. One seemingly feasible approach is to use a registry method to map the same address across different chains, but this carries centralization risks.

In contrast, Particle Network's full-chain account abstraction structure attempts to take on the role of a "dispatch center" using a decentralized chain-native framework. Every new chain that generates a new address will be unifiedly connected to the sub Deploy Contract for unified operations, including deployment and upgrades, all coordinated by the master contract.

The only challenge here lies in the smoothness of real-time communication between heterogeneous chains, requiring the "middle layer" to act as an efficient communication medium, capable of achieving unified scheduling through contracts distributed across various chain light nodes, with a practical solution similar to LayerZero's cross-chain solution.

This approach at least breaks through the property limitations of EVM chains, allowing any multi-chain that supports heterogeneous chain contract interoperability and the EIP-4337 solution to be included within the multi-chain system. It can significantly achieve full-chain account abstraction.

However, non-EVM chains like Aptos and Sui currently cannot achieve connectivity in a similar contract-linked manner. Indeed, it confirms that this is still an additive solution from the EVM camp. Given Ethereum's absolute dominance in the Layer, Layer2, and Layer3 domains, the market is already large enough.

What other modular abstract services can the "middle layer" release in terms of imaginative space?

Of course, to truly achieve comprehensive "user-centric" abstraction, full-chain account abstraction is just the beginning. Besides abstracting the account itself to enhance the experience, a "middle layer" dispatch center can also attempt to perform other abstract tasks:

1. A cross-chain asset transfer and unified settlement layer, allowing users to manage and circulate assets in a decentralized manner across different chains, reducing potential slippage and friction costs in cross-chain transactions. dappOS has adopted a similar middle-layer abstraction solution;

2. A unified identity and credit connection for cross-chain DID, using the middle layer as an "authentication center" to achieve identity sharing and data synchronization across multiple chains, thereby generating "credit" for cross-chain applications, reducing user barriers across platforms, while breaking the data fragmentation between chains, truly realizing an "identity"-centric interaction experience;

3. Implementing a unified decentralized Solver solution, ideally aggregating these dispersed Solvers into a super Solver dispatch center. For example, users could connect to various Solver solutions like UniswapX, Cowswap, and Flashbot's SUAVE on a single platform, facilitating participation from market makers, institutional traders, arbitrage scientists, and other potential Solver participants. Without a middle layer for scheduling, these Solvers would undoubtedly remain fragmented across chains.

The Cosmos chain has abstracted an IBC middle communication layer to connect various chain hubs. You can understand that, in the EVM ecosystem, given the inherent existence of various standard splits, ERC4337 defines communication rules, and communication still relies on a "middle layer" like IBC.

Moreover, do not underestimate the value of such middle-layer infrastructure, as it may be a necessary complement for account abstraction to break away from the engineering abstraction layer and move towards large-scale popularization and implementation.

We have placed too many expectations on the intent-centric abstraction track, but this track will remain very abstract for a long time. How to maximize the value of standards, how to unify the product and protocol standards of various wallets and chains in the track, and how to truly bridge the gap between Web2 user experience and Web3 chain-native characteristics based on user-centricity are all challenges that need to be addressed.