a16z关于SNARK的17个误解（假设相同的多项式承诺方案或SNARK的部署具有相似的运行时间）

在这篇文章中，我将谈谈随着该技术在过去几年中的快速发展，我所接触到的一些误解。首先，我要解释什么是SNARK，以及它们在加密货币及其他领域的重要性。

SNARKs允许潜在的敌对实体对数据进行处理，然后证明数据是有效的，并已被正确处理，而无需公布实际数据。例如，第二层卷积可以向不信任的“验证者”（如以太坊区块链）证明，他们知道一些满足特定属性的数据，如一批有效交易，其执行会导致给定的全局状态。通过这种方式，以太坊区块链本身无需处理交易，甚至无需存储数据（尽管滚动通常会向区块链发布足够的数据，以确保状态是可重构的）。

如果SNARK满足零知识属性，那么它也可以用于隐私保护；例如，让某人证明自己将钱存入了混合池（因此有权从池中取款），而不透露哪笔存款交易是自己的。

实体还可以出于合规目的有选择地披露其他信息，例如他们是否在白名单上或不在黑名单上，或者他们是否向指定地址转移了适当的税款，而不会泄露其他敏感信息（例如税款计算的具体细节）。

SNARK在区块链之外也有许多潜在的应用，可以在信任不存在的情况下促进信任。

SNARK起源于20世纪80年代和90年代，直到最近才从理论走向实践，这得益于研究人员、工程师和开发人员在Web3方面取得的进步。我之前已经讨论过SNARK的设计原理、性能和安全性，以及其发展历史。

但随着的发展进程加快，以及认可这项实用技术的人数日益增长，我们在思考和谈论时必须要准确。设计领域是复杂而微妙的，一不小心就会导致各种误解和错误，从而延缓进展并造成无尽的挫折。我整理了一份这些误解的清单，并试图在此加以澄清。我希望这份清单对社区和任何在基础上进行开发的人都有用，也欢迎大家提出建议，以便我在今后的文章中再加以阐述。

术语混淆

1. 用“ZK”表示“简洁”

人们经常使用“ZK-proof”一词来指那些事实上并非零知识的简洁论证。同样，ZK-rollups通常不使用零知识证明，只使用简洁证明。

“简洁”是指证明简短，验证速度快。但“零知识”意味着证明者声称知道的“证人”的任何信息都不会泄露。简洁是关于（验证）性能，而零知识是关于证明者敏感数据的隐私。

使用“ZK-proof”来指代所有简洁论证的做法，可能是因为靠前个大规模部署SNARKs的项目ZCash实际上属于零知识的范畴，因此该术语在指代该特定项目时是准确的。还有一种可能是，人们根本就没有“简洁论证”这个术语的简称，所以尽管ZK并不准确，他们还是开始使用ZK（“基于SNARK的rollup”不像“ZK-rollup”那么有趣且易说）。

作为一个团队，我们应该更加精确。虽然技术专家可能能够解析其本意，但我经常与一些人交谈，他们对此感到非常困惑，尤其因为“ZK”一词确实有精确的技术含义。

这不仅仅是迂腐，期望每个人都能以某种方式区分术语的精确使用和非精确使用是有实际风险的。有人可能会得出这样的结论：一个SNARK库满足了零知识的要求，因为它将自己称为“ZK”；尽管它泄露了关于证人的信息，导致他们在一个隐私关键型应用中危险地部署了一个非零知识的库。

我的建议是，用“verifiable rollup”或“validity rollup”来代替“ZK-rollup”更为直观。当我想提及一个简洁的论证（可能涉及零知识，也可能没有）时，我会说SNARK或“简洁论证”，而非ZK-proof。而在需要强调SNARK是零知识的情况下，我会使用“zkSNARK”。

2.“简洁”一词的变体

SNARK中的S代表“简洁”，泛指具有简短证明和快速验证的证明系统。虽然这看起来足够简单明了，但人们在使用“简洁”一词时却有不同的定量含义，从而导致混淆。

许多作者使用“简洁”一词来指证明长度和验证时间至多为验证程序运行时间的多对数的协议。还有一些人更进一步，仅指恒定大小的证明。然而，我用它来指亚线性，而不是多对数或常数。

我认为其他人也应该采用这种做法：首先，简洁的“正确”定义应该涵盖任何具有有趣的定性验证成本的协议。

我所说的“有趣”是指任何证明规模和验证时间小于琐碎证明系统相关成本的协议。

所谓“琐碎的证明系统”，指的是证明者将整个见证发送给验证者，由验证者直接检查其正确性的证明系统。

此外，一旦设计出具有有趣验证成本的证明系统（例如√nλ�λ哈希值），就可以通过SNARK组合进一步降低成本，而不会显著增加证明者的时间。

其次，优越的渐进性并不总能**为优越的具体性能。（例如，请参阅下面#16中Ligero和FRI多项式承诺的比较）。

如果我们坚持一个证明系统的验证成本必须是多项式的，才有资格成为SNARK，那么我们就必须使用完全不同的术语来指代一个使用Ligero多项式承诺的项目（其验证者的验证成本约为 √nλ�λ哈希值），而不是 FRI（其验证器执行约λ log(n)2 哈希值）。

这很糟糕，由此产生的协议具有相同的安全属性，而FRI的证明规模优势甚至要等到被证明的语句大于某些应用中实际出现的语句时才会显现出来（而Ligero的证明者优势在所有规模下都存在）。

为了更精确和更具包容性，我使用“简洁”来指任何具有亚线性证明规模的协议，而用“省时”来指任何具有亚线性验证时间的协议。这确保了具有小证明但线性时间验证的SNARK（如基于IPA/Bulletproofs多项式承诺方案的SNARK）确实符合SNARK的条件。

为什么许多作者使用多对数验证成本作为“简洁”的标准？这种做法源于这样一个事实，即在理论语境中，多对数成本被视为划定界限的自然位置，这与“多项式时间”被视为理论计算机科学中“高效”算法的基准（尽管许多多项式时间算法都是无可救药的不切实际的）如出一辙。

但是，SNARK设计与多项式时间算法研究的共同点并不那么多，它与亚线性算法领域的共同点更少，后者研究的是如何处理大到算法无法读取或存储全部内容的输入。与今天对SNARK的研究一样，亚线性算法也在很大程度上是出于实用性的考虑。正如总有一个微不足道的证明系统，即证明者向验证者发送整个见证，在亚线性算法中，总有一个线性成本的微不足道的解决方案（即读取并存储整个输入）。

因此，正如亚线性算法领域选择了包容性——宣布任何具有亚线性代价的解都是有趣的，我们也应该为SNARKs做同样的事情。

3. SNARKs vs. STARKs

经常有人要求我解释SNARKs和STARKs之间的区别，我不得不在这里讨论它们的含义。

SNARK是 of 的缩写。我已经讨论过 "简洁 "的含义。"非交互式 "意味着验证者无需向证明者发送任何挑战，因此证明可以（例如）发布在区块链上，供任何区块链节点随意验证。"知识论证 "是指多项式时间证明者能够找到令人信服的证明其认识证人的唯一方法是实际认识证人。

STARK在科学文献中被介绍为具有精确的技术含义。

STARK是 of 的缩写。

