# From strawmap to reality: how do we actually ship this roadmap? | Pari (March 2026)

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

## Description

Join us on Meetup to get up to date on our Berlin events: 
https://www.meetup.com/berlin-ethereu...
See you at the next one!

Apply to speak at our future meetups: https://forms.gle/txTvFB4E8E8KbEqX8

X (Twitter): @BerlinMeetup

## Transcript

Everyone, my name's Paritosh. I'm a part of the East Panda Ops team at the Ethereum Foundation. Most of what we do is testing as well as fork coordination. So, if you ever had questions about how to ship a fork on a decentralized network with like 10 to 12 different clients in multiple time zones, then I'm happy to help you and talk through that. Uh, it's a lot of pain. So, what is the straw map? Earlier this year, we realized that at the foundation itself, there was a bit of a disconnect in terms of what people are working towards. There were a lot of research streams. We had a bunch of teams. Everyone has good ideas. The problem is we kept running into the situation where we hadn't sequenced things the perfect way and we found out a bit too late. So, that often was historically the reasons why we had to pull out features. We hadn't prototyped them well enough beforehand. There were dependencies of other features that had to move in earlier and so on. So, we met up in January. It was meant to be a research meetup along with a few people and there was no plan to come up with a straw map or some sort of coherent strategy, but it sort of organically emerged. The idea was to surface issues early. We didn't want to be in the situation where something needed to be shipped in 2 years and we hadn't assigned anyone to work on that thing until 6 months before. We wanted to align teams so that we move in a similar direction. We can also allocate resources better in terms of X is more important than Y because of timeline reasons, which is why you need to do things a bit differently. There were also a bunch of open questions. On speaking to the community, to a bunch of people over the last year, um, it surfaced what everyone found was most important and we had to update the version of Vitalik's roadmap you might have seen from a few years ago with the merge, purge, and so on with a more holistic view of what what we actually are moving towards. There was also the question of lean chain that was announced a year year and a half ago. People are working on that. Where did that fit into the whole system? There were just a bunch of questions and we were trying to bring everything together. You can see the straw map.org website. There's it's maintained by the protocol architecture team at the EF. It's not 100% up to date, but it's a good direction of where things are going. This is an extremely hard to read document, but if you open open the straw map.org whenever you're free and you can slowly go through it. I'm mostly going to be talking about the first two portions here, but at a high level there's about three sections to it. The first one's the consensus layer. That's the beacon chain that we launched like 6 issue years ago. This decides what the what's canonical on the chain. The second one's the data layer. This is what processes blobs. This is what L2s are using and consuming and potentially in the future the L1 as well. The third one is the execution layer. So, if you're an app developer, if you're running nodes, if you're anyone in that stream of things, that's the layer you're most interacting with. And there's a lot coming for for basically all three of them. You might have noticed from Annika's presentation earlier, there's notably one big thing missing. Like where does privacy necessarily fit in here? Same with where does the access layer necessarily fit in? As a user, how are you accessing this whole thing? So, that's what I mean by this this is a living document. It's not that we we have this now and no matter what happens, this is what we ship. It's a it's a living document. We're going to be updating it with more information since we have a active privacy cluster and team at the EF. We also have a new effort with with the access layer headed by Frederick from the security team. So, you you can probably see a lot of changes in this direction in the future. I'm going to dig a bit Okay, maybe before I dig a bit deeper, what's what's the direction we're in general moving towards? A lot of this is adding some censorship resistance into the consensus layer, making it post-quantum secure, as well as making it easier to to have validators on the network as well as those validators playing an active role and different types of roles in the network, right? All of this is basically increasing the throughput of blobs as well as making them post-quantum secure. All of this is related to different approaches to scaling the L1. So, higher gas limits, native rollups, how are we thinking about state and so on. There's also a small point about shielded transactions, but that's that's probably going to be expanded a lot more on the privacy topic later on. And as you can imagine, we're quite solid in terms of the research phase here. Where it gets fuzzier over time as you move farther away. Just the nature of research, I guess. That's why there's some dependency trees so that we also understand what needs to be researched and shipped before something else. We try as actively as possible to reduce those dependency trees. We also Yeah, we'll probably be adding more things in the future. Right now, I'm going to talk about Glamsterdam. So, this is the next fork on Ethereum. This is something that's very very very actively being worked on. We don't have a live network with all of the Glamsterdam features and the reason is we split it into two halves. So, we're working on one live network with the consensus layer of the Glamsterdam features. Another one with the execution layer of the Glamsterdam features because devs are not fungible. And then you can deep dive into both of those things. You have testing teams deep diving into both of those things and eventually we join those two work streams into one coherent work stream that we ship. This is just allows us to move extremely fast with changes with reducing the number of people who need to be included in the change set. So, what are we actually shipping? The fork is mostly about efficiency, speed, and better utilization of resources. Um, the first one is enshrined proposal builder separation. So, this gets rid of the MEV boost and builder workflow that exists today. So, if you want to make use of make use of the builders in Ethereum, you kind of have this privilege you delegate some amount of trust to the relays. Um, proposal builder separation gets rid of this. The builders directly interact with the validators over the peer-to-peer network. They can support They can propose bids. These bids can be chosen or rejected. This means that you as a person staying at home can now be a builder if you want to. In the past or how it works today, you would need to first figure out a way to enter a relationship with the relay. They would need to list you. Then you get exposed to the validator. You would still need to produce a good block. It doesn't change anything that happens beyond the builder. So, doesn't change the searcher infrastructure at all. It mainly focuses on getting rid of the relay trust assumption. There's a bunch of other things EPBS also does. It decouples execution from consensus. So, you no long So, today in Ethereum, if a block is missed, then for example, the execution layer block doesn't exist, then the consensus layer block can't be validated and it's also missed, which is kind of weird if you think about it. Those are handled by two separate entities on on the protocol level. Um, there's no reason that even though the consensus layer block could have been present, which is useful for processing blobs, which is useful for a bunch of other reasons, just because the execution layer wasn't available, we can't use it. So, this splits the two things and you now have the you have a different deadline for when the consensus layer block is supposed to be produced as well as it includes a reference to the execution layer block. And this allows us to have bigger execution layer blocks that can propagate through the network at a longer duration because they only have to be present at a later point in the block's life cycle. I don't have an exact picture. Just speaking it out, it's a very big change. I probably should have added a picture. I can do that the next time. Um, the second big feature that's coming in the in in Glamsterdam is block level access lists. And what this does is introduces parallel execution into the EVM. So, if you have a transaction, so maybe one step before that. So, we had in Fusaka this concept of a transaction gas cap limit. So, now a transaction can only be 16 million gas at a at a max. However, the gas limit's way higher, which means you could have multiple transactions, but you still process them sequentially today. And the idea with blocks level block level access lists is you no longer need to do this. You precalculate if there's any conflicts. If there isn't, you can do them you can parallelly execute them. Um, and yeah, it's it uses the resources more effectively essentially. There's also some side effects. The side effects is the sync algorithm we use right now gets a bit simpler. You have all the state diffs essentially visible in the block. And the harder part of syncing today is there's a concept called state heal. So, once you once you sync everything, you do a bunch of healing processes. And that gets a bit easier. There's a very alpha proposal. I have to admit I haven't read the alpha proposal yet, but it's it's getting it's getting there. And it's something that we can ship after the focus lab. It's not something we have to wait to ship with the fork. And on the same lines of getting better at efficiency, there's also a gas limit change as well as gas repricing. And I think the repricing might be the more interesting one for a lot of people. If you have contracts that assume that gas costs a certain amount, then please look into this. We're changing how much a lot of opcodes on the EVM are supposed to cost. This is through exhaustive benchmarking. This is through exhaustive analysis of trying to find what the ZK prover bottlenecks are through analysis of trying to find what our like failure modes are. You can go to gigagas today. The problem with gigagas on Ethereum is that state is priced way too low, which means you're making the situation worse over time. So state is clearly something that's going to be priced way higher in the future. There's a lot of benchmarking that goes into this effort. We also have this canary network that's based off of Ethereum mainnet, but it has roughly 3x the state size. So you're already able to envision a few years in the future how mainnet's going to look. We've taken the worst case contracts, worst case depths, and then we're applying benchmarks on this case, and then we're pricing the opcodes. So there's like a bunch of layers of thought being put into this. And then the other one is gas limit expansion. So today I think we're at 60 million gas along with EPBS and block level access list, we can safely target about 2 to 300 million gas. However, that comes in line with opcode pricing. So if you 1000x the gas limit and 1000x the opcode price, you didn't actually scale anything. So this is of course like a holistic journey together. Things will get cheaper, don't worry about that. We're not just making everything more expensive and scaling. But yeah, in itself this is a whole work stream that a bunch of research has gone through over the past years. It isn't targeting multi-dimensional gas yet, but there's a plan for a work stream in the future that could potentially target that as well. The fork that comes after Glams down. So we're done with the first layer, and then now the second layer. This is of course a lot more alpha as a discussion because we are not yet done with what goes into a fork. Um, so the Ethereum Foundation can only make proposals about what goes into a fork. It's all core devs, which is a combination of community, client devs, etc. That actually decides what the final version of what goes in the fork is. It happens via rough consensus. And this has a process and a life cycle. We're not long enough in the life cycle that I can guarantee that these are what's going in, but there's at least high conviction that effort is being spent by client teams, etc. to investigate these work streams. The first one is shorter slots. If you look at Ethereum slots as they are today, um, they don't really make much sense. We have a deadline, so the slot is 12 seconds. We have three times four second sub slots under them. The first sub slot is for block to be proposed. Next one's for it to be attested. Third one's for it to be aggregated. The thing is aggregation is super easy. So the last bit is kind of wasted slack. The second bit at a station propagation also kind of good. And the first bit, block propagation, apparently it's too long, which is why you have timing games. So the first like two seconds of a slot basically nothing happens, and then everyone proposes and suddenly there's a few seconds where everything needs to happen really quickly, and then you're wasting the last bit as well. So EPBS makes this fundamentally better, but there's still going to be lax at the end of EPBS, and we don't know what this lax is going to be unless we ship it, we analyze it, we use this tool called Zatu, which is a distributed bunch of nodes all over the network. We have people running this tool called Contributor. If anyone wants to run it, you can run it at home yourself. That basically tells us some timing information about how your house perceives the Ethereum network, and then that goes into understanding, okay, how much lax do we actually have on this network such that everyone around the world is able to actually interact with it. Um, this So we're going to go for the quick wins early. So reduce the lax, EPBS. Potentially this already gets us to either 10 seconds or 8 seconds, we're not sure. Then there's some peer-to-peer changes, an example of which is EthP2P, which is consensus layer change. Um, it's still very alpha, so I'm not going to go too much into it, but the idea is that you make better use of broadcast, you make better understanding of your peers, you We have this failure mode, or not failure mode, it's also resiliency mode in Ethereum that all the attestations you see typically EPBS offers. It like makes the whole thing a bit better, and helps against proposal centralization. It gives in the end the end user more say in the network. Um, there's zero knowledge optional proofs. So there's a whole work stream in the Ethereum world about adding zero knowledge proofs. And these zero knowledge proofs um, took a while to get to real time. And now I think 90 something percent of them are generated in real time with about 16 GPUs and 10 kilowatt prover setups. This number is going down, which is nice, but also gas limit is going up, so maybe it nullifies. We don't want to go to a world where one day to the next we just start relying on these external entities. There's a lot of open questions here. Who's funding them? How are they supposed to work? Are there security bugs? Whatever. Which is why the first step we want to do is with EIP 025. You can optionally opt into the system. So there might be some subset of people, maybe they set up a provers prover amongst themselves, and so on. Um, they don't need to hold the EL state, so it's kind of clear why you and your friends can get together, especially with today's RAM prices as well as SSD prices. Maybe it makes sense. Um, and yeah, it allows us to basically soft roll the feature. We can try it out, see how the network reacts, see how many people adopt it, and then slowly increase our reliance on it as security finds more and more bugs. Yeah, so as you can see, a lot of this road ahead is in direction of scaling, it's in the direction of a post-quantum future, it's making the network more accessible. There's a whole thing with work of trees that we did in the past that we're not doing Merkel trees anymore, but there's an option to do binary trees. And ZK proofs imply that you're just going to have fundamentally different types of participants in the network. I think the Justin Drake meme is that you should be able to validate with like a smartwatch. And that's possible with some of these changes. It's more censorship resistant by EPBS fossil and a lot of other topics and then UX gets a lot better with the counter abstraction a plan for native roll ups. Potential fuel transactions and so on. Um. I've glossed over a ton of open questions and these are the best things to get involved in. The easiest one is like yeah, you can thousand next the gas limit, but who actually manages the state cuz like you can't use fossil if you can't generate the transaction. If you want to generate the transaction if you have to go to an RPC provider, did you actually add any censorship resistance? You just move the problem from one location to another one. I don't have any answers for any of these by the way. If you do your genius, but it's it's work streams. We have researchers thinking about these problems. We have people engaging on these problems and we'll find a solution. We also don't have an answer who serves it. I would love to continue running my ethereum node at home forever. I don't know if I can if it goes to a gig a gas. I potentially already contra I mean I can't run a lot of chain nodes at home. We don't want to make that the case. Maybe we need some sort of decentralized serving. Maybe we need some sort of shattered state. Maybe we need read replicas. No idea. Do we want some form of state expiry? What's the design space there? What's the trade off space there? Is the UX hit worth it? Not sure. Can nodes even perform if you keep increasing the gas limit? Where's the bottleneck there? We're just starting on our journey with optimizations. A lot of clients of course have spent years doing this already, but things like block level access lists open a whole new dimension of optimizations that are possible. But in the end databases have limits. We have to figure out what those limits are. Same with blobs. We don't know how many blobs we exactly need. What's the demand versus cost? We don't necessarily know what where on the trade off space we exactly want to land. You can do 10,000 blobs on ethereum today, but if you remove every staker on the network then what's the trade off there? Same with ZK provers. So who pays for the provers? Is it just going to be builders? Is it some sort of in protocol incentivization? Are RPC providers paying for it? Shared proving with friends. That's the one I kind of like. But yeah, let's let's see. And yeah, what what a tester proposal include a separation construct do we want? There's a bunch of things you can change in that design space. There's a bunch of trade offs of course in every design space. So you have to figure out where we want to land. Same with EVM. Do we want to do risk five? Is it even a good idea? Do we want to revive EOF? Can we get away with the EVM as it is today by solving some of the problems that people have complained for years. Not sure. There's a lot more. I'm not a researcher. I won't pretend to be one. I'm mostly doing testing. At best I have a decent view of ethereum in a plus one year time frame. After that it gets hazy even for me. So that's that's I think most of my presentation. Thank you for having me. I have a question. So from my perspective, how good are we on the path to gloucester now? What do you think maybe would be the biggest hurdles to overcome or test net smart and how? Yeah, so in gloucester now one of the things that played out surprisingly well was an early design decision to not do everything merged. So we did consensus layer testing different from execution layer testing. I'd say as it stands today the execution layer testing is significantly further ahead than the consensus layer testing purely cuz it doesn't change as much as deeply. Um. So there's a world in which we ship block level access list without EPBS and do EPBS after. There's a world in which we do both together. Either ways we're targeting summer this year which is maybe slightly longer than the six month proposed fork window, but not drastically longer. The idea is that by end of April we have a combined gloucester down devnet. So all features in one location and then it's about hardening and shipping. I'm new to ethereum, but I was always wondering about the post quantum thing and you mentioned it. So do you have any like insights like what's the challenge or the idea? I think the largest challenge is that post quantum doesn't already have a universally adopted standard. So it's a very active research field. There's a couple of types of signatures and a couple of cryptographic constructs that people like, but a lot of them haven't been fully proven or on their way of being formally proven. There's conjectures that could hold. There's some conjectures who would couldn't hold in the future. We it's just a bit too early to decide. There's one roll out path that I'm actually quite excited about which is we just ship multiple types at the same time. And then every transaction you do or sorry not transaction. This is for the validators. You just kind of do two or three of the top candidates for post quantum and then a year or two down the line we decide to cull a couple of them. There's a couple of approaches, but there's so much about blockchains that break with post quantum that it's not going to be one thing. Also there's kind of one feature of so today on ethereum we use BLS signatures and the cool thing about CL BLS signatures is that you can just arbitrarily aggregate them. So you can have like a million validators and the signature is super small. You lose this with a lot of post quantum stuff and then you have to deal with the realities of that. So there's just a ton of let's say implementation difficulties that are worth being figured out. Yeah. You mentioned the account abstraction in addition and could you please elaborate a bit more about this? What are the motivation behind that? Yeah, sure. A couple of things with account abstraction is today as ethereum works you need a private key. The private key needs to sign everything which is it's okay. The problem with private keys is that it's easy to lose them and you can't do things like have someone else pay for you pay for your stuff. That's sort of gas sponsorship approach. You might have faced this if you ever used a new chain for the first time. You can create an account a wallet whatever and then you realize that there might be like a USDC token on there that you you had, but you didn't have the native gas to pay for it. So there's a lot of these problems you can solve smartly with account abstraction. There's of course some amount of trade offs. It also makes the design space a bit harder, but it's it's a direction that ethereum in general wants to move to. There's also a way to ship post quantum security with account abstraction. So you can sort of do account migrations using account abstraction. So there's And I think that's probably the fundamental problem with account abstraction. Every year this topic comes up and there's a new use case for it. I think two years ago there was a lot of hyper on the account abstraction. I don't think we were talking about post quantum then at all, but now it's suddenly part of the use case which changes the design space again and so on and every few years this changes. However, we're getting better at it and trying to ship something. It's called frame transactions. Have a look. It's a relatively new proposal I think from February and it's actually one of the outcomes from the January meet up we had. This was actually in Berlin. Yeah. Thank you so much again. Thanks.