Cosa non dimostra una Proof of Existence

Una Proof of Existence dimostra una cosa precisa e circoscritta: questi byte esatti esistevano entro un momento pubblico. È un fatto davvero utile, ed è anche l'intera affermazione.

Una prova valida non mostra automaticamente che un file è veritiero, originale, di proprietà di chi lo pubblica, utilizzabile legalmente, completo o ammissibile in tribunale. Ciascuna di queste è un'affermazione a sé, che richiede prove proprie. Il modo più rapido per usare bene una prova, ed evitare di rivendicare più di quanto consenta, è capire con esattezza dove finisce la sua garanzia.

Questo articolo passa in rassegna le affermazioni che spesso si dà per scontato che un timestamp copra, dice in modo chiaro quali copre e quali no, e mostra come aggiungere il livello mancante quando ti serve qualcosa di più.

Cosa dimostra davvero una Proof of Existence?

Dimostra un impegno a livello di byte che fissa quei byte a un momento nel tempo.

Qualcuno prende un file, un messaggio, un dataset, un'immagine, un video, un archivio o un manifest e ne calcola un hash crittografico. Quell'hash finisce in un record pubblico con timestamp. In seguito, chiunque possieda i byte originali ricalcola l'hash e lo confronta con il record. Se i due coincidono, il verificatore può affermare una cosa con sicurezza:

Questa esatta sequenza di byte esisteva entro il momento del record pubblico.

Con CardanoWall e lo standard aperto Label 309, quel record pubblico è costituito dai metadati di una transazione Cardano, pubblicati sotto la label dei metadati 309. Per verificarlo, un verificatore legge la transazione da un explorer Cardano pubblico, ricompone il record Label 309, ne valida la struttura e confronta l'hash (oppure, per i record raggruppati, una inclusion proof basata su Merkle). Nessun server, dominio o account CardanoWall fa parte di questo controllo. La prova regge sulla sola catena pubblica.

Quell'impegno è il fondamento. Tutto ciò che segue è una domanda diversa.

Una prova dimostra che il file è veritiero?

No. Un'affermazione falsa può ricevere un timestamp con la stessa facilità di una vera. Una fattura contraffatta, un report errato, un'immagine manipolata: tutti producono un hash, e tutti possono essere ancorati.

Una Proof of Existence non giudica il contenuto. Dimostra che un contenuto specifico esisteva entro un certo momento, non che quel contenuto sia corretto.

Vale comunque molto. Se un report viene corretto in seguito, la prova del report originale mostra cosa esisteva prima della correzione. Se un'immagine viene contestata, la prova mostra che un determinato file esisteva prima che iniziasse la contestazione. Ma se l'affermazione contenuta nel file sia accurata dipende da tutt'altro: le prove circostanti, il processo di revisione, le fonti dei dati, i testimoni, il contesto.

Una prova fissa il quando e quali byte. Non decide mai se sia vero o falso.

Una prova dimostra la proprietà?

No. Se un file è pubblico, chiunque può calcolarne l'hash. Marcare temporalmente un PDF pubblico, una foto, un video, un file sorgente o un dataset non ti rende il proprietario: registra soltanto che possedevi quei byte entro quel momento.

Un timestamp può sostenere una storia di proprietà quando si affianca ad altri fatti:

• bozze e cronologia delle modifiche;
• record firmati;
• file sorgente originali;
• contratti e licenze;
• documenti di assunzione o di incarico;
• cronologia del repository;
• comunicazioni con i collaboratori.

La prova attesta il momento. Non è un atto di proprietà e non stabilisce diritti esclusivi.

Una prova dimostra chi ha creato il file?

Non da sola. Una prova solo-hash dice che certi byte esistevano; non dice nulla su chi li ha creati. Se due persone possiedono lo stesso file, ciascuna può pubblicare lo stesso hash.

I record Label 309 possono portare una firma opzionale. Un record firmato dimostra che una chiave crittografica specifica ha firmato il corpo del record, il che è significativamente più forte di un semplice hash, perché lega la prova a una chiave anziché a chiunque abbia inviato la transazione. Le firme nello standard sono sempre opzionali: chi pubblica e vuole restare indipendente dall'emittente le omette semplicemente.

Anche con una firma, le parole contano. Una firma dimostra che la chiave ha firmato il record. Da sola non dimostra la persona reale dietro quella chiave. Quel collegamento viene da come la chiave è stata stabilita: onboarding, una chiave pubblica pubblicata, una policy aziendale, un contratto, la custodia di un dispositivo o un altro processo esterno alla prova stessa.

Se vuoi una prova che porti anche la paternità, la firmi in modo deliberato e gestisci la chiave di firma con cura. La guida in hash, firma, sigilla, condividi spiega quando vale la pena aggiungere ciascuno di questi passaggi.

Una prova dimostra che chi pubblica è arrivato prima?

Di solito non da sola. Una prova può mostrare che chi pubblica possedeva i byte entro un certo momento. Non può mostrare che nessun altro li possedesse prima.

