Highlights

基于对称密钥假设的有上限深度累积方案及其优化

所有以往的累积方案（accumulation schemes）都依赖于同态向量承诺（homomorphic vector commitments），这些承诺的安全性基于公钥假设。本文中提出通过构建一个来自非同态向量承诺的累积方案，该方案仅基于对称密钥假设（例如 Merkle 树）。此方案通过利用对承诺向量的错误纠正（error-correcting）编码进行抽查（spot-checks）来克服对同态的需求。与以往的累积方案不同，此方案仅支持有限数量的累积步骤。但即使深度有上限的累积方案（accumulation schemes），也足以构建携带证明的数据（IVC的泛化）。另外本文还展示了几种对 PCD 构建的优化，显著提高了效率。 本文的主要贡献主要包括： （1）引入了一种新的有上限的深度累积方案（bounded-depth accumulation schemes）概念，支持有限数量的累积。 （2）有上限的深度的携带证明数据（PCD），根据已知结果[BCCT13]，足以获得多项式深度的增量可验证计算（IVC）。 （3）从任意（非同态的）向量承诺方案（例如基于随机预言机的 Merkle 树）和任何线性代码构建了高效的有上限的深度累积方案。这种 PCD 方案需要更少的证明者开销，并实现了可信的后量子安全。 （4）为实例化的 PCD 方案提供了几种优化，包括支持“批量”累积（'batch' accumulation）、从低深度 PCD 到 IVC 的新低开销编译器，以及一种新的混合 PCD 方案，将低深度 PCD 与任何基于 SNARK 的 PCD 方案结合。

a note on the elliptic curve pairing checks in zero knowledge proofs

这篇文章主要探讨了零知识证明中椭圆曲线配对检查的一些重要概念和应用。它着重介绍了在零知识证明系统中使用椭圆曲线配对检查的技术，并深入讨论了其在密码学中的作用和应用。文章通过对配对检查的基本原理、常见应用场景以及一些相关概念的解释，为读者提供了对这一领域的深入理解和探索的入口。

Do You Need a Zero Knowledge Proof?

如果你正在探索零知识证明（ZKPs）的世界，想要了解它们如何在不同情境下发挥作用，我强烈推荐你阅读这篇文章。

它批判性地分析了 ZKPs 的适用性，将它们分为几种类型：SNARKs（简洁的非交互式知识论点）、提交然后证明 ZKPs、MPC in-head 和 Sigma 协议。每种类型都提供了不同的权衡和好处。文章通过一种创新的流程图方法，帮助你确定最适合你需求的ZKP系统，并提出了一套技术应用要求。它深入探讨了外包计算、数字自主身份和网络中的 ZKPs 这三个主要用例，提供了关于 ZKPs 其他应用的高层次概述，并探讨了它们在更广泛领域内的含义和机会。

这篇文章能够帮助你理解选择合适的 ZKP 系统所涉及的决策过程，明确这些加密工具何时以及如何在不同领域中有效使用，以及何时应该避免使用这些工具。对于那些寻求深入了解 ZKPs 潜力和局限的人来说，这篇文章是一份宝贵的资源。

Updates

Aleo IP core.

最近 Ingo 公布了关于 Aleo 的最新产品 - Aleo IP core。 Aleo 首创了 KZG 谜题的概念，其中，作为 Aleo 共识机制的一部分，证明者竞相解决 ZK 币库谜题。最具成本效益的证明者可以获得更多奖励。这种独特的机制是迄今为止唯一能够产生公平竞争环境和对 ZK 证明的足够需求的实例 Aleo IP 是面向运行 Aleo 测试网难题的 ASIC 平台。Aleo IP 采用参数化 RTL 设计，可实现最先进的性能和功效。该设计是使用与运行频率为 1.2 GHz 的 TSMC 7nm 工艺兼容的工具进行综合的，包括单个矿工管理器负责用户界面和整个逻辑的管理与Aleo 核心数量。 链接https://medium.com/@ingonyama/product-announcement-aleo-ip-core-e7181ca31094

bitvm1 与 bitvm2 的比较

bitvm1版本： Verifier 不断要求 Prover 揭示他指定步骤的中间状态，从而在 logN 次挑战之后可以确认 Prover 作恶了没。

  1. 两方参与挑战，链上交互次数为logN次
  2. 链上采用的验证的是 RISC_V 指令集执行的不正确性
  3. 在网络开始之前需要 Prover 和 Verifeir 提前的 presign，网络一经启动就无法再更改

bitvm2版本: Prover直接在链上用一笔交易揭示所有的中间状态之后，如果任何人发现揭示的某一步中间状态执行不正确都可以通过 f(x)!=y 的逻辑来解锁对应的Prover质押金额

  1. 任何人都可以 premissionless 的参与挑战 prover
  2. 链上交互次数大大减少
  3. 不再验证采用 RISC_V 指令集，而是采用在链上写一个原生的 zk verifier
  4. 因为每个 tapleaf 的 script 大小是 400kb(比特币节点限制)，意味着链上每 400kb 的验证 script 就 prover 需要揭示一个中间状态，同时又因为缺少 op_loop 指令，op_mul 指令以及 op_cat，会导致比特币无论是在做 groth16 verifier (椭圆曲线运算贵，并且 field size 是 254bit )或者在做 stark verifier (计算 Merkle Path 的困难)都会出现比较多中间状态的问题，这样 prover 需要花费更多的手续费来证明他是对的。 -link

其他

  1. Constant-Size zk-SNARKs in ROM from Falsifiable Assumptions - Roberto Parisella：https://www.youtube.com/watch?v=VPAA85Mtt2s

  2. Great work by @weikengchen: We now have finite field arithmetic for the M31 and Baby Bear fields, as well as for their degree-4 extensions.These are the basis for implementing STARK verifiers on Bitcoin.

  • link: https://twitter.com/robin_linus/status/1771809562246463577