---
title: "BLS 签名"
description: "以验证为核心，理解 Boneh-Lynn-Shacham 签名、聚合模式、密码套件、流氓密钥防御、以太坊共识用途和实现风险。"
image: "https://wiki.fcontext.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.
# BLS 签名
> 仅供教育参考，不构成投资或密码学实现建议。签名有效本身不能证明协议安全、授权、可用性或最终性。
## 直接答案
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 签名使所签区块、跨链桥消息或协议在经济上安全且最终确定。
## 相关主题
- [密码学哈希](/zh-cn/crypto/cryptographic-hash/)
- [权益证明](/zh-cn/crypto/proof-of-stake/)
- [门限签名](/zh-cn/crypto/threshold-signature/)
## 来源
- [BLS 签名](https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-bls-signature-06) - Internet Research Task Force（查阅日期：2026-08-12）
- [RFC 9380：哈希到椭圆曲线](https://www.rfc-editor.org/rfc/rfc9380.html) - RFC Editor（查阅日期：2026-08-12）
- [来自 Weil 配对的短签名](https://doi.org/10.1007/3-540-45682-1_30) - Springer（查阅日期：2026-08-12）
- [以太坊权益证明共识规范](https://github.com/ethereum/consensus-specs) - Ethereum Foundation（查阅日期：2026-08-12）
- [Phase 0 信标链规范](https://github.com/ethereum/consensus-specs/blob/master/specs/phase0/beacon-chain.md) - Ethereum Foundation（查阅日期：2026-08-12）
- [以太坊注释规范：BLS 签名](https://github.com/ethereum/annotated-spec/blob/master/phase0/beacon-chain.md#bls-signatures) - Ethereum Foundation（查阅日期：2026-08-12）
- [EIP-2537：BLS12-381 曲线运算预编译](https://eips.ethereum.org/EIPS/eip-2537) - Ethereum Improvement Proposals（查阅日期：2026-08-12）
- [共识机制](https://ethereum.org/developers/docs/consensus-mechanisms/) - Ethereum.org（查阅日期：2026-08-12）
Source: https://wiki.fcontext.com/zh-cn/crypto/bls-signature/index.mdx