What Is in the Glamsterdam Upgrade?

Transcript

Hello. Actually, I think diving in like this works well. As you've already been introduced, thank you for the introduction. Thank you for having me for this session. I'm a researcher at Four Pillars, a Korean research firm, and also work as a validator engineer on our validator team.

My name is Hudson Jang. On Twitter, I go by "Izagas." Today I'll be introducing the very next upcoming upgrade, Glamsterdam. It can get technical, and some of you probably know this far better than I do, so just listen like it's ASMR. It's the first session, and I really appreciate such a full room. So, the upgrade right before Glamsterdam was Fusaka, which went live on December 3, 2025.

December 3 was a special day for me as well, because my daughter was born on December 2. So I was at the hospital with the baby and my wife, before joining Four Pillars, I was at a company running many Ethereum validators, working as the lead of its validator team. I was holding the baby while monitoring everything nonstop, and I got a real earful for it. A fond memory. But that's a digression. You could say Fusaka was an upgrade for L2s.

Its most important proposal, PeerDAS, laid the groundwork for L2s to secure space for posting data to Ethereum L1 through sharding. Glamsterdam, on the other hand, includes 18 proposals that lay the foundation for scaling Ethereum L1. The name combines Gloas, the name of a star, which is the consensus layer upgrade name, and Amsterdam, where Devconnect was held. Execution layer upgrades are named after such cities, and the two together make Glamsterdam.

The screen is smaller than I expected, so you may not see this well, which is probably a good thing. Before getting into Glamsterdam, I'd like to walk through the big picture. In February, Ethereum Foundation researchers published a roadmap called the "strawmap." In the past, the Ethereum roadmap was just a static page you'd find on the Ethereum website. Unlike that, the term "strawmap" itself combines "strawman" and "roadmap."

So there's a public roadmap, and it has five North Stars. Through 2029, over the short to mid term, it drives toward these five North Stars, and it lays out in concrete terms which fork will implement each intermediate goal, and how. That's what this roadmap is. So unlike before, anyone can see it, and as the name "strawmap" suggests, anyone can attack it, and if you don't like something, you can point it out.

It's open in every sense. Going through the five North Stars one by one, the first is Fast L1: make Ethereum's Layer 1 fast. Ethereum's slot time today is 12 seconds. A block is produced every 12 seconds, and the idea is to cut that gradually to 6, then 4, then 2 seconds. And to cut Ethereum's finality time from about 16 minutes today down to seconds. That's Fast L1. Gigagas L1 means raising the throughput of each Ethereum block to the gigagas level. Teragas L2 means expanding the data space for L2s on Ethereum to the teragas level.

Post-quantum means making Ethereum a quantum-resistant network so it can survive sustainably. Lastly, Private L1 means making Ethereum L1 itself a chain that supports private transactions. That's the gist. That's the strawmap. As I said, anyone can attack the strawmap, and since Ethereum is ultimately technology, it can change whenever the technical landscape changes.

I think that's both Ethereum's greatest strength and its weakness. In that context, the strawmap itself can change at any time. But beyond all the things about Ethereum that can change, the charter defining which values must never change is CROPS. CROPS stands for censorship resistance, that's the C, open source, privacy, and security. Whatever happens technically — say quantum resistance is one of the North Stars, but suppose some Google engineer suddenly says quantum is basically not feasible. That could happen.

Then the North Stars can change. But the values in CROPS are what the Foundation puts forward as values that should never change. So far I've covered the big picture over the short to mid term. Earlier I said Glamsterdam is about scaling L1. Now, what you've mostly heard is that Ethereum scales in an L2-centric way.

So some of you may wonder why it's suddenly talking about scaling L1. But in fact, Ethereum has been steadily scaling L1 all along. The per-block gas limit comes up a lot in my talk today, so let me explain it first. Think of it as the throughput a single Ethereum block can process. When the per-block gas limit goes up, a single block can do more work. And last year alone, it doubled.

It went from 30M to 60M, so effectively Ethereum scaled 2x over the course of last year. But while Ethereum has been steadily scaling L1 like this, it has hit a wall of sorts. There are two parts to that wall. As blocks get bigger, it takes longer for them to reach nodes and validators spread across the world. So we've reached a point where it's hard to grow block size under the current architecture.

And while Ethereum is even talking about cutting block time to 2 seconds, it simply can't make blocks any bigger. The other issue is that today, to execute a block, Ethereum has to run every transaction in it one by one, and with bigger blocks under this design, that takes much longer. We went from 30M to 60M, doubling in a year, and the plan is to reach 200M and go even higher over the long term, but structurally, that had become difficult.

So rather than seeing this as Ethereum finally pursuing scalability, it's better to understand it as structural improvements to enable further scaling. Honestly, even once Glamsterdam ships, you won't feel any big change right away. Nothing shrinks dramatically, and the gas limit doesn't jump right away, so think of it as a step toward building that foundation. As for Glamsterdam: Fusaka went live on mainnet on December 3, and a test network called "Platoberge" was set up for Glamsterdam, and the test failed.

