Stateless Ethereum | Guillaume (February 2026)

Yeah. So I'm going to to speak about stateless Ethereum. Um when we talk about the state in Ethereum, what we mean is the set of all accounts of all balances of all u data that belongs to an account. So your your wallet balance, your USDC balance, all all those things, all the cryptokitties, all the NFTts, everything. And so the state is what makes Ethereum special.

Of course, that's what uh that's what gives Ethereum an edge over Bitcoin for example. Uh but uh the problem is that uh the state is growing. So we have uh if you go to this uh page which is called the lab, I forgot to give the link but it's lab.eththops.io.

you have a uh a lot of graphs such as this one and you can see the the state grows and it's not exactly an exponential but it's starting to look like like one. Um so so yeah this is a bit of a this is a bit of a problem. Uh the state is about 217 GB today and uh I'm extrapolating with the last over the last year. Of course it used to be less uh less than this but you can see this little thing here. Uh that's 50 gigabytes per year.

So it grows uh fast and it becomes a problem simply because uh all that state is stored in the database and the performance of a database is going to crater as uh the state goes goes sorry grows bigger and bigger and right now it's okay you don't really see it in fact you might get the impression Ethereum is going faster and faster uh but there will be a point and unfortunately it's going to be uh to come as as a shock is going to happen in yeah really in just uh from one moment to the next the uh the data will be such that the performance is going to crater. We know that because we tested uh so and we found out about this problem. Um so the perfect uh solution would be uh to not to use a database. Don't store anything in the database. So what we do is have the idea of self-contained block.

You have the block, you receive the block, but you also received the part of the state that you need to verify to execute this block, to do whatever you want, but at least you got the right context. Um, and this uh extra data is called the witness. So, it's uh all the accounts that you access during this block, all the proofs that some things that get created uh when something gets created, it was nothing before. Um things like this. Um but uh so the advantage is that if you can achieve that, this is great because uh you don't really need to do a sync.

If anybody's running a node, they might know how long it takes to to to get the state. Um and uh well, we we want to get rid of that. So uh that would be that would be a very sweet point sweet spot to be at. Uh so how do we get there? Well, let's look first where we are today.

And the state currently is stored in what we call Merkel Patricia tree or MPT. An MPT u is a tree that has what's called an arity of 16 which mean which means that every child sorry every node has has up to 16 children. Uh and so we each node for example this one has uh 15 siblings. And then you go on uh the next level uh and and so on and so on. So this is of course a representation that is a bit simplified.

The tree is much larger 270 gigabytes total. Uh but uh what you can see if you want to create a proof um you have to pass all 15 siblings at every level and this adds up. So you end up at having about 4 kilobytes give or take a few things uh just to prove the inclusion of one uh one value in a block. you access maybe a 100 a thousand values. So this can balloon fast.

To make things worse, uh contracts, smart contracts, they have code, you know, they're programs, they have code, and that code is only referred as the hash of the entire code. And that means that if you want to to pass this in the witness, if you want to pass this to uh uh any node that does not have the state, you need to pass the code. And the code really comes as a slab as a big chunk which means you can actually craft blocks uh that are extremely pathological where the block would be 330 megabytes like the the witness would be 330 megabytes. Now imagine if you produce a block and by the way that was uh those are numbers from before we increased the gas limit from 30 million to 60 million. So now it's more like half a gigabyte.

And um imagine you produce a block. You have a lot of nodes on the network that that try to replicate your block. You have to send that witness to them. Um that means you have to send half a gigabyte. Let's say you have 20 peers.

Uh half a gigabyte to everybody in 12 less than 12 seconds. Uh and then they need to connect uh to their own peers and and send it to send it over. So that's that's a lot of data and that means you will not be able to um to achieve that if if such a pathological block happens the the block is missed basically. Uh oh and one thing I forgot to check to say is this 330 megabyte block is very cheap to do uh because there are because of the way the the code is uh is stored. Um and uh yes, you can for $25 you can create a block like that and that's going to kill a lot of uh things on the network.

Um so we don't want that. Obviously we would also because by the way uh 24 kilobyt is the maximum size of a code uh of of a bite code. Uh there's a reason why there's a limit. In fact there are several reasons why this is the limit. We would like to expand it because everything that is really interesting requires more logic.

