toggle quoted messageShow quoted text
I understand your point. In the case of the auction system, nevertheless, how can I get the best current price when I do transaction queries. Maybe I have to use the range-based queries to seek the best price every time there is a query? I think that would affect system performance if there are a lot of queries. I also concern about querying time in the case that the system gets massive adoption.
On Wed, Oct 23, 2019 at 4:21 PM Yacov Manevich <YACOVM@...
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.
10/23/2019 12:16 PM
Fabric] How to manage the Multi-Version Concurrency Control (MVCC) in Fabric
on time-critical applications
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
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
Here are my questions:
my solution suitable for the above example?
anyone have better solutions?
Hyperledger Fabric suitable for real-time applications such as auction
and voting systems?
Blockchain Architect and Full-Stack Developer