Content
@
0 reply
0 recast
2 reactions
Vitalik Buterin
@vitalik.eth
EIP proposal, relevant to gas limit raising discussions: Increase calldata cost, perhaps back to the original 68 per nonzero byte, now that we have EIP-4844 blobs for data-heavy use cases. It would address the worst-case data issues and add breathing room to raise not just gas limit but also blob count target.
7 replies
13 recasts
150 reactions
Vitalik Buterin
@vitalik.eth
One alternative, which would keep average-case calldata prices low, is to bring back a separate limit for calldata, eg. via https://eips.ethereum.org/EIPS/eip-4488, assuming that our experience with EIP-4844 de-risks multidimensional limits+pricing in the meantime.
0 reply
1 recast
6 reactions
Barnabé Monnot
@barnabe
Agreed that if calldata and blobs compete for bandwidth, then increasing calldata cost allows for raising blob count. But if calldata isn't the bottleneck for raising the gas limit, does it really help for that?
1 reply
0 recast
4 reactions
Ittai Svidler ❤️🔥
@ittaisvidler
Is the explanation that calldata can still lead to state size growing at too great of a rate even with EIP-4844 blobs, so by making calldata more expensive, we directly limit state size from growing too quickly when we raise the block gas limit?
1 reply
0 recast
0 reaction
jesse.base.eth 🔵
@jessepollak
I like this idea - seems like a good forcing function
0 reply
0 recast
5 reactions
woj ツ
@woj.eth
assuming that calldata is what stays in the evm and rollups pay independently for 4844 blobs that sounds great
0 reply
0 recast
2 reactions
will
@w
why not just leave calldata alone and add blobs first (which is an effective increase) to see how that shakes out? seems like we’re unnecessarily complicating things but twisting multiple knobs at once
1 reply
0 recast
0 reaction
ndx 🐉
@ndx.eth
I want to not like this as I’ve become accustomed to optimizing with calldata but… I guess it makes sense.
0 reply
0 recast
3 reactions
