先区分接口规则与链上事实
研究区块链查询机制时，第一步是区分“接口如何工作”和“链上实际记录了什么”。以太坊 JSON-RPC 为应用访问节点提供统一的方法规范，应用可以通过节点读取区块、账户状态、交易和合约执行结果。接口文档能够证明方法名称、参数格式、返回类型和区块参数含义，但它本身不能证明某个具体地址、交易或区块当前返回了什么。具体结果必须由可识别的节点、网络和查询时间共同支撑。
比特币的 gettxoutproof 则用于返回交易被纳入区块的序列化证明。它说明了证明的输入包括交易哈希列表，也可以选择区块哈希限定查询范围，输出是十六进制编码的证明数据。由此可以核验接口用途和适用前提，但是否成功生成证明，还取决于节点是否具备相应交易索引、交易是否确实位于指定区块，以及输入是否完整。
核验以太坊查询证据的关键项目
以太坊查询结果首先要记录网络、节点客户端、请求方法、参数、请求标识和原始响应。查询账户余额、合约代码、存储或 eth_call 时，区块参数会决定读取哪个高度或状态视图。latest、safe、finalized、pending 与明确的十六进制区块号具有不同语义，因此研究报告不能只写“查询结果”，还应写明使用的区块标识。
参数编码也需要单独检查。数量通常使用带 0x 前缀的紧凑十六进制表示，零写作 0x0；字节数组、地址、哈希和字节码则使用每字节两位十六进制字符。前导零、奇数位数据或缺少前缀，都可能导致请求无效或被错误解释。核验时应保存原始请求，并将十六进制值转换为人类可读形式后再次比对。
同一方法在不同执行客户端上的支持情况和扩展字段可能存在差异。像 eth_syncing 这类同步状态查询，节点可能返回布尔值，也可能返回包含同步进度的对象。研究者应核对具体客户端文档，并通过另一节点或另一客户端复查关键结论。单个节点报告的连接数、同步状态或最新区块高度，不能直接当作整个网络的统一状态。
核验比特币证明查询的适用条件
gettxoutproof 的证据核验重点在于证明对象和节点条件。输入交易哈希应与目标交易完全匹配；如果提供区块哈希，节点应在该区块范围内查找交易。返回的十六进制字符串只是序列化证明，不能仅凭字符串外观判断交易已经被确认，仍需使用支持该证明格式的工具或节点接口进行解析和验证。
该方法的可用性还受交易索引影响。材料说明，在默认情况下，节点有时只有在该交易仍有未花费输出时才能处理证明；启用交易索引，或手动提供交易所在区块哈希，可以改变可查询条件。因此，查询失败不能直接证明交易未上链。核验记录应包含节点配置、是否使用交易索引、是否提供区块哈希以及错误信息。
一套可复现的证据核验流程
可以按以下顺序整理研究证据：先确定问题是接口规范、状态读取、历史记录还是包含证明；再固定网络和查询目标；随后记录完整请求、参数编码、区块标识、节点客户端和返回时间；接着对结果进行格式验证和语义验证；最后使用独立节点、不同客户端或可解析证明进行交叉复核。
交叉复核时，应区分预期差异与异常差异。不同节点的最新状态可能因同步进度或区块头变化而不同，但在固定区块号、交易哈希和网络后，历史数据通常应能对应起来。若结果不一致，应检查网络是否相同、节点是否同步完成、查询是否使用 pending 状态、客户端是否支持该方法，以及是否存在索引或归档数据要求。
研究报告最好同时保留原始响应和解释后的结论。原始响应用于追溯，解释文字用于说明字段含义，复核记录用于证明结果不是单次偶然读取。对于不能由接口文档单独证明的内容，应明确写成“需要通过节点返回结果验证”，避免把规范中的示例或方法说明写成具体链上事实。
常见问题
问题一：接口文档写明某方法存在，是否就能证明节点一定支持？不能。规范说明方法的设计和语义，具体客户端或节点服务可能存在支持范围差异，应查询该实现的文档并实际发送请求。
问题二：查询返回错误，是否代表数据不存在？不能直接这样判断。错误可能来自参数编码、网络选择、节点同步状态、索引配置、区块数据保留范围或方法权限。应先记录错误内容，再逐项排除。
问题三：一个节点返回的最新区块能否作为全网事实？只能作为该节点视角下的结果。涉及研究结论时，应记录节点和区块标识，并对关键数据进行独立复核。
问题四：证明字符串是否等于交易确认？不等于。证明需要被正确解析，并与交易哈希、区块信息及验证规则相匹配；确认深度等其他判断也需要单独定义和核验。