La prova che nessuno sa verificare

Ancorare un registro decisionale su una catena pubblica è diventato un esercizio quasi banale. Si prendono gli eventi, si costruisce un albero di Merkle, si scrive la root in una transazione. Un pomeriggio di lavoro, una riga nel changelog, e da quel momento in poi il sistema «è ancorato». La parte che quasi nessuno progetta con la stessa cura è l'altra metà, e arriva dopo: qualcuno, fuori dall'azienda, deve poter controllare un fatto specifico senza fidarsi di te.

Quattro cose, e devono esistere insieme

Una verifica non è un'affermazione, è un calcolo che qualcun altro rifà. Perché quel calcolo si possa fare servono quattro elementi, e la parola importante è insieme.

La entry originale, byte per byte com'era quando è stata hashata. Non il record riletto dal database e riserializzato da una versione più recente dell'applicativo: quello produce un hash diverso, e un hash diverso è indistinguibile da una manomissione.

La proof di inclusione per quella entry: il percorso di nodi fratelli che porta dalla foglia alla root. Va conservata, o va rigenerabile da chiunque abbia il registro, non solo dal tool interno che gira su una macchina del team.

La root, a un'altezza di blocco che si possa nominare. «È sulla catena» non è una coordinata; il numero di blocco e l'hash della transazione lo sono.

E un modo di leggere quella catena che non sia la tua API. È il punto che salta più spesso. Se il revisore, per controllare la tua affermazione, deve chiamare il tuo server, si sta fidando di te un'altra volta — da un'altra porta, con più passaggi in mezzo. Serve un nodo pubblico, un explorer indipendente, qualcosa che tu non controlli.

I modi di perderla sono noiosi

Nessuno di questi guasti è drammatico, ed è esattamente il motivo per cui passano inosservati fino al momento sbagliato.

La entry viene riserializzata da un refactoring, e l'hash si sposta. La proof la genera uno script che esiste solo nella cartella di chi lo ha scritto. La root sta su una catena che il team ha smesso di finanziare, o su una testnet che a un certo punto è stata spenta. L'applicativo che produceva il log viene dismesso e si porta via, insieme al resto, l'unico componente capace di dimostrare qualcosa.

In tutti questi casi il dato è ancora lì. È il percorso di verifica che non esiste più, e senza quello l'ancoraggio è una ricevuta che ti sei scritto da solo.

Il verificatore è un deliverable

La conseguenza pratica, per chi costruisce questi sistemi, è che il verificatore non è un accessorio da aggiungere se avanza tempo. È un pezzo della consegna: un formato di serializzazione congelato e versionato, le proof esportabili, le coordinate on-chain in chiaro nel record, e uno strumento di verifica che gira fuori dal tuo perimetro — idealmente un file che un revisore può eseguire da solo.

Vale anche a monte della catena. L'AI Act, per i sistemi ad alto rischio, chiede registrazioni che restino utilizzabili nel tempo, non solo scritte una volta. Una registrazione che nessuno sa più aprire soddisfa la lettera e manca il punto.

La domanda di progetto, insomma, non è mai stata «cosa ancoriamo». È chi verificherà, con cosa in mano, e se quel percorso funziona ancora quando la tua azienda non è nella stanza.

Se un revisore te lo chiedesse oggi, potrebbe verificare una singola entry senza di te?