The agreement process of receiving approvals from other peers to update the ledger is called a consensus.  A consensus ensures the following:

• It ensures that ledger transactions are synchronized throughout the blockchain network
• It ensures that only valid and approved transactions are appended to the ledger
• It ensures that when transactions are appended, they follow the same sequence as is set by the orderers

For a consensus to work, it is important that the transaction order is established and maintained and that there is an effective way to reject invalid transactions from becoming appended to the ledger. This can be achieved by PBFT, which ensures file replicas to keep each copy consistent. Bitcoin uses mining for ordering, where each computing node will solve a puzzle and define the order. HLF offers various consensus mechanisms to choose from—SOLO or Kakfa.

A consensus goes beyond just establishing the order of transactions. In HLF, a consensus plays an important role in the transaction flow—from proposal to endorsement, to ordering, validation, and appending. Throughout the transaction flow, identity verification happens at various stages. It is an ongoing process. Payloads are signed by endorsers, and peers, and the payload gets verified and authenticated repeatedly, throughout the transaction flow. To achieve a consensus, it is important to ensure that the order of the transaction is met and that transactions have gone through the endorsement policy. Before committing, it is important to ensure that sufficient endorsements are achieved and that the transactions have passed the versioning checks, where the current state is agreed before committing to the ledger. A versioning check is a check against double spending and other data integrity threats.

To me, the whole transaction flow is a consensus process. If you check the following transaction flow, peers reach agreement regarding the order of the transactions and the content of the transactions. This is achieved by going through various stages of the transaction flow. Under the hood, SDK manages the whole consensus process and the client is notified at the notification stage when the process is concluded.

The channel (application channel) contains details about the consensus options and orderer organizations. For example, the channel configuration has a parameter called Kafka broker. If it is set with ConsensusType as Kafka, then it's set for the channel's orders as the consensus algorithm. It is generally established during the bootstrapping of the blockchain network and, once configured in the channel configuration and the blockchain network, is bootstrapped; then, it's impossible to change it via configuration. Also, note that the MSP is synchronized via a consensus, too. The consensus is the ordering service, and you will get this clarified when you walk through transaction flow in the following section.

BFT versus CFT: Consensus algorithms (protocols) are pluggable in HLF, allowing designers to choose a consensus algorithm based on the use case. For cases when a blockchain business network is composed as a single enterprise, or all the participating organizations are fully trusted, then BFT is not the ideal consensus algorithm as the trust already exists. CFT algorithms can be used as they are more performant and offer better throughput. However, for decentralized distributed use cases, which include multi parties, BFT is the most suitable consensus algorithm.