企業(yè)級區(qū)塊鏈技術(shù)綜述*

邵奇峰,張 召,朱燕超,周傲英

1(華東師范大學(xué) 數(shù)據(jù)科學(xué)與工程學(xué)院,上海 200062)

2(中原工學(xué)院 軟件學(xué)院,河南 鄭州 450007)

通信作者:張召,E-mail:zhzhang@dase.ecnu.edu.cn

在涉及多方交易的場景中,目前的企業(yè)級應(yīng)用各自記錄己方的交易數(shù)據(jù),不同交易方多個賬本間的數(shù)據(jù)差異會引起分歧與爭議,因而需要人工對賬或第三方中介裁決,增加了交易的延遲和費(fèi)用.例如,目前美國股票交易時間不到1 秒,但在證券存托與清算公司(depository trust &clearing corporation,簡稱DTCC)的結(jié)算時間卻為3 天,限制了資本流動性[1].各國銀行機(jī)構(gòu)主要通過環(huán)球銀行金融電信協(xié)會(society for worldwide interbank financial telecommunications,簡稱SWIFT)實(shí)現(xiàn)跨幣種、跨境交易,目前每筆交易需支付百元左右的電訊費(fèi),且轉(zhuǎn)賬時間為2 天～3 天[2].區(qū)塊鏈(blockchain)技術(shù)實(shí)現(xiàn)了多方共享的全局性單一賬本,解決了多方獨(dú)立記賬所帶來的數(shù)據(jù)不一致性問題.區(qū)塊鏈?zhǔn)且环N去中心化、不可篡改、可追溯、可信的分布式數(shù)據(jù)庫,由互不信任的多方參與者共同維護(hù)；每筆交易需經(jīng)全網(wǎng)大多數(shù)參與者驗(yàn)證且達(dá)成共識后,才會一致性地記錄在全網(wǎng)節(jié)點(diǎn)；交易一旦被記錄,任何人都無法篡改,從而實(shí)現(xiàn)了可信的多方間數(shù)據(jù)共享,避免了人工對賬,消除了中介機(jī)構(gòu),減少了交易的延遲與費(fèi)用.區(qū)塊鏈?zhǔn)遣煌趥鹘y(tǒng)數(shù)據(jù)庫的新型數(shù)據(jù)庫,表1 對比了區(qū)塊鏈與傳統(tǒng)數(shù)據(jù)庫的差異.

Table 1 Comparison of blockchain and DBMS表1 區(qū)塊鏈與DBMS 對比

2008 年,化名為中本聰(Satoshi Nakamoto)的學(xué)者提出了比特幣,這是一種無需任何權(quán)威機(jī)構(gòu)背書的去中心化的數(shù)字貨幣支付系統(tǒng)[3].隨后人們發(fā)現(xiàn)了從比特幣底層提取出的區(qū)塊鏈技術(shù)不僅能夠應(yīng)用于數(shù)字貨幣,還能夠使用戶在無需相互信任與可信中介的場景下實(shí)現(xiàn)可信的價值傳輸.為此出現(xiàn)了一批用以太坊(ethereum)[4]為代表的實(shí)現(xiàn)數(shù)字資產(chǎn)交易的區(qū)塊鏈平臺.任何節(jié)點(diǎn)無需許可就能夠隨時加入/退出,所以此類區(qū)塊鏈被稱為公有鏈(public blockchain)或非許可鏈(permissionless blockchain).公有鏈允許任何節(jié)點(diǎn)隨意進(jìn)出的特性顯然無法適用于企業(yè)級應(yīng)用.在跨機(jī)構(gòu)的交易場景中,相互協(xié)作的多家企業(yè)組成聯(lián)盟,只有聯(lián)盟成員才可加入?yún)^(qū)塊鏈及參與交易.此類節(jié)點(diǎn)需經(jīng)許可才能加入的區(qū)塊鏈,被稱為企業(yè)級區(qū)塊鏈(enterprise blockchain)、聯(lián)盟鏈(consortium blockchain)或許可鏈(permissioned blockchain).公有鏈和企業(yè)級區(qū)塊鏈針對的應(yīng)用場景不同、解決的問題領(lǐng)域不同,它們之間的主要區(qū)別見表2.

Table 2 Comparison of public blockchain and enterprise blockchain表2 公有鏈與企業(yè)級區(qū)塊鏈對比

基于比特幣、以太坊等公有鏈的成功經(jīng)驗(yàn)及企業(yè)級應(yīng)用需求,業(yè)界推出了一批支持企業(yè)級應(yīng)用的區(qū)塊鏈平臺.2015 年12 月,Linux 基金會發(fā)起了Hyperledger(https://www.hyperledger.org)開源區(qū)塊鏈項(xiàng)目,著重于發(fā)展跨行業(yè)的企業(yè)級區(qū)塊鏈.Hyperledger 分別提出了Fabric(https://github.com/hyperledger/fabric),Sawtooth(https://github.com/hyperledger/sawtooth-core),Iroha(https://github.com/hyperledger/iroha),Burrow(https://github.com/hyperledger/burrow)和Indy(https://github.com/hyperledger/indy-node)等多個企業(yè)級區(qū)塊鏈平臺,以適應(yīng)不同的需求和場景.Hyperledger Fabric 應(yīng)用最為廣泛,其采用了合約執(zhí)行與共識機(jī)制相分離的系統(tǒng)架構(gòu),模塊化地實(shí)現(xiàn)了共識服務(wù)、成員服務(wù)等服務(wù)的即插即用.Hyperledger Sawtooth 基于Intel SGX(software guard extensions)[8]可信硬件實(shí)現(xiàn)了經(jīng)歷時間證明(proof of elapsed time,簡稱PoET)[9]共識機(jī)制,相對于PoW 共識,其無需挖礦且出塊間隔更短.Hyperledger Iroha 主要針對于移動應(yīng)用,其實(shí)現(xiàn)了基于鏈復(fù)制(chain replication)[10]的共識機(jī)制Sumeragi.Hyperledger Burrow 集成了以太坊虛擬機(jī)并可運(yùn)行以太坊智能合約,其使用了Tendermint[11]共識機(jī)制.Hyperledger Indy 是基于區(qū)塊鏈的去中心的數(shù)字身份平臺,其使用了 RBFT(redundant byzantine fault tolerance)[12]共識機(jī)制.2016 年4 月,R3 金融區(qū)塊鏈聯(lián)盟(https://www.r3.com)提出了Corda[13,14]平臺,著重服務(wù)于受監(jiān)管的金融行業(yè),強(qiáng)調(diào)業(yè)務(wù)數(shù)據(jù)僅對交易雙方及監(jiān)管可見的數(shù)據(jù)隱私性,反對數(shù)據(jù)全網(wǎng)廣播及每個節(jié)點(diǎn)擁有全部數(shù)據(jù).Corda 自稱是受到區(qū)塊鏈啟發(fā)的分布式賬本[15],在技術(shù)架構(gòu)上有許多特色與創(chuàng)新.2016 年9 月,摩根大通提出了基于以太坊構(gòu)建的企業(yè)級區(qū)塊鏈平臺Quorum[16],其通過分別處理公有交易和私有交易實(shí)現(xiàn)了交易和合約的隱私保護(hù),并用Raft 共識替換了以太坊的PoW 共識.2017 年2 月,企業(yè)以太坊聯(lián)盟(enterprise ethereum alliance,簡稱EEA)(https://entethalliance.org)成立,旨在合作開發(fā)標(biāo)準(zhǔn)和技術(shù)以拓展以太坊適用于企業(yè)級應(yīng)用,Quorum 即是EEA 的技術(shù)參考實(shí)現(xiàn).Chain Core(https://github.com/chain/chain)是由Chain 公司提出的企業(yè)級區(qū)塊鏈平臺,主要專注于金融行業(yè)的數(shù)字資產(chǎn)服務(wù),其基于Chain Protocol 實(shí)現(xiàn)了資產(chǎn)的發(fā)行、傳輸和控制.MultiChain[17]是由Coin Sciences 公司提出的企業(yè)級區(qū)塊鏈平臺,其兼容于比特幣系統(tǒng),側(cè)重于數(shù)字資產(chǎn)類應(yīng)用,可快速部署在Windows,Linux 和Mac OS 多種操作系統(tǒng)之上.Ripple[18]是瑞波公司提出的基于分布式賬本的實(shí)時跨境支付網(wǎng)絡(luò),其通過ILP(interledger protocol)[19]協(xié)議實(shí)現(xiàn)了不同賬本與支付系統(tǒng)間的互聯(lián).BigchainDB[20]是由BigchainDB 公司提出的可擴(kuò)展的區(qū)塊鏈數(shù)據(jù)庫,其聲稱既擁有高吞吐量、低延遲、大容量、豐富查詢和權(quán)限等分布式數(shù)據(jù)庫的優(yōu)點(diǎn),又擁有去中心化、不可篡改、資產(chǎn)傳輸?shù)葏^(qū)塊鏈的特性,因此被稱為在分布式數(shù)據(jù)庫中加入了區(qū)塊鏈特性.2017 年7 月,微眾銀行、萬向區(qū)塊鏈和矩陣元聯(lián)合提出了開源企業(yè)級區(qū)塊鏈平臺BCOS(https://github.com/bcosorg/bcos),為了適用于企業(yè)級應(yīng)用,其在以太坊基礎(chǔ)上加入了CA 身份認(rèn)證、PBFT共識機(jī)制、隱私保護(hù)等組件,在國內(nèi)率先應(yīng)用于金融領(lǐng)域并取得了商用實(shí)踐成果.隨后,又聯(lián)合金鏈盟提出了著重于解決金融行業(yè)高頻交易、安全性及合規(guī)方面需求的BCOS 分支版本FISCO BCOS(https://github.com/FISCO-BCOS).表3 分別從數(shù)據(jù)模型、共識機(jī)制、智能合約語言、智能合約沙箱、底層數(shù)據(jù)庫幾個方面對比了以上企業(yè)級區(qū)塊鏈平臺.

Table 3 Comparison of enterprise blockchain platform表3 企業(yè)級區(qū)塊鏈平臺對比

企業(yè)級區(qū)塊鏈產(chǎn)品眾多,但最有影響力的是Linux 基金會的Hyperledger Fabric、R3 聯(lián)盟的Corda 和EEA參考實(shí)現(xiàn)Quorum.目前,Hyperledger 包括IBM、Intel、百度等200 多家成員；R3 聯(lián)盟包括花旗銀行、匯豐銀行、德意志銀行等200 多家以金融機(jī)構(gòu)為主的成員；EEA 包括摩根大通、微軟、Intel 等400 多家成員.Fabric,Corda和Quorum 平臺都有著完善的軟件實(shí)現(xiàn)、廣泛的用戶群體和充分的運(yùn)營實(shí)踐,產(chǎn)品版本都在1.0 之上且系統(tǒng)代碼開源.文獻(xiàn)[21-23]主要基于比特幣介紹了區(qū)塊鏈技術(shù)的研究現(xiàn)狀,文獻(xiàn)[24-26]從數(shù)據(jù)處理的角度綜述了區(qū)塊鏈技術(shù).與已有文獻(xiàn)不同,本文主要結(jié)合Fabric,Corda 和Quorum 平臺的共性與差異進(jìn)行對比分析,在此基礎(chǔ)上,介紹了企業(yè)級區(qū)塊鏈技術(shù)的研究現(xiàn)狀與發(fā)展趨勢.本文第1 節(jié)提出企業(yè)級區(qū)塊鏈的系統(tǒng)架構(gòu).第2 節(jié)從整體結(jié)構(gòu)上描述Fabric,Corda 和Quorum 的交易流程.第3 節(jié)從網(wǎng)絡(luò)層闡述準(zhǔn)入機(jī)制和網(wǎng)絡(luò)協(xié)議.第4 節(jié)介紹共識機(jī)制的實(shí)現(xiàn)方案.第5 節(jié)對比分析Fabric,Corda 和Quorum 的數(shù)據(jù)組織與結(jié)構(gòu).第6 節(jié)從合約模型、沙箱環(huán)境論述智能合約.第7 節(jié)分別介紹Fabric、Corda 和Quorum 的隱私保護(hù)方案.第8 節(jié)總結(jié)企業(yè)級區(qū)塊鏈的研究挑戰(zhàn)與趨勢.結(jié)束語展望發(fā)展中的企業(yè)級區(qū)塊鏈.

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

各類企業(yè)級區(qū)塊鏈盡管面向的應(yīng)用領(lǐng)域不同,具體設(shè)計實(shí)現(xiàn)細(xì)節(jié)不同,但在整體系統(tǒng)架構(gòu)上還是存在著諸多共性.如圖1 所示,企業(yè)級區(qū)塊鏈可劃分為成網(wǎng)絡(luò)層、共識層、數(shù)據(jù)層、智能合約層和應(yīng)用層.

Fig.1 Architecture of enterprise blockchain圖1 企業(yè)級區(qū)塊鏈系統(tǒng)架構(gòu)

1.1 網(wǎng)絡(luò)層

區(qū)塊鏈強(qiáng)調(diào)網(wǎng)絡(luò)去中心化,強(qiáng)調(diào)節(jié)點(diǎn)平等、自治.以比特幣、以太坊為代表的公有鏈允許任何節(jié)點(diǎn)隨意加入退出且身份匿名,所以采用P2P 協(xié)議廣播消息以實(shí)現(xiàn)路由發(fā)現(xiàn)、節(jié)點(diǎn)識別、傳播交易數(shù)據(jù)與區(qū)塊數(shù)據(jù)[27].對于企業(yè)級區(qū)塊鏈而言,所有節(jié)點(diǎn)經(jīng)審核后才可加入網(wǎng)絡(luò)且身份已知,其交易數(shù)據(jù)因涉及商業(yè)機(jī)密而不宜全網(wǎng)廣播,因此就需要企業(yè)級區(qū)塊鏈在考慮去中心化的同時,既需加入節(jié)點(diǎn)準(zhǔn)入機(jī)制,還要利用節(jié)點(diǎn)身份已知、數(shù)據(jù)傳播范圍受限等特性對網(wǎng)絡(luò)協(xié)議進(jìn)行優(yōu)化.Fabric 采用了基于gRPC 的Gossip[28,29]協(xié)議,且支持TLS 加密通信.Corda 采用了AMQP1.0[30]協(xié)議,且支持TLS 加密通信.Quorum 分別采用以太坊P2P 協(xié)議和HTTPS 協(xié)議傳輸公有交易和私用交易.

1.2 共識層

比特幣采用PoW 共識機(jī)制是為了適應(yīng)其節(jié)點(diǎn)身份匿名、自由進(jìn)出、數(shù)目眾多等公有鏈特性[31],但其帶來的消耗計算資源、交易未最終確認(rèn)、交易吞吐量受限等問題,則是企業(yè)級區(qū)塊鏈所無法接受的.企業(yè)級區(qū)塊鏈主要采用PBFT 共識機(jī)制,在PBFT 共識過程中,有兩個階段需要傳輸?shù)木W(wǎng)絡(luò)消息數(shù)為O(n2),其造成了很大的網(wǎng)絡(luò)開銷；另外,PBFT 共識假設(shè)網(wǎng)絡(luò)中共識節(jié)點(diǎn)數(shù)目是靜態(tài)不變的,這就影響到了共識服務(wù)的可擴(kuò)展性.因此,企業(yè)級區(qū)塊鏈通常實(shí)現(xiàn)的是各種改進(jìn)的PBFT 共識機(jī)制.

Kwon 等人[11]提出了Tendermint,在基于PBFT 按節(jié)點(diǎn)計票的基礎(chǔ)上,對每張投票分配了不同的權(quán)重,重要節(jié)點(diǎn)的投票可分配較高的權(quán)重,若投票權(quán)重超過總數(shù)2/3,即認(rèn)為達(dá)成共識.僅通過少數(shù)重要節(jié)點(diǎn)達(dá)成共識,會顯著減少網(wǎng)絡(luò)中廣播的消息數(shù)；在基于數(shù)字貨幣的應(yīng)用中,權(quán)重也可對應(yīng)為用戶的持幣量,從而實(shí)現(xiàn)類似權(quán)益證明的共識機(jī)制.Iroha 采用基于鏈復(fù)制的共識機(jī)制Sumeragi,其源自于Duan 等人[32]提出的BChain 共識.BChain 將網(wǎng)絡(luò)節(jié)點(diǎn)按信譽(yù)由高到低組織成邏輯上的鏈?zhǔn)浇Y(jié)構(gòu),交易依照節(jié)點(diǎn)的鏈接順序線性地進(jìn)行傳播.假設(shè)節(jié)點(diǎn)總數(shù)為3f+1,正常情況下只需鏈中前2f+1 的節(jié)點(diǎn)參與共識.僅當(dāng)前2f+1 的節(jié)點(diǎn)出現(xiàn)錯誤,才需要剩余f個節(jié)點(diǎn)參與共識.BChain 減少了網(wǎng)絡(luò)中廣播的消息數(shù),但增加了傳播延遲和節(jié)點(diǎn)出錯后的恢復(fù)時間.Aublin 等人[12]提出了RBFT,多臺共識主機(jī)上并行運(yùn)行著多組PBFT 共識,每組的主節(jié)點(diǎn)都位于不同的主機(jī).多組共識同時對請求進(jìn)行排序,但僅有一組提交數(shù)據(jù),若該組出現(xiàn)錯誤而性能降低時,則可迅速切換至其他組來提交數(shù)據(jù).Chain Core 使用的共識機(jī)制為Federated Consensus(https://chain.com/docs/1.2/protocol/papers/whitepaper),其假設(shè)創(chuàng)建區(qū)塊的主節(jié)點(diǎn)是固定的、不作惡的、不宕機(jī)的,從而減少了共識中廣播的消息數(shù)目.MultiChain 模擬了PoW 共識機(jī)制,其預(yù)先設(shè)定多個可信節(jié)點(diǎn),若某節(jié)點(diǎn)等待系統(tǒng)設(shè)定的隨機(jī)時間率先到達(dá),就可創(chuàng)建區(qū)塊.為了保證出塊節(jié)點(diǎn)的多樣性,還可靈活配置節(jié)點(diǎn)需等待多少連續(xù)區(qū)塊后才可創(chuàng)建下一區(qū)塊,MultiChain 的共識機(jī)制也存在著分叉帶來的交易沒有最終確認(rèn)的問題.Ripple 提出了僅由可信驗(yàn)證節(jié)點(diǎn)投票的共識機(jī)制RPCA(ripple protocol consensus algorithm)[18],在n≥5f+1 的條件下,解決了拜占庭將軍問題.此外,在假設(shè)節(jié)點(diǎn)不會作惡的前提下,很多平臺還提供了吞吐量相對較高、實(shí)現(xiàn)相對簡單的Raft 共識機(jī)制.Fabric 提供了單節(jié)點(diǎn)的Solo(供開發(fā)使用)、高吞吐量的Apache Kafka[33]和基于PBFT 的BFT-SMaRt[34]這3 種共識服務(wù).Corda 提供了高信任場景下的單節(jié)點(diǎn)Notary[13]服務(wù),為了實(shí)現(xiàn)分布式的Notary 服務(wù),還提供基于Raft 的Copycat(http://atomix.io)和基于PBFT 的BFT-SMaRt分布式共識.Quorum 提供了基于Raft 的etcd(https://github.com/coreos/etcd)和基于PBFT 的Istanbul BFT(https://github.com/ethereum/EIPs/issues/650)共識服務(wù).

1.3 數(shù)據(jù)層

區(qū)塊鏈系統(tǒng)通常將一批交易打包進(jìn)區(qū)塊,然后以區(qū)塊為單位對這些交易進(jìn)行共識、存儲及執(zhí)行.以區(qū)塊為單位組織交易數(shù)據(jù),并以區(qū)塊哈希作為指針將孤立的區(qū)塊按時間順序鏈接在一起,一方面保證了交易數(shù)據(jù)的不可篡改性,另一方面也實(shí)現(xiàn)了交易數(shù)據(jù)的可追溯性[35].區(qū)塊鏈數(shù)據(jù)模型可分為基于交易的模型和基于賬戶的模型[36]:基于交易的模型也被稱為UTXO 模型,其每筆交易由表明交易來源的輸入和表明交易去向的輸出組成,所有交易通過輸入與輸出鏈接在一起,使得每一筆交易都可追溯,避免了偽造與雙花(double spending)問題,更適于支持?jǐn)?shù)字資產(chǎn)；基于賬戶的模型維護(hù)著賬戶各屬性的當(dāng)前狀態(tài),通過執(zhí)行交易來不斷更新賬戶數(shù)據(jù),更適于支持智能合約.區(qū)塊鏈實(shí)現(xiàn)了交易數(shù)據(jù)按時間順序的追溯,UTXO 模型則實(shí)現(xiàn)了交易數(shù)據(jù)按交易順序的追溯.Fabric,Quorum 是基于賬戶模型的,其采用區(qū)塊鏈來組織交易數(shù)據(jù)；Corda 是基于交易模型的,其采用UTXO 模型來組織交易數(shù)據(jù).在數(shù)據(jù)存儲上,Fabric,Quorum 為了實(shí)現(xiàn)基于哈希的快速檢索,選用了健值數(shù)據(jù)庫LevelDB,Fabric 還支持CouchDB[37]數(shù)據(jù)庫；Corda 考慮與企業(yè)已有系統(tǒng)的整合,選用了通用的關(guān)系數(shù)據(jù)庫.此外,業(yè)界提出一些用圖來組織交易數(shù)據(jù)的方案.IOTA(http://iota.org)平臺提出了使用DAG(directed acyclic graph)來組織交易的方案Tangle[38],每個交易需至少鏈接之前的兩個交易(即包含兩個交易的哈希)以表示確認(rèn)了這兩個交易.Swirlds(https://www.swirlds.com)平臺提出使用Hashgraph[39]來組織交易的方案,其依靠節(jié)點(diǎn)間的Gossip 通信歷史構(gòu)造了基于交易的哈希有向無循環(huán)圖.

1.4 智能合約層

1994 年,Szabo 提出了智能合約[40],其被定義為一套以數(shù)字形式定義的承諾,包括合約參與方執(zhí)行這些承諾所需的協(xié)議,其初衷是將智能合約內(nèi)置到物理實(shí)體,以創(chuàng)造各種靈活可控的智能資產(chǎn).智能合約最初并未受到廣泛關(guān)注,直到以太坊將智能合約應(yīng)用于區(qū)塊鏈系統(tǒng),使得區(qū)塊鏈可以處理數(shù)字貨幣之外更為復(fù)雜的應(yīng)用.智能合約是一種用程序來編制的數(shù)字合約條款,部署在區(qū)塊鏈上且可按照規(guī)則自動執(zhí)行.區(qū)塊鏈實(shí)現(xiàn)了去中心化的存儲,智能合約作為運(yùn)行在區(qū)塊鏈上的商業(yè)邏輯,實(shí)現(xiàn)了去中心化的計算.智能合約可以是簡單的狀態(tài)數(shù)據(jù)修改、交易合規(guī)驗(yàn)證,也可以是依據(jù)商業(yè)合約及外部事件的復(fù)雜交易邏輯.為了保證在任意節(jié)點(diǎn)上智能合約的執(zhí)行結(jié)果始終一致,智能合約通常運(yùn)行在沙箱環(huán)境中.Fabric 智能合約運(yùn)行在Docker 容器,支持Go,Node.js 和Java 語言.Corda 智能合約運(yùn)行在JVM(Java virtual machine),支持Kotlin 和Java 語言.Quorum 智能合約運(yùn)行在EVM(ethereum virtual machine),支持Solidity 語言.Chain Core 的智能合約運(yùn)行在CVM(Chain virtual machine),支持Ivy 語言.Sawtooth 提出了交易家族(transaction family)的概念,其支持Go,JavaScript,Python 等多種常用的編程語言,限定僅能執(zhí)行特定的業(yè)務(wù)操作.Sawtooth 也整合了EVM,以支持由Solidity 編寫的智能合約.

1.5 應(yīng)用層

應(yīng)用層通過調(diào)用智能合約,并依據(jù)合約中定義的規(guī)則執(zhí)行交易.Fabric 主要面向通用行業(yè),其應(yīng)用可基于Go,Java,Python,Node.js 等多種語言的SDK 構(gòu)建,并通過gPRC 與運(yùn)行在Fabric 節(jié)點(diǎn)上的智能合約進(jìn)行通信[41].Corda 主要面向受監(jiān)管的金融行業(yè),其應(yīng)用被稱為CorDapp(Corda distributed application)[13],可基于Kotlin 和Java 語言構(gòu)建.CorDapp 主要由狀態(tài)對象、智能合約和Flow[13]構(gòu)成,Flow 定義了交易流程,在Flow 執(zhí)行過程中,需驗(yàn)證交易的狀態(tài)對象符合智能合約定義的約束后,才簽名并提交交易.Quorum 主要面向金融行業(yè),與以太坊應(yīng)用一致,其應(yīng)用被稱為Dapp(decentralized application).Dapp 是由JavaScript 構(gòu)建的Web 前端應(yīng)用,通過JSONRPC 與運(yùn)行在Quorum 節(jié)點(diǎn)上的智能合約進(jìn)行通信[42].

2 交易流程

區(qū)塊主要包含的是交易數(shù)據(jù),智能合約主要處理的也是交易數(shù)據(jù),交易是區(qū)塊鏈中存儲和執(zhí)行的基本邏輯單元.完整的交易流程可動態(tài)展示出區(qū)塊鏈系統(tǒng)內(nèi)部各組件間是如何協(xié)作的.本節(jié)分別介紹Fabric,Corda 和Quorum 的交易流程.

2.1 Fabric交易流程

Fabric 著重于模塊化的架構(gòu)設(shè)計,把系統(tǒng)分為了背書節(jié)點(diǎn)(endorsing peer)、排序服務(wù)(ordering service)和提交節(jié)點(diǎn)(committing peer)[43]:背書節(jié)點(diǎn)主要執(zhí)行智能合約,排序服務(wù)主要執(zhí)行共識以對交易排序并生成區(qū)塊,提交節(jié)點(diǎn)主要持久化區(qū)塊數(shù)據(jù)和狀態(tài)數(shù)據(jù).模塊化設(shè)計實(shí)現(xiàn)了側(cè)重于計算的合約執(zhí)行、側(cè)重于通信的網(wǎng)絡(luò)共識和側(cè)重于I/O 的區(qū)塊存儲等各模塊間的相互解耦,使得各種服務(wù)均可獨(dú)立的橫向擴(kuò)展.如圖2 所示,Fabric 執(zhí)行交易的完整流程如下.

(1)客戶端對新的交易數(shù)據(jù)簽名并發(fā)送到一至多個背書節(jié)點(diǎn)；

(2)背書節(jié)點(diǎn)以交易數(shù)據(jù)為輸入執(zhí)行智能合約并生成讀寫集(readset,writeset)；

(3)背書節(jié)點(diǎn)對讀寫集進(jìn)行簽名并返回至客戶端；

(4)客戶端收集讀寫集,驗(yàn)證符合背書策略(endorsement policy)后將其廣播至排序服務(wù)；

(5)排序服務(wù)基于共識機(jī)制對多筆交易的讀寫集排序并將其打包成區(qū)塊；

(6)排序服務(wù)將區(qū)塊傳播至提交節(jié)點(diǎn)；

(7)提交節(jié)點(diǎn)對從排序服務(wù)收到的區(qū)塊中的讀寫集進(jìn)行背書策略驗(yàn)證和讀集(readset)版本驗(yàn)證,驗(yàn)證通過后,將區(qū)塊追加至區(qū)塊鏈,并將寫集(writeset)寫入狀態(tài)數(shù)據(jù)庫.

傳統(tǒng)區(qū)塊鏈平臺采用的是的先排序、后執(zhí)行的主動復(fù)制(active replication)模型[44],如果智能合約中含有非確定性(non-determinism)代碼[45],就會造成節(jié)點(diǎn)間的數(shù)據(jù)不一致從而發(fā)生分叉.Fabric 提供的是一種先執(zhí)行、后排序、再驗(yàn)證的系統(tǒng)架構(gòu),這實(shí)際上是一種結(jié)合被動復(fù)制(passive replication)[46]與主動復(fù)制的混合模型.如果多個背書節(jié)點(diǎn)返回的合約執(zhí)行結(jié)果不一致,Fabric 可在數(shù)據(jù)寫入之前就識別出非確定性,從而避免了不一致數(shù)據(jù)的寫入.不同于傳統(tǒng)區(qū)塊鏈的智能合約串行運(yùn)行在全部節(jié)點(diǎn),Fabric 智能合約可并行運(yùn)行在不同的背書節(jié)點(diǎn),從而提高了系統(tǒng)交易吞吐量[47].同時,隨著背書節(jié)點(diǎn)數(shù)目的動態(tài)增加,系統(tǒng)內(nèi)可并行運(yùn)行的合約數(shù)目也將隨之增加,從而實(shí)現(xiàn)了一定的可擴(kuò)展性.從本質(zhì)上來講,傳統(tǒng)區(qū)塊鏈?zhǔn)菍⒔灰讛?shù)據(jù)傳播到所有節(jié)點(diǎn),并通過在所有節(jié)點(diǎn)上執(zhí)行而達(dá)到狀態(tài)一致.Fabric 僅在部分可信的背書節(jié)點(diǎn)上執(zhí)行交易,然后將執(zhí)行結(jié)果傳播到所有節(jié)點(diǎn)從而達(dá)到狀態(tài)一致.

Fig.2 Transaction flow in Hyperledger Fabric圖2 Hyperledger Fabric 交易流程

2.2 Corda交易流程

Corda 著重服務(wù)于受監(jiān)管的金融行業(yè),其強(qiáng)調(diào)交易數(shù)據(jù)僅對交易雙方及監(jiān)管可見.基于P2P 協(xié)議廣播交易數(shù)據(jù)難于控制數(shù)據(jù)的傳播范圍,所以Corda 交易都是直接被傳送至指定目的節(jié)點(diǎn),Corda 網(wǎng)絡(luò)中的共識服務(wù)則主要由Notary 實(shí)現(xiàn).如圖3 所示,Corda 執(zhí)行交易的完整流程如下.

(1)發(fā)送者創(chuàng)建交易并簽名；

(2)發(fā)送者發(fā)送交易數(shù)據(jù)及簽名至接收者；

(3)接收者驗(yàn)證交易數(shù)據(jù)及發(fā)送者簽名無誤,就附加上接收者簽名；

(4)接收者發(fā)送交易數(shù)據(jù)及交易雙方簽名至Notary 共識服務(wù)；

(5)Notary 驗(yàn)證交易數(shù)據(jù)及交易雙方簽名無誤,就附加上Notary 簽名；

(6)Notary 返回交易數(shù)據(jù)至接收者；

(7)接收者核對Notary 簽名無誤后提交交易；

(8)接收者返回交易數(shù)據(jù)至發(fā)送者；

(9)發(fā)送者核對接收者及Notary 簽名無誤后提交交易.

Fig.3 Transaction flow in Corda圖3 Corda 交易流程

在驗(yàn)證交易時,除了驗(yàn)證交易涉及的各方簽名是否正確,交易雙方主要驗(yàn)證交易數(shù)據(jù)是否符合智能合約中的約束條件,Notary 則主要檢查交易是否涉及雙花.圖3 的流程可以用Corda 的Flow 來定義,Flow 針對節(jié)點(diǎn)間的多輪交互,隱藏了網(wǎng)絡(luò)、I/O 與并發(fā)等編程細(xì)節(jié),支持用領(lǐng)域?qū)Ｓ谜Z言(domain specific language,簡稱DSL)實(shí)現(xiàn)工作流編程.

2.3 Quorum交易流程

Quorum 擴(kuò)展以太坊公有鏈,并加入了企業(yè)級區(qū)塊鏈的特性.Quorum 交易分為公有交易和私有交易:公有交易是全網(wǎng)共享的傳統(tǒng)以太坊交易,私有交易僅在交易雙方共享.

Quorum 系統(tǒng)主要由Quorum 節(jié)點(diǎn)和Constellation 構(gòu)成:Quorum 節(jié)點(diǎn)基于以太坊Go 版本(go-ethereum)構(gòu)建,主要用于執(zhí)行合約及維護(hù)區(qū)塊鏈與狀態(tài)數(shù)據(jù),狀態(tài)數(shù)據(jù)分為存儲公有交易執(zhí)行結(jié)果的公有狀態(tài)數(shù)據(jù)和存儲私有交易執(zhí)行結(jié)果的私有狀態(tài)數(shù)據(jù)；Constellation 主要實(shí)現(xiàn)私有交易數(shù)據(jù)的加密、解密、存儲及點(diǎn)對點(diǎn)傳輸.Quorum 公有交易的執(zhí)行流程與以太坊類似,圖4 主要描述了私有交易的執(zhí)行流程.

(1)客戶端發(fā)送私有交易到Quorum 節(jié)點(diǎn),并在交易中直接指明每個接收者的公鑰；

(2)Quorum 節(jié)點(diǎn)將私有交易傳送至對應(yīng)的Constellation 進(jìn)行加密；

(3)Constellation 生成一個對稱秘鑰,先用該對稱秘鑰加密私有交易負(fù)載(payload),再分別用每個接收者的公鑰分別加密該對稱秘鑰,最后還要基于私有交易的加密負(fù)載計算其哈希值；

(4)Constellation 將私有交易的加密負(fù)載、私有交易的加密負(fù)載的哈希值、加密后的對稱秘鑰分別點(diǎn)對點(diǎn)的傳播至每個交易接收方的Constellation；

(5)數(shù)據(jù)傳播成功后,Constellation 將私有交易的加密負(fù)載的哈希值返回至對應(yīng)的Quorum 節(jié)點(diǎn)；

(6)Quorum 節(jié)點(diǎn)將私有交易的加密負(fù)載的哈希值打包為一個以太坊交易,經(jīng)以太坊P2P 協(xié)議廣播至所有Quorum 節(jié)點(diǎn)；

(7)該以太坊交易經(jīng)過共識被打包進(jìn)Quorum 區(qū)塊.當(dāng)每個Quorum 節(jié)點(diǎn)執(zhí)行該以太坊交易時,需要基于該以太坊交易的負(fù)載(即私有交易加密負(fù)載的哈希值)向?qū)?yīng)的Constellation 請求原始的私有交易負(fù)載；

(8)根據(jù)Quorum 節(jié)點(diǎn)的請求,各個交易接收方的Constellation 基于自己的私鑰、公鑰加密的對稱秘鑰、對稱秘鑰加密的私有交易負(fù)載解密出原始的私有交易負(fù)載；

(9)交易接收方的Constellation 將原始的私有交易負(fù)載返回至對應(yīng)的Quorum 節(jié)點(diǎn).非交易接收方的Constellation 沒有接收過加密的私有交易負(fù)載,其向Quorum 節(jié)點(diǎn)返回的是“NotARecipient”消息；

(10)交易涉及的每個Quorum 節(jié)點(diǎn)將私有交易提交至智能合約運(yùn)行,智能合約會將執(zhí)行私有交易時生成的狀態(tài)數(shù)據(jù)存儲至私有狀態(tài)數(shù)據(jù)庫.

Fig.4 Transaction flow in Quorum圖4 Quorum 交易流程

以太坊經(jīng)歷了全球范圍應(yīng)用考驗(yàn)且有強(qiáng)大的開發(fā)社區(qū)支持,基于以太坊構(gòu)建的Quorum 具有著先天的技術(shù)優(yōu)勢.Quorum 智能合約及Dapp 開發(fā)與以太坊基本一致,因而以太坊中的智能合約和Dapp 可輕松移植到Quorum,Quorum 也可直接使用以太坊生態(tài)下的集成開發(fā)工具和開發(fā)框架.Quorum 以最小化修改go-etnereum并保留與以太坊的兼容性和互操作性為原則,以便及時跟隨go-ethereum 的版本變化,并促成以太坊最新技術(shù)在企業(yè)區(qū)塊鏈中的應(yīng)用.

3 區(qū)塊鏈網(wǎng)絡(luò)

企業(yè)級區(qū)塊鏈必須提供節(jié)點(diǎn)準(zhǔn)入機(jī)制,使得每個節(jié)點(diǎn)經(jīng)過授權(quán)才可加入網(wǎng)絡(luò).因不適宜采用傳統(tǒng)中心化的準(zhǔn)入機(jī)制,目前主要依靠數(shù)字證書來識別每個節(jié)點(diǎn),依靠數(shù)字簽名來鑒別每次操作.公有鏈網(wǎng)絡(luò)節(jié)點(diǎn)的身份是匿名的,因而需要在網(wǎng)絡(luò)中將交易數(shù)據(jù)廣播至所有節(jié)點(diǎn),一方面保證在接收節(jié)點(diǎn)地址未知的情況下,交易數(shù)據(jù)仍能被傳送到指定的接收方；另一方面,通過在每個節(jié)點(diǎn)接收并驗(yàn)證每筆交易,也阻止了雙花的可能[48].在企業(yè)級區(qū)塊鏈網(wǎng)絡(luò)中,節(jié)點(diǎn)身份是已知的,并且需要控制數(shù)據(jù)的傳播范圍,所以其傳播協(xié)議有著不同于公有鏈的設(shè)計.

3.1 準(zhǔn)入機(jī)制

Fabric 節(jié)點(diǎn)中的MSP(membership service provider)模塊負(fù)責(zé)身份管理,主要完成數(shù)字證書驗(yàn)證、簽名與驗(yàn)證、私鑰管理等功能[49].Fabric 網(wǎng)絡(luò)的各類節(jié)點(diǎn)(背書/提交節(jié)點(diǎn)、排序節(jié)點(diǎn)、客戶端)由X.509 數(shù)字證書表示其身份,也針對組織、管理員、普通用戶生成相應(yīng)的數(shù)字證書.普通用戶一般發(fā)起與應(yīng)用有關(guān)的商業(yè)交易,管理員則發(fā)起與系統(tǒng)相關(guān)的配置交易.一個組織代表一個機(jī)構(gòu),其下可包括背書/提交節(jié)點(diǎn)、管理員及普通用戶.組織的證書是自簽名的根證書,組織內(nèi)的實(shí)體將該證書作為證書根.智能合約可依據(jù)調(diào)用者的數(shù)字證書、MSP ID 及其屬性字段實(shí)現(xiàn)多種級別的訪問控制.Hyperledger 還提供了獨(dú)立的 Fabric-CA 項(xiàng)目(https://github.com/hyperledger/fabric-ca),其可作為root CA 和intermediate CA 為Fabric 項(xiàng)目生成和撤銷數(shù)字證書.

Corda 許可服務(wù)被稱為doorman[13],Corda 節(jié)點(diǎn)需要基于節(jié)點(diǎn)信息向doorman 申請到根證書機(jī)構(gòu)簽名的TLS證書,才能加入到對應(yīng)的Corda 網(wǎng)絡(luò).為了控制交易數(shù)據(jù)的傳播范圍,交易發(fā)送者需在發(fā)送的消息中直接指定接收者地址.為了便于獲取接收者地址,Corda 網(wǎng)絡(luò)提供了包含節(jié)點(diǎn)地址、節(jié)點(diǎn)證書和節(jié)點(diǎn)服務(wù)等節(jié)點(diǎn)信息的網(wǎng)絡(luò)地圖(network map)服務(wù)[13].每個節(jié)點(diǎn)向網(wǎng)絡(luò)地圖服務(wù)上傳簽名的本節(jié)點(diǎn)信息,并周期地下載已簽名的其他節(jié)點(diǎn)信息.任何節(jié)點(diǎn)都可提供網(wǎng)絡(luò)地圖服務(wù),從而實(shí)現(xiàn)了網(wǎng)絡(luò)地圖服務(wù)的去中心化.

Quorum 擴(kuò)展了以太坊P2P 層,保證只有被授權(quán)的節(jié)點(diǎn)才可加入.Quorum 在每個節(jié)點(diǎn)都設(shè)置一個JSON 配置文件,其定義了所有被授權(quán)的網(wǎng)絡(luò)節(jié)點(diǎn).如果要添加或移除節(jié)點(diǎn),就需要修改所有節(jié)點(diǎn)的配置文件.為了實(shí)現(xiàn)節(jié)點(diǎn)的動態(tài)添加和移除,Quorum 計劃基于智能合約實(shí)現(xiàn)節(jié)點(diǎn)準(zhǔn)入機(jī)制.

3.2 網(wǎng)絡(luò)協(xié)議

Gossip 協(xié)議的去中心化、可容錯、最終一致性等特性非常適合于區(qū)塊鏈網(wǎng)絡(luò),相對于全網(wǎng)廣播協(xié)議,隨機(jī)選取節(jié)點(diǎn)廣播消息的Goosip 協(xié)議減少了網(wǎng)絡(luò)負(fù)載和攻擊面.Fabric 網(wǎng)絡(luò)采用Gossip 協(xié)議保證了節(jié)點(diǎn)間傳輸消息的一致性,Gossip 協(xié)議在Fabric 主要實(shí)現(xiàn)的任務(wù)是:

(1)每個節(jié)點(diǎn)持續(xù)傳播alive 消息,以使系統(tǒng)及時發(fā)現(xiàn)出新的節(jié)點(diǎn)并監(jiān)測離線節(jié)點(diǎn)；

(2)為了減少與共識服務(wù)間的通信,每個組織選取一個主節(jié)點(diǎn)先從共識服務(wù)拉取區(qū)塊數(shù)據(jù),然后再將區(qū)塊廣播至組織內(nèi)的其他節(jié)點(diǎn)；

(3)缺失區(qū)塊的節(jié)點(diǎn)以點(diǎn)對點(diǎn)方式從其他節(jié)點(diǎn)同步區(qū)塊數(shù)據(jù).

Fabric 的Gossip 協(xié)議基于gRPC 構(gòu)建,并可利用TLS 實(shí)現(xiàn)加密的數(shù)據(jù)傳輸.

為了保證交易數(shù)據(jù)僅對相關(guān)參與者可見,Corda 沒有使用類似Gossip 協(xié)議的廣播通信,而是基于AMQP1.0協(xié)議實(shí)現(xiàn)了點(diǎn)對點(diǎn)的直接通信.AMQP1.0 協(xié)議報文是二進(jìn)制的,相對于REST 的文本格式報文,其傳輸效率更高.Corda 基于AMQP1.0 協(xié)議并利用TLS 實(shí)現(xiàn)了加密通信.

Quorum 采用go-ethereum 的P2P 傳輸層在Quorum 節(jié)點(diǎn)間傳播公有交易；Quorum 在私有交易中指明了接收者的公鑰,所以Constellation 直接將私有交易經(jīng)HTTPS 發(fā)送至接收者的Constellation,沒有參與私有交易的節(jié)點(diǎn)不會接收到交易.為了實(shí)現(xiàn)更高的區(qū)塊傳輸效率,Quorum 采用etcd Raft 的HTTP 傳輸層傳播區(qū)塊數(shù)據(jù).

4 共識機(jī)制

為了實(shí)現(xiàn)完全的去中心化,比特幣、以太坊采用了PoW 共識機(jī)制,雖然網(wǎng)絡(luò)節(jié)點(diǎn)總數(shù)可以達(dá)到數(shù)以萬計,但是交易吞吐量非常低.另外,為了防止分叉帶來的雙花問題,交易提交一定時間后才可確認(rèn),但理論上所有交易并未得到最終確認(rèn)[50],這顯然無法適用于對交易結(jié)果有著嚴(yán)格確定性要求的企業(yè)級應(yīng)用,尤其是金融行業(yè)應(yīng)用.企業(yè)級區(qū)塊鏈對交易吞吐量有著較高的要求,同時,其網(wǎng)絡(luò)節(jié)點(diǎn)相對較少且規(guī)模基本穩(wěn)定,因而更適合采用基于投票的BFT(Byzantine fault-tolerant)[51,52]共識算法.企業(yè)級區(qū)塊鏈節(jié)點(diǎn)身份通常是實(shí)名的,并且具有一定的可信性,為了提高整個系統(tǒng)的吞吐量,還可以采用僅容忍宕機(jī)錯誤的CFT(crash fault-tolerant)[7,53]共識算法.

傳統(tǒng)的區(qū)塊鏈節(jié)點(diǎn)既需要執(zhí)行共識協(xié)議又需要執(zhí)行智能合約.Fabric 采用了合約執(zhí)行、共識排序、驗(yàn)證寫入相互解耦的系統(tǒng)架構(gòu),保證了各功能節(jié)點(diǎn)獨(dú)立地進(jìn)行擴(kuò)展.因?yàn)楣沧R服務(wù)不用執(zhí)行交易和存儲交易,即無需關(guān)心交易的具體內(nèi)容,因而無狀態(tài)的共識服務(wù)更易插件化[54].Fabric 提供了開發(fā)者使用的Solo、高吞吐量的Kafka和基于PBFT 的BFT-SmaRt 這3 種共識服務(wù)[55].

Corda 依靠Notary 服務(wù)防止雙花,避免產(chǎn)生沖突的交易.每筆交易提交前必須獲得Notary 服務(wù)的簽名,以證明交易的每個輸入狀態(tài)所引用的資產(chǎn)都是未被花費(fèi)的.Corda 提供了高信任場景下的單節(jié)點(diǎn)Notary、基于Raft的Copycat 和基于PBFT 的BFT-SmaRt 這3 種類型的共識服務(wù).Corda 網(wǎng)絡(luò)可同時部署多種Notray 服務(wù),各個Notary 服務(wù)可并行運(yùn)行,用戶可根據(jù)具體應(yīng)用場景選擇相應(yīng)的服務(wù).

Quorum 沒有沿用以太坊的PoW 共識機(jī)制.Quorum 同時維護(hù)著公有狀態(tài)數(shù)據(jù)和私有狀態(tài)數(shù)據(jù):公有狀態(tài)數(shù)據(jù)需要在全網(wǎng)所有節(jié)點(diǎn)間達(dá)成共識,私有狀態(tài)數(shù)據(jù)僅需在交易參與者間達(dá)成共識.基于這些前提,Quorum 提供了基于Raft 的etcd 和基于PBFT 的Istanbul BFT 這兩種共識服務(wù).Quorum 也實(shí)現(xiàn)了基于PoS 的QuorumChain共識服務(wù),但在Quorum2.0 中已被舍棄.

4.1 BFT-SMaRt

近年來,針對BFT 的理論研究取得了重要進(jìn)展,基于這些研究實(shí)現(xiàn)了一些原型系統(tǒng),但很少被部署到真實(shí)系統(tǒng)中.業(yè)界成熟可用的產(chǎn)品相對較少,因?yàn)閷?shí)現(xiàn)實(shí)用的BFT 共識具有相當(dāng)難度.里斯本大學(xué)基于Java 的開源項(xiàng)目BFT-SMaRt 則是一個較為成熟的系統(tǒng),其基于BFT 共識實(shí)現(xiàn)了SMR(state machine replication),主要特性如下.

(1)簡潔性.著重協(xié)議正確性而避免限于瑣碎的優(yōu)化細(xì)節(jié)(如采用Java 語言而非C++)；

(2)模塊化.基于模塊化設(shè)計將系統(tǒng)劃分為SMR 模塊(Mod-SMaRT)、狀態(tài)同步(state transfer)、配置模塊(reconfig)等；

(3)可配置.既可配置BFT 共識節(jié)點(diǎn)的動態(tài)加入和退出,又可配置采用BFT 共識還是CFT 共識；

(4)可擴(kuò)展.基于插件擴(kuò)展系統(tǒng)功能；

(5)多核感知.基于多核運(yùn)行開銷較高的計算任務(wù)(如簽名驗(yàn)證)；

(6)高性能.在4 個節(jié)點(diǎn)構(gòu)成的局域網(wǎng)中,交易吞吐量達(dá)到了80000TPS.

為了適應(yīng)于廣域網(wǎng),Fabric 還參考了WHEAT[56].WHEAT 是針對共識節(jié)點(diǎn)分布在廣域網(wǎng)時的BFT-SMaRT改進(jìn)版本,其主要在假設(shè)執(zhí)行(tentative execution)和投票分配模式(voting assignment schemes)方面做了優(yōu)化.假設(shè)執(zhí)行是假設(shè)在PBFT 共識的prepare 階段后系統(tǒng)不會出現(xiàn)異常,而在prepare 階段就提交請求,并讓commit 階段異步執(zhí)行；若commit 階段發(fā)生主節(jié)點(diǎn)更換,則回滾先前的執(zhí)行結(jié)果.投票分配模式是給廣域網(wǎng)中較快的共識節(jié)點(diǎn)分配較高的投票權(quán)重,以實(shí)現(xiàn)基于更少的節(jié)點(diǎn)更快的達(dá)成共識.

