Führte vor jeder Bereitstellung einen schnellen RPC-Check gegen das DuskEVM-Testnet durch, nur um sicherzustellen, dass ich wirklich im richtigen Netzwerk war. Ein kleiner Schritt, aber er hat die CreatorPad-Aufgabe auf etwas Reales gestützt – statt auf Doku-Screenshots. Überbrückte eine Charge von $DUSK from DuskDS, um die Deployment-Wallet zu finanzieren, und schob dann einen einfachen Solidity-Vertrag durch Hardhat. #dusk @Dusk

Was mich tatsächlich aufhielt, war nicht, dass das Deployment erfolgreich war, sondern die Gebührenaufstellung danach. Ich hatte angenommen, dass „privacy-preserving EVM“ bedeutet, dass die Privatsphäre standardmäßig in jede Transaktion eingebaut ist. Dem ist nicht so. Die Ausführungsgebühr und die Data-Availability-Gebühr fürs Posten der Batch-Backs an DuskDS waren beide vollständig sichtbar – ganz im Standard-OP-Stack-Stil. Nichts ist abgeschirmt, außer du leitest gezielt über Hedger.

Das ist eine nachvollziehbare Annahme, die man falsch haben kann. Dusks Kommunikation setzt stark auf Vertraulichkeit, daher liegt es nahe zu erwarten, dass die EVM-Schicht das standardmäßig übernimmt – statt dass man es separat explizit dazubucht.

Architektonisch ergibt das Sinn: Settlement- und Privacy-Tools bleiben entkoppelt von genereller Ausführung. Trotzdem bin ich neugierig, wie viele Entwickler, die hier gerade bauen, tatsächlich zu Hedger greifen – statt einfach nur Standard-EVM-Verträge zu shippen und weiterzumachen. Das ist meine eigene Beobachtung aus Tests, keine finanzielle Beratung. Wenn du das Ökosystem einschätzt, lohnt es sich, das nicht weiter zu verbeißen.

Welchen Teil beim Bauen auf DuskEVM würdest du zuerst angehen? 👇