FHE简介:什么是FHE,FHE如何工作,它如何与ZK和MPC连接,FHE在区块链内外的用例有哪些等。

fen yun
2023-11-24 05:21
发布于 Mirror

特别感谢Leo Fan的宝贵意见和Tomer Solberg的反馈和审查。

长话短说

在本文中,我们简要解释什么是 FHE 及其工作原理,考虑其在区块链内外的用例,并涵盖未解决的问题和限制。最后,我们还提到了一些区块链 FHE 项目,并提供了一个列表以供进一步阅读。

内容

  • 介绍

  • FHE 的工作原理

  • FHE 用例

  • FHE 的担忧

  • FHE 技术细节

    • 关于格子的旁注

    • 简要(不是真正简短)观察 TFHE 的工作原理

  • 当前区块链中的 FHE 项目

  • 区块链之外的 FHE

  • 进一步阅读

  • 免责声明:本文有时会引用 Secret Network(基于 FHE 的可定制隐私的区块链)和 Zama(基于 FHE 的加密工具)作为说明。有关研究和开发 FHE 的项目的更详细列表,请查看“区块链中当前的 FHE 项目”部分。

介绍

  • FHE 代表完全同态加密。

  • FHE 于 20 世纪 70 年代首次提出。然而,直到2009年,在实现全同态加密方面还没有太大进展。最好的结构提供了任意数量的加法,但只有一次乘法(而所需的结果是任意数量的加法和乘法)。

  • Craig Gentry在2009 年实现了开创性的飞跃,展示了第一个支持任意数量的加法和乘法的 FHE 结构。

  • FHE 支持加密数据处理。

图表来源:研讨会“Morten Dahl - EVM 中的同态加密”。

  • 也就是说,它对加密数据进行计算。

  • “完全”代表加法和乘法:

    加性同态:乙(米1)+乙(米2)=乙(米1+米2)

    乘法同态:乙(米1)*乙(米2)=乙(米1*米2)

  • 从数学角度来看,FHE 是一个已解决的问题。从工程角度来看,这是一项正在进行的工作,其核心瓶颈是性能。

  • FHE 不被认为是一个自给自足的解决方案(至少目前如此),而是提供隐私的组件之一,预计可与 ZKP、MPC 和 TEE 配合使用。

    例如,虽然FHE在计算过程中保护了数据隐私,但它并不能保证计算的真实性。为了缓解这个问题,FHE 可以与 ZKP 结合起来,以实现机密性和计算真实性。另一个例子是结合FHE和MPC来处理效率问题。然后,HE用于对加密数据进行线性计算,MPC处理非线性计算。

图表来源:研讨会“Morten Dahl - EVM 中的同态加密”。

FHE 的工作原理

  • 密文=加密数据+噪声。即在加密数据中添加随机噪声来保证安全性。

图来源:文章《使用同态加密的私人智能合约》

  • 然而,现在所有的计算不仅是对数据进行的,而且是对加上噪声的数据进行的。

  • 此外,经过多次操作后,噪声开始增大并溢出到实际数据位上,这可能会导致错误的结果。具体的增长速度取决于使用哪种编码。例如,可以在最低有效位 (LSB) 中添加噪声,同时在最高有效位 (MSB) 中添加消息,或者相反。它还可以包括填充(添加零位):

图来源:zama 的文章“TFHE Deep Dive - Part II - Encodings and Linear Leveled Operations”。

或者将消息和错误编码为单个事物:

图来源:zama 的文章“TFHE Deep Dive - Part II - Encodings and Linear Leveled Operations”。

  • 为了应对噪声的增长,只需​​为噪声的增长提供足够的空间即可。然后,它在速度方面变得相当高效,但可用计算的数量无论如何都是有限的(无论噪声空间有多大)。对于智能合约来说,它不起作用,因为有时它们可​​以无限更新(例如,ERC-20)。

  • 另一个问题是,通过添加噪声空间,只能进行加法和乘法,而比较和非线性函数则使用多项式近似来近似。对于机器学习案例来说它工作得很好,但对于智能合约来说,情况可能并非如此(例如,用户没有足够的资金,但交易通过了 - 不酷)。

  • 为了减少噪音,还可以使用自举(bootstrapping)。自举是一种特殊操作,可将噪声重置为其标称水平。它可以永远进行计算,但它是一种缓慢且昂贵的操作(无论是在内存消耗还是计算成本方面)。这就是为什么当我们谈论 FHE 研究时,我们实际上谈论的是自举加速。“FHE 技术细节”部分将介绍引导程序的工作原理。

  • 另一个解决方案是 TFHE——一种能够实现无限计算、精确任意数量(而不是近似)和非常快速引导的方案。使用 TFHE,引导操作可评估同态查找表。任何函数都可以编码为查找表。因此,TFHE 消除了近似和运算次数的限制。

表来源:研讨会“使用同态加密的私人智能合约 - Rand Hindi,ETHcc 5”

  • 另一个值得一提的FHE方案是CKKS(近似数算术同态加密)。其性能预计与 TFHE 接近,但优点有所不同。借助 CKKS,人们可以在引导程序之间执行更多操作,同时操作多个数据(在 SIMD 中,单指令/多数据),并处理整数和浮点数的更大位表示。CKKS 支持加密消息的近似加法和乘法以及用于管理明文大小的替代重新缩放过程。此过程将密文截断为较小的模数,从而导致明文舍入。主要思想是在包含主要信息的重要数字后面添加噪音。为了安全起见,这种噪声最初被添加到明文中,但被认为是近似计算期间发生的错误的一部分,通过重新缩放与明文一起减少。结果,解密结构输出具有预定精度的明文的近似值。评估过程中的精度损失受到电路深度的限制,与浮点运算等未加密的近似算术相比,最​​多多多一位。由于重新缩放过程,密文模数的位大小随着所评估的电路的深度线性增长。CKKS 还可用于有效评估超越函数,例如乘法逆函数、指数函数、逻辑函数和离散傅里叶变换。

  • Ingonyama 提供的当前 FHE 性能的另一个示例可以在本文中找到。它回答了“使用 FHE 运行 LLM 推理需要多长时间?”的问题。

FHE 用例

一般示例

  • 私有链上计算:

    • 加密交易数据:交易中包含的数据是加密的。

    • 加密状态更新:状态在保持加密状态的同时进行更新。

    • 加密的链上数据:存储在链上的数据保持加密状态。

    • 私有智能合约:私有计算+私有数据

      • 智能合约中不是整数,而是加密的整数。不应对常规智能合约编写逻辑进行其他更改。

      • 最棘手的部分是智能合约如何检查加密的余额。

  • EVM 中的 FHE(以 Zama 的 fhEVM 为例)

    • fhEVM不是区块链,而是其他区块链可以使用的加密组件。它还包括针对 FHE 优化的阈值协议、一个用于表达在加密数据上运行的智能合约的 Solidity 库以及用于构建 dapp 来正确加密数据并与加密区块链交互的 dapp SDK。

    • fhEVM 背后的机制

      • 所有内容均通过单一全球 FHE 公钥进行加密。

      • 全局密钥是使用阈值协议生成的(部分密钥分布在验证器之间)。

      • 输入使用 FHE 公钥加密。

      • 对加密数据的计算由验证器在本地完成。

      • 验证器可以使用阈值协议对值进行解密。

      • 值还可以使用阈值协议在另一个公钥(我们将其表示为*“公钥 a” )下重新加密(无需解密)。重新加密的值可以由公钥*所有者解密。

  • 具体例子

    • 链上盲

      • 两个阶段:投标阶段和索赔阶段。投标阶段包括用户投标加密数量的代币(使用加密的 ERC20 合约)。当拍卖结束时,合约同态确定最高出价者。

      • 最终,合约只公开中标者,而中标价格和未中标价格则保密。

    • 一个市场,买卖订单在成交之前对公众不可见。

    • 机密 ERC-20代币

    • 加密的键值数据库

    • 无信任桥:使用加密密钥对桥交易进行同态签名。

    • 保密投票:加密的选择和代币数量。

https://twitter.com/socrates1024/status/1629224192527974400?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1629229659400404993%7Ctwgr%5Ec6e9ed65707a61b67f7c480f6e91909c02092979%7Ctwcon%5Es2_&ref_url=https%3A%2F%2Ftaiko.mirror.xyz%2F2O9rJeB-1PalQeYQlZkn4vgRNr_PgzaO8TWUOM5wf3M

View on OpenSea

FHE 的担忧

  • **就 FHE 区块链而言,整个网络只有一把钥匙。谁持有解密密钥?**这个“谁”将定义安全级别。按照Secret Network的建议,密钥片被分发到每个预言机节点——即使用阈值MPC。关于MPC安全性存在很多问题,对于依赖MPC安全性的FHE安全性也存在很多质疑。

  • 改进安全假设的一种方法是在 TEE 内部分运行秘密解密。然而,如果出于安全考虑,TEE 是可选的,那么使用它还有另一个原因:擦除问题。当 Oracle 节点轮换时,应保证前一个节点已删除其拥有的密钥份额。

View on OpenSea

  • 然而,与普通 MPC 相比,FHE 更好,因为它将大量计算外包给完全不可信的节点,然后只有半可信的仲裁用于阈值解密,这与 MPC 不同,在 MPC 中,该仲裁完成所有工作。

    怎么运行的:

    1. 密钥的各个部分是在验证者之间生成和共享的。

    2. 每个验证器都会进行部分解密。

    3. 部分解密被聚合以产生完整的解密值。

    它的安全性在 2/3 诚实验证者的假设下成立。然而,验证器集应该是固定的和有限的。

  • 在秘密网络的具体情况下,网络验证者需要在共识时间内做出断言。他们应该如何访问解密的数据?它不能使用“vanilla oracle”来完成,因为它会破坏隐私。解决方案是两轮共识机制。第一轮是关于应该解密什么的共识。也就是说,Oracle 会等待,直到大多数验证器向其发送相同的解密请求。然后,Oracle 对其进行解密。然后,验证器更新链状态并将块附加到区块链。

  • 如何防止用户解密其他用户的数据?如果用户只是编写一个合约来解密输入并提供其他人的加密数据作为该合约的输入怎么办?解决方案是零知识证明!用户应该提供他们发送到网络的每个加密输入的 ZKP,以证明用户确实知道他们以加密方式发送的值。

  • **FHE 的关键技术问题是其速度缓慢。**它的性能比已知的替代品慢得多。

https://twitter.com/randhindi/status/1628824430808911872?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1628824430808911872%7Ctwgr%5Ec6e9ed65707a61b67f7c480f6e91909c02092979%7Ctwcon%5Es1_&ref_url=https%3A%2F%2Ftaiko.mirror.xyz%2F2O9rJeB-1PalQeYQlZkn4vgRNr_PgzaO8TWUOM5wf3M

  • 慢了多少?

https://twitter.com/0x_widehat/status/1628825039561801731?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1628831057616289795%7Ctwgr%5Ec6e9ed65707a61b67f7c480f6e91909c02092979%7Ctwcon%5Es2_&ref_url=https%3A%2F%2Ftaiko.mirror.xyz%2F2O9rJeB-1PalQeYQlZkn4vgRNr_PgzaO8TWUOM5wf3M

View on OpenSea

  • FHE 性能取决于硬件加速,并且在 ASIC 出现之前预计不会便宜。

  • Leo Fan 表示,FHE 开销大约是未加密计算的 10,000 倍。使用 GPU 和 FPGA 的性能比 CPU 高 2 个数量级。为 FHE 设计 ASIC 可以实现 3-4 个数量级的性能提升(相对于 CPU),几乎缩小了 10,000 倍的差距。“如果应用程序需要无交互的解决方案,那么 ASIC 似乎是最佳选择。由于HE对于一些简单计算(例如线性计算)的性能和密文爆炸令人满意,因此GPU/FPGA加速的HE结合MPC技术可以在一些网络连接良好的应用中使用。”

  • 如果能够生成正确 FHE 执行的证明以避免执行冗余,我们就可以拥有可证明的 FHE(类似于 ZK)和 zk-FHE-rollups。

FHE 技术细节

安全

  • 为了考虑 FHE 安全性,假设我们有四个参与方:加密者、解密者、进行 FHE 计算的人以及对手。有可能加密者和解密者是同一个人,那么我们就处理对称FHE。可能存在多个加密器的情况。FHE 的安全假设假设所有这些方都可能不诚实。

密码学

  • FHE 是一种基于格子的结构。最初提出的 FHE 基于理想晶格,但从那时起,该晶格已被证明是不安全的。

关于什么是格子的旁注

  • 晶格是 n 维空间中点的周期性网格。可以有无限多的基础。基的长度是其最长向量的长度。我们将最长向量长度最小化的基称为“短基”。

  • 短向量格问题听起来如下:给定任意基 b,找到一个尽可能短的非零格向量。

  • 该问题的另一个版本称为解码问题。在此版本中,要求在定义的区域内找到一个目标点(不是最短的,但不长于某个特定值)。

图源:CryptoBook

这两个问题之间的核心区别在于,短向量问题需要唯一的向量。在解码问题下,我们保证在某个固定的足够大的半径内总是存在多个点。

  • 如果您在二维空间中考虑这个问题,那就很简单:晶格只是平面上无限的点集。这些点是通过两个“基向量”的整数线性组合生成的。困难的数学问题是找到生成晶格的两个短向量。在下图中,黑色向量是“基本向量”,红色向量是“困难数学问题”的解决方案:

图来源:文章《全同态加密与后量子密码学》

  • 在二维中,这个问题似乎非常简单。然而,当我们将维数扩大到更高时,这确实变得非常困难。特别是,随着维数的增加,复杂性呈指数级增长。当维度足够多时,它变得非常困难,以至于我们不相信即使是量子计算机也能够解决这个难题。

  • 该问题的重要参数是密码学基础的确切维度和初始基本向量的选择。

  • 晶格被认为是后量子原语背后的核心机制。

  • 许多改进的 FHE 方法(例如 FHEW、TFHE、BGV、BFV 和 CKKS)都基于误差学习 (LWE),从其术语来说,LWE 是基于格问题的。

简要(不是真正简短)观察 TFHE 的工作原理

  • TFHE 中的 T 代表 Torus,一种类似甜甜圈的数学结构。

  • 该方案的安全性基于称为 LWE(错误学习)的硬格问题。

  • TFHE 与其他方法的不同之处在于它提出了一种特殊的自举法,该自举法速度非常快,并且能够在降低噪声的同时评估函数。

第 1 部分:定义密文

  • 特别是,TFHE 使用三种类型的密文:LWE、RLWE 和 RGSW,因为它们都具有在同态运算中有用的不同属性。作为对这些密文的简短了解,让我们看一下广义 LWE (GLWE)——涵盖 LWE 和 RLWE 的概括。消息加密可以表示为:

图来源:zama 的文章“TFHE Deep Dive - Part I - Ciphertext types”。

其中M是加密消息,△= q/p其中q和p都是大整数(通常是2的幂),�我是密钥(最多 N 次方的 k 个多项式),�我是随机采样的系数(称为“掩模”),E 是噪声误差。每次加密都会对“掩码”和噪声错误进行采样,这意味着即使同一消息的加密也会有所不同。

为了能够解密消息,|E| 应小于 /2(|E|<  /2)。如果这个条件成立,解密将如下所示:

图来源:zama 的文章“TFHE Deep Dive - Part I - Ciphertext types”。

  • 回到引导程序,我们在“FHE 工作原理”部分中简要介绍了一种降噪工具,它恰好应用于前面摘要中描述的两步解密。特别是,它在单项式 X 的指数中进行第 1 步计算,然后使用这个新的单项式来旋转查找表 (LUT),以评估第二个解密步骤(重新缩放和舍入)。

  • 要从 GLWE 到 LWE,请取 N = 1(N 是 S 中多项式的最大可能幂)。

  • 要从 GLWE 到 RLWE,请取 k = 1(S 中多项式的数量)和 N – 2 的幂。

  • 为了简单地定义 GGSW,我们必须简单地定义 GLev,实际上就是 GLWE 密文的向量。那么,GGSW密文就是GLev密文的向量。如果 GLWE 密文是来自以下元素的向量右�,那么 GGSW 密文是元素的 3 维矩阵右�:

图来源:zama 的文章“TFHE Deep Dive - Part I - Ciphertext types”。

第二部分:密文同态加法 运算

  • 假设我们有两个 GLWE 密文加密消息 M 和 M'。然后,我们可以将两个密文的每个组成部分相加(在右�),结果将是一个新的 GLWE 密文,加密总和 M+M'。

图来源:zama 的文章“TFHE Deep Dive - Part II - Encodings and Linear Leveled Operations”。

  • 为了执行同态加法,我们添加右�组件术语:

未加密常量的同态 乘法

  • 假设我们有一个 GLWE 密文加密消息 M 和一个小的常数多项式 Λ。然后,我们可以将密文 M 的每个分量乘以多项式 Λ,结果将是对乘积 Λ⋅M 进行加密的新 GLWE 密文。

图来源:文章“TFHE Deep Dive - Part II - Encodings and Linear Leveled Operations”。

  • 对于解密,我们使用与 GLWE 描述的相同方法。

  • 为了将两个 GLev 密文或两个 GGSW 密文相加,只需将组成它们的相应 GLWE 密文相加即可。假设我们想要将 GLev 密文或 GGSW 密文乘以一个小的常数多项式 Λ。在这种情况下,将所有 GLWE 密文相乘就足够了,将它们组合乘以 Λ。

  • 然而,这仅在常数很小时才有效。如果常数很大,则噪声与其大小成比例增长。如果我们将密文的每个元素乘以一个大常数,噪声就会影响结果。为了解决这个问题,将大常数分解为小基数:

为了使分解可逆,我们使用了 GLev 加密

这是对 FHE 和 TFHE 底层内容的简短了解。有关更多详细信息,请查看 Zama 的精彩解释(第 1 部分第 2 部分第 3 部分第 4 部分)。

  • 另一种选择是基于NTRU假设的方案。然而,他们也表现出缺乏安全感。

  • 目前,仅假设 LWE 方法适用。缺点之一是 LWE 式加密要求每个密文由两个元素组成,而基于 NTRU 的方案的主要优点是密文仅由一个环元素组成。另一个担忧是,从某种意义上说,它把所有的安全鸡蛋都放在一个篮子里。

当前区块链中的 FHE 项目

区块链之外的 FHE

免责声明:本节的输入由 Cysic 联合创始人 Leo Fan 友情提供。

FHE可以应用于许多需要隐私保护计算的情况。

除了区块链之外,FHE 主要用于隐私保护机器学习。例如,在这种情况下,客户想要使用他的私人数据和外部人工智能模型。

客户端使用FHE对数据进行加密,然后将密文上传到服务器。服务器对密文运行人工智能模型的同态计算。计算完成后,服务器将加密结果发回,客户端可以解密并获知结果。

基于FHE的安全性和功能性,可以保证客户数据的保密性和结果的正确性。该应用程序的一个突出特性是客户端在评估过程中不需要与服务器交互。

进一步阅读

为了不朽

  • Craig Gentry 为那些真正对 FHE 感到兴奋的人撰写的 200 页关于完全同态加密方案的论文(注:这是 2009 年的文章,可能在某种程度上已经过时,但保证会很有趣)

来源

  • 研讨会“使用同态加密的私人智能合约 - Rand Hindi,ETHcc 5” 

  • “Morten Dahl - EVM 中的同态加密”研讨会

  • 一篇文章“使用同态加密和 fhEVM 的链上盲拍”。

  • 一篇文章“使用同态加密的加密键值数据库”。

  • 一篇文章“完全同态加密和后量子密码学”。

  • 一篇文章“使用同态加密的私人智能合约”。

  • “Secret Network 和 Zama 的完全同态早餐”研讨会

  • 安德鲁·米勒公司 (Andrew Miller & Co.) 的推特帖子

  • Ingonyama 的文章“通过 FHE 解决 LLM 隐私问题” 

已订阅

FHE简介:什么是FHE,FHE如何工作,它如何与ZK和MPC连接,FHE在区块链内外的用例有哪些等。

太鼓实验室

0x5b79

丽莎A.

10小时前

37 已收集

薄荷

特别感谢Leo Fan的宝贵意见和Tomer Solberg的反馈和审查。

长话短说

在本文中,我们简要解释什么是 FHE 及其工作原理,考虑其在区块链内外的用例,并涵盖未解决的问题和限制。最后,我们还提到了一些区块链 FHE 项目,并提供了一个列表以供进一步阅读。

内容

  • 介绍

  • FHE 的工作原理

  • FHE 用例

  • FHE 的担忧

  • FHE 技术细节

    • 关于格子的旁注

    • 简要(不是真正简短)观察 TFHE 的工作原理

  • 当前区块链中的 FHE 项目

  • 区块链之外的 FHE

  • 进一步阅读

免责声明:本文有时会引用 Secret Network(基于 FHE 的可定制隐私的区块链)和 Zama(基于 FHE 的加密工具)作为说明。有关研究和开发 FHE 的项目的更详细列表,请查看“区块链中当前的 FHE 项目”部分。

介绍

  • FHE 代表完全同态加密。

  • FHE 于 20 世纪 70 年代首次提出。然而,直到2009年,在实现全同态加密方面还没有太大进展。最好的结构提供了任意数量的加法,但只有一次乘法(而所需的结果是任意数量的加法和乘法)。

  • Craig Gentry在2009 年实现了开创性的飞跃,展示了第一个支持任意数量的加法和乘法的 FHE 结构。

  • FHE 支持加密数据处理。

图表来源:研讨会“Morten Dahl - EVM 中的同态加密”。

  • 也就是说,它对加密数据进行计算。

  • “完全”代表加法和乘法:

    加性同态:乙(米1)+乙(米2)=乙(米1+米2)

    乘法同态:乙(米1)*乙(米2)=乙(米1*米2)

  • 从数学角度来看,FHE 是一个已解决的问题。从工程角度来看,这是一项正在进行的工作,其核心瓶颈是性能。

  • FHE 不被认为是一个自给自足的解决方案(至少目前如此),而是提供隐私的组件之一,预计可与 ZKP、MPC 和 TEE 配合使用。

    例如,虽然FHE在计算过程中保护了数据隐私,但它并不能保证计算的真实性。为了缓解这个问题,FHE 可以与 ZKP 结合起来,以实现机密性和计算真实性。另一个例子是结合FHE和MPC来处理效率问题。然后,HE用于对加密数据进行线性计算,MPC处理非线性计算。

图表来源:研讨会“Morten Dahl - EVM 中的同态加密”。

FHE 的工作原理

  • 密文=加密数据+噪声。即在加密数据中添加随机噪声来保证安全性。

图来源:文章《使用同态加密的私人智能合约》

  • 然而,现在所有的计算不仅是对数据进行的,而且是对加上噪声的数据进行的。

  • 此外,经过多次操作后,噪声开始增大并溢出到实际数据位上,这可能会导致错误的结果。具体的增长速度取决于使用哪种编码。例如,可以在最低有效位 (LSB) 中添加噪声,同时在最高有效位 (MSB) 中添加消息,或者相反。它还可以包括填充(添加零位):

图来源:zama 的文章“TFHE Deep Dive - Part II - Encodings and Linear Leveled Operations”。

或者将消息和错误编码为单个事物:

图来源:zama 的文章“TFHE Deep Dive - Part II - Encodings and Linear Leveled Operations”。

  • 为了应对噪声的增长,只需​​为噪声的增长提供足够的空间即可。然后,它在速度方面变得相当高效,但可用计算的数量无论如何都是有限的(无论噪声空间有多大)。对于智能合约来说,它不起作用,因为有时它们可​​以无限更新(例如,ERC-20)。

  • 另一个问题是,通过添加噪声空间,只能进行加法和乘法,而比较和非线性函数则使用多项式近似来近似。对于机器学习案例来说它工作得很好,但对于智能合约来说,情况可能并非如此(例如,用户没有足够的资金,但交易通过了 - 不酷)。

  • 为了减少噪音,还可以使用自举(bootstrapping)。自举是一种特殊操作,可将噪声重置为其标称水平。它可以永远进行计算,但它是一种缓慢且昂贵的操作(无论是在内存消耗还是计算成本方面)。这就是为什么当我们谈论 FHE 研究时,我们实际上谈论的是自举加速。“FHE 技术细节”部分将介绍引导程序的工作原理。

  • 另一个解决方案是 TFHE——一种能够实现无限计算、精确任意数量(而不是近似)和非常快速引导的方案。使用 TFHE,引导操作可评估同态查找表。任何函数都可以编码为查找表。因此,TFHE 消除了近似和运算次数的限制。

表来源:研讨会“使用同态加密的私人智能合约 - Rand Hindi,ETHcc 5”

  • 另一个值得一提的FHE方案是CKKS(近似数算术同态加密)。其性能预计与 TFHE 接近,但优点有所不同。借助 CKKS,人们可以在引导程序之间执行更多操作,同时操作多个数据(在 SIMD 中,单指令/多数据),并处理整数和浮点数的更大位表示。CKKS 支持加密消息的近似加法和乘法以及用于管理明文大小的替代重新缩放过程。此过程将密文截断为较小的模数,从而导致明文舍入。主要思想是在包含主要信息的重要数字后面添加噪音。为了安全起见,这种噪声最初被添加到明文中,但被认为是近似计算期间发生的错误的一部分,通过重新缩放与明文一起减少。结果,解密结构输出具有预定精度的明文的近似值。评估过程中的精度损失受到电路深度的限制,与浮点运算等未加密的近似算术相比,最​​多多多一位。由于重新缩放过程,密文模数的位大小随着所评估的电路的深度线性增长。CKKS 还可用于有效评估超越函数,例如乘法逆函数、指数函数、逻辑函数和离散傅里叶变换。

  • Ingonyama 提供的当前 FHE 性能的另一个示例可以在本文中找到。它回答了“使用 FHE 运行 LLM 推理需要多长时间?”的问题。

FHE 用例

一般示例

  • 私有链上计算:

    • 加密交易数据:交易中包含的数据是加密的。

    • 加密状态更新:状态在保持加密状态的同时进行更新。

    • 加密的链上数据:存储在链上的数据保持加密状态。

    • 私有智能合约:私有计算+私有数据

      • 智能合约中不是整数,而是加密的整数。不应对常规智能合约编写逻辑进行其他更改。

      • 最棘手的部分是智能合约如何检查加密的余额。

  • EVM 中的 FHE(以 Zama 的 fhEVM 为例)

    • fhEVM不是区块链,而是其他区块链可以使用的加密组件。它还包括针对 FHE 优化的阈值协议、一个用于表达在加密数据上运行的智能合约的 Solidity 库以及用于构建 dapp 来正确加密数据并与加密区块链交互的 dapp SDK。

    • fhEVM 背后的机制

      • 所有内容均通过单一全球 FHE 公钥进行加密。

      • 全局密钥是使用阈值协议生成的(部分密钥分布在验证器之间)。

      • 输入使用 FHE 公钥加密。

      • 对加密数据的计算由验证器在本地完成。

      • 验证器可以使用阈值协议对值进行解密。

      • 值还可以使用阈值协议在另一个公钥(我们将其表示为*“公钥 a” )下重新加密(无需解密)。重新加密的值可以由公钥*所有者解密。

具体例子

  • 链上盲

    • 两个阶段:投标阶段和索赔阶段。投标阶段包括用户投标加密数量的代币(使用加密的 ERC20 合约)。当拍卖结束时,合约同态确定最高出价者。

    • 最终,合约只公开中标者,而中标价格和未中标价格则保密。

  • 一个市场,买卖订单在成交之前对公众不可见。

  • 机密 ERC-20代币

  • 加密的键值数据库

  • 无信任桥:使用加密密钥对桥交易进行同态签名。

  • 保密投票:加密的选择和代币数量。

FHE 的担忧

  • **就 FHE 区块链而言,整个网络只有一把钥匙。谁持有解密密钥?**这个“谁”将定义安全级别。按照Secret Network的建议,密钥片被分发到每个预言机节点——即使用阈值MPC。关于MPC安全性存在很多问题,对于依赖MPC安全性的FHE安全性也存在很多质疑。

  • 改进安全假设的一种方法是在 TEE 内部分运行秘密解密。然而,如果出于安全考虑,TEE 是可选的,那么使用它还有另一个原因:擦除问题。当 Oracle 节点轮换时,应保证前一个节点已删除其拥有的密钥份额。

  • 然而,与普通 MPC 相比,FHE 更好,因为它将大量计算外包给完全不可信的节点,然后只有半可信的仲裁用于阈值解密,这与 MPC 不同,在 MPC 中,该仲裁完成所有工作。

    怎么运行的:

    1. 密钥的各个部分是在验证者之间生成和共享的。

    2. 每个验证器都会进行部分解密。

    3. 部分解密被聚合以产生完整的解密值。

    它的安全性在 2/3 诚实验证者的假设下成立。然而,验证器集应该是固定的和有限的。

  • 在秘密网络的具体情况下,网络验证者需要在共识时间内做出断言。他们应该如何访问解密的数据?它不能使用“vanilla oracle”来完成,因为它会破坏隐私。解决方案是两轮共识机制。第一轮是关于应该解密什么的共识。也就是说,Oracle 会等待,直到大多数验证器向其发送相同的解密请求。然后,Oracle 对其进行解密。然后,验证器更新链状态并将块附加到区块链。

  • 如何防止用户解密其他用户的数据?如果用户只是编写一个合约来解密输入并提供其他人的加密数据作为该合约的输入怎么办?解决方案是零知识证明!用户应该提供他们发送到网络的每个加密输入的 ZKP,以证明用户确实知道他们以加密方式发送的值。

  • **FHE 的关键技术问题是其速度缓慢。**它的性能比已知的替代品慢得多。

  • 慢了多少?

  • FHE 性能取决于硬件加速,并且在 ASIC 出现之前预计不会便宜。

  • Leo Fan 表示,FHE 开销大约是未加密计算的 10,000 倍。使用 GPU 和 FPGA 的性能比 CPU 高 2 个数量级。为 FHE 设计 ASIC 可以实现 3-4 个数量级的性能提升(相对于 CPU),几乎缩小了 10,000 倍的差距。“如果应用程序需要无交互的解决方案,那么 ASIC 似乎是最佳选择。由于HE对于一些简单计算(例如线性计算)的性能和密文爆炸令人满意,因此GPU/FPGA加速的HE结合MPC技术可以在一些网络连接良好的应用中使用。”

  • 如果能够生成正确 FHE 执行的证明以避免执行冗余,我们就可以拥有可证明的 FHE(类似于 ZK)和 zk-FHE-rollups。

FHE 技术细节

安全

  • 为了考虑 FHE 安全性,假设我们有四个参与方:加密者、解密者、进行 FHE 计算的人以及对手。有可能加密者和解密者是同一个人,那么我们就处理对称FHE。可能存在多个加密器的情况。FHE 的安全假设假设所有这些方都可能不诚实。

密码学

  • FHE 是一种基于格子的结构。最初提出的 FHE 基于理想晶格,但从那时起,该晶格已被证明是不安全的。

关于什么是格子的旁注

  • 晶格是 n 维空间中点的周期性网格。可以有无限多的基础。基的长度是其最长向量的长度。我们将最长向量长度最小化的基称为“短基”。

  • 短向量格问题听起来如下:给定任意基 b,找到一个尽可能短的非零格向量。

  • 该问题的另一个版本称为解码问题。在此版本中,要求在定义的区域内找到一个目标点(不是最短的,但不长于某个特定值)。

图源:CryptoBook

这两个问题之间的核心区别在于,短向量问题需要唯一的向量。在解码问题下,我们保证在某个固定的足够大的半径内总是存在多个点。

  • 如果您在二维空间中考虑这个问题,那就很简单:晶格只是平面上无限的点集。这些点是通过两个“基向量”的整数线性组合生成的。困难的数学问题是找到生成晶格的两个短向量。在下图中,黑色向量是“基本向量”,红色向量是“困难数学问题”的解决方案:

图来源:文章《全同态加密与后量子密码学》

  • 在二维中,这个问题似乎非常简单。然而,当我们将维数扩大到更高时,这确实变得非常困难。特别是,随着维数的增加,复杂性呈指数级增长。当维度足够多时,它变得非常困难,以至于我们不相信即使是量子计算机也能够解决这个难题。

  • 该问题的重要参数是密码学基础的确切维度和初始基本向量的选择。

  • 晶格被认为是后量子原语背后的核心机制。

  • 许多改进的 FHE 方法(例如 FHEW、TFHE、BGV、BFV 和 CKKS)都基于误差学习 (LWE),从其术语来说,LWE 是基于格问题的。

简要(不是真正简短)观察 TFHE 的工作原理

  • TFHE 中的 T 代表 Torus,一种类似甜甜圈的数学结构。

  • 该方案的安全性基于称为 LWE(错误学习)的硬格问题。

  • TFHE 与其他方法的不同之处在于它提出了一种特殊的自举法,该自举法速度非常快,并且能够在降低噪声的同时评估函数。

第 1 部分:定义密文

  • 特别是,TFHE 使用三种类型的密文:LWE、RLWE 和 RGSW,因为它们都具有在同态运算中有用的不同属性。作为对这些密文的简短了解,让我们看一下广义 LWE (GLWE)——涵盖 LWE 和 RLWE 的概括。消息加密可以表示为:

图来源:zama 的文章“TFHE Deep Dive - Part I - Ciphertext types”。

其中M是加密消息,△= q/p其中q和p都是大整数(通常是2的幂),�我是密钥(最多 N 次方的 k 个多项式),�我是随机采样的系数(称为“掩模”),E 是噪声误差。每次加密都会对“掩码”和噪声错误进行采样,这意味着即使同一消息的加密也会有所不同。

为了能够解密消息,|E| 应小于 /2(|E|<  /2)。如果这个条件成立,解密将如下所示:

