Block budget usage in Nakamoto #5398
Comments
|
Issue #5397 aims to help with this problem by improving mempool walking. |
|
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. |
|
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. |
|
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. |
|
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. 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. |
|
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. |
|
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: #3777 (comment). 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. |
|
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. |
|
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. |
|
Edit: I just re-read some comments above and saw that @obycode suggested it in just a few lines. Would it make sense for miners to always keep budget space for upcoming higher fees txs?
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: 
|
|
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):
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. |
|
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 |
|
@eriqferrari
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. |
|
Great! Love to hear that @hugocaillard !! |
|
@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. |
There's the
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 |
|
@siriusbtc currently there's only a tenure budget. Can you explain what you have in mind with the addition of a block budget? |
why not considering to automatically extend the tenure with a new budget, every time the block size is 99% allocated? |
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 |
|
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 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). |
|
Hi @jcnelson, I have some questions about the overall UX: hope you will activate the tenure-extend function asap, this could at least increase 2x the max TPS |
|
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)? 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. 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. |
|
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. |
|
@owenstrevor gets it, accelerate |
|
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. |
|
@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. |
|
@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. 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. |
|
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:
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. |
STX transfers already use no cost budget, except for the size (bytes) of the representation of the transaction in the block. |
@obycode, would you be able to tell if @kantai's assumption here, #3777 (comment), 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. |
|
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. |
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. |
|
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:
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! |
|
@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) |
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. |
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. |
|
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. |
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.
OK, this was not totally clear because the new terms are a bit confusing. Hope it achieves in the desired result! |
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 ? |
|
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. |
|
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. |
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. |
Ok, to be specific, here is the upper bound:
(This scenario is essentially the same as setting a "fast block budget") |
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.
This nails it. You need both and just one of the two won't be enough. |
|
@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? |
|
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. |
So why this |
How much is X? |
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. |
|
Lets say we do the tenure extend and update cost functions in early December. Do we have any estimation as to what the results of that would be? From my understanding, simply extending tenure wouldnt fix the issue of blocks being filled instantly right? Miners would still want to fill instantly so as to not leave any money on the table. |
|
@owenstrevor this is the cost limit: {
write_length: 15_000_000,
write_count: 15_000,
read_length: 100_000_000,
read_count: 15_000,
runtime: 5_000_000_000,
}Comparing with L1 isn't really 1-1 because Bitcoin only accounts for data (there is no "compute" cost), but this roughly equates to 15MB of written data per tenure, which is the only really comparable metric to L1. |
|
I'd like to personally thank everyone (especially non-core devs) in this thread for chiming in and taking the time to understand the problem and the possible solutions - IMO this has been a pretty productive discussion, even though I know many of you are frustrated about the current experience. There will be disagreements about what the exact solution should be, but I think we're all on the same page in terms of how we want this to improve from a user experience standpoint. |
This is super helpful! Thanks Hank. This should give builders a starting point to work with and estimate a few scenarios for what kind of throughput they realistically need. 100% understand the L1 and L2 have very different data/computer models. The founders I've talked to are looking to estimate the costs of their various smart contracts calls and compare that to the number of Txs on L1. So if you're building a swap on Stacks, you would look at the number of L1 swaps on Runes per block during different situations. Then you would multiply that by the % of market share you expect (let's say 10% market share) and then multiply that number by the cost of that specific smart contract call for your app on Stacks. Do this a couple times for different use cases and this can help you estimate what kind of throughput is needed. However, I'd guess that with faster blocks and lower fees the same people would have more activity so we could throw in another 25% bonus multiplier to account for that. |
|
I've added a new visualization to the quick block space usage I shared above. I also extended the data so that there is data for block budget utilization from block 1000 until 172661, grouped by tenure. This, for example, shows % utilization per dimension in the few blocks after Nakamoto was activated and the mempool was quite busy:
You can navigate and interact with the data here: https://observablehq.com/@vini-btc/stacks-space-usage I still haven't validated/cleaned it up, so it could be off. Something I found peculiar is that a few tenures after Nakamoto already seem to show read count consumption above the tenure limit. Tenure 172299, for example, seems to have used ~30.000 read counts, and 172480 almost ~45000. I'm not sure if this is expected or not. I am, anyway, sharing in the hope it could be informative now and in the future. |
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.
The text was updated successfully, but these errors were encountered: