Interacting With The Network
Get started with NovaNet's p2p proving network.
NovaNet is a peer-to-peer network designed for decentralized coordination and incentivization of zero-knowledge provers. Unlike zkEVM or zkL2, its primary focus isn’t on scaling Ethereum but on enabling privacy, scalability, and verifiable compute across diverse applications. With NovaNet, there’s no verifier lock-in—you can post proofs to your choice of an L1 blockchain or even a Web2 server, making it uniquely suited for privacy-focused use cases.
The network’s tokenomics, escrow, and payouts are managed via blockchain smart contracts (ERC20). Developers initiate proving jobs by depositing funds into an escrow contract. NovaNet estimates the computational effort based on the WASM execution trace and provides a cost estimate for review. If the developer commits, the network coordinates the proving process through its peer-to-peer layer. Once the proof is verified, funds are distributed among participants, either evenly or with premium options for specialized provers.
NovaNet balances performance, flexibility, and cost-efficiency, allowing developers to create scalable, privacy-preserving applications. By enabling decentralized proving and avoiding centralized lock-in, it fosters an open, permissionless ecosystem for zero-knowledge computation.
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
Traditional systems often assume that adding more provers automatically lowers costs for users. However, the actual cost is primarily determined by how inexpensive it is for a single prover to post a proof to the L1, whether aggregated or not. Fast proving schemes like STARKs, Plonky, and JOLT often come with higher on-chain verification costs. NovaNet addresses this by wrapping various proving schemes within a NovaNet aggregation circuit, which posts a single, "cheap" proof on-chain, significantly reducing verification expenses.
In NovaNet, proving costs are not directly tied to the number of competing provers. Developers have the flexibility to control proof sharding and opt to pay a premium for specialized provers when needed. Want to involve 10 provers? You can split the workload, reducing effort for each prover while sharing the total price. Costs are determined by the total opcode count, current network conditions, and the expense of posting the final proof to your chosen L1.
For applications with bottom-up use cases, such as user-driven participation in zk-enabled apps, costs depend on the total aggregated opcodes and the final proof posting cost, not the total number of provers in the network. NovaNet’s incentive structure strikes a balance, rewarding specialized provers while keeping on-chain verification costs low—offering developers unparalleled freedom and flexibility.
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
