Proof of reserves con le Merkle root

Una Merkle root può rendere molto più facile da verificare uno snapshot di proof of reserves, ma da sola non dimostra la solvibilità. Dimostra che un insieme preciso di voci è stato impegnato in un momento preciso. Se quelle voci compongano o no un'azienda solvente è una questione a parte.

Ecco lo schema. Un exchange, un custode, una fintech, un marketplace, un emittente di stablecoin o un team di tesoreria interno costruisce un Merkle tree su uno snapshot di riserve o passività, poi ancora la singola root da 32 byte con un record Label 309 su Cardano. Ogni cliente, wallet o riga di saldo è una foglia. In seguito, a qualunque partecipante si può consegnare una breve inclusion proof che mostra come la sua voce facesse parte dello snapshot impegnato — senza che l'intero dataset venga mai pubblicato.

Il timestamp svolge un compito preciso: fissa quando quell'impegno è esistito, su una catena pubblica, senza alcun server dell'emittente da dover credere sulla parola. La qualità dello snapshot in sé continua a dipendere dalla contabilità, dal perimetro, dalla copertura delle passività, dai controlli di custodia e dalla revisione indipendente.

Cos'è uno snapshot di proof of reserves?

Uno snapshot di proof of reserves è una prova sugli asset in un dato momento.

Per le aziende crypto-native significa spesso dimostrare che certi wallet on-chain detenevano certi asset a una certa block height o a un certo momento. In un processo più solido, collega anche quegli asset alle passività verso i clienti, ai registri interni, ai controlli di custodia e alla revisione indipendente.

Uno snapshot può includere:

i saldi dei wallet di riserva;
gli identificatori degli asset;
le block height;
i saldi delle passività;
gli impegni sui conti dei clienti;
esclusioni e rettifiche;
i report dei revisori;
le prove dei controlli;
i file di riconciliazione;
le attestazioni del management.

Lo snapshot non è un bilancio vivo. È un impegno a un istante preciso.

Perché usare una Merkle root?

Perché di solito lo snapshot completo è troppo grande o troppo sensibile per essere pubblicato.

Un Merkle tree permette a un'azienda di impegnarsi su molte voci con una sola root da 32 byte. Ogni cliente, conto, wallet o riga di saldo diventa una foglia, le foglie vengono combinate via hash in un albero e solo la root finisce on-chain. La root non rivela nulla sulle foglie su cui si impegna, eppure è vincolata a tutte: cambia una foglia qualsiasi, o il numero di foglie, e la root non corrisponde più. In seguito, un partecipante riceve una inclusion proof — un breve percorso di nodi fratelli, dell'ordine di log n hash — che mostra come la sua voce facesse parte dello snapshot impegnato.

È questo che rende possibile la divulgazione selettiva:

un singolo cliente può verificare solo la propria inclusione;
a un revisore si può consegnare l'intera lista delle foglie e la mappatura dei conti;
il pubblico vede soltanto la root con il timestamp;
i dettagli sensibili dei conti non devono mai essere esposti.

È lo stesso meccanismo di batching che sta dietro l'ancoraggio di un solo record per migliaia di file: la root è compatta, ma ciò che conta davvero è il processo sottostante.

Cosa aggiunge Label 309?

Aggiunge un timestamp pubblico e indipendente che nessuna singola parte controlla.

Un report di proof of reserves vive spesso su un sito web o in un PDF, e la Merkle root in un post di blog. Ma un sito web può cambiare. Un PDF può essere sostituito. Un report può essere aggiornato in silenzio, e con esso può sparire una root precedente.

Pubblicare la root dello snapshot in un record Label 309 dà invece all'impegno un'àncora temporale pubblica su Cardano. In seguito chiunque può confermare che la stessa root esisteva entro il block time della transazione, usando solo i metadati della transazione e un explorer Cardano pubblico — senza alcun server dell'emittente, e senza dover credere al dominio o all'infrastruttura di CardanoWall.

Il record può includere anche:

l'hash di una dichiarazione firmata;
gli hash degli snapshot degli asset;
le root degli snapshot delle passività;
gli URI dei report indirizzati per contenuto;
workpaper di audit sigillati per destinatari selezionati;
un puntatore di supersessione per i report corretti.

Cosa dovrebbe finire nello snapshot?

Definisci la rivendicazione prima di costruire l'albero.

Lo snapshot dovrebbe chiarire cosa sta dimostrando. Uno snapshot di sole riserve non è la stessa cosa di uno snapshot di riserve-e-passività. Uno snapshot del solo wallet non è la stessa cosa di un bilancio sottoposto a revisione.

Alcuni campi utili possono essere:

l'id dello snapshot;
l'ora dello snapshot;
la catena e l'id dell'asset;
la block height o il riferimento di registro;
l'indirizzo del wallet o l'id del conto interno;
il saldo;
l'hash della voce di passività;
l'hash dell'identificatore del cliente o l'id offuscato;
l'hash della foglia di inclusione;
il riferimento del revisore o del valutatore;
l'hash del report;
la dichiarazione di perimetro;
le esclusioni;
l'indice della foglia Merkle.

Lo schema dovrebbe essere deterministico. Se la costruzione delle foglie è ambigua, la verifica diventa fragile.

Come possono i clienti verificare l'inclusione?

L'azienda consegna a ciascun cliente un pacchetto di prova.

Quel pacchetto può includere:

la voce di saldo del cliente stesso;
il salt o il materiale di offuscamento, se usato;
il percorso Merkle;
la root;
il riferimento della transazione Label 309;
l'hash del report;
le istruzioni di verifica.

Il cliente verifica che la sua voce produca via hash la foglia, che il percorso Merkle si ricomponga fino alla root pubblicata e che la root corrisponda a quella presente nel record Label 309 on-chain. Niente di tutto questo richiede che i server dell'azienda siano online o onesti — gli strumenti Label 309 open source, incluso lo strumento da riga di comando cardanowall, possono verificare un record e controllare le inclusion proof in modo indipendente.

Questo dimostra l'inclusione in quello snapshot. Non dimostra che ogni altro conto sia stato gestito correttamente, ed è proprio per questo che la prospettiva del revisore qui sotto conta.

Come possono usarlo i revisori?

I revisori possono ispezionare l'intero insieme di prove.

Il pubblico può vedere solo la root e un report. A un revisore o a un'autorità di vigilanza si può consegnare il manifest completo, la lista delle foglie, la mappatura dei conti, le prove sui wallet, i file di riconciliazione e i workpaper sigillati.

Label 309 può aiutare ancorando:

la root pubblica;
l'hash del manifest privato completo;
le prove dei saldi dei wallet;
i file delle passività;
gli export di riconciliazione;
le bozze del report di audit;
il report finale firmato.

Questo rende l'audit trail più difficile da riscrivere a posteriori.

E le correzioni?

Le correzioni dovrebbero essere visibili, non nascoste.

Se l'azienda scopre un errore in uno snapshot, dovrebbe pubblicare un record corretto invece di sostituire in silenzio il vecchio report. Label 309 ha un meccanismo integrato per questo: un puntatore supersedes porta con sé l'hash della transazione del record precedente, creando un collegamento append-only dalla correzione a ciò che sostituisce.

Su questo collegamento vale la pena capire due cose. Primo, la supersessione non rimuove né invalida il record precedente — la catena è append-only, quindi la root originale resta on-chain e verificabile in modo indipendente per sempre. Il nuovo record le sta accanto e rimanda a essa; chi legge può vedere entrambi. Secondo, perché il collegamento sia affidabile, entrambi i record dovrebbero essere firmati dalla stessa chiave. Chiunque può pubblicare un record che dichiara di sostituire il tuo, perciò ci si aspetta che verificatori e strumenti onorino un collegamento di supersessione solo quando il record che sostituisce è firmato da una chiave presente anche nell'originale. Se intendi emettere correzioni, firma i tuoi snapshot.

È di gran lunga meglio che fingere che la prima root non sia mai esistita.

Cosa non dimostra tutto questo?

Da solo non dimostra la solvibilità.

Non dimostra che tutte le passività siano state incluse.

Non dimostra che gli asset siano liberi da vincoli.

Non dimostra che le chiavi siano controllate in modo sicuro.

Non dimostra che gli asset non siano stati presi in prestito temporaneamente per lo snapshot.

Non sostituisce un audit, una revisione di un'autorità di vigilanza, i controlli contabili o la riconciliazione delle passività verso i clienti.

Ciò che dimostra è ristretto e davvero utile: un impegno preciso è esistito a un'ora pubblica, e si può mostrare che singole voci ne fanno parte. Come per qualunque Proof of Existence, è una prova del momento e dell'integrità, non della verità o dei diritti.

Dove può essere utile al di fuori degli exchange crypto?

Lo stesso schema funziona ovunque uno snapshot abbia molte voci private.

Esempi:

le riserve di stablecoin;
i report sugli asset tokenizzati;
i saldi dei venditori su un marketplace;
i saldi di custodia delle fintech;
gli snapshot di tesoreria interni;
i registri di equity dei dipendenti;
le passività dei punti fedeltà;
gli inventari di crediti di carbonio;
le riserve per sinistri assicurativi;
i registri dei depositi dei clienti.

L'idea condivisa è semplice: impegnati su molte voci, rivela in modo selettivo, conserva il timestamp.

In breve

Le Merkle root rendono scalabili gli snapshot di proof of reserves. Label 309 rende la root dotata di timestamp e verificabile in modo indipendente rispetto a una catena pubblica.

Usa la root per impegnarti sullo snapshot. Usa le inclusion proof per clienti e revisori. Usa i record sigillati per le prove sensibili. Usa la supersessione — con le firme — per le correzioni.

Poi sii onesto sul limite: una Merkle root con timestamp non è solvibilità. È un tassello solido e a prova di manomissione di un processo di prova più ampio. Label 309 è di per sé uno standard aperto e neutrale rispetto al fornitore, sottoposto al processo CIP di Cardano e attualmente in revisione presso gli editor CIP come proposta di categoria Metadata — il batching, l'hashing e i meccanismi di supersessione descritti sopra sono definiti nello standard, non in un singolo prodotto.

Approfondimenti

Lo standard e la specifica Label 309 — il formato wire per i record, gli impegni Merkle, le firme e la supersessione.
Il codice open source, gli SDK e la CLI cardanowall — verifica record e inclusion proof senza dover credere ad alcun singolo server.
La proposta CIP di Label 309 — la submission che traccia la revisione nel processo CIP di Cardano.
Un solo record per migliaia di file — il meccanismo di batching più in dettaglio.
Log di compliance senza fiducia nel fornitore — lo stesso schema di impegno-e-ancoraggio applicato ai log di audit e di eventi.
Cosa dimostra — e cosa non dimostra — una prova.