TinyZKP

TinyZKP

TinyZKP es un backend de prueba de conocimiento con recursos limitados, con licencia MIT, para Plonky3. Su objetivo de producción es simple: permitir que los equipos de prueba completen rastros STARK más grandes bajo un límite explícito de RAM, utilizando almacenamiento temporal SSD determinista donde las transformaciones globales lo requieran, manteniendo el formato de prueba oficial de Plonky3 y el verificador sin modificar.

Autoridad de lanzamiento: la fuente comunitaria MIT es pública; un binario de motor de producción solo se admite cuando su evidencia de lanzamiento automatizada pasa. TinyZKP no opera pruebas alojadas, verificación alojada, cuentas de clientes, medición de uso ni comercio MCP. Los artefactos de protección y el checkout son independientemente de cierre seguro por la release/guard-launch-state-v2.json derivada de la evidencia, generada a partir de release/guard-launch-evidence-v2.json y verificada contra la firma protegida y la confianza de lanzamiento. Consulte esos contratos generados para la disponibilidad actual; no la infiera de la prosa del README.

Límite del producto

TinyZKP no introduce un nuevo transcript de producción, verificador, formato de prueba o perfil de seguridad. La ruta de producción está fijada a Plonky3 0.6.1 y la configuración de ejemplo upstream Goldilocks/Poseidon2 p3-uni-stark, congelada como tinyzkp-p3-goldilocks-v1.

La capa diferenciadora es la infraestructura del lado del prover:

• políticas de recursos para RAM, almacenamiento temporal, hilos y retención de puntos de control;
• almacenes de matrices con suma de verificación, solo propietario, y acceso a matrices legible por bloques;
• un adaptador DFT de Plonky3 determinista respaldado por almacenamiento temporal;
• generación y verificación de pruebas oficiales de Plonky3 para AIRs de referencia Fibonacci y Goldilocks Poseidon2;
• doce contratos congelados orientados a Guard generados a partir de la autoridad Rust compartida tinyzkp-contracts, más contratos del motor de prueba;
• medición de cgroup-v2 de Linux desde la creación del proceso hasta la verificación;
• procedencia de lanzamiento, bloqueo de compatibilidad y puertas de publicación de cierre seguro.

La canalización con recursos limitados se implementa localmente: la generación de trazas y cocientes, transformaciones de cuatro pasos, MMCS, aperturas y FRI utilizan almacenes limitados duraderos, y los puntos de control tipados preservan el estado oficial del desafiante para reanudación idéntica byte a byte. Plonky3 0.6.1 aún entrega su rasgo DFT genérico a un RowMajorMatrix propiedad; la orquestación limitada de TinyZKP utiliza por lo tanto el punto de entrada de matriz de bloques separado. La implementación sigue siendo preproducción hasta que el verificador automatizado, determinismo, recursos de host fijo, recuperación, fuzzing, procedencia, SBOM, firma, CLI y comprobaciones OCI pasen para el lanzamiento exacto y las puertas de lanzamiento de Guard controladas por el propietario publiquen ese artefacto. Las revisiones independientes y los resultados de socios de diseño siguen siendo avisos visibles.

Los protocolos independientes de TinyZKP, recibos heredados, servicios alojados, recursión, zkML, zkVM, IPA, Spartan, KZG y prototipos de rollup son solo de investigación. El acceso CLI heredado requiere la característica explícita legacy-research y no se compila en el contenedor del motor público ni en la ruta CI predeterminada.

Mapa del repositorio

Ruta	Propósito
crates/tinyzkp-contracts	Contratos JSON públicos congelados, vocabulario de razones, esquemas y aritmética de recursos compartidos por el motor y Guard
crates/hc-stream	Política de recursos, matrices de bloques, almacenes de matrices, preflight y contratos de puntos de control
crates/hc-plonky3	Configuración fijada de Plonky3, cargas de trabajo, adaptador DFT, prover/verificador oficial y contratos de artefactos
crates/hc-cli	CLI de producción de Plonky3 y trabajador de benchmarks
scripts/benchmark	Orquestación de benchmarks cgroup-v2 y herramientas de informes
release	Compatibilidad de dependencias y evidencia obligatoria de puerta de lanzamiento
site	Sitio estático de Guard: producto, compatibilidad, evidencia, documentación y estado legal
docs/recovery	Documentación de arquitectura, entrega, lanzamiento y operación

Las fuentes de servidor, MCP, facturación, SDK y beta alojada permanecen temporalmente en esta rama pendientes del inventario de obligaciones, exportaciones finales verificadas, smoke en vivo de reemplazo y desmantelamiento autorizado. Sus flujos de trabajo están deshabilitados y sus binarios están excluidos de los payloads de lanzamiento y despliegue activos. La etiqueta archive/hosted-beta-2026-07-17 preserva la instantánea histórica; no es evidencia de que la fuente restante o la infraestructura externa ya haya sido eliminada.

Compilación y pruebas

Rust 1.95.0 está fijado porque Plonky3 0.6.1 utiliza APIs no disponibles en toolchains más antiguas. Las dependencias de Plonky3 y serialización de artefactos están fijadas exactamente en el workspace y verificadas contra release/plonky3-compatibility-v1.json.

cargo test --locked -p hc-stream -p hc-plonky3 -p hc-cli
cargo clippy --locked -p hc-stream -p hc-plonky3 -p hc-cli \
  --all-targets -- -D warnings
python3 scripts/ci/guard_launch_gate.py --check

La auditoría de lanzamiento de API/MCP/facturación alojada está retirada y no puede autorizar a Guard. El candidato de motor firmado, el candidato de Guard, el sitio estático y las identidades OCI deben pasar los controles de evidencia de Guard y promoción conjunta.

CLI

Genere los doce esquemas de API orientados a Guard congelados, el esquema de perfil de compatibilidad independiente y los esquemas del motor de prueba a partir de sus fuentes de verdad Rust:

cargo run --locked -p hc-cli -- schema --output-dir /tmp/tinyzkp-schemas

El ejecutable instalado orientado a producción es tinyzkp-engine; hc-cli es el paquete Cargo y el nombre del binario de desarrollo. Ejecute el doctor de compatibilidad con un JobManifestV1 poblado antes de probar:

tinyzkp-engine doctor --job job.json

La ruta de prueba AIR declarativa utiliza un directorio de puntos de control exacto propiedad del llamador:

tinyzkp-engine plonky3 prove-air \
  --air <air-package-v1.json> \
  --trace-manifest <trace-manifest-v1.json> \
  --chunks-dir <trace-chunks> \
  --public-inputs <public-inputs-v1.json> \
  --policy <resource-policy-v1.json> \
  --checkpoint-dir <job-directory/checkpoint> \
  --output <air-proof-bundle-v1.json>

tinyzkp-engine plonky3 inspect-checkpoint \
  --checkpoint <job-directory/checkpoint/checkpoint.json> \
  --air <air-package-v1.json> \
  --trace-manifest <trace-manifest-v1.json> \
  --chunks-dir <trace-chunks> \
  --public-inputs <public-inputs-v1.json> \
  --policy <resource-policy-v1.json>

tinyzkp-engine plonky3 resume-air \
  --air <air-package-v1.json> \
  --trace-manifest <trace-manifest-v1.json> \
  --chunks-dir <trace-chunks> \
  --public-inputs <public-inputs-v1.json> \
  --checkpoint <job-directory/checkpoint/checkpoint.json> \
  --output <air-proof-bundle-v1.json>

tinyzkp-engine plonky3 verify-air --bundle <air-proof-bundle-v1.json>

inspect-checkpoint realiza las mismas comprobaciones de identidad y artefactos duraderos sin cambiar el estado del trabajo. resume-air luego valida cada identidad de punto de control y artefacto duradero, reconstruye la carga de trabajo declarativa cargada, restaura el estado oficial del desafiante y continúa desde la última fase completada. Las pruebas de crash/reanudación de lanzamiento exacto requieren que los bytes de prueba resultantes coincidan exactamente con una ejecución ininterrumpida.

Los comandos genéricos prove y verify devuelven orientación de migración. La reproducción histórica está disponible solo en una compilación de investigación fuera de línea:

cargo run -p hc-cli --features legacy-research -- legacy-research --help

El comando instalado tinyzkp-engine release emite JSON para verificación cruzada del binario del motor, imagen OCI, perfil de compatibilidad y procedencia de benchmarks antes de la publicación. En un checkout de desarrollo de fuente, su equivalente interno es cargo run --locked -p hc-cli -- release.

Integridad de benchmarks

Las mediciones de lanzamiento deben ejecutarse en Linux bajo cgroup v2, con la línea base y el candidato cada uno lanzado en un proceso nuevo. El informe incluye hardware, SO, almacenamiento, SHA de lanzamiento, perfil de dependencias, comando exacto, segundos de CPU, memoria máxima de todo el proceso, marca de agua alta de almacenamiento temporal, E/S de bloques, tamaño de prueba, tiempo de verificación y resultado del verificador.

cargo build --release -p hc-cli
sudo python3 scripts/benchmark/run_plonky3_cgroup.py \
  --manifest examples/plonky3/fibonacci-small.json \
  --report /tmp/fibonacci-bounded.json

Las mediciones de macOS y las pruebas solo de componentes son útiles para el desarrollo pero no son evidencia de lanzamiento aceptable. TinyZKP nunca infiere memoria, rendimiento, costo o capacidad del prover completo a partir de un benchmark de componentes.

Los objetivos de lanzamiento permanecen bloqueados hasta que la suite automatizada firmada por el propietario demuestre:

• 1M filas: al menos 4× menos RAM máxima, como máximo 3× el tiempo de pared de la línea base y no más del 10% por encima del límite configurado;
• 16,777,216 filas: como máximo 2 GiB de memoria máxima de todo el proceso, verificación oficial exitosa y uso de almacenamiento temporal dentro del 10% del preflight;
• recuperación de crash determinista, fuzzing de parser/recursos, artefactos firmados, SBOM, sumas de verificación, procedencia, smoke de CLI/OCI y acuerdo de identidad de lanzamiento. La reproducción independiente, la revisión externa y las cargas de trabajo externas son avisos transparentes not_completed y no autorizan el checkout.

Comportamiento autoalojado

El producto público es un binario local y una imagen OCI operada por el cliente. No tiene API de trabajos, base de datos de cuentas, cola, flota de trabajadores, almacenamiento de pruebas, medidor de uso o dependencia de TinyZKP en tiempo de ejecución. Los testigos del cliente, los datos de almacenamiento temporal y las pruebas permanecen en almacenamiento controlado por el cliente.

El supervisor comercial separado de Guard puede activar un lanzamiento firmado a través del comerciante de registro. Después de la activación, las operaciones de doctor, ejecución, reanudación, política y verificación están fuera de línea. La cancelación previene la activación de lanzamientos futuros pero no deshabilita un lanzamiento ya activado.

Modelo comercial

El software crítico de prueba permanece MIT. TinyZKP tiene la intención de vender un producto operado por el cliente:

• Comunidad: motor MIT gratuito, verificador, esquemas, doctor, cargas de trabajo de referencia y evidencia pública.
• TinyZKP Guard: $499/mes o $4,990/año para uso interno de una organización legal, con selección automática de modo, supervisión de recuperación, política de CI, calificación firmada y acceso a nuevos lanzamientos.

No hay prueba gratuita de Guard, medición de uso, nivel Enterprise, plan Fleet/OEM, computación alojada, trabajo AIR personalizado, SLA, llamada de incorporación o ingeniería incluida. El motor gratuito y el doctor son la ruta de evaluación. El checkout público permanece deshabilitado hasta que las puertas técnicas, legales, de comerciante, de carga de trabajo externa, de instalación sin ayuda y de primer cliente estén evidenciadas.

El perfil de compatibilidad admitido permanece fijo. Se puede considerar un perfil diferente para una ventana de calificación trimestral solo a través de la puerta de demanda local, solo agregada, documentada en docs/validation/PROFILE_EXPANSION_DEMAND_GATE.md; cumplir ese umbral de demanda no hace que el candidato sea admitido.

La fuente comercial legible por máquina es site/pricing.json. El estado de lanzamiento comercial es generado por scripts/ci/guard_launch_gate.py a partir de evidencia V2 revisada; el archivo de estado derivado no es una aprobación de lanzamiento editable manualmente. Consulte BUSINESS_GUIDE.md para controles operativos y docs/recovery/implementation-status.md para el libro mayor de brechas actual. Los operadores deben seguir docs/runbooks/release_provenance.md, docs/validation/FOUNDING_VALIDATION_PROTOCOL.md, y docs/runbooks/guard_commerce_setup.md. La ingesta opcional de asesoría legal se consolida en docs/governance/GUARD_COUNSEL_PACKET.md; ese paquete es de asesoría y no es autoridad de lanzamiento requerida. La aprobación del propietario de LN Holdings de los hechos exactos del vendedor y los resúmenes de documentos es la puerta legal de máquina.

Seguridad y divulgación

No comprometa secretos, datos de testigos, entradas de clientes, credenciales de proveedores de pago, claves privadas o archivos de entorno de producción. Los artefactos de almacenamiento temporal deben ser solo del propietario y no son confiables al reabrir; manifiestos, fragmentos, identidad de lanzamiento, bloqueo de dependencias, carga de trabajo, entrada y política deben validarse antes de reanudar.

Reporte problemas de seguridad a través del canal privado enlazado desde tinyzkp.com/security. Las afirmaciones de rendimiento y seguridad requieren evidencia reproducible; el código fuente previo al lanzamiento no es una certificación de producción.

Licencia

Este repositorio y su código de motor público tienen licencia MIT. TinyZKP Guard es un supervisor separado con licencia comercial. Guard debe invocar el motor público a través de los contratos de archivo y CLI publicados; no puede bifurcar la semántica de prueba ni colocar el comportamiento crítico de prueba detrás de la licencia comercial.