00. Plonky2–Plonky3 数学原理个人学习总结
这是我围绕 Plonky2 → QED Plonky2.5 → Plonky3 整理的一组个人学习总结。我先梳理有限域、多项式、PLONK、AIR、FRI 与 Fiat–Shamir，再逐层记录三套实现为什么这样组合、哪些概念可以迁移，以及哪些 proof format 完全不兼容。
资料快照：2026-07-29。 数学原理与软件状态分开叙述；“当前实现”均绑定具体仓库快照。Plonky2.5 特指 QED Protocol 的 2024 prototype，不是官方标准化的中间版本。
1. 整体知识脉络
这些记录按文件编号从 01 延伸到 18，整体脉络如下：
\[\boxed{ \text{数学基础} \to \text{承诺与 transcript} \to \text{PLONK / AIR} \to \text{FRI} \to \text{Plonky2} \to \text{Plonky2.5} \to \text{Plonky3} \to \text{递归、迁移与安全} }\]各篇笔记的内容依赖关系如下：
flowchart TD
A["01 技术全景"] --> B["02 有限域、多项式与编码"]
B --> C["03 承诺与 Fiat-Shamir"]
C --> D["04 PLONK 算术化"]
D --> E["05 PLONK 完整协议"]
E --> F["06 PLONKish 门与查表"]
C --> G["07 STARK、AIR 与 ALI"]
G --> H["08 FRI 与 DEEP-FRI"]
D --> I["09 Plonky2 算术化与 FRI"]
F --> I
H --> I
I --> J["10 Plonky2 递归"]
J --> K["11 QED Plonky2.5 bridge"]
K --> L["12 Plonky3 模块化架构"]
F --> L
H --> L
L --> M["13 Plonky3 FRI、LogUp 与递归"]
M --> N["14 Circle STARK 与现代 PCS"]
J --> O["15 通用递归、累积与折叠"]
M --> O
O --> P["16 代际对照与迁移"]
P --> Q["17 参数与安全审计"]
Q --> R["18 一手资料索引"]
图中的箭头表示理解依赖，不表示 proof bytes 或代码 API 兼容。
2. 六组主题笔记
第一组：共同语言
| 编号 | 文档 | 记录的核心问题 |
|---|---|---|
| 01 | 技术全景与知识脉络 | SNARK、STARK、PLONK、FRI、PCS 分别位于哪一层？ |
| 02 | 有限域、多项式与编码基础 | FFT、Lagrange、消失多项式、RS code 为什么是证明系统基础设施？ |
| 03 | 多项式承诺与 Fiat–Shamir 变换 | commitment、opening、Merkle oracle 与 transcript 各自保证什么？ |
第二组：Plonky2 的两条来源
Plonky2 不是“纯 PLONK”，也不是传统 AIR-STARK。它把 PLONKish 算术化和 permutation argument 接到 Merkle/FRI 后端，因此这里同时整理两条基础线。
| 编号 | 文档 | 记录的核心问题 |
|---|---|---|
| 04 | PLONK 算术化基础 | selector、wire、copy constraint、grand product 如何工作？ |
| 05 | PLONK 完整协议与 KZG 承诺 | quotient、linearization、随机点 opening 如何组成完整协议？ |
| 06 | PLONKish 自定义门与查表 | 宽门、rotation、Plookup、LogUp 与 Lasso 分别解决什么问题？ |
| 07 | STARK 执行轨迹与 AIR / ALI | trace constraints 如何变成低度多项式恒等式？ |
| 08 | FRI 与 DEEP-FRI 低度测试 | 为什么折叠与少量查询能检测 RS proximity？ |
第三组：完整拆解 Plonky2
| 编号 | 文档 | 记录的核心问题 |
|---|---|---|
| 09 | Plonky2 算术化与 FRI | Goldilocks、135 wires、部分积、Poseidon、FRI 如何拼成一份 proof？ |
| 10 | Plonky2 递归原理与工程 | verifier-in-circuit、Merkle cap、高元 FRI 与 cyclic recursion 为什么高效？ |
第四组：2.5 bridge，而不是虚构的“中间协议”
| 编号 | 文档 | 记录的核心问题 |
|---|---|---|
| 11 | Plonky2.5 跨系统递归桥 | 旧版 Plonky3 proof 怎样成为 Plonky2 private witness？固定字段、AIR、MMCS、FRI schema 为什么限制兼容性？ |
第 11 篇只研究 QED 仓库中的具体 cross-verifier。它的价值是展示“在系统 A 中重演系统 B verifier”的完整边界，不应被理解为 Plonky2 与当前 Plonky3 之间的通用升级器。
第五组：从固定系统到 Plonky3 toolkit
| 编号 | 文档 | 记录的核心问题 |
|---|---|---|
| 12 | Plonky3 模块化架构 | Field、Domain、Matrix、MMCS、PCS、Challenger、AIR 如何经类型组合成 concrete proof system？ |
| 13 | Plonky3 的 FRI、LogUp 与原生递归 | 动态高元 FRI、Batch-STARK、LogUp bus、multi-chip recursive verifier 如何工作？ |
| 14 | Circle STARK 与现代哈希型 PCS | Circle FRI、STIR、WHIR 等新后端改变了哪些域与验证成本假设？ |
第六组：比较、迁移与审计
| 编号 | 文档 | 记录的核心问题 |
|---|---|---|
| 15 | 递归、累积与折叠方案 | recursive verification、accumulation、Nova-style folding 为什么不是同一件事？ |
| 16 | Plonky 系列对照与迁移 | 2、2.5、3 哪些层能类比，哪些 proof identity 和 wire format 必须重建？ |
| 17 | 系统对比、参数与安全清单 | 如何区分 proven/conjectured soundness、ZK、安全位、审计与性能声明？ |
| 18 | 论文与官方资料索引 | 每一个关键公式和当前实现状态应回到哪份一手资料？ |
3. 三组快速索引
关注 Plonky2
01 → 02 → 03 → 04 → 05 → 06 → 07 → 08 → 09 → 10
其中 04、06 给出宽门与 permutation 的语言，07、08 给出 FRI 后端所需的编码与低度测试语言。
关注当前 Plonky3 / zkVM
01 → 02 → 03 → 06 → 07 → 08 → 12 → 13 → 14 → 17
06 的 LogUp 与 07 的 AIR 是理解后续约束与 soundness 的必要背景。
关注从 Plonky2 到 Plonky3 的迁移
09 → 10 → 11 → 12 → 13 → 15 → 16 → 17
这条路线假定已经掌握 02–08。迁移对象是 relation、public-input schema、security parameters 与 recursion semantics，不是 crate major version。
4. 贯穿这些笔记的四层模型
任何具体系统都拆成四层：
| 层 | 核心对象 | Plonky2 例子 | Plonky3 例子 |
|---|---|---|---|
| 关系与算术化 | witness、trace、约束 | 宽 PLONKish gates + permutation | AIR / chips / buses |
| 多项式 IOP | quotient、随机线性组合 | gate/permutation quotient | Uni-STARK / Batch-STARK quotient |
| 承诺与低度测试 | commit、open、proximity | Merkle + FRI | 可组合 MMCS + PCS + FRI/WHIR |
| transcript 与封装 | challenges、ZK、recursion | Poseidon challenger + recursive circuit | Challenger trait + ZK PCS + native recursion |
阅读任何公式时，先问它属于哪一层。许多错误都来自把“算术化名称”“承诺后端”和“最终 proof system”混成一个名词。
5. 先纠正四个常见误解
- PLONK 不等于 KZG。 PLONK 首先是一套算术化与多项式 IOP；Plonky2 正是把 PLONKish 前端接到 FRI，而不是 KZG。
- STARK 与 SNARK 不是严格反义词。 STARK 强调透明性、可扩展性与常见的哈希/编码路线；SNARK 描述 succinct argument 的性质。
- Plonky3 不是 Plonky2 proof format 的第三版。 它是可组合 polynomial-IOP toolkit；不同类型参数可以产生不同 proof schema。
- “证明系统”不自动意味着 zero-knowledge。 soundness、knowledge soundness、succinctness 与 witness privacy 是独立性质；ZK 必须有明确 hiding 机制与模拟论证。
6. 统一记号
- $\mathbb F$：有限域；$q=\lvert\mathbb F\rvert$；
- $H={1,\omega,\ldots,\omega^{n-1}}$：大小为 $n$ 的 evaluation domain；
- $Z_H(X)$：$H$ 的消失多项式；
- $L_i(X)$：第 $i$ 个 Lagrange 基多项式；
- $\alpha,\beta,\gamma,\zeta$：Fiat–Shamir transcript 导出的随机挑战；
- $\operatorname{Com}(f)$：多项式或 evaluation matrix 的承诺；
- $x$：公开输入，$w$：私有 witness，$\pi$：证明。
不同论文的 challenge 名称、grand-product 方向和行下标可能相反；笔记保持内部一致，并在涉及源码时注明映射。
7. 阅读与渲染
- 数学公式使用 LaTeX delimiters：行内 $…$、块级 \(...\)。
- 图使用 Mermaid，并经过渲染级校验。
- 每篇结尾按新编号提供唯一的上一篇、下一篇和总目录链接。
- 这些笔记解释原理，不是 wire-format specification 或可直接部署的参数文件。生产系统必须重新核对 release、参数生成代码、安全证明与审计报告。
下一篇：技术全景与知识脉络