基于Fabric的電網(wǎng)采購交易數(shù)據(jù)平臺①

李冉冉, 周少丹

(南方電網(wǎng)物資有限公司, 廣州 510655)

近年來, 隨著電子商務(wù)和管理信息化的迅猛發(fā)展,基于紙質(zhì)標(biāo)書的傳統(tǒng)招投標(biāo)活動弊端日益凸顯. 采用傳統(tǒng)紙質(zhì)標(biāo)書投標(biāo), 不僅成本高昂、效率低下, 還存在諸如人為因素多、過程透明度低、標(biāo)書存檔利用困難、不符合低碳環(huán)保要求等缺點(diǎn). 為此, 電子化招投標(biāo)應(yīng)運(yùn)而生, 成為招標(biāo)采購中的主流模式.

為了貫徹國家關(guān)于電子化招投標(biāo)的精神, 南方電網(wǎng)物資有限公司于2019年完成南方電網(wǎng)電子采購交易平臺建設(shè)工作. 該平臺支持各類招標(biāo)及非招標(biāo)采購方式, 實(shí)現(xiàn)發(fā)投標(biāo)、開評標(biāo)、費(fèi)用支付、歸檔等全過程線上辦理, 且已獲得電子招標(biāo)投標(biāo)系統(tǒng)交易平臺最高等級“三星”認(rèn)證. 截至2021年9月, 業(yè)務(wù)項(xiàng)目的采購金額已突破100億元. 與傳統(tǒng)招投標(biāo)相比, 電子化招投標(biāo)技術(shù)的應(yīng)用, 在招投標(biāo)效率、數(shù)據(jù)準(zhǔn)確性、節(jié)省人力物力、提高采購過程公正性等方面帶來了巨大進(jìn)步. 但是, 招投標(biāo)過程涉及環(huán)節(jié)多、信息量大且信息敏感, 仍然存在一些必須解決的問題.

隨著區(qū)塊鏈技術(shù)的發(fā)展, 其有望于解決電子化招投標(biāo)過程中存在的問題, 并且將區(qū)塊鏈應(yīng)用于電子招投標(biāo)也成為了當(dāng)前電子招投標(biāo)研究的熱點(diǎn). 文獻(xiàn)[1]將智能合約應(yīng)用于政府招標(biāo), 構(gòu)建一個(gè)公平、透明且可審計(jì)的政府招標(biāo)平臺. 文獻(xiàn)[2]提出一種應(yīng)用在以太坊區(qū)塊鏈上進(jìn)行簡潔可驗(yàn)證的密封投標(biāo)拍賣的智能合約協(xié)議. 文獻(xiàn)[3]引入了基于區(qū)塊鏈的電子投標(biāo)系統(tǒng), 在不需要可信第三方的情況下, 由智能合約處理所有投標(biāo)交易, 確保投標(biāo)過程的完整性. 文獻(xiàn)[4]提出了“大數(shù)據(jù)＋區(qū)塊鏈技術(shù)”在電子招投標(biāo)平臺的應(yīng)用方案, 保證招投標(biāo)活動的“公平、公正、公開”. 文獻(xiàn)[5]提出了一種基于區(qū)塊鏈的可信電子投標(biāo)系統(tǒng)(BCES), 以解決投標(biāo)數(shù)據(jù)文件分發(fā)、驗(yàn)證和回溯過程中的操作合規(guī)性、多方協(xié)調(diào)和網(wǎng)絡(luò)安全問題. 文獻(xiàn)[6]考慮到拍賣的隱私性和安全約束, 提出了基于區(qū)塊鏈的公開競價(jià)拍賣系統(tǒng)框架, 增強(qiáng)了拍賣人和投標(biāo)人之間的安全性. 文獻(xiàn)[7]提出了基于以太坊區(qū)塊鏈的解決方案, 以確保數(shù)據(jù)完整性和透明度并消除中間人.

