Foundry 识别 HyperEVM 系统发送者修复区块重放中的 Base Fee 校验失败【免费下载链接】foundryFoundry is a blazing fast, portable and modular toolkit for Ethereum application development written in Rust.项目地址: https://gitcode.com/GitHub_Trending/fo/foundryHyperEVMHyperliquid EVM在每笔由 HyperCore 跨链转账“入账”的交易都由一个固定的系统地址作为发送者且这些交易带有gasPrice 0、receiptgasUsed 0的特殊形态。本文以 Foundry 仓库中的 变更记录 .changelog/cast-hyperliquid-system-sender.md 为核心结合源码、测试与 CLI 实现完整剖析 Foundry 如何识别 HyperEVM 系统发送者以及为什么回放replay包含此类交易的区块时会出现 base fee 校验失败、修复又是如何落地的。读完你可以理解 Foundry 在 L2 系统交易处理上的整体设计并掌握cast run等命令在相关场景下的正确用法。一、变更背景什么是 HyperEVM 系统发送者1.1 变更内容速览该 changelog 记录的是一次foundry-common、cast、forge三个 crate 的同步 patch 更新核心描述只有一句话Recognized the HyperEVM system sender that credits HyperCore transfers, so replaying transactions from a block that contains one no longer fails base fee validation.翻译过来就是Foundry 现在能够识别负责“入账”HyperCore 转账的 HyperEVM 系统发送者system sender从而在回放包含这类交易的区块时不再因 base fee 校验而失败。三个被标记为patch的 crate 恰好覆盖了修复的完整链路foundry-common新增/完善系统地址常量与判断逻辑是本次修复的“事实来源”castcast run等命令在回放区块时使用该判断逻辑跳过或特殊处理系统交易forge测试、fork 与合约验证等流程同样受益于对系统发送者的统一识别。1.2 什么是系统发送者System Sender在许多 L2 网络中每个区块的第一笔交易通常不是用户发起的而是由协议层自动注入的“系统交易”用于传递 L1 状态、处理跨链消息或结算手续费。这类交易的发送者是一个固定的、不存在的“系统地址”。Foundry 在 crates/common/src/constants.rs 中集中定义了这些已知的系统发送者/// Arbitrum L1 sender address of the first transaction in every block. /// 0x00000000000000000000000000000000000a4b05 pub const ARBITRUM_SENDER: Address address!(0x00000000000000000000000000000000000a4b05); /// The system address, the sender of the first transaction in every block: /// 0xdeaddeaddeaddeaddeaddeaddeaddeaddead0001 pub const OPTIMISM_SYSTEM_ADDRESS: Address address!(0xdeaddeaddeaddeaddeaddeaddeaddeaddead0001); /// The system address, the sender of the first transaction in every block: pub const MONAD_SYSTEM_ADDRESS: Address address!(0x6f49a8F621353f12378d0046E7d7e4b9B249DC9e); /// HyperEVM system address that credits HyperCore - HyperEVM native transfers. pub const HYPERLIQUID_SYSTEM_ADDRESS: Address address!(0x2222222222222222222222222222222222222222); /// MegaETH system address for Set Slots in the MegaETH oracle. pub const MEGA_SYSTEM_ADDRESS: Address address!(0xa887dcb9d5f39ef79272801d05abdf707cfbbd1d); /// Transaction identifier of System transaction types pub const SYSTEM_TRANSACTION_TYPE: u8 126;其中本次新增的核心是HYPERLIQUID_SYSTEM_ADDRESS地址为0x2222222222222222222222222222222222222222其文档注释给出了与本次修复完全对应的动机HyperEVM system address that credits HyperCore - HyperEVM native transfers. These are legacy envelopes withgasPrice 0and a receiptgasUsedof0, so replaying one as a regular transaction fails base fee validation and aborts the whole block replay.也就是说HyperCore 向 HyperEVM 发起原生转账native transfer时入账方交易由该固定系统地址发出并且采用的是gasPrice 0、receiptgasUsed 0的“legacy envelope”形态。这正是后续一切问题的根源。二、问题机理为什么回放会触发 base fee 校验失败要理解修复的价值先要弄清楚“回放一个区块”在 Foundry 里意味着什么。2.1 区块回放Block Replay的工作方式以cast run为例当需要复现某笔历史交易时Foundry 并不只执行目标交易本身而是先按顺序执行目标交易所在区块中位于其之前的所有前缀交易prefix transactions以还原目标交易执行时的链上状态。核心逻辑位于 crates/cast/src/cmd/run.rs 的for_each_prefix_transaction流程中前缀交易全部执行成功、状态落库后再执行目标交易。这种机制天然要求区块内每一笔前缀交易都能被本地 EVM 正常执行。一旦其中任何一笔交易在本地回放时失败整个回放过程就会中断。2.2 失败原因gasPrice 0 与 base fee 的矛盾在 EIP-1559 生效的链上交易的有效 gas 价格effective gas price必须不低于区块的 base fee否则交易无法被打包。而 HyperEVM 的这类系统交易是gasPrice 0的 legacy envelope本地回放时EVM 会按普通交易路径校验该交易的 gas 价格与区块 base fee 的关系gasPrice 0 base fee校验必然失败一旦该校验抛错cast run的整块回放就会中止目标交易自然也无法得到正确的执行上下文。这就是 changelog 中 “fails base fee validation and aborts the whole block replay” 的完整机理问题交易本身并不需要被“真实”执行它只是被当作普通交易硬塞进了本地 EVM才触发了 fee 校验。2.3 修复思路修复的关键不在于提高 gasPrice而在于在回放之前识别出这类系统交易不把它们当作普通用户交易去执行。Foundry 将这一判断收敛为统一的公共函数is_known_system_sender同样位于 crates/common/src/constants.rs/// Returns whether the sender is a known L2 system sender that is the first tx in every block. pub fn is_known_system_sender(sender: Address) - bool { [ ARBITRUM_SENDER, OPTIMISM_SYSTEM_ADDRESS, MONAD_SYSTEM_ADDRESS, MEGA_SYSTEM_ADDRESS, HYPERLIQUID_SYSTEM_ADDRESS, Address::ZERO, ] .contains(sender) }把HYPERLIQUID_SYSTEM_ADDRESS加入这份名单后凡是发送者为0x2222...2222的交易在回放流程中都会被识别为系统交易并走特殊路径跳过或按系统交易语义处理从而绕开普通交易的 base fee 校验。从源码结构可以推断这套名单是增量维护的Arbitrum、OP-stack、Monad、MegaETH 之后HyperEVM 成为又一个被纳入的 L2 网络。三、修复落地从常量到执行器的完整链路仅靠一个常量并不能解决问题关键在于回放路径的每一环都调用同一个判断。下面沿着调用链看修复是如何贯穿cast与 EVM 执行层的。3.1 cast 侧目标交易与前缀交易的双重拦截在cast run中判断逻辑集中在 crates/cast/src/cmd/run.rs 的辅助函数fn is_system_transaction(tx: AnyRpcTransaction) - bool { is_known_system_sender(tx.from()) || tx.transaction_type() Some(SYSTEM_TRANSACTION_TYPE) }即“发送者是已知系统地址或交易类型是 126系统交易类型”二者满足其一即视为系统交易。该判断被用在两个地方目标交易拦截在run_with_evm中如果用户直接用cast run重放的目标交易本身就是系统交易且未显式指定--replay-system-txes命令会直接报错退出if is_system_transaction(target.tx) !self.replay_system_txes { eyre::bail!( {:?} is a system transaction.\nReplaying system transactions is currently not supported., target.tx.tx_hash() ); }前缀交易过滤在块回放阶段只有非系统交易或用户显式要求重放系统交易才会进入本地执行循环if !is_system_transaction(tx) || replay_system_txes { // 执行该前缀交易并提交状态 }这意味着含 HyperEVM 系统发送者的区块其系统交易会被跳过不再进入本地 EVM 触发 base fee 校验整个区块可以正常回放完成。3.2 EVM 层backend 与 executor 的同步识别cast之外forge测试与 fork 场景同样会遇到带系统发送者的区块因此修复还必须下沉到 EVM 核心层两处实现均复用了is_known_system_sendercrates/evm/core/src/backend/mod.rs在replay_tx_env中判断is_known_system_sender(tx.from()) || tx.ty() SYSTEM_TRANSACTION_TYPE对系统 envelope 按构建能力决定跳过Ok(None)还是尽力解码crates/evm/evm/src/executors/mod.rs在 Monad 风格的区块重放transact_with_monad_block_replay中对is_known_system_sender(tx_env.caller()) || tx_env.tx_type() SYSTEM_TRANSACTION_TYPE的系统交易走try_transact_monad_system_replay特殊路径而非普通evm.transact。从这些实现可以推断Foundry 对“系统交易”的处理策略是分层的能按链语义重放如 Monad就特殊重放否则直接跳过但绝不把它们当作普通交易送进 EVM——这正是避免 fee 校验失败的通用原则。四、验证与测试修复如何在仓库中被守护4.1 常量级测试crates/common/src/constants.rs 内置了单元测试校验系统地址常量与期望值一致#[test] fn test_constant_sender() { let arb address!(0x00000000000000000000000000000000000a4b05); assert_eq!(arb, ARBITRUM_SENDER); let base address!(0xdeaddeaddeaddeaddeaddeaddeaddeaddead0001); assert_eq!(base, OPTIMISM_SYSTEM_ADDRESS); }这类测试保证已知的系统地址不会被误改为本次 HyperEVM 地址的加入提供了回归保护。4.2 fork 与验证场景测试crates/anvil/tests/it/fork_chains.rs 中提供了flaky_test_fork_hyperliquid通过assert_can_fork(NamedChain::Hyperliquid)验证 anvil 可以成功 fork HyperEVM 最新区块覆盖了系统交易可能出现的真实链上环境crates/forge/tests/cli/verify.rs 中的deploy_verify_hyperevm_testnet_sourcify组合了NamedChain::HyperliquidTestnet与 Sourcify 验证流程说明 HyperEVM 已进入 Foundry 的链名与验证矩阵crates/forge/tests/cli/test_cmd/spec.rs 中还有test_gas_paying_system_sender_target_fork_is_rejected这类测试守护“以系统发送者为目标的 fork 应被拒绝”的边界行为与 crates/cast/src/cmd/receive_policy.rs 中“拦截系统发送者需显式--force”的提示形成呼应。这些测试共同说明修复并非只改一个常量而是由常量、执行器、CLI 拦截与链级测试构成的一个闭环。五、实践指南在包含 HyperEVM 系统交易的区块上使用 Foundry5.1cast run的相关参数cast run在 crates/cast/src/cmd/run.rs 中定义了与系统交易直接相关的参数--replay-system-txes, --sys 是否重放系统交易默认不重放 --quick 仅使用前一区块的状态执行目标交易不做完整块回放使用要点默认行为回放区块时自动跳过系统发送者的交易包括 HyperEVM 系统地址因此包含gasPrice 0系统交易的 HyperEVM 区块也能顺利完成回放目标交易是系统交易直接重放会报 “Replaying system transactions is currently not supported”需显式加--replay-system-txes想跳过完整回放使用--quick只基于前一区块状态执行目标交易天然绕开前缀交易中的系统交易问题不想本地回放cast run --debug-trace-transaction直接通过节点的debug_traceTransaction取 call 树完全跳过本地块回放也从机制上规避了 fee 校验问题前提是 RPC 节点开放debug_命名空间。5.2 HyperEVM 网络的 RPC 配置Foundry 在 crates/test-utils/src/rpc.rs 中给出了测试环境下的 HyperEVM RPC 获取方式可作为配置参考if matches!(chain, Hyperliquid) { return env_rpc_url(HYPERLIQUID_RPC) .unwrap_or_else(|| https://rpc.hyperliquid.xyz/evm.to_string()); }即可以通过环境变量HYPERLIQUID_RPC覆盖默认的 HyperEVM 公开 RPC 端点仓库内 deny.toml 中的注释也提到 HyperliquidTestnet 相关的依赖处理仍在跟进说明该网络在依赖与链定义层面是持续演进的状态。5.3 常见错误排查现象可能原因处理方式cast run回放区块时中断提示 base fee 校验失败区块包含gasPrice 0的 HyperEVM 系统交易且使用的 Foundry 版本未包含本次修复升级到包含本 changelog 的版本使HYPERLIQUID_SYSTEM_ADDRESS被识别提示 “is a system transaction. Replaying system transactions is currently not supported”目标交易本身是系统交易显式加--replay-system-txes或改用--quick/--debug-trace-transactionfork HyperEVM 失败RPC 端点不可用或非 archive 节点通过HYPERLIQUID_RPC指定 archive 节点参考 crates/test-utils/src/rpc.rs六、总结本次变更通过“一个常量 一个统一判断函数 各回放路径复用”的方式把 HyperEVM 系统发送者0x2222222222222222222222222222222222222222纳入 Foundry 的已知系统发送者名单问题HyperCore → HyperEVM 的原生转账以gasPrice 0、receiptgasUsed 0的 legacy envelope 形态出现按普通交易回放必然触发 base fee 校验失败导致整个区块回放中止修复在 crates/common/src/constants.rs 中新增HYPERLIQUID_SYSTEM_ADDRESS并加入is_known_system_sender名单cast与forge的所有回放路径crates/cast/src/cmd/run.rs、crates/evm/core/src/backend/mod.rs、crates/evm/evm/src/executors/mod.rs统一识别并跳过/特殊处理系统交易验证HyperEVM fork 测试、Sourcify 验证矩阵与系统交易边界测试共同守护该行为实践cast run默认跳过系统交易必要时使用--replay-system-txes、--quick或--debug-trace-transaction灵活控制回放策略。对于任何需要回放历史交易或 fork HyperEVM 的开发者理解这条系统发送者识别机制是避免“莫名其妙回放失败”的关键一步。【免费下载链接】foundryFoundry is a blazing fast, portable and modular toolkit for Ethereum application development written in Rust.项目地址: https://gitcode.com/GitHub_Trending/fo/foundry创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Foundry 识别 HyperEVM 系统发送者：修复区块重放中的 Base Fee 校验失败
Foundry 识别 HyperEVM 系统发送者修复区块重放中的 Base Fee 校验失败【免费下载链接】foundryFoundry is a blazing fast, portable and modular toolkit for Ethereum application development written in Rust.项目地址: https://gitcode.com/GitHub_Trending/fo/foundryHyperEVMHyperliquid EVM在每笔由 HyperCore 跨链转账“入账”的交易都由一个固定的系统地址作为发送者且这些交易带有gasPrice 0、receiptgasUsed 0的特殊形态。本文以 Foundry 仓库中的 变更记录 .changelog/cast-hyperliquid-system-sender.md 为核心结合源码、测试与 CLI 实现完整剖析 Foundry 如何识别 HyperEVM 系统发送者以及为什么回放replay包含此类交易的区块时会出现 base fee 校验失败、修复又是如何落地的。读完你可以理解 Foundry 在 L2 系统交易处理上的整体设计并掌握cast run等命令在相关场景下的正确用法。一、变更背景什么是 HyperEVM 系统发送者1.1 变更内容速览该 changelog 记录的是一次foundry-common、cast、forge三个 crate 的同步 patch 更新核心描述只有一句话Recognized the HyperEVM system sender that credits HyperCore transfers, so replaying transactions from a block that contains one no longer fails base fee validation.翻译过来就是Foundry 现在能够识别负责“入账”HyperCore 转账的 HyperEVM 系统发送者system sender从而在回放包含这类交易的区块时不再因 base fee 校验而失败。三个被标记为patch的 crate 恰好覆盖了修复的完整链路foundry-common新增/完善系统地址常量与判断逻辑是本次修复的“事实来源”castcast run等命令在回放区块时使用该判断逻辑跳过或特殊处理系统交易forge测试、fork 与合约验证等流程同样受益于对系统发送者的统一识别。1.2 什么是系统发送者System Sender在许多 L2 网络中每个区块的第一笔交易通常不是用户发起的而是由协议层自动注入的“系统交易”用于传递 L1 状态、处理跨链消息或结算手续费。这类交易的发送者是一个固定的、不存在的“系统地址”。Foundry 在 crates/common/src/constants.rs 中集中定义了这些已知的系统发送者/// Arbitrum L1 sender address of the first transaction in every block. /// 0x00000000000000000000000000000000000a4b05 pub const ARBITRUM_SENDER: Address address!(0x00000000000000000000000000000000000a4b05); /// The system address, the sender of the first transaction in every block: /// 0xdeaddeaddeaddeaddeaddeaddeaddeaddead0001 pub const OPTIMISM_SYSTEM_ADDRESS: Address address!(0xdeaddeaddeaddeaddeaddeaddeaddeaddead0001); /// The system address, the sender of the first transaction in every block: pub const MONAD_SYSTEM_ADDRESS: Address address!(0x6f49a8F621353f12378d0046E7d7e4b9B249DC9e); /// HyperEVM system address that credits HyperCore - HyperEVM native transfers. pub const HYPERLIQUID_SYSTEM_ADDRESS: Address address!(0x2222222222222222222222222222222222222222); /// MegaETH system address for Set Slots in the MegaETH oracle. pub const MEGA_SYSTEM_ADDRESS: Address address!(0xa887dcb9d5f39ef79272801d05abdf707cfbbd1d); /// Transaction identifier of System transaction types pub const SYSTEM_TRANSACTION_TYPE: u8 126;其中本次新增的核心是HYPERLIQUID_SYSTEM_ADDRESS地址为0x2222222222222222222222222222222222222222其文档注释给出了与本次修复完全对应的动机HyperEVM system address that credits HyperCore - HyperEVM native transfers. These are legacy envelopes withgasPrice 0and a receiptgasUsedof0, so replaying one as a regular transaction fails base fee validation and aborts the whole block replay.也就是说HyperCore 向 HyperEVM 发起原生转账native transfer时入账方交易由该固定系统地址发出并且采用的是gasPrice 0、receiptgasUsed 0的“legacy envelope”形态。这正是后续一切问题的根源。二、问题机理为什么回放会触发 base fee 校验失败要理解修复的价值先要弄清楚“回放一个区块”在 Foundry 里意味着什么。2.1 区块回放Block Replay的工作方式以cast run为例当需要复现某笔历史交易时Foundry 并不只执行目标交易本身而是先按顺序执行目标交易所在区块中位于其之前的所有前缀交易prefix transactions以还原目标交易执行时的链上状态。核心逻辑位于 crates/cast/src/cmd/run.rs 的for_each_prefix_transaction流程中前缀交易全部执行成功、状态落库后再执行目标交易。这种机制天然要求区块内每一笔前缀交易都能被本地 EVM 正常执行。一旦其中任何一笔交易在本地回放时失败整个回放过程就会中断。2.2 失败原因gasPrice 0 与 base fee 的矛盾在 EIP-1559 生效的链上交易的有效 gas 价格effective gas price必须不低于区块的 base fee否则交易无法被打包。而 HyperEVM 的这类系统交易是gasPrice 0的 legacy envelope本地回放时EVM 会按普通交易路径校验该交易的 gas 价格与区块 base fee 的关系gasPrice 0 base fee校验必然失败一旦该校验抛错cast run的整块回放就会中止目标交易自然也无法得到正确的执行上下文。这就是 changelog 中 “fails base fee validation and aborts the whole block replay” 的完整机理问题交易本身并不需要被“真实”执行它只是被当作普通交易硬塞进了本地 EVM才触发了 fee 校验。2.3 修复思路修复的关键不在于提高 gasPrice而在于在回放之前识别出这类系统交易不把它们当作普通用户交易去执行。Foundry 将这一判断收敛为统一的公共函数is_known_system_sender同样位于 crates/common/src/constants.rs/// Returns whether the sender is a known L2 system sender that is the first tx in every block. pub fn is_known_system_sender(sender: Address) - bool { [ ARBITRUM_SENDER, OPTIMISM_SYSTEM_ADDRESS, MONAD_SYSTEM_ADDRESS, MEGA_SYSTEM_ADDRESS, HYPERLIQUID_SYSTEM_ADDRESS, Address::ZERO, ] .contains(sender) }把HYPERLIQUID_SYSTEM_ADDRESS加入这份名单后凡是发送者为0x2222...2222的交易在回放流程中都会被识别为系统交易并走特殊路径跳过或按系统交易语义处理从而绕开普通交易的 base fee 校验。从源码结构可以推断这套名单是增量维护的Arbitrum、OP-stack、Monad、MegaETH 之后HyperEVM 成为又一个被纳入的 L2 网络。三、修复落地从常量到执行器的完整链路仅靠一个常量并不能解决问题关键在于回放路径的每一环都调用同一个判断。下面沿着调用链看修复是如何贯穿cast与 EVM 执行层的。3.1 cast 侧目标交易与前缀交易的双重拦截在cast run中判断逻辑集中在 crates/cast/src/cmd/run.rs 的辅助函数fn is_system_transaction(tx: AnyRpcTransaction) - bool { is_known_system_sender(tx.from()) || tx.transaction_type() Some(SYSTEM_TRANSACTION_TYPE) }即“发送者是已知系统地址或交易类型是 126系统交易类型”二者满足其一即视为系统交易。该判断被用在两个地方目标交易拦截在run_with_evm中如果用户直接用cast run重放的目标交易本身就是系统交易且未显式指定--replay-system-txes命令会直接报错退出if is_system_transaction(target.tx) !self.replay_system_txes { eyre::bail!( {:?} is a system transaction.\nReplaying system transactions is currently not supported., target.tx.tx_hash() ); }前缀交易过滤在块回放阶段只有非系统交易或用户显式要求重放系统交易才会进入本地执行循环if !is_system_transaction(tx) || replay_system_txes { // 执行该前缀交易并提交状态 }这意味着含 HyperEVM 系统发送者的区块其系统交易会被跳过不再进入本地 EVM 触发 base fee 校验整个区块可以正常回放完成。3.2 EVM 层backend 与 executor 的同步识别cast之外forge测试与 fork 场景同样会遇到带系统发送者的区块因此修复还必须下沉到 EVM 核心层两处实现均复用了is_known_system_sendercrates/evm/core/src/backend/mod.rs在replay_tx_env中判断is_known_system_sender(tx.from()) || tx.ty() SYSTEM_TRANSACTION_TYPE对系统 envelope 按构建能力决定跳过Ok(None)还是尽力解码crates/evm/evm/src/executors/mod.rs在 Monad 风格的区块重放transact_with_monad_block_replay中对is_known_system_sender(tx_env.caller()) || tx_env.tx_type() SYSTEM_TRANSACTION_TYPE的系统交易走try_transact_monad_system_replay特殊路径而非普通evm.transact。从这些实现可以推断Foundry 对“系统交易”的处理策略是分层的能按链语义重放如 Monad就特殊重放否则直接跳过但绝不把它们当作普通交易送进 EVM——这正是避免 fee 校验失败的通用原则。四、验证与测试修复如何在仓库中被守护4.1 常量级测试crates/common/src/constants.rs 内置了单元测试校验系统地址常量与期望值一致#[test] fn test_constant_sender() { let arb address!(0x00000000000000000000000000000000000a4b05); assert_eq!(arb, ARBITRUM_SENDER); let base address!(0xdeaddeaddeaddeaddeaddeaddeaddeaddead0001); assert_eq!(base, OPTIMISM_SYSTEM_ADDRESS); }这类测试保证已知的系统地址不会被误改为本次 HyperEVM 地址的加入提供了回归保护。4.2 fork 与验证场景测试crates/anvil/tests/it/fork_chains.rs 中提供了flaky_test_fork_hyperliquid通过assert_can_fork(NamedChain::Hyperliquid)验证 anvil 可以成功 fork HyperEVM 最新区块覆盖了系统交易可能出现的真实链上环境crates/forge/tests/cli/verify.rs 中的deploy_verify_hyperevm_testnet_sourcify组合了NamedChain::HyperliquidTestnet与 Sourcify 验证流程说明 HyperEVM 已进入 Foundry 的链名与验证矩阵crates/forge/tests/cli/test_cmd/spec.rs 中还有test_gas_paying_system_sender_target_fork_is_rejected这类测试守护“以系统发送者为目标的 fork 应被拒绝”的边界行为与 crates/cast/src/cmd/receive_policy.rs 中“拦截系统发送者需显式--force”的提示形成呼应。这些测试共同说明修复并非只改一个常量而是由常量、执行器、CLI 拦截与链级测试构成的一个闭环。五、实践指南在包含 HyperEVM 系统交易的区块上使用 Foundry5.1cast run的相关参数cast run在 crates/cast/src/cmd/run.rs 中定义了与系统交易直接相关的参数--replay-system-txes, --sys 是否重放系统交易默认不重放 --quick 仅使用前一区块的状态执行目标交易不做完整块回放使用要点默认行为回放区块时自动跳过系统发送者的交易包括 HyperEVM 系统地址因此包含gasPrice 0系统交易的 HyperEVM 区块也能顺利完成回放目标交易是系统交易直接重放会报 “Replaying system transactions is currently not supported”需显式加--replay-system-txes想跳过完整回放使用--quick只基于前一区块状态执行目标交易天然绕开前缀交易中的系统交易问题不想本地回放cast run --debug-trace-transaction直接通过节点的debug_traceTransaction取 call 树完全跳过本地块回放也从机制上规避了 fee 校验问题前提是 RPC 节点开放debug_命名空间。5.2 HyperEVM 网络的 RPC 配置Foundry 在 crates/test-utils/src/rpc.rs 中给出了测试环境下的 HyperEVM RPC 获取方式可作为配置参考if matches!(chain, Hyperliquid) { return env_rpc_url(HYPERLIQUID_RPC) .unwrap_or_else(|| https://rpc.hyperliquid.xyz/evm.to_string()); }即可以通过环境变量HYPERLIQUID_RPC覆盖默认的 HyperEVM 公开 RPC 端点仓库内 deny.toml 中的注释也提到 HyperliquidTestnet 相关的依赖处理仍在跟进说明该网络在依赖与链定义层面是持续演进的状态。5.3 常见错误排查现象可能原因处理方式cast run回放区块时中断提示 base fee 校验失败区块包含gasPrice 0的 HyperEVM 系统交易且使用的 Foundry 版本未包含本次修复升级到包含本 changelog 的版本使HYPERLIQUID_SYSTEM_ADDRESS被识别提示 “is a system transaction. Replaying system transactions is currently not supported”目标交易本身是系统交易显式加--replay-system-txes或改用--quick/--debug-trace-transactionfork HyperEVM 失败RPC 端点不可用或非 archive 节点通过HYPERLIQUID_RPC指定 archive 节点参考 crates/test-utils/src/rpc.rs六、总结本次变更通过“一个常量 一个统一判断函数 各回放路径复用”的方式把 HyperEVM 系统发送者0x2222222222222222222222222222222222222222纳入 Foundry 的已知系统发送者名单问题HyperCore → HyperEVM 的原生转账以gasPrice 0、receiptgasUsed 0的 legacy envelope 形态出现按普通交易回放必然触发 base fee 校验失败导致整个区块回放中止修复在 crates/common/src/constants.rs 中新增HYPERLIQUID_SYSTEM_ADDRESS并加入is_known_system_sender名单cast与forge的所有回放路径crates/cast/src/cmd/run.rs、crates/evm/core/src/backend/mod.rs、crates/evm/evm/src/executors/mod.rs统一识别并跳过/特殊处理系统交易验证HyperEVM fork 测试、Sourcify 验证矩阵与系统交易边界测试共同守护该行为实践cast run默认跳过系统交易必要时使用--replay-system-txes、--quick或--debug-trace-transaction灵活控制回放策略。对于任何需要回放历史交易或 fork HyperEVM 的开发者理解这条系统发送者识别机制是避免“莫名其妙回放失败”的关键一步。【免费下载链接】foundryFoundry is a blazing fast, portable and modular toolkit for Ethereum application development written in Rust.项目地址: https://gitcode.com/GitHub_Trending/fo/foundry创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考