Topics

#fabric-orderer #fabric-chaincode #fabric-chaincode #fabric-orderer


marco.comuzzi@...
 

I have a question regarding the ordering of transactions changing the value of the same variable in the world state:

Lets' assume that the 2 clients C1 and C2 submit two transactions (T1 submitted from C1 and T2 submitted from C2) that modify the value of the same variable "v" (identified by key "k"). Let's also assume, for simplicity, that for both T1 and T2 have an empty read set.

As far as I understand (reading [1]), both transactions will be endorsed by the endorsing peers, because they do not violate the "read your writes" policy.
However, what determines the order in which T1 and T2 will be included in block(s) and, therefore, what determine which will be the value of the variable "v" after both transactions are validated and committed by peers?

(I guess that in case T1 and T2 are submitted by the same client, then the orderer service will follow the timestamp to determine the correct order. The client must in fact timestamp the transactions progressively. I am not sure what happens when such transactions are originated from different clients)

Thank you
Marco

[1]  https://hyperledger-fabric.readthedocs.io/en/release-2.0/readwrite.html


Adhav Pavan
 

Hello Marco,

When committing a peer to get block from the orderer, first it validates the block signature(Signed by orderer). If the orderer is valid, then committing peers to decode all transactions from the block.
It goes through VSCC(validate System Chaincode- checks if the transaction has sufficient endorsement policy as per Endorsement policy)  and if transaction do not satisfy this policy, it will be marked as invalid.
Once Successful validation of VSCC, peer check for MVCC(Multiversion concurrency control), for each transaction, it checks the existing version of the asset(Key), if this is a new asset, peer update current state database with version vo, when it picks second transaction(Same asset), it checks if state database has it, if it has, the peer checks the existing version of the asset (T1 updated asset with vo), but T2 has written with vo, so it will get rejected and generally we get MVCC conflicts error.

Guys, Please correct me if I am wrong somewhere.

Thank you.
 

Heartfelt Regards,

Pavan Adhav
Blockchain Developer, Infinichains
phone:  8390114357
email:  pavan@...
------
Please excuse my brevity.


On Sat, May 9, 2020 at 7:16 PM <marco.comuzzi@...> wrote:
I have a question regarding the ordering of transactions changing the value of the same variable in the world state:

Lets' assume that the 2 clients C1 and C2 submit two transactions (T1 submitted from C1 and T2 submitted from C2) that modify the value of the same variable "v" (identified by key "k"). Let's also assume, for simplicity, that for both T1 and T2 have an empty read set.

As far as I understand (reading [1]), both transactions will be endorsed by the endorsing peers, because they do not violate the "read your writes" policy.
However, what determines the order in which T1 and T2 will be included in block(s) and, therefore, what determine which will be the value of the variable "v" after both transactions are validated and committed by peers?

(I guess that in case T1 and T2 are submitted by the same client, then the orderer service will follow the timestamp to determine the correct order. The client must in fact timestamp the transactions progressively. I am not sure what happens when such transactions are originated from different clients)

Thank you
Marco

[1]  https://hyperledger-fabric.readthedocs.io/en/release-2.0/readwrite.html


David Enyeart
 

Not quite...

MVCC in validation/commit phase checks the chaincode execution readset key version against current state key version to ensure that the execution results are still valid. Therefore if the chaincode did a read then write of the same key in both transactions, it would behave as Adhav mentions (the transaction that gets ordered later would be invalidated, and would need to be resubmitted for endorsement/ordering by the client).

If the chaincode does a write only without first reading the key, this is called a 'blind write'. In the case of a blind write, there is no readset for the MVCC version check, and therefore both transactions will perform a valid write. The end result would be that T1 writes the key state, and then T2 overwrites the key state - last update 'wins'. This is true regardless of whether the transactions were ordered in the same block or in different blocks.

So in most use cases, you'll want the chaincode to read before writing, to ensure colliding transactions don't go undetected.

The ordering service simply orders transactions as they arrive, it makes no attempt to order transactions based on timestamps or any other intelligence. The timestamp that the client adds to the transaction is just for reference, it is not used by ordering service or any other component for that matter.


Dave Enyeart

"Adhav Pavan" ---05/09/2020 01:06:40 PM---Hello Marco, When committing a peer to get block from the orderer, first it validates

From: "Adhav Pavan" <adhavpavan@...>
To: marco.comuzzi@..., hyperledger-fabric <hyperledger-fabric@...>
Date: 05/09/2020 01:06 PM
Subject: [EXTERNAL] Re: [Hyperledger Fabric] #fabric-orderer #fabric-chaincode
Sent by: fabric@...