Conta soprattutto per i dati di addestramento dell'IA, i dataset, le opere creative e i segreti commerciali. Se oggi un'azienda marca temporalmente il manifest di un dataset, ha una prova solida che il manifest esisteva oggi. Ma se un'altra parte produce una prova più vecchia, una cronologia del repository o un record firmato, la linea temporale si sposta a suo favore.

La lezione pratica: pubblica presto e con costanza. Una prova più tardiva resta utile, ma un impegno pubblico anteriore è sempre quello più forte. Prima ancori, più difficile sarà mettere in discussione la tua linea temporale.

Una prova dimostra che il file non è mai stato modificato?

Dimostra qualcosa di più preciso: che un file che hai ora corrisponde ai byte sui quali ci si è impegnati.

Non dimostra che nessuna copia, da nessuna parte, sia mai stata alterata. Non protegge il tuo disco locale e non impedisce a qualcuno di modificare una versione diversa del file. La domanda di verifica a cui risponde è circoscritta e concreta:

Questo file corrisponde all'hash presente nel record pubblico?

Se sì, il file davanti a te è l'esatta sequenza di byte su cui ci si è impegnati. Se no, allora o il file è cambiato, o è stato fornito il file sbagliato, o è stato controllato l'hash sbagliato, oppure il record appartiene a byte diversi: il solo mancato riscontro non ti dice quale di questi.

Per qualunque cosa tu possa dover difendere in futuro, tieni insieme tre elementi: il file originale, il riferimento della transazione e qualsiasi manifest o inclusion proof basata su Merkle. Se il file originale stesso rischia di andare perso, è esattamente il caso da affrontare con una prova sigillata.

Una prova conserva il file al posto tuo?

Una prova solo-hash no. Se pubblichi solo un hash e in seguito perdi i byte originali, potresti avere ancora la prova che una certa sequenza di byte esisteva, ma potresti non essere più in grado di mostrare quale fosse quella sequenza.

È per questo che Label 309 supporta i record sigillati. Una prova sigillata si impegna sull'hash del testo in chiaro, mentre conserva il testo cifrato in una posizione indirizzata per contenuto, identificata da una URI ar:// (Arweave) o ipfs:// (IPFS). Chi possiede la chiave giusta può, in seguito, recuperare il testo cifrato, decifrarlo, ricalcolare l'hash del testo in chiaro e confermare che corrisponde all'impegno on-chain, recuperando così sia i byte sia la prova che li lega a un momento.

La modalità solo-hash basta quando conserverai tu stesso il file. Sigillare è la scelta migliore quando il recupero, o la consegna a qualcun altro, fa parte del piano.

Una prova dimostra la legalità o la compliance?

No. Un'azienda può marcare temporalmente dati raccolti in modo scorretto. Un creatore può marcare temporalmente contenuti che non ha alcun diritto di distribuire. Un team può marcare temporalmente un log di compliance incompleto. Un fornitore può marcare temporalmente il manifest di una release di software che viene comunque distribuito con vulnerabilità.

Una Proof of Existence può sostenere uno sforzo di compliance rendendo i record a prova di manomissione e ancorati nel tempo. Non può sostituire il programma di compliance vero e proprio.

La compliance reale viene da policy, controlli, raccolta lecita dei dati, registrazioni degli accessi, regole di retention, revisioni, approvazioni e, a volte, audit esterni. Una prova aiuta a mostrare cosa esisteva e quando. Non certifica che il processo sottostante fosse corretto. Se stai ancorando audit trail, log di compliance senza fiducia nel fornitore tratta esattamente questo confine.

Una prova stabilisce la catena di custodia?

No. La catena di custodia è la storia di un processo: chi ha raccolto un elemento, dove è stato conservato, chi vi ha avuto accesso, come si è spostato, quali strumenti l'hanno toccato e quali controlli ne hanno impedito la manomissione lungo il percorso.

Una prova Label 309 può essere un tassello di quella storia. Può mostrare che un file, un export, un log o un manifest di prove esisteva entro un momento pubblico e continua a corrispondere in seguito. Non può nominare ogni custode né spiegare ogni passaggio di gestione, a meno che quei fatti non siano a loro volta registrati — e idealmente vincolati con un impegno — altrove.

Per i flussi di lavoro probatori, lo schema è marcare temporalmente il manifest e conservare i record di processo circostanti a cui la prova rimanda.

Una prova garantisce la privacy?

No, e vale la pena essere precisi sui limiti.

Un record solo-hash non rivela il file originale in condizioni normali, ma comunica comunque che qualcuno si è impegnato su qualcosa in un certo momento. E se il file è a bassa entropia o facilmente indovinabile, un aggressore può calcolare l'hash dei candidati probabili e confrontarne ciascuno con il record finché non compare una corrispondenza.

Un record sigillato va oltre: il testo in chiaro non finisce mai on-chain in chiaro — vi finiscono solo il suo hash e una busta sigillata che non rivela il destinatario, con il testo cifrato conservato off-chain — e Label 309 è progettato deliberatamente in modo che le chiavi pubbliche dei destinatari non compaiano mai nel record. Ma la privacy è più ampia del formato del record. Tempi, pagamento delle commissioni, log del gateway, indirizzi IP, comportamento del browser, accesso allo storage, nomi dei file che vivono al di fuori del payload cifrato e ordinari errori operativi possono ciascuno far trapelare informazioni che la crittografia non tocca mai.

I flussi di lavoro sensibili hanno bisogno di sicurezza operativa attorno alla prova, non della sola cifratura. Quando l'obiettivo è la divulgazione a una parte specifica senza esporre nulla pubblicamente, divulgazione confidenziale senza file pubblici tratta l'approccio.

Una prova garantisce l'anonimato?

No. Un record Label 309 sigillato e non firmato può evitare di inserire nel record della prova stessa l'identità di un mittente o un elenco leggibile di destinatari: gli slot che portano le chiavi protette rivelano quanti destinatari ci sono, mai chi. È una proprietà reale e utile. Non rende anonimo il processo di pubblicazione che vi sta attorno.

La transazione Cardano ha comunque degli input e paga una commissione. Un gateway ospitato può vedere dettagli di account, pagamento, rete o tempi. Recuperare il testo cifrato dallo storage può lasciare tracce. Un utente può riutilizzare un indirizzo o rivelare il contesto da qualche altra parte.

Quindi l'affermazione onesta è circoscritta: il formato del record può omettere campi leggibili di mittente e destinatario. L'anonimato completo dipende dall'intero assetto operativo, non dai soli byte — una distinzione che conta soprattutto nelle prove dei whistleblower e in casi analoghi ad alto rischio.

Una prova garantisce che sarà accettata come prova legale?

No. Tribunali, autorità di regolamentazione, arbitri e controparti decidono ciascuno quali prove accettare in base alle regole che li riguardano. Una prova crittografica può essere una prova persuasiva di integrità e tempistica, ma non è un lasciapassare legale universale.

In alcune giurisdizioni o contratti possono essere richiesti un timestamp qualificato, un notaio, un servizio fiduciario regolamentato o un metodo di firma specifico. In altri, una prova ancorata a una blockchain pubblica può avere un peso reale come parte di un pacchetto probatorio più ampio. Quale dei due si applichi dipende dalla giurisdizione e dalla materia.

Rivolgiti a un legale quando una prova avrà rilevanza giuridica. Una prova può contribuire a stabilire tempistica e integrità; non sostituisce la consulenza legale, e questo articolo non è consulenza legale. Il ruolo pratico che una Proof of Existence tende a svolgere nelle controversie è illustrato in prove legali ed e-discovery.

Come si rende più forte una prova?

Aggiungi il livello che corrisponde all'affermazione di cui hai davvero bisogno — e solo quel livello.

• Ti serve la tempistica. Pubblica un hash, oppure una Merkle root per molti file in una volta sola.
• Ti serve la paternità o l'approvazione. Firma il record Label 309 e gestisci correttamente la chiave di firma.
• Ti serve il recupero dei byte. Sigilla il file e conserva il testo cifrato.
• Ti serve la consegna confidenziale. Cifra verso l'indirizzo di ricezione del destinatario.
• Ti servono prove ad alto volume. Impegnati su una singola Merkle root e conserva la lista delle foglie e le inclusion proof; una sola àncora può sostituire migliaia di file, come spiegato in un record per migliaia di file.
• Ti serve peso legale. Combina la prova con policy, contratti, servizi qualificati dove la tua giurisdizione li richiede e una catena di custodia documentata.

Ogni livello risponde a una domanda diversa. Impilarli è il modo in cui un semplice timestamp diventa una prova che porta esattamente l'affermazione che intendi.

In breve

Una prova è più forte quando dice solo ciò che può davvero dimostrare.

Label 309 dimostra l'esistenza a livello di byte entro un momento pubblico su Cardano. Su questa base può aggiungere firme di paternità, conservazione sigillata, consegna confidenziale e Merkle batching. Non sostituisce la verità, la proprietà, la legge, l'identità, la sicurezza operativa o il processo — e non finge di farlo.

Quell'onestà non è un punto debole del progetto. È ciò che rende la prova affidabile: sai sempre con esattezza cosa garantisce, e con esattezza cosa lascia al resto delle tue prove.

Approfondimenti

• Che cos'è la Proof of Existence? — l'idea di base di cui questo articolo delimita i confini.
• Hash, firma, sigilla, condividi — i livelli opzionali (firma, sigillatura, consegna) e quando vale la pena aggiungere ciascuno.
• Prove legali ed e-discovery — come una Proof of Existence si inserisce in una controversia, e dove si ferma.
• Proof of Existence e autorità di marcatura temporale a confronto — ancorare nel consenso pubblico anziché fidarsi della chiave di un'autorità nominata.
• Proof of Existence e C2PA a confronto — una prova di tempistica e integrità accanto a un livello completo di provenienza dei contenuti.