4.2 Notary

Corda 交易需要達(dá)成有效性共識和唯一性共識.

· 有效性共識需交易涉及的每個參與者都確認(rèn)交易數(shù)據(jù)有效.為了達(dá)成有效性共識,既要檢查交易是否符合每個輸入狀態(tài)和輸出狀態(tài)所引用的合約的約束條件,又要檢查相應(yīng)參與者的簽名是否齊全.Corda 沒有全局統(tǒng)一總賬,每個節(jié)點(diǎn)一致性地存儲著與自己業(yè)務(wù)相關(guān)的交易數(shù)據(jù),所以為了確保發(fā)送者提供的交易是來源是可靠的,就需針對每個輸入狀態(tài)沿著UTXO 模型一直回溯至最初的發(fā)行交易,以從其他節(jié)點(diǎn)獲取到當(dāng)前交易涉及的所有歷史交易,并驗(yàn)證每筆交易都是有效的；

· 唯一性共識需Notary 服務(wù)確認(rèn)交易的每個輸入狀態(tài)所引用的輸出狀態(tài)都未被花費(fèi)過,以阻止雙花發(fā)生.如果一筆交易的每個輸入狀態(tài)所引用的資產(chǎn)都未被花費(fèi),Notary 就會對該交易簽名,并將相關(guān)信息記錄在 Notary 內(nèi)的一個 Map 中.Map 的 key 記錄了上筆被花費(fèi)交易的哈希與輸出狀態(tài)索引(txID,outputIndex),value 記錄了當(dāng)前被Notary 簽名的交易的哈希、輸入狀態(tài)索引及請求節(jié)點(diǎn)地址(txID,inputIndex,requestingPeer).Notary 基于Map 中由其簽名過的所有已花費(fèi)交易,可快速驗(yàn)證一筆交易是否涉及雙花.在檢查一筆交易時,交易的所有輸入狀態(tài)必須指向同一Notary 節(jié)點(diǎn),否則就需將所有狀態(tài)先遷移到同一 Notary 節(jié)點(diǎn),其避免了在 Notary 服務(wù)中涉及兩階段提交.如果不涉及數(shù)據(jù)隱私,Notary 服務(wù)也可以運(yùn)行有效性共識.由于Notary 節(jié)點(diǎn)可以訪問每筆交易的輸入狀態(tài),在參與者互不信任且沒有可信第三方的場景中,Notary 由哪方維護(hù)將會成為問題.

4.3 Istanbul BFT

以太坊支持的共識算法有基于PoW 的Ethash[57]和基于PoA 的Clique[58].為了在以太坊引入PBFT 共識,AMIS(http://am.is)公司發(fā)布了基于Go 語言的開源項(xiàng)目Istanbul BFT.Istanbul BFT 根據(jù)PBFT 實(shí)現(xiàn)了專門適用于以太坊的共識模塊,其主要特性如下.

(1)每個節(jié)點(diǎn)都會將其在PBFT 共識收到的2f+1 條commit 簽名消息寫在區(qū)塊頭部的擴(kuò)展字段,使得每個區(qū)塊在共識上都是自驗(yàn)證的；

(2)基于投票實(shí)現(xiàn)了共識節(jié)點(diǎn)的動態(tài)加入或退出；

(3)利用backlog 緩存失序的消息,避免了重傳；

(4)已接收到2f+1 條commit 消息的節(jié)點(diǎn),即使未接收全2f+1 條prepare 消息,也可提前進(jìn)入commit 階段；

(5)所有節(jié)點(diǎn)間可以基于Gossip 協(xié)議建立間接連接,而不需要建立一對一的直接連接.

5 區(qū)塊鏈數(shù)據(jù)

區(qū)塊鏈在數(shù)據(jù)結(jié)構(gòu)上是以區(qū)塊為結(jié)點(diǎn)的鏈表,每個區(qū)塊中主要包含交易數(shù)據(jù)、前塊哈希及元數(shù)據(jù).區(qū)塊中的交易數(shù)據(jù)是前一區(qū)塊創(chuàng)建后到當(dāng)前區(qū)塊創(chuàng)建時,系統(tǒng)中發(fā)起的所有交易.針對每個區(qū)塊都可計算出一個哈希值,其被稱為區(qū)塊哈希或區(qū)塊ID.通過在區(qū)塊中包含前一區(qū)塊的哈希,即可以前塊哈希為指針,把各個孤立的區(qū)塊鏈接起來.元數(shù)據(jù)主要包含了區(qū)塊創(chuàng)建時的時間戳、塊內(nèi)交易數(shù)據(jù)哈希計算得出的Merkle 根[59]等數(shù)據(jù).以區(qū)塊鏈組織交易,實(shí)現(xiàn)了交易數(shù)據(jù)的不可篡改性和可追溯性.為了支持智能合約的運(yùn)行以及展現(xiàn)交易數(shù)據(jù)的執(zhí)行結(jié)果,區(qū)塊鏈系統(tǒng)通常提供了狀態(tài)數(shù)據(jù)庫.為了支持基于區(qū)塊高度、區(qū)塊哈希的區(qū)塊數(shù)據(jù)檢索及基于交易哈希的交易數(shù)據(jù)檢索,區(qū)塊鏈系統(tǒng)還提供了索引數(shù)據(jù)庫.

5.1 Fabric區(qū)塊鏈數(shù)據(jù)

Fabric 區(qū)塊中的交易主要由讀寫集表示,讀寫集由背書節(jié)點(diǎn)依據(jù)交易數(shù)據(jù)執(zhí)行智能合約后生成:讀集表示執(zhí)行該筆交易所需讀出的數(shù)據(jù)集,每項(xiàng)讀是一個健及其版本號(key,ver)；寫集表示存儲交易執(zhí)行結(jié)果所需寫入的數(shù)據(jù)集,每項(xiàng)寫是一個健及其新值(key,val).每次寫入前,只有基于MVCC(multiversion concurrency control)驗(yàn)證讀集數(shù)據(jù)版本與狀態(tài)數(shù)據(jù)庫當(dāng)前數(shù)據(jù)版本一致,才會將寫集寫入數(shù)據(jù)庫.Fabric 實(shí)際上實(shí)現(xiàn)的是基于樂觀鎖的并發(fā)控制.為了方便新塊的追加操作,Fabric 區(qū)塊鏈數(shù)據(jù)以日志文件的方式進(jìn)行存儲.如圖5 所示:Fabric 除了支持狀態(tài)數(shù)據(jù)庫、區(qū)塊索引庫外,還提供了歷史索引庫,實(shí)現(xiàn)了基于主健的歷史狀態(tài)數(shù)據(jù)查詢.Fabric 支持插件化的數(shù)據(jù)訪問,底層數(shù)據(jù)庫可選用LevelDB 或CouchDB.基于數(shù)據(jù)庫產(chǎn)品自身特性,LevelDB 支持主健查詢、復(fù)合主鍵查詢、主健范圍查詢與主健歷史查詢.CouchDB 除了支持以上查詢,還支持富查詢及分頁.

Fabric 區(qū)塊鏈中除了包含交易數(shù)據(jù)的數(shù)據(jù)區(qū)塊外,還有包含配置數(shù)據(jù)的配置區(qū)塊,配置區(qū)塊主要包含了區(qū)塊鏈中所有節(jié)點(diǎn)的數(shù)字證書、共識服務(wù)地址、區(qū)塊切分依據(jù)等系統(tǒng)配置參數(shù).每條Fabric 區(qū)塊鏈的創(chuàng)世區(qū)塊就是一個配置區(qū)塊,如果需要增加anchor 節(jié)點(diǎn)、調(diào)整區(qū)塊尺寸等,就需要發(fā)送配置修改交易,經(jīng)共識生成新的配置區(qū)塊,再傳播至其他節(jié)點(diǎn)以使其接受新的配置信息.

Fig.5 Blockchain data of Hyperledger Fabric圖5 Hyperledger Fabric 區(qū)塊鏈數(shù)據(jù)

5.2 Corda分布式賬本

Corda 沒有使用區(qū)塊鏈組織交易數(shù)據(jù).Corda 強(qiáng)調(diào)自己是受區(qū)塊鏈系統(tǒng)啟發(fā)的分布式賬本,摒棄了區(qū)塊鏈系統(tǒng)中不適合金融場景的設(shè)計元素.Corda 認(rèn)為區(qū)塊是PoW 共識分?jǐn)偼诘V開銷的產(chǎn)物,以區(qū)塊為單位提交交易會延遲交易的執(zhí)行及增加端到端的延時,并不適合交易及時產(chǎn)生及時提交的金融業(yè)務(wù)場景.因?yàn)橹饕?wù)于數(shù)據(jù)可見范圍嚴(yán)格受限的金融領(lǐng)域,Corda 系統(tǒng)沒有維護(hù)一個全局賬本,每個節(jié)點(diǎn)通過數(shù)據(jù)庫一致性地維護(hù)與自己業(yè)務(wù)相關(guān)的當(dāng)前和歷史狀態(tài)數(shù)據(jù),該數(shù)據(jù)庫被稱為Vault[13].Corda 采用UTXO 模型,一個交易包含一到多個輸入狀態(tài)和一到多個輸出狀態(tài),輸入狀態(tài)源自之前某筆交易的輸出狀態(tài),執(zhí)行交易就是花費(fèi)之前交易中的一批輸出狀態(tài),并生成一批新的輸出狀態(tài).被花費(fèi)的狀態(tài)成為合約的歷史狀態(tài),新的輸出狀態(tài)則成為了合約的當(dāng)前狀態(tài).

如圖6 所示:交易n包含3 個輸入狀態(tài)和2 個輸出狀態(tài),表示分別向2 個賬戶轉(zhuǎn)了70 美元和50 美元,其中有80 美元來自于交易m,另外的10 美元和30 美元分別來自于其他交易.每個輸入狀態(tài)通過交易哈希和輸出狀態(tài)索引(txHash,outputIndex)兩個屬性作為引用,指明自己花費(fèi)的是哪筆交易中的哪個輸出狀態(tài).輸入狀態(tài)按交易執(zhí)行順序把各個交易鏈接起來構(gòu)成交易鏈,每筆交易可一直向前追溯至源頭的原始發(fā)行交易(即交易不包含輸入狀態(tài)),向后可追蹤至尚未花費(fèi)的交易(即沒有任何交易的輸入狀態(tài)指向該交易的輸出狀態(tài)).一個交易中被花費(fèi)過的輸出狀態(tài)不能被再次花費(fèi),否則即被認(rèn)為是雙花,即至少有兩筆交易的輸入狀態(tài)指向了同一交易的同一輸出狀態(tài).與比特幣的UTXO 模型相比,Corda 的UTXO 模型不但支持?jǐn)?shù)字貨幣轉(zhuǎn)賬,還支持用戶定義的通用數(shù)字資產(chǎn)的流轉(zhuǎn).Corda 交易還包含命令(command)、附件、時間窗口(time window)等內(nèi)容,命令指明了交易類型(如轉(zhuǎn)賬、借貸),還提供了一個公鑰列表,列出了需要對交易進(jìn)行簽名的各個交易者的公鑰.附件是執(zhí)行交易所需的一些數(shù)據(jù)文件,交易基于文件哈希來訪問這些文件.時間窗口限定了交易執(zhí)行的時間段.Corda 還提供了Oracle[13]服務(wù),其作為權(quán)威機(jī)構(gòu)提供了交易所需的一些外部信息(如股價、匯率),Oracle 提供的外部信息主要被嵌在交易的命令或附件中.

Fig.6 Transaction and state of Corda圖6 Corda 的交易與狀態(tài)

輸入狀態(tài)實(shí)質(zhì)上是輸出狀態(tài)的引用,所以Corda 中的狀態(tài)通常是指輸出狀態(tài).輸出狀態(tài)包含狀態(tài)屬性、合約引用和參與者列表.狀態(tài)屬性定義了執(zhí)行交易時所涉及的各項(xiàng)狀態(tài)數(shù)據(jù),其可表達(dá)任意的業(yè)務(wù)對象(如股票、債券).合約引用定義了用于驗(yàn)證交易的智能合約的地址,參與者列表定義了該狀態(tài)涉及的交易參與者.為了保留每筆交易的原始事實(shí),Corda 中的狀態(tài)對象是不可變的(immutable),以反映合約各個階段的真實(shí)狀態(tài).執(zhí)行交易并沒有直接修改賬本中的狀態(tài)數(shù)據(jù),實(shí)際上是將該狀態(tài)標(biāo)記成為歷史狀態(tài)(即已花費(fèi)),并創(chuàng)建新的狀態(tài)以反映修改后的當(dāng)前狀態(tài),所有歷史狀態(tài)與當(dāng)前狀態(tài)構(gòu)成的序列展現(xiàn)了完整的業(yè)務(wù)事實(shí),這非常適合于注重原始單據(jù)合法合規(guī)性的金融行業(yè).在基于賬戶的模型中,對同一賬戶的所有修改操作都要串行執(zhí)行；UTXO 模型中的每個輸出狀態(tài)是獨(dú)立且不可變的,花費(fèi)一個輸出狀態(tài)不會影響其他輸出狀態(tài),因而多筆交易可并行執(zhí)行.

Corda 底層采用通用關(guān)系數(shù)據(jù)庫(缺省是H2 數(shù)據(jù)庫)存儲交易數(shù)據(jù)和狀態(tài)數(shù)據(jù),可實(shí)現(xiàn)Corda 賬本與企業(yè)內(nèi)部信息系統(tǒng)在數(shù)據(jù)庫層面上的無縫整合,避免了跨系統(tǒng)匯總查詢引起的數(shù)據(jù)遷移、核對及同步.Corda 支持基于JPA(Java persistence architecture)的數(shù)據(jù)持久化,可實(shí)現(xiàn)復(fù)雜的SQL 查詢及與鏈下數(shù)據(jù)的連接查詢.傳統(tǒng)區(qū)塊鏈系統(tǒng)節(jié)點(diǎn)丟失數(shù)據(jù)時,主要從其他對等節(jié)點(diǎn)同步缺失的區(qū)塊來恢復(fù)數(shù)據(jù),但Corda 主要利用底層關(guān)系數(shù)據(jù)庫的容災(zāi)備份機(jī)制來恢復(fù)丟失的數(shù)據(jù).

5.3 Quorum區(qū)塊鏈數(shù)據(jù)

以太坊所有交易數(shù)據(jù)存儲在區(qū)塊鏈上,每個交易數(shù)據(jù)的執(zhí)行結(jié)果存儲在狀態(tài)數(shù)據(jù)庫,區(qū)塊鏈與狀態(tài)數(shù)據(jù)庫都構(gòu)建在LevelDB 數(shù)據(jù)庫上,任何人都可以訪問所有交易數(shù)據(jù)和狀態(tài)數(shù)據(jù),以太坊數(shù)據(jù)的全網(wǎng)可見性顯然無法滿足企業(yè)級區(qū)塊鏈的實(shí)際需求.因此,Quorum 將系統(tǒng)中的交易分為公有交易和私有交易,以對其采用不同的交易流程和存儲.相對于公有交易,私有交易加入了一個可選參數(shù)privateFor,它包含了多個接收者公鑰的列表,指明了該私有交易應(yīng)該只發(fā)送給那些接收者.圖7 描述了Quorum 區(qū)塊鏈數(shù)據(jù)的組織方式.

Fig.7 Blockchain data of Quorum圖7 Quorum 區(qū)塊鏈數(shù)據(jù)

Quorum 區(qū)塊中存儲的是公有交易以及私有交易負(fù)載被加密后的哈希值,其既保護(hù)了私有交易隱私,又實(shí)現(xiàn)了私有交易和公有交易參與統(tǒng)一的共識.私有交易數(shù)據(jù)存儲在鏈外(off-chain),也就是Constellation.私有交易在智能合約中的執(zhí)行結(jié)果存儲在Quorum 節(jié)點(diǎn)的私有狀態(tài)數(shù)據(jù)庫中.Quorum 節(jié)點(diǎn)包括公有狀態(tài)數(shù)據(jù)和私有狀態(tài)數(shù)據(jù),所以其需要同時維護(hù)公有狀態(tài)Merkle Patricia 樹和私有狀態(tài)Merkle Patricia 樹.所有節(jié)點(diǎn)都可訪問的數(shù)據(jù)是公有狀態(tài)數(shù)據(jù)和交易數(shù)據(jù)哈希,所以Quorum 區(qū)塊的驗(yàn)證工作主要檢驗(yàn)公有狀態(tài)Merkle Patricia 樹根和交易Merkle Patricia 樹根.

6 智能合約

區(qū)塊鏈在互不信任的多方間實(shí)現(xiàn)了數(shù)據(jù)的可信共享,運(yùn)行在區(qū)塊鏈上的智能合約則在互不信任的多方間實(shí)現(xiàn)了商業(yè)邏輯的可信執(zhí)行.智能合約是運(yùn)行在區(qū)塊鏈上的程序代碼,同時執(zhí)行在多個區(qū)塊鏈節(jié)點(diǎn)上,任何參與者都無法強(qiáng)行將其停止.智能合約定義了交易規(guī)則,外部應(yīng)用通過調(diào)用智能合約來執(zhí)行各種交易及訪問區(qū)塊鏈數(shù)據(jù).交易數(shù)據(jù)被記錄在區(qū)塊鏈,合約執(zhí)行結(jié)果則被記錄在狀態(tài)數(shù)據(jù)庫.

6.1 合約模型

Fabric 智能合約被稱為Chaincode,其主要用于執(zhí)行交易和訪問狀態(tài)數(shù)據(jù).編寫合約就是實(shí)現(xiàn)Chaincode 接口中的Init和Invoke函數(shù),以執(zhí)行狀態(tài)初始化和讀寫狀態(tài)數(shù)據(jù).Chaincode 運(yùn)行在背書節(jié)點(diǎn),但不同于傳統(tǒng)區(qū)塊鏈,Chaincode 無需在所有的背書節(jié)點(diǎn)上運(yùn)行.在部署Chaincode 時,可依據(jù)背書策略讓Chaincode 運(yùn)行在部分指定的背書節(jié)點(diǎn).背書策略定義了執(zhí)行Chaincode 所需的背書節(jié)點(diǎn)數(shù)量及組合(如一個Chaincode 至少要被n個背書節(jié)點(diǎn)中的任意k個節(jié)點(diǎn)執(zhí)行并簽名),用戶可根據(jù)不同應(yīng)用所需的信任模型,靈活地定義背書策略.在可信環(huán)境下,執(zhí)行Chaincode 背書節(jié)點(diǎn)的數(shù)目越少,系統(tǒng)資源會被占用得越少,也會越快收集全執(zhí)行結(jié)果；空閑的背書節(jié)點(diǎn)可同時執(zhí)行其他Chaincode,從而實(shí)現(xiàn)了Fabric 智能合約的并行執(zhí)行.另外,指定Chaincode 僅在可信節(jié)點(diǎn)上部署運(yùn)行,可避免合約邏輯與交易數(shù)據(jù)在不可信節(jié)點(diǎn)上的傳播與泄露.

Corda 交易包含多個輸入/輸出狀態(tài),每個狀態(tài)都有一個引用指向一個智能合約,執(zhí)行交易時,需要執(zhí)行交易中每個狀態(tài)所引用的合約.為了支持金融行業(yè)嚴(yán)格的審計需求,Corda 智能合約主要驗(yàn)證交易數(shù)據(jù),以保證其符合各項(xiàng)約束條件.編寫Corda 合約就是實(shí)現(xiàn)Contract 接口中的verify函數(shù),verify函數(shù)以交易數(shù)據(jù)為輸入,定義了具體的驗(yàn)證規(guī)則,如果不符合規(guī)則就拋出異常.Corda 的合約是無狀態(tài)的,其不負(fù)責(zé)存儲任何數(shù)據(jù),而由Flow 在共識達(dá)成后才將數(shù)據(jù)存儲在交易雙方的節(jié)點(diǎn).為了保證業(yè)務(wù)合法合規(guī),Corda 智能合約有一個哈希引用指向了該合約所依據(jù)的原始法律文檔,以作為處理糾紛時的法律依據(jù).

Quorum 智能合約分為公有合約和私有合約,它們在編程實(shí)現(xiàn)上并無分別:公有合約運(yùn)行在所有節(jié)點(diǎn),以公有交易數(shù)據(jù)為輸入,將執(zhí)行結(jié)果存儲在公有狀態(tài)數(shù)據(jù)庫；私有合約僅運(yùn)行在與交易相關(guān)的參與者節(jié)點(diǎn),以私有交易數(shù)據(jù)為輸入,將執(zhí)行結(jié)果存儲在私有狀態(tài)數(shù)據(jù)庫.因?yàn)樗接袪顟B(tài)數(shù)據(jù)的訪問限制,Quorum 公有合約不能調(diào)用私有合約.私有合約可以調(diào)用公有合約,但僅允許執(zhí)行讀操作,不能執(zhí)行寫操作.Quorum 沿用了以太坊的智能合約模型,但以太坊執(zhí)行合約按Gas[60]計費(fèi)的設(shè)計顯然并不適用于企業(yè)級區(qū)塊鏈.為了避免長時間運(yùn)行的合約阻塞整個系統(tǒng),Quorum 平臺執(zhí)行合約仍然消耗Gas,只是將Gas 的價格(gasPrice)設(shè)置為0,從而繞過了Gas 計費(fèi)的問題.

6.2 沙箱環(huán)境

智能合約不能直接運(yùn)行在區(qū)塊鏈節(jié)點(diǎn)上.因?yàn)橐环矫嬉ＷC在不同節(jié)點(diǎn)的軟硬件環(huán)境下,合約執(zhí)行結(jié)果始終是確定的；另一方面,合約中若含有漏洞或惡意代碼,要保證不會影響其他合約的執(zhí)行及區(qū)塊鏈節(jié)點(diǎn)的安全.所以智能合約必須運(yùn)行在沙箱環(huán)境中.目前,沙箱主要分為虛擬機(jī)和容器兩類,都是為了保證合約代碼在沙箱中執(zhí)行時,對合約使用的資源進(jìn)行限制和隔離.

Fabric 使用輕量級的Docker 容器作為沙箱,其基于Docker 的隔離性和安全性,保護(hù)了宿主機(jī)不受容器內(nèi)惡意合約的攻擊,也防止了容器之間的相互影響.Chaincode 可基于Go,Node.js 和Java 開發(fā),這些語言不但圖靈完備,編譯技術(shù)成熟,也減輕了合約編程者的學(xué)習(xí)門檻.Fabric 智能合約的執(zhí)行結(jié)果可能是不確定的,因?yàn)槠錄]有限制使用編程語言中一些非確定性的特性.Fabric 依據(jù)背書策略收集并比較多個背書節(jié)點(diǎn)的合約執(zhí)行結(jié)果,從而避免了不一致數(shù)據(jù)的提交.

為了保證合約執(zhí)行結(jié)果的確定性,Corda 采用一個修訂版的JVM 作為沙箱,限制引用編程語言中一些非確定性特性.同時,對合約生成的字節(jié)碼做了靜態(tài)分析和重寫,限制合約運(yùn)行時間過長及使用內(nèi)存過多.Corda 合約可基于Kotlin 和Java 開發(fā),并基于Kotlin 和Java 定義了領(lǐng)域?qū)Ｓ谜Z言,使得智能合約編寫更為簡潔和高效,也提高了合約代碼的可讀性.

Quorum 沿用了以太坊自定義的EVM 作為沙箱,運(yùn)行以太坊自定義的字節(jié)碼,這些字節(jié)碼不能訪問EVM 宿主機(jī)的網(wǎng)絡(luò)系統(tǒng)、文件系統(tǒng)和其他進(jìn)程,合約之間也只有有限的調(diào)用.Quorum 合約需基于以太坊自定義的Solidity 語言開發(fā),之所以創(chuàng)建新的開發(fā)語言,就是為了保證合約執(zhí)行結(jié)果的確定性.Solidity 雖是一個執(zhí)行結(jié)果完全確定的編程語言,但對企業(yè)應(yīng)用開發(fā)者而言,學(xué)習(xí)新的語言需要一個過程,且Solidity 對復(fù)雜數(shù)據(jù)結(jié)構(gòu)支持有限,各種功能的函數(shù)庫也并不完備,因而實(shí)現(xiàn)智能合約受到一定的限制.

7 隱私保護(hù)

