Ich habe die Anleitung zu der neuen Wallet @Dusk mit den Dusk-Connect-Infos abgeglichen und erst dadurch verstanden: Sie liefern nicht „noch eine weitere Wallet-Haut“, sondern die Verbindungs-/Verbindungsschicht, die dem dApp-System bisher gefehlt hat. Die alte Web Wallet konnte zwar einzeln Überweisungen tätigen und staken, aber die Anwendung konnte die Wallet nicht über eine einheitliche Schnittstelle entdecken, Konten anfordern, signieren und Transaktionen anstoßen. Entwickler mussten daher um jede einzelne Wallet herum separat anpassen.
Dusk Connect macht im Grunde das Gleiche wie das Standardisieren dieses „Klebers“: Die Wallet-Erkennung folgt dem Gedanken von EIP-6963, das RPC verarbeitet Konten, Signaturen, Transaktionen und Netzwerk-Anfragen über Namensräume, und es gibt auch Konsistenztests für Wallet-Implementierer. Die neue offizielle First-Party-Wallet setzt ab Anfang auf diese Provider-Schnittstelle und deckt dabei Browser-Extensions, Desktop und Mobile ab; öffentliche und vertrauliche Transfers, shield/unshield, Staking, Rewards abholen sowie DRC-20 und DRC-721 werden auf demselben Interaktionspfad gebündelt.
Der Bereich, der in Werbetexten am leichtesten in die Irre führt, ist die Gleichsetzung von „Repository ist offen“ mit „Produkt ist reif“. Offiziell ist das aktuell weiterhin als developer preview eingeordnet. Die lokalen Schlüssel werden gespeichert, die Extension-seitige Verschlüsselung nutzt PBKDF2 und AES-GCM, nativer Endpunkt Stronghold und Argon2 – das sind die richtigen sicherheitsrelevanten Grundlagen, aber wie sich die Erfahrung tatsächlich anfühlt, entscheiden andere Dinge: Wiederherstellung nach Abbruch der Verbindung, Hinweis-/Berechtigungs-Prompt, Feedback bei fehlgeschlagenen Transaktionen und Konsistenz des Status über mehrere Endgeräte hinweg.
Das ist auch der Grund, warum ich mir zuletzt die #dusk nicht nur wegen der Protokoll-Begriffe genauer angesehen habe: Ohne eine stabile Wallet-Verbindungsschicht sind selbst die schönsten Privacy-Contracts am Ende nur eine Entwickler-Demo. Die nächste Stufe für $DUSK ist nicht noch ein Screenshot einer Oberfläche, sondern dass eine Drittanbieter-dApp wirklich nahtlos andocken kann. Woran würdet ihr die Nutzbarkeit einer neuen Wallet zuerst festmachen: an der Funktionsübersicht oder daran, wie sie sich in Fehlerszenarien verhält?
Dusk Connect macht im Grunde das Gleiche wie das Standardisieren dieses „Klebers“: Die Wallet-Erkennung folgt dem Gedanken von EIP-6963, das RPC verarbeitet Konten, Signaturen, Transaktionen und Netzwerk-Anfragen über Namensräume, und es gibt auch Konsistenztests für Wallet-Implementierer. Die neue offizielle First-Party-Wallet setzt ab Anfang auf diese Provider-Schnittstelle und deckt dabei Browser-Extensions, Desktop und Mobile ab; öffentliche und vertrauliche Transfers, shield/unshield, Staking, Rewards abholen sowie DRC-20 und DRC-721 werden auf demselben Interaktionspfad gebündelt.
Der Bereich, der in Werbetexten am leichtesten in die Irre führt, ist die Gleichsetzung von „Repository ist offen“ mit „Produkt ist reif“. Offiziell ist das aktuell weiterhin als developer preview eingeordnet. Die lokalen Schlüssel werden gespeichert, die Extension-seitige Verschlüsselung nutzt PBKDF2 und AES-GCM, nativer Endpunkt Stronghold und Argon2 – das sind die richtigen sicherheitsrelevanten Grundlagen, aber wie sich die Erfahrung tatsächlich anfühlt, entscheiden andere Dinge: Wiederherstellung nach Abbruch der Verbindung, Hinweis-/Berechtigungs-Prompt, Feedback bei fehlgeschlagenen Transaktionen und Konsistenz des Status über mehrere Endgeräte hinweg.
Das ist auch der Grund, warum ich mir zuletzt die #dusk nicht nur wegen der Protokoll-Begriffe genauer angesehen habe: Ohne eine stabile Wallet-Verbindungsschicht sind selbst die schönsten Privacy-Contracts am Ende nur eine Entwickler-Demo. Die nächste Stufe für $DUSK ist nicht noch ein Screenshot einer Oberfläche, sondern dass eine Drittanbieter-dApp wirklich nahtlos andocken kann. Woran würdet ihr die Nutzbarkeit einer neuen Wallet zuerst festmachen: an der Funktionsübersicht oder daran, wie sie sich in Fehlerszenarien verhält?
