前言
本篇是“PLONK VS Groth16”的下篇,在上篇中我们对PLONK作了简要介绍,分析了PLONK和Groth16算法在「可信验证」和「约束构建」上的异同。那么,接下来让我们一起看看在后续的「证明生成」和「验证阶段」两者将有怎样的差异,以及整体上的性能区别。
原文链接:https://mp.weixin.qq.com/s/xrLe4cJVucr_m69cBF8wfQ
证明生成
对于程序qeval, prover需要证明自己知道qeval(x)=35的解,即x=3。
def qeval(x):
y = x**3
return x + y + 5
在上篇中我们已经介绍了PLONK的约束形式:门约束与线约束。继续使用之前的例子(如上所示),约束意味着零知识证明系统将这个问题约束成了一组格式固定的数学表达式,即问题描述等价于约束描述。而如果证明者(Prover)真的知道这个问题的答案,将答案和计算中的中间参数代入约束表达式,这个组表达式必将是成立的。反之,如果该Prover提供的一组解无法使表达式成立,说明prover并不具备关于该问题解的知识。
这是最朴素的证明验证思路,可以将它看作是“锁”和“钥匙的配对“:该问题约束的构建类似于“打造门锁“,而针对该问题提供的一组解信息就是”一把开启门锁的钥匙“。显然,Prover可以举着自己的解交给验证者(Verifier)来验证。可是这违背了我们的零知识原则:Verifier不应该获取到Prover的隐私信息。
那么有什么方法能在解锁的同时保护隐私信息呢?
这里我们用到一个简单的数学小技巧