Generación de Pruebas y Confianza

Genera, empaqueta y verifica pruebas Achronyme sin confundir setup de desarrollo con confianza de producción.

Achronyme compila circuitos, genera witnesses y produce pruebas criptográficas en proceso. En 0.1.0, generar una prueba falla de forma cerrada hasta que el operador selecciona de dónde proviene la proving key.

Modos de confianza

Modo	Selección	Uso previsto
Sin fuente de llave	Default	Compilación, exportación de witness y verificación; se rechaza generar pruebas
Setup de desarrollo	`--insecure-dev-setup`	Experimentos y tests locales; las llaves de una sola parte no son confiables para producción
Store confiable	`--trusted-key-dir <dir>`	BN254 Groth16 de producción con llave de ceremonia ligada al circuito exacto

Las opciones de desarrollo y store son mutuamente excluyentes. Los mismos settings pueden expresarse en achronyme.toml, aunque un flag es más claro para comandos puntuales.

Compilar sin probar

Compilar el circuito y validar el witness no requiere una proving key:

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

La ruta R1CS exporta archivos .r1cs y .wtns compatibles con iden3. Valida el witness de forma independiente al cruzar entre herramientas:

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

Pruebas de desarrollo

Activa el modo inseguro explícitamente al experimentar:

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

Los bloques inline prove {} usan la misma política:

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

La prueba generada es criptográficamente real y útil para desarrollo, pero su llave local no aporta confianza de setup multi-party. No publiques esa llave como artefacto de producción.

Proving BN254 de producción

Un trusted-key store contiene un paquete inmutable y versionado para un R1CS optimizado exacto. Su manifest liga al menos:

hashes del R1CS y proving key final;
artefacto de fase 1 y digest publicado;
llave contribuida anterior al beacon;
cada ID y hash de contribuidor de fase 2;
beacon público final y evidencia de compromiso previo;
versión de la herramienta y evidencia del release.

Selecciona el store al ejecutar código de pruebas:

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

Si el circuito optimizado no existe o no coincide con el store, generar la prueba falla en lugar de crear una llave de reemplazo.

ach trusted-setup package valida y empaqueta artefactos de ceremonia ya verificados externamente. No ejecuta la ceremonia ni vuelve confiable una llave no confiable. Los operadores deben usar las guías versionadas de trusted setup y boss fight del repositorio core.

Verificación separada

Verificar no necesita configuración de proyecto, bandera insegura ni trusted store:

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

La curva es obligatoria. Se soporta verificación bn254 y bls12-381. Artefactos malformados, con curva incorrecta o alterados retornan status distinto de cero.

Backends y confianza del release

Backend	Circuito y witness	Prueba de desarrollo	Producción en 0.1.0
R1CS + Groth16, BN254	Soportado	Soportado con opt-in explícito	Soportado con trusted-key store verificado
R1CS + Groth16, BLS12-381	Las rutas soportadas varían por comando	Solo desarrollo	No es target de proving de producción
Plonkish + KZG	Ruta de desarrollo soportada	Solo desarrollo	No es target de proving de producción

La generación de verificadores Solidity y exportación snarkjs apuntan a BN254 Groth16. No generalices esas afirmaciones a cada curva o backend.

Proof values inline

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))

El compilador infiere capturas witness y mantiene explícitos los inputs públicos declarados. I/O del host, creación de tareas y suspensión están prohibidos dentro del body determinista de prueba.

Clases de error

Espera que la generación rechace:

una fuente de llave faltante;
opciones de desarrollo y store simultáneas;
un circuito ausente del store;
diferencias de circuito, curva, transcript o manifest;
proof, public inputs o verification key malformados;
witnesses que no satisfacen los constraints.

Estos fallos forman parte del límite de confianza; no son molestias de setup que deban saltarse.