Zero-knowledge proofs

Tenzro Network 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

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 Tenzro Network verifies proofs once, outside the EVM, and lets contracts check the result cheaply:

1. A proof is submitted in an AttestZkProof transaction.
2. Every validator executing the block re-runs the verifier; a proof that does not verify fails the transaction.
3. A proof verified in an executed block has its commitment admitted to the on-chain ZK_VERIFY registry. Because it is part of executed state, every node agrees on it.
4. Contracts call the ZK_VERIFY precompile with the commitment, which is a constant-time lookup against the registry.

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.

Finality proofs bound to an attestation

A finality proof made on a confidential machine can carry evidence of where it was made. tenzro zk attest-finality-proof takes a wrapped finality proof made on the node's machine and binds it to an attestation of the node's TEE: the report data commits to the program, the journal, the seal and the prover. tenzro zk verify-tee-finality-proof admits the bundle only when the seal verifies, the prover is the published one, the signed report data carries the binding and the attestation itself verifies, and prints the measurement registers to compare with the published image measurements.

tenzro zk attest-finality-proof --proof proof.json --out bound.json
tenzro zk verify-tee-finality-proof --bundle bound.json --rpc https://rpc.tenzro.com

The methods are tenzro_attestFinalityProof (an open write that stores nothing) and tenzro_verifyTeeFinalityProof (open).

Using the CLI

# List circuits
tenzro zk circuits

# Create a proof bound to the verifier's challenge (prints a JSON bundle)
tenzro zk prove --circuit-id settlement --binding 0x<32-byte challenge> > bundle.json

# Verify the bundle
tenzro zk verify --bundle bundle.json

# Whether a commitment is in the attested registry
tenzro zk attestation --commitment 0x...

Verification over JSON-RPC (open method):

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

Related open methods: tenzro_createZkProof, tenzro_listZkCircuits and tenzro_getZkAttestation.

Related

• Finality certificates
• Cryptography
• VRF
• TEE