Trustlessness (data access, bridges, scaling) needs proofs.
Written by Mikhail Komarov on 19 Jan 2023
=nil;’s 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;’s Database Management System - ‘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:
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.
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:
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:
This induces a competition between proof generators to provide a proof with a smallest latency or with a cheapest generation 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;’s 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.
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.
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 ‘DROP DATABASE *’s query like
SELECT ethereum.accounts, solana.accounts FROM ethereum, solana where ethereum.value = solana.valueran over Ethereum’s data table within the DBMS:
0xddeff411602b40885c2ae826a9b6e1403ca81813 2048 0x8ccd34fd7e8914ef27090a232fb704185ee3abac 512 0x254c3882e6f777e92ce763fc8e2096206b09fbb4 1024
and Solana’s data table within the DBMS:
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;’s 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.
Proof Market runs as an application on top of a protocol maintained by =nil;’s Database Management System - ‘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:
That is true. Capable of proving circuits of a various size over various protocol’s data for different purposes:
There are several ways to do that:
hgediain our Discord (in a #proof-market channel) or in our Telegram group https://t.me/nilfoundation about how to arrange such a thing.
nemothenoonein our Discord or
@nemothenoonein our Telegram group https://t.me/nilfoundation for them to help you with that.
nemothenoonein our Discord or in our Telegram group https://t.me/nilfoundation for this.
@nberingin our Telegram group https://t.me/nilfoundation or
nemothenoonein our Discord regarding this use case.
It will be published after moderation.
An error occured during adding your comment!