構建你的第一個網路（Building Your First Network）

These instructions have been verified to work against the latest stable Docker images and the pre-compiled setup utilities within the supplied tar file. If you run these commands with images or tools from the current master branch, it is possible that you will see configuration and panic errors.

The build your first network (BYFN) scenario provisions a sample Hyperledger Fabric network consisting of two organizations, each maintaining two peer nodes, and a “solo” ordering service. 構建你的第一個網路（BYFN）方案提供了一個示例Hyperledger Fabric網路，該網路由兩個組織組成，每個組織維護兩個對等節點，以及一個“單一”排序服務。

安裝先決條件（Install prerequisites）

Before we begin, if you haven’t already done so, you may wish to check that you have all the Prerequisites installed on the platform(s) on which you’ll be developing blockchain applications and/or operating Hyperledger Fabric. 在我們開始之前，如果你還沒有這樣做，你可能希望檢查是否已安裝所有先決條件 在你將開發區塊鏈應用程式和/或執行Hyperledger Fabric的平臺上。

You will also need to Install Samples, Binaries and Docker Images. You will notice that there are a number of samples included in the fabric-samples repository. We will be using the first-network sample. Let’s open that sub-directory now. 你還需要安裝樣本，二進位制檔案和Docker映象。 你會注意到fabric-samples儲存庫中包含了許多樣本。 我們將使用first-network樣本。 我們現在開啟那個子目錄。

cd fabric-samples/first-network

The supplied commands in this documentation MUST be run from your first-network sub-directory of the fabric-samples repository clone. If you elect to run the commands from a different location, the various provided scripts will be unable to find the binaries. 本文件中提供的命令必須從fabric-samples儲存庫克隆的first-network子目錄執行。 如果你選擇從其他位置執行命令，則各種提供的指令碼將無法找到二進位制檔案。

想要現在執行嗎（Want to run it now）?

We provide a fully annotated script - byfn.sh - that leverages these Docker images to quickly bootstrap a Hyperledger Fabric network comprised of 4 peers representing two different organizations, and an orderer node. It will also launch a container to run a scripted execution that will join peers to a channel, deploy and instantiate chaincode and drive execution of transactions against the deployed chaincode. 我們提供了一個完全註釋的指令碼 - byfn.sh - 它利用這些Docker映象快速引導Hyperledger Fabric網路，該網路由代表兩個不同組織的4個對等節點和一個排序節點組成。 它還將啟動一個容器來執行指令碼執行，該執行將對等節點連線到一個通道，部署和例項化鏈程式碼並根據部署的鏈程式碼驅動交易執行。

Here’s the help text for the byfn.sh script: 這是byfn.sh指令碼的幫助文字：

Usage:
  byfn.sh <mode> [-c <channel name>] [-t <timeout>] [-d <delay>] [-f <docker-compose-file>] [-s <dbtype>] [-l <language>] [-i <imagetag>] [-v]
    <mode> - one of 'up', 'down', 'restart', 'generate' or 'upgrade'
      - 'up' - bring up the network with docker-compose up
      - 'down' - clear the network with docker-compose down
      - 'restart' - restart the network
      - 'generate' - generate required certificates and genesis block
      - 'upgrade'  - upgrade the network from v1.0.x to v1.1
    -c <channel name> - channel name to use (defaults to "mychannel")
    -t <timeout> - CLI timeout duration in seconds (defaults to 10)
    -d <delay> - delay duration in seconds (defaults to 3)
    -f <docker-compose-file> - specify which docker-compose file use (defaults to docker-compose-cli.yaml)
    -s <dbtype> - the database backend to use: goleveldb (default) or couchdb
    -l <language> - the chaincode language: golang (default), node or java
    -i <imagetag> - the tag to be used to launch the network (defaults to "latest")
    -v - verbose mode
  byfn.sh -h (print this message)

Typically, one would first generate the required certificates and
genesis block, then bring up the network. e.g.:

        byfn.sh generate -c mychannel
        byfn.sh up -c mychannel -s couchdb
        byfn.sh up -c mychannel -s couchdb -i 1.1.0-alpha
        byfn.sh up -l node
        byfn.sh down -c mychannel
        byfn.sh upgrade -c mychannel

Taking all defaults:
        byfn.sh generate
        byfn.sh up
        byfn.sh down

If you choose not to supply a channel name, then the script will use a default name of mychannel. The CLI timeout parameter (specified with the -t flag) is an optional value; if you choose not to set it, then the CLI will give up on query requests made after the default setting of 10 seconds. 如果你選擇不提供通道名稱，則指令碼將使用預設名稱“mychannel”。 CLI超時引數（使用-t標誌指定）是可選值; 如果你選擇不設定它，那麼CLI將在預設設定的10秒後放棄查詢請求。

生成網路工件（Generate Network Artifacts）

Ready to give it a go? Okay then! Execute the following command: 準備好了嗎？ 好吧！ 執行以下命令：

./byfn.sh generate

You will see a brief description as to what will occur, along with a yes/no command line prompt. Respond with a y or hit the return key to execute the described action. 你將看到有關將發生什麼的簡要說明，以及是/否命令列提示。 用y回答或按回車鍵執行描述的動作。

appletekiMacBook-Pro:first-network apple$ ./byfn.sh generate
Generating certs and genesis block for channel 'mychannel' with CLI timeout of '10' seconds and CLI delay of '3' seconds
Continue? [Y/n] y
proceeding ...
/Users/apple/go/src/github.com/hyperledger/fabric-samples/first-network/../bin/cryptogen

##########################################################
##### Generate certificates using cryptogen tool #########
##########################################################
+ cryptogen generate --config=./crypto-config.yaml
org1.example.com
org2.example.com
+ res=0
+ set +x

/Users/apple/go/src/github.com/hyperledger/fabric-samples/first-network/../bin/configtxgen
##########################################################
#########  Generating Orderer Genesis block ##############
##########################################################
+ configtxgen -profile TwoOrgsOrdererGenesis -outputBlock ./channel-artifacts/genesis.block
2018-10-19 16:09:22.434 CST [common/tools/configtxgen] main -> WARN 001 Omitting the channel ID for configtxgen for output operations is deprecated.  Explicitly passing the channel ID will be required in the future, defaulting to 'testchainid'.
2018-10-19 16:09:22.437 CST [common/tools/configtxgen] main -> INFO 002 Loading configuration
2018-10-19 16:09:22.496 CST [common/tools/configtxgen] doOutputBlock -> INFO 003 Generating genesis block
2018-10-19 16:09:22.498 CST [common/tools/configtxgen] doOutputBlock -> INFO 004 Writing genesis block
+ res=0
+ set +x

