Milos Stankovic - Understanding Glamsterdam

Good morning. Good morning. Thank you for coming. Uh my name is Milos. I work for the deal foundation protocol prototyping team and today I will talk about Amsterdam.

Who here knows what I mean when I say Amsterdam? Raise your hand. And who has no idea what I'm talking about when I say Amsterdam? Okay. So, good.

Let's first see what what I mean by that and what is what am I even talking about? So, on Ethereum you probably know we have hard forks every couple of months, every year, sometimes twice a year. And those forks basically introduce upgrades to the core Ethereum protocol and we get some new cool features on the protocol level. And this is historically uh two forks ago we had Petra and I will explain how we came up with the names. They are slightly here.

So, on the Ethereum we have two layers. We have uh execution layer and consensus layer. And uh we started after the move to the proof of stake uh when we introduced consensus layer we started making forks both on execution layer consensus layer at the same time on the same date. Um and we started but they are sort of slightly different technologies. And we started uh basically the names of the cities like Prague, Osaka, Amsterdam, Bogota.

They are names of the forks that happen on the execution layer. And uh Electra, Fullu, Gloss, Haze, those are the names of the star uh in the universe and we we named those for the consensus layer. So, we basically use this ideology to combined the cities on the earth and the stars in the universe to kind of like bridge the gap. And the the the name of the fork is combined those two names together. So, for for Electra and Prague it was Spectra and you can see the others.

And these are the previous forks. So, very briefly in Spectrum, that happened in 2025 in in May, we um we gained these features. We unlocked some account abstraction which enabled better wallet UX. Um we allow allow validators to consolidate. Before Spectra, you could only run a validator node.

You needed 32 ETH. If you had 32,000 ETH, you needed 32,000 validators. So, now with validator consolidation, you can have like a run one node that has more ETH on its own balance. So, its own vote will uh give more votes to the consensus system. And withdrawals address exits, this is a bit more technical, uh but basically it allowed validators to exit the validation directly from the execution's uh layer instead of always going through the consensus layer.

Uh in Fusaka, we focused on scaling um L1 and L2. Uh around that time we increased the gas limit on L1 from uh 30 million gas uh per block to 60 million gas per block. We also unlocked some uh passkeys for wallets and other primitives that they can use more natively with pre-compiles that support uh different cryptographic primitives. And the main focus on Glamsterdam will be L1 scaling, um reducing trust assumption between the builders and the actual validators, and some gas optimization which indirectly helps with gas scaling. We will cover this very in details.

And we already know what is the high-level idea for the next fork after Glouchester dump, um which is Hegota, and that is uh censorship resistance and native account abstraction. Um we don't know exactly yet the dates. We expect that the Glouchester dump happen somewhere in the third quarter of 2026, and in 2027 we will somewhere in 2027 we expect the the next fork afterwards. So, let's focus on Glouchester dump. So, these are all improvement proposals that comes to Glouchester dump so far.

Um and don't worry about this all of them read. We will cover them a bit late in details, but not every single one of them. The QR code you can go you can go to the website called forecast, uh which where you can see um all of these proven proposals for in details what exactly is. Go read more documentation if you really want to learn all the exact details. Um I will just explain what are these differences.

So, first, how the Ethereum core developers agree on what proposal needs to they want to do in the next fork. So, at the beginning uh when we discuss the fork, we first select the headliners. Those are usually one improvement on the execution side, one improvement consensus side that are the biggest and the most sort of set a team of the entire fork. Like, what do we want to focus on? And they are usually the biggest the things.

So, for Glouchester dump, that is uh the the two that are marked with a star, EIP-7732 and EIP-7928, and shrine proposal builder separation or EPBS, and block level access list which we call balls. So, they set the teams for for Glamseldam and after the headliners are being set, then uh they are called headliners and they they are considered we are not shipping this fork until these two are done. These two are the two primary things that we want to ship. Others are a bit more optional. Then, they go and discuss what other things we want to add in the same fork either because they are small and they are nice improvements or because they somehow depend on interact with a headliners in some way or to the general team or something like that.

