Understanding Glamsterdam — Milos Stankovic | ex-Ethereum Foundation

Thank you. Thank you. Good morning. Um um my name is Milos. I am a former member of Fit Foundation and I will talk a bit about this coming up in a glamster.

Um so maybe first of all can you tell me raise your hands if you're familiar with how Ethereum forks work and what are the upgrades. So this I just had like a roughly feeling. Perfect. And um how many of you are more working on the protocol versus more or like raise your hand if you are more working on the app side of the Ethereum rather than the protocol itself. Okay, great.

Um so very quick reminder about uh previous and may plan for the current and future upgrades. So Ethereum upgrades we shipped Pectra um and Fusaka in 25. Uh plan is to ship Glamsterdam in November this year. So in 3 months from now roughly if there are no delays and there is another fork already being planned what is going to go there in 27. The QR code you can scan it leads to forecast which is a website where you can track all of the forks and all the EIPs that go into every fork and discussions and what is the current status what is the status of the test nets etc you can find all the useful information about forks in general uh over there um um so quick reminder in pectra uh we get slightly better wallet UX um we had some uh validator uh consolidation meaning they can like put more stakes uh like quality can have more stakes than just 32e um and allow the the withdrawals uh in Fusaka we did uh we scale the blobs which helps with scaling L1 and L2s as well um another cryptography primitives that also help with wallets uh with wallets and uh the main topic of this talk will be about what we are shipping in Amsterdam just highlight sites.

Uh we are further more focused on the L1 scaling um reduction trust assumption through EPBS which I will also talk about and various gas optimizations for or more like repricing not necessarily optimizations but um a lot of gas changes for the various uh various up codes and very briefly based on what we know so far for Hegotaa we are looking for improving censorship resistance via fossil which I will mention a Uh we are planning to add account obstruction via frame transactions and very likely still to be decided. It seems there is a lot of interest to make slots quicker meaning that blocks will be created faster than 12 seconds if that is being selected still TBD. I will talk a bit about that uh towards the end of the presentation. Okay. So Glamsterdam.

So these are all the EIPs that go into Glamsterdam. As you can see, there are a lot of them. Uh we don't have to like go through this list. I will go in smaller chunks through them later on. Uh but there are a lot of them.

Presentation is relatively short. So I cannot talk about all of them for a lot a lot of time. And um I will just focus on the main aspects that I think might be the most important. The others I I will just skip. Um the two at the top that are highlighted uh they are called headliners meaning they're the most important ones when the fork is being planned and they are the the main ones that core developers focus on and want to finish and ship as they are.

The others are just things that we add on top that we think is important but they are not uh like if they're not as critical uh usually and these here I group them into three categories. is the protocol improvements which are basically the ones that affect the protocol directly. Uh the network improvements which help with uh the nodes communicating on the network and sharing data on the network etc which are not necessarily part of the EVM or protocol but they are important for keeping the network uh lively and secure and someformational EIPs that are basically relevant to some of the other ones but they don't actually demand any protocol change. They're more like informative about why certain changes are made in a certain way. Um let's start with the first headliner uh EPBS or enshrined proposal builder separation.

Um the QR code will lead you to the exact details and everything about the the EIP. In short, currently the the the validators are responsible for building blocks. However, most validators are not very sophisticated block builders. So what they do is they go to the other external entities external to the protocol I mean and they ask them to build block blocks and extract M me make some other um stuff in a block that they can profit from and they share the profit with the validators themselves. In order to do that they both go like the builders and the validators communicate with the relay which are trusted entities to make sure that nobody cheat each other.

For example, if the block builder builds a block and gives to the validator, there is nothing that valid stops validator from um just taking all the profit for themsel once the block is being built. So rebuilding the block and relays are there to make sure that u everything is valid but it comes with a trust basically the both the validators and the builders trust the relays. Uh and shrine proposal separation uh builds this mechanic into the protocol itself. Um it's a very complicated changes a lot of on the consensus side how it works. Now the block builders are also uh participate of the protocol themselves.

They have to be registered etc. Um main point is it reduces the trust assumption in the system between the validators and the builders. They're both official members of the protocol. And another related EIP here is builder execution request. how it's technically not really relevant but it's one of other related EIPs here.

Um you can go and read more about it if you want but it's it's the biggest change on the consensus side for this fork and it took a lot of time uh to actually do it properly and build it and obviously there was a lot of uh input from the builders that are not core developers that were doing and wanted to change things and how exactly many components needed to be worked out together how they work. Um another uh this is on execution side. Another uh another uh headliner is a BAL or block level access list. Currently if you want to verify a block um you have to execute each transaction one after another. So that once after once you execute the first transaction you have the state after the first one then you execute the second transaction etc until you exit all transactions.

At the very end, once all transactions are executed, you have a final state and then you calculate the hash root of the entire state tree which also takes some noticeable time and only then you verify that the entire block is valid. With a block access list, you have access um at the beginning before you even start executing the block. You have access to all the state that changed in each transaction and the ones that weren't changed that were just being read. You also have access to what is being read. You don't have value what is being read, but you know what is the slot that is being read.

This allows you that you can start prefetching all of the stuff that will need to be read for the entire block already at the beginning and you can prioritize stuff that are uh important for early transactions if you want to do it. But you don't really have to do it because you can already execute transaction in parallel. Because if you want to execute transaction 10, if you prefetch what is being read on transaction 10 and you already have from the block access list, you have everything that is being written in the first 10 transaction or first nine transactions, you can already execute transaction 10 without executing the previous ones. So you can paralyze all transaction execution and verification. And since you know everything that is being modified in the block um you can uh start calculating the the state route very early on.

So you can paralyze that as well. So basically this goes from like a single thread model of processing the the blockchain. Uh you can parallelize it depending on how many threads you have. Uh you you can also utilize the disk uh IO much better. So it speeds up the the blockch block blockchain execution uh significantly and it's it will it's the main thing that helps us scale L1 um in the next fork.

Speaking of scaling L1, scaling N1 has many other challenges rather than just how fast you can execute a block. It's also how fast you can uh there's a network component which I will talk later but there is also other challenges that comes to the gas. Uh for example, if you scale the L1 and increase the max gas, um you also allow for blocks to become much bigger because you can include more transactions. Some transaction have like a lot of call data or the blocks can suddenly start writing a lot to the disk. So you have like another bottleneck about how fast the the the state will grow or how much time you need to to to actually write to the disk.

Or you might have a block that just reads from the disk. or just reading might be very expensive and costly. It might not fit in a time even though your computational power is significantly better etc. So we have here a list of uh various repricings. The first one that um basically is maybe the most important for average user is reducing the intrinsing transaction cost with basically currently if you're just if your transaction is just sending ETH it's 21,000 gas.

uh this is actually going to reduce that. I don't know exactly what value is being uh proposed. I think it's a different value if by sending the ease if you are creating a new account or if you are sending to already existing account because it would make sense that they are different because one is actually creating new state that will forever be stored. The other one is just updating the balance which is very cheap. Um and it's definitely going to be lower than 21,000.

Um others are mostly increasing the price for various corner cases that uh would be that are more that should be more expensive compared to pure computational costs that are mostly not being touched uh in this fork. Um you can you can you can go and see all of the EAPs if you care about the details about how expensive each operation uh is going to cost. Um the last two that are separate they are basically uh how we ho how how this calculation is being done. Basically various clients were being uh benchmarked and uh different operations were being uh calculated how long they take on each client on various different hardares etc and how the computation of the gas costs was being adjusted. And the last one basically is a discussion about what we plan to to increase the gas limit after the fork.

Currently it's a 60 million gas limit uh per block. uh there is a plan to after the fork to go maybe at the fork I'm not quite sure to go to 200 million and depending on how that go it seems that there is potential but it's a bit reservative to so it's safe to go to 100 million and that's why it was selected but there is potential to go maybe even to 300 million before the fork after glamsterdam even um increasing the gas limit doesn't require the fork this is purely uh validators and builders signaling what they think the the the gas limit should be. Uh so it can be done outside the proto outside of the fork. So the plan needs to go to 200 million and maybe even to two to 300 million depending on how things behave in in practice. Um the next group of improvements um are the EVM related.

Um this is in details. They are mostly uh important for uh obviously adept developers and also indexers or other other users of the of the Ethereum blockchain. Um so most of them are the most crucial for solidity because they can now do some stuff that uh their users want. Like for example um Nicola mentioned EIP uh 8024 that is going to help from my understanding with the stack to deep. Another one that is being requested by a lot of users is the maximum contract size.

