第3章 协议巡礼：从来回对话到一行证明

第3章 协议巡礼：从来回对话到一行证明

章节摘要：本章跟着一条工程化主线走——交互式协议优雅却低效，怎么把它变成"证明者丢下一份数据就走人、任何人事后可验"的形态？沿这条线，我们依次检阅交互式协议、Fiat-Shamir 变换、SNARK 家族与 STARK，最后给出一套可操作的选型判断。

一条主线

第 2 章收尾时留了个现实难题：交互式证明每验一次都要证明者在线陪玩，验证记录还不便转交。本章的整条主线就是解决它。想象一个商用场景的落差：协议理论已经完备，可你没法要求公证处每天派人和你对暗号五十轮。于是全部注意力集中到一个问题上——验证者的那把"随机骰子"，能不能在不牺牲不可预知性的前提下，由别的东西替代？答案将由哈希函数给出（Fiat-Shamir 变换）。骰子问题解决后，新的瓶颈立刻显形：证明尺寸与验证成本。于是又有两条技术路线接棒——把证明压到几百字节的 SNARK，与拒绝一切仪式的 STARK。本章就是沿着这条"瓶颈-解法-新瓶颈"的接力线跑完协议演化的全程。

沿途站点

站点一：交互式零知识协议。先给"陪玩时代"立一座碑：三拍结构如何在真实协议（三染色、哈密顿回路）里落地，交互性买到了什么（强零知识、无需任何额外假设之外的信任）、又输在哪里（在线、不可转交、验证成本与轮数挂钩）。配一段可以运行的哈希承诺版三染色演算。

站点二：Fiat-Shamir 与非交互化。把"验证者现场抛骰子"换成"对承诺做哈希导出挑战"，对话塌缩成一条静态记录。这一步的微妙之处在于安全论证从标准模型搬进了随机预言机模型，本节会讲清变换为什么可信、哪些实现错误会把它做坏（上下文缺失、可操纵输入、grinding 攻击）。

站点三：SNARK 家族与选型。Groth16 的极小证明、Plonk 的通用设置、Halo2 的免设置递归、Bulletproofs 的免仪式范围证明——四张面孔对应四种工程性格。本节用一张多维对比矩阵与一段证明成本测算，把"选型"从背参数变成查账。

站点四：STARK 透明证明。另一条路线干脆不碰椭圆曲线配对：全哈希构建、无需任何可信仪式、天然抗量子，代价是证明大到几十上百 KB。低度扩展与 FRI 折叠是它的发动机，本节用小规模演算演示"低次多项式为什么骗不了抽查"。

拐点与结论

本章最大的认知拐点是：非交互化不是把交互删掉，而是把交互的随机性委托给哈希函数。理解了这一点，SNARK 与 STARK 的所有差异都退居工程层面——它们同样生活在"算术化 + 多项式 + 抽查"的世界里，分歧只在承诺工具与信任来源。第二个拐点是"信任预算"概念的引入：任何方案都要么消耗一次可信仪式（SNARK 系），要么消耗更大的证明带宽（STARK 系），不存在的选项是"既不花钱又不占带宽"。把这两条带进第 4 章，积木的组装方式会一目了然。

本章常见疑问

**四个站点的依赖关系是什么？**站点一是公共地基，必读；站点二的哈希折叠思想是站点三、四的共同前提；站点三与站点四相互独立，可以按兴趣任选先后，但都在读完站点二之后再进入。

**选型结论能不能直接抄？**第 3 站的对账表可以直接用作会议材料，但"结论方向"那几行是示例业务下的答案——你的业务参数（电路规模、验证拓扑、合规要求）填进对账演算后，结论可能不同。工具是表格本身，不是表格里的示例数字。

**每章代码建议都跑吗？**Fiat-Shamir 一节（站点二）的 Schnorr 签名实现强烈建议跑一遍——它是全册被引用次数最多的演算；其余按需。所有代码都是纯标准库，任意 Python 环境可直接运行。

读完你应该

• 说出交互性换来的三样东西与付出的三样代价；
• 手工执行一次 Fiat-Shamir 折叠，并解释随机预言机模型在论证中的角色；
• 对任一具体业务给出 SNARK 内部的方案初选，理由落到证明大小、验证成本、仪式与假设四项；
• 解释低度扩展与 FRI 折叠如何让抽查成为可能；
• 指出 STARK 证明偏大的根本原因，并判断何时这个代价值得付。

下一章的接力

协议看完了，第 4 章钻进道具箱：这一章出现过的每个名词——承诺、多项式、算术化、仪式——都会被拆开重造一遍，你会看到它们的内部构造与失误代价。