Ethereum is about to fundamentally change how blocks are executed. With the upcoming Glamsterdam hardfork, it's shipping EIP-7928: Block-level Access Lists, a proposal that brings parallelization to the EVM. Here's a short explainer of what it is, how it works, and why it's a big deal for scaling. Let's start from the top. Alongside EIP-7732 (ePBS), EIP-7928 is the execution-layer (EL) headliner for Glamsterdam. Like ePBS, the main focus has been scaling Ethereum, though both proposals come with a bunch of other, equally important properties on the side e.g. removing trust requirements from the PBS pipeline or improving sync. EIP-7928 adds a Block Access List (BAL) to every Ethereum block. A BAL is a list of accounts and storage slots that the block touches, but that's not all: it also contains post-transaction state diffs (this part is critical!). Post-transaction state diffs tell you what the state looks like after each transaction. Quick example: user A swaps 1 ETH for DAI on DEX B. The BAL tells you that user A's ETH balance decreased by 1 ETH tx fees and their nonce went up by 1; that DEX B's ETH balance went up by 1 ETH; and that inside the DAI contract, user A's DAI balance increased while DEX B's decreased. In other words, all of that info becomes statically available, something that previously required tracing the transaction. Client software (Geth, Nethermind, Besu, Erigon, Reth, Ethrex, Nimbus) can use this to do a few very powerful things: 1. Parallelize transaction execution. Knowing the post-state of each tx resolves the dependencies between them. No transaction has to wait on the previous one anymore, so execution can be perfectly parallelized. Instead of large parts of block validation sitting idle waiting on sequential execution, clients can finally make much better use of modern hardware. 2. Batch prefetch. One of the most cumbersome jobs for a node has been fetching the state needed for execution from disk. Because state locations (e.g. the exact storage slot in the DAI contract where user A's balance lives) are only discovered along the way, while executing, state-fetching has been a real drag on scaling: it blocks execution, takes time, and eventually slows everything down. With BALs, everything a node needs for execution is known upfront and can be loaded into cache in one go, in parallel. This speeds things up even further. 3. Parallelize post-state root calculation. Another expensive task is walking the updated state tree to compute the post-state root, which is needed so that everyone agrees on what's on disk after executing the block. With the post-tx state already in the BAL, nodes can do this in parallel while executing. A heavy task that used to wait until all transactions had finished can now run alongside prefetching and execution. 4. Snap sync (v2). An often overlooked, less sexy aspect of blockchains is syncing. Nodes need to catch up with the chain, and they need to catch up faster than the chain progresses. Today, most nodes do snap sync: downloading blocks, headers, and state in parallel while chasing the tip, and then "healing" the database once they're close to the head. Healing means asking peers for trie nodes, receiving them, validating them, and updating the local DB. It's iterative, networking-heavy, can take a while, and especially higher throughput pushes that phase to its limits. BALs help here too: with snap v2, nodes can catch up to the tip and skip the healing phase entirely. Syncing at higher throughput becomes more robust and reliable. So, to summarize, a BAL contains two things: -> The state locations the block accesses -> The state changes after each tx (incl. the new values) We're already seeing big performance gains today: on 6-core machines, EL clients validate blocks up to 5x faster, making block gas limits of 300M a very realistic outcome. ePBS will add to that by decoupling the block from the payload, giving validators 2-4x more time for execution. To not overshoot (security stays priority #1), the fork will likely ship with a 200M gas limit, but we shouldn't be stuck there for long before pushing to 300M and beyond. That's a 10x in scaling since we started taking the topic seriously, without touching hardware requirements. None of this would have happened without people going all-in, heads down, shipping: so many hours spent in calls debating the right design, so many iterations refining the specs, and tons of test cases written (and still being worked on). The road from whiteboard to production-ready code has been a journey, and we're not at the finish line yet, but from what I can tell, things look super bullish for Ethereum. Glamsterdam will be a fork that shows what's possible when a distributed, decentralized community works on a shared goal, laser-focused on providing enough block space to onboard the next wave of users.

New EIP! Multi-block access list warming 🔗 github.com/ethereum/EIPs/pul… Highlights: - Introduces a new chain-derived structure, the Warm-Access Multiset (WAM), that keeps refcounts for accounts and (address, storage_key) pairs seen in Block Access Lists (BALs) over a sliding 256-block window; an item is warm if its count > 0. - Meaningfully reduces repeated cold-access charges across blocks: empirical analysis cited shows ~14.1% median per-block gas savings at a 256-block horizon (vs ~18.4% estimated upper bound), with 256 blocks capturing ~76% of the recoverable savings. - Efficient maintenance: per-block updates are O(|BAL_in| |BAL_out|) by incrementing items from the newest BAL and decrementing items aging out of the window, avoiding recomputing unions across many blocks. - Adds a verifiable commitment: WAM is committed via a fixed-depth (256) binary Sparse Merkle Tree using SHA-256, and the resulting 32-byte `wam_root` is added to the block header; this enables uniform inclusion/non-inclusion proofs and is positioned as zkEVM-friendly (SHA-256 cheaper than Keccak in typical circuits). - Backwards-compatible and forward-only: existing transactions become cheaper or unchanged (no new gas constants, no invalidations), at the cost of additional node state (~10 MB typical at W=256, worst-case bounded but much larger) and one extra header field; WAM is updated per-block and is unaffected by transaction reverts. ELI5: Ethereum charges extra “cold” gas the first time a transaction touches an address or a storage slot, then it’s “warm” (cheaper) for the rest of that transaction. This EIP makes recently-used addresses/slots stay warm not just within one transaction, but across many blocks: if something was used in any of the last 256 blocks, it starts out warm in the next block’s transactions. To track that efficiently, the chain keeps a rolling counter set (a multiset) of recently-accessed items and commits it to the block header so others can verify what’s warm without downloading lots of history.

Does Ethereum need an enshrined deterministic factory (EIP-7997)? Factories such as Arachnid, ERC-2470, CreateX, and 0age's deployer exist at the same address across Ethereum and most EVM chains thanks to Nick's method: a pre-signed transaction with a fixed gas limit. They enable devs to deploy contracts to the same address across chains. The gas limit set in the tx that deploys those factories is part of the signature and cannot be changed. As state cost increase (e.g. EIP-8037), some deployments may no longer fit. CreateX, 0age's deployer, and pcaversaccio's deployer already have essentially zero gas headroom, Arachnid not enough, meaning future chains following Ethereum's gas schedule may not be able to deploy them at their canonical addresses. In practice, this is mostly a future-chain problem. Ethereum L1 and most existing chains already have these contracts deployed, and many L2s and new chains use their own gas schedule, so canonical deployment addresses are not guaranteed across all chains today anyway. For Ethereum Glamsterdam devnets this issue has come up and we'll likely go with putting those factories inside the genesis state, mirroring Ethereum mainnet, something that future chains could do too. At today's ACD, we discussed whether to enshrine a canonical deterministic factory via EIP-7997, or defer the decision until we have more info and potentially target Hegota instead. Curious where people stand on this.

We built a simulator for the fast confirmation rule, and replayed a years worth of blocks and attestations on Mainnet. Across 800,000 mainnet slots, roughly 96 out of every 100 slots would have been fast-confirmed within 12 seconds. Zero false confirmations. Read more below!

🪾New EIP-8272: Recent Roots for Frame Transactions 🪾 by @soispoke, @nero_eth and @VitalikButerin Another EIP to enable native, trustless, censorship-resistant privacy on Ethereum. tldr: Private transactions on Ethereum often need to prove against a recent commitment tree root. This EIP lets a FrameTx carry that root directly in its signed envelope. The protocol checks that the root was written onchain for the referenced slot and is still inside the usable window. This means validation can use the root without reading arbitrary application storage. The goal is to help private transactions get FOCIL inclusion guarantees by making recent roots part of the partial state attesters will store after the transition to zkEVM. Target fork: Hegota Links below 👇

A quick post on how ePBS changes Ethereum scaling: terencechain.com/writing/epb…

amidst noise & uncertainty, eth core devs push forward with significant protocol improvements --- respect for their tireless, behind-the-scenes effort! economies require robust public infra. we desperately need consistent, scalable, unencumbered funding for this protocol work

Breakthroughs coming to attestation broadcast too. Three principles: shaving off wire bytes, reducing latencies, increasing information efficiency per committee. One Hegotá proposal that made several Core Devs happy is Batching Attestations at Source, authored by yours truly, in collaboration with @nero_eth and @mkalinin2. github.com/ethereum/EIPs/pul…

Bitcoin doesn’t need a "new" privacy solution that’s really just a worse mixer wrapped in multisigs and trust assumptions. CoinJoins already work, and they’ve worked for years. Reinventing privacy badly is not progress.

The blog post is great, but something that is often lost, or simply taken for granted, may not be so obvious to everyone. In my experience the single most important aspect of these meetings is the human interaction and trust-building connections that are started in these events. It is pretty clear that Ethereum is steered by a body of people representing very disparate corporate and personal interests. After a few nights hacking until 3am you get a clear feeling on people's values. We may disagree on some technical aspects, very strongly at times, but I know my allies and whom to trust mostly from these meetings. And often times are the ones that disagree with me the most. blog.ethereum.org/2026/05/02…

Now that Glamsterdam made solid progress at the interop, we’ve started ramping up work on Hegotá. At first glance, Hegotá looks easy. A fork with one headliner. But you’ve been warned. FOCIL is just the beginning. A long line of EIPs is vying for inclusion. Plenty more to come in subsequent forks. Native AA, statelessness, execution proofs, PQ, Fast Finality and so on. It’s hard to say which one is more important or more difficult than others. Exciting years ahead. Stay ambitious. Play the long game.

10M of stake, just ~12500 validators. If the whole stake was like this, we could finalize in seconds. Let your staking pool know that you want the finality time to go down by 100x, and let's get the remaining 900k validators down to a few thousands 🫡

Excited about what @lou3ee is cooking. Dude captured the magic and chaos of Ethereum core devs perfectly. Can’t wait for this one.

Privacy is good 🤝

Privacy 🤝🏻 2D nonces.

Ethereum is turning privacy into a first-class primitive. Frame transactions (EIP-8141) 2D nonces remove the need for intermediaries: fees can be paid from the withdrawal itself, no third party relayer or doxxed account needed anymore. Next steps include: - cheaper deposits/withdrawals (more throughput, cheaper proving) - enshrined privacy at L1 More details in the ethresearch post: ethresear.ch/t/frame-transac…

Ethereum continues to scale in the background. Gas prices are low, so maybe people don't care as much, but it's important to get ahead of the coming demand surge.

Glamsterdam changes the scale. Ethereum will see a gas limit increase by more than 3x, introducing parallelism, smart slot pipelining, sustainable state handling and more. Wouldn't have been possible without Tim - thank you! 🫡

Ethereum is about to scale hard. Time for app devs to revisit ideas that failed years ago due to high gas costs. 200M gas looks very realistic, and 300M is well within reach. Glamsterdam changes the scale.

Interop for Glamsterdam was a big success, and from what I can tell, it will bring major scaling improvements to Ethereum. With BALs (EIP-7928), nodes can parallelize transaction execution, state root computation, and batch prefetch the state needed for a block. With ePBS (EIP-7732), we get ~2-3x more time for execution. Devs have been shipping non-stop this week, and I’m as tired as I am convinced this fork will be a huge unlock.