Introduzione
Che cos'è Label 309, i principi che garantisce e come chiunque può verificare un record senza fidarsi di alcun server.
Label 309 è uno standard aperto per la Proof of Existence (PoE, prova di esistenza) sulla blockchain Cardano. Chi pubblica calcola un hash crittografico di un contenuto e lo ancora in una transazione Cardano sotto la label 309 dei metadati. Da quel momento, chiunque disponga del riferimento di transazione può dimostrare che il contenuto esisteva entro l'orario del blocco (il block time), basandosi unicamente sulla blockchain pubblica e senza dover riporre alcuna fiducia in chi pubblica, in un dominio o in un server.
Il cuore dello standard è volutamente essenziale: l'hash del contenuto è la rivendicazione, e tutto il resto sono metadati opzionali che lo riguardano. Su questo nucleo lo standard definisce firme di paternità opzionali e un payload cifrato ("sigillato") opzionale, indirizzato a destinatari specifici, senza che nulla di tutto ciò richieda mai un intermediario fidato.
I cinque invarianti
Tutto in Label 309 discende da cinque principi irrinunciabili:
- Incentrato sul contenuto. L'hash del contenuto è la rivendicazione primaria; ogni altro campo è un metadato che lo riguarda.
- Indipendente dall'emittente. Qualsiasi wallet può pubblicare un record. I verificatori non si fidano mai di chi pubblica.
- Indipendente dallo storage. Gli URI di storage sono un elenco opzionale e
plurale (
ar://,ipfs://); un record di solo hash è pienamente valido. - Verificabile in autonomia. A un verificatore servono soltanto i metadati della transazione, facoltativamente i byte del contenuto e un explorer pubblico della blockchain. Non è mai richiesto un server dell'emittente.
- Agile rispetto agli algoritmi. Hash, AEAD, KEM, KDF e firme fanno tutti riferimento a identificatori nominati provenienti da registri estensibili. La migrazione ad algoritmi post-quantistici è additiva, non una rottura di compatibilità.
Profili di conformità
Un record si colloca in uno di quattro profili stratificati, da un semplice timestamp fino a un payload cifrato e indirizzato a un destinatario. Ogni profilo è un'estensione rigorosa di quello che lo precede.
| Profilo | Aggiunge | Risponde a |
|---|---|---|
| core | un hash del contenuto sotto label 309 | "questo contenuto esisteva entro l'orario T" |
| signed | una o più firme di record COSE_Sign1 | "...e questa chiave se ne fa garante" |
| sealed | un payload cifrato (passphrase o destinatari) | "...mantenuto riservato, ma con timestamp" |
| recipient-sealed | slot di chiave per destinatario (X25519 o X-Wing) | "...consegnato a chiavi specifiche, custodito in privato" |
Paternità e cifratura sono sempre opzionali. Un verificatore che comprende solo il
profilo core può comunque validare la rivendicazione di timestamp di qualsiasi
record.
La verifica in breve
Label 309 definisce tre ruoli di verifica, ciascuno un'estensione rigorosa del precedente:
- Validatore strutturale — una funzione pura sui byte del record. Niente rete, nessun controllo delle firme, nessuna decifratura; si limita a confermare che il record sia ben formato rispetto allo schema e alle regole dello standard.
- Verificatore pubblico — recupera la transazione da un explorer pubblico, esegue la validazione strutturale, conferma che il record sia ancorato on-chain (sulla blockchain) e verifica eventuali firme di paternità. Non effettua la decifratura.
- Verificatore destinatario — un verificatore pubblico che, in più, possiede una chiave privata, decifra un payload sigillato a lui indirizzato e ricalcola gli hash del testo in chiaro.
Poiché ogni ruolo lavora a partire da dati pubblici e da un explorer scelto dal verificatore, la verifica non dipende mai dall'infrastruttura di chi pubblica.
La proprietà fondamentale
Una prova Label 309 è qualcosa che puoi verificare in autonomia. Dato un riferimento di transazione e, per le rivendicazioni sul contenuto, i byte originali, qualsiasi implementazione conforme arriva allo stesso verdetto basandosi soltanto sulla blockchain pubblica.
Com'è organizzata questa specifica
I capitoli che seguono definiscono il formato wire (il record sotto label 309), i registri degli algoritmi, il modello crittografico delle chiavi, le firme di paternità, la consegna sigillata (cifrata), la pipeline di verifica con il relativo catalogo degli errori, il modello di sicurezza e il contratto di conformità tra linguaggi diversi. Ogni pagina è autonoma e cita le costanti nominate e le regole di cui un implementatore ha bisogno.