Zero-Knowledge Proofs over KoalaBear

Abstract

Tenzro Network proves and verifies zero-knowledge statements with Plonky3 STARKs over the KoalaBear field, hashed with Poseidon2 and committed via FRI. The system has no trusted setup, no per-circuit ceremony, no per-circuit proving keys, and no toxic waste — every proof is transparent and post-quantum-conjectured sound. Three domain-specific AIRs (Algebraic Intermediate Representations) ship with the testnet: inference, settlement, and identity. All three prove and verify under one pinned TenzroStarkConfig, so the cryptographic surface area is small and reviewable.

On-chain verification uses a commitment-attestation model: validators run the full Plonky3 verifier off-EVM and record a 32-byte SHA-256 commitment of each verified proof in an on-chain registry. The EVM ZK_VERIFY precompile (address 0x1006) becomes an O(1) HashSet lookup against that registry. This keeps consensus-time verification cheap without sacrificing soundness — the proof is fully verified by the validator that observed it; the registry simply records that a quorum agrees.

A hybrid ZK-in-TEE execution path combines the same Plonky3 proofs with hardware attestation: the witness is computed inside a TEE enclave, the prover runs inside the enclave, and the resulting proof is signed with the enclave's hardware-rooted Ed25519 key. Verifiers see both a STARK proof and a TEE quote bound to the same statement, providing defense-in-depth.

1. Introduction

Zero-knowledge proofs let one party (the prover) convince another (the verifier) that a statement is true without revealing any information beyond the validity of the statement itself. Tenzro Network uses ZK proofs to enable:

• Verifiable AI inference without revealing model weights, inputs, or outputs
• Private payment settlements that prove correctness without exposing transaction details
• Anonymous identity attestations demonstrating capabilities without revealing credentials
• Cheap on-chain verification via commitment-attestation, decoupling cryptographic verification from EVM gas cost

The system targets the AI economy, where autonomous agents transact continuously and verification cost dominates verifier-side budgets. STARKs over a small prime field with Poseidon2 hashing are well-suited to this regime: provers and verifiers share a single algebraic structure, hashing is cheap inside the constraint system, and FRI proof sizes scale logarithmically with trace length.

2. Proof System Architecture

2.1 Plonky3 STARKs

Tenzro uses Plonky3 — Polygon's open-source STARK toolkit — pinned at git revision 32079474b1d31d9221656ae774afb322d2597db0. Plonky3 provides the AIR-to-trace pipeline, the FRI commitment scheme, and the Fiat-Shamir challenger. All Tenzro circuits build on Plonky3's p3-uni-stark proof system, which gives:

• No trusted setup: Transparent — every parameter is publicly derivable from the field, the AIR, and the FRI configuration. No ceremony, no toxic waste.
• Post-quantum-conjectured soundness: Security rests on collision-resistance of Poseidon2 and the FRI low-degree test, both believed to resist quantum adversaries.
• Logarithmic proof size: ~64–128 KB for the Tenzro AIRs at trace heights up to 2²⁰.
• Fast verification: 5–20 ms on commodity hardware for the pinned testnet config.

2.2 KoalaBear Field

The base field is KoalaBear, the 31-bit prime p = 231 − 224 + 1. KoalaBear has two-adicity 24, meaning multiplicative subgroups of size up to 2²⁴ exist natively — more than enough headroom for any Tenzro trace. Poseidon2 round constants are tuned for the d = 3exponentiation S-box, the natural fit for KoalaBear's arithmetic.

For challenge generation and FRI work, the system lifts to a degree-4 binomial extension BinomialExtensionField<KoalaBear, 4>. Combined with the FRI conjectured soundness bound (see §2.4), this yields ≥100-bit security at the testnet parameters and room to push higher at mainnet hardening.

2.3 Poseidon2 Hashing

Poseidon2 is the only hash function used inside the proof system. It serves three roles:

• Merkle leaf hash: A padding-free sponge over Poseidon2 width 16, rate 8, capacity 8, output 8.
• Merkle compression: A two-to-one truncated permutation over Poseidon2 width 16.
• Fiat-Shamir transcript: A duplex challenger over Poseidon2 width 24, used to derive challenges from prover messages without an interactive verifier.

Both permutations are constructed from the bundled default_koalabear_poseidon2_16 and default_koalabear_poseidon2_24 helpers. Round constants are baked into the constructors — there are no local secrets to audit, and config builds are bit-for-bit deterministic.

2.4 FRI Commitments

The polynomial commitment scheme is FRI (Fast Reed-Solomon Interactive Oracle Proof of Proximity) via Plonky3's TwoAdicFriPcs. The Tenzro testnet pins the following FRI parameters:

Conjectured soundness bits are log_blowup × num_queries + query_proof_of_work_bits = 1 × 64 + 16 = 80 bits at the FRI layer. Combined with the degree-4 extension challenge space (~124 bits) and Poseidon2 collision resistance, the end-to-end soundness target is ≥100 bits. Mainnet hardening is reserved for higher num_queries and additional PoW grinding.

3. The Three AIRs

A circuit in Plonky3 is an AIR — a set of polynomial constraints over a tabular execution trace. Every row is a constraint instance; the prover commits to the full trace and proves that all rows satisfy the AIR. Tenzro ships three AIRs covering the canonical statements the network needs to make verifiable.

3.1 InferenceAir

Proves that a model with hash model_hash applied to input input_hash produced output output_hash. The witness binds a private model checksum, input checksum, and computed output checksum to their public hashes via Poseidon2. The same AIR underlies the verifiable-inference path used by paid providers and the Native VM precompile.

Public inputs: model_hash, input_hash, output_hash — each represented as KoalaBear field elements (4 bytes per element in the on-chain envelope).

Trace columns: NUM_INFERENCE_COLS, exposed as a Rust constant alongside NUM_INFERENCE_PUBLIC_VALUES. Witness builders import these constants directly from tenzro-zk.

3.2 SettlementAir

Proves that a payment settlement is well-formed: the payer had sufficient balance, the amount and service hash bind to the settlement hash, and the nonce strictly increments. Used by the off-chain micropayment channel reconciliation path, by the on-chain escrow primitive, and by the verifiable-payments middleware that fronts paid HTTP routes.

Public inputs: settlement_hash, service_hash, amount.

Trace columns: NUM_SETTLEMENT_COLS, with NUM_SETTLEMENT_PUBLIC_VALUES public values.

3.3 IdentityAir

Proves possession of a valid Tenzro DID without revealing the underlying private key, plus optional bounded predicates over capability bitmasks and reputation thresholds. Used by anonymous credential presentation flows, including delegated-agent attestations and KYC tier disclosure.

Public inputs: public_key_hash, capability_commitment, minimum_reputation.

Trace columns: NUM_IDENTITY_COLS, with NUM_IDENTITY_PUBLIC_VALUES public values.

3.4 Single Verifier Dispatch

All three AIRs go through one entry point — verify_proof_envelope(&Proof) — which matches on the circuit_id field and dispatches to the right Plonky3Verifier<Air> instance. RPC, MCP, web verification, and the settlement engine all consume this single function:

use tenzro_zk::{verify_proof_envelope, Proof};

fn verify_any_tenzro_proof(p: &Proof) -> bool {
    // circuit_id ∈ { "inference", "settlement", "identity" }
    verify_proof_envelope(p).is_ok()
}

4. Wire Format

Proofs flow through storage, RPC, MCP, A2A, and the on-chain commitment registry as a single Proof envelope:

pub struct Proof {
    pub proof_bytes: Vec<u8>,        // bincode of p3_uni_stark::Proof
    pub public_inputs: Vec<Vec<u8>>, // 4-byte LE KoalaBear chunks, one per public value
    pub proof_type: ProofType,       // Plonky3
    pub circuit_id: String,          // "inference" | "settlement" | "identity"
    pub metadata: ProofMetadata,
}

• Proof bytes: the typed p3_uni_stark::Proof<TenzroStarkConfig> encoded with bincode. The encoding is version-pinned by the Plonky3 git revision called out in §2.1.
• Public inputs: a Vec<Vec<u8>> of fixed-width 4-byte little-endian KoalaBear field-element chunks. The consumer knows the expected count from the AIR (e.g. NUM_INFERENCE_PUBLIC_VALUES), so no length prefix is needed per chunk.
• Circuit ID: a short ASCII tag the dispatcher uses to pick the right verifier. Unknown IDs are rejected with a typed error.

Live Tenzro proofs use ProofType::Plonky3. Verifiers reject any other variant with a typed WrongProofType error.

5. Commitment-Attestation On-Chain Model

Verifying a STARK proof inside the EVM is too expensive to be practical at testnet gas limits. Tenzro instead uses a commitment-attestation model: validators verify the proof off-EVM using the full verify_proof_envelope path, then record a 32-byte SHA-256 commitment to the proof in an on-chain ZkCommitmentRegistry. Smart contracts that want to consume a proof check the registry, not the proof bytes.

5.1 Commitment Hash

The commitment is a single SHA-256 over a length-prefixed concatenation of the circuit ID, the proof bytes, and each public input:

commitment = SHA256(
    circuit_id_bytes
  ||
    proof_bytes
  ||
    Σ_i ( len_le4(public_inputs[i]) || public_inputs[i] )
)

Each public-input chunk is preceded by a 4-byte little-endian length prefix so the encoding is unambiguous. Validators compute this hash via compute_zk_commitment(circuit_id, proof_bytes, public_inputs) after a successful off-chain verification, and only then write to the registry.

5.2 ZK_VERIFY Precompile

The EVM ZK_VERIFY precompile lives at address 0x1006 alongside the other Tenzro-specific precompiles (TEE_VERIFY, NFT_FACTORY, VRF_VERIFY, …). Its semantics are deliberately small:

• Input: a 32-byte commitment hash.
• Output: 1 if the commitment is in the registry, 0 otherwise.
• Gas cost: O(1) — it's a HashSet lookup, not a STARK verification.

Smart contracts that want ZK-gated logic compute the expected commitment from their inputs, call the precompile, and branch on the result. The cryptographic verification has already happened off-EVM at the validator layer; the precompile simply attests that a quorum of validators saw and verified the proof.

6. Hybrid ZK-in-TEE Execution

For the highest-trust path — verifiable AI inference with confidentiality guarantees — Tenzro composes Plonky3 STARKs with TEE attestation. The witness derivation, AIR trace generation, and proof construction all happen inside an Intel TDX, AMD SEV-SNP, AWS Nitro, or NVIDIA GPU enclave. The enclave then signs the proof with its hardware-rooted Ed25519 key.

A verifier that consumes a hybrid proof checks both layers:

1. The Plonky3 proof is verified with verify_proof_envelope, ensuring the public statement is mathematically sound.
2. The TEE attestation quote is verified against the pinned vendor root CA (Intel, AMD, AWS, NVIDIA), ensuring the witness was derived inside a genuine enclave.
3. The enclave Ed25519 signature is verified against the proof bytes, binding the two layers together.

The relevant entry points live in the tenzro_zk::tee_integration module: generate_tee_zk_proof, verify_tee_zk_proof, sign_tee_zk_proof, and verify_tee_zk_signature. Witness inputs that contain confidential data (private model weights, raw user inputs) never leave the enclave; only the public statement and the proof do.

use tenzro_zk::{
    generate_tee_zk_proof, verify_tee_zk_proof,
    sign_tee_zk_proof,    verify_tee_zk_signature,
};

// Inside the enclave: derive witness, prove, sign.
let proof   = generate_tee_zk_proof(&witness)?;
let signed  = sign_tee_zk_proof(&proof, &enclave_key)?;

// Outside the enclave: verify both layers.
verify_tee_zk_proof(&proof)?;                      // STARK verification
verify_tee_zk_signature(&signed, &expected_jkt)?;  // TEE attestation

7. Performance

Benchmarks below run on a single x86_64 core (no SIMD/AVX-512 packing flags) at the pinned testnet config:

Plonky3 supports SIMD packing across AVX-512 lanes and GPU acceleration for FRI commitments. Both are mainnet hardening targets and are not enabled in the testnet binary.

8. Integration Points

The proving and verification path is wired into every surface that needs verifiable computation:

9. Use Cases

9.1 Verifiable AI Inference

A model provider serving paid inference can produce an InferenceAir proof binding the model hash, input hash, and output hash without exposing weights or user input. Consumers verify the proof off-chain or accept the on-chain commitment, gaining cryptographic assurance that the advertised model produced the response.

9.2 Confidential Settlement

Off-chain micropayment channels close with a SettlementAir proof that the final balance is consistent with the committed channel state — no need to publish per-tick payment events. The on-chain registry records the commitment; the dispute resolver consumes the proof if a counterparty challenges.

9.3 Anonymous Credentials

An agent can prove, via IdentityAir, that it controls a DID with a given capability bitmask and reputation above a threshold without disclosing the underlying credential or the precise reputation value. This composes with the TDIP delegation system: a delegated agent presents a ZK credential alongside its DPoP-bound auth token, and the resource server checks both.

9.4 Hybrid ZK-in-TEE Verifiable Inference

High-stakes inference (regulated workloads, sealed-input pipelines, multi-tenant model serving) runs end-to-end inside a TEE. The enclave proves correctness with Plonky3 and signs the proof with its hardware key. Verifiers gain both mathematical and hardware-rooted assurance that the computation ran as advertised on the advertised model in a non-extracted environment.

10. Security Model

10.1 Soundness

The verifier accepts a proof only if every FRI query passes, every challenge is consistent with the Fiat-Shamir transcript, and every boundary and transition constraint of the AIR holds at every queried index. The conjectured soundness target is ≥100 bits at the testnet config and is dialed up at mainnet hardening by raising num_queries and PoW grinding.

10.2 Zero-Knowledge

Witness columns (private values such as model checksums, input data, private keys, and capability bitmasks) are never serialized into the proof bytes. They appear only in the prover's local trace and are masked by Reed-Solomon encoding before commitment. The public inputs are limited to the explicit NUM_*_PUBLIC_VALUES field elements declared by each AIR.

10.3 Post-Quantum Conjecture

The cryptographic primitives used — Poseidon2 hashing and FRI low-degree testing — are believed to resist quantum adversaries. There is no factoring or discrete-log assumption anywhere in the proof system. This pairs naturally with Tenzro's in-flight post-quantum signature migration (hybrid Ed25519 + ML-DSA-65) so the entire verification stack is on a path toward PQ-safe end-to-end.

10.4 Commitment Registry Trust

The on-chain ZkCommitmentRegistry is populated only by validators that have run the full off-EVM verify_proof_envelope path. A malicious validator that registers a commitment for an invalid proof would produce an inconsistent state root and be slashed under the equivocation rules in tenzro-consensus. Smart contracts consuming the precompile inherit the same security as any other consensus-attested fact on the Tenzro Ledger.

11. Roadmap

• Mainnet hardening: Increase num_queries and PoW grinding for tighter soundness margins.
• SIMD + GPU acceleration: Enable AVX-512 packing and GPU FRI for faster proving on supported hardware.
• Recursive composition: Aggregate multiple Tenzro proofs into a single recursive proof — useful for batched settlement and rollup-style scaling.
• Custom AIR builder: A typed Rust DSL for downstream developers to author domain-specific AIRs that share the pinned TenzroStarkConfig.
• PQ key binding: Bind IdentityAir witnesses to ML-DSA-65 verifying keys in addition to Ed25519, completing the PQ-safe identity story.

12. Conclusion

Tenzro's ZK stack is small, transparent, and uniform. One field, one hash function, one PCS, one verifier dispatch, and three concrete AIRs — every piece is open code under crates/tenzro-zk. The commitment-attestation model decouples cryptographic verification from EVM gas, while the hybrid ZK-in-TEE path adds hardware-rooted assurance for the highest-trust workloads. Together, these primitives give the AI economy what it needs: cheap, verifiable, privacy-preserving statements that compose with payments, identity, and inference.

References

1. Polygon Labs. “Plonky3.” https://github.com/Plonky3/Plonky3
2. Ben-Sasson, E., Bentov, I., Horesh, Y., & Riabzev, M. (2018). “Scalable, transparent, and post-quantum secure computational integrity.” (STARKs)
3. Ben-Sasson, E., Bentov, I., Horesh, Y., & Riabzev, M. (2018). “Fast Reed-Solomon Interactive Oracle Proofs of Proximity.” (FRI)
4. Grassi, L., Khovratovich, D., & Schofnegger, M. (2023). “Poseidon2: A Faster Version of the Poseidon Hash Function.”
5. Tenzro Network. “TEE-Based Security & Confidential Computing.” Whitepaper
6. Tenzro Network. “Tenzro Decentralized Identity Protocol (TDIP).” Whitepaper