Taking E2E_CLI as an example to talk about some basic knowledge points of fabric

In the first contact with the fabric is usually directly follow the Wiki tutorial step-by-step installation of the configuration, execute a series of commands, and eventually run it up, but many people on the running process and its basic knowledge point may not be very familiar. Based on this today I will take the $fabric_root/examples/e2e_cli/classic demo as an example to share some of my understanding, hope can be helpful to the beginner.

Generate certificate

Fabric is an entry-threshold alliance chain that uses MSP services to manage its members uniformly. Since the MSP is mentioned, the concept of certificates must be inseparable. The role of a certificate is to verify that the signature of the message is valid to verify that the transaction is valid, and on the other hand, to confirm the identity of the certificate's owner.

So to run the entire fabric network first you have to generate a certificate, The configuration file that generates the certificate in Crypto-config.yaml, define the Ordererorgs and Peerorgs information according to your own requirements, and then execute the Generatecerts method in the Generateartifacts.sh script to generate the document containing the certificate in the current directory. The Crypto-config directory of the components.

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证书

The above is an example of the Orderer organization, which describes the hierarchy of certificates generated below and the meaning of their corresponding directories or files, similar to peer organizations.

TLS (Transport Layer Security Protocol) is a standard secure Transport layer protocol that HTTPS builds on SSL 3.0. Responsible for secure communication and secure transmission of packets. Need to do digital signature authentication in order to continue to do the HTTP handshake and then do the interaction.
MSP (Membership Service Provider) is responsible for the security management of members who have been certified into our network

Generate Genesis.block

After the certificate is generated, you can then define the configuration of the orderer to generate the Genesis.block. This configuration is under Profiles.twoorgsorderergenesis in Configtx.yaml.

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

*ordererdefaults: Reference to the basic information containing the orderer is as follows

• Orderertype (consensus type) is solo or Kafka. Solo is a local single-machine simulation Kafka Message Queuing, the disadvantage is that in the execution speed and efficiency is certainly not as good as Kafka, test environment is generally used solo, production environment with Kafka. Kafka is currently through the message queue to ensure that all nodes on the transaction time there is a consensus, and there is no specific like the POW consensus algorithm such as Bitcoin, the previous 0.6 version has PBFT algorithm, but 1.0 has not been implemented.
• Address List of the Addresses:orderer service
• Batchtimeout:orderer Time of the node
• BatchSize: Chunk size contains maximum number of trades (maxmessagecount), maximum chunk size (absolutemaxbytes), and recommended chunk size (preferredmaxbytes)
• Kafka: Contains a list of brokers. When Orderertype is set to Kafka, the configuration does not take effect if it is a solo.

*ordererorg: Reference to MSP information with ordererorg

• name:ordererorg
• Id:orderer's Mspid
• Mspdir:orderer Organization's MSP directory (which is the MSP directory generated above)

*org1 Same as ordererorg reference

*org2 Same as ordererorg reference

