#dusk $DUSK @Dusk
Was ich an Dusk’ Datenschutzkonzept interessant finde, ist nicht nur, dass Notizen verborgen werden. Es geht darum, *wo* das Verbergen passiert und wie viele Annahmen gleichzeitig erfüllt sein müssen.
Phoenix nutzt Zusagen und einen Merkle-Baum, während Wert-Zusagen einen Verdunkelungsfaktor hinzufügen. Validatoren können die Konsistenz überprüfen, ohne den Betrag zu lernen. Versteckte Adressen erschweren außerdem das Verknüpfen von Empfängern.
Die Verschlüsselungsschicht ist der Bereich, den ich genauer betrachte. Aktuell legt Phoenix AES als symmetrischen Chiffre fest, während der Stack auch JubJub ElGamal und Poseidon umfasst. Dusk’ Poseidon-Bibliothek hat Verschlüsselungsfunktionen, aber zu sagen „Poseidon bietet Vertraulichkeit“ ist zu vereinfacht. Die Implementierung hat sich weiterentwickelt, und das ist relevant, wenn man die semantische Sicherheit beurteilt.
Meine eigentliche Frage ist, ob die Komposition als *ein* System nachgewiesen wurde. Eine Zusage kann einen Wert verbergen und Verschlüsselung kann Klartext verbergen—aber der Datenschutz kann dennoch scheitern, etwa durch Metadaten, fehlerhafte Schlüsselbehandlung, Nonce-Missbrauch, Adresskorrelation oder eine fehlerhafte Beziehungsprüfung im Beweis. Das habe ich schon einmal gesehen: Starke Bausteine machen nicht automatisch ein starkes Protokoll.
Poseidon ist für zk-freundliche Berechnungen gebaut, während AES für allgemeine Verschlüsselung ausgereift ist. Das kann die Performance verbessern, aber es macht die Abgrenzung zwischen Verschlüsseln, Zusagen und Beweisen wichtig.
Ich bin noch nicht bereit, der Konstruktion zu vertrauen, nur weil die Zutaten respektiert werden. Ich möchte ein formales Argument sehen, das zeigt, dass die Notizenverschlüsselung Werte und Identitäten verbirgt. Genau dort wird Dusk’ Datenschutzbehauptung zu etwas, das ich bewerten kann.
Was ich an Dusk’ Datenschutzkonzept interessant finde, ist nicht nur, dass Notizen verborgen werden. Es geht darum, *wo* das Verbergen passiert und wie viele Annahmen gleichzeitig erfüllt sein müssen.
Phoenix nutzt Zusagen und einen Merkle-Baum, während Wert-Zusagen einen Verdunkelungsfaktor hinzufügen. Validatoren können die Konsistenz überprüfen, ohne den Betrag zu lernen. Versteckte Adressen erschweren außerdem das Verknüpfen von Empfängern.
Die Verschlüsselungsschicht ist der Bereich, den ich genauer betrachte. Aktuell legt Phoenix AES als symmetrischen Chiffre fest, während der Stack auch JubJub ElGamal und Poseidon umfasst. Dusk’ Poseidon-Bibliothek hat Verschlüsselungsfunktionen, aber zu sagen „Poseidon bietet Vertraulichkeit“ ist zu vereinfacht. Die Implementierung hat sich weiterentwickelt, und das ist relevant, wenn man die semantische Sicherheit beurteilt.
Meine eigentliche Frage ist, ob die Komposition als *ein* System nachgewiesen wurde. Eine Zusage kann einen Wert verbergen und Verschlüsselung kann Klartext verbergen—aber der Datenschutz kann dennoch scheitern, etwa durch Metadaten, fehlerhafte Schlüsselbehandlung, Nonce-Missbrauch, Adresskorrelation oder eine fehlerhafte Beziehungsprüfung im Beweis. Das habe ich schon einmal gesehen: Starke Bausteine machen nicht automatisch ein starkes Protokoll.
Poseidon ist für zk-freundliche Berechnungen gebaut, während AES für allgemeine Verschlüsselung ausgereift ist. Das kann die Performance verbessern, aber es macht die Abgrenzung zwischen Verschlüsseln, Zusagen und Beweisen wichtig.
Ich bin noch nicht bereit, der Konstruktion zu vertrauen, nur weil die Zutaten respektiert werden. Ich möchte ein formales Argument sehen, das zeigt, dass die Notizenverschlüsselung Werte und Identitäten verbirgt. Genau dort wird Dusk’ Datenschutzbehauptung zu etwas, das ich bewerten kann.
