Subnets: Supercharging Scalability on Avalanche
The Avalanche ecosystem has experienced tremendous growth over the past year. With over $12B TVL, and over 70,000 daily active users, Avalanche has become one of the largest hubs for DeFi outside of Ethereum.
The growth Avalanche has experienced has come without one of the core value propositions even existing yet. This value proposition is Avalanche’s subnet architecture, which allows for the creation of highly customizable blockchains or set of blockchains that are validated by a specific subset of Avalanche validators.
Current State of Avalanche
Most activity on the Avalanche network occurs on one of 3 chains (X,P,C) on the primary subnet (subnet containing all Avalanche validators).
X-Chain (Exchange Chain) – The X Chain acts as a simple payments chain that is optimized for basic UTXO transfers and simple NFT minting. Transferring assets on the X Chain is less expensive than transferring assets on the C Chain.
C-Chain (Contract Chain) – The C Chain is an EVM smart contract platform that allows for the creation of Dapps like Trader Joe, Pangolin Exchange, and Aave. This is where the majority of end-users are currently interacting with Avalanche.
P-Chain (Platform Chain) – The P Chain is responsible for the coordination of Avalanche validators and is the chain used to create and manage subnets. In the future, we could potentially see hundreds or even thousands of subnets existing on the P Chain.
All Avalanche validators must validate all three of these chains, also known as the Primary Network as they form the baseline of Avalanche. Requiring all validators to validate the Primary Network makes the connectivity between subnets much easier to implement and feel much more native.
The addition of subnets give validators the opportunity to validate additional blockchains on Avalanche. So why would one create a subnet?
Fully Customizable Scalability
A subnet on Avalanche can be thought of as a Layer 2 on Ethereum or a parachain on Polkadot, but with a fully isolated state (no shared security), and more flexibility in design and implementation. Anyone on Avalanche can freely create a subnet whenever they want by burning 1 AVAX token and paying some small additional fees.
There are no rules when creating subnets. Subnets can include multiple blockchains, unique virtual machines, rules sets, and requirements for participation. This makes the possibilities of subnets virtually limitless.
You can think of subnets like a zone within the Cosmos ecosystem, but with the added benefit of having direct access to a set of validators ready to start validating your subnet’s blockchain(s). Validators on Avalanche will simply add your subnets ID to their node configuration and download the custom VM binary used. Once complete, validators will begin syncing to your subnet and start to validate.
Source: Why Avalanche (AVAX) has the potential to be an incredible store of value, Seq
Application Specific Subnets
As usage of Web 3 protocols continue to grow, more and more networks will experience throughput issues. For example, the C Chain on Avalanche has a transactional throughput of ~4,500 TPS, which is very high in comparison to Ethereum. That said, as demand for throughput on the C Chain grows, transactions will become more expensive and slower for end-users.
Creating an application specific subnet removes the need of having to compete with other applications for network throughput. This will ensure that end-users of your application will always experience cheap and fast transactions.
Permissioned & Semi-Permissioned Subnets
Creating permissioned & semi-permissioned subnets can offer privacy and regulatory compliance to organizations when transacting on subnets. Requirements for accessing permissioned subnets can include special licenses, being located in specific geographic locations, or having accredited investor status. This will allow for fully-compliant financial products and applications to be built on subnets.
Subnets can also require validators to meet certain criteria including operating on special hardware like supporting trusted execution environments, having high validator uptime, and passing KYC checks.
Scalable Subnets
ZK-rollup and optimistic rollup based subnets can be created for process-intensive applications like decentralized gaming and enterprise-level computation.
Interoperable Subnets
As the number of subnets grow on Avalanche, the need for interoperability between subnets becomes more important. Cross-chain transfers between subnets can be managed by a special subnet similar to Connext or Wormhole which will allow assets and data to freely move between subnets without having to transact via the X Chain.
Economics of Subnets
As mentioned before, there are no rules when it comes to building subnets. This means that we can see a wide variety of token economic designs on Avalanche subnets with distinctive fee structures, incentive mechanisms, economic primitives, and slashing mechanisms.
Implications for Validators & AVAX Delegators
Building a subnet on Avalanche gives developers instant access to a set of validators, but unlike parachains on Polkadot where security is guaranteed as long as you are a parachain, subnets need to incentivize Avalanche validators to validate their subnets.
Incentives for validators can be completely customizable, including earning rewards in the native subnet token, which means that Avalanche validators can earn multiple different tokens, including AVAX, by validating multiple different subnets with a single validator. This has the potential to greatly increase the yearly reward rate for running an Avalanche validator, which is currently around 10% APY.
Avalanche validators can distribute a portion of their new subnet rewards to their delegators in order to incentivize more delegations. It would not be surprising to see airdrops and high reward rates on new subnets in order to incentivize validators early on.
Roadmap/What to Expect
Since Primary Network launch, or “Mainnet”, it has been possible to create your own subnet/pre-defined VM instance on Avalanche. Since July, it has been possible to run a custom VM using the AvalancheGo RPCChainVM interface (communicates over gRPC with any VM). You can view the short list of custom chains here: https://explorer.avax.network/blockchains.
There are 10x as many on Fuji: https://explorer.avax-test.network/blockchains.
Over the next few quarters, Ava Labs will be adding permissionless validation (join a subnet by staking some custom token), incentivized subnets (P-Chain managed reward mechanism), and cross-subnet transfers. Now is the best time to start experimenting with your own VM and subnet so that you are prepared to hit the ground running/train up validators on your VM before all the attention shifts to it.
Useful links:
- Docs
- Creating a Custom Subnet
- Creating a Custom Virtual Machine
- GitHub (Custom VM Testing)
We have been long-term supporters of the Avalanche ecosystem, and look forward to supporting Avalanche subnet development. We are actively looking to help coordinate the launch of subnets through validation, sourcing other validators, and joining multi-sig subnets until permissionless subnets launch. Feel free to reach out to clayton@figment.io to learn more about what Figment can do for your subnet.
Special Thanks
Thanks to Patrick O’Grady and the rest of the Avalanche team for supporting the writing of this!
