fabric區塊鏈需要多少節點

㈡ 區塊鏈之聯盟鏈（三） 認識Fabric

Fabric 是超級賬本聯盟推出的核心區塊鏈框架，它適合在復雜的企業內和企業間搭建聯盟鏈。根據超級賬本聯盟的目標， Fabric 被建設為一個模塊化的、支持可插拔組件的基礎聯盟鏈框架。；

與以太坊系的Quorum不同，Fabric從一開始就只考慮企業間的應用。其獨有的channel概念，將企業根據業務目的不同以不同的子網連接起來， 每一個子網對應一個channel，而每個channel有自己獨立的區塊鏈。而Quorum很顯然是只有一個公網（所有企業節點都加入進去），企業與企業間的私有業務是通過Private Manager 完成的。

理解channel的最簡單方法就是，將它類比為一個消息服務提供的Topic，實際上Fabic最早就是基於Kafka 的分布式消息服務來實現。

       在Fabric網路中，一個企業可以有一個或多個節點加入整個聯盟鏈；一個企業可以加入1個或者多個Channel（子網）；  一個節點可以加入1個或者多個channel。每個channel構成一個子網，所以Fabric 是 一種由子網組成的網路。

那麼Fabric是怎麼實現智能合約的執行和完成業務上鏈（將事務結果記錄在區塊鏈里）的呢？

與其它框架不同， Fabric 將整個過程分成了三個階段：

業務背書階段 ： 客戶的請求發送的背書節點，通過智能合約完成業務的計算（但不更新狀態），並完成背書；將背書結果返回個客戶端。

業務的排序階段 ： 客戶端將背書結果通過Channel被發送到排序節點（orderer），在排序節點完成事務的排序，並打包到block里，最後下發給所有連接到channel的節點。

業務驗證並寫入賬本階段 : 通過Gossip 網路，所有Channel的節點都會接收到新的block，節點會驗證block中的每一個事務，確定是否有效：有效地將會跟新world state，無效的將會標志為「無效」，不會更新World state，但整個block會被完整的加入到帳本中（包括無效的事務）。

根據以上的描述，Fabric 節點實際可以分為  ，普通節點和Order節點：

 Peer, 普通節點, 完成背書（包括只能合約的執行）和驗證.

orderer,  排序節點，完成排序。

加入orderer節點的Fabric網路可以被描述如下：

每一個Channel，都定義了所有屬於channel的節點，但是並不需要所有節點都連接到Orderer 節點（節點間可以通過gossip 協議通訊來傳播私有數據或事務）.

       在區塊鏈中，共識是區塊鏈的基礎。與公有鏈不同，聯盟鏈的共識要求所有加入賬本的事務是確定的、最終的，也就是不可以有分叉，區塊與區塊間的順序是一定的，只存在唯一條鏈。在Fabric 中，這個客觀需求正是由排序實現的，所有的事務將被提交給orderer節點獲得確定的順序，並最終打包成block進入帳本。 Fabric 從1.4.1開始支持基於Raft實現排序服務,  可以認為基於Raft實現共識。

基於RAFT的排序服務相對於早期的Kafka 具有更好的分布性，配置更加簡單，是聯盟鏈里常用的一個常用的達成共識的演算法，Quorum就 默認使用RAFT作為共識層。簡單的說，RAFT是一個leader和follower的模式， 所有加入RAFT網路的節點，任意時候都有一個leader,  只有這個leader有權決定事務的順序，並打包成Block，其它節點只能作為follower提交事務和同步block。

基於FAFT網路，每個企業可以有一個或多個節點參與到Orderer中去。在Frabric中企業間的網路連接可以變化成如下形式：

       區塊鏈的使用用戶在乙太網中被稱作EOA（External of Account）, EOA的載體是錢包。我們沿用這個概念，來看看Fabric是如何實現用戶和發起事務的。Fabric中EOA是一個CA中心發布的certificate（x.509），一個Certificate代表一個Identity（這與以太坊還是有很大區別的， 以太坊中一個EOA其實是一個hash地址），EOA能夠參與的channel以及被授權的操作是有channel的MSP（ Membership Service  Provider）決定的（如下圖）。

註：certificate 是一種密碼學上驗證身份的通用做法； certificate包含了個人的信息，公鑰以及發布這個certificate的CA的簽名。驗證方只需要擁有這個CA的證書（包含CA的公鑰），就可以驗證這個簽名是否正確，certificate的內容是否有篡改。簡單的說，通過CA和Certificate，我們可以獲得一個可驗證的的身份和信任鏈。

      如上圖，fabric中通要使用Wallet作為EOA的載體，一個Wallet中可以包含多個Identity（x.509 certificate）。 Identity 通過 CA提供的信任鏈來驗證正確性。

  驗證了身份之後， Fabric 通過MSP在區塊鏈網路中解決該身份是否代表組織的成員和在組織內具有什麼角色。例如，channel首先會驗證當前用戶Identity是否是有效地身份，然後通過MSP查看其所處的企業和具有的角色，最終確定該用戶是否有權執行操作。

可以說，Fabric的訪問控制是通過MSP來完成的。在每一個需要訪問控制的地方都需要定義一個MSP。  例如，每個channel都定義一個MSP，這個MSP規定了在channel范圍內資源的訪問許可權。 MSP 是Fabric里一個晦澀難懂的概念，也是其賦予企業間安全訪問的基礎。

