区块链中的可编程隐私:链下计算与链上验证
公共区块链以牺牲隐私为代价提供了透明度和完整性——每笔交易和合约状态都对所有参与者公开。这种开放性带来了诸如 MEV (矿工可提取价值) 攻击、复制交易以及敏感商业逻辑泄露等问题。可编程隐私旨在通过允许在不泄露数据本身的情况下对私有数据进行计算来解决这些问题。两种新兴的密码学范式正在使这成为可能:全同态加密虚拟机 (FHE-VM) 和零知识 (ZK) 协处理器。这些方法实现了链下或加密计算与链上验证,在保留信任的同时保护了机密性。在本报告中,我们将深入探讨 FHE-VM 和 ZK 协处理器的架构,比较它们的优缺点,并探索它们在金融、身份、医疗、数据市场和去中心化机器学习等领域的用例。
全同态加密虚拟机 (FHE-VM)
全同态加密 (FHE) 允许在不解密数据的情况下对加密数据进行任意计算。FHE 虚拟机将此功能集成到区块链智能合约中,实现了加密的合约状态和逻辑。在一个支持 FHE 的区块链(对于 EVM 兼容的设计,通常称为 fhEVM)中,所有输入、合约存储和输出在整个执行过程中都保持加密状态。这意 味着验证者可以在不了解任何敏感值的情况下处理交易和更新状态,从而实现具有数据机密性的链上执行。
FHE-VM 的架构与设计
一个典型的 FHE-VM 扩展了标准的智能合约运行时(如以太坊虚拟机),增加了对加密数据类型和操作的原生支持。例如,Zama 的 FHEVM 引入了加密整数(euint8
、euint32
等)、加密布尔值(ebool
),甚至加密数组作为一等类型。像 Solidity 这样的智能合约语言通过库或新的操作码进行了增强,使开发者可以直接对密文执行算术(add
、mul
等)、逻辑和比较操作。在底层,这些操作调用 FHE 原语(例如,使用 TFHE 库)来操作加密位并产生加密结果。
加密状态存储也得到支持,以便合约变量在区块链状态中保持加密。执行流程通常如下:
- 客户端加密: 用户在发送交易前,使用公共 FHE 密钥在本地加密其输入。加密密钥是公开的(用于加密和评估),而解密密钥则保持私密。在某些设计中,每个用户管理自己的密钥;在其他设计中,使用单个全局 FHE 密钥(下文将讨论)。
- 链上同态计算: 矿工/验证者使用加密的操作码执行合约。他们对密文执行相同的确定性同态操作,因此可以在加密的新状态上达成共识。关键是,验证者永远看不到明文数据——他们只看到“乱码”的密文,但仍然可以一致地处理它。
- 解密(可选): 如果需要公开或在链下使用某个结果,拥有私钥的授权方可以解密输出的密文。否则,结果将保持加密状态,并可用作后续交易的输入(允许对持久的加密状态进行连续计算)。
一个主要的设计考虑是密钥管理。一种方法是每个用户一个密钥,即每个用户持有自己的私钥,只有他们才能解密与他们相关的输出。这最大限度地保护了隐私(其他任何人都无法解密你的数据),但同态操作无法混合使用不同密钥加密的数据,除非使用复杂的多密钥协议。另一种方法,被 Zama 的 FHEVM 采用,是全局 FHE 密钥:一个单一的公钥加密所有合约数据,而一组分布式的验证者持有门限解密密钥的份额。公共加密和评估密钥在链上发布,因此任何人都可以向网络加密数据;私钥被分割给验证者,他们可以在门限方案下集体解密(如果需要)。为了防止验证者串通损害隐私,Zama 采用了一种门限 FHE 协议(基于他们的 Noah’s Ark 研究),并使用“噪声泛洪”来确保部分解密的安全性。只有当足够数量的验证者合作时,才能恢复明文,例如响应一个读取请求。然而,在正常操作中,没有任何单个节点能看到明文——数据在链上始终保持加密。
访问控制是另一个关键组成部分。FHE-VM 实现包括细粒度的控制,以管理谁(如果有的话)可以触发解密或访问某些加密字段。例如,Cypher 的 fhEV M支持对密文的访问控制列表,允许开发者指定哪些地址或合约可以与某些数据交互或重新加密。一些框架支持重加密:即在不暴露明文的情况下,将一个加密值从一个用户的密钥转移到另一个用户的密钥。这对于数据市场等场景非常有用,数据所有者可以用自己的密钥加密数据集,在购买后, 将其重加密为买家的密钥——所有操作都在链上完成,无需公开解密。
确保正确性和隐私性
有人可能会问:如果所有数据都是加密的,我们如何强制执行合约逻辑的正确性?如果链无法“看到”值,它如何防止无效操作?FHE 本身不提供正确性证明——验证者可以执行同态步骤,但他们无法在不解密的情况下判断用户的加密输入是否有效,或者是否应该执行某个条件分支。零知识证明 (ZKPs) 可以补充 FHE 来解决这个问题。在 FHE-VM 中,通常用户在需要时必须提供一个 ZK 证明来证实某些明文条件。例如,Zama 的设计在每个加密输入中都附带一个明文知识的零知识证明 (ZKPoK)。这证明了用户知道其密文对应的明文,并且该明文符合预期标准,而无需透露明文本身。这种**“认证密文”**可以防止恶意用户提交格式错误的加密或超出范围的值。同样,对于需要决策的操作(例如,确保账户余额 ≥ 提款金额),用户可以在执行加密操作之前提供一个 ZK 证明,证明该条件在明文上成立。这样,链既不解密也不查看值,但它能确信加密交易遵循了规则。
FHE Rollup 中的另一种方法是使用 ZKPs 进行链下验证。Fhenix(一个使用 FHE 的 L2 Rollup)选择了一种乐观模型,其中一个名为门限服务网络的独立网络组件可以解密或验证加密结果,任何不正确的计算都可以通过欺诈证明进行挑战。总的来说,结合 FHE + ZK 或欺诈证明可以确保加密执行保持无需信任。验证者要么仅在授权时集体解密 ,要么验证每个加密状态转换都是有效的证明,而无需看到明文。
性能考虑: FHE 操作的计算量非常大——比普通算术慢几个数量级。例如,在以太坊上进行一次简单的 64 位加法大约花费 3 Gas,而在 Zama 的 FHEVM 下对一个加密的 64 位整数 (euint64) 进行加法大约需要 188,000 Gas。即使是 8 位的加法也可能花费约 94k Gas。这种巨大的开销意味着在现有节点上直接实现将非常缓慢且成本高昂。FHE-VM 项目通过优化的密码学库(如 Zama 用于二进制门自举的 TFHE-rs 库)和定制的 EVM 修改来解决这个问题。例如,Cypher 修改后的 Geth 客户端增加了新的操作码,并在 C++/汇编中优化了同态指令的执行,以最小化开销。尽管如此,要实现可用的吞吐量还需要加速。正在进行的工作包括使用 GPU、FPGA 甚至专门的光子芯片来加速 FHE 计算。Zama 报告称,自 2024 年以来,他们的 FHE 性能提高了 100 倍,并计划通过 GPU/FPGA 加速实现数千 TPS。专用的 FHE 协处理器服务器(如 Optalysys 的 LightLocker Node)可以插入验证者节点,将加密操作卸载到硬件上,支持每个节点每秒超过 100 次加密的 ERC-20 转账。随着硬件和算法的改进,FHE 与明文计算之间的差距将缩小,使私有合约能够接近更实用的速度。
兼容性: FHE-VM 设计的一个关键目标是与现有的开发工作流程保持兼容。Cypher 和 Zama 的 fhEVM 实现允许开发者使用 Solidity 编写合约,只需进行最小的更改——使用一个库来声明加密类型和操作。以太坊工具链的其余部分(Remix、Hardhat 等)仍然可以使用,因为底层的修改主要在客户端/节点级别。这降低了入门门槛:开发者无需成为密码学专家就能编写机密智能合约。例如,两个数的简单加法可以写成 euint32 c = a + b;
,FHEVM 会在幕后处理与加密相关的细节。这些合约甚至可以与普通合约互操作——例如,一个加密合约如果需要,可以向一个标准合约输出一个解密结果,从而允许在一个生态系统中混合使用私有和公共部分。
当前的 FHE-VM 项目: 有几个项目正在开拓这一领域。Zama(一家总部位于巴黎的 FHE 初创公司)开发了核心的 FHEVM 概念和库(TFHE-rs 和一个 fhevm-solidity
库)。他们不打算推出自己的链,而是为他人提供基础设施。Inco 是一个 L1 区块链(基于 Cosmos SDK 和 Evmos 构建),它集成了 Zama 的 FHEVM,创建了一个模块化的机密链。他们的测试网(名为 Gentry 和 Paillier)展示了加密的 ERC-20 转账和其他私有 DeFi 原语。Fhenix 是一个以太坊二层乐观 Rollup,使用 FHE 实现隐私。它选择了乐观(欺诈证明)方法而不是 ZK-Rollup,因为对每个区块同时进行 FHE 和 ZK 的成本非常高。Fhenix 使用相同的 TFHE-rs 库(进行了一些修改),并引入了一个门限服务网络来以去中心化的方式处理解密。还有一些独立的团队,如 Fhenix (现已更名) 和一些初创公司正在探索 MPC + FHE 的混合方案。此外,Cypher (由 Z1 Labs 开发) 正在构建一个专注于 AI 和隐私的三层网络,使用一个具有秘密存储和联邦学习支持等功能的 fhEVM。这个生态系统虽然 nascent 但发展迅速,并得到了大量资金的支持——例如,Zama 在 2025 年前筹集了超过 1.3 亿美元,成为“独角兽”,以推进 FHE 技术。
总之,FHE-VM 通过在链上对加密数据执行所有逻辑,实现了保护隐私的智能合约。这种范式确保了最大的机密性——在交易或状态中永远不会暴露任何敏感 信息——同时利用现有的区块链共识来保证完整性。其代价是增加了验证者的计算负担以及密钥管理和证明集成的复杂性。接下来,我们将探讨一种替代范式,它将计算完全卸载到链下,仅使用链进行验证:零知识协处理器。
零知识协处理器 (ZK 协处理器)
ZK 协处理器是一种新的区块链架构模式,其中昂贵的计算在链下执行,其正确性的简洁零知识证明则在链上进行验证。这使得智能合约能够利用比链上执行所允许的更大的计算能力和数据,而无需牺牲无需信任性。术语协处理器是类比于硬件协处理器(如数学协处理器或 GPU),它们为 CPU 处理专门任务。在这里,区块链的“CPU”(如 EVM 等原生虚拟机)将某些任务委托给一个零知识证明系统,该系统充当密码学协处理器。ZK 协处理器返回一个结果和一个证明该结果计算正确的证明,链上合约可以验证并使用该结果。
架构与工作流程
在典型设置中,dApp 开发者识别出其应用逻辑中对于链上执行来说过于昂贵或复杂的部分(例如,对历史数据的大量计算、重型算法、机器学习模型推理等)。他们将这些部分实现为一个链下程序(使用高级语言或电路 DSL),该程序可以为其执行生成零知识证明。链 上组件是一个验证者智能合约,它检查证明并使结果可用于系统的其余部分。流程可以总结如下:
- 请求 – 链上合约触发一个请求,要求在链下完成某个计算。这可以由用户交易发起,也可以由一个合约调用 ZK 协处理器的接口。例如,一个 DeFi 合约可能会调用 “proveInterestRate(currentState)”,或者一个用户调用 “queryHistoricalData(query)”。
- 链下执行与证明 – 一个链下服务(可能是一个去中心化的证明者网络或一个受信任的服务,取决于设计)接收请求。它收集所有需要的数据(链上状态、链下输入等),并在一个特殊的 ZK 虚拟机 (ZKVM) 或电路中执行计算。在执行过程中,会生成一个证明轨迹。最后,该服务生成一个简洁证明(例如,SNARK 或 STARK),证明*“在输入 X 上计算函数 F 得到输出 Y”*,并可选地证明数据完整性(下文将详细介绍)。
- 链上验证 – 证明和结果被返回到区块链(通常通过回调函数)。验证者合约使用高效的密码学验证(配对检查等)来检查证明的有效性。如果有效,合约现在可以信任输出 Y 是正确的。结果可以存储在状态中,作为事件发出,或输入到进一步的合约逻辑中。如果证明无效或在某个时间内未提供,请求可以被视为失败(并可能触发一些回退或超时逻辑)。
图 1:ZK 协处理器的架构(以 RISC Zero Bonsai 为例)。在链下,一个程序在 ZKVM 上运行,输入来自智能合约调用。执行证明通过一个中继合约返回到链上,该合约用验证后的结果调用一个回调函数。
关键是,无论链下计算有多复杂,链上验证的 Gas 成本是恒定的(或增长非常缓慢)。验证一个简洁证明可能花费几十万 Gas(以太坊区块的一小部分),但该证明可能代表了在链下完成的数百万个计算步骤。正如一位开发者所说,“想证明一个数字签名?大约 15 美元。想证明一百万个签名?也是大约 15 美元。”。这种可扩展性是一个巨大的优势:dApp 可以提供复杂的功能(大数据分析、复杂的金融模型等),而不会堵塞区块链。
ZK 协处理器系统的主要组件是:
- 证明生成环境: 这可以是一个通用的 ZKVM(能够运行任意程序)或为特定计算量身定制的自定义电路。方法各不相同:
- 一些项目为每个支持的查询或函数使用手工制作的电路(最大化该函数的效率)。
- 其他项目提供一个领域特定语言 (DSL) 或嵌入式 DSL,开发者用它来编写他们的链下逻辑,然后编译成电路(在易用性和性能之间取得平衡)。
- 最灵活的方法是 zkVM:一个虚拟机(通常基于 RISC 架构),程序可以用标准语言(Rust、C 等)编写并自动证明。这牺牲了性能(在电路中模拟 CPU 会增加开销),但换来了最佳的开发者体验。
- 数据访问与完整性: 一个独特的挑战是为链下计算提供正确的数据,特别是如果这些数据位于区块链上(过去的区块、合约状态等)。一个简单的解决方案是让证明者从一个存档节点读取并信任它——但这引入了信任假设。相反,ZK 协处理器通常通过链接到 Merkle 证明或状态承诺来证明所使用的任何链上数据都是真实的。例如,查询程序可能会接收一个区块号和一个存储槽或交易的 Merkle 证明,电路将根据已知的区块头哈希验证该证明。存在三种模式: