0 概述

农产品溯源, 即对农产品从生产到流通产业链所有环节的正向追踪与逆向回溯^[1]。我国农产品溯源体系经过多年发展日趋完善, 但仍存在溯源结果可信度低、系统灵活性差等问题。

为提高农产品溯源系统的可信度与灵活性, 可采用区块链替代传统集中式数据库, 以确保溯源数据安全存储与信息源头不可抵赖, 从而实现农产品的可信溯源^[2]。此外, 还可将完整产业链解耦为多个独立环节, 与超级账本中独立通道结合为环节模块, 配合模块调配机制并根据实际生产动态调整溯源流程, 最终实现农产品的动态溯源。本文在文献[3-4]所提农产品产业链柔性溯源模型的基础上, 结合超级账本的特点与农产品溯源的可信性及灵活性需求, 提出基于区块链的农产品柔性可信溯源模型设计方案。

1 传统农产品溯源 1.1 传统溯源模型

2006年我国提出建立农产品质量安全追溯体系^[5], 经过多年发展该项目已经取得丰硕的成果。文献[6]结合物联网技术特点提出“一核、双轴、三链”的农产品质量安全追溯系统技术体系。文献[7]基于食品链提出溯源系统的追溯链层次模型。文献[8]针对我国溯源系统分散不集中的特点, 设计出农产品质量安全多边溯源系统。文献[9]提出基于区块链的供应链可信溯源查寻实现方案。文献[10]构建出基于Fabric区块链实现策略的农产品质量溯源系统设计方案。通过分析典型溯源系统得到国内传统农产品溯源模型, 其结构如图 1所示。

传统农产品溯源系统普遍以集中式数据库为中心^[11]。在实际生产过程中, 产业链中生产资料的供应、种植、仓储、物流、销售等环节依次排布^[12], 溯源数据上传至集中式数据库^[13]。质量监管部门通过调取集中式数据库的信息以达到监督农产品质量安全的目的。消费者向集中式数据库发送查询请求可得到所购农产品的溯源信息。

1.2 存在的问题

在农产品溯源研究的前期阶段, 国内研究人员通常将重点聚焦于溯源数据充分采集与产业链完整覆盖上, 而在数据安全存储和系统动态追溯等方面的研究相对较少, 导致传统农产品溯源系统的可信度与灵活性不足。部分研究人员将区块链技术应用到农产品溯源中, 却很少结合两者的特点优化溯源流程及系统结构, 虽然得到的溯源结果具有可信度, 但系统灵活性仍有较大提升空间。

1) 可信度

传统农产品溯源系统将数据存储在集中式数据库中, 这带来数据安全问题:(1)企业可能会为自身利益篡改数据, 导致无法达到可信溯源的目标; (2)如果系统遭受黑客攻击或者存储介质发生损坏, 溯源数据会被破坏甚至消失。数据安全问题会导致消费者无法查询到正确的溯源信息, 从而降低农产品溯源系统的可信度。

2) 系统灵活性

传统溯源系统通常针对较窄范围内特定的农产品进行溯源, 溯源对象与生产过程的局限性导致溯源系统的事务处理流程被固化, 无法根据实际生产场景动态调整生产环节组合顺序, 不利于系统功能拓展与升级, 导致溯源系统的灵活性较差。

2 区块链 2.1 区块链概念

2008年NAKAMOTO提出区块链概念^[14], 并将其作为比特币的底层技术支撑。区块链是一种共享账本, 用于数据分布式加密存储, 其融合了计算机网络、概率论、密码学等多方面技术, 具有去中心化、天然互信、数据不可篡改等特性^[15], 被广泛用于金融、能源、征信和贸易等多个领域^[16]。

2.2 区块链结构

区块链是由区块有序串联形成的链式数据结构^[17], 区块是构成区块链的基本单元, 每条区块链都存在于各自所属的通道x中。区块链包括区块头与区块体, 其结构如图 2所示。区块头包含版本号、前一区块Hash、Merkle树根、时间戳等本区块元信息。前一区块Hash字段中保存前一区块内容的Hash值^[18], 若前一区块中任何内容被篡改, 则对其内容再次进行Hash运算后的结果就与此字段完全不同^[19], 由此可定位发生篡改的区块位置。Merkle树是一种Hash二叉树, 其叶子结点保存溯源数据, 分支节点保存子节点Hash值, 底层节点数据发生变化后会逐级向上传递到父节点直到Merkle树根, 从而可定位发生篡改的节点位置。

2.3 区块链实现方式

区块链按照其对外开放程度分为公有链、私有链和联盟链。其中:所有人都能参与并维护公有链(如比特币), 其在区块链中信息公开, 在公有链的基础上引入身份验证机制可实现私有链与联盟链; 私有链只允许某组织内部少数人参与, 对信息保密度要求较高, 通常用于企业内部系统; 联盟链介于公有链与私有链之间, 由几个组织共同参与和维护, 其所存储信息也由上述参与方共享, 例如银行联盟链^[20]等。

目前区块链主要有以太坊和超级账本2种实现方式。其中:以太坊属于公有链, 对数据的保密度较低, 且参与方不易管理^[21]; 超级账本属于联盟链, 具有权限控制优势, 较以太坊安全程度更高^[22]。因此, 本文以超级账本为区块链实现方式来设计基于区块链的农产品柔性可信溯源模型。

2.4 超级账本

超级账本具有去中心化、天然互信、数据不可篡改以及多通道等特点, 其与农产品溯源相结合, 既可保证溯源数据的可信度, 又能为柔性可信溯源的实现提供架构基础。

1) 去中心化。超级账本采用分布式存储结构, 其中的peer节点均有同一账本的完整备份, 所有节点共同维护此账本。超级账本无集中式管理者, 所有peer节点都可给出提案, 并在通过共识机制后将新数据同步到每个节点的备份数据中, 从而避免农产品溯源系统的控制权由少数用户掌控。

2) 天然互信。由于超级账本属于联盟链, 要求其必须控制用户权限, 因此超级账本中内置基于证书等密码学机制的身份验证功能, 以确保只有联盟中指定组织成员才能对账本发起操作, 且一旦发生农产品质量安全问题可直接追责至溯源数据发起方, 身份的确定性保证了组织成员之间互相信任。

3) 数据不可篡改。数据被加密保存在区块的Merkle树中, 随区块同步到多个节点并持久化, 相邻区块通过Hash值产生密切关联。上述加密措施可提高数据篡改难度, 从而保证农产品溯源信息安全。如果要实现对某个区块中数据的改动, 则需继续修改所有后续区块和每个节点中的对应备份。此外, 由于超级账本为分布式存储, 如果某个节点的数据被破坏, 则其他节点可将数据恢复到该节点, 因此提高了区块链系统的容错性。

4) 多通道。多通道是超级账本特有的概念, 1个通道存在1个账本, 该逻辑结构可将账本相互隔离, 账本之间无法直接通信从而确保账本的机密性。操作不同账本需不同身份加密信息, 保证了账本数据的隐私性。多通道为后续动态溯源机制的实现提供了架构基础。

3 基于区块链的农产品柔性可信溯源模型

本文设计了基于区块链的农产品柔性可信溯源模型及系统架构, 并以生姜产品为溯源对象实现对该系统模型的验证。

3.1 系统设计思想与动态追溯机制

以下介绍本文所提基于区块链的农产品柔性可信溯源模型系统的设计思想与动态追溯机制。

1) 系统设计思想

如果将所有模块的数据存储在同个账本中, 随着参与方的加入及环节扩展, 数据量会日渐庞大, 数据内容会趋于复杂, 不同环节参与方在同个区块链系统中共享数据隐私性也会降低。本文在双区块链和侧链结构的农产品供需系统基础上^{[2, 20, 23]}, 结合超级账本的通道概念, 进一步细化存储结构, 提出“一环节一账本”的设计思想^[24], 将各环节数据相互隔离存储在不同账本中, 为后续实现动态溯源所要求的模块化结构做好准备, 并在保证数据安全的基础上降低存储结构复杂度以实现可信溯源。

