Interacting With The Network
NovaNet is a peer-to-peer network for the decentralized coordination and incentivization of zero-knowledge provers. Its aim is to reach optimal outcomes in prover speed and costs while allowing for unmatched liveliness and modularity. It differs to zkEVM or zkL2 in that fact that its primary goal is not to scale Ethereum, but rather more generally for use in privacy, scalability, and verifiable compute. Unlike many zkL2, you can use NovaNet for privacy applications. There is no verifier lock-in so you can post proofs onto your choice of L1 or even onto a web2 server.
Tokenomics, escrow, payouts, and other details are handled by blockchain smart contracts (ERC20). A developer who wants to prove using NovaNet adds funds into an escrow contract on blockchain. The network then estimates the work by counting the cycles in the WASM execution trace. It then returns that estimate for the developers review. If the costs seem appropriate the developer can commit to the proving job. Or if they decide to cancel their job before work has been conducted they can at this time. A small fee will be taken and the funds returned out of escrow.
The smart contract is signaled upon completion of a proof by the peer to peer layer (NovaNet). After a proof is verified, the smart contract sends funds to participants who helped complete the proof. By default this is divided evenly among participants. But there is a 'premium' option to use specialized provers when needed. In this case the specialized provers earn a percentage overhead over the default price.
Top-Down and Bottom-Up
You can use NovaNet to parallelize proofs across many nodes. In this case privacy is not possible as parts of the proofs will run across many nodes in the network. We call this the 'top-down' use-case. Examples are zkBLS or zkECDSA where verifiable computation is the main goal. You can also use NovaNet for aggregating privacy proofs, this is called 'bottom-up' proving. Your nodes (gamers, local DeFi, DePin), will be joining as provers in the network. This could be 5,000 gamers who all want to run a proof locally and benefit from the aggregation and amortization done in NovaNet. In this case, the opcode amount should be contained to a reasonable amount for local proving. Fixing bad assumptions:
Prior systems have assumed that more provers means de facto cheaper prices for users. While in fact the real cost is actually a function of how cheap it is for a single prover to post a proof to the L1 (this can be an aggregated proof or not). Very fast proving scheme (STARKs, Plonky, JOLT) tend to have more expensive on-chain verification. With NovaNet you can use various proving scheme while paying lower costs, as those verifiers are wrapped in a NovaNet aggregation circuit that is responsible for posting one 'cheap' proof on-chain.
The cost of proving is not directly correlated to the amount of competing provers in the marketplace. You as the developer can pick the amount to shard your proof, and decide on paying a premium for specialized provers where needed. Want 10 provers? You can have them. The provers have less work and therefore split the total price. Price is determined by opcode amount, current network conditions, and the cost to post the final proof on your preferred L1.
In the bottom-up use-case the provers are participants in your application. Your estimate has nothing to do with amount of provers in the network in this case, rather the total opcodes aggregated and the cost of the final proof to be posted onto the L1.
NovaNet creates an incentive structure for specialized provers while keeping on-chain verification costs low; i.e. developer freedom of choice.
Commands
Estimate
You first send a minimal balance to the smart contract to generate a job ID from parameters. Parameters include the WASM byte code, start and end opcodes, function to invoke and arguments that are passed into that function. Parameters are concatenated into a byte array and a random key is also generated and concatenated into the byte array and the byte array is hashed, producing a Keccak-256 checksum which is the job ID. All following commands, whether estimation or proving, require you to pass the same job parameters and key that were used to generate the job ID. Getting an estimate does not require you to commit to running the job, but rather returns basic details from the network such as estimated costs & amount of nodes required.
This command returns an estimation based on the execution trace size (in # of opcodes) and current network conditions.
This command also returns an estimation based on the execution trace size (in # of opcodes x amount of provers) and current network conditions. The --num-provers option is used later to determine when the job should be finished. The --num-aggregations option specifies the interval at which the ON should aggregate proofs and it must be a multiple of --num-provers. If, e.g., --num-provers is 6 and --num-aggregations is 3, aggregation triggers for every other proof and the client is sent three SNARKs.
In the following: NODE 1 is the orchestrator node. Any node can take up this role.
Lets prove our WASM (Top-Down)
You must transfer the estimated amount from the last step into the smart contract after which you can proceed to the next step — proving your WASM.
To run a proof with the default parameters.
The user commits to the job and estimated costs. This returns `success` when the network starts on the proof.
Optionally prove --finalize can be run which will block until the job is finalized and the proof is received. The proof is serialized to JSON and stored on disk.
By default the job will be sharded among a predetermined amount of provers for the amount of opcodes in the WASM byte code. Alternatively, you can choose the amount of provers to be used using the --shards option. If there aren't enough provers in the network to accept the requested shard count, ON rejects the job and you must try with a lower value.
Lets prove our WASM (Bottom-Up)
Nodes will need to join the network via the NovaNet executable. This is available as an addition to your project via the RustSDK or directly (browser, etc) with our WASM compile.
Run this command to start aggregating proofs from the local nodes. The --orchestrator option specifies the on-chain address of the ON to whom the proof should be sent when it's ready. --key must be provided so the ON can verify that this proof belongs to an active and funded job.
You can keep this running to see when N out of N proofs has been completed. With N being the amount_of_provers that was set in the estimation process.
Lets get our data out of the network (Top-Down)
To download proof data and complete verification.
with the --endpoint options a developer can select an endpoint to send the proof data for verification. This could be a custom smart contract or verifier endpoint. This step is not needed If --finalize was passed into the prove command (prove --finalize) as it will automatically download the proof.
*The verifier code will be open-sourced. It can be made to run anywhere Rust can run. We expect verifiers to come online as ETH smart contract and various other platforms in the near term. If you need a solution now for L1 interop reach out as we have solutions.
Lets get our data out of the network (Bottom-Up)
After the bottom-up has been funded on L1, bottom-up provers can start proving and sending proofs to the selected ON. The job creator can download the aggregated proofs as follows:
Where --orchestrator specifies the on-chain address of the ON that was selected for the bottom-up job, --job-id specifies the calculated ID of the job and --token specifies an authentication token which allows the connecting client to authenticate their proof downloading request.
The ON selected for the job accepts as many proofs and aggregates them as many times as was requested in the L1 job funding event. For example, if the client specified 6 proofs and 3 aggregations, the ON aggregates two proofs, sends the SNARK to client and waits for another two proofs to be received. This process continue until all proofs have been received and aggregated. The proofs produced by novanet download-proofs are stored on the client's disk.
Prove parameters
Following is a list of optional parameters a developer can choose from for the `prove` step.
specialized -type
Sometimes problems are best solved by specialized machines. These large and powerful machines are available for use in NovaNet. This option reduces decentralization and most of the speed from parallelization. -type determines the type of special prover. A full list of these provers will be provided after testnet (JOLT prover, zkML prover, etc); A smart contract manages this list.
Last updated
