Ansgar Dietrichs

And I think similarly, maybe even to a larger degree with ZKVM, as we'll discuss, it's

It actually, it has this nature of it's an ongoing transition that is basically about to start.

Then we will have the main hard fork and then it will continue after.

So it's much more like a ongoing transition.

But yeah, let's dive in.

Yeah, so I think, you know, to understand this, like really kind of you have to start from the problem statement, right?

So ZKVM really arose in the context of scaling and basically the fundamental point is that a blockchain, if you run a blockchain, you have these three primary constraints.

You have the data, right?

You have to first, like any new block you create, it has to...

get to the user, then you have the IO, you have to, like, then go to disk, you have to get all the data you need to actually, like, then verify the block, and then you have the actual verification, the execution, the compute, right?

So those are, like, the three main constraints, the bandwidth, the IO, and the compute.

That's any blockchain, no matter the design, those are the main constraints.

And so...

If you want to scale this, you can just do the thing where you take that and you just scale it up.

And we'll talk about this in a bit.

That's actually, to some degree, what we're doing in the short term.

And that's what many other chains have been doing.

That's a very natural thing.

But you do run into limits.

You do run into tight limits.