2) 动态追溯机制

农产品产业链中各环节之间衔接的先后顺序并非固定不变, 溯源系统需根据实际生产的推进情况灵活追踪不同环节直到串联为完整的溯源链, 即动态追溯。本文先遵循“高内聚, 低耦合”的软件设计标准, 将复杂的系统解耦、封装为一系列功能模块, 再在生产过程中根据实际需求选择后续环节, 并将现阶段农产品信息发送至该环节模块进行下一阶段处理, 从而实现农产品产业链灵活延伸, 使溯源系统能适应不同场景下的生产流程, 最终实现动态追溯。

3.2 溯源模型

为提高农产品溯源系统的可信度与灵活性, 本文结合“一环节一账本”的设计思想与动态追溯机制, 提出基于区块链的农产品柔性可信溯源模型, 其结构如图 3所示(图中实线表示直接通信，虚线表示间接通信)。在该模型中:产业链各环节和模块管理服务均由适量的独立模块组成, 模块内后台服务程序与具备本环节账本操作权限的peer节点整合, 能独立处理环节主体的事务请求并安全存储溯源数据; 环节模块与模块管理服务模块直接交互, 环节模块间通过此服务模块实现间接通信; 模块管理服务模块处于溯源模型的核心部位, 负责管理与调配系统中各环节, 并处理质量监管部门与消费者的查询请求, 完成环节之间动态组合进而实现灵活溯源。基于区块链的农产品柔性可信溯源模型由区块链储存关键数据以确保系统的可信性, 各环节之间无固定衔接顺序, 其主要根据模块管理服务模块的统一调度, 按照实际生产需求灵活排布环节模块, 最终实现产业链的柔性延展。

3.3 系统架构

基于区块链的农产品柔性可信溯源系统架构如图 4所示, 该系统主要由数据采集层、存储层、应用层以及交互层构成。

1) 数据采集层

数据采集层是由生产资料供应商、种植农户、仓库、物流公司、销售商等产业链中间环节参与者通过配套的农残检测仪、温湿度传感器、扫描设备、RFID标签等物联网设备, 详尽地采集各环节数据, 以实现农产品产业链信息的完整输入。

2) 存储层

存储层由超级账本与传统集中式数据库组成, 超级账本与集中式数据库分别保存溯源数据与非溯源数据。产业链各环节的参与者在对应账本中均有其特定身份标识, 根据溯源数据的加密信息可直接对发布者进行定位, 从源头确保数据的不可抵赖性。产业链各环节数据只保存于对应模块的账本内, 以降低数据结构复杂度, 并提高系统的可拓展性与灵活性。结合图 3可知, 模块管理服务模块处于系统中心, 其他模块均仅与其直接交互并由其统一管理, 各环节模块的状态信息也由模块信息账本统一保存, 通过集中式管理机制实现环节模块的规范管理与灵活调配。超级账本与传统的集中式数据库互相配合存储农产品溯源系统全部数据。

3) 应用层

应用层为系统管理员、数据提供者、质量监管部门以及消费者提供服务。其中:系统管理员负责维护农产品溯源系统与超级账本, 保证其稳定运行; 数据提供者即产业链中间环节的参与者, 其主要负责采集产业链中的溯源数据并上传到系统; 质量监管部门负责监督上链的农产品是否符合质量安全标准, 并对存在问题的农产品发出警告; 消费者是农产品产业链的最后一环, 其主要负责对所购农产品的溯源数据进行查询。

4) 交互层

交互层包括Web应用、手机APP、微信小程序以及溯源终端, 是系统与使用者之间的接口, 可提供快捷方便的系统操作途径。

3.4 系统运行流程与分析