So more data, more more code. But if we do this, we uh look like we paint ourselves in a corner because that means the the future witnesses will be even even larger. So what we suggest is to replace the the tree with a binary tree. And you can see each tree at each level a tree has two siblings. So you do have more nodes, right?

uh the depth is higher but uh because you only pass one sibling instead of uh 15 you actually uh reduce the proof size by uh sorry the w the witness size by 4x. So it's uh it goes from 4 kilobytes to only 1 kilobyte. On top of that, what we want to do is chunk the code in pieces and instead of referring the code to the code as a whole, we just uh refer to one piece at a time. Every time we use we use it, we we add it to the witness, but just the piece, not the whole code, which is great because that means we can then expand the size of the of the code. And um yeah, you will have to uh if you if you don't access most of it, you don't have a problem.

Uh and so the worst case uh if we do all of that is uh 10 megabyte witness and uh that's a lot more practical. This is still a bit heavy if you have to send it to uh to 20 peers and you know 5,000 validators overall on the network but uh but it's it's much more realistic. Uh now I'm going to uh detail a bit code chunking which is what I was referring to before. We want to cut the the code into small smaller pieces and in fact this is the more interesting uh present um like the more explanatory view. Uh imagine your code is 23 chunks but you know when you start the code you can jump here which by the way is incorrect.

You should always uh uh jump like it always starts at at the first but um okay that's uh that's bes besides the point here. Um so you start executing this and then you jump here and then you decide to jump here. Why not? And then you come back here and you exit. So you can see there are more um there are more codes parts of the code that you did not touch than those you touched.

So in the current model you have to pass it all. It's a slab. Here you just pass what you what you use. So it's smaller. And uh of course uh that's not the end of the story.

We also associate a gas cost to every to every time a a chunk is being accessed for the first time. So that means if you want to execute the whole thing, you can, but it's going to cost you more money. So there's uh it matches uh between the usage and uh and the size of the witness, which is something that did not exist until now. Um mind you, this is not only for witnesses, it's also for executing code in memory. So if we want to have code that is I don't know 100 megabyt in the future why not uh you know guess for example is I checked this morning is 76 uh 77 megabytes.

So if you want something complex that will take more code u but you don't necessarily want to load everything into memory especially if you want to do like execute contracts in parallel if you want to do a lot of things. So with this approach, you can just load everything as you need it, one by one. You pay for it. So every time there's a load, there's a gas cost associated to it. And so it's a much more uh I would say future proof uh model.

Um like I said, to to do this, we're going to uh to change the gas cost. It's going to become a bit more expensive. And the reason for this is because we are putting the code inside the tree. So we treat the code like any any other part of the state like code and data are exactly the same thing and so they are treated the same. So uh since they are treated the same you should pay the same.

So far you get a huge discount on using code and uh we have to fix that. It's uh it's a bit sad for applications because it's going to become uh become more expensive like I think 20% uh in our estimates but uh the result is that we will uh we have something that is more um uh perennial because we uh you know we don't ask anybody on the network to subsidize execution for for everybody else. So quick uh quick recap in terms of clients. Today we have stateful clients. You need over one terabyte of space on your disk.

Uh it's actually less true today because you can delete the the block history but the idea remains the same. Um and uh it takes takes hours up to days to to synchronize to get in sync with the network. Um you need uh powerfulish hardware. I mean, we say 32 g 32 gigs of RAM, a processor from from 5 years ago. Um, and then NVME, you know, it's uh it's a bit expensive.

You know, it's going to be 1,000 one and 1.5,000. Um, uh, but yeah, it's uh it's still manageable, but it's it's quite uh it's something you need to to buy and maintain. And then the future potentially stateless clients. So you you store just what you need and nothing more.

Um you get an instance almost instance synchronization because the proof to execute a block is correct. If you know that the block is the head of the chain, then you know the block is correct. You're you're exactly where you want. Uh you can run it on the phone potentially on a browser. Uh the joke the meme is that you can run it on a watch.

I'm not sure why you would, but in theory it's possible. Uh Justin Drake loves this watch uh watch meme. Um and then yeah, it's like it's like um a light client, but you don't need to trust anybody. So that's uh that's pretty great. And you can still be a validator.

So if I don't know if you have people validating uh creating blocks here today. Uh but if you exper if you experience this, this is a lot of trouble. You need the machine. You need to make sure it doesn't uh you know if you you need to have a contingency plan. And if you're on holiday and the power is cut off, uh you have uh it's a lot of headaches.

