加密合约落地，先把证据和披露规则讲清楚

Fhenix在2026年10月20日发布的技术文章讨论了合约使用加密数值计算时的安全问题。它值得关注的地方，是把应用设计带回了一个常常由密码学主导的话题。Fhenix技术文章

对于考虑采用链上保密应用的企业，首先要决定哪些信息不应被其他参与者获知，随后还要决定这些参与者必须能够核验什么。两种要求可能产生张力：采购流程需要隐藏竞争者的报价，同时又要证明最后遵循了事先公布的选择规则。把报价隐藏起来，并没有回答规则由谁制定、谁能修改，以及发生争议后谁可以查看结果。

本文提出的是分析框架，不是对某项部署的安全评估。架构文件可以说明设计主张，不能证明实现中不存在缺陷；研究某类系统的论文，也不能直接成为某个具体产品存在漏洞的证据。

报价保密之后，交易规则仍需明确

假设一家采购方采用加密招标。供应商提交竞争对手无法读取的价格，采购方则希望选出满足交付和质量要求的最低报价。保密有明确的商业理由：供应商不应为了竞争一笔订单，就必须公开整套定价策略。

但数值最低，并不一定代表业务上应该中选。供应商可能使用了错误的币种，没有计入运费，或者承诺了不符合要求的交付日期。即使加密算术完全正确，也可能比较了本来就不应放在一起比较的输入。因此，应用在开始计算之前，就需要定义什么是合格报价。加密技术无法替采购方判断交付承诺是否可信，也无法判断招标规格是否真正符合采购需求。

输出端同样存在选择。采购方可能只需要知道中选供应商和最终应付金额。向所有参与者公开完整排名，可能披露超出交易需要的商业信息；反过来，披露过少又可能让落选供应商无法质疑前后不一致的决定。合适的披露政策应来自交易目的及其争议处理安排，而不是由某一种密码学技术自动决定。

计算有效与决定合理，需要不同证据

2023年1月17日提交的《Verifiable Fully Homomorphic Encryption》论文将计算完整性视为独立问题，并研究应对恶意执行的保护方法。这是历史技术研究，不是对当前CoFHE实现的漏洞认定。研究论文

对于上述假想招标，这提示我们区分两类保证。技术核验关注的是：指定的操作是否确实作用于指定的输入。业务审查关注的是：这些输入和操作是否代表各方约定的采购规则。前者的证明不能悄悄替代后者。如果一项加密比较准确执行了已经过时的准入条件，它仍可能选出业务上无法接受的供应商。

这种区分还会改变证据的组织方式。一份有用的审查记录，应当把规则版本、被接受的输入集合、正在核验的计算，以及最后披露的结果联系起来。脱离这些背景的密码学校验，即使在数学上有意义，也可能不足以解释采购决定。这是本文对证据设计的分析判断，并不意味着某个协议会自动提供全部相关记录。

采购团队尤其需要在系统上线前约定谁负责解释这些记录。技术人员能够确认程序执行情况，却未必有权解释商业例外；业务负责人能够说明采购目的，也未必知道一个证明覆盖了哪些条件。把两种责任都交给一个笼统的“系统已验证”标签，会使争议发生后的沟通更加困难。

权限设计本身就是产品的一部分

Zama当前的ACL文档区分长期有效的密文权限和仅在当前交易内有效的权限，并单独说明让数值能够被公开解密的授权。这些对应不同的应用选择。Zama ACL文档

采购团队可以借助这种区分，把自身要求写清楚，而不必假定各个平台的控制机制完全相同。计算服务可能只需要一次任务的临时权限；审计人员可能需要在特定委托范围内查看特定信息；客服人员可能只需掌握解决某张工单所需的内容。如果三个角色都获得同样宽泛的权限，管理也许更方便，却会削弱最初采用保密应用的理由。

权限的范围还需要经得起普通的组织变化：供应商更换账户、审计合同结束，或者采购方替换外包运营商。设计问题不只是“能不能授权”，还包括团队能否识别受影响的数据，并理解权限变化能做到什么、做不到什么。停止未来访问，无法让接收者忘记已经获得的明文。因此，即使底层计算保持加密，导出的报表和截屏仍然属于日常隐私管理的范围。

这也意味着，权限评审不能只发生在首次接入。一个原本只负责展示结果的服务，后来可能增加分析或导出功能。功能变化未必构成技术故障，却可能改变实际接触数据的人和系统。企业需要能够识别这种业务范围变化，再决定是否调整授权，而不能仅凭旧版本曾经通过审查就持续放行。

评估当前系统，而不是把路线图提前兑现

CoFHE当前的Teecryptor文档说明，解密在经过证明的可信执行环境内进行，多方阈值解密则被列为计划中的替代方案。现有设计和未来路线图不应混为一谈。CoFHE Teecryptor文档

这一限定并不是反对部署存在硬件假设的系统。只要收益值得，企业经常会接受技术依赖。它要求的是比较真实的依赖条件，而不是比较营销分类。采购方应理解哪些组件必须保持可用、有哪些证据支持其运行，以及必要的服务无法产出结果时将发生什么。

对招标而言，即使没有报价泄露，也没有算术错误，结果暂时无法取得仍可能推迟定标。事先约定延期或取消程序，可能比临时扩大披露范围更有价值。但这类程序也有商业成本，例如供应商可能需要更久地预留产能。因此，保密性、可用性和合同时间安排需要一起考虑，而不是由不同团队分别评估后，再也不核对彼此的假设。

加密计算最有说服力的用途，是让参与者无需分发全部底层数据，也能完成合作。在信息披露本身会造成竞争成本的场景中，这种价值是真实而具体的。当应用能够说明哪些事实保持隐藏、哪些结论可以被检验，以及哪些人仍对变更和例外拥有决定权时，这种价值也更容易被评估。

因此，初期部署应接受一次完整交易和一次现实争议的检验，而不只是展示加密计算能够运行。如果采购方能够在不暴露无关报价的情况下解释有争议的结果，并在流程停滞时仍遵守原来的披露限制，技术就服务于一个可以辨认的业务需求。某项具体实现能否做到这些，仍需证据和测试，不能从FHE这个名称直接推导出来。