(许多人很合理地认为S的意思是 "简洁"，正如SNARK中的意思一样；见本文第3.3节）。

但在这，"可扩展 "是指证明者的时间与验证程序的运行时间成类线性关系（即线性到对数因子），验证成本（时间和证明大小）与运行时间成多项式关系。

"透明 "是指证明系统不需要可信设置。

根据这一技术定义，目前存在许多STARK。

那么，混淆的根源及其后果是什么呢？至少有三个。

首先，在公开讨论中，"STARK "的含义与 "ZK "一词一样，在很大程度上偏离了我上面解释的技术含义。该术语现在通常用来特指（将Stark纳入其品牌名称）的证明系统及其近似衍生产品。

值得注意的是，术语 "STARK "并没有指定协议是否是交互式的。据我所知，今天的STARK完全是非交互式部署的（这使得它们成为SNARK）。这导致公众在讨论已部署证明系统的安全性时产生了很大的困惑。

第二，当一个证明系统是交互式部署时，其安全级别可能比非交互式部署时低得多。攻击交互式部署的对手在不与验证者交互的情况下无法知道尝试的攻击是否会成功，这大大降低了尝试攻击的速度，增加了成本，并使验证者看到攻击。此外，与交互式部署相比，非交互式部署需要更强的加密假设。

由于 "STARK "一词并未指明协议是否是交互式的，因此它混淆了有关部署的可接受安全参数的讨论。在我发表了上一篇关于这个话题的博文之后，有很多人联系我，告诉我他们认为目前部署的STARK是交互式的，因此低安全级别是合适的。显然他们错了。

第三，"STARK "一词的引入导致社区中的许多人滥用 "SNARK "一词，误将其特指具有可信设置的SNARK，如及其前身。这样做是为了将这些SNARK与及其后代区分开来。

我的建议是：我们不需要为协议可能满足的每一个属性集合使用不同的缩写，尤其是如果这会导致对核心问题（如适当的安全级别）的混淆。

术语 "透明SNARK "非常清楚，应该用来指任何透明的SNARK。

如果部署了交互式模拟，则可以简单地将其称为透明交互式论证。

(在这篇文章中，我使用 "STARK "一词来指及其衍生的证明系统，因为这里描述的一些误解特别适用于这些证明系统）。

SNARKs设计者和用户的一些常见误解

4. 只有Plonk后端才能支持 "Plonkish电路"，只有基于STARK的后端才能支持AIR

如今，许多项目都在使用过度为特定后端定制的约束系统。因此，人们往往无法区分约束系统本身和为其量身定制的后端。此外，到目前为止，业界还没有认识到，与这些约束系统所定制的后端不同的后端也可以证明关于这些约束系统的声明（而且还具有性能优势）。

这些误解导致了科学文献和公共讨论中对不同后端相对性能的错误论断。因此，项目的努力方向出现了偏差，部署的SNARK性能不尽如人意。

相关背景：

l SNARK的部署通常是先应用前端，将适当的验证检查程序**为一种电路；然后应用后端，即用于电路可满足性的SNARK。

l "Plonkish "指的是Plonk后端能够证明的一种电路（或者更准确地说，一种约束系统）。

l 代数中间表示法（Algebraic Intermediate Representation，AIR）是指STARK后端可以证明语句的另一种电路（粗略地说，是一种结构特别复杂的Plonkish电路）。

一个常见的误解是，Plonk是唯一能够证明Plonkish电路相关语句的后端，而STARK是唯一能够证明AIR相关语句的后端。事实上，人们经常无法区分 "Plonkish"（一种约束系统）和Plonk（一种能够证明Plonkish约束系统的特定后端），我也遇到过类似不区分AIR和STARK后端的情况。

这种混淆是可以理解的。事实上除了混乱的命名约定之外，Plonkish和AIR的定义往往是针对Plonk和STARK后端如何工作的低级细节。

到底发生了什么？大多数SNARK可以很容易地调整为同时支持Plonkish和AIR。

主要的例外是及其前身，它们仅限于 "约束"，特别是对于约束系统的一个子类，即 "秩一约束"（R1CS），实现了最快的验证。(顺便提一下，很多人没有意识到及其前身可以修改为支持任意约束，而不仅仅是秩一约束。验证者的成本随着约束的阶数增加而增加，但可以通过递归来降低。参见下面的 #6）。

有些人似乎对各种SNARK的相对通用性有一个基本落后的概念。Plonk和它的后代，例如，无法在不增加证明者开销的情况下处理R1CS。但是像和这样的SNARK，它们最初被描述为针对R1CS，并且经常因为不支持和AIR这样的流行电路类别而被剔除--可以处理这个问题。

事实上，Spartan和Marlin支持R1CS、Plonkish和AIR的简洁概括，称为可定制约束系统（CCS）（见下图1）。

它们还具有性能优势。

例如，Plonk要求验证者承诺电路中每条 "线 "的值，并使用所谓的复制约束来确保分配给从单个门出来的每条 "线 "的值是相等的。

这些承诺成本通常是验证器的瓶颈。

因此，使用Plonk及其变体的工程师在开发 "相对引用 "等概念方面投入了大量精力，目的是最大限度地减少Plonk电路中的复制约束。

在中，当处理具有重复结构的电路时，验证者只对电路中的每个乘法门承诺一个值。门的数量总是比线的数量少（通常至少少两倍）。当应用于具有重复结构的电路时，加法门是 "免费"的：加法门不增加证明者的承诺成本，也不增加证明者的其他成本，只是增加了 "直接验证检查"所需的工作，即在不保证正确性的情况下对验证电路进行评估所需的工作。

尽管AIR和Plonkish电路很受欢迎，但它们的概念过于受Plonk和STARK后端低级细节的影响。模块化在概念和性能上都有好处，在这种情况下，模块化意味着将用于表示见证检查程序的电路类型与用于证明该电路满足性的后端明确分开。

建议：我主张使用像CCS这样的约束系统，它的定义与R1CS的精神相同，只涉及矩阵向量积和Hadamard（即条目向）向量积。正如R1CS明显有别于像Groth16这样用于证明它的流行后端，CCS也明显有别于任何用于证明它的特定后端。CCS可以捕捉到当今最流行的约束系统，而不会产生开销。

5. SNARKs针对R1CS不能支持查找参数

相关背景：查找参数是一种特殊的SNARK，它可以与通用SNARK相结合，以大大减少通用SNARK所摄取的电路的大小。SNARK设计中的查找参数概念是在Arya中引入的，Arya在R1CS的一个特例--扇入二的算术电路中描述了查找参数。

有鉴于此，我不知道为什么会产生R1CS的SNARK不能与查找参数接口的误解。也许这与Plookup有关，Plookup是一种流行的查找论证，最初使用的是受Plonk后端启发的技术。但是，就像Plonk不是唯一支持 "Plonkish circuits "的后端一样，Plonk也不是唯一能够证明Plookup中隐含的约束系统的可满足性的后端。

许多查找论证可以归结为 "大乘积"论证——计算大量承诺值的乘积。大乘积可以通过扇入2的算术电路（通过乘法门的二叉树）高效计算，这是R1CS的一种非常特殊的情况。在计算大乘积时，我们可能不想将R1CS的SNARK作为一个黑盒子，而是要修改R1CS的SNARK的基础技术，以利用大乘积的特殊结构来提高具体效率（例如，参见本文第5节和第6节）。

影响：这种误解导致对不同SNARK相对性能的估计出现重大误差。一个典型的错误是在电路上运行最初被描述为针对R1CS的SNARK，这些电路比被描述为针对Plonkish的SNARK大一个数量级以上，理由是前者不能支持查找或高阶约束。实验者自然而然地得出结论，后者比前者更快。但他们得出这一结论的原因很简单，因为前者是在比必要大得多的电路上运行的。

一个相关的、但更普遍的错误是将后端与具有大型评估证明的多项式承诺方案结合起来，然后得出结论认为后端本质上具有大型证明。事实上，证明的大小主要取决于多项式承诺方案的选择。在大多数情况下，任何SNARK都可以使用任何多项式承诺方案，主要的复杂性在于，一些SNARK需要对多线性多项式进行承诺，而另一些则需要对单变量多项式进行承诺。

建议：了解哪些前端技术（和其他优化）可以与哪些后端相结合是一项挑战。因此，SNARK的设计者会对不同后端的相对性能得出不准确的结论。

有些混淆是不可避免的，因为新的前端技术（和其他优化）通常是在特定的后端背景下描述的，尽管它们的适用范围更广。此外，现有的后端可能需要进行修改，以便与新的前端和其他优化技术相结合。

但是，我们可以而且应该改善这种状况。例如，社区可以鼓励更深入地了解最初被描述为以R1CS为目标的后端，直到现在，这些后端一直被恶意诽谤为无法与某些前端技术对接。我们可以鼓励人们在断言现有的后端无法与新的前端或其他优化技术对接之前，更认真地修改现有的后端。最后，应尽可能使用相同的多项式承诺方案对不同的后端进行比较。

6. Plonk对证明者来说比Groth16更快

相关背景：Groth16需要一个特定电路的可信设置；证明一个新电路的可满足性需要运行一个新的可信设置。普朗克有一个通用的设置，这意味着一个设置就可以支持达到指定大小边界的所有电路。人们可能会认为，普朗克求证器应该为实现通用设置付出性能代价，但许多人认为普朗克求证器实际上比Groth16求证器更快。

事实并非如此。

细节：Plonk无法支持无开销的R1CS。以R1CS为目标，但无法支持Plonk电路。因此，它们支持的电路类型无法比较。但两者都支持扇入二的加法和乘法门电路，当应用于此类电路时，实际上比Plonk更快。

具体来说，Plonk要求验证者进行11次多标量乘法运算（MSM），每次运算的长度等于电路中的门数，即乘法门和加法门。

而只需要在G1组和G2组（其中G1和G2是带有配对的组）分别进行3次和1次MSM。此外，对于，每个MSM的大小仅等于乘法门的数量（在中，加法门是 "免费 "的）。G2上的MSM比G1上的MSM慢2-3倍，因此G1上有5-6个MSM，每个MSM的大小等于乘法门的数量。根据加法门的数量，这可能比普朗克证明者的工作快很多倍。

许多人认为Plonk比更快，因为对于一些重要的应用，Plonk电路可能比捕获相同应用的R1CS实例小得多（例如和散列）。但是，要利用这一点，需要有时间和专业知识来编写优化的电路（当然，除非已经有人完成了这项工作）。这项工作通常由手工完成，不过可以想象，未来的编译器可能会自动利用电路的全部表达能力。目前的工作方式既耗时又困难（在指定约束系统时出现的任何错误都会破坏系统的安全性）。

此外，如上文#5所述，很多人没有意识到及其前身可以修改为支持任意的约束，而不仅仅是约束。（的局限性在于无法超越度-2约束，而不是不支持自定义约束。（另一个鲜为人知的事实是，的前身（如）可以处理高阶约束，但它们产生的是两轮私有币论证，因此不允许链上验证）。

底线：Plonk可以产生比Groth16更快的验证器，但并不总是如此。即使能做到这一点，也往往需要开发者投入大量的专业知识和时间。

7. STARK依赖的假设比ECC替代方案更少或更弱

STARK中使用的唯一加密原语是加密哈希函数，基于椭圆曲线密码学（ECC）的SNARK假设离散对数问题在某些椭圆曲线组中很难解决（也可能做出其他假设）。

如果FRI的部署参数被证明能够在随机甲骨文模型中达到目标安全级别，我会同意这一声明的精神，但事实并非如此。今天，基于FRI的SNARK普遍部署在未经证实的猜想下，即已知对FRI的攻击是完全最优的。这样做是为了控制证明规模和验证成本。(有关猜想的详情，请参阅我的上一篇文章；有关猜想对性能的影响，请参阅下面的#9）。

这里，FRI是STARKs底层的流行多项式承诺方案，其证明包括当应用于安全性为λ位的 n 阶多项式时O(λ log(n) 2）的多次哈希求值。更准确地说，FRI是一种测试承诺函数是否为低度函数的方法（请参阅本讲座，这是我较好的阐述尝试），它可以用来给出多项式承诺方案（请参阅上述讲座的幻灯片59-65）。

总之，在保守的安全假设下部署STARK是可能实现的，但现有项目并没有这样做。

8. 假设相同的多项式承诺方案或SNARK的部署具有相似的运行时间

对于多项式承诺方案，参数的选择会对验证器的运行时间和证明规模产生重大影响。这尤其适用于只使用散列的方案（如FRI、、等）。

以上就是a16z关于SNARK的17个误解（假设相同的多项式承诺方案或SNARK的部署具有相似的运行时间）的详细内容，希望大家能够有所收获！更多请关注倾诉星球其它相关文章！