以太坊、ICP 的 BLS 签名趣谈

以太坊、ICP 的 BLS 签名趣谈

在区块链世界里，共识的核心问题是：如何让数以千计的节点，对某个区块是否有效达成一致？

在这一过程中，签名机制扮演着关键角色。它不仅是节点证明自己参与共识的凭证，还决定了外部世界是否能轻松验证链上数据的可信性。

一种被广泛应用的签名机制就是 BLS 签名（Boneh–Lynn–Shacham）。这种签名方案在不同的公链中有着不同的使用方式：以太坊采用 聚合 BLS 签名（Aggregate BLS），而 ICP 则采用 门限 BLS 签名（Threshold BLS）。

二者的差别，不仅体现在技术细节上，更深刻影响了它们的共识效率与外部可验证性。

二、什么是 BLS 签名

BLS 签名是一种基于椭圆曲线配对运算的数字签名方案，最早由 Dan Boneh、Ben Lynn 和 Hovav Shacham 在 2001 年提出。它有两个显著优势：

1. 签名可聚合 多个不同参与者对同一消息生成的签名，可以被压缩合并为一条短签名。 不管有多少人参与，最终的签名大小始终是固定的（通常 96 字节）。

2. 验证高效 聚合后的签名只需要一次运算就能验证，而不必逐一验证所有单签。

在一个公链中，如果有数百上千的验证者需要对区块投票，BLS 签名就能显著降低通信和存储成本。这也是它被以太坊和 ICP 选择作为共识签名工具的原因。

三、Aggregate BLS 与 Threshold BLS 的区别

Aggregate BLS（聚合签名）

• 生成方式：每个验证者独立生成签名，之后再由聚合器合并成一条聚合签名。

• 验证方式：需要知道具体哪些验证者参与签名（通过位图标记），然后再将他们的公钥聚合后进行验证。

• 核心作用：压缩签名数据，提高效率。

Threshold BLS（门限签名）

• 生成方式：一把私钥被分割成若干份，分发给多个节点。只有超过阈值（例如 2/3）的节点联合，才能生成完整签名。

• 验证方式：只需子网的公共公钥即可验证，不需要知道具体哪些人参与。

• 核心作用：签名本身即为“2/3 多数背书”的证明。

简而言之：

• Aggregate BLS：签名本身只回答“有一批人签了”，但不能直接证明是否达到了共识阈值。

• Threshold BLS：签名一旦生成，就天然包含了“多数通过”的语义。

四、以太坊如何使用 Aggregate BLS 和位图（bitmap）形成共识

以太坊在 PoS（权益证明）机制下，采用 Casper FFG + LMD-GHOST 作为共识协议。BLS 聚合签名在其中发挥着关键的效率作用，但真正的共识判定还需要位图与质押权重统计。

(1) 每个验证者单独签名

每个验证者对消息（例如“这个区块是合法的”）生成 BLS 签名：

σi=Sign(ski,message)\sigma_i = Sign(sk_i, \text{message})

(2) 签名聚合

聚合者收集这些签名，并通过 BLS 聚合算法合并为一条签名：

σ=∏i∈Sσi\sigma = \prod_{i \in S} \sigma_i

其中 S 是参与签名的验证者集合。

(3) 位图生成

聚合者同时生成一份位图（bitmap）：

• 位数长度 = 委员会人数 N。

• 若验证者

i∈Si \in S

则位图第 i 位标记为 1，否则为 0。

例子：

• 假设委员会有 8 个验证者，其中第 2、4、7 个签了名。

• 那么位图为：

01010010

(4) 验证者公钥聚合

在验证时，节点根据位图提取签名者的公钥集合

{pki∣i∈S} \{pk_i \mid i \in S\}

并将它们聚合为一个公钥 PK。

(5) 验证聚合签名

使用 BLS 验证：

如果成立，就说明位图所标记的这些人确实都对消息签过名。

Verify(PK,message,σ)=TrueVerify(PK, \text{message}, \sigma) = \text{True}

(6) 权重统计与 Finality

• 通过位图，可以进一步计算签名者背后的质押权重：

W=∑i∈SstakeiW = \sum_{i \in S} stake_i

• 若

W≥23WtotalW \geq \tfrac{2}{3} W_{total}

则该区块被认定为有效背书。

• 在 Casper FFG 中，一个检查点先被 Justify，再在下一个检查点的支持下被 Finalize，通常需要两个 epoch（约 12 分钟）。

小结：

