三种角色
这三类角色不是“组织分工”，而是系统里必然出现的三段责任链。只要你在做 ZK 证明，就一定会碰到它们，即使你在一个团队里把它们都包了。角色分清楚了，排错会快很多。
先把三类角色直观列出来：
- Producer：定义电路/程序，并产出可用的 vk
- Prover：拿到私有输入并生成 proof
- Verifier：验证 proof 是否有效
先讲 Producer。它负责写电路/程序，并定义可用的 vk。你可以把它理解成“验收标准的制定方”，因为后续的验证都以它为准。现实里 Producer 可能是你自己，也可能是第三方电路作者，但系统里一定有这个角色。
再讲 Prover。它负责拿到私有输入并生成 proof。Prover 通常在客户端或用户侧，因为私有输入不应该上链。工程上你会看到证明生成在链下完成，并且耗时和算力成本比较明显。
最后是 Verifier。它拿到 proof 与公开材料来判断真伪。zkVerify 在这里扮演 Verifier 角色，但它不是唯一可能的 Verifier。只要系统里存在“验证证明是否有效”的步骤，这个角色就存在。
一个实用的类比是质检流水线：Producer 负责定义规格，Prover 负责生产符合规格的样本，Verifier 负责抽检并给出结论。如果你把检验规则搞错，后面的结论再“通过”也没有意义。
如果你更习惯从“我现在在做什么”来判断，可以用下面这个简化流程对照：
- 选电路、生成 vk → 你正在执行 Producer 的职责
- 准备私有输入、产出 proof → 你在执行 Prover 的职责
- 验证 proof 的真伪 → 你在执行 Verifier 的职责
也可以用问答来快速辨认当前角色：
Q: 我是在定义验证标准还是在跑证明？ A: 定义标准的是 Producer，跑证明的是 Prover。
Q: 我是在产出 proof 还是在判断 proof 对不对？ A: 产出的是 Prover，判断的是 Verifier。
⚠️ 注意：如果你把 Producer 当成 Prover 去理解，最常见的后果是 vk 和 proof 来自不同版本的电路，验证会一直失败，但你会误以为链上出了问题。
这一节的核心是让你在系统里“分清责任链”。下一节会把五步管线拆开，让你能把每个角色映射到具体的输入输出。