Foundry 支持 Tempo T13 硬分叉检测与 Keychain 授权 ABI 更新解读
发布时间：2026/9/16 12:11:10 作者：尧图编辑部 阅读量：1,286
Foundry 支持 Tempo T13 硬分叉检测与 Keychain 授权 ABI 更新解读【免费下载链接】foundryFoundry is a blazing fast, portable and modular toolkit for Ethereum application development written in Rust.项目地址: https://gitcode.com/GitHub_Trending/fo/foundry本篇技术指南围绕 Foundry 仓库中的变更记录 .changelog/tempo-t13-detection.md 展开系统讲解 Foundry 如何将 Tempo 网络支持推进到 T13 硬分叉Cast 通过链上/节点信息自动检测活跃硬分叉并切换到当前版本的 keychain 授权 ABI。读完本文你将理解FoundryHardfork统一硬分叉枚举的工作原理、cast keychain系列命令背后的 precompile ABI 设计以及这些能力在 cast、forge、anvil、chisel 四个工具中的落地方式与测试验证路径。变更概览一次横跨四个工具的 patch该变更记录以 Foundry 标准的 changelog 条目形式声明了四个工具的同步更新受影响工具变更类型castpatchforgepatchanvilpatchchiselpatchfoundry-evm-hardforkspatch其核心内容为将 Tempo 支持推进到 T13 硬分叉使得 Cast 能够正确检测当前活跃的 Tempo 硬分叉根据 RPC 返回或 Anvil 节点信息使用当前版本的 keychain 授权 ABI即与 T13 时代一致的IAccountKeychainprecompile 接口。底层硬分叉定义变更集中在 crates/evm/hardforks/src/lib.rsfoundry-evm-hardforkscrate而 Cast 侧的交易辅助逻辑在 crates/cast/src/tempo.rskeychain 命令实现在 crates/cast/src/cmd/keychain.rs。Tempo 硬分叉在 Foundry 中的统一表示FoundryHardfork统一的硬分叉枚举在 crates/evm/hardforks/src/lib.rs 中Foundry 将多个网络的硬分叉统一收敛为一个枚举pub enum FoundryHardfork { Ethereum(EthereumHardfork), #[cfg(feature optimism)] Optimism(OpHardfork), Tempo(TempoHardfork), #[cfg(feature monad)] Monad(MonadHardfork), }其中TempoHardfork直接pub use自外部tempo-hardforkcrate同文件第 20 行该依赖在根 Cargo.toml 中以 git rev 形式锁定版本。也就是说Tempo 硬分叉的激活时间表T1 到 T13 的激活区块/时间戳由 Tempo 官方仓库定义Foundry 通过统一枚举将其纳入自己的硬分叉调度体系。network:hardfork 命名空间与解析规则FoundryHardfork实现了FromStr、Serialize/Deserialize支持 CLI 与配置文件两种使用场景。命名空间前缀规则lib.rs#L62-L100eth/ethereum→EthereumHardforkop/optimism→OpHardfork需启用optimismfeature默认开启t/tempo→TempoHardforkm/monad→MonadHardfork需启用monadfeature无前缀时优先按 Ethereum 解析失败后回退到同名尝试对应的序列化格式为tempo:T13这样的字符串namespace()方法对 Tempo 返回Some(tempo)lib.rs#L136-L145。活跃硬分叉的自动检测链级调度from_chain_and_timestamp本次变更的核心能力之一是正确检测活跃硬分叉。其实现入口是FoundryHardfork::from_chain_and_timestamp(chain_id, timestamp)lib.rs#L150-L167pub fn from_chain_and_timestamp(chain_id: u64, timestamp: u64) - OptionSelf { let chain Chain::from_id(chain_id); if let Some(fork) EthereumHardfork::from_chain_and_timestamp(chain, timestamp) { return Some(Self::Ethereum(fork)); } // ...Optimism 分支feature 门控 if let Some(fork) TempoHardfork::from_chain_and_timestamp(chain_id, timestamp) { return Some(Self::Tempo(fork)); } // ...Monad 分支feature 门控 None }它按Ethereum → Optimism → Tempo → Monad的顺序尝试各网络给定链 ID 与时间戳后返回该时刻处于激活状态的硬分叉。对 Tempo 而言其内部按已知 Tempo 网络主网 chain ID4217、Moderato 测试网 chain ID42431的激活时间表计算。仓库测试 test_tempo_hardfork_from_chain_and_timestamp 以边界时间戳验证了该函数在主网与 Moderato 上的正确性——例如在MAINNET_T8_TIMESTAMP - 1时返回T7、在MAINNET_T8_TIMESTAMP时返回T8证明了时间戳边界切换这一行为。由于 T13 激活时间表由上游tempo-hardforkcrate 提供传入u64::MAX代表未来时刻即可探测到当前最新硬分叉仓库测试中对应返回T11说明该快照对应的上游最新已调度分叉。最新活跃硬分叉的快捷查询latest_active_tempo_hardfork()lib.rs#L534-L543读取系统当前时间分别查询主网与 Moderato 的激活状态取两者中已激活的最新分叉用于当前默认 Tempo 执行规范的确定——例如FromEvmVersion for TempoHardfork会把EvmVersion::Osaka映射到latest_active_tempo_hardfork()lib.rs#L465-L469并有测试 test_tempo_evm_version_defaults_to_latest_active_hardfork 保证这一点。RPC 层的活跃性探测is_tempo_hardfork_active检测动作真正发生的位置在 crates/cast/src/tempo.rs 的is_tempo_hardfork_active。它采用两级探测策略首选调用 Tempo 提供者扩展方法provider.is_hardfork_active(hardfork)直接询问 RPC 当前激活的硬分叉若 RPC 不支持该方法is_rpc_method_not_found错误则回退到 Anvil 特有的anvil_nodeInfoRPC解析network tempo且hard_fork 目标分叉来判断tempo.rs#L230-L245。单元测试 tempo_fork_schedule_detects_t13_as_t3_active 直接印证了本次变更的关键语义当 RPC 返回{ active: T13 }时is_tempo_hardfork_active(provider, T3)判定为 true——因为T13 T3激活顺序具备单调性。这正是正确检测活跃硬分叉在 Cast 侧的落地无论链上处于 T10、T11、T12 还是 T13Cast 都能正确判断某个 precompile 能力是否可用。require_hardforktempo.rs#L178-L188在此基础上提供前置校验能力命令执行前先断言目标硬分叉已激活否则直接报错。例如cast keychain burn-witness要求 T5、is-admin要求 T6见 keychain.rs#L779-L826。Keychain 授权 ABI从 T10 到 T13 保持一致变更记录强调使用当前 keychain 授权 ABI。这对应 Cast 的cast keychain命令族它通过 Tempo 的IAccountKeychainprecompileACCOUNT_KEYCHAIN_ADDRESS进行链上密钥管理ABI 类型定义来自tempo_contracts::precompileskeychain.rs#L45-L60。keychain 子命令一览KeychainSubcommandkeychain.rs#L67-L397包含完整的密钥生命周期管理子命令功能硬分叉要求list/show读取本地 Tempo Accounts store~/.tempo/wallet/store.json无check/inspect通过 precompile 查询链上密钥状态与策略无doctor端到端诊断访问密钥签名问题无authorize/auth链上授权新密钥支持 secp256k1 / p256 / webauthn无revoke/rev撤销已授权密钥无burn-witness销毁 TIP-1053 密钥授权 witnessT5is-witness-burned查询 witness 是否已销毁T5is-admin检查根密钥/管理密钥T6 管理密钥T6verify/verify-admin验证 keychain 签名普通访问密钥 / 根或管理密钥无rl/remaining-limit查询密钥在某 token 上的剩余限额T3 起支持额度语义ul/update-limit更新密钥花费限额无ss/set-scope设置允许调用范围无rs/remove-scope移除某个 target 的调用范围无policyTIP-1011 访问密钥权限的增删改查add-call/set-limit/remove-target无authorize支持丰富的策略参数包括--key-type签名类型secp256k1默认、p256或webauthn--expiry过期时间戳默认u64::MAX永不过期--limit TOKEN:AMOUNT[:PERIOD]花费限额可重复指定--scope TARGET[:SELECTORS[RECIPIENTS]]调用范围限制TARGET 单独出现表示允许对该地址的全部调用--scopesJSON 数组更结构化的范围描述例如[{target:0x...,selectors:[{selector:transfer,recipients:[0x...]}]}]--witness可选的 TIP-1053 witness0x000...000是合法占位并区别于省略该标志--admin授权 T6 管理密钥仅限密钥管理不能携带限额与范围。这些参数解析器parse_auth_limit、parse_scope、parse_selector_bytes等位于 keychain.rs#L577-L706。T13 下 ABI 保持不变的验证使用当前的 keychain 授权 ABI并不意味着 T13 引入了新的 ABI而是指Cast 在 T13 时代继续使用与其匹配的正确 ABI 版本tuple 风格的新版authorizeKey系列调用。集成测试 keychain_set_scope_succeeds_through_t13 明确验证了这一点for hardfork in [TempoHardfork::T10, TempoHardfork::T11, TempoHardfork::T12, TempoHardfork::T13] { let (_, handle) anvil::spawn(NodeConfig::test_tempo().with_hardfork(Some(hardfork.into()))).await; // cast keychain authorize ... // cast keychain set-scope ... --scope target }该测试在 T10、T11、T12、T13 四个硬分叉下分别启动 Anvil Tempo 节点逐一执行cast keychain authorize与cast keychain set-scope断言全部成功。这从端到端角度证明从 T10 到 T13keychain 授权与范围设置的调用 ABI 保持兼容Cast 无需为每个硬分叉切换不同的编码格式同时验证了正确检测活跃硬分叉在真实节点上的行为。签名类型与 ABI 编码的对应代码中还体现了 ABI 类型与内部KeyType的映射关系abi_key_type将 ABI 的SignatureTypeSecp256k1/P256/WebAuthn转换为本地KeyType并以key_type_name/key_type_label提供展示用名称keychain.rs#L591-L609。这保证了 CLI 输入的字符串类型与 precompile ABI 编码严格对应。T13 在其它工具中的影响forge共享foundry-evm-hardforks的硬分叉定义与evm_spec_id_from_str解析逻辑支持T13与tempo:T13两种写法见 lib.rs 测试 L783-L790测试与脚本可按 Tempo 硬分叉名直接指定 EVM 规范。anvil作为本地 Tempo 开发节点支持with_hardfork配置到 T13测试用例即以此方式启动并通过anvil_nodeInfo向 Cast 暴露当前激活硬分叉构成 RPC 探测的回退路径。chisel与 cast 共享 EVM 与 RPC 基础设施硬分叉检测的更新同步生效。从解析到执行的完整调用链将以上内容串起来一次在 Tempo T13 链上执行 keychain 操作的完整链路为用户在cast keychain authorize key --rpc-url tempo_rpc ...中指定 RPCtempo_provider 从配置构建RetryProviderTempoNetwork命令执行前通过is_tempo_hardfork_active探测活跃硬分叉RPC 方法优先Anvil 回退必要时以require_hardfork前置校验使用IAccountKeychain的authorizeKey或authorizeAdminKey、legacyAuthorizeKey构建 precompile 调用签名后上链若配置了赞助sponsor或访问密钥由apply_fee_payment等逻辑处理 fee token 与赞助签名tempo.rs#L47-L72。整条链路都建立在活跃硬分叉能被正确识别这一前提之上这正是本次 T13 变更的意义所在让工具在最新 Tempo 网络上保持可用同时不破坏历史硬分叉下的兼容性。总结本次 T13 支持变更是一次典型的演进性兼容更新检测层面通过FoundryHardfork::from_chain_and_timestamp与is_tempo_hardfork_activeCast 可精确判断 Tempo 链当前激活的硬分叉并支持 Anvil 本地节点的信息回退ABI 层面T10 至 T13 期间 keychain 授权 ABI 保持一致cast keychain系列命令authorize、set-scope、policy 等无需分支切换即可在最新网络上运行测试保障单元测试时间戳边界、T13 T3的单调性、tempo:T13字符串解析与 Anvil 集成测试四个硬分叉下的真实链上操作共同锁定了行为。如果你正在 Tempo 网络上进行开发可以放心使用cast keychain管理访问密钥若需在测试中固定 EVM 规范T13或tempo:T13两种写法均可直接被evm_spec_id_from_str解析。【免费下载链接】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），仅供参考
尧图网站开发 