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.

Glamsterdam will bring snap sync to the next level. With snap v2, the Block-level Access List, which is basically a state diff, is used to replace the traditional healing phase. The result, it becomes faster and simpler to sync a node. Clients are ready with Glamsterdam. Snycing has never been that smooth.

One step closer to 4-8x faster Ethereum finality! It took some time and lots of tokens, but we now have a formally verified proposal for a decoupled consensus protocol in I* (a future Ethereum upgrade)! Not yet a full spec (up next), but it includes all the key consensus-relevant details to become one. Since Ethereum aspires to be live without most of the stake online, the protocol involves many more components than a normal BFT protocol, and its correctness involves much more than standard safety and liveness. Those nuanced properties are now verified! What's more, I came away convinced that all protocol design will involve AI-assisted Formal Verification in the future, both for correctness and iteration speed. The work wasn't limited to just: Design the protocol -> Formally verify it Instead, the loop became more like: Design -> Formal Model -> Find exactly what breaks and why -> Redesign it. For a fairly complicated protocol like this one, I think having the Lean model be part of the design loop played a big role in accelerating the process. A future with agents paired with formal models is a superpower for Ethereum development, because they can then use those models to find exactly where an argument breaks down, formalize counterexamples, test proposed fixes, iterate on the protocol. Many details that would slip under the radar when asking agents (and indeed, humans) can now be specified exactly and checked by the Lean kernel. This then forces agents to be more precise and lets them make verifiable progress on their own. It's been incredible to see this play out, seeing agents find gaps and propose protocol changes to fix them. In other words, autoresearch can speed up protocol design, formal verification is here to stay, and Ethereum Finality will get faster.

Glamsterdam is coming in hot and the unlock for Ethereum and its user will be huge.

HeLFGOOOOOOOta!!!

Geth's Hegotá tier list: notes.ethereum.org/@lightcli…

@Nethermind Ethereum Client team Hegota scoping: gist.github.com/LukaszRozmej…

Forkcast can now combine multiple tier lists into a single ranking. For example, here’s the joint tier list from @ethlabs_org and @ethereumfndn: forkcast.org/upgrade/hegota/… h/t @wolovim

The Protocol Cluster has published two new posts: Hegotá EIP Opinion Post and Tier List evaluates and grades all 62 EIPs proposed for Hegotá, providing the cluster’s first unified tier list for a network upgrade Current and Emerging Priorities covers commitments and research arcs, anchored on a quantum-resistant Ethereum L1 by Dec. 2029 Offered as one input to Hegotá scoping, roughly 60 researchers, engineers, and individual domain experts across all 9 teams in the Protocol Cluster contributed to the Hegotá tier list, providing 397 tier grades before discussing contested items live. The plan, commitments, and shared set of cluster-wide priorities covered in the companion post provide the context behind the final tier grades. The Protocol cluster will host a Reddit AMA on r/ethereum on September 16 at 2pm UTC to talk through these priorities, the Hegotá tier list, and anything else on your mind. → Submit questions ahead of time here: pad.ethereum.org/form/#/2/fo… Read the articles here: → EF Protocol - Current and Emerging Priorities: blog.ethereum.org/2026/09/07… → EF Protocol - The Hegotá EIP Opinion Post and Tier List: blog.ethereum.org/2026/09/07…

