使用結構測試網絡
下載Hyperledger Fabric Docker映像和示例后，可以使用fabric-samples存儲庫中提供的腳本來部署測試網絡
。提供測試網絡是為了通過在本地計算機上運行節(jié)點來了解Fabric。開發(fā)人員可以使用網絡來測試其智能合約和應用程序。該網絡只能用作教育和測試的工具，而不能用作建立網絡的模型。通常，不建議對腳本進行修改，否則可能會破壞網絡。它基于有限的配置，不應用作部署生產網絡的模板：
它包括兩個對等組織和一個訂購組織。
為簡單起見，配置了一個單節(jié)點Raft訂購服務。
為了降低復雜性，未部署TLS證書頒發(fā)機構(CA)。所有證書均由根CA頒發(fā)。
該示例網絡使用Docker Compose部署了一個Fabric網絡。由于節(jié)點在Docker
Compose網絡中是隔離的，因此未將測試網絡配置為連接到其他正在運行的Fabric節(jié)點。
要了解如何在生產中使用Fabric，請參閱部署生產網絡。
注意：這些說明已通過驗證，可與提供的tar文件中的最新穩(wěn)定Fabric
Docker映像和預編譯的設置實用程序一起使用。如果使用當前master分支中的圖像或工具運行這些命令，則可能會遇到錯誤。
在你開始之前
在運行測試網絡之前，您需要克隆fabric-samples
存儲庫并下載Fabric映像。確保已安裝前提條件并安裝了示例，二進制文件和Docker映像。
注意：測試網絡已通過Docker Desktop 2.5.0.1版成功驗證，目前是推薦的版本。更高版本可能無法正常工作。
建立測試網絡
您可以test-network在fabric-samples存儲庫目錄中找到用于啟動網絡的腳本。使用以下命令導航到測試網絡目錄：
cd fabric-samples/test-network
在此目錄中，您可以找到帶注釋的腳本，network.sh該腳本使用本地計算機上的Docker映像站立在Fabric網絡上。您可以運行
以打印腳本幫助文本：./network.sh -h
從test-network目錄內部，運行以下命令以從以前的任何運行中刪除任何容器或工件：
./network.sh down
然后，您可以通過發(fā)出以下命令來啟動網絡。如果嘗試從另一個目錄運行腳本，則會遇到問題：
./network.sh up
此命令創(chuàng)建一個結構網絡，該結構網絡由兩個對等節(jié)點(一個訂購節(jié)點)組成。您在運行時不會創(chuàng)建任何渠道，盡管我們將在以后的步驟中實現(xiàn)。如果命令成功完成，您將看到正在創(chuàng)建的節(jié)點的日志：./network.sh
up
測試網絡的組成部分
部署測試網絡后，您可能需要一些時間來檢查其組件。運行以下命令以列出您的計算機上運行的所有Docker容器。您應該看到該network.sh腳本創(chuàng)建的三個節(jié)點：
docker ps -a
與Fabric網絡交互的每個節(jié)點和用戶都必須屬于一個組織才能參與網絡。測試網絡包括兩個對等組織，Org1和Org2。它還包括維護網絡訂購服務的單個訂購者組織。
對等是任何Fabric網絡的基本組成部分。對等方存儲區(qū)塊鏈分類帳并在將交易提交到分類帳之前對其進行驗證。對等方運行包含業(yè)務邏輯的智能合約，該業(yè)務邏輯用于管理區(qū)塊鏈分類賬上的資產。
網絡中的每個對等方都必須屬于一個組織。在測試網絡中，每個組織各自運營一個對等方，peer0.org1.example.com
并且peer0.org2.example.com。
每個Fabric網絡還包括訂購服務。當對等方驗證交易并將交易塊添加到區(qū)塊鏈分類賬中時，他們并不確定交易的順序或將其包括在新的塊中。在分布式網絡上，對等點可能彼此相距很遠，并且對創(chuàng)建事務的時間沒有共同的看法。在交易順序上達成共識是一個代價高昂的過程，這會給對等方造成開銷。
訂購服務允許對等方專注于驗證交易并將其提交到分類賬。在訂購節(jié)點收到客戶認可的交易后，他們就交易順序達成共識，然后將其添加到區(qū)塊中。然后將這些塊分發(fā)到對等節(jié)點，對等節(jié)點將這些塊添加到區(qū)塊鏈分類賬中。
示例網絡使用由訂購者組織操作的單節(jié)點Raft訂購服務。您可以看到正在計算機上運行的訂購節(jié)點orderer.example.com。盡管測試網絡僅使用單個節(jié)點訂購服務，但是生產網絡將具有多個訂購節(jié)點，這些訂購節(jié)點由一個或多個訂購者組織操作。不同的排序節(jié)點將使用Raft共識算法來就網絡上的事務順序達成協(xié)議。
建立頻道
現(xiàn)在，我們的機器上正在運行對等節(jié)點和訂購者節(jié)點，我們可以使用該腳本為Org1和Org2之間的事務創(chuàng)建Fabric通道。通道是特定網絡成員之間的專用通信層。頻道只能由受邀加入該頻道的組織使用，并且對網絡的其他成員不可見。每個通道都有一個單獨的區(qū)塊鏈分類帳。被邀請的組織將其同行“加入”渠道以存儲渠道分類帳并驗證渠道上的交易。
您可以使用network.sh腳本在Org1和Org2之間創(chuàng)建頻道，并將其對等方加入該頻道。運行以下命令以使用默認名稱創(chuàng)建頻道m(xù)ychannel：
./network.sh createChannel
如果命令成功執(zhí)行，則可以在日志中看到以下消息：
========= Channel successfully joined ===========
您也可以使用channel標志創(chuàng)建具有自定義名稱的頻道。例如，以下命令將創(chuàng)建一個名為的通道channel1：
./network.sh createChannel -c channel1
通道標志還允許您通過指定不同的通道名稱來創(chuàng)建多個通道。創(chuàng)建mychannel或后channel1，您可以使用以下命令創(chuàng)建另一個名為的頻道channel2：
./network.sh createChannel -c channel2
如果要一步一步建立網絡并創(chuàng)建頻道，可以將up和createChannel模式一起使用：
./network.sh up createChannel
通道配置(configtx)
筆記
本主題描述了當尚未使用系統(tǒng)通道發(fā)生塊自舉網絡時如何配置通道。有關配置結構(包括系統(tǒng)通道的配置)的信息，請 從v2.2文檔中查看“
通道配置(configtx) ”。
Hyperledger Fabric區(qū)塊鏈網絡的共享配置存儲在一個集合配置事務中，每個通道一個。通常，每個配置事務都使用簡稱
configtx來引用。
通道配置具有以下重要屬性：
1、版本化：配置的所有元素都有一個關聯(lián)的版本，每次修改都會對其進行升級。此外，每個提交的配置都會接收一個序列號。
2、允許的：配置的每個元素都有一個關聯(lián)的策略，該策略控制是否允許對該元素進行修改。擁有先前configtx副本(并且沒有其他信息)的任何人都可以基于這些策略來驗證新配置的有效性。
3、層次結構：根配置組包含子組，層次結構的每個組都有關聯(lián)的值和策略。這些策略可以利用層次結構從較低級別的策略中一級導出策略。
配置剖析
配置作為類型的事務存儲HeaderType_CONFIG 在一個塊中，沒有其他事務。這些塊稱為 配置塊，第一個稱為 Genesis塊。
用于配置的原型結構存儲在中
fabric-protos/common/configtx.proto。類型的信封HeaderType_CONFIG將ConfigEnvelope消息編碼為
Payload data字段。的原型ConfigEnvelope定義如下：
該last_update字段在下面的“更新到配置”部分中定義，但僅在驗證配置而不讀取時才是必需的。而是將當前提交的配置存儲在config包含Config
消息的字段中。
sequence對于每個已提交的配置，該數字將增加一。該channel_group字段是包含配置的根組。該ConfigGroup結構是遞歸定義的，并構建了一個分組樹，每個分組都包含值和策略。它的定義如下：
由于ConfigGroup是遞歸結構，因此具有層次結構。為了簡化Go語法，表達了以下示例。
每個組在配置層次結構中定義一個級別，每個組具有一組關聯(lián)的值(由字符串鍵索引)和策略(也由字符串鍵索引)。
請注意，值，策略和組都有一個version和一個
mod_policy。的version元素的是，元件被修改的每個時間遞增。將mod_policy被用來管理所需的簽名修改該元素。對于組，修改是在“值”，“策略”或“組”映射中添加或刪除元素(或更改mod_policy)。對于“值”和“策略”，修改將分別更改“值”和“策略”字段(或更改
mod_policy)。mod_policy在配置的當前級別的上下文中評估每個元素?？紤]下面定義的示例mod策略Channel.Groups["Application"](此處，我們使用Go
map引用語法，因此 Channel.Groups["Application"].Policies["policy1"]是指基
Channel組的Application組的Policiesmap的 policy1策略。)
policy1 映射到 Channel.Groups["Application"].Policies["policy1"]
Org1/policy2 映射到
Channel.Groups["Application"].Groups["Org1"].Policies["policy2"]
/Channel/policy3 映射到 Channel.Policies["policy3"]
請注意，如果mod_policy引用的策略不存在，則不能修改該項目。
新增功能
更高的私密性：由于以前所有訂購節(jié)點都已加入系統(tǒng)通道，因此網絡中的每個訂購節(jié)點都知道該訂購服務上每個通道的存在?，F(xiàn)在，訂購節(jié)點僅知道其加入的渠道。
可伸縮性：當系統(tǒng)通道上定義了大量的訂購節(jié)點和訂購通道時，訂購節(jié)點要花很長時間才能就所有通道的成員資格達成共識?，F(xiàn)在，訂購服務可以通過將訂購節(jié)點獨立連接到特定渠道，以分散的方式水平擴展。
運營收益
將訂購節(jié)點加入頻道的簡單過程。
能夠列出訂購節(jié)點同意的渠道。
從訂購節(jié)點移除渠道的簡單過程，該過程自動清除與該渠道關聯(lián)的模塊。
對等組織無需與系統(tǒng)通道的管理員協(xié)調即可創(chuàng)建或更新其MSP。
分類帳快照
現(xiàn)在可以對一個對等方的頻道信息(包括其狀態(tài)數據庫)進行快照，并根據快照將新對等方(在同一組織或不同組織中)加入該信道。
使用分類帳快照具有以下優(yōu)點：
自從創(chuàng)世塊以來，對等方不需要處理所有塊：自從創(chuàng)世塊以來，對等方可以在不處理所有先前塊的情況下加入通道，從而大大減少了將對等方加入現(xiàn)有通道所需的時間。
對等方可以使用最新的通道配置加入頻道：由于快照包含最新的頻道配置，因此對等方現(xiàn)在可以使用最新的頻道配置加入頻道。如果自創(chuàng)世以來，關鍵通道配置(例如訂購者端點或TLS
CA證書)已更新，則這一點尤其重要。
降低存儲成本：自從生成塊以來，通過快照加入的對等方不會產生維護所有塊的存儲成本。
狀態(tài)檢查點：對等管理員可以快照當前通道狀態(tài)，并與同一組織或不同組織中的其他對等進行比較，以驗證每個對等上賬本的一致性和完整性。商定的快照可用作新加入對等方的檢查點和基礎。
