Recently, I’ve seen questions around Stacks scalability and potential optimizations that can be made to network capacity. The scalability properties of Stacks and design tradeoffs are unique and it’s worth understanding them to put various pieces together.
Let’s jump in!
First, there are two categories of design decisions any blockchain network needs to consider:
-
Hardware and cost assumptions for nodes: it makes a big difference if a network is designed for the average users i.e., people with average network bandwidths and off-the-shelf computers (like laptops) or designed for data center nodes.
-
Consensus algorithms: different consensus algorithms have different trade-offs. Whenever you are gaining something (e.g., instant finality) you are gaining it at the cost of something else (e.g., ability to route around failures).
Hardware:
For hardware requirements and the cost of running a node, it’s really a decentralization question. You can optimize for (a) average users with laptops, (b) higher-cost hardware but still something users can run at home, or (c ) data centers only (no home nodes can be possible).
An example of (c ) is Dfinity, where you can’t be a miner unless you operate a data center node with bandwidth connections that meet a minimum criteria (which home nodes cannot meet). An example of (b) is Solana where the hardware requirements are quite costly and they’re already moving towards category (c ).
Stacks is designed for category (a) i.e., any user can run both a Stacks miner and a Stacks full-node simply on a normal laptop at home.
This is a decentralization decision.
Stacks is designed to maximize decentralization (like Bitcoin). That does not mean that faster transaction or high-throughput cannot happen with Stacks but it’ll likely come in the form of subnets (explained below) or app-chains (another scalability proposal).
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.
Consensus:
In terms of consensus algorithms, there are a few tradeoffs that impact throughput:
Closed membership vs. open membership: If the group of miners allowed to mine is closed meaning that nodes cannot freely join/leave at will then you can get much higher throughout. An example of this type of consensus is Dfinity or EOS. You score very low on decentralization but then can process blocks faster (because you already know who the miners are and it operates more like a federation of nodes which is a well-studied area in distributed systems).
Stacks is an open membership system (like Bitcoin). Anyone can become a miner at any Stacks block. For subnets you can relax this requirement a bit (e.g., miners can be selected in advance for a series of blocks) to get higher throughout. The important thing to understand is that for maintaining decentralization it’s critical that the Stacks main chain is open membership.
Instant finality vs. Nakamoto consensus: Some newer L1 PoS chains offer instant finality. The key thing to understand about instant finality is that you get it at the expense of the ability to route around failures (amongst other things), which in the end is a decentralization concern.
Stacks main chain follows a Nakamoto-style consensus, meaning that similar to Bitcoin independent miners can fork around any catastrophic failures without requiring hard forks. Subnets can pick different tradeoffs but it is critical that Stacks main chain is able to automatically route around failures without manual intervention for hard forks.
Current Network Capacity:
With this general framework in mind, let’s look at the network capacity of the Stacks main chain.
Just by looking at the choice to optimize for average nodes (like laptops) we know that Stacks main chain is not a “datacenter chain”. The throughput for Stacks main chain is roughly going to be somewhere between Bitcoin and Ethereum. Ethereum often gets criticized for reliance on infura. Most ETH 1.0 nodes run in the cloud. People can try this on their own: if you run geth on your home network, it’ll eat all your available bandwidth. The lesson from Ethereum is that you want to have explicit scalability solutions instead of putting so much load on the main chain that it can no longer be run by average home nodes.
Stacks main chain can theoretically do approx 1.67M simple transfer operations (for STX) in a day. These STX transfers are highly optimized and fairly simple from a compute cost perspective, so they can serve as an indication of current theoretical max throughput for simple operations (main chain).
For comparison Ethereum today does approx 1.2M transactions per day. However, these include contract calls which are more complex (not just simple transfers).
To understand the real throughput of the Stacks network, you need to think in terms of capacity bottlenecks. There are two limits that you typically hit:
- Runtime costs i.e., compute costs.
- I/O limits i.e., reading and writing data.
Stacks developers did an analysis of current network traffic and approx 68% of recent traffic was bound by compute cost and and 31% by I/O. The key thing here is to not think of the system’s capacity in terms of transactions, since the transaction’s size has nothing to do with the compute resources it uses. A contract-call can easily eat a double-digit percentage of one of the block’s runtime dimensions (think of it like a 100-kilobyte Bitcoin transaction). The important thing here is, if they’re paying for those resources at a higher metered rate than anyone else then it makes sense that these transactions get mined first.
Network Growth:
Since the launch of the Stacks mainnet in January 2021 by independent miners, the Stacks community has seen great growth: there’s dozens of startups going through the Stacks Accelerator, devs are tinkering with all parts of the technology, and new people join our community every day. While this growth is obviously a good thing, the additional traffic is also pressure testing parts of the underlying infrastructure that we all use and independent miners operate, and it is highlighting a number of areas in which improvements are needed.
There are three categories of improvements:
- Minor updates
- Consensus-breaking changes
- Scalability layers
Minor updates are non-consensus breaking meaning that the rules of the system do not change but software upgrades can help improve various things. Such upgrades are part of the normal lifecycle of any software. Stacks is open-source software and anyone can make minor improvements to the software and independent miners and full-node operators can upgrade their software. Any previous version of the software remains compatible with the rules of the system and continues to work on the network.
Consensus-breaking changes can only be deployed by miners following the SIP process. During consensus-breaking changes, new rules can be introduced for the system or previous rules can be modified. Deploying consensus-breaking changes is a well-understood concept in blockchains and Stacks roughly follows the Bitcoin philosophy i.e., deploying consensus-breaking changes is very hard and a high threshold of miners need to support such major upgrades.
Scalability layers are “add ons” that don’t impact the Stacks main chain. They should be thought of as optional additional features that anyone can deploy and use and typically require no input from miners. Both app chains and subnet proposals are scalability layers meaning that they don’t touch consensus and are optional add ons that anyone can deploy and use as they see fit.
Potential Improvements in the Coming Months:
For any scalability improvements, everyone needs to understand that Stacks is a fully decentralized ecosystem. Miners decide what upgrade (minor or major) they want to deploy or not. Hiro for example is not a miner and does not even know who the miners on the network are. So the open-source community will need to self-organize, following the processes laid out in SIPs, to help improve things that they care more about.
My lens on potential improvements is to divide them in the three categories laid above:
-
In the coming weeks, only minor upgrades (non-consensus breaking) are possible, which can be quite effective nonetheless. For example, new cost estimates can go live through a cost vote (that is allowed by current consensus rules).
-
In the 3-month timeline, Stacks 2.1 release could help with a bunch of these.
-
In the 6-month timeline subnets or app chains could provide scalability, which are the more sustainable long-term scalability options anyway.
The Stacks ecosystem is fully open source, and anyone can help with any improvement they care more about. We’re operating in a fully decentralized landscape and it’s important to highlight ways in which this ecosystem is different from others and can be more resilient long-term through decentralization, similar to Bitcoin.
With that context in mind, let’s look at potential things in the short-term:
Things that can help:
-
Smart contract runtime and compute costs are currently treated as if they will cost significantly more than they actually do. This significantly limits capacity for the Stacks chain but is fixable. There can be a cost-vote as outlined in SIP-006 to implement potential improvements pre-Stacks 2.0. The cost-vote process would require participation by Stacks holders.
-
From what I’ve seen, the coming Stacks 2.1 release could help with a ton of improvements. Discussion is linked here.
-
Subnets or App-chains can be implemented in the next ~6 months that could allow more optionality and features for end-users and developers alike. I’ll share more details on my thoughts about subnets in the coming days, but sharing a quick summary of the idea here to start. As mentioned, the Stacks mainchain is optimizing for decentralization and independent verification. Anyone can independently verify it’s the correct version, and anyone can run a node. This is an intentional design decision as you want average laptop nodes to be able to connect, although a tradeoff is that your effective bandwidth on the mainchain is going to be relatively small. A healthy fee market will emerge for the main chain (which also means higher Bitcoin rewards for Stackers!). The block space on the main chain will always be scarce and expensive (like Bitcoin) but you can scale around it.
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.
As we think through and implement solutions, it’s also important to keep in mind that the Stacks ecosystem follows an open decentralized process for implementing gradual changes (like Bitcoin) vs. overnight changes dictated by a central authority.
Developers launching their apps and contracts in the coming weeks can:
- Use better benchmarking tools to get a sense of costs on the network, and set expectations (e.g., better default gas fees) with their users.
- Can monitor the cost voting process to see if launching after better cost estimates go live makes more sense. Cost voting does not need to wait for Stacks 2.1.
- Follow the subnets proposal and upcoming development to start thinking about how their app can evolve in the 6 months+ window with solutions like subnets or app chains.
Thanks for taking the time to read and I look forward to what you all have to add to this!
– Muneeb | Stacks founder
