區塊鏈相關技術在鐵路客票系統中的應用研究

戴琳琳，賈成強，苗 凡，楊海峰

（1.中國鐵道科學研究院集團有限公司，北京 100081；2.中國鐵路南昌局集團有限公司，南昌 330000）

區塊鏈（blockchain）已經成為當下炙手可熱的新興技術，是基于分布式存儲、共識機制、點對點傳輸、加密算法等計算機技術的新型應用模式。基于區塊鏈技術的分布式系統是完全去中心化的節點自組織、自驗證的可靠系統。運用該技術衍生出大量應用，例如比特幣（BitCoin）、Tezos 智能合約系統、Synereo 分布式社交網絡等。

目前，鐵路客票系統部分業務系統的應急工作模式如圖1 所示，中國國家鐵路集團有限公司（簡稱：國鐵集團）級系統與鐵路局集團公司級（簡稱：鐵路局級）某單點服務器進行定期數據同步，如果國鐵集團級系統出現故障，可以降級到鐵路局級的該臺服務器上進行應急期間數據查詢和業務操作，車站應急也類似。即在鐵路局或車站應急期間，分布式的客票系統會降級為集中式的單點模式。因此迫切需要剖析區塊鏈的關鍵技術細節，將其在客票系統中進行創新應用。

圖1 客票系統現有業務系統應急模式示意圖

本文在目前業務模型框架下利用區塊鏈相關技術改進現有集中式應急系統模型，設計分布式的智能應急模型，實現應急數據的智能同步。

1 分布式系統同步算法分析

分布式系統具有節點動態調整和系統容錯性強的特點，該系統的難點是數據同步，根據同步模式可分為始終一致（Always Consistent）和最終一致（Eventually Consistent）2 種，其中始終一致同步模式，是強同步模式，要求分布式系統的大多數節點數據在任何時刻都保持一致，代表算法有Paxos算法，代表應用有ZooKeeper 等[1-2]；最終一致同步是松耦合同步，分布式系統的各節點保持自己的數據，通過消息交互逐漸達成一致，代表算法有區塊鏈共識算法[3-5]、DHT 算法[6-8]等，代表應用有比特幣和電驢等。

1.1 Paxos同步算法

Basic Paxos 算法中節點有提議者、接受者和觀察者3 種角色。由提議者提出一個同步準備請求，過半的接受者同意后，提議者發出真正同步請求，過半的接受者接受后，實現節點間同步。為了防止活鎖（2 個提議者輪流提議而導致節點間長時間達不成一致），提議者在發現有更高編號的提議時，該提議者靜默一段時間后再進行下一輪提議。但每次數據同步都使用這一流程，效率比較低，因此在實際應用中都采用有領導者模式的Multi-Paxos 算法，即各個提議者節點自主選擇出一個領導者節點，這個節點負責數據同步的提議，大家追隨它進行同步，如果該節點出現故障，需要重新選擇領導節點。由于算法在多節點情況下同步效率較低，一般應用中不會超過20 個節點。

1.2 區塊鏈共識算法

區塊鏈共識算法是區塊鏈技術中創造性的價值體現之一，比特幣是區塊鏈最成功的應用實例，本文以比特幣實現作為區塊鏈機制的主要參考。截至2018 年5 月7 日，比特幣區塊鏈上有10 450 個節點。每個節點都保存著一份關于它對整個區塊鏈理解的區塊鏈數據。通過不停地監聽新塊產生的消息，驗證新塊數據正確，自主維護區塊鏈。

由于新塊產生和廣播的速度不一致，比特幣區塊鏈每個節點上的區塊鏈數據在某個時刻不都是一致的，在特定時刻還可能出現區塊鏈分支的情況，但是比特幣區塊鏈的共識算法，通過工作量證明的難度設計和全網節點間接投票決定（最長區塊鏈策略）的方法，可以保證經過一段時間后，全網大多數節點會達成一致，這種同步機制是完全自主實現的，對于節點數沒有限制。

2 智能應急系統設計

2.1 系統需求

本文設計的客票智能應急系統，需要滿足以下需求：（1）充分利用現有客票系統已有服務器、終端設備的計算和存儲能力；（2）應急存儲客票數據具有可追溯的邏輯鏈條；（3）應急節點動態調整，數據智能分布，在應急狀態下減少人工干預環節，允許部分（最新）數據不一致。

2.2 系統架構

智能應急系統由應急數據私鏈和應急交易私鏈組成，如圖2 所示。在業務正常運行時，各業務系統同步業務數據到應急數據私鏈上，應急數據私鏈是基于區塊鏈技術實現的分布式數據存儲層，允許有一定的數據同步延時。而應急交易私鏈則是一個典型的分布式交易集群。

業務系統在進入應急模式后，與應急交易私鏈進行應急期間交易，例如，若國鐵集團級業務系統發生故障，鐵路局級業務系統就調用應急交易私鏈繼續進行國鐵集團級業務數據交易，應急交易私鏈支持快速應用交易，并且使用應急數據私鏈存儲應急交易數據。

應急結束后，業務系統查詢應急數據私鏈，尋找屬于自己的、最新的應急數據，進行應急數據恢復，例如，國鐵集團級業務系統一直在監聽應急數據私鏈上關于本級系統的應急數據是否有變化，然后提取數據并進行處理，存儲于原系統中。

