基于云平台的区块链组网方案及数据共享存储机制

　　摘要:为解决在区块链上进行数据存储和共享过程中面临的交易确认效率低以及存储空间利用率低的问题，本文提出一种基于云平台部署的区块链组网方案以及与其适配的数据共享存储方案。首先，通过对传统的全连接区块链组网进行分解和重构，形成一种基于子网的非全连接组网方案，将交易确认的范围限定在有限的节点之内。

　　其次，通过将数据依次划分为事务数据-敏感状态数据-非敏感状态数据3个层次进行管理，节点只保存与状态转移相关的事务数据以保障不可篡改性，状态数据则在云平台上实现不同程度的共享存储，最大限度优化了存储空间。实验结果表明，该方案可为区块链中可信数据的存储和共享提供新的思路。

　　关键词:云计算;区块链;数据共享

　　0引言

　　近年来，区块链成为了社会的热点话题，它通过将点对点传输、分布式数据存储、共识机制、加密算法等技术进行集成，具有不可篡改、可追溯、去中心化等特性，这些特性使得区块链非常适合用于对可信数据进行存储和共享。

　　目前关于区块链数据存储和共享机制的相关研究，主要面临2个问题:1)交易确认效率问题。由于区块链每次状态的更新都需要得到全网多数节点的确认，形成共识，并向各节点广播实现账本的全网同步，因此网络中参与的节点越多则交易确认的速度越慢。2)存储空间利用率问题。由于区块链具有不可篡改不可删除的特性，因此存储在区块链上的数据只会随时间不断增长，长期下来对存储空间的开销极大。

　　通过引入云计算的相关理念，可以在一定程度上改善上述问题。区块链与云计算结合，称为区块链即服务(BlockchainasaService，BaaS)[1]，它可以有效降低区块链部署成本，用云计算快速搭建区块链服务。2015年11月，微软在Azure[2]云平台里面提供BaaS服务，并于2016年8月正式对外开放。开发者可以在上面以最简便、高效的方式创建区块链环境。

　　IBM[3]也在2016年2月宣布推出区块链服务平台，帮助开发人员在IBM云上创建、部署、运行和监控区块链应用程序。国内的阿里云[4]、腾讯云[5]等也相继提供了BaaS服务。本文提出一种基于云平台部署的区块链组网方案以及与其适配的数据共享存储方案，其主要有3个方面特点:1)引入了非全连接组网的思路，将交易确认的范围限定在有限的节点之内。2)根据敏感程度对数据进行分层存储，在保留不可篡改性的前提下，提高了存储空间利用率。3)针对云计算环境下的部署进行设计，使得用户可以通过云平台快速地搭建区块链服务，降低部署成本。

　　1相关工作

　　关于区块链数据的存储和共享机制，国内外有很多相关的研究，这些研究探讨了在不同应用场景下如何在区块链上存储可信数据，一方面充分利用区块链不可篡改的特性保证数据的安全性，另一方面还需要在保证隐私的前提下将存储在链上的数据共享给具备访问权限的用户。文献[6]研究了医疗数据的共享模型，采用改进的DPOS机制实现节点之间的共识，通过自定义的一套层级存储结构，最后将所有数据Merkle根锚定到比特币区块链，实现真正的不可篡改和不可抵赖。

　　文献[7]研究基于联盟区块链实现智能电网数据的存储和共享，文中以数据采集基站作为区块链的节点，对无线传感网络的数据进行采集、审计和存储，进而在网络节点中进行共享。数据的“记账权”需要在预选的节点之间通过POW机制进行竞争获取。文献[8]研究了人文社科数据共享模型，使用HyperledgerFabric区块链框架作为联盟链的基础，并对区块的数据存储方式进行了改进，用关系型数据库的存储方式替代传统超级账本的键值对数据存储方式，以提升链上数据的查询处理能力，提高人文社科数据共享平台的溯源追踪效率。

　　文献[9]设计了BBDS系统，为储存在云平台中的共享医疗数据提供数据来源、审计和控制，主要解决了在无信任环境中医疗数据的共享问题。该设计采用智能合约和访问控制机制来有效地跟踪数据的行为，并在检测到对数据的权限的违反时撤销对违规实体的访问。文献[10]建立了一个基于HACCP(危害分析和关键控制点)、区块链和物联网的实时食品追踪食品供应链可追溯系统，为所有供应链成员提供开放性的信息平台。

　　供应链中的数据通过BigchainDB进行存储，BigchainDB[11]是由TrentMcConaghy等人提出的一种高可扩容性的区块链数据存储架构，它继承了分布式数据库的特征:吞吐量和容量可根据节点数量线性扩展，提供全功能NoSQL查询语言，具备较高的查询效率和完善的权限控制机制。

　　文献[12]提出了一种基于云计算的物流区块链模型，通过结合区块链共识机制及Hadoop分布式存储技术，设计了CloudPBFT算法，其相比经典PBFT算法在吞吐量以及网络延迟时间方面均有所提升。上述的相关工作均在不同程度上改善了交易确认效率和存储空间利用率的问题，但也存在一定的局限性。从4个角度将本文方案与上述几种研究成果进行对比评估。

　　本文方案在交易确认效率和存储空间利用率上占优的原因在于:1)采用了非全连接的组网方案，状态的更新不需要得到全网多数节点的确认即可达成共识，从而减少了网络请求量。2)采用了基于云平台的数据分级存储的机制，一方面节点只需要保留少量能够保障不可篡改性的事务数据，另一方面将可共享的状态数据做进一步的压缩存储，达到了更高的空间利用率。

　　2基于云计算的区块链组网设计

　　2.1当前主流的区块链组网方案

　　在主流的区块链架构里，设计者们都追求模型的泛化能力(generalizationability)，试图在一个软件层面的框架里，提出一种通用的方法，来解决分布式网络的节点间的公共状态的同步和更新问题，而这种方法通常称为共识算法。当前主流的共识算法包括以数字货币为代表应用的公有链中使用的POW[13]、POS[14]和DPOS[15]算法，以及联盟链中使用的PBFT[16]、RAFT[17]、Paxos[18]算法等。

　　共识算法的研究通常偏向理论化，其假设任意节点间完全连通且也有必要连通，另外，其假设节点间的信息交互是完全随机的。全连接模型中，每次状态的更新都需要得到所有成员的确认。在通常的客户端-服务器模型中，如果某个节点需要更新N个状态，其只需向服务器发送N次网络请求即可;但在全连接网络中，相应的节点每更新一个状态，其均需向其他所有节点广播一次网络请求，总共的网络请求量为N×(M-1)，其中，M为分布式网络的节点总数。

　　当节点总数增加时，交易确认的效率不可避免地受到影响。基于这个考虑，本文将研究现实世界中不同实体间真实的连接关系，尝试建立一个新的结构化模型，在网络拓扑层面实现共识算法。

　　2.2一种非全连接的区块链组网思路

　　2.2.1结构化模型

　　所有的算法模型都是模拟自然界或人类社会的行为的，而不论自然界还是人类社会的个体之间，很少有一个个体会和其他所有个体都有交互作用，即全连接模型是几乎不存在的。通常的情况是，每个个体只与若干个个体有较为紧密的接触，也就是说，实际的模型是一个由若干个稀疏图组成的集合。

　　在实际的网络拓扑结构中，图与图之间是没有任何联系的，它们之间没有数据交互。因此，在不同图之间没有必要存储其他图的内部数据，这是在网络结构层面实现共识的第一个步骤。在每一个图的内部，节点间的数据交互关系可以归结为2种基本模型，分别为单一的主从关系和互为主从关系。其中箭头所指向的节点称为“父节点”，箭头发出的节点称为“子节点”。在单一主从关系模型中，每一次对账本的“写”请求只从父节点发出，子节点只负责对父节点的请求进行校验。

　　当然，最终能否对账本进行合法的写操作，由父子节点共同决定。供应链是典型的以单一主从关系为主的结构，数据基本上是单向流动的，比如交易只能由供应商发起，由客户进行确认。在互为主从关系模型中，每个节点都可以随机发起写请求，不存在明显的隶属关系。微信这类即时通信工具属于典型的互为主从关系模型，通信双方都可以随时对账本(聊天记录)进行“追加写”操作。

　　严格来讲，互为主从关系模型也可以分解为2个独立的单一主从关系模型。是否有必要再进一步细分，可以根据网络的规模和节点间交易的相关程度来决定。一般来说，网络规模越大、交易的相关程度越低，越需要细分。

　　在人类社会的经济活动中，单一主从关系模型是主流，即生产关系是比较稳固的，改变的频率较小。随着节点数的增多，以互为主从关系模型为基本组件的结构，在实际事务中将会越来越少。当遇到一个实际问题时，需要分析节点间的逻辑关系，确定具体的实施方案。基本的实施方案主要有2种:1)混合使用2种基本模型进行建模;2)将事务全部分解成单一主从关系进行最终的合成建模。本文的研究将以后一种方案为主。

　　2.2.2模型的分解和重构

　　根据上节的分析，本文将基于单一主从关系模型对现实的经济活动进行分解，形成一系列较小的结构，并按照一定的顺序将这些结构重新组合，从而达到将网络结构清晰化、交易流程有序化的目的。本文的最终目标是将整个网络的数据流进行分类处理，而数据流动的方向是通过“边”来表示的，即需要将原来网络(简称“原图”)中的“单向边”进行重新整理。

　　因此，基于原图进行重构的新图必须囊括原图的所有边(每条双向边需拆分成2条单向边)。首先将原图的长路径截短，并将所有指向同一个节点的边归为同一类，从而形成一个个基本的单层结构，可将其称为“原子树”，寓意为不再细分的树。

　　一种可行的做法是，依次扫描原图，找出所有父节点(即存在若干箭头指向的节点)，并以各个父节点为基础对原图进行划分。然后依次找出每个父节点的子节点，并最终形成若干棵原子树。其中节点1、2、3是原子树的父节点，各棵子树间通过“信使节点”连通，即节点2和3。显然地，能成为信使节点的节点必须同时邻接至少一条“入边”和“出边”。

　　2.2.3组网方案设计

　　每一棵原子树中的每一个节点都在共同维护着树内的数据流，这些数据流有比较大的关联性，因此，可将原子树内的交互数据全部写在同一个分布式账本里，原子树内的节点共同组成了一个区块链网络，本文将其称为子网。每个子网需包含如下几个基本角色:1)授权认证节点。即CA，主要采用数字证书机制对网络中成员身份进行管理。2)普通节点。发起交易或对交易进行签名背书。

　　3)排序节点。对收到的合法交易在网络中进行全局排序，并打包成区块。4)全节点。对区块进行合法性验证并维护整个账本。另外，经过授权的外部节点或客户端可以获得对账本的部分或全部数据的访问权。由上文可以看出，每新建一个子网，都需要为其分配全节点和排序节点，而由于在云计算环境下，可以非常灵活地分配虚拟机资源并通过脚本实现自动化部署，因此该组网方案在云计算环境下可以达到最高的运作效率。但需要说明的是，在非云计算环境下，组网方案依然是可行的。

　　其中较粗的箭头表示不同的模块之间的信息交互，较细的箭头指示的是模块内的信息传递过程。实线表示该交互过程是主要的，虚线表示该交互过程处于次要地位。

　　3基于云计算的区块链数据存储机制

　　3.1数据存储架构设计

　　本文中数据存储架构的思路来源于HyperledgerFabric[19]项目，这是由IBM牵头发起的一个代表性的联盟链项目。在Fabric中，账本是一系列有序的、不可篡改的状态转移记录日志。状态转移是链码(chaincode)执行(交易)的结果，每个交易都是通过增删改操作提交一系列键值对到账本[20]。一系列有序的交易被打包成块，这样就将账本串联成了区块链。同时，一个状态数据库维护账本当前的状态，因此也被叫做世界状态。账本状态数据库实际上存储的是所有曾经在交易中出现的键值对的最新值。

　　调用链码执行交易可以改变状态数据，为了高效地执行链码调用，所有数据的最新值都被存放在状态数据库中。就逻辑上来说，状态数据库仅仅是有序交易日志的快照，因此在任何时候都可以根据交易日志重新生成。本文基于这种思想，结合云计算的特性进行了一定的拓展，形成了一种基于云计算的区块链数据存储机制。该机制将需要存储的数据拆分为事务数据和状态数据这2个部分。

　　事务数据即包含与状态转移相关的关键内容，目的是为了保障整个网络的保序性和不可篡改性，通过区块链结构进行存储，一个区块中应包含如下字段:1)交易详情。指示在相关节点间实际发生的业务。2)交易的生成者标识。指示该交易是由哪个节点生成的，即生成者的完整签名。3)交易的验证者标识。交易的接收方确认交易详情和其生成者标识是合法的，对交易进行最终的签名。4)前一区块的唯一标识。指示当前区块数据是追加在哪一个区块后面的，该标识通常是前一区块序列化后的哈希值。

　　5)区块号。指示当前区块是全局的第几个区块。6)当前区块的唯一标识。当前区块序列化后的哈希值。7)区块类型。指示当前区块的种类，比如普通区块或者创世区块。状态数据与上文提到的世界状态概念相似，为整个子网的全局状态。Fabric中提供了LevelDB或CouchDB这2种方案供选择，然而这2种数据库能支持的查询方式较少，不能很好地满足商业级应用复杂的查询需求。

　　事实上，可以认为只要能通过事务数据来保障账本的不可篡改，状态数据完全可以通过其他性能更好的数据库来存储。考虑到实际应用中，用户对于数据的加密级别会有不同的要求，因此状态数据中又可以分为仅限子网内部成员可见的敏感数据，以及可以与外界共享的非敏感数据。

　　节点A和节点B组成了子网1，节点B和节点C组成了子网2。其中节点B同时存储了2个子网的事务数据。2个子网分别配备有全节点集群，用于存储子网中的敏感数据，这部分数据由子网内的节点共享，而对于各个子网的非敏感数据，可以在全网数据共享服务器集群存储。本文方案中的状态数据均通过部署在云服务器上的HBase数据库进行存储。

　　Hbase[21]是一种分布式、面向列的开源数据库。该技术来源于Chang所撰写的BigTable[22]论文，是一种面向海量非结构化数据的高性能存储方案。HBase支持基于Snappy[23]算法的压缩存储功能，可以最大程度节省存储空间。同时，由于节点拥有与状态变更记录直接相关的事务数据的所有权，因此依然能够有效地防止状态数据被篡改的情况。

　　3.2典型流程分析

　　3.2.1子网组建流程

　　步骤1所有类型的节点加入网络前，都需向CA申请相应的证书。步骤2当一个节点想创建一个子网时，其先从CA处获取相应成员的证书、IP、权限等，并根据IP向其他节点发起组网请求。步骤3组网规则(比如全部节点同意)通过后，由发起初始请求的节点生成经过签名的创世区块，并为子网分配排序节点和全节点。

　　3.2.2数据存储流程

　　步骤1子网内的任意节点生成一条交易/记录的前提是已经向CA申请了相应的证书以证明其身份。步骤2子网内的节点发起的交易，根据该交易涉及的子网内的成员的数量，需要相应的节点对该交易都进行签名。比如，节点A发起涉及A、B、C的交易，那么该交易必须含有A、B、C的全部签名才是合法的，此时不能离线交易，如果该交易仅仅涉及A自身，该交易可离线进行。

　　步骤3收集所有的签名后，节点A将带有序号(指示当前是全局的第几个交易)的该交易发往排序节点，排序节点通过共识/容错算法，返回接受或者拒绝的响应。步骤4如果排序节点接受该交易，那么将该交易进行签名并与交易内容的哈希一起广播至所有节点，此时相当于所有节点同步新增一条事务数据。步骤5与上一步骤同时，排序服务器会将交易分为敏感数据与非敏感数据2种类型，敏感数据提交至子网的全节点服务器存储，非敏感数据提交至全网数据共享服务器存储。

　　3.2.3数据查询流程

　　步骤1节点通过客户端发起查询请求，节点所属的节点首先验证客户端的身份和权限。步骤2如验证通过，分别向全网数据共享服务器和子网全节点服务器发起查询。步骤3步骤2中的2类服务分别返回请求的敏感及非敏感数据字段信息，节点服务器将其组合后，取哈希值与自身存储的事务数据进行校验。步骤4节点将数据返回给客户端。

　　4实验与分析

　　4.1实验数据

　　本文所提出的非全连接组网方案为模拟人类社会行为所设计，因此在使用现实存在的数据模型进行实验时可以达到最佳的效果。供应链是区块链技术当前较为热门的应用场景，同时也是一种典型的以单一主从关系为主的结构。在供应链上，数据基本上是单向流动的，交易由供应商发货，由客户进行确认。

　　笔者所在机构在本文基金项目资助下在广州市多个肉菜批发市场及农贸菜市场对基于区块链的农产品溯源模式进行了一系列的探索，形成了一套包括至少3个层级，100个节点的供应链基础数据模型，代表了从上游供应商-运输方-批发商-零售商的相互关系。

　　供应链基础数据模型中，每个上游节点可以看做是一个子网的父节点，其下游即为子节点，同时下游本身如果与更下游进行交易，则其自身又可以成为父节点。通过非全连接模型，就可以将一条庞大的供应链拆分成一个个子网，下文中将基于该模型进行测试和分析。

　　上文提到的农产品供应链溯源应用中，数据主要存储在以下5个表中:1)Product。当前节点的主营产品信息，包括产品名称、产地、价格等，这部分数据加密存储在子网全节点服务器中。2)Customer。当前节点的客户信息，包括客户名称、联系电话、身份证号、营业许可等，这部分数据加密存储在子网全节点服务器中。3)Supplier。当前节点的供应商信息，包括供应商名称、联系电话、营业许可、经营范围、地址等，这部分数据加密存储在子网全节点服务器中。

　　4)Purchase。当前节点的进货记录，包括进货单号、交易日期、进货明细(包含商品、批次、数量、价格等)、供货商、总价、运输物流单等。其中日期、商品、数量等在不暴露节点身份的前提下并非敏感数据，因此可以存储在全网数据共享服务器中，其余信息加密存储在子网全节点服务器。5)Sale。当前节点的销售记录，包括销售单号、交易日期、销售明细(包含商品、批次、数量、价格等)、客户、总价、运输物流单等。其中日期、商品、数量等在不暴露节点身份的前提下并非敏感数据，因此可以存储在全网数据共享服务器中，其余信息加密存储在子网全节点服务器。

　　4.2实验环境

　　本文全部应用均基于云平台进行部署，根据子网的组建情况动态分配排序服务器和数据库服务器。

　　4.3实验结果

　　为了验证本文所提出方案的可行性，下面分别对比了使用全连接组网方案以及本文的非全连接组网方案在不同节点数量情况下的吞吐量，以及使用经典的区块链数据存储方案以及本文提出的3级数据共享存储方案的存储空间效率情况。

　　4.3.1吞吐量对比

　　将供应链基础数据模型中的100个节点进行拆分，分别测试不同节点数量使用全连接组网方案以及非全连接组网方案的吞吐量情况。全连接组网方案在节点数较少的情况下吞吐量较高，但是随着节点数增加吞吐量会大幅下降，其原因在于，全连接模型中，相应的节点每更新一个状态，均需向其他所有节点广播一次网络请求，总共的网络请求量为N×(M-1)，其中，M为分布式网络的节点总数，因此节点数量越多，交易确认的时间越长，吞吐量也就越低。

　　而非全连接组网方案由于将一个大的全连接网络拆分成了不同的子网，并且交易只需要得到相关方的确认而非所有节点的确认，因此在节点数增多时，其吞吐量的下降趋势并不明显。在100个节点的情况下，非全连接组网吞吐量达到了全连接组网的8.8倍。

　　5结束语

　　本文针对在云计算环境下的部署区块链的方案进行了一定的优化，提出一种新的区块链组网机制，提高了网络的整体吞吐量;同时通过引入基于云计算的数据共享存储，最大限度优化了存储空间。后续将在本文理论基础上继续深入研究，方向包括:不同数据共享模型应用在区块链数据存储时的存储空间、查询延时、吞吐量的对比;各种意外状况下(节点离线、恶意节点攻击、分叉等)该模型的抗风险能力等。

　　参考文献:

　　[1]SAMANIEGOM，DETERSR.BlockchainasaServiceforIoT[C]

　　[2]Microsoft.AzureBlockchainSolutionArchitecture[EB/OL].[2019-07-15].

　　[3]IBM.TheIBMBlockchainPlatform[EB/OL].[2019-07-15].

　　[4]阿里巴巴.阿里云区块链服务[EB/OL].[2019-07-15].

　　[5]腾讯.腾讯云区块链服务[EB/OL].[2019-07-15].

　　[6]薛腾飞，傅群超，王枞，等.基于区块链的医疗数据共享模型研究[J].自动化学报，2017，43(9):1555-1562.

　　[7]吴振铨，梁宇辉，康嘉文，等.基于联盟区块链的智能电网数据安全存储与共享系统[J].计算机应用，2017，37(10):2742-2747.

　　[8]谷俊，许鑫.人文社科数据共享模型的设计与实现———以联盟链技术为例[J].情报学报，2019，38(4):354-367.

　　区块链组网方案投稿刊物：自动化学报(月刊)创刊于1963年，是由中国自动化学会、中国科学院自动化研究所共同主办的高级学术期刊。刊载自动化科学与技术领域的高水平理论性和应用性的科研成果。