KZG 多项式承诺的曲线基础及其协议应用

Reading: KZG turns polynomial objects into deployable commitments.

到 ECC 子系列的最后一篇，问题已经收缩得很具体了。前面几篇分别回答了 why not one curve、账户层为什么停在 secp256k1、pairing-friendly curves 为什么进入 verifier、以及 Ethereum 为什么在 BN254 与 BLS12-381 之间形成长期工程张力。到了 EIP-4844，pairing-friendly curve 不再只是 verifier 的数学背景，而是直接进入 data-availability commitment workflow。

这里真正要理解的，不是“BLS12-381 为什么常出现”，而是“KZG commitments 为什么会自然进入 blob workflow”。如果一个协议只需要对数据做普通哈希承诺，那么 pairing-friendly curve 完全可以不出现；但如果协议既想对多项式对象做常数大小承诺，又想对某个 evaluation claim 给出紧凑 opening proof，那么 verifier 最终就会落到 pairing equation 上，而这也是 KZG commitments and opening proofs rely on pairing-friendly curves 的根本原因。^{1 2}

所以这一篇的顺序会比“直接讲 blob”更慢半步：先定义 polynomial commitment object，再写 minimal KZG opening verification equation，随后把这个对象映射到 EIP-4844 blobs 的 commitment / proof / verification workflow，最后把 trusted setup 从尾注抬成 first-class protocol constraint，并在文末给出工程实现对接。

Quick Note. This article explains why KZG commitments and opening proofs rely on pairing-friendly curves. It also gives the minimal KZG opening verification equation, shows the role of BLS12-381 in modern Ethereum data-availability commitments, maps the polynomial commitment object to the blob-commitment workflow in EIP-4844, and makes trusted setup a first-class protocol constraint rather than an afterthought.

为什么 KZG 会进入 EIP-4844

如果把 EIP-4844 blobs 理解成“链上多了一种大数据对象”，会漏掉关键点。EIP-4844 真正要解决的不是把字节串丢进链里，而是让协议能够围绕这些数据对象建立可验证、可传递、可压缩的承诺接口。

这就是为什么 blob 不是普通哈希承诺。哈希可以证明“这个字节串对应这个 digest”，但它不直接提供多项式 evaluation claim 的紧凑 opening structure。KZG 则不同：它把一个多项式对象压成常数大小 commitment，同时允许 prover 对“在点 $z$ 处，值是否为 $y$”这类 claim 给出紧凑证明。

于是 BLS12-381 在 modern Ethereum data-availability commitments 里的角色就变得具体了：它不是“某条大家现在更喜欢的曲线”，而是 KZG verifier 需要的 pairing-friendly setting 的工作曲线。

Formal Object：KZG commitments

structured reference string

KZG 的起点不是消息，而是多项式 $f(X)$。为了对它做 commitment，协议首先需要一个 structured reference string。最小语境下，可以把它理解成某个隐藏标量 $\tau$ 诱导出来的一组群元素，例如

$$ g_1, g_1^{\tau}, g_1^{\tau^2}, \ldots $$

以及配套的目标群侧对象。这里已经出现了本文必须单独抬出来的约束：trusted setup。因为 commitment object 不是从空气中长出来的，它依赖一个结构化参考字符串，而这正是 KZG 和普通无结构承诺的根本区别。

多项式承诺与 opening claim

对多项式 $f(X)$，KZG commitment 可以压成

$$ C = g_1^{f(\tau)}. $$

这就是 KZG commitments 的最小对象。接下来，如果 prover 想证明

$$ f(z) = y, $$

那么它需要给出一个 opening proof $\pi$，使 verifier 不必知道整个 $f(X)$，也不必看到 $f(\tau)$ 的秘密结构，就能检查这个 claim 是否成立。

minimal KZG opening verification equation

商多项式视角

KZG opening proof 的关键在于商多项式

$$ q(X)=\frac{f(X)-y}{X-z}. $$

这个对象存在的前提正是 $f(z)=y$。如果 claim 为真，那么 $f(X)-y$ 可以被 $(X-z)$ 整除，于是 prover 可以围绕 $q(X)$ 构造证明对象。

pairing verification 形状

This section gives the minimal KZG opening verification equation.

在最小形状下，verifier 要检查的是

$$ e(C / g_1^y, g_2) \stackrel{?}= e(\pi, g_2^{\tau-z}). $$

这就是 minimal KZG opening verification equation。

一旦这条式子出现，为什么 KZG commitments and opening proofs rely on pairing-friendly curves 就已经不需要再靠口号解释了。左边编码的是 commitment 与 claimed value 的差，右边编码的是商多项式与结构化参考字符串的关系。verifier 真正比较的，不再是普通群里的签名等式，而是 pairing equation。

从 polynomial commitment object 到 blob workflow

blob commitment、proof 与 verifier

This section gives the mapping from polynomial commitment object to blob-commitment workflow in EIP-4844.

把抽象对象压到 blob-commitment workflow in EIP-4844，可以得到下面这张表：

KZG 对象	协议角色	EIP-4844 语境
多项式 $f(X)$	被承诺的数据对象	blob 对应的数据多项式表示
commitment $C$	常数大小承诺	blob commitment
evaluation claim $(z, y)$	想验证的点值关系	某个 opening query
proof $\pi$	opening proof	blob verification proof
pairing verifier	检查 claim 是否成立	共识/验证流程中的 KZG verification

这张表后面的关键结论是：EIP-4844 不是“先发明了 blob，再随手挑了 KZG”；而是 data-availability commitment workflow 需要一个既能紧凑承诺多项式对象、又能紧凑验证 opening claim 的接口，而 KZG 正好提供了这组对象。

BLS12-381 在工作流里的角色

BLS12-381 在这里的角色非常直接：它提供 KZG verifier 所依赖的 pairing-friendly setting。换句话说，curve choice 不是外围实现细节，而是 commitment object 能否被实际验证的一部分。

这也是为什么上一章的 Ethereum 曲线演化不能单独看。BLS12-381 在 modern Ethereum data-availability commitments 中的重要性，不是因为它“流行”，而是因为 blob commitment 和 opening proof 的 verifier 最终消费的就是这一类 pairing-friendly curve interface。

trusted setup 不是尾注

为什么 setup 在 KZG 里是结构性约束

很多工程叙事会把 trusted setup 写成“当然还有个 ceremony”。这种写法太轻。更准确的说法是：在 KZG 里，setup assumptions 是 commitment object 的一部分。如果结构化参考字符串的生成过程不可信，那么整个安全边界都会被污染。

This article makes trusted setup a first-class protocol constraint rather than an afterthought.

也就是说，trusted setup 不是 KZG 旁边的行政手续，而是协议本体的一部分。它和 pairing-friendly curve 一样，都是 verifier interface 的组成条件。

工程师该如何理解 toxic waste 风险

如果用工程语言重写这个问题，真正需要问的是：

• setup ceremony 的假设是什么
• 哪些对象必须被销毁或不可恢复
• library 和 integration 是否默认了 setup 输入永远可信

只要这些前提没有被明确写进协议和实现边界里，KZG integration 就是不完整的。

工程实现对接

library boundary 与 serialization

现实系统里最先会出问题的，通常不是 pairing 公式写错，而是 object boundary 不清：

• commitment、proof 和 evaluation input 的 serialization 是否一致
• library 是否把 BLS12-381 群对象与 KZG object 清晰分开
• verifier 调用方是否明确知道哪些输入已经做 subgroup checks

这些看起来像实现细节，但实际上直接决定 blob verification integration 是否可靠。

blob-verification integration

对协议工程师来说，blob-verification integration 真正要关心的是：在哪一层消费 commitment、在哪一层消费 opening proof、哪一段系统承担 verification，以及 setup assumptions 是否被正确继承到运行环境里。

如果这些接线位置不清，系统很容易退化成“数学对象是对的，部署对象是糊的”。这也是为什么 KZG 的工程实现对接必须同时包含：

• 曲线与 pairing library 边界
• setup ceremony 假设
• serialization 与 proof object 约束
• verifier workflow 的责任划分

作为 ECC 子系列的收尾

到这里，ECC 子系列实际上收束成了一条很稳定的判断线：

• 账户层问题先问普通离散对数群接口
• verifier compression 问 pairing-friendly curve
• 进入 Ethereum 工程现实后，再问 precompile、gas、deployment friction
• 进入 KZG / blob workflow 后，再把 trusted setup 和 object boundary 拉回主轴

也就是说，曲线从来不是孤立选型，而是协议接口、实现边界和部署现实的交点。

总结

KZG 之所以会成为 EIP-4844 blob workflow 的核心，不是因为它“先进”，而是因为它把 polynomial commitment object 和 opening proof 压成了实际可消费的 verifier interface。于是 pairing-friendly curve 在这里不再是背景知识，而是 commitment / proof / verification 整条链上的工作曲线。

因此这一篇最想固定下来的判断线是：如果协议要对多项式对象做紧凑承诺，并对 evaluation claim 做紧凑验证，那么 KZG 会自然进入画面；而一旦 KZG 进入画面，BLS12-381 与 trusted setup 也就不再是可选注释，而是协议主轴本身。

作为 ECC 子系列收尾，这也把前面 6 篇连成了一条线：不同曲线不是被“偏好”出来的，而是被账户接口、verifier compression、Ethereum execution surface 和 deployment constraints 一起推出来的。