Ansgar Dietrichs

Like it might be that you're still running this explicit split of two clients, like the consensus layer client and the execution client, but the execution client's role is very different now.

It basically just verifies the proofs

The one that you run locally, right?

That just verifies the proofs and does some maybe like mempool networking, that kind of stuff, state management.

But inside of the proof lives the CK program that was also derived from an execution layer client.

So if you think about the roles of clients now, basically it means that

the main question is like, what about the diversity within those proofs, right?

Because the outer system we are familiar with, but what about the diversity within those proofs?

And so the nice thing is that in principle, you kind of, you get a very

comparable very parallel type of mapping where you can just you know you don't just take a single execution client and compile it into RISC-V you take multiple so you know you basically you take kind of you know the existing ones you know or like also there's a few ones that will be specially written for that use case

You compile all of those.

And then to make sure that the redundancy is full stack, not just the first half of the stack, you also have multiple of these proving systems that take RISC-V, because of course they could also be bug in that part of the stack, right?

Like they take the RISC-V and prove over it.

So you say you have like, as an example, five of each, right?

You have five execution layers that can be compiled into this RISC-V, and then you have five different proving systems.

And what you can do is you can basically...

build pairs of those.

So you can say, and Justin has this really nice idea where you can even, you could in principle even like say performance match them.

So maybe the fastest execution client is paired with the slowest proving system.

So you basically, so the pairs kind of balance each other out, but that's just an idea.