Cos'è la Proof of Existence?

La Proof of Existence (prova dell'esistenza) è un modo per dimostrare che dati precisi esistevano entro un certo momento, usando un timestamp pubblico che chiunque può controllare.

Il metodo è semplice. Calcola l'hash dei dati, pubblica quell'hash in un record pubblico con timestamp e, in seguito, lascia che chiunque disponga dei dati originali ricalcoli l'hash e lo confronti con il record. Se i due hash coincidono, il verificatore sa che gli stessi byte esistevano entro il momento di quel record. Non deve fidarsi di te, del tuo server o del tuo account — solo del record pubblico e della matematica.

Il file in sé non deve mai essere pubblico. La prova può essere pubblica mentre il contenuto resta privato.

Cosa dimostra la Proof of Existence?

Dimostra un'affermazione precisa e circoscritta, ma utile:

Questi byte esatti esistevano entro questo momento pubblico.

È tutto ciò che la prova di base afferma — e la sua forza nasce proprio da quanto è specifica.

Quasi tutto può essere ridotto a un hash crittografico: un documento, un'immagine, un video, un dataset, un archivio di codice sorgente, un artefatto di build, un contratto, un file di log, l'output di un modello o un manifest. L'hash è una breve impronta di una precisa sequenza di byte. Cambia un solo byte e l'impronta cambia completamente.

Quando quell'hash viene ancorato in un record pubblico, il record diventa un testimone temporale. In seguito, se mostri a qualcuno il file originale, quella persona ne ricalcola l'hash. Se il nuovo hash coincide con quello registrato, può confermare che il file davanti a sé è esattamente lo stesso dato vincolato in precedenza — al momento del timestamp del record o prima.

Questo rende la Proof of Existence preziosa ogni volta che il fattore tempo conta:

• dimostrare che un file esisteva prima di una controversia;
• dimostrare che un report esisteva prima della scadenza di un audit;
• dimostrare che un artefatto software esisteva al momento del rilascio;
• dimostrare che lo snapshot di un dataset esisteva prima di essere modificato;
• dimostrare che un output AI, un set di prompt o un file multimediale esisteva prima di essere contestato.

La prova non è una descrizione del file. È un impegno crittografico sui suoi byte esatti.

Perché il file non deve essere pubblico?

Perché ciò che è pubblico è l'hash, non il file.

Una buona funzione di hash si comporta come un'impronta a senso unico. Chiunque può calcolare l'hash a partire dal file, ma chi vede solo l'hash non può ricostruire il file da esso. È per questo che un documento privato può portare con sé una prova pubblica: il record dice «qualcuno si è impegnato su questi byte esatti in questo momento» senza rivelare i byte.

Per esempio, un'azienda può calcolare l'hash del manifest di un dataset riservato e pubblicare solo l'hash. Il dataset resta privato. In seguito, se l'azienda deve dimostrare cosa conteneva lo snapshot, può rivelare il manifest completo, un suo sottoinsieme o una inclusion proof (prova di inclusione) di un singolo elemento — a seconda di ciò che la situazione richiede.

È anche per questo che la Proof of Existence si adatta bene ai team legali, di compliance e di sicurezza: crea un timestamp esterno senza inserire prove riservate in un database pubblico. Per un'analisi più approfondita di questo schema, vedi la divulgazione riservata senza file pubblici.

Che ruolo gioca la blockchain?

La blockchain è il testimone temporale pubblico — la parte che nessuno, neppure chi pubblica, può riscrivere di nascosto.

Se un hash vive solo nel tuo database, la prova dipende interamente dal tuo sistema. Quando in seguito il timestamp viene messo in dubbio, qualcuno può ragionevolmente chiedersi se il database sia stato riscritto, ripristinato da un backup, modificato da un amministratore o retrodatato. Una blockchain pubblica elimina questo dubbio. Una volta confermata la transazione, il record con timestamp è visibile a chiunque e non è più sotto il controllo esclusivo di chi lo ha pubblicato.

In CardanoWall, il record della prova è ancorato nei metadati di una transazione Cardano sotto la label dei metadati 309. Un verificatore recupera la transazione da un explorer pubblico di Cardano a sua scelta, legge il record e confronta l'hash del contenuto con i byte originali. In quel controllo non è coinvolto alcun server di CardanoWall — il punto è proprio che la prova regge anche senza di noi.

La blockchain non comprende il tuo documento, e non ne ha bisogno. Registra i dati della prova; il significato emerge quando un verificatore ricalcola l'hash e conferma che i byte coincidono.

Qual è la prova più semplice?

La prova più semplice è quella solo-hash.

Scegli un file. Il software calcola un hash, per esempio SHA-256 o BLAKE2b-256. Quell'hash finisce in un record pubblicato nei metadati di Cardano. In seguito, un verificatore ripete il calcolo dell'hash sul file originale e, se il digest coincide, la prova è valida.

Quindi il primo livello si riduce a tre fatti:

1. Il contenuto esiste.
2. Il suo hash è ancorato on-chain.
3. Chiunque disponga del contenuto originale può verificare la corrispondenza.

Per molti usi, tanto basta. Un hash con timestamp è potente proprio perché è semplice — c'è poco da configurare male e nulla di cui fidarsi.

Quando un hash non basta?

Un hash nudo risponde bene a una domanda, ma non a ogni domanda.

Non dice chi ha creato il file. Mostra soltanto che i byte esistevano. Se due persone possiedono entrambe lo stesso PDF pubblico, ognuna di esse può pubblicarne l'hash; l'hash da solo non dice nulla sulla paternità.

Non conserva il file. Perdi i byte originali e ti resta comunque un hash pubblico, ma potresti non avere più nulla da confrontare con esso.

E non consegna il file a nessuno. Se un'altra persona ha bisogno dei dati originali, un hash nudo non glieli mette in mano.

Ecco perché il formato del record sottostante è stratificato. Un record solo-hash è pienamente valido, ma lo standard supporta anche firme, payload sigillati (cifrati), consegna indirizzata al destinatario e Merkle batching — ciascuno aggiunge una capacità in più sopra il timestamp.

In che modo una firma cambia la prova?

Una firma aggiunge un'affermazione garantita da una chiave.

Un record firmato dice qualcosa in più rispetto a «questi byte esistevano entro questo momento». Può dire anche «questa chiave ha firmato questo record». Questo conta per la paternità, le approvazioni, i controlli interni e i flussi di lavoro aziendali: un'organizzazione può usare una chiave di firma per mostrare che un determinato sistema, team o identità ha avallato un record, e un creatore può firmare una prova per associare la propria identità a un'opera.

La formulazione, però, deve restare precisa. Una firma mostra che la chiave ha firmato il record — non chi, nel mondo reale, detiene quella chiave. Legare una chiave a una persona dipende da un contesto stabilito al di fuori del record. (CardanoWall mantiene le firme opzionali per scelta progettuale; chiunque può pubblicare, e i verificatori non devono mai fidarsi di chi pubblica.)

In che modo la sigillatura cambia la prova?

Una prova sigillata aggiunge una conservazione cifrata.

In un record sigillato, la prova on-chain continua a impegnarsi sull'hash del testo in chiaro. Ma il file in sé può essere cifrato e conservato in una posizione indirizzata per contenuto — un indirizzo ar:// (Arweave) o ipfs:// — mantenendo nel record solo il suo riferimento. La catena non vede mai il testo in chiaro.

Questo conta quando la perdita del file originale renderebbe difficile usare l'hash. Con una prova sigillata, chi possiede la chiave giusta può in seguito recuperare il testo cifrato conservato, decifrarlo, ricalcolare l'hash del testo in chiaro e confermare che il file decifrato è esattamente il contenuto vincolato on-chain. Poiché l'indirizzo di storage deriva dai byte stessi, il destinatario può anche capire che un gateway di storage ha restituito i byte giusti senza doversi fidare di quel gateway.

La catena pubblica non deve mai esporre il testo in chiaro. Il payload cifrato viaggia insieme alla prova, mentre la chiave di decifratura resta a chi è destinato a detenerla.

In che modo la consegna al destinatario cambia la prova?

La consegna al destinatario permette di cifrare un record sigillato per qualcun altro.

Se conosci l'indirizzo di ricezione di un destinatario (una chiave pubblica che ha condiviso), puoi pubblicare un record sigillato che solo lui può aprire con la propria chiave. Da notare che il record non porta alcun campo che dica «questo è per Alice». On-chain non c'è alcun destinatario indicato. Il software del destinatario scorre i record pubblici e prova a decifrare a tentativi, in silenzio, quelli che potrebbero essere indirizzati alle sue chiavi, aprendo solo quelli che lo sono davvero.

Questo trasforma la Proof of Existence in qualcosa di più del timestamp personale. Può supportare la divulgazione riservata, lo scambio di prove legali, i pacchetti di compliance privati e i passaggi di consegne per l'audit interno — flussi di lavoro in cui la cronologia deve essere pubblica ma il contenuto no. Prima di sigillare qualcosa per qualcuno, però, vale la pena confermare che la chiave gli appartenga davvero; vedi come verificare un destinatario prima di sigillare un file.

Un limite onesto: la cifratura protegge i byte, non le persone. La sigillatura mantiene il testo in chiaro leggibile solo da chi detiene la chiave, ma non garantisce l'anonimato, e un destinatario può sempre divulgare il testo in chiaro una volta che lo ha decifrato.

In che modo il Merkle batching cambia la prova?

Il Merkle batching permette a un solo record di impegnarsi su molti elementi in una volta.

Invece di una transazione per ogni file, un sistema può calcolare l'hash di migliaia o milioni di elementi, ripiegare quegli hash in un Merkle tree e pubblicare una singola root da 32 byte. In seguito, una inclusion proof mostra che un elemento specifico faceva parte del batch vincolato. Il verificatore non ha bisogno di avere ogni file on-chain: la root è l'impegno pubblico, e una breve inclusion proof — che cresce solo con il logaritmo della dimensione del batch — collega un singolo elemento a quella root. Tutti gli altri elementi del batch restano privati.

Questo si adatta ai flussi di lavoro ad alto volume:

• artefatti CI/CD e release manifest;
• log di compliance giornalieri;
• contenuti generati dall'AI su larga scala;
• snapshot di dataset;
• cartelle di prove per l'audit;
• archivi multimediali ed editoriali.

La modalità Merkle mantiene minuscolo il record on-chain, permettendo a una sola prova di coprire un insieme enorme di elementi. Per un esempio pratico, vedi un solo record per migliaia di file.

Cosa non dimostra la Proof of Existence?

Questa è la sezione che mantiene onesta la prova. Un impegno con timestamp è forte perché è specifico — ed essere specifici significa che ci sono affermazioni che semplicemente non fa.

Non dimostra che un documento sia vero. Un documento falso può essere marcato temporalmente con la stessa facilità di uno vero.

Non dimostra la proprietà. Chiunque può calcolare l'hash di un file che non possiede.

Non dimostra da sola la paternità. La paternità richiede firme, gestione delle chiavi e un contesto reale sovrapposti.

Non dimostra che una build software sia sicura. Può mostrare quale artefatto, SBOM, log o manifest esisteva in un dato momento, ma la sicurezza dipende dal processo di build e dai controlli che lo circondano.

Non dimostra che un dataset sia stato raccolto o usato legalmente. Può mostrare che l'impegno su un dataset esisteva — il che può essere una prova importante — ma i diritti legali sono una questione a parte che dipende dalla tua giurisdizione e dai tuoi consulenti.

In breve: la Proof of Existence ti dà tempistica e integrità, non verità o diritti. Qualunque ulteriore affermazione va costruita con cura su quella base. Cosa una prova non dimostra approfondisce con precisione dove passa il confine.

Perché CardanoWall si basa su Label 309

Una prova è utile solo nella misura in cui è portabile. Una che funziona solo all'interno di un singolo sito web non è granché come prova — una prova seria dovrebbe essere leggibile da strumenti indipendenti, verificabile da un'infrastruttura pubblica e comprensibile da software che il servizio originale non ha mai scritto.

È per questo che CardanoWall è costruito su Label 309, uno standard aperto e neutrale rispetto al fornitore per la Proof of Existence su Cardano. Label 309 — non l'app CardanoWall — è l'artefatto durevole; l'app web, lo strumento da riga di comando e gli SDK sono implementazioni di riferimento che ne discendono. Lo standard definisce un unico formato di record che scala a partire da un semplice timestamp:

• prove solo-hash per la semplice esistenza;
• prove firmate per affermazioni di paternità garantite da una chiave;
• prove sigillate per la conservazione cifrata;
• prove sigillate per destinatario per la consegna privata;
• prove Merkle per i batch ad alto volume;
• identificatori di algoritmo con nome, così che la crittografia possa evolvere nel tempo senza compromettere i record più vecchi.

Il formato è anche sottoposto a revisione pubblica: la Proof of Existence sotto la label dei metadati 309 è stata presentata al processo CIP di Cardano ed è in revisione presso gli editor CIP come proposta di categoria Metadata. (La label dei metadati 309 è l'identificatore on-chain; il numero CIP viene assegnato separatamente dal processo.) Lo standard completo, le sue implementazioni di riferimento e tutto il codice open source vivono pubblicamente su github.com/cardanowall con licenze permissive.

CardanoWall è l'interfaccia. Label 309 è il formato del record. La prova è progettata per sopravvivere a entrambi — all'interfaccia e all'azienda che ti ha aiutato a pubblicarla.

Approfondimenti

• Come funziona Label 309 — lo standard dietro ogni prova CardanoWall.
• Cosa finisce sulla blockchain — esattamente quali byte vengono pubblicati e quali non lasciano mai il tuo dispositivo.
• Verifica un record Label 309 — come controllare una prova da solo, a partire dalla sola infrastruttura pubblica.
• Come la Proof of Existence si confronta con altri sistemi di marcatura temporale e di provenienza: rispetto a OpenTimestamps, rispetto a un'autorità di timestamp e rispetto a C2PA / Content Credentials.