Stacks Roadmap and Product Vision Update

Community
#1

: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!

6 Likes
#2

This is a really cool initiative!

2 Likes
#3

“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?

4 Likes
#4

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

1 Like
#5

1000x this

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

1 Like
#6

use $WELSH for gas fees on Stacks:)

#7

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.

4 Likes
#8

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.

2 Likes
#9

We cannot 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

So we need upgrade miners’ hardware requirements to 128G and 1Gbps bandwidth and signers requirements could be a bit lower.

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

1 Like
#10

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

#11

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
#12

agree with jake. it’s time the 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.

3 Likes