you don't have to write to the same key.

You can have each voter / bidder commit to his vote / bid by writing to a separate key that corresponds to its identity, and in the end have all the voters / bidders reveal their votes / bids, and this will not create any MVCC conflicts.



From:        "Mr.Phuwanai Thummavet" <mr.thummavet@...>
To:        fabric@...
Date:        10/23/2019 12:16 PM
Subject:        [EXTERNAL] [Hyperledger Fabric] How to manage the Multi-Version Concurrency Control (MVCC) in Fabric on time-critical applications
Sent by:        fabric@...

---

Hi everyone,

I know that the multi-version concurrency control (MVCC) is used to address double-spending problems in Fabric. However, the MVCC might become one of the most obstacles when designing time-critical applications such as auction and voting systems. On a voting system, for example, two voters commit to voting for the same candidate in the same block-time frame. This results in an invalid transaction for the 2nd voter according to the MVCC.

My solution to such an issue was to use an off-chain messaging queue system to gather and categorize certain transaction requests from clients. Then, the batches of the categorized transactions were sent to a chaincode to invoke.

Here are my questions:
1.        Was my solution suitable for the above example? 
2.        Does anyone have better solutions?
3.        Is Hyperledger Fabric suitable for real-time applications such as auction and voting systems?

Thanks.

--
Best Regards,
Phuwanai Thummavet