EIP-8141与MAYO后量子账户方案

Frame transactions 是后量子账户将迎来的最好变化。

我想坦诚地谈一次立场逆转。过去几周里，我一直对 EIP-8141 持怀疑态度。现在不再怀疑了。某件事突然想通了，而 Ethereum 上后量子迁移的形态，在我看来，已经和一个月前非常不同。

这篇文章想解释我最初的反对意见，以及让我改变看法的那个具体领悟。这样，任何仍然和我当时一样犹豫的人，都可以看看同样的论点是否也会改变他们。

我过去对 8141 的看法

说实话，我有三个真实存在的抱怨。

它像是被硬塞进来的。这个 EIP 在被排进 straw map、作为 Hegotia 的头条之前，提前了好几周就被宣布了。光是这个顺序，就足以让我对任何提案保持警惕。但 Hegotia 不会在 2026 年交付（现实点说），这意味着我们其实有时间把这件事真正产品化。硬塞进来的确是个问题。但 runway 比我们想象得更长。两件事都可以是真的。

PQ 故事听起来很空泛。“账户定义自己的签名方案”这句话很好说，成本却很难算。没有针对人们真正想用的后量子算法的快速原生 verifier，任何 PQ 账户的成败都将取决于 gas 经济性。我看不到从 EIP 文本到“这在 mainnet 规模下真的能工作”的清晰路径。

涉及面太大了。一个新的 transaction type。新的 opcodes（APPROVE、TXPARAMLOAD、ENTRY_POINT）。一整套 frame 生命周期，带有 validation prefix 规则和 mempool simulation 约束。这是一个很大的 spec，而仅仅是 PQ 的 framing 本身，并不足以让我觉得有理由扩展到这个程度。

这些就是我当时的前提。它们不是恶意反对意见。但我缺少了最关键的东西。

但后来我突然想通了

EIP-8141 不只是让你选择签名方案。它让账户拥有自己加密逻辑中的每一个字节。

具体来说，我的领悟是这样的：

地址与 cryptographic keys 分离了。EOA transactions 过去依赖于提取出来的地址。但在 EIP-8141 transactions 里，地址是硬编码在 transaction 中的。它现在只是一个地址，与 verification keys 没有关系。

这改变了哪些 PQC schemes 可行。影响很大。

链上 pubkey，而不是哈希到地址

在现有模型中，要验证一个 transaction 是否获得授权，你会提取 public key，对它做 hash，然后把这个结果用作执行账户的地址。这里存在与提取出的地址的 hash 之间的隐含匹配。但现在我们可以把整个 public key 放进账户里（作为 contract data 或 storage data），并用这个 public key 来验证授权。地址和 key data 现在解耦了。

这个重新表述就是全部的卖点。

PQ signature landscape，以字节计

让我们绕个弯，看看可能会用上的 PQC signatures。这些是代表性方案，取自 NIST 流程。

为什么 X Articles 这么讨厌表格？

来源：NIST FIPS 204 · FIPS 205 · FIPS 206 · MAYO Round 2 spec · FAEST v2 spec · Mirath Round 2 spec · SDitH Round 2 spec · CROSS spec v1.2 · NIST IR 8528 · OQS benchmarks 。Verify times 是数量级估计；MPC-in-the-head 的数据应与 Round 2 spec benchmarks 交叉核对。取决于硬件。

用旧模型来看这张表——“pubkey 必须随着每个已签名的 tx 一起在 wire 上传输”——大多数方案看起来都很糟。用新模型来看——“pubkey 存在于 contract code 里，只有 signature 在 wire 上”——就有一个方案跃然纸上，可能只是因为我把它加粗了。

关于表格里没有出现的内容，或者说我从中删掉的内容，有一点说明：这篇文章早期草稿里包含 UOV，它有很小的（128 字节）签名，但 public key 约 278 KB。即使采用链上 pubkey 模型，每个账户四分之一 MB 的 state footprint 仍然有问题——它甚至放不进今天的 contract size limits，即使把这些限制提高，随着账户数量增长，部署成本和放大效应也会使它成为错误的默认选择。MAYO-2 让我们在多变量家族中获得签名大小上的收益，同时避免 UOV 级别的 state footprint。这才是值得围绕其构建的方案。

