零知识证明

重要‼️Stark101虽然是希望成为任何软件工程师的入门教程，但是ZK确实有太多不得不说的概念，不过，我会尽量用最简单，最少公式的方式来讲解。所以，Start101绝对不会教会你如何成为数学大师，其目的在于让你轻松的理解Stark的逻辑。但是你需要遵守以下规则：任何标题开头为附加内容

计算轨迹是 Stark 的第一步，也是最简单的一步，但是最为重要的一步。
但是在章节开始之前，你需要必须 🚨掌握以下前置知识：

低度拓展(LDE)是Stark中用于提高安全性的一个步骤，通过把多项式的域拓展到更大的域，从而提高计算的安全性。

承诺（Commitments）是Stark中用于去除需要交互验证的步骤，通过将Trace的值进行默克尔树构建，从而获得虚拟的交互验证。

那些应该学 ZK 数学，有些人也许不需要学 ZK 数学

Zama 团队发布了 TFHE-rs (v0.11)、Concrete (v2.9)、Concrete ML (v1.8) 和 fhEVM (v0.6) 的新版本。

Ingonyama Research 宣布了 2025 年度的研究资助计划，总额为 10 万美元，旨在支持使用 ICICLE（一个用于零知识证明的数学库）进行算法研究的开发者和研究人员。该计划鼓励研究者使用 ICICLE 重新实现已有的算法，并通过与原始论文的性能比较来获得资助，资助金额与性能提升幅度成正比。

大量零知识证明项目由于错误地使用了某个 zkSNARKs 合约库，引入「输入假名 (Input Aliasing) 」漏洞，可导致伪造证明、双花、重放等攻击行为发生，且攻击成本极低。众多以太坊社区开源项目受影响，其中包括三大最常用的 zkSNARKs 零知开发库 snarkjs、ethsnarks、ZoKrates，以及近期大热的三个混币（匿名转账）应用 hopper、Heiswap、Miximus。这是一场由 Solidity 语言之父 Chris 两年前随手贴的一段代码而引发的血案。

Ingonyama 发布了 ICICLE v3.1，这是一个位于 ZK 堆栈硬件和协议层之间的库，旨在优化 CPU 和 GPU 上的 ZK 算法性能。v3.1版本修复了多个bug，并增强了CPU后端性能，支持客户端后端和Sumcheck。未来还将添加Poseidon2哈希算法，目标是在CPU上超越Plonky3的性能。

文章介绍了Binius，一种在二进制域上高效生成证明的系统，详细解释了其技术原理、实现方法及其相较于SNARKs和STARKs的优势。

本文介绍了RC-STARKs，它通过利用复数域上的FFT，并识别问题中的对称性，使得在M31域上使用STARKs成为可能，并能有效利用现有的硬件优化。RC-STARKs在性能上与Circle STARK相当，但由于其对FFT的直接利用，具有更好的硬件兼容性。本文还分享了作者阅读研究论文的经验和方法。

这篇文章解释利用ZKP(零知识证明)与区块链来实现去中介的交易协议的原理，讲讲我们是怎么把这个理论变成实用的代码的，这是一篇概述，希望了解更多的朋友请关注后续。

ICICLE v3 发布，这是一个密码学库，旨在加速零知识证明（ZKP）。新版本引入了强大的CPU后端，将ICICLE的卓越性能和用户友好的多项式API扩展到标准处理器，从而实现更大的灵活性和可访问性。此外，新版本还优化了GPU功能，并支持更大的原语。

Brevis 集成了 Ingonyama 的 ICICLE 加速库，显著提升了零知识证明的性能，特别是在多标量乘法（MSM）和数论变换（NTT）等关键操作上，实现了高达 70% 的加速。通过此次集成，Brevis 能够更高效地处理大规模数据集上的复杂计算，并扩展其在区块链领域的应用，例如数据驱动的 DeFi、zkBridges 和 zkDID 等。

Zcash的发展大体经过了OverWinter(过冬) -> Sprout(发芽) -> Sapling(树苗)这几个阶段，随着业务和功能的逐渐丰富，密钥系统也越来越复杂，刚开始接触时感觉一头雾水，但是静下心来仔细分析，就能逐渐领略其中的魅力。