Rafael Matias 🐼🕯️

Doing Ethereum stuff at the @Ethereum Foundation. @ethPandaOps

[Péter Szilágyi @peter_szilagyi]

Dark Bio whitepaper is out!

We're building a system in which a person's health data, their genome most of all, no longer has to live with a custodian to be useful. A system, where data does not move, rather stays on a small device the owner holds.

[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.

[Rafael Matias 🐼🕯️ @skylenet]

@trent_vanepps @TimBeiko @ProtocolGuild Thank you so so much for your work and dedication! You rock 🤘

[carlbeek @CarlBeek]

the QuickSlots ⚡️🎰 website is live, and I'm very proud of the design! take a look!

https://t.co/yIfNTnHbbX

QuickSlots is the pragmatic way to get Ethereum to run much faster

[Fate meh @Fatalmeh]

I wish all those who spend so much critical thinking going after EF would give a tiny fraction of it to tweet about the 28days long comms shutdown in Iran, the war their countries are involved in or initiated, the fear and suffering and destruction of so many innocent lives

[Mario Havel @TMIYChao]

One month, only 30 days, left in Bordel crowdloaning campaign to fund a DeFi mortgage for our new community space! https://t.co/YM3ti9ETEH

We are building a space for independent creation, chaotic education and sustaining cypherpunk values.

What is it and how does it work?!👇

[Justin Drake @drakefjustin]

Introducing strawmap, a strawman roadmap by EF Protocol.

Believe in something. Believe in an Ethereum strawmap.

Who is this for?

The document, available at strawmap[.]org, is intended for advanced readers. It is a dense and technical resource primarily for researchers, developers, and participants in Ethereum governance. Visit ethereum[.]org/roadmap for more introductory material. Accessible explainers unpacking the strawmap will follow soon™.

What is the strawmap?

The strawmap is an invitation to view L1 protocol upgrades through a holistic lens. By placing proposals on a single visual it provides a unified perspective on Ethereum L1 ambitions. The time horizon spans years, extending beyond the immediate focus of All Core Devs (ACD) and forkcast[.]org which typically cover only the next couple of forks.

What are some of the highlights?

The strawmap features five simple north stars, presented as black boxes on the right:

→ fast L1: fast UX, via short slots and finality in seconds
→ gigagas L1: 1 gigagas/sec (10K TPS), via zkEVMs and real-time proving
→ teragas L2: 1 gigabyte/sec (10M TPS), via data availability sampling
→ post quantum L1: durable cryptography, via hash-based schemes
→ private L1: first-class privacy, via shielded ETH transfers

What is the origin story?

The strawman roadmap originated as a discussion starter at an EF workshop in Jan 2026, partly motivated by a desire to integrate lean Ethereum with shorter-term initiatives. Upgrade dependencies and fork constraints became particularly effective at surfacing valuable discussion topics. The strawman is now shared publicly in a spirit of proactive transparency and accelerationism.

Why the "strawmap" name?

"Strawmap" is a portmanteau of "strawman" and "roadmap". The strawman qualifier is deliberate for two reasons:

1. It acknowledges the limits of drafting a roadmap in a highly decentralized ecosystem. An "official" roadmap reflecting all Ethereum stakeholders is effectively impossible. Rough consensus is fundamentally an emergent, continuous, and inherent uncertain process.
2. It underscores the document's status as a work-in-progress. Although it originated within the EF Protocol cluster, there are competing views held among its 100 members, not to mention a rich diversity of non-EFer views.

The strawmap is not a prediction. It is an accelerationist coordination tool, sketching one reasonably coherent path among millions of possible outcomes.

What is the strawmap time frame?

The strawmap focuses on forks extending through the end of the decade. It outlines seven forks by 2029 based on a rough cadence of one fork every six months. While grounded in current expectations, these timelines should be treated with healthy skepticism. The current draft assumes human-first development. AI-driven development and formal verification could significantly compress schedules.

What do the letters on top represent?

The strawmap is organized as a timeline, with forks progressing from left to right. Consensus layer forks follow a star-based naming scheme with incrementing first letters: Altair, Bellatrix, Capella, Deneb, Electra, Fulu, etc. Upcoming forks such as Glamsterdam and Hegotá have finalized names. Other forks, like I* and J*, have placeholder names (with I* pronounced "I star").

What do the colors and arrows represent?

Upgrades are grouped into three color-coded horizontal layers: consensus (CL), data (DL), execution (EL). Dark boxes denote headliners (see below), grey boxes indicate offchain upgrades, and black boxes represent north stars. An explanatory legend appears at the bottom.

Within each layer, upgrades are further organized by theme and sub-theme. Arrows signal hard technical dependencies or natural upgrade progressions. Underlined text in boxes links to relevant EIPs and write-ups.

What are headliners?

Headliners are particularly prominent and ambitious upgrades. To maintain a fast fork cadence, the modern ACD process limits itself to one consensus and one execution headliner per fork. For example, in Glamsterdam, these headliners are ePBS and BALs, respectively.

(L* is an exceptional fork, displaying two headliners tied to the bigger lean consensus fork. Lean consensus landing in L* would be a fateful coincidence.)

Will the strawmap evolve?

Yes, the strawmap is a living and malleable document. It will evolve alongside community feedback, R&D advancements, and governance. Expect at least quarterly updates, with the latest revision date noted on the document.

Can I share feedback?

Yes, feedback is actively encouraged. The EF Protocol strawmap is maintained by the EF Architecture team: @adietrichs, @barnabemonnot, @fradamt, @drakefjustin. Each has open DMs and can be reached at first.name@ethereum[.]org. General inquiries can be sent to strawmap@ethereum[.]org.

[ethPandaOps @ethPandaOps]

New in Xatu: Execution trace data.

Per-opcode gas consumption for blocks/txs. 9 new tables covering call frames, opcode gas, and daily/hourly aggregations.

Blog post + schema docs: https://t.co/jQdeG2a1uV

[Go Ethereum @go_ethereum]

🚨 Geth v1.16.8 is out

This is a security release addressing issues that can impact liveness.

Geth node operators and downstream maintainers are strongly encouraged to upgrade promptly.

[ethPandaOps @ethPandaOps]

⏰ BPO2 lands on Mainnet on Wed 07/01/2026 at 01:01:11 GMT (in ~13 hours) - raising the max blob count to 21

No preparation or action is required, but we advise all node operators to monitor their infrastructure around fork time

View the countdown: https://t.co/Z3paW4Zi09

[vitalik.eth @VitalikButerin]

Welcome to 2026! Milady is back.

Ethereum did a lot in 2025: gas limits increased, blob count increased, node software quality improved, zkEVMs blasted through their performance milestones, and with zkEVMs and PeerDAS ethereum made its largest step toward being a fundamentally new and more powerful kind of blockchain (more on this later)

But we have a challenge: Ethereum needs to do more to meet its own stated goals. Not the quest of "winning the next meta" regardless of whether it's tokenized dollars or political memecoins, not arbitrarily convincing people to help us fill up blockspace to make ETH ultrasound again, but the mission:

To build the world computer that serves as a central infrastructure piece of a more free and open internet.

We're building decentralized applications. Applications that run without fraud, censorship or third-party interference. Applications that pass the walkaway test: they keep running even if the original developers disappear. Applications where if you're a user, you don't even notice if Cloudflare goes down - or even if all of Cloudflare gets hacked by North Korea. Applications whose stability transcends the rise and fall of companies, ideologies and political parties. And applications that protect your privacy. All this - for finance, and also for identity, governance and whatever other civilizational infrastructure people want to build.

These properties sound radical, but we must remember that a generation ago any wallet, kitchen appliance, book or car would fulfill every single one of them. Today, all of the above are by default becoming subscription services, consigning you to permanent dependence on some centralized overlord.

Ethereum is the rebellion against this.

To achieve this, it needs to be (i) usable, and usable at scale, and (ii) actually decentralized. This needs to happen at both (a) the blockchain layer, including the software we use to run and talk to the blockchain, and (b) the application layer. All of these pieces must be improved - they are already being improved, but they must be improved more.

Fortunately, we have powerful tools on our side - but we need to apply them, and we will.

Wishing everyone an exciting 2026.

Milady.

[Sam Calder-Mason @samcmAU]

Heres some data from the last 24h of nodes that we connected to on Mainnet wrt. PeerDAS.

- 17.6% of nodes are supernodes (4096+ ETH staked)
- 46.1% custody 4 columns (the minimum)
- 23.4% custody between 5-8 columns

IMPORTANT: These are NODE counts. They are not directly stake weighted.

More insights below 👇

[binji @binji_x]

not a fusaka explainer, but i hope you get a chance to read this.

[parithosh | 🐼👉👈🐼 @parithosh_j]

Don't forget that we managed 2x the forks in a year while shipping a bunch of other things and keeping the chain healthy! Client devs are beasts ❤️🐼

[ethPandaOps @ethPandaOps]

Fusaka is now live and finalized on Mainnet! We're busy looking at the data now and will update you on how the networking layer looks once we have enough samples!

In the meantime, please report any bugs you see with your nearest friendly client dev!

[ethPandaOps @ethPandaOps]

Happy Fusaka week! 🦓

New Lab view going live shortly after Mainnet: live custody monitoring for PeerDAS. Are peers actually storing what they claim? Let's verify them in real-time.

Built in collaboration with @ethereumfndn's P2P team🤝

[terence @terencechain]

Happy 5th birthday to the beacon chain
Crazy to look back at how far the network has come and how much has grown since genesis
Huge thanks to everyone who’s pushed this thing forward over the years 🎉

[Rafael Matias 🐼🕯️ @skylenet]

3 Servers seized in Zürich from a Bitcoin mixer. 25M eur worth of currencies. But the best part, is the video https://t.co/R871wGXmu1 . Man, the EUROPOL intern needs a raise. 🔥

[Rafael Matias 🐼🕯️ @skylenet]

I still remember being on my first DevCon in Prague and reading this book. Ethereum was totally new for me back then. It helped me a lot. Can recommened🙏 Also shoutout to @nonsens3 for answering all my newb questions back then.

[Blackie.hl @ManInBlackie]

Mastering Ethereum: Second Edition is officially out for free on github.

You can read it directly on github or on masteringethereum/./xyz if you prefer that UI.

Enjoy the book and let us know if you like it.