Author: Wuyue, Geek Web3

Lead: Although the AA wallet has greatly reduced the user's threshold, initially realized gas payment and web2 account login, but the design related to mass adoption such as privacy login-privacy transaction, unified AA account for the entire chain, Intent-specific architecture, still needs to be improved on the basis of AA.

Although we can see many UX optimization solutions, such as ZenGo and Argent, which effectively reduce the user threshold, they only solve part of the above-mentioned problems, and do not comprehensively cover the product's usability issues.

Obviously, most AA wallets or similar products currently cannot support the large-scale adoption of Web3. On the other hand, from the perspective of the ecosystem, the developer side is a very important aspect. Only being attractive to ordinary users in the product, but not influential enough on the developer side, it is difficult to form a scale. The emergence of more and more development experience optimization solutions has already indicated the important significance of the developer side for the product ecosystem.

Taking Particle Network as an example, we will explain in detail the current problems in the experience of Web3 products and how to design a comprehensive technical solution targetedly. This comprehensive solution may be the necessary condition for mass adoption. At the same time, Particle's BtoBtoC business strategy is also a train of thought that many project parties need to learn from.

Particle Product Structure Fully Explained

Particle Network takes solving the user threshold as the core, builds a B2B2C product and ecological development strategy, and proposes a set of solutions for the large-scale adoption of Web3. Its core modules are three:

zkWaaS, Wallet-as-a-service based on zero-knowledge proof. Developers can quickly integrate the smart wallet module into their dApp based on the SDK provided by Particle. This wallet is a keyless smart contract wallet based on account abstraction, which can not only realize basic AA scenarios such as gas payment, but also provide Web2-style OAuth privacy login and privacy transaction functions.

Particle Chain—specifically designed for Particle's omnichain account abstraction solution, dedicated to solving the cross-chain deployment, maintenance, and invocation issues of smart contract wallets. It is accompanied by a universal gas token (Unified Gas Token) to solve the trouble of using different gas currencies in multi-chain transactions.

Intent Fusion Protocol, including a concise DSL (Domain Specific Language) language, Intent framework, Intent Solver Network, etc., is used to build a Web3 interaction framework based on intent, allowing users to declare their transaction intent directly rather than executing each specific operation, freeing users from cumbersome path thinking and reducing the need to understand complex underlying infrastructure.

zkWaaS—Combining ZK with smart wallet as a service

On the wallet side, Particle mainly provides SDK as WaaS (smart contract wallet as a service) to dApp developers, in order to enable developers to access its complete Web3 mass adoption framework. This BtoBtoC solution has several advantages from a business and ecological perspective:

The competition for consumer wallets has become intense, and the functions are relatively similar. Consumer wallets are no longer a good entry point. On the other hand, dApp developers are increasingly inclined to embed wallets in dApps to avoid the user experience loss caused by connecting wallets and switching wallets during transactions, and to provide more customizable functions.

The cost of acquiring customers on the consumer side is high, but it is different on the business side. The user growth of WaaS mainly comes from dApps that have integrated the SDK. As long as the business development and developer relationships are well managed, the entire ecosystem can be expanded in a "surrounding the city from the countryside" manner.

Currently, consumer wallets mainly focus on finance and assets, and it is difficult to say that this is the main scenario for Web3 in the future. To achieve the large-scale adoption of Web3, it is necessary for projects to abstract more basic features—user identity (account) and user operations (sending transactions/trades) as a fundamental service, and leave the richer scenarios to dApps.

From the previous dApp entry point, it can be observed that there is a close binding relationship between wallets and dApps. It is crucial to maximize the market share of wallets on the dApp side. This is particularly important for the B2B2C model.

Building a WaaS that meets user needs, reduces the user threshold, and is easy for developers to access is another pillar of the successful solution. Particle's zkWaaS has three cores:

1. Privacy login. Using traditional Web2 login methods on the contract wallet, such as Twitter, Google, WeChat login, and other OAuth verification methods, allows users to completely free themselves from the shackles of private key management and enter Web3 in the most familiar and simple way. At the same time, user identity is hidden using zero-knowledge proof.

