适用范围：先明确跟踪什么
汽车区块链跟踪可以讨论车辆履历、零部件流转或维修记录的核验，但这些场景涉及的事实仍需由链外主体采集。以下解释适用于需要将外部记录交给链上合约、或在机构间交换可验证声明的方案，不代表某个汽车项目已经实现这些能力。
误区一：上链就能证明记录真实
以太坊预言机文档说明，智能合约默认无法直接访问链外信息，需要预言机提供外部数据；数据的正确性、可用性和提供者责任仍是关键问题。
用于汽车场景时，维修记录写入链上，并不能自动证明维修实际发生。方案还需要说明谁录入、依据什么证据、如何将记录对应到车辆，以及发现错误后由谁处理。记录留痕与现场事实核验承担不同职责。
误区二：节点多就没有数据源风险
多个节点若都读取同一个维修系统，可能共同转发同一条错误记录。评估方案时，需要区分传输节点数量与原始信息来源的独立性。对于来源之间的冲突，也应明确采用什么核验规则，不能仅凭多数一致就认定车辆实际状态。
误区三：凭证验签通过就能直接采信
W3C可验证凭证数据模型明确区分可验证性与声明真实性：验证方仍需依据业务规则评估签发者、证明、主体和声明。该模型也允许使用可信数据库等注册机制，并不限定必须使用区块链。
例如，一份零部件检测凭证能够通过密码学验证，业务方仍需确认签发机构是否被认可、检测对象是否对应当前部件，以及检测范围是否覆盖所需判断。仅有数字签名不足以回答这些问题。
误区四：记录越公开，跟踪效果越好
车辆记录可能与车主身份、活动地点发生关联。W3C文档提醒，持久保存且易于关联的数字信息可能带来隐私问题。因此，设计跟踪方案需要明确哪些信息用于核验、哪些主体有权查看，而不能把完整公开当作默认目标。
常见问题：旧记录和错误记录怎么处理
历史记录只能反映特定时点的声明。例如，过去的检测结果不能直接证明零部件当前状态；缺少维修记录也不能直接推出车辆从未维修。
方案应明确采集时间、更新时间、适用期限以及更正和争议处理方式。需要自动触发业务动作时，还应定义数据过期、来源中断或结果冲突时的处理条件。这样才能让跟踪记录具有清晰的使用边界。