Contents
[Note: Developers across the Stacks ecosystem are contributing to SIP022, a fix related to Stacks 2.1 POX-2 contracts. There may be some delays in responding to subnet related requests until this issue is resolved. For more information please go to the Stacks forum.]
What Are Subnets?
Subnets are a scaling solution for Stacks designed to handle high throughput, low latency workloads. Subnets are an ideal solution for things like a DeFi marketplace or an NFT mint that have a high volume of time-sensitive transactions. Subnets provide a way to handle those workloads without congesting the main chain, which leads to problems in the user experience (transactions get stuck in the mempool, transaction fees skyrocket, etc).
Eventually, we believe there will be a wide range of subnets, each optimized for different use cases and leveraging different consensus protocols. Each subnet exists as an independent layer on top of Stacks, and users can opt-in to various subnets depending on their needs. A choose-your-own-subnet, if you will.
Since subnets exist as a layer above the Stacks blockchain, where transactions happen on a subnet and then ultimately settle on the Stacks blockchain, subnets also provide an opportunity for developers to experiment with cutting edge technologies without requiring any protocol changes to the Stacks blockchain itself. For example, subnets are an ideal environment to explore Bitcoin rollups, EVM-compatibility and zk-proofs on Stacks.
The Story So Far
Last summer, we launched a light-weight version of subnets on testnet that enabled developers to experiment with NFT deposits, withdrawals, and conduct preliminary research for usability and performance.
In the second half of 2022, contributors across the broader Stacks ecosystem shifted focus toward the preparation for the 2.1 network upgrade (which went live last earlier this year!). This was a critical effort that brought a number of important upgrades to the ecosystem, and in the process, we prepared all of Hiro tooling for 2.1 compatibility, including subnets. Tl;dr we updated subnets to be compatible with Stacks 2.1 and improved the throughput and block confirmation times.
Along with 2.1 compatibility, we have also released a number of other critical work relating to subnets in the past few months, including:
- Complete multi-miner support: The latest node implementation supports all of the features necessary to use an n-of-m federation of miners, in addition to the simple, single miner option.
- FT withdrawals: When we first launched subnets on testnet, we built out an NFT use case, and in the time since we have added the ability to move fungible tokens back and forth between the Stacks blockchain and subnets.
- Canonical Clarity VM: The previous implementation used a modified version of the Clarity VM to support the special subnet operations. Since then, we have rewritten the deposit and withdrawal implementations so that the node can use the canonical VM.
- Error handling: Various error scenarios are now properly handled by the subnet node.
- Improved microblock implementation: Due to the controlled mining scenario in a subnet, the microblock generation process can work quite differently from the way it works on mainnet. This implementation is in progress on the subnet, and the goal is to enable consistent, reliable, low latency microblocks.
- End-to-end developer experience: Our focus has been to provide a seamless Dev experience using and building subnets. We have updated our Stacks API, Clarinet, Stacks.js, Explorer to provide a holistic Subnets experience. This means developers can use the API to query data on a subnet or write new transactions to it, and you can view subnet transactions on the Stacks Explorer. Subnet wallet support via the Hiro Wallet is in progress.
What Happens Now?
With this release, it’s time for you to start coding. We are battle-testing our subnet on testnet, and you now have an end-to-end developer experience to begin your own work building on a subnet in a local devnet environment.
We have built a holistic subnet developer experience around the NFT use case, meaning developers can experiment with everything from wallet support, contract testing and development to etc.
Important to note that interacting with a subnet in a local devnet environment is different from interacting with the alpha subnet Hiro has live on testnet. As a safety feature, subnets require a predefined list of whitelisted contracts that the subnet can interact with. In the local devnet subnet, the developer has control to register their own contract to the set of allowed contracts, but on the alpha subnet Hiro has on testnet, only Hiro has permissions to whitelist contracts.
Eventually, there will be a process for developers to register and whitelist new contracts for the Hiro-maintained subnet on testnet. We envision a community-driven and community-owned whitelisting process on mainnet, more on this to follow. For now, you can interact with a full-featured subnet on your local machine and register whatever subnet contracts to it you like.
This implementation of subnets is in Alpha. What does that mean? It’s ready for developers to experiment with and test out, but there are some known stability issues that we are continuing to work on. We are continuing to optimize the subnets performance for higher throughput and faster block confirmation times and will incorporate feedback from the Stacks developer community. We anticipate that this implementation of subnets will be ready for mainnet later this summer.
Get Started With Subnets
If you’d like to get started with subnets, check out the subnets Github. If you need help or have questions, register here for the community support call scheduled for 12:30 ET on Monday, May 1st.
Please submit any issues, feature requests or bug reports on GitHub.
If you are part of a developer team interested in running a subnet on mainnet, let us know! Reach out on Discord or register for the community call on May 1st.
