16. Plonky2、Plonky2.5、Plonky3：逐层对照与迁移方法

发表于 2026/07/29 更新于 2026/07/29

作者 Chen Xichao

20 分钟阅读

结论先行：Plonky2 是一套具体 PLONKish + FRI 证明系统；QED Plonky2.5 是“旧版 Plonky3 proof → Plonky2 proof”的第三方 bridge；Plonky3 是模块化 PIOP/STARK toolkit，并已有独立的原生 STARK recursion 项目。三者不是线性兼容的三个 wire-format versions。

1. 三个名字各指什么

1.1 Plonky2

\[\boxed{ \text{宽 custom-gate PLONKish} + \text{permutation} + \text{Merkle/FRI polynomial testing}. }\]

典型具体化：

Goldilocks；
quadratic extension；
width-12 Poseidon；
135-wire recursion config；
Plonky2-specific proof/common/verifier data。

1.2 QED Plonky2.5

\[\boxed{ \pi_2 \text{ proves } \mathsf{Verify}_{\mathrm{old\ P3}}(\pi_3)=1. }\]

它是：

2024 v0.1.0 prototype；
Goldilocks/degree-2/Poseidon2；
手工重写 Plonky3 AIR/verifier；
二元 FRI；
outer proof 仍是 Plonky2。

1.3 Plonky3

\[\boxed{ \text{Field} +\text{Domain/DFT} +\text{MMCS} +\text{PCS} +\text{AIR/PIOP} +\text{Challenger}. }\]

它是 primitives toolkit，不是一个单一 proof format。当前主线包括：

Uni-STARK；
Batch-STARK；
two-adic FRI；
Circle PCS；
WHIR/sumcheck primitives；
LogUp；
security calculator；
独立原生 recursion stack。

2. 时间线不是兼容性链

timeline
    title Plonky 系列的设计演进
    2022 : Plonky2 技术稿
         : PLONKish + FRI + Goldilocks 递归
    2024 : QED Plonky2.5 prototype
         : 在 Plonky2 中验证当时的 Plonky3 Uni-STARK
    2024-2026 : Plonky3 模块持续演进
              : fields, FRI, Circle, Batch-STARK, LogUp, WHIR
    2026 : Plonky3-recursion 独立项目
         : 用 Plonky3 STARK primitives 做原生递归

时间上 $2\to2.5\to3$，不代表：

\[\operatorname{Decode}_{3}(\pi_2)\]

或

\[\operatorname{Verify}_{2.5} (\pi_3^{\mathrm{current}})\]

存在。

3. 全栈对照表

层	Plonky2	QED Plonky2.5	当前 Plonky3
定位	具体 proof system/library	cross-verifier prototype	modular PIOP toolkit
主算术化	PLONKish custom gates	inner AIR，outer PLONKish	AIR / Uni-STARK / Batch-STARK
wiring/跨表	PLONK permutation	outer 继承 Plonky2；inner demo 无 current batch LogUp	LogUp buses / batch interactions
基础域	Goldilocks	Goldilocks → Goldilocks	Goldilocks、BabyBear、KoalaBear、M31 等
challenge 扩域	常用 degree 2	固定 degree 2	config-dependent，31-bit fields 常见 degree 4 等
domain	two-adic multiplicative coset	two-adic	two-adic 或 Circle 等
PCS	Plonky2 batch FRI testing	inner old two-adic FRI；outer Plonky2 FRI	`Pcs` abstraction：FRI/Circle/其他
vector commitment	Plonky2 Merkle cap	inner Poseidon2 MMCS；outer Plonky2 cap	`Mmcs` mixed heights/multi-proof
transcript hash	常用 Poseidon	inner Poseidon2，outer Plonky2	configurable challenger
quotient	gate+permutation combined quotients	inner AIR quotient，由 outer circuit 检查	symbolic AIR degree → chunks
recursion	Plonky2 verifier custom gates	P3 verifier in P2	fixed P3 verifier → P3 Batch-STARK
ZK	explicit config；默认 recursion config false	demo outer 默认 false	PCS/backend property；ZK layouts
security口径	default conjectured target	依 inner+bridge+outer，无独立通用结论	conjectured + proven reports
proof format	Plonky2-specific	outer P2 + pinned old P3 JSON	config-associated types；非单一格式
当前状态	官方弃用	2024 prototype	active development

