【51CTO.com原創(chuàng)稿件】

摘要

第46屆世界經(jīng)濟論壇達沃斯年會將區(qū)塊鏈與人工智能、自動駕駛等一并列入“第四次工業(yè)革命”?！督?jīng)濟學人》曾在2015年10月的封面文章《信任的機器》中介紹區(qū)塊鏈——“比特幣背后的技術有可能改變經(jīng)濟運行的方式”。

區(qū)塊鏈之所以被稱為信任的機器源于其分布式和不可篡改的兩個核心特性，這也是區(qū)塊鏈有別于傳統(tǒng)數(shù)據(jù)庫的核心特性。這里的分布式包含兩層含義：一是傳統(tǒng)的分布式存儲，二是區(qū)塊鏈的底層協(xié)議帶來的協(xié)作性，我們這里更多的是指代其分布式協(xié)作的能力。

黨中央在10月24日下午就區(qū)塊鏈技術發(fā)展現(xiàn)狀和趨勢進行第十八次集體學習時指出，要抓住區(qū)塊鏈技術融合、功能拓展、產(chǎn)業(yè)細分的契機，發(fā)揮區(qū)塊鏈在促進數(shù)據(jù)共享、優(yōu)化業(yè)務流程、降低運營成本、提升協(xié)同效率、建設可信體系等方面的作用。我們認為正是由于區(qū)塊鏈”可信的機器”的特性使其有在社會的諸多領域發(fā)揮重要作用的潛力。

在區(qū)塊鏈中主要通過共識算法、智能合約、治理、跨鏈、隱私等來實現(xiàn)其“可信協(xié)作”，所以我們將從這幾個方面并結(jié)合企業(yè)應用場景來分析底層技術的差異，來幫助企業(yè)用戶更好地做出選擇。同時我們也會從傳統(tǒng)企業(yè)軟件的可維護性、性能、開發(fā)工具、擴展性、軟件協(xié)議等方面來進行分析和對比。

我們選擇了市面上歷史最悠久，用戶范圍最廣的幾個開源底層進行對比。

FISCO BCOS誕生于2017年，由金鏈盟推出，是標準的國產(chǎn)底層。金鏈盟是由深圳市金融科技協(xié)會、深圳前海微眾銀行、深證通等二十余家金融機構(gòu)和科技企業(yè)于2016年5月31日共同發(fā)起成立的非營利性組織。

CITA 是一個開源的區(qū)塊鏈操作系統(tǒng)內(nèi)核，以高穩(wěn)定性，高性能，高可擴展性為設計目標。CITA 開源項目由秘猿科技 Cryptape 于2016年發(fā)起。目前由溪塔科技等CITAHub社區(qū)企業(yè)共同維護。CITA 采用微服務架構(gòu)設計，提供豐富的開發(fā)工具集，靈活的區(qū)塊鏈治理工具，開發(fā)者可為不同類型的區(qū)塊鏈網(wǎng)絡進行二次開發(fā)或配置。

Hyperledger Fabric是分布式賬本解決方案的平臺，該平臺以模塊化架構(gòu)為基礎，提供高度的機密性，靈活性和可擴展性。 它旨在支持不同組件的可插拔實現(xiàn)，并適應整個經(jīng)濟生態(tài)系統(tǒng)中存在的復雜性。Fabric最早由IBM設計和開發(fā)，2015年將其源代碼奉獻給了Linux基金會的Hyperledger項目。

共識和交易流程

共識機制作為區(qū)塊鏈的靈魂，無論是公鏈還是聯(lián)盟鏈，共識機制都從根本上限制了區(qū)塊鏈的交易處理能力和擴展性，同時也是其分布式協(xié)作能力的基礎。共識是分布式系統(tǒng)中節(jié)點對數(shù)據(jù)或網(wǎng)絡最終狀態(tài)達成的協(xié)議。由于網(wǎng)絡環(huán)境和節(jié)點狀態(tài)的不可控，共識機制需要同時考慮性能、可靠性、安全性等多方面問題。共識機制從大的方面，可分為 Nakamoto Consensus等無需準入的共識機制，和PBFT等需要準入的共識機制兩大類。

Nakamoto 共識在公鏈上應用廣泛，但是它的概率模型在提供較高可靠性的同時，犧牲了效率。在具體商業(yè)應用環(huán)境中，許可機制已經(jīng)保證了一定程度上的節(jié)點可信度，這樣的前提下，用戶更關心執(zhí)行效率和最終確定性。這是BFT類共識在聯(lián)盟鏈中流行的原因。

下面先分別介紹BCOS、CITA和 Fabirc共識技術實現(xiàn)，我們再從性能，應用場景，擴展性和安全性等幾個方面來進行對比分析。

技術實現(xiàn)

BCOS共識機制效率相對較低

BCOS的共識機制采用了傳統(tǒng)的PBFT共識，其共識流程主要包括Pre-prepare, Prepare和Commit三個階段：

1.Pre-prepare：Leader節(jié)點執(zhí)行區(qū)塊，產(chǎn)生簽名，并將Proposal廣播給其他共識節(jié)點；

2.Prepare：共識節(jié)點驗證Proposal并廣播簽名，同時收集其他節(jié)點簽名，節(jié)點收集到2f + 1的簽名后，開始廣播Commit包；

3.Commit：Leader節(jié)點收集Commit包，節(jié)點收集滿2*f + 1的Commit包后，更新本地數(shù)據(jù)庫并廣播給其他節(jié)點，其他節(jié)點收到之后更新本地數(shù)據(jù)庫。

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

在區(qū)塊鏈中因為共識節(jié)點之間需要統(tǒng)一Commit階段的投票，所以最后的Commit階段略為不同：Leader節(jié)點收到2*f + 1 的Commit 包之后會將最終的Commit 包廣播給其他共識節(jié)點來統(tǒng)一投票。

在整個共識流程中，交易在Pre-prepare階段執(zhí)行一次，在Prepare階段驗證一次，BCOS中使用的傳統(tǒng)PBFT流程為先執(zhí)行再驗證的模式，包含了兩個執(zhí)行交易的時間長度。

CITA采用高效的自主研發(fā)的共識協(xié)議

CITA實現(xiàn)了根據(jù)區(qū)塊鏈連續(xù)共識特點而優(yōu)化的CITA-BFT。區(qū)塊鏈是一個連續(xù)共識的過程，CITA將交易的執(zhí)行和共識進行拆分，避免了兩次執(zhí)行的問題。根據(jù)復制狀態(tài)機的原理：起始狀態(tài)一致，執(zhí)行交易順序一致，執(zhí)行過程是確定的，三個條件都滿足的情況下就可以保證最終結(jié)果一定會一致。在區(qū)塊鏈中起始狀態(tài)由創(chuàng)世塊來保證一致，虛擬機是完全確定的，所以只要保證交易順序一致就可以保證其最終結(jié)果一定一致。在區(qū)塊鏈中Block的preHash已經(jīng)包含了上個塊交易處理之后的世界狀態(tài)信息。CITA-BFT對當前區(qū)塊的交易順序和上個區(qū)塊的執(zhí)行結(jié)果進行共識。這樣在共識過程中不需要去執(zhí)行交易，而只需要在共識完之后進行一次交易處理，大大提高了整個鏈的吞吐量。CITA-BFT是針對區(qū)塊鏈連續(xù)共識的特點進行了優(yōu)化，采用了先共識后處理的方式，使得共識的過程不必執(zhí)行交易，只需要共識完成之后執(zhí)行一次交易即可。經(jīng)過驗證，在最簡單的存證交易時，共識性能有35%左右提升。

CITA-BFT避免了共識協(xié)議最后一輪Leader廣播的過程。在傳統(tǒng)的PBFT中在最后的Commit階段，需要Leader收到足夠的Commit包并廣播給其他節(jié)點。區(qū)塊鏈是一個連續(xù)共識的過程，在CITA-BFT中，Block中共識投票是上一個區(qū)塊的投票，所以合并了Commit階段的Leader廣播最終區(qū)塊過程和下一個高度的Proposal階段，這樣節(jié)省了一輪廣播過程，通過下一個高度Proposal的過程統(tǒng)一了Commit投票信息。

CITA-BFT采用Proposal預處理技術使共識和執(zhí)行能夠并行進行，極大地提高的系統(tǒng)性能。由于聯(lián)盟鏈在多數(shù)情況下，網(wǎng)絡狀況良好能在一輪共識流程中完成共識，CITA中引入了Proposal預處理的技術：在Pre-prepare階段，節(jié)點在收到Proposal之后可以直接處理交易，而不必等到共識流程完成，等到共識流程完成之后再將共識結(jié)果通知交易處理器。在傳統(tǒng)的PBFT的過程中，交易處理和共識是串行的，引入Proposal預處理之后，可以使得共識的Prepare階段Commit階段和交易處理并行進行，大大提高了整個系統(tǒng)的吞吐量。經(jīng)測試，對于簡單的交易處理，有10%到20%左右的性能提升。

在CITA中采用了CompactBlock的技術來壓縮共識區(qū)塊的大小，提高網(wǎng)絡帶寬利用率。Block中的交易已經(jīng)單獨廣播過一次，所以共識Block中只需要包含交易ID即可，這樣可以大大降低區(qū)塊消息的大小。經(jīng)測試在網(wǎng)絡條件較好的情況下，對于簡單的交易處理，有5%到10%的性能提升。

Fabric共識機制限制業(yè)務效率提升

Fabric將其節(jié)點角色分為：排序節(jié)點，背書節(jié)點，提交節(jié)點?？蛻舳耸紫葘⒔灰渍埱蟀l(fā)送給背書節(jié)點，背書節(jié)點執(zhí)行后將read/write set及其簽名返回給客戶端，客戶端收集到足夠相同的結(jié)果后，將read/writeset、多組簽名和交易請求組成簽名后的交易，發(fā)送給排序節(jié)點，排序節(jié)點組成區(qū)塊之后，廣播給提交節(jié)點，提交節(jié)點驗證read/write set和簽名數(shù)是否滿足，標記結(jié)果并保存合法的結(jié)果到各自的賬本。

在Fabric中由于交易的執(zhí)行是非確定性的，這點不同于BCOS和CITA的設計理念。所以需要背書節(jié)點先執(zhí)行交易，并由客戶端根據(jù)背書策略進行對比結(jié)果，再發(fā)給排序節(jié)點，最終由提交節(jié)點驗證并更新各自的數(shù)據(jù)庫。我們可以理解為：共識狀態(tài)的過程是由客戶端、背書節(jié)點、提交節(jié)點共同參與完成的；排序節(jié)點只負責交易順序的共識，而不負責狀態(tài)共識。在交易狀態(tài)共識和排序可以分別采用不同的策略。比如交易狀態(tài)可以采用超過3/4的狀態(tài)一致，而排序節(jié)點的共識使用傳統(tǒng)的Raft或者Solo共識，采用傳統(tǒng)CFT共識即可滿足多數(shù)場景。這里的問題是交易中需要包含用戶的簽名，以及多個背書節(jié)點的簽名，以及read/write set，這樣導致交易非常大。

Fabric在交易狀態(tài)有沖突時，例如A和Ｂ之間頻繁轉(zhuǎn)帳這種場景，因為每筆交易都會修改AB賬戶的余額，所以會造成交易沖突。沖突交易每個塊最多只能有一個交易被處理，這將大大限制業(yè)務合約的場景。

性能對比

最佳">CITA共識性能最佳

BCOS：

•傳統(tǒng)的PBFT

•共識過程中會重復執(zhí)行交易，共識效率較低

CITA：

•先共識再執(zhí)行，只執(zhí)行一次交易，整體效率較高

•優(yōu)化Commit階段的Leader廣播過程，減少共識時間

•Proposal預執(zhí)行技術使得共識和執(zhí)行并行，提高整體性能

•CompactBlock技術提高帶寬利用率

Fabric：

•執(zhí)行（驗證）和排序可以采用不同的共識策略，比較靈活

•交易需要多個背書節(jié)點簽名和read/write集合會導致交易非常大

對比可以看出BCOS采用傳統(tǒng)PBFT，共識效率較低；CITA采用了自主研發(fā)的CITA-BFT，共識和交易處理有50%以上的性能提升；Fabric將整個流程拆分為執(zhí)行、排序、驗證，增加了靈活性，但是驗證和執(zhí)行的分離導致交易非常大。

應用場景

Fabirc共識機制限制了業(yè)務場景

BCOS/CITA：都是BFT類共識，適合多數(shù)的聯(lián)盟鏈場景，由參與方、監(jiān)管方和可信第三方組成共識節(jié)點。

Fabric：將共識的流程拆分為執(zhí)行，排序和驗證，具有更好的靈活性，但是由此帶來交易結(jié)構(gòu)非常大，而且沖突交易每個塊只能上鏈一個交易，大大限制了業(yè)務合約的場景。比如對于一個統(tǒng)計投票的合約，有N個投票者，每個投票人員通過發(fā)送交易進行投票，因為總的投票結(jié)果是共享狀態(tài)，這種情況下每個區(qū)塊只能處理一筆交易。

擴展性

安全性

可以看到，BCOS和CITA都使用類BFT的共識，所以在安全性方面分析現(xiàn)有的BFT協(xié)議即可，有用比較高的安全邊界。

對于Fabric，由于執(zhí)行、排序、提交節(jié)點職能的分離，且執(zhí)行（驗證）和排序可以分別采用不同的共識策略，安全策略可以由用戶自由把握，客戶端參與狀態(tài)和執(zhí)行的共識。

智能合約

智能合約一詞有一定的誤導性，智能往往給人帶來一定的神秘色彩，就其合約功能本身來講并無”智能性”。在區(qū)塊鏈出現(xiàn)之前，所有的系統(tǒng)都是采用中心化的架構(gòu)，監(jiān)管機構(gòu)和用戶無法驗證和保證系統(tǒng)功能的正確性，無法確保數(shù)據(jù)未被惡意修改，無法保證數(shù)據(jù)的安全性。由于區(qū)塊鏈的出現(xiàn)，使得在不依賴于第三方的情況下，能夠可信地進行交易，而且交易可追蹤無法逆轉(zhuǎn)。智能合約的核心含義在于：在區(qū)塊鏈基礎上實現(xiàn)可信計算，并由區(qū)塊鏈協(xié)議保證的可追蹤和無法逆轉(zhuǎn)。

在比特幣中交易主要用于點對點的現(xiàn)金支付，以太坊由于引入圖靈完備的智能合約被稱為區(qū)塊鏈2.0。雖然理論上以太坊上的智能合約是圖靈完備的，但是受限于交易手續(xù)費、合約指令、區(qū)塊Gas上限、節(jié)點可信度等，公鏈智能合約并不適用于現(xiàn)有的企業(yè)開發(fā)。

聯(lián)盟鏈由于節(jié)點數(shù)量有限，且節(jié)點運營方可以采用高性能的硬件設備，以及底層協(xié)議支持等，更適合企業(yè)開發(fā)。首先我們介紹三者智能合約的技術實現(xiàn)，再分別從安全性、易用性、可用性三方面進行對比分析。

技術實現(xiàn)

BCOS和CITA均支持EVM和預編譯合約。借助于Ethereum 智能合約的完善的生態(tài)系統(tǒng)，兩者都在其基礎之上做了定制化，有豐富的合約編寫和測試工具。

對于預編譯合約需要開發(fā)者對區(qū)塊鏈系統(tǒng)有一定的了解，需要較高的門檻。當前支持EVM的語言主要是Solidity，Solidity合約可以通過交易進行部署，在調(diào)用時將合約代碼加載到虛擬機中。

Fabric的合約通過ChainCode的方式以Docker的方式進行線下安裝，然后通過交易進行激活。ChainCode合約的部署相對較重，但支持多種語言（Go,Javascript等），合約的部署和更新以線下方式進行更新，合約代碼并沒有進行共識，可以將合約看成黑盒，只需要保證其輸入和輸出正確即可，并不關心其內(nèi)部邏輯的具體實現(xiàn)。

由于Fabric采用了傳統(tǒng)的語言進行合約編寫，雖然開發(fā)者不需要學習新的語言，但是由于虛擬機的不確定性，ChainCode的方式只適合Fabric的先執(zhí)行再共識再驗證的共識方式，并不具備通用性。

安全性

安全性是智能合約有別于其他程序的主要特征，這里的安全性，包含確定性、可驗證、可審計、可追蹤等特性。

由于BCOS和CITA在智能合約設計理念上接近，我們將兩者放入同一欄中。

