以太坊验证者的后量子公钥注册中心设计探索

作者： Thomas Coratger, Tom Wambsgans, Ladislaus, Thomas Thiery, Justin Drake

如 Strawmap 路线图 所述，保护以太坊免受大规模量子计算机的威胁，这是迫在眉睫的首要任务。这一转型中的关键里程碑是将我们的权益证明共识从 BLS 签名迁移到后量子（PQ）安全的签名方案。

本文旨在探讨后量子公钥注册表的概念和设计空间。重要的是，实际过渡将分阶段进行：公钥注册表分叉将首先发生，使验证者能够注册其 PQ 密钥，然后在几个分叉之后进行实际的签名切换。这种逐步部署为网络提供了充足的时间来构建状态、监控漏洞并最终确定底层密码学原语。最终，这里产生的讨论将成熟为一个正式的以太坊改进提案（EIP）。

历史背景与注册表的必要性

在当前的权益证明设计中，验证者公钥（BLS12-381）通过执行层的存款合约注册，随后由共识层处理。BLS 签名在聚合方面非常高效，但它们依赖于椭圆曲线密码学，而 Shor 算法可以完全破解这种密码学。

过渡到后量子签名给网络参与者带来了重大的操作困难。生成并安全存储这些新密钥要求验证者访问其冷存储，执行新的密钥生成脚本，并与其最敏感的密码学材料进行交互。由于这是一项高摩擦、高风险的操作，我们计划将这些密钥的注册与其在共识中的实际使用解耦。专用的公钥注册表充当了一个关键的热身阶段，为验证者提供一个低压环境，使其能够安全管理其硬件设置，并在实际协议升级之前逐步提交其后量子身份。

第 1 部分：基础 — 密码学核心：扩展 Merkle 签名方案 (XMSS)

在探索后量子数字签名时，密码学界通常将设计空间分为几个主要家族：基于格的、基于编码的、基于同源的、多元的和基于哈希的。虽然像基于格的签名（例如，通过像 LaBRADOR 这样的证明系统聚合 Falcon 签名）等解决方案被广泛研究，但为它们选择安全参数非常复杂，其安全证明通常依赖于技术影响具有不确定性的后量子环境。

最终，基于哈希的签名成为以太坊的最强候选方案。它们因其概念简单、易于实现，以及依赖于非常保守的标准模型密码学假设（如基本的抗碰撞性和抗原像性）而非复杂的代数结构而脱颖而出。

基于哈希的签名面临两个主要挑战：它们本身不支持聚合，并且需要严格的状态管理以防止密钥重用。虽然聚合问题必须通过密码学证明单独解决，但以太坊权益证明共识的结构化性质为后者提供了巨大优势：验证者被要求每个 epoch 恰好签名一次。

这条严格的时间线使我们能够绕过完全无状态方案（如 SPHINCS+，它在验证时需要大约 10 倍的哈希运算）的显著验证开销，而是利用一种同步（有状态）的签名方案。扩展 Merkle 签名方案 (XMSS) 完美契合此模型，将每个签名绑定到特定的顺序位置。请注意，在 XMSS 下，双重签名会泄露足够多的中间哈希信息，从而使攻击者能够伪造该叶子的签名，从而破坏密钥。

XMSS 如何工作

要理解为什么 XMSS 如此有效，有助于从哈希函数的基本属性开始，逐步分解其构造。

构建块：哈希链

由于密码学哈希函数是单向的（抗原像性），你无法轻易从输出推导出输入。哈希链利用这一点，获取一个秘密起始值（私钥）并重复哈希预定的次数，以产生最终值（公钥）。

如果哈希链有 256 步，揭示第 100 步的中间哈希值就能证明你知道秘密，因为验证者只需将该值再哈希 156 次，看是否与公钥匹配。这就是一次性签名 (OTS) 的基础。为了签署消息，你将消息转换为一个数字（例如，100），并揭示该链中特定位置的哈希值。

并行链以确保安全

单个哈希链存在一个关键漏洞：如果你揭示位置 100 的哈希值来签署消息，攻击者只需将你揭示的签名值再哈希一次，就可以伪造映射到位置 101 的消息的签名。

为了防止这种伪造，该方案将消息分成多个较小的块，为每个块使用一个并行的哈希链，并强制执行一个严格的数学约束：目标总和。为了使签名有效，所有块值（链位置）的总和必须等于一个特定的预定数字。

