Ansgar Dietrichs

Because if you want to verify a block, you have to go and again, load all the data.

You have to have it all locally.

Once you have zkavm, that becomes optional because you don't actually need the data local to double check the validity of the block, right?

So what you can do is you can, in principle, what you could do is you could throw away the entire data, right?

So you can basically just, you can only keep like this root commitment and you can just always update the root commitment and that's it.

In practice, what you'd want is because Ethereum nodes have multiple functions, they also operate the Ethereum mempool, they have to understand validity of transactions in flight, all these kind of things.

What you'd want to do is you don't want to run fully stateless, you want to run in what we're calling partial statelessness.

So for example, there's this proposal called

LOPS, validity only partial statelessness.

So it means you specifically have a subset of the state and that can be defined by several different rules.

It can be, say, the balances of all the accounts or it can be, I don't know, if you are specifically interested in some state that belongs to you as the user or something, you can define what state you're interested in.

But basically, now you can keep a subset of the Ethereum state

And that's totally safe because of ZKVM, right?

And you only have to apply the diff.

You only have to go to disk.

You only have to have the IO overhead of updating that subset.

So that's the second, basically.

You have ZKVM for compute.

Now you have partial statusness for more optimized IO.

And also, by the way, for keeping your disk size contained.