为什么 MAYO 突然有意义了

关于多变量 signature schemes 的传统观点是，它们巨大的 public keys 会扼杀它们。当 key 不在 wire 上时，这种观点会——部分地——被颠倒。

我说“部分地”，是因为 UOV 的四分之一 MB pubkeys 仍然太大。但 MAYO-2 是这个家族中达到甜点位的参数集：signature size 小到足以在 per-tx 层面产生意义，pubkey 小到可以舒适地放进 contract bytecode 里。

MAYO-2 signature：180 bytes。大约比 ML-DSA-44 小 13 倍，比 Falcon-512 小 3.7 倍，并且是在 NIST standards set 中，带有可驻留在 code 中且能放进链上的 pubkey 的最小 PQ signature。每笔 transaction 都保持便宜。5,488-byte 的 public key 是部署成本，不是每笔 tx 的成本。

MAYO-2 pubkey：5,488 bytes。放得下。~5.4 KB 完全在 24 KB contract size cap 之内，也在 EVM contract model 能容纳的范围内。它比 MAYO-1 的 1,168 bytes 大，但这个取舍是值得的：之后每笔 transaction 都能使用 180-byte 的 signatures。

这个取舍是：在部署时付一次成本，把一个约 ~5.4 KB 的 pubkey 存进 contract code；之后每笔 transaction 付约 180 bytes 的 signature calldata 成本。对于一个生命周期内要签名数十亿笔 transaction 的链来说，per-tx 成本才是真正重要的。规模化下的 storage amortization 是我们已经知道怎么做的一件事。

伪 EVM：一个 MAYO 账户的 VERIFY frame

下面是一个 MAYO 账户的 VERIFY frame，假设在 0x10 处有一个假设中的 MAYO_VERIFY precompile。signature 通过 frame calldata 传输；pubkey 存在于 bytecode 中。（用等宽字体会更好看，但 X articles 真的很糟糕。）

// VERIFY frame entrypoint. 由 ENTRY_POINT（0xaa）调用。 // calldata: [sig (180 B) || msgHash (32 B)] PUSH0 // 自身代码中的偏移 PUSH2 0x1570 // MAYO-2 pubkey length = 5488 PUSH2 0x0100 // 在 memory 中的加载目标 CODECOPY // pubkey <- 我自己的 bytecode CALLDATACOPY 0x1670 0x00 0x0D4 // sig || msgHash -> mem // staticcall MAYO_VERIFY(pubkey, sig, msgHash) PUSH1 0x20 // retSize (bool) PUSH1 0x00 // retOffset PUSH2 0x1644 // argsSize = 5488 + 180 + 32 PUSH2 0x0100 // argsOffset PUSH1 0x10 // MAYO_VERIFY precompile GAS STATICCALL PUSH1 0x00 MLOAD ISZERO PUSH1 0x2A JUMPI // 失败则 revert PUSH0 PUSH0 PUSH0 // scope = execute APPROVE // authorize this frame tx

关键洞见是：CODECOPY 从 contract 自身的 bytecode 中读取 pubkey。每笔 transaction 都没有额外的 calldata 开销，而 code load 的成本已经由 intrinsic frame cost 支付了。你没有付两次钱。

这改变了什么

在 8141 ship 之前，值得思考的四个下游影响。

Precompiles 比 opcodes 更重要。新的 opcodes（APPROVE、TXPARAMLOAD、ENTRY_POINT）是 8141 的显性部分，但它们并不是决定 PQ accounts 是否可用的部分。verifier precompiles 才是。Opcodes 告诉你如何分发；precompiles 告诉你分发过去的东西是否负担得起。

State pricing 变得有意思了。一个约 ~5.4 KB 的 MAYO-2 pubkey 作为 contract code 存储时，每次使用都很便宜，但对于数百万账户来说，这仍然是一个值得认真考虑的部署成本。部署时成本与 per-tx 成本之间的权衡，是 gas model 还没有真正被压力测试过的一种新模式。值得 profiling。

Crypto-agility 不再只是口头宣传（在有限范围内）。每个账户都可以选择方案，意味着真正的 hybrid deployments 变得可能。今天 ECDSA，明天 ECDSA+FN-DSA，后天纯 MAYO。没有 fork。没有大规模迁移事件。问题在于：“per-account scheme choice” 只覆盖协议已经为之 ship 了 precompiles 的方案。下面会再说。

“哪种 PQC”之争会安静下来。我们不必在 L1 选一个赢家。让账户自己选。让市场决定哪种方案最适合哪种用例。支持者只需要为某个特定 precompile 通过 ACD gauntlet。

我们仍然需要 ship 一些 precompiles

我想谨慎一些，不要夸大其词，因为我上面用的 framing——“user-space decision，不是 protocol schedule”——只有在协议真的 ship 了你想用的 verifier 时才成立。

只有当协议里有快速的 MAYO verifier 时，MAYO account 才可行。理论上，你可以在 Solidity 里或者作为 EVM bytecode 写一个 MAYO verifier。但你不应该这么做。在 EVM 中实现一个后量子 signature 的 verification，会比用 native client code 编写并以 precompile 暴露出来的同一个 verifier，消耗高出几个数量级的 gas。“它能工作”和“它在经济上可行”是两个非常不同的标准，如果没有 precompiles，PQ accounts 能通过前者，却会在后者失败。看看 Falcon 和 ML-DSA 就知道了。

所以，关于 8141 的诚实故事其实是一个两部分的故事：

1. EIP-8141 移除了 transaction layer 上的 cryptographic monoculture。这是架构上的胜利，而且是真实的胜利。账户在 protocol 层面不再彼此在密码学上完全相同。

2. Precompile EIPs 决定了哪些方案在经济上可用。MAYO、Hash signatures、Falcon——这些都需要各自的 EIP、各自的 benchmarks、各自的 gas schedule、各自的 audit。如果没有配套的 precompile 工作就 ship 8141，我们会得到使用 PQ signatures 的理论自由，却得不到负担得起它们的实际能力。

这不是对 8141 的批评。这是在提醒：8141 是使能器，不是载荷。载荷是 precompiles，而对它们进行 specification 和 benchmarking 的工作，才是未来一两年里大部分真正工程工作的所在。

我要转为支持

我支持 8141。我希望在标准推出时，我们能推动一个 MAYO precompile。给社区的三个具体请求：

1. 适时推动一个 MAYO precompile EIP。MAYO-2 是 NIST standards set 中最小的、可用的 PQ signature，并且有一个可驻留在 code 中、能舒适放进链上的 pubkey。它与 code-resident pubkey 模型天然契合。如果 8141 是使能器，那么 MAYO 就是第一个真正有说服力的客户。但它仍在 NIST 流程中，等标准推出时再标准化它。

2. 保持 ML-DSA、Falcon/FN-DSA 和 Hash based schemes 在组合中。我们仍然需要尽早拥有算法多样性，而不是晚些时候。把任何单一 PQ scheme 定为“那个唯一方案”，正好会造成 NIST 的 on-ramp process 试图避免的那种 monoculture 风险。8141 架构让我们能够在 protocol 层面避开这场争论；让我们真正拿到这份胜利。

3. 留意 contract size limits。MAYO-2 pubkeys（~5.4 KB）完全能放进今天 24 KB 的 contract size cap，所以这不是阻塞项。但我们应该从现在开始以不同方式看待这个上限。过去的讨论是：Diamond-pattern 可升级 contracts 是否值得更多空间。越来越多地，它变成了：未来更高安全级别的 PQ schemes，或者 hybrid multi-scheme accounts，是否有足够空间呼吸。

我错了。8141 是好的。让我们把它正确地 ship 出去。

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