陀螺精選 | 一文看懂BCOS、CITA、Fabric的區別

買賣虛擬貨幣

聯盟鏈技術哪家強?開源架構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 和 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,由於執行、排序、提交節點職能的分離,且執行(驗證)和排序可以分別採用不同的共識策略,安全策略可以由使用者自由把握,客戶端參與狀態和執行的共識。

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.10228.pdf](https://arxiv.org/pdf/1801.10228.pdf)),在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

總結經過以上的分析,本文彙總其最主要的優缺點:

免責聲明:

  1. 本文版權歸原作者所有,僅代表作者本人觀點,不代表鏈報觀點或立場。
  2. 如發現文章、圖片等侵權行爲,侵權責任將由作者本人承擔。
  3. 鏈報僅提供相關項目信息,不構成任何投資建議

推荐阅读

;