FHE 如何解决 a16z 提出的合规可编程隐私问题？

原文标题：《Programmable Privacy and Onchain Compliance using Homomorphic Encryption》

作者：Rand Hindi

编译：Luccy，BlockBeats

编者按：

9 月 19 日，a16z 的加密团队在 Nakamoto Challenge 中提出了七个问题，分别是：原子可组合性和共享测序的局限性、DePIN 验证、JOLT + Lasso 问题、合规可编程隐私、最佳 LVR 缓解、设计 MEV 交易供应链以及利用区块链进行 Deepfake 保护。

对于合规可编程隐私问题，开源加密工具 Zama 提出了一种解决方案，完全同态加密 (FHE) 或说 fhEVM 机密智能合约协议。fhEVM 以其在加密状态上进行计算的能力，为开发者提供了在链上构建合规可编程隐私应用的新途径。

去中心化标识（DID）作为数字身份的颁发者，存储在加密状态中，实现了用户身份的隐私和可编程合规的双赢。通过监管合约定义个体之间的代币转移规则，实现了对转账条件的动态监管。此设计在智能合约级别执行监管规定，无需硬编码，用户通过几行 Solidity 代码即可确保应用程序的合规性。

Zama 首席执行官 Rand Hindi 在文章中展示了如何使用 fhEVM 构建一个合规的 ERC20 代币，通过链上 DIDs 进行身份抽象。他指出，相对于其他隐私解决方案，fhEVM 的所有数据和计算均发生在链上，确保了可组合性和数据可用性。

几个月前，a16z 的加密团队发布了 Nakamoto Challenge（中本挑战），这是一份在区块链中解决的最重要问题清单。其中，第四个问题特别引起了我们的注意：「合规可编程隐私」，因为我们一直在积极思考这个问题，今天，我们提出了使用同态加密和 fhEVM 机密智能合约协议的第一个解决方案。

fhEVM 是一个常规的 EVM，其中包含一些 precompiles，可以使用我们的 TFHE-rs 同态加密库在加密状态上进行计算。从开发者的角度来看，没有涉及到密码学，他们只需使用我们提供的加密数据类型（euint32，ebool 等）编写 Solidity 代码。fhEVM 相对于其他隐私解决方案的一个重大优势是，所有的数据和计算都发生在链上。这意味着您可以获得与常规明文合同相同的可组合性和数据可用性。

这个特性对于构建可编程隐私至关重要，因为所有的访问控制逻辑都可以在合同本身中定义。在协议中没有需要硬编码的内容，用户无需在链外执行任何操作以确保合规性。应用程序可以直接强制执行合规性，只需几行 Solidity 代码。

在这篇文章中，我们将展示如何使用链上 DIDs 构建一个合规的 ERC20 代币。本教程的源代码可以在 fhEVM 存储库的 examples 文件夹中找到。

通过链上、保密的 DID 进行身份抽象

去中心化标识（DID）是由政府、注册机构、公司或用户自身等实体颁发的独特数字身份。这个 DID 可以与证明用户拥有 DID 的加密密钥绑定，例如 EVM 钱包。但它还可以存储一系列属性，比如用户的年龄、国籍、社会安全号等。这些属性反过来可以用来证明你满足某些条件（称为「证明」），比如年满 18 岁或不是纳尼亚公民。由政府、注册机构、公司或用户自身等实体颁发的，比如政府、注册机构、公司或用户本身。

大多数 DID 实际上是在用户端实现的，它们利用零知识证明生成证明。虽然在许多情况下这是可行的，但当涉及多个用户参与交易、需要对 DID 应用复杂规则，或者需要所有人遵循一套通用规则时，情况就会变得复杂。这本质上与边缘应用与云应用的权衡相似。

然而，拥有一个集中式的 DID 注册表可以解决这些问题，因为您可以简单地要求注册表检查每个人是否符合规定。这还将使得法规跟踪变得更简便，因为您只需在一个地方进行实施。区块链将是这个理想的基础设施，因为它将允许 DID 和需要遵循规定的应用之间的可组合性，以及规定之间的可组合性。这本质上与边缘应用与云应用的权衡相似。

问题：每个人都会看到所有人的身份！

幸运的是，我们有一个解决方案：同态加密，更具体地说是 fhEVM！由于在加密状态上具有可组合性的能力，我们可以直接在链上以加密形式托管用户的 DID，并通过简单的合同调用让合规的应用程序验证属性。通过智能合约管理身份的能力，我们称之为「身份抽象」，类似于通过具有账户抽象的智能合约管理资金的方式。

本教程分为 3 个部分：

