来源关系建模：先说明追溯什么
溯源系统首先需要表达对象、过程和责任主体之间的关系。W3C的PROV-O以实体、活动和代理者等概念描述来源信息，并提供生成、派生、使用和归属等关系，支持不同系统交换来源描述。它属于数据建模工具，本身不要求使用区块链。
以加工业务为例，可以把原料批次、成品批次和检验报告作为实体，把加工作为活动，把参与企业作为责任主体。这样才能表达某批成品使用了哪些原料、经历了什么过程，以及由谁参与处理。仅有一串按时间排列的记录，未必足以解释这些关系。
智能合约：把业务规则变成可执行逻辑
以太坊智能合约文档将合约描述为部署在链上特定地址的程序，包含代码与状态。账户通过交易调用合约功能；部署和执行涉及计算费用。合约不能自行获取链外事实，外部信息需要通过预言机等机制接入，多签机制则可要求多个有效签名共同授权。
用于溯源时，可以将提交记录、确认交接等操作设计为合约功能，并为不同操作规定允许的状态变化。例如，系统可以要求先存在加工记录，才接受后续交接确认。这是业务规则的设计示例，具体条件取决于实际流程。
身份与权限：地址需要对应业务角色
链上地址提供程序交互的标识，业务系统还需要明确它对应哪家机构、哪类岗位，以及能够提交哪些记录。控制一个地址，并不自动说明持有者具备检验或认证资格。
涉及多方确认的流程，可以考虑共同授权机制。但签名数量只能体现授权条件是否满足，不能替代参与方对货物、报告或交接事实的核验。
链下数据接入：记录可信度的关键边界
物流状态、检测结果等信息产生于链外。系统需要明确由谁采集、如何提交，以及出现差错后如何补充说明。预言机解决的是外部数据进入合约的问题，输入内容是否真实仍取决于数据来源及核验过程。
因此，设计时应分别说明现实事件的发生时间与链上提交行为。不能仅凭一条链上记录，就推断货物实际经历了记录所描述的全部过程。
适用条件与常见问题
当多个参与方需要共享来源关系，并按共同规则提交和确认记录时，可以评估区块链与溯源模型的结合。实施前应先统一对象标识、关系含义和角色权限，否则不同系统即使交换了数据，也可能产生不同理解。
是否必须使用PROV-O？它提供可复用的来源描述方式，是否采用取决于互操作需求。智能合约能否自动判断商品真伪？仅凭合约无法完成这一判断，还需要可靠的链外证据。理解这些边界，才能合理划分数据模型、程序规则与现实核验各自的职责。