该文探讨了以太坊外部账户(EOA)在量子计算威胁下的迁移策略,重点分析了原生抗量子签名、账户抽象(ERC-4337/RIP-7560)及EIP-7702委托等技术路径。文章深入评估了迁移过程中对现有合约兼容性的冲击(如ecrecover、permit等),并提出了应对量子紧急情况的韧性方案。
大家好,我是 Marco López(马拉加大学 / NICS 实验室 + 去中心化安全)。
我们最近有一篇关于在未来密码学相关量子计算机 (CRQC) 威胁下,针对 secp256k1/ECDSA 的以太坊 EOA 迁移策略的论文被接收了。
我们将论文的研究范围特意限定在执行层(EOA 授权、交易/签名流等),并未涵盖共识层的后量子(PQ)迁移(如验证者签名、BLS/KZG 等)。
在发布论文之前,我们关注了 ethresearch 社区中几个已经在探索 PQ 交易签名和实际工程权衡的优秀讨论帖。非常感谢推动这些讨论的研究者,特别是 asanso 和 seresistvanandras:
asanso (第 1 部分):“所以你想要一个后量子以太坊交易签名”
asanso (第 2 部分):“Falcon 作为以太坊交易签名:好的、坏的和棘手的”
asanso (第 3 部分):“通往后量子以太坊交易的道路是由账户抽象 (AA) 铺就的”
seresistvanandras:“poqeth:以太坊上高效的后量子签名验证” (+ 基准测试 + 反对者模式)
我们的论文旨在对迁移路线进行初步调查,并侧重于分析兼容性破坏以及转型过程中出现的攻击面。
这项工作是一个初步(且特意简化)的迭代。我们试图梳理出目前讨论的、旨在提高 EOA 在 CRQC 威胁下韧性的主要迁移路线,并强调在实践中可能出现的问题。
本文的目的是收集社区意见并整合力量,围绕该问题的执行层展开工作:
我们是否遗漏了相关的缓解方案 / 迁移路线?
还有哪些兼容性破坏(链上和链下)应该被列入关注范围?
我们是否低估了哪些对抗行为 / MEV / 运营风险?
我们应该引用或学习哪些先前的论文 / 代码库 / 讨论帖?
还有谁在积极研究这个领域,哪里可以进行协作?
如果你正在从事钱包、AA、基础设施、协议研究、审计或 L2 生态系统的工作,你的观点将非常有价值。
我们梳理了目前讨论的 EOA 向后量子安全迁移的主要方法,并尝试明确其权衡,特别是这些方法与现有基础设施和合约模式产生交集时的情况。
这种方式在概念上很简单,但验证成本和签名/密钥大小因方案而异,会影响交易大小、Gas 消耗和性能,有时还会影响地址派生。此外,这是一个较慢的协议级推广过程。
关于哈希签名的笔记(极简主义视角):我们花了一些时间讨论基于哈希的签名,因为以太坊已经严重依赖哈希函数作为核心原语。使用基于哈希的签名在“密码学上是极简的”(没有引入像晶格、等向性等方案那样全新的硬度假设)。此外,许多基于哈希的构造在链上可以拥有极小的“公钥”(通常只是一个哈希或根承诺),这与 poqeth 中强调的“在以太坊背景下,大型公钥是行不通的”观点相契合。当然,权衡会转移到其他方面(如签名大小、状态性、UX/mempool 摩擦),这正是我们希望获得更多反馈的地方。
细微差别:**有状态的哈希签名(例如 XMSS/LMS)在通用系统中可能使用不便,因为它们需要状态管理,但区块链可以在链上管理该状态(类似于索引/nonce)。在其他生态系统中已有先例(例如 QRL 使用 XMSS**)。
问题在于(如 asanso 系列文章所述),Bundler 仍然发布 ECDSA 签名的交易,因此端到端的流程并非完全抗 PQ。此外,它还引入了额外的组件(类似于 mempool 的基础设施、费用、运营复杂性)。
这需要深度的协议更改;时间表和最终设计尚不确定。
关键局限性:只要协议仍然接受 EOA 的 ECDSA 密钥,它就仍然拥有“根权限”(在 CRQC 环境下,这种残留权限尤为危险)。
我们将其视为在拥有更灵活的验证机制后,消除“根 ECDSA 权限”的更广泛设计空间的一部分。
在所有路线中,我们都保持了实际视角:ECDSA 在哪些地方仍然保留,出现了哪些新的基础设施假设,以及在转型期间生态系统中哪些部分会失效。
我们预计挑战最多的地方包括:
ecrecover 的身份验证(签名即身份)。许多链上授权实际上是通过 ecrecover 实现的“签名即身份”。在 PQ 迁移中,仅在交易层停止使用 ECDSA 是不够的。只要 ecrecover 仍然是有效的 ECDSA 预编译合约,现有合约就可以继续将 ECDSA 链下签名视为权威。因此,任何严肃的转型都需要一个处理 ecrecover 风格验证的方案(确定它是被限制、替换还是由新的验证路径补充),否则即使 EOA 停止使用 ECDSA 进行交易,旧的链下签名可能仍会在合约内部保留控制权。
(相关:正如 asanso 在关于 AA/Falcon 的讨论中提到的,许多 PQ 方案不支持“密钥恢复”。例如“普通”的 Falcon 不支持从签名中恢复公钥,因此 ecrecover 模式无法沿用。基于 Falcon 的钱包通常需要根据存储的公钥进行验证。Falcon 论文中也讨论了一种“可恢复”模型(第 3.12 节,由 Renaud Dubois 指出),该模型允许密钥恢复,但它会使签名大小翻倍,对链上带宽有明显影响。)
ERC-2612 permit + 更广泛的链下签名流(类型化数据、特定于应用的身份验证、元交易模式)。
tx.origin 假设(EOA 与合约身份,脆弱的授权逻辑)。
L2s + 跨链漂移(身份语义、重放域、跨链桥接假设)。
迁移窗口期间的 MEV(围绕委托、撤销、“最后有效签名”时刻的排序竞争)。
我们希望社区反馈:这份清单上还有什么遗漏,以及在实践中哪些因素最具破坏性?
除了“平滑迁移”路径外,量子紧急硬分叉也是韧性方案的重要组成部分。
Vitalik 2024 年 3 月的帖子(“如何在量子紧急情况下通过硬分叉挽救大多数用户的资金”)构思了一个可靠的最后手段响应方案:如果实用的量子能力突然出现并开始发生大规模盗窃,则回滚到盗窃发生前,禁用旧的 EOA 交易,并提供一条将控制权转移到量子安全智能合约验证中的恢复路径。
我们提到这一点并不是作为一个主动推进的计划(其成本和社交/运营压力巨大),而是作为一个提醒:紧急规划很重要。 与此同时,生态系统应该致力于实现更渐进的加密敏捷性,以免被迫进入“砸玻璃自救”模式。
如果你回复,请提供指向讨论帖 / 论文 / 代码库 / 团队的链接,这将非常有帮助:
是否有我们遗漏的(在执行层)迁移路线 / 缓解措施,或者我们应该纳入的重要变体?
你认为哪些兼容性破坏(链上和链下)最为紧迫,或者最有可能对用户造成实际伤害?欢迎提供具体案例。
在迁移过程中应考虑哪些对抗行为 / MEV / 运营风险(如抢跑、恶意干扰、“最后有效签名”问题、基础设施受损、有状态方案的交易卡死动态等)?
是否存在已知类型的合约或钱包模式,其中的 ecrecover、permit 或 tx.origin 假设使迁移变得特别棘手?
你是否知道有助于量化这些模式普及程度的测量方法 / 数据集 / 工具(例如扫描 ecrecover 的分布、实际中的 permit 使用情况等)?
还有谁在积极研究 EOA 的 CRQC / 加密敏捷性?如果你参与其中(或认识相关人员),我们很乐意取得联系。
我们将此作为一项公共利益努力(UMA/NICS 实验室 + 去中心化安全)。非常欢迎审阅、更正以及在合适的地方进行协作。
我们将于 3 月中旬在西班牙特内里费岛的拉拉古纳大学一次会议上展示这篇论文。我们还计划在 2026 年 5 月 9 日在罗马举行的 Eurocrypt 相关区块链密码学工具研讨会 (CTB-26) 上展示后续工作。
如果你在这个领域工作,我们很乐意在这些活动中与你交流。
顺便说一下,CBT26 的提交截止日期是 2 月底,你还有时间参与。
谢谢!!期待你的反馈。
- 原文链接: ethresear.ch/t/migration...
- 登链社区 AI 助手,为大家转译优秀英文文章,如有翻译不通的地方,还请包涵~
如果觉得我的文章对您有用,请随意打赏。你的支持将鼓励我继续创作!