Anatomy of a stateless client by Guillaume Ballet

Transcript

um so yeah I'm I'm working as part of the go etherum team and I focus on the fork called Osaka which is the the fork in two like two forks from now the next one is Prague and then it's Osaka you need to know two things about Osaka first uh its spirit animal is a cute elephant and the second thing is that it introduces a new version of ethereum uh which is statelessness and what is statelessness uh it's when you don't use the you don't hold any state and the state is the collection of all the accounts uh erc20 values uh balances I mean things like

this so we want notes to not hold this and just uh follow the network anyway um I'll start with the usual fear mongering bit where I remind you that client diversity is a big problem and that uh gu currently owns or represents probably two3 of the networks we don't know for sure it's it's kind of hard to determine um and what you have to know is that the the way the consensus algorithm Works in fact any consensus algorithm works is that if an attacker owns more than onethird of the network there's no way you can ever reach consensus but there's some flip side to

that it means that if uh honest uh player owns more than 2third of the of the network and has a bug we uh also like we will definitely finalize on an invalid uh on an invalid State and then uh there's no algorithmic way to recover from this so that requires a um some kind of manual intervention maybe it's just the decision that we're going to live with that bug the way etherum classic did it or we just have a very embarrassing moment um where uh where we have to to hold the chain and somehow try to figure it out maybe a lot of people get slashed uh that means that the security of the

network drops suddenly um so it's really not a pleasant thing so of course the guest team test their software um so is it likely to happen not really but but is if it does happen because we're all failable uh if it does happen it's very catastrophic so the question is how do we make it easier for people to um to adopt other clients um one thing I will start with the starting point uh I would like to express how difficult it is to maintain a client a client has a lot of modules um I'll start with the TX pool the TX pool is where uh when you send a

transaction it ends up in a big list and then it gets uh some algorithm runs to try to order those transactions to include them in the block so that they bring more value to the block producer the blockchain is simply the list of blocks um but it's also a series of functions that uh handle reorgs and things like that so there's a bit of complexity there the tree uh so tree TR i e is some special kind of tree t r um that we use to give a signature of the current state of ethereum this is what uh when you hear about vertical tree trees this is what gets upgraded in the EK Fork uh the peer-to-peer layer how you transfer transactions or blocks on the network

the evm of course the virtual machine everybody knows that the state is a series of helper functions to uh go read an account go read the storage uh like the storage slot inside a contract something like this uh the database the data Bas is well what it is a database where you store all the data on disk uh the sync is the algorithm how you somehow try to find the head of the chain uh and stay current uh ensure you are at the latest at the head of the chain and and you are downloading and processing the latest blocks the engine API is how you communicate with uh the consensus uh the consensus layer so uh the the since to merge it's a different

type of client that uh that manages the the consensus uh there's the then there's the consensus module which is a leftover from proof of work now most um most execution client don't really have a consensus engine to speak off I mean there's still some remains but uh so it's still there but we the complexity has been moved to a different uh different module and then you have the RPC uh endpoints where users can query information about the current state of the node uh when we did the merge like I said we moved most of the consensus uh intelligence or logic to a different client so that simplified the the execution client by a lot but of course

most of the complexity is still there we still have a lot of Maintenance to do we still need to look for performance uh for example when it comes to maintenance uh databases are a big problem uh simply because as we insert more and more data they become slower right every time you uh insert new uh a new field or a new element in the database it need it needs to look for a place to to go uh so it needs to thft through more data to find out find out where it goes uh the takes pool there's a lot of uh very nasty stuff happening in the takes pool of course there's all the protocol updates so all the uh Evolutions to the protocol that uh we have to introduce we need to

make sure they don't break all older versions of the protocol that you can still sync all the way from the start uh so that's the maintenance burden and then you have the performance issues uh the biggest one is IO when You' write data to disk this is the main killer everything else is uh come second far second uh you have the synchronization when you want to join the network you need at the best case you need a day if you want to do it like re-executing everything from the start you're between two and 3 weeks by now um and then you've got blog production because you need to produce a Blog but you need to produce it in a very short time frame and this is where parallelism for example would be useful of course it's a distance second to I/O but if we solve

the io problem which we will uh this this would become the the next big uh area of improvement so um these are the problems here's how we propose to solve some of them by introducing veral trees uh and what are veral trees or what at least uh I'm not going to get too deep into the veral tree uh uh the way they work but at least I want to give you a hunch of how they work uh what they do the what they do is that they allow for adding U to for creating blogs that are self-contain execution uh units so you add you take the current format of the block you add all the data that you need to execute that block you download it on

the network uh from the network you unpack the data you execute the block and you have nothing uh less than you have nothing more than what you need and you have nothing less so just to give a quick overview imagine your state only has four values v0 to V3 uh and during the execution of the block you determine that you only need v0 and V2 uh you package v0 and V2 along with the keys to to find them in the tree you create a proof with them to to prove that those values are indeed belonging to the state at that block and then you propagate this over the network and whoever wants to verify your block uh gets this extra data along with the block reconstruct a

view of the tree that's not exactly the same it's missing data but it's everything you need because everything else was not accessed right in that slide V1 and V3 were not accessed were not needed to execute the block so they're not in that view and this way you only get a tiny tiny subset of a very large uh tree uh and uh you can fit everything in memory which means uh you do not need to store the data on disk um so yeah another thing about veral tree is that it's got a single tree structure um so if you know the way the MPT currently works you have a tree for an account uh and for all accounts and then each account has a sub tree for its

state we get rid of that we put everything in a single tree because it makes the the proof smaller uh the proof themselves are smaller thanks to this new feature and uh the tree becomes smaller uh as well as as a result of this new structure and this is very important because as I was saying the database gets slower as the data increase so if you have less data and it grow slower then you uh like you you push back the moment where your database is going to to give up on you basically and now like I said because you can just verify in Ram most of the clients will actually not uh store anything so the database is no longer a

problem for them which means as a result you can already get rid of this database module which is which is a big uh maintenance burden um now I'm going to go over the sync very briefly as well when uh the CL finds the head of the chain so the consensus layer finds the head of the chain it sends a message called Fork Choice update to the execution layer and in that message there's a value that says which one which was the hash of the finalized block and the execution layer goes to its blockchain module looks for that block if it doesn't find it that means it needs to sync and then it starts a very painful process of going over the network trying to find the

blocks uh verifying that can be reorg there's a lot of data to download it takes a lot of time but so it will respond to the consens layer saying I'm sying check back later uh I'm I'm working on it just uh uh check for updates pull me for updates when it comes to stateless since you no longer store the entire blockchain it's pretty easy um the CL gives you an old like the latest version um of the block it knows the the the latest head of the block and either this e is the correct one soorry either this block is the correct one or it's an incorrect one so it's a yes no check uh

either you say well I'm synced because I I have the block you asked me in fact you gave me the block you you asked me to to set as the head or uh I don't have this block so figure it out and give me the right block so it's a very simple module so we can already remove the sync module or at least simplify it to uh greatly and we can also remove the blockchain because we don't store it anymore and by the way the blockchain is uh itself is taking a lot of space on dis it's the one biggest uh hog of space so um you can you can uh save a lot of gain a lot of performance and maintenance burdens by by removing it now uh there's the problem that to

build a block you need the state because the transactions they refer to a state you're supposed to have on your disk so you find yourself not having the ability to to produce a block um and there's a solution for that it already already exist even in a stateful environment it's you delegate the block construction uh to a builder via me Mev boost typically and uh yeah this is what I said like the solution already exists but people don't need the state at the moment a lot of validators don't use the state but they still download it so uh there's there's a way to now we just offer them a way to delete the state so that they just get that data uh that block built by someone

else and then publish it on the network uh when they get that data from the Block uh the difference um the difference being that when they receive the the data from the Builder the block from the Builder they also receive the proof that this is a valid block so they can verify the block before they publish it so once you Del uh gave up on the ability to build blocks yourself uh you decide you're going to delegate this to to a builder you can remove uh the the T pool you can remove the the blockchain uh you also uh remove the the sync in a way because uh you don't need to uh you don't need to download blocks and transactions anymore so you already

uh deleted a lot of uh well or at least you you removed the need for a lot of code uh you also have uh A reduced capacity to serve rpcs because you don't need to you can't provide information about the the state of the blockchain about peer-to-peer about sync so might as well get rid of that now uh some of you will probably have noticed that this is a bit of a problem in the sense that you're effectively trusting uh someone else to build the the block for you and the fact that uh the currently the builders there there's maybe like 10 different Builders um well it's it's a series of networks but there's definitely a centralization uh Factor here uh so what do you do uh

because then they can hold the state hostage they just don't deliver it to you and uh then the rest of the network is is held hostage uh well thankfully um there's a way to um to prevent this somehow and it's by using uh deterrence you there will be people myself included that will be happy to provide you a terrible block like a block that will provide you terrible returns but I don't need to be performant I just need to uh provide the risk for a Builder uh like an an opportunity cost to those Builders so those Builders will not uh like if people choose my bad block over them

over their dishonest block uh they can put a lot of pressure on those Builder to adopt a honest uh honest behavior and this is what uh this is what matters it's just the fear that anybody from the network can actually replace them even though it's going to be uh a terrible block at first but once again if um if there's a big Market in producing better blocks new actors will uh will start appearing U and what I mean is people like the the last harest block producer um does need not own all the state they just need to watch the network to keep a subset of the state

for which they can produce enough uh like blocks that are full enough the idea being that uh a lot of the state a lot of the E theem state is called and there's a very uh relatively small subsection of the state that is actually active at a given time so you could just hold that small subset and still produce useful blocks and if you need more you can start downloading from solutions that don't aren't quite here already but are being worked on like the portal Network where you have a distributed Network where you from which you can download the state so this is what a stateless client would uh look like eventually just an evm just the virtual machine the State Management

function the tree the vertical tree and the engine API to to communicate with the with the client with the consensus client and uh that that means that it's way easier to maintain um a fork sorry a a client for example because you only live block to block you don't need to worry about uh Forks like 10 uh 10 Forks ago right you only need to worry about the current fork and maybe the next one so you're able to Pro uh to to keep working past the fork but that's it so it's uh it allows for a lot of deletion of code delation which uh uh makes maintenance maintenance much much easier uh and we

have some candidates uh that work to to provide this uh this client this type of client stateless clients so we have the JavaScript one which is the by far the most advanced in the sense that it's uh already running on the on the veral test net and prod following the test net checking blocks stateless uh there's one in Zig being developed and there's been interest by people to write one in Crystal Crystal Lang so yeah a crystal Lang if you don't know what that is that is compile Ruby um right so this is the moment where I start making predictions that are going to come back and bite me um but I just want to give a sense of

uh how these changes are going to make ethereum evolve and what it allows I would say the the main uh the main uh point is that it's going to allow for a differentiation in actors so Builders they will want to build big infrastructures to produce the best blog they will want to uh to run archive know to learn from How The Chain behaved in the past that you know come up with a machine learning algorithms things like this uh on the other hand stateless uh solo stakers will be running very very lightweight machines and because those behaviors are very different they are likely to attract different kind of uh

well they are creating different kind of niches that uh clients can tailor to so that means that instead of doing it trying to Force client diversity by shaming people on Twitter like we currently do it uh we would have different niches where let's say client diversity emerges uh by itself instead of being tried being forced by intimidation or um other means that are not necessarily compatible with the values of ethereum as a community um and what I want to point out is if you get client diverse uh differentiation uh you get client diversity but there are two types of

diversities you get here because uh the first diversity is that uh yes you are getting uh different niches but the other diversity is that in the block prodution production pipeline you have several clients that interact right the blog productor will the blog producer will create a block using one client that will be immediately verify by the solo Staker responsible for publishing that block so if there's a disagree agreement already an invalid block will okay might still be sent over the network but you already have um less chance like you the the chance of this happening is already greatly reduced because you you need to have the same

bug in two different clients um and yeah and then uh I there's this article about that's uh like this this area of research called rainbow staking where uh people like the the researchers at thef that that worked on it suggest other avenues for staking your eth so not just uh not just uh blog production and that's going to create more niches and therefore there's more room for clients to uh to uh to start differentiating and um and diversity to happen now the point I assume most people are interested in in are can we raise the gas limit the answer is

eventually yes because those blog producers will need to store a lot of state so if you increase the gas limit you would immediately augment the way uh the the speed the pace at which more blocks get produced uh sorry the the state grows um and uh and so yeah the so you need some very uh specific infrastructure and that's some like we're talking data centers we're talking Hado clusters things like this uh not everybody can do this but uh that's fine because whatever they produce will be checked by the solo Staker so that's the other side of the scale low power machines uh low maintenance mode you

just plug them and you forget um and uh and they they work together and um and hopefully um this way because the the latter don't need to uh don't need to are not affected by the the the state of the sorry the growth of the State uh this way uh we can we can increase the gas limit without the network losing too many participants uh yeah and hopefully with all those techniques like rainbow staking with uh uh specialization um we can uh we can create more niches even more niches so that means even less permission to be asked and more

decentralization uh this is pretty much it if you want to learn more about veral trees and stateless in general stateless ethereum in general visit recorded info and I don't know if I have time for questions yeah we can take uh one or two questions do we have any questions in the audience so if the nodes in the network are mostly stateless does that mean that wallets meaning the users that want to do transactions will need to store part of the state state that they're interested in um right um that's a possibility but we yes if they want so the the main use case would be they ask someone else to

build the block right but indeed we could have um we could have some kind of hybrid validator that would store just a subset of the tree that they need or they they are interested in or they could just use something like the portal network uh where they just download the data as they as they need it and then they could have this subset they're interested in so yes it's it's possible to do this all they need is to have this view of the tree that they need and to make a proof of again against it which they can hi thanks for the talk uh when you say State uh proof and verifying do you imply Zike Nar no uh so it's it's a bit more

complicated than this but no these proofs are not ZK narks they are just plain um Vector commitment proofs um I'm looking for the word IPA proof if you've heard of it so it's just it's just um a polinomial verif like you're just checking that something is a polinomial uh but it's been designed veral has been designed to work both in a non-z environment and a ZK environment so all the crypto Primitives are chosen specifically to be ZK friendly so that when in the future we want to uh start using zkm when they become more stable when they when they become more trusted uh we can switch without uh we can switch to to to ZK proof uh without

without making any concrete like major upgrade to the protocol all right let's go a and give it up for guom B thank you very much Gom