一台服务器声称算完了一个天文数字规模的表格，并告诉你所有格子的总和是某个数。客户端不想也不该重算整个表——那样验证的成本和重算一样，证明就失去了意义。sum-check 协议回答的正是这类问题：能不能把『求和一亿亿个数』的证明，压缩成验证者只读几个点、做几次抽查就能完成的对话？Lund、Fortnow、Karloff 和 Nisan 在 1992 年的论文给出了肯定答案，这个协议后来成了可验证计算领域最常被复用的积木，GKR 电路证明、多数现代交互式论证的地基里都能看到它。
把求和改写成多项式游戏
协议的魔法发生在翻译那一步。要把一张定义在超立方体顶点上的函数 g 的所有取值求和，先把 g 多线性扩展成一个多项式：它把原表忠实嵌进去，同时允许变量离开 0 和 1 取值。求和本身被改写成一串嵌套的分组求和——先把第一个变量设成 0 和 1 时各自剩下的格子加总，再对第二个变量分组，如此一层层剥。协议按层进行：证明方每轮提交一个单变量多项式，声称它就是当前层对某个随机点的部分求和结果；验证者检查相邻两轮的连续性（上一轮多项式在 0 和 1 处相加是否等于本轮声称值），再抛一个随机点要求下一轮在那个点上继续。v 个变量就 v 轮，最终验证者只需在随机一点上直接计算多项式——如果证明方在某一轮撒谎，由于低次多项式与真实函数的差异点稀疏，被随机点撞破的概率极高。这就是整套协议的核心账本：把全域检查换成随机抽查，用 Schwartz-Zippel 式的直觉把作弊概率压到可忽略。
GKR：给电路的每一层装上求和
求和验证本身听起来离『证明程序执行正确』很远。Goldwasser、Tauman-Kalai 和 Rothblum 的 GKR 构造搭了这座桥：把一个计算电路的每一层门函数表示成低次多元多项式，声称的输出满足一个逐层的恒等式——第 i 层的值等于用第 i+1 层值和该层门结构算出来的求和式。自顶向下逐层运行 sum-check，验证者从声称的输出出发，一路把信任需求压到底层的输入上，而底层输入本来就可以用普通承诺核对。整个证明的验证者开销只有对数级，证明方只需在本地算多项式的部分和——这『对数验证者』的性能曲线是 GKR 系协议在委托计算、折叠方案、数据库完整性里反复出场的根本原因。
从协议到工业积木
现代证明系统里，sum-check 的角色更像标准件而非整机。多线性承诺配 sum-check 的论证族把证明拆成若干轮并行、可流式生成的子协议；折叠方案（如 HyperPlonk 一族）用它验证约束求和；数据库完整性协议用扫描协议加 sum-check 的组合把表查询证明成常数轮。值得注意的是它的默认姿势：标准 sum-check 本身不隐藏任何信息，证明方发的每个多项式都暴露了对函数的部分聚合，零知识版本需要额外轮次的遮蔽承诺——隐私不是白拿的，每一层隐藏都要付轮数或多项式大小的代价。把 sum-check 直接当『零知识证明』的宣传来理解，几乎必然是误会。
随机点从哪来才诚实
交互式版本里验证者的随机点由验证者现场抛出；现实部署几乎都用 Fiat-Shamir 把对话非交互化——把验证者随机数替换成对已发证明的承诺哈希。这个替换在随机 oracle 模型下顺手，但对轮数敏感协议的归约并不总像教科书说的那般便宜：近年多轮 Fiat-Shamir 的安全归约被反复审计，部分构造发现比预期弱。工程判断上，把非交互化视为需要单独审计的密码学决策、而不是配置文件里的一行开关，是读任何证明系统白皮书时都带得走的纪律。
快速问答
sum-check 验证者到底算了多少东西？它每轮只做常数次多项式求值和一次连续性检查，总开销与变量数成正比、与表格大小无关——这正是协议的存在理由。
和可信设置有什么关系？纯 sum-check 论证一般不需要可信设置；只有当它和多项式承诺组合、且承诺方案需要初始化时，整个系统才继承那个前提。
风险提示：本文仅作密码学机制科普，不构成任何投资建议，也不对任何具体证明系统做安全性背书。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。