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 into the smart contract to get your 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 'amount_of_provers' option is used later to determine when aggregation should be complete.
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. It will return an init_id which lets you know that you can go 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 run the finalization step automatically.
By default the proof will be 'sharded' among a pre-determined amount of nodes for the amount of opcodes in the proof. Alternatively, you can choose the amount of provers to be used using the `shard` option.
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.
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
To download proof data and complete verification.
with the '-target' command a developer can select an endpoint to send the proof data for verification. This could be a custom smart contract or verifier endpoint. *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.
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