前文提到， Fabric 將業務處理和上網分成了三個部分， 背書，排序，驗證後加入賬本。

其中背書是Fabric執行智能合約的階段。以太坊中，智能合約是在EVM中執行的，有多種語言支持。 在Fabric，智能合約被稱為chaincode： 一個chaincode 可以理解為是智能合約的容器，可以包含一個或多個智能合約， 不用於EVM, chaincode是在 JVM 或NodeJS中執行。

客戶應用程序通過智能合約來訪問賬本，每一個可訪問的智能合約都被安裝在客戶端可以訪問的節點上，並被定義在channel里。（有隻能合約的節點被稱為背書節點，沒有隻能合約的節點被稱未提交節點，提交節點只維護賬本）

客戶應用提交一個交易請求， 請求到達背書節點， 背書節點首先會驗證客戶的簽名，確保客戶的身份有權執行本次交易，接著執行交易提及的智能合約（chaincode），並生成一個背書響應（或者叫做交易提案，tran-proposal）。這個背書響應中通常包含World state 的讀集合，寫集合， 以及節點對本次交易的簽名。這里與以太坊系聯盟鏈最主要的不同是： 背書階段只模擬交易，並不真正更新交易結果。 而真正更新交易在第三階段完成。背書節點最後將生成的背書響應fanhui給客戶端， 智能合約部分的執行就結束了。

通常一個交易的執行需要多方的簽名，所以客戶端需要將一個交易發送給多個背書節點，這些背書節點的選擇需要滿足背書策略的要求。

下圖是一個包含有客戶、背書節點，提交節點的網路示意圖。

根據Fabric官方的參考文檔，客戶交易的正果過程可使用下圖描述。

如上圖，從1到3，為背書階段，4為排序階段，4.1,4,2, 5為驗證提交階段。 參考 Frabic的節點 概念，可以了解更多在交易細節的概念。  

總的來看， Fabric 更專注於企業間，通過上文，可以讓大家對Fabric的基本構成與概念有一個總的了解。  Fabric本身並不神秘，都是使用的現有的企業間的技術。要更好的了解，建議參考閱讀分布式消息系統和企業的安全基礎設施（CA相關）的支持。與以太坊系聯盟鏈實現比較，  Fabric 的子網更概念對於復雜企業間應用適應更強，但是其復雜的安全考量，使得運營成本很高，另外，Fabric 使用Certificate做為用戶身份，有很大的局限性，在新的2.0里，Fabric對於此處將有所改變。

下一篇，我們將來看看Sawtooth , 由Inter 提供的區塊鏈框架。

區塊鏈之聯盟鏈(一) 認識以太坊

區塊鏈之聯盟鏈(二) 認識Quotum

區塊鏈之聯盟鏈(三) 認識Fabric

區塊鏈之聯盟鏈(四) 認識Sawtooth

㈢ Fabric 入門：Peer節點是什麼

作為區塊鏈產品經理，不需要太深入理解區塊鏈的技術，但是基本的概念必須要懂，包括網路、通道、賬本、節點、鏈碼、SDK、MSP，它們之間的關系，以及數據寫入的過程、數據查詢的過程。

首先需要明確的是，Peer節點是一個物理的概念（與之對比，通道是一個邏輯的概念，通道並沒有實體），一台伺服器可以充當Peer的作用。這台伺服器既可以是私有物理機，也可以是雲上的資源。Peer是整個Fabric體系的基礎設施，下面會解釋為什麼。

Peer節點存儲關鍵的數據，並且執行特定的程序。存儲的數據包括賬本、鏈碼（智能合約），執行的程序主要包括背書以及鏈碼的執行。所有的賬本查詢以及賬本修改必須通過鏈碼來操作，所有的鏈碼操作必須通過Peer節點在喚起，所以SDK或者應用需要存取賬本數據時，必須通過Peer。這就是為什麼說Peer是Fabric的基礎設施。

二、Peer與賬本和鏈碼的關系

剛剛說了，Peer是賬本和鏈碼的物理載體，Peer可以調動鏈碼去查詢和更新賬本。

一個Peer可以存儲0個或者多個賬本，一個Peer也可以存儲0個或者多個鏈碼。

上圖中，一個Peer節點，存儲了L1、L2兩個賬本，以及S1、S2、S3三個鏈碼，其中賬本L1可以被鏈碼S1、S2訪問到，賬本L2可以被鏈碼S1、S3訪問到。

一個組織可以有一個或者多個Peer，比如下圖中，組織2管理了P3、P4、P5三個Peer節點，。而一個Peer可以加入一個或者多個通道中，比如下圖中，P3、P5加入到紫色的這個Channel中。

還有其他的議題：Peer分為記賬節點和背書節點；發生一筆交易的時候，Peer要發生哪些操作；Peer與證書的關系。

這些議題會在介紹交易提交流程、MSP部分等部分介紹。

2018年12月6日。

㈣ Fabric上鏈流程

看看一筆交易的上鏈過程：

1. 應用提出交易，首先從客戶端發起一筆交易提交到3個Endorsing Peer，該筆交易的背書政策P（E0,E1,E2必須簽名），客戶端應用程序為智能合約提交一個交易。它必須提交給所需的對等點{E0,E1,E2}

