Technical Analysis: Access Layer of Open Web built by Particle Network

Introduction: While AA wallets have significantly lowered user entry barriers and achieved gas payments and web2 account logins, aspects related to mass adoption, such as confidential login, confidential transactions, omnichain AA, and intent fusion protocol, still require further development on the foundation of AA.

Although we see various UX optimization solutions like ZenGo’s MPC wallet or smart contract wallets like Argent effectively reducing user barriers, they only address a portion of the aforementioned issues, without fully covering the overall product usability concerns.

Clearly, most AA wallets or similar products cannot yet support the widespread adoption of Web3. On the other hand, from an ecosystem perspective, the developer side is a crucial aspect. Attractiveness to regular users alone, without sufficient impact on the developer side, is unlikely to achieve scalability. The emergence of more developer experience optimization solutions indicates the growing importance of the developer side in the product ecosystem.

Taking Particle Network as an example, we will elaborate on the current UX challenges faced by Web3 products and discuss how to design a targeted, comprehensive technical solution. This kind of integrated solution may be a necessary condition for mass adoption. Additionally, Particle’s BtoBtoC business strategy serves as a noteworthy approach that many project teams may find beneficial.

Particle Product Structure Breakdown

Particle Network, with its core focus on lowering usage barriers, adopts a B2B2C product construction and ecological development approach, providing a comprehensive solution for the widespread adoption of Web3. Its core modules consist of three key components:

zkWaaS refers to zero-knowledge wallet-as-a-service. Developers can quickly integrate smart wallet modules into their dApps using Particle’s SDK. The wallet is a keyless smart contract wallet based on account abstraction, enabling gas payments and offering Web2-style OAuth confidential login and confidential transactions.

Particle Chain - The dedicated Omnichain Account Abstraction scheme designed for Particle aims to address cross-chain deployment, maintenance, and invocation challenges for smart contract wallets. It also includes the Unified Gas Token, simplifying the use of different gas tokens in multi-chain transactions.

Intent Fusion Protocol - Includes a concise Domain-Specific Language (DSL), Intent framework, Intent Solver Network, etc., to construct a Web3 interaction framework based on intent. Users declare their transaction intentions directly rather than executing each specific operation, freeing them from intricate path considerations and reducing the need to comprehend complex underlying infrastructure.

zkWaaS - Zero-Knowledge Wallet-as-a-Service

On the wallet side, Particle primarily provides SDKs for dApp developers in the form of Wallet-as-a-Service (WaaS). The aim is to enable developers to integrate into its comprehensive Web3 mass adoption framework. This BtoBtoC approach holds several advantages from both a business and ecosystem perspective:

The consumer wallet market is highly competitive, and functionalities are becoming increasingly similar. Consumer wallets are no longer the optimal entry point. On the other hand, dApp developers prefer integrating wallets within their applications to enhance user experience and provide more customizable features.

Acquiring users on the consumer side is costly, but the business side differs. WaaS’s user growth primarily stems from dApps integrated with the SDK. With effective business development and developer relations, the ecosystem can expand organically.

Current consumer wallets primarily focus on finance and assets, which may not represent the main scenarios for the future of Web3. To achieve widespread Web3 adoption, foundational features like user identity (accounts) and user operations (transaction initiation) must be abstracted as a fundamental service, leaving richer scenarios to be handled by dApps.

Historically, the entrance point for dApps has shown a close relationship between wallets and dApps. Increasing the wallet’s market share on the dApp side is crucial. This is particularly advantageous for the B2B2C model.

To construct a solution that meets user needs, lowers entry barriers, and facilitates developer integration, Particle’s zkWaaS serves as a pivotal component with three core features:

1. Confidential Login: Leveraging traditional Web2 login methods such as OAuth verification from platforms like Twitter, Google, WeChat, etc., on the smart contract wallet. This enables users to completely free themselves from the constraints of private key management, entering Web3 in the most familiar and straightforward manner. Simultaneously, user identity is concealed using zero-knowledge proofs.

