Viele blicken bei Dusk nur auf die Privatsphäre, aber Privatsphäre ist für regulierte Finanzmärkte nur eine Eintrittskarte. Der echte Unterschied entsteht dadurch, ob Regeln in genau dem Moment, in dem ein Handel stattfindet, zwangsweise durchgesetzt werden – und nicht erst danach durch Anwälte, Verwahrer oder indem man bei der Börse noch einen zusätzlichen Schritt nachliefert. Die Architektur von Dusk lohnt sich mehr als bei den meisten Privacy-Public-Chains auseinanderzunehmen.
@Dusk
Phoenix nutzt Zero-Knowledge-Beweise, um Beträge und Adressen zu verschleiern, Moonlight behält transparente Kontopfad-Informationen, Citadel setzt auf selektive Offenlegung, und beim XSC-Contract werden Qualifikationsschwellen, Übertragungsbeschränkungen und Berichtspflichten direkt in die Logik des Transaktions-Workflows geschrieben. Im Vergleich zu ERC-3643, dem gängigen Standard für Tokenisierte Wertpapiere auf Ethereum: Man arbeitet dort mit Permissioned-Contracts plus Off-Chain-Identitäts-Orakeln, während Transaktionsdetails on-chain weiterhin öffentlich und analysierbar sind; Zcash versteckt nur Beträge, Tornado Cash wurde wegen fehlender compliant Identität regulatorisch zerschlagen. Dusk will beides gleichzeitig lösen: „unsichtbar sein“ und „kontrollierbar sein“.

Der echte Unterschied liegt in komplexen Produkten. Ein Vermögenswert mit Stimmrechten, Wiederherstellungsverfahren, mehrstufiger Offenlegung und einer Sperrfrist – eine einzelne Überweisung kann gleichzeitig über fünf oder mehr Zwänge auslösen: Ob der Inhaber noch im aktuellsten Whitelist-Status ist, ob nach der Übertragung die Zahl qualifizierter Investoren die Grenze überschreitet, ob die Sperrfrist bereits beendet ist, ob Regulierungsknoten den zugehörigen Hash entschlüsseln können und ob die Stimmrechte sich mit dem Bestand synchron einfrieren. PLONK-Beweise können diese Bedingungen belegen, ohne den Transaktionsgraphen offenzulegen, aber die Voraussetzung ist, dass der Contract-Status beim Lesen keine Race Conditions hat. PLONK braucht kein Trusted Setup und eignet sich für XSC-ähnliche Multi-Constraint-Zircuits; bei statusabhängigen Abläufen kann es jedoch, wenn Prioritäten nicht sauber sortiert wurden, zu „Privatsphäre durchschlüpft“ und „Compliance scheitert“ kommen – oder zwei Compliance-Module decken sich gegenseitig ungewollt.

Ein verifizierbares Beispiel: Ein europäisches KMU emittiert tokenisierte Schuldverschreibungen. Mit XSC wird festgelegt, dass nur Whitelist-Institutionen halten dürfen; wenn die Zahl der Inhaber 100 überschreitet, wird der Sekundärmarkt automatisch pausiert. Jede Überweisung muss zwingend einen Audit-Hash an den Regulierungsknoten senden. Solche Einschränkungen lassen sich nicht mit Frontend-Buttons „hinbekommen“ – sie müssen vom Beweis-Zircuits hart überprüft werden. Das Verkaufsargument von Dusk liegt genau hier: Compliance ist nicht erst ein nachträglicher Bericht, sondern eine Vorbedingung dafür, dass ein Handel überhaupt gepackt und verarbeitet werden kann.
$BTC
Wenn Unternehmensaktionen einen zwangsweisen Rückkauf auslösen, während zugleich ein Aktionär einen Antrag zur Wiederherstellung des gestohlenen Schlüssels stellt und die Regulierungsbehörde zudem eine sofortige Offenlegung verlangt: Kann Rusk VM die Abfolge der Aktionen klären, ohne dabei den Transaktionsgraphen offenzulegen? Ein Blueprints lässt sich nachvollziehbar entwerfen – schwierig wird es erst, wenn der Prozess durcheinandergerät: Können dann die Constraint-Systeme ihre Grenzen weiterhin einhalten.#dusk $DUSK