Wenn Nutzer das falsche Netzwerk auswählen, sollte das Produkt dies so früh wie möglich unterbinden – nicht erst, nachdem die Signatur abgeschlossen ist und der Fehler gemeldet wird.
DuskEVM hat eine eindeutige Netzwerkidentität: Das Testnetz hat die Chain-ID 745, und andere Umgebungen haben jeweils unterschiedliche IDs. Für Entwickler ist das lediglich eine Konfigurationseinstellung, für normale Nutzer jedoch eine häufige Fehlerquelle. Möglicherweise ist er in der einen Sekunde noch auf einer anderen EVM-Kette unterwegs, und in der nächsten Sekunde klickt er in der Dusk-App auf „Einreichen“, während das Erscheinungsbild des Wallet-Pop-ups fast identisch ist.
Gute Produkte vergleichen die Chain-ID unmittelbar nach dem Auslesen des Wallets, schalten die Seite in einen nicht bedienbaren Zustand und teilen dem Nutzer klar mit, zu welchem Netzwerk er wechseln muss. Es sollte den Nutzer nicht erst Formulare ausfüllen, Tokens freigeben, eine ganze Reihe von Nachrichten signieren lassen und ihn dann am Ende mit einem „RPC Error“ wissen lassen: „Das Netzwerk stimmt nicht“. Je früher der Fehler abgefangen wird, desto geringer sind die Kosten.
Noch detaillierere Tests umfassen: Nutzer lehnen den Netzwerkwechsel ab, das Wallet erkennt das Netzwerk nicht, während des Wechsels wird das Konto geändert, und die Seite hat den Restbetrag des vorherigen Kontos aus dem Cache geladen. Die Anwendung muss auf Änderungen im Network und Account des Wallets reagieren und alte Angebote und alte Berechtigungen umgehend löschen. Andernfalls wirkt die Seite so, als würde sie normal weiterlaufen, obwohl geschäftlich bereits eine andere Person dran ist.
Die Dusk Connect mit der Nummer @Dusk erkennt kompatible Wallets und nimmt Statusänderungen wahr; $DUSK und #dusk . Auf Anwendungsebene muss das bedeuten: Diese Signale in sichere Interaktionen umzusetzen. Ich beurteile, ob ein Web3-Produkt reif ist, oft daran, wie es damit umgeht, wenn Nutzer sich nicht an die Standard-Skripte halten.
DuskEVM hat eine eindeutige Netzwerkidentität: Das Testnetz hat die Chain-ID 745, und andere Umgebungen haben jeweils unterschiedliche IDs. Für Entwickler ist das lediglich eine Konfigurationseinstellung, für normale Nutzer jedoch eine häufige Fehlerquelle. Möglicherweise ist er in der einen Sekunde noch auf einer anderen EVM-Kette unterwegs, und in der nächsten Sekunde klickt er in der Dusk-App auf „Einreichen“, während das Erscheinungsbild des Wallet-Pop-ups fast identisch ist.
Gute Produkte vergleichen die Chain-ID unmittelbar nach dem Auslesen des Wallets, schalten die Seite in einen nicht bedienbaren Zustand und teilen dem Nutzer klar mit, zu welchem Netzwerk er wechseln muss. Es sollte den Nutzer nicht erst Formulare ausfüllen, Tokens freigeben, eine ganze Reihe von Nachrichten signieren lassen und ihn dann am Ende mit einem „RPC Error“ wissen lassen: „Das Netzwerk stimmt nicht“. Je früher der Fehler abgefangen wird, desto geringer sind die Kosten.
Noch detaillierere Tests umfassen: Nutzer lehnen den Netzwerkwechsel ab, das Wallet erkennt das Netzwerk nicht, während des Wechsels wird das Konto geändert, und die Seite hat den Restbetrag des vorherigen Kontos aus dem Cache geladen. Die Anwendung muss auf Änderungen im Network und Account des Wallets reagieren und alte Angebote und alte Berechtigungen umgehend löschen. Andernfalls wirkt die Seite so, als würde sie normal weiterlaufen, obwohl geschäftlich bereits eine andere Person dran ist.
Die Dusk Connect mit der Nummer @Dusk erkennt kompatible Wallets und nimmt Statusänderungen wahr; $DUSK und #dusk . Auf Anwendungsebene muss das bedeuten: Diese Signale in sichere Interaktionen umzusetzen. Ich beurteile, ob ein Web3-Produkt reif ist, oft daran, wie es damit umgeht, wenn Nutzer sich nicht an die Standard-Skripte halten.