Proof Generation and Trust

Generate, package, and verify Achronyme proofs without confusing development setup with production trust.

Achronyme compiles circuits, generates witnesses, and produces cryptographic proofs in process. In 0.1.0, proof generation fails closed until the operator selects where the proving key comes from.

Trust modes

The development and trusted-store options are mutually exclusive. The same settings can be expressed in achronyme.toml, but a CLI flag is clearer for one-off commands.

Compile without proving

Circuit compilation and witness validation do not require a proving key:

ach circuit multiply.ach \
  --inputs "product=42,a=6,b=7" \
  --r1cs build/multiply.r1cs \
  --wtns build/multiply.wtns

The R1CS path exports iden3-compatible .r1cs and .wtns files. Validate the witness independently when crossing a tooling boundary:

snarkjs wtns check build/multiply.r1cs build/multiply.wtns

Development proofs

Opt in explicitly when experimenting locally:

ach --insecure-dev-setup circuit multiply.ach \
  --inputs "product=42,a=6,b=7" \
  --prove

Inline prove {} blocks use the same policy:

ach --insecure-dev-setup run proof.ach

The generated proof is cryptographically real and useful for development, but its locally generated key does not provide multi-party setup trust. Do not publish that key as a production artifact.

Production BN254 proving

A trusted-key store contains an immutable, versioned package for one exact optimized R1CS. Its manifest binds at least:

• the R1CS and final proving key hashes;
• the phase-1 artifact and published digest;
• the contributed pre-beacon key;
• every phase-2 contributor ID and contribution hash;
• the final public beacon and prior commitment evidence;
• the ceremony tool version and release evidence.

Select the store when running proof code:

ach --trusted-key-dir ./trusted-keys run proof.ach

If the program’s optimized circuit is absent or does not match the store, proof generation fails instead of creating a replacement key.

ach trusted-setup package validates and packages externally verified ceremony artifacts. It does not run the ceremony or make an untrusted key trusted. Operators should use the versioned trusted-setup and boss-fight guides from the core repository.

Detached verification

Verification does not need project configuration, an insecure setup flag, or a trusted-key store:

ach verify \
  --proof proof.json \
  --public public.json \
  --vkey verification_key.json \
  --curve bn254 \
  --format json

The curve is mandatory. bn254 and bls12-381 verification are supported. Malformed, curve-mismatched, or tampered artifacts return a non-zero status.

Backends and release trust

Solidity verifier generation and snarkjs export target BN254 Groth16. Do not generalize those compatibility claims to every curve or backend.

Inline proof values

let secret = 0p42
let commitment = poseidon(secret, 0p7)

let proof = prove(commitment: Public) {
    assert_eq(poseidon(secret, 0p7), commitment)
}

print(proof_json(proof))
print(proof_public(proof))
print(proof_vkey(proof))

The compiler infers witness captures and keeps declared public inputs explicit. Host I/O, task spawning, and suspension are forbidden inside the deterministic proof body.

Error classes

Expect proof generation to reject:

• a missing key source;
• simultaneous development and trusted-store options;
• a missing circuit entry in the store;
• circuit, curve, transcript, or manifest hash mismatches;
• malformed proof, public input, or verification-key artifacts;
• witness values that do not satisfy the constraints.

These failures are part of the trust boundary, not setup inconveniences to bypass.

Further reading

• 0.1.0 Release Candidate
• CLI Commands
• R1CS
• Plonkish
• Inline Proofs