Proovik
Certificare
Verificatore pubblico · PVK-PROOF/1

Come verificare una prova di Proovik senza fidarsi di Proovik

Ti servono il file di prova (o il PDF del certificato) e la tua copia del documento originale. Non viene caricato nulla: l'impronta viene calcolata nel tuo browser. Qui sotto, la specifica completa, passo per passo e con valori reali.

Versione 1 Rete: Kaspa mainnet Verificatore di riferimento: 248 righe di Python, senza dipendenze
Strumento

Verificare una prova online

Verifica qui un certificato con lo stesso motore descritto più sotto. Il documento non esce dal tuo dispositivo: il suo SHA-256 viene calcolato nel tuo browser e viaggia solo l'impronta. L'hash lo fornisci tu, non viene mai preso dal file di prova. Se trascini il PDF del certificato, il pacchetto di evidenze allegato viene estratto nel tuo browser e nemmeno il PDF viene inviato.

1 · File di prova

2 · Documento originale

Il verificatore non prende mai l'hash dal file di prova: lo fornisci tu.

Il pacchetto e l'hash vengono inviati a POST /api/verify/proof. Senza account. Limite: 120 verifiche all'ora per IP.

Compare nel certificato PDF e nell'explorer di Kaspa.

Puoi calcolarlo trascinando il documento nell'altra scheda: il valore viene condiviso.

Questa modalità ricostruisce il pacchetto interrogando api.kaspa.org. Kaspa serve l'intestazione completa solo per circa 40 ore dopo l'ancoraggio: trascorso quel termine gli anelli 3 e 4 non possono essere ricalcolati e il verdetto sarà Non conclusivo, mai «Attesta». Per una verifica completa usa il file di prova catturato al momento.

GET /api/verify/proof/{txid}?hash=…. Limite: 30 all'ora per IP (interroga la rete).

Verdetto ·

Attestato Non conclusivo Non attestato

I quattro anelli reggono: il documento con questo SHA-256 esisteva quando è stato minato il blocco indicato. Ricorda che cosa la prova non attesta: né la paternità né la veridicità del contenuto.

Ciò che è stato possibile ricalcolare regge, ma manca qualche dato (di norma l'intestazione completa del blocco, fuori dalla finestra di pruning) per chiudere la catena. Non è un difetto della prova: è una verifica parziale. Con il file di prova catturato al momento, o con il pacchetto di evidenze completo, si può portare a termine.

Almeno un anello non regge con l'hash fornito. Il caso più frequente: il documento non è esattamente quello che è stato sigillato (un solo byte diverso cambia lo SHA-256) oppure il file di prova non corrisponde a questo documento. Controlla il dettaglio di ogni anello.

Vedi la transazione sulla rete
documento
txid
block_hash
rete
modalità
intestazione
verificato

Gli anelli, uno per uno

  1. Testimone di accettazione (KIP-15)

    Il pacchetto non include un testimone di accettazione. È facoltativo: non incide sul verdetto.

Avvertenze

Che cosa significa ogni anello

Portata della prova

Che cosa si afferma esattamente

Qui la precisione conta più dell'eloquenza, perché da essa dipende la tenuta della prova nel contraddittorio.

Che cosa attesta la prova

Che una sequenza di byte il cui SHA-256 è un valore determinato è stata inserita in una transazione della rete Kaspa, che quella transazione è rimasta vincolata all'interno dell'intestazione di un blocco e che su quell'intestazione —che include una marca temporale— è stata eseguita una proof of work valida. Poiché la marca temporale sta dentro il dato su cui è stato svolto il lavoro, alterarla invalida il lavoro. La data non è la dichiarazione di nessuno: è una grandezza fisica già spesa.

Che cosa NON attesta la prova

Chi ha creato il documento, se il suo contenuto è vero, se il suo autore aveva il diritto di crearlo, né che il documento non esistesse prima. Attesta l'anteriorità rispetto a un istante, non la paternità né la veridicità. Proovik non vede il documento in alcun momento: ne riceve soltanto l'hash.

Sull'hash

SHA-256 è una funzione di digest da 256 bit. Trovare due documenti diversi con lo stesso digest non è mai riuscito a nessuno e lo sforzo stimato eccede ciò che l'umanità è in grado di calcolare. Perciò, se il digest del documento fornito coincide con quello scritto sulla catena, il documento è lo stesso, senza margine pratico di dubbio.

Esempio reale · 20-09-2026

I quattro anelli

La verifica è una catena. Ogni anello si aggancia al successivo e basta che uno ceda perché la prova non valga. I valori riportati qui sotto sono reali: corrispondono a un certificato emesso il 20 settembre 2026.

1 2 3 4

1 · Il dato della transazione è il digest del documento

Corrisponde
Che cosa verifica
Che l'impronta del tuo file sia esattamente quella scritta su Kaspa.
Se fallisse
Qualcuno avrebbe modificato il documento, foss'anche di un solo byte.
Come
Ogni transazione di Kaspa ammette un campo libero, payload. Proovik ci scrive i 32 byte dello SHA-256 del documento, e nient'altro. La verifica è un confronto letterale.
Vedi il calcolo 
SHA-256(documento) == transaccion.payload
documento0f7383b381366cc3a75dadd7e4a1e8998c492f7c5c5610f4384d7320f484aad8
payload0f7383b381366cc3a75dadd7e4a1e8998c492f7c5c5610f4384d7320f484aad8

2 · La transazione è vincolata nell'intestazione del blocco

Corrisponde
Che cosa verifica
Che questa transazione faccia parte del blocco dichiarato dalla prova, e non di un altro.
Se fallisse
La transazione esisterebbe, ma non in quel blocco né con quella data.
Come
Kaspa registra in ogni intestazione della catena un impegno rispetto alle transazioni che quel blocco accetta. Dall'entrata in vigore di KIP-15 quel campo, acceptedIdMerkleRoot, non è una semplice radice Merkle ma un valore concatenato: combina l'impegno del blocco padre con la radice delle transazioni accettate. Un ricalcolo che ignori questa concatenazione fallisce, ed è questa la causa più frequente di verifiche errate.
Vedi il calcolo 
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. parent2b3265225d51e5b051e46b9f164dc116cf2e21d566827abc8a7b1ae036d8330d
calcolato7843221eda25f05ddf9872ed57b59fb95c4f15aa7bf15017105e9797ef09caa5
nell'intestazione7843221eda25f05ddf9872ed57b59fb95c4f15aa7bf15017105e9797ef09caa5
Due trabocchetti verificati

L'ordine delle transazioni accettate è quello canonico fissato da KIP-15, non l'ordine in cui le restituisce un'API né l'ordine per hash. E le foglie dell'albero di un blocco —quando si verifica l'inclusione anziché l'accettazione— non sono i txid, ma i tx::hash, calcolati con la codifica completa (compresi i signature script e l'impegno di massa di archiviazione).

