Proovik
Certificar
Verificador público · PVK-PROOF/1

Como verificar uma prova da Proovik sem confiar na Proovik

Precisa do ficheiro de prova (ou do PDF do certificado) e da sua cópia do documento original. Nada é carregado: a impressão digital é calculada no seu navegador. Em baixo, a especificação completa, passo a passo e com valores reais.

Versão 1 Rede: Kaspa mainnet Verificador de referência: 248 linhas de Python, sem dependências
Ferramenta

Verificar uma prova em linha

Verifique aqui um certificado com o mesmo motor descrito em baixo. O documento não sai do seu dispositivo: o seu SHA-256 é calculado no seu navegador e só a impressão digital viaja. O hash é fornecido por si, nunca é retirado do ficheiro de prova. Se arrastar o PDF do certificado, o pacote de evidência em anexo é extraído no seu navegador e o PDF também não é enviado.

1 · Ficheiro de prova

2 · Documento original

O verificador nunca retira o hash do ficheiro de prova: é você que o fornece.

O pacote e o hash são enviados para POST /api/verify/proof. Sem conta. Limite: 120 verificações por hora e por IP.

Aparece no certificado PDF e no explorador de Kaspa.

Pode calculá-lo arrastando o documento no outro separador: o valor é partilhado.

Este modo reconstrói o pacote consultando api.kaspa.org. A Kaspa só serve o cabeçalho completo durante cerca de 40 horas após a ancoragem: passado esse prazo, os elos 3 e 4 não podem ser recalculados e o veredicto será Não conclusivo, nunca «Comprova». Para uma verificação completa, use o ficheiro de prova capturado na altura.

GET /api/verify/proof/{txid}?hash=…. Limite: 30 por hora e por IP (consulta a rede).

Veredicto ·

Acreditado Não conclusivo Não acreditado

Os quatro elos conferem: o documento com este SHA-256 existia quando o bloco indicado foi minado. Lembre-se do que a prova não comprova: nem a autoria nem a veracidade do conteúdo.

O que foi possível recalcular confere, mas falta algum dado (normalmente o cabeçalho completo do bloco, fora da janela de poda) para fechar a cadeia. Não é uma falha da prova: é uma verificação parcial. Com o ficheiro de prova capturado na altura, ou com o pacote de evidência completo, pode ser concluída.

Pelo menos um elo não confere com o hash fornecido. O mais habitual: o documento não é exatamente o que foi selado (um byte diferente altera o SHA-256) ou o ficheiro de prova não corresponde a este documento. Reveja o detalhe de cada elo.

Ver a transação na rede
documento
txid
block_hash
rede
modo
cabeçalho
verificado

Os elos, um a um

  1. Testemunho de aceitação (KIP-15)

    O pacote não inclui testemunho de aceitação. É opcional: não afeta o veredicto.

Avisos

O que significa cada elo

Alcance da prova

O que se afirma exatamente

Aqui a precisão importa mais do que a eloquência, porque disso depende que a prova resista ao contraditório.

O que a prova demonstra

Que uma cadeia de bytes cujo SHA-256 é um determinado valor foi incorporada numa transação da rede Kaspa, que essa transação ficou comprometida dentro do cabeçalho de um bloco e que sobre esse cabeçalho — que inclui uma marca temporal — foi executada uma prova de trabalho válida. Como a marca temporal está dentro do dado sobre o qual o trabalho foi feito, alterá-la invalida o trabalho. A data não é a declaração de ninguém: é uma grandeza física já gasta.

O que a prova NÃO demonstra

Quem criou o documento, se o seu conteúdo é verdadeiro, se o seu autor tinha o direito de o criar, nem que o documento não existisse antes. Demonstra anterioridade a um instante, não autoria nem veracidade. A Proovik nunca vê o documento: recebe apenas o seu hash.

Sobre o hash

O SHA-256 é uma função de resumo de 256 bits. Nunca se conseguiu encontrar dois documentos diferentes com o mesmo resumo e o esforço estimado excede o que a humanidade consegue computar. Por isso, se o resumo do documento apresentado coincide com o que está na cadeia, o documento é o mesmo, sem margem prática para dúvida.

