Taking Particle Network as an example, the technology interprets the experience problems of current Web3 products

Author: Wuyue, Geek Web3

Introduction: Although AA wallet has lowered the threshold for users to a large extent and initially realized gas payment and web2 account login, the design related to mass adoption, such as privacy login - private transaction, full-chain unified AA account, and intent dedicated architecture, still needs to be added on the basis of AA.

Although we can see many UX optimization solutions, such as MPC wallets such as ZenGo or smart contract wallets such as Argent, which effectively lower the threshold for users, they only solve some of the above problems, and do not fully cover the ease of use of the product.

Obviously, most AA wallets or similar products are not yet able to support the mass adoption of Web3. On the other hand, from an ecological point of view, the developer side is a very important level, which is only attractive to ordinary users in terms of products, but it is difficult to form a scale because of its insufficient influence on the developer side. **The emergence of more and more development experience optimization solutions has demonstrated the importance of the developer side to the product ecosystem.

We will take Particle Network as an example to explain in detail the current experience problems of Web3 products, and how to design a comprehensive technical solution, which may be a necessary condition for mass adoption. At the same time, Particle’s BtoBtoC business strategy happens to be an idea that many project parties need to learn from. **

Particle product structure full solution

With the core of solving the threshold of use, Particle Network proposes a complete set of solutions for the large-scale adoption of Web3 with the idea of B2B2C product construction and ecological development. Its core modules are three:

**zkWaaS, a Wallet-as-a-service (WaaS) service based on zero-knowledge proofs. **Developers can quickly integrate the smart wallet module into their own dApp based on the SDK provided by Particle. The wallet is a keyless smart contract wallet based on account abstraction, which can not only realize AA basic scenarios such as gas payment, but also provide Web2-style OAuth privacy login methods and private transactions and other functions.

Particle Chain - An Omnichain Account Abstraction solution dedicated to Particle, dedicated to solving the cross-chain deployment, maintenance, and invocation of smart contract wallets. There is also a Unified Gas Token (Unified Gas Token) to solve the trouble of using different gas coins for multi-chain transactions.

**Intent Fusion Protocol, which includes a concise DSL (Domain Specific Language) language, Intent Framework, Intent Solver Network, etc., is used to build a set of Intent-based Web3 interaction frameworks. Users directly declare their transaction intent instead of performing each specific action, freeing users from cumbersome path thinking and reducing their understanding of the complex underlying infrastructure.

zkWaaS – Smart Wallet-as-a-Service combined with ZK

On the wallet side, Particle mainly provides SDKs for dApp developers in the form of WaaS (Smart Contract Wallet-as-a-Service), in order to allow developers to access its complete Web3 mass option framework. This BtoBtoC solution has several advantages from a business and ecological point of view:

**The competition of pure C-end wallets has become white-hot, and the functions are relatively similar, and C-end wallets are no longer a good entry point. On the other hand, dApp developers are increasingly inclined to build wallets into dApps to avoid the loss of experience when users need to switch wallets when connecting wallets and transactions, and provide more customizable features.

**The customer acquisition cost is high on the C-side, but it is different on the B-side. **WaaS user growth is primarily driven by dApps integrated with SDKs. As long as the relationship between BD and developers is good, the entire ecosystem can be expanded in a “city surrounding the countryside” style.

**At present, C-end wallets are mainly focused on finance and assets, and it is difficult for us to say that this is the main scenario of Web3 in the future. To truly achieve mass adoption of Web3, there must be projects that abstract the more basic features - user identity (account) and user operation (sending transactions/transactions) as a low-level service, and hand over the richer scenarios of the upper layer to the dApp.

From the previous dApp connection entrance, you can observe the close binding relationship between the wallet and the dApp. **It is very important to increase the market share of wallets as much as possible on the dApp side. This is the first priority for the B2B2C model. **

Building a WaaS that meets the needs of users, lowers the barrier to entry, and is easy for developers to access is another pillar of the solution’s success. Particle’s zkWaaS has three cores:

**1. Privacy Login. **Using traditional Web2 login methods on contract wallets, such as Twitter, Google, WeChat login and other OAuth verification methods, users can completely get rid of the shackles of private key management and enter Web3 in the most familiar and simple way. At the same time, zero-knowledge proofs are used to hide user identities.

