Geschäftskunden - CBDC-Anwendungsworkflow

Das Szenario der vertraulichen digitalen Zentralbankwährung (CBDC) stellt eine Währung dar, die über eine strukturierte Finanzinstitutshierarchie verteilt wird, wobei vertrauliche Informationen privat gespeichert werden.

Die vertrauliche Version des CBDC-Großhandels-Szenarios unterscheidet sich in der Handhabung von Transaktionsdaten. Nicht sensible Informationen wie grundlegende Transaktionsdetails und Organisationskontoinformationen werden im öffentlichen Buch gespeichert. Sensible Informationen (wie Benutzer-IDs, Ist-Saldenwerte und Blinding-Faktoren) werden in der privaten Datenerfassung jeder Organisation gespeichert und über eine transiente Karte an den Chaincode übergeben, sodass sie niemals in das öffentliche Buch geschrieben werden. Kontensalden und Einbehaltungssalden werden im öffentlichen Buch als Pedersen-Verpflichtungswerte dargestellt, sodass die öffentliche Verifizierung durch Zero-Knowledge-Nachweise ermöglicht wird, ohne die zugrunde liegenden Beträge anzugeben. Auf Zentralbankebene verwenden Überweisungen einen Zwei-Phasen-Commit-Prozess für eine atomare Transaktion, bei der gleichzeitig die APIs executeHoldTokensSender und executeHoldTokensReceiver ausgeführt werden müssen, wodurch die Vertraulichkeit während der Übertragung gewahrt wird. Transfers auf Finanzinstitutsebene verwenden die standardmäßige einzelne executeHoldTokens-API.

In der folgenden Tabelle werden die wichtigsten Unterschiede zwischen der nicht vertraulichen und der vertraulichen Version des CBDC-Großhandels-Szenarios zusammengefasst.
Arbeitsvorgang/Daten Nicht vertraulicher CBDC CBDC vertraulich
Zwischenbetriebliche Überweisung (Zentralbankgenehmiger führt Sperre aus) executeHoldTokens-API (einzelner Aufruf) executeHoldTokensSender- und executeHoldTokensReceiver-APIs (zwei gleichzeitige Aufrufe bei Two-Phase Commit)
Transfer innerhalb der Organisation (Genehmiger des Finanzinstituts führt eine Sperre aus) executeHoldTokens-API (einzelner Aufruf) executeHoldTokens-API (einzelner Aufruf, kein Unterschied)
Transaktionsdaten im Buch Alle Daten, die in einfacher Form im öffentlichen Ledger gespeichert sind, ohne Datentrennung Nicht sensible Daten im öffentlichen Buch, sensible Daten (Benutzer-IDs, Istsalden, Blinding-Faktoren), die in der privaten Datenerfassung jeder Organisation gespeichert sind
Saldendarstellung Tatsächliche Saldenwerte direkt gespeichert Salden, die als Pedersen-Verpflichtungswerte dargestellt werden, Istbeträge, die nicht im öffentlichen Buch angezeigt werden
Verifizierungsmethode Direkt: Werte können im Buch gelesen werden Zero-Knowledge-Beweise ermöglichen eine öffentliche Überprüfung, ohne die zugrunde liegenden Beträge aufzudecken
Handhabung sensibler Daten In öffentlichem Ledger gespeichert Über transiente Map an Chaincode übergeben, nicht in öffentliches Ledger geschrieben

Hinweis:

Die APIs executeHoldTokensSender und executeHoldTokensReceiver müssen gleichzeitig als Teil eines Zwei-Phasen-Commit-Prozesses aufgerufen werden. Wenn nur einer ohne den anderen aufgerufen wird, tritt ein Fehler auf.
In der folgenden Tabelle werden die Akteure in diesem Szenario zusammengefasst.
Teilnehmer Rolle Beschreibung
Administrator Token-Admin Initialisiert das System und weist Rollen zu.
Ersteller Minter Fordert das Prägen von Token an und erhält geprägte Token.
Zentralbankgenehmiger Notar Genehmigt alle Vorgänge auf Zentralbankebene.
Ausgebender Benutzer Kein Erhält Token vom Ersteller, leitet Token an den Finanzinstitutsleiter oder Retirer weiter.
Finanzinstitutsbeauftragter Kein Erhält Token vom Aussteller und verteilt Token an Benutzer von Finanzinstituten.
Finanzinstitutsgenehmiger Notar Genehmigt Sperrenübertragungen von Finanzinstitutsmitarbeitern an Finanzinstitutsbenutzer.
Finanzinstitutbenutzer Kein Endgültiger Empfänger übertragener Token bei einem Finanzinstitut.
Retoure Brenner Erhält Token vom Aussteller und sendet Verbrennungsanforderungen an den Zentralbankgenehmiger.
Der Administrator führt die folgenden Schritte aus, um das System zu initialisieren.
  1. Initialisieren Sie das CBDC-System mit der API initializeCBDCToken.
  2. Registrieren Sie Organisationen mit der API registerOrg.
  3. Erstellen Sie Accounts mit der API createAccount.
  4. Verknüpfen Sie das Token mit der associateTokenToAccount-API mit Accounts.
  5. Weisen Sie den Ersteller, die Notarrolle dem Zentralbankgenehmiger und die Brennerrolle dem Retirer mit der API addRole zu.
Nach der Initialisierung des Systems führt ein typischer Prozessfluss diese grundlegenden Schritte aus.
  1. Münzwährung.
    1. Der Tokenersteller verwendet die API requestMint, um eine Anforderung an Mint-Einzahlungstoken weiterzuleiten.
    2. Der Zentralbankgenehmiger verwendet die API approveMint, um die Mint-Anforderung zu prüfen und zu genehmigen. Die Token werden dem Konto des Erstellers gutgeschrieben. Alternativ kann der Zentralbankgenehmiger die Anforderung mit der API rejectMint ablehnen.
  2. Token an den Aussteller übertragen.
    • Der Ersteller verwendet die transferTokens-API-Sendetoken an den Aussteller.
  3. Übertragen Sie Token an Finanzbeamte.
    1. Der Emittent verwendet die API holdTokens, um Token an einen Finanzinstitutsbeauftragten zu senden.
    2. Der Zentralbankgenehmiger verwendet die APIs executeHoldTokensSender und executeHoldTokensReceiver als Teil eines zweiphasigen Commits, um die Übertragungsanforderung zu validieren und zu genehmigen. Alternativ kann der Zentralbankgenehmiger die Übertragung mit der API releaseHold ablehnen.
  4. Geben Sie Benutzern Token aus.
    1. Der Finanzinstitutsbeauftragte verwendet die API holdTokens, um Token an einen Finanzinstitutsbenutzer zu senden.
    2. Der Genehmiger des Finanzinstituts verwendet die API executeHoldTokens, um die Transferanforderung zu validieren und zu genehmigen. Alternativ kann der Genehmiger des Finanzinstituts die API releaseHold verwenden, um den Transfer abzulehnen.
  5. Token brennen.
    1. Der Aussteller verwendet die API transferTokens, um Token an den Retirer zu übertragen.
    2. Der Retirer verwendet die API requestBurn, um eine Burn-Anforderung an den Zentralbankgenehmiger zu senden.
    3. Der Zentralbankgenehmiger verwendet die API approveBurn, um die Burn-Anforderung zu genehmigen, und die Token werden zerstört. Alternativ kann der Zentralbankgenehmiger die Anforderung mit der API rejectBurn ablehnen.
  6. Token-Saldo prüfen.
    • Benutzer können die API getAccountBalance verwenden, um die Gesamtzahl der gesperrten Währungen abzurufen.