先区分溯源与真实性
资料溯源关注的是一项数据或信息的来历，包括相关实体、处理活动和参与主体。W3C PROV体系将这些要素组织成可交换的溯源信息，并支持描述数据如何产生、由谁负责、经过哪些步骤以及如何形成衍生结果。它有助于评估数据的质量、可靠性和可信程度，但“记录了来源”并不等于“来源内容必然真实”。
因此，区块链上的时间戳、交易记录或哈希值，主要能够证明某项内容曾以某种形式被写入链上，以及之后是否发生了变化。它们通常不能单独证明链下原始资料没有错误，也不能证明提交者一定具备权威资格。核验时应把“是否被篡改”和“最初是否正确”分开判断。
建立完整的来源链
核验的第一步是明确资料对象。应记录原始文件、接口响应、检测结果或业务凭证的唯一标识，并保留必要的版本、生成时间、采集环境和格式信息。随后追踪处理活动，例如采集、清洗、转换、汇总、签名和上链等环节。每一步都应能关联到具体系统、机构或操作主体。
可以借鉴PROV的思路，将资料看作实体，将采集和处理看作活动，将机构、系统或人员看作责任主体，再记录实体与活动之间的生成、使用和派生关系。这样形成的不是一条孤立的区块链交易，而是一张可审查的来源关系图。若中间存在人工修改、批量导入或数据合并，也应明确记录，而不能只保留最终结果。
核对上链环节与预言机
区块链智能合约通常不能直接读取链下网站、数据库或现实世界事件，外部资料需要通过预言机等链下组件取得并提交到链上。因此，核验资料来源时，不能止步于查看智能合约存储的值，还要了解数据由哪些外部来源提供、由谁读取、采用什么接口、经过何种转换，以及最终由哪个链上账户提交。
预言机带来的关键问题包括来源真实性、数据完整性和数据可用性。真实性要求资料确实来自声明的来源；完整性要求资料在读取、传输和上链过程中没有被擅自修改；可用性则要求数据能够按约定持续提供。若系统采用多个来源或多个报告者，还应查看冲突处理、聚合和异常值过滤规则，因为最终上链值可能是处理后的结果，而不是某个原始来源的直接复制。
适用范围也需要写清楚。链上记录适合核对数字凭证、版本变化和提交过程，但对于天气、物流状态、检测结论等链下事实，仍需审查原始提供者、采集方法和责任机制。区块链只能固定传入的数据，不能自动替代对现实来源的审计。
一套可执行的核验步骤
首先，确认资料的原始出处是否明确，检查域名、机构身份、接口说明、版本信息和发布时间是否相互一致。其次，对原始内容计算或核对内容摘要，确认链上保存的哈希、文件指纹或版本标识是否对应同一份资料。再次，沿着溯源关系检查每次转换：输入是什么、输出是什么、由哪个系统执行、是否有可复现的规则。
然后核对链上交易和合约事件，确认提交账户、区块记录、调用参数与业务记录是否匹配。对于预言机传入的数据，还要检查来源数量、报告者身份、签名或授权方式，以及异常和冲突的处理逻辑。最后，分别给出三个结论：内容是否与原始资料一致，来源是否能够追溯，事实本身是否有独立证据支持。三者不能合并成一个笼统的“可信”。
常见问题
问题一：链上数据不可篡改，是否就代表资料真实？不代表。不可篡改主要说明已上链记录之后较难被无痕修改，无法证明上链前采集的数据没有错误、伪造或偏差。
问题二：只核对一个官方接口够不够？这取决于业务风险和来源特性。单一来源容易形成集中式信任点，至少应确认接口身份、访问时间、返回内容和责任主体；对重要资料，还应结合独立来源或原始凭证进行交叉核对。
问题三：哈希值能证明什么？哈希可以帮助判断两份内容是否一致或内容是否发生变化，但不能说明内容由谁产生、产生过程是否合法，也不能单独证明内容符合事实。
问题四：什么时候适合采用PROV式记录？当资料需要跨系统流转、重复处理、版本管理或责任追踪时，结构化记录实体、活动和主体之间的关系尤其有用。它适用于审计和复核，但仍需结合领域标准、权限记录及独立证据。