Hello Marco,

When committing a peer to get block from the orderer, first it validates the block signature(Signed by orderer). If the orderer is valid, then committing peers to decode all transactions from the block.
It goes through VSCC(validate System Chaincode- checks if the transaction has sufficient endorsement policy as per Endorsement policy)  and if transaction do not satisfy this policy, it will be marked as invalid.
Once Successful validation of VSCC, peer check for MVCC(Multiversion concurrency control), for each transaction, it checks the existing version of the asset(Key), if this is a new asset, peer update current state database with version vo, when it picks second transaction(Same asset), it checks if state database has it, if it has, the peer checks the existing version of the asset (T1 updated asset with vo), but T2 has written with vo, so it will get rejected and generally we get MVCC conflicts error.

Guys, Please correct me if I am wrong somewhere.

Thank you.
 

Heartfelt Regards,

Pavan Adhav
Blockchain Developer, Infinichains
phone:  8390114357
email:  pavan@...
------
Please excuse my brevity.


On Sat, May 9, 2020 at 7:16 PM <marco.comuzzi@...> wrote:

    I have a question regarding the ordering of transactions changing the value of the same variable in the world state:

    Lets' assume that the 2 clients C1 and C2 submit two transactions (T1 submitted from C1 and T2 submitted from C2) that modify the value of the same variable "v" (identified by key "k"). Let's also assume, for simplicity, that for both T1 and T2 have an empty read set.

    As far as I understand (reading [1]), both transactions will be endorsed by the endorsing peers, because they do not violate the "read your writes" policy.
    However, what determines the order in which T1 and T2 will be included in block(s) and, therefore, what determine which will be the value of the variable "v" after both transactions are validated and committed by peers?

    (I guess that in case T1 and T2 are submitted by the same client, then the orderer service will follow the timestamp to determine the correct order. The client must in fact timestamp the transactions progressively. I am not sure what happens when such transactions are originated from different clients)

    Thank you
    Marco

    [1]  https://hyperledger-fabric.readthedocs.io/en/release-2.0/readwrite.html





marco.comuzzi@...
 

Thank you! That's very helpful.

In particular, I see now how dangerous the "blind write" can be. 

Regards,
Marco


Rob Murgai
 

I am curious, what use case would require a blind-write vs a read-write? 

S Rob Murgai
Program Director - Hyperledger Fabric 
IBM Blockchain
Raleigh-Durham, NC
M: 919.342.8432 LinkedIn: Rob-Murgai
 
 

----- Original message -----
From: marco.comuzzi@...
Sent by: fabric@...
To: fabric@...
Cc:
Subject: [EXTERNAL] Re: [Hyperledger Fabric] #fabric-orderer #fabric-chaincode
Date: Sun, May 10, 2020 7:36 PM
 
Thank you! That's very helpful.

In particular, I see now how dangerous the "blind write" can be. 

Regards,
Marco
 


David Enyeart
 

I think most use cases will want the read-write behavior.
Append-only use cases may want the blind write behavior. For example consider an IOT sensor that records a data point hourly. There isn't really a need to detect collisions. Performance would be better if you did blind writes, and in the rare case a sensor sent the same data point twice, having the later transaction overwrite the first would be acceptable.


Dave Enyeart

"Rob Murgai" ---05/11/2020 02:58:09 PM---I am curious, what use case would require a blind-write vs a read-write? S Rob Murgai

From: "Rob Murgai" <murgai@...>
To: marco.comuzzi@...
Cc: fabric@...
Date: 05/11/2020 02:58 PM
Subject: [EXTERNAL] Re: [Hyperledger Fabric] #fabric-orderer #fabric-chaincode
Sent by: fabric@...





I am curious, what use case would require a blind-write vs a read-write?

S Rob Murgai
Program Director - Hyperledger Fabric
IBM Blockchain
Raleigh-Durham, NC
M: 919.342.8432 | LinkedIn: Rob-Murgai


----- Original message -----
From: marco.comuzzi@...
Sent by: fabric@...
To: fabric@...
Cc:
Subject: [EXTERNAL] Re: [Hyperledger Fabric] #fabric-orderer #fabric-chaincode
Date: Sun, May 10, 2020 7:36 PM

Thank you! That's very helpful.

In particular, I see now how dangerous the "blind write" can be.

Regards,
Marco