Ich dachte früher immer, wenn man in einer EVM-Wallet „Approve“ bestätigt, dann ist die DUSK-Migration schon zur Hälfte erledigt. Später habe ich die Mainnet-Migrationsanleitung von @Dusk gelesen und gemerkt, dass dahinter noch eine eigenständige Aktion steckt: Man muss zusätzlich „Execute migration“ auswählen und die zweite Transaktion bestätigen. Dieses Detail ist zwar klein, aber es ist sehr leicht, „Autorisierung“ mit „das Asset ist schon unterwegs“ zu verwechseln.
Diese zwei Transaktionen sind überhaupt nicht dasselbe. „Approve“ erlaubt lediglich, dass der Migrationsvertrag eine bestimmte Menge an ERC20- oder BEP20-DUSK verwenden darf; „Execute“ ist das, was die Token tatsächlich sperrt und die Migration erst richtig startet. Das Mainnet-Account wartet darauf, dass die „Execute“-Bestätigung erfolgt, bevor es in den Verarbeitungsprozess eintritt. Wer EVM kennt, hält das vielleicht für selbstverständlich. Aber wenn man zum ersten Mal eine Migration über Netzwerke hinweg macht und zwei Buttons sieht, kann das wirklich leicht durcheinander geraten.
Ich finde, das Problem liegt nicht darin, dass man einmal mehr eine Multi-Signature benötigt, sondern dass der Zwischenstatus zu leicht übersehen wird. Manche klicken nach dem „Approve“ einfach die Seite weg, kommen später zurück und sehen, dass sich der Dusk-Guthabenstand nicht verändert hat. Dann autorisieren sie möglicherweise doppelt oder sind direkt der Meinung, die Migration sei fehlgeschlagen. Was am Ende wirklich Geld kostet, sind das Gas des Nutzers, die Wartezeit und die Zeit fürs Debugging. Auf Produktseite wird häufig nur ein kalter Status wie „nicht abgeschlossen“ angezeigt.
Darum glaube ich nicht, dass der Dusk-Migrationsprozess mit dem einmaligen Bestätigen erledigt ist. @Dusk teilt heute die Autorisierung und das Sperren der Assets in zwei Schritte – die Grenze ist bereits klarer gezogen. Als Nächstes sollte man stärker daran arbeiten, „autorisiert, ausstehend, gesperrt, in Bearbeitung“ getrennt anzuzeigen. $DUSK will, dass normale Nutzer den Cross-Chain-Einstieg nutzen können. Es reicht nicht, dass die Migration nur erfolgreich ist – die Leute müssen auch wissen, an welcher Stelle ihres Ablaufs sie gerade stehen. #dusk
Diese zwei Transaktionen sind überhaupt nicht dasselbe. „Approve“ erlaubt lediglich, dass der Migrationsvertrag eine bestimmte Menge an ERC20- oder BEP20-DUSK verwenden darf; „Execute“ ist das, was die Token tatsächlich sperrt und die Migration erst richtig startet. Das Mainnet-Account wartet darauf, dass die „Execute“-Bestätigung erfolgt, bevor es in den Verarbeitungsprozess eintritt. Wer EVM kennt, hält das vielleicht für selbstverständlich. Aber wenn man zum ersten Mal eine Migration über Netzwerke hinweg macht und zwei Buttons sieht, kann das wirklich leicht durcheinander geraten.
Ich finde, das Problem liegt nicht darin, dass man einmal mehr eine Multi-Signature benötigt, sondern dass der Zwischenstatus zu leicht übersehen wird. Manche klicken nach dem „Approve“ einfach die Seite weg, kommen später zurück und sehen, dass sich der Dusk-Guthabenstand nicht verändert hat. Dann autorisieren sie möglicherweise doppelt oder sind direkt der Meinung, die Migration sei fehlgeschlagen. Was am Ende wirklich Geld kostet, sind das Gas des Nutzers, die Wartezeit und die Zeit fürs Debugging. Auf Produktseite wird häufig nur ein kalter Status wie „nicht abgeschlossen“ angezeigt.
Darum glaube ich nicht, dass der Dusk-Migrationsprozess mit dem einmaligen Bestätigen erledigt ist. @Dusk teilt heute die Autorisierung und das Sperren der Assets in zwei Schritte – die Grenze ist bereits klarer gezogen. Als Nächstes sollte man stärker daran arbeiten, „autorisiert, ausstehend, gesperrt, in Bearbeitung“ getrennt anzuzeigen. $DUSK will, dass normale Nutzer den Cross-Chain-Einstieg nutzen können. Es reicht nicht, dass die Migration nur erfolgreich ist – die Leute müssen auch wissen, an welcher Stelle ihres Ablaufs sie gerade stehen. #dusk
