Block budget usage in Nakamoto

[obycode]

With Nakamoto activation, a Stacks miner can quickly use up nearly its entire budget for the tenure within the first few blocks. After that, it will only be able to include an occasional cheap contract call or primarily STX transfers in new blocks for the rest of the tenure. This behavior is not a surprise, but it is an area where we could potentially do something better. This issue will be for brainstorming options to improve this problem.

[obycode]

Issue #5397 aims to help with this problem by improving mempool walking.

[obycode]

The obvious thing to do is to make the signers enforce a pacing of the budget usage, such that the miner would need to spread the costs over a 10 minute period. The problem with this is that if the miner is pacing the cost out for 10 minutes but the next bitcoin block arrives in 2 minutes, then the tenure was not utilized to its full potential. This would also make expensive transactions less likely to ever be included in a block, since they make take up more than the segmented cost.

[obycode]

Updating the cost limits could help with this problem somewhat, giving the miner more space to fill. The fact that miners can fill a block and get it signed so quickly indicates that the current cost limits are likely too low.

[obycode]

Another option is to make a change in the mining heuristics only, so that it will pace out the block budget on its own, without any restrictions from the signer. This would avoid any potential conflicts and strange incentives that could come from the signers deciding how to pace. The miner is incentivized to reserve block space throughout its tenure so that it has room for potential high-paying txs that show up later in the tenure.

[JakeBlockchain]

Been thinking about this a little as fee estimation is a big UX boost if done right. With all of Bitcoins slow block issues, accurate fee estimates with the mempool make it decent enough to use because you know what to expect.

At first glance, letting the miner frontload their blocks with the highest fee TXs is rational, to limit a fast Bitcoin block leaving money on the table. But as Stacks mining is a probabilistic game that rewards long-term players. This downside shouldn't affect miners that much.

Forcing pieces of the blockspace to be filled over a set period of time seems like the best way to balance user UX while also allowing "in-tenure" fee markets to arise. Maybe spread the blockspace over 5 minutes as a happy medium to account for faster Bitcoin blocks. After that, the simple token transfer behavior will be limited to a few minutes on average.

[Rapha-btc]

Been thinking about blockspace constraints in Stacks. Spreading TXs across the 10-min tenure seems like a workaround, but what's actually preventing continuous processing, especially for DeFi?

Is there something fundamental about these limitations beyond the Bitcoin anchor? Or are we working with inherited design choices that could be revisited?

Curious what's really at stake here.

[vini-btc]

I quickly analyzed block space usage from Stacks Block 169289 until 174376. Data and data gathering methods should be available here in this repo. I created some data visualizations for the key metrics in this observable notebook.

The key insight is that read_count is the biggest block space usage bottleneck. I believe the core team knows this well, so there are no big surprises. Here is the graph for read counts per tenure:

It looks like post-Nakamoto tenures are consistently maxing read counts, which is good since it signals v3 is efficient.

Spreading the space budget throughout the tenure wouldn't solve many issues, IMO.

Digging into the topic, I found @jcnelson already explored read optimizations: https://github.com/stacks-network/stacks-core/discussions/3777#discussioncomment-6405938. So, I believe there's a clear path to increasing read_counts (142 times, if I understood it right?!), which should significantly increase the number of transactions processed without any big compromises. That would be a consensus-breaking change, though. It's a bit of a shame it wasn't included in SIP-021, but anyway, at least there's even a (hopefully still relevant) POC done.

[siriusbtc]

Bitcoin block production time is uneven, not constant speed 10 min, sometimes 1 hours a block, sometimes 1 second a block, but the total tenture blocks size of Stacks is limited to 2mb, to get the max txs fees , miner who wins this tenture trends to fill full the first several blocks with txs to avoid rapid bitcoin block. That is the way how congestion happened.

So the simplest strategy to solve this issue is to increase the total tenure blocks size limit into a big size such as 1GB and set small size limit (200-500k) to Stacks micro fast blocks. This could address throughout issue and uneven Stacks block size issue at the same time.

[eriqferrari]

Increasing the blocks size seems the fastest solution, but based on @vini-btc analysis seems the read counts generate the bottleneck.. what about of grouping read/write counts to a cumulative 30k, instead of having 2 counters of 15k. it could generate about a 33% more of available space, optimizing the usage of each block.

like @Rapha-btc i would like to know if there are some limits on the tenure block that doesn't allows for bigger blocks.

