Consensus Mechanism

The result of arriving at a common consensus happens by engaging with various algorithms like Proof of Work (PoW), or Byzantine Fault Tolerant (BFT).

Achievement of consensus in Ethereum

All peers taking part in the network have to reach consensus so that the transaction can be appended to the blockchain. Peer has to take part in achieving the consensus even if it has not taken part in the transaction. You might think why should the peer take part in validating the transaction when it has got nothing to do with it. The catch is that- there is an incentive. If a peer proves the correctness of a transaction in Ethereum network, it will be rewarded with Ethers. In the current implementation of Ethereum, the mechanism is established by mining based on Proof of Work algorithm.

Issues with proof of work

It requires lot of computational power (CPU cycles, GPU, electricity) to get random bits. Tragedy of the commons — Miners reward reduces over time, when this occurs less miners will mine these blocks. This could open up window for malicious users who can easily acquire more than 51% of network and thus destroying the network.

Ethereum is trying to switch from proof of work to proof of stake consensus algorithm.

There is a problem of double spend here. Maybe there are two parallel transactions which transfer the same coin to two different recipients. In easier terms, suppose a person has only $10 but ends up spending $20 without going into debt.

Security is also of paramount importance here. The data recorded on the ledger is accessible to everyone which is a problem for applications that require a more serious degree of privacy.

Achievement of Consensus in Hyperledger Fabric

The definition of consensus in Hyperledger Fabric is different. It doesn’t narrow down to mining based on PoW or any other derivative thereof. Since it is operating in permissioned mode, there is more fine grained access control to improve privacy.

Here, consensus encompasses the entire transaction flow right from the beginning (from proposing a transaction to the network) till the end (committing the transaction to the ledger). In this case, every node assumes different role to play while reaching consensus unlike Ethereum where every node has identical role to play.

Nodes are differentiated based on whether they are:

1. Clients: They act on behalf of an end-user and creates and thereby invokes transactions. They communicate with both peers and orderers.

2. Peers: They maintain the ledger and receive ordered update messages for committing new transaction to the ledger. Endorsers are special type of peers where their task is to endorse a transaction by checking whether they fulfil necessary and sufficient conditions. (eg. Provision of required signatures)

3. Orderers: They provide communication channel to clients and peers over which messages containing transaction can be broadcasted.

At this point, the problem arises that there might occur faults in the delivery of messages when many mutually untrusting orderers are employed. As a consequence, a consensus algorithm has to be used in order to reach consensus despite faults, e.g. inconsistent order of messages, thus making the replication of the distributed ledger faults tolerant. With Fabric, the algorithm employed is “pluggable”, meaning that depending on application specific requirements various algorithms can be used. For example, in order to deal with random or malicious replication faults as outlined above a variant of the Byzantine fault-tolerant (BFT) algorithms could be used.

Furthermore, channels partition message flows, meaning that clients only see the messages and associated transactions of the channels they are connected to and are unaware of other channels. This way, access to transactions is restricted to involved parties only with the consequence that consensus has only to be reached at transaction level and not at ledger level as with Ethereum.

Transaction flow

A client sends a transaction to connected endorsers in order to initiate an update of the ledger. All endorsers have to agree upon the proposed transaction, thus some sort of consensus has to be reached regarding the proposed ledger update. The client now successively collects approval of all endorsers. The approved transaction is now sent to connected orderers which again reach consensus. Subsequently, the transaction is forwarded to peers holding the ledger for committing the transaction. Without going further into detail, it becomes clear that Fabric allows fine grained control over consensus and restricted access to transactions which results in improved performance scalability and privacy.