徐 濤 楊 陽 劉才華
(中國民航大學計算機科學與技術學院 天津 300300)(中國民航信息技術科研基地 天津 300300)
在多方協作場景中,多采用中心化架構設計應用系統。由于缺少信任機制,每一方都需要構建單獨的數據庫,而多個數據庫之間易存在數據差異,可能導致繁瑣的人工對賬和爭議[1-2]。區塊鏈技術作為一種全新的分布式賬本技術,具有去中心化、開放性、不可篡改等特點[3],是解決這些問題的一種有效方法。
目前區塊鏈技術在多種場景已得到廣泛應用[4-6],然而鮮有針對民航應用領域的區塊鏈技術研究。將區塊鏈應用于民航業有以下優勢:區塊一經生成便無法修改,防止航班信息被篡改;區塊鏈的數據共享分布到各個節點之間進行,部分節點或網絡受到損壞時對其他節點的影響很小,保障航班信息安全共享;每個參與者都將保存區塊數據,比傳統數據庫更易于被所有成員共同維護和監管。
在民航領域的信息共享中,尚未出現涉及民航具體業務流程的區塊鏈應用架構,而直接應用區塊鏈架構無法滿足民航有機隔離的多方參與需求:區塊鏈中的參與成員對其他用戶的訪問無感,且無法直接追溯訪問信息,難以監管區塊訪問;區塊鏈將數據公開透明的全部存儲在每個節點上,對僅部分用戶能夠訪問的數據沒有其他的管理機制,無法滿足不同用戶對提供的航班信息隱私保護需求;直接將區塊鏈架構應用在航班運行數據存儲上,存在多節點信息存儲量過大的問題。因此需結合航班保障流程,設計一種在滿足民航業務需求的基礎上,既能保障數據的有機隔離,又能保障航班運行數據防篡改、易追溯、保護隱私的系統架構。
本文結合航班協同運行保障過程中的實際運行流程,提出基于區塊鏈技術的航班協同運行保障系統架構,主要貢獻如下:(1) 將航班運行過程中的實際數據與區塊鏈技術相結合,設計應用于民航領域的航班信息共享鏈架構,為實現航班協同運行保障系統;(2) 設計訪問事件監管機制,通過自動執行智能合約的方式將訪問記錄保存到區塊鏈中,以監管和追溯訪問事件;(3) 根據航班運行具體業務流程和不同參與方的共享需要,設計既能共享數據又能隔離數據的多通道方案。
區塊鏈是由多個獨立節點組成,用來維護區塊數據的分布式數據庫系統[7],也可稱之為分布式去中心化賬本。區塊鏈記錄所有數據事件信息,過程透明、數據安全性高,且區塊由所有參與節點共同維護,不易篡改、難偽造、可追溯。
隨著區塊鏈技術的飛速發展,涌現了多種應用場景下的區塊鏈解決思路,例如:Yuan等[8]提出基于超級賬本的排放交易系統,通過在區塊鏈中設計特定的賬本結構和智能合約來實現業務邏輯;Raikwar等[9]提出基于區塊鏈的保險處理平臺,給參與者提供細粒度的訪問控制;對于車載系統,Yang等[10]提出基于區塊鏈的車載網絡中的分布式信任管理系統。顯然,區塊鏈在各個領域的應用都在逐步拓廣與加強。
在民航領域,國際航空電訊協會(Societe International De Telecommunications,SITA)引入區塊鏈技術,利用分布式記賬技術實現多個企業間的數據共享;新加坡航空公司為常旅客推出一個數字錢包計劃,成為“世界上第一個基于區塊鏈的航空公司忠誠度數字錢包”。在國內,以南方航空為代表的航空公司開展了區塊鏈技術在民航業的應用探索,建立了積分和里程兌換系統,實現實時積分兌換里程功能。民航在區塊鏈上的有許多可實現的應用方向,例如航班運行系統、行李跟蹤系統,但仍亟待需要結合具體業務和實際應用流程,設計應用架構。
航班協同運行保障是航空運輸中民航領域的核心業務,如何打破各個參與方之間的信息壁壘又能保障數據隱私是關鍵。目前民航領域多采用面向機場運行的協同決策系統A-CDM(Airport—Collaborative Decision Making)解決信息共享問題。A-CDM系統是由機場主導,航空公司、空管、地服公司共同參與的協同決策機制,核心是航班運行數據的協同共享。其中心化架構特點使數據易引起爭議,且參與方之間的數據隱私保護需求未考慮全面。
區塊鏈可在互不了解的聯盟成員之間和沒有第三方機構的協調下建立可靠的信任,實現可信的數據共享。因此,將區塊鏈技術應用于航班協同運行保障過程中,不僅給民航業帶來新的信息共享解決思路,還能針對性地解決其信息共享問題。
航班信息共享鏈架構是基于區塊鏈技術的航班協同運行保障系統應用的基礎架構,其主體為航空公司、機場、空管、地服公司。該架構在區塊鏈基礎架構和區塊鏈網絡節點分布上進行改進。
結合具體航班運行數據和區塊鏈基礎架構,將航班信息共享鏈的層次結構分為數據層、區塊鏈服務層、智能合約層、應用層(如圖1所示)。

圖1 航班信息共享鏈層次結構
數據層主要是對航班運行保障數據進行加密、存儲為區塊、數據驗證等,包含航班號、執行日期、計劃出發時間、到港航班停機位、進港跑道號、實際落地時間、配餐開始時間、配餐結束時間、擺渡車到位時間、計算撤輪擋時間、目標撤輪擋時間等信息。為滿足民航業務不同形式的數據存儲需求,摒棄傳統區塊鏈中以key-value形式存儲數據的LevelDB數據庫[2],使用可存儲多種數據格式的CouchDB數據庫。
區塊鏈服務層包括節點管理、區塊管理和一致性管理。節點管理包括授權許可和主節點選取,其中授權許可是參與方各自對參與交易的節點給予許可,主節點用于對其他節點廣播區塊;區塊管理是對每個區塊數據的管理,即節點將每次請求所需存儲的數據存入對應的通道中,不同數據對應不同通道;一致性管理包括建立區塊、發送區塊、區塊投票,其中區塊投票采用拜占庭共識協議PBFT(Practical Byzantine Fault Tolerance)[11],通過PBFT共識機制使所有的誠實節點達成一致。
智能合約層包括航班運行流程中不同業務的合約條款。該層提供建立合約的環境,并由相關參與者進行合法性和正確性驗證,最后部署在區塊鏈系統中。
應用層是基于區塊鏈技術的應用系統,且根據數據層、區塊鏈服務層和智能合約層實現,比如基于以太坊的旅客積分優惠系統、旅客行李跟蹤系統、基于超級賬本[11]的航班信息共享系統等。
通過對民航業務需求分析,結合區塊鏈網絡節點,得到航班信息共享鏈的網絡結構如圖2所示。其網絡結構由機場、地服、航空公司、空管四個參與方組成,每個參與方至少包括以下五個節點:證書頒發機構、主節點、背書節點、錨節點、記賬節點。

圖2 航班信息共享鏈網絡結構圖
證書頒發機構是航班協同運行保障系統的證書頒發機構節點,每個機構都配置一個證書頒發機構節點,且可根據自己的需求增加節點;背書節點負責對客戶端的交易提案進行檢查和背書;主節點用于鏈接排序服務,排序服務進行交易排序后,主節點將區塊分發到所在參與方的其他節點上[12];錨節點用來與其他參與方交互,它能發現通道中所有節點,配置多個錨節點能防止單節點故障;記賬節點用來接收交易區塊,驗證區塊合格后保存到自己的賬本中。以上非證書頒發機構節點除了默認是記賬節點外還可擔任其他一到多種角色,即某個節點可以同時是記賬節點和背書節點,也可以同時是記賬節點、背書節點、主節點、錨節點。
以地服工作人員存儲目標撤輪擋時間為例,說明在實際的航班信息共享鏈網絡中各個參與方之間的數據流通過程如圖3所示。

圖3 地服參與者存儲目標撤輪擋時間具體過程
地服存儲目標撤輪擋時間具體過程為:地服工作人員向其他參與方發送存儲目標撤輪擋時間請求;航空公司、空管、機場的背書節點檢查其地服簽名,若正確,則給該請求簽名并將信息發送給地服;地服節點收到簽名后,若滿足背書策略則給排序節點發送簽名后的存儲請求;排序節點將該事件生成區塊后分發給各個參與方的主節點,主節點將其分發給同一參與方的其他節點,最后完成該區塊的存儲。
綜上,航班信息共享鏈的層次結構結合實際民航業務和區塊鏈基礎架構,利用區塊鏈的特性保障航班協同運行,且其網絡結構內所有參與節點都是系統的重要組成,所有數據操作過程都由每個參與者維護,能確保系統具有信任和分布式的特征。
訪問事件監管機制可追溯用戶訪問信息,具體執行方式是:用戶訪問航班協同運行保障系統時,系統通過自動執行智能合約的方式將訪問記錄提交給區塊鏈網絡,并將訪問記錄形成區塊,然后航班信息共享鏈分發該區塊給每個節點。
以參與成員修改目標撤輪擋時間為例(如圖4所示),當一個參與方修改目標撤輪擋時間時,節點自動保存該條執行修改的訪問記錄,此時其他參與方可以通過查詢操作來追溯網絡中的訪問事件。