[hugocaillard]

Edit: I just re-read some comments above and saw that @obycode suggested it in just a few lines. But I guess my question is; could it be the default strategy for miners? And they could set how aggressive they want to follow strategy (keeping more or less space at the beginning of tenure, and how quickly it decreases)

---

Would it make sense for miners to always keep budget space for upcoming higher fees txs? In short: the miner should always keep room to mine a potential high fees tx.

• during the 1st minute of a tenure the miner could keep 90% of the block space for future high budget txs
• during the 2nd minute, the miner could keep 70%
• ...
• during the 8th minute, miner would only keep 5%

The % to preserve could follow a inversed logarithmic curve, that could be more or less agressive depending on the miner settings.

It encourages users to pay higher fees if they want fast txs, while lower fees txs would take less priority and can fill remaining block space toward the end of tenure.

Please appreciate this graph that illustrates the idea:

[augustbleeds]

hi guys. just giving my 2 cents ~ tbh I have no idea how stacks core code works so I'm just speaking from a strategic high-level. I think industry shows us that there's really only a few proven ways to increase tx throughput (TPS):

1. increase block size
2. stacking performance optimizations (parallelization, networking, etc.)
3. rollups

3 is obviously out of the question. 2 is a long road of improvements. 1 is easiest to do in the short-term, but sacrifices decentralization in the long-term.

2 is the way forward ... probably first by cutting fat and then building muscle (if you get what i mean). But unless there are egregious issues, cutting fat would probably only lead to marginal improvements which may or may not be enough to get the network to be quick enough given the demand for block space. You'd probably need some hefty redesigns to see vast performance gains.

1 would be a short-term fix to get to an acceptable TPS.

godspeed! rooting for you guys.

[eriqferrari]

Hi @hugocaillard , this is a nice solution but doesn't solve the problem. Degens out there wants fast txs during all the tenure. If we remain capped to a max block size that allows about 5-600 txs per block will be difficult to onboard more ppl. We need Ethereum speed with Solana costs. That's what the community wants. I will personally increase slowly the block size, testing the response from the network. In the best scenario with 10 minutes Bitcoin blocks we can have 50-60 txs/min. Here is the real bottleneck. To succeed we need at least to go 100x, actually 5x or 10x will be enough to handle the market needs, but we are not prepared for the bull run. This is my investor sentiment, as a developer understand the difficulties to achieve it, but we need to risk a bit more.

If increasing block size is the short term solution, let's do it. If it requires a new SIP to be approved we need to hurry.

I still congratulate with all the core devs for the hard fork, but the fine-tuning is now crucial to success, and should be asap.

Eriq

[hugocaillard]

@eriqferrari In my comment I only discuss one idea that could improve the situation. I'm also greatly in favor of other solutions, especially that ones that can increase the number of transactions included in a tenure. Increasing read count budget limit is definitely something I'd like to see as soon as possible :100:

Degens out there want fast txs during all the tenure

This is exactly what the solution I developed tries to address. Even with high budget limits and performances optimizations, there will be periods with high volume of txs and pressure on the network. With the current mining behavior, this would lead into tenure budgets being filled early in the tenure. By reserving block space for potential higher fees txs, it guarantes that fast txs can be mined during the whole tenure. And it also gives more meaning to the fees strategy. Of course, the fees doesn't need to be super high, just higher than the market.

[eriqferrari]

Great! Love to hear that @hugocaillard !! your solution works very good, allowing more txs to be added during all the tenure. I didn't want to criticize that, but would like to focus on the real bottleneck that we are facing while submitting txs: the block size. simple example: 100 = 50 + 30 + 20 = 80 + 15 +5 To achieve more transactions, we don’t need to change the order or size of the addends; instead, we need to work on increasing the total result. just try to imagine stacks with 10x the current daily users. I really appreciate all of your works! it was nice to meet you in Adam too!! We are all eager to be ready for the bull run, that's all! and we need to push the narrative now!!

[siriusbtc]

@hugocaillard in practice, there are more bitcoin blocks times exceeded 10 mins than we imagine, almost each day we could see at least one btc block exceeded 40 min, so the inversed logarithmic curve limit will not bring users fast experience too in many cases, after 8 mints, users will feel congested unavoidably too.

To have users get stable and continuous fast experience, set size limits on fast stacks block st the same time when increasing tenure block size is the simplest and effective strategies.

[hugocaillard]

@siriusbtc

there are more bitcoin blocks times exceeded 10 mins than we imagine

There's the tenure-extend strategy for that, where the miner gets a fresh new budget to keep mining.

set size limits on fast stacks block [instead of on the tenure]

It don't think this is something with want, this would greatly affect the whole mining logic and dynamic. Tenure budget exists for reasons. I don't think my current understanding of the matter would allow to clearly and effectively describe it so it'd be better to find documentation for that, or refer to someone with a deeper knowledge on the matter

[siriusbtc]

@siriusbtc

there are more bitcoin blocks times exceeded 10 mins than we imagine

There's the tenure-extend strategy for that, where the miner gets a fresh new budget to keep mining.

set size limits on fast stacks block [instead of on the tenure]

It don't think this is something with want, this would greatly affect the whole mining logic and dynamic. Tenure budget exists for reasons. I don't think my current understanding of the matter would allow to clearly and effectively describe it so it'd be better to find documentation for that, or refer to someone with a deeper knowledge on the matter

I dont mean that tenure budget should not exist, i mean tenure block budget limit and fast block budget imit should exist at the same time

[hugocaillard]

@siriusbtc currently there's only a tenure budget. Can you explain what you have in mind with the addition of a block budget?

[eriqferrari]

@siriusbtc

there are more bitcoin blocks times exceeded 10 mins than we imagine

There's the tenure-extend strategy for that, where the miner gets a fresh new budget to keep mining.

why not considering to automatically extend the tenure with a new budget, every time the block size is 99% allocated? Miners will continue to produce blocks until the next tenure is minted. this way high fee tx will always be confirmed immediately, but the network can respond to high demand when it's needed.

[siriusbtc]

@siriusbtc currently there's only a tenure budget. Can you explain what you have in mind with the addition of a block budget?

The benefit of setting budget limit on fast blocks when setting a big tenure budget is that could make stacks fasts blocks always achieve 5 second in any cases of bitcoin block time gap, and could be fully filled with txs on stacks super high volume flow scenario.

For example, the tenure size limit is 1GB, fast size limit is 500KB, on the most extreme case that bitcoin block get 2 hours interval, stacks mempool has 1M pending txs, 2•60•60=7200s,7200s/5s=1440 fast stacks blocks, 1400•0.5MB=720MB<1GB tenure limit, stacks network could meet this challenge.

The design of big tenure block budget and small fast block budget could make stacks generate 5 second blocks smoothly and solve congestion in any cases

[jcnelson]

Tenure limits are no longer relevant in Nakamoto, since signers decide how many tenure extensions can happen per unit time. The "tenure limit" parameter only controls how much compute resources get consumed between TenureChange transactions (be they Extension or BlockFound). In the extreme, Nakamoto's runtime limits only require that each transaction fit into the "tenure limit" constraints, since signers could grant an Extension every block, and every block could contain just the Extension and the humongous transaction.

That said, a per-tenure size limit of 1GB is unsustainable, even in the short term. It would mean the blockchain grows by about 1 TB a week, which is well beyond most people's storage and bandwidth budgets.

---

I agree with @obycode that the signers ultimately need to meter the miners' resource consumption. We can't leave this to miners. The economically optimal strategy for miners it to greedily fill their tenures with all available transactions as soon as possible, since they do not know when the next Bitcoin block will arrive, they don't know if more-valuable transactions will arrive before their tenure ends, and any transactions they don't mine are transactions that will be picked up by the next miner. So, signers have to throttle them down.

We want to preserve the property that Nakamoto provides low transaction latency to those who are willing to pay the tx fee for it. At the same time, we also want resource consumption rate to be linear as a function of time in expectation -- if you're X% the way through the tenure, then X% of a given resource ought to have been used. To support both, I think signers need to allow a miner to exhibit some bursty behavior as a function of the transaction fee and the degree of burstiness. If they have a humongous transaction with a very high fee, then signers should allow them to mine it right away (recall that signers are incentivized to maximize miner ROI because it maximizes PoX payouts). But, that fee needs to be high enough to justify deviating from the targeted resource consumption rate. The more deviation, the higher the fee (in fact, the required fee probably needs to grow faster-than-linearly with the degree of deviation).

[eriqferrari]

Hi @jcnelson, I have some questions about the overall UX: which TPS should we expect for Stacks considering the actual tenure limits? how can we scale in case of high demand to have a seamless Bitcoin DeFi? there could be more than one tenure-extend before the tenure change?

hope you will activate the tenure-extend function asap, this could at least increase 2x the max TPS

[benjamin-p-newton]

My 2 cents.

Upfront I'll note that I'm not a Stacks developer and nor do I fully understand the mechanics or limitations of a Stacks tenure (given @jcnelson's recent comment above). None-the-less, hopefully my thoughts spark some thought and is somewhat helpful.

Rather than limiting a Stacks tenure to a X resource unit (RU) budget, along the lines of what @siriusbtc is suggesting, why not limit the Stacks blocks themselves to a Y resource unit (RU) budget (Y being a fraction of X)? Bitcoin blocks on average occur every 10 minutes, for the sake of argument let's assume we're targeting a Stacks block every 5 seconds. That means a Stacks tenure would need to produce 120 blocks on average. For the sake of argument lets assign X a value of 120 resource units (RUs) and Y a value of 1 resource unit (RU).

If Stacks blocks were limited to a 1 RU budget, some miners would be caught short if a Bitcoin block arrived early, some miners would win big if a Bitcoin block arrives late, but on average over the long-term miners would be able to utilise the full 120 RUs per Stacks tenure/Bitcoin block (and make on average the same fees as they would currently over the long term).

Meanwhile, Stacks blocks are being produced at a consistent and reliable frequency to allow for a predictable UX for end-users. Additionally, to make the system more dynamic, if the network is able to produce Stacks blocks faster than every 5 seconds, lets say 3 seconds, the protocol could adapt and change the Stacks block budget to a smaller RU to increase the frequency of Stacks block production (while maintaining the Stacks tenure budget).

In the case that a single transaction exceeds the Stacks block budget (not even sure if this is reasonable under current circumstances) and if the miner choses to mine the single transaction in the block (due to a lucrative fee), then the subsequent Stacks block budgets are reduced until the deficit is restored and normal Stacks block budgets can continue. Thus, maintaining the average Stacks tenure budget (over the long term).

Once the consistent frequency and reliability of Stacks block production is resolved, then well considered throughput optimisations can be made. For example, if the single Stacks block resource budget is continually exceeded by individually large and resource intensive transactions, then maybe it's worth looking at increasing the Stacks block budget. Plus, all the other optimisations that have already been highlighted, etc.

[owenstrevor]

Make the budgets bigger. Other optimizations are just putting a band aid over the problem. Developers and end users will not use an L2 that is slow and we are so early in the adoption cycle that these tiny budgets don't make any sense.

[tycho1212]

@owenstrevor gets it, accelerate

[enjoywithouthey]

Is there a ROI element to consider alongside the tenure optimizing as well?

For example, miners exhaust the tenure budget quickly to make sure the tenure budget is used up in case of a rapid tenure change. The drawback is obviously poor UX with 1 tx blocks through the rest of the tenure.

But how often do these rapid bitcoin blocks actually occur and how do they affect (if at all) the ROI of the miners longterm?

To wit...assume miners distribute budget linearly over the tenure (10 minutes) to offer the best UX. If the next bitcoin block occurs without the current miner's tenure budget spent... then so what? That's a write off or cost of doing business. In the economics of mining, yes it is a loss, but a small one and in the longterm won't make a significant difference to the ROI.

Point being, processing more tx throughout the tenure is economically more attractive for users, attracting more users a developing a robust fee market which creates a better ROI than trying to exhaust the tenure budget as quickly as possible.

To get hard data to study the economics between distributed budget or quickly used-up budget (for lack of a better term), the miners would have to distribute the budget throughout the tenure so we can collect some economic data to better compare the two scenarios from an ROI perspective.

[philiphacks]

@enjoywithouthey I don't think this idea makes sense game theory wise... a miner wants to maximize profit.. if a protocol/chain/ecosystem actively limits (or "harms" imho in this context) profit making, then why would someone mine in that ecosystem? Mining is also economically broken atm, as the network does not support more than a single digit of profitable miners at the same time, but that's another discussion for later. Miners wanna mine maximizing profits without setting artificial limits... of course they will still sort transactions based on profit (with MEV etc) but you're harming throughput here.

As for the user perspective, you don't actually meaningfully increase throughput if you divide compute over a whole tenure (assuming a tenure is ~10 mins long on average).. what have you won? The optics that fast blocks are being filled without a performance benefit as I see it... that's not seeking the truth and building for what users want, that's hiding your suboptimal system.

As for cost limits in general, I agree with @owenstrevor here.. I don't know how hard it would be and it would probably be significant to revisit costs and practically increase limits but it's 2024 and we still have exponential hardware improvements every 18-ish months... we'd be idiots writing software for cutting-edge HW that is available under $1000/month. The ideological decentralization argument does not make sense since we don't need Bitcoin-levels of decentralisation, nor is Stacks really decentralised to begin with (see single digit miners as an example). Also if one miner/signer malfunctions today, you get a liveness issue on Stacks...

When "fast blocks" were pitched for 18+ months, I expected that to be holistic... meaning you not only get fast blocks but these are actually full (with functioning fee markets), I (wrongly) thought compute budgets would be adapted to filling fast blocks in a reasonable manner.

Just my perspective - happy to hear where I'm wrong, always open to changing my opinion.

[LNow]

@jcnelson @obycode would it be possible to put a cap on nakamoto blocks (micro-blocks?)?

Instead of limiting tenure, put limits on micro-blocks. Reduce them to 10-20% (maybe less) of the old limits. And increase a little bit the dimensions that were most limiting in the past to alleviate bottlenecks. To accommodate exceptional situations, introduce a premium option that allows users to temporarily exceed these limits for a substantial fee. Allow it to happen no more than X time/tenure (I'd start with low value like 2-3) and put a hard-cap when that happen (1.5 - 3x usual limits). And make it truly premium service, where fee must be at least 10x or more higher than it would be normally. And lastly - exempt standard wallet to wallet STX transfer from any execution costs limits (if it hasn't been done already).

Shifting execution costs from big blocks to micro-blocks, and reducing them to a portion of the original ones should spread resource consumption more evenly throughout the tenure. At the same time it should increase the overall throughput without increasing blockchain size in an uncontrollable way.

[obycode]

Just to point out one thing that might not be immediately obvious -- the challenge to simply raising the block budget (or allowing unlimited tenure extends) is that the larger this total budget is, the more difficult it becomes to boot a node from genesis (i.e. a node booting up needs to replay the same transactions significantly faster then real-time, or it will never be able to catch up to the tip), so we have to be careful not to go too high with that total budget.

Two points that lead me to a straightforward solution:

• The original cost budget targets 30s of execution time for every 10 minute block. These values have not been updated with recent improvements, so a full block can be constructed now in significantly less than 30s.
• We are not aware of any projects that cannot do what they need to do within the current block limits.

Using those two facts, I think we could safely allow time-based tenure extensions (see #4843) where the time is less than 10 minutes, with the exact length of time determined after some experimentation. The miner would then be free to spend the budget however they like, but refresh their budget with some regular cadence. This would avoid the problem of dividing up the budget into smaller units that could prevent transactions from ever being included.

[obycode]

exempt standard wallet to wallet STX transfer from any execution costs limits (if it hasn't been done already).

STX transfers already use no cost budget, except for the size (bytes) of the representation of the transaction in the block.

[vini-btc]

Just to point out one thing that might not be immediately obvious -- the challenge to simply raising the block budget (or allowing unlimited tenure extends) is that the larger this total budget is, the more difficult it becomes to boot a node from genesis (i.e. a node booting up needs to replay the same transactions significantly faster then real-time, or it will never be able to catch up to the tip), so we have to be careful not to go too high with that total budget.

@obycode, would you be able to tell if @kantai's assumption here, https://github.com/stacks-network/stacks-core/discussions/3777#discussioncomment-7535734, was ever validated? Getting back to my point earlier, read counts seem to be by far the biggest bottleneck in terms of block dimension usage. His hypothesis is that the estimates were off 142 times (they would be ~70 microseconds for an operation but were assessed at ~10ms). If it is correct, this means we could safely increase the read count without the risk of exceeding the 30s limit, significantly relieving pressure during busy times. That wouldn't exclude other improvements, but it could be an impactful yet easy win.

[jcnelson]

Just to reiterate, the tenure budget doesn't matter in Nakamoto, because signers can extend it at any time. Signers, not consensus rules, decide what the per-tenure compute capacity will be. There's no need to change the per-tenure compute budgets, since they only restrict the compute budget for a single transaction (per my comment above).

We're all working hard on making it so that signers can take full advantage of this in the near future.

[owenstrevor]

Just to point out one thing that might not be immediately obvious -- the challenge to simply raising the block budget (or allowing unlimited tenure extends) is that the larger this total budget is, the more difficult it becomes to boot a node from genesis (i.e. a node booting up needs to replay the same transactions significantly faster then real-time, or it will never be able to catch up to the tip), so we have to be careful not to go too high with that total budget.

I believe this is indeed obvious to the people I see commenting here.

What everyone's saying is that current settings are excessively conservative. Stacks is an L2, not an L1. It takes time to boot a node and there's nothing wrong with that. I've personally been involved in helping a few hundred people set up Bitcoin nodes. Bitcoin's IBD is horrible and yet no one cares. It's about as hard as downloading movies from Limewire back in the early 2000s (not hard). People who want to run nodes will run nodes whether it takes weeks or a day to set it up.

Meanwhile, the current block budget makes the network non-viable for developers and end users. These tiny budgets are shooting Stacks in the foot. People expected that Nakamoto would be at least as fast as Ethereum. Now that the community is finding out it's not, and that the core dev's worked on this for 2 years with no intention of actually making it consistently as fast as Ethereum (which is old tech in most people's view), the community feels misled.

No one wants to use a slow L2. There are now dozens of new alternative Bitcoin L2s being developed with substantial funding. It would be a shame if Stacks blows it's early lead here for being overly conservative in prioritizing the wrong things and not listening to feedback from the community.

[vini-btc]

I understand tenure extensions could alleviate the throughput issue significantly. Thanks for the hard work in making sure this gets delivered ASAP, and I also appreciate how nuanced the block dimension discussion is. But just to try to make it very clear one last time:

MARF reads from Clarity should be much, much cheaper than they are currently assessed in block limits. Jude's benchmarking found MARF read + deserialization takes ~70 microseconds for an operation. Those currently are assessed at ~10ms in block limits (a 142x larger assessment). In theory, this means that the read_count limit in blocks could be increased 142-fold without any other work.

If this is true, the original cost assessment for read counts was wrong. So it would make perfect sense to take this opportunity to FIX it and set it to some appropriate number. Since the correction would be just this—a correction—this would mean that the fixed version would still be "valid" even under the original constraints, so we shouldn't even have to debate the topic!

[enjoywithouthey]

@philiphacks obviously miners want to maximize profits. I question if the current strategy to exhaust tenure budget as quickly as possible in fear of a quick bitcoin block is a profit maximizing strategy? I don't believe it is.

If devs and users go to other chains and stacks loses participation, because miners might lose a little profit due to a quick bitcoin block, I argue the current tenure budget strategy cannot see the forest for the trees.

Having more txs per block throughout the tenure would appear to improve UX and attract users, would it not? Leading to more chain usage and more profits for miners. Unfortunately, the hard economic data won't be known unless miners experiment a little and spread the budget throughout the tenure (bringing the conversation back to the chart presented by @hugocaillard earlier in the thread)

[obycode]

Meanwhile, the current block budget makes the network non-viable for developers and end users. These tiny budgets are shooting Stacks in the foot. People expected that Nakamoto would be at least as fast as Ethereum. Now that the community is finding out it's not, and that the core dev's worked on this for 2 years with no intention of actually making it consistently as fast as Ethereum (which is old tech in most people's view), the community feels misled.

I understand the frustration, and I’d like to clarify a few aspects — speaking just for myself here. It’s not accurate to say there was no intention to support robust transaction throughput. As Jude mentioned, the flexibility in the tenure extension mechanism allows signers to refresh the block budget dynamically, directly addressing these concerns. The initial Nakamoto release prioritized security and stability with the new consensus design, and work is actively progressing to utilize these tenure extensions to enhance throughput. Importantly, these changes are fully compatible with the current node version.

[obycode]

obviously miners want to maximize profits. I question if the current strategy to exhaust tenure budget as quickly as possible in fear of a quick bitcoin block is a profit maximizing strategy? I don't believe it is.

I wouldn't necessarily call the current situation a "strategy" 😅 -- it's just what happens by default without any real strategy in place. I agree that we can definitely improve this along with implementing the tenure extensions.

[enjoywithouthey]

Thank you @obycode. From reading this thread and other posts, tenure extensions appear to be the next big unlock to help improve UX.

IMHO, it seems there was an expectation mismatch with the Nakamoto hard fork regarding fast blocks and throughput. Had the tenure-budget bottleneck been known and anticipated ahead of the hard fork, KOL's, community members and protocol teams could've have helped with managing expectations, instead of searching for answers ourselves.

Anyways, moving forward and quoting @tycho1212 , let's accelerate! Amazing work to all and looking forward to the tenure extensions going live.

[owenstrevor]

I understand the frustration, and I’d like to clarify a few aspects — speaking just for myself here. It’s not accurate to say there was no intention to support robust transaction throughput.

Totally get it. Apologies if it sounded like I was making accusations, that was not my intention. I simply wanted to describe the broader community sentiment accurately.

As Jude mentioned, the flexibility in the tenure extension mechanism allows signers to refresh the block budget dynamically, directly addressing these concerns. The initial Nakamoto release prioritized security and stability with the new consensus design, and work is actively progressing to utilize these tenure extensions to enhance throughput. Importantly, these changes are fully compatible with the current node version.

OK, this was not totally clear because the new terms are a bit confusing. Hope it achieves in the desired result!

[yinyunqiao]

@siriusbtc currently there's only a tenure budget. Can you explain what you have in mind with the addition of a block budget?

Would also like to know, what's the technical reason behind the design on the budget at tenure level, not fast block level ? If technically possible to have per block budget limit, we seems don't need tenure level budget nor the tenure extend thing, miners should be able to produce fast blocks as big as they can as long as the blocks are within the limit, and produce blocks as many as they can until next bitcoin block mined. Are there any special reasons to make stacks can't do this way due to the nature of stacks' PoX and deep binding with Bitcoin network ?

[muneeb-ali]

I think we need to look at both cost function updates (requires a hardfork but we might need to do a hardfork for a separate upcoming emissions SIP that is timely) and making tenure extensions happen more frequently. I don't think it was ever the intention of the nakamoto launch that only certain types of transactions (like transfers) will be fast and other types of transactions will not be. Core devs decided to ship the bulk of nakamoto live to derisk any further delays, get real-world data from mainnet, and now can focus on performance optimizations. There is nothing fundamental here that stops stacks from being fast relative to other L2s, just a bunch of tradeoffs and optimizations that we plan to focus on now.

[owenstrevor]

Hi all,

What I'm hearing here and in chats with several builders leads me to believe core devs and ecosystem builders are on dramatically different pages with their beliefs about the right balance between node requirements and network performance. Because of this, I believe there's a good chance the current upgrades being worked on will fail to meet the community's expectations and largely be a waste of time until these differences are reconciled—leading to further disappointment and frustration on both sides.

The first thing I'd recommend is for core devs be 100% transparent on what the actual cost functions and limitations are for block space, compute limits, etc. All that has been said so far is that tenure extension mechanism will add flexibility to adjust the budget dynamically. This statement lacks specifics. My hunch is that this flexibility is not unlimited and there is a likely scenario the mechanism will not include enough flexibility to address the the community's needs.

The second thing I'd recommend is to engage with builders on the logic and calculations behind these limitations. Hardware costs are actually very easy to model in the real world. We can almost say with certainty what the cost per GB of RAM and disk space will be 5 years from now based on 20 years of historical data. We can reliably extrapolate to say, "in 5 years, a $1,000 computer at BestBuy will have X RAM and Y disk space." Yet, to my knowledge no transparent discussion about the node requirements based on demographic data and hardware costs has been had and no one can answer to the logic behind the core devs decisions about network limitations. There's no reason this can't be boiled down to a single cost number for running a node backed by historical market data and a hardware/performance function. e.g. "For anyone to be able to run a node with at least $500 from 2024-2035, the block size/compute limits will be fixed at X without further software-level optimizations."

For Stacks to be the number 1 L2 on Bitcoin the balance between node requirements and network performance should not be guess work, nor should the decision be made devoid of feedback from the actual builders who know the competitive landscape they are operating in and what kind of performance they need/expect from Stacks for their businesses to be competitive.

Core devs have done a fantastic job getting Nakamoto across the finish line. Let's take the time to do the next upgrade properly so it meets everyone's expectations and we're not stuck going in circles here without addressing the core issue.

[hstove]

I think we need to look at both cost function updates (requires a hardfork but we might need to do a hardfork for a separate upcoming emissions SIP that is timely) and making tenure extensions happen more frequently

Building on this, if we only shipped an update to the cost limits, you'd see the exact same behavior as today (block budget filling up quickly in a tenure), it's just that the first block(s) would have more transactions in them. You'd still end up with only STX transfers being allowed until the next tenure (or tenure extend). Obviously it's not rational for a miner to spend 10 minutes building a block, so if the cost budget were that high, it would make economic sense for miners to chunk this out a bit (but still probably with some heavier front-loading).

Only doing tenure extends (say, hypothetically, every minute) would have the same behavior as today, but at least every minute you'd get through a lot more of the more expensive transactions.

So, ultimately I think doing both (increasing the cost budget as appropriate, and also implementing better ability for us to be flexible with when to do tenure extends) is needed.

There is also a balance here of aiming for very fast (ie 5 second) block times. Even if we shipped both tenure extends and cost budget increases, it may be the most fruitful path for miners to spend as much time as possible (up to some point) building one big block. For us to achieve 5 second blocks consistently, we may need signers to enact a "fast block cost budget", as some have mentioned.

[hstove]

All that has been said so far is that tenure extension mechanism will add flexibility to adjust the budget dynamically. This statement lacks specifics. My hunch is that this flexibility is not unlimited and there is a likely scenario the mechanism will not include enough flexibility to address the the community's needs.

Ok, to be specific, here is the upper bound:

• The current cost budget is X
• A miner fills a block up to X
• Signers approve it and the block is mined
• Miner starts over but with a TenureExtend, which signers are OK with, repeat

(This scenario is essentially the same as setting a "fast block budget")

[muneeb-ali]

My hunch is that this flexibility is not unlimited

Yes, it's not unlimited. It's a reset of the existing compute budget. And the reset can only happen after X time has passed. @hstove does a good job explaining this above.

So, ultimately I think doing both (increasing the cost budget as appropriate, and also implementing better ability for us to be flexible with when to do tenure extends) is needed.

This nails it. You need both and just one of the two won't be enough.

[eriqferrari]

@muneeb-ali Since the hard fork requires more time to be implemented, do you think the tenure extension mechanism could be activated within two weeks, and block size increased in 3 month, SIP voting included? it's a reasonable schedule in your opinion?

[owenstrevor]

1 more thing—In addition to an analysis on hardware cost, it would be helpful to look at the activity on L1 for Runes/Ordinals/BRC-20 over the past year as a benchmark for what kind of network activity we would need to be able to accommodate on Stacks.

[yinyunqiao]

All that has been said so far is that tenure extension mechanism will add flexibility to adjust the budget dynamically. This statement lacks specifics. My hunch is that this flexibility is not unlimited and there is a likely scenario the mechanism will not include enough flexibility to address the the community's needs.

Ok, to be specific, here is the upper bound:

• The current cost budget is X
• A miner fills a block up to X
• Signers approve it and the block is mined
• Miner starts over but with a TenureExtend, which signers are OK with, repeat

(This scenario is essentially the same as setting a "fast block budget")

So why this TenureExtend thing was designed in the first place ? I tried to dig up the answer myself but couldn't find it. Almost all other blockchains are designed with per block limitation, include Bitcoin. If Worrying the block are filled too full, then just put a relative smaller limit per block wise. It's almost like before people cooking every dinner they must ask for permission from the government. Can someone point me some reasonable technical analysis behind the design please ?

[owenstrevor]

All that has been said so far is that tenure extension mechanism will add flexibility to adjust the budget dynamically. This statement lacks specifics. My hunch is that this flexibility is not unlimited and there is a likely scenario the mechanism will not include enough flexibility to address the the community's needs.

Ok, to be specific, here is the upper bound:

• The current cost budget is X
• A miner fills a block up to X
• Signers approve it and the block is mined
• Miner starts over but with a TenureExtend, which signers are OK with, repeat

(This scenario is essentially the same as setting a "fast block budget")

How much is X?

[muneeb-ali]

@muneeb-ali Since the hard fork requires more time to be implemented, do you think the tenure extension mechanism could be activated within two weeks, and block size increased in 3 month, SIP voting included? it's a reasonable schedule in your opinion?

Tenure-extend can be faster for sure because doesn't require a hardfork. The only reason I'm pushing for updating cost-functions is that (a) they likely give a higher performance boost and (b) there is likely a timely hardfork coming up (early Dec), see this emissions post and the cost functions can be updated with the same hardfork vs waiting a longer time for it.