上述文獻(xiàn)研究了將區(qū)塊鏈技術(shù)應(yīng)用于電子化招投標(biāo)中. 然而, 當(dāng)前在面向電力行業(yè)的電子化招投標(biāo)應(yīng)用較少, 區(qū)塊鏈技術(shù)未能賦能電力物資供應(yīng)鏈電子化招投標(biāo), 導(dǎo)致在電力行業(yè)中電子化招投標(biāo)過程中數(shù)據(jù)的真實(shí)性及合法性仍被質(zhì)疑, 影響并阻礙了南方電網(wǎng)電子采購交易平臺建設(shè)工作的進(jìn)一步展開. 因此在電子招采過程中, 如何將區(qū)塊鏈技術(shù)應(yīng)用于電網(wǎng)企業(yè)的電子化招投標(biāo)過程, 并且保證數(shù)據(jù)的防篡改, 將具有非常重要現(xiàn)實(shí)意義.

1 問題與挑戰(zhàn)

南方電網(wǎng)電子化招投標(biāo)和傳統(tǒng)的紙質(zhì)化現(xiàn)場招投標(biāo)相比, 采購交易形式發(fā)生了較大的變化, 減少了傳統(tǒng)的人力、物力投入, 但存在以下兩個(gè)問題:

(1)數(shù)據(jù)真實(shí)性問題

與傳統(tǒng)招投標(biāo)相比, 電子化招投標(biāo)技術(shù)的應(yīng)用, 在招投標(biāo)效率、數(shù)據(jù)準(zhǔn)確性、節(jié)省人力物力、提高采購過程公正性等方面帶來了巨大進(jìn)步. 但是, 招投標(biāo)過程涉及環(huán)節(jié)多, 信息量大且信息敏感, 仍然存在一些必須解決的問題. 如: 交易數(shù)據(jù)的真實(shí)性與完整性容易讓人質(zhì)疑, 監(jiān)管部門難以對交易數(shù)據(jù)進(jìn)行有效的核驗(yàn), 平臺主體間的信任危機(jī)以及針對招投標(biāo)公平性的質(zhì)疑時(shí)有出現(xiàn), 因數(shù)據(jù)共享不暢導(dǎo)致的招標(biāo)投標(biāo)組織工作負(fù)擔(dān)重、效率低, 以及數(shù)據(jù)驗(yàn)證不好追溯等問題.

(2)中心化數(shù)據(jù)存儲易篡改問題

目前的采購及電子招投標(biāo)信息都采用集中式存儲方式, 由系統(tǒng)管理員進(jìn)行數(shù)據(jù)管理, 包括數(shù)據(jù)錄入、數(shù)據(jù)查詢、數(shù)據(jù)添加、數(shù)據(jù)刪除、數(shù)據(jù)更新等各種操作.由于系統(tǒng)管理員擁有數(shù)據(jù)處理的所有權(quán)限, 其可以不經(jīng)授權(quán)私自篡改數(shù)據(jù); 也可以在領(lǐng)導(dǎo)授意下篡改數(shù)據(jù),從而無法保證招投標(biāo)信息的真實(shí)性, 影響采購和招投標(biāo)的公平公正, 也給廉政建設(shè)帶來隱患. 此外, 集中式的數(shù)據(jù)存儲還容易受到內(nèi)/外部攻擊[8]; 有很多企業(yè)采用數(shù)據(jù)異地冗余備份技術(shù)[9,10], 但這顯然大幅度增加了數(shù)據(jù)存儲和數(shù)據(jù)維護(hù)的成本.

區(qū)塊鏈技術(shù)具有分布式共享、防篡改、數(shù)據(jù)可追溯等特點(diǎn), 可以有效解決數(shù)據(jù)被篡改的問題. 區(qū)塊鏈技術(shù)是利用塊鏈?zhǔn)綌?shù)據(jù)結(jié)構(gòu)來驗(yàn)證與存儲數(shù)據(jù)、利用分布式節(jié)點(diǎn)共識算法來生成和更新賬本數(shù)據(jù)、利用密碼學(xué)方式保證數(shù)據(jù)傳輸和訪問安全、利用智能合約來編程和操作數(shù)據(jù)的一種全新的分布式計(jì)算范式[11], 具有分布式共享、非篡改、數(shù)據(jù)可追溯的特點(diǎn), 可以解決數(shù)據(jù)可信和單點(diǎn)故障、遭受攻擊等問題, 因此在電力行業(yè)得到了豐富的應(yīng)用[12–16].