#################################################################
### Generating channel configuration transaction 'channel.tx' ###
#################################################################
+ configtxgen -profile TwoOrgsChannel -outputCreateChannelTx ./channel-artifacts/channel.tx -channelID mychannel
2018-10-19 16:09:22.576 CST [common/tools/configtxgen] main -> INFO 001 Loading configuration
2018-10-19 16:09:22.622 CST [common/tools/configtxgen] doOutputChannelCreateTx -> INFO 002 Generating new channel configtx
2018-10-19 16:09:22.628 CST [common/tools/configtxgen] doOutputChannelCreateTx -> INFO 003 Writing new channel tx
+ res=0
+ set +x

#################################################################
#######    Generating anchor peer update for Org1MSP   ##########
#################################################################
+ configtxgen -profile TwoOrgsChannel -outputAnchorPeersUpdate ./channel-artifacts/Org1MSPanchors.tx -channelID mychannel -asOrg Org1MSP
2018-10-19 16:09:22.703 CST [common/tools/configtxgen] main -> INFO 001 Loading configuration
2018-10-19 16:09:22.736 CST [common/tools/configtxgen] doOutputAnchorPeersUpdate -> INFO 002 Generating anchor peer update
2018-10-19 16:09:22.736 CST [common/tools/configtxgen] doOutputAnchorPeersUpdate -> INFO 003 Writing anchor peer update
+ res=0
+ set +x

#################################################################
#######    Generating anchor peer update for Org2MSP   ##########
#################################################################
+ configtxgen -profile TwoOrgsChannel -outputAnchorPeersUpdate ./channel-artifacts/Org2MSPanchors.tx -channelID mychannel -asOrg Org2MSP
2018-10-19 16:09:22.801 CST [common/tools/configtxgen] main -> INFO 001 Loading configuration
2018-10-19 16:09:22.844 CST [common/tools/configtxgen] doOutputAnchorPeersUpdate -> INFO 002 Generating anchor peer update
2018-10-19 16:09:22.844 CST [common/tools/configtxgen] doOutputAnchorPeersUpdate -> INFO 003 Writing anchor peer update
+ res=0
+ set +x

This first step generates all of the certificates and keys for our various network entities, the genesis block used to bootstrap the ordering service, and a collection of configuration transactions required to configure a Channel. 第一步為我們的各種網路實體生成所有證書和金鑰，用於引導排序服務的genesis block，以及配置[通道](https：// hyperledger-fabric。readthedocs.io/en/release-1.3/glossary.html#channel)所需的一組配置交易。

啟動網路（Bring Up the Network）

(後面準備執行node鏈程式碼，會報錯，把所有.sh檔案中 -v 1.0 改為 -v 1.3，3:-1.0改為3:-1.3，就能正常執行)

Next, you can bring the network up with one of the following commands: 接下來，你可以使用以下命令之一啟動網路：

./byfn.sh up

The above command will compile Golang chaincode images and spin up the corresponding containers. Go is the default chaincode language, however there is also support for Node.js and Java chaincode. If you’d like to run through this tutorial with node chaincode, pass the following command instead: 上面的命令將編譯Golang鏈程式碼映象並加速相應的容器。 Go是預設的鏈程式碼語言，但也支援Node.js和Java 鏈程式碼。 如果你想通過node鏈程式碼執行本教程，請改為使用以下命令：

# we use the -l flag to specify the chaincode language
# forgoing the -l flag will default to Golang

./byfn.sh up -l node

For more information on the Node.js shim, please refer to its documentation. 有關Node.js shim的更多資訊，請參閱其文件。

For more information on the Java shim, please refer to its documentation. 有關Java shim的更多資訊，請參閱其文件。

Тo make the sample run with Java chaincode, you have to specify -l java as follows: 如果使用Java鏈程式碼執行示例，則必須指定-l java，如下所示：

./byfn.sh up -l java

Do not run both of these commands. Only one language can be tried unless you bring down and recreate the network between. 不要同時執行這兩個命令。 除非你關閉並重新建立網路，否則只能嘗試一種語言。

Once again, you will be prompted as to whether you wish to continue or abort. Respond with a y or hit the return key: 再次，系統將提示你是繼續還是中止。 回答y或點選回車鍵：

appletekiMacBook-Pro:first-network apple$ ./byfn.sh up -l node
Starting for channel 'mychannel' with CLI timeout of '10' seconds and CLI delay of '3' seconds
Continue? [Y/n] y
proceeding ...
LOCAL_VERSION=1.3.0
DOCKER_IMAGE_VERSION=1.3.0
Creating network "net_byfn" with the default driver
Creating volume "net_orderer.example.com" with default driver
Creating volume "net_peer0.org1.example.com" with default driver
Creating volume "net_peer1.org1.example.com" with default driver
Creating volume "net_peer0.org2.example.com" with default driver
Creating volume "net_peer1.org2.example.com" with default driver
Creating peer1.org2.example.com ... done
Creating peer0.org2.example.com ... done
Creating peer1.org1.example.com ... done
Creating peer0.org1.example.com ... done
Creating orderer.example.com    ... done
Creating cli                    ... done

 ____    _____      _      ____    _____ 
/ ___|  |_   _|    / \    |  _ \  |_   _|
\___ \    | |     / _ \   | |_) |   | |  
 ___) |   | |    / ___ \  |  _ <    | |  
|____/    |_|   /_/   \_\ |_| \_\   |_|  

Build your first network (BYFN) end-to-end test

Channel name : mychannel
Creating channel...
+ peer channel create -o orderer.example.com:7050 -c mychannel -f ./channel-artifacts/channel.tx --tls true --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem
+ res=0
+ set +x
2018-10-19 08:09:39.675 UTC [channelCmd] InitCmdFactory -> INFO 001 Endorser and orderer connections initialized
2018-10-19 08:09:39.730 UTC [cli/common] readBlock -> INFO 002 Received block: 0
===================== Channel 'mychannel' created ===================== 

Having all peers join the channel...
+ peer channel join -b mychannel.block
+ res=0
+ set +x
2018-10-19 08:09:39.863 UTC [channelCmd] InitCmdFactory -> INFO 001 Endorser and orderer connections initialized
2018-10-19 08:09:39.911 UTC [channelCmd] executeJoin -> INFO 002 Successfully submitted proposal to join channel
===================== peer0.org1 joined channel 'mychannel' ===================== 

+ peer channel join -b mychannel.block
+ res=0
+ set +x
2018-10-19 08:09:43.052 UTC [channelCmd] InitCmdFactory -> INFO 001 Endorser and orderer connections initialized
2018-10-19 08:09:43.096 UTC [channelCmd] executeJoin -> INFO 002 Successfully submitted proposal to join channel
===================== peer1.org1 joined channel 'mychannel' ===================== 

+ peer channel join -b mychannel.block
+ res=0
+ set +x
2018-10-19 08:09:46.237 UTC [channelCmd] InitCmdFactory -> INFO 001 Endorser and orderer connections initialized
2018-10-19 08:09:46.292 UTC [channelCmd] executeJoin -> INFO 002 Successfully submitted proposal to join channel
===================== peer0.org2 joined channel 'mychannel' ===================== 

+ peer channel join -b mychannel.block
+ res=0
+ set +x
2018-10-19 08:09:49.437 UTC [channelCmd] InitCmdFactory -> INFO 001 Endorser and orderer connections initialized
2018-10-19 08:09:49.484 UTC [channelCmd] executeJoin -> INFO 002 Successfully submitted proposal to join channel
===================== peer1.org2 joined channel 'mychannel' ===================== 

Updating anchor peers for org1...
+ peer channel update -o orderer.example.com:7050 -c mychannel -f ./channel-artifacts/Org1MSPanchors.tx --tls true --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem
+ res=0
+ set +x
2018-10-19 08:09:52.629 UTC [channelCmd] InitCmdFactory -> INFO 001 Endorser and orderer connections initialized
2018-10-19 08:09:52.658 UTC [channelCmd] update -> INFO 002 Successfully submitted channel update
===================== Anchor peers updated for org 'Org1MSP' on channel 'mychannel' ===================== 

Updating anchor peers for org2...
+ peer channel update -o orderer.example.com:7050 -c mychannel -f ./channel-artifacts/Org2MSPanchors.tx --tls true --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem
+ res=0
+ set +x
2018-10-19 08:09:55.781 UTC [channelCmd] InitCmdFactory -> INFO 001 Endorser and orderer connections initialized
2018-10-19 08:09:55.809 UTC [channelCmd] update -> INFO 002 Successfully submitted channel update
===================== Anchor peers updated for org 'Org2MSP' on channel 'mychannel' ===================== 

Installing chaincode on peer0.org1...
+ peer chaincode install -n mycc -v 1.3 -l node -p /opt/gopath/src/github.com/chaincode/chaincode_example02/node/
+ res=0
+ set +x
2018-10-19 08:09:58.970 UTC [chaincodeCmd] checkChaincodeCmdParams -> INFO 001 Using default escc
2018-10-19 08:09:58.970 UTC [chaincodeCmd] checkChaincodeCmdParams -> INFO 002 Using default vscc
2018-10-19 08:09:58.986 UTC [chaincodeCmd] install -> INFO 003 Installed remotely response:<status:200 payload:"OK" > 
===================== Chaincode is installed on peer0.org1 ===================== 

Install chaincode on peer0.org2...
+ peer chaincode install -n mycc -v 1.3 -l node -p /opt/gopath/src/github.com/chaincode/chaincode_example02/node/
+ res=0
+ set +x
2018-10-19 08:09:59.145 UTC [chaincodeCmd] checkChaincodeCmdParams -> INFO 001 Using default escc
2018-10-19 08:09:59.145 UTC [chaincodeCmd] checkChaincodeCmdParams -> INFO 002 Using default vscc
2018-10-19 08:09:59.159 UTC [chaincodeCmd] install -> INFO 003 Installed remotely response:<status:200 payload:"OK" > 
===================== Chaincode is installed on peer0.org2 ===================== 

Instantiating chaincode on peer0.org2...
+ peer chaincode instantiate -o orderer.example.com:7050 --tls true --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 mychannel -n mycc -l node -v 1.3 -c '{"Args":["init","a","100","b","200"]}' -P 'AND ('\''Org1MSP.peer'\'','\''Org2MSP.peer'\'')'
+ res=0
+ set +x
2018-10-19 08:09:59.309 UTC [chaincodeCmd] checkChaincodeCmdParams -> INFO 001 Using default escc
2018-10-19 08:09:59.310 UTC [chaincodeCmd] checkChaincodeCmdParams -> INFO 002 Using default vscc
===================== Chaincode is instantiated on peer0.org2 on channel 'mychannel' ===================== 

Querying chaincode on peer0.org1...
===================== Querying on peer0.org1 on channel 'mychannel'... ===================== 
+ peer chaincode query -C mychannel -n mycc -c '{"Args":["query","a"]}'
Attempting to Query peer0.org1 ...3 secs
+ res=0
+ set +x

100
===================== Query successful on peer0.org1 on channel 'mychannel' ===================== 
Sending invoke transaction on peer0.org1 peer0.org2...
+ peer chaincode invoke -o orderer.example.com:7050 --tls true --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 mychannel -n mycc --peerAddresses peer0.org1.example.com:7051 --tlsRootCertFiles /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/ca.crt --peerAddresses peer0.org2.example.com:7051 --tlsRootCertFiles /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org2.example.com/peers/peer0.org2.example.com/tls/ca.crt -c '{"Args":["invoke","a","b","10"]}'
+ res=0
+ set +x
2018-10-19 08:11:41.470 UTC [chaincodeCmd] chaincodeInvokeOrQuery -> INFO 001 Chaincode invoke successful. result: status:200 
===================== Invoke transaction successful on peer0.org1 peer0.org2 on channel 'mychannel' ===================== 

Installing chaincode on peer1.org2...
+ peer chaincode install -n mycc -v 1.3 -l node -p /opt/gopath/src/github.com/chaincode/chaincode_example02/node/
+ res=0
+ set +x
2018-10-19 08:11:41.622 UTC [chaincodeCmd] checkChaincodeCmdParams -> INFO 001 Using default escc
2018-10-19 08:11:41.622 UTC [chaincodeCmd] checkChaincodeCmdParams -> INFO 002 Using default vscc
2018-10-19 08:11:41.642 UTC [chaincodeCmd] install -> INFO 003 Installed remotely response:<status:200 payload:"OK" > 
===================== Chaincode is installed on peer1.org2 ===================== 

