Ir para o conteúdo
Financial Context Wiki

Prova de validade

Guia orientado à verificação sobre provas de validade, entradas públicas, testemunhas, premissas do sistema de prova, transições de estado de rollups, disponibilidade de dados, finalidade e falhas operacionais.

Atualizado

Somente para fins educacionais; não constitui aconselhamento de investimento ou segurança. Uma prova de validade é tão confiável quanto sua afirmação, vinculação das entradas públicas, sistema de prova, verificador, disponibilidade de dados, contratos, operadores, governança e cadeia de liquidação.

Resposta direta

Uma prova de validade é evidência criptográfica de que um cálculo declarado satisfaz uma relação definida com precisão. Um verificador confere a prova com uma chave de verificação e entradas públicas. Em um rollup, essas entradas normalmente vinculam a raiz anterior, a nova raiz proposta e compromissos de um lote. Se a verificação passar, o contrato de liquidação pode aceitar a nova raiz sem reexecutar cada transação.

A garantia é mais restrita que “o sistema está correto”. Ela depende de criptografia sólida, programa ou circuito pretendido, codificação correta, chave autêntica e contratos corretos. A verificação isolada não prova acesso aos dados, atividade do provador, finalidade do bloco, segurança de um upgrade ou funcionamento do saque. Pode usar conhecimento zero, mas validade não implica privacidade.

1
Executar

O provador executa um lote ou cálculo e registra a transição de estado resultante.

Como funciona

  1. Fixar a implantação exata: IDs L1 e L2, versão, contrato de estado, endereço e bytecode do verificador, hash da chave, sistema, circuito ou programa, modo de dados, poderes administrativos, pausa e política de finalidade. validity proof não é especificação universal.
  2. Definir a relação antes de interpretar. Sob as premissas de solidez, Verify(vk, x, proof) = 1 deve implicar uma testemunha w tal que R(x, w) = 1. vk é a chave, x a entrada pública completa e R as regras codificadas. A prova cobre apenas essa relação.
  3. Reconstruir as entradas de modo independente. Confirmar a raiz anterior aceita; derivar compromisso, identificadores, raiz posterior, raízes de mensagens ou saques e parâmetros de dados canônicos. Prova vinculada ao objeto errado prova a afirmação errada.
  4. Verificar prova e caminho contratual. Rodar verificador independente e inspecionar chamada onchain, recibo, evento, lote aceito e armazenamento. Confirmar o verificador previsto e ausência de bypass, simulação ou substituição por upgrade ou privilégio.
  5. Verificar disponibilidade dos dados separadamente. Obter transações, diferenças de estado, blob sidecars ou dados atestados exigidos; conferir compromissos e reproduzir transição ou testemunha de saída. Prova válida e dados indisponíveis podem coexistir, sobretudo em validium.
  6. Separar estados: gerada, enviada, incluída, verificada, estado aceito, liquidação segura, finalizada e saque concluído. Medir fila, custos, atividade, inclusão L1, reorganizações, atrasos da ponte, inclusão forçada e escape.
  7. Guardar evidência reproduzível: endereços e hashes de código, hashes da chave e programa, entradas completas, bytes ou referência da prova, dados do lote, comando e versão, recibo, bloco finalizado e teste de saída. Rever após cada upgrade.

Exemplos calculados

  • Afirmação do lote. Um rollup processa 8,192 transfers. A prova vincula R0, R1 e B7. A verificação sustenta uma testemunha de R0 a R1 para B7; não prova obtenção dos bytes de B7, inclusão total ou finalidade de R1.
  • Agregação recursiva. Um agregador verifica 16 child proofs num circuito pai e envia uma prova pai. Ainda é preciso conferir cada filho, ordem e mapeamento das entradas; a quantidade não cria o vínculo.
  • Livro de gas hipotético. Reexecução custa 24,000,000 gas, verificação 600,000 gas e publicação 180,000 gas. Total 600,000 + 180,000 = 780,000 gas, redução modelada de (24,000,000 - 780,000) / 24,000,000 = 96.75%. Hardware, agregação, falhas, armazenamento, ponte e retenção ficam fora.

Riscos

  • Verificar cadeia, implantação, lote, verificador, chave ou circuito errados.
  • Um sistema sólido provar fielmente um circuito incompleto ou incorreto.
  • Entradas públicas omitirem ou codificarem mal ID, raiz, lote, domínio ou parâmetro.
  • Falha no verificador, pré-compilado, biblioteca insegura ou implementação incompatível.
  • Material de configuração comprometido ou premissas criptográficas violadas.
  • Contratos atualizáveis ou governança substituírem verificador, chave, programa ou regra.
  • Desvios privilegiados, emergência, pausas ou listas permitidas enfraquecerem o caminho.
  • Falhas de geração, não determinismo ou testemunhas diferentes entre clientes.
  • Centralização, censura, indisponibilidade, fila ou hardware do provador pararem atualizações.
  • Faltarem transações, diferenças de estado, blobs, pré-imagens ou arquivos.
  • Confundir assinaturas de comitê ou compromisso com recuperação atual dos dados.
  • Aceitar prova de bloco inseguro, reorganizado ou não canônico.
  • Confundir aceitação da prova com saque imediato ou finalidade econômica.
  • Não reproduzir transição, saldo, mensagem ou testemunha de saída de forma independente.
  • Subestimar gas, tarifas de dados, latência, atrasos da ponte ou recuperação.
  • Aplicar a uma implantação o modelo de prova, disponibilidade e upgrade de outra.

Erros comuns

  • Uma prova verificada garante todos os detalhes e saldos exibidos.
  • Toda prova de validade é de conhecimento zero e oculta transações.
  • As provas eliminam riscos de dados, atividade do sequenciador e censura.
  • A verificação torna a liquidação imediatamente final e sacável.
  • Prova menor ou verificador mais rápido torna o sistema automaticamente mais seguro ou barato.

Tópicos relacionados

Fontes

Navegação

Pesquisar na wiki...