作者：Justin Thaler. 编译：Cointime.com QDD

SNARK是一种重要的加密工具，它为系统设计开辟了令人兴奋的新可能性，尤其是在去中心化环境中，SNARK可以帮助互不信任的各方进行合作和交易。在这篇文章中，我将谈谈随着该技术在过去几年中的快速发展，我所接触到的一些误解。首先，我要解释什么是SNARK，以及它们在加密货币及其他领域的重要性。

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

如果SNARK满足零知识属性，那么它也可以用于隐私保护；例如，让某人证明自己将钱存入了混合池（因此有权从池中取款），而不透露哪笔存款交易是自己的。实体还可以出于合规目的有选择地披露其他信息，例如他们是否在白名单上或不在黑名单上，或者他们是否向指定地址转移了适当的税款，而不会泄露其他敏感信息（例如税款计算的具体细节）。SNARK在区块链之外也有许多潜在的应用，可以在信任不存在的情况下促进信任。

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

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

术语混淆

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

STARK在科学文献中被介绍为具有精确的技术含义。STARK是Scalable Transparent ARgument of Knowledge的缩写。(许多人很合理地认为S的意思是 "简洁"，正如SNARK中的意思一样；见本文第3.3节）。但在这，"可扩展 "是指证明者的时间与验证程序的运行时间成类线性关系（即线性到对数因子），验证成本（时间和证明大小）与运行时间成多项式关系。"透明 "是指证明系统不需要可信设置。根据这一技术定义，目前存在许多STARK。

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

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

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

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

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

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

我的建议是：我们不需要为协议可能满足的每一个属性集合使用不同的缩写，尤其是如果这会导致对核心问题（如适当的安全级别）的混淆。术语 "透明SNARK "非常清楚，应该用来指任何透明的SNARK。如果部署了交互式模拟，则可以简单地将其称为透明交互式论证。(在这篇文章中，我使用 "STARK "一词来指StarkWare及其衍生的证明系统，因为这里描述的一些误解特别适用于这些证明系统）。

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。

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

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

事实上，Spartan和Marlin支持R1CS、Plonkish和AIR的简洁概括，称为可定制约束系统（CCS）（见下图1）。它们还具有性能优势。例如，Plonk要求验证者承诺电路中每条 "线 "的值，并使用所谓的复制约束来确保分配给从单个门出来的每条 "线 "的值是相等的。这些承诺成本通常是验证器的瓶颈。因此，使用Plonk及其变体的工程师在开发 "相对引用 "等概念方面投入了大量精力，目的是最大限度地减少Plonk电路中的复制约束。

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

尽管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。Groth16以R1CS为目标，但无法支持Plonk电路。因此，它们支持的电路类型无法比较。但两者都支持扇入二的加法和乘法门电路，当应用于此类电路时，Groth16实际上比Plonk更快。

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

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

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

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

底线：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、Ligero、Brakedown等）。

在已部署的该类SNARK中，字段大小和所谓的爆炸因子B（控制证明者时间和证明大小之间的权衡）都存在重大差异。证明者时间与B呈线性关系，而证明规模与1/log(B)呈线性关系。例如，放大系数为16的证明比放大系数为2的证明小4倍，但证明器的速度却慢8倍。

一些项目将基于FRI的SNARK与基于椭圆曲线的SNARK组成，在链上发布之前缩小FRI证明的大小。由于FRI证明不直接发布在链上，这些项目可以将FRI证明器配置得更快，证明更大。其他项目则直接在链上发布FRI证明，因此配置证明器的速度会大大降低。

具体来说，如果在251位字段上运行放大系数为16的FRI，与使用放大系数为4和（64位字段的扩展）64位字段相比，对于给定的多项式度约束，证明器可能会慢10倍以上。在这个比较中，4因子直接来自于4倍的放大因子，其余的来自于更大的字段（因为更大的字段使得FFT和Merkle-hashing慢4倍以上）。

9. 将FRI和STARK证明描述为几十KB的长度

这是FRI和STARK证明长度的标准特征。但是，FRI证明实际上是数百KB的长度，安全性在100比特以上，即使在上文#7讨论的猜想中，已知攻击是完全最优的。

例如，在 FRI 放大系数为 4 的情况下，将 FRI 最直接的实现应用于安全度为 128 位的 220 度多项式（即使在激进的健全性猜想下），会导致证明的大小接近 500 KiB。这可以通过某些优化来降低，例如 "磨削"、"梅克尔封顶"和"提前停止"（在下面#16中讨论）。但是，这些技术无法将证明大小减小到200KB以下。

"几十KB "的描述似乎是指我在上一篇博文中讨论的FRI配置。该配置的目标是在激进猜想下实现80比特的安全性，其中32比特来自打磨技术，只有48比特来自FRI本身。此外，这个配置使用了16的大爆炸因子，导致验证器速度很慢。该博文中讨论的SHARP校验器后来被改成了安全性更高的配置，但StarkEx dYdX校验器目前仍采用博文中讨论的配置。

将80比特增加到128比特，证明大小增加一倍。将炸毁因子从16减少到4，以获得更合理的验证时间，使证明大小再次翻倍。去掉上面#7中讨论的激进安全猜想，证明规模再次增加一倍（至少）。将磨削所贡献的安全位数从32位降低到16位（因为使用磨削来获得32位安全位数迫使诚实的证明者执行232次哈希运算），证明规模又增加了33%。

这些增加是几十KB和几百KB之间的差别。

研究人员和SNARK设计师的误解

10. 混淆分组指数化和分组乘法

相关背景：在乘法群中，群运算将两个群元素g1、g2作为输入，并输出它们的（群）乘积g1 * g2。群幂运算是指将某个群元素g提升到某个幂x。也就是说，幂运算计算的是输入g和指数x的值gx。

一般来说，指数x可以是介于1和组的大小|G|之间的任何数字。通过标准平方乘法算法计算幂级数所需的分组运算（即乘法）总数约为3/2 log |G|。加密分组的大小至少约为2256。 因此，组幂运算的速度大约是组运算速度的400倍。

然而，许多关于SNARK的论文都将群幂级数称为群运算。如果我们不区分证明器运行时间的400倍因子，我们作为一个社区就无法清楚地了解SNARK的性能。

建议：我不确定这里的根本问题是粗心的核算，还是没有意识到这些运算具有本质上不同的代价（无论是渐进上还是具体上）。不过我更倾向于后者——很难想象协议设计者会故意掩盖如此大的成本差异。

作为一个社区，我们必须提高对这些操作的实际成本的认识，并鼓励在论文和演讲中进行更精确的成本核算。加强对实施的重视和更仔细的基准测试也会有所帮助。

11. 混淆多幂级数与多幂级数（又称MSM）

相关背景：大小为n的多幂运算计算的表达式为：

也就是说，多幂运算输出n个幂运算结果的乘积。根据加法群符号，这通常也被称为MSM（多标量乘法）。

计算一个多幂运算需要独立地执行n个幂运算（每个幂运算都需要3/2 log |G|组运算），然后将结果相乘。然而，Pippenger的一个著名算法计算多幂运算时的分组运算量比这个天真的算法少了大约log n倍（见本文第4节的精彩阐述）。如果n为几百万或更大，这种 "Pippenger加速"在实践中很容易达到20倍或更多。

许多论文没有区分分组运算和指数运算，也没有区分 n 指数运算和大小为 n 的多指数运算，导致具体的性能代价更加不精确。

建议：与#10一样，补救措施是提高对这些运算实际成本的认识，进行更精确的成本核算，以及加强对实施和基准的关注。

12. 将安全参数λ视为常数

如果攻击者必须执行约2λ的工作才能找到一个概率接近1的虚假声明的令人信服的证明，则SNARK具有λ比特的安全性。

从渐进的角度看，安全参数必须是输入大小的超对数，才能保证对超多项式时间对手的安全性。也就是说，λ应被视为大于任何对数因子。

具体来说，λ应为128及以上。对于实际输入大小n，这比log(n)大3到6倍。在实践中，将λ看作4*log(n)是可以接受的，但不要忘记4因子。

用λ因子代替SNARK中的log(n)因子会使SNARK更昂贵，而不是更便宜，无论是具体还是渐近。

13. 相信Fiat-Shamir变换通常不会导致重大的安全性损失，除非应用于 "基本协议"的顺序重复

误解：下面涉及顺序重复的示例表明，将Fiat-Shamir应用于r轮交互协议会导致安全比特数以r为系数的损失。社区中的许多人认为，顺序重复是产生交互式协议的主要自然技术，会导致这种损失。事实上，还有其他技术。

背景和示例：将一个健全性误差为1/2（即 "1比特的交互安全性"）的一轮交互协议连续重复λ次，可以得到一个健全性误差为2-λ（即 "λ比特的交互安全性"）的λ轮交互协议。将Fiat-Shamir变换应用于这个λ轮协议可能会导致一个完全不安全的结果：所谓的研磨攻击只需要大约λ次哈希评估就可以找到任何虚假语句的令人信服的证明（即Fiat-Shamir-ed协议只有log(λ)比特的安全性）。

在对Fiat-Shamir-ed协议的攻击中，作弊验证者对每一轮进行单独攻击。首先，它在第一轮重复中仔细检查验证者的信息，直到找到一个 "幸运 "验证者响应的哈希值。从期望值来看，这只需要尝试2个验证者信息（因为健全性误差1/2意味着任何特定的验证者信息产生幸运验证者响应的概率为1/2，所以在尝试2个信息之后，验证者期望找到一个幸运的信息）。

一旦找到这样的验证者报文m1，就完成了第一次重复的攻击。它将第一轮的报文固定为m1，然后在第二轮重复中继续筛选验证报文，直到找到一个幸运的验证响应。同样，预计这只需要2个哈希值——以此类推，直到所有重复都被成功攻击。

实际情况 并行重复与Fiat-Shamir相结合也会导致严重的安全性损失。（该攻击由Attema、Fehr和Klooß首次提出）。

举例来说，假设一个两轮基本协议的交互安全性为64比特，并行重复两次，得到一个交互安全性为128比特的两轮协议。验证者要想在两次重复中都说服验证者接受协议，就必须在两次重复中都走运，发生这种情况的概率为2-64*2-64=2-128。如果您应用Fiat-Shamir使协议变得非交互式，那么它最多只有64比特的安全性，与您根本没有重复基础协议的情况基本相同。

对经过Fiat-Shamir处理的协议的攻击又是一次重复一次。攻击者不断地重复第一条信息m1，直到在两次重复中的一次获得幸运的验证挑战。（我们所说的 "幸运"是指攻击者可以轻松地通过验证者在基础协议的特定重复中的所有检查）。预计攻击者最多需要进行264次散列评估才能找到这样的信息m1。确定了m1之后，攻击者就会对信息m2进行反复验证，直到在另一个基础协议的第二轮验证中幸运地得到验证者的挑战。同样，在找到幸运信息之前，只需要进行大约264次散列评估。此时，基本协议的两次重复都已被攻击者破坏。

建议：其结果是，如果希望将Fiat-Shamir变换应用于多轮的交互协议，那么为了排除重大的安全性损失，确实应该证明交互协议满足加强版的健全性，即逐轮健全性。逐轮健全的交互协议，即使它们有很多轮——在随机甲骨文模型中应用Fiat-Shamir变换时也不会遭受安全损失。其中一个例子就是和校验协议（参见本文第2.1节）。IPA/Bulletproofs是另一个已知在Fiat-Shamir变换时在随机甲骨文模型中安全的多轮协议。

令人惊讶的是，FRI是一个对数轮协议，直到现在还没有被证明是逐轮健全的--尽管据我所知，它的所有部署都应用了Fiat-Shamir来使其非交互，尽管多篇研究论文都指出了FRI逐轮健全性的安全保证。因此，与之前的许多断言相反，基于FRI的SNARK在随机甲骨文模型中并不安全。幸运的是，新的工作解决了现有安全分析中的这一缺陷。但这并不能解决这些部署所基于的有关FRI健全性的其他猜想（见上文#7）。

额外奖励：需要避免的相关安全陷阱。当我们在讨论应用Fiat-Shamir变换的危险时，请记住对任何可能受对手控制的待证明语句的输入（或参数）进行散列。

如果不这样做，攻击者就可以生成一个SNARK证明，它可以通过验证者的所有检查，只有一项除外，然后很容易找到一个输入，使最后一项检查也能通过。多年来，这一漏洞在使用Fiat-Shamir转换的协议部署中反复出现。这个问题非常普遍，因此我们有专门的术语来称呼它，即"弱Fiat-Shamir"。

利用弱Fiat-Shamir漏洞，攻击者可以找到虚假声明和令人信服的证明，但无法完全控制所找到的虚假声明。也就是说，攻击者不能随意选择一个虚假陈述，然后为其找到一个令人信服的证明π。相反，对手首先产生π，然后逆向设计出一个虚假语句，而π就是一个令人信服的证明。尽管如此，该漏洞的影响可能是毁灭性的，正如上文所链接的作品所探讨的那样。

14. SNARKs性能更佳的关键是在更小的字段上工作

很多优秀的工作致力于设计在小字段上工作的SNARK，特别是比椭圆曲线组使用的字段更小的字段，椭圆曲线组通常使用2256或更大的字段。其动机在于，在小字段（例如，大小为264 - 232 + 1的字）中进行字段运算比在大字段中进行相同的字段运算要快得多。此外，某些硬件（如GPU）原生支持32位数据类型，这使得对极小字段的操作尤其快速。

我所看到的关于这个问题的公开讨论忽略了一个重要的细微差别：使用小字段（即使它们是一个选项）是否有意义在很大程度上取决于应用。例如，卷积服务器的主要任务之一是证明ECDSA数字签名的知识。这些都是在大字段上的声明。在证明ECDSA签名知识时，在小字段上的操作实际上增加了证明时间。数字签名验证所需的每个大字段操作都必须通过SNARK工作的小字段上的许多操作来模拟。

对于以前的zkEVM卷积，证明数字签名知识是验证器的瓶颈。例如，这可能就是为什么Starkware在251比特的字段上工作，与某些ECDSA签名相匹配，而不是更小的字段。(EVM涉及足够复杂的逻辑，如Merkle-Patricia trie更新，因此证明签名知识可能不是zkEVM的瓶颈）。

再比如，EVM使用256位字作为字大小。如果在小于2256的字段上工作，就必须分配多个字段元素来表示单个uint256数据类型。当使用的字段大小小于2的幂次（如Goldilocks字段）时，这种情况尤其令人头疼。例如，一个251位的字段对于表示uint256数据类型来说 "太小了一点"。这将使支持这些数据类型所需的验证器成本增加大约一倍。

我的想法：大字段也是一种潜在的资源，可以通过单个大字段操作来模拟许多小字段操作。我希望在不久的将来看到这方面的更多进展。与此同时，能够选择在小油田作业是件好事，但这并不是在所有情况下提高SNARK速度的关键。

15. 内积参数需要线性验证时间

内积论证是对多项式承诺的一种概括：它允许不受信任的验证者揭示一个承诺向量与验证者指定的任何其他向量的内积。目前最著名的内积论证是IPA/Bulletproofs，它有一个线性时间验证器。许多项目优先考虑亚线性验证，因此忽略了内积参数。突出的例外包括ZCash Orchard协议和Monero，因为IPA/Bulletproofs的验证时间对于这些应用来说已经足够快了。

虽然IPA/Bulletproofs拥有线性时间验证器，但这并不是故事的结束。例如，Dory是一种透明的同态内积论证，其验证时间和证明大小均为对数（尽管证明大小比IPA/Bulletproofs具体大一个数量级）。此外，IPA/Bulletproofs与所有同态承诺一样，具有吸引人的批处理特性，在可能进行摊销的情况下，它的验证器时间是亚线性的。

还有一些透明的多项式承诺直接受内积论证工作的启发，具有极好的成本曲线。Hyrax就是一个例子，它有一个非常快的证明器，但由于它的证明量很大（承诺多项式大小的平方根），所以现在并不流行。然而，通过SNARK组合可以减小证明规模。

16. FRI的证明比其他具有相同安全特性的协议的证明要小

实际情况：这取决于提交的多项式的度数。对于度数不超过218的多项式，FRI证明实际上比称为Ligero的替代方案要大。这一点在Ligero的安全性没有建立在任何未经证实的统计安全性猜想的基础上，而在FRI的安全性建立在这些猜想的基础上时是成立的（见上文#7）。

诚然，Degree-218比目前大多数项目所使用的都要低。但一些项目计划在未来使用这个度数的多项式，以控制FRI证明器的大量内存成本（很多GB）。

如果我们不把 FRI 的安全性建立在上面 #7 中提到的猜想的基础上，那么直到度数大于大约 220 时，Ligero 证明仍然比 FRI 证明小。（更详细的比较可以在这里找到）。

结果是，不同证明系统的渐进比较并不一定与其具体成本相匹配，直到实例大小大于实际中出现的实例大小。对小于220度的多项式应用FRI的项目应该考虑转换到Ligero，以提高性能和避免强安全性猜想。

17. SNARKs如今的表现力足够强，他们现在应该僵化了

不，他们不是。

Justin Thaler是a16z的研究合伙人，同时也是乔治城大学计算机科学系的副教授。他的研究兴趣包括可验证计算、复杂性理论和海量数据集算法。

本文所表达的观点仅代表所引用的AH Capital Management, L.L.C. ("a16z")个人观点，并不一定代表a16z或其关联公司的观点。a16z是一家在美国证券交易委员会注册的投资顾问公司。注册为投资顾问并不意味着拥有任何特殊技能或培训。此处包含的某些信息来自第三方来源，包括a16z管理的基金的投资组合公司。尽管a16z认为这些信息来源可靠，但并没有独立核实这些信息，也不对这些信息的持久准确性或其在特定情况下的适当性做出任何陈述。此外，这些内容可能包括第三方信息；a16z没有审查这些材料，也不认可其中包含的任何广告内容。

内容仅供参考，不应作为法律、商业、投资或税务建议。您应就这些问题咨询您自己的顾问。对任何证券、数字资产、投资策略或技术的提及仅用于说明目的，并不构成投资建议或提供投资咨询服务的要约。此外，本内容不针对任何投资者或潜在投资者，也不打算供任何投资者或潜在投资者使用，在任何情况下，在决定投资于a16z管理的任何基金时，不得依赖本内容。(投资A16Z基金的要约仅由私募备忘录、认购协议和任何此类基金的其他相关文件做出，应完整阅读)。所提及、提及或描述的任何投资或投资组合公司并不代表a16z管理的所有投资工具，也不能保证投资或投资策略将有利可图，或未来进行的其他投资将具有类似的特征或结果。由Andreessen Horowitz管理的基金所进行的投资清单（不包括发行人未允许a16z公开披露的投资以及未公开交易的数字资产投资）可在https://a16z.com/investments/。

此外，本资料仅供参考，在做出任何投资决策时不应依赖本资料，过去的表现并不代表未来的结果。投资于集合投资工具和/或数字资产包含许多本文未充分讨论的风险，包括但不限于重大波动性、流动性、技术和监管风险。内容仅截至所示日期。这些材料中表达的任何预测、估计、预报、目标、前景和/或意见可能会在未通知的情况下发生变化，并可能与其他人表达的意见不同或相反。更多重要信息请参见https://a16z.com/disclosures/。