Querying chaincode on peer1.org2...
===================== Querying on peer1.org2 on channel 'mychannel'... ===================== 
Attempting to Query peer1.org2 ...3 secs
+ peer chaincode query -C mychannel -n mycc -c '{"Args":["query","a"]}'
+ res=0
+ set +x

90
===================== Query successful on peer1.org2 on channel 'mychannel' ===================== 

========= All GOOD, BYFN execution completed =========== 


 _____   _   _   ____   
| ____| | \ | | |  _ \  
|  _|   |  \| | | | | | 
| |___  | |\  | | |_| | 
|_____| |_| \_| |____/  

You can scroll through these logs to see the various transactions. If you don’t get this result, then jump down to the Troubleshooting section and let’s see whether we can help you discover what went wrong. 你可以滾動瀏覽這些日誌以檢視各種事務。 如果你沒有得到這個結果，那麼跳到故障排除部分，讓我們看看我們是否可以幫助你發現問題。

關閉網路（Bring Down the Network）

Finally, let’s bring it all down so we can explore the network setup one step at a time. The following will kill your containers, remove the crypto material and four artifacts, and delete the chaincode images from your Docker Registry: 最後，讓我們把它全部放下，這樣我們就可以一步一步地探索網路設定。 以下內容將終止你的容器，刪除加密材料和四個檔案，並從Docker Registry中刪除鏈程式碼映象：

./byfn.sh down

Once again, you will be prompted to continue, respond with a y or hit the return key: 再一次，系統將提示你繼續，以y回覆或點選回車鍵：

appletekiMacBook-Pro:first-network apple$ ./byfn.sh down
Stopping for channel 'mychannel' with CLI timeout of '10' seconds and CLI delay of '3' seconds
Continue? [Y/n] y
proceeding ...
Stopping cli                    ... done
Stopping orderer.example.com    ... done
Stopping peer0.org2.example.com ... done
Stopping peer0.org1.example.com ... done
Stopping peer1.org1.example.com ... done
Stopping peer1.org2.example.com ... done
Removing cli                    ... done
Removing orderer.example.com    ... done
Removing peer0.org2.example.com ... done
Removing peer0.org1.example.com ... done
Removing peer1.org1.example.com ... done
Removing peer1.org2.example.com ... done
Removing network net_byfn
Removing volume net_orderer.example.com
Removing volume net_peer0.org1.example.com
Removing volume net_peer1.org1.example.com
Removing volume net_peer0.org2.example.com
Removing volume net_peer1.org2.example.com
Removing volume net_peer0.org3.example.com
WARNING: Volume net_peer0.org3.example.com not found.
Removing volume net_peer1.org3.example.com
WARNING: Volume net_peer1.org3.example.com not found.
ecb4fdc92f08
371265c5742b
09345fac83ed
Untagged: dev-peer1.org2.example.com-mycc-1.3-382167099009df91290882e242a2f144a07c1d6ddb4a0a026f58c03c759dfd52:latest
Deleted: sha256:2cc1d46f3be5372466f85018e113b00d5e835ace9538166b298214b388225af8
Deleted: sha256:5449d6c12453181e8ac2554783e03da8ae34b4125c1eaf18271481a9b9e0da01
Deleted: sha256:04419c789a444d1224e1d462a74edb708a6ce7605f983f97a2276166b47d4ed8
Deleted: sha256:fbaf2f7733aa26c1fd20ac4e92771f3831377922acb9353263ef406a7fceae60
Untagged: dev-peer0.org1.example.com-mycc-1.3-f06095641d6dc000080874fa4076a996130733a970973834b35af14851f9a0f4:latest
Deleted: sha256:4402a7363aa40acead3bbba0d3917c77bcff6650fd88e2cb5f0cf52c75c1d80a
Deleted: sha256:fa8516c3ccbc3504e7fb826c72435219dd6c36ee18a2d55a2c2dadf914851cb9
Deleted: sha256:856305e1de606a4ab38de20e16f67f7303fc7a17101186d5ac98fdfee6562a56
Deleted: sha256:f272755391d3e5180491d0c0763e7e32a5235a8137a3c9b4b61fb1bc0237b601
Untagged: dev-peer0.org2.example.com-mycc-1.3-1eb1a770d33b0287ab46570523c2f9d1c35f2e4794920cf70d1841a20e74095b:latest
Deleted: sha256:97f4d6292ee2c37fa11e14a6f1e9692382d6ce86864c62aa48c7820910a651cb
Deleted: sha256:9c863a43d8b5e24c1a1ed197f76fcef1a7efe5e4a473e8c98d777aa76a16cb49
Deleted: sha256:713f12cc236025a9582f6f24943b45b9123cf0a1db43c23a74b70cab4f5534bd
Deleted: sha256:a47634d20eac92b4629bdb39f309bc7cf1aa5b20208f2eaa566eaf948f57c05a

If you’d like to learn more about the underlying tooling and bootstrap mechanics, continue reading. In these next sections we’ll walk through the various steps and requirements to build a fully-functional Hyperledger Fabric network. 如果你想了解有關底層工具和引導機制的更多資訊，請繼續閱讀。 在接下來的部分中，我們將介紹構建全功能Hyperledger Fabric網路的各種步驟和要求。

The manual steps outlined below assume that the CORE_LOGGING_LEVEL in the cli container is set to DEBUG. You can set this by modifying the docker-compose-cli.yaml file in the first-network directory. e.g. 下面列出的手動步驟假定cli容器中的CORE_LOGGING_LEVEL設定為DEBUG。 你可以通過修改first-network目錄中的docker-compose-cli.yaml檔案來設定它。 例如。

cli:
  container_name: cli
  image: hyperledger/fabric-tools:$IMAGE_TAG
  tty: true
  stdin_open: true
  environment:
    - GOPATH=/opt/gopath
    - CORE_VM_ENDPOINT=unix:///host/var/run/docker.sock
    - CORE_LOGGING_LEVEL=DEBUG
    #- CORE_LOGGING_LEVEL=INFO

加密材料生成器（Crypto Generator）

