By: Jake Mok
Built by Ava Labs, Avalanche is a new platform that allows for the development of decentralized applications. Avalanche rivals well-known names such as Ethereum and Solana to be the next widely used blockchain. With a shrinking circulation of 720M AVAX tokens, Avalanche’s architecture and consensus mechanism help differentiate it from the competition.
Before diving into the unique consensus model of Avalanche, it is imperative to understand the history of consensus, in particular, Classical and Nakamoto consensus. Classical was the original consensus model and required each validator to know one another and agree on a universal decision. As a result, Classical consensus is highly efficient in terms of speed but is unable to scale well as it is dependent on agreement from all participating nodes. Nakamoto consensus, on the other hand, does not require all nodes to know each other and reach a universal decision but instead leaves room for a very small amount of disagreement. While Nakamoto consensus can scale well, it requires a high amount of energy usage and has a higher barrier to entry. Thus came along Avalanche which proposed a new consensus model that sought to solve these issues. Avalanche consensus is based on repeated random subsampling of AVAX (Avalanche token) stakers and a Directed Acyclic Graph (DAG)-an optimized protocol that allows for 4500 transactions per second.
Avalanche’s repeated random sampling works off of an idea known as “network gossiping”. Every user can participate in the validating of transactions by staking AVAX coins. From these stakers, Avalanche randomly selects a certain amount of validators to decide whether or not they believe the transaction is valid. Eventually, Avalanche builds up enough confidence through sampling stakers that allow a particular decision on whether or not a transaction is valid.
Here is a visualization of this process:
The other distinctive feature of Avalanche’s consensus model is its use of the directed acyclic graph (DAG) to store nodes. Most chains, such as Bitcoin and Ethereum utilize a linear chain when storing on-chain transactions. In a DAG there is not always a particular ordering as it is in a tree-like structure in which parent nodes can have multiple children, and children are not necessarily connected. The reason that Avalanche is able to process 4,500+ transactions per second is that in the DAG model nodes can have multiple parents allowing multiple transactions to be referenced at once. The DAG model will then use random sampling and “network gossiping” to determine whether or not the node should be added. However, a challenge arises when this random subsampling yields a conflicting opinion between nodes. Avalanche’s solution is adding two conflicting nodes, say (X and X’), to a conflict set.
Avalanche’s next selling point is its unique architecture. Unlike typical chains, Avalanche has three chains—the X-Chain, P-Chain, and C-Chain. The X-Chain is responsible for handling the distribution and transactions of tokens utilizing the DAG model mentioned above. The C-Chain is best for handling smart contracts and building out decentralized applications. Lastly, the P-Chain is perhaps the most complex of the three and the one I will be diving into deeper (more information on the other chains can be found here).
In order to understand the P-Chain in-depth, it is important to understand three fundamental features: subnets, the snowman protocol, and virtual machines.
As Avalanche puts it, a subnet is a “sovereign network which defines its own rules regarding its membership and token economics.” In essence, subnets consist of individual validators that function on their own blockchain and rules within the Avalanche ecosystem. They also offer the users the freedom to make a private subnet and decide who validates the chain. Moreover, a member may have or be a part of any arbitrary amount of subnets. These individual subnets are then used to validate the network as a whole with their own particular consensus model. Subnets also allow for interoperability which allows for two blockchains to be interconnected and share functionality.
The snowman protocol works in a similar way as the Avalanche consensus protocol, except the only difference is that instead of utilizing a DAG, the snowman protocol uses a linear graph similar to Bitcoin and Ethereum. A linear chain is often useful when time is a necessary component of the chain as it gives a clear understanding of relationships between all nodes. Whereas, in the event of a DAG, oftentimes, there may be no clear understanding of which node came before another.
Virtual Machines serve as computers with CPU and memory to help run the blockchain. Utilizing a virtual machine allows people to work with the blockchain without having to buy expensive setups that take up space. Avalanche’s Virtual Machine outlines a blueprint that helps developers extract away the parts of the lower-level complications of creating a chain. Avalanche’s virtual machine is referred to as the X-Chain, whose functions are mentioned above. When creating a new blockchain, the ID of the Virtual Machine is tracked along with the genesis data (starting block).
Subnets function through Virtual Machines, as VMs are the places where a user hosts the chain data to then validate and continuously build up. Due to the customizable nature of the subnets and virtual machines, this is favorable for developers. For example, with the Ethereum Virtual Machines developers don’t have to decide right away between the Avalanche and Ethereum blockchain. Instead, they can develop in the Ethereum native language, solidity, and still launch their app on the Avalanche blockchain utilizing the Ethereum Virtual Machine. As per the snowman protocol, it is in charge of keeping track of these subnets and their nodes.