TinyZKP

TinyZKP

TinyZKP é um backend de prova com recursos limitados, licenciado sob MIT, para Plonky3. Seu objetivo de produção é simples: permitir que equipes de prova completem traces STARK maiores sob um teto explícito de RAM, usando scratch SSD determinístico onde transformações globais exigirem, mantendo o formato de prova oficial do Plonky3 e o verificador inalterado.

Autoridade de lançamento: o código-fonte da comunidade MIT é público; um binário de engine de produção é suportado somente quando suas evidências de lançamento automatizadas passam. TinyZKP não opera prova hospedada, verificação hospedada, contas de clientes, medição de uso ou comércio MCP. Artefatos de Guard e checkout são independentemente fail-closed pelas evidências derivadas de release/guard-launch-state-v2.json, geradas a partir de release/guard-launch-evidence-v2.json e verificadas contra assinatura protegida e confiança de lançamento. Consulte esses contratos gerados para disponibilidade atual; não infira a partir do texto do README.

Limite do produto

TinyZKP não introduz um novo transcript de produção, verificador, formato de prova ou perfil de segurança. O caminho de produção está fixado em Plonky3 0.6.1 e na configuração de exemplo Goldilocks/Poseidon2 p3-uni-stark upstream, congelada como tinyzkp-p3-goldilocks-v1.

A camada diferenciadora é a infraestrutura do lado do provador:

• políticas de recursos para RAM, scratch, threads e retenção de checkpoints;
• armazenamentos de matriz com checksum, somente do proprietário, e acesso a matriz legível por blocos;
• um adaptador DFT Plonky3 determinístico com suporte a scratch;
• geração e verificação de prova oficiais do Plonky3 para AIRs de referência Fibonacci e Goldilocks Poseidon2;
• doze contratos congelados voltados para Guard gerados a partir da autoridade Rust compartilhada tinyzkp-contracts, além de contratos de proof-engine;
• medição Linux cgroup-v2 desde a criação de processo novo até a verificação;
• proveniência de lançamento, bloqueio de compatibilidade e portões de publicação fail-closed.

O pipeline com recursos limitados é implementado localmente: geração de trace e quociente, transformações em quatro etapas, MMCS, aberturas e FRI usam armazenamentos limitados duráveis, e checkpoints tipados preservam o estado oficial do challenger para retomada byte-idêntica. Plonky3 0.6.1 ainda entrega ao seu trait DFT genérico um RowMajorMatrix de propriedade; a orquestração limitada do TinyZKP usa, portanto, o ponto de entrada separado de matriz de blocos. A implementação permanece pré-produção até que as verificações automatizadas de verificador, determinismo, recursos de host fixo, recuperação, fuzzing, proveniência, SBOM, assinatura, CLI e OCI passem para a versão exata e os portões de lançamento do Guard controlados pelo proprietário publiquem esse artefato. Revisões independentes e resultados de parceiros de design permanecem como avisos visíveis.

Protocolos TinyZKP autônomos, recibos legados, serviços hospedados, recursão, zkML, zkVM, IPA, Spartan, KZG e protótipos de rollup são apenas pesquisa. O acesso CLI legado requer o recurso explícito legacy-research e não é compilado no contêiner público do engine ou no caminho padrão de CI.

Mapa do repositório

Caminho	Propósito
crates/tinyzkp-contracts	Contratos JSON públicos congelados, vocabulário de razões, esquemas e aritmética de recursos compartilhados entre o engine e o Guard
crates/hc-stream	Política de recursos, matrizes de blocos, armazenamentos de matriz, preflight e contratos de checkpoint
crates/hc-plonky3	Configuração Plonky3 fixada, workloads, adaptador DFT, provador/verificador oficiais e contratos de artefatos
crates/hc-cli	CLI Plonky3 de produção e worker de benchmark
scripts/benchmark	Orquestração de benchmark cgroup-v2 e ferramentas de relatório
release	Compatibilidade de dependências e evidências obrigatórias de portão de lançamento
site	Site estático do produto Guard, compatibilidade, evidências, documentação e status legal
docs/recovery	Documentação de arquitetura, entrega, lançamento e operação

Fontes de servidor, MCP, cobrança, SDK e beta hospedado permanecem temporariamente neste branch, aguardando o inventário de obrigações, exportações finais verificadas, smoke test ao vivo substituto e descomissionamento autorizado. Seus fluxos de trabalho estão desabilitados e seus binários são excluídos dos payloads ativos de lançamento e implantação. A tag archive/hosted-beta-2026-07-17 preserva o snapshot histórico; ela não é evidência de que o código-fonte restante ou a infraestrutura externa já foi removida.

Build e teste

Rust 1.95.0 é fixado porque Plonky3 0.6.1 usa APIs indisponíveis em toolchains mais antigas. As dependências de Plonky3 e serialização de artefatos são fixadas exatamente no workspace e 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

A auditoria de lançamento hospedada de API/MCP/cobrança está aposentada e não pode autorizar o Guard. O candidato assinado do engine, o candidato do Guard, o site estático e as identidades OCI devem, em vez disso, passar pelas evidências do Guard e pelos controles conjuntos de promoção.

CLI

Gere os doze esquemas de API congelados voltados para Guard, o esquema de perfil de compatibilidade autônomo e os esquemas de proof-engine a partir de suas fontes de verdade Rust:

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

O executável instalado voltado para produção é tinyzkp-engine; hc-cli é o pacote Cargo e o nome do binário de desenvolvimento. Execute o doctor de compatibilidade com um JobManifestV1 preenchido antes de provar:

tinyzkp-engine doctor --job job.json

O caminho de prova AIR declarativo usa um diretório de checkpoint exato de propriedade do chamador:

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 executa as mesmas verificações de identidade e artefatos duráveis sem alterar o estado do job. resume-air então valida cada identidade de checkpoint e artefato durável, reconstrói o workload declarativo enviado, restaura o estado oficial do challenger e continua da última fase concluída. Testes de crash/retomada de versão exata exigem que os bytes de prova resultantes correspondam exatamente a uma execução ininterrupta.

Comandos genéricos prove e verify retornam orientação de migração. A reprodução histórica está disponível apenas em uma build de pesquisa offline:

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

O comando instalado tinyzkp-engine release emite JSON para verificação cruzada do binário do engine, imagem OCI, perfil de compatibilidade e proveniência de benchmark antes da publicação. Em um checkout de desenvolvimento de código-fonte, seu equivalente interno é cargo run --locked -p hc-cli -- release.

Integridade do benchmark

As medições de lançamento devem ser executadas em Linux sob cgroup v2, com baseline e candidato cada um iniciado em um processo novo. O relatório inclui hardware, SO, armazenamento, SHA de lançamento, perfil de dependências, comando exato, segundos de CPU, pico de memória do processo inteiro, marca d'água alta de scratch, I/O de blocos, tamanho da prova, tempo de verificação e resultado do 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

Medições em macOS e testes apenas de componentes são úteis para desenvolvimento, mas não são evidências de lançamento aceitáveis. TinyZKP nunca infere memória, throughput, custo ou capacidade do provador completo a partir de um benchmark de componente.

Os alvos de lançamento permanecem bloqueados até que a suíte automatizada assinada pelo proprietário prove:

• 1M linhas: pelo menos 4× menor pico de RAM, no máximo 3× o tempo de parede do baseline e não mais que 10% acima do limite configurado;
• 16.777.216 linhas: no máximo 2 GiB de pico de memória do processo inteiro, verificação oficial bem-sucedida e uso de scratch dentro de 10% do preflight;
• recuperação determinística de crash, fuzzing de parser/recursos, artefatos assinados, SBOM, checksums, proveniência, smoke de CLI/OCI e concordância de identidade de lançamento. Reprodução independente, revisão externa e workloads externos são avisos transparentes not_completed e não autorizam checkout.

Comportamento auto-hospedado

O produto público é um binário local e uma imagem OCI operada pelo cliente. Ele não tem API de job, banco de contas, fila, frota de workers, armazenamento de provas, medidor de uso ou dependência de runtime do TinyZKP. Testemunhas do cliente, dados de scratch e provas permanecem em armazenamento controlado pelo cliente.

O supervisor comercial separado Guard pode ativar um lançamento assinado por meio do merchant-of-record. Após a ativação, as operações de doctor, run, resume, policy e verify são offline. O cancelamento impede a ativação de lançamentos futuros, mas não desativa um lançamento já ativado.

Modelo comercial

O software crítico para prova permanece MIT. TinyZKP pretende vender um produto operado pelo cliente:

• Comunidade: engine MIT gratuito, verificador, esquemas, doctor, workloads de referência e evidências públicas.
• TinyZKP Guard: US$ 499/mês ou US$ 4.990/ano para uso interno de uma organização legal, com seleção automática de modo, supervisão de recuperação, política de CI, qualificação assinada e acesso a novos lançamentos.

Não há teste gratuito do Guard, medição de uso, camada Enterprise, plano Fleet/OEM, computação hospedada, trabalho AIR personalizado, SLA, chamada de onboarding ou engenharia incluída. O engine e o doctor gratuitos são o caminho de avaliação. O checkout público permanece desabilitado até que os portões técnico, legal, comercial, de workload externo, de instalação sem assistência e de primeiro cliente sejam evidenciados.

O perfil de compatibilidade suportado permanece fixo. Um perfil diferente pode ser considerado para uma janela de qualificação trimestral apenas por meio do portão de demanda local, somente agregada, documentado em docs/validation/PROFILE_EXPANSION_DEMAND_GATE.md; atingir esse limite de demanda não torna o candidato suportado.

A fonte comercial legível por máquina é site/pricing.json. O estado de lançamento comercial é gerado por scripts/ci/guard_launch_gate.py a partir de evidências V2 revisadas; o arquivo de estado derivado não é uma aprovação de lançamento editável manualmente. Consulte BUSINESS_GUIDE.md para controles operacionais e docs/recovery/implementation-status.md para o ledger de lacunas atual. Os operadores devem seguir docs/runbooks/release_provenance.md, docs/validation/FOUNDING_VALIDATION_PROTOCOL.md e docs/runbooks/guard_commerce_setup.md. A coleta opcional de aconselhamento jurídico é consolidada em docs/governance/GUARD_COUNSEL_PACKET.md; esse pacote é consultivo e não é autoridade de lançamento obrigatória. A aprovação do proprietário da LN Holdings sobre fatos exatos do vendedor e resumos de documentos é o portão legal de máquina.

Segurança e divulgação

Não faça commit de segredos, dados de testemunhas, entradas de clientes, credenciais de provedores de pagamento, chaves privadas ou arquivos de ambiente de produção. Artefatos de scratch devem ser somente do proprietário e não são confiáveis ao reabrir; manifests, chunks, identidade de lançamento, lock de dependências, workload, entrada e política devem ser todos validados antes da retomada.

Relate problemas de segurança pelo canal privado vinculado em tinyzkp.com/security. Alegações de desempenho e segurança exigem evidências reproduzíveis; código-fonte pré-lançamento não é uma certificação de produção.

Licença

Este repositório e seu código de engine público são licenciados sob MIT. TinyZKP Guard é um supervisor separado, licenciado comercialmente. O Guard deve invocar o engine público por meio dos contratos de arquivo e CLI publicados; ele não pode bifurcar a semântica de prova nem colocar comportamento crítico para prova atrás da licença comercial.