In conclusion, after generating genesis.block through these configurations, the Orderer service will clearly identify the type of consensus used, the list of service addresses, the block time, and the size of the block. It also has the Orderer node Mspid and MSP certificates (including Orderer Administrator certificate, orderer CA certificate, orderer TLS CA certificate), and all the Org (here is Org1 and ORG2) in the Federation of the Mspid and MSP certificates (including Org's administrator certificate, Org's CA certificate, org's TLS CA certificate), After the entire fabric network is running, the Orderer service can take advantage of these CA certificates to verify that the certificates sent by the nodes are valid.

Generate Channel Configuration transactions

Once the orderer is configured, it also generates a transaction (Configupdateenvelope) of the channel configuration type through the Profiles.twoorgschannel configuration information in the Configtx.yaml.

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

Start the network

In E2E_CLI This demo project we are running the fabric network through Docker. Normally our Docker, for example, has created a lot of Docker image in our local, such as we have hyperledger/fabric-peer, if we want to let Docker image run, it is usually through Docker Run such a command, such as I go to run a peer,docker run + the name of the Docker image, and then add some parameters to launch a Docker Container,docker container run the Docker Image's environment. If there are more than one image, we manually go to boot too much trouble, we want to have a configuration file, can let a lot of lots of many nodes to start together, then this feature leads to Docker-compose. Simply put, Docker-compose is the combination of the definitions and configurations of multiple Docker image launches together in one file to start up together.

# 启动fabric网络所需要的所有Docker Container并在后台挂起docker-compose -f docker-compose-cli.yaml up -d# 进入container_name为 orderer.example.com 的Docker Containerdocker exec -it orderer.example.com bash# 查看docker日志docker logs -f containerID/containerNamedocker logs -f orderer.example.com

Normally the Docker container named "CLI" in Docker-compose-cli.yaml executes the script scripts/script.sh after it is run, which contains the creation channel, the join channel, the update anchor node, Install Chaincode, instantiate Chaincode, Query/invoke chaincode a series of operations, in order to step by step, so before starting the network need to make the following changes in Docker-compose-cli.yaml

# 将名为“cli”的docker-container原来的命令注释掉并改为如下command: /bin/bash -c 'sleep 100000'#command: /bin/bash -c './scripts/script.sh ${CHANNEL_NAME}; sleep $TIMEOUT'

Operating Network

By docker-compose the Docker container required for fabric to run, you can enter the appropriate container through Docker exec-it CLI Bash to operate on the fabric network. The specific operation commands are available in the scripts/script.sh and are not described here. The following diagram describes the interaction between the CLI/SDK, peer, and order in the process of a series of operations on the network.

Description

1. If you set $CORE _peer_tls_enabled = TRUE on the sdk/cli side, you will need and only create Channel, Updateanchorpeers, instantiate Chaincode, Invoke Chaincode specify Ordererca, the configuration is used to set whether to turn on TLS,TLS is the secure SSL 3.0 security of a way, equivalent to a secure authentication before the data transfer, here just to determine if it should not do security certification.
2. In the fabric network, the orderer side actually holds its own blockchain, which is ledger, and all the peer sides in all organization maintain a ledger and a state db, respectively, In order to be concise and no text marked, here to explain.
3. The local ledger of the peer node is saved in the following location:/var/hyperledger/production/ledgerdata/chains/chains/mychannel
4. Orderer inside the MyChannel directory is orderer this side to store transaction and block location, all transaction to submit to orderer this side let Orderer do a transaction sort, After sorting, Orderer.
   The block will be distributed to each of the main node of the Org (leader Peer) to synchronize, so Orderer Local also exists a block chain (ledger), save location:/var/hyperledger/production/ Orderer/chains/mychannel.
5. What is said here is to view the ledger path of peer and orderer as a prerequisite for entering into its corresponding Docker container.

Instantiation process

The fabric network starts well, creates the channel, joins the channel, and after installing Chaincode must instantiate Chaincode to perform query/invoke operations, and instantiate Chaincode This process is also the whole process of taking the longest time, a lot of new entry partners in this piece is also easy to confuse, so here alone to share.

Chaincode The instantiate process like this. First the peer node needs to compile the chaincode, it will build the Chaincode in the FABRIC-CCENV environment, use FABRIC-CCENV to create a new Docker container and load the Chaincode, Chaincode in this new Docker container run, Chaincode first will go to peer node to register, and then peer node will allow it to register successfully, peer node initialization, call Chaincode init method, Then wait for someone else to call. Since they are isolated in different container, Chaincode and peer will always have a keepalive long link (sending packets to each other) to protect their links from being disconnected.

Description

1. In a channel the same chaincode only need to do once instantiate, the other nodes only need to install it can not need to instantiate again, when CLI/SDK to call the other node Chaincode, It will automatically be called at the time to do a instantiate chaincode and load it into a new container inside the run up.
2. Chaincode is triggered by peer to build, and after build is chaincode loaded into a new container run, its entire life cycle is managed by peer, Peer in the management of the Chaincode through a system called Lifecycle Chaincode (LSCC) to manage our loaded user Chaincode, so need to simulate to install Chaincode, Let peer know that a new chaincode is coming, and peer knows to manage its life cycle.
3. The Chaincode run phase is a phase of endorsement endorsement simulation execution, which is performed on the same machine as peer, the peer creates a new container, and then loads the Chaincode to execute the corresponding method.

Complementary knowledge points

1. MSP certificate Interpretation

• Admincerts: Administrator certificate, it has some special permissions than ordinary PEER0 certificate, such as the modification of nodes or the configuration of operations
• Cacerts: What's in it is the CA who issued the certificate for this Peer0, which is the CA's public key
• KeyStore: Is the Peer0 of this node MSP's own private key
• Signcerts: This is the organization CA (CA.ORG1.EXAMPLE.COM-CERT.PEM) certificate issued to Peer0.
• Tlscacerts: What's in it is the CA who has the TLS certificate for this Peer0 method, which puts the public key of the TLS CA
• Admincerts and Signcerts are issued after the certificate, but their role is different, admincerts to Peer0 have some special administrative rights, but Signcerts is just a normal certs

2. TLS Certificate Interpretation

• Ca.crt:TLS The CA that validates the certificate during the security certification process
• SERVER.CRT: TLS certificate for the node itself
• Server.key: TLS private key for the node itself

3. View the contents of the certificate on the command line

OpenSSL x509-in Peer0.org1.example.com-cert.pem-text

4. If a new peer node is added to a current organization, you do not need to update the configuration of the Orderer sorting service, just give the peer the ROOTCA of the owning organization to issue a set of certificates. And when new organization is added we need to update the configuration of the Orderer sort service. namely the new organization what is its root CA (what is the root CA of the MSP, what is the root CA of TLS), and then we take it to verify that a member is not in this Organization

5, the role of FABRIC-CA is Encroll registration, access, through name and org to obtain tokens, later access to use token access, and MSP Certificate is two different. Token authentication is neither MSP nor TLS certified

6, the use of Configtxlator tools to view genesis.block content, in fact, it is a common.block (protos/common/ COMMON.PB.GO) format of the structure of the generated file after serialization, so the deserialization needs to use Common.block to untie it, the steps are as follows

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 Tool Service

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

7. If you want to change the function of peer, you need to re-execute the maker Docker command under $fabric_home to generate a new Fabric-peer image after modifying the code of the peer Section

8, Fabric-baseos Mirror is in the peer node when compiling chaincode, it needs to Baseos as a compilation environment in the base of an OS

9, Balance-transfer is a complete use of the fabric-node-sdk of a client side, it can interact with the blockchain peer,orderer, it can go to configure Orderer, create channel, it can go to configure peer, It is possible to have the peer node join the channel. It can be understood that all of the tasks previously available through the CLI can be done under the SDK and are more powerful because the SDK is programmable.

10, the digital certificate contains the original text of the certificate, cryptographic hashing algorithm and the CA private key signed certificate cipher three parts. When verifying the validity of a digital certificate, you only need to know the public key of the certificate's issuing organization/authority (CA). In addition, the public key asymmetric encryption algorithm in PKI system public key decryption scenario will occur only in one case, that is, when the digital certificate validity check/digital signature verification.