本文將結(jié)合數(shù)據(jù)分片、數(shù)據(jù)指紋、數(shù)據(jù)指紋數(shù)據(jù)庫、智能合約等技術(shù), 設(shè)計(jì)與實(shí)現(xiàn)基于Fabric的電網(wǎng)采購交易數(shù)據(jù)平臺, 平臺面向電力物資供應(yīng)鏈領(lǐng)域, 實(shí)現(xiàn)了采購交易數(shù)據(jù)不可篡改、數(shù)據(jù)隨時(shí)可驗(yàn)證、數(shù)據(jù)訪問控制等功能, 從而保證在電子招標(biāo)采購過程中數(shù)據(jù)的完整性、真實(shí)性, 同時(shí)減少人工參與, 從而減少人為篡改數(shù)據(jù)的風(fēng)險(xiǎn).

2 電網(wǎng)采購交易數(shù)據(jù)平臺

本節(jié)介紹平臺的具體細(xì)節(jié), 第2.1節(jié)對原型系統(tǒng)的總體架構(gòu)進(jìn)行描述, 并且對技術(shù)選型以及整個(gè)采購交易業(yè)務(wù)流程進(jìn)行說明, 第2.2節(jié)、第2.3節(jié)及第2.4節(jié)對重要模塊進(jìn)行說明, 其描述的模塊分別為數(shù)據(jù)訪問控制權(quán)限模塊、數(shù)據(jù)訪問控制權(quán)限模塊以及數(shù)據(jù)取證及驗(yàn)證模塊.

2.1 系統(tǒng)總體架構(gòu)

基于Fabric的電網(wǎng)采購交易數(shù)據(jù)平臺分為底層區(qū)塊鏈、數(shù)據(jù)存儲層、系統(tǒng)層以及門戶層, 如圖1所示.底層區(qū)塊鏈模塊主要負(fù)責(zé)采購交易的信息及全流程行為, 數(shù)據(jù)一旦上鏈, 無法篡改. 監(jiān)管機(jī)構(gòu)對智能合約進(jìn)行簽名認(rèn)證, 參與方通過智能合約提交中間結(jié)果, 驗(yàn)證方通過智能合約驗(yàn)證中間結(jié)果. 數(shù)據(jù)存儲層用于多云互聯(lián)管理系統(tǒng)存儲, 包含關(guān)系型數(shù)據(jù)庫、非關(guān)系型數(shù)據(jù)庫、分布式文件系統(tǒng)、對象存儲等. 系統(tǒng)層用于平臺業(yè)務(wù)實(shí)現(xiàn), 包含數(shù)據(jù)管理、上鏈管理、合約管理、用戶管理、權(quán)限管理等模塊. 門戶層用于給各類不同用戶提供一致的操作體驗(yàn), 包含數(shù)據(jù)可視化門戶、服務(wù)門戶、管理門戶、運(yùn)營門戶模塊.

圖1 系統(tǒng)架構(gòu)

系統(tǒng)的技術(shù)選型包括界面展現(xiàn)技術(shù)、服務(wù)器開發(fā)技術(shù)以及架構(gòu)技術(shù), 其中界面展現(xiàn)技術(shù)包括HTML、JavaScript和CSS, 服務(wù)器開發(fā)技術(shù)語言為Java和PHP, 架構(gòu)技術(shù)為微服務(wù)架構(gòu). 開發(fā)平臺為微服務(wù)平臺.接口包括RESTful API, 接口遵循Spring Cloud框架約定的規(guī)范.

圖2為基于區(qū)塊鏈的采購交易數(shù)據(jù)上鏈業(yè)務(wù)流程圖, 其流程描述如下: 先由需求人員提出需求, 分包人員進(jìn)行項(xiàng)目分包, 然后經(jīng)由項(xiàng)目承辦人員完成采購方案的制定, 之后項(xiàng)目經(jīng)辦人員完成以下流程: 編寫采購文件, 發(fā)布采購公告, 進(jìn)行項(xiàng)目發(fā)售, 項(xiàng)目發(fā)售中包含供應(yīng)商購標(biāo)、制作標(biāo)書、投標(biāo)、澄清等流程, 然后進(jìn)行開標(biāo), 評標(biāo)配置, 評標(biāo); 之后項(xiàng)目承辦人員完成定標(biāo),由項(xiàng)目經(jīng)辦人員進(jìn)行結(jié)果公示和結(jié)果公告, 在公告結(jié)束后進(jìn)行結(jié)果通知, 最后完成項(xiàng)目歸檔.

圖2 基于區(qū)塊鏈的采購交易數(shù)據(jù)上鏈業(yè)務(wù)流程

其中, 在采購公告環(huán)節(jié)可以利用區(qū)塊鏈技術(shù)進(jìn)行關(guān)鍵信息上鏈操作, 開標(biāo)階段可以將供應(yīng)商信息, 報(bào)價(jià),項(xiàng)目信息(包括項(xiàng)目編號名稱), 標(biāo)包的關(guān)鍵信息進(jìn)行上鏈; 在結(jié)果公示和結(jié)果公告環(huán)節(jié)中可將供應(yīng)商名單上鏈存證.

而在交易過程中產(chǎn)生的電子數(shù)據(jù)—交易電子數(shù)據(jù),需要我們對它進(jìn)行存儲并且防篡改. 交易電子數(shù)據(jù)具有易創(chuàng)建、易存儲、易傳輸和高利用率等特點(diǎn), 是可靠、有證明力度的電子數(shù)據(jù)證據(jù). 數(shù)據(jù)存證首先要對數(shù)據(jù)按類型進(jìn)行很好的存儲保存, 并且還要對數(shù)據(jù)的可信性、完整性有很好的保障, 并且還要方便對數(shù)據(jù)進(jìn)行存儲、共享、驗(yàn)證等操作. 對于上鏈存證的電子化招投標(biāo)項(xiàng)目中的關(guān)鍵信息、公示公告等內(nèi)容, 通過設(shè)置訪問權(quán)限, 對不同的身份主體劃分權(quán)限.

2.2 數(shù)據(jù)指紋提取及上鏈

在區(qū)塊鏈中, 數(shù)據(jù)上鏈的流程如圖3所示, 主要包括上鏈前處理階段和上鏈處理階段. 在上鏈前處理階段, 有業(yè)務(wù)數(shù)據(jù)處理和數(shù)字簽名兩個(gè)處理步驟. 業(yè)務(wù)數(shù)據(jù)處理的業(yè)務(wù)數(shù)據(jù)可以是任意的內(nèi)容, 比如供應(yīng)商信息, 報(bào)價(jià), 項(xiàng)目信息(包括項(xiàng)目編號名稱)或者對應(yīng)數(shù)據(jù)的哈希值等, 這些業(yè)務(wù)數(shù)據(jù)通過服務(wù)器處理; 在上鏈處理階段, 有廣播、打包、共識等處理步驟.

圖3 數(shù)據(jù)上鏈流程圖

在業(yè)務(wù)數(shù)據(jù)處理階段, 使用類Merkle樹算法對數(shù)據(jù)進(jìn)行處理, 提取業(yè)務(wù)數(shù)據(jù)的數(shù)據(jù)指紋, 具體算法步驟如算法1所示.

算法1. 類Merkle樹算法1) 從數(shù)據(jù)庫中獲取業(yè)務(wù)原始數(shù)據(jù);2) 將業(yè)務(wù)原始數(shù)據(jù)分塊;3) 采用SHA256作為哈希函數(shù)來計(jì)算數(shù)據(jù)塊的哈希值;4) 構(gòu)建Merkle樹, 提取數(shù)據(jù)指紋;5) 數(shù)據(jù)指紋簽名.

