Avalanche: Let It Snow!

/ Allan Cassis & Jimmy Cassis

In 2018, a paper of what would become Avalanche was published. Those ideas are almost ready for a mainnet launch.

Below, we intend to share with the Avalanche community a summary of our findings during our review of the design and implementation of those ideas, But, before focusing on that, let us provide some context.

Bitcoin vs. Smart Contract Platforms

Bitcoin is used for storage and transfer of value across the internet without a trusted intermediary. It can be accessed by anyone, anywhere, at any time. It is a financial asset that is superior to gold in many ways, but, like gold, its use cases are rather limited--at least today.

Approximately five years after the creation of Bitcoin, Ethereum pioneered the idea that a blockchain can not only host simple data, like transactions, but also complex programs now known as smart contracts.

Smart contracts are programs running on the blockchain that execute automatically when certain conditions are met. They enable developers to build far more sophisticated functionality than simply sending and receiving cryptocurrencies. Transactions submitted through a virtual machine--in Ethereum, the EVM--can call these pieces of software to perform complex tasks, like issuing collateralized loans or exchanging assets, among a myriad of others. With smart contracts, we can construct peer-to-peer, decentralized applications, or DApps, that replace the existing solutions we use today and create new and innovative business models. All without the need for centralized entities to manage the flow of information.

So, What is Avalanche and What Makes It Unique?

Like Ethereum, Avalanche is an open-source platform that allows anyone to write smart contracts and develop DApps. The difference?

Avalanche is a high-performance, scalable, secure, customizable, and modular “build your own blockchain” platform.

  • High-performance: blockchains built on Avalanche employ the state-of-the-art Snow family of protocols, which handle thousands of transactions per second and permanently finalize transactions within seconds.
  • Scalable and Secure: Avalanche uses Proof-of-Stake (PoS) as a Sybil protection mechanism, which allows tens of thousands of validators to have a first-hand say in the system while consuming minimal energy and making the network robust and resistant to attacks.
  • Customizable: Avalanche gives developers full control over how a DApp executes, what language or virtual machine it executes it with, who gets to interact with it, who gets to control it, and who gets to view it. It also allows for the creation of "smart assets," or arbitrarily complex digital assets with custom rules, covenants, and riders.
  • Modular: anyone can create their own standardized, application-specific, permissionless (public) or permissioned (private) chains that efficiently interoperate together into one common blockchain network. Avalanche is not limited to a single lowest-common-denominator blockchain. Instead, it is an ecosystem of many blockchains which can be easily extended to fit specific needs.

Public Blockchains and Consensus Protocols

A public blockchain is a distributed and decentralized database that, in general, must satisfy three properties: it must be readable by anyone, writable by anyone, and inalterable by anyone. The problem that computer scientists have been trying to solve for decades is: if anyone is allowed to participate in the network, then how do we make sure that only valid transactions are included in the database?

A public blockchain is a type of distributed system in which a group of nodes (computers) communicate over a peer-to-peer network to accomplish common tasks (validating transactions) in a coordinated manner. To do so, these nodes run protocols to reach consensus on which transactions are valid. While below we briefly discuss three families of consensus protocols, we will not go into too much detail. For additional information, we highly recommend this summary from Avalanche’s Co-Founder and COO, Kevin Sekniqi.

The Snow Family of Protocols

Used in Bitcoin and in the current implementation of Ethereum, Nakamoto consensus protocols rely on Proof-of-Work (PoW) mining, coupled with the longest-chain-rule. They are robust and decentralized, but suffer from high confirmation latencies, low throughput, and require constant energy expenditure for security.

Classical consensus protocols, like Cosmos' Tendermint, rely on all-to-all communication to ensure that all correct nodes reach the same decisions with absolute certainty. While these protocols can have low latency and high throughput, they do not scale to large numbers of participants, nor are they robust in the presence of membership changes

The Snow family, introduced by Team Rocket's Avalanche paper, combines the best properties of Classical consensus protocols with the best of Nakamoto consensus.

Properties of Snow Protocols

Protocols in the Snow family are very fast. They can achieve irreversible finality in 1-2 seconds, quicker than all point of sale transaction systems, including credit card transactions, which typically take 24 to 48 hours to clear. They support many thousands of transactions per second, in excess of payment processors' normalized throughput.

Snow protocols operate through repeated random sub-sampled voting. In a given round, a validator queries only a small sub-sample of validators, which are selected randomly and weighted by stake amount, allowing the protocol to scale to up to millions of participants. 

Snow protocols are also lightweight and sustainable. Unlike Nakamoto protocols, they use very little energy, and when there is no work to do, the system quiesces (waits in a low-energy-consumption state).

Finally, Snow protocols are highly secure. They are immune to a number of attacks that other consensus protocol families face. The large number of validators ensures immutability and censorship resistance that PoW protocols, backed by small numbers of mining pools, cannot achieve. Other projects that use PoS attempt to scale by delegating validation to a subcommittee. The cost of compromising safety in such a system is only as low as the cost of corrupting any subcommittee, which may be very low. In Snow protocols, delegation is not necessary because the protocol allows every validator to participate in consensus.

How Do Snow Protocols Work?

When a validator -- Validator A -- sees a transaction and wishes to check the network to verify its validity, it asks a small, random subset of validators whether they think the transaction should be accepted or rejected. If one of the queried validators -- Validator B -- thinks the transaction is invalid, has already rejected the transaction or prefers a conflicting transaction, Validator B replies to Validator A that it thinks the transaction should be rejected. Otherwise, it replies that the transaction should be accepted. In this context, Validator B is one of the randomly sampled validators in one of the repeated rounds of sampling and, therefore, has a strong opinion about the validity of the transaction.

