How Does Avalanche Consensus Works?

Introduction

The Avalanche consensus mechanism is a revolutionary system that aims to provide high throughput, scalability, and speedy finality in blockchain networks. It is based on repeated random sampling and validator consensus.

But, before we go into Avalanche Consensus, let us first define what consensus is and why it is necessary.

All about avalanche consensus

What is Consensus?

Blockchain networks rely largely on consensus. The primary goal of a consensus mechanism is to establish a single version of truth. i.e. a truth or fact that is universally approved by all network participants.

As a result, consensus may be defined as the ability of a collection of computers (or nodes) to reach an agreement. In blockchain, this means that all network participants must agree on any modifications made to the shared ledger. This agreement is established via a specialized mechanism known as a consensus protocol, which assures that everyone sees the same information and that it is accurate and trustworthy.

Key features of Avalanche consensus

Some of the main key features of avalanche consensus are:

Speed: Avalanche can handle a large number of transactions per second (TPS), making it appropriate for applications that require rapid transaction processing. (Approximately 0.8 seconds)
Scalability: Avalanche consensus enables the rapid processing of many transactions while reducing delays to a minimum. (throughput: 2500 TPS)
Energy Efficient: Unlike other popular consensus techniques, Avalanche consensus is neither computationally nor economically costly.
Parallel Processing: Avalanche supports parallel transaction processing, which means that numerous transactions can be confirmed at the same time, increasing the network's speed and efficiency.
Highly Decentralized: Despite its high throughput and efficiency, Avalanche aims to keep a decentralized network by letting different kinds of individuals participate in the consensus process. This helps to prevent centralized network control.

Now, let’s look at the avalanche consensus protocol with an example of a conflicting transaction.

About Avalanche Consensus

The avalanche consensus relies on the principle of Repeated Sub-Sampling Voting.

It is also called snowball algorithm or protocol.

What is a Repeated Sub-Sampling Voting Mechanism?

Let’s say there is a conflicting transaction where the node validators have to validate among two conflicting transactions which one is to be accepted in the blockchain.

When a node is determining whether a transaction should be accepted or not, it asks a small, random subset of validator nodes for their preference. Each queried validator replies with the transaction that it prefers, or thinks should be accepted.

If a significant majority of the validators sampled respond with the same preferred transaction, it becomes the preferred choice of the validator who queried.

In the future, this node will respond with the transaction chosen by the majority.

The node repeats this sampling procedure until the validators who were queried return the same answer for a sufficient number of successive rounds.

Let’s take an example for better understanding.

Suppose there is a conflicting transaction where two users are trying to book the same ride with the same driver at a single point in time by initiating the transaction.

For example

Let’s say Max and Kevin are both trying to book a ride by making a payment of 50 AVAX at the same time. The conflict over here is that the timing for both rides is the same, say 12 noon. But since there is only one cab/taxi available, therefore only one ride is possible and thus valid. (AVAX is the native cryptocurrency of the Avalanche platform).

Example

MAX and KEVIN now both issue their booking ride transactions at the same time to two different validators. First stating “MAX booked the ride at 12 noon” and Second stating “KEVIN booked the ride at 12 noon”. And tries to execute the payments at the same time.

Book my ride example

Both transactions are valid as both MAX and KEVIN have appropriate balances in their wallets to cover the transaction costs and fees. But as there is only one ride, thus the ride can be booked for a single user, and both of them can’t have it.

Now, when transactions are begun and delivered to validators, they have no idea which transaction began first and which came later. So what do they do now?

The validators simply take group votes and use the majority to determine if the transaction is fake or not, as well as who should get the ride.

When we look at the validators, each validator might have an initial preference or no preference at all of which of these two transactions is valid or should be included in the blockchain.

Let’s look at the process for the above case.

Assume we have a room of 50 validators validating the transactions listed above, one of which will be included on the blockchain. So, the first consensus parameter we have is the number of participants (n). (Here, n = 50)
Assume we are also validators with an initial preference for the transaction, and we will start a loop in which we will question a set of 5 validators about the transactions at once until our judgment is made. So, for each round of sub-sampling, we ask 5 validators. This must be an integer between one and n. This is abbreviated as (k). Here (k=5)
We'll ask five random validators to tell us something. Should the cab be scheduled for MAX or KEVIN?
Now, when we first started as validators, we only had a preference and did not examine if it was right or not. So we won't stay with that preference. While the sub-voting is taking place, if we receive a majority of three votes out of five for a certain transaction that we did not vote for, we will still cast our vote in favor of it.
The Quorum size (α) is the proportion of the sample size required to change our choice. Ex. We will modify our decision because we have a clear majority of three out of five people who agree.
In our example, suppose we question five separate validators and three of them indicate that we believe MAX applied for the cab first, then the cab should be reserved for MAX. We will modify our perspective on the system now that we have a simple majority. We're going to adjust our personal preference to MAX.
But how many times do we have to do that? As a result, the idea of decision thresholds emerged. (β). That is, how many times in a row do I need to hear the same majority of the Quorum agreeing?
Let's suppose the decision threshold is 12. Performing sub-sample voting with 5 random validators 12 times in a row results in 3 of the 5 (Quorum), indicating a preference for booking the cab for MAX. Then I will go along with MAX as my final choice and not change anymore.

Thus, this is how all the validators in this protocol will come to a decision for a particular transaction.

When there are no conflicts, transactions are finalized very quickly. If conflicts arise, honest validators quickly focus on the conflicting transactions, creating a positive feedback loop. This process ensures that all honest validators agree, leading to the acceptance of non-conflicting transactions and the rejection of conflicting ones.

In short

The number of validators equals the number of network participants equals n.
Out of these n Validators, k (sample size), random validators will be chosen and asked to vote on which transaction they prefer.
When a choice receives a majority of votes (votes > Quorum size (α)) among the k Validators, it is chosen.
The Decision Threshold (β) is achieved by repeating the process several times.
Finally, after a choice has been selected, the system will log in and will not allow them to alter their mind.

First Round of Subsampling

First Round of Subsampled Voting

We initially started with a preference (initial preference = MAX)

Preference Changed After First Round

Our preference changes to Blue (KEVIN)

After the first round of sub-sample voting, preference changed to KEVIN (as per majority).

Second Round of Voting

Second round of sub-sampled voting

The second round of sub-sampled voting, and we are sticking to our decision with consecutive success increments.

Pseudo Code

With these parameters, we can illustrate the consensus algorithm as a pseudo-code:

preference := MAX 
consecutiveSuccesses := 0 
 
while not decided: 
 ask k random people their preference 
  
if >= a give the same response : 
 preference := response with >= a 
  
if preference == old preference: 
 consecutiveSuccesses += 1 
 else: 
 consecutiveSuccesses = 1 
 else: 
 consecutiveSuccesses = 0 
 if consecutiveSuccesses > β 
 decide(preference)

Source - Avalanche Consensus | Avalanche Academy

How effective is this consensus mechanism?

There are two parameters we can use to determine if a consensus mechanism is good or not.

Time to finality: Refers to how long it takes from the moment I submit a transaction to the system until it is finished and cannot be changed and,
Throughput: which refers to how many transactions may be decided each second.

When compared with some other popular blockchain networks, the results of Avalanche were much better in consideration.

Network	Throughput	Time to Finality
Bitcoin	7 TPS	60 mins
Ethereum	30 TPS	6.4 mins
Avalanche	2500 TPS per Subnet	~0.8 seconds

Source - Avalanche Consensus | Avalanche Academy

Here, TPS stands for (Transactions per second), and Subnet means groups of validators working to validate specific transactions.

Conclusion

The Avalanche consensus method is an exciting shift in blockchain technology, providing incredible speed, scalability, and energy efficiency. Avalanche enables quick transaction processing and finality in 0.8 seconds by utilizing repeated sub-sampling voting, beating rival blockchain networks like as Bitcoin and Ethereum.

Its parallel processing capabilities and strong decentralization enable both robustness and resistance to centralization. Overall, Avalanche establishes a new benchmark for blockchain consensus by balancing high performance, decentralization, and efficiency.