基于Hyperledger Sawtooth的农产品供应链追溯系统的研究与设计

曹祖晟，丁磊

（广东工业大学计算机学院，广州510006）

0 引言

近年来农产品的安全问题得到了社会的广泛关注，劣质农产品给人们的生命财产安全带来了巨大威胁，但事后的追责却因为缺乏可靠证据或难以定位责任方而难以继续，严重侵害了消费者的权益。在农产品供应链中，互信难的问题[1-2]使得参与方之间达成合作的成本升高，而参与方各自维护自己的数据仓库，缺乏统一的标准体系，又使得农产品在不同流通环节中数据混乱，且中心化的运作方式易造成信息不透明，导致追溯信息可信度不高[3]。

区块链是一种去中心化、无需信任的新型数据架构，目前已经发展到3.0时代,成为各行业去中心化数据管理的技术支撑[4]。区块链由网络中所有的节点共同拥有、管理和监督，不接受单一方面的控制，数据上链后被永久记录，不能被篡改，在解决追溯系统可信度问题方面具有先天技术优势，能够实现可追溯性，有效解决上述农产品供应链中的问题。Kamble等人通过解释结构模型等方法分析将区块链技术运用到农产品供应链的驱动因素，结果也表明了可追溯性是采用区块链技术最重要的原因[5]。近年来国内外学者运用区块链技术在供应链领域进行了探索研究，如Tian等人运用区块链与RFID技术相结合的方法实现了一个供应链追溯系统[6]；李明佳等人结合区块链技术设计了食品安全溯源体系并论证了有效性[7]；方燚飚等人设计了基于区块链的供应链交易系统，能够实现更高效、透明的信息共享[8]；洪坤明等人结合GS1编码标准，设计了基于联盟链的水产养殖品质量追溯系统，使得追溯更高效[9]。在数据存储方面，由于一般区块链的链式存储方式，查询效率低下，为此，杨信廷等人提出了一种“数据库+区块链”链上链下追溯信息双存储方法，保证了追溯信息可靠性的同时保证了查询效率[10]。现在的研究大多都是基于常用的区块链系统如Bit⁃coin、Ethereum、Hyperledger Fabric，对 于Hyperledger Sawtooth的研究较少。M.P.Caro等人分别用Ethereum和Sawtooth实现了同一种供应链系统，并对两种方案实现的系统进行测试，结果显示Sawtooth拥有更优的性能，但缺点是Sawtooth不如Ethereum成熟[11]。Fabric和Sawtooth都是Hyperledger下的项目，区别是在于Fabric注重隐私，而Sawtooth注重特定业务[12]，在农产品供应链业务频繁的体系中，互信的商户信息是公开的，对隐私性的要求较低，所以Sawtooth比Fabric更适合农产品供应链追溯系统。综上，区块链技术在解决供应链面临的各种问题上具有显著优势。因此本文对Hyperledger Sawtooth和农产品供应链展开研究，结合GS1编码体系，设计了一个农产品供应链追溯系统，完成农产品供应链交易并记录数据，构建追溯链，解决农产品供应链面临的参与方互信难、信息不对称、产品质量和安全问题追责难等问题。

1 系统模型

本文系统采用的农产品供应链追溯模型如图1所示，参与方有生产商、加工商、分销商、零售商、消费者和拥有监管职权的监管部门。

图1 供应链追溯模型

系统的架构分为物理层、数据层、区块链层，如图2所示。物理层主要包括供应链中的各参与方和资产，即生产商、加工商、分销商、零售商、消费者和监管部门等实体以及商户创建的产品等各项资产；数据层主要是各资产的属性，如：所有者、产品类型、重量、采摘日期或屠宰日期等，属性在系统中的表现方式为传输和存储在系统中数据以及包含索引信息的二维码；区块链层是处理和存储可追溯性数据的区块链平台，响应用户的操作请求，并对数据进行持久化存储。

图2 系统架构

本文设计的农产品供应链追溯系统是在Hy⁃perledger Sawtooth基本框架中实现的，应用区块链的分布式特征，每个节点都备份所参与链的相同账本，共同维护账本的完整性和不变性[13]。基于Hyperledger Saw⁃tooth的区块链是一种联盟链，通过节点与节点双向连接的方式形成可靠的区块链网络，参与方在整个网络中共享数据，有效解决供应链中不同参与方所维护的数据不同步的问题。多节点的区块链网络保证了系统的安全性，当少量节点故障时不影响网络的正常运作，当有新节点加入时也能通过其他节点获取完整的账本。农产品供应链的所有交易信息都将永久记录在账本中，通过查找账本可以准确构建供应链的历史过程，从而达到追溯的目的。

本文设计的系统结构模型如图3所示。区块链网络中有多个Sawtooth节点，每个节点都拥有相同的验证器、交易处理器、共识引擎和REST API，每个节点都能以可插拔的方式连接客户端[14]。基于Hyperledger Sawtooth的开发要求通过定义交易处理器的业务逻辑、客户端的业务逻辑和数据模型构建交易族（TF，Trans⁃action Family）来完成特定业务需求。

