在區塊鏈中因為共識節點之間需要統一 Commit 階段的投票,所以最後的 Commit 階段略為不同:Leader 節點收到 2*f+1 的 Commit 包之後會將最終的 Commit 包廣播給其他共識節點來統一投票。
在整個共識流程中,交易在 Pre-prepare 階段執行一次,在 Prepare 階段驗證一次,FISCO BCOS 中使用的傳統 PBFT 流程為先執行再驗證的模式,包含了兩個執行交易的時間長度。
CITA 採用自主研發的共識協議
CITA 實現了根據區塊鏈連續共識特點而最佳化的 CITA-BFT。區塊鏈是一個連續共識的過程,CITA 將交易的執行和共識進行拆分,避免了兩次執行的問題。根據複製狀態機的原理:起始狀態一致,執行交易順序一致,執行過程是確定的,三個條件都滿足的情況下就可以保證最終結果一定會一致。在區塊鏈中起始狀態由創世塊來保證一致,虛擬機器是完全確定的,所以只要保證交易順序一致就可以保證其最終結果一定一致。在區塊鏈中 Block 的 preHash 已經包含了上個塊交易處理之後的世界狀態資訊。CITA-BFT 對當前區塊的交易順序和上個區塊的執行結果進行共識。這樣在共識過程中不需要去執行交易,而只需要在共識完之後進行一次交易處理,大大提高了整個鏈的吞吐量。CITA-BFT 是針對區塊鏈連續共識的特點進行了最佳化,採用了先共識後處理的方式,使得共識的過程不必執行交易,只需要共識完成之後執行一次交易即可。經過驗證,在最簡單的存證交易時,共識效能有 35% 左右提升。
CITA-BFT 避免了共識協議最後一輪 Leader 廣播的過程。在傳統的 PBFT 中在最後的 Commit階段,需要 Leader 收到足夠的 Commit 包並廣播給其他節點。區塊鏈是一個連續共識的過程,在 CITA-BFT 中,Block 中共識投票是上一個區塊的投票,所以合併了 Commit 階段的 Leader 廣播最終區塊過程和下一個高度的 Proposal 階段,這樣節省了一輪廣播過程,透過下一個高度Proposal 的過程統一了 Commit 投票資訊。
CITA-BFT 採用Proposal 預處理技術使共識和執行能夠並行進行,提高了系統效能。由於聯盟鏈在多數情況下,網路狀況良好能在一輪共識流程中完成共識,CITA 中引入了 Proposal預處理的技術:在 Pre-prepare 階段,節點在收到 Proposal 之後可以直接處理交易,而不必等到共識流程完成,等到共識流程完成之後再將共識結果通知交易處理器。在傳統的 PBFT 的過程中,交易處理和共識是序列的,引入 Proposal 預處理之後,可以使得共識的 Prepare 階段 Commit 階段和交易處理並行進行,大大提高了整個系統的吞吐量。經測試,對於簡單的交易處理,有 10% 到 20% 左右的效能提升。
在 CITA 中採用了 CompactBlock 的技術來壓縮共識區塊的大小,提高網路頻寬利用率。Block中的交易已經單獨廣播過一次,所以共識 Block 中只需要包含交易 ID 即可,這樣可以大大降低區塊訊息的大小。經測試在網路條件較好的情況下,對於簡單的交易處理,有 5% 到 10% 的效能提升。
Fabric 共識機制限制業務效率提升
Fabric 將其節點角色分為:排序節點,背書節點,提交節點。客戶端首先將交易請求傳送給背書節點,背書節點執行後將 read/write set 及其簽名返回給客戶端,客戶端收集到足夠相同的結果後,將 read/writeset、多組簽名和交易請求組成簽名後的交易,傳送給排序節點,排序節點組成區塊之後,廣播給提交節點,提交節點驗證 read/write set 和簽名數是否滿足,標記結果並儲存合法的結果到各自的賬本。
在 Fabric 中由於交易的執行是非確定性的,這點不同於 FISCO BCOS 和 CITA 的設計理念。所以需要背書節點先執行交易,並由客戶端根據背書策略進行對比結果,再發給排序節點,最終由提交節點驗證並更新各自的資料庫。可以理解為:共識狀態的過程是由客戶端、背書節點、提交節點共同參與完成的;排序節點只負責交易順序的共識,而不負責狀態共識。在交易狀態共識和排序可以分別採用不同的策略。比如交易狀態可以採用超過 3/4 的狀態一致,而排序節點的共識使用傳統的 Raft 或者 Solo 共識,採用傳統 CFT 共識即可滿足多數場景。這裡的問題是交易中需要包含使用者的簽名,以及多個背書節點的簽名,以及 read/write set,這樣導致交易非常大。
Fabric 在交易狀態有衝突時,例如 A 和 B 之間頻繁轉帳這種場景,因為每筆交易都會修改 AB 賬戶的餘額,所以會造成交易衝突。衝突交易每個塊最多隻能有一個交易被處理,這將大大限制業務合約的場景。
效能對比
CITA共識效能好
FISCO BCOS:
· 傳統的 PBFT
· 共識過程中會重複執行交易,共識效率一般
CITA:
· 先共識再執行,只執行一次交易,整體效率較高
· 最佳化 Commit 階段的 Leader 廣播過程,減少共識時間
· Proposal 預執行技術使得共識和執行並行,提高整體效能
· CompactBlock 技術提高頻寬利用率
Fabric:
· 執行(驗證)和排序可以採用不同的共識策略,比較靈活
· 交易需要多個背書節點簽名和 read/write 集合會導致交易非常大
對比可以看出 FISCO BCOS 採用傳統 PBFT,共識效率一般;CITA 採用了自主研發的 CITA-BFT,共識和交易處理有 50% 以上的效能提升;Fabric 將整個流程拆分為執行、排序、驗證,增加了靈活性,但是驗證和執行的分離導致交易非常大。
應用場景
Fabirc 共識機制限制了業務場景
FISCO BCOS/CITA:都是 BFT 類共識,適合多數的聯盟鏈場景,由參與方、監管方和可信第三方組成共識節點。
Fabric:將共識的流程拆分為執行,排序和驗證,具有更好的靈活性,但是由此帶來交易結構非常大,而且衝突交易每個塊只能上鍊一個交易,大大限制了業務合約的場景。比如對於一個統計投票的合約,有 N 個投票者,每個投票人員透過傳送交易進行投票,因為總的投票結果是共享狀態,這種情況下每個區塊只能處理一筆交易。比如對於 Randao 專案,需要收集參與者的所有提交資訊,這個時候就需要一個集合變數來儲存這些資訊,由於每個參與者的交易都會修改這個集合變數,導致每個塊只能處理一筆提交交易,並且集合變數會導致 read/write set 會非常大。
擴充套件性
安全性
可以看到,BCOS和CITA都使用類BFT的共識,所以在安全性方面分析現有的BFT協議即可,有用比較高的安全邊界。
對於Fabric,由於執行、排序、提交節點職能的分離,且執行(驗證)和排序可以分別採用不同的共識策略,安全策略可以由使用者自由把握,客戶端參與狀態和執行的共識。
3. 智慧合約
智慧合約一詞有一定的誤導性,智慧往往給人帶來一定的神秘色彩,就其合約功能本身來講並無”智慧性”。在區塊鏈出現之前,所有的系統都是採用中心化的架構,監管機構和使用者無法驗證和保證系統功能的正確性,無法確保資料未被惡意修改,無法保證資料的安全性。由於區塊鏈的出現,使得在不依賴於第三方的情況下,能夠可信地進行交易,而且交易可追蹤無法逆轉。智慧合約的核心含義在於:在區塊鏈基礎上實現可信計算,並由區塊鏈協議保證的可追蹤和無法逆轉。
在比特幣中交易主要用於點對點的現金支付,以太坊由於引入圖靈完備的智慧合約被稱為區塊鏈2.0。雖然理論上以太坊上的智慧合約是圖靈完備的,但是受限於交易手續費、合約指令、區塊Gas上限、節點可信度等,公鏈智慧合約並不適用於現有的企業開發。
聯盟鏈由於節點數量有限,且節點運營方可以採用高效能的硬體裝置,以及底層協議支援等,更適合企業開發。首先本文介紹三者智慧合約的技術實現,再分別從安全性、易用性、可用性三方面進行對比分析。
技術實現
BCOS和CITA均支援EVM和預編譯合約。藉助於Ethereum 智慧合約的完善的生態系統,兩者都在其基礎之上做了定製化,有豐富的合約編寫和測試工具。
對於預編譯合約需要開發者對區塊鏈系統有一定的瞭解,需要較高的門檻。當前支援EVM的語言主要是Solidity,Solidity合約可以透過交易進行部署,在呼叫時將合約程式碼載入到虛擬機器中。
Fabric的合約透過ChainCode的方式以Docker的方式進行線下安裝,然後透過交易進行啟用。ChainCode合約的部署相對較重,但支援多種語言(Go,Javascript等),合約的部署和更新以線下方式進行更新,合約程式碼並沒有進行共識,可以將合約看成黑盒,只需要保證其輸入和輸出正確即可,並不關心其內部邏輯的具體實現。
由於Fabric採用了傳統的語言進行合約編寫,雖然開發者不需要學習新的語言,但是由於虛擬機器的不確定性,ChainCode的方式只適合Fabric的先執行再共識再驗證的共識方式,並不具備通用性。
安全性
安全性是智慧合約有別於其他程式的主要特徵,這裡的安全性,包含確定性、可驗證、可審計、可追蹤等特性。
由於BCOS和CITA在智慧合約設計理念上接近,本文將兩者放入同一欄中。
對比可以看出由於BCOS/CITA交易是鏈上執行的,所以BCOS/CITA的智慧合約更具有確定性、可驗證、可審計、不可逆、可追蹤的特點。
Fabric在合約程式碼由背書節點各自部署和升級,驗證性、審計性、可追蹤性無法保證。但是由於在Fabric的設計理念中,合約執行後再由客戶端進行驗證,本文可以認為合約最終的結果是由客戶端和背書節點共同決定的,只要交易結果符合背書策略並且符合使用者預期,對於合約程式碼的驗證性要求相對就沒有那麼重要了。
易用性
BCOS/CITA在合約易用性上略勝於Fabric
BCOS/CITA支援以太坊EVM並且對其工具鏈進行深度最佳化,對開發者更友好,合約的部署、呼叫、升級都透過交易進行,更輕量和方便。
可用性
BCOS/CITA/Fabric都可以應對企業複雜的業務邏輯,支援比較複雜的合約計算和處理,同時CITA支援鏈上定時任務。
4. 效能
經過區塊鏈底層技術最近幾年的發展,聯盟鏈的效能已經不再是其最主要的瓶頸。
BCOS官方文件並未提供效能資料,本文只能根據第三方提供的資料來判斷,我們找到了兩個相對可靠的資訊來源。中國信通院可信區塊鏈最新評測(2019年11-19日),BCOS單鏈TPS超2萬。[在2019年7月底的一篇新聞稿”](undefined)當測試團隊說區塊鏈效能達到10000TPS的那一刻,張開翔在微信群裡給團隊發出了人生中最大的紅包。“。因為兩次測試資料均未提供測試用的環境、節點數、使用的共識協議(BCOS支援Raft)等,推測這裡可能是分別使用了不同的共識方法和節點數進行的測試。
CITA在官方文件中最新版本的交易效能已經可以達到 15,000+ TPS,資料來自 CITA 0.16 版本(2018年5月15日),在四臺 32 核,64G 的雲伺服器上部署 4個節點,每臺伺服器配置百兆頻寬。
Fabric官方並未提供其效能資料。根據第三方提供的資料([https://arxiv.org/pdf/1801.10228.pdf](https://arxiv.org/pdf/1801.10228.pdf)),在32核CPU,10節點的情況下,效能可以到3400左右。根據這份報告背書節點數對效能影響並不大,因為背書節點並不實際參與共識。
現階段聯盟的效能已經有了長足的進步,相對落地場景而言,效能已經不再是最主要的瓶頸。同時國產聯盟鏈在效能方面已經不輸於國外的大品牌,甚至已經領先於國外。
5. 儲存
區塊鏈的儲存從內容方面講主要包括兩個方面:區塊和交易儲存、世界狀態儲存。本文先分別介紹各自的實現方式,再從支援資料庫型別、儲存效率、可擴充套件性、資料維護等方面進行對比分析。
實現方式
BCOS的狀態儲存支援兩種儲存模式
對於區塊的儲存,BCOS交易列表,交易回執等都採用了傳統的MPT方式儲存。對於世界狀態,BCOS採用了兩種儲存模式:storage state和MPT state。MPT state支援RocksDB和External儲存,MPT儲存在儲存歷史狀態的同時,最大化減少儲存資料。Storage State 支援RocksDB、MySQL、External,使用storage state儲存時,犧牲了部分的可追溯性,但帶來了效能上的提升,同時能支援SQL語句的查詢和統計。因為世界狀態始終是可以透過交易進行還原,所以對於犧牲部分可追溯性而換取效能的提升和狀態查詢是可以接受的。
CITA支援RocksDB、External儲存。使用MPT儲存狀態,使用Simple Merkle Tree儲存交易和交易回執。對於狀態儲存CITA選擇了經典的MPT儲存,儲存歷史狀態的同時,最大化減少儲存資料。而對於交易和交易回執使用Simple Merkle Tree儲存,可以最佳化儲存資料量和減少Hash計算。
Fabric的區塊儲存,同樣採用了MPT的方式進行儲存。對於世界狀態的儲存支援KV和CouchDB儲存,在世界狀態儲存時,Fabric不支援歷史狀態的儲存,同時有效能上的提升,並支援豐富的條件查詢和統計。
對比分析
對比來看:
CITA在交易的儲存結構上做了最佳化和改進,提供了快照功能對世界狀態的歷史進行裁剪。BCOS世界狀態的儲存模式上,支援兩種不同的模式,允許在犧牲一部分狀態可追溯性上,提升效能和支援豐富的SQL查詢。
Fabric的世界狀態儲存不保留歷史狀態,支援世界狀態的條件查詢。
本文認為在交易儲存方面,節點必須要保留歷史記錄,而對於世界狀態的歷史儲存,可以透過交易進行還原,在這種情況下BCOS/Fabric為使用者提供較好的查詢功能和較高的效能是一個不錯的取捨。
6. 治理
聯盟鏈不同於公鏈的最大不同之處在於其治理方式的不同,對於公鏈來講由於其是開放的系統需要一定的經濟激勵來協調不同角色間的關係,而聯盟鏈由於節點是准入機制,所以其治理方式與公鏈有非常大的不同。對於聯盟鏈來講,其治理主要包含:節點管理、帳號許可權、經濟模型。
節點管理
對於BCOS和CITA來講,節點主要分為兩類:共識節點和普通節點。共識節點負責共識出塊,普通節點只能同步資料並驗證資料而沒有打包交易的權力。
對於Fabric,節點分為背書節點,排序節點,提交節點。背書節點負責執行交易並返回結果,排序節點負責對交易排序並打包出塊,提交節點負責驗證交易並更新狀態。
對於共識節點BCOS/CITA均採用了系統合約的方式進行管理,節點的增刪需要共識節點進行共識。而Fabric的節點增刪,可以由節點管理員修改配置,無需共識,但是啟用新的配置檔案需要傳送交易並進行共識。
本文認為透過白名單/黑名單的方式或者CA的方式管理節點身份,均能滿足聯盟鏈的大多數場景,CA在對節點身份的驗證方面更加嚴格。
使用者許可權管理
對於聯盟鏈來將,聯盟各個角色以及聯盟內均需要比較複雜的許可權管理,這樣不同的角色只能訪問屬於自己授權的資源。
在CITA/BCOS中都透過複雜的許可權管理,來對使用者的交易許可權進行管理,包括髮送交易,建立合約,合約方法呼叫許可權等等。
Fabric透過配置檔案的方式(Policy)的方式進行管理使用者的許可權。
BCOS/CITA許可權管理透過交易的方式進行管理,比Fabric透過配置檔案的方式修改,更加區塊鏈化,治理操作會保留痕跡。
經濟模型
CITA支援兩種不同的經濟模型
在公鏈中,礦工打包使用者的交易往往需要使用者支付一定的手續費;對於聯盟鏈來講,情況有所不同。
BCOS、CITA和Fabric均支援向使用者提供免費服務的模式,同時在BCOS/CITA中會透過系統合約控制使用者單個區塊內對系統資源的使用情況,防止對系統濫用。
而CITA又可以支援收費模式,節點對使用者交易精確計費並收取Token手續費。而Token即可以是節點免費分配給使用者,也可以需要使用者有償使用,這樣可以更加精細地控制使用者對系統資源的使用情況。
7. 跨鏈和隱私
跨鏈和隱私方案,距離生產環境依然有可最佳化空間
BCOS引入了群組的方式,使一個節點可以屬於不同群組,而群組的訊息、交易、儲存、執行等等完全隔離。
Fabric 的群組概念和BCOS類似,一個節點可以屬於不同群組,不同群組可以使用不同的背書策略。
在BCOS和Fabric中,群組的資料和通訊等都是隔離的,並且可以使用不同的共識策略,所以可以將其看成多鏈。當前對於多鏈最大的問題在於鏈間通訊,兩者在這方面均沒有非常成熟方案。
在CITA中,引入了側鏈技術,側鏈和主鏈之間可以互相通訊,側鏈技術距離生產環境依然有可最佳化的空間。
無論群組或者側鏈等技術,本質上都是一種多鏈技術,當前多鏈技術只能解決節點的隱私問題,暫時無法處理交易和使用者級別的隱私。
CITA已經開源其零知識證明和SGX的實現。
對於同態加密、零知識證明,SGX等等,都處於發展階段,距離生產環境依然有可最佳化的空間。
8. 密碼學支援
CITA在密碼學支援上更全面
對比可以看到BCOS/CITA均支援國密,對國內監管需求較友好;在密碼學演算法支援上CITA更全面,除了支援常見的Keccak/Secp256k1之外,也支援更安全效能更好的Keccak/Secp256k1。
9. 系統架構
CITA採用了微服務架構
BCOS和Fabric均採用了單一系統的架構,這種架構要求節點必須在單一的物理機器上。
而CITA採用了微服務架構,而且CITA也是全球第一個使用微服務架構的開源區塊鏈。採用微服務架構,可以使節點不僅僅限制在單個物理機器上,這樣對於企業使用者可以用更好的硬體裝置去支援節點,有更好的擴充套件性。由於微服務間透過訊息訂閱進行通訊,企業使用者可以方便地替換或者增加定製化的服務,方便進行功能擴充套件。
10. 開源協議
BCOS的開源協議對商業應用不夠友好
這裡簡單介紹下相關的開源協議。
GPL協議的主要內容是隻要在一個軟體中使用(”使用”指類庫引用,修改後的程式碼或者衍生程式碼)GPL 協議的產品,則該軟體產品必須也採用GPL協議,既必須也是開源和免費。這就是所謂的”傳染性”。由於GPL嚴格要求使用了GPL類庫的軟體產品必須使用GPL協議,對於使用GPL協議的開原始碼,商業軟體或者對程式碼有保密要求的部門就不適合整合/採用作為類庫和二次開發的基礎。
Apache Licence也是對商業應用友好的許可。使用者也可以在需要的時候修改程式碼來滿足需要並作為開源或商業產品釋出/銷售。
由此可以看出,BCOS的開源協議對商業應用不夠友好。
11. 語言實現
CITA使用更現代的語言Rust,效能更高同時安全性更可靠
BCOS:使用C++進行開發,C++效能高,但是由於其歷史原因,系統容易有記憶體安全的隱患;
Fabirc:Go實現,由於垃圾回收機制效能比C++弱;
CITA:Rust實現,現在相對主流的區塊鏈界的語言,Rust在記憶體安全方面有保證,效能可以和C++媲美。
12. 總結
經過以上的分析,本文彙總其最主要的優缺點: