Proovik
Sertifiser
Offentlig verifikator · PVK-PROOF/1

Slik kontrollerer du et Proovik-bevis uten å stole på Proovik

Du trenger bevisfilen (eller PDF-sertifikatet) og din egen kopi av originaldokumentet. Ingenting lastes opp: fingeravtrykket beregnes i nettleseren din. Nedenfor finner du hele spesifikasjonen, steg for steg og med ekte verdier.

Versjon 1 Nettverk: Kaspa mainnet Referanseverifikator: 248 linjer Python, uten avhengigheter
Verktøy

Verifiser et bevis på nett

Kontroller et sertifikat her med den samme motoren som beskrives nedenfor. Dokumentet forlater aldri enheten din: SHA-256 beregnes i nettleseren din, og bare fingeravtrykket sendes. Hashen oppgir du selv; den hentes aldri fra bevisfilen. Slipper du PDF-sertifikatet, hentes den vedlagte bevispakken ut i nettleseren din, og PDF-en sendes heller ikke.

1 · Bevisfil

2 · Originaldokument

Verifikatoren henter aldri hashen fra bevisfilen: den oppgir du.

Pakken og hashen sendes til POST /api/verify/proof. Uten konto. Grense: 120 verifiseringer per time og IP.

Står på PDF-sertifikatet og vises i Kaspa-utforskeren.

Du kan beregne den ved å slippe dokumentet i den andre fanen: verdien deles.

Denne modusen bygger opp pakken igjen ved å spørre api.kaspa.org. Kaspa leverer bare det fullstendige blokkhodet i rundt 40 timer etter forankringen: etter det kan ledd 3 og 4 ikke beregnes på nytt, og verdiktet blir Ikke konklusivt, aldri «Dokumentert». For en fullstendig verifisering, bruk bevisfilen som ble fanget opp der og da.

GET /api/verify/proof/{txid}?hash=…. Grense: 30 per time og IP (den spør nettverket).

Verdikt ·

Dokumentert Ikke konklusivt Ikke dokumentert

De fire leddene stemmer: dokumentet med denne SHA-256 fantes da den oppgitte blokken ble utvunnet. Husk hva beviset ikke dokumenterer: verken opphav eller om innholdet er sant.

Det som kunne beregnes på nytt, stemmer, men noen data mangler (som regel det fullstendige blokkhodet, utenfor beskjæringsvinduet) for å lukke kjeden. Det er ikke en svikt ved beviset: det er en delvis verifisering. Med bevisfilen som ble fanget opp der og da, eller med den fullstendige bevispakken, kan den fullføres.

Minst ett ledd stemmer ikke med hashen som er oppgitt. Vanligst: dokumentet er ikke akkurat det som ble forseglet (én byte forskjell endrer SHA-256), eller bevisfilen hører ikke til dette dokumentet. Se gjennom detaljene for hvert ledd.

Se transaksjonen på nettverket
dokument
txid
block_hash
nettverk
modus
blokkhode
verifisert

Leddene, ett for ett

  1. Aksepteringsvitne (KIP-15)

    Pakken inneholder ikke noe aksepteringsvitne. Det er valgfritt: det påvirker ikke verdiktet.

Advarsler

Hva hvert ledd betyr

Bevisets omfang

Hva som nøyaktig hevdes

Presisjon betyr mer enn veltalenhet her, for det er dette som avgjør om beviset holder i en kontradiktorisk prosess.

Det beviset dokumenterer

At en bytestreng med en bestemt SHA-256 ble lagt inn i en transaksjon på Kaspa-nettverket, at den transaksjonen ble forpliktet inne i et blokkhode, og at det over det blokkhodet —som inneholder et tidsstempel— ble utført et gyldig arbeidsbevis. Siden tidsstemplet ligger inne i dataene arbeidet ble gjort på, ugyldiggjør enhver endring av det arbeidet. Datoen er ingens erklæring: den er en fysisk størrelse som allerede er brukt.

Det beviset IKKE dokumenterer

Hvem som laget dokumentet, om innholdet er sant, om opphavspersonen hadde rett til å lage det, eller at dokumentet ikke fantes tidligere. Det dokumenterer at noe forelå før et gitt øyeblikk, ikke opphav eller sannhet. Proovik ser aldri dokumentet: det mottar bare hashen.

Om hashen

SHA-256 er en hashfunksjon på 256 bit. Å finne to forskjellige dokumenter med samme hashverdi har aldri lyktes, og den anslåtte innsatsen overstiger det menneskeheten kan beregne. Derfor: hvis hashverdien av dokumentet som legges fram, stemmer med den som ligger i kjeden, er dokumentet det samme, uten praktisk rom for tvil.

Ekte eksempel · 20.09.2026

De fire leddene

Verifiseringen er en kjede. Hvert ledd henger sammen med det neste, og det holder at ett svikter for at beviset skal være verdiløst. Verdiene som vises nedenfor, er ekte: de hører til et sertifikat utstedt 20. september 2026.

1 2 3 4

