區塊鏈與現實①｜資料延遲怎麼辦？吞吐量怎麼擴大？

前語

制約區塊鏈投入大規模應用的瓶頸很多，很難在一篇文章裡完全介紹，所以我們做了一個系列四篇文章來逐個探討。這個系列分為四篇，分別從資料同步的吞吐量，跨中心的控制管理機制，多參與方的安全隱私交易，以及殺手級應用的實踐與特點幾個方面來解析。我們首先來談談區塊鏈資料同步及吞吐量方面的難點及發展。

公有鏈和聯盟鏈的區別

簡單來說，區塊鏈是一種分散式資料庫，其特殊之處在於無（弱）中心化。從面向人群來分類，區塊鏈可分為公有鏈和聯盟鏈（或私有鏈）兩大類。公有鏈面向所有參與者開放，所有人都可以參與；聯盟鏈，通常認為與私有鏈類似，面向特定的組織團體或者單獨的個人或實體開放。公有鏈和聯盟鏈在實現上有很多不同，其中最顯著的不同點就是共識機制的差異。

公有鏈共識機制的制約

區塊鏈網路上的多個參與方，在每次更新鏈上資料時（例如轉賬）必須要獲得一定數量的參與方認可才可以進行，這個認可過程就是共識機制。該機制的主要目標是在參與方控制多個節點的情況下，杜絕多個參與方聯合造假的可能性。

目前，以比特幣、以太坊為代表的公有鏈，其共識機制並不適合商業場景使用，主要有三個原因。第一是效能遠低於商用需求，以金融系統為例，延遲1秒已經難以適用於多數場景。 而延遲1秒會帶來什麼？除了降低使用者體驗以外和熱點賬戶使用率外，第三方也會獲得充足時間透過高頻交易策略給交易人帶來損失，但最為恐怖的是， 這區區幾秒的延遲可能會破壞整個體系個個子系統對交易”超時“的定義從而導致生產系統故障。因此目前耗時數秒，甚至數分鐘的共識機制基本無法列入候選；第二是弱最終一致性，會導致參與方無法在固定時間內100%確定交易的成功與否，例如公有鏈上的一個現象是，一筆最初顯示成功的交易有可能在幾個小時後判定為失敗，這在現實金融業場景中是無法接受的，因為這種特性同樣可能帶來金錢上的損失；第三是安全性，公有鏈的安全機制一般是靠參與者算力或者代幣持有量來維持的，對資金額巨大的金融機構或者國家機關來說，是完全有能力建立或直接控制大部分資源，進而徹底破壞整個區塊鏈網路。因此僅僅透過算力或代幣規模進行利益繫結保證的安全機制是難以承擔關係到金融體系的大格局網路的。

聯盟鏈共識機制及瓶頸

為了解決公有鏈共識機制的問題，業內引入了聯盟鏈。在聯盟鏈場景中，共識機制裡防止造假節點的問題通常稱為拜占庭將軍問題；能夠防止惡意造假節點的演算法，也被統稱為拜占庭將軍演算法（BFT）。用通俗的話講，共識機制就是讓參與方來一起投票來決定是否接受一筆交易。其中較有代表性的是PBFT演算法（PBFT誕生於1999年，因為區塊鏈的推動終於在沉睡十幾年後獲得長足發展的可能）。這些年中PBFT演算法的衍生品能叫得出來名字的也有不下20種。基於PBFT的聯盟鏈共識機制，雖然在理論上大大減輕了公有鏈問題的嚴重性，但其自身的一些劣勢也長期限制了它們的發展。理想的商用共識機制必須是完整、穩定的，並且能夠應對所有可能發生的異常。什麼是異常？簡單說就是如果你去銀行轉賬，但銀行系統由於之前被駭客攻擊或者網路堵塞等各種原因不能工作了。而xBFT系列演算法的最大問題，正是由於需要處理各種異常而引入的複雜性。以2003年發表的第二版完整版本PBFT演算法論文為例，文中只有一小部分論述演算法的正常流程，絕大部分內容都在探討各種可能出現的異常情況以及處理方案。目前國際上一般認為可用性最高的超級賬本Fabric 0。6 版本中的PBFT實現，也只實現了PBFT的基本功能，在“正常環境”下可以工作，離真正完整、穩定、可商用的目標還尚需時日。至於後面的S（P）BFT，目前也還是在前期開發中。

除了以上問題，xBFT系類演算法的另一個通病是多節點資料執行的確定性，節點分佈在各個不同的地點，但是要求它們對同樣指令的計算結果必須是一致的。雖然機率很低，但同樣指令在不同環境不同物理機下執行結果不一致的情況也確實發生過。不解決這個問題，就無法應用在一些相對嚴苛的系統環境裡，如金融類系統。解決這個問題需要對預計算的結果進行背書，雖然PBFT演算法設計之初這類問題就被提及，遺憾的是目前各種xBFT實現中極少考慮到這個問題。

除此之外，xBFT演算法下如何動態增加節點也是一個多故障點的複雜工程，雖然已經有一些這方面的嘗試（如BFT-SMaRt，已經開發5年 ），但是由於高複雜性目前還很難保障最基本的穩定執行，離商用需求的穩定性需求和各種異常處理機制的完善也還相差甚遠。對這些問題的深入理解，也是平安壹賬通在設計FiMAX產品時在共識機制的選擇及開發上，儘量採用成熟度可商用且容易被接受的機制。

擴大吞吐量的嘗試

在公有鏈上，擴大吞吐量近年來一直有很多嘗試。使用的策略大多分為兩類，第一類是鏈下清結算模式，在必要的時候才將交易寫到鏈上，這類以閃電網路為代表；另一類是多鏈分片模式。

前者（鏈下清結算模式）雖然概念新穎，涉及點除了技術層面，還新增加了鏈下商業角色，對商業模式也有創新。該模式在公有鏈網路上才剛剛開始測試，並且功能上單一，短時間內還無法適用在需求繁瑣的商業場景中。相比前者，後者（分鏈模式）雖然現在有了很多變種（如DAG）但難點則都主要集中在技術層面，由於分散式儲存特性的限制，為換取更大的吞吐量往往要犧牲部分資料一致性，勢必會為保證準確性而增加交易延遲，甚至是長時間不確定延遲。對於最終一致性問題本身已經不盡人意的區塊鏈系統來說，分鏈分片的引入也許在公鏈環境能被接受，但在現實金融關鍵任務系統中的運用上不現實。

跨鏈的問題

近年來各種區塊鏈和代幣越來越多，代幣之間的交易也隨之增長，一個逐漸變為熱點的話題就是“跨鏈”交易。從分散式資料庫領域來看，跨鏈並不是一個新話題，如何實現兩個不同資料庫之間的更新同步，在該領域已經被探討和實踐了幾十年。其中最重要的問題就是，如何保證兩個或多個數據庫上的資訊更新是同時成功或者同時失敗的，對區塊鏈而言，就是不同區塊鏈網路上的同一筆交易，要被兩個網路同時認定為成功或失敗，不能一邊認定成功，另一邊認定失敗。舉個例子，如果一個客戶用現金購買股票，當現金轉出的同時股票必須同時轉給這個客戶，不能出現款扣了但股票轉讓失敗，或者股票成功轉給了客戶但沒有扣款。目前，業內提出來的“跨鏈”技術雖然多種多樣，但其原理都是分散式資料庫理論中“二階段提交”方法的變種。相比傳統的二階段提交，更為複雜的是，區塊鏈的最終一致性導致“跨鏈”時的交易失敗率提高。尤其在二階段提交中對“超時”的定義和判斷上，這個原本制約二階段提交廣泛應用的問題，會讓區塊鏈交易延遲不可控的問題進一步惡化。

因此，我們在設計FiMAX產品中秉承的理念是，突破吞吐量的限制必須，也只能，從單鏈開始，多鏈、跨鏈等機制都要儘量避免，不到迫不得已不要輕易使用。目前，FiMAX網路上每個節點只需要2。1Ghz 8核CPU、無跨鏈、無分鏈分片的情況下，支援每秒5000+筆的交易吞吐量，並能夠透過簡單方便的硬體升級迅速成倍提高單鏈吞吐量到數萬級別，綜合性能與傳統資料庫已很接近，已具備支撐大規模商業應用的能力。

在跨鏈方面，FiMAX系列體系為客戶提供三套方案。因為由於網路延遲，演算法複雜等原因造成的一些無法避免問題， FiMAX的三套跨鏈方案的理念是讓客戶根據自身的需求在複雜度和效率上做出平衡選擇。

發展方向

雖然還在起步階段，但平安投產的區塊鏈應用已經超過14個，國際國內專利也發表了60份以上。以我們的實踐經驗來看，要想說服大型機構真正採用區塊鏈技術作為生產應用，而非僅僅是PoC實驗專案，首先最值得關注的就是資料同步的穩定性和一致性，因為只要涉及真實生產資料的場景就必須是穩定壓倒一切。 因為在關鍵任務系統中，任何“暫時”性的資料不一致或者理論上的“小機率”事件都會帶來災難性的後果。

（作者陸一帆系平安壹賬通壹賬鏈專案總監，FiMAX總架構師；褚鎮飛（平安壹賬通壹賬鏈技術副總監，FiMAX Core首席架構師）