由于这个约束，如果攻击者试图通过将一个链向前哈希（这会增加其数值）来伪造签名，他们伪造签名的总和将超过目标值。为了重新平衡总和并产生有效的编码，攻击者将被迫减少另一条链上的值。减少值需要沿着链向后移动（逆转哈希函数）。由于密码学哈希函数是严格单向的（抗原像性），这种向后移动在计算上是不可行的，从而使 W-OTS 签名完全安全。

尝试伪造分析

攻击为何失败

为了将第一条链向前伪造 ($2 \rightarrow 3$)，攻击者只需将揭示的值再哈希一次。然而，这会使总和增加到 10，违反了协议严格的目标约束。

为了维持必须的目标总和 9，攻击者被迫减少另一条链上的值 ($3 \rightarrow 2$)。由于密码学哈希函数是严格单向的（抗原像性），沿着链向后移动以减少值在计算上是不可行的，使得伪造的签名无效。

扩展到多次签名

由于揭示这些中间哈希值会消耗链，这种设置只能安全地使用 一次。为了在验证者的生命周期内签名数千个区块，我们需要一个多次签名方案。

XMSS 通过生成一个大规模独立的一次性签名密钥对序列来解决这个问题。所有这些 OTS 实例的公钥被放置为一个大型 Merkle 树的叶子。这个 Merkle 树的根成为验证者的实际全局公钥——这是将提交给公钥注册表的小而紧凑的数据点。

签名和验证过程

当验证者需要为特定 slot 签名一个区块时，他们移动到其树中下一个未使用的叶子。最终签名包含：

1. 当前消息的 OTS 签名。
2. 该叶子的特定 OTS 公钥。
3. 连接该叶子到全局 Merkle 根的 Merkle 认证路径（兄弟哈希）。

验证者只需使用 OTS 公钥检查 OTS 签名，然后验证 Merkle 路径以确保该特定叶子是验证者注册的根的有效部分。

注册什么：密钥大小与实际影响

现在我们理解了 XMSS 的概念设计，注册表自然要问的问题是：验证者到底需要提交什么，它有多大？

公钥：52 字节

每个验证者的 XMSS 公钥由两部分组成：

作为比较，BLS12-381 公钥是 48 字节。后量子公钥仅大 4 字节——这是一个显著的结果，意味着注册表每个验证者的存储开销可以忽略不计。在规模上，注册 100 万个验证者只需要在状态中存储约 52 MiB 的公钥。

签名：3,112 字节

每个 slot 的 XMSS 签名包含：

这远大于 BLS 签名（96 字节），这也是通过 SNARK 进行聚合至关重要的原因（见下一节）。

私钥：消费级硬件可管理

一个朴素的实现需要一次性计算并存储包含 $2^{32}$ 个叶子的完整 Merkle 树——需要 TB 级的存储和巨大的内存。相反，我们对该方案的参考实现采用了一种 自顶向下树 策略。它将巨大的树分成上半部分（高度 16）和 $2^{16}$ 个底部树（每个高度 16）。

这将密钥生成和签名的空间复杂度降低到 $\mathcal{O}(\sqrt{\text{生命周期}})$，意味着它只需要几 MB 的 RAM 和磁盘空间。验证者无需持有整个结构，只需存储顶部树并缓存仅两个底部树的滑动窗口：当前 底部树和 下一个 底部树。缓存下一个树是一个实际需要；它确保了当当前底部树耗尽时（大约每 65,536 个 slot，或约 9 天）能够无缝过渡，而不会错过任何证明。

至关重要的是，这些缓存的树结构不具有密码学敏感性。 它们只是通向全局 Merkle 根的中间公共哈希。它们可以以明文形式存储在标准磁盘上。唯一 实际的密码学秘密是 32 字节的 PRF 种子。

为什么选择 KoalaBear？

该方案中的所有算术都在 KoalaBear 素域上执行，模数为：

$p = 2^{31} - 2^{24} + 1$

这是一个 31 位素数，意味着每个域元素适合一个 32 位字（4 字节）。选择小域是故意的并且对性能至关重要。因为 XMSS 方案和 SNARK 聚合器都主要进行域算术，每个乘法和加法都必须尽可能快。

一个 31 位素数有三个关键优势：

