劉玉紅，楊亮，樸春慧，張志國

（1.石家莊鐵道大學信息科學與技術學院，河北 石家莊 050043 ；2.河北省電磁環(huán)境效應與信息處理重點實驗室，河北 石家莊 050043；3.石家莊鐵道大學土木工程學院，河北 石家莊 050043）

1 引言

在鐵路工程施工過程中，大量帶有感知功能的物聯(lián)網(wǎng)設備被部署到施工項目內的不同結構物上，這些設備產生的數(shù)據(jù)具有多源異構、規(guī)模龐大、時空關聯(lián)、冗余度高、多維標量等特征[1]。這些數(shù)據(jù)經過整合、共享，可實現(xiàn)鐵路建設過程安全管理和事故后的責任追溯等。但由于傳統(tǒng)的信息化平臺采用了中心式的云存儲方式，該方式使數(shù)據(jù)脫離了施工參與方的物理控制，無法保證數(shù)據(jù)的安全性，存在篡改風險，使鐵路施工各參與方無法對中心式存儲下的監(jiān)測數(shù)據(jù)達成共識，且在該模式下無法確保共享過程中數(shù)據(jù)的有效性以及在不同系統(tǒng)傳輸過程中數(shù)據(jù)的一致性[2-4]。

區(qū)塊鏈技術起源于文獻[5]，是一種由多方共同維護，使用密碼學保證傳輸和訪問安全，能夠實現(xiàn)數(shù)據(jù)一致存儲、難以篡改、防止抵賴的記賬技術，也稱為分布式賬本技術，它構建了數(shù)據(jù)安全保護機制，實現(xiàn)數(shù)據(jù)所有權與使用權的分離，按智能合約進行數(shù)據(jù)存儲與查詢[6-7]。在鐵路建設領域內，有學者結合區(qū)塊鏈進行研究，如代明睿[8]研究了基于區(qū)塊鏈的鐵路數(shù)據(jù)匯集共享過程中的關鍵技術，分析了鐵路數(shù)據(jù)匯集共享體系架構的安全特性，提出了基于區(qū)塊鏈的鐵路數(shù)據(jù)匯集共享體系架構。在鐵路建設方面的區(qū)塊鏈技術的應用也有一些實際案例，如2020 年，區(qū)塊鏈技術應用于雄安新區(qū)工程質量監(jiān)督管理[9]。綜上所述，將區(qū)塊鏈應用于鐵路工程建設中，已有一些理論研究與實際應用。

基于上述背景，針對鐵路工程施工中監(jiān)測數(shù)據(jù)的安全問題以及保證監(jiān)測數(shù)據(jù)真實性，本文提出一種基于區(qū)塊鏈的鐵路工程施工安全監(jiān)測數(shù)據(jù)共享模型，主要貢獻如下。

1) 提出一種基于區(qū)塊鏈的鐵路工程施工安全監(jiān)測數(shù)據(jù)共享模型，利用智能合約自動執(zhí)行的特點保證監(jiān)測數(shù)據(jù)上鏈過程的透明性，使業(yè)主單位、施工單位和監(jiān)管單位認可鏈上數(shù)據(jù)的真實性。采用區(qū)塊鏈存儲監(jiān)測數(shù)據(jù)的關鍵索引信息、數(shù)據(jù)中心存儲原始監(jiān)測數(shù)據(jù)的方式實現(xiàn)監(jiān)測數(shù)據(jù)的存儲。

2) 設計了監(jiān)測數(shù)據(jù)存儲與查詢智能合約，使施工單位通過智能合約將監(jiān)測數(shù)據(jù)的特征值、異常數(shù)據(jù)等上鏈存儲，監(jiān)管單位和業(yè)主單位通過查詢智能合約查看鏈上數(shù)據(jù)。

3) 針對鐵路施工過程中監(jiān)測數(shù)據(jù)的流式特征導致的數(shù)據(jù)上鏈過程中產生的網(wǎng)絡擁塞問題，提出了一種基于信譽積分的實用拜占庭容錯（RPBFT,reputation-based practical Byzantine fault tolerance）算法。通過簡化一致性協(xié)議的方式，將協(xié)議的時間復雜度由O(n2)降為O(n)；通過加入基于節(jié)點行為的獎勵機制，降低拜占庭節(jié)點作為主節(jié)點的概率。

4) 通過攻擊可能性和攻擊成功概率的量化分析，表明智能合約技術為鏈上監(jiān)測數(shù)據(jù)提供了防篡改性。利用Hyperledger Caliper 進行對比實驗，證明RPBFT 算法在共識過程中的時延較PBFT 算法降低約30%，吞吐量提升約170%。與同類問題的對比分析表明，本文模型在共識效率與共享速度方面優(yōu)勢明顯。

2 基于區(qū)塊鏈的鐵路工程施工安全監(jiān)測數(shù)據(jù)共享模型

區(qū)塊鏈按照中心化程度可以分為公有鏈、聯(lián)盟鏈和私有鏈。公有鏈由所有參與成員維護，具有完全去中心化的特點；聯(lián)盟鏈由一些機構發(fā)起，只允許該機構組織內部成員參加，具有部分中心化的特點；私有鏈的寫入權限只受一個實體組織控制，為了追求性能已漸漸演變成中心化的模式[10]。考慮到鐵路工程施工中的監(jiān)測數(shù)據(jù)共享區(qū)塊鏈參與節(jié)點是多個參建實體或其他機構組成的組織或聯(lián)盟，并未面向大眾完全公開，且加入?yún)^(qū)塊鏈的參與者需要經過主管部門的審核，故聯(lián)盟鏈是最佳選擇。

基于區(qū)塊鏈的鐵路工程施工安全監(jiān)測數(shù)據(jù)共享模型如圖1 所示，模型中區(qū)塊鏈節(jié)點主要分為業(yè)主單位、施工單位和監(jiān)管單位。

圖1 基于區(qū)塊鏈的鐵路工程施工安全監(jiān)測數(shù)據(jù)共享模型

業(yè)主單位。業(yè)主單位是鐵路工程施工的投資主體，是鐵路工程施工的發(fā)起者，也是施工過程的管理者。

施工單位。在鐵路工程施工過程中施工單位廣義上包括現(xiàn)場負責施工的單位、監(jiān)測單位等與鐵路建設相關的單位，本文將上述單位統(tǒng)稱為施工單位。施工單位是鐵路項目的總承包單位，也是鐵路項目施工過程的主要負責單位。施工單位負責在項目中的結構體不同部位安裝多種物聯(lián)網(wǎng)感知設備，物聯(lián)網(wǎng)感知設備的數(shù)量根據(jù)結構體類型、體積等的不同而變化。

監(jiān)管單位。監(jiān)管單位包括負責鐵路施工項目建設監(jiān)管等工作的監(jiān)理單位、地區(qū)鐵路監(jiān)督管理局以及鐵路行業(yè)信息化工作的主管部門。本文提出的監(jiān)測數(shù)據(jù)共享聯(lián)盟鏈是由監(jiān)管單位負責發(fā)起與維護的；當鐵路項目施工過程中出現(xiàn)安全事故時，監(jiān)管單位根據(jù)該項目施工監(jiān)測數(shù)據(jù)進行責任追溯。

模型結構主要包括智能合約、區(qū)塊鏈網(wǎng)絡、數(shù)據(jù)中心和物聯(lián)網(wǎng)設備。

智能合約保存在區(qū)塊鏈上，鏈內各節(jié)點可以查看并執(zhí)行智能合約指令，還可以查看節(jié)點與智能合約交互日志[11]。通過智能合約，施工單位可以將數(shù)據(jù)存儲在去中心化的區(qū)塊鏈網(wǎng)絡中，監(jiān)管單位和業(yè)主單位可以監(jiān)測數(shù)據(jù)進行查詢。

區(qū)塊鏈網(wǎng)絡主要包括節(jié)點網(wǎng)絡和共識機制，在節(jié)點網(wǎng)絡中的節(jié)點維護自己的分布式賬本。節(jié)點網(wǎng)絡主要包括共識節(jié)點和驗證節(jié)點，共識節(jié)點負責驗證數(shù)據(jù)存儲或查詢交易并執(zhí)行共識算法，還在自身分布式賬本中記錄存儲的數(shù)據(jù)；驗證節(jié)點負責驗證數(shù)據(jù)存儲或查詢交易。

數(shù)據(jù)中心用于存儲鐵路施工現(xiàn)場傳輸?shù)脑急O(jiān)測數(shù)據(jù)，對監(jiān)測數(shù)據(jù)進行轉換、處理、特征提取等操作，最后將特征值、異常值等構成的監(jiān)測數(shù)據(jù)索引與摘要傳輸給監(jiān)管單位。

物聯(lián)網(wǎng)設備指鐵路施工現(xiàn)場的監(jiān)測數(shù)據(jù)收集與傳輸設備，由于傳感器本身不具備數(shù)據(jù)的遠程傳輸能力，因此需要借助數(shù)據(jù)傳輸單元（DTU,data transfer unit）進行數(shù)據(jù)的遠程傳輸。

監(jiān)測數(shù)據(jù)存儲流程如圖2 所示。在鐵路施工現(xiàn)場，物聯(lián)網(wǎng)設備監(jiān)測到數(shù)據(jù)后傳輸至DTU，DTU通過運營商網(wǎng)絡將監(jiān)測數(shù)據(jù)以二進制流的形式分別傳輸至數(shù)據(jù)中心和施工單位。1) 監(jiān)測數(shù)據(jù)傳輸至數(shù)據(jù)中心后，由于監(jiān)測數(shù)據(jù)是實時采集的，存在噪聲、異常值和缺失值等問題，因此需要在數(shù)據(jù)中心進行數(shù)據(jù)處理；處理完成后將監(jiān)測數(shù)據(jù)存儲至數(shù)據(jù)中心。2) 監(jiān)測數(shù)據(jù)傳輸至施工單位后，在施工單位的信息化平臺使用與數(shù)據(jù)中心相同的方法對監(jiān)測數(shù)據(jù)進行處理，由于區(qū)塊鏈的鏈上狀態(tài)數(shù)據(jù)庫不適合存儲大量數(shù)據(jù)，故需生成監(jiān)測數(shù)據(jù)的索引與摘要，其中包括了監(jiān)測數(shù)據(jù)的特征值、異常值等信息；然后通過智能合約將數(shù)據(jù)索引與摘要存儲至區(qū)塊鏈平臺。施工單位出于成本考慮，不會在本地服務器中存儲大量監(jiān)測數(shù)據(jù)，因此當上傳數(shù)據(jù)完成后，便將數(shù)據(jù)刪除，繼續(xù)接收下一階段監(jiān)測數(shù)據(jù)。

圖2 監(jiān)測數(shù)據(jù)存儲流程

監(jiān)測數(shù)據(jù)查詢流程如圖3 所示。當鐵路項目在施工過程中出現(xiàn)安全事故時，監(jiān)管單位可以使用存儲于數(shù)據(jù)中心的監(jiān)測數(shù)據(jù)作為責任追溯的依據(jù)之一。但由于數(shù)據(jù)中心數(shù)據(jù)存在被篡改的風險，因此需要與區(qū)塊鏈中的監(jiān)測數(shù)據(jù)進行驗證，確定監(jiān)測數(shù)據(jù)的真實性。當監(jiān)管單位提出查詢請求時，判斷查詢請求是否需要調取區(qū)塊鏈中的數(shù)據(jù)。1) 當請求消息發(fā)送至數(shù)據(jù)中心時，數(shù)據(jù)中心根據(jù)請求信息中的項目編號提取相應監(jiān)測數(shù)據(jù)傳輸至監(jiān)管單位；2) 當請求消息發(fā)送至區(qū)塊鏈時，智能合約根據(jù)請求信息中的項目編號將相應的監(jiān)測數(shù)據(jù)索引提取并發(fā)送給監(jiān)管單位。

圖3 監(jiān)測數(shù)據(jù)查詢流程

3 相關合約設計

在本文方案中，參與方將通過聯(lián)盟區(qū)塊鏈的遠程過程調用（RPC,remote procedure call）接口實現(xiàn)監(jiān)測數(shù)據(jù)索引的存儲與查詢。據(jù)此本文設計了監(jiān)測數(shù)據(jù)存儲合約和監(jiān)測數(shù)據(jù)查詢合約。

3.1 監(jiān)測數(shù)據(jù)存儲合約

監(jiān)測數(shù)據(jù)存儲合約用于將原始監(jiān)測數(shù)據(jù)索引存儲到區(qū)塊鏈中。當上傳原始監(jiān)測數(shù)據(jù)索引時，通過區(qū)塊鏈向外部提供的RPC 接口發(fā)送索引相關數(shù)據(jù)；監(jiān)測數(shù)據(jù)存儲合約監(jiān)測到有數(shù)據(jù)傳輸時，先對傳輸?shù)臄?shù)據(jù)進行檢查，通過后其方可進入聯(lián)盟鏈中，作為新區(qū)塊的區(qū)塊體，并進行下一步的共識過程。監(jiān)測數(shù)據(jù)存儲合約設計如算法1 所示。

算法1監(jiān)測數(shù)據(jù)存儲合約

輸入監(jiān)測數(shù)據(jù)索引MD

輸出存儲成功Req

3.2 監(jiān)測數(shù)據(jù)查詢合約

監(jiān)測數(shù)據(jù)查詢合約為區(qū)塊鏈參與方提供查詢存儲在聯(lián)盟鏈的監(jiān)測數(shù)據(jù)索引功能。當參與方向聯(lián)盟鏈提出查詢請求時，區(qū)塊鏈系統(tǒng)構造查詢請求信息R，如式(1)所示；將R發(fā)送至聯(lián)盟鏈節(jié)點，等待查詢結果。被查詢的監(jiān)測數(shù)據(jù)索引會被參與方的公鑰加密，加密后的結果返回給參與方，參與方使用自己的私鑰解密即可得到真實監(jiān)測數(shù)據(jù)索引。

其中，SHARE 表示該命令的請求類型為查詢請求，proid 是全局不會重復的項目編號，Pub(key)是參與方的公鑰。為了提升查詢效率，本文方案的監(jiān)管方所處的節(jié)點會維護一張哈希表LIST，LIST 用來記錄監(jiān)測數(shù)據(jù)索引在聯(lián)盟鏈中的位置，LIST 的結構如式(2)所示。

其中，proid 是全局不會重復的項目編號，TimeStamp是項目編號所對應項目的最新監(jiān)測數(shù)據(jù)索引上傳時間，Blockid 是項目編號所對應項目的監(jiān)測數(shù)據(jù)索引所處區(qū)塊編號。監(jiān)測數(shù)據(jù)查詢合約設計如算法2所示。

算法2監(jiān)測數(shù)據(jù)查詢合約

輸入查詢請求R

輸出查詢結果result

4 PBFT 算法的改進

共識機制是區(qū)塊鏈的核心技術，它確定新區(qū)塊是否經過驗證以及誰保留記錄，影響著整個系統(tǒng)的安全性和可靠性[12]。本文方案采用聯(lián)盟鏈，因此選擇Hyperledger Fabric 作為區(qū)塊鏈底層框架，該框架采用了PBFT 算法作為共識算法，但PBFT 算法存在以下問題。

1) 主節(jié)點選擇問題。PBFT 算法的各節(jié)點成為主節(jié)點的概率是相同的，它們輪流成為主節(jié)點，承擔出塊任務。按照上述方式來選擇主節(jié)點，會讓一些性能較低或共識過程中表現(xiàn)較差的節(jié)點成為主節(jié)點，這樣會影響系統(tǒng)中的出塊效率，降低系統(tǒng)性能。

2) 通信量問題。在PBFT 算法的一致性協(xié)議準備階段和提交階段，每個從節(jié)點都會向所有節(jié)點廣播信息，使共識過程的通信量達到O(n2)。造成節(jié)點通信次數(shù)隨節(jié)點數(shù)量增加而呈指數(shù)級增長，進而導致共識效率下降，嚴重影響了系統(tǒng)擴展性。

針對上述問題，文獻[13]在共識策略方面改進了PBFT 算法，通過劃分節(jié)點簇的方式保證算法的協(xié)調性和安全性。文獻[14]在節(jié)點選擇方面改進了PBFT 算法，根據(jù)節(jié)點職責劃分多個節(jié)點集合，使其適用于節(jié)點數(shù)量不停變化的動態(tài)區(qū)塊鏈網(wǎng)絡中。文獻[15]在方法創(chuàng)新方面改進了PBFT 算法，利用K-medoids 對節(jié)點進行聚類和層次劃分，使其適用于較大規(guī)模共識節(jié)點參與的共識過程。文獻[16]在區(qū)塊結構方面改進了PBFT 算法，通過設計多主節(jié)點的方式，一定程度上降低了惡意節(jié)點作為主節(jié)點時的高時延問題。上述文獻從不同角度對PBFT 算法進行了改進，以期降低算法復雜度和通信量，提高共識效率，但其針對的數(shù)據(jù)類型均屬于靜態(tài)數(shù)據(jù)，對于鐵路施工項目安全監(jiān)測中的流式數(shù)據(jù)并不適用，且在改進算法時均插入了節(jié)點選擇算法，在一定程度上增加了算法的復雜度，存在降低共識效率的潛在風險。

因此，本文結合鐵路工程施工安全監(jiān)測數(shù)據(jù)共享應用場景，提出了RPBFT 算法，該算法從以下兩方面對PBFT 算法進行了改進。

1) 加入了基于節(jié)點行為的獎勵機制，獎勵或懲罰將通過節(jié)點得分體現(xiàn)，RPBFT 根據(jù)得分來選擇更加值得信任的節(jié)點作為主節(jié)點和共識節(jié)點，以達到提升算法效率的目的。

2) 由于聯(lián)盟鏈中大部分節(jié)點都是誠實節(jié)點，因此在不存在拜占庭節(jié)點的情況下通過簡化PBFT 一致性協(xié)議，以達到降低節(jié)點間的通信量，減少系統(tǒng)開銷，減輕帶寬壓力的目的。

4.1 基于節(jié)點行為的獎勵機制

1) 節(jié)點信譽分數(shù)計算在初始階段，各個節(jié)點的信譽分數(shù)設置為100，分數(shù)根據(jù)節(jié)點在共識過程中的行為改變，每完成一輪共識，各個節(jié)點的分數(shù)將根據(jù)該節(jié)點在此輪共識中的表現(xiàn)進行加分或減分。成功參與本輪共識的節(jié)點加分；在本輪共識中作惡或者失效的節(jié)點減分。對節(jié)點行為懲罰嚴重程度上，方案允許節(jié)點偶發(fā)失效，即當節(jié)點失效時，減分較少；但對節(jié)點作惡的行為絕對不允許，若節(jié)點作惡則進行嚴厲懲罰，扣除該節(jié)點大部分分數(shù)，使其短時間內難以參與共識過程，杜絕其連續(xù)作惡情況發(fā)生。本文方案對獎懲的相關系數(shù)按照2 的指數(shù)級別設置，分數(shù)的計算如式(3)所示。

其中，Score 表示節(jié)點當前的分數(shù)；S表示節(jié)點是否成功參與本輪共識，若成功參與，則S=1，否則S=0；F表示節(jié)點在本輪共識中是否出現(xiàn)失效情況，若出現(xiàn)，則F=1，否則F=0；E表示節(jié)點在本輪共識中是否出現(xiàn)作惡情況，若出現(xiàn)，則E=1，否則E=0。

2) 基于信譽分數(shù)的主節(jié)點和共識節(jié)點選取方案

主節(jié)點選取。本文方案的主節(jié)點選取方式采用基于信譽分數(shù)的選取方式，選取分數(shù)最高的節(jié)點為主節(jié)點，當主節(jié)點失效或作惡時，根據(jù)視圖變更協(xié)議選擇分數(shù)排名第二的節(jié)點作為主節(jié)點，并開始新一輪共識。

共識節(jié)點選取。本文選擇的區(qū)塊鏈類型為聯(lián)盟鏈，參與其中的節(jié)點已經通過了身份驗證，有力保證了節(jié)點的誠實性。使用分數(shù)的多少作為節(jié)點可靠性排名的依據(jù)，進一步確保了節(jié)點的可靠性。因此為提升共識效率，本文方案選取部分分數(shù)較高的節(jié)點作為共識節(jié)點，其他節(jié)點在共識結束后同步共識結果。

4.2 完整一致性協(xié)議分析與簡化設計

PBFT 算法要求所有節(jié)點處于同一種狀態(tài)下和行為一致性。達到此目的的方式是運行3 類基本協(xié)議：一致性協(xié)議、視圖更換協(xié)議和檢查點協(xié)議。一致性協(xié)議通過預準備、準備、確認3 個階段保證區(qū)塊鏈內全部節(jié)點的數(shù)據(jù)一致性；在共識過程中主節(jié)點出現(xiàn)失效或作惡情況時，會觸發(fā)視圖更換協(xié)議，選擇另一節(jié)點作為主節(jié)點；檢查點協(xié)議將系統(tǒng)中的服務器同步到某一個相同狀態(tài)，系統(tǒng)設置了checkpoint 時間點，定期處理系統(tǒng)內日志，節(jié)約網(wǎng)絡資源并糾正服務器狀態(tài)[17]。

1) 完整一致性協(xié)議分析

完整一致性協(xié)議定義了主節(jié)點和共識節(jié)點2 種節(jié)點，在每一輪共識過程中，主節(jié)點只有一個，共識節(jié)點有多個。主節(jié)點負責驗證一段時間內區(qū)塊鏈系統(tǒng)接收到準備上鏈的數(shù)據(jù)，驗證通過后主節(jié)點將這些數(shù)據(jù)打包進區(qū)塊并發(fā)起共識。完成一次完整的一致性協(xié)議需要3 個階段，其執(zhí)行過程如圖4 所示。

圖4 完整一致性協(xié)議執(zhí)行過程

圖4 中Client 表示客戶端，A0是主節(jié)點，A1和A2是誠實節(jié)點，A3是拜占庭節(jié)點，具體運行過程如下。

預準備階段（pre-prepare）。主節(jié)點將客戶端發(fā)來的請求生成預準備消息，將其廣播給所有共識節(jié)點。消息格式為，其中，v是視圖編號，n是消息編號，d是對m進行哈希運算后的結果，m是客戶端發(fā)來的消息。

準備階段（prepare）。共識節(jié)點收到預準備消息后，生成準備消息并廣播，預準備消息和準備消息被同時寫入自身日志文件，消息格式為，其中i是節(jié)點編號。節(jié)點收到其他節(jié)點的準備消息后，驗證消息的真實性，將收到消息的n,v,m和自己日志中準備消息對應字段進行比較，若超過f+1 個準備消息的比較結果是正確的則進入確認階段。本文將此階段中共識節(jié)點接收預準備消息、發(fā)送準備消息、接收并驗證其他節(jié)點的準備消息稱為共識節(jié)點在準備階段的“接收-發(fā)送-接收”驗證過程。

確認階段（commit）。所有共識節(jié)點生成確認消息，并廣播到網(wǎng)絡中的其他節(jié)點，消息格式為。此階段驗證步驟與準備階段相同，當超過f+1 個節(jié)點的確認消息驗證成功后，此輪共識過程方可成功。

2) 簡化一致性協(xié)議設計

在PBFT 一致性協(xié)議運行過程中，完成了兩次復雜度為O(n2)的通信步驟，這是為了解決網(wǎng)絡中存在的拜占庭將軍問題，使區(qū)塊鏈網(wǎng)絡中各個節(jié)點能夠達成共識。RPBFT 中簡化一致性協(xié)議將完整一致性協(xié)議的準備階段進行轉換，把共識節(jié)點“接收-發(fā)送-接收”的驗證過程轉移至主節(jié)點，由主節(jié)點判定所有共識節(jié)點的反饋信息是否正確，不需要共識節(jié)點再做判斷；另外，在選擇參與共識節(jié)點過程中，選擇節(jié)點數(shù)量超過全網(wǎng)節(jié)點數(shù)量的一半。簡化一致性協(xié)議運行的前提是當前共識節(jié)點中不存在拜占庭節(jié)點，使RPBFT 算法在完成復雜度為O(n)的共識操作后，區(qū)塊鏈網(wǎng)絡中各個節(jié)點能夠達成共識。

簡化一致性協(xié)議是基于文獻[18]，并結合本文研究背景提出的一種一致性協(xié)議，其運行過程如圖5 所示。

圖5 簡化一致性協(xié)議運行過程

圖5 中Client 為客戶端，A0為主節(jié)點，A1、A2為共識節(jié)點，A3為非共識節(jié)點，簡化一致性協(xié)議具體運行過程如下。

預準備階段（pre-prepare）。在此階段，主節(jié)點會為打包信息分配一個序列號n，然后將序列號與打包信息共同廣播至全網(wǎng)，消息格式為，其中，v是視圖編號，n是消息編號，m是客戶端發(fā)來的消息摘要，d是對m進行哈希運算后的結果，w是節(jié)點的信譽積分信息。

反饋階段（feedback）。主節(jié)點發(fā)送的預準備消息被共識節(jié)點接收后，共識節(jié)點驗證預準備消息中的交易信息及其信譽積分與本地積分是否相同，若認可該消息且相同，則生成反饋消息并向主節(jié)點發(fā)送；否則不發(fā)送反饋消息，反饋消息格式為。如果主節(jié)點沒有收到全部共識節(jié)點的反饋消息，則進入完整的一致性協(xié)議流程；否則進入驗證階段。此階段從節(jié)點驗證以下內容。

①查看預準備消息的簽名是否正確。

②摘要內容與d是否一致。

③查看視圖編號，確定消息是否來自主節(jié)點。

④該節(jié)點是否接收過相同視圖編號v發(fā)送的相同信息編號n的消息。

⑤消息序號是否在一定區(qū)間中。此處設定一定區(qū)間一方面可以方便清除多余的日志信息，另一方面可以防止拜占庭主節(jié)點使用大量序列號，消耗序列號空間。

驗證階段（verify）。當主節(jié)點接收到所有共識節(jié)點的反饋消息后，會驗證接收到的所有反饋消息是否相同，若全部相同則生成驗證消息并廣播，消息格式為，其中a是確認添加的信息。共識節(jié)點接收到驗證消息后將確認添加的信息保存到本地內存中，若不同，則執(zhí)行完整一致性協(xié)議，至此簡化一致性協(xié)議完成。

RPBFT 是為鐵路施工項目安全監(jiān)測數(shù)據(jù)共享聯(lián)盟鏈設計的共識算法，在此背景下，參與聯(lián)盟鏈的節(jié)點絕大多數(shù)都是誠實節(jié)點，因此RPBFT 在絕大部分時間內都執(zhí)行簡化一致性協(xié)議，縮短了共識時間，使其能夠適應鐵路施工項目安全監(jiān)測的流式數(shù)據(jù)上鏈速度。通過引入獎勵機制，選擇信譽分數(shù)最高的節(jié)點作為主節(jié)點，極大地降低了主節(jié)點失效或作惡的概率，保證了共識過程的穩(wěn)定；選擇部分節(jié)點參與共識的方法，減低了共識時間，提高了共識效率。

4.3 算法的流程

RPBFT 算法在PBFT 算法基礎上增加了基于節(jié)點行為的獎勵機制，設計了以信譽分數(shù)為指標的主節(jié)點選擇方案，極大地降低了選擇拜占庭節(jié)點作為主節(jié)點的概率；并簡化了一致性協(xié)議的運行流程，減少了節(jié)點間的通信量，節(jié)省了通信開銷。RPBFT 算法的流程如圖6 所示。RPBFT 算法的具體執(zhí)行過程如下。

圖6 RPBFT 算法流程

節(jié)點初始化。使用整數(shù)0～N-1 對節(jié)點進行編號（N為節(jié)點總數(shù)），將各節(jié)點信譽值設為100。隨機選取一個節(jié)點作為主節(jié)點和個共識節(jié)點。

客戶端向主節(jié)點發(fā)送請求信息，主節(jié)點接收請求信息后，將請求消息編號，生成預準備消息，并執(zhí)行簡化一致性協(xié)議。

所有共識節(jié)點執(zhí)行簡化一致性協(xié)議，在簡化一致性協(xié)議的執(zhí)行過程中，對所有參與共識的節(jié)點狀態(tài)進行判斷，算法根據(jù)判斷結果進行操作，具體如下。

1) 若判斷參與共識的節(jié)點中無拜占庭節(jié)點，則主節(jié)點和共識節(jié)點會繼續(xù)執(zhí)行簡化一致性協(xié)議，直到完成本次共識。

2) 若判斷共識節(jié)點中出現(xiàn)拜占庭節(jié)點，則主節(jié)點終止本次簡化一致性協(xié)議的運行；全網(wǎng)節(jié)點執(zhí)行完整一致性協(xié)議，完成本次請求信息的共識過程。當完整一致性協(xié)議完成后，系統(tǒng)扣除拜占庭節(jié)點的信譽值，并重新選擇主節(jié)點和共識節(jié)點，在下一次共識過程中繼續(xù)執(zhí)行簡化一致性協(xié)議。

