Re: Possible configuration of first-come-first-serve ordering policy
Jason Yellick <jyellick@...>
toggle quoted messageShow quoted text
Transactions are placed into blocks, by the consensus plugin. So, for Raft, you'll see this done https://github.com/hyperledger/fabric/blob/9715155109cd7992c0d4d7417b97dfb9d210c4da/orderer/consensus/etcdraft/chain.go#L810-L816
It would of course be nice if we had a property like "all the timestamps on the transactions will be ordered monotonically in the blockchain." But, Fabric is an asynchronous system, so it's simply not possible.
How long do you wait? If you wait 30 seconds, what if the client's message is delayed by 31 seconds? Then you've broken the premise. You cannot wait forever. So, in general, any re-ordering you do of client transactions will have failure cases under asynchrony.
With a more invasive approach to the consensus protocol, like assigning client sequence numbers to all requests, it might be possible to achieve some weaker guarantees like "client tx with sequence number n will not commit until after client tx with sequence number n-1", but this would not be a trivial exercise and would require additional consensus than simple total order. All this to say, a particular consensus implementation might be able to offer stronger guarantees, with cooperation from the client, but there's no way to do this reliably in Fabric as it stands today.
----- Original message -----
From: "Nikos Kapsoulis" <nkapsoulis@...>
Sent by: fabric@...
To: Gari Singh <garis@...>
Subject: [EXTERNAL] Re: [Hyperledger Fabric] Possible configuration of first-come-first-serve ordering policy
Date: Fri, May 15, 2020 9:43 AM
Gari, thank you for your answer. I am answering inline.
Modify the following - keep reading please.
However, I think that after the transactions are sent to the orderer and the orderer puts them in a strict order, then the peers will use the same order when validating and committing transactions. Thus, I suppose that somewhere in the orderer's code exists the point or function where the orderer sends the transactions to the peers, and hopefully it could be somewhat configured or modified. (For instance, in a way of sorting them by Header or something else.).
Again, correct me if I am wrong, I am trying to locate this exact point in code where the transactions are received, ordered and then sent to the peers (1 of the 3 points will do I guess), and hopefully configure a custom orderer. Thank you in advance.
With kind regards,