Ich wollte einen Teil meiner brachliegenden Ether-Assets rüber auf DuskEVM schieben und es mal ausprobieren. Letzte Nacht bin ich den Cross-Chain-Bridge-Prozess anhand der offiziellen Doku einmal durchgegangen und dokumentiere meine echten Eindrücke: Es war nicht so reibungslos, wie ich mir das vorgestellt hatte.
Der Prozess selbst ist nicht kompliziert – auf Ethereum wird eine Lock-Transaktion ausgelöst, man wartet die Bestätigung ab und holt dann auf DuskEVM die entsprechenden Assets ab. Diese Logik unterscheidet sich im Grunde nicht wesentlich von den meisten Cross-Chain-Bridges. Was mich wirklich hat warten lassen, war weniger die Bridge an sich als die Bestätigungszeit: Auf der Ethereum-Seite muss man erst auf genügend Blockbestätigungen warten, bevor die Freigabe erfolgt. Zusätzlich braucht auch DuskEVM mit seinem eigenen Finalitätsmechanismus Zeit, um Vertrauen aufzubauen. Wenn sich die Wartezeiten auf beiden Seiten addieren, ist das eben kein „einmal klicken und sofort ist das Geld da“-Gefühl.
Anfangs dachte ich, diese Wartezeit sei ein Mangel beim Erlebnis. Später habe ich aber verstanden, dass das die notwendige „Kosten“ sind: Cross-Chain-Bridges wurden in der Vergangenheit viel zu oft angegriffen oder ausgenutzt. Viele der Bridges, bei denen es schiefging, haben genau aus dem Wunsch nach Tempo ein zu aggressives Bestätigungs-/Finalitäts-Handling gewählt und damit Angreifern mehr Spielraum gegeben. Dusk hat sich entschieden, dass die Finalität auf beiden Seiten erst ausreichend „sitzt“, bevor freigegeben wird. Das ist zwar langsamer – aber zumindest ist diese Designidee eher Sicherheit vor Nutzererlebnis, nicht umgekehrt.
Erlebnis-seitig gibt es aber trotzdem Optimierungsmöglichkeiten: Während des Prozesses gab es keine besonders klaren Fortschrittsanzeigen. Nachdem ich die Transaktion angestoßen hatte, war ich eine Weile unsicher, ob ich weiter warten soll oder ob irgendwo ein Schritt feststeckt und ich erneut etwas machen muss. Dieses Ungewissheitsgefühl ist für Erstnutzer nicht besonders freundlich und lässt schnell zweifeln, ob man vielleicht etwas falsch bedient hat. Im Vergleich zu einigen ausgereiften Bridges gibt es hier noch Potenzial bei der Feedback-Mechanik.
Außerdem habe ich noch eine Frage, die ich nicht ganz durchdrungen habe: Nachdem die Assets über die Bridge gegangen sind – wie existieren sie dann auf DuskEVM genau? Als native gemappte Assets oder als verpackte Token? Diese Beziehung ist entscheidend dafür, wie die Rücktausch-/Rückzahlungslogik für meine Assets aussieht, falls diese Bridge in Zukunft doch mal ein Problem hat. In der Doku ist diese Stelle nicht sonderlich deutlich erklärt; man muss sich mehrere Ebenen tiefer durchlesen, um die Antwort zusammenzusetzen.
Was Cross-Chain-Bridges angeht, war meine Haltung bisher immer: Wenn es sich vermeiden lässt, dann lass es. Wenn es unvermeidbar ist, dann lieber etwas langsamer und dafür mit einem Design, das Sicherheit priorisiert. Nach diesem Praxistest hat Dusk auf jeden Fall die richtige Richtung eingeschlagen – bei den Detail-User-Experiences gibt es aber noch Feinschliff.
@Dusk_Foundation #dusk $DUSK
Der Prozess selbst ist nicht kompliziert – auf Ethereum wird eine Lock-Transaktion ausgelöst, man wartet die Bestätigung ab und holt dann auf DuskEVM die entsprechenden Assets ab. Diese Logik unterscheidet sich im Grunde nicht wesentlich von den meisten Cross-Chain-Bridges. Was mich wirklich hat warten lassen, war weniger die Bridge an sich als die Bestätigungszeit: Auf der Ethereum-Seite muss man erst auf genügend Blockbestätigungen warten, bevor die Freigabe erfolgt. Zusätzlich braucht auch DuskEVM mit seinem eigenen Finalitätsmechanismus Zeit, um Vertrauen aufzubauen. Wenn sich die Wartezeiten auf beiden Seiten addieren, ist das eben kein „einmal klicken und sofort ist das Geld da“-Gefühl.
Anfangs dachte ich, diese Wartezeit sei ein Mangel beim Erlebnis. Später habe ich aber verstanden, dass das die notwendige „Kosten“ sind: Cross-Chain-Bridges wurden in der Vergangenheit viel zu oft angegriffen oder ausgenutzt. Viele der Bridges, bei denen es schiefging, haben genau aus dem Wunsch nach Tempo ein zu aggressives Bestätigungs-/Finalitäts-Handling gewählt und damit Angreifern mehr Spielraum gegeben. Dusk hat sich entschieden, dass die Finalität auf beiden Seiten erst ausreichend „sitzt“, bevor freigegeben wird. Das ist zwar langsamer – aber zumindest ist diese Designidee eher Sicherheit vor Nutzererlebnis, nicht umgekehrt.
Erlebnis-seitig gibt es aber trotzdem Optimierungsmöglichkeiten: Während des Prozesses gab es keine besonders klaren Fortschrittsanzeigen. Nachdem ich die Transaktion angestoßen hatte, war ich eine Weile unsicher, ob ich weiter warten soll oder ob irgendwo ein Schritt feststeckt und ich erneut etwas machen muss. Dieses Ungewissheitsgefühl ist für Erstnutzer nicht besonders freundlich und lässt schnell zweifeln, ob man vielleicht etwas falsch bedient hat. Im Vergleich zu einigen ausgereiften Bridges gibt es hier noch Potenzial bei der Feedback-Mechanik.
Außerdem habe ich noch eine Frage, die ich nicht ganz durchdrungen habe: Nachdem die Assets über die Bridge gegangen sind – wie existieren sie dann auf DuskEVM genau? Als native gemappte Assets oder als verpackte Token? Diese Beziehung ist entscheidend dafür, wie die Rücktausch-/Rückzahlungslogik für meine Assets aussieht, falls diese Bridge in Zukunft doch mal ein Problem hat. In der Doku ist diese Stelle nicht sonderlich deutlich erklärt; man muss sich mehrere Ebenen tiefer durchlesen, um die Antwort zusammenzusetzen.
Was Cross-Chain-Bridges angeht, war meine Haltung bisher immer: Wenn es sich vermeiden lässt, dann lass es. Wenn es unvermeidbar ist, dann lieber etwas langsamer und dafür mit einem Design, das Sicherheit priorisiert. Nach diesem Praxistest hat Dusk auf jeden Fall die richtige Richtung eingeschlagen – bei den Detail-User-Experiences gibt es aber noch Feinschliff.
@Dusk_Foundation #dusk $DUSK