Hyperledger Fabric Chaincode Development Best Practices

[former_member231477]

Smart contract or chaincode developers should adhere to strict development guidelines and rules.

With Turing complete languages like Go Lang becoming the defacto standard for chaincode development and high interest from developers to get into this exciting space.

I am writing down some of the Don’ts and Best Practices to consider while developing your chaincode.

Read After Write

func addToAccount(stub shim.ChaincodeStubInterface, account *string, amount int){

balance,_ := stub.GetState(*account)

stub.PutState(*account, balance + amount)

}



func (t *SimpleChaincode) Invoke(stub shim.ChaincodeStubInterface)

pb.Response {



args := stub.GetArgs()

// assume args match addToAccount

addToAccount(stub,"AccountNo1", args[0])

// babalce == 150

// do more actions

addToAccount(stub,"AccountNo1", args[1])

// balance == 175

return shim.Success(nil)

}

Assume initial balance of 100 and inputs of [50,25],
What is the end state value of the balance ?

> 125,150,175 ???

> Note here that the first PutState isn't written/committed to the ledger until
the transaction finishes successfully. Hence the next GetState will return the initial state value.

Don't Ignore error handling

Range Iterations over maps are not deterministic

Using range to iterate over the entries of a map is not deterministic. Consistency over peers is therefore not guaranteed.

type BadChaincode struct{

}



var myMap = map[int]int{

1:1,

2:5,

3:10,

4:50,

}



func (t *BadChaincode) Invoke (stub shim.ChaincodeStubInterface) peer.Response{

returnValue := 0

for i,ii := range myMap{

returnValue = returnValue * i - ii

}

return shim.Success([]byte("value: " + string(returnValue)))

}

 

Validate the number of arguments before use

The number of arguments received from a client must be validated inorder not to use non existent element.

 

func (t *BadChaincode) Invoke(stub shim.ChaincodeStubInterface) peer.Response {

args := stub.GetStringArgs()

// by assuming passed len(args) == 2 but only 1 argument is passed

result,err := stub.GetState(args[0])

if err != nil{

return shim.Error(err.Error())

}else {

return shim.Success(result)

}

}

 

Blacklisted Imports

Libraries such as time,file access that allow access to the real world can lead to non determinism

Global Declarations

Global declared values are not stored on the ledger and can have different values among peers since peers don't need to execute the chaincode for every transaction.
Global states should be managed over the ledger.

package main

import (

"fmt"

"github.com/hyperledger/fabric/core/chaincode/shim"

"github.com/hyperledger/fabric/protos/peer"

)



var globalValue = ""



func (t *BadChaincode) Invoke(stub shim.ChaincodeStubInterface){



}

Phantom Reads

Reading the ledger with GetHistoryOfKey or GetQueryResult do not pass the versioning control of the system. Data received from phantom reads should therefore not be used to write new data or update data on the ledger.

iterator,_ := stub.GetHistoryForKey("key")

data,_ := iterator.Next()

err, := stub.PutState("key", data.Value)

 

Go Routines

The use of concurrency can lead to non deterministic behavior. The result is a non consistent among peers.

package main

import (

"fmt"

"github.com/hyperledger/fabric/core/chaincode/shim"

"github.com/hyperledger/fabric/protos/peer"

)

type BadChainCode struct{

}

func (t *BadChainCode) Invoke(stub shim.ChaincodeStubInterface){

go writeToLedger(stub, "data1")

go writeToLedger(stub, "data2")

}



func writeToLedger(stub shim.ChaincodeStubInterface, data string){

stub.PutState("key",[]byte(data))

}

 

Last words: Have your development reviewed by an experienced blockchain developer to avoid loss of resources

Disclaimer : This is not intended to be an exhaustive list so don’t treat it as one.