以太坊计划如何用后量子签名替代BLS签名 - HashCloak

hashcloak 发布于 2026-05-21 阅读 109

本文详细介绍了以太坊为应对量子计算机威胁，计划用后量子签名方案LeanSig替代当前使用的BLS签名。文章首先解释了BLS签名及其聚合机制在以太坊共识中的关键作用，然后引入LeanSig——一种基于哈希链和Merkle树的签名方案，专为以太坊验证者单次签名场景优化。文章还讨论了为解决签名聚合而设计的哈希基zkVM（leanVM），以及其形式化验证目标。最后分析了优化目标（签名大小、树深度、证明性能）和哈希函数选择（Poseidon与SHA-3的权衡）。整体展示了以太坊后量子密码升级的研发进展。

![](https://img.learnblockchain.cn/2026/06/04/UtBoAfePeAqDVqBkPnt2yKf8p4o.jpeg)

Elena

密码学工程师

2026年5月20日

多年来，我们一直在数字世界（包括去中心化数字世界）中快乐地建设，其基础是 Diffie-Hellman、RSA、ElGamal 和椭圆曲线。不幸的是，我们大多数人用于密钥交换和数字签名的经典公钥密码学正面临威胁。嗯，随着 AI 的崛起，威胁可能是多方面的，但这里我们聚焦于量子计算机的威胁。如果建造出能够执行 Shor 算法（该算法能破解椭圆曲线密码学和 RSA）的量子计算机，就可以从公钥推导出私钥，从而伪造数字签名。

以太坊也面临这一威胁，因为其整个堆栈中使用的配对签名基于椭圆曲线，因此不具备量子安全性。作为 [lean Ethereum](https://learnblockchain.cn/article/19244) 路线图的一部分，以太坊旨在将其所有密码学升级为量子安全。需要注意的是，在以太坊案例中，量子计算机的威胁不仅仅是量子计算机本身的实现，而是这种潜在可能性引发的**恐惧**可能危及系统，因为它最终依赖于人们及其对系统的信任。

在这篇文章中，我们将深入探讨 lean Ethereum 团队分享的研究进展。区块链自豪地建立在密码学之上，而在以太坊中，共识层、执行层和数据层使用了各种密码算法，所有这些都不具备量子安全性。我们将聚焦于以太坊共识中使用的密码学，以及该领域当前向后量子密码学迁移的计划。

### 当前以太坊共识中签名是如何使用的

自 The Merge 以来，以太坊的共识依赖于 [权益证明](https://ethereum.org/developers/docs/consensus-mechanisms/pos/) 共识机制。验证者需要重新执行区块中的交易，并检查这些交易以及区块签名是否有效。然后验证者通过网络发送关于区块正确性的认证，这本身就是一个签名。由于在撰写本文时，以太坊网络有 90 万至 100 万活跃验证者（参考文献 [1](https://tokenterminal.com/explorer/projects/ethereum/metrics/number-of-validators), [2](https://beaconcha.in/charts/validators)），单独验证每个签名会带来巨大开销。这时 BLS 签名方案就派上了用场。

我们简要介绍基于双线性配对的 BLS 签名。有关更完整的介绍，请参阅本文末尾的参考文献。

素数阶 $q$ 的群 $G_1 = \langle g_1 \rangle$、$G_2 = \langle g_2 \rangle$ 和 $G_t$ 上的双线性配对是一个映射 $e: G_1 \times G_2 \to G_t$，满足以下三个条件：

* **双线性。** 对所有 $r \in G_1$, $s \in G_2$ 和 $a, b \in \mathbb{Z}_q$：
  $$e(r^a, s^b) = e(r, s)^{ab}$$

* **非退化性。** $e(g_1, g_2) \neq 1_{G_t}$。

* **可高效计算。**

要定义 BLS 签名方案（针对单个签名），我们还需要一个哈希函数 $H: \{0,1\}^* \to G_1$。签名方案的工作方式如下：

1. **KeyGen。** 随机选择 $sk \stackrel{R}{\leftarrow} \mathbb{Z}_q$ 并令 $pk = g_2^{sk} \in G_2$。输出 $(sk, pk)$。

2. **Sign**(sk, m)。设置 $\sigma = H(m)^{sk} \in G_1$。输出 $\sigma$。

3. **Verify**(pk, m, $\sigma$)。检查 $e(\sigma, g_2) \stackrel{?}{=} e(H(m), pk)$。如果成立则接受，否则拒绝。

注意签名由群 $G_1$ 中的一个元素组成。为了理解签名验证为什么合理，使用配对的双线性性质：

$$
\begin{aligned}
e(\sigma, g_2) &= e(H(m)^{sk}, g_2) \\
&= e(H(m), g_2)^{sk} \\
&= e(H(m), g_2^{sk}) \\
&= e(H(m), pk)
\end{aligned}
$$

现在，正如我们之前讨论的，在以太坊的情况下，我们需要验证大量签名。因此，理想情况下，我们希望有一种机制可以批量验证签名，而不会增加任何开销，例如各方之间的额外通信或添加受信任的第三方。同时请记住，对于这个用例，每个参与方都旨在签署相同的消息 $m$。

实际上，对 BLS 签名进行聚合有一个简单的扩展。假设我们要聚合各方 $1,\dots,n$ 的签名及其各自的公钥 $pk_1,\dots,pk_n$。KeyGen 和 Sign 过程与上述相同。我们只需添加一种方法来合并对消息 $m$ 使用私钥 $sk_1,\dots,sk_n$ 生成的签名 $\sigma_1,\dots,\sigma_n$，然后验证合并后的签名：

**签名聚合**($\sigma_1,\dots,\sigma_n$)。输出 $\prod_{i=1}^n \sigma_i$。

**聚合签名验证**($\{pk_1,\dots,pk_n\}$, $m$, $\sigma$)。计算 $apk = \prod_{i=1}^n pk_i$。然后，检查 $e(\sigma, g_2) \stackrel{?}{=} e(H(m), apk)$。如果成立则接受，否则拒绝。

注意，聚合公钥可以独立于验证阶段计算，并直接作为输入。同样，利用双线性性质，我们可以看到这正确地验证了聚合签名：

$$
\begin{aligned}
e(\sigma, g_2) &= e\left(\prod \sigma_i, g_2\right) \\
&= \prod e(\sigma_i, g_2) \\
&= \prod e(H(m)^{sk_i}, g_2) \\
&= \prod e(H(m), g_2^{sk_i}) \\
&= e\left(H(m), \prod g_2^{sk_i}\right) \\
&= e\left(H(m), \prod pk_i\right) \\
&= e(H(m), apk)
\end{aligned}
```

这种朴素聚合容易受到**流氓公钥攻击**，其中攻击者从现有密钥中构造一个公钥，而从未知道底层私钥。这允许攻击者创建伪造的聚合签名。解决方法是在注册公钥作为验证者时提供所有权证明，表明验证者知道与该公钥对应的私钥。

所以总结一下：我们有一种签名方案，允许所有验证者单独签署区块，并有一个廉价的聚合机制，可以将所有这些签名批量合并为单个签名。实际上，最终会有几个聚合签名，每个都批处理了大量单个签名。

这个非常实用的方案在后量子替代方案方面留下了巨大的挑战，特别是在大小和计算开销方面。

### LeanSig：为以太坊共识定制的后量子签名

LeanSig 是目前正在考虑替代 BLS 的基于哈希的签名方案。该方案之所以被优先考虑，是因为：

- 最小的假设（哈希）

- 简单性。无需高深数学，易于实现

- 一切使用同一个哈希

对于以太坊共识，我们正在优化的是一种非常特定的情况：验证者签署相同的消息，并且每个 epoch 只应签署一次。**有状态**签名方案非常适合这里；这是一种跟踪状态以避免重复使用私钥的方案。NIST 标准化的 SPHINCS 变体也是基于哈希的，但增加了防止状态跟踪的开销——而我们可以避免这种开销。

在本节中，我们将介绍 LeanSig 的高级思想并审查设计选择。请记住，所有这些都是进行中的研究，对该计划的大大小小的更改都是意料之中的。此外，虽然我们专注于理解功能以及为什么这能覆盖以太坊的用例，但 Lean Ethereum 团队的大量工作实际上是在进行安全分析，目标是采用非常保守的假设。

#### 来自哈希链的一次性签名

LeanSig 的基础是 XMSS，于 2011 年提出，其本身基于 1979 年起源的 Merkle 签名方案。它使用一次性签名 (OTS)，允许用户仅使用一次私钥签署一条消息，并通过 Merkle 树将它们组合成一个通用的**多次签名**签名方案。

对于单个签名，思路如下：生成一个秘密值 $x$ 并重复哈希它：

$$sk = x \to H(x) \to H^2(x) \to \dots \to H^k(x) = pk$$

然后令公钥/私钥对为 $(H^k(x), x)$，因此链的第一个元素是私钥，最后一个元素是公钥。由于哈希函数的性质，在链上前进很容易，但后退很难。

对（短）消息 $m$ 的签名是通过将消息转换为 $[1,\dots,k-1]$ 中的索引 $i$，并输出 $\sigma = H^i(x)$ 获得的。例如，如果 $i = 2$，我们有以下哈希链，圆圈元素是签名：

![](https://img.learnblockchain.cn/2026/06/04/69QYKse7QPzshi0kYoE7V331m0.png)

验证者将通过将消息 $m$ 重新转换为索引 $i$，然后检查哈希链的完成是否等于签名者的公钥来验证此签名：

$$H^{k-i}(\sigma) \stackrel{?}{=} pk$$

![](https://img.learnblockchain.cn/2026/06/04/LJ9VNzZu9s4QNW6ju7PD5Pw4zSA.png)

为什么这是一次性签名？一旦一条消息被签署，任何映射到索引大于已签署消息的消息也可以被签署，因为我们只需应用额外的哈希次数即可。

乍一看，这似乎不是一个非常实用的方案，因为我们需要使用许多不同的密钥来签署许多不同的消息。而且我们还没有考虑到上面的例子假设消息可以直接映射到 $1$ 和 $k-1$ 之间的单个索引，而实际上它会映射到多个索引，我们不能为其中任何一个重复使用私钥。但事实证明，将这个核心思想扩展到多次签名并不困难，而且（令人惊讶地？）我们得到了一个实用的方案。

#### 从一次性到多次：Merkle 树和多条链

为了支持大量的密钥对，我们将使用经典的 Merkle 树；每个叶子包含一个公钥，我们最终得到一个公钥根。签名者通过发布根上链来承诺一棵树，从而承诺一组密钥对。

![](https://img.learnblockchain.cn/2026/06/04/GtmgsQ0mXBFE1PCOV3yrkFXj7M.png)

为了扩展到多个签名，我们只需使用多条链。如果我们想签署消息 $m$，首先哈希它，然后将其分割成 $v$ 个选定长度的块（如果需要，在末尾添加填充）。然后，使用 $v$ 条哈希链来签署每个块，方法是将块转换为链中的索引并将该索引处的元素添加到签名中。

因此，每个 epoch 我们使用 $v$ 个公钥/私钥对，最终得到 $v$ 个添加到签名中的哈希。例如，在下图中，签名由索引 $1,2,k-1,\dots,1$ 组成（中间还有更多索引）。使用的公钥可以哈希在一起形成单个公钥 $pk$，该公钥存在于更大的 Merkle 树中。

![](https://img.learnblockchain.cn/2026/06/04/yMXCVlY6jjpXZC0XfdITqhY.png)

签名包含来自哈希链的元素以及 Merkle 证明，表明它是验证者承诺的所有公钥的一部分。

结合这两个概念，我们最终得到用于生成和验证签名的哈希链，以及用于支持许多密钥的 Merkle 树。我们在这里看到重叠的力量了吗？确实，是哈希函数。

![](https://img.learnblockchain.cn/2026/06/04/deFu6WN3IrQwhT3157p90t3ONk.jpg)

#### 添加目标总和

然而，当前签名方案的描述存在一个问题：攻击者可以使用不同的链伪造有效的签名。让我们看一个使用三条链的小例子。如果验证者 $V$ 打算签署消息 $m$，该消息编码为索引 $(1,2,4)$，那么有效签名将是 $(H(x_0), H^2(x_1), H^4(x_2))$。在这种情况下，攻击者可以假装验证者 $V$ 实际签署了一条不同的消息 $m'$，如果该消息编码为 $(2,2,5)$，因为每个索引都等于或大于原始索引。伪造的签名将是 $(H(H(x_0)), H^2(x_1), H(H^4(x_2)))$，攻击者可以在不知道私钥 $x_0, x_1, x_2$ 的情况下创建它。

这可以通过添加一个对所使用索引的校验和来解决；在上面的例子中，$(1,2,4)$ 会给出校验和 $1+2+4=7$，任何对不同的（伪造）消息的伪造签名至少会大于 $7$ 并且无法通过验证。但请注意，这个值本身也需要被签署，这就需要更多的哈希链来解决这个问题。作为解决方案，LeanSig 采用了一种**目标总和**方法，其中有一个固定的目标值 $T$，校验和应加起来等于该值，从而消除了签署校验和所需的额外链。使校验和等于 $T$ 是通过在开始时用随机值哈希消息，并根据需要重新采样随机性来完成的。

#### 完整图景

![](https://img.learnblockchain.cn/2026/06/04/7bpqvxVWnFbzNt72SjYXWU0SM.png)

这就是 leanSig 的高级思想：验证者在注册时通过 Merkle 根承诺 $L$ 个密钥对。然后，在每个 epoch 中，它使用 $v$ 个公钥来签署已哈希并编码为 $v$ 个索引的块。然后签名由 $v$ 个哈希和附带的用于所使用公钥的 Merkle 证明组成。验证者完成哈希链，并随后验证这些公钥确实属于验证者承诺的 Merkle 树。

附加说明。如何安全且针对此用例以最佳性能从 $m$ 编码到索引数组 $(i_0,\dots,i_{v-1})$ 目前仍在积极研究中。我们已知需要一种**不可比较编码**，其中对于两条消息 $m_1$ 和 $m_2$，不可能出现 $m_2$ 的每个索引都大于 $m_1$ 的索引的情况。如果没有这个属性，就可能伪造签名。

### LeanSig 的聚合：引入 leanVM

定义的签名方案适用于单个方，即我们为以太坊考虑的用例中的单个验证者，并且与 BLS 的情况一样，我们希望有一个聚合选项。不幸的是，哈希没有我们可以利用的代数结构。然而，总是有选项可以使用**简洁知识论证** (SNARK) 来聚合签名。在这种情况下，公共输入是公钥，见证由要验证的签名组成，生成的证明使我们都相信所有签名都通过了检查。当然，由于迁移到后量子签名的目标也必须与抗量子 SNARK 相结合，即 pqSNARK。

为了解决这个问题，团队一直在开发一个最小的 zkVM，称为 [leanVM](https://github.com/leanEthereum/leanMultisig)，它本身是基于哈希的。zkVM 的设计灵感来自 Cairo。主要设计目标是创建一个非常简单的 zkVM，可以完全形式化验证，并且针对聚合基于哈希的签名和支持递归的特定任务。再说一遍：目标是完全形式化验证这个 zkVM！形式化验证工作将使用 Lean，而这些名称重叠显然纯属巧合。请注意，目标是形式化验证 zkVM 本身以及在其上运行的程序，例如 XMSS 签名聚合。

如果你付出如此努力来构建一个安全、快速的用于基于哈希的签名聚合的 zkVM，为什么不将其用于 XMSS 签名之外的其他用途呢？这就是为什么它也将用于执行层，计划在那里使用 SPHINCS 签名，这些签名也是基于哈希的并且需要聚合。

zkVM（参见 [文档](https://github.com/leanEthereum/leanMultisig/blob/main/minimal_zkVM.pdf)）具有非常小的指令集架构，只有 4 个操作码用于加法 (ADD)、乘法 (MUL)、跳转指令 (JUMP) 和内存指令 (DEREF)。此外，目前有 2 个预编译用于执行哈希和扩域运算。再次强调，所有这些研究都在不断发展，对此的更改是意料之中的。

对于证明，使用了 Plonky3，Lean Ethereum 团队与 Plonky3 团队合作进行了优化，以提升 CPU 相关架构和 zkVM 使用的低级功能的性能。虽然许多 zkVM 团队正在为 GPU 进行优化，但由于所有这项工作都针对以太坊验证者及其应能使用非常简单的硬件，因此 CPU 优化一直是主要焦点。此外，对乘法等低级功能的每项改进都是一种增益，因为这些功能在电路中会被重复使用。

### 我们在优化什么

现在我们已经看到了各个相互关联的部分，让我们退后一步，看看我们正在尝试优化什么。

由于签名需要在网络上共享，我们追求更小的签名大小。更小的签名意味着更少的哈希链，而这如何影响需要完成的哈希量取决于所选的编码方法。

另一个单独的参数是公钥 Merkle 树中叶子的生命周期参数 $L$。如果 $L = 2^{26}$，则相当于以太坊验证者约 10 年的活动（[参考文献](https://learnblockchain.cn/video/play/1827)）。你不希望过于频繁地重新生成密钥，但更大的树也意味着更大的签名大小、额外的哈希，最重要的是对存储如此大树的记忆体影响。

此外，由于签名聚合是使用 zkVM 完成的，我们旨在最小化验证器中的哈希。验证的所有操作都在电路内完成，这很昂贵。此外，哈希函数的选择在这里很重要；Poseidon 在电路内性能更好。

对于 leanVM 的基准测试，重要的是要记住每秒可以聚合多少个 XMSS 签名、递归的速度有多快以及证明大小。虽然优化电路内单个哈希函数的性能很重要，但团队在 [ZK Podcast 第 394 集](https://www.youtube.com/watch?v=YWkyvTrwtQU) 中解释说，总性能也取决于**粘合逻辑**，例如形成哈希链和 Merkle 树以及将消息编码为索引。

为 leanSig 提出的改进之一集中在编码方法上，旨在生成降低验证器工作负载的索引。然而，在电路中实例化该编码算法结果相当昂贵，并且会中止非微不足道的时间；这给团队带来了更多研究工作以支持这一改进。

### 关于哈希函数选择的些许讨论

关于这一切中实际使用的哈希函数，还有更多细节。首先，不同点使用的（哈希函数的实例化）并不完全相同。哈希链内部的哈希与 Merkle 证明中的哈希略有不同，而用于 zkVM 的哈希也可能不同。

关于哈希函数的选择，目前尚无定论。我们已经讨论了 Poseidon 在电路内哈希中更受青睐，而 SHA-3 可能不是因为性能而是因为安全性而被优先考虑；它已经存在了相当长一段时间。

Poseidon2 由于性能似乎是最好的候选者，但在 [EthProofs 电话会议 #8](https://www.youtube.com/watch?v=7Jxq3YU8GUY) 中宣布，Lean Ethereum 正在将重点转移到 Poseidon1，因为事实证明 Poseidon2 的攻击面与 Poseidon1 不同，因此它无法像之前假设的那样继承安全分析。考虑 Poseidon2 的理由是它已经经过了 7 年的审查，这似乎合理，考虑到中本聪选择 SHA-256 时它已经 7 岁，而 Vitalik 选择 Keccak 时它也是 7 岁（[参考文献](https://learnblockchain.cn/video/play/1826)）。有了这一新见解，时钟重置为 3 年，即 Poseidon2 论文实际发表的时间。

（该 Meme 在 EthProofs 电话会议 #8 上展示）

![](https://img.learnblockchain.cn/2026/06/04/aLCvBXgTWXFLoMXiptapuTHqsU.png)

由于哈希函数的选择至关重要，以太坊提供了大量资助和奖励以鼓励密码分析研究工作（阅读此 [网站了解更多信息](https://www.poseidon-initiative.info/)）。在重点转移之后，这现在主要考虑 Poseidon1。

### 总结

在未来的文章中，我们希望更深入地探讨 leanVM 和编码机制的研究进展。所有这些努力也可能服务于其他区块链，甚至其他类型的技术，只要其用例与以太坊的情况一致。要了解更多细节，我们推荐来自 2025 年 10 月 leanVM/PQ 研讨会的 [这些资源](https://github.com/leanEthereum/pm/blob/main/workshops-and-interops/2025/lean-week-cambridge/index.md)、[零知识播客](https://zeroknowledge.fm/podcast/390/) 上关于 Lean Ethereum 的短系列以及 Lean 共识研发 [网站](https://leanroadmap.org/)。

虽然我们以量子威胁的描述作为本文的开头，但这项研究工作的整体基调要积极得多。我们没有深入探讨 Lean Ethereum 升级提案的全部范围（这是一项持续的努力），但其主要思想是利用这样一个事实：无论如何都需要进行大的改动，所以让我们充分利用这一点。后量子签名要大得多，我们非但不能降低性能，反而可以最终得到一个更快、更强的系统。

### 参考文献

\[1\] Boneh, D., Lynn, B., & Shacham, H. (2001). _Short signatures from the Weil pairing_. ASIACRYPT 2001. [https://www.iacr.org/archive/asiacrypt2001/22480516.pdf](https://www.iacr.org/archive/asiacrypt2001/22480516.pdf)

\[2\] Boneh, D., Drijvers, M., & Neven, G. (2018). _Compact multi-signatures for smaller blockchains_. ASIACRYPT 2018. [https://eprint.iacr.org/2018/483.pdf](https://eprint.iacr.org/2018/483.pdf)

\[3\] Drake, J. _Pragmatic signature aggregation with BLS_. Ethereum Research. [https://ethresear.ch/t/pragmatic-signature-aggregation-with-bls/2105](https://ethresear.ch/t/pragmatic-signature-aggregation-with-bls/2105)

\[4\] Drake, J., Khovratovich, D., Kudinov, M., & Wagner, B. (2025). _Hash-Based Multi-Signatures for Post-Quantum Ethereum_. Cryptology ePrint Archive, Paper 2025/055. [https://eprint.iacr.org/2025/055](https://eprint.iacr.org/2025/055)

\[5\] Goldberg, L., Papini, S., & Riabzev, M. (2021). _Cairo - a Turing-complete STARK-friendly CPU architecture_. Cryptology ePrint Archive, Paper 2021/1063. [https://eprint.iacr.org/2021/1063](https://eprint.iacr.org/2021/1063)

\[6\] Khovratovich, D., Kudinov, M., & Wagner, B. (2025). _At the Top of the Hypercube - Better Size-Time Tradeoffs for Hash-Based Signatures_. Cryptology ePrint Archive, Paper 2025/889. [https://eprint.iacr.org/2025/889](https://eprint.iacr.org/2025/889)

\[7\] Drake, J., Khovratovich, D., Kudinov, M., & Wagner, B. (2025). _Technical Note: LeanSig for Post-Quantum Ethereum_. Cryptology ePrint Archive, Paper 2025/1332. [https://eprint.iacr.org/2025/1332](https://eprint.iacr.org/2025/1332)

\[8\] Buchmann, J., Dahmen, E., & Hülsing, A. (2011). _XMSS - A Practical Forward Secure Signature Scheme based on Minimal Security Assumptions_. Cryptology ePrint Archive, Paper 2011/484. [https://eprint.iacr.org/2011/484](https://eprint.iacr.org/2011/484)

\[9\] Merkle, R. C. (1979). _A Certified Digital Signature_. [https://scispace.com/pdf/a-certified-digital-signature-2quebo9evb.pdf](https://scispace.com/pdf/a-certified-digital-signature-2quebo9evb.pdf)

>- 原文链接： [hashcloak.com/blog/how-e...](https://hashcloak.com/blog/how-ethereum-plans-to-replace-bls-with-post-quantum-signatures)
>- 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～

Elena

密码学工程师

2026年5月20日

以太坊也面临这一威胁，因为其整个堆栈中使用的配对签名基于椭圆曲线，因此不具备量子安全性。作为 lean Ethereum 路线图的一部分，以太坊旨在将其所有密码学升级为量子安全。需要注意的是，在以太坊案例中，量子计算机的威胁不仅仅是量子计算机本身的实现，而是这种潜在可能性引发的恐惧可能危及系统，因为它最终依赖于人们及其对系统的信任。

当前以太坊共识中签名是如何使用的

自 The Merge 以来，以太坊的共识依赖于权益证明共识机制。验证者需要重新执行区块中的交易，并检查这些交易以及区块签名是否有效。然后验证者通过网络发送关于区块正确性的认证，这本身就是一个签名。由于在撰写本文时，以太坊网络有 90 万至 100 万活跃验证者（参考文献 1, 2），单独验证每个签名会带来巨大开销。这时 BLS 签名方案就派上了用场。

我们简要介绍基于双线性配对的 BLS 签名。有关更完整的介绍，请参阅本文末尾的参考文献。

素数阶 $q$ 的群 $G_1 = \langle g_1 \rangle$、$G_2 = \langle g_2 \rangle$ 和 $G_t$ 上的双线性配对是一个映射 $e: G_1 \times G_2 \to G_t$，满足以下三个条件：

双线性。 对所有 $r \in G_1$, $s \in G_2$ 和 $a, b \in \mathbb{Z}_q$： $$e(r^a, s^b) = e(r, s)^{ab}$$
非退化性。 $e(g_1, g_2) \neq 1_{G_t}$。
可高效计算。

要定义 BLS 签名方案（针对单个签名），我们还需要一个哈希函数 $H: {0,1}^* \to G_1$。签名方案的工作方式如下：

KeyGen。 随机选择 $sk \stackrel{R}{\leftarrow} \mathbb{Z}_q$ 并令 $pk = g_2^{sk} \in G_2$。输出 $(sk, pk)$。
Sign(sk, m)。设置 $\sigma = H(m)^{sk} \in G_1$。输出 $\sigma$。
Verify(pk, m, $\sigma$)。检查 $e(\sigma, g_2) \stackrel{?}{=} e(H(m), pk)$。如果成立则接受，否则拒绝。

注意签名由群 $G_1$ 中的一个元素组成。为了理解签名验证为什么合理，使用配对的双线性性质：

$$ \begin{aligned} e(\sigma, g_2) &= e(H(m)^{sk}, g_2) \ &= e(H(m), g_2)^{sk} \ &= e(H(m), g_2^{sk}) \ &= e(H(m), pk) \end{aligned} $$

签名聚合($\sigma_1,\dots,\sigma_n$)。输出 $\prod_{i=1}^n \sigma_i$。

聚合签名验证(${pk_1,\dots,pk_n}$, $m$, $\sigma$)。计算 $apk = \prod_{i=1}^n pk_i$。然后，检查 $e(\sigma, g_2) \stackrel{?}{=} e(H(m), apk)$。如果成立则接受，否则拒绝。

注意，聚合公钥可以独立于验证阶段计算，并直接作为输入。同样，利用双线性性质，我们可以看到这正确地验证了聚合签名：

$$ \begin{aligned} e(\sigma, g_2) &= e\left(\prod \sigma_i, g_2\right) \ &= \prod e(\sigma_i, g_2) \ &= \prod e(H(m)^{sk_i}, g_2) \ &= \prod e(H(m), g_2^{sk_i}) \ &= e\left(H(m), \prod g_2^{sk_i}\right) \ &= e\left(H(m), \prod pk_i\right) \ &= e(H(m), apk) \end{aligned}


这种朴素聚合容易受到**流氓公钥攻击**，其中攻击者从现有密钥中构造一个公钥，而从未知道底层私钥。这允许攻击者创建伪造的聚合签名。解决方法是在注册公钥作为验证者时提供所有权证明，表明验证者知道与该公钥对应的私钥。

所以总结一下：我们有一种签名方案，允许所有验证者单独签署区块，并有一个廉价的聚合机制，可以将所有这些签名批量合并为单个签名。实际上，最终会有几个聚合签名，每个都批处理了大量单个签名。

这个非常实用的方案在后量子替代方案方面留下了巨大的挑战，特别是在大小和计算开销方面。

### LeanSig：为以太坊共识定制的后量子签名

LeanSig 是目前正在考虑替代 BLS 的基于哈希的签名方案。该方案之所以被优先考虑，是因为：

- 最小的假设（哈希）

- 简单性。无需高深数学，易于实现

- 一切使用同一个哈希

对于以太坊共识，我们正在优化的是一种非常特定的情况：验证者签署相同的消息，并且每个 epoch 只应签署一次。**有状态**签名方案非常适合这里；这是一种跟踪状态以避免重复使用私钥的方案。NIST 标准化的 SPHINCS 变体也是基于哈希的，但增加了防止状态跟踪的开销——而我们可以避免这种开销。

在本节中，我们将介绍 LeanSig 的高级思想并审查设计选择。请记住，所有这些都是进行中的研究，对该计划的大大小小的更改都是意料之中的。此外，虽然我们专注于理解功能以及为什么这能覆盖以太坊的用例，但 Lean Ethereum 团队的大量工作实际上是在进行安全分析，目标是采用非常保守的假设。

#### 来自哈希链的一次性签名

LeanSig 的基础是 XMSS，于 2011 年提出，其本身基于 1979 年起源的 Merkle 签名方案。它使用一次性签名 (OTS)，允许用户仅使用一次私钥签署一条消息，并通过 Merkle 树将它们组合成一个通用的**多次签名**签名方案。

对于单个签名，思路如下：生成一个秘密值 $x$ 并重复哈希它：

$$sk = x \to H(x) \to H^2(x) \to \dots \to H^k(x) = pk$$

然后令公钥/私钥对为 $(H^k(x), x)$，因此链的第一个元素是私钥，最后一个元素是公钥。由于哈希函数的性质，在链上前进很容易，但后退很难。

对（短）消息 $m$ 的签名是通过将消息转换为 $[1,\dots,k-1]$ 中的索引 $i$，并输出 $\sigma = H^i(x)$ 获得的。例如，如果 $i = 2$，我们有以下哈希链，圆圈元素是签名：

![](https://img.learnblockchain.cn/2026/06/04/69QYKse7QPzshi0kYoE7V331m0.png)

验证者将通过将消息 $m$ 重新转换为索引 $i$，然后检查哈希链的完成是否等于签名者的公钥来验证此签名：

$$H^{k-i}(\sigma) \stackrel{?}{=} pk$$

![](https://img.learnblockchain.cn/2026/06/04/LJ9VNzZu9s4QNW6ju7PD5Pw4zSA.png)

为什么这是一次性签名？一旦一条消息被签署，任何映射到索引大于已签署消息的消息也可以被签署，因为我们只需应用额外的哈希次数即可。

乍一看，这似乎不是一个非常实用的方案，因为我们需要使用许多不同的密钥来签署许多不同的消息。而且我们还没有考虑到上面的例子假设消息可以直接映射到 $1$ 和 $k-1$ 之间的单个索引，而实际上它会映射到多个索引，我们不能为其中任何一个重复使用私钥。但事实证明，将这个核心思想扩展到多次签名并不困难，而且（令人惊讶地？）我们得到了一个实用的方案。

#### 从一次性到多次：Merkle 树和多条链

为了支持大量的密钥对，我们将使用经典的 Merkle 树；每个叶子包含一个公钥，我们最终得到一个公钥根。签名者通过发布根上链来承诺一棵树，从而承诺一组密钥对。

![](https://img.learnblockchain.cn/2026/06/04/GtmgsQ0mXBFE1PCOV3yrkFXj7M.png)

为了扩展到多个签名，我们只需使用多条链。如果我们想签署消息 $m$，首先哈希它，然后将其分割成 $v$ 个选定长度的块（如果需要，在末尾添加填充）。然后，使用 $v$ 条哈希链来签署每个块，方法是将块转换为链中的索引并将该索引处的元素添加到签名中。

因此，每个 epoch 我们使用 $v$ 个公钥/私钥对，最终得到 $v$ 个添加到签名中的哈希。例如，在下图中，签名由索引 $1,2,k-1,\dots,1$ 组成（中间还有更多索引）。使用的公钥可以哈希在一起形成单个公钥 $pk$，该公钥存在于更大的 Merkle 树中。

![](https://img.learnblockchain.cn/2026/06/04/yMXCVlY6jjpXZC0XfdITqhY.png)

签名包含来自哈希链的元素以及 Merkle 证明，表明它是验证者承诺的所有公钥的一部分。

结合这两个概念，我们最终得到用于生成和验证签名的哈希链，以及用于支持许多密钥的 Merkle 树。我们在这里看到重叠的力量了吗？确实，是哈希函数。

![](https://img.learnblockchain.cn/2026/06/04/deFu6WN3IrQwhT3157p90t3ONk.jpg)

#### 添加目标总和

然而，当前签名方案的描述存在一个问题：攻击者可以使用不同的链伪造有效的签名。让我们看一个使用三条链的小例子。如果验证者 $V$ 打算签署消息 $m$，该消息编码为索引 $(1,2,4)$，那么有效签名将是 $(H(x_0), H^2(x_1), H^4(x_2))$。在这种情况下，攻击者可以假装验证者 $V$ 实际签署了一条不同的消息 $m'$，如果该消息编码为 $(2,2,5)$，因为每个索引都等于或大于原始索引。伪造的签名将是 $(H(H(x_0)), H^2(x_1), H(H^4(x_2)))$，攻击者可以在不知道私钥 $x_0, x_1, x_2$ 的情况下创建它。

这可以通过添加一个对所使用索引的校验和来解决；在上面的例子中，$(1,2,4)$ 会给出校验和 $1+2+4=7$，任何对不同的（伪造）消息的伪造签名至少会大于 $7$ 并且无法通过验证。但请注意，这个值本身也需要被签署，这就需要更多的哈希链来解决这个问题。作为解决方案，LeanSig 采用了一种**目标总和**方法，其中有一个固定的目标值 $T$，校验和应加起来等于该值，从而消除了签署校验和所需的额外链。使校验和等于 $T$ 是通过在开始时用随机值哈希消息，并根据需要重新采样随机性来完成的。

#### 完整图景

![](https://img.learnblockchain.cn/2026/06/04/7bpqvxVWnFbzNt72SjYXWU0SM.png)

这就是 leanSig 的高级思想：验证者在注册时通过 Merkle 根承诺 $L$ 个密钥对。然后，在每个 epoch 中，它使用 $v$ 个公钥来签署已哈希并编码为 $v$ 个索引的块。然后签名由 $v$ 个哈希和附带的用于所使用公钥的 Merkle 证明组成。验证者完成哈希链，并随后验证这些公钥确实属于验证者承诺的 Merkle 树。

附加说明。如何安全且针对此用例以最佳性能从 $m$ 编码到索引数组 $(i_0,\dots,i_{v-1})$ 目前仍在积极研究中。我们已知需要一种**不可比较编码**，其中对于两条消息 $m_1$ 和 $m_2$，不可能出现 $m_2$ 的每个索引都大于 $m_1$ 的索引的情况。如果没有这个属性，就可能伪造签名。

### LeanSig 的聚合：引入 leanVM

定义的签名方案适用于单个方，即我们为以太坊考虑的用例中的单个验证者，并且与 BLS 的情况一样，我们希望有一个聚合选项。不幸的是，哈希没有我们可以利用的代数结构。然而，总是有选项可以使用**简洁知识论证** (SNARK) 来聚合签名。在这种情况下，公共输入是公钥，见证由要验证的签名组成，生成的证明使我们都相信所有签名都通过了检查。当然，由于迁移到后量子签名的目标也必须与抗量子 SNARK 相结合，即 pqSNARK。

为了解决这个问题，团队一直在开发一个最小的 zkVM，称为 [leanVM](https://github.com/leanEthereum/leanMultisig)，它本身是基于哈希的。zkVM 的设计灵感来自 Cairo。主要设计目标是创建一个非常简单的 zkVM，可以完全形式化验证，并且针对聚合基于哈希的签名和支持递归的特定任务。再说一遍：目标是完全形式化验证这个 zkVM！形式化验证工作将使用 Lean，而这些名称重叠显然纯属巧合。请注意，目标是形式化验证 zkVM 本身以及在其上运行的程序，例如 XMSS 签名聚合。

如果你付出如此努力来构建一个安全、快速的用于基于哈希的签名聚合的 zkVM，为什么不将其用于 XMSS 签名之外的其他用途呢？这就是为什么它也将用于执行层，计划在那里使用 SPHINCS 签名，这些签名也是基于哈希的并且需要聚合。

zkVM（参见 [文档](https://github.com/leanEthereum/leanMultisig/blob/main/minimal_zkVM.pdf)）具有非常小的指令集架构，只有 4 个操作码用于加法 (ADD)、乘法 (MUL)、跳转指令 (JUMP) 和内存指令 (DEREF)。此外，目前有 2 个预编译用于执行哈希和扩域运算。再次强调，所有这些研究都在不断发展，对此的更改是意料之中的。

对于证明，使用了 Plonky3，Lean Ethereum 团队与 Plonky3 团队合作进行了优化，以提升 CPU 相关架构和 zkVM 使用的低级功能的性能。虽然许多 zkVM 团队正在为 GPU 进行优化，但由于所有这项工作都针对以太坊验证者及其应能使用非常简单的硬件，因此 CPU 优化一直是主要焦点。此外，对乘法等低级功能的每项改进都是一种增益，因为这些功能在电路中会被重复使用。

### 我们在优化什么

现在我们已经看到了各个相互关联的部分，让我们退后一步，看看我们正在尝试优化什么。

由于签名需要在网络上共享，我们追求更小的签名大小。更小的签名意味着更少的哈希链，而这如何影响需要完成的哈希量取决于所选的编码方法。

另一个单独的参数是公钥 Merkle 树中叶子的生命周期参数 $L$。如果 $L = 2^{26}$，则相当于以太坊验证者约 10 年的活动（[参考文献](https://learnblockchain.cn/video/play/1827)）。你不希望过于频繁地重新生成密钥，但更大的树也意味着更大的签名大小、额外的哈希，最重要的是对存储如此大树的记忆体影响。

此外，由于签名聚合是使用 zkVM 完成的，我们旨在最小化验证器中的哈希。验证的所有操作都在电路内完成，这很昂贵。此外，哈希函数的选择在这里很重要；Poseidon 在电路内性能更好。

对于 leanVM 的基准测试，重要的是要记住每秒可以聚合多少个 XMSS 签名、递归的速度有多快以及证明大小。虽然优化电路内单个哈希函数的性能很重要，但团队在 [ZK Podcast 第 394 集](https://www.youtube.com/watch?v=YWkyvTrwtQU) 中解释说，总性能也取决于**粘合逻辑**，例如形成哈希链和 Merkle 树以及将消息编码为索引。

为 leanSig 提出的改进之一集中在编码方法上，旨在生成降低验证器工作负载的索引。然而，在电路中实例化该编码算法结果相当昂贵，并且会中止非微不足道的时间；这给团队带来了更多研究工作以支持这一改进。

### 关于哈希函数选择的些许讨论

关于这一切中实际使用的哈希函数，还有更多细节。首先，不同点使用的（哈希函数的实例化）并不完全相同。哈希链内部的哈希与 Merkle 证明中的哈希略有不同，而用于 zkVM 的哈希也可能不同。

关于哈希函数的选择，目前尚无定论。我们已经讨论了 Poseidon 在电路内哈希中更受青睐，而 SHA-3 可能不是因为性能而是因为安全性而被优先考虑；它已经存在了相当长一段时间。

Poseidon2 由于性能似乎是最好的候选者，但在 [EthProofs 电话会议 #8](https://www.youtube.com/watch?v=7Jxq3YU8GUY) 中宣布，Lean Ethereum 正在将重点转移到 Poseidon1，因为事实证明 Poseidon2 的攻击面与 Poseidon1 不同，因此它无法像之前假设的那样继承安全分析。考虑 Poseidon2 的理由是它已经经过了 7 年的审查，这似乎合理，考虑到中本聪选择 SHA-256 时它已经 7 岁，而 Vitalik 选择 Keccak 时它也是 7 岁（[参考文献](https://learnblockchain.cn/video/play/1826)）。有了这一新见解，时钟重置为 3 年，即 Poseidon2 论文实际发表的时间。

（该 Meme 在 EthProofs 电话会议 #8 上展示）

![](https://img.learnblockchain.cn/2026/06/04/aLCvBXgTWXFLoMXiptapuTHqsU.png)

由于哈希函数的选择至关重要，以太坊提供了大量资助和奖励以鼓励密码分析研究工作（阅读此 [网站了解更多信息](https://www.poseidon-initiative.info/)）。在重点转移之后，这现在主要考虑 Poseidon1。

### 总结

在未来的文章中，我们希望更深入地探讨 leanVM 和编码机制的研究进展。所有这些努力也可能服务于其他区块链，甚至其他类型的技术，只要其用例与以太坊的情况一致。要了解更多细节，我们推荐来自 2025 年 10 月 leanVM/PQ 研讨会的 [这些资源](https://github.com/leanEthereum/pm/blob/main/workshops-and-interops/2025/lean-week-cambridge/index.md)、[零知识播客](https://zeroknowledge.fm/podcast/390/) 上关于 Lean Ethereum 的短系列以及 Lean 共识研发 [网站](https://leanroadmap.org/)。

虽然我们以量子威胁的描述作为本文的开头，但这项研究工作的整体基调要积极得多。我们没有深入探讨 Lean Ethereum 升级提案的全部范围（这是一项持续的努力），但其主要思想是利用这样一个事实：无论如何都需要进行大的改动，所以让我们充分利用这一点。后量子签名要大得多，我们非但不能降低性能，反而可以最终得到一个更快、更强的系统。

### 参考文献

\[1\] Boneh, D., Lynn, B., & Shacham, H. (2001). _Short signatures from the Weil pairing_. ASIACRYPT 2001. [https://www.iacr.org/archive/asiacrypt2001/22480516.pdf](https://www.iacr.org/archive/asiacrypt2001/22480516.pdf)

\[2\] Boneh, D., Drijvers, M., & Neven, G. (2018). _Compact multi-signatures for smaller blockchains_. ASIACRYPT 2018. [https://eprint.iacr.org/2018/483.pdf](https://eprint.iacr.org/2018/483.pdf)

\[3\] Drake, J. _Pragmatic signature aggregation with BLS_. Ethereum Research. [https://ethresear.ch/t/pragmatic-signature-aggregation-with-bls/2105](https://ethresear.ch/t/pragmatic-signature-aggregation-with-bls/2105)

\[4\] Drake, J., Khovratovich, D., Kudinov, M., & Wagner, B. (2025). _Hash-Based Multi-Signatures for Post-Quantum Ethereum_. Cryptology ePrint Archive, Paper 2025/055. [https://eprint.iacr.org/2025/055](https://eprint.iacr.org/2025/055)

\[5\] Goldberg, L., Papini, S., & Riabzev, M. (2021). _Cairo - a Turing-complete STARK-friendly CPU architecture_. Cryptology ePrint Archive, Paper 2021/1063. [https://eprint.iacr.org/2021/1063](https://eprint.iacr.org/2021/1063)

\[6\] Khovratovich, D., Kudinov, M., & Wagner, B. (2025). _At the Top of the Hypercube - Better Size-Time Tradeoffs for Hash-Based Signatures_. Cryptology ePrint Archive, Paper 2025/889. [https://eprint.iacr.org/2025/889](https://eprint.iacr.org/2025/889)

\[7\] Drake, J., Khovratovich, D., Kudinov, M., & Wagner, B. (2025). _Technical Note: LeanSig for Post-Quantum Ethereum_. Cryptology ePrint Archive, Paper 2025/1332. [https://eprint.iacr.org/2025/1332](https://eprint.iacr.org/2025/1332)

\[8\] Buchmann, J., Dahmen, E., & Hülsing, A. (2011). _XMSS - A Practical Forward Secure Signature Scheme based on Minimal Security Assumptions_. Cryptology ePrint Archive, Paper 2011/484. [https://eprint.iacr.org/2011/484](https://eprint.iacr.org/2011/484)

\[9\] Merkle, R. C. (1979). _A Certified Digital Signature_. [https://scispace.com/pdf/a-certified-digital-signature-2quebo9evb.pdf](https://scispace.com/pdf/a-certified-digital-signature-2quebo9evb.pdf)

>- 原文链接： [hashcloak.com/blog/how-e...](https://hashcloak.com/blog/how-ethereum-plans-to-replace-bls-with-post-quantum-signatures)
>- 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～

0 条评论

以太坊计划如何用后量子签名替代BLS签名 - HashCloak

当前以太坊共识中签名是如何使用的

相关文章

0 条评论

请输入验证码

登链社区服务条款与隐私政策

登链社区服务条款与隐私政策

登链社区用户服务条款

一、定义

二、服务内容

三、用户权利义务

四、知识产权保护

五、有限保证及服务免责

六、服务变更、中断或终止

七、通知和送达

八、投诉处理

九、法律适用、争议管辖及其他

隐私政策

一、登链社区可能收集的信息内容

二、登链社区收集信息的使用规则

三、登链社区如何共享、转让、公开披露您的个人信息

四、登链社区如何使用 Cookie 和同类技术

五、登链社区如何保护和保存您的个人信息

六、您如何管理个人信息

七、未成年人信息的保护

八、隐私政策的修订和更新

如何联系我们