Thought I’d start with what I’ve observed over the years.. For many years researchers (I was one of them) kept being told by a vocal part of the community that gas should be turned way up and to hell with small nodes. We did hear scaling demand from app devs, at least that they were considering deploying away from L1 because they did not imagine their scaling needs could be met. It took a while (too long) to internalise that scaling was desirable, particularly given the L2-centric roadmap that considered more or less that activity should be offloaded from the L1 and towards L2s. If app devs go there, that’s a feature! Clearly this thinking has been heavily updated, more towards apps should go wherever they’d best leverage the platform they’re building on, either L1 or L2s. Then somewhere around March 2025 we sat down more properly and I think that was the first seeds of a clearer scaling roadmap for Ethereum. L2s were in favour too, scaling was useful to them from the blob perspective, but many would also highlight a strong L1 being a better value proposition for them. Repricings like the ones Glamsterdam intends to do were discussed iirc. They’re not a strange researchy solution in my view, when you look at how to prevent DoS attacks like Shanghai, it’s clear that getting the price right is the first step. But here it’s more about the long-term load. I don’t think it’s right to say we’re overindexing on historical precedent, the NFT reference was perhaps a bit unhappy. afaict (chart attached below!), state creation is distributed fairly equally over time, and scales linearly with the gas used (the bigger the blocks, roughly proportionally more state). So then there’s a couple points. 1. Yes state creation increases 5x, bytecode increases 7.65x, but gas limit increases 3.33x, meaning relatively speaking, state creation gets 50% more expensive, and bytecode 2.3x. Not trivial! But some of the state operations besides creation benefit from the block-access list feature that ships with Glamsterdam too. And then future, deeper updates like partitioned binary tree continue to push state access costs down again. Not state creation, afaik, but for bytecode, nodes already don’t keep duplicated code around so proposals like SETCODEFROM can stop charging for it. 2. Then there is the issue of contracts breaking because they have made specific assumptions about the cost of state operations. This is where the line has been that such expectations were misplaced, Ethereum had done such changes in the past etc. I agree with this, and to be clear as a supporter of quick slots, block time is another such parameter that I think we should be allowed to update. But of course it’s a bit of a rollercoaster that transactions were capped at 16.7M gas in Fusaka and now they could be consuming more gas with the reservoir, so this is a legitimate expectation that is now broken shortly after being introduced. It’s mostly a tooling impact more than a contract impact, but still. 3. And then there is the issue of contracts breaking beyond what most would consider legitimate. This was surfaced in reviews and audits, sadly it seems that it wasn’t addressed until late, with pcaversaccio shining a light on these issues that triggered the heightened attention. Most of the attention is on that now, and all known findings are expected to be published by early next week. Any of the three above could be controversial. On net, I think 1. is neutral-ish, it simply tries to make the best of the limited resources of the network, and state is the resource that doesn’t scale as well as the others, until deeper changes like expiry (if that's ever a thing.. that also has DX implications). 2. has precedents, but it caught more people by surprise than it should have imo. 3. is an issue, and there’s possibly a judgement call to make regarding how to move forward here, I’ll not opine on it until I see more of the findings. I don’t think this addresses the point about sentiment around the fork. I’m sad that it is this low. From my perspective everyone is clear about building better loops between core protocol and builders, even pointing at the contract size increase contained in Glamsterdam as proof we were finally listening.. but the mark was missed here and the reaction is legitimate. I’m hopeful that this week and the next will bring a lot more clarity and structure to the discussion. We have a post coming tomorrow (Tuesday) laying out some of these steps. Fully expect that it won’t clear up every disagreement, and it’s not about explaining away the sentiment of experienced devs either. I talked about Ross’s piece here because I found it well-balanced, and it led me to consider how the fork would be perceived if the developer outreach had been earlier and stronger. It’s possible that it wouldn’t have changed the core disagreement. For the future, the only way I see here is to be clear about what expectations are, also something briefly discussed here I’ve seen versions of this around and I expect we’d want to push something like this once the current crisis is resolved.