綜上，由應急數據私鏈和應急交易私鏈構成了全網分布、適應于各級業務系統故障的智能應急系統，與客票分布式系統相比有更大優勢。智能應急系統屏蔽了各級業務系統間的區別，使用統一的分布式數據鏈存儲數據，統一的交易鏈處理交易，具有更強的通用性。

圖2 智能應急系統架構圖

2.3 應急交易私鏈拓撲

為了快速處理交易，應急交易私鏈是一個分組、分節點的傳統分布式交易系統，每個組各節點一起承擔處理應急業務交易工作，同一個交易業務ID（根據業務要求來定義，可以是鐵路局碼+ 車站碼+ 售票處號+ 終端號，也可以是用戶證件號+ 日期+ 車次）的交易是由同一組節點處理的，并且由每個組的領導者發布交易數據。

如圖3 所示，在全路建立9 ～11 組的交易節點組（不同顏色虛線圈代表不同組），每個交易組內有5 ～9 個交易節點，每個交易組選出領導者節點，該節點負責將組內交易數據發布到應急數據鏈，全路領導者節點間同步應急交易分組規則。同一個業務操作產生的多條交易數據可以按照交易順序統一由領導者節點提交到應急數據私鏈中，從而保障交易的原子性。

圖3 應急交易私鏈拓撲圖

2.4 應急數據私鏈拓撲

應急數據私鏈采用區塊鏈技術，充分利用現有客票各個系統的計算和存儲能力，并且考慮到各個系統的數據存儲條件，其中，每個節點可根據能力和角色選擇是否保持全量數據。

如圖4 所示，國鐵集團級和鐵路局級參與應急數據私鏈的節點大多數是服務器，存儲能力相對較強，可以將節點角色定位成全功能節點，存儲全量數據；車站參與應急數據私鏈的節點一般能力有限，可將節點角色定位為部分功能節點或瘦客戶端節點。全功能節點間通過區塊鏈協議和數據組織結構進行數據同步和保存；部分功能節點和全功能節點組成局部網絡，進行全區塊鏈全數據的分片存儲[9]；終端用瘦客戶端節點接入系統，只查詢數據，不存儲數據。

圖4 應急數據私鏈節點拓撲圖

2.5 應急數據私鏈同步機制

比特幣區塊鏈通過工作量證明來限定新塊的產生速度。工作量證明的實質是對新塊塊頭執行哈希算法，通過調整新塊塊頭里的一些可變字段，來改變哈希值，直到得到的哈希值小于難度目標值。為了控制新塊產生時間在10 min 左右，難度目標值設定前幾十個（70 左右）比特位都是0。

由于應急數據私鏈在客票專網運行，網絡條件有保證，網絡節點規模較小，可以適當縮短新塊產生時間，因此該私鏈工作量證明的難度設置可以把前面比特位為0 的個數調小，設置為22 位左右，那么新塊產生時間只需要13 s 左右，這個時間對于在專網進行數據傳播和應急數據更新延時來說，都是可以接受的。

2.6 應急數據結構

2.6.1 區塊鏈數據存儲結構分析

比特幣區塊鏈實現了一個鏈條式的數據存儲結構，如表1、表2 所示，區塊鏈上的每個區塊單向相連，存放父塊的塊ID（塊ID 是塊頭的哈希值），形成一個賬簿形式的數據結構。子節點保持父節點的哈希值，也是一種對父節點的校驗，每個節點在區塊鏈上增加新塊時，都會對新塊進行計算校驗。

表1 比特幣區塊鏈塊定義列表

表2 比特幣區塊鏈塊頭定義列表

在比特幣區塊鏈中，每個塊內包含多個交易，交易是公開的，只是交易擁有者是匿名的，每個交易有若干個輸入和輸出定義，如表3、表4 所示，交易輸入代表交易的來源點，交易輸出代表交易的消費點，輸入里包含交易哈希值，可通過一個交易追溯到該交易的全流程。

表3 交易輸入定義列表

表4 交易輸出定義列表

2.6.2 應急數據結構設計

在客票智能應急系統的應急數據私鏈設計中，參照2.6.1 中比特幣區塊鏈的數據存儲結構。區塊鏈中每個區塊存放著若干客票業務操作數據，有些數據的來源點可以是空的，表明這個是一張新票存根數據；已有票的更改或其他延伸服務數據變化的輸入點是原有票，輸出點是客票變更業務數據。應急數據不考慮匿名消費機制。

區塊鏈可以接收由正常業務系統產生的單條交易數據，也可以接收由應急交易私鏈產生的塊交易數據，并且在交易中標識出應急標識，為應急結束后的應急數據恢復提供支撐。

區塊鏈數據大小估算。每個客票交易數據大概200 B，每個區塊存儲1 000 條交易數據，大小在2 KB左右，以每天400 萬條客票業務操作來計算，每天累計私鏈數據8 GB 左右。

3 結束語

本文討論了分布式系統相關技術，包括Paxos 同步算法、區塊鏈共識算法、比特幣區塊鏈數據組織等。通過分析算法和機制得出，區塊鏈相關技術適用的交易系統具有分布式數據存儲冗余性強，可容忍交易確認延時，數據透明可追溯及安全強校驗等特點[10]，客票應急系統滿足這些特點，因此本文設計了基于區塊鏈相關技術的雙鏈智能應急系統，對現有客票應急系統提供了相應的技術改造方案，該方案發揮了區塊鏈技術完全去中心化、節點自組織和自驗證的優勢，將新興技術在客票系統應用上做出大膽嘗試。