4.4 通信量對比

假設此時區(qū)塊鏈網(wǎng)絡中有n個節(jié)點，在PBFT算法的一致性協(xié)議的預準備階段中，主節(jié)點向所有共識節(jié)點廣播預準備消息，通信次數(shù)為n-1 次；準備階段中，所有共識節(jié)點分別向除自身之外的共識節(jié)點廣播準備消息，通信次數(shù)為n(n-1)次；提交階段中，所有共識節(jié)點分別向除自身之外的共識節(jié)點廣播提交消息，通信次數(shù)為n(n-1)次。由此可知，PBFT 算法的一致性協(xié)議總通信次數(shù)為2n2-n-1 次。

在RPBFT 算法簡化一致性協(xié)議的預準備階段中，主節(jié)點向所有共識節(jié)點廣播預準備消息，通信次數(shù)為n-1 次；反饋階段中，共識節(jié)點將反饋消息發(fā)送給主節(jié)點，通信次數(shù)為(n-1)次；驗證階段中，主節(jié)點將驗證消息發(fā)送給所有共識節(jié)點，通信次數(shù)為(n-1)次。由此可知，RPBFT 算法的簡化一致性協(xié)議總通信次數(shù)為3n-3 次。

可以看出，RPBFT 算法的通信次數(shù)遠小于PBFT 算法的通信次數(shù)，減少了網(wǎng)絡帶寬的消耗，提高了共識算法的效率。值得注意的是，上述通信次數(shù)的計算是建立在區(qū)塊鏈網(wǎng)絡中不存在拜占庭節(jié)點情況下的。當區(qū)塊鏈網(wǎng)絡中存在拜占庭節(jié)點時，RPBFT 算法會執(zhí)行完整的一致性協(xié)議，其通信次數(shù)與PBFT 算法一致。

5 實驗結果與分析

本文使用超級賬本的子項目Caliper 對RPBFT 算法進行實驗評估。Hyperledger Caliper 是華為公司參與設計和開發(fā)的一個項目，它是一個區(qū)塊鏈基準測試工具。為不失一般性，每次實驗測試10 次，取平均值作為測試結果。

5.1 性能測試與結果分析

1) 共識時延測試

共識時延是指從交易提起到交易結束所消耗的時間，是衡量共識算法運行速度的重要指標[17]。為了對比RPBFT算法和PBFT算法在共識時延上的差別，在固定4 個共識節(jié)點和相同時間間隔的情況下，系統(tǒng)分別發(fā)送200 條、400 條、600 條、800 條、1 000 條交易的對比實驗，實驗結果如圖7 所示。

圖7 中，當區(qū)塊鏈內不存在拜占庭節(jié)點時，RPBFT 算法執(zhí)行簡化一致性協(xié)議，其共識時延明顯低于PBFT 算法。當交易量增加時，PBFT 算法的交易時延增長迅速，而RPBFT 算法與之相比增速較慢，在交易量為1 000 條時，時延降低約30%。因此，當交易量增多時，RPBFT 算法的優(yōu)勢更為明顯，時延更低。

圖7 相同節(jié)點數(shù)量，不同交易量下共識時延的對比

2) 吞吐量測試

吞吐量（TPS,transaction per second）是單位時間內打包的交易數(shù)量，是反映共識算法性能的關鍵指標[13]。為了對比RPBFT 算法和PBFT 算法在TPS 上的差別，本文進行如下實驗：固定4 個共識節(jié)點情況下，相同時間間隔內分別發(fā)送1 000 條、1 500 條、2 000 條、2 500 條、3 000 條交易量，實驗結果如圖8 所示。

圖8 相同節(jié)點數(shù)量，不同交易量下TPS 的對比

圖8 中，當區(qū)塊鏈內不存在拜占庭節(jié)點時，RPBFT 算法會執(zhí)行簡化一致性協(xié)議，其TPS 明顯大于PBFT 算法，在交易量為2 500 條時，RPBFT的TPS 較PBFT 增長了約250%。當交易量過大，超出系統(tǒng)處理能力時會造成線程堵塞，使TPS 呈現(xiàn)下降態(tài)勢，但從整體上看，RPBFT 算法的TPS 仍舊高于PBFT 算法。

5.2 安全性分析

在本文提出模型中，施工單位通過上傳監(jiān)測數(shù)據(jù)至區(qū)塊鏈的行為，將監(jiān)測數(shù)據(jù)訪問控制權和數(shù)據(jù)安全性托付給了區(qū)塊鏈。在本文模型中施工單位可能成為攻擊者，攻擊目的是逃避事故后的責任追究，因此攻擊者想要成功逃避責任則必須篡改鏈上數(shù)據(jù)。本節(jié)根據(jù)參考文獻[19-20]中攻擊可能性和攻擊成功概率的量化分析方法，對本文模型進行分析。攻擊者攻擊成功的概率函數(shù)表示為

