为什么不能只引用截图或单一平台
区块链新闻中的“某笔交易已完成”“某区块包含大量交易”或“某地址发生转账”等表述，都应尽量对应到可定位的链上对象，例如交易哈希、区块哈希、区块高度或地址。区块浏览器提供了查询区块、交易、账户、合约和验证者等信息的界面，但界面上的标签、排序方式和展示口径可能因平台而异，因此不能只凭截图、搜索摘要或单一网站的结论完成核验。
较稳妥的做法是同时保留原始标识和查询时间，并在条件允许时使用另一家浏览器、公开节点接口或链的官方开发者文档进行复核。交叉核验的重点不是让不同页面看起来完全相同，而是确认它们指向同一条链、同一个对象，并解释数值差异来自统计口径还是数据状态变化。
第一步：确认网络、对象与唯一标识
首先要确认报道涉及的是哪条网络，例如比特币主链、以太坊主网或测试网。以太坊区块浏览器通常同时展示执行层数据和共识层数据；两者关注点不同，不能把验证者、epoch 或 slot 信息直接当作普通交易数据。测试网数据也不应被写成主网事实。
其次应优先取得唯一标识。区块可用区块哈希、区块高度或交易所在区块定位；交易可用交易哈希定位；合约和账户则应记录完整地址。比特币的 getblock 接口以 blockhash 为必要参数，并可按不同 verbosity 返回十六进制原始数据、区块对象或包含交易详情的对象，这说明区块哈希是连接报道与原始记录的重要依据。
第二步：核对区块与交易字段
核对区块时，应至少比较区块哈希、区块高度、时间、交易数量以及前一区块哈希。比特币 getblock 返回的常见字段还包括 confirmations、Merkle root、区块大小、权重、难度、chainwork 和交易标识列表。报道若声称“区块已确认”或“属于主链”，就应检查确认数及相关链位置，而不能仅依据页面颜色或状态文字。
以太坊浏览器可展示区块高度、时间戳、交易数、gas 使用量、gas 限制、基础费用、销毁费用、父哈希和状态根等字段。核对交易时，应关注交易哈希、状态、所在区块、发送方、接收方、转移的代币、金额以及手续费。若文章讨论合约调用，还要查看输入数据、事件日志和合约地址，避免把普通转账与合约内部产生的代币转移混为一谈。
时间字段尤其需要谨慎。不同系统可能使用区块提议时间、交易被纳入区块的时间或 Unix 时间戳。新闻写作应明确“提交时间”“纳入区块时间”还是“页面显示时间”，并尽量保留原始时区和时间格式。
第三步：区分原始事实与平台推断
区块哈希、交易哈希、区块高度、交易列表等通常属于可直接比对的链上字段；“某地址属于某机构”“某笔转账代表某种商业行为”则往往需要链下证据，不能仅凭地址标签或资金流向下结论。浏览器显示的代币名称、价格、总市值、地址标签和风险提示，也可能是平台整理或推断信息，引用时应标注其性质。
以太坊资料将数据区分为执行数据与共识数据。涉及验证者、attestation、finalized 状态、slot 或 epoch 的报道，应使用相应共识层字段，并说明所依据的状态。涉及交易执行、gas、合约事件的报道，则应回到执行层交易和区块记录。不同层的数据不能在没有解释的情况下互相替代。
适用条件与常见问题
这种核验方法适用于能够公开查询区块或节点数据的公链事件，尤其适合验证交易是否存在、交易是否进入区块、区块是否处于主链位置，以及某地址在链上的公开活动。它不适合单独证明现实身份、交易动机、资产所有权或新闻中的法律结论。
常见问题一是把待处理交易写成已完成交易。解决方法是检查交易状态和所在区块。问题二是把区块浏览器的实时估算值当作历史事实，例如当前 gas 建议或确认时间；这类数据会随网络状态变化，报道历史事件时应使用对应时点的记录。问题三是只核对金额、不核对代币合约地址，导致同名或仿冒代币被误认。问题四是忽略分叉、重组或链选择，因而应检查确认数、父哈希及是否处于主链。
发布前可制作一份核验清单：记录网络名称、查询入口、区块或交易唯一标识、关键字段、查询时间、第二个独立验证来源，以及哪些内容仍属于链下推断。这样既能提高报道可复核性，也能避免把平台界面上的解释误写成区块链已经直接证明的事实。