图来源:zama 的文章“TFHE Deep Dive - Part I - Ciphertext types”。

  • 回到引导程序,我们在“FHE 工作原理”部分中简要介绍了一种降噪工具,它恰好应用于前面摘要中描述的两步解密。特别是,它在单项式 X 的指数中进行第 1 步计算,然后使用这个新的单项式来旋转查找表 (LUT),以评估第二个解密步骤(重新缩放和舍入)。

  • 要从 GLWE 到 LWE,请取 N = 1(N 是 S 中多项式的最大可能幂)。

  • 要从 GLWE 到 RLWE,请取 k = 1(S 中多项式的数量)和 N – 2 的幂。

  • 为了简单地定义 GGSW,我们必须简单地定义 GLev,实际上就是 GLWE 密文的向量。那么,GGSW密文就是GLev密文的向量。如果 GLWE 密文是来自以下元素的向量右�,那么 GGSW 密文是元素的 3 维矩阵右�:

图来源:zama 的文章“TFHE Deep Dive - Part I - Ciphertext types”。

第二部分:密文同态加法 运算

  • 假设我们有两个 GLWE 密文加密消息 M 和 M'。然后,我们可以将两个密文的每个组成部分相加(在右�),结果将是一个新的 GLWE 密文,加密总和 M+M'。

图来源:zama 的文章“TFHE Deep Dive - Part II - Encodings and Linear Leveled Operations”。

  • 为了执行同态加法,我们添加右�组件术语:

    �0(+)=�0+�0′,�1(+)=�1+�1′,乙(+)=乙+乙′

未加密常量的同态 乘法

  • 假设我们有一个 GLWE 密文加密消息 M 和一个小的常数多项式 Λ。然后,我们可以将密文 M 的每个分量乘以多项式 Λ,结果将是对乘积 Λ⋅M 进行加密的新 GLWE 密文。

图来源:文章“TFHE Deep Dive - Part II - Encodings and Linear Leveled Operations”。

  • 对于解密,我们使用与 GLWE 描述的相同方法。

  • 为了将两个 GLev 密文或两个 GGSW 密文相加,只需将组成它们的相应 GLWE 密文相加即可。假设我们想要将 GLev 密文或 GGSW 密文乘以一个小的常数多项式 Λ。在这种情况下,将所有 GLWE 密文相乘就足够了,将它们组合乘以 Λ。

  • 然而,这仅在常数很小时才有效。如果常数很大,则噪声与其大小成比例增长。如果我们将密文的每个元素乘以一个大常数,噪声就会影响结果。为了解决这个问题,将大常数分解为小基数:

为了使分解可逆,我们使用了 GLev 加密

这是对 FHE 和 TFHE 底层内容的简短了解。有关更多详细信息,请查看 Zama 的精彩解释(第 1 部分第 2 部分第 3 部分第 4 部分)。

  • 另一种选择是基于NTRU假设的方案。然而,他们也表现出缺乏安全感。

  • 目前,仅假设 LWE 方法适用。缺点之一是 LWE 式加密要求每个密文由两个元素组成,而基于 NTRU 的方案的主要优点是密文仅由一个环元素组成。另一个担忧是,从某种意义上说,它把所有的安全鸡蛋都放在一个篮子里。

当前区块链中的 FHE 项目

区块链之外的 FHE

免责声明:本节的输入由 Cysic 联合创始人 Leo Fan 友情提供。

FHE可以应用于许多需要隐私保护计算的情况。

除了区块链之外,FHE 主要用于隐私保护机器学习。例如,在这种情况下,客户想要使用他的私人数据和外部人工智能模型。

客户端使用FHE对数据进行加密,然后将密文上传到服务器。服务器对密文运行人工智能模型的同态计算。计算完成后,服务器将加密结果发回,客户端可以解密并获知结果。

基于FHE的安全性和功能性,可以保证客户数据的保密性和结果的正确性。该应用程序的一个突出特性是客户端在评估过程中不需要与服务器交互。

进一步阅读

为了不朽

  • Craig Gentry 为那些真正对 FHE 感到兴奋的人撰写的 200 页关于完全同态加密方案的论文(注:这是 2009 年的文章,可能在某种程度上已经过时,但保证会很有趣)

来源

  • 研讨会“使用同态加密的私人智能合约 - Rand Hindi,ETHcc 5” 

  • “Morten Dahl - EVM 中的同态加密”研讨会

  • 一篇文章“使用同态加密和 fhEVM 的链上盲拍”。

  • 一篇文章“使用同态加密的加密键值数据库”。

  • 一篇文章“完全同态加密和后量子密码学”。

  • 一篇文章“使用同态加密的私人智能合约”。

  • “Secret Network 和 Zama 的完全同态早餐”研讨会

  • 安德鲁·米勒公司 (Andrew Miller & Co.) 的推特帖子

  • Ingonyama 的文章“通过 FHE 解决 LLM 隐私问题”

加入我们💗

探索我们的 招聘网站上的空缺职位。

关注我们🥁

从 Taiko 获取最新信息:

贡献🤓

在 GitHub 上为 Taiko 做出贡献并获得 GitPOAP!您还将成为我们自述文件的贡献者。开始使用 贡献手册

0
粉丝
0
获赞
52
精选
数据来源区块链,不构成投资建议!
网站只展示作者的精选文章
2022 Tagge. With ❤️ from Lambda