比特幣、以太坊的每個節(jié)點(diǎn)全量存儲著全部交易數(shù)據(jù),每個用戶可見證任何用戶的交易歷史.這種全網(wǎng)存儲與全網(wǎng)見證雖保證了數(shù)據(jù)的可靠性,但卻犧牲了數(shù)據(jù)隱私性.企業(yè)級區(qū)塊鏈的用戶主要是商業(yè)機(jī)構(gòu),交易數(shù)據(jù)是其重要資產(chǎn)和商業(yè)機(jī)密,隱私保護(hù)是必須具備的特性.

7.1 通 道

為了確保數(shù)據(jù)的隱私性,Fabric 提出了通道(channel)[61]的方案,圖2 中的交易流程就是在一個通道內(nèi)實(shí)現(xiàn)的.多個參與者可自發(fā)組建一個通道,每個通道擁有一條專有的區(qū)塊鏈,通道內(nèi)的所有交易數(shù)據(jù)存儲在內(nèi)部的鏈上,只有通道內(nèi)的節(jié)點(diǎn)才可訪問鏈上的數(shù)據(jù),沒有加入通道的節(jié)點(diǎn)將無權(quán)訪問.Fabric 通過將交易分配到相互隔離的多條區(qū)塊鏈上,實(shí)現(xiàn)了私密的交易,保障了數(shù)據(jù)的隱私性.通道實(shí)際上是一種基于多鏈的數(shù)據(jù)分區(qū),一個節(jié)點(diǎn)根據(jù)交易需求可加入多條通道,多個通道內(nèi)的交易可并行地執(zhí)行.相對于單鏈的方案,其提高了全網(wǎng)的交易吞吐量.如果有n個交易者,每個交易者都需和其他n-1 個交易者進(jìn)行僅涉及雙方的私密交易,那么Fabric 就需建立n(n-1)/2 個通道及區(qū)塊鏈,此時,通道的開銷就會給系統(tǒng)造成很大壓力.Fabric 智能合約目前僅支持跨通道的查詢操作,實(shí)現(xiàn)跨通道的修改操作需要在業(yè)務(wù)層實(shí)現(xiàn).此外,如果交易者需要統(tǒng)計所有通道中的交易數(shù)據(jù),也會相當(dāng)繁瑣.

7.2 Flow

Corda 基于Flow 用代碼定義了多個參與者間的交易流程,實(shí)現(xiàn)了無中心節(jié)點(diǎn)控制的交易流程自動化.Flow中的交易僅在交易參與者間共享與執(zhí)行,交易數(shù)據(jù)被點(diǎn)對點(diǎn)地直接發(fā)送到指定的接收者.一筆交易在流程中需在多個節(jié)點(diǎn)間進(jìn)行多輪通信,每個節(jié)點(diǎn)還需進(jìn)行驗(yàn)證和簽名,用傳統(tǒng)編程方法實(shí)現(xiàn)整個流程會比較困難,而Flow封裝了網(wǎng)絡(luò)與簽名等編程細(xì)節(jié),提供了簡潔的工作流編程接口.Flow 是基于纖程(fiber)實(shí)現(xiàn)的,當(dāng)?shù)却渌?jié)點(diǎn)的消息時,Flow 的當(dāng)前堆棧會被掛起并被序列化到底層的數(shù)據(jù)庫,以釋放占有的系統(tǒng)資源；當(dāng)其他節(jié)點(diǎn)的消息到達(dá)時,被掛起的Flow 會被喚醒并恢復(fù)堆棧,從而可從中斷處繼續(xù)執(zhí)行.阻塞的Flow 并不占用內(nèi)存資源,因而可實(shí)現(xiàn)更高的Flow 并發(fā)度.Flow 的纖程基于Quasar 庫構(gòu)建,Flow 代碼實(shí)質(zhì)上是一個運(yùn)行在纖程中的異步可持久化狀態(tài)機(jī).多條Flow 可并行執(zhí)行,每個參與者也可同時執(zhí)行多個Flow,從而提高了系統(tǒng)的交易吞吐量.

為了實(shí)現(xiàn)完善的隱私保護(hù),Corda 還采用了其他技術(shù):首先,在每次交易中使用隨機(jī)公鑰隱藏了交易雙方的真實(shí)身份；其次,為了減少交易數(shù)據(jù)的泄露,在對交易進(jìn)行簽名時,Corda 利用Tear-offs 技術(shù)實(shí)現(xiàn)了對簽名者僅展示交易的部分?jǐn)?shù)據(jù)(例如,Notary 服務(wù)僅能訪問交易的輸入狀態(tài),Oracle 服務(wù)僅能訪問交易的命令部分),而不展示交易的全部數(shù)據(jù).Tear-offs 將一個交易的各組成部分的哈希值作為Merkle 樹的葉子結(jié)點(diǎn),并依照Merkle 樹定義計算出Merkle 根(即交易ID),當(dāng)Notary 需要對交易簽名時,可僅展示輸入狀態(tài)及其到根結(jié)點(diǎn)路徑上的各直接分支結(jié)點(diǎn),從而隱藏該交易的其他部分內(nèi)容(如輸出狀態(tài)、命令和時間窗口等).

7.3 Constellation

為了實(shí)現(xiàn)隱私保護(hù),Quorum 平臺針對公有交易和私有交易分別使用了不同的交易流程和狀態(tài)數(shù)據(jù)庫,其中,私有交易的加解密、存儲及點(diǎn)對點(diǎn)傳輸都是依靠Constellation 來實(shí)現(xiàn)的.如圖7 所示,Constellation 主要包含交易管理(transaction manager)和Enclave 兩個模塊.

· 交易管理主要實(shí)現(xiàn)了私有交易的鏈外存儲、基于加密負(fù)載哈希的私有交易負(fù)載訪問、點(diǎn)對點(diǎn)的傳輸私有交易的加密負(fù)載至指定接收者；

· Enclave 負(fù)責(zé)私有交易負(fù)載的加解密,其加密私有交易負(fù)載的流程為:(1)接收交易管理發(fā)送的私有交易并驗(yàn)證交易發(fā)送者的簽名；(2)生成對稱秘鑰；(3)使用對稱秘鑰加密私有交易負(fù)載；(4)計算私有交易加密負(fù)載的哈希；(5)逐一使用每個交易接收者的公鑰加密對稱秘鑰；(6)返回加密的私有交易負(fù)載、加密的私有交易負(fù)載的哈希、被加密的對稱秘鑰到交易管理.解密私有交易負(fù)載的流程與之相反,流程中使用對稱秘鑰是為了解決非對稱秘鑰加解密效率低的問題.Enclave 還負(fù)責(zé)管理私鑰,實(shí)際上是一個與其他模塊隔離的虛擬HSM.

通過依靠Constellation 進(jìn)行私有交易數(shù)據(jù)管理,沒有參與私有交易的節(jié)點(diǎn)不接收私有交易、不存儲私有交易、不執(zhí)行私有交易,其僅能訪問到私有交易負(fù)載被加密后的哈希值.

8 研究挑戰(zhàn)與趨勢

企業(yè)級區(qū)塊鏈引起了以金融行業(yè)為主的眾多企業(yè)機(jī)構(gòu)的關(guān)注.當(dāng)應(yīng)用于實(shí)際業(yè)務(wù)時,企業(yè)級區(qū)塊鏈目前在諸多方面尚存在問題.為了解決這些問題,未來需要在以下幾個方面進(jìn)行更深入的研究.

(1)吞吐量

目前,依據(jù)各方獨(dú)立提供的數(shù)據(jù),Fabric 的交易吞吐量約為 3500TPS[43],Corda 的交易提供吞吐量約為1000TPS[62],Quorum 的交易吞吐量約為100TPS[16],與比特幣(7TPS)、以太坊(15TPS)相比已有相當(dāng)改善,但與傳統(tǒng)的數(shù)據(jù)庫系統(tǒng)相比,仍有著不小的差距.區(qū)塊鏈系統(tǒng)雖不涉及復(fù)雜的事務(wù)處理,但是其以區(qū)塊為單位提交交易、每筆交易涉及的多方簽名與驗(yàn)證、基于BFT 的共識機(jī)制、串行執(zhí)行的智能合約等都會限制其吞吐量.另外,在實(shí)際部署應(yīng)用時,不同的策略與配置也會影響吞吐量.以Fabric 為例,并行運(yùn)行的通道數(shù)目、通道內(nèi)并行運(yùn)行的背書節(jié)點(diǎn)數(shù)目、區(qū)塊內(nèi)多筆交易修改同一狀態(tài)的寫沖突程度、底層數(shù)據(jù)庫用LevelDB 還是CouchDB、每個區(qū)塊包含的交易數(shù)目(缺省為10)及出塊間隔(缺省為2s)都會影響系統(tǒng)吞吐量.因此,無論從系統(tǒng)架構(gòu)設(shè)計還是從實(shí)際部署維護(hù),企業(yè)級區(qū)塊鏈在吞吐量方面尚需更多的研究.

(2)共識機(jī)制

首先,作為區(qū)塊鏈系統(tǒng)的核心引擎,共識機(jī)制目前仍是整個系統(tǒng)性能的關(guān)鍵瓶頸.當(dāng)前,許多區(qū)塊鏈平臺聲稱提出了高性能的共識機(jī)制,但這些共識并沒給出前提假設(shè)、數(shù)學(xué)模型和形式化證明,其安全性無法衡量.能夠在安全與性能間取得最佳權(quán)衡的共識機(jī)制,仍是最迫切的研究工作.其次,企業(yè)級區(qū)塊鏈平臺未必要自己實(shí)現(xiàn)共識機(jī)制,完全可以采用通用的解決方案,如Fabric 和Corda 采用了BFT-SMaRt,Burrow 和Cosmos 采用了Tendermint.因此,通用的BFT 與CFT 共識框架將會是未來的一個研究方向.最后,因?yàn)闆]有one-size-fits-all 的共識機(jī)制[63],同一共識在不同的安全假設(shè)與可信場景下會展現(xiàn)出不同的性能.所以企業(yè)級區(qū)塊鏈平臺必須支持插件化、可配置的共識服務(wù),以靈活支持從局域網(wǎng)到廣域網(wǎng)、從BFT 到CFT 不同場景下的多種共識.

(3)可擴(kuò)展性

比特幣、以太坊采用的是全網(wǎng)共享一條區(qū)塊鏈的單鏈方案,每個節(jié)點(diǎn)需處理、存儲全網(wǎng)的所有交易,整個區(qū)塊鏈系統(tǒng)能力實(shí)際上受限于單個節(jié)點(diǎn)的處理能力.企業(yè)級區(qū)塊鏈的每個節(jié)點(diǎn)通常僅處理、存儲與自己業(yè)務(wù)相關(guān)的交易數(shù)據(jù),使其更易于支持可擴(kuò)展性[64].為了實(shí)現(xiàn)可擴(kuò)展性,Fabric 采用了多通道(multichannel)的數(shù)據(jù)分區(qū)方案,使得多通道(即多鏈)間可獨(dú)立并行地處理交易.在同一通道內(nèi),Fabric 多個合約可并行運(yùn)行在不同的背書節(jié)點(diǎn),通過增加背書節(jié)點(diǎn),就可增加并行運(yùn)行的智能合約數(shù)目.Corda 可通過增加節(jié)點(diǎn)數(shù)來提高整個網(wǎng)絡(luò)的Flow并發(fā)度,其也支持多個Notray 服務(wù)集群的并行運(yùn)行.從整體上來講,與通過增加節(jié)點(diǎn)數(shù)而線性提高系統(tǒng)吞吐量和容量的橫向擴(kuò)展性目標(biāo)相比,企業(yè)級區(qū)塊鏈尚有很大的差距.因此,如何更高效靈活地實(shí)現(xiàn)可擴(kuò)展性,將是研究的熱點(diǎn).

(4)隱私保護(hù)

區(qū)塊鏈隱私保護(hù)的難點(diǎn)在于既需隱藏交易細(xì)節(jié),又需驗(yàn)證交易的有效性.目前,Fabric,Corda 與Quorum 提供的隱私保護(hù)方案都有著一定的局限性:Fabric 通道面臨著僅兩個交易者也需建立通道所帶來的開銷問題以及排序服務(wù)可讀取所有通道交易數(shù)據(jù)的問題；Corda 處理每筆交易前都需驗(yàn)證從當(dāng)前交易到發(fā)行交易之間的全部歷史交易,存在著交易驗(yàn)證流程低效及歷史交易數(shù)據(jù)泄露的問題；Quorum 私有狀態(tài)數(shù)據(jù)無法被非交易者節(jié)點(diǎn)讀取見證,因而無法解決跨私有合約交易時的雙花問題.因此,各平臺都在積極研究更為完善的隱私保護(hù)方案.Fabric為了進(jìn)一步在通道內(nèi)實(shí)現(xiàn)細(xì)粒度的隱私保護(hù),其PDC(private data collection)方案將狀態(tài)數(shù)據(jù)庫分為公有狀態(tài)數(shù)據(jù)庫和私有狀態(tài)數(shù)據(jù)庫(SideDB),私有交易數(shù)據(jù)僅在通道內(nèi)部分指定的節(jié)點(diǎn)間傳輸,排序服務(wù)處理的是私有交易的讀寫集的哈希值,區(qū)塊鏈存儲的也是私有交易的讀寫集的哈希值,私有交易的寫集被寫入到了隔離的私有狀態(tài)數(shù)據(jù)庫,公有狀態(tài)數(shù)據(jù)庫存儲的是私有狀態(tài)數(shù)據(jù)健值的哈希.Intel SGX 基于CPU 提供了可信內(nèi)存空間enclave,任何惡意軟件甚至操作系統(tǒng)都無法訪問和影響enclave 內(nèi)部的敏感代碼和數(shù)據(jù).Corda 采用Intel SGX 技術(shù)實(shí)現(xiàn)了加密交易在enclave 內(nèi)的解密與驗(yàn)證,使得處理每筆交易時的歷史交易驗(yàn)證都在enclave 內(nèi)完成,從而避免了歷史交易數(shù)據(jù)的泄露.零知識證明(zero-knowledge proof)可以讓證明者在不透漏任何有用信息的前提下,使驗(yàn)證者相信某個論斷的正確性.Quorum 基于非交互的零知識證明zk-SNARKs[65,66]構(gòu)建了零知識安全層(zero knowledge security layer)[67],在不泄露發(fā)送方、接收方和交易金額的前提下,基于交易數(shù)據(jù)生成的零知識證明,使得全網(wǎng)均可驗(yàn)證交易的有效性.為了提供一個將企業(yè)級區(qū)塊鏈和可信計算環(huán)境TEE(trusted execution environment)高度集成的基礎(chǔ)平臺,微軟提出了Coco 框架(confidential consortium blockchain framework)[68],其保證了運(yùn)行于TEE 內(nèi)的區(qū)塊鏈代碼和數(shù)據(jù)的機(jī)密性和完整性,提高了部署在Coco 框架上的區(qū)塊鏈平臺的隱私性.目前,與其合作的企業(yè)級區(qū)塊鏈平臺有Corda,Quorum 與Hyperledger Sawtooth.此外,基于同態(tài)映射實(shí)現(xiàn)加密數(shù)據(jù)運(yùn)算的同態(tài)加密(homomorphic encryption)[69]和實(shí)現(xiàn)智能合約中私密信息處理的Hawk[70]也都引起了業(yè)界的關(guān)注.

(5)跨 鏈

如同Intranet 網(wǎng)絡(luò)之間需要互聯(lián)互通,企業(yè)級區(qū)塊鏈網(wǎng)絡(luò)間也需要互聯(lián)互通.目前較有影響力的跨鏈技術(shù)是Polkadot[71],Cosmos[72]和Hyperledger Quilt(https://github.com/hyperledger/quilt).Polkadot 的主干網(wǎng)絡(luò)被稱為中繼鏈(relay chain),其以以太坊為主實(shí)現(xiàn)了與各種平行鏈(parachain)的互聯(lián),每個平行鏈就是一個單獨(dú)的區(qū)塊鏈網(wǎng)絡(luò).Polkadot 還以其他公有鏈為升級目標(biāo),最終讓以太坊可直接與任何鏈進(jìn)行互聯(lián).Cosmos 把不同種類的區(qū)塊鏈子網(wǎng)看做Zone,通過主干網(wǎng)絡(luò)Cosmos Hub 上運(yùn)行的IBC(inter-blockchain communication)協(xié)議,實(shí)現(xiàn)不同Zone之間的互聯(lián).Hyperledger Quilt 是ILP 協(xié)議的Java 實(shí)現(xiàn),ILP 是無需中介的跨賬本支付協(xié)議,其實(shí)現(xiàn)了不同數(shù)字資產(chǎn)賬本間的自動路由與原子支付操作.Polkadot 專注于實(shí)現(xiàn)通用的跨鏈通信,Cosmos 專注于實(shí)現(xiàn)跨鏈的數(shù)字資產(chǎn)交易,Hyperledger Quilt 則專注于實(shí)現(xiàn)跨鏈的支付操作.各類企業(yè)級區(qū)塊鏈平臺無論在系統(tǒng)整體架構(gòu)還是在交易數(shù)據(jù)格式上都存在著很大差別,這些都加大了跨鏈技術(shù)的研究難度.

(6)評測系統(tǒng)

基準(zhǔn)評測系統(tǒng)可幫助使用者對比各區(qū)塊鏈平臺,以選擇適合自己需求的平臺；也可幫助系統(tǒng)設(shè)計者識別出系統(tǒng)缺陷以進(jìn)行改進(jìn).Dinh 等人[73]開發(fā)了專用于評測企業(yè)級區(qū)塊鏈的開源評測框架Blockbench(https://github.com/ooibc88/blockbench),其將區(qū)塊鏈平臺分為共識層、數(shù)據(jù)模型層、智能合約執(zhí)行層和應(yīng)用層,提供了整體性能評估的宏觀評測基準(zhǔn)和分層性能評估的微觀評測基準(zhǔn),具體可從吞吐量、延遲、可擴(kuò)展性、容錯性和安全性這5 個維度進(jìn)行評測,目前支持對Fabric,Ethereum 和Parity(https://www.parity.io)的評測.Hyperledger Caliper(https://github.com/hyperledger/caliper)是主要由華為開發(fā)的區(qū)塊鏈開源測評工具,其通過可插拔的適配層來集成不同區(qū)塊鏈平臺,目前支持對Fabric,Sawtooth 和Iroha 的評測.Hyperledger Caliper 基于一組預(yù)定義用例,從吞吐量、延遲和資源利用率這3 個維度進(jìn)行評測.在評測區(qū)塊鏈平臺多個維度的指標(biāo)中,以交易吞吐量為代表的性能評測最受關(guān)注.對不同區(qū)塊鏈平臺而言,網(wǎng)絡(luò)節(jié)點(diǎn)數(shù)目不同、共識機(jī)制容錯類型不同、交易模型及尺寸不同、智能合約功能復(fù)雜度不同、測試用例不同等,都直接影響著其所能展示出來的性能.這就要求評測系統(tǒng)不僅要基于多個維度指標(biāo)進(jìn)行綜合評估,還要對區(qū)塊鏈平臺內(nèi)在的系統(tǒng)架構(gòu)、交易流程、應(yīng)用領(lǐng)域等方面有著深入的理解.為了實(shí)現(xiàn)更為客觀、公平的評測,也非常需要制定可被行業(yè)所廣泛接受的通用評測基準(zhǔn).

(7)底層數(shù)據(jù)庫

不同于以數(shù)字貨幣業(yè)務(wù)為主的公有鏈,企業(yè)級應(yīng)用通常涉及復(fù)雜的統(tǒng)計查詢與分析.由表3 可知,目前,企業(yè)級區(qū)塊鏈底層數(shù)據(jù)庫大多是NoSQL 數(shù)據(jù)庫,其主要支持的是Key-Value 查詢.但現(xiàn)有的技術(shù)人員更熟悉SQL 查詢,現(xiàn)有的數(shù)據(jù)分析工具更多基于SQL 構(gòu)建,如同支持Hadoop 的SQL 查詢工具Hive、支持HBase 的SQL 查詢工具Phoenix,目前迫切需要支持企業(yè)級區(qū)塊鏈的SQL 查詢工具.比特幣、以太坊等公有鏈底層都采用了LevelDB 單機(jī)數(shù)據(jù)庫,這是因?yàn)檩p量級LevelDB 數(shù)據(jù)庫所需配置較低,可運(yùn)行在更多常規(guī)計算能力的節(jié)點(diǎn)上,從而更易實(shí)現(xiàn)公有鏈去中心化的理念.節(jié)點(diǎn)數(shù)目有限的企業(yè)級區(qū)塊鏈?zhǔn)聦?shí)上是弱中心化的,其更需要支持高吞吐、高并發(fā)、豐富查詢、權(quán)限控制、備份與恢復(fù)等特性的適合于企業(yè)級應(yīng)用的數(shù)據(jù)庫.

(8)智能合約

首先,相對于公有鏈,企業(yè)級區(qū)塊鏈中的業(yè)務(wù)邏輯更為復(fù)雜,需要智能合約支持更復(fù)雜的功能與數(shù)據(jù)結(jié)構(gòu),同時還要確保執(zhí)行結(jié)果的確定性以及合約語言的易用性,這對智能合約語言的設(shè)計提出了更高的要求；其次,The DAO 合約漏洞、Parity 多重簽名合約漏洞等揭示了智能合約的大量安全問題[74],相對于傳統(tǒng)的軟件測試、專家審查等方法,研究智能合約的語義模型,并通過形式化驗(yàn)證檢測合約漏洞[75]以保障智能合約的運(yùn)行時安全,將是今后的主要研究方向；最后,智能合約發(fā)布后,因需求變更、Bug 修復(fù)等原因,如何實(shí)現(xiàn)不停機(jī)的全網(wǎng)合約同步升級以及向下兼容先前版本的狀態(tài)數(shù)據(jù),也是必須解決的問題.

(9)可治理性

在部署實(shí)施企業(yè)級區(qū)塊鏈平臺時,區(qū)塊鏈的去中心化給目前的平臺帶來了許多治理上的問題:首先,在節(jié)點(diǎn)與用戶管理方面,傳統(tǒng)中心化的數(shù)據(jù)庫基于用戶名與密碼驗(yàn)證的實(shí)現(xiàn)已非常成熟,而去中心化的區(qū)塊鏈基于公鑰與私鑰驗(yàn)證的實(shí)現(xiàn)仍需大量繁瑣的手工配制,私鑰的存儲與丟失問題也需要易用可行的解決方案；其次,去中心化的區(qū)塊鏈系統(tǒng)沒有控制全局的管理員,系統(tǒng)在軟件動態(tài)升級、節(jié)點(diǎn)動態(tài)加入等方面需要聯(lián)盟成員集體表決并簽名,其造成了決策的低效與滯后；最后,區(qū)塊鏈的去中心化與政府部門與監(jiān)管機(jī)構(gòu)的監(jiān)管政策相矛盾,如何在實(shí)現(xiàn)去中心化同時兼顧政府與監(jiān)管的合規(guī)性要求,也是需要研究的問題.

9 結(jié)束語

關(guān)系數(shù)據(jù)庫基于關(guān)系模型、事務(wù)處理、查詢優(yōu)化等技術(shù),解決了以銀行為代表的金融機(jī)構(gòu)內(nèi)部記賬的業(yè)務(wù)需求.區(qū)塊鏈技術(shù)通過集成P2P 協(xié)議、塊鏈結(jié)構(gòu)、共識機(jī)制、智能合約等技術(shù),解決了多個互不信任機(jī)構(gòu)間一致性記賬的業(yè)務(wù)需求,減少了跨機(jī)構(gòu)業(yè)務(wù)流程中的摩擦,縮短了對賬周期、降低了運(yùn)營成本、提升了協(xié)作效率.目前,Hyperledger Fabric,Corda 和Quorum 等企業(yè)級區(qū)塊鏈平臺在以金融機(jī)構(gòu)為代表的眾多企業(yè)應(yīng)用實(shí)施時,還主要以概念驗(yàn)證(proof of concept,簡稱POC)為主.與發(fā)展了近40 年的傳統(tǒng)數(shù)據(jù)庫相比,企業(yè)級區(qū)塊鏈技術(shù)仍處于技術(shù)路線的初期階段,從系統(tǒng)架構(gòu)到開發(fā)范式都尚未形成統(tǒng)一標(biāo)準(zhǔn),在諸多方面還存在許多問題.為了解決這些問題,未來的還需更多的研究工作.