2. 背書節點執行提議，將簽名數據，傳回給客戶端。E0、E1、E2將分別執行提出事務。這些執行都不會更新至賬本，每次執行都將獲一組讀和寫數據，稱為讀寫集，交易可以簽名與加密。

3. 應用接受回復，讀寫集將非同步返回給應用程序，讀寫集由每個背書節點簽名，並且每個都記錄了版本號(這些信息將在後面的共識過程中進行核對)。

4，交易排序，Ordering Node對交易進行排序，應用程序將背書節點的響應作為交易提交給排序節點，排序與應用程序的提交並行發生在fabric上。

5.   Orderer交付給記賬節點，order service將所有交易打包到區塊中，然後分發給提記賬節點，記賬節點可以交付給同層中的其他記賬節點。目前支持的排序演算法:Solo(單節點，開發)，Kafka(崩潰容錯)，RAFT。

6. 記賬節點驗證交易，每個記賬節點會根據背書政策進行驗證。還要檢查讀寫集對於當前世界狀態是否仍然有效。驗證有效的交易，將適用於世界狀態（world state）並保留在區塊鏈賬本上，無效的交易也保留在區塊鏈賬上，但不更新世界狀態。

7. 記賬節點通知應用程序，當交易成功或失敗時，以及當區塊被添加到分類賬時，應用程序將收到連接的記賬節點的通知(事件觸發器)。

㈤ 淺析 Fabric Peer 節點

Hyperledger Fabric，也稱之為超級賬本，是由 IBM 發起，後成為 Linux 基金會 Hyperledger 中的區塊鏈項目之一。

Fabric 是一個提供分布式賬本解決方案的平台，底層的賬本數據存儲使用了區塊鏈。區塊鏈平台通常可以分為公有鏈、聯盟鏈和私有鏈。公有鏈典型的代表是比特幣這些公開的區塊鏈網路，誰都可以加入到這個網路中。聯盟鏈則有準入機制，無法隨意加入到網路中，聯盟鏈的典型例子就是 Fabric。

Fabric 不需要發幣來激勵參與方，也不需要挖礦來防止有人作惡，所以 Fabric 有著更好的性能。在Fabric 網路中，也有著諸多不同類型的節點來組成網路。其中 Peer 節點承載著賬本和智能合約，是整個區塊鏈網路的基礎。在這篇文章中，會詳細分析 Peer 的結構及其運行方式。

在本文中，假設讀者已經了解區塊鏈、智能合約等概念。

本文基於 Fabric1.4 LTS。

區塊鏈網路是一個分布式的網路，Fabric 也是如此，由於 Fabric 是聯盟鏈，需要准入機制，所以在網路結構上會復雜很多，下面是一個簡化的 Fabric 網路：

各個元素的含義如下：

對於 Fabric 網路，外部的用戶需要通過客戶端應用，也就是圖中的 A1、A2 或者 A3 來訪問網路，客戶端應用需要通過 CA 證書表明自己的身份，這樣才能訪問到 Fabric 網路中有許可權訪問的部分。

在上面的網路中，共有四個組織，R1、R2、R3 和 R4。其中 R4 是整個 Fabric 網路的創建者，網路是根據 NC4 配置的。

在 Fabric 網路中，不同的組織可以組成聯盟，不同的聯盟之間數據通過 Channel 來隔離。Channel 中的數據只有該聯盟中的組織才能訪問，每一個新的 Channel 都可以認為是一條新的鏈。與其他的區塊鏈網路中通常只有一條鏈不一樣，Fabric 可以通過 Channel 在網路中快速的搭建出一個新的區塊鏈。

上面 R1 和 R2 組成了一個聯盟，在 C1 上交易。R2 同時又和 R3 組成了另外一個聯盟，在 C2 上交易。R1 和 R2 在 C1 上交易時，對 R3 是不可見的，R2 和 R3 在 C2 上交易時，對 R1 是不可見的。Channel 機制提供了很好的隱私保護能力。

Orderer 節點是整個 Fabric 網路共有的，用來為所有的交易排序、打包。比如上面網路中 O4 節點。本文不會對 Orderer 節點進行詳細說明，可以把這個功能理解為比特幣網路中的挖礦過程。

Peer 節點表示網路中的節點，通常一個 Peer 就表示一個組織，Peer 是整個區塊鏈網路的基礎，是智能合約和賬本的載體，Peer 也是本文討論的重點。

一個 Peer 節點可以承載多套賬本和智能合約，比如 P2 節點，既維護了 C1 的賬本和智能合約，也維護了 C2 的賬本和智能合約。

為了可以更深入了解 Peer 節點的作用，先了解一下 Fabric 整體的交易流程。整體的交易流程圖如下：

Peer 節點按照功能來分可以分為 背書節點 和 記賬節點 。

客戶端會提交交易請求到背書節點，背書節點開始模擬執行交易，在模擬執行之後，背書節點並不會去更新賬本數據，而是把這個交易進行加密和簽名，然後返回給客戶端。

客戶端收到這個響應之後就會把響應提交到 Orderer 節點，Orderer 節點會對這些交易進行排序，並打包成區塊，然後分發到記賬節點，記賬節點就會對交易進行驗證，驗證結束之後，就會把交易記錄到賬本裡面。

一筆交易是否能成功是根據背書策略來指定的，每一個智能合約都會指定一個背書策略。