Exemplo real · 20-09-2026

Os quatro elos

A verificação é uma cadeia. Cada elo liga-se ao seguinte e basta que um falhe para a prova não valer. Os valores que se seguem são reais: correspondem a um certificado emitido a 20 de setembro de 2026.

1 2 3 4

1 · O dado da transação é o resumo do documento

Coincide
O que verifica
Que a impressão digital do seu ficheiro é exatamente a que está em Kaspa.
Se falhasse
Alguém teria alterado o documento, nem que fosse um byte.
Como
Qualquer transação de Kaspa admite um campo livre, payload. A Proovik escreve aí os 32 bytes do SHA-256 do documento, e nada mais. A verificação é uma comparação literal.
Ver o cálculo 
SHA-256(documento) == transaccion.payload
documento0f7383b381366cc3a75dadd7e4a1e8998c492f7c5c5610f4384d7320f484aad8
payload0f7383b381366cc3a75dadd7e4a1e8998c492f7c5c5610f4384d7320f484aad8

2 · A transação está comprometida no cabeçalho do bloco

Coincide
O que verifica
Que esta transação faz parte do bloco que a prova declara, e não de outro.
Se falhasse
A transação existiria, mas não nesse bloco nem com essa data.
Como
A Kaspa regista em cada cabeçalho da cadeia um compromisso com as transações que esse bloco aceita. Desde a entrada em vigor do KIP-15, esse campo, acceptedIdMerkleRoot, não é uma raiz Merkle simples, mas um valor encadeado: combina o compromisso do bloco pai com a raiz das transações aceites. Um recálculo que ignore esse encadeamento falha, e essa é a causa mais frequente de verificações erradas.
Ver o cálculo 
nodo(a,b) = blake2b-256( clave = "MerkleBranchHash", a ‖ b )

AIMR      = raiz Merkle sobre las transacciones aceptadas, en orden canonico
SeqCommit = nodo( SeqCommit_del_padre_seleccionado , AIMR )

valido ⟹ SeqCommit == cabecera.acceptedIdMerkleRoot
AIMRb3bc256951640ff6468511fb62ec8fb280dafb99ebf7ecd00245d0cc3c9debb3
seq. pai2b3265225d51e5b051e46b9f164dc116cf2e21d566827abc8a7b1ae036d8330d
calculado7843221eda25f05ddf9872ed57b59fb95c4f15aa7bf15017105e9797ef09caa5
no cabeçalho7843221eda25f05ddf9872ed57b59fb95c4f15aa7bf15017105e9797ef09caa5
Duas armadilhas verificadas

A ordem das transações aceites é a canónica fixada pelo KIP-15, não a ordem em que uma API as devolva nem a ordem por hash. E as folhas da árvore de um bloco — quando se verifica inclusão em vez de aceitação — não são os txid, mas os tx::hash, calculados com a codificação completa (incluindo os signature scripts e o compromisso de massa de armazenamento).

3 · O cabeçalho produz o hash de bloco declarado

Coincide
O que verifica
Que o cabeçalho recebido, recalculado byte a byte, dá exatamente este hash de bloco.
Se falhasse
O cabeçalho não seria o do bloco: a data que contém não valeria.
Como
O hash de um bloco é o resumo do seu cabeçalho serializado. Recalculá-lo demonstra que o cabeçalho apresentado é exatamente o que diz ser e que nenhum dos seus campos — incluindo a marca temporal — foi tocado.
Ver o cálculo 
h = blake2b-256( clave = "BlockHash" )

h ← version                    u16  little-endian
h ← numero de niveles          u64  little-endian
para cada nivel:
    h ← numero de padres       u64  little-endian
    h ← cada hash de padre      32 bytes
h ← hashMerkleRoot             32 bytes
h ← acceptedIdMerkleRoot       32 bytes
h ← utxoCommitment             32 bytes
h ← timestamp                  u64  little-endian   ← la marca temporal
h ← bits                       u32  little-endian
h ← nonce                      u64  little-endian
h ← daaScore                   u64  little-endian
h ← blueScore                  u64  little-endian
h ← longitud de blueWork       u64  little-endian
h ← blueWork      big-endian, sin ceros a la izquierda
h ← pruningPoint               32 bytes
bloco77ee3a38aecdb3d8e97a010f7f8f78927e48282d22ebfae3004713ba8a9d51fc
Requisito não negociável

O cabeçalho compromete-se com todos os níveis de pais — hoje são 56, com mais de duzentos hashes —. Se faltar um só, o resumo não pode ser reconstruído. É por isso que o ficheiro de prova tem de capturar o cabeçalho íntegro no momento da ancoragem: passadas umas trinta horas, a rede descarta esses dados e os serviços públicos devolvem o cabeçalho recortado.

4 · Sobre esse cabeçalho foi executada uma prova de trabalho válida

Trabalho válido
O que verifica
Que o trabalho foi feito sobre este cabeçalho, com esta data lá dentro. Alterar a data invalida o trabalho.
Se falhasse
A data seria uma declaração, não uma grandeza física já gasta.
Como
É aqui que a prova deixa de ser uma afirmação e passa a ser uma constatação. A Kaspa exige que o resultado de aplicar a sua função de trabalho (kHeavyHash) ao cabeçalho fique abaixo de um limiar. Alcançá-lo exige milhares de biliões de tentativas: energia real, irreversivelmente gasta.
Ver o cálculo 
pre = hash_de_cabecera( con timestamp = 0 y nonce = 0 )
M   = matriz 64x64 generada con xoshiro256++ sembrado con pre,
      regenerada hasta que su rango sea 64
p   = cSHAKE256("ProofOfWorkHash")( pre ‖ timestamp ‖ 32 ceros ‖ nonce )
r   = cSHAKE256("HeavyHash")( (M · nibbles(p)) ⊕ p )

valido  ⟹  entero_little_endian(r)  ≤  objetivo(bits)
pre6e4f2ca8feb279a54f2c4ac8d57c867917f1766a7936a5bd7bd9351557d3c6f7
resultado0x15222b53caabb3b049ec84e25d0a0c7a35512f9d557adb4bc20
objetivo0x2345b0000000000000000000000000000000000000000000000
ancorado2026-09-20 00:03:00 UTC
A data

Porque a data é uma grandeza física e não uma declaração

Esta é a parte que o contraditório costuma exigir, pelo que convém mostrá-la em vez de a argumentar. A marca temporal está dentro do cabeçalho, e o cabeçalho é a entrada da prova de trabalho. Modificar a hora modifica a entrada, e o trabalho deixa de ser válido. Comprova-se experimentalmente alterando o cabeçalho verificado no passo 4 e repetindo o cálculo:

Efeito de alterar o cabeçalho sobre o resultado da prova de trabalho
Cabeçalho Resultado do trabalho Veredicto
Original, sem tocar0x15222b53caabb3b049ec…Válido
nonce + 10x6775abc19ba960657f66…Inválido
timestamp adiantado um segundo0xaee1e8274b1d268866ed…Inválido
A consequência

Para apresentar o documento com uma data diferente seria preciso refazer a prova de trabalho desse cabeçalho contra a dificuldade real da rede. Não é uma barreira de custo: é uma barreira de computação da ordem da potência agregada de toda a rede durante o intervalo que se pretenda falsear. Ninguém declara a data. A data paga-se.

Permanência

Continuará a funcionar depois de futuros hardforks?

A resposta honesta é sim, e convém perceber porquê. Uma prova capturada não é uma consulta em direto à rede: é um facto histórico, verificado com as regras em vigor no momento em que foi ancorada. A Kaspa muda com o tempo — a transição Crescendo/Toccata alterou, por exemplo, o ritmo do DAA e a contagem da dificuldade —, mas isso não apaga o passado: significa apenas que um bloco de janeiro de 2026 se verifica com as regras de janeiro de 2026, e um daqui a três anos com as de daqui a três anos.

