Fabric Source Learning Note 2-chaincode startup process

This is a creation in Article, where the information may have evolved or changed.

Brief introduction

Chaincode is the user chain code, which provides state processing logic based on the blockchain distributed ledger.
Fabric, Chaincode is run by default in the Docker container.
Peer creates and launches the Chaincode container by calling the Docker API.
Chaincode A GRPC connection is created between the container and peer, and both parties communicate interactively by sending Chaincodemessage.
The Chaincode container uses the interface provided by the Core.chaincode.shim package to initiate a request to the peer.

CHAINCODE Typical structure

The user only has to focus on the implementation of the Init () and Invoke () functions, in which the shim is used. The chaincodestubinterface structure implements the interaction logic with the ledger.

package mainimport (    "errors"    "fmt"    "github.com/hyperledger/fabric/core/chaincode/shim")type DemoChaincode struct { }func (t *DemoChaincode) Init(stub shim.ChaincodeStubInterface) pb.Response {    // more logics using stub here    return stub.Success(nil)}func (t *DemoChaincode) Invoke(stub shim.ChaincodeStubInterface) pb.Response    // more logics using stub here    return stub.Success(nil)}func main() {    err := shim.Start(new(DemoChaincode))    if err != nil {        fmt.Printf("Error starting DemoChaincode: %s", err)    }}

startup process

Chaincode first is an ordinary Golang program, whose main method calls the Start method of the shim layer.
Initialization is done first, including reading the default configuration and creating a GRPC connection to the peer.
Mainly includes two methods of Newchaincodesupportclient and Chaincodesupportclient.register.
After initialization is complete, create a finite state machine structure (FSM,GITHUB.COM/LOOPLAB/FSM).
The FSM triggers a state transition based on the received message and the current state, and performs the action set in advance.
Peer-side also uses a similar FSM structure to manage message responses.
After that, the first GRPC message is sent to the peer using the created GRPC connection: Chaincodemessage_register, registering itself on the peer.
After the registration succeeds, the message processing loop is started, waiting to receive the message from peer and its own state transfer (NEXTSTATE) message.

In the follow-up process, Chaincode and peer use the FSM to perform a series of response operations on the message:
1, peer receives the Chaincodemessage_register message from the chain Code container, registers it to a local handler structure, returns CHAINCODEMESSAGE_REGISTERD message to the chain Code container.
After the update status is established (established), and the Chaincodemessage_ready message is sent to the link side, the update status is ready.
2, Link code side received Chaincodemessage_registerd message, do not take any action, registration success, update status of established (established).
The update status is ready after you receive the Chaincodemessage_ready message.
3, Peer sends Chaincodemessage_init message to the chain Code container, ready to trigger the link code side initialization operation.
4. The Chain code container receives the CHAINCODEMESSAGE_INIT message and initializes it via the Handler.handleinit () method.
This includes the CHAINCODESTUB structure required for initialization, and the Init () method in the call chain code. After the initialization succeeds, the chaincodemessage_completed message is returned to peer.
At this point the chain code container enters the callable (invoke) state.
5, when the chain code is called, Peer sends Chaincodemessage_transaction message to the chain code.
6, the link code receives the chaincodemessage_transaction message, will call the Invoke () method.
Depending on the user-implemented logic in the Invoke method, you can issue a chaincodemessage_get_history_for_key, Chaincodemessage_get_query_result,
Chaincodemessage_get_state, Chaincodemessage_get_state_by_range, Chaincodemessage_query_state_close,
Chaincodemessage_query_state_next, Chaincodemessage_invoke_chaincode and other messages to peer side.
Peer receives these messages, handles them accordingly, and responds to chaincodemessage_response messages.
Finally, the link-side will reply to the message that the completion of the call Chaincodemessage_complete to peer side.
In the above process, peer and chain code will also send chaincodemessage_keepalive messages to each other periodically to ensure online.

Related documents

Https://github.com/yeasy/hyperledger_code_fabric/blob/master/process/chaincode_start.md