以太坊信标链每个周期要收集大量验证者签名，若逐份独立存储与验证，数据与算力开销都会随验证者数量线性膨胀。答案是 BLS 聚合签名：基于双线性配对（pairing）运算的签名方案可以把任意多个对同一消息的签名压缩成一个固定大小的聚合签名，验证一次等于验证全体。它是 PoS“证明为什么多”的工程解药，也是分片、无状态、跨链轻客户端反复引用的同一件工具。
原理：把乘法搬进双射
BLS 签名的私钥是数 k，公钥是曲线上的点 k·G；对消息 m 的签名等于“把哈希到曲线上的 m 乘以 k”。聚合为什么可行？因为双射 e 满足 e(a·P, Q) = e(P, b·Q)（当 aP=bQ）这类线性交换性质：一堆签名 S1+…+Sn，只需检查 e(ΣSi, G) = e(H(m), ΣPk)——左边求和签名，右边求和公钥，一次双射比对替代 n 次独立验证。三个前提必须同时成立：所有人签的是同一条消息、每个签名者的公钥已被清点求和、公钥集合不被篡改。第三点是最大的暗礁。
暗礁： rogue key 攻击与密钥证明
若公钥集合不设防，攻击者可提交一个“用别人公钥算出来的”公钥（P_attack = P_victim − P_mine），把自己的签名伪装成合法成员、实际签出不该签的消息。防御办法是密钥证明（proof-of-possession）：入册时先用私钥对“我自己的公钥”签一份存在证明，把公钥与知识绑定。所以看到 BLS 系统的安全说明，“是否强制 PoP”是检查它的第一个问题；BLS 标准化工作（IETF 草案）专门定义了密钥注册时的 possession 证明变体，部署方案若不启用它就必须给出等价的替代防御。
与 MuSig2 类 Schnorr 聚合的区别
比特币阵营的 MuSig2（见 BIP327 MuSig2聚合签名如何工作？）聚合的是“多方共同签一个账本交易”的场景：几方必须先协作跑协议才能产生一个看起来像单签名的签名，链上验证走普通 ECDSA 路径，不需要新曲线。BLS 则是“先各自独立签，验证时才聚合”，签名者之间零协调——这是 PoS 场景的决定性优势，代价是引入配对曲线（如 BLS12-381）与更复杂的密码审计面；以太坊社区曾以 EIP-2537 提议在执行层加入 BLS 预编译，该提议是否落地以其 EIP 状态为准。
快速问答
- “聚合能证明谁签了什么吗？“对同一消息的纯聚合丢失个体归属，需要个体证明时用“签名分位”或与聚合并列的位图（哪些位=谁投了），信标链的同步委员会正是位图+聚合的组合。
- “验证延迟会多大？“聚合是把签名与各自公钥做群内求和，单签开销近零；验证方最后要做的独立配对运算次数与签名人数基本无关——这正是它替代“数千次独立验证”的价值。
- “它为什么和同步委员会总一起出现？“Sync Committee 每周期换一批成员投票证明轻客户端可信（见 slot 和 epoch 是什么？以太坊的时间单位的时间结构），BLS 让这 512 人的投票压成一个可塞进头的证明——两者是同一枚硬币的机制与包装（详见 同步委员会（Sync Committee）是什么？）。
- “量子来了怎么办？“基于离散对数的 BLS 与 ECDSA 同样脆弱，抗量子替代（基于格）暂无同规格的廉价聚合，这是后量子路线图的公开难题。
常见误区
- 误区一：以为聚合需要签名者在线协调。BLS 的聚合发生在验证前的任意时刻，任何人可代做——这一点让“打包者代替签名者”成为常设角色，也意味着聚合的归责链要单独设计。
- 误区二：把“一个签名”当“一个秘密”。聚合大小恒定但验证需要完整公钥集，公钥集合管理本身就是系统状态，膨胀问题被移到了公钥层。
- 误区三：忽略曲线与实现的审计门槛。双射实现的常数时间与正确性是重灾区，选 BLS 方案先看是否用成熟审计库与标准曲线（BLS12-381 为当前主流）。
小结
BLS 聚合把“人多证明大”的诅咒变成“人多证明不变大”的红利，PoS 的可扩展性叙事几乎全押在它身上。评估使用 BLS 的系统时问三件事：入册有没有密钥证明、个体投票归责怎么做（位图方案）、实现是否用标准曲线与审计库。三个答案决定它是在压缩数据，还是在压缩信任。
风险提示：本文不构成投资建议。密码方案存在理论演进风险，机制以官方文档为准。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。