2. Confidential Transactions: Implementing point-to-point privacy transfers through the Smart Stealth Address mechanism, ensuring universal privacy in transactions. Additionally, utilizing ERC-4337’s Paymaster enables gasless usage of assets for Smart Stealth Addresses (gas sponsorship).

3. Comprehensive AA Wallet Functionality: Particle’s wallet module fully complies with the fundamental requirements of ERC-4337. It includes essential components such as Bundler, EntryPoint, Paymaster, Smart Wallet Account, and more, covering all critical aspects of the ERC-4337 workflow. This one-stop solution effectively satisfies the functional demands of DApps or users for smart wallets.

Confidential Login for On-Chain Wallets Based on Web2 Accounts

Particle’s confidential login solution utilizes JSON Web Tokens (JWT), enabling Web2 identity authentication and wallet operations within the smart contract.

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

(Source: FlutterFlow Docs)

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

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

·”aud” (Audience): Specifies the service or application for which the JWT is intended. For example, when logging into Medium using Twitter, the JWT issued by Twitter will include this field indicating its applicability to Medium.

·”sub” (Subject): Refers to the user identity receiving the JWT, typically identified by UID.

In practice, “iss” and “sub” generally remain constant to avoid substantial confusion between internal systems and external references. Therefore, these parameters can be used by the contract to determine user identity, eliminating the need for users to generate and safeguard private keys.

Corresponding to JWT is the concept of JSON Web Key (JWK), a set of key pairs on the server. When issuing JWT, the server signs it with the private key of JWK, while the corresponding public key is made public for other services to verify the signature.

For example, when Medium uses Twitter for login, Medium will validate the JWT using Google’s public JWK to confirm its authenticity – that it was indeed issued by Google. The contract’s verification of JWT will also involve the use of JWK.

The process of Particle’s confidential login solution is depicted in the diagram below:

We will skip the specific ZK circuit here, just highlighting some key points in the process:

The Verifier contract validating login information will only perceive a ZK Proof related to the user’s identity JWT and an eph_pk. It cannot directly acquire the corresponding wallet public key or JWT information, ensuring user privacy, and preventing external entities from identifying 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 wallet’s public-private key pair. Users need not concern themselves with it.

This system supports off-chain verification and can be used for contract wallets employing logic such as MPC (Multiparty Computation).

As this is a contract verification solution genuinely based on traditional login methods, users can also designate other social contacts as guardians in extreme cases, such as the Web2 account being deactivated.

Confidential Transactions Based on DH Key Exchange

Before discussing Particle’s confidential transactions, let’s examine how to achieve confidential transactions for the recipient within the existing EVM system, specifically hiding the recipient’s address.

Assuming Alice is the sender and Bob is the recipient, both parties share some common knowledge:

1. Bob generates a root spending key (m) and a stealth meta-address (M). M can be generated by m, and their relationship is represented by M = G * m, indicating a mathematical relationship in cryptographic operations.

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

3. Alice generates an ephemeral private key (r) and uses the algorithm generate_address(r, M) to create a stealth address (A). This address serves as a dedicated stealth address prepared for Bob, with Bob gaining control once assets are received.

4. Alice generates an ephemeral pubkey (R) based on the ephemeral private key r and sends it to the ephemeral pubkey recording contract (or any mutually agreed-upon location that Bob can access).

5. Bob periodically scans the ephemeral pubkey recording contract, recording every updated ephemeral pubkey. Since the ephemeral pubkey contract is public and contains keys related to privacy transactions sent by others, Bob doesn’t know which one Alice sent for him to see.

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

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

The described process simplifies many complex mathematical operations. The entire information exchange process is akin to two secret agents writing cryptic messages on a public bulletin board, messages only decipherable by each other. Although the generation and decryption methods of these messages are public, crucial data necessary for both agents is known only to them. Consequently, even if outsiders understand the methods, successful decryption remains elusive.

This exchange process is somewhat analogous to the well-known Diffie–Hellman key exchange method. Without revealing their secrets (Bob’s root spending key (m) and Alice’s ephemeral private key (r)), both parties can compute a shared secret – the stealth address (A) mentioned earlier. If unfamiliar with DH exchange, the metaphorical understanding can be facilitated using the diagram below.

