Shipping faster forks on Ethereum | Guillaume Ballet (Berlin Ethereum Day, June 2026)

Yeah, so over the course uh of the time I spent working on on Ethereum, I've seen many forks, and they're quite different, all of them, but they share one common at least two common problems. They are always delayed, and they're always painful. And so this uh this presentation this talk is about a reflection on how we could improve things. So let's begin with the plan. This is the straw map.

It's called the straw straw map the straw man road map. It has been published in January 26, so not so long ago, uh by the EF research team. And well, it's been presented by Perry earlier today. The the first remark is that clearly there's a lot of things on this. Um you can also see like you have the the link if you want to go read the little boxes.

Um there's there's a lot of very ambitious things on the on the far right of things. And on the on the left, which is like today, uh you have things that are a lot more uh conservative, a lot less ambitious. Um and uh yeah, like we have a five year five year timeline. I don't know if you know this, this is currently a bear market. So do we have five years?

Um maybe, hopefully. Um and then there's another problem, which is that if you look at the boxes on the on the right, uh some of them contain the word end game. Now, it sounds like there's a plan that's it's well understood, but then if that was the case, why don't we actually write what the plan is? So it's more like a hand wavy thing, uh meaning we are actually committing to do things we don't fully understand, and whatever we do today is in provision of this stuff that we're not sure we're going to ship eventually. Let's take a step back.

Not so long ago, less than less than 3 years ago and at the end of 2023, there was a plan like this. There was a roadmap published by Vitalik. Same thing. Lots of very detailed short-term things. A lot of fuzzy long-term things.

A lot of things. And less than 3 years later, this is, you know, time for some uh like looking back on what has been achieved. And you know, some things have been achieved. No no doubt about this. There's a lot of check boxes.

So, things have been done, especially in the surge section of things, which is uh yeah, which is about uh shipping like native Sorry, not native rollups, just uh rollup-centric rollups. Um so, core devs have been busy. There's no There's no question. They they have achieved things. Um but then you see there's also a lot of red crosses.

And those red crosses are either things that we decided not to do after all, or things we I mean, we also decided not to do after all, but we worked a lot on it before deciding this. So, it's a lot of wasted efforts. And then uh I have a little clock emoji to say, "Well, this thing uh is still technically on the roadmap today. It's still on the straw map. However, there's no date for it to be shipped, to even begin working on it.

Some of it is being worked on, but we we don't have a delivery date. So, potentially, it could end up being a red cross. Then there's the thinking emoji. Uh this one is I don't know what happened to this. Uh I haven't heard of it uh since uh since for the last 2 years.

Uh and everything else is currently being worked on and it will probably be shipped. So, there's not much of it left. Did we learn from this? Well, if you go to forecast, which Mario was talking about earlier today, um you can see the list of EIPs that have been proposed for the next fork, which is called Glams for them. There's 10 EIPs that are currently scheduled for inclusion, meaning we think uh they're going to be uh to be shipped.

We are working on them. We're testing them. Um so, they're the priority fuel. There's the stuff we actually try to ship. Then, there's the uh things considered for inclusion.

We we want to do it, uh but, you know, they're not a priority. So, it might land, it might not. So, this is the prime spot for working on something that uh will be thrown in the garbage. And then, you have uh so, those were 14 EIPs. Now, you have the further down, they're not displayed on the thing, but there's uh okay, there was one that was still proposed.

So, this one we haven't really thought about. We don't know where to put it. And then, there's the 32 declined for inclusion, meaning people have been proposing EIPs. We had to debate them. We had to to assess them.

We had to reject them. Mind you, the process is more of an art than a science. A lot of it is very arbitrary. A lot of A lot of it is feeling-based. And um some things um some things get uh dropped, sometimes very late in the process.

If you think of EOF, and uh and there's no accountability. Like, there's no learning from that process, um in my view, at least not enough. And uh one last point I wanted to make on this slide is that the testing is incompressible. No matter how hard an EIP is, testing it uh like, you have to test it and testing takes time. So, it's like we're DDOSing the the testers and that's that's a very bad thing.

So, somewhat provocatively, I suggest doing something doing less simply. What I called the minimum viable straw map. Actually, the name comes from Perry good good one. Um and the idea is like the the mindset is let's be pessimistic about this. What if the the whole community has only three years to ship something?

What can we ship in the next three years that will leave the chain better off? Uh you know, and keep going for the next 100 years when all the funds for for tweaking it have disappeared. And the effect of this is that there's a lot of less boxes. It's it's a lot less full. Um it's it's also focusing on what's concrete.

It's removing a lot of boxes both in the future especially in the future but also in what's what's coming like in the the next fork in the fork after. Um this is just my opinion. I I thought about it for like maybe half a day. I am not a client like you see all developer. I am not specialist of blobs.

Uh I am happy to discuss it but yeah, that's that's what I think we should do at least. Now, that's the I would say that's the global thing. There's something you can do at a more at a smaller scale. And that would be to do an approach that we're trying with an EIP that was proposed by someone from my team Han. Uh it's EIP 8188.

It tackles what it tries to tackle a big problem we've been trying to solve in Ethereum for like over 10 years now. It's called state expiry. The idea is that if you keep holding the state forever, your database is going to get fuller and fuller and it's going to get slower and slower and your performance is going to degrade. So, you have to somehow delete the data that no one needs. Now, there's been proposals that, you know, holistic proposals that try to tackle the whole problem in one go, but this uh this EIP has uh let's say more modest approach.

What we're going to do is every time a location in the state is being written, we're going to take a note at which block it was written. So, that means that every time you look at a location in the state, you know how old it is. And then, the clients can do whatever they want with that information. The users can do whatever they want with this information. Um we're not we're not uh we're not presc- uh prescribing what uh what needs to be done.

We are going to describe what's go- is going on. And then, well, the it has many advantages. One of them is that the the EIP itself is very easy to implement. We write things to the state. We know how to write things to to the Ethereum state.

So, what's another 4 bytes to stor- to store block number? Uh when this is done, people will start experimenting. Clients will start experimenting. I have described one idea that uh we are working on in my team currently. Uh Erigon has done some similar work.

The idea is instead of having 100% of the state in the database, thanks to this EIP, I know what is uh recent, what is uh what is old. So, I'm going to take the 80% of the state that no one ever uses, actually, move it to a flat file, just a regular file. It's never changing, so we don't need the DB feature. We just need to keep the data. And reading a file is a lot faster than reading a database, and for everything that is actively being used and read and written to, we still use the database, but the database is smaller, so it's a lot faster.

And then, and that's the beauty of it, people are going to experiment. We're going to see what works, what doesn't. Um and what works will be copied, and it will become the de facto standard. And only then we're going to go with a state expiry EIP. Might be next year, might be 10 years from now, doesn't really matter.

Um when this uh happens, the basically the good solution will have will filter itself. And then, uh when it's time to come up with an EIP, the testing will already have been done, or at least most of the testing will already have been done. The code will already have been written. Uh we will know what we're shipping. Um now, okay, that's cool, uh but what what about, you know, things like the merge or uh or even EIP-4844?

Um how do we ship that? Uh I would argue, so following the like the EIP-8188 method can can still apply. You can decide to only ship tiny bits of uh of it in the protocol, and leave let people uh organize around it and decide what is the best the best method. So, the method still works. The other uh I mean, the next idea is to say we're not going to do most of it.

Like, we have to accept we have to choose. Um and we have to choose because we have to understand, and I'm not dunking on any of the EIPs that were listed that are listed here. They were useful in their time. Uh EIP-4844 definitely served its purpose. The repricing the gas repricings we did were useful, but the thing is, we're changing the gas again.

Uh EIP-4844 is not quantum secure, so we'll we will have to change it at some point. A lot of pre-compiles Whoops, what's going on here? A lot of the pre-compiles that were added are useless today. So, we added them and we found out we we were not needing them after all. Um I think with like this is a sign that we're shipping too fast and we're shipping things that are not really um cons- considered for the for the long run.

I don't know why this thing keeps changing by itself. Um but yeah, okay. The the idea is that maybe we should have less forks and and have them ship faster. Okay. So, the other thing, I have this nice picture of Linus Torvalds.

He keeps saying, "My job is to say no." And and I think we could do it more tactfully, especially since doing it this way is actually not the best way to do it. If anybody here has looked at at the Linux kernel, there's a lot of useless stuff in there. Um so, it's not it's not working. Sorry, I don't know why this thing is keeps changing.

Is it Is it the clicker that's trying to Okay. I don't know. So, I think it's a good way of seeing things. The the methodology is is not the best, but uh but yeah, it's still I think shipping less is ultimately a good idea. Doesn't mean you should not ship on Ethereum, it's just you should not ship in the protocol.

Like you shouldn't ship everything in the kernel. Um yeah, then this is maybe the most the most How do you call that? Uh No, jeez. Uh this is not the most uh Yeah, okay. Let's Let's not qualify it.

I'm just saying, sometimes we have Yeah, I don't know why it's happening like this. Uh Sometimes we have some people who have a great idea and they say we could use it in a protocol to achieve this moonshot. Um but there's actually no user requirement for it. Um and so it's a big chunk of work and we realize no one was asking for this. So you know, things people want it's increasing the throughput of transactions.

That's that's useful. Enhancing privacy, that's something people want. But um the for example altering the state tree or forcing ZKVMs inside block production Well, you know, I'm not saying it's not a bad idea per se, but this is not something that people actually want. It's something it's a means to an end. So we should keep the the end in sight instead of the means.

And then yeah, okay. I'm going to progress cuz I have I'm running out of time. The last idea I could come up with actually use the L2s for what they were intended to when they designed the the L2 centric roadmap, the roll-up centric roadmap. It's using L2s to experiment things because shipping on L1 is actually a lot slower than shipping on L2. So maybe maybe do this first and I had this poorly thought out idea that we could and Jesus I had this poorly thought out idea that we could maybe create a like experimental L2 where you would ship all your EIPs and make the gas super super cheap to motivate people to to join.

Um you know, you pay no gas, you take the risk of losing everything cuz there was a bug in your EIP, but if you're if you're an instant trader, that that might might interesting. And then there's Holger who created this this effort that I just learned about like a few days ago, feel your protocol. Same kind of idea. So, have a look at it if if you have a moment. Will the you know, if we ship less forks, what will core devs do?

Well, they would still be doing something. There's a lot to fix in the clients themselves. The time that is spent shipping a fork is not spent actually working and improving the clients. So, we would have a lot more time to do this. And I'm finally at the last slide.

So, hopefully it's not going to go any further. But yeah, I'm just leaving these thoughts. We're building Ethereum for the next 100 years. So, focusing on the only focusing on shipping the next 6 months is uh might not be the the wisest thing to do. At least in a world where everybody speaks about accelerationism, maybe doing you know, taking a step back might be the the wiser thing to do.

And that's all for me. Thank you.

[applause]