1 可信區(qū)塊鏈聯(lián)盟鏈平臺
可信區(qū)塊鏈聯(lián)盟鏈平臺（Trusted Consortium Blockchains,簡稱TrustedCBS）。面向企業(yè)用戶（to business）的區(qū)塊鏈一般叫做聯(lián)盟鏈,，進(jìn)行商業(yè)合作的企業(yè)構(gòu)建成一個(gè)聯(lián)盟,，共同維護(hù)這個(gè)區(qū)塊鏈，區(qū)塊鏈只對聯(lián)盟成員開放,。目前聯(lián)盟鏈比較有影響力的技術(shù)解決方案是Hyperledger Fabric,。可信區(qū)塊鏈聯(lián)盟鏈（TrustedCBS）是基于Hyperledger Fabric技術(shù)實(shí)現(xiàn)的,?？尚艆^(qū)塊鏈聯(lián)盟鏈的技術(shù)是指在共識的過程當(dāng)中可以受到預(yù)選節(jié)點(diǎn)控制的區(qū)塊鏈。在聯(lián)盟鏈不斷發(fā)展中,，業(yè)務(wù)上可能沒有辦法讓所有參與交易的人都可以看到所有人的交易數(shù)據(jù),，但是從某些方面講數(shù)據(jù)及隱私的保護(hù)是毫無疑問的。當(dāng)下在傳統(tǒng)的方案當(dāng)中普遍采用物理隔離,，來使得交易紀(jì)錄只存儲于各交易者的物理空間里,。區(qū)塊鏈技術(shù)的優(yōu)點(diǎn)就是交易過程中形成“共識機(jī)制的賬本”，但是同一個(gè)賬本的背景下,，聯(lián)盟鏈可以使交易數(shù)據(jù)及隱私得到保護(hù),。聯(lián)盟區(qū)塊鏈具有驗(yàn)證節(jié)點(diǎn)授權(quán)機(jī)制、多級加密機(jī)制,、共識機(jī)制,、高性能智能合約執(zhí)行引擎、數(shù)據(jù)管理等特性,。聯(lián)盟區(qū)塊鏈考慮到商業(yè)應(yīng)用對安全,、隱私、監(jiān)管,、審計(jì),、性能的需求，提高準(zhǔn)入門檻,，增加了安全,、隱私、可監(jiān)管審計(jì)等商業(yè)特性,，是區(qū)塊鏈技術(shù)在商業(yè)領(lǐng)域的應(yīng)用探索,。
聯(lián)盟鏈不用擔(dān)心有惡意節(jié)點(diǎn)偽造記錄，所以不需要耗資巨大的工作量證明,，而是通過一組排序服務(wù)器進(jìn)行交易排序與打包,。因?yàn)橐芾砺?lián)盟，所以還額外加入了會員服務(wù),。此外,，由于商業(yè)活動的復(fù)雜性,，所以Hyperledger Fabric提供智能合約（chaincode）服務(wù)，即由交易請求或者外部條件觸發(fā)新的交易,，比如買家的確認(rèn)收貨交易會觸發(fā)將保證金打款給賣家的交易,。相比于公鏈，聯(lián)盟鏈有更加切實(shí)的場景需求,，所以很多企業(yè),，都對聯(lián)盟鏈表現(xiàn)出極大的興趣。尤其是金融和跨國交易領(lǐng)域,，對聯(lián)盟鏈的需求非常強(qiáng)烈,。
超級賬本( Hyperledger)是Linux基金會的區(qū)塊鏈項(xiàng)目，致力于發(fā)展跨行業(yè)的商用區(qū)塊鏈平臺技術(shù),。超級賬本項(xiàng)目自創(chuàng)立伊始便吸引了眾多行業(yè)的領(lǐng)頭羊,，包括金融業(yè)、銀行,、互聯(lián)網(wǎng)行業(yè),、運(yùn)輸業(yè)、制作業(yè)等,?；趨^(qū)塊鏈技術(shù)、智能合約及其他相關(guān)技術(shù),，超級賬本項(xiàng)目致力于建立新一代的分布式賬本交易應(yīng)用平臺,，從而在簡化商業(yè)流程和法律事務(wù)的同時(shí)，建立起商業(yè)信任,、透明,、審查能力。
Hyperledger Fabric是一個(gè)帶有可插入各種功能模塊架構(gòu)的區(qū)塊鏈實(shí)施方案,，目標(biāo)是打造成一個(gè)由全社會共同維護(hù)的開源超級賬本,。Fabric的主要框架核心開發(fā)語言是Go語言，其更適合于聯(lián)盟鏈,?？梢哉f，Hyperledger是對傳統(tǒng)區(qū)塊鏈模型的革新,，在某種程度上是允許創(chuàng)建授權(quán)和非授權(quán)的區(qū)塊鏈,。Hyperledger還通過提供一個(gè)針對身份識別、可審計(jì),、隱私安全和健壯的模型,，使得縮短計(jì)算周期、提高規(guī)模效率和響應(yīng)各個(gè)行業(yè)的應(yīng)用需求成為可能。
利用超級賬本平臺,，用戶可以輕松地搭建起企業(yè)級的區(qū)塊鏈網(wǎng)絡(luò),。在這個(gè)網(wǎng)絡(luò)中,，每名成員都可以訪問實(shí)時(shí)更新,、加密過的賬本，并能查詢及發(fā)起交易,。一旦交易經(jīng)過共識流程的驗(yàn)證,，它就會立即加入到網(wǎng)絡(luò)中所有的賬本中，并且不能更改,。交易結(jié)果迅速,、私有、保密且易于審計(jì),。另外,，早期的超級賬本還定義了協(xié)議規(guī)范：Open Blockchain Protocol Specification，并以此建立了區(qū)塊鏈平臺Hyperledger Fabric,，并可以用于一系列B2B和B2C交易相關(guān)的行業(yè)案例中,。
2 可信區(qū)塊鏈聯(lián)盟鏈平臺系統(tǒng)架構(gòu)
可信區(qū)塊鏈聯(lián)盟鏈平臺架構(gòu)由上層應(yīng)用由桌面客戶端、移動客戶端,、瀏覽器客戶API組成,。用戶主要由API 將業(yè)務(wù)數(shù)據(jù)接入到系統(tǒng)。該平臺架構(gòu)底層是基于Hyperledger Fabric V1.0.0架構(gòu)構(gòu)建的,。該底層架構(gòu)主要由接入網(wǎng)關(guān),、區(qū)塊鏈應(yīng)用兩大部分功能組成，接入網(wǎng)關(guān)包含了注冊,、認(rèn)證,、授權(quán)、監(jiān)控,、審計(jì)五大功能,，區(qū)塊鏈應(yīng)用則主要由鏈上程序、區(qū)塊鏈管理,、可撥插共識模塊三大模塊組成,。可信區(qū)塊鏈聯(lián)盟鏈架構(gòu)如下所示,。
鏈上程序主要包括智能合約,、圖靈完備高級語言、合約容器/虛擬機(jī),。Hyperledger Fabric的智能合約smart contract稱為鏈碼chaincode,，是一段代碼，它處理網(wǎng)絡(luò)成員所同意的業(yè)務(wù)邏輯,。和以太坊相比,，Hyperledger Fabric鏈碼和底層賬本是分開的,，升級鏈碼時(shí)并不需要遷移賬本數(shù)據(jù)到新鏈碼當(dāng)中，真正實(shí)現(xiàn)了邏輯與數(shù)據(jù)的分離,。鏈碼可采用Go,、Java、Node.js語言編寫,。鏈碼被編譯成一個(gè)獨(dú)立的應(yīng)用程序,，fabric用Docker容器來運(yùn)行chaincode，里面的base鏡像都是經(jīng)過簽名驗(yàn)證的安全鏡像,，包括OS層和開發(fā)chaincode的語言,、runtime和SDK層。一旦chaincode容器被啟動,，它就會通過gRPC與啟動這個(gè)chaincode的Peer節(jié)點(diǎn)連接,。
區(qū)塊鏈管理主要包括賬戶管理、區(qū)塊鏈管理,、區(qū)塊校驗(yàn),、交易校驗(yàn)。Hyperledger Fabric是目前為止在設(shè)計(jì)上最貼近聯(lián)盟鏈思想的區(qū)塊鏈,。聯(lián)盟鏈考慮到商業(yè)應(yīng)用對安全,、隱私、監(jiān)管,、審計(jì),、性能的需求，提高準(zhǔn)入門檻,，成員必須被許可才能加入網(wǎng)絡(luò),。Fabric成員管理服務(wù)為整個(gè)區(qū)塊鏈網(wǎng)絡(luò)提供身份管理、隱私,、保密和可審計(jì)的服務(wù),。成員管理服務(wù)通過公鑰基礎(chǔ)設(shè)施PKI和去中心化共識機(jī)制使得非許可的區(qū)塊鏈變成許可制的區(qū)塊鏈。
可撥插共識模塊,，Hyperledger Fabric使用建立在HTTP/2上的P2P協(xié)議來管理分布式賬本,。采取可插拔的方式來根據(jù)具體需求來設(shè)置共識協(xié)議，比如PBFT,，Raft,，PoW和PoS等。
3 可信區(qū)塊鏈聯(lián)盟鏈平臺系統(tǒng)功能
3.1超級賬本聯(lián)盟鏈區(qū)塊鏈網(wǎng)絡(luò)的創(chuàng)建
（1）客戶端節(jié)點(diǎn)的創(chuàng)建：客戶端是用戶和應(yīng)用跟區(qū)塊鏈網(wǎng)絡(luò)打交道的橋梁?？蛻舳酥饕▋纱舐毮埽?）操作Fabric網(wǎng)絡(luò)：包括更新網(wǎng)絡(luò)配置,、啟停節(jié)點(diǎn)等；2）操作運(yùn)行在網(wǎng)絡(luò)中的鏈碼：包括安裝,、實(shí)例化,、發(fā)起交易調(diào)用鏈碼等。
（2）Peer節(jié)點(diǎn)的創(chuàng)建：Peer意味著在網(wǎng)絡(luò)中負(fù)責(zé)接受交易請求,、維護(hù)一致賬本的各個(gè)fabric-peer實(shí)例,。這些實(shí)例可能運(yùn)行在裸機(jī),、虛擬機(jī)甚至容器中,。節(jié)點(diǎn)之間彼此通過gRPC消息進(jìn)行通信。按照功能角色劃分,，Peer可以包括三種類型：1）Endorser（背書節(jié)點(diǎn)）：負(fù)責(zé)對來自客戶端的交易提案進(jìn)行檢查和背書,；2）Committer（確認(rèn)節(jié)點(diǎn)）：負(fù)責(zé)檢查交易請求，執(zhí)行交易并維護(hù)區(qū)塊鏈和賬本結(jié)構(gòu),；3）Submitter（提交節(jié)點(diǎn)）：負(fù)責(zé)接收交易,，轉(zhuǎn)發(fā)給排序者，目前未單獨(dú)出現(xiàn),。
（3）排序服務(wù)節(jié)點(diǎn)的創(chuàng)建：負(fù)責(zé)對所收到的交易在網(wǎng)絡(luò)中進(jìn)行全局排序,。Orderer主要提供Broadcast error和Deliver error兩個(gè)接口。前者代表客戶端將數(shù)據(jù)（交易）發(fā)給Orderer,，后者代表從Orderer獲取到排序后構(gòu)造的區(qū)塊結(jié)構(gòu),。客戶端可以使用atomicBroadcastClient結(jié)構(gòu)訪問這兩個(gè)接口,。
（4）CA證書節(jié)點(diǎn)的創(chuàng)建：負(fù)責(zé)網(wǎng)絡(luò)中所有證書的管理（分發(fā),、撤銷等），實(shí)現(xiàn)標(biāo)準(zhǔn)的PKI架構(gòu),。主要代碼在單獨(dú)的fabric-ca項(xiàng)目中,。CA在簽發(fā)證書后，自身不參與到網(wǎng)絡(luò)中的交易過程,。
在Gossip網(wǎng)絡(luò)中,，每個(gè)節(jié)點(diǎn)都有超級賬本網(wǎng)絡(luò)認(rèn)可的MSP（Membership Service Provider）頒發(fā)的證書（身份，Indentity）,，從證書計(jì)算哈希值導(dǎo)出（目前的實(shí)現(xiàn)是直接用Endpoint轉(zhuǎn)換而來的）的一個(gè)標(biāo)識符稱為節(jié)點(diǎn)的PKI-ID,。
超級賬本的Peer節(jié)點(diǎn)組成了一個(gè)P2P的網(wǎng)絡(luò)，客戶端SDK(Go,、Java,、Python、Node. js等不同語言)會提交請求給Per節(jié)點(diǎn)，Peer節(jié)點(diǎn)處理后會提交交易提案（TransactionProposal）給背書節(jié)點(diǎn)（Endorser）,，然后進(jìn)行背書簽名（Endorsement）,，最后經(jīng)過排序服務(wù)達(dá)成共識后廣播給Peer節(jié)點(diǎn)。
身份管理模塊管理節(jié)點(diǎn)標(biāo)識符和證書之前的映射,，在內(nèi)部維護(hù)了以PKI-ID為鍵,、證書為值的映射表pkiID2Cert，可以通過PKI?ID獲取節(jié)點(diǎn)的證書,，也可以更新節(jié)點(diǎn)的證書,。同時(shí)還內(nèi)置了MCS（MessageCryptoService）模塊，它可以對消息進(jìn)行簽名和驗(yàn)證,。更新節(jié)點(diǎn)證書的時(shí)候也會通過MCS模塊驗(yàn)證證書是否有效,，檢查從證書導(dǎo)出的標(biāo)識符是否和PKI-ID匹配。
在生成環(huán)境中,，假設(shè)所有節(jié)點(diǎn)都是雙向TLS部署的,，TLS連接的雙方都有一個(gè)有效的TLS證書。當(dāng)節(jié)點(diǎn)和對端節(jié)點(diǎn)第一次連接時(shí),，會有一個(gè)握手協(xié)議,，這個(gè)協(xié)議驗(yàn)證它是否擁有TLS證書的私鑰，因而在TLS會話中綁定成員身份,。握手是相互的,，過程比較簡單，握手節(jié)點(diǎn)主動發(fā)送給對端點(diǎn)一條ConnEstablish消息,，包含的內(nèi)容有：1）節(jié)點(diǎn)TLS證書的哈希值,。2）節(jié)點(diǎn)的PKI-ID。3）MSP身份證書,。
3.2 賬本管理功能
在Fabric中,，賬本（Ledger）是一個(gè)有序的、防篡改的全交易記錄的區(qū)塊哈希鏈,，它被ordering service構(gòu)造,，記錄了所有的成功和不成功的狀態(tài)更新交易。在1.0的版本中每個(gè)信道（channel）在orderer上都存儲了一個(gè)獨(dú)立的賬本,，信道中的每個(gè)參與節(jié)點(diǎn)（peer）都存儲了一份該賬本的拷貝,。同時(shí)賬本提供了SQL形式的查詢功能，以便進(jìn)行高效的對賬和爭議解決,。
因?yàn)橘~本是建立在信道的基礎(chǔ)上,，并通過鏈碼（chaincode）對其進(jìn)行操作或修改，這就產(chǎn)生了兩種方式：第一種是賬本可以在整個(gè)網(wǎng)絡(luò)中共享（可以理解為整個(gè)網(wǎng)絡(luò)是一個(gè)特殊的公共信道）,，第二種是賬本可以私有化,，只包括一組特定的參與者,。在后一種方式中，這些參與者將創(chuàng)建一個(gè)單獨(dú)的信道,，從而分離其交易事務(wù)（transactions）和賬本,。為了解決透明度和隱私的沖突，鏈碼只會被安裝在擁有讀寫權(quán)限的參與節(jié)點(diǎn)上,，換句話說如果沒有合適的鏈碼支持,，參與節(jié)點(diǎn)將無法與賬本進(jìn)行正確數(shù)據(jù)的對接。更進(jìn)一步在混淆數(shù)據(jù),，鏈碼中操作的鍵值可以在被追加到賬本之前使用像AES這樣的算法進(jìn)行全部或選擇性的加密,。
3.3 交易管理
交易流程主要包括：
區(qū)塊鏈客戶端把交易請求發(fā)給之前約定好的所有背書節(jié)點(diǎn)（endorsing peer）。這里說明一下endorsing peer的選擇是有一定范圍的,，并不是在所有的endorsing peer里隨意選擇,，是由交易所屬的ChainCode和該Chaincode所定義的Endorsement Policy共同決定的。
背書節(jié)點(diǎn)收到上述信息后,，首先用Client的公鑰驗(yàn)證它的簽名,，背書節(jié)點(diǎn)執(zhí)行智能合約（是模擬交易,，不會寫到賬本里）,，將執(zhí)行的結(jié)果反饋給客戶端。
客戶端搜集“足夠”多的背書節(jié)點(diǎn)的結(jié)果后,，就說明這個(gè)交易通過了Endorsement階段,。通過之后就打包發(fā)給共識節(jié)點(diǎn)（orderers）。其中“足夠”的數(shù)量是多少,，取決于背書策略Endorsement Policy是如果規(guī)定的,，相反如果Client沒有搜集到足夠多的信息的話，這個(gè)交易就會被廢止掉,。Client可以選擇重新發(fā)起交易,。
共識階段雖然有不同的算法，不過目的都是把有效的交易加入新生成的區(qū)塊,，并通知所有節(jié)點(diǎn)使他們賬本保存一致,。共識節(jié)點(diǎn)將結(jié)果廣播所有的節(jié)點(diǎn)（peer）。然后各節(jié)點(diǎn)再更新自己賬本,。交易流程圖如下所示,。
3.4 鏈碼生命周期管理
鏈碼提供了4個(gè)管理鏈碼生命周期的命令，分別是鏈碼的打包,、安裝,、實(shí)例化、升級,。在以后的版本中,，還可能提供鏈碼的停止和啟動命令,，在不刪除鏈碼的情況下可以停止和啟動鏈碼。鏈碼在安裝和實(shí)例化以后,，就處于激活的狀態(tài),，應(yīng)用程序或者命令就可以調(diào)用和觸發(fā)智能合約的功能了。鏈碼安裝以后隨時(shí)都是可以升級的,。
（1）鏈碼的打包
鏈碼的內(nèi)容主要包括以下3個(gè)部分：1）鏈碼源碼,。2）實(shí)例化策略。3）鏈碼的簽名,。
（2）鏈碼的安裝
鏈碼安裝的時(shí)候會把鏈碼的源碼到前面已經(jīng)介紹過的結(jié)構(gòu)Chaincode DeploymentSpec中,，安裝到需要運(yùn)行鏈碼的Peer節(jié)點(diǎn)上。鏈碼安裝是針對節(jié)點(diǎn)的,，每次安裝只對單個(gè)節(jié)點(diǎn)有效,。需要給每個(gè)要運(yùn)行鏈碼的背書節(jié)點(diǎn)都安裝一遍，具體需要安裝到哪些節(jié)點(diǎn),，可以根據(jù)背書策略來選擇,。
從安全角度考慮，鏈碼應(yīng)該只需要安裝在需要執(zhí)行的背書節(jié)點(diǎn)上,，可以保護(hù)鏈碼的邏輯被未授權(quán)的節(jié)點(diǎn)獲取到,。沒有安裝鏈碼的節(jié)點(diǎn)是不能執(zhí)行鏈碼的智能合約的，但是可以驗(yàn)證鏈上的交易并且提交到本地賬戶中,。
（3）鏈碼的實(shí)例化
鏈碼的實(shí)例化會調(diào)用鏈碼生命周期系統(tǒng)鏈碼（LSCC）在通道上創(chuàng)建和初始化鏈碼,。鏈碼在實(shí)例化之前是和通道無關(guān)的，實(shí)例化的時(shí)候才和通道綁定,。鏈碼可以和多個(gè)通道綁定,，在通道上初始化后記錄到通道的狀態(tài)數(shù)據(jù)庫中。同一個(gè)鏈碼在不同通道上的數(shù)據(jù)是隔離的,。
鏈碼實(shí)例化的時(shí)候會檢查是否符合鏈碼實(shí)例化的策略和通道的寫入策略,。實(shí)例化的策略驗(yàn)證過程是檢查實(shí)例化交易的簽名是否符合策略的規(guī)則，驗(yàn)證通過才會寫入到賬本和狀態(tài)數(shù)據(jù)中,。通道的寫入策略是在創(chuàng)建通道時(shí)指定的,，這也是從安全角度考慮的，避免未授權(quán)的用戶部署鏈碼和調(diào)用鏈碼,。默認(rèn)的實(shí)例化策略是通道的任何一個(gè)管理員,，所以鏈碼的實(shí)例化交易提交者必須也是通道的管理員鏈碼的實(shí)例化會指定鏈碼的背書策略，用來確定通道上哪些節(jié)點(diǎn)執(zhí)行的交易才能添加到賬本中,。
（4）鏈碼的升級
鏈碼安裝以后是隨時(shí)于可以升級的,，鏈碼的名稱需要保持不變，必須要更新的是鏈碼的版本,，其他的部分,，比如鏈碼的所有者和實(shí)例化策略都是可選的,。鏈碼的版本是用字符串表示的，并沒有指定比較版本大小的規(guī)則,，是以更新的先后順序?yàn)闇?zhǔn)的,，具體的操作方法線下自行確定。
同樣,，升級之前還需要把鏈碼安裝到對應(yīng)的背書節(jié)點(diǎn)上,。鏈碼的升級和實(shí)例化是類似的操作，也是綁定鏈碼到通道上,，執(zhí)行初始化的操作,。鏈碼升級只會影響到指定的通道沒有綁定鏈碼新版本的通道還是繼續(xù)舊的版本。同一個(gè)背書節(jié)點(diǎn)上,，不同通道綁定的鏈碼可能是不同的版本,，所以升級的時(shí)候不會主動刪除舊的版本。
鏈碼升級的時(shí)候同樣會檢查實(shí)例化策略,，采用的是通道上鏈碼最新版本的實(shí)例化策略檢查通過以后才會更新為鏈碼新版本指定的實(shí)例化策略,。
（5）鏈碼的停止與啟動
鏈碼的停止與啟動功能還沒實(shí)現(xiàn)，只能手動刪除鏈碼的容器和鏡像,，再刪除背書節(jié)點(diǎn)本地保存的鏈碼,。
3.5 通道的管理
Hyperledger Fabric 通道是兩個(gè)或多個(gè)特定網(wǎng)絡(luò)成員之間的通信的私有“子網(wǎng)”，用于進(jìn)行需要數(shù)據(jù)保密的交易,。channel由成員（組織）,、每個(gè)成員的錨點(diǎn)、共享賬本,，鏈碼應(yīng)用程序和order服務(wù)節(jié)點(diǎn)定義。網(wǎng)絡(luò)上的每個(gè)transaction都在一個(gè)channel上執(zhí)行,，每個(gè)通信方必須經(jīng)過身份驗(yàn)證并授權(quán)在該channel上進(jìn)行交易,。加入channel的每個(gè)peer都具有由成員服務(wù)提供商（MSP）給出的自己的身份。
要?jiǎng)?chuàng)建新的channel,，客戶端SDK會調(diào)用configuration system chaincode和引用屬性,，如錨點(diǎn)和成員（組織）。該請求為channel ledger創(chuàng)建一個(gè)genesis block,，它存儲有關(guān)channel策略,，成員和錨點(diǎn)的配置信息。當(dāng)將新成員添加到現(xiàn)有channel時(shí),，這個(gè)genesis block或最近被重新配置的塊將會分享給新成員,。
channel中每個(gè)成員的leading peer的選舉決定了哪個(gè)peer代表成員與ordering service進(jìn)行通信。如果沒有指定leader,，則可以使用算法來指定leader,。共識服務(wù)將交易排序并以一個(gè)block的形式發(fā)送給一個(gè)leader,，然后leader將其分發(fā)給其成員 peer，并用gossip 協(xié)議進(jìn)行跨channel通信,。
雖然任何一個(gè)錨點(diǎn)可以屬于多個(gè)信道,，并且因此維護(hù)多個(gè)賬本，但沒有賬本數(shù)據(jù)可以從一個(gè)channel傳遞到另一個(gè)channel,。ledger按channel分隔,，由configuration chaincode，identity membership service和gossip數(shù)據(jù)傳播協(xié)議來定義和實(shí)現(xiàn),。被隔離的數(shù)據(jù)包括交易信息,，賬本狀態(tài)和channel成員資料，這些數(shù)據(jù)僅限于在channel上具有可驗(yàn)證成員資格的peer間傳播,。通過信道隔離peer和賬本數(shù)據(jù),，允許需要私有和機(jī)密事務(wù)的網(wǎng)絡(luò)成員與同一個(gè)塊鏈網(wǎng)絡(luò)上的業(yè)務(wù)競爭對手和其他受限制的成員共存。
3.6 Docker管理鏈碼
鏈碼運(yùn)行在與承認(rèn)對等體進(jìn)程隔離的安全Docker容器中,。Chaincode通過應(yīng)用程序提交的交易來初始化和管理分類帳狀態(tài),。鏈碼通常處理網(wǎng)絡(luò)成員所同意的業(yè)務(wù)邏輯，因此可被視為“智能合同”,。 由鏈碼創(chuàng)建的狀態(tài)僅限于該鏈碼,，不能被另一個(gè)鏈碼直接訪問。 然而,，在同一個(gè)網(wǎng)絡(luò)中,，給定適當(dāng)?shù)臋?quán)限，鏈碼可以調(diào)用另一個(gè)鏈碼來訪問其狀態(tài),。Docker管理鏈碼,，確保智能合約的安全執(zhí)行環(huán)境，同時(shí)也確保安全的執(zhí)行過程與用戶數(shù)據(jù)的隔離,。Docker提供了安全的沙箱環(huán)境和鏡像文件倉庫,。
3.7 超級賬本聯(lián)盟鏈共識服務(wù)
超級賬本中把共識分為交易背書、交易排序和交易驗(yàn)證3個(gè)階段,，如圖所示：
1）交易背書
應(yīng)用程序根據(jù)背書策略的要求選擇背書節(jié)點(diǎn),，給這些節(jié)點(diǎn)發(fā)送需要執(zhí)行的交易提案（Proposal）。背書節(jié)點(diǎn)調(diào)用鏈碼（Chaincode）執(zhí)行這些交易提案,交易過程是執(zhí)行是模擬執(zhí)行的,，并不真正提交數(shù)據(jù)到賬本中,。執(zhí)行完成以后調(diào)用交易背書系統(tǒng)鏈碼ESCC對模擬執(zhí)行結(jié)果進(jìn)行簽名背書。
2）交易排序
排序階段接受已經(jīng)簽名背書的交易,，確定交易的順序和數(shù)量,，將排好序的交易打包到區(qū)塊中，廣播給Peer節(jié)點(diǎn)進(jìn)行驗(yàn)證,。通常,，從效率方面考慮,，排序服務(wù)不會輸出單個(gè)交易作為一個(gè)區(qū)塊，而是把多個(gè)交易打包成一個(gè)區(qū)塊,。
3）交易驗(yàn)證
Peer節(jié)點(diǎn)驗(yàn)證接收到區(qū)塊里包含的交易的有效性,，包括背書策略驗(yàn)證及雙花檢測（double-spending）?？梢詫Ⅱ?yàn)證錯(cuò)誤分為兩大類:語法錯(cuò)誤和邏輯錯(cuò)誤,。語法錯(cuò)誤包括無效輸入、未驗(yàn)證的簽名以及重復(fù)的交易（雙花攻擊）,，重復(fù)的交易應(yīng)該丟棄,。第二類錯(cuò)誤比較復(fù)雜，比如會導(dǎo)致雙花或者M(jìn)VCC失敗的交易,，這需要定義策略來決定程序是繼續(xù)執(zhí)行還是終止,。策略還可以定義是否需要記錄日志以便對這類交易進(jìn)行審計(jì)。交易驗(yàn)證依賴鏈碼的業(yè)務(wù)邏輯,，目前默認(rèn)的交易驗(yàn)證系統(tǒng)鏈碼ⅤSCC只支持背書策略的驗(yàn)證,。
3.8 Kafka的排序服務(wù)
基于Kafka的排序服務(wù)利用Kafka作為交易的消息隊(duì)列，實(shí)現(xiàn)高吞吐量的數(shù)據(jù)分發(fā)每個(gè)通道都對應(yīng)Kafka的一個(gè)主題（topic）,，排序服務(wù)節(jié)點(diǎn)在不同階段充當(dāng)不同的角色,。
1）接收交易階段：排序服務(wù)節(jié)點(diǎn)充當(dāng)?shù)氖荎afka的生產(chǎn)者（producer），接收到交易后
通過權(quán)限檢查轉(zhuǎn)發(fā)給對應(yīng)通道的主題,。
2）消息處理階段：排序服務(wù)節(jié)點(diǎn)充當(dāng)?shù)氖荎afka的消費(fèi)者（consumer）,，實(shí)時(shí)監(jiān)聽消息進(jìn)行后續(xù)的處理，生成區(qū)塊或者交易分割消息等,。
3.9 超級賬本聯(lián)盟鏈數(shù)據(jù)區(qū)塊的構(gòu)建
聯(lián)盟鏈數(shù)據(jù)區(qū)塊主要包括狀態(tài)數(shù)據(jù)和賬本數(shù)據(jù)兩大模塊,，其中賬本數(shù)據(jù)主要包含交易數(shù)據(jù)及構(gòu)建的區(qū)塊信息數(shù)據(jù)。
（1）狀態(tài)（state）
區(qū)塊鏈的最新狀態(tài)被建模為一個(gè)版本化的鍵值存儲（KVS）,，鍵是名字,，值是任意二進(jìn)制大對象（blobs）。這些鍵值對被運(yùn)行在區(qū)塊鏈上的鏈碼（應(yīng)用程序）通過put和getKVS操作來操縱,。狀態(tài)被持久化存儲并且狀態(tài)的更新被記錄為日志。請注意狀態(tài)模型采用的是版本化的KVS,，具體實(shí)現(xiàn)可以使用實(shí)際的KVS存儲,，但是也可以用關(guān)系數(shù)據(jù)庫系統(tǒng)或其他的解決方案。
狀態(tài)由對等點(diǎn)維護(hù),，而不是order節(jié)點(diǎn)和客戶端,。狀態(tài)分區(qū)。KVS中的鍵可以從它們鏈碼的名字識別,，在這個(gè)意義上,，只有一個(gè)特定鏈碼的交易可以修改屬于這個(gè)鏈碼的鍵,。原則上，任何鏈碼都可以讀取屬于其他鏈碼的鍵,。為了支持跨鏈碼交易,，修改屬于兩個(gè)或更多個(gè)鏈碼的狀態(tài)作為一個(gè)V1后的功能點(diǎn)。
（2）賬本
賬本提供一份可驗(yàn)證歷史信息,，記錄所有在系統(tǒng)操作中發(fā)生的成功的狀態(tài)改變（即有效交易）和未成功的對改變狀態(tài)的嘗試（即無效交易）,。賬本由排序服務(wù)構(gòu)建為一個(gè)完整排序的交易（有效的和無效的）區(qū)塊的哈希鏈。哈希鏈強(qiáng)制要求賬本中的區(qū)塊是完全排序的并且每個(gè)區(qū)塊內(nèi)包含的交易是完全排序的,。
賬本存儲在所有的對等點(diǎn)里,，也可以選擇保存在一部分排序者里。存在排序者節(jié)點(diǎn)內(nèi)的賬本我們叫排序者的賬本（OedererLedger）,，而存在對等點(diǎn)的賬本我們叫對等點(diǎn)賬本（PeerLedger）,。對等點(diǎn)賬本與排序者賬本不同之處在于對等點(diǎn)賬本本地維護(hù)一個(gè)比特掩碼來區(qū)分有效交易和無效交易。
對等點(diǎn)可以修訂對等點(diǎn)賬本,。排序者維護(hù)排序者賬本用于容錯(cuò)和（對等點(diǎn)賬本的）可用性并可以隨時(shí)決定修訂對等點(diǎn)賬本,，前提是排序服務(wù)的屬性保持不變。賬本允許對等點(diǎn)重播所有交易的歷史來重構(gòu)狀態(tài),。因此,，狀態(tài)是一個(gè)可選的數(shù)據(jù)結(jié)構(gòu)。
4 可信區(qū)塊鏈聯(lián)盟鏈平臺系統(tǒng)部署
4.1 系統(tǒng)要求
4.1.1 系統(tǒng)硬件要求
（1）處 理 器：4核或者更高主頻的處理器,。
（2）內(nèi) 存：16G內(nèi)存或更大容量內(nèi)存,。
（3）硬盤空間：500G或更大容量硬盤。
（4）帶 寬：4M或更高帶寬,。
（5）系統(tǒng)操作數(shù)：64位,。
4.1.2 系統(tǒng)軟件要求
（1）操作系統(tǒng)：Ubuntu 16.04 64位。
（2）數(shù) 據(jù) 庫：MySQL 5.7,。
4.2 環(huán)境配置
（1）GO語言安裝：GO 1.6.3或者更高版本,。
（2）Nodejs語言安裝：Nodejs 6.9或者更高版本。
（3）Docker容器安裝：1.13.1或者更高版本,，建議使用17.03.0-ce,。
（4）Docker Compose安裝：1.8或者更高版本。
5 可信區(qū)塊鏈聯(lián)盟鏈平臺技術(shù)支持與服務(wù)
（1）我們秉承“用戶至上,，服務(wù)為先”的理念,，竭誠提供從整體解決方案到產(chǎn)品的定制、售前培訓(xùn)和售后的技術(shù)服務(wù)與升級,，確保產(chǎn)品的安全性和質(zhì)量,。
（2）提供全方位的技術(shù)支持和客戶服務(wù)。
（3）提供現(xiàn)場和遠(yuǎn)程技術(shù)支持與系統(tǒng)服務(wù)。
（4）專門客服人員提供快速精準(zhǔn)技術(shù)服務(wù)支持,。