导语：虽然AA钱包在很大程度上降低了用户使用门槛，初步实现了gas代付与web2账户登录，但隐私登录-隐私交易、全链统一AA账户、Intent专用架构等与mass adoption相关的设计，仍然要在AA的基础上添砖加瓦。

我们虽然能见到很多UX优化方案，如ZenGo等MPC钱包或Argent这种智能合约wallet，有效的降低了用户门槛，但他们只解决了上述问题中的一部分，而没有全方位覆盖产品易用性问题。

显然，目前大多数AA钱包或者类似产品，还无法支持Web3大规模采用。另一方面，从生态角度考量，开发者侧是非常重要的层面，仅仅在产品上对普通用户有吸引力，但在开发者侧影响力不够，很难形成规模。越来越多开发体验优化方案的涌现，已经说明开发者端对于产品生态的重要意义。

我们将以Particle Network为例，详解目前Web3产品在体验上的问题，以及如何针对性地设计一套综合的技术解决方案，而这种综合解决方案可能正是mass adoption的必要条件。同时，Particle的BtoBtoC商业策略，恰好也是许多项目方需要学习借鉴的思路。

Particle产品结构全解

Particle Network以解决使用门槛为核心，用B2B2C的产品构建与生态发展思路，针对Web3大规模采用提出了一整套解决方案。其核心模块为三个：

zkWaaS，基于零知识证明的WaaS(Wallet-as-a-service)服务。开发者可以基于Particle提供的SDK，快速将智能钱包模块集成至自己的dApp内。该钱包是基于账户抽象的keyless智能合约钱包，不但可以实现gas代付等AA基本场景，还可以提供Web2式的OAuth隐私登录方式以及隐私交易等功能。

Particle Chain——专门用于Particle的全链账户抽象（Omnichain Account Abstraction）方案，致力于解决智能合约钱包的跨链部署、维护和调用问题。配套的还有通用gas代币（Unified Gas Token），用以解决多链交易时需要用到不同gas币种的麻烦。

Intent Fusion Protocol，包含了简洁的DSL（Domain Specific Language）语言，Intent框架，Intent Solver Network等，用以构建一套基于意图(Intent)的Web3交互框架，用户直接声明自己的交易意图而非去执行每一条具体的操作，使用户摆脱繁琐的路径思考，并减少对复杂底层基础设施的理解。

zkWaaS——结合ZK的智能钱包即服务

在钱包侧，Particle主要以WaaS（智能合约钱包即服务）的形式来为dApp开发者提供SDK，以期让开发者接入其完整的Web3 mass adoption框架。这种BtoBtoC方案从商业和生态角度看有几个优点：

单纯的C端钱包竞争已经白热化，功能也较为雷同，C端钱包不再是一个好的切入点。另一方面，dApp开发者也开始越来越倾向于在dApp内内置钱包，以避免用户连接钱包、交易时需要到切换钱包等步骤的体验损耗，并提供更多可自定义的功能。

C端的获客成本高昂，但B端却不同。WaaS的用户增长主要源于集成了SDK的dApp。只要做好BD与开发者关系，就能“城市包围农村”式的扩展整个生态。

目前C端钱包主要专注于金融与资产，我们很难说这就是未来Web3的主要场景。真正要实现Web3的大规模采用，必须有项目将更基础的特性——用户身份（账户）和用户操作（发送事务/交易），抽象出来作为一个底层服务，将上层更丰富的场景交由dApp。

从以往的dApp连接入口，大家可以观察到钱包和dApp之间较为紧密的绑定关系。在dApp端尽可能提高钱包的市占率，是非常关键的。这一点对B2B2C模式而言是近水楼台先得月的。

构建一套能满足用户需求，降低使用门槛，易于开发者接入的WaaS则是方案成功的另一个支柱。Particle的zkWaaS有三个核心：

1.隐私登录。在合约钱包上利用传统Web2的登录方式，如Twitter、Google、微信登录等OAuth验证方式，让用户完全摆脱私钥管理的桎梏，以最熟悉和简单的方式进入Web3。同时利用零知识证明将用户身份隐藏。

2.隐私交易。通过智能匿踪地址(Smart Stealth Address)机制实现点对点的通用性隐私转账，并使用ERC4337的Paymaster让匿踪地址可以免gas地使用资产（gas赞助商）。

3.完备的AA钱包功能。Particle的钱包模块完全符合ERC-4337的基本要求，包含Bundler、EntryPoint、Paymaster、Smart Wallet Account 等ERC-4337工作流中的重要部分，一站式的满足DAPP或用户对智能钱包的功能需求。

基于web2账户的链上钱包隐私登录

Particle的隐私登录方案利用了JWT(Json Web Token)，可以在合约内进行Web2身份认证和操作钱包。

JWT是一种广泛运用于传统互联网中的，由服务端向客户端发放的身份证明，客户端在每次与服务端交互时凭借此证明来进行身份认证。

（图源：FlutterFlow Docs）

在JWT中有几个关键字段，是合约验证身份的基础：

·”iss” (Issuer) ，表明JWT的发行者，也即服务端，如Google、Twitter等。

·”aud” (Audience) ，表明该JWT所使用的服务或应用，如在登录Medium时使用Twitter登录，那么Twitter发行JWT时此字段会写明该JWT适用于Medium。

·”sub” (Subject) ，指的就是接受该JWT的用户身份，一般用UID标示。

在实践中，iss和sub在绝大多数情况下都不会变，否则会带来内部系统和外部引用的巨大混乱。因此，上述这些参数可用于合约确定用户身份，这样用户完全无需生成和保管私钥。

与JWT相对应的概念是JWK(JSON Web Key)，它是服务端的一组密钥对。服务端在发放JWT的时候会用JWK的私钥签名，而对应的公钥是公开的，用于给其他服务验证其签名。

比如，在Medium使用Twitter登录，Medium会对JWT用Google公开的JWK公钥进行验证，以确认该JWT的真实性——确实是由Google发放的。合约对JWT的校验也会使用到JWK。

Particle的隐私登录方案流程如下图所示：

其中具体的ZK电路我们这里先略过。只列流程中的一些重点：

·验证登录信息的Verifier合约，只会感知到一个与用户身份-JWT相关的ZK Proof，以及一个无伤大雅的eph_pk，无法直接获知对应的钱包公钥或JWT信息，这样就可以保护用户隐私，外界无法从链上数据获知登录者身份。

·eph_pk(临时密钥对)是一种在单个会话中使用的密钥对，并不是钱包的公私钥，用户也无需关心。

·这套系统也可以做链下验证，可用于使用了MPC等逻辑的合约钱包。

由于这是真正基于传统登录方式的合约验证方案，用户还可以指定其他社交联系人作为自己的守护者，以备Web2账户被销户等非常极端的情况。

DH秘钥交换方法基础上的隐私交易

在谈到Particle的隐私交易方案前，我们先考察一下如何在现有的EVM体系内，实现对接收者的隐私交易，也即隐藏接收者的地址。

我们假设Alice为发送者，Bob为接收者，双方拥有一些共同的知识：

1.Bob生成根消费私钥(root spending key) m以及匿踪元地址(stealth meta-address) M。M可以被m生成，二者关系为M = G * m，代表了一种密码学运算上的数学关系。

2.Alice通过任意一种方式，获取到Bob的匿踪元地址M。

3.Alice生成一个临时私钥r，并使用算法generate_address(r,M)生成一个匿踪地址A。该地址即为Bob准备的专属匿踪地址，Bob在收到资产后拥有对该地址的掌控权。

4.Alice再根据临时私钥r生成一个临时公钥R，并将其发送至临时公钥记录合约（或者是任何双方认可的位置，不管什么渠道只要Bob可以获取即可）。

5.Bob需要定期扫描临时公钥记录合约，记录下更新的每一条临时公钥。由于临时公钥合约是公开的，包含了其他人发送的隐私交易相关密钥，Bob还不知道哪一条是Alice发给自己看的。

6.Bob扫描每一条更新的记录，执行generate_address(R,m)来计算匿踪地址。如果该地址里有资产，那就是Alice生成并授权给Bob去控制的，否则就和Bob无关。

7.Bob执行generate_spending_key(R,m)来生成该匿踪地址的消费私钥，也即p = m + hash(A)，然后可以控制Alice生成的那个地址A。

上面的流程描述其实简化了很多复杂的数学运算，整个情报交换过程，就好比两个特务在公用的公告板上，写下一些只有彼此才能破解的暗语，暗语的生成与解密方法虽然是公开的，但只有两个特务知道中间必需的重要数据，所以外界就算知道暗语的生成与解密方法，还是无法顺利解密。

这个交换流程与著名的Diffie–Hellman秘钥交换方法大致相同，在不透露各自的秘密（Bob的根消费私钥m和Alice的临时私钥r）的情况下，双方都可以计算出共享秘密——上文中的匿踪地址A。如果对DH交换不了解可以用下面的染色图进行比喻式的理解。

相比DH需要增加的一步是，在各自算出共享秘密-匿踪地址A后，并不能用它当做私钥，因为Alice也知道A。需要构造消费私钥p = m + hash(A)，而把A当做一个公钥。由于前面提到，根消费私钥m只有Bob知道，这样Bob就成为了该匿踪地址的唯一控制者。

显然，这种方式下的隐私转账，接收者每接收一笔新的交易，该交易的资金都会流入一个全新的EOA地址。接收者可以用持有的根消费私钥，去撞运气的方式分别计算每个地址的消费私钥，看哪一个真的与他有关。

但现在还有一个问题，这个新生成的匿踪地址一开始还是EOA账户，上面可能没有ETH等gas代币，Bob没有办法直接发起交易，需要用到智能合约钱包的Paymaster功能进行gas代付，才能实现隐私交易。所以还需要对接收地址进行一定改动：

用合约部署时CREATE2方法中的地址计算方法，附带相应参数（将匿踪地址A设为该合约的Owner等），计算一个Counterfactual地址。这是一个计算出的合约地址，但尚未部署合约，暂时还是EOA。

Alice会直接向该Counterfactual地址转账。Bob想使用时，就直接在该地址上进行合约钱包创建，这样就可以调用gas代付服务（这一步也可以由Alice或Particle网络代劳前置完成）。

我们可以把上述的Counterfactual地址称为智能匿踪地址。Bob通过下列流程来匿名地使用该智能匿踪地址下的资产：

·通过自己的任意地址向Paymaster充值，Paymaster会返还一个资金证明（ZK化）。

·凭借AA机制，用其他任意地址（可以没有余额）向Bundler节点发送UserOperation，调用上述匿踪地址下的资产。Bob只要用一个新地址向Paymaster提供资金证明，Paymaster支付Bundler打包交易的费用。

这其实是类似Tornado Cash的工作原理，通过资金证明（ZK化）既可以证明梅克尔树上的叶子节点集合中曾经有一笔充值，花费时任何人却无法得知具体消耗了哪个叶子节点上的资金，以此切断消费者和充值者之间的联系。

综上，Particle结合了AA与匿踪地址，巧妙地通过了智能匿踪钱包的形式实现了隐私转账。

Particle Chain & 全链账户抽象

Particle Chain是一条为全链账户抽象(Omnichain Account Abstraction)而设计的POS链。着眼现状和未来，都不可能是单链的天下，在多链工况下提升用户体验是至关重要的。

目前ERC4337账户抽象系统在多链情况下会出现一定问题：

·同一个用户在不同链的地址有可能不统一，具体取决于合约的设计。

·用户管理不同链上的合约钱包，需要手动在多个链之间重复管理操作，如更换管理员等。更糟糕的情况，如果在一条链上更新了管理员权限随后丢弃了旧的管理员验证方式，那么在其他链上将无法变更，也无法使用钱包。

·使用不同的链，需要拥有各个链的gas币，或者在各个链的Paymaster上有预存资金。对开发者而言也有一定麻烦，如果他想让用户在一定条件下零成本使用或实现其他功能，也需要在各个链上部署自己自定义的Paymaster，并在其中预存资金。

Particle Chain的全链账户抽象针对上述痛点：

·在Particle Chain上建立AA钱包。

·通过LayerZero等AMB(Arbitrary Message Bridge)跨链协议，将各种操作，如新建、升级、更改权限等同步至其他链上。可以理解为其他链上的钱包都是该链上钱包的引用，只需要修改主体即可同步至所有钱包。

·通过一致参数的Deployer Contract来保证各链上钱包地址相同。

·各个链之间钱包也可以通过AMB互相调用，并非都要从Particle Chain发起。

·发行Unified Gas Token，全链gas币。由Paymaster机制实现ERC20充当gas费。即使在某条链上没有gas或Paymaster预存资金，也可以在符合条件的链上发起跨链交易消耗Unified Gas Token。

除了上述用途外，Particle Chain未来也许还可以用于：

·zkWaaS的Proof和Salt生成的去中心化网络。

·各链Bundler的激励层，帮助Bundler实现更好的去中心化。

·作为Intent Fusion Protocol的Solver网络。

在Particle Chain的叙事中，Unified Gas Token是整个生态中核心的价值抓手：