2. Privacy transactions. Implementing peer-to-peer universal privacy transfers through the Smart Stealth Address mechanism, and using ERC4337's Paymaster to allow stealth addresses to use assets (gas sponsors) without gas.

3. Complete AA wallet functionality. 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 the ERC-4337 workflow, providing one-stop satisfaction for DAPPs or users' smart wallet functional requirements.

Chain-based wallet privacy login based on web2 account

Particle's privacy login solution uses JWT (Json Web Token) for web2 identity authentication and wallet operations within the contract.

JWT is a widely used identity proof issued by the server to the client in the traditional Internet, and the client uses this proof for identity authentication in each interaction with the server.

There are several key fields in JWT that form the basis for contract identity verification:

· "iss" (Issuer), indicating the issuer of the JWT, i.e., the server, such as Google, Twitter, etc.

· "aud" (Audience), indicating the service or application used by the JWT, such as using Twitter login when logging into Medium, then Twitter will specify in the JWT that it is applicable to Medium.

· "sub" (Subject), which refers to the user identity that accepts the JWT, generally indicated by UID.

In practice, the "iss" and "sub" parameters will not change in the vast majority of cases, as it would cause significant confusion between internal systems and external references. Therefore, these parameters can be used by the contract to determine the user's identity, so the user does not need to generate and keep private keys.

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

For example, when using Twitter to log in to Medium, Medium will verify the JWT using Google's public JWK to confirm the authenticity of the JWT—confirming that it was indeed issued by Google. The contract's verification of the JWT will also use JWK.

The process of Particle's privacy login scheme is as shown in the following diagram:

The specific ZK circuit is omitted here. Only some key points in the process are listed:

· The Verifier contract that verifies the login information will only perceive a ZK Proof related to the user's identity-JWT, and an innocuous eph_pk, and cannot directly obtain the corresponding wallet public key or JWT information. This protects the user's privacy, preventing external parties from knowing the identity of the login user from on-chain data.

· eph_pk (ephemeral key pair) is a key pair used in a single session and is not the public-private key pair of the wallet, and the user does not need to be concerned about it.

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

As this is a contract verification solution based on traditional login methods, users can also specify other social contacts as their guardians in case of extreme situations such as the deactivation of their Web2 account.

Privacy transactions based on DH key exchange method

Before discussing Particle's privacy transaction scheme, let's first examine how to achieve privacy transactions for the recipient within the existing EVM system, i.e., hiding the recipient's address.

We assume that Alice is the sender and Bob is the recipient, and both parties have some common knowledge:

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

2. Alice obtains Bob's stealth meta-address M through any means.

3. Alice generates a temporary private key r and uses the algorithm generate_address(r,M) to generate a stealth address A. This address is the dedicated stealth address prepared for Bob, and Bob has control over this 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 location mutually recognized by both parties, as long as Bob can access it).

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

6. Bob scans each updated record and uses generate_address(R,m) to calculate the stealth address. If there are assets in this address, it means that it was generated and authorized by Alice for Bob's control, otherwise, it is irrelevant to Bob.

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

The above process simplifies many complex mathematical operations. The entire information exchange process is like two spies writing some secret messages on a public notice board that only they can decipher, although the generation and decryption methods of the secret messages are public, only the two spies know the important data required in the middle, so even if the outside world knows the generation and decryption methods of the secret messages, they still cannot decrypt them successfully.

This exchange process is roughly similar to the well-known Diffie–Hellman key exchange method, where both parties can calculate a shared secret— the stealth address A—without revealing their secrets (Bob's root spending key m and Alice's temporary private key r). If you are not familiar with the DH exchange, you can use the following colored diagram for a metaphorical understanding.

In comparison to DH, an additional step is needed. After calculating the shared secret—stealth address A, it cannot be used as a private key because Alice also knows A. It is necessary to construct the spending private key p = m + hash(A), and treat A as a public key. As mentioned earlier, only Bob knows the root spending key m, so Bob becomes the sole controller of this stealth address.