圖4 參與成員修改目標撤輪擋時間時自動保存訪問事件示例
訪問事件無時無刻都在發生,若將訪問信息全部存儲在節點上,會存在存儲量過大的問題,因此僅存儲訪問事件的關鍵要素:訪問者、時間、IP地址、操作、字段,其中操作為增加、刪除、查詢、修改,字段為訪問者訪問的航班運行數據。用戶訪問區塊數據后,訪問事件將以表1形式存儲在區塊鏈中。

表1 訪問事件示例
綜上,當航班協同運行保障系統檢測到用戶對航班信息變更或訪問航班運行數據時,將自動生成一個區塊來保存訪問事件,不僅能保障每個參與者對每個航班運行數據的每項操作都是負責任的,還能使用戶對訪問事件可追溯,有效監管訪問事件。
在航班運行過程中,因航班運行數據項較為固定,故根據航班運行具體流程中不同保障時間段劃分通道,其航班運行流程如圖5所示。

圖5 航班運行流程示例
首先,航班運行流程通常由進港、過站和離港三個階段組成,為利用多通道優勢減少存儲空間,可按與業務流程相關的信息分別單獨劃分通道,故將通道劃分為四大類:航班信息通道、進港航班保障通道、過站航班保障通道、離港航班保障通道。其中航班信息通道存儲提前預知的航班基本信息,進港航班保障通道、過站航班保障通道、離港航班保障通道分別存儲進港、過站、離港的航班運行數據。
其次,由于進港、過站、離港涉及到的航班信息并非所有參與方都能訪問,且參與方所需訪問信息不同,還可將進港通道、過站通道和離港通道劃分為若干子通道(如圖6所示)。因航班運行數據過多,圖6僅給出空管、機場、航空公司、地服與部分子通道之間的關系。

圖6 多通道劃分
航班信息通道用于存儲提前預知的航班信息,包括航班號、執行日期、計劃出發時間等。該通道保存所有參與方必須知道的信息,故所有參與方都加入。
進港航班保障通道用于存儲進港流程中所涉及的航班運行數據,包括進港跑道號、實際落地時間等。進港跑道號和實際落地時間都是由空管提供,僅有機場能查看,故將這些數據單獨劃分子通道,且僅有空管和機場能訪問。
過站航班保障通道用于存儲過站流程中所涉及的航班運行數據,包括配餐開始時間、配餐結束時間、擺渡車到位時間等。其中配餐開始時間、配餐結束時間由航空公司提供,僅地服需要,故僅地服和航空公司能訪問。擺渡車到位時間由地服提供,航空公司后續提供的數據需參考該數據,故航空公司能訪問。因僅航空公司和地服擁有配餐開始時間、配餐結束時間、擺渡車到位時間的訪問權限,故將這些數據存儲于同一子通道中,且僅航空公司和地服可訪問。
出港航班保障通道用于存儲出港流程所涉及的數據,包括計算撤輪擋時間、目標撤輪擋時間等。因僅空管、機場、地服擁有計算撤輪擋時間和目標撤輪擋時間的訪問權限,故將這些數據劃分到同一通道。
綜上,多通道設計的劃分規則是:根據參與方對航班運行數據訪問的需求,相同參與方的數據項配置到相同通道中。
本實驗包括四個參與方:航空公司、地服、空管、機場,實驗數據為首都機場的實際航班運行數據。針對多通道設計方案和非多通道模式進行實驗對比,衡量通道設計對存儲空間的影響。
首先,在多通道設計方案下,分別記錄每個節點分別存儲航班信息、進港航班信息、過站信息、離港信息的通道容量大小;其次,對存儲同類通道信息的容量求和,得到航班信息容量、進港信息容量、過站信息容量、離港信息容量;最后,記錄在非多通道模式下存儲相同信息的容量總和(如表2所示)。

表2 通道存儲容量比較
比較多通道設計下總容量和非多通道總容量可以得出:1) 在整個航班信息共享鏈中存儲相同數據量時,多通道模式下所有節點的存儲容量總和跟非多通道設計模式比減少了46%的存儲空間;2) 隨著數據量線性增長,多通道模式下節省的容量也線性增加。
綜上,多通道方案將航班數據在不同的信息共享域之間隔離,不僅滿足了每個參與方的隱私保護需求,還縮減了節點通道數,降低了節點存儲空間。
本文提出了一種基于區塊鏈技術的航班協同運行保障系統架構,根據實際航班運行數據監管和隱私保護需求設計訪問事件監管機制和多通道方案。在滿足航班運行具體流程的業務需求下,不僅為保障航班協同運行提供區塊鏈技術的架構方案,還為民航業的數據共享問題提供了新的技術思路。