You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We are using a hardcoded constant (16) which is a bit higher than what we're likely to see in practice (6 before Electra, 9 after).
In a future PR we could try to plumb the ChainSpec into this function so we can get a more accurate estimate, or we could stick with the current approach if no issues arise because of it.
The text was updated successfully, but these errors were encountered:
Plumbing in the ChainSpec is a bit of a PITA. The RateLimiter really seems like it doesn't want to have a ChainSpec near it. The RPCHandler is fine because it has a ForkContext.
Maybe we could re-do @jxs's changes from this PR, but with ssz(skip_deserializing, skip_serializing) on the max_blobs_per_block field?
Description
In the
max_blobs_per_block
PR we changed the heuristic for estimating the maximum number of blobs exchanged in aBlobsByRange
request:We are using a hardcoded constant (16) which is a bit higher than what we're likely to see in practice (6 before Electra, 9 after).
In a future PR we could try to plumb the
ChainSpec
into this function so we can get a more accurate estimate, or we could stick with the current approach if no issues arise because of it.The text was updated successfully, but these errors were encountered: