。

即#xff0c;任何第三方或云厂商#xff0c;都可对敏感信息的密文进行处理#xff0c;而无需访问密文内…1.

何为FHE

是一种隐私技术支持直接对密文进行计算而无需对密文先解密再计算。

即任何第三方或云厂商都可对敏感信息的密文进行处理而无需访问密文内的任何明文数据。

1.1

中构建了首个支持通用电路的方案——通过加法和乘法来实例化FHE。

FHE用例

隐私加强如用于机器学习、云计算、FHEZKPMPC实现链上gambling、加密搜索和数据库操作。

链上私有交易、私有智能合约、专注隐私的VM如FHEVM等。

2.1

上传合约S和交易T计算S(T)在不公开S和或T的情况下来做资产转移、swap等。

如某些云厂商提供合约隐私某些云厂商提供数据隐私而有的云厂商同时提供合约隐私和数据隐私。

dev

需要将program转换为“FHE-friendly”表示如只包含加法和乘法门的电路。

相比于直接计算这引入了大量的开销。

对每个电路执行密码学运算将单个操作符替换为一系列基于大数的复杂运算。

这仍会增加开销。

2023年9月Intel声称正在开发对FHE运算高效的定制芯片

Intel

电路设计的挑战在于需要非常准确的域和运算来最大限度地利用固定电路拓扑。

正在算法和优化方面进行扎实但渐进的改进。

从必须将程序转换为某种形式的THE友好表示这将增加开销到必须对更大的数字进行计算这一切都不会改变。

2.1.2

不能像编写公共数据[和程序]那样编写私有数据。

也就是说加密交易不能像明文值那样在智能合约中使用——接收加密交易的程序不能调用另一个程序也不能向仅通过明文值操作的程序发送存款。

这使得在一个生态之上构建另一生态更具挑战性。

2.1.3

似乎很少有人讨论这一点但在加密的领域中不可能有相同的监控/调试工具。

如

假设客户打电话说“我的交易没有通过”。

要调试此语句需要知道问题是否与数据编码、加密、程序评估或管道中的其他任何地方有关。

如果没有对数据本身的可见性客户一开始就试图隐藏数据这是非常具有挑战性的。

2.1.4

已经看到了保护隐私的token和网络的问题。

可能会因为编写该软件而遇到麻烦。

监管机构将如何接收和分类完全加密的环境还有待观察。

1为加强计算安全性在加密期间会给密文添加一些“noise噪声”。

2当密文中累积了过多“噪声”时会因过噪而影响输出的精度。

3Bootstrapping自举

是一种常用去噪技术但其是计算密集型的。

4不同的解决方案正在探索在不给设计施加太多约束的情况下有效去噪的方法包括TFHE、CKKS、BGV等。

FHE领域项目

将ZK推向今天的水平总共花费了大约10亿美元——这是一个很大的兴奋和潜力但还有更多的生产用例有待观察。

Sergey预计FHE将需要大约相同的资金才能达到目前的水平[需要大约9亿VC]。

这是因为软件栈的类似部分需要重写而且可以说需要重写更多。

Sergey认为工程师应该关注更多的垂直用例并考虑端到端的开发人员体验。

当然考虑通用VM环境是有利可图的但其应针对特定的工作负载进行优化。

谁将为保护隐私的固有管理费用支付美元工程、维护和执行成本还有待观察。

FHE领域需要更多的资金、更多的工程师、实用的用例和简单的开发环境。

参考资料

Zero中验证FHE——由隐藏到证明FHE验证的ZK路径1基于[Discretized]

Torus的全同态加密指引2TFHE——基于[Discretized]

代码解析技术探秘在RISC