響應式許可鏈基礎組件
——RepChain*

李春曉, 陳 勝, 鄭龍帥, 左 春, 蔣步云, 梁 賡

1(中國科學院 軟件研究所,北京 100190)

2(北京連琪科技有限公司,北京 100086)

區塊鏈(blockchain)作為一種分布式可信賬本[1],以其具備的分布式、去中心化、可追溯、不可篡改等特點,在全球金融和IT等領域掀起一波發展熱潮,誕生了更靈活的商業模式[2],并推動了信任經濟時代的快速發展.

然而迄今為止,區塊鏈技術中最具影響力的領域仍然局限于以比特幣實驗和以太坊為代表的公有鏈和虛擬貨幣領域[3-6],對于區塊鏈技術在企業級場景的應用仍然處于探索階段[7,8].區塊鏈的核心價值是通過可被多方驗證的賬本數據建立多方信任,公有鏈系統中固化的用戶匿名、激勵機制、完全去中心化、競爭性共識都是在其特定場景下采用的技術手段而非核心價值,在企業應用中,必須根據具體場景對其重新審視.現有的公有鏈開源程序難以為企業級場景所利用.

許可鏈對于參與組網的節點采取身份準入,并在此基礎上建立安全的通信信道.相對于公有鏈提高了節點之間的信任程度,以此為基礎,可以通過減少參與共識節點的數量、用協同性的共識代替公有鏈的競爭性共識,從而達到提高實時性和交易通量的企業應用目標.因此,企業應用場景通常選擇許可鏈的組網方式.現階段也出現了一些基于許可鏈面向企業應用的開源組件,但它們或多或少存在以下問題.

· 系統缺乏模塊化設計,系統各組成部分耦合高,難以對模塊進行替換或裁剪;

· 設計的目標場景過于多樣化,導致系統臃腫,當面對單一場景時,其裁剪工作量巨大;

· 缺乏性能的可擴展性設計,在BAAS(blockchain as a service)模式下,理想的超級節點應該能做到節點整體或節點內的某個處理環節自適應業務壓力,算力可伸縮;

· 缺少直觀的對區塊如何形成的展示過程.

為了解決上述問題,本文提出了響應式許可鏈的基礎組件——RepChain.目前,國內并沒有同類的開源基礎組件,本文的原創性貢獻如下.

(1) 采用無協商隨機抽簽算法(consultation-free random draw algorithm with distributed environment,簡稱CFRD)協同性共識代替公有鏈的競爭性共識;

(2) 以異步消息交互代替傳統的方法調用,實現了模塊之間松耦合,方便根據不同場景對模塊進行替換;

(3) 專注于提供必須的基礎模塊,用做加法的項目實施思路代替減法思路;

(4) 利用 Actor集群化[9],可以實現節點或節點內部細粒度的自適應彈性計算,根據業務壓力動態地申請或釋放算力資源;

(5) 利用 Actor的位置透明性,根據合約信任程度的不同采用不同的合約部署策略,從而合理解決了合約的安全隔離與執行性能之間存在的沖突;

(6) 采用圖形化的實時狀態顯示,搜集和直觀展示各節點入網與離網、數據同步、交易提交與傳播、出塊節點選舉、候選塊背書、正式出塊的完整過程.

本文第 1節介紹區塊鏈的核心價值和響應式編程的特點,并對比公有鏈和許可鏈的組網方式.第 2節介紹RepChain的系統結構,共分6個層次,對每一個層次的含義進行說明.第3節介紹RepChain的各個組成模塊,對每個模塊的設計方案進行說明.第4節介紹RepChain性能實驗.最后總結全文并進行展望.

1 引 言

1.1 區塊鏈技術

區塊鏈系統的核心價值是建立信任,區塊+鏈這種獨特的數據結構[10]忠實、完整地記錄了行為主體簽名認可的授權行為[11].用戶可以不信任區塊鏈系統,但它出具的每條數據皆有其授權來源,是可追溯并可驗證的.區塊鏈的實施要避免類似傳統系統越過行為主體的授權自行其是,并且好的區塊鏈系統應該讓行為主體在做出授權之前,清楚認識到其授權行為將可能面臨的風險[12,13].

區塊鏈的數據結構如圖 1(a)所示,它是由一系列前后銜接的區塊組成,每個區塊里面包含按順序排列的交易[14-16],每一個交易包含行為主體對授權行為的簽名認可,以此來滿足達共識[17]、可追溯[18]、防篡改[19]的目標,獨特的鏈式結構確保了數據只能增加不能刪除.

傳統應用數據結構如圖 1(b)所示,它是由各種表組成,數據本身缺乏可驗證的授權來源,用戶只能選擇信任這個系統;而對于區塊鏈來說,防篡改是指防止系統偽造或篡改數據,用戶不需要信任系統,只需要信任系統出具的可被驗證的數據.

通過區塊鏈和傳統應用數據結構的對比可以發現：區塊鏈最大的用處是通過對參與方授權行為完整的、忠實的記錄來建立各個行為主體之間的信任,將對傳統系統的信任切換到對系統出具的可驗證數據的信任,這是區塊鏈的本質特征.

公有鏈通常采用匿名、開放的組網策略[20],采用激勵機制吸引更多的算力加入組網;反過來,在龐大算力上形成的多數共識,又確保了共識結果的可信.但同時,公有鏈采用的這種大規模組網上的競爭性共識導致其交易實時性差,交易通量不高.許可鏈面向企業聯盟式行業應用,在身份準入的基礎上建立安全信道,降低參與共識節點的規模,用協同性的共識算法取代公有鏈競爭性的共識算法,這樣能夠較大地提高交易實時性和交易通量.

兩者的組網方式如圖2所示.

在圖 2(a)的公有鏈中,用戶節點B不需要其他節點(如在網節點A)審核并驗明身份;在圖 2(b)的許可鏈中,用戶節點B入網申請需經過其他節點(如在網節點A)進行核驗身份,并簽名擔保.在公有鏈中,密鑰是證明用戶身份的唯一手段;而在許可鏈中,負責核驗的節點后續可以協助用戶恢復密鑰.通過兩者的比較可以發現：許可鏈在準入機制的基礎上更容易支持密鑰對的恢復,更好地保障用戶的權益,同時還能更好地保護數據隱私.

1.2 響應式編程及實踐

傳統面向對象編程模型在應對高并發分布式系統時存在局限性.例如多個線程調用同一個方法時,需要用分布式鎖保證共享變量的一致性,但加鎖嚴重限制并發、多臺機器通信的網絡延遲過高且容易導致死鎖.

Actor模型[21]是響應式編程[22]的一種實現,在Actor系統中,每個實體都是一個響應消息的Actor,Actor的內部狀態是私有的,以消息驅動代替傳統的方法調用完成交互.經過驗證,采用Akka Actor模型的scala語言顯著降低了通信延遲,且在維持分布式系統中的休眠進程時表現最佳[23].

RepChain的實現采用了Actor模型[24],表現出良好的容錯性/韌性;同時,易于對系統的瓶頸環節進行算力調整.例如,在RepChain的性能優化過程中發現,請求背書環節存在比較嚴重的阻塞(耗時約120ms),拖累了整個系統的每秒交易數(transactions per second,簡稱TPS).因此,決定將背書請求的處理從原來的單Actor實例串行改為多Actor實例并行：將負責背書請求的模塊調整為負責調度的Actor和負責背書處理的子Actor;同時保持對外服務的背書請求消息格式不變,子Actor對背書請求消息的處理邏輯不變.改進后背書處理耗時降低了40ms,系統的TPS指標提高了60,改動的代碼數不到300行[25].而同類系統采用Kubernetes等工具在容器級別進行算力調度,難以實現類似的模塊/子模塊級別的細粒度算力調整.

2 系統結構

參考工信部白皮書的分層模型[2],RepChain針對企業級應用場景去掉了激勵層,增加了 API層和監控層.RepChain系統共分為 6層,從底層到上層分別是數據層、網絡層、共識層、合約層、API層、監控層,如圖 3所示.

(1) 數據層：負責數據格式定義,數據結構采用Protocol Buffers定義文件,并以此為基礎實現數據的交換、驗證、存儲、讀取及檢索;

(2) 網絡層：采用JDK內置的TLS實現,支持入網許可驗證,在此基礎上進行去中心化的gossip組網,網絡傳播支持P2P和Pub/Sub兩種方式;

(3) 共識層：完成區塊的輸入共識和輸出共識.采用兼顧實時性和安全性的CFRD算法,既照顧到交易的實時性要求,又能在一定程度防止節點串通作弊;輸入共識對入塊的交易順序達成一致,輸出共識對交易順序執行的結果達成一致;

(4) 合約層：為合約執行提供上下文環境,支持合約的動態部署、運行時加載和編譯執行;

(5) API層：提供外部接口,允許第三方應用以Restful的形式與系統交互,并允許開發者通過 Swagger UI進行在線測試.API層提供交易簽名提交、區塊和交易檢索等基本功能;

(6) 監控層：在區塊鏈網絡中收集事件/日志,并將其以Protocol Buffers的格式推送至Web端,以H5圖形技術進行實時狀態的可視化展示和日志回放.

RepChain采用輕量化和標準化設計,相比重新開發的非標準實現更穩定和易于升級(例如組網信道從TLS1.2升級到TLS1.3).在目前已開源的功能完整的許可鏈基礎組件中,RepChain代碼體量遠小于同類實現,全部代碼僅有11 000行左右,更適合在工程實踐中根據業務場景進行定制修改.

3 模塊設計

RepChain模塊化設計具備高內聚低耦合的特點,每個組網節點對應一個ActorSystem,主要功能模塊均封裝為Actor,包括API服務、合約執行、共識策略、事件訂閱,如圖4所示.去掉一個Actor不會影響其他Actor之間的消息交互,也不會產生編譯依賴的問題,便于進行系統調整.

(1) 合約執行

合約的安全隔離與執行性能是困擾開發者的普遍問題,為了避免非信任合約執行時對節點主機造成資源(CPU、內存、存儲)過度占用,通常都會對合約的執行采取進程隔離措施.但是由于合約執行仍然依賴節點主進程維護的WorldState,因此不得不付出跨進程通信的性能代價.

RepChain采用的Actor模型具備位置透明性,因此能夠實現在合約執行時,按照合約的受信任程度,決定在節點進程內加載執行,還是獨立的 JVM 進程執行,抑或在遠程主機執行.根據合約信任程度的不同,采用不同的合約部署策略,從而合理解決了合約的安全隔離與執行性能之間存在的沖突.

另外,根據具體場景,Actor模型能夠對合約的執行方式進行調度：首先,執行請求被發送到根路由 Actor,根路由 Actor將根據合約機制,決定哪些合約需要串行執行,哪些合約能夠并發執行;然后,根路由Actor將串行執行請求發送給單例合約容器,將并發執行請求發送給下一子路由Actor,以便調度更多Actor參與并發執行.如圖5所示.

(2) 存儲

RepChain存儲模塊由文件存儲和LevelDB構成,文件用來存放區塊數據以及鏈信息,LevelDB存放區塊和交易的索引信息以及供合約讀寫的 WorldState信息.存儲模塊提供快照以及狀態回滾以支持交易預執行,對正式出塊的交易執行結果進行數據驗證之后持久化.

RepChain存儲結構設計如圖6所示,功能包括：

· 支持區塊的讀寫,對區塊信息及交易信息的索引和檢索;

· 支持在WorldState快照之上的讀寫以及交易預執行的狀態回滾;

· 支持對WorldState進行Merkle計算.

在文件系統API之上,采用分段存儲技術,避免單個大文件導致區塊鏈數據的寫入/讀入性能下降;并且為了實現區塊數據的快速檢索,在LevelDB中建立對區塊數據的內容索引,以支持高性能的檢索.

(3) 通信

通信模塊建立在 Akka Cluster之上,組網節點之間以及節點與 Web端之間消息的序列化均采用 Protocol Buffers(簡稱 Protobuf)協議.

Akka Cluster采用去中心化的gossip協議組網,它具備以下功能.

· 節點之間采用TLS1.2作為安全通信信道;

· 通過訂閱系統事件,每個節點可以維持一張全網在線節點視圖;

· 支持節點之間采用發布/訂閱方式通信;

· 支持節點之間采用P2P方式通信.

(4) 共識

引入合約機制之后,不僅需要對打包入塊的交易及其順序進行輸入共識,還需要對順序執行交易對“賬本”產生的影響進行輸出共識.如圖7所示.

完成數據同步是參與共識的前提,只有數據達到最新區塊高度的節點才有能力參與共識.RepChain共識采用CFRD算法,各節點在無須協商的前提下,采用全網一致的偽隨機種子抽簽決定出塊節點順位序列.在每個時間段,只有唯一的一個節點擁有全網認可的出塊資格.如果當前出塊節點不能正常出塊,隨著時間的推移,出塊權將順位給下一個出塊節點.

RepChain采用兩階段共識：第1階段出塊節點負責將收集到并通過簽名驗證的交易按順序打包入塊,附上預執行獲得的輸出結果之后,簽名形成預出塊,然后向參與共識的節點發送預出塊并請求背書;第2階段出塊節點收集到足夠的背書之后,將背書附加到預出塊形成正式出塊,向全網廣播.兩階段機制能夠避免惡意節點的非法出塊.