• 在以太坊中，BLS 聚合签名的作用是减少签名体积。

• 真正的共识结论，需要结合 位图 + 权重统计 + Casper FFG 规则 才能得出。

五、ICP 如何通过 Threshold BLS 来形成共识

1. 门限签名机制与原理

• 每个子网有一把公共公钥，但对应的私钥并不掌握在任何单一节点手里。

• 私钥通过 分布式密钥生成协议（DKG） 被分割成份额，每个节点持有一份。

• 单个节点无法独立签名，必须至少有 2/3 节点合作，才能生成完整签名。

• 一条签名的存在，本身就是“2/3 多数达成共识”的证明。

2. 出块与签名份额

• proposer 节点提出新区块。

• 其他节点验证区块并生成各自的签名份额：

σi=ShareSign(ski,m)\sigma_i = ShareSign(sk_i, m)

3. 门限签名生成

• 当收集到足够多（≥ 2/3）的签名份额后，可以合成完整签名：

σ=Combine({σi∣i∈S,∣S∣≥23N})\sigma = Combine(\{\sigma_i \mid i \in S, |S| \geq \tfrac{2}{3}N \})

• 这条签名在外部看来与普通 BLS 签名无异，但它的存在就等同于“子网多数同意”。

4. Finality 的即时性

• 在 ICP 中，签名一旦生成，就直接意味着该区块已被 final。

• 外部验证只需：

Verify(PKsubnet,m,σ)Verify(PK_{subnet}, m, \sigma)

验证成功，即确认该区块无可争议。

5. 系统支持与扩展功能

• 密钥管理：DKG 自动完成密钥生成和更新，避免单点失效。

• 跨子网交互：子网之间通过门限签名传递消息，确保数据真实。

• 对外证明：第三方只需验证一条签名，就能信任 ICP 提供的数据。

• 扩展功能：ICP 利用门限签名同时实现随机数生成、跨链通信、直接给浏览器用户提供可验证数据。

六、第三方使用链上数据

以太坊的数据使用

• 浏览器验证 1. 获取聚合签名和位图。 2. 根据位图提取验证者公钥。 3. 聚合公钥，验证聚合签名。 4. 累计签名者的质押权重。 5. 应用 Casper FFG 规则判断 finality。 流程复杂，普通用户设备难以完成，现实中大多依赖 RPC 服务商。

• 跨链验证 另一条链若要验证以太坊的交易，需要运行完整的以太坊轻客户端逻辑。 包括验证者集合更新、聚合签名校验、位图解析和质押权重计算。 成本高昂，因此跨链桥往往退化为“预言机模式”，依赖中继人，安全性下降。

ICP 的数据使用

• 浏览器验证 浏览器只需拿到区块头和一条门限签名，用子网公钥验证一次即可。 无需位图、无需验证者集合，轻量、直接、无需信任第三方。

• 跨链验证 目标链只需存储 ICP 子网的公钥。 验证一条门限签名即可确认数据已被子网多数节点背书。 成本极低，效率极高，天然适合跨链和预言机应用。

七、总结

• 以太坊：BLS 聚合签名是效率工具，本身不代表共识。真正的共识依赖位图、质押权重和 Casper FFG 规则。外部验证成本高，导致用户依赖第三方，跨链桥安全性受限。

• ICP：BLS 门限签名是共识基石，签名一出即为 finality。外部验证轻量，第三方使用链上数据极为方便。

这种差异不仅是技术选择上的不同，更深刻地决定了两条公链在外部可验证性、跨链能力和用户体验上的巨大差别。

小趣闻：BLS 签名与 ICP 的缘分

BLS 签名由 Dan Boneh、Ben Lynn 和 Hovav Shacham 于 2001 年提出。其中的 Ben Lynn，也就是签名算法名字里那个 “L”，后来曾在 Dfinity（ICP 背后的研发团队） 工作。

Ben Lynn 在斯坦福攻读博士时与 Dan Boneh 合作提出 BLS 签名，之后投身业界多年，专注密码学与分布式系统工程。加入 Dfinity 后，他的研究成果恰好与 ICP 的设计不谋而合 —— ICP 的共识机制正是基于 Threshold BLS 门限签名。

这让 ICP 成为了少数几个“原生使用 BLS 门限签名”的公链，而这一机制的落地，正是由其发明人之一亲手推动的。可以说，ICP 是 BLS 技术从理论走向大规模实践的代表性作品。

• 本文转载自： x.com/xiao_zcloak/status... , 如有侵权请联系管理员删除。