Page Content

Tutorials

Consensus Mechanisms In Blockchain: How Networks Agree

What Is Consensus Mechanisms In Blockchain?

Consensus Mechanisms In Blockchain
Consensus Mechanisms In Blockchain

A key idea in distributed systems and blockchain technology is a consensus mechanism. Participants in a distributed system use this approach to reach a consensus on a single, consistent state of the system, namely which transactions are legitimate and ought to be included in the shared ledger. Consensus methods are essential for guaranteeing that each block added to the blockchain is authentic and that all participants keep the same version of the ledger in the absence of a centralised authority.

Why Consensus Mechanisms Are Necessary

To maintain a single, accurate ledger in a decentralised network with numerous nodes independently recording information, there must be a mechanism for these nodes to agree on the validity and order of transactions. The issue of reaching consensus among dispersed nodes is resolved via consensus techniques, particularly in settings where some nodes may be untrustworthy or even hostile. They cover topics such as who gets to publish the next block and how disputes are settled when several blocks are put forward at once.

Essential Features of Dispersed Consensus

Several essential characteristics are sought for by distributed consensus protocols:

Agreement

The same value must be chosen by all honest nodes. No two proper procedures may arrive to different conclusions.

Integrity

A good person chooses no more than one value. The chosen value must be proposed by some people. This guarantees that in a single consensus cycle, no node makes a decision more than once.

Validity

If everyone suggests the same amount, then everyone who is right chooses that amount. The initial value suggested by at least one honest node must match the value that all honest nodes agree upon.

Termination

Each appropriate person must ultimately choose a value. Every honest node ends the consensus process’s execution and ultimately makes a choice. Another name for this is a liveness attribute.

Fault Tolerance

The consensus mechanism need to function properly even when there are malevolent or defective nodes present (Byzantine nodes). The tolerance of various algorithms for crash faults (nodes stopping or failing) and Byzantine faults (nodes acting maliciously or arbitrarily) varies.

The safety property, which covers validity and agreement, often indicates that nothing negative will occur. Liveness, which is usually symbolised by termination, suggests that something positive will finally happen.

Also Read About What Are The Characteristics Of Blockchain And Core Concepts

Types of consensus mechanisms & Categories

Based on their methodology and the blockchain ecosystem in which they are employed, consensus methods can be roughly divided into two categories:

Based on Permission Model:

Permission-less Consensus: Employed in open or public networks where anyone can join without requiring authorisation. Usually, participants don’t trust or know one another. Proof of Stake (PoS) and Proof of Work (PoW) are two examples.

When members of closed or consortium networks need permission to join and communicate, they use permission-ed consensus. Participants frequently have some degree of trust in one another, or at the very least, their identities are known. Consensus models may be less computationally costly and speedier. Round Robin is one example, as is Practical Byzantine Fault Tolerance (PBFT). Certain algorithms are especially well-suited for permission-ed contexts, such as Proof of Authority (PoA) and Proof of Elapsed Time (PoET).

Based on Approach:

Proof-Based Consensus: Nodes vie for the privilege of proposing the following block, frequently by investing resources. Proof of Work (PoW) (expending computational work), Proof of Authority (PoA) (staking identity/reputation), Proof of Burn (PoB) (burning coins), Proof of Capacity (PoC) (using hard drive space), Proof of Activity (PoAc) (combining PoW and PoS), and Proof of Elapsed Time (PoET) (random timer using TEE) are a few examples.

Voting-Based Consensus: To come to an agreement, nodes exchange signed messages and communicate with one another. When a predetermined number of messages are received, an agreement is formed. Byzantine Fault Tolerance is a common problem for these algorithms (BFT). Examples include FBFT, DBFT, and PBFT. PAXOS and RAFT, Crash Fault Tolerance (CFT) algorithms, prevent node crashes and inaccessibility.

Also Read About Role Of Cryptography In Blockchain Explained For Beginners

Prominent Consensus Algorithms

Prominent Consensus Algorithms
Prominent Consensus Algorithms

A number of consensus algorithms, each with unique features:

Proof of Work (PoW)

The right to publish the next block is granted to the first node to solve a computationally challenging puzzle. utilised in Ethereum and Bitcoin (albeit switching to PoS at the moment). It is intended for situations where there is little to no trust. High energy consumption is a big worry. To keep a constant block duration (ten minutes in Bitcoin, for example), the puzzle’s difficulty is adjusted.

Proof of Stake (PoS)

As collateral, participants “stake” a certain amount of cryptocurrency. The amount staked typically determines the likelihood of being chosen to produce the following block. Compared to PoW, this uses less energy. Delegated PoS (DPoS), Committee-based PoS, and Chain-based PoS are other variations. The PoS consensus technique is being used by Ethereum 2.0.

Practical Byzantine Fault Tolerance (PBFT)

Asynchronous networks with Byzantine faults are the target of Practical Byzantine Fault Tolerance (PBFT). In order to come to an agreement, a leader node and replica nodes must communicate during the pre-prepare, prepare, and commit phases. Tolerating faulty nodes (f) requires a minimum number of correct nodes, such as 2f+1 or 3f+1, depending on the model. In permission-ed blockchains such as Hyperledger Fabric, PBFT is widely used.

Raft

Unlike PAXOS, Raft is a Crash Fault-Tolerant (CFT) algorithm that is intended to be simpler to comprehend. It follows a leader-follower model in which a majority vote is needed to commit followers to changes that are repeated from the elected leader. utilised in Consensus Quorum and R3 Corda.

Proof of Authority (PoA)

A node’s reputation and identity are at risk rather than money. Block creation and validation are known to and permitted by validators. frequently employed in networks with permissions where users’ identities are confirmed.

Proof of Elapsed Time (PoET)

Selects the next node to generate a block in a fair manner by using a random timer, frequently found in a Trusted Execution Environment (TEE) such as Intel SGX. Efficiency and equal probability among nodes are its goals. suitable for situations with permissions.

Proof of Authority (PoA)

By producing verifiable historical recordings of events, Proof of History (PoH) enables nodes to agree on the sequence and time of transactions without necessitating extensive pre-communication. utilised in Solana in conjunction with PoS.

Round Robin, Delegated Proof of Stake (DPoS), Federated Byzantine Fault Tolerance (FBFT), Proof of Burn (PoB), Proof of Capacity (PoC), Proof of Activity (PoAc), and Algorand’s Pure Proof of Stake (PPoS) are some of the other algorithms that have been mentioned.

Consensus in Blockchain Architecture and Flow

A crucial component of the blockchain architecture, the consensus mechanism is positioned beneath the execution and application levels and above the network, P2P, and cryptography layers. Nodes in the transaction flow utilize the consensus process to decide which block should be added to the chain once transactions have been collected and may be included in candidate blocks. A block is added to the chain and its associated transactions are validated once consensus has been established on it. The blockchain’s consensus state is then propagated throughout the network.

Challenges and Considerations

It is difficult to design and deploy scalable and effective consensus systems. Problems include energy consumption (especially with PoW), scalability in terms of transaction throughput and node count, achieving consensus finality (the guarantee that a block won’t be reverted), and security against different types of attacks (such as Sybil or 51% attacks, which PoW and other mechanisms are meant to withstand). Depending on the particular application environment and presumptions about trust, choosing a consensus algorithm frequently requires trade-offs between performance, scalability, security, and decentralisation.

Also Read About Understanding Distributed Ledger Technology (DTL) Overview

Thota Nithya
Thota Nithyahttps://govindhtech.com/
Hai, Iam Nithya. My role in Govindhtech involves contributing to the platform's mission of delivering the latest news and insights on emerging technologies such as artificial intelligence, cloud computing, computer hardware, and mobile devices.
Index