• SIMD 并行性：4 字节元素紧密地打包到 CPU 向量寄存器中。在 x86 处理器上，AVX2 指令可以并行处理 8 个域元素（256 位寄存器），AVX512 可以一次处理 16 个（512 位寄存器）。在 ARM 处理器上（包括 Apple Silicon），NEON 指令每个向量处理 4 个元素。这意味着单个 CPU 指令可以同时执行 4 到 16 次域乘法。
• 无溢出风险：将两个 31 位值相乘最多产生一个 62 位结果，可以轻松容纳在 64 位寄存器中。这消除了多精度算术或进位传播的需要，使模约化变得微不足道。
• 高二次幂性：乘法群的阶为 $p - 1 = 2^{24} \times 127$，给出二次幂性为 24。虽然看起来很小，但这在使用交织 Reed-Solomon 码时对于像 WHIR 这样的多元多项式承诺方案来说并不是限制因素。此外，在五次扩域（$q = p^5$ 上的 $\mathbb{F}_{q}$）上的操作提供了 WHIR 所需的 128 位安全性。

除了原始算术速度之外，选择 KoalaBear 还有一个特殊原因：立方映射 $x \mapsto x^3$ 是乘法群的一个置换。这是因为 $\gcd(3, p - 1) = \gcd(3, 2^{24} \times 127) = 1$。这一特性对于 Poseidon 很重要：哈希函数需要一个 S-box（非线性替换层），该 S-box 是域上的置换多项式。由于立方映射已经是一个置换，S-box 可以使用度 3——尽可能小的度。较低度的 S-box 意味着每轮更少的乘法，这直接转化为更快的哈希速度以及 SNARK 电路内更少的约束。作为比较，其他域如 BabyBear（$p = 2^{31} - 2^{27} + 1$）需要度 7 的 S-box，基于 BN254 的 Poseidon 使用度 5。

度 3 S-box、高二次幂性和 SIMD 友好的元素大小的结合，使得 KoalaBear 成为非常适合此工作负载的域。

生产方案参数

下表列出了迄今为止在我们的精简共识开发者网络中使用的完整生产配置。为了易于理解，参数按其控制的系统部分进行分组。

生命周期和消息

这些参数定义了密钥的整体范围和它所签名的内容。

消息编码（消息如何变为链位置）

从上面的 XMSS 概述中回想一下，签署消息意味着揭示哈希链中的中间值。但首先，消息必须转换为一组数字，告诉签名者在每条链的 何处 进行揭示。这种转换称为 编码，这些参数控制其工作方式。

消息与一些新鲜的随机性一起哈希，产生 46 个数字（每条链一个），每个在 0 到 7 之间。这些数字是块值。给定链的块值告诉签名者从其秘密起点开始进入该链多少步，然后揭示该值。然后验证者从该点走到链的终点：最大链长为 7，块值为 5 意味着签名者揭示了进入 5 步的值，而验证者将其再哈希剩余的 2 次 ($7 - 5$) 以到达终点。

关键的安全约束是 目标总和：46 个块值必须正好加起来为 200。这就是使编码不可比的原因——没有有效的码字可以通过将每条链向相同方向移动而从另一个码字到达。由于看到签名的攻击者只能向前哈希揭示的值（这增加了一个块值），他们将不得不减少其他一些块以保持总和为 200。减少一个块意味着反转哈希，这在计算上是不可行的。固定总和加上链的单向性阻止了伪造。

如果 46 个块值是均匀采样的，它们的期望总和约为 161 ($46 \times 3.5$)。目标 200 被故意设置在此平均值之上：因为验证者只走每条链的剩余步数，更高的目标总和意味着验证时更少的哈希评估——这里为 $46 \times 7 - 200 = 122$ 次链哈希，而如果目标设在平均值则为 161。为了使块值首先变得均匀（以便可预测地达到目标），消息哈希使用了一种 中止超立方体构造。它拒绝采样哈希输出，每当输出元素落在均匀范围之外时就丢弃并重新哈希。然后签名者只需抽取新鲜的随机性并重新编码，直到 46 个值恰好加起来等于 200，最多尝试 100,000 次；在实践中，在此界限内总能找到有效的编码。

注意：由于在 SNARK 上下文中为签名聚合优化这些哈希函数是一个高度活跃的研究领域，确切的基础编码算法仍在变动中。下面的参数代表当前的工作配置，但随着密码学为主网最终确定，具体值可能会发生变化。

哈希函数和内部大小

这些参数控制整个方案中使用的哈希函数。所有大小都以域元素表示；每个 KoalaBear 域元素是 4 字节，因此乘以 4 得到字节大小。

树结构和密钥派生

通过 leanVM 和 pqSNARK 进行签名聚合

基于哈希的签名本身不支持我们享受 BLS 时所拥有的公开聚合功能。大约有 100 万个验证者各自广播约 3.1 KiB 的签名，聚合器的带宽需求将轻易超过每个 slot 3 GiB，这对于以太坊的 slot 约束来说是完全不可行的。

解决方案是使用简洁的知识论证（pqSNARK）来聚合这些同步的多次签名。为了优雅高效地处理这个问题，我们利用 leanVM，一个极简的、受 Cairo 启发的 zkVM，专门为以太坊的后量子签名验证设计。leanVM 构建在一个高度优化的证明栈上，利用 SuperSpartan 和特定于 AIR 的优化、Logup 用于总线交互，以及 WHIR 用于多元多项式承诺。至关重要的是，WHIR 允许简单的多项式堆叠，避免了对每个单独列进行 Merkle 承诺，并显著减少了最终证明大小。

并非在一个巨大的电路中同时验证大量签名，leanVM 使用 递归聚合。协议将签名者分成可管理的组，聚合器验证他们的 XMSS 签名以创建子证明，然后递归地在程序 内部 运行 leanVM 验证器以将这些子证明合并为一个最终证明。

由于共识层必须确切知道谁参与了以处理奖励、不活动泄漏、分叉选择权重和罚没，聚合有效载荷包括 leanVM 证明和一个 签名者位域（类似于当前 BLS 证明中使用的位列表）。leanVM 电路被明确约束为证明对于此附带位域指示的精确公钥子集存在有效签名。

根据最近在高端消费级硬件（例如，M4 Max CPU）上运行的基准测试，leanVM 实现了大约每秒 1k 个 XMSS 签名的证明吞吐量。在其经过验证的安全体制中——通过 KoalaBear 域的 5 次扩域提供 123 位的可证明安全性——生成一个 2 对 1 的递归证明不到一秒，并产生一个大约 128 KiB 到 350 KiB 的高度紧凑的最终证明大小，具体取决于 PCS 速率。这种递归方法扩展性良好，使得链上验证和网络传播对于以太坊的 slot 预算非常实用。

哈希函数：一个开放的设计空间

由于验证过程主要由哈希函数评估主导，我们的 pqSNARK 聚合器的效率在很大程度上依赖于所选的哈希函数。

最初，Poseidon2 成为主要候选。它在有限域上原生运行，使其针对现代算术化框架和像 leanVM 这样的 zkVM 高度优化。然而，最近针对代数哈希函数的密码分析和攻击技术（例如 eprint 2026/306 中详述的）迫使我们重新考虑仅仅依赖 Poseidon2。

由于我们尚未做出最终决定，公钥注册表的设计必须保持灵活。为此，我们可能允许使用各种哈希函数生成公钥——这种设计称为 多哈希公钥注册表。

当前哈希候选

这直接影响注册表设计：注册表必须具有 哈希函数敏捷性，可能需要在每个公钥旁边存储一个哈希函数标识符，以便网络在过渡期间支持多个哈希函数，并在其中一个被弃用时强制迁移。

第 2 部分：注册表设计考量

注册协议机制

注册协议本身需要具体的机制，以确保在不压倒信标链的情况下实现平滑、安全和抗 sybil 的过渡。由于此升级从根本上改变了验证者身份，密钥注册的生命周期必须仔细管理。以下是关于验证者如何实际注册其密钥的建议架构：

• 交付和授权：为了安全地将后量子身份绑定到现有验证者，交付机制可能利用一个新的共识层操作（例如，一个 PostQuantumRegistration 消息）。此提交必须被明确授权，以证明对验证者索引的绝对所有权。对于拥有 0x01 或 0x02 执行层提款凭证的验证者，这将需要来自提款地址的 L1 签名。对于传统的 0x00 凭证，则需要来自当前活跃的 BLS 密钥的签名。至关重要的是，此注册消息还必须包含一个 所有权证明——一个对注册有效载荷有效的单一 XMSS 签名。如果没有这个，协议将盲目接受 52 个原始字节，这意味着一个密钥生成设置静默失败的验证者将在数年后实际签名分叉时才发现故障。一旦两个签名都被验证，网络接受并将 52 字节的 XMSS 公钥绑定到信标状态中的验证者记录。为了支持哈希函数敏捷性，这种绑定不是永久的；注册消息应包含一个序列号或版本字段，以允许验证者将来更新或轮换其密钥。

