基于区块链的防护物资捐赠监管系统(二)：系统结构

第1章 对研究背景及内容进行介绍

第2章 智能合约、密码学知识、共识机制等相关技术

第3章 系统的整体设计

第4章 系统功能的具体实现

第5章 系统的实验测试

目录

• 基于区块链的防护物资捐赠监管系统(二)：系统结构
• 三、系统设计
• • 3.1 系统方案
  • • 3.1.1 系统设计
    • 3.1.2 系统结构
  • 3.2 系统安全分析
  • • 3.2.1 安全分析
    • 3.2.2 安全措施
    • 3.2.3 争议仲裁
  • 3.3 数据结构
  • • 3.3.1 物资摘要链
    • 3.3.2 流转记录链
  • 3.4 智能合约
  • 3.5 隐私保护
• 总结

三、系统设计

3.1 系统方案

系统旨在协助公益组织提高信息化程度、增进运作效率，并且为公众及监管部门提供一个将捐赠物资后续使用进展公开透明的平台，从而使公益组织实现透明化运营，重新获得公众尊重、提高社会公信力。根据需求特性本文选择了基于区块链技术建立这样一个用户为公益活动各方参与者，并且用户均能与系统直接交互的监管平台，通过区块链技术实现信息透明公开，解决信息不对称的问题。

3.1.1 系统设计

系统主要存在四类用户，物资需求方、物资捐赠方、公益组织以及监管部门。如图所示，用户均可进行对区块链的直接操作，但行为需要经过系统验证，物资需求方通过区块链发布物资需求；物资捐赠方通过区块链发布物资捐赠情况，系统根据算法匹配，从而实现捐受双方的需求精准对接；公益组织负责相关物资的流转验证以及对用户诚信的记录和黑名单公示；监管部门可全程在区块链上对物资进行跟踪查询，并可根据相关因素对公益组织进行评价。整体参照了软件工程的迭代开发模式，能够使软件实现快速迭代，并且可根据实际反馈更新系统版本。

物资需求方为社会公认的医院，针对疫情中出现相关组织曾将紧缺防疫物资捐赠予未设立发热门诊等医院的现象，物资需求方在向区块链系统中提交物资需求时，需要提供相应资格证明以及门诊压力，便于系统进行认证及物资分配等操作。

物资捐赠方主要为社会各界爱心人士，但也存在不诚信用户，因此使用系统前需要用户进行身份信息的实名认证；针对可能出现的供需对接后捐赠方物资迟迟未能发送的问题，设置时间锁，若时间节点到期后相关双方没有发生争端，则捐赠有效；否则会将信息记入信用记录，并由系统进行黑名单公示。

公益组织也可能存在内部不诚信员工等问题，可采用外部监督志愿者的形式，公益组织应主动向媒体通报公益活动开展、援建项目进度、重要会议召开等相关信息。监管机构可为志愿者或相关媒体、政府机构等。

3.1.2 系统结构

系统采用MVC框架结构，基于不同功能分为3层。

第一层View层负责数据的可视化操作。能够实现数据查询、数据交易、数据评价等功能。

第二层是Controller层，通过网络控制数据流向Model层，并在检测到数据变化时更新View层。这一部分由共识机制PBFT和基于P2P通信的节点服务器组成。如图3.2所示，每个节点既用于数据副本存储，也作为区块链节点；数据副本加密存储在各个节点的数据库当中，而将数据摘要存储在区块链当中，保证数据的不可篡改性和完整性；

第三层是Model层，负责处理数据逻辑的部分。由数据层和存储层组成，每个服务器建立并与维护物资摘要链和流转记录链，具体内容将在存储结构中介绍。

3.2 系统安全分析

3.2.1 安全分析

合法用户正常使用系统的情况下，操作主要分为四种类型：1.捐赠方将物资信息发布并记录在平台；2.物资需求方通过获取资格认证后，将物资需求信息发布并写入区块链；3.系统进行物资信息匹配环节后，由公益组织将捐赠物资转赠予物资需求方；4.在物资顺利送达后，由公益组织负责跟进后续活动进展，并且将所有流通细节通报媒体，并写入区块链。

如图所示，系统可能会存在如下安全问题：

(1) 捐赠欺骗：由于不诚信用户的存在，可能会出现物资捐赠方提交与其所拥有的实际物资质量、数量等不相符的物资捐赠信息，导致智能合约出现空匹配等问题，影响系统后续功能实现；并且可能会出现非法用户进行DDOS攻击，不经过客户端向服务器发送大量无用数据包，导致服务器节点宕机等问题；

(2) 不合格交易：同时可能出现用户在捐赠物资信息发布后，物资捐赠方拒绝提交或超时提交相关物资等情况，导致物资需求方不能及时获取防护物资；

(3) 需求欺骗：医院等物资需求方可能会在利益驱使下申请与其自身实际需求不相符的物资，或请求与自身医疗资质不匹配的防护物资；

(4) 节点欺骗：公益组织内部可能会存在不诚实员工，通过人为操作将紧缺物资分配给予其个人存在非法利益关系的机构，牟取非法收入；

3.2.2 安全措施

(1) 为了减小不诚信用户威胁，在用户注册登录系统时，需要进行实名认证，系统会通过加密存储的形式保护用户个人信息；在物资捐赠方上传物品捐赠信息时，需要提供相关产品标准、产品检验标志、有效合格证件、检查第三方检验报告、企业灭菌记录等信息，从而减少不合格物品的影响；为防止出现DDOS攻击，在用户上传信息的数据包中加入设备硬件特征码，限制设备一定周期内数据发送的次数。

(2) 针对出现不合格交易的问题，平台加入了信誉值系统，信誉值变化将影响其自身属性和系统的后续使用；不同系统功能会设定阈值，如果信誉值不满足要求，相关功能会被限制访问，详细设计内容会在下一章节进行介绍。如果相关人员存在操作行为问题，系统会将其记入信用黑名单并进行广播，情节严重的则会移交法院依照法律进行评判。

(3) 对于存在的需求欺骗问题，同样采取确认用户身份的形式。与物资捐赠方不同，物资需求方在获得医院资格认证信息的前提下，申领防护物资时必须向系统提供如发热门诊人员配置、诊室数量、就医人数等信息，这些内容将影响后续物资匹配算法计算。

(4) 为了防止节点欺骗，系统采用联盟链结构，任何区块链操作都需要系统内大部分节点达成共识；同时公益组织需要将区块链上展示的慈善活动，通告媒体经公开通报后进行上链，以此避免节点欺骗；并且公益组织人员登录系统进行操作时，会留下其个人身份哈希值。

3.2.3 争议仲裁

在活动过程中可能会出现多方纠纷等问题，由监管部门作为第三方介入。当物资捐赠方或物资需求方在慈善活动过程中出现纠纷，或公众对相关公益活动真实性存在质疑，可以向公益组织发起投诉，这是会由监管部门介入，如图3.4所示，监管部门能够通过系统查询物资摘要链、流转记录链中活动信息的记录，进而通过直接证据或通过身份码征询相关员工等方式，对相关活动信息溯源取证，并执行相应必要的惩罚。

3.3 数据结构

根据上述系统需求，设计了下面的数据结构。系统整体采用双链的结构，物资摘要链负责记录物资捐赠及需求信息，方便匹配及活动查阅；流转记录链负责记录物流、经办人等捐赠物资流转信息。详细内容将在下文介绍。

3.3.1 物资摘要链

物资摘要链存储物资捐赠方物资的信息摘要以及物资需求方的需求信息，同时在侧链中存储第三方的审核标准以及相应活动的评价信息，通过区块链不可篡改的特点保证存储信息真实可靠。首先依照区块链特性设计了包含父区块哈希值、Merkle根以及时间戳的区块头结构，其中记录的信息包括：

(1) 父区块哈希值：通过这个值将每个区块首尾相连从而组成区块链，对区块链的安全性起到了至关重要的作用，关于安全性的具体叙述详见之后的验证算法；

(2) Merkle根：通过Merkle树计算所得当前区块的哈希值，将区块中除评价侧链以外的所有信息内容利用 SHA256 算法计算哈希值；由于区块任意底层叶子节点的变化都会传递从而影响其父节点直至根节点哈希值，因此可保证数据内容不被篡改；

(3) 时间戳，记录生成该区块的时间，精确到秒；通过时间戳技术将篡改区块内容的难度进一步提升，如果想要篡改某一区块内容就需要依次改动，直至将该区块后面所有区块改变；

(4) 区块编号，记录该区块的高度便于系统查询调用；

(5) 版本号，记录生成区块节点的平台版本信息，便于系统后续的工程维护。

作为区块链的基本结构，区块头内容适用于所有区块类型。由于系统需求，需要对用户的个人信誉进行评测以及记录公益活动后续进展，因此设计采用二维链式的区块链数据结构，如图3.3所示，由物资摘要信息构成的数据区块作为纵链；

由用户的评价信息构成的区块链接并作为侧链，每个用户进行系统操作过后，系统会为参与此次捐赠匹配的双方提供评价权限，受捐方可将该捐赠物资的使用情况发布在区块链上，从而影响捐赠方的信誉值，用户信誉的具体计算方式将在下一章进行详细讲解。在查询信息时，可在纵链上找到数据摘要信息区块，在并根据侧链上的评价信息选取，从而提高系统的可读性公平性，查询数据的效率和系统的时间性能。

评价信息的更新，建立在数据摘要链特殊的二维结构基础上，由主节点直接完成，数据区块的区块头Merkel树根哈希值为除侧链以外的其他信息的计算结果；每个评价侧链的创世区块哈希值，为其所处区块的区块头Merkel根哈希值，从而与数据区块构成横向链式结构；经过一个更新周期时间后，由主节点通过系统将侧链的更新内容进行广播并同步给所有其他节点。

根据需求不同，分别针对性设计了如下不同功能的区块体:

(1) 捐赠方区块体，如图3.4所示，区块主体记录的信息有：

1)物资摘要信息，包括物资描述、物资类型、物资数量、质量认证信息等；

2)地址信息，捐赠者所处地理位置，该信息将影响后续的供需匹配；

3)个人信息，存放用户个人身份码，便于物资所属权认证；

4)个人信誉侧链，包含前一区块的哈希值（用于构成一条完整链结构）、评价分数、评价文字描述以及信息生成的时间等。为了实现可更新的评价侧链，用于数据摘要链组件的哈希值计算将不包括侧链内容，用户提交评价后将进行一次广播投票，确保合法后更新相应区块。

(2) 需求方区块体，如图3.5所示，区块主体记录的信息有：

1)需求摘要信息，包括需求描述、需求类型、需求数量等；

2)地址信息，需求方如医院所处地理位置，该信息将影响后续的供需匹配；

3)资格信息，存放如医院医疗资格认证码，防止莆田系医院干扰；

4)门诊信息，如发热门诊工作人员情况、相关诊室数量、门诊就医人数；

5)医院信誉侧链，包含前一区块的哈希值，评价分数、评价文字描述等内容，信誉值具体更新算法将在下一章介绍。

3.3.2 流转记录链

同样采用上述的二维链式结构，流转记录链用于存储捐赠物资后续活动进展产生的信息，记录用户捐赠物资的转移过程以及后续使用记录等内容。

上述区块头内容同样适用于流转记录区块，流转记录链的数据结构与物资摘要链结构较为相似。如图3.6所示，流转记录链中储存：

(1) 流转信息如物流编号,便于查询当前区块所属活动的物资货运进展；

(2) 发送方信息，存储物资发送方的身份ID，便于确认物资所属权以及后续奖励或惩罚对象；

(3) 经办人信息，记录公益组织工作人员身份ID，便于监管部门在活动后续介入调查取证时的相关责任归属；

(4) 接收方信息，包含接受物资捐赠的医院等物资需求方信息，用于活动记录公开展示；

(5) 后续进展侧链，后续动态更新经媒体通告后的公益活动进展。

用户的物资资产判定由流转记录链中的交易输入输出决定，区块链可能会非常长，而交易必须查找并检查其输入。因此保存了一个额外的集合称之为未使用的交易作为可用的输入, 执行一些检查以确保交易有效，然后收集输入并生成输出并更新集合，执行的交易以Merkel tree形式存入区块，以此避免大量的hash计算。

3.4 智能合约

物资捐赠方可以通过智能合约发布自己的物资信息，合约会包含需求物资的类型描述、物资数量等内容，系统在对用户资格审查过后，会将该智能合约发布到分享系统中。同样，物资需求方可以通过其发布自己的物资需求，合约包含上述区块种的需求信息、地址信息、资格信息以及门诊情况等。

该系统智能合约主要包括三个部分：

(1) 初始化合约public String initialize()：

该合约由用户发起，初始化合约状态；

contract Crowding {
    address public dataDemander;  // 发起人地址
    string public publicKey;  //发起人公钥
    string public projectDetail;  //使用物资的活动描述
    string public styleDetail;  //需求物资类型细节
    uint public goalData;   // 需求物资数量目标
    uint public deadline;    // 截止日期
  }
           

(2) 物资信息匹配合约public String provide()：系统会调用该合约协助完成捐受双方数量类型上的精准匹配，详细匹配方式将在下一章介绍；

(3) 用户信誉评价public String reputationChange():其中包含物资捐赠方初始提供的捐赠物资数据，如物资数量DQTi (Data amount)，物资质量DQLi(Data quality)等。在匹配完成物资需求方收到对应物资活动完成后，系统会根据用户反馈对物资捐赠方信誉值重新确认。

与数字货币交易不同，该系统设计的智能合约不仅仅包含数据的流转，还包括数据的收集过程，因此在进行项目初始化时，物资需求方应该声明所需要物资的数量，并描述需要物资的类型，这样更有利于拥有该类型物资的提供者参与该项目。同时为了满足物资使用的隐私性，发起合约项目的数据需求方还需要提供真实的身份以及使用目的，例如医疗机构名称或者其他团体名称，这样物资提供者可以在参与公益活动时，知道自己的物资将被何人用于何种目的。

3.5 隐私保护

随着网络的普及以及人们日益提高的隐私保护意识，用户对其使用系统的要求也愈发严苛，本文系统采用AES+RSA结合的方式实现DH密钥交互算法，对系统内所有必要的通信内容进行了双向加密，保证系统中的安全通信不会被窃听或冒充；对于网络内传输的敏感内容，只有拥有证书机构认证的授权用户才能解密密文获取信息，具体方案在第二章中进行了讲解。

用户首次登陆系统时，会分配签名私钥信息，私钥与用户手机客户端绑定存储在本地。系统会将用户个人身份等验证信息进行捆绑，通过椭圆曲线数字签名算法生成用户身份码。用户个人隐私数据以加密的形式存储，利用身份码实现保护平台用户隐私的同时，对捐赠物品所属权进行认证。同时基于信誉值的访问控制，能够有效限制可能存在非法操作的用户获取系统内容；系统支持匿名捐赠，但会将身份码留作证据，用于可能出现的归责流程。

总结

以上是系统结构的具体设计，接下来会对具体功能的实现进行展示，仅供参考。

第1章 对研究背景及内容进行介绍

第2章 智能合约、密码学知识、共识机制等相关技术

第3章 系统的整体设计

第4章 系统功能的具体实现

第5章 系统的实验测试