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