4. 同一个 Fibonacci relation 怎样表达

设公开 statement：

\[(a,b,x,N),\]

要求从 $(a,b)$ 开始，经过 $N$ 行 Fibonacci transition，末值为 $x$。

4.1 Plonky2

CircuitBuilder 分配变量并添加：

\[l_{r+1}=r_r, \qquad r_{r+1}=l_r+r_r.\]

这些 arithmetic operations 被打包到 Plonky2 custom gates；跨 gate 的变量相等通过 routed wires/permutation 证明。

公开值注册为 circuit public inputs，再被哈希进固定 PI gate。

4.2 Plonky2.5

inner 旧版 Plonky3 先用 AIR 证明：

\[\begin{aligned} c_r&=a_r+b_r,\\ a_{r+1}&=b_r,\\ b_{r+1}&=c_r. \end{aligned}\]

得到 $\pi_3$。

outer Plonky2 circuit 手工重写同一 AIR verifier，并证明：

\[\mathsf{Verify}_{\mathrm{oldP3,Fib}}(\pi_3)=1.\]

若 outer circuit 没有把 $(a,b,x,N)$ 作为 public inputs 显式绑定，外部不会自动得到完整 statement。

4.3 当前 Plonky3

FibonacciAir::eval 同一份源码用于：

symbolic degree inference；
prover quotient evaluations；
verifier OOD identity。

public values length 由 BaseAir::num_public_values 固定，trace commitment/quotient/PCS 由所选 StarkConfig 决定。

若递归，则固定 verifier circuit 被 lower 到 Const/Public/ALU/Poseidon chips，再用 Batch-STARK 证明。

flowchart TB
    REL["Fibonacci relation"] --> P2["Plonky2<br/>custom gates + permutation"]
    REL --> P3["Current Plonky3<br/>single-source AIR"]
    P3 --> PR3["P3 STARK proof"]
    PR3 --> Q25["QED 2.5 bridge<br/>old format only"]
    Q25 --> OP2["Outer Plonky2 proof"]
    PR3 --> R3["Current native P3 recursion<br/>fixed verifier chips"]
    R3 --> OP3["Outer P3 Batch-STARK"]

图中 QED bridge 的箭头只表示其目标思想；当前 $\pi_3$ 不应被理解为与 2024 serialized proof 直接兼容。

5. 算术化的根本差异

5.1 Plonky2：gate-row-centric

一行选择一种 gate：

\[G_j( \mathbf w_r, \mathbf c_r )=0.\]

selector 编码 gate id，copy constraints 由 permutation argument 处理。

适合：

普通 circuit builder；
大量不规则 arithmetic DAG；
为 verifier/hash 设计很宽的 custom gates。

5.2 Plonky3：trace-transition-centric

AIR 约束：

\[C_j( \mathbf t_r, \mathbf t_{r+1}, \mathbf p_r, \mathbf{pv} )=0.\]

适合：

状态机；
CPU/zkVM chips；
hash rounds；
多表系统；
SIMD packed quotient evaluation。

5.3 不能机械一行对一行

一个 Plonky2 Poseidon gate 可能表示整次 permutation；Plonky3 Poseidon AIR 可能用多行/多表表示。

因此 migration 目标应是 relation 等价：

\[\mathcal R_{\mathrm{P2}} = \mathcal R_{\mathrm{P3}},\]

不是：

\[\operatorname{rowCount}_{\mathrm{P2}} = \operatorname{rowCount}_{\mathrm{P3}}.\]

6. copy permutation 与 LogUp bus 的映射

