核验对象与适用范围
区块链小数据的资料来源如何核验，可以从一笔交易、一个区块或某个账户状态入手。这里的“小数据”指数量有限、能够逐项检查的记录。核验重点是说明数据来自哪里、对应哪个网络与区块，以及字段怎样解释。以下方法适用于链上记录及其接口查询结果；涉及现实身份或链外事件时，还需要其他证据。
先区分接口依据与记录证据
以太坊 JSON-RPC 文档说明，应用通过节点读取区块链数据，状态查询的区块参数决定查询位置，数量与字节数据采用不同的十六进制编码规则。出处为 https://ethereum.org/developers/docs/apis/json-rpc/ 。
Bitcoin 开发者参考中的 getblock 文档说明，同一区块可按 verbosity 返回序列化数据、区块信息或包含交易详情的信息，返回字段包括区块哈希、高度和确认数。出处为 https://developer.bitcoin.org/reference/rpc/getblock.html 。
这两个独立文档分别解释不同链的接口，不能互相证明某条记录真实。文档用于核对方法和字段含义，具体记录还需要对应的节点查询结果。
建立可重复的核验记录
一份便于复核的记录应保留网络、节点来源、查询时间、方法、参数和原始返回值，并标明引用的字段。区块数据应同时记录高度与哈希，交易数据应保留交易标识；仅有截图或转述，通常不足以还原查询条件。
对以太坊状态数据，使用 latest 或 pending 会让结果随查询时点变化。需要复现时，应明确具体区块并核对其哈希，同时记录安全或最终确定状态的查询口径。对 Bitcoin 区块，应注明 verbosity，避免把交易标识列表误当成交易详情。
交叉复核的条件与局限
比较不同节点或服务的结果时，需要保持网络、查询对象和参数一致。否则，差异可能来自查询时点或返回层级，而非数据错误。不同网站也可能共用同一数据服务，因此页面数量不能直接代表证据的独立程度。
交叉结果一致可以增加可信度，但不等于完成全部验证。还应检查字段转换是否正确，例如十六进制数量的解读；保留原始值与转换说明，能帮助定位抄录或解析错误。
常见问题如何判断
为什么区块高度相同仍要核对哈希？高度表示位置，哈希标识具体区块，两者一起保留更便于确认查询对象。为什么有确认数字段仍需解释？Bitcoin getblock 文档中，确认数为负一表示该区块不在主链，不能只凭接口返回了区块信息就认定其处于主链。
为什么文档示例不能作为实际数据引用？示例用于说明接口格式。文章中的具体结论，应能追溯到相应查询记录，并限定在这些记录能够支持的范围内。