Introduction

=nil; Provable Queries enable safe and seamless data transfer between different protocol’s databases, which leads to zkBridging (first introduced for Solana and for Mina back in 2021) and Pluggable Scaling (aka Danksharding). Facilitated by =nil; Foundation’s Database Management System - =nil; `DROP DATABASE * it, moreover, provides a seamless access to different protocol’s data via provable queries. Some folks also call this a proof-based interoperability (ugh…). But! Such an access requires state and query proofs which have to be taken from somewhere, they shoud be generated by someone.

There is a couple of options regarding where to take them from:

1. Make those who maintain the data (so-called “validators”) to generate them themselves.
2. Split roles of data managers and proof generators so every party could focus on providing best in class services.

There is one more problem different kinds of proofs induce different production costs and in combination with the second option among those I’ve just mentioned, proof production becomes a Proof Market.

A Proof Market? But a proof is not an asset. Which market?

That is right, it is not an aset. It is a commodity. This means we’re talking about a proof generation market.

Considering proof generation market, there will be two critical points which will determine the market itself:

1. Proof generation cost.
2. Proof generation time.

Also! Since the supply of the proofs is supposed to be handled by entities dedicated to that (e.g. running specialised FPGA hardware), considerations for them will include:

1. Can I make it cheaper?
2. Can I make it faster?

This induces a competition between proof generators to provide a proof with a smallest latency or with a cheapest generation cost.

But it doesn’t mean a proof has to be sold at its production cost.

Right. A Proof Market is not only about proof generation cost, but also about proof generators being able to sell the result of its work and applications being able to retrieve proofs necessary for their functioning.

This means a proof can be sold and bought at a more expensive or some cheaper price than its production cost. And here we go, a traditional market-alike price structure.

But! There is also a nuance. A proof has an expiration time. This means there is also a generation time that matters a lot because some application might not need it after a certain amount of time has passed. Such expiration timings existense would, for example, result into rapid proof’s cost decline.

For example, Mina’s zkBridge using =nil; Proof Market requires for the Mina’s state proof not to be older than 15 minutes. Why? Simply because a bridge requires for the state to be relevant to the current Mina’s state and Mina’s replication interval is something about 15 minutes.

Does the fastest proof delivery means the highest price?

Nope, because in some cases there is no need in an early proof delivery. For example, Mina’s bridge proof requires to be submitted every 15 minutes. But no matter how fast you deliver it, next time it will be required will come in 15 minutes. This means sometimes there is no need to hurry and an application can pick a proof suitable in terms of cost.

But! This doesn’t mean proof generators cannot compete in terms of proof generation costs and timings ‘cause no matter of production costs, the final price is determined by the market.

But what about other circuit’s proofs?

Each proof is unique thanks to its inputs and its circuit. And since the circuit is what defines a type of a proof, it results in defining a “trading pair” (talking in a more finance-related terms). Moreover, the amount of circuits can be populated even more because of different proof systems.

For example, Ethereum’s light-client state proof, Solana’s light-client state proof and Mina’s state proof already create three “traiding pairs”. Having Solana’s state proof generated as a STARK results into a 4-th one. Another example is Ethereum’s state proof generated in Kimchi proof system would results into 5-th pair etc.

Another example, a =nil; `DROP DATABASE *’s query like SELECT ethereum.accounts, solana.accounts FROM ethereum, solana where ethereum.value = solana.value ran over Ethereum’s data table within the DBMS:

ethereum.accounts : STRING	ethereum.value : INTEGER
0xddeff411602b40885c2ae826a9b6e1403ca81813	2048
0x8ccd34fd7e8914ef27090a232fb704185ee3abac	512
0x254c3882e6f777e92ce763fc8e2096206b09fbb4	1024

and Solana’s data table within the DBMS:

solana.accounts : STRING	solana.value : INTEGER
8zJd5X6VqbTQNJ27QJ3cW5aCJy5UqKAcrPUe6HfBi1C3	2048
3C1iBfH6eUPrcAKqU5yJCc5Wc3JQ72JNQTbqV6X5dJz8	1024

would result into a following query plan:

PROJECT[ethereum.accounts, solana.accounts]
  JOIN[nation.regionkey = region.regionkey]
      TABLE[ETHEREUM, accountkey=varchar, name=char, valuekey=int, comment=varchar]
		TABLE[SOLANA, accountkey=varchar, name=char, comment=varchar]

Which! In its turn will be turned by =nil; zkLLVM into a separate circuit which become a separate trading pair on a proof market.

