Hyperledger Fabric架構 — 對等節點

Hyperledger Fabric 的一個基本元素是一群對等節點（peers or peer nodes）。對等點是最基礎的，因為它們管理帳本和chaincode。從 Hyperledger Fabric v2.4 開始，peer 還通過運行 Fabric Gateway service來管理交易的提案(proposals)和背書(endorsements)。賬本不可變特性記錄了chaincode產生的所有交易（在 Hyperledger Fabric 中，這些交易包含在chaincode中，稍後會詳細介紹）並得到所需組織的背書。Chaincode和帳本分別封裝了會與渠道對等方共享的流程(processes)和資訊(information)。

Fabric 區塊鏈網路（上圖）由對等節點（而非排序節點）組成，每個節點都存儲和管理帳本和chaincode的副本。 在這個例子中，Fabric 網路 N 由對等節點 P1、P2 和 P3 組成，每個節點都維護自己的帳本 L1 。 P1、P2 和 P3 各自呼叫相同的Chaincode S1 來存取它們各自的帳本副本。

對等點是一個靈活且冗餘的元素，可以建立、啟動、停止、重新配置和刪除。 對等點公開一組 API，使client applications能夠與對等點提供的服務進行交互 — 特別是 Fabric Gateway service。

關於Chaincode

Fabric 通過一種稱為Chaincode的邏輯（存取帳本的代碼）實現智慧合約，該代碼是使用Chaincode API 編寫的。 在本文中，我們會使用術語chaincode，但如果該概念更熟悉，我們可以將chaincode等同於智慧合約。 更多有關Chaincode的資訊請參與本文章。

帳本與Chaincode

現在讓我們更詳細的解釋對等點。 我們可以看到，除了諸如 Fabric Gateway 之類的服務之外，它是同時託管帳本和chaincode的對等點。 更準確地說，對等點託管帳本實例(instance)和chaincodes實例，因為區塊鏈需要在渠道中的對等點之間要有一致的資料和chaincodes副本。 這種設計在 Fabric 網路中提供了有意的冗餘 — — 避免單點故障並提供一致的現行帳本。

對等點託管帳本實例和chaincodes實例（上圖）。 在這個例子中，P1 託管了一個帳本 L1 的實例和一個chaincodes S1 的實例。 任何單一個對等點上都可以託管許多帳本和chaincodes。

因為對等點是帳本、chaincode和服務的宿主，所以client application和管理員必須與對等點交互才能存取這些資源。 這就是為什麼對等點被認為是 Fabric 網路的基本單位。

多個帳本

對等點能夠託管多個帳本，這讓它的系統設計是靈活的，其中單一對等點可以屬於 Fabric 網路中多個渠道。 在最簡單的配置中，對等點託管單一個帳本，因此屬於單一渠道。 但是對等點託管多個帳本並不少見，因為它屬於多個渠道。

託管多個帳本的對等點（如上圖）。 對等點託管一個或多個帳本以及存取它們的chaincode。 在此範例中，對等點 P1 託管帳本 L1 和 L2。 使用chaincode S1 存取帳本 L1； 可以使用Chaincodes S1 或 S2 存取帳本 L2。

安裝在對等點上的chaincodes可以查詢或更新（寫入）帳本。 另外，對等節點還託管與 Fabric 網路的整體配置相關的system chaincodes。

多個chaincodes

Chaincodes在單一個渠道上實例化(instantiated)。 每個渠道（和帳本）可以有多個與之交互的chaincode。

如上圖的託管多個chaincodes的對等點範例。 每個帳本可以有許多存取它的chaincodes。 在這個範例中，對等點 P1 託管帳本 L1 和 L2，其中 L1 由chaincodes S1 和 S2 存取，L2 由 S1 和 S3 存取。 S1 可以存取 L1 和 L2。

稍後我們將看到為什麼 Fabric 中的渠道概念對於在對等點上託管多個帳本和多個chaincodes很重要。

Fabric Gateway service

從 Hyperledger Fabric v2.4 開始，Fabric Gateway service預設安裝與開啟在每個對等點。 與client applications相反，Fabric Gateway service管理對等方的交易提案和背書。 Gateway SDK（用於 Go、Node 和 Java 的 v1.0.0）結合了這種以對等為中心的交易處理模型，從而簡化了應用程序開發。 使用 Fabric v2.3 或更早版本的 SDK 開發的client application將繼續在 Fabric v2.4 中運行。

應用程式與對等節點

我們將說明client applications如何與對等節點交互，更具體地說，是在對等節點上運行的 Fabric Gateway service交互以存取帳本。查詢涉及應用程式和對等節點之間的對話，而帳本更新（寫入）則有其他步驟會發生。

Client Application連接到對等節點上的 Fabric Gateway service，以存取帳本和chaincodes。從 Fabric v2.4 開始，Gateway SDK (v1.x) 為開發人員提供了便利性。 API 使應用程式能夠通過Gateway提交交易提案（呼叫chaincode）、請求背書、接收事件，並將背書的交易轉發到排序服務。

通過gateway上的peer connection，應用程式可以運行chaincode來查詢或更新帳本。帳本查詢交易的結果通過簡單的處理返回，而帳本更新（寫入）涉及應用程式、對等節點和排序者之間更複雜的工作流程。後面我們會詳細解說這個流程。

對等節點與排序節點一起確保帳本在渠道中的每個節點上保持一致和最新。以下序列分三個階段描述了client application、對等節點上運行的gateway service、排序節點和其他對等節點之間的交互並更新帳本。

以下三個交易階段解釋了 Fabric 如何管理交易的Fabric內部處理。 開發人員只需要使用 Gateway SDK (1.x)，這三個階段的處理則由SDK來處理。

第一階段:交易的提案(Proposal)與背書(Endorsement)

帳本的更新（寫入）的第 1 階段包括交易的提案提交、執行和背書：

1)交易提案 — — Client Application (A1) 通過連接到 P1 上的Gateway提交經過簽署的交易提案。 A1 要不將背書組織的選擇委託給Gateways，或是明確標識需要背書的組織。

2)交易執行 — — Gateway選擇 P1 或其組織中的另一個對等點來執行交易。被選中的節點執行提案中指定的鏈Chaincode（S1），產生提案回應（包含read-write set）。被選中的對等節點對提議的交易進行一個有簽名的回應並將其返回給Gateway。

3)交易背書 — — Gateway為chaincodes背書政策所需的每個組織重複交易的執行 (2)。Gateway收集所需組織簽名的提案回應並建立一個交易信封 — — 它返回給客戶端 (SDK) 進行請客戶端簽名。

第二階段:交易的提交(Submission)與排序(Ordering)

帳本更新的第 2 階段包括交易提交和排序到區塊中：

1) 交易提交 — — 客戶端 (SDK) 將簽名好的交易信封發送到Gateway。 Gateway將信封轉發到排序節點並向客戶端發送成功的訊息。

2) 交易排序 — — 排序節點（O1）驗證簽名，排序服務對交易進行排序，並將這筆交易與其他已排序的交易打包成區塊。 然後，排序服務將區塊分發給渠道中的所有對等節點，以對帳本進行驗證和寫入。

第三階段:交易的驗證(Validation)與寫入(Commitment)

帳本更新的第 3 階段包括交易驗證、帳本資料寫入並會產生一個資料寫入事件：

1) 交易驗證 — — 每個對等節點檢查交易信封上的client applications簽名是否與原始交易提案上的簽名相匹配。每個對等節點還檢查所有read-write set和狀態回應是否相等（即來自所有對等節點的背書匹配）以及背書是否滿足背書政策。然後，每個對等節點將每筆交易標記為有效或無效，以便寫入帳本。

2) 交易寫入— — 每個對等節點將有序的交易區塊寫到到渠道帳本（L1）。這通常是對帳本的update(write)。渠道的整體狀態（又稱world state，本質上是所有有效交易的總和）僅使用有效交易的結果進行更新。

3) 寫入事件 — — 每個向帳本寫入的節點都會向client applications發送一個寫入狀態事件，其中包含帳本更新的證明。

