In this article, I will try to describe the purpose of an Ordering Service and its techniques used in the transaction flow.
Hyperledger Fabric architecture is designed based on the Deterministic Consensus Algorithm which implies that whenever any new block is distributed by the ordering node to any peer for validation of the block that is guaranteed to be final and correct. Meanwhile, different distributed blockchain platforms like Ethereum and Bitcoin support the Probabilistic Consensus Algorithm, so if an ordering node distributes a block to peer, later that has to be accepted without accepting any Policy or Endorsement of transaction. In the case of Hyperledger Fabric, the ordering services only receive the endorsed transaction proposal response from the client application. The group of ordering nodes forms an ordering service.
Orderer maintain Channel Configuration
The ordering nodes also maintain the list of organizations that are authorized to create channels and the list saved in a configuration known as the orderer system channel. The orderer determines the basic access control for channels, which satisfy the read and write access to the participants of the channel.
To change the channel configuration, the orderer processes the transaction by checking the current set of policies to make sure that the participant must have administrative rights. If the orderer confirms the update request as valid then it packages the configuration transaction in a block and sends it to all peers of the channel. The peer again validates the configuration transaction to make sure that the modification approved by the orderer and then applies the new channel configuration.
There are three sets of phases in the process when a client application wants to update the ledger. Because the agreement needs to be followed among all the peers in the blockchain network.
Phase One — Transaction Proposal
The client application sends a transaction proposal to the peers, later the peers invoke the proposal into the Chanicode to produce the ledger update and then endorsed the result. Now essentially, the endorsed proposal result will not be committed into the ledger but the endorsed peers will return the endorsed proposal response to the client application. So, in the second phase, the orderer can create blocks to save the transaction proposal for further processing.
Phase Two — Transaction packaging into blocks
In this phase, the client application submits the endorsed transaction proposal response to the ordering service nodes. There will be several ordering service nodes receiving endorsed transaction proposals from many different client applications parallelly. So, all these ordering service nodes collaborate to create blocks and ordered them in a well-defined sequence. Every block will vary based on their BatchSize and BatchTimeout, so these fields are defined in channel configuration that determines how many transactions can fit-in within an individual block.
Controls the number of messages batched into a block
The amount of time to wait before creating a batch
In Hyperledger Fabric, the ordering service supports strict ordering which means that if the Transaction T1 is already been written within block B1 then the same transaction T1 cannot re-written into different blocks such as B2, B3. The blocks generated by an ordering service remain final and delivered into the orderer’s ledger and available to distribute to all the peers that have joined the channel.
One more thing, an Orderer cannot be modified to the content of the transaction while writing into the block, can only modify the channel configuration of transaction based on proper administrative rights.
Phase Three — Block validation and commit
In the final phase, the peers receive the blocks from the orderer and validate all block transactions to ensure that the transaction has been endorsed by the organization’s peers. If the transaction becomes invalidated, as the orderer can not remove from the blocks as written from the beginning, so the peer marks the transaction as invalid and does not update in the ledger state.
Not all the peers need to be connected to the orderer while receiving blocks but later they can get a copy of the blocks from the other peers via gossip protocol. In this way, the blocks generated by the ordering service is properly validated and committed into the ledger.
So, this is the summary of “An Ordering Service in Hyperledger Fabric”, I hope this article gives you an idea about the roles of the Ordering Service and its techniques used in the transaction flow.
Please find the article useful :)