🔥干货科普分享（你知道 ZK 和 FHE 具体说的是啥吗？） 最近其实隐私概念开始陆续被一些 NFT 项目拿来做文章了。 比如之前比较火的 Zcash 生态的 NFT 项目 @zec_bit ，以及基于 Zama FHE 方案的 @FungoLabs 其实很多人只知道 ZK、FHE 是两种隐私相关的密码学方案，但对它们其实并不了解，我之前恰好写过这两方面的文章，也有过一些浅浅的研究，可以借这个机会聊聊。 我尽量用大家都能看懂的人话，把 ZK 和 FHE 的原理解释清楚。（建议收藏） ──────────────────────────────── 1/ ZK：零知识证明 ZK 全称 Zero-Knowledge，之前其实我更习惯叫它 ZKP，也就是 Zero-Knowledge Proof。 上两轮周期我接触过很多 ZK 类项目，一般能玩得动 ZK 的开发团队，都有点东西，开发起来很复杂。 所谓零知识证明，就是你想向对方证明某件事情是真的，但又不希望把背后的秘密或者原始数据暴露给对方。 比如说： 你想向银行申请贷款，银行要求你的存款必须超过 100 万美元，但你不想告诉银行自己具体有多少钱，也不想公开账户信息。 这个时候就可以使用 ZK。 你可以向银行提供一个数学证明，银行通过验证这个证明，就可以确认你的存款确实超过了 100 万美元。 整个过程中，银行并不知道你具体有多少钱，却可以确认你符合贷款条件。（这里有个前提，就是你用于生成证明的存款数据，本身必须来自可信的银行凭证） 那么更深入一些，ZK 的实现我觉得可以简单理解为三个步骤： ✅ 第一步：把需要证明的事情，转化成一套数学规则，也就是电路。 比如上面的例子，就是设计一套规则：要求证明者确实拥有可信的存款凭证，并且凭证里的余额超过 100 万美元。 这个电路本质上是由大量数学约束组成的计算逻辑，这个就比较复杂了。 ✅第二步：通过证明系统生成一份零知识证明，也就是我们说的 ZKP。 常见的零知识证明技术有 zk-SNARK、zk-STARK（不止这两种），它们是几类不同的证明技术，当然不同系统的复杂程度也不一样。 证明者把自己的秘密数据和公开条件输入证明系统，通过大量数学运算，最终生成一份可以被验证的密码学证明。 ZK 属于一种比较消耗计算资源的方案，尤其是生成证明通常需要消耗比较多的计算资源，这个就看你用的什么证明系统了，不过验证证明往往可以相对高效地完成。 ✅ 第三步：验证这份证明。 银行只需要按照验证规则检查 ZKP 是否有效。 如果证明有效，就可以确认相应的数学条件成立。 ZK 的安全性建立在密码学数学难题、证明系统的可靠性以及电路设计正确的基础上。 在这些前提成立的情况下，想要凭空伪造一份有效证明，在计算上几乎超级难。 当然，ZK 在我们行业主要的另一个用例是提高效率。 比如 L2 方案里的 ZK Rollup，就是在链下完成大量交易计算，再通过证明让以太坊验证计算结果，从而提高效率、降低成本。 代表性项目包括： @zksync 、最近涨的贼猛的 @Starknet 、 @aztecnetwork 、 @Scroll_ZKP 、 @LineaBuild 、 @taikoxyz 等等吧。 ──────────────────────────────── 2/ FHE：全同态加密 FHE 全称中文叫全同态加密。 其实我个人认为，FHE 要比 ZK 更复杂。 它本身在实际工程中，要对大量加密数据持续进行复杂计算，技术难度和计算开销通常都很高，目前的探索其实还处于相对早期的阶段。 所谓 FHE，就是让一份数据即便处于加密状态，别人仍然能够直接对它进行计算，而不需要知道原始数据是什么。 我们还是用上面那个贷款的例子。 这次银行不仅要求你的存款超过 100 万美元，还需要根据你的收入、存款、负债等数据计算信用评分，决定最终给你多少贷款额度。 但你不希望银行掌握自己的完整财务情况。 这个时候也可以使用 FHE。 就是你先把自己的财务数据全部加密，再把加密后的数据交给银行。 银行虽然看不到你的原始数据，但仍然可以直接对这些加密数据进行计算，最终得到一份加密的信用评分。 然后你通过自己的密钥把计算结果解密，就能得到正确的评分。如果银行需要这个结果来审批贷款，还可以通过授权等方式获取最终评分。 那么 FHE 到底是怎么实现的？ 我们同样分成几个步骤： ✅ 第一步：先通过特殊的加密算法，把原始数据变成密文。 比如你有两个数字，10 和 20。 经过 FHE 加密以后，别人看到的就不再是 10 和 20，而是两份无法直接看懂的密文。 ✅ 第二步：利用同态加密的数学特性，直接对密文进行计算。 传统加密技术一般需要先把数据解密，才能正常进行计算。 但 FHE 不需要，它通过特殊的数学结构，让密文上的运算能够对应到原始数据上的运算。 比如： 原始数据是：10 + 20 = 30 加密数据则是：密文 A + 密文 B = 密文 C 虽然别人不知道 A 和 B 分别代表什么，但是按照 FHE 的运算规则计算以后，最终把密文 C 解密，就能够得到 30。 ✅第三步：处理密文计算过程中产生的噪声。 很多 FHE 方案基于格密码学，在加密过程中会引入一定的数学噪声，以此保证数据的安全性。 但是随着密文不断进行加法、乘法等运算，这些噪声也可能不断积累。 如果噪声超过一定范围，最后就可能无法正确解密。 所以，FHE 需要通过一系列数学技术控制噪声，有些方案还会使用一种叫做自举的技术。 你可以把它理解成，在不暴露原始数据的前提下，给密文进行一次刷新，让它能够继续参与后面的计算。 因为这些复杂的加密运算和噪声管理机制，所以 FHE 的计算成本会远远高于直接处理明文数据。 所以 FHE 的主要技术挑战之一，是如何把它的计算成本降下来，让它能够真正进入大规模的商业应用。 （目前说自己在 FHE 上大规模采用的项目，都 TM 是吹牛逼） 💡 FHE 里面还有一个概念：全同态和半同态 同态加密并不只有 FHE 这一种，按照计算能力的不同，大致可以分成三类： 第一类：部分同态加密（PHE），也经常被笼统地叫作半同态。 它只能支持特定类型的计算。 比如有的只能对密文做加法，有的只能做乘法，无法像普通计算机一样同时灵活处理各种运算。 但是因为支持的计算比较简单，所以在特定应用中，性能和实现成本往往更有优势。 第二类：有限同态加密（SHE）。 它比部分同态更进一步，可以同时支持一定程度的加法和乘法。 但是由于计算过程中会积累噪声，能够连续执行的计算深度受到限制。 第三类：全同态加密（FHE）。 它在理论上可以支持任意可计算的函数，通过自举等技术突破有限计算深度的限制。 也就是说，它不仅能够进行简单的加减乘法，还能通过组合基础运算来完成更加复杂的计算任务。 当然，计算能力越灵活，通常也意味着需要付出更大的计算资源和性能成本。 所以并不是所有场景都必须使用 FHE，很多只需要简单加密运算的业务，用部分同态或者有限同态方案反而可能更合适。 ──────────────────────────────── 所以相对来说： ZK 其实解决的是可信验证问题： 上面的例子是，我不告诉你自己有多少钱，但可以通过数学证明，让你确认我的存款超过 100 万美元。 FHE 解决的是隐私计算问题： 即我不告诉你自己的收入、存款和负债，但是你仍然可以在看不到原始数据的情况下，帮我计算出信用评分。 一个侧重于证明，一个侧重于计算。 它俩其实并不冲突，甚至可以结合使用。 比如通过 FHE 对加密数据进行计算，再结合 ZK 等可验证计算技术，证明计算过程符合规定的规则。 既可以保护数据隐私，也可以进一步解决计算结果是否可信的问题。 以后嘴撸 ZK 或者 FHE 相关项目以前，先整明白是啥，不然你就是不懂装懂！！！