Web3 语境下椭圆曲线密码学的系统分工

Scope. 这是一张系统职责图。签名机制、pairing 安全边界、Ethereum precompile 历史和 KZG/blob 工作流分别由后续五篇展开。

Web3 同时使用 secp256k1、BN254 和 BLS12-381，原因来自验证接口和部署环境。账户签名消费普通椭圆曲线群；BLS、部分 SNARK verifier 与 KZG 消费双线性映射；链上协议还受 precompile ABI 和 gas 定价约束。

截至 2026-08-08，Ethereum 的能力表已经包含 Pectra 后的 EIP-2537。BLS12-381 在执行层仍有采用和工具链成本；把“缺少主网 precompile”列为阻碍已经过时。

两类验证接口

普通椭圆曲线群

ECDSA 和 Schnorr 等签名最终检查群加法与标量乘关系。抽象地看，verifier 组合公开标量与群元素：

\[ uG+vP. \]

这类接口不要求目标群或双线性映射。账户层的核心约束来自签名规范、nonce、编码、常数时间实现和密钥管理。

Pairing-Friendly 接口

pairing-based 协议把源群关系搬到目标群中，常见验证形状为

\[ \prod_{i=1}^{k}e(P_i,Q_i)=1. \]

BLS 签名、Groth16 等 verifier 和 KZG openings 以不同方式消费这个接口。相同的 pairing product 形状不代表它们共享 setup、安全证明或消息语义。

三条曲线的职责图

曲线	主要接口	Web3 中的职责	Ethereum 执行层现状	首要审计边界
secp256k1	普通离散对数群	Bitcoin 签名；Ethereum EOA/ECDSA	ecrecover 等既有接口	nonce、low-s、编码、constant-time
BN254 / alt_bn128	pairing-friendly	历史 Groth16 与链上 pairing verifier	EIP-196/197 precompiles；EIP-1108 已 repricing	ABI、subgroup、gas、安全 margin
BLS12-381	pairing-friendly	共识 BLS、EIP-4844 KZG、现代 pairing 协议	EIP-2537 七个 precompiles 已随 Pectra 激活	subgroup、serialization、PoP、SRS、协议域分离

表中的“主要接口”只描述曲线提供的代数能力。具体协议仍决定 proof format、trusted setup、hash-to-curve、message binding 和验证方程。

secp256k1：账户签名职责

Bitcoin 与 Ethereum 的账户体系长期消费 secp256k1。部署深度体现在硬件钱包、密钥派生、签名 API、libsecp256k1、BIP-340 和 Ethereum 的地址恢复语义中。^{1 2 3}

同一条曲线可以承载 ECDSA 与 Schnorr；两种机制的 malleability、批量验证和多签组合性质不同。下一篇负责这些方程和工程边界，本篇只保留选型结论：账户层需要成熟的签名群与实现生态，pairing 不在该接口的必要条件中。

BN254：历史链上 Verifier 职责

EIP-196 暴露 BN254 加法与标量乘，EIP-197 暴露 pairing check。EIP-1108 随后降低这些 precompiles 的 gas。三项变化共同建立了早期链上 zkSNARK verifier 的现实入口。^{4 5 6}

BN254 的长期存在来自已部署 verifier、现有 proving stacks 与可用 gas 接口。EIP-2537 的动机将现有 BN254 precompile 的安全级别概括为约 80 bits，而 BLS12-381 提供 120+ bits；这个差距形成升级压力，却不会自动迁移历史合约和 proving keys。⁷

BLS12-381：共识、KZG 与通用 Precompile

BLS12-381 同时出现在三类基础设施中：

• Ethereum 共识层的 BLS signatures；
• EIP-4844 blob commitments 与 point-evaluation verification；⁸
• 需要 BLS12-381 group/MSM/pairing/map-to-curve 运算的执行层协议。

Pectra 于 2025-05-07 在 Ethereum 主网激活。EIP-2537 随之加入地址 0x0b 到 0x11 的七个 precompiles：G1/G2 addition、G1/G2 MSM、pairing check、Fp-to-G1 和 Fp2-to-G2 mapping。^{9 7}

EIP-2537 的 mapping precompiles 只接收 field element，不负责把任意 byte string hash 到 field。G1/G2 addition 不做 subgroup check，MSM 与 pairing 必须做 subgroup check。协议实现要按具体 ABI 分配这些职责，不能把“precompile 已上线”理解为 BLS 或 KZG 验证逻辑已经自动完成。

Trusted Setup 属于协议层

曲线提供群与 pairing；trusted setup 由协议构造引入。几个组合可以直接说明边界：

曲线/协议	是否 pairing-friendly	是否需要 structured setup
BLS12-381 + BLS signatures	是	否
BLS12-381 + KZG	是	是
BN254 + Groth16	是	是，且 circuit-specific
secp256k1 + Schnorr	否	否

因此，SRS 来源、toxic waste 与 ceremony 审计属于 KZG/Groth16 的协议风险，不能记在曲线属性下。

四个选型问题

验证器需要 Pairing 吗

账户签名和普通公钥关系通常只需要群运算。聚合 BLS、KZG opening 或 pairing-based SNARK verifier 才要求双线性接口。

代码运行在哪一层

同一运算在 consensus client、execution precompile、Solidity contract 和 off-chain prover 中有不同 ABI、资源模型与升级路径。曲线名称相同，边界条件仍可能完全不同。

当前接口的 Gas 与输入规则是什么

链上 verifier 要核对地址、输入长度、字节序、infinity 编码、subgroup checks、失败时 gas 行为和调用成本。EIP-2537 上线消除了“完全没有接口”的缺口，没有消除这些检查。

协议还引入了哪些状态

BLS 聚合要声明 rogue-key 防护、proof of possession 与 message distinctness。KZG 要声明 SRS、blob 编码、versioned hash 和 point-evaluation proof。Groth16 要声明 circuit-specific verifying key。曲线选型只完成了第一层。

后续文章分工

1. secp256k1 的协议定位与签名机制：ECDSA、Schnorr、nonce 与编码。
2. 从 ECDLP 到 HNP、EC-HNP 与 EHNP：nonce leakage 到格问题。
3. Pairing-Friendly Curves 的数学结构与协议动机：bilinearity 与 BLS 安全边界。
4. Ethereum 中配对友好曲线的演化路径：EIP-196/197/1108/2537、ABI 与 gas。
5. KZG、BLS12-381 与 EIP-4844：精确 blob commitment workflow。

Summary

• secp256k1 承担账户签名职责。
• BN254 仍是历史链上 pairing verifier 的重要接口。
• BLS12-381 服务共识 BLS、KZG/blob 和 Pectra 后的通用执行层曲线运算。
• trusted setup、rogue-key 防护与 blob 绑定都属于协议层。
• 选型需要同时检查代数接口、运行层、ABI/gas 和协议附加状态。

References