Sagen wir es mal ganz ehrlich: Dieser WASM-Vertrags-Workflow von Dusk – Editor im Chrome öffnen, Wallet verbinden, kompilieren klicken – und ich hatte davor und danach keinerlei lokale Abhängigkeiten installiert. Das Erlebnis ist wirklich ziemlich reibungslos.#[contract] Das Macro übernimmt Export und Serialisierung komplett von der Seite her. Auch die Bridge-Ebene in Contract Drivers hat mir einiges an Zeit gespart, um überhaupt erst nach dem ABI zu suchen. Wenn du nur den öffentlichen Transfer von Moonlight aus ausführst – von null bis live – dann ist das vielleicht sogar schneller, als würdest du dir einen Becher Handgebrühten (Pour-over) aufsetzen.
Der Brotkuchen steigt schon wieder … BTC ist weiterhin stark.
Aber was mich wirklich dazu gebracht hat, mich für eine halbe Stunde hinzusetzen und mehr nachzudenken, war: als ich eine gesperrte Phoenix-Überweisung in die Query-Logik von Moonlight eingebaut habe und dabei debuggen musste.
Die Spielweise von Dusk setzt auf zwei Beine: Moonlight ist ein transparenter Ledger, dessen Saldo direkt ins Konto geschrieben wird; Phoenix ist ein UTXO-Modell, das eine Ebene „unsichtbarer“ Adressen darüberlegt, sodass der Saldo im note steckt. Zwischen diesen beiden fließt das Geld über den Transfer Contract als Übersetzer: öffentlicher Transfer → zuerst Saldo abziehen, dann note prägen; gesperrter Transfer → erst note verbrennen, dann Saldo erhöhen. Klingt das nicht nach klarer Logik? Aber sobald du eine Query-API schreibst und einmalig die Summe der Salden auf beiden Seiten anzeigen willst, musst du gleichzeitig zwei komplett unterschiedliche Datenformate verarbeiten: den Kontostatus und die note-Verschlüsselungen.
Die erste Reaktion in meinem Team war, den value der note einfach als Saldo zu addieren – aber die Transaktion, die ich danach broadcastet habe, war direkt futsch. Denn bei Phoenix muss der note erst alle Eigentumsbeweise validieren, bevor man den Zahlenwert überhaupt entschlüsseln kann. Das ist zeitlich überhaupt nicht dasselbe wie das Auslesen der Salden in Moonlight.
Gas ist dabei noch ein unsichtbares Minenfeld. Bei öffentlichen Transaktionen kannst du die Gas-Kosten wie üblich abschätzen – grob liegst du meistens richtig; aber bei gesperrten Transaktionen läuft alles über die Generierung und Verifizierung von ZK-Beweisen. Die Komplexität des Beweisschaltkreises hängt unmittelbar mit der Anzahl der notes in deiner Transaktion und den jeweiligen Constraints zusammen. Ich habe eine Phoenix-Überweisung mit 2 Input-notes und 3 Output-notes ausprobiert: Der Gas-Verbrauch war im Vergleich zu einer öffentlichen Transaktion mit derselben Größenordnung um fast zwei Größenordnungen höher. Die in der Doku angegebenen Gas-Konstanten kannst du dabei nur als groben Startpreis ansehen. Für einen echten Launch musst du vorab im Testnet mit echten Parametern ein paar Runden simulieren – sonst traut man sich das Gas-Limit wirklich nicht aus dem Bauch einzutragen: Zu wenig → Transaktion wird revertet; zu viel → du verbrennst einfach Geld.
Was ich noch nicht ganz verstanden habe: In den offiziellen Dusk-Tutorials sind die Randfälle rund um „Hybrid-Query + Cross-Model-Calls“ ziemlich dünn erklärt – die Grenzbeschreibungen sind echt spärlich. @Dusk $DUSK #dusk
Der Brotkuchen steigt schon wieder … BTC ist weiterhin stark.
Aber was mich wirklich dazu gebracht hat, mich für eine halbe Stunde hinzusetzen und mehr nachzudenken, war: als ich eine gesperrte Phoenix-Überweisung in die Query-Logik von Moonlight eingebaut habe und dabei debuggen musste.
Die Spielweise von Dusk setzt auf zwei Beine: Moonlight ist ein transparenter Ledger, dessen Saldo direkt ins Konto geschrieben wird; Phoenix ist ein UTXO-Modell, das eine Ebene „unsichtbarer“ Adressen darüberlegt, sodass der Saldo im note steckt. Zwischen diesen beiden fließt das Geld über den Transfer Contract als Übersetzer: öffentlicher Transfer → zuerst Saldo abziehen, dann note prägen; gesperrter Transfer → erst note verbrennen, dann Saldo erhöhen. Klingt das nicht nach klarer Logik? Aber sobald du eine Query-API schreibst und einmalig die Summe der Salden auf beiden Seiten anzeigen willst, musst du gleichzeitig zwei komplett unterschiedliche Datenformate verarbeiten: den Kontostatus und die note-Verschlüsselungen.
Die erste Reaktion in meinem Team war, den value der note einfach als Saldo zu addieren – aber die Transaktion, die ich danach broadcastet habe, war direkt futsch. Denn bei Phoenix muss der note erst alle Eigentumsbeweise validieren, bevor man den Zahlenwert überhaupt entschlüsseln kann. Das ist zeitlich überhaupt nicht dasselbe wie das Auslesen der Salden in Moonlight.
Gas ist dabei noch ein unsichtbares Minenfeld. Bei öffentlichen Transaktionen kannst du die Gas-Kosten wie üblich abschätzen – grob liegst du meistens richtig; aber bei gesperrten Transaktionen läuft alles über die Generierung und Verifizierung von ZK-Beweisen. Die Komplexität des Beweisschaltkreises hängt unmittelbar mit der Anzahl der notes in deiner Transaktion und den jeweiligen Constraints zusammen. Ich habe eine Phoenix-Überweisung mit 2 Input-notes und 3 Output-notes ausprobiert: Der Gas-Verbrauch war im Vergleich zu einer öffentlichen Transaktion mit derselben Größenordnung um fast zwei Größenordnungen höher. Die in der Doku angegebenen Gas-Konstanten kannst du dabei nur als groben Startpreis ansehen. Für einen echten Launch musst du vorab im Testnet mit echten Parametern ein paar Runden simulieren – sonst traut man sich das Gas-Limit wirklich nicht aus dem Bauch einzutragen: Zu wenig → Transaktion wird revertet; zu viel → du verbrennst einfach Geld.
Was ich noch nicht ganz verstanden habe: In den offiziellen Dusk-Tutorials sind die Randfälle rund um „Hybrid-Query + Cross-Model-Calls“ ziemlich dünn erklärt – die Grenzbeschreibungen sind echt spärlich. @Dusk $DUSK #dusk