Coming Soon
The Next Era In Scaling Stacks
What might be ahead for Stacks builders in the coming weeks and months?
by Mitchell Cuevas on October 8, 2021
Feeling technical? Feel free to skip right to Github and the forum:
App Chains
Subnets
Short-term improvements
Note: This post is my interpretation of information gathered from public blockchain related meetings and posts on the forum and Github, it is not a guarantee that any of this will be built or play out in the way outlined. It is also in no way meant to commit to any timelines on behalf of the developers taking on this challenge—its purpose is simply to surface the information to encourage broader community understanding and involvement.
Scaling Stacks
In spite of what clever marketing might lead you to believe, blockchains do not, in fact, scale. There will always be a tradeoff between speed and decentralization, each coming with its own set of problems and opportunities. Every protocol you can name simply offers us different tradeoffs and the same is true of Stacks.

In the case of the Stacks blockchain, very specific decisions to ensure security and decentralization were made, necessitating a tradeoff in speed and capacity. We won’t go into specifics of those decisions in this post, so I highly recommend taking a look at this forum post by Muneeb Ali, Stacks Founder: Framework for Stacks Scalability.

So with the network facing congestion at times in the past few weeks, what are we to do? Are we stuck with either slow or safe? Will you forever be frustrated trying to mint the latest NFT drop?!

No! The good news is that although individual blockchains can’t scale, networks most certainly can. Better still, we can even allow developers to make their own speed and security tradeoffs without dictating one set of options for the whole network. And better even still, a number of efforts in the Stacks ecosystem are already underway to give developers the tools to make their own decisions, while still benefiting from the features of Stacks and the security of Bitcoin settlement.

A simple idea to keep in mind while reading through the outlines below is that what’s ideal for one application might be terrible for another. For example, an appropriate tradeoff for a DEX may not be feasible for an NFT marketplace. The secure scaling solutions outlined below are coming together with modularity and choice as guiding principles thanks to Stacks core devs across the ecosystem.
Short-term wins
The current network is operating at an artificially low capacity because of cost functions, meaning optimizing these functions would immediately give current builders more wiggle room and reduce congestion. While not a permanent solution, removing these artificial capacity constraints are changes that can help builders out in a matter of weeks vs. months.

Early research by developers at Hiro suggests builders can leverage more optimized cost functions to get 10-17x increases for contracts like BNS. The MARF implementation has also been a bottleneck, and the same research indicates potential for 20-40x improvements there as well.

A note about microblocks: These are live on the network already and enabled by some miners, but are NOT a scalability solution, they simply allow faster transaction confirmations. There’s been some confusion about this in the community, if you want to learn more about microblocks, please read this post from Hiro.
The Next Era
It’s exciting to see that we’ve reached a point where further scaling already needs to be addressed. No one anticipated reaching full blocks on Stacks this quickly, and we shouldn’t forget to celebrate that even as congestion can be frustrating, it’s a credit to all the exciting applications, NFTs, and platforms Stacks builders are creating. But, we can’t stand around and be happy about it, we need to clear the way so these builders can have runaway success without the risk of impacting their user experience.

Below, I’ll outline my current understanding of the various scaling options being discussed at a high-level and borrow heavily from posted resources. For specifics, I’ll link you toward further reading on Github or the forum where you can get deeper into the conversation and offer feedback.
⛓️ App Chains
As noted, blockchains can’t scale, but a series of blockchains can. Imagine a future where the Stacks network is not one chain, but where one underlying chain serves as something of a backend to many chains on top. These chains all anchor back to Stacks and therefore to Bitcoin, but they can have everything from their own block sizes, miners, and incentives structures.

Jude Nelson describes it here:
The PoX consensus algorithm in Stacks lets it use the hashpower of Bitcoin to securely host its chain structure. With a couple modifications, it also allows an instance of the Stacks blockchain to use another instance of the Stacks blockchain to host its chain structure as well! PoX generalizes: many, many L1 blockchains may run at varying degrees of separation between themselves and Bitcoin, but Bitcoin will commit to the chain structures of all of them.
The appchain approach makes Stacks a composite blockchain. You can add more capacity to the Stacks blockchain by adding more appchains. Instantiating an appchain is just a matter of deploying a specially-crafted smart contract that can store the relevant mining state. Just as with Stacks and Bitcoin, each appchain's blocks are hashed to a single transaction in the host chain, so to host chain nodes, mining an appchain just looks like doing a particular contract-call? transaction.

