介紹
什么是區(qū)塊鏈
一個分布式賬本
區(qū)塊鏈網(wǎng)絡的核心是一個分布式賬本，記錄網(wǎng)絡上發(fā)生的所有交易。
區(qū)塊鏈賬本通常被描述為 去中心化的 ，因為它會被復制到許多網(wǎng)絡參與者中，每個參與者都在 協(xié)作 維護賬本。我們將看到去中心化和協(xié)作是強大的屬性，反映了企業(yè)在現(xiàn)實世界中交換商品和服務的方式。
除了”去中心化”和”協(xié)作”之外，信息僅能以追加的方式記錄到區(qū)塊鏈上，并使用加密技術保證一旦將交易添加到賬本就無法修改。這種“不可修改”的屬性簡化了信息的溯源，因為參與者可以確定信息在記錄后沒有改變過。這就是為什么區(qū)塊鏈有時被描述為 證明系統(tǒng) 。
智能合約
為了支持以同樣的方式更新信息，并實現(xiàn)一整套賬本功能（交易，查詢等），區(qū)塊鏈使用 智能合約 來提供對賬本的受控訪問。
智能合約不僅是在網(wǎng)絡中封裝和簡化信息的關鍵機制，它還可以被編寫成自動執(zhí)行參與者的特定交易的合約。
例如，可以編寫智能合約以規(guī)定物品的運費，運費根據(jù)物品送達的速度變化而變化。交易雙方同意并把條款寫入賬本后，當物品送達時，相應的資金就會自動轉賬。
共識
保持賬本在整個網(wǎng)絡中同步的過程稱為 共識 。該過程確保所有賬本僅在交易被相應參與者批準時更新，并且當賬本更新時，所有賬本都以相同的順序更新相同的交易。
稍后您將學習更多關于賬本，智能合約和共識的知識。目前，將區(qū)塊鏈視為共享的并具有多份副本的交易系統(tǒng)就足夠了，該系統(tǒng)通過智能合約進行更新，并通過稱為共識的協(xié)作流程來保持一致。
為什么區(qū)塊鏈有用？
現(xiàn)在的記錄系統(tǒng)
從業(yè)務交易記錄產(chǎn)生自今，當今的交易網(wǎng)絡只不過是過往網(wǎng)絡的小版本升級。 業(yè)務網(wǎng)絡 中的成員彼此交易，但他們分別維護各自的交易記錄。他們所交易的東西，無論是16世紀的佛蘭芒掛毯還是今天的證券，必須在每次出售時確定其來源，以確保出售物品的企業(yè)擁有的所有權。
上述流程產(chǎn)生的是一個如下所示的商業(yè)網(wǎng)絡：
現(xiàn)代技術已經(jīng)從石碑和紙質(zhì)文件夾演變?yōu)橛脖P驅動器和云平臺，但底層結構是相同的。因為沒有管理網(wǎng)絡參與者身份的統(tǒng)一系統(tǒng)，因而溯源非常費力，需要數(shù)天才能清理證券交易（其世界交易量以數(shù)萬億美元計算），合同必須手動簽署和執(zhí)行，而且系統(tǒng)中的每個數(shù)據(jù)庫的信息都是孤立的，這也意味著單點故障。
即使可見性和信任的需求很明確，但在如今信息和流程共享的方法支離破碎，不可能構建一個跨業(yè)務網(wǎng)絡的記錄系統(tǒng)。
區(qū)塊鏈的不同
如果業(yè)務網(wǎng)絡不是由像老鼠窩一樣的（譯者注：老鼠窩，指亂七八糟的系統(tǒng)），低效的“現(xiàn)代”交易系統(tǒng)構建，而是由一套標準方法構建，包括在網(wǎng)絡上建立身份，執(zhí)行交易和存儲數(shù)據(jù)，那會怎么樣？如果資產(chǎn)來源可以通過查看交易列表來確定，此列表一旦寫入，無法更改，因此可信任，那會怎么樣？
該業(yè)務網(wǎng)絡看起來更像是這樣的：
這就是一個區(qū)塊鏈網(wǎng)絡，其中每個參與者都有自己的賬本副本。除了共享賬本信息之外，還共享更新賬本的過程。與今天使用參與者的 私人 程序更新其 私人 賬本的系統(tǒng)不同，區(qū)塊鏈系統(tǒng)具有 共享 程序來更新 共享 賬本。
利用共享賬本協(xié)調(diào)其業(yè)務網(wǎng)絡的能力，區(qū)塊鏈網(wǎng)絡可以減少與處理私人信息相關的時間、成本和風險，同時提高信任和可見性。
你現(xiàn)在已經(jīng)知道區(qū)塊鏈是什么，以及為什么它有用。還有許多其他重要的細節(jié)，但它們都與信息和流程共享的這些基本思想有關。
什么是Hyperledger Fabric？
Linux 基金會于2015年創(chuàng)建了 Hyperledger（超級賬本）項目，以推進跨行業(yè)的區(qū)塊鏈技術。它不是用來宣布一個區(qū)塊鏈標準，而是鼓勵通過社區(qū)流程開發(fā)區(qū)塊鏈技術的協(xié)作方法，其中包括鼓勵開放式開發(fā)、和隨著時間的推移采用關鍵標準的知識產(chǎn)權。
Hyperledger Fabric 是 Hyperledger 中的區(qū)塊鏈項目之一。與其他區(qū)塊鏈技術一樣，它有一個賬本，使用智能合約，是一個參與者管理交易的系統(tǒng)。
Hyperledger Fabric 與其他區(qū)塊鏈系統(tǒng)不同的地方是 私有 和 許可 。與允許未知身份參與網(wǎng)絡的開放式非許可系統(tǒng)（需要諸如“工作量證明”之類的協(xié)議來驗證交易并保護網(wǎng)絡）不同，Hyperledger Fabric 網(wǎng)絡的成員需要從可信賴的 成員服務提供者（MSP） 注冊。
Hyperledger Fabric 還提供多種可插拔選項。賬本數(shù)據(jù)可以以多種格式存儲，共識機制可以交換替換，并且支持不同的MSP。
Hyperledger Fabric 還提供創(chuàng)建 通道 的功能，允許一組參與者創(chuàng)建各自的交易賬本。對于某些網(wǎng)絡而言，這是一個特別重要的選擇。這些網(wǎng)絡中，一些參與者可能是競爭對手，并且不希望他們做出的每筆交易都被每個參與者知曉，例如，他們只向某些參與者提供的特殊價格，而其他人不是。如果兩個參與者組成一個通道，那么只有這兩個參與者擁有該通道的賬本副本，而其他參與者沒有。
共享賬本
Hyperledger Fabric 有一個賬本子系統(tǒng)，包括兩個組件： 世界狀態(tài) 和 交易日志 。每個參與者都擁有他們所屬的每個 Hyperledger Fabric 網(wǎng)絡的賬本副本。
世界狀態(tài)組件描述了在給定時間點的賬本的狀態(tài)。它是賬本的數(shù)據(jù)庫。交易日志組件記錄產(chǎn)生世界狀態(tài)中當前值的所有交易；這是世界狀態(tài)的更新歷史。然后，賬本包括世界狀態(tài)數(shù)據(jù)庫和交易日志歷史記錄。
賬本中世界狀態(tài)的數(shù)據(jù)存儲是可替換的。默認情況下，這是 LevelDB 鍵值存儲數(shù)據(jù)庫。交易日志不需要是可插拔的。它只記錄區(qū)塊鏈網(wǎng)絡使用賬本數(shù)據(jù)庫前后的值。
智能合約
Hyperledger Fabric 智能合約用 鏈碼 編寫，當該應用程序需要與賬本交互時，由區(qū)塊鏈外部的應用程序調(diào)用。在大多數(shù)情況下，鏈碼只與賬本的數(shù)據(jù)庫、世界狀態(tài)（例如，查詢）交互，而不與交易日志交互。
鏈碼可以用幾種編程語言實現(xiàn)。目前支持 Go、Node.js 和 Java 鏈碼。
隱私
根據(jù)網(wǎng)絡的需求，企業(yè)對企業(yè)（B2B）網(wǎng)絡中的參與者可能對他們共享的信息量非常敏感。對于其他網(wǎng)絡，隱私不是最受關注的問題。
Hyperledger Fabric 支持私有網(wǎng)絡（使用通道）是很重要的，因為網(wǎng)絡是相對開放的。
共識
交易必須按照發(fā)生的順序寫入賬本，即使它們可能位于網(wǎng)絡中不同的參與者集合之中。為此，必須建立交易的順序，且必須采用一種方法來拒絕錯誤（或惡意）插入到賬本中的非法交易。
這是一個徹底的計算機科學研究領域，且有很多方法可以實現(xiàn)它，每個方法都有不同的權衡。例如，PBFT（實用拜占庭容錯算法）可以為文件副本提供一種機制，使其能夠保持各個副本的一致性，即使在發(fā)生損壞的情況下也是如此?；蛘?，在比特幣中，通過稱為挖礦的過程進行排序，其中競爭計算機競相解決加密難題，該難題定義所有過程隨后構建的順序。
Hyperledger Fabric 被設計為允許網(wǎng)絡啟動者選擇最能代表參與者間存在的關系的共識機制。與隱私一樣，有一系列需求；從他們的關系高度結構化的網(wǎng)絡，到更加點對點的網(wǎng)絡。
Hyperledger Fabric 模型
本節(jié)講述了 Hyperledger Fabric 的關鍵設計特性，實現(xiàn)了全方位、可定制的企業(yè)級區(qū)塊鏈解決方案：
- 資產(chǎn) — 資產(chǎn)是可以通過網(wǎng)絡交換的幾乎所有具有價值的東西，從食品到古董車、貨幣期貨。
- 鏈碼 — 鏈碼執(zhí)行與交易排序分離，限制了跨節(jié)點類型所需的信任和驗證級別，并優(yōu)化了網(wǎng)絡可擴展性和性能。
- 賬本特性 — 不可變的共享賬本為每個通道編碼整個交易歷史記錄，并包括類似 SQL 的查詢功能，以便高效審計和解決爭議。
- 隱私 — 通道和私有數(shù)據(jù)集合實現(xiàn)了隱私且機密的多邊交易，這些交易通常是在共同網(wǎng)絡上交換資產(chǎn)的競爭企業(yè)和受監(jiān)管行業(yè)所要求的。
- 安全和成員服務 — 許可成員資格提供可信的區(qū)塊鏈網(wǎng)絡，參與者知道所有交易都可以由授權的監(jiān)管機構和審計員檢測和跟蹤。
- 共識 — 達成共識的獨特方法可實現(xiàn)企業(yè)所需的靈活性和可擴展性。
資產(chǎn)
資產(chǎn)的范圍可以從有形（房地產(chǎn)和硬件）到無形資產(chǎn)（合同和知識產(chǎn)權）。Hyperledger Fabric 提供使用鏈碼交易來修改資產(chǎn)的功能。
資產(chǎn)在 Hyperledger Fabric 中表示為鍵值對的集合，狀態(tài)更改記錄為 Channel 賬本上的交易。資產(chǎn)可以用二進制或 JSON 格式表示。
鏈碼
鏈碼是定義單項或多項資產(chǎn)的軟件，和能修改資產(chǎn)的交易指令；換句話說，它是業(yè)務邏輯。鏈碼強制執(zhí)行讀取或更改鍵值對或其他狀態(tài)數(shù)據(jù)庫信息的規(guī)則。鏈碼函數(shù)針對賬本的當前狀態(tài)數(shù)據(jù)庫執(zhí)行，并通過交易提案啟動。鏈碼執(zhí)行會產(chǎn)生一組用于寫入的鍵值對（寫集），可以被提交到網(wǎng)絡并應用于所有節(jié)點的賬本。
賬本特性
賬本是 Fabirc 中所有狀態(tài)轉換的有序的防篡改的記錄。狀態(tài)轉換是參與方提交的鏈碼調(diào)用（“交易”）的結果。每個交易都會生成一組資產(chǎn)鍵值對，這些鍵值對以創(chuàng)建、更新或刪除形式提交到賬本。
賬本由區(qū)塊鏈（“鏈”）組成，用于以區(qū)塊的形式存儲不可變的順序記錄，以及用于維護當前 Fabirc 狀態(tài)的狀態(tài)數(shù)據(jù)庫。每個通道有一個賬本。每個節(jié)點為其所屬的每個通道維護一個賬本的副本。
Fabric 賬本的一些特點：
- 使用基于鍵的查找、范圍查詢和組合鍵查詢來查詢和更新賬本
- 使用富查詢語言進行只讀查詢（如果使用 CouchDB 作為狀態(tài)數(shù)據(jù)庫）
- 只讀歷史記錄查詢（查詢一個鍵的賬本歷史記錄）用于支持數(shù)據(jù)溯源場景
- 交易包括鏈碼讀取鍵/值（讀集）的版本以及鏈碼寫入鍵/值（寫集）的版本
- 交易包含每個背書節(jié)點的簽名，并被提交給排序服務
- 交易按順序打包到區(qū)塊，并被排序服務“分發(fā)”到通道上的節(jié)點
- 節(jié)點根據(jù)背書策略驗證交易并執(zhí)行策略
- 在附加一個區(qū)塊之前，會執(zhí)行一次版本檢查，以確保被讀取的資產(chǎn)的狀態(tài)自鏈碼執(zhí)行以來未發(fā)生更改
- 一旦交易被驗證并提交，就具有不變性
- 一個通道的賬本包含一個配置區(qū)塊，用于定義策略、訪問控制列表和其他相關信息
- 通道包含 Membership Service Provider 的實例，允許從不同的證書頒發(fā)機構（CA）生成加密材料
查看 賬本 主題來更深地了解數(shù)據(jù)庫、存儲結構和 “查詢能力”。
隱私
Hyperledger Fabric 在每個通道上使用不可變的賬本，以及可操縱和修改資產(chǎn)當前狀態(tài)（即更新鍵值對）的鏈碼。賬本存在于通道范圍內(nèi)，它可以在整個網(wǎng)絡中共享（假設每個參與者都在同一個公共通道上），也可以被私有化，僅包括一組特定的參與者。
在后一種情況下，這些參與者將創(chuàng)建一個單獨的通道，從而隔離他們的交易和賬本。為了想在完全透明和隱私之間獲得平衡的場景，可以僅在需要訪問資產(chǎn)狀態(tài)以執(zhí)行讀取和寫入的節(jié)點上安裝鏈碼（換句話說，如果未在節(jié)點上安裝鏈碼，它將無法與賬本正確連接）。
當該通道上的組織子集需要對其交易數(shù)據(jù)保密時，私有數(shù)據(jù)集合用于將此數(shù)據(jù)隔離在私有數(shù)據(jù)庫中，在邏輯上與通道賬本分開，只有經(jīng)授權的組織子集才能訪問。
因此，通道在更廣泛的網(wǎng)絡上保持交易的私密性，而集合則在通道上的組織子集之間保持數(shù)據(jù)的私密性。
為了進一步模糊數(shù)據(jù)，在將交易發(fā)送到排序服務并將區(qū)塊附加到賬本之前，可以使用諸如 AES 之類的通用加密算法對鏈碼內(nèi)的值進行加密（部分或全部）。一旦加密數(shù)據(jù)被寫入賬本，它就只能由擁有用于生成密文的相應密鑰的用戶解密。
有關如何在區(qū)塊鏈網(wǎng)絡上實現(xiàn)隱私的更多詳細信息，請參閱 私有數(shù)據(jù) 主題。
安全和成員服務
Hyperledger Fabric 支持一個交易網(wǎng)絡，在這個網(wǎng)絡中，所有參與者都擁有已知的身份。公鑰基礎設施用于生成與組織、網(wǎng)絡組件以及終端用戶或客戶端應用程序相關聯(lián)的加密證書。因此，可以在更廣泛的網(wǎng)絡和通道級別上操縱和管理數(shù)據(jù)訪問控制。Hyperledger Fabric 的這種“許可”概念，加上通道的存在和功能，有助于解決隱私和機密性要求較高的場景。
請參閱 成員服務提供者 (MSP) 主題，以更好地了解加密實現(xiàn)，以及 Hyperledger Fabric 中使用的簽名、驗證、身份認證方法。
共識
最近，在分布式賬本技術中，共識已成為單個函數(shù)內(nèi)特定算法的同義詞。然而，共識不僅包括簡單地就交易順序達成一致，Hyperledger Fabric 通過其在整個交易流程中的基本角色，從提案和背書到排序、驗證和提交，突出了這種區(qū)別。簡而言之，共識被定義為組成區(qū)塊的一組交易的正確性的閉環(huán)驗證。
當區(qū)塊中交易的順序和結果滿足明確的策略標準檢查時，最終會達成共識。這些制衡措施是在交易的生命周期內(nèi)進行的，包括使用背書策略來規(guī)定哪些特定成員必須背書某個交易類別，以及使用系統(tǒng)鏈碼來確保這些策略得到執(zhí)行和維護。在提交之前，節(jié)點將使用這些系統(tǒng)鏈碼來確保存在足夠的背書，并且它們來自適當?shù)膶嶓w。此外，在將包含交易的任何區(qū)塊附加到賬本之前，將進行版本檢查，以確保在此期間，賬本的當前狀態(tài)是能與交易中的信息達成共識的。該最終檢查可防止雙重花費操作和可能危及數(shù)據(jù)完整性的其他威脅，并允許針對非靜態(tài)變量執(zhí)行功能。
除了眾多的背書、驗證和版本檢查外，交易流的各個方向上還會發(fā)生持續(xù)的身份驗證。訪問控制列表是在網(wǎng)絡的分層上實現(xiàn)的(排序服務到通道)，并且當一個交易提議通過不同的架構組件時，有效負載會被反復簽名、驗證和認證?？偠灾?，共識并不僅僅局限于一批交易的商定順序；相反，它的首要特征是交易從提案到提交的過程中不斷進行核查而附帶實現(xiàn)的。
區(qū)塊鏈網(wǎng)絡
這個話題會在概念層面上描述 Hyperledger Fabric 是如何讓組織間以區(qū)塊鏈網(wǎng)絡的形式進行合作的。如果你是一個架構師，管理員或者開發(fā)者，你可以通過這個話題來理解在 Hyperledger Fabric 區(qū)塊鏈網(wǎng)絡中的主要結構和處理組件。這個話題會使用一個可管理的工作的例子來介紹在一個區(qū)塊鏈網(wǎng)絡中的主要組件。理解了本例之后你可以閱讀更多關于這些組件的詳細信息，或者嘗試 構建一個示例網(wǎng)絡。
當閱讀完這個話題并且理解策略的概念后，你就能夠完全理解組織在建立管控一個部署的 Hyperledger Fabric 網(wǎng)絡而需要做的決策。你也能夠理解組織是如何使用定義的策略來管理網(wǎng)絡的演變的，策略是 Hyperledger Fabric 的一個重要特點。簡言之，你會理解 Hyperledger Fabric 的主要技術組件以及組織對于他們所要做的決策。
什么是區(qū)塊鏈網(wǎng)絡
區(qū)塊鏈網(wǎng)絡是一個為應用程序提供賬本及智能合約（chaincode）服務的技術基礎設施。首先，智能合約被用來生成交易，接下來這些交易會被分發(fā)給網(wǎng)絡中的每個節(jié)點，這些交易會被記錄在他們的賬本副本上并且是不可篡改的。這個應用程序的用戶可能是使用客戶端應用的終端用戶，或者是一個區(qū)塊鏈網(wǎng)絡的管理員。
在大多數(shù)的額情況下，多個組織 會聚集到一起作為一個聯(lián)盟 來形成一個網(wǎng)絡，并且他們的權限是由一套在網(wǎng)絡最初配置的時候聯(lián)盟成員都同意的規(guī)則來決定的。并且，網(wǎng)絡的規(guī)則可以在聯(lián)盟中的組織同意的情況下隨時地被改變，就像當我們討論 修改規(guī)則 概念的時候將要發(fā)現(xiàn)的那樣。
示例網(wǎng)絡
在我們開始前，讓我們來展示一下我們最終要做的東西吧！這是一個圖表展示了我們示例網(wǎng)絡的 最終狀態(tài)。
不必擔心這個看起來非常復雜！在我們學習這個話題的過程中，我們會一點一點地構建起這個網(wǎng)絡，所以你能夠了解組織 R1、R2、R3 和 R4 是如何為網(wǎng)絡提供基礎設施并且從中獲益。這個基礎設施實現(xiàn)了區(qū)塊鏈網(wǎng)絡，并且它是由來自網(wǎng)絡中的組織都同意的規(guī)則來管理的，比如誰可以添加新的組織。你會發(fā)現(xiàn)應用程序是如何消費賬本以及區(qū)塊鏈網(wǎng)絡所提供的智能合約服務。
四個組織 R1、R2、R3 和 R4，他們共同決定，并且達成了一個協(xié)議，他們將會設置并開發(fā)一個 Hyperledger Fabric 網(wǎng)絡。R4 被分配作為網(wǎng)絡的初始者，它有權設置網(wǎng)絡的初始版本。R4 不會在網(wǎng)絡中去進行任何的業(yè)務交易。R1 和 R2 在整個網(wǎng)絡中有進行私有通信的需求，R2 和 R3 也是。組織 R1 有一個客戶端的應用能夠在通道 C1 中進行業(yè)務的交易。組織 R2 有一個客戶端應用可以在通道 C1 和 C2 中進行類似的工作。組織 R3 可以在通道 C2 中做這樣的工作。節(jié)點 P1 維護了 C1 的賬本 L1 的副本。節(jié)點 P2 維護了 C1 的賬本 L1 和 C2 的賬本 L2 的副本。節(jié)點 P3 維護了 C2 的賬本 L2 的副本。這個網(wǎng)絡是根據(jù)在網(wǎng)絡配置 NC4 中指定的規(guī)則來進行管理的，整個網(wǎng)絡由組織 R1 和 R4 管理。通道 C1 是根據(jù)在通道配置 CC1 中指定的規(guī)則來管理的，這個通道由組織 R1 和 R2 管理。通道 C2 是根據(jù)在 通道配置 CC2 中指定的規(guī)則來管理的，這個通道由組織 R2 和 R3 管理。這有一個排序服務 O4 作為這個網(wǎng)絡 N 的一個網(wǎng)絡管理員節(jié)點，并且使用系統(tǒng)通道。排序服務同時也支持應用通道 C1 和 C2，來對交易進行排序、加入?yún)^(qū)塊然后分發(fā)。每個組織都有一個首選的 CA。
創(chuàng)建網(wǎng)絡
讓我們從頭開始來創(chuàng)建網(wǎng)絡的基礎：
當一個排序服務啟動后就形成了這樣的一個網(wǎng)絡。在我們的示例網(wǎng)絡 N 中，排序服務 O4 由一個單獨的節(jié)點組成，是根據(jù)一個網(wǎng)絡配置 NC4 來進行配置的。在網(wǎng)絡層面上，證書頒發(fā)機構 CA4 被用來向管理員和組織 R4 的網(wǎng)絡節(jié)點分配身份信息。
我們能夠看到，在定義 網(wǎng)絡 N 的時候，第一件事情就是定義一個 排序服務， O4。對于一個網(wǎng)絡在最初就考慮以管理員節(jié)點的形式定義這個排序服務是非常有幫助的。就像在之前同意的，O4 最初被配置并且由組織 R4 的一個管理員來啟動，并且由 R4 管理。配置 NC4 包含了描述網(wǎng)絡管理能力初始集合的規(guī)則。最初在網(wǎng)絡中集合僅賦予了 R4 這個權利。這個在將來會變化，我們稍后會看到，但是目前 R4 是這個網(wǎng)絡中唯一的一個成員。
證書頒發(fā)機構（Certificate Authorities，CA）
你也能夠看到一個證書頒發(fā)機構，CA4，它會被用來給管理者和網(wǎng)絡節(jié)點頒發(fā)證書。CA4 在我們的網(wǎng)絡中扮演著重要的角色，因為它會分配 X.509 證書，這個證書能夠用來識別屬于組織 R4 的組件。由 CA 頒發(fā)的證書也可以用來為交易提供簽名，來表明一個組織對交易的結果進行背書，背書是一筆交易可以被接受并記錄到賬本上的前提條件。讓我們對有關 CA 的兩個方面更詳細的介紹一下。
首先，在區(qū)塊鏈網(wǎng)絡中的不同組件之間，彼此是使用證書來標識自己是來自于特定組織的。這就是為什么通常會有多個 CA 來支持一個區(qū)塊鏈網(wǎng)絡，因為不同的組織通常會使用不同的 CA。在我們的網(wǎng)絡中，我們會使用 4 個 CA，每個組織會有一個 CA。事實上，CA 是非常重要的，所以 Hyperledger Fabric 提供給你一個內(nèi)置的 CA（被稱為 Fabric-CA）以方便使用，盡管在實際當中，組織會選擇使用它們自己的 CA。
將證書同成員組織進行匹配是通過一個稱為成員服務提供者（Membership Service Provider, MSP）的結構來實現(xiàn)的。網(wǎng)絡配置 NC4 使用一個已命名的 MSP 來識別由 CA4 頒發(fā)的證書的屬性，這些證書會關聯(lián)到組織 R4 下的證書持有者。NC4 接下來會使用在策略中的這個 MSP 名字來分配在網(wǎng)絡資源上的特殊權利。這個策略的一個例子就是，在 R4 中識別管理員，這個管理員可以向網(wǎng)絡中添加新的成員組織。我們沒有在這些圖標中顯示 MSP，因為他們會很雜亂，但是他們是非常重要的。
第二點，接下來我們會看到由 CA 簽發(fā)的證書是如何在交易的生成和驗證的流程中處于核心位置的。特別的，X.509 證書被用于客戶端應用的交易提案和智能合約的交易響應，來對交易進行數(shù)字簽名。接下來持有賬本副本的網(wǎng)絡節(jié)點在接受將交易更新到賬本之前會驗證交易簽名是否有效。
讓我們重新整理一下我們的區(qū)塊鏈網(wǎng)絡示例的基本結構。這有一個資源，網(wǎng)絡 N，有一些用戶能夠訪問這個網(wǎng)絡，這些用戶是由一個證書頒發(fā)機構 CA4 定義的，他們具有網(wǎng)絡配置 NC4 中包含的規(guī)則中所描述的在網(wǎng)絡 N 中的權利。當我們配置和啟動排序服務節(jié)點 O4 的時候上邊講的事情都會發(fā)生。
添加網(wǎng)絡管理員
NC4 最初被配置為僅僅允許 R4 用戶在網(wǎng)絡中具有管理的權限。在接下來的階段，我們會允許組織 R1 用戶也具有管理的權限。讓我們來看看網(wǎng)絡是如何演變的：
組織 R4 更新了網(wǎng)絡配置來使組織 R1 也成為了管理員?，F(xiàn)在 R1 和 R4 在網(wǎng)絡配置中便具有了相同的權限。
我們看到了新的組織 R1 變成了管理員，R1 和 R4 現(xiàn)在在網(wǎng)絡中具有了相同的權限。我們看到證書頒發(fā)機構 CA1 也被添加進來了，他用來標識 R1 組織的用戶?，F(xiàn)在從 R1 和 R4 來的用戶就已經(jīng)是網(wǎng)絡的管理員了。
盡管排序節(jié)點 O4 是運行在 R4 的基礎設施上的，如果 R1 能夠訪問到的話就可以共享管理的權限。也就是說 R1 或者 R4 可以更新這個網(wǎng)絡配置 NC4 來允許組織 R2 進行網(wǎng)絡維護中的部分功能。通過這種方式，盡管 R4 運行著排序服務，但是 R1 在其中也具有著全部的管理員權限，R2 具有有限的創(chuàng)建新聯(lián)盟的權限。
在這個最簡單的模式中，排序服務在網(wǎng)絡中是一個獨立的節(jié)點，就像你在例子中看到的。排序服務通常是多節(jié)點的，也可以被配置為在不同組織中的不同節(jié)點上。比如，我們可能會在 R4 中運行 O4 并連接到 O2，O2 是在組織 R1 中的另一個排序節(jié)點。通過這種方式，我們就有了一個多節(jié)點、多組織的管理結構。
我們會在后邊討論更多關于排序服務的話題，但是目前只需要把排序服務當成是一個管理者，它給不同的組織提供了對于網(wǎng)絡的管理的權限。
定義聯(lián)盟
盡管這個網(wǎng)絡當前可以被 R1 和 R4 管理，但是只有這些還是太少了。我們需要做的第一件事就是定義一個聯(lián)盟。這個詞表示“具有著共同命運的一個群組”，也就是在一個區(qū)塊鏈網(wǎng)絡中合理地選擇出來的一些組織。
讓我們來看看如何定義一個聯(lián)盟：
網(wǎng)絡管理員定義了一個包含兩個成員的聯(lián)盟 X1，包含組織 R1 和 R2。這個聯(lián)盟的定義被存儲在了網(wǎng)絡配置 NC4 中，會在接下來的網(wǎng)絡開發(fā)中被使用。CA1 和 CA2 是這兩個組織對應的證書頒發(fā)機構。
由于 NC4 的配置方式，只有 R1 和 R4 能夠創(chuàng)建新的聯(lián)盟。這個圖標顯示了一個新的聯(lián)盟 X1，它定義了 R1 和 R2 是它的聯(lián)盟組織。我們也看到了 CA2 也被添加進來標識來自 R2 的用戶。注意一個聯(lián)盟可以包含任意數(shù)量的組織，這里我們僅包含了兩個組織作為一個最簡單的配置。
為什么聯(lián)盟這么重要？我們能夠看到聯(lián)盟定義了網(wǎng)絡中的一部分組織，他們共享了彼此能夠交易的需求，在這個示例中就是 R1 和 R2 能夠進行交易。這對于一組有著共同的目標的組織來說是有意義的。
這個網(wǎng)絡雖然最初僅包含一個組織，現(xiàn)在已經(jīng)由多個組織來管理了。我們將從 R1、R2 和 R4 共享管控權的方式開始，這樣的構成更容易被理解。
現(xiàn)在我們要使用聯(lián)盟 X1 創(chuàng)建一個對于 Hyperledger Fabric 區(qū)塊鏈非常重要的部分——通道。
為聯(lián)盟創(chuàng)建通道
現(xiàn)在讓我們來創(chuàng)建對于 Fabric 區(qū)塊鏈網(wǎng)絡的關鍵部分——通道。通道是一個聯(lián)盟中的成員彼此進行通信的主要機制。在一個網(wǎng)絡中可能會有多個通道，但是現(xiàn)在讓我們從一個通道開始。
讓我們來看下第一個通道是如何被添加到這個網(wǎng)絡中的：
使用聯(lián)盟 X1 為 R1 和 R2 創(chuàng)建的的通道 C1。這個通道通過通道配置 CC1 來進行管理，完全獨立于網(wǎng)絡配置。CC1 是由 R1 和 R2 管理的，他們在 C1 上具有同等的權利。R4 在 CC1 中是沒有任何權利的。
通道 C1 為聯(lián)盟 X1 提供了一個私有的通信機制。我們能夠看到通道 C1 已經(jīng)關聯(lián)到了排序服務 O4 但是這并沒有附帶任何功能。在網(wǎng)絡開發(fā)的下一個階段，我們將會連接不同的組件，比如客戶端應用和 Peer 節(jié)點。但是到目前為止，一個通道就代表了將來要進行連接的可能性。
盡管 C1 是網(wǎng)絡 N 中的一部分，它還是跟這個網(wǎng)絡非常不同的。同時也要注意到組織 R3 和 R4 并沒有在這個通道中，因為這個通道僅僅是為了處理在 R1 和 R2 之間進行的交易的。在上一步中，我們看到了 R4 是如何能夠為 R1 分配權限來創(chuàng)建新的聯(lián)盟。R4 同樣也允許 R1 來創(chuàng)建通道。在這個圖中，組織 R1 和 R4 創(chuàng)建了通道 C1。再次強調(diào)，一個通道可以包含任意數(shù)量的組織，但是我們目前只包含了兩個組織，這是一個最簡單的配置。
需要注意的是通道 C1 如何具有一個同網(wǎng)絡配置 NC4 完全分開的配置 CC1。CC1 包含了賦予 R1 和 R2 在通道 C1 上的權利的規(guī)則，就像我們看到的那樣，R3 和 R4 在這個通道中沒有權限。R3 和 R4 只有被 R1 或 R2 添加到通道配置 CC1 中的規(guī)則后才能夠跟 C1 進行交互。這樣做的一個例子是定義誰能夠向通道中添加新的組織。特別要注意的是 R4 是不能夠將它自己添加到通道 C1 中的，這個只能由 R1 或者 R2 來授權添加。
為什么通道會如此重要？通道非常有用，因為提供了一個聯(lián)盟成員之間進行私有通信和私有數(shù)據(jù)的機制。通道提供了與其他通道以及整個網(wǎng)絡的隱私性。Hyperledger Fabric 在這一點上是很強悍的，因為它允許組織間共享基礎設施的同時又保持了私有性。這里并不矛盾，網(wǎng)絡中不同的聯(lián)盟之間會需要將不同的信息和流程進行適合的共享，通道為之提供了有效的機制。通道提供了一個有效的基礎設施共享，同時保持了數(shù)據(jù)和通信的隱私性。
我們也能夠看到一旦通道被創(chuàng)建之后，它會真正地代表了“從網(wǎng)絡中解放出來”。從現(xiàn)在開始和未來，只有在通道配置中指定的組織才能夠控制它。同樣的，從現(xiàn)在開始，之后的對于網(wǎng)絡配置 NC4 的任何改動都不會對通道配置 CC1 造成任何直接的影響。比如如果聯(lián)盟定義 X1 被改動了，它不會影響通道 C1 的成員。所以通道是有用的，因為他們允許構成通道的組織間進行私有的溝通。并且在通道中的數(shù)據(jù)跟網(wǎng)絡中的其他部分是完全隔離的，包括其他的通道。
同時，這里還有一個被排序服務使用的特殊的系統(tǒng)通道。它跟常規(guī)的通道是完全一樣的方式運行的，因此常規(guī)的通道有時候又被稱為應用通道。我們通常不會關心這個通道，但是以后我們會更詳細的討論它。
節(jié)點和賬本
現(xiàn)在，讓我們開始使用通道來將這個區(qū)塊鏈網(wǎng)絡以及組織的組件關聯(lián)到一起吧。在網(wǎng)絡開發(fā)的下一個階段，我們能夠看到我們的網(wǎng)絡 N 又新增了兩個組件，稱作 Peer 節(jié)點 P1 和賬本實例 L1。
一個 Peer 節(jié)點 P1 加入了通道 C1。物理上 P1 會存儲賬本 L1 的副本。P1 和 O4 可以使用通道 C1 來進行通信。
Peer 節(jié)點是存儲區(qū)塊鏈賬本副本的網(wǎng)絡組件。至少，我們已經(jīng)開始看到了一些區(qū)塊鏈標志性的組件了！P1 在這個網(wǎng)絡中的目的是單純地放置被其他人訪問的賬本 L1 的副本。我們可以想象 L1 會被物理地存儲在 P1 上，但是 邏輯上 是存儲在通道 C1 上。當我們向通道中添加更多的節(jié)點之后，我們對這些就會更加清楚。
P1 的配置中一個關鍵部分就是一個由 CA1 頒發(fā)的 X.509 身份信息，它將 P1 和組織 R1 關聯(lián)了起來。當 P1 啟動之后，它就可以使用排序 O4 加入通道C1。當 O4 收到這個加入請求，它會使用通道配置 CC1 來決定 P1 在這個通道中的權限。比如，CC1 決定 P1 是否能夠向賬本 L1 中讀取或寫入信息。
注意節(jié)點是如何通過所在組織加入到通道的，盡管我們僅僅加了一個節(jié)點，我們將會看到如何在網(wǎng)絡中將多個節(jié)點加入通道。我們也會在后邊的部分看到節(jié)點能夠扮演的不同的角色。
應用程序和智能合約鏈碼
現(xiàn)在通道 C1 擁有了一個賬本，我們可以連接客戶端應用來使用由 Peer 節(jié)點提供的服務了。
注意網(wǎng)絡是如何變化的：
智能合約 S5 被安裝在了 P1 上。在組織 R1 中的客戶端應用 A1 可以通過 Peer 節(jié)點 P1 使用 S5 來訪問賬本。A1、P1 和 O4 都加入了通道 C1，他們都可以使用由這個通道提供的通信設施。
在網(wǎng)絡開發(fā)的下一個階段，我們可以看到客戶端應用 A1 能夠使用通道 C1 來連接指定的網(wǎng)絡資源，在這個示例中，A1 能夠連接 Peer 節(jié)點 P1 和排序節(jié)點 O4。再次注意，看看通道是如何處在網(wǎng)絡和組織的組件的通信中心的。就像 Peer 節(jié)點和排序節(jié)點一樣，客戶端應用也會有一個使它和組織相關聯(lián)的身份信息。在我們的例子中，客戶端應用 A1 是跟組織 R1 相關聯(lián)的，盡管它處在 Fabric 區(qū)塊鏈網(wǎng)絡的外邊，但它是可以通過通道 C1 跟網(wǎng)絡相連的。
現(xiàn)在我們能夠清楚地看到 A1 能夠通過 P1 直接訪問賬本 L1，但是事實上，所有的訪問都是由一個稱為智能合約鏈碼 S5 的特殊程序來管理的。將 S5 理解為定義訪問賬本的常規(guī)模式，S5 提供了一套完整的定義來對賬本 L1 進行查詢及更新。簡言之，客戶端應用 A1 需要通過智能合約 S5 來獲得賬本 L1。
智能合約可以被每個組織的應用開發(fā)者創(chuàng)建來實現(xiàn)一個在聯(lián)盟成員間共享的業(yè)務流程。智能合約被用來幫助生成被分發(fā)到網(wǎng)絡中每個節(jié)點的交易。我們接下來會詳細討論。當網(wǎng)絡變得更大了之后，這個會更容易理解。現(xiàn)在，需要理解的重要的事情是，為了達到這一點，需要對智能合約執(zhí)行兩項操作，它必須被安裝，然后在通道中被定義。
Hyperledger Fabric 用戶經(jīng)常會在內(nèi)部使用名詞智能合約和鏈碼。大體上來說，一個智能合約定義了交易邏輯，它控制了在世界狀態(tài)中包含的一個業(yè)務對象的生命周期。然后它會被打包進一個鏈碼中，這個鏈碼會被部署到一個區(qū)塊鏈網(wǎng)絡中。可以把智能合約想象為管理交易，鏈碼則管理著智能合約應該如何被打包部署。
安裝鏈碼包
在智能合約 S5 被開發(fā)完之后，組織 R1 中的管理員必須要把它安裝到節(jié)點 P1 上。這是一個很簡單的操作。當完成之后，P1 就完全了解了 S5。特別地，P1 能夠看到 S5 的實現(xiàn)邏輯（用來訪問賬本 L1 的程序代碼）。我們將這個同 S5 的接口進行對比，接口只是描述了 S5 的輸入和輸出，但是沒有它的實現(xiàn)。
當一個組織在一個通道中有多個 Peer 節(jié)點時，可以選擇在哪個節(jié)點安裝智能合約，而不需要每個 Peer 節(jié)點上都安裝。
定義鏈碼
盡管鏈碼會被安裝在組織的 Peer 節(jié)點上，但是它是在一個通道范圍內(nèi)被管理和維護的。每個組織需要批準一個鏈碼定義，和一系列參數(shù)來定義在一個通道中鏈碼應該被如何使用。一個組織必須要批準一個鏈碼定義，才能使用已經(jīng)安裝的智能合約來查詢賬本和為交易背書。在我們的例子中，只有一個單獨的 Peer 節(jié)點 P1，一個組織中的管理員 R1 必須要批準 S5 的鏈碼定義。
在鏈碼定義能夠被提交到通道并且用來同通道賬本進行互動之前，需要有效數(shù)量的組織來批準一個鏈碼的定義（默認為大多數(shù)）。因為通道中只有一個成員，R1 的管理員可以提交 S5 的鏈碼定義到通道 C1。當這個定義提交后，S5 就可以被客戶端應用 A1 調(diào)用了！
注意，雖然在這個通道上的每個組件現(xiàn)在都可以訪問 S5，但是他們是不能夠看到它的程序邏輯的。這對于安裝了這個智能合約的節(jié)點還是保持隱私性的，在我們的示例中指的是 P1。從概念上講，這意味著實際上是定義并提交了智能合約的接口到通道，而不是安裝了智能合約的實現(xiàn)。為了強調(diào)這個想法，安裝智能合約展示了我們是如何將它物理地存儲在 Peer 節(jié)點上，而實例化智能合約展示了我們是如何將它邏輯地存儲在通道中。
背書策略
在鏈碼定義提供的信息中最重要的部分就是背書策略。它描述了在交易被其他的組織接受并存儲在他們的賬本副本上之前，哪些組織必須要同意此交易。在我們的示例網(wǎng)絡中，只有當 R1 和 R2 對交易進行背書之后，交易才能夠被接受并存儲到賬本 L1 中。
將鏈碼定義提交到通道的同時背書策略也會被放置在通道賬本上，通道中的每個成員都可以訪問該策略。你可以在交易流程話題中閱讀更多關于背書策略的內(nèi)容。
調(diào)用智能合約
當智能合約被安裝在 Peer 節(jié)點并且在通道上定義之后，它就可以被客戶端應用調(diào)用了?？蛻舳藨檬峭ㄟ^發(fā)送交易提案給智能合約背書策略所指定的 Peer 的節(jié)點方式來調(diào)用智能合約的。這個交易的提案會作為智能合約的輸入，智能合約會使用它來生成一個背書交易響應，這會由 Peer 節(jié)點返回給客戶端應用。
這些交易的響應會和交易的提案打包到一起形成一個完整的經(jīng)過背書的交易，他們會被分發(fā)到整個網(wǎng)絡。我們會在之后更詳細的了解，現(xiàn)在理解應用是如何調(diào)用智能合約來生成經(jīng)過背書的交易就已經(jīng)足夠了。
在網(wǎng)絡開發(fā)的這個階段，我們能夠看到組織 R1 完整參與了這個網(wǎng)絡。它的應用，從 A1 開始，通過智能合約 S5 訪問賬本 L1，并生成將要被 R1 背書的交易，最后會被接受并添加到賬本中，因為這滿足了背書策略。
完成網(wǎng)絡
我們的目標是為聯(lián)盟 X1（由組織 R1 和 R2 構成）創(chuàng)建一個通道。網(wǎng)絡開發(fā)的下一個階段是將組織 R2 的基礎設施添加到網(wǎng)絡中。
讓我們看一下網(wǎng)絡是如何演進的：
這個網(wǎng)絡通過增加新組織 R2 的基礎設施變得更大了。具體來說，R2 添加了 Peer 節(jié)點 P2，它會存有賬本 L1 的一個副本，和鏈碼 S5。R2 像 R1 一樣批準了相同的鏈碼定義。P2 也加入了通道 C1，也有一個客戶端應用 A2。A2 和 P2 使用由 CA2 頒發(fā)的證書來標識 A2 和 P2。所有這些都說明了 A1 和 A2 能夠使用 Peer 節(jié)點 P1 或者 P2 來調(diào)用在 C1 上的 S5。
我們能夠看到組織 R2 在通道 C1 上添加了 Peer 節(jié)點 P2。P2 也存儲了賬本 L1 和智能合約 S5 的副本。R2 也添加了客戶端應用 A2，它能夠通過通道 C1 連接到網(wǎng)絡。為了達到這個目的，組織 R2 的管理員添加了 Peer 節(jié)點 P2 并且將它加入到通道 C1，就像 R1 的管理員一樣。管理員也必須要像 R1 那樣批準相同的鏈碼定義。
我們創(chuàng)建了第一個可運行的網(wǎng)絡！目前，我們定義了一個通道，在這個通道中組織 R1 和 R2 能夠彼此進行交易。特別地，這意味著 A1 和 A2 能夠使用在通道 C1 上的智能合約 S5 和賬本 L1 來生成交易。
生成并接受交易
相較于經(jīng)常會存有賬本副本的 Peer 節(jié)點，我們能夠看到兩種類型的 Peer 節(jié)點，一類是存儲智能合約而另一類則不存。在我們的網(wǎng)絡中，每個 Peer 節(jié)點都會存儲智能合約的副本，但是在一個更大的網(wǎng)絡中，會存在更多的 Peer 節(jié)點并且沒有存儲智能合約的副本。節(jié)點只有在安裝了智能合約之后才能夠運行它，但是這個 Peer 節(jié)點可以通過連接到通道來獲取一個智能合約的接口信息。
對于沒有安裝智能合約的 Peer 節(jié)點，我們不應該認為他們在某種程度上是較差的。更多情況下，帶有智能合約的 Peer 節(jié)點通常會擁有一個特殊的能力——幫助生成交易。需要注意的是所有的 Peer 節(jié)點都可以驗證并接受或者拒絕交易存入他們的賬本 L1 的副本中。然而，只有安裝了智能合約的 Peer 節(jié)點才能夠參與交易背書的流程，這是生成一筆有效交易的核心。
我們不需要關心交易生成的詳細信息、分發(fā)和被接受的，只需知道我們有一個區(qū)塊鏈網(wǎng)絡，在這個網(wǎng)絡中組織 R1 和 R2 能夠共享由賬本記錄的交易信息和流程就夠了。我們會在其他的部分學習更多關于交易、賬本以及智能合約。
Peer 節(jié)點的類型
在 Hyperledger Fabric 中，所有的 Peer 節(jié)點都是一樣的，基于這個網(wǎng)絡的配置，Peer 節(jié)點能夠擔當多個角色。我們現(xiàn)在對于描述這些角色的典型網(wǎng)絡拓撲已經(jīng)有足夠的理解了。
提交節(jié)點。通道中的每個 Peer 節(jié)點都是一個提交節(jié)點。他們會接收生成的區(qū)塊，在這些區(qū)塊被驗證之后會以附加的方式提交到 Peer 節(jié)點的賬本副本中。
-
背書節(jié)點。每個安裝了智能合約的 Peer 節(jié)點都可以作為一個背書節(jié)點。然而，想要成為一個真正的背書節(jié)點，節(jié)點上的智能合約必須要被客戶端應用使用，來生成一個被簽名的交易響應。背書節(jié)點的術語就是這樣來的。
智能合約的背書策略明確了在交易被接受并且記錄到提交節(jié)點的賬本之前，需要哪些組織的 Peer 節(jié)點為交易簽名。
這是 Peer 節(jié)點的兩個主要類型，一個 Peer 節(jié)點還可以擔任的兩種其他的角色:
-
主節(jié)點。當組織在通道中具有多個 Peer 節(jié)點的時候，會有一個主節(jié)點，它負責將交易從排序節(jié)點分發(fā)到該組織中其他的提交節(jié)點。一個節(jié)點可以選擇參與靜態(tài)或者動態(tài)的領導選舉。
這是很有用的，從管理者的角度來考慮的話會有兩套節(jié)點，一套是靜態(tài)選擇的主節(jié)點，另一套是動態(tài)選舉的主節(jié)點。對于靜態(tài)選擇，0個或者多個節(jié)點可以被配置為主節(jié)點。對于動態(tài)選舉，一個節(jié)點會被選舉成為主節(jié)點。另外，在動態(tài)選舉主節(jié)點中，如果一個主節(jié)點出錯了，那么剩下的節(jié)點將會重新選舉一個主節(jié)點。
這意味著一個組織的節(jié)點可以有一個或者多個主節(jié)點連接到排序服務。這有助于改進需要處理大量交易的大型網(wǎng)絡的彈性以及可擴展性。
錨節(jié)點。如果一個 Peer 節(jié)點需要同另一個組織的 Peer 節(jié)點通信的話，它可以使用對方組織通道配置中定義的錨節(jié)點。一個組織可以擁有0個或者多個錨節(jié)點，并且一個錨節(jié)點能夠幫助很多不同的跨組織間的通信。
需要注意的是，一個 Peer 節(jié)點可以同時是一個提交節(jié)點、背書節(jié)點、主節(jié)點和錨節(jié)點。在實際情況中只有錨節(jié)點是可選的，一般都會有一個主節(jié)點，至少一個背書節(jié)點和一個提交節(jié)點。
向通道中添加組織和節(jié)點
當 R2 加入到通道的時候，組織必須要向它的 Peer 節(jié)點 P2 上安裝智能合約 S5。這很明顯，如果應用 A1 或者 A2 想要使用 Peer 節(jié)點 P2 上的 S5 來生成交易，節(jié)點 P2 就必須安裝了智能合約 S5?，F(xiàn)在，Peer 節(jié)點 P2 有了智能合約和賬本的物理的副本，像 P1 一樣，它可以生成并接受交易到它的賬本 L1 的副本上了。
R2 必須要像 R1 那樣批準相同的鏈碼定義才能夠使用智能合約 S5。因為鏈碼定義已經(jīng)被組織 R1 提交到了通道，當 R2 的組織批準了鏈碼定義并且安裝了鏈碼包之后，R2 就可以使用鏈碼了。提交的交易只需要發(fā)生一次。通道中新的組織批準了通道中其他成員已經(jīng)同意的鏈碼參數(shù)之后就可以使用鏈碼了。因為鏈碼定義的批準是發(fā)生在組織級別的，所以 R2 只需要批準鏈碼定義一次，然后就可以將多個節(jié)點加入到安裝了鏈碼包的通道。然而，如果 R2 想改變鏈碼的定義，那么 R1 和 R2 需要為他們的組織批準一個新的定義，然后其中的一個組織需要將定義提交到通道。
在我們的網(wǎng)路中，我們能夠看到通道 C1 連接了兩個客戶端應用、兩個 Peer 節(jié)點和一個排序服務。因為這里只有一個通道，也就只有一個跟這個通道組件交互的邏輯賬本。Peer 節(jié)點 P1 和 P2 具有相同的賬本 L1 的副本。智能合約 S5 的副本通常會使用相同的編程語言來進行相同的實現(xiàn)，如果語言不同，他們也必須有相同的語義。
我們能夠看到，在網(wǎng)絡精心的增加節(jié)點有助于提升吞吐量、穩(wěn)定性以及彈性。比如，網(wǎng)絡中有更多的節(jié)點將允許更多的應用來連接這個網(wǎng)絡，并且當組織中有多個節(jié)點發(fā)生計劃內(nèi)和計劃外停機的時候可以提供額外的彈性。
這意味著可以通過配置網(wǎng)絡拓撲來支持不同的目的，網(wǎng)絡的大小是沒有理論上限的。并且，一個組織內(nèi)節(jié)點的發(fā)現(xiàn)和通信的技術機制，gossip 協(xié)議，可以容納大量的 Peer 節(jié)點來支持這樣的拓撲。
網(wǎng)絡和通道策略的精心使用可以很好的管理龐大的網(wǎng)絡。組織可以隨意地向網(wǎng)絡中添加 Peer 節(jié)點，只要他們滿足了網(wǎng)絡的策略。網(wǎng)絡及通道的策略在描繪去中心化網(wǎng)絡中的自主和管控之間創(chuàng)建了平衡。
簡化視覺詞匯表
我們現(xiàn)在要簡化一下我們示例區(qū)塊鏈網(wǎng)絡的視覺詞匯表。隨著網(wǎng)絡的增長，之前幫助我們理解通道的連線將會變得越發(fā)笨拙。設想一下如果我們添加了另外一個 Peer 節(jié)點或者客戶端應用，又或者另外一個通道的話，我們的圖表將會變得有多復雜。
我們接下來要為網(wǎng)絡中添加更多內(nèi)容，在我們做這個之前，讓我們來一起簡化一下視覺詞匯表吧。下邊是我們目前開發(fā)的網(wǎng)絡的簡圖：
這個圖表展示了在網(wǎng)絡 N 中和通道 C1 的相關內(nèi)容：客戶端應用 A1 和 A2 能夠通過節(jié)點 P1 和 P2 以及排序節(jié)點 O4 使用通道 C1 來進行通信。Peer 節(jié)點 P1 和 P2 可以使用通道 C1 的通信服務。排序服務 O4 可以使用通道 C1 的通信服務。通道配置 CC1 應用于通道 C1。
注意，這個網(wǎng)絡的圖表通過將通道連線替換成了連接點的方式進行了簡化，連接點顯示為一個藍色的圓圈，里邊包含了通道數(shù)字。沒有任何的信息丟失。這種展現(xiàn)方式更加的可擴展，因為它去除了交叉的連接線。這個讓我們能夠更清晰地展現(xiàn)更大的網(wǎng)絡。我們通過更加關注組件和通道之間的連接點，而不是通道本身的方式實現(xiàn)了這樣的簡化。
添加另外一個聯(lián)盟定義
在網(wǎng)絡開發(fā)的下一個階段，我們引入了組織 R3。我們將會給 R2 和 R3 一個新的獨立的應用通道，以便他們互相進行交易。這個應用通道會同之前定義的通道完全分離開來，所以 R2 和 R3 的交易信息會對他們保持良好的隱私性。
讓我們回到網(wǎng)絡級別并且為 R2 和 R3 定義一個新的聯(lián)盟 X2：
來自 R1 或者 R4 的網(wǎng)絡管理員添加了一個新的聯(lián)盟定義 X2，其中包含了 R2 和 R3。這將會被用來為 X2 定義一個新的通道。
注意到現(xiàn)在網(wǎng)絡中已經(jīng)有兩個聯(lián)盟被定義了：組織 R1 和 R2 的聯(lián)盟 X1，以及組織 R2 和 R3 的聯(lián)盟 X2。引入聯(lián)盟 X2 是為了給 R2 和 R3 創(chuàng)建一個新的通道。
新通道只能夠由網(wǎng)絡配置策略 NC4 中指定的組織比如 R1 或者 R4 來創(chuàng)建，因為只有他們才有相關的權限。這是一個區(qū)分在網(wǎng)絡級別和通道級別誰能管理資源的策略的例子。在工作中觀察這些策略能夠幫助我們理解為什么 Hyperledger Fabric 具有一個復雜的層級的策略結構。
實際上，聯(lián)盟定義 X2 已經(jīng)被添加進了網(wǎng)絡配置 NC4。我們會在文檔的其他部分討論具體的技術細節(jié)。
添加一個新的通道
讓我們使用這個新的聯(lián)盟定義 X2 來創(chuàng)建一個新的通道 C2。為了幫助加強你對于簡單通道符號的理解，我們會使用兩種視覺樣式：通道 C1，使用藍色的圓圈來表示；通道C2，使用紅色的連接線表示：
一個使用聯(lián)盟定義 X2 為 R2 和 R3 的創(chuàng)建的新通道 C2。這個通道具有通道配置 CC2，完全同網(wǎng)絡配置 NC4 以及通道配置 CC1 分離。通道 C2 由 R2 和 R3 來管理，他們兩個就像 CC2 中的一個策略定義的那樣具有相同的權利。R1 和 R4 在 CC2 中是沒有任何權利的。
通道 C2 為聯(lián)盟 X2 提供了一個私有的通信機制。這里，需要注意的是聯(lián)盟將組織統(tǒng)一到一起的方式就是通道。通道配置 CC2 現(xiàn)在包含了管理通道資源的策略，通過通道C2 來向組織分配管理權限。這由 R2 和 R3 唯一管理，R1 和 R4 在通道 C2 中是沒有權力的。比如可以更新通道配置 CC2 來添加新的組織以支持網(wǎng)絡的增長，但是這個只能由 R2 或者 R3 來完成。
注意，通道配置 CC1 和 CC2 以及網(wǎng)絡配置 NC4 是彼此完全分離的。我們也看到了一個 Hyperledger Fabric 網(wǎng)絡的去中心化的特質(zhì)，一旦通道 C2 被創(chuàng)建后，它是由組織 R2 和 R3 來管理的，獨立于網(wǎng)絡中的其他元素。通道的策略通常是保持彼此分離的，并且只能由通道中授權的組織來進行改動。
隨著網(wǎng)絡和通道的發(fā)展，網(wǎng)絡和通道的配置也會升級。這里有一個以可控形式實現(xiàn)的流程——引入包含配置變更的配置交易。每次配置的改變會生成一個新的配置區(qū)塊，在后邊的話題中，我們會看到這些區(qū)塊是如何被驗證和接受，并更新相關網(wǎng)絡及通道的配置。
網(wǎng)絡和通道配置
在我們的示例網(wǎng)絡中，我們看到了網(wǎng)絡和通道配置的重要性。這些配置很重要，是因為他們封裝了網(wǎng)絡成員同意的策略，這提供了對網(wǎng)絡資源訪問控制的共享參考。網(wǎng)絡和通道配置也包含了有關網(wǎng)絡和通道組成的一些情況，比如聯(lián)盟的名字以及它所包含的組織。
比如，當使用排序服務節(jié)點 O4 首次組建網(wǎng)絡的時候，它的行為是由網(wǎng)絡配置 NC4 來管理的。NC4 的初始配置中只包含了允許組織 R4 來管理網(wǎng)絡資源的策略。NC4 接下來被變更為也允許 R1 來管理網(wǎng)絡資源。一旦這個改動生效后，任何來自于組織 R1 或者 R4 的管理員連接到 O4 都將具有網(wǎng)絡管理的權限，因為這是網(wǎng)絡配置 NC4 中的策略所允許的。在內(nèi)部來說，在排序服務中的每個節(jié)點都記錄著網(wǎng)絡配置中的每個通道，所以在網(wǎng)絡級別中每個通道被創(chuàng)建時都會有一條記錄。
這就意味著，盡管排序服務節(jié)點 O4 創(chuàng)建了聯(lián)盟 X1 和 X2 以及通道 C1 和 C2，網(wǎng)絡配置 NC4 中包含了 O4 遵守的這個網(wǎng)絡的智慧。只要 O4 是一個好的參與者，并且在它處理網(wǎng)絡資源的任何時候都能夠正確的實現(xiàn)在 NC4 中定義的策略的話，那么我們的網(wǎng)絡就會按照所有的組織一致同意的方式工作。在很多方面 NC4 被認為要比 O4 更重要，因為最終是它來管控網(wǎng)絡的訪問。
與 Peer 節(jié)點同樣的概念也可以應用到通道配置。在我們的網(wǎng)絡中，P1 和 P2 是很類似的角色。當 Peer 節(jié)點 P1 和 P2 同客戶端應用程序 A1 或者 A2 進行交互的時候，他們使用了在通道配置中定義的策略來管理對通道 C1 資源的訪問。
比如，如果 A1 想要訪問在 Peer 節(jié)點 P1 或者 P2 上的智能合約鏈碼 S5 的話，每個 Peer 節(jié)點會使用它的 CC1 的副本來決定 A1 能夠進行哪些操作。比如根據(jù)在 CC1 中定義的策略，A1 可能被允許從賬本 L1 上讀取或者寫入數(shù)據(jù)。后邊我們會看到在通道和通道配置 CC2 中對操作者相同的模式。我們能夠看到盡管 Peer 節(jié)點和應用程序在網(wǎng)絡中是關鍵的操作者，他們在一個通道中的行為更多的是由通道配置的策略來決定的。
最后，理解網(wǎng)絡和通道配置是如何在物理上來實現(xiàn)的是非常重要的。我們能夠看到網(wǎng)絡和通道的配置在邏輯上是獨立的，網(wǎng)絡會有一個配置，每個通道也會有一個配置。這一點非常重要，任何訪問網(wǎng)絡或者通道的組件必須對不同組織的授權有共同的理解。
盡管在邏輯上是獨立的配置，實際上它會被復制到組成網(wǎng)絡或者通道的每個節(jié)點，并保持一致。比如，在我們的網(wǎng)絡中，節(jié)點 P1 和 P2 都有通道配置 CC1 的副本，在這個網(wǎng)絡完成的時候，節(jié)點 P2 和 P3 也會有通道配置 CC2 的副本。類似的，排序服務節(jié)點 O4 有網(wǎng)絡配置的副本，但是在多節(jié)點配置中，每個排序服務節(jié)點都會有他們自己的關于網(wǎng)絡配置的副本。
網(wǎng)絡和通道的配置使用了和用戶交易所使用的相同的區(qū)塊鏈技術來保持一致，只是被叫做配置的交易。想要改變網(wǎng)絡或者通道的配置，管理員必須要提交一個配置交易來改變網(wǎng)絡或者通道的配置。該交易必須被對應策略中指定的組織簽名，這些組織負責配置的改變。這個策略被稱為mod_policy 我們稍后討論。
實際上，排序服務節(jié)點運行著一個小型的區(qū)塊鏈，通過我們前邊提到過的系統(tǒng)通道連接。使用系統(tǒng)通道排序服務節(jié)點分發(fā)網(wǎng)絡配置交易。這些交易被用來維護每個排序服務節(jié)點間網(wǎng)絡配置副本的一致性。類似的，應用程序通道中的 Peer 節(jié)點分發(fā)通道配置交易。同樣，這些交易被用來維護每個 Peer 節(jié)點通道配置的一致性。
這種對象在邏輯上獨立，卻在物理分發(fā)上平衡，這在 Hyperledger Fabric 中是一種常見的模式。像網(wǎng)絡配置這樣的對象，邏輯上是獨立的，但在一些排序服務節(jié)點間被物理復制。對于通道配置、賬本及智能合約，我們也看到了這樣的情況，他們被安裝在了多個地方，但是在邏輯上他們的接口是在通道級別上的。這種模式你會在 Hyperledger Fabric 中重復地看到多次，這使 Hyperledger Fabric 變得既去中心化，有能夠在同一時間進行管理。
添加另外一個 Peer 節(jié)點
現(xiàn)在組織 R3 能夠完全地參與到通道 C2 中了，讓我們來把它的基礎設施組件添加到通道中。我們不會每次只加一個組件，我們將會一次性地將 Peer 節(jié)點、它的賬本本地副本、智能合約以及客戶端應用程序都加進來。
讓我們看一下添加了組織 R3 的組件的網(wǎng)絡是什么樣：
這個圖展示了在網(wǎng)絡 N 中關于通道 C1 和 C2 的以下內(nèi)容：客戶端應用程序 A1 和 A2 可以使用通道 C1 來同節(jié)點 P1 和 P2，以及排序服務 O4 進行通信?？蛻舳藨贸绦?A3 能夠使用 C2 同節(jié)點 P3 和排序服務 O4 進行通信。排序服務 O4 可以使用通道 C1 和 C2 的通信服務。通道配置 CC1 應用到了通道 C1 上，CC2 應用到了通道 C2 上。
首先，要注意的是因為 Peer 節(jié)點 P3 連接到了通道 C2，所以它有一個和使用通道 C1 的節(jié)點不同的賬本 L2。賬本 L2 被有效地控制在了通道 C2 中。賬本 L1 是完全獨立的，它被限制在了通道 C1。這么做是有意義的，通道 C2 的目的是為聯(lián)盟 X2 的成員提供私有通信，并且賬本 L2 是他們的交易的私有存儲。
同樣的方式，智能合約 S6 安裝在 Peer 節(jié)點 P3，定義在通道 C2 上，用來為賬本 L2 提供可控的訪問。應用程序 A3 現(xiàn)在能夠使用通道 C2 來調(diào)用智能合約 S6 提供的服務來生成交易，這些交易會在網(wǎng)絡中被每個賬本的副本所接受。
到目前為止，我們有一個獨立的網(wǎng)絡，其中定義了兩個完全獨立的通道。這些通道為組織提供了獨立的管理設施來彼此交易。這是在工作中的去中心化，我們在管控和自制之間具有著一個平衡。這是通過應用到通道的策略來實現(xiàn)的，這些通道由不同的組織控制，而通道又會影響這些組織。
把一個 Peer 節(jié)點添加到多個通道中
在網(wǎng)絡開發(fā)的最后一個階段，讓我們把焦點再轉回組織 R2。我們可以通過把 R2 加入到多個通道中的方式來讓它成為兩個聯(lián)盟 X1 和 X2 的成員。
這個圖展示了在網(wǎng)絡 N 中關于通道 C1 和 C2 的以下內(nèi)容：客戶端應用程序 A1 能夠使用通道 C1 與節(jié)點 P1 和 P2 以及排序服務 O4 進行通信?？蛻舳藨贸绦?A2 可以使用通道 C1 與節(jié)點 P1 和 P2 進行通信，以及使用通道 C2 與節(jié)點 P2 和 P3 以及排序服務 O4 進行通信?？蛻舳藨贸绦?A3 能夠使用通道 C2 與節(jié)點 P3 和 P2 和排序服務 O4 進行通信。排序服務 O4 能夠使用通道 C1 和 C2 的通信服務。通道配置 CC1 應用在了通道 C1 中，CC2 應用在了通道 C2 中。
我們能夠看到，R2 在網(wǎng)絡中是一個特別的組織，因為它是唯一一個同時屬于兩個通道成員的組織！它能夠在通道 C1 上跟組織 R1 進行交易，也能夠同時使用另外一個通道 C2 來跟組織 R3 進行交易。
注意，節(jié)點 P2 將智能合約 S5 安裝在通道 C1 中，將智能合約 S6 安裝在通道 C2 中。節(jié)點 P2 同時是兩個通道的成員，并且通過不同的智能合約來處理不同的賬本。
通道是一個非常強大的概念，既提供了組織間的分離，又提供了組織間進行合作的機制?？偟膩碚f，這個基礎設施是由一系列獨立的組織來提供的，并且在這些組織間進行共享。
重點需要注意的是，在不同通道上交易時 Peer 節(jié)點 P2 的行為受到不同的約束。特別地，在通道配置 CC1 中包含的策略決定了 P2 在通道 C1 中進行交易的時候的操作，這也是通道配置 CC2 中的策略對 P2 在通道 C2 中的控制。
這是值得的，R2 和 R1 同意了通道 C1 的規(guī)則，R2 和 R3 同意了通道 C2 的規(guī)則。這些規(guī)則包含在對應的通道策略中，它們能夠且必須要在通道里被用來強制執(zhí)行正確的操作，就像當初同意的一樣。
類似的，我們能夠看到客戶端應用程序 A2 現(xiàn)在能夠在通道 C1 和 C2 上進行交易。同樣，它也會按照在相關通道配置中的策略來進行管理。另外，注意客戶端應用程序 A2 和 Peer 節(jié)點 P2 在使用一個混合的視覺詞匯表，既包括線也包括連接點。你能夠看到他們是等價的，他們在視覺上是同義詞。
排序服務
善于觀察的讀者可能已經(jīng)注意到排序服務看起來像是一個中心化的組件，它最初被用來創(chuàng)建這個網(wǎng)絡，然后連接到了網(wǎng)絡中的每個通道。即使我們添加 R1 和 R4 到了管理排序服務的網(wǎng)絡配置策略 NC4，這個排序節(jié)點依舊是運行在 R4 的基礎設施上。在一個去中心化的世界中，這個看起來是錯誤的！
不必擔心！我們的示例網(wǎng)絡顯示的是一個最簡單的排序服務配置，為了幫助你從網(wǎng)絡管理員的角度來理解。事實上，排序服務本身可以是完全去中心化的！我們之前提到過一個排序服務可以包含很多單獨的由不同組織所有的節(jié)點，讓我們看一下在我們的網(wǎng)絡中應該怎么做。
讓我們看一個更加真實的排序服務節(jié)點配置：
一個多組織的排序服務。排序服務包括排序服務節(jié)點 O1 和 O4。O1 是由組織 R1 提供的，O4 是由組織 R4 提供的。網(wǎng)絡配置 NC4 中定義了來自 R1 和 R4 的操作者的網(wǎng)絡資源權限。
我們能夠看到這個排序服務是完全去中心化的，它在組織 R1 和 R4 中運行。網(wǎng)絡配置策略 NC4 賦予了 R1 和 R4 對于網(wǎng)絡資源相同的權限。R1 和 R4 的客戶端應用程序和 Peer 節(jié)點可以通過連接 O1 或者 O4 來管理網(wǎng)絡資源，就像在網(wǎng)絡配置 NC4 中定義的策略一樣，兩個節(jié)點是用相同的方式來操作的。在實際中，組織的操作者愿意使用自己組織提供的基礎設施，但是顯然并不總是這樣的。
去中心化的交易分發(fā)
跟作為網(wǎng)絡的管理點一樣，排序服務同樣提供了另外一個關鍵的設施——交易的分發(fā)點。排序服務是一個從應用程序搜集背書過的交易的組件，然后它會把這些交易進行排序并放進區(qū)塊中，這些區(qū)塊會被分發(fā)到通道中的每個 Peer 節(jié)點。在每個這樣的提交節(jié)點中，交易不管是有效的還是無效的都會被記錄下來，并且他們本地賬本副本也會更新。
注意這里，排序服務節(jié)點 O4 在通道 C1 扮演著和網(wǎng)絡 N 不同的角色。當在通道級別操作時，O4 的角色是搜集交易并在通道中分發(fā)區(qū)塊。它依據(jù)通道配置 CC1 中定義的策略來操作。當在網(wǎng)絡級別操作時，O4 的角色是提供對網(wǎng)絡資源的管理，這是根據(jù)網(wǎng)絡配置 NC4 中定義的策略來操作的。我們應該注意這些不同的角色是如何在通道和網(wǎng)絡的配置中定義的。這個會加強你對 Hyperledger Fabric 中基于配置的可聲明策略的重要性的印象。兩種策略都被定義并且用來管控聯(lián)盟中的每個成員都同意的行為。
我們能夠看到排序服務和 Hyperledger Fabric 中的其他組件一樣，是一個完全去中心化的組件。不管是作為一個網(wǎng)絡的管理點，還是作為一個通道中的分發(fā)節(jié)點，它的節(jié)點都可以依據(jù)在一個網(wǎng)絡中的多個組織的要求被分散地運行。
修改策略
經(jīng)過我們對于這個示例網(wǎng)絡的解析，我們看到了在這個系統(tǒng)中使用策略對不同操作者行為控制的重要性。我們僅僅討論了一些可用的策略，還有很多不同方面管控行為的定義。這些單獨的策略會在文檔的其他部分討論。
最重要的一點，Hyperledger Fabric 提供了一個獨特的強大的策略來允許網(wǎng)絡和通道管理員自己來管理策略的變更！底層的理論是：策略的變更是一個常量，無論它是發(fā)生在不同的組織間，還是由外部的監(jiān)管者加進來的。比如一個新的組織想要加入一個通道或者一些已經(jīng)存在的組織想要增加或減少他們的權限。讓我們來詳細的看一下在 Hyperledger Fabric 中修改策略是如何實現(xiàn)的。
理解這個的關鍵點是一個策略的變化是由策略中的策略來管理的。那就是修改策略，或者簡稱mod_poicy，它是在管理變化的網(wǎng)絡或者通道配置中的頭等策略。關于我們是如何已經(jīng)使用了 mod_policy 來管理網(wǎng)絡中的變化，我們提供了兩個簡單的示例。
第一個例子是創(chuàng)建網(wǎng)絡初始的時候。這時，只有組織 R4 被允許管理網(wǎng)絡。在實際當中，這個是通過在網(wǎng)絡配置 NC4 中把 R4 定義為唯一一個有權限來管理網(wǎng)絡資源的組織來實現(xiàn)的。并且對于 NC4 的 mod_policy 也僅僅提到了組織 R4，因此只有 R4 被允許改變這個配置。
我們接下來將網(wǎng)絡 N 進行了演進，同時允許組織 R1 來管理網(wǎng)絡。R4 通過將 R1 添加到通道創(chuàng)建和聯(lián)盟創(chuàng)建的策略中來實現(xiàn)。因為這個改動，R1 就可以定義聯(lián)盟 X1 和 X2 了，并且可以創(chuàng)建通道 C1 和 C2。R1 在網(wǎng)絡配置中對于通道和聯(lián)盟策略具有了同樣的管理權限。
R4 甚至可以通過網(wǎng)絡配置來給 R1 賦予更大的權限！R4 可以將 R1 添加到 mod_poicy，這樣 R1 就同樣可以管理這個網(wǎng)絡中的變更了。
第二個權利要比第一個權利大的多，因為現(xiàn)在 R1 具有了在網(wǎng)絡配置 NC4 上的所有權限！這意味著，R1 能夠移除 R4 在這個網(wǎng)絡的管理權限。在實際當中，R4 會將 mod_policy 配置成對這樣的改動需要 R4 批準，或者需要所有在 mod_policy 中定義的組織批準。這里有很大的靈活性來使 mod_policy 根據(jù)需要來定義任何更改流程。
這就是在實際工作中的 mod_policy，它允許一個基本的配置被優(yōu)雅地演進為一個成熟的配置。這些演進都需要所有被引入的組織的同意。mod_policy 像在一個網(wǎng)絡或者通道配置中的每一個其他的策略一樣，它定義了一系列的組織，這些組織被允許自己來修改這個 mod_policy。
我們僅僅在這個部分了解了策略以及 mod_policy 的表面的內(nèi)容。這會在策略的話題中有更詳細的討論，但是現(xiàn)在讓我們回到這個已經(jīng)完成的網(wǎng)絡！
網(wǎng)路已經(jīng)完全形成了
讓我們使用一個統(tǒng)一的視覺詞典來回顧一下我們的網(wǎng)絡應該是什么樣。我們使用更加緊湊的視覺語法來稍微重新組織一下這個網(wǎng)絡，因為它能夠更好地適應更大的一個拓撲結構：
在這個圖中，我們看到了這個 Fabric 區(qū)塊鏈網(wǎng)絡包括了兩個應用程序通道以及一個排序通道。組織 R1 和 R4 負責排序通道，R1 和 R2 負責藍色的應用程序通道，R2 和 R3 負責紅色的應用程序通道?？蛻舳藨贸绦?A1 是組織 R1 的元素，CA1 是它的證書頒發(fā)機構。注意到組織 R2 的節(jié)點 P2 可以使用藍色的通信設施，也可以使用紅色的應用程序通道。每個應用程序通道具有它自己的通道配置，這里是 CC1 和 CC2。系統(tǒng)通道的通道配置是網(wǎng)絡配置 NC4 的一部分。
我們已經(jīng)在概念上構建了一個 Hyperledger Fabric 區(qū)塊鏈網(wǎng)絡實例的最后一部分了。我們創(chuàng)建了一個有四個組織的網(wǎng)絡，帶有兩個通道和三個 Peer 節(jié)點，兩個智能合約和一個排序服務。并由四個證書頒發(fā)機構來支撐。它為三個客戶端應用程序提供了賬本及智能合約服務，這些應用程序可以通過兩個通道與賬本和智能合約進行交互?；ㄐr間來仔細看看這個圖中網(wǎng)絡的詳細內(nèi)容，并且隨時回來閱讀這個部分來加強你的理解，或者查看其它更詳細的話題。
網(wǎng)絡組件的總結
下邊是我們討論過的網(wǎng)絡組件的一個快速總結：
- 賬本。每個通道一個。由 區(qū)塊鏈 和 World state 組成
- 智能合約 (或者叫鏈碼)
- Peer 節(jié)點
- 排序服務
- Channel
- 證書頒發(fā)機構
網(wǎng)絡總結
在本主題中，我們了解了不同的組織如何共享它們的基礎設施來提供一個集成的 Hyperledger Fabric 區(qū)塊鏈網(wǎng)絡。我們看到了如何將集體基礎設施組織成提供獨立管理的私有通信機制的通道。我們也已經(jīng)看到了如何通過使用來自各自證書認證機構的證書來識別來自不同組織的參與者，比如客戶端應用程序、管理員、節(jié)點和排序服務。反過來，我們也看到了策略的重要性，它定義了這些組織參與者在網(wǎng)絡和通道資源上擁有的一致同意的權限。
