Datenschutzfreundliche Stablecoins lösen das Transparenzdilemma öffentlicher Blockchains für institutionelle und private Akteure. Das PLabs-Note-Protokoll implementiert einen privaten, mit USDC/USDT besicherten Stablecoin auf Ethereum, der über komplexe UTXO-/Note-Architekturen Solvenz, Nebenläufigkeit und regulatorische Konformität ohne zentralen Treuhänder gewährleistet. Der folgende Beitrag erläutert die Kernarchitektur, den Buy-Protocol-Ablauf, die Probleme bei gleichzeitigen On-Ramps sowie die getroffenen Design-Entscheidungen, die diese Risiken adressieren.

Grundlagen des PLabs-Note-Protokolls

Das Protokoll besteht aus drei zentralen Smart-Contracts:

• ReserveVault – hält die USDC/USDT-Reserven und zieht sie atomar ein, sobald ein gültiger Note-Pool-Beweis vorliegt.
• NotePool – verwaltet die UTXO-basierten Notes (inventar- und nutzer-Notes) in einem Merkle-Commitment-Tree mit einer Tiefe von 32 Ebenen, was einer maximalen Kapazität von ca. 4,29 Milliarden Blättern entspricht.
• Operator – besitzt den Spending-Key askP und koordiniert die Ausgabe von Nutzer-Notes (cmxout) aus dem unverteilten Protokoll-Inventar (paP).

Der Reserve-Deckungsgrad ist smart-contract-geprüft ≥ 100 %, sodass jederzeit ein 1:1-Reserveverhältnis zwischen ERC-20-Reserven und den im Umlauf befindlichen ZK-Notes besteht (Slack ≥ 0).

Buy-Protocol: Vom unverteilten Inventar zur Nutzer-Note

Der Kaufprozess (Buy Protocol) funktioniert über eine Off-Chain-Koordination zwischen drei Akteuren:

1. Der Nutzer übergibt USDC/USDT an eine On-Ramp (paU).
2. Die On-Ramp erzeugt eine neue Nutzer-Note (cmxout) und signiert das BuyAuth -Objekt.
3. Der Operator verwendet den Schlüssel askP, um die zugehörige Inventar-Note zu verbrauchen und kombiniert sie mit der neu erstellten Note zu einem atomaren Bundle.
4. Ein Relayer submittert das Bundle an den ReserveVault, der die USDC-Reserven einzieht und die Note ausgibt.

Durch die strikte Trennung zwischen unbesichertem Inventar (paP) und zirkulierenden Notes (cmxout) wird die 1:1-Reserveabsicherung atomar garantiert.

UTXO-Contention bei parallelen On-Ramps

Mehrere On-Ramps, die gleichzeitig auf denselben Operator zugreifen, können in einen Wettlauf um dieselbe Inventar-Note geraten. Das Protokoll verhindert Kollisionen durch zwei zentrale Mechanismen:

• Fragmentierte UTXO-Bestände (Denomination Buckets) – das Inventar wird in vorab definierte Größen-Tranchierungen aufgeteilt, sodass jede Kaufanfrage nur aus einem eigenen Bucket schöpft.
• Internes FIFO-Queueing auf Operator-Ebene – eingehende BuyAuth-Anfragen werden seriell abgearbeitet, wodurch atomare Bündel kollisionsfrei erzeugt werden.

Falls dennoch zwei Bundles dieselbe Note zu entwerten versuchen, führt der Nullifier-Check im NotePool zu einem sofortigen Revert auf-Chain, sodass Doppelverwendungen kryptografisch ausgeschlossen sind.

Wichtige Kennzahlen:

• Commitment-Tree-Tiefe: 32 Ebenen (ca. 4,29 Mrd. Blätter) – Quelle S1.
• Exit-Only-Schwelle: 50 % Belegung des NotePool-Baums, ab der das System in den reinen Rückgabemodus wechselt – Quelle S1.
• valueBalance-Invariant: 0 (Differenz zwischen vernichtetem und erzeugtem Nennwert ist stets null) – Quelle S1.

Technische Fragen zur Koordination und Contention

Frage 1: Wie wird verhindert, dass zwei Ramps gleichzeitig dieselbe Inventar-Note ausgeben?

Der Operator verwaltet das Inventar über serialisierte Warteschlangen oder getrennte UTXO-Tranchen (Denominations). Da nur der Operator den Ausgabeschlüssel askP besitzt, weist er jeder BuyAuth -Anfrage eine eindeutige, ungespendete Note zu, bevor das Bündel an den Relayer geht.

Frage 2: Was passiert, wenn der Operator offline geht, nachdem der Nutzer gezahlt hat?

Solange die BuyAuth -Frist läuft, bleibt die Gutschrift verzögert; nach Ablauf verfällt die Signatur ungenutzt. Da der ReserveVault die USDC erst atomar bei gültigem NotePool-Beweis einzieht, verliert der Zahler bei Nicht-Ausführung keine Reserven.

Der Platzierungshinweis wird direkt nach diesen beiden Fragen eingefügt:

Direkt im Anschluss an die zwei technischen Fragen zur Koordination und Contention am Ende des Entwurfs einfügen.

Verfügbarkeitsrisiko des Operators und Threshold-Signing (t-von-n MPC) für den Spending-Key askP ausgestattet. Statt einer reinen Batch-Vorbautorisierung erfordert die Signatur einer konfigurierten Mehrheit der Operator-Instanzen, wodurch die Verfügbarkeit erhöht und das Risiko eines kompletten Ausfalls gemindert wird.

Die valueBalance-Invariant (Δ = 0) stellt sicher, dass bei jedem NotePool-Zustandsübergang die erzeugte und vernichtete Nennwert-Summe exakt übereinstimmen – ein zentraler Sicherheitsparameter, der Fehlbuchungen verhindert.

Regulatorische Konformität via Compliance-Freeze-Root

Um Sanktionen und Geldwäscherisiken zu begegnen, trennt das System Transaktionsanonymität von Sanktionskontrollen. Ein spezieller Compliance-Merkle-Root friert verdächtige Notes ein, ohne dass Administratoren Zugriff auf die gesperrten USDC-Reserven im ReserveVault erhalten. Dadurch bleibt die Privatsphäre erhalten, während regulatorische Anforderungen erfüllt werden.

Der Reserve-Deckungsgrad von ≥ 100 % garantiert, dass stets genügend USDC/USDT vorhanden sind, um alle zirkulierenden ZK-Notes zu decken. Der Smart-Contract prüft kontinuierlich das Verhältnis von Reserve-ERC20 zu zirkulierenden Notes (Slack ≥ 0).

DeFi-Komposition und weitere Risiken

Private Notes folgen keinem Standard-ERC-20-Interface. Interaktionen mit Lending- oder AMM-Pools erfordern ein temporäres Unshielding über Coordinator-Verträge. Dieses Vorgehen birgt Slippage- und Re-entrancy-Risiken, die nur durch atomare Unshielding-Adapter mitigiert werden können.

Ein weiterer Engpass entsteht durch die Latenz und Kosten der Zero-Knowledge-Beweisgenerierung. Die clientseitige Erstellung von ZK-SNARKs und die On-Chain-Verifikation auf Ethereum L1 limitieren den Durchsatz und erfordern zusätzliche Relayer-Gebühren.

Fazit

Das PLabs-Note-Protokoll demonstriert, wie private, USDC/USDT-besicherte Stablecoins auf Ethereum technisch realisiert werden können, ohne die Sicherheit der 1:1-Reserve zu gefährden. Durch fragmentierte UTXO-Bestände, FIFO-Queueing und optionales UTXO-Contention bei parallelen On-Ramps wirksam gelöst, während das Verfügbarkeitsrisiko des Operators durch dezentrale Signatur-Schemen minimiert wird. Die Einführung eines Compliance-Freeze-Roots verbindet Datenschutz mit regulatorischer Konformität, und die streng enforce-te valueBalance-Invariant garantiert korrekte Nennwert-Bilanzen. Trotz dieser Fortschritte bleiben Herausforderungen bei DeFi-Komposition und Zero-Knowledge-Beweis-Kosten bestehen, die weitere Forschung erfordern. Insgesamt bietet das Protokoll einen praktikablen Ansatz für institutionelle und private Akteure, die auf eine datenschutzfreundliche, aber regulatorisch einwandfreie Stablecoin-Lösung setzen.