# Ethereum's Future: The Strawmap, Glamsterdam & Hegota | Paritosh (Berlin Ethereum Day, June 2026)

- Channel: [Berlin Ethereum Meetup](https://streameth.org/berlin-ethereum-meetup)
- Date: 2026-09-09
- Duration: 11:23
- Watch: https://streameth.org/watch/yt-CKp7RyF6s1I
- YouTube: https://www.youtube.com/watch?v=CKp7RyF6s1I

## Description

A coordinated roadmap toward a faster, more scalable, and truly decentralized Ethereum by Parithosh Jayanthi (ethPandaOps lead
at the Ethereum Foundation)

The Berlin Ethereum Day was a one-day event held on June 15, 2026 during the Berlin Blockchain Week.

The full-day program brought together speakers from the Ethereum Foundation and the broader FOSS, privacy, and security ecosystems to explore the future of Ethereum and self-sovereign technologies - from technical direction and core values to the challenges and opportunities ahead.

Future Meetups and Events: https://www.meetup.com/berlin-ethereum-meetup/

More information on the speakers and the agenda: https://berlinethereumday.com/

## Transcript

Hi, my name's Paritosh. I work at the Panda Ops team at the Ethereum Foundation. Um thank you for the intro, Martin, uh and thanks for having me. So, the Panda Ops team mainly focuses on testing and shipping the next fork on Ethereum. Today, I'm going to be talking about the straw map. Uh you might have seen this earlier this year making the rounds on Twitter and the Ethereum Foundation blog post. Uh I want to talk about what the straw map aims to ship. My focus is going to be a bit more on the earlier side of the straw map, so what's coming in Glämserdam, what's coming in Bogota, rather than the uh later half of the straw map, but there's a couple of speakers who might be talking about that uh today. So, you're going to see this really complicated diagram online. Um half the words probably no one gets fully what they mean. Um I think there's very few people who would actually know what every single word on that chart actually means. But, at a high level, uh there's three parts that we're working on. So, there's the consensus layer on the top, there's the data layer in the middle, and the execution layer at the bottom. So, the consensus layer is focusing on making sure that your uh Ethereum chain is alive and well. Uh this is everything to do with validators, it's to do with faster finality, it's to do with making sure that um you have the properties of a safe chain, as well as making sure that it survives post uh post-quantum. The data layer is everything to do with L2s. So, this is to do with um making blobs easier, making them post-quantum resistant, making them um faster to propagate around the network, cheaper, and so on. The third part is the execution layer, and this is the stuff that the app application developers would care, as well as people running the nodes themselves. So, this would include things like block level access lists to make uh transaction processing faster, um it which in turn would make it easier for you to run a node or increase the gas limit. This would include something like the post quantum transactions. So, this is going to keep your money secure after we have quantum computers. Um, it's including a potential tree change. So, the tree change would allow you to prove what data you have on chain without needing to run the full node. Um, there are things like proofs. So, ZK proofs. This would allow you to uh have just new types of nodes on the network and brings us on a path towards gigagas later in the year. So, if you look at this, it's more of a five-ish year road map. Timeline can always be contested, of course, but I'm going to focus on the left half. So, that's Glasser Dam as well as Segota. Um, Glasser Dam's the next fork on Ethereum. So, this is the one that we're going to be shipping, let's say, over the next few months. And Segota's already mostly scoped. Uh, it's the fork that comes after. The headliners have been high-level decided and we're still the the submissions open for EIPs if you want other changes to go into Segota right now. So, the first one that's going to impact people is gas limit increases. So, this happens via block level access list and I'm going to shortly talk about that after. But, we're targeting something in the two in the range of 200 to 300 million gas. And this is something that we've also tested last month at the interop event where a lot of client devs got together. Um, and this is based on a lot of optimizations that are being done to Ethereum itself. Um, however, there's another big change that's coming which is changing what the cost of a lot of operations on on Ethereum are. So, this means if you're doing contract calls, if you're trying to deploy stuff, etc., it might cost different from than what you're used to right now. And the reason we're doing this is cuz um a lot of the costs on the EVM don't fully represent the true cost they'd have to the node. And that uh affects us in weird ways, as well as it sets us up for better optimizations um to support proof uh ZK proof generation, um more accurate state pricing, and it just allow unlocks like faster sync algorithms, etc. once we have like a few other changes in. Um the fork that comes after this uh So, one part that I've missed here is uh block level access lists. So, block level access lists allows you when you uh have transactions in a block to for the node to parallelly fetch the information required to process this. And this enables the nodes to process stuff in parallel, and it gives you a huge speed up. Um block level access lists also has a nice side effect for indexers, etc. where you know all the states that the block is going to be touching, and this allows you to run a ton of optimizations on top. Um actually, one sec. I think the clicker might be Yeah, okay. I'm going to stop using the clicker. Uh I think there's an issue with it. It's just skipping a bunch of slides. Um so, the other headliner uh change that's coming in Amsterdam is EPBS. Um so, that's in shrine proposal builder separation, and this gets rid of one of the entities on the network that is largely relays. Uh instead, builders can directly submit bids to validators. The other thing that EPBS does is um it adds a layer of asynchrony to when a block is proposed and when it has to actually propagate through the network. So, this allows you to have a way longer execution time on the network. So, today you have roughly, let's say, 4 seconds, and there's a lot of issues with uh why those 4 seconds aren't fully given to the node process stuff. Um and with EPBS, we get rid of a lot of those issues. So, a combination of EPBS and block level access lists is what leads to uh is what leads to the gas limit expansion I spoke of earlier. And there's another change that can come in the um in the next, let's say, months without necessarily having a fork, and this is optional proofs with um ZK. So, this is already proposed as an EIP, and this allows no this enables validators to run a node without having an execution layer attached. So, your consensus layer would essentially just use the ZK proof and then attest based on that. Uh if you were at uh Devcon last year, you might have seen that uh Justin Drake trans uh used one of his validators to only use ZK proofs. So, this is something that's gotten a lot more work over the last half a year. It's gotten a lot more security eyes, client devs getting involved, and so on. And um later this year, we don't strictly need a fork for this. It's you can soft roll out the feature. You would start seeing some nodes on the network using optional proofs. The fork that comes after, however, um is mostly defined on the headliner side, like I said earlier, and it's not defined on the smaller EIP side. So, the first one is fossil. Um fossil is forced inclusion list, and this is supposed to massively increase the censorship resistance of the chain. So, this allows you to define uh for validators to ensure that certain transactions are included in the chain. So, if you can imagine OFAC censorship, etc., occurring, um fossil would essentially pre-prevent that. And it's committee-based, so random validators would be chosen to create this inclu- inclusion list, and these transactions have to be included for the block to be valid. Um and this is kind of a larger stream of thought, so EPBS as well as fossil will give us a lot of properties or censorship resistance that we might otherwise lose if we directly go to the ZK world. Uh the second proposal that's included is a count abstraction, um currently being discussed on ACD quite actively. It's frame transactions, and this is a way of bringing account abstraction into the protocol itself. Um the major con that's being discussed is that it needs some amount of dev adoption for it to actually be useful. Um and mempool logic is is proven to be significantly harder than um earlier anticipated, but both of these things are having active work being done, and keep in touch with ACD to allow for devs to figure out um uh how this looks in the future. The thing that it enables is uh native gas sponsorships, batch transactions, key rotation, quantum-resistant signatures, and so on. So, this is kind of a big play, and it's going to, along with gas re-pricing, fundamentally change how you interact with the chain. So, there's a lot of dev work over the next, let's say, year that people would have to upgrade with Ethereum in order to keep things safe and working well. So, all in all, um the road ahead has a lot of scalability built in. Um so, there's support for thousands, millions of transactions over an L1 and L2 once the entire um straw map has been shipped. There's a fundamental fixes in um for fixes being added for a post-quantum future. Uh it's supposed to make the chain way more accessible if we have tree migration as well as ZK proofs. Uh it makes it a lot more censorship resistant with EPBS, fossil, and other type of includer roles that haven't been that I didn't touch too much in today. Um it changes UX, so you're going to have account abstraction, native rollups, potential shielded transfers, etc. for better privacy UX. And all of this is very ambitious roadmap, so we do need a lot of community buy-in for us to actually get there. Um you might notice that small parts might be changing here or there over the next months. Um and I think Guillaume has a talk later today where he's also proposing a more major change to how things would work. Um yeah, please keep involved and keep in touch with all core devs to uh know what's going on there. Um you might have seen that there's still like a lot of open questions even if you've dug deeper into the straw map. What is the future of state for example? Um how many blobs do we actually need? How how's the market over there looking? Who pays for ZK provers? Um if we do have multiple types of um entities on the network, are attesters, includers, proposal separation, is that the right one? Um how is the EVM actually evolving? Do we want to do risk five? Do we want to revive EOF? There's plenty of questions. Um I'm mostly on the testing side, however, so I focus on the next let's say fork or two. Um but there's probably some researchers amongst us as well. Um so please talk to them, share your opinion, share your thoughts, share your feels. What's the straw map changing for you? And the earlier you give feedback on it, the more we can um modify it. Um that's it from me. Thank you. >> [applause]