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

Cómo comprobar una prueba de Proovik sin fiarse de Proovik

Necesitas el fichero de prueba (o el PDF del certificado) y tu copia del documento original. Nada se sube: la huella se calcula en tu navegador. Debajo, la especificación completa, paso a paso y con valores reales.

Versión 1 Red: Kaspa mainnet Verificador de referencia: 248 líneas de Python, sin dependencias
Herramienta

Verificar una prueba en línea

Comprueba aquí un certificado con el mismo motor que se describe debajo. El documento no sale de tu dispositivo: su SHA-256 se calcula en tu navegador y solo viaja la huella. El hash lo aportas tú, nunca se toma del fichero de prueba. Si arrastras el PDF del certificado, el paquete de evidencia adjunto se extrae en tu navegador y el PDF tampoco se envía.

1 · Fichero de prueba

2 · Documento original

El verificador nunca toma el hash del fichero de prueba: lo aportas tú.

Se envían el paquete y el hash a POST /api/verify/proof. Sin cuenta. Límite: 120 verificaciones por hora e IP.

Aparece en el certificado PDF y en el explorador de Kaspa.

Puedes calcularlo arrastrando el documento en la otra pestaña: el valor se comparte.

Este modo reconstruye el paquete consultando api.kaspa.org. Kaspa solo sirve la cabecera completa durante unas 40 horas tras el anclaje: pasado ese plazo los eslabones 3 y 4 no se pueden recomputar y el veredicto será No concluyente, nunca «Acredita». Para una verificación completa usa el fichero de prueba capturado en su momento.

GET /api/verify/proof/{txid}?hash=…. Límite: 30 por hora e IP (consulta la red).

Veredicto ·

Acredita No concluyente No acredita

Los cuatro eslabones cuadran: el documento con este SHA-256 existía cuando se minó el bloque indicado. Recuerda lo que la prueba no acredita: autoría ni veracidad del contenido.

Lo que se ha podido recomputar cuadra, pero falta algún dato (normalmente la cabecera completa del bloque, fuera de la ventana de poda) para cerrar la cadena. No es un fallo de la prueba: es una verificación parcial. Con el fichero de prueba capturado en su momento, o con el paquete de evidencia completo, se puede completar.

Al menos un eslabón no cuadra con el hash aportado. Lo más habitual: el documento no es exactamente el que se selló (un byte distinto cambia el SHA-256) o el fichero de prueba no corresponde a este documento. Revisa el detalle de cada eslabón.

Ver la transacción en la red
documento
txid
block_hash
red
modo
cabecera
verificado

Los eslabones, uno a uno

  1. Testigo de aceptación (KIP-15)

    El paquete no incluye testigo de aceptación. Es opcional: no afecta al veredicto.

Avisos

Qué significa cada eslabón

Alcance de la prueba

Qué se afirma exactamente

La precisión aquí importa más que la elocuencia, porque de esto depende que la prueba aguante un contradictorio.

Lo que la prueba acredita

Que una cadena de bytes cuyo SHA-256 es un valor determinado fue incorporada a una transacción de la red Kaspa, que esa transacción quedó comprometida dentro de la cabecera de un bloque, y que sobre esa cabecera —que incluye una marca temporal— se ejecutó una prueba de trabajo válida. Como la marca temporal está dentro del dato sobre el que se hizo el trabajo, alterarla invalida el trabajo. La fecha no es una declaración de nadie: es una magnitud física ya gastada.

Lo que la prueba NO acredita

Quién creó el documento, si su contenido es cierto, si su autor tenía derecho a crearlo, ni que el documento no existiera antes. Acredita anterioridad a un instante, no autoría ni veracidad. Proovik no ve el documento en ningún momento: solo recibe su hash.

Sobre el hash

SHA-256 es una función resumen de 256 bits. Encontrar dos documentos distintos con el mismo resumen no se ha conseguido nunca y el esfuerzo estimado excede lo que la humanidad puede computar. Por eso, si el resumen del documento aportado coincide con el que está en la cadena, el documento es el mismo, sin margen práctico de duda.

Ejemplo real · 20-09-2026

Los cuatro eslabones

La verificación es una cadena. Cada eslabón enlaza con el siguiente, y basta que uno falle para que la prueba no valga. Los valores que aparecen a continuación son reales: corresponden a un certificado emitido el 20 de septiembre de 2026.

1 2 3 4

1 · El dato de la transacción es el resumen del documento

Coincide
Qué comprueba
Que la huella de tu archivo es exactamente la que está en Kaspa.
Si fallara
Alguien habría cambiado el documento, aunque fuera un byte.
Cómo
Toda transacción de Kaspa admite un campo libre, payload. Proovik escribe ahí los 32 bytes del SHA-256 del documento, y nada más. La comprobación es una comparación literal.
Ver el cálculo 
SHA-256(documento) == transaccion.payload
documento0f7383b381366cc3a75dadd7e4a1e8998c492f7c5c5610f4384d7320f484aad8
payload0f7383b381366cc3a75dadd7e4a1e8998c492f7c5c5610f4384d7320f484aad8

2 · La transacción está comprometida en la cabecera del bloque

Coincide
Qué comprueba
Que esta transacción forma parte del bloque que la prueba declara, y no de otro.
Si fallara
La transacción existiría, pero no en ese bloque ni con esa fecha.
Cómo
Kaspa registra en cada cabecera de la cadena un compromiso con las transacciones que ese bloque acepta. Desde la entrada en vigor de KIP-15 ese campo, acceptedIdMerkleRoot, no es una raíz Merkle simple sino un valor encadenado: combina el compromiso del bloque padre con la raíz de las transacciones aceptadas. Un recálculo que ignore ese encadenamiento falla, y ésa es la causa más frecuente de verificaciones erróneas.
Ver el 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. padre2b3265225d51e5b051e46b9f164dc116cf2e21d566827abc8a7b1ae036d8330d
calculado7843221eda25f05ddf9872ed57b59fb95c4f15aa7bf15017105e9797ef09caa5
en cabecera7843221eda25f05ddf9872ed57b59fb95c4f15aa7bf15017105e9797ef09caa5
Dos trampas verificadas

El orden de las transacciones aceptadas es el canónico que fija KIP-15, no el orden en que las devuelva una API ni el orden por hash. Y las hojas del árbol de un bloque —cuando se verifica inclusión en lugar de aceptación— no son los txid, sino los tx::hash, calculados con la codificación completa (incluidos los signature scripts y el compromiso de masa de almacenamiento).

3 · La cabecera produce el hash de bloque declarado

Coincide
Qué comprueba
Que la cabecera recibida, recalculada byte a byte, da exactamente este hash de bloque.
Si fallara
La cabecera no sería la del bloque: la fecha que contiene no valdría.
Cómo
El hash de un bloque es el resumen de su cabecera serializada. Recalcularlo demuestra que la cabecera aportada es exactamente la que dice ser, y que ninguno de sus campos —incluida la marca temporal— ha sido tocado.
Ver el 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
bloque77ee3a38aecdb3d8e97a010f7f8f78927e48282d22ebfae3004713ba8a9d51fc
Requisito no negociable

La cabecera se compromete a todos los niveles de padres —hoy son 56, con más de doscientos hashes—. Si falta uno solo, el resumen no se puede reconstruir. Éste es el motivo por el que el fichero de prueba debe capturar la cabecera íntegra en el momento del anclaje: pasadas unas treinta horas, la red descarta esos datos y los servicios públicos devuelven la cabecera recortada.

4 · Sobre esa cabecera se ejecutó una prueba de trabajo válida

Trabajo válido
Qué comprueba
Que el trabajo se hizo sobre esta cabecera, con esta fecha dentro. Cambiar la fecha invalida el trabajo.
Si fallara
La fecha sería una declaración, no una magnitud física ya gastada.
Cómo
Aquí es donde la prueba deja de ser una afirmación y pasa a ser una constatación. Kaspa exige que el resultado de aplicar su función de trabajo (kHeavyHash) a la cabecera quede por debajo de un umbral. Alcanzarlo requiere miles de billones de intentos: energía real, irreversiblemente gastada.
Ver el 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
anclado2026-09-20 00:03:00 UTC
La fecha

Por qué la fecha es una magnitud física y no una declaración

Ésta es la parte que suele exigir el contradictorio, así que conviene enseñarla en vez de argumentarla. La marca temporal está dentro de la cabecera, y la cabecera es la entrada de la prueba de trabajo. Modificar la hora modifica la entrada, y el trabajo deja de ser válido. Se comprueba experimentalmente alterando la cabecera verificada en el paso 4 y repitiendo el cálculo:

Efecto de alterar la cabecera sobre el resultado de la prueba de trabajo
Cabecera Resultado del trabajo Veredicto
Original, sin tocar0x15222b53caabb3b049ec…Válido
nonce + 10x6775abc19ba960657f66…Inválido
timestamp adelantado un segundo0xaee1e8274b1d268866ed…Inválido
La consecuencia

Para presentar el documento con una fecha distinta habría que rehacer la prueba de trabajo de esa cabecera contra la dificultad real de la red. No es una barrera de coste: es una barrera de cómputo del orden de la potencia agregada de toda la red durante el intervalo que se pretenda falsear. Nadie declara la fecha. La fecha se paga.

Permanencia

¿Seguirá funcionando tras futuros hardforks?

La respuesta honesta es sí, y conviene entender por qué. Una prueba capturada no es una consulta viva a la red: es un hecho histórico, verificado con las reglas vigentes en el momento en que se ancló. Kaspa cambia con el tiempo —la transición Crescendo/Toccata modificó, por ejemplo, el ritmo del DAA y el conteo de dificultad—, pero eso no borra el pasado: solo significa que un bloque de enero de 2026 se verifica con las reglas de enero de 2026, y uno de dentro de tres años con las de dentro de tres años.

El verificador de referencia está construido para eso: distingue eras. Conoce el punto de activación de cada cambio de consenso (por ejemplo, la constante CRESCENDO_DAA_MAINNET) y aplica a cada bloque las reglas de su época, no las de hoy. Un hardfork posterior añade una era nueva; no invalida las anteriores.

La permanencia de la prueba descansa entonces en tres condiciones, todas bajo control de quien la posee:

1

Capturar dentro de la ventana

Guardar la cabecera íntegra en el momento del anclaje, antes de que la red descarte los datos completos (unas 30-40 horas).

2

Guardar la prueba

El fichero de prueba (o el PDF que lo lleva embebido) es autosuficiente: no remite a ningún servidor ni consulta en línea.

3

Mantener el verificador de referencia

248 líneas de código abierto, sin dependencias, re-derivables del código fuente público de Kaspa. Aunque se perdiera, se reescribe.

Verifíquelo usted mismo

Hazlo sin Proovik

El verificador de referencia son 248 líneas de Python sin dependencias externas: implementa blake2b con clave, la permutación Keccak-f[1600], el generador xoshiro256++ y la aritmética de la matriz. Se lee en una tarde y se audita en dos.

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

Descargar el verificador de referencia

Dos ficheros. Colóquelos en la misma carpeta y ejecute el primero. No instalan nada ni salen a la red.

verificador_kaspa.py kaspa_pow.py

Quien prefiera no ejecutar código ajeno puede reimplementarlo: los cuatro algoritmos están descritos arriba sin ambigüedad, y todos los parámetros proceden del código fuente público de rusty-kaspa. Es igualmente legítimo consultar la transacción en cualquier explorador público de Kaspa como contraste, pero conviene entender la diferencia: el explorador es un testimonio; el cálculo es una demostración. Esta especificación existe para no depender del primero.

Marco jurídico

Alcance jurídico

Proovik presta un servicio de sello de tiempo electrónico no cualificado en el sentido del artículo 3.16.i) del Reglamento (UE) 910/2014. Conviene ser explícito sobre lo que eso significa.

  • Conforme al artículo 41.1 del citado Reglamento, no pueden negarse efectos jurídicos ni admisibilidad como prueba en juicio a un sello de tiempo electrónico por el solo hecho de estar en formato electrónico o de no ser cualificado.
  • Un sello no cualificado no goza de la presunción de exactitud de fecha y hora del artículo 41.2, reservada a los cualificados. En caso de impugnación, la carga de acreditar la prueba recae sobre quien la aporta.
  • Precisamente por eso esta especificación existe: para que esa carga se satisfaga con una comprobación aritmética reproducible por cualquiera, en lugar de con la declaración del prestador.

Proovik no verifica el contenido, la autoría ni la licitud de los documentos, y en ningún momento accede a ellos: recibe únicamente su resumen criptográfico. Lo que se acredita es una prueba de existencia y anterioridad a un instante determinado.

Referencias

Serialización de cabecera y transacción, construcción del árbol Merkle y prueba de trabajo, según el código fuente de la implementación de referencia de 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/.

Los valores empleados como ejemplo corresponden a certificados reales y son comprobables por cualquiera. Esta especificación se versiona: las pruebas indican en su interior la versión con la que fueron emitidas.