Binius：助力ZK行业发展

最新推荐文章于 2024-05-20 14:27:03 发布

mutourend

最新推荐文章于 2024-05-20 14:27:03 发布

阅读量1.1k

点赞数 19

分类专栏：零知识证明文章标签：零知识证明

本文链接：https://blog.csdn.net/mutourend/article/details/135422339

版权

零知识证明专栏收录该内容

329 篇文章 131 订阅

订阅专栏

1. 引言

前序博客：

Binius：基于binary fields的SNARKs（Part 1）

Zero-knowledge and validity proofs，通常简称为ZK，代表了密码学、数学和计算机科学领域的一个迷人领域。ZK允许一方，即Prover，以一种时间和空间有效的方式说服其他方，即Verifier，特定的陈述（如某计算机程序的执行）是正确的。这意味着，与Verifier直接执行计算相比，验证proof的速度要快得多，并且需要更少的信息，且proof可能不会泄露敏感数据。

2. ZK当前进展

为证明任意计算机程序的执行，需将其转换为适合ZK的形式：

该过程被称为算术化
将程序表示为在整数/有限域上定义的一组方程式
这与，在计算机程序中，使用字节和二进制运算来表达和思考的方式，存在差异。

如，某程序有一个布尔变量，须确保该变量只取值0或1。由于使用整数，添加形如 $b (1 - b) = 0$ 这样的条件。问题在于，当该变量用大整数（至少64位长）表示时，由于这样处理有限域（而不是位）上的运算，将显著增加内存使用和计算时长开销。诸如bitwise运算或将某整数做二进制分解之类的运算代价高昂。

与普通编程相比，ZK中的性能涉及不同的权衡，开发人员需要对密码学有更深入的理解，并学会以不同的方式进行编码。开发人员的工具仍在创建中，在某些情况下，它依赖于直接编写算术电路，这很耗时，而且容易出现错误。此外，proving增加了大量的开销，包括所用内存和时长。因此，ZK在开发人员和用户体验方面都带来了困难。这意味着更多的时间和金钱花在培训开发人员上，而现有熟练程序员的可用性较低。

过去几年，ZK行业发展迅猛，提高证明系统的性能，目前有多个研究方向：

使用small field sizes的STARK，如mini-Goldilocks和31-bit Mersenne prime。
Folding schemes，如Nova、Protostar和Protogalaxy等。
Lookup arguments，当前Jolt的目标是将所有内容简化为只在预先计算的有效输入/输出对表上查找任何操作。

每个系统在证明大小、证明时长、验证时长和易于支持的计算类型方面都有优缺点。在硬件方面已经努力加速这些证明系统，但它们都为“用field elements来表示bits”付出了代价。

3. Binius及其所使用的binary fields

在STARK中使用smaller fields减少了表示变量的开销，并缩短了证明时长。问题自然而然地出现了：

我们能做得更好吗？

2023年年底，Ulvetanna团队Benjamin E. Diamond和Jim Posen 发表论文《Succinct Arguments over Towers of Binary Fields》，开源代码见：

https://github.com/recmo/binius（Rust + Sage）【基于plonky3等库】【Binius：针对硬件优化的SNARK】

Binius展示了：

可使用更小的fields。

Binius的主要贡献分为三大块：

1）基于binary fields：其本质是基于各种size的bitstrings。可在没有开销的情况下调整大小以表示变量。
2）基于small fields的承诺方案。该承诺方案基于哈希函数，比基于椭圆曲线的承诺方案更快，且不需要可信设置。这在很大程度上借鉴了Brakedown。
3）基于以上1）和2）构建的SNARK，其基于HyperPlonk思想，但可扩展到其他算术化方案。

Binius整个构建的主要优点在于：

其可更自然地处理位运算（如，两个bitstrings之间的XOR只是binary field上的加法）
消除了与数据类型表示相关的开销。如，布尔变量可仅由一个大小为1位的域元素表示！这减少了整个证明系统的内存占用（尽管我们需要使用larger fields来实现密码学安全）。
运算非常快速且对硬件友好。在做域元素加法的情况下，它只是XOR运算，避免了进位和溢出。
也有基于binary fields的非常有效的算法，如用于产生Reed-Solomon编码的加additive Fast Fourier Transform（FFT）。

Binius的主要缺点在于：

主要缺点与证明大小（它明显大于大多数SNARK和STARK，大约为几MB）和验证时长有关。
- 然而，验证时长与大多数证明系统不相上下，而Prover的速度明显更快。
- 此外，SNARK中较小的证明大小是以可信设置为代价的，这使得整个系统依赖于参数初始化仪式的完整性，通常使用几GB的内存。

4. Binius应用

Binius论文中展示了如何对Keccak和Grøstl哈希函数进行算术化：

这涉及到许多bitwise运算，使得它们很难使用其他证明系统。
并对此进行性能分析，展示了Binius的潜力：
- 更自然地处理bitwise运算的能力，使得能将Keccak和Grøstl哈希函数用于承诺方案中，且易于证明。

也可使用Binius构建一个虚拟机并证明其执行的正确性。这可高效证明通用计算机程序，至少在生成证明所需的时间方面是如此。
可再通过用SNARK/STARK wrapping来解决证明大小的问题，其只需要验证Binius’s proofs，从而实现更轻量级和高效的构造。

减少Prover的内存和证明时长，可实现可证明的全同态加密（FHE），这允许用户在不compromising数据的情况下将昂贵的计算委托给不受信任的服务器。FHE允许用户在不首先解密的情况下对已加密数据进行计算。

5. 结论

LambdaClass团队认为，在扩展可证明计算方面，Binius可以改变游戏规则，其在软件工程和金融等不同领域引发重大变化。
所用内存的减少、运算的硬件友好性，以及虚拟机的开发，将使消费级硬件中的可证明计算成为现实，同时增强开发人员体验，减少所需的资源和培训。离大规模采用ZK技术又近了一步。Lambdaclass对这种新的证明系统及其功能感兴趣，并希望在2024年开始实施和开发。