先分清“当前状态”和“历史记录”
区块链上的记录通常按区块组织，交易则包含在区块中。查询某个账户余额或合约数据，得到的是指定区块对应的状态；查询区块和交易，得到的才是形成这些状态变化的历史记录。只看最新余额，不能直接知道它过去经历了哪些更新。
实际查询前，先确认要查的是哪条链、使用哪个节点或服务，以及手头有什么标识：区块高度、区块哈希、交易哈希，还是账户或合约地址。JSON-RPC 是以 JSON 请求与节点交互的一种常见接口，但各客户端和服务支持的方法可能不同。
以太坊：从区块定位到交易
可先用 eth_blockNumber 获取节点当前报告的区块高度，再通过 eth_getBlockByNumber 或 eth_getBlockByHash 查看区块信息。区块中包含交易标识；拿到交易哈希后，可继续用 eth_getTransactionByHash 查询交易，并用 eth_getTransactionReceipt 查询交易回执。
如果关注的是某个区块时点的账户或合约状态，可查询 eth_getBalance、eth_getCode、eth_getStorageAt 等状态方法，并指定区块参数。使用明确的区块高度有助于复查同一时点；使用 latest 则表示查询节点所见的最新区块状态。接口还定义了 safe、finalized 等区块标记，适合在需要关注确认程度时了解并选择，但它们代表的区块位置不同。
因此，追踪一项更新时，可先确定相关区块，再查看其中交易及回执；如需比较变化前后的状态，则分别查询相邻或指定区块的状态。仅调用状态查询方法，不一定会自动返回完整的变更时间线。
比特币：按区块哈希读取
比特币的 getblock 方法以区块哈希作为必需参数。verbosity 参数控制返回内容：0 返回序列化的十六进制数据，1 返回区块信息及交易标识，2 还会包含交易的详细对象。若目的是查看某区块中有哪些交易，通常应选择能返回 JSON 信息的形式，再依据交易标识继续查交易详情。
区块信息可用于核对高度、哈希、时间、交易数量，以及前后区块关联等字段。返回信息中的 confirmations 表示确认数；资料说明，若区块不在主链上，该字段可能为 -1。遇到该值时，应进一步核对区块是否属于当前主链，而不要把它当作普通确认数量解读。
查询时的核对方法与常见限制
查询结果最好同时记录网络名称、区块高度或哈希、交易哈希及接口返回状态。高度便于定位顺序，哈希便于精确标识对象；如果服务返回的信息与预期不符，可换用区块哈希复查，并确认请求确实发往目标网络。
常见误区是把“最新状态”当成全部历史，或把区块里的交易列表直接等同于业务层面的更新说明。底层 RPC 展示的是区块、交易、回执或指定区块状态；要解释某笔交易具体改变了什么，还需结合相应应用的数据定义。可查询的历史范围、方法支持情况也取决于所用节点或服务。
简要流程是：确认链和节点，取得区块或交易标识，读取区块与交易记录，再按指定区块核对状态，并留意确认或最终性信息。这样可以区分“某时点现在是什么”与“它如何一步步更新”。