Re: Possible configuration of first-come-first-serve ordering policy

Jason Yellick <jyellick@...>

Transactions are placed into blocks, by the consensus plugin.  So, for Raft, you'll see this done

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@...>
Cc: fabric@...
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.

What are you trying / hoping to do?
Modify the following - keep reading please.
There is no "policy" per se and strictly speaking there is no guarantee that the transactions will be ordered in the exact order in which they were sent.


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.).

That being said, it is currently generally this case that transactions are ordered in the order received as they are processed from a gRPC stream which does queue messages in the order in which they are received.

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,


Gari Singh
Distinguished Engineer, CTO - IBM Blockchain
IBM Middleware
550 King St
Littleton, MA 01460
Cell: 978-846-7499

-----fabric@... wrote: -----
To: fabric@...
From: "Nikos Kapsoulis"
Sent by: fabric@...
Date: 05/15/2020 08:44AM
Subject: [EXTERNAL] [Hyperledger Fabric] Possible configuration of first-come-first-serve ordering policy

     according to orderer documentation, in phase         two the "the ordering service puts the transactions into           a strict order". Where in the orderer's         code (or anywhere else) is it possible to configure this "first-come-first-serve"       policy? Thank you in advance.
     With kind regards,


Join to automatically receive all group messages.