Proovik
Certificér
Offentlig verifikator · PVK-PROOF/1

Sådan kontrollerer du et Proovik-bevis uden at stole på Proovik

Du skal bruge bevisfilen (eller certifikatets PDF) og din kopi af det originale dokument. Intet uploades: hashen beregnes i din browser. Nedenfor finder du hele specifikationen, trin for trin og med rigtige værdier.

Version 1 Netværk: Kaspa mainnet Referenceverifikator: 248 linjer Python, uden afhængigheder
Værktøj

Verificér et bevis online

Kontrollér et certifikat her med den samme motor, som beskrives nedenfor. Dokumentet forlader ikke din enhed: dets SHA-256 beregnes i din browser, og kun hashen sendes. Hashen leverer du selv; den tages aldrig fra bevisfilen. Trækker du certifikatets PDF hertil, udtrækkes den vedhæftede bevispakke i din browser, og PDF'en sendes heller ikke.

1 · Bevisfil

2 · Originaldokument

Verifikatoren tager aldrig hashen fra bevisfilen: den leverer du.

Pakken og hashen sendes til POST /api/verify/proof. Uden konto. Grænse: 120 verifikationer i timen pr. IP.

Det står på PDF-certifikatet og i Kaspa-exploreren.

Du kan beregne den ved at trække dokumentet ind i den anden fane: værdien deles.

Denne tilstand genopbygger pakken ved at forespørge api.kaspa.org. Kaspa leverer kun den fulde header i omkring 40 timer efter forankringen: derefter kan led 3 og 4 ikke genberegnes, og verdiktet bliver Uafklaret, aldrig »Godtgjort«. Vil du have en fuldstændig verifikation, så brug den bevisfil, der blev fanget dengang.

GET /api/verify/proof/{txid}?hash=…. Grænse: 30 i timen pr. IP (der forespørges på netværket).

Verdikt ·

Godtgjort Uafklaret Ikke godtgjort

De fire led stemmer: dokumentet med denne SHA-256 fandtes, da den angivne blok blev minet. Husk, hvad beviset ikke godtgør: hverken ophavsmand eller indholdets rigtighed.

Det, der kunne genberegnes, stemmer, men der mangler data (normalt blokkens fulde header, som ligger uden for beskæringsvinduet) for at lukke kæden. Det er ikke en fejl ved beviset: det er en delvis verifikation. Med den bevisfil, der blev fanget dengang, eller med den komplette bevispakke kan den fuldføres.

Mindst ét led stemmer ikke med den angivne hash. Det mest almindelige: dokumentet er ikke præcis det, der blev forseglet (én anderledes byte ændrer SHA-256), eller bevisfilen hører ikke til dette dokument. Se detaljerne for hvert led.

Se transaktionen på netværket
dokument
txid
block_hash
netværk
tilstand
header
verificeret

Leddene, ét for ét

  1. Acceptvidne (KIP-15)

    Pakken indeholder intet acceptvidne. Det er valgfrit: det påvirker ikke verdiktet.

Advarsler

Hvad hvert led betyder

Bevisets omfang

Hvad der præcist hævdes

Præcision betyder mere end veltalenhed her, for det afgør, om beviset kan holde til en kontradiktorisk prøvelse.

Hvad beviset godtgør

At en bytestreng, hvis SHA-256 er en bestemt værdi, blev lagt ind i en transaktion på Kaspa-netværket, at den transaktion blev bundet ind i en bloks header, og at der over den header — som indeholder et tidsstempel — blev udført et gyldigt proof of work. Fordi tidsstemplet ligger inde i de data, arbejdet blev udført på, ugyldiggør enhver ændring af det arbejdet. Datoen er ikke nogens erklæring: den er en fysisk størrelse, der allerede er brugt.

Hvad beviset IKKE godtgør

Hvem der har skabt dokumentet, om indholdet er sandt, om ophavsmanden havde ret til at skabe det, eller at dokumentet ikke fandtes tidligere. Det godtgør prioritet i forhold til et bestemt øjeblik, ikke ophavsmand eller rigtighed. Proovik ser på intet tidspunkt dokumentet: det modtager kun dets hash.

Om hashen

SHA-256 er en hashfunktion på 256 bit. Det er aldrig lykkedes at finde to forskellige dokumenter med samme hashværdi, og den anslåede indsats overstiger, hvad menneskeheden kan beregne. Derfor gælder: stemmer hashværdien af det fremlagte dokument med den, der ligger på kæden, er dokumentet det samme, uden praktisk rum for tvivl.

Virkeligt eksempel · 20-09-2026

De fire led

Verifikationen er en kæde. Hvert led hænger sammen med det næste, og det er nok, at ét svigter, for at beviset intet er værd. Værdierne nedenfor er ægte: de stammer fra et certifikat udstedt den 20. september 2026.

1 2 3 4

1 · Transaktionens payload er dokumentets hashværdi

Stemmer overens
Hvad det kontrollerer
At din fils hash er præcis den, der ligger på Kaspa.
Hvis det svigtede
Så ville nogen have ændret dokumentet, om så kun med en enkelt byte.
Hvordan
Enhver Kaspa-transaktion har et frit felt, payload. Der skriver Proovik de 32 byte af dokumentets SHA-256 og intet andet. Kontrollen er en bogstavelig sammenligning.
Se beregningen 
SHA-256(documento) == transaccion.payload
documento0f7383b381366cc3a75dadd7e4a1e8998c492f7c5c5610f4384d7320f484aad8
payload0f7383b381366cc3a75dadd7e4a1e8998c492f7c5c5610f4384d7320f484aad8

2 · Transaktionen er bundet ind i blokkens header

Stemmer overens
Hvad det kontrollerer
At denne transaktion hører til den blok, beviset angiver, og ikke til en anden.
Hvis det svigtede
Transaktionen ville findes, men ikke i den blok og ikke med den dato.
Hvordan
Kaspa registrerer i hver header på kæden en binding til de transaktioner, blokken accepterer. Siden KIP-15 trådte i kraft, er det felt, acceptedIdMerkleRoot, ikke en simpel Merkle-rod, men en kædet værdi: den kombinerer forældreblokkens binding med roden af de accepterede transaktioner. En genberegning, der ignorerer den kædning, slår fejl, og det er den hyppigste årsag til fejlslagne verifikationer.
Se beregningen 
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
forælder-seq.2b3265225d51e5b051e46b9f164dc116cf2e21d566827abc8a7b1ae036d8330d
beregnet7843221eda25f05ddf9872ed57b59fb95c4f15aa7bf15017105e9797ef09caa5
i headeren7843221eda25f05ddf9872ed57b59fb95c4f15aa7bf15017105e9797ef09caa5
To verificerede faldgruber

Rækkefølgen af de accepterede transaktioner er den kanoniske, som KIP-15 fastlægger, ikke den rækkefølge, et API returnerer dem i, og heller ikke rækkefølgen efter hash. Og bladene i en bloks træ — når man verificerer inklusion i stedet for accept — er ikke txid, men tx::hash, beregnet med den fulde kodning (inklusive signature scripts og bindingen til lagermasse).

3 · Headeren giver den angivne blok-hash

Stemmer overens
Hvad det kontrollerer
At den modtagne header, genberegnet byte for byte, giver præcis denne blok-hash.
Hvis det svigtede
Så ville headeren ikke være blokkens: den dato, den indeholder, ville intet være værd.
Hvordan
En bloks hash er hashværdien af dens serialiserede header. At genberegne den viser, at den fremlagte header er præcis det, den giver sig ud for at være, og at ingen af dens felter — tidsstemplet inklusive — er blevet rørt.
Se beregningen 
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
Krav, der ikke er til forhandling

Headeren binder sig til alle forældreniveauer — i dag 56 med over to hundrede hashværdier. Mangler blot ét eneste, kan hashværdien ikke rekonstrueres. Derfor skal bevisfilen fange hele headeren i forankringsøjeblikket: efter omkring tredive timer kasserer netværket de data, og offentlige tjenester returnerer en afkortet header.

4 · Der blev udført et gyldigt proof of work over den header

Gyldigt arbejde
Hvad det kontrollerer
At arbejdet blev udført over denne header med denne dato indeni. At ændre datoen ugyldiggør arbejdet.
Hvis det svigtede
Så ville datoen være en erklæring og ikke en fysisk størrelse, der allerede er brugt.
Hvordan
Her holder beviset op med at være en påstand og bliver en konstatering. Kaspa kræver, at resultatet af at anvende netværkets arbejdsfunktion (kHeavyHash) på headeren ligger under en tærskel. At nå dertil kræver tusindvis af billioner forsøg: rigtig energi, uigenkaldeligt brugt.
Se beregningen 
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
resultat0x15222b53caabb3b049ec84e25d0a0c7a35512f9d557adb4bc20
mål0x2345b0000000000000000000000000000000000000000000000
forankret2026-09-20 00:03:00 UTC
Datoen

Derfor er datoen en fysisk størrelse og ikke en erklæring

Det er den del, som den kontradiktoriske prøvelse plejer at kræve, så den bør vises frem frem for at blive argumenteret. Tidsstemplet ligger inde i headeren, og headeren er input til proof of work. Ændrer man klokkeslættet, ændrer man inputtet, og arbejdet holder op med at være gyldigt. Det kan efterprøves eksperimentelt ved at ændre den header, der blev verificeret i trin 4, og gentage beregningen:

Virkningen af at ændre headeren på resultatet af proof of work
Header Arbejdets resultat Verdikt
Original, urørt0x15222b53caabb3b049ec…Gyldigt
nonce + 10x6775abc19ba960657f66…Ugyldigt
timestamp rykket ét sekund frem0xaee1e8274b1d268866ed…Ugyldigt
Konsekvensen

For at fremlægge dokumentet med en anden dato skulle man gøre den headers proof of work om mod netværkets reelle sværhedsgrad. Det er ikke en omkostningsbarriere: det er en beregningsbarriere i størrelsesordenen hele netværkets samlede ydeevne i det tidsrum, man vil forfalske. Ingen erklærer datoen. Datoen betales.

Holdbarhed

Vil det stadig virke efter fremtidige hardforks?

Det ærlige svar er ja, og det er værd at forstå hvorfor. Et fanget bevis er ikke en levende forespørgsel til netværket: det er en historisk kendsgerning, verificeret efter de regler, der gjaldt i det øjeblik, det blev forankret. Kaspa ændrer sig med tiden — overgangen Crescendo/Toccata ændrede for eksempel DAA-kadencen og optællingen af sværhedsgrad — men det sletter ikke fortiden: det betyder blot, at en blok fra januar 2026 verificeres med reglerne fra januar 2026, og en blok om tre år med reglerne om tre år.

Referenceverifikatoren er bygget netop til det: den skelner mellem epoker. Den kender aktiveringspunktet for hver konsensusændring (for eksempel konstanten CRESCENDO_DAA_MAINNET) og anvender på hver blok reglerne fra dens epoke, ikke dagens. En senere hardfork tilføjer en ny epoke; den ugyldiggør ikke de tidligere.

Bevisets holdbarhed hviler altså på tre betingelser, som alle er under kontrol af den, der har beviset:

1

Fang det inden for vinduet

Gem hele headeren i forankringsøjeblikket, før netværket kasserer de fulde data (omkring 30-40 timer).

2

Gem beviset

Bevisfilen (eller den PDF, der har den indlejret) er selvbærende: den henviser hverken til nogen server eller til noget opslag online.

3

Bevar referenceverifikatoren

248 linjer åben kildekode uden afhængigheder, som kan udledes på ny af Kaspas offentlige kildekode. Selv hvis den gik tabt, kan den skrives igen.

Verificér det selv

Gør det uden Proovik

Referenceverifikatoren er 248 linjer Python uden eksterne afhængigheder: den implementerer blake2b med nøgle, permutationen Keccak-f[1600], generatoren xoshiro256++ og matrixaritmetikken. Den kan læses på en eftermiddag og revideres på to.

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

Download referenceverifikatoren

To filer. Læg dem i samme mappe, og kør den første. De installerer intet og går ikke på nettet.

verificador_kaspa.py kaspa_pow.py

Den, der foretrækker ikke at køre andres kode, kan implementere den forfra: de fire algoritmer er beskrevet utvetydigt ovenfor, og alle parametre stammer fra den offentlige kildekode til rusty-kaspa. Det er lige så legitimt at slå transaktionen op i en hvilken som helst offentlig Kaspa-explorer som modkontrol, men forskellen er værd at forstå: exploreren er et vidneudsagn; beregningen er en demonstration. Denne specifikation findes for ikke at være afhængig af det første.

Juridiske rammer

Juridisk rækkevidde

Proovik leverer en ikke-kvalificeret elektronisk tidsstemplingstjeneste i den forstand, som artikel 3, nr. 16, litra i), i forordning (EU) nr. 910/2014 anvender begrebet. Det er værd at være tydelig om, hvad det betyder.

  • Efter artikel 41, stk. 1, i den nævnte forordning må et elektronisk tidsstempel ikke nægtes retsvirkning eller anerkendelse som bevis i retssager, alene fordi det er i elektronisk form, eller fordi det ikke opfylder kravene til et kvalificeret tidsstempel.
  • Et ikke-kvalificeret tidsstempel nyder ikke formodningen om nøjagtigheden af dato og klokkeslæt efter artikel 41, stk. 2, som er forbeholdt de kvalificerede. Bestrides det, påhviler det den, der fremlægger beviset, at underbygge det.
  • Netop derfor findes denne specifikation: for at den byrde kan løftes med en aritmetisk kontrol, som enhver kan gentage, i stedet for med udbyderens erklæring.

Proovik kontrollerer hverken dokumenternes indhold, ophavsmand eller lovlighed og får på intet tidspunkt adgang til dem: det modtager udelukkende deres kryptografiske hashværdi. Det, der godtgøres, er et bevis for eksistens og prioritet forud for et bestemt øjeblik.

Referencer

Serialisering af header og transaktion, opbygning af Merkle-træet og proof of work, efter kildekoden til Kaspas referenceimplementering (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 værdier, der bruges som eksempler, stammer fra rigtige certifikater og kan kontrolleres af enhver. Denne specifikation versioneres: beviserne angiver internt, hvilken version de blev udstedt under.