(5) 事件訂閱與推送

RepChain事件模塊通過Akka Cluster的Sub/Pub,以Event Topic廣播到提供事件服務的Event Actor.Event Actor訂閱Event Topic并接收事件消息,通過EventServer將消息序列化為Protocal Buffers字節流并推送到瀏覽器,瀏覽器通過WebSocket Client接收到推送的字節流后將其反序列化為Event對象,然后調用可視化模塊進行實時狀態展示.主要過程如圖8所示.

(6) 可視化

可視化模塊將從系統中收集的實時狀態,以圖形化的方式呈現給用戶.

RepChain提供的實時狀態圖如圖9所示：左邊是圖形區;右上部分是塊堆棧區,顯示不斷生成的區塊以及包含的交易內容;右下部分是日志區,以文本方式滾動顯示接收到的事件.圖形區圓周代表組網,圓周上的小圓代表當前參與組網的節點.小圓的不同顏色代表節點處于不同狀態：亮綠色代表出塊節點,深綠色代表背書節點,藍色代表當前未完成數據同步的節點.

圖形區有以下幾個Topic.

1) RepChain：組網節點的個數;

2) Transaction：節點間發生交易請求;

3) Endorsement：節點需要背書;

4) Block：交易達成出塊;

5) Sync：當新加入的節點與已有節點區塊高度不一致時,發出數據同步請求.

組網節點與Topic之間的連線代表消息通信,其中,紅線代表發送Topic消息,綠線代表從訂閱的Topic接收到消息.實時圖能夠直觀展示節點入網與離網、數據同步、交易提交與傳播、出塊節點選舉、候選塊背書、正式出塊的完整過程.

4 RepChain性能評估

Pongnumkul[26]完成了以太坊(版本 geth 1.5.8)在局域網上的性能測試實驗.作為對比,本文在局域網上設計了RepChain(版本improved_tps_20181026)的性能測試實驗[24],實驗結果見表1.

Table 1 Contract of experimental result表1 實驗結果對比

實驗結果顯示：交易量從100～1 000時,以太坊的交易通量下降、時延顯著增加,RepChain的交易通量上升、時延有所增加;在上述實驗條件下,RepChain的交易通量均高于以太坊,時延均低于以太坊,且隨著交易量的增大優勢更加明顯.

實驗結果表明,CFRD協同性共識算法比公有鏈的競爭性共識算法在交易通量 TPS和時延方面有較大改善,從而提升了響應式許可鏈的整體性能.

另外,本文在 30個節點組網的環境下,采用手動終止節點進程的方式模擬個別節點的機器故障,系統都能夠在90s內重新同步全網節點狀態并繼續正確運轉.實驗結果表明：在分布式環境下,RepChain具備良好的容錯性/韌性.因為Actor模型的消息驅動只確保消息達到的順序,不確保消息一定送達,所以程序邏輯不能假設發出的消息一定收到預期的回應.在這種編程約束下,系統能夠應對分布式環境下的各類異常.

5 總結與展望

區塊鏈通過忠實完整地記錄行為主體的授權行為,在參與者之間共享可驗證、防篡改、可追溯授權的記錄以建立信任.傳統應用中的數據存在著被非法篡改的風險,而區塊鏈應用通過對交易簽名,保證了只有行為主體可以增加數據;通過對鏈式區塊的簽名,保證了已生成數據的固定(即不可刪除或修改),因而在行為主體之間建立起了基于可信數據的信任.當前,區塊鏈以公有鏈方式實現的數字資產應用引人矚目,但在企業場景的應用探索才剛剛起步.

RepChain以企業應用為目標場景,提供了國內第一款響應式、輕量級的許可鏈基礎組件,優化了交易的實時性和交易通量.考慮到應用場景的多樣性,RepChain專注于基礎功能,并且盡量保持模塊之間的松耦合,以方便在具體實施中進行調整.

目前,RepChain已經應用到存證溯源、供應鏈升級、消費積分等領域.基于RepChain的服裝供應鏈實現了各參與方的權益保障,進一步地各參與方通過可信及時的銷售數據反饋,能夠有效提高其市場應變能力.RepChain為傳統集中化的電子證據存證服務注入防篡改和可追溯的特性,使其存證要素可被驗證,從而保護了電子證據的完整性,并奠定了其可采用性的基礎.

我們希望對RepChain的開源能夠賦予它更多的實踐機會,在歷練中不斷改進,在實體經濟加區塊鏈的創新發展中發揮應有的作用.