Una transazione CBDC può essere confermata come valida senza che nessuno al di fuori delle persone coinvolte conosca l'importo.
Questo è il tipo di sistema che @SignOfficial sta sperimentando con implementazioni permissioned basate su Hyperledger Fabric.
Sembra ragionevole. Ma è anche il momento in cui le cose iniziano a complicarsi.
Non si tratta di nascondere tutto. Ma solo di rivelare ciò che deve essere rivelato.
In teoria, le CBDC sono sempre bloccate tra due estremi. Da un lato ci sono la trasparenza come RTGS, dove le banche vedono tutto. Dall'altro lato c'è la privacy come il contante, dove nessuno vede nulla al di fuori delle persone coinvolte. La maggior parte dei sistemi sceglie un punto a metà strada.
Sign si evolve in un modo diverso. Si dividono in molti spazi.
wCBDC per le interbancarie. rCBDC per gli utenti. Un livello separato per i regolatori. Ogni namespace ha la propria policy di endorsement; ogni transazione deve essere confermata secondo regole diverse.
La privacy non è più una proprietà legata alla transazione. È una conseguenza dello spazio a cui appartiene quella transazione. Se si trova nel wholesale, il livello di trasparenza è vicino al RTGS. Se si trova nel retail, le informazioni sono visibili solo al mittente, al destinatario e all'ente di regolamentazione designato.
Non c'è una configurazione comune. Questo approccio consente a ciascun tipo di transazione di avere un livello di privacy diverso sin dall'architettura.
Il secondo livello riguarda la gestione delle transazioni. Il sistema utilizza il Hyperledger Fabric Token SDK con il modello UTXO. Ogni transazione consuma un output vecchio e crea un nuovo output. Combinato con le zero-knowledge proofs (ZKP), il sistema dimostra solo ciò che è necessario, senza rivelare tutti i dati.
Un esempio: una transazione al dettaglio può dimostrare che non supera il limite di 10.000 USD senza rivelare l'importo esatto, o dimostrare che il destinatario appartiene a un gruppo idoneo senza rivelare l'intera identità. La verifica continua a svolgersi, ma i dati non vengono completamente esposti.
Le implementazioni permissioned di questo tipo puntano a un throughput di ~100.000 transazioni al secondo, adatto per ambienti interbancari o implementazioni nazionali. A quella scala, l'operazione di “nascondere tutto e decifrare quando necessario” è praticamente impossibile. La divulgazione selettiva diventa obbligatoria.
Ma i rischi iniziano a emergere. La privacy secondo il namespace solleva la domanda: chi decide a quale namespace appartieni. Se una transazione è classificata erroneamente, il livello di privacy è anch'esso errato. Se la policy di endorsement è distorta, anche il diritto di conferma lo è. Non è un errore di crittografia, ma un errore di governance.
Un livello più profondo: i regolatori non sono più esterni. Ricevono accesso a livello architetturale, necessario per la compliance, l'audit e la politica monetaria. Ma assumere che l'accesso venga sempre utilizzato per scopi corretti è un rischio reale.
Questo sistema funziona quando tre elementi sono bilanciati: separazione del namespace sufficientemente chiara, policy sufficientemente rigide, accesso controllato correttamente. Inizia a presentare problemi quando uno dei tre elementi viene distorto: namespace mescolati, policy allentate, accesso esteso oltre le aspettative.
La privacy nel Sign Protocol non è un interruttore on/off. È il risultato di come il sistema definisce: chi sei, dove stai transando e quale regola segui. Non tutte le transazioni sono private, non tutte le transazioni sono trasparenti. Ogni transazione nasce con un livello di privacy già definito.
Funziona se l'architettura mantiene confini chiari tra i layer.
Fallisce se quel confine viene violato.
Questo è anche il motivo per cui continuo a monitorare come design simili vengano implementati nella pratica, dove gli errori non derivano dal codice, ma da come le persone definiscono e gestiscono il sistema.
$SIGN #SignDigitalSovereignInfra