Um another one that might be relevant for some some uh applications is you can now get directly the slot number uh directly in the EVM up code. Um and uh the first one it uh it transfers and burn emits a log. Um currently if you are just observing the blockchain and you want to make some statistics or analysis about the tokens and defy uh there is a completely different mechanism of how you would uh track whether ETH was being transferred or some ERC20 tokens are being transferred and this would basically makes it much easier for to track ET transfers and make uh it's just basically nice uh nice uh feature for for community uh deterministic factory uh predeploys uh 79.997 um it allows you to predeterministically deploy contracts across L1 and L2s always at the same address. So this will significantly help with uh applications that want to build on multiple on L1 and multiple L2s and always say make sure that they always use the same address because it will help with uh security like you're not going to mistype the address with wallets with everything.

Uh so just some nice feature for the app developers. Um couple of consensus improvements. Um I would say these are mostly uh some cleanups and um the consensus clients were mostly busy with the proposal builder separation EIP that I mentioned. Um these are the first one is basically the slash validators currently if I'm not mistaken they cannot vote anymore on the blocks but somehow they can still propose blocks which doesn't make sense. So uh the AT45 is supposed to fix that and the AT61 uh basically decreases how fast the validators are going to become validator or if you want to stop being a validator how fast uh that is being processed.

So how fast you join to become validator and how fast you stop being validator. um the network improvements. These are basically some EIPs that uh affect not necessarily how the protocol or the EVM works directly but more about how the clients communicate and share data between themsel. Um it's about how blobs are being shared. Uh currently you you you can send only the entire blob one by one or you can send the entire column of the blob.

But if you're already having certain so you can you can see the blobs as a matrix like each row being a blob and each column being a data that you have to store. Sometimes you might have the rows, sometimes you might have the columns and sometimes you might just missing some of the cells. But currently there is no way to fetch just one of the cell in the matrix. You have to either fetch a row or a column. This EIP allow you to to fetch only one cell that you're missing.

For example, um the execution layer data basically allows for um sending various different parts that currently are not uh not available on the network. So basically you can improve the a network efficiency when sharing data between peers. Uh again, it's not part of the critical um timeline, but it helps with nodes that are either sinking or that were offline for a couple of minutes and need to refetch to the head of the state or there was some network glitch and they need to update their their state. Um but they are just feature that are helping the health of the protocol in general, not uh not something that is significantly improving the end user experience. Um and the last one is basically helping with the syncing of nodes.

Um the snap uh v2 protocol using the block access lists um significantly helps with syncing the fresh client. uh current or original snap uh protocol had a uh potential like it I'm not going to go into details but basically there is a first phase where you start syncing and then as the blockchain keeps going you have to heal and regenerate the parts that uh you already um synced so that you re reheal the part that was being synced before you actually finish the whole sinking. If we increase the gas limit and the blocks gets maybe faster and more transactions, the process of healing can take longer and longer and the original protocol wasn't designed to uh very optimize to deal with that and that can take potentially a very long time and in some situation it can happen that uh first of all you never know how long it will take to finish sinking because of that healing stage is very unpredictable and potentially potentially it can take longer to heal than it is to keep updating the new state. So you potentially if it's if it if the blockchain scales a lot the the original protocol might not be able to follow it. So you might never be able to sync again depending on your network etc.

Um the snap v2 basically using the block access list pretty much solves that problem because if you have block access list you need to heal through the network you can heal using the the the blocks access list directly. Uh and there were a couple of EIPs. I will basically skip those. These are pretty much some code client health and technical depth that was left in a protocol that are not being used. But it helps with the core developers with the with the future upgrades and making the code uh and everything kind of clean.

Um really not important for anybody who is not a core dev. Um and that's pretty much so if there is a main takeaway about what we are shipping in glamst um we are scaling L1. We are block access list primarily and some gas repricings to to help with that and we are reducing trust assumptions uh by shipping the enshrined proposal builder separation and removing trusted relays. So basically that the now it's part of the protocol the the the builders and the validators work together as part of the protocol without outside trust assumptions. And let's talk very briefly about Hegota which is the next fork which currently we don't have a timeline but most likely sometime next year.

Uh there is one headliner already being selected which is fossil uh fork choice enforcer inclusion list. Um so one of the so this helps with censorship resistance. So if we have and we already have block builders that are building most of the blocks. If they decide or if they are forced by governments to not include certain transactions um those transaction will not be included for a long time until somebody who is like some solo builder who is on their machine building the blocks until they decide that I want to include this specific transaction. It can take quite a lot on time.

