Ich sitze mit einer Frage: Die Dokumentation von Dusk beantwortet das nicht direkt mit konkreten Zahlen — können zwei unterschiedliche Phoenix-Notizen jemals denselben Nullifier erzeugen.
Was ich genau bestätigen kann: Das eigene Phoenix-Repository von Dusk hält fest, dass der Nullifier so berechnet wird, dass ein externer Beobachter ihn nicht mehr darauf zurückführen kann, aus welcher Notiz er stammt. Jede Notiz wird in die Blätter eines Merkle-Baums der Notizen gehasht, und das Ausgeben (Spenden) erzeugt einen deterministischen Nullifier-Wert, der an die Daten dieser konkreten Notiz gebunden ist.
Das darunterliegende Hashing — sowohl in Dusk’ Merkle-Baumstruktur als auch in umfassendere kryptografische Operationen — läuft auf Poseidon, einer SNARK-freundlichen Hash-Funktion, die von Dusk’ eigenem Team speziell für kollisionsresistentes Hashing entworfen wurde, und zwar für das Hashing innerhalb von Zero-Knowledge-Schaltkreisen. Das ist kein generischer, von der Stange gekaufter Hash; er ist exakt für diese Art von ZK-nativem Commitment-Work gebaut.
Aber „kollisionsresistent“ ist nicht dasselbe wie „kollisionssicher“. Jede Hash-Funktion, einschließlich Poseidon, trägt eine theoretische (astronomisch kleine) Chance, dass zwei unterschiedliche Eingaben denselben Ausgabewert erzeugen — das ist die Natur des Hashings selbst und keine spezifische Schwäche von Dusk.
Was ich in den eigenen Unterlagen von Dusk nicht gefunden habe, ist eine veröffentlichte Kollisionswahrscheinlichkeits-Zahl, die speziell für ihre exakten Poseidon-Parameter gilt, oder eine Dokumentation eines eigenen Kollisions-Tests über die allgemeinen Sicherheitsannahmen hinaus, die Poseidon per Design mitbringt.
Falls jemand einen Audit-Report gesehen hat, der genau diese Eigenschaft für die Implementierung von Dusk abdeckt, würde ich ihn gern mit dem vergleichen, was öffentlich dokumentiert ist.
#dusk $DUSK @Dusk
Was ich genau bestätigen kann: Das eigene Phoenix-Repository von Dusk hält fest, dass der Nullifier so berechnet wird, dass ein externer Beobachter ihn nicht mehr darauf zurückführen kann, aus welcher Notiz er stammt. Jede Notiz wird in die Blätter eines Merkle-Baums der Notizen gehasht, und das Ausgeben (Spenden) erzeugt einen deterministischen Nullifier-Wert, der an die Daten dieser konkreten Notiz gebunden ist.
Das darunterliegende Hashing — sowohl in Dusk’ Merkle-Baumstruktur als auch in umfassendere kryptografische Operationen — läuft auf Poseidon, einer SNARK-freundlichen Hash-Funktion, die von Dusk’ eigenem Team speziell für kollisionsresistentes Hashing entworfen wurde, und zwar für das Hashing innerhalb von Zero-Knowledge-Schaltkreisen. Das ist kein generischer, von der Stange gekaufter Hash; er ist exakt für diese Art von ZK-nativem Commitment-Work gebaut.
Aber „kollisionsresistent“ ist nicht dasselbe wie „kollisionssicher“. Jede Hash-Funktion, einschließlich Poseidon, trägt eine theoretische (astronomisch kleine) Chance, dass zwei unterschiedliche Eingaben denselben Ausgabewert erzeugen — das ist die Natur des Hashings selbst und keine spezifische Schwäche von Dusk.
Was ich in den eigenen Unterlagen von Dusk nicht gefunden habe, ist eine veröffentlichte Kollisionswahrscheinlichkeits-Zahl, die speziell für ihre exakten Poseidon-Parameter gilt, oder eine Dokumentation eines eigenen Kollisions-Tests über die allgemeinen Sicherheitsannahmen hinaus, die Poseidon per Design mitbringt.
Falls jemand einen Audit-Report gesehen hat, der genau diese Eigenschaft für die Implementierung von Dusk abdeckt, würde ich ihn gern mit dem vergleichen, was öffentlich dokumentiert ist.
#dusk $DUSK @Dusk