In this segment of Blockchain articles, we are going to understand the role of Consensus in blockchain, it’s properties, and other concepts related to it.
Consensus mechanisms permit the secure updating of a distributed shared state. Common methods used for achieving fault tolerance (defined below) in a distributed network system is to maintain or distribute the shared state over different multiple replicas in the network system. Refreshing the replicated shared state occurs as per predefined state transition rules characterized by the state machine that is executed on all the replicas. This strategy is known as State Machine Replication.
Replication of state guarantees that the state is not lost in the event that at least one node crashes. The state machine rules guarantee that all nodes executing them with identical input, will in the end produce the same output. This results in agreement on the change in state by means of the consensus protocol. The replicas likewise interact with one another to construct consensus and agree upon the finality of the state after a state change is executed. With a blockchain based network system, the shared state is the blockchain and the state transition rules are the rules of the blockchain protocol.
Achieving consensus in a distributed network system is challenging. Consensus algorithms must be resilient to the failure of nodes, partitioning the network system, message delays and corrupted messages. The consensus algorithms also need to deal with intentionally malicious nodes in the network. Several algorithms are proposed to solve this issue. For a blockchain network system, achieving consensus guarantees that all nodes in the network system agree upon a consistent global state of the blockchain.
A consensus protocol has three key properties based on which its relevance and viability can be resolved.
1. Safety :
A consensus protocol is said to be safe if all nodes produce the same output and the outputs produced by the nodes are valid as per the standards of the consensus protocol. This is also known as the “consistency” of the shared state.
2. Liveness :
A consensus protocol ensures liveness if all non-faulty nodes participating in consensus, in the end, produce a value in the network.
3. Fault Tolerance :
A consensus protocol provides fault tolerance in the event that it can recover from the failure of a node participating in the consensus.
While all the mentioned three properties are crucial which is a popular outcome by Fischer, Lynch, and Paterson known as the FLP Impossibility Result, expresses that no deterministic consensus protocol can ensure security/safety, liveness and fault tolerance to internal failure in an asynchronous network system. While fault tolerance is crucial for all globally distributed network systems to work, distributed network systems will in general pick among safety and liveness relying upon their network system requirements and assumptions.
Fault tolerance is of two types of faults in distributed network systems. Fail Stop Faults deals with node failures that cause nodes to stop taking participation in the consensus protocol. These are the failures which are caused by hardware or software problems and crashing. At the point when a Fail Stop Fault happens, the node just quits response. The second class of failures are Byzantine faults, which cause nodes to behave erratically. This classification of Fault Tolerance was recognized and described by Leslie Lamport as the Byzantine Generals Problem. Byzantine failures can happen from software bugs or because of the node being compromised or attacked. A Byzantine node can lie, can give undecided responses or totally misdirect different nodes associated with the consensus protocol. The consensus protocol must have the option or features to work effectively and reach consensus.
The Byzantine Generals Problem.
Suppose, a gathering of generals, each general controlling a part of the Byzantine armed force has surrounded an enemy city. To attack the city, all generals need to agree on a battle plan. Generals can communicate with the help of messengers only. The messenger may be caught by the enemy and the message may never arrive at the other general. The problem in the agreement is that at least one general may be traitors and are interested in undermining the battle plan. To any communication end, they may send false messages, distort messages, or not send any messages. Every single agreed general will act as indicated by the battle plan. So, few traitors must not make the agreed generals adopt a bad battle plan.
Bitcoin’s Proof-of-Work Mechanism.
The Bitcoin network system makes possible the transfer of the cryptocurrency (Bitcoins) starting with one individual then onto the next in a totally decentralized manner and no central entity controls either the creation of Bitcoins or is engaged with the transfer. The Bitcoin blockchain is replicated on various nodes and the nodes order the transactions based on a Proof-of-Work (PoW) Consensus Mechanism.
To add blocks to the blockchain, every node needs to show that it has played out some measure of work, that’s why it is called Proof-of-Work (PoW). In Bitcoin, the node needs to discover a hash value which is less than a specific number, also referred to as the difficulty level set by the network system. The difficulty level is decided by the Bitcoin network protocols, which as of now guarantees that one block is generated every ten minutes. The process of solving the PoW puzzle or difficulty is to calculate a valid hash value, which is known as Mining. The first node to calculate a valid hash value gets the chance to add its proposed block to the blockchain and furthermore guarantee the mining reward.
Because of the distributed network, concurrent nature of this mining process, sometimes more than one node can calculate a valid hash at the same time. Each valid node adds its own proposed block to the blockchain and transmits this over the shared network system. In such cases, there is a temporary fork in the blockchain network, where some nodes are adding blocks to one branch, while different other nodes are adding blocks to another branch, based on which valid node is closest to the hash value. In any case, as more blocks are added to these forks, the protocol will guarantee that the branch with the greatest PoW (The Longest Branch) will get included in the blockchain and others will be removed. This prompts an inevitable consistency among all the nodes.
The Bitcoin PoW consensus mechanism works well enough in an open domain where any number of nodes can take part in the system and begin mining. No information or verification is required of any members, in this manner making this sort of consensus model incredibly adaptable as far as supporting a huge number of nodes. The Bitcoin PoW consensus is vulnerable to “51%” attack, where a mining pool that can control 51% of the mining power ( hashrate ), then the mining pool can add its own blocks into the blockchain or fork it to make a free branch that merges at a later point with the main blockchain. The bit of advantage for the attacker in launching such an attack, is that he can double spend his own funds and specifically dismiss transactions that the mining pool doesn’t want to include in the blockchain.
Another new type of attack can be carried out with a methodology known as Selfish Mining, where the honest miners are incentivized to help the attacker and join in performing a 51% attack. In this attack, the attacker performs inconsistent mining, at the expense of his own income by keeping up a different private blockchain in parallel to the Bitcoin blockchain then he specifically publishes many blocks at the same time, driving the network system to discard their blocks and the network starts losing revenue. This incentivizes honest miners to join the attacker’s alliance to build their revenue, which in the end can get to the size of control of 51% of the Bitcoin network. This methodology brings about longer transaction confirmation due to the instant load on the network. Bitcoin PoW likewise wastes a lot of energy in calculation of hashes during the mining process.
If you have any thoughts or suggestions, just comment down below. Stay Tuned for more.