faheel

Blockchain dev | building MEV infra @PBS_Foundation | Protocol Fellow @ethereum | Previously @ShutterNetwork

[faheel @721Orbit]

Few days ago i tweeted about the internals of Geth. @noxx3xxon suggested me to do a breakdown of storage vs memory so here it goes. A thread

[Toni Wahrstätter ⟠ @nero_eth]

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.

[faheel @721Orbit]

Solid work!

[Gul Hameed @CyberGul]

spent some time pulling my security work into one place
👇

web2 pentests → CEX audits → web3 protocol audits.
Research.

want to collab? DMs open
https://t.co/zzseqo3NQv

[Ethereum @ethereum]

Last week, Ethereum core contributors gathered in Svalbard for the Soldøgn interop: a week long event focused on hardening Glamsterdam implementations to scale Ethereum securely ☀️

Read the full recap, including their candidate post-fork gas limit, below:

[Mario Havel @TMIYChao]

Applications are now officially opened! Welcome to EPF7, we keep going and look for the best talent Ethereum to bring to core development
https://t.co/zjNteXP982

[carlbeek @CarlBeek]

excited to see H* starting to take shape, between frame transactions and quick slots ⚡️🎰, it’s going to bring the biggest ux upgrades to ethereum thus far!

[joshrudolf.eth @rudolf6_]

1/ How L1 and L2s can build the strongest possible Ethereum

tldr: we should continue to lean into the unique capabilities of each layer, and make sure all users have a clear path to securely and seamlessly benefit from the core properties of Ethereum

[Davide @0xseiryu]

1/ The Ethereum protocol prices congestion correctly. Wallets don’t.

• 25 days of data.
• ~185k observations.
• 3 wallets.

One clear mismatch ↓

[Julian @_julianma]

https://t.co/7WZDKbB4Iz

[ethPandaOps @ethPandaOps]

It turns out some AI models can step through EVM bytecode in their head.

We built EthIQ, a new benchmark to test how well models actually understand Ethereum protocol internals.

325 questions across two evaluation modes, and one alive canary 🐦

Read more 👇

[PBS Foundation @PBS_Foundation]

Be @Bitwise: support @ethereum open-source development tirelessly through bear and bull.

Honored to be recipients alongside @ProtocolGuild, supporting critical PBS infrastructure and research for a more decentralized future with this second annual donation! 🙏

[kaden.eth @0xKaden]

✨Introducing evmresearch✨✨

A knowledge graph of nearly everything I've learned about the EVM in the past six years

The graph structure emulates the brain, exponentiating research speeds for both humans and agents

https://t.co/974InOGRmw

[Shutter 🛡️⚔️ @ShutterNetwork]

Markets need fairness to function, that's why in TradFi front running is illegal & "Payment for Order Flow" (PFOF) is getting banned

For Ethereum, we don't want regulation nor centralized parties to "solve" this for us

We can do better, EIP-8105 will help get us there

[Potuz @potuz_eth]

This one is more on the technical side, it's a first pass annotating the Gloas Fork until @benjaminion_xyz catches up.

Mostly for client devs that are asking why this or that was included instead of how the spec works.
https://t.co/TSLphGhHcm

[faheel @721Orbit]

@potuz_eth yepp, forgot to mention this

[faheel @721Orbit]

How do block builders submit their blocks after ePBS (EIP-7732)?

Two pathways:
Off-chain: Direct proposer ↔ builder via Builder-API
On-chain: Public bidding via p2p gossip

Let's break down exactly how each works.

[faheel @721Orbit]

@drjasper_eth yess, in practice for a proposer its best to connect to as many builders

[faheel @721Orbit]

We are also trying to figure out how this protocol update affects preconfs, and other off chain infra. If you are working on these things, lets talk😁

https://t.co/1RceCzulSK
https://t.co/GaXsE96UwH
https://t.co/sMU4ex53e7

[faheel @721Orbit]

14/ With this path we can lower the risk of centralization which might exist if the proposers directly only connect to few big builders which have a history of publishing better bids, lowering the chances of smaller builders to enter the market.