#dusk $DUSK @Dusk Diese Woche habe ich eine ganze Nacht damit verbracht, mir anhand der offiziellen Dusk-Dokumentation angesehen, wie man mit dem W3sper SDK im Testnetz den kompletten Ablauf von der Erstellung eines Kontos bis zur Abfrage des Kontostands und dem Senden einer Transaktion durchläuft – ich wollte herausfinden, was sich an diesem von Dusk selbst entwickelten Tooling in der Praxis von den SDKs anderer Chains unterscheidet.
Das Erste, was mich überrascht hat: Dusk’ W3sper läuft komplett in WebAssembly. Man muss keinerlei lokale Abhängigkeiten installieren – man kann alle Schritte wie Kontoverwaltung, Transaktionskonstruktion und Event-Abos direkt im Browser erledigen. Wenn man an die Ethereum-typische Vorgehensweise gewöhnt ist (Node-Umgebung installieren, Provider konfigurieren, Private-Key-Dateien verwalten), ist dieses „Zero-Install“-Erlebnis deutlich leichter. Aber der Teil, der wirklich Zeit kostet, ist: In Dusk ist das Konzept „Account“ komplexer, als man zuerst denkt. In dem W3sper-Profil werden sowohl öffentliche Konten (public account) als auch Abschirmadressen (shielded address) gleichzeitig verwaltet. Man muss zunächst klarhaben, auf welcher Seite man operiert. Öffentliche Konten folgen einem Weg, der wie ein herkömmliches Kontostandsmodell funktioniert. Hinter Abschirmadressen steckt dagegen die Phoenix-Note-/Nullifier-Mechanik. Die Logik zur Transaktionskonstruktion ist auf beiden Seiten völlig unterschiedlich – wenn man sie vermischt, macht man sich leicht Fehler.
Der zweite Stolperstein liegt bei der Gas-Schätzung. In der Doku heißt das Ganze „Proof Management“. Da Abschirmtransaktionen vor dem Senden erst lokal einen Zero-Knowledge-Proof generieren müssen, beinhaltet die Gas-Schätzung in diesem Schritt tatsächlich auch die Rechenkosten, die für die Proof-Generierung anfallen. Das ist nicht dasselbe wie die Gas-Schätzung bei öffentlichen Transaktionen. In meinen ersten Tests habe ich einfach die Schätzlogik für öffentliche Transaktionen übernommen – dadurch wurde die Transaktion zwei Mal abgelehnt, bis ich gemerkt habe, dass man das getrennt behandeln muss.
Ich persönlich finde, dass Dusk in W3sper das Konzept der „Contract Drivers“ (eine standardisierte Brücke zwischen Wallet und Smart Contract) ziemlich clever gelöst hat. Damit müssen Entwickler das „Wallet-Interaktionsrad“ nicht für jedes dApp neu erfinden. Aber die Dokumentation ist dafür aktuell noch nicht detailliert genug: Viele Randfälle (z. B. ob zwischen öffentlichem Konto und Abschirmadresse umgewandelt werden soll, oder wie die Gebühren bei einer Umwandlung berechnet werden) muss man erst selbst ausprobieren, um es zu verstehen. Für Entwickler, die gerade erst mit Dusk anfangen, ist die Einstiegskurve damit steiler als das, was die offizielle Darstellung als „friendly SDK“ verspricht.
Das Erste, was mich überrascht hat: Dusk’ W3sper läuft komplett in WebAssembly. Man muss keinerlei lokale Abhängigkeiten installieren – man kann alle Schritte wie Kontoverwaltung, Transaktionskonstruktion und Event-Abos direkt im Browser erledigen. Wenn man an die Ethereum-typische Vorgehensweise gewöhnt ist (Node-Umgebung installieren, Provider konfigurieren, Private-Key-Dateien verwalten), ist dieses „Zero-Install“-Erlebnis deutlich leichter. Aber der Teil, der wirklich Zeit kostet, ist: In Dusk ist das Konzept „Account“ komplexer, als man zuerst denkt. In dem W3sper-Profil werden sowohl öffentliche Konten (public account) als auch Abschirmadressen (shielded address) gleichzeitig verwaltet. Man muss zunächst klarhaben, auf welcher Seite man operiert. Öffentliche Konten folgen einem Weg, der wie ein herkömmliches Kontostandsmodell funktioniert. Hinter Abschirmadressen steckt dagegen die Phoenix-Note-/Nullifier-Mechanik. Die Logik zur Transaktionskonstruktion ist auf beiden Seiten völlig unterschiedlich – wenn man sie vermischt, macht man sich leicht Fehler.
Der zweite Stolperstein liegt bei der Gas-Schätzung. In der Doku heißt das Ganze „Proof Management“. Da Abschirmtransaktionen vor dem Senden erst lokal einen Zero-Knowledge-Proof generieren müssen, beinhaltet die Gas-Schätzung in diesem Schritt tatsächlich auch die Rechenkosten, die für die Proof-Generierung anfallen. Das ist nicht dasselbe wie die Gas-Schätzung bei öffentlichen Transaktionen. In meinen ersten Tests habe ich einfach die Schätzlogik für öffentliche Transaktionen übernommen – dadurch wurde die Transaktion zwei Mal abgelehnt, bis ich gemerkt habe, dass man das getrennt behandeln muss.
Ich persönlich finde, dass Dusk in W3sper das Konzept der „Contract Drivers“ (eine standardisierte Brücke zwischen Wallet und Smart Contract) ziemlich clever gelöst hat. Damit müssen Entwickler das „Wallet-Interaktionsrad“ nicht für jedes dApp neu erfinden. Aber die Dokumentation ist dafür aktuell noch nicht detailliert genug: Viele Randfälle (z. B. ob zwischen öffentlichem Konto und Abschirmadresse umgewandelt werden soll, oder wie die Gebühren bei einer Umwandlung berechnet werden) muss man erst selbst ausprobieren, um es zu verstehen. Für Entwickler, die gerade erst mit Dusk anfangen, ist die Einstiegskurve damit steiler als das, was die offizielle Darstellung als „friendly SDK“ verspricht.