Why is the current "account abstraction" too divided, and how to move towards a unified "user-oriented" abstraction?

Author: Haotian

Seeing that Particle Network has newly released the full-chain account abstraction, it feels like it needs to superimpose a "middle layer" on top of the existing ERC4337 standards, why do you have to do this? If you are familiar with the current status quo of account abstraction, it is not difficult to come up with the answer:

• At present, each EVM equivalent chain, including Layer 1 and Layer 2 and Layer 3 application chain, has a completely different approach, and this kind of abstraction is chain-based, not user-oriented;
• In order to truly realize the user-oriented, such as allowing a user to connect all the associated chains based on one entry and one address, so as to achieve a more coherent and global interactive experience, a "middle-layer" role that can define the unified specification and implementation standards of intent has become a must;

Why is the current market practice of "account abstraction" too divided? How is Particle Network's full-chain account abstraction technically implemented? How far is it to achieve Mass Adoption of the Intent centric abstract track? Let's analyze them one by one:

Account abstraction AA solutions are unified at the "engineering" level, and the practice layer is multifaceted

In terms of technical simplicity, account abstraction is a series of intentions that users stuff into the UserOP memory pool, and the bundler packages them and sends them to the Entrypoint contract for execution, where the batch transactions can be processed through the signature aggregation of Aggregator, and the details of gas payment are handled by Paymaster.

This is a set of ERC4337-defined standards, and the back-end implementation logic is also unified, but it is essentially an abstraction of the EVM chain, and the front-end that connects users is not necessarily "unified".

For example, zkSync uses EOA addresses to bind accounts, and all users see is a transferable shadow address, and the front-end hardly feels the existence of AA accounts. Starknet, on the other hand, is in the form of an upgradeable contract account, and users need to constantly upgrade the contract to update the account function. In addition, Argent uses the social recovery mechanism of the Guardian mechanism, and Unipass's account abstraction scheme tends to be applied in heterogeneous multi-chain applications in non-EVM environments.

Wait, this kind of inconsistency at the entrance end seems to be a kind of personalization, but it undoubtedly increases the threshold for users. Abstraction comes and goes, why is the threshold higher in the "user-oriented"? It is manifested in the fact that it is impossible for a user to interact with only one chain in a multi-chain and multi-Layer2 environment, and the learning cost is generated out of thin air when spanning multiple wallets and multiple chains; A user will generate multiple different contract addresses on different EVM chains, which brings challenges to the unified management of assets.

How can such a fragmented multi-chain ERC4337 standard engineering implementation lead a user-oriented Mass Adoption?

What is the difficulty in the abstract practice logic of unified accounts? Take the full-chain account abstraction as an example

As mentioned earlier, the current account abstraction is only based on the EVM chain, but the EOA address can still be unified with the EVM chain, why?

Because EOA addresses are derived from public key computation, as long as the algorithms of different chains are the same, and the private key is the same, the derived address is also the same. However, the contract address is calculated from the Creator address and the nonce, and the contract address is different due to the different nonces of each chain. One seemingly feasible approach is to use a registry approach to map the same address between different chains, but there is a risk of centralization.

On the other hand, Particle Network's abstract structure diagram of the whole chain account, it is trying to assume the role of a "dispatch center" with the native framework of the decentralized chain, and each new chain with a new address will be generated by the general contract of the dispatch center, and the sub-Deploy Contract will be uniformly connected to the Deploy Contract for unified operation, including deployment and upgrade, all aspects will be uniformly scheduled by the general contract.

The only difficulty in this is the fluency of instant communication between heterogeneous chains, which requires the "middle layer" to act as an efficient communication medium, which can achieve unified scheduling by distributing contracts on each chain light node, and the practice scheme is similar to LayerZero's cross-chain solution.

This approach at least breaks through the attribute limitations of EVM chains, so that any multi-chain that supports heterogeneous chain contract interoperability and EIP-4337 scheme will be included in the multi-chain system. Full-chain account abstraction can be implemented on a large scale.

However, non-EVM chains like Aptos and Sui are currently unable to connect in a similar way in series. This is a big enough market at a time when the Ethereum ecosystem is absolutely dominant in the Layer, Layer 2, and Layer 3 categories.

What kind of imagination can be freed up by other modular abstract services in the "middle layer"?

Of course, to really achieve a full range of "user-oriented" abstraction, the full-chain account abstraction is just the beginning. In addition to the account itself being abstracted to improve the experience, a "middle-tier" dispatch center can also try to do other abstract work:

1. The transfer of cross-chain assets and the unified settlement layer allow users to realize asset management and circulation in a decentralized way between different chains, reducing the possible slippage friction consumption of cross-chains.

2. Cross-chain DID unifies the concatenation of identity and credit, with the middle layer as the "authentication center", to realize identity sharing and data synchronization between multiple chains, and then derive the "credit" that can be applied across chains, reduce the cross-platform threshold for users, and at the same time break the data separation between chains, and truly realize the interactive experience of "identity" standard;

3. Implement a unified decentralized Solver solution, it is best to aggregate these scattered Solvers into a super Solver dispatch center, for example, users can connect to UniswapX and Cowswap and Flashbot's SUAVE and other Solver solutions on one platform, and construct a Solver that is convenient for potential Solver participants such as market makers, institutional traders, and arbitrage scientists. Because without the middle layer for scheduling, there is no doubt that these Solvers will still exist in fragments between chains.

You can understand that under the premise that there are various standard splits in the EVM ecosystem, ERC4337 defines the communication rules, and the communication still relies on an IBC that acts as the "middle layer" to emerge.

And don't underestimate the value of this kind of middle-tier INFRA, because it is likely to be a necessary supplement for account abstraction to move away from the engineering abstraction layer and move towards large-scale popularization.

How to maximize the value of the ERC4337 standard, how to unify the products and protocol standards of various wallets, chains and other builders in the track, and how to truly smooth out the gap between the Web2 user experience and the native characteristics of the Web3 chain based on the user-oriented are all topics that need to be overcome.