Ich habe mir kürzlich die Bridging-Dokumentation von DuskEVM angesehen und dabei einen Hinweis bemerkt, der immer wieder betont wird.
Derzeit unterstützt das Bridging nur das Testnetz DUSK.
Das ist keine technische Einschränkung.
Es ist vielmehr so, dass die Veröffentlichung des Status, die Reife der Beweise und das Zeitfenster für Streitfälle noch Zeit zur Validierung benötigen.$BTC
Das bringt mich zu einer realistischeren Frage: Dass ein Testnetz durchläuft, heißt nicht, dass das Mainnet auch genutzt werden kann.
In der mehrschichtigen Architektur von @Dusk übernimmt DuskDS Konsens und Abwicklung, DuskEVM stellt mit OP Stack die EVM-Kompatibilität bereit, und zwischen beiden werden über das Bridging Nachrichten und Assets übertragen. Theoretisch können Entwickler Solidity-Verträge direkt auf DuskEVM deployen und sich mit vertrauten Toolchains schnell einarbeiten.
Aber das Bridging ist nicht sofort.
Einlagen müssen auf die Bestätigung durch DuskDS warten, Auszahlungen auf die Zustandsveröffentlichung nach L1, auf das Einreichen der Beweise und auf das Ende der Disput-Periode. Wenn eine DeFi-Anwendung schnellen, hochfrequenten Arbitrage- oder raschen Liquidationsbedarf hat, können diese Verzögerungen akzeptabel sein? Und wenn eine Cross-Layer-Nachricht in irgendeinem Schritt feststeckt: Wer springt als Backup ein, wie wird wiederhergestellt, und wem gehören die Verluste des Nutzers?
Noch entscheidender ist die Liquidität.
Im Testnetz kann man beliebig minten, aber im Mainnet hat jede einzelne $DUSK echte Kosten. Wenn bei der Inbetriebnahme von DuskEVM in der Bridge die Liquidität nicht ausreicht, ist es für Nutzer zwar leicht, einzuzahlen, aber schwierig, wieder herauszubekommen — oder wenn die Wartezeit für Abhebungen zu lang ist, selbst die beste Kompatibilität wird die Anwendung schwerlich halten können.
Ich habe mir den Fahrplan von #dusk angesehen: Die Audit-Zeit für die Bridging-Verträge und die Roadmap für den Mainnet-Deployment sind noch nicht klar genug. Das heißt nicht, dass die Technik nicht funktioniert — aber vom Test zur Produktion gibt es dazwischen noch mehrere Hürden: Betrieb, Monitoring, Fehlerbehandlung und das Lenken der Liquidität.
Darum frage ich bei der aktuellen Entwicklung von DuskEVM nicht nur: „Kann man Verträge deployen?“
Ich interessiere mich vielmehr für drei Umwandlungspunkte: den Anteil der Testnetz-Anwendungen, die in das Mainnet migrieren; die anfängliche Größe der Bridge-Liquidität und die Mechanismen zur Nachfüllung; sowie die tatsächliche Reaktionsgeschwindigkeit, wenn über Cross-Layer hinweg ein Ausnahmefall auftritt.
EVM-Kompatibilität senkt die Einstiegskosten — aber Entwickler und Nutzer zu halten, hängt davon ab, dass die Bridge zuverlässig ist, das Geld schnell fließt und jemand sich um Probleme kümmert.
Ist diese Distanz wirklich nur eine Frage der Zeit?
#dusk @Dusk $DUSK