本文以生姜产业链为例, 从动态溯源机制角度出发介绍基于区块链的农产品柔性可信溯源系统应用场景并分析动态溯源过程。

3.4.1 溯源系统的运行

假设某生姜产品依次经历种植、物流、仓储、物流和销售5个环节后到达消费者手中, 参照图 4的系统架构, 溯源模型的运行流程如下:

1) 种植环节

该生姜溯源产品的流程由种植环节开始。在种植环节运行过程中, 种植户将地块信息、种植人员信息、生产资料数据、生产过程数据等录入种植数据账本。在种植环节完成后, 系统自动为该环节输出产品生成批次码, 同时模块管理服务模块为种植户提供可选的下一环节。种植户根据实际生产需要选定物流环节, 种植环节的产品批次码会即刻通过模块管理服务模块提交到所选物流环节, 并在该环节完成后续过程。

2) 物流环节

在物流环节运行过程中, 物流公司将农产品的发货地、目的地、配送人员、配送路线等信息录入物流数据账本。在物流环节完成后, 相关操作与种植环节相同, 系统自动生成批次码, 物流公司选择仓储环节作为下一环节并将批次码提交至该环节, 然后在所选仓储环节完成后续过程。

3) 仓储环节

在仓储环节运行过程中, 仓库管理员将农产品的入库时间、出库时间、仓库环境信息等录入仓储数据账本。在仓储环节完成后, 重复与物流环节类似的操作, 系统自动生成批次码, 仓储管理员选择物流环节作为下一环节并将批次码提交至该环节, 然后在所选物流环节完成后续过程。

4) 物流环节

物流环节的运行过程与上个物流环节相同。在物流环节完成后, 系统会自动生成批次码, 物流公司选择销售环节作为下一环节并将批次码提交至该环节, 然后在所选销售环节完成后续过程。值得注意的是, 这批生姜虽经历过2次不同的物流运输过程, 但其物流数据的提交、处理、保存等操作均在物流环节模块中完成。

5) 销售环节

在销售环节运行过程中, 分销商将农产品的价格、销售地点、上架时间等录入销售数据账本, 系统自动为商品生成批次码。在销售环节完成后, 消费者可凭借销售环节批次码查询商品所经历的全部环节数据。

3.4.2 溯源流程的优化

结合上述系统运行流程可知, 柔性可信溯源模型使溯源流程较传统农产品溯源模型在灵活性方面有本质提升, 上述模型的逻辑流程如图 5所示。与传统农产品溯源流程的一维逻辑结构相比, 柔性可信溯源流程的逻辑结构升级为二维有向连通结构, 环节顺序不再固定, 产业链中任意两节点可前后相继, 进而实现随着实际需求动态改变生产流程走向的目的。

3.5 模型应用问题及解决方案 3.5.1 溯源码标识对象的确定

农产品产业链各环节生产信息通过溯源码前后衔接形成完整的溯源数据, 但是以哪种粒度的农产品作为溯源码标识对象值得考虑。本文从产业链网络中剥离并分析得到上、下游环节输出产品之间的对应关系模型, 并选取输出产品作为溯源对象。

由于产业链各环节形成复杂的供需关系网络, 对某一环节而言, 可能同时有多个上游环节发来不同生产原料, 也可能向多个下游环节同时输出本环节的不同产品, 产品之间供需关系较复杂, 因此上下游关系可分别从环节层次与产品层次来分析。值得注意的是, 产品层次的分析结果是在环节层次分析的基础上形成, 环节之间与产品之间的上下游对应关系如图 6所示。其中:a模块为复杂的农产品产业链, A、B、C、D分别代表种植、加工、仓储、物流等农产品产业链环节, 由于这些环节会出现在产业链中任何位置, 因此其既可作为上游环节向下游环节输出原料, 也可作为下游环节接收原料并运行本环节处理过程；b模块将C作为输入环节, 并剔除a模块中多余的上下游关系, A、B等n个输出环节向环节C输出原料, 环节C接收原料并进行本环节内的生产活动, 这种上下游关系可视为环节间复杂关系的基本组成单位；c模块将上下游关系的粒度进一步细化到产品层次, 上游环节输出原料就是该环节的产品, 下游环节接收原料为生产本环节产品, 环节间上下游关系的实质是产品间上下游关系；d模块在c模块的基础上减少了环节层次和其他无关产品, 只保留C环节某一输出产品及其对应的上游原料产品, 简化后产品上下游关系可视为产品间复杂关系的基本组成单位。