·支付Gas费用这一功能，是crypto中反复验证过的强烈需求和价值捕获逻辑。

·Unified Gas Token从既有的公链生态中又抽象出gas层这一概念，而这种抽象，离开了Particle Chain与钱包是无法实现的，所以Unified Gas Token是Particle整个生态的一种价值的提现。有了gas层之后，各链的用户交互与增长以及本币价值，和Unified Gas Token是互惠共生的关系。

·统一gas也是实现Chainless的推动因素之一。对用户而言，使用单一的币种支付高度简化了使用流程和理解成本。日后即使在多链场景下，用户很可能是无感的，并不需要关心底层基础设施的运行情况。就像目前在Web2上我们和服务器交互并不关心机房位于哪个地区，什么配置，使用什么语言和数据库工作一样。

·dApp导入的用户直接为Unified Gas Token赋能，使用场景非常丰富。

Intent Fusion Protocol

通常，我们在使用各种dApp的时候需要不断思考使用路径：

·在一个dex上若没有某种流动性，就需要查看另一个dex。

·对同品类的dApp不知应该选择哪个能更好地完成交易或事务。

·Approve然后才能使用很多功能，approve又是什么？

·钱包除尘，多个小额代币转换为某一种币，过程繁琐。

·为完成最终目标需要历经多个应用。诸如高杠杆借贷：先swap，质押，借贷，得到的Token再swap，质押，借贷……

上述内容只是我们在目前的DeFi世界的冰山一角，而在dApp越来越多样化的Web3大规模采用时代，交互复杂度可能远超想象。

所以，用意图Intent代替具体的操作步骤，对用户而言体验是天差地别的。意图较之操作，就像声明式编程之于函数式编程。声明式的语句往往给人简单明了的感觉，只需要声明我要做什么即可而不关心其后细节，而这需要底层有层层封装的各种函数式编程语句。

那么使用Intent也不例外，也需要有一系列设施的支持。我们可以从整个流程来看一下：

1.用户提交将自己的意图用某种方式描述，如自然语言等以RFS(Request For Solver)形式提交给Solver网络。Solver是意图的解释器，目前常见的Solver有1inch等聚合器，可以为用户寻找最优的dex，但相比我们的愿景而言它们并不够通用和强大。

2.多个Solver给出回应，他们之间是竞争关系。这些回应由Intent DSL语言编写，再由客户端解析为易于用户理解的形式。这些回应包含Input Constraints和Output Constraints，界定了输入和输出的界限。用户也可以自行指定约束。一个简单的例子来理解：在使用Swap的时候会提示用户Swap后最少可获得的数量，这就是一种约束。用户自行在多个Solver的回应中进行选择。

3.对Intent签名。

4.Solver指定特定的执行合约Executor，并将Intent递交响应合约Reactor。

5.Reactor从用户账户中搜集所需要的输入（如某种资产），向Executor递交Intent，Executor再调用相关逻辑合约后，将该交易的输出返回给Reactor。Reactor检查约束，若无误则将输出返给用户。

我们可以把这个过程想象为你将需求讲给ChatGPT听，不论多复杂的需求，他都可以给你生成一个最终的结果，只要你对结果满意就可以直接使用，而无需关心其中的过程。

总结

Particle Network提出了一种全方位解决方案：通过zkWaaS、Particle Chain、Intent Fusion Protocol三位一体式的综合形态，实现了Web2 OAuth隐私登录，隐私交易，全链账户抽象和意图交易范式。每一个feature都将覆盖Web3使用的一部分痛点，这些进步与优化将成为日后Web3大规模采用的产品和技术基础。在生态和商业模式上，采用B2B2C范式，以WaaS为入口带动整个产品链条规模化标准化，与dApp开发者共建生态，共同为用户打造一个低门槛高体验的Web3世界。

当然，不同的项目对Web3 mass adoption的实现路径理解是不一样的。除了对具体项目的审视，我们希望通过不同的方案引出对Web3目前面临的onboard friction的理解，对用户需求和痛点的思考，以及对整个生态共同串联和发展的考量。

声明：

1. 本文转载自[极客 Web3]，著作权归属原作者[雾月，极客Web3]，如对转载有异议，请联系Gate Learn团队，团队会根据相关流程尽速处理。
2. 免责声明：本文所表达的观点和意见仅代表作者个人观点，不构成任何投资建议。
3. 文章其他语言版本由Gate Learn团队翻译， 在未提及Gate.io的情况下不得复制、传播或抄袭经翻译文章。