Hyperledger Fabric的架構簡介

Hyperledger Fabric中的主要結構與流程組件

本篇將有助於我們理解政策(policies)的概念後，對組織需要做出的決策來協助組織透過控制政策部署一個 Hyperledger Fabric的網路。 我們還將了解組織如何使用宣告式政策(declarative policies)來管理Fabric網路的演進 — — 這是 Hyperledger Fabric 的一個關鍵功能。 簡單來說，我們將了解 Hyperledger Fabric 的主要技術組件以及組織需要就這些組件的功能做出的決策。

什麼是區塊鏈網路?

區塊鍊網路是一種技術基礎設施，可為應用程式提供分佈帳本和智慧合約（在hyperledger 稱為chaincode，以下也會這樣統稱）服務。智慧能合約用來產生成交易(transactions)，這些交易隨後被分發到網路中的每個對等節點(peer node,也就是獨立的電腦)，這些紀錄被記在不可變的帳本副本上。應用程式的用戶可能是使用客戶端應用程式的終端用戶或區塊鍊網路管理員。

在大多數情況下，多個組織在Fabric網路中聚集在一起形成一個通道(channel)，在該通道上呼叫chaincode並產生交易，並且權限由最初配置通道大部分組織(就是要過半)都同意的一組政策(policies)來決定。此外，政策可能會隨著時間的推移而改變，但須經組織同意。

在本篇文章中，我們將同時提及“網路(network)”和“通道(channel)”。在 Hyperledger Fabric 中，這些術語實際上是同義詞，因為它們都統稱為組織(organization)、組件(components)、政策(policies)和流程(processes)，這些組織、組件、策略和流程在定義的結構內管理組織之間的交互。

網路的建立

下圖為一個我們想要建立Hyperledger Fabric的最終狀態。我們將逐步說明如何來建構這一個網路架構，這個網路中會有R0-R1三個組織參與。這個基礎架構實現了區塊鏈網路，並受架設該網路的組織所一致同意的政策來進行管理 — — 例如，誰可以把新組織加入。 我們將看到應用程式如何使用區塊鏈網路提供的分佈式帳本和chaincode服務。

R0-R1這三間企業決定建立一個Fabric網路。這三個組織決定這個網路的配置為CC1，其中列出了組織的定義以及定義每個組織將在通道上所扮演角色的政策。

在此通道上，R1 和 R2 將名為 P1 和 P2 的對等點(peers，也就是伺服器)加入通道 C1，而 R0 擁有 O(通道的Ordering service)。 所有這些節點都將包含通道帳本 (L1) 的副本。 而Ordering service保存的分佈帳本的副本不包含狀態資料庫(state database)。 R1 和 R2 還將使用他們的應用程式 A1 和 A2 與通道進行交互。 這三個組織都有一個憑證發行機構(Certificate Authority, 以下簡稱CA)，該CA為其組織的節點、管理員、組織定義和應用程式都產生了必要的憑證。

第一步：建立整體網路配置

首先我們要用組織同意的網路配置CC1來建立整個網路/渠道。

渠道配置(channel configuration)通常會配置在一個稱為configuration block之中。這個configuration block會由一個稱為”configtxgen” CLI工具產生一個 configtx.yaml的檔案。雖然一個組織可以獨立建立一個渠道，然後邀請其他組織加入（我們會在後面提到這要怎麼做），但現在我們假設這些組織希望在從一開始就都在該渠道中。

一旦configtx.yaml檔案存在，我們就可以說一個渠道在邏輯上是存在的，即使沒有任何物理性組件連接到它。configtx.yaml檔案包含有哪些組織在裡面使用的組件跟這些組件的交互，以及定義如何制定決策和達到特定結果的結構性政策(policies)。雖然對等點和應用程式是網路中的關鍵參與者，但它們在渠道中的行為更多地取決於渠道配置政策，而不是任何其他因素。有關策略以及它們如何在渠道配置中定義的更多資訊，請參考此篇文章。

這些組織的定義及其管理員的身份必須由與每個組織關聯的CA建立。 在這個範例中，組織 R0 — R1的認證和組織定義分別由 CA0 — CA1建立。 而有關怎麼使用configtxgen來產生configtx.yaml檔案請參考此篇文章。

