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.

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.

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.

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:

And the best news: App chains are already being tested!

A longer-term solution (think 3-6 months) could be subnets, an idea discussed in this post from Stacks founder, Muneeb Ali.

Our very own Jude Nelson expands on his interpretation of subnets and how they might work in a recent post here.

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.

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.