#dusk $DUSK Kürzlich habe ich mir an einem Wochenende vorgenommen, basierend auf der Entwickler-Dokumentation nach @Dusk eine lokale Umgebung von Grund auf aufzubauen. Ganz ehrlich: Der Prozess war zäher als ich erwartet hatte.
Auf konzeptioneller Ebene ist die Doku wirklich gut gelungen: Die Architekturdiagramme sind klar, die Aufgabenverteilung der Kernmodule ist verständlich, und auch die Design-Ideen der Rusk-VM werden in eigenen Kapiteln ausführlich behandelt. Aber sobald man in die Praxis geht, tauchen die Probleme auf. Die Abhängigkeiten in den Beispielcodes sind nicht mit den neuesten Versionen in den Repositories synchron, bei manchen APIs fehlen in der Doku die Angaben zu den Eingabeparametern vollständig – man muss den Quellcode durchsuchen, um das Parameterformat zu finden. Das ist nicht unbedingt ein „Dealbreaker“, aber es zehrt stark an Geduld und Vertrauen der Entwickler.
Was mich noch mehr beschäftigt, ist die Stabilität des Testnetzes. Als ich mich lokal mit dem Testnet verband, um ein paar einfache Transaktionen zu debuggen, hatte ich mehrmals Situationen, in denen RPC-Knoten nicht reagierten. Nach einem Retry ging es zwar wieder, aber in der Doku stehen keine Hinweise zur Service-Klasse des Testnetzes und zu Wartungsfenstern. Für Entwickler, die nur mal „schauen wollen, wie es läuft“, kann diese Ungewissheit direkt abschrecken – und sie würden dir nicht einmal erklären, warum du gehst.
Ein weiterer Eindruck: Das Entwickler-Tooling von Dusk unterscheidet sich deutlich vom Ethereum-Ökosystem – das ist ein zweischneidiges Schwert. Einerseits kann Dusk seine Privatsphäre- und Compliance-Eigenschaften tiefgehend anpassen, ohne durch die historische Last des EVM eingeschränkt zu sein; andererseits können Entwickler ihre Solidity-Skills und vorhandenen Tools nicht einfach wiederverwenden. Obwohl die Doku einen Rust SDK sowie Kontraktbeispiele bereitstellt, ist die Lernkurve deutlich steiler, wenn man von null zuerst Rust lernt und dann das Dusk-Entwicklungsparadigma. Das ist viel steiler als „einen ERC-20 forked“.
Ich verstehe, dass Dokumentation und Toolchain-Zusammenstellung Zeit brauchen und es auch sinnvoll ist, dass das Team Ressourcen zuerst auf Mainnet und Kernprotokolle fokussiert. Aber bei der Cold-Start-Entwicklung des Entwickler-Ökosystems hängt der Anlauf nicht an der Protokollleistung, sondern daran, dass am ersten Tag ein „Hello World“ sofort durchläuft. Wenn #dusk dann ein stabileres Testnet, einanfängerfreundliche Tutorials mit Versionsbindung sowie genug Fälle von Drittentwicklern liefert, die erfolgreich deployen, dann bewerte ich erneut, ob das Ökosystem in einen positiven Kreislauf eingetreten ist. Für $DUSK bedeutet die Zahl der Entwickler nicht „Community-Mitglieder“, sondern die Anzahl der tatsächlich auf der Chain deployedeten Smart Contracts. @Dusk