對等節點與渠道

接下來我們會說明對等節點如何在渠道上相互交互，以及如何與應用程式交互 — — Fabric 區塊鍊網路中的組件通過這種機制進行私密通訊和交易。

渠道組件包括對等節點、排序節點和應用程式，通過加入渠道，這些組件同意協作以共同管理和共享帳本的相同副本。從概念上講，我們可以將渠道與一群朋友圈相比；一個人可能有幾群朋友，每群組參加不同的活動。這些群組可能是完全獨立的（一群工作上的朋友與一組有相同嗜好的朋友相比），或者有朋友可能存在兩個群都有的狀況。然而，每個朋友群組都是它自己的實體，具有建立和維護成員資格的特定規則（或期望）。

渠道成員的工作方式與其他組組相同；任何一個對等節點都可能屬於多個渠道，並維護一個特定於每個渠道的帳本和chaincode。或者一個對等節點可能只屬於一個渠道，因此只有一組規則要遵循。

渠道允許一組特定的應用程式和對等節點（和組織）在 Fabric 區塊鏈網路上相互通訊。 在上面的範例中，應用程式 A 通過Gateway在渠道 C 上與對等節點 P1 和 P2 進行通信。渠道是特定應用程式和對等節點之間通訊的路徑。

我們看到渠道的存在方式與對等節點不同 — — 將渠道視為由物理對等節點集合形成的邏輯結構更為準確。 理解這一點至關重要 — — 對等節點提供存取和管理渠道的控制點。

對等節點與組織

我們現在知道了對等節點及其與帳本、chaincode和渠道的關係，我們將能夠看到多個組織如何聚集在一起形成區塊鏈網路。

Fabric 區塊鏈網路由一群組織而不是單一個組織來管理。 對等節點是如何構建這種分佈式網路的核心，因為它們歸這些組織所有，並且是這些組織的網連接連接點。

上圖範例顯示了 Fabric 區塊鏈網路中的組織及其對等節點。我們看到四個組織貢獻了總共八個對等節點來形成一個網路。渠道 C 連接網路 N 中的五個對等節點 — — P1、P3、P5、P7 和 P8。這些組織擁有的其他尚未加入通道 C的對等節點，但通常會加入至少一個其他渠道。組織開發的應用程式通過 Fabric Gateway service連接到同一組織中的對等節點以及渠道上其他組織中的對等節點。

重要的是要注意在 Fabric 區塊鏈網路形成過程中發生的事情。該網路為其提供資源的多個組織所組成與管理。 對等節點是我們在本文中討論的資源，但組織也提供其他資源，例如chaincode和排序服務節點。這裡有一個原則在發生作用 — — 如果沒有組織將其個人資源貢獻給集體網路，網路實際上就不存在。此外，網路隨著協作組織提供資源而增長，從而提高了網路的彈性和安全性。

我們可以看到（在某種程度上，除了排序服務之外）沒有集中的資源 — — 在上圖中，如果組織不貢獻其對等節點和其他資源，則網路 N 將不存在。此外，該網路不依賴於任何單一組織 — — 只要其成員滿足網路的所定義的要求，它就會繼續存在。這是網路去中心化的核心所在；其所有成員組織平等分享和貢獻。

如上圖所示，組織使用的應用程式可能不盡相同，因為每個組織都可以決定如何使用帳本上的資料。因此，應用程式和呈現的邏輯都可能因組織而異，即使所有對等節點都託管了帳本的同等副本。

對等節點與身分(Identity)

我們已經知道了來自不同組織的對等節點如何聚集在一起形成區塊鏈網路，接下來我們要了解對等節點如何由其管理員分配給組織。

對等節點通過來自特定CA(certificate authority)的憑證分配給他們的身份。 我們可以將憑證視為提供有關對等節點的可驗證資訊的 ID 卡。 網路中的每個對等節點都由其所屬組織的管理員分配一個憑證。

當對等節點連接到渠道時，其憑證通過通道 MSP 識別其擁有的組織。在上面的範例中，P1 和 P2 具有由CA1頒發的身份。渠道 C 根據其渠道配置中的設定確定來自 CA1 的身份應使用 ORG1.MSP 與 Org1 相關聯。同樣，P3 和 P4 被 ORG2.MSP 標識為 Org2 的一部分。

每當對等節點連接到 Fabric 網路渠道時，渠道配置中的設定都會使用對等節點的身份來確定其權限。身份到組織的對應是由一個稱為MSP 的組件提供的，該組件決定了對等節點如何被分配到特定組織中的特定角色，並因此獲得對資源的授權存取。此外，對等節點只能由單一個組織擁有，因此與單一個 MSP 相關聯。將 MSP 視為將個人身份與 Fabric 網路中的特定組織角色關聯起來。

對等結點以及與 Fabric 網路交互的任何事物都從其憑證和 MSP 中獲取其組織身份。對等節方、應用程式、諸端用戶、管理員和排序者都必須具有身份和關聯的 MSP，才能與網路進行交互。任何使用身份與區塊鏈網路交互的實體都稱為主體(principal)。需要注意的是，身份與對等節點的物理位置不同 — — 它可以在雲端中，或者在一個組織擁有的資料中心中，或者在本地機器上 。在前面的範例圖中，P3 可以託管在 Org1 的資料中心，但只要與其關聯的憑證由 CA2 頒發，它就歸 Org2 所有。

對等節點於排序者(Orderers)

我們已經看到，對等節點構成了 Fabric 網路的基礎，託管帳本和chaincodes，可以通過對等節點連接的應用程式進行查詢和更新。 應用程式和對等節點相互交互以保持帳本在渠道中保持最新和一致的機制由稱為排序者的特殊節點來處理。

帳本更新交易與查詢交易不同，因為單一個節點無法自行更新帳本 — — 這需要網路中其他節點的同意，這一過程稱為共識。 當需要批准交易的對等節點這樣做並且交易提交到帳本時，Gateway service會通知應用程式帳本已更新。 對等節點和排序者一起進行共識作業的管理。

排序者的三階段作業

我們在上面應用程式和對等節點的章節中，我們看到了請求帳本更新的client application如何啟動一個三階段過程，該過程在 Fabric Gateway Service的幫助下，確保 Fabric 網路中的所有對等節點保持當前和一致的副本帳本。 如前所述，排序者也參與其中； 以下部分從排序節點和對等節點（即排序服務和Gateway service）的角度探究三個階段的過程。

第一階段:交易提案(Proposal)

交易工作流的階段 1 涉及client applications、對等節點和排序者之間的交互。在第 1 階段，client applications向 Fabric Gateway service發起請求以評估交易提案。

由client applications會選擇目標對等節點來呼叫chaincode執行交易 — — 這一步可以描述為模擬交易，因為它執行交易對帳本沒有任何影響。然後對等點節將其交易結果返回給client applications。

Gateway service還將交易提案轉發給所需的背書節點（基於背書政策），這些背書節點也執行交易並將其結果返回給對等節點。Gateway service收集所有回應，如果它們滿足背書政策，則將交易轉發給排序服務。

如果提案的交易將寫入private data collection，（作為臨時資料）client applications必須明確指定要背書組織是哪一個。對等節點是通過添加其憑證並使用其私鑰簽署整筆交易來認可提案回應。該背書隨後可用於證明該組織的對等節點產生了特定的回應。

第二階段:交易排序

交易工作流程的第二個階段是排序和封裝階段。 排序服務（在排序節點上運行）通過Gateway service從一個或多個應用程式接收包含其簽名和背書的提案回應的交易，並將交易排序然後打包成區塊。 這些是組成 Fabric 區塊鏈帳本的區塊（也是有序的） — — 由背書和有序交易組成。

第三階段:交易的驗證(Validation)與寫入(Commitment)

交易工作流程的最後一個階段是將有序交易從排序者分發到對等節點。 然後，每個對等節點以正確的順序驗證每筆交易，並確保每筆交易都得到所有所需組織的一致認可。 只有這樣，對等節點才會將該區塊寫入到其渠道帳本的副本中。

排序節點將有序區塊分發給對等節點以進行驗證和寫入。在上面的範例中，排序者 O1 將區塊 B2 分發給對等節點 P1 和 P2。對等節點 P1 處理區塊 B2，從而將一個新區塊加到 P1 上的帳本 L1。對等點節 P2 也會同時處理區塊 B2，從而將一個新區塊加到 P2 上的帳本 L1 中。一旦完成，帳本 L1 會在對等節點 P1 和 P2 上更新，並且Gateway service會通知相關應用程式交易已寫入。

第 3 階段開始於排序節點將區塊分發給與其連接的所有對等節點。對等節點在渠道上連接到排序節點，這樣當新區塊產生時，所有連接到排序節點的對等節點都將收到新區塊的副本。每個對等節點都將獨立處理此區塊，但處理方式與渠道上的所有其他對等節點完全相同。通過這種方式，我們將看到帳本可以保持一致。還值得注意的是，並非每個對等節點都需要連接到排序者 — — 對等節點可以使用gossip協議將區塊散發到其他對等節點，這些對等節點也可以獨立處理它們。

收到區塊後，對等節方將按照區塊中指定的順序處理每筆交易。對於每筆交易，對等節點將根據產生交易的chaincodes的背書政策來驗證該筆交易是否已被所需的組織背書。例如，一些交易可能只需要由一個組織背書，而其他交易可能需要多個背書才能有效。這個驗證過程驗證所有相關組織都產生了相同的結果。

如果交易已被正確背書，對等節點將嘗試寫入帳本。為此，對等節點必須執行帳本的一致性檢查，以驗證帳本的當前狀態是否與產生的建議更新時的帳本狀態相容。帳本的寫入有時會被拒絕，即使交易已被完全認可。例如，另一個交易可能已經更新了帳本中的相同資產，因此交易更新不再有效，因此無法再寫入了。通過這種方式，帳本在渠道中的每個對等節點之間保持一致，因為它們每個都遵循相同的驗證規則。

在對等節點成功驗證每筆單獨的交易後，它會更新帳本。失敗的交易不會寫入於帳本，但它們會保留用於稽核，成功的交易也是如此。這意味著對等區塊(peer blocks)與從排序者收到的區塊幾乎完全相同，除了區塊中每個交易的有效或無效標示。

第 3 階段不需要運行chaincodes — — 這只會發生在第 1 階段，這很重要。這意味著"chaincode只需要在運作在背書節點"，而不是在整個區塊鏈網路中。這使chaincode的邏輯只對背書組織是保密的，背書組織只驗證交易內容是否正確。這與chaincode（交易提議回應）的輸出形成對比，chaincode與渠道中的每個對等節點共享，無論他們是否認可交易。背書節點的這種專門的功能化主要在提高可擴展性和保密性。

最後，每次將一個區塊寫入到對等節點的帳本時，該對等節點都會產生一個事件。區塊事件(Block event)包括完整的區塊內容，而區塊交易事件(Block transaction event)只有摘要信息，例如區塊中的每筆交易是否已被驗證或無效。Chaincodes執行產生的chaincodes events的此時也可以發布。應用程式可以註冊這些事件類型來得到事件通知。寫入事件通知結束了交易工作流的最後階段。

總之，第 3 階段看到由排序者產生的交易區塊經過驗證並一致地寫入到帳本中。每筆交易進到區塊中的嚴格排序允許每個對等節點驗證交易更新是否在渠道中是否一致。

排序者與共識(Consensus)

整個交易工作流程的過程稱為共識，因為對等節點必須在排序者的整合下就交易的順序和內容達成一致。 共識是一個多個步驟的過程，只有在過程成功完成後才會更新帳本 — — 這可能在不同的對等節點上發生的時間略有不同。 將排序者視為節點，它們對提議的帳本內容更新進行排序和分發，以供對等節點背書並加到帳本中。

總結

在本文中我們介紹到，對等節點在很多方面都是 Hyperledger Fabric 架構中最基本的單元 — — 它們構成網路、託管chaincode和帳本，處理交易提議和回應，並保持帳本更新並與經過驗證和背書的交易保持一致。