StarkWareSessions2023
https://www.youtube.com/playlist?list=PLcIyXLwiPilUs4PiBinyL2ker2oEFT-mc
@nico_mnbl: 最近更新了这个！
https://nmohnblatt.github.io/zk-jargon-decoder/foreword.html
- 新外观：移动到了 mdbook
- 新条目：Oracle、PLONKish ，并完成了许多空条目，例如 Nullifier、Polynomial Commitment Scheme、Threshold Encryption
- 改进了一些现有条目，如 R1CS
密码学工具
作者将常用的一些密码学工具的 Web 版，比如生成密钥、哈希、解密加密等等，做在了一起方便使用。
https://crypto-online.cn/
@Steven Galbraith：
https://www.nist.gov/news-events/news/2023/02/nist-revises-digital-signature-standard-dss-and-publishes-guideline
用于数字签名的 NIST 联邦信息处理标准 (FIPS) 的新版本已经发布， 另见此处。此版本包括进了 EdDSA。 EdDSA（至少）有两个显着特征。 首先，它与 Schnorr 签名的关系比 ECDSA 更密切。 这意味着它（在我看来）避免了ECDSA 的许多笨拙方面，并允许进行更优雅的安全分析。 其次，它使用Edwards形式的曲线。 具体来说，文件 Recommendations for Discrete Logarithm-based Cryptography: Elliptic Curve Domain Parameters 指出“本建议包括两条新指定的 Edwards 曲线，与传统曲线相比，它们提供更高的性能、抵抗侧信道攻击和更简单的实现”。 这些曲线包括广泛使用的 Edwards25519 曲线。我还借此机会宣传此页面，其中列出了使用 Ed25519 的应用程序。
NIST 选择“轻量级密码学”算法来保护小型设备。这些算法旨在保护由物联网和其他小型电子产品创建和传输的数据。
https://www.nist.gov/news-events/news/2023/02/nist-selects-lightweight-cryptography-algorithms-protect-small-devices
零知识证明 (ZKP) 是区块链的未来吗？在对消费者数据隐私的新兴趣和零知识以太坊虚拟机 (zkEVM) 的发展的推动下，整个 ZKP 生态系统的创新呈爆炸式增长。
https://www.bvp.com/atlas/are-zero-knowledge-proofs-zkps-the-future-of-blockchain
@Ingo_zk：这是我们演讲“ECNTT 简介”的幻灯片
https://www.ingonyama.com/blogs/intro-to-ecntt-from-starkware-sessions-2023
@federicocarrone：我刚刚结束了与我们团队的 20 名工程师、数学家、物理学家、密码学家和计算机科学家的会议，他们刚刚开始在 lambdaworks 和我们的 rust证明者中的starknet 的工作。 看看这个库并了解我们如何构建的：
https://github.com/lambdaclass/lambdaworks
@sproule_：zk力量尽在您掌中！ zk 的独特属性比以往任何时候都更能通过突破性的新工具提供给所有级别的开发人员。我通过这些选项整理了一份指南，有助于剖析关键的权衡：
https://blockchain.capital/a-developers-guide-to-the-zkgalaxy/
@verumlotus：周末hack ： 建立了一个网站，允许你用 ZK友好哈希（MiMC 和 Poseidon）计算任何输入的哈希值，在各种椭圆曲线上，包括 BN-128 和来自@ElectricCoinCo的pasta曲线
https://zk-hashes.vercel.app/
上个月在搞一个使用Nova（需要Vesta曲线）的ZK 项目时有了这个想法。 生成 MiMC/Poseidon 哈希的唯一方法是编写 Circom 电路并记录输出。它适用于高达 50 维的数字、向量和矩阵。 MiMC 是从@0xPARC的@darkforest_eth 实现中改来的，而 Poseidon 是由@identhree的实现中改来的。
这里是源代码：
https://github.com/verumlotus/ZK-Hashes
SAFE (Sponge API for Field Elements) – ZK Hash 应用的工具箱
https://hackmd.io/bHgsH6mMStCVibM_wYvb2w
@Braavos：Braavos 钱包账户合约以及快速ECDSA实现现已开源！
https://github.com/myBraavos/braavos-account-cairo
https://github.com/myBraavos/efficient-secp256r1
@Braavos：宣布账户抽象安全金字塔！
https://twitter.com/myBraavos/status/1622548536444305411
@crypto_carsten：我们花了一些时间列出了 MPC（和其他一些隐私增强技术）在经典金融和 Defi 中的使用情况。
https://eprint.iacr.org/2023/122
@Ariel Gabizon：Does someone know by what factor roughly is multiplication in goldilocks faster than e.g. the bn254 field?
https://twitter.com/rel_zeta_tech/status/1622984483359129601
@λFederico Carrone：starknet_in_rust 是 StarkNet 在 Rust 中的一个实现。 使用 cairo-rs，即 Cairo 虚拟机的 Rust 实现。
https://github.com/lambdaclass/starknet_in_rust
@smpalladino：在研究了如何构建零知识证明一段时间后，我整理了一篇文章，阐述了我从开发人员的角度所学到的知识。包括以下代码示例：Circom/Halo2/Noir
https://dev.to/spalladino/a-beginners-intro-to-coding-zero-knowledge-proofs-c56
@λFederico Carrone：正在研究 STARKs 递归、SNARKs 和 IVC 相关内容。 我们仍然不了解有关 STARK 中递归的一些事情，但我们已经看到它们比我们原先想象的更强大。 我们将在接下来的几周内在帖子中进行解释。
@sofía celi：Gregor Seiler 非常有趣的博士论文：“实用的基于格的零知识证明系统”
https://www.research-collection.ethz.ch/bitstream/handle/20.500.11850/560505/1/thesis.pdf
@makoto_inoue：ENS at StarkWare Sessions
https://ens.mirror.xyz/Lznxnu4tBovdWcsv7QHFCieXaTddpdKKDrN4nfZSzxk
@Prof B Buchanan OBE：OpenSSL 已经变得臃肿，漏洞不断，但 NaCl 已经将编程剥离到一些最受信任的方法，例如 Curve 25519（X25519 和 Ed25519）、AES GCM、Blake2b 和 XChaCha20。 更少的代码行数，更少的bugs！
https://asecuritysite.com/nacl
@fermatslibrary：在信息论中，字符串的 Kolmogorov 复杂度定义为可以生成该字符串作为输出的最短程序的长度。它提供了一种量化字符串信息内容的方法：
@mkoeppe_math：发布SageMath 9.8 且在Github开源 https://github.com/sagemath/sage
新的多项式系统 (msolve)、混合整数优化问题 (SCIP Optimization Suite)、半定规划（DSDP、SCIP-SDP）和 SAT (Kissat) 的求解器。
@Brendan：一年前Polygon只被视为权宜之计，一个在全部过渡到L2之前满足当下需求的EVM 侧链。今天，Polygon 拥有最快的 ZK 技术和第一个可用于生产的 zkEVM。怎么做到的？论反馈循环和专业化……
对于 ZK，性能非常重要。 当然，证明可并行，但下面两者之间存在着巨大的差异：
- 使用许多 GPU，每笔交易证明时间30 分钟
- Polygon zkEVM 可以在 CPU 上在 2.5 分钟内证明 10m 的gas的批量（这还会进一步下降！）。
Polygon 是如何变得如此之快的？我们有一个整个团队（Zero）在致力于研发，其任务是构建业内最快的 ZK 证明者。Zero 拥有非常强大的密码学家和工程师，这创造了一个具有巨大好处的反馈循环。
密码学学术界重点关注的主要是渐近（big-O）性能。 你的证明系统是否使用 O(nlogn) 的域操作、O(n) 的群操作等？当然是有性能基准测试，但它们的用处不大，因为这些实现没有得到高度优化。Zero的认识是常数因子也很重要！
这创建了一个反馈循环——密码学家与工程师合作，以识别和使用更有效的工具（更小的域、更快的哈希函数），从而产生更快的 ZK 证明者。举个例子：理论研究人员可能无法区分各个使用 O(nlogn) 次域操作的证明系统。但从性能的角度来看，其他条件相同时，使用 256 位域的证明者将比使用由 Polygon 发现的 64 位 Goldilocks 域的证明者慢得多。密码学家设计证明系统以使用更高效的原语 + 工程师进一步优化这些原语以用于硬件 = 🤯 突然间，我们有了令人难以置信的性能证明者，我们可以将其交给 zkEVM 大师 @jbaylina 以进行合作。
Polygon反驳了 EVM 等价的 zkEVM（扩展的圣杯）还有 3-5 年距离的传统观点。zkEVM 已经来了。 现在在测试网上，很快就会在主网上。与此同时，Zero团队正在展望未来……
@Alin Tomescu：许多人喜欢对他们的Merkle树的叶子进行排序，以此作为证明非成员资格的一种方式。
在这篇博文中，我给出了 3 个为什么这是次优的原因，并试图说服你几乎总是使用 Merkle trie（前缀树）：
太长不看版：当摘要被恶意生成时，带有排序叶子的 Merkle 树是不安全的（见截图）。 这种情况实际上出现在证书透明度 (CT) 等真实应用中。
这种错误排序完全破坏了安全性：恶意服务器可以证明元素 8 不在树中，同时也证明 8 在树中。 这使得任何 Merkle 证明对任何客户都毫无意义。
例如，这是 8 的恶意非成员证明：
…这里还有一个8的恶意的成员资格证明 。 糟糕 ：）
不过，并非所有的希望都破灭了。 在某些场景中，假设 Merkle 树（以及 Merkle 根）计算正确是安全的，因此这种攻击不会发生。 例如，在拜占庭容错系统或“区块链”中。但不是在密钥透明度中，那里有一个恶意服务器。即便如此，具有排序叶子的 Merkle 树还有其他问题，应该尽可能避免：（1）它们不能有效更新，以及（2）它们具有次优的证明大小。为了避免所有这些痛苦，请使用 Merkle tries！ 它们既简单又安全，即使在恶意生成摘要时。
@13 yo VC ：什么是 RISC Zero以及为什么它是创建 ZK 应用的游戏规则改变者？
这里是一份CPU、指令集架构、操作码等如何与@RiscZero 结合在一起的简单易懂的分解线程：
CPU 运行机器并执行计算。CPU 根据其指令集架构 (ISA) 解释指令，ISA 确定操作码（电路和位操作）。因此，ISA 定义了软件如何使用 CPU。
常见的 ISA：ARM、X86、RISC-V，甚至 EVM（“虚拟 ISA”）。
其中，@risc_v 的新颖之处在于它是开源的，并得到广泛的行业联盟和开发者生态系统的支持，也是最高效、最快的指令集。
ZKP 是通过对电路生成多项式创建的。 zkEVM 想要用 EVM 制作电路，以便每个 EVM 计算都可以产生 ZKP。但EVM 最初并不是为 ZKP 设计的。因此，@RiscZero 不是让 ZK 根据 EVM 工作，而是通过从头开始重新设计 RISC-V 指令集的电路来创建 zkVM，以便从 RISC-V ISA 的任何指令中生成 ZKP。因此，任何在 zkVM 上运行的东西都可以生成 ZKP 计算。
由于 RISC-V 是开源的，能够为 ZKP 生成添加自定义加速器，因此它将支持更快的计算和证明者/验证者生成。可以查看 http://delendum.xyz/2023/01/11/zk-system-benchmarking.html以获得基准测试。而且 b/c RISC-V 已经拥有自己的社区和编译器，现有对 Rust 和 C++ 等通用语言的向后兼容性支持，与 Solidity/Cairo 等其他语言相比，它们更主流，支持库/包更多 .
总而言之，@RiscZero zkVM 是一台可验证的计算机，它像真正的嵌入式 RISC-V 处理器一样工作，使开发人员能够像编写任何其他代码（如 Rust 和 C++）一样编写 ZK 证明。它通过将现有语言和工具引入 ZKP 开发来消除障碍。
@Jordi Baylina ：FFLONK 已经在#snarkJS 中可用了！
首先，我要感谢@aztecnetwork 的@rel_zeta_tech 和@Zac_Aztec创建了这个惊人的协议。FFLONK 与 GROTH16 或 PLONK 一样，是一种 zkSNARK 协议，具有以下优点：
- 不需要特定的可信设置（仅需通用设置）。
- 可以在链上验证证明，比 Groth16 便宜一点，比普通 PLONK 便宜 30%。
唯一的缺点是证明生成比 Groth16 慢 10 倍左右。这在@0xPolygon #zkEVM 上下文中不是大问题。我们仅在聚合许多批次证明的证明的最后递归阶段使用 SNARK。该电路相对较小，成本在许多批量证明中均摊。最后一个阶段的当前证明时间约为 2 分钟，但我们的目标是在进行一些未决优化后不到 1 分钟。Gas 成本验证为 203K，优于 Groth16 的 230K gas 和 PLONK 的 300K。一旦我们对该实现进行了良好的审核，我们将在Polygon主网 zkEVM 中使用该协议。 （寻求专家审议）
@Sin7y - Ola：非常高兴地宣布OlaVM 的概念验证已经完成！ 工程设计和实现的细节可以在https://github.com/Sin7Y/olavm 找到；通过 Ola，我们寻求构建一个具有可编程隐私、可编程可扩展性和开发人员兼容性的一站式平台，以支持Ethereum 生态；Ola将由零知识虚拟机OlaVM、智能合约语言Ola-lang、Ola-compiler、Ola-sequencer等组成。除了完成概念验证，我们还完成了Olang的设计和实现（详见 https://github.com/Sin7Y/ola-lang）；Ola-lang已成功集成到对开发者友好的IDE——Visual Studio Code中，开发者可以在VSCode上编写Ola-lang程序，调用程序函数，生成证明和验证流程（下载地址：https://marketplace.visualstudio.com/items?itemName=Sin7y.ola); OlaVM 概念验证的完成标志着 Ola 的一个里程碑。 我们相信可编程的可扩展性和隐私性将是以太坊乃至区块链行业未来的重要特征；如果您希望与我们合作赋能以太坊区块链并共同建立 Ola 生态和社区，请加入 Sin7y - Ola DC 服务器 (https://discord.gg/vDFy7YEG6j) 或联系我们 在 contact@sin7y.org。 欢迎任何形式的贡献！要了解有关Ola 当前发展和未来计划的更多信息，请阅读下面的文章。
https://medium.com/@sin7y/unveiling-olavm-proof-of-concept-the-next-generation-full-featured-zkvm-5840b27f8e4c
@Binance：我们团队本周对Binance 储备金证明（PoR）验证系统进行了一些升级。该线程总结了这个更新。
我们已经使用 zk-SNARK 升级了我们的储备金证明系统，这是一种零知识验证方法，旨在让您的敏感信息更加私密和安全。@PolyhedraZK说：“在当今的计算能力范围内，破坏现代零知识证明系统的安全性是不可能的。” 作为此次升级的一部分，我们向储备金证明系统添加了四个新代币。现在支持 13 种流行的代币，您可以验证您在我们托管中的持有量。
我们打算在未来几周内继续向Binance 的储备金证明系统添加更多代币。敬请关注。我们将Binance 的储备金证明系统代码开源，因为我们希望继续为我们的用户提供更多透明度，以便行业同行和社区可以从这项创新技术中受益。Binance 还将继续投资于使验证功能更加可靠、安全和私密的技术。通过下面文章详细了解 ZK-SNARK 如何改进币安的储备金证明系统。
https://www.binance.com/en/blog/all/how-zk-snar-ks-improve-binances-proof-of-reserves-system-6654580406550811626
由于这是我们 zk-SNARK 的第一个版本，我们希望鼓励社区提供反馈，以便我们可以继续改进系统。
@Geometry：新研究Sangria，@nico_mnbl 的 PLONK 折叠方案
https://geometry.xyz/notebook/sangria-a-folding-scheme-for-plonk
折叠方案首先在 Nova 中引入，用于构建已知递归开销最低的递归 SNARK。 我们将类似的想法应用于 PLONK 算术化。
什么是折叠方案？ 我们想证明对公共输入 A 和公共输入 B 的计算。折叠方案允许我们将 A 和 B 一起折叠成 C，而不是为每个输入做一个 SNARK。证明 C 足以说服验证者 A 和 B 是正确的！Nova 使用折叠方案来实现增量可验证计算IVC。 即函数 F 被重复应用的证明：z, F(z), F(F(z)), F(F(F(z)))…证明额外的步骤不需要验证之前的证明，而是通过折叠来更新它
目前实现 IVC 的方法有：
- 完全递归（SNARK的SNARK的 …）如 Plonky2
- 像halo2一样的分裂和原子累加
- Nova的折叠方案做法
我们来快速看看其中的细节并提供概览比较。在完全递归中，在计算的每一步中，我们都会产生一个值 y 和一个证明 P，即“1) 先前的证明是有效的且 2) y = F(prev_state)” 这需要验证这一步电路内部的 S[N/T]ARK。 成本各不相同：Plonky2 为 $O(log(F))$，Groth16 为 3 个配对 。在累加方案中，在每一步开始生成 SNARK 证明，但推迟多项式承诺的昂贵打开。 相反，承诺会累加起来，只在最后打开一次。halo2 (atomic) 需要 $O(log(F))$ 次点加，拆分 acc需要O(1)。
最后看 Nova 的折叠方案，这里直到最后才证明：正如我们所见，折叠方案将两个实例组合为一个。 在每一步，我们将实例折叠成一个正在运行的实例。这需要 O(1) 点加法，但常数更小！虽然 Nova 是为 R1CS 电路设计的，但 Sangria 为 PLONK 算法释放了相同的潜力。与 Nova 推出“relaxed R1CS”的方式相同，Sangria 中的主要成分是“relaxed PLONK”
