使用 zkScanner 保障电路的安全性 Part I：介绍

ScaleBit

2024-01-26 22:13

来源链接

订阅此专栏

收藏此文章

本篇技术研报由 ScaleBit 研究团队的 Zorrot 撰写，并特别感谢 Venus 和 David 的修订意见

TL;DR

最近，由 BitsLab 旗下子品牌 ScaleBit 主办的 zkCTF 开放报名正在火热进行中。长期以来，ScaleBit 致力于保障 ZK 技术和应用的安全发展。为了应对 ZK 和 Web3 生态的动态发展，一种全新的用于检测 ZKP 内部漏洞的工具 —— zkScanner 开发上线。

在接下来的两篇文章中，ScaleBit 将全面深入地探讨 zkScanner。了解更多详细信息，请访问 ScaleBit 官网。

https://scalebit.xyz/

零知识证明（ZKP，Zero Knowledge Proof）的当前发展令人兴奋。简单来说，ZKP 是一种强大的隐私范式，能够在不必出示隐私信息的前提下，证明您拥有这些信息。可能听起来有些抽象，让我们来举一个例子：您可以在不向服务器暴露密码的情况下证明您的身份！这种应用已经能够通过 ZKP 工具和框架实现了。

实际上，在过去的许多年里，与零知识证明（ZKP）相关的知识主要停留在理论层面。然而，自 2016 年起，实际的 ZKP 框架已经开始崭露头角。随着 Layer 2 解决方案的发展，ZKP 框架在 2019 年后出现了显著爆发。今天，我们正在见证着 ZKP 的第一次小规模繁荣，无数基于 ZK 的方案和应用已逐渐成为市场中特定问题和场景下的明星解决方案。从小规模的应用来看，如混币器和基于 ZK 的扑克游戏与拼字游戏；再到区块链中更为重要的基础设施，如 zkEVM 和 zkRollup，可以说即使您或许对 ZKP 不太熟悉，但 ZK 已经在塑造大家对 Web3 的全新理解。而且，它对去中心化世界未来方向将会产生深远影响。

ScaleBit 与 ZKP 开发者、学者和用户一样，非常重视 ZK 的市场机遇。自去年以来，我们一直在致力于了解 ZKP，并为社区做出了诸多实质性贡献。在讨论我们取得的小小成就之前，我们首先想分享一下当前对 ZKP 的观察，并在近年来涌现的无数 ZKP 产品中找到共同之处。

From ZKP to Circuit

从 ZKP 到电路

事实上，从概念上来看，大多数现有的 ZKP 框架基于三种范式：Groth16、Sonic 和 zk-STARK。

其中，Groth16 和 zk-STARK 家族的成员稍微少一些，但它们具有独特的优势：Groth16 证明简单且快捷，相比其他方法，证明速度和大小都有优势。然而，Groth16 却需要特殊的电路特定设置。至于 zk-STARK，它克服了 Groth16 的许多缺点，一方面在于它不需要可信的设置，另一方面对量子攻击具备抵抗性。不过，与 Groth16 相比，zk-STARK 的证明在计算上更加昂贵。

通过对比 Groth16 和 zk-STARK，Sonic 的实现多种多样，一些非常著名的框架，如 Halo、Marlin 和 Plonk 都是基于 Sonic 诞生的。Sonic 可以看作是介于两者之间的一种范式：它只需要一次可信的设置，适用于所有电路，但证明开销也不小。

显然，这些五花八门的方案各有优劣，那应该怎样选择呢？对于我们来说，每一种方案都有可取之处，而且能用于不同的场景中，因此最好的情况就是：全部都要。为了解决这一困境，各种 ZKP 的前端应运而生，例如基于 Groth16 的 Circom，基于 Plonk 的 Halo2，基于 zk-STARK 的 Cairo 等等。尽管存在各种工具和语言，但这些前端事实上有一个共同的称呼，它们被称为算术电路。从简单的视角出发，电路仅就是由许多断言式组成的一个集合。显然，电路使得 ZKP 应用变的相对来说容易了一些，至少避免了开发者接触复杂的密码学原语，这是很多开发者所希望的。因此，这些前端在各个领域都开始流行了起来。开发者完全可以选择快速地掌握它们所有的范式。

So .. What’s the Problem?

那么...问题在哪？

然而，这些前端工具和语言带来了一个明显的问题：它们可能会引入在使用密码学原语时不存在的问题。这里需要解释的一个重要问题是：电路是与传统代码非常不同的程序。传统程序的目标始终是根据某些输入，来计算出对应的结果。但电路通常假定程序已经知道答案，它只是重新验算一遍所有的约束。这自然引发了一个问题：如果电路采用了错误的输入，那么电路肯定就不能通过编译。那么，电路怎么会出错呢？

别着急，事实上电路的确可能出错，而这些错误主要能够分为两类：欠约束（under-constrained）和过约束（over-constrained)。大部分其他的电路问题，实际上最终都会被归于这两个类型之中。简单来说，欠约束的意思是，在某些情况下，您的输入是错误的，但是电路没有看出来，并且让它通过了。而过约束则是指，您的输入是对的，但是电路就是不让它通过。这些问题事实上几乎存在于一切电路当中。

但是为什么这些错误会发生呢？为了解释这点，我们需要回到电路的运作方法。我们给电路一组输入，电路来验证答案是否正确。但是如果我们给的答案太长了呢？显然，开发者不会喜欢每次进行 ZKP 验证都输入上千个参数。因此，电路除了验证每个输入之间的数量关系，还需要帮助开发者计算非常大一部分的输入。显然，正是由于这个计算过程的存在，导致了电路中引入了大量的不确定性。

显然，我们对以上电路中存在的两类问题非常关心，我们将会在未来的章节中，详细讨论这些漏洞的原理，以及如何解决它们。但是在正式解决问题之前，我们还需要挑选一种合适的前端，并基于它开始我们的工作。

Why Circom First?

为什么选择 Circom？

我们对电路中潜在问题非常关注，打算即将采用一种前端方法开始我们的工作。在众多可用的语言中，我们注意到了 Circom 语言。尽管 Circom 相对较新，但它已经支持了 Groth16 和 Plonk 两种方案。同时，Circom 语法更类似于传统编程语言。与其他复杂的前端相比，开发者更容易学习、理解和使用。因此，我们相信检测和验证 Circom 将会更加有意义。让我们稍微介绍一下 Circom，以一段典型的代码为例：

pragma circom 2.1.6;
template Example () {   // declaration   signal input a;   signal input b;   signal c;   signal output d;
// Assignment and Constraint   c <== a * b;   // Assignment   d <-- c + a;   // Constraint   d === c + a;}

首先，让我们关注 Circom 的声明部分，在这里包含了我们打算传达给电路的所有答案。这些答案被称为信号。信号可以通过前缀反映其性质，输入信号表示我们需要传达给电路的参数。电路中的计算可以从输入信号衍生出信号和输出信号。虽然每个信号只能计算和赋值一次，但它可以有多个约束。

正如前文提到的，电路可用于指示信号之间的关系并计算它们的值。关系的确定被称为约束（constraint），计算称为赋值（assignment）。Circom 的约束系统主要使用 "a === b" 来断言 a 和 b 的相等性。其赋值系统使用 "a <-- b" 来表示将 'b' 赋值给 'a'。最后，"a ==> b" 会同时执行约束和赋值。

Circom 以及任何其他电路语言，都有一个至关重要的性质：所有计算都必须在有限域 F 内进行。基本上，这是因为零知识证明方案依赖于椭圆曲线的特定方程，并因此受到它们的循环群的限制。从实际的角度来看，可以理解为 Circom 中的任何操作都需要在最后进行 'modulo p' 操作，以确保值在有限域内。此外，由于椭圆曲线上的操作与常规计算相比具有不同的性质，如 a * a * a 或 a / b；这样的非二次表达式不能在 Circom 中表示为约束（可以在赋值中使用）。

显然，这些特殊的规则与漏洞息息相关。在我们对 Circom 有了基本的了解之后，我们已经准备好深入探讨 ZKP 电路中的漏洞了！在下一篇文章中，我们将介绍 zkScanner 以及它如何发现和探索这两种漏洞。

ScaleBit，BitsLab 旗下子品牌，作为 Web3 领域领先的区块链安全团队，分布于硅谷、新加坡、香港、台湾等地。我们已为全球 Web3 领域 200+ 个机构和项目提供了区块链安全解决方案，累计审计代码 180，000+ 行，累计保护用户资产超过 80 亿 + 美元。Make Security Accessible for All！若您有任何安全审计需要，欢迎随时与我们取得联系，我们将为您定制细致、全面、专业的安全解决方案，护航您和 Web3 领域安全无虞！