Das Detail im Dusk-Style, das mich zweimal hinschauen ließ, ist nicht der ZK-Stack — sondern das, was die Wallet tut, wenn sie nicht weiß, ob eine geschützte Transaktion erfolgreich war.
In Dusk Wallet v0.1.0 erhielten Phoenix-Transaktionen ein Tracking für „pending-nullifier reservation“. In ihrem Changelog steht, dass diese Reservierungen nicht automatisch freigegeben werden, nachdem ein Watcher-Timeout eintritt, bei einem unbekannten Status, bei einem entfernten Status oder bei einer einzelnen fehlenden Mempool-Abfrage.
Warum gezielt Gelder gebunden lassen, wenn Unsicherheit besteht?
Weil Phoenix Notes ausgibt. Wenn die Wallet das gleiche nutzbare Note-Set sofort wiederverwenden würde, während die erste Transaktion möglicherweise noch landet, könnte sie widersprüchliche geschützte Spends aufbauen. Dusk hat außerdem einen Spend-Mutex hinzugefügt, um zu verhindern, dass parallele Phoenix-Sends gleichzeitig gegen dieselben Notes konstruiert werden.
Fakt: Das ist Sicherheitslogik auf Wallet-Seite, keine neue Konsensregel. Meine Interpretation: Dusk wählt eine konservative UX gegenüber einer optimistischen Verfügbarkeit des Kontostands, wenn der Transaktionsstatus unklar ist.
Dieser Trade-off ist wichtig. Privatsphäre-Systeme brauchen mehr als starke Kryptografie; die Verarbeitung des Wallet-Zustands muss auch dann sicher bleiben, wenn die Netzwerk-Sichtbarkeit unvollständig ist.
Für DUSK beobachte ich, ob zukünftige Wallet-Releases diese „unsichere“ Phase verkürzen können, ohne den Schutz zu schwächen. Wie aggressiv sollte eine Privacy-Wallet Gelder freischalten, wenn der Chain-Status unklar ist?
@Dusk $DUSK #dusk
In Dusk Wallet v0.1.0 erhielten Phoenix-Transaktionen ein Tracking für „pending-nullifier reservation“. In ihrem Changelog steht, dass diese Reservierungen nicht automatisch freigegeben werden, nachdem ein Watcher-Timeout eintritt, bei einem unbekannten Status, bei einem entfernten Status oder bei einer einzelnen fehlenden Mempool-Abfrage.
Warum gezielt Gelder gebunden lassen, wenn Unsicherheit besteht?
Weil Phoenix Notes ausgibt. Wenn die Wallet das gleiche nutzbare Note-Set sofort wiederverwenden würde, während die erste Transaktion möglicherweise noch landet, könnte sie widersprüchliche geschützte Spends aufbauen. Dusk hat außerdem einen Spend-Mutex hinzugefügt, um zu verhindern, dass parallele Phoenix-Sends gleichzeitig gegen dieselben Notes konstruiert werden.
Fakt: Das ist Sicherheitslogik auf Wallet-Seite, keine neue Konsensregel. Meine Interpretation: Dusk wählt eine konservative UX gegenüber einer optimistischen Verfügbarkeit des Kontostands, wenn der Transaktionsstatus unklar ist.
Dieser Trade-off ist wichtig. Privatsphäre-Systeme brauchen mehr als starke Kryptografie; die Verarbeitung des Wallet-Zustands muss auch dann sicher bleiben, wenn die Netzwerk-Sichtbarkeit unvollständig ist.
Für DUSK beobachte ich, ob zukünftige Wallet-Releases diese „unsichere“ Phase verkürzen können, ohne den Schutz zu schwächen. Wie aggressiv sollte eine Privacy-Wallet Gelder freischalten, wenn der Chain-Status unklar ist?
@Dusk $DUSK #dusk