I in fact most people I know just say, "Well, if it uh if it dies while I'm on holiday, I I'll just turn it back on in two weeks." Uh but yeah, that's the kind of thing. Whereas in this new model, all you need to do is uh you can run run it on a Raspberry Pi potentially, plug it and forget it, and it's not going to to bother you too much. Um so what do we get out of this? uh we get a lot more transaction per seconds like I said at the start the problem is the DB um if every validator on the network does not need to maintain the state in this DB they can re-execute faster which means you can give more time to the to the block builder to produce the block and because you know that in the uh when the block is created and propagated uh it will be much faster to to verify so uh you can put more transactions inside a block.

Um better decentralization. So it depends on the on the model is definitely better for the validator. In some models it's also good for the builder. Um yeah I was talking about trustless like client but more importantly and I'm going to talk about this it enables state expiry and then because the proofs are smaller uh it facilitates uh inter interoperability between L2s between L1 and L2. Um, so if you looked into uh native rollups for example, that's that's a great unlock.

All right, how do we switch from um from the current tree to the to the new tree? Um there's about 1.5 million uh sorry billion accounts in the state. You're not going to be able to uh to convert that in one second like in 12 seconds between two blocks. It's just it's just too long.

So there are several uh ideas that have been proposed. There's one that I haven't uh mentioned this, but uh I'm going to mention uh I I haven't mentioned it on the on the slide, but it's called the rollup appreciation week where we just turn off the chain, translate, and go back uh the next day hoping everything is translated and correct. That's of course uh like a straw man. We're not going to do that. U but uh but at least that gives a a reference point in what we want and what we don't.

Uh there's something a bit similar. uh we keep running the chain but we just do the offline conversion offline. This has several problems. So we haven't really uh created any IP for this because we tried to look into this and it was so complicated then we said we're not going to we're not going to do this. The reason for that is uh you need twice the the space on your on your disk during the conversion.

You need to store two trees and uh once the conversion uh is done the chain has progressed. So you need to replay the blocks in that alternative history and this is very risky to do because there might be something that was correct in the old uh way of doing things that might not be correct in the new thing way of doing things and you will only find out when you replay the blocks. So you can find yourself stuck, excuse me. Um and uh and uh yeah um it's it's a bit dangerous. So what we want to do is the overlay transition.

And how does that work? Um you before a transition you just have a merkel partition tree with uh three accounts. So if you want to read the account B for example you go straight to the MPT you want to write same thing and then the transition starts. Uh so we create a transition period. Uh and uh we put another tree on top which is the the target tree uh the binary tree and we call the overlay and then the MPT is frozen.

So you can no longer write to it. You can still read from it but you cannot write to it. And if you want to read from an account a prime that is actually an updated version of account A. So um for example you transfer some funds to it. So you've wrote it's here.

So you read you find it in the tree. That's good enough. Uh that's the end of your read. If you want to read an account that is not currently in the overlay, uh you continue and you read into the MPT. You find it there.

You return all the rights because this this tree is frozen. So all the rights will uh end up in the MPT. So a new account D here has been created that will mask any potential uh account D that existed. even though in that case it didn't. And then and that's not really uh well represented so I need to improve this this slide but um you have an iterator that goes over the state and the stride of that iterator is like 10,000.

So every block we convert 10,000 accounts 10,000 slots um and uh and those things are copied into the bin tree into the binary tree. So that means that when the iterate the iterator sweep has has ended all the data that were not clobbered by the by the overlay tree are have been copied into the overlay tree. So all your data has been converted. That's the that's the TLDDR and so you no longer need the MPT. You can delete it.

One important point is that uh once account A has been um has been uh clo is clobering uh sorry once account A prime is clobbering uh account A I can delete account A. So I don't have to store both trees on the disk. U so it's saving space. It's putting everything in consensus so we know if something is wrong we can just use the regular reorg logic to to uh to fix it. Um, yeah.

So, that's that's what we're going to to deliver. Um, and now, uh, I'm, uh, okay, I'm a bit over time. I'm sorry, but, uh, that's not I don't have to to, uh, yap too much longer. Um, I want to talk about state expiry. So, what you have to know is that the the expiry the state most of it is completely um, uh, completely uh, I mean most of it is completely dead.

Some people they they touch they create uh they create a contract they create they store some data they never touch it again we don't necessarily know why we have some uh intuition for example we know a lot of things are related to me um but if you're doing me and you're trying to to collect a lot of money from uh from some other transactions the thing is if you create a contract you're not going you're not going to care about cleaning after you you spent money to create the contract um but you're leaving it where uh where where it is. It's it's going to cost you money to delete it. So why would you you don't So the result is that uh like I said 80% of the data hasn't been touched in over six months. Um and um and you can see this is pretty much the same line as the one I showed at the beginning. This is the the growth of the state and this is what you do.

This is what you get if you delete data uh that hasn't been touched in I think this is two year. Yeah, two years uh one month. But what you can see compared to this like like I said this is more or less exponential. This is more or less flat. I mean sure there's a little bump here but uh but overall you can see it's more or less flat.

So that means that you can uh if you delete all that stuff that is essentially useless. Um the result is that your performance remains the same because your database size is the same and uh yeah you can see here I think if you delete after one year after six months you get 80% of the state if you keep for two years it's more like 60% but it's still half um half your uh half your data u and I think people you know people might might uh think well but deleting data isn't that against the e ethos of uh of blockchain And the answer is yes and no. Um because there are two things when you when we started Ethereum we created uh you know we we made a bit of a mistake. We conflated two things. there's the commitment to the data like so you commit that this data was there and you can prove at any time that uh it was there and then there's the storage aspect of it where the data is stored but then if you think about it that means that you can store any data you want you know even if it cost you a hundred euros to to store that data it's effectively free because over time the everybody is expected to store your data for and you paid once.

Okay, it was expensive €100, but uh divided by by infinity uh that's still that's still effectively zero. So there are two promises that were made together and I think uh we still want the commitment. So what we want to be able to do is to say yeah okay you commit your um you commit your data at this point like you store it we give it to we let it uh we ask everybody to store it for like six months. So if you need to access it for the in the next six months, no problem. But then we're going to delete it.

But we're keeping the commitment to it. So if you provide us with the right proof that this was here at this time, for example, we'll resurrect it for you. Um and so yeah, this is in my view uh the distinction that should have been done. So this approach I just described preserves the ethos of uh proving that something was on the blockchain at some point but it doesn't promise that things will be stored forever because then things accumulate forever and then in a 100 years hopefully Ethereum still exists in in a 100 year people will still be storing everybody's uh cryptokitties when no one cares about it. This being said I was surprised to check uh people are still using cryptokitties quite quite a lot.

Um, right. There was something else I wanted to say about that. Uh, okay. That's uh I'm a bit over time, so I'll skip. So, yeah, next um next question is who's going to hold the state?

Um, that's that's a much harder question simply because uh when everybody is expected to store everybody else's data, there's a clear role defined. But as soon as people are uh free to start deleting data from their discs, the question becomes uh who's responsible for this. So this is still an open question. Uh we have the beginning of an answer for this is probably going to be wallets and RPC providers simply because especially wallets they make their money. Um you know I discovered recently that builders are actually not the one making money because uh all the money they earn most of it they pay wallets to give to send them transactions.

So actually they are not the ones storing the data. Uh but wallets are the best candidates to to store that data simply because um well first they want uh users to use their services. So they will be uh they will they will make sure that uh in terms of UX that's that's better for wallets to provide it and then they can also charge a small fee for resurrecting like they can charge the user they can say well look you haven't used your data in 10 years in a 100 years you know your grandpa hasn't touched that data in in in a 100 years u just pay us a little bit we've been keeping it for you all this time just g give us a little bit uh we'll uh we'll build a witness for you to resurrect your data and uh and we'll do uh you know and everybody's happy. So um so yeah this is probably how we answer that question but this is still very much uh open. So as a way to conclude um there's you might have seen recently and I'm sorry the the the picture is really unreadable but that's because there's a lot of things uh Justin Drake recently published the the straw map or the strawman road mapap.

Uh you can find it at strawmap.org. or and there's a lot of things to do but what I wanted to point out is that you have binary trees so about uh end of 2027 so this is uh this is the first step and then um there's another thing that's uh I can't can't even read anymore uh endame state that's what they call it endgame state which is a solution that probably uh includes uh state expiry and potentially other things so that's more like for early 2029 if the road map you know is on time. Um yeah take away u stateless Ethereum is going to help increase uh uh scalability the scalability of Ethereum. Um if you have any question or if you want to learn more there are two things you can go it's pretty hard to read but you can go to stateless.

