先把报告结论拆成可检验的问题
区块链运行报告的研究证据怎么核验，关键在于能否从结论追溯到原始记录。例如，“节点同步正常”与“全网运行稳定”范围不同，后者需要更广的观测支持。核验时应明确研究对象、观察时段、指标定义和计算方法，判断数据究竟覆盖了哪一层结论。
接口文档能支持什么
以太坊开发者文档说明，JSON-RPC可用于读取节点数据；状态查询的区块参数决定查询位置，eth_syncing返回同步信息或false。该页面主要涉及执行客户端，共识客户端另有接口。因此，核验时需要区分执行层状态与共识相关证据。
比特币开发者文档中的getblockchaininfo提供节点链处理状态，包括已验证区块高度、最佳区块哈希、验证进度估计及裁剪状态。这些字段可辅助检查节点数据条件，但验证进度估计不能直接充当全网健康程度指标。
固定数据位置，保留复核路径
证据记录应包含网络、客户端版本、接口方法、请求参数、采样时间及原始返回值。涉及区块的数据，应保留高度和哈希；涉及统计结果，还应说明样本范围、异常值处理与计算规则，让复核者能够追踪结果如何产生。
以太坊的latest、safe、finalized和pending具有不同语义，不能混为同一统计口径。动态标签对应的位置会变化，报告应保留实际对应的区块信息。跨时间比较时，也应检查查询位置和观察窗口是否一致。
交叉核对需要独立且可比
独立节点或不同数据提供方的结果可以用于交叉核对，但应先统一网络、区块位置和字段含义。同一后端生成的多个页面，不能仅凭展示形式不同就算作独立证据。结果不一致时，应先检查采样时点、同步状态及接口支持差异。
两份接口文档分别解释两条链的数据含义，并不构成对某份运行报告结论的双重实测验证。文档证明字段如何解释，观测记录才支持相应时段的具体判断。
适用条件与常见问题
这套方法适用于以节点接口数据为依据的运行报告。核验历史结论前，应确认数据源具备所需历史数据；比特币节点开启裁剪时，不能默认其仍保存全部历史区块。
同步接口返回false，能否证明全网正常？不能，它只描述该节点的同步状态。只有图表能否复核研究结论？图表还需配套原始记录和计算口径。若报告缺少这些内容，应明确其证据不足以支持哪些判断，而不是据此推断网络发生故障。