O verificador de referência foi construído para isso: distingue eras. Conhece o ponto de ativação de cada alteração de consenso (por exemplo, a constante CRESCENDO_DAA_MAINNET) e aplica a cada bloco as regras da sua época, não as de hoje. Um hardfork posterior acrescenta uma era nova; não invalida as anteriores.

A permanência da prova assenta, então, em três condições, todas sob o controlo de quem a detém:

1

Capturar dentro da janela

Guardar o cabeçalho íntegro no momento da ancoragem, antes de a rede descartar os dados completos (cerca de 30-40 horas).

2

Guardar a prova

O ficheiro de prova (ou o PDF que o traz embebido) é autossuficiente: não remete para nenhum servidor nem faz consultas em linha.

3

Manter o verificador de referência

248 linhas de código aberto, sem dependências, que se podem voltar a derivar do código-fonte público da Kaspa. Mesmo que se perdesse, reescreve-se.

Verifique por si próprio

Faça-o sem a Proovik

O verificador de referência são 248 linhas de Python sem dependências externas: implementa o blake2b com chave, a permutação Keccak-f[1600], o gerador xoshiro256++ e a aritmética da matriz. Lê-se numa tarde e audita-se em duas.

Terminal 
$ python3 verificador_kaspa.py prueba.json 0f7383b381366cc3a75dadd7e4a1e8998c492f7c5c5610f4384d7320f484aad8

  OK    1. El payload on-chain es el hash del documento
  OK    2. La transaccion esta en el arbol Merkle del bloque
  OK    3. La cabecera produce el hash de bloque declarado
  OK    4. La prueba de trabajo de esa cabecera es valida

RESULTADO: PRUEBA VALIDA

Descarregar o verificador de referência

Dois ficheiros. Coloque-os na mesma pasta e execute o primeiro. Não instalam nada nem acedem à rede.

verificador_kaspa.py kaspa_pow.py

Quem preferir não executar código alheio pode reimplementá-lo: os quatro algoritmos estão descritos acima sem ambiguidade e todos os parâmetros provêm do código-fonte público do rusty-kaspa. É igualmente legítimo consultar a transação em qualquer explorador público de Kaspa como contraste, mas convém perceber a diferença: o explorador é um testemunho; o cálculo é uma demonstração. Esta especificação existe para não depender do primeiro.

Enquadramento jurídico

Alcance jurídico

A Proovik presta um serviço de selo temporal eletrónico não qualificado na aceção do artigo 3.º, ponto 16, alínea i) do Regulamento (UE) n.º 910/2014. Convém ser explícito quanto ao que isso significa.

  • Nos termos do artigo 41.º, n.º 1 do referido Regulamento, não podem ser recusados a um selo temporal eletrónico efeitos jurídicos nem admissibilidade como prova em juízo pelo simples facto de se apresentar em formato eletrónico ou de não ser qualificado.
  • Um selo não qualificado não goza da presunção de exatidão da data e da hora do artigo 41.º, n.º 2, reservada aos qualificados. Em caso de impugnação, o ónus de sustentar a prova recai sobre quem a apresenta.
  • É precisamente por isso que esta especificação existe: para que esse ónus se cumpra com uma verificação aritmética reproduzível por qualquer pessoa, em vez da declaração do prestador.

A Proovik não verifica o conteúdo, a autoria nem a licitude dos documentos e em momento algum lhes acede: recebe unicamente o seu resumo criptográfico. O que se comprova é uma prova de existência e anterioridade a um determinado instante.

Referências

Serialização de cabeçalho e de transação, construção da árvore Merkle e prova de trabalho, segundo o código-fonte da implementação de referência da Kaspa (rusty-kaspa): consensus/core/src/hashing/header.rs, consensus/core/src/hashing/tx.rs, consensus/core/src/merkle.rs, crypto/hashes/src/pow_hashers.rs, consensus/pow/.

Os valores usados como exemplo correspondem a certificados reais e podem ser verificados por qualquer pessoa. Esta especificação é versionada: as provas indicam no seu interior a versão com que foram emitidas.