撰文：康水跃，Fox Tech CEO；孟铉济，Fox Tech 首席科学家

前言

密码学当中的零知识证明技术在 web3 世界有着广泛的应用，包括进行隐私计算、zkRollup 等等。其中 Layer2 项目 FOX 所使用的 FOAKS 就是一个零知识证明算法。在上述的一系列应用当中，对于零知识证明算法而言，有两方面属性极为重要，那就是算法的效率以及交互性。

算法效率的重要性不言而喻，高效的算法可以明显的降低系统运行时间，从而降低客户端延迟，显著的提高用户体验和效率，这也是 FOAKS 致力于实现线性证明时间的一个重要原因。

另一方面，从密码学的角度来讲，零知识证明系统的设计往往依赖证明者和验证者的多轮交互。例如在许多介绍零知识证明的科普文章当中都会使用的“零知识洞穴”的故事当中，证明的实现就依赖于阿里巴巴（证明者）和记者（验证者）多轮的信息传递交互才能实现。但是事实上，在许多应用场景当中，依赖交互会使得系统不再可用，或者极高的增加延迟。就像在 zkRollup 系统当中，我们期望证明者（也就是 FOX 当中的 folder）能够在本地，不依赖于和验证者交互的情况下就计算出正确的证明值。

从这个角度说，如何将交互式的零知识证明协议改造为非交互式，就是一个很有意义的问题。在这篇文章当中，我们将介绍 FOX 使用经典的 Fiat-Shamir 启发式（heuristic）来生成 Brakedown 中的挑战从而实现非交互式协议的过程。

零知识证明中的 Challenge

零知识证明算法随着应用的铺开而变得异常火爆，近些年也诞生了包括 FOAKS、Orion、zk-stark 等在内的各种算法。这些算法，以及密码学界早期的 sigma 协议等的核心证明逻辑都是证明者（Prover）先将某个值发送给验证者（Verifier），验证者通过本地随机数产生一个挑战（Challenge），将这个随机产生的挑战值发给证明者，证明者需要真的有知识才能以大概率做出通过验证者的响应。例如在零知识洞穴当中，记者抛一个硬币，告诉阿里巴巴从左侧出来还是从右侧出来，这里的“左和右”就是对阿里巴巴的挑战，他如果真的知道咒语，就一定可以从要求的方向走出来，否则就有一半的概率失败。

这里我们注意到，Challenge 的生成是一个很关键的步骤，它有两个要求，随机和不可被证明者预测。第一点，随机性保证了它的概率属性。第二点，如果证明者可以预测挑战值那就意味着协议的安全性被破坏了，证明者没有知识也可以通过验证，可以继续类比，阿里巴巴如果能预测记者要求他从哪边出来，他即使没有咒语也可以提前进入那一边，结果表现出来一样可以通过协议。

所以我们需要一种办法，能够让证明者自己本地生成这样一个不可预测的随机数，同时还能够被验证者验证，这样就可以实现非交互式的协议。

哈希函数（Hash Function）

哈希函数的名字对我们来说或许并不陌生，无论是在比特币的共识协议 POW 当中担任挖矿的数学难题，还是压缩数据量，构造消息验证码等等，都有哈希函数的身影。而在上述不同的协议当中，其实是运用了哈希函数的各种不同性质。

具体来讲，安全的哈希函数的性质包括以下几点：

压缩性：确定的哈希函数可以将任意长度的消息压缩成为固定长度。

有效性：给定输入 x，计算输出 h（x）是容易的。

抗碰撞性：给定一个输入 x1，希望找到另一个输入 x2，x1x2，h（x1）= h（x2），是困难的。

注意，如果哈希函数满足抗碰撞性，那么必然满足单向性，也就是说给定一个输出 y，要找出 x 满足 h（x）= y 是困难的。在密码学当中，还不能构造出理论上绝对满足单向性的函数，但是哈希函数在实际应用当中可以基本视作单向函数。

这样一来，可以发现上述的几种应用分别对应于哈希函数的几点不同的性质，同时我们说，哈希函数还有一个很重要的作用是提供随机性，虽然密码学理论当中要求的完美的随机数生成器目前也无法构造，但是哈希函数在实际当中同样可以充当这个角色，这就为我们后文介绍的 Fiat-Shamir 启发式（Heuristic）的技巧提供了基础。

Fiat-Shamir 启发式（Heuristic）

事实上，Fiat-Shamir 启发式（Heuristic）就是利用哈希函数来对前面生成的脚本进行哈希运算，从而得到一个值，用这个值来充当挑战值。

因为将哈希函数 H 视作一个随机函数，挑战是均匀随机的被选择，独立于证明者的公开信息和承诺的。安全分析认为 Alice 不能预测 H 的输出，只能将其当作一个 oracle。在这种情况下，Alice 在不遵循协议的情况下做出正确响应的概率 ( 特别是当她不知道必要的秘密时 ) 与 H 的值域的大小成反比。