Peer 節點代表著聯盟鏈中的各個組織，區塊鏈網路也是由 Peer 節點來組成的，而且也是賬本和智能合約的載體。

通過對上面交易過程的了解可以知道，Peer 節點是主要的參與方。如果用戶想要訪問賬本資源，都必須要和 peer 節點進行交互。在一個 Peer 節點中，可以同時維護多個賬本，這些賬本屬於不同的 Channel 。每個 Peer 節點都會維護一套冗餘賬本，這樣就避免了單點故障。

Peer 節點根據在交易中的不同角色，可以分成背書節點（Endorser）和記賬節點（Committer），背書節點會對交易進行模擬執行，記賬節點才會真正將數據存儲到賬本中。

賬本可以分成兩個部分，一部分是區塊鏈，另一部分是 Current State，也被稱之為 World State。

區塊鏈上只能追加，不能對過去的數據進行修改，鏈上也包含兩部分信息，一部分是通道的配置信息，另一部分是不可修改，序列化的記錄。每一個區塊記錄前一個區塊的信息，然後連成鏈，如下圖所示：

第一個區塊被稱之為 genesis block，其中不存儲交易信息。每個區塊可以被分為 區塊頭 、 區塊數據 和 區塊元數據 。區塊頭中存儲著當前區塊的區塊號、當前區塊的 hash 值和上一個區塊的 hash 值，這樣才能把所有的區塊連接起來。區塊數據中包含了交易數據。區塊元數據中則包括了區塊寫入的時間、寫入人及簽名。

其中每一筆交易的結構如下，在 Header 中，包含了 ChainCode 的名稱、版本信息。Signature 就是交易發起用戶的簽名。Proposal 中主要是一些參數。Response 中是智能合約執行的結果。Endorsements 中是背書結果返回的結果。

WorldState中維護了賬本的當前狀態，數據以 Key-Value 的形式存儲，可以快速查詢和修改，每一次對 WorldState 的修改都會被記錄到區塊鏈中。WorldState 中的數據需要依賴外部的存儲，通常使用 LevelDB 或者 CouchDB。

區塊鏈和 WorldState 組成了一個完整的賬本，World State 保證的業務數據的靈活變化，而區塊鏈則保證了所有的修改是可追溯和不可篡改的。

在交易完成之後，數據已經寫入賬本，就需要將這些數據同步到其他的 Peer，Fabric 中使用的是 Gossip 協議。Gossip 也是 Channel 隔離的，只會在 Channel 中的 Peer 中廣播和同步賬本數據。

智能合約需要安裝到 Peer 節點上，智能合約是訪問賬本的唯一方式。智能合約可以通過 Go、Java 等變成語言進行編寫。

智能合約編寫完成之後，需要打包到 ChainCode 中，每個 ChainCode 中可以包含多個智能合約。ChainCode 需要安裝，ChainCode 需要安裝到 Peer 節點上。安裝好了之後，ChainCode 需要在 Channel 上實例化，實例化的時候需要指定背書策略。

智能合約在實例化之後就可以用來與賬本進行交互了，流程圖如下：

用戶編寫並部署實例化智能合約之後，就可以通過客戶端應用程序來向智能合約提交請求，智能合約會對 WorldState 中數據進行 get、put 或者 delete。其中 get 操作直接從 WorldState 中讀取交易對象當前的狀態信息，不會去區塊鏈上寫入信息，但 put 和 delete 操作除了修改 WorldState，還會去區塊鏈中寫入一條交易信息，且交易信息不能修改。

區塊鏈上的信息可以通過智能合約訪問，也可以在客戶端應用通過 API 直接訪問。

Event 是客戶端應用和 Fabric 網路交互的一種方式，客戶端應用可以訂閱 Event，當 Event 發生時，客戶端應用就會接受到消息。

事件源可以兩類，一類是智能合約發出的 Event，另一類是賬本變更觸發的 Event。用戶可以從 Event 中獲取到交易的信息，比如區塊高度等信息。

在這篇文章中，首先介紹了 Fabric 整體的網路架構，通過對 Fabric 交易流程的分析，討論了 peer 節點在交易中的作用，然後詳細分析了 peer 節點所維護的賬本和智能合約，並分析了 peer 節點維護賬本以及 peer 節點執行智能合約的流程。

文 / Rayjun

[1] https://hyperledger-fabric.readthedocs.io/zh_CN/release-1.4/whatis.html

[2] https://developer.ibm.com/zh/technologies/blockchain/series/os-academy-hyperledger-fabric/

[3] https://en.wikipedia.org/wiki/Gossip_protocol

㈥ 區塊鏈的TPS

眾所周知，比特幣每秒只能進行大約7筆交易，以太坊稍微好一些，也就10-20筆。作為一個支付系統，這是遠遠遠遠不夠的，經常也有人拿這點來說事，認為區塊鏈效率低雲雲。

其實現在有很多的方案在試圖解決TPS的問題，比如說fabric可以到數千的TPS，石墨烯系列可以到上萬的TPS，比特幣和以太坊的Off-chain方案理論上支持無限的TPS。那麼是不是說這些新的技術才是區塊鏈的未來呢？這個問題總是很難回答，要說一大堆共識，分布式，安全之類的事情。

過年期間看了BM的一個訪談，他提到了VB的一個理論，Scalability，Decentralization和Security在區塊鏈中不能兼顧，類似於分布式系統裡面的CAP理論。

