tl;dr Yes we can BUT for a very popular custom use cases such as proving Ethereum blocks. For everything else NO, we can’t.

We often think about ZK-VMs in analogy with regular computers: prove whatever. Any program.

However, practically speaking, there is no such creature as ‘any program’. Let’s think about it:

Generally speaking,

• Programs are written in different languages.

• Languages are compiled into different ISAs (for virtual machines).

• ISAs are compiled further into the bytecode by different compilers.

All of those language/compiler setups require their own tooling.

So ‘prove whatever’ means prove a program in any language. And this is important because if we want to bring ZKPs (or even vanilla SNARKs) into ‘the real world’, we can’t demand from the world to re-write all existing software in our custom language or even in rust.

If we make a serious bet that ZKPs will be in high demand all over the world, we need to be able to prove Python, C, C++, C#, as well as Assembly, Ada, etc.

Most existing ZK-VMs either want you to write in rust or in their custom language. So if I have a let’s say C++ program and I want to benchmark it on all existing proof generation solutions I need to either rewrite it in rust or custom DSL.

Yes, hypothetically I can compile C++ into risc v. But the goal of benchmarking is to compare the state of art performance of different solutions. So it doesn’t make any sense to compare a polished and optimized approach to an almost DIY approach.

But well.. what if the program we want to prove is optimized for 32-bit x86 ISA? Or even worth – what if it is C# program that targets its own Intermediate Language (IL)?

If one day we see ZKPs becoming a mass market tech i.e. everything compiling into everything, we will need a lot of compilers. Building compilers is frustrating: it takes a lot of effort to build it and ensure it is secure, but at the same time it’s not a self-sufficient product. So it’s a half public good, half idk what. Reasonably compilers are usually built and maintained either by foundations or by commercial companies that need these compilers.

If one day we can prove the world, that zk tech adds billions/trillions value to the world – setting up and maintaining a foundation that will maintain variety of zk tooling is kinda doable. But we are very far from that point.

Most ZK-VM and zkDSL (frankly speaking all afaik), target one particular case of language —> ISA —> proof. If we want to deviate – we have to emulate. Emulation automatically means efficiency going down (have you ever run Linux on Mac?). But for an early stage technology such as SNARK generation the overhead is wild.

And it’s fine.

ZKPs and SNARKs are still an emerging technology. It just starts to feel the ground under the feet. The fact that there is almost no tooling and 99% of things are still in the air is an absolutely expected state of environment.

However, it means that today we can’t predict or estimate which ZK-VM or zkDSL will be the most performant for real world proving. Unless… one is capable of connecting dots very early.

Today we have maybe 27 ZK-VMs and some amount of zkDSLs. As a thought experiment, assume we want to build something long-term (assume it will last at least for 10y) and it’s not written in rust or from scratch. We need to prove some already existing programs and we can’t rewrite them.

How will we make this choice? Bet on the team.

Try to understand of the team is even targeting long-term real world proving? Or is proving Ethereum blocks the endgame? (You do not know for sure, and teams do not know for sure, but if talking to them long enough you can sense a bit the sentiment).

• Wait 10 years till ZKPs and SNARKs are (maybe) more ossified and then build. Advantages – more certainty, disadvantages – losing the early mover advantage.

• Find one particular use case and build custom proving for your particular use case (maybe partially reusing existing ZK-VM).

• Try to build general purpose ZK-VM for real. Just think from scratch unrelated to blockchain what is the most optimal way to design ZK-VM architecture and will it ever be really general-purpose. (this is wild, no sane people will be down, luckily enough, there are some insane people around).

• Look for the use cases that will be fine with rewriting the codebase.

• Look for the use cases where code is already in rust.

That list sounds kind of a bit depressive. That’s why I have one more suggestion.

Building ZK proving infra is hard, insanely hard:

• You are building state of art tech, you fail many times before things work and redo the same stuff several times in a row till it works properly.

• You do not know if it ever pays back.

• everyone tells you ‘damn one more zkvm lmao’.

However, to build zk and snark applications we need to be able to generate proofs in a reasonable manner. Otherwise we just have to build ZK-VMs on our own and I am telling you it’s hard, so we better avoid it haha.

1. Find teams you believe in (for your own reasons, because of how you have connected the dots) and tell them that you believe in them being the pioneer, being a long-term winner. Tell them you want to build with their tech, what you will build, how you see the long-term picture, how their tech powering your product will change the world. Even if all of that is still hypothetical, it gives energy and good vibes to continue working hard.

2. Do not fool the less educated crowd with benchmarking Fibonacci. Proving Fibonacci doesn’t tell you anything about proving real world programs. For most people who are not zk experts it’s not obvious. Do not fool them please. Let’s be honest with each other in the relations between zk infra builders and apps builders. We need each other to build long-lasting things that work.

When you build ZK infra in blockchain, you can raise 100M+ rounds. When you build application-layer products you can’t. When you build app-layer products, you make a pre-seed / seed of several millions so that you have a team of 6 really good builders and approx 1.5y to build a prototype that works enough to validate the use case and raise money to build the production stage product.

If your tech doesn’t work but you say ‘come come build on us’ – you betray the builders. Meaning that they will run out of time earlier than they will be able to deliver working prototype. If you hope that apps will help you building libraries, tooling or whatever just because they need it – you betray the builders because they do not have time for anything else except for building prototype that works. They rely on your tech to be able to generate reasonable proofs. Be honest. Be honest with what is possible today for real.

p.s. If I did my own bet on long-lasting zk tech, from everything I see around, I would bet on Lita, Irreducible, and Noir. Because of how i connect the dots: teams, approaches to worm, sentiments in the air. That doesn’t mean I am right. It’s purely a very biased mostly intuitive personal opinion. But I want to support these teams and say: I believe in what you do and one day I want to build ZK apps using your tech. Because I really think it has all chances to be world-chaning.