溯源关系与链上处理
产品区块链溯源涉及两类问题：一类是怎样描述产品的来源、处理过程与责任主体，另一类是怎样通过链上程序处理相关记录。前者需要清晰的数据关系，后者需要明确的执行规则。两者结合，才能解释一条记录代表什么，以及它如何进入系统。
来源建模：实体、活动与主体
W3C的PROV-O使用实体、活动、主体等概念表达来源信息，并通过生成、使用、派生和关联等关系支持不同系统之间的信息交换。它是来源信息的建模工具，并不专属于区块链。
在产品场景中，可以把某批产品或一份检测报告描述为实体，把加工、检测描述为活动，把参与企业描述为主体。例如，报告由检测活动生成，活动与检测机构关联。这是概念应用示例；实际系统仍需明确批次边界，以及拆分、合并后的对应关系。
智能合约：代码、状态与调用
以太坊开发文档将智能合约解释为位于链上特定地址的代码与状态，用户通过交易调用其功能；合约依照代码执行规则。文档还介绍了链外数据接入和多签授权机制。
用于溯源时，可以把业务条件转化为程序规则，例如限定谁能提交某类记录、哪些条件满足后才能改变处理状态。这里的“交易”可以是一次数据提交或功能调用。规则是否符合实际业务，仍取决于设计与实现。
链外数据与适用条件
智能合约自身不能直接获取现实事件信息，需要通过预言机等机制接收链外数据。产品检测结果、生产事件等信息进入合约之前，因此还存在数据采集与传递环节。
适用条件是能够明确数据提供者、记录对象和业务含义，并建立相应核验机制。把一项检测结论写入链上，只能让程序处理这项输入；输入是否对应真实产品、检测过程是否可靠，需要额外证据。
多方授权与常见问题
多签机制要求满足约定数量的有效签名后才能执行操作，可用于需要多方共同授权的环节。但多人批准与事实核验承担不同作用，签名数量本身不能证明记录内容真实。
来源本体能直接保证产品质量吗？不能，它帮助表达和交换来源关系。智能合约能自动发现虚假报告吗？只有具备相应输入与校验规则时，才可能识别特定问题。理解系统能力时，应分别审视关系表达、规则执行和现实证据，避免将链上记录直接等同于产品真实性证明。