图3 Hyperledger Sawtooth区块链网络结构模型

2 系统设计

系统的设计细分为七个模块，第一模块系统角色设区分了本系统面向的用户类型；第二模块GS1编码设计规定了用户使用本系统时应该遵循的产品数据规范；第三模块交易和批次，定义了交易和批次的数据结构，规定了客户端打包用户交易的规则；第四模块区块链结构规定了区块的打包规则以及区块链的链接方式；第五模块寻址方案制定了State存储空间的划分规则及索引方式，提供了高效的数据库查找方案；第六模块交易逻辑设计描述了交易从发起到区块产生的全过程；第七模块追溯链构建设计了追溯链条的构建算法。

2.1 系统角色设计

本文系统中的角色主要包括系统管理员、业务管理员、操作员、追溯者四类，各角色说明如表1所示。系统管理员拥有管理节点的权限，能代表节点进行链上治理，验证业务管理员的身份并管理其读写访问权限；业务管理员是一个拥有的admin权限的参与方（组织）代理，拥有一个组织的所有操作权限，同时可以管理该组织操作员的权限；操作员也是组织下的代理，拥有组织授予的读写权限，可以进行相应的业务操作；追溯者拥有构建农产品供应链中历史过程的权限，并查看产品相关历史信息。各供应链商户以组织的形式参与到区块链系统中，业务管理员对应供应链中的商户角色，操作员对应商户中的员工角色，追溯者主要对应有追溯需求的消费者和监管部门。不同的角色登录客户端将打开不同的操作子集。

表1 角色说明

系统采用严格的身份认证机制，使用公私密钥对进行身份标识，交易的产生、打包、处理、数据的写入和读取都会进行相应的签名验证，不符合权限的操作将被拒绝。

2.2 GS1编码设计

为避免不同参与方的产品编码规则不同，造成数据的混乱，系统采用标准化的编码体系，使用GS1编码体系对农产品相关信息进行唯一标识[15]，关键编码如表2所示。GTIN-12码唯一标识产品，GLN码唯一标识了厂商的物理位置，编码都内含了厂商识别码，在区别产品和位置的同时也区别了厂商，为追溯链的构建提供了数据上的便捷。

表2 关键编码

系统对owner、product_id、pre_product_id、dir_prod⁃uct_id、location、pre_location、dir_location七个字段进行了GS1体系的编码，分别对应厂商识别码、当前产品GTIN、来源产品GTIN、厂商GLN码和来源厂商GLN码，这七个字段伴随着供应链阶段的前进而更新。

2.3 交易和批次

系统中任何事件都通过交易的方式进行，如创建产品、记录产品信息、修改产品信息、创建代理、更新代理权限等。一个或多个交易在客户端中被打包成一个批次，通过REST API提交至验证器进行处理。一个批次的数据结构如图4所示，一个批次包括批次（Batch）、批次头（BatchHeader）、交易（Transaction）和交易头（TransactionHeader）。在批次中，header是经过序列化的批次头，在交易处理器中进行反序列化后将得到签名 公 钥（signer_public_key）和 交 易 列 表（transac⁃tion_ids），验证签名密钥（header_signature）是否与签名公钥匹配，从而验证批次的合法性，交易列表对应每一笔交易（Transaction）。交易与批次的结构类似，交易头中包含了打包批次的公钥（batcher_public_key），输入（inputs）和输出（outputs）分别表示交易需要读取的状态地址和交易写入的状态地址，有效负载（payload）记录了交易的具体参数。

图4 批次（Batch）数据结构图

2.4 区块链结构

交易以批次的形式提交到验证器，一个或多个批次的交易被验证和执行成功后被打包成区块并发布，区块和批次的嵌套数据结构与交易和批次的数据结构类似，在此不再赘述。区块链的结构示意图如图5所示，区块包含区块头和区块体两部分，区块头中包含前一个区块的哈希值、区块号、签名公钥、时间戳、批次列表、状态根哈希值和本区块的哈希值。所有交易的相关数据以Merkle-Radix树的形式存储在验证器的状态（State）中，区块打包时将State的当前状态也打包进区块。数据存放在树最下层的叶子节点，叶子节点不断向上层节点进行哈希运算，最终得到树的根哈希，区块一旦被验证，任何数据的改变都将导致根哈希的改变，仅检验根哈希值就能保证数据的完整性[16]。

图5 区块链结构示意图

2.5 寻址方案设计

Merkle-Radix树能够以索引的方式迅速定位数据的物理存放地址，如图6所示。地址是35字节的十六进制编码字符串，共70个字符，每个字节向下索引一个叶子节点，从根节点到叶子节点，深度最多可以达到35。

图6 寻址方式示意图

根据业务逻辑需求设计寻址方案。完成农产品供应链相关功能的交易族被命名为APSChain，使用SHA512算法对APSChain编码，取哈希值的前六位“f20ac0”作为命名空间地址的前缀，所有APSChain相关存放在状态中的数据的地址都以此前缀开头。如图7所示，前6位是命名空间地址前缀，紧接在后面的两个十六进制字符用来对具有相同结构的数据进行分组，分组情况如表3所示。

