Come funziona Label 309

Label 309 definisce come un record di Proof-of-Existence viene scritto nei metadati di una transazione Cardano. Alla sua base, un record vincola a Cardano uno o più hash di contenuto sotto la label dei metadati 309. Il block time di quella transazione diventa il testimone pubblico che quei byte esatti esistevano entro quel momento. Tutto il resto che il record può trasportare — firme, URI di storage, payload cifrati, slot di chiave per i destinatari, Merkle root, un puntatore a un record precedente — sono metadati opzionali a corredo di quell'unica affermazione.

L'obiettivo di progettazione è semplice da enunciare: una prova deve essere verificabile in modo indipendente. Controllare l'affermazione di base non dovrebbe richiedere di fidarsi di CardanoWall, del sito di chi pubblica, di un database privato o di un'autorità di certificazione — soltanto della catena pubblica e, per le affermazioni sul contenuto, dei byte originali.

Label 309 è uno standard aperto. È stato sottoposto al processo CIP di Cardano come proposta di categoria Metadata ed è in fase di revisione da parte degli editor del CIP; è la label dei metadati stessa l'identificatore on-chain durevole, e l'app web, la CLI e gli SDK ne sono implementazioni di riferimento, non lo standard. Se prima vuoi il quadro più ampio, parti da cos'è davvero la Proof of Existence.

Cosa viene memorizzato sulla blockchain sotto la label 309?

Un record Label 309 risiede nei metadati di una transazione Cardano sotto la label intera 309. Esattamente un record per transazione; un verificatore ignora ogni altra label dei metadati.

Il corpo del record è codificato in CBOR canonico — un formato binario deterministico, così due implementazioni che esprimono lo stesso record logico emettono byte identici. Cardano limita ogni singola stringa di metadati a 64 byte, e un record serializzato di solito è più grande. Per questo il corpo viene trasportato come un unico array CBOR di piccoli chunk byte-string la cui concatenazione nell'ordine corretto è il corpo del record. Un verificatore concatena di nuovo i chunk prima di validare qualunque cosa. Questo è l'unico chunking che il formato esegue.

Quel dettaglio di trasporto conta per chi implementa, ma l'idea di fondo è lineare:

1. La transazione porta la label dei metadati 309.
2. Il valore sotto quella label si ricompone in un unico record Label 309.
3. Il record si impegna su hash di contenuto, Merkle root, o entrambi.
4. Campi opzionali aggiungono firme, materiale di payload cifrato, URI di storage e un puntatore di sostituzione.

Questo non è un campo note a forma libera. Il record ha una forma rigida e chiusa, ed è esattamente ciò che permette a implementazioni diverse di produrre e verificare gli stessi byte.

Perché l'hash del contenuto è l'affermazione primaria?

Perché la Proof of Existence è un'affermazione su byte esatti, e un hash è l'impronta di byte esatti.

L'hash del contenuto è l'affermazione primaria in Label 309; ogni altro campo è un metadato a suo corredo. Per una semplice prova su file, un item porta una mappa hashes che abbina un algoritmo di hash con nome — per esempio sha2-256 o blake2b-256 — a un digest grezzo da 32 byte. Per controllare la prova, un verificatore ricalcola il digest dal file originale e lo confronta con il digest contenuto nel record.

Se i byte corrispondono, la prova passa. Cambia un solo byte e il digest cambia, quindi la prova fallisce.

Ecco perché l'affermazione resta piccola anche quando il contenuto è grande o privato. Il record non ha mai bisogno del file. Gli serve l'impronta.

Cosa sono items, uris ed enc?

Gli items sono gli impegni per-contenuto all'interno di un record. Ogni item è un'affermazione di contenuto. L'unica parte obbligatoria è una mappa hashes non vuota; il resto è opzionale.

Un item può portare:

• hashes — la mappa obbligatoria che associa l'algoritmo di hash al digest grezzo;
• uris — posizioni opzionali indirizzate per contenuto come ar://… (Arweave) o ipfs://… (IPFS);
• enc — una busta di cifratura opzionale per un record sigillato (cifrato).

L'idea chiave è che gli uris non sono la prova. La prova è l'hash. Un URI è un suggerimento per il recupero o un impegno di storage che aiuta un verificatore a trovare i byte da controllare. Un record solo-hash, senza URI, è una prova completa e valida. Un record con un URI può aiutare a recuperare contenuto pubblico o testo cifrato. Un record sigillato mantiene il testo in chiaro cifrato off-chain dimostrando comunque quando è esistito.

Perché solo ar:// e ipfs://?

Label 309 v1 limita gli URI di storage agli schemi indirizzati per contenuto — Arweave e IPFS — e rifiuta tutto il resto, incluso https://. Quella restrizione è deliberata, non temporanea.

Un normale URL https:// dipende da DNS, TLS, comportamento del server, redirect e da qualunque cosa finisca per essere ospitata a quell'indirizzo in seguito. Un URI indirizzato per contenuto è diverso: l'indirizzo stesso è derivato dal contenuto (un CID IPFS è un multihash dei byte; un id di transazione Arweave si impegna sui dati sotto il consenso di Arweave). Così un verificatore può confermare «i byte che ho recuperato sono i byte su cui il produttore si è impegnato» senza fidarsi del gateway di storage, del DNS o di un'autorità di certificazione. I byte recuperati devono comunque corrispondere all'impegno on-chain; da solo, il livello di storage non è mai una fonte di verità.

Cosa dimostrano le firme — e cosa non dimostrano?

Un record Label 309 può portare un array sigs opzionale a livello superiore. Ogni voce è una firma COSE_Sign1 separata sul corpo del record con il campo sigs rimosso. In parole semplici, un firmatario garantisce per l'intero record in un colpo solo: ogni item, ogni hash, ogni URI, ogni busta sigillata, ogni Merkle root, il puntatore di supersessione e ogni campo di estensione.

La firma è additiva. Un record senza firma dimostra comunque l'esistenza. Un record con una firma valida mostra anche che una chiave specifica si è fatta garante del record:

• solo-hash: questi byte esistevano entro questo momento pubblico;
• firmato: questi byte esistevano entro questo momento pubblico, e questa chiave si è fatta garante del record.

La precisione conta, perché una firma dimostra meno di quanto spesso si supponga. Una firma verificata non dimostra che la stessa chiave ha pagato o inviato la transazione Cardano, che ha scelto il block time, o che appartiene a una persona reale con nome e cognome. Dimostra che la chiave ha firmato il corpo del record — niente di più. Rendila come «firmato da questa chiave», mai come «pubblicato da questa chiave». È quel significato ristretto e onesto a rendere una prova firmata trasferibile tra app e gateway diversi. La paternità è sempre opzionale, e una firma che un verificatore non riesce a controllare (un algoritmo non supportato, una chiave non risolvibile) non invalida mai l'affermazione di esistenza: il fallimento di una firma non è bloccante; quello dell'esistenza sì.

Cos'è un record sigillato?

Un record sigillato mantiene il contenuto riservato dimostrando comunque quando è esistito.

In un record Label 309 sigillato, l'item si impegna comunque sull'hash del testo in chiaro — mai sul testo cifrato. Il testo in chiaro è cifrato, e il testo cifrato risiede a un URI indirizzato per contenuto (ar://… o ipfs://…), mai sulla catena. Il record on-chain porta una busta di cifratura che contiene il materiale di cui un titolare di chiave prescelto ha bisogno per recuperare la chiave di cifratura del contenuto. La catena non contiene il testo in chiaro e non pubblica un elenco di destinatari.

Per un destinatario, la verifica aggiunge alcuni passaggi:

1. Recupera il record da Cardano.
2. Recupera il testo cifrato dallo storage indirizzato per contenuto.
3. Prova ad aprire localmente uno slot di chiave corrispondente.
4. Decifra il testo cifrato se uno slot si apre.
5. Ricalcola l'hash del testo in chiaro e confrontalo con l'impegno on-chain.

Poiché il digest on-chain vincola il testo in chiaro, una prova sigillata preserva il file originale esatto e lo mantiene privato. Con questo arrivano alcuni limiti onesti: un record sigillato dimostra tempistica e integrità, non anonimato, e un destinatario che decifra può sempre scegliere di divulgare il testo in chiaro in seguito.

Come funzionano i destinatari senza un campo destinatario?

I destinatari funzionano tramite chiavi di ricezione e decifratura a tentativi, non un campo destinatario leggibile.

Se un mittente conosce l'indirizzo di ricezione di un destinatario (una chiave pubblica X25519, eventualmente una ibrida post-quantum), il mittente può costruire un record sigillato con uno slot di chiave che quel destinatario può aprire. La chiave pubblica del destinatario non compare mai come campo leggibile nel record. Il software del destinatario osserva il flusso pubblico di record Label 309 e prova localmente a decifrare gli slot candidati; se uno slot si apre, il record appartiene alla Inbox di quel destinatario.

Ecco perché una Inbox di CardanoWall non è una normale casella di posta lato server. Il gateway espone un feed di record cieco rispetto al destinatario; è il client a trovare quelli che riesce a decifrare. Il server non ha mai bisogno di sapere chi sia il destinatario né di decifrare alcunché per suo conto. (Vedi come ricevere record sigillati per il lato destinatario nella pratica.)

Restano comunque dei limiti sui metadati da chiarire. Il record non pubblica mai testo in chiaro né una colonna destinatario, e l'ordine degli slot viene mescolato prima della pubblicazione, così da non trasportare alcun segnale. Ma il numero di slot è visibile, e tempistiche, tracce di pagamento ed errori operativi possono rivelare informazioni che il formato del record di per sé non può nascondere.

Come fa un solo record a coprire migliaia di file?

Se devi dimostrare che mille file esistevano, non dovresti aver bisogno di mille transazioni Cardano. Label 309 supporta il Merkle batching: calcola l'hash dei file, costruisci un Merkle tree sulla lista ordinata degli hash e pubblica una singola root da 32 byte nell'array merkle del record. Insieme alla root, il record porta un conteggio delle foglie, che vincola la root on-chain alla dimensione esatta della lista off-chain.

In seguito puoi dimostrare che un file o un evento specifico era nel batch mostrando:

• il file (o il suo hash di foglia);
• una inclusion proof — gli hash fratelli lungo il percorso fino alla root;
• la Merkle root ancorata nel record Label 309.

Il verificatore ripiega la inclusion proof fino a una root e l'accetta solo se la root ricalcolata è uguale, byte per byte, alla root pubblicata. Ogni foglia non divulgata resta privata — la root non rivela nulla sulle foglie su cui si impegna.

Questo è il livello di scalabilità per artefatti di CI/CD, log di compliance, output di IA, manifest di dataset, cartelle di rilascio e bundle di prove. Ha una trattazione dedicata in un solo record per migliaia di file.

A cosa serve il puntatore supersedes?

supersedes è un puntatore opzionale da 32 byte a un record Label 309 precedente, tramite il suo hash di transazione. Permette a un record più recente di dire «questo sostituisce o aggiorna quel record precedente».

Il record precedente non viene cancellato né invalidato. Cardano è append-only, quindi entrambi i record restano verificabili in modo indipendente per sempre. Il puntatore è solo un collegamento; non porta un campo motivazione. Il significato umano della sostituzione — una correzione, un manifest rivisto, un pacchetto di prove aggiornato — appartiene al nuovo contenuto o al livello applicativo, non ai metadati. Il valore del puntatore sta nel fatto che funziona senza alcuna riga in un database di un fornitore e senza alcun id di record proprietario.

Come funziona la verifica?

La verifica è a livelli. Label 309 definisce tre ruoli di verificatore, ciascuno una rigorosa estensione del precedente:

• Validatore strutturale — una funzione pura sui byte del record. Conferma il CBOR canonico, la forma dello schema, i tipi dei campi, i campi obbligatori, gli identificatori di algoritmo e le regole sugli URI. Non esegue alcun I/O di rete, non verifica firme e non decifra nulla.
• Verificatore pubblico — parte da un riferimento di transazione Cardano. Recupera la transazione grezza da un explorer che il verificatore stesso sceglie, vincola quei byte all'hash di transazione richiesto, conferma che la label 309 sia presente, ricompone il record, esegue la validazione strutturale, controlla la profondità di conferma e verifica le firme che supporta. Se i byte del contenuto sono disponibili, può ricalcolare gli hash del contenuto pubblico. Non decifra.
• Verificatore destinatario — tutto ciò che fa il verificatore pubblico, più la propria chiave privata per aprire i payload sigillati e ricalcolare gli hash del testo in chiaro.

Una sottigliezza mantiene onesta la verifica: un verificatore pubblico legge il CBOR grezzo della transazione, non la vista JSON dei metadati di un explorer. Una proiezione JSON è con perdita — scarta l'ordine delle chiavi delle mappe e la distinzione tra byte e testo — quindi ricodificare a partire da essa romperebbe ogni firma su un record conforme. E poiché il settlement su Cardano è probabilistico, un record profondo solo un blocco o due viene riportato come pending anziché valid finché non ha abbastanza conferme alle spalle.

Questa struttura mantiene pulito il modello di fiducia. Un verificatore di base non ha bisogno di un account CardanoWall; una prova pubblica si controlla senza un server di chi pubblica; una prova sigillata si decifra localmente, nelle mani del titolare della chiave. La guida pratica verifica un record Label 309 mostra il percorso del verificatore pubblico dall'inizio alla fine.

Dove si colloca il gateway?

Il gateway pubblica i record. Non è la radice della fiducia.

Un gateway Label 309 gestisce le parti che sono davvero difficili da far girare da soli: calcola il preventivo, carica il testo cifrato sullo storage, costruisce e invia la transazione Cardano, attende la conferma, indicizza i record, gestisce i saldi ed espone un'API. CardanoWall usa questo modello di gateway per rendere la pubblicazione pratica per utenti e sviluppatori comuni.

Ma una prova non è affidabile perché un gateway dice che esiste. È affidabile perché il record è sulla catena, i byte si validano, le firme tornano e gli hash si ricalcolano. È questa la linea che separa un servizio ospitato da uno standard di prova: il servizio ti aiuta a pubblicare; lo standard permette a chiunque di verificare, con il gateway completamente fuori dal percorso di fiducia.

Il modello mentale minimo

Pensa a Label 309 come a un piccolo record a livelli:

1. Gli items dimostrano che byte di contenuto esatti esistevano entro un momento pubblico.
2. I sigs permettono alle chiavi di farsi garanti del record, in via opzionale.
3. L'enc permette al contenuto cifrato di restare privato ma recuperabile.
4. Gli slot di chiave per i destinatari permettono a titolari di chiave specifici di aprire il contenuto sigillato.
5. Il merkle permette a un solo record di rappresentare un batch molto grande.
6. La verifica gira su dati pubblici e chiavi locali — mai sulla fiducia in un fornitore.

È questa stratificazione che permette a CardanoWall di essere un'app web, un'API, una CLI, un'app desktop o un gateway self-hosted — mentre il formato della prova resta lo stesso. Il prodotto può cambiare; la prova resta verificabile.

Una cosa su cui vale la pena essere onesti dall'inizio alla fine: una prova Label 309 mostra che byte specifici esistevano entro un momento pubblico, e che non sono cambiati da allora. Non dimostra chi ha creato il contenuto, chi lo possiede, o se quanto vi è scritto sia vero. Per capire dove cade quella linea, vedi cosa una prova non dimostra.

Letture di approfondimento

• Cos'è la Proof of Existence?
• Verifica un record Label 309
• Un solo record per migliaia di file
• Cosa una prova non dimostra
• Lo standard Label 309: label309.org
• Gli SDK e la CLI open-source: github.com/cardanowall
• La sottomissione al CIP di Cardano (in revisione): CIPs PR #1205