電力用戶信息的多區塊鏈管理及跨鏈查詢方法研究

許俊曉,崔昊楊,江超,江友華

(上海電力大學 電子與信息工程學院, 上海 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構建聯盟區塊鏈,在設置節點注冊以保證用戶信息安全隱私的前提下,利用多通道技術實現多鏈并行,減輕單個節點的存儲壓力,避免節點服務器運行效率低下。為了避免通道間數據無法交流,文中通過設置中間人節點結合鍵值查詢方法實現跨鏈查詢。最后文中完成并測試了系統消息上鏈及跨鏈查詢的功能,并且對比了文中系統與單鏈系統的吞吐量及其下降率,結果證明文中系統更加高效。

綜上,所述方法不僅保證了電力用戶信息的安全隱私,實現了數據的融通共享,也確保了信息處理的高效穩定,對推動國家電網智能化升級,企業數字化轉型提供了一定的參考和借鑒。