我發現這個理論用來解釋區塊鏈技術真是簡單粗暴而有效。

比如說：聯盟鏈通過准入機制，控制了驗證節點的數量，通過犧牲Decentralization提升了Scalability；石墨烯系列的DPOS，RippleNet的共識也是同理；比特幣通過提高每個區塊的容量，也可以達到擴容的目的，但結果是對礦機提出了更高的要求，形成自然的准入門檻，實際上也是犧牲了Decentralization；比特幣和以太坊挖礦難度都可以調整，降低挖礦難度實際上也可以提升Scalability，但付出的代價是抗攻擊能力下降了，犧牲的是Security。

但這個理論放在off-chain類型的方案上就失效了，比如說閃電網路（雷電網路），以太坊的plasma還有R3 Corda（這個比較特殊，直接把鏈都省了）。對off-chain方案原理感興趣的童鞋移步這里， http://www.8btc.com/ln-rn-corda 。大致方案就是交易雙方鎖定準備金，把海量的交易打包以後上鏈，鏈上只保存交易的最終結果。通過智能合約和線下的多重簽名機制，作弊方將會被罰沒准備金。

Off-chain方案看上去很完美，保證Decentralization和Security，同時無限擴展。

但天下沒有免費的午餐，我們以閃電網路為例（事實上plasma我還沒完全理解😅），至少它有下面幾個缺點：

1.閃電網路中鎖定的比特幣只能用在閃電網路中，只有交易通道關閉的時候才能真正成為鏈上承認的貨幣，這在理論上會出現類似銀行擠兌的情況。如果大家對閃電網路失去信心，集中關閉通道，會拖垮比特幣網路。但，這個似乎也不是很大的問題，只要閃電網路沒有爆出什麼漏洞，比如說簽名演算法被攻破之類的。

2.交易是在鏈外執行，鏈上無法驗證提交的交易是否最新版本，雖然腳本保證了提交舊版本交易的攻擊者有被罰沒准備金的風險，但前提是要防禦者監控網路並提交更新版本交易的證據。也就是說從原來比特幣的被動防禦（私鑰不丟失就能保證資金安全）轉變成主動防禦。從這個角度看也算是降低了Security吧。這個主動防禦的操作交給用戶也不太現實，最終必然會衍生出一些服務公司，代替用戶保存鏈外交易憑證，並防止作弊。某種意義上面又從「去中介化的信任」轉變為需要信任中介了。這個角度看，似乎也是犧牲了Decentralization。

3.閃電網路中只有保存最終的資金狀態保存，中間的交易細節全部被忽略，支持者認為是保護了用戶的隱私，反對者認為是損失了交易數據。

4.因為通道需要准備金維持，不可能任意兩個用戶間都存在交易通道，用戶之間轉賬可以通過中轉的方法，最終很可能會有大資金形成中心化的中轉節點。

㈦ fabric國密改造記錄及思路-具體工作(3)

七、msp成員關系服務模塊改造

       (1)、fabric的成員身份基於標準的x509證書,秘鑰使用的是ECDSA演算法,利用PKI體系給每個成員頒發數字證書，通道內只有  相同MSP內的節點才可以通過Gossip協議進行數據分發;

       (2)、國密改造需要把x509證書修改成sm2證書,ECDSA演算法修改成sm2演算法；

       (3)、修改程序文件列表如下： 

             msp/identities.go

             msp/cert.go

            msp/mspimplsetup.go

            msp/mspimplvalidate.go

           msp/mspimpl.go

八、Orderer節點模塊改造

       (1)、orderer節點在fabric架構中處於最核心位置,主要功能是排序打包交易，生成新的區塊，然後通過共識演算法將數據廣播;

       (2)、orderer節點模塊的共識模式有，solo單機模式,kafka消息隊列模式,etcdraft一致性演算法模式，最開始採用的是kafka模式，後邊為了減少資源開銷切換成etcdraft模式；

       (3)、如果採用kafka模式共識，需要確認kafaka的tls連接是否支持國密演算法,再決定是否對kafka的tls做出修改；

       (4)、改程序文件列表如下：

             orderer/common/cluster/comm.go

             orderer/common/cluster/connections.go

             orderer/consensus/kafka/config.go

九、Peer節點模塊改造

        (1)、peer可是區塊鏈網路的基石，包含了賬本和鏈碼，應用程序或管理員都得通過節點去管理網路的資源；

        (2)、channel對應賬本，一個peer節點可以接入到多個channel， 所以一個節點可以有多個賬本副本;

        (3)、國密改造中對chaincode和common部分有修改;

        (4)、改程序文件列表如下：

               peer/common/common.go

               peer/common/peerclient.go

               peer/common/ordererclient.go

               peer/chaincode/common.go 

十、vendor目錄國密改造

     （1）、修改程序文件列表如下：

                vendor/github.com/Shopify/sarama/config.go

總結:

       到目前為止fabric的國密修改已經完成，修改完畢後通過前面提到的編譯方式進行編譯，然後進行測試,如有bug再增對性的進行處理,遇到問題和解決問題是比較好的熟悉系統的方式。

㈧ (譯)超級賬本官方文檔 基本概念(三) - 節點(Peer)

超級賬本是Linux基金會發起的項目，意在提供一套企業級區塊鏈應用框架，便於大家開發基於區塊鏈技術的應用。

Fabric的基本概念

