would love folks thoughts and input here

https://twitter.com/ViktorBunin/status/1745185178362757146

@base contributor #001; onchain cities w/ OAK & city3

yes 

gas limit should have inflated every year since compute/disk/memory continually improve.

Real World Ethereum 🌎 
building /daimo ✳️ 

cc @ansgar.eth i remember you were skeptical of validator voting. should limits like the blob limit and gas limit only be changeable by hard fork? / why?

i'd love to see it. "anyone can run a home validator for $1000 in hardware + $100/mo in internet" is an important schelling fence, but that buys more every year!

important to keep reinforcing the precedent that Ethereum is not static. tech choices rooted in principled empiricism rather than religion

Ethereum protocol R&D. Admirer of emergent order.

I’m for it, though 33% seems like a big jump, as @ansgar.eth said we already have a “blocksize increase” shock soon with 4844, perhaps we can go at it iteratively

I think an objective document outlining pros/cons and the expected outcome would be helpful here.

Even being in the space for a while it’s hard to have an informed opinion and meaningful contribute to these gas conversations.

any changes to block gas limit shd consider:

1. impact of upcoming dencun/4844 on node resource reqs, esp bandwidth. i think @ansgar.eth said this is equiv. to +11m gas

2. cross-client benchmarking for worst case scenarios - back things up w/ clear data + methodologies. @dcbuilder is putting together a group

context for anyone diving in!

https://warpcast.com/trent/0xb40d2985

Yes! That would send a strong signal across the industry and show our ability to influence the ecosystem without the implications of the Ethereum Foundation

This may be orthogonal, but I would love to see a higher block gas limit on Base (and other L2's).

I want to utilize the cost savings of Base to have more exhaustive accounting on chain, but for some use cases I have run into block gas limit constraints

I read the first half of the first reddit comment and agree completely

Researcher at Clave and
Co author of EIP-7212 

so on a worst-case attack block, the 85% running Geth are totally fine, and the 4% running Besu are still fine (but cutting it closer?)

sending those is expensive, and the attacker gains nothing.

my takeaways from that table: 1. 40m gas seems fine, 2. small clients need perf improvements, 3. Reth will rip

Speeding up clients seems like a tractable problem though?

I think not yet - 4844 early results already show significant impact to gas and latency

There are centralization vectors not just from the increased hardware cost but the second order effect on the PBS builder market. It can also add complexity to SSF

Further R&D efforts are warranted imho