Toni Wahrstätter ⟠(@nero_eth):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:

2026.10.19 06:21

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: