Is SP1 zero knowledge by default for every input?

SP1 keeps inputs private only when the program reads them as private witness data and does not commit them as public values. The proof binds the execution to the ELF, the private input, and any committed outputs, while the verifier receives only the verification material required by the selected mode. Logging, host-side storage, or explicit public-value writes sit outside that cryptographic privacy boundary, so the program’s input and output design determines what becomes visible.

Which operating systems support local SP1 development?

Native SP1 development supports Linux and macOS, while GPU proving requires Linux on x86_64, CUDA 12, and an NVIDIA GPU with compute capability 8.0 or higher. The prebuilt toolchain targets those platforms; Windows is not listed as a native target. CPU execution and mock or network flows need less memory than local SNARK wrapping. Groth16 calls for at least 16 GB, while local PLONK calls for 64 GB.

How long does a Prover Network deposit take to appear?

A PROVE deposit can take up to 5 minutes to appear in the Prover Network account after Ethereum confirmation and indexing. The wallet transaction and the network balance are separate states: the former settles the token movement, and the latter enables proof requests. If the balance remains unavailable, compare the requester address with the funded account before changing proof code, because an account mismatch leaves the program setup untouched.

Can one SP1 proof combine results from several programs?

Yes, SP1 recursion verifies compressed SP1 proofs inside another SP1 program and produces one aggregate statement. This pattern fits independent proofs from separate parties, block-range proofs, or computations that begin at different times. A single large program remains simpler when it fits the zkVM’s memory and cycle envelope, because every extra proof introduces setup and recursive verification work. The aggregation program must also commit the final public values that downstream verifiers expect.

What happens if the ELF and verification key come from different builds?

Verification fails when an SP1 proof and verification key do not correspond to the same ELF and supported circuit version. Setup derives program-specific key material from the executable, so rebuilding or changing dependencies creates a new compatibility boundary. Keep the ELF digest, verification key, circuit version, public-value schema, and deployed verifier aligned as one release unit. Regenerating only the proof does not repair a key mismatch from a different build.

Succint is the company behind SP1 proof generation

Succint is the applied cryptography company behind SP1, software that lets a verifier confirm correct execution without rerunning the program. Developers compile Rust or another LLVM-supported language into a RISC-V executable. SP1 executes it inside its zero-knowledge virtual machine and returns a cryptographic proof plus chosen public outputs. Local CPU or GPU proving supports development, while the Prover Network assigns production requests to external proving capacity and settles payment in PROVE.

Should a project use SP1 instead of a custom circuit?

Three conditions make SP1 preferable to a custom circuit: reusable Rust logic, compact verification, and acceptance of the proof system and setup assumptions for the project.

Succint fits when the computation already has reliable software semantics and changes often enough that maintaining application-specific constraints would slow releases. A bridge light client, rollup state transition, or cryptographic coprocessor reuses Rust crates and normal tests. Proof generation follows only after software checks pass. The verifier binds to the exact Executable and Linkable Format (ELF) binary and its verification key. Each program build therefore creates a compatibility boundary. That boundary matters during upgrades. Teams requiring the smallest possible constraint set or a proof system tailored to one stable function should compare a custom circuit before committing.

Local core or compressed proofs call for at least 16 CPU cores, 16 GB of memory, and 10 GB of disk; local PLONK wrapping raises memory to 64 GB. Those thresholds make network proving the practical path for larger workloads.

From a Rust project to a first proof

Five setup elements move an SP1 project from source code to its first proof: the toolchain, program crate, host script, execution report, and selected prover backend.

Install Git, Rust, Docker, and Protocol Buffers; prebuilt SP1 tools run on Linux and macOS.
Create a bare project, keeping provable code in the program crate and host logic in the script crate.
Compile the program into an RV64IM ELF that fixes the executable statement to be proved.
Execute before proving, then inspect public values, cycle count, and prover gas.
Select a local CPU, local GPU, or Prover Network backend, then choose the required proof mode.

