Hyperledger Fabric Chain code Start-up process implementation

Note: This article was first published on 2017-09-22.

Hyperledger source code Analysis of Fabric introduction

The Chaincode is the user chaincode,ucc, which is important for application developers, and it provides state processing logic based on the blockchain distributed ledger, which can be used to develop a variety of complex applications.

Hyperledger Fabric, Chaincode runs in the Docker container by default. 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. Typical structure

The following gives the typical structure of the chain code, where the user only needs to focus on the implementation of the Init () and Invoke () functions, in which the shim is used. Chaincodestubinterface structure that 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 the using stub here
	return stub. Success (nil)
}func (t *demochaincode) Invoke (stub shim. Chaincodestubinterface) PB. Response
	//More logics the 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. The overall boot process is shown in the following figure.

Initialization is done first. Includes reading the default configuration, creating a GRPC connection to Peer, mainly including newchaincodesupportclient (CC *GRPC. Clientconn) and Chaincodesupportclient.register (CTX context. Context, opts ... grpc. Calloption) Two methods.

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 migration (nextstate) message.

In the follow-up process, Chaincode and Peer use the FSM to perform a series of response operations to the message, as shown below.

Peer receives a chaincodemessage_register message from the chain Code container, registers it to a local Handler structure, and returns chaincodemessage_registered message to the chain Code container. The update status is established, and the Chaincodemessage_ready message is sent to the link side, and the update status is ready.

The link code side receives the chaincodemessage_registered message, does not do any operation, the registration succeeds. The update status is established. The update status is ready after you receive the Chaincodemessage_ready message.

Peer sends a CHAINCODEMESSAGE_INIT message to the chain Code container, ready to trigger the link-side initialization operation.

The Chain code container receives the CHAINCODEMESSAGE_INIT message and initializes it through 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.

When a chain code is called, Peer sends a chaincodemessage_transaction message to the chain code.

The link code receives the Chaincodemessage_transaction message and invokes the Invoke () method, which, depending on the user-implemented logic in the Invoke method, can emit 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 call completion message chaincodemessage_complete to the Peer side.

In the above process, Peer and link side also periodically send chaincodemessage_keepalive messages to each other to ensure that each other is online.

=====================================

"Blockchain principle, design and application" book has been formally published, taking the super-Ledger project as an example, introduced the blockchain and distributed ledger technology, the underlying principles, design architecture, application of a lot of details of the practice, welcome to read correct.

===== about Techfirst Public number =====

Focus on financial technology, artificial intelligence, cloud computing, big data-related areas of popular technology and forward-looking direction.

Send keywords (such as blockchain, cloud computing, Big Data, AI) to get hot reviews and technical dry goods.

Welcome to contribute.

If you like the public, please encourage a cup of coffee~