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

Re: How to confirm a transaction? #fabric

Kim Letkeman <kletkema@...>
 

Joe,

So what you are saying is that you want the database to have some kind of built in mechanism that does not require that the chaincode do a read->update->write cycle, but instead decrements the key by the amount requested. So let's look at the flow to see how it helps us ... because intuitively, it offers us the ability to say for sure that there are not enough to satisfy the request.

So at endorsement time, no read set is created, but the write set is still created. Each of the transactions executing in parallel will record the operation and immediately exit successfully. Later, they will all execute in some random order and eventually one will fail because the decrement goes below zero. The transaction could have a boolean to allow partial fulfilment, which means that the the start inventory is what was fulfilled, and if the start was 0 or below, nothing was fulfilled.

In this case, it would seem that the database must be able to handle that last calculation, or fail it outright if it would drop below zero.

It could work ... but relies on some smart plumbing ... it also complicates things since this is rather non-standard way to do things.

I would always opt for the read->update->write cycle and understands how to retry. As you say, it is safe and methodical. I consider that a good thing when writing a blockchain app since we do want them to actually work ...

Kim

Kim Letkeman
Senior Technical Staff Member, IBM Watson IoT
IoT Blockchain

Phone: +1 (613) 762-0352
E-mail: kletkema@...


"Joe Alewine" ---06/07/2018 11:59:58 AM---Kim, I can understand why this implementation would be adopted. It's safe, it's methodical. There ar

From: "Joe Alewine" <joe.alewine@...>
To: "Kim Letkeman" <kletkema@...>
Cc: fabric@..., huwenbo1988@..., jmason900@...
Date: 06/07/2018 11:59 AM
Subject: Re: [Hyperledger Fabric] How to confirm a transaction? #fabric
Sent by: fabric@...




Kim, I can understand why this implementation would be adopted. It's safe, it's methodical. There are advantages. But it might make sense perhaps to also allow the system to check for "enough" supply given a transaction proposal. And then rather than directly modifying the key (telling it to go from 100 to 90), we "tell it", in a manner of speaking, only to reduce its supply by 10. In that scenario, only if the supply is less than 10 (at commit time) would the transaction fail. Not because the amount of supply changed.

A system in which transactions fail not because there is not enough to supply but because the amount of supply changed seems less than ideal, especially given the use cases in which this is likely to come up.

Regards,

Joe Alewine
IBM Blockchain, Raleigh

rocket chat: joe-alewine
slack: joe.alewine



----- Original message -----
From: "Kim Letkeman" <kletkema@...>
Sent by: fabric@...
To: jmason900@..., huwenbo1988@..., Joe Alewine <joe.alewine@...>
Cc: fabric@...
Subject: Re: [Hyperledger Fabric] How to confirm a transaction? #fabric
Date: Thu, Jun 7, 2018 11:34 AM

Regarding the "same block" assumption. It's not about what block transactions end up in, but rather it's about running transactions in parallel and *reading* the same key versions. This means that each transaction has a view of the world that does not take into account the parallel transaction(s), which will change that world. MVCC protects from that, which eliminates double spend as an issue.

Note that two parallel transactions can easily end up in different blocks as I mentioned in an earlier response on this list but the second transaction will always fail to commit because the key version has changed by the time it is being committed.

A simple resubmit fixes the problem and the new transaction will know the real inventory level or balance. Once the first transaction is committed, the balance or inventory is accurate and the resubmitted second transaction gets committed without a hitch.

Kim

Kim Letkeman
Senior Technical Staff Member, IBM Watson IoT
IoT Blockchain

Phone: +1 (613) 762-0352
E-mail: kletkema@...


"Jim via Lists.Hyperledger.Org" ---06/06/2018 05:02:09 PM--- Hi Joe, Good example where the application only needs to check available "capacity" before submitti

From: "Jim via Lists.Hyperledger.Org" <jmason900=yahoo.com@...>
To: huwenbo1988@..., Joe Alewine <joe.alewine@...>
Cc: fabric@...
Date: 06/06/2018 05:02 PM
Subject: Re: [Hyperledger Fabric] How to confirm a transaction? #fabric
Sent by: fabric@...




Hi Joe,

Good example where the application only needs to check available "capacity" before submitting the transaction. For your given scenario, any other mvcc transaction conflicts should be minimal in theory. Client applications would rarely need to resubmit the transaction for mvcc errors.

Jim

On Wednesday, June 6, 2018, 3:20:08 PM EDT, Joe Alewine <joe.alewine@...> wrote:


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.