Virus Database Chain:联盟式传染病数据区块链系统

黎祖睿 李 强 张 超 陈子豪

(四川大学计算机学院 四川 成都 610065)

0 引 言

如今对急性突发传染病爆发的预测预警是公共卫生领域始终关注的热点问题，世界各国纷纷把发展生物医学大数据作为国家战略，从大数据处理、存储、分析与应用等方面推动生物医学大数据研究的发展。目前国内各大疾病预防控制中心的信息量巨大却又不能互通，产生了信息孤岛。各省市疾病预防控制中心迫切需要一个能够在各地之间实现传染病信息共享，并能够保证信息不会泄露的系统。

在2008年，中本聪[2]在其论文中提出比特币一词。与此同时，区块链技术也逐渐开始推广。区块链是由多个独立节点参与的分布式数据库系统[3]，它能安全地存储比特币的交易信息及各类数据，并保证数据和信息的安全。区块链是多种已有技术(P2P网络、密码学等)的组合。区块链技术可以帮助疾病控制中心和医院等机构快速安全地认证权限，实现自由的数据访问和共享。因此，区块链是目前实现传染病数据存储和共享的绝佳方式。

根据参与者不同，区块链可分为公有链、联盟链和私有链。1) 公有链：任何人都可以参与，每个人都可以读取、发送交易并得到有效确认，也可以参与区块链的共识过程。2) 私有链：在一个实体内部使用，信息不公开的区块链。所有参与到区块链中的节点都会被严格控制。3) 联盟链：由多个实体共同维护、决定，并带有准入限制的区块链，其中实体为企业、银行或医院等任何组织或机构，每个实体可以为一个或多个节点。联盟链相对于公有链，有一定的准入机制和访问限制条件等约束。联盟链相对于私有链则是有多家实体参与，共同维护并能共享信息。

根据传染病数据敏感性和保密性的特性，使得其必然需要一定的政府监管控制。而每个医院和疾病控制中心都是一个实体，这些实体同时受到政府的监督、管理。并且用户应有严格的分级制度和一定的参与限制。每一个传染病数据既是一位患者的个人隐私，又涉及到国家机密，因此传染病数据的访问带有严格的权限限制。根据以上特点可以看出，传染病数据区块链应以联盟链的方式来实现。

目前，多数医疗数据类区块链系统采用POX系列共识机制，而联盟链系统大多选择DPOS与PBFT共识算法。POX系列算法包括：工作量证明、权益证明和股份授权证明。POW算法需要大量算力以防止恶意节点的出现。其余POX算法通过概率选择记账者但降低了潜在的提案者，通过增加提案成本，放宽最终一致性确认的需求，但延长了达成最终一致性的时间。因此都不适合传染病数据存储的需求。本文使用实用拜占庭容错算法，构建了一种只需较少节点，启动代价小，且不需要大量算力和代币来维护的联盟式传染病数据区块链系统——Virus Database Chain(VD Chain)。

1 相关研究

1.1 PBFT共识算法

PBFT算法[1]是在1999年由Miguel Castro和Barbara Liskov所提出，用于解决原始拜占庭容错算法效率问题。该算法将原始拜占庭容错算法的复杂度从指数级降低到多项式级，更切合实际运用[1]。

PBFT是在分布式环境中，解决状态机副本复制问题的算法。该算法可以在失效节点(出现故障或恶意操作)不超过(N-1)/3(N为集群节点总数)的情况下，依然能正确达成分布式共识。

PBFT的节点都在一个视图的轮换中。在某视图中副本节点主要包含三种角色：客户端、主节点和备份节点。一个副本为主节点，其余为备份节点，其中主节点主要用来接收客户端发送的请求消息。视图是连续编号的整数，在编号为v的视图中，主节点由公式p=vmod|R|计算选出，这里v表示视图编号，p表示副本编号，|R|表示存储副本节点的个数。当主节点失效时，需要启动视图更换过程，更改当前的视图编号v，再根据上述公式选出新的主节点。假设副本节点集为R，每个节点的编号分别为：0,1,…,|R|-1，则系统最大恶意节点个数f与R之间的关系为|R|≥3f+1[3]。

PBFT算法共识过程如图1所示。

PBFT算法的共识过程基本流程大致为：

步骤1客户端发送请求给主节点。

步骤2主节点广播请求给其他节点，节点执行PBFT算法的三阶段共识流程。

步骤3节点完成三阶段共识，返回消息给客户端。

步骤4客户端收到来自f+1个节点的相同消息后，代表共识已经正确完成。其中步骤2中的三阶段共识分别为：预准备阶段、准备阶段和提交阶段。

(1) 预准备阶段：主节点收到客户端请求后，给请求分配一个序号n，广播序号分配消息和客户端请求消息，并构造PRE-PREPARE消息发送给各备份节点。

(2) 准备阶段：备份节点接收PRE-PREPARE消息后，对消息进行验证。若通过验证则向其他服务节点广播PREPARE消息。如果验证不通过，则丢弃PRE-PREPARE消息。在一定时间范围内，如果收到超过2f个不同节点的PREPARE消息，就代表准备阶段已经完成。

(3) 提交阶段：各节点对视图内的请求和次序进行验证后，广播COMMIT消息。当收到2f+1个COMMOT消息后(包括自己)，代表大多数节点已经进入提交阶段，这一阶段已经达成共识，节点将执行请求，写入数据。

1.2 智能合约

Nick Szabo[4]于1996年初次给出智能合约的定义：智能合约是用于执行合同条款的计算交易协议，包括合同当事人和执行这些条款的协议。

区块链的出现使得智能合约的执行能够获得可信的环境。比特币交易中的输出条件用脚本描述，这是智能合约的雏形，而以太坊首先实现了区块链和智能合约的结合。通常，智能合约在各方签署后，以脚本代码的形式附加到区块链上，并经过P2P网络和其余节点验证后写入各自节点中[5]。其中合约封装了许多预定义状态、转换规则、触发条件和响应操作等[5]。智能合约的概念模式如图2所示。

图2 智能合约概念模式

1.3 传染病预警

随着全球经济一体化和生态环境的快速恶化，进一步加大了传染病疫情的发生频率。虽然我国暂未受到全球化疫情的影响和冲击，但对难以防控的新发、突发和全球性传染病的蔓延仍需提高警惕。传染病预警是根据收集到的病例、病原体、媒介昆虫等监测资料，对疫情发生的性质、规模、地域、影响因素、危害程度等进行综合评估和预测，以便采取相应级别的预警行动[6]。

传染病预警方法的理论基础是基于数学理论形成的传染病预警理论，主要有信号检测论和决策理论，这两大理论提高了检测和预警系统的及时性、灵敏度和特异度[7]。传染病预警方法是基于传染病流行的三间(人群、时间、地区)分布特点，根据分析数据项的类型将预警模型分为时间、空间和时空模型三大类[8]。

基于病例、症状、病原学、媒介等监测数据建立的传染病自动预警系统已开始应用于疾病监测预警，本文将基于区块链技术为课题的疾病监测预警提供有效的数据支持。

1.4 医疗类数据区块链

目前区块链的实际应用主要在金融方面，因此较为成熟的区块链应用只有比特币、以太坊等。区块链在医疗数据方面的应用相对较少，而侧重于传染病数据存储的区块链系统则暂时没有。

国内，薛腾飞等[9]使用改进的DPOS共识算法提出了一种医疗机构联盟服务器群和审计联盟服务器群相结合的医疗区块链系统MDSM。国外，Azaria等[11]使用以太坊[10]并结合大数据，实现了一个医疗信息共享平台MedRec。Ivan等[12]将区块链作为保护医疗健康数据存储的方法并提出了一个基于区块链存储病人医疗记录的方法。Shrier等[13]结合使用美国麻省理工学院的OPAL/Enigma加密平台和区块链技术，创造了一个用于医疗保健信息存储和分析的安全环境。Kuo等[14]使用隐私保护在线机器学习和私有链技术，实现了一个跨机构的医疗健康预测模型。Witchey[15]介绍了医疗交易单验证系统。对比发现国内关于区块链在医疗方面的应用与研究相对较少，且大多在应用层面上。

1.5 密码学基础

密码学是区块链技术的基础，其中主要包括非对称加密、哈希函数、数字签名和Merkel数等。

非对称加密使用一对公私钥进行加密、解密操作。这对密钥中，公钥对外公开。不对外公开、自己持有的密钥称为私钥。假设A与B之间互相通信，A给B发消息的时候，会将消息的内容用B的公钥加密。同理，在B收到A发送的加密消息之后，会用自己的私钥对消息进行解密。由于B的私钥只有B拥有，所以即便消息被C接收到，C也无法知晓消息的内容。

数字签名利用非对称加密来保证数据的完整性、不可否认性和防伪性[16]。假设A与B之间通信，其详细过程如图3所示。

图3 数字签名原理

2 基于PBFT算法的联盟式传染病数据区块链系统

VD Chain架构自上而下分为应用层、合约层、共识层、网络层与数据层。系统架构图如图4所示。

图4 系统架构

2.1 数据层

数据层是VD Chain的基础，其功能包括数据存储和数据处理。

2.1.1数据处理模块

数据处理模块中使用非对称加密、哈希函数、数字签名和时间戳等技术，其中：哈希函数将区块或交易单的相关内容作为输入，计算出摘要，生成区块ID或交易单ID；非对称加密用以验证交易的合法性，并使通信各方的信息安全传递；数字签名用以确认被签名数据的完整性以及签署人的身份；时间戳是标识某一时刻的技术，表明数据是在什么时间存在的[17]。

区块链是结合上述技术的一种安全可靠的分布式存储技术。区块链系统的安全性抛弃了传统意义上的“信用”而完全基于密码学算法[18]。其中包括：

1) 利用哈希算法(HASH256)来防止交易信息被篡改和验证交易信息的完整性；

2) 利用现代密码学中的非对称加密技术[19]对交易进行签名，防止交易被伪造；

3) 在交易写入区块链之前，为防止个别节点的恶意破坏，全网节点需要通过共识算法达成一致。

区块链系统中数据的修改时，需要系统中半数以上的节点同意，才能进行。即使部分节点的数据损坏、丢失，或者遭到其他恶意节点的攻击，也不会影响整个区块链系统数据的记录和更新，从而确保系统数据的完整性[20]。

2.1.2数据存储模块

VD Chain区块链主要由两部分构成：区块与交易单。一条区块链由若干个记录着前一个区块ID的区块组成，这样一个接一个构成逻辑上的“链”结构。而每个区块又包含了若干交易单，交易单则是实际数据的载体。一个区块的结构如图5所示。

图5 区块结构

一个区块主要由块头和块身构成，块头是需要进行数字签名的部分。区块头包含上一个区块的HASH值、由区块下各交易单生成的Merkle根[21]、生成区块的难度指标和生成区块的时间戳等信息。块身主要包括区块生成者对于区块头的数字签名、区块ID等信息。其中数字签名保证了区块内容不被篡改，并保证恶意区块无法抵赖，确保了区块的真实性。另外，区块中仅保存交易单的ID(即索引)，以便降低每个区块的大小，便于同步与备份。区块和交易单在实际中是存储在数据库中，在逻辑上以区块链的形式来存储。

交易单内容如图6所示。交易单类型是该交易所需进行的操作(增、删、查、改)，验证器集群根据不同的类型进行相应的操作。在增、删、查、改的操作中使用交易单是为了防止某一节点可能的恶意操作。使用者在进行任意操作时需要对交易单进行数字签名，将操作记录在区块链中，使得使用者对于自己进行的操作无法抵赖。交易单内容是该交易单中所存储的内容，如传染病数据信息等。对于哈希算法和编码算法可以选择SHA-256[22]哈希算法或BASE64[21]编码算法保证系统的安全。

图6 交易单结构

2.1.3交易单存储的内容

交易单中存储的内容包括传染病信息、用户信息、各节点的信息等，交易单内容主要有如下几类：

1) 实体信息类。主要用于记录用户实体的详细信息，如名称、简介、权限等级，以及所拥有的密钥中的公钥信息等。主要的用户群体有疾病控制中心、医院、卫生部等机构。对于实体中的隐私信息，如名称、简介等，在存储到区块链之前，会采用非对称加密技术，使用实体公钥对这些信息进行加密，但不加密其公钥信息，方便实体检索自己的信息。在需要查看这些信息时，经实体授权，使用实体自己的私钥进行解密，获取这部分信息。

2) 传染病信息类。主要用于记录区块链上相关传染病信息，如某医院P在某时上传到区块链上的一条传染病病例，包括：病因、宿主、传播途径、地点、时间和信息所属机构等。若包括了图片或视频等信息时，则对产生的图片或视频进行哈希运算获得哈希值，存入到交易单里。这样，当图片或视频被篡改时，其哈希值就会发生变化，与存储在区块链中的哈希值不符，从而保证多媒体资料的防篡改。该条传染病信息所在交易单ID即为该条传染病信息的ID。图片或视频等较大的数据存储在生成节点。

3) 增加、删除、修改、查询类。

增加：交易类型为“增加”，交易单内容为要增加的数据，如传染病信息、病历信息等。

删除：交易单类型为“删除”，交易单内容为被“删除”的交易单ID。“删除”并不是将该交易单从区块链中直接删除，而是进行查询操作，同时检索删除类型交易单，排除该删除交易单中所存储交易单ID所对应的交易单，从而实现“删除”操作。

修改：交易单类型为“修改”，交易单内容为修改前的交易单ID、修改后交易单ID、修改时间和修改原因等内容。“修改”并不是用新的交易单去覆盖旧的交易单，而是修改的时候产生两个交易单，一个是拥有修改过内容的交易单，另一个是记录该交易单ID和被修改的交易单的ID。在查询时，排除被修改的交易单，从而实现“修改”操作。

查询：交易单类型为“查询”，交易单的内容为查询条件。验证器在接收到查询交易单时，同时会检索权限交易单，判断查询发起者是否拥有相应的查询权限，若有权限则返回查询信息，若无则丢弃该查询条件。

4) 权限类。交易单类型为“权限”，交易单内容为具体权限信息，如某疾病控制中心可授权用户在某段时间内查看属于自己的传染病信息，其余时间便不能再查看此类信息。

2.1.4传染病数据存储

VD Chain的数据存储可以同疾病控制中心、医院等的传染病数据系统相结合。利用计算机、网络、数据库等，有机结合疾病控制中心、医院的业务信息和管理信息，实现文字、图像、音频、视频等信息的数字化收集、存储、查询和修改。系统的数据来源于疾病控制中心、医院、卫生部等多方，所有数据分别存储在区块链或数据库中，实现数据共享并保证数据安全。数据之间的存储关系如图7所示。

图7 数据存储

这些数据可分为结构化和非结构化数据。其中结构化数据一般是数值或文字等，这些数据通过添加交易单信息，作为交易单的内容，形成交易单存储在一般数据库中，如Oracle Database、DB2、MySQL等。通过收集交易单ID生成的区块也存储在这些数据库中。通过数据库分片将海量结构化数据分布式存储在节点的各个数据库服务器上，通过数据库备份技术备份这些数据。非结构化数据指的是传染病数据相关的图片和音频数据。这些数据本身数据量较大，不适合在共识过程中进行传输，因此仅将这些数据的哈希值上链。节点在存储这些数据时，首先取其哈希值，作为结构化数据存储起来。

2.1.5一次完整的交易单存储流程

以传染病信息为例，将其存储在一个交易单中最后存储到区块链上的过程如下：

1) 用户使用客户端登录，选择添加传染病病例，并根据提示添加相关信息。该信息包括病因、宿主、传播途径、地点、时间以及信息所属机构等结构化数据和图片或视频等非结构化数据，其中还可能有一些病人个人的隐私信息。

2) 对于交易单中不公开的隐私信息，如个人信息等，用户可利用自己的公钥对该数据项进行加密处理。即使其他用户获得了该交易单，但没有该用户的私钥也没有办法解密被公钥所加密的数据项。

3) 在用户提交信息后客户端将利用哈希算法将所有数据进行哈希运算取得传染病实体的Hash值，生成时间戳，以及此笔交易单的Hash值，随后利用该用户的私钥对交易单Hash值进行数字签名，最后将该笔交易单以及传染病实体发送至与该客户端连接的共识网络中某个共识节点服务器。

4) 服务器将对该笔交易中的时间戳等信息进行初步验证后，将该传染病实体备份在共识节点的数据库中，并根据信息所属机构把图片或视频等非结构化数据存储在该机构的数据库中，最后将交易单发送至共识网络中的主节点。

5) 主节点收集一段时间内发送来的交易单后生成一个区块，将这些交易单信息录入此区块中，再将这些交易单与这个区块通过P2P模式的共识网络发送给所有从节点，从节点与主节点经过共识算法验证此区块以及其包含的所有交易单的合法性后，这笔交易单中的请求将在所有共识节点上执行。

2.2 网络层

区块链网络层是建立在TCP/IP通信协议和对等网络基础上的一个分布式系统。与传统的中心分布式系统不同，它不依靠中心化服务器，而是依靠网络中的每个节点。点对点的网络通信协议、传播机制和验证机制共同构成了区块链网络层的基石。

P2P网络自身有多方面优点，在与区块链相结合的应用中它的优点如下：

1) 去中心化。区块链的资源和服务分布在所有参与节点上，通过共识机制维护区块链网络一致性，无须中心系统的存在。

2) 可扩展性。区块链节点可以自由加入、退出，网络系统根据节点自由扩展。

3) 健壮性。区块链网络没有中心节点，也就没有了攻击对象。参与节点分布在网络中，部分节点遭到破坏对区块链系统无影响。

4) 高性价比。无须昂贵的设备搭建中央服务器，无须支付昂贵的宽带费用，普通用户也可以参与。

5) 隐私保护。区块信息采用广播机制，无法定位广播初始节点，防止用户通信被监听，保护其隐私。

6) 负载均衡。区块链通过限制节点连接数等配置，避免资源负载、网络阻塞。

在最原始的P2P网络中，至少一个Tracker(一台服务器地址)信息和文件的分割记录信息，用户从中心服务器里获得Tracker后根据Tracker返回的信息直接跟其他节点建立联系，开始数据传输。而在去中心化的应用中则需要使用DHT技术。

分布式哈希表(DHT)是一个分布式系统,它提供了一个类似哈希表一样的查询服务。它把键值对存储在DHT中，键值对的映射由网络中所有的节点维护,每个节点负责一小部分路由和数据存储。这样即使有节点加入或者离开,对整个网络造成的影响很小,于是DHT可以扩展到非常庞大的节点。

DHT广泛应用于各种点对点系统,用来存储节点的元数据。比如：BTC系统使用Mainline DHT来维护节点。

本文采用分布式哈希表实现结构化的P2P网络。DHT将P2P网络节点通过Hash算法散列为标准长度数据，整个网络构成一个巨大的散列表。每个参与节点都有一部分散列表，并储存维护自身数据，散列表分布在P2P网络各个节点上。任何接入网络的节点都有散列表中的ID,可以通过DHT寻找更多节点，也可以被其他节点根据ID值精确查找。

2.3 共识层

在一个去中心化的分布式系统中，如何使各节点达成共识这是分布式系统所需解决的问题。共识层则是解决这个问题的关键，本文采用PBFT共识算法使系统各节点达成共识。

2.3.1共识算法

采用PBFT算法作为传染病区块链中的共识算法，是因为PBFT算法是一种适用于联盟链的共识算法，其特点在于：

(1) PBFT算法与POX系列算法达成一致的方式不同，不需要使用大量的算力，不靠代币作为衡量投票权的标准。

(2) PBFT算法在系统中存在小于或等于(N-1)/3个故障或恶意节点时才能保证一次共识过程的正常执行[27]。即系统的节点中，每次共识中至少有(2N+1)/3个正常节点，因此这些节点所运行的环境必须是相对安全、稳定的。

(3) 传染病区块链是联盟链，参与到传染病区块链中的实体大多为医院或政府部门，具有一定公信力，并由中国疾病控制中心、卫生局等多个管理部门严格监管，出现恶意行为的情况远小于其他区块链系统。同时各省市的疾病控制中心及医院具有较为完备的网络、服务器和数据库系统。现有传染病系统能提供一个相对安全、稳定的运行环境供PBFT算法正常运行，因此PBFT算法十分适合传染病区块链。

2.3.2节点管理

一个区块链系统中各节点间最重要的是达成一致的共识算法，除去各节点间的共识过程，它们还分别扮演着重要的功能：验证器，验证交易单和区块；打包器，生成交易单和区块。与比特币的区块链组件类似，VD Chain区块链系统中的节点主要有客户端、验证器和打包器三个组件，如图8所示。

图8 节点管理

1) 客户端。客户端是用来生成交易单的组件。VD Chain链中的删除和修改都不直接操作对应的交易单，而是重新生成一个新的交易单，以覆盖原有的。这是因为区块链中为了保证其可追溯性，所有生成的区块将无法被修改或者删除，只能通过添加新区块来说明对前面区块的修改或删除。客户端主要分为两类：

(1) 管理员客户端。管理员客户端主要拥有的功能是增删改查，医院、疾病控制中心和监督机构均使用此类客户端。在增加方面，可以增加传染病记录。在删除和修改方面，可以删除有错误的传染病记录，或者修改传染病记录中存在问题的地方。在查询方面，可以查询链上所有传染病数据。这些对数据的增加、修改、删除和查看等操作需要在系统授权情况下，且在一定期限内进行。未经授权或授权过期情况下，系统将拒绝执行这些操作，并根据其公钥与数字签名，将其加入到黑名单中。若在授权期间，个别疾病控制中心出现恶意行为，这些恶意行为是极难在区块链中抹除的，此时系统中所存储的错误数据将作为证据，通过国家相关部门进行处理。

(2) 查询信息客户端。查询信息客户端仅具有查询的功能。一些机构可能需要查看传染病数据的相关信息。如研究机构获得审批需要阅读数据时；又或者个别医院、疾病控制中心出现恶意行为时，公安机关或法院需要查看此类记录等，以此为依据做出合理的判断，这时候就需要授予相应的查看权限。

2) 验证器。验证器为PBFT算法中的副本节点，主要用于验证客户端和打包器发来的消息。所有的消息结构如图9所示。验证器接收到消息后，首先校验该消息数字签名是否正确，然后校验其是否符合规定，例如一个用户在未获得授权情况下无法查看传染病数据。校验后，所有节点开始PBFT三阶段共识，完成共识过程后，将该交易单存入自己的数据库中。

图9 消息管理

在一般区块链中，“挖矿”节点(即Virus Database Chain中的验证器节点)分为全节点和轻量级节点。全节点保存了区块链上面所需存储的所有数据，而轻量级节点只保留了部分数据。在VD Chain中，验证器节点均为轻量级节点，每个验证器节点保存所有产生自该疾病控制中心的数据，按照三级存储方式进行存储。对于来自其他疾病控制中心的数据，每个验证器仅保存半年左右。同时每个节点完整地保存区块链的信息。所有传染病数据均同步至各数据管理部门，以备各节点校验时使用。此方式对中心化的传染病数据管理部门有一定程度上的依赖，但减小了每个节点的存储压力。

3) 打包器。打包器将收集来的交易单的ID生成默克尔树(Merkle Tree)打包成区块，再发送给验证器集群。打包器生成区块时需要获得当前区块链最后一个区块的ID，因此一段时间内仅有一个区块生成。在VD Chain链中，每生成一个区块都要经过验证器的校验，若出现恶意区块，则不予接受并生成区块。另外，本区块链部署在各疾病控制中心，网络相对稳定，不会时刻都有节点的加入与退出，并有专门的管理人员，恶意操作的情况较少。因此本区块链系统通过以下的方式来生成一个区块：

(1) 首先将验证器和打包器部署在一个疾病控制中心或医院节点上，一个节点包含若干台服务器与数据库。部署在一起是因为每个疾病控制中心节点的数据库中保存着验证过的交易单信息，可以减少不必要的网络传输。

(2) 每个节点根据公式B=L%(N-1)来判断是否由自己来生成当前区块。其中B为生成区块的节点，L为区块链的长度。因主节点需要处理来自客户端的请求，因此其不参与区块的生成，以实现各节点任务的负载均衡。

(3) 若某一中心节点根据(2)中公式检测到当前需要自己生成区块，则收集一定量的校验过的交易单ID，生成Merkle树，打包成区块，发送给主节点。经过PBFT算法三阶段过程后，将该区块加入到个节点的区块链链尾。

通过上面三种组件，可以保证在恶意或故障的节点小于等于(N-1)/3时，正常完成共识过程。其验证过程请参见文献[23]。

2.4 合约层

区块链每个区块可编程、可嵌入代码，合约层通过脚本、算法以及智能合约，可以简单地自定义一份电子合同。称之为智能合约，是因为这份合约可以在达到约束条件自动触发执行，不需人工干预，也可以在不满足条件时自动解约，理论上可以触发执行事先约定好的一切条款。这也是区块链能够解放信用体系核心的技术之一。

智能合约是合约层的核心，通过嵌入区块链的合约代码实现。参与方事先拟定合约内容和触发机制，以代码形式嵌入系统，一旦满足触发条件，合约自动执行，外界无法干扰。

传统的疾病预警系统中由于各机构数据互不相通，使得预警精度不足或数据整合时间过长延迟预警时间，并且在中心化管理下，中心系统完全控制数据的写入权，使得操作无法被很好地监管。当前网络和信息化技术高度发达，各种网络攻击层出不穷，信息的收集整合并不是在一个完全的内部系统，因此在运行过程中会遭受到不法分子的恶意攻击，无论是针对应用服务器还是数据服务器的攻击都有可能导致应用或数据异常。相较于传统中心化疾病预警系统，VD Chain上通过共识机制加快了传染病信息的录入过程，数据处理模块中的非对称加密与数字签名技术保证了数据的真实性，共识节点上的数据存储分散了传染病信息的价值，降低被黑客集中入侵中心节点的风险，而将传统的传染病预警与区块链相结合可使数据利用更加得安全、高效。

智能合约如同计算机编程语言中的if-then语句，一旦预先定义的条件被触发，合约就会智能地执行，对数字财产进行交换。而在传染病邻域，患者、医疗机构、疾病控制中心之间组成了一个三角关系。每一个交互中，都存在效率低下和服务复杂的问题。因此智能合约也适合在VD Chain中使用。

本文针对传统的传染病预警模式以及区块链技术智能合约的发展，将智能合约与传染病预警相结合，设置了一个实时可行的传染病预警合约，提出一种基于区块链智能合约的传染病预警方法。预警合约的执行流程图如图10所示。

图10 预警合约执行流程

2.5 应用层

2.5.1客户端

客户端分为管理员和查询信息客户端。疾病控制中心和医院在使用管理员客户端登录后，可操作自己的相关数据，而要查看其他机构的数据则需获得对方权限许可，在获取限权后的一段时间里可查询所需数据。对于查询信息客户端登录的用户在查询数据时，都需要向数据拥有方提出查询申请，在获得权限后方可查看相应的数据。

2.5.2传染病预警

传染病预警合约是自动运行的合约脚本。用户在应用层所能体验到的则是基于该合约的两类传染病预警，分别为单病例自动预警和移动百分位数法自动预警。

单病例预警的特殊病种包括鼠疫、霍乱、传染性非典型肺炎等11种急性传染病[24]。单病例自动预警的过程如下：

1) 各医院节点实时把各自医院当前的传染病病例信息通过客户端上传到VD Chain系统中。

2) 每当有新病例加入，系统合约开始自动检查是否是特殊病种。若是，系统及时发出预警信号。

移动百分位数法自动预警的病种包括麻疹、流行性脑脊髓膜炎等19种急性传染病[24]。移动百分位数法的过程如下：

1) 根据链上的已有数据。合约使用移动百分位数法动态计算传染病的历史基线(阈值)。

2) 系统合约自动把当前观察周期(7天)内病例数与阈值进行实时比较。

3) 若观察周期内发生的病例数大于或等于阈值后，系统将在24小时内发出预警信号。

上述两种预警合约预警在触发预警信号后的预警过程的工作流程如图11所示。

图11 预警工作流程

本文预警机制仅为基于智能合约的简单预测，同时VD Chain还提供一个数据接口为课题其他的项目提供数据支持，实现更加完善的传染病预警。

2.6 用户管理

用户管理主要用来管理参与到Virus Database Chain中用户的账号、密钥和权限，是实现身份认证与访问控制的模块。

2.6.1账户管理

账户管理主要用来管理用户登录、注销、密码找回等功能。其中普通用户可以选择不参与链上共识，只需使用客户端。在获得授权条件下，可以查看区块链中的传染病数据信息，使得数据达到共享。为了更好地管理链上共识节点权限，目前将链上共识参与者节点角色分为三类：普通用户，疾病控制中心，监督者。这些节点以及连接在节点上的客户端在区块链上的行为同样是受到权限限制的，也正是因为权限的限制使平台更加安全可靠。

2.6.2权限管理

权限管理功能是VD Chain中十分重要的部分，它直接关系到VD Chain的安全性及传染病数据的共享性。VD Chain的参与者大致分为三类：监督部门、疾病控制中心和普通用户。监督部门主要包括中国疾病控制中心和卫生部。存储节点是各省市疾病控制中心和医院等机构。普通用户是所有获得权限的使用者，包括医疗机构、政府相关部门等。针对这种特点，VD Chain采用基于角色的访问控制模型(Role-Based Access Control,RBAC)来实现权限管理，RBAC将用户映射到角色，用户通过角色享有许可[25]。通过定义不同角色、角色继承关系、角色之间的联系以及相应的限制，动态或静态地规范用户行为[25]。角色与权限控制如图12所示。

图12 角色与权限控制

1) 监督部门：负责VD Chain运行中的监管活动，由中国疾病控制中心和卫生部控制节点，在三类角色中管理权限最高。其中，中国疾病控制中心拥有最高的管理权限，可以赋予省级管理部门权限。省级管理部门可以在自己的权限范围内赋予市级管理部门权限。公安、法院等政府部门在需要介入到系统中或者需要系统中的信息时，需要通过卫生部授权。但是此类节点的所有操作仍会在链上留下记录，以监督防止其内部人员出现违规行为。

2) 疾病控制中心：由各省市疾病控制中心负责此类节点，是VD Chain中主要的节点。其中包含从业人员和管理人员两类角色。从业人员可以在授权的期限内，查看、修改、添加以及修改传染病信息。管理人员可以在授权的期限内，查看、修改、添加以及修改传染病信息，并能够管理和授权所属的从业人员。

3) 普通用户：医疗机构、政府相关部门和医院等获得权限的用户。在授权的期限内只允许查看传染病信息，不能进行其他操作。该类用户并不负责节点的管理，只需要通过查询客户端就能完成所有操作。

2.7 安全与隐私

VD Chain在隐私与安全保护上主要通过人为干预和系统安全模块来保证。

在人为干预方面：① 严格选聘系统管理人员。② 对系统管理人员进行权限划分。③ 管理人员相互监督。④ 设置清晰、明确的管理和维护规则。

在系统安全模块方面：① 利用“权限管理”模块来保证参与到VD Chain中各方能够在规定权限下，正常使用其所需功能，实现有效的权限监管与分配。② 通过VD Chain中的验证器和打包器组件，采用PBFT共识算法，保证系统能够处理节点的恶意行为与运行故障，且确保区块链中的数据不被篡改。

3 评 估

本平台使用区块链技术管理传染病数据，在保障数据信息安全可靠的前提下实现各节点间的数据共享，并与现有医疗类区块链系统进行对比评估。

3.1 系统评估

经过多年信息数字化发展，我国传染病信息化已较为成熟，但在保密性和共享性上仍面临诸多问题。下面列举了一些传染病数据存储面临的问题，阐述VD Chain应对这些问题的方案，如表1所示。

表1 面临的问题与应对方案

3.2 对比评估

采用对比分析的方式对比已有医疗信息类区块链系统与本传染病信息区块链系统，目前主要的医疗区块链系统有MDSM[9]、MedRec[11]与Model Chain[14]。对比结果如表2所示。

表2 与现有医疗类区块链对比

由表2使用PBFT共识算法的VD Chain：

1) 与MDSM系统相比较，VD Chain所需节点个数远少于MDSM，且MDSM需要人为设定投票权重比例，在这两方面VD Chain都更为简单。

2) 与MedRec系统相比较，VD Chain所需维护节点数远少于MedRec，且无代币激励机制，也不需要大量算力来维护系统。

3) 与Model Chain相比较，Model Chain采用私有区块链形式，所需节点个数不确定。但POI算法容易受到“51%攻击”，因此需要较多的节点维护系统[5]。所以VD Chain所需的节点数要少于Model Chain。

3.3 性能评估

本文实验使用美国Virus Pathogen Database and Analysis Resource(ViPR)[26]网站的传染病数据，实验环境为实验室内局域网，实验使用6台Windows系统的台式机器作为共识网络中的共识节点。

3.3.1共识速度实验

在VD Chain平台上测试共识算法速度，在实验环境下测试不同节点数的单次共识速度。首先保证实验机器中可能的故障节点和恶意节点都是相同的节点f个。选择3组对比试验，分别使用4个、5个和6个节点作为共识节点。多次实验4个共识节点的共识耗时并计算平均值，如表3所示。

表3 4节点共识耗时 ms

多次实验5个共识节点的共识耗时并计算平均值，如表4所示。

表4 5节点共识耗时 ms

多次实验6个共识节点的共识耗时并计算平均值，如表5所示。

表5 6节点共识耗时 ms

实验中共识算法的共识过程耗时如图13所示。

图13 共识算法耗时

3.3.2数据存储实验

实验数据采用ViPR网站的数据进行存储，节点数4个，分别存储100、500、1 000、5 000和10 000个传染病数据，运行结果如图14所示。

图14 数据存储耗时

由图14可知，VD Chain在各节点日常数据存储时可达到毫秒级，性能接近普通数据库。由于节点共识需要时间，在进行大量数据存储时如上万条记录同时生成，在保证数据安全共享的前提下系统需要一定的处理时间，这样的时间开销是必不可少的。

4 结 语

本文结合传染病存储系统和区块链技术，设计了一个联盟式传染病数据区块链系统。该系统有效地保护了数据安全并打破信息孤岛使数据能更简单地共享使用，同时通过引入智能合约，设计了一个简单的预警合约，使得传染病预警自动化。系统评估和实验结果证明了系统的有效性和实用性。

目前，随着国内区块链技术的发展，将为海量数据提供数据共享性与安全可靠性等多方面做出贡献。VD Chain仍然处于实验阶段，链上节点角色与权限还需要细化，未来我们将会增加数据对外接口以及数据脱敏性处理，为本课题的其余子项目提供数据支持等功能，并为将来的DAPP开发做准备。同时，链下实体数据的管理也需要进行优化，考虑使用IPFS[27]的存储方式分布式的管理与存储链下的非结构化数据实体，来保证链下数据的安全存储。另一方面，对于智能合约，考虑实现自己的虚拟机，使用户能够在平台提供的接口下自定义智能合约，使用户体验更加友好。