The reason this scales is because the host chain doesn't need to know or care about the state of its client chains(just like how Bitcoin doesn't know or care about Stacks). Only the people who want to use your smart contracts need to run nodes for your appchain; everyone else can ignore it entirely.
And the best news: App chains are already being tested!

Subnets
A longer-term solution (think 3-6 months) could be subnets, an idea discussed in this post from Stacks founder, Muneeb Ali.
Subnets can be thought of as an extension of the core main Stacks chain. Subnets can score lower on the decentralization side but once you score lower on decentralization you can score very high on the speed of transactions with low costs. And if you combine that with the main chain, now you’re getting the best of both worlds.

The general model here is to scale in layers around Bitcoin. Stacks itself can be thought of as a smart contract layer for Bitcoin, and Stacks can then have subnets that make different decentralization/throughput tradeoffs than the Stacks main chain.
Our very own Jude Nelson expands on his interpretation of subnets and how they might work in a recent post here.
From what I've been able to gather, a Stacks subnet is shaping up to be a system that, at a high level, makes a lot of similar guarantees to sidechains and drivechains. It has the following properties:

  • High-power Nodes: system liveness is driven by a set of network participants that are selected by stackers. These nodes can have high bandwidth links and compute power(e.g., datacenter nodes) unlike the Stacks main chain that needs to remain open to mining from normal laptops.
  • Instant finality: Once a transaction is sent and applied to the subnet state, it stays applied. The Stacks mainchain can fork around failures like Bitcoin. Subnets don’t have to and can optimize for speed by not allowing forks.
  • Routing with main chain: Assets on the subnet originate from the Stacks chain(users can send a transaction to the subnet contract to transfers assets to it). Users can then interact with apps and contracts deployed on the subnet at high speeds and low gas fees e.g., a DEX and eventually withdraw their asset back to the main chain.

However, they're neither drivechains or sidechains because they operate under a totally different incentive model, which I outline below. In fact, they're not even blockchains.

What I suspect subnets will look like instead is a"super Lightning channel," inspired by Bitcoin's Lightning protocol:
  1. A set of users lock up their assets on Stacks in order to materialize them on the subnet.
  2. Subnet nodes begin relaying and processing off-chain trades between these users.
  3. Eventually, the subnet terminates; at which point, the final state of the subnet is applied to the state of its users' on-chain accounts as one large state-transition.

Crucially, users drive forward progress on this system, since they are the only party here with a financial incentive to do so.
Read write-ups from the forum and Github to learn more about Subnets

State Channels
State channel approaches, like lightning in Bitcoin or more generalized fraud-proofs approaches like Arbitrum, can also be explored. These approaches use layer-1 verifiable proofs to materialize layer-2 operations in a trustless way, without a second layer of mining. These as a scalability solution for Stacks needs further exploration and research. The key thing here is because Clarity is a general-purpose language; any scalability solution (roll-ups, fraud proofs) can be implemented in Clarity. In other words, any progress on scalability in the crypto industry can be brought to the Bitcoin ecosystem now. Stacks scales around Bitcoin in layers, with BTC being the decentralized money layer itself.
Conclusion
As always, changes of this nature to the Stacks protocol require a SIP, community input, and the miners to adopt and implement those changes, in some of these situations, via hard fork. We’re thankful to all the developers in the community working quickly to address this exciting demand and look forward to seeing their work continue to unfold via Github, SIPs, and forum discussions. On our end, we’ll do our absolute best to stay on top of these developments and communicate about them to all of you.

If you’re interested in jumping in on some of these, or have other scaling ideas and feedback, please join the relevant discussion on Github.


Mitchell Cuevas leads partnership and growth efforts at the Stacks Foundation. He's spent the last decade working in community-driven high-growth startups.