Flusso di lavoro applicazione CBDC all'ingrosso riservato

Lo scenario della valuta digitale della banca centrale all'ingrosso riservata (CBDC) rappresenta una valuta distribuita attraverso una gerarchia strutturata di istituti finanziari, con informazioni riservate memorizzate privatamente.

La versione riservata dello scenario CBDC all'ingrosso è diversa dalla modalità di gestione dei dati delle transazioni. Le informazioni non riservate, come i dettagli delle transazioni di base e le informazioni sul conto organizzativo, vengono memorizzate nel libro contabile pubblico. Le informazioni riservate (ad esempio ID utente, valori di saldo effettivi e fattori di accecamento) vengono memorizzate nella raccolta dati privata di ciascuna organizzazione e passate al codice concatenato tramite una mappa transitoria, in modo che non vengano mai scritte nel libro mastro pubblico. I saldi contabili e i saldi in sospeso sono rappresentati come valori di impegno Pedersen nel registro pubblico, consentendo la verifica pubblica tramite prove a conoscenza zero senza esporre gli importi sottostanti. A livello di banca centrale, i trasferimenti di blocco utilizzano un processo di commit a due fasi per una transazione atomica che richiede l'esecuzione simultanea delle API executeHoldTokensSender e executeHoldTokensReceiver, che mantiene la riservatezza durante tutto il trasferimento. I trasferimenti a livello di istituto finanziario utilizzano l'API standard executeHoldTokens.

La tabella seguente riassume le principali differenze tra le versioni non riservate e riservate dello scenario CBDC all'ingrosso.
Operazione/dati CBDC non riservato CBDC riservato
Trasferimento tra organizzazioni (l'approvatore della banca centrale esegue il blocco) API executeHoldTokens (chiamata singola) API executeHoldTokensSender e executeHoldTokensReceiver (due chiamate simultanee eseguite in commit a due fasi)
Trasferimento intra-organizzazione (l'approvatore dell'istituto finanziario esegue il blocco) API executeHoldTokens (chiamata singola) API executeHoldTokens (chiamata singola, nessuna differenza)
Dati transazione nel libro contabile Tutti i dati memorizzati in formato normale sul libro contabile pubblico, nessuna separazione dei dati Dati non sensibili su libri contabili pubblici, dati sensibili (ID utente, saldi effettivi, fattori di accecamento) memorizzati nella raccolta di dati privati di ciascuna organizzazione
Rappresentazione saldo Valori saldo effettivi memorizzati direttamente Saldi rappresentati come valori di impegno Pedersen, importi effettivi non esposti nel libro contabile pubblico
Metodo di verifica Diretto: valori leggibili nel libro contabile Le prove a conoscenza zero consentono la verifica pubblica senza rivelare gli importi sottostanti
Gestione dei dati sensibili Memorizzato nel libro contabile pubblico Passato tramite mappa transitoria al codice concatenato, non scritto nel libro contabile pubblico

Nota

Le interfacce API executeHoldTokensSender e executeHoldTokensReceiver devono essere richiamate contemporaneamente come parte di un processo di commit a due fasi. Chiamare solo uno senza l'altro comporta un errore.
Nella tabella seguente vengono riepilogati gli attori in questo scenario.
Attore Ruolo Descrizione
Administrator Amministrazione token Inizializza il sistema e assegna ruoli.
Autore Minter Richiede la creazione di token e riceve token coniati.
Approvatore banca centrale Notaio Approva tutte le operazioni a livello di banca centrale.
Emittente nessuno Riceve i token dal creatore, instrada i token al funzionario dell'istituto finanziario o al pensionato.
Funzionario istituto finanziario nessuno Riceve token dall'emittente, distribuisce token agli utenti dell'istituto finanziario.
Approvatore istituto finanziario Notaio Approva i trasferimenti di blocco dal funzionario dell'istituto finanziario agli utenti dell'istituto finanziario.
Utente istituto finanziario nessuno Destinatario finale dei token trasferiti presso un istituto finanziario.
Ritiro Bruciatore Riceve token dall'emittente e invia richieste di burn all'approvatore della banca centrale.
L'amministratore completa i passaggi seguenti per inizializzare il sistema.
  1. Inizializzare il sistema CBDC utilizzando l'API initializeCBDCToken.
  2. Registrare le organizzazioni utilizzando l'API registerOrg.
  3. Creare account utilizzando l'API createAccount.
  4. Associare il token agli account utilizzando l'API associateTokenToAccount.
  5. Assegnare il ruolo minore al creatore, il ruolo notaio all'approvatore della banca centrale e il ruolo masterizzatore al pensionato utilizzando l'API addRole.
Dopo l'inizializzazione del sistema, un tipico flusso di processo segue questi passaggi di base.
  1. Valuta della menta.
    1. L'autore del token utilizza l'API requestMint per sottomettere una richiesta per creare token di deposito.
    2. L'approvatore della banca centrale utilizza l'API approveMint per rivedere e approvare la richiesta di zecca. I token vengono accreditati sull'account del creatore. In alternativa, l'approvatore della banca centrale può utilizzare l'API rejectMint per negare la richiesta.
  2. Trasferire i token all'emittente.
    • L'autore utilizza l'API transferTokens per inviare i token all'emittente.
  3. Trasferire i token ai funzionari finanziari.
    1. L'emittente utilizza l'API holdTokens per inviare token a un funzionario dell'istituto finanziario.
    2. L'approvatore della banca centrale utilizza le API executeHoldTokensSender e executeHoldTokensReceiver come parte di un commit in due fasi per convalidare e approvare la richiesta di trasferimento. In alternativa, l'approvatore della banca centrale può utilizzare l'API releaseHold per rifiutare il trasferimento.
  4. Emettere token agli utenti.
    1. Il responsabile dell'istituto finanziario utilizza l'API holdTokens per inviare i token a un utente dell'istituto finanziario.
    2. L'approvatore dell'istituto finanziario utilizza l'API executeHoldTokens per convalidare e approvare la richiesta di trasferimento. In alternativa, l'approvatore dell'istituto finanziario può utilizzare l'API releaseHold per rifiutare il trasferimento.
  5. Brucia i token.
    1. L'emittente utilizza l'API transferTokens per trasferire i token allo smobilizzo.
    2. Il pensionato utilizza l'API requestBurn per inviare una richiesta di masterizzazione all'approvatore della banca centrale.
    3. L'approvatore della banca centrale utilizza l'API approveBurn per approvare la richiesta di masterizzazione e i token vengono eliminati. In alternativa, l'approvatore della banca centrale può utilizzare l'API rejectBurn per rifiutare la richiesta.
  6. Verificare il saldo del token.
    • Gli utenti possono utilizzare l'API getAccountBalance per ottenere il numero totale di valute in loro possesso.