Eine CBDC-Transaktion kann als gültig bestätigt werden, ohne dass jemand außerhalb der Beteiligten den Betrag kennt.
Das ist die Art von System, die @SignOfficial derzeit mit permissioned Implementierungen auf der Grundlage von Hyperledger Fabric testet.
Das klingt vernünftig. Aber es ist auch der Moment, in dem alles kompliziert wird.
Es geht nicht darum, alles zu verbergen. Sondern nur das, was offenbart werden muss.
Theoretisch ist eine CBDC immer zwischen zwei Extremen gefangen. Auf der einen Seite ist sie so transparent wie RTGS, wo die Banken alles sehen. Auf der anderen Seite ist sie so privat wie Bargeld, wo niemand etwas sieht außer den Beteiligten. Die meisten Systeme wählen einen Punkt dazwischen.
Sign geht auf eine andere Weise vor. Sie trennen sich in mehrere Räume.
wCBDC für Interbank. rCBDC für Benutzer. Eine eigene Schicht für Regulierungsbehörden. Jeder Namespace hat eine eigene Endorsement-Richtlinie; jede Transaktion muss gemäß unterschiedlichen Regeln bestätigt werden.
Privatsphäre ist nicht mehr eine Eigenschaft, die an Transaktionen gebunden ist. Sie ist eine Folge davon, in welchem Raum diese Transaktion stattfindet. Im Wholesale-Bereich ist das Maß an Transparenz fast RTGS. Im Retail-Bereich sind die Informationen nur für den Absender, den Empfänger und die zugewiesene Aufsichtsbehörde sichtbar.
Es gibt keine allgemeine Einstellung. Dieser Ansatz ermöglicht es, dass jede Art von Transaktion ein unterschiedliches Maß an Privatsphäre von der Architektur her hat.
Die zweite Schicht ist die Verarbeitung von Transaktionen. Das System verwendet das Hyperledger Fabric Token SDK mit einem UTXO-Modell. Jede Transaktion verbraucht einen alten Output und erstellt einen neuen Output. In Kombination mit Zero-Knowledge-Proofs (ZKP) beweist das System nur das Notwendige und offenbart nicht die gesamten Daten.
Ein Beispiel: Eine Einzelhandels-Transaktion kann beweisen, dass sie nicht über das Limit von 10.000 USD hinausgeht, ohne den genauen Betrag offenzulegen, oder beweisen, dass der Empfänger zur berechtigten Gruppe gehört, ohne die gesamte Identität preiszugeben. Die Überprüfung findet dennoch statt, aber die Daten werden nicht vollständig offenbart.
Solche permissioned Implementierungen zielen auf einen Durchsatz von ~100.000 Transaktionen pro Sekunde ab, geeignet für das Interbanken-Umfeld oder nationale Implementierungen. Bei diesem Maß ist es fast unmöglich, "alles zu verbergen und bei Bedarf zu entschlüsseln". Selektive Offenlegung wird zwingend erforderlich.
Aber Risiken beginnen aufzutreten. Privatsphäre gemäß Namespace wirft die Frage auf: Wer entscheidet, zu welchem Namespace Sie gehören. Wenn eine Transaktion falsch klassifiziert wird, ist auch das Maß an Privatsphäre falsch. Wenn die Endorsement-Richtlinie abweicht, weicht auch das Bestätigungsrecht ab. Dies ist kein Fehler der Kryptographie, sondern ein Fehler der Governance.
Eine tiefere Schicht: Regulierungsbehörden stehen nicht mehr außen vor. Sie erhalten Zugang auf Architektur-Ebene, was für Compliance, Audits und Geldpolitik notwendig ist. Aber die Annahme, dass der Zugriff immer für den richtigen Zweck verwendet wird, ist ein tatsächliches Risiko.
Dieses System funktioniert, wenn drei Dinge im Gleichgewicht sind: der Namespace ausreichend klar getrennt ist, die Richtlinie ausreichend streng ist und der Zugriff korrekt kontrolliert wird. Es beginnt, Probleme zu haben, wenn eines der drei aus dem Gleichgewicht gerät: vermischter Namespace, lockere Richtlinien, unerwartete Erweiterung des Zugriffs.
Privatsphäre im Sign Protocol ist kein einfacher Schalter. Es ist das Ergebnis der Art und Weise, wie das System definiert: Wer sind Sie, wo handeln Sie und nach welcher Regel handeln Sie. Nicht jede Transaktion ist privat, nicht jede Transaktion ist transparent. Jede Transaktion wird mit einem bereits definierten Maß an Privatsphäre generiert.
Es funktioniert, wenn die Architektur die Grenzen zwischen den Schichten klar hält.
Es versagt, wenn diese Grenze verletzt wird.
Das ist auch der Grund, warum ich weiterhin verfolge, wie solche Designs in die praktische Umsetzung gelangen, wo Fehler nicht aus dem Code kommen, sondern aus der Art und Weise, wie Menschen das System definieren und betreiben.
$SIGN #SignDigitalSovereignInfra
