Sina Mahmoodi - Stateless Ethereum

hi guys Cena is about to tell you about stateless aetherium hey so this is Cena and this will be kind of like a li reminder kind of talk I've been following the ethnics and state conversation closely and here I will mention a few like I will first give an introduction or very lightening intro to stateless aetherium and what kind of changes we can probably expect and then how it could influence contract development like if you are designing a smart contract what should you have in mind like if you want to have it future proof when stateless aetherium hits so you all know about the storage growth problem the two main issues for users is that the storage requirements for nodes are are quite high and that it takes very long to sink a node so these are the two goals that the stateless etherium is kind of among other goals is targeting reduce storage requirements for at least some some of the nodes and hopefully improve like sink sink times like block processing times and the goal is to do it by introducing a new kind of client which is called a stateless client and these clients do not store the whole state they only store parts of the state that they care about and they depend on miners who who additionally like so miners right now they just produce a block and then propagated to the network but then they would also produce what we call block witnesses so Merkle proofs so so they say okay here's a block this is all parts of the state that this list of transaction needs and these are all the murk proofs that's that prove their validity and and they include these witnesses in the blog so that stateless clients when they receive the block and the witness they can make sure that the these parts of the state are valid and they can run the transactions against them and this is an example of a block witness and this is not a big block like it's one of the smaller blocks you can see the tree structure you can see those orange boxes they are hashes here down here are the leaves and this big thing is a contract code so mmm when you make a block witness you need to send all of the accounts that are needed for these transactions all of the storage items all of the contract codes so you can assume that this will introduce a lot of network overhead and here is like over a list of recent blocks like from 8 million something to to 9 million how much these these block witnesses like what what's their size and this is an average average over 128 blocks each point so there can be like we have blocks that have block witness of 3 megabytes but sometimes if it's lower so so up there the blue is the total and then you have all the hashes that are necessary for the Merkel proofs and then you have like the orange ones is the contract code that you have to send and down here are the actual values there so so you can see that the values are not much it's mainly dominated by contract code and proof hashes so the key takeaway here is that when we switch to stateless aetherium then although you know some knows won't need to store much but the network overhead will increase by quite a lot and to to make some optimization on the network overhead there are some changes like some possible changes being considered one is to change the tree structure of aetherium right now you might know that if he amuses a tree structure called Merkel Patricia tree and it's a hectare a tree so each node has 16 children but as we saw like heck Zuri trees have very large proofs so theoretically we thought that switching to a binary tree could reduce the proof sizes by quite a lot and so far at the like team for tubogas team Alex Ianno and the rest they've done some experiments and and have shown that this is true so we can reduce like if you look at this chart here you can reduce this so the hashes by 3 3 times which is which is quite a lot and after you do that the contract code will dominate the bark witnesses and so the next step is to do code medicalization and I will talk about this in more detail in a TCCC so if you're curious check it out code my digits of code medicalization is that four four four one transaction you don't need you know you don't need the whole contract code like if you want to transact with makers at all you don't need the whole thing you just need one function for example so here we we break contract code into chunks make tree out of it and then for every transaction we only send the parts that are necessary for executing it and this as we as as I show in in the data also reduces the block witness size by by quite a bit and the next thing so so up to here they were optimizations that you don't really care about like as a contract developer but the next three things affect you directly and especially the next one so because every time you do an S load or a balance or any of the up codes that touch a part of the state miners would have to include a Merkel proof for that so this means that any state accessing up code introduces now a lot of additional overhead and it means that the gas prices would have to be increased the other thing is that as we saw recently it's it's very hard to predict what the actual gas costs of an app code should be and over the course of a theorems life gasca's prices have changed a few times so something that's being considered and and this has led to breaking some of the contracts like with AIP 1884 which broke some of the contracts so so the goal here with ungass is to disable contracts from observing gas in their contracts so you wouldn't be able to know how much gas has been so far spent in this transaction and how much is left and the other one that is not directly related to stateless etherium but it's kind of related is chain pruning this is a separate proposal because so again full loads they have to store all of the blocks all of the block headers from Genesis from the first block of aetherium which is quite a lot of data and like clients are now considering to remove the remove it every once in a while and this makes it difficult for new nodes to sync to the network and you can expect that stateless clients probably won't keep this data anyway and this has some consequence that I will tell you they are about so so these are the changes that we can roughly expect I mean it's it's it's all in research phase it's not at all clear but it's it's very probable now I'm going to go deeper in to the gas price changes of state accessing up codes right now you might know that s load I think cost 700 or 800 but Vitalik estimated that with stateless aetherium the price might have to increase to 2000 and similar similarly for balance and other output it will have to increase to 2400 this is to prevent some some some blocks that can basically dass the network because you have to for every like every time you do an S load we have to include a miracle proof in the block which introduces a lot of data so we have to kind of price it in a way that we can target a maximum block size like we don't want blocks to become ten megabytes or twenty megabytes or something we want to limit them to let's say three megabytes so we have to price the state accessing up codes in a way that we can we can limit it as such so this is what this is one approach to to pricing states accessing up codes the other approach is to price it based on the actual proof size that they they induce on the network so let's say I have a contract that only has one storage slot the proof that would need to be included for this one storage slot is quite small you just need one leaf but on the other hand I have a contract that has a million storage slots which means a tree of depth are on a large tree and so each time that contract does is less load a large proof would have to be included so this is an alternative way of pricing but this would kind of discourage big storage for contracts like contracts that have a big storage would have to pay more for for storage it's also very hard to estimate because you can estimate for like any timelike s load up code is executed but on the other hand at the end of the block we are kind of aggregating these proofs together which we get some saving from so it's hard to estimate at the time of execution how much this this s load will actually add to to about data so we have these two approaches to two storage up code and then we have the contract code so anytime you do a call or an X code hash or something the code for the whole contract that you're calling has to be included in the in the block which which can be quite a lot like if you imagine the limit for contract size is 24 kilobytes right now so I can I can create a like a contract that does thousands of calls and this would mean that I that I can I think eventually in his post bitterly estimated it you couldn't you can craft a transaction that induces a block size of 300 megabytes which is quite a lot like we don't want that so one option is to charge gas for every byte of contract code like if you if you're calling a contract that has 100 hundred bytes you would pay 300 gas for it if it's a contract that has 24 kilobytes then you would have to pay 70 to kill 72,000 gas for calling that contract so depending on the size of the contract that you're calling you would have to pay more the other approach is to go down the Merkel ization route so we as I said before we create we divide contracts into chunks memorize it so forth and then then you would have to only pay for those parts of the code that were accessed during the science transaction so this will probably be cheaper but it's also more complicated approach yeah as I said so these are things that you shouldn't be assuming when you're writing a smart contract you shouldn't assume the prices of opcodes because these prices can change and they could therefore possibly break your contracts make them more expensive you shouldn't rely that at all at all I try to not assume any any gas prices the other thing is like you shouldn't for now you shouldn't assume a tree structure like if for example if you are doing miracle proof verification inside the insider contract that could that assumption could break when we change the tree structure and and sometimes some of the gaps use receipts and logs - as a way of storing things and this could also like this is also something that you cannot rely on because I wouldn't be surprised if in a few months client start pruning all blogs and old receipts so that the user cannot access them and this is something that I want to encourage like it would be nice to see more experimentation on so what we've been so far discussing is stateless clients but this is a similar approach but it's we call them status contracts so even before aetherium itself becomes stateless you can write status contracts and they would be like you have a contract that doesn't store anything but a 32 byte hash and this hash would be the root of a tree which you are storing off chain not in the contract itself and every time that you like a user sends a transaction you send all of the merkel proofs necessary all of the parts of the tree necessary for that transaction with it so let's say you have a you want to develop a stateless token you sort the root of like you have a tree of accounts in the leaves of the tree you have balances of the accounts you only store the roots on chain in the contract and every time you want to do a transfer from user a to user B you in - in the transaction you include accounts for a and B and the Merkel proofs for a and B and the contract can verify the proof and then do a transfer and that's it and this is kind of I I wrote here future proof because it doesn't use the default mechanism that if um provides for storage so even if up code prices are increased you won't be affected by it by much because you're only soaring one item in the contract and you probably won't be making assumptions about gas and so on so I mean you can you can think that the ZK roll-up and similar contracts they are stateless contracts ZK roll-up only stores one route but does the only difference to what I'm saying would be that they are doing all of this proof verification and transfer by zero knowledge proof but but you don't need the zero knowledge proof really and and something that could help with with this approach is I know some people like um ballet and and john adler they are working on pre compiles for proof verification and if these pre comp eyes come then you might be able to do this even for cheaper today so yeah in short storage prices will probably increase it's not clear how much or how exactly it could be a static increase in in gas or it could be based on how large your storage is you should make assumptions about gas you shouldn't rely on on logs and you should check out status contracts thank you and are there any questions I thank you so much that was a great great summary I unfortunately I missed like following up on the whole topic more than I probably should have so I got a ton of questions and maybe they stupid yeah no no I I have to say that I just wanted to like in the beginning parts I kind of gave only a short summary of what stateless a theorem is all about because if you're going to eat si si you will probably hear about it a lot I like I just wanted to focus on the later part which is how it affects you yeah so when you when you talked about the witness that I need to transmit with every transaction that basically my transaction becomes the whole witness and like the actual thing that that I want to do yeah so in the examples of like the pricing wouldn't it is it has it been considered that just the size of the witness would be the somehow impacting the price because that seems like the the clearest one to me if the your goal is to keep the block size at a certain limit yeah that's that's here the the second approach like what I call witness size sensitive pricing it's basically to to see how large the witness is and charge based on that but but the problem is that you cannot estimate exactly like when you're trying to execute in the transaction let's say you're you're running EVM bytecodes like when you reach an S load at that point you won't know how many other merkel proofs would have to be included because the thing is like you can you can estimate the price of one branch but at the end of the block we are all merging all of these into one big proof like this one so you would get quite a lot of saving and we like this only we know the exact size only at the end of the block not during the execution of a transaction so we can only do a very conservative estimate and that means that the the gas cost would be much higher than the necessary that brings me directly to my second question is how do I create that witness because if I now want to send a transaction from my wallet right I need to create that witness locally I guess no no so this is like with the stateless client approach you don't need to do that this is you just send a transaction the miner pick will pick it up and the miner will include all of like when the miner wants to make a block out of all these transactions in the pool it will also add the witness to the block itself so users won't need to directly send include the proofs I mean that's okay they might need to include parts of the proof parts of the witness that's that's still being discussed but the majority of the witness will be the responsibility of the miner so or they may so how does that make the miners stateless like I thought that no no no them the miners will be saiful I should have made this clear miners will be stateful it's just that you add a new class of clients that are fully executed they are different from light clients in that they can fully execute or fully verify the chain they can start verifying from the genesis and they will they will receive a block with its full witness verify it go to the next block and so on but these are a new kind of entity these are a new kind of nodes that don't have high storage requirements and we expect that like we will have minors that are stateful and then you would have a lot of user end-user nodes that we don't have now because user are now relying on in fira but instead of in fewer you could run a stateless client which has which can process blocks fast and don't doesn't have a high storage requirement yeah yeah so so miners would be stateful this is great I thank you for that information yeah so can I just follow up with one more stupid question there like if I run then this new type of client that it's not doesn't have the full state then I can't even use that to create a witness for my transaction right so I still have to know somebody like in fora oh yeah he has a full information yes so souldn't this is again what like I want to stress that again these are all in discussion like it's not I don't wanna say that this these are all clear at all or something but so it would be the network structure would have to change and the the stateless clients would store parts of the state that they care about like if I'm if I'm an end-user I will I would hold my my own account or all of my accounts in in my storage and the contracts that I'm more like most likely will interact with and anytime that I'm missing part of the sig like let's say I want to interact with a new contract that I haven't interacted with before then I ask the network ok what's this so this part would be interactive like I asked some some of my peers does anyone have this part of the state I get it with the proof I have it now locally and then but again so the end user wouldn't need to include the witness so they don't they only need this part of the state to be able to know okay what is my balance what is this friends balance how can i but they wouldn't really need to make the witness themselves apart from their own balance like they need to prove their own balance so that the client the other clients in the network can verify that they can pay gas okay thank you is very interesting thank you thank you see now for awesome [Applause]