基于區塊鏈的鐵路工程施工安全監測數據共享關鍵技術研究

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

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

1 引言

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

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

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

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

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

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

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

2 基于區塊鏈的鐵路工程施工安全監測數據共享模型

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

基于區塊鏈的鐵路工程施工安全監測數據共享模型如圖1 所示，模型中區塊鏈節點主要分為業主單位、施工單位和監管單位。

圖1 基于區塊鏈的鐵路工程施工安全監測數據共享模型

業主單位。業主單位是鐵路工程施工的投資主體，是鐵路工程施工的發起者，也是施工過程的管理者。

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

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

模型結構主要包括智能合約、區塊鏈網絡、數據中心和物聯網設備。

智能合約保存在區塊鏈上，鏈內各節點可以查看并執行智能合約指令，還可以查看節點與智能合約交互日志[11]。通過智能合約，施工單位可以將數據存儲在去中心化的區塊鏈網絡中，監管單位和業主單位可以監測數據進行查詢。

區塊鏈網絡主要包括節點網絡和共識機制，在節點網絡中的節點維護自己的分布式賬本。節點網絡主要包括共識節點和驗證節點，共識節點負責驗證數據存儲或查詢交易并執行共識算法，還在自身分布式賬本中記錄存儲的數據；驗證節點負責驗證數據存儲或查詢交易。

數據中心用于存儲鐵路施工現場傳輸的原始監測數據，對監測數據進行轉換、處理、特征提取等操作，最后將特征值、異常值等構成的監測數據索引與摘要傳輸給監管單位。

物聯網設備指鐵路施工現場的監測數據收集與傳輸設備，由于傳感器本身不具備數據的遠程傳輸能力，因此需要借助數據傳輸單元（DTU,data transfer unit）進行數據的遠程傳輸。

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

圖2 監測數據存儲流程

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

圖3 監測數據查詢流程

3 相關合約設計

在本文方案中，參與方將通過聯盟區塊鏈的遠程過程調用（RPC,remote procedure call）接口實現監測數據索引的存儲與查詢。據此本文設計了監測數據存儲合約和監測數據查詢合約。

3.1 監測數據存儲合約

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

算法1監測數據存儲合約

輸入監測數據索引MD

輸出存儲成功Req

3.2 監測數據查詢合約

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

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

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

算法2監測數據查詢合約

輸入查詢請求R

輸出查詢結果result

4 PBFT 算法的改進

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

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

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

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

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

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

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

4.1 基于節點行為的獎勵機制

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

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

2) 基于信譽分數的主節點和共識節點選取方案

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

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

4.2 完整一致性協議分析與簡化設計

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

1) 完整一致性協議分析

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

圖4 完整一致性協議執行過程

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

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

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

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

2) 簡化一致性協議設計

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

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

圖5 簡化一致性協議運行過程

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

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

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

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

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

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

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

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

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

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

4.3 算法的流程

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

圖6 RPBFT 算法流程

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

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

所有共識節點執行簡化一致性協議，在簡化一致性協議的執行過程中，對所有參與共識的節點狀態進行判斷，算法根據判斷結果進行操作，具體如下。

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

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

4.4 通信量對比

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

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

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

5 實驗結果與分析

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

5.1 性能測試與結果分析

1) 共識時延測試

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

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

圖7 相同節點數量，不同交易量下共識時延的對比

2) 吞吐量測試

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

圖8 相同節點數量，不同交易量下TPS 的對比

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

5.2 安全性分析

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

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

圖9 攻擊成功概率對比

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

5.3 對比分析

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

表1 對比分析結果

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

6 結束語

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