电力用户信息的多区块链管理及跨链查询方法研究

许俊晓,崔昊杨,江超,江友华

(上海电力大学 电子与信息工程学院, 上海 200090)

0 引 言

信息安全一直是电网信息化与数字化[1-3]进程中的重要研究课题。在2020年,英国电力市场结算机构Elexon与能源供应商People′s Energy均不同程度遭受了网络攻击[4],尽管用户信息安全未受到严重泄露威胁,但也给人工智能时代下的用户隐私信息与存储安全问题敲响了警钟。目前,针对电力用户海量数据信息均以中心化存储的模式为主,极易遭受单点攻击。基于区块链[5-6]去中心化分布式信息管理方法,则能通过密钥加密[7]、Hash加密[8]等技术保证信息数据的安全性[9]。同时,利用通用共识机制并结合加密和星际文件系统(IPFS)等方法,即可实现多节点广义多模通信[10-11]。然而,受区块链各节点数据维护和存储压力过大影响,节点服务器运行效率日益低下的问题正逐步显现。

针对单链多点方案在海量信息处理中遇到的难题,有学者提出了多链多节点的解决方案,如双链方案[12]、主从链方案[13]等。而针对多链数据隔离问题,则相应发展了跨链技术[14],如文献[15]采用基于侧链和中继链跨链实现了物联网的多域认证;文献[16]通过中继链技术实现能源交易不同主体的数据资产流通等。鉴于电力用户具有物理空域强分散性、数字空间多样多维海量特性,利用多链技术与跨链技术实现信息的安全管理具有重要现实意义。但目前针对海量电力用户信息的多区块链数据存储和跨链查询方法,仍少有文献报道。为此,文中将采用Hyperledger Fabric[17]构建电力用户信息区块链管理系统,在保证信息安全性和隐私性的前提下,通过创建多数据通道来实现多链并行,将账本数据多路隔离,交由不同的节点维护,以减轻每个节点的维护任务。同时通过设置中间人节点结合键值查询方法实现了跨链查询,避免多链间出现“数据孤岛”问题,利于数据的交流和统计分析。

1 基于Hyperledger Fabric的多链模型构建

为实现系统的安全管理和高效运行,采用Hyperledger Fabric模块化架构方法构建区块链。文中设计不同模块以实现系统功能,使用链码[18](Chaincode)完成节点和区块链的信息交互。

1.1 系统需求分析

为安全高效地管理电力用户信息,文中设计了节点注册、多通道创建、电力用户信息上链以及电力用户信息查询4个模块,系统模块组成如图1所示。节点注册模块负责通过使用Fabric的准入机制严格把控参与账本维护的节点,实现对于链上信息的安全隐私保护,同时监控每一笔交易的源头,实现信息修改的责任追溯。文中要保证电力用户信息的安全和隐私,因此系统中的节点由省级至县级电力公司的信息管理部门组成。

图1 电力用户信息管理系统组成

多通道创建模块负责使用Fabric的多通道技术实现多链并行,以减轻节点存储压力。通道本质上是账本的逻辑概念,单一通道内的节点共同维护相同账本,通道外的节点与通道内的账本信息完全隔离,因此单个通道可被视为单一单链。一个通道可以含多个节点,一个节点也可以参与多个通道账本的维护。文中采用按省划分的方法构建多个通道,同省的节点进入一个通道,维护该省的账本信息。

电力用户信息上链模块负责通过链码将电力用户的个人信息(例如姓名、用户编号、开户地址等)和用电信息(例如用电量、缴费金额、用电类型等)上链存储。根据用户的开户地址,各省份的用户信息被记录在各自省份通道的账本上,由该省节点进行维护。电力用户信息查询模块负责通过Fabric的键值查询功能对链上对应数据进行查询。但通道间存在数据隔离,不利于数据的交流或统计。因此,除了各省节点之外,文中还设置了一个中间人节点,该节点拥有进入所有通道的权限,通过该节点可进行跨链查询操作。

1.2 节点注册

节点的注册由Fabric CA完成。Fabric CA采用分层公开密钥基础结构(PKI)[19],公私钥和数字证书由各注册节点颁发。具体而言,省、市、县各级电力公司的信息管理部门均需通过Fabric CA完成节点注册以获得公私钥和数字证书,用于保证数据的安全隐私,未持有正确公私钥和证书的节点无法参与系统操作。公私钥主要用于交易签名,文中使用椭圆曲线加密算法(ECC)[20]进行签名操作,ECC在使用更小的密钥时,能够提供比传统RSA加密算法更快的运行速度及更高的安全性能。

Fabric CA使用椭圆曲线加密算法得出成组的非对称公私钥,先随机生成正整数k作为私钥,接着计算Q=kP,Q就作为公钥,其他人无法从公开的公钥倒推出相应的私钥[20]。公私钥被用于交易签名,每一笔交易都需要发起人节点使用私钥签名,其他节点验签成功后交易才能完成。首先发起人节点将交易信息M进行Hash加密处理[21]得到h,并随机产生一个整数r以及计算点rP(x,y),根据r、h和k计算出验证数s,如式(1)所示,然后将交易信息M与签名{rP(x,y),s}发送给其它节点。

(1)

其他节点接收到M与签名后,先对M进行Hash处理得到h,使用公钥Q计算点R,计算公式见式(2),由于Q=Kp,因此式(3)成立。最后,对比R与rP,若两者相等则验签成功。通过签名和验签操作,每一笔交易过程会十分清晰且不可篡改,保证了电力用户信息管理系统内数据的安全。

(2)

(3)

为防止攻击者伪造公钥而影响交易签名,客户端会对所有节点的数字证书进行验证。证书中包含公钥,公钥的签名等信息,证书生成及验证的过程如图2所示。节点注册成功后,会生成公私钥A,CA使用自身私钥B对节点公钥A进行加密,得到签名C,并将签名C与公钥A存入证书中。节点进行工作时,其证书需要通过验证。客户端先从CA处获取公钥B,对证书中的签名C进行解密,接着将解密后的公钥a与公钥A对比,查看是否相同,相同则通过验证。只有拥有合法证书的节点才能参与账本的维护,保证了链上电力用户信息的安全隐私。

图2 证书生成及验证流程

1.3 多通道创建

节点注册完成后,需要创建多通道实现多链并行,以减轻节点存储任务。如图3所示,系统按省划分通道,各省节点只需维护各省的账本信息。账本中的区块信息主要由前一区块哈希值,时间戳和包含用户信息的Markle树根等组成。

图3 多通道结构

文中使用Fabric的configtxgen模块和peer模块创建多个通道。通道创建流程如图4所示。首先开通通道(Channel),以用户的开户地址省份为划分标准。在Profile配置文件中设置通道的组织名称,使用Configtxgen模块运行Profile文件生成各省份通道的初始块文件channel.tx。channel.tx规定了Channel中包含了哪些组织,它最终会被用作Channel的配置原型,通过填补成为账本的genesis块。channel.tx创建成功后,执行jion命令将各省的Peer节点加入各省的通道。加入的具体流程如下：首先通过channel.tx读取Channel的genesis块数据;接着调用CreateLedger方法根据该数据创建Peer节点的本地Channel账本;最后调用createChain方法创建针对此Channel使用的链对象,使用InitializeChannel方法初始化了Peer节点间的Gossip连接服务,由此Peer节点可以向其他节点索要区块的数据并将其添加到本地的Channel账本。各省节点加入后,执行更新命令更新锚节点,锚节点的作用是了解其他通道内成员的信息,检查其是否同时属于本通道。文中利用多通道技术构建多链并分散存储任务,可以避免出现每个节点服务器都存储过量用户数据的情况,减轻节点的存储压力。

图4 多通道创建流程

1.4 链码设计

节点和通道创建完成后,需要将用户信息上链管理,而信息上链、查询的操作都需要链码来实现。链码,也称智能合约,是一段部署在Docker容器中的程序。链码负责客户端程序与Fabric账本的数据交互,节点可以通过链码在客户端发起交易和查询信息。首先我们通过链码声明一个结构体,将用户的个人信息(例如姓名、用户编号、开户地址等)和用电信息(例如用电量、缴费金额、用电类型等)与结构体中的键值一一对应(见表1和表2),用于将数据封装成对象,并将用户编号(EntityID)定为查询键值。为了完成信息的上链和查询,文中使用了Fabric的Shim系统包与客户端进行通信。

表1 电力用户个人信息结构体组成

表2 电力用户用电信息结构体组成

1.4.1 信息上链

完成电力用户信息上链需要调用Shim包中的ChaincodeStubinterface接口,使用接口中的读取方法(GetState)和写入方法(PutState)将信息写入账本,具体设计流程如图5所示。节点将用户信息上传至客户端,客户端业务层先将信息封装为数据对象Power,接着将Power序列化为字节数组,调用链码,上传字节数组。链码通过接口获取字节数组后,首先判断上传数组的参数个数是否符合要求,若不符合则返回错误,若符合则将数组反序列化为Power。反序列化后,链码通过GetState(Power. EntityID)检查用户号EntityID是否已经存在,若存在则返回错误,若不存在则通过PutState(Power)发起交易,将数据写入账本。节点证书验证、交易签名验签成功后,交易完成,用户信息成功上链。

图5 电力用户信息上链流程

1.4.2 跨链信息查询

为打破通道间的数据隔离,实现数据交流,文中设计了一种方案,设置中间人节点,结合InvokeChaincode方法实现跨链链码调用,用于全局数据查询。InvokeChaincode是Shim系统包的ChaincodeStubinterface接口中用作调用外部链码的方法,使用InvokeChaincode方法可以对本通道的账本进行读写操作。但当使用InvokeChaincode调用外部通道的链码时,只有GetState方法等读取方法可以响应,因此 InvokeChaincode方法只能读取外部通道的账本信息,并不能写入信息。而读取信息也是有条件的,即需要侵入外部通道的链码,否则由于通道间存在数据隔离,仅仅使用 InvokeChaincode方法无法调用外部通道的账本数据。

为此,文中提出了中间人节点,可作为两条不同通道的“沟通桥梁”。在Fabric中,单一节点可以加入多个不同通道,因此该节点也可以获取不同通道中的账本信息。如图6所示,Peer3加入了Channel1和Channel2通道,有权限获取两者的账本信息,能够调用双方的链码,公共物理节点Peer3即为中间人节点。以Peer3节点为中间通道,当Channel1的Peer1节点使用InvokeChaincode方法,上传 Channel2的通道ID(ChannelID)和链码名称(ChaincodeName)参数对Channel2的账本信息进行调用操作后,该方法会将上传的ChannelID和ChaincodeName进行拼接形成新的账本名称—ChName。拼接成功后,调用handleInvokeChaincode方法,并传入ChName以及Order节点发来的通道ID(ChID)和交易编号(Txid)。Order节点是独立于Peer节点外,用于交易排序的节点,它通过Grpc[22]与各个节点连接。handleInvokeChaincode方法调用成功后,先调用createChannel函数,使用ChID和Txid创建一个txCtxID通道,此通道与上文Channel不同,是Handler中的通道,只用于消息的收发。通道构建成功后,向Order节点发送InvokeChaincode上传的ChName,由Order节点对Peer3节点提出链码调用的请求,调用成功后将消息记录在txCtxID通道返回。文中将InvokeChaincode方法和中间人节点结合,成功实现了电力用户信息的跨链链码调用。

借助跨链链码调用可以实现全局电力用户信息查询。首先使用CA完成中间人节点的注册,此CA必须与之前节点注册使用的CA相同。接着,将中间人节点加入所有的通道中。中间人节点设置成功后,通过链码完成查询操作,具体设计流程如图7所示。

图6 跨链调用结构

图7 电力用户信息查询流程

首先节点将用户编号(EntityID)、所在省份的通道ID(ChannelID)和该通道的账本名称(ChaincodeName)通过客户端业务层上传,接着判断该用户是否为本省用户,是则直接调用本通道链码,否则通过InvokeChaincode(ChaincodeName, ChannelID)进行跨链链码调用,查询用户对应省份通道的账本。调用链码成功后,先判断上传的EntityID的参数是否符合要求,若不符合则返回错误,若符合则使用GetState(EntityID)查询该链码的账本,读取EntityID对应的数据对象。最后判断读取的数据对象是否为Null,是则返回错误,否则返回查询结果。

1.5 落地方案设计

为迎合国家电网的需求,文中设计了系统的现实落地方案。首先,系统中的节点均由省级至区/县级电力公司的信息管理部门构成,实现信息数据的安全存储以及信息管理的责任追溯。接着以省份为通道划分的标准实现多通道管理,每个省份通道拥有固定数量的节点,维护该省的用户信息,以分散信息处理的压力。最后设置中间人节点,打破通道间的信息隔离。由于中间人节点是各通道间的“交通枢纽”,其重要性等级较高,因此中间人节点均由省级部门构成,各省节点通过该节点实现信息数据的交流及共享。

2 系统功能测试

2.1 系统测试环境

采用Hyperledger Fabric搭建联盟区块链系统,整个测试的组成包括1个CA节点,3个Peer节点,其中Peer0为中间人节点,3个Org通道,3个Orderer排序节点,其名称与所在组织或通道如表3所示。系统的测试是在虚拟机上完成的,虚拟机的配置如表4所示。

表3 系统节点组成

表4 虚拟机配置

2.2 系统功能测试

首先验证系统的信息上链功能,在节点注册,通道创建和链码实例化完成之后,通过客户端上传两个不同省份的测试用户信息,这两个用户的信息被分开写入Org1(上海市)和Org2(北京市)两个通道的账本,上链的后台记录如图8所示。

验证系统的本链和跨链信息查询功能,通过前端输入用户编号(EntityID)、所在省份的通道ID(ChannelID)和该通道的账本名称(ChaincodeName)查询记录在不同通道账本上的两个用户的完整记录,查询成功后将结果通过Web前端界面显示,查询成功后结果如图9所示。

图8 上链后台记录

图9 本/跨链查询结果界面及后台记录

2.3 系统效率测试

文中使用区块链性能测试工具Hyperledger Caliper对系统和测试单链进行吞吐量测试,测试分为两轮,第一轮两者拥有5个节点,另一轮两者拥有15个节点。每轮测试在相同环境下进行了两次,每一次测试15回,两次测试交易次数txNumber分别为500和1 500,测试数据如图10所示。

图10 系统吞吐量测试数据

当两者节点数量为5时,对文中系统和测试单链进行txNumber为500的测试,两者的平均吞吐量分别为163.8 tps和163.1 tps。当txNumber上升为1 500后,两者平均吞吐量下降为155.1 tps和149.5 tps。在交易量大量增加后,文中系统和测试单链的吞吐量下降率分别为5.3%和8.3%。

当两者节点数量为15时,文中系统和测试单链的平均吞吐量在txNumber为500的情况下,分别为163.1 tps和162.5 tps。当txNumber上升为1 500后,两者平均吞吐量下降为154.2 tps和148.3 tps,吞吐量下降率分别为5.5%和8.7%。结果证明,节点数量翻倍增长后,系统吞吐量变化不大,而在交易任务不断增加的情况下,文中系统具有比单链系统更高的运行效率。

3 结束语

文章针对单链情况下节点存储压力过大的问题,提出了多链管理及跨链查询的方法,并设计了电力用户信息区块链管理系统。系统使用Fabric构建联盟区块链,在设置节点注册以保证用户信息安全隐私的前提下,利用多通道技术实现多链并行,减轻单个节点的存储压力,避免节点服务器运行效率低下。为了避免通道间数据无法交流,文中通过设置中间人节点结合键值查询方法实现跨链查询。最后文中完成并测试了系统消息上链及跨链查询的功能,并且对比了文中系统与单链系统的吞吐量及其下降率,结果证明文中系统更加高效。

综上,所述方法不仅保证了电力用户信息的安全隐私,实现了数据的融通共享,也确保了信息处理的高效稳定,对推动国家电网智能化升级,企业数字化转型提供了一定的参考和借鉴。