Optimizing Stacks Nakamoto for lower latency and higher bandwidth
//: November 22, 2024
Adriano Di Luzio
Andre Serrano
Stacks Nakamoto upgrade has introduced Bitcoin finality and faster blocks, with a new block now arriving on average every 28 seconds.
To deliver Nakamoto to builders as soon as possible, its initial release was structured to immediately enable faster block times and later increase the allocation of resources across blocks and within a miner tenures (a miner’s tenure today is roughly the length of a Bitcoin block).
This approach enabled builders to start working with Nakamoto faster, while enabling users to experience fast blocks for most network transactions. Meanwhile, core developers have been able to observe the live system and deliver incremental, continuous updates to it.
We recognize that fast blocks don’t translate into lower latency for all transactions, which, understandably, has been frustrating for developers, users, and builders interacting with complex smart contracts — who expected faster blocks, lower latency, and increased bandwidth from the get-go.
This blog post goes into details on the path forward, the proposed (and discarded) solutions, and the timelines to deployment.
To deliver Nakamoto to builders as soon as possible, its initial release was structured to immediately enable faster block times and later increase the allocation of resources across blocks and within a miner tenures (a miner’s tenure today is roughly the length of a Bitcoin block).
This approach enabled builders to start working with Nakamoto faster, while enabling users to experience fast blocks for most network transactions. Meanwhile, core developers have been able to observe the live system and deliver incremental, continuous updates to it.
We recognize that fast blocks don’t translate into lower latency for all transactions, which, understandably, has been frustrating for developers, users, and builders interacting with complex smart contracts — who expected faster blocks, lower latency, and increased bandwidth from the get-go.
This blog post goes into details on the path forward, the proposed (and discarded) solutions, and the timelines to deployment.
//: TL;DR
Builders, we hear you! Through the next four weeks (targeting December 16 at the latest, so that all releases go out before the holiday season), Stacks will:
Builders, we hear you! Through the next four weeks (targeting December 16 at the latest, so that all releases go out before the holiday season), Stacks will:
1
Increase up to 5x in bandwidth and decrease up to 5x latency by enabling “Tenure Extend”.
2
Improve latency predictability, by ensuring that transactions can be consistently included within the next few blocks, instead of having to wait for the beginning next tenure.
3
Introduce additional fixes and optimizations: today, a new miner that fails to come online at the beginning of a tenure will fail to create blocks for 10 minutes; instead, the previous miner will continue their tenure.
The Challenge: Unlock Efficient Block Budget Usage
Currently, miners operate on a budget, allocated per tenure, which limits the amount of operations (e.g. read and write operations in a Smart Contract) that transactions can perform across all blocks within a tenure.
Miners will typically maximize profitability by proposing blocks that include as many transactions as possible, as early as possible within a tenure, while prioritizing transactions that pay higher fees. Such a strategy is perfectly rational, but creates spikiness in block budget consumption:
Miners will typically maximize profitability by proposing blocks that include as many transactions as possible, as early as possible within a tenure, while prioritizing transactions that pay higher fees. Such a strategy is perfectly rational, but creates spikiness in block budget consumption:
- The first few blocks of a tenure will include “expensive” transactions (both in terms of opcodes, read/write operations, and fees) and sometimes consume most of a tenure’s budget.
- All remaining blocks (the majority of a tenure) will only be able to include computationally inexpensive transactions (e.g., STX transfers).
User Expectations vs. Reality
From a user perspective, this behavior affects both latency and bandwidth.
Users often expect that faster block arrivals correspond to lower latency for their transactions to be included (ideally, in the next available block). Then, with more blocks, users could expect more transactions to be processed overall within a tenure.
However, the spikiness in budget utilization can lead to delays in transaction processing. Once the block budget is exhausted, users must wait for the next Bitcoin block to reset the tenure budget before their transaction will be included in a Stacks block.
This behavior reduces the positive impact of faster block times, as the bottleneck shifts from block arrival times to tenure-wide budget consumption.
Users often expect that faster block arrivals correspond to lower latency for their transactions to be included (ideally, in the next available block). Then, with more blocks, users could expect more transactions to be processed overall within a tenure.
However, the spikiness in budget utilization can lead to delays in transaction processing. Once the block budget is exhausted, users must wait for the next Bitcoin block to reset the tenure budget before their transaction will be included in a Stacks block.
This behavior reduces the positive impact of faster block times, as the bottleneck shifts from block arrival times to tenure-wide budget consumption.
Next Steps We’re Taking
To solve such challenge, we will decrease latency and increase bandwidth consistently across all blocks in a tenure. Stacks Nakamoto was designed with all these optimizations in mind. At this point, they are well-understood and ready to be enabled.
For this reason, the core developers will be able to deliver them quickly and then iteratively adjust their parameters. Through the rest of this post, we describe the steps we will take in that direction (our roadmap going forward) and highlight a few additional solutions that we have evaluated and discarded.
For this reason, the core developers will be able to deliver them quickly and then iteratively adjust their parameters. Through the rest of this post, we describe the steps we will take in that direction (our roadmap going forward) and highlight a few additional solutions that we have evaluated and discarded.
1
More bandwidth, less latency: Tenure Extend (Github)
As we have seen, currently miners fill blocks up with a set budget limit within a tenure. Once that budget is exhausted, miners must wait for the next Bitcoin block to reset it.
Or do they?
Tenure Extend allows miners to dynamically request budget increases to Stacks signers. A Tenure Extend could happen because a few “heavy” transactions have consumed the whole tenure budget, or because a Bitcoin block is taking longer than average.
Effectively, Tenure Extend lowers the latency and increases the bandwidth of the Stacks blockchain. And, as a result, it improves UX: users transactions will be included faster and more transactions will be processed within a given time (e.g., a Bitcoin block).
Here’s how it works:
Our rollout plan will initially enable miners to request a Tenure Extend after some time has passed since the beginning of a tenure (e.g., 10m). Then, we will hit the throttle and experiment on lower timeouts — down to the order of one or two minutes. Our goal is to enable miners to request a Tenure Extend often, yielding 5x on bandwidth and lowering latency by the same factor.
Or do they?
Tenure Extend allows miners to dynamically request budget increases to Stacks signers. A Tenure Extend could happen because a few “heavy” transactions have consumed the whole tenure budget, or because a Bitcoin block is taking longer than average.
Effectively, Tenure Extend lowers the latency and increases the bandwidth of the Stacks blockchain. And, as a result, it improves UX: users transactions will be included faster and more transactions will be processed within a given time (e.g., a Bitcoin block).
Here’s how it works:
- After some minimum time has passed or when a tenure’s budget is consumed, miners can request a TenureExtend.
- Stack signers can evaluate and approve the request, granting additional budget to the miner and allowing it to process additional transactions within the same tenure.
- This cycle could repeat, ensuring consistent transaction throughput.
Our rollout plan will initially enable miners to request a Tenure Extend after some time has passed since the beginning of a tenure (e.g., 10m). Then, we will hit the throttle and experiment on lower timeouts — down to the order of one or two minutes. Our goal is to enable miners to request a Tenure Extend often, yielding 5x on bandwidth and lowering latency by the same factor.
Note for the techies: Signers will use idle-time (instead of wall-clock time) to signal how long before they are ready to allow a miner to tenure extend. This way, the measurement also accounts for the amount of time that signers spend processing blocks and can dynamically adapt their signal based on how much work they are actually doing.
2
Predictable latency: Distributing spending across the tenure (Github)
Even with Tenure Extend enabled, users might still need to wait for the next tenure (or a new extension) before their transactions can be included in a block. Even if they are willing to pay higher fees (or RBF existing transactions), a miner will not be able to pick up their transactions if their tenure’s budget has been exhausted.
By this time is clear: this leads to bad user experience.
Instead, we want users to experience predictable, low latency.
To fix this, we will distribute block budget consumption more evenly across the tenure. This approach reserves a portion of the budget for transactions arriving later with potentially higher fees.
Here’s how it works:
At the end of a tenure, the miner and the blockchain have performed the same amount of work as before. Users, though, experience lower latency and can RBF their transactions to prioritize their timely inclusion.
By this time is clear: this leads to bad user experience.
Instead, we want users to experience predictable, low latency.
To fix this, we will distribute block budget consumption more evenly across the tenure. This approach reserves a portion of the budget for transactions arriving later with potentially higher fees.
Here’s how it works:
- The miner sets a target budget when mining the first block, e.g., 50% of the tenure budget (measured across all dimensions).
- For subsequent blocks, the miner reduces the budget proportionally using an exponential target curve:
- Block 1: Use 50% of the tenure budget.
- Block 2: Use up to 75% of the tenure budget (i.e., 25% of the budget is reserved for later blocks).
- Block 3: Use up to 87.5%, and so on.
At the end of a tenure, the miner and the blockchain have performed the same amount of work as before. Users, though, experience lower latency and can RBF their transactions to prioritize their timely inclusion.
3
Additional goodies: More consistent mining (Github)
In some scenarios, a miner wins sortition but is then unable to mine a block, leaving the network in a state where no progress can be made until a new Bitcoin block arrives, when sortition will repeat.
This can occur in a few cases, for instance when:
By relying on Nakamoto’s design, we can fix this as follows:
This can occur in a few cases, for instance when:
- The next miner's block commit does not reference the correct parent tenure.
- A miner has technical issues and does not start mining quickly enough.
By relying on Nakamoto’s design, we can fix this as follows:
- The previous miner will monitor the correct tenure change to the next miner.
- If it sees that the next miner is not producing block, the previous miner will immediately submit a tenure extend, continuing its previous work.
The Benefits of These Improvements:
By enabling faster tenures and smoothing out transaction processing within each tenure, these updates align user expectation with the reality of faster block times. This will lead to:
- Improved User Experience: Transactions are less likely to be delayed due to budget exhaustion in early blocks.
- Improved Throughput: The Stacks network manages higher throughput without compromising decentralization or user experience.
- Efficient Resource Utilization: Ensures all blocks within a tenure are utilized effectively, avoiding wasted opportunities to process transactions.
What Else Have We Considered?
Doubling the Read Count Limit
All of us have considered the obvious option. If the existing tenure budgets are impacting the user experience, why not simply raising the limits?
TL;DR: because that would not fix the user experience.
As we have seen, currently the very first few blocks in a tenure consume the whole tenure budget (in particular, the amount of read operations that can be performed).
Even if you increased the tenure budget (say, by a factor of 2 or 5), it wouldn’t meaningfully impact the user experience. The first few blocks of a tenure would still consume most of the budget. The pattern will remain the same — yes, some more transactions will get through in the first few blocks, but other transactions will still ultimately end up waiting. All users would need to wait, regardless of the amount of fees that they are willing to pay (or RBF).
In other words, latency would still be bad: high and unpredictable. User experience would remain bad as well.
The solutions described here, instead, will not only result in comparable or higher bandwidth, but will also lead to lower and more consistent latency. All leading to consistently improved user experience.
Even better: tenure extends allow us to dynamically adjust the throughput based on actual observed behavior, whereas cost estimates come from experiment and capture worst-case scenarios, especially for reads and writes.
Besides, even with increased limits the network would still need the changes in this roadmap to extend tenures, spread their spending across blocks, and ensure failed miners do not result in a long-radio silence. All things that can be introduced without a consensus-breaking change.
To make matter worse for the idea of adjusting the cost limits, things are not as simple as they sound. Adjusting the budget is a consensus-critical change that requires:
For all these reasons, we have evaluated the option but have decided not to pursue it at this time.
Even if you increased the tenure budget (say, by a factor of 2 or 5), it wouldn’t meaningfully impact the user experience. The first few blocks of a tenure would still consume most of the budget. The pattern will remain the same — yes, some more transactions will get through in the first few blocks, but other transactions will still ultimately end up waiting. All users would need to wait, regardless of the amount of fees that they are willing to pay (or RBF).
In other words, latency would still be bad: high and unpredictable. User experience would remain bad as well.
The solutions described here, instead, will not only result in comparable or higher bandwidth, but will also lead to lower and more consistent latency. All leading to consistently improved user experience.
Even better: tenure extends allow us to dynamically adjust the throughput based on actual observed behavior, whereas cost estimates come from experiment and capture worst-case scenarios, especially for reads and writes.
Besides, even with increased limits the network would still need the changes in this roadmap to extend tenures, spread their spending across blocks, and ensure failed miners do not result in a long-radio silence. All things that can be introduced without a consensus-breaking change.
To make matter worse for the idea of adjusting the cost limits, things are not as simple as they sound. Adjusting the budget is a consensus-critical change that requires:
- Extensive experiments, to measure whether increased limits would reduce network decentralization (for instance, by requiring faster hardware or connectivity) and highlight potential trade-offs.
- Extensive testing, to ensure that a rollout would not result in network partitioning or other failures.
- Imagine for instance, a naive 2x increase on the amount of read operations in budget. Before the change, a network node might have been able to fit most of the required data in cache. With a 2x increase, instead, that might not be the case anymore. Then, most reads would miss the cache and require a disk fetch, that takes orders of magnitude more time. As a result, the time required to process a block would increase by more than 2x.
- Now imagine the above, applied to several blocks in a row. Nodes that cannot process blocks fast enough would de-synchronize from the rest of the network and would not be able to recover and catch-up — because they don’t have the resources and it is not enough to 2x them.
For all these reasons, we have evaluated the option but have decided not to pursue it at this time.
Timeline & Key Milestones
›
Milestone: Tenure Extend
Mainnet Activation: On or before December 16, 2024.
Goal: Implement 2-minute tenure extends, ensuring smoother and more predictable transaction processing across the tenure.
Goal: Implement 2-minute tenure extends, ensuring smoother and more predictable transaction processing across the tenure.
›
Milestone: Predictable latency and additional goodies
Mainnet Activation: On or before December 16, 2024.
Status:
Next Steps: Testing and monitoring to evaluate its impact on transaction distribution and miner behavior, then release.
Status:
- The pull request for balanced block budget utilization has been merged
- The pull request for tenure extend when the previous tenure is merged
Next Steps: Testing and monitoring to evaluate its impact on transaction distribution and miner behavior, then release.
Conclusion
The introduction of Tenure Extend represents an important upgrade for the Stacks ecosystem to ensure the network can meet the demands of its growing user base and fulfill the full promise of Nakamoto. We’re excited to work with the community to make this vision a reality and welcome your feedback as we continue to optimize Stacks for the future.