如何只用4个预编译合约判断是否在zkSync链foundry-devops的isOnZkSyncPrecompiles原理深扒【免费下载链接】foundry-devops项目地址: https://gitcode.com/gh_mirrors/fo/foundry-devops你是否遇到过这样的窘境同一套 Foundry 测试在以太坊主网上跑得好好的切到 zkSync 链上却频频失败foundry-devops 就是为此而生的Foundry 开发运维工具集它的核心能力之一是通过预编译合约差异自动判断当前是否运行在 zkSync 链上。本文深扒isOnZkSyncPrecompiles函数的设计原理带你搞懂这套4个预编译合约探测 zkSync的巧妙方案。 为什么需要判断是否在 zkSync 链上zkSync 是以太坊 L2 扩容方案虽然兼容 EVM但并非所有以太坊预编译合约都已实现。这意味着依赖RIPEMD-160、椭圆曲线运算等预编译的合约在 zkSync 上会直接调用失败你在本地 Foundry 和foundry-zksync之间切换时同一份测试代码需要知道自己此刻身处哪条链才能决定跳过哪些用例。传统做法是硬编码链 ID 判断但 Foundry 本地环境中链 ID 可以随意配置链 ID 并不可靠。foundry-devops 给出的答案分两层先用链 ID 走快速路径再用预编译行为做终极裁决。️ 核心原理4个预编译合约探测 zkSync主角位于src/ZkSyncChainChecker.sol中的isOnZkSyncPrecompiles()。原理一句话概括在 zkSync 上至少有 4 个以太坊预编译合约不被支持挨个打电话谁不接就证明这是 zkSync。预编译地址名称以太坊上的作用zkSync 表现0x03RIPEMDRIPEMD-160 哈希❌ 不支持调用失败0x04Identity数据原样返回❌ 不支持调用失败0x05ModExp模幂运算加密常用❌ 不支持调用失败0x08椭圆曲线运算曲线标量乘/配对相关❌ 不支持调用失败函数内部维护这 4 个目标地址通过内联汇编逐一下发call携带 1 wei 的转账值并检查返回的成功标志// 核心检测逻辑节选自 src/ZkSyncChainChecker.sol for (uint256 i 0; i targets.length; i) { bool success; assembly { success : call(gas(), targets[i], value, 0, 0, 0, 0) } if (!success) { return true; // 任一预编译调用失败 → 判定为 zkSync } }判断逻辑非常暴力美学任一预编译调用失败→ 立即返回true在 zkSync 上4 个全部成功→ 返回false大概率是标准以太坊 EVM。之所以用低层call而不是直接函数调用是因为预编译合约没有 ABI 可调用只能通过底层调用观察success标志——这正是 Solidity 开发者少用但极其好用的探测技术。⚡ 链ID快速路径isOnZkSyncChainId 的补充isOnZkSyncChainId()则简单直接比对block.chainid是否属于以下三个已知 zkSync 环境链 ID环境324zkSync 主网300zkSync Sepolia 测试网260zkSync 内存节点但源码注释明确写道链 ID 检查在 Foundry 本地工作中不可靠本地节点链 ID 可配置且foundry-zksync本地模式不会使用 zkSync 链 ID。所以统一的入口函数isZkSyncChain()采用双保险策略先查链 ID快、零开销→ 不匹配再查预编译行为准、环境无关。 上手指南一行继承即可跳过 zkSync 用例在实际项目中使用这套检测只需继承抽象合约并挂上修饰符import {ZkSyncChainChecker} from lib/foundry-devops/src/ZkSyncChainChecker.sol; contract MyContract is ZkSyncChainChecker { function testSomething() public skipZkSync { ... } // 在 zkSync 上自动跳过 }提供的两个修饰符覆盖双向场景skipZkSync在 zkSync 链上跳过该函数最常见的用途onlyZkSync只在 zkSync 链上执行。完整可用函数包括isZkSyncChain()、isOnZkSyncPrecompiles()、isOnZkSyncChainId()三个均可按需单独调用。✅ 测试验证同一套测试如何在两套 Foundry 中运行项目的测试矩阵设计也很值得参考见test/ZkSyncChainCheckerTest.t.sol与test/ZkSyncChainCheckerLocalTest.t.sol标准 Foundry 侧make test会 fork 以太坊主网与 zkSync 两条 RPC 分叉分别断言链 ID 检测的真假值。RPC 端点在foundry.toml的[rpc_endpoints]中通过环境变量MAINNET_RPC_URL/ZKSYNC_RPC_URL注入。foundry-zksync 侧make zktest实际执行foundryup-zksync forge test --zksync foundryup—— 安装 zkSync 版 Foundry、以--zksync标志跑测试、再切回官方版。本地环境下预编译检测应返回truetestIsOnZkSyncByPrecompiles_local用例。值得一提的是由于foundry-zksync的 fork 功能尚不完善基于 fork 的预编译用例在测试文件中被刻意注释保留待上游修复后启用——这种诚实标注已知限制的工程态度也值得借鉴。 附加彩蛋如何识别 foundry-zksync 本体光判断链还不够foundry-zksync本身也是另一个Foundry 变体。src/FoundryZkSyncChecker.sol用了一个意想不到的办法通过vm.ffi调用外部命令执行forge --version再比对版本字符串前缀forge 0.2.0/forge 0.3.0→ 标准 Foundryforge 0.0.2→ foundry-zksync。配合onlyFoundryZkSync/onlyVanillaFoundry两个修饰符甚至可以在同一测试文件里精确控制哪个 Foundry 版本跑哪些用例。test/FoundryZkSyncCheckerTest.t.sol还用test/is_foundry_zksync.sh这个 Shell 脚本做了交叉验证确保 Solidity 版检测结果与脚本版一致。注意使用该功能需在foundry.toml中开启ffi true。⚠️ 常见陷阱与限制使用这套方案前了解它的边界很重要预编译探测存在未来失效风险源码注释明确说明一旦 zkSync 未来补齐这些预编译合约isOnZkSyncPrecompiles将失去判断力。这是以行为差异做指纹方案的固有限制不能部署带检测器的合约foundry-zksync对 cheatcode 识别有兼容问题编译到 EraVM 后会困惑所以ZkSyncChainChecker设计为抽象合约只供测试/脚本继承不用于部署链 ID 检查不可单独依赖本地 Foundry 环境请始终走isZkSyncChain()的完整双保险路径。 总结检测方式函数优点局限链 ID 比对isOnZkSyncChainId零开销、快速Foundry 本地环境不可靠预编译行为探测isOnZkSyncPrecompiles环境无关、准确依赖 zkSync 暂不支持 4 个预编译Foundry 版本探测is_foundry_zksync区分两种工具链需要开启 FFIfoundry-devops 用4个预编译合约 3个链ID 版本指纹三件套把我在哪条链上运行这个困扰多链开发者的老问题变成了继承一个抽象合约就能解决的小事。如果你的项目同时面向以太坊和 zkSync 双链这套 [src/ZkSyncChainChecker.sol] 方案值得直接搬进你的测试工具箱。【免费下载链接】foundry-devops项目地址: https://gitcode.com/gh_mirrors/fo/foundry-devops创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考