peer節點區塊鏈

❶ (譯)超級賬本官方文檔 基本概念(三) - 節點(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進行驗證及更新賬本的過程。

❷ 淺析 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