聯盟鏈走向何方

聯盟鏈技術哪家強？開源架構Fabric、FISCO BCOS（如下簡稱「BCOS」）、CITA 技術對比。

出品：碳鏈價值研究院

01　摘要

第 46 屆世界經濟論壇達沃斯年會將區塊鏈與人工智能、自動駕駛等一併列入「第四次工業革命」。《經濟學人》曾在 2015 年 10 月的封面文章《信任的機器》中介紹區塊鏈——「比特幣背後的技術有可能改變經濟運行的方式」。

區塊鏈之因此被稱爲信任的機器源於其分佈式和不可篡改的兩個核心特性，這也是區塊鏈有別於傳統數據庫的核心特性。這裏的分佈式包含兩層含義：一是傳統的分佈式存儲，二是區塊鏈的底層協議帶來的協做性，這裏更多的是指代其分佈式協做的能力。

在區塊鏈中主要經過共識算法、智能合約、治理、跨鏈、隱私等來實現其「可信協做」，因此本文將從這幾個方面並結合企業應用場景來分析底層技術的差別，來幫助企業用戶更好地作出選擇。同時也會從傳統企業軟件的可維護性、性能、開發工具、擴展性、軟件協議等方面來進行分析和對比。

就聯盟鏈的歷史、以及和公鏈的區別來講，早期來看差別不大，可是如今隨着細分市場持續深化，公鏈和聯盟鏈之間的差異愈來愈明顯。

首先，公鏈面對的是一個不可控場景，須要在安全，性能和去中心化上找到一個平衡點。而在聯盟鏈企業服務場景中，參與方數量相對來講更加的可控，聯盟鏈在性能和安全性上更容易有突破。但也正是因爲參與方（節點）的可控，去中心化這個方面有本身更加獨特的設計。除此之外，在公鏈中，全部的信息都是公開透明能夠被查驗的，每個參與方相對來講比較平等。可是在工業界中，這是不可被接受的，有大量的公對公數據隱私須要處理，在企業中也存在多種組織模式須要設定權限。

基於這些特徵，聯盟鏈在發展上包括節點管理、共識選擇、權限控制和合約設計範式差別化多很大，同時不一樣的框架對於合約的設計範式理解也不盡相同。此外，區塊鏈有開源和閉源之分，可是區塊鏈創造的信任是基於開源代碼產生的，沒有開源就不是真正意義上的區塊鏈系統。所以爲了研究的客觀，本文主要集中討論開源框架。目前在國內市場使用較普遍的開源架構分別是 Fabric，FISCO BCOS 和 CITA。

Hyperledger Fabric 是分佈式帳本解決方案的平臺，該平臺以模塊化架構爲基礎，提供高度的機密性，靈活性和可擴展性。它旨在支持不一樣組件的可插拔實現，並適應整個經濟生態系統中存在的複雜性。Fabric 最先由 IBM 設計和開發，2015 年將其源代碼奉獻給了 Linux 基金會的Hyperledger 項目。

FISCO BCOS 誕生於 2017 年，由金鍊盟推出，是標準的國產底層。金鍊盟是由深圳市金融科技協會、深圳前海微衆銀行、深證通等二十餘家金融機構和科技企業於 2016 年 5 月 31 日共同發起成立的非營利性組織。

CITA 是一個開源的區塊鏈操做系統內核，以高穩定性，高性能，高可擴展性爲設計目標。CITA 開源項目由祕猿科技 Cryptape 於 2016 年發起。目前由溪塔科技等 CITAHub 社區企業共同維護。CITA 採用微服務架構設計，提供豐富的開發工具集，靈活的區塊鏈治理工具，開發者可爲不一樣類型的區塊鏈網絡進行二次開發或配置。

爲了區分區塊鏈不一樣的實現和設計思路，能夠首先來明確一下區塊鏈自己的定義。一般區塊鏈自己的定義是一個去中心化和分佈式帳本，同時也是一個記錄事件和交易的不可篡改帳本。在這個帳本中，不可篡改的特性是由共識算法保證的。由此看來，現有的聯盟鏈能夠分爲兩大類：以 Fabric 爲表明，在傳統數據庫主導的分佈式數據庫技術；以及更符合「區塊鏈精神」的 FISCO BCOS 和 CITA。

Fabric 特性：IBM Fabric 保證了區塊鏈中的分佈式和不可篡改性兩點，省略了去中心化的共識機制，IBM Fabric 在框架中並無真正的去中心化共識機制。在 Fabric 架構中，將參與方（節點）分紅了三種角色即：排序節點、背書節點和提交節點。對於每一筆交易：共識狀態的過程是由客戶端、背書節點、提交節點共同參與完成的；排序節點只負責交易順序的共識，而不負責狀態共識，在交易狀態共識和排序能夠分別採用不一樣的策略。排序節點中的共識方式是 Kafka 或者 Raft，這實際上和已有的分佈式數據庫共識方式是一致的，不具有容錯性。

IBM Fabric 若是做爲一個一體化的套件來知足帶有角色的分佈式數據庫業務，是功能很是全面的，但也正是節點的複雜性使得應用部署較重，對於環境要求較高。除此以外，因爲共識算法採用的是 Kafka 和 Raft，致使節點數量擴展上難以突破，在項目後期擴展上會比較吃力。

CITA 和 FISCO BCOS 的特性：對於 FISCO BCOS 和 CITA 來講，保證以上所述區塊鏈的全部特色，可是在使用的時候設計範式會和傳統項目差別較大。做爲一個分佈式帳本，能夠保證數據的不可篡改同時也可使用了去中心化的共識機制拜占庭容錯，保證了 1/3 的容錯率。在這兩種框架中，將鏈的參與方分紅了共識節點和只讀節點兩種，共識節點便是擁有記帳權利的參與方，而只讀節點是擁有查閱全部數據的參與方。

若是說以太坊表明着區塊鏈的精神，CITA 和 FISCO BCOS 繼承自公鏈。CITA  和 FISCO BCOS 身上對於以太坊雖然在場景和使用上已經和公鏈徹底不一樣，可是在一些底層邏輯上仍是能夠看到對於公有鏈的繼承。從技術上來說，繼承了以太坊的虛擬機，也就是繼承了以太坊龐大的生態。接下來，本文將從技術實現角度對比三者的不一樣。

02　共識和交易流程

共識機制做爲區塊鏈的靈魂，不管是公鏈仍是聯盟鏈，共識機制都從根本上限制了區塊鏈的交易處理能力和擴展性，同時也是其分佈式協做能力的基礎。共識是分佈式系統中節點對數據或網絡最終狀態達成的協議。因爲網絡環境和節點狀態的不可控，共識機制須要同時考慮性能、可靠性、安全性等多方面問題。共識機制從大的方面，可分爲 Nakamoto Consensus 等無需准入的共識機制，和 PBFT 等須要准入的共識機制兩大類。

Nakamoto 共識在公鏈上應用普遍，可是它的機率模型在提供較高可靠性的同時，犧牲了效率。在具體商業應用環境中，許可機制已經保證了必定程度上的節點可信度，這樣的前提下，用戶更關心執行效率和最終肯定性。這是 BFT 類共識在聯盟鏈中流行的緣由。

接下來本文將先分別介紹 FISCO BCOS、CITA 和 Fabirc 共識技術實現，本文再從性能，應用場景，擴展性和安全性等幾個方面來進行對比分析。

技術實現

BCOS共識機制效率相對較爲傳統

FISCO BCOS 的共識機制採用了傳統的 PBFT 共識，其共識流程主要包括 Pre-prepare, Prepare 和 Commit 三個階段：

1. Pre-prepare：Leader 節點執行區塊，產生簽名，並將 Proposal 廣播給其餘共識節點；

2. Prepare：共識節點驗證 Proposal 並廣播簽名，同時收集其餘節點簽名，節點收集到 2f + 1 的簽名後，開始廣播 Commit 包；

3. Commit：Leader 節點收集 Commit 包，節點收集滿 2*f + 1 的 Commit 包後，更新本地數據庫並廣播給其餘節點，其餘節點收到以後更新本地數據庫。

下圖爲標準的一次PBFT的過程：

在區塊鏈中由於共識節點之間須要統一 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 和 Ｂ 之間頻繁轉賬這種場景，由於每筆交易都會修改 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，因爲執行、排序、提交節點職能的分離，且執行（驗證）和排序能夠分別採用不一樣的共識策略，安全策略能夠由用戶自由把握，客戶端參與狀態和執行的共識。

03　智能合約

智能合約一詞有必定的誤導性，智能每每給人帶來必定的神祕色彩，就其合約功能自己來說並沒有」智能性」。在區塊鏈出現以前，全部的系統都是採用中心化的架構，監管機構和用戶沒法驗證和保證系統功能的正確性，沒法確保數據未被惡意修改，沒法保證數據的安全性。因爲區塊鏈的出現，使得在不依賴於第三方的狀況下，可以可信地進行交易，並且交易可追蹤沒法逆轉。智能合約的核心含義在於：在區塊鏈基礎上實現可信計算，並由區塊鏈協議保證的可追蹤和沒法逆轉。

在比特幣中交易主要用於點對點的現金支付，以太坊因爲引入圖靈完備的智能合約被稱爲區塊鏈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支持鏈上定時任務。

04性能

通過區塊鏈底層技術最近幾年的發展，聯盟鏈的性能已經再也不是其最主要的瓶頸。

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.10...](https://arxiv.org/pdf/1801.10...），在32核CPU，10節點的狀況下，性能能夠到3400左右。根據這份報告背書節點數對性能影響並不大，由於背書節點並不實際參與共識。

現階段聯盟的性能已經有了長足的進步，相對落地場景而言，性能已經再也不是最主要的瓶頸。同時國產聯盟鏈在性能方面已經不輸於國外的大品牌，甚至已經領先於國外。

　05存儲

區塊鏈的存儲從內容方面講主要包括兩個方面：區塊和交易存儲、世界狀態存儲。本文先分別介紹各自的實現方式，再從支持數據庫類型、存儲效率、可擴展性、數據維護等方面進行對比分析。

實現方式

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爲用戶提供較好的查詢功能和較高的性能是一個不錯的取捨。

06　治理

聯盟鏈不一樣於公鏈的最大不一樣之處在於其治理方式的不一樣，對於公鏈來說因爲其是開放的系統須要必定的經濟激勵來協調不一樣角色間的關係，而聯盟鏈因爲節點是准入機制，因此其治理方式與公鏈有很是大的不一樣。對於聯盟鏈來說，其治理主要包含：節點管理、賬號權限、經濟模型。

節點管理

對於BCOS和CITA來說，節點主要分爲兩類：共識節點和普通節點。共識節點負責共識出塊，普通節點只能同步數據並驗證數據而沒有打包交易的權力。

對於Fabric，節點分爲背書節點，排序節點，提交節點。背書節點負責執行交易並返回結果，排序節點負責對交易排序並打包出塊，提交節點負責驗證交易並更新狀態。

對於共識節點BCOS/CITA均採用了系統合約的方式進行管理，節點的增刪須要共識節點進行共識。而Fabric的節點增刪，能夠由節點管理員修改配置，無需共識，可是激活新的配置文件須要發送交易並進行共識。

本文認爲經過白名單/黑名單的方式或者CA的方式管理節點身份，均能知足聯盟鏈的大多數場景，CA在對節點身份的驗證方面更加嚴格。

用戶權限管理

對於聯盟鏈來將，聯盟各個角色以及聯盟內均須要比較複雜的權限管理，這樣不一樣的角色只能訪問屬於本身受權的資源。

在CITA/BCOS中都經過複雜的權限管理，來對用戶的交易權限進行管理，包括髮送交易，建立合約，合約方法調用權限等等。

Fabric經過配置文件的方式(Policy）的方式進行管理用戶的權限。

BCOS/CITA權限管理經過交易的方式進行管理，比Fabric經過配置文件的方式修改，更加區塊鏈化，治理操做會保留痕跡。

經濟模型

CITA支持兩種不一樣的經濟模型

在公鏈中，礦工打包用戶的交易每每須要用戶支付必定的手續費；對於聯盟鏈來說，狀況有所不一樣。

BCOS、CITA和Fabric均支持向用戶提供免費服務的模式，同時在BCOS/CITA中會經過系統合約控制用戶單個區塊內對系統資源的使用狀況，防止對系統濫用。

而CITA又能夠支持收費模式，節點對用戶交易精確計費並收取Token手續費。而Token便可以是節點免費分配給用戶，也能夠須要用戶有償使用，這樣能夠更加精細地控制用戶對系統資源的使用狀況。

　07跨鏈和隱私

跨鏈和隱私方案，距離生產環境依然有可優化空間

BCOS引入了羣組的方式，使一個節點能夠屬於不一樣羣組，而羣組的消息、交易、存儲、執行等等徹底隔離。

Fabric 的羣組概念和BCOS相似，一個節點能夠屬於不一樣羣組，不一樣羣組可使用不一樣的背書策略。

在BCOS和Fabric中，羣組的數據和通訊等都是隔離的，而且可使用不一樣的共識策略，因此能夠將其當作多鏈。當前對於多鏈最大的問題在於鏈間通訊，二者在這方面均沒有很是成熟方案。

在CITA中，引入了側鏈技術，側鏈和主鏈之間能夠互相通訊，側鏈技術距離生產環境依然有可優化的空間。

不管羣組或者側鏈等技術，本質上都是一種多鏈技術，當前多鏈技術只能解決節點的隱私問題，暫時沒法處理交易和用戶級別的隱私。

CITA已經開源其零知識證實和SGX的實現。

對於同態加密、零知識證實，SGX等等，都處於發展階段，距離生產環境依然有可優化的空間。

08密碼學支持

CITA在密碼學支持上更全面

對比能夠看到BCOS/CITA均支持國密，對國內監管需求較友好；在密碼學算法支持上CITA更全面，除了支持常見的Keccak/Secp256k1以外，也支持更安全性能更好的Keccak/Secp256k1。

09系統架構

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　總結

通過以上的分析，本文彙總其最主要的優缺點：

若是您對技術感興趣，歡迎關注咱們開源代碼庫（點個 Star 唄）：

GitHub：https://github.com/citahub