适用于物联网数据共享的区块链节点存储优化方案*

陈鹏阁，柏粉花，张 弛，江年旗

（1.昆明理工大学 信息工程与自动化学院，云南 昆明 650500；2.昆明理工大学 云南省计算机技术应用重点实验室，云南 昆明 650500）

0 引言

近些年来，物联网作为通信行业的核心领域发展十分迅速，它具有巨大的技术、社会和经济意义[1]。与此同时，数据共享已经发展成为物联网的核心应用之一，收集于物联网的数据经过有效的处理后可以用于服务许多不同类型的应用。传统的物联网数据共享多依托基于云的第三方进行，用户将从各类物联网设备收集到的数据上传到第三方的云，并与其他利益相关者进行数据共享[2]。在这种共享机制下，用户以及物联网设备都必须信任第三方服务提供商，可能还需要支付额外的服务费用。此外，这种集中式的数据共享方式还需要在第三方服务提供商、物联网设备以及用户之间建立协议，这些协议大多是静态的，需要花费大量的时间和管理才能建立，大大降低了数据共享的效率。因此，传统的集中式数据共享机制难以扩展，不能满足未来物联网数据共享的需求[3]。

近年来随着区块链的发展，众多国家政府、企业和研究机构开始关注并重视这一新兴的信息技术[4]。在我国“十四五”规划纲要中，区块链被列为七大数字经济重点产业之一，并且目前已经被应用于数字资产交易、物流管理、智慧城市和物联网等诸多领域，助力实体经济转型升级[5]。其中，区块链和物联网共同具备的分布式特性使它们能够有效地结合在一起[6,7]，在物联网数据共享场景中，应用区块链技术，可以将相应的共享交易通过部署在区块链上的智能合约自动管理，不需要手动验证支付和预定义。与依托第三方的集中式业务场景相比，基于区块链的物联网数据共享可以有效地提高用户信任度，降低运行成本，提高共享效率。

然而，随着时间的推移，区块链账本所需的存储空间在不断增加，以比特币系统为例，其每年的存储开销在50 GB 以上，经过10 年以上的运行，其存储开销已经十分庞大，这个问题在资源有限的物联网中显得更加突出，愈来愈大的存储开销已经成为物联网设备加入数据共享的阻碍。

研究人员对区块链的存储优化问题已经进行了许多研究，其中对于链上存储优化方案来说，中本聪最早提出了简单支付验证（Simplified Payment Verification，SPV）轻节点方案[8]，它允许存储资源不足的节点只存储区块头即可，这类节点就被称为轻节点。后续，又陆续出现了一些存储方案，这些都可以归结为类轻节点方案，其中比较著名的方案有Jidar[9]方案和CUB[10]方案。Jidar 方案允许节点只存储自己感兴趣的交易事务和Merkle 根，而CUB 方案引入信任单元，使一个单元的节点共同维护一份完整的区块链数据副本。这些方案都能够在一定程度上减少区块链节点的存储开销，但是对于基于区块链的物联网数据共享场景来说，这些研究方案存在以下不足：

（1）SPV 方案虽然要求网络内必须存在存储完整区块链账本的全节点，但是轻节点数量过多的话，会出现账本只由少部分全节点维护的情况，这与区块链的“去中心化”理念并不相符。类轻节点方案虽然由区块链中的所有节点共同维护区块链账本，但是缺乏存储完整区块链数据的全节点。在物联网数据共享场景中，对交易数据的验证和溯源是非常必要的，所以其网络中必须存在存储完整区块链账本的节点以方便验证。

（2）现有的区块链节点存储优化方案绝大多数是对经过共识并且出块的区块进行处理，即只是从区块链技术架构的网络层进行改进，并不涉及区块链的共识机制[11]，步骤繁琐，效率不高。

针对上述问题，本文面向基于区块链的物联网数据高共享场景，提出一种区块链节点存储优化方案，该方案结合物联网数据共享场景业务需求，利用基于域的区块链存储模型，引入部分重复（Fractional Repetition，FR）码，对实用拜占庭容错[12]（Practical Byzantine Fault Tolerance，PBFT）算法进行改进，在保证共识效率的前提下，在共识过程中对区块链账本进行优化存储，大幅降低节点的存储开销。

1 方案设计

1.1 部分重复码

由于本文在改进共识算法时引入了部分重复码的概念，所以在此对其进行介绍。

部分重复码[13]的概念由Rouayheb 等人在极大距离可分（Maximum Distance Separable，MDS）码的基础上提出，可以实现非编码的精确修复，简单来说，就是当系统中的某节点失效时，它可以从其他节点下载编码数据片段存储到替换节点，而不需要额外的计算，适合资源有限的物联网场景。

FR 码的外部采用MDS 码，内部采用重复码，其编码过程可以描述为，首先，原始数据被分成j个数据片段后，经MDS(m,j)编码，生成大小相同的m个编码数据片段；其次，将m个编码数据片段复制γ倍，分散放置到系统中的n个存储节点中，每个节点存储p个编码数据片段；最后，经过该编码操作即可得到FR(n,p,γ)码，满足公式：

式中：r=m-j（m>j）为校验片段。FR码具备MDS特性，即从m个片段中任取j个即可解码获得完整数据。

以FR(4,3,2)码为例，其构造过程如图1 所示。当FR 码的重复率γ=2 时，多采用MacWilliams 提出的基于正则图的FR 构造法，4 个角落代表4 个节点，与之连线上对应的数字即表示在此次构造中，节点被分配得到的编码片段。正则图构造法是最简单，也是用得最多的一种FR 码构造方式。当重复率γ>2 时，就要选择其他的构造方法，具体参考文献[14]和文献[15]。

图1 基于正则图的FR(4,3,2)构造

1.2 存储模型

为了降低节点的存储开销，同时满足基于区块链的物联网数据共享场景中交易验证、交易溯源等业务需求，本文提出基于域的区块链存储模型，如图2 所示。

在该存储模型中，节点类型被分为主节点、值班节点和普通节点。网络被划分成了n个域，每个域中的节点类型包含1 个值班节点和k-1 个普通节点，此时域的大小记为k。在这个存储模型中，由主节点充当编码器，在共识过程中对上链交易数据进行编码，将编码片段广播给各个值班节点和普通节点。值班节点和普通节点负责对上链数据进行共识，共识结束后，值班节点存储完整区块链数据和编码片段，普通节点只存储区块头和编码片段。

在这个存储模型中，绝大多数的节点类型均为存储少量数据的普通节点，可以大幅降低该区块链系统的存储开销。同时，存在值班节点存储完整数据和编码片段，可以提供交易验证和数据恢复的服务。此外，该存储模型中的区块链账本由所有节点共同维护，符合区块链“去中心化”的思想。

1.3 PBFT 改进

区块链的类型可以根据其适用场景分为公有链、私有链和联盟链3 种。公有链即比特币、以太坊等项目所采用的区块链，这类区块链不需要权限，任何人均可进入，去中心化程度最高，但是吞吐量低，并不适用于商业场景。私有链则一般用于组织或企业内部，开放程度低，也不适用于商业场景。联盟链的开放程度介于二者之间，多采用PBFT 和其改进算法等快速共识算法，具有较高的吞吐量，所以受到各种商业场景的青睐。本文面向物联网数据共享场景，引入FR 码对PBFT 算法进行修改，降低节点的存储开销。

改进过的PBFT 算法包含主节点、值班节点和普通节点3 种节点类型，经请求（Request）、预准备（Pre-prepare）、准备（Prepare）、提交（Commit）、回复（Reply）5个步骤达成共识。具体步骤描述如下：

（1）Request：由客户端或其他节点向主节点发送请求消息，t为时间戳，z为请求上链数据。

（2）Pre-prepare：主节点对z进行MDS(m,j)编码，生成m个编码片段zf，之后，向网络中的其他节点发送预准备消息<zfs>，v为视图编号，l为该请求交易的编号，d为z的摘要，zfs 为编码片段。此处，主节点以构造FR 码的方式向其他节点广播预备消息。不同的是，传统FR 码要求n个节点中的每个节点获得p个编码片段，而在此要求主节点以域为单位向n个域发送编码片段，每个域中的k个节点获得相同j个编码片段，其中包括p个固定编码片段和q个任意其他编码片段，以保证这些节点能够顺利解码获得数据进行共识。

（3）Prepare：收到预准备消息的普通节点和值班节点利用j个编码数据片段进行解码获得完整上链数据，之后验证预备消息的合法性，验证通过后向其他节点广播准备消息。i为该节点的序号。当该节点在收到至少2f（f为PBFT算法能够容忍的作恶节点数量）个其他节点的验证通过消息时，代表Prepare 阶段完成。

（4）Commit：节点广播确认消息，当节点收到2f+1 个来自不同节点的确认消息时，证明该条请求被通过，执行请求内容并写入日志。若该节点为值班节点，则存储和，即完整的区块信息，包括区块头和区块体，以及在本轮共识中的编码数据片段；若该节点为普通节点，则存储，即区块头和p个FR码要求的固定编码片段。

（5）Reply：每个节点向客户端或请求发起者，单独发送回复消息，0 为执行结果。

2 实验与分析

2.1 性能测试与分析

本文使用JAVA 语言搭建了一个区块链系统实验平台，系统的底层技术包括分布式数据存储、Spring 框架、gRPC 通信机制等。为了减少网络问题对本实验的影响，实验平台部署在OpenStack 云平台中，部署多台配置相同的虚拟机作为区块链网络节点，数据库和Redis 分别运行在docker 环境中，具体物理配置如表1 所示。

表1 节点物理配置

2.1.1 FR 码的编码解码速度测试

在本次测试中，FR 码的外部MDS 编码采用RS 码，这是一种已经被广泛运用于存储系统中的经典MDS 码。区块大小被设置为1.12 MB，其大小与主流区块链系统的区块大小类似。实验测试了在不同情况编码参数下采用FR 码对区块数据进行编码和解码的速度，结果如图3 和图4 所示，其中横坐标代表参数j，纵坐标代表编码速度与解码速度。

图3 FR 码编码速度

图4 FR 码解码速度

从实验结果可以发现，FR 码的编码速度和解码速度是相当快的，在r=2 时，FR 码的编码速度能达到2 200 MB/s，解码速度最低也在200 MB/s 左右，对于一个1 MB 左右的区块来说，解码和编码都在毫秒间完成。由此可以得出结论，FR 码的性能优越，这不仅有利于FR 码存储系统的维护，也说明编码解码过程并不会拖慢PBFT 的共识进程。

2.1.2 PBFT 的TPS 测试

实验通过测试共识算法每秒钟能够处理的事务（Transaction Per Second，TPS）来评估共识算法的性能，定义TPS 的计算式为：

式中：∆t为一个区块的生成时间；trans_number为一个区块内包含的交易数目。

在测试中，区块链系统采用原始PBFT 算法和基于FR(4,3,2)码的改进的PBFT 算法对来自Redis缓存数据库的模拟测试数据进行共识。测试数据是模拟物联网数据共享的交易数据，设置为20个普通非空字段。测试结果均在共识结束后，由统一计算交易数目和共识时间得出。单个区块的trans_number被设置为2 000，此时区块大小约为1.12 MB。实验对连续20 轮共识的时间进行测试和分析，结果如图5 所示，其中横坐标代表共识轮次，纵坐标代表TPS。

从图5 中可以看出，改进过的PBFT 算法的TPS较原始PBFT 算法并未出现下降的情况，这是因为在测试中发现，PBFT 算法的共识过程用时在数秒内，而FR 码的编码解码过程用时在毫秒级别。由此可以分析得出，在PBFT 算法中引入FR 码，对区块链账本进行优化存储的方案具有可行性。

图5 PBFT 和改进后的PBFT 的TPS 对比

2.2 容错性分析

在FR 码中，当失效节点或者离线节点的数量小于等于γ-1 时，FR 码能够进行非编码修复，但一旦失效节点或离线节点的数量达到甚至超过γ，即某编码数据片段的所有副本全部丢失，该存储系统就丢失了非编码修复的特性。本文通过分析本方案中FR码的非编码修复失败率来评估它的容错性，容错性与非编码修复失败率成反比，即非编码修复失败率越低，该编码的容错性就越高。

虽然联盟链严格控制节点的出入，但是节点的错误离线行为是不可控的，本文用作为FR 码的非编码修复失败率，那么在域大小为k的情况下（不考虑值班节点），本方案中FR 码非编码修复失败率表示为F k。本文分析了在不同参数下，传统FR 码与本方案中FR 码的非编码修复失败率，结果如表2 所示。

表2 不同参数下的FR 码的非编码修复率

从表2 可以看出，本方案的非编码修复失败率远小于传统FR 码，且随着k增大呈指数级下降，因此可以得出结论，本存储优化方案相较于传统FR 码具有更高的容错性。

2.3 存储开销分析

为了更加直观地评估本存储优化方案的效果，本文在节点相同的条件下，将本方案与CUB 方案的存储开销减少率和数据丢失率进行对比（不考虑值班节点，r=2，k=4）。本方案的存储开销减少率即为1-p/j，而数据丢失率即为非编码修复失败率。对比结果如图6 所示。

图6 本方案与CUB 方案效果对比

从图6 中可以看出，采用FR 码的本方案与CUB 方案均大幅降低了节点的存储开销。此外，CUB 方案的存储开销减少率一直维持在0.9 以上，而本方案的存储开销减少率随着节点数量从0.667不断攀升至0.867，这是因为在本次对比中，域的大小k被固定为4，随着节点的数量增加，本方案中的域数量n在不断增加，节点的存储开销逐渐下降。因此可以得出结论，在节点数量比较少的情况下，CUB 的存储效率优于本方案，但是随着节点数量增加，这个优势会逐渐缩短甚至消失，从而凸显了本方案的一个优势，即可以根据实际应用场景调节参数以调整节点的存储成本。同时，从图6 中还可以看出，本方案的数据丢失率明显优于CUB方案，可以提高数据的可靠性。此外，本方案的存储过程在共识过程中完成，相较于CUB，在共识结束之后处理效率更高。

3 结语

本文提出了一种适用于物联网数据共享场景的区块俩存储优化方案，该方案给出了一种适用于物联网数据共享的存储模型，引入FR 码的概念对PBFT 算法进行修改，在共识过程中完成区块链账本的存储优化。仿真结果表明，本方案在保证算法的共识效率和编码方案的容错性的前提下，大幅降低了节点的存储开销，为基于区块链的物联网数据共享场景下的存储优化提供了一种新思路。