Glamsterdam for App Developers: What Ethereum's Next Fork Changes for You

Transcript

[music] [music] Hello. Good evening. I know it's been a long day, a lot of technical talks, so I'll keep this fun. There'll be some memes. Um, but also uh one request. If you meet any app developers later on today, next week, please do talk about the contents of this talk. not necessarily for me but for their own sake. So um actually I I live in England and in England we do a lot of pub quizzes. That's that's our way of life.

And let's there is a trivia on why Ethereum's next hot fork is called Glamsterdam. And in England we care a lot about trivia because that's how you win pub quizzes and that's how you get free pints of beer. Uh so the naming for glamsterdam comes from a star called glaus. So Ethereum can be thought of as the consensus layer and the execution layer. The consensus layer takes its name based on stars. So the word glaus. The execution layer uses names of past cities that devcon or dev connect has been in. In this case it's obviously Amsterdam which was the first ever dev connect. Maybe someday we'll have a hard

fork that uses the word Mumbai in it. That would be quite nice. But okay. Um before I talk about Glamdam, let's take a step back. Why why does Ethereum ship hard fork in the first place? Why not just oify and be completely immutable? Well, it is quite hard. So there's a good reason to oify. It's a bit like the International Space Station which gets upgraded in flight. There are very few use cases in the real world where you have a running system and you have to swap out its engine with zero downtime.

ISS is one of them. Ethereum is also one of them. Uh the main reason you do these things is first to keep scaling. As blockchains mature, as more and more companies use it, the requirements subtly change. Things that weren't problems before suddenly become problems. So we need to keep improving Ethereum without losing our values. Improving can be scaling. Improving can also be improving the UX. Um how do developers work? How do users work? Um a lot of you may have seen this. This is our strong map. There are loads of things here. Not all of this is relevant for the talk. In fact, most aren't. But when we think about hard folks at

Ethereum, we think about what are we working towards? And our goals are back to scaling and improving UX, but more specifically, how do we make the L1 much faster? That is making blocks final not from minutes but seconds. That is having much bigger blocks. That is enabling L2s like Mudit from Polygon just gave a beautiful talk. Enabling them to be cheaper, to be faster um and also eventually making Ethereum completely private.

um a little bit about what we have done so far in the recent history of hard folks. This is not a complete list of all of the hard folks in Ethereum land but in every hard fork we have successfully managed to improve one critical thing in the consensus layer, one critical thing in the app layer. And my personal sitch is I don't think this is talked about enough, right? Um, [snorts] merge gave app developers um, a direct path to knowing that the blocks will get finalized in a few minutes. Chappella gave everyone a new op code that made call data very cheap if you had zeros in them. Spoiler alert, almost all call data has a lot of zeros

in it. Denkun gives blobs for L2s, making L2s cheaper. It also gave transient storage. So if you write to a storage slot but don't actually use it, it doesn't count. Um, Pectra gave a new kind of account abstraction routine. Fusaka gave added a pre-ompile in Ethereum to make pass keys, the things that we use in our phones for Face ID, Touch ID. It made that cheaper because it put that straight into the protocol. And I'm here to talk about Glamdan uh, which is slated for early 2026, but we'll go into the details of that. Um, I will claim that Glamsterdam is the most profound hard fork in recent history of

Ethereum hardforks for app developers, for infra builders. This is strictly my own personal opinion. Um, and I guess I'll try and explain why I think so. At a huge glance, uh, Glam solves the top two biggest pain points of Solidity developers who sadly have been complaining for over 10 years. I am one of those people. Um, the first complaint was that contract sizes are really small. They're only 24 kilobytes. You can't write very complicated contracts with a lot of functions in them. In Glamsterdam, we're going from 24 to 64 kilobytes, which is roughly a 2.7x

increase. This on its own is a very conservative increase. We have a clear path to increasing it much, much more. Um, the second one is stack to deep. Anyone who has written solidity knows that you can only have 16 variables at a time. It's a bit of a mess. We can solve that. I'll go into details about this. The third one is adding logs for Ethereum. We'll go talk about this more. The next one is not spoken about enough actually. It's a new op code called slotnum which lets you in your smart contract figure out when the next slot is. Um, as I mentioned, Ethereum plans to make everything faster. That means blocks will become not 12 seconds, much

more shorter. So core devs with all of their insights have decided to already bring this op code. So smart contract people don't need to hardcode 12 seconds. they can for now do use the slottenham op code and eventually much later um as Ethereum becomes faster they can keep using it. Block sizes go from 60 million to 200 million in gas. That means much more transactions. Um there are a few gas changes too. We'll talk about that. And finally create 2 which is used by a lot of exchanges a lot of smart account teams that gets put in as into the genesis state. So, every new chain just gets it.

TLDDR, when Glamn ships, society will look amazing. It'll be great. Um, let's talk about some of them, some of these um, EIPs in much more detail. Um, contract sizes. So, almost everyone has probably seen this error sometime in their life building on Ethereum. Hopefully you will see this much much less. Um, today every protocol needs to rewrite their contracts into libraries or diamond proxies and have way too many contracts and delegate call and frankly it's a bit of a mess. Um, but after Glamsterdam hopefully you'll have

significantly less workarounds. The catch though, because there's always a catch, is deployments cost much much more. For a completely complete contract of 64 kilobytes, you'll probably pay something like 100 million in gas. Um, an interesting question here is, but how? Transaction cap is only 16.7 million. Uh, we're actually changing increasing the transaction cap as well. uh transaction gas is now 4 billion more than the block size. Um and any gas you want to pay will be taken from that. So the 16.7 million is just pure execution only. We'll talk about that a bit more

later. Next is stack to deep. I used to when I was a junior solidity engineer, my seniors joked that the only way to become senior is by facing this error and then crying about it and breaking your head for many hours. Uh I hate this error. It is a cause of a lot of nightmares for me personally. With in Glamsterdam, we're introducing three new op codes to make it easy for compilers to start manipulating the stack. So you can go from 16 stack variables to much more.

Um this is this does not just gets fixed the moment Glamsterdam is shipped. Compilers have to adapt to it. But the work that compilers have to do goes very very less. Sol which is the compiler that most of us use. If you don't know what compiler you're using, you're using Sol C. um sol will just have to enable these op codes add a few lines of code which they are already working on and you can see it by enabling EVM version Amsterdam which would be default the moment uh things become shipped maybe hopefully after Amsterdam all of us can tell new solidity engineers about

our pains these agents AI agents wouldn't know the pain that we all went through in dealing with these two three issues Uh the next one which is also not talking spoke about that much is ETH transfers. Today when you send tokens from me to you um you will get an event also called a log and every indexer every exchange really depends on this event. It's what tells them that this transfer actually happened. But that is not the case with ETH.

Instead, people exchanges or indexers need to do tracing in every call to figure out when transaction was sent. Even bigger problem if you're sending ETH from an EOA from my own account to a smart account. Pretty big problem for uh exchanges that use create 2. So now we are introducing this log. The log looks exactly like an ERC20 log. In fact, it has the same topic to filter just the emitter i.e. the contract which emits the log is FE to state that it is not any token. The catch here is you will not see this log for gas payments

because that is not the transaction. It's just a part of the transaction. You'll obviously not see this for past transaction. You won't see it for staking related transactions and you won't see it for reverted calls as well. Okay, so it sounds like Glamsterdam is mostly amazing for apps. There is very little bad things, right? No, sadly. Sorry. Um so as I mentioned Ethereum is trying to increase the amount of state that we can hold make Ethereum faster. Block sizes are going from 60 million to 300 million uh 200 million sorry. But if the number of

transactions increase that obviously also means the state increases. Um the gigab brains at core dev figured out a way where you can keep increasing the block gas limit without having to increase the state growth. But that is a much longerterm project. In the short term, what that means is a lot of gas op code pricing changes. A lot of them you will see in red. Specifically, anytime you are updating a storage of a brand new account, like sending ETH or USDC or D to a brand new account, your gas is 10x. I want to be very careful with my wording here. I

said gas and not the cost of your transaction. Your cost of the transaction depends on of course the price of ETH but also the block gas limit which is also increasing a lot. So just because you see a 9.7x here does not mean the price of your transaction will also be a 9.7x. Um some one thing is actually going is actually reducing which is the base call. It's going from 2100 to 1500 if there's no ETH. And there are a bunch of new things like we're adding a a gas per state. Another thing that I've not mentioned on the slides is how to think about gas. Historically gas has just been this one number. It's uh you have a cap in a transaction of 16.7 million and

that's it. Today uh sorry Glamsterdam onwards what happens is you can think of gas is in two buckets. The first is the execution gas. That's the that's the cost of your compute. that stays at 16.7 million. There's a new bucket. It's called the reservoir, which as the name suggests, any gas over 16 million just goes into the reservoir. And if you have gas in the reservoir, anytime you make any state changes, so sending ETH creates new state, sending tokens creates new state. Um, but also deploying contracts create new state.

Those go from the reservoir. And that means that you can now have much state heavy transactions than you could before without it competing with all the other execution only transactions. Initially we had a more naive algorithm where state and the execution were forced into one bucket. Now you pay for the thing that you actually use. um this two bucket scenario that I've created a nice interactive walk through on this QR code on this website for you to understand what changes but it turns out this breaks a few assumption that we as solidity developers have always

thought about um one of them is the gas left op code in solidity which tells you how much gas is left that can not actually go down because you have the reservoir now which might get refunds or all of the compute all of the state goes from the reservoir so your gas left which is the execution gas would show that you're constant because you have a lot of gas in the reservoir just because you call another contract um and that contract reverts does not mean that me also I will revert I still may have a lot of gas left if you're familiar with the 63 three of 64th rule

this changes some mental models. The other one is of course because we're changing the pricing. If you had ever hardcoded any of the gas numbers of how much gas to forward that may also break depending on what you've done. Also, as I alluded gas left only shows you the execution gas. It does not show you the reservoir. Um, so gas calling gas left may not give you the full picture of how much state gas you have. Um, and of course, as I've mentioned a couple of times, transactions can be more than 16.7 million.

[snorts] Cool. Um, all of that said, given some of these things have changed, particularly around the gas repricing, uh, chain security last month had discovered a few security incidents, but at the app layer. Essentially, a lot of these assumptions that we as engineers always had broke, which leads to new attack vectors for certain apps. This is not a bug in our implementation of Glamsterdam. It is not a bug in the clients but we it is not affect it does not affect any apps live today but we found out that if you were to ship Glamsterdam as is certain apps may have new security issues so we have

delayed glamsterdam for a bit to figure out first of all which apps are getting bricked secondly what do we do with what do those apps do what do we do and thirdly what's next steps for example next steps could be helping these apps update their code. Next steps could be us changing our own spec for how these gas repricing should work. Um, we're in early days of this, but huge shout out to DOB and chain security. Oh, I have a typo there. Sorry, sorry, chain security, but also that's how you know these are not AI slop. Um yeah, huge shout out to both of these teams for helping us analyze a bunch of contracts of and people deploying on L1

to see what breaks. Um okay, as I mentioned, if you know any app developers, if you are an app developer, if you're an auditor, if you build any libraries, please convey this message. There are a few things you should be doing. First, if you've written any smart contracts on L1, please check if the rericing hits you. Uh we have created a GitHub repo, another QR code for this GitHub repo. Um which will list all of the invariants that we have found so far that break.

You can point your AI agents at it and they can check with your against your contract if anything will break for you. If anything does break, please, please, please email us at this email. We do not bite. We want to talk to every team which gets affected by this. We want to figure out what we can do here. Um, also, Glamsterdam is already deployed on Seolia. Please do test all of your apps on Seolia. Um, if you are a tool provider, if you've written in indexes, SDKs, wallets, simulation tooling, please update. There are loads of things changing. Do not

have a cap of 16.7 million. Do not allow do not have a cap of 24 kilobytes. Update all your constants. And finally, um, go to forkcast.org. It is a website maintained by my good friend Mark. He has made this website very friendly for agents. It keeps track of every core dev call, all of the chats, all of the transcriptions, but also all of the EIPs included in Glammadam. You can always point your agents at Forkcast and ask it, hey, what changes for me? This is something I used to do in my old job and I highly recommend everyone to still do uh to still do this. Um, if you want to keep

track of what's happening with Amsterdam, some of these security incidents, this is also a great way to do this. You can set up, let's say, a chron job that pulls this every week or so or every month. Um, all right. Thank you so much for listening to my talk. I know it's been a long day. Um, if you want to reach out to me, that's a third QR code that has to be a record. Uh, but also you can read more about Glamster and its changes at those two websites. Um I really appreciate it. Have a great Devcon. >> Thank you for the talk. That's a solid piece of advice for the app developers.

Uh let's take some questions. >> Oh wow. >> So the first question is uh there are other important hard forks for 2027 and 2828. Does the delay of Glamsterdam affect those upcoming hard folks? Yeah, it's too early to say, but the other hard folks, Hegota, IR, Jar, etc. all of their work stream is sort of independent and the work has already begun because most of the work for glamst is also done. So, they're happening in parallel.

So, as of now, not but things change pretty quickly. So, let's see. >> Okay. Uh the next question is how will the protocol stop builders from abandoning blocks for late stage arbitrage during uh times of high volatility? >> I'm not sure I understand the question. So I'll try to answer what I think the question is otherwise please ask me or find me at the end. >> I think it's like the free option problem in APBS if I understood that correctly. >> Yeah. Um basically over here the protocol like we're doing a lot of work with EPBS which is one of the EIPs in glam that I actually did not mention here because this more for apps uh but

with that a lot of things become much simpler we can it's a much deeper topic we can talk about it outside >> okay so the next question is uh using block number for tracking time is a known antiattern u block time stamp is a much better alternative Why would we use a slot number? >> Yeah, slot number is more for telling you when the next slot is. Um, it tells you do not hardcode. There are many contracts that expect things to only happen every 12 seconds, which is Ethereum's current block. All we're saying there is stop hard coding the number 12. Block numbers, block times can change from 12 seconds to let's say

5 seconds or 2 seconds in successive hard folks. So it's more of a call out of not making this assumption that blocks will always be in 12 seconds. >> Okay. Uh the next question is is there no way to use ethlos for gas payments from an EIP8130 or frame transaction perspective? Uh native A and pay masters would inherit a lot of benefits with ETH logs. >> Yeah. So assuming this question means can we have ETH logs for gas payments too. With frames actually yeah you can always create like another frame so to speak which has an assertion which checks what changes including your ETH

um your ETH amount and then create a log for that. Um it's one of the benefits of having account abstraction. You can do what you sort of want. Okay, the next question is about parallel execution. Uh if we scale to 200 million gas limit, are we worried about the computational spikes uh and knocking out regular nodes out of sync? >> Yes, a lot of work on Ethereum R&D is to make sure Ethereum is always running and does not get out of sync. If regular nodes, you mean validators versus full nodes, those are very different things.

As far as validators go, um the whole protocol is designed to make sure that every validator can keep up. Much later on there'll be a lot of work on reducing state bloat and all of these things to make sure people can keep up. Um but the parallel execution is not proper. It's more on balance. So like to make sure at the later end of consensus when we are validating that like all these things work it helps with quicker validation rather than quicker execution. Those are very different beasts and with ZKVM we care way more about validations.

>> Okay we have time for one more question. Um so post Glamsterdam can the EPBS payment to the proposer be delayed beyond the N plusment slot? Um candidly I am not the best person to answer about that. I have done all of my work around what affects apps and infrauilders directly. Uh the better core devs that can answer but my current understanding is I do not think so but don't go by my word. We can research into this later or I can connect you with one of the core devs.

>> Okay. Uh that's all for this session and also end of [music]