Mio padre ha trascorso due decenni in un ufficio registri governativo. File cartacei. Armadi chiusi a chiave. Stanze separate per documenti pubblici e sensibili. Stesso edificio, stesso personale. Un incendio nella hall ha minacciato tutto. Un'intrusione in una stanza non ha automaticamente esposto le altre. La separazione era reale, ma l'infrastruttura condivisa comportava un pericolo condiviso.
Quel ricordo è riemerso mentre leggevo il design Fabric X CBDC di Sign. Invece di canali separati per all'ingrosso (wCBDC), per cittadini al dettaglio (rCBDC) e per la supervisione normativa, utilizza un unico canale con partizionamento dello spazio dei nomi. Tre spazi dei nomi isolati all'interno di un unico canale condiviso. Ognuno opera sotto la propria politica di approvazione, definendo esattamente quali nodi devono convalidare prima dell'impegno. Un pagamento al dettaglio non ha bisogno dell'approvazione di una banca all'ingrosso. Una query normativa rimane invisibile ai validatori commerciali. Il controllo degli accessi appare preciso e mirato.
I livelli di privacy corrispondono anche ai casi d'uso. wCBDC mantiene la trasparenza in stile RTGS per la visibilità interbancaria. rCBDC utilizza prove ZK così i dettagli rimangono privati tranne che per mittente, destinatario e supervisione autorizzata. Lo spazio dei nomi normativo si trova sopra con accesso in lettura appropriato.
La logica è acuta. Operazioni diverse richiedono sinceramente visibilità diversa. Costruire separazione a livello di protocollo supera la sovrapposizione a livello di applicazione.
Ma ecco cosa persiste. Il canale è singolo.
Nell'architettura in stile Fabric, un canale è il confine di isolamento centrale. Gli spazi dei nomi condividono il servizio di ordinamento, la pipeline di commit, la struttura dei blocchi. Le politiche di approvazione applicano la separazione logica per l'accesso. Non forniscono isolamento fisico. Un fallimento di consenso, un bug nel servizio di ordinamento o un attacco mirato a livello di canale colpiscono tutti e tre gli spazi dei nomi contemporaneamente. Liquidazione interbancaria, pagamenti dei cittadini, supervisione normativa—tutto insieme.
Continuavo a rifletterci. Per la maggior parte dei fallimenti, il recupero potrebbe essere rapido: i microservizi limitano il raggio d'azione, Arma BFT tollera un terzo di nodi bizantini. Ma per un CBDC nazionale dove i pagamenti al dettaglio e la banca all'ingrosso condividono un dominio di fallimento, la domanda sembra ineludibile: cosa succede quando entrambi collassano simultaneamente in un evento peggiore?
C'è una preoccupazione più sottile che il whitepaper non risolve completamente per me. L'applicazione dell'approvazione avviene tra i peer. I peer controllano le firme prima del commit. Un peer compromesso potrebbe comportarsi in modo malevolo. L'isolamento dello spazio dei nomi regge in condizioni normali, ma cosa succede in quelle avversariali? La gerarchia del certificato X.509 garantisce identità e partecipazione. Questo è forte. Eppure le CA possono essere compromesse, le chiavi rubate, le configurazioni applicate in modo errato. In un unico canale, un'identità ribelle che ottiene accesso al canale si trova ancora all'interno della struttura dello spazio dei nomi—anche se le politiche limitano le sue azioni.
Questi non sono unici per Sign. Sono compromessi intrinseci nei design a canale condiviso. Ma per un'infrastruttura sovrana che mira ai governi, il divario tra isolamento logico e fisico merita una chiara comprensione prima del dispiegamento dal vivo.
Quindi mi chiedo: è il modello di spazio dei nomi a canale singolo il giusto equilibrio tra efficienza e isolamento per il CBDC nazionale... o un design in cui i risparmi delle infrastrutture condivise comportano un dominio di fallimento condiviso che diventa ovvio solo dopo che qualcosa si rompe?
#SignDigitalSovereignInfra @SignOfficial $SIGN
