The pluralist zkVM

These days there are a lot of zkVMs and zkEVMs. Yet, trying to find a system that does just what is needed is hard. Why is that so?

There are a bunch of things an application developer cares about. Verification cost, proving cost, proof size, zk property, recursion and aggregation, custom precompiles, front-end language, adoption and ecosystem, and so on. There is no single set of parameters that works for any application, yet each zkVM makes these decisions, the decisions that should belong to the application developer. The developer have to choose between the properties relevant to the user (say, best aggregation mechanism) and properties relevant to the application itself (say, supported host platform).

zkVM projects try to find the best solution, but there is no best solution.

zkVM I’d like to see is a higher-level entity. It is not a zkVM in the traditional sense, it is an abstraction over zkVM designs. It doesn’t make the application-relevant decisions or makes as little as possible of them. It has a simple interface, it is easy to deploy and use on any host platform and it can be customised to serve the needs of the application. The higher level interface can verify any proof produced by a parametrised instance of this zkVM, so we only need to host one thing - the pluralist zkVM.

The goal is to make available as many properties as possible. Do you need recursion? Do you want optimise for the verification cost? Do you want to utilise a custom precompile because your application heavily relies on it? You should be able to do it.

4 Likes