“Snowflake to Avalanche” Consensus Protocol Family: Overview and Technicality

We provide a technical explanation of the “Snowflake to Avalanche” consensus protocol family. We based our analysis on the May 16th, 2018 version of whitepaper published by Team Rocket. Although consensus protocols are related to cryptocurrency mining, we focus on “Snowflake to Avalanche” as a consensus mechanism.

Motivation of Creation

The most popular consensus mechanism currently in use is Proof-of-Work (PoW). Bitcoin and other cryptocurrencies that utilize PoW have multiple problems such as high energy consumption and low transaction per second, which prevent them from succeeding as functioning, day-to-day cryptocurrencies. “Snowflake to Avalanche” aims to solve these problems by presenting a new family of consensus protocol specialized for cryptocurrencies.


At its core, traditional consensus protocols require absolute communication between all nodes to ensure that correct nodes agree on the same decision. This concept requires quadratic communication overhead O(n²) and accurate knowledge of membership (knowing all the network’s participants) which makes it difficult for scalability. Whereas Nakamoto consensus protocols instilled a probabilistic safety guarantee; meaning that, with very small probability, decisions have a possibility to revert. The underlying notions of these protocols are not efficient, requiring miners to constantly participate even when decisions are not necessary to be made.

· Requiring communication overheads from O(kn log n) to O(kn) for some small security parameter k

· Establishing only a partial order among dependent transactions

The paper claims that one significant trade-off of this protocol is the liveness for conflicting transactions, meaning that SoA only guarantees liveness for honest transactions. Although this might stall the network, it does not tamper the safety of honest transactions. Lastly, the consensus protocol family SoA can be divided into 4 parts: Slush, Snowflake, Snowball, and Avalanche.


To begin, Slush is the foundation of this protocol family, it is a single-decree consensus protocol inspired by gossip algorithms. The main idea of Slush is, with high probability, to categorize all nodes in an identical manner. However, it is crucial to remember that Slush does not have a strong safety guarantee against Byzantine nodes, as these nodes lack state. This means that if Slush is deployed within a network that contains Byzantine nodes, malicious actors can interfere with the decisions. This problem will be addressed on the Snowflake part of SoA.

Slush Procedure

The procedure of Slush will be explained using the color red and blue for better understanding. Initially, a node starts out with no color, updating its own color based on the clients’ color upon receiving a transaction. This node will then initiates a query; the process to start a query is by picking a small, constant sized (k) sample uniformly from the network at random and sends a query message.

Figure 1: Slush Diagram A
Figure 2: Slush Diagram B


The purpose of snowflake is to strengthen Slush with a single counter that emphasizes a node’s loyalty in its current color. In other words, a node will only accept its current color when the counter, which stores the number of consecutive samples that resulted in the same color, exceeds β, a security parameter.

Figure 3: Snowflake Diagram


In a nutshell, snowball adds a layer of protection for SoA by implementing confidence counters. The purpose of these counters is to record the number of queries that yielded a threshold result for their specific color. Essentially, a node finalizes on a color if the confidence for that color exceeds the other color after a certain number of consecutive queries.

Figure 4: Snowball Diagram


The final step of SoA, Avalanche, generalizes Snowball and maintains a dynamic append-only Directed Acyclic Graph (DAG) of all known transactions. The purpose of these steps is to improve efficiency and security. The DAG achieves efficiency due to a single sink called the genesis vertex, which enables a single vote on a DAG vertex to represent all transactions votes on the path to the genesis vertex. On the security side, DAG intertwines the fate of transactions, which simply means it ensures past decisions are difficult to undo without the approval of correct nodes.

Figure 5: Bitcoin’s Parents and Children





Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Marco Manoppo

Marco Manoppo

Research Director @DAR_crypto. Writing crypto, investing, venture building, strategy, and life musings. A pragmatic dreamer.