以太坊的开放、应用驱动的全同态加密 - 隐私

本文深入探讨了全同态加密（FHE）在以太坊中的应用，包括DeFi、治理、rollup和AI等多个用例。文章分析了现有FHE技术在以太坊生态中的角色及面临的技术挑战，提出了开放基准测试、可持续经济模型、可验证FHE（vFHE）以及去中心化密钥管理等潜在发展路径，并强调了应用驱动的方案选择、可验证性设计、安全密钥管理以及IND-CPAD安全性的核心考虑因素。

以太坊的开放、应用驱动的 FHE

我要衷心感谢 Andy Guzman、Christian Knabenhans、Eugene Joo、Gurgen Arakelov、Keewoo Lee、Nam Ngo、Rand Hindi、Sam Richards、Thore Hildebrandt、Younes Talibi Alaoui 和 Yuriy Polyakov 提供的慷慨反馈。

概括

  • 为什么这很重要（以及为什么它很难）： 全同态加密（FHE）能够在加密数据上进行计算，从而为以太坊智能合约、rollup 和 AI 应用解锁保密性。 然而，性能约束、去中心化密钥管理的难度，以及不断寻找隐私优势能够证明额外成本合理的应用，都减缓了它的采用。 克服这些挑战既需要技术创新，也需要可持续的经济模型。

  • 这里有什么：

    • 用例（DeFi、治理、rollup、AI）说明了不同的工作负载如何指向对 方案不可知性 的需求 —— 例如，TFHE 用于布尔逻辑，BFV/BGV 用于精确算术，CKKS 用于 ML 推理，以及 离散 CKKS 用于高吞吐量机密 DeFi 和会计。 它们还突出了对保密性至关重要到足以证明 FHE 当前成本合理的应用的探索。
    • 生态系统图谱 展示了参与者（Zama、Fhenix、Inco、Enclave、Phantom Zone、Sunscreen、Shutter Network、Flashbots、OpenZeppelin、Circle Research、Fair Math、OpenFHE）的多样化方法、仍然存在的技术差距以及互操作性的机会。
    • 潜在的前进道路 概述了进一步工作的领域，例如开放基准、可持续经济模型、可验证 FHE (vFHE) 和去中心化密钥管理。
    • 核心考虑因素 提炼了应指导开发的反思主题：应用驱动的方案选择、可验证性的需求、安全的密钥管理模型，以及反映真实世界对抗者的安全定义的需求。 与方案不可知性一致，讨论突出了不同的 FHE 方案如何映射到特定的以太坊用例，表明没有一种单一的方法足以满足所有工作负载。

目录

动机

以太坊拥有用于 可验证性 的强大工具（zkSNARK、rollup），但 保密性 仍然是一个缺失的支柱。 FHE 有望提供一种直接在加密状态下进行计算而无需解密的方法 —— 在保持以太坊信任模型完整的同时，实现机密的 DeFi、私有治理和可验证的 AI。

参与者

在深入探讨之前，先看一张概览图 —— 项目的完整列表和详细信息将在本文档的后面给出。

项目 他们做什么 以太坊连接
Zama FHEVM、TFHE-rs 库、机密 EVM 执行 支持 L2 工作； 机密 ERC-20 框架的创始成员
Fhenix 通过 FHE 协处理器实现机密以太坊智能合约 CoFHE 链下协处理器； 用于加密计算的 SDK
Inco 使用 FHE/MPC/TEE 的模块化保密层 连接到以太坊； 机密 ERC-20 框架的创始成员
Enclave 机密 FHE 协处理器层 以太坊 dApp 调用加密计算; 链上验证结果
Phantom Zone 加密 VM 研究 (RISC-V + Poulpy) 未来机密 EVM 的潜在运行时基础
Sunscreen FHE 编译器/SDK（“一个程序，任何链”） 链无关； 与以太坊 dApp 集成
Shutter Network 用于公平性的阈值加密 mempool 和 DAO 部署在 Gnosis 上； 正在寻求以太坊集成为防 MEV 工作流程提供支持
Flashbots MEV 供应链中的 FHE（“盲套利”） 探索加密交易流程以限制 MEV
OpenZeppelin 智能合约安全和标准； 机密 ERC-20 框架的共同开发者 维护 ERC-20/721 标准，并为机密代币设计贡献安全专业知识
Circle Research 基于 FHE 的隐私研究和机密 ERC-20 标准 共同撰写隐私框架； 确保以太坊中的合规性和可组合性
Fair Math 去中心化“FHE 计算机”+ FHERMA 挑战 用于结算/协调的以太坊端点
OpenFHE 领先的开源 FHE 库 (BFV/BGV/CKKS/TFHE/FHEW) 用于以太坊隐私研发的核心构建块

如果遗漏了任何参与者，请致歉 —— 请告知我们，我们将在未来的更新中添加他们。

区块链中 FHE 的用例

全同态加密（FHE）使得直接在加密数据上执行任意计算成为可能，同时始终保持数据的机密性。 这一突破使用户可以委托计算，而无需泄露其输入、输出或中间值。 在 Gentry 2009 年的结果之后，FHE 已经从一个理论上的里程碑发展成为一项最终变得实用的技术，具有具体的实现和快速提高的性能。 这种技术可以通过多种方式融入以太坊生态系统 —— 无论是作为智能合约执行的一部分（启用 FHE 的 EVM），还是作为去中心化应用程序的隐私保护层。 下面概述了其中一些潜在的用例。

以太坊和区块链中 FHE 潜在用例的完整列表

机密 DeFi 协议

私有稳定币
它的意义

用户可以铸造、持有和转移稳定币（例如，USDC 等价物），而他们的余额或交易历史记录不会在以太坊上公开可见。 所有金额都保持加密状态，但智能合约仍然可以验证转移。

为什么 FHE 有帮助
  • 与混币器（Tornado Cash）或基于 ZK 的屏蔽池不同，FHE 允许余额始终保持加密状态，而不仅仅是在转移期间。
  • 支持在智能合约中进行持续的加密余额管理。
挑战
  • 审计和合规性： 监管机构可能需要“查看密钥”或选择性披露 —— 在不损害隐私的情况下设计这一点很难。
  • 互操作性： 除非生态系统采用隐私标准，否则将私有稳定币与公共 DeFi 协议集成会破坏可组合性。
机密借贷
它的意义

用户存入抵押品并获得贷款，但贷款规模或抵押品类型/金额对公共区块链都不可见。

为什么 FHE 有帮助
  • 智能合约可以在不知道实际数字的情况下，对加密余额强制执行还款逻辑。
  • 风险参数（抵押率、清算触发器）可以在密文上进行评估。
挑战
  • 清算： 如果抵押率下降，清算人需要采取行动 —— 但加密状态会隐藏谁的抵押不足。 协议必须揭示足够的信息来进行清算，而不会破坏整体隐私。
  • 利息累计： 连续同态乘法（用于复利）比加法重得多； 需要像 CKKS 这样的近似方案，这会使精确值保证复杂化。
  • 跨协议集成： 借来的私有资产可能无法在公共 DeFi 中直接使用（例如，在公共 AMM 中使用私有 DAI），从而限制了效用。
私有自动做市商 (AMM)
它的意义

流动性提供者可以为资金池做出贡献，交易者可以交换资产，而无需向公众透露资金池大小、交易量或订单详细信息。

为什么 FHE 有帮助
  • 订单流和流动性头寸保持加密，防止抢先交易和 MEV 提取。
  • 定价公式（例如，x*y=k）可以在密文上强制执行。
挑战
  • 计算成本： AMM 数学涉及乘法/除法 —— 在 FHE 中成本很高（尤其是除法）。
  • 滑点和价格发现： 如果资金池状态被加密，外部参与者将无法观察到价格变化。 需要一些部分披露或预言机机制来保持市场正常运行。
  • MEV 与可验证性： 加密交换可以防止抢先交易，但矿工/验证者仍然需要密码学证明（ZK 或 vFHE）来验证交易是否遵循资金池规则。
  • 公共信号需求： 交易者和套利者需要最低程度的可见性 —— 例如当前价格、时间加权平均价格 (TWAP) 或汇总的流动性信息 —— 才能使市场保持高效。 如果没有公共信号，流动性就会变成“暗流动性”：它以加密或隐藏的形式存在，但由于参与者缺乏报价、套利或重新平衡头寸所需的信息，因此无法支持有意义的价格发现。

隐私保护治理

密封投标投票
它的意义

DAO 可以在不泄露个人偏好的情况下进行选举和投票，同时仍能证明计票的正确性。 系统必须执行一个 计票步骤：将所有加密选票组合成一个聚合结果，该结果可以解密和验证，而无需暴露单个选票，而不是计算明文选票。

为什么 FHE 有帮助
  • 投票保持端到端加密。
  • 可以在密文上直接计算计票（例如，同态加法运算 Enc(YES) 和 Enc(NO) 选票），确保不会泄露任何个人投票。
  • 只需要解密最终聚合（例如，“132 YES / 87 NO”），而不是单个选票。
挑战
  • 加权投票： 基于代币或二次投票方案需要在加密值上进行乘法运算，这会更加昂贵。
  • 中心化信任和密钥管理： 如果单个协调者持有 FHE 解密密钥，他们可能会窥视个人投票或提前泄露部分计票。 安全的设计需要 阈值密钥共享（在多个方之间拆分解密密钥）和/或 可验证的解密证明，以消除单点信任。

Rollup 和协处理器

隐私 Rollup
它的意义

Rollup 是一种Layer2扩展解决方案，可在链下处理交易，但会将紧凑的证明或摘要发布回以太坊以确保安全。 通过将许多交易批量处理为一个交易，rollup 降低了成本，同时仍然继承了以太坊的安全保证。

  • Optimistic rollup（例如，Arbitrum、Optimism）默认假定交易有效，但允许任何人在出现错误时通过 欺诈证明 质疑不正确的状态更新。
  • zk-rollup（例如，zkSync、Scroll、StarkNet）要求每个状态更新都附带一个 有效性证明（通常是 zk-SNARK 或 zk-STARK），以太坊可以有效地验证该证明。

在这两种设计中，rollup 状态（余额、合约）通常是 公开可见的。

隐私 rollup 则保持整个状态加密。 用户私下进行交易，只有加密的状态转换加上有效性证明会发布到以太坊。

为什么 FHE 有帮助
  • Rollup 运营商永远看不到明文状态或交易。
  • Rollup 用户的端到端保密性。
  • 加密执行可以与有效性证明相结合，以同时保留 隐私性 和 无信任性。
挑战
  • 可验证性： 必须设计欺诈证明或有效性证明，以便与加密状态转换一起使用。
  • 性能： Rollup 转换的同态评估非常耗费资源。
  • 可组合性： 除非经过精心设计，否则与公共 L1 合约的互操作性受到限制。
加密执行协处理器
它的意义

繁重的 FHE 计算（例如，AI 推理、模拟或私有 DeFi 逻辑）可以在链下运行，结果在链上进行验证和结算。

为什么 FHE 有帮助
  • 通过卸载复杂的计算，降低了以太坊 gas 成本。
  • 实现了私有 AI 推理或加密模拟等用例。
挑战
  • 去中心化： 协处理器不得成为中心化的信任瓶颈。
  • 证明： 用于验证加密计算的当前证明系统 (vFHE) 尚不成熟。

  • 延迟： 与原生 EVM 执行相比，链下 FHE 执行加上验证会引入延迟。

    fhe

AI 中 FHE 和区块链的用例

除了区块链本身，FHE 和去中心化账本的融合还扩展到了 AI 领域。 区块链和 FHE 的结合可以使 AI 系统以保护隐私、保证可验证性以及支持去中心化治理的方式进行训练、部署和使用。 这种集成可确保敏感数据受到保护，模型输出可以被信任，并且对强大 AI 系统的控制权不会集中在少数人手中。 以下各节概述了说明这些可能性的潜在用例。

AI + FHE 用例的完整列表

隐私保护 AI 推理

医疗保健
它的意义

患者可以使用其私有健康记录查询 AI 诊断模型，而无需向医院、保险公司或云提供商披露记录。

为什么 FHE 有帮助
  • 健康数据保持端到端加密。
  • 模型直接处理密文，只有结果（例如，诊断概率）会被解密。
  • 防止因中心化数据存储而引起的泄露。
为什么区块链有帮助
  • 提供查询和结果的可审计日志，而无需泄露患者数据。
  • 启用医疗 AI 模型的去中心化治理（例如，决定哪些医院或研究人员可以更新它们）。
  • 消除单点信任 —— 患者通过开放协议进行交互，而不是通过专有孤岛进行交互。
挑战
  • 性能： 在 FHE 下对深度模型进行推理仍然成本高昂。
  • 部分披露： 监管机构可能需要选择性可审计性。
  • 集成： 医院必须相信加密推理是正确的 → 需要可验证的 FHE。
金融
它的意义

投资者可以在敏感的财务数据上运行风险模型或投资组合分析，而无需向经纪人或服务提供商泄露其头寸。 投资组合头寸 是指投资者持有的特定资产和分配（例如，股票的数量、ETH 的数量、债券的价值）。 这些头寸高度敏感，因为它们揭示了交易策略和风险敞口。

为什么 FHE 有帮助
  • 在模型计算性能或风险（例如，波动率、风险价值）时，保持投资组合头寸加密。
  • 启用机密的“压力测试”和合规性检查，而无需披露个人持股。
为什么区块链有帮助
  • 充当 中立的结算层：区块链以防篡改的方式记录付款、分析请求和结果，确保投资者和模型提供商都不能更改结果。
  • 审计员可以验证模型的执行是否符合商定的智能合约，而无需依赖中心化机构。
  • 鼓励公平的风险模型市场，因为结算在链上进行，而不是通过单个经纪人或中介机构进行。
