Un solo record per migliaia di file: il Merkle batching

Un solo record Label 309 può dimostrare che migliaia o milioni di file esistevano in un dato momento.

Invece di pubblicare una transazione blockchain per ogni file, calcoli l'hash di ogni file, ripieghi quegli hash in un Merkle tree e pubblichi una singola Merkle root da 32 byte. In seguito puoi dimostrare che un file faceva parte di quel batch con una piccola inclusion proof — senza rivelare il resto e senza mettere ogni item on-chain.

È così che la Proof of Existence passa da un singolo documento a un insieme arbitrariamente grande.

Quale problema risolve il Merkle batching?

Le blockchain sono un pessimo posto dove conservare lunghi elenchi. Ogni byte costa una fee e una transazione Cardano ha un tetto rigido alle dimensioni.

Se un sistema genera un flusso costante di artefatti — log, output di modelli, build di rilascio, fatture, report, voci di prova — pubblicare ogni hash come record on-chain a sé diventa in fretta costoso e dispersivo.

Il Merkle batching comprime un elenco ordinato di hash in un unico commitment espresso da una root. La root ha dimensione fissa (32 byte), il batch può essere illimitato e la prova per ogni singolo item resta piccola — cresce solo con il logaritmo della dimensione del batch. Questo rende praticabili commitment regolari per i flussi di lavoro ad alto volume.

Cos'è una Merkle root?

Una Merkle root è un singolo hash che si impegna su un intero elenco ordinato.

Parti da una lista di foglie. In un flusso di lavoro di Proof of Existence, ogni foglia è di solito l'hash di un file, di un evento o di una voce di manifest. Le foglie vengono combinate a coppie risalendo un albero binario, e l'hash in cima è la Merkle root.

Il commitment è esatto in tre modi:

• se cambia una qualsiasi foglia, cambia la root;
• se cambia l'ordine delle foglie, cambia la root;
• il commitment registra anche quante foglie ci sono, così un elenco di dimensione diversa non può spacciarsi per lo stesso batch.

Pubblicare la root è come pubblicare un'impronta dell'intero elenco ordinato.

Cosa finisce davvero on-chain?

Solo la root. L'elenco completo delle foglie resta off-chain.

Un record Label 309 trasporta il commitment in un campo merkle dedicato, separato dagli ordinari hash per singolo file. Ogni commitment è una struttura piccola e a dimensione fissa:

• l'algoritmo del commitment (Label 309 v1 registra rfc9162-sha256: il Merkle Tree Hash di RFC 9162 con SHA-256);
• la root da 32 byte;
• il leaf count, che vincola la root alla dimensione dell'elenco off-chain;
• URI opzionali indirizzati per contenuto (ar:// o ipfs://) che puntano al file con la lista delle foglie.

Il record on-chain resta minuscolo — una sola root si impegna su un elenco illimitato al costo fisso di 32 byte. Il dettaglio risiede off-chain, nella lista ordinata delle foglie. (Per dove risiede il resto di un record, vedi cosa finisce sulla blockchain.)

Come si dimostra in seguito un singolo file?

Produci una inclusion proof.

Una inclusion proof è il breve elenco di hash fratelli lungo il percorso da una foglia fino alla root. Un verificatore ripiega la foglia e quei fratelli risalendo l'albero, e accetta la prova solo se la root ricalcolata è esattamente uguale alla root pubblicata.

In pratica il controllo ha quattro input:

1. l'hash del file o dell'item che stai dimostrando;
2. la inclusion proof (il percorso dei fratelli);
3. la Merkle root nel record Label 309;
4. il block time Cardano della transazione che l'ha trasportata.

Se il ripiegamento riproduce la root pubblicata, l'item era nell'elenco impegnato — e il block time testimonia quando quell'elenco esisteva. Al verificatore servono il singolo item e la sua prova; non gli servono mai gli altri file del batch.

Due dettagli da tenere a mente. La costruzione è sensibile all'ordine, quindi le foglie vanno mantenute nella stessa sequenza in cui sono state pubblicate. E un «albero» a foglia singola non è un timestamp utile: la root di un albero a una foglia non è la foglia stessa, perciò per dimostrare un singolo file pubblichi un semplice hash del contenuto, non un commitment Merkle a un solo item.

Perché costruire e verificare interamente offline è un punto di forza?

Perché l'unico passaggio che tocca un server è la pubblicazione della root.

Costruire l'albero, derivare le inclusion proof e verificarle sono pura computazione. Chiunque possieda la lista ordinata delle foglie può ricalcolare la root e riderivare qualsiasi prova — nessun account, nessun gateway, nessuna rete e nessuna collaborazione da parte di chi ha pubblicato in origine. Chi pubblica non è mai coinvolto nel momento della verifica.

Questo conta per le prove che devono sopravvivere a strumenti e fornitori. Una prova verificabile offline contro un explorer Cardano pubblico continua a funzionare molto dopo che un determinato servizio è scomparso. Puoi verificare un commitment di batch nello stesso modo in cui verificheresti un qualsiasi record Label 309, e puoi collegare il controllo di inclusione direttamente al tuo CI con lo strumento da riga di comando open source cardanowall (merkle-build per ripiegare una cartella in una root, merkle-verify per confermare che un item le appartiene).

Perché tutto questo è utile per i flussi di lavoro ad alto volume?

Perché molte prove reali hanno la forma di un batch, non di un singolo file. Un team può aver bisogno di mostrare:

• cosa ha costruito una pipeline CI/CD e quali artefatti sono stati rilasciati in una release;
• quale software bill of materials (SBOM) esisteva prima che fosse divulgata una vulnerabilità;
• quali output AI sono stati prodotti in un determinato giorno;
• quale snapshot di dataset esisteva prima di un training;
• quali log di compliance esistevano prima di un audit;
• quali file di prove legali sono stati conservati prima di un blocco;
• quali riserve un bilancio impegnava in un dato momento.

Nessuno di questi casi si adatta bene a un modello «un file, una transazione». Il Merkle batching ti permette di pubblicare un singolo commitment per batch — senza esporre ogni item privato e senza metadati on-chain che crescono linearmente con la dimensione del batch.

La lista delle foglie può restare privata?

Sì. La root pubblicata non rivela nulla sulle foglie su cui si impegna.

Puoi tenere la lista delle foglie all'interno del tuo sistema di prove, del tuo archivio di rilascio, della tua data room o del tuo store di compliance, e in seguito rivelare solo ciò che ti serve:

• un file e la sua inclusion proof;
• una riga di dataset, un documento o un artefatto di rilascio;
• una voce di log di audit;
• un sottoinsieme dell'elenco;
• oppure l'intera lista delle foglie.

Questo è lo schema da seguire quando vuoi un commitment pubblico e con timestamp senza rendere pubblici i dati sottostanti — strettamente legato a divulgazione confidenziale senza file pubblici e proof of reserves con Merkle root.

Il compromesso è la responsabilità. Una root dimostra che un qualche elenco di dimensione nota esisteva in un momento noto; di per sé non permette a nessuno di dimostrare quali item specifici contenesse. Se tieni privata la lista delle foglie, devi conservarla. Perdi sia la lista delle foglie sia eventuali inclusion proof salvate, e mantieni il timestamp ma perdi la capacità di dimostrare che un determinato item era impegnato.

Cosa dovrebbe essere una foglia?

Una foglia dovrebbe rappresentare esattamente la cosa che potresti dover dimostrare in seguito.

Per i file, la foglia è l'hash dei byte del file. Per i dati strutturati, è di solito l'hash di una voce di manifest canonica. Per il CI/CD, una foglia può essere un digest di artefatto, un digest di SBOM, un digest di build-log, un riferimento a un commit o una voce firmata di manifest di rilascio. Per la provenienza AI, una foglia può essere l'hash di un file di output, una voce di manifest prompt/output, un commitment di item di dataset o l'hash di un manifest di provenienza del contenuto.

La disciplina che conta è la coerenza. Se le foglie vengono generate in modi diversi tra un'esecuzione e l'altra, diventa difficile fidarsi delle inclusion proof successive. Fissa una volta la definizione della foglia e la canonicalizzazione, e applicale sempre allo stesso modo.

Conviene pubblicare la lista delle foglie o tenerla privata?

Dipende da cosa stai dimostrando e da chi dovrebbe vederla.

Pubblicare la lista delle foglie rende banale la verifica da parte di terzi: chiunque può recuperare l'elenco, ricalcolare la root e ispezionare l'insieme impegnato. Tenerla privata ti dà confidenzialità e divulgazione selettiva — riveli le inclusion proof solo quando serve. Molti flussi di lavoro fanno entrambe le cose: una lista delle foglie pubblica per le release open source, una privata per i log di compliance interni, una sigillata per le prove sensibili.

La root è il commitment pubblico. La politica sulla lista delle foglie è una scelta separata che vi si sovrappone.

Con quale frequenza pubblicare le root?

Adatta la cadenza al flusso di lavoro.

Un sistema CI/CD potrebbe pubblicare una root per release, build o finestra di deployment. Un sistema di compliance potrebbe pubblicare una root all'ora, al giorno o per periodo di controllo. Una piattaforma AI potrebbe pubblicare root per ogni batch di contenuto generato, per ogni snapshot di training o per ogni evento di versione del modello. Un sistema di prove legali potrebbe pubblicare una root per ogni fascicolo di caso, finestra di acquisizione o milestone della catena di custodia.

La cadenza giusta bilancia costo, semplicità operativa e quanto precisa dovrà essere la timeline che potresti dover dimostrare in seguito.

Cosa non dimostra una Merkle root?

Una Merkle root dimostra l'impegno su un elenco in un dato momento. Non dimostra le affermazioni di business costruite attorno a quell'elenco. Come ogni Proof of Existence, mostra che byte specifici esistevano entro un momento pubblico — non che siano veri, leciti, scritti da qualcuno in particolare o di proprietà di qualcuno (vedi cosa non dimostra una prova).

In concreto:

• non dimostra che una build software fosse sicura. Può dimostrare quali artefatti o manifest sono stati inclusi in una release;
• non dimostra che un dataset sia stato raccolto lecitamente. Può dimostrare che un commitment di dataset esisteva prima di un dato momento;
• non dimostra che una voce di log sia vera. Può dimostrare che la voce faceva parte di un batch impegnato;
• non dimostra la paternità — a meno che il record o il processo circostante non aggiungano firme e controlli di identità.

In Label 309 la paternità è opzionale ed esplicita: un record può portare firme separate, ma non sono mai obbligatorie, e un commitment Merkle di per sé non afferma nulla su chi ha prodotto l'elenco. La root dà il commitment con timestamp; il processo che la circonda dà il significato di business.

Come si inserisce Label 309?

Label 309 è lo standard aperto e neutrale rispetto al fornitore per la Proof of Existence su Cardano; è stato sottoposto al processo CIP di Cardano ed è in revisione presso gli editor CIP come proposta di categoria Metadata. Il Merkle batching non è un prodotto a parte — è il livello di scalabilità integrato nello standard.

Un commitment di batch usa lo stesso record e lo stesso percorso di verifica di una prova a singolo file. Un solo record sotto la label dei metadati 309 può portare una Merkle root e, accanto a essa, gli stessi pezzi opzionali che ogni record supporta: ordinari hash per singolo file, URI di storage indirizzati per contenuto, un puntatore di supersessione a un record precedente e firme di paternità. Così una prova di batch eredita tutto ciò che ha una prova singola:

• una testimonianza di block time Cardano;
• una struttura di record standard e chiusa;
• verifica autonoma e offline contro un explorer pubblico;
• gli stessi strumenti, librerie e CLI open source nei vari linguaggi.

Calcola l'hash di ogni item, costruisci un Merkle tree ordinato, pubblica una root in un record Label 309 e conserva la lista delle foglie e le eventuali prove che potrebbero servirti. In seguito, dimostra che un qualsiasi singolo item faceva parte del batch impegnato — senza mettere ogni item on-chain. È questo che rende la Proof of Existence praticabile per CI/CD, provenienza AI, dataset, compliance, prove legali e altri flussi di lavoro ad alto volume.

Per approfondire

• Come funziona Label 309 — la struttura di record in cui si inserisce un commitment di batch.
• Dimostrare i dati di training senza rivelarli — divulgazione selettiva da una lista delle foglie privata, dall'inizio alla fine.
• Come si confronta Label 309 con OpenTimestamps — un altro protocollo che aggrega molti hash in una sola àncora.
• Lo standard, gli SDK e la CLI open source, e il testo della specifica: label309.org e github.com/cardanowall.
• RFC 9162 — la costruzione Merkle Tree Hash che Label 309 usa per i commitment di batch.