身份抽象是通过一个注册合约实现的，该合约负责管理身份和证明。在这里，我们假设 DIDs 是官方政府身份证。注册表本身由中央机构（例如 AFNIC）管理，该机构可以创建注册机构（例如 KYC 公司，如 Onfido，Jumio 等），然后注册机构可以创建用户 DIDs。然后，用户通过其注册机构来管理和更新其 DID。

监管在一个合约中定义，该合约对基于用户 DID 中包含的信息的个体之间的代币转移规则进行编码。它基本上在合约级别而不是用户级别执行监管。

合规的机密转账是在一个合规的 ERC20 合约中实现的，该合约使用法规合约来强制执行代币转移的合规性，而不对 ERC20 API 本身进行任何更改。在这个例子中，我们使用了一个机密的 ERC20 合约，其中余额和金额是隐藏的，但对于一个常规的、明文的 ERC20 代币同样有效。

身份注册合约

身份注册合约是一个由注册机构发放用户 DID 的注册表，其中包含一组加密标识，如国籍、年龄、社会安全号等。这些标识以加密的 32 位值（euint32）的形式存储。

该合约还处理权限，包括：

允许合约所有者（例如 AFNIC）添加、删除或更新注册机构。

允许注册机构添加、删除或更新他们创建的用户 DID。

允许用户授予智能合约访问其 DID 特定属性的权限。这里需要注意，用户有责任不向恶意合约授予访问权限，就像他们有责任不让恶意合约花费他们的代币一样。

第一步，实现创建和管理 DID 的逻辑：

注：图片为部分截图，可在原文查看完整代码

下一步是实现标识和访问控制的逻辑。

标识符简单来说是一个字符串（例如「出生日期」）和一个加密的 32 位值。它只能由注册机构创建或更新。用户不能创建自己的标识符，因为我们希望它们经过注册机构的认证。

然而，由于标识符是加密的，用户需要授予合约访问特定值的权限，我们将通过一个简单的访问控制机制来处理，类似于您可以允许合约花费您的 ERC20 代币的简单访问控制机制。

注：图片为部分截图，可在原文查看完整代码

现在我们可以通过添加必要的获取器，加入一些条件和错误处理，来完成我们的身份注册合约。

注：图片为部分截图，可在原文查看完整代码

监管合约

下一步是创建监管合约。

在实施两个个体之间的转账规则时，重要的是要认识到这些规则可能会随时间演变。有一个单一的智能合约来定义给定上下文（如资金转移）的所有监管规定，这意味着 ERC20 合约无需自己跟踪监管规定。政府只需更新此合约，它将自动传播到实施了它的所有代币。

在核心部分，监管合约只是一组与加密身份属性匹配的条件。为了防止滥用，用户不会直接授予监管合约访问权限，而是授予 ERC20 代币合约访问权限，然后由 ERC20 代币合约执行对监管合约的委托调用。这种方法确保只有用户信任的 ERC20 合约才能访问他们的信息。请记住，在发件人和接收人在它们之间发生转账之前，它们都必须已经授予 ERC20 合约许可。

在这个例子中，我们将实施一些基本规则：

国内的转账是无限制的，但向外国的转账上限为 1 万代币。

黑名单用户无法转账或接收代币。

用户不能将代币转账到黑名单国家。

与其使交易失败，可能会泄露敏感信息，如果其中一个条件不满足，我们将简单地将转账金额设置为 0。这使用了一个称为 cmux 的同态三元运算符：value = TFHE.cmux(encryptedCondition, valueIfTrue, valueIfFalse);

注：图片为部分截图，可在原文查看完整代码

合规的隐私 ERC20 合约

现在我们有了身份注册和监管合约，我们终于可以创建符合要求的、保护隐私的代币合约了。这个合约将被称为 CompliantERC20，具有以下关键特点：

用户余额和转账金额都是加密的。

合规性通过调用监管合约来执行转账。

可以向白名单地址（例如监管机构）授予对某些余额的可见性。

注：图片为部分截图，可在原文查看完整代码

可简单的调用监管合约。这意味着用户在发起任何转账之前必须提供对 ERC20 合约的访问权限；否则，转账将被回滚。

最后，我们现在可以创建我们的 ERC20 合约：

类似于用户授予 DeFi 协议花费他们的代币的权限，他们需要授予合约访问监管合约所需的标识的权限。这是通过调用 Identity.grantAccess(contractAddress, identifiers) 来实现的，可以通过调用 ERC20.identifiers() 视图方法来检索。此列表直接来自 ERC20Rules 合约，以允许属性的更新。

合规和隐私可以共存

如果有合适的工具，建立合规并不难。虽然我们最初构建 fhEVM 以在区块链中实现隐私，但我们很快意识到这项技术可以用于身份管理，从而实现可编程合规。

此设计还远非完美，但我们相信它可以继续改进，并作为一个真实的用例推出，使合规不再等同于监管。