公共区块链以牺牲隐私为代价提供了透明度和完整性——每笔交易和合约状态都对所有参与者公开。这种开放性带来了诸如 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 证明，电路将根据已知的区块头哈希验证该证明。存在三种模式：
- 内联数据： 将所需数据放在链上（作为验证者的输入），以便直接检查。这对于大数据来说成本非常高，并且破坏了整个目的。
- 信任预言机： 让一个预言机服务将数据提供给证明并为其担保。这更简单，但重新引入了对第三方的信任。
- 通过 ZK 证明数据包含： 在零知识电路本身中包含数据在链历史中的包含证明。这利用了每个以太坊区块头都提交了整个先前状态（通过状态根）和交易历史的事实。通过在电路内验证数据的 Merkle Patricia 证明，输出证明向合约保证*“此计算使用了来自区块 N 的真实区块链数据”，无需额外的信任。
第三种方法是最无需信任的，并被像 Axiom 和 Xpansion 这样的高级 ZK 协处理器使用（它确实增加了证明成本，但为了安全性是可取的）。例如，Axiom 的系统在其电路中模拟了以太坊的区块结构、状态树和交易树，因此它可以证明诸如“账户
X 在区块 N 时的余额为 Y”或“一个具有某些属性的交易发生在区块 N”*之类的陈述。它利用了这样一个事实：给定一个最近的可信区块哈希，可以递归地证明历史数据的包含，而无需信任任何外部方。
- 验证者合约： 这个链上合约包含验证密钥和接受或拒绝证明的逻辑。对于像 Groth16 或 PLONK 这样的 SNARKs，验证者可能会进行一些椭圆曲线配对；对于 STARKs，它可能会进行一些哈希计算。聚合和递归等性能优化可以最小化链上负载。例如，RISC Zero 的 Bonsai 使用一个 STARK-to-SNARK 包装器：它在链下运行一个基于 STARK 的 VM 以提高速度，然后生成一个小的 SNARK 证明来证明 STARK 的有效性。这将证明大小从几百千字节缩小到几百字节，使得链上验证变得可行且便宜。然后，Solidity 验证者只需检查 SNARK（这是一个常数时间操作）。
在部署方面，ZK 协处理器可以作为类似二层的网络或纯粹的链下服务运行。一些，如 Axiom，最初是作为以太坊的专门服务（得到 Paradigm 的支持），开发者向 Axiom 的证明者网络提交查询，并在链上获得证明。Axiom 的口号是为以太坊合约提供*“对所有链上数据和对其的任意表达性计算的无需信任的访问”*。它实际上充当了一个查询预言机，其中答案由 ZKPs 而不是信任来验证。其他的，如 RISC Zero 的 Bonsai，提供了一个更开放的平台：任何开发者都可以上传一个程序（编译成与 RISC-V 兼容的 ZKVM），并通过一个中继合约使用 Bonsai 的证明服务。如图 1 所示的中继模式涉及一个合约，该合约协调请求和响应：dApp 合约调用中继来请求一个证明，链下服务监听此请求（例如，通过事件或直接调用），计算证明，然后中继在 dApp 合约上调用一个回调函数，并附带结果和证明。这种异步模型是必要的，因为证明可能需要几秒到几分钟，具体取决于复杂性。它引入了延迟（以及证明者会响应的活性假设），而 FHE-VM 计算则在块内同步发生。设计应用程序以处理这种异步工作流（可能类似于预言机响应）是使用 ZK 协处理器的一部分。
著名的 ZK 协处理器项目
- Axiom: Axiom 是一个为以太坊量身定制的 ZK 协处理器，最初专注于证明历史链上数据查询。它使用 Halo2 证明框架（一种 Plonk-ish SNARK）来创建包含以太坊密码学结构的证明。在 Axiom 的系统中，开发者可以查询诸如*“合约 X 在区块 N 的状态是什么？”或对某个范围内的所有交易进行计算。在底层，Axiom 的电路必须实现以太坊的状态/树逻辑，甚至在电路内部执行椭圆曲线操作和 SNARK 验证以支持递归。Trail of Bits 在一次审计中指出了 Axiom 的 Halo2 电路模拟整个区块和状态的复杂性。审计后，Axiom 将其技术推广到一个 OpenVM，允许使用相同的基于 Halo2 的基础设施来证明任意 Rust 代码。（这反映了从领域特定电路转向更通用的 ZKVM 方法的趋势。）Axiom 团队展示了以太坊原生无法完成的 ZK 查询，实现了对任何历史数据的无状态访问*和密码学完整性。他们还强调了安全性，捕获并修复了约束不足的电路错误并确保了可靠性。虽然 Axiom 的初始产品在其转型期间被关闭，但他们的方法仍然是 ZK 协处理器领域的一个里程碑。
- RISC Zero Bonsai: RISC Zero 是一个基于 RISC-V 架构的 ZKVM。他们的 zkVM 可以执行任意程序（用 Rust、C++ 和其他编译到 RISC-V 的语言编写）并生成一个 STARK 执行证明。Bonsai 是 RISC Zero 的云服务，按需提供这种证明，充当智能合约的协处理器。要使用它，开发者编写一个程序（例如，一个执行复杂数学或验证链下 API 响应的函数），将其上传到 Bonsai 服务，并部署一个相应的验证者合约。当合约需要该计算时，它会调用 Bonsai 中继，触发证明生成并通过回调返回结果。一个展示的应用示例是链下治理计算：RISC Zero 展示了一个 DAO 使用 Bonsai 在链下统计投票并计算复杂的投票指标，然后发布一个证明，以便链上治理合约能够以最小的 Gas 成本信任结果。RISC Zero 的技术强调开发者可以使用熟悉的编程范式——例如，编写一个 Rust 函数来计算某些东西——而电路创建的繁重工作由 zkVM 处理。然而，证明可能很大，因此如前所述，他们为链上验证实现了一个 SNARK 压缩。2023 年 8 月，他们成功地在以太坊的 Sepolia 测试网上验证了 RISC Zero 证明，每个证明的成本约为 30 万 Gas。这为以太坊 dApp 今天使用 Bonsai 作为扩展和隐私解决方案打开了大门。（Bonsai 仍处于 alpha 阶段，尚未准备好生产，并使用一个没有仪式的临时 SNARK 设置。）
- 其他: 还有许多其他参与者和研究计划。Expansion/Xpansion（如一篇博客中所述）使用一种嵌入式 DSL 方法，开发者可以用一种专门的语言编写对链上数据的查询，它在内部处理证明生成。StarkWare 的 Cairo 和 Polygon 的 zkEVM 是更通用的 ZK-Rollup VM，但它们的技术可以通过在 L1 合约内验证证明来重新用于类似协处理器的用途。我们还看到 ZKML (ZK 机器学习) 领域的项目，它们实际上充当协处理器，在链上验证 ML 模型推理或训练结果。例如，一个 zkML 设置可以证明*“在私有输入上进行的神经网络推理产生了分类 X”*，而无需透露输入或在链上进行计算。这些是协处理器概念应用于 AI 的特例。
信任假设： ZK 协处理器依赖于密码学证明的可靠性。如果证明系统是安全的（并且任何可信设置都是诚实完成的），那么一个被接受的证明就保证了计算是正确的。不需要对证明者有额外的信任——即使是恶意的证明者也无法让验证者相信一个错误的陈述。然而，存在一个活性假设：必须有人实际执行链下计算并生成证明。在实践中，这可能是一个去中心化的网络（有激励或费用来完成工作）或一个单一的服务运营商。如果没有人提供证明，链上请求可能会保持未解决状态。另一个微妙的信任方面是对于不在区块链上的链下输入的数据可用性。如果计算依赖于某些私有或外部数据，验证者无法知道该数据是否被诚实提供，除非使用额外的措施（如数据承诺或预言机签名）。但对于纯粹的链上数据计算，所描述的机制确保了与链本身等效的无需信任性（Axiom 认为他们的证明为历史查询提供了“与以太坊在密码学上等效的安全性”）。
隐私： 零知识证明本身也支持隐私——证明者可以在证明关于它们陈述的同时保持输入隐藏。在协处理器上下文中，这意味着一个证明可以允许合约使用从私有数据派生的结果。例如，一个证明可能显示*“用户的信用评分 > 700，因此批准贷款”，而无需透露实际的信用评分或原始数据。Axiom 的用例更多是关于公开已知的数据（区块链历史），所以隐私不是重点。但 RISC Zero 的 zkVM 可以用来证明关于用户提供的秘密数据的断言：数据保留在链下，只有需要的结果上链。值得注意的是，与 FHE 不同，ZK 证明通常不提供状态的持续机密性——它是一次性的证明。如果一个工作流需要跨交易维护一个秘密状态，可以通过让合约存储一个状态的承诺*，并且每个证明都显示从旧承诺到新承诺的有效状态转换，同时隐藏秘密来构建它。这基本上是用于私有交易的 zk-rollups（如 Aztec 或 Zcash）的工作方式。因此，ZK 协处理器可以促进完全私有的状态机，但实现并非易事；它们通常用于一次性计算，其中输入或输出（或两者）可以根据需要保持私有。
开发者体验： 使用 ZK 协处理器通常需要学习新工具。编写自定义电路（上述选项 (1)）相当复杂，通常只用于狭窄的目的。像 DSLs 或 zkVMs 这样的更高级别的选项使生活更容易，但仍然增加了开销：开发者必须编写和部署链下代码并管理交互。与 FHE-VM 相比，在 FHE-VM 中，加密主要在幕后处理，开发者编写正常的智能合约代码，而在这里，开发者需要划分他们的逻辑，并可能需要用不同的语言（Rust 等）为链下部分编写代码。然而，像 Noir、Leo、Circom DSLs 或 RISC Zero 的方法这样的举措正在迅速提高可访问性。例如，RISC Zero 提供了模板和 Foundry 集成，这样开发者可以在本地模拟他们的链下代码（为了正确性），然后通过 Bonsai 回调无缝地将其挂钩到 Solidity 测试中。随着时间的推移，我们可以期待开发框架能够抽象出一段逻辑是通过 ZK 证明还是在链上执行——编译器或工具可能会根据成本来决定。
FHE-VM vs ZK 协处理器：比较
FHE-VM 和 ZK 协处理器都实现了一种*“在私有数据上计算并进行链上保证”*的形式，但它们在架构上根本不同。下表总结了主要区别：
| 方面 | FHE-VM (加密的链上执行) | ZK 协处理器 (链下证明) |
|---|
| 计算发生地 | 直接在链上（所有节点对密文执行同态操作）。 | 在链下（一个证明者或网络执行程序；只有一个证明在链上被验证）。 |
| 数据机密性 | 完全加密： 数据在链上始终保持加密；验证者永远看不到明文。只有解密密钥的持有者才能解密输出。 | 零知识： 证明者的私有输入永远不会在链上透露；证明除了公共输出中的内容外，不泄露任何秘密。然而，任何必须影响链上状态的计算中使用的数据都必须编码在输出或承诺中。秘密默认保留在链下。 |
| 信任模型 | 信任共识执行和密码学：如果大多数验证者遵循协议，加密执行是确定性和正确的。计算正确性无需外部信任（所有节点重新计算）。隐私方面必须信任 FHE 方案的安全性（通常基于格的困难性）。在某些设计中，还需信任足够数量的验证者不会串通滥用门限密钥。 | 信任证明系统的安全性（SNARK/STARK 的可靠性）。如果证明验证通过，结果在密码学上可以确定是正确的。链下证明者无法欺骗数学。对证明者实际完成工作存在活性假设。如果使用可信设置（例如 SNARK SRS），必须信任它是诚实生成的，或使用透明/无设置的系统。 |
| 链上成本和可扩展性 | 每笔交易成本高： 同态操作计算成本极高，每个节点都必须执行。Gas 成本很高（例如，一个 8 位加法就需要 10 万+ Gas）。复杂合约受限于每个验证者在一个区块内能计算的内容。除非采用专用硬件，否则吞吐量远低于普通智能合约。通过更快的密码学和硬件加速可以提高可扩展性，但从根本上说，每个操作都会增加链的工作负载。 | 验证成本低： 验证一个简洁证明是高效且大小恒定的，因此链上 Gas 适中（任何大小的计算都只需几十万 Gas）。这将复杂性与链上资源限制解耦——大型计算没有额外的链上成本。因此，它在链上负载方面是可扩展的。在链下，证明时间可能很长（对于大型任务可能需要几分钟或更长时间），并且可能需要强大的机器，但这不会直接减慢区块链。只要能及时生成证明（潜在的并行证明者网络），整体吞吐量可以很高。 |
| 延迟 | 结果在同一交易/区块中立即可用，因为计算在执行期间发生。没有额外的往返——同步操作。然而，如果 FHE 操作很慢，较长的区块处理时间可能会增加区块链的延迟。 | 本质上是异步的。通常需要一个交易来请求，并在稍后的交易（或回调）中提供证明/结果。这会引入延迟（可能从秒到小时，取决于证明复杂性和证明硬件）。不适合单个交易的即时最终性——更像一个异步作业模型。 |
| 隐私保证 | 强： 所有内容（输入、输出、中间状态）都可以在链上保持加密。你可以拥有长期的加密状态，多个交易可以更新它而无需透露。只有授权的解密操作（如果有的话）才会揭示输出，并且这些操作可以通过密钥/ACL 控制。然而，必 须管理像 Gas 使用或事件日志这样的侧信道考虑，以免它们泄露模式（fhEVM 设计力求通过对操作使用恒定 Gas 来实现数据无关的执行，以避免泄露）。 | 选择性： 证明揭示了公共输出中的内容或验证所必需的内容（例如，对初始状态的承诺）。设计者可以确保只揭示预期的结果，而所有其他输入都保持零知识隐藏。但与 FHE 不同，区块链通常不存储隐藏状态——隐私是通过将数据完全保留在链下来实现的。如果需要持久的私有状态，合约可以存储一个对其的密码学承诺（因此状态更新每次仍然会揭示一个新的承诺）。隐私受限于你选择证明的内容；你可以灵活地证明例如一个阈值被满足而无需透露确切的值。 |
| 完整性强制执行 | 通过设计，所有验证者都同态地重新计算下一个状态，因此如果一个恶意行为者提供了错误的密文结果，其他人会检测到不匹配——除非每个人都得到相同的结果，否则共识会失败。因此，完整性是通过冗余执行来强制执行的（就像普通区块链一样，只是在加密数据上）。通常使用额外的 ZK 证明来强制执行业务规则（例如，用户不能违反约束），因为验证者无法直接检查明文条件。 | 完整性由验证者合约检查 ZK 证明来强制执行。只要证明验证通过，结果就保证与链下程序的某个有效执行一致。正确性不需要诚实多数假设——即使是单个诚实的验证者（合约代码本身）也足够了。链上合约会简单地拒绝任何错误的证明或缺失的证明（类似于它会拒绝一个无效的签名）。一个考虑因素是：如果证明者中止或延迟，合约可能需要回退逻辑（或者用户可能需要稍后重试 ），但它不会接受不正确的结果。 |
| 开发者体验 | 优点：可以主要使用熟悉的智能合约语言（Solidity 等）及其扩展。机密性由平台处理——开发者主要关心加密什么以及谁持有密钥。加密合约和普通合约的组合是可能的，保持了 DeFi 的可组合性（只是带有加密变量）。缺点：必须理解 FHE 的限制——例如，没有特殊处理就不能直接对秘密数据进行条件跳转，电路深度有限（尽管 TFHE 中的自举允许任意长度的计算，但会牺牲时间）。调试加密逻辑可能很棘手，因为没有密钥就无法轻易地内省运行时值。此外，密钥管理和权限设置给合约设计增加了复杂性。 | 优点：链下部分可能可以使用任何编程语言（特别是使用 zkVM）。可以在链下程序中利用现有的代码/库（但要注意 ZK 兼容性）。如果使用通用的 ZKVM，开发者不需要自定义密码学——他们编写普通代码并获得一个证明。此外，重型计算可以使用永远无法在链上运行的库（例如，机器学习代码）。缺点：开发者必须协调链下基础设施或使用证明服务。处理异步工作流并将其与链上逻辑集成需要更多的设计工作（例如，存储一个待处理状态，等待回调）。编写高效的电路或 zkVM 代码可能需要学习新的约束（例如，没有浮点数，使用定点数或特殊原语；避免会使证明时间爆炸的重度分支；为约束数量进行优化）。还有处理证明失败、超时等的负担，这些在常规 Solidity 中不是问题。工具生态系统正在增长，但对许多人来说这是一个新的范式。 |
这两种方法都在积极改进中，我们甚至看到了融合：如前所述，ZKPs 被用于 FHE-VM 内部进行某些检查，反之，一些研究人员建议使 用 FHE 来保持 ZK 中证明者输入的私密性（这样云证明者就看不到你的秘密数据）。可以想象未来的系统会将它们结合起来——例如，在链下执行 FHE，然后向链证明其正确性，或者在链上使用 FHE，但向轻客户端 ZK 证明加密操作是正确完成的。每种技术都有其优势：FHE-VM 提供持续的隐私和实时交互，但计算成本高昂；而 ZK 协处理器提供可扩展性和灵活性，但有延迟和复杂性的代价。
用例与影响
可编程隐私的出现为各行各业开启了大量新的区块链应用。下面我们探讨 FHE-VM 和 ZK 协处理器（或混合方案）如何通过实现保护隐私的智能合约和安全的数据经济来赋能各个领域。
机密 DeFi 与金融
在去中心化金融中，隐私可以减轻抢先交易、保护交易策略，并在需要时满足合规要求，而无需牺牲透明度。机密 DeFi 可以让用户与协议互动，而无需向全世界透露他们的头寸。
- 私密交易与隐藏余额： 使用 FHE，可以在区块链 L1 上实现机密代币转账（加密的 ERC-20 余额和交易）或屏蔽池。没有观察者能看到你持有或转移了多少代币，从而消除了基于持仓的定向攻击风险。ZK 证明可以确保余额保持同步且没有双重花费（类似于 Zcash，但在智能合约平台上）。一个例子是机密 AMM (自动做市商)，其中池子的储备和交易在链上是加密的。套利者或抢先交易者无法利用该池，因为他们在交易结算前无法观察到价格滑点，从而减少了 MEV。只有在一定延迟后或通过访问控制机制，某些数据才可能被披露以供审计。
- 抗 MEV 的拍卖与交易： 矿工和机器人利用交易透明度来抢先交易。通过加密，你可以拥有一个加密的内存池或批量拍卖，其中订单以密文形式提交。只有在拍卖清算后，交易才会解密。这个概念，有时被称为公平订单流，可以通过门限解密（多个验证者集体解密批次）或通过 ZK 证明拍卖结果而无需透露单个出价来实现。例如，一个 ZK 协处理器可以在链下处理一批密封的出价，计算拍卖清算价格，并只输出该价格和获胜者以及证明。这保护了失败出价的公平性和隐私。
- 机密借贷与衍生品： 在 DeFi 借贷中，用户可能不希望透露他们的贷款或抵押品规模（这会影响市场情绪或招致利用）。FHE-VM 可以维护一个加密的贷款账本，其中每笔贷款的细节都是加密的。智能合约逻辑仍然可以通过操作加密的健康因子来强制执行清算条件等规则。如果一笔贷款的抵押率低于阈值，合约（在 ZK 证明的帮助下）可以标记其进行清算，而无需暴露确切的值——它可能只在明文中产生一个“是/否”标志。同样，秘密的衍生品或期权头寸可以在链上管理，只披露聚合的风险指标。这可以防止复制交易并保护专有策略，从而鼓励更多机构参与。
- 合规隐私： 并非所有金融环境都希望完全匿名；有时为了监管需要选择性披露。有了这些工具，我们可以实现受监管的隐私：例如，交易对公众是私密的，但受监管的 交易所可以解密或接收关于某些属性的证明。可以通过 ZK 证明*“这笔交易不涉及黑名单地址，且双方都经过 KYC 验证”*，而无需向链透露身份。这种平衡可以满足反洗钱 (AML) 规则，同时对其他人保密用户的身份和头寸。FHE 可以允许一个链上合规官合约扫描加密交易以寻找风险信号（例如，解密密钥仅在法院命令下才能访问）。
数字身份与个人数据
身份系统将从链上隐私技术中获益匪浅。目前，由于隐私法和用户的不情愿，将个人凭证或属性放在公共账本上是不切实际的。有了 FHE 和 ZK，自主身份可以以保护隐私的方式实现：
- 零知识凭证： 使用 ZK 证明（在一些身份项目中已经很常见），用户可以证明诸如*“我已年满 18 岁”、“我有有效的驾驶执照”或“我的收入超过 5 万美元（用于信用评分）”*之类的陈述，而无需透露任何其他个人信息。ZK 协处理器可以通过在链下处理更复杂的检查来增强这一点，例如，通过以类似 Axiom 的方式查询私有信用数据库来证明用户的信用评分高于某个阈值，只向区块链输出一个“是/否”的结果。
- DeFi 上的机密 KYC： 想象一个 DeFi 协议，根据法律必须确保用户经过 KYC。使用 FHE-VM，用户的凭证可以加密存储在链上（或通过 DID 引用），智能合约可以执行 FHE 计算来验证 KYC 信息是否符合要求。例如，一个合约可以同态地检查加密用户配置文件中的姓名和社保号是否与受制 裁用户列表（也加密）匹配，或者用户的国家是否不受限制。合约只会得到一个加密的“通过/失败”，可以由网络验证者门限解密为一个布尔标志。只有用户是否被允许的事实被揭示，保护了个人身份信息 (PII) 的机密性，并符合 GDPR 原则。这种选择性披露确保了合规性和隐私。
- 基于属性的访问与选择性披露： 用户可以持有一堆可验证的凭证（年龄、公民身份、技能等）作为加密属性。他们可以授权某些 dApp 对其进行计算，而无需披露所有内容。例如，一个去中心化的招聘 DApp 可以通过对加密的简历进行搜索（使用 FHE）来筛选候选人——例如，计算工作年限、检查是否有某个认证——只有在找到匹配项时，才在链下联系候选人。候选人的私人细节保持加密，除非他们选择透露。ZK 证明还可以让用户选择性地证明他们拥有属性的组合（例如，超过 21 岁且在某个邮政编码内），而无需透露实际值。
- 多方身份验证： 有时用户的身份需要由多方审查（例如，公司 A 的背景调查，公司 B 的信用检查）。使用同态和 ZK 工具，每个验证者可以贡献一个加密的分数或批准，智能合约可以将这些聚合为一个最终决定，而无需暴露单个贡献。例如，三个机构提供加密的“通过/失败”位，如果三个都是通过，合约就输出一个批准——用户或依赖方只看到最终结果，而不是哪个特定机构可能让他们失败，从而保护了用户在每个机构的记录隐私。这可以减少与例如一次失败的检查揭示特定问题相关的偏见和污名。
医疗保健与敏感数据共享
医疗数据高度敏感且受监管，但将来自多个来源的数据结合起来可以释放巨大价值（用于研究、保险、个性化医疗）。如果隐私问题得到解决，区块链可以为数据交换提供一个信任层。机密智能合约可以催生新的健康数据生态系统：
- 安全的医疗数据交换： 患者可以将其医疗记录的引用以加密形式存储在链上。一个支持 FHE 的合约可以允许研究机构对一组患者数据进行分析，而无需解密。例如，一个合约可以计算一种药物在加密的患者结果中的平均疗效。只有聚合的统计结果被解密出来（并且可能只有在包含最少数量的患者时，以防止重新识别）。患者可以通过贡献他们的加密数据进行研究而获得微支付，因为他们知道自己的隐私得到了保护，因为即使是区块链和研究人员也只能看到密文或聚合证明。这促进了一个尊重隐私的医疗保健数据市场。
- 保护隐私的保险理赔： 健康保险理赔处理可以通过智能合约自动化，这些合约可以在不向保险公司暴露数据的情况下验证医疗数据的条件。一份理赔可以包括一个加密的诊断代码和加密的治疗费用；合约使用 FHE 检查保单规则（例如，覆盖范围、免赔额）对该加密数据。它可以输出一个批准和支付金额，而无需向保险公司的区块链透露实际诊断（只有患者和医生有密钥）。ZK 证明可以用来证明患者的数据来自认证医院的记录（使用类似 Axiom 的东西来验证医院的签名或记录包含），而无需透露记录本身。这确保了患者隐私，同时防止了欺诈。
- 基因组与个人数据计算： 基因组数据极其敏感（它实际上是一个人的 DNA 蓝图）。然而，分析基因组可以提供有价值的健康见解。公司可以使用 FHE-VM 对用户上传的加密基因组进行计算。例如，一个智能合约可以在加密的基因组数据和加密的环境数据（可能来自可穿戴设备）上运行一个基因-环境风险模型，输出一个只有用户才能解密的风险评分。逻辑（可能是一个多基因风险评分算法）被编码在合约中并同态运行，因此基因组数据永远不会以明文形式出现。这样，用户可以在不向公司提供原始 DNA 数据的情况下获得见解——从而减轻了隐私和数据所有权方面的担忧。
- 流行病学与公共卫生： 在大流行等情况下，共享数据对于模拟疾病传播至关重要，但隐私法可能会阻碍数据共享。ZK 协处理器可以允许公共卫生当局通过证明向医院网络的数据提交诸如*“X 地区在过去 24 小时内有多少人检测呈阳性？”*之类的查询。每家医院将患者测试记录保留在链下，但可以向当局的合约证明阳性计数，而无需透露是谁。同样，接触者追踪可以通过匹配加密的位置轨迹来完成：合约可以计算患者加密位置历史的交集以识别热点，只输出热点位置（以及可能只有卫生部门才能解密的受影响 ID 的加密列表）。个人的原始位置轨迹保持私密。
数据市场与协作
在不泄露数据的情况下对其进行计算的能力为数据共享开辟了新的商业模式。实体可以在知道其专有数据不会被暴露的情况下进行计算协作：
- 安全的数据市场： 卖家 可以在区块链市场上以加密形式提供数据。买家可以付费通过智能合约在加密数据集上运行特定的分析或机器学习模型，获得训练好的模型或聚合结果。卖家的原始数据永远不会向买家或公众透露——买家可能只收到一个模型（其权重中仍可能泄露一些信息，但差分隐私或控制输出粒度等技术可以减轻这种情况）。ZK 证明可以向买家保证计算是在承诺的数据集上正确完成的（例如，卖家不能通过在虚拟数据上运行模型来作弊，因为证明将其与承诺的加密数据集联系起来）。这种情况鼓励了数据共享：例如，一家公司可以通过允许批准的算法在加密的用户行为数据上运行来将其货币化，而无需交出数据本身。
- 联邦学习与去中心化 AI： 在去中心化机器学习中，多方（例如，不同的公司或设备）希望在不相互共享数据的情况下共同训练一个模型。FHE-VM 在这里表现出色：它们可以实现联邦学习，其中各方的模型更新由合约进行同态聚合。因为更新是加密的，所以没有参与者能了解其他人的贡献。合约甚至可以在链上加密地执行部分训练循环（如梯度下降步骤），产生一个只有授权方才能解密的更新模型。ZK 可以通过证明各方的更新是按照训练算法计算的来补充这一点（防止恶意参与者毒害模型）。这意味着一个全局模型可以在链上进行完全可审计的训练，而每个贡献者的训练数据都保持私密。用例包括跨银行联合训练欺诈检测模型，或在不集中原始数据的情况下使用来自许多用户的数据改进 AI 助手。
- 跨组织分析： 考虑两家公司希望为合作活动找到他们的客户交集，而不想向对方暴露他们完整的客户列表。他们可以各自加密他们的客户 ID 列表并上传一 个承诺。一个支持 FHE 的合约可以在加密集上计算交集（使用像通过 FHE 的私有集交集等技术）。结果可能是一个加密的共同客户 ID 列表，只有相互信任的第三方（或客户自己，通过某种机制）才能解密。或者，一种 ZK 方法：一方以零知识向另一方证明*“我们有 N 个共同客户，这里是这些 ID 的加密”*，并附带一个证明，证明该加密确实对应于共同条目。这样，他们就可以对这 N 个客户进行营销活动，而无需交换完整的明文列表。类似的情景：在不透露单个供应商细节的情况下计算跨竞争对手的供应链指标，或银行在不共享完整客户数据的情况下整理信用信息。
- 区块链上的安全多方计算 (MPC)： FHE 和 ZK 基本上将 MPC 概念带到了链上。跨多个组织的复杂业务逻辑可以编码在智能合约中，使得每个组织的输入都是秘密共享或加密的。合约（作为 MPC 协调者）产生每个人都可以信任的输出，如利润分配、成本计算或联合风险评估。例如，假设几家能源公司希望结算一个电力交易市场。他们可以将加密的出价和报价输入到一个智能合约拍卖中；合约在加密的出价上计算清算价格和分配，并将每个公司的分配和成本只输出给该公司（通过加密到他们的公钥）。没有公司能看到其他公司的出价，保护了竞争信息，但拍卖结果是公平且可验证的。这种区块链透明度与 MPC 隐私的结合可以彻底改变目前依赖可信第三方的联盟和企业联盟。
去中心化机器学习 (ZKML 和 FHE-ML)
以可验证和私密的方式将机器学习引入区块链是一个新兴的前沿领域：
- 可验证的 ML 推理： 使用 ZK 证明，可以证明*“机器学习模型 f，在给定输入 x 时，产生输出 y”，而无需透露 x（如果它是私有数据）或 f 的内部工作原理（如果模型权重是专有的）。这对于区块链上的 AI 服务至关重要——例如，一个提供预测或分类的去中心化 AI 预言机。ZK 协处理器可以在链下运行模型（因为模型可能很大且评估成本高昂）并发布结果的证明。例如，一个预言机可以证明陈述“提供的卫星图像显示至少 50% 的树木覆盖率”*以支持碳信用合约，而无需透露卫星图像，甚至可能无需透露模型。这被称为 ZKML，并且有项目正在优化适合电路的神经网络。它确保了智能合约中使用的 AI 输出的完整性（没有作弊或任意输出），并可以保护输入数据和模型参数的机密性。
- 具有隐私和可审计性的训练： 训练一个 ML 模型计算量更大，但如果可以实现，它将允许基于区块链的模型市场。多个数据提供者可以在 FHE 下为训练模型做出贡献，以便训练算法在加密数据上运行。结果可能是一个只有买家才能解密的加密模型。在整个训练过程中，可以定期提供 ZK 证明，以证明训练遵循了协议（例如，防止恶意训练者插入后门）。虽然完全在链上进行 ML 训练由于成本原因还很遥远，但一种混合方法可以使用链下计算和 ZK 证明来处理关键部分。可以想象一个去中心化的类似 Kaggle 的竞赛，参与者在私有数据集上训练模型，并提交模型在加密测试数据上准确性的 ZK 证明来确定获胜者——所有这些都无需透露数据集或测试数据。
- 个性化 AI 与数据所 有权： 有了这些技术，用户可以保留其个人数据的所有权，同时仍然受益于 AI。例如，用户的移动设备可以使用 FHE 加密其使用数据，并将其发送到一个分析合约，该合约仅为他们计算一个个性化的 AI 模型（如推荐模型）。该模型是加密的，只有用户的设备才能解密和在本地使用。平台（也许是社交网络）永远看不到原始数据或模型，但用户获得了 AI 的好处。如果平台想要聚合的见解，它可以向合约请求某些聚合模式的 ZK 证明，而无需访问个人数据。
其他领域
- 游戏： 链上游戏通常难以隐藏秘密信息（例如，隐藏的牌手、策略游戏中的战争迷雾）。FHE 可以实现隐藏状态游戏，其中游戏逻辑在加密状态上运行。例如，一个扑克游戏合约可以洗牌并发放加密的牌；玩家获得自己牌的解密，但合约和其他人只看到密文。下注逻辑可以使用 ZK 证明来确保玩家没有在某个行动上虚张声势（或者在最后以可验证的公平方式揭示获胜的手牌）。同样，用于 NFT 铸造或游戏结果的随机种子可以生成并证明其公平性，而无需暴露种子（防止操纵）。这可以极大地增强区块链游戏，使其能够支持与传统游戏相同的动态。
- 投票与治理： DAO 可以使用隐私技术进行链上秘密投票，消除买票和压力。FHE-VM 可以统计以加密形式投出的选票，只有最终总数被解密。ZK 证明可以确保每张选票都是有效的（来自合格的选民，且未投过两次票），而无需透露谁投了什么票。这提供了可验证性（每个人都可以验证证明和计票），同时保持个人投票的秘密——这对于无偏见的治理至关重要。
- 安全供应链与物联网： 在供应链中，合作伙伴可能希望共享某些属性的证明（来源、质量指标），而不想向竞争对手暴露全部细节。例如，食品运输上的物联网传感器可以持续向区块链发送加密的温度数据。合约可以使用 FHE 检查在整个运输过程中温度是否保持在安全范围内。如果超过了阈值，它可以触发警报或罚款，但不必公开整个温度日志——也许只公开一个证明或一个聚合值，如*“第 90 百分位的温度”*。这在尊重过程数据机密性的同时，建立了对供应链自动化的信任。
这些用例中的每一个都利用了核心能力：在不泄露数据的情况下对数据进行计算或验证。这种能力可以从根本上改变我们在去中心化系统中处理敏感信息的方式。它减少了在处理私有数据的领域中限制区块链采用的透明度与隐私之间的权衡。
区块链技术正在进入一个可编程隐私的新时代，数据机密性与智能合约功能齐头并进。FHE-VM 和 ZK 协处理器的范式，虽然在技术上截然不同，但都致力于通过将我们能计算什么与我们必须揭示什么解耦来扩展区块链应用范围。
全同态加密虚拟机将计算保持在链上并加密，保留了去中心化和可组合性，但要求在效率上取得进步。零知识协处理器将繁重的工作转移到链下，在密码学保证下实现了几乎无限的计算，并已在扩展和增强以太坊方面证明了其价值。它们（及其混合方案）之间的选择将取决于用例：如 果需要与私有状态进行实时交互，FHE 方法可能更合适；如果需要极其复杂的计算或与现有代码集成，ZK 协处理器可能是更好的选择。在许多情况下，它们是互补的——事实上，我们看到 ZK 证明增强了 FHE 的完整性，而 FHE 可能通过为证明者处理私有数据来帮助 ZK。
对于开发者来说，这些技术将引入新的设计模式。我们将把加密变量和证明验证视为 dApp 架构的一等元素来思考。工具正在迅速发展：高级语言和 SDK 正在抽象化密码学细节（例如，Zama 的库使 FHE 类型像原生类型一样易于使用，或者 RISC Zero 的证明请求模板）。几年后，编写一个机密智能合约可能会感觉几乎和编写一个普通合约一样直接，只是默认“内置”了隐私。
对数据经济的影响是深远的。当个人和企业能够控制其数据的可见性时，他们将更愿意将数据或逻辑放在链上。这可以解锁以前因隐私问题而无法实现的跨组织协作、新金融产品和 AI 模型。监管机构也可能开始接受这些技术，因为它们允许通过密码学手段进行合规检查和审计（例如，在链上证明税款已正确支付，而无需暴露所有交易）。
我们仍处于早期阶段——目前的 FHE-VM 原型有性能限制，而 ZK 证明虽然比以前快得多，但对于极其复杂的任务仍然可能成为瓶颈。但持续的研究和工程努力（包括专用硬件，如 Optalysys 等公司推动的光学 FHE 加速所证明的）正在迅速消除这些障碍。涌入该领域的资金（例如，Zama 的独角兽地位，Paradigm 对 Axiom 的投资）突显了一种强烈的信念，即隐私功能将像透明度对 Web1/2 一样对 Web3 至关重要。
总之，通过 FHE-VM 和 ZK 协处理器实现的可编程隐私预示着一类新的 dApp，它们是无需信任、去中心化和机密的 。从不透露任何细节的 DeFi 交易，到保护患者数据的健康研究，再到在世界各地训练而无需暴露原始数据的机器学习模型——可能性是巨大的。随着这些技术的成熟，区块链平台将不再强迫在效用和隐私之间做出权衡，从而在需要机密性的行业中实现更广泛的采用。Web3 的未来是，*用户和组织可以自信地在链上处理和计算敏感数据，因为他们知道区块链将在保护他们秘密的同时验证完整性*。
来源： 本报告中的信息来自该领域领先项目的技术文档和最新研究博客，包括 Cypher 和 Zama 的 FHEVM 文档、Trail of Bits 对 Axiom 电路的详细分析、RISC Zero 的开发者指南和博客文章，以及强调机密区块链技术用例的行业文章。这些来源及更多内容已在全文中引用，以提供进一步的阅读和对所描述的架构和应用的证据。