If a sufficiently large portion (let's call this variable alpha) of the sampled validators reply that they think the transaction should be accepted, Validator A prefers to accept the transaction. That is, when another validator -- Validator C -- queries Validator A about the transaction in the future, it will reply that it thinks the transaction should be accepted. Similarly, Validator A will prefer to reject the transaction if alpha of the queried validators reply that they think the transaction should be rejected.

Validator A repeats this sampling process until alpha of the validators queried reply the same way (accept/reject) for a pre-defined number of consecutive rounds (beta).

In the common case when a transaction has no conflicts, finalization happens very quickly. When conflicts exist, honest validators quickly cluster around preferring one of the conflicting transactions, entering a positive feedback loop until all correct validators prefer that transaction, leading to its acceptance and the rejection of all conflicting transactions. Avalanche gets its name from this cascading property.

It is guaranteed (with arbitrarily high probability based on system parameters) that if any honest validator accepts or rejects a transaction, then all honest validators will similarly accept or reject that transaction.

Avalanche is the first implementation of the Snow family of protocols. Below is a table comparing implementations of both Nakamoto and Classical protocols with Avalanche.

Platform Architecture

Snow protocols form the basis for Avalanche consensus. The platform has two consensus engines:

  1. Avalanche (a DAG-optimized consensus): high-throughput, parallelizable, and simple to prune.
  2. Snowman (a chain-optimized consensus): high-throughput, totally-ordered, and best for smart contracts.

Everything in Avalanche is a subnet (short for “sub-network”), and every chain is part of a subnet. A subnet is a subset of the global validator set, who have opted to participate in validating a group of chains. Subnets create their own incentive mechanisms for these validators. All but the Default Subnet are optional for validators.

Avalanche has 3 built-in blockchains, which are validated by the Default Subnet:

  1. The X-Chain is a DAG-based payment chain for creating and trading smart digital assets (i.e., a representation of a real-world thing with a set of rules that govern its behavior). One of the assets traded on the X-Chain is $AVAX, the network's native token. When one issues a transaction to a blockchain on the Avalanche network, they pay a fee denominated in $AVAX. The X-Chain is an instance of the Avalanche Virtual Machine (AVM).
  2. The P-Chain manages metadata about the Avalanche network. Its API allows nodes to create subnets, add validators to subnets, and create blockchains.
  3. The C-Chain is an instance of the Ethereum Virtual Machine, powered by Avalanche’s consensus protocol. One can create smart contracts on the C-Chain and do anything else they would do on Ethereum by using the C-Chain’s API.

Avalanche can also support multiple chains with their own custom virtual machines. It enables developers to easily create custom blockchains and DApps that can contain any arbitrary logic.

Avalanche's Architecture

Network Functionality

  • Subnet Design and Incentives
    For different use cases, subnet creators will be able to design their own chains and incentive schemes, which means that validators will be able to scale without regard to the number of subnets on the network and opt-in to subnets which they are interested in validating.
  • Regulatory Compliance
    Avalanche was built with financial use cases in mind. So, subnet creators may require users to meet an arbitrary set of requirements, such as: (i) must be located in a given country, (ii) must pass a KYC/AML check, and (iii) must hold a certain license. This architecture allows regulatory compliance and opens blockchain technology to the development of existing, but more efficient and new real-world financial solutions that would not be possible otherwise.
  • Athereum = Avalanche + Ethereum
    As an Avalanche subnet, Athereum will be a friendly fork of Ethereum, but with Avalanche's consensus engine, which allows near instant finality and high throughput. Developers on Athereum will be able to leverage the full suite of tools that exist within the Ethereum ecosystem (e.g., Remix, Metamask, MyEtherWallet, and Web3js). By porting over the Ethereum state at a to-be-determined block height to Avalanche, all existing $ETH holders will have access to $ATH, Athereum's native asset, equal to the current amount of $ETH they hold in their wallets.
  • Governable Transaction Fees
    Avalanche will allow validators to extract their own fees according to their own custom algorithms. Fees are essential for incentivizing validators and for distributed denial-of-service (DDoS) protection across all blockchains.
  • Smart Asset Creation
    Avalanche will have native support for easily creating and trading digital smart assets with complex custom rulesets that define how the asset is handled and traded. The assets could represent financial instruments, such as equities, bonds, debt, derivatives, and fractionalized real estate, among others. Subnets will be able to manage their own assets. Both fungible and non-fungible tokens will be supported.
  • Atomic Commitment Across Subnets
    Because subnets use the same underlying protocol for consensus, transactions to atomically commit across multiple subnets will be enabled, allowing validators to verify transactions across two or more subnets.
  • Governance Parameters
    Stakeholders will be able to adjust key economic parameters of the system, according to changing external circumstances. Key parameters (e.g., minimum staking amounts and rewards rate) can be modified dynamically, while maintaining the supply cap intact.

Avalanche gains its performance advantages from its revolutionary consensus protocol; yet, the implementation can be improved. The development and engineering team at AVA Labs is exploring pruning, networking improvements (interestingly, NAT Traversal supported on mainnet), Frosty consensus (a new, leadered version of Snowman), database upgrades, post-quantum and privacy VMs, and blockchain sandboxing, among many others.

The $AVAX Token

$AVAX is the native token of the Avalanche platform. It is the main unit of account in the network (i.e., the “global reserve currency”) and serves as a very fast peer-to-peer payments currency. It is also used for securing the network, deploying subnets, paying transaction fees, creating and exchanging assets, and governing the protocol (voting).

$AVAX has a capped-supply of 720 million tokens. The genesis block will create 360 million $AVAX tokens. The remaining 360 million tokens will be minted according to a predetermined equation (for additional information see Avalanche's token paper linked in the additional resources section). For the first year, the annual staking reward will initially target a minting rate between 7% and 12%. Note that $AVAX token holders, through a governance mechanism, can determine the rate at which the maximum cap is reached, adapting to changing economic conditions. For additional details on Avalanche’s token economics, including detailed token distributions and unlocking schedules, visit the token sale website.

Validating nodes earn the right to mint by putting up a stake and participating actively in consensus. Minting is dependent on (a) the percentage of the total supply being staked, (b) the stake duration (min./max. staking duration: 2 weeks/1 year), and (c) node uptime (Proof-of-Uptime) and response latency (Proof-of-Responsiveness).

Importantly, at the moment, Snow is a family of leaderless Byzantine fault tolerant protocols. Unlike other protocols that mint new tokens to the elected leader, such as in Bitcoin and most other PoS projects, in Avalanche, all validating nodes participate in consensus and are remunerated proportionally for the service they provide to the network, so the variance of rewards is kept to a minimum, eliminating the need for staking pools. Additionally, transaction fees are not paid to any specific validator either. Instead, fees are burned, thus increasing the scarcity of $AVAX.

Taking advantage of its flexible and parametrizable protocol through governance, Avalanche attempts to take the best of both Keynesian and Austrian economics to eventually reach steady growth and an economic equilibrium. The hope is to develop a network in which there is a significant amount of money velocity (users continually transacting, signaling a healthy and useful economy), very low fees (such that the deflationary effect of burning isn't too powerful), and low minting (to neutralize the aforementioned deflationary force).

The Avalanche Team

Avalanche is being developed by a world-class research group that spun out of Cornell University and IC3 (The Initiative for Cryptocurrencies and Contracts) with deep technology and finance experience.

Core Team

Dr. Emin Gün Sirer, Founder & CEO

  • Associate Professor (on leave) from Cornell
  • Co-Director of IC3 (on leave)
  • Creator of first PoW cryptocurrency in 2003 Karma, Bitcoin-NG, Bitcoin Covenants
  • Author of the Bitcoin selfish mining paper

Dr. Maofan "Ted" Yin, Founder & Chief Protocol Architect

Kevin Sekniqi, Founder & COO

  • Cornell PhD candidate in Computer Science 2021 (on leave)
  • Ex Microsoft, NASA

John Wu, President

  • Ex-CEO of Digital Assets at Sharespost
  • Founder of $500m hedge fund Sureview Capital / Sego
  • Ex Kingdom Capital, Tiger Management
  • Harvard MBA

Stephen Buttolph. Senior Systems Architect

  • Graduated from Cornell University with a B.S. in Computer Science after just 5 semesters
  • Member of the Avalanche’s client (Gecko) development team

Plus 30+ additional team members, primarily engineers and business-oriented staff attending all major markets.

Advisors

Dr. Maureen O'Hara

Robert W. Purcell Professor of Finance at the Johnson Graduate School of Management, Cornell University. Seminal figure in microstructure theory.

Adam Kravetz

COO of Seven Eight Capital. COO of ETF Market Making and Arbitrage at Citadel Securities. COO of Global Execution Services at Bank of America Merrill Lynch. Managing Director of Tower Research Capital.

Plus additional unannounced advisors, which provide specialized knowledge, significant experience, and strong relationships both within and outside the blockchain ecosystem.

Investors

In early 2019, Avalanche raised $6 million from venture capital and crypto funds, including a16z, Polychain Capital, Initialized Capital and Metastable, with angel investments from former Coinbase CTO Balaji Srinivasan, Naval Ravikant and Ramtin Naimi of Abstract Ventures. In June 2020, the team raised $12 million from Galaxy Digital, Bitmain, Initialized Capital, NGC Ventures, and Dragonfly Capital, among other individuals.

A public token sale will take place from July 8, 2020 at 10am EST until July 22, 2020 at 10am EST. For more information, visit the Avalanche token sale website.

Additional Resources

If you like this content and want to hear more, subscribe to our newsletter.

Disclaimer

This blog post is provided as general information only and is in no way intended as investment advice, investment research, a research report or a recommendation. Any decision to invest or take any other action with respect to the securities or tokens discussed in this commentary may involve risks not discussed herein and such decisions should not be based solely on the information contained in this document.

Statements in this communication may include forward-looking information and/or may be based on various assumptions. The forward-looking statements and other views or opinions expressed herein are made as of the date of this publication. Actual future results or occurrences may differ significantly from those anticipated and there is no guarantee that any particular outcome will come to pass. The statements made herein are subject to change at any time. Lvna disclaims any obligation to update or revise any statements or views expressed herein.

In considering any performance information included in this commentary, it should be noted that past performance is not a guarantee of future results and there can be no assurance that future results will be realized. Some or all of the information provided herein may be or be based on statements of opinion. In addition, certain information provided herein may be based on third-party sources, which information, although believed to be accurate, has not been independently verified. Lvna and/or certain of its affiliates and/or clients hold and may, in the future, hold a financial interest in securities or tokens that are the same as or substantially similar to the securities discussed in this commentary. No claims are made as to the profitability of such financial interests, now, in the past or in the future and Lvna and/or its clients may sell such financial interests at any time. The information provided herein is not intended to be, nor should it be construed as an offer to sell or a solicitation of any offer to buy any securities or tokens. This commentary has not been reviewed or approved by any regulatory authority and has been prepared without regard to the individual financial circumstances or objectives of persons who may receive it. The appropriateness of a particular investment or strategy will depend on an investor’s individual circumstances and objectives.

Back to list