https://galoishlee.github.io/tags/blob/ Recent content in Blob on As it was Hugo zh-CN maocred@gmail.com (Halois) maocred@gmail.com (Halois) This work is licensed under a Creative Commons Attribution-NonCommercial 4.0 International License. Tue, 16 Dec 2025 08:00:00 +0800 https://galoishlee.github.io/kzg-bls12-381-eip-4844/ Tue, 16 Dec 2025 08:00:00 +0800maocred@gmail.com (Halois) https://galoishlee.github.io/kzg-bls12-381-eip-4844/ <blockquote> <p>Reading: KZG turns polynomial objects into deployable commitments.</p> </blockquote> <p>到 ECC 子系列的最后一篇，问题已经收缩得很具体了。前面几篇分别回答了 why not one curve、账户层为什么停在 secp256k1、pairing-friendly curves 为什么进入 verifier、以及 Ethereum 为什么在 BN254 与 BLS12-381 之间形成长期工程张力。到了 EIP-4844，pairing-friendly curve 不再只是 verifier 的数学背景，而是直接进入 data-availability commitment workflow。</p> <p>这里真正要理解的，不是“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 的根本原因。<sup id="fnref:1"><a href="#fn:1" class="footnote-ref" role="doc-noteref">1</a></sup> <sup id="fnref:2"><a href="#fn:2" class="footnote-ref" role="doc-noteref">2</a></sup></p> <p>所以这一篇的顺序会比“直接讲 blob”更慢半步：先定义 polynomial commitment object，再写 minimal KZG opening verification equation，随后把这个对象映射到 <code>EIP-4844 blobs</code> 的 commitment / proof / verification workflow，最后把 <code>trusted setup</code> 从尾注抬成 first-class protocol constraint，并在文末给出工程实现对接。</p> <blockquote> <p>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.</p> </blockquote>