Blockchain Technology Series (iii)-Fabric protocol Introduction

The point-to-point (peer-to-peer) communication of fabric is built on a stream-based message grpc that allows bidirectional flow. It uses protocol buffers to serialize the data structure that is transferred between peer. Protocol buffers is a language-independent, platform-independent technology that has an extensible mechanism to serialize structured data. Data structures, messages, and services are described using PROTO3 language annotations. 3.1 News

Messages are passed between nodes through the Messageproto structure encapsulation, which can be divided into 4 types: Discovery (Discovery), Trade (Transaction), Synchronization (synchronization), and consensus (Consensus). Each type defines a multiple seed type in payload.

message message {enum Type {UNDEFINED = 0;
        Disc_hello = 1;
        Disc_disconnect = 2;
        Disc_get_peers = 3;
        Disc_peers = 4;

        Disc_newmsg = 5;
        Chain_status = 6;
        Chain_transaction = 7;
        Chain_get_transactions = 8;

        Chain_query = 9;
        Sync_get_blocks = 11;
        Sync_blocks = 12;

        sync_block_added = 13;
        Sync_state_get_snapshot = 14;
        Sync_state_snapshot = 15;
        Sync_state_get_deltas = 16;

        Sync_state_deltas = 17;
        RESPONSE = 20;
    CONSENSUS = 21;
    } Type type = 1;
    Bytes payload = 2;
Google.protobuf.Timestamp Timestamp = 3; }

Payload is an opaque byte array of objects, such as transaction or response, that are contained by different message types. For example: type is chain_transaction so payload is a transaction object. 3.1.1 Discovery Message

At boot time, if Core_peer_discovery_rootnode is specified, PEER will run the discovery protocol. Core_peer_discovery_rootnode is the IP address of another peer in the network (any peer) that plays the starting role for discovering all peers. The protocol sequence with payload is a containing:

Message HelloMessage {
  Peerendpoint peerendpoint = 1;
  UInt64 blocknumber = 2;
}
Message peerendpoint {
    Peerid ID = 1;
    string address = 2;
    Enum Type {
      UNDEFINED = 0;
      VALIDATOR = 1;
      Non_validator = 2;
    }
    Type type = 3;
    Bytes pkiid = 4;
}

Message Peerid {
    string name = 1;
}

The Disc_hello message of the HelloMessage object for such an endpoint begins.

Domain definition: Peerid is an arbitrary name for the peer defined in the startup or configuration file Peerendpoint describes the endpoint and whether it is authenticated or non-authenticated peer Pkiid is the peer's encryption ID address to Ip:port in this format The host name or IP and Port blocknumber is the current height of the peer's blockchain

If the height of the block of the received Disc_hello message is higher than the height of the current peer's block, then it initializes the synchronization protocol immediately to catch up with the current network.

After Disc_hello, peer periodically sends disc_get_peers to discover any peer that wants to join the network. When Disc_get_peers is received, peer sends the disc_peers of the array containing the peerendpoint as a response payload. This is not used for other discovery message types. 3.1.2 Trading Messages

There are three different types of transactions: Deployment (Deploy), Invoke (Invoke), and queries (query). The deployment transaction installs the specified chain code on the chain, invokes and queries the trade fair to invoke the chain code of the deployment number. Another type to consider is creating (create) transactions where the deployed chain code can be instantiated and addressed on the chain. This type is not yet implemented when writing this document. data structures for 3.1.2.1 transactions

Messages of type chain_transaction and Chain_query are payload with transaction objects:

message Transaction {enum Type {UNDEFINED = 0;
        Chaincode_deploy = 1;
        Chaincode_invoke = 2;
        Chaincode_query = 3;
    Chaincode_terminate = 4;
    } Type type = 1;
    string uuid = 5;
    Bytes Chaincodeid = 2;

    Bytes Payloadhash = 3;
    Confidentialitylevel confidentialitylevel = 7;
    Bytes Nonce = 8;
    Bytes cert = 9;

    Bytes Signature = 10;
    Bytes metadata = 4;
Google.protobuf.Timestamp Timestamp = 6;

} message transactionpayload {bytes payload = 1;}
    Enum Confidentialitylevel {public = 0;
confidential = 1; }

The definition of a domain: type-the types of trades, represented as 1: UNDEFINED-reserved for future use. Chaincode_deploy-Represents the deployment of a new chain code. Chaincode_invoke-Represents a chain code function that is executed and modifies the world state Chaincode_query-a chain code that represents a chain code function that is executed and may read only the world state chaincode_terminate-tag is not available, So the function in the chain code will not be called Chaincodeid-chain code source, path, constructor and parameter hash obtained by the ID payloadhash-transactionpayload.payload defined by the hash byte. Metadata-the application may use any trade-related metadata UUID that is defined by itself-the unique ID of the transaction timestamp-peer the time stamp to receive the transaction Confidentialitylevel-the level of data privacy. There are currently two levels. There may be multiple levels in the future. Nonce-For security use Cert-Trader's certificate signature-trader's signature transactionpayload.payload-the byte defined by the payload of the trade. Since the payload can be very large, the transaction message contains only the hash of the payload

Details of the transaction security can be found in section Fourth of the 3.1.2.2 trading specification

A transaction is usually linked to a chain code definition and its execution environment (like the language and security context) of the chain code specification. Now, there is an implementation that uses the go language to write the chain code. New languages may be added in the future.

Message Chaincodespec {
    enum Type {
        UNDEFINED = 0;
        Golang = 1;
        NODE = 2;
    }
    Type type = 1;
    Chaincodeid Chaincodeid = 2;
    Chaincodeinput ctormsg = 3;
    Int32 timeout = 4;
    string securecontext = 5;
    Confidentialitylevel confidentialitylevel = 6;
    Bytes metadata = 7;
}

Message Chaincodeid {
    string path = 1;
    String name = 2;
}

Message Chaincodeinput {
    string function = 1;
    Repeated string args  = 2;
}

Domain definition: chaincodeid-chain Code source path and name Ctormsg-Call Function name and parameter timeout-the time required to execute the exchange (in milliseconds) Confidentialitylevel-the level of secrecy of this transaction secureconte XT-Trader's security context metadata-apply any data that you want to pass down

When peer receives CHAINCODESPEC, it wraps it with the appropriate transaction message and broadcasts it to the network 3.1.2.3 to deploy the transaction

The type of deployment transaction is Chaincode_deploy, and its payload contains Chaincodedeploymentspec objects.

Message Chaincodedeploymentspec {
    Chaincodespec chaincodespec = 1;
    Google.protobuf.Timestamp effectivedate = 2;
    Bytes Codepackage = 3;
}

Definition of domain: CHAINCODESPEC-see section 3.1 above. 2.2. Effectivedate-chain code ready to be called time Codepackage-chain code of the source of gzip

When verifying peer deployment chain code, it usually verifies the hash of the codepackage to ensure that the transaction has not been tampered with after it has been deployed to the network. 3.1.2.4 Call Transaction

The type of the call transaction is Chaincode_deploy, and its payload contains the Chaincodeinvocationspec object.

Message Chaincodeinvocationspec {
    Chaincodespec chaincodespec = 1;
}

3.1.2.5 Inquiry Trading

Query transactions except that the message type is chaincode_query other and invokes the transaction as 3.1.3 Synchronous message

The synchronization protocol is described in section 3.1.1, when peer knows that its own chunks are behind other peers or are not the same as they were initiated. Peer broadcasts Sync_get_blocks,sync_state_get_snapshot or Sync_state_get_deltas and receives sync_blocks, Sync_state_snapshot, or Sync_ respectively State_deltas.

The installed consensus plugin (for example: PBFT) determines how the synchronization protocol is applied. Each hour is designed for a specific state:

Sync_get_blocks is a Syncblockrange object that contains a continuous chunk of the range of payload requests.

Message Syncblockrange {
    UInt64 start = 1;
    UInt64 end = 2;
    UInt64 end = 3;
}

The receiving peer responds with the sync_blocks information of the payload that contains the Syncblocks object

Message Syncblocks {
    Syncblockrange range = 1;
    Repeated Block blocks = 2;
}

Start and end identify the starting and ending of the chunks that are contained, and the order of the returned chunks is defined by the value of start and end. For example, when start=3,end=5, the order of the chunks will be 3,4,5. When start=5,end=3, the order of the chunks will be 5,4,3.

Sync_state_get_snapshot requests a snapshot of the current world state. Payload is a Syncstatesnapshotrequest object

Message syncstatesnapshotrequest {
  UInt64 correlationid = 1;
}

Correlationid is the request that peer uses to track response messages. Accept peer reply payload to sync_state_snapshot information for Syncstatesnapshot instance

Message syncstatesnapshot {
    bytes delta = 1;
    UInt64 sequence = 2;
    UInt64 blocknumber = 3;
    Syncstatesnapshotrequest request = 4;
}

This message contains a snapshot or a chunk of the snapshot stream sequence starting at 0. The terminating message is a block of len (delta) = = 0

Sync_state_get_deltas requests the state change of contiguous chunks. By default, the General Ledger maintains 500 trade changes. Delta (J) is a state transition between block (i) and Block (j), where I=j-1. Payload contains syncstatedeltasrequest instances