最開始，應用程序會選出一組peer來生成賬本更新提議。哪些peer會被選出來是依據的背書策略，這個背書策略決定了哪些組織需要在廣播賬本更新提議前對更新提議進行背書。這會影響到共識方式，任何一個關心更新提議是否背書的組織都會在廣播給peer更新提議並被peer接受前確認提議是否有背書。

peer對一個提議響應進行背書，就是把自己的數字簽名加入到響應中，並用自己的私鑰對整個響應簽名。背書內容隨後可以被用於證明這個響應是某個組織的peer生成的。在我們的例子中，如果peer P1屬於組織1(Org1)，那麼背書E1就相當於可以證明L1上的交易T1和響應R1是由Org1的peer P1提供的。

當應用程序得到了足夠多的簽名的提議響應時，第一階段就結束了。
我們注意到peer可能返回不同的信息，因此同一筆交易可能有不一致的返回信息。這可能由於響應是在不同時間，不同peer，在不同賬本狀態下生成的，大多數情況下應用程序可以多次請求更新的提議響應。另外更嚴重，但概率很小的原因是因為鏈碼的不確定性導致的響應不一致。不確定性是鏈碼和賬本的大敵，如果這種情況發生了，對提議交易來說是很嚴重的，不一致的提議響應肯定不能提交到賬本中。一個獨立的節點是不可能知道交易結果是非確定性的交易，在檢測到非確定性交易前，必須將交易匯總比較(嚴格地說，即使這還不夠，但我們將此討論推遲到交易部分，其中詳細討論了非確定性)。

在第一階段結束時，如果應用程序希望如此的話，可以放心丟棄不一致的響應以提前結束交易流程。後面我們會看到如果應用程序使用不一致的響應提交到賬本時，會被拒絕。

過程2 打包
第二個交易流程是打包。Orderer節點這個過程關鍵的點，它接收來自很多應用傳來的背書過的提議交易響應。Orderer對交易進行排序，並將大量的交易打包進區塊，並准備將區塊分發到所有連接到Orderer的peer，包括背書peer。

orderer的第一個角色就是打包賬本更新提議。在上圖的例子中，應用A1發送給Orderer O1一個被E1和E2背書的交易T1。同時，應用A2發送給Orderer O1一個被E1背書的交易T2。O1將A1傳來的交易和A2傳來的交易以及其它交易共同打包進區塊B2。我們可以看到區塊B2里的交易排序是T1，T2，T3，T4，T6，T5，並不一定是按照到達orderer節點的順序(這個例子展示了一個非常簡單的orderer配置)。

Orderer節點會同時收到網路Channel中不同應用程序發送的賬本更新提議。Orderer節點的任務就是按照事先定義好的順序整理這些更新提議，並把它們打包進區塊，為下一步的分發做准備。這些區塊將構成區塊鏈。一旦Orderer節點生成了期望大小的區塊，或者超過最大等待時間，Orderer會向連接到它特定Channel的Peer發送區塊。第三個過程會詳述這個流程。

區塊中的交易排列順序和交易到達Orderer節點的順序沒有直接關系。交易在區塊中可以是任意的排列順序，這個次序就是交易執行的順序。重點是有一個嚴格的交易排序，但具體是怎樣的排序並不重要。

區塊中的嚴格交易順序排列使得Fabric與公鏈中一筆交易可以被打包進多個不同區塊的情況不同。在Fabric中，這不可能發生，由多個Orderer生成的區塊就是最終的區塊，因為交易被寫入區塊後，交易的位置順序就確定了。這意味著Fabric不會存在分叉。一旦交易被寫入區塊，以後就不能再重寫了。

我們可以看到，peer是存儲賬本和鏈碼的，orderer完全不會存儲這些。每一筆交易到達orderer時，orderer只是機械的將交易打包進區塊，而不會理會交易的價值，額度等。這是Fabric的一個重要特性，所有交易都會按照一個嚴格的順序進行整理，沒有交易會被拋棄掉。

到第二階段結束時，我們可以了解到orderer的責任就是進行必要的，簡單的收集交易更新提議，將他們排序，打包進區塊，准備分發出去。

過程3 認證
最後一個交易工作流程是分發和驗證從orderer到peer的區塊，如果驗證成功，將會被提交到賬本中。
特別的，在每個peer中，在區塊中的每一筆交易在更新到賬本之前都是驗證過的，以保證所有交易都是由相關的組織背書過的。失敗的交易會保留，作為日後審查用，並不會更新到賬本中。

Orderer除了在過程2中的打包角色外，在過程3中還負責分發區塊到peer節點。在這個例子中，O1分發區塊到P1和P2。P1處理區塊2，然後將區塊2添加到P1的賬本L1中。同時，P2處理區塊2，然後將區塊2添加到P2的賬本L1中。一旦操作完成，賬本L1在P1和P2中都被更新了，每個Peer都可以向連接到他們的應用程序發送處理結果。

Orderer向連接到他的Peer分發區塊是過程3的開始。連接到orderer節點的某個渠道的peer，會收到orderer生成的新區塊的一份拷貝。每個peer節點都會獨立的處理收到的區塊，但所有peer處理區塊的方式都是相同的。採用這種方式，不同peer中的賬本可以達成共識。並不是所有的peer都必須連接到orderer節點，peer和peer之間可以通過gossip協議來傳遞區塊，這樣peer也可以獨立的處理相同區塊。

