Happy 10th birthday to Ethereum! Its an understatement to say this project has been life changing ❤️

AND HERE IT IS: First 45 Milion Gas Limit block proposed on #Ethereum Mainnet! 🔥🚀 Next Target: 60M 📈

The gas limit is slowly moving upwards! We should be at 45M soon. If you run a validator, all you have to do is update your software!

Headliner picks from all client teams: Execution Layer: - Geth: EIP-7928 (Block-level Access Lists) - Reth: EIP-7928 + EIP-7732 (ePBS) + EIP-7805 (FOCIL) stretch - Erigon (both EL + CL): EIP-7928 + EIP-7805 + EIP-7782 (Reduce Block Latency) - Nethermind: EIP-7928 + EIP-7732 and also support EIP-7805 + EIP-7692 - Besu: EIP-7928 + EIP-7732 + EIP-7805 stretch Consensus Layer: - Lighthouse: EIP-7732 (ePBS) - Prysm: EIP-7732 + EIP-7805 stretch - Grandine: EIP-7732 + EIP-7805 stretch - Lodestar: EIP-7732 + EIP-7805 stretch + EIP-7919 Pureth for EL - Teku: EIP-7732 - Nimbus (both CL + EL): EIP-7732 + EIP-7919

is anyone aware of past efforts to build a mathematical bandwidth utilization model for Eth? as we scale L1 capacity+throughput, scale blobs, restructure the slot, increase propagation efficiency, add new mechanisms (e.g. FOCIL, BAL), shard the mempool, etc. we're working against the constraints of EIP-7870. we'd benefit from a model where we can punch in parameters like block gas limit, mempool pressure, blob count, propagation overhead & efficiency factors, blob count, blob utilization, validator count, active peer count, checkpoint sync activity, etc. in order to visualize how it all stacks up along the slot timeline. also to alert us when our choices violate EIP-7870. at design time, this would help us reason about tradeoffs, bandwidth allocation, throughput/goodput. also, it helps drive discussion about active traffic shaping, where we explicitly prioritize certain types of activity at different instants (and throttle bandwidth to others) in order to maximize overall system efficiency. essentially a tunable mathematical model of the very elemental chart below (which omits a lot),

Took a look at the entire Ethereum validator set to calculate how many consolidation opportunities were missed after the Pectra upgrade. Key stats: - Since pectra, 96,672 new validators got activated - 79,547 of those validators could have been consolidated, they reused a pre-pectra withdrawal credential - 14,362 of those validators reused a post-pectra withdrawal credential - This leaves just 2,763 truly “unique” validators! At some point, we have to ask what’s preventing validators from consolidating, is it tooling maturity, confidence time frame, or something else? Happy to help anyone consolidate or talk through it, just DM me

No seriously, what even IS an @ethereum fork "headliner"? Who do the proposed EIPs benefit? How do we compare across them? My team at the @ethereumfndn is looking to make the upgrade process easier to understand. I'm stoked to share a smol tool we've been hacking on: 🧵↓

After a really productive in-person week with client devs, we arrived at a plan for how we want to tackle scaling and the challenges that might arise. Expect a steady stream of analysis and progressive updates to the gas limit in the future.

Attestation Propagation: In missed slots (no block), attesters delay until the attestation deadline. This gives us clean data on when non-aggregated attestations hit nodes. Even fast, well-connected Xatu nodes (DC-hosted) only see ~40% of attestations after 1s; slower ones hit 40% after 2s. These are better-than-average-case latency observations.

Special interop edition of the Checkpoint series! The Checkpoint posts are accessible updates to @ethereum core development. This past week, core devs & researchers got together for an in-person hacking week during @BerBlockWeek and this is an inside look into what they did: