跳到正文
Financial Context Wiki

BLS 签名

以验证为核心，理解 Boneh-Lynn-Shacham 签名、聚合模式、密码套件、流氓密钥防御、以太坊共识用途和实现风险。

更新于

仅供教育参考，不构成投资或密码学实现建议。签名有效本身不能证明协议安全、授权、可用性或最终性。

直接答案

Boneh-Lynn-Shacham 签名是一种基于配对的数字签名。在一种常见方向中，私钥 sk 生成公钥 PK = sk * G1；消息 m 被映射为 H(m)，该点位于 G2；签名 sig = sk * H(m) 通过 e(PK, H(m)) = e(G1, sig) 验证。具体群、编码、哈希到曲线套件和域分离均由密码套件决定，不能把不同选择视为可互换记法。

BLS 有一项特殊的操作优势：有效签名可以相加成一个固定大小的群元素。这会压缩签名，但不会压缩签名者列表，也不能证明法定人数、识别获准验证者、防止双签或使共识最终确定。这些属性来自外围协议。

运作方式

  1. 固定协议、密码套件和版本：曲线、公钥群与签名群、序列化、哈希到曲线函数、域分离标签和消息根构造。绝不能只凭 BLS 名称推断兼容性。
  2. 按规定的密钥生成程序生成 sk 并推导 PK。依据准确的 KeyValidate 和反序列化规则，拒绝零值、无穷点、格式错误、非规范及错误子群编码。
  3. 构造准确的消息字节与签名域。在以太坊共识中，签名根把 SSZ 对象根与由操作类型和分叉数据推导的域绑定；界面显示文字不是签名对象。
  4. 使用选定方案签名并逐一验证。Basic、消息增强和持有证明三种变体采用不同的流氓密钥防御，不能随意混用。
  5. 按消息模式选择聚合验证器。只有在多个已验证公钥按所需持有证明假设签署同一消息时，才使用 FastAggregateVerify；对于方案允许的公钥与消息列表，使用 AggregateVerify。
  6. 根据委员会数据或参与者位图独立重建签名者集合，拒绝重复或未授权索引，应用质押权重或门限权重，然后验证聚合签名。有效聚合只认证所提供集合，并不决定该集合是否满足政策。
  7. 将结果与分叉选择、罚没条件、法定人数、可用性、时限和最终性核对。保存输入字节、域、签名者索引、实现版本和测试向量，并在部署前比较独立库。

算例

  • 压缩不会消除成员数据。 以太坊共识把每个 BLS 公钥编码为 48 bytes，每个签名编码为 96 bytes。512 个同消息签名单独占用 512 * 96 = 49,152 bytes。一个聚合签名加 512-bit = 64-byte 参与者位图共占 96 + 64 = 160 bytes，减少 49,152 - 160 = 48,992 bytes，即 99.6744791667%。验证者公钥和委员会映射仍须在别处提供。
  • 同消息聚合。 假设已注册验证者 17、24 和 91 都签署相同签名根 R，签名聚合为 sigAgg = sig17 + sig24 + sig91。验证使用有序且已验证的公钥集合 [PK17, PK24, PK91]、同一 R 和 FastAggregateVerify。有效结果证明这些密钥按该方案签署了 R；另行规则决定其权重以及三名签名者是否构成法定人数。
  • 不同消息需要正确 API。 公钥 PK1、PK2 和 PK3 分别签署消息 m1、m2 和 m3。验证器必须保留配对 [PK1, m1]、[PK2, m2]、[PK3, m3]，并调用适用的 AggregateVerify；把这些输入替换为单一消息并调用 FastAggregateVerify，验证的是另一项主张。在 Basic 方案下，消息还必须互不相同。
  • 聚合不等于门限签名。 在一个 8 人群组中，成员 [1, 2, 4, 6, 8] 的普通签名聚合会产生一个签名和五人签名者列表，不会变成由单一群组公钥验证的 5-of-8 门限签名。真正的门限 BLS 需要分布式密钥生成或可信经销商模型、份额索引和插值规则；其信任与失败假设必须另行审计。

风险

  • 使用与协议不同的曲线、群方向或密码套件。
  • 显示相同可读消息，却签署不同序列化字节。
  • 遗漏分叉域、操作域或应用域，导致跨上下文重放。
  • 把已过期 Internet-Draft 当成不可变的最终标准。
  • 接受格式错误、非规范或无穷点编码。
  • 跳过子群检查，接纳无效曲线或小子群输入。
  • 不按规定套件和测试向量，而自行编写哈希到曲线代码。
  • 生成有偏、为零、重复、泄露或可预测推导的私钥。
  • 在持有证明和域假设不同的协议间复用同一密钥。
  • 未采用方案要求的流氓密钥防御，就聚合未注册公钥。
  • 对不同消息或不一致消息根调用同消息快速验证。
  • 置换、重复或遗漏公钥与消息的对应关系。
  • 未核查委员会成员资格和索引唯一性就信任参与者位图。
  • 统计签名数量，而不是协议定义的质押、权重或门限。
  • 假设单个聚合签名能够揭示哪份个别签名无效。
  • 混淆普通聚合、多重签名和门限签名。
  • 把签名有效视为数据可用、执行正确或最终确定的证明。
  • 忽略双签、可罚没消息、时间窗口或分叉选择上下文。
  • 依赖单一库、CPU 特性或未经检查的批量验证优化。
  • 低估配对成本、拒绝服务输入、旁信道、密钥托管、升级和不具备抗量子安全性的风险。

常见误区

  • 聚合签名证明所有验证者都参与了。
  • 无需持有证明规则，任何 BLS 公钥和签名都能安全组合。
  • 固定大小聚合消除了传输或重建签名者成员信息的需要。
  • BLS 聚合与门限 BLS 是同一种构造。
  • 有效 BLS 签名使所签区块、跨链桥消息或协议在经济上安全且最终确定。

相关主题

来源

导航

搜索知识库...