Ich habe jetzt die größte Frage zu @Dusk : nicht, ob es technisch umsetzbar ist, sondern ob der normale Nutzer es überhaupt wagen würde, es zu verwenden.
Kürzlich habe ich den praktischen Ablauf noch einmal Schritt für Schritt durchgegangen. Auf der Engineering-Seite wird tatsächlich ziemlich regelmäßig aktualisiert, aber wenn es dann wirklich beim Nutzer ankommt, ist die Fehlertoleranz bei den grundlegendsten Aktionen wie Migration, Cross-Chain und Staking immer noch etwas niedrig.
Zum Beispiel: ERC20/BEP20 DUSK auf das Mainnet migrieren bedeutet nicht, dass man einfach nur einmal klickt und fertig ist. Zuerst braucht man ein Approve, dann ein Execute. Fehlt ein Schritt, zählt das nicht als abgeschlossene Migration. Die typische Wartezeit, die die offizielle Anleitung vorgibt, liegt zudem immer noch bei etwa 1 Stunde. Außerdem muss man vorher ETH/BNB bereithalten, um Gas zu bezahlen.
Was mich aber noch mehr beschäftigt, ist die Umstellung von Mainnet auf BSC. Die Empfangsadresse muss über ein memo angegeben werden. In der offiziellen Dokumentation wird direkt darauf hingewiesen: Wenn memo fehlt oder ungültig ist, kann die Transaktion möglicherweise nicht automatisch verarbeitet werden, und es besteht sogar das Risiko, dass Vermögenswerte nicht wiederhergestellt werden können.
Für alte Spieler klingt das vielleicht nach „wenn man es doch nur richtig liest, ist es doch kein Problem“, aber wenn ein Produkt sich an eine größere Nutzergruppe richtet, sollte man die Verantwortung für das Vermeiden von Bedienfehlern nicht dauerhaft dem Nutzer überlassen.
Beim Staking ist es ähnlich. Direkt mindestens 1000 DUSK zu staken reicht nicht aus – man muss auch selbst einen provisioner betreiben. Der Node muss online bleiben, synchron und in der richtigen Version. Außerdem dauert die Aktivierung noch einmal etwa 6 bis 12 Stunden. Technisch ist daran nichts auszusetzen, aber aus Sicht einer Person, die einfach nur DUSK hält, ist das eindeutig keine besonders leichte Bedienung.
Und dieses Jahr im Januar ist zudem der Bridge-Dienst angegriffen worden, wobei eine Signatur-Wallet kompromittiert wurde. Auch wenn die offizielle Stelle später eindeutig sagte, dass es kein Schwachstellenproblem im Dusk-Konsenslayer sei, wird ein normaler Nutzer nicht zwischen „Sicherheit auf Protokoll-Ebene“ und „Sicherheit auf Service-Ebene“ unterscheiden. Er interessiert sich nur für eine Sache: Wenn ich bei der Geldoperation einen Fehler mache oder das System ein Problem hat – kann ich mein Geld dann überhaupt wieder zurückbekommen?
Daher finde ich im Moment eher, dass Dusk in der nächsten Phase nicht nur die Performance auf der Basisebene nachbessern sollte.
Sondern dass „nicht falsch ausfüllen, Status verständlich sehen, wenn etwas schiefgeht, gibt es Hilfe“ wirklich als Standard-Produkt-Erlebnis umgesetzt wird.
Technische Komplexität kann sein, aber die Nutzererfahrung darf nicht komplex sein.
#dusk $DUSK @Dusk
Kürzlich habe ich den praktischen Ablauf noch einmal Schritt für Schritt durchgegangen. Auf der Engineering-Seite wird tatsächlich ziemlich regelmäßig aktualisiert, aber wenn es dann wirklich beim Nutzer ankommt, ist die Fehlertoleranz bei den grundlegendsten Aktionen wie Migration, Cross-Chain und Staking immer noch etwas niedrig.
Zum Beispiel: ERC20/BEP20 DUSK auf das Mainnet migrieren bedeutet nicht, dass man einfach nur einmal klickt und fertig ist. Zuerst braucht man ein Approve, dann ein Execute. Fehlt ein Schritt, zählt das nicht als abgeschlossene Migration. Die typische Wartezeit, die die offizielle Anleitung vorgibt, liegt zudem immer noch bei etwa 1 Stunde. Außerdem muss man vorher ETH/BNB bereithalten, um Gas zu bezahlen.
Was mich aber noch mehr beschäftigt, ist die Umstellung von Mainnet auf BSC. Die Empfangsadresse muss über ein memo angegeben werden. In der offiziellen Dokumentation wird direkt darauf hingewiesen: Wenn memo fehlt oder ungültig ist, kann die Transaktion möglicherweise nicht automatisch verarbeitet werden, und es besteht sogar das Risiko, dass Vermögenswerte nicht wiederhergestellt werden können.
Für alte Spieler klingt das vielleicht nach „wenn man es doch nur richtig liest, ist es doch kein Problem“, aber wenn ein Produkt sich an eine größere Nutzergruppe richtet, sollte man die Verantwortung für das Vermeiden von Bedienfehlern nicht dauerhaft dem Nutzer überlassen.
Beim Staking ist es ähnlich. Direkt mindestens 1000 DUSK zu staken reicht nicht aus – man muss auch selbst einen provisioner betreiben. Der Node muss online bleiben, synchron und in der richtigen Version. Außerdem dauert die Aktivierung noch einmal etwa 6 bis 12 Stunden. Technisch ist daran nichts auszusetzen, aber aus Sicht einer Person, die einfach nur DUSK hält, ist das eindeutig keine besonders leichte Bedienung.
Und dieses Jahr im Januar ist zudem der Bridge-Dienst angegriffen worden, wobei eine Signatur-Wallet kompromittiert wurde. Auch wenn die offizielle Stelle später eindeutig sagte, dass es kein Schwachstellenproblem im Dusk-Konsenslayer sei, wird ein normaler Nutzer nicht zwischen „Sicherheit auf Protokoll-Ebene“ und „Sicherheit auf Service-Ebene“ unterscheiden. Er interessiert sich nur für eine Sache: Wenn ich bei der Geldoperation einen Fehler mache oder das System ein Problem hat – kann ich mein Geld dann überhaupt wieder zurückbekommen?
Daher finde ich im Moment eher, dass Dusk in der nächsten Phase nicht nur die Performance auf der Basisebene nachbessern sollte.
Sondern dass „nicht falsch ausfüllen, Status verständlich sehen, wenn etwas schiefgeht, gibt es Hilfe“ wirklich als Standard-Produkt-Erlebnis umgesetzt wird.
Technische Komplexität kann sein, aber die Nutzererfahrung darf nicht komplex sein.
#dusk $DUSK @Dusk