0 引言

随着互联网数字经济的快速发展, 资产数字化越来越受到关注.仓储物作为实物资产的重要组成, 往往依托电子仓单交易实现资产数字化.仓单是保管人收到仓储物后给存货人开付的凭证, 除作为提取仓储物的凭证外, 还可以通过信任背书, 转让仓单项下货物的所有权.但是在当前的仓单业务中, 往往需要第三方机构背书, 这种方式通常会增加交易的成本, 降低效率; 且采用传统的集中式数据存储方式, 数据安全难以保证.同时, 行业内存在背书机构信任不足、货权交易频繁带来的溯源困难等诸多行业痛点.

区块链的出现, 为上述问题的解决带来了可能. 2008年, 署名为中本聪的学者在一个密码学讨论组上发布了一篇名为《比特币:一种点对点式的电子现金系统》的论文, 文中首次提出了区块链的概念, 并以此为基础设计了一种不需要第三方中介机构(如银行、支付平台等)参与的自组织、去中心化、去信任化的电子现金系统^[1]. 2013年, Buterin发表了以太坊白皮书^[2], 支持可编程的智能合约, 区块链进入2.0时代. 2014年, R3区块链联盟成立, 致力于制定银行业的区块链行业标准与协议^[3]. 2015年Linux Foundation发起了Hyperledger Project^[4], 目的是要共同建立并维系一个跨产业的、开放的、分布式账本技术平台.区块链是一种按照时间顺序将数据区块以顺序相连的方式组合成的一种链式数据结构, 并以密码学方式保证的不可篡改和不可伪造的分布式账本^[5].区块链通常分为数据层、共识层、合约层和网络层.数据层采用块链式数据结构来存储和验证数据; 共识层采用如POW(Proof of Work)、POS(Proof of Stake)、PBFT(Practical Byzantine Foult Tolerance)等共识算法来保证节点数据的一致性; 合约层采用自动化脚本构成智能合约来控制交易过程; 网络层采用采用P2P(Peer to Peer)网络来组织分散的节点, 并利用密码学的方式保证数据传输和访问的安全.总地来说, 区块链本质上是一种基于P2P网络的去中心化、去信任化、不可篡改的分布式数据库.

本文利用区块链高度透明、去核心、集体维护、去信任、不可更改和伪造的特点, 设计实现了基于区块链的仓单管理系统, 有效地解决了传统仓单业务中数据集中式管理方式带来的问题, 同时保证了数据的可追溯和不可篡改.考虑到区块链中状态数据使用的是Key-Value存储方式, 本文在系统中构建了倒排索引, 以提高非主键值的查询效率, 且支持复杂查询.同时, 本文系统实现了基于REST的微服务架构, 为多方接入提供了灵活接口, 也为企业已有系统的集成及Web端、移动端的实现提供了友好支持.

1 区块链技术

区块链是一种按照时间顺序将数据区块以顺序相连的方式组合成的一种链式数据结构, 如图 1所示.由图 1可知, 区块由区块头和交易日志两部分构成, 其中区块头中会记录前一个区块(父区块)的哈希值, 区块与区块间通过哈希链连接起来, 这样把每个区块连接到各自父区块的哈希值序列就是一条一直可以追溯到第一个区块(创世区块)的链条.可以看出, 区块链上任何一个区块的更改, 都会影响到该区块的所有后续区块, 当一个区块后链有很多区块后, 这样的重新计算需要耗费巨大的计算量, 也就保证了区块链数据的不可篡改性.节点间依靠P2P网络连接, 并运用共识协议保证不同节点间数据一致.例如比特币系统, 采用POW算法, 主要原理是让全网节点解密哈希难题, 最先算出该问题的节点作为"优胜者", 可以获得一定数量的比特币作为奖赏, 同时获得优先记账权, 将网络上发生的交易优先记录到本地的区块上; 之后, 再把区块信息同步到所有其他全节点上; 其他节点在收到"优胜者"节点发出的区块信息并且验证通过后, 就直接进行下一次"挖矿", 这也就保证了每个全节点上的数据一致性.

2 系统设计 2.1 区块链开发方案的选择

通过前期广泛的调研, 并结合仓单业务的需求, 本文主要了解了以下3种开源的区块链平台.

超级账本Hyperledger: Linux基金会2015年发起的区块链开源项目, 提供分布式账本平台, 支持各种增值解决方案的开发, 以智能合约为中心, 商用情形考虑比较周到. Hyperledger适合联盟链、私有链的构建, 平台设计了独立的CA(Certificate Authority)节点, 支持完善的权限管理机制.

以太坊Ethereum:开源的区块链底层平台, 支持可编程的智能合约.开发人员通过编写符合业务需求的智能合约就能够在以太坊平台上开发和发布分布式应用.以太坊自身实现了一套图灵完备的脚本语言EVM (Ethereum Virtual Machinecode)语言, 用户使用高级语言编程, 再通过编译器转换成EVM语言运行在EVM虚拟机上.以太坊还提供了丰富的API(Application Programming Interface)和接口, 且在算法、智能合约和账本扩展性有较大改善.

瑞波Ripple^[6]:世界上第一个开放的支付网络, 瞄准细分应用场景, 银行间的直接转账、外汇兑换和跨境支付结算.目前未考虑智能合约、隐私和监管支持.

目前区块链按照节点组织方式分为公有链、联盟链、私有链.考虑到仓单业务场景中, 参与成员多、业务较复杂、货物价值大等特点, 比较符合联盟链的组织方式, 即只有获得授权的成员方可加入网络.且信息选择性公开.同时, 仓单管理系统还需要较高效的系统性能、良好的安全保证和严格的权限管理.在上述开源平台中, 以太坊开发的应用大多属于公有链, 任意用户都可自由加入网络. Ripple目前只用于支付应用, 但是不支持智能合约, 系统不具有良好的拓展性. Hyperledger平台以智能合约为中心, 设计了独立的CA节点, 能够进行严格的权限管理.所以, 针对上述区块链平台的特点和优势, 结合仓单业务场景和需求, 本文选用Hyperledger平台进行区块链系统开发.

2.2 设计目标

在仓单业务中, 往往存在仓库、平台、监管、物流、银行等多方参与, 业务逻辑比较复杂.当不同成员需要进行数据共享时, 传统解决方案一般是在各方间搭建数据访问中间件来进行数据互换, 这就带来了"一账多记"的问题, 即相同的记录分别被记在多个参与方的账本上.这种方式很容易造成数据的不一致性, 引起争端, 并使得多方数据共享在传统的解决方案中难以实现, 数据追溯也变为不可能.但是在仓单业务中, 高效、安全多方接入是必须, 同时仓单作为保管人收到仓储物后给存货人开付的凭证, 需要频繁地在金融交易中进行流通, 可追溯性会变得尤为重要.因此, 考虑到上述问题和需求, 本文提出以下设计目标.

(1) 系统对多方接入提供友好支持, 各方共同维护同一本公共账本.

(2) 采用严格的权限管理机制, 通过非对称加密方式验证成员身份, 且分配其相应权限.

(3) 提供良好的性能, 及时响应请求, 满足仓单业务的性能需求.

(4) 提供丰富的REST API接口, 为多方接入提供灵活接口, 支持企业已有系统的集成及Web端、移动端的接入.

2.3 业务流程

业务流程如图 2所示, 货主可以根据需求提出仓单的申请, 但必须在货主仓储物资产价值内.仓库审核仓单申请所填的仓储资产情况, 如实批准或拒绝该申请.监管公司进行商品质检和仓储资产确认, 批准或拒绝该申请.平台对仓单进行登记, 并根据仓库和监管的审核意见, 决定批准或拒绝该申请.仓库、监管、平台分别审核, 只要有一方审核失败, 则此次申请不通过并反馈货主; 若三方都审核通过, 则生成仓单.

2.4 系统架构

整个系统的设计采用了3层应用架构, 如图 3所示, 分别为应用层、服务层、数据层.应用层提供用户的操作功能页面; 服务层负责应用层和数据层的交互; 数据层则是提供存储的区块链系统.

2.4.1 数据层

数据层是由区块链提供的分布式存储, 采用开源项目Hyperledger Fabric进行开发.区块链网络是由4个Peer节点和1个Membersrvc节点构成的P2P网络. Membersrvc是权限管理节点, 用来验证区块链网络中Peer节点的身份合法性, 所有Peer节点都要向Membersrvc节点注册. Peer节点分为Validating Peer和Non-validating Peer: Validating Peer负责达成共识, 验证、执行交易并维护总账; Non-validating Peer只会验证交易, 并不执行, 节点间通过PBFT算法保证数据一致性.数据层的主要作用是存储仓单业务中的审计数据, 并且确保数据不可篡改、仓单历史可追溯.

2.4.2 服务层

服务层作为数据层和应用层的中间层, 向上为应用层提供丰富的REST API, 向下将应用层的逻辑操作转换成对数据层区块链网络的操作.服务层还有成员管理、索引机制、事件机制、合约管理等功能.成员管理主要功能是对成员进行授权和验证; 索引机制是维护系统中的索引; 事件机制是响应系统中发生的事件; 合约管理是执行合约的部署、更新和销毁.

2.4.3 应用层

应用层为多角色的Web系统, 角色分为货主、仓库、监管、平台. Web系统选用Spring-side框架, 并对其进行扩展和定制.应用层加入了严格的权限管理机制, 结合Bootstrap作为前端UI框架, 提高了系统的交互性.主要功能如下.

(1) 权限管理:运用Apache-shrio框架对用户进行身份验证和授权.

(2) 仓单申请:货主可以根据需求提出仓单的申请, 但必须在货主仓储物资产数量内.

(3) 仓库审核:仓库审核仓单申请所填的仓储资产情况, 批准或拒绝该申请.

(4) 监管审核:监管公司进行商品质检和仓储资产确认, 批准或拒绝该申请.

(5) 平台审核:平台对仓单进行登记, 并根据仓库和监管的审核意见, 决定批准或拒绝发布仓单.

3 关键技术 3.1 仓单业务到区块链的映射

在传统的仓单业务系统中, 应用层业务操作映射到数据层就是对数据库中相应表的操作.而在区块链系统中, 情况会变得复杂.区块链上的数据分为交易数据和状态数据.交易数据记录的是交易的参与双方及交易详细内容; 状态数据是指交易发生后, 交易双方的账户状态数据.它们的存储方式也不同, 状态数据保存在Key-Value数据库中, 而交易数据则会保存在区块中, 区块再按照时间戳顺序连接.新的区块生成后, 会通过共识算法来达成区块链系统的数据一致性, 一旦达成共识就不可逆转.在Hyperledger Fabric中, 智能合约是区块链和状态数据交互的唯一渠道, 可视作一段部署在区块链上可自动运行的程序.智能合约会按照事先的约定, 接收和储存价值, 也可以进行价值转移, 由代码强制执行, 完全自动且无法干预.在Hyperledger Fabric中, Chaincode(链码)即为"智能合约", 部署在Hyperledger Fabric的Validating peer上. Chaincode采用Go或Java语言编写, 并通过gRPC协议与相应的Peer节点进行交互.当Chaincode被部署时, 会执行Init函数, 进行仓单数据库的初始化; 货主执行仓单申请操作时, Chaincode会执行仓单创建, 在验证货主身份合法后, 会为货主生成一份仓单申请表; 审核人员在审核仓单给出审核意见时, Chaincode会执行审核操作, 在验证审核人员身份合法后, 记录仓单审核结果.

3.2 倒排索引构建与复合查询

Hyperledger Fabric中, 数据分为状态数据和区块数据.其中, 底层采用的是Key-Value数据库LevelDB^[7]存储状态数据. LevelDB的特点是主键查询速度快, 但是对于非主键数据的查询速度较慢, 而且不能很好地支持较为复杂的查询.而在仓单业务中, 针对仓单内容的非主键查询和如模糊查询等复杂查询是非常必要的.基于上述问题, 本文基于CouchDB^[8]构建了倒排索引, 即一种面向单词的索引机制, 来加快非主键值的查询, 同时支持例如模糊查询等复杂查询.倒排索引是实现"单词-文档矩阵"的一种具体存储形式, 通过倒排索引, 可以根据单词快速获取包含这个单词的文档列表.倒排索引主要由两个部分组成: "单词词典"和"倒排文件", 如图 4所示.

在区块链系统中, 一旦交易经过网络共识后被记录到区块中, 因为区块是不可以被篡改的, 也就意味着共识后的数据不可更改.这样的特性, 避免了表数据更新带来的索引更新的问题, 简化了倒排索引的维护.该功能实现分为Listener模块和Persistence模块. Listener模块有两阶段的工作:第一阶段会实时监听区块链节点, 监测是否有新的完成共识的数据, 如监测到就进入第二阶段; 进入第二阶段后, Listener模块就将数据立即传输给Persistence模块进行数据持久化. Persistence模块是建立倒排索引的关键部分, 实现的主要思路是在CouchDB中维护一张Value-Key索引表, 在接收到Listener模块发来的数据后, 数据会被按照Value-Key的结构倒插入到索引表中, 使得Value变成了新的"Key".在做非主键查询时, 在Value-Key索引表中查询新的"Key"值, 找到原先的Key值, 再用原先的Key值查询得到记录, 这样极大地提升了查询效率.在此基础上, Persistence模块还提供了复合查询, 支持模糊查询和范围查询, 搜索条件可以是仓单审核状态、仓单号、保管单位、仓库地址、存货人等信息.

4 原型系统演示 4.1 环境配置

服务器: 5节点的集群; 含2 TB存储; 千兆以太网; Ubuntu 14.04操作系统.

编程语言: Go(区块链)和Java(网站).

编程环境: JDK 1.8; Spring-side; MyEclipse; Gogland.

4.2 功能演示

(1) 仓单查询模块

如图 5所示, 仓单查询支持根据仓单号的精确查询, 还支持根据仓单审核状态、监管审核状态、平台审核状态的条件查询和根据关键词的模糊查询.例如, 某货主在登录后进入查询页面, 其想查询仓单号为"W20170523162648000", 保存在上海动产测试仓库的货物仓单的审核状态.该货主不仅可以输入仓单号进行精确查询, 而且可以输入仓库地址、存货人等关键词进行模糊查询.模糊查询也支持部分单词查询, 例如输入"2017"进行查询, 即会返回该货主所有2017年申请的仓单记录.

(2) 仓单审核模块

如图 6所示, 用户提出的仓单申请, 加入到仓库的待审仓单列表; 待仓库审核完之后再转交给监管审核; 监管审核完之后, 再转交给平台审核; 平台审核完成后, 仓单审核流程结束.如果货主的仓单申请成功, 上海动产测试仓库管理员的待审仓单中就会增加此条记录.管理员在审核仓库内货物信息真实性后, 决定是否予以通过.如果通过, 则审核人、审核时间等信息就会打包记录到区块中上链, 一旦上链就不可篡改, 然后进入接下来的审核步骤.

(3) 审核完成界面

当仓单审核完成后, 页面有"审核完成"字符提示, 同时会有仓库审核、监管审核、平台审核后的3条记录, 每步审核都会记录在区块链中, 形成可追溯的"审核链", 且可以点击查看详细信息.如图 7所示, 该仓单已是审核完成状态, 在履历标签下分别是仓库、监管、平台的审核记录, 可以点击详情查看审核详细信息, 追溯每步仓单审核记录.

(4) 查看区块详情

区块中记录了审核的详细信息, 包括交易数据、时间戳、数字签名等.如图 8所示, 从该区块详细信息中可以得知, 此区块生成时间是Unix时间"1496027306", 仓单号为"W20170529110654000"的仓单在"2017-05-29 11:07:35"创建, 包含的货物是材质为H234的螺纹钢, 重量为1吨(1 000 kg), 数量为1件, 目前审核状态是"平台已审", 即已审核成功.

5 性能测试

硬件环境: 4台Peer节点服务器; 1台Membersrc节点服务器; 主节点提供REST服务.每台服务器硬件配置如表 1所示.

测试程序采用多线程编程, 每个线程模拟1个Client(客户端)与区块链系统交互, 不断在系统中增加记录.共进行6组测试, Client每组依次递增5个.记录下请求次数、响应时间等实验数据, 计算不同负载下系统的吞吐量, 同时监控服务器CPU、内存、磁盘I/O、网络等资源使用状况.

实验结果如图 9所示, 横坐标是Client数量, 纵坐标是TPS(Transaction Per Second, 吞吐量). Client数量在10到25之间, 服务器未达到硬件瓶颈, TPS稳定提升; 当Client数量在25之后继续提升, TPS趋于稳定, 但到达30时并有略微下降, 此时服务器磁盘I/O达到峰值, 成为系统瓶颈.通过实验结果, 可以得出本系统TPS约为240, 因为仓单业务用户群体小、数量少, 基本能够满足仓单业务场景需求.但是考虑到并发数大的应用场景, 本文实现的系统性能还有很大的提升空间.

6 总结与展望

本文基于区块链设计实现了一个仓单管理系统, 将仓单业务中审计数据记录在区块中, 保证了数据可追溯、不可篡改.在此基础上, 本文在区块链系统上构建了倒排索引, 提高了查询效率, 且支持复杂查询.同时, 实现了基于REST的微服务架构, 支持多方接入.由于研究时间和现有知识水平的限制, 本文的研究工作还不够完善, 需要进一步探索和研究, 作为下一步的研究内容, 将要进行的工作主要有以下几点.

(1) 目前系统吞吐量(TPS)较低, 主要原因是节点共识耗时太长, 下一步工作考虑优化PBFT共识算法.

(2) 支持当新节点加入区块链系统或者节点故障重启后数据快速同步.

(3) 区块链中数据为全备份, 这会占用大量的存储和网络带宽.因此下一步工作将考虑在数据安全、有效的情况下让区块链系统支持分片(Sharding).