In every blockchain network, certain interactions are carried out. Examples of these interactions may include the minting of NFTs, sending and receiving cryptocurrencies, signing of transactions, and even on-chain voting.

In traditional systems, before money is sent out from any first party involved in a transaction to a second party involved in a transaction, there is a validation and agreement before submission is made to the commercial banks then the individual withdraws.

This happens too on blockchain networks and each blockchain network has a specific method of verification of transactions through an agreement - "Consensus Mechanism" before funds can be sent out.

To get a better understanding of the concept of blockchain consensus mechanism. Visit this article.

What to expect in this article?

At the end of this article, you will understand the process involved in verifying transactions of users of the Avalanche network. This article does not require you to have coding skills for comprehension.

Introduction to Avalanche Blockchain

The Avalanche blockchain is an open source platform that enables developers to build decentralized applications to attain high scalability of transactions and fast throughput.

Notable blockchain network carry out a consensus mechanism such as Proof-of work, Proof-of-stake, and delegated proof of Stake in order to finalize a transaction before added to the blockchain network.

In order to avoid double spending of cryptocurrencies, the avalanche network uses run with repeated sub-sampling method before blocks can be added to the network.

User A has $30 worth of AVAX in his portfolio and decides to send out $30 worth of AVAX to user B on the Avalanche network and yet decides to send same amount to User C. This is regarded as double spending as User A has limited amount of AVAX in his possession for a double transaction worth that amount.

In order to verify and agree to the transaction to be carried out, a group of node validators come together to carry out the sub-sampling method.

The Process of Repeated Sub Sampling Method.

The Sub-sampling method takes place in loops untill verification of transactions can be obtained.

The number of loops before a transaction destination is runs is based on the Decision threshold which would be decided by a query node.

Other parameters involved in the process include:

• Number Of Participants, n

• Sample Size, K

• Quorum Size.

Where;

1. Number of participants, N: is the recorded number of node validators set to agree on the destination of the transaction.

2. K, Sample Size: is the number of node validators grouped together per set and;

3. ∞,Quorum Size: is the majority or minority per group after every round of sampling.

To start the sub-sampling process the decision threshold is given, 20. Therefore, 20 rounds of verification has to be obtained before finalization on the transaction destination can be agreed upon.

Given that there are 25 node validators, N to decide, the sample size can be given as 5. With K as 5, hence before every verification per group of validators, 5 individuals must be asked to choose which preferred destination the AVAX must be directed to.

In the first group of validators, assume 3 out of 5 node validators agree on User C, hence the first quorum size,∞ is 3 and the second set of random node validators receives 3 as the quorum preference.

If the second group of validators decides on User C, the consecutive amount of success in the algorithm increases by 1 as illustrated below:

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

Without the same response, the consecutiveSuccesses decreases by 1 and even to 0 when without a response.

To determine the final destination of the transaction, the decision threshold 20 must be met by the random selection to respond and hence finalization can be made by the algorithm and a destination for the transaction to be sent is decided and hence transaction is carried out instantly.

Transactions are quite different from interactions as the former would require validators. Avalanche is divided into Subnet blockchains with different functions and hence for every defined function of a specific subnet a need for a validator can emerge.

Avalanche validator's roles aren't a free spot for enthusiast of the blockchain as it is required that you must stake AVAX to be a validator of the network in order to ensure that malicious actors aren't part of the consensus team at any point.

Visit the Avalanche network docs here to learn more.