#dusk $DUSK Gestern Abend, als ich in den Dusk-Dokumenten nachgeschaut habe, wurde mir der Rücken ein wenig kalt.
EVM-kompatibel – klingt erst mal großartig. Aber bei genauerem Blick auf die Exit-Mechanik zog es mir den Bauch zusammen: Kein „Abzocke“-Modell, aber die Architektur ist zu tief.
Anwendungen laufen auf der EVM-Seite, und L1 übernimmt das Abrechnungs- und Verifikations-Handling. Für den Exit gibt es drei Schritte: auf den Output-Vorschlag warten, auf die Einreichung der Beweise warten und darauf, dass das Disput-Fenster abläuft. Bei der Cross-Layer-Statusverifikation muss jede Ebene Gas bereitstellen. Das ist keine doppelte Abrechnung – es ist so, als müsste man für jede einzelne Tür ein eigenes Ticket kaufen. Sobald bei irgendeinem Schritt das Guthaben nicht ausreicht, bleiben die Assets direkt auf halbem Weg stecken – rein oder raus, beides wird schwierig.
Am beunruhigendsten ist für mich: Im Moment handelt es sich bei den Daten allesamt um Testnetze.
Wenn der Prozess nur zeigt, dass der Code „läuft“, heißt das noch lange nicht, dass es auf dem Mainnet von @Dusk auch wirklich stabil funktioniert. Das Validierer-Set, die Häufigkeit von Disputes und die Gas-Preis-Schwankungen – jeder dieser Faktoren kann aus „exitfähig“ plötzlich „nicht wieder raus“ machen. Die Projektseite sagt, dass ein Exit unterstützt wird, aber sie hat nie öffentlich gemacht, wie lange ein Exit im Mainnet typischerweise dauert, und auch keine Details zur Fehlerbehebungs-/Recovery-Mechanik veröffentlicht. Wenn wirklich etwas schiefgeht – wer holt dann deine Assets zurück? In den Dokumenten steht dazu nichts.
Reife Cross-Layer-Brücken sind nie nur „weniger Klicks“, sondern dafür sorgen, dass Nutzer jede einzelne Stufe verstehen: Was passiert, wohin die Assets gehen und warum man warten muss. Bei der DuskEVM ist die technische Schichtung zwar logisch klar, aber für Nutzer wirkt es wie eine Blackbox: einmal Exit klicken und dann ist da diese lange Wartezeit – auf dem Bildschirm nur ein paar unverständliche „pending“-Status.
Dieser Branche mangelt es nie an technischen Visionen – es mangelt daran, was man tut, wenn es irgendwo schiefgeht. Wenn der Protokolltext nicht einmal eindeutig erklärt, wie ein Failure-Recovery funktioniert, worauf setzt du dann: auf Technik oder auf Glück?
EVM-kompatibel – klingt erst mal großartig. Aber bei genauerem Blick auf die Exit-Mechanik zog es mir den Bauch zusammen: Kein „Abzocke“-Modell, aber die Architektur ist zu tief.
Anwendungen laufen auf der EVM-Seite, und L1 übernimmt das Abrechnungs- und Verifikations-Handling. Für den Exit gibt es drei Schritte: auf den Output-Vorschlag warten, auf die Einreichung der Beweise warten und darauf, dass das Disput-Fenster abläuft. Bei der Cross-Layer-Statusverifikation muss jede Ebene Gas bereitstellen. Das ist keine doppelte Abrechnung – es ist so, als müsste man für jede einzelne Tür ein eigenes Ticket kaufen. Sobald bei irgendeinem Schritt das Guthaben nicht ausreicht, bleiben die Assets direkt auf halbem Weg stecken – rein oder raus, beides wird schwierig.
Am beunruhigendsten ist für mich: Im Moment handelt es sich bei den Daten allesamt um Testnetze.
Wenn der Prozess nur zeigt, dass der Code „läuft“, heißt das noch lange nicht, dass es auf dem Mainnet von @Dusk auch wirklich stabil funktioniert. Das Validierer-Set, die Häufigkeit von Disputes und die Gas-Preis-Schwankungen – jeder dieser Faktoren kann aus „exitfähig“ plötzlich „nicht wieder raus“ machen. Die Projektseite sagt, dass ein Exit unterstützt wird, aber sie hat nie öffentlich gemacht, wie lange ein Exit im Mainnet typischerweise dauert, und auch keine Details zur Fehlerbehebungs-/Recovery-Mechanik veröffentlicht. Wenn wirklich etwas schiefgeht – wer holt dann deine Assets zurück? In den Dokumenten steht dazu nichts.
Reife Cross-Layer-Brücken sind nie nur „weniger Klicks“, sondern dafür sorgen, dass Nutzer jede einzelne Stufe verstehen: Was passiert, wohin die Assets gehen und warum man warten muss. Bei der DuskEVM ist die technische Schichtung zwar logisch klar, aber für Nutzer wirkt es wie eine Blackbox: einmal Exit klicken und dann ist da diese lange Wartezeit – auf dem Bildschirm nur ein paar unverständliche „pending“-Status.
Dieser Branche mangelt es nie an technischen Visionen – es mangelt daran, was man tut, wenn es irgendwo schiefgeht. Wenn der Protokolltext nicht einmal eindeutig erklärt, wie ein Failure-Recovery funktioniert, worauf setzt du dann: auf Technik oder auf Glück?
