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.

More than sequencing fees, I could see sequencing logic and constraints imposed by the synchronisation block and L1<>L2 co-building coordination stand in the way of integrating current L2s with EEZ. Possibly future L2s too, those that have more the shape of semi-sovereign chains deriving properties of and interoperability with Ethereum via blobs. I expect more success with L1 applications that are extending their functionality towards use cases best offered by the shape of a chain, e.g., "app-chains". Will be interesting to observe how it develops!

The FCR rollout continues. Getting RPCs onboarded unblocks many more systems built on their signal, such as bridges. We’re making Ethereum faster day by day, link by link. Great to see from @Quicknode.

I submitted my talk application to @EFDevcon for "Fast Ethereum" on August 6th. This is almost three months ago, a lifetime in this new world. Opus 5.5 was released on September 22nd! Since Aug. 6th, here is what Ethereum obtained: - A formally verified next-generation consensus mechanism, unlocking fast finality and faster slots. - Massive improvements to post-quantum secure cryptography, lowering latency and cost. We've also heard of new threats, and old threats accelerated. Overall the highs are higher, and the lows are lower. Fast Ethereum remains centred on delivering a seamless, responsive, and asset-friendly network. But it has acquired a new dimension for me over the last three months. This is about meeting the moment with urgency and ambition, which I explore in the second part of the talk. Increasingly, we have the means of delivering a secure and more useful Ethereum, with renewed conviction. We can do this! Find my slides:

EEZ went live with their docs and three demos. Extending the L1 is a recurring theme across the demos: - Tapping liquidity from the L1 for a CoW order - Using L1 as root of trust for a Safe owner change - Authorising an L1 transfer from a rollup Increasing L1 utility deepens its function as a centre of gravity for the Ethereum economy. Kudos to the team!

Come find me talk about the multi-node future of Ethereum, and why this sets up Ethereum as the settlement layer of the global economy with ETH at its center. Lotus stage 2 at 2.30pm.

“Ethereum is the most credibly neutral blockchain." - @barnabemonnot Barnabé said this while explaining why $ETH works as a store of value. I asked him questions on faster finality, $ETH as money and the work at @ethlabs. > Faster settlement sits at the top of your agenda. How long does finality take today, and what will it feel like for a regular user once it gets faster?
> What will faster finality mean for someone just sending money on Ethereum?
> Ethlabs is also researching ETH's monetary properties. What questions are you trying to answer about ETH as money, and why should holders care?
> Should ETH be treated as money, and does that change how Ethereum gets built?
> What does Ethereum gain from having more than one research lab working on it?
> What is the one problem Ethlabs most wants to solve in the next year?
> Why does Ethlabs matter to Ethereum? Full Q&A👇

Everyone's worried quantum computers will break crypto. Julian Zawistowski, Founder of Golem Foundation, finds the panic "funny." I asked him for the bull case on ETH. He's honest that Ethereum is still a bet, but he went straight to quantum and thinks it's "uniquely positioned to be quantum ready before anyone else." @julianzawist