The starter scaffold has 2 Rust crates. The program crate contains code executed by SP1, while the script crate handles inputs, setup, proof requests, and verification. Execute the ELF first because the report exposes both cycle count and prover gas without paying proof-generation overhead. For programs above 1 million cycles, execution-only iteration avoids repeated proof work during debugging. A network request then needs one secp256k1 requester key and a funded PROVE balance. It also needs one private-key environment variable. A deposit can require up to 5 minutes to appear before requests proceed.

Only values written to the public-values stream become verifier-visible commitments; private stdin remains part of the witness. The next benchmark should record program version, public-value schema, proof type, and prover gas together.

How does SP1 turn Rust execution into a proof?

Four transformations turn ordinary Rust code into an SP1 proof for downstream verification: compilation, trace construction, shard proving, and finally recursive compression or SNARK wrapping.

Execution and arithmetization

LLVM compiles Rust, C, or C++ into an ELF for the RV64IM instruction set. The SP1 executor runs that binary and records instruction and memory events. It then converts the trace into algebraic constraints. Inputs enter through SP1Stdin; outputs become public only when the program commits them.

SP1 Hypercube divides execution into shards of about 2 ²² RV64IM instructions, proves each shard, and checks memory consistency across shard boundaries.

Fixed parameter and value	Main failure mode
KoalaBear modulus - 2 ³¹ − 2 ²⁴ + 1	A field mismatch makes proof and verifier incompatible
Poseidon2 state width - 16 field elements	Different state dimensions fail verification
Poseidon2 S-box degree - 3	Nonlinear constraints no longer match
Poseidon2 schedule - 8 external and 20 internal rounds	Transcript commitments diverge during verification

Recursion and wrappers

Normalization gives differently shaped shard proofs a uniform recursive circuit. Compression then combines groups of typically 3 or 4 proofs in a tree until one compressed scalable transparent argument of knowledge (STARK) remains.

Core and compressed outputs

Core mode returns a list of STARK proofs whose total size grows with execution. Compressed mode recursively reduces that list to constant size, which suits off-chain verification and proof aggregation inside SP1.

Groth16 and PLONK wrappers

On Ethereum Virtual Machine (EVM) chains, SP1 shrinks the compressed STARK and wraps it as either a Groth16 or PLONK succinct non-interactive argument of knowledge (SNARK). This step creates the EVM-compatible endpoint. The verifier checks the program key, proof bytes, and committed public values without executing the underlying Rust computation.

Rollups, bridges, and verifiable computation

Four workload classes capture SP1’s main crypto uses across blockchain infrastructure: rollup state transitions, bridge light clients, off-chain coprocessors, and aggregation of proofs from separate computations.

An OP Stack proving deployment runs its state transition function outside Ethereum. It then submits a proof for contract verification. RSP uses Reth to model Ethereum execution in a type-1 zkEVM, while Tendermint light clients prove consensus updates for interoperability. SP1 Blobstream verifies Celestia data roots, while SP1 Vector relays Avail Merkle roots toward EVM contracts. In each case, the program ingests headers, state, or execution data, applies deterministic rules off-chain, and commits a compact result that a contract verifies.

Coprocessors move historical-state scans, signature checks, or heavy arithmetic away from an EVM contract and return a proof-bound output. Precompiles for Keccak, SHA-256, secp256k1, Ed25519, BN254, and BLS12-381 reduce proving work for recurring cryptographic operations.

Aggregation becomes relevant when a computation exceeds about 2 GB of zkVM memory, passes 120 billion cycles, or must combine independently timed proofs into one on-chain statement. That split determines whether compressed or SNARK output belongs downstream.

What determines proof cost and verification overhead?

Four proof modes determine SP1 cost and verification overhead: core, compressed, Groth16, and PLONK, with each successive layer producing a smaller or more compatible verifier payload. This is revisited in detail.

Core proving avoids recursive compression, but its proof list expands with program execution. Compressed mode produces a constant-size STARK for off-chain verification and aggregation. Groth16 output is about 260 bytes and verifies on an EVM chain at roughly 270,000 gas, while PLONK is about 868 bytes and roughly 300,000 gas. PLONK uses a universal setup, while Groth16 uses a circuit-specific ceremony. The appropriate mode follows from verifier location, latency budget, payload size, and setup preference.

PROVE settles Prover Network requests, while the final amount follows the base fee, total prover gas units (PGUs), winning auction price per PGU, and deadline. The network accepts compressed, Groth16, and PLONK modes, caps gas at 1 trillion PGUs, and limits request timeout to 24 hours. Prover gas combines cycle work with precompile-specific cost profiles. Two programs with equal cycle counts therefore need not consume equal proving resources.

Alternatives and boundaries for circuit selection

Three alternative routes frame SP1’s boundary: RISC Zero for another Rust-and-RISC-V zkVM, Cairo for a proof-native language and VM, or custom circuits for fixed logic.

RISC Zero also compiles guest code for a RISC-V zkVM and returns verifiable receipts. Teams should compare supported crates, proof composition, verifier targets, and operational tooling. Cairo replaces the RISC-V guest model with the Cairo language, Sierra and CASM artifacts, and Cairo VM, which aligns closely with Starknet development. Circom and Halo2 expose lower-level constraint construction. They demand more cryptographic engineering, yet they let a stable computation control arithmetization and proof structure more directly than a general-purpose VM.

SP1 proves that the selected ELF executed consistently; it does not prove that business rules, input provenance, or public-output encoding match an application’s intent. A changed ELF also changes the program verification key, while verifier contracts and proof artifacts must share one supported circuit version.

Choose the VM after freezing three interfaces: source-language boundary, public-value schema, and verification environment. That choice reveals whether reusable software, ecosystem alignment, or hand-tuned constraints carries the highest maintenance cost.

Still have questions?

Is SP1 zero knowledge by default for every input?: SP1 keeps inputs private only when the program reads them as private witness data and does not commit them as public values. The proof binds the execution to the ELF, the private input, and any committed outputs, while the verifier receives only the verification material required by the selected mode. Logging, host-side storage, or explicit public-value writes sit outside that cryptographic privacy boundary, so the program’s input and output design determines what becomes visible.
Which operating systems support local SP1 development?: Native SP1 development supports Linux and macOS, while GPU proving requires Linux on x86_64, CUDA 12, and an NVIDIA GPU with compute capability 8.0 or higher. The prebuilt toolchain targets those platforms; Windows is not listed as a native target. CPU execution and mock or network flows need less memory than local SNARK wrapping. Groth16 calls for at least 16 GB, while local PLONK calls for 64 GB.
How long does a Prover Network deposit take to appear?: A PROVE deposit can take up to 5 minutes to appear in the Prover Network account after Ethereum confirmation and indexing. The wallet transaction and the network balance are separate states: the former settles the token movement, and the latter enables proof requests. If the balance remains unavailable, compare the requester address with the funded account before changing proof code, because an account mismatch leaves the program setup untouched.
Can one SP1 proof combine results from several programs?: Yes, SP1 recursion verifies compressed SP1 proofs inside another SP1 program and produces one aggregate statement. This pattern fits independent proofs from separate parties, block-range proofs, or computations that begin at different times. A single large program remains simpler when it fits the zkVM’s memory and cycle envelope, because every extra proof introduces setup and recursive verification work. The aggregation program must also commit the final public values that downstream verifiers expect.
What happens if the ELF and verification key come from different builds?: Verification fails when an SP1 proof and verification key do not correspond to the same ELF and supported circuit version. Setup derives program-specific key material from the executable, so rebuilding or changing dependencies creates a new compatibility boundary. Keep the ELF digest, verification key, circuit version, public-value schema, and deployed verifier aligned as one release unit. Regenerating only the proof does not repair a key mismatch from a different build.