Hash, firma, sigillo, condivisione: i quattro livelli di una prova CardanoWall

Una prova CardanoWall ha quattro livelli pratici, e sei tu a scegliere fin dove salire lungo la scala:

• Hash dimostra che quei byte esatti esistevano entro un momento pubblico.
• Firma aggiunge un'affermazione garantita da una chiave: una specifica identità avalla il record.
• Sigillo cifra il file originale, così da poterlo conservare in privato accanto alla prova.
• Condivisione prepara quel file sigillato per destinatari specifici, che potranno poi scoprirlo e decifrarlo con le proprie chiavi.

Ogni livello poggia su quello sottostante, e lo standard comune a tutti è Label 309. È il modo più semplice per capire che cos'è CardanoWall: non solo un posto dove mettere hash su una blockchain, ma un modo stratificato per rendere i record durevoli, privati e verificabili — partendo da un timestamp nudo e aggiungendo solo la protezione che la situazione richiede davvero.

Livello 1: hash — dimostrare che byte esatti esistevano entro un momento

Il primo livello è la classica Proof of Existence.

Prendi un file, un messaggio, un dataset, un asset multimediale, un artefatto di build, un report o un manifest. CardanoWall calcola un hash crittografico dei byte esatti e pubblica quell'hash in un record Label 309 su Cardano.

In seguito, chiunque disponga degli stessi byte originali può ricalcolare l'hash. Se corrisponde a quello presente nel record, il verificatore sa che quei byte esatti esistevano non oltre il block time della transazione. Il controllo gira contro la chain pubblica di Cardano — non serve alcun account CardanoWall e non si ripone fiducia in alcun server CardanoWall.

Il bello è che il file in sé non deve mai diventare pubblico. Un contratto privato, lo snapshot di un dataset, il manifest del rilascio di un software o un fascicolo di prove legali possono ciascuno portare con sé una prova pubblica. Il record dice questi byte esistevano. Non deve mostrare i byte.

A cosa servono le prove basate sull'hash?

Le prove basate sull'hash danno il meglio quando la domanda riguarda il momento e l'integrità. Rispondono a cose come:

• Questo file esatto esisteva prima di una scadenza?
• È lo stesso PDF a cui è stato applicato un timestamp il mese scorso?
• Questo manifest del rilascio era già stato fissato prima dell'incidente?
• Lo snapshot di questo dataset esisteva prima che il modello venisse addestrato su di esso?
• Questo file multimediale esisteva prima di essere modificato o contestato?

Sono anche efficienti. Un file da diversi gigabyte si riduce a un breve digest, e un file privato diventa un impegno pubblico senza rivelarne il contenuto.

Il limite conta esattamente quanto il pregio: un hash non dimostra chi ha creato il file, né che il file sia veritiero, né che qualcuno ne abbia la proprietà. Dimostra che quei byte esatti esistevano entro un momento pubblico — niente di più. Per molti flussi di lavoro è sufficiente. Per gli altri, CardanoWall aggiunge i livelli successivi.

Livello 2: firma — legare al record la chiave di un'identità

Il secondo livello aggiunge una firma.

Una firma permette a una chiave di avallare il record. Invece di limitarsi a dimostrare che dei byte esistevano, il record può anche mostrare che la chiave di una specifica identità ha firmato la prova. In Label 309 si tratta di una firma COSE_Sign1 separata e opzionale, calcolata sul corpo del record, e la paternità non è mai obbligatoria: un record senza firma resta una prova completa e del tutto verificabile.

Quell'opzione cambia il significato pratico. Per un singolo creatore, un record firmato può collegare un lavoro all'identità CardanoWall del creatore. Per un'azienda, può mostrare che una chiave approvata sta dietro a un report, al manifest di un rilascio, a uno snapshot di compliance o all'impegno su un dataset. Per un flusso di lavoro automatizzato, distingue «qualcuno ha applicato un timestamp a questo file» da «il nostro sistema ha firmato questo record come parte del processo».

La firma non sostituisce l'hash; gli si appoggia sopra.

• L'hash dice: questi byte esatti esistevano.
• La firma dice: questa chiave ha firmato il record che porta quell'affermazione.

Cosa non dimostra una firma?

Le firme sono potenti, ma non sono magiche.

Una firma dimostra il controllo di una chiave al momento della firma. Non dimostra, di per sé, l'identità reale della persona o dell'azienda dietro quella chiave. Quell'identità nasce dal contesto: da come la chiave è stata creata, da come è stata pubblicata, da come un'organizzazione la gestisce e da come gli altri arrivano a fidarsene.

Una firma non dimostra nemmeno che il firmatario abbia pagato la fee della transazione o l'abbia inviata a Cardano. In Label 309 la firma copre il corpo del record, non l'intera transazione Cardano. È una scelta deliberata, ed è ciò che mantiene i record portabili: un gateway, un sistema di automazione o un qualsiasi terzo possono pubblicare un record firmato senza diventare l'autore del contenuto. Una firma verificata si legge come «firmato da questa chiave» — mai «questa chiave ha inviato la transazione».

In parole semplici: firma quando vuoi che la prova non dica solo «questo esisteva», ma «questa identità sta dietro alla prova».

Livello 3: sigillo — conservare una copia cifrata insieme alla prova

Il terzo livello aggiunge la conservazione cifrata.

Una prova solo-hash ha una debolezza pratica: il verificatore ha comunque bisogno dei byte originali. Se perdi il file, o lo modifichi anche di un solo byte, non sei più in grado di produrre il contenuto che corrisponde al record.

Il sigillo risolve il problema cifrando il file e tenendo il payload cifrato insieme alla prova, in una posizione indirizzata per contenuto come Arweave o IPFS. Il record on-chain continua a impegnarsi sull'hash del testo in chiaro — mai sul testo cifrato — quindi l'affermazione sul timestamp resta invariata. Il file non viene mai pubblicato in chiaro. Chiunque possieda la chiave giusta può in seguito recuperare il testo cifrato, decifrarlo, ricalcolare l'hash del testo in chiaro e dimostrare che si tratta del file dietro al record.

Questo sposta l'esperienza d'uso. Con una prova solo-hash, sei tu a conservare il file originale. Con una prova sigillata, puoi conservare una copia cifrata dell'originale come parte stessa del flusso di lavoro della prova.

Quando vale la pena sigillare?

Il sigillo conta quando il file originale è tanto importante che perderlo indebolirebbe la prova. Pensa a:

• fascicoli di prove legali e contratti firmati;
• report di compliance e log di incidenti sensibili;
• file creativi originali e dati di ricerca;
• manifest di dataset, prompt e output di AI, e artefatti di rilascio.

In ogni caso l'hash è utile, ma i byte originali sono ciò che potresti dover produrre in seguito. La Sealed Proof of Existence ti permette di mantenere quei byte cifrati mentre il timestamp resta pubblico. La chain dimostra la cronologia; la cifratura protegge il contenuto.

Livello 4: condivisione — consegnare un file sigillato a destinatari specifici

Il quarto livello aggiunge la consegna privata ai destinatari.

A volte la prova non è solo per te. Potresti aver bisogno di inviare prove cifrate a un avvocato, un revisore, un partner, un giornalista, un cliente, un'autorità di controllo o un team interno.

Se conosci l'indirizzo di ricezione del destinatario, CardanoWall può creare un record sigillato che il destinatario potrà poi aprire con la propria chiave. Quel record ha comunque un timestamp pubblico e si impegna comunque sull'hash del testo in chiaro. Può comunque conservare un file cifrato. Ma ora il payload cifrato può essere aperto da destinatari specifici, non solo dal mittente. È qui che CardanoWall inizia a sembrare meno uno strumento di marcatura temporale e più un sistema sicuro di consegna dei record.

Come funziona la consegna privata senza una rubrica pubblica?

La consegna ai destinatari non richiede alcuna rubrica pubblica sulla chain, e nessuna chiave pubblica del destinatario viene mai scritta nel record come campo leggibile.

Ecco il flusso. Un destinatario ha un indirizzo di ricezione. Il mittente lo ottiene tramite un canale separato — direttamente dal destinatario, da un profilo, dalla pagina di un'azienda o da un altro canale fidato. Quando il mittente costruisce un record sigillato, la busta porta con sé slot di chiave cifrati per ciascun destinatario, che solo i destinatari previsti possono aprire.

Sul lato di chi riceve, il software del destinatario scandisce i record sigillati pubblici e decifra a tentativi: prova localmente ogni slot con le proprie chiavi. Quando uno slot si apre, il record compare nella Inbox di quel destinatario. Il server non decifra mai il messaggio e non ha bisogno di sapere chi sia il destinatario. (Vedi come ricevere record sigillati per il lato del destinatario nel dettaglio.)

Questa non è la promessa di un anonimato perfetto. Tempistiche, flussi di pagamento, metadati di rete, comportamento del browser ed errori operativi possono comunque far trapelare informazioni, e un destinatario può sempre condividere il testo in chiaro una volta che lo ha decifrato. Ciò che il design garantisce è più circoscritto e concreto: il record Label 309 in sé non pubblica né il testo in chiaro né un elenco leggibile di destinatari — un osservatore vede soltanto che un record è sigillato e quanti slot di chiave porta con sé, mai a chi sono destinati.

