#dusk $DUSK Ich habe mich durch die Entwicklungdokumentation von Dusk gearbeitet – vom Einrichten der Umgebung bis zum Deployment eines einfachen Contracts. Fazit: Zwischen der „Abdeckungsrate“ und der „Nutzbarkeit“ der Doku liegt eine ganze Strecke.
DuskEVM ist mit Solidity kompatibel, theoretisch sollten Ethereum-Entwickler nahtlos migrieren können. Aber als ich die Doku Schritt für Schritt befolgt habe, lag der erste Stolperstein in der lokalen Testumgebung: Die RPC-Endpunkt-Stabilität des DuskEVM Testnet ist eher durchschnittlich; gelegentlich kommt es zu Timeouts. Der Faucet reagiert manchmal nicht, man muss ein paar Stunden warten, bis man Testcoins erhält. Das ist für Entwickler, die mit Ethereum vertraut sind, nicht zwangsläufig tödlich – aber es schreckt diejenigen ab, die nur „mal ausprobieren“ wollen.
Der zweite Stolperstein sind Dusk-spezifische Konzept-Zuordnungen. Ethereum-Entwickler sind an das Kontomodell, Gas-Schätzungen und den Lebenszyklus von Transaktionen gewöhnt – in Dusk muss man das alles neu verstehen. Zum Beispiel erfordert der Exit-Prozess über L1 und EVM drei Schritte; Status und Wartebedingungen unterscheiden sich in jedem Schritt von denen eines Ethereum-L2. Die Doku beschreibt das zwar, aber es fehlen Anleitungen zur Fehlerbehebung – wenn man an einer Stelle festhängt, bleibt Entwicklern nur, selbst in den Quellcode zu schauen oder im Discord nachzufragen.
Der dritte Stolperstein ist die Reife der Toolchain. Der Blockexplorer arbeitet an seiner Unterstützung für die EVM-Seite noch – bei Teilen der Contract-Verifikationsfunktionen ist der Zugriff nicht verfügbar. Auch die Stabilität der APIs für Event-Listening und Log-Abfragen ist nicht so zuverlässig wie bei ausgereiften Netzwerken. Diese Lücken in der Infrastruktur bedeuten, dass Entwickler beim Debugging mehr Zeit damit verbringen müssen, Tool-Probleme auszuschließen, statt sich auf die Business-Logik zu konzentrieren.
Ich sage nicht, dass die Entwickler-Experience von Dusk schlecht ist – für eine Kette, die sich noch schnell weiterentwickelt, gehören solche Punkte zu einer normalen Phase. Das Problem ist nur: Ökosystemwachstum hängt davon ab, dass Entwickler einsteigen. Und welche Kette Entwickler wählen, hängt oft nicht am Whitepaper, sondern daran, wie lange es dauert, bis der erste Demo-Run funktioniert. Wenn das Einrichten der Umgebung schon einen Nachmittag kostet, schließen viele einfach das Fenster.
@Dusk
Daher schaue ich bei den Fortschritten im Dusk-Ökosystem nicht auf das Logo-Wand-Programm der Partner, sondern auf die Aktualisierungsfrequenz der Entwicklerdokumentation, die Reaktionsgeschwindigkeit auf technische Fragen im Discord und darauf, ob es „inoffizielle Anreize“ gibt, die Dritte über Tools und Tutorials treiben. Das echte Entwickler-Ökosystem entsteht durch die Erfahrungen, die beim Stolpern gesammelt wurden – nicht dadurch, dass man technische Blogposts aufeinanderstapelt.