era boojum下载 -era era boojum源码下载

era boojum

其他源码

下载

警告

该箱子已存档。开发已转移到 zksync-crypto 存储库。请改用它。

布琼姆

zkSync Era 是第 2 层汇总，它使用零知识证明来扩展以太坊，而不会影响安全性或去中心化。由于它与 EVM 兼容（Solidity/Vyper），因此 99% 的以太坊项目可以重新部署，而无需重构或重新审核一行代码。 zkSync Era 还使用基于 LLVM 的编译器，最终让开发人员可以用 C++、Rust 和其他流行语言编写智能合约。

关于

该库的目的是使用非常具体的算术运算以及有关字段大小的附加假设。粗略地说，我们期望有一个带有 |F| 的字段F ~ 64 位（机器字的大小）（关于字段大小的假设对于算术和门布局策略并不重要，但在依赖于特定字段大小的特定函数的小工具实现中断言）。

该系统具有逻辑功能（小工具）的层次结构 - 门（可以将自身记录到跟踪中的实体） - 和求值器（多项式之间的关系）。评估器以特征的形式编写，允许我们稍后自动编写函数来检查可满足性和计算证明，以及合成普通验证器和递归验证器。门附加了额外的工具，允许门本身跟踪它们应该放置在迹线中的位置的逻辑。请注意，我们依靠 Plonk 的复制约束并处理“变量”的可复制逻辑实体来组成最终的可证明语句。该系统不适用于 AIR 算术，并且不允许表达跨越跟踪的多行的约束。

一般来说，痕迹包含很少种类的柱。主要区别在于：

通用列 - 可以允许不同类型的门使用某些变量列（可复制）、见证列（不可复制，有时也称为“建议”列）和常量，从而需要将选择器放在前面商多项式中的相应项。对于这些通用列，放置逻辑很简单：我们尝试根据系统中相应类型的指定列数，在门/求值器允许的范围内放入尽可能多的相同关系的重复项。稍后，当选择器具体化时，可以添加一些额外的常量列。一般来说，门的默认行为是尝试“摊销”常量，从某种意义上说，在同一行上，我们尝试放置使用相同常量的门。这是一种合理的方法，因为实际上大多数电路都是“循环”，因此我们可以“填充”该行。
“专用”列 - 人们可以为特定的门/评估器指定一组单独的列，因此评估器强制执行的关系必须适用于这些列中的每一行。这在某些经常使用特定门的电路中可能是有益的。在多个集合被用于相同关系的情况下，人们可以指定这些列的几种不同的利用模式，即在集合之间是否共享常量。

此外，跟踪允许您添加查找参数，该参数还可以使用专用列来容纳查找表的条目，或者仅使用通用列。目前，表仅被编码为一组多项式，因此跟踪的总长度必须大于表中的条目总数。

请注意，每个“门”（作为 Rust 类型）都是唯一的，因此门只能放置在专用列或通用列中，但不能同时放置在两者中。如果需要这样的功能，那么可以制作一个新类型包装器。

更高级别的逻辑函数（如布尔分解、范围检查、零检查等）用于使电路以不同的方式在内部记录自己，具体取决于 CS 的特定实例中是否允许某些门。从 Rust 的角度来看，具有不同门集的 CS 实例被认为是不同的类型，我们依靠一些内联/常量 prop/编译器工作来减少静态跳转的分支。

施工分部注意事项

仅实现了 2^64 - 2^32 + 1 字段。非向量化数学实现基于为 Plonky2 开发的实现，但针对 const 特征重新制定
自动矢量化主要用于加法，其好处是显而易见的
Poseidon MDS和轮常量等于Plonky2，为用户提供一定的兼容性
Poseidon2 轮常量重用了 Poseidon 常量
算术约束仅影响一行。放置策略是通过按行或按列平铺来尽可能摊销常数
复制排列参数取自 Plonk（基于大乘积的参数）。稍后可能会更改为对数导数（加法导数）
查找参数是对数导数（加法）
目前电路中的查找表必须具有相同的宽度
目前还没有任何列可以与预言分离并输入到另一个证明中
目前，向扩展字段的移动仅在 FRI 聚合上完成（因此在之前的阶段挑战是|F| ，因此我们必须重复参数），但这将被更改，以便我们移动到扩展字段，如下所示提交给见证人后尽可能快地避免分母为零的相当“大”的机会。证明中计算费用的影响可以忽略不计
零知识尚未实现，但已计划（门本身将决定如何在尚未使用的行中放置令人满意的但随机的见证人）
FFT 未优化
哈希值有所优化
实现的门是固执己见的，以及算术化

关于查找参数的注意事项

我们使用通过关系sum_i selector(x_i) / (witness(x_i) + beta) == sum_i multiplicity(x_i) / (table(x_i) + beta)执行的查找参数，其中对专用列selector(x_i)的查找selector(x_i)只是一个身份。我们也不将表编码为较小次数的多项式以消除额外的次数边界检查，而是用零填充它们。请注意，表条目永远不会包含(0,0,...,0)元素，因为在多个表的情况下（即使只使用一个表），我们对表类型使用单独的 ID 列，并且使用 ID就像这样从1开始。

像这样的查找参数的一个很好的功能是，由于其附加性质，如果我们在同一个表中查找多个witness多项式，而不是对每个多项式（元组）重复该参数（这将需要一个单独的多重性列，以及稍后的一些中间多项式），我们可以“添加”多重性并将参数转换为类似sum_i selector_0(x_i) / (witness_0(x_i) + beta) + sum_i selector_1(x_i) / (witness_1(x_i) + beta) == sum_i total_multiplicity(x_i) / (table(x_i) + beta) ，这样查找的总成本只是 1 个多重性列和 2 个（与见证相关的）+ 1 个（与表相关的）中间多项式来编码 lhs和rhs关系在统一的根源上。

这个论点的正确性是显而易见的。为了合理性，我们使用“快速查找的缓存商”论文引理 2.4 中的原始参数。我们需要证明，提交total_multiplicity就足够了，而不是分别提交witness_0和witness_1的多重性。

假设方程sum_i selector_0(x_i) / (witness_0(x_i) + X) + sum_i selector_1(x_i) / (witness_1(x_i) + X) == sum_i total_multiplicity(x_i) / (table(x_i) + X)成立。我们需要证明witness_0和witness_1包含在表t中。令f = (witness_0 | witness_1) ，值的串联。上面的等式意味着sum_i selector_i / (f_i + X) == sum_i total_multiplicity_i / (t_i + X) （注意 LHS 上i的区间长度是上面的两倍）。根据引理 2.4，我们得到f subset t ：“子集”，即向量f的每个坐标都是t的坐标。特别是， witness_0, witness_1 subset f subset t 。

请注意，该论点也适用于多个witness_i 。对于所选的beta ，其余的稳健性论证直接遵循上述工作。

计划扩建

仅适用于基准测试中的小数

有 8kB SHA256 的基准，使用我们认为是 SHA256 电路的门 + 表的最佳配置。请注意，尽管证明器速度有点快，但我们没有正确优化 FFT，并且仍然使用 Poseidon（而不是 Poseidon2）进行我们希望将证明用于递归的配置。两个脚本sha256_bench_recursive.sh和sha256_bench_non_recursive.sh允许您运行相应的测试（是否预计将在递归中使用证明），并且您应该查找一行Proving is done, taken ...以查看证明时间，因为在它之后运行的验证程序非常冗长。这些基准测试使用 LDE 因子 8，尽管我们所有的约束都是 4 级或更小 - 然而，它是一些其他公共基准测试中使用的参数。我们也不在这些证明中使用 PoW，因为 20 位的 PoW 可以忽略不计（30 毫秒），而且我们还不支持代数哈希上的 PoW（然而，这些仅慢约 2 倍，所以也可以忽略不计）。安全级别大约为100位，但可以通过增加查询数量来提高 FRI 健全性，并且查询数量的增加不会增加证明时间（不要与更改 FRI 速率相混淆）。跟踪长度为2^16 ，它使用 60 个通用列和 8 个宽度为 4 的查找参数。

注意：基准测试只是尝试编译为本机架构，目前通常仅对 AArch64（读取 Apple M1）架构进行端到端测试。 x86-64 算术实现进行了有效性测试，但未进行端到端的完整证明。请注意，除了cpu = native之外，最大性能 x86-64 还需要额外的编译器功能标志（即使在本机 CPU 上，Rust 编译器也不使用 AVX512 集）