Clearly, in this method of privacy transfers, each time the recipient receives a new transaction, the funds will flow into a brand new EOA address. The recipient can use the root spending key they hold to calculate the spending private key for each address in a trial-and-error manner to see which one is truly related to them.

However, there is still a problem. The newly generated stealth address initially is still an EOA account, and may not have ETH or other gas tokens. Bob cannot directly initiate a transaction and needs to use the Paymaster function of the smart contract wallet for gas payment to achieve privacy transactions. Therefore, some modifications need to be made to the recipient address:

Using the address calculation method in the CREATE2 method during contract deployment, with the corresponding parameters (setting the stealth address A as the Owner of the contract, etc.), calculate a Counterfactual address. This is a calculated contract address that has not yet been deployed and is still an EOA for the time being.

Alice will directly transfer to this Counterfactual address. When Bob wants to use it, they can directly create a contract wallet at this address, allowing them to call the gas payment service (this step can also be done by Alice or the Particle network as a prelude).

We can refer to the above-mentioned Counterfactual address as a smart stealth address. Bob anonymously uses the assets under this smart stealth address through the following process:

· Recharge to the Paymaster from any of their own addresses, and the Paymaster will return a fund proof (ZK-ified).

· Using the AA mechanism, send UserOperation to the Bundler node from any other address (even if there is no balance), to call the assets under the stealth address mentioned above. Bob only needs to provide a fund proof to the Paymaster, and the Paymaster pays the Bundler for the transaction packaging.

This is actually similar to the working principle of Tornado Cash, where fund proofs (ZK-ified) can prove that there was a deposit in the set of leaf nodes on the Merkle tree, but no one can know which specific leaf node's funds were spent, thus cutting off the connection between the spender and the depositor.

In summary, Particle combines AA with stealth addresses, cleverly achieving privacy transfers through the form of smart stealth wallets.

Particle Chain & Omnichain Account Abstraction

Particle Chain is a POS chain designed for Omnichain Account Abstraction. Considering the present and the future, it is unlikely that there will be a single dominant chain, so improving user experience in a multi-chain environment is crucial.

The current ERC4337 account abstraction system faces certain issues in a multi-chain environment:

· The same user's addresses on different chains may not be consistent, depending on the design of the contracts.

· Managing contract wallets on different chains requires manual management and operations across multiple chains, such as changing administrators. In a worse scenario, if administrator permissions are updated on one chain and the old administrator verification method is discarded, it cannot be changed on other chains, and the wallet cannot be used.

· Using different chains requires owning gas tokens for each chain, or having pre-deposited funds on Paymasters for each chain. This also poses some inconvenience for developers, as they need to deploy their custom Paymasters on each chain and pre-deposit funds for users to use certain features at zero cost.

Omnichain Account Abstraction in Particle Chain addresses the above pain points:

· Establishing AA wallets on Particle Chain.

· Through LayerZero and other Arbitrary Message Bridge (AMB) cross-chain protocols, various operations such as creation, upgrade, and permission changes are synchronized to other chains. This means that wallets on other chains are references to the wallets on those chains, and only the main entity needs to be modified to synchronize to all wallets.

· Ensuring consistent addresses for wallets on different chains through a Deployer Contract with consistent parameters.

· Wallets on different chains can also call each other through AMB, not necessarily initiated from Particle Chain.

· Issuance of Unified Gas Token, a gas token for the entire chain. This is achieved through the Paymaster mechanism, where ERC20 tokens act as gas fees. Even if there is no gas or pre-deposited funds on a certain chain, cross-chain transactions consuming Unified Gas Token can still be initiated on eligible chains.

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

· Decentralized network for zkWaaS proof and salt generation.

· Incentive layer for various chain Bundlers, helping Bundlers achieve better decentralization.

· Solver network for the Intent Fusion Protocol.

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

· The function of paying gas fees is a strongly validated demand and value capture logic in the crypto space.

