排序服務
許多分散式區塊鏈，如以太坊（Ethereum）和比特幣（Bitcoin），都是非許可的，這意味著任何節點都可以參與共識過程，在共識過程中，交易被排序並打包成區塊。因此，這些系統依靠概率共識演算法最終保證賬本一致性高的概率，但仍容易受到不同的賬本（有時也稱為一個賬本“分叉”），在網路中不同的參與者對於交易順序有不同的觀點。

Hyperledger Fabric 的工作方式不同。它有一種稱為排序節點的節點使交易有序，並與其他排序節點一起形成一個排序服務。因為 Fabric 的設計依賴於確定性的共識演算法，所以 Peer 節點所驗證的區塊都是最終的和正確的。賬本不會像其他分散式的以及無需許可的區塊鏈中那樣產生分叉。

排序節點和通道配置
除了排序角色之外，排序節點還維護著允許建立通道的組織列表。

排序節點還對通道執行基本訪問控制，限制誰可以讀寫資料，以及誰可以配置資料。請記住，誰有權修改通道中的配置元素取決於相關管理員在建立聯盟或通道時設定的策略。配置交易由排序節點處理，因為它需要知道當前的策略集合，並根據策略來執行其基本的訪問控制。在這種情況下，排序節點處理配置更新，以確保請求者擁有正確的管理許可權。如果有許可權，排序節點將根據現有配置驗證更新請求，生成一個新的配置交易，並將其打包到一個區塊中，該區塊將轉發給通道上的所有節點。然後節點處理配置交易，以驗證排序節點批准的修改確實滿足通道中定義的策略。

排序節點和身份

與區塊鏈網路互動的所有東西，包括節點、應用程式、管理員和排序節點，都從它們的數字證書和成員服務提供者（MSP）定義中獲取它們的組織身份。

Peer 節點和排序節點，確保了賬本在每個 Peer 節點上都具有最新的賬本。在這個例子中，應用程式 A 連線到了 P1 並且呼叫了鏈碼 S1 來查詢或者更新賬本 L1。P1 呼叫了鏈碼 S1 來生成提案響應，這個響應包含了查詢結果或者賬本更新的提案。應用程式 A 接收到了提案的響應，對於查詢來說，流程到這裡就結束了。對於更新來說，應用程式 A 會從所有的響應中建立一筆交易，它會把這筆交易傳送給排序節點 O1 進行排序。O1 會蒐集網路中的交易並打包到區塊中，然後將這些區塊分發到所有 Peer 節點上，包括 P1。P1 再把交易提交到賬本 L1 之前對交易進行驗證。當 L1 被更新之後，P1 會生成一個事件，該事件會被 A 接收到，來標識這個過程結束了。

Peer 節點可以馬上將查詢的結果返回給應用程式，因為滿足這個查詢的所有資訊都儲存在 Peer 節點本地的賬本副本中。Peer 節點從來不會為了應用程式的查詢返回結果而去詢問其他 Peer 節點的。但是應用程式還是能夠連線到一個或者多個 Peer 節點來執行一個查詢；比如，為了協調在多個 Peer 節點間的一個結果，或者當懷疑資料不是最新的時候，需要從不同的 Peer 節點獲得更新的結果。在這個圖示中，你能夠看到賬本查詢是一個簡單的三步流程。

更新交易和查詢交易起點相同，但是有兩個額外的步驟。儘管更新賬本的應用程式也會連線到 Peer 節點來呼叫鏈碼，但是不像查詢賬本的應用程式，一個獨立的 Peer 節點目前是不能進行賬本更新的，因為其他的 Peer 節點必須首先要同意這個變動（即達成共識）。因此，Peer 節點會返回給應用程式一個被提案過的更新，這個 Peer 節點會依據其他節點之前的協議來應用這個更新。第一個額外的步驟，也就是第四步，要求應用程式將響應的提案過的更新發送到網路中，網路中的 Peer 節點會將交易提交到它們相應的賬本中。應用程式會收到排序節點打包了交易的區塊，然後將他們分發到網路中所有的 Peer 節點，在區塊被更新到每個 Peer 節點本地賬本的副本中之前，這些區塊都需要被驗證。排序流程需要一定時間來完成 (數秒鐘)，因此應用程式會被非同步通知，像步驟五中展示的那樣。

Peer 節點和通道
使得區塊鏈網路中各個元件能夠進行交流和私密交易的機制。

這些元件通常是 Peer 節點、排序節點和應用程式，並且通過加入通道的方式，表明他們同意在哪個通道中通過互相合作來共享以及管理完全一致的賬本副本。概念上來說，你可以把通道想象為類似於一個由朋友組成的群組一樣（儘管一個通道中的成員不需要是朋友！）。一個人可能會有很多個群組，在每個群組中他們會共同地進行一些活動。這些群組可能是完全獨立的（一個工作夥伴的群組和一個興趣愛好夥伴的群組），或者群組間可能會有交叉的部分。然而，每個群組都是它自己的實體，具備某種”規則”。

通道允許區塊鏈網路中特定的一些 Peer 節點以及應用程式來彼此互動。在這個例子中，應用程式 A 能夠直接同 Peer 節點 P1 和 P2 使用通道 C 進行溝通。你可以把通道想象為在某些應用程式和 Peer 節點之間進行通訊的小路。（排序節點沒有顯示在這個圖中，但是在工作網路中它必須存在。）

我們可以看到通道和 Peer 節點是以不同的方式存在的，將通道理解為由物理的 Peer 節點的組成的邏輯結構更合適一些。理解這一點很重要，因為 Peer 節點提供了對通道訪問和管理的控制。

Peer 節點和組織
區塊鏈網路是由多個組織來管理的，而不是單個組織。對於如何構建這種型別的分散式網路，Peer 節點是核心，因為他們是由這些組織所有，也是這些組織同這個網路的連線點。

四個Org擁有八個Peer。網路N中的通道C連線了這些Peer節點中的5個。組織中擁有的其他節點還有沒有加入該通道的。通常每個節點都會加入至少一個通道。

真正重要的是，你能夠看到在形成一個區塊鏈網路的時候都發生了什麼。這個網路是由多個組織來組成並維護的，這些組織向這個網路貢獻資源。Peer 節點是我們在這個話題中正在討論的資源，但是一個組織提供的資源不僅僅是 Peer 節點。這裡有一個工作原則：如果組織不為這個網路貢獻他們的資源，這個網路是不會存在的。更關鍵的是，這個網路會隨著這些互相合作的組織提供的資源而增長或者萎縮。

在 上邊的例子 中，你能夠看到（除了排序服務），這裡沒有中心化的資源，如果這些組織不貢獻他們的節點的話，網路 N 是不會存在的。這反應了一個事實，除非並且直到組織貢獻了他們的資源才會形成這樣一個網路，否則這個網路沒有存在的意義。另外，這個網路不依賴於任何一個單獨的組織，只要還存在一個組織，網路就會繼續存在，不管其他的組織加入或者離開。這就是去中心化網路的核心。

就像上邊的例子，在不同的組織中的應用程式可能相同也可能不同。這完全取決於組織想要他們的應用程式如何處理他們的 Peer 節點的賬本副本。這意味著應用程式和展示邏輯可能在不同組織間有很大的不同，儘管他們的 Peer 節點維護著完全相同的賬本資料。

應用程式會連線到他們組織的 Peer 節點或者其他組織的 Peer 節點，取決於賬本互動的需求。對於查詢賬本的互動，應用程式通常會連線到他們自己組織的 Peer 節點。對於更新賬本的互動，之後我們會看到為什麼應用程式需要連線到多個 Peer 節點，這些節點是每一個要為賬本更新進行背書的組織的代表。

Peer 節點和身份
Peer 節點會有一個身份資訊被分給他們，這是通過一個特定的證書認證機構頒發的數字證書來實現的。你可以在本指南的其他地方閱讀更多的關於 X.509 數字證書是如何工作的，但是，現在，就把數字證書看成是能夠為 Peer 節點提供可驗證資訊的身份證。在網路中的每個 Peer 節點都會被所屬組織的管理員分配一個數字證書。

當 Peer 節點連線到一個通道的時候，它的數字證書會通過通道 MSP 來識別它的所屬組織。在這個例子中，P1 和 P2 具有由 CA1 頒發的身份資訊。通道 C 通過在它的通道配置中的策略來決定來自 CA1 的身份資訊應該使用 ORG1.MSP 被關聯到 Org1。類似的，P3 和 P4 由 ORG2.MSP 識別為 Org2 的一部分。

當 Peer 節點使用通道連線到一個區塊鏈網路的時候，在通道配置中的策略會使用 Peer 節點的身份資訊來確定它的權利。關於身份資訊和組織的對映是由成員服務提供者（MSP）來提供的，它決定了一個 Peer 節點如何在指定的組織中分配到特定的角色以及得到訪問區塊鏈資源的相關許可權。更多的是，一個 Peer 節點只能被一個組織所有，因此也就只能被關聯到一個單獨的 MSP。我們會在本部分的後邊學習更過關於 Peer 節點的訪問控制，並且在本指南中還有關於 MSP 和訪問控制策略的部分。目前，可以把 MSP 看作在區塊鏈網路中，為一個獨立的身份資訊和一個特定的組織角色之間提供了關聯。

Peer 節點以及同一個區塊鏈網路進行互動的每件事情都會從他們的數字證書和 MSP 來得到他們的組織的身份資訊。Peer 節點、應用程式、終端使用者、管理員以及排序節點如果想同一個區塊鏈網路進行互動的話，必須要有一個身份資訊和一個相關聯的 MSP。我們使用身份資訊來為每個跟區塊鏈網路進行互動的實體提供一個名字——一個主角（principal）

請注意 Peer 節點物理上在哪真的不重要——它可以放在雲中，或者是由一個組織所有的資料中心中，或者在一個本地機器中——是與它相關聯的數字證書資訊來識別出它是由哪個組織所有的。在我們上邊的例子中，P3 可以執行在 Org1 的資料中心中，只要與它相關聯的數字證書是由 CA2 頒發的，那麼它就是 Org2 所擁有的。

Peer 節點和排序節點
Peer 節點構成了一個基本的區塊鏈網路，維護著賬本和智慧合約，連線到 Peer 節點的應用程式進行查詢及更新。但是，應用程式和 Peer 節點彼此互相互動來確保每個 Peer 節點的賬本永遠保持一致是通過以排序節點作為中心媒介的一種特殊機制。

一個更新的交易和一個查詢的交易區別很大，因為一個單獨的 Peer 節點不能夠由它自己來更新賬本——更新需要網路中其他節點的同意。在一個賬本的更新被應用到 Peer 節點的本地賬本之前， Peer 節點會請求網路中的其他 Peer 節點來批准這次更新。這個過程被稱為共識，這會比一個簡單的查詢花費更長的時間來完成。但是當所有被要求提供批准的節點都提供了批准，並且這筆交易被提交到賬本的時候，Peer 節點會通知它連線的應用程式賬本已經更新了。

特別的是，想要更新賬本的應用程式會被引入到一個三階段的流程，這確保了在一個區塊鏈網路中所有的 Peer 節點都彼此保持著一致的賬本。

在第一個階段，應用程式會跟認可節點的子集一起工作，其中的每個節點都會嚮應用程式為提案的賬本更新提供認證，但是不會將提案的更新應用到他們的賬本副本上。
在第二個階段，這些分散的認證會被蒐集到一起當做交易被打包進區塊中。
在最後一個階段，這些區塊會被分發回每個 Peer 節點，在這些 Peer 節點上每筆交易在被應用到 Peer 節點的賬本副本之前會被驗證。
第一階段：提案 (背書？)
交易流程的第一階段會引入在應用程式和一系列的 Peer 節點之間的互動——它並沒有涉及到排序節點。第一階段只在乎應用程式詢問不同組織的背書節點同意鏈碼呼叫的提案結果。

為了開始第一階段，應用程式會生成一筆交易的提案，它會把這個提案發送給一系列的被要求的節點來獲得背書。其中的每一個背書節點接下來都會獨立地使用交易提案來執行鏈碼，以此來生成這個交易提案的響應。這並沒有將這次更新應用到賬本上，只是簡單地為它提供簽名然後將它返回給應用程式。當應用程式接收到有效數量的被簽過名的提案響應之後，交易流程中的第一個階段就結束了。

交易提案會被 Peer 節點獨立地執行，Peer 節點會返回經過背書的提案響應。在這個例子中，應用程式 A1 生成了交易 T1 和提案 P，應用程式會將交易及提案發送給通道 C 上的 Peer 節點 P1 和 Peer 節點 P2。P1 使用交易 T1 和 提案 P 來執行鏈碼 S1，這會生成對交易 T1 的響應 R1，它會提供背書 E1。P2 使用交易 T1 提案 P 執行了鏈碼 S1，這會生成對於交易 T1 的響應 R2，它會提供背書 E2。應用程式 A1 對於交易 T1 接收到了兩個背書響應，稱為 E1 和 E2。

最初，應用程式會選擇一些 Peer 節點來生成一套關於賬本更新的提案。應用程式會選擇哪些 Peer 節點呢？這取決於背書策略（這是為鏈碼來義的），這個策略定義了在一個賬本提案能夠被網路所接受之前，都需要哪些 Peer 節點需要對這個賬本變更提案進行背書。這很明顯就是為了實現共識——每一個需要的組織必須對賬本更新的提案在被各個 Peer 節點同意更新到他們的賬本之前，對這個提案進行背書。

Peer 節點通過向提案的響應新增自己的數字簽名的方式提供背書，並且使用它的私鑰為整個的負載提供簽名。然後這個背書會被用於證明這個組織的 Peer 節點生成了一個特殊的響應。在我們的例子中，如果 Peer 節點 P1 是屬於組織 Org1 的話，背書 E1 就相當於一個數字證明——”在賬本 L1 上的交易 T1 的響應 R1 已經被 Org1 的 Peer 節點 P1 同意了！”。

第一階段在當應用程式從足夠多的有效的 Peer 節點那裡收到了簽過名的提案響應的時候就結束了。

在第一階段的最後，應用程式可以自由地放棄不一致的交易響應，如果他們想這麼做的話，就可以在早期有效地終結這個交易流程。我們接下來會看到如果應用程式嘗試使用不一致的交易響應來更新賬本的時候，這會被拒絕。

階段2：排序和將交易打包到區塊
交易流程的第二個階段是打包階段。排序節點是這個過程的關鍵——它接收交易，這些交易中包含了來自很多個應用的已經背書過的交易提案，並且將交易排序並打包進區塊。

階段3：驗證和提交
在第二階段末尾，我們看到了排序節點需要負責這個簡單但是重要的蒐集提案的交易變更，將他們排序，並且打包到區塊中，讓他們準備好分發給 Peer 節點的整個流程。

這個交易流程的最後一個階段是分發以及接下來的對於從排序節點發送給 Peer 節點的區塊的驗證工作，這些區塊最終會提交到賬本中。具體來說，在每個 Peer 節點上，區塊中的每筆交易都會被驗證，以確保它在被提交到賬本之前，已經被所有相關的組織一致地背書過了。失敗的交易會被留下來方便審計，但是不會被提交到賬本中。

排序節點的第二個角色是將區塊分發給 Peer 節點。在這個例子中，排序節點 O1 將區塊 B2 分發給了 Peer 節點 P1 和 Peer 節點 P2。Peer P1 處理了區塊 B2，產生了一個會被新增到 P1 的賬本 L1 中的新區塊。同時，peer P2 處理了區塊 B2，產生了一個會被新增到 P2 的賬本 L1 中的新區塊。當這個過程結束之後，賬本 L1 就會被一致地更新到了 Peer 節點 P1 和 P2 上，他們也可能會通知所連線的應用程式關於這筆交易已經被處理過的訊息。

階段三是從排序節點將區塊分發到所有與它連線的 Peer 節點開始的。Peer 節點會和通道中的排序節點相連，所有跟這個排序節點相連的 Peer 節點將會收到一個新的區塊的副本。每個 Peer 節點會獨立處理這個區塊，但是會跟這個通道上的每一個其他 Peer 節點使用完全一致的方式處理。通過這種方式，我們會看到賬本是會始終保持一致的。不是每個 Peer 節點都需要連線到排序節點——Peer 節點可以使用 gossip 協議將區塊的資訊傳送給其他 Peer 節點，其他 Peer 節點也可以獨立地處理這些區塊。

當接到區塊的時候，Peer 節點會按照區塊中的順序處理每筆交易。對於每一筆交易，每個 Peer 節點都會確認這筆交易已經根據產生這筆交易的鏈碼中定義的背書策略由要求的組織進行過背書了。比如，在一些交易被認為是有效之前，這些交易可能僅僅需要一個組織的背書，但是其他的交易可能會需要多個背書。這個驗證的流程確認了所有相關的組織已經生成了相同的產出或者結果。也需要注意到的是，這次的驗證跟在階段 1 中進行的背書檢查是不同的，應用程式從背書節點那裡接收到了交易的響應，然後做了決定來發送交易提案。如果應用程式違反了背書策略傳送了錯誤的交易，那麼 Peer 節點還是能夠在階段 3 中的驗證流程裡拒絕這筆交易。

如果一筆交易被正確的背書，Peer 節點會嘗試將它應用到賬本中。為了做這個，Peer 節點必須要進行賬本一致性檢查來驗證當前賬本中的狀態同應用了更新提案後的賬本是能夠相容的。這可能不是每次都是有可行的，即使交易已經被完整地背書過了。比如，另外一筆交易可能會更新賬本中的同一個資產，這樣的話交易的更新就不會是有效的了，因此也就不會被應用。通過這種方式，賬本在通道中的每個 Peer 節點都是保持一致的，因為他們中每個都在遵守相同的驗證規則。

當 Peer 節點成功地驗證每筆單獨的交易之後，它就會更新賬本了。失敗的交易是不會應用到賬本中的，但是他們會被保留為之後的審計使用，就像成功的交易那樣。這意味著 Peer 節點中的區塊幾乎會跟從排序節點收到的區塊是一樣的，除了在區塊中每筆交易中會帶有有效或者無效的指示符。

總結來說，在第三階段中看到了由排序節點生成的區塊被一致地應用到了賬本中。將交易嚴格地排序到區塊中讓每個 Peer 節點都來驗證交易更新，並一致地應用到區塊鏈網路中。

排序節點和共識
整個交易處理流程被稱為共識，因為所有 Peer 節點在由排序節點提供的流程中對交易的排序及內容都達成了一致。共識是一個多步驟的流程，並且應用程式只會在這個流程結束的時候通知賬本更新——這個在不同的 Peer 節點上可能在不同的時間會發生。

我們看到了 Peer 節點在很多方面都是最基礎的元素——他們構成了網路，維護鏈碼和賬本，處理交易提案和響應，並且通過一致地將交易更新到賬本上來保持一個始終包含最新內容的賬本。