 Hi, guys. Sina is about to tell you about Stateless Ethereum. Hey. So this is Sina. And this will be kind of like a friendly reminder kind of talk. I've been following the Eth1x and Stateless conversation closely. And here I will mention a few, like I will first give an introduction or very lightning intro to Stateless Ethereum 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 Ethereum hits. So you all know about the storage growth problem. The two main issues for users is that the storage requirements for nodes are quite high and that it takes very long to sync a node. So these are the two goals that the Stateless Ethereum is kind of among other goals is targeting. Reduce storage requirements for at least some of the nodes and hopefully improve sync times, like block process sync times. And the goal is to do it by introducing a new kind of client which is called the 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 additionally, like, so miners right now they just produce a block and then propagate it to the network. But then they would also produce what we call block witnesses, so Merkle proofs. 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 Merkle proofs that prove their validity. And they include these witnesses in the block so that Stateless Clients, when they receive the block and the witness, they can make sure that 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 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 9 million, how much these block witnesses, like what's their size. And this is an average over 128 blocks each point. So there can be like we have blocks that have block witness of 3 megabytes, but sometimes it's lower. So up there the blue is the total. And then you have all the hashes that are necessary for the Merkle proofs. And then you have like the orange one is the contract code that you have to send. And down here are the actual values. 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 Ethereum, then although some nodes won't need to store much, but the network overhead will increase by quite a lot. And 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 Ethereum. Right now you might know that Ethereum uses a tree structure called Merkle Patricia tree. And it's a hexary tree. So each node has 16 children. But as we saw, like, hexary 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, my team from Turbogev team, Alexi Akhnov and the rest, they've done some experiments 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 three times, which is quite a lot. And after you do that, the contract code will dominate the block witnesses. And so the next step is to do code miracleization. And I will talk about this in more detail at ETHCC, so if you're curious, check it out. The gist of code miracleization is that for one transaction, you don't need the whole contract code. Like, if you want to transact with MakerDAO, you don't need the whole thing. You just need one function, for example. So here we break contract code into chunks, make a tree out of it, and then for every transaction, we only send the parts that are necessary for executing it. And this, as I show in the data, also reduces the block witness size by quite a bit. And the next thing, so up to here, there 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 op codes that touch a part of the state, miners would have to include a miracle proof for that. So this means that any state accessing op 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 very hard to predict what the actual gas cost of an op code should be. And over the course of Ethereum's life, gas cost prices have changed a few times. So something that's being considered, and this has led to breaking some of the contracts, like with EIP 1884, which broke some of the contracts. So the goal here with OnGas 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 Ethereum, but it's kind of related is chain pruning. This is a separate proposal because, again, full nodes, they have to store all of the blocks, all of the block headers from Genesis, from the first block of Ethereum, which is quite a lot of data. And like clients are now considering to 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 later about. So these are the changes that we can roughly expect. I mean, it's all in research phase, it's not at all clear, but it's very probable. Now, I'm going to go deeper into the gas price changes of state accessing upcodes. Right now, you might know that Sload I think costs 700 or 800, but Vitalik estimated that with stateless Ethereum, the price might have to increase to 2,000. And similarly for balance and other upcodes, it will have to increase to 2,400. This is to prevent some blocks that can basically dust the network. Because every time you do an Sload, we have to include a Merkle 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. We don't want blocks to become 10 megabytes or 20 megabytes or something. We want to limit them to, let's say, 3 megabytes. So we have to price the state accessing upcodes in a way that we can limit it as such. So this is one approach to pricing state accessing upcodes. The other approach is to price it based on the actual proof size that 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. On the other hand, I have a contract that has a million storage slots, which means a tree of depth, a large tree. And so each time that contract does a Sload, 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. Contracts that have a big storage would have to pay more for storage. It's also very hard to estimate because you can estimate for any time an Sload upcode 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 Sload will actually add to the block data. So we have these two approaches to storage upcodes. And then we have the contract code. So any time you do a call or an Xcode hash or something, the code for the whole contract that you're calling has to be included in the block, which can be quite a lot. Like if you imagine the limit for contract size is 24 kilobytes right now. So I can create a contract that does thousands of calls. And this would mean that I can... I think in his post, he estimated that 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're calling a contract that has 100 bytes, you would pay 300 gas for it. If it's a contract that has 24 kilobytes, then you would have to pay 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 mercilization route. So as I said before, we divide contracts into chunks, and then you would have to only pay for those parts of the code that were accessed during the transaction. So this would probably be cheaper, but it's also a more complicated approach. As I said, these are things that you shouldn't be assuming when you're writing a smart contract. You shouldn't assume the prices of op codes because these prices can change, and they could therefore possibly break your contracts, make them more expensive. You shouldn't rely at all, like try to not assume any gas prices. The other thing is, for now, you shouldn't assume a tree structure. For example, if you are doing a mercil-proof verification inside a contract, that assumption could break when we change the tree structure. And sometimes some of the dApps use receipts and logs as a way of storing things. This is also something that you cannot rely on, because I wouldn't be surprised if, in a few months, clients start pruning old logs and old receipts so that the user cannot access them. And this is something that I want to encourage. It would be nice to see more experimentation on. So what we've been so far discussing is stateless clients. This is a similar approach, but we call them status contracts. So even before Ethereum 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 a user sends a transaction, you send all of the Merkle proofs necessary, all of the parts of the tree necessary for that transaction with it. So let's say you want to develop a stateless token. You store the root, like you have a tree of accounts. In the leaves of the tree, you have balances of the accounts. You only store the root on-chain in the contract. And every time you want to do a transfer from user A to user B, in the transaction, you include the accounts for A and B and the Merkle 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 wrote here future proof because it doesn't use the default mechanism that Ethereum provides for storage. So even if up-code prices are increased, you won't be affected by it by much because you're only storing one item in the contract. And you probably won't be making assumptions about gas and so on. So, I mean, you can think that ZK-Rollup and similar contracts, they are stateless contracts. ZK-Rollup only stores one root, but the only difference to what I'm saying would be that they are doing all of this proof verification and transfer by zero-knowledge proofs. But you don't need the zero-knowledge proof, really. And something that could help with this approach is... I know some people like Guillaume Ballet and John Adler, they are working on pre-compiles for proof verification. And if these pre-compiles 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 gas or it could be based on how large your storage is. You shouldn't make assumptions about gas. You shouldn't rely on logs. And you should check out status contracts. Thank you, and are there any questions? Thank you so much. There was a great summary. Unfortunately, I missed following up on the whole topic more than I probably should have, so I got a ton of questions and maybe they're stupid. Yeah, no, no, sure, great. I have to say that I just wanted to... In the beginning parts, I kind of gave only a short summary of what Stateless Ethereum is all about, because if you're going to ECC, you will probably hear about it a lot. I just wanted to focus on the later part, which is how it affects you. Yeah, yeah. So when you talked about the witness that I need to transmit with every transaction, that basically my transaction becomes the whole witness and the actual thing that I want to do. So in the examples of the pricing, has it been considered that just the size of the witness would be somehow impacting the price? Because that seems like the clearest one to me. If the goal is to keep the block size at a certain limit. Yeah, that's here the second approach, like what I call witness-size sensitive pricing. It's basically to see how large the witness is and charge based on that. But the problem is that you cannot estimate exactly, like when you're executing the transaction, let's say you're running EVM byte codes. Like when you reach an S load, at that point you won't know how many other Merkle proofs would have to be included. Because the thing is like you can estimate the price of one Merkle branch. But at the end of the block, we are merging all of these into one big proof like this one. So you would get quite a lot of saving. 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. That means that the gas cost would be much higher than necessary. That brings me directly to my second question. How do I create that witness? Because if I now want to send a transaction from my wallet, I need to create that witness locally, I guess. This is like with the stateless client approach, you don't need to do that. You just send a transaction, the miner 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 include the proofs. They might need to include parts of the witness that's still being discussed. But the majority of the witness will be the responsibility of the miner. So how does that make the miner stateless? No, no, no, the miners will be stateful. 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, so 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 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 new kind of nodes that don't have high storage requirements, and we expect that, like, we will have miners that are stateful, and then you would have a lot of user, end user nodes that we don't have now, because users are now relying on Inferior, but instead of Inferior, you could run a stateless client which can process blocks fast and doesn't have a high storage requirement. So miners would be stateful. This is great. Thank you for that information. Can I just follow up with one more stupid question there? If I run then this new type of client that 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 Infura who actually has the full information. Yeah, so this is, again, like, I want to stress that, again, these are all in discussion. Like, it's not, I don't want to say that these are all clear at all or something, but so it will be the network structure would have to change, and the stateless clients would store parts of the state that they care about. Like, if I'm an end user, I would hold my own account or all of my accounts in my storage and the contracts that I most likely will interact with. And anytime that I'm missing part of the stick, like, let's say I want to interact with a new contract that I haven't interacted with before, then I ask the network, okay, so this part would be interactive. Like, I ask 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 only need this part of the state to be able to know, okay, what is my balance? What is this friend's balance? 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 other clients in the network can verify that they can pay gas. Okay, thank you. I hope that wasn't confusing. Very interesting. Thank you. Thank you, Sina, for awesome talk. Thank you.