· The Unified Gas Token abstracts the concept of a gas layer from the existing public chain ecosystem, and this abstraction cannot be achieved without Particle Chain and wallets. Therefore, the Unified Gas Token represents a realization of value for the entire Particle ecosystem. With the gas layer, user interactions, growth, and the value of native tokens on various chains are mutually beneficial with the Unified Gas Token.

· Unified gas is also one of the driving factors for achieving Chainless. For users, using a single currency for payment greatly simplifies the usage process and understanding. In the future, even in a multi-chain scenario, users may be unaware and not need to be concerned about the operation of the underlying infrastructure, just as we currently interact with servers on Web2 without caring about their location, configuration, programming language, or database.

· Users directly empower the Unified Gas Token for dApp imports, and the usage scenarios are very diverse.

Intent Fusion Protocol

Usually, when using various dApps, we constantly need to consider the usage path:

· If a certain dex lacks liquidity, we need to check another dex.

· When choosing between dApps of the same category, it's unclear which one is better for completing a transaction or task.

· Many functions require approval before use, but what is approval?

· Dusting the wallet, converting multiple small token amounts into a single type of token, is a cumbersome process.

· Completing the final goal requires going through multiple applications. For example, for high-leverage borrowing: first swap, collateralize, borrow, then swap, collateralize, borrow again…

The above content is just the tip of the iceberg in the current DeFi world, and as dApps become more diverse and widely adopted in the Web3 era, the complexity of interactions may far exceed imagination.

Therefore, using Intent to replace specific operational steps makes a huge difference in user experience compared to operations. Compared to operations, Intent is like declarative programming compared to functional programming. Declarative statements often give a simple and clear feeling, as they only need to declare what needs to be done without caring about the details, and this requires various layers of encapsulated functional programming statements.

Similarly, using Intent also requires support from a series of facilities. Let's look at the entire process:

1. Users describe their intent in some way, such as natural language, and submit it to the Solver network in the form of a Request For Solver (RFS). The Solver is the interpreter of the intent, and common Solvers include aggregators like 1inch, which can find the best dex for users. However, they are not as versatile and powerful as our vision.

2. Multiple Solvers respond, and they compete with each other. These responses are written in Intent DSL language and are parsed by the client into a form that is easy for users to understand. These responses include Input Constraints and Output Constraints, defining the boundaries of inputs and outputs. Users can also specify constraints themselves. To understand this with a simple example: when using Swap, users are prompted with the minimum amount they can receive after the swap, which is a form of constraint. Users can choose from the responses of multiple Solvers.

3. Signing the Intent.

4. The Solver specifies a specific execution contract Executor and submits the Intent to the response contract Reactor.

5. The Reactor collects the required inputs from the user's account (such as a certain asset), submits the Intent to the Executor, the Executor calls the relevant logic contract, and returns the output of the transaction to the Reactor. The Reactor checks the constraints, and if there are no errors, returns the output to the user.

We can imagine this process as telling ChatGPT what you need, and no matter how complex the requirement, it can generate a final result for you. As long as you are satisfied with the result, you can use it directly without caring about the process.

Conclusion

Particle Network has proposed a comprehensive solution: through the integrated form of zkWaaS, Particle Chain, and Intent Fusion Protocol, it has achieved Web2 OAuth privacy login, privacy transactions, omnichain account abstraction, and intent-based transaction paradigm. Each feature covers a part of the pain points in Web3 usage, and these advancements and optimizations will become the product and technological foundation for the widespread adoption of Web3 in the future. In terms of the ecosystem and business model, adopting the B2B2C paradigm, using WaaS as an entry point to drive the entire product chain to scale and standardize, and jointly building the ecosystem with dApp developers to create a low-threshold, high-experience Web3 world for users.

Of course, different projects have different understandings of the path to achieving Web3 mass adoption. In addition to examining specific projects, we hope to use different solutions to bring out an understanding of the onboard friction currently faced by Web3, considerations for user needs and pain points, and the interconnected development of the entire ecosystem.

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。