關於憑證發行機構(Certificate Authority)
CA在網路中發行 X.509 憑證，可用於將組件標識為屬於組織。 CA 發行的憑證也可用於簽署交易，以表明組織認可交易結果 — — 這是其被分佈式帳本接受的先決條件。CA有著以下兩方面對整個網路是很重要的。

首先，區塊鏈網路的不同組件使用憑證來相互識別自己來自特定組織。這就是為什麼通常有不止一個 CA 支援區塊鏈網路的原因 — — 不同的組織通常使用不同的 CA。我們將在這個範例的渠道中使用三個 CA；每個組織一個。事實上，CA 非常重要，以至於 Hyperledger Fabric 為我們提供了一個內置的（稱為 Fabric-CA）來協助我們之後的作業，儘管在現實中，組織會選擇使用他們自己的 CA。

憑證與成員組織的對應是通過稱為MSP(Membership Service Provider) 的結構實現的，該結構通過建立與Root CA 憑證綁定的 MSP 來定義組織，以標識由Root CA 建立的組件和身份。然後，渠道配置可以通過政策為組織分配某些權限（這將賦予特定組織，例如 R0，可以將新組織加入到渠道的權限）。我們沒有在這些圖示中顯示 MSP，因為把MSP加入可能會讓人更混亂，但是因為它們定義了組織，所以它們非常重要。更多的MSP資訊請參閱本篇文章。

其次，我們稍後會看到 CA 發行的憑證如何產生交易和驗證過程的核心。具體來說，X.509 憑證用於客戶端應用程式產生交易的要求和chaincode對交易的回應(chaincode會對交易進行數位簽章)。隨後，有著分類帳本副本的網路節點在接受帳本上的交易之前會驗證交易簽章是否有效。

第二步：將節點加入渠道

對等點(peer，也就是伺服器)是整個網路的基本元素，因為它們運行了帳本和chaincode，因此是在渠道中進行交易的組織連接到渠道的物理節點之一（另一個是應用程式）。對等點可以有很多個渠道（取決於伺服器大小和特定國家/地區對資料監管規則等因素）。關於對等節點的詳細資訊請參考本文章。

另一方面，Ordering service收集來自應用程式有背書的交易並將它們排序到交易區塊中，然後將其分發到渠道中的每個對等節點(peer node)。在這些提交節點(committing node)中的每一個節點上，都會記錄交易並適當更新分佈帳本的local cpoy。 每個渠道只會有一個Ordering service，服務該渠道的節點也稱為“conseter set”。即使一個節點（或一組節點）為多個渠道提供服務，也就是每個Ordering service 的instances支援不同的的渠道。有關Ordering service更多資訊，請參閱本文章。

因為 R0 -R1被列在渠道配置中，所以允許它們加入對等節點（在 R1 和 R2 的情況下）或Ordering node（在 R0 的情況下）到渠道。

組織R1 的對等點 P1 和 組織R2 的對等點 P2 以及 組織R0 的Ordering service O 會建立起一個渠道的產生流程。雖然只有一個Ordering node 1(在上圖圖示中有個數字1) 加入了此渠道，但在企業運作的正式環境中，Ordering service應至少包含三個節點，以維持服務的高可用度。然而，就本文要描述的，我們要概念化的是Ordering service和網路其他組件的交互要比了解高可用度需求如何影響配置決策更為重要。屬於每個組織的節點具有由剛這個組織關聯的CA為它們創建的 x.509 憑證。 P1 的證書由 CA1 創建，P2 的證書由 CA2 創建，以此類推。

渠道中的每個節點都存儲了渠道帳本 L1 的副本，該副本將隨每個新區塊更新而更新（需要注意的是Ordering service只做包含帳本的區塊鏈部分，而不包含狀態資料庫）。因此，我們可以將 L1 視為是物理性的託管在 P1 上，但邏輯上的託管是在渠道 C1 上。最佳實踐是 組織R1 和 R2 使它們的對等點 P1 和 P2 成為錨點，因為這將引導 R1 和 R2 之間在網路上的通訊。

Ordering service加入渠道後，可以提議和提交對渠道配置的更新。接下來，我們要在渠道上安裝、批准和提交chaincode。

第三步:安裝、批准和提交chaincode

Chaincode是安裝在對等點中，然後被定義於提交在渠道中。

在 Fabric 中，定義對等組織(peer org)如何與分佈式帳本交互的業務邏輯（例如，變動資產所有權之類的交易）包含在chaincode中。這會安裝在相關對等點上，由相關對等組織批准，並在渠道上提交。通過這種方式，我們可以視為chaincode物理上運作在對等節點上，但邏輯上運作在渠道中。在我們的範例中，Chainbcode S5 安裝在每個對等點上，即使組織不需要安裝每個chaincode ，它還是會被安裝。我們注意的是，Ordering service上沒有安裝chaincode，因為Ordering node通常不提交一筆交易。安裝、批准和提交chaincode的過程稱為chaincode的“生命週期”。有關更多資訊Fabric chaincode 生命週期，請參閱本文章。

Chaincode的定義中提供的最重要的資訊是背書政策。它描述了哪些組織必須在該筆交易被其他組織寫入到他們的分佈式帳本副本之前對其進行背書。根據需求，可以為渠道中的任何成員組合設置背書策略。如果未設置背書策略，則繼承自渠道配置中指定的預設背書策略。

第四步:在渠道中使用應用程式

提交chaincode後，應用程式可用於通過 Fabric Gateway service 呼叫chaincode來產生交易。 這完成了我們在第一張圖片中顯示的架構：

如同peers和orderers一樣，應用程式也有將它自己與組織相關聯的身份。 在我們的範例中，端應用程式 A1 與組織 R1 相關聯並連接到 渠道C1。

從 Fabric v2.4 開始，應用程式（使用 Gateway SDK v1.x 開發）與Gateway servicec會建立 gRPC 連現，然後Gateway servicec會代表應用程式處理交易提議和背書過程。 交易提議作為chaincode的input，chaincode使用它來產生交易的回應。

我們可以看到，我們的對等組織 R1 和 R2 正在參與該渠道。 他們的應用程式可以通過chaincode S5 存取帳本 L1 以產生將由背書政策中指定的組織背書並寫入帳本的交易。

將組件加入多個渠道

現在我們已經說明如何建立渠道的過程，以及組織、節點、政策、chaincode和應用程式之間的交互的性質，下一步是在之後若有新的組織要加入與要為這個組織加入新渠道應該要怎麼做。 為了展示如何將 Fabric 組件加入到多個渠道中，我們將 R2 及其對等點 P2 加入到新渠道中，而 R1 和 P1 不會加入。

選項一:建立新渠道的配置

如同我們看到的，建立渠道的第一步是要有配置檔產生。 該渠道不僅包括 R2 和 R0，還包括一個新組織 R3，該組織的身份和憑證由 CA3 創建。 R1 對該渠道沒有參與所以也沒有任何權限。 事實上，R1組織甚至不知道新的渠道存在。

跟我們建立一開始建立整個網路與渠道一樣，我們會建立一個有組織R0/R2/R3的渠道配置 CC2，但這只是一個空殼，它還沒有加入任何組件。

選項二:在新渠道中加入組件

我們已經展示了所有渠道如何產生一個帳本，以及chaincode，這個新渠道有自己的帳本 L2，它與 渠道C1 的帳本完全分開。 這是因為即使 R2這個組織（及其對等點 P2）加入了這兩個渠道，這兩個渠道也是完全獨立的管理範圍(如下圖)。

雖然 渠道C1 和 渠道C2 都有相同的Orderer organization R0，但不同的渠道是由不同的ordering node來負責的。這不是強制性的配置，因為即使相同的ordering node加入多個渠道，但每個渠道都有一個單獨的ordering service instance，並且這在有多個orderer organization聚集在一起為Ordering service 提供服務節點的渠道中更為常見。只有加入特定渠道的ordering node具有該渠道的帳本。如果我們不想把所有帳本都放在同一組伺服器，哪就要設計成每個渠道都有自己的ordering node.

雖然 組織R2 也可以部署一個新的對等點(伺服器)來加入渠道 C2，在這個範例中，P2 也運行了渠道C2的設定。所以P2 在其file system上同時具有 渠道C1 的帳本（ L1）和 渠道C2 的帳本（ L2）。同樣，R2 選擇修改其應用程式 A2，以便與 渠道C2 連結，而組織R3 的應用程式 A3 也連接到渠道C2。

從邏輯上講，這一切都與 渠道C1 的建立非常相似。兩個對等組織與一個Orderer organization一起建立一個渠道並將組件和chaincode加入其中。

從連接到兩個渠道的 組織R2 的角度考量這種配置。從R2的角度來看，他們可能會將 渠道C1 和 渠道C2 以及它們加入的組件視為“網路(network)”，即使這兩個渠道彼此不同。從這個意義上說，“網路”也可以被視為存在於特定組織的視度內，即“我所屬的所有渠道和我擁有的所有組件”。

現在我們已經了解了如何將組織及其組件加入到多個渠道中，讓我們要看如何將組織及其組件加入到現有渠道中。

選項三:在既有渠道中加入組織

隨著越來越多組織要加入Fabric網路中，我們勢必需要修改渠道的設定。 修改渠道的常見方法之一是加入新組織。 雖然也可以添加更多的Orderer organization（他們可能會或可能不會提供伺服器當節點），但在這個範例中，我們將講述如何將新的對等組織 R3 加到渠道 C1 的渠道配置 CC1 的過程。

這裡要注意的是，權限是在渠道這一個等級定義的。 一個組織是一個渠道的管理員並不意味著它會是另一個渠道的管理員。 每個渠道都是一個不同的管理區域，並且可以根據其需求來修改。

將新組織加入到渠道中會有以下三個過程：

1. 決定這個新組織的權限和角色。 在將組織R3 加到 渠道C1 之前，必須決定這些權限的範圍，但包含首先建立渠道時必須回答的相同類型的問題。 組織R3 將在 渠道C1 上擁有什麼樣的權限？ 是渠道的管理員嗎？ 它對任何渠道資源的存取是否會受到限制（例如，組織R3 可能只能寫入渠道 C1，這意味著它可以提出交易變更但不能簽署交易）？ 組織R3 將在其對等節點上會安裝哪些chaincode呢？
2. 更新渠道，包括相關的chaincode，以反映這些變動。
3. 該組織將其對等節點（以及可能會有的ordering nodes）加入渠道並開始運作。

在本文中，我們假設 組織R3 將加入 渠道C1，並享有與 組織R1 和 R2 相同的權現和位階。 同樣，組織R3 也將作為 chaincode S5 的背書人加入，這意味著 組織R1 或 R2 必須重新定義 S5（特別是chaincode定義的背書政策部分）並在渠道上啟動它。

更新渠道配置會建立一個新的配置檔 CC1.1，它將作為渠道配置，直到再次更新。 即使配置已更改，渠道仍然存在，並且 節點P1 和 P2 還是在裡面。 無需將組織或對等方重加到渠道中。

選項四:將現有組件加入到新渠道

現在 組織R3 能夠完全參與渠道 C1，它可以將其組件加到渠道中。 與其一次只做一個組件，讓我們看一下組織R3的對等點、本地帳本副本、chaincode和應用程式是如何同時加入的。

在這個範例中，組織R3 將先前連接到 渠道C2 的 節點P3 添加到 渠道C1。 當組織R3這樣做時，節點P3 拉取 渠道C1 的帳本 L1。 正如我們在之前所提到的，組織R3 已加到渠道 C1 中，具有與 組織R1 和 R2 相同的權限。 同樣，由於chaincode S5 已在渠道上重新定義並重新批准以便組織 R3的加入，因此 組織R3 現在可以安裝 chaincode S5 並開始交易。 正如組織 R2 修改其應用程式 A2 以便能夠連接渠道 C2 一樣，應用程式 A3 現在也能夠在 渠道C1 上產生交易。

重點回顧

本文中我們已經從兩個組織在單一個通渠道上進行交易的簡單配置逐漸轉變為多個組織在多個渠道上進行交易，以及將組織加入到既有渠道的過程。

雖然本文所舉的是一個相對簡單的案例，但在 Fabric 中可以實現無數複雜拓撲的組合，支援無數的運作目標，並且對網路的規模沒有理論上的限制。 網路和渠道政策的謹慎使用甚至可以讓大型網路得到良好的管理。