The fossil helps with this because now validators can the ones that are not building the block uh randomly selected group of validators can sele can say I want these transactions to be included into next block and the block builder is forced to include those uh as part of their block building under certain conditions. Those certain conditions are if the if they build a block that is full meaning there is no more gas limit that they can put in. they don't have to include any any anything that is being forced on them. Basically, they can say like no, I have enough transactions. I'm putting everything that I have.

But if they have some gas limit and they have potential to include, they have to include transactions that other validators send to them via fossil. So unless they're building a full block, they have to include it. Um or another condition also technically is if the transaction is no longer valid at the point that they have to include it. Like for example um user can have two transaction running at the same time. They cannot both be included because they have the same nons for example and if they include one and the other one is is in a inclusion list they can say this one cannot be included anymore because it's it's not the valid nonsance or the user spend their balance.

They don't have the ease to pay for it anymore. So there are some cases when they are actually not included and because they cannot be included or because the block is already full. But in most cases what is in the inclusion list the the builders will force to include them. If if they are in if they are able to include them they will be forced to include them and this helps directly with the censorship resistant as some components of the of the of the consensus layer becomes more centralized meaning builders uh this directly helps with that in a long term. Uh, another one which is not uh officially a headliner but a lot of people treat it as a headliner and it's gaining more and more support so it might be upgraded to a headliner is a frame transaction.

It has a it's kind of complicated um uh EIP and proposal and has a lot of potential benefits. Um it basically introduces new transaction type where instead of just having like how currently transactions most transactions are just sending the ETH or calling a smart contract to do certain one certain thing and to verify transactions all you need to do is make sure from the signature to see who is the sender of transaction making sure that the nuance matches the nuance of that user and make sure that he has enough ET to um to pay for that transaction And that's all that comes with verification. And that's all that comes for uh uh for verification and everything that needs that transaction can do. It cannot do multiple logic. The frame transaction is basically a new type transaction where you have multiple frames.

Certain frames usually the beginning of transactions are called verify frames where you can have arbitrary verification logic. It would probably be mostly checking signature, checking nuance and checking balance. But it can be done in a different way. For example, you can do like a multi- signature verification or one wallet can verify the signature who is the sender but another wallet will verify that they are paying for the transaction. So you can have a sponsored transaction by uh somebody else without you having the ease.

Um you can and then so those those frames the beginning will be verifying and then you have other execution frames which will actually do various stuff. So they can do multiple things at the same time and you can do some kind of transaction batching like for example within the same transaction you can make uh like for example if you want to do a deck swap in a first frame you can do an approval for the unis swap to spend your token in the next frame you can actually go and do the swap and they would be batched together and only if one of and both frames would need to succeed because you can structure them such that you want to chain the frames or you don't want to chain the frames you have a lot of uh availability of what you want to do with them. You can also have account of sections. You have have like arbitrary logic that can run um as part of your verification logic again multi- signatures or something like that. Um you can also have like postquantum signatures in their verification logic.

All of those come with some additional challenges how exactly want to do it etc. But frame transactions will in some way unlock most of those features. It will probably take some time for users and applications to build on top of it and get it there. But it will be available on a protocol level. Um, and most likely it's going to get upgraded to the uh headliner uh proposal.

Currently, it's being planned uh for the next fork. Uh this one and the previous one, the fossil, those are the that the only two that are being planned. Um others are in a current stage where they are just being proposed and now now it's starting a debate which of them will actually be selected and considered for inclusion. Um and there are a lot of them. Um but what is important most likely we're going to get censorship resistance and most likely we're going to get some native account abstraction through frame transactions as part of the next fork.

Another one that I mentioned very earlier is it seems that one of the proposals that allows for faster slots is having strong uh support already. Uh we are not going to get significantly shorter slots. Currently slots are every 12 seconds. But it seems that the first step will be to add parts of the protocol such that the shorts can be shorter because there's a lot of infrastructure that depends on all the slots are always the same length and there's a lot of dependency on that and a lot of things would break if you suddenly become shorter even to 10 seconds. A lot of things can break because there's lot of mad that depends oh they are all exactly the same time and a lot of assumptions around that and it's very possible that the first one will just enable things on the protocol maybe go sign like not significantly shorter but maybe slightly shorter maybe to nine or 10 seconds block and maybe the let down in the future maybe we can go even shorter to maybe six seconds or something but the first step will be to enable the protocol to go to a shorter slots and then we will see um in the future if we can go lower or not and by how much.

And uh that's all from me. If you have any questions,