ZK系统内隐私 VS. FHE系统内隐私

1. 引言

当前，crypto中最大的问题之一是：

• 缺少链上隐私

尽管现有ZK方案，如Aztec，支持私有交易和基于私有数据计算，但其有一个主要问题在于：

• 无法处理私有共享状态。

为何需要私有共享状态呢？
私有共享状态可为：

• 某私有链上投票记录
• 某扑克游戏状态
• 某dark AMM pool状态

私有共享状态可启用crypto中前所未有的应用场景。

为何Aztec不能处理私有共享状态呢？
原因在于：

• 要维护数据隐私，就需要加密，但是zk无法处理加密数据，数据必须解密，计算在客户端进行，结果必须重新加密。

当数据是个人的，例如年龄，财富数据等，做客户端计算是可行的 当私有数据是共享的，即多人可以改变它时，你需要：

• 共享解密密钥，即，泄露隐私，
• 或使用 FHE。

FHE如何解决该问题？
全同态加密 (FHE) 允许加密数据并对此数据运行计算，而无需解密。
如：

• 在私人投票中，每次新投票都会更改计票结果而不会泄露它。
• AMM 矿池或借贷协议的状态可以通过有效交易进行更改，而无需在交易之前或之后透露协议的状态。这可以提供针对提取性 MEV 的保护，如三明治攻击。

总体而言，FHE 具有一些主要优势：

• 私有状态可以由许多用户更改，从而提高了可组合性
• 用户不需要存储数据或生成 ZKP，从而提高了用户体验
• 通过私有地址实现完全隐私

但 FHE 仍然有其挑战：

• FHE 的计算成本非常高

即使使用像 Zama TFHE-rs 库这样的优化库，FHE 计算可能比透明计算慢一百万倍。如下图为AI中使用FEH计算的性能对比：

尽管很复杂，但 fhEVM（带 FHE 的 EVM）等创新让我们更接近实际应用。
在 fhEVM 中，Inco Network 用于 L1 时，FHE 操作作为 EVM 预编译实现，以加速计算并减少 Gas 消耗。
使用 fhEVM，开发人员可以创建任何共享私有状态作为加密变量数组：

• Solidify 合约可以在不解密的情况下读取和修改这些加密变量。
• 换句话说，可以修改许多现有应用程序以启用隐私。

开发人员开始使用这种架构来实现隐藏信息游戏，如《狼人杀》和《黑手党》。

仍有很多工作要做，为完全EVM兼容，fhEVM：

• 需要支持更大的加密变量（高达256位）
• 支持更难多数学运算
• 合并MPC用于私有状态的协同加密/解密

推进这项技术还需要教育开发者如何围绕处理私有状态建立适当的心智模型。

总之，任何共享状态都需要加密/解密密钥。该密钥必须在网络validitors（MPC）之间进行分片。validators在需要时解密数据，如最终投票结果。

现有的fhEVM实现，还没有这个MPC组件。此外，这个MPC应该是动态的，密钥可以随着时间的推移而改变，以避免有一个密钥控制所有历史状态的隐私。

隐私绝对是多层的。RPC层隐私也很重要，但它与互联网流量隐私这一更大的主题有关。

2. Web3中隐私很难

Tornado Cash，使用常规交易10倍以上的开销，来实现私有ETH转账。为运行具有私有状态的智能合约，其复杂度将增加1000倍。

在高层次上，Aztec 希望将公共和私人执行结合在一起。

• 公共执行的工作方式与任何其他 ZK rollup 相同
• 当您尝试执行私人交易或混合私人和公共交易时，神奇（和复杂性）就会发生

让我们把复杂的 Aztec 设计分解：

• 1）第一部分是数据：运行私有应用程序意味着你需要拥有私有数据，又名私有状态
  在 Aztec 中，私有状态是基于 UTXO 的，即每个账户的私有余额由多个数据/UTXO。
  
  Aztec私有状态以Merkle tree表示。每个UTXO表示为该Merkle tree内的一个叶子节点。当某交易改变了某私有状态时，其叶子节点将被删除，并创建新的叶子节点。所谓删除，是通过为old state创建nullifier来实现的。
• 2）第二部分是执行：如何基于私有状态运行应用？如何执行转账和AMM swap？能否使用智能合约？这些答案都可以为“肯定”的。但，智能合约仅能基于明文数据运行，不能使用加密的/私有的状态，除非使用FHE，这是另一个故事了。

若想要基于私有数据运行某合约，仅能在client端，即，在数据所有者设备上，来运行。

因此，数据所有者读取其私有状态、解密该数据、运行该合约、创建新状态、加密新状态、将加密后的新状态发送到网络，与此同时，数据所有者会生成ZKP proof，以向网络证明该新加密状态是有效的，同时，还需为老的私有状态创建nullifier，并将该nullifier共享给网络，以让老状态失效：

显然该流程很复杂，挑战在于：

• 用户如何运行合约？
• 用户是否修改网络状态？
• 用户能否足够快地生成ZKP proof？
• 为生成ZKP proof，合约应为ZK电路，由app者来创建这些电路么？

Aztec解决这些挑战的方案为：

• 1）用户如何运行合约？

  • Aztec将合约切分为函数。每个函数实现为一个zk电路。当用户运行某交易时，仅使用域该交易相关的函数，并为这些函数生成ZKP proof。
    
  • 交易通常会调用很多函数，每个函数的ZKP proof可递归聚合，来生成单个ZKP proof 提交到网络。
    

• 2）用户是否修改网络状态？：

  • Aztec用户不会修改整个rollup网络状态。用户仅将new state提交为“a state change request”。rollup sequencer来处理“执行”该request，即更新公开和私有状态树，添加nullifier到nullifier set中，等等。

• 3）用户能否足够快地生成ZKP proof？：

  • Aztec需要一个支持递归的快速证明系统，以允许用户在本地生成ZKP proof。Aztec团队正在开发其自己的名为Honk的证明系统，其支持在消费级硬件上高效生成ZKP proof。

• 4）为生成ZKP proof，合约应为ZK电路，由app者来创建这些电路么？：

  • ZK电路难以开发，但Aztec正在开发Noir和Aztec.nr合约，使得开发者可用高级语言来编写合约。
  • Noir会编译合约，并为合约内的每个函数创建ZK电路。函数是公开的（由sequencer执行）或私有的（有client端执行）。

即使解决了以上所有挑战，未来仍有很多其它设计细节待讨论。如处理共享私有状态，即，能否有具有私有pool的AMM？
此外，ZK方案不一定是某些应用的最优方案，如游戏应用，且这些应用可能需要不同的技术，如FHE。

参考资料

[1] Mohamed Fouda 2024年1月23日twitter 链上隐私方案讨论
[2] Web3隐私讨论