About Particle's zkWaas and Privacy Transactions - Technical Interpretation of Privacy Login, Omni-chain AA, and Intent Framework.

Author: Foggy, Geek Web3

Introduction: Although AA wallets have greatly reduced the user's usage threshold and initially realized gas payment and web2 account login, the design related to privacy login, privacy transactions, omni-chain unified AA accounts, and Intent dedicated architecture, which are related to mass adoption, still need to be improved on top of AA.

Although we can see many UX optimization solutions, such as ZenGo and Argent, which effectively reduce the user's 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 an ecological perspective, the developer side is a very important aspect. It is difficult to form a scale if the product is only attractive to ordinary users but lacks influence on the developer side. The emergence of more and more development experience optimization solutions has already indicated the important significance of the developer side for the product ecosystem.

We will take Particle Network as an example to 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 happens to be a train of thought that many project parties need to learn from.

Particle Product Structure Fully Explained

Particle Network focuses on solving the usage threshold as the core, using a B2B2C product construction and ecological development approach, and has proposed a set of solutions for the large-scale adoption of Web3. Its core modules are three:

zkWaaS, a Wallet-as-a-service (WaaS) service based on zero-knowledge proof. Developers can quickly integrate the smart wallet module into their dApps 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 omni-chain account abstraction (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, which includes a concise Domain Specific Language (DSL) 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's Smart Wallet as a Service

On the wallet side, Particle mainly provides SDKs for dApp developers in the form of WaaS (smart contract wallet as a service) 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 functionality is relatively similar. Consumer wallets are no longer a good entry point. On the other hand, dApp developers are increasingly inclined to embed wallets within dApps to avoid the user experience loss caused by connecting wallets and switching wallets during transactions, and to provide more customizable features.

The cost of acquiring consumers 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 good business development and developer relationships are established, 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, there must be projects that abstract more basic features—user identity (account) and user operations (sending transactions/trades)—as a fundamental service, leaving the richer scenarios to dApps.

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

Building a WaaS that meets user needs, reduces usage thresholds, 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 such as Twitter, Google, WeChat login, etc., on the smart contract wallet, allowing 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, using zero-knowledge proof to hide user identity.

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 without gas (gas sponsor).

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, meeting the one-stop needs of DAPPs or users for smart wallets.

Web2 account-based on-chain wallet privacy login

Particle's privacy login solution uses JWT (Json Web Token), which can perform Web2 identity authentication and wallet operations within the contract.

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

(Image source: FlutterFlow Docs)

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, for example, when logging into Medium using Twitter, the "aud" field in the JWT issued by Twitter will specify that the JWT is applicable to Medium.
• "sub" (Subject), referring to the identity of the user receiving the JWT, generally identified by a UID.

In practice, "iss" and "sub" 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, allowing users to completely avoid generating and safeguarding private keys.

The concept corresponding to JWT is JSON Web Key (JWK), which is a set of key pairs on the server. When issuing JWT, the server signs it with the private key of the 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 the JWK.

The privacy login process of Particle is shown in the following diagram:

Specific ZK circuits are omitted here. Only some key points in the process are listed:

• The Verifier contract that verifies login information will only perceive a ZK Proof related to the user's identity (JWT) and a harmless eph_pk, without directly knowing the corresponding wallet public key or JWT information. This protects user privacy, preventing outsiders from knowing the identity of the login from on-chain data.
• eph_pk (ephemeral public key) is a key pair used in a single session and is not the public-private key pair of the wallet, and users do 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 designate other social contacts as their guardians in case of extreme situations such as the deactivation of their Web2 accounts.

Privacy Transactions Based on DH Key Exchange

Before discussing Particle's privacy transaction solution, let's first consider 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 mutually agreed location, as long as Bob can access it).

5. Bob needs to regularly scan the temporary public key record contract and record every 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 was 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 that address, it means that Alice generated and authorized it for Bob's control; otherwise, it is unrelated to Bob.

7. Bob uses generate_spending_key(R, m) to generate the spending key for that 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 bulletin 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 necessary in the middle, so outsiders cannot decrypt them successfully.

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

One additional step compared to DH is that 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 that 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 is initially an EOA account, which may not have ETH or other gas tokens. Bob cannot initiate transactions directly and needs to use the Paymaster function of the smart contract wallet to pay for gas, enabling privacy transactions. Therefore, some modifications need to be made to the receiving address:

