Letzte Nacht habe ich das Whitepaper mit der Nummer @Dusk noch einmal gelesen, und als ich auf der Seite mit der „Dual-VM-Architektur“ ankam, bin ich hängen geblieben.
Zuerst zur Architektur. Piecrust ist eine native Zero-Knowledge-Virtual Machine, basiert auf WASM, und die Abrechnung lässt sich auf 2–3 Sekunden drücken. DuskEVM ist Solidity-kompatibel: Hardhat und MetaMask kann man direkt dagegenhalten – es läuft sofort. Die Privatsphäre wird durch Hedger ergänzt und auf der unteren ZK-Ebene nachgerüstet.
Das Dual-Track-Design hat wirklich Substanz: Ein Strang kümmert sich um Privacy-Contracts, der andere um Kompatibilität, damit jede Einheit ihre Aufgabe erfüllt.
Aber je weiter ich lese, desto seltsamer kommt es mir vor. Piecrust entwickelt seine VM selbst. Im März kam beim AEGIS-Audit heraus, dass es 39 Probleme gab, davon 7 schwerwiegend. Zwei zentrale Schwachstellen stecken in der Sandbox-Schicht. Selbst ehrliche Nodes, die denselben Code ausführen, können zu unterschiedlichen Ergebnissen kommen. Ein bösartiger Contract kann den Runtime-Zustand so kippen, dass die Garantien für Ownership nicht mehr greifen. Wenn die Sandbox durchbrochen wird, sind die darüberliegenden vertraulichen Contracts komplett verloren. DuskEVM unterstützt an sich nur öffentliche Transaktionen; die Privatsphäre wird über zusätzliche Module abgefedert. Zwei VM-Systeme, die jeweils für sich arbeiten: Codeumfang und Angriffsfläche verdoppeln sich direkt.
Dann zur Zusammenarbeit. NPEX, Chainlink, Cordial, Quantoz, 21X – auf der Website stehen €300M+ bestätigte Emission, 50K+ Reichweite von Investoren, 210M+ DUSK gestaked. Die Ressourcen wirken tatsächlich solider als bei Projekten, die nur RWA-Geschichten erzählen. Aber selbst die offizielle Seite gibt zu: Tokenisierung kann Reibung reduzieren, aber man kann damit keine Käufer, Verkäufer und keine Markttiefe „erschaffen“. Dusk Trade ist noch „Building/Waitlist“, und DuskEVM sowie Hedger sind ebenfalls noch im Testnet. Die Partnerschaft zeigt, dass andere bereit sind, mitzumachen – aber ob es wirklich läuft, hängt an harten Kennzahlen: wie viel Asset tatsächlich on-chain geht, wie viele Nutzer handeln und wie tief die Orderbücher im Sekundärmarkt sind.
Zum Schluss: Compliance und der Anschluss an die Privatsphäre. Zedger schreibt bei der Emission Whitelists, „single identity, single account“ sowie eine explizite Zustimmung des Empfängers in das Protokoll. Die Übertragung wird in zwei Schritte zerlegt, und bei Timeout wird sie automatisch ungültig. Phoenix nutzt eine UTXO-Architektur: Gelder existieren als verschlüsselte Notes; bei der Transaktion prüft ZK gleichzeitig fünf Dinge. Pedersen Commitments verbergen sowohl Beträge als auch Adressen komplett. DuskDS bestätigt in drei Phasen, und der Blockbau ist zugleich der Endzustand. Die Regeln steuern, ob etwas passieren darf; Phoenix legt fest, welche Aspekte nicht öffentlich sein müssen; DuskDS definiert, welcher Status zählt. Diese drei Bausteine ergänzen denselben Engpass: Von Emission bis Abrechnung soll das, was nötig ist, möglichst nicht zurück auf die Kette verlagert und neu koordiniert werden.
Die Partnerliste ist inzwischen schon ziemlich „institutionell“ geworden. In der nächsten Phase möchte ich vor allem echte Migrations- und成交daten sehen – nicht ständig nur als PPT. #dusk $DUSK
Zuerst zur Architektur. Piecrust ist eine native Zero-Knowledge-Virtual Machine, basiert auf WASM, und die Abrechnung lässt sich auf 2–3 Sekunden drücken. DuskEVM ist Solidity-kompatibel: Hardhat und MetaMask kann man direkt dagegenhalten – es läuft sofort. Die Privatsphäre wird durch Hedger ergänzt und auf der unteren ZK-Ebene nachgerüstet.
Das Dual-Track-Design hat wirklich Substanz: Ein Strang kümmert sich um Privacy-Contracts, der andere um Kompatibilität, damit jede Einheit ihre Aufgabe erfüllt.
Aber je weiter ich lese, desto seltsamer kommt es mir vor. Piecrust entwickelt seine VM selbst. Im März kam beim AEGIS-Audit heraus, dass es 39 Probleme gab, davon 7 schwerwiegend. Zwei zentrale Schwachstellen stecken in der Sandbox-Schicht. Selbst ehrliche Nodes, die denselben Code ausführen, können zu unterschiedlichen Ergebnissen kommen. Ein bösartiger Contract kann den Runtime-Zustand so kippen, dass die Garantien für Ownership nicht mehr greifen. Wenn die Sandbox durchbrochen wird, sind die darüberliegenden vertraulichen Contracts komplett verloren. DuskEVM unterstützt an sich nur öffentliche Transaktionen; die Privatsphäre wird über zusätzliche Module abgefedert. Zwei VM-Systeme, die jeweils für sich arbeiten: Codeumfang und Angriffsfläche verdoppeln sich direkt.
Dann zur Zusammenarbeit. NPEX, Chainlink, Cordial, Quantoz, 21X – auf der Website stehen €300M+ bestätigte Emission, 50K+ Reichweite von Investoren, 210M+ DUSK gestaked. Die Ressourcen wirken tatsächlich solider als bei Projekten, die nur RWA-Geschichten erzählen. Aber selbst die offizielle Seite gibt zu: Tokenisierung kann Reibung reduzieren, aber man kann damit keine Käufer, Verkäufer und keine Markttiefe „erschaffen“. Dusk Trade ist noch „Building/Waitlist“, und DuskEVM sowie Hedger sind ebenfalls noch im Testnet. Die Partnerschaft zeigt, dass andere bereit sind, mitzumachen – aber ob es wirklich läuft, hängt an harten Kennzahlen: wie viel Asset tatsächlich on-chain geht, wie viele Nutzer handeln und wie tief die Orderbücher im Sekundärmarkt sind.
Zum Schluss: Compliance und der Anschluss an die Privatsphäre. Zedger schreibt bei der Emission Whitelists, „single identity, single account“ sowie eine explizite Zustimmung des Empfängers in das Protokoll. Die Übertragung wird in zwei Schritte zerlegt, und bei Timeout wird sie automatisch ungültig. Phoenix nutzt eine UTXO-Architektur: Gelder existieren als verschlüsselte Notes; bei der Transaktion prüft ZK gleichzeitig fünf Dinge. Pedersen Commitments verbergen sowohl Beträge als auch Adressen komplett. DuskDS bestätigt in drei Phasen, und der Blockbau ist zugleich der Endzustand. Die Regeln steuern, ob etwas passieren darf; Phoenix legt fest, welche Aspekte nicht öffentlich sein müssen; DuskDS definiert, welcher Status zählt. Diese drei Bausteine ergänzen denselben Engpass: Von Emission bis Abrechnung soll das, was nötig ist, möglichst nicht zurück auf die Kette verlagert und neu koordiniert werden.
Die Partnerliste ist inzwischen schon ziemlich „institutionell“ geworden. In der nächsten Phase möchte ich vor allem echte Migrations- und成交daten sehen – nicht ständig nur als PPT. #dusk $DUSK