SIMD-0207: Raise Block Limits to 50M

[apfitzge]

No description provided.

[mertimus]

Can we get a more concrete idea of what this looks like? I think doing a small increase first is prudent, but I think the increases proceeding that should be non-linear and increasing in %

[steviez]

I imagine a subsequent SIMD will introduce a ladder of feature gates. If we used linear and a 5M step (pulling this number out of the air for now), then I think we'd have individual gates for each of these values:

[55M, 60M, 65M, 70M, ..., 100M]

but I think the increases proceeding that should be non-linear and increasing in %

I haven't given too much thought to this aspect. If we land on % (and say 10%), then the ladder would look like this if we round to 1M-multiples:

[55M, 61M, 67M, 73M, 81M, 89M, 97M]

Assuming this answers your general question, I think we can kick the can on specifics of the ladder to the follow-on SIMD

[apfitzge]

It's gonna depend how things go, and how quickly we can improve performance.
To the best of my knowledge, we have no plans for some automatic increasing limit at this time; any further changes will go through same SIMD process.

[blockiosaurus]

Is the feature gate actual required? It would be nice to have automatic progression and so long as you use a static calculation based off of numbers already under consensus (e.g. Epoch or Slot) the validators should be able to easily calculate the current block limit.

[steviez]

The feature gate gives us the ability to raise the limit at a time when we feel the cluster is healthy and can handle the additional load that the higher limit could introduce. Adding in "raise limit at epoch N" adds unknowns; what if the cluster is struggling when epoch N comes up or what if the entire validator set hasn't adopted a new enough version by the time epoch N rolls around.

It would be nice to have automatic progression

This is somewhat similar to what 7layermagik mentioned here. But to quote Andrew from here, we are viewing this as a "foot in the door" feature. Implementing this SIMD will establish the logic to raise the limit which will enable future SIMDs to raise the limit to be easier

[mertimus]

which infrastructure specifically? are we referring to RPCs?

[steviez]

Yeah, RPC and related technologies (ie BigTable) definitely included here

[apfitzge]

unforeseen

RPCs, indexers, historical transaction data providers come to mind, but idk what's out there. Hoping people will either alert us or fix their system if increased limits are coming close to breaking their stuff.

[7layermagik]

How about making it so the block limit cu increases are contingent on cluster vote latency being within a good enough range?

You can propose a doubling in block limit to 96mil cu and then increase the cu limit linearly each epoch (1 or 2mil cu's for example). Each epoch you can increment it and if the 80 percentile (could be something else) by stake vote latency is too slow that indicates it shouldn't be increased the next epoch until the cluster performance is good enough. For example, say right now 1.6 slot vote latency is our 80th percentile, we keep increasing cu's each epoch but once it goes over say 1.8 slot vote latency it stops increasing until latency drops again. There should also be a criteria that blocks are at least 80 or 90% full or so on avg during the epoch because we don't want to be comparing vote latencies between two epochs where the avg traffic is a lot different and blocks aren't even close to max (because vote latency will go up once they are fuller so that's risky to base assumptions on not very full blocks). Anyway, just some quick ideas.

[mertimus]

How about making it so the block limit cu increases are contingent on cluster vote latency being within a good enough range?

You can propose a doubling in block limit to 96mil cu and then increase the cu limit linearly each epoch (1 or 2mil cu's for example). Each epoch you can increment it and if the 80 percentile (could be something else) by stake vote latency is too slow that indicates it shouldn't be increased the next epoch until the cluster performance is good enough. For example, say right now 1.6 slot vote latency is our 80th percentile, we keep increasing cu's each epoch but once it goes over say 1.8 slot vote latency it stops increasing until latency drops again. There should also be a criteria that blocks are at least 80 or 90% full or so on avg during the epoch because we don't want to be comparing vote latencies between two epochs where the avg traffic is a lot different and blocks aren't even close to max (because vote latency will go up once they are fuller so that's risky to base assumptions on not very full blocks). Anyway, just some quick ideas.

that seems like something for a next SIMD after seeing how this one goes

[7layermagik]

How about making it so the block limit cu increases are contingent on cluster vote latency being within a good enough range?

That'll add many months though. The SIMD process seems to take forever -- might as well make the proposal a more thorough one. 2mil more cu's isn't going to stress things much at all either I imagine -- idk what value there is increasing it only that much

[apfitzge]

That'll add many months though. The SIMD process seems to take forever -- might as well make the proposal a more thorough one. 2mil more cu's isn't going to stress things much at all either I imagine -- idk what value there is increasing it only that much

Goal with this is kind of a "foot in the door" from my perspective.

With this simd, we set up system so we can easily add features for block-limits. I'm hoping to backport this.
Future SIMDs adjusting limits can just be backported and activated more quickly. Regular procedure of taking eons to activate be damned.

[ripatel-fd]

Approving on behalf of Firedancer even if the increase is merely symbolic. 48M CUs is far too low and holding back performance of potentially faster clients.

[bw-solana]

Approved by Anza

[Benhawkins18]

Looks good to me, I see approvals from Anza and FD. Moving this into main.