Proovik
Certificeren
Openbare verificatietool · PVK-PROOF/1

Hoe je een Proovik-bewijs controleert zonder Proovik te vertrouwen

Je hebt het bewijsbestand (of de PDF van het certificaat) en je eigen kopie van het originele document nodig. Er wordt niets geüpload: de hash wordt in je browser berekend. Hieronder de volledige specificatie, stap voor stap en met echte waarden.

Versie 1 Netwerk: Kaspa mainnet Referentieverificatietool: 248 regels Python, zonder afhankelijkheden
Hulpmiddel

Een bewijs online verifiëren

Controleer hier een certificaat met dezelfde motor die hieronder wordt beschreven. Het document verlaat je apparaat niet: de SHA-256 ervan wordt in je browser berekend en alleen de hash gaat de deur uit. De hash lever jij aan, hij wordt nooit uit het bewijsbestand gehaald. Sleep je de PDF van het certificaat hierheen, dan wordt het bijgevoegde bewijspakket in je browser uitgepakt en wordt ook de PDF niet verzonden.

1 · Bewijsbestand

2 · Origineel document

De verificatietool neemt de hash nooit uit het bewijsbestand: die lever jij aan.

Het pakket en de hash worden naar POST /api/verify/proof gestuurd. Zonder account. Limiet: 120 verificaties per uur en per IP.

Staat op het PDF-certificaat en in de Kaspa-explorer.

Je kunt hem berekenen door het document op het andere tabblad neer te zetten: de waarde wordt gedeeld.

Deze modus reconstrueert het pakket door api.kaspa.org te raadplegen. Kaspa levert de volledige header maar ongeveer 40 uur na de verankering: daarna zijn schakel 3 en 4 niet meer te herberekenen en luidt het oordeel Niet doorslaggevend, nooit “Aangetoond”. Gebruik voor een volledige verificatie het bewijsbestand dat destijds is vastgelegd.

GET /api/verify/proof/{txid}?hash=…. Limiet: 30 per uur en per IP (raadpleegt het netwerk).

Oordeel ·

Aangetoond Niet doorslaggevend Niet aangetoond

De vier schakels kloppen: het document met deze SHA-256 bestond toen het aangegeven blok werd gemined. Denk eraan wat het bewijs niet aantoont: auteurschap of waarheid van de inhoud.

Wat herberekend kon worden klopt, maar er ontbreken gegevens (meestal de volledige blokheader, buiten het pruning-venster) om de keten te sluiten. Dat is geen tekortkoming van het bewijs: het is een gedeeltelijke verificatie. Met het destijds vastgelegde bewijsbestand, of met het volledige bewijspakket, kan ze worden afgemaakt.

Ten minste één schakel klopt niet met de aangeleverde hash. Meestal: het document is niet precies het document dat verzegeld is (één andere byte verandert de SHA-256) of het bewijsbestand hoort niet bij dit document. Bekijk het detail van elke schakel.

De transactie op het netwerk bekijken
document
txid
block_hash
netwerk
modus
header
geverifieerd

De schakels, een voor een

  1. Acceptatiegetuige (KIP-15)

    Het pakket bevat geen acceptatiegetuige. Die is optioneel: het heeft geen invloed op het oordeel.

Waarschuwingen

Wat elke schakel betekent

Reikwijdte van het bewijs

Wat er precies wordt beweerd

Precisie telt hier zwaarder dan welsprekendheid, want daarvan hangt af of het bewijs een tegenspraak doorstaat.

Wat het bewijs aantoont

Dat een reeks bytes waarvan de SHA-256 een bepaalde waarde is, in een transactie op het Kaspa-netwerk is opgenomen, dat die transactie is vastgelegd in de header van een blok, en dat over die header —die een tijdstempel bevat— een geldige proof-of-work is uitgevoerd. Doordat het tijdstempel binnen de gegevens zit waarover het werk is verricht, maakt wijziging ervan dat werk ongeldig. De datum is niemands verklaring: het is een fysieke grootheid die al is verbruikt.

Wat het bewijs NIET aantoont

Wie het document heeft gemaakt, of de inhoud ervan waar is, of de auteur het recht had het te maken, noch dat het document niet eerder bestond. Het toont anterioriteit ten opzichte van een tijdstip aan, niet auteurschap of waarheid. Proovik ziet het document op geen enkel moment: het ontvangt alleen de hash ervan.

Over de hash

SHA-256 is een hashfunctie van 256 bits. Twee verschillende documenten met dezelfde hash vinden is nog nooit gelukt, en de geschatte inspanning gaat verder dan wat de mensheid kan berekenen. Daarom geldt: komt de hash van het aangeleverde document overeen met die op de keten, dan is het document hetzelfde, zonder praktische ruimte voor twijfel.

Echt voorbeeld · 20-09-2026

De vier schakels

Verificatie is een keten. Elke schakel grijpt in de volgende, en één schakel die het begeeft is genoeg om het bewijs waardeloos te maken. De waarden hieronder zijn echt: ze horen bij een certificaat dat op 20 september 2026 is uitgegeven.

1 2 3 4

1 · De payload van de transactie is de hash van het document

Komt overeen
Wat het controleert
Dat de hash van je bestand precies die is die op Kaspa staat.
Als het zou falen
Dan zou iemand het document hebben gewijzigd, al was het maar één byte.
Hoe
Elke Kaspa-transactie heeft een vrij veld, payload. Proovik schrijft daar de 32 bytes van de SHA-256 van het document, en niets anders. De controle is een letterlijke vergelijking.
De berekening bekijken 
SHA-256(documento) == transaccion.payload
documento0f7383b381366cc3a75dadd7e4a1e8998c492f7c5c5610f4384d7320f484aad8
payload0f7383b381366cc3a75dadd7e4a1e8998c492f7c5c5610f4384d7320f484aad8

2 · De transactie is vastgelegd in de header van het blok

Komt overeen
Wat het controleert
Dat deze transactie deel uitmaakt van het blok dat het bewijs aangeeft, en van geen ander.
Als het zou falen
De transactie zou bestaan, maar niet in dat blok en niet met die datum.
Hoe
Kaspa registreert in elke header van de keten een commitment aan de transacties die dat blok accepteert. Sinds KIP-15 van kracht werd, is dat veld, acceptedIdMerkleRoot, geen gewone Merkle-wortel meer maar een geketende waarde: het combineert het commitment van het ouderblok met de wortel van de geaccepteerde transacties. Een herberekening die die ketening negeert, mislukt, en dat is de meest voorkomende oorzaak van foutieve verificaties.
De berekening bekijken 
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
ouder-seq.2b3265225d51e5b051e46b9f164dc116cf2e21d566827abc8a7b1ae036d8330d
berekend7843221eda25f05ddf9872ed57b59fb95c4f15aa7bf15017105e9797ef09caa5
in de header7843221eda25f05ddf9872ed57b59fb95c4f15aa7bf15017105e9797ef09caa5
Twee bevestigde valkuilen

De volgorde van de geaccepteerde transacties is de canonieke volgorde die KIP-15 vastlegt, niet de volgorde waarin een API ze teruggeeft en ook niet de volgorde op hash. En de bladeren van de boom van een blok —wanneer opname in plaats van acceptatie wordt geverifieerd— zijn niet de txid-waarden, maar de tx::hash-waarden, berekend met de volledige codering (inclusief de signature scripts en het commitment van de opslagmassa).

3 · De header levert de aangegeven blokhash op

Komt overeen
Wat het controleert
Dat de ontvangen header, byte voor byte herberekend, precies deze blokhash oplevert.
Als het zou falen
Dan zou de header niet die van het blok zijn: de datum die erin staat zou niets waard zijn.
Hoe
De hash van een blok is de digest van de geserialiseerde header ervan. Die herberekenen bewijst dat de aangeleverde header precies is wat hij beweert te zijn, en dat geen van zijn velden —het tijdstempel inbegrepen— is aangeraakt.
De berekening bekijken 
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
blok77ee3a38aecdb3d8e97a010f7f8f78927e48282d22ebfae3004713ba8a9d51fc
Niet-onderhandelbare eis

De header legt zich vast op alle ouderniveaus —vandaag zijn dat er 56, met meer dan tweehonderd hashes—. Ontbreekt er ook maar één, dan is de digest niet te reconstrueren. Daarom moet het bewijsbestand de volledige header vastleggen op het moment van verankering: na een uur of dertig gooit het netwerk die gegevens weg en geven openbare diensten de header afgekapt terug.

4 · Op die header is een geldige proof-of-work uitgevoerd

Geldig werk
Wat het controleert
Dat het werk over deze header is gedaan, met deze datum erin. De datum veranderen maakt het werk ongeldig.
Als het zou falen
Dan zou de datum een verklaring zijn en geen fysieke grootheid die al is verbruikt.
Hoe
Hier houdt het bewijs op een bewering te zijn en wordt het een vaststelling. Kaspa eist dat het resultaat van zijn werkfunctie (kHeavyHash) op de header onder een drempel blijft. Dat halen vergt duizenden biljoenen pogingen: echte energie, onomkeerbaar verbruikt.
De berekening bekijken 
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
resultaat0x15222b53caabb3b049ec84e25d0a0c7a35512f9d557adb4bc20
doelwaarde0x2345b0000000000000000000000000000000000000000000000
verankerd2026-09-20 00:03:00 UTC
De datum

Waarom de datum een fysieke grootheid is en geen verklaring

Dit is het deel dat de tegenspraak meestal opeist, dus je kunt het beter tonen dan beargumenteren. Het tijdstempel zit binnen de header, en de header is de invoer van de proof-of-work. De tijd wijzigen wijzigt de invoer, en het werk is niet langer geldig. Dat is experimenteel te controleren door de in stap 4 geverifieerde header te wijzigen en de berekening te herhalen:

Effect van het wijzigen van de header op het resultaat van de proof-of-work
Header Resultaat van het werk Oordeel
Origineel, onaangeroerd0x15222b53caabb3b049ec…Geldig
nonce + 10x6775abc19ba960657f66…Ongeldig
timestamp één seconde vooruitgezet0xaee1e8274b1d268866ed…Ongeldig
Het gevolg

Om het document met een andere datum te presenteren zou de proof-of-work van die header opnieuw gedaan moeten worden tegen de werkelijke moeilijkheidsgraad van het netwerk. Dat is geen kostenbarrière: het is een rekenbarrière in de orde van het gezamenlijke vermogen van het hele netwerk gedurende het interval dat men wil vervalsen. Niemand verklaart de datum. De datum wordt betaald.

Bestendigheid

Blijft het werken na toekomstige hardforks?

Het eerlijke antwoord is ja, en het is goed te begrijpen waarom. Een vastgelegd bewijs is geen live-bevraging van het netwerk: het is een historisch feit, geverifieerd met de regels die golden op het moment van verankering. Kaspa verandert in de loop van de tijd —de overgang Crescendo/Toccata wijzigde bijvoorbeeld het ritme van de DAA en de telling van de moeilijkheidsgraad—, maar dat wist het verleden niet uit: het betekent alleen dat een blok uit januari 2026 met de regels van januari 2026 wordt geverifieerd, en een blok van over drie jaar met de regels van over drie jaar.

De referentieverificatietool is daar precies voor gebouwd: hij onderscheidt tijdperken. Hij kent het activeringspunt van elke consensuswijziging (bijvoorbeeld de constante CRESCENDO_DAA_MAINNET) en past op elk blok de regels van zijn tijd toe, niet die van vandaag. Een latere hardfork voegt een nieuw tijdperk toe; hij maakt de eerdere niet ongeldig.

De bestendigheid van het bewijs rust dan op drie voorwaarden, die alle in handen zijn van wie het bewijs bezit:

1

Vastleggen binnen het venster

Bewaar de volledige header op het moment van verankering, voordat het netwerk de volledige gegevens weggooit (een uur of 30-40).

2

Het bewijs bewaren

Het bewijsbestand (of de PDF waarin het is ingesloten) is zelfvoorzienend: het verwijst naar geen enkele server en doet geen enkele online bevraging.

3

De referentieverificatietool bewaren

248 regels opensourcecode, zonder afhankelijkheden, opnieuw af te leiden uit de openbare broncode van Kaspa. Zelfs als hij verloren zou gaan, is hij te herschrijven.

Verifieer het zelf

Doe het zonder Proovik

De referentieverificatietool bestaat uit 248 regels Python zonder externe afhankelijkheden: hij implementeert blake2b met sleutel, de Keccak-f[1600]-permutatie, de xoshiro256++-generator en de matrixrekenkunde. Je leest hem in één middag en je auditeert hem in twee.

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

De referentieverificatietool downloaden

Twee bestanden. Zet ze in dezelfde map en voer het eerste uit. Ze installeren niets en gaan niet het netwerk op.

verificador_kaspa.py kaspa_pow.py

Wie liever geen code van een ander uitvoert, kan hem opnieuw implementeren: de vier algoritmen staan hierboven ondubbelzinnig beschreven, en alle parameters komen uit de openbare broncode van rusty-kaspa. Het is even legitiem om de transactie ter vergelijking in een openbare Kaspa-explorer op te zoeken, maar het is goed het verschil te begrijpen: de explorer is een getuigenis; de berekening is een bewijsvoering. Deze specificatie bestaat om niet van het eerste afhankelijk te zijn.

Juridisch kader

Juridische reikwijdte

Proovik levert een dienst voor niet-gekwalificeerde elektronische tijdstempels in de zin van artikel 3, punt 16, onder i) van Verordening (EU) nr. 910/2014. Het is goed expliciet te zijn over wat dat betekent.

  • Op grond van artikel 41, lid 1 van die verordening mag aan een elektronisch tijdstempel het rechtsgevolg en de toelaatbaarheid als bewijsmiddel in gerechtelijke procedures niet worden ontzegd louter op grond van het feit dat het in elektronische vorm is of niet aan de eisen voor een gekwalificeerd tijdstempel voldoet.
  • Een niet-gekwalificeerd tijdstempel geniet niet het vermoeden van juistheid van de datum en het tijdstip van artikel 41, lid 2, dat is voorbehouden aan gekwalificeerde tijdstempels. Bij betwisting rust de last om het bewijs te staven op wie het aanvoert.
  • Juist daarom bestaat deze specificatie: opdat die last wordt vervuld met een rekenkundige controle die iedereen kan herhalen, in plaats van met de verklaring van de dienstverlener.

Proovik controleert de inhoud, het auteurschap en de rechtmatigheid van de documenten niet, en heeft er op geen enkel moment toegang toe: het ontvangt alleen de cryptografische hash ervan. Wat wordt aangetoond is een bewijs van bestaan en anterioriteit ten opzichte van een bepaald tijdstip.

Referenties

Serialisatie van header en transactie, opbouw van de Merkle-boom en proof-of-work, volgens de broncode van de referentie-implementatie van 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/.

De waarden die als voorbeeld zijn gebruikt horen bij echte certificaten en zijn door iedereen te controleren. Deze specificatie wordt geversioneerd: bewijzen vermelden in zichzelf met welke versie ze zijn uitgegeven.