Perché la cifratura post-quantum rientra nella storia della condivisione?

I record sigillati possono vivere molto a lungo. Se il contenuto cifrato è conservato in modo permanente o semi-permanente, a un attaccante non serve violarlo oggi: può archiviare il testo cifrato adesso e tentare più avanti, con hardware migliore e una crittanalisi migliore. È il problema del «harvest now, decrypt later».

Ecco perché Label 309 prende sul serio l'agilità algoritmica. Gli indirizzi di ricezione esistono in due forme — un indirizzo classico X25519 e un indirizzo ibrido post-quantum opzionale che combina X25519 con ML-KEM-768 (una costruzione in stile X-Wing). L'ibrido mantiene la sicurezza classica di X25519 come livello minimo garantito e vi aggiunge resistenza a un futuro attaccante quantistico, quindi è il default migliore per i contenuti destinati a sopravvivere alle assunzioni crittografiche di oggi. Il punto non è promettere una sicurezza permanente — niente di onesto può farlo — ma evitare di progettare un sistema di prove che dia per scontato che le comodità crittografiche di oggi reggeranno per sempre.

La versione rivolta all'utente resta semplice: proteggi il tuo Identity Seed, preferisci l'indirizzo di ricezione ibrido post-quantum quando il tuo destinatario ne pubblica uno, e lascia che sia il software a occuparsi della crittografia.

Come lavorano insieme i quattro livelli?

I livelli non sono prodotti separati. Sono strati su un unico standard:

• Pubblica una semplice prova hash quando ti serve solo un timestamp.
• Aggiungi una firma quando vuoi che la chiave di un'identità avalli il record.
• Sigilla il file quando conta conservare i byte originali esatti.
• Condividi il file sigillato quando destinatari specifici hanno bisogno di un accesso privato.

Poiché lo stesso standard sottostante supporta ogni scelta, puoi partire semplice e ricorrere a strati più robusti solo quando la situazione lo richiede.

Quale livello dovresti usare?

• Hash quando il file originale è facile da conservare e l'unica domanda è se quei byte esistevano entro un certo momento.
• Firma quando vuoi che un'identità garantita da una chiave stia dietro alla prova.
• Sigillo quando i byte originali sono abbastanza sensibili o importanti da conservarne una copia cifrata insieme alla prova.
• Condivisione quando qualcun altro ha bisogno di ricevere il contenuto cifrato e di verificarlo in seguito.

C'è anche un quinto strumento, trasversale a tutti e quattro: il Merkle batching, per quando hai troppi hash da pubblicare uno per uno — artefatti CI/CD, log giornalieri, snapshot di dataset, media generati o qualsiasi flusso di lavoro in cui migliaia di elementi dovrebbero essere impegnati sotto un unico record e un'unica root.

Cosa continuano a non dimostrare queste prove?

Anche con tutti e quattro i livelli, la Proof of Existence resta precisa sulle proprie affermazioni.

Può dimostrare che byte esatti esistevano, che una chiave ha firmato il record, che del contenuto cifrato è stato conservato, che il contenuto è stato consegnato a chiavi specifiche e — con una Merkle root — che un item apparteneva a un batch impegnato.

Non dimostra, di per sé, che il contenuto sia veritiero, che qualcuno ne abbia la proprietà legale, che un dataset sia stato raccolto in modo lecito o che un processo fragile sia solido. Per saperne di più su questi confini, vedi cosa non dimostra una prova. CardanoWall ti dà un livello di prova durevole; il processo di business attorno a quella prova conta comunque.

La versione breve

• Hash è il timestamp.
• Firma è l'affermazione sull'identità.
• Sigillo è la conservazione cifrata.
• Condivisione è la consegna privata.

Insieme trasformano la Proof of Existence da un nudo hash su una chain in un flusso di lavoro utilizzabile per file, dataset, prove, rilasci software, output di AI e record riservati — e poiché Label 309 è uno standard aperto con strumenti open-source, gli stessi quattro livelli funzionano attraverso il sito web, la CLI o l'implementazione di chiunque altro.

Approfondimenti

• Che cos'è la Proof of Existence? — il livello hash, in profondità.
• Come ricevere record sigillati — il lato del destinatario nella «condivisione».
• Un record per migliaia di file — il Merkle batching attraverso tutti e quattro i livelli.
• Cosa non dimostra una prova — i limiti da tenere a mente.
• Label 309 — lo standard aperto, proposto al processo CIP di Cardano e in fase di revisione da parte degli editor CIP (PR #1205).
• github.com/cardanowall — gli SDK open-source e la CLI cardanowall.