关于 Particle 的 zkWaas 及隐私交易-隐私登录、全链 AA、Intent 框架的技术解读
作者：雾月，极客 Web3
封面：Particle Network
导语：虽然 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 是一种广泛运用于传统互联网中的，由服务端向客户端发放的身份证明，客户端在每次与服务端交互时凭借此证明来进行身份认证。
在 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 的理解，对用户需求和痛点的思考，以及对整个生态共同串联和发展的考量。
免责声明：作为区块链信息平台，本站所发布文章仅代表作者及嘉宾个人观点，与 Web3Caff 立场无关。文章内的信息仅供参考，均不构成任何投资建议及要约，并请您遵守所在国家或地区的相关法律法规。
