I am trying to understand how the "transaction mempool" works in Hyperledger. I am mainly looking at the documentation here: http://hyperledger-fabric.readthedocs.io/en/release-1.1/peers/peers.html#peers-and-orderers I know how bitcoin works and I am thinking in 'bitcoin' terms (hence the word 'mempool') So as I understand it, in hyperledger there are 3 parties: application, peers and orderers. All parties have permission credentials from the MSP. The application submitting a transaction first needs to aquire a sufficient number of endorsements from a number of peers. After it appends to the transaction these endorsements, it sends it to an orderer that puts it in its 'mempool'. In the documentation it clearly states that forks can't happen, and if a transaction is included in a block is final. My question is: after the application receives the endorsements and sends the transactions to an orderer, how can we be sure that it doesn't send it to another orderer? And what would happen if two different orderers had the same transaction in their memory (before posting the relevant block)?
1
votes
1 Answers
2
votes
There is no concept of mempool in Hyperledger Fabric. Ideally in a production environment, all transactions gets written to a Crash Fault Tolerant Kafka cluster, which gives a single view of all the transactions to all the ordering service nodes. Orderers read back from the Kafka to cut blocks of Transactions, they do not send it to other orderers.
You can read more about it in my answer here: Transactions order in a channel with multiple Orderers