6.1 Plonky2

两个 cells 相等：

\[w_j(\omega^r)=w_k(\omega^s)\]

通过全局 permutation grand product 证明。

6.2 Plonky3 multi-chip

producer/consumer 都发 message：

\[(\text{bus},\text{id},\text{value},\ldots).\]

LogUp 证明 sends/receives multisets 平衡。

6.3 迁移对应

Plonky2 概念	Plonky3 常见对应
routed variable equality	同一 chip 内 local transition，或跨 chip bus interaction
advice wire	main/auxiliary trace column
constant selector	preprocessed/periodic column
copy permutation	LogUp / explicit AIR equality
custom lookup gate	lookup interaction + permutation trace

映射不是自动的。若一个 Plonky2 copy class 同时承担：

value equality；
memory address consistency；
uniqueness；
write ordering，

仅用无序 multiset lookup 可能不足，还需 timestamp/sortedness/range constraints。

7. commitment 与 proof identity

7.1 Plonky2 identity

\[\operatorname{Spec}_2 = ( d_{\mathrm{circ}}, C_{\mathrm{const},\sigma}, \text{common data}, \text{hash/FRI config} ).\]

7.2 Plonky2.5 identity

还要同时固定：

\[\operatorname{Spec}_{2.5} = ( \operatorname{Spec}_2, \text{old P3 proof schema}, \text{bridge AIR}, \text{Poseidon2 constants} ).\]

7.3 Plonky3 identity

\[\operatorname{Spec}_3 = ( \text{AIR code/layout}, \text{StarkConfig}, \text{PCS/MMCS}, \text{challenger}, \text{parameters}, \text{proof schema} ).\]

迁移时必须给新 spec 一个 versioned digest：

\[\operatorname{id}_3 = H( \operatorname{EncodeCanonical}( \operatorname{Spec}_3 ) ).\]

只复用旧 application 的字符串 “plonky2” 或 circuit 名称不能绑定新 proof semantics。

8. 递归模型对照

8.1 Plonky2

\[\pi_{2,i+1} \text{ proves } \mathsf{Verify}_{2}(\pi_{2,i})=1.\]

outer verifier 是 135-wire PLONKish circuit。

8.2 Plonky2.5

\[\pi_2 \text{ proves } \mathsf{Verify}_{3,\mathrm{old}}(\pi_3)=1.\]

是异构单向 wrapper。

8.3 current Plonky3 recursion

\[\pi_{3,i+1}^{\mathrm{batch}} \text{ proves } \mathsf{Verify}_{3}(\pi_{3,i})=1.\]

outer verifier program 被拆成 chips，由 LogUp 连接，再由 Batch-STARK 证明。

8.4 都不是 folding

三条都是 verifier-in-circuit recursive composition，不等同于 Nova：

\[(U_1,W_1),(U_2,W_2) \xrightarrow{\mathrm{fold}} (U',W').\]

不要把“聚合两个 proofs”与“线性 fold 两个 relaxed instances”混用。

9. Zero-knowledge 对照

9.1 Plonky2

standard_recursion_config：

\[\texttt{zero\_knowledge=false}.\]

必须显式使用 ZK config，并确认：

trace random rows；
hiding leaves/salts；
permutation blinding；
recursive layer 也启用 hiding。

9.2 Plonky2.5

inner 是否 ZK 与 outer 是否 ZK 是两个独立开关，但 wrapper ZK 不要求在所有接口下同时打开两者。若旧 Plonky3 proof/view 只作为 Plonky2 outer relation 的 private witness，并且只公开安全的 statement projection $\Phi$，则一个通用充分条件是：

\[\mathsf{ZK}_{2} \land \mathsf{Private}(\operatorname{View}_{3,\mathrm{old}}) \land \mathsf{SafeProjection}(\Phi) \Longrightarrow \mathsf{ZK}_{2.5\text{-wrapper}}.\]

此时 inner proof 自身不必是 ZK，因为外界看不到它。若 inner proof/transcript 被独立发布或直接映射进 outer public inputs，则需额外证明其暴露 view 的 ZK：

\[\mathsf{ZK}_{3,\mathrm{old,exposed}} \land \mathsf{ZK}_{2} \land \mathsf{SafeProjection}(\Phi) \Longrightarrow \mathsf{ZK}_{\mathrm{visible\ stack}}.\]

QED demo 的 outer config 默认非 ZK，所以它不满足第一条充分条件，也不应仅凭项目名称被称为 production zero-knowledge wrapper。迁移时还必须核对 inner proof 是否真的保持 private，以及 $\Phi$ 究竟公开了哪些 commitments、evaluations 与 statement fields。

9.3 Plonky3

ZK 是 Pcs::ZK / backend property，proof shape 会增加：

randomized trace domain；
hiding MMCS data；
random polynomial commitment/opening；
相应 transcript checks。

原生 recursion 还要让 outer circuit Batch-STARK 使用 ZK backend。

9.4 migration 的隐私测试

不能只比较：

\[\mathsf{Verify}_2(\pi_2) = \mathsf{Verify}_3(\pi_3).\]

还要比较泄露面：

\[\operatorname{View}_2 \stackrel{?}{\approx} \operatorname{View}_3.\]

至少审计：

public inputs 新旧差异；
proof size/shape metadata；
trace length；
lookup multiplicities；
preprocessed commitments；
aggregation tree shape；
error/timing side channels。

10. Soundness 口径对照

10.1 Plonky2

官方默认值面向约 100-bit conjectured security：

\[3\cdot28+16=100\]

是旧式 FRI heuristic。官方 README 还指出默认 Poseidon 参数可能约 95-bit。

10.2 Plonky2.5

整体 soundness 受最弱层限制：

\[\lambda_{2.5} \lesssim \min( \lambda_{\mathrm{oldP3}}, \lambda_{\mathrm{bridge}}, \lambda_{\mathrm{P2}}, \lambda_{\mathrm{hash}} ).\]

bridge circuit bug 不在 inner/outer proof system 的抽象 soundness theorem 内。

10.3 Plonky3

当前 security modules 把：

\[\begin{aligned} &\varepsilon_{\mathrm{ALI}}, \varepsilon_{\mathrm{DEEP}}, \varepsilon_{\mathrm{FRI}},\\ &\varepsilon_{\mathrm{batch}}, \varepsilon_{\mathrm{LogUp}}, \varepsilon_{\mathrm{collision}} \end{aligned}\]

纳入报告，并区分 conjectured/proven。

10.4 迁移不能只复制 queries

若从 Goldilocks degree-2 改为 BabyBear degree-4：

challenge field size 可能都接近 124–128 bit；
基础域大小不同；
trace max size/two-adicity 不同；
AIR constraint count/degree 不同；
batched functions/LogUp terms 不同；
hash collision security 不同。

所以旧参数：

\[(b=3,q=28,w=16)\]

不应直接成为新参数。

11. 性能不能用“代数代号”排序

不能普遍断言：

\[\text{Plonky3 一定比 Plonky2 快}\]

或反之。

性能是函数：

\[\operatorname{Cost} = f( \text{relation}, \text{field}, \text{AIR/gate layout}, \text{hash}, \text{PCS}, \text{security}, \text{ZK}, \text{hardware} ).\]

11.1 Plonky2 可能擅长

已优化的 Goldilocks arithmetic circuit；
width-12 Poseidon custom gate；
固定旧递归 proof；
已有 mature application gadgets。

11.2 Plonky3 可能擅长

31-bit SIMD packed fields；
zkVM/chip traces；
multi-table batch proving；
configurable hash/DFT；
current high-arity FRI/multi-proofs；
Circle/M31 或其他研究后端。

11.3 公平 benchmark 必须固定

\[\begin{aligned} &\text{同一 relation/statement},\\ &\text{同一 ZK 口径},\\ &\text{同一 proven/conjectured security},\\ &\text{同一机器与 CPU flags},\\ &\text{同一并行度/内存限制},\\ &\text{同一 recursion/aggregation depth}. \end{aligned}\]

12. 迁移第 0 步：冻结旧系统语义

在写新 AIR 前，先保存旧系统的：

12.1 protocol manifest

\[\begin{aligned} &\text{Plonky2 commit/toolchain},\\ &\text{CircuitConfig},\\ &\text{hash constants},\\ &\text{FRI params},\\ &\text{ZK flag},\\ &\text{serialization version}. \end{aligned}\]

12.2 circuit manifest

gate set 与 gate ids；
selector groups；
public-input schema；
circuit digest；
constants/$\sigma$ cap；
lookup tables；
recursion common data。

12.3 semantic test corpus

保存：

合法 witnesses/statements；
每条约束的故意破坏样例；
boundary range values；
serialization fixtures；
recursive/cyclic base cases；
aggregation ordering cases。

目标是形成 relation oracle：

\[\mathsf{Accept}_{\mathrm{old}}(x,w)\]

供新 AIR 差分测试。

13. 迁移第 1 步：重新设计 AIR/chips

13.1 列出 state transition

把旧 arithmetic DAG 重写为：

\[\mathbf s_{r+1} = F(\mathbf s_r,\mathbf u_r).\]

区分：

local row constraints；
transition constraints；
first/last boundaries；
public values；
tables/buses。

13.2 选择 chip 边界

按高频、规则性和 lookup 关系拆：

CPU/control；
arithmetic；
memory；
hash；
range/bitwise；
public/preprocessed。

过细会增加 bus interactions；过粗会让 trace 很宽、约束难 SIMD。

13.3 翻译 copy classes

对每个旧 copy constraint 问：

只是同一行 equality？
是相邻行 transition？
是跨 chip producer/consumer？
是否还包含顺序/唯一性？

前三类可分别变成：

local assert_eq；
next-row constraint；
LogUp bus。

第四类需要额外 AIR。

13.4 单一来源约束

尽量让：

  
Air::eval

成为 symbolic/prover/verifier 的单一来源，避免 Plonky2.5 式双份手写 drift。

14. 迁移第 2 步：选择 concrete Plonky3 config

14.1 field

根据：

trace length；
SIMD target；
extension soundness；
recursion support；
hash implementations

选择 Goldilocks、BabyBear、KoalaBear 或 M31/Circle。

14.2 PCS/domain

two-adic trace：TwoAdicFriPcs；
M31：CirclePcs；
multilinear relation：评估 WHIR/其他接口；
需要 ZK：选择相应 hiding backend。

14.3 hash/challenger

固定：

leaf hash；
compression；
challenger；
width/rate；
round constants；
serialization。

14.4 security report

对实际：

\[( N, d, m_c, c, n_{\mathrm{batched}}, r_{\mathrm{lookup}}, W_{\mathrm{lookup}} )\]

计算 proven 与 conjectured reports，记录 binding term，而不是只输出一个没有出处的 “100 bits”。

15. 迁移第 3 步：重新设计递归接口

15.1 不要让新 recursion 继承旧 proof schema

旧 Plonky2 recursion public inputs 可能是：

\[(\text{stateRoot},\text{batchHash},\text{cyclicVK}).\]

新 Plonky3 recursion 应定义 versioned schema：

\[\operatorname{PI}_3 = ( \text{schemaVersion}, \text{appState}, \text{innerSpecId}, \text{aggregationRoot} ).\]

15.2 选择 native recursion

若目标是 current Plonky3，优先评估当前原生递归路径：

\[\pi_3 \to \text{fixed verifier circuit} \to \pi_3^{\mathrm{batch}}.\]

优势：

跟随 current proof structs；
Uni/Batch support；
LogUp/chip architecture；
ZK handling；
统一 aggregation API。

边界：

未审计；
active APIs；
fixed shapes；
backend support matrix 仍演进。

