Vor kurzem habe ich die Entwickler-Tools von Dusk ausprobiert und dabei etwas entdeckt, das mich ziemlich überrascht hat: Dusk Connect.
Beim Durchsehen der Dusk-Dokumentation war mein größter Eindruck, dass der technische Stack zwar wirklich schön ist, aber das Frontend-Tooling fast komplett fehlt. Entwickler haben die Verträge geschrieben, sie auf die Kette gebracht – und dann? Wie verbinden Nutzer ihre Wallets, wie signieren sie Transaktionen? Das mussten sie alles selbst bauen.
Dusk Connect löst genau dieses Problem: ein leichtgewichtiges SDK, mit dem dApps kompatible Wallets für Konten, Signatur-Transaktionen automatisch erkennen können. Dabei wird der Standard EIP-6963 verwendet. Ergänzend gibt es auch offizielle Wallets – mit Browser-Plugin, Desktop- und Mobile-Abdeckung. Der Kern-Workflow ist jetzt verbunden: Forge schreibt die Verträge, Dusk Connect verbindet sich mit der Wallet, und Nutzer können direkt interagieren.
Aber diese ganze @Dusk -Sache ist derzeit nur ein „developer preview“. Ich bin kein Entwickler, daher kann ich die technische Stabilität nicht beurteilen. Allerdings scheint es logisch, dass damit ein fehlendes Puzzleteil im Dusk-Ökosystem ergänzt wird: die Infrastruktur auf Anwendungsebene. Früher mussten Institutionen, die auf dieser Kette Anwendungen aufbauen wollten, die Wallet-Anpassung von Grund auf selbst lösen. Jetzt gibt es zumindest eine Standardantwort, die man übernehmen kann.
Ich habe außerdem festgestellt, dass Dusk die Senkung der Einstiegshürde für Entwickler, von der es bisher immer gesprochen hat, nach der DuskEVM-Kompatibilität mit Solidity noch einmal einen Schritt weiter vorangetrieben hat. Jetzt ist die Frage: Sobald das Tooling da ist – kommen die Entwickler überhaupt, und kann das Ökosystem wirklich in Gang kommen? Das ist die eigentliche Bewährungsprobe. Ich bleibe dran und schaue, sobald die OpenDusk-Community-Initiative offiziell startet.#dusk $DUSK
Beim Durchsehen der Dusk-Dokumentation war mein größter Eindruck, dass der technische Stack zwar wirklich schön ist, aber das Frontend-Tooling fast komplett fehlt. Entwickler haben die Verträge geschrieben, sie auf die Kette gebracht – und dann? Wie verbinden Nutzer ihre Wallets, wie signieren sie Transaktionen? Das mussten sie alles selbst bauen.
Dusk Connect löst genau dieses Problem: ein leichtgewichtiges SDK, mit dem dApps kompatible Wallets für Konten, Signatur-Transaktionen automatisch erkennen können. Dabei wird der Standard EIP-6963 verwendet. Ergänzend gibt es auch offizielle Wallets – mit Browser-Plugin, Desktop- und Mobile-Abdeckung. Der Kern-Workflow ist jetzt verbunden: Forge schreibt die Verträge, Dusk Connect verbindet sich mit der Wallet, und Nutzer können direkt interagieren.
Aber diese ganze @Dusk -Sache ist derzeit nur ein „developer preview“. Ich bin kein Entwickler, daher kann ich die technische Stabilität nicht beurteilen. Allerdings scheint es logisch, dass damit ein fehlendes Puzzleteil im Dusk-Ökosystem ergänzt wird: die Infrastruktur auf Anwendungsebene. Früher mussten Institutionen, die auf dieser Kette Anwendungen aufbauen wollten, die Wallet-Anpassung von Grund auf selbst lösen. Jetzt gibt es zumindest eine Standardantwort, die man übernehmen kann.
Ich habe außerdem festgestellt, dass Dusk die Senkung der Einstiegshürde für Entwickler, von der es bisher immer gesprochen hat, nach der DuskEVM-Kompatibilität mit Solidity noch einmal einen Schritt weiter vorangetrieben hat. Jetzt ist die Frage: Sobald das Tooling da ist – kommen die Entwickler überhaupt, und kann das Ökosystem wirklich in Gang kommen? Das ist die eigentliche Bewährungsprobe. Ich bleibe dran und schaue, sobald die OpenDusk-Community-Initiative offiziell startet.#dusk $DUSK