1 · Transaksjonens nyttelast er dokumentets hashverdi

Samsvarer
Hva det kontrollerer
At filens fingeravtrykk er nøyaktig det som ligger på Kaspa.
Hvis det sviktet
Da hadde noen endret dokumentet, om så bare med én byte.
Hvordan
Enhver Kaspa-transaksjon har et fritt felt, payload. Der skriver Proovik de 32 bytene i dokumentets SHA-256, og ingenting annet. Kontrollen er en bokstavelig sammenligning.
Se utregningen 
SHA-256(documento) == transaccion.payload
documento0f7383b381366cc3a75dadd7e4a1e8998c492f7c5c5610f4384d7320f484aad8
payload0f7383b381366cc3a75dadd7e4a1e8998c492f7c5c5610f4384d7320f484aad8

2 · Transaksjonen er forpliktet i blokkhodet

Samsvarer
Hva det kontrollerer
At denne transaksjonen hører til blokken beviset oppgir, og ikke til noen annen.
Hvis det sviktet
Transaksjonen ville finnes, men ikke i den blokken og ikke med den datoen.
Hvordan
Kaspa registrerer i hvert blokkhode i kjeden en forpliktelse til transaksjonene den blokken aksepterer. Etter at KIP-15 trådte i kraft, er det feltet, acceptedIdMerkleRoot, ikke en enkel Merkle-rot, men en lenket verdi: den kombinerer forelderblokkens forpliktelse med roten til de aksepterte transaksjonene. En ny utregning som overser denne lenkingen, feiler, og det er den vanligste årsaken til mislykkede verifiseringer.
Se utregningen 
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. forelder2b3265225d51e5b051e46b9f164dc116cf2e21d566827abc8a7b1ae036d8330d
beregnet7843221eda25f05ddf9872ed57b59fb95c4f15aa7bf15017105e9797ef09caa5
i blokkhodet7843221eda25f05ddf9872ed57b59fb95c4f15aa7bf15017105e9797ef09caa5
To verifiserte fallgruver

Rekkefølgen på de aksepterte transaksjonene er den kanoniske rekkefølgen KIP-15 fastsetter, ikke rekkefølgen et API returnerer dem i, og heller ikke rekkefølge etter hash. Og bladene i en blokks tre —når det er inklusjon og ikke aksept som verifiseres— er ikke txid, men tx::hash, beregnet med den fullstendige kodingen (inkludert signature scripts og forpliktelsen til lagringsmasse).

3 · Blokkhodet gir den oppgitte blokkhashen

Samsvarer
Hva det kontrollerer
At blokkhodet som er mottatt, beregnet på nytt byte for byte, gir nøyaktig denne blokkhashen.
Hvis det sviktet
Blokkhodet ville ikke være blokkens: datoen det inneholder, ville være verdiløs.
Hvordan
Hashen til en blokk er hashverdien av det serialiserte blokkhodet. Å beregne den på nytt viser at blokkhodet som er lagt fram, er nøyaktig det det utgir seg for å være, og at ingen av feltene —heller ikke tidsstemplet— er rørt.
Se utregningen 
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
blokk77ee3a38aecdb3d8e97a010f7f8f78927e48282d22ebfae3004713ba8a9d51fc
Krav det ikke forhandles om

Blokkhodet forplikter seg til alle foreldrenivåene —i dag 56 av dem, med over to hundre hasher—. Mangler ett eneste, kan hashverdien ikke rekonstrueres. Det er grunnen til at bevisfilen må fange opp hele blokkhodet i forankringsøyeblikket: etter rundt tretti timer forkaster nettverket disse dataene, og offentlige tjenester returnerer et avkortet blokkhode.

4 · Et gyldig arbeidsbevis ble utført over det blokkhodet

Gyldig arbeid
Hva det kontrollerer
At arbeidet ble gjort over dette blokkhodet, med denne datoen inni. Å endre datoen ugyldiggjør arbeidet.
Hvis det sviktet
Datoen ville vært en erklæring, ikke en fysisk størrelse som allerede er brukt.
Hvordan
Det er her beviset slutter å være en påstand og blir en konstatering. Kaspa krever at resultatet av å anvende arbeidsfunksjonen sin (kHeavyHash) på blokkhodet, faller under en terskel. Å nå dit krever tusenvis av billioner forsøk: ekte energi, ugjenkallelig brukt.
Se utregningen 
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

Dette er den delen en kontradiktorisk prosess som regel krever, så den bør heller vises enn argumenteres for. Tidsstemplet ligger inne i blokkhodet, og blokkhodet er inndataene til arbeidsbeviset. Endrer du klokkeslettet, endrer du inndataene, og arbeidet er ikke lenger gyldig. Det kontrolleres eksperimentelt ved å endre blokkhodet som ble verifisert i steg 4, og gjenta utregningen:

Virkningen av å endre blokkhodet på resultatet av arbeidsbeviset
Blokkhode Arbeidsresultat Verdikt
Original, urørt0x15222b53caabb3b049ec…Gyldig
nonce + 10x6775abc19ba960657f66…Ugyldig
timestamp flyttet ett sekund fram0xaee1e8274b1d268866ed…Ugyldig
Konsekvensen

