CardanoWall torna, costruito su Label 309

CardanoWall torna, e questa volta il prodotto è la parte più piccola della storia. La parte destinata a durare è Label 309: un formato di record aperto e neutrale rispetto al fornitore per ancorare la Proof of Existence nei metadati delle transazioni Cardano. Calcoli l’hash di un contenuto, eventualmente lo firmi, eventualmente lo sigilli per persone specifiche e pubblichi il risultato su Cardano. Da quel momento chiunque abbia il riferimento della transazione può verificarlo a partire dalla sola catena pubblica, senza dover dare fiducia a CardanoWall come fornitore permanente.

L’idea originale del 2021 funzionava perché i metadati di Cardano possono trasportare impegni pubblici destinati a durare. Il rilancio trasforma quell’idea in qualcosa di preciso: un formato di record specificato, un percorso di gateway aperto, gli SDK, uno strumento da riga di comando e un software per l’utente finale che anche chi non è crittografo può davvero usare.

Da un esperimento del 2021 a un formato specificato

CardanoWall è nato nel 2021 da una scommessa semplice: usare i metadati delle transazioni Cardano come luogo pubblico in cui ancorare una prova.

All’epoca la prova era fatta soprattutto di hash, testo e metadati improvvisati. Potevi calcolare l’hash di un file, scriverlo sulla catena e più tardi — se avevi ancora il file originale — ricalcolarlo e confrontarlo con il record on-chain.

Questo è lo schema fondamentale della Proof of Existence, e vale la pena dirlo con chiarezza perché tutto il resto si fonda su di esso. Non pubblichi mai il file privato: pubblichi un’impronta crittografica dei byte esatti, e la blockchain fornisce il testimone temporale pubblico. Se i byte corrispondono all’hash registrato, allora esistevano entro il momento del blocco.

C’era chi ci sperimentava, infilando ogni sorta di messaggio e metadato dentro i record. Era utile, ma metteva in luce il limite di un esperimento poco rigoroso. Per diventare infrastruttura, l’idea aveva bisogno di un formato preciso, di regole di verifica rigorose e di strumenti che funzionassero tra app e fornitori diversi. Una prova vale solo quanto la capacità della controparte di controllarla senza chiamare chi l’ha emessa.

È esattamente a questo che serve Label 309. È costruito attorno alla label dei metadati Cardano 309, che il formato riserva ai record di Proof of Existence, e la specifica è stata sottoposta al processo CIP di Cardano. Al momento è in revisione presso gli editor CIP come proposta di categoria Metadata.

Le parole qui sono scelte con cura. Label 309 è una proposta in revisione, non ancora uno standard Cardano accettato, e la descriviamo così finché il processo CIP non dirà diversamente. Ma la direzione è ormai decisa: l’idea originale di CardanoWall è cresciuta fino a diventare un formato di record accuratamente specificato e neutrale rispetto al fornitore. Se vuoi il quadro completo del formato wire, come funziona Label 309 è il punto da cui partire.

Cosa è cambiato davvero nel rilancio?

Il nuovo CardanoWall non è un’interfaccia più curata sopra il vecchio concetto. È un percorso di implementazione completo per uno standard aperto:

un’app web, per chi vuole un’interfaccia semplice;
un gateway che fa il preventivo, carica, pubblica, conferma e indicizza i record;
gli SDK e uno strumento da riga di comando, per gli sviluppatori e l’automazione;
percorsi di verifica che non dipendono dal fatto che il sito di CardanoWall resti online;
e un’app desktop open source che sincronizza l’insieme pubblico dei record per l’uso locale, anche offline.

Il punto architetturale che sta sotto a tutto questo: CardanoWall è un prodotto, ma le prove non restano intrappolate dentro il prodotto. Un record Label 309 può essere controllato a partire dalla catena pubblica di Cardano, dai byte del record e — quando serve — dal contenuto originale o dal payload cifrato. Il sito può rendere tutto questo piacevole, ma non è mai la radice della fiducia. La radice è la catena.

Il modo più chiaro di capire il prodotto rilanciato è vederlo come quattro livelli, ciascuno un soprainsieme rigoroso del precedente. La stessa struttura ricompare nei profili di conformità dello standard, e la percorriamo nel dettaglio in hash, sign, seal, share.

Hash: dimostrare che byte esatti esistevano entro un momento pubblico

Il primo livello è la prova classica. CardanoWall calcola l’hash di un file, un messaggio, un dataset o un manifesto e ancora quell’hash in una transazione Cardano sotto la label 309. In seguito chiunque abbia gli stessi byte originali può ricalcolare l’hash e confermare che corrisponde al record on-chain.

Questo dimostra una cosa sola e ben circoscritta: i byte esatti esistevano entro il block time della transazione. Non dimostra chi ha creato il file, né che il contenuto del file sia vero, né che qualcuno ne sia il proprietario. È proprio questa ristrettezza a renderlo affidabile — e vale la pena capirla con precisione, ed è per questo che cosa una prova non dimostra è uno dei primi articoli di questo blog.

Sign: mostrare che una chiave specifica garantisce per il record

Il secondo livello aggiunge la paternità. Un hash mostra che un contenuto è esistito; una firma mostra che una chiave precisa sta dietro al record. Label 309 permette a un record di portare una o più firme, così l’affermazione passa da «questi byte esistevano» a «e questa chiave ha garantito per loro».

Questa distinzione conta per una persona o per un’azienda. Un timestamp pubblico è utile di per sé. Un timestamp pubblico legato a una chiave d’identità stabile è più forte quando devi mostrare di avere creato, approvato o inviato tu stesso il record. Le firme restano però sempre facoltative: il formato non ti obbliga mai a rivelare un’identità per pubblicare.

Seal: mantenere il file privato pur applicandogli un timestamp

Il terzo livello aggiunge la conservazione cifrata. Un hash nudo basta finché il file originale non viene perso o non cambia anche di un solo byte; dopodiché l’hash non corrisponde più. Ottimo per l’integrità, doloroso se non possiedi più i byte esatti.

Una prova sigillata risolve il problema cifrando il file e referenziando il testo cifrato attraverso uno storage indirizzato per contenuto come Arweave. Il record pubblico continua a impegnarsi sull’hash del testo in chiaro esatto, ma il testo in chiaro non deve mai diventare pubblico, e il file cifrato può essere conservato accanto alla prova. L’affermazione passa da «posso dimostrare che questo hash è esistito, se ho ancora il file» a «posso conservare il file originale in forma cifrata e in seguito dimostrare che è il file dietro l’hash».

Il quarto livello aggiunge i destinatari. Un file sigillato può essere cifrato per te stesso, oppure per altre persone specifiche. Se conosci l’indirizzo di ricezione di un destinatario, puoi pubblicare un record che lui potrà in seguito scoprire e decifrare con la propria chiave.

È questo che rende Label 309 qualcosa di più del semplice timestamping personale. Può sostenere la consegna riservata di prove, record aziendali privati, impegni su dataset e qualunque flusso di lavoro in cui la catena pubblica debba dimostrare che un record esiste mentre il contenuto resta privato. Il modello dei destinatari è pensato per tutelare la privacy: il record non porta alcun campo pubblico «destinatario» che annunci a chi è rivolto il messaggio. Al contrario, un client scorre il feed pubblico dei record e prova, localmente, a decifrare quelli che potrebbero essere indirizzati alle sue chiavi.

Perché la cifratura post-quantum fa parte del progetto?

Lo storage permanente cambia i termini del discorso sulla sicurezza. Una volta che dati cifrati possono restare su uno storage pubblico a lunga vita, la domanda non è più soltanto «qualcuno può decifrarli oggi?». Diventa anche «e se qualcuno conservasse il testo cifrato ora per attaccarlo tra anni?».

È per questo che Label 309 tratta l’agilità degli algoritmi — e la cifratura ibrida post-quantum per i payload sigillati — come obiettivi di progetto di primo piano, non come ripensamenti. Il formato non è vincolato a una singola primitiva: fa riferimento a identificatori di algoritmo nominati da registri estendibili, così le implementazioni future possono aggiungere algoritmi più robusti senza rompere il modello di base del record. Migrare verso algoritmi post-quantum è additivo.

Per i record sigillati, CardanoWall è progettato per supportare sia un indirizzo di ricezione classico sia uno ibrido post-quantum facoltativo. Nella versione attuale, questa storia post-quantum riguarda specificamente la cifratura dei payload sigillati; le firme dei record restano Ed25519. Non dovresti aver bisogno di capire nulla di tutto questo per beneficiare del default più sicuro. Ti basta proteggere il tuo Identity Seed — l’unico segreto da 32 byte da cui deriva tutta la tua identità, e il vero backup che le sta dietro — e usare un software che segue lo standard. La tua identità è un seed spiega perché quell’unico valore conta così tanto.

Perché il gateway è aperto?

Pubblicare una prova è più di un pulsante. Qualcosa deve preparare il record, caricare il testo cifrato quando ci sono file di mezzo, fare il preventivo del costo, inviare la transazione Cardano, pagare le commissioni reali di rete e di storage, attendere la conferma, indicizzare il risultato ed esporlo per la verifica. Questo componente è il gateway.

CardanoWall è costruito attorno a un modello di gateway che qualunque sviluppatore o azienda può usare. Non esiste un percorso di pubblicazione privato e speciale riservato al prodotto ufficiale: l’app web raggiunge il gateway attraverso le stesse interfacce pubbliche che userebbe un soggetto terzo. Uno sviluppatore può costruire un’app diversa sulle stesse superfici. Un’azienda può far funzionare il proprio gateway, finanziare i propri wallet Cardano e di storage e pubblicare record Label 309 senza dipendere da CardanoWall come operatore ospitante.

Quell’apertura è il punto, non una nota a piè di pagina. Se lo standard è aperto ma l’unico strumento concreto è un servizio chiuso, il sistema ha comunque un centro debole. CardanoWall vuole essere insieme un buon prodotto e un percorso di riferimento che altri possano ispezionare, eseguire, modificare e sostituire. Il gateway core, gli SDK e lo strumento da riga di comando sono open source.

Cosa non pretende di dimostrare

La Proof of Existence è potente proprio perché è circoscritta. Dimostra che dati esatti esistevano entro un momento pubblico. Con le firme, può mostrare che una chiave ha garantito per un record. Con i payload sigillati, può conservare file cifrati e in seguito dimostrare che i byte decifrati corrispondono all’hash su cui ci si è impegnati. Con la cifratura per destinatario, può consegnare dati riservati a chiavi specifiche.

Non dimostra che il contenuto di un file sia vero. Non dimostra che chi ha pubblicato fosse il proprietario del contenuto. Non sostituisce una consulenza legale, un timestamp regolamentato dove ne è richiesto uno, né un sistema di compliance completo. E sebbene i record sigillati tengano fuori dalla catena il testo in chiaro e l’identità dei destinatari, la riservatezza non è la stessa cosa dell’anonimato: il comportamento di rete, le tracce dei pagamenti, le impronte del browser e i normali errori operativi al di fuori del record Label 309 possono comunque rivelare chi sta facendo cosa. Un destinatario che decifra un file sigillato può anche scegliere di condividere il testo in chiaro.

Questi limiti non sono una debolezza. Sono la linea che separa un serio sistema di prove dalla nebbia del marketing.

Cosa arriva dopo su questo blog

Questo blog spiegherà il sistema una domanda mirata alla volta.

Prima le basi: cos’è la Proof of Existence, come funziona Label 309, cosa finisce sulla catena e cosa resta privato.

Poi il modello dell’utente: l’Identity Seed, gli indirizzi di ricezione, i record sigillati e il client desktop.

Poi il livello dell’operatore: come funziona il gateway, perché pubblicare ha un prezzo, come si inserisce l’accesso via API e quando un’azienda dovrebbe far funzionare il proprio gateway.

E poi i casi d’uso che rendono lo standard degno di essere costruito: prove di CI/CD, provenienza dei contenuti generati dall’AI, impegni su dataset privati, log di compliance, fascicoli di prove legali, divulgazioni riservate e il Merkle batching per le prove su larga scala.

CardanoWall è nato come modo per scrivere una prova nei metadati di Cardano. La versione rilanciata punta a rendere quella prova destinata a durare, privata quando deve esserlo, verificabile senza fiducia nel fornitore e abbastanza pratica da usare senza dover prima diventare ingegnere di protocollo.

Questo è il rilancio.

Per approfondire

Lo standard Label 309: label309.org
La proposta in revisione nel processo CIP di Cardano: CIPs PR #1205
Il codice open source, gli SDK e la CLI: github.com/cardanowall