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

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

(1.國網電子商務有限公司(國網雄安金融科技集團有限公司)，北京100053；2.國網區塊鏈科技(北京)有限公司，北京100053；3.中國科學院 信息工程研究所，北京100093；4.國家電網有限公司區塊鏈技術實驗室，北京100053；5.國網江蘇省電力有限公司，江蘇 南京210000)

0 引言

隨著電力體制改革加快推進，電力行業逐漸從垂直一體化的內部供應鏈體系，轉變為由多個相對獨立環節構成的外部供應鏈體系。根據電產品的生產和流通過程，電產品的生產、輸送、分配和銷售等環節將構成一條完整的電力供應鏈。電力供應鏈上的主體角色多樣，包括了獨立生產、分配、銷售電力的企業和電力用戶。電力企業通過實施供應鏈管理，有效降低了成本以保證收益，也使得供應鏈的總體流動效率和電力企業的管理水平得到了顯著的提高。

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

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

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

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

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

1 相關背景

1.1 Hyperledger Fabric

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

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

Fabric中的一筆成功交易從客戶端提交交易給背書節點開始，到確認節點將狀態改變更新到區塊中結束。具體的交易流程如圖1所示。

圖1 Fabric的交易流程

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

(1)背書階段

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

(2)排序階段

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

(3)驗證階段

在驗證階段，錨節點收到區塊后，先驗證交易和區塊是否有效，驗證通過之后將執行區塊中的有效交易，并根據交易執行的結果對賬本狀態進行更新。之后將區塊同步給組織內的其他節點，其他節點也需驗證交易和區塊，最后組織內所有節點的賬本都會得到更新。

正是上述所描述的三個階段組成了Fabric的共識機制，實現了Fabric內大部分節點對多個事件發生的順序、某個鍵對應的值、誰是主節點等某個提案信息達成了一致。

1.2 典型電力供應鏈模式概述

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

圖2 電力供應鏈的上下游主體關系

2 智能合約個性化升級模型和應用的設計

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

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

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

假設發電企業Org1、電網企業Org2、配售電企業Org3都采用基于智能合約的個性化升級模型，并且各個企業在鏈下擁有不完全相同的電力交易數據庫。Org1-peer、Org2-peer、Org3-peer代表企業用戶，也是實際的Fabric網絡節點，其中只有Org1-peer才有權限訪問Org1的IT服務商，Org2-peer和Org3-peer同理。當發電企業的用戶Org1-peer發出只能讓電網企業的用戶Org2-peer驗證帶有“A”標簽的待升級合約驗證請求時，由設計的智能合約實現對用戶的訪問授權和合約信息的驗證，規范性驗證合約會判斷當前運行合約的節點的身份，然后到安全對接的IT服務商查詢合約信息的完整性、可靠性、真實性。

此外，當聯盟鏈網絡的背書策略采用滿足任意成員簽名的背書策略時，若沒有智能合約對用戶的訪問控制，會導致每個peer節點都能執行并驗證智能合約，即在同一個通道內的任意peer節點都能修改賬本，這使得數據存在一定的泄露風險。因此，在智能合約內制定面向用戶身份的訪問控制策略，有利于增強隱私數據的安全性。該策略指的是在任意成員簽名的背書策略情況下，同一個通道內的peer節點有同等修改賬本的權利；在不同角色主體之間交互的情況下，智能合約能夠實現不同角色主體的職能，以滿足各個主體的多種需求。如果該用戶具備驗證待升級合約的有效性資質，且待升級合約數據的驗證結果符合訪問控制策略，則將合約的哈希值和版本號記入區塊連；否則，則拒絕該請求。

2.2 基于Fabric的電力交易合約升級應用

本文將應用場景范圍定位在有直接電力交易往來的發電企業、電網企業和配售電企業中，其中的電網企業位于交易供應鏈的中游。基于此應用場景，實現了一個基于Fabric的電力交易合約升級應用。該應用的工作流程圖如圖4所示。在應用程序運行的過程中，整個工作流程由企業的普通用戶和應用程序的交互、應用程序和Fabric網絡的交互、智能合約和IT服務商的交互三部分組成。

圖4所示為企業的普通用戶經過身份認證之后進行電力交易合約升級的過程。首先，普通用戶在電力交易應用中執行電力交易合約升級的命令；接著，應用將這交易發送到Fabric網絡。在Fabric網絡內執行交易的過程中，智能合約對運行合約的節點進行身份驗證，再將待升級合約的哈希值和版本號與存儲在IT服務商中的數據進行比對，隨后得到比對后的結果；然后，當這一交易在Fabric網絡內執行完成后，Fabric網絡將交易執行結果返回給電力交易應用；最終，電力交易應用返回執行命令結果給用戶。

圖4 工作流程圖

3 電力供應鏈交易合約設計與實現

3.1 聯盟鏈網絡

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

圖5 聯盟鏈網絡結構

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

3.2 智能合約

3.2.1 背書節點身份的獲取

在Fabric中，實體的身份驗證可以由成員服務提供者(Membership Service Provider，MSP)實現。成員服務提供者這一機制不僅能確認實體的數據簽名，也能驗證簽名者的身份。Fabric中的組織代表一組擁有相同信任的根證書的成員。通常，同一個企業組織屬于同一個MSP，同一個組織的成員節點在網絡中可以被認為是同一個身份，代表組織進行簽名。換句話說，統一組織內的成員節點有著相同的MSP信息。

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

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

3.2.2 智能合約與IT服務商的對接

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

Golang語言編寫的GET請求中的URL地址依次由服務器IP、端口號、信息系統的項目名稱、項目內自定義的路徑、GET請求附帶的鍵值對組成。

GET請求回復消息為“true”或“false”，使用該值可以校驗待升級合約數據的真實性、可靠性和完整性。

3.3 IT服務商

IT服務商的設計主要分為系統的分層結構設計、數據校驗功能模塊設計三個部分。

3.3.1 系統的分層結構設計

IT服務商采用了Spring MVC框架進行架構設計，系統內部在結構上可分為Controller層、DAO層和Impl層，具體實現的時序圖如圖6所示。

圖6 IT服務商的分層結構

鏈碼層通過HTTP協議向IT服務商內部的Controller層發送請求，收到請求的Controller層將調用DAO層的接口，以將業務交付給DAO層；DAO層為業務邏輯的設計了具體的類，該層業務邏輯的實現需調用Impl層接口完成；Impl層封裝了對數據庫的交互動作。當Impl層和數據庫完成交互后，底層的MySQL數據庫返回的訪問結果將依次經過Impl層、DAO層、Controller層進行結果的分析和封裝，最終的請求結果將返回給鏈碼。

3.3.2 數據校驗功能模塊設計

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

圖7 數據校驗方法的流程圖

3.4 基于Node.js SDK的應用

在完成聯盟鏈網絡設計之后，Fabric提供了Node.js、Python、Java、Go等多種語言實現SDK應用程序的開發。本文選擇功能較成熟和完善的Node.js語言進行開發，實現用戶通過應用程序與聯盟鏈進行交互并完成交易。基于Node.js SDK的應用程序的設計主要分為啟動網絡和關閉網絡的腳本設計、應用程序和網絡交互設計兩部分。

3.4.1 啟動網絡和關閉網絡的腳本設計

啟動網絡的腳本設計目標是：依據配置文件建立網絡，啟動鏈碼容器，并將智能合約安裝在節點上。啟動網絡具體的步驟如下：

(1)設置網絡搭建的啟動時間、智能合約的編程語言、智能合約的位置等環境變量；

(2)清除掉當前還在運行或活躍的容器等，以確保搭建Fabric網絡前的環境是干凈的；

(3)生成組織結構與身份證書；

(4)成系統通道的創世區塊文件genesis.block；

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

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

(7)創建使Peer節點加入的“SCMchannel”通道；

(8)將peer0.org1、peer0.org2和peer0.org3更新為錨節點；

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

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

(11)輸出啟動網絡所用的時間、應用與Fabric網絡進行交互的命令。

關閉網絡的腳本設計目標是：暫停并移除網絡中的容器節點、刪除網絡啟動過程生成的配置文件、刪除賬本備份和清除鏡像文件，以實現清理網絡環境的目的。

3.4.2 應用程序和網絡交互設計

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

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

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

接下來將設計交易數據上鏈相關的功能。為了減輕應用程序的負擔，Fabric v2.0在原本的SDK基礎上加了一層網關Gateway，用于將認證過的普通用戶連接到某個組織的Peer節點。因此，基于Node.js實現SDK的特點，實現應用程序功能的基本過程如下：

(1)加載網絡連接對象相關的配置；

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

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

(4)若用戶已經登記過，接下來創建一個網關；

(5)利用網關，根據通道名稱“SCMchannel”，獲得部署在Fabric網絡中的通道對象；

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

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

4 仿真實驗及分析

4.1 仿真實驗環境測試

4.1.1 環境配置

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

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

4.1.2 工作負載和評測程序

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

4.2 實驗結果及評估

4.2.1 平均每秒交易數

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

圖9 Fabric網絡的平均吞吐量

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

4.2.2 數據安全

在傳統的智能合約升級中，區塊鏈網絡設置背書策略之后，所有滿足背書策略的節點將共享相同的合約的升級驗證數據，這難以滿足電力供應鏈場景下多方機構對本方數據隱私保密的個性化需求。智能合約個性化升級方法則是基于機構對本方數據隱私保密的需求而設計的，該方法使得只有加入聯盟鏈網絡的實體才可以查看聯盟鏈上的所有信息，通過智能合約驗證后的實體才可實現合約的升級，這有利于保證合約數據的安全性，進而確保網絡底層的數據安全。

5 結論

本文基于聯盟鏈平臺，構建了基于智能合約的個性化升級模型，使得具有驗證上鏈數據有效性資質的電力企業負責驗證上鏈數據。同時將該模型應用在電力供應鏈的場景中，設計實現了基于Fabric的電力交易合約更新應用。本文將區塊鏈的智能合約融入到面向用戶的訪問控制和待升級合約數據的驗證中，有效增強了對待升級智能合約的合法、合規性做出的背書保證，推動了鏈上鏈下合約升級數據的協同發展，進而提高了智能合約升級的安全性和可靠性。