收到一個區塊後，peer會按照交易在區塊中出現的順序依次處理。對於每一筆交易，peer會按照生成這筆交易的鏈碼背書策略檢查交易是否被與之相關組織的背書。例如，某些交易可能只需要一個組織背書，而另一些交易需要多個組織同時背書才有效。這個驗證過程驗證了所有相關組織產生的結果或者輸出是否一致。同時請注意，第三階段的驗證和第一階段不同，階段一隻是應用程序收到背書節點的響應，判斷是否需要發送交易提議。如果應用程序發送錯誤的交易，違反了背書策略，在第三階段的驗證過程中peer還是可以拒絕本次交易。

如果交易背書正確，peer將嘗試把交易提交到賬本中。為了能寫賬本，peer必須進行賬本一致性檢查，保證當前賬本的狀態與賬本更新後的狀態一致。這個狀態並不總會是一致的，即使交易擁有完整的背書。舉個栗子，另外一筆交易可能已經更新了賬本中的同一個資產，以至於我們正要更新的交易將永遠不會被寫入賬本。這樣的話，每個節點中的賬本必須通過網路保持共識，每個節點的驗證方式是一樣的。

在peer驗證完每筆獨立交易後，將更新賬本。失敗的交易會保存下來作為審查資料。這意味著peer中的區塊和從orderer中收到的區塊一致，除了區塊中指示交易成功或失敗的標志。

我們也要注意到，第三階段並沒有執行鏈碼，這一步只會在第一階段完成，這很重要。這意味著鏈碼只在背書節點可用，而不是整個網路中都可用，這保證了鏈碼在背書組織中的安全及私密。這和收到鏈碼的執行結果不同，執行結果會分享到所有在Channel里的peer，不論他是否能背書交易。背書節點的這種設計方式是為了方便擴展。

最後，每次區塊被提交到peer的賬本中時，這個peer會生成對應的事件。區塊事件包含區塊的所有內容，而區塊交易事件只包含簡要信息，比如每筆區塊中的交易是否有效。由鏈碼的執行而產生的鏈碼事件也可以在這個時候發布。應用程序可以注冊這些事件，當這些事件發生時，可以收到通知。這些通知在交易工作流程的第三階段和最後階段完成。

總的來說，我們可以知道第三階段由orderer產生的區塊被不斷地同步到賬本中。區塊中交易的嚴格排序能讓每個peer在區塊鏈網路中始終如一地驗證交易並提交到賬本中。

Orderer和共識
整個交易工作流程被稱為共識，因為所有peer都認同交易的排序和內容，在執行過程中由orderer節點來協調。共識是多步驟的過程，應用程序只會在共識過程結束時收到通知，但通知的時間在不同的peer上可能不同。

我們將會在後面更多的探討orderer，現在，把orderer僅僅當做從應用程序收集、分發賬本更新提議到peer，由peer進行驗證及更新賬本的過程。

㈨ 主流區塊鏈技術有哪些

