some Questions about hyper ledger fabric chaincodes


elmira
 

Hi

I have a few questions; I would be very grateful if you could answer them.

(Some questions may be wrong due to my low experience. I would be grateful if you could guide me to understand my mistake.)

 

1) Is it possible that transactions are not executed in the order we intend? (trouble at the business level). For example, Transaction 1 called an external service earlier than Transaction 2, but Transaction 2's response came earlier and changed the blockchain state, which causes a situation that we do not want. More precisely, are these external calls asynchronous, or are they in order and synchronous?

I found out from the documentation that the transactions are asynchronous so, I think this may happen, but I did not find an example of it, and I do not know how to deal with this issue.

When the block is sent to the validator nodes by orderers, are the transactions validated in order that they placed in block, or can they validate transactions asynchronously?

 

2) according to some articles, concurrency (using goroutine and go channel) can cause non-deterministic behavior.

I have not found any source or example on the use of Goroutines and go channels in fabric contracts;I need an example. I need to know how concurrency in the fabric contracts causes inconsistency in it.

I know that it is better not to use the following code, but I want to know how the race condition that is in the code causes inconsistency 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))

 

}

 

3) In Hyperledger Fabric, Read-Your-Write semantics are not supported. Hence, if a transaction reads a key value, the committed state's value is returned even if the transaction has updated the value for the key before issuing the read.

Can we use mutual exclusion for our code's critical part to prevent invalid transactions resulting from outdated data due to a lack of support for Read-Your-Writing semantics? Or is there a better way, in your opinion?

 Always be in perfect health.

With respect,

Elmira

Join fabric@lists.hyperledger.org to automatically receive all group messages.