图7 寻址地址结构

表3 寻址地址分组

剩余62个索引字符将根据分组属性进一步灵活划分，如User分组的62个字符中，前两个用于区分用户在系统中的身份，11、12、13、14分别对应系统管理员、业务管理员、操作员和追溯者四种用户角色，最后60个字符取用户公钥进行SHA-512后的前60位。再如Product分类，产品对象在系统中更新的频率很高，为了达成追溯目的，需要长久且完整地存储产品的所有历史记录，所以将命名空间的最后4个十六进制字符规定为分页地址。属性本身存储在以0000结尾的命名空间中，属性的历史记录按时间戳的先后顺序存储在0001至ffff的分页中，每当属性进行更新，0000中的数据将加入到历史记录分页中，并将0000中的数据更新为最新的数据。交易处理器将这些分页视为环形buffer，当ffff分页被填充后，下一次更新将覆盖0001分页，在此方案下，可以在记录被覆盖之前存储162*(1 64-1)=16776960个历史分页，充分满足了记录产品历史属性的需求。分页地址之前的58个字符取产品的GTIN-12编码经过SHA-512后的前58位，最终生成了特定产品对象的完整命名空间。

2.6 交易处理和区块上链

交易处理流程如图8所示。交易由客户端发起，经过序列化的一笔或多笔交易被打包成批次，通过REST API发送到验证器。验证器是Sawtooth节点的核心组件，负责检验交易的合法性，其过程包括对交易信息完整性的检测和对上下文完整性的检测，被篡改或不符合权限要求的交易将被丢弃；若上下文不完整，则向区块链网络中请求上下文信息，在规定时间内未获得上下文信息的交易也将被丢弃。完成交易合法性验证的交易批次将在区块网络中进行广播，然后被发送至对应的交易处理器。交易处理器定义了处理交易的业务逻辑，即智能合约。收到交易内容的交易处理器首先对交易内容的有效负载进行反序列化，接着按照智能合约的业务逻辑对交易进行处理，同时根据寻址方案找到验证器中存放数据的状态地址，并改变状态。状态存储了区块链的所有数据，状态完成更新后，验证器将当前状态的哈希值和批次打包成区块，添加到当前区块链的链头。其他收到广播的节点也将根据批次的内容进行合法性检验、执行智能合约、改变状态和区块打包等，从而保证了区块链分布式账本的统一性。

图8 交易处理流程图

2.7 追溯链构建

追溯分为“追”和“溯”两个过程，即“向上溯源”和“向下追寻去向”两个过程。由于农产品在供应链中通常以散装称重进行交易，所以一批农产品可能被分为多批流向供应链下游，所以“追”的过程不能像“溯”的过程一样简单视为一条单链，应构造树状的追溯链。本文采用基于深度优先搜索算法（Depth First Search，DFS）的追溯链构建算法如下：

算法1追溯链构建算法

利用该算法在状态中查找农产品相关的所有信息构建追溯链。

3 系统实现

3.1 系统启动测试

开发与测试平台如下：Ubuntu 18.04操作系统、Intel Core i5-4210M处理器，内存8G，部署Docker 18.03-ce、docker-compose 1.24.0、Nodejs v12.20.1。

运用Docker技术，将客户端和运行APSChain智能合约的交易处理器与Sawtooth组件在测试环境下一起运行，运行成功显示如图9，Docker容器的启动情况如图10。

图9 系统启动成功示例图

图10 Docker容器启动情况

系统运用在生产环境中还应考虑商业环境下供应链参与方维护区块链节点的成本和收益，采用合适的共识机制，将devmode-engine替换为其他共识引擎，达成共识后，区块链网络中的各节点都将运行功能相同的docker容器。

3.2 追溯结果

追溯者使用移动设备扫描二维码进行追溯链的构建，二维码信息需包含农产品的GTIN-12编码和时间戳。以上信息将携带追溯者的公钥以批次的形式被发送至验证器，并启动追溯者的操作子集，结果将打印在追溯者的客户端界面。如图11所示，以追溯者在供应链中的阶段为原点，向供应链上游溯源出一条链式结构的链，向供应链下游追寻出一个树状结构的链，两条链拼接在一起即是一条完整的供应链追溯链。

图11 追溯链示例

4 结语

本文针对农产品供应链情景下参与方互信难、信息不对称、产品质量和安全问题追责难等问题，研究并设计了一种农产品供应链追溯系统。本文首先对供应链系统的研究现状进行分析，论述了区块链技术用于供应链追溯的有效性，并选取了性能较优的Hy⁃perledger Sawtooth框架进行进一步研究，然后确定了系统的整体模型，接着对系统的用户角色、GS1编码体系、交易批次的数据结构和寻址方案等模块进行细节的设计，最后运用“追”与“溯”的追溯链构建算法，实现了农产品追溯链的构建。经过系统的运行测试和追溯链构建测试，系统能够稳定运行并构建追溯链，可满足农产品供应链的追溯需求。