本文試圖對區塊鏈有關技術流派和主流平台進行一個概覽，作為學習區塊鏈技術體系的導覽，意在拋磚引玉，促進區塊鏈開發社區的討論與共識。區塊鏈技術的流派未戰先謀局，你想投入區塊鏈開發這個領域，至少先要搞清楚現在有哪些玩家，各自的主張和實力如何。劃分區塊鏈技術流派並無一定之規，據我所見，或可有以下四種方式：第一是按照節點准入規則，劃分為公有鏈、私有鏈和聯盟鏈。公有鏈的代表自然是比特幣和以太坊，私有鏈則以R3 Corda聲名最盛，聯盟鏈的代表作品是Hyperledger名下的Fabric。公有鏈注重匿名性與去中心化，而私有鏈及聯盟鏈注重高效率，而且還往往設置了准入門檻。公有鏈、私有鏈與聯盟鏈之間的這些不同都在技術中有所體現，比如私有鏈和聯盟鏈假設節點數目不大，可以採用PBFT演算法來形成共識。而公有鏈假設有大量且不斷動態變化的節點網路，用PBFT效率太低，只能採用類似抽彩票的演算法來確定意見領袖。這就意味著，私有鏈與聯盟鏈很難變成公有鏈，而用公有鏈來作聯盟鏈或私有鏈雖然容易，卻也並非即插即用。此種差異，學者不可不察。第二是按照共享目標，劃分為共享賬本和共享狀態機兩派。比特幣是典型的共享賬本，而Chain和BigchainDB也應屬此類，這幾個區塊鏈系統在各個節點之間共享一本總賬，因此對接金融應用比較方便。另一大類區塊鏈系統中，各個節點所共享的是可完成圖靈完備計算的狀態機，如以太坊、Fabric，它們都通過執行智能合約而改變共享狀態機狀態，進而達成種種復雜功能。第三是按照梅蘭妮· 斯旺所描述的代際演進，將區塊鏈系統分為1.0、2.0和3.0三代。其中1.0支撐去中心化交易和支付系統，2.0通過智能合約支撐行業應用，3.0支撐去中心化的社會體系。比特幣和Chain應屬於區塊鏈1.0系統，而以太坊和Fabric是區塊鏈2.0系統，目前尚無成功的區塊鏈3.0系統出現，不成功的嘗試倒是有那麼一個，就是著名的The DAO。第四是按照核心數據結構，分為區塊鏈和分布式總賬兩派。區塊鏈這一派在系統中真的實現了一個區塊的鏈作為核心數據結構，而分布式總賬這一派，只是吸取了區塊鏈的精神，並沒有真用一條區塊鏈作為核心數據結構，或者雖然暫時用了，但聲明說吾項庄舞區塊鏈，意在分布式總賬耳，若假以時日，因緣際會，未嘗不可取而代之也。主流區塊鏈技術平台了解流派劃分，仍是只能用來指點江山，吹牛論道，要動手，總要有個切入點。區塊鏈貨幣據說已經有上千個了，但值得關注的技術平台大概只有數十個，而如果要進入區塊鏈開發領域，打下一個好基礎，練出一身好功夫，撈到幾個好offer，則值得深入研究學習的平台，屈指可數。首先當然是比特幣。比特幣作為區塊鏈的第一個也是目前為止最成功、最重要的樣板工程，已經上線運行了八年多，本身沒有發生任何嚴重的安全和運維事故，其穩定與強悍堪稱當代軟體系統典範。比特幣Bitcoin Core是一個代碼質量高、文檔良好的開源軟體，從學習區塊鏈原理、掌握核心技術的角度來說，Bitcoin Core是最佳切入點，能夠學到原汁原味的區塊鏈技術。當然，Bitcoin Core是用C++寫的，而且用了一些C++11和Boost庫的機制，對學習者的C++水平提出了較高的要求。學習比特幣平台開發還有一個優勢，就是可以對接繁榮的比特幣技術社區。目前圍繞比特幣進行改進和提升的人很多，人多力量就大，諸如隔離驗證、閃電網路、側鏈等比較新的想法和技術，都率先在比特幣社區里落地。比如側鏈技術的主要領導者Blockstream是由密碼學貨幣元老Adam Back領銜的，而Blockstream是Bitcoin Core最大的貢獻者之一，所以一些有關側鏈的技術在比特幣社區里討論最充分。但比特幣作為一個典型的區塊鏈1.0系統，是不是支撐其他類型區塊鏈應用的最佳技術平台，存在很大的爭議。另外，也不是所有人都有能力和必要精通區塊鏈底層技術。所以對那些急於沖到區塊鏈領域里做（quān）事（qián）的人來說，可能更直截了當的學習目標是以太坊和Hyperledger Fabric。在以太坊上面用Solidity進行的智能合約開發是切入區塊鏈開發最簡單的方式，沒有之一。以太坊的理想非常宏大，由於配備了強大的圖靈完備的智能合約虛擬機，因此可以成為一切區塊鏈項目的母平台，是馱住整個區塊鏈世界的大烏龜。在以太坊上開發一個類似比特幣的加密貨幣，是一個不折不扣的小目標。一般有經驗的開發者在文檔指導下，半天到一天即可入門。問題在於，入門以後又如何？靠寫Solidity是否就可以包打天下？這是大大存疑的。我們也可以反過來說，如果以太坊+Solidity是區塊鏈的終極解決方案，那麼怎麼還會出現那麼多區塊鏈技術門派呢？特別是，以太坊似乎並沒有給現實世界中巨型的中心化組織們留下一條活路，這種徹底不妥協的革命態度有可能也成為以太坊推廣的障礙。當前以太坊項目的開發進展並不順利。一個比較突出的問題是項目過多，力量分散，導致項目質量參差不齊。但盡管如此，跟其他區塊鏈2.0平台相比，以太坊提供的開發環境是最簡單最完善的。初學區塊鏈的人絕對有必要學習以太坊，從而對區塊鏈和智能合約建立起一個最「正宗」的認識。主流區塊鏈技術平台的第三支就是Fabric，它是Hyperledger的第一個也是最知名的孵化項目。 Fabric最早來自IBM的Open Blockchain項目，到2015年11月，IBM將當時已經開發完成的44,000行Go語言代碼交給Linux基金會，並入Hyperledger項目之中。在2016年3月一次黑客馬拉松中，Blockstream和DAH兩家公司將各自的代碼並入Open Blockchain，隨後改名為Fabric。到目前為止，Fabric與Intel提供的Sawtooth Lake並列為Hyperledger的一級孵化項目，但前者得到的關注遠超後者。從技術角度來說，Fabric思路不錯，重點是滿足企業商用的需求，比如解決交易量問題。眾所周知，比特幣最大的短板是它每秒鍾7個交易的上限，完全無法滿足現實需要。而Fabric目標是實現每秒鍾10萬交易，這個量接近剛剛過去的雙十一交易量瞬時峰值，完全可以滿足正常條件下的行業級應用。Fabric用Go語言開發，也提供多種語言的API。特別值得一提的是，Fabric比較充分地運用了容器技術，比如其智能合約就運行在容器當中。這也是Go語言帶給Fabric的一項福利，因為Go語言靜態編譯部署的特徵很適合開發容器中的程序。Fabric還有一些特點，比如其membership服務可以設置節點准入審查，這是典型的聯盟鏈特徵。再比如其共識演算法是可定製的。Fabric的短板是體系較為復雜，雖有文檔，但缺少經驗的開發者學習起來障礙比較大。然而由於其定位清楚，迎合了不少企業的心態，所以已經有多家機構在基於Fabric秘密研發行業內的聯盟鏈項目。