電力供應(yīng)鏈場景下智能合約個性化升級方法*

李 達(dá)，王 棟，阮倩昀，柏德勝，許洪華，霍冬冬

(1.國網(wǎng)電子商務(wù)有限公司(國網(wǎng)雄安金融科技集團(tuán)有限公司)，北京100053；2.國網(wǎng)區(qū)塊鏈科技(北京)有限公司，北京100053；3.中國科學(xué)院 信息工程研究所，北京100093；4.國家電網(wǎng)有限公司區(qū)塊鏈技術(shù)實(shí)驗(yàn)室，北京100053；5.國網(wǎng)江蘇省電力有限公司，江蘇 南京210000)

0 引言

隨著電力體制改革加快推進(jìn)，電力行業(yè)逐漸從垂直一體化的內(nèi)部供應(yīng)鏈體系，轉(zhuǎn)變?yōu)橛啥鄠€相對獨(dú)立環(huán)節(jié)構(gòu)成的外部供應(yīng)鏈體系。根據(jù)電產(chǎn)品的生產(chǎn)和流通過程，電產(chǎn)品的生產(chǎn)、輸送、分配和銷售等環(huán)節(jié)將構(gòu)成一條完整的電力供應(yīng)鏈。電力供應(yīng)鏈上的主體角色多樣，包括了獨(dú)立生產(chǎn)、分配、銷售電力的企業(yè)和電力用戶。電力企業(yè)通過實(shí)施供應(yīng)鏈管理，有效降低了成本以保證收益，也使得供應(yīng)鏈的總體流動效率和電力企業(yè)的管理水平得到了顯著的提高。

當(dāng)前，電力市場正在經(jīng)歷由以電網(wǎng)為核心、交易單一能源品種逐漸向多主體參與、能源交易品種多樣化轉(zhuǎn)變，由此帶來分布式能源數(shù)量龐大且分散、主體間信息不對稱、可信任度低等問題日益嚴(yán)峻。具備隱私保護(hù)性、不可篡改性、分布式容錯性、可信任性等特性的區(qū)塊鏈技術(shù)，是解決能源交易中間環(huán)節(jié)較多、主體間信息不對稱、信任缺失、交易成本高、用戶隱私難以保障等問題的重要技術(shù)手段。但隨著電力供應(yīng)鏈業(yè)務(wù)交易數(shù)據(jù)量日益增長，部分業(yè)務(wù)交易流程繁瑣、實(shí)時性要求高，急需一種自動化處理復(fù)雜業(yè)務(wù)的應(yīng)用模式。

“智能合約”由密碼學(xué)家Szabo于20世紀(jì)90年代首次提出，他指出智能合約是一種可計算的交易協(xié)議，以計算機(jī)程序的方式來執(zhí)行合約條款[1]。目前，業(yè)內(nèi)對智能合約的定義還未統(tǒng)一，文獻(xiàn)[2]定義智能合約的實(shí)質(zhì)為一段腳本代碼，該腳本代碼具備可復(fù)用性、模塊化編程和滿足條件即可觸發(fā)執(zhí)行等特點(diǎn)。文獻(xiàn)[3]強(qiáng)調(diào)了區(qū)塊鏈對智能合約的可實(shí)現(xiàn)性有著巨大意義，每個合約聲明的執(zhí)行都記錄為存儲在區(qū)塊鏈中的不變交易。

近年來，許多國內(nèi)外專家學(xué)者在電力領(lǐng)域?qū)^(qū)塊鏈智能合約技術(shù)展開了研究，取得了較顯著的成果。在合約實(shí)現(xiàn)數(shù)據(jù)上鏈方面，文獻(xiàn)[4]提出了一種基于區(qū)塊鏈的電力交易管理方法，該方法利用自動執(zhí)行的智能合約維護(hù)和管理電力交易數(shù)據(jù)，根據(jù)合約內(nèi)容自動化地轉(zhuǎn)移資金，并存儲由智能電表采集的實(shí)時電能信息以便后續(xù)分析和使用。文獻(xiàn)[5]提出了一個弱中心化的能源互聯(lián)網(wǎng)架構(gòu)模型，該模型利用區(qū)塊鏈技術(shù)實(shí)現(xiàn)了各類能源節(jié)點(diǎn)和售電企業(yè)節(jié)點(diǎn)的交互，通過驗(yàn)證并注冊身份，從而保障了各節(jié)點(diǎn)之間的安全交易?；趨^(qū)塊鏈的分布式特性使得各節(jié)點(diǎn)在交易過程中做出較公平的決策，并利用智能合約實(shí)現(xiàn)了源-售雙邊交易信息的存儲和管理。文獻(xiàn)[6]提出了一種分布式微電網(wǎng)交易和能源的任務(wù)調(diào)度策略，并在此基礎(chǔ)上提出了基于面向訂單轉(zhuǎn)移的動態(tài)智能合約的制定方法，實(shí)現(xiàn)了降低用戶經(jīng)濟(jì)開銷與提高數(shù)據(jù)中心經(jīng)濟(jì)收益的目標(biāo)。文獻(xiàn)[7]提出了基于區(qū)塊鏈的電力交易和調(diào)度系統(tǒng)，該系統(tǒng)針對微電網(wǎng)中典型的業(yè)務(wù)處理邏輯，設(shè)計了面向電力購買、電力輸送和電力結(jié)算等場景的智能合約，并有效實(shí)現(xiàn)了將微電網(wǎng)主體的關(guān)鍵數(shù)據(jù)記入?yún)^(qū)塊鏈中。在合約的可升級性方面，文獻(xiàn)[8]利用智能合約設(shè)計并提出了一個訪問控制框架，該框架由三類定制化的合約組成，分別為面向用戶的訪問控制合約、判斷合約和注冊合約，將注冊訪問控制合約中的訪問控制信息、判斷合約中的不良行為信息以及智能合約中的信息，交由注冊合約統(tǒng)一進(jìn)行注冊、更新和刪除等管理。文獻(xiàn)[9]提出了一種自動支持智能合約更新的方法，通過計算目標(biāo)智能合約的代碼語法和語義相似度，從而發(fā)現(xiàn)相似的智能合約，并從智能合約源代碼中提取差異化的代碼以支持目標(biāo)智能合約的更新。文獻(xiàn)[10]提出了一種基于區(qū)塊鏈日志系統(tǒng)的智能合約自動更新的框架，該框架融合了區(qū)塊鏈技術(shù)和機(jī)器學(xué)習(xí)方法，先將采用機(jī)器學(xué)習(xí)方法提取到的日志異常信息連續(xù)輸入到智能合約中，再執(zhí)行智能合約實(shí)現(xiàn)日志的異常檢測，從而達(dá)到支持合約自動更新的目的。文獻(xiàn)[11]提出了一種松耦合的智能合約鏈上升級模型，該模型通過定制的智能合約實(shí)現(xiàn)了各功能之間的順利調(diào)用，也在保證合約的調(diào)用接口與數(shù)據(jù)結(jié)構(gòu)不改變的同時，實(shí)現(xiàn)了合約的邏輯功能升級。文獻(xiàn)[12]提出了一個基于區(qū)塊鏈技術(shù)的線上公平合約交換協(xié)議，采用數(shù)字簽名，在合約內(nèi)容之后追加新內(nèi)容并確認(rèn)的方式，提供了公平合約的追加、更新和刪除管理功能，以保證合約追加內(nèi)容與過程的可靠性和不可抵賴性。在合約實(shí)現(xiàn)電力交易執(zhí)行方面，文獻(xiàn)[13]提出了一個基于區(qū)塊鏈的虛擬電廠調(diào)度模型，該模型利用智能合約使得虛擬電廠中各主體之間的運(yùn)行調(diào)度能夠有序、安全且自動地發(fā)生。文獻(xiàn)[14]從綠色低碳和經(jīng)濟(jì)效益角度出發(fā)，提出了一種弱中心化的電力市場交易出清模型，該模型利用智能合約技術(shù)使得電力交易中競價和結(jié)算的過程安全和自動執(zhí)行成為可能。文獻(xiàn)[15]提出了一種弱中心化的電力交易清結(jié)算智能合約，該智能合約不僅將清算業(yè)務(wù)結(jié)構(gòu)化，也提高了電費(fèi)清算的效率，并通過不可銷毀、篡改且透明的交易記錄使得電費(fèi)清算過程具備較高的可審計性和真實(shí)性。文獻(xiàn)[16]提出了一種基于區(qū)塊鏈的分布式電力交易方法，采用定制的智能合約實(shí)現(xiàn)了交易信息投標(biāo)、P2P交易、安全校核和交易清算過程。文獻(xiàn)[17]提出了一種弱中心化的面向電力供應(yīng)鏈的主體利益分配模型，該模型利用智能合約自動匹配并結(jié)算利益，以實(shí)現(xiàn)電力供應(yīng)鏈上各個企業(yè)的利益最優(yōu)和整個供應(yīng)鏈的利益最優(yōu)。文獻(xiàn)[18]設(shè)計了基于區(qū)塊鏈的安全電力交易模型，通過在無線網(wǎng)絡(luò)中引入?yún)^(qū)塊鏈的智能合約進(jìn)行數(shù)據(jù)的傳輸和決策，解決了集中電力交易中安全性低和可信任性低的問題，并設(shè)計了基于智能合約的可再生能源激勵機(jī)制，以實(shí)現(xiàn)根據(jù)激勵算法自動、公平地向可再生能源生產(chǎn)商支付報酬，有效鼓勵了生產(chǎn)者提高電能質(zhì)量、擴(kuò)大生產(chǎn)能力。

當(dāng)前，針對在電力供應(yīng)鏈的智能合約技術(shù)研究還停留在保證鏈上所有用戶數(shù)據(jù)的可信互聯(lián)，還未深入到電力供應(yīng)鏈場景下智能合約的管理，缺乏在電力供應(yīng)鏈場景下對用戶訪問數(shù)據(jù)的權(quán)限做出細(xì)粒度控制。例如，在多用戶的合約升級場景下，將會造成以下問題：受限于電力企業(yè)各自的職能，區(qū)塊鏈上參與電力供應(yīng)的某一個企業(yè)無法對所有待升級的智能合約的合法、合規(guī)性做出背書保證。

為解決上述提出的問題，本文設(shè)計并提出了一種智能合約個性化升級方法，該方法通過編寫個性化的智能合約，使得具備驗(yàn)證待升級合約有效性資質(zhì)的電力企業(yè)能夠驗(yàn)證新合約及實(shí)現(xiàn)有關(guān)數(shù)據(jù)的上鏈，并確保不具備驗(yàn)證資質(zhì)的企業(yè)無法進(jìn)行合約的升級驗(yàn)證。對于驗(yàn)證通過的合約，其合約哈希值將被存至區(qū)塊鏈鏈上，并與合約版本號碼匹配，以用來索引新的合約。該方法采用智能合約結(jié)合背書策略的方式，進(jìn)一步保證了智能合約升級的安全性和可靠性，并將該模型應(yīng)用于電力交易合約的升級驗(yàn)證。本文實(shí)現(xiàn)了一個基于Fabric的合約升級驗(yàn)證方案，可降低電力企業(yè)合約升級驗(yàn)證數(shù)據(jù)上鏈的失真風(fēng)險，推動鏈上鏈下合約升級數(shù)據(jù)協(xié)同發(fā)展。

1 相關(guān)背景

1.1 Hyperledger Fabric

Hyperledger項(xiàng)目是Linux基金會支持的企業(yè)級開源分布式賬本實(shí)現(xiàn)，Hyperledger Fabric是第一個加入Hyperledger的項(xiàng)目，其目標(biāo)是構(gòu)建企業(yè)級的區(qū)塊鏈基礎(chǔ)核心平臺，支持權(quán)限管理和數(shù)據(jù)安全，以下簡稱Fabric。Fabric最初是0.6版本，后來在2017年發(fā)布了版本v1.0[19]。在2020年1月，IBM正式發(fā)布了Fabric v2.0，較之前的版本增添了一些新的特性和功能，新版本引入了智能合約的新鏈碼應(yīng)用模式、私有數(shù)據(jù)的優(yōu)化增強(qiáng)、新的外部鏈碼啟動器、新的狀態(tài)數(shù)據(jù)庫緩存和新的基于Alpine Linux的Docker鏡像[20]。Fabric項(xiàng)目面向的是聯(lián)盟鏈的場景，通常在許可區(qū)塊鏈中的眾多組織將組成一個聯(lián)盟，每個單獨(dú)的組織都構(gòu)成一個信任域，組織內(nèi)的實(shí)體彼此信任[21]。聯(lián)盟在整體上定義了共同的規(guī)則、政策以及共享的業(yè)務(wù)邏輯。

本文基于Fabric v2.0進(jìn)行研究討論，下面給出Fabric的交易流程。

Fabric中的一筆成功交易從客戶端提交交易給背書節(jié)點(diǎn)開始，到確認(rèn)節(jié)點(diǎn)將狀態(tài)改變更新到區(qū)塊中結(jié)束。具體的交易流程如圖1所示。

圖1 Fabric的交易流程

Fabric的交易流程由背書階段、排序階段和驗(yàn)證階段組成[22]，根據(jù)圖1將對整個交易流程進(jìn)行如下概述。

(1)背書階段

在背書階段，首先由客戶端發(fā)送交易提案的請求給背書節(jié)點(diǎn)。背書節(jié)點(diǎn)收到提案請求后，驗(yàn)證消息格式與簽名合法性，以及檢查簽名提案消息的唯一性和是否滿足通道權(quán)限策略。驗(yàn)證檢查結(jié)束后，背書節(jié)點(diǎn)模擬執(zhí)行交易提案，并對結(jié)果進(jìn)行背書簽名，之后將簽名結(jié)果、模擬執(zhí)行結(jié)果讀寫集、鏈碼執(zhí)行響應(yīng)消息等封裝為提案響應(yīng)消息發(fā)送給客戶端。收到提案的響應(yīng)回復(fù)消息后，客戶端將判斷該消息結(jié)果是否合法。若該交易是“查詢交易”，檢查通過后，客戶端將以提案響應(yīng)消息結(jié)果作為下一步業(yè)務(wù)邏輯判斷的依據(jù)。若該交易是“寫交易”，下一步將進(jìn)入排序階段。

(2)排序階段

客戶端收到的提案響應(yīng)消息包括鏈碼執(zhí)行響應(yīng)消息和模擬執(zhí)行結(jié)果讀寫集。在排序階段，客戶端需確保收到的所有提案響應(yīng)消息都是按位相等的，否則返回錯誤，然后將提案消息、提案響應(yīng)消息、背書信息列表等構(gòu)造成簽名交易消息，提交給排序節(jié)點(diǎn)。排序節(jié)點(diǎn)先對交易進(jìn)行排序并構(gòu)造成區(qū)塊，然后以廣播的方式發(fā)送給各組織的錨節(jié)點(diǎn)。

(3)驗(yàn)證階段

在驗(yàn)證階段，錨節(jié)點(diǎn)收到區(qū)塊后，先驗(yàn)證交易和區(qū)塊是否有效，驗(yàn)證通過之后將執(zhí)行區(qū)塊中的有效交易，并根據(jù)交易執(zhí)行的結(jié)果對賬本狀態(tài)進(jìn)行更新。之后將區(qū)塊同步給組織內(nèi)的其他節(jié)點(diǎn)，其他節(jié)點(diǎn)也需驗(yàn)證交易和區(qū)塊，最后組織內(nèi)所有節(jié)點(diǎn)的賬本都會得到更新。

正是上述所描述的三個階段組成了Fabric的共識機(jī)制，實(shí)現(xiàn)了Fabric內(nèi)大部分節(jié)點(diǎn)對多個事件發(fā)生的順序、某個鍵對應(yīng)的值、誰是主節(jié)點(diǎn)等某個提案信息達(dá)成了一致。

1.2 典型電力供應(yīng)鏈模式概述

按照電力供應(yīng)鏈的上下游關(guān)系，典型的電力供應(yīng)鏈大致可以分為發(fā)電、輸電、配電、售電、用電等環(huán)節(jié)。其中，發(fā)電環(huán)節(jié)是指發(fā)電企業(yè)生產(chǎn)電能；輸電環(huán)節(jié)是指電網(wǎng)企業(yè)把電能由發(fā)電企業(yè)輸送到配售電企業(yè)；配電環(huán)節(jié)是指配電企業(yè)根據(jù)用戶用電電壓級別和用電需求與用戶直接相連并向用戶分配電能；售電環(huán)節(jié)是指售電企業(yè)向最終用戶提供電能并完成電力交易；用電環(huán)節(jié)則是指終端用戶消費(fèi)電能。電力供應(yīng)鏈的上下游主體關(guān)系簡化圖如圖2所示。

圖2 電力供應(yīng)鏈的上下游主體關(guān)系

2 智能合約個性化升級模型和應(yīng)用的設(shè)計

2.1 基于智能合約的個性化升級模型

在電力結(jié)算交易環(huán)境中，由于不同角色的主體之間的交互越來越頻繁，為適應(yīng)多用戶場景下的合約升級需求、增強(qiáng)訪問控制的安全性，提出了如圖3所示的基于智能合約的個性化升級模型，模型利用智能合約實(shí)現(xiàn)了對用戶訪問控制和待升級合約信息的管理。

圖3 基于智能合約的個性化升級模型示意圖

假設(shè)發(fā)電企業(yè)Org1、電網(wǎng)企業(yè)Org2、配售電企業(yè)Org3都采用基于智能合約的個性化升級模型，并且各個企業(yè)在鏈下?lián)碛胁煌耆嗤碾娏灰讛?shù)據(jù)庫。Org1-peer、Org2-peer、Org3-peer代表企業(yè)用戶，也是實(shí)際的Fabric網(wǎng)絡(luò)節(jié)點(diǎn)，其中只有Org1-peer才有權(quán)限訪問Org1的IT服務(wù)商，Org2-peer和Org3-peer同理。當(dāng)發(fā)電企業(yè)的用戶Org1-peer發(fā)出只能讓電網(wǎng)企業(yè)的用戶Org2-peer驗(yàn)證帶有“A”標(biāo)簽的待升級合約驗(yàn)證請求時，由設(shè)計的智能合約實(shí)現(xiàn)對用戶的訪問授權(quán)和合約信息的驗(yàn)證，規(guī)范性驗(yàn)證合約會判斷當(dāng)前運(yùn)行合約的節(jié)點(diǎn)的身份，然后到安全對接的IT服務(wù)商查詢合約信息的完整性、可靠性、真實(shí)性。

此外，當(dāng)聯(lián)盟鏈網(wǎng)絡(luò)的背書策略采用滿足任意成員簽名的背書策略時，若沒有智能合約對用戶的訪問控制，會導(dǎo)致每個peer節(jié)點(diǎn)都能執(zhí)行并驗(yàn)證智能合約，即在同一個通道內(nèi)的任意peer節(jié)點(diǎn)都能修改賬本，這使得數(shù)據(jù)存在一定的泄露風(fēng)險。因此，在智能合約內(nèi)制定面向用戶身份的訪問控制策略，有利于增強(qiáng)隱私數(shù)據(jù)的安全性。該策略指的是在任意成員簽名的背書策略情況下，同一個通道內(nèi)的peer節(jié)點(diǎn)有同等修改賬本的權(quán)利；在不同角色主體之間交互的情況下，智能合約能夠?qū)崿F(xiàn)不同角色主體的職能，以滿足各個主體的多種需求。如果該用戶具備驗(yàn)證待升級合約的有效性資質(zhì)，且待升級合約數(shù)據(jù)的驗(yàn)證結(jié)果符合訪問控制策略，則將合約的哈希值和版本號記入?yún)^(qū)塊連；否則，則拒絕該請求。

2.2 基于Fabric的電力交易合約升級應(yīng)用

本文將應(yīng)用場景范圍定位在有直接電力交易往來的發(fā)電企業(yè)、電網(wǎng)企業(yè)和配售電企業(yè)中，其中的電網(wǎng)企業(yè)位于交易供應(yīng)鏈的中游?；诖藨?yīng)用場景，實(shí)現(xiàn)了一個基于Fabric的電力交易合約升級應(yīng)用。該應(yīng)用的工作流程圖如圖4所示。在應(yīng)用程序運(yùn)行的過程中，整個工作流程由企業(yè)的普通用戶和應(yīng)用程序的交互、應(yīng)用程序和Fabric網(wǎng)絡(luò)的交互、智能合約和IT服務(wù)商的交互三部分組成。

圖4所示為企業(yè)的普通用戶經(jīng)過身份認(rèn)證之后進(jìn)行電力交易合約升級的過程。首先，普通用戶在電力交易應(yīng)用中執(zhí)行電力交易合約升級的命令；接著，應(yīng)用將這交易發(fā)送到Fabric網(wǎng)絡(luò)。在Fabric網(wǎng)絡(luò)內(nèi)執(zhí)行交易的過程中，智能合約對運(yùn)行合約的節(jié)點(diǎn)進(jìn)行身份驗(yàn)證，再將待升級合約的哈希值和版本號與存儲在IT服務(wù)商中的數(shù)據(jù)進(jìn)行比對，隨后得到比對后的結(jié)果；然后，當(dāng)這一交易在Fabric網(wǎng)絡(luò)內(nèi)執(zhí)行完成后，F(xiàn)abric網(wǎng)絡(luò)將交易執(zhí)行結(jié)果返回給電力交易應(yīng)用；最終，電力交易應(yīng)用返回執(zhí)行命令結(jié)果給用戶。

圖4 工作流程圖

3 電力供應(yīng)鏈交易合約設(shè)計與實(shí)現(xiàn)

3.1 聯(lián)盟鏈網(wǎng)絡(luò)

通過編寫組織結(jié)構(gòu)與身份證書、通道、組織的錨節(jié)點(diǎn)等配置文件，設(shè)計聯(lián)盟鏈網(wǎng)絡(luò)的結(jié)構(gòu)。在本應(yīng)用程序中，聯(lián)盟鏈的結(jié)構(gòu)示意圖如圖5所示。在聯(lián)盟鏈中，發(fā)電企業(yè)、電網(wǎng)企業(yè)和配售電企業(yè)分別用組織Org1、組織Org2和組織Org3表示，并且為每個組織配置兩個Peer節(jié)點(diǎn)，其中Org1中的Peer0節(jié)點(diǎn)、Org2中的Peer0節(jié)點(diǎn)和Org3中的Peer0節(jié)點(diǎn)作為錨節(jié)點(diǎn)，且每個組織分別擁有自己的CA機(jī)構(gòu)，記為ca-org1、ca-org2和ca-org3，用于頒發(fā)相應(yīng)組織的證書。聯(lián)盟鏈網(wǎng)絡(luò)提供了基于etcdraft共識的排序服務(wù)，并為聯(lián)盟創(chuàng)建了一條名為“SCMchannel”的應(yīng)用通道，Org1、Org2和Org3中的Peer節(jié)點(diǎn)加入應(yīng)用通道之后,可以安裝與交易數(shù)據(jù)上鏈相關(guān)的“example”智能合約。Peer節(jié)點(diǎn)物理上存放賬本ledger的副本，而賬本ledger邏輯上存放在“SCMchannel”應(yīng)用通道上。

圖5 聯(lián)盟鏈網(wǎng)絡(luò)結(jié)構(gòu)

本應(yīng)用程序采用基于容器的方式來快速部署網(wǎng)絡(luò)，事先需要編寫節(jié)點(diǎn)相應(yīng)的配置文件，然后使用docker-compose工具將配置文件作為參數(shù)，啟動提供網(wǎng)絡(luò)服務(wù)的各個節(jié)點(diǎn)。其中，docker-compose是一個Python程序，可以快速管理由多個Docker容器組成的服務(wù)。

3.2 智能合約

3.2.1 背書節(jié)點(diǎn)身份的獲取

在Fabric中，實(shí)體的身份驗(yàn)證可以由成員服務(wù)提供者(Membership Service Provider，MSP)實(shí)現(xiàn)。成員服務(wù)提供者這一機(jī)制不僅能確認(rèn)實(shí)體的數(shù)據(jù)簽名，也能驗(yàn)證簽名者的身份。Fabric中的組織代表一組擁有相同信任的根證書的成員。通常，同一個企業(yè)組織屬于同一個MSP，同一個組織的成員節(jié)點(diǎn)在網(wǎng)絡(luò)中可以被認(rèn)為是同一個身份，代表組織進(jìn)行簽名。換句話說，統(tǒng)一組織內(nèi)的成員節(jié)點(diǎn)有著相同的MSP信息。

在啟動Fabric網(wǎng)絡(luò)中所有的Peer節(jié)點(diǎn)之前，首先會檢查節(jié)點(diǎn)啟動所需的配置的完備性。在Peer節(jié)點(diǎn)的配置文件中，指定了Peer節(jié)點(diǎn)的環(huán)境變量配置，其中與所屬組織MSP有關(guān)的環(huán)境變量是“CORE_PEER_LOCALMSPID”，該環(huán)境變量表示Peer節(jié)點(diǎn)所屬組織的MSP的ID值，可以記為mspid。例如，若該組織名為“Org1”，mspid則為“Org1MSP”；若該組織名為“Org2”，mspid則為“Org2MSP”。

當(dāng)Fabric將Go語言作為編程語言時，在鏈碼容器的shim層，通過使用“os”包下的Getenv()方法，獲取執(zhí)行合約的背書節(jié)點(diǎn)的“CORE_PEER_LOCALMSPID”環(huán)境變量的值，然后再將該值傳給智能合約。由此，智能合約獲得了當(dāng)前背書節(jié)點(diǎn)的身份，為實(shí)現(xiàn)個性化的訪問控制授權(quán)做好準(zhǔn)備。

3.2.2 智能合約與IT服務(wù)商的對接

為了實(shí)現(xiàn)待升級合約數(shù)據(jù)的校驗(yàn)，在智能合約內(nèi)實(shí)現(xiàn)驗(yàn)證合約數(shù)據(jù)的業(yè)務(wù)邏輯的過程中，需向IT服務(wù)商請求查詢數(shù)據(jù)庫中該數(shù)據(jù)是否存在。通常，HTTP協(xié)議定義了客戶端與服務(wù)器交互的不同方法。在上鏈數(shù)據(jù)的校驗(yàn)這一情景下，選擇用于獲取或查詢資源信息的HTTP GET方法。

Golang語言編寫的GET請求中的URL地址依次由服務(wù)器IP、端口號、信息系統(tǒng)的項(xiàng)目名稱、項(xiàng)目內(nèi)自定義的路徑、GET請求附帶的鍵值對組成。

GET請求回復(fù)消息為“true”或“false”，使用該值可以校驗(yàn)待升級合約數(shù)據(jù)的真實(shí)性、可靠性和完整性。

3.3 IT服務(wù)商

IT服務(wù)商的設(shè)計主要分為系統(tǒng)的分層結(jié)構(gòu)設(shè)計、數(shù)據(jù)校驗(yàn)功能模塊設(shè)計三個部分。

3.3.1 系統(tǒng)的分層結(jié)構(gòu)設(shè)計

IT服務(wù)商采用了Spring MVC框架進(jìn)行架構(gòu)設(shè)計，系統(tǒng)內(nèi)部在結(jié)構(gòu)上可分為Controller層、DAO層和Impl層，具體實(shí)現(xiàn)的時序圖如圖6所示。

圖6 IT服務(wù)商的分層結(jié)構(gòu)

鏈碼層通過HTTP協(xié)議向IT服務(wù)商內(nèi)部的Controller層發(fā)送請求，收到請求的Controller層將調(diào)用DAO層的接口，以將業(yè)務(wù)交付給DAO層；DAO層為業(yè)務(wù)邏輯的設(shè)計了具體的類，該層業(yè)務(wù)邏輯的實(shí)現(xiàn)需調(diào)用Impl層接口完成；Impl層封裝了對數(shù)據(jù)庫的交互動作。當(dāng)Impl層和數(shù)據(jù)庫完成交互后，底層的MySQL數(shù)據(jù)庫返回的訪問結(jié)果將依次經(jīng)過Impl層、DAO層、Controller層進(jìn)行結(jié)果的分析和封裝，最終的請求結(jié)果將返回給鏈碼。

3.3.2 數(shù)據(jù)校驗(yàn)功能模塊設(shè)計

與智能合約對接的IT服務(wù)商最重要的功能是校驗(yàn)交易數(shù)據(jù)的真實(shí)性、完整性和可靠性，因此在Controller層設(shè)計checkAccount()方法，接收智能合約請求、校驗(yàn)數(shù)據(jù)、返回請求結(jié)果，該過程的流程圖如圖7所示。

圖7 數(shù)據(jù)校驗(yàn)方法的流程圖

3.4 基于Node.js SDK的應(yīng)用

在完成聯(lián)盟鏈網(wǎng)絡(luò)設(shè)計之后，F(xiàn)abric提供了Node.js、Python、Java、Go等多種語言實(shí)現(xiàn)SDK應(yīng)用程序的開發(fā)。本文選擇功能較成熟和完善的Node.js語言進(jìn)行開發(fā)，實(shí)現(xiàn)用戶通過應(yīng)用程序與聯(lián)盟鏈進(jìn)行交互并完成交易?；贜ode.js SDK的應(yīng)用程序的設(shè)計主要分為啟動網(wǎng)絡(luò)和關(guān)閉網(wǎng)絡(luò)的腳本設(shè)計、應(yīng)用程序和網(wǎng)絡(luò)交互設(shè)計兩部分。

3.4.1 啟動網(wǎng)絡(luò)和關(guān)閉網(wǎng)絡(luò)的腳本設(shè)計

啟動網(wǎng)絡(luò)的腳本設(shè)計目標(biāo)是：依據(jù)配置文件建立網(wǎng)絡(luò)，啟動鏈碼容器，并將智能合約安裝在節(jié)點(diǎn)上。啟動網(wǎng)絡(luò)具體的步驟如下：

(1)設(shè)置網(wǎng)絡(luò)搭建的啟動時間、智能合約的編程語言、智能合約的位置等環(huán)境變量；

(2)清除掉當(dāng)前還在運(yùn)行或活躍的容器等，以確保搭建Fabric網(wǎng)絡(luò)前的環(huán)境是干凈的；

(3)生成組織結(jié)構(gòu)與身份證書；

(4)成系統(tǒng)通道的創(chuàng)世區(qū)塊文件genesis.block；

(5)生成應(yīng)用通道交易配置文件channel.tx；

(6)生成錨節(jié)點(diǎn)更新配置文件Org1MSPanchors.tx、Org2MSPanchors.tx和Org3MSPanchors.tx，并采用基于容器的方式來快速部署網(wǎng)絡(luò)；

(7)創(chuàng)建使Peer節(jié)點(diǎn)加入的“SCMchannel”通道；

(8)將peer0.org1、peer0.org2和peer0.org3更新為錨節(jié)點(diǎn)；

(9)org1、org2、org3組織中的節(jié)點(diǎn)進(jìn)行鏈碼的打包、鏈碼的安裝以及安裝的驗(yàn)證，并需要org1、org2、org3組織分別同意鏈碼定義；

(10)在滿足了鏈碼定義的策略后，提交智能合約；

(11)輸出啟動網(wǎng)絡(luò)所用的時間、應(yīng)用與Fabric網(wǎng)絡(luò)進(jìn)行交互的命令。

關(guān)閉網(wǎng)絡(luò)的腳本設(shè)計目標(biāo)是：暫停并移除網(wǎng)絡(luò)中的容器節(jié)點(diǎn)、刪除網(wǎng)絡(luò)啟動過程生成的配置文件、刪除賬本備份和清除鏡像文件，以實(shí)現(xiàn)清理網(wǎng)絡(luò)環(huán)境的目的。

3.4.2 應(yīng)用程序和網(wǎng)絡(luò)交互設(shè)計

由于只有被CA機(jī)構(gòu)認(rèn)可的身份才能夠在Fabric上進(jìn)行交易，因此用戶在首次使用該應(yīng)用程序時，需先登記管理員用戶，接著注冊、登記普通用戶，最后查詢或更新賬本。

管理員用戶和普通用戶的登記流程如圖8所示。首先，“enrollAdmin.js”實(shí)現(xiàn)了向ca-org1認(rèn)證機(jī)構(gòu)注冊ID為“admin”、密文為“adminpw”的管理員，管理員將收到證書、簽名私鑰、mspId值和證書類型信息。接著，“registerUser.js”是實(shí)現(xiàn)了管理員在ca-org1機(jī)構(gòu)注冊一個普通用戶，ca-org1機(jī)構(gòu)將返回密文。最后，密文用于普通用戶在ca-org1機(jī)構(gòu)的登記，登記完成后，普通用戶將收到證書、簽名私鑰、mspId值和證書類型信息，這些信息將被用于后續(xù)的交易數(shù)據(jù)上鏈操作。

圖8 登記管理員用戶和普通用戶

接下來將設(shè)計交易數(shù)據(jù)上鏈相關(guān)的功能。為了減輕應(yīng)用程序的負(fù)擔(dān)，F(xiàn)abric v2.0在原本的SDK基礎(chǔ)上加了一層網(wǎng)關(guān)Gateway，用于將認(rèn)證過的普通用戶連接到某個組織的Peer節(jié)點(diǎn)。因此，基于Node.js實(shí)現(xiàn)SDK的特點(diǎn)，實(shí)現(xiàn)應(yīng)用程序功能的基本過程如下：

(1)加載網(wǎng)絡(luò)連接對象相關(guān)的配置；

(2)創(chuàng)建管理身份的流式文件，記為錢包；

(3)獲得普通用戶的身份，并檢查用戶是否登記過，若還未登記過，功能函數(shù)將在此處結(jié)束，返回空值；

(4)若用戶已經(jīng)登記過，接下來創(chuàng)建一個網(wǎng)關(guān)；

(5)利用網(wǎng)關(guān)，根據(jù)通道名稱“SCMchannel”，獲得部署在Fabric網(wǎng)絡(luò)中的通道對象；

(6)根據(jù)打包后的智能合約名稱，獲得合約對象；

(7)若要實(shí)現(xiàn)查詢交易方或賬本數(shù)據(jù)的功能，調(diào)用智能合約對象的evaluateTransaction()方法，相關(guān)參數(shù)作為傳入值；若要實(shí)現(xiàn)注冊交易方、交易數(shù)據(jù)上鏈等更新賬本的功能，調(diào)用智能合約對象的submit-Transaction()方法，相關(guān)參數(shù)作為傳入值。用戶可以通過修改evaluateTransaction()方法和submitTransaction()方法傳入的參數(shù)，實(shí)現(xiàn)不同功能。

4 仿真實(shí)驗(yàn)及分析

4.1 仿真實(shí)驗(yàn)環(huán)境測試

4.1.1 環(huán)境配置

為了對本文所述方案進(jìn)行驗(yàn)證，實(shí)驗(yàn)環(huán)境配置如下：具體來說，每個Fabric節(jié)點(diǎn)被部署在相同配置的服務(wù)器上，它們使用相同類型的vCPU(e3-1220 V5＠3.00 GHz)，內(nèi)存大小為8 GB。所有服務(wù)器都在同一個局域網(wǎng)中，交換機(jī)的速率為1.0 Gb/s。此外，當(dāng)前Fabric網(wǎng)絡(luò)內(nèi)部的節(jié)點(diǎn)共識將基于raft共識算法，使用五個排序節(jié)點(diǎn)來提供排序服務(wù)。

本文中將設(shè)定每一個部門節(jié)點(diǎn)(即org)都對應(yīng)一個peer，并將針對不同數(shù)量的peer節(jié)點(diǎn)測試了兩個典型背書策略：“任意peer節(jié)點(diǎn)”、“全部peer節(jié)點(diǎn)”和個性化背書策略—“指定peer節(jié)點(diǎn)”三種。在驗(yàn)證過程中，每類實(shí)驗(yàn)重復(fù)5輪，取平均值作為最終結(jié)果。策略的含義如下：“任意peer節(jié)點(diǎn)”表示客戶端將交易提議發(fā)送給任意候選peer節(jié)點(diǎn)進(jìn)行背書，在Fabric中對這種背書方式進(jìn)行了一些優(yōu)化，即具備一定的負(fù)載均衡屬性；“全部peer節(jié)點(diǎn)”表示客戶端將交易提議發(fā)送給全部候選peer節(jié)點(diǎn)進(jìn)行背書；最后，“指定peer節(jié)點(diǎn)”是客戶端只指定一個候選peer節(jié)點(diǎn)作為目標(biāo)背書節(jié)點(diǎn)，即本文工作。

4.1.2 工作負(fù)載和評測程序

本文使用的智能合約是powerDataOnChain，旨在模擬電力客戶對智能合約升級的常見操作，包括管理員用戶的注冊、普通用戶的注冊、交易者的注冊、待升級合約數(shù)據(jù)的上鏈、交易者信息的查詢、已上鏈的待升級合約數(shù)據(jù)的查詢、交易者賬戶的注銷等。對于實(shí)驗(yàn)工作負(fù)載，本文為powerDataOnChain合約準(zhǔn)備了20 000個假交易者賬戶。由于硬件資源有限，客戶端只能以500次/秒的速度發(fā)送交易。

4.2 實(shí)驗(yàn)結(jié)果及評估

4.2.1 平均每秒交易數(shù)

Fabric網(wǎng)絡(luò)的吞吐量通常用平均每秒交易數(shù)(TPS)來表示，peer節(jié)點(diǎn)數(shù)量的變化對TPS影響的結(jié)果如圖9所示。隨著peer節(jié)點(diǎn)數(shù)量的增加，三種策略的TPS均有所降低且趨于穩(wěn)定。“任意peer節(jié)點(diǎn)”策略下的TPS值均高于其他兩種策略。這是因?yàn)楫?dāng)Fabric網(wǎng)絡(luò)的背書策略采用滿足任意成員簽名的背書策略且用戶對數(shù)據(jù)的訪問權(quán)限受限時，最好的情況是所選擇的背書節(jié)點(diǎn)正好具備對數(shù)據(jù)的訪問權(quán)限，從而可以進(jìn)行背書，因此該情況下工作流程的平均每秒交易數(shù)最高，進(jìn)而響應(yīng)速度最快。

圖9 Fabric網(wǎng)絡(luò)的平均吞吐量

當(dāng)peer節(jié)點(diǎn)數(shù)量大于6時，“指定peer節(jié)點(diǎn)”策略的TPS持續(xù)略高于“全部peer節(jié)點(diǎn)”策略。當(dāng)peer節(jié)點(diǎn)的數(shù)量足夠大時，“全部peer節(jié)點(diǎn)”策略需要選擇遍歷過所有節(jié)點(diǎn)才找到可以真正背書的節(jié)點(diǎn)，因此該情況下工作流程的平均每秒交易數(shù)最小，進(jìn)而導(dǎo)致響應(yīng)速度最慢。由于智能合約個性化升級方法在智能合約內(nèi)制定面向用戶身份的訪問控制策略，因此，“指定peer節(jié)點(diǎn)”策略的工作流程的平均每秒交易數(shù)介于其他兩種策略之間，從而響應(yīng)速度也處于中間水平。

4.2.2 數(shù)據(jù)安全

在傳統(tǒng)的智能合約升級中，區(qū)塊鏈網(wǎng)絡(luò)設(shè)置背書策略之后，所有滿足背書策略的節(jié)點(diǎn)將共享相同的合約的升級驗(yàn)證數(shù)據(jù)，這難以滿足電力供應(yīng)鏈場景下多方機(jī)構(gòu)對本方數(shù)據(jù)隱私保密的個性化需求。智能合約個性化升級方法則是基于機(jī)構(gòu)對本方數(shù)據(jù)隱私保密的需求而設(shè)計的，該方法使得只有加入聯(lián)盟鏈網(wǎng)絡(luò)的實(shí)體才可以查看聯(lián)盟鏈上的所有信息，通過智能合約驗(yàn)證后的實(shí)體才可實(shí)現(xiàn)合約的升級，這有利于保證合約數(shù)據(jù)的安全性，進(jìn)而確保網(wǎng)絡(luò)底層的數(shù)據(jù)安全。

5 結(jié)論

本文基于聯(lián)盟鏈平臺，構(gòu)建了基于智能合約的個性化升級模型，使得具有驗(yàn)證上鏈數(shù)據(jù)有效性資質(zhì)的電力企業(yè)負(fù)責(zé)驗(yàn)證上鏈數(shù)據(jù)。同時將該模型應(yīng)用在電力供應(yīng)鏈的場景中，設(shè)計實(shí)現(xiàn)了基于Fabric的電力交易合約更新應(yīng)用。本文將區(qū)塊鏈的智能合約融入到面向用戶的訪問控制和待升級合約數(shù)據(jù)的驗(yàn)證中，有效增強(qiáng)了對待升級智能合約的合法、合規(guī)性做出的背書保證，推動了鏈上鏈下合約升級數(shù)據(jù)的協(xié)同發(fā)展，進(jìn)而提高了智能合約升級的安全性和可靠性。