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.

Last week, core devs had to delay forking the Hoodi testnet to Glamsterdam to study a report by @chain_security which revealed some problems with how EIP-8037 interacts with a few contracts. Over the weekend, ppl tried to get a better picture of the impact and by now it's quite well understood. So here's what you need to know: What's been known is that contracts which hardcode forwarded gas are affected by repricings, e.g. making state writes (SSTORE) more expensive. What's new is that some coding patterns rely on specific invariant which were broken with EIP-8037. Gas already spent can come back mid-tx, so gasleft() can go up. This causes two problems: (1) a before / after gas counter underflows and reverts (2) a failed sub-call hands gas back, so a path that should've been unreachable runs, and the tx looks like it succeeded Related but different: (3) measuring the gas usage of a call using GAS - before and after the call - might undercount because the state gas reservoir is not visible during execution (e.g. gas_left). It's now about deciding how to proceed. Delaying hoodi bought time but won't resolve the issue. This week, we have to dig deep into contracts and make sure nothing is missed. Eventually, this might just need some coordination among the involved parties (dapps, core devs, auditors, people running nodes, etc.), or worst-case, spec changes. If you're an app dev or auditor, check your contracts for issues with EIP-8037/EIP-8038, and report them. Also, share this with your favorite app dev to spread awareness.

8288 will make using privacy apps cheap. Bookmark this too.

This is cool! Partial-stateful nodes will play a major role in Ethereum's future, and this year's hard fork - Glamsterdam - is a big unlock. Nodes will be able to maintain partial state and serve RPC requests without the heavy work of re-executing finalized blocks. This doesn't work for validators, but it's great for home RPC setups, reducing their disk footprint.

Catching up with the chain after being offline will see massive speedups with the upcoming Glamsterdam hard fork. Here's how it works: Today, nodes that come back online enter what's called "full-sync" mode. This means fetching blocks from peers and executing them. This guarantees that nodes verify each state transition and produce transaction receipts (=outputs that tell you "how" your tx executed, the amount of gas it used, logs, etc). With EIP-7928: Block-Level Access Lists (BALs), each block comes with a BAL (=state diff) attached, allowing nodes to apply the changes listed in each BAL to their local state and arrive at the correct post-state, validated against the state root in the block header. This has already been useful for snap sync, and Glamsterdam ships snap/2, improving upon classical snap sync by increasing robustness and speed. It turns out, it's also useful for catching up with the chain after being offline for a while. Instead of entering full-sync mode, nodes can download blocks and BALs from peers and then use the BALs to derive the latest finalized state, and the state diffs between blocks needed for reorgs. Instead of re-executing all transactions, they simply apply the BALs. This works fine for most nodes but some might also want to have the receipts for finalized transactions. In such cases, nodes can either re-execute or fetch receipts from peers. This is safe because execution is only skipped for finalized blocks, as reported by the attached CL client, and it's fast. Nethermind has been experimenting with this, and the first results are pretty wild: 2,000 blocks synced in 40 seconds instead of 76 minutes. That's 115x faster. These are early devnet benchmarks, so take them with a grain of salt, but this is very much the kind of improvement that could make life easier for RPCs, full-node/desktop wallets. Check out @Nethermind 's PR: github.com/NethermindEth/net…

Hoodi is the final testnet before mainnet. With Glamsterdam going live soon, Ethereum will 3.3x its gas limit, from 60M to 200M. From there, 300M feels like a realistic next step.

So far, 23 EIPs are CFI'd/SFI'd for next year's fork, Hegotá. That's a lot already, but tbf, only the two headliners (FOCIL + Frame Transactions) are SFI'd. The rest are still CFI'd and could end up being DFI'd. Over the next couple of weeks, we'll see how many make it into devnets (and thus get implemented by clients), before eventually being SFI'd or DFI'd. AI has accelerated development, and devs are getting faster at shipping code, especially prototypes. But governance and coordination still need to adapt to that pace. Pipelining fork development has never worked as smoothly as with Glamsterdam/Hegotá, with headliner devnets launching before Glamsterdam has even shipped, but scope creep is real and just because we can ship more doesn't mean we should. It's up to the community, including core devs and researchers, to keep forks manageable in size and, most importantly, secure.

"It derived wallet keys from publicly known developer recovery phrases". This seems intended - using the default, hardcoded account for testing and since no one cares about testnet ETH it might have not been emptied. Not sure that's a big deal, really.

accelerating

Ethereum isn't slowing down. It's accelerating.

Glamsterdam EIPs moved from "Review" to "Last Call": github.com/ethereum/EIPs/pul… If you cannot name all 23, here's a quick list: - EIP-2780: Resource-based intrinsic transaction gas - EIP-7688: Forward compatible consensus data structures - EIP-7708: ETH transfers emit a log - EIP-7732: Enshrined Proposer-Builder Separation - EIP-7778: Block Gas Accounting without Refunds - EIP-7843: SLOTNUM opcode - EIP-7928: Block-Level Access Lists - EIP-7954: Increase Maximum Contract Size - EIP-7976: Increase Calldata Floor Cost - EIP-7981: Increase Access List Cost - EIP-7997: Deterministic Factory Contract - EIP-8024: Backward compatible SWAPN, DUPN, EXCHANGE - EIP-8037: State Creation Gas Cost Increase - EIP-8038: State-access gas cost update - EIP-8045: Exclude slashed validators from proposing - EIP-8061: Increase exit and consolidation churn - EIP-8246: Remove SELFDESTRUCT Burn - EIP-8282: Builder Execution Requests - EIP-7975: eth/70 - partial block receipt lists - EIP-8070: eth/72 - Sparse Blobpool - EIP-8136: Cell-Level Deltas for Data Column Broadcast - EIP-8159: eth/71 - Block Access List Exchange - EIP-8189: snap/2 - BAL-Based State Healing cc @rakitadragan

Glamsterdam will bring Ethereum’s biggest throughput increase since launch.

Sepolia testnet validators: update your nodes. Today at ~4pm, we’ll see Glamsterdam (Gloas + Amsterdam) go live on Sepolia. This marks a major milestone for Glamsterdam and for Ethereum more broadly. Glamsterdam’s main focus has been scaling, but at the same time the fork also reduces trust requirements, improves sync, and harmonizes resource pricing to improve DoS resistance as the chain scales. It will likely be the largest Ethereum fork since the Merge, and it has been ambitious from the beginning. ePBS and BALs were selected as headliners early on, and the fork’s theme - scaling - evolved quite naturally from there. When core devs later decided to reprice the EVM as well, the fork’s surface area increased quite a lot and Glamsterdam became a much broader upgrade than initially expected. That also meant more work across specs, clients, tooling, and testing. Almost a year of benchmarking, implementation work, refining specs, testing and devnets followed, and over time Glamsterdam has really started to harden. It has also been the first fork where AI played a major role across basically the whole pipeline: research, benchmarking, testing, client implementations, and security audits, which is interesting to witness. One can clearly feel the accelerated pace at the frontlines: while Sepolia is forking to Glamsterdam, core devs are already busy shipping the first Hegota devnets. Ethereum is not yet where it needs to be, but we’re getting there. Fork after fork, the chain becomes more scalable, more robust, and more capable. And with post-quantum security likely becoming one of the main focus areas over the next few years, there is still a lot ahead.