Stacks Roadmap and Product Vision Update

Community
#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.

4 Likes
#9

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 (TPS: 1200-200)
Tron and BSC requirements: 128G RAM, 1Gbps bandwidth ( TPS:100-150)
ETH requirements: 32G RAM 100Mbps bandwith (TPS:12-15)

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（it’s at lowest level currently,if stx price surges to $10,the figure becomes $10000),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)

By the way, BSC announced to scale to Solana speed and throughput rencently,and ETH is going to scale its L1 too,scaling on L1 is a unstoppable tendency for all smart contract layers.

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

Calculated 20 full filled tenure from Stacks block 426309-426550,each tenure has average 34.6 transactions,so the TPS is 34.6/2/60=0.28,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,and we could get 0.28•500=140 TPS

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

5 Likes
#10

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

2 Likes
#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 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.

5 Likes
#13

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.
5 Likes
Remove Cool Down Cycle in Stacking
#14

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.

4 Likes
#15

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.

2 Likes
#16

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?

2 Likes
#17

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

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

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

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 .

5 Likes
#22

I would like to see Stacks integrate Chainlink. Dapp builders will need the data feed and Chainlink also has CCIP which would allow sBTC and all other tokens to move crosschain on a top tier bridge.

1 Like
#23

When discussing TPS, it’s important to consider the state of the mempool. Stacks has had no trouble keeping up with recent demand, and the mempool is nearly always empty. If there are no transactions waiting to be mined, no blocks will be produced. Any TPS measurements should take this into account to avoid misleading conclusions.

Before debating block production times, the key first step is identifying the current bottlenecks. From my perspective, three main factors contribute to block mining speed:

  1. Block production by the miner
  2. Networking: transmitting block proposals to signers and receiving signatures back
  3. Block processing on the signer

There’s likely room for optimization in all three, but we need solid data to determine where to focus next.

On hardware requirements, throwing more resources at the problem without understanding the root cause is a temporary fix at best. I’m in favor of decentralization, so I’d advocate for keeping follower node requirements reasonable and low to ensure broad participation in the network. Miners and signers, however, will naturally require more powerful hardware—but those costs should be factored into incentives. Miners might adjust PoX payouts to account for expenses, and signers could demand higher fees or a larger share of rewards for their role.

10 Likes
#24

Im not a technical person but my view as a user…

Success will depend on arriving at a clear vision statement that should alidn with and support the roadmap.

So, were is stacks we headed, or where could it be, where should it be? Lets do a SWOT and PESTLE to help define a few things and canvase the landscape. Once we’ve done this we could match the reqired tech to acheive the vision and talk about incentives to get action.

In summary:

  1. Analyse the crypto landscape using SWOT, PESTLE
  2. Reaffirm stacks mission statement and value propsition
  3. Land our desired use case by functions and users
  4. Build a road map around deploying use cases POV
  5. Identify required crypto technology stuff to deliver use cases
  6. Develop incentive strutures for community to build out the use cases in a coordinatated manner with a fast delivery ship timeframe to maintain market competition.

Lets dive in to get the ball rolling…

  1. SWOT
    Strengths of stacks
  • decentralised
  • highly secure as settle on btc
  • can access btc liquidity via sBTC
  • great " can do" community
  • SEC cleared
    …
    Weaknesses of Stacks
  • transaction speed?
  • community image and visability
  • low market cap
  • high market cap when compared to tradtional crypto metrics, tvl, number transactions.
  • slow shipping

Opportunities for stacks and crytpo

  • sBTC unlocks could bring billions into ecosystem, allowing institutions to earn yield on their btc
  • companies are creating btc strategic reserves, stacks could be their platform to park their btc and btc
  • defi, use sBTC as collateralized for house loans and business loans, traditional payments, transfer of value
  • RWA, leverage stack/btc security to store and transact large complex transactions on chain. Property deeds, futures trading.
  • web3 if we link our verified identifies to stacks ecosystem, could make transactions faster, like buying a house, insurances, legal matters, access government services, access complex private sectors services, track transfer of goods etc…imagine the efficiencies in huying and selling a house in days rather than months, theres a lot of friction that could be removed.
  • consumer defi: build local communities of value, like the memes model combined with company incentive systems, eg starbucks rewards card loaded onto stacks platorm. I don’t care if i have starbucks consimer credit loaded on my stacks / xverse verified wallet or $leo, its all just value that i want to move around in the community. Creates loyalty, incentives and puts consumer data back with wallet holders.

Threats

  • SOLANA - defi, transaction speed
  • lack of engagement from shillers and investment gurus
  • perception issues
  • microstrategy becomes the everything bitcoin company.

Next, we need to discuss above and choose where we want to go, we cant do it all, we cant be it all, we whats our immediate, and medium term focus…institutions, retail value, RWA, defi?

Lets pick institutions…as they will use stacks to first secure their reserves, then logically build apps for retail to access there services, especially the btc community.

So our vision statement: Stacks brings institutions and their customers into crypto via leveraging the most secure network known and simultaneously unlocking monetary value via btc to allow seamless integration between businesses and consumers, allowing a direct, secure relationship…or something like that.

  1. Now, use cases…what needs to happen to bring our vision to light.

…over to the community…

2 Likes
#25

Brice -

Thanks for the thoughtful response and a big+1 from me!

Curious, for the three main block production factors you noted in your response what are the best metrics to monitor for each one? Also, is there a publicly available dashboard you use to monitor those metrics?

Also, separate topic, but curious where signature schema fits into the roadmap conversation? (i.e. SIP-025). In your opinion, is iterating closer towards the original SIP-021 schema (WSTS, I believe) a high / med / low priority?

3 Likes
#26

Decentralized Mining Pools

Mining pools play a crucial role in decentralizing the mining process on Stacks. However, for mining pools to function effectively in a decentralized manner, specific components need to be integrated:

  1. StackerDB – Communication Layer
    • StackerDB is a key component for facilitating communication among participants.
    • However, its integration lacks proper documentation, making it difficult for developers to understand and utilize its capabilities.
    • Questions that need to be addressed:
      • How do stacks signers communicate using StackerDB?
      • How can a decentralized application interact with and store state using StackerDB?
      • Can StackerDB be used beyond mining pools, and what features does it offer?
    • In the context of mining pools, StackerDB could serve as a communication layer to:
      1. Compute the aggregate key using Weighted Schnorr Threshold Signatures (WSTS).
      2. Establish and update the participants set in the pool.
      3. Notify participants about pool updates and other events that take place in the pool.
  2. WSTS Signature – Enabling Multi-Signature Participation
    • Stacks Core has not yet implemented WSTS, but it is planned for a future SIP (cannot add links, check on github stacksgov/sips/blob/main/sips/sip-025/sip-025-iterating-towards-weighted-schnorr-threshold-signatures.md#iteration-2 ).
    • There are no existing examples of how WSTS can be used in complex applications that require multi-party communication.
    • WSTS is crucial for mining pools because it enables the computation of an aggregate key and allows transaction signing by all participants.
    • Once implemented, it will provide a decentralized and secure method for miners to collaborate without relying on a centralized trust.

Change PoX Reward Address Without Penalty

Currently, if a user wants to change their PoX reward address while stacking, they must wait through a one-cycle cooldown, during which their STX remains unstacked, and no rewards are earned. This cooldown is problematic, especially for users managing large amounts of STX.

To improve flexibility, the system could be updated to allow reward address changes mid-cycle:

  • The reward address could be updated at any time, provided the change is made at least X burn blocks before the associated rewarded Bitcoin block.
  • This would allow the rewards to be sent to the new address dynamically, without affecting slot allocations.
  • The parameter X could be chosen to prevent performance issues and race conditions.

Benefits of this update:

  • More liquidity in stacking, especially for large accounts that want to adjust their reward distributions.
  • Enables new non-custodial stacking solutions, allowing users to receive rewards in sBTC bridged from Bitcoin rewards.
  • Reduces inefficiencies caused by the one-cycle cooldown, allowing participants to optimize their stacking strategy.

This change would require modifications to both the PoX contract and Stacks Node, but it would significantly enhance the flexibility and usability of the PoX mechanism.

Non-Custodial Stacking Pools

A decentralized, non-custodial stacking pool could be implemented using the sBTC bridge and Clarity smart contracts.

How it would work:

  • Users would stack through a smart contract, without relying on an admin or liquidity provider.

  • Rewards can be calculated and distributed by anyone, using on-chain logic, without the need of a centralized entity performing the operations.

  • The system would have safeguards to prevent malicious behavior, such as:

    • Cycle extensions limited to one cycle at a time to prevent participants from being locked in longer than intended by others.

  • The pool would allow flexible staking amounts, as long as the total pool stacked amount meets the minimum threshold for stacking.

  • Once sBTC signers are integrated into the Stacks signers, they would be responsible for dynamically updating the reward address.

  • The contract would track the current set of signers by calling the get-signers read-only function within the signers contract (SP000000000000000000002Q6VF78.signers).

  • At least 70% of the weighted signers must agree on the new reward address for the update to take effect.

  • This ensures a decentralized and secure mechanism for managing BTC rewards and bridging them into sBTC.

Bridging Capital into the Stacks Network: sBTC on Solana and Ethereum

By making sBTC available on both Solana and Ethereum, users on those chains can hold a Bitcoin-pegged asset and easily move it across different ecosystems. They’ll see that sBTC is powered by Stacks, giving them access to yield opportunities on the Stacks blockchain. As a result, it’s much simpler for someone already using Solana or Ethereum to start using Stacks following these steps directly from their ecosystem.

To achieve this , Chainlink’s decentralized Cross-Chain Interoperability Protocol (CCIP) can be used for secure cross-chain messaging and proofs. The process could be a lock-and-mint approach: sBTC is locked on Stacks, and an equivalent amount is minted on Solana or Ethereum. When returning the tokens, users burn them on the destination chain, and the locked sBTC is released back on Stacks.

5 Likes
#27

Curious, for the three main block production factors you noted in your response what are the best metrics to monitor for each one? Also, is there a publicly available dashboard you use to monitor those metrics?

I don’t think we have these yet.

Also, separate topic, but curious where signature schema fits into the roadmap conversation? (i.e. SIP-025 ). In your opinion, is iterating closer towards the original SIP-021 schema (WSTS, I believe) a high / med / low priority?

I’d put WSTS as low priority at the moment, since the current signer implementation is fine for the current needs. When we want to integrate sBTC signers into the consensus mechanism, then we’ll need WSTS, but until we’re ready for that, I think this is a low priority task.

2 Likes
#28

Looking from a PMF perspective.

Watch Bob’s newly launched Odin Fun platform video to see how fast and smooth the UI/UX is, which has been a massive success.

:star: Let’s imagine this as the end goal:
*The best UI/UX for any Bitcoin Layer 2, whether it’s for Stacks assets or L1 assets.

Transactions are settled and confirmed at lightning speed. (In the video, the user completed 50 runes purchases/transactions in just 10 seconds.)

:repeat: Now, let’s work backwards from this endgame:

*What types of Stacks technological infrastructure (Blockchain, APIs, Wallet Integration, etc.) are needed to make this possible?

Thinking in this way may help us map out a roadmap for the required steps to achieve this goal.

(Note: I’m not a big blocker either, reason attracted me to Stacks is ability to run on low requirement same ethos as Bitcoin. So I am hoping the solutions to achieve this endgame UI/UX can be implemented without relying solely on centralized databases and servers.)

Problem Statement:
*Current UI/UX in the Stacks ecosystem lacks the speed and smoothness needed for seamless transactions, with delays in settlement and confirmation, hindering user experience.

Solution Statement:
*Create the fastest UI/UX for Bitcoin L2 (Stacks and L1 assets), enabling near-instant transaction settlements. Success will be measured by transaction speed, user satisfaction, and increased transaction volume.

Expected Impact:
*Improved user experience through lightning-fast transaction processing
*Enhanced users adoption due to smooth and responsive UI/UX
*Increased transaction volume and usage within the Stacks ecosystem

How Success Will Be Measured:
*Speed of transaction settlement and confirmation
*User satisfaction and engagement with the UI/UX
*Increased number of successful transactions per user within a short period (e.g., 50 purchases in 10 seconds)

2 Likes