1. #fabric
  2. How to confirm a transaction?

Re: How to confirm a transaction? #fabric

Joe Alewine <joe.alewine@...>
 

That's my understanding as well, that two transactions modifying a single key can't be in a single block. But with what I'm proposing, there's no reason it couldn't be as long as the total number of assets being bought doesn't exceed the current number available. So if 1000 Macbooks are available and one retailer puts in an order for 300 simultaneous to another putting in an order for 400, why couldn't those both be in the same block? The question, "are there are least 700 Macbooks available" is yes.
 
This kind of thing would require a final check in any case where a key is being modified twice (with timestamps on the proposals within the block to determine which proposal came first in case of a conflict), but operationally it makes sense as a thing that should be a allowed. Again, the key question is the not the total number of available Macbooks. It's whether there enough Macbooks *available* to complete the transaction. That's all that really matters. That's all that should be checked with these kinds of bulk items (whether it's produce or Macbooks).
 
I don't understand why this would render the endorsement stage meaningless. Perhaps I'm misunderstanding you.
 
Regards,
 
Joe Alewine
IBM Blockchain, Raleigh
 
rocket chat: joe-alewine
slack: joe.alewine
 
 
 

----- Original message -----
From: "Wenbo Hu" <huwenbo1988@...>
Sent by: fabric@...
To: fabric@...
Cc:
Subject: Re: [Hyperledger Fabric] How to confirm a transaction? #fabric
Date: Wed, Jun 6, 2018 12:08 PM
 
Joe,
   Ticket system should be a better use case for my solution.
  And another problem is that end user should not directly get involved with the ledger. All operations should be requested by certified members. That's why I prefer to generate the stock locally. But yes, it's wasteful.
   Back to the simple bank account ledger, according to our dissdiscus, fabric doesn't support multiple transactions on the same account within one single block, is that right? It seems to be a critical problem.
   If the transactions are validating based on the most recent transaction at VSCC/MVCC stage, the endorsement stage is meaningless. Transactions are not spread and unordered at that stage, so endorse peer nodes are not able to determine the result. Then this is a mechanism problem.
 
Join fabric@lists.hyperledger.org to automatically receive all group messages.