3 · L'intestazione produce l'hash di blocco dichiarato

Corrisponde
Che cosa verifica
Che l'intestazione ricevuta, ricalcolata byte per byte, dia esattamente questo hash di blocco.
Se fallisse
L'intestazione non sarebbe quella del blocco: la data che contiene non varrebbe nulla.
Come
L'hash di un blocco è il digest della sua intestazione serializzata. Ricalcolarlo dimostra che l'intestazione fornita è esattamente quella che dichiara di essere e che nessuno dei suoi campi —marca temporale compresa— è stato toccato.
Vedi il calcolo 
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
blocco77ee3a38aecdb3d8e97a010f7f8f78927e48282d22ebfae3004713ba8a9d51fc
Requisito non negoziabile

L'intestazione si impegna rispetto a tutti i livelli di parent —oggi sono 56, con più di duecento hash—. Se ne manca anche uno solo, il digest non può essere ricostruito. È questo il motivo per cui il file di prova deve catturare l'intestazione integrale al momento dell'ancoraggio: passate una trentina di ore, la rete scarta quei dati e i servizi pubblici restituiscono l'intestazione troncata.

4 · Su quell'intestazione è stata eseguita una proof of work valida

Lavoro valido
Che cosa verifica
Che il lavoro sia stato svolto su questa intestazione, con questa data al suo interno. Cambiare la data invalida il lavoro.
Se fallisse
La data sarebbe una dichiarazione, non una grandezza fisica già spesa.
Come
È qui che la prova smette di essere un'affermazione e diventa una constatazione. Kaspa esige che il risultato dell'applicazione della sua funzione di lavoro (kHeavyHash) all'intestazione resti al di sotto di una soglia. Raggiungerlo richiede milioni di miliardi di tentativi: energia reale, spesa in modo irreversibile.
Vedi il calcolo 
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
risultato0x15222b53caabb3b049ec84e25d0a0c7a35512f9d557adb4bc20
obiettivo0x2345b0000000000000000000000000000000000000000000000
ancorato2026-09-20 00:03:00 UTC
La data

Perché la data è una grandezza fisica e non una dichiarazione

Questa è la parte che il contraddittorio di solito esige, quindi conviene mostrarla anziché argomentarla. La marca temporale sta dentro l'intestazione, e l'intestazione è l'input della proof of work. Modificare l'ora modifica l'input, e il lavoro cessa di essere valido. Lo si verifica sperimentalmente alterando l'intestazione verificata al passo 4 e ripetendo il calcolo:

Effetto dell'alterazione dell'intestazione sul risultato della proof of work
Intestazione Risultato del lavoro Verdetto
Originale, intatta0x15222b53caabb3b049ec…Valido
nonce + 10x6775abc19ba960657f66…Non valido
timestamp spostato avanti di un secondo0xaee1e8274b1d268866ed…Non valido
La conseguenza

Per presentare il documento con una data diversa bisognerebbe rifare la proof of work di quell'intestazione contro la difficoltà reale della rete. Non è una barriera di costo: è una barriera di calcolo dell'ordine della potenza aggregata dell'intera rete per tutto l'intervallo che si intende falsificare. Nessuno dichiara la data. La data si paga.

Permanenza

Continuerà a funzionare dopo i futuri hardfork?

La risposta onesta è sì, e conviene capire perché. Una prova catturata non è un'interrogazione in tempo reale alla rete: è un fatto storico, verificato con le regole in vigore nel momento in cui è stata ancorata. Kaspa cambia nel tempo —la transizione Crescendo/Toccata ha modificato, per esempio, il ritmo del DAA e il conteggio della difficoltà—, ma questo non cancella il passato: significa soltanto che un blocco del gennaio 2026 si verifica con le regole del gennaio 2026, e uno di fra tre anni con quelle di fra tre anni.

Il verificatore di riferimento è costruito proprio per questo: distingue le ere. Conosce il punto di attivazione di ogni cambio di consenso (per esempio la costante CRESCENDO_DAA_MAINNET) e applica a ogni blocco le regole della sua epoca, non quelle di oggi. Un hardfork successivo aggiunge una nuova era; non invalida quelle precedenti.

La permanenza della prova poggia quindi su tre condizioni, tutte sotto il controllo di chi la possiede:

1

Catturare entro la finestra

Salvare l'intestazione integrale al momento dell'ancoraggio, prima che la rete scarti i dati completi (circa 30-40 ore).

2

Conservare la prova

Il file di prova (o il PDF che lo incorpora) è autosufficiente: non rimanda ad alcun server né a consultazioni online.

3

Conservare il verificatore di riferimento

248 righe di codice aperto, senza dipendenze, ri-derivabili dal codice sorgente pubblico di Kaspa. Anche se andasse perso, si riscrive.

Lo verifichi lei stesso

Fallo senza Proovik

Il verificatore di riferimento è fatto di 248 righe di Python senza dipendenze esterne: implementa blake2b con chiave, la permutazione Keccak-f[1600], il generatore xoshiro256++ e l'aritmetica della matrice. Si legge in un pomeriggio e se ne fa l'audit in due.

Terminale 
$ 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

Scarica il verificatore di riferimento

Due file. Li collochi nella stessa cartella ed esegua il primo. Non installano nulla e non accedono alla rete.

verificador_kaspa.py kaspa_pow.py

Chi preferisce non eseguire codice altrui può reimplementarlo: i quattro algoritmi sono descritti sopra senza ambiguità e tutti i parametri provengono dal codice sorgente pubblico di rusty-kaspa. È altrettanto legittimo consultare la transazione in qualunque explorer pubblico di Kaspa come controprova, ma conviene capire la differenza: l'explorer è una testimonianza; il calcolo è una dimostrazione. Questa specifica esiste per non dipendere dal primo.

Quadro giuridico

Ambito giuridico

Proovik presta un servizio di validazione temporale elettronica non qualificata ai sensi dell'articolo 3, punto 16, lett. i) del Regolamento (UE) n. 910/2014. Conviene essere espliciti su che cosa questo significhi.

  • Ai sensi dell'articolo 41, paragrafo 1 del citato Regolamento, a una validazione temporale elettronica non possono essere negati gli effetti giuridici e l'ammissibilità come prova in procedimenti giudiziali per il solo motivo della sua forma elettronica o perché non soddisfa i requisiti di una validazione temporale qualificata.
  • Una validazione temporale non qualificata non gode della presunzione di accuratezza della data e dell'ora dell'articolo 41, paragrafo 2, riservata a quelle qualificate. In caso di contestazione, l'onere di comprovare la prova ricade su chi la produce.
  • Proprio per questo esiste questa specifica: perché quell'onere si assolva con una verifica aritmetica riproducibile da chiunque, anziché con la dichiarazione del prestatore.

Proovik non verifica il contenuto, la paternità né la liceità dei documenti e non vi accede in alcun momento: ne riceve unicamente il digest crittografico. Ciò che viene attestato è una prova di esistenza e anteriorità rispetto a un determinato istante.

Riferimenti

Serializzazione dell'intestazione e della transazione, costruzione dell'albero Merkle e proof of work, secondo il codice sorgente dell'implementazione di riferimento di 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/.

I valori usati come esempio corrispondono a certificati reali e sono verificabili da chiunque. Questa specifica è versionata: le prove indicano al loro interno la versione con cui sono state emesse.