3.5.2 账本内容及数据格式

超级账本主要用来存储键值对数据。本文结合溯源码标识对象的确定, 以环节输出产品批次码和数据所属环节标识码为键, 以环节输入原料批次码集、生产过程负责人姓名和编号、加工步骤名称为值, 以JSON格式书写键、值信息并作为农产品溯源数据的存储格式, 具体样例如下:

1.{"traceCode":"12345", "linkCode":"CLink"}:

2.{

3."rawMaterialTraceCodes":[

4.{"rawMaterialTraceCode":"678",

5."linkCode":"ALink"},

6.{"rawMaterialTraceCode":"789",

7."linkCode":"BLink"}

8.],

9."producer":"oneProducer",

10."producerCode":"12345",

11."productionProcess":[

12.{"stepName":"firstStep"},

13.{"stepName":"secondStep"}

14.]

15.}

3.6 模型验证 3.6.1 应用背景

山东省万兴食品有限公司(以下简称万兴), 是全国生姜出口第一大户, 也是农业产业化国家重点龙头企业, 该公司已具有多年溯源系统应用经验。本文结合万兴生姜产业链流程分析其环节之间与产品之间的上下游关系, 将原有系统进行升级, 充分利用超级账本的多通道架构和模块化设计思想, 建立基于区块链的生姜产品质量安全管理柔性可信溯源系统。

3.6.2 系统模型实现

本文在Hyperledger Fabric v1.1版本开源框架的基础上, 采用4台服务器组建具有3个orderer节点、4个peer节点、基于Kafka共识机制的超级账本后端, 将fabric-sdk-java植入区块链前端代码并根据具体功能需求做出适配, 初步实现基于区块链的生姜产品质量安全管理柔性可信溯源系统。该系统自2019年7月开始测试运行, 到2019年9月已稳定运行70多天, 各区块链存储数据共计800余条。生姜脱水类产品系统、生姜脱水类产品向上与向下溯源信息、区块链后台测试样例信息输出等系统运行界面如图 7~图 9所示。在实际运行过程中可以看到, 系统将完整产业链数据按环节划分存储在不同模块的区块链中, 模块间通过网络交互数据合作完成系统功能, 并能根据生姜生产流程的变化改变或追加追溯环节, 柔性贴合实际的产业链走向, 实现了基于区块链的农产品质量安全可信溯源, 这表明该系统可有效提高溯源信息安全性和溯源结果可信度, 灵活性较传统溯源系统有本质提升。

4 结束语

本文在传统农产品溯源模型的基础上, 结合超级账本与农产品供应链的特点, 提出“一环节一账本”的系统设计思想与动态追溯机制, 建立基于区块链的农产品柔性可信溯源模型及系统架构, 针对模型应用过程中出现的追溯粒度与溯源数据结构问题给出解决方案, 并以生姜产品为追溯对象进行溯源模型的验证。分析及应用结果表明, 该系统具有数据存储安全、农产品质量安全责任主体明确以及系统拓展性强等特点, 实现了农产品的柔性可信溯源, 系统追溯产品信息可信度高, 可适用于多种生产场景。后续将针对本文模型设计溯源码标准和追溯机制提高系统效率, 研究用于数据批量处理应用场景的数据安全保障方案, 同时在农产品溯源系统中加入供需交易功能, 利用大数据分析并根据供需双方交易行为定向推送其所需农产品信息。