# Milos - Ethereum Stateless Clients

- Channel: [ETHCluj Meetup](https://streameth.org/ethcluj-meetup)
- Date: 2025-10-07
- Duration: 23:26
- Watch: https://streameth.org/watch/yt-rx7GcjeRqM0
- YouTube: https://www.youtube.com/watch?v=rx7GcjeRqM0

## Description

The statelessness is on the Ethereum roadmap, in the visible future. Let's discover what that means and what Stateless clients will bring us.

## Transcript

Um, hi, my name is Milos. Um, I think the timer didn't start, so I would like to know how much time I have left. Perfect. Um, and I work for Foundation. Uh, and I will talk with you about the stateless clients. first so that I know the audience that I'm addressing. Can you raise your hand if you never heard about the statelessness before or you heard but you have no idea what it means? Okay. And can you raise your hand if you don't know what what is the purpose of what are the Ethereum clients like execution clients like what what they are or what they do. If you don't know what those are, can you also raise your hand or Okay. So we will talk about the stateless clients and first about Ethereum client. So if you want to access Ethereum directly from your machine, you have to run some software and that's usually Ethereum client and that's usually execution client or consensus client or combination of those two and you need that if you want to be a validator or if you just want access raw access to the Ethereum data Ethereum blockchain. Um if you don't have that usually you rely on some centralized entity to provide you the data for you uh because there is no other way to access it in a decentralized manner. So if you use MetaMask then MetaMask is probably uh getting the data from Infura or something like that. Or if you're using a web browser then the app serving you the the the website is accessing either their own data or from some other centralized entity. So pretty much most of the accesses rely on some centralized identity unless you're actually running um Ethereum client on your machine. And let's see what they do. So here uh there are couple of different types of execution clients. Uh and my talk is mostly focused on execution clients. They also consensus clients but that's outside the topic. And um there are three types of the nodes. Archive nodes and their purpose. We will see exactly what's the difference between them and uh the full nodes which is the most common type and the light clients. Light clients are not really defined what is their purpose and what are their characteristics and trust assumption. That's why there's an asterisk there because they are not fully defined what exactly it means to be a light client and what qualifies as a light client and what doesn't. Um and here are some of the operations that they are actually what they are responsible for to and doing. The first three that are highlighted um are basically the most important ones to keep the blockchain going on. So somebody needs to build a new block. Somebody needs to verify that the block that is being built is valid. And those first two tasks are basically done by validators. Although most of the validators outsource the block building to different entities using MEV boost so that it can build more efficient blocks and extract extra values from there. And the third one is creating and verifying transactions so that the memp pool of transaction is containing only the valid transaction so that they know what transaction to include in the next blocks. So that's all part and responsibility of the validators the main responsibility to keep the blockchain going on. The others are basically more user friendly features. So the head state is accessing the accessing the the the balances like for example what is my balance right now at the at ethereum or what is who who owns this specific token or something like that. What is the price of the ether compared to US dollar based on the unis swap deck pool. So that's everything is a head state like what is the price right now. If you want to know what was my balance a year ago that is belongs to the archive state that is no longer part of the head state and here we can see what are the requirements of these nodes. So archive node basically stores all of this information and depending on what kind of archive node you're running. Um it can go up to 10 terabytes if you also want to include all the proofs for all the data that it stores etc. So it's a very big machine requirements to have this running. The full nodes are way more common. They require only two terabytes of data which is still quite big. But they cannot access um or they cannot quickly tell you what was my balance a year ago. They can if they really want to they can go and recreate everything. They have a data to recreate that information on the go but it will just take like maybe a couple of days or a weeks to get that information. So so they just don't do it. But technically they can answer the historical stuff but they just don't do it. Uh and the light clients they pretty much cannot do anything. They don't have any state themselves. Um the first two they cannot do it any capacity. The rest they can do by relying on some centralized entity to give them that information. And it's the question whether they require proof or not. So whether they trust the centralized entity or they verify etc. But pretty much they cannot do any of these, right? Statelessness. Statelessness is the idea of block verifiers don't actually need to hold the state to verify the blocks. So right now, if you want to build a block, you need a states to build a new block. And that's still true for the statelessness. So block builders would still need a state, but block verifiers don't need a state. That significantly lowers the requirement of being a validator. If you just care about validating then this would make it much easier for you to do it. Um this is called weak statelessness. There is something called strong statelessness where even the block building uh doesn't require having the state but it's much harder to achieve and there is very little research being going in this direction. Maybe at some point we will think about this as well. So the benefits I will just enumerate them very briefly because um don't have time to go into details but there are many benefits to having stateless ethereum when the nodes are running much much easier the proofs are much smaller for the state you have all of these benefits um basically much much easier achievable with statelessness than without right so how what is the idea behind statelessness so this is how the generally blockchain works. Um, if you want to verify block n, every block has like a previous block hash, time step, state, root, etc. And the idea for statelessness is we would add another field to the block that is called execution witness. Execution witness will have all the data that you need from the previous block with the proof anchored to the state root of the previous block. So if the every block will include the execution witness anchor to the previous block and then when you want to execute or verify block n all the data that you need and only the data that you need will be included with the block that you are verifying and you can just verify the block n. So you don't need any state before that you can you will get the state that you need for verifying purposes and that's called execution witness. What does it contain? Well, it contains all the accounts that are being accessed, all of their balances, all of the smart contracts are being accessed, all of the stoages from the smart contracts that are being accessed. Everything that is being accessed during that block will be there with a proof anchored to the state root of the previous block. Now, as probably some of you know or most of you know, the current structure that stores the state is called Merkel Patricia tree. And you can do this with a Merkel Patricia tree. everything there is provable. Um, so you can do this already. The downside of it and why it's not being done is this proof will just be too big if you use the mer patricia tree. If you want to prove the entire block, I think the proof size can go up to maybe hundreds of megabytes or something like that. And if you have to distribute it across all state validators within 4 seconds or 5 seconds, how much they need time to receive to verify it and then vote on the validity of the block is just like too big to be practical and actually used in practice to spread around. So the meratri is not designed for this use case and it's not really good for this use case. So how do we actually achieve that? Well, we use the snarks like with everything in crypto. we go to zero knowledge and similar technologies. Snark says succinct non-interactive argument of knowledge. I'm not going to go deep into it but basically we need to change a state uh tree structure. There are two main candidates for this. One is called the worklet trees. Uh this is the AP proposal. Um I'm not going to go into how it works but basically it it allows to make much smaller proofs for any subset of the state. you can create much much smaller proofs that that state actually belongs to the state tree. Um and another with a similar idea but using completely different structures some different primitives is called unifi binary tree and it looks similar principles achieve the same things. Uh the trade-offs between these two approaches is worklet tree has been in research for much much longer. But even from the beginning of the research it was known to be not quantum secure and now there is a question whether we want to do it and then do another transition of the state tree later on that is quantum secure or should we maybe try to go directly to unify binary tree which will be made quantum secure from beginning but less research has been done into it. But considering latest advancement in the quantum uh computing and in a cryptography that is probably quantum secure etc. there's now discussion which of these two approaches will be actually uh when we decide to implement this which one of those to take. Uh there is a QR code you can scan where you can find more information on the ongoing uh research phase of the statelessness. Yes, I will briefly just mention that there is alternative uh something called ZKVMs where instead of having execution witness so execution witness basically gives us all the state and then we verify the block by executing the block and verifying that the execution is valid. The ZKVM we don't execute the block we execute the proof that the block is created correctly. So we don't execute anything. We just execute the proof. And it's a much newer idea. Um even less work has been done in this direction. Uh but it's something that we might want to get to at some point as well. Uh maybe before statelessness, maybe after statelessness, but something that is being also in part of the research, but not really part of the presentation so much. Uh right. So if you go back to our chart, uh now we have stateless clients. So what can they do? Well, they cannot do almost anything except validating blocks because they don't have state themselves. So they cannot access state, they cannot build uh blocks, they cannot verify transactions because they don't have state. They can know if transactions are valid or not. So they can pretty much not do anything. So they seem maybe not so useful. However, there are a couple of things here that um are other ongoing research that um sort of like interact with statelessness in in interesting ways. Uh something called EPBS I will talk about all of them in next couple of slides. Uh will be important for the block building. uh something called fossil and something called uh uh validity something partial statelessness um is the next one. They will be uh important for the transaction verification. Uh block building um right so currently most of the block validators and block builders they use meost to create new blocks. uh that gives much better efficiency in the block building and extracting the ME um and most of the validators use it. What is the problem with that? Um okay, I will go back. So the problem with that is that if you have centralized ME boosts, you rely on centralized entity to for that to work. And most of them may have boost it's not so uh trust specific but there is still a single checkpoint in the point of relays and how relays operate and both the builders and the validators trust the relay will do the work correctly and there's a lot of trust consumption in all this mechanism. The idea is to do something like that but enshrine it as part of the Ethereum protocol. Currently this is outside of Ethereum protocol and you have trust assumptions on it. The EPBS is stands for enshrined proposal builder separation where all this idea of having the separated entities that do a block proposing and the separate entity that does block building and it will be enshrined as a part of the Ethereum protocol. And here is like the EIP proposal. is still very early research. But what this will allow us in a context of statelessness is the stateless clients would then be only the uh block proposers. They would not be blockers. The separate entities do block building would be block builders and the stateless clients can be just block proposals. So they will still contribute to the block building uh part as well. Transactions and mempool. So the problem is well if we have very small number of block builders which we currently have and which we'll probably have even with the EPBS uh they can decide they don't they don't want to include certain transactions in a blocks that they are building. So they can decide to censor either certain users or certain protocols or whatever they want to do. So they can censors whoever they want and if there are only a couple of them then it's very easy for governments to impose sanctions on whatever they they deem they want to do. So the solution is fossil um fork choice enforced inclusion list. The idea behind this this uh EIP and this improvement is the block that there will be a subset of validators on each block that are going to construct inclusion list of transactions that the next that have to be included in the next block and then the next block builder will have to include those transactions uh in the next block. And there are how how to deal with when there are too many transactions being included they cannot include all of them and how to deal deal with all of these issues and that what fossil is about. How to basically you have majority of the nodes on the network can force inclus transaction that only one node is building in the next block and that's how you you combat the censorship um and you make the whole EPBS more censorship resistant. Uh now the problem with that is uh how can a statelessness clients participate in a fossil if they cannot verify what transactions are valid and what are not valid and that is a challenge because if you if you are stateless clients and you want to participate and include certain transactions in the inclusion list for a block builder to include you need to know that what you are including is actually valid or not. And the idea is validity only partial statelessness where instead of not storing any state you only store the minimal state that you need to store in order to verify the transactions. And there are a couple of ways you can do that. Um and the the WOPS EIP which is I don't think even EIP it's still like a very early stage. It's a it's like a research post about it, how it can be done and some some theory and research that went into it. Uh you can find the QR code behind me. Uh right. So with all of this stuff, stateless clients now look something more like this. Um first they don't participate in the block building because they're just block proposing. So the first category no longer applies to them basically. Um but they can do other stuff if all of these EIPs get adopted and get accepted and get implemented together. Um and yeah in a short term the main takeaway from this is the the lightweight clients are difficult but they are they're coming eventually to to whole ecosystem and everybody who wants to run a a Ethereum node on their own machine they can do so in a very lightweight uh manner. Um yeah and that's it from me. Thank you. if you have any questions. >> Thank you. Thank you so much. There's one question. So, we'll go to the next slide. And for you guys, you can scan the QR code and ask a question or I'll just walk around with the mic. Just raise your hand and I'll come to you. Uh but the first question is when can we expect Ethereum stateless clients? >> Uh that's a good question. My guess would be in maybe two to three years, but it's still like a long process and there is still research to be done and I would say maybe two years, maybe more realistic two and a half to three years. That's my guess. >> Do we have any more questions? Okay. So I guess uh we should uh think about implementing some form of uh rainbow stinking first like separating light services from heavy services first protocol services. Uh so those light clients can have light services to um offer to the protocol. Um I'm not sure I got the question. Um but yeah can you >> if uh if stateless clients or light clients u they are not they're not so useful at this point but once you have light protocol services once you once we implement some form of rainbow staking and we differentiate between some protocol services that need full node and some protocol services that need uh only stateless uh uh node. So my question is do we first wait to implement um some form of rainbow staking and then we think about how to build uh these light stateless clients. Um um I don't have much technical knowledge about the implications between the rainbow staking and the statelessness. My feeling um is you don't need to wait for statelessness to start with the rainbow staking and then once you have rainbow staking and statelessness you can figure out which of the use cases the statelessness clients would cover and which one would not cover and whether you need to maybe adjust the statelessness the same way that for example in the um the the validity only partial statelessness it doesn't like the statelessness doesn't work with fossils. So you fix that by having only partial statelessness and partial statelessness means you don't need to store smart contracts and any of the uh contracts from the stoages. All you need to do is just do the account tree for example and that's enough for the for the fossil for example. So maybe for the rainbow staking you can do something like that. You can see what use cases are covered and what use cases are not covered and um like can you use stateless clients or can you modify the stateless class to support that because even with the fossil and validity only partial statelessness if you're not a validator maybe you don't even want partial stateless maybe you will go fully stateless for your use case so it will be an option of what you want to do and what is your use case so there will be more options it will not be just um archive node full node node and stateless nodes. There will be partial stateless nodes and stateless nodes and light clients. So there will be more more variety on the clients and what state they store based on their use case. And I would say with rainbow staking probably you would have to see exactly the use cases and what you need. Maybe you need a maybe you will just need a full node if you want to cover everything. But maybe for a subset the stateless client would be enough or maybe partial uh stateless client would be enough. So we will have to wait and see how things develop. But I don't think you have to wait for that to be answered to start with a rainbow staking basically because you can just do a full node. Thank you for that. And I have one question for you. If we just take a step back, I'm non-technical, not a developer. Could you just explain as I'm five years old why is that important and why should we achieve that within the next two to three years? Um well as I started at the beginning of the talk currently if you want to access any of the state or if you want to do anything you need you need a node to run your machine which currently the only option is to run a full node that takes like two terabytes of data. If you want to for example just validate the state then you can use a stateless client that will have much uh much lower requirement you can run it on much uh the devices that are much weaker in a storage or in a CPU department etc. So you can you can run your node on a much weaker devices and still have access to it. You will still not have maybe access to the state um but you can use centralized entities and with the statelessness the proofs become smaller. So the centralized entities can provide you the data that you need but can also include proof in a way more efficient manner than what they can do currently and that's why currently most of the centralized entities don't include proofs or most of the protocols don't use proofs because they are more expensive and they're not worth it maybe so much when with the statelessness all that can be basically trustless in a way that proof because proofs are now significantly smaller so you can do it in a much more efficient manner and you can write the the the the clients on much weaker devices.