在算法1中, 數(shù)據(jù)塊的分塊大小首先由SHA256的原理確定, 同時(shí)采用GPU對數(shù)據(jù)塊哈希值的計(jì)算進(jìn)行加速, 所以分塊的大小還基于GPU的性能. 通過構(gòu)建Merkle樹[17]的形式, 構(gòu)建數(shù)據(jù)指紋樹, 得到業(yè)務(wù)數(shù)據(jù)的數(shù)據(jù)指紋, 邏輯示意圖如圖4所示.

圖4 數(shù)據(jù)處理邏輯示意圖

在完成數(shù)據(jù)的指紋提取之后, 對數(shù)據(jù)進(jìn)行簽名, 得到帶有簽名的數(shù)據(jù)指紋信息. 然后對帶有簽名的數(shù)據(jù)指紋信息打包, 放進(jìn)區(qū)塊鏈交易池中, 排序節(jié)點(diǎn)對交易排序之后, 將帶有簽名的數(shù)據(jù)指紋信息構(gòu)建默克爾哈希樹, 并將所述默克爾哈希樹的默克爾根作為所述采購交易數(shù)據(jù)文件的元數(shù)據(jù)儲存到區(qū)塊鏈的區(qū)塊頭中.

與所有區(qū)塊鏈結(jié)構(gòu)相同, 區(qū)塊鏈鏈上數(shù)據(jù)包括兩部分結(jié)構(gòu), 即區(qū)塊頭和區(qū)塊體中交易數(shù)據(jù)字段. 區(qū)塊頭數(shù)據(jù)主要由系統(tǒng)產(chǎn)生和維護(hù), 用于區(qū)塊鏈數(shù)據(jù)的保護(hù),區(qū)塊頭數(shù)據(jù)結(jié)構(gòu)如表1所列. 用戶數(shù)據(jù)主要存儲在區(qū)塊體的交易記錄中, 交易記錄以交易列表的形式存儲在區(qū)塊體中, 表2中給出與查詢相關(guān)字段的相關(guān)說明.

表1 區(qū)塊頭字段說明

表2 交易事務(wù)列表中包含的主要字段

2.3 數(shù)據(jù)訪問控制權(quán)限

由于供應(yīng)需求, 不同的部門存在需要其他部門的供應(yīng)商信息的情況, 對于其他部門的訪問, 則需要設(shè)置訪問權(quán)限. 此外, 對于上鏈存證的電子化招投標(biāo)項(xiàng)目中的關(guān)鍵信息、公示公告等內(nèi)容, 通過設(shè)置訪問權(quán)限, 對不同的身份主體劃分權(quán)限. 根據(jù)用戶不同角色, 提取用戶的如下信息: 用戶屬性、所屬部門, 基于這些信息,設(shè)計(jì)如下的角色、部門及權(quán)限對應(yīng)規(guī)則, 如表3所示.

表3 用戶訪問權(quán)限表

面向用戶的權(quán)限訪問控制將用戶分為了3類: 部門用戶、管理員和普通用戶. 其中, 只有管理員具有存證權(quán)限; 3種用戶都具有取證權(quán)限, 只是取證的數(shù)據(jù)范圍不同: 管理員可以取證所有數(shù)據(jù), 部門用戶只能取證所在部門的數(shù)據(jù)以及公開數(shù)據(jù), 普通用戶只能取證公開數(shù)據(jù)(如電子招投標(biāo)的公示信息).

完成用戶權(quán)限設(shè)計(jì)后, 通過智能合約的鏈碼邏輯來響應(yīng)基于用戶屬性的訪問控制. 聲明GetAttributeValue()函數(shù)來獲取用戶的屬性值, 聲明GetDepartmentInfo()函數(shù)來獲取用戶所屬的部門信息. 訪問控制鏈碼偽代碼如算法2, 顯示了訪問控制邏輯, 根據(jù)不同的用戶屬性, 允許執(zhí)行不同的存證和取證操作. 圖5為用戶訪問獲取鏈上數(shù)據(jù)流程圖.

算法2. 訪問控制鏈碼偽代碼1. attr := GetAttributeValue()2. departmentinfo := GetDepartmentInfo()3. switch attr{4. case “GuestUser”:5. //執(zhí)行取證操作, 僅限于公開信息6. case “AdminUser”:7. //執(zhí)行存證和取證操作8. case “DepartmentUser”:9. //執(zhí)行取證操作, 僅限于公開信息以及屬于departmentinfo部門的信息}

圖5 用戶訪問獲取鏈上數(shù)據(jù)流程圖

2.4 數(shù)據(jù)取證及驗(yàn)證

數(shù)據(jù)取證是為調(diào)取鏈下文件對應(yīng)的鏈上哈希值,利用哈希函數(shù)的抗碰撞性, 將文件的鏈上數(shù)據(jù)指紋與鏈下文件生成的數(shù)據(jù)指紋進(jìn)行對比, 以驗(yàn)證數(shù)據(jù)在存儲前后的一致性, 確保數(shù)據(jù)在存儲和處理過程中沒有發(fā)生丟失或篡改. 區(qū)塊鏈?zhǔn)且环N不斷增長的數(shù)據(jù)庫, 當(dāng)上鏈存證信息數(shù)量較大時(shí), 區(qū)塊鏈數(shù)據(jù)庫面臨遍歷查詢效率偏低和查詢功能有限的問題[18]. 本文基于外聯(lián)數(shù)據(jù)庫查詢思想[19], 設(shè)計(jì)鏈上數(shù)據(jù)指紋索引庫擴(kuò)展鏈上數(shù)據(jù)查詢功能, 在鏈下建立關(guān)聯(lián)各上鏈存證文件的數(shù)據(jù)指紋索引表, 提高查詢?nèi)∽C的效率.

數(shù)據(jù)取證與驗(yàn)證的流程和各數(shù)據(jù)庫之間的交互如圖6所示, 數(shù)據(jù)取證之前需要在區(qū)塊鏈數(shù)據(jù)庫和外部數(shù)據(jù)指紋索引庫之間同步關(guān)聯(lián)數(shù)據(jù), 取證及驗(yàn)證具體步驟如下.

圖6 數(shù)據(jù)取證及驗(yàn)證執(zhí)行流程

(1)數(shù)據(jù)關(guān)聯(lián): 外部數(shù)據(jù)指紋索引庫通過API接口監(jiān)聽鏈上狀態(tài), 一旦區(qū)塊鏈中存儲一筆招標(biāo)采購事務(wù)上鏈, 通過接口將區(qū)塊數(shù)據(jù)同步導(dǎo)入到緩沖區(qū), 緩沖區(qū)的數(shù)據(jù)利用數(shù)據(jù)解析模塊將區(qū)塊中和外部數(shù)據(jù)庫的關(guān)聯(lián)數(shù)據(jù)經(jīng)處理導(dǎo)入數(shù)據(jù)指紋索引庫, 關(guān)聯(lián)數(shù)據(jù)包括區(qū)塊ID、交易ID、項(xiàng)目編號、項(xiàng)目階段屬性和文件標(biāo)識等.

(2)數(shù)據(jù)取證: 調(diào)用數(shù)據(jù)指紋索引庫API接口, 利用文件標(biāo)識和項(xiàng)目編號作為數(shù)據(jù)庫之間的關(guān)聯(lián)值進(jìn)行查詢操作, 數(shù)據(jù)庫通過API接口返回目標(biāo)文件所在區(qū)塊號和交易索引號. 查詢操作調(diào)用鏈上數(shù)據(jù)獲取智能合約, 以區(qū)塊ID和交易ID作為合約觸發(fā)條件的輸入,定位目標(biāo)文件哈希值所在位置, 并返回目標(biāo)文件的鏈上哈希值.

(3)數(shù)據(jù)驗(yàn)證: 將鏈上數(shù)據(jù)哈希值與鏈下文件哈希值進(jìn)行對比, 若一致, 則證明采購交易文件在鏈下存儲過程中沒有被篡改.

3 系統(tǒng)展示與分析

本節(jié)實(shí)驗(yàn)與分析首先對基于Fabric的電網(wǎng)采購交易數(shù)據(jù)平臺中數(shù)據(jù)防篡改進(jìn)行理論分析, 然后對系統(tǒng)進(jìn)行關(guān)鍵性指標(biāo)分析, 最后對系統(tǒng)的一些模塊進(jìn)行界面展示.

3.1 數(shù)據(jù)安全性分析

對于數(shù)據(jù)防篡改的理論分析從數(shù)據(jù)庫和區(qū)塊鏈兩個(gè)層面進(jìn)行分析.

(1)數(shù)據(jù)庫層面

在數(shù)據(jù)處理的時(shí)候, 對業(yè)務(wù)數(shù)據(jù)進(jìn)行分塊, 將容量大的業(yè)務(wù)數(shù)據(jù)分成容量小的數(shù)據(jù)塊數(shù)據(jù), 并且將每個(gè)劃分的數(shù)據(jù)塊進(jìn)行哈希運(yùn)算, 采用類Merkle樹的思想,對數(shù)據(jù)塊構(gòu)建一個(gè)數(shù)據(jù)指紋樹. 對業(yè)務(wù)數(shù)據(jù)的一小部分?jǐn)?shù)據(jù)進(jìn)行篡改, 都將得到一個(gè)不同的數(shù)據(jù)指紋.

(2)區(qū)塊鏈層面

將數(shù)據(jù)指紋上傳到區(qū)塊鏈系統(tǒng)中, 區(qū)塊鏈作為一個(gè)分布式、多方參與的系統(tǒng), 鏈上的數(shù)據(jù)均可查詢, 通過訪問權(quán)限設(shè)置, 實(shí)現(xiàn)不同主體對于數(shù)據(jù)的訪問, 從鏈上獲取的數(shù)據(jù), 能夠與鏈下的數(shù)據(jù)進(jìn)行指紋比對, 進(jìn)一步實(shí)現(xiàn)數(shù)據(jù)的防篡改.

3.2 關(guān)鍵性指標(biāo)分析

針對上述系統(tǒng)的可用性, 本文利用Hyperledger提供的工具“Hyperledger Cliper”, 對關(guān)鍵性指標(biāo)進(jìn)行測試, 其關(guān)鍵指標(biāo)為對存證和查詢的時(shí)間, 如表4和表5所示. 系統(tǒng)部署在3臺2核4 GB內(nèi)存的主機(jī)中, 系統(tǒng)使用的版本為Ubuntu 20.04.3 LTS, Fabric版本為1.4.1, Docker版本為20.10.8, Docker-compose版本為1.26.0, Golang版本為1.14.9 Linux/amd64. Fabric部署在docker容器中, 首先下載及安裝環(huán)境必需的軟件和依賴, 包括Go、docker、docker-compose等; 其次搭建多節(jié)點(diǎn)環(huán)境, 環(huán)境中搭建了4個(gè)ordered節(jié)點(diǎn)及10個(gè)peer節(jié)點(diǎn); 然后生成創(chuàng)世塊, 并搭建組織通道; 最后, 在通道中部署、安裝實(shí)例化鏈碼. 系統(tǒng)共識采用常用的PBFT共識, 該共識通信復(fù)雜度低, 且實(shí)用性強(qiáng), 系統(tǒng)部署的4個(gè)ordered節(jié)點(diǎn)也符合PBFT共識的邊界條件(為了應(yīng)對1個(gè)惡意節(jié)點(diǎn), PBFT算法至少需要4個(gè)共識節(jié)點(diǎn)).

表5 數(shù)據(jù)查詢驗(yàn)證平均時(shí)間

由表4所示, 通過Cliper的測試可知, 上鏈?zhǔn)聞?wù)成功率為100%, 并且隨著發(fā)送速率的增大, 吞吐量也在增大, 寫3 000條記錄的平均延時(shí)均在0.1 s以下.

表4 上鏈存證測試結(jié)果表

