Dimostrare un file da un batch Merkle: il certificato di inclusione

Quando pubblichi un batch di file su Cardano, on-chain finisce una sola piccola impronta: una singola Merkle root che rappresenta l'intero elenco. Questo mantiene economica la pubblicazione. Ma solleva una domanda ovvia — se on-chain c'è solo la root, come dimostri in seguito che un file specifico faceva davvero parte del batch?

La risposta è un certificato di inclusione: un piccolo file che puoi scaricare e che dimostra che l'hash di un file specifico faceva parte di quel batch pubblicato. Chiunque può verificarlo nel proprio browser, contro un qualsiasi explorer Cardano pubblico, senza fiducia in CardanoWall. E poiché la prova è incorporata nel file, continua a funzionare per sempre.

È il compagno quotidiano del Merkle batching. Il batching è il modo in cui ti impegni su migliaia di file in una volta sola; un certificato di inclusione è il modo in cui ne ripeschi uno e lo dimostri in seguito.

Quale problema risolve un certificato di inclusione?

Immagina di aver pubblicato l'anno scorso mille file in un solo batch — una cartella di contratti, un insieme di artefatti di rilascio, una giornata di log di audit. Sono stati tutti ripiegati in una sola Merkle root, e quella root è stata marcata temporalmente su Cardano. Economico, compatto, fatto.

Ora qualcuno contesta uno solo di quei file. Magari una controparte chiede: «Puoi mostrare che proprio questo contratto esisteva prima della scadenza?». La blockchain conserva solo la root, non il file e non l'elenco. Indicare la transazione dimostra che esisteva un qualche batch di dimensione nota — ma non che questo documento ne facesse parte.

Un certificato di inclusione colma questa lacuna. È un file minuscolo e autonomo che dice, in sostanza: «l'hash di questo file era l'item numero 42 del batch che sta dietro a questa transazione Cardano, ed ecco l'esatto calcolo che chiunque può eseguire per confermarlo». Consegni il certificato, e l'altra parte lo verifica senza che servano ancora tu, il tuo account o persino il nostro sito.

Cosa contiene davvero un certificato?

Pensalo come un plico di prove sigillato in tre parti.

• L'impronta del tuo file. Non il file stesso — solo il suo hash. Il certificato non trasporta mai il contenuto del tuo documento, quindi è sicuro condividerlo anche quando il file è privato.
• Il percorso della prova. Un breve elenco di impronte «fratelle» che permette a chiunque di ripiegare l'hash del tuo file risalendo il Merkle tree e arrivare esattamente alla root pubblicata. È questa la parte che rende il certificato autonomo: il calcolo è incorporato, così nessuno deve mai chiederti il resto del batch.
• L'àncora sulla blockchain. La transazione Cardano in cui è stata pubblicata la root, l'orario che la blockchain ha registrato per essa e un paio di link a explorer pubblici, così chiunque può controllare da sé.

Include inoltre una riga claim in linguaggio chiaro che dichiara cosa dimostra il certificato, e una breve nota su come verificarlo in modo indipendente. Un singolo certificato può coprire un file o più di uno alla volta: ciascuno riceve il proprio percorso di prova e un chiaro contrassegno verified.

CardanoWall può consegnarti questo plico in un paio di formati: un file JSON (l'originale leggibile dalle macchine che gli strumenti possono ricontrollare) e un PDF (una versione leggibile e stampabile per le persone e i fascicoli legali, con il JSON inserito al suo interno come allegato, così il documento resta verificabile dalle macchine).

Come ne ottieni uno?

Lo crei tu stesso, sulla pagina della transazione, nel tuo browser.

Apri la pagina pubblica della transazione che ha trasportato il batch. Poiché il record contiene una Merkle root, la pagina offre un controllo di inclusione. Da lì sono due piccoli passi:

1. Indicale quale file. Puoi incollare l'hash del file, oppure semplicemente trascinare il file sulla pagina: il tuo browser ne calcola l'hash localmente e non lo carica mai.
2. Leggi il risultato. La pagina recupera la lista delle foglie del batch, ricalcola la prova e ti mostra un risultato chiaro verde (il tuo file è nel batch) o rosso (non lo è).

Quando è verde, scarichi il certificato — JSON, PDF o entrambi. Quel download è la prova portabile. Inviala via email, archiviala, allegala a un contratto, depositala in una data room. Da quel momento è del tutto indipendente da CardanoWall.

Tutto avviene lato client. Non generiamo il certificato su un server per poi chiederti di fidarti; è il tuo browser a fare il lavoro, ed è esattamente per questo che il risultato è affidabile.

Perché nessuno deve fidarsi di CardanoWall?

Perché nulla nel certificato dipende dal fatto che noi siamo onesti, online o persino ancora in attività.

In un certificato di inclusione ci sono due affermazioni, ed entrambe sono cose che chiunque può verificare da sé:

• Il tuo file era nel batch. Un verificatore ripiega l'hash del tuo file lungo il percorso della prova e conferma che riproduce la root pubblicata. È pura aritmetica — serve solo il file del certificato, nient'altro. Se anche un solo bit del tuo file fosse cambiato, il ripiegamento atterrerebbe su una root diversa e il controllo fallirebbe.
• La root è davvero su Cardano. Un verificatore cerca la transazione su un qualsiasi explorer Cardano pubblico — Cardanoscan, AdaStat, uno a sua scelta — e conferma che la stessa root si trova nel record on-chain. In quella ricerca non è coinvolto alcun server di CardanoWall.

Messi insieme, questi due controlli dimostrano che il file esisteva entro o prima dell'orario che la blockchain ha impresso su quella transazione. E quell'orario viene da Cardano, non da noi. Non possiamo mandare avanti un blocco, retrodatare una transazione o modificare in silenzio la storia; è la blockchain a decidere quando le cose sono accadute. È proprio questo il senso di ancorarsi a una catena pubblica invece di chiederti di fidarti dell'orologio di un'azienda.

Se CardanoWall sparisse domani, ogni certificato che abbiamo mai emesso continuerebbe a verificarsi. Lo strumento da riga di comando open source cardanowall, e qualunque strumento indipendente che comprenda il formato, possono rieseguire gli stessi controlli.

flowchart LR
  A["Il tuo file"] -->|"hash locale"| B["Hash del file"]
  B --> C["Ripiega il percorso della prova"]
  C --> D["Root ricalcolata"]
  E["Transazione Cardano<br/>(explorer pubblico)"] --> F["Root pubblicata + block time"]
  D -->|"devono coincidere"| F
  F --> G["Esisteva entro o prima<br/>del block time"]

Cosa non dimostra un certificato?

Un certificato è preciso su una cosa e silenzioso su tutto il resto — ed essere onesti su questo è ciò che lo rende affidabile.

Dimostra che l'hash di un file specifico esisteva entro o prima del block time della blockchain, e che faceva parte del batch impegnato. Tutto qui. In particolare:

• Non dimostra chi ha creato il file. Un certificato non dice nulla sulla paternità. Chiunque potrebbe aver pubblicato il batch. (In Label 309 la paternità è una firma separata e opzionale, mai data per scontata — vedi cosa non dimostra una prova.)
• Non dimostra che il file sia vero, accurato o lecito. Dimostra che i byte esistevano entro un certo momento, non che ciò che dicono sia corretto.
• Non dimostra che il file sia l'unica versione né l'originale. Dimostra che proprio questo file era nel batch — non che non esista nessun'altra versione.
• Non è un timestamp «qualificato». È un timestamp ancorato a blockchain, della stessa famiglia degli altri timestamp blockchain. È una prova corroborante solida sul fattore tempo, ma non è un timestamp elettronico qualificato eIDAS emesso da un'autorità regolamentata. Se un processo richiede specificamente un timestamp qualificato, questo da solo non soddisfa quel requisito (vedi proof of existence e autorità di marcatura temporale).

Il valore del certificato sta proprio nel fatto che non rivendica nulla di più. Inchioda il momento temporale e l'integrità, e lascia il significato ai documenti e alle persone che gli stanno intorno.

Che relazione c'è con OpenTimestamps?

Se conosci già OpenTimestamps, l'idea ti risulterà familiare.

OpenTimestamps ti dà un piccolo file di prova .ots: un timestamp portabile e autonomo che chiunque può verificare in seguito senza fidarsi del servizio che lo ha creato. Un certificato di inclusione è una cosa della stessa forma — un file di prova portabile che puoi consegnare a chiunque — con due differenze che vale la pena conoscere.

L'autorità di marcatura temporale è la blockchain Cardano, con l'orario preso dal blocco che ha trasportato la tua root, anziché da un server di calendario. E il calcolo della prova è la stessa costruzione a Merkle tree usata altrove nello standard, così un singolo certificato può estrarre un file da un grande batch impegnato. Stesso spirito, àncora diversa.

Per un confronto più completo, fianco a fianco, vedi come la Proof of Existence si confronta con OpenTimestamps.

In breve

Pubblica molti file sotto una sola Merkle root e mantieni minuscolo il costo della blockchain. Un certificato di inclusione è il modo in cui dimostri in seguito che uno qualsiasi di quei file faceva davvero parte del batch: un piccolo download, verificabile nel tuo browser, contro un qualsiasi explorer Cardano pubblico, con l'orario fornito dalla catena e senza fiducia in CardanoWall. Il percorso della prova è incorporato nel file, così il certificato continua a funzionare molto dopo che un particolare strumento, account o azienda è scomparso.

Per approfondire

• Un solo record per migliaia di file — come il Merkle batching ripiega un intero elenco nella singola root contro cui un certificato verifica.
• Come la Proof of Existence si confronta con OpenTimestamps — il parente più stretto: un altro file di prova portabile e auto-verificabile.
• Cosa dimostra — e cosa non dimostra — una prova — i limiti onesti che valgono per ogni certificato.
• Verifica un record Label 309 — controllare il record on-chain a cui punta l'àncora di un certificato.
• Lo standard, gli SDK e la CLI open source, e il testo della specifica: label309.org e github.com/cardanowall.