For å legge fram dokumentet med en annen dato måtte man gjøre arbeidsbeviset for det blokkhodet på nytt mot nettverkets reelle vanskelighetsgrad. Det er ikke en kostnadsbarriere: det er en beregningsbarriere i størrelsesorden hele nettverkets samlede kapasitet i det tidsrommet man vil forfalske. Ingen erklærer datoen. Datoen betales.

Bestandighet

Vil det fortsatt virke etter framtidige hardforker?

Det ærlige svaret er ja, og det er verdt å forstå hvorfor. Et bevis som er fanget opp, er ikke et direkte oppslag mot nettverket: det er et historisk faktum, verifisert etter reglene som gjaldt da det ble forankret. Kaspa endrer seg over tid —overgangen Crescendo/Toccata endret for eksempel DAA-rytmen og opptellingen av vanskelighetsgrad— men det sletter ikke fortiden: det betyr bare at en blokk fra januar 2026 verifiseres med reglene fra januar 2026, og en om tre år med reglene om tre år.

Referanseverifikatoren er bygget nettopp for dette: den skiller mellom epoker. Den kjenner aktiveringspunktet for hver konsensusendring (for eksempel konstanten CRESCENDO_DAA_MAINNET) og bruker på hver blokk reglene fra dens epoke, ikke dagens. En senere hardfork legger til en ny epoke; den ugyldiggjør ikke de tidligere.

Bevisets bestandighet hviler dermed på tre betingelser, alle under kontroll av den som har det:

1

Fang det opp innenfor vinduet

Lagre hele blokkhodet i forankringsøyeblikket, før nettverket forkaster de fullstendige dataene (rundt 30-40 timer).

2

Ta vare på beviset

Bevisfilen (eller PDF-en som har den innebygd) er selvbærende: den viser ikke til noen server og gjør ingen oppslag på nett.

3

Ta vare på referanseverifikatoren

248 linjer åpen kode, uten avhengigheter, som kan utledes på nytt fra Kaspas offentlige kildekode. Selv om den gikk tapt, kan den skrives på nytt.

Verifiser det selv

Gjør det uten Proovik

Referanseverifikatoren er 248 linjer Python uten eksterne avhengigheter: den implementerer blake2b med nøkkel, permutasjonen Keccak-f[1600], generatoren xoshiro256++ og matriseregningen. Den leses på en ettermiddag 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

Last ned referanseverifikatoren

To filer. Legg dem i samme mappe og kjør den første. De installerer ingenting og går aldri ut på nettet.

verificador_kaspa.py kaspa_pow.py

Den som helst ikke vil kjøre andres kode, kan implementere den på nytt: de fire algoritmene er beskrevet entydig ovenfor, og alle parametrene kommer fra den offentlige kildekoden til rusty-kaspa. Det er like legitimt å slå opp transaksjonen i en hvilken som helst offentlig Kaspa-utforsker som kontroll, men forskjellen er verdt å forstå: utforskeren er et vitnesbyrd; utregningen er en demonstrasjon. Denne spesifikasjonen finnes for at man ikke skal være avhengig av det første.

Juridisk rammeverk

Juridisk omfang

Proovik leverer en tjeneste for ikke-kvalifiserte elektroniske tidsstempler i betydningen artikkel 3 nr. 16 bokstav i) i forordning (EU) nr. 910/2014. Det er verdt å være tydelig på hva det betyr.

  • Etter artikkel 41 nr. 1 i den nevnte forordningen kan et elektronisk tidsstempel ikke nektes rettsvirkning eller adgang som bevis i rettergang utelukkende fordi det foreligger i elektronisk form eller ikke oppfyller kravene til et kvalifisert stempel.
  • Et ikke-kvalifisert stempel nyter ikke presumsjonen om at dato og klokkeslett er nøyaktige etter artikkel 41 nr. 2, som er forbeholdt kvalifiserte stempler. Ved innsigelse ligger byrden med å underbygge beviset hos den som legger det fram.
  • Nettopp derfor finnes denne spesifikasjonen: for at den byrden skal kunne oppfylles med en aritmetisk kontroll hvem som helst kan gjenta, i stedet for med tilbyderens erklæring.

Proovik verifiserer verken innholdet, opphavet eller lovligheten av dokumentene, og får aldri tilgang til dem: det mottar bare den kryptografiske hashverdien deres. Det som dokumenteres, er et bevis for eksistens og forutgående dato til et gitt øyeblikk.

Referanser

Serialisering av blokkhode og transaksjon, oppbygging av Merkle-treet og arbeidsbevis, i henhold til kildekoden til Kaspas referanseimplementasjon (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/.

Verdiene som brukes som eksempel, hører til ekte sertifikater og kan kontrolleres av hvem som helst. Denne spesifikasjonen versjoneres: bevisene angir selv hvilken versjon de ble utstedt under.