Foundry Cast Safe CLI 的确定性测试基座解析 Safe v1.4.1 运行时字节码 fixtures【免费下载链接】foundryFoundry is a blazing fast, portable and modular toolkit for Ethereum application development written in Rust.项目地址: https://gitcode.com/GitHub_Trending/fo/foundry本文聚焦 Foundry 仓库中为cast safe命令端到端测试所准备的 Safe v1.4.1 运行时字节码 fixtures这三个以“官方已部署代码”为蓝本 vendored 的二进制文件如何保证测试无需公网 RPC 或真实 Safe Transaction Service 即可确定性运行其来源provenance、格式约定与双重校验机制字节长度 Keccak-256 哈希在源码中的落点以及cast safe create等命令是如何基于这套 fixtures 完成全生命周期验证的。一、这批 fixtures 解决什么问题Safe原 Gnosis Safe是多签智能账户cast safe子命令负责在本地/远端链上创建并管理 Safe 实例。要对该命令做端到端end-to-end测试测试环境必须满足一个苛刻条件链上某组地址必须恰好部署着“官方 Safe v1.4.1 运行时字节码”否则cast safe create之后对 Safe 实例的getOwners()、getThreshold()、nonce()等调用都无法真实执行。正常情况下这依赖 fork 一条主网或接入公开的 Safe 服务但这会让测试变得不稳定且不可离线复现。仓库给出的解法是把官方部署的运行时字节码原样 vendor 进仓库在本地 anvil 节点启动后用anvil_setCode把代码安装到其规范部署地址canonical address上。fixtures 目录说明 明确指出这样做使“测试保持确定性不依赖公共 RPC 端点或在线的 Safe Transaction Service”。当前 fixtures 目录共 3 个二进制文件与 1 个说明文档SafeL2.runtime.binSafeProxyFactory.runtime.binSimulateTxAccessor.runtime.binREADME.md二、来源与授权与官方部署逐字节对齐这批 fixtures 对应 Safe Contracts v1.4.1 官方发布版本取自 safe-smart-account 仓库 commitbf943f80fec5ac647159d26161446ac5d716a294其规范部署地址与代码哈希则以 safe-deployments 仓库 v1.4.1 assetscommita1e93fb为对照基准。上游 Safe 合约采用 GNU LGPL v3.0 许可证这也解释了为什么 fixtures 目录保留了一份专门的 Provenance and license 说明。README 中的来源对照表是理解这套基座的核心完整保留如下FixtureDeployment asset规范部署地址运行时字节数Keccak-256 代码哈希SafeL2.runtime.binsafe_l2.json0x29fcB43b46531BcA003ddC8FCB67FFE91900C76224,4210xb1f926978a0f44a2c0ec8fe822418ae969bd8c3f18d61e5103100339894f81ffSafeProxyFactory.runtime.binsafe_proxy_factory.json0x4e1DCf7AD4e460CfD30791CCC4F9c8a4f820ec673,0540x50c3cdc4074750a7a974204a716c999edd37482f907608d960b2b025ee0b3317SimulateTxAccessor.runtime.binsimulate_tx_accessor.json0x3d4BA2E0884aa488718476ca2FB8Efc291A461998500x91f82615581fc73b190b83d72e883608b25e392f72322035df1b13d51766cf8d三个地址/长度/哈希在测试源码中被原样声明为常量见 safe.rs#L35-L46const SAFE_L2_V1_4_1: Address address!(29fcB43b46531BcA003ddC8FCB67FFE91900C762); const SAFE_PROXY_FACTORY_V1_4_1: Address address!(4e1DCf7AD4e460CfD30791CCC4F9c8a4f820ec67); const SIMULATE_TX_ACCESSOR_V1_4_1: Address address!(3d4BA2E0884aa488718476ca2FB8Efc291A46199); const SAFE_L2_V1_4_1_RUNTIME_LEN: usize 24_421; const SAFE_PROXY_FACTORY_V1_4_1_RUNTIME_LEN: usize 3_054; const SIMULATE_TX_ACCESSOR_V1_4_1_RUNTIME_LEN: usize 850; const SAFE_L2_V1_4_1_RUNTIME_HASH: B256 b256!(b1f926978a0f44a2c0ec8fe822418ae969bd8c3f18d61e5103100339894f81ff);对当前仓库文件的实测大小24421 / 3054 / 850 字节与 README 表格、源码常量三者完全一致说明 fixtures 与其文档承诺逐字节吻合。一个值得注意的细节是SimulateTxAccessor它含有一个immutable self-address编译期内嵌自身的部署地址。fixtures 中该 immutable 字使用的是规范地址0x3d4BA2E0...而非本地占位地址这正是其 Keccak-256 哈希能与已部署代码对齐的原因——如果直接拿编译产物替换地址哈希校验必然失败。这提示任何想复用/替换 fixtures 的团队immutable 自地址代码必须与目标部署地址绑定。三、文件格式约定是“运行时字节码”而非“创建字节码”README 的 Format and verification 一节明确了格式边界文件为已部署的运行时字节deployed runtime bytes不含0x前缀、无换行且不是合约创建字节码creation bytecode测试通过include_bytes!在编译期把它们嵌入二进制安装前先校验字节长度与Keccak-256 哈希双重指纹校验通过后用 anvil 的anvil_setCode方法把代码写入规范地址。这里的“运行时字节码 vs 创建字节码”区分对 EVM 测试很关键anvil_setCode写入的是运行时码直接对应链上eth_getCode的返回值若误用创建字节码含构造器逻辑部署后的代码哈希与主网部署就不一致所有依赖“与官方部署相同代码”的断言都会失效。四、源码级实现从校验到注入的完整链路fixtures 的消费方是 crates/cast/tests/cli/safe.rs约 1880 行的集成测试文件其核心流程可概括为三步1. 编译期嵌入 运行期双重校验fixture_runtimesafe.rs#L126接收include_bytes!得到的静态字节切片及“期望长度 期望哈希”两个常量在测试运行时验证两者均匹配后才返回可用于anvil_setCode的Bytes。这是典型的“fail fast”设计一旦 fixtures 被误改哪怕一个字节测试会在校验阶段而非断言阶段暴露问题。2. anvil 启动后立即安装三份代码以safe_v1_4_1_lifecycle_uses_stateful_service测试safe.rs#L966-L999为例let (api, handle) anvil::spawn(NodeConfig::test()).await; let provider handle.http_provider(); api.anvil_set_code( SAFE_L2_V1_4_1, fixture_runtime( include_bytes!(../fixtures/safe/v1.4.1/SafeL2.runtime.bin), SAFE_L2_V1_4_1_RUNTIME_LEN, SAFE_L2_V1_4_1_RUNTIME_HASH, ), ) .await .unwrap(); // 同样方式安装 SafeProxyFactory 与 SimulateTxAccessor …同一段测试还额外在目标地址写入一段最小 EVM 字节码0x6000546001016000553360005260206000f3即“对槽 0 加一并返回msg.sender”用于区分模拟调用的一次执行与重复调用——这体现了 fixtures 不仅用于部署还服务于对cast safe simulate一类行为的可观测断言。3. 基于已安装代码执行cast safe create全生命周期安装代码后测试驱动真实的cast safe create命令行safe.rs#L1012-L1044cast safe create owner1 owner2 --threshold 2 \ --singleton 0x29fcB43b46531BcA003ddC8FCB67FFE91900C762 \ --factory 0x4e1DCf7AD4e460CfD30791CCC4F9c8a4f820ec67 \ --fallback-handler 0x0000000000000000000000000000000000000000 \ --private-key 0x... --rpc-url anvil endpoint测试随后解析 stdout 中打印的 Safe 地址用alloy_sol_types::sol!声明的TestSafe接口safe.rs#L51-L90含nonce()、getOwners()、getThreshold()、getTransactionHash(...)、execTransaction(...)及ExecutionSuccess事件直接对链上 Safe 发起真实调用断言getOwners()返回两个 owner、getThreshold()为 2、nonce()为 0并调用getTransactionHash验证 Safe 交易哈希计算。此外同一文件还覆盖--legacyType-0 交易与显式--access-list参数对交易字段的实际影响safe.rs#L925-L964。同一组 fixtures 在文件后段被第二个生命周期测试约 L1761 起复用说明该基座被设计为多个独立测试用例共享的“一次性基础设施”进一步印证了 vendored 方案相对 fork 方案的复用价值。五、实践要点小结适用前提这套 fixtures 绑定 Safe v1.4.1 这一具体版本若测试目标换成 v1.3.x 或其他版本地址、字节数与哈希需整体替换不能混用。校验不可省略长度校验能抓住截断Keccak-256 校验能抓住任意位翻转二者同时声明于 safe.rs#L38-L46替换 fixtures 时必须同步更新这三组常量。不可用创建字节码顶替anvil_setCode语义要求运行时码从源码结构看整条断言链getOwners/getThreshold/getTransactionHash均返回真实值的前提就是链上代码与官方部署逐字节一致。immutable 地址的陷阱SimulateTxAccessor类含自地址的合约fixtures 必须采用规范地址编入 immutable否则哈希与部署事实脱节。离线可复现整套方案不依赖公共 RPC 与在线 Safe Transaction Service服务侧交互由测试内基于 axum 的本地 mock HTTP 服务spawn_safe_servicesafe.rs#L109承担与 fixtures 共同构成cast safe命令的确定性测试闭环。对维护者而言这份文档与其三个.bin文件、crates/cast/tests/cli/safe.rs 构成一个自洽单元文档负责声明“这些字节是谁、从哪来、怎么验”源码负责执行“验过了才允许装进节点”二者配合使 Safe 相关 CLI 行为测试在 CI 中无需任何外部依赖即可稳定运行。【免费下载链接】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），仅供参考