15.3 不要把 QED 2.5 当 current adapter

若直接喂入 current proof：

\[\pi_3^{2026}\]

QED bridge 不理解：

current structural transcript fields；
dynamic arities；
multi-proofs；
preprocessed/periodic columns；
randomization fields；
Batch-STARK/LogUp；
current extension/config types。

15.4 cyclic/base case

迁移旧 cyclic recursion 时，逐项重建：

verifier identity binding；
base/dummy proof；
state transition；
layer counter；
initial/final state；
public-input order。

不能只验证“上一 proof valid”而漏掉：

\[z_{i+1}=F(z_i,u_i).\]

16. 迁移第 4 步：差分证明与双轨运行

16.1 relation differential tests

对相同 $(x,w)$：

\[\mathsf{CheckCircuit}_{2}(x,w) \stackrel{?}{=} \mathsf{CheckAIR}_{3}(x,w).\]

包括：

random valid traces；
mutation testing；
every boundary；
malformed public-input length；
overflow/range edges；
lookup multiplicities。

16.2 proof differential tests

对合法实例：

\[\mathsf{Verify}_2(\pi_2,x)=1, \qquad \mathsf{Verify}_3(\pi_3,x)=1.\]

对每种篡改：

\[\mathsf{Verify}_2(\widetilde\pi_2,x)=0, \qquad \mathsf{Verify}_3(\widetilde\pi_3,x)=0.\]

不要求两种 proof bytes 相同；要求 application statement 相同。

16.3 双轨 production shadowing

可先：

旧系统仍是 authoritative；
新 prover shadow 生成 $\pi_3$；
独立 verifier 对比 statement/result；
记录性能、失败与资源；
达到审计/稳定门槛后切换。

16.4 cutover identifier

切换时必须让 consumer 能区分：

\[\texttt{P2-vOld} \quad\text{与}\quad \texttt{P3-vNew}.\]

不要让同一 RPC field 接受两种未经 domain separation 的 proof encoding。

17. Plonky2.5 在迁移中何时有意义

17.1 合理用途

学习 cross-verifier architecture；
验证保存的特定 2024 Plonky3 proof fixture；
做 Goldilocks/Poseidon2 in-circuit research；
原型演示异构 proof wrapping。

17.2 不合理用途

current Plonky3 通用 verifier；
无修改生产 bridge；
已审计递归层；
自动 public-statement binding；
自动 ZK wrapper；
Plonky2 到 Plonky3 的长期协议升级器。

17.3 如果确需 legacy bridge

应 fork 并固定：

\[(\text{inner producer commit}, \text{bridge commit}, \text{outer Plonky2 commit}).\]

然后：

加 exact proof-shape checks；
加 public values；
固定 AIR/config digest；
增加 transcript test vectors；
启用/分析 ZK；
独立审计。

这本质上是维护一条 frozen legacy protocol，不是跟随 current Plonky3。

18. 选型决策图

flowchart TB
    A{"已有系统还是新系统？"} -->|已有 Plonky2| B{"短期只维护还是主动迁移？"}
    A -->|新系统| C{"主要 workload"}
    B -->|短期维护| D["固定旧 commit/参数<br/>补安全与运维边界"]
    B -->|主动迁移| E["重新设计 AIR/chips<br/>不要追求 proof bytes 兼容"]
    C -->|zkVM / 多表状态机| F["优先评估 Plonky3<br/>Batch-STARK + LogUp"]
    C -->|已有 arithmetic circuit 生态| G["比较移植成本<br/>也可评估其他 PLONKish 系统"]
    C -->|M31/Circle 目标| H["评估 Circle PCS 路径"]
    E --> I{"需要递归？"}
    F --> I
    H --> I
    I -->|否| J["先完成 native proof 与安全报告"]
    I -->|是| K["评估 Plonky3-recursion<br/>注意未审计与 fixed shape"]
    K --> L{"需要验证 2024 old P3 fixture？"}
    L -->|是| M["QED 2.5 可作研究起点<br/>需 fork + 重审"]
    L -->|否| N["不要使用旧 2.5 bridge"]