挑战
  • 复杂模型： 风险引擎使用繁重的计算（矩阵乘法、特征值分解），这在 FHE 下非常昂贵。
  • 延迟： 市场环境需要实时推理，但 FHE 会引入开销。
  • 信任： 需要证明加密结果与加密输入正确对应。

可验证的 AI 输出

可审计的财务预测
它的意义

监管机构和审计员可以检查用于交易、风险评分或信用决策的 AI 模型是否已正确执行，而无需泄露输入数据。

为什么 FHE 有帮助
  • 模型直接在加密输入上运行。
  • 在不泄露敏感市场/客户数据的情况下，揭示最终决策。
为什么区块链有帮助
  • 为争议提供中立的结算层（例如，证明合规性）。
  • 使结果公开可验证，而无需信任单个运营商。
挑战
  • vFHE 成熟度： 正确加密推理的证明是早期研究。
  • 可扩展性： 大规模验证许多推理成本高昂。

去中心化 AI 治理

协同训练
它的意义

多个组织在链上强制执行治理规则的情况下，共同训练加密数据模型。

为什么 FHE 有帮助
  • 在训练期间保持每个数据集加密。
  • 防止参与者之间的数据泄露。
为什么区块链有帮助
  • 强制执行治理规则（例如，谁可以更新模型、如何分配奖励）。
  • 提供透明的协调和争议解决机制。
挑战
  • 训练成本： FHE 训练仍然非常昂贵。
  • 可验证性： 确保模型更新是在加密数据上 诚实计算 是很困难的。 如果没有证明，恶意参与者可能会注入有毒梯度或跳过计算，同时仍然声称获得奖励。 目前的研究正在探索 可验证的 FHE (vFHE) 和 正确训练步骤的 ZK 证明，但这两种方法仍处于早期阶段。

key\ key2872×608 69.1 KB

以太坊世界中的 FHE 参与者

本节介绍在以太坊和相关生态系统中研究 FHE 的主要参与者。 最好根据上述挑战和用例来理解他们的努力：实现机密 DeFi 协议、隐私保护治理、安全数据共享、可扩展的 rollup 以及隐私增强的 AI。 每个参与者都贡献了不同的部分 —— 从核心密码学库、到开发人员友好的 SDK、到实验性 rollup 架构 —— 这些共同旨在使完全私有、可验证和去中心化的计算在以太坊上成为可能。

影响以太坊上 FHE 的项目、框架和库的完整列表

Zama

  • 他们做什么：Zama 构建开源 FHE 库，并且是将 FHE 应用于区块链的主要驱动力之一。

  • 核心技术：

    • TFHE-rs：TFHE 方案的 Rust 实现，针对快速引导和按位运算进行了优化。
    • Concrete Framework：一套用于在生产系统中处理 FHE 的开发工具。

  • 以太坊背景：

    • FHEVM 是 Zama 的核心产品，使智能合约可以直接在加密状态下进行计算。
    • Zama 协议 已在 Sepolia 上线（并将很快在以太坊主网和其他 EVM 上线）。
  • 网站：Zama.ai

Fhenix

  • 他们做什么：

Fhenix 构建工具，使以太坊智能合约能够处理加密数据，而无需开发人员对密码学有深入的了解。 他们的 CoFHE 协处理器以最小的摩擦实现全同态加密计算。

  • 架构：
    • CoFHE（FHE 协处理器）：一种链下服务，对加密值执行同态计算，并将结果安全地发送回合约。 开发人员通过熟悉的 Solidity 模式进行交互，而繁重的密码学在后台进行。
  • 以太坊集成：
    • CoFHE 目前已在公共测试网上线：Ethereum Sepolia 和 Arbitrum Sepolia。 开发人员可以部署启用 FHE 的智能合约，并通过 Fhenix 工具进行交互。
  • 关于演变的说明：

Fhenix 最初提出了一个“FHE Rollup”设计，但已转向一个模块化的 CoFHE 协处理器模型，该模型可以插入到现有的 EVM 兼容链中。

Inco

  • 他们做什么：Inco 正在为区块链构建一个 保密层，该层由 FHE 和 MPC 和 TEE 等互补技术提供支持。 他们的目标是使智能合约和去中心化应用程序默认情况下是保密的，同时仍然可以与更广泛的以太坊生态系统互操作。

  • 主要特点：

    • 加密状态和交易，直接通过 FHE/MPC 进行计算。
    • 开发人员工具，因此合约可以声明加密变量。
    • 设计为 模块化服务，因此可以将保密性集成到不同的区块链环境中。

  • 以太坊连接：

    • 提供互操作性，因此以太坊开发者可以将 ERC-20 代币桥接到 机密 ERC-20。
    • 将自己定位为模块化区块链堆栈的“机密计算层”，补充了以太坊作为结算和流动性枢纽的角色。
    • Confidential ERC-20 Framework 的创始成员之一，与其他生态系统参与者合作，定义机密代币的标准。
  • 白皮书：Inco 协议

Phantom Zone

  • 他们做什么：

Phantom Zone 研究和构建完全加密的运行时。 他们的旗舰项目 phantom 是一个由内部 FHE 库（Poulpy）提供支持的 加密 RISC-V 虚拟机。 开发人员用 Rust 编写程序，将它们编译成加密的 RISC-V 二进制文件，并在加密输入上执行它们 —— 常量、指令和状态都保持隐藏。 目标是使任意程序能够在加密数据上安全地运行。

  • 架构：
    • Poulpy（FHE 库）： 一个通用的 FHE 库，支持方案切换、阈值密钥生成和引导。
    • phantom（加密 RISC-V VM）： 直接通过密文执行 RISC-V 二进制文件，从而创建一种新的“加密程序”范例。
    • 研究驱动型设计： 优先考虑加密计算的基础原语，而不是立即进行 dApp 集成。
  • 以太坊连接：
    • Phantom 不是以太坊 L2 或链，但可以为将来与以太坊集成的机密执行层提供 运行时基础。
    • 他们的重点是 底层加密 VM 设计，而不是 Solidity/EVM 兼容性。
  • 网站：phantom.zone

Enclave (Enclave.gg)

  • 他们做什么：Enclave 为 Web3 提供 基于 FHE 的机密计算基础设施，重点关注 DeFi 和治理。 他们的目标是使私有计算成为一种模块化服务，dApp 和协议可以调用该服务，而无需自己构建密码学。

  • 架构：

    • 机密 DeFi：支持对加密状态执行交换、借贷或投资组合管理等操作，以便策略、头寸和余额保持私有。
    • 使用 CRISP 进行治理：提出机密治理框架（例如，CRISP – 机密、可靠和激励的安全协议），该框架允许加密投票和提案评估。 这确保了选民的偏好保持隐藏，而结果仍然可以验证。
    • FHE 协处理器：链下协处理器对加密输入执行同态计算，并将证明/可验证结果返回到调用智能合约。
    • 去中心化密钥管理：基于阈值的方案在多方之间分配信任，避免了解密中的单点妥协。

  • 以太坊连接：

    • 目标是希望在不离开以太坊生态系统的情况下保持交易、策略或头寸私有的以太坊 DeFi 协议。
    • 机密治理模块可以直接插入以太坊 DAO，从而使项目能够进行 具有公开可验证性的私有投票。
    • Enclave 将自己定位为以太坊合约可以调用的 机密执行层，类似于预言机，但用于私有计算。
  • 白皮书：Enclave 白皮书

Sunscreen

  • 他们做什么：

Sunscreen 正在构建一个 安全处理框架 (SPF) —— 一个全同态加密 (FHE) 的编译器和运行时，使开发人员可以“自带程序”并将其部署到各个区块链上。 它的目标是为暗池、私有预测市场、ML 推理等隐私保护应用程序提供支持，同时确保可验证的隐藏状态。

  • 架构：
    • “一个（FHE）程序，任何链”：开发人员可以用 Rust（或其他主流语言）编写应用程序，标记敏感输入/输出，并让 Sunscreen 将逻辑编译成可在加密数据上运行的启用 FHE 的代码。
    • 以 TFHE 为重点的编译器：他们的新编译器生成针对 Torus FHE (TFHE) 方案进行了优化，支持任意长度的计算 —— 非常适合动态和不断发展的应用程序。
    • 可验证的隐藏状态：支持输入保持机密且输出有选择地披露的场景 —— 例如，未匹配订单永远不会被披露的私有双重拍卖。
  • 以太坊/区块链连接：
    • 专为 链无关集成 而设计，可在以太坊内外的链上启用机密有状态计算。
    • 支持隐私保护的 DeFi 原语，例如暗池和机密 AMM、安全的链上 ML 推理以及具有可验证性的私有状态转换。
  • 网站：Sunscreen

Shutter Network

  • 他们做什么： Shutter Network 开发阈值加密协议，通过 加密 mempool 和 屏蔽投票 来保护 DeFi 和 DAO 交互。 其目标是在保持公平、抗审查执行的同时，减少恶意 MEV 和抢先交易。 他们还提供了一个 Shutter API，以便轻松进行 dApp 集成。
  • 架构：
    • 具有分布式密钥生成 (DKG) 的 阈值加密，可在显示/最终确定之前保持交易的机密性。
    • 屏蔽交易（加密 mempool）、屏蔽投票（DAO 机密投票）和面向开发人员的 API。
  • 以太坊连接：
    • 部署在 Gnosis Chain 上； 致力于以太坊主网集成，以实现 MEV 保护和跨 EVM 生态系统的公平排序。

Flashbots

  • 关注领域：探索 MEV（最大可提取价值） 供应链中的 FHE。

  • 概念：“盲套利”

    • 交易在 FHE 下加密。
    • 搜索者/构建者在看不到明文的情况下盲目地运行策略。
    • 仅在区块排序最终确定后才进行解密。

  • 以太坊背景：

    • 通过隐藏 mempool 内容来防止抢先交易和尾随交易。
  • 白皮书：盲套利

OpenZeppelin

  • 他们做什么：OpenZeppelin 是 智能合约安全性、标准和开发人员工具 的领先提供商。 他们维护着被广泛采用的 ERC-20 和 ERC-721 标准，并提供经过审计、可用于生产的实现。 作为 Confidential ERC-20 Framework 的创始成员，他们正在为隐私保护代币和机密 DeFi 做出贡献。

  • 主要特点：

    • 维护以太坊上使用的规范 ERC-20/721 库。
    • 为关键任务协议提供 安全审计 和最佳实践。
    • 为集成 FHE 的 机密 ERC-20 代币 的设计和规范做出贡献。
    • 在 已建立的以太坊标准 和新兴的机密代币生态系统之间架起桥梁。

  • 以太坊连接：

    • 他们的库支持部署在以太坊上的大多数 ERC-20 代币和 DeFi 项目。
    • 通过帮助标准化机密代币，OpenZeppelin 确保了整个以太坊生态系统的 兼容性、安全性和采用 。
  • 网站：OpenZeppelin
  • 机密代币倡议：confidentialtoken.org

Circle Research

  • 他们做什么：Circle Research 是 Circle 的研究部门，专注于推进开源密码学和区块链标准。 他们共同撰写了 Confidential ERC-20 Framework，为 ERC-20 代币带来了基于 FHE 的隐私保护。

  • 主要特点：

    • 共同撰写了 机密 ERC-20 代币 的基础设计，这些代币使用 FHE 隐藏余额和交易金额。
    • 提出了 加密余额、委托查看 和 用于合规性的可编程传输规则 等功能。

  • 以太坊连接：

    • 该框架将现有的 ERC-20 代币转换为隐私保护的包装版本，这些版本在整个以太坊和 EVM 链上仍然完全可组合。
    • 机密 ERC-20 框架 的创始成员之一，与 Inco、Zama 和 OpenZeppelin 合作。
  • 博客/白皮书：揭示机密 ERC-20 框架

Fair Math

  • 他们做什么：一家研究驱动型公司，致力于构建去中心化 FHE 计算机 平台，用于对加密数据进行安全计算； 还运营 FHERMA 挑战平台，以众包 FHE 组件。

  • 架构：

    • FHE 计算机：用于加密工作负载的模块化、去中心化执行（应用程序、协调、验证、执行、数据层）。
    • 用于底层同态运算的 POLYCIRCUIT 组件。
    • 用于社区主导的库构建的 FHERMA。

  • 以太坊连接：

    • 用于加密结果的链上结算/协调的 以太坊端点。
    • 具有可验证性的加密分析用例（例如，欺诈检测）。
  • 网站：Fair Math

OpenFHE

  • 他们做什么：OpenFHE 是 全同态加密 (FHE) 的领先开源库，为开发人员和研究人员提供标准化工具来构建隐私保护应用程序。 它是先前开源项目（例如 PALISADE、IBM HELib、HEAAN、FHEW 和其他学术努力）的继任者，并将它们合并到一个现代平台中

  • 架构：

    • 方案：BFV/BGV（精确整数）、CKKS（近似实数）、TFHE/FHEW（带引导的按位运算）、离散 CKKS。
    • 生态系统：基准测试工具、C++/Python API、CPU/GPU 后端、混合 MPC/ZK 集成路径。

  • 以太坊连接：

    • 区块链隐私研究和原型中使用的核心构建模块。
    • zk+FHE 混合、加密 rollup、保密 DeFi 以及加密数据上的 ML 推理的自然基础。

  • 网站：OpenFHE

    • *

比较：以太坊中的 ZK 与 FHE

特性 ZK FHE
隐私性 输入公开；通过证明隐藏 witness 输入和状态保持加密
成熟度 生产级 rollup 测试网、原型、研究
性能 证明验证迅速 自举过程繁重（正在改进）
用例 可扩展性、可验证性 保密智能合约、私有 DeFi
关键挑战 证明者/验证者效率 加密评估和密钥管理

可能的前进方向

以太坊中 FHE 的进展不太可能来自单一的突破。更现实的情况是，多条研究和开发路线可以并行推进，每条路线都有助于解决挑战的不同方面。以下方向概述了增量改进可能为更广泛的应用打开大门的领域：

  1. 用开放基准量化开销：

为了从理论走向实践，社区将受益于标准化的开源基准。衡量在 FHE 下运行代表性以太坊工作负载（例如，Uniswap 交换、Compound 贷款）的开销可以指导优化工作，并为性能提供现实的期望。

  1. 设计可持续的经济模型：

使隐私在实践中可用还需要可行的激励措施。潜在的方法包括：

  • 协议提供的 基于 Token 的补贴，以抵消隐私开销。
  • 用户选择加入并为保密交易支付溢价的 混合模型。
  • 共享安全模型，其中激励解密或验证网络诚实行事。
    1. 推进 vFHE 以实现去中心化信任：

需要进一步的工作来使 FHE 执行的零知识证明更加高效和简洁。公共可验证性在 Web3 中至关重要，而可扩展的 vFHE 是确保运营商在处理加密数据时不会作弊的有希望的途径之一。

同时，可信执行环境 (TEE) 仍然是一个活跃的探索领域。虽然它们依赖于硬件信任假设，并且不如密码学证明那样有弹性，但 TEE 可以为可验证性提供更短期的途径，并且可以作为混合解决方案与 vFHE 集成——在今天的实用性与明天的更强保证之间取得平衡。

有关 vFHE 周围正在进行的工作和开放挑战的更详细讨论，可以在下面的专门部分中找到。

  1. 探索去中心化密钥管理模型：

超越固定委员会是一个中心挑战。研究 阈值 FHE（其中解密密钥分布在一组动态的参与者中）和 多密钥 FHE 与代理重加密相结合，可以帮助消除中央故障点，同时保持系统与 Web3 分布式信任的精神一致。

有关 密钥管理和去中心化 的进一步考虑和正在进行的研究方向将在下面的部分中更详细地探讨。

核心考虑因素

当生态系统尝试以太坊上 FHE 的不同架构时，很容易迷失在性能基准或小众协议设计中。但是，长期可持续性较少依赖于短期优化，而更多地依赖于指导跨项目开发的 明确的设计优先级。

我们确定了四个核心原则：应用驱动的方案选择、设计上的可验证性 (vFHE)、安全密钥管理以及以太坊上下文中的 IND-CPAD 级别安全性。下面将详细讨论每个原则。

1) 应用驱动的方案选择

不同的 FHE 系列在不同的工作负载中表现出色，具体取决于延迟要求、数据类型和精度需求。

  • BFV / BGV → 用于结算、会计、链上规则评估、PIR、PSI 以及私有智能合约/数据库查询的精确整数算术。

  • TFHE / FHEW → 低延迟布尔电路、链上策略检查以及使用查找表对任意函数进行标量评估。

  • CKKS → 用于加密分析/ML/AI、DeFi 风险建模的近似算术。

  • 离散 CKKS → 使用查找表（向量化 TFHE/FHEW）对任意函数进行高吞吐量精确评估；可以与 BFV 或 CKKS 耦合。

    • *
TFHE / FHEW

最适合

  • 对加密交易进行低延迟策略强制执行（amount ≤ limit?、KYC passed?）。
  • 智能合约中的私有访问控制。
  • 通过 LUT 对任意函数进行标量评估以进行即时决策。
  • 延迟至关重要的链下协处理器检查。

工作原理

  • 位级或小整数处理：一个 ciphertext = 1 位或最多 8 位。
  • 计算逐个 门（AND、OR、XOR、NOT）进行。
  • 每个门内置自举 → 支持具有恒定延迟的深度、决策密集的逻辑。
  • 用于小整数的可编程自举可用于构建任意计算能力。

优势

  • 适用于小型、逻辑繁重的检查。
  • 精确（位完美）的正确性。

局限性

  • 没有 SIMD 批处理——对于批量数据处理（例如，扫描整个状态）的吞吐量较差。

  • 多位算术需要许多门 → 对于大规模金融计算来说速度较慢。

  • 大的 plaintext-to-ciphertext 扩展因子：每个加密位都会膨胀成一个大的 ciphertext，从而产生大量的存储、计算和通信开销。这种可扩展性瓶颈限制了对小型、延迟关键逻辑的应用，而不是批量加密处理。

    • *
BFV / BGV

最适合

  • 对加密余额、Token 数量、计数器进行精确的整数运算。
  • PIR/PSI 用于查询加密的链上或链下状态，而不会泄露查询。
  • 需要精确算术的私有结算、拍卖和订单匹配。
  • 用于与链上证明集成的链下存储的加密数据库查询。

工作原理

  • 在每个 ciphertext 插槽中对模 ( q ) 的整数进行运算。
  • 支持 SIMD 批处理——在一个 ciphertext 中处理数千个整数。
  • 通常可以通过选择参数来匹配计算深度来避免自举。

优势

  • 精确、位完美的结果——对于财务正确性至关重要。
  • 对于大型数据集上的向量/矩阵样式操作非常高效。
  • 通过批处理实现的并行性适合许多区块链数据聚合任务。

局限性

  • 比较/分支逻辑比 TFHE/FHEW 中更昂贵/更具挑战性。

  • 需要参数调整以避免在深度计算中进行自举。

    • *
CKKS

最适合

  • 通过 DeFi 交易数据进行的加密分析。
  • 对加密的用户指标（例如，信用评分）进行的私有 ML/AI 推理。
  • 使用浮点型算术进行风险建模和 AMM 参数优化。
  • 对大型加密数据集进行高吞吐量处理。

工作原理

  • 使用 SIMD 批处理编码近似实数/复数。
  • 用于大规模数值工作负载的高效多项式/算术运算。

优势

  • 通常是用于实数算术和 ML/AI 的主要 FHE 方案。
  • 高效地处理大规模近似算术。
  • 用于高吞吐量的批处理适合分析和 ML 管道。

局限性

  • 不精确——本质上不适合等式检查、阈值规则或结算值。

    • *
离散 CKKS
  • 提供与 TFHE/FHEW 相同的功能，但用于批量处理。
  • 实现比 TFHE/FHEW 高 2-3 个数量级的吞吐量。
  • 对于大小高达数百的向量（对于小精度运算），比 TFHE/FHEW 慢。对于更大的向量或大精度运算，比 TFHE/FHEW 快。
  • 非常适合数据的离线批量处理。
总结表
方案 数据类型 SIMD 精确？ 最适合
TFHE/FHEW 布尔值（位级） 否 是 低延迟链上策略检查、私有访问控制
BFV/BGV 整数（mod q） 是 是 结算、PIR、PSI、加密数据库查询
CKKS 实数/复数（近似） 是 否 对 DeFi 数据进行加密分析、ML/AI
离散 CKKS 整数/定点数（离散） 是 是 保密 DeFi（余额、利息、清算）、私有支付、治理投票、加密会计

2) 设计上的可验证性 (vFHE)

在 Web3 中，可验证性不是可选的：与依赖于对中心化供应商的信任的 Web2 系统不同，区块链用共识代替信任，其中每个验证者必须独立检查正确性。这使得 公开可验证的正确性 成为核心安全属性。

同态计算通过引入一个根本性的挑战使情况变得复杂：验证者如何验证链下 FHE 计算是否诚实地执行？ 如果没有解决方案，验证者要么必须 信任 专业的评估者（与去中心化相矛盾），要么尝试自己重新计算繁重的 FHE 电路。因此，推动 可验证 FHE (vFHE)。

以太坊中可验证性的设计选项：

A. 携带证明的 FHE（简洁的参数）

评估者返回 (Enc(f(x)), π)，其中 π 是一个 简洁的参数，即 ciphertext 转换与电路 f 的 FHE 语义相匹配。这反映了 zk-rollup 验证：链上成本是证明验证。

  • 来自通用 SNARK 的 vFHE (2024)

  • Zama 的 vFHE 自举演示 (2024)。

Zama 表明，可以使用 Plonky2 IVC 通过 SNARK 证明 TFHE 可编程自举：证明时间约为 18-48 分钟，验证时间约为 5-10 毫秒（取决于硬件）。这是研究/PoC，还不是完整的管道，但证明了最困难步骤的可行性。

Zama 博客

  • HasteBoots (2025)。

一个专为 FHEW/TFHE 自举 构建的简洁参数系统（ePrint 2025/261）。

使用 自定义多项式 IOP 加上优化的 多项式承诺方案（带有打包）以实现 秒级证明（例如，在 Apple M4 上进行实验时约为 3 秒）。

由于 ciphertext 是不透明的，因此无需零知识；重点完全在于 FHE 关系的正确性（NTT、提升、累加器更新、模数切换）。

对以太坊的影响。

携带证明的 FHE 集成干净：评估者（协处理器）发布 (ciphertext, proof)；验证者合约检查 π 并更新加密状态。

ZK 在这里是可选的——可靠性和简洁性最重要。

B. 可信硬件证明 (TEE)

另一种方法是在 可信执行环境 (TEE)（例如 Intel SGX 或 AMD SEV）中执行 FHE 计算。TEE 提供了一个受硬件保护的 enclave，即使面对恶意的 host，代码和数据也保持机密和防篡改。

当 enclave 初始化时，TEE 会执行 测量：它计算加载到 enclave 中的程序代码和关键配置的加密哈希值（例如，SHA-256）。此哈希值唯一标识正在执行的二进制文件。然后，硬件生成 证明报告，其中包含：

  1. Enclave 的测量值（加载代码的哈希值）。
  2. 使用供应商（Intel、AMD）提供的硬件信任根密钥生成的此测量值的数字签名。

证明 可以与加密的计算结果一起发送。外部验证者（例如以太坊智能合约或链下验证器服务）检查：

  • 供应商在证明上的签名是否有效。
  • 测量值是否与预期参考哈希值（已知、经过审查的二进制文件，用于实现 FHE 评估）相匹配。

如果两个检查都成功，则验证者可以确信计算是由预期的 enclave 代码执行的，并且输入在执行期间保持机密。这种方法避免了对繁重的密码学证明的需求，但其 安全模型较弱：它取决于硬件供应商的保证和证明基础设施的完整性，而不是纯粹依赖于密码学。

C. 重新执行/冗余

在此模型中，评估者发布 ciphertext 状态更新，而不附加证明。验证者（或指定的挑战者）可以独立地在链下重新执行 FHE 计算以检查正确性。如果发现差异，将触发欺诈证明式争议机制，逐步重放计算，直到找到错误。

这实际上是应用于 FHE 的 乐观 rollup 方法：默认情况下假定正确性，并且仅在受到质疑时才进行验证。优点是在链上的前期成本最低——无需为每次更新生成或验证繁重的证明。缺点是重新执行 FHE 电路仍然需要大量的计算，并且安全性取决于至少一个诚实验证者将重新运行计算并在必要时提出争议的假设。

但是，与公共状态 rollup 相比，存在一个额外的微妙之处。如果恶意的 ciphertext 泄露并通过乐观方式被接受，则稍后解密它的用户可能会无意中充当 反应预言机。即使没有看到 plaintext，攻击者也可以观察用户的行为方式——例如，他们是继续、中止还是后续交互失败。由于基于 LWE 的 FHE 方案中的解密将 plaintext 直接与密钥联系起来，因此原则上可以在 选择 ciphertext 样式的密钥恢复攻击 中利用此类反应信号。这种风险在正常的 rollup 中不会出现，并突出了为什么将乐观模型应用于 FHE 需要特别小心。

总结。

对于 以太坊集成，携带证明的 FHE 仍然是理想的长期设计：它反映了 rollup 的验证逻辑并确保 无需信任的正确性。

  • Zama 基于 SNARK 的原型显示了可行性，但尚未实用。
  • HasteBoots 指向了一条更有效的路径，特别是对于 TFHE 样式的方案。
  • TEE 和重新执行可以作为临时或补充机制，但最终 简洁的密码学可验证性 是在分散环境中扩展的首选解决方案。

3) 安全密钥管理

安全密钥管理是区块链中 FHE 采用的关键支柱。在区块链环境中，安全密钥管理必须超越传统方法——它需要具有弹性、去中心化并与对抗环境兼容的机制。阈值密码学 (Asharov et al., EUROCRYPT 2012)、多方计算和代理重加密 (Yasuda et al., ISC 2018) 提供了有希望的方法来确保没有单个实体单方面控制解密，同时仍然能够实现高效可靠的操作。

同样重要的是 用户主权 原则。参与者应该能够保留对其密钥的有意义的控制权，而不会被迫进入破坏去中心化的托管模型。在这种情况下，安全密钥管理不仅关系到保护私有数据，还关系到与区块链的精神保持一致：分配信任、确保可用性并使系统能够抵抗技术故障和治理捕获。

密钥生成和加密

管理密钥从设置开始。在 阈值 FHE 方案中，所有参与者共同运行 分布式密钥生成 (DKG) 协议以生成 公共 公钥和 公共 私钥的份额（Asharov et al., 2012）。这意味着该组实际上有一个共享的 FHE 密钥对（公钥、私钥）——每个参与者都持有私钥份额，并且公钥对于每个人都是相同的。每个参与者的数据都使用此联合公钥加密。

相比之下，在 多密钥 FHE (MK-FHE) 方案中，不需要前期联合密钥生成。每个用户独立创建自己的密钥对，并且可以使用自己的公钥加密数据。然后可以对使用不同用户密钥加密的 ciphertext 执行同态运算（因此称为“多密钥”）。这里最大的好处是，各方不需要 协调或同时在线以设置公共密钥。任何一方都可以随时使用自己的密钥进行加密，这在分布式设置中很方便（例如，用户在不同时间加入或异步上传数据）。这消除了阈值 FHE 所需的复杂 DKG 步骤，并简化了初始密钥管理（Chen, Chillotti, Song, ASIACRYPT 2019）。

阈值 FHE 中的安全风险和保护

在阈值 FHE 方案中出现了两个微妙的挑战，它们同时与 密钥管理 和 设计上可验证 的更广泛目标相关：

1. 来自解密份额的泄露
  • 在阈值 FHE 中，每个参与者都发布一个解密份额。在多次解密后，这些份额可能会泄露有关密钥的信息。
  • 两种常见的缓解措施：
    • 噪声泛洪（污损）： 每个参与者在发布其份额之前，都会向其份额添加大量随机噪声，从而隐藏与密钥的关联。这需要扩大 FHE 参数以容忍额外的噪声。
    • MPC 舍入： 各方共同执行安全多方计算 (MPC)，以直接在其私密 shares 上完成解密的舍入步骤，以便仅公开 plaintext。这避免了参数膨胀，但引入了更多的 MPC 开销。
2. 可验证的密钥生成
  • 尽管 MPC 确保了密钥生成参与者之间的公平性和正确性，但它无法向外部验证者提供任何保证。

  • 为了使 分布式密钥设置本身可验证，可以使用：

    • 公开可验证的秘密共享 (PVSS)： 每个参与者的份额都附带一个证明，证明它与承诺的秘密一致，因此任何人都可以在 VERIFY DKG。
    • 协作 SNARK (cosnarks)： 参与者共同生成一个简洁的证明，证明 DKG 协议已正确执行，从而提供诚实密钥生成的可公开验证的保证。
解密机制

另一方面是在涉及多个密钥持有者时如何处理解密：

  • 阈值 FHE 解密： 由于有一个公共秘密（拆分为份额），因此各方可以 协作 解密。可以将经典的阈值方案配置为 n-out-of-n（需要所有份额）或更灵活的 t-out-of-n，其中至少 t 方的任何子集都可以解密。这种灵活性是阈值 FHE 的一个优势——它可以容忍某些方在解密期间处于离线状态（只要阈值数 t 合作）。

但是，其安全性取决于 阈值信任假设——通常是大多数方保持诚实。如果勾结的人太多，他们可以过早地解密 ciphertext 并破坏机密性。这种勾结风险是根本性的：任何一组 t 个或更多个合作方都可以在标准阈值方案中恢复密钥。

最近的工作提出了问责制增强措施来阻止或检测勾结。例如，Dziembowski 等人 的 Secret Sharing with Snitching (SSS) 确保任何非法重建都会产生可公开验证的证明。同样，Chiang et al. (2021) 引入了阈值加密的 自证其罪的证明，保证在完成解密时，至少有一名参与者会学习到解密行为的证明。此类证明充当审计跟踪，阻止恶意行为。同样，可追溯的阈值加密 (Boneh et al., 2021) 赋予跟踪密钥以查明哪些方参与了解密。

阈值 FHE 的另一个众所周知的限制是 固定委员会的刚性。传统方案依赖于成本高昂且通信量大的 分布式密钥生成 (DKG) 仪式。一旦完成，参与方的委员会基本上是固定的：添加或删除成员需要运行另一个 DKG，这在验证者集轮换或参与者流失的动态区块链设置中是不切实际的。Hall-Andersen et al., 的 静默设置（ePrint 2023/318）解决了这个问题，允许每个参与者独立生成密钥并发布一个小的“提示”。然后，任何提示子集都可以组合起来以形成公钥，而无需全局协调。这使得委员会更容易重新配置，支持异步注册，并将设置复杂性从二次降低到本质上是线性通信。

简而言之，虽然经典的阈值 FHE 提供了灵活的 t-out-of-n 解密，但它继承了信任和刚性问题：勾结会破坏机密性，而固定的委员会会使重新配置成本高昂。新的原语——问责机制（SSS、自证其罪的证明、可追溯的加密）和灵活的设置（如静默 DKG）——显着缓解了这些问题。有关在加密内存池上下文中进行的明确应用讨论，请参阅 Shutter Network 博客文章。

  • 多密钥 FHE 解密： 与阈值 FHE 相比，主要优势在于加密是使用不同的密钥执行的（无需在加密之前生成公共联合密钥）。对多密钥加密数据进行同态计算的结果是与 多个密钥 绑定的 ciphertext。

在标准 MK-FHE 方案中，所有参与用户都必须合作才能解密——本质上默认是 n-out-of-n 要求。每个用户都使用自己的密钥生成部分解密，然后将这些部分结果合并以恢复 plaintext。一个已知的缺点是这种合并过程 需要交互并且所有密钥持有者同时在线。如果甚至一方不可用或不合作，则解密将无法进行。此外，组合解密份额的通信和计算成本随着参与者数量的增加而增加。

简而言之，开箱即用的多密钥 FHE 缺乏阈值方案的 t-out-of-n 解密的内置灵活性——它本质上要求每个人都参与最终解密。

混合方法和代理重加密

最近的研究试图通过将多密钥加密与阈值解密技术相结合来获得 两全其美。在这种情况下，一种有前途的工具是 代理重加密 (PRE)，它使在许多独立密钥（多密钥 FHE）下加密的 ciphertext 能够转换为可在阈值委员会密钥下解密的 ciphertext，而无需暴露 plaintext。

乍一看，有人可能会问：如果目标委员会是提前知道的，为什么不直接使用阈值 FHE？ 答案是 PRE 在 两种互补的方式 中提供了优势：

1. 简化的密钥设置（即使对于固定委员会）
  • 阈值 FHE 需要 分布式密钥生成 (DKG) 来生成公共密钥并将其私钥拆分为份额。DKG 具有交互性、脆弱性，并且需要所有方同时在线。
  • 多密钥 FHE + PRE 消除了此障碍：每个用户都可以 独立生成自己的密钥对 并立即加密，而无需协调。PRE 稍后将多密钥 ciphertext 合并为一个固定委员会密钥下的 ciphertext。

这意味着即使委员会从未改变：

  • 用户可以随时异步注册。
  • 无需全局设置仪式。
  • 重加密负担被放在委员会基础设施上，而不是用户身上。
2. 动态或灵活的委员会

在许多区块链环境中，解密权限不是静态的：验证者集轮换，DAO 每周期分配委员会，或者审计师随着时间的推移而更改。PRE 允许在使用独立用户密钥加密的 ciphertext 在解密时 重新定向 到任何活跃的委员会。这支持：

  • 动态验证者或委员会轮换。
  • 可委托的解密权限（例如，审计师、验证者）。
  • 每个查询分配解密器。
示例

  • _单代理 MK-PRE (Yasuda et al., 2018)_: 将多密钥 ciphertext 转换为可由一个 delegatee 解密的形式。降低了用户协调成本，但引入了对代理和 delegatee 的信任。

  • 阈值代理重加密 (Nakashima et al., SAC 2024): 在多个代理之间拆分重加密功能。没有单个代理学习完整的重密钥，并且只有阈值的代理一起才能重加密到委员会密钥。

    • *
超越代理重加密

还存在其他 混合多方 FHE 方法。一些方法结合了多密钥和阈值方案的各个方面以提高效率。例如，Chen、Chillotti 和 Song (2019) 将 TFHE 方案扩展到多密钥设置，使多个方可以评估在使用其个人 TFHE 密钥加密的数据。后来的工作探索了：

  • 用于批处理的 打包 ciphertext，减少了每个用户的开销。
  • 用于多密钥 运算的 改进的渐近效率。
  • 分层混合，其中一方可以持有某个密钥的阈值份额，同时也可以在另一层中拥有自己的密钥。

这些混合方法旨在保留多密钥系统的 加密自主性（无需全局设置），同时通过阈值技术或密钥切换来缓解 解密协调问题。

总之：

  • 当委员会是固定的并且可以接受 DKG 时，阈值 FHE 是最好的。
  • 多密钥 FHE + PRE 简化了设置（没有 DKG，异步注册），并且在委员会轮换时增加了灵活性。
  • 更广泛地说，混合方案 探索了中间地带，展示了 FHE 中安全且实用的密钥管理的丰富设计空间。
实践考虑和工具

在实践中，现代 FHE 库正在整合这些进展，以使多方密钥管理更加用户友好。例如，OpenFHE 支持阈值 FHE 模型 和 其主要方案（BFV、BGV、CKKS）的代理重加密操作。这意味着开发人员可以使用阈值密钥共享，以便计算的解密需要多个利益相关者，并且可以根据需要在 旋转密钥或委托解密 时使用 PRE。典型的 workflow 可能涉及各方在使用他们自己的密钥加密数据（用于灵活性的多密钥加密）、执行 FHE 计算，然后在最终解密之前使用 PRE 步骤将结果转换为公共密钥。在区块链环境中，这种设计非常强大：它允许参与者独立提交加密的输入，稍后网络（或一组充当代理的节点）可以将加密的结果 重加密 到特定节点子集（或智能合约）可以解密的新密钥。因此，代理重加密充当了不同密钥域之间的桥梁，从而实现了 动态密钥管理——例如，自动将解密权限转移给指定的“结果验证者”或为连续的计算轮次旋转密钥。

总之，多密钥 FHE 提供了更简单的加密密钥管理（无需联合密钥设置），并且适用于各方在不同时间贡献数据的场景，而 阈值 FHE 提供了灵活的解密策略（例如，通过 t-of-n 解密容忍缺少参与者）。通过诸如阈值代理重加密之类的混合方法，这两种范例越来越多地被组合在一起，以利用彼此的优势。正在进行的研究和工具改进（例如，在 OpenFHE 中）继续改进 FHE 的密钥管理，使其更具可扩展性和实用性，适用于现实世界中的多方应用程序。

4) IND-CPAD 安全和 FHE

为什么 IND-CPAD 重要

所有现代 FHE 方案在格假设下都是 IND-CPA 安全的，但 IND-CPA 会忽略辅助信息，例如：

  • 罕见的 解密错误（噪声溢出），或
  • 小的 近似差异（CKKS）。

在实践中，与 FHE ciphertext 交互的攻击者可以利用这些微妙的影响。Li 和 Micciancio 引入了 IND-CPAD 以捕获这一点。在此模型中，攻击者会获得：

  • 加密和评估预言机，以及
  • 一个 严格限制的解密预言机，该预言机仅输出 plaintext 已知的 ciphertext 的 plaintext（例如，攻击者创建或派生的 ciphertext）。

这不是完整的 CCA 安全性：攻击者无法解密任意挑战 ciphertext。但它确实反映了 FHE 系统的 真实接口，并捕获了 IND-CPA 忽略的侧信道。请注意，已经充分证明，全同态加密不能满足完全自适应 CCA 安全性 (IND-CCA2)。在传统的公钥加密方案中，解密是一种“单向”算法，它只是恢复底层 plaintext。相比之下，在 FHE 方案中，解密算法与评估机制纠缠在一起：ciphertext 可以通过应用同态操作转换为相关 plaintext 的加密。如果攻击者可以访问解密预言机，他们可以将这种同态可塑性与解密查询相结合来发起攻击。

已知攻击
  • 近似方案 (CKKS)： Li-Micciancio 表明，近似噪声会泄露密钥上的线性关系，从而实现被动密钥恢复。
  • 精确方案 (BFV、BGV、TFHE)： Cheon et al. 证明了实际实现允许非可忽略的解密失败（例如，~2^-40）。通过制作接近失败边界的 ciphertext，攻击者可以检测异常甚至恢复密钥。

因此，如果正确性不是本质上完美的，则近似方案和精确方案都可能无法满足 IND-CPAD。

对以太坊的影响

以太坊用例放大了这些担忧，因为攻击者可以直接与由 FHE 驱动的合约交互：

  • 加密余额： 攻击者发送精心设计的 转移，将受害者的 ciphertext 推送到接近失败的边界。通过观察异常行为（回滚、不一致），他们可以推断出隐藏的余额。

  • 私有拍卖或投票： 恶意出价可能导致计票 ciphertext 在解密期间失败，从而泄露竞争对手的出价或投票。

  • 机密合约： 对抗性输入可能会触发贷款审批或信用评分逻辑中的解密异常，从而泄露敏感状态。

  • 阈值 FHE： 即使在验证者之间分配密钥也无济于事，因为每个参与者都可以诚实地解密对抗性 ciphertext——仍然会在 IND-CPAD 攻击下泄露信息（Cheon et al.）。

    • *
结论

IND-CPAD 是以太坊上 FHE 的实际安全概念。 虽然所有现代方案都满足 IND-CPA，但它错过了可解密变异性的微妙但可利用的影响。如果没有 IND-CPAD 级别的安全性（或缓解措施），加密 Token、拍卖和私有合约可能会有泄露风险，甚至会危及密钥。

结论

全同态加密有望为以太坊提供一个 原生保密层，从而在不损害网络开放性和可验证性的前提下实现私有计算。生态系统已经规划了关键方向——从方案选择和可验证性到去中心化密钥管理——但将这些转化为实践需要的不仅仅是密码学。

真正的考验在于效率和经济性：自举必须变得更快，其可验证性必须实用，开发者工具必须更符合人体工程学，并且商业模式必须足够可持续，以至于用户认为保密是值得的。基准和开放标准对于指导这一进展至关重要。

与此同时，FHE 与区块链的集成指向了更广阔的前景，尤其是在人工智能领域。我们可以想象共享、可验证和保护隐私的基础设施，而不是封闭的服务，并以塑造以太坊的相同的最小信任精神进行管理。

  • 原文链接： ethresear.ch/t/open-appl...
  • 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～
点赞 0
收藏 0
分享
本文参与登链社区写作激励计划 ，好文好收益，欢迎正在阅读的你也加入。

0 条评论

请先 登录 后评论
以太坊中文
以太坊中文
以太坊中文， 用中文传播以太坊的最新进展

以太坊中文

如果觉得我的文章对您有用，请随意打赏。你的支持将鼓励我继续创作！