其中，Δh為攻擊者想攻擊的區(qū)塊與最新區(qū)塊的高度差。為了比較高度差不同時的攻擊成功概率，本節(jié)實驗對比了Δh分別為4、6、8、10 的Pt(h)，如圖9 所示。圖9 中橫坐標的單位M 表示未被攻擊節(jié)點生成一個區(qū)塊的平均時間。

圖9 攻擊成功概率對比

由圖9 可知，攻擊者攻擊成功的概率隨著高度差Δh的增大而減小。當攻擊者的算力小于未被攻擊節(jié)點算力時，攻擊者首先需要生成攻擊區(qū)塊與最新區(qū)塊之間的Δh個區(qū)塊，然后才可以與未被攻擊的節(jié)點競爭產生新區(qū)塊，攻擊成功的概率先增大后減小，最終趨于0。當攻擊者的算力與未被攻擊節(jié)點相同時，攻擊成功的概率會逐漸變大，但變大幅度越來越小[20]。在本文場景中，攻擊者攻擊區(qū)塊的目的往往涉及事故后的追責，此時距離區(qū)塊生成時間間隔較長，區(qū)塊高度差Δh的值至少達到103的數(shù)量級，即使攻擊者算力與未被攻擊節(jié)點算力相同，完成攻擊的概率也是極低的。

5.3 對比分析

傳統(tǒng)基于中心化云存儲的數(shù)據(jù)共享模型不可避免地存在數(shù)據(jù)被篡改的安全問題，區(qū)塊鏈本身的防篡改特點對能夠有效避免該問題，但區(qū)塊鏈自身數(shù)據(jù)庫并不支持海量流式鐵路施工項目監(jiān)測數(shù)據(jù)的存儲，因此需輔以其他存儲手段，且鐵路施工項目監(jiān)測產生的流式數(shù)據(jù)對區(qū)塊鏈的存儲與共享過程中的共識算法效率要求較高。本文將共識機制、共識效率、吞吐量、區(qū)塊生成速度和算力需求作為對比指標，將本文提出的模型與文獻[8,21-22]進行對比分析，結果如表1 所示。

表1 對比分析結果

根據(jù)5.1 節(jié)的實驗結果可以看出，RPBFT 算法在共識效率、吞吐量和區(qū)塊生成速度方面優(yōu)于PBFT 算法，且算力需求比PBFT 低。文獻[8]提出的鐵路數(shù)據(jù)匯集共享系統(tǒng)能將鐵路數(shù)據(jù)規(guī)范存儲、管理和應用，但使用的PBFT 算法存在通信量大和主節(jié)點選擇隨機的問題。文獻[21]使用混合共識的方式解決拜占庭節(jié)點問題，導致共識過程復雜，共識效率和吞吐量較低，區(qū)塊生成速度緩慢，且節(jié)點中同時運行2 種共識算法，對算力的需求較高。文獻[22]的DPCC（disease prevention and control algorithm）是基于DPoS（delegated proof of stake）算法的改進方案，優(yōu)化了節(jié)點選舉方式，共識效率相對較高，但是其每次共識時都需要選擇一個出塊節(jié)點導致其吞吐量有所降低；在區(qū)塊生成速度方面，DPCC 繼承了DPoS的快速出塊特點[22]。由表1 可知，本文模型與其他模型相比，在共識效率、吞吐量和區(qū)塊生成速度方面表現(xiàn)較優(yōu)秀。

6 結束語

區(qū)塊鏈技術的去中心化、防篡改特點為鐵路工程施工安全監(jiān)測數(shù)據(jù)共享中的安全問題以及保證監(jiān)測數(shù)據(jù)真實性提供了新的解決思路。本文首先提出了基于區(qū)塊鏈的鐵路工程施工安全監(jiān)測數(shù)據(jù)共享模型，并對該模型的框架、參與者和共享流程進行了說明；其次，通過智能合約實現(xiàn)了監(jiān)測數(shù)據(jù)的存儲與查詢功能，施工單位可以通過存儲合約實現(xiàn)監(jiān)測數(shù)據(jù)的上鏈存儲，監(jiān)管單位和業(yè)主單位可以通過查詢合約查詢歷史監(jiān)測數(shù)據(jù)；然后，針對PBFT算法的拜占庭節(jié)點與正常節(jié)點被選為主節(jié)點概率相同以及共識過程中通信量較大的問題，結合鐵路施工項目監(jiān)測到的流式數(shù)據(jù)特點，提出了RPBFT算法，降低了通信量和拜占庭節(jié)點作為主節(jié)點的概率；最后，在Hyperledger Caliper 中的對比實驗證明，RPBFT 算法共識時延與吞吐量均優(yōu)于PBFT 算法，時間復雜度由O(n2)降為O(n)；攻擊可能性和攻擊成功概率的量化分析結果表明，智能合約技術為鏈上監(jiān)測數(shù)據(jù)提供了防篡改性；與其他模型的對比分析表明，本文模型在共識效率、吞吐量和區(qū)塊生成速度方面表現(xiàn)較優(yōu)秀。