Ich kann zwei Dusk-Wallets installieren und eine gültige DUSK-Übertragung veranlassen, die vom falschen Wallet ohne Kettenfehler ausgeht.
Das Risiko beginnt, bevor unterschrieben wird. Dusk-Wallet-Erkennung erfolgt ereignisbasiert, nicht singleton-basiert. Eine dApp sendet dusk:requestProvider, jedes kompatible Wallet kann mit dusk:announceProvider antworten, und jeder Provider trägt seine eigene stabile UUID sowie seinen eigenen Profilstatus.
Wenn ich nur providers[0] beibehalte und dusk_requestProfiles aufrufe, habe ich die Ankündigungsreihenfolge in eine Wallet-Auswahl umgewandelt. Die Transaktion kann trotzdem völlig gültig sein. Der falsche Provider öffnet die Freigabe, das falsche Profil liefert das Konto, und dusk_sendTransaction signiert aus genau diesem Wallet.
Darum würde ich niemals „ein Dusk-Provider existiert“ als ausreichend betrachten. Wenn mehr als ein Provider verfügbar ist, möchte ich, dass der Nutzer das Wallet anhand seiner angekündigten Identität auswählt, diese UUID speichert und dann das sichtbare Profil und das Konto an diesen ausgewählten Provider binde, bevor ich irgendeine Übertragungsfreigabe anzeige.
Die Folge ist kein fehlgeschlagener Transaktionsversuch. Es ist schlimmer, weil alles funktioniert.
Bei Dusk sagt mir die Provider-Erkennung, welche Wallets vorhanden sind. Sie sagt mir nicht, von welchem Wallet der Nutzer beabsichtigt auszugeben.
#dusk $DUSK @Dusk