【轉載請标明出處】：https://blog.csdn.net/qq_25870633/article/details/81144847
我們接着上一篇文章 【我的區塊鍊之路】- Hyperledger fabric的簡單入門（一）接着講fabric-samples/first-network目錄中來快速啟動我們的第一個fabric網絡；在上篇文章中我們隻是使用了 ./byfn.sh 檔案來把fabric網絡示例跑起來，我們也可以從日志中檢視到 從啟動前的準備工作、怎麼啟動網絡及啟動網絡後如何去安裝鍊碼、執行個體化鍊碼，調用鍊碼等全過程。那麼，今天我們來講解下，這些詳細的步驟并通過手動啟動網絡來實踐下整個過程：
首先，我們在啟動網絡之前需要做一下準備工作，在前一篇文章中我們一筆帶過了說在 fabric-samples/bin目錄中有幾個我們需要的工具 configtxgen 、configtxlator 、cryptogen ；【a】其中 cryptogen 用來生成組織的拓撲結構和相關身份證書生成的檔案都放置到 crypto-config目錄下(沒有的話會自動建立)；【b】configtxgen 用來生成 創世區塊 genesis.block【創世塊 為同道中所有交易的起始塊】及生成通道的交易配置檔案(主要用來建立通道用 xxxchannel.tx) 及各個組織的錨節點的更新配置檔案(如: Org1MspAnchors.tx，生成錨節點配置檔案 需要根據組織來生成 如有N個組織那個需要生成N個，包活後面的更新錨節點配置的操作也是一樣，需要執根據不同的組織來執行N次)；【c】configtxlator 用來解讀配置資訊及動态網正在運作的網絡中添加 新組織；然後下面我們先來說一說 使用 fabric 網絡的整個大體的流程。
fabric網絡使用流程步驟：
以下指令均是需要在配了環境變量 ~/fabric-samples/bin的情況下執行的哦
【一】cryptogen：生成網絡組織及相應的身份證書
進入fabric-samples/first-network目錄中，執行
cryptogen generate --config=./crypto-config.yaml
或者
cryptogen generate --config=./crypto-config.yaml --output ./crypto-config
【其中 --config=./crypto-config.yaml (關于配置檔案的内容我們後續再讨論)為指定使用配置檔案預設會使用目前目錄的 ； --output ./crypto-config 不指定的話會預設在目前檔案夾生成 crypto-config 目錄；裡面生成了 ordererOrganizations 和 peerOrganizations】我們通過 tree 檢視裡面的内容為：
.
├── ordererOrganizations
│ │
│ │ ## Orderer的參考 Peer的講解，因為他們二者差不多的
│ └── example.com
│ ├── ca
│ │ ├── 56d9c0c46acdda38a174a5ba3ffc44726a2c027e16bb22b460413acbcb9b3a90_sk
│ │ └── ca.example.com-cert.pem
│ ├── msp
│ │ ├── admincerts
│ │ │ └── [email protected]
│ │ ├── cacerts
│ │ │ └── ca.example.com-cert.pem
│ │ └── tlscacerts
│ │ └── tlsca.example.com-cert.pem
│ ├── orderers
│ │ └── orderer.example.com
│ │ ├── msp
│ │ │ ├── admincerts
│ │ │ │ └── [email protected]
│ │ │ ├── cacerts
│ │ │ │ └── ca.example.com-cert.pem
│ │ │ ├── keystore
│ │ │ │ └── 2ec1193fe048848eaa8e20666e26c527b791c4fb127d69cae65095bd31b6c80e_sk
│ │ │ ├── signcerts
│ │ │ │ └── orderer.example.com-cert.pem
│ │ │ └── tlscacerts
│ │ │ └── tlsca.example.com-cert.pem
│ │ └── tls
│ │ ├── ca.crt
│ │ ├── server.crt
│ │ └── server.key
│ ├── tlsca
│ │ ├── 2d66be83c519da67bb36b0972256a3b24357fa7f5b3a61f11405bc8b1f4d7c53_sk
│ │ └── tlsca.example.com-cert.pem
│ └── users
│ └── [email protected]
│ ├── msp
│ │ ├── admincerts
│ │ │ └── [email protected]
│ │ ├── cacerts
│ │ │ └── ca.example.com-cert.pem
│ │ ├── keystore
│ │ │ └── a3c1d7e1bc464faf2e3a205cb76ea231bd3ee7010655d3cd31dc6cb78726c4d0_sk
│ │ ├── signcerts
│ │ │ └── [email protected]
│ │ └── tlscacerts
│ │ └── tlsca.example.com-cert.pem
│ └── tls
│ ├── ca.crt
│ ├── client.crt
│ └── client.key
└── peerOrganizations
│
│ ## 組織1的
├── org1.example.com
│ ├── ca ## 存放組織Org1的 【根證書】 和 對應的私鑰檔案，預設采用EC算法，證書為自簽名。組織内的實體将基于該根證書作為證書根。
│ │ ├── 496d6a41ae5f66bf120df3eab3a9d2dc4d268b2ab9a22af891d33d323bbdb5c8_sk
│ │ └── ca.org1.example.com-cert.pem
│ ├── msp ## 存放代表該組織的身份資訊
│ │ ├── admincerts ## 組織管理者的身份驗證證書，被根證書簽名
│ │ │ └── [email protected]
│ │ ├── cacerts ## 組織的根證書，同ca目錄下檔案
│ │ │ └── ca.org1.example.com-cert.pem
│ │ ├── config.yaml
│ │ └── tlscacerts ## 用于TLS的CA憑證，自簽名
│ │ └── tlsca.org1.example.com-cert.pem
│ ├── peers ## 存放屬于該組織的所有Peer節點
│ │ │
│ │ ├── peer0.org1.example.com ## 第一個peer的資訊，包括其msp證書和tls證書兩類
│ │ │ |
│ │ │ ├── msp ## msp相關證書
│ │ │ │ ├── admincerts ## 組織管理者的身份驗證證書。Peer将基于這些證書來認證交易簽署者是否為管理者身份
│ │ │ │ │ └── [email protected]
│ │ │ │ ├── cacerts ## 存放組織的根證書
│ │ │ │ │ └── ca.org1.example.com-cert.pem
│ │ │ │ ├── config.yaml
│ │ │ │ ├── keystore ## 本節點的身份私鑰，用來簽名
│ │ │ │ │ └── 0f0c2e1835086161f6a10c4bb38c2d89b2cee4e1128cee0fcda4433feb6eb6f8_sk
│ │ │ │ ├── signcerts ## 驗證本節點簽名的證書，被組織根證書簽名
│ │ │ │ │ └── peer0.org1.example.com-cert.pem
│ │ │ │ └── tlscacerts ## TLS連接配接用到身份證書，即組織TLS證書
│ │ │ │ └── tlsca.org1.example.com-cert.pem
│ │ │ └── tls ## tls相關證書
│ │ │ ├── ca.crt ## 組織的根證書
│ │ │ ├── server.crt ## 驗證本節點簽名的證書，被組織根證書簽名
│ │ │ └── server.key ## 本節點的身份私鑰，用來簽名
│ │ │
│ │ │
│ │ └── peer1.org1.example.com
│ │
│ │
│ │
│ ├── tlsca ## 存放tls相關的證書和私鑰
│ │ ├── 3d39ea82dd5343c261b0480bc13d645a3cee13b7e7aa8c54fd2b5162f709671f_sk
│ │ └── tlsca.org1.example.com-cert.pem
│ │
│ └── users ## 存放屬于該組織的使用者的實體
│ │
│ ├── [email protected] ## 管理者使用者的資訊，其中包括msp證書和tls證書兩類
│ │ │
│ │ │
│ │ ├── msp ## msp相關證書
│ │ │ |
│ │ │ ├── admincerts ## 組織根證書作為管理者身份驗證證書
│ │ │ │ └── [email protected]
│ │ │ ├── cacerts ## 存放組織的根證書
│ │ │ │ └── ca.org1.example.com-cert.pem
│ │ │ ├── keystore ## 本使用者的身份私鑰，用來簽名
│ │ │ │ └── 2b933c0740d857284be98ff218bf279261e55eff2b89d973e0a1f435f7c7d28b_sk
│ │ │ ├── signcerts ## 管理者使用者的身份驗證證書，被組織根證書簽名。要被某個Peer認可，則必須放到該Peer的msp/admincerts目錄下
│ │ │ │ └── [email protected]
│ │ │ └── tlscacerts ## TLS連接配接用的身份證書，即組織TLS證書
│ │ │ └── tlsca.org1.example.com-cert.pem
│ │ |
│ │ └── tls ## 存放tls相關的證書和私鑰
│ │ ├── ca.crt ## 組織的根證書
│ │ ├── client.crt ## 管理者的使用者身份驗證證書，被組織根證書簽名
│ │ └── client.key ## 管理者使用者的身份私鑰，被組織根證書簽名
│ │
│ └── [email protected] ## 第一個使用者的資訊，包括msp證書和tls證書兩類
│ │
│ ├── msp ## msp證書相關資訊
│ │ ├── admincerts ## 組織根證書作為管理者身份驗證證書
│ │ │ └── [email protected]
│ │ ├── cacerts ## 存放組織的根證書
│ │ │ └── ca.org1.example.com-cert.pem
│ │ ├── keystore ## 本使用者的身份私鑰，用來簽名
│ │ │ └── 11ebc5afac42348f84a8882f329d18beee079efd4fd5d9b30389dc82053fc0c9_sk
│ │ ├── signcerts ## 驗證本使用者簽名的身份證書，被組織根證書簽名
│ │ │ └── [email protected]
│ │ └── tlscacerts ## TLS連接配接用的身份證書，被組織根證書簽名
│ │ └── tlsca.org1.example.com-cert.pem
│ └── tls ## tls的根證書
│ ├── ca.crt ## 組織的根證書
│ ├── client.crt ## 驗證使用者簽名的身份證書，被根組織證書簽名
│ └── client.key ## 使用者的身份私鑰用來簽名
└── org2.example.com
好了現在相應的組織結構及結構下的相應的身份證書都已經依照相應的目錄生成存放好了。
身份的各種證書檔案，一般包括：
- admincerts ：管理者的身份證書檔案
- cacerts ：信任的根證書檔案
- key store ：節點的簽名私鑰檔案
- signcerts ：節點的簽名身份證書檔案
- tlscacerts: TLS 連接配接用的證書
- intermediatecerts （可選）：信任的中間證書
- crls （可選）：證書撤銷清單
- config.yaml （可選）：記錄OrganizationalUnitldentifiers 資訊，包括根證書位置和ID資訊
這些身份檔案随後可以分發到對應的Orderer 節點和Peer 節點上，并放到對應的MSP路徑下，用于簽名使用
【二】configtxgen：生成Orderer的創世塊、生成通道的配置交易檔案、生成各個組織的錨節點配置更新檔案
【生成Orderer的創世塊】
configtxgen -profile TwoOrgsOrdererGenesis -outputBlock ./channel-artifacts/genesis.block
或者
## 先配置臨時環境變量 FABRIC_CFG_PATH 來制定 config.yaml的路徑
export FABRIC_CFG_PATH=$PWD/first-network 【因為我是在 first-network的上一級目錄配置的】
configtxgen -profile TwoOrgsOrdererGenesis -outputBlock ./channel-artifacts/genesis.block
或者
configtxgen -profile TwoOrgsOrdererGenesis -outputBlock ./first-network/channel-artifacts/mygenesis.block --configPath /home/gavin/fabric/fabric-samples/first-network/
【注意：--configPath 為可選項，用來指定使用的 config.yaml 檔案；其中 configtxgen 預設需要用到目前目錄下的 config.yaml 配置檔案(關于配置檔案的内容我們後續在讨論)，且指令行中的 TwoOrgsOrdererGenesis 是讀取了config.yaml 檔案中的 Profiles 部分中定義的配置内容】，正常執行完成後我們會在指令的指定輸出目錄(這裡是指令中指定的 channel-artifacts目錄)看到genesis.block 創世塊，我們可以通過 configtxgen --inspectBlock ./genesis.block 來使用json的形式把 創世塊的内容列印出來
【生成通道的配置交易檔案】
export CHANNEL_NAME=mychannel ## 最好是先配置個臨時的環境變量友善後面引用，當然後面選擇手打也是可以的
configtxgen -profile TwoOrgsChannel -outputCreateChannelTx ./channel-artifacts/channel.tx -channelID $CHANNEL_NAME
【可選項和上面生成創世塊一緻，貌似不指定 channelID 預設就是 mychannel ？？ 】然後我們可以在指定的目錄下(這裡是 /home/gavin/fabric/fabric-samples/first-network/channel-artifacts 檢視到 channel.tx )同樣也有檢視交易檔案的方式：
configtxgen --inspectChannelCreateTx ./channel.tx 和檢視創世塊内容一樣隻是指令選項不一樣 具體可以 --help 去檢視，我們可以以json的形式列印到控制台
【生成各個組織的錨節點配置更新檔案】
【注意】：生成組織的錨節點配置更新檔案的時候，我們需要注意的是美哥組織都需要分别取生成對應的錨節點，詳細是哪個為錨節點請檢視 config.yaml 中自然清楚了；如我們的 config.yaml 中有這一段指定了每個組織的錨節點，
則，我們需要分别執行如下指令：【注意：生成組織錨節點所用的 profile選項值 和 生成 通道配置交易檔案所用的一樣哦~】
configtxgen -profile TwoOrgsChannel -outputAnchorPeersUpdate ./channel-artifacts/Org1MSPanchors.tx -channelID $CHANNEL_NAME -asOrg Org1MSP
以及
configtxgen -profile TwoOrgsChannel -outputAnchorPeersUpdate ./channel-artifacts/Org2MSPanchors.tx -channelID $CHANNEL_NAME -asOrg Org2MSP
【其中，-asOrg 所攜帶的值 Org1MSP 等是 上圖中所示的 org的ID 的值】執行完後我們可以在 ~/fabric-samples/first-network/channel-artifacts 目錄産看到兩個檔案 Org1MSPanchors.tx 和 Org2MSPanchors.tx 這就是我們需要的兩個組織各自的錨節點配置更新檔案了
OK，到目前為止我們在啟動網絡前的所有準備工作都已經做完了，下面我們就來把網絡啟動起來 【本操作是屬于 單機版的示範，現實生産環境啟動網絡可以使 逐個去不同伺服器上啟動的哦~】
【三】啟動fabric網絡：使用 docker-compose 來批量啟動網絡
【注意】：我們本示例中啟動網絡是使用了docker-compose 來直接啟動網絡架構中所有的資源，這裡使用的底層原理是：通過指定的 docker-compose.yaml 來對之前我們下好的Orderer、Peer等鏡像及 我們生成好的組織結構及對應的身份證書、配置檔案等來搭建我們的fabric網絡，具體做了些什麼需要檢視 所指定的docker-compose.yaml 中配置了些什麼。(docker-compose.yaml 我們後續再講解)，現在我們隻需要用一下指令即可啟動這個我們配置好的網絡
docker-compose -f docker-compose-cli.yaml up -d 【注意： -d 是可選項，加了的話就不會列印詳細的啟動過程日志，個人建議不要加】
這隻是開始的一小部分日志，往下我們還可以看到不同節點的啟動過程日志，比如：
最後是：
啟動完之後我們可以使用 docker logs -f 容器ID/容器名稱 來檢視各個容器的啟動控制台日志，看看是否正常啟動了容器 【注意 這時候還是無法確定 目前節點是否 沒有問題的哦~】
首先我們先 docker ps 檢視下起了幾個容器：
我們可以看到一共起了 一個Order 、4個peer、一個cli 共6個容器，我們不放心的話可以逐一的進入容器中【使用 docker logs -f 容器ID/容器名稱 】檢視啟動日志~
有一點需要注意的是，
CLI容器将閑置1000秒。如果在需要時它消失了，可以用一個簡單的指令重新啟動它：
docker start cli
【四】建立應用通道：使用 cli 建立應用通道
Peer節點啟動後, 預設情況下沒有加入網絡中的任何應用通道, 也不會與Orderer服務建立連接配接.需要通過用戶端對其進行操作, 讓它加入網絡和指定的應用通道中
我們進入cli容器來操作下面所有動作【嚴格來說後續的操作均是需要cli來和各個節點進行互動，主要是Peer節點】
docker exec -ti cli bash
或者
docker exec -ti cli /bin/bash 【本人更傾向這種】
l
為了以防萬一，我們優先檢查下臨時環境變量是否配置了 【剛進去cli容器中是沒有這個變量的】
echo $CHANNEL_NAME 沒有設定的話需要設定 export CHANNEL_NAME=mychannel
進去之後直接在 cli 容器的這個目錄下： /opt/gopath/src/github.com/hyperledger/fabric/peer ，然後我們可以看到
l
裡面有三個目錄 channel-artifacts 中放置的是我們準備工作中生成的 配置檔案 (創世塊、通道配置交易檔案 等)、crypto 中放置着生成的組織結構及對應的身份證書、scripts 中是某些啟動腳本；
【建立通道】：
peer channel create -o orderer.example.com:7050 -c $CHANNEL_NAME -f ./channel-artifacts/channel.tx --tls --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem ## --cafile 攜帶的是 orderer 的root cert的本地路徑，允許我們去驗證TLS握手
在執行完後會在目前目錄下 有一個 通道名.block 的檔案【本例子中為：mychannel.block】
【注意了 這個檔案在 peer加入通道後，或者 cli 停止運作/重新開機 後 就不見了，因為他是在cli 容器裡面生成的，生命伴随着 cli 容器，而 其他三個目錄的内容時從外部Linux 挂載進來的，不一樣~，但是我們可以使用 peer channel fetch 來從正在運作的網絡中 捕獲最新的 xxxchannel.block 檔案】
【五】加入通道：使用 cli 依次更換指向環境，逐個把peer加入到指定同道中
peer channel join -b mychannel.block
【注意：目前 cli 預設就是 Org1的 peer0 請檢視 docker-compose-cli.yaml 中的配置自然明白】
切換身份（其實還是在 cli 中，隻不過會以 指定的組織下的身份去 操作該組織下的資源 ，因為是由 cli 來和各個peer 等做互動的，我們可以把 cli 認為是個跳闆機 ），去把其他的節點也加入 通道中：
CORE_PEER_LOCALMSPID="Org2MSP" ## 指定組織
CORE_PEER_ADDRESS=peer0.org2.example.com:7051 ## 指定資源的 服務位址
CORE_PEER_MSPCONFIGPATH=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org2.example.com/users/[email protected]/msp ## 指定 資源的管理者身份資訊
CORE_PEER_TLS_ROOTCERT_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org2.example.com/peers/peer0.org2.example.com/tls/ca.crt ## 指定 該組織的該資源 tls根證書
【這裡有個小技巧，想要知道 cli 容器目前所指的 身份環境是誰，我們可以】
echo $CORE_PEER_LOCALMSPID ## 檢視 目前的組織
echo $CORE_PEER_ADDRESS ## 檢視 目前peer的服務位址
echo $CORE_PEER_MSPCONFIGPATH ## 檢視 目前資源的管理者MSP 身份資訊
echo $CORE_PEER_TLS_ROOTCERT_FILE ## 檢視 目前資源的TLS根證書
如我們預設 docker-compose-cli.yaml 中配置了 org1的 peer0 作為 cli 容器的預設指向環境，那麼我們第一次進入 cli 就依次執行上述 指令得到：
好，我們現在先切換 cli 的環境指向到 org0 的 peer1 【由于相同組織 則，組織和 管理者身份不需要切換，隻有資源服務位址 和 資源的 tls根證書 需要切換】
CORE_PEER_ADDRESS=peer1.org1.example.com:7051
CORE_PEER_TLS_ROOTCERT_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/peers/peer1.org1.example.com/tls/ca.crt
如下: 【注意 每一次新開進入的 cli 的終端 都是預設指向 org1 的 peer0 環境的哦】
OK，我們隻需要依次更換cli 指向的環境，并逐個把對應的peer 加入通道中即可
【六】更新組織錨節點：使用 cli 依次更換指向環境，逐個把peer加入到指定同道中
同樣我們需要依次更換 環境身份逐個去對應組織的對應peer上把它更新為 該組織的錨節點
如：【注意 錨節點必須是 之前config.yaml 中所指定的哦】
peer channel update -o orderer.example.com:7050 -c ${CHANNEL_NAME} -f ./channel-artifacts/Org1MSPanchors.tx --tls --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem
到這裡為止我們整個 fabric 網絡結構就算搭建起來了，那麼下面我們就可以使用它來跑我們的鍊碼了。
【七】安裝鍊碼：使用 cli 依次更換指向環境，把ChainCode安裝到指定的Peer節點中
【注意了，我們這裡隻是把ChainCode安裝到指定的 Peer 上哦 (感覺是隻需要背書節點安裝即可)，我沒有說 所有的Peer都需要安裝ChainCode】
如： 我們隻在Org1 的 Peer0 上安裝了鍊碼：
peer chaincode install -n mycc -v 1.0 -p \
github.com/chaincode/chaincode_example02/go/
【注意：鍊碼的起始 目錄為 GOPATH 的src 中的 項目目錄，我們這裡就是 github.com 目錄】
這樣紙就是鍊碼安裝成功了
【八】執行個體化鍊碼：使用 cli 随便一個已安裝有該鍊碼環境，把已經安裝的ChainCode 進行執行個體化
peer chaincode instantiate -o orderer.example.com:7050 --tls --cafile \
/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem \
-C $CHANNEL_NAME -n mycc -v 1.0 -c '{"Args":["init","a", "100", "b","200"]}' -P "OR ('Org1MSP.member','Org2MSP.member')"
【注意：我們必須在安裝有鍊碼的節點去執行個體化鍊碼，不然的話會失敗；其中鍊碼是嚴格區分名稱和版本号的，這個要和安裝的時候一緻；其中 -P 後面跟的是 指定調用鍊碼時的 背書政策 其實Peer的 Endorser 節點也就是在 執行個體化鍊碼時 通過背書政策 來指定的，上述背書政策表示，該鍊碼需要Org1 或者Org2 的随意成員簽名的交易均可調用該鍊碼，如果把 member 改成peer 那麼就是 随意peer 簽名】
安裝成功如下:
其中，在沒有安裝鍊碼的節點上執行執行個體化而失敗的結果，如：
【九】測試鍊碼：使用 cli 随便一個相同通道的節點，測試調用鍊碼
查詢：
peer chaincode query -C $CHANNEL_NAME -n mycc -c '{"Args": ["query","a"]}'
執行事務：
peer chaincode invoke -o orderer.example.com:7050 --tls --cafile \
/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem \
-C $CHANNEL_NAME -n mycc -c '{"Args":["invoke","a","b","10"]}'
查詢：
peer chaincode query -C $CHANNEL_NAME -n mycc -c '{"Args": ["query","a"]}'
【注意】：這裡需要說一下，鍊碼的執行原理，我們之前隻在 org1 的 peer0 上安裝并且執行個體化了鍊碼之後，然後來到 其他三個節點 做鍊碼 Query 發現提示錯誤資訊
再做 事務操作，提示：
那麼這是什麼回事呢？這個會涉及到這個 transaction flow (交易流程) 了，因為peer會在用戶端把交易proposal送出過來的時候本地啟動一個鍊碼容器模拟交易過程且簽名結果傳回給用戶端的，是以本地沒有鍊碼怎麼行呢？在這裡我們隻需要記得，隻能在已安裝了鍊碼的節點執行個體化鍊碼且相同名稱相同版本的鍊碼隻需要執行個體化一次即可，然後其他節點可以在本次執行個體化之前或者之後 安裝相同的鍊碼都沒有問題，且調用鍊碼隻能是在安裝了鍊碼的節點調用；是以，後面到org1的peer1和org2的peer1上面各自安裝了鍊碼，這時候調用成功(當然在 org2的peer0上面是不能調用生成的)
好了，手動執行一個簡單的fabric網絡及鍊碼的調用全過程這裡就結束了，今天下午我也懶得再寫了，後續我們繼續深入，其他的一些操作，比如： 往正在運作的網絡中添加 新的組織，添加新的通道等等，Bye~