# Pairing-Friendly Curves：双线性接口与 BLS 聚合边界 > Scope. 本文负责 pairing properties 与 BLS aggregate-signature security。Groth16 pairing equation 已由第 6 篇展开，KZG opening 与 blob workflow 留给第 16 篇。 pairing-friendly curve 为协议提供两个源群和一个目标群。双线性可以压缩验证关系，也会把 point validation、subgroup、hash-to-curve 和 rogue-key 防护带进 verifier boundary。 ## 最小 Pairing 接口 设 \(G_1,G_2,G_T\) 为阶为素数 \(r\) 的循环群，协议使用可高效计算的映射 \[ e:G_1\times G_2\longrightarrow G_T. \] 它满足双线性 \[ e(aP,bQ)=e(P,Q)^{ab}, \] 以及 non-degeneracy：对生成元 \(P,Q\)，\(e(P,Q)\ne1\)。目标群乘法让 verifier 合并多项源群关系： \[ \prod_{i=1}^{k}e(P_i,Q_i)=1_{G_T}. \] “少数 pairing checks”仍可能包含多个 Miller loops、final exponentiation 和昂贵输入验证。compression 描述 proof/verifier interface，不等同于低执行成本。 ## BLS 单签名方程 以下采用 signature in G1、public key in G2 的记号。私钥 \(x\in\mathbb F_r^*\)，公钥与签名为 \[ X=xG_2, \qquad \sigma=xH(m), \] 其中 \(H\) 是指定 ciphersuite 的 hash-to-curve。verifier 检查 \[ e(\sigma,G_2)=e(H(m),X). \] 双线性给出 completeness： \[ e(xH(m),G_2)=e(H(m),xG_2). \] 这条方程只说明正确签名会通过。完整验证还要检查公钥和签名编码、non-identity、curve membership、subgroup membership，以及 hash-to-curve ciphersuite 和 DST。 ## 聚合签名与 Rogue-Key Attack 对 \(n\) 份签名，aggregate signature 为 \[ \sigma_{\mathrm{agg}}=\sum_{i=1}^{n}\sigma_i. \] 若消息彼此不同，可以检查 \[ e(\sigma_{\mathrm{agg}},G_2) =\prod_{i=1}^{n}e(H(m_i),X_i). \] 同消息快速聚合常把公钥也相加： \[ e(\sigma_{\mathrm{agg}},G_2) =e(H(m),\sum_iX_i). \] 第二个等式在开放注册环境中面临 rogue-key attack。攻击者看到诚实公钥 \(X_1\) 后，可以选择与它相关的公钥，例如 \(X_2=x_2G_2-X_1\)，使 aggregate key 等于 \(x_2G_2\)。攻击者随后只用 \(x_2\) 生成一份签名，却让等式看起来包含两个参与者。 pairing equation 无法识别“公钥是否由独立 secret key 产生”。注册与消息规则必须补上这层语义。 ## 三种标准化防护路径 截至 2026-08-08，CFRG 的 BLS Signatures 最新可见版本仍是 2025-11 的 Internet-Draft 06，尚未成为 RFC。它区分三种 scheme；实现应固定其中一种，不能混合 API。[^bls-draft] ### Basic Scheme：消息必须 Distinct Basic aggregate verification 要求所有 \(m_i\) 彼此不同。distinct-message 条件阻止攻击者把上面的 same-message rogue-key 构造直接套入聚合验证。调用方必须实际检查 distinctness，不能只依赖上层“通常不会重复”。 ### Message Augmentation：把公钥绑定进消息 augmentation scheme 签名 \[ m_i'=\mathsf{PK}_i\,\|\,m_i. \] 即使应用消息相同，不同公钥也会导出不同的 hash-to-curve 输入。serialization 必须 canonical；同一公钥的不同字节表示会破坏跨实现一致性。 ### Proof of Possession：注册后做 Same-Message Fast Aggregate PoP scheme 要求每个 public key 随注册提供 proof of possession，并强制执行 `PopVerify`。通过 PoP 的 key 才能进入 same-message `FastAggregateVerify`。 PoP 使用独立的 ciphersuite/DST 和规定的 public-key encoding，证明注册者知道对应 secret key；对业务消息的普通签名不能替代它。缓存 PoP 结果时要绑定 key bytes、scheme ID、ciphersuite version 与验证策略。 ## Input Validation 是验证方程的一部分 ### Public Key 与 Signature Validation `KeyValidate` 至少要求 public key： - 解码为曲线上的点； - 位于正确的 prime-order subgroup； - 点不等于 identity。 signature 与 PoP proof 也要按各自规范执行 group validation。跳过 subgroup checks 可能让小阶分量进入 pairing product；接受 identity public key 会对应零 secret key，并产生协议未预期的等价行为。 ### Hash-to-Curve 与 Domain Separation RFC 9380 要求每个 hash-to-curve 实例使用非空 DST，并建议包含应用、版本和 ciphersuite 标识。BLS Basic、Augmentation、PoP signature 和 PoP proof 使用不同的 tags。[^rfc9380] EIP-2537 的 Fp/Fp2 mapping precompiles 接收 field element 并输出 subgroup point。上层 BLS 实现仍要按 ciphersuite 完成 byte string 到 field、DST、`expand_message`、每次映射所需的 field elements 数量和点组合；不能把单次 precompile 调用当作完整 `hash_to_curve`。 ### Message Binding 应用层还要明确消息 bytes 中是否包含 chain ID、fork version、role、epoch、object type 和 replay domain。BLS 库验证一个 byte string 的签名，不会替应用决定这个 byte string 是否唯一代表待授权动作。 ## SNARK 与 KZG 只消费 Pairing 接口 Groth16 把 QAP 与 CRS 关系编码成 verifier pairing equation；第 6 篇已经逐项展开 \(A,B,C\)、公开输入项和 \(\alpha,\beta,\gamma,\delta\) terms。 KZG 把 polynomial opening 归约为 commitment/proof pairing relation；第 16 篇负责精确 SRS、opening equation、blob encoding 和 EIP-4844 integration。 这两类协议共享双线性工具，不继承 BLS 的 message、PoP 或 rogue-key 规则；BLS 也不继承 KZG/Groth16 的 trusted setup。 ## 工程审计清单 1. 明确 signature-in-G1 或 signature-in-G2 variant，拒绝跨 variant 编码； 2. 固定 Basic、Augmentation 或 PoP scheme，并按方案执行 distinctness/augmentation/PopVerify； 3. 对 public keys、signatures、aggregate signatures 和 PoP proofs 执行 non-identity、curve 与 subgroup validation； 4. 固定 hash-to-curve suite、DST、message serialization 和 application replay domain； 5. 将注册时 PoP 状态绑定到 canonical public-key bytes 和 scheme version； 6. 测试 rogue key、duplicate message、identity、wrong subgroup、malformed encoding 和 mixed ciphersuite； 7. 区分 library pairing success 与 application authorization success。 ## Summary - pairing 将源群标量关系搬到目标群，使 BLS、SNARK 和 KZG 获得紧凑验证接口。 - BLS 单签名 pairing equation 不覆盖聚合注册语义。 - Basic 要求 distinct messages；Augmentation 把 public key 纳入 message；PoP 通过注册证明支持 same-message fast aggregation。 - KeyValidate、signature validation、hash-to-curve DST 与 application message binding 都属于 verifier boundary。 - pairing 是共同工具；trusted setup、rogue-key 和 blob binding 仍由各协议分别承担。 ## References [^bls]: Dan Boneh, Ben Lynn, and Hovav Shacham, *Short Signatures from the Weil Pairing*, . [^bls-draft]: Boneh et al., *BLS Signatures*, `draft-irtf-cfrg-bls-signature-06`, November 2025, . [^rfc9380]: RFC 9380, *Hashing to Elliptic Curves*, .