Hyperledger

Fabric六月23目錄Hyperledger簡介架構(gòu)設計共享賬本共識算法CA通道智能合約成員管理交易過程主要特點HyperledgerHyperledger

項目是LinuxFoundation托管的一個開源、協(xié)作式項目，為企業(yè)構(gòu)建開源、通用區(qū)塊鏈結(jié)構(gòu)。作為一個聯(lián)合項目，超級賬本由面向不同目的和場景的子項目構(gòu)成。目前主要包括8大頂級項目，所有項目都遵守Apachev2許可FabricSawtoothIrohaBlockchainExplorerCelloIndyComposerBurrowHyperledgerFabricFabric是Hyperledger的一個基于社區(qū)的項目是一個區(qū)塊鏈應用支持框架；旨在作為開發(fā)模塊化體系結(jié)構(gòu)的區(qū)塊鏈應用程序的基礎，以便諸如共識和會員服務等組件可以即插即用；賬本數(shù)據(jù)可以以多種格式存儲，一致的機制可以被轉(zhuǎn)換和輸出，并且支持不同的MSPs；它使用容器技術(shù)來托管構(gòu)成系統(tǒng)應用邏輯的智能合約（也稱為鏈代碼）。使用容器技術(shù)來促成“智能合約”，智能合約在“鏈代碼”中實現(xiàn)；如同其它區(qū)塊鏈技術(shù)一樣，它有一個賬本，使用智能合約，并且是一個由參與者管理他們的交易的系統(tǒng)；Fabric是私有的，而且是被許可的。組織的成員可以通過一個MSP來注冊；Fabric提供創(chuàng)建通道（channel）的能力，允許一組參與者創(chuàng)建一個單獨的共同維護的交易賬本。Hyperledger定義和術(shù)語Client：

代表由最終用戶操作的實體，它必須連接到某一個peer節(jié)點或者orderer節(jié)點上與區(qū)塊鏈網(wǎng)絡通信；客戶端向endorser提交交易提案，當收集到足夠背書后，向排序服務廣播交易，進行排序，生成區(qū)塊；CA節(jié)點：證書頒發(fā)機構(gòu)，負責對加入鏈內(nèi)的所有節(jié)點進行授權(quán)認證，由服務器（fabric-ca-service）和客戶端組件（fabric-ca-client）組成。CA節(jié)點接收客戶端的注冊申請，返回注冊密碼用于用戶登入，以便獲取身份證書，在區(qū)塊鏈網(wǎng)絡上所有的操作都會驗證用戶的身份；Orderers：提供共識服務的網(wǎng)絡節(jié)點，負責接收包含背書簽名的交易，對未打包的交易進行排序生成區(qū)塊，廣播給peer節(jié)點。例如，使用Kafka或PBFT；通道：Order服務提供Peer節(jié)點供訂閱的主題（如發(fā)布-訂閱消息隊列），每個主題是一個通道。peer可以訂閱多個通道，并且只能訪問訂閱通道上的交易；賬本：賬本保存Orders提交經(jīng)節(jié)點確認的交易記錄；成員：訪問和使用賬本的網(wǎng)絡節(jié)點；鏈：基本上，一個鏈由1個通道+1個賬本+N個成員組成。非鏈的成員無法訪問該鏈上的交易。鏈的成員可以由應用程序動態(tài)指定。Hyperledger定義和術(shù)語Peers：參與交易的主體，可以說是代表每個參與到鏈上的成員，維護賬本的網(wǎng)絡節(jié)點，所有的peer節(jié)點都是committer（記賬節(jié)點）。通常在HyperledgerFabric架構(gòu)中存在各種角色，如endorser和committer（維護完整的賬本數(shù)據(jù)）；所有的peer節(jié)點都是committer（記賬節(jié)點），而又有可能擔任的角色有endorser（背書節(jié)點）、Leader（主節(jié)點）、Anchor（錨節(jié)點）Committer：記賬節(jié)點使用基于Gossip的p2p數(shù)據(jù)分發(fā)，節(jié)點會定期跟其他節(jié)點交換信息。如果在這個過程中有節(jié)點發(fā)生故障，則會從存活的節(jié)點中刪除這個節(jié)點的信息。對于故障節(jié)點，還會定時檢查是否已經(jīng)恢復，恢復存活的節(jié)點會更新到存活節(jié)點列表中。如果有新加入的節(jié)點，也能通過節(jié)點信息的交換獲取到，添加到存活列表中，廣播給其他節(jié)點Leader：主節(jié)點連接到排序服務，負責把接受到的批量區(qū)塊轉(zhuǎn)發(fā)給其他節(jié)點。因此主節(jié)點與排序服務的穩(wěn)定連接至關(guān)重要。可以強制設置為主節(jié)點，也可以動態(tài)選舉產(chǎn)生Endorser：背書節(jié)點為動態(tài)的角色與具體的chaincode綁定，背書節(jié)點的故障對網(wǎng)絡的影響取決于chaincode對應的背書策略，例如背書策略指定只要3個組織其中的2個組織的成員完成背書，該交易就是有效的，那么只有一個組織的成員節(jié)點出現(xiàn)故障對交易完成沒有影響Anchor：錨節(jié)點是在一個channel上可以被所有其他peer發(fā)現(xiàn)的peer，channel上的每個成員都有一個anchorPeer(或多個anchorpeer來防止單點故障)，允許屬于不同成員的peer發(fā)現(xiàn)channel上的所有現(xiàn)有peerFabric0.6到1.0的架構(gòu)圖結(jié)構(gòu)簡單：應用-成員管理-Peer的三角形關(guān)系，主要業(yè)務功能全部集中于Peer節(jié)點；架構(gòu)問題：由于peer節(jié)點承擔了太多的功能，所以帶來擴展性、可維護性、安全性、業(yè)務隔離等方面的諸多問題0.6版本在推出后，并沒有大規(guī)模被行業(yè)使用，只是在一些零星的案例中進行業(yè)務驗證。分拆Peer的功能，將Blockchain的數(shù)據(jù)維護和共識服務進行分離，共識服務從Peer節(jié)點中完全分離出來，獨立為Orderer節(jié)點提供共識服務；基于新的架構(gòu)，實現(xiàn)多通道（channel）的結(jié)構(gòu)，實現(xiàn)了更為靈活的業(yè)務適應性（業(yè)務隔離、安全性等方面）特性：chaincode信任的靈活性：支持多個ordering服務節(jié)點，增強共識的容錯能力和對抗orderer作惡的能力擴展性：將endorsement和ordering進行分離，實現(xiàn)多通道（實際是分區(qū)）結(jié)構(gòu)，增強系統(tǒng)的擴展性；同時也將chaincode執(zhí)行、ledger、state維護等非常消耗系統(tǒng)性能的任務與共識任務分離，保證了關(guān)鍵任務（ordering）的可靠執(zhí)行保密性：新架構(gòu)對于chaincode在數(shù)據(jù)更新、狀態(tài)維護等方面提供了新的保密性要求，提高系統(tǒng)的業(yè)務、安全方面的能力共識服務的模塊化：支持可插拔的共識結(jié)構(gòu)，支持多種共識服務的接入和服務實現(xiàn)Fabric架構(gòu)設計超級賬本包括三大組件：區(qū)塊鏈（Blockchain）鏈碼（Chaincode）成員權(quán)限管理（Membership）區(qū)塊鏈提供一個分布式賬本平臺。一般地，多個交易被打包進區(qū)塊中，多個區(qū)塊構(gòu)成一條區(qū)塊鏈。區(qū)塊鏈代表的是賬本狀態(tài)機發(fā)生變更的歷史過程。鏈碼包含所有的處理邏輯對外提供接口，外部通過調(diào)用鏈碼接口來改變世界觀。世界觀是一個鍵值數(shù)據(jù)庫，用于存放鏈碼執(zhí)行過程中涉及到的狀態(tài)變量。成員權(quán)限管理基于PKI，平臺可以對接入的節(jié)點和客戶端的能力進行限制。Fabric共享賬本區(qū)塊鏈數(shù)據(jù)，這是用文件系統(tǒng)存儲在Committer節(jié)點上的。區(qū)塊鏈中存儲了Transaction的讀寫集；每個參與者都有一份賬本的副本到他們所屬的每一個Fabric的網(wǎng)絡上；包括兩個組成部分：世界狀態(tài)（worldstate）、事務日志（transactionlog）在給定的時間點上，世界狀態(tài)組件描述了總賬的狀態(tài)，它是賬本的數(shù)據(jù)庫事務日志組件記錄所有導致當前世界狀態(tài)值的事務，這是世界狀態(tài)的更新歷史，記錄了區(qū)塊鏈網(wǎng)絡使用的賬本數(shù)據(jù)庫之前和之后的值賬本是世界狀態(tài)數(shù)據(jù)庫和事務日志歷史的組合該賬本為世界狀態(tài)提供了可替換的數(shù)據(jù)存儲方案默認情況下，是一個LevelDB鍵值存儲數(shù)據(jù)庫，也支持使用CouchDB事務日志不需要是可插拔的為了檢索區(qū)塊鏈的方便，用LevelDB對其中的Transaction進行了索引。Fabric智能合約超級賬本支持基于主流編程語言的智能合約（鏈碼）設計，極大地方便了應用開發(fā)人員快速開發(fā)新型的分布式應用，或?qū)⒁延袘眠w移到區(qū)塊鏈系統(tǒng)上。區(qū)塊鏈應用，一般由若干部署在區(qū)塊鏈網(wǎng)絡中的智能合約，以及調(diào)用這些智能合約的應用程序組成。用戶專注于與業(yè)務本身相關(guān)的應用程序；智能合約則封裝了與區(qū)塊賬本直接交互的相關(guān)過程，被應用程序調(diào)用智能合約直接與賬本結(jié)構(gòu)打交道，處于十分核心的位置。智能合約代碼本質(zhì)上是為了對上層業(yè)務邏輯進行支持；智能合約最終會部署在區(qū)塊鏈網(wǎng)絡中與賬本進行交互。應用程序通過調(diào)用智能合約提供的方法接口來實現(xiàn)業(yè)務邏輯。由于離用戶側(cè)更貼近，應用程序的開發(fā)更為靈活，可以采用已有的主流開發(fā)語言進行開發(fā)，包括Javascript、Python、Go、Java等。在運行位置上，應用程序可以運行在區(qū)塊鏈網(wǎng)絡的節(jié)點上；又可以運行在中心化的服務器上，但必須保證可以訪問到智能合約暴露的服務接口。典型的區(qū)塊鏈應用程序的工作過程Fabric成員管理MembershipServiceProviders(MSP)在劃分成員結(jié)構(gòu)的時候Fabric用MSP來定義一個成員，在最佳實例推薦中，一個企業(yè)或者機構(gòu)可以是一個單獨的MSP例如供應鏈案例中，核心企業(yè)便是一個MSP，銀行和供應商各代表一個MSP，那么在一個MSP下可以有多個Peer節(jié)點，而不同的授權(quán)便有不同的功能MSP具體應用場景在部署智能合約或者初始化時需要擁有對應CA賦權(quán)的證書才可執(zhí)行（默認為PeerAdmin用戶）。為新節(jié)點或用戶注冊證書時，需要CA對該操作證書賦予權(quán)限（一般為Admin用戶）。在背書策略中可通過MSP來代表背書成員，可設定單個Peer節(jié)點代表其MSP達成協(xié)議（也可以要求全部Peer節(jié)點通過才達成協(xié)議）。在跨MSP間的Peer節(jié)點通信，先通過各MSP內(nèi)指定的AnchorPeer收集MSP內(nèi)的Peer列表，然后通過各MSP下的AnchorPeer交互其Peer列表，將其他MSP下的Peer列表同步到內(nèi)部Peer后，便通過Gossip協(xié)議Peer節(jié)點間隨機通信。每個MSP都有自己獨立的CA節(jié)點，為其提供所有的證書需求，各MSP共享其CA節(jié)點的ROOT證書達到互相認證。匿名交易。在一筆交易中，包含著每一個參與背書的用戶證書，這可以認為是公開實名制的交易，所有鏈內(nèi)成員都可以看見每一筆交易是由誰參與的，但是如果我們希望匿名交易該如何實現(xiàn)呢？在Fabric0.6版本內(nèi)有Ecert和Tcert的概念，Ecert即為用戶的證書，而Tcert則是用于匿名交易，用戶可以通過向CA申請一批Tcert用于交易，而該Tcert不包含用戶的信息，當需要驗證查驗信息時可通過CA來認證該用戶的身份。（此功能在1.0版本尚未實現(xiàn)）Revoke，廢除證書。在PKI體系中，其最大的優(yōu)勢便是Offline的，即在證書頒發(fā)后，不需要CA節(jié)點的存在也可以在本地進行認證，而遇到很大的問題是類似于廢除證書時如果希望能即時將廢除證書的消息通知到各個節(jié)點，目前的做法是需要CA節(jié)點保持在線并與各節(jié)點保持通信。（獲取Tcert也需要CA節(jié)點在線）Fabric通道數(shù)據(jù)隔離和保密在共識服務上支持多通道消息傳遞，使得Peer節(jié)點可以基于應用訪問控制策略來訂閱任意數(shù)量的通道;也就是說，應用程序指定Peer節(jié)點的子集中架設通道。這些peer組成提交到該通道交易的相關(guān)者集合，而且只有這些peer可以接收包含相關(guān)交易的區(qū)塊，與其他交易完全隔離此外，peers的子集將這些私有塊提交到不同的賬本上，允許它們保護這些私有交易，與其他peers子集的賬本隔離開來。應用程序根據(jù)業(yè)務邏輯決定將交易發(fā)送到1個或多個通道。這不是內(nèi)置的限制，區(qū)塊鏈網(wǎng)絡不知道并假設不同通道上的交易之間沒有關(guān)系通道和賬本的組合是一個虛擬鏈，因此一個區(qū)塊鏈網(wǎng)絡可以具有1個共識服務的多個鏈。系統(tǒng)通道和全賬本構(gòu)成系統(tǒng)鏈。每個區(qū)塊鏈網(wǎng)絡只有1個系統(tǒng)鏈。如果交易是公開的，區(qū)塊鏈網(wǎng)絡可能永遠不需要多個鏈;所有的交易對所有Peers成員都可見。然而，在成員間進行私密交易（例如雙邊合同），單獨的鏈是隔離數(shù)據(jù)、提供保密的方式注意：共識服務接收所有鏈的所有交易，因此保密性僅與peer而不是Orderers相關(guān)。當共識服務由被許可網(wǎng)絡中的可信方和監(jiān)管機構(gòu)組成時，這樣是合理的，也就是說，這些交易作為業(yè)務需求僅對他們可見。另一方面，如果應用程序不希望Orderers知道交易的內(nèi)容，它必須利用其他技術(shù)來隱藏敏感數(shù)據(jù)，例如哈希散列或加密。共識服務作為一個信任方存在，如果是由拜占庭容錯（BFT）共識協(xié)議實現(xiàn)（例如PBFT），可以防止不可信的Orderers破壞賬本的一致性和阻礙系統(tǒng)可用性。然而，現(xiàn)在還沒有一種協(xié)議可以在有不可信的Orderers存在的情況下，提供多通道設計的同時提供數(shù)據(jù)保密性。FabricCACA主要功能身份注冊，或者將連接到LDAP作為用戶注冊；頒發(fā)登錄證書(ECerts)；頒發(fā)交易證書(TCerts)，保證鏈上交易的匿名性與不可連接性；證書續(xù)期與撤銷。Fabric共識機制目前包括SOLO，Kafka，未來可能要使用的PBFT（實踐拜占庭容錯）、SBFT（簡化拜占庭容錯）solo、kafka和bft，分別可以認為是中心化、半中心化和去中心化。solo模式指整個fabric網(wǎng)絡依賴于一個orderer節(jié)點kafka模式依賴于一個kafka集群bft模式則是去中心化的orderer集群，但目前bft模式并沒有在fabric-1.0中實現(xiàn)Fabric共識機制SOLO機制是一個非常容易部署的非生產(chǎn)環(huán)境的共識排序節(jié)點。它由一個為所有客戶服務的單一節(jié)點組成，所以不需要“共識”，因為有一個中央權(quán)威機構(gòu)。相應地沒有高可用性或可擴展性。這使得獨立開發(fā)和測試很理想，但不適合生產(chǎn)環(huán)境部署。order-solo模式作為單節(jié)點通信模式，所有從peer收到的消息都在本節(jié)點進行排序與生成數(shù)據(jù)塊。Fabric共識機制Kafka是一種支持多通道分區(qū)的集群時序服務，可以有序地管理消息并在多個冗余副本間保證數(shù)據(jù)一致性kafka集群的狀態(tài)由zookeeper管理，選舉leader節(jié)點kafka集群至少要四個節(jié)點，可保證在一個節(jié)點宕機后還能繼續(xù)提交交易和排序，并且創(chuàng)建新的通道zookeeper集群將會是3個、5個或7個，它的值需要是一個奇數(shù)避免split-brain情況，同時選擇大于1的值為了避免單點故障。超過7個zookeeperservers會被認為overkill可以容忍部分節(jié)點失效（crash），但不能容忍惡意節(jié)點基于zookeeper進行Paxos算法選舉，支持2f+1節(jié)點集群，f代表失效節(jié)點個數(shù)。即kafka可以容忍少于半數(shù)的共識節(jié)點失效Kafka模式的Orderer服務包含Kafka集群及相關(guān)聯(lián)的Zookeeper集群，以及許多OSN（orderingservicenode）ordering服務使用一個單Partition（每channel）接收客戶端的交易消息和TTC-X消息，在本地存儲區(qū)塊（每channel），這種解決方案能夠在性能和復雜度之間取得較好的平衡不用擔心排序服務里插入數(shù)據(jù)帶來的安全問題，因為最終記賬還需要經(jīng)過多重檢查，比如消息類型的檢查和簽名驗證、記賬節(jié)點對背書策略的驗證和交易內(nèi)容的驗證。但是其他的惡意節(jié)點攻擊的問題還是無法避免的，比如拒絕服務（丟掉交易）值得一提的是，官方的example的在kafka集群和orderer之間都是沒有安全傳輸?shù)?，切不可直接投入生產(chǎn)環(huán)境?？梢酝ㄟ^使用openssl為kafka集群生成秘鑰，增加orderer和kafka的配置以使用基于TLS的安全傳輸Fabric共識機制PBFT算法拜占庭算法支持（3f+1）的節(jié)點集群，f代表惡意節(jié)點的數(shù)量。惡意節(jié)點可能會做一些惡意偽造時序或者返回相反的錯誤的結(jié)果等三個階段：預準備（pre-prepare）、準備（prepare）、和確認（commit）從全網(wǎng)節(jié)點選舉出一個主節(jié)點（Leader），新區(qū)塊由主節(jié)點負責生成Pre-Prepare：每個節(jié)點把客戶端發(fā)來的交易向全網(wǎng)廣播，主節(jié)點0將從網(wǎng)絡收集到需放在新區(qū)塊內(nèi)的多個交易排序后存入列表，并將該列表向全網(wǎng)廣播，擴散至123Prepare：每個節(jié)點接收到交易列表后，根據(jù)排序模擬執(zhí)行這些交易。所有交易執(zhí)行完后，基于交易結(jié)果計算新區(qū)塊的哈希摘要，并向全網(wǎng)廣播，1->023，2->013，3因為宕機無法廣播Commit：如果一個節(jié)點收到的2f（f為可容忍的拜占庭節(jié)點數(shù)）個其它節(jié)點發(fā)來的摘要都和自己相等，就向全網(wǎng)廣播一條commit消息Reply：如果一個節(jié)點收到2f+1條commit消息，即可提交新區(qū)塊及其交易到本地的區(qū)塊鏈和狀態(tài)數(shù)據(jù)庫Fabric交易過程Fabric交易過程Hyperledger主要特點-1獲得許可的成員HyperledgerFabric因作為許可網(wǎng)絡的平臺而聞名，其中的所有參與者都有已知的身份。考慮許可網(wǎng)絡時，應該考慮自己的區(qū)塊鏈用例是否需要遵守數(shù)據(jù)保護法規(guī)。許多用例（具體來講，是在金融領域和醫(yī)療行業(yè)中的許多用例）都需要遵守數(shù)據(jù)保護法律，要求知道網(wǎng)絡成員和訪問特定數(shù)據(jù)的人的身份。例如，假設有一家私募股權(quán)公司。根據(jù)定義，私募股權(quán)不在證券交易所公開交易，而且它的投資者通常是風險投資公司、私募股權(quán)公司或天使投資者。此網(wǎng)絡的參與者需要是已知的，而且在資本投資方面具有可信度，然后才能參與區(qū)塊鏈。Hyperledger主要特點-2性能、可伸縮性和信任水平HyperledgerFabric構(gòu)建于一種模塊化架構(gòu)之上，該架構(gòu)將交易處理分為3個階段：分布式邏輯處理和協(xié)商（“鏈代碼”）交易訂購交易驗證和提交這種分離提供了一些優(yōu)勢：不同節(jié)點類型之間需要的信任和驗證水平更低，網(wǎng)絡可伸縮性和性能得到了優(yōu)化。Hyperledger主要特點-2在新的v1.0架構(gòu)中，僅在網(wǎng)絡上發(fā)送簽名和讀/寫集，所以可伸縮性和性能得到了優(yōu)化。此外，因為僅背書者和提交者能夠真正看到該交易，所以區(qū)塊鏈系統(tǒng)的不同部分中需要的信任水平更低，提供了更高的安全性。例如，在資本市場中，購買和銷售基于股權(quán)的證券或債務，由于參與者數(shù)量增多，所以交易量也在增加。更多的交易要求更高的可伸縮性和性能，HyperledgerFabricv1.0提供了這一優(yōu)勢，該優(yōu)勢從某種程度上講歸功于鏈代碼執(zhí)行過程的拆分。拆分鏈代碼執(zhí)行還在網(wǎng)絡中實現(xiàn)了動態(tài)增長在HyperledgerFabricv1.0中，可以動態(tài)地或以編程方式添加對等節(jié)點，而不是像v0.6中一樣靜態(tài)添加。例如，假設一家管理外匯匯率的公司要向網(wǎng)絡中添加一家新銀行。在HyperledgerFabricv1.0中，他們能夠以編程方式完成此操作。Hyperledger主要特點-3以“需要知道”為原則來公開數(shù)據(jù)由于競爭形勢、保護法律和有關(guān)個人數(shù)據(jù)機密性的法規(guī)，企業(yè)規(guī)定需要確保某些數(shù)據(jù)元素的隱私，這可以通過區(qū)塊鏈上的數(shù)據(jù)分區(qū)來實現(xiàn)。HyperledgerFabric中支持的通道允許僅將數(shù)據(jù)傳遞給需要知道的相關(guān)方。例如，許多金融實體表明擔憂競爭對手看到所處理的交易數(shù)量。一些金融機構(gòu)沒有考慮通過“足夠”的加密來保護其數(shù)據(jù)。考慮到這種情況，一些金融工具可能需要10年或更長時間才