In the upcoming weeks, we'll have to decide what to ship next year in the Hegota hardfork. A few themes appear to get most of the focus: -> native privacy: that's the bundle of EIP-8141 (Frame Transactions) + EIP-8250 (Keyed Nonces) + EIP-8272 (Recent Root Refs). This moves Ethereum closer to native + scalable onchain privacy. -> repricing/security: with increasing block sizes and more blobs, networking throughput goes up. To counter that, EIP-8131 and EIP-8279 meter and reprice data, ensuring blocks propagate safely. The same applies to state growth: EIP-8368 (recalibrating state growth costs) deals with increased state growth at higher gas limits. Those changes can translate into further gas limit increases. -> clean-ups: there's EIP-3289 (removing refunds), EIP-8015 (removing the eth1data field), EIP-8253 (bumping the nonce of a few ancient accounts), EIP-7668 (removing bloom filters), or EIP-8146 separating the BAL from the payload, which also has security benefits from smaller networking objects. PQ prep: EIP-8365 retiring BLS withdrawal credentials, EIP-8298 introducing SETCODEFROM for easier wallet migration, or EIP-8151 restricting ecRecover. Besides the already mentioned EIPs, there are a bunch more, but core-dev resources are scarce and Ethereum's 100% uptime is the #1 priority. This means that while many ideas make sense, they'll have to be deprioritized for the sake of shipping fast and securely. In the upcoming weeks, ACD will make decisions about which EIPs to drop (DFI - "declined for inclusion") and which to move into the next round (CFI - "considered for inclusion"). This usually begins with easy/clear DFI decisions, and the further we get, the clearer the shape of Hegota becomes. Imo, we should focus on privacy and security. This means shipping a cleanly scoped fork in a timely manner, keeping interacting changes to a minimum, and fighting scope creep at every stage of the process. Shipping secure, contained forks doesn't mean we'd stop being ambitious wrt increasing gas limits or blob counts, though. There is still much to do, e.g, prepare Ethereum for PQ, enshrine strong privacy, scale, reduce tx inclusion times, confirmation times, and time to finality, and, in general, harden the chain on every front: sync, RPCs, indexers, wallets, etc. There's still much to do, but Hegota can be a big step forward. The process is fully open and transparent btw. Everyone can rank the proposed EIPs, put them into a tier list, and post it on the Hegota EthMagicians thread. We did so as the Architecture team at EF here: ethereum-magicians.org/t/eip… Do as we did and participate: forkcast.org/rank/

Frame transactions, or native Account Abstraction, improve Ethereum in so many ways: - users choose their signature scheme - passkeys, post-quantum, etc - signature aggregation - key rotation - atomic batching - gas payments in ERC-20s - no bundlers or relayers required - contracts can sponsor transactions - safer (tx assertions)

Frames are all you need. lightclient.io/blog/frames-a…

The relay market keeps evolving. Ultrasound being the largest relay. Titan relay share growing.

Swapping engines while flying.

Glamsterdam, mapped: two devnet streams converge at Interop 🐼, then grow devnet-by-devnet (s/o @ethPandaOps )

One overlooked aspect of EIP-8141 is privacy. Frame Transactions let privacy pools sponsor withdrawals directly from the withdrawal amount, removing the relayer needed today. The next step is STARK aggregation, which can push the cost of privacy pool interactions close to zero. Frame Transactions are also the foundation for native privacy and utxos, mempool aggregation and more. Quite bullish Ethereum.

we will finally kill "stack too deep" the next @ethereum update brings both: 1) the ability to deploy larger contracts 2) lets compilers fix "stack too deep" eth dev is going to rip in Q4

Heads-up for anyone maintaining L1 contracts: → The Glamsterdam upgrade will include gas repricings (EIP-8037, EIP-8038) that shift state creation and access costs. → Most contracts are unaffected, but a small set may break or degrade without updates. Affected contracts rely on assumptions the new schedule changes, such as hardcoded gas values. Full context in the overview: blog.ethereum.org/2026/08/24…

Today is a good day to tweet about ethereum:native . Platåberget testnet is also upgrading to Glamsterdam in about six hours. It’s the first public testnet, the new scaling paradigm is here

Hegotá with 65+ EIPs sounds wild, yes, but it’s nothing we haven’t done before. For the current hard fork, we’re now 258 days in. Since the Merge, we’ve shipped forks every 294 days on average, so we’re still within that range. I’d expect Glamsterdam to overshoot the average somewhat, given how large the fork has become, but it should also be at least as impactful. This Sankey nicely shows how EIPs move through the process: from being proposed, to being considered, to eventually being scheduled for the fork. Most, however, end up being DFI’d, meaning declined for inclusion. With Hegotá, the same process is now repeating.