Original author: Pengyu, Co-founder of Particle Network

Intent-Centric (intent-centered) is a topic that has caused a lot of discussion recently, and there are also a lot of doubts on top of the popularity.

Questions mainly focus on two angles:

• It is too abstract and narrative-oriented, making it difficult to implement the project. It is not like a technology-driven industry upgrade, but more like a product design philosophy.

• It may just be that the Account Abstraction track has a new term. Because intuitively everyone would think that Intent-Centric (intention-centered) and Account Abstraction (account abstraction) have a certain relationship, and they seem to be related to lowering the user threshold and improving user experience.

This article will analyze the association, evolution and competition between Intent-Centric and Account Abstraction.

The origin of Account Abstraction

Overall, the development trend of the Web3 industry is from a cypherpunk-friendly engineering industry to a mass-friendly consumer industry.

For Ethereums Account Abstraction, the community has already started discussions between 2016 and 2017. Early discussions and design goals were more from a developer perspective, mainly to simplify the creation and interaction of contracts and provide more freedom for complex transaction structures. In addition, we also hope to solve some complex problems in smart contract and dApp development through account abstraction. The account abstraction at this stage is essentially a generalization of the account model.

In the development of account abstraction, the core is the proposal and maturity of ERC-4337. As the discussion deepened, the community found that some common demands of ordinary end users in application layer business scenarios were impossible to solve from the account structure and chain.native structurebe directly satisfied. For example, recovering private keys, obtaining specific services with 0 gas, and batch authorization, etc.

As a supplement to the previous exploration of account abstraction, ERC-4337 was proposed by Vitalik and Ansgar Dietrichs, hoping to provide some scenario functions from the perspective of upgrading the account structure itself. It introduces the concept of User Operation, allowing users to conduct transactions more flexibly without worrying about Nonce or complex transaction fees.

Please see the figure below for the timeline proposed for different protocols in the field of Account Abstraction:

The current status of the account abstraction industry: core values ​​and constraints

The Account Abstraction industry is close to maturity and is easy to understand. We can roughly divide the current Account Abstraction industry into the following in order of proximity to users:

• Public chain layer

• private key management

• AA Stack layer (mainly including Paymaster and Bundler)

• Functional layer

• Application layer

There are many mature solutions for private key management, such as Magic.link, a hosted solution based on AWSs KMS service, and MPC-TSS used by us (Particle Network). There are currently more than 100 providers of the AA Stack layer, including startups StackUp, ZeroDev, Pimlico, infrastructure Alchemy, and leading wallet company Safe, which have all provided available solutions. On the application layer, we have seen that leading projects such as CyberConnect and dYdX are already applying Account Abstraction to their own specific business scenarios.

Account abstraction undoubtedly promotes end-user experience and clears more obstacles for the large-scale application of Web3. However, the actual effect at this stage clearly does not match our expectations for the paradigm improvement that account abstraction can bring to the industry experience.

Because the essence of Account Abstraction is to solve user UX problems from the supply side, it is more like providing developers with more development options at the account structure level. At the same time, the expansion of social login + account functions brought about by the combination of account abstraction and private key management reduces the threshold for new users to enter Web3 product services to a certain extent.

However, judging from the acceleration of the popularity of account abstraction and the feedback from end users on Aha moments, it seems that user potential has not been fully unleashed.

Of course, on the one hand, this is because the quantity and quality of application layer content are still being rapidly iterated, but on the other hand, we think it is because:

• Account abstraction optimizes the user experience when entering expressions

• But it did not solve the problem of expressing the results

The optimization of expression and results is the core value of Intent-Centric.

Why Intent-Centric was proposed is mainly due to two reasons:

• One of the cornerstones of the encryption industry is to restore user autonomy from the underlying design of the chain, including asset autonomy, data autonomy, and information autonomy. But the problem brought about by autonomy is that every subtle on-chain operation behind completing a goal needs to be exposed to users for authorization.

• In the early days of the industry, the business scenarios were relatively single, the execution logic was relatively simple, and there was little interoperability between chains. At this time, there were not many user authorizations required. There were few places where users needed to make active judgments, and the experience was okay. Accepted. But when more L2s appear, and more services overlap each other and are combined together, it will appear that the users needs are single, but the frequency of authorization is very high, and more are involved in the process. Subjective judgments, such as Gas, slippage settings, etc.

The core logic introduced by Intent-Centric is actually to block the process without losing user autonomy., including process monitoring and process management, users only need to clarify the starting point and end point of their needs. The benefit of this is that it allows users to transform from a Transaction perspective to a demand perspective.

We can test this problem with a simple conversation question:

Let me ask you about one of the most common on-chain operations: I have 10 ETH, and I want to lend it out on Compound at an annualized return of 2%.

Is this expression really what you need?

In fact, this expression is not your need. Your need is: I have 10 ETH, help me find the highest return in a safe protocol.

And loan out on Compound at an annualized return of 2% is a Transaction.

Then why do you subconsciously think that this Transaction is your need? Essentially, it is because the current encryption industry has been separated into transactions and states one after another. All needs need to be broken down into transactions and the status can be monitored. The problem brought about by being realized is that the users I just mentioned do not start from the perspective of demand, but from the perspective of transaction. This obviously limits the expression and realization of many user needs, because the users psychology actually has a way of thinking. of shackles.

Therefore, Intent-Centric (intent-centered) solves the problem of expressing the optimal path to the result.

This matter is valuable, because only by solving the problem of the path from expression to results can the vast needs of end users be truly released.

To achieve such a goal, from what angles Intent-Centric (intent-centered) needs to promote products and research.

Based on the idea just now, we divided the entire Intent-Centric industry into four layers:

• User Expression Entry Level

• Translation layer that expresses the intention

• Integration layer for vertical needs

• Coordination layer for complex requirements

The calculation purposes completed by each are very clear:

• The entry level of user expression is used to collect the real needs of users. Core indicators: completion rate;

• The translation layer that expresses the intention is to translate the real needs of users into a language that can be communicated uniformly between machines, between developers and machines, and between developers. The core indicators are: response time and accuracy;

• The integration layer of vertical demand is to integrate vertical category demand and match up appropriate solvers (Solvers) to respond to this demand. Core indicators: matching efficiency;

• The coordination layer that meets the needs is to disassemble the composite requirements into vertical category requirements, and at the same time coordinate the Solvers (solvers) of different vertical categories to respond to the composite requirements according to a goal or logic. Core indicators: dismantling efficiency and demand coverage.

When all four angles have a certain degree of maturity, they can bring about such a user path:

The user completes the expression of requirements at any expression entry layer, and the expression is translated by the translation layer into an intention described in a universal language for inter-machine coordination. The intention is disassembled by the coordination layer, and the Solvers (solvers) of the vertical demand integration layer compete to These intentions are executed in an efficient and safe manner, and finally the execution results of vertical intentions are integrated into a composite intention result by the coordination layer.

Let’s take a look at a practical example:

A Coinbase stock holder saw the release of Base Chain and wanted to experience a game application on Base Chain. He knew what he needed was to Mint the games NFT to start the process.

We skip the wallet registration process (which is already very complicated), and assume that he has played other Web3 games in the Polygon ecosystem and already holds Polygons Matic tokens. In order to participate in the Base Chain project, he needs to complete the following disassembly:

• Find a three-party cross-chain bridge to cross-chain Matic tokens to Ethereum’s ETH tokens

• Cross ETH tokens from Base Chain to ETH-Base;

• Mint NFT；

• Start the game.

This is the current process. Even if it is Batch Transaction (packaged transaction) or Gasless Transaction (Gasless transaction) combined with account abstraction, the threshold is still very high. We know that the users intention (Mint an NFT on Base Chain to start the game) is actually clear. He knows what he wants to do, but the process is too cumbersome.

If the Intent-Centric field matures, it can complete the structuring, dismantling, and execution of user intentions. From the perspective of end user experience, users interact with wallets or applications that are adapted to the Intent-Centric protocol or inChatGPTSimilar to expressing ones intention in LLM UI, the Intent-Centric development framework integrated by the developer will automatically structure the Intent, and then the Intent Bidder and Solver will complete the final disassembly and execution. The users perception is just clicking a button or sending a message. said a word.

We can now try to answer this question: Is Intent-Centric old wine in new bottles for AA (Account Abstraction) or is it the best choice for evolution?

In addition to taking a step further along the user path - from entry to expression to expression to result - in what other ways is Intent-Centric significantly different from account abstraction?

Through the comparison of the above content dimensions, we can clearly answer:Intent-Centric (intent-centered) is not an old wine in a new bottle of Account Abstraction (account abstraction), but another option for user path experience optimization.

But will the Account Abstraction track become an infrastructure for implementing specific operations in the Intent-Centric field as the Intent-Centric field becomes more mature? We need more information. This can only be judged if the protocols or products in this field become more mature.

Particle Network’s unique perspective in the Intent-Centric field

First, let’s review our core product of V1: Wallet-as-a-Service based on MPC-TSS and Account Abstraction. The value position in the field of Account Abstraction can be used as shown in the figure. Show.

As shown in the figure, it is clear that our core work is the Key Management (private key management) layer based on MPC-TSS and the functional layer that provides the social login suite.

In fact, essentially our V1 only does two things:

• Simplify and abstract users’ behaviors and needs when entering Web3 products through social login;

• Calculate multi-chain signatures and directly complete signatures in various types of products connected to our wallet as a service to improve transaction efficiency.

The core reasons why we launch Intent-Centric related products are two points:

• The core work of Intent-Centric is completely consistent with the essence of our v1 product: abstracting user needs and improving transaction efficiency.

• we are atB 2 B 2CUnder this approach, we have worked with our partners to introduce a considerable number of users in the past 10 months, and our focus has shifted from user entry to user expression and results.

So what is our basic judgment on the Intent-Centric field, our unique advantages in Intent-Centric, and what is our product strategy based on this advantage?

We believe that in the hierarchical logic of the Intent-Centric field we mentioned above, there is a clear order of value priority:

We believe that the Translation Layer that expresses the intention is the core, because it is the only one that has been driven by the formulation of standards.flywheel effectlevel, followed by the Cordination coordination layer of composite requirements, then the integration layer of vertical requirements, and then the expression layer of user portal.

What are our unique strengths at Intent-Centric:

• The accumulation of abstract user needs and the accumulation of multi-chain and multi-behavior signature calculations;

• Partners who have completed product integration covering basically all tracks;

So our V2 product in the Intent-Centric field is called Intent Fusion Protocol, which essentially includes:

• A unified language and framework to express the intended translation layer (serving the translation layer we feel is most important)

• Development kit for the coordination layer of complex requirements

• and zkEVM, which is used by Particle Network for abstract management and calculation of full-chain accounts.

We look forward to using V2s Intent Fusion Protocol to allow users to log in privately in any application layer product enabled by zkWaaS products (while enjoying the convenience of social login without exposing any Web2 identity privacy), allowing them to persist with one click. Some ETH participates in the best on-chain income products on any L1/L2, and automatically redeems them when the income reaches a specific amount, and thenpledgeGo to Lido for risk-free returns.

Particle Network V2s Intent Fusion Protocol will be more based on user needs and expectations, rather than providing a bunch of complex functions and settings, and directly accomplish the users true intention with minimal understanding and operation costs.

We feel this method can get closer to our goal:

By creating an intent-centered, modular Web3 access layer, we accelerate the transformation of Web3 from an engineer-friendly financial industry to a mass-friendly consumer industry.