news 2026/6/2 9:03:56

以太坊中的量子攻击面

作者头像

张小明

前端开发工程师

1.2k 24
文章封面图
以太坊中的量子攻击面

1. 引言

本文将深入分析量子计算机如何攻破以太坊的签名系统,以及由此在 EOA、智能合约、验证者、Rollup、跨链桥和预言机等层面暴露出的安全风险。

以太坊的安全性依赖于两类密码学机制:

  • 签名算法:用户账户使用 ECDSA,验证者和部分承诺机制使用 BLS。
  • 哈希函数:Keccak-256,用于地址生成和 Merkle 结构。

量子计算机对这两类机制的威胁并不相同。

Shor 算法能够在多项式时间内求解离散对数问题,这意味着一旦公钥可见,基于椭圆曲线的非对称密码学将不再安全,如:

  • ECDSA(基于 secp256k1 和 BLS12-381)

而 Grover 算法仅能将暴力搜索复杂度降低至平方根级别,因此当前参数规模下的哈希函数和对称密码学仍然是安全的。

这一差异至关重要,但经常被人误解。

当具备密码学攻击能力的量子计算机(CRQC,Cryptographically Relevant Quantum Computer)出现时:

  • 以太坊基于哈希的结构仍将保持安全;
  • 以太坊的签名系统则不再安全。

其结果是可预见的:

  • 凡是控制权依赖于 ECDSA 或 BLS 的地方,其安全保证都将失效。

本文将梳理当前以太坊体系中的这些攻击面,重点关注:

  • 公钥在哪里暴露;
  • 公钥如何被恢复;
  • 一旦被恢复,会产生什么后果。

最早出现的实际量子攻击很可能不会针对内存池(mempool),而是针对那些已经在链上公开多年公钥的账户进行长期、持续的密钥恢复攻击。

随后,影响将扩散至:

  • 账户
  • 智能合约
  • 共识层
  • Rollup
  • 跨链桥
  • 预言机

2. 以太坊中的公钥在哪里出现

以太坊 EOA(Externally Owned Account,外部拥有账户)的地址,是keccak256(uncompressed_pubkey)结果的最后 20 个字节。

如果某EOA账户从未签署过任何公开可见的交易,那么其公钥并不会出现在链上,相应的地址本质上只是一个哈希值截断结果。

然而,一旦该EOA账户签名并广播了一笔交易,签名中的(v, r, s)值就会暴露足够的信息,使任何人都可以通过签名恢复出相应的公钥。

相关说明可参考:

  • 2023年6月11日博客 Understanding Digital Signatures: The Role of v, r, s in Cryptographic Security and Signature Verification

链下公开签名也会产生同样的效果,如:

  • 用于订单和挂单的 EIP-712 Typed Data 签名;
  • ERC-20 授权(Permit)调用;
  • 登录挑战(Login Challenge);
  • 各类“签署此消息以证明所有权(Sign this message to prove ownership)”操作。

只要这些签名对其他人可见,相应的公钥就会被暴露出来。

作者认为:对于绝大多数以太坊账户而言,其公钥实际上已经处于公开状态。

以太坊采用账户模型(Account Model)。人们会在多年时间里持续使用同一个地址来管理:

  • ETH
  • ERC-20 代币
  • NFT
  • 授权(Approvals)
  • 治理投票(Governance)
  • 合约管理员权限(Contract Admin)

等等。

这与比特币的 UTXO 模型不同。在比特币中,良好的地址使用习惯会在资金花费前隐藏公钥,并在花费后弃用该地址;更多内容可参考2025年7月22日博客 Quantum vulnerability of Bitcoin addresses。

而在以太坊中,身份(Identity)是长期存在的。一旦公钥被公开,它通常会长期保持相关性,因为资产和权限会持续流经同一个账户。

在存在 CRQC(具备密码学攻击能力的量子计算机)的世界里,“公钥可见”意味着“私钥可被计算出来”。

这一事实将永久成立;只是其后果是否严重,取决于该账户是否仍然控制着资产或权限。

EOA 并不是唯一会暴露公钥的地方。

验证者(Validator)在存入质押时会公开其 BLS12-381 公钥,这些公钥会永久存在于共识状态中,并被用于验证:

  • Attestation(见证)
  • Block Proposal(区块提议)

EIP-4844 引入了 KZG Commitment,其中所依赖的 Structured Reference String(SRS)由椭圆曲线点构成,其绑定性(binding property)依赖于离散对数难题。

zk-SNARK 系统(如 Groth16 和 PLONK)会将验证密钥(Verification Key)发布到链上,而这些验证密钥本身也是椭圆曲线点。

跨链桥(Bridge)和预言机(Oracle)通常也会公开其签名者集合(Signer Set)的公钥。

在所有这些场景中,情况都是一样的:一旦这些公开密码学材料可见,Shor 算法就能够恢复与之对应的秘密信息。

为了完整起见,再讨论一下 Grover 算法的情况。

如果某个公钥从未被公开,那么该地址仅仅是keccak256(pubkey)结果的最后 20 个字节。

攻击这种地址意味着:

  • 找到某个合法的 secp256k1 密钥对,使其哈希值恰好以目标的 160 位模式结尾。

这实际上是一个截断哈希原像(truncated hash preimage)问题

经典计算机下,其复杂度约为2 160 2^{160}2160,Grover 算法可将其降低至2 80 2^{80}280
攻击者并不需要找到相应的原始私钥,只需找到一个产生相同地址的碰撞密钥即可。

但即便如此,2 80 2^{80}280级别的量子计算量仍然远远超出现实可达范围。

因此在实践中 从未发生过签名行为的地址仍然是安全的。

更详细的分析可参考2019年论文 Benchmarking the quantum cryptanalysis of symmetric, public-key and hash-based cryptographic schemes。

真正的风险始于第一次签名,因为那会暴露真实公钥,并使 Shor 算法能够进行私钥恢复。

3. 两类攻击向量

3.1 长期恢复攻击(Long-Grinding / At Rest)

任何公钥已知的账户或系统,都可能在较长时间内被恢复私钥,如:

  • 已经使用过的 EOA
  • 管理员 EOA
  • Validator 的 BLS 密钥
  • 基于椭圆曲线的 SNARKs 验证密钥
  • EIP-4844 的 SRS 中嵌入的 KZG Commitment 材料

这些公钥今天就已经是公开的,因此不存在与区块时间赛跑的问题。

这很可能是人们最先看到的量子攻击方式。

不过,它只有在被恢复出的密钥仍然控制着有价值的资产或权限时才会产生实际影响。

3.2 即时攻击(Just-in-Time / Mempool)

当一笔 EOA 交易进入公共内存池(Public Mempool)时:

  • 签名已经公开;
  • 公钥也随之公开;

但该交易尚未被打包进区块。

如果攻击者能够在数秒内恢复私钥,那其就可以:

  1. 使用相同 nonce;
  2. 支付更高的 Gas Fee;
  3. 构造替代交易(Replacement Transaction);
  4. 抢先花费资金。

然而,以太坊大约 12 秒的 Slot 时间极大压缩了这一攻击窗口。

因此 在量子私钥恢复速度达到极高水平之前,这种攻击方式并不现实。

4. EOA(Externally Owned Accounts)

4.1 EOA 工作原理

以太坊有两类账户:

  • Externally Owned Accounts(EOA):由私钥控制;
  • Contract Accounts(合约账户):由代码控制。

EOA 就是大多数人理解中的“钱包”。

如:

  • MetaMask
  • Ledger 等硬件钱包

提供的都是 EOA。

当发送一笔交易时:

  1. 钱包使用私钥对交易进行签名;
  2. 网络根据对应公钥验证签名是否正确。

4.2 EOA 量子风险

前文已经介绍了 EOA 公钥何时以及如何被公开。

简单来说,一旦某个 EOA 的公钥被公开(无论是通过链上交易,还是通过可见的链下签名),具备密码学攻击能力的量子计算机(CRQC)就能够恢复其私钥。

从那一刻起,攻击者便能够以该账户的身份行事。

这是否会造成实际影响,取决于该账户仍然掌握什么:

  • 资金(Funds)
  • 授权(Approvals)
  • 合约所有权(Contract Ownership)

如果账户已经为空,那么实际风险相对较小。

4.3 EOA 实践说明

EOA 实践说明:

  • Nonce(随机数)
    以太坊要求同一账户发出的交易按照连续递增的 nonce 顺序执行。
    但 nonce 仅决定交易顺序。
    如果攻击者已经获得了你的私钥,那么他无需与你竞争交易顺序;因为在协议看来:

    他就是你。

  • 硬件钱包
    Ledger 或 Trezor 能够防止恶意软件窃取你的私钥。
    但它们无法阻止 Shor 算法在公钥公开后反推出私钥。
  • 由 EOA 组成的多签(Multisig)
    多签本质上只是多个 EOA 与门限规则(Threshold)的组合。
    对于人类攻击者而言,多签更难被攻破;
    但对于 CRQC 来说,每个 EOA 仍然只是一个需要求解的离散对数问题。
    它并没有引入新的安全假设。

4.4 对 EOA 影响

很难准确预测这一切将如何发生。已在Quantum Wargames进行了更详细的讨论。

但从宏观层面看,最可能出现的情况是:某些 EOA 钱包被悄无声息、有选择性地清空。

这些账户可能包括:

  • 交易所热钱包(Hot Wallet)
  • 曾经发生过转账的冷钱包(Cold Storage)
  • 项目金库 EOA(Treasury EOA)

从链上表现来看:这些攻击与普通交易或传统黑客攻击没有任何区别。

5. 智能合约

5.1 智能合约工作原理

智能合约的安全基础是:

  • 代码(Code)
  • 状态存储(Storage)

二者都被提交到状态根(State Root)中。

智能合约本身并不信任、也不一定需要数字签名。

只有当开发者主动将签名验证逻辑写入代码时,签名才会参与权限控制。
然而现实情况是:

  • 绝大多数控制平面(Control Plane)正是这样设计的。

5.2 智能合约中的签名出现在哪里

智能合约中的签名出现在哪里:

  • onlyOwner模式,且 Owner 是 EOA;
  • 可升级代理合约(Upgradeable Proxy),其升级权限由 EOA 多签管理员控制;
  • 基于ecrecover的链下授权验证,如:
    • Permit
    • Meta-Transaction
    • 自定义管理员调用
  • 治理系统(Governance),其中提案需要委员会成员使用 ECDSA 私钥签名授权。

5.3 智能合约中的量子风险

在 CRQC 存在的情况下:

  • 只要这些签名者的公钥曾经公开过,其私钥就可能被恢复。

攻击者随后便能执行该密钥所授权的任何操作,如:

  • 将代理合约升级为恶意实现;
  • 调用管理员函数;
  • 任意增发(Mint)或销毁(Burn)资产;
  • 关闭安全保护机制;
  • 转移项目金库资产。

所有这些攻击:

  • 不依赖 EVM 漏洞;
  • 不依赖智能合约代码缺陷;

攻击之所以成功,仅仅是因为攻击者能够利用恢复出的私钥生成合法签名。

5.4 对智能合约影响

与 EOA 钱包类似,很难准确预测实际情况会如何发展。

但一个可能的场景如下:

  • 某个大型智能合约采用代理模式(Proxy),管理员为一个4-of-6 EOA 多签

假设:

  • 这 6 个 EOA 的公钥自 2021 年起就已经公开。

在量子时代到来之日(Q-Day):

  • 攻击者恢复出其中 4 个私钥。

随后:

  1. 调用upgradeTo()
  2. 将代理合约升级为恶意实现;
  3. 将储备资产转移出去;
  4. 使用伪造签名滥用用户授权(Allowance);
  5. 清空用户资金。

从链上的角度看:

  • 所有调用都是合法的。

在 EVM 层面没有任何异常现象,因为这些签名完全符合协议逻辑,并且能够正常通过验证。

关于量子攻击如何影响 Ethereum 上的 USDC 智能合约,可参阅:

  • 2025年7月8日博客 Quantum vs. USDC: A Threat Analysis of Circle’s Smart-Contract

6. 权益证明(Proof-of-Stake)

6.1 PoS 工作原理

以太坊的共识机制由验证者(Validators)运行。

每个验证者需要质押 32 ETH,并在加入网络时生成一个 BLS12-381 公钥。

该公钥用于签署:

  • 验证者活动(Validator Activity)
  • 区块见证(Attestations)
  • 某些情况下的新区块提议(Block Proposals)

这些公钥会在验证者存款时公开发布,并在验证者保持活跃期间持续存在于共识状态(Consensus State)中。

如果出现具备密码学攻击能力的量子计算机(CRQC),验证者的私钥将能够被恢复出来。

5.2 PoS中的量子风险

PoS中的量子风险有:

  • 伪造验证者参与(Forged Participation)
    如果足够多的验证者密钥被破解,攻击者便能够生成看起来来自诚实验证者的签名(Attestations 和 Proposals)。
    即使这些签名实际上并非由验证者本人产生,也能通过验证。
    这将破坏用于确定规范链(Canonical Chain)的投票机制。

  • 双重签名与罚没(Equivocation and Slashing)
    如果验证者对互相冲突的内容进行签名,如:

    • 对同一高度的两个不同区块投票;

    那么验证者将受到罚没(Slashing)处罚。

    如果攻击者掌握了验证者私钥,就可以故意大规模制造此类冲突。
    结果是:

    • 诚实验证者看起来像是在作恶;
    • 他们会被罚没;
    • 被迫退出验证者集合。

    这会导致:

    • 可用验证者数量下降;
    • 共识机制被削弱。

    即使攻击者并未掌握多数验证者密钥,大规模罚没本身就足以:

    • 破坏网络稳定性;
    • 迫使交易所暂停服务;
    • 迫使跨链桥暂停运行。
  • 最终性(Finality)
    最终性(Finality)意味着:当区块达到某个阶段后,它将无法再被回滚。
    如果:

    • 验证者参与率下降;
    • 投票被伪造;

    那么最终性将变得不可靠。

    即便只是短时间的不稳定,也足以破坏:

    • 应用程序
    • 交易所
    • 跨链桥

    所依赖的安全假设。

    如果攻击者控制了超多数(Supermajority)验证者密钥,则情况会进一步恶化。

    他们甚至能够操纵已经最终确认的历史记录,并决定 哪条分叉链最终成为“真实历史”。

    需要注意的是:这要求攻击者能够恢复多数验证者的私钥。

  • 提款(Withdrawals)
    验证者最终会提取其质押的 ETH。
    提款目的地址由 Withdrawal Credentials 控制。
    部分验证者仍在使用:

    • BLS Withdrawal Credentials

    在这种情况下:控制验证者退出(Exit)的仍然是同一个 BLS 密钥。

    因此它们直接暴露在 CRQC 攻击面前。

    另一些验证者则使用:

    • Execution Layer Withdrawal Credentials

    这类凭证会将资金发送到一个以太坊地址。

    如果该地址是 EOA:那么它与普通 EOA 一样,可以被量子计算恢复私钥。

    如果该地址是:

    • 不依赖椭圆曲线密码学(ECC)的合约钱包(Contract Wallet)

    则相对更安全。

    不过目前此类配置仍然较少见。

  • 轻客户端与同步委员会(Light Clients and Sync Committees)
    轻客户端(Light Client)不会运行完整节点。
    它们依赖同步委员会(Sync Committee)提供的签名来确认最近的区块头。
    同步委员会本质上是:

    一组轮换产生的验证者集合。

    这些验证者使用 BLS 签名为最新区块头背书。

    如果这些委员会成员的密钥可以被恢复:攻击者就能够伪造区块头,并诱导轻客户端接受一条实际上会被完整网络拒绝的链。

    结果将导致:

    • 轻客户端所相信的状态;
    • 全节点实际执行的状态;

    发生分裂。

    所有依赖轻客户端的下游系统都会继承这种混乱,如:

    • 移动钱包(Mobile Wallets)
    • 某些跨链桥(Bridges)

5.3 对PoS的影响

要造成严重破坏,并不一定需要发动完整的“51% 攻击”。

仅仅是大规模罚没(Mass Slashing),就足以:

  • 使最终性瘫痪;
  • 削弱市场信心;
  • 动摇网络安全性。

哪怕只是几个小时的:

  • 双重签名(Equivocating Proposals)
  • 验证者参与异常

都可能导致:

  • 客户端进入安全模式(Safety Mode);
  • 交易所暂停提款(Withdrawal Freeze)。

6. Rollup

以太坊的扩容策略高度依赖 Rollup。

Rollup 在链下执行交易,然后将证明(Proof)提交回以太坊,以证明其状态转换(State Transition)是有效的。

6.1 zk-Rollup

目前大多数生产环境中的 zk-Rollup 使用的是:

  • Groth16
  • PLONK

等 SNARK 系统。

这些系统通常建立在如下椭圆曲线之上:

  • BN254
  • BLS12-381

这些证明系统的不可伪造性(Unforgeability)依赖于椭圆曲线群中的离散对数难题。

如果攻击者拥有 CRQC,那么他们就能够伪造证明,使本应无效的状态转换看起来是有效的。

这可能允许攻击者:

  • 在 Rollup 上凭空铸造(Mint)资产;
  • 然后将这些没有实际抵押物支持的资产提取到 L1。

6.2 STARK Rollup

与此不同,STARK 完全建立在:

  • 哈希函数(Hash Functions)
  • 纠错码(Error-Correcting Codes)

之上。

如前所述,Grover 算法只能将攻击复杂度降低到平方根级别。

在 256 位安全参数下,STARK 仍然保有极高、事实上不可行攻击的安全边际。

因此 STARK 证明在量子攻击者面前仍然保持可靠性(Soundness)。

但问题在于,许多基于 STARK 的系统仍然使用:

  • ECDSA
  • EdDSA

来保护:

  • Sequencer(排序器)
  • Bridge(跨链桥)
  • Governance(治理)

这些组件。

因此即便证明层本身是安全的,这些薄弱环节仍然可能首先失陷。

6.3 Optimistic Rollup

另一类 Rollup 被称为 Optimistic Rollup(乐观 Rollup),其设计假设 默认所有交易都是有效的。

只有当有人在规定时间窗口内提出挑战时,系统才会执行欺诈证明(Fraud Proof)。

欺诈证明挑战机制本身基于哈希函数,理论上具备抗量子能力。

然而,发起挑战的人本身通常是使用 ECC 的 EOA。如果这些 EOA 的密钥能够被量子计算恢复,攻击者就能够:

  • 冒充挑战者;
  • 阻止挑战者行动;
  • 推动治理提案禁用欺诈证明机制。

7. 跨链桥(Bridges)

跨链桥是以太坊生态中最容易受到攻击的组件之一,原因在于:它们将巨额资产集中托管在规模很小的签名者集合之后。

虽然不同桥的设计有所不同,但其量子风险本质上是一致的——一旦公钥已知,对应签名就可能被伪造。

7.1 基于多签的跨链桥(Multisig-Based Bridges)

大多数通用 Token Bridge 的工作方式如下:

  1. 将资产锁定在以太坊上的托管合约(Escrow Contract)中;
  2. 在另一条链上发行对应的封装资产(Wrapped Asset)。

当用户想要赎回资产时:

  • 用户提交提款请求;
  • 请求需要获得一组链下签名者的批准。

桥合约会验证这些签名者的 ECDSA 签名是否来自预设公钥集合。

在 CRQC 存在的情况下,这些公钥都可以被破解,此时,一个 5-of-7 多签不再意味着“五个人达成共识”,而变成了“需要恢复五个离散对数”。

一旦达到签名门限,攻击者就能够指示桥合约,将资产释放给自己。

最终结果是:

  • 托管资产被直接盗走;
  • 另一条链上的封装资产立即脱锚(Depeg)。

而那些将这些封装资产作为抵押品(Collateral)的协议,则会陷入抵押不足(Under-Collateralized)状态。

7.2 Canonical Rollup Bridge(官方 Rollup 桥)

每个 Rollup 都会在以太坊上部署一个官方桥接合约(Canonical Bridge Contract),用于处理充值(Deposit)和提现(Withdrawal)。

这些桥接合约理论上应当是完全无需信任(Trustless)的:

  • 用户在 L1 上锁定资产;
  • 只有当提交了有效的 Rollup 状态转换证明后,提现请求才会被执行。

然而,这些合约通常仍然保留管理员密钥(Admin Keys),用于:

  • 升级合约逻辑;
  • 修改系统参数;
  • 在紧急情况下暂停系统。

这些管理员权限通常由:

  • EOA;
  • 或基于 EOA 的多签(EOA-based Multisig)

控制。

在 CRQC 存在的情况下,这些密钥都可以被恢复出来。

这意味着:攻击者可以伪装成合法管理员,对桥逻辑进行升级、修改甚至关闭系统。

即使证明系统本身仍然安全(如基于 STARK 的 Rollup),围绕 Canonical Bridge 的控制平面(Control Plane)仍然可能被攻击者接管。

7.3 对跨链桥的影响

跨链桥是整个生态系统中的关键瓶颈(Systemic Chokepoint)。

一次成功攻击就可能在瞬间盗取数亿美元资产。

跨链桥同时还将以太坊的信誉与其他链连接在一起。

当桥系统失效时:

  • 两侧链上的用户都会受到影响;
  • 整个生态对跨链资产的信心都会受到冲击。

在量子威胁面前,跨链桥本质上就是:

  • 一组等待被破解的签名者集合(Signer Sets Waiting to Be Solved)。

8. 预言机(Oracles)

预言机负责将链下数据引入以太坊,如:

  • 资产价格(Asset Prices)
  • 事件结果(Event Outcomes)
  • 跨链状态(Cross-Chain States)

智能合约依赖这些数据来:

  • 清算贷款(Liquidations)
  • 结算衍生品(Derivatives)
  • 铸造或赎回资产

8.1 预言机工作原理

预言机节点使用 ECDSA 密钥对数据报告进行签名。

消费者合约(Consumer Contract)会使用预先配置好的公钥集合验证这些签名。

部分预言机采用门限机制,如15-of-20,即 只有当 20 个节点中至少有 15 个节点签名时,数据才会被接受。

8.2 预言机中的量子风险

这些公钥从设计上就是公开的。

一旦私钥能够被恢复,攻击者就可以伪造数据报告。

如果攻击者恢复出了足够多的密钥并达到签名门限,那么他们就能够发布任意想要的数据。

如:

  • 将 ETH/USD 价格压低以触发大规模清算;
  • 虚增抵押品价格以铸造稳定币;
  • 伪造事件结果以掏空保险资金池。

8.3 对预言机影响

预言机已经深度嵌入整个 DeFi 生态。

一旦数据源被攻破,其影响会同时传播到多个协议。

通过操纵价格或事件结果,攻击者可以:

  • 强制触发清算;
  • 铸造没有实际抵押物支持的资产;
  • 触发不应发生的赔付;

从而直接获利。

与此同时,相关协议则可能陷入资不抵债(Insolvent)的状态。

从代码层面来看:一切都在正常运行。

但问题在于:合约所执行的是错误的数据输入。

9. EIP-4844 数据可用性(Data Availability)

9.1 EIP-4844 数据可用性工作原理

EIP-4844(“Proto-Danksharding”)引入了 Blob(数据块)机制。

Blob 是一种大型交易数据载体,其发布到以太坊上的成本比传统 Calldata 更低。

为了能够在不保存全部数据的情况下验证 Blob 的正确性,以太坊采用了 KZG Commitment。

其基本原理是:将一个多项式在某个秘密值τ \tauτ处进行求值,并将结果绑定到椭圆曲线点上,从而形成承诺(Commitment)。

为了证明某个 Blob 与其对应的 Commitment 一致,只需提供一个简短的基于 Pairing 的证明(Pairing-Based Proof)。

这样:

  • 轻客户端(Light Clients)
  • Rollup

就能够在无需下载完整 Blob 数据的情况下验证其正确性。

9.2 EIP-4844 数据可用性中的量子风险

KZG 的绑定性(Binding)和可靠性(Soundness)依赖于 BLS12-381 曲线上的离散对数难题。

而在 CRQC 存在的情况下,这一安全假设将失效。

攻击者可能伪造求值证明(Evaluation Proof),即:

  • Blob 与 Commitment 实际并不匹配;
  • 但验证结果却显示其合法有效。

简单来说:错误数据可以被伪装成正确数据。

9.3 对EIP-4844 数据可用性的影响

这种攻击并不会直接破坏 EVM 在区块内部的执行规则。

交易仍然必须遵守协议规范。

真正失效的是:数据可用性层(Data Availability Layer)。

而 Rollup 正是依赖这一层来重建自己的状态。

如果 Blob 证明可以被伪造,那么:

  • 轻客户端;
  • Rollup;

将无法区分:

  • 真实有效的数据;
  • 被伪造的数据。

结果是:“以太坊会拒绝无效数据”这一安全保证将不复存在。

这会直接削弱:

  • Rollup 的安全性;
  • 所有建立在 Rollup 之上的系统的安全性。

10. MEV、Builder 与私有订单流(Private Order Flow)

10.1 MEV、Builder 与私有订单流工作原理

以太坊当前的交易处理流程采用了Proposer-Builder Separation(PBS),即 提议者(Proposer)与构建者(Builder)分离。

在该模型中:

  • Validator(验证者)负责提议区块;
  • Builder(构建者)负责收集并排序交易。

Builder 会构建完整区块,然后通过 Relay(中继)发送给验证者。

此外,用户还可以通过私有订单流系统(Private Order Flow)直接将交易发送给 Builder,而无需经过公开 Mempool——如Flashbots Protect,这样做的主要目的,是避免遭受抢跑(Front-running)攻击。

10.2 MEV、Builder 与私有订单流中的安全机制

MEV、Builder 与私有订单流中的以下连接依赖于椭圆曲线密码学(Elliptic-Curve Cryptography)来提供安全保障:

  • devp2p(见下文)使用基于 secp256k1 的 ECDH(Elliptic-Curve Diffie-Hellman)握手协议;
  • Relay(中继)和 RPC 端点使用带有 ECC 证书的 TLS;
  • Builder(区块构建者)会对证明信息进行签名,以证明自身身份的真实性。

这些机制所依赖的安全假设非常直接:

  • 你能够确认通信对象的身份;
  • 你的交易在进入区块之前保持机密。

10.3 MEV、Builder 与私有订单流中的量子风险

一旦椭圆曲线密码学被攻破,这些安全保证也将随之消失。

攻击者可以:

  • 冒充 Builder 或 Relay;
  • 截获私有交易;
  • 修改交易内容;
  • 将私有交易重新泄露到公开 Mempool。

此外,以下攻击也会变得更加容易:

  • 中间人攻击(MITM,Man-in-the-Middle)
  • Eclipse Attack(节点隔离攻击)

在 Eclipse Attack 中,攻击者会让节点只能接收到自己控制的信息,从而将其与真实网络隔离。

10.4 对MEV、Builder 与私有订单流的影响

单独来看,这些问题主要属于:

  • 机密性(Confidentiality)问题;
  • 可用性(Availability)问题。

但如果与:

  • 被伪造的验证者密钥;
  • 被盗取的 EOA 私钥;

结合起来,则会进一步放大:

  • 审查(Censorship)
  • 交易误导(Misrouting)
  • 对私有交易提交机制的信任流失

等问题。

如果身份认证机制本身已不可信,那么所谓的“防抢跑保护(Front-Running Protection)”也将失去意义。

从更长期的角度来看,随着量子计算能力进一步增强,公开 Mempool 本身也会成为一个盗窃攻击面:攻击者可以通过即时私钥恢复(Just-in-Time Key Recovery)窃取交易。

不过这是更后期才会出现的风险。

在量子时代的早期阶段,更现实的威胁是:私有交易供应链(Private Transaction Supply Chain)的信任被破坏。

11. 网络层(devp2p 与 RPC)

11.1 网络层工作原理

以太坊节点通过 devp2p 协议进行节点发现和通信。

为了保护这些连接,节点会基于 secp256k1 执行:ECDH(Elliptic-Curve Diffie-Hellman)密钥协商。

RPC 端点(钱包、DApp 和基础设施服务商所使用)通常通过 TLS 进行保护。

而 TLS 同样依赖于:

  • ECC 证书;
  • ECC 密钥交换机制。

11.2 网络层中的量子风险

在 CRQC 存在的情况下,这些安全保证都会失效。

攻击者能够:

  • 冒充节点(Peer);
  • 冒充服务器;
  • 截获并解密网络流量;
  • 通过 Eclipse Attack 向节点持续提供攻击者控制的数据。

最终,用户可能认为自己连接的是以太坊网络,实际上却只是在与攻击者通信。

11.3 对网络层的影响

网络层本身并不直接控制资金流动,但它是整个网络韧性(Resilience)的基础。

如果网络连接无法被信任,那么:

  • 监控系统(Monitoring)
  • 可观测性工具(Observability Tools)
  • 故障响应(Incident Response)

都会受到影响。

同时,以太坊赖以自豪的抗审查能力(Censorship Resistance)也会被削弱。

在量子攻击事件发生时,如果:

  • 伪造密钥已经出现;
  • 伪造证明已经出现;

整个网络本就处于混乱状态。

而一旦可靠通信能力也同时丧失,那么:网络协调(Coordination)和恢复(Recovery)将变得更加困难。

12. 今天可以做些什么?

12.1 对智能合约

如今已经有一些切实可行的方法,可以将椭圆曲线密码学从智能合约的授权边界(Authorization Boundary)中移除。

智能账户(Smart Account)能够在合约代码中自行验证签名。

  • ERC-1271 为合约定义了标准化的isValidSignature接口。
  • ERC-4337 则允许账户自定义签名验证逻辑。

这意味着 钱包已经可以要求使用后量子签名方案,如:

  • 基于哈希的签名方案
    • SPHINCS+ / SLH-DSA
    • XMSS
  • 基于格的签名方案
    • Dilithium / ML-DSA
    • Falcon / FN-DSA

这些方案的计算开销普遍高于 ECDSA,但对于:

  • 治理操作(Governance)
  • 高价值交易(High-Value Transactions)

而言,这种成本通常是可以接受的。

12.2 对EOA

在量子威胁下,外部拥有账户(EOA)是最薄弱的环节。

因为一旦公钥被公开,对应私钥就可能被恢复出来。

目前存在两种实际可行的应对方式:

  • 将资产转移到一个从未签名过的新地址
    这样可以继续隐藏公钥。
    只要该地址从未进行过签名操作,其公钥就不会暴露。
    不过这只是临时措施。
    因为当你第一次使用该地址签名时,公钥仍然会被公开。
  • 迁移到智能合约钱包(Smart Contract Wallet)
    具体可参考上一节关于后量子智能合约的讨论。

13. 结论

可以将以太坊所依赖的密码学技术划分为两大类:

  • 1)第一类:哈希函数与对称密码学
    在 Grover 算法面前:

    • 哈希函数(Hash Functions)
    • 对称密码学(Symmetric Cryptography)

    依然保持安全。

  • 2)第二类:椭圆曲线签名
    而基于椭圆曲线的签名系统:

    • ECDSA
    • BLS12-381

    则无法抵御 Shor 算法。

这一区别决定了整个量子攻击面(Attack Surface)的边界。

一旦出现具备密码学攻击能力的量子计算机(CRQC),任何已经在以太坊上公开过的公钥都将可能被恢复对应私钥。

这包括:

  • 曾签名过交易或消息的 EOA;
  • 验证者存款时公开的验证者密钥;
  • 多签钱包;
  • 跨链桥委员会;
  • 预言机签名者;
  • SNARK 验证密钥;
  • EIP-4844 中 KZG Commitment 所依赖的椭圆曲线承诺。

最先出现的攻击将很可能是:

对已经公开多年的公钥进行长期恢复(Long-Grinding Recovery)。

而针对 Mempool 的实时攻击则更可能在后期出现,即量子硬件已经足够快,能够在一个区块时间内恢复私钥的时候。

在量子时代到来之日(Q-Day),可能发生的情况包括:

  • 钱包资产被盗;
  • 管理员权限被接管;
  • Rollup 证明被伪造;
  • 验证者遭遇大规模 Slashing;
  • 跨链桥资金被盗;
  • 预言机数据被篡改;
  • 数据可用性验证失效。

简而言之:任何依赖 ECDSA 或 BLS 签名进行授权的系统组件,都将失去其安全保证。

与此同时,以下组件在当前参数设置下仍然保持安全:

  • 基于哈希的安全机制;
  • 从未签名过的地址;
  • Merkle 树结构;
  • STARK 证明系统。

某些防御措施今天就可以开始实施。

用户可以:

  • 将资产迁移到从未使用过的新地址;
  • 迁移到支持后量子验证的合约钱包。

协议开发者可以:

  • 使用合约账户替代 EOA 管理员;
  • 在合约中验证后量子签名。

这些措施:

  • 不需要协议分叉(Fork);
  • 能够将高价值资产移出椭圆曲线密码学的风险半径。

但要实现真正的长期韧性(Full Resilience),仍然需要协议层面的变更,如:

  • 为账户引入后量子签名支持;
  • 为验证者引入后量子签名支持;
  • 为各种 Commitment 机制引入后量子方案。

量子计算的发展速度正在超过大多数人的预期。

可参考:

  • Google Willow Quantum Chip
  • 相关研究论文
  • Q-Day Clock

最困难的运营问题其实并不是 选择哪一种后量子密码算法,而是 如何在不中断系统运行的前提下,迁移那些已经暴露的海量密钥。

整个生态系统都需要一种标准化的大规模权限迁移机制,覆盖:

  • 用户账户(Users)
  • 智能合约(Contracts)
  • 跨链桥(Bridges)
  • Sequencer
  • Validator

最终 迁移路径(Migration Path)与最终目标(Destination)同样重要。

参考资料

[1] Project 11团队2025年8月26日博客 Quantum Attack Vectors in Ethereum

版权声明: 本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若内容造成侵权/违法违规/事实不符,请联系邮箱:809451989@qq.com进行投诉反馈,一经查实,立即删除!
网站建设 2026/6/2 9:02:02

警钟敲响:从 Mac Office“只读危机”看软件授权的脆弱性与技术应对

警钟敲响:从 Mac Office“只读危机”看软件授权的脆弱性与技术应对 近日,技术社区和开发者圈子中流传着一则令许多 Mac 用户感到不安的消息:微软计划对 Office 2019 和 2021 for Mac 版本实施一项重大的功能变更。根据相关文档披露&#xff0…

作者头像 李华
网站建设 2026/6/2 8:58:55

Office Remote:手机遥控PPT演示,提升演讲流畅度与专业感

1. 项目概述:从手机到讲台的遥控革命几年前,如果你告诉我,我能用手里这台小小的手机,隔空控制会议室大屏幕上的PPT翻页、高亮重点,甚至遥控视频播放,我可能会觉得你在讲科幻故事。但微软研究院和Office工程…

作者头像 李华
网站建设 2026/6/2 8:56:57

GitHub中文界面终极方案:轻松掌握全中文GitHub使用体验

GitHub中文界面终极方案:轻松掌握全中文GitHub使用体验 【免费下载链接】github-chinese GitHub 汉化插件,GitHub 中文化界面。 (GitHub Translation To Chinese) 项目地址: https://gitcode.com/gh_mirrors/gi/github-chinese 还在为GitHub全英文…

作者头像 李华