• 每块处理上限和状态增长：为了保护网络在大规模注册事件期间免受状态膨胀和计算峰值的影响，协议必须强制执行严格的处理队列。类似于现有的验证者激活和退出变动限制，我们建议限制每个 slot 处理的注册数量（例如，MAX_PQ_REGISTRATIONS_PER_BLOCK = 16）。广播到 gossip 网络的注册将停留在本地内存池中；区块提议者将打包最多不超过限制的数量到其区块中。这确保了区块验证时间保持可预测的低水平，并且产生的状态增长在数周或数月内被平滑处理，防止节点资源需求的突然激增。

• 激励和过渡时间线：分阶段部署的一个主要风险是，在 BLS 签名正式弃用之前发生最后一刻的蜂拥注册，这可能压垮处理队列，并使活跃验证者无法签名，从而威胁网络最终性。为了避免这种情况，部署将包含鼓励早期行动的机制。在早期热身阶段参与的验证者可能被授予最终后量子激活队列中的优先位置。或者，对早期注册者给予适度的临时证明奖励提升（例如，基础奖励的轻微乘数）可以有效推动采用。最后，随着硬截止日期的临近，协议可以采用大棒方法——逐步对未能注册后量子密钥的验证者应用不活动泄漏或启动强制退出，确保在最终开关切换之前，活跃集仅包含 PQ 就绪的节点。

哈希函数敏捷性

由于哈希函数尚未最终确定，注册表的设计必须考虑敏捷性。一种方法是允许验证者注册不同哈希函数标识符下的密钥，这意味着每个注册条目将携带 52 字节的公钥以及一个指示所选哈希函数的标签。如果某个函数后来被破解，受影响的验证者将需要重新注册。或者，为了确保稳健的前瞻性而无需未来重新注册的麻烦，协议可以从一开始就强制要求使用两个或三个特定的哈希候选（例如，Poseidon1、BLAKE3 和 SHA-256）。在这种情况下，每个验证者将提前为每个强制要求的哈希函数执行密钥生成，并提交到注册表的最终值将只是这些多个 XMSS 公钥的串联。

由于密钥生成和注册是预先进行的，如果其中一个哈希函数被破解，网络可以迅速切换到替代方案，而无需验证者从头开始重新生成密钥。虽然这种方法提供了出色的前瞻性，但有一个小的权衡：注册的密钥大小从 52 字节增加到 104-156 字节。幸运的是，密钥生成的计算开销是最小的。由于传统的位哈希函数（如 SHA-256、BLAKE3 或 Monolith）在标准 CPU 上的计算速度比像 Poseidon 这样的代数哈希快几个数量级，生成这些备份树在基线密钥生成过程中只增加了很小一部分时间。最终，这种存储和计算的轻微增加对于它所提供的无缝敏捷性来说是一个非常可接受的权衡。这两种解决方案只是各有优缺点，需要进一步探索。

密钥生命周期和激活窗口

XMSS 密钥本质上是在生成时带有一个明确的 激活窗口：一个起始 slot 和由 Merkle 树容量决定的有限数量的活跃 slot。由于密码学构造将每个签名绑定到特定的顺序位置，密钥自然不能在此窗口外签署消息。因此，没有必要在注册表中显式记录这些边界或在协议级别强制执行；一旦验证者用尽了可用的叶子，他们就无法再产生有效签名。

为了内存效率，激活 slot 与 65,536 个 slot（约 9 天）的边界对齐。这对验证者是透明的——密钥生成工具会自动处理对齐。

序列化

所有数据结构都使用 SSZ（简单序列化），这是以太坊共识层的标准序列化格式。公钥是一个固定大小的 52 字节值，使其可以直接包含在现有的信标状态验证者记录中，与当前的 BLS 密钥一起。

验证者的实际考量

注册后量子密钥是一次性操作，但它涉及生成一个巨大的 Merkle 树并安全存储结果材料。以下是验证者在实际操作中与当前操作相比应预期的情况：