A step added compared to DH is that, after calculating the shared secret – stealth address (A), it cannot be used as a private key directly because Alice also knows A. It is necessary to construct the spending key (p = m + hash(A)) treating A as a public key. As mentioned earlier, only Bob knows the root spending key (m), making Bob the sole controller of this stealth address.

Clearly, in this privacy transfer method, for each new transaction received, the funds will flow into a brand new EOA address. The recipient can use the root spending key to iteratively calculate the spending key for each address, experimenting to find the one genuinely associated with them.

However, there is still an issue. Initially, this newly generated stealth address is still an EOA account and may lack ETH or other gas tokens. Bob cannot initiate transactions directly and needs to use the Paymaster of a smart contract wallet for gas payment to achieve confidential transactions. Therefore, some modifications are required for the recipient address:

Using the address calculation method from the CREATE2 function during contract deployment, along with the corresponding parameters (setting the stealth address A as the owner of the contract, etc.), calculate a Counterfactual address. This is a computed contract address not yet deployed, currently an EOA.

Alice directly transfers funds to this Counterfactual address. When Bob wants to use it, he directly creates a contract wallet at this address, enabling the invocation of the gas payment service (this step can also be handled by Alice or the Particle network in advance).

We can refer to the aforementioned Counterfactual address as a Smart Stealth Address. Bob anonymously uses assets under this Smart Stealth Address through the following process:

·Deposit Paymaster from any of his addresses, and Paymaster will return a fund proof (ZK-based).

·With the AA mechanism, use any other address, which may have no balance, to send UserOperation to the Bundler node, invoking the assets under the mentioned stealth address. Bob only needs to provide a fund proof to Paymaster using a new address, and Paymaster pays the Bundler for transaction packaging.

This process is similar to how Tornado Cash operates. The fund proof (ZK-based) can prove that a recharge occurred in the set of leaf nodes on the Merkle tree. When spending, however, no one can determine which specific leaf node’s funds were consumed, thereby severing the connection between the consumer and the recharger.

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

Particle Chain & Omnichain Account Abstraction

Particle Chain is a POS chain designed for Omnichain Account Abstraction. Considering both the present and the future, a single-chain dominance is unlikely. Enhancing user experience in a multi-chain scenario is crucial.

Currently, the ERC4337 account abstraction system may encounter certain issues in a multi-chain situation:

• The same user’s addresses on different chains may not be uniform, depending on the contract’s design.
• Managing different chain contract wallets requires manual operations across multiple chains, such as changing administrators. In worse scenarios, if administrator permissions are updated on one chain, followed by discarding the old administrator validation method, it becomes impossible to make changes on other chains, rendering the wallet unusable.
• Using different chains requires having gas tokens for each chain, or pre-stored funds in the Paymaster of each chain. For developers, this can be troublesome. If they want users to use certain conditions at zero cost or implement other functions, they need to deploy their custom Paymasters on each chain and pre-fund them.

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

• Establish AA wallets on Particle Chain.
• Use LayerZero and other Arbitrary Message Bridge (AMB) cross-chain protocols to synchronize various operations, such as creating, upgrading, and changing permissions, to other chains. It can be understood as wallets on other chains being references to the wallet on that chain, with modifications to the main body syncing to all wallets.
• Ensure uniform addresses for wallets on each chain through a consistent parameter Deployer Contract.
• Wallets on different chains can also call each other through AMB, not necessarily initiated from Particle Chain.
• Issue Unified Gas Token. The Paymaster mechanism implements ERC20 as gas fees. Even on a chain without gas or pre-stored funds in Paymaster, cross-chain transactions consuming unified gas tokens can be initiated on compliant chains.

In addition to the above-mentioned use cases, Particle Chain might also be utilized for:

• The decentralized network for zkWaaS proofs and salt generation.
• Incentive layers for Bundlers across different chains, aiding Bundlers in achieving greater decentralization.
• Serving as the solver network for the Intent Fusion Protocol.

In the narrative of Particle Chain, the unified gas token serves as a core value proposition for the entire ecosystem:

• The functionality of paying gas fees is a repeatedly validated strong demand and value capture logic in the crypto space.
• The Unified Gas Token abstracts the concept of gas layers from existing public chain ecosystems. This abstraction, without Particle Chain and wallets, cannot be achieved. Therefore, the unified gas token represents a realization of value for the entire Particle ecosystem. With the gas layer, user interaction, growth, and the native token’s value across different chains are in a mutually beneficial relationship with the unified gas token.
• Unified gas is also one of the driving factors for achieving Chainless. For users, using a single currency highly simplifies the usage process and understanding of costs. In the future, even in a multi-chain scenario, users might be unaware and not need to concern themselves with the operation of underlying infrastructure. Similar to how, currently on Web2, we interact with servers without caring about the location of data centers, their configurations, or the languages and databases they use.
• Users imported by dApps directly empower the unified gas token, offering a wide range of use cases.

Intent Fusion Protocol

Typically, when using various dApps, users constantly need to consider the usage paths:

• If there’s no liquidity on one DEX, it’s necessary to check another DEX.
• Choosing the most suitable dApp within the same category for a transaction or task.
• Understanding the concept of “Approve” before being able to use many features.
• Dusting off wallets, converting multiple small-token amounts into a specific token - a tedious process.
• Completing multiple steps across different applications to achieve a final goal. For example, in high-leverage lending: swapping, staking, borrowing, obtaining tokens, then swapping again, staking, and borrowing.

The content above represents only a glimpse into the current DeFi landscape, and as we move into the era of widespread adoption of diverse dApps in Web3, the complexity of interactions may far exceed our imagination.

Therefore, replacing specific operational steps with intents brings a vastly different experience for users. Intents, compared to operations, are akin to declarative programming versus functional programming. Declarative statements often give a straightforward feeling, requiring only a declaration of what needs to be done without concerning oneself with the subsequent details. This necessitates various levels of encapsulated functional programming statements in the underlying layers.

Similarly, using Intents requires support from a series of facilities. Let’s examine the entire process:

1. Users submit their Intents, describing them in some way, such as natural language, in the form of RFS (Request For Solver), submitted to the Solver network. The Solver is an interpreter for intents, and common solvers like 1inch, an aggregator, seeking the optimal DEX for users. However, these Solvers, in comparison to our vision, may not be versatile and powerful enough.

2. Multiple Solvers respond, competing with each other. These responses are written in the Intent DSL language, later 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. A simple example for understanding: when using Swap, the user is prompted with the minimum amount they can receive after swapping, which is a form of constraint. Users choose from responses provided by 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 (such as a specific asset) from the user’s account, submits the intent to the Executor, and after calling the relevant logic contract, returns the output of the transaction to the Reactor. The Reactor checks the constraints and, if correct, returns the output to the user.

We can envision this process as if you are explaining your requirements to ChatGPT. Regardless of 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 concerning yourself with the underlying process.

Conclusion

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, privacy transactions, omnichain account abstraction, and an intent-based transaction paradigm. Each feature addresses a part of the pain points in Web3 usage. These advancements and optimizations will serve as the foundation for the future widespread adoption of Web3 products and technologies. In terms of ecosystem and business models, adopting the B2B2C paradigm, using WaaS as the entry point to drive the entire product chain’s scalability and standardization, co-building the ecosystem with dApp developers, and jointly creating a low-threshold, high-experience Web3 world for users.

Of course, different projects have varying interpretations of the implementation path for Web3 mass adoption. Apart from scrutinizing specific projects, we hope to use different solutions to highlight the understanding of the onboarding friction faced by Web3 currently, the contemplation of user needs and pain points, and the considerations for the collective connection and development of the entire ecosystem.

Disclaimer：

1. This article is reprinted from [极客 Web3], All copyrights belong to the original author [雾月，极客Web3]. If there are objections to this reprint, please contact the Gate Learn team, and they will handle it promptly.
2. Liability Disclaimer: The views and opinions expressed in this article are solely those of the author and do not constitute any investment advice.
3. Translations of the article into other languages are done by the Gate Learn team. Unless mentioned, copying, distributing, or plagiarizing the translated articles is prohibited.