This means more of an auction model could seem suitable than an order book-based one. But! An order book-based one is a more generic one, it can handle auction-alike trades as well and sometimes there is no need in getting the proof right now (e.g. again Mina’s case - once in 15 minutes, remember?), which means an order book-based model is here to stay.

Do you suppose for users to come in to your service and trade proofs?

Proof Market runs as an application on top of a protocol maintained by =nil; Foundation’s Database Management System - =nil; `DROP DATABASE * native replication protocol. This means it is not a service, but more of, as some would call it, a “Proof DEX”.

And, of course, we do not suppose for all of the nodes of this to be ran by =nil; for several reasons:

1. A proof market requries an access to all the protocols data. Currently only =nil; `DROP DATABASE * is capable of providing necessary data accessibility level on a protocol level (i.e. being able to access various protocols’ data within a VM). This means a proof market turns out to be an application on top of a =nil; `DROP DATABASE *-based cluster.
2. A proof market requires for an order book to be maintained. This means an underlying protocol has to be performant enough with finality good enough to provide a proof market with an orderbook. =nil; `DROP DATABASE * provides such a protocol.
3. A proof market requires for its nodes to be ran by independent parties. This reduces potential order front running.

Okay, a decentralized set of proof generation sequencers this is, right?

That is true. Capable of proving circuits of a various size over various protocol’s data for different purposes:

1. Trustless (non-optimisitic) data retrieval and insertion. (aka zkOracles) Retrieve and insert the data from and to different databases (fault-tolerant full-replica included aka Bitcoin or Ethereum or whatever) through simple query language (SQL or JS-based one) without any need to trust data providers becuase of SNARK data correctness proofs.
2. Trustless bridging. (aka zkBridging) Use the data retrievied from the protocol and a SNARK correctness proof for putting the data from different protocols databases to each other. For example for Mina’s or Solana’s to Ethereum zkBridges. Another example is a zkBridge from Solana to StarkNet.
3. Pluggable trustless scaling (aka Danksharding for various protocol) Use the data retrieved from the protocol and a SNARK correctness proof to increase the throughput of a particular protocol by deploying several independent application-specific clusters.

Okay. How do I participate?

There are several ways to do that:

1. Becoming a proof generator. This means you would need to:
   1. Pick a circuit/a proof you want to supply (e.g. Solana’s state proof).
   2. Pick a suitable hardware for that (ask in Discord about those for now, we will arrange a typical hardware setups table).
   3. Install a Proof Market toolchain from our Github: https://github.com/NilFoundation/proof-market-toolchain/
   4. Follow the set up instruction in the repository.
   5. Ask further questions in our Discord (in a #proof-market channel) or in our Telegram group https://t.me/nilfoundation.
   6. Receive rewards for proofs sold.
2. Becoming a circuit design provider/developer This means you would need to:
   1. Develop a design of a circuit you want provers to prove. Get some inspiration from our zkLLVM’s examples directory: https://github.com/NilFoundation/zkllvm/tree/master/examples
   2. Pick a toolchain you want to use. Or course we would recommend the =nil; zkLLVM, but you’re free to pick any other one - ask hgedia in our Discord (in a #proof-market channel) or in our Telegram group https://t.me/nilfoundation about how to arrange such a thing.
   3. Build it and receive rewards for every proof generated from your circuit sold on a Proof Market.
3. Becoming a proof-consuming application
   1. In case you’re building a bridge - you can become a zkBridge via integration with Proof Market. A typical integration workflow is in progress of development, so it would be easier to reach out hgedia or nemothenoone in our Discord or @nemothenoone in our Telegram group https://t.me/nilfoundation for them to help you with that.
   2. In case you’re building a scaling solution (e.g. an Ethereum Rollup) - you can cheapen/fasten your proof generation via re-using state proofs from a Proof Market. You would need a little bit more than just a proof market. Makes sense to reach out Ilia Shirobokov or nemothenoone in our Discord or in our Telegram group https://t.me/nilfoundation for this.
   3. In case you’re building an application-specific rollup (e.g. Aztec Protocol or Dark Forest game), you would need a provable computations toolchain for that. zkLLVM is the first (we hope it will not be the only one) toolchain fully and properly integrated with the proof market and =nil; `DROP DATABASE * as a data source, which allows it to prove various protocol’s data along with extensive computations over it to any other supported protocol. It is worth pinging @nbering in our Telegram group https://t.me/nilfoundation or nemothenoone in our Discord regarding this use case.