• 密钥生成计算量大但内存占用小：验证者运行一个离线工具，将 32 字节的种子扩展为完整的 XMSS 树。由于树有 $2^{32}$ 个叶子，这涉及数十亿次哈希评估。参考实现使用 SIMD 优化在可用的所有 CPU 核心上并行化此过程。虽然在现代多核机器（例如 8-16 核）上这个过程需要数小时，但由于自顶向下树策略，它以 $\mathcal{O}(\sqrt{\text{生命周期}})$ 的空间运行。这意味着任何只有几 MB 空闲 RAM 的标准机器都可以生成密钥。由于涉及主秘密，这一一次性操作 必须 在气隙或冷存储机器上完成。
• 秘密 vs. 操作密钥：今天，一个加密的 BLS 验证者密钥库大约为 1 KiB。在后量子时代，实际的密码学秘密（32 字节的 PRF 种子）仍然很小，必须严密保护和备份。丢失它意味着失去签名能力，且无法恢复。然而，操作密钥文件——它缓存了非秘密的顶树和当前底树对，以便快速、轻量级签名——以 SSZ 格式序列化，大小约为几十 MB。虽然远大于 BLS 密钥，但这个操作文件可以轻松放在消费级 SSD 上。
• 持续签名是轻量级的：一旦密钥生成并且操作文件加载到签名基础设施中，为每个 slot 生成签名只需要少量的哈希评估（走最多 7 步的 64 条链，加上一个 Merkle 路径查找）。这足够快，可以在 12 秒的 slot 预算内轻松在标准消费级硬件上运行。
• 社区驱动的工具：从第一天起，构建密钥生成用户体验就需要强大的利益相关者参与。从信标链启动中学到的一个重要教训是，仅依赖 EF 维护 deposit-cli 随时间成为了一个瓶颈。为了确保可持续的支持、安全审计和功能迭代（如合并），我们设想 PQ 密钥生成工具从一开始就是一个开源的、社区维护的努力，可能由 EF 资助激励。

验证者实际提交到注册表的是 52 字节的公钥以及一个单一的 XMSS 所有权证明签名。这证明了端到端的离线密钥生成工作完美。此提交可以通过标准的链上交易完成，类似于当前的 BLS 密钥存入。私钥永远不会离开验证者的机器。

未解决问题和未来工作

1. 哈希函数最终确定：Poseidon 能否在持续的密码分析中幸存，还是我们需要回退到 SHA-3/BLAKE3（以显著的证明成本为代价）？
2. 注册表更新机制：如果验证者需要切换哈希函数，状态应如何适应密钥轮换或重新注册？
3. 聚合器经济学：谁承担 SNARK 证明的计算成本？是否应通过协议奖励补偿聚合？
4. 兼容期：在过渡期间，协议是否应同时支持 BLS 和 XMSS 签名？
5. 注册表扩展：当前的开发者网络仅支持数百个验证者。生产环境以太坊有约 100 万个。聚合树如何扩展？
6. 多项式承诺优化：由于 WHIR 在小域和递归堆叠方面的效率，我们当前依赖它进行多元多项式承诺。我们能否通过完善 Reed-Solomon 交织策略，或完全采用替代多项式承诺方案来进一步缩小证明大小？
7. 密钥生成用户体验和工具：我们如何使密钥生成过程对 solo 质押者来说可访问且万无一失？借鉴 deposit-cli 的经验，我们如何从第一天起就培育一个社区拥有、由资助激励的开源项目来构建这个关键基础设施？
8. XMSS 的标准模型与 ROM：关于将 XMSS 参数从标准模型转移到随机预言机模型 (ROM) 存在持续的争论。虽然依赖 ROM 在密码学上不那么保守，但它会将签名大小缩小到 IPv6 MTU 限制以下，并消除对多个 Poseidon 宽度（16 和 24）的需求。此外，由于 SNARK 聚合器已经依赖 ROM，标准模型 XMSS 可能过于严格。我们是否应该倾向于一个更强的（更多轮）Poseidon 并接受 ROM 以简化方案？
9. 有限域选择（KoalaBear vs. Goldilocks）：虽然 KoalaBear 非常快，但其 31 位大小和低二次幂性（24）对证明大小施加了严格限制——目前将 leanVM 限制在大约 1600 万 cycles 和 200 万 Poseidon 以内，以防止 Logup 多重性（multiplicity）溢出。迁移到 64 位域如 Goldilocks 将解决这些溢出约束，允许更大的证明，支持原生存储 CL 余额，并轻松达到 128 位安全性（通过宽度为 8 的 Poseidon 状态），同时最小化 WHIR 研磨。主要的权衡是证明速度，目前在 Goldilocks 上大约慢 2 倍。协议是否应该优先考虑 Goldilocks 的容量和优雅，并预期未来的性能优化？

• 原文链接： ethresear.ch/t/exploring...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～