Proovik
Certifier
Vérificateur public · PVK-PROOF/1

Comment vérifier une preuve Proovik sans faire confiance à Proovik

Il vous faut le fichier de preuve (ou le PDF du certificat) et votre copie du document original. Rien n'est téléversé : l'empreinte est calculée dans votre navigateur. Ci-dessous, la spécification complète, pas à pas et avec des valeurs réelles.

Version 1 Réseau: Kaspa mainnet Vérificateur de référence: 248 lignes de Python, sans dépendances
Outil

Vérifier une preuve en ligne

Vérifiez ici un certificat avec le moteur décrit ci-dessous. Le document ne quitte pas votre appareil : son SHA-256 est calculé dans votre navigateur et seule l'empreinte circule. C'est vous qui fournissez le hash, il n'est jamais repris du fichier de preuve. Si vous déposez le PDF du certificat, le paquet de preuve joint est extrait dans votre navigateur et le PDF n'est pas envoyé non plus.

1 · Fichier de preuve

2 · Document original

Le vérificateur ne prend jamais le hash dans le fichier de preuve : c'est vous qui le fournissez.

Le paquet et le hash sont envoyés à POST /api/verify/proof. Sans compte. Limite : 120 vérifications par heure et par IP.

Il figure sur le certificat PDF et dans l'explorateur Kaspa.

Vous pouvez le calculer en déposant le document dans l'autre onglet : la valeur est partagée.

Ce mode reconstruit le paquet en interrogeant api.kaspa.org. Kaspa ne sert l'en-tête complet que pendant une quarantaine d'heures après l'ancrage : passé ce délai, les maillons 3 et 4 ne peuvent plus être recalculés et le verdict sera Non concluant, jamais « Établi ». Pour une vérification complète, utilisez le fichier de preuve capturé au moment de l'ancrage.

GET /api/verify/proof/{txid}?hash=…. Limite : 30 par heure et par IP (cela interroge le réseau).

Verdict ·

Établi Non concluant Non établi

Les quatre maillons concordent : le document portant ce SHA-256 existait lorsque le bloc indiqué a été miné. Rappelez-vous ce que la preuve n'établit pas : ni la paternité ni la véracité du contenu.

Ce qui a pu être recalculé concorde, mais il manque une donnée (généralement l'en-tête complet du bloc, sorti de la fenêtre d'élagage) pour fermer la chaîne. Ce n'est pas un défaut de la preuve : c'est une vérification partielle. Avec le fichier de preuve capturé au moment de l'ancrage, ou avec le paquet de preuve complet, elle peut être menée à son terme.

Au moins un maillon ne concorde pas avec le hash fourni. Le plus souvent : le document n'est pas exactement celui qui a été scellé (un seul octet différent change le SHA-256) ou le fichier de preuve ne correspond pas à ce document. Examinez le détail de chaque maillon.

Voir la transaction sur le réseau
document
txid
block_hash
réseau
mode
en-tête
vérifié

Les maillons, un à un

  1. Témoin d'acceptation (KIP-15)

    Le paquet n'inclut pas de témoin d'acceptation. Il est facultatif : cela n'affecte pas le verdict.

Avertissements

Ce que signifie chaque maillon

Portée de la preuve

Ce qui est affirmé, exactement

Ici, la précision compte plus que l'éloquence, car c'est d'elle que dépend la résistance de la preuve à la contradiction.

Ce que la preuve établit

Qu'une chaîne d'octets dont le SHA-256 vaut une valeur déterminée a été incorporée à une transaction du réseau Kaspa, que cette transaction a été engagée dans l'en-tête d'un bloc, et que sur cet en-tête —qui contient un horodatage— une preuve de travail valide a été exécutée. Comme l'horodatage se trouve à l'intérieur de la donnée sur laquelle le travail a porté, le modifier invalide le travail. La date n'est la déclaration de personne : c'est une grandeur physique déjà dépensée.

Ce que la preuve N'établit PAS

Qui a créé le document, si son contenu est vrai, si son auteur avait le droit de le créer, ni que le document n'existait pas avant. Elle établit l'antériorité à un instant donné, non la paternité ni la véracité. Proovik ne voit à aucun moment le document : il n'en reçoit que le hash.

À propos du hash

SHA-256 est une fonction de condensé de 256 bits. Trouver deux documents différents ayant le même condensé n'a jamais été réalisé et l'effort estimé dépasse ce que l'humanité peut calculer. Dès lors, si le condensé du document fourni coïncide avec celui qui figure dans la chaîne, le document est le même, sans marge de doute en pratique.

Exemple réel · 20-09-2026

Les quatre maillons

La vérification est une chaîne. Chaque maillon s'accroche au suivant, et il suffit qu'un seul cède pour que la preuve ne vaille plus rien. Les valeurs qui suivent sont réelles : elles correspondent à un certificat émis le 20 septembre 2026.

1 2 3 4

1 · La donnée de la transaction est le condensé du document

Coïncide
Ce qu'il vérifie
Que l'empreinte de votre fichier est exactement celle qui est sur Kaspa.
En cas d'échec
Quelqu'un aurait modifié le document, ne serait-ce que d'un octet.
Comment
Toute transaction Kaspa admet un champ libre, payload. Proovik y écrit les 32 octets du SHA-256 du document, et rien d'autre. La vérification est une comparaison littérale.
Voir le calcul 
SHA-256(documento) == transaccion.payload
documento0f7383b381366cc3a75dadd7e4a1e8998c492f7c5c5610f4384d7320f484aad8
payload0f7383b381366cc3a75dadd7e4a1e8998c492f7c5c5610f4384d7320f484aad8

2 · La transaction est engagée dans l'en-tête du bloc

Coïncide
Ce qu'il vérifie
Que cette transaction fait partie du bloc que la preuve déclare, et d'aucun autre.
En cas d'échec
La transaction existerait, mais pas dans ce bloc ni avec cette date.
Comment
Kaspa inscrit dans chaque en-tête de la chaîne un engagement sur les transactions que ce bloc accepte. Depuis l'entrée en vigueur de KIP-15, ce champ, acceptedIdMerkleRoot, n'est pas une simple racine Merkle mais une valeur chaînée : il combine l'engagement du bloc parent avec la racine des transactions acceptées. Un recalcul qui ignore ce chaînage échoue, et c'est la cause la plus fréquente de vérifications erronées.
Voir le calcul 
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
séq. parent2b3265225d51e5b051e46b9f164dc116cf2e21d566827abc8a7b1ae036d8330d
calculé7843221eda25f05ddf9872ed57b59fb95c4f15aa7bf15017105e9797ef09caa5
dans l'en-tête7843221eda25f05ddf9872ed57b59fb95c4f15aa7bf15017105e9797ef09caa5
Deux pièges vérifiés

L'ordre des transactions acceptées est l'ordre canonique fixé par KIP-15, et non l'ordre dans lequel une API les renvoie ni un ordre par hash. Et les feuilles de l'arbre d'un bloc —lorsqu'on vérifie l'inclusion au lieu de l'acceptation— ne sont pas les txid, mais les tx::hash, calculés avec l'encodage complet (y compris les signature scripts et l'engagement de masse de stockage).

3 · L'en-tête produit le hash de bloc déclaré

Coïncide
Ce qu'il vérifie
Que l'en-tête reçu, recalculé octet par octet, donne exactement ce hash de bloc.
En cas d'échec
L'en-tête ne serait pas celui du bloc : la date qu'il contient ne vaudrait rien.
Comment
Le hash d'un bloc est le condensé de son en-tête sérialisé. Le recalculer démontre que l'en-tête fourni est exactement celui qu'il prétend être, et qu'aucun de ses champs —horodatage compris— n'a été touché.
Voir le calcul 
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
bloc77ee3a38aecdb3d8e97a010f7f8f78927e48282d22ebfae3004713ba8a9d51fc
Exigence non négociable

L'en-tête s'engage sur tous les niveaux de parents —aujourd'hui 56, avec plus de deux cents hashes—. S'il en manque un seul, le condensé ne peut pas être reconstruit. C'est la raison pour laquelle le fichier de preuve doit capturer l'en-tête intégral au moment de l'ancrage : passé une trentaine d'heures, le réseau écarte ces données et les services publics renvoient un en-tête tronqué.

4 · Une preuve de travail valide a été exécutée sur cet en-tête

Travail valide
Ce qu'il vérifie
Que le travail a été fait sur cet en-tête, avec cette date à l'intérieur. Changer la date invalide le travail.
En cas d'échec
La date serait une déclaration, non une grandeur physique déjà dépensée.
Comment
C'est ici que la preuve cesse d'être une affirmation pour devenir une constatation. Kaspa exige que le résultat de l'application de sa fonction de travail (kHeavyHash) à l'en-tête reste sous un seuil. L'atteindre demande des milliers de billions d'essais : de l'énergie réelle, irréversiblement dépensée.
Voir le calcul 
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
résultat0x15222b53caabb3b049ec84e25d0a0c7a35512f9d557adb4bc20
cible0x2345b0000000000000000000000000000000000000000000000
ancré2026-09-20 00:03:00 UTC
La date

Pourquoi la date est une grandeur physique et non une déclaration

C'est la partie que la contradiction réclame le plus souvent ; mieux vaut donc la montrer que l'argumenter. L'horodatage se trouve à l'intérieur de l'en-tête, et l'en-tête est l'entrée de la preuve de travail. Modifier l'heure modifie l'entrée, et le travail cesse d'être valide. Cela se vérifie expérimentalement en altérant l'en-tête vérifié à l'étape 4 et en refaisant le calcul :

Effet d'une altération de l'en-tête sur le résultat de la preuve de travail
En-tête Résultat du travail Verdict
Original, intact0x15222b53caabb3b049ec…Valide
nonce + 10x6775abc19ba960657f66…Invalide
timestamp avancé d'une seconde0xaee1e8274b1d268866ed…Invalide
La conséquence

Pour présenter le document avec une date différente, il faudrait refaire la preuve de travail de cet en-tête contre la difficulté réelle du réseau. Ce n'est pas une barrière de coût : c'est une barrière de calcul de l'ordre de la puissance agrégée de tout le réseau pendant l'intervalle que l'on prétendrait falsifier. Personne ne déclare la date. La date se paie.

Permanence

Cela fonctionnera-t-il encore après de futurs hardforks ?

La réponse honnête est oui, et il vaut la peine de comprendre pourquoi. Une preuve capturée n'est pas une interrogation en direct du réseau : c'est un fait historique, vérifié avec les règles en vigueur au moment où elle a été ancrée. Kaspa évolue avec le temps —la transition Crescendo/Toccata a modifié, par exemple, le rythme du DAA et le comptage de la difficulté—, mais cela n'efface pas le passé : cela signifie seulement qu'un bloc de janvier 2026 se vérifie avec les règles de janvier 2026, et un bloc de dans trois ans avec celles de dans trois ans.

Le vérificateur de référence est construit pour cela : il distingue les ères. Il connaît le point d'activation de chaque changement de consensus (par exemple, la constante CRESCENDO_DAA_MAINNET) et applique à chaque bloc les règles de son époque, non celles d'aujourd'hui. Un hardfork ultérieur ajoute une nouvelle ère ; il n'invalide pas les précédentes.

La permanence de la preuve repose alors sur trois conditions, toutes sous le contrôle de celui qui la détient :

1

Capturer dans la fenêtre

Enregistrer l'en-tête intégral au moment de l'ancrage, avant que le réseau n'écarte les données complètes (environ 30 à 40 heures).

2

Conserver la preuve

Le fichier de preuve (ou le PDF qui l'embarque) se suffit à lui-même : il ne renvoie à aucun serveur ni à aucune consultation en ligne.

3

Conserver le vérificateur de référence

248 lignes de code ouvert, sans dépendances, redérivables du code source public de Kaspa. Même s'il se perdait, il se réécrit.

Vérifiez-le vous-même

Faites-le sans Proovik

Le vérificateur de référence tient en 248 lignes de Python sans dépendances externes : il implémente blake2b à clé, la permutation Keccak-f[1600], le générateur xoshiro256++ et l'arithmétique de la matrice. Il se lit en une après-midi et s'audite en deux.

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

Télécharger le vérificateur de référence

Deux fichiers. Placez-les dans le même dossier et exécutez le premier. Ils n'installent rien et ne sortent jamais sur le réseau.

verificador_kaspa.py kaspa_pow.py

Qui préfère ne pas exécuter du code écrit par autrui peut le réimplémenter : les quatre algorithmes sont décrits ci-dessus sans ambiguïté, et tous les paramètres proviennent du code source public de rusty-kaspa. Il est tout aussi légitime de consulter la transaction dans n'importe quel explorateur public de Kaspa à titre de contrôle, mais il faut comprendre la différence : l'explorateur est un témoignage ; le calcul est une démonstration. Cette spécification existe pour ne pas dépendre du premier.

Cadre juridique

Portée juridique

Proovik fournit un service d'horodatage électronique non qualifié au sens de l'article 3, point 16 i), du règlement (UE) n° 910/2014. Il convient d'être explicite sur ce que cela signifie.

  • Conformément à l'article 41, paragraphe 1, dudit règlement, l'effet juridique et la recevabilité comme preuve en justice d'un horodatage électronique ne peuvent être refusés au seul motif que cet horodatage se présente sous une forme électronique ou qu'il ne satisfait pas aux exigences de l'horodatage qualifié.
  • Un horodatage non qualifié ne bénéficie pas de la présomption d'exactitude de la date et de l'heure de l'article 41, paragraphe 2, réservée aux horodatages qualifiés. En cas de contestation, la charge d'étayer la preuve incombe à celui qui la produit.
  • C'est précisément pour cela que cette spécification existe : pour que cette charge soit satisfaite par une vérification arithmétique reproductible par n'importe qui, plutôt que par la déclaration du prestataire.

Proovik ne vérifie ni le contenu, ni la paternité, ni la licéité des documents, et n'y accède à aucun moment : il n'en reçoit que le condensé cryptographique. Ce qui est établi, c'est une preuve d'existence et d'antériorité à un instant déterminé.

Références

Sérialisation de l'en-tête et de la transaction, construction de l'arbre Merkle et preuve de travail, d'après le code source de l'implémentation de référence 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/.

Les valeurs utilisées comme exemple correspondent à des certificats réels et sont vérifiables par n'importe qui. Cette spécification est versionnée : les preuves indiquent en leur sein la version sous laquelle elles ont été émises.