先把研究结论拆成可检查的问题
区块链的查询机制的研究证据怎么核验，首先取决于要证明什么。接口是否提供某项功能、节点在某个区块返回什么数据、某笔交易是否被收入区块，是不同的问题。接口文档可以支持功能与参数说明；一次响应只能记录该次查询结果；包含证明则用于核验特定的包含关系。三者不能互相替代。
两个来源分别支持什么
以太坊开发者文档的 JSON-RPC 页面说明，应用通过节点接口读取数据；状态查询中的区块参数决定查询上下文，数值与字节数据采用不同的十六进制编码规则。该页面主要讨论执行客户端接口。来源：https://ethereum.org/developers/docs/apis/json-rpc/
比特币开发者参考文档说明，gettxoutproof 返回交易被包含在区块中的十六进制编码证明。能否找到目标交易受查询条件影响，文档列出了未花费输出、交易索引及指定区块哈希等相关条件。来源：https://developer.bitcoin.org/reference/rpc/gettxoutproof.html
这两个来源涉及不同系统，可分别支持对应接口的说明，但不能彼此证明实现正确，也不能据此推断所有区块链具有相同的查询能力。
让查询结果具备复核条件
研究记录应保留网络、客户端版本、接口方法、完整参数、原始响应及错误信息。涉及状态时，还应记录区块高度与对应哈希，使复核者能够判断两次查询是否针对同一链上位置。只保存界面截图或转换后的数值，会丢失检查编码和参数所需的上下文。
采用 latest 或 pending 等标签时，查询上下文可能随时间变化，因此重复请求得到不同结果，不能直接认定接口错误。固定区块上下文后再比较结果，更适合检查可重复性；比较不同节点时，也应先排除查询位置不同的情况。
证明的适用条件与结论边界
获得包含证明后，还需要验证证明与目标交易、目标区块之间的对应关系，并核验该区块在所接受链上的位置。仅有一串证明数据，尚不足以完成核验。
交易被包含在某个区块中，与交易输出目前是否未花费，是不同命题。研究结论应停留在证据能够支持的范围内。历史查询失败时，也应先检查定位条件、索引和数据可用性，不能直接把失败解释为交易从未存在。
常见问题如何判断
多个节点返回一致，是否就等于密码学证明？一致性可以作为交叉检查结果，但它本身没有完成证明验证。文档示例能否作为实测记录？示例用于解释接口，不能替代实际请求与响应。若研究声称查询更快或更可靠，还需要另行提供测试条件与观测记录；上述接口说明本身不支持性能结论。