對于本論文設(shè)計(jì)的基于數(shù)據(jù)指紋哈希索引庫的外部關(guān)聯(lián)查詢方法, 包括兩次查詢操作. 第1次查詢操作為通過文件ID和項(xiàng)目編號在數(shù)據(jù)指紋索引庫中執(zhí)行,由于數(shù)據(jù)指紋哈希索引庫采用關(guān)系型數(shù)據(jù)庫的形式,因此對數(shù)據(jù)的查找可直接利用主鍵查詢的方式, 查找速度快, 且數(shù)據(jù)量的增長并不會影響數(shù)據(jù)的查詢速度.第2次查詢操作為調(diào)用智能合約以區(qū)塊號和交易索引號為查找條件進(jìn)行鏈上查找, 由于已經(jīng)知道數(shù)據(jù)指紋所在的區(qū)塊號和交易索引號, 因此不同于傳統(tǒng)區(qū)塊鏈的遍歷查找, 傳統(tǒng)區(qū)塊鏈的數(shù)據(jù)查找方式, 查詢的時(shí)間消耗與數(shù)據(jù)量的增長呈正比, 而本文的查找方法直接通過索引進(jìn)行定位查詢, 在查詢速度上有很大提升.

由于數(shù)據(jù)量較大, 因此采用數(shù)據(jù)分片的方法, 將數(shù)據(jù)進(jìn)行分片, 然后采用GPU并行計(jì)算的方法, 將數(shù)據(jù)并行計(jì)算哈希值, 提取數(shù)據(jù)指紋, 最后將數(shù)據(jù)指紋上鏈.系統(tǒng)采用基于CUDA的數(shù)據(jù)并行處理方法, 相對于傳統(tǒng)的CPU (OpenSSL)計(jì)算, 業(yè)務(wù)數(shù)據(jù)量越高, 并行計(jì)算的效果越好, 如圖7所示.

圖7 基于OpenSSl和CUDA的上鏈時(shí)間對比圖

3.3 系統(tǒng)展示

如圖8所示, 為業(yè)務(wù)數(shù)據(jù)指紋提取展示界面, 通過對數(shù)據(jù)分塊以及GPU計(jì)算, 采用類Merkle樹的形式,得到了業(yè)務(wù)數(shù)據(jù)的數(shù)據(jù)指紋.

圖8 業(yè)務(wù)數(shù)據(jù)的數(shù)據(jù)指紋展示圖

如圖9所示, 為用戶訪問權(quán)限控制, 可以從圖中看出沒有權(quán)限的用戶沒辦法查詢更多的數(shù)據(jù), 會有一個(gè)彈窗顯示沒有權(quán)限訪問. 如圖10所示, 為業(yè)務(wù)數(shù)據(jù)的數(shù)據(jù)驗(yàn)證示意圖, 通過數(shù)據(jù)指紋數(shù)據(jù)庫快速獲取區(qū)塊鏈中的區(qū)塊鏈中的數(shù)據(jù), 然后與鏈下的數(shù)據(jù)進(jìn)行哈希比對, 可以知道數(shù)據(jù)是否被篡改, 圖中數(shù)據(jù)因?yàn)榇鄹? 導(dǎo)致哈希值對比時(shí)出現(xiàn)問題, 顯示數(shù)據(jù)被篡改.

圖9 權(quán)限訪問控制展示圖

圖10 數(shù)據(jù)防篡改展示圖

4 總結(jié)

本文給出了基于Fabric的電網(wǎng)采購交易數(shù)據(jù)平臺的設(shè)計(jì)與實(shí)現(xiàn)方案, 通過指紋提取、數(shù)據(jù)訪問控制、數(shù)據(jù)指紋庫設(shè)計(jì)等手段確保了電子化招標(biāo)采購過程的中數(shù)據(jù)的防篡改性和真實(shí)性驗(yàn)證. 平臺采用前后端分離的模式, 保證了系統(tǒng)的高內(nèi)聚和低耦合, 試運(yùn)行表示能夠解決招標(biāo)采購中的采購交易數(shù)據(jù)篡改問題. 在未來的系統(tǒng)優(yōu)化中, 將加入合同簽約等功能模塊, 進(jìn)一步提高電力物資供應(yīng)鏈中各環(huán)節(jié)的業(yè)務(wù)效率.