eth_call如何查询历史状态？

eth_call会让节点在指定状态上执行一条消息调用并返回结果，但不会广播交易，也不会持久化写入。它既能查询view函数，也能模拟会修改状态的函数；“只读”描述的是执行结果不落链，不代表EVM只允许读操作。

同一调用，换一个区块就可能换答案

请求对象常含from、to、data、value、gas和费用字段，另加一个区块参数。余额、allowance、池价格、代理实现和权限都会随区块变化，因此参数相同但blockTag不同，返回值或revert原因都可能不同。

blockTag	适合用途	主要边界
latest	当前已知链头查询	可能受短重组影响
safe / finalized	需要更强稳定性的读取	比latest更滞后
pending	模拟节点待处理状态	各客户端和节点池差异较大
固定区块号/哈希	复现历史结果	节点需保存对应状态

历史调用为何会报missing trie node

执行旧区块eth_call需要该区块的账户与存储状态。普通节点可能已经裁剪历史状态，只保留足够同步和验证的数据；区块与回执仍可查询，不代表任意旧状态都可执行。此时应使用归档节点，或在较近的可用区块重试并明确标注限制，不能把节点缺数据解释成合约revert。

from和value不能随便省略

不少合约依据msg.sender判断权限，或根据msg.value选择分支。省略from时节点会使用默认零地址或实现约定，模拟结果可能与真实钱包发送不同。余额不足、allowance不足、nonce相关条件也可能改变路径。要预演真实交易，应复制最终发送的from、to、value与data，并给出合理gas上限。

pending结果只是一个节点的假设

pending状态可能包含节点本地内存池交易，公共RPC还可能禁用或重新定义它。即使模拟成功，真正上链前也会有其他交易改变状态；反之，pending模拟失败的交易在状态更新后可能成功。产品应把pending标为预估，不用于生成永久审计结论。

可复现记录需要哪些字段

保存chainId、RPC客户端或服务商、区块号与区块哈希、完整call对象、返回原文和合约代码哈希。代理合约还要保存当时implementation。若使用state override，应单独记录覆盖内容，因为那是人为构造的状态，不是链上事实。

block参数决定你查到哪一份状态

eth_call的第二个参数可以是latest、safe、finalized、具体区块号，或支持EIP-1898的区块哈希对象。复盘历史余额时应固定区块号或哈希；使用latest会让同一请求随新区块产生不同结果。若节点已裁剪旧状态，历史调用可能返回missing trie node之类错误，此时需要archive节点，而不是重复请求普通RPC。

还要区分“在某区块执行之后的状态”与交易执行前状态。JSON-RPC按所给区块的最终状态模拟调用；要还原区块内某笔交易之前的精确状态，通常需要trace/replay能力或在前一区块基础上重放交易。

固定区块标签的稳定性可参考latest、safe与finalized，代理实现读取见ERC-1967槽位；如果返回revert data，继续按自定义错误解码处理。