And again, depending on the complexity and everything, something that is maybe very good but if it's too complex, we are not going to do it in the same fork. We will maybe make it a headliner in the next fork, etc. And first all of the EIPs, EIP stands for Ethereum Improvement Proposal. All the EIPs um go to the stage of consider for inclusion where we basically consider everything and then maybe through voting some of them are no longer considered and then they're declined for inclusion. And none of the declined ones are showed here.

And as clients teams start working on something, once they make enough progress and they maybe write to a devnet or something like that, then we when we feel very confident those are ready and we are more like most likely going to ship them, then we upgrade them to schedule for inclusion status and those are all the ones that are being bold. Um in a bold font. So, all of the bolded ones are pretty much guaranteed to be included. Everything else we still plan to include but if for example uh all headliners are all done and ready and maybe couple of the others that are not done, we might decide to we don't want to delay the fork for some of the others, non-headliners, if they didn't make it in time because people or engineers didn't have time to prioritize them and work on them, or they they figure out they might be too much effort, or there are some other difficulties with them. We are completely fine with removing some of those.

It's also possible later to add one or two more fork proposals because something very small or something that needs to be improved comes up to the last minute, but that really happens. Um so, let's talk about the headliners first because again that sets the theme of the entire fork. Um ensuring proposal builder separation. So, does anybody here know what are the role of validators or sort of like does anybody here doesn't have any clue how the consensus mechanism works on Ethereum? Feel free to raise your hand so I just know how much details I should go on that topic.

Okay. So, I will assume everybody has at least some knowledge. I will very briefly say um so, validators are in charge of verifying the blocks every slot or every 12 seconds one of the validators is being selected to be a proposer. So, they are by protocol supposed to build a block and then send it to the rest of the network. There's the validators, they validate and vote whether the block is valid.

And um the at the end um uh they come to a consensus that the block is valid and then the next validator will build on top of the the last block and the blockchain keeps building. Um so, I did say that slot is 12 seconds and you will see later that I say that uh broadcast and execution time from 2 seconds to 9 seconds changes with this change. Um so, even though the slot is 12 seconds, the first 4 seconds are reserved for block building propagation and validation. Then the next 4 seconds are reserved for uh validators voting on those votes. And then the next the last 4 seconds are reserved for aggregating those votes and propagating to the rest of the to the entire set of validators.

I'm not going to go into details, but usually the the entire time that the validators have to propagate the block through the network and verify it is around 2 to 4 seconds on average. Um and with this proposal, what we do is So, yes, another thing to mention, currently protocol is designed such that every validator builds their own block. But uh we have uh out-of-protocol entities called builders and relays in the middle who are trusted entities and most of the time they are the ones doing the the block building because they are more sophisticated builder, they can extract MEV, make some profit, and they share part of that profit with the with a with the actual proposers. But this is done outside the protocol. And in order to make it safe, there is a relays, which are a bit more centralized, and they are trusted entities both by the proposers and both by the builders.

Um and they make sure that everybody basically trust the relays in this system. And it's not part of the protocol, you have trust assumptions. So, in enshrined proposal builder separation is designed to make the builders first-class citizen of the protocol as well. So, now we have another entity that is just responsible for building the blocks. In short, how it works, um the the bids for who is going to build the the block is different from who is going to propose the block.

The block proposer has a right to still build the block themself, but alternatively, on a protocol level, they can also accept bids, and they can accept a bid from any of the builders, and they can say and then they propagate on the network on the protocol that this builder is going to reveal the block that they built. And the builder still has to pay the the price to the to the proposer even if they don't reveal the block, even if they don't build the block. So, there are some guarantees there expected that now basically replace the relays. Um I'm not going to go to into details. You can scan the QR code, you can read all about it.

It's very complex change. It's one of the reasons why we are the the the fork takes a bit longer to implement because there are a lot of moving parts, a lot of external entities, meaning builders and relays that also are affected by this. So, we have to coordinate with them and figure out how is the best how it best to do this. Um But, the main benefit is that now in we no longer have trusted entities, so we reduce the trust assumption in the whole protocol, and because of how we structured the fork, um the how we structured the the proposer process and when the block is being propagated and by who and when it's being verified, we get significantly more time to propagate and verify block now than in a previous design. Um The next uh headliner is block access list or balls.

