先明确证据需要证明什么
区块链运行报告的研究证据怎么核验，首先取决于报告提出了什么结论。“节点正在同步”“某区块包含哪些交易”“全网运行稳定”需要不同范围的证据。核验时，应把每项结论对应到原始记录、采集时间、网络、节点及统计方法，判断证据是否足以覆盖结论。
接口文档可以解释字段含义，却不能证明某次实际运行结果。报告仍需提供对应的观测记录，让读者能够区分接口定义、采集事实与研究者的解释。
用两类接口文档校准字段含义
以太坊开发者文档的 JSON-RPC API 说明，应用可通过节点接口读取链上数据；状态查询的区块参数决定查询位置，支持具体高度及 latest、safe、finalized 等标签。eth_syncing 返回同步信息或 false，具体字段可能因客户端而异。这些定义可用于检查报告是否交代查询位置和客户端条件。
比特币开发者参考文档的 getblockchaininfo 说明，该接口返回节点的链处理状态，包括已完整验证链的高度、已验证区块头数量、最佳区块哈希、验证进度估计及裁剪状态。核验时应分别理解这些字段，尤其不能把进度估计当作完整性证明。
两个来源分别解释不同网络的接口，可共同支撑核验方法，但不能互相证明某次以太坊或比特币观测正确。
固定查询条件，保留复核路径
可复核的报告应记录接口方法、参数、原始返回、采集时间和客户端版本，并明确网络身份。对于历史状态研究，还应记录目标区块高度与哈希，避免仅以不断变化的 latest 作为复查依据。
数值处理也需要可追溯。以太坊接口中的数量采用十六进制编码，报告转为十进制或进一步计算时，应保留转换规则。统计结果还应说明样本区间、缺失记录及计算方法，使读者能从原始值复算结论。
适用条件与常见问题
这套方法适用于以节点接口数据为依据的运行状态与历史记录研究。节点裁剪、接口支持差异或历史数据不可用，都可能限制复核范围；查询失败应记录原因，不能直接解释为链上没有对应数据。
同步状态正常，能否证明全网正常？单个节点的返回只覆盖其观测范围。涉及全网的判断，还需要更广的观测和明确的评价指标。
多个接口返回一致，是否足够？还需检查是否来自同一上游，以及是否查询同一网络、同一区块。出现差异时，应先排查采集时点、同步进度和参数，再判断报告结论是否成立。