ELI5 Avalanche [AVAX] Platform Whitepaper Summary

In this post we’ll summarize the Avalanche Platform whitepaper [PDF].

This document is part of Ava Labs’ technical material about the Avalanche protocol and its implementation. Since the paper goes into high detail, we’ve summarized it ELI5 style to give you an overview of how the official AVAX implementation works.

The Avalanche platform whitepaper focuses on three main axis, which we’ve summarized as such:

• The Snow Consensus Engine
• Snow Implementation
• Avalanche Governance Mechanism

Let’s take a look at each of these individually, while summarizing the Avalanche whitepaper.

The Snow Consensus Engine

Snow family of protocols is third kind of distributed consensus mechanisms after Classical consensus and Nakamoto consensus (Bitcoin et al).

Snow operates by repeated sampling of network. Nodes poll a small, constant size and randomly chosen set of network peers and changes its decision about a transaction if a super majority supports a different decision.

Snow is permissionless : network participants don’t necessarily know about the existence of all nodes. In fact, the protocol allows for nodes to have very different views of the network.

Snow is scalable: the network can grow to millions of nodes working independently. Stake delegation is possible but not required. Everyone can become a validator and earn AVAX against their contribution to the network.

Snow is asynchronously safe: it does not depend on a hard consensus like Bitcoin or Ethereum do. The Avalanche network is metastable and not rigidly set to one consensual state. See our ELI5 Avalanche protocol article for a summary of how this works.

Snow Implementation

Ava Labs implemented the Snow protocol in a system called Gecko.

The platform architecture has three main concerns:

• Chains (on which assets are built)
• Execution environments
• Deployment

Chains & Assets

Under Avalanche, each asset lives on its own blockchain. Unlike Ethereum and other smart contracts platforms where assets go in the main blockchain, Avalanche creates a separate chain for each asset.

Each chain is an instance of an Avalanche Virtual Machine. The current Ava Labs implementation offers two virtual machines you can instantiate, but any kind of VM can be implemented if you have special requirements. Avalanche VM’s are implemented in the Go programming language.

When a new asset is created on the Avalanche system, its genesis is stored in the Platform Chain (P-Chain). When the Gecko node is started, it bootstraps the P-Chain and reads all assets created, instantiating a virtual machine for each asset running on its own chain.

Subnetworks

A subnetwork is a set of validators which verify transactions for a certain blockchain chain and its asset.

Each asset is validated by exactly one subnetwork. Though the nodes in a subnetwork can each validate several blockchains if they choose to.

This elegant hierarchical design allows for several networks of validators to validate their own chain running under Avalanche, decoupling the main AVAX chain from different assets.

The “miners” (validators) don’t nave to “see” all the others assets’ transactions, which is what happens in Ethereum, for example. This makes the system much more scalable.

Execution Environment

When the Gecko full node is initially run, it executes a startup process called bootstrapping. This terminology comes from general computing jargon, where starting a computer is called “booting”, which stems from “bootstrapping” (which itself is short for “pulling oneself up by the bootstraps”!).

Bootstrapping happens in 3 stages: connecting to network seeds, network and state discovery and finally becoming a validator. Once this process is done, you’re a full node running on the Avalanche network.

Bootstrapping: Connecting to Network Seeds

Every P2P networking system needs some way to start discovering the network. In a truly decentralized system such as Avalanche, a node starts up with no notion of any other node. There are no special nodes, no leaders, no masternodes or anything of the sort in Avalanche.

So, once a node starts up, it has a few seed nodes hardcoded into the source code, much like Bitcoin Core does.

Avalanche has one significant difference from Bitcoin, though. Since Bitcoin uses Proof of Work, it’s irrelevant whether the seed network nodes are dishonest. The security is guaranteed via Proof of Work.

In Avalanche, on the other hand, the initial network is the security. The majority of seeds, therefore, must be honest. For this reason, the initial list of nodes is hardcoded into the Gecko implementation.

Bootstrapping: Network and State Discovery

The node now requests the latest state transitions from the seed nodes.

The latest state is called the accepted frontier. Remember: Avalanche does not have the concept of a “chain tip”, like Bitcoin does. The accepted frontier of vertices is the closest concept Avalanche has to a chain tip. It’s a generalized concept of a chain tip. E.g. If a DAG only has one path in it, forming a blockchain, then the accepted frontier is the chain tip.

Once a node receives the accepted frontier from the seeds, it begins to walk the DAG backwards towards the root of the graph by querying other nodes. Since it has a valid frontier, all transitions backwards will walk through valid states.

By walking back through the chain in this manner, the node also become aware of every asset and every validator for those assets. Every full node thus knows who’s a validator for which asset/chain.

Bootstrapping: Becoming a Validator

Once the node has its copy of the accepted frontier and has walked the DAG backwards to the root, it then becomes a validator itself and becomes able to propagate its own accepted frontier and vertex data to other bootstrapping nodes on the network.

Sybil Protection

Avalanche networks are protected against so called Sybil attacks through staking. A Sybil attack is a kind of exploit where one player impersonates a large number of players in order to fake a majority. See our main Proof of Stake article for general details.

Each node that wishes to validate the network must lock up at least 2000 AVAX. The bigger the locked amount, and the longer the lockup period, the bigger the staking rewards once the validating period is over. See details of reaping AVAX validating rewards on our Avalanche staking article.

Once the stake is locked and the validation period begins, it’s impossible to revert. The node must then be online 24×7 in order to guarantee proof-of-uptime and proof-of-correctness.

Staking (validating) period is limited to one year. This is a safety mechanism to make sure users don’t accidentally lock their stake up for an arbitrary period of time by making a mistake at staking time. E.g. Locking funds for 10 years instead of 1 by entering one accidental zero.

Unlike Tezos, Prysm and other PoS coins, avalanche does not employ slashing. The reason for this is explained by Snow creator Emin Gün Sirer:

And this is why I called out slashing as a dangerous idea. @avalancheavax was the first system (and may still be the only one) to point out the misconception that slashing is necessary for a PoS chain to function. https://t.co/LbzxVF6L4l

— Emin Gün Sirer (@el33th4xor) August 15, 2020

Ethereum Smart Contracts

The initial Avalanche implementation supports Ethereum smart contracts from the start. An Ethereum Virtual Machine is built on top of the Snow protocol and runs with Gecko as a plugin (feature extension). Thus all Ethereum smart contracts, including the most popular DeFi, will be supported on a blockchain running under Avalanche. (This chain has been called the C-Chain by the Avalanche team, short for Contracts Chain.)

The main Avalanche advantage over Ethereum is that the C-Chain runs on its own virtual machine / chain and not in the main AVAX virtual machine. This accommodates much more growth than possible by using a single blockchain for all assets.

Avalanche Governance Mechanism

The Avalanche systems allows governance decisions over several aspects of the system.

For example, the transaction fee formula and staking rewards (inflation rate) can be dynamically decided.

A crowd oracle receives votes from stakeholders who decide on a set of parameters. Not everything is decidable through governance, though. This limitation is included on purpose to respect the principle of predictability.

As mentioned, inflation rate is one very important governance issue that may be voted on. AVAX may be inflationary, deflationary or even uncapped altogether. Which means the 720M hard cap is not set in stone.

Atomic Swaps

Avalanche natively supports atomic swaps.

Since all the different blockchains run under the main Avalanche umbrella, assets can be atomically traded between chains.

Pruning

The Avalanche DAG may be pruned. Which means that full nodes don’t need to keep the entire chain in permanent storage at all times. Deep vertices, which have been confirmed several iterations ago can be assumed to be accepted. To do this, a light node can keep only metadata and total address balances.

Client Types

Avalanche has 3 main client types: archival, full and light.

Archival nodes store a complete database of all Avalanche vertices, transactions, chains and so on.

Full nodes are complete, sovereign nodes but which only store the current state of the system, as mentioned under the Pruning section.

Finally, light clients run the complete Avalanche protocol but don’t store permanent state at all. Light clients constantly check the current state of the system and run the consensus algorithm and can, thus, be considered 100% safe.

Sharding

Sharding is the process of dividing work to be done into different sets which can be processed in parallel, in order to optimize speed. For example, RAID systems use disk sharding to read or write several sectors or disks at the same time.

There are three kinds of sharding: network, state and transaction sharding.

Avalanche supports network sharding, where the network is divided into subnets, where each subnet is verified by a different set of validators. Unlike other blockchains like Ethereum where all assets run on the main chain and are validated by the same set of miners.

Technical Concerns

The platform whitepaper mentions a few technical concerns that are worthy of notice.

Post Quantum Cryptography

Quantum cryptography, while still not developed enough to pose a direct threat to Bitcoin and other cryptocurrencies, is a 100% certain threat in the future. Avalanche allows any arbitrary VM to be implemented, thus an asset developer can simply use quantum-resistant cryptography.

Realistic adversaries were simulated and the Avalanche team determined that an all-powerful adversary would be very difficult to implement in a real scenario.

Finally, Equality is encouraged by the Avalanche staking mechanism where every validator is rewarded as long as they prove uptime and correctness, thus avoiding the rich getting richer problem inherent in most Proof of Stake cryptocurrencies. Avalanche is leaderless, which means blocks and vertices do not have leaders or owners, being verified by everyone in the exact same way.

Conclusion

Avalanche is light-weight, versatile and design to scale.

Several limitations of previously developed Proof of Stake protocols have been improved in Avalanche, including network sharding, leaderless validation, built-in atomic swaps and the possibility of developing custom VM’s for specific requirements.

We hope this summary has made the Avalanche platform easier to understand. It truly is an exciting new cryptocurrency technology which promises to bring significant advances to third generation crypto technology.

Links

Avalanche Platform Whitepaper

Gecko: Avalanche implementation by Ava Labs

Avalanche Documentation Home

Video: From Snowflake to Avalanche – Emin Gün Sirer