system: [SYSTEM]

user: 5. 区块链苹果溯源系统 基于上文提出的方案，本文以苹果溯源为例实现了一个系统原型。 5.1. 流程分析 图4展示了该原型系统的基本运作流程，下文对该流程进行分析。 在苹果成熟采摘前，以苹果树为单位进行维护。果树的发芽、花开、结果等生长观测信息需要追溯，应当上链；果农对果树所进行施肥、修剪、浇水、除虫、采摘等操作信息需要追溯，也应当上链。 苹果在果树上生长成熟后，即可作为基础单位进入系统维护。苹果的来源信息，即该苹果从具体某棵果树上采摘的信息上链；对该苹果所进行的除梗、包装、打蜡等粗加工操作也上链溯源。 在粗加工完成后，苹果被打入物流包裹中，运输至客户仓储。负责运输的物流公司、物流单号、运输状态等信息上链；此外，运输包中所包含的苹果信息也上链。 图4. 苹果溯源记录流程图 上述过程涉及三种主体：苹果树、苹果、物流包。在逻辑和物理上，每一个苹果树、苹果、物流包都有自己的唯一标识。 本应用使用二维码作为物理标识。在果园中，苹果的产量十分巨大，相对于传统的昂贵的RFID卡，二维码更适应每一个苹果都需要单独标识的情景。 在溯源过程中的任何一环，都可以对某个具体的溯源单位进行查询。如图5所示，如果用户扫描苹果树或物流包的二维码，即可获取目标的溯源记录；如果用户扫描苹果的二维码，除获得苹果自身的溯源记录外，也获取该苹果对应的果树和物流包的溯源记录。 图5. 苹果溯源记录流程图 5.2. 数据模型分析 代码3：溯源主体数据模型 Apple: { Meta: { product_id: id of the product， product_name: name of the product， description: description of the product， org: organization the product belong to， previous: [product id of apple tree， product id of package] }， Transactions: [ { tx_id: hashed transaction id， block_id: hashed block id the transaction belong to， transaction_time: when transaction committed into the block， operation_type: type of the operation， operation_user: who make the operation， operation_time: when the operation happened， description: description of the operation， }， ] } 苹果树、苹果、物流包三种主体的数据都需要保存。如上所示，它们的数据形式类似，可以大致分为两部分：一部分是Meta字段，它描述主体本身的属性，例如品名、所属公司等；另一部分是Transactions字段，它描述主体被进行的操作，包括操作类型，操作描述，操作执行人，操作时间，上链时间等。 此外，苹果树和物流包只需要维护自身的溯源信息，而每个苹果除了自身维护的信息外，溯源时还需要得到所属苹果树和物流包的溯源信息。因此，苹果主体的Meta字段中，有一个额外的previous属性。该属性是该苹果的所有额外信息源的编号。在对苹果进行溯源查询时，递归地查询该列表中的所有编号，将额外信息源的溯源信息与苹果的溯源信息合并。 存在两个可能改变该previous属性的时间点。果树采摘操作时，在所采摘苹果的previous属性中添加该果树的唯一编号；苹果打包成物流包裹时，在这些苹果的previous属性中添加该物流包的唯一编号。 5.3. 实现结果 在本应用系统上为苹果树建立数据时，会为该苹果树生成唯一编号和对应的二维码。果园员工将该二维码贴在果树上，每当对果树进行操作或观察到果树进入新的生长阶段，扫描二维码，进入如图6所示的果树数据录入表单页，将过程和结果录入进去。 图6. 溯源信息录入界面(部分) 在二维码中，编码了溯源查询网站的链接，并把产品的唯一标识码加密地编码在内。任何用户只要扫描二维码，就可看到对应实体的溯源信息；任何登录系统的操作员，只要通过系统提供的页面扫描二维码，就可进入对应的数据录入页面。对于气温、空气湿度等易于智能监控的生长数据，通过物联网设备进行数据采集，发送给系统自动上链。 当果树上的苹果成熟，扫描果树二维码，可生成对应数量的苹果唯一编号与二维码。 在采摘到的苹果的简易包装上贴上苹果的二维码，每当对该苹果进行加工操作后，扫描二维码，将结果录入进系统内。 当苹果准备打包装箱时，操作员进入系统，生成物流包所对应的唯一编号与二维码。将二维码贴到包裹上，扫描二维码，进入物流包溯源页，扫描每个要被打入包中的苹果的二维码，为这些苹果的previous属性添加该物流包的编号。物流包打包完成后，中间层会定时调用物流公司的物流查询接口，如有物流进度更新，自动将物流数据录入。 消费者收到苹果后，可以扫描其上的二维码，看到如图7所示的从果树到苹果到物流的完整溯源记录。 图7. 溯源查询界面(部分) 5.4. 性能测试与分析 本节进行性能测试。将系统部署在一个具有4核1.5 Ghz CPU、16 GB内存的主机上，在中间层模拟用户行为，持续向区块链网络发送上链事务请求。完成固定上链事务请求数的平均所用时间和单个请求的平均延迟如表1所示。从表1可以看出，该系统在该环境下的吞吐量能够稳定在100 TPS以上，具有承载溯源应用的能力。 在本文的系统中，单个功能可能需要顺序地进行多个请求，响应时间随请求数线性增长。基于3.3节的思路，本文对该系统的业务代码和链码设计进行了优化。优化前后部分功能的区块链事务请求数如表2所示。从表2可以看出，需要多次请求的功能都被降低为仅需1或2次请求，有效提升了大规模数据上链和查询的速度。 Table 1 Statistics on the time taken by the system to complete the fixed reques 完成上链请求/次 所用时间/秒 平均响应时间/秒 10，000 96 3.5 20，000 187 3.4 30，000 297 3.6 40，000 388 3.6 50，000 491 3.7 表1. 系统完成固定上链请求所用时间统计表 Table 2 Comparison of the number of blockchain requests before and after optimizatio 功能名称 优化前请求数/次 优化后请求数/次 果树信息上链 1 1 苹果采摘上链 2 1 为n个苹果树建码 n 1 为n个苹果打包装箱 2n 2 表2. 系统功能优化前后上链请求数对比 5.5. 安全性分析 本节结合场景特点，从业务层面和数据层面展开分析，从安全角度评估本文所提出的方案的可行性。 业务逻辑集中于中间应用层，中间应用层是传统的Web应用。在传统Web应用中，存在许多常见的安全威胁，如XSS攻击、CSRF攻击、流量劫持、钓鱼攻击等。对于这些威胁，都可以由传统Web应用已有的防范措施进行应对。 溯源数据存储在区块链网络中，这些数据的真实性、完整性和隐私性是溯源可信的基石。对于真实性和完整性，中间层作为传统的Web应用，以RBAC确认用户的操作权限；所有向联盟链网络请求都由发起请求的用户私钥进行签名，并且请求用户和请求内容都符合链码的背书策略，保证了相关信息来源的真实性；在此之外，由Hyperledger Fabric提供的CA和MSP (Membership Service Provider)等机制可以确保链上数据无法被伪造或篡改。对于隐私性，依照不同的保密要求，利用多Channel实现不同种数据的隔离，联盟内的成员只能访问有权访问的数据，保证成员的隐私信息。综上，在数据存储层面，可以认为存在足够的安全保障，使得溯源数据高可信。