定义

零知识证明技术满足以下三个性质：

完备性（Completeness）：如果证明者 P 知道证据（Witness）能证明命题的正确性，则能以极大概率让验证者 V 信任。
正确性（Soundness）：一个恶意的证明者 P’ 难以用一个错误的命题欺骗验证者 V。这里的正确性区分为计算正确性和完美正确性。满足计算正确性的零知识证明方案能防止只能做多项式时间计算的恶意证明者（可以简单理解为恶意证明者只有有限计算资源），这样的方案也称为“论据”（Arguments），之后将会介绍的zk-SNARK和zk-STARK方案都属于 Arguments，而满足完美正确性的方案可以防止拥有任意计算资源的恶意证明者。
零知识性（Zero-knowledge）：一个恶意的验证者 V’ 不能获取除了命题是否正确以外的信息。同样，我们区分计算零知识性和完美零知识性。

fig1

从交互式到非交互式

fig2

目前为止，我们介绍的例子包括数独游戏和三染色问题，都需要验证者和证明者同时在线，并且通过若干轮验证者的挑战和证明者的回应来完成证明。这样一来零知识证明方案存在很多限制：首先参与方必须同时在线，并且只有验证者才会相信证明的正确性，因为只有验证者才知道提出的挑战是随机的，还是和证明者串通作弊的。

这一限制在传统的中心化节点的架构中并不严重，我们可以相信中心化节点的验证以及颁发的证书（比如在DNS，HTTPS等协议中）。但是在区块链领域，用户信奉着“Don’t trust, verify it”（别相信，验证它）的理念。所有参与的节点都需要独立验证区块链上的数据是否正确，如果我们要求证明者时刻在线等待着所有参与节点发起的挑战，那么只有极少服务器可以作为证明者参与这一过程，普通人将难以使用该系统。

因此，如果我们希望其他人也信任该证明的正确性，要么其他人都信任该验证者，要么存在一个公开可信的随机数列作为“验证者”的身份发起挑战。但这也存在一个问题，如果随机数列是公开的，那么证明者也可以访问到，进而根据这一数列提前伪造承诺。如果大家对前文的时光机部分还有印象，那么就知道我们需要的是与承诺数据相关的挑战，这样可以避免证明者事先伪造好承诺。换句话说，我们需要通过承诺计算得到公开可信的随机数列。实际上，利用hash函数结果的随机性，我们可以将承诺数据的hash计算结果作为随机数列用于生成挑战，这也就是 Fiat–Shamir 变换[1]，具体过程如图二所示。