Chaincode debugging in Hyperledger Fabric

Good afternoon, dear habrozhiteli and especially those who are more or less interested in the blockchain. It so happened that when I came to work as a java-developer at one company, I had to deal with projects using the blockchain.

About the blockchain itself, its features and various implementations on the Internet, and on Habré in particular, you can find a ton of information. But the deeper the questions, the less answers to them. In the official documentation of the fabric, there is very little information about debugging, and the one that is is that you would just log the entire code and see what went wrong. IBM Russian-speaking developers responded the same way. So this article will highlight one of our former problems associated with debugging the cheyncode in one of the Hyperledger projects, namely Fabric (v0.6).

The changecode in the fabric is nothing more than the usual smart contract. A chejncode can be written in Go, Java, and, in the near future, JavaScript. The article discusses the implementation of cheyncode on Go, but I think this approach is also suitable for Java implementations.

A few prefaces about how to use cheyncode from the side of the node:

1. Noda receives a request for a deployment → searches for a docker-container → if it does not find it, then it creates a new docker-container with a cheyncode inside; if it finds one, it uses it
2. After the creation of the container, it runs the executable file of the cheyncode, which is connected via gRPC to the node and starts listening to its instructions
3. When a Invoke / Query query arrives at a node, it simply sends commands to the connected executable files, they process them and send the result back.

Accordingly, initially we were looking for a way to deceive a node so that it would not search for a container, but this was not successful. A quick reading of the docker-compose files revealed an interesting parameter - CORE_CHAINCODE_MODE, with which you can make the node not to create or search containers, but just to trust the environment.

So, as the medium will be used:

• 1 node as membersrvc
• 1 node as validation peer (further VP)
• Intellij Idea with Go Plugin

I will not describe how to raise the environment, since there is a lot of documentation on deployment, it is worth mentioning some features:

Since only 1 VP is used, the PBFT consensus algorithm, which is used by default, does not suit us. To do this, in the configuration (docker-compose file) you need to add a parameter
CORE_PEER_VALIDATOR_CONSENSUS_PLUGIN = noops .

Now you need to specify that our environment should be running in the dev-mode, for this you need to set the parameter CORE_CHAINCODE_MODE = dev .

It is also necessary to port ports 7050 (used for REST API node) and 7051 (used for gRPC connection to node).

This completes the necessary parameters, the rest can be configured at your discretion.

As an example, we will use an example of a cheyncode from the official Hyperledger repository, namely the map.

We now turn to the environment settings. For this you need to set 2 parameters, namely:

1. Specify the Environment variable - CORE_CHAINCODE_ID_NAME = mapCC
2. Specify the launch argument -peer.address = ip: gRpcPort

Instead of "mapCC" you can specify any name for the chincode. After that, you need to run the cheyncode through the main method in debug mode. The IDE should display the following information:

13: 36: 57.675 [shim] DEBU: Peer address: 192.168.1.1:7051
13: 36: 57.676 [shim] DEBU: os.Args returns: [C: \ Users \ vasya \ AppData \ Local \ Temp \ Build map.go and rungo -peer.address = 192.168.1.1: 7051]
13: 36: 57.701 [shim] DEBU: Registering ... sending REGISTER
13: 36: 57.702 [shim] DEBU: [] Received message REGISTERED from shim
13: 36: 57.702 [shim] DEBU: [] Handling ChaincodeMessage of type: REGISTERED (state: created)
13: 36: 57.702 [shim] DEBU: Received REGISTERED, ready for invocations

Next, you need to send a deployment command to the node.

curl -X POST --header "Content-Type: application / json" --header "Accept: application / json" -d "{
\ "jsonrpc \": \ "2.0 \",
\ "method \": \ "deploy \",
\ "params \": {
\ "type \": 1,
\ "chaincodeID \": {
\ "name \": \ "mapCC \"
},
\ "ctorMsg \": {
\ "function \": \ "init \"
},
\ "secureContext \": \ "test_user0 \"
},
\ "id \": 1
} "ip: RESTPort / chaincode

Information will appear in the IDE

13: 37: 12.038 [shim] DEBU: [mapCCId2] Received message INIT from shim
13: 37: 12.038 [shim] DEBU: [mapCCId2] Handling Chaincode Message of type: INIT (state: established)
13: 37: 12.038 [shim] DEBU: Entered state init
13: 37: 12.038 [shim] DEBU: [mapCCId2] Received INIT, initializing chaincode
13: 37: 12.038 [shim] DEBU: [mapCCId2] Init succeeded. Sending COMPLETED
13: 37: 12.038 [shim] DEBU: [mapCCId2] Move state message COMPLETED
13: 37: 12.038 [shim] DEBU: [mapCCId2] Handling Chaincode Message of type: COMPLETED (state: init)
13: 37: 12.038 [shim] DEBU: [mapCCId2] send state message COMPLETED

After that, you can set breakpoint in any right place and debug by sending Invoke / Query requests. I think I don’t need to write about them, everything is almost the same as Init-requests.

On this article comes to an end, please don’t beat me strongly with my hands and feet, I’m just a junior and this is my first article on Habré and I hope she will help someone since I haven’t found such an article anywhere.