You are reading an excerpt from our free but shortened abridged report! While still packed with incredible research and data, for just $20/month you can upgrade to our FULL library of 50+ reports (including this one) and complete industry-leading analysis on the top crypto assets.
Becoming a Premium member means enjoying all the perks of a Basic membership PLUS:
- Full-length CORE Reports: More technical, in-depth research, actionable insights, and potential market alpha for serious crypto users
- Early access to future CORE ratings: Being early is sometimes just as important as being right!
- Premium Member CORE+ Reports: Coverage on the top issues pertaining to crypto users like bridge security, layer two solutions, DeFi plays, and more
- CORE report Audio playback: Don’t want to read? No problem! Listen on the go.
Avalanche Consensus
The Avalanche network doesn’t use just one consensus mechanism but rather a collection of consensus protocols used by different components of the Avalanche Primary Network. The four consensus mechanisms under the Avalanche family are Slush, Snowflake, Snowball, and Avalanche. Avalanche Consensus is based upon a family of BFT protocols derived from the non-BFT protocol, Slush. Slush lays the foundation for Snowflake and Snowball BFT protocols by introducing metastability through subsampling (detailed below).
Avalanche consensus model. Source: The Hash Tray
Avalanche’s consensus performs repeated sub-sampling (explained below) among its validator nodes as it needs only a subset of nodes to communicate, resulting in low messaging complexity in the network. So, the bandwidth and processing power requirements per node stay constant even as the network grows to many thousands of validators. In terms of validator participation, chains built on Avalanche are more inclusive than Polkadot and Cosmos because of unbounded participation per chain. The number of chains a validator can work on depends on the chain runtime and virtual machine design.
The primary consensus mechanism used by the default asset chain is Avalanche Consensus. Slush, Snowflake, and Snowball all contribute to Avalanche (image below). Avalanche is an UTXO-based Directed Acyclic Graphs (DAG). A DAG is an alternative distributed ledger technology popularized by IOTA, that has a tree-like architecture with roots and branches rather than a simple, linear, sequential chain of blocks.
Comparing workflows of a blockchain and a directed acyclic graph. Source: Zipmex
Connections between nodes are called ‘edges’ in network theory, and these edges are directional in DAGs. DAGs are similar to trees, though trees are typically undirected (the connections between nodes aren’t one way or the other, they’re just connected) and don’t allow for closed loops.
DAGs enable the partial ordering of decisions by linking transactions together, thereby allowing for multiple transactions to be validated simultaneously rather than one after the other, as in many sequential blockchains. Avalanche consensus could work with either PoW or PoS, but Ava Labs chose PoS as its Sybil-resistant mechanism of choice. In short, Avalanche validators must stake some capital before being allowed to vote on transactions simply to deter spam/bot/DDoS attacks.
Snowman Consensus
The Avalanche consensus protocol can be applied to traditional “linear chains,” as opposed to DAGs, in what Ava Labs calls Snowman Consensus. Snowman enables the network’s validators to reach consensus much quicker than previous consensus mechanisms, like Classical or Nakamoto consensus, making it one of Ava Labs' primary breakthroughs.
Snowman Consensus is similar to Avalanche consensus, except that its architecture is linearized to make it EVM-compatible. Linear chains follow the “longest” or “heaviest” chain rule in which nodes on the network select the chain with the most work done as the valid chain (the “true” chain). Snowman Consensus is account-based rather than UTXO-based (diverging from Avalanche consensus) to be more compatible with Ethereum and other account-based smart contracts and dapps. Finally, a recent upgrade to Snowman, Snowman++, implements a leader for block production in an attempt to combat Maximum Extractable Value (MEV). Both the Platform Chain and the Contract Chain implement the Snowman consensus protocol.
Avalanche consensus is probabilistic and implements a novel network sampling mechanism called “repeated random sub-sampled voting.” In traditional consensus mechanisms, the network requires input from every node (Nakamoto consensus), however, with Avalanche consensus, the network simply polls a random portion of the validator set multiple times to arrive at an answer. Because it only needs to poll a small sample of validators, this makes reaching consensus incredibly lightweight and less burdensome than all nodes talking to all other nodes.
At a practical level, this is the process of random sub-sampled voting:
1. Transactions are submitted by network users, and validators must then decide to either accept or reject the transaction based on the rules set by the Virtual Machine (VM) for that subnet. Transactions that don’t follow the rules set by the VM are deemed invalid and ignored, while valid transactions are added to a list of pending transactions.
2. Once a specific validator has made their decision (valid or invalid), the validator then begins polling a random portion of other nodes in the network on their decision to accept or reject the transactions. Meanwhile, the other validators do exactly the same thing simultaneously. Roughly speaking, this is what’s known as a “gossip protocol.” A validator’s probability of being randomly polled by a peer is weighted based on the amount of AVAX stake it controls.
3. Each polled node must answer: valid or invalid. If >50% of the randomly polled nodes agree with the initial decision, it adds to the confidence of the polling node. If the supermajority supports a different value, the validator will switch its initial position to reflect the majority.
4. Because simply polling a small, random group of validators once won’t always be an accurate representation of the actual “truth,” validators will run through this process multiple times, each time sampling at random. All nodes are working in parallel to check other validators’ transaction confirmations randomly. After enough rounds of polling, a majority position begins to proliferate and each subsequent round builds on the momentum of the previous round akin to a snowball rolling down a hill. At this point, a transaction is determined to be probabilistically true.
5. This polling process will continue until a confidence threshold is met (set by the individual subnet). While this threshold strategy technically means consensus is still probabilistic, it’s based on the validators collecting enough data via sampling rounds that the probability of being incorrect is less than the odds of Bitcoin’s SHA-256 hashing algorithm being broken. Once met, the transactions are finalized (assuming the votes were in favor of “valid”) when all validators settle on one side of the decision. At this point, transactions achieve true finality (known as “0-conf”) and no reorganization of the blockchain is possible. Nodes accept the finalized transactions and they become permanently immutable, whereas Nakamoto Consensus (Bitcoin) is always probabilistic and adheres to the “longest chain” rule.
This same process is used even for conflicting transactions (e.g., a double-spend). The validator voting process will continue to poll until either:
- one of the transactions in the double-spend receives sufficient votes beyond the threshold and the other transaction is rejected, or
- the predetermined number of sampling rounds is reached without surpassing the confidence threshold and both transactions are dropped, whichever comes first.
Transactions in a “conflict set” may never reach a resolution, which is contrary to how chains like Bitcoin and Ethereum operate (discussed more below). However, this only affects users in the conflict set. The rest of the network resumes operating as normal.
Another breakthrough of this process and what makes Avalanche consensus unique is that it’s a leaderless protocol with an elastic block time, meaning blocks can be produced at any time and only when needed. Block times average two seconds. However, the C-Chain has had periods where >10 blocks were produced within one second.
This is incredibly quick compared to existing decentralized blockchains. Previously, in other consensus mechanisms, there was a trade-off involved in this respect. Bitcoin’s Nakamoto Consensus, coupled with proof of work, is permissionless and scalable but takes ~30 minutes to one hour for a block to be considered final (relatively high latency). Other PoS networks that use Classical Consensus (Polkadot, Cosmos, Tezos) offer faster finality but do so by limiting the validator set. They do this because, in Classical protocols, validators perform all-to-all communication, requiring more coordination and an updated view of the global validator set. Avalanche validators simply interact with a small, randomly sampled number of validators multiple times at the peer level. There’s no need to know the global state at all times. This results in far less overall node-to-node communication and, therefore, faster finality.
Avalanche consensus prioritizes safety over liveness, meaning if issues do arise, the network will halt rather than push forward anything invalid. This is the opposite of Nakamoto Consensus, though it enables Avalanche to provide high-security guarantees. Up to 50% of the nodes can be malicious and try to imbalance the network. However, they’ll be unable to do this in a way that causes two nodes to push through invalid data.
Minimum number of validators required for a 33% attack. Source: Kraken
