Frag die meisten Menschen, die eine Privacy-Chain bewerten, ob sie privat ist, und sie setzen ein Häkchen: ja oder nein. Für Dusk ist das die falsche Frage, und Dusk’ eigene Ausarbeitung zu Hedger zeigt, warum.
Zedger, Dusk’ natives privacy-schonendes Protokoll, kann vollständige Anonymität liefern. Hedger, gebaut für DuskEVM, kann das nicht. Dusk sagt es ganz offen: Das EVM-Modell mit kontobasierten Accounts verhindert vollständige Anonymität, während Hedger die Transaktionsdetails mit homomorpher Verschlüsselung und Zero-Knowledge-Beweisen verschlüsselt, ohne jedoch dieselbe Garantie für vollständige Anonymität zu bieten.
Das ist kein Bug, den Dusk versteckt. Es ist der Zielkonflikt, den die Architektur ausdrücklich macht: EVM-Kompatibilität bedeutet eine andere Privacy-Garantie als Zedgers vollständige Anonymität.
So ändert sich das tatsächlich, wenn dieser Zielkonflikt eingegangen wird. Der entscheidende Unterschied liegt nicht nur darin, ob Transaktionsdetails verschlüsselt sind. Entscheidend ist die Anonymitätsgarantie. Nimm den Zedger-Pfad, dann ist vollständige Anonymität verfügbar. Nimm den EVM-kompatiblen Hedger-Pfad, und dieselbe Garantie gibt es nicht. Gleiche Marke, gleiches Wort „confidential“, aber darunter eine andere Garantie.
Das verändert, welche eigentliche Frage sich für alle stellt, die das bewerten. Nicht: „Unterstützt Dusk vertrauliche Transaktionen?“ Beide Pfade unterstützen private Transaktionsabläufe, aber sie liefern nicht dieselbe Anonymitätsgarantie. Die echte Frage ist, ob die Garantie, die ein reguliertes Asset erhält, tatsächlich zu dem passt, was sein Workflow im ersten Schritt braucht.
„Privacy, die Transaktionsdetails vertraulich hält, und Privacy, die vollständige Anonymität bietet, sind zwei verschiedene Garantien – selbst dann, wenn ein Projekt beides unter demselben Wort ausliefert.“
Was ich stattdessen sehen möchte: Welchen Privacy-Pfad eine regulierte Security tatsächlich innerhalb von Dusk Trade nutzt und welche Anforderungen dieser Workflow stellt, damit der Pfad verborgen bleiben muss.
#dusk $DUSK @Dusk
Zedger, Dusk’ natives privacy-schonendes Protokoll, kann vollständige Anonymität liefern. Hedger, gebaut für DuskEVM, kann das nicht. Dusk sagt es ganz offen: Das EVM-Modell mit kontobasierten Accounts verhindert vollständige Anonymität, während Hedger die Transaktionsdetails mit homomorpher Verschlüsselung und Zero-Knowledge-Beweisen verschlüsselt, ohne jedoch dieselbe Garantie für vollständige Anonymität zu bieten.
Das ist kein Bug, den Dusk versteckt. Es ist der Zielkonflikt, den die Architektur ausdrücklich macht: EVM-Kompatibilität bedeutet eine andere Privacy-Garantie als Zedgers vollständige Anonymität.
So ändert sich das tatsächlich, wenn dieser Zielkonflikt eingegangen wird. Der entscheidende Unterschied liegt nicht nur darin, ob Transaktionsdetails verschlüsselt sind. Entscheidend ist die Anonymitätsgarantie. Nimm den Zedger-Pfad, dann ist vollständige Anonymität verfügbar. Nimm den EVM-kompatiblen Hedger-Pfad, und dieselbe Garantie gibt es nicht. Gleiche Marke, gleiches Wort „confidential“, aber darunter eine andere Garantie.
Das verändert, welche eigentliche Frage sich für alle stellt, die das bewerten. Nicht: „Unterstützt Dusk vertrauliche Transaktionen?“ Beide Pfade unterstützen private Transaktionsabläufe, aber sie liefern nicht dieselbe Anonymitätsgarantie. Die echte Frage ist, ob die Garantie, die ein reguliertes Asset erhält, tatsächlich zu dem passt, was sein Workflow im ersten Schritt braucht.
„Privacy, die Transaktionsdetails vertraulich hält, und Privacy, die vollständige Anonymität bietet, sind zwei verschiedene Garantien – selbst dann, wenn ein Projekt beides unter demselben Wort ausliefert.“
Was ich stattdessen sehen möchte: Welchen Privacy-Pfad eine regulierte Security tatsächlich innerhalb von Dusk Trade nutzt und welche Anforderungen dieser Workflow stellt, damit der Pfad verborgen bleiben muss.
#dusk $DUSK @Dusk
