Introduction
We anticipate the emergence of numerous decentralized prover markets in the near future. These markets are uniquely characterized by highly-available and highly-performant infrastructure, coupled with strong security and transparency guarantees.
This technical blog post serves as an addendum to our joint partnership announcement with Twinstake, a leading validator in proof of stake networks.
Background: The emergence of prover markets
Zero Knowledge (ZK) Rollups, e.g. Starknet and ZkSync, are being used today as a scaling solution on Ethereum. Their success led to a steadily growing demand in ZK proofs. Prover markets are a natural evolution for ZK Rollups as part of their transition towards decentralization. Led by this strong demand, we expect that over the next year ZK Rollups will become prime prover marketplaces, driving competition and lowering down costs.
These particular markets however, are somewhat limited in scope: Rollups can be viewed as “islands” on Ethereum, each catering to proofs of the same kind originating from a single rollup and ultimately settled on Ethereum. Addressing this fragmentation issue is an active area of development. Interoperability solutions like Polygon AggLayer and Espresso sequencer marketplace will contribute to more generalized prover markets, aggregating demand for various proofs across all Rollups.
If we take a higher level view we find that ZK Rollups are only one application of ZK technology, and Ethereum is a very specific target layer. In a broader sense, a decentralized prover market can serve multiple prover networks and target multiple layers, such as verification networks. Supporting a prover in such a multi-prover marketplace can be achieved with a modular structure that enables the addition of prover-verifier pairs, as demonstrated by Gevulot and Lagrange.
Recent advancements in ZKVM technology suggest a different approach based on a single prover capable of efficiently running multiple types of computations, similar to how a CPU runs various programs. Examples include RISC0 and Succinct. The innovation in ZKVMs is expected to continue, significantly enhancing the efficiency of ZK proofs.
Bottom line, there is one clear vision to guide all of these parallel efforts: to efficiently generate ZK proofs in a decentralized manner and transfer them from any source to any destination, enabling real-time verification of any computation.
Unique Characteristics of Prover Markets
There are not many things we know yet about the dynamics of prover markets. It is a new area to explore, on both design space and operations. The simple facts so far are that the prover market is unlike any existing market and no two teams share the same mechanism design. This means that until some standard will emerge, we expect more research and experimentation to follow in the near-term future.
To give some color into the challenges we can look into the transaction fee mechanism:
Prover markets differ from classical fee markets (e.g., that in Bitcoin and Ethereum) in three ways. Firstly, a prover market is a two-sided market where users demand proof capacity, and provers supply it. In a prover market, users have heterogeneous valuations of proof capacity, and provers may have heterogeneous cost and capacity (e.g., some provers may invest in specialized hardware that has low proving costs). This is in contrast to block space markets where validators’ cost to produce blocks is nominal. Secondly, compensating provers for their work would be essential, whereas fee markets do not aim to compensate validators… Thirdly, fee markets are usually not concerned with selecting validators (e.g., in Ethereum, validators are selected by the consensus protocol), but prover markets need to select provers from a group of candidates when there is a supply surplus. Ideally, this process will select the provers with the lowest costs, but provers need not report their true costs. source
As it is evident from existing design ideas, a common security requirement is for provers to stake before submitting bids for proof capacity or any form of active participation. This stake will be slashed if the prover is not functioning as expected. Here we also need to introduce the QoS and uptime usually required from Staking services. Therefore, participation in the new prover marketplaces may require at least two roles: compute provider and a validator.
A concrete example is the recently launched Lagrange prover network:
Already in this early market we can observe that stakers (in Lagrange these are re-stakers) now also have requirements on compute resources for proof generation. Our assumption is that to fully support this and other prover networks, we will need a new kind of infrastructure. This is what we set out to explore and the basis for our partnership with Twinstake.
Demo: Decentralizing ZkSync prover using ZaKi
ZaKi instances are our dedicated hardware infrastructure, optimized for running ZK workloads. In the demo below, we show how we took the ZkSync Boojum prover and ran it on ZaKi instances, replacing Google Cloud. In our setup, a user, for example a validator like Twinstake, is requesting some proofs from a remote ZkSync prover, operated by us, later to be submitted to the network. We configured our load balancer to work with two ZaKi machines, using two GPUs in each, demonstrating how we can utilize our infrastructure to run multiple proofs efficiently. Outsourcing proof generation to ZaKi, we benefit from faster running times and at lower costs compared to general or AI specific cloud providers.
Screen recording of NGINX load-balancing 4 ZKSYNC workloads. 1st row: use curl to submit 4 workloads to NGINX. 2nd row: monitor 4 different ZKSYNC containers (two servers, two containers per server). 3rd row: monitor NGINX log — distribute workloads to different servers/ports
These capabilities can empower validators to easily access high-performance compute: AI or ZK, and at scale. Together with Twinstake we are experimenting with different ways validators can take on responsibilities that involve heavy workloads.
If you are a builder working on such a network, please reach out to hi@ingonyama.com to collaborate with us.
