Zero-knowledge proofs

Plonky3 STARKs on Network 1: what they prove, how proofs are verified and committed on chain, and how to create and check one.

Tenzro Network 1 uses STARK proofs built with Plonky3. A STARK lets someone prove that a computation was carried out correctly, or that they know a value with some property, without the verifier redoing the work or seeing the private inputs.

Why STARKs

No trusted setup. There is no ceremony and no secret parameters that could be leaked.
Quantum-safe assumptions. STARK security rests on hash functions, which fits a network whose signatures and finality are quantum-safe.
Transparent parameters. Proofs use the KoalaBear prime field (2^31 - 2^24 + 1), Poseidon2 hashing and the FRI commitment scheme, with a fixed, published configuration.

What is proven

Use	What the proof shows
Finality certificates	Tenzro DAG Consensus (TDC) certificates are compressed with STARK proofs, so light clients, bridges and new nodes can check finality compactly. See Finality certificates.
Settlement (`settlement` circuit)	A settlement is valid: the payer's balance covers the amount and the payment nonce follows the previous one, without revealing the balance.
Identity (`identity` circuit)	The holder has a capability and a reputation above a required minimum, without revealing the capability set or the actual reputation.

Proof format

A proof travels as an envelope with four fields:

Proof {
  proof_bytes     serialised Plonky3 STARK proof
  public_inputs   list of public inputs, each as 4-byte little-endian field elements
  proof_type      plonky3
  circuit_id      "settlement" | "identity"
}

Each proof has a commitment that binds the circuit, the proof and every public input:

commitment = SHA-256( circuit_id || proof_bytes || for each input: len_le(input) || input )

Substituting different public inputs produces a different commitment, so a commitment cannot be reused for a statement it does not cover.

How proofs reach the chain

Verifying a STARK inside the EVM would be expensive, so Network 1 verifies proofs once, outside the EVM, and lets contracts check the result cheaply:

A proof is submitted for verification.
Validators each re-run the verifier independently and publish the proof to the data-availability layer.
Once a supermajority of validator stake has verified it, the proof's commitment is recorded as attested.
Contracts call the ZK_VERIFY precompile with the commitment, which is a constant-time lookup against the attested set.

Fraud window

An attested commitment stays open to challenge for a fixed window of finalised blocks. Any staked party can file a fraud proof; nodes fetch the proof from the data-availability layer and re-run the verifier. If it fails, the commitment is withdrawn and the validators who vouched for it are slashed.

ZK proofs inside a TEE

An enclave can generate a STARK and sign its commitment with a composite hybrid key (a classical key plus ML-DSA-65). Both signatures must verify. This combines a proof about the computation with evidence about where it ran.

Using the CLI

bash

# List circuits
tenzro zk circuits

# Create a proof from a witness
tenzro zk prove --circuit-id settlement \
  --witness '{"payer_balance":1000,"amount":250,"nonce":8,"prev_nonce":7,"service_proof":123456}'

# Verify a proof
tenzro zk verify --circuit-id settlement --proof <hex> --inputs '["0x...","0x..."]'

# Read the fraud-window record for a commitment
tenzro zk attestation --commitment 0x...

# Challenge an attested commitment
tenzro zk file-fraud-proof --commitment 0x...

Verification over JSON-RPC (open method):

bash

curl -s https://rpc.tenzro.xyz \
  -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"tenzro_verifyZkProof","params":{"circuit_id":"settlement","proof":"0x...","public_inputs":["0x..."]}}'

Related open methods: tenzro_createZkProof, tenzro_listZkCircuits, tenzro_getZkAttestation and tenzro_fileZkFraudProof.