We will use the cryptogen tool to generate the cryptographic material (x509 certs and signing keys) for our various network entities. These certificates are representative of identities, and they allow for sign/verify authentication to take place as our entities communicate and transact. 我們將使用cryptogen工具為我們的各種網路實體生成加密材料（x509證書和簽名金鑰）。 這些證書代表身份，它們允許在我們的實體進行通訊和交易時進行簽名/驗證身份認證。

它如何工作（How does it work）?

Cryptogen consumes a file - crypto-config.yaml - that contains the network topology and allows us to generate a set of certificates and keys for both the Organizations and the components that belong to those Organizations. Each Organization is provisioned a unique root certificate (ca-cert) that binds specific components (peers and orderers) to that Org. By assigning each Organization a unique CA certificate, we are mimicking a typical network where a participating Member would use its own Certificate Authority. Transactions and communications within Hyperledger Fabric are signed by an entity’s private key (keystore), and then verified by means of a public key (signcerts). Cryptogen使用一個檔案 - “crypto-config.yaml” - 包含網路拓撲，並允許我們為組織和屬於這些組織的元件生成一組證書和金鑰。 每個組織都配置了一個唯一的根證書（ca-cert），它將特定元件（對等節點和排序節點）繫結到該組織。 通過為每個組織分配一個唯一的CA證書，我們模仿一個典型的網路，其中參與的成員會使用它自己的證書頒發機構。 Hyperledger Fabric中的交易和通訊由實體的私鑰（keystore）簽名，然後通過公鑰（signcerts）進行驗證。

You will notice a count variable within this file. We use this to specify the number of peers per Organization; in our case there are two peers per Org. We won’t delve into the minutiae of x.509 certificates and public key infrastructure right now. If you’re interested, you can peruse these topics on your own time. 你會注意到這個檔案中有一個count變數。 我們用它來指定每個組織的對等節點數量; 在我們的例子中，每個Org有兩個對等節點。 我們現在不會深入研究x.509證書和公鑰基礎設施的細枝末節。 如果你有興趣，可以在自己的時間內仔細閱讀這些主題。

Before running the tool, let’s take a quick look at a snippet from the crypto-config.yaml. Pay specific attention to the “Name”, “Domain” and “Specs” parameters under the OrdererOrgs header: 在執行該工具之前，讓我們快速瀏覽一下crypto-config.yaml的片段。 特別注意OrdererOrgs標題下的“Name”，“Domain”和“Specs”引數：

OrdererOrgs:
#---------------------------------------------------------
# Orderer
# --------------------------------------------------------
- Name: Orderer
  Domain: example.com
  CA:
      Country: US
      Province: California
      Locality: San Francisco
  #   OrganizationalUnit: Hyperledger Fabric
  #   StreetAddress: address for org # default nil
  #   PostalCode: postalCode for org # default nil
  # ------------------------------------------------------
  # "Specs" - See PeerOrgs below for complete description
# -----------------------------------------------------
  Specs:
    - Hostname: orderer
# -------------------------------------------------------
# "PeerOrgs" - Definition of organizations managing peer nodes
 # ------------------------------------------------------
PeerOrgs:
# -----------------------------------------------------
# Org1
# ----------------------------------------------------
- Name: Org1
  Domain: org1.example.com
  EnableNodeOUs: true

The naming convention for a network entity is as follows - “{{.Hostname}}.{{.Domain}}”. So using our ordering node as a reference point, we are left with an ordering node named - orderer.example.com that is tied to an MSP ID of Orderer. This file contains extensive documentation on the definitions and syntax. You can also refer to the Membership Service Providers (MSP) documentation for a deeper dive on MSP. 網路實體的命名約定如下 - “{{.Hostname}}.{{.Domain}}”。 因此，使用我們的排序節點作為參考點，我們留下一個名為 - “orderer.example.com”的排序節點，它與“Orderer”的MSP ID相關聯。 該檔案包含有關定義和語法的大量文件。 你還可以參考會員服務提供者（MSP）文件，深入瞭解MSP。

After we run the cryptogen tool, the generated certificates and keys will be saved to a folder titled crypto-config. 執行cryptogen工具後，生成的證書和金鑰將儲存到名為crypto-config的資料夾中。

配置交易生成器（Configuration Transaction Generator）

The configtxgen tool is used to create four configuration artifacts: configtxgen工具用於建立四個配置工件：

• orderer genesis block, 排序節點genesis block，
• channel configuration transaction, 通道configuration transaction，
• and two anchor peer transactions - one for each Peer Org. 和兩個“anchor peer transactions” - 每個對等節點的組織一個。

Please see configtxgen for a complete description of this tool’s functionality. 有關此工具功能的完整說明，請參閱configtxgen。

The orderer block is the Genesis Block for the ordering service, and the channel configuration transaction file is broadcast to the orderer at Channel creation time. The anchor peer transactions, as the name might suggest, specify each Org’s Anchor Peer on this channel. 排序節點區塊是排序服務的創世區塊，並且通道配置交易檔案在通道建立時被廣播到排序節點。 正如名稱所暗示的那樣，主播節點交易在此通道上指定每個組織的主播節點。

它如何工作（How does it work）?

Configtxgen consumes a file - configtx.yaml - that contains the definitions for the sample network. There are three members - one Orderer Org (OrdererOrg) and two Peer Orgs (Org1 & Org2) each managing and maintaining two peer nodes. This file also specifies a consortium - SampleConsortium - consisting of our two Peer Orgs. Pay specific attention to the “Profiles” section at the top of this file. You will notice that we have two unique headers. One for the orderer genesis block - TwoOrgsOrdererGenesis - and one for our channel - TwoOrgsChannel. Configtxgen使用一個檔案 - configtx.yaml - 包含示例網路的定義。有三個成員 - 一個排序節點的組織（OrdererOrg）和兩個對等節點的組織（Org1和Org2），每個對等節點的組織管理和維護兩個對等節點。該檔案還指定了一個聯盟 - SampleConsortium - 由這兩個對等節點組織組成。請特別注意此檔案頂部的“配置檔案”部分。你會注意到我們有兩個唯一的頭部。一個用於排序節點創世區塊 - TwoOrgsOrdererGenesis - ，一個用於我們的通道 - TwoOrgsChannel。

These headers are important, as we will pass them in as arguments when we create our artifacts. 這些頭部很重要，因為我們將在建立工件時將它們作為引數傳遞。