2. Privacy Transactions. **Implement peer-to-peer universal private transfers through the Smart Stealth Address mechanism, and use ERC4337 Paymaster to allow the Stealth Address to use assets (gas sponsors) without gas.

**3. Complete AA wallet function. **Particle’s wallet module fully complies with the basic requirements of ERC-4337, including Bundler, EntryPoint, Paymaster, Smart Wallet Account and other important parts of ERC-4337 workflows, one-stop to meet the functional requirements of DAPP or users for smart wallets.

On-chain wallet privacy login based on web2 accounts

Particle’s private login solution makes use of JWT (Json Web Token), which can be used for Web2 identity authentication and wallet operation within the contract.

JWT is a kind of identity certificate issued by the server to the client that is widely used in the traditional Internet, and the client relies on this proof to authenticate each time it interacts with the server.

There are several key fields in the JWT that are the basis for the contract to verify identity:

·" iss" (Issuer) indicates the publisher of the JWT, that is, the server, such as Google, Twitter, etc.

·" aud" (Audience) indicates the service or application used by the JWT, if you log in to Medium with Twitter, then this field will indicate that the JWT applies to Medium when Twitter issues the JWT.

·" sub" (Subject) refers to the identity of the user who accepts the JWT, which is usually marked by a UID.

In practice, the ISS and sub will not change in the vast majority of cases, otherwise it will bring a huge mess of internal systems and external references. Therefore, these parameters can be used by the contract to determine the identity of the user,** so that the user does not need to generate and keep the private key at all. **

The concept corresponding to JWT is JWK (JSON Web Key), which is a set of key pairs on the server side. When the server issues a JWT, it will sign with the JWK’s private key, and the corresponding public key is public and used to verify its signature for other services.

For example, if you log in to Twitter on Medium, Medium will verify the JWT with the JWK public key that Google has made public to confirm that the JWT is authentic — that it was indeed issued by Google. JWK is also used for contract validation of JWT.

Particle’s private login solution flow is shown in the following figure:

Among them, we will skip the specific ZK circuit here. List just a few of the key points in the process:

**The Verifier contract that verifies the login information will only perceive a ZK Proof related to the user’s identity-JWT, as well as an innocuous eph_pk, and cannot directly obtain the corresponding wallet public key or JWT information, so as to protect the user’s privacy, and the outside world cannot know the identity of the login person from the on-chain data. **

Eph_pk (ephemeral key pair) is a key pair used in a single session, not the public or private key of the wallet, and the user does not need to care.

This system can also be used for off-chain verification, and can be used for contract wallets that use logic such as MPC.

Since this is a true contract verification scheme based on traditional logins, users can also designate other social contacts as their guardians in case of very extreme situations such as Web2 account cancellation.

Private transactions based on the DH key exchange method

Before talking about Particle’s private transaction solution, let’s first examine how to achieve private transactions to recipient within the existing EVM system, that is, hide the recipient’s address.

Let’s assume that Alice is the sender and Bob is the receiver, and we have some common knowledge:

1. Bob generates the root spending key m and the stealth meta-address M. M can be generated by m, and the relationship between the two is M = G * m, which represents a mathematical relationship in cryptographic operations.

2. Alice obtains Bob’s stealth meta address M in either way.

3. Alice generates a temporary private key r, and uses algorithmic generate_address (r,M) to generate a hidden address A. **This address is Bob’s exclusive **** stealth address, and Bob has control of the address after receiving the assets. **

4. Alice then generates a temporary public key R based on the temporary private key r and sends it to the temporary public key record contract (or any mutually agreed location, whatever the channel as long as Bob can obtain it).

5. Bob needs to periodically scan the temporary public key record contract and record each updated temporary public key. Since the ephemeral public key contract is public and contains keys related to private transactions sent by others, Bob doesn’t know which one Alice sent to him.

6. Bob scans each updated record and performs generate_address (R,m) to calculate the redacted address. If there is an asset in the address, it is generated by Alice and authorized to be controlled by Bob, otherwise it has nothing to do with Bob.

7. Bob executes the generate_spending_key(R,m) to generate the consumer private key for the stealth address, i.e. p = m + hash(A), and then can control the address A generated by Alice.

The above process description actually simplifies a lot of complex mathematical operations,**The entire intelligence exchange process is like two spies writing down some code words that can only be deciphered by each other on a public bulletin board,**Although the generation and decryption methods of code words are public, only two spies know the important data necessary in the middle, so even if the outside world knows the generation and decryption methods of code words, they still can’t be decrypted smoothly.

This exchange process is much the same as the well-known Diffie–Hellman key exchange method, in which both parties can calculate the shared secret – Hidden Address A above – without revealing their respective secrets (Bob’s root consumer private key m and Alice’s temporary private key r). **If you don’t know about DH exchange, you can use the following staining diagram to understand it metaphorically.

An additional step compared to DH is that after each of them has figured out the shared secret-redacted address A, they can’t use it as the private key, because Alice also knows A. It is necessary to construct the consumer private key p = m + hash(A), and treat A as a public key. As mentioned earlier, the root consumer private key m is known only to Bob, so Bob becomes the sole controller of the stealth address. **

Obviously, with this method of private transfers, every time the recipient receives a new transaction, the funds for that transaction will flow into a brand new EOA address. The receiver can use the root consumption private key to calculate the consumption private key of each address separately to see which one is really related to him.

But now there is another problem, this newly generated stealth address is still an EOA account at the beginning, there may be no gas tokens such as ETH on it, Bob has no way to directly initiate transactions, ** need to use the Paymaster function of the smart contract wallet for gas payment, in order to achieve private transactions. **Therefore, it is necessary to make some changes to the receiving address:

Calculate a counterfactual address using the address calculation method in the CREATE2 method when the contract is deployed, with the corresponding parameters (setting the stealth address A as the owner of the contract, etc.). This is a calculated contract address, but the contract has not yet been deployed, and it is still EOA for the time being.

**Alice will transfer money directly to the Counterfactual address. **When Bob wants to use it, he can create a contract wallet directly on this address, so that he can call the gas payment service (this step can also be done by Alice or Particle network on his behalf).

We can call the above Counterfactual address a smart stealth address. Bob uses the following process to anonymously use the assets under the Smart Cloak address:

Recharge Paymaster through any of your own addresses, and Paymaster will return a proof of funds (ZK).

With the AA mechanism, send a UserOperation to the Bundler node with any other address (can have no balance) to call the assets under the above hidden address. Bob simply provides proof of funds to Paymaster with a new address, and Paymaster pays for the Bundler packaging transaction.

This is actually similar to how Tornado Cash works, through proof-of-funds (ZK), which can prove that there was a top-up in the set of leaf nodes on the Merkle tree, and no one can know which leaf node was consumed when it was spent, so as to cut off the connection between the consumer and the depositor.

To sum up, Particle combines AA and hidden addresses, and cleverly realizes private transfers in the form of smart hidden wallets.

Particle Chain & Full Chain Account Abstraction

Particle Chain is a POS chain designed for Omnichain Account Abstraction. Focusing on the current situation and the future, it is impossible to be a single-chain world, and it is crucial to improve the user experience in a multi-chain working environment.

At present ERC4337 account abstraction system will have certain problems in the case of multi-chain:

The address of the same user in different chains may not be uniform, depending on the design of the contract.

Users need to manually repeat management operations between multiple chains to manage contract wallets on different chains, such as changing administrators. Worse yet, if administrator privileges are updated on one chain and then the old admin authentication method is discarded, the wallet cannot be changed on other chains.

To use different chains, you need to have gas coins in each chain, or have pre-deposited funds in Paymaster on each chain. There is also a certain amount of trouble for developers, if they want users to use or implement other functions at zero cost under certain conditions, they also need to deploy their own custom Paymaster on each chain and deposit funds in it.

Particle Chain’s full-chain account abstraction addresses the above pain points:

Build an AA wallet on Particle Chain.

Through the AMB (Arbitrary Message Bridge) cross-chain protocol such as LayerZero, various operations, such as new creation, upgrade, change permissions, etc., are synchronized to other chains. **It can be understood that other wallets on the chain are references to the wallets on the chain, and only the main body needs to be modified to be synchronized to all wallets.

**Deployer Contract with consistent parameters to ensure that the wallet address on each chain is the same. **

Wallets between chains can also call each other through AMB, not all of which are initiated from Particle Chain.

**Issuance of Unified Gas Token, a full-chain gas coin. **ERC20 is implemented by the Paymaster mechanism as a gas fee. Even if there is no gas or Paymaster pre-deposited funds on a certain chain, you can initiate a cross-chain transaction on an eligible chain to consume Unified Gas Token.

In addition to the above uses, Particle Chain may also be used in the future:

A decentralized network generated by zkWaaS’s Proof and Salt.

The incentive layer of each chain Bundler helps Bundler achieve better decentralization.

A Solver network as an Intent Fusion Protocol.

In the narrative of Particle Chain, Unified Gas Token is the core value grasp of the entire ecosystem:

The function of paying gas fees is a strong demand and value capture logic that has been repeatedly verified in crypto.

Unified Gas Token abstracts the concept of gas layer from the existing public chain ecology, and this abstraction cannot be achieved without Particle Chain and wallet, so Unified Gas Token is a value withdrawal of the entire ecology of Particle. With the gas layer, the user interaction and growth of each chain and the value of the local currency are mutually beneficial and symbiotic with the Unified Gas Token.

Unified gas is also one of the driving factors for the realization of Chainless. For users, paying in a single currency highly simplifies the process and understanding costs. In the future, even in the multi-chain scenario, users are likely to be insensitive, and do not need to care about the operation of the underlying infrastructure. Just like currently in Web2, we don’t care which region the computer room is located in, what configuration, what language is used, and what database works.

The users imported by the dApp directly empower the Unified Gas Token, and the usage scenarios are very rich.

Intent Fusion Protocol

Usually, we need to constantly think about the path of use when using various dApps:

If there is no liquidity on one DEX, you need to look at another DEX.

I don’t know which dApp of the same category should choose to better complete the transaction or transaction.

· Approve then has a lot of features to use, and what is approve?

Wallet dusting, multiple small tokens into a certain currency, the process is cumbersome.

In order to achieve the final goal, it takes multiple applications. Such as high-leverage lending: swap, pledge, borrow, get Token and then swap, pledge, borrow…

The above is just the tip of the iceberg in our current DeFi world, and in the era of Web3 mass adoption where dApps are becoming more diverse, interactions can be much more complex than you think.

Therefore, replacing specific operation steps with intent intent can be very different for the user experience. Intent is more than operational, just as declarative programming is to functional programming. Declarative statements tend to feel simple and straightforward, just declare what I’m going to do and don’t care about the details, and this requires a variety of functional programming statements that are encapsulated at the bottom.

Then the use of Intents is no exception, and it also needs to be supported by a range of facilities. Let’s take a look at the whole process:

**1. The user submits to the Solver network in the form of RFS (Request For Solver), such as natural language. **Solver is an interpreter of intent, and there are aggregators such as 1inch that can find the best dex for users, but they are not generic and powerful enough compared to our vision.

**2. Multiple Solvers respond to each other, and they are in competition. These responses are written in the Intent DSL language and parsed by the client into a form that is easy for the user to understand. These responses consist of Input Constraints and Output Constraints, which define the boundaries between input and output. Users can also specify their own constraints. A simple example to understand: when using Swap, the user will be prompted to the minimum amount that can be obtained after swapping, which is a constraint. The user chooses among the responses of multiple Solvers on their own.

3. Sign the Intent.

**4.The Solver specifies a specific execution contract utor and submits the intent to the response contract Reactor. **

5. Reactor collects the required input (such as an asset) from the user account, submits an intent to utor, and then calls the relevant logical contract to return the output of the transaction to Reactor. The reactor checks the constraints and returns the output to the user if it is correct.

We can think of this process as you tell ChatGPT about the requirements, no matter how complex the requirements, he can generate a final result for you, as long as you are satisfied with the results, you can use it directly, without caring about the process.

Summary

Particle Network proposes a comprehensive solution: through the trinity of zkWaaS, Particle Chain, and Intent Fusion Protocol, Web2 OAuth privacy login, private transactions, full-chain account abstraction, and intent transaction paradigms are realized. Each feature will cover some of the pain points of Web3 use, and these advancements and optimizations will become the product and technology foundation for the mass adoption of Web3 in the future. In terms of ecology and business model, the B2B2C paradigm is adopted, WaaS is used as the entrance to drive the large-scale standardization of the entire product chain, and the ecosystem is built with dApp developers to jointly create a Web3 world with low threshold and high experience for users.

Of course, different projects have different understandings of the implementation path of Web3 mass adoption. In addition to the review of specific projects, we hope to lead to an understanding of the onboard friction that Web3 is currently facing, a reflection on user needs and pain points, and a consideration for the joint connection and development of the entire ecosystem.