đ
8.22
Die letzten Tage war die Flut an Meldungen Ăźberwältigend: $BTC hat irgendwas âdurchbrochenâ, $BNB hat irgendwas âdurchbrochenâ â und ich habe kein einziges Spot-Asset. Ich schaue dabei zu, wie ihr Geld verdient, während ich mich lieber an die Tasten setze und mit ein bisschen Gelegenheitsarbeit mein kleines SĂźmmchen verdiene.
Heute Morgen, als ich die Dusk-Entwicklerdokumentation durchgegangen bin, gab es ein Paradox, das sich immer wieder zeigt: Das Designgefßhl fßr die technische Architektur ist zwar stark, aber wenn man dann wirklich mit der Entwicklung anfängt, gibt es viel mehr Stolperstellen als gedacht.
â Die Vorteile sind tatsächlich da. DuskVM läuft auf WebAssembly und erlaubt es, Rust-Contracts auszufĂźhren â ohne lokale Abhängigkeiten; Entwicklung ist allein im Browser mĂśglich. Der W3sper-SDK-Contract-Drivers-Bridge-Layer hat eine Menge Ideen: Er baut eine Abstraktionsschicht zwischen Wallet und Contract, wodurch sich die doppelte Entwicklungsarbeit reduziert. Als ich diese Designs das erste Mal gesehen habe, habe ich wirklich gedacht: Wow, das ist ziemlich erfrischend.
â ď¸ Aber sobald ich versuche, wirklich eine Privacy-Transaktion auszufĂźhren, tauchen die Probleme auf.
Moonlight (Ăśffentliches Konto) und Phoenix (gesperrte/verdeckt adressierte) nutzen zwei komplett unterschiedliche Transaktionslogiken, die auf derselben Kette laufen. Von Moonlight zu Phoenix zieht der Contract das Ăśffentliche Guthaben ab und erzeugt ein ânoteâ, das dann an eine versteckte Adresse gesendet wird; umgekehrt wird erst die note verbraucht und dann das Ăśffentliche Guthaben gutgeschrieben. Logisch ist das nachvollziehbar â aber in der Praxis ist das Zustandsmodell, der Instruction-Set und die Gas-Berechnung alles um âtransparente AusfĂźhrungâ herum entworfen. Ich habe versucht, die Gas-Logik der Ăśffentlichen Transaktionen direkt wiederzuverwenden, um die Gas-Kosten fĂźr eine getarnte Transaktion abzuschätzen â das Ergebnis: Die Transaktion ist sofort fehlgeschlagen.
Was mir zusätzlich Kopfzerbrechen macht, ist die Dokumentation. Offiziell heiĂt es âEntwicklung nur im Browserâ, aber ich habe mich durch die Doku gewĂźhlt â viele Hinweise zu Randfällen fehlen. Eine essentielle Funktion findet man in der Dokumentation nicht mit klarer Anleitung; ich muss also selbst im Quellcode der Contracts suchen. FĂźr die Entwicklung eines realen Projekts ist diese Zeitersparnis deutlich geringer als ursprĂźnglich erhofft.
Die Innovation in der technischen Architektur verdient Anerkennung â WASM-Contracts, das Dual-Transaktionsmodell und die abstrakte Idee von Contract Drivers sind allesamt zukunftsorientiert. Aber die Komplexität, die diese Innovationen mit sich bringen, ist derzeit von Dokumentation und Toolchain noch nicht vollständig abgedeckt. FĂźr mich ist die EinstiegshĂźrde fĂźr diese Architektur weit hĂśher als das, was der offizielle Claim âBrowser-only developmentâ beim ersten Lesen erwarten lässt.
#dusk $DUSK @Dusk
Die letzten Tage war die Flut an Meldungen Ăźberwältigend: $BTC hat irgendwas âdurchbrochenâ, $BNB hat irgendwas âdurchbrochenâ â und ich habe kein einziges Spot-Asset. Ich schaue dabei zu, wie ihr Geld verdient, während ich mich lieber an die Tasten setze und mit ein bisschen Gelegenheitsarbeit mein kleines SĂźmmchen verdiene.
Heute Morgen, als ich die Dusk-Entwicklerdokumentation durchgegangen bin, gab es ein Paradox, das sich immer wieder zeigt: Das Designgefßhl fßr die technische Architektur ist zwar stark, aber wenn man dann wirklich mit der Entwicklung anfängt, gibt es viel mehr Stolperstellen als gedacht.
â Die Vorteile sind tatsächlich da. DuskVM läuft auf WebAssembly und erlaubt es, Rust-Contracts auszufĂźhren â ohne lokale Abhängigkeiten; Entwicklung ist allein im Browser mĂśglich. Der W3sper-SDK-Contract-Drivers-Bridge-Layer hat eine Menge Ideen: Er baut eine Abstraktionsschicht zwischen Wallet und Contract, wodurch sich die doppelte Entwicklungsarbeit reduziert. Als ich diese Designs das erste Mal gesehen habe, habe ich wirklich gedacht: Wow, das ist ziemlich erfrischend.
â ď¸ Aber sobald ich versuche, wirklich eine Privacy-Transaktion auszufĂźhren, tauchen die Probleme auf.
Moonlight (Ăśffentliches Konto) und Phoenix (gesperrte/verdeckt adressierte) nutzen zwei komplett unterschiedliche Transaktionslogiken, die auf derselben Kette laufen. Von Moonlight zu Phoenix zieht der Contract das Ăśffentliche Guthaben ab und erzeugt ein ânoteâ, das dann an eine versteckte Adresse gesendet wird; umgekehrt wird erst die note verbraucht und dann das Ăśffentliche Guthaben gutgeschrieben. Logisch ist das nachvollziehbar â aber in der Praxis ist das Zustandsmodell, der Instruction-Set und die Gas-Berechnung alles um âtransparente AusfĂźhrungâ herum entworfen. Ich habe versucht, die Gas-Logik der Ăśffentlichen Transaktionen direkt wiederzuverwenden, um die Gas-Kosten fĂźr eine getarnte Transaktion abzuschätzen â das Ergebnis: Die Transaktion ist sofort fehlgeschlagen.
Was mir zusätzlich Kopfzerbrechen macht, ist die Dokumentation. Offiziell heiĂt es âEntwicklung nur im Browserâ, aber ich habe mich durch die Doku gewĂźhlt â viele Hinweise zu Randfällen fehlen. Eine essentielle Funktion findet man in der Dokumentation nicht mit klarer Anleitung; ich muss also selbst im Quellcode der Contracts suchen. FĂźr die Entwicklung eines realen Projekts ist diese Zeitersparnis deutlich geringer als ursprĂźnglich erhofft.
Die Innovation in der technischen Architektur verdient Anerkennung â WASM-Contracts, das Dual-Transaktionsmodell und die abstrakte Idee von Contract Drivers sind allesamt zukunftsorientiert. Aber die Komplexität, die diese Innovationen mit sich bringen, ist derzeit von Dokumentation und Toolchain noch nicht vollständig abgedeckt. FĂźr mich ist die EinstiegshĂźrde fĂźr diese Architektur weit hĂśher als das, was der offizielle Claim âBrowser-only developmentâ beim ersten Lesen erwarten lässt.
#dusk $DUSK @Dusk