19. 兼容性矩阵

表中“否”表示不能无适配直接互验，不表示理论上无法写新 wrapper。

producer proof	Plonky2 native verifier	QED 2.5 bridge	current P3 verifier	current P3 recursion
Plonky2 proof	是，同版本/config	outer 输出格式是 P2，但 bridge 目标不是验证 P2	否	否
QED demo old P3 proof	否	是，固定支持范围	通常否，schema 已演进	通常否，需 legacy adapter
current P3 Uni-STARK	否	否	是，同 config	支持目标路径，依 commit/config
current P3 Batch-STARK	否	否	是，同 config	支持目标路径，依 commit/config
current P3 Circle/WHIR variants	否	否	依具体 verifier/backend	依递归仓库当前 support matrix

“同 config”至少包括：

\[\text{field} +\text{extension} +\text{PCS} +\text{hash} +\text{params} +\text{schema}.\]

20. 上线前验收门槛

20.1 语义

新 AIR relation 有书面 specification；
old/new accept set 经过差分测试；
public-input mapping injective；
padding rows 不产生额外 witnesses；
lookup buses 全部平衡且无别名。

20.2 密码参数

记录 proven 与 conjectured reports；
记录 binding security term；
hash collision cap；
extension field 与 max trace length；
LogUp/batch extras；
recursion 层数的组合界。

20.3 实现

commit/lock/toolchain 可重现；
serialization fuzzing；
malformed proof 不造成未隔离 panic；
verifier resource limits；
SIMD/non-SIMD results 一致；
test fixtures versioned。

20.4 递归

native/circuit transcript challenge-by-challenge 相同；
verifier/AIR/config identity 公开绑定；
aggregation child order/domain separation；
base case；
ZK inner/outer；
shape lifting policy。

20.5 审计与运维

审计覆盖准确 commit；
审计后 delta review；
vulnerability response；
proof schema rollout/rollback；
old proof sunset policy。

21. 一个最小迁移 manifest

建议每个 proof artifact 伴随以下逻辑 manifest：

  
{
  "system": "p3-batch-stark",
  "schemaVersion": 1,
  "codeCommit": "pinned-commit",
  "airManifestHash": "0x...",
  "field": "koala-bear",
  "extensionDegree": 4,
  "domain": "two-adic",
  "pcs": "fri",
  "hash": "poseidon2-kb-w16",
  "zk": true,
  "friParameterSet": "prod-2026-01",
  "publicInputSchema": "state-transition-v3",
  "recursion": {
    "enabled": true,
    "verifierCircuitHash": "0x..."
  }
}

manifest 本身必须：

canonical encode；
被 application/verifier policy 固定；
必要时被 transcript 或 public statement digest 绑定。

它不是让 prover 自报参数后 verifier 全盘接受的配置文件。

22. 总结

最重要的关系是：

\[\boxed{ \begin{aligned} \text{Plonky2} &=\text{specific PLONKish+FRI system},\\ \text{QED Plonky2.5} &=\text{old P3 verifier encoded in P2},\\ \text{Plonky3} &=\text{modular PIOP/STARK toolkit},\\ \text{P3 recursion} &=\text{fixed verifier proven by P3 Batch-STARK}. \end{aligned} }\]

迁移不是“升级 crate major version”，而是 relation-preserving protocol replacement：

\[\boxed{ \mathcal R_2 \stackrel{\text{spec + tests}}{=} \mathcal R_3, }\]

同时重新固定：

\[\text{proof identity} +\text{public schema} +\text{security parameters} +\text{recursion semantics}.\]

23. 延伸阅读

上一篇：递归、累积与折叠
下一篇：系统对比、参数与安全清单
返回：总目录

zero-knowledge, stark

本文由作者按照 CC BY 4.0 进行授权