We're going to go ahead and get started. My name is Gabriel Cardona. I'm a Developer Evangelist at Ava Labs. Today's presentation is going to be "How to launch an Avalanche Subnet" with a high level introduction to the Avalanche Network followed by demo. We're going to talk about several of the unique attributes of the Avalanche network which are Avalanche Consensus, Network of Networks, Subnets and Virtual Machines and then I'll show how to deploy a local test network for development.
The obvious place to start is what is Avalanche? Avalanche is a global financial network for the issuing and trading of all digital goods. We enable potentially millions of validators to process thousands of transactions per second with near instant finality using a protocol which is completely green and quiescent. We've paired this high throughput and fast finality protocol w/ an architecture that can meet the needs of unique financial services and decentralized apps.
We accomplish this through the notion of Subnets. Subnets allow anyone anywhere to spin up a taylor-made network w/ custom virtual machines and complex validator rulesets. Avalanche is a network of networks. It's a platform of platforms where we invision thousands and thousands of public and private Subnets all emerging into this global marketplace which we call The Internet of Finance.
Before we start I want to give a brief history of the evolution of the blockchain revolution. I suspect that most of this information on these next few slides won't be news to the people watching today but in my life I've discovered that to truly appreciate where you're headed it helps to truly understand where you're coming from.
Blockchain 1.0 was Bitcoin. In the beginning was Bitcoin and Bitcoin was good. Bitcoin proved to the world the need for a robust and decentralized payment network.
As big of a leap forward as Bitcoin was it still has downsides. Namely it's slow, only a handful of txs per second. It doesn't have fast finality, it takes an hour before you can be confident that your transaction won't be reorged. It's not lightweight and green—we all know the meme about BTC burning more energy each day that some nation states.
Bitcoin a scripting language, creatively named Script, but it's archaic and cumbersome to use. It's stack based and it doesn't feel modern for someone who has come of age in the era of golang, typescript and python. Lastly it doesn't have tokens. Technically there is an OP code, called OP_RETURN which enables you to write 80 bytes of arbitrary data to the blockchain which can be used to encode asset creation, minting, transfering and burning commands. You can then write wallets which can tease out those 80 bytes and decode them from which you can have tokens but it's really a technical hack and the tokens aren't native to the Bitcoin Virtual Machine. They aren't miner validated.
In summary, Bitcoin was a huge leap forward and kicked off a financial revolution but it left a few things to be desired and inspired engineers to try and do better.
Ethereum is Blockchain 2.0. Ethereum is a decentralized app which enables developers to launch their own dapps on top of it in the form of a smart contract. Prior to Ethereum if you wanted to launch your own dapp then you had to roll your own network. This led to a very bespoke environment where few projects were able to reach the network effects required to tip and go mainstream.
By enabling devs to launch their dapps on top of Ethereum, it enabled a huge network effect. This led to a wave of innovation around tokenomics, initial coin offerings, non fungible tokens or NFTs, decentralized finance or DeFi, yield farming, prediction markets, distributed autonomous organizations or DAOs, and so much more.
We view Avalanche as Blockchain 3.0 technology. Similar to Bitcoin and Ethereum, we're introducing a handful of new paradigms which we'll go over today.
We'll discuss how Avalanche Consensus is the 3rd major paradigm over 40 years in the field of consensus. We'll discuss how Avalanche is unlike most other existing blockchains in that it's a network of networks instead of a single virtual machine and set of validators.
We'll also dig into Virtual Machines, what they are and how they fit into the Avalanche network. Lastly, we'll discuss how Avalanche enables developers to spin up their own taylor made networks with custom virtual machines and complex validator rulesets.
First off, what is consensus? If you work in the blockchain space you probably hear the word consensus a dozen times each day but what is it exactly? Consensus is the process by which a group of independent validators come into agreement on a decision. So it's that simple, how do you get a bunch of people or machines to agree on a decision. It's a very rich field of computer science that goes back at least 40 years.
As I mentioned, Avalanche Consensus is the 3rd major paradigm in the field of consensus. The first was called Classical Consensus and it goes back to the 70s and 80s. Classical Consensus has low latency and very high throughput. It's lightweight and green. However it isn't very scalable nor robust and it performs poorly in adversarial conditions.
In 2008/2009 when Satoshi Nakamoto released Bitcoin the world was introduced to the 2nd major paradigm in the field of consensus, what ultimately became known as Nakamoto Consensus. Nakamoto Consensus is very scalable, robust and decentralized but it doesn't have low latency, as I mentioned it takes around an hour to be sure your transaction is sufficiently settled that you won't experience a reorg. It doesn't have high throughput, Bitcoin only does a handful of transaction per second. Of course I'm aware of 2nd layer solutions such as the lightning network. I'm referring to the layer 1 Bitcoin protocol and network here. It's not lightweight or green, as I mentioned Bitcoin burns more energy each day than some nation states. Lastly, Nakamoto Consensus performs ok in adversarial conditions up to the famous 51% attack.
In 2018 a pseudonymous group going by the name "Team Rocket" released a white paper on the InterPlanetary File System, or the IPFS, describing a 3rd major paradigm shift in the field of consensus. This new breakthrough was known as Avalanche Consensus. Avalanche Consensus is the perfect storm of features from Classical and Nakamoto Consensus.
It's very scalable, robust and decentralized. There are currently around 1500 full block and vertex producing validators on the Avalanche network. The protocol theoretically enables millions of validators so it's very decentralized. Avalanche consensus has low latency with subsecond immutable and irreversible finality. There is no notion of a reorg on Avalanche. Within a literal blink of an eye your transaction has settled completely. Avalanche has high throughput with 4,500 transactions per second. It's very lightweight and green and can be run on a PC, a Macbook, a VPS droplet on the cloud and in the future on Internet of Things devices. And Avalanche consensus is parameterizable so it performs very well in adversarial conditions.
Technically Avalanche is a metastable consensus protocol inspired by epidemic protocols and gossip networks. The process used to determine whether a transaction is preferred or not is referred to as "repeated random subsampling." Here is a great demo created by our Chief Protocol Officer Ted Yin. Ted was one of the creators of HotStuff, which is the classical consensus protocol behind Facebook's Libra or Diem network. He is now at Ava Labs working on Avalanche Consensus.
Here the squares represent different nodes, and the color of each square represents its current proposal. So, is this transaction blue or is orange. Briefly, it's worth noting that Avalanche consensus can handle non-binary decisions. So for example you can give it 5 options instead of 2 and it will still reach immutable and irreversible consensus. For the sake of this demo, and in most transaction related decisions we're going w/ a binary decision–blue or orange. The darkness of the color shows the node's conviction in that proposal. Does this node kind of think the decision is blue or does it really really believe the decision is blue.
When I click start each node will begin repeatedly and randomly sampling it's peers and changing it's own color and conviction based on the responses. Expectedly, all nodes will collapse to the same color in the end. You can see that it only takes a couple rounds of sampling and the entire set will tip and Avalanche into consensus. I'm going to play that again because I think it's so beautiful. It only takes a couple rounds of sampling and the entire set will tip and Avalanche into consensus.
So that's Avalanche consensus, which is the 3rd major paradigm shift in the field of consensus. Next let's discuss how Avalanche is a Network of Networks. As I mentioned Avalanche is different than traditional crypto networks like bitcoin and ethereum that have 1 virtual machine and 1 set of miners or validators. Avalanche is a network of networks w/ compound network effects.
To help visualize this I have a really great slide. Credit and shoutout to the amazing CryptoSeq. You can see the twitter handle at the bottom right. Please go follow them on twitter and check out their medium account for some incredibly deep and insightful posts on the blockchain. Thank you CryptoSeq.
Here you can see the grey oval represents the Avalanche network. Within the network are many different subnetworks or Subnets which are represented by the circles. In each of those Subnets are green squares which represent the different Virtual Machines or blockchains which are running on those Subnets. The lines between the Subnets show that you can move assets and users between the different Subnets. At the top you can see Bitcoin, Ethereum and Cosmos with lines representing the ability to bridge assets from those other networks into the Avalanche Network. Currently bridge.avax.network supports bridging assets from Ethereum into Avalanche and recently we announced Bitcoin support too. Since launch around a year ago, the Avalanche Bridge has over $500M in bridged assets between Avalanche<>Ethereum. In addition to bridging assets to Ethereum, Avalanche has also bridged more Bitcoin than is currently on the lightning network, around $120M. Lastly I can point out that we recently released Avalanche Warp Messaging (AWM) which is a new native Subnet<>Subnet messaging protocol with the ability for existing cross-blockchain messaging protocols, such as Cosmos' IBC or Polkadot's XMC, to be overlayed on top of AWM. We're huge advocates for interoperability and think that it's critical for the Blockchain to be as transformative as the Web.
I often say that Avalanche's Subnet architecture is primed for compound network effects and what do I mean by that? Most everyone has heard of network effects. Which technically are known as Metcalfe's Law. Metcalfe's Law says that a network's value is proportional to the square of the number of nodes in the network. For example, if a network has 10 nodes, its inherent value is 100 (10×10=100). In other words a product or service gains additional value as more people use it.
A great example of network effects is the telephone network. If only 1 person has a telephone then it's not very useful. For every additional person who plugs into the telephone network then the entire network grows in value for every other user. Perhaps the canonical example of network effects is money. If only 1 person accepts a currency then it's not very useful. For each additional person that accepts the currency then it becomes more valuable for every other user who can then use their currency for goods and services.
So that's network effects but what about compound network effects? Compound network effects are known as Reed's Law which states that the utility of large networks, particularly social networks, can scale exponentially with the size of the network as the number of possible sub-groups grows much more rapidly than either the number of participants or the number of possible pair connections. Even if the utility of groups available to be joined is very small on a per-group basis, eventually the network effect of potential group membership can dominate the overall economics of the system
Avalanche's Subnets are designed and primed for compound networks effects.
A Virtual Machine defines the application-level logic of a blockchain. In technical terms, it specifies the blockchain’s state, state transition function, transactions, and the API through which users can interact with the blockchain. Every blockchain on Avalanche is an instance of a VM.
The way to think of a VM is like a class in OOP. A class is a description or an object. It's a template from which you can instantiate as many objects as you wish. Each of these objects, though derived from a common template, are unique and logically separate entities with their own state. Similar to a class, a VM is a blueprint or template from which you can instantiate as many different instances of a blockchain as you wish. Each of these blockchains, though derived from a common template, are unique and logically separate entities with their own state.
As a developer when you write a VM, you don't need to concern yourself with lower-level logic like networking, consensus, or the structure of the blockchain. Avalanche does this behind the scenes so you can focus on the thing you would like to build.
At first, blockchain networks had one Virtual Machine (VM) with a pre-defined, static set of functionality. This rigid, monolithic design limited what blockchain-based applications one could run on such networks.
People who wanted custom decentralized applications had to create their own, entirely new blockchain network from scratch. Doing so required a great deal of time and effort, offered limited security, and generally resulted in a bespoke, fragile blockchain that never got off the ground and achieved the network effects required to tip and go mainstream.
As mentioned before Ethereum made a huge step toward solving this problem with smart contracts so that developers didn’t need to worry about networking and consensus, but creating decentralized applications was still hard. The Ethereum VM has low performance and imposes restrictions on smart contract developers. Solidity and the other few languages for writing Ethereum smart contracts are unfamiliar to most programmers. They're not very expressive and they don't fit into the rest of your development workflow.
Avalanche VMs (AVMs) make it easy to define a blockchain-based decentralized application. Rather than new, limited languages like Solidity, developers can write VMs in Go and using a gRPC API you can actually write your VM in a language other than Golang as long as your VM implements a certain interface. Your blockchain can run as a separate process from AvalancheGo and can communicate with AvalancheGo over gRPC. This is enabled by rpcchainvm, a special VM that uses go-plugin and wraps another VM implementation. The C-Chain, for example, runs the Coreth VM in this fashion.
rpcchainvm has two important parts: a server and a client. The server runs in its own process and allows the underlying VM's methods to be called via gRPC. The client runs as part of AvalancheGo and makes gRPC calls to the corresponding server in order to update or query the state of the blockchain.
In the interest of interoperability we have a VM called SubnetEVM which has 100% backward compatibility w/ existing EVM networks (Ethereum, Binance, Polygon etc) and smart contracts/dapps which run on our C-Chain and/or the SubnetEVM can be deployed on any other EVM network w/ very minimal work. Basically devs just need to add a new network ID and potential gas settings into their existing workflow and then deploy their contracts/dapp on the other network and everything should work out-of-the-box.
Lastly we have Subnet, or subnetwork, which is a dynamic set of validators working together to achieve consensus on the state of a set of blockchains. Each blockchain is validated by exactly one Subnets. A Subnets can validate many blockchains. A node may be a member of many Subnets.
So to visualize the heterogenous, or rich and diverse nature of the Avalanche network picture this. A VM is the application level logic of your blockchain. It's the template and can be instantiated into many different blockchains, some of which are public and some of which are private. A blockchain is an instance of a VM. Each blockchain is validated by exactly 1 Subnet. A Subnet can be on a spectrum of public to private and can validate many different blockchains, including many instances of the same virtual machine. A node can be a member of many Subnets, validating many many blockchain including many instances of the same virtual machine, some public and some private. Avalanche is truly a heterogenous network.
Subnets manage their own membership, and may require that their constituent validators have certain properties which is very useful.
Avalanche’s Subnet architecture makes regulatory compliance manageable. A Subnet may require validators to meet a set of requirements.
Some for example you can say that:
- All validators in my Subnet must be located in a given country or legal jurisdiction
- All validators must pass a KYC/AML checks
- All validators must hold a certain license
You can create a Subnet where only certain pre-defined validators may join and create a private Subnet where the contents of the blockchains would be visible only to those validators. This is ideal for organizations interested in keeping their information private.
In a heterogeneous network of blockchains, some validators will not want to validate certain blockchains because they simply have no interest in those blockchains. The Subnet model allows validators to only concern themselves with blockchains that they care about. This reduces the burden on validators.
Different blockchain-based applications may require validators to have certain properties. Suppose there is an application that requires large amounts of RAM or CPU power. A Subnet could require that validators meet certain hardware requirements so that the application doesn’t suffer from low performance due to slow validators.
Our mainnet launched in August 2020 w/ what we call the Primary Subnet. It has the X-Chain, C-Chain, and the P-Chain.
Now it's time for the demo where we're going to show how to spin up a local subnet with 5 validator nodes. We'll also launch a custom VM called SubnetEVM. SubnetEVM implements the Ethereum Virtual Machine and supports Solidity smart contracts as well as most other Ethereum client functionality. In the spirit of interoperability you can take any smart contracts which are live on any EVM chain (Ethereum, Binance, Polygon etc), change the network ID and deploy them to an instance of the SubnetEVM which is running on your custom Subnet and everything will work. You can then use Avalanche's Warp Messaging protocol to move assets between Subnets on Avalanche or you can use technology such as Chainbridge to bridge your assets to other EVMs.
We'll be launching a local subnet with a custom virtual machine using avalanche-cli. Avalanche-cli is a command-line tool which gives developers access to all things Avalanche specifically helping devs build and test Subnets. You can see that there are 4 major commands in avalanche-cli. Key lets you create and manage testnet signing keys. Network lets you manage locally deployed Subnets. Subnet lets you create and deploy Subnets. Transaction lets you sign and execute specific transactions.
Avalanche network lets you start and stop a local network. Also you can check it's status, which we'll do shortly and you can clean it up which stops a running network and deletes it's state. The Subnet command lets you create and deploy a new Subnet. It also describes a network. It'll list all networks. You can also import/export Subnet settings. You can also add validators or have your validator join a Subnet.
First we want to run the ./avalanche subnet create ETHDenverSubnet1 command. By default you can chose between SubnetEVM, SpacesVM which is an authenticated hiearchical key/value store, or a custom VM. We're gonna go w/ SubnetEVM. Next we need to enter a ChainID which can be any postitive integer. If you were launching this Subnet to production you would want to go to https://chainlist.org and make sure that you're not choosing a ChainID which is already in use by another network. Since this is only on localhost the chainID doesn't matter. Next select a symbol for your Subnet's token. I'll go w/ TEST. Which version of SubnetEVM do you want? We want the latest and greatest.
Next how would you like to set fees. We recommend low disk use / low throughput. Next, how would you like to distribute funds. Here you can airdrop some of the native tokens for your Subnet, in our case TEST tokens, to any address you wish. By default we have an address which we call the ewoq address because ewoq are the first 4 characters of the CB58 encoded private key. I'm going to use that here but if you were going to launch this to production you wouldn't want to do that since we share the ewoq key in our documentation and many different devs use it. In that case you would chose "customize your airdrop" and airdrop the tokens to an address which you control. Finally would you like to add a custom precompile. You can extend the functionality of SubnetEVM via stateful precompiled contracts. We have precompiles for restricting who can deploy a contract. For restricting who can submit transactions. For minting native coins. For configuring dynamic fees. And for changing fee reward mechanisms. None of which we're going to leverage in this demo.
Boom. You can see we Successfully created subnet configuration. We can call ./avalanche subnet list to see ETHDenverSubnet1 listed. We can call ./avalanche subnet describe ETHDenverSubnet1 to see a nice description of the details, gas config, airdrop and precompiles. Here you can see we're airdropping to the ewoq address. This is the hex address for the ewoq private key.
Also you can call . Next we need to enter a ChainID which can be any postitive integer. If you were launching this Subnet to production you would want to go to https://chainlist.org and make sure that you're not choosing a ChainID which is already in use by another network. Since this is only on localhost the chainID doesn't matter. Next select a symbol for your Subnet's token. I'll go w/ TEST. Which version of SubnetEVM do you want? We want the latest and greatest.
Next how would you like to set fees. We recommend low disk use / low throughput. Next, how would you like to distribute funds. Here you can airdrop some of the native tokens for your Subnet, in our case TEST tokens, to any address you wish. By default we have an address which we call the ewoq address because ewoq are the first 4 characters of the CB58 encoded private key. I'm going to use that here but if you were going to launch this to production you wouldn't want to do that since we share the ewoq key in our documentation and many different devs use it. In that case you would chose "customize your airdrop" and airdrop the tokens to an address which you control. Finally would you like to add a custom precompile. You can extend the functionality of SubnetEVM via stateful precompiled contracts. We have precompiles for restricting who can deploy a contract. For restricting who can submit transactions. For minting native coins. For configuring dynamic fees. And for changing fee reward mechanisms. None of which we're going to leverage in this demo.
Boom. You can see we Successfully created subnet configuration. We can call ./avalanche subnet list to see ETHDenverSubnet1 listed. We can call ./avalanche subnet describe ETHDenverSubnet1 to see a nice description of the details, gas config, airdrop and precompiles. Here you can see we're airdropping to the ewoq address. This is the hex address for the ewoq private key.
Also you can call ./avalanche subnet describe ETHDenverSubnet1 --genesis and pass in the --genesis or -g flag and get the same info as above but in a JSON format. You can then use this JSON structure as a config file when you're setting up and configing your validators.
Now we want to call avalanche subnet deploy ETHDenverSubnet1 and deploy our Subnet. Chose local network. This is now firing up a local network and paying the fees using the ewoq key. You can use a hardware wallet and a ledger for deploying to Fuji testnet or the mainnet. When it's successful it will output the RPC details for the 5 node local validating network. It'll also show the details for a single node so that you can add it to a wallet. We're going to use the Avalanche Core wallet but Metamask would work as well.
In Core add a new network. Paste in the details provided and then select that network. I've already imported the ewoq private key so you can see it has 1M TEST tokens for that address. Now let's deploy and interact with a smart-contract. We go to remix.ethereum.org. You can see the injected provider says Metamask but it's really Core. You can see the networkID is 1337 which was what we set for our local Subnet. The account is the ewoq account and it has the 1M TEST balance though it says ETH. I'm going to compile and deploy the "Storage.sol" contract. This is a very basic contract which lets us write a number to the blockchain and then reads it back to us.
I first compile then deploy the contract. It will fire up a Core popup window. You can see the account is "Imported Account 1". The network is "ETHDenverSubnet1" and we set the network fee then approve. The contract has been deployed and we can interact with it via remix. I first click 'retrieve' and it returns 0 because we've not yet written to the chain. I then write a number to the chain and approve the tx. Now when we click retrieve we get that same number back, showing that we were able to create a subnet and custom SubnetVM blockchain, deploy it to a local network with 5 validating nodes, write to the contract and read back from the contract. As I mentioned in the spirit of interoperability you could use AWM to move these TEST tokens, or any other value bearing assets that we created on this Subnet, between Subnets on the Avalanche network. Or you could use briding tech such as Chainbridge or the Avalanche bridge to bridge these assets to other blockchain network such as ETH or Bitcoin.