1. 项目概述：为什么“Anvil完全指南”不是又一篇泛泛而谈的工具介绍

Anvil 是 Foundry 生态中那个你装完 Foundry 后默认就带上的命令行工具，但绝大多数人只用过anvil这个命令启动一个空链，然后就切去写测试了。直到某天——合约在本地跑通，一上 Sepolia 就 revert；Gas 估算本地稳如老狗，主网交易却频繁 out of gas；或者更糟：跨链调用逻辑在单链环境里根本暴露不出竞态问题。这时候才有人翻出 Anvil 的文档，发现它居然能分叉以太坊主网、快进时间、预充值任意地址、模拟多链并行状态……而这些能力，90% 的 Solidity 开发者从未系统用过。

我带过的几个模拟项目X团队，初期都卡在“本地测试和真实链行为不一致”这个坎上。有人花三天排查一个看似是合约 bug 的问题，最后发现只是本地时间戳没对齐；有人反复修改签名验证逻辑，结果上线后才发现主网分叉升级后 EIP-1559 的 base fee 计算方式变了，而本地链压根没启用。Anvil 的价值，从来不是“又一个本地链”，而是把主网的复杂性可控地搬进你的终端——它不模拟“区块链”，它模拟“正在运行的区块链”。

这篇指南不讲怎么安装 Foundry（官网三行命令的事），也不堆砌所有 CLI 参数（anvil --help比我写得全）。我要带你拆的是：

• 本地测试链：为什么anvil默认启动的链，连“重放交易”这个基本调试动作都做不到？真正可复现的本地链该怎么配？
• 分叉主网：不是简单--fork-url，而是如何让分叉链稳定扛住 200+ 并发请求？分叉后区块时间怎么调？历史状态怎么查？
• 多链并行调试：当你的前端要同时连接 Arbitrum 和 Base，合约要跨链验证 Merkle Proof，你怎么在一台机器上让两条链实时同步、互相通信、甚至共享同一个钱包状态？

这不是工具说明书，这是我在过去 18 个月里，用 Anvil 调试过 7 个跨链 DeFi 协议、3 个 NFT 铸造平台、2 个 DAO 投票系统后，把踩过的坑、抄来的参数、压测出的阈值、写死在脚本里的 hack 方案，全部摊开给你看。

2. 核心设计思路：Anvil 不是“轻量版 Ganache”，它是“主网镜像控制器”

2.1 为什么放弃 Ganache 和 Hardhat Network？

很多人问：既然有 Ganache，有 Hardhat Network，为什么还要学 Anvil？答案藏在三个底层设计差异里：

第一，状态快照机制完全不同。
Ganache 的evm_snapshot只保存内存状态，重启进程就丢；Hardhat Network 的快照依赖 Node.js 进程生命周期，无法跨终端共享。而 Anvil 的anvil snapshot命令会生成一个包含完整世界状态（账户余额、合约存储、交易日志）的二进制快照文件，你可以把它传给同事、存进 CI 流水线、甚至用anvil load-state在另一台机器上原样恢复。我上次帮某高校实验室复现一个共识漏洞，就是靠他们发来的一个 42MB 的.anvil-snapshot文件，本地anvil load-state后 12 秒内就复现了问题——这在 Ganache 里根本不可想象。

第二，分叉不是“拉取最新区块头”，而是“建立全状态镜像”。
anvil --fork-url https://eth.llamarpc.com启动后，Anvil 会向 RPC 节点发起eth_getBlockByNumber、eth_getStorageAt、eth_getCode等数十种请求，把指定区块号下所有合约字节码、所有账户存储槽、所有 EVM 状态变量，一股脑下载到本地内存。这意味着：

• 你可以在分叉链上直接eth_call调用 Uniswap V3 的getSqrtRatioAtTick，结果和主网上一模一样；
• 你能用cast storage查到某个 LP 仓位在区块 18,234,567 的精确 liquidity 值；
• 甚至可以anvil set-storage手动篡改某个合约的 storage，再观察下游影响——这在 Hardhat 分叉里需要额外 patch provider，而 Anvil 原生支持。

第三，多链并行不是“开多个终端”，而是“共享状态总线”。
Anvil 支持--ipc（Unix Domain Socket）和--http-host 0.0.0.0，这意味着你可以用anvil --port 8545 --fork-url mainnet启一个主网分叉，再用anvil --port 8546 --fork-url arbitrum启一个 Arbitrum 分叉，然后用cast send --rpc-url http://localhost:8545和cast send --rpc-url http://localhost:8546同时发交易。更关键的是，Anvil 提供anvil set-balance和anvil set-code的跨链批量操作接口，我写过一个 Python 脚本，能自动把同一套私钥在两条链上预充值 10 ETH、部署测试合约、设置初始存储，整个过程 3.2 秒完成。

提示：Anvil 的 IPC 模式比 HTTP 更快，尤其在高频eth_blockNumber轮询场景下，延迟能从 12ms 降到 1.8ms。如果你的前端用 wagmi 或 viem，记得在createConfig里把transport设为http('http://localhost:8545', { type: 'http' })，而不是默认的fallback。

2.2 本地测试链的三大致命误区

很多团队把 Anvil 当成“高级 Ganache”用，结果调试效率反而下降。以下是三个最常被忽略的配置陷阱：

误区一：“默认链 = 可调试链”
anvil命令不加任何参数启动，默认使用--block-base-fee-per-gas 0和--gas-price 0。这导致：

• 所有交易gasUsed都是 0，根本没法测真实 Gas 消耗；
• baseFeePerGas永远为 0，EIP-1559 逻辑完全失效；
• eth_estimateGas返回的值毫无参考意义。

正确做法：本地链必须模拟目标网络的 Fee Market 行为。比如调试 Sepolia，就该用：

anvil \ --block-base-fee-per-gas 1000000000 \ --gas-price 1000000000 \ --steps-tracing \ --block-time 15

其中--steps-tracing开启 EVM 步骤级追踪（用于cast debug），--block-time 15模拟 Sepolia 的平均出块时间。

误区二：“快照 = 备份”
anvil snapshot生成的文件默认存在/tmp/anvil-snapshots/，但这个目录在 macOS 上可能被系统自动清理。更糟的是，快照不包含 fork URL 和区块号信息——你下周打开快照，根本不知道它对应主网哪个时刻的状态。

正确做法：用带时间戳和网络标识的命名规范，并存入项目根目录：

# 启动分叉时记录区块号 BLOCK_NUM=$(curl -s -X POST --data '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}' https://eth.llamarpc.com | jq -r '.result') anvil --fork-url https://eth.llamarpc.com --fork-block-number $BLOCK_NUM --port 8545 & # 5 秒后创建快照（确保状态加载完成） sleep 5 anvil snapshot > ./anvil-snapshots/mainnet-$BLOCK_NUM-$(date +%Y%m%d-%H%M%S).json

误区三：“多链 = 多端口”
单纯开anvil --port 8545和anvil --port 8546，两条链之间完全隔离。但现实调试中，你经常需要：

• 在 Arbitrum 链上触发一个事件，然后立刻在 Base 链上查询该事件对应的 Merkle Root；
• 把同一笔 USDC 在两条链上做 Approve，验证跨链桥的授权逻辑。

正确做法：用 Anvil 的--host和--http-host绑定到127.0.0.1（而非默认的localhost），并配合cast的-r参数实现链间调用：

# 启动两条链，显式绑定 IP anvil --port 8545 --http-host 127.0.0.1 --fork-url https://arb-mainnet.g.alchemy.com/v2/xxx & anvil --port 8546 --http-host 127.0.0.1 --fork-url https://base-mainnet.g.alchemy.com/v2/yyy & # 在 Arbitrum 上发送交易，获取 tx hash TX_HASH=$(cast send --rpc-url http://127.0.0.1:8545 $ARB_CONTRACT "mint(address,uint256)" $ADDR 1000000000000000000) # 立刻在 Base 链上查询该 tx hash 对应的事件（需提前部署监听合约） cast call --rpc-url http://127.0.0.1:8546 $BASE_LISTENER "getMintEvent(string)" $TX_HASH

3. 实操详解：从零搭建可复现、可协作、可压测的 Anvil 调试环境

3.1 本地测试链：构建“可回滚的确定性沙盒”

真正的本地测试链，必须满足三个条件：确定性、可回滚、可观测。下面是一套经过 12 个团队验证的标准化启动脚本：

#!/bin/bash # anvil-local.sh —— 本地开发链启动脚本 set -e # 参数校验 if [ $# -ne 2 ]; then echo "Usage: $0 <network> <block_time_seconds>" echo "Example: $0 sepolia 15" exit 1 fi NETWORK=$1 BLOCK_TIME=$2 # 网络参数映射表 case $NETWORK in "mainnet") BASE_FEE="1000000000" GAS_PRICE="1000000000" FORK_URL="https://eth.llamarpc.com" ;; "sepolia") BASE_FEE="1000000000" GAS_PRICE="1000000000" FORK_URL="https://sepolia.infura.io/v3/YOUR_KEY" ;; "arbitrum") BASE_FEE="0" GAS_PRICE="1000000000" FORK_URL="https://arb-mainnet.g.alchemy.com/v2/YOUR_KEY" ;; *) echo "Unknown network: $NETWORK" exit 1 ;; esac # 启动 Anvil，带完整调试能力 anvil \ --block-base-fee-per-gas $BASE_FEE \ --gas-price $GAS_PRICE \ --block-time $BLOCK_TIME \ --steps-tracing \ --host 127.0.0.1 \ --port 8545 \ --fork-url $FORK_URL \ --fork-retry-backoff 250 \ --fork-block-number $(curl -s -X POST --data '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}' $FORK_URL | jq -r '.result') \ --silent \ --no-mining \ --prune-history 1000 \ --state ./anvil-state.json

关键参数解析：

• --fork-retry-backoff 250：当 RPC 请求失败时，等待 250ms 后重试，避免因瞬时网络抖动导致分叉失败；
• --prune-history 1000：只保留最近 1000 个区块的历史，防止内存爆炸（Anvil 默认无限缓存）；
• --state ./anvil-state.json：将当前链状态持久化到文件，关机重启后可用anvil --load-state ./anvil-state.json恢复；
• --no-mining：关闭自动挖矿，改为手动anvil mine控制出块节奏，这对调试时间敏感逻辑（如预言机更新）至关重要。

实操心得：

• 我们团队规定，所有 PR 必须附带anvil-local.sh sepolia 15启动后的快照文件（.anvil-snapshot），CI 流水线会用anvil load-state加载该快照，再运行测试。这样每个开发者看到的“本地环境”完全一致；
• --steps-tracing会显著增加内存占用（约 +40%），但它是cast debug的前提。我们只在需要深度调试时开启，日常开发用--no-steps-tracing；
• --silent不是关闭日志，而是过滤掉冗余的 “mining block” 日志，只保留tx sent、block mined、snapshot saved等关键事件，日志体积减少 70%。

3.2 分叉主网：打造“低延迟、高保真”的生产环境镜像

分叉主网不是“拉一条链过来”，而是构建一个可交互、可干预、可验证的镜像系统。以下是分叉链的黄金配置组合：

# anvil-fork.sh —— 主网分叉启动脚本 set -e # 获取最新区块号（带重试） get_latest_block() { for i in {1..3}; do BLOCK=$(curl -s -X POST --data '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}' $RPC_URL | jq -r '.result' 2>/dev/null) if [ "$BLOCK" != "null" ] && [ -n "$BLOCK" ]; then echo $BLOCK return fi sleep 1 done echo "Failed to get block number after 3 retries" >&2 exit 1 } RPC_URL="https://eth.llamarpc.com" LATEST_BLOCK=$(get_latest_block) FORK_BLOCK=$((LATEST_BLOCK - 10)) # 回退 10 个区块，避开未确认交易 anvil \ --fork-url $RPC_URL \ --fork-block-number $FORK_BLOCK \ --port 8545 \ --host 127.0.0.1 \ --block-base-fee-per-gas 1000000000 \ --gas-price 1000000000 \ --block-time 12 \ --prune-history 500 \ --state ./fork-mainnet-$FORK_BLOCK.json \ --fork-retry-backoff 100 \ --fork-jitter 500 \ --no-mining

为什么回退 10 个区块？
主网最新区块（latest）包含未确认交易，分叉后这些交易状态不稳定。回退 10 个区块（约 2 分钟）能确保所有交易已获得 12+ 个确认，状态绝对确定。我们实测过：在latest分叉，cast call有 3.7% 概率返回reverted；在latest-10分叉，错误率为 0。

--fork-jitter 500的妙用：
这个参数会让 Anvil 在每次 fork 请求时，随机增加 0~500ms 的延迟。乍看是“制造混乱”，实则是为了暴露竞态问题。比如你的前端在页面加载时并发调用eth_getBalance和eth_getTransactionCount，在无 jitter 的分叉链上永远返回一致结果；但在有 jitter 的链上，你就能复现“balance 已更新但 nonce 未更新”的经典 race condition。

分叉链的三大必做验证：

1. 状态一致性验证：

   # 对比主网和分叉链的同一地址余额 MAINNET_BAL=$(curl -s -X POST --data '{"jsonrpc":"2.0","method":"eth_getBalance","params":["0xAb5801a7D398351b8bE11C439e05C5B3259aeC9B","0x'"$(printf "%x" $FORK_BLOCK)"'"],"id":1}' $RPC_URL | jq -r '.result') FORK_BAL=$(cast balance --rpc-url http://127.0.0.1:8545 0xAb5801a7D398351b8bE11C439e05C5B3259aeC9B) echo "Mainnet: $MAINNET_BAL | Fork: $FORK_BAL | Match: $(if [ "$MAINNET_BAL" = "$FORK_BAL" ]; then echo "YES"; else echo "NO"; fi)"

2. 合约代码验证：

   # 验证 Uniswap V3 Factory 字节码是否一致 MAINNET_CODE=$(curl -s -X POST --data '{"jsonrpc":"2.0","method":"eth_getCode","params":["0x1F98431c8aD98523631AE4a59f267346ea31F984","0x'"$(printf "%x" $FORK_BLOCK)"'"],"id":1}' $RPC_URL | jq -r '.result') FORK_CODE=$(cast code --rpc-url http://127.0.0.1:8545 0x1F98431c8aD98523631AE4a59f267346ea31F984) echo "Code match: $(sha256sum <<< "$MAINNET_CODE" | cut -d' ' -f1) == $(sha256sum <<< "$FORK_CODE" | cut -d' ' -f1)"

3. 存储槽验证：

   # 查询 WETH 合约的 totalSupply 存储槽（slot 0） MAINNET_SUPPLY=$(curl -s -X POST --data '{"jsonrpc":"2.0","method":"eth_getStorageAt","params":["0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2","0x0","0x'"$(printf "%x" $FORK_BLOCK)"'"],"id":1}' $RPC_URL | jq -r '.result') FORK_SUPPLY=$(cast storage --rpc-url http://127.0.0.1:8545 0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2 0) echo "Supply: $(cast to-dec $MAINNET_SUPPLY) == $(cast to-dec $FORK_SUPPLY)"

注意：cast storage默认查当前链状态，要查历史存储必须用cast storage --block <block_num>。而分叉链的--fork-block-number只影响初始状态，后续eth_call仍以最新区块为准。所以验证时务必用--block指定同一区块号。

3.3 多链并行调试：用 Anvil 构建“跨链事务协调器”

当你的应用涉及 Arbitrum、Base、Optimism 三条链时，手动管理三个终端、三套私钥、三组 RPC URL 是灾难。Anvil 的多链调试核心在于：状态同步 + 事务编排 + 日志聚合。

第一步：统一密钥管理
我们不用anvil accounts生成的随机地址，而是用cast wallet new创建一套标准助记词，并导出所有链的地址：

# 生成助记词并保存 cast wallet new --mnemonic-passphrase "" > .wallet-mnemonic.txt # 导出各链地址（相同私钥，不同路径） ARBITRUM_ADDR=$(cast wallet address --mnemonic ".wallet-mnemonic.txt" --mnemonic-index 0 --derivation-path "m/44'/60'/0'/0/0" --rpc-url https://arb-mainnet.g.alchemy.com/v2/xxx) BASE_ADDR=$(cast wallet address --mnemonic ".wallet-mnemonic.txt" --mnemonic-index 0 --derivation-path "m/44'/60'/0'/0/0" --rpc-url https://base-mainnet.g.alchemy.com/v2/yyy) echo "Arbitrum: $ARBITRUM_ADDR" >> .wallet-addresses.txt echo "Base: $BASE_ADDR" >> .wallet-addresses.txt

第二步：并行启动多链

# 启动 Arbitrum 分叉 anvil \ --port 8545 \ --http-host 127.0.0.1 \ --fork-url https://arb-mainnet.g.alchemy.com/v2/xxx \ --fork-block-number $(curl -s -X POST --data '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}' https://arb-mainnet.g.alchemy.com/v2/xxx | jq -r '.result') \ --block-time 1 \ --prune-history 200 \ --state ./arb-fork.json & # 启动 Base 分叉 anvil \ --port 8546 \ --http-host 127.0.0.1 \ --fork-url https://base-mainnet.g.alchemy.com/v2/yyy \ --fork-block-number $(curl -s -X POST --data '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}' https://base-mainnet.g.alchemy.com/v2/yyy | jq -r '.result') \ --block-time 2 \ --prune-history 200 \ --state ./base-fork.json & # 启动 Optimism 分叉 anvil \ --port 8547 \ --http-host 127.0.0.1 \ --fork-url https://optimism-mainnet.g.alchemy.com/v2/zzz \ --fork-block-number $(curl -s -X POST --data '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}' https://optimism-mainnet.g.alchemy.com/v2/zzz | jq -r '.result') \ --block-time 2 \ --prune-history 200 \ --state ./op-fork.json &

第三步：编写跨链事务脚本
以下是一个典型的跨链资产桥接调试脚本（简化版）：

# crosschain-debug.py import subprocess import json import time def cast_send(chain_port, to, sig, args): cmd = f"cast send --rpc-url http://127.0.0.1:{chain_port} {to} '{sig}' {args} --private-key .wallet-key" result = subprocess.run(cmd, shell=True, capture_output=True, text=True) if result.returncode != 0: raise Exception(f"Send failed on port {chain_port}: {result.stderr}") return json.loads(result.stdout)['hash'] def cast_call(chain_port, to, sig, args): cmd = f"cast call --rpc-url http://127.0.0.1:{chain_port} {to} '{sig}' {args}" result = subprocess.run(cmd, shell=True, capture_output=True, text=True) return result.stdout.strip() # 1. 在 Arbitrum 上 Approve 桥接合约 arb_approve_tx = cast_send(8545, "0xArbBridge", "approve(address,uint256)", "0xArbBridge 1000000000000000000") # 2. 等待 Arb 确认（模拟桥接延迟） time.sleep(3) # 3. 在 Base 上检查桥接状态 bridge_status = cast_call(8546, "0xBaseBridge", "isDeposited(bytes32)", "0x" + arb_approve_tx[2:]) print(f"Arb TX: {arb_approve_tx}") print(f"Base status: {bridge_status}")

第四步：日志聚合与时间线对齐
Anvil 默认日志是分散的，我们用multilog工具统一收集：

# 安装 multilog（macOS） brew install multilog # 启动多链并聚合日志 multilog \ --name arb --cmd "anvil --port 8545 --fork-url ..." \ --name base --cmd "anvil --port 8546 --fork-url ..." \ --name op --cmd "anvil --port 8547 --fork-url ..." \ --format "[$NAME] $LINE" \ --output ./anvil-logs/

日志文件./anvil-logs/all.log会按[arb] tx sent ...、[base] block mined ...格式输出，用grep -E "(arb|base|op).*tx sent"就能快速定位跨链事务时间线。

4. 常见问题与实战排障：那些文档里不会写的硬核技巧

4.1 分叉失败的五大原因及速查表

独家技巧：用cast rpc直接调试分叉状态
当分叉链行为异常时，别急着重启，先用cast rpc检查底层状态：

# 查看分叉链当前区块的 baseFee cast rpc eth_getBlockByNumber latest | jq '.result.baseFeePerGas' # 查看某地址在分叉链上的 nonce cast rpc eth_getTransactionCount '"0xAb5801a7D398351b8bE11C439e05C5B3259aeC9B"' '"latest"' | jq '.result' # 查看分叉链的 chainId cast rpc eth_chainId | jq '.result'

这些命令比anvil --help更快定位问题根源。

4.2 多链调试中的“幽灵状态”问题

现象：你在 Arbitrum 链上cast send了一笔交易，cast receipt显示成功，但用cast balance查目标地址余额没变。

根本原因：Anvil 的--no-mining模式下，交易进入内存池但不自动打包。你看到的 “success” 只是交易被接受，不是执行完成。

解决方案：

• 方案一（推荐）：手动触发出块anvil mine，或anvil mine --blocks 1；
• 方案二：启动时去掉--no-mining，让 Anvil 自动挖矿（适合长时间调试）；
• 方案三：用cast send --legacy强制使用 Legacy Transaction，避免 EIP-1559 的 baseFee 计算干扰。

验证方法：

# 发送交易后，立即查 pending 状态 cast rpc eth_getBlockByNumber pending | jq '.result.transactions | length' # 查看最新区块号，确认是否已打包 cast rpc eth_blockNumber | jq '.result'

4.3 本地链 Gas 消耗与主网偏差超 20% 的调优指南

我们统计了 37 个主流 DeFi 合约的 Gas 消耗，发现本地链与主网偏差主要来自三处：

偏差源一：EVM 版本不一致
主网已升级到 Shanghai（EIP-3855），但 Anvil 默认用 Paris。解决：

anvil --hardfork shanghai

偏差源二：预编译合约优化差异
主网客户端（如 Erigon）对ecrecover、keccak256有硬件加速，Anvil 是纯软件实现。解决：

• 不追求 100% 一致，关注相对变化（如函数 A 比函数 B 多消耗 30% Gas，在本地和主网应一致）；
• 用cast debug查看每步 EVM 操作的 gasCost，定位具体哪条指令偏差大。

偏差源三：存储冷热状态
主网合约存储槽多数是“warm”（已访问过），本地分叉链首次访问是“cold”，多消耗 2100 gas。解决：

# 在分叉后，预先 warm 所有关键存储槽 cast storage --rpc-url http://127.0.0.1:8545 $CONTRACT_ADDR 0 cast storage --rpc-url http://127.0.0.1:8545 $CONTRACT_ADDR 1 cast storage --rpc-url http://127.0.0.1:8545 $CONTRACT_ADDR 2

4.4 Anvil 内存泄漏的终极修复法

长期运行的 Anvil 进程（尤其分叉链）会出现内存缓慢增长，48 小时后可能吃光 16GB 内存。官方 issue #1243 承认此问题，但未修复。我们的临时方案：

步骤一：监控内存

# 每 5 分钟检查一次 while true; do MEM=$(ps aux | grep anvil | grep -v grep | awk '{print $6}' | sort -nr | head -1) if [ "$MEM" -gt 8000000 ]; then # 8GB echo "$(date): Anvil memory > 8GB, restarting..." pkill -f "anvil.*fork-url" sleep 2 ./anvil-fork.sh & fi sleep 300 done

步骤二：限制进程内存

# Linux 下用 systemd-run 限制内存 systemd-run --scope -p MemoryLimit=6G -- anvil --fork-url ...

步骤三：定期 dump 状态并重启

# 每 2 小时保存状态并重启 while true; do anvil snapshot > ./auto-snapshot-$(date +%s).json pkill -f "anvil.*fork-url" sleep 5 ./anvil-fork.sh & sleep 7200 done

5. 进阶实践：把 Anvil 变成你的“链上实验沙盒”

5.1 模拟主网分叉升级：EIP-4844 的本地验证

以太坊坎昆升级引入 EIP-4844（Proto-Danksharding），要验证你的合约是否兼容，不能等主网升级。Anvil 支持--hardfork canyon（Optimism）和--hardfork prague（即将支持），但 EIP-4844 需要手动注入：

# 启动支持 Blob Transactions 的 Anvil（需 Foundry nightly） anvil \ --hardfork prague \ --fork-url https://ethereum-sepolia-rpc.publicnode.com \ --fork-block-number 4200000 \ --port 8545 \ --blob-store ./blobs/ # 发送 Blob Transaction（需 cast >= 0.2.20） cast send \ --rpc-url http://127.0.0.1:8545 \ --blob "0x01020304" \ --blob-versioned-hash "0x..." \ $TO_ADDR

验证要点：

• 检查eth_getBlockByNumber返回的blobGasUsed字段是否非零；
• 用cast blob命令读取存储的 blob 数据；
• 验证合约能否通过BLOBHASH操作码访问 blob hash。

5.2 构建“时间机器”：回溯任意历史区块状态

Anvil 本身不支持eth_getStorageAt查询任意历史区块，但我们可以用 `--fork-block-number