Notice that our SampleConsortium is defined in the system-level profile and then referenced by our channel-level profile. Channels exist within the purview of a consortium, and all consortia must be defined in the scope of the network at large. 請注意，我們的SampleConsortium在系統級配置檔案中定義，然後由我們的通道級配置檔案引用。通道存在於一個聯盟的範圍內，所有聯盟必須在整個網路範圍內定義。

This file also contains two additional specifications that are worth noting. Firstly, we specify the anchor peers for each Peer Org (peer0.org1.example.com & peer0.org2.example.com). Secondly, we point to the location of the MSP directory for each member, in turn allowing us to store the root certificates for each Org in the orderer genesis block. This is a critical concept. Now any network entity communicating with the ordering service can have its digital signature verified. 此檔案還包含兩個值得注意的其他規範。首先，我們為每個對等節點的組織指定主播節點（peer0.org1.example.com和peer0.org2.example.com）。其次，我們指出每個成員的MSP目錄的位置，從而允許我們在排序節點創世區塊中儲存每個組織的根證書。這是一個關鍵概念。現在，與排序服務通訊的任何網路實體都可以驗證其數字簽名。

執行工具（Run the tools）

You can manually generate the certificates/keys and the various configuration artifacts using the configtxgen and cryptogen commands. Alternately, you could try to adapt the byfn.sh script to accomplish your objectives. 你可以使用configtxgen和cryptogen命令手動生成證書/金鑰和各種配置工件。 或者，你可以嘗試調整byfn.sh指令碼來實現目標。

手工生成工件（Manually generate the artifacts）

You can refer to the generateCerts function in the byfn.sh script for the commands necessary to generate the certificates that will be used for your network configuration as defined in the crypto-config.yaml file. However, for the sake of convenience, we will also provide a reference here. 你可以在byfn.sh指令碼中引用generateCerts函式，以獲取生成將用於你的網路配置的證書所需的命令，如crypto-config.yaml檔案中所定義。 但是，為方便起見，我們也將在此提供參考。

First let’s run the cryptogen tool. Our binary is in the bin directory, so we need to provide the relative path to where the tool resides. 首先讓我們執行cryptogen工具。 我們的二進位制檔案位於bin目錄中，因此我們需要提供工具所在位置的相對路徑。

../bin/cryptogen generate --config=./crypto-config.yaml

You should see the following in your terminal: 你應該在終端中看到以下內容：

org1.example.com
org2.example.com

The certs and keys (i.e. the MSP material) will be output into a directory - crypto-config - at the root of the first-network directory. 證書和金鑰（即MSP材料）將輸出到first-network目錄下的 - “crypto-config” - 目錄。

Next, we need to tell the configtxgen tool where to look for the configtx.yaml file that it needs to ingest. We will tell it look in our present working directory: 接下來，我們需要告訴configtxgen工具在哪裡查詢它需要用到的configtx.yaml檔案。 我們將在目前的工作目錄中告訴它：

export FABRIC_CFG_PATH=$PWD

Then, we’ll invoke the configtxgen tool to create the orderer genesis block: 然後，我們將呼叫configtxgen工具來建立排序節點創世區塊：

../bin/configtxgen -profile TwoOrgsOrdererGenesis -outputBlock ./channel-artifacts/genesis.block

You should see an output similar to the following in your terminal: 你應該在終端中看到類似於以下內容的輸出：

2018-10-22 10:13:12.673 CST [common/tools/configtxgen] main -> INFO 002 Loading configuration
2018-10-22 10:13:12.735 CST [common/tools/configtxgen] doOutputBlock -> INFO 003 Generating genesis block
2018-10-22 10:13:12.736 CST [common/tools/configtxgen] doOutputBlock -> INFO 004 Writing genesis block

The orderer genesis block and the subsequent artifacts we are about to create will be output into the channel-artifacts directory at the root of this project. ** 排序節點創世區塊和我們即將建立的後續工件將輸出到該專案根目錄的channel-artifacts目錄中。**

建立通道配置交易（Create a Channel Configuration Transaction）

Next, we need to create the channel transaction artifact. Be sure to replace $CHANNEL_NAME or set CHANNEL_NAME as an environment variable that can be used throughout these instructions: 接下來，我們需要建立通道交易工件。 請務必替換$ CHANNEL_NAME或將CHANNEL_NAME設定為可在整個說明中使用的環境變數：

# The channel.tx artifact contains the definitions for our sample channel

export CHANNEL_NAME=mychannel  && ../bin/configtxgen -profile TwoOrgsChannel -outputCreateChannelTx ./channel-artifacts/channel.tx -channelID $CHANNEL_NAME

You should see an output similar to the following in your terminal: 你應該在終端中看到類似於以下內容的輸出：

2018-10-19 16:09:22.576 CST [common/tools/configtxgen] main -> INFO 001 Loading configuration
2018-10-19 16:09:22.622 CST [common/tools/configtxgen] doOutputChannelCreateTx -> INFO 002 Generating new channel configtx
2018-10-19 16:09:22.628 CST [common/tools/configtxgen] doOutputChannelCreateTx -> INFO 003 Writing new channel tx

Next, we will define the anchor peer for Org1 on the channel that we are constructing. Again, be sure to replace $CHANNEL_NAME or set the environment variable for the following commands. The terminal output will mimic that of the channel transaction artifact: 接下來，我們將在我們構建的通道上為Org1定義主播節點。 同樣，請務必替換$ CHANNEL_NAME或為以下命令設定環境變數。 終端輸出將模仿通道交易工件的輸出：

../bin/configtxgen -profile TwoOrgsChannel -outputAnchorPeersUpdate ./channel-artifacts/Org1MSPanchors.tx -channelID $CHANNEL_NAME -asOrg Org1MSP

Now, we will define the anchor peer for Org2 on the same channel: 現在我們將在同一個通道定義Org2的主播節點：

../bin/configtxgen -profile TwoOrgsChannel -outputAnchorPeersUpdate ./channel-artifacts/Org2MSPanchors.tx -channelID $CHANNEL_NAME -asOrg Org2MSP

啟動網路（Start the network）

If you ran the byfn.sh example above previously, be sure that you have brought down the test network before you proceed (see Bring Down the Network). 如果你之前執行過byfn.sh示例，請確保在繼續操作之前已關閉測試網路（請參閱關閉網路).

We will leverage a script to spin up our network. The docker-compose file references the images that we have previously downloaded, and bootstraps the orderer with our previously generated genesis.block. 我們將利用指令碼來運轉我們的網路。 docker-compose檔案引用我們之前下載的映象，並引導之前生成genesis.block的排序節點。