Using the address calculation method in the contract deployment CREATE2 method, 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 that address, enabling the use of the gas payment service (this step can also be done by Alice or the Particle network in advance).

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

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

Using the AA mechanism, send UserOperation to the Bundler node from another arbitrary address (which may have no balance) to invoke operations under the stealth address. Bob only needs to provide a fund proof to the Paymaster from a new address, and the Paymaster will pay the Bundler for transaction packaging fees.

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 severing the connection between the spender and the depositor.

In summary, Particle cleverly achieves privacy transfers through the combination of AA and stealth addresses in the form of intelligent 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 impossible for a single chain to dominate, and improving user experience in a multi-chain environment is crucial.

Currently, the ERC4337 account abstraction system faces certain issues in a multi-chain scenario:

• 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 case scenario, if administrator permissions are updated on one chain and the old administrator verification method is discarded, it will not be possible to make changes on other chains or use the wallet.
• Using different chains requires owning gas tokens for each chain or having pre-deposited funds on Paymasters on each chain. This also poses some inconvenience for developers, as they would need to deploy their custom Paymasters on each chain and pre-deposit funds for zero-cost usage or other functionalities under certain conditions.

Particle Chain's Omnichain Account Abstraction addresses the above pain points:

• Establish an AA wallet on Particle Chain.
• Through LayerZero and other Arbitrary Message Bridge (AMB) cross-chain protocols, synchronize various operations such as creation, upgrade, and permission changes to other chains. This means that wallets on other chains are references to the wallet on that chain, and modifications to the main entity will be synchronized to all wallets.
• Ensure 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.
• Issue Unified Gas Token, a cross-chain gas token. Implemented by the Paymaster mechanism, it acts as an ERC20 token for gas fees. Even if there is no gas or pre-deposited funds on a particular chain, cross-chain transactions consuming Unified Gas Token can be initiated on eligible chains.

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

• Decentralized networks for generating proofs and salts for zkWaaS.
• Incentive layers for various chain Bundlers to help achieve better decentralization.
• Serving as the 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. This abstraction, without Particle Chain and wallets, would not be possible, making the Unified Gas Token a realization of value for the entire Particle ecosystem. With the gas layer, user interactions and growth on various chains, as well as the value of the native token, 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 costs. 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 currently in Web2, we interact with servers without caring about which region the data center is located in, its configuration, or the language and database it uses.

Intent Fusion Protocol

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

• If a certain liquidity is not available on one dex, we need to check another dex.
• It's unclear which dApp in the same category is better for completing a transaction or operation.
• Many functions require approval before use, but what is approval?
• Dusting the wallet, converting multiple small tokens into a single token is a cumbersome process.
• Multiple applications are required to achieve the final goal. For example, for high-leverage borrowing: swap, collateralize, borrow, swap the obtained tokens again, collateralize, borrow…

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 expectations.

Therefore, using Intent instead of specific operational steps makes a huge difference for users. 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 at the lower levels.

Similarly, using Intent also requires support from a series of facilities. Let's take a 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 optimal dex for users. However, they are not as universal and powerful as our vision.

2. Multiple Solvers respond, and they compete with each other. These responses are written in the Intent DSL language and then parsed by the client into a form that is easy for the user to understand. These responses contain Input Constraints and Output Constraints, defining the boundaries of input and output. Users can also specify constraints themselves. A simple example to understand: when using Swap, the user will be 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. Sign 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, which then 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 explaining your requirements to ChatGPT. No matter how complex the requirements are, it can generate a final result for you. As long as you are satisfied with the result, you can use it directly without worrying about the process.

In summary, Particle Network has proposed a comprehensive solution: through the integrated form of zkWaaS, Particle Chain, and Intent Fusion Protocol, it achieves Web2 OAuth privacy login, private transactions, omnichain account abstraction, and intent trading paradigm. Each feature will address some pain points in Web3 usage, and these advancements and optimizations will become the product and technological foundation for the large-scale adoption of Web3 in the future. In terms of ecology and business models, adopting the B2B2C paradigm, driving the entire product chain to scale and standardization through WaaS as an entry point, 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，本平台相关工作人员将会进行核查。