Um Currently, so this doesn't help with block building building, but it significantly helps with uh verifying the blocks. So, currently, if you want to execute and verify the block on execution layer, you have to run every transaction at in order, and every transaction runs purely sequentially. So, you start executing the transaction, then for example, you have something to read from the state, then you stop executing, you go to the hard disk, you read the state, you get your state, you continue executing, again read something from the state, you stop executing, etc. So, there is a big sequential execution that is interrupted by using disk to read state and again write state, though you can write state sort of in parallel later on, that's not on a critical path. And after you execute all transaction, you have to calculate the new state root after all of the transaction are being executed.

The block access list, in short, gives us a snippet of what are all the states that are being read in a block and what are all the rights that are being written during every transaction. What that allows us is, as soon as you receive a block and block access list, you can start pre-fetching all of the states that will be ever read in the entire block. And you can, since you know all of the rights that are going to be done in parallel, you can start calculating state root already from the beginning without executing any transaction. So, you can start reading everything from the disk, you can start calculating state root from the beginning, and all transactions, because you know what changes in each transaction, you can execute transactions in parallel. So, you can execute transaction five without first execute transaction one, two, three, four.

You just know what states change in those transactions, and that's enough for you to execute and and verify transaction five. So, eventually, once you execute all of that, you have to make sure that what block access list says that was modified transaction two actually did get modified transaction two, etc. So, you basically can parallelize execution, you can pre-fetch everything from the state, and you parallelize a calculating the state root, which significantly improves the speed of we can uh verify the block. Uh again, you can scan the QR code, you can read all the details. Um but yeah, it gets uh significantly improvements on uh on the verification speed of the block.

As I said, it doesn't have with the block building, but it helps with the block verification logic. Um Again, these are now going to talk about other improvements that we could and I separate them to multiple categories that are sort of related to each other. One is gas re-pricing, which is basically focused around scaling L1, which is also what block access list do. They allow us to execute the block faster, meaning verify blocks faster. But we want some other things.

If we want to increase the gas limit, we run into multiple challenges on the protocol level. So, one of the challenge is is if you increase the gas limit, let's say five times, somebody if and you keep everything the same, somebody can make the block five times bigger in pure bytes size. And that can make it in a worst case, it would take five times longer to propagate through the network. And that comes with its own challenges. So, maybe execution logic is five times faster.

Um so, you can compensate execution verification logic with the balls because balls you can paralyze based on how many cores you have. But if it takes five times longer to propagate through the network, you still run into some bottlenecks. So, for example, um computing so, increasing the call data floor cost that basically increases how much how expensive is the call data. And the more bytes you add using the call data, the bigger the transaction is, the bigger the block is, and we want to price that more accordingly to what we want to achieve. Uh Another Another issue with when you increase the block gas limit is um the state the the the rate that the reach the entire state grows will also increase.

So, if you suddenly have five times more gas and they are five times more transaction in Ethereum, the entire state of the entire Ethereum will keep increasing as of at a 5x rate compared to the current state. So, that is an issue because for most node operators and for most home operators, we advocated that 2 terabytes would be enough to run Ethereum node. We know that the state keeps growing and always keep growing and we need some solution in the long term of how that can be sustainable. Um but the the 2 terabytes gas limit is not something we would hit very soon, but if we scale the gas limit 10x and the state that the we will hit that uh boundary 10 times faster. So, instead of maybe having 10 years to figure out the the state growth problem, now we have 1 year to figure that out.

So, the state growth is another problem that we can run into if we suddenly increase the gas limit significantly. And that's for example, what the state creation gas cost increase is focused on. Um and the state access gas cost update because as as as the state grows, it become it takes longer to read stuff from the disk, it takes longer to write stuff to the disk and update the state root, etc. So, there are other stuff that's regards to state that change as the state grows on its own. Um the first one is reducing interesting transaction gas.

is very uh interesting and I think maybe the most important for average user out of this list. Um Currently, if you want to send the ETH, simple ETH transfer from one account to another, always costs 21,000 gas. But if you think about it, if you send the account if you send the your ETH to account that already exists in a database or in a Ethereum state, that is just changing one number to a number to another. Like, there's no new state creation and anything like that. It just changes one number to another, just the balance changed.

If you are sending it to an address that doesn't already exist, we have to create completely new account on the Ethereum state that will now have the thing. So, there is a increase in the size of the entire state, and it should be priced differently. And that's what this is going to do. Basically, if you're sending to already existing account, it's going to be cheaper than 21,000 gas. If you're sending to and creating completely new account, it's going to be, I think, similar price as it is now.

But, the sending ETH transfer simple ETH transfer to already existing account is going to become cheaper. I think some other stuff are going to become cheaper. Like, for example, if you the 21,000 gas is initial gas that you pay just for interacting with the account, like a smart contract, even if it exists. I think that is also become cheaper because you're not creating anything in that first initial interaction. But, then again, how much smart contract logic you consume, that's going to add to the gas anyway, but it's going to become slightly cheaper to do basic stuff.

Um And many of others are updates and increases, basically trying to make consistent that operations and their prices are consistent with uh the target uh gas increase that we planned. We still need to do a proper benchmarking to figure out exactly how much we can increase the gas limit. Current target, I believe, is 200 uh million. So, we plan after Gansteldam to scale from 60 million to 200 million gas. And see how that whole goes.

Maybe we can even bump it further. Um but, that would be like three times uh increase in a couple of months from now. Um EVM improvements. Uh these are mostly some stuff that help developers, the the dapp developers. Um ETH transfer and burns and its log, basically now if you look through the uh receipts of the block or transaction, you can find uh for example, ERC-20 transfers.

They will all be shown uh in a nice logs. But, if you want to see ETH transfers because they are on the core protocol, they were never emitting the logs, so you never see them as logs. There are some metadata you can go and try trace and figure it out, but it's much harder to do that. So, uh this proposal will actually emit the log every time the ETH is transferred between two accounts because it becomes much easier for uh wallets, aggregators, whatever to figure out what ETH was transferred during the transaction between what accounts. Uh slot number op code, uh currently the EVM, you don't have direct access to what is the current slot.

You have You can technically figure it out because you know what is the time step of the block, and then you can do some math and figure out what is the slot number. Uh but, many many applications would benefit and simplify significantly they would know slot number. There is no reason why we shouldn't support that. Um increase maximum contract size. This is something that developers were asking for for a while.

Uh 24 KB is very small. It's been like that I think since very beginning of Ethereum. Uh maybe not since very beginning, but at least for the last eight years or something, I believe. And uh develop smart contract developers have to figure out to split their code into multiple smart contract that they are going to call between themselves, etc. This is not huge increase, um but there are many challenges in going further than that.

We have plans for that, which will might happen in the fork afterwards or maybe two forks from now. They are more complicated, and we want to something as a first step to make it life easier, and we are going to do a proper solution uh later down the road. Uh the deterministic factory pre-deploys. Uh this is yet another nice feature so that um basically make it consistent if you want to deploy on the same address across uh Ethereum layer one and uh some layer twos and you want always to be sure that you always deploy on the same address so that users don't have to worry about am I on base or am I on Arbitrum and am I on layer one? Where am I?

What what is the address of my uh application or DEX or whatever or uh you ERC-20 token? This will allow to developers to always be in control um or always be consistent on what addresses they deploy their smart contracts regardless of uh what uh what uh layer one or layer two they're on. Uh backward-compatible uh functions. This is more like Solidity improvement stuff. Most developers will not touch this uh directly but Solidity will offer certain features and make certain operation cheaper in the terms of gas uh how much they how much it would cost to do some some some operation in background.

Uh it's more for like a language programmers that to care about rather than the the uh the dapp developers. Consensus improvements, as I said um EPBS, the first headliner that I covered, is on the consensus side and most of the consensus work uh took a bit longer for that. So none of this, as you see, is bold so none of this is actually being done so far. We still plan to do them. Um Very short, what is the most important from this list?

Um Uh Yeah. First one is purely security-oriented stuff. Uh if somebody gets slashed, we don't want to let them propose in the future, which completely makes sense. Should be part of the maybe things from the beginning. Um, the last one helps with propagating.

Uh, currently, if you if you're propagating blobs on the on the network, you propagate columns from all blocks at once, uh, but it can happen that, um, that, uh, the the recipient has already parts of that columns. And this allows to propagate only the parts that they're missing in a way. So, optimization. You don't propagate data that the other side already has in a way. Um, just network optimization stuff on the protocol level.

The the middle two are similar and related. Basically, it will be if you're validator and you want to stop being a validator, uh, it should be faster. Like, it will take less time to, um, to exit validation if you want to exit. Um, and the the exits and consolidation. Consolidation is if you own 10 validators, is it having 32 ETH?

Um, and you want to combine them to one validator, that's called consolidation. Exit is if you want to stop being validator. Now, technically, they're going to be processed kind of together in order. They're going to be one queue for processing all of that, and it's going to be faster than before. Um, slight optimization for validators so they can faster stop being validators or consolidate and etc.

Uh, and, um, the last category is, uh, a bit of code uh, code health and tech cleanup on the protocol level. It's more for the core developer improvements rather than end users or even validators etc. Um, let me see anything high highlight to highlight. It's mostly just making things more performant um and better. Yeah, I don't think there is anything here for most of the audience like uh for core developers, these features matters because they allow us to simplify protocol, to simplify the code, to remove some of the functionality that is not being used, uh to make some stuff more performant on either networking layer like the sparse block pool, uh sorry, sparse block pool.

Um the EIP-70, EIP-71 basically they work together with the block access list. They are also dependent. They are related of how the client think because until now the client didn't have access the they were we didn't have block access list, but now we are also adding them during the sync process when the when you just start a new client, so that also like supports in that regard. It's not necessarily needed, but it improves things and thinking should be much faster and more consistent. Um it's mostly the improves the life and the quality of the the clients themself.

Um I can I can dig deeper into this during the Q&A somebody has any specific topic either from this list or any of the previous ones. So, in short, uh the the Glimmering Dawn upgrade is focused on scaling L1 and reducing the trust assumptions primarily on the relays and the builders because they are now part of the protocol. Um and let's very quickly look at Hegota, which is the fork after the Glimmering Dawn, probably coming somewhere in 2027. Um the one main thing that is already selected as a headliner is a fossil, which is fork choice inclusion lists. Um in short, this allows uh this this It another entities of part of the consensus protocol that are called inclusures and they even though they are not building a block or proposing the block, they can force the next proposer and builder by extend to include certain transactions in the in the build in the in the block themselves.

So, they basically like we want these transactions to be or more like if I'm inclusure, I would say I want these transactions to be included in the next block. Now, it's not very strict. You cannot fully force the builder to do that. The The builder will be forced to do that if they still have some gas limits left in a block. Like if they want some transaction that they want to include, they have that freedom.

But if there is an extra gas limit that they can use and there are some transaction that other people want to include via inclusion list, then they are forced to include them. But if they have a full block, then they can do a full block and ignore the inclusion list. So, it's a sort of a compromise with builders having a freedom to do what they want, but also respecting wishes of other participants of the network that can force them to include something that maybe they don't want or maybe they don't know about certain transactions, etc. Um But yes, basically it's helps with censorship resistance because if we have builders that don't want to include certain transaction for censorship reasons, this way they would basically be forced to include them. Again, if their block is not full, they will be forced to include them.

Um And another proposal which is not a headliner uh this time for Hegota, it was a bit uh uh difficult to select a headliner because none of the options was so big or important. The only one that was strongly considered was French reductions, but some client teams uh due to pure complexity of the change were unsure this is the best path forward. They definitely want to do something regarding native accounts account abstraction, which is what frame transactions do. They definitely want to do something regarding post-quantum security on the account level, which is something that frame transaction can do. But whether the frame transaction design and the actual specification of how we achieve that is the right approach, they didn't want to commit to to be a headliner status.

So it's the only one that is being considered for inclusion at the moment, and there's more research on that to decide if uh if there is a if this is the right approach or do we want something else to consider? And so far, these are the only two proposals that are being scheduled or planned for the inclusion, and currently we are in a period where all other EAPs are being proposed and being discussed what else is going to be there while we still work on the glams and also it takes a bit longer. Um but in short, for hecota, we get censorship resistant through fossil, and we will get some post-quantum security for the externally owned accounts, and we will hopefully get some native account abstraction support as well.