We want to go through the commands manually in order to expose the syntax and functionality of each call. 我們希望手動完成命令，以便公開每個呼叫的語法和功能。

First let’s start our network: 首先讓我們開始我們的網路：

docker-compose -f docker-compose-cli.yaml up -d

If you want to see the realtime logs for your network, then do not supply the -d flag. If you let the logs stream, then you will need to open a second terminal to execute the CLI calls. 如果要檢視網路的實時日誌，請不要提供-d標誌。 如果你讓日誌輸出，那麼你將需要開啟第二個終端來執行CLI呼叫。

環境變數（Environment variables）

For the following CLI commands against peer0.org1.example.com to work, we need to preface our commands with the four environment variables given below. These variables for peer0.org1.example.com are baked into the CLI container, therefore we can operate without passing them. HOWEVER, if you want to send calls to other peers or the orderer, then you can provide these values accordingly by editing the docker-compose-base.yaml before starting the container. Modify the following four environment variables to use a different peer and org. 要使以下針對peer0.org1.example.com的CLI命令起作用，我們需要在命令前加上下面給出的四個環境變數。 peer0.org1.example.com的這些變數被內建到CLI容器中，因此我們可以在不傳遞它們的情況下進行操作。 但是，如果要將呼叫傳送給其他對等節點或排序節點，則可以在啟動容器之前通過編輯docker-compose-base.yaml來相應地提供這些值。 修改以下四個環境變數以使用不同的對等節點和組織。

# Environment variables for PEER0

CORE_PEER_MSPCONFIGPATH=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/users/[email protected]/msp
CORE_PEER_ADDRESS=peer0.org1.example.com:7051
CORE_PEER_LOCALMSPID="Org1MSP"
CORE_PEER_TLS_ROOTCERT_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/ca.crt

建立和加入通道（Create & Join Channel）

Recall that we created the channel configuration transaction using the configtxgen tool in the Create a Channel Configuration Transaction section, above. You can repeat that process to create additional channel configuration transactions, using the same or different profiles in the configtx.yaml that you pass to the configtxgen tool. Then you can repeat the process defined in this section to establish those other channels in your network. 回想一下，我們在前面使用建立通道配置交易部分中的configtxgen工具建立了通道配置交易。 你可以使用傳遞給configtxgen工具的configtx.yaml中相同或不同的配置檔案重複該過程以建立其他通道配置交易。 然後，你可以重複本節中定義的過程，以在你的網路中建立其他通道。

We will enter the CLI container using the docker exec command: 我們將使用docker exec命令進入CLI容器：

docker exec -it cli bash

If successful you should see the following: 如果成功，你將看到如下內容：

[email protected]:/opt/gopath/src/github.com/hyperledger/fabric/peer# 

If you do not want to run the CLI commands against the default peer peer0.org1.example.com, replace the values of peer0 or org1 in the four environment variables and run the commands: 如果你不想針對預設對等節點peer0.org1.example.com執行CLI命令，請在四個環境變數中替換peer0或org1的值並執行命令：

# Environment variables for PEER0

export CORE_PEER_MSPCONFIGPATH=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/users/[email protected]/msp
export CORE_PEER_ADDRESS=peer0.org1.example.com:7051
export CORE_PEER_LOCALMSPID="Org1MSP"
export CORE_PEER_TLS_ROOTCERT_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/ca.crt

Next, we are going to pass in the generated channel configuration transaction artifact that we created in the Create a Channel Configuration Transaction section (we called it channel.tx) to the orderer as part of the create channel request. 接下來，我們將傳遞我們在建立通道配置交易中建立的生成的通道配置事務工件作為建立通道請求的一部分（我們稱之為“channel.tx”）給排序節點。

We specify our channel name with the -c flag and our channel configuration transaction with the -f flag. In this case it is channel.tx, however you can mount your own configuration transaction with a different name. Once again we will set the CHANNEL_NAME environment variable within our CLI container so that we don’t have to explicitly pass this argument. Channel names must be all lower case, less than 250 characters long and match the regular expression [a-z][a-z0-9.-]*. 我們使用-c標誌指定通道名稱，使用-f標誌指定通道配置交易。 在這種情況下，它是channel.tx，但是你可以使用不同的名稱裝入自己的配置交易。 我們將再次在CLI容器中設定CHANNEL_NAME環境變數，以便我們不必顯式傳遞此引數。 通道名稱必須全部小寫，長度小於250個字元，並匹配正則表示式[a-z] [a-z0-9 .-] *。

export CHANNEL_NAME=mychannel

# the channel.tx file is mounted in the channel-artifacts directory within your CLI container
# as a result, we pass the full path for the file
# we also pass the path for the orderer ca-cert in order to verify the TLS handshake
# be sure to export or replace the $CHANNEL_NAME variable appropriately

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

Notice the --cafile that we pass as part of this command. It is the local path to the orderer’s root cert, allowing us to verify the TLS handshake. 注意我們作為此命令的一部分傳遞的--cafile。 它是排序節點的根證書的本地路徑，允許我們驗證TLS握手。

This command returns a genesis block - <channel-ID.block> - which we will use to join the channel. It contains the configuration information specified in channel.tx If you have not made any modifications to the default channel name, then the command will return you a proto titled mychannel.block. 該命令返回一個創世塊 - <channel-ID.block> - 我們將用它來加入通道。 它包含channel.tx中指定的配置資訊。如果你沒有對預設通道名稱進行任何修改，那麼該命令將返回一個名為mychannel.block的原型。

You will remain in the CLI container for the remainder of these manual commands. You must also remember to preface all commands with the corresponding environment variables when targeting a peer other than peer0.org1.example.com. 為了這些手動命令的其餘部分，你將保留在CLI容器中。 在目標是除peer0.org1.example.com以外的對等節點時，你還必須記住在所有命令前加上相應的環境變數。

Now let’s join peer0.org1.example.com to the channel. 現在讓我們將peer0.org1.example.com加入通道。

# By default, this joins ``peer0.org1.example.com`` only
# the <channel-ID.block> was returned by the previous command
# if you have not modified the channel name, you will join with mychannel.block
# if you have created a different channel name, then pass in the appropriately named block

 peer channel join -b mychannel.block

