节点与RPC接口
读取区块链数据通常从节点接口开始。应用提交查询方法和参数，节点返回结果。RPC是远程过程调用，JSON-RPC用JSON表达请求与响应；它规定消息形式，具体能查询什么则由链和客户端的接口决定。
以太坊开发文档介绍了执行客户端的JSON-RPC接口，覆盖余额、合约状态及区块等查询；共识相关信息另有接口。开发库可以封装请求，但理解底层方法仍有助于判断返回结果的含义。
区块高度、哈希与查询范围
区块高度描述区块在链上的位置，区块哈希用于标识具体区块。阅读查询结果时，需要区分“查询哪个位置”和“查询哪个区块”：位置与身份承担不同作用，不能把二者混为一谈。
以太坊部分状态查询接受区块参数，可指定高度或使用latest、safe、finalized、pending等标签。它们表达不同的状态范围，尤其不能把待处理状态直接解释为已最终确定的结果。
状态数据与历史记录
状态查询回答某个时点的余额、代码或存储是什么；历史查询回答区块包含哪些交易、交易执行留下什么记录。查询前应先明确问题属于哪一类，避免用交易列表代替状态结果。
例如，核对某个区块包含的交易与核对某个区块时点的账户余额，是两项不同任务。两者可以相互辅助，但返回字段和解释方式不同。涉及多次查询时，还应关注它们是否采用一致的区块范围。
编码与返回详细程度
十六进制既可表达数量，也可表达字节数据。以太坊接口对两者采用不同格式规则：数量使用紧凑表示，字节数据按每字节两位表示。因此，解析时应依据字段类型，不能统一按普通整数处理。
比特币开发参考中的getblock通过区块哈希查询区块。文档列出的verbosity参数可选择序列化十六进制数据、包含交易标识的区块对象，或包含交易详情的对象；返回字段还涉及高度、确认数和前一区块哈希。
适用条件与常见问题
返回十六进制字符串是否意味着没有查到数据？不一定，它可能就是接口要求的序列化结果。交易字段是否总包含完整交易？也不一定，应先检查返回详细程度，再决定如何解析。
这些例子分别适用于对应的以太坊与比特币接口，方法名、参数和字段不能直接跨链套用。实际解释结果时，需要同时核对客户端支持情况、查询范围和返回类型；接口成功响应只是起点，字段语义才决定数据能回答什么问题。