fyi which is the website where we store all our resources. So we have presentations, we have explanations, we have plenty of things uh for anybody interested. And the second thing is that we're organ we are organizing a stateless summit uh in CAM during CC uh on April 1st. Not a joke. And uh we uh if you want to participate, you are welcome to.

If you want to learn, if you want to contribute, uh please uh please this is our landing page. So please uh come meet us. And that's it. Thank you.

Yeah.

Oh. Uh. Oh, sure. Yeah. was chosen by the state.

Um the the honest answer is I don't know. I haven't figured it out myself, but um my my u okay like the the more serious explanation would be that people have tried. It's a very difficult UX problem. Uh you know I' I've heard about state run since 2018. I haven't seen a single, you know, Ligi is is uh shaking his head in approval.

Um this is this is a this was a concept we we've been playing with since 2018. Uh it has never delivered anything uh anything uh palatable. So um so yeah, we just uh we just decided to to move on to something else. But if you want if you feel like uh implementing state rent if you have a solution that satisfies everybody well first of all good job and second come talk about it. Yeah, Ben.

So when you mention the partition contracts, will this be similar to like access type to say I'm going to access these parts of the contract,

right? So uh I forgot to repeat the previous question, but uh are the like the the contract chunking is it like access list? No, it's completely orthogonal. Uh we are going to I mean you could add those chunks to the access list already. So it's not a it's not a problem.

Um but uh but yeah like we it's really just witness based. So if you want you can add them to your access list but this is kind of replacing access access lists anyway. So when uh you can um I mean I would say the design space is open but what we what we want to do is really uh we like I would say the cost aspect of it is very much like access list but the access list would be would be uh duplicated. So um now okay I was talking about transaction access list now there's block access list. So in that case that would be pretty much the same.

So it's a it's a list of locations you access including code that would be attached to the block

sir.

Yeah. So very questioning for less hardware requirement. requirements also very fast.

Um, yeah. Okay. So, let me summarize this question. Um, yeah. Okay.

So, do we have a trade-off curve between centralized fast building and uh decentralized slow building? Is that a fair summary summary of your question?

Uh yeah, something like this and also like the entrance barrier.

Yeah. So we still want every anyone to uh to spin off a node. So this is definitely I would say this is non-negotiable. the one thing that is currently up for debate. Um, and I'm going to try to be uh to give a honest rendition of the other side's argument because of the other side of the debate.

Uh some people want centralized block building uh with very powerful machines and the idea is those people will uh you know will be like provide the speed that Solena has and then everybody uh you know uh is still able to verify using stateless stateless proofs. So um this is personally not the model I want. So once again uh I'm going to try to sell it. definitely going to make a bad job at it because I don't believe in it. But um but yeah, like the idea is you can try to do the the best of both world by building fast and centralized and uh and verifying so still keeping the decentralization because if a centralized actor misbehaves you, you can uh you can slash him.

You can uh you can refuse his block. So uh so yeah, that's uh I mean that's pretty much how rollups work as well. centralized centralized block building and then if they misbehave you you have a chance to uh to claim uh a fault and uh and refuse that block at at the L1 level. Was that a

yeah Chris?

So do you have thoughts how decentralized block building could work?

Yeah. Uh maybe I do I have thought on how decentralized block building could work? Yes. Um I mean you would not necessarily get the same scale of course because centralized block building is always going to be faster clearly. But uh the question is how do you build decentralized block building that is fast enough for the current use case right?

Um and yeah there are plenty of things we could do. I mean we could uh we could for example work on our database engines instead of uh pouring all all our resources on on you know this uh this approach. So if I go back to the um yeah I'm sorry to to bring this back but uh they want to have mandatory proof here. Uh so it's a zk proofs proving u this can only be done in a big uh in a big server like the the computing power required to achieve this this box is is you're never going to have that okay you're not going to have that in everybody's um home in the foreseeable future. So that means only big builders can have that.

Well instead of working on shipping this we could just rewrite our database engine. Uh it's going to give us a 3x improvement. It's not uh it's not as good as what this promises, but at the same time it's it's achievable and it can be done in in the same time frame.

Okay. Ben

one accounted over.

Yeah.

Is this more like contracts that are accessed frequently? Is it migrated? address, right?

Yes. Uh it's the same address. Absolutely.

A prime is unlikely to be but rather it's anything.

If it's not clear, I can explain offline.