You can make other peers join the channel as necessary by making appropriate changes in the four environment variables we used in the Environment variables section, above. 你可以根據需要通過對上面提到的[環境變數](https://hyperledger-fabric.readthedocs.io/en/release-1.3/build_network.html# peerenvvars)章節中使用的四個環境變數進行適當更改來使其他對等節點加入通道。

Rather than join every peer, we will simply join peer0.org2.example.com so that we can properly update the anchor peer definitions in our channel. Since we are overriding the default environment variables baked into the CLI container, this full command will be the following: 我們只需加入peer0.org2.example.com，而不是加入每個對等節點，這樣我們就可以正確地更新通道中的主播節點定義。 由於我們將覆蓋CLI容器中的預設環境變數，因此完整命令如下：

CORE_PEER_MSPCONFIGPATH=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org2.example.com/users/[email protected]/msp CORE_PEER_ADDRESS=peer0.org2.example.com:7051 CORE_PEER_LOCALMSPID="Org2MSP" 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 peer channel join -b mychannel.block

Alternatively, you could choose to set these environment variables individually rather than passing in the entire string. Once they’ve been set, you simply need to issue the peer channel join command again and the CLI container will act on behalf of peer0.org2.example.com. 或者，你可以選擇單獨設定這些環境變數，而不是傳入整個字串。 一旦設定完畢，你只需再次發出peer channel join命令，CLI容器將代表peer0.org2.example.com。

更新主播節點（Update the anchor peers）

The following commands are channel updates and they will propagate to the definition of the channel. In essence, we adding additional configuration information on top of the channel’s genesis block. Note that we are not modifying the genesis block, but simply adding deltas into the chain that will define the anchor peers. 以下命令是通道更新，它們將傳播到通道的定義。 實質上，我們在通道的創世區塊之上添加了額外的配置資訊。 請注意，我們不是修改genesis塊，而是簡單地將增量新增到將定義主播節點的鏈中。

Update the channel definition to define the anchor peer for Org1 as peer0.org1.example.com: 更新通道定義以將Org1的主播節點定義為“peer0.org1.example.com”：

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

Now update the channel definition to define the anchor peer for Org2 as peer0.org2.example.com. Identically to the peer channel join command for the Org2 peer, we will need to preface this call with the appropriate environment variables. 現在更新通道定義，將Org2的主播節點定義為peer0.org2.example.com。 與Org2對等節點的peer channel join命令相同，我們需要在此呼叫前加上適當的環境變數。

CORE_PEER_MSPCONFIGPATH=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org2.example.com/users/[email protected]/msp CORE_PEER_ADDRESS=peer0.org2.example.com:7051 CORE_PEER_LOCALMSPID="Org2MSP" 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 peer channel update -o orderer.example.com:7050 -c $CHANNEL_NAME -f ./channel-artifacts/Org2MSPanchors.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

安裝和例項化鏈程式碼（Install & Instantiate Chaincode）

We will utilize a simple existing chaincode. To learn how to write your own chaincode, see the Chaincode for Developers tutorial. 我們將使用簡單的現有鏈程式碼。 要了解如何編寫自己的鏈程式碼，請參閱Chaincode for Developers教程。

Applications interact with the blockchain ledger through chaincode. As such we need to install the chaincode on every peer that will execute and endorse our transactions, and then instantiate the chaincode on the channel. 應用程式通過chaincode與區塊鏈帳本互動。 因此，我們需要在每個將執行和背書我們交易的對等節點上安裝鏈程式碼，然後在通道上例項化鏈程式碼。

First, install the sample Go, Node.js or Java chaincode onto one of the four peer nodes. These commands place the specified source code flavor onto our peer’s filesystem. 首先，將示例Go，Node.js或Java鏈程式碼安裝到四個對等節點之一上。 這些命令將指定的原始碼放在我們的對等節點檔案系統上。

You can only install one version of the source code per chaincode name and version. The source code exists on the peer’s file system in the context of chaincode name and version; it is language agnostic. Similarly the instantiated chaincode container will be reflective of whichever language has been installed on the peer. 每個鏈程式碼名稱和版本只能安裝一個版本的原始碼。 原始碼存在於對等節點基於鏈程式碼名稱和版本的檔案系統中; 它與語言無關。 類似地，例項化的鏈程式碼容器將反映對等節點上安裝的任何語言。

Golang

# this installs the Go chaincode
peer chaincode install -n mycc -v 1.0 -p github.com/chaincode/chaincode_example02/go/

Node.js

# this installs the Node.js chaincode
# make note of the -l flag; we use this to specify the language
peer chaincode install -n mycc -v 1.0 -l node -p /opt/gopath/src/github.com/chaincode/chaincode_example02/node/

Java

peer chaincode install -n mycc -v 1.0 -l java -p /opt/gopath/src/github.com/chaincode/chaincode_example02/java/

Next, instantiate the chaincode on the channel. This will initialize the chaincode on the channel, set the endorsement policy for the chaincode, and launch a chaincode container for the targeted peer. Take note of the -P argument. This is our policy where we specify the required level of endorsement for a transaction against this chaincode to be validated. 接下來，在通道上例項化鏈碼。 這將初始化通道上的鏈程式碼，設定鏈程式碼的背書策略，併為目標對等節點啟動鏈程式碼容器。 記下-P引數。 這是我們的策略，我們在此策略中指定針對要驗證的鏈程式碼交易所需的請求級別。

In the command below you’ll notice that we specify our policy as -P "AND ('Org1MSP.peer','Org2MSP.peer')". This means that we need “endorsement” from a peer belonging to Org1 AND Org2 (i.e. two endorsement). If we changed the syntax to OR then we would need only one endorsement. 在下面的命令中，你會注意到我們將策略指定為-P "AND ('Org1MSP.peer','Org2MSP.peer')"。 這意味著我們需要來自屬於Org1 和 Org2的對等節點的“背書”（即兩個背書）。 如果我們將語法更改為OR，那麼我們只需要一個背書。

Golang

# be sure to replace the $CHANNEL_NAME environment variable if you have not exported it
# if you did not install your chaincode with a name of mycc, then modify that argument as well

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 "AND ('Org1MSP.peer','Org2MSP.peer')"

Node.js

The instantiation of the Node.js chaincode will take roughly a minute. The command is not hanging; rather it is installing the fabric-shim layer as the image is being compiled. ** Node.js鏈程式碼的例項化大約需要一分鐘。 命令沒有掛