張明武, 夏禹軒, 張語荻, 陳啟祥, 楊 波

1. 湖北工業(yè)大學計算機學院, 武漢 430068

2. 襄陽湖北工業(yè)大學產業(yè)研究院, 襄陽 441100

3. 廣西密碼學與信息安全重點實驗室, 桂林 541004

4. 陜西師范大學計算機科學學院, 西安 710119

1 引言

區(qū)塊鏈技術(Blockchain) 是分布式存儲、點對點傳輸、加密算法、共識機制等結合的新型應用, 能夠實現(xiàn)無中心化節(jié)點的大型數據的存儲、更新、追溯等, 以及服務參與者的激勵. 區(qū)塊鏈最初在2008 年由中本聰提出的比特幣項目中開始被人們關注, 比特幣通過技術手段實現(xiàn)了去中心化的加密貨幣交易方案, 并且取得了巨大成功[1,2]. 2013 年以太坊[3]中引入智能合約的概念, 使得通過程序實現(xiàn)自動化的業(yè)務處理變得更加容易. 隨著區(qū)塊鏈應用領域的不斷擴展, 各種區(qū)塊鏈技術與平臺也隨之出現(xiàn), 例如面向企業(yè)應用解決方案的Hyperledger Fabric[4], 以及更加注重保護隱私的Zcash[5]等. 區(qū)塊鏈技術得到長足的發(fā)展和應用, 不僅在加密貨幣方面, 同時在金融、醫(yī)療、電子政務等領域也得到廣泛應用[6,7]. 然而, 現(xiàn)有區(qū)塊鏈上大多數區(qū)塊鏈的實現(xiàn)依賴鏈上數據的公開透明, 這與現(xiàn)在普遍應用場景所需要遵循的隱私保護要求不相符, 區(qū)塊鏈隱私問題成為區(qū)塊鏈除效率外阻礙其實施與應用的又一難題[8].

針對區(qū)塊鏈隱私問題學者提出了隱私保護的方法, 主要集中在交易的隱私保護[9], 較少涉及到區(qū)塊鏈背書隱私保護問題. 區(qū)塊鏈背書(block endorsement) 是區(qū)塊鏈實現(xiàn)共識的基礎, 其背書者身份的泄漏會威脅到整個區(qū)塊鏈共識的安全, 然而現(xiàn)在大多數區(qū)塊鏈包括許可區(qū)塊鏈并沒有對背書采取具體的隱私保護手段. 例如, 針對目前使用最廣的聯(lián)盟許可區(qū)塊鏈的Hyperledger Fabric, 僅通過分析其背書簽名就可以輕易獲取某項特定交易的背書策略, 從而得知參與此項交易的背書節(jié)點身份. 在背書節(jié)點身份泄露的情況下, 攻擊者通過對指定背書節(jié)點的DDOS 攻擊或阻攔通信, 可以用極小的代價阻礙相關交易的正常執(zhí)行,而如果可以實現(xiàn)對特定背書節(jié)點的腐蝕或共謀, 甚至可以威脅到整個交易的安全[10].

針對背書中存在的隱私問題, Mazumdar[11]等人提出一種針對Hyperledger Fabric 的匿名背書方案, 該方案保證背書節(jié)點身份的匿名性, 并且可以在匿名條件下實現(xiàn)(t,n) 門陷的背書策略, 但該方案在交易發(fā)生歧義或問題時無法快速進行身份追蹤, 這與現(xiàn)有的大多數聯(lián)盟區(qū)塊鏈應用要求相違背, 也為區(qū)塊鏈溯源增加了困難, 而且每次背書策略改變或者需要增加或減少背書節(jié)點時都必須重新分配密鑰, 造成整個系統(tǒng)效率低下.

群簽名方案在實現(xiàn)匿名驗證中一直有著不錯的效果, 除了群管理員, 其它人都無法獲知簽名者的身份,只有群內成員才能生成合法簽名, 在發(fā)生爭議時, 可以由群管理員通過打開簽名確認簽名者身份. 群簽名的概念首先由Chaum 等人[12]提出, 在1997 年Camenisch 等人[13]提出首個針對大群組的群簽名方案,該方案加入新成員時不需要重新更新其它成員的密鑰, 但該方案沒有考慮如何安全高效地撤銷群內成員.Kim 等人[14]提出了一個可以撤銷群成員的群簽名方案, 但每次撤銷都需要重新更新其它群成員密鑰, 帶來額外的開銷. 文獻[15] 提出了基于中國剩余定理的群簽名, 其優(yōu)勢在于在成員的加入和注銷時不用改變已經生成的密鑰, 更為靈活, 但該方案并不能抵抗聯(lián)合攻擊以及實現(xiàn)非關聯(lián)性. 文獻[16] 針對該方案進行了改進, 提出了能抵抗聯(lián)合攻擊的基于中國剩余定理的群簽名方案.

本文使用基于中國剩余定理的群簽名方案實現(xiàn)可靈活更改背書策略的許可區(qū)塊鏈背書方案, 可以滿足(t,n) 策略的驗證要求, 同時滿足許可區(qū)塊鏈的溯源要求.

1.1 本文貢獻

基于依托中國剩余定理的群簽名方案, 本文設計了一種可以應用于許可區(qū)塊鏈上的匿名背書方案, 保護了許可區(qū)塊鏈上的背書節(jié)點身份隱私以及區(qū)塊鏈交易的背書策略信息, 主要貢獻如下:

(1) 通過應用中國剩余定理實現(xiàn)背書成員的快速加入以及退出, 解決了已有匿名背書方案的背書成員加入以及退出低效的問題.

(2) 引入Schnorr 簽名提高群簽名過程中的簽名及驗證效率, 從而提高了整個匿名背書系統(tǒng)效率.

(3) 設計了可以隱藏背書策略的匿名背書方案, 并且滿足背書節(jié)點權重不對等條件下的許可區(qū)塊鏈應用需求, 同時該方案還兼容新舊簽名的驗證以及對以往交易的溯源. 同時, 給出了方案的實驗結果及性能分析.

2 預備知識

2.1 區(qū)塊鏈及背書

2.1.1 許可區(qū)塊鏈和非許可區(qū)塊鏈

區(qū)塊鏈根據其節(jié)點的加入及對網絡的訪問可以劃分為許可區(qū)塊鏈與非許可區(qū)塊鏈. 最初非許可區(qū)塊鏈如: 比特幣以及以太坊得到極力推廣, 因為它們在實現(xiàn)去中心的可信任系統(tǒng)具有優(yōu)勢, 但隨著區(qū)塊鏈技術的發(fā)展及其與商業(yè)應用的結合, 需求發(fā)生了變化, 更加貼切企業(yè)生產環(huán)境要求的許可區(qū)塊鏈被提出, 其中的佼佼者是IBM 的Hyperledger Fabric. 在許可區(qū)塊鏈環(huán)境下, 為滿足生產的需要, 通常采取半中心化或中心化的結構, 通過設置權限及訪問限制來保證整個區(qū)塊鏈網絡的安全, 同時保留了非許可區(qū)塊鏈原有的數據不可篡改, 智能合約自動化處理交易、共識協(xié)議保證交易的一致性等特性.

2.1.2 Hyperledger Fabric 許可區(qū)塊鏈背書

比特幣及以太坊等公有鏈采取先排序再執(zhí)行的交易流程, 對智能合約有著嚴格的要求, 必須保證智能合約在任何機械、任何時間針對相同的輸入都必須輸出確定性的結果, 因此對智能合約的編寫和使用有著很高的限制. 如圖1 所示, Hyperledger Fabric 許可區(qū)塊鏈采用執(zhí)行-排序-驗證的交易流程[17], 其先通過背書節(jié)點模擬執(zhí)行, 然后選取一致的背書結果, 再排序驗證. 這在保證交易一致性的硬性要求下, 給了智能合約編寫更靈活的空間, 因此其智能合約開發(fā)可以使用Golang、Java 等高級語言, 但也使得其更依賴于底層的背書來保證交易的一致性和正確性, 其交易背書流程可見圖2, 簡述為以下幾步:

圖1 Hyperledger Fabric 與非許可區(qū)塊鏈交易流程Figure 1 Hyperledger Fabric and non-permissioned chain transaction process

圖2 Hyperledger Fabric 交易背書流程Figure 2 Framework of Hyperledger Fabric transaction endorsement

(1) 系統(tǒng)初始化, 設定背書策略并在相應的背書節(jié)點上安裝智能合約.

(2) 發(fā)送交易請求, 客戶端向背書策略中的背書節(jié)點發(fā)送交易請求.

(3) 收集背書結果, 背書節(jié)點模擬執(zhí)行, 返回背書結果讀寫集及簽名, 客戶端收集并背書結果直至滿足所需的背書策略.

(4) 交易排序, 客戶端將背書結果及簽名發(fā)送至排序節(jié)點, 排序節(jié)點驗證簽名, 背書策略是否滿足, 交易是否完整, 交易是否已經存在.

(5) 打包及廣播, 排序節(jié)點將排序好的交易打包成區(qū)塊, 然后廣播給區(qū)塊鏈網絡內的可以記賬的節(jié)點,讓它們寫入賬本.

2.1.3 Hyperledger Fabric 許可區(qū)塊鏈背書分析

分析許可區(qū)鏈交易背書過程, 我們發(fā)現(xiàn)其存在以下安全性問題:

(1) 一項交易的鏈碼在安裝后, 除非鏈碼更新, 其背書策略都不會改變, 交易的背書節(jié)點固定, 這在關鍵背書節(jié)點故障時會影響到整個交易的正常執(zhí)行, 且背書節(jié)點固定也會增加受到針對特定交易的攻擊.

(2) 背書策略不光交易的發(fā)起者知道, 所有參與的背書節(jié)點以及排序節(jié)點都知道, 因此除非以上所有參與者都足夠誠信, 否則背書策略很容易暴露給第三方, 現(xiàn)實情況下這種誠實性是很難保證的.

(3) 當區(qū)塊鏈成員進行隱私交易的時候, 由于背書過程中排序節(jié)點及客戶端都需要驗證背書策略是否滿足, 因此必須向排序節(jié)點或客戶端公開交易的背書及相關隱私信息, 這是在很多應用情況下, 比如電子政務或涉及患者隱私信息的醫(yī)療領域都不樂見的.

2.2 安全與密碼學原語

2.2.1 中國剩余定理

設p1,p2,··· ,pk是k個兩兩互素的正整數,k ≥2, 對于任意整數y1,y2,··· ,yk, 滿足:

該方程的正整數解可表示為:

2.2.2 Schnorr 簽名

Schnorr 簽名[18]是基于離散對數安全假設的簽名方案, 具體方案如下:

(1) 系統(tǒng)初始化: 選取滿足p ≥2512大素數p, 選取大素數q, 滿足q|(p ?1),q ≥2160, 從Z?p中選取元素g, 滿足gq ≡1 (modp), 選取一個安全的hash 函數h:{0,1}→Z?q.

(2) 密鑰生成: 生成用戶秘密鑰x, 滿足1

(3) 簽名的產生: 輸入待簽名的消息m, 簽名者執(zhí)行: 選擇滿足1

(4) 簽名的驗證: 在接收方收到消息m和數字簽名σ=(e,s) 后, 先計算r′≡gsy?e(modp), 然后計算e=H(r,m), 驗證等式H(r′,m)=e是否成立, 若成立則簽名合法, 否則簽名非法.

2.2.3 群簽名

群簽名方案是一種特殊的數字簽名方案, 群中的任何人可以產生代表群的簽名, 簽名的驗證者只能驗證簽名是否由群內成員產生, 而不能獲知簽名者的具體身份[20]. 一個群簽名方案包括以下功能的算法:

(1) 創(chuàng)建: 產生群公鑰和私鑰的多項式時間概率算法.

(2) 加入: 用戶和群管理人之間的使用戶成為群成員的交互式或非交互式協(xié)議. 執(zhí)行該協(xié)議可產生群成員的私鑰和成員證書, 并使群管理人得到群成員的成員管理鑰.

(3) 簽名: 當輸入一個消息和一個群成員的私鑰后, 輸出對該消息的簽名.

(4) 驗證: 在輸入對消息的簽名及群公鑰后確定簽名是否有效.

(5) 打開: 在給定一個簽名及群私鑰的條件下確定簽名人身份.

群簽名的安全性包含以下幾方面:

?匿名性: 除了群管理員, 任何人不能得到簽名者的具體身份.

?非關聯(lián)性: 在不打開簽名的情況下, 獲知兩個不同的簽名是否由同一個成員簽署的, 在計算上是困難的. 在某些特定的應用場景下群簽名可以不滿足該性質, 比如投票中防止重復投票.

?防偽造性: 只有群成員才能生成有效的簽名.

?可追蹤性: 群管理員在有必要的時候可以打開一個簽名, 而簽名者不能阻止合法簽名的打開.

?防陷害性: 包括管理員在內的任何群成員都不能以其他群成員的名義生成一個合法的簽名.

?抗聯(lián)合攻擊性: 即使一些成員串通也不能生成一個合法的不能被攻擊的群簽名.

2.2.4 基于中國剩余定理的群簽名方案

群簽名方案有很多種構造方法, 本節(jié)介紹一種基于中國剩余定理的群簽名方案[15], 方案構造如下:

3 許可區(qū)塊鏈的匿名背書

3.1 匿名背書的群簽名方案

本文結合Schnorr 簽名與中國剩余定理群簽名方案給出的群簽名方案, 可以靈活快速地實現(xiàn)成員的加入以及注銷, 且能防止許可區(qū)塊鏈背書中的同一成員多次簽名同一消息.

3.1.1 具體方案

本匿名背書的群簽名方案包括7 個算法: 系統(tǒng)建立、成員的加入、用戶的撤銷、簽名的生成、簽名驗證、背書策略的驗證和簽名的打開等. 具體方案構造如下:

(1)系統(tǒng)建立: 系統(tǒng)建立階段會進行系統(tǒng)初始化及密鑰生成, 具體流程參見圖3 所示. 步驟如下:

圖3 系統(tǒng)初始化及密鑰生成Figure 3 System initialization and key generation

(a) 區(qū)塊鏈管理員在進行鏈碼安裝時首先確認要安裝的鏈碼所設定的背書策略, 在本匿名背書方案下, 不使用原Fabric 許可區(qū)塊鏈的and 及or 邏輯的背書策略, 而是按照選定的背書節(jié)點權重及數量轉換為相應的(t,n) 門限背書策略, 即此模式下當有權重總和為t的背書節(jié)點完成背書時, 該交易背書被認為是有效的.

(b) 管理員選取待背書節(jié)點, 節(jié)點總數記為k, 為每個背書節(jié)點設置權重ti(i指代第i個背書節(jié)點編號), 并保證選取的背書節(jié)點的總權重滿足d=t1+t2+···+tk>t(為保證容錯性背書節(jié)點的總權重n不能與背書策略要求的權重t過于接近), 將各個節(jié)點權重與身份的對應關系記錄到表{ID,ti}中.

(c) 根據參與的背書節(jié)點總數d的數量選取相同數量的大素數pi, 選取對應數量的大素數qi, 滿足qi|(pi ?1). 選取所有Z?pi共同的生成元g, 滿足gqi ≡1 (modpi),i=1,2,··· ,k.

(d) 選取一個安全的哈希函數:H(·). 計算P=p1p2···pk, 將pi和qi發(fā)送給安裝了鏈碼的背書節(jié)點.

(e) 背書節(jié)點收到區(qū)塊鏈管理員發(fā)送的pi,qi后, 選取密鑰xi, 滿足1

(f) 區(qū)塊鏈管理員收到y(tǒng)i后, 確保i ?=j時,yi ?=yj, 記錄{ID,yi,ti}對照關系表, 構造滿足式(1)的同余方程組. 并求該方程組的唯一解:

其中Pi,如2.2.4 節(jié)所述, 之后區(qū)塊鏈管理員公開(g,c,pi),i=1,2,··· ,k.

(2)成員的加入: 對于新成員的加入, 執(zhí)行如下過程:

(3)撤銷用戶: 區(qū)塊鏈管理者將退出的背書節(jié)點ID 對應的yi設為不同的隨機數, 然后重新計算并公開參數c.

(4)簽名的生成: 背書節(jié)點選取隨機數ri, 滿足1

(6)背書策略的驗證: 簽名驗證者在經過u的簽名收集時間后, 將計算收集的yi集合發(fā)送給區(qū)塊鏈管理者, 由區(qū)塊鏈管理者查詢(ID,yi,ti), 得到ti, 驗證t1+t2+···+tl>t(l為區(qū)塊鏈管理員收到的yi總數), 并將結果布爾值返回給驗證者, 驗證者根據驗證結果判斷收集到的簽名是否滿足背書策略要求, 具體驗證流程可見圖4.

圖4 簽名的生成和驗證Figure 4 Signature generation and verification

(7)簽名的打開: 區(qū)塊鏈管理者根據簽名信息中的pi計算yi ≡c(modpi), 在(ID,yi,ti) 對照表中

查找對應背書節(jié)點的身份ID.

3.1.2 方案分析

(6)背書權重隱藏: 區(qū)塊鏈管理者通過收到的yi查詢權重ti, 驗證t1+t2+···+tl>t, 并返回結果,驗證過程中, 驗證者無法獲知具體背書節(jié)點的權重情況, 只能得到背書結果是否滿足背書策略的布爾值.

(7)防止同一成員對同一消息重復背書: 許可鏈背書過程中要求交易背書中背書結果及簽名由不同的背書節(jié)點產生, 在本方案中驗證者可以通過簽名中的pi判斷該簽名是否由同一背書節(jié)點產生.

3.2 匿名背書方案的設計

3.2.1 系統(tǒng)結構

本背書方案參與方包含以下成員, 其結構見圖5 所示:

圖5 匿名背書系統(tǒng)結構Figure 5 Anonymous endorsement system structure

(1) 客戶端: 安裝在用戶節(jié)點上的應用程序, 負責發(fā)起交易的背書請求以及收集背書結果和簽名.

(2) 背書節(jié)點: 負責交易的背書, 會模擬執(zhí)行智能合約, 輸出背書結果及相應的群簽名.

(3) 排序服務: 由排序節(jié)點和提交節(jié)點組成. 排序節(jié)點負責驗證客戶端發(fā)送的交易是否滿足背書策略,交易的完整性以及交易是否已經存在, 還有對已驗證的交易進行排序. 提交節(jié)點負責將排序好的交易打包成塊然后廣播給網絡內記賬的節(jié)點.

(4) 記賬節(jié)點: 包含所有在區(qū)塊鏈網絡中可以記賬的節(jié)點, 這些節(jié)點將排序好的交易按順序寫入本地賬本, 共同維護某一智能合約中的交易賬本.

(5) 智能合約: 在本方案中以鏈碼形式安裝在相關節(jié)點上, 對應一個背書策略, 會自動對輸入的交易進行處理輸出一個讀寫結果集.

3.2.2 系統(tǒng)初始化及智能合約的安裝

(1) 區(qū)塊鏈用戶, 開發(fā)者及區(qū)塊鏈管理者確定待安裝的智能合約及所需要的背書策略(t,n), 為所有擬加入背書的節(jié)點安裝智能合約及配置背書策略門限要求t, 并收集安裝成功與否的反饋結果.

(2) 區(qū)塊鏈管理者生成一個匿名背書節(jié)點候選集群E, 將所有安裝成功的擬參與許可區(qū)塊鏈背書的節(jié)點添加到該集群E中, 為候選集E中的每一個背書節(jié)點分配參數pi,qi, 設置背書權重ti. 將pi,qi發(fā)送給候選背書節(jié)點, 收集候選背書節(jié)點計算的參數yi, 根據背書節(jié)點的身份ID 記錄關系對照表(ID,yi,ti).

(3) 所有以上參數分配及收集完成后, 區(qū)塊鏈管理計算群簽名的關鍵參數c, 向區(qū)塊鏈所有有背書驗證權限的節(jié)點公開參數(g,c,pi), 將背書策略門限要求t發(fā)送給排序節(jié)點.

(4) 每經過一段時間, 區(qū)塊鏈管理員從背書候選集合E選取子集F, 保證F中的背書節(jié)點權限ti之和大于t,F作為當前時刻使用的背書節(jié)點集合列表發(fā)送給用戶的客戶端.

參數t,pi,qi,ti和yi的選取和生成,c的計算具體可見3.1.1 節(jié).

3.2.3 用戶訂閱

用戶通過訂閱相關交易的背書服務來加入許可區(qū)塊鏈中的具體交易:

(1) 區(qū)塊鏈的已注冊用戶向區(qū)塊鏈管理員申請加入交易.

(2) 申請通過后區(qū)塊鏈管理員向其發(fā)送公開參數(g,c,pi), 當前時刻的背書節(jié)點集合F, 為其安裝交易智能合約及配置背書策略門限要求t.

3.2.4 背書策略的更新及候選背書節(jié)點的加入和退出

(1) 背書策略更新當需要進行背書策略更新時, 因為本方案中智能合約和背書策略分開, 因此只需要區(qū)塊鏈管理員更新背書策略門限要求t, 將其發(fā)送給用戶客戶端和排序節(jié)點即可.

(2) 候選背書節(jié)點的加入當新的背書節(jié)點需要加入時, 區(qū)塊鏈管理員將新生成的pi+1,qi+1發(fā)送給新的候選背書節(jié)點, 收集候選背書節(jié)點計算的參數yi+1, 根據背書節(jié)點的身份ID 將新的身份關系(ID,yi+1,ti+1) 添加到關系對照表(ID,yi,ti), 重新計算c并公布, 將新的候選節(jié)點添加至集合E中.

以上操作均不需要改變其它背書節(jié)點的驗證參數yi, 背書節(jié)點的加入及退出通過計算公布新的參數c即可完成.

3.2.5 匿名背書交易流程

匿名背書交易流程可見圖6, 具體如下:

圖6 匿名背書流程Figure 6 Anonymous endorsement process

(1) 發(fā)送交易請求

當區(qū)塊鏈用戶需要執(zhí)行交易時, 通過其客戶端根據自己已有的背書節(jié)點集合列表F向背書節(jié)點發(fā)送廣播交易請求m, 以及自己對m的簽名sc.

(2) 背書節(jié)點模擬執(zhí)行

背書節(jié)點收到后先驗證客戶端的簽名sc, 然后用智能合約進行模擬執(zhí)行, 輸出執(zhí)行結果讀寫集resi,然后根據統(tǒng)一的哈希函數H生成相應的讀寫集resi的哈希值H(resi), 使用在3.1.1 節(jié)中方案描述的自己的xi對H(resi) 生成相應的簽名si, 最終簽名為(si,ei,pi), 其中ei為簽名中計算出來的參數,pi在系統(tǒng)初始化階段由區(qū)塊鏈管理員發(fā)給背書節(jié)點.

算法1 交易背書Input: parameters m, sc, xi, pi, qi, ri Output: result H(resi), ei, si 1 if ver(sc,m) == true then 2execute the smart contract to get the result;3resi = result;4Ri ≡gri (mod pi);5ei = H(Ri||m);6si ≡ri +xiei (mod qi);7 end 8 return H(resi),ei,si

(3) 返回匿名背書結果

各背書節(jié)點將上步過程中產生的簽名si及讀寫哈希值H(resi) 發(fā)送回提交交易請求的客戶端.

(4) 背書結果收集

客戶端在本地進行模擬執(zhí)行然后根據統(tǒng)一哈希函數對結果進行哈希, 生成本地讀寫集res′的哈希值H(res′), 收集背書結果, 判斷H(res′)=H(res) 是否成立, 成立則驗證該群簽名si(驗證方法可見3.1.1 節(jié)中的簽名驗證), 驗證通過后將{m,H(resi),si}加入待發(fā)送的結果集合F中, 判斷是否已經收集到集合F中所有背書節(jié)點的簽名, 或者時間是否超過背書時限Te, 是則準備將其發(fā)送給排序節(jié)點.

算法2 背書結果收集Input: parameters m, si, ei, pi, H(resi), total Output: result F 1 execute the smart contract to get the result;2 res′ = result;3 create set F for each i in all do 5 add {m,H(resi),si} to set F;4if H(res′) == H(resi) AND ver(si,m,ei,pi) == true then 6 if time out OR i ≥total then 7 break;end 9end 10 end 11 return F 8

(5) 發(fā)送交易及背書結果

將上一步的結果集合F及客戶端自己的簽名sc發(fā)送給區(qū)塊鏈排序節(jié)點.

(6) 背書策略驗證及交易排序

排序節(jié)點收到客戶端發(fā)送的背書節(jié)點集合后首先檢查客戶端的簽名sc是否正確, 然后檢查簽名是否存在同一背書節(jié)點多簽的情況(通過計算yi ≡c(modpi) ), 在區(qū)塊鏈管理員的輔助下驗證是否滿足背書策略要求t, 滿足則進行每個群簽名si的驗證. 驗證通過后檢查交易m的完整性, 是否已經存在, 全部通過后進行交易排序, 輸出排序后的交易TX.

算法3 交易排序Input: parameters m, sc, si, yi, ti, t Output: result TX 1 if ver(sc,m) == True AND when i ?= j,yi ?= yj then 2if sum(ti) ≥t then 3 for each i in all do 4 if ver(si,m,ei,pi) == true AND transaction m is complete and not repeated then 5 add m to set TX;6 end end 8end 9 end 10 sort TX;11 return TX 7

(7) 生成區(qū)塊, 廣播及記賬

當排序完成后, 排序節(jié)點用排序后的交易TX 生成區(qū)塊, 發(fā)送給提交節(jié)點, 提交節(jié)點發(fā)布新的世界狀態(tài), 并廣播給區(qū)塊鏈內的所有節(jié)點, 讓它們進行復制, 寫入各節(jié)點的賬本.

3.2.6 許可區(qū)塊鏈溯源及身份追蹤

當交易出現(xiàn)爭議或問題時, 為了進行溯源, 需要追蹤背書節(jié)點身份. 在本匿名方案中, 追蹤簽名對應的yi仍然有效時, 只需要區(qū)塊鏈管理員計算yi ≡c(modpi), 查詢yi在現(xiàn)有關系對照表(ID,yi,ti) 中的對應ID 即可獲取該背書節(jié)點身份. 追蹤簽名對應的yi失效時, 根據歷史y′i失效記錄時間time 查詢歷史關系對照表(time,c′,ID,y′i,t′i), 計算y′i ≡c′(modpi) 獲取簽名者身份ID.

算法4 背書節(jié)點身份追蹤Input: parameters m, si, pi, c, (ID,yi,ti), (time,c′,ID,y′i,t′i)Output: result ID 1 yi ≡c (mod pi);2 if yi not in (ID,yi,ti) then 3get ID from (time,c′,ID,y′i,t′i);4 end 5 get ID from (ID,yi,ti);6 if ver(si,m,ei,pi) == true then 7return ID;8 end 9 return signature illegal

4 仿真實驗及分析

本實驗使用電腦 CPU 為 Intel(R) Core(TM) i7-9750H, 內存為 8 GB, 操作系統(tǒng)為 64 位的Ubuntu 20.04.1 LTS, 使用編寫語言為與Hyperledger Fabric 源碼相同的Golang, Golang 版本為1.15, 使用庫主要包含Golang 的math/big, crypto 中的rand 及SHA3 庫, Schnorr 簽名使用庫github.com/ChainSafe/go-schnorrkel. 具體實驗分為群簽名的效率測試實驗及在Hyperledger Fabric 許可區(qū)塊鏈上的匿名背書仿真實驗兩部分.

4.1 群簽名性能測試及分析

該部分實驗通過編寫Golang 代碼, 測試方案中的群簽名在簽名及驗證的效率, 方案中的加入以及刪除新的成員節(jié)點的效率, 測試結果可見圖7. 分析以上測試結果可知, 本方案中的群簽名部分在簽名上的效率要稍差, 驗證效率良好, 考慮匿名背書中因為簽名部分是并行處理的, 實際影響不會很大. 成員加入部分, 因為包含新成員的密鑰生成, 花費時間較長, 但也在可接受的范圍內, 成員刪除部分則有著很高的效率.

圖7 (a) 簽名和驗證; (b) 成員節(jié)點的加入; (c) 成員節(jié)點的刪除;Figure 7 (a) Signing and verification; (b) Joining of member nodes; (c) Deletion of member nodes

4.2 Hyperledger Fabric 許可區(qū)塊鏈上的仿真實驗及分析

本部分實驗通過部署版本1.4.6 的Hyperledger Fabric 并編寫代碼來仿真模擬實現(xiàn), 以測試本方案應用對許可區(qū)塊鏈的效率的影響. 我們部署的Hyperledger Fabric 包含兩個組織, 每個組織各有兩個peer節(jié)點, 它們同時具有背書節(jié)點及記賬節(jié)點身份, 五個orderer 節(jié)點用來實現(xiàn)排序服務及raft 共識. 實驗中的交易請求除了初始交易請求由排序節(jié)點發(fā)出, 其它均由組織2 的管理員節(jié)點上的客戶端發(fā)出. 設定的背書策略為上述四個peer 共同完成交易背書, 通過Golang 的math/rand 為背書節(jié)點隨機設定的背書權重, 范圍為1 至3, 權重總和達到5 即背書成功.

實驗樣本采用2750 條獨立的交易數據, 并將這些數據以50 為單位遞增, 分為10 組, 分別進行交易的執(zhí)行實驗, 對最后的結果處理中, 我們去掉實驗結果中的最大及最小誤差項并對剩下數據進行平均處理,實驗測試結果可見表1、圖8. 對以上數據分析對比可知, 使用本方案中的匿名背書方法對Fabric 許可區(qū)塊鏈的交易執(zhí)行效率影響較小, 整個許可區(qū)塊鏈交易在保證背書身份的匿名前提下仍具有較高執(zhí)行效率.

圖8 (a) 匿名背書交易執(zhí)行時間與原Fabric 許可鏈交易執(zhí)行時間(平均); (b) 交易時間差值Figure 8 (a) Anonymous endorsement transaction time and original Fabric permissioned blockchain transaction time (average); (b) Trading time difference

表1 匿名背書許可區(qū)塊鏈交易執(zhí)行時間Table 1 Running time of anonymous endorsement permissioned blockchain transaction

5 結束語

本文在基于現(xiàn)有許可區(qū)塊鏈中存在的安全問題, 提出了一種基于群簽名的許可區(qū)塊鏈匿名背書方案.通過中國剩余定理實現(xiàn)適用于許可區(qū)塊鏈匿名背書要求的群簽名方案, 該方案除了實現(xiàn)對背書節(jié)點身份的保護外, 還解決了現(xiàn)有許可區(qū)塊鏈匿名方案中存在的成員加入與刪除效率不高的問題. 在此基礎上, 提出了一種以Hyperledger Fabric 許可區(qū)塊鏈為基礎的匿名背書方案, 該方案可以實現(xiàn)非對等的權重背書節(jié)點配置下的匿名背書, 以滿足許可區(qū)塊鏈應用中的溯源要求. 通過在Hyperledger Fabric 許可區(qū)塊鏈上的仿真實驗, 給出方案的測試結果, 實驗分析表明使用所提出的許可區(qū)塊鏈背書, 在具有匿名性的前提下仍有著較好的計算效率.