以e2e_cli爲例漫談fabric的一些基礎知識點

在剛接觸fabric的時候通常都是直接跟着wiki的教程一步步安裝配置，執行一系列命令，最終將其運行起來，但不少人對其中的運行流程及其基礎知識點可能不是很瞭解。基於此今天我將以$FABRIC_ROOT/examples/e2e_cli/ 經典Demo爲例來分享一些個人理解，但願能夠對入門者有所幫助。

生成證書

fabric是有準入門檻的聯盟鏈，經過MSP服務來進行對其中的成員進行統一管理。既然提到了MSP，那就確定離不開證書這一律念。證書的做用一方面是用於驗證消息的簽名是否有效從而驗證交易是否有效，另外一方面能夠用於確認該證書的擁有者身份。

因此要運行起整個fabric網絡首先得生成證書，生成證書的配置文件在crypto-config.yaml中，根據本身的需求定義好OrdererOrgs和PeerOrgs信息，以後在generateArtifacts.sh腳本中執行generateCerts方法便可在當前目錄下生成包含證書文件的crypto-config目錄。

ordererOrganizations
    example.com
        ca  # 包含給Orderer組織頒發MSP證書的ca的公私鑰
        msp # 包含Orderer組織的msp相關證書（admincerts，cacerts，tlscacerts）
        orderers 
            orderer.example.com
                msp
                    admincerts # 管理員證書
                    cacerts    # 給Orderer組織頒發MSP證書的ca的證書
                    keystore   # 當前Orderer組織的私鑰
                    signcerts  # 當前Orderer組織的證書（包含公鑰）
                    tlscacerts # 給Orderer組織頒發TLS證書的ca的證書
                tls
                    ca.crt     # 給Orderer組織頒發TLS證書的ca的證書
                    server.crt # 當前Orderer組織的tls證書（包含公鑰）
                    server.key # 當前Orderer組織的tls私鑰              
        tlsca # 包含給Orderer組織頒發TLS證書的ca的公私鑰
        users # 包含Orderer下普通用戶和管理員用戶的msp和tls證書

以上是以Orderer組織爲例說明了下生成的證書目錄層級結構及其對應的目錄或文件的含義，Peer組織的相似。

TLS（Transport Layer Security Protocol）是Https創建在SSL 3.0之上的一個標準的安全傳輸層協議。負責安全通訊，安全傳輸數據包。須要作數字簽名的認證才能正常的去繼續作http的握手而後再作交互。
MSP（Membership Service Provider）是負責成員是否被認證過進入咱們這個網絡裏的安全管理

生成genesis.block

證書生成好以後接下來就能夠定義Orderer的配置以生成genesis.block了。該配置在configtx.yaml中的Profiles.TwoOrgsOrdererGenesis下。

TwoOrgsOrdererGenesis:
        Capabilities:
            <<: *ChannelCapabilities
        Orderer:
            <<: *OrdererDefaults
            Organizations:
                - *OrdererOrg
            Capabilities:
                <<: *OrdererCapabilities
        Consortiums:
            SampleConsortium:
                Organizations:
                    - *Org1
                    - *Org2

*OrdererDefaults：引用包含了Orderer的基本信息以下

• OrdererType（共識類型）是solo仍是kafka。solo就是一個模擬kafka的本地的單機的文件系統實現的消息隊列，缺點是在執行速度和效率上確定不如kafka，測試環境通常就用solo，生產環境用kafka。kafka目前是經過消息隊列保證全部的節點對transaction的時間有一個共識，並無具體的像比特幣之類的pow共識算法，之前的0.6版本有pbft算法，但1.0之後尚未實現。
• Addresses：Orderer服務的地址列表
• BatchTimeout：Orderer節點的出塊時間
• BatchSize：區塊大小包含最大交易筆數（MaxMessageCount），最大區塊大小（AbsoluteMaxBytes）以及建議區塊大小（PreferredMaxBytes）
• Kafka：包含brokers列表。當設置了OrdererType爲kafka才生效，若是是solo則該配置不生效。

*OrdererOrg：引用包含了OrdererOrg的MSP信息

• Name：OrdererOrg
• ID：Orderer的MSPID
• MSPDir：Orderer組織的MSP目錄（就是上面生成的msp目錄）

*Org1 同OrdererOrg引用同樣

*Org2 同OrdererOrg引用同樣

綜上，經過這些配置生成genesis.block以後，Orderer服務就會明確所使用的共識類型，服務地址列表，出塊時間，出塊大小。同時也就擁有了Orderer節點MSPID和MSP證書（包含Orderer的管理員證書，Orderer的CA證書，Orderer的TLS CA證書），以及聯盟裏面的全部Org（這裏是Org1和Org2）的MSPID和MSP證書（包含Org的管理員證書，Org的CA證書，Org的TLS CA證書）,待整個fabric網絡運行起來以後Orderer服務即可以利用這些CA證書很容易的驗證節點傳過來的證書是否有效。

生成通道配置交易

Orderer配置好以後，一樣經過configtx.yaml中的Profiles.TwoOrgsChannel配置信息來生成一個通道配置類型的交易（ConfigUpdateEnvelope）。

TwoOrgsChannel:
        Consortium: SampleConsortium
        Application:
            <<: *ApplicationDefaults
            Organizations:
                - *Org1
                - *Org2
            Capabilities:
                <<: *ApplicationCapabilities

啓動網絡

在e2e_cli這個Demo項目裏面咱們是經過Docker的方式來運行fabric網絡的。正常咱們的docker，好比在咱們本地已經build出了不少docker image，好比咱們有hyperledger/fabric-peer，若是想讓docker image運行起來，通常都是經過docker run這樣的命令，好比我單獨去run一個peer，docker run + 這個docker image的名字，而後加一些參數就啓動了一個docker container，docker container運行了這個docker image的環境。若是有多個image，咱們手動的一個個去啓動太麻煩了，咱們想有一個配置文件，能讓批量的不少不少的節點一塊兒啓動，那這個功能就引出了docker-compose。簡單說，docker-compose就是把多個docker image啓動的定義和配置組合在一塊兒放在一個文件裏一塊兒啓動起來。

# 啓動fabric網絡所須要的全部Docker Container並在後臺掛起
docker-compose -f docker-compose-cli.yaml up -d

# 進入container_name爲 orderer.example.com 的Docker Container
docker exec -it orderer.example.com bash

# 查看docker日誌
docker logs -f containerID/containerName
docker logs -f orderer.example.com

正常狀況下在docker-compose-cli.yaml裏面名爲「cli」的docker container在一運行起來之後就會執行腳本scripts/script.sh，該腳本中包含了建立通道、加入通道、更新錨節點、安裝chaincode、實例化chaincode、query/invoke chaincode等一系列操做，爲了一步步進行，所以在啓動網絡前須要在docker-compose-cli.yaml中作以下修改

# 將名爲「cli」的docker-container原來的命令註釋掉並改成以下
command: /bin/bash -c 'sleep 100000'
#command: /bin/bash -c './scripts/script.sh ${CHANNEL_NAME}; sleep $TIMEOUT'

操做網絡

經過docker-compose將fabric所須要的docker container都run起來以後，就能夠經過 docker exec -it cli bash 進入相應的container，從而對fabric網絡進行操做。具體的操做命令在 scripts/script.sh 中都有，這裏就再也不贅述了。下面用一張圖來描述在對網絡進行一系列操做的過程當中cli/sdk端、peer端、order端之間的交互過程。

說明：

1. 若是在sdk/cli側設置 $CORE_PEER_TLS_ENABLED = TRUE，則須要且僅僅在Create Channel、UpdateAnchorPeers、Instantiate Chaincode、Invoke Chaincode的時候指定OrdererCA，該配置用於設置是否開啓TLS，TLS就是那個安全的SSL 3.0的時候安全的一個認證方式，至關於在數據傳輸以前作一個安全的認證，這裏只是判斷它要不要作安全認證。
2. 在fabric network中，orderer側其實也會保存有本身的區塊鏈也就是ledger，而剩下全部的Organization中的全部的peer側都會分別維護一個ledger和一個state db，圖中爲了簡潔沒有文字標出，這裏作下解釋。
3. peer節點的本地帳本保存位置爲：/var/hyperledger/production/ledgerData/chains/chains/mychannel
4. orderer裏面的mychannel目錄是orderer這邊來存放transaction和block的位置，全部的transaction都要提交到orderer這邊讓orderer作一個transaction的排序，排序好以後orderer
   會把block分發下去給每個Org的主節點（leader peer）節點去同步，因此orderer本地也是存在一個block的鏈（帳本）的，保存位置爲：/var/hyperledger/production/orderer/chains/mychannel。
5. 這裏所說的查看peer和orderer的帳本路徑前提是要進入到其對應的docker container中。

實例化過程

fabric網絡啓動好，建立channel，加入channel，安裝chaincode以後必須實例化chaincode才能夠進行query/invoke操做，而instantiate chaincode這一過程也是整個過程當中花時間最久的，好多新入門的夥伴在這一塊也容易混淆，因此這裏單獨摘出來分享一下。

chaincode的instantiate過程這樣的。首先peer節點須要對chaincode作編譯，它會在fabric-ccenv環境裏面把chaincode build，利用fabric-ccenv建立一個新的docker container並把chaincode裝載進去，chaincode在這個新的docker container裏面運行起來，chaincode首先會去到peer節點去註冊一下，而後peer節點會容許它註冊成功，peer節點作初始化，調用chaincode的init方法，以後等待別人調用。因爲他們隔離在不一樣的container裏面，以後chaincode和peer一直都會有一個keepalive的長連接（互相發送數據包）來保護他們之間的連接不被斷開。

說明：

1. 在一個channel中同一個chaincode只須要作一次instantiate就能夠了，其它的節點只須要安裝了就能夠不須要再次實例化，當cli/sdk去調用到其它節點的chaincode時候，它會自動的在被調用的時候去作一次instantiate chaincode並把它裝載到一個新的container裏面運行起來。
2. chaincode是由peer觸發去build的，build好以後chaincode被裝載到一個新的container運行，它的整個生命週期是由peer管理的，peer在管理chaincode的時候經過一個叫lifecycle的系統chaincode（lscc）來管理咱們裝載的用戶chaincode，因此須要模擬去install一下chaincode，讓peer知道有一個新的chaincode來了，peer知道去管理它的生命週期。
3. chaincode運行階段是一個endorsement背書模擬執行的階段，它是在跟peer相同的機器上執行，peer建立一個新的container，而後裝載chaincode來執行相應的方法。

補充知識點

一、MSP證書解釋

• admincerts：管理員證書，它比普通的peer0證書有一些特殊的權限，好比對節點的修改或者配置等操做
• cacerts：裏面放的是對這個peer0頒發證書的ca是誰，裏面放的是ca的公鑰
• keystore：是peer0這個節點msp的本身的私鑰
• signcerts：裏面放的是這個organization的ca（ca.org1.example.com-cert.pem）給peer0頒發的證書
• tlscacerts：裏面放的是對這個peer0辦法TLS證書的ca是誰，裏面放的是TLS ca的公鑰
• admincerts和signcerts都是簽發以後的證書，只是他們的角色不一樣，admincerts對peer0有一些特殊的管理權限，但signcerts只是一個普通的certs

二、TLS證書解釋

• ca.crt：TLS安全認證過程的時候驗證證書的ca
• server.crt：節點自己的TLS證書
• server.key：節點自己的TLS私鑰

三、命令行查看證書內容

openssl x509 -in peer0.org1.example.com-cert.pem -text

四、若是在當前的某個Organization中加入一個新的peer節點，則不須要更新orderer排序服務的配置，只須要給peer用所屬Organization的rootca給其頒發一套證書便可；而當新加入一個新的Organization的時候咱們須要更新orderer排序服務的配置。即新的Organization它的root ca是什麼（msp的root ca是什麼，tls的root ca是什麼），而後咱們拿它去驗證一個成員在不在這個Organization裏面

五、fabric-ca的做用是encroll註冊，准入，經過name和org去得到token，之後訪問就用token訪問，跟msp證書是兩回事。token認證既不是msp認證，又不是tls認證

六、利用configtxlator工具查看genesis.block內容，其實它就是一個common.Block（protos/common/common.pb.go）格式的結構體序列化之後生成的文件，因此反序列化的時候須要用common.Block才能把它解開，具體步驟以下

vagrant@hyperledger-devenv:523f644:/opt/gopath/src/github.com/hyperledger/fabric/release/linux-amd64/bin$ ./configtxlator start
2018-05-01 09:32:12.726 UTC [configtxlator] startServer -> INFO 001 Serving HTTP requests on 0.0.0.0:7059

configtxlator start 啓動工具服務

http://127.0.0.1:7059/protolator/decode/common.Block

七、若是想要更改peer的功能，則在修改完peer部分的代碼以後須要在$FABRIC_HOME下從新執行maker docker命令以生成新的fabric-peer鏡像

八、fabric-baseos鏡像是在peer節點在編譯chaincode的時候它須要baseos做爲編譯環境裏的一個os的基礎

九、balance-transfer是一個完整的使用了fabric-node-sdk的一個client端，它能跟區塊鏈peer，orderer作交互，它能夠去配置orderer，建立channel，它能夠去配置peer，讓peer節點加入channel，都是能夠作的。能夠理解爲以前經過CLI能夠作的全部任務，在sdk下均可以完成，並且功能更強大，由於sdk是可編程的。

十、數字證書包含了證書原文、加密哈希算法以及ca私鑰簽名後的證書密文三部份內容。在驗證數字證書的有效性時只須要知道該證書的頒發組織/機構（CA）的公鑰便可。另外PKI體系中的公私鑰非對稱加密算法公鑰解密的場景只有在一種狀況下會發生，就是在數字證書有效性校驗/數字簽名驗籤的時候。