Unless I’m misunderstanding state growth is completely orthogonal to this, you mean Historical Data growth? (Also addressed via something like eip-4444, since the EL doesn’t really use Historical Data for block processing/validation beyond syncing)
1 Like
Yeah right, this was expressed very poorly. And yeah, no direct relation except for syncing.
EDIT. I fixed it in the TLDR points of the text.
1 Like
According to a modeling we did on rollups deciding between using calldata posting strategy vs blob posting strategy (2310.01155.pdf (arxiv.org)), smaller rollups will use calldata while larger ones will use blobs. Threshold on what is smaller and what is larger is defined in the equilibrium.
Increasing calldata price will force more rollups to use blob posting strategy, which in turn increases blob price in the equilibrium, with the current target number 3. On the positive side, blobs will be fuller.
4 Likes
I think the goal is that we simultaneously reduce max calldata size and increase max blob count, so total max theoretical bytes remains the same (but average-case available bytes increases, because calldata has a very unfavorable worst case / average case ratio whereas with blobs it’s just 2:1)
3 Likes
Maybe the problem (of large call-data) will solve itself once 4844 comes into effect since those who use it now for DA will just move to blobs with no further action necessary?
1 Like
I think, without further scaling on the blob front, we might find ourself in a balanced price between using calldata vs blobs and rollups will be able to switch dynamically.
The externalities imposed by those that want their history to be stored in plain forever - of until we get history expiry - are larger than those of blob users, so it makes sense to treat them differently.
Also, if we don’t touch calldata pricing we will always have to deal with the inefficient case that the avg. block has 125 KB while it could potentially have a max of > 2.7 MB. This is a huge discrpancy that is super inefficient.
1 Like
Are there other factors that influence this? Based on my stats, the winning bid for the median forked mev block arrives about 1200ms later than the median succcessful block, but that would only account for ~10% of the difference. Are blocks from Coinbase / solo stakers / Rocket Pool statistically larger (as they make up an overweight share of forks)?
I’m just wondering about this in the context of monitoring timing games. Maybe block size needs to get factored into the stats as well.
1 Like
Yeah good question. Without having looked deeper into it, my feeling is that both variables, timing and size, have great influence on the reorged block rate. Also, the used clients may have great impact.
I cannot think of scenarios in which that Rocketpool Operators or Solo Stakers have more DA transactions in their blocks than others. Why would that be the case? Difficult to say because of the many variables that impact the reorg rate.
1 Like
The only thing that stands out to me is MEV-Boost prevalence and different building algorithms for self-built vs MEV builders. Are there any good studies of missed/forked blocks? Looks like ~50% are PBS (half of those being Coinbase slots). I wonder if the rest are payload timeouts or were always going to be self-built. Maybe the other 50% are just really big and slow to propagate.
1 Like
I have some numbers on that on timing.pics but yeah, identifying a single cause is challenging due to the numerous influencing factors. Recently, we observed that participants engaging in timing strategies have been missing more slots. Additionally, solo stakers are often among those with the highest slot miss rates, relatively speaking. It’s important to note that the solo staker category, as typically presented on various sites, includes ‘zombie validators’—those who have lost their keys. This contributes to their lower efficiency often seen in stats.
1 Like
I was curious, so I took a look at the time dependency of the comparative block sizes. It looks to me like there are two definite regimes, with forked blocks very late in the slot not being too much larger than finalized blocks late in the slot, but for earlier blocks the ratio is really high (a max of 250%+ rather than the 93% claimed for the set of all times).
How is the block size defined on the y axis, is that in bytes?
This would be an interesting result that even strenghens the argument of the block size significantly impacting the event of being reorged.
I did some logistic regressions an already got significant results with very low p values, so I’d expect, if one cleans the data set by those transactions that were regored bc they were very late, then we should get event better results.
bytes / bytes. It’s the quotient of the median forked block size against the median finalized block size. And agreed re-strengthening the argument.
Any update on this? Blobs unlocked a huge potential, and seems the demand of data needs a long time to meet the capacity.
Yeah, there exists and EIP (EIP-7623) and some analysis on it:
This might be a little bit off-topic, but I’m just curious.
Why can’t we just increase the block gas limit substantially and add an explicit limit on the block size instead?
I thought the major bottleneck of decentralized scaling was the networking overhead in block propagation, not the computation/storage overhead in EVM execution. So as long as we can keep the block size small (e.g., under 2MB), more computations shouldn’t be a problem, theoretically.
(Even this very article is using “maximum possible block size” as a key metric for measuring the consensus overhead that the adjustments may affect, not “computational costs that node operators pay”)
Considering that most of the current blocks only contain ~0.1 MB data, if what I’m saying makes sense, I think we potentially have quite a lot of room to scale the block size in terms of networking costs.
Please correct me if I’m wrong.
(I assume this subject must have been discussed somewhere else before, but I couldn’t find any materials)
cc. @vbuterin
IMO the biggest problem with Ethereum’s gas limit right now is that it allows for significant state growth over time, and that is driving Ethereum node operation further and further away from consumers. If you can’t run your own node, then the network is no longer censorship resistant because you are relying on the good will of others to be willing to let you use their node. You also lose a bit of privacy since you likely need to pay someone to use their node and currently most of the node providers do not allow anonymous purchases (also further encouraging censorship).
I’m not sure if storage cost is the major issue here.
Currently, running a full node requires around 1TB SSD, while even 8TB SSD costs around $500, which I don’t think is too expensive even for solo stakers (given that they’re staking 32 ETH)
(assuming we’re talking about the costs in the consensus layer)
Solo stakers are not the demographic we care about. Users should be able to run an Ethereum node on hardware they already have, and it is rare for a non-gamer to have a multi-TB drive, and even gamers rarely have multiple TBs available.
2 Likes
I think that as soon as we increase the block gas limit and allow more operations within one block, we’ll stumble over new limits. Maybe it’s some opcode that is too cheap, maybe it’s the state or history growth that becomes problematic, or maybe, while most users/validators easily keep up, we lose some who would have to stop their operations.
One cool feature of EIP-7623 is the balancing force between much calldata and EVM operations. A block can still have much calldata but it would cost too much to create a significantly large block. At the same time, if you fill your block with many complex operations, there’s no gas left to make the block “big” at the same time.
Also, I wouldn’t rely much on the current avg. block size as it is only that low on the happy path. Blocks (incl. blobs) can go up to 3.5 MiB right now. This big gap between the avg. and the max. is inefficient (client teams must ensure their software can process such big blocks in reasonable time, knowing such blocks are essentially nothing but an attack and have no other usecase).