對比可以看出由于BCOS/CITA交易是鏈上執(zhí)行的，所以BCOS/CITA的智能合約更具有確定性、可驗證、可審計、不可逆、可追蹤的特點。

Fabric在合約代碼由背書節(jié)點各自部署和升級，驗證性、審計性、可追蹤性無法保證。但是由于在Fabric的設計理念中，合約執(zhí)行后再由客戶端進行驗證，我們可以認為合約最終的結(jié)果是由客戶端和背書節(jié)點共同決定的，只要交易結(jié)果符合背書策略并且符合用戶預期，對于合約代碼的驗證性要求相對就沒有那么重要了。

易用性

BCOS/CITA在合約易用性上略勝于Fabric

BCOS/CITA支持以太坊EVM并且對其工具鏈進行深度優(yōu)化，對開發(fā)者更友好，合約的部署、調(diào)用、升級都通過交易進行，更輕量和方便。

可用性

BCOS/CITA/Fabric都可以應對企業(yè)復雜的業(yè)務邏輯，支持比較復雜的合約計算和處理，同時CITA支持鏈上定時任務。

性能

經(jīng)過區(qū)塊鏈底層技術最近幾年的發(fā)展，聯(lián)盟鏈的性能已經(jīng)不再是其最主要的瓶頸。

BCOS官方文檔并未提供性能數(shù)據(jù)，我們只能根據(jù)第三方提供的數(shù)據(jù)來判斷，我們找到了兩個相對可靠的信息來源。中國信通院可信區(qū)塊鏈最新評測（2019年11-19日），BCOS單鏈TPS超2萬。在2019年7月底的一篇新聞稿”當測試團隊說區(qū)塊鏈性能達到10000TPS的那一刻，張開翔在微信群里給團隊發(fā)出了人生中最大的紅包。“。因為兩次測試數(shù)據(jù)均未提供測試用的環(huán)境、節(jié)點數(shù)、使用的共識協(xié)議（BCOS支持Raft）等，推測這里可能是分別使用了不同的共識方法和節(jié)點數(shù)進行的測試。

CITA在官方文檔中最新版本的交易性能已經(jīng)可以達到 15,000+ TPS，數(shù)據(jù)來自 CITA 0.16 版本（2018年5月15日），在四臺 32 核，64G 的云服務器上部署 4個節(jié)點，每臺服務器配置百兆帶寬。

Fabric官方并未提供其性能數(shù)據(jù)。根據(jù)第三方提供的數(shù)據(jù)（https://arxiv.org/pdf/1801.10228.pdf），在32核CPU，10節(jié)點的情況下，性能可以到3400左右。根據(jù)這份報告背書節(jié)點數(shù)對性能影響并不大，因為背書節(jié)點并不實際參與共識。

現(xiàn)階段聯(lián)盟的性能已經(jīng)有了長足的進步，相對落地場景而言，性能已經(jīng)不再是最主要的瓶頸。同時國產(chǎn)聯(lián)盟鏈在性能方面已經(jīng)不輸于國外的大品牌，甚至已經(jīng)領先于國外。

存儲

區(qū)塊鏈的存儲從內(nèi)容方面講主要包括兩個方面：區(qū)塊和交易存儲、世界狀態(tài)存儲。我們先分別介紹各自的實現(xiàn)方式，再從支持數(shù)據(jù)庫類型、存儲效率、可擴展性、數(shù)據(jù)維護等方面進行對比分析。

實現(xiàn)方式

BCOS的狀態(tài)存儲支持兩種存儲模式

對于區(qū)塊的保存，BCOS交易列表，交易回執(zhí)等都采用了傳統(tǒng)的MPT方式保存。對于世界狀態(tài)，BCOS采用了兩種存儲模式：storage state和MPT state。MPT state支持RocksDB和External存儲，MPT存儲在保存歷史狀態(tài)的同時，最大化減少存儲數(shù)據(jù)。Storage State 支持RocksDB、MySQL、External，使用storage state存儲時，犧牲了部分的可追溯性，但帶來了性能上的提升，同時能支持SQL語句的查詢和統(tǒng)計。因為世界狀態(tài)始終是可以通過交易進行還原，所以對于犧牲部分可追溯性而換取性能的提升和狀態(tài)查詢是可以接受的。

CITA支持RocksDB、External存儲。使用MPT保存狀態(tài)，使用Simple Merkle Tree保存交易和交易回執(zhí)。對于狀態(tài)存儲CITA選擇了經(jīng)典的MPT存儲，保存歷史狀態(tài)的同時，最大化減少存儲數(shù)據(jù)。而對于交易和交易回執(zhí)使用Simple Merkle Tree存儲，可以優(yōu)化存儲數(shù)據(jù)量和減少Hash計算。

Fabric的區(qū)塊存儲，同樣采用了MPT的方式進行保存。對于世界狀態(tài)的存儲支持KV和CouchDB存儲，在世界狀態(tài)存儲時，F(xiàn)abric不支持歷史狀態(tài)的保存，同時有性能上的提升，并支持豐富的條件查詢和統(tǒng)計。

對比分析

對比來看：

CITA在交易的存儲結(jié)構(gòu)上做了優(yōu)化和改進，提供了快照功能對世界狀態(tài)的歷史進行裁剪。

BCOS世界狀態(tài)的存儲模式上，支持兩種不同的模式，允許在犧牲一部分狀態(tài)可追溯性上，提升性能和支持豐富的SQL查詢。

Fabric的世界狀態(tài)存儲不保留歷史狀態(tài)，支持世界狀態(tài)的條件查詢。

我們認為在交易存儲方面，節(jié)點必須要保留歷史記錄，而對于世界狀態(tài)的歷史存儲，可以通過交易進行還原，在這種情況下BCOS/Fabric為用戶提供較好的查詢功能和較高的性能是一個不錯的取舍。

治理

聯(lián)盟鏈不同于公鏈的最大不同之處在于其治理方式的不同，對于公鏈來講由于其是開放的系統(tǒng)需要一定的經(jīng)濟激勵來協(xié)調(diào)不同角色間的關系，而聯(lián)盟鏈由于節(jié)點是準入機制，所以其治理方式與公鏈有非常大的不同。對于聯(lián)盟鏈來講，其治理主要包含：節(jié)點管理、帳號權限、經(jīng)濟模型。

節(jié)點管理

對于BCOS和CITA來講，節(jié)點主要分為兩類：共識節(jié)點和普通節(jié)點。共識節(jié)點負責共識出塊，普通節(jié)點只能同步數(shù)據(jù)并驗證數(shù)據(jù)而沒有打包交易的權力。

對于Fabric，節(jié)點分為背書節(jié)點，排序節(jié)點，提交節(jié)點。背書節(jié)點負責執(zhí)行交易并返回結(jié)果，排序節(jié)點負責對交易排序并打包出塊，提交節(jié)點負責驗證交易并更新狀態(tài)。

對于共識節(jié)點BCOS/CITA均采用了系統(tǒng)合約的方式進行管理，節(jié)點的增刪需要共識節(jié)點進行共識。而Fabric的節(jié)點增刪，可以由節(jié)點管理員修改配置，無需共識，但是激活新的配置文件需要發(fā)送交易并進行共識。

我們認為通過白名單/黑名單的方式或者CA的方式管理節(jié)點身份，均能滿足聯(lián)盟鏈的大多數(shù)場景，CA在對節(jié)點身份的驗證方面更加嚴格。

用戶權限管理

對于聯(lián)盟鏈來將，聯(lián)盟各個角色以及聯(lián)盟內(nèi)均需要比較復雜的權限管理，這樣不同的角色只能訪問屬于自己授權的資源。

在CITA/BCOS中都通過復雜的權限管理，來對用戶的交易權限進行管理，包括發(fā)送交易，創(chuàng)建合約，合約方法調(diào)用權限等等。

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

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

經(jīng)濟模型

CITA支持兩種不同的經(jīng)濟模型

在公鏈中，礦工打包用戶的交易往往需要用戶支付一定的手續(xù)費；對于聯(lián)盟鏈來講，情況有所不同。

BCOS、CITA和Fabric均支持向用戶提供免費服務的模式，同時在BCOS/CITA中會通過系統(tǒng)合約控制用戶單個區(qū)塊內(nèi)對系統(tǒng)資源的使用情況，防止對系統(tǒng)濫用。

而CITA又可以支持收費模式，節(jié)點對用戶交易精確計費并收取Token手續(xù)費。而Token即可以是節(jié)點免費分配給用戶，也可以需要用戶有償使用，這樣可以更加精細地控制用戶對系統(tǒng)資源的使用情況。

跨鏈和隱私

跨鏈和隱私方案，距離生產(chǎn)環(huán)境依然有可優(yōu)化空間

BCOS引入了群組的方式，使一個節(jié)點可以屬于不同群組，而群組的消息、交易、存儲、執(zhí)行等等完全隔離。

Fabric 的群組概念和BCOS類似，一個節(jié)點可以屬于不同群組，不同群組可以使用不同的背書策略。

在BCOS和Fabric中，群組的數(shù)據(jù)和通信等都是隔離的，并且可以使用不同的共識策略，所以可以將其看成多鏈。當前對于多鏈最大的問題在于鏈間通信，兩者在這方面均沒有非常成熟方案。

在CITA中，引入了側(cè)鏈技術，側(cè)鏈和主鏈之間可以互相通信，側(cè)鏈技術距離生產(chǎn)環(huán)境依然有可優(yōu)化的空間。

無論群組或者側(cè)鏈等技術，本質(zhì)上都是一種多鏈技術，當前多鏈技術只能解決節(jié)點的隱私問題，暫時無法處理交易和用戶級別的隱私。

CITA已經(jīng)開源其零知識證明和SGX的實現(xiàn)。

對于同態(tài)加密、零知識證明，SGX等等，都處于發(fā)展階段，距離生產(chǎn)環(huán)境依然有可優(yōu)化的空間。

密碼學支持

CITA在密碼學支持上更全面

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

系統(tǒng)架構(gòu)

CITA采用了微服務架構(gòu)

BCOS和Fabric均采用了單一系統(tǒng)的架構(gòu)，這種架構(gòu)要求節(jié)點必須在單一的物理機器上。

而CITA采用了微服務架構(gòu)，而且CITA也是全球第一個使用微服務架構(gòu)的開源區(qū)塊鏈。采用微服務架構(gòu)，可以使節(jié)點不僅僅限制在單個物理機器上，這樣對于企業(yè)用戶可以用更好的硬件設備去支持節(jié)點，有更好的擴展性。由于微服務間通過消息訂閱進行通信，企業(yè)用戶可以方便地替換或者增加定制化的服務，方便進行功能擴展。

開源協(xié)議

BCOS的開源協(xié)議對商業(yè)應用不夠友好

這里簡單介紹下相關的開源協(xié)議。

GPL協(xié)議的主要內(nèi)容是只要在一個軟件中使用(”使用”指類庫引用，修改后的代碼或者衍生代碼)GPL 協(xié)議的產(chǎn)品，則該軟件產(chǎn)品必須也采用GPL協(xié)議，既必須也是開源和免費。這就是所謂的”傳染性”。由于GPL嚴格要求使用了GPL類庫的軟件產(chǎn)品必須使用GPL協(xié)議，對于使用GPL協(xié)議的開源代碼，商業(yè)軟件或者對代碼有保密要求的部門就不適合集成/采用作為類庫和二次開發(fā)的基礎。

Apache Licence也是對商業(yè)應用友好的許可。使用者也可以在需要的時候修改代碼來滿足需要并作為開源或商業(yè)產(chǎn)品發(fā)布/銷售。

由此可以看出，BCOS的開源協(xié)議對商業(yè)應用不夠友好。

語言實現(xiàn)

CITA使用更現(xiàn)代的語言Rust，性能更高同時安全性更可靠

BCOS：使用C++進行開發(fā)，C++性能高，但是由于其歷史原因，系統(tǒng)容易有內(nèi)存安全的隱患；

Fabirc：Go實現(xiàn)，由于垃圾回收機制性能比C++弱；

CITA：Rust實現(xiàn)，現(xiàn)在相對主流的區(qū)塊鏈界的語言，Rust在內(nèi)存安全方面有保證，性能可以和C++媲美。

總結(jié)

經(jīng)過以上的分析，我們匯總其最主要的優(yōu)缺點：

 【51CTO原創(chuàng)稿件，合作站點轉(zhuǎn)載請注明原文作者和出處為51CTO.com】