cover_image

Daily Hunting of The SNARK (01/01/23)

Kurt Pan XPTY
2023年01月01日 00:15

@Daniel Lubarov：我认为对 zkVM 性能的关注有点过了。 即使用type-1 zkEVM，与gas费相比，证明成本也可以忽略不计。 让我们考虑一个最坏的情况。 证明成本与gas比最差的 EVM 指令可能就是 EXTCODESIZE了。 仅对 100  gas，它就可以使 type-1 zkEVM 运行大约 200 个 Keccak-f 置换； 借助巧妙的 Keccak 算术化 (https://polygon.technology/blog/zk-white-paper-efficient-zk-proofs-for-keccak) 和我们基于 Plonky2 的证明者，我们可以在每 CPU 秒内证明大约 25 个 Keccak-f 置换。 所以最坏的情况，我们每 CPU 秒将证明大约 12 gas。 各种云证明者将以每 CPU 小时约 1 美分的价格租用计算，最坏情况下的证明者成本约为 2.3e-7 美元/gas。 在撰写本文时，Eth 的 gas 价格约为 20 gwei，而 ETH 约为 1200 美元，因此用户支付的费用约为 2.4e-5 美元/gas。 那是两个数量级的差距！ 因此，如果我们增加每单位 gas 的固定费用来资助证明，它将使净费用增加约 1%。 这还只是一个起点。 证明效率也会影响延迟，但这可以通过并行化来缓解。 我们的系统将每笔交易分配给不同的证明者； 原则上我们也可以拆分大笔交易。 所以我不认为证明者效率是避免特定 zkVM 的好理由，例如 type-1 zkEVM。 最好也关注下其他因素，例如复杂性、工具和本机执行速度。

@Ye Zhang:  我不同意对 type-1 zkEVM 的说法。

  1. 如果是 12 gas/second，延迟会很明显。 对于智能合约部署这样的交易，你需要10多个小时来生成证明，它不能像你描述的那样并行化，因为它是一个单一的交易。
  2. 对于任何交易都需要考虑最坏情况。 例如如果你把每个交易的gas上限设为 1M，则 keccak 电路的容量应假设在最坏的情况下这1M gas全部用于 keccak。 无论真正需要多少 keccak，你都要支付证明开销。
  3. 整个 zkEVM 的 CPU 开销远大于每小时 1 美分，因为 zkEVM 作为一个整体在实践中是非常大的， 它需要具有大内存和多核的 CPU。 除非我看错了，但我记得Hermez的数据点也是每小时几美元？ 我同意像我们@Scroll_ZKP和@0xPolygonZK这样的 EVM 等价 zkEVM 的证明成本相当小（还可通过 GPU/ASICs 等硬件改进），但是 type-1 有点太多了，1 层还需要做一些改变才能真正到达那里……

@Daniel Lubarov：我们还没有做到这一点，但我认为我们可以像 Risc0 那样将一个交易拆分成一系列证明。或者作为一种短平快的解决方案，我们可以使用具有多个内核的证明者。 目前，我们的证明者在 40 个核心左右遇到了一些扩展问题，但通过一些工作，我认为它可以很好地扩展到 100+。

@Ye Zhang：是的，这将是非常理想的……非常细粒度的并行化。 但是在不同的分散子块之间共享内存似乎代价高昂。

@StarkCon： 我们今天学习递归Starks！ 要完全理解递归 Starks，我们需要了解非递归证明是如何工作的。 Cairo 代表 CPU代数中间表示AIR且包括一个单一的 AIR 来验证这个“CPU”的指令集。 它为更复杂的业务逻辑、对任意计算的语句，以更快、更安全的方式进行证明编写打开了大门。 而一个Cairo 程序也可以是多个SHARP应用程序的串联。 SHARP——一个共享的证明者——从几个独立的应用中获取交易，并在一个单一的 STARK 证明中证明它们。 应用将他们的交易批次结合起来，更快地填满 STARK 证明的容量。 交易以改进的速度和延迟进行处理。

下一个前沿是递归证明，它不仅适用于一些硬编码逻辑，还适用于一般计算。 现在让我们看 STARKS 的递归证明。

Cairo 允许表达一般的计算语句，这些语句可以被 STARK 证明证明并被相应的 STARK 验证者验证。 这就是可以执行递归的地方所在：就像我们编写一个 Cairo 程序来证明数千笔交易的正确性一样，我们也可以编写一个 Cairo 程序来验证多个 STARK 证明。 我们可以生成单个证明来证明多个“上游”证明的有效性。 这就是我们所说的递归证明。

递归证明的一些重要好处：

  1. 降低链上成本
  2. 减少延迟
  3. 促进 L3
  4. 降低链上验证者复杂性
  5. 减少计算足迹

要了解更多信息，请在此处阅读完整的博客：https://medium.com/starkware/recursive-starks-78f8dd401025

@Mikerah： 有没有任何关于如何生成 BLS12-381 和 BN254 的提示？老实说，非常好奇如何通过算法找到配对友好曲线

@Sean Bowe： 作为 BLS12-381 的设计者，我可以告诉你我就是搞定以后请一些著名的密码学家对我进行了复查。 他们好像就说“是的，那很好”，于是现在它就成为了无数区块链的中心了，哈哈 （但要确保这一切都是确定性的）

@Mikerah：但是你是怎么搞定它的？你使用什么技术/启发式方法来得出参数？

@Pratyush Mishra ： 在 for 循环中尝试不同的 x 参数

但是你仍然需要做很多工作来确定它是否真的配对友好，对吧？

不，基本上你尝试各种 x 参数，将它们插入指定基域和标量域的多项式中，如果结果满足你的标准（例如，是质数，具有高 2-adicity），那么你就有一个有效的候选。 参见例如 https://eprint.iacr.org/2012/072

有趣。那么一旦你有了一组有效的候选，你如何从那里过滤？ 是否只是实施它们并查看它们对关键操作的效率如何？

你通常可以静态地知道这一点。 例如，如果曲线方程中的 b 系数为 1，或者扩域是从好的二次非剩余定义的。

@levochka.eth ： 它们都是使用 CM 方法构造的。 我建议先研究 BN 曲线，他们在论文中有一个非常清晰的阐述：https://eprint.iacr.org/2005/133.pdf

@Ben Edgington：我在这里收集了一些关于 BLS12-381 设计的信息，https://hackmd.io/@benjaminion/bls12-381