Stacks Roadmap and Product Vision Update

:wave: Hey Stacks community!

The journey to Stacks 3.0 (Nakamoto) and sBTC has been thrilling, and to keep pushing forward, your insights are needed to shape Stacks’ future. As such, you’re invited to engage with the upcoming roadmap series to make your voice heard on next steps and priorities. We’ll be facilitating sessions both technical and non-technical, surfacing thoughts and ideas from all layers of the ecosystem, seeding key discussions, and supporting further research, decision-making, and clear ownership wherever needed!

This initiative will see a re-commitment to the Stacks Forum as the hub for significant, in-depth discussions on technical, governance, product, and community aspects. What better way to begin than by discussing the Post-Nakamoto, Post-sBTC roadmap? Our north star remains Activating the Bitcoin economy, with a particular focus on establishing sBTC as the dominant Bitcoin asset across crypto through enhanced decentralization and security of both sBTC and the Stacks layer. Here’s where we start:

Key Priorities to Include

  • Boosting sBTC capacity and enhancing network performance with an eye on increasing sBTC utility and reach
  • Enabling overall network traction, TVL growth, and liquidity for builders
  • Expanding sBTC listings and delving into stablecoin integration.
  • Exploring unilateral exit options for sBTC to increase user autonomy.
  • Exploring options for increased interoperability of the network

These are just high-level aspirations; we need to dive deeper into specifics then set ecosystem-wide priorities so that individual contributors can plug in and support specific deliverables. The aim here isn’t just a technical roadmap but will also include exploring paths for governance improvements and product & community growth, ensuring a comprehensive approach to Stacks’ evolution.

Why Now?

  • We’ve successfully navigated the intense, 25-month journey of upgrading Stacks and launching sBTC.
  • To educate and engage the broader market by showcasing Stacks’ vision for the future.
  • To solidify our community’s direction and align it with the evolving landscape of Bitcoin layers.

Rollout Plan

  • Phase I: Cast a Wide Net (Now - Feb 21st)
    • Share your roadmap ideas in the comments below - focus on problems to solve, features to enhance, and how to measure success. Be sure to frame your suggestions in the following manner:
      • Problem Statement: Outline:
        • What the problem you feel needs to be solved and/or
        • What the feature you feel needs to be enhanced
      • Solution Statement: Outline:
        • What is expected impact and
        • How success will be measured
  • Phase II: Community Call 1 (Feb 21st)
    • Join us to review forum feedback and converge on priorities
    • Define roadmap tracks and identify track leads
  • Phase III: Track Development (Feb 21st - Mar 21st)
    • Dedicated forum threads for each roadmap track
    • Weekly track calls with published summaries
  • Phase IV: Memorialize & Milestone (Mar 21st - Apr 11th)
    • Synthesize track discussions into formal roadmap
    • Scope milestones, identify required SIPs, and define success metrics
  • Phase V: Community Call 2 (April 11th)
    • Present comprehensive long-term roadmap

Join us for the Roadmap Kickoff Call on February 12th at 3pm EST (X Space) to hear early thoughts from key Stacks engineering, product, and community contributors.

We urge you to begin sharing your feedback now. This open, iterative process will culminate in a published long-term roadmap by end of April.

Let’s collaborate to build a vibrant, sustainable ecosystem.

:point_down: Share your roadmap ideas below!

9 Likes

This is a really cool initiative!

2 Likes

“Solana-like speeds with Bitcoin finality.”

Great post Wil and good overview of target goals. Especially like unilateral exit as an option for sBTC.
That said I’ll jump straight to a more important point IMO.

As mentioned, we just completed a crazy 25-month grind to get sBTC and Nakamoto over the line. Amazing job by everybody. That North Star was compelling and the teams delivered.

If I look at the next 24-month North Star. None of these are compelling enough.
They are great targets to work towards, but they don’t inspire the community.
Network performance relating to consistent block confirmations can be something devs work on in the background without the general community knowing.

IMO. We need to have a discussion about massively increasing the hardware requirements. The crypto space has learned a lot since Stacks launched. Mainly on the topic of how robust and reliable a performant blockchain can be. The market is speaking in mcaps on how it sees the future going.

So the question comes down to:

  • Are we good with aiming for higher decentralization and scaling through layers, which introduces friction?
  • Or do we aim more for “sufficiently decentralized” and scale much better on the L1?

I bring this up because I dont see anyone talking about it publicly. And the arguments for max decentralization are much weaker with the Nakamoto signer set. It doesn’t seem like we’d have any issue getting 50 signers to run more demanding hardware. Maybe im wrong?

7 Likes

This is good stuff! Looking forward to the 21st!!

2 Likes

1000x this

why settle for as fast as solana. lets be 100x faster

2 Likes

use $WELSH for gas fees on Stacks:)

1 Like

Agree with Jake, low-level hardware requirements and limited network capacity has been the biggest obstacle of the whole stacks ecosystem, i elaborated details on the my yesterday’s post
x.com

Stacks aims to be ia scalable smart contract layer of bitcoin, putting network performance for first priority is within our initial target and original intention.

5 Likes

My understanding is that a big part of the solution here is the next version of Clarity using WASM or Move/Rust, reportedly will use compiled contracts instead of interpreted contracts. This greatly increases the capacity of the Stacks mining nodes with whatever hardware they are currently using. ie, should increase the amount of transactions per tenure and TPS. This should be a BIG improvement without impacting node hardware costs and decentralization.

I have read comments on X and TG about Stacks having low TPS compared to Lighting and other blockchains but they often don’t realize or take into consideration the big difference in the processing required to send simple value transfer tx’s versus large and complicated smart-contract tx’s.

Clarity wasm/move/rust… whatever is the next version I’m really looking forward to.

3 Likes

We may not reach Solana level but it’s easy to reach BSC or Tron performance level at first.

1.Hardware requirements enhancing:

Solana requirements: 512G RAM,10Gbps bandwidth
Tron and BSC requirements: 128G RAM, 1Gbps bandwidth
ETH requirements: 32G RAM 100Mbps bandwith

Current Stacks nodes requirement:
Stacks nodes: 4GB RAM, no bandwidth requirements
Signers only: 256MB RAM no bandwidth requirements

In the past month 5 miners cost about 38btc, each miners cost average $760k per month for mining, minimum solo stacker got about $1000 value btc rewards,so it is easy for miners to afford 128G RAM hardware.

Thus we need upgrade miners’ hardware requirements to 128G RAM and 1Gbps bandwidth for about $1000/months, and signers requirements could be a bit lower 32GB RAM for about 160$/month.(some solo stackers may have high-performance personal computer then don’t pay extra node fees)

2.tenure budget improving (need hard-fork)

current tenure budget:
read_count: 15,000
read_length: 100,000,000
write_count: 15,000
write_length:15,000,000
runtime: 5,000,000,000

I calculated 20 full filled tenure from Stacks block 426309-426550,each tenure has average 34.6 transactions,and each tenure average usage:
read_count: 99%
read_length: 50%
write_count: 8%
write_length:4%
runtime: 4%

If we want improve TPS to Tron or BSC level about 100 TPS, and every Stacks block time is about 15s, once we decrease tenure-extend time into each Stacks block, that means we need to make every stacks block has 1500 txs,now every Stacks has average 2 txs.

In consideration that we will have to improve performance in the future, if we want to improve TPS by decreasing tenure time without hardfork, thus we have to improve tenure budget at one time as much as possible, so 500x bigger tenure budget is reasonable.

So we need improve tenure budget 500x to:

read_count: 15,000•500=7,500,000
read_length: 100,000,000•500•50%=25,000,000,000
write_count: 15,000•500•8%=600,000
write_length:15,000,000•500•4%=300,000,000
runtime: 5,000,000,000•500•4%=100,000,000,000

3 Likes

Its a comparing with same measuring method, explained this earlier.x.com

2 Likes

The way transactions are processed is downstream from the question of hardware requirements and decentralization. Underlying your answer to go the WASM/optimize clarity right is choosing to maintain max decentralization. Thats fine if we want to choose that. Lets just make it crystal clear that’s what we are doing.

For context. Solana is doing 5,000/TPS right now. Which includes simple transfers and smart contract things. And they are sprinting as an ecosystem towards an upgrade called Firedancer that targets 1m TPS.

The best estimates I’ve seen with WASM is a 100x improvement. 500/TPS.

Again to the community. There are lots of good goals to work on as a collective. Many that Will mentioned. The most important decision is likely to be this.
Monolithic L1 or L1 + Subnets and all that comes with that.

It’s Solana or ETH with Bitcoin finality.

4 Likes

agree with jake. it’s time to juice the hardware requirements.

personally think stacks should focus on scaling/improving the base layer before worrying about layers/subnets/etc. keep things as simple and intuitive as possible for now, and prove the sBTC+clarity value prop first.

4 Likes

I would like to see

  • simplified stacking, e.g. remove solo stacking and pool admins, enable business models for signers.
  • better support for miners, e.g. enable mining pools, public strategies, better monitoring tools, stacking rewards in sBTC.
3 Likes

Currently, the mempool is almost always empty, and transactions are confirmed very quickly, even with very low fees. However, since Nakamoto and the tenure extensions have been active, we’ve never truly put the chain under stress. The impression is that there’s very little on-chain activity, resulting in much faster transactions. Undoubtedly, increasing the hardware requirements could only improve performance. I understand the need to keep the process as decentralized as possible, allowing anyone to operate a node, but let’s also consider the entities contributing as miners and signers—can’t they afford higher-performance hardware?

As a developer, I exclusively use the services offered by Hiro Systems to sync my apps with the blockchain. I could operate a node independently for reading/writing data, but I would certainly not participate in the mining/signing process. Therefore, raising the hardware specifications to a highly professional level doesn’t seem like a decentralization issue to me. In practice, most users don’t participate in this process beyond stacking their funds—they’re definitely not operating nodes.

In the short term, I don’t see the possibility of reaching Solana’s speed unless the protocol undergoes a radical change. However, we could certainly surpass Ethereum while maintaining 100% Bitcoin finality.

An increase in read operations is necessary, as this represents the real bottleneck that has always paralyzed the chain during periods of intense activity. However, perhaps the concept of read count itself needs to be revisited. Limiting operations because there’s an excess of reads seems outdated. I’d understand if there were an excess of writes, as writing is typically a slower and more resource-intensive operation in terms of hardware. In my opinion, we should maintain a read/write ratio of 10:1 or even remove the read limitation entirely.

2 Likes

Everyone is aware of the benefits of super high TPS and super low fees but if I’m not mistaken Solana also has somewhat of a Tx spam problem because of this. True?

Q1: Is tx spam a real problem or not? What problems does it cause if any, DeFi attacks, something else, or is it relatively harmless?

Q2: what are other tradeoffs to the Solana model, if any, beside the hit to decentralization and maybe tx-spam?

Q3: Would it be better to keep the L1 speed and cost near where it is now and create a super-fast and super-cheap L2/subnet so that the L1 will not fill with spam?

Q4: How is the design of Avalanche and other chains that use subnets working out? How is their tx-performance and tx/user growth metrics? Is it clear from their results that this layered design approach is inferior to the Solana model from a technical standpoint and/or market performance?

I think much of this has been considered in the past when Stacks Hyperchains was a direction being discussed. Maybe this info/knowledge should be resurfaced and discussed again.

1 Like

More Q’s for discussion:

What is the drawbacks of having 100 subnets each doing 500 to 1000 TPS?
Why shouldn’t a chain grow/scale in this way?

Is there worse UX than the Solana monolithic model because of interoperability or can users traverse the subnets and move their assets seamlessly over them?

Similar Q for developers; could there be a unified API to make it easy for them to develop apps that seamlessly work across all subnets or would it be much more difficult than an API for a single monolithic Stacks chain?

again, have subnet chains like Avalanche shown the answers to these questions?

1 Like

What is the drawbacks of having 100 subnets each doing 500 to 1000 TPS?
Why shouldn’t a chain grow/scale in this way?

I mean, everything always comes down to implementation.

But if there’s 100 subnets, then users should be oblivious to it, and that seems tricky to pull off without fragmenting an already very small audience. And doing so before the value prop of the base layer has even been proven.

Stacks/Blockstacks is what, 8, 9 years old? And we still don’t know if people outside of a small number of us are interested in a project like this?

From my pov, remove as much friction as possible that doesn’t directly tie into the sBTC/Smart Contract use case. If there’s actually demand for it and the chain is working and the community is growing, subnets will still be there to tackle.

But at this point, it seems to me like the move is to simplify things instead of further expanding what sometimes feels like a monument to the software gods and not an actual, real world, useable product. And that doesn’t feel far away, smart contracts just have to be fast since they’re core to the value prop.

Juice the hardware requirements and move on. The financial costs involved in mining/signing prevent it from being decentralized on poor people running pi’s in caves anyway.

2 Likes

taking the path of not caring about centralization might be fine for some cohort of users but it could hurt attracting much BTC capital. Would you want to commit billions of $ to a chain controlled by a small number of entities?
So like Bitcoin, I think Stacks should stay “sufficiently” decentralized.

It’s been said that Solana has been gradually becoming more decentralized than where it was when it started but I don’t know the details of this. So obviously even to Solana decentralization is a consideration, if not just for network resilience.

Subnets and compiled contracts are just two ways to improve performance and scaling. There are others, and they all should be considered. Just because Solana is currently leading in many ways doesn’t mean their design is the best or the ONLY one that works. If it was the only, or best, way we wouldn’t see such a large amount of different designs. There are other chains that reportedly can outperform Solana in terms of TTF (time to finality) which is more important o users than TPS.

Spending more on hardware could be a short term solution if and when it’s needed, but since expenses impact the viability of businesses supporting the network, the blockchain optimizations should also be investigated for possible payback of the time/resources invested.

1 Like

taking the path of not caring about centralization might be fine for some cohort of users but it could hurt attracting much BTC capital.

So like Bitcoin, I think Stacks should stay “sufficiently” decentralized.

We’re likely saying the same thing. I think its sufficiently decentralized already, in that it works, and to me its important to recognize that its unlikely to become more so anytime soon. The capital requirements to mine are too high for most, and bigger money won’t show up until there’s the user demand to justify it.

The lack of user demand is the bottleneck, and one of the ongoing complaints from people building in/around stacks has been the speed of smart contract execution.

There are other chains that reportedly can outperform Solana in terms of TTF (time to finality) which is more important o users than TPS.

Sure. Users just want things to happen quickly and reliably. We can call it whatever we want.

Spending more on hardware could be a short term solution if and when it’s needed , but since expenses impact the viability of businesses supporting the network, the blockchain optimizations should also be investigated for possible payback of the time/resources invested.

I would be very surprised if the people currently involved in running/mining stacks are worried about the financial costs of upgrading their hardware, versus this being a hypothetical concern that won’t ever be applicable if Stacks remains a ghost chain.

1 Like

We have much less signers than Solana, Stacks onIy has 5 miners and 43 signers.
In fact,Solana is much more decentralized than its begining, in Jan 2021 ,it only has 350+ validators, Solana Year in Review 2020. 2020 was a difficult and challenging… | by Solana | Solana | Medium, now Solana has more than 1400 validators, this proved my forward flywheel theory:

Hardware Upgrade → TPS Enhancement → On-chain Activity Surge (Solana/ETH User Migration) → STX Market Cap Growth → Miner/Signer Expansion → sBTC Supply Scaling → BTCfi Ecosystem Maturation → Reinforced STX Valuation → Recursive Value Creation .

4 Likes