Ethereum is at a critical juncture in its development. Many layer-2s are of the same mentality of copy and pasting their architecture and have not innovated over key blockchain problems such as parallel execution or state growth. If Ethereum is to compete with other alternative high performance blockchains, it has to solve for state growth. This talk will explore the landscape of state minimized layer-2s and show how Ethereum will be able to go beyond the state problem with non-EVM based design.

Stage 1

Nick is the CEO of Fuel Labs and is the builder behind Fuel V1, the first Optimistic Rollup on Ethereum Mainnet. A long-time Ethereum community member and one of the first users of Solidity. Nick has presented multiple times at DevCon on topics from decentralized crowdfunding to DAO governance.

Nick Dodson

State Minimized Layer-2s and Why Ethereum > EVM

 All right. Okay. So I'm going to be very, very fast. I have, like, more than 30 slides, and there's five minutes. So I'm going to have to make this work. It's fine though. A lot of this I can kind of skip. So today we're going to be doing state minimization and why Ethereum is greater than the EVM. So components of a blockchain, just to review quickly, you have this area of a blockchain node that would be, you could think of as state, state being these things that you need to both verify things and propose new blocks into a blockchain. Then you have things like execution, largely what we do with the CPU and RAM, sometimes a GPU if you're going to do GPU acceleration. Then you have data. And in this case, I'm just calling it data, which is just sort of the data you communicate over the internet to basically get everyone else in sync and, you know, kind of progress things forward and ensure that it's actually, you know, a system we can all use. So in many senses, on the data side, we have some solutions. On the execution side, we also have a lot of solutions. On the state side, though, you don't really hear about this problem very much. And you don't hear about it because a lot of people don't really have any good solutions. So that's why this talk is, you know, kind of interesting and also fun. So on the execution side, we've got all kinds of things coming out. Parallel transaxle execution is becoming more normalized. You know, you have the SVM. You have, as well, things like stylus, you know, dropping into WASM, stuff like that, as well. My project, FuelVM, we have our own virtual machine that helps with this. You know, and there's all kinds of different ways we can alleviate execution. Data has also been somewhat solved as well. So we post data now as roll-ups. We can post them over Ethereum, right, on EIP-4044. There's all kinds of sharding designs. There's all kinds of different kinds of DA layers that are coming up. So there's lots of solutions in that camp. But with state, there isn't really a lot of solutions. And so when we're talking about state, you kind of have a bunch of information that you really need to store in order if you want to progress things forward, right? So with Bitcoin, you have like the active UTXO set, the unspent UTXOs. With Ethereum, you have things like the account balances, smart contract code, smart contract state, token balances, et cetera. So there's a lot of stuff there. And Ethereum state system is quite interesting, but it's very, very, what you could say is really difficult to deal with. It's very difficult to optimize around. So you'll see there's a lot of different layers to how we're actually both taking this sort of key value store we have with Ethereum that we call like S-door, etc. when you're in contracts and how that filters all the way back up to single state roots, single succinct state roots within block headers. And it's quite enormous, the amount of state that's accrued here. So when we talk about scalability and we talk about state, a lot of people just blame the clients, they blame Geth, they blame these kinds of things like, why don't we just up the gas and screw everything, let's do it. And the thing is, Peter's already addressed this quite well, which is effectively that you can't just do this. And it's not slow because of Geth, quite frankly. It's not slow because of our clients. It's slow because we're all actually, or some people are very, very concerned about the state growth itself, right? And the requirements that puts onto things. And, you know, one way you could even look at state growth here is just like, I believe this is just the accounts on Ethereum, but you can just see that like, you have a ballooning of information. And all of these accounts have to be Merkle-ized, so it's really, really intense in terms of the amount of storage that we need to hold within Ethereum. So how can we address state growth? Basically, there's a bunch of different solutions for this. We can go on and on about it, but some ones that have been proposed before, right? State rent. There's also statelessness, which is sexy to say, but there isn't really a lot of great things underneath the hood for it. Unmerkleizing the state, so you just YOLO it like Solana does. As well, app level compression, so doing things at the application level. You can also just let it grow and maybe we just keep adding hard drives. Verkle trees, you also have some nice things here, right, where they kind of compress a certain amount of state using other techniques, but still pretty messy. And then we have another option, which I'll talk about at the end, which is bandwidth. So basically with state rent, we've all kind of heard this one before. You state, you rent it out, et cetera. Statelessness, just trying to do more things just kind of away from Ethereum state system. Unmerkleizing the state, it's not really a great approach as well. Application level techniques, you can do things more in call data, more things at the application level, but it's still not a great system in general. Here's Tully basically saying, I don't know, here's a bunch of options, but I'm not really sure. Here's Verkle trees, and again, Verkle trees, not really the best solution, because there's still a ton of state that gets accrued, right? So, alt VMs, again, Tully's system, not that great. Fuel state philosophy, we'll go into it in like two minutes, or like one minute, and then we'll go to questions. Thanks. So, fuel state philosophy is very different. We actually don't have any global state trees. We also use a system of native assets. We use UTXOs. We have as well different kinds of models to use state, but use it in the right way. We try to move a lot of the state that's typically within Merkle trees into an area which you would consider bandwidth. And in bandwidth, we actually have a lot more room to play with because everything, once you've moved it over bandwidth and kind of done the proving, then effectively you can just trim it. So there's a lot of really nice things you can do. So applications can be designed in a new technique that we have, which is called native state rehydration. And this really means that across our system, we have different techniques to basically create applications and different techniques to effectively remove state from the system and keep it very lean. These are basically, in our system, scripts, predicates, native assets, and a transaction model. I only have three seconds left, so I'm just going to skip through this. Again, UTXO model is very, very powerful in this setting, and it provides a lot of different options. And this is why in my super crazy lightning talk, I hope you guys enjoyed that. Ethereum, fuel is on Ethereum. It's a layer two. And Ethereum is much greater than the EVM with all these state problems. So thank you. Okay, cool. We have 40 seconds for one question. What about state expiry? What also keeps state in check? Yeah, so kind of, but again, you have this intense problem of a massive run-up of state. The problem with state expiry is that it's not so much that you can or can't do it. It's that basically once it expires, you would need a good system to then refill that state. And it helps, but I would say that there are better techniques where, again, you can use bandwidth. Over bandwidth, you kind of store things, and then once you've kind of consumed that or other people have consumed it, then they can bring it back only whenever they need it. You could say that's kind of like expiry, but I think expiry is too simple. You need a way to both kind of use state and then rehydrate state and then basically take it away. So in Fuel we have really nice systems for this.

https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/6736d2581b0f83434d6a4c04.vtt