Ansgar Dietrichs

But if you are just a full node, just for hobby purposes, or maybe you're a validator on a very weak machine, you might be tempted to just, at that point, transition over.

So that will be the first step.

And then one thing we haven't really touched on yet is that, well, I guess a little bit, is that there's actually quite a few technical requirements that we need to hit before we can move the bulk of validators over.

And I can briefly go over those.

So one we already touched on, for example, is the block-in blobs, which...

will come at some point where we basically say, look, we now put the block into the data, so there's also the sampling aspect to it.

If you are a re-execution node, you still download all of it.

But if you now are a ZK node, you can start only sampling it, right?

But this will come after the initial optional proofs roll out.

So before then, a validator basically has to download the proof, but also has to download the full block still.

So it means they don't yet gain any bandwidth benefits.

They only get the IO and the compute benefits.

So basically, we have the block-in blobs that will have to come.

We have to have, in general, networking improvements that are in the works.

We have repricings, meaning we have to actually make sure that the parts of the Ethereum chain that are especially hard to ZK verify, we make a bit more expensive.

We basically rebalance the cost.

And then the most important

technical dependency for the mandatory proofs, the full transition basically, is actually, it's related to the statusness element.

And that's specifically that we need to transition the Ethereum state tree over to a new format.

Like long-term listeners might be familiar with this like elusive Verkle tree idea, right?