# Ethereum’s Evolution: Fusaka, Glamsterdam, and Beyond |  Preston Van Loon - Offchain Labs Prysm

- Channel: [Ethereum Denver](https://streameth.org/ethereum-denver)
- Date: 2026-03-09
- Duration: 13:54
- Topics: ETHDenver, Crypto, Web3, Blockchain, Event, Conference, ETHDenver 2025, ETHDenver 2024, Bitcoin, Ethereum
- Watch: https://streameth.org/watch/yt-GgKveVMLnoo
- YouTube: https://www.youtube.com/watch?v=GgKveVMLnoo

## Description

🚀 Get Ready for ETHDenver 2026! 🚀

We're already hard at work preparing for next year's biggest Web3 event!

Keep your eyes peeled for more info on ETHDenver 2026—it’s going to be epic! 🌟

## Transcript

[music] All right, everybody. Moving right along. We're going to talk about Ethereum's evolution. Shun shun shun with Preston Van Lun, >> take it away. >> All right. Thank you. Uh GM, you know it's GM anytime, day or night, whether or not it's morning. So I see GM all day and night. I want to talk about Ethereum's evolution. So let's get started. There's a narrative you've probably heard before. Ethereum is too slow to ship. I [snorts] know you've heard it. I've heard it. You've heard it many times. People would say, "When merge, can't the devs do something? Other chains are moving fast. Why is Ethereum moving so slow?" I'm here to tell you that narrative is dead. I work on the Prism consensus client. It's one of the key components of the Ethereum beacon chain. And I was in the trenches for the most recent updates for Peekro Fusaka. From what I saw on the inside was not this slowmoving bureaucracy that people have claimed for Ethereum for many years. It was actually a high velocity and wellexecuted machine delivering some of the biggest upgrades we've seen ever in Ethereum's history. What we shipped in 2025 were three major updates in one year. First being Pectra in May of 2025. This introduced native account abstraction, an increase to the validator max effective balance and allowing for consolidations and 10 more EIPs. In May, this was the biggest upgrade in terms of EIPs that Ethereum had ever seen. But then just 7 months later, we shipped Fusaka, even bigger upgrade in terms of EIPs. This one had 13 with an innovation called Pieras, which is really, really exciting. But just 6 days later, we upgraded again with a BPO1 fork and BPO2 followed just shortly after that, increasing Ethereum's blob capacity. This is a testament to Ethereum shipping. This is a collaboration between five or six consensus clients, five execution clients, many many researchers, over a hundred people involved Ethereum's core development, and they're all shipping in coordination at the same time. So it's really fascinating. Let's take a look at the headliner for Fusanka. This is Purdas. Pias is a very awesome scaling solution. Prior to Purdas, we had PectTra. And with Pekra, you had to as a node operator or validator, you had to download every blob that came with a block. This was targeting six blobs per block. Everyone had to download it. And that's really a scaling bottleneck. If you want to increase that, you're asking node operators to proportionally increase their bandwidth usage for blobs. Now with Fusaka, we have blobs that are eraser coded and asking validators to only custody a portion of that. You only need to custody 1/8 of the the blobs. And with [snorts] any 50% of the blobs, you can reconstruct the whole thing. So with this spread out over the network, it makes sure that data is available and that there's less of a burden on solo stakers. This is giving us an immediate almost 90% network bandwidth reduction in blob usage. Looking at the numbers, so for Pectra, we t we had a target of six and a max of nine blobs with a gas limit of 36 million. We consider this the baseline for blob usage that was at 768 kilobytes per block. Now in between Pectra and Fusaka, we had an out-of-bound upgrade which was the gas limit was increased. This was an onchain governance where validators simply voted on what they thought the block limit should be went from 36 to 45 million. And then later in the year we go to Fusaka which didn't change the blob target or maximum but then again increase the the gas limit. And then we got that in in large decrease in bandwidth where each block with a target of six blobs is now only 96 kilobytes of blob data that a validator had to store. And then again with BPO1 the blob parameter only fork we increased the target to 10 the max to 15 BP2 which happened just a month later we went to 14 and 21 which is double of what we had in Pekra but still 71% less bandwidth usage on blobs for solo stakers than it was in Perra. What's coming next in Glamsterdam? Well, there's three really key things and one that's uh kind of still active research. So, the first one being EPBS, enshrined proposer builder separation. The way block production is done today is a lot of people are outsourcing their their opportunity to build a block through MEV boost to these uh very sophisticated builders. Uh that's the majority of the network. Now the problem with that is that you have to trust a relay and you have there's a lot of trust there that that the builder will actually put forward the block that they had bid on. EPBS introduces a in protocol mechanism so there's much less trust and it's a very clean implementation of the same idea. The next thing we have is block level access list and this is a cool innovation where each block will come with a list that says where in the state it was reading or writing uh data. What that means is you can process blocks in parallel. Today you have to process blocks sequentially. If you want to process block 10 you have to first process nine and eight and so on. Well, now if you have a collection of blocks and you say, "Oh, none of them are conflicting with state access information, you can process all eight of them in parallel. Maybe you have eight cores. That makes Ethereum more efficient and faster to process blocks. The third thing is gas repricing. Now, this is a good one because there's been benchmarks through this EIP that showed some op codes were overpriced, some were underpriced. Now we're going to update the fees which you pay for each op code to reflect reality that makes Ethereum more secure and more efficient. Now there's one thing I want to talk about that uh Vitalic had mention mentioned recently. He said in this tweet uh back a couple weeks ago that the original vision of L2s and their role in Ethereum no longer makes sense. And this is just part of the tweet. It was a very long tweet. Um, it got a lot of headlines and a lot of people, I think, took the wrong takeaway from this. So, let me tell you what it means from someone on the inside. Ethereum is scaling faster than expected. Fees are lower than ever. I never thought I would be paying gas fees less than one guay on mainet. Uh, but here we are. Their blobs are bountiful. They're we have plenty. We're scaling blobs faster than expected. And even L2 fees are really, really low. So the idea that we need general purpose L2s, that is L2s that are simply the same EVM we have on the L1, just copy and paste it a bunch of times and all they do is go faster, that's not the vision anymore. These L2s will thrive with specialization. Some of them will target things like privacy, gaming specifics in DeFi, extensions of the EVM, but if they're simply a clone copy of the L1, they're not part of the road map where we initially envision this kind of like sharded paradigm through L2s. Now looking beyond the horizon beyond glamsterdam there are three really cool things in active development and research that I want to highlight. First one being fossil so having protocol level censorship resistance shorter slot times meaning you will have faster transaction confirmation times and a better UX for end users and faster finality where the L1 is the settlement layer and it will be settling faster. Let's dive into each of these. So Fossil stands for for choice in enforced inclusion list. [snorts] And the problem it aims to solve is that block builders have a choice. They get to decide what transactions get included in the block. They may have some they prefer or some they don't prefer. Maybe it's for an MV advantage. Maybe it's for regulatory pressure. But in any case, they're able to censor transactions as they wish and there's nothing anyone can do about it. Fossil changes the power dynamic here. Now instead of saying um block builders can choose all the transactions in a block, there's a random committee that selects based on their local horistics some transactions that they believe must be included in the next block. It's not all of the transactions in the next block. Builders still have a lot of freedom there, but there's a subset where they must include them. So the block proposer will take this short list maybe eight or so transactions and put it at the end of the block and they get um executed with the block. Now this is enforced through fork choice. What that means is validators that see this block will not attest to it unless it has an inclusion list appended at the bottom. Now if they see one without the list, they'll consider that block invalid and they'll just sort of ignore it. They won't propagate it. They won't uh vote on it. And this is still active research. So there's some parameters still being decided, you know, trying to make sure that it's making sense, but the the direction is clear. Ethereum is going to be including censorship resistance at the protocol level. The next really exciting one is shorter slot times. So with Hegata, the fork after uh Glamsterdam, we're considering whether or not we can include shorter slot times or quick slots. And that's not to say we jump all the way to sixcond slots or even faster, but building the rails in which we can do that because this changes a lot of areas of the application, it's it sounds really simple like oh let's just go faster. But you have to think about there's network propagation validated attestation duties where they have a limited amount of time to perform their duties and then there also the economics of things like when I first experimented with this I said I'll just change the 12 to a six and suddenly everybody was making twice as much uh issuance twice as much money which is not really the intention behind shorter slot times it's to go faster but keep all things equal. So it is a very complex thing but it's has a possibility to get there in the endgame incrementally. The third thing I wanted to talk about is faster finality. This is really important because Ethereum finalizes every two epochs every 13 minutes and there are applications that really depend on asking this question. Is my transaction permanent? And if the transaction has not been finalized that is an epoch that is finalized then the answer is no. there is a small chance that it could be reorged away and that transaction needs to be submitted again. Now if we have fast finality things like exchanges bridges or any application that wants that can be assured that transaction is final. First we'll start with instead of two epochs to have finality let's do it in one. Then we can say instead of having ep epochs that are 32 slots long let's shorten them to four slots. Now, if you couple this with uh 6second slot times, you're talking about finality in less than 30 seconds. That's a really cool endgame. Now, all this is built into the northstar in which we say the L1 is fast with finalization in seconds. How do we get there? Well, first we start with pure that's already shipped. That's given us a a scalable layer for data availability. Next we have Glamsterdam mostly including EPBS which is a clean implementation for proposer and builder separation and that makes things like Fossil more uh more impactful. Fossil comes in and says here's the censorship resistance mechanism which is which is very harmonious with EPBS with quicker slots faster slot times that makes faster finality even more impactful. Then we get to this end goal where we really do have fast transactions that are finalized in seconds. Now I want you to picture what life is like in two years. It's kind of hard to think because crypto moves so fast. This might be a reality in just two years. We have four or six second transaction confirmation times. That's the minimum amount of time it takes for your transaction to be included. We have finality measured in seconds and not minutes. We have a protocol level enforcement for censorship resistance. We have protections against postquantum cryptography. L2s compete on features, new innovations, not just going faster. All this is to say, while we still retain this virtue where you can use a consumer-grade laptop or hardware to run a full node at home, Ethereum is accessible and remains accessible for everybody into the future. Now, the takeaway I want you to have from this is the narrative I presented to you in the beginning, there's truly no evidence to support it. Ethereum is shipping fast. In just one year, there were three upgrades. And in the in the next 24 months, there are even more things that are coming and that'll be coming even faster. These are not just fantasy 5-year timelines. These are actual things with concrete proposals that are being developed right now. There are things in DevNet right now. There are people working as we speak on these implementations. If you're building on Ethereum today, you're building on the most actively developed blockchain in the world. And with that, I want to say thank you. I'm uh Preston Vanlon, Ethereum core developer. I work on the Prism team at Offchain Labs. If you want to get involved, the best way to stay in in tune with what's happening Ethereum is to help build it yourself. Come talk to me afterwards over here. Come look at the Prism repo or any of the consensus spec or execution spec repos. and we'd really love your contributions. Thank you. [music] >> [music]