在以太坊上做零知识验证，历史上只有一扇门：地址 0x06 到 0x08 的三个 BN254 预编译，供 ecAdd、ecMul 与配对检查。问题是这条曲线的安全参数——提案原文直说：BN254 预编译只提供约 80 比特的安全强度，而配对友好曲线家族里早就存在能提供 120 比特以上安全的选择。EIP-2539 因此提出给 EVM 增加 BLS12-377 的运算预编译，2020 年 2 月 26 日创建，依赖配对框架类提案 EIP-1109 与静态调用降价的 EIP-2046，如今状态是 Stagnant（停滞）。
BLS12-377 是谁家孩子
这条曲线出自 Zexe 那篇可组合证明系统的论文，是 BLS12 家族的成员——形如 y² = x³ + b 的极简方程（家族系数 A 恒为零），好处在配对与证明系统里的表现：它让「在 EVM 里验证一个 BLS12-377 上的配对等式」成为可能，也让关于这条曲线证明的递归证明更小。动机段列了三个理由：配对曲线上的 120 比特以上安全、对 BN254 的 80 比特是量级升级；一次性递归聚合证明（比如证明「存在某个 377 曲线上的签名」）可以高效进行；未来恒定大小的 BLS 聚合签名验证有了落点。它与 2537 提案（BLS12-381 预编译）是同一思想的两条曲线——381 那条后来随 Pectra 上线了主网，377 这条停在原地。
编码与 ABI 的三处设计
规范文本值得抄三处细节。点编码：G1 的点用仿射坐标 x、y 各 64 字节拼接，共 128 字节；G2 的点在二次扩张域上，坐标各翻倍，共 256 字节。无穷远点（零元）：BLS12 曲线上的点 (0,0) 并不在曲线上，于是编码约定把它征用为「零点」表示。多标量乘单独开 ABI：与其让调用方自己循环几百次 ecMul 预编译（每多一次调用都要付一次 CALL 开销），不如一个入口吃进全部点与标量，用 Pippenger 类算法一次算完——提案估算百点规模能省下十万量级以上的 gas。这些选择处处透露气质：这不是一条给普通合约用的曲线，是给证明系统装的服务接口。
为什么它停在那里
密码学提案的墓地由评审问题填满，2539 也不例外。选 377 而不选 381 的论证没有服众：381 有更长的部署历史和更标准化的实现，当 EIP-2537 在 2025 年随 Pectra 落地，377 的存在理由被进一步抽薄——同一条 EVM 是否需要两条 BLS 曲线，答案倾向于否。曲线本身的参数生成也非免检：BLS12-377 的模数与子群结构可审计，但「谁的曲线生成仪式可信」在 2020 年仍是争论点。于是这份提案进入低维护轨道：文件保留、状态标 Stagnant，等待一个想复活它的人。对读者的实用结论很简单：今天想在合约里验证 BLS 签名，答案是 2537 与 381 曲线；提到 377 时，它是「被评审淘汰的备选」，不是「即将上线的新功能」。
一份选型清单
假想你是要在链上验证证明的开发者，把三条路线摆开：BN254 预编译成熟、便宜，但安全参数偏旧；BLS12-381 预编译已上线，签名聚合与主流证明栈兼容度最高；BLS12-377 在证明递归尺寸上有账面优势，但链上没有入口。清单最后一行决定了它进入提案而非产品文档的命运。密码学组件的选型从来如此：不是问哪条曲线数学上更美，而是问哪条曲线同时有可审计的参数生成、被审计过的实现、以及生态里足够的验证案例。2539 停在 Stagnant 不是败给技术，是败给「另一条曲线先到了」这个最普通的工程现实。
快速问答
问：BLS12-377 现在能在以太坊合约里用吗？ 答：不能直接用。EVM 里没有它的预编译，链下生成、链上用其他曲线验证的桥接方式都不等于曲线本身进了 EVM。
问：它和 EIP-2537 的 381 是什么关系？ 答：同一家族的两条实例化曲线，预编译设计相互参照；381 已随 Pectra 激活，377 停留在 Stagnant。
问：80 比特到 120 比特意味着什么？ 答：攻击所需工作量的对数刻度——120 比特意味着暴力搜索代价再乘约 2 的 40 次方。具体安全评估以密码学文献为准。
风险提示
本文为密码学机制解读，不构成投资建议。曲线与算法的安全结论随研究演进可能变化，协议集成决策请以专业审计与最新规范为准。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。