It didn't go well. After that, devnets 8 and 9 didn't go well either, but fortunately devnet 10 passed, so probably on October 6, October 6, it'll first go live on the Sepolia public testnet. If Sepolia goes well, there's Hoodi, a testnet for testing infrastructure, and if that goes well too, they're targeting early December this year for mainnet, as I understand it. The reason this has been hard is that the core of Glamsterdam is ePBS, and while I don't know the exact details,

it's said to be the biggest change to Ethereum since the Merge. It changes how Ethereum reaches consensus and produces blocks, so it's a very sensitive and difficult undertaking. On Platoberge, the Ethereum client with the largest share ran into. So they're proceeding more carefully. Glamsterdam was originally planned for the first half, and I think that's why it slipped this far.

So what's in Glamsterdam? A total of 18 proposals will be included. I've grouped them into four categories of my own. One is consensus, one is execution, and another is gas cost adjustments, repricing gas for execution, and one on developer experience. Those are the four. I can't cover them all, so I'll briefly go over the two headliners and two of the gas repricing changes.

Some of these slides look hard, but they may not be. I'm not sure what background you all have, so I'll just go through what I've prepared, and take from it what you can. To explain ePBS, you need to know PBS, and explaining PBS takes a lot. So I wondered how to explain it, and ended up not explaining it. Anyway, Ethereum produces blocks. Building a block means collecting transactions, ordering them, and bundling them, but in practice, that doesn't happen inside Ethereum.

Most blocks are built outside Ethereum by so-called block builders, in a kind of outsourcing arrangement where validators have block builders build blocks for them. Validators just propose those blocks, so proposers and builders are separated. That's the setup. And block building is highly capital-intensive, and competitiveness varies hugely depending on whose private order flow you have, so in practice, about four or five block builders are producing over 95% of all Ethereum blocks today.

ePBS matters here because almost the entire process of building Ethereum blocks happens outside the protocol, so things like censorship that occur along the way are very hard for Ethereum to handle internally. Proposers and builders are already separated, so the idea is to bring all of this into the protocol. That's ePBS, which is going into Glamsterdam. Until now, builders have worked through relays, and a relay is another external intermediary.

The idea is to bring that exchange between builders and proposers into Ethereum. To bring this external process into the protocol, creating new committees and various mechanisms is what ePBS covers. To give the overall picture: until now, when transactions are sent from outside, external block builders build blocks and bid to the block proposer, who picks the highest bid. ePBS takes that same process and brings it inside the protocol. Since that's how it works anyway,

I thought about how to explain it and came up with a shipping-label analogy. You used to carry every package around asking, "Is this the right one? Is this the right package?" Whether it was a pencil, a case of water, or a car, you carried it all around, and validators voted on it. So the heavier the package, the bigger the burden. But now, as block production shifts to ePBS, you only carry the shipping label at first.

Block builders don't reveal up front what they'll put in the block, since revealing it early means it can be stolen. So they keep it sealed, attach a bid, and send only the label first. Then the validator, the proposer, picks one, signs it, and broadcasts just that label, everyone votes on it, and the builder later, with much more time, reveals the full block. So the block size Ethereum had to carry around to vote and reach consensus now has a lot more headroom.

The label stays around 70KB no matter how big the block gets, so this too is a mechanism that gives Ethereum room to keep growing block size going forward. So ePBS comes down to two things. Bring PBS into the protocol for things like censorship resistance. And in doing so, create the conditions to grow block size further. That's how to understand it. Next, on the execution layer side, let me explain BAL, block-level access lists.

Right now, a block holds 100 or 200 transactions, and Ethereum runs them in order, one at a time. Parallel execution isn't possible because if the 1st and the 100th transactions touch the same state, you could get double-spends or tangled state, so running them one by one was very inefficient. And what an Ethereum transaction does isn't all that heavy. Each operation is priced in gas, so the computation itself isn't hard.

The real burden comes from disk I/O for data access, so the question is whether that can be made more efficient. After executing a block, Ethereum finally computes the root of the resulting state from those transactions, and that takes longer than you'd think. And since that can only happen after all transactions are executed, being able to do it in parallel would help. Also, when a new node syncs, it has to execute and verify every transaction one by one, which takes a very long time. To solve all of this, a new mechanism

is being introduced: each Ethereum block attaches a map of the transactions inside it. With the map showing which state each transaction touches, the executor knows that transactions not touching the same state can run at the same time. By attaching a map that enables parallel execution, the state root can be computed separately, and Ethereum transactions can be executed in parallel, substantially cutting execution time.

That's BAL. There have been plenty of parallel EVM chains. Ethereum will be able to do that too. So with ePBS, even as blocks grow, Ethereum gains a lot more time to propagate them, and with BAL, it can cut execution time itself. Admittedly, BAL is more of a stepping stone, since in the long run Ethereum will move to ZK-based verification, but as an intermediate step, it'll bring a lot of change.

The result is that Ethereum can handle much bigger blocks on today's hardware. This is one reason I like Ethereum. Ultimately, to grow block size, you could just raise hardware requirements. But higher hardware requirements mean less decentralization. It's not that I'm dogmatic about that, but Ethereum holds certain values and keeps developing without compromising them, and I think that's great. Huh, that's odd.

Anyway, finally: so far I've covered the two headliners, ePBS and BAL. Next is gas repricing. Exactly how much gas goes down where probably isn't that interesting to you. It might matter if you're a contract developer, so I'll only explain why it's being included now. This is also about blocks getting bigger. Right now, every operation in an Ethereum transaction, like is priced in gas, but those prices aren't ideal. Some easy operations are overpriced, while some complex, resource-heavy operations are

surprisingly cheap. When blocks aren't that big, these add up to little impact. But if we make blocks 100 times, 100 times bigger, the worst-case block can get really bad. It could become an attack vector. An attacker could build transactions out of underpriced operations, fill a block with them, and cause real problems. Since we want to grow blocks a lot, let's fix gas pricing early first.

About eight gas repricing proposals are included. This likely won't affect regular users much, but it may matter for contract and tooling developers. Gas costs are being adjusted item by item, so contracts and tools that hard-code them could completely break after the Glamsterdam fork.

After Glamsterdam goes live on the Sepolia testnet on October 6, there will be tools you can use to check this right away, so if you lead a dev team, it'd be worth checking. There are also several EIPs for developer experience. For example, raising the contract initcode size limit, or the deterministic factory. Today, contract addresses can't be determined deterministically, so the same contract deployed on Base, on Robinhood, or on Ethereum mainnet can end up with different addresses.

This makes them deterministic so you can use the same address. You'll see a few EIPs like that for developer experience. Then there are things originally slated for Glamsterdam that didn't make it, most notably FOCIL. As I mentioned, ePBS brings block building that happens outside into the protocol, but it doesn't solve the current concentration among block builders.

The whole point of bringing it inside is to deal with it at the protocol level, but today four or five block builders produce the blocks, and if the SEC sanctions them and says "don't include Tornado Cash transactions," things get difficult. Moving it into the protocol requires an extra mechanism to prevent censorship, and that mechanism is FOCIL. Ideally it should have shipped together with Glamsterdam to work in tandem, but it got pushed back.

It slipped to the next upgrade, Hegota. Next, cutting Ethereum's slot time in half, from 12 seconds to 6, was also discussed, but it was postponed to stabilize ePBS first. So after Glamsterdam, a fork called Hegota is expected sometime next year. It's very likely to slip, but development on Glamsterdam and Hegota is running in parallel, so I hope it goes well.

As for why frame transactions are going into Hegota, this is about bringing account abstraction to the Ethereum mainnet protocol level, but honestly, I think the real reason it rose so quickly to become Hegota's headliner is quantum resistance. Frame transactions are what let Ethereum change its cryptographic, transaction-signing algorithm, making it easy to move to quantum-resistant ones. The quantum threat is emerging faster than expected, so I think they're fast-tracking frame transactions to get that in.

So these were originally discussed for Glamsterdam and moved to Hegota. If it had included all of them, I think Glamsterdam would have run into far bigger problems. I've covered a lot, and I'm not sure how much stuck, but just remember three things. Glamsterdam will introduce ePBS and BAL, block-level access lists. Both are structural mechanisms that allow L1's gas limit to be raised further.

So nothing will change immediately when they ship. They make that possible structurally. Also, the gas schedule is changing, so if you're a builder, it's worth checking. And Glamsterdam is scheduled for early December this year. It'll go well, right? I hope so. Usually when these slip, the price drops. It can't drop. That part isn't a big deal, so I'll wrap up here.

While preparing, not knowing who'd be here, I wondered how to explain this and how far to go into detail. Thank you for sitting and listening. I'm Hudson Jang. I'm on the panel in the next session, so to leave a little time, I'll take one question, and please send the rest to me by DM. That's why I skipped as much as I could. Thank you.

Thank you. Financial firms often won't let us use Ethereum's public chain. Once Glamsterdam ships, could it address those financial firms' concerns? Actually, compared with before, Ethereum mainnet has already become much smoother. Even now, Ethereum is often cheaper on average than Solana when Solana is congested.

It's already improved to the point where it's usable, and with Glamsterdam bringing these structural improvements, and in the long run as Ethereum moves to ZK, block size can grow much more, and Ethereum's gas costs could get even cheaper. But it depends on the purpose. Personally, rather than saying Ethereum is better or Solana is better, it's about which chain to choose for your use case. Even with Glamsterdam and a move to ZK, Ethereum can't be used for things like high-frequency trading.

Still, there will be plenty of use cases. We won't be back in a period where a single transaction costs $200–300 like before. Thank you for listening. You'll see me about two more times today, so if you have any questions, reach out on Twitter or by DM. Thank you very much.