In jedem wachsenden Blockchain-Leben gibt es einen Moment, in dem das Team entscheiden muss: monolithisch bleiben oder sich in Schichten aufteilen, die für unterschiedliche Aufgaben gebaut sind. Dusk Network hat diese Entscheidung getroffen – und es lohnt sich, sie Schritt für Schritt durchzugehen.
Die Basis ist DuskDS: die Schicht für Settlement, Konsens und Datenverfügbarkeit. Sie betreibt Succinct Attestation, verwaltet den Genesis-Stake sowie die Transfer-Contracts und überträgt Daten über Kadcast – ein Peer-to-Peer-Netzwerkprotokoll, das den Bandbreitenverbrauch im Vergleich zu standardmäßigen Gossip-Netzwerken ungefähr um 25% bis 50% reduziert. Darauf sitzt DuskVM, die Heimat von Piecrust und nativen datenschutzfreundlichen Contracts, die auf dem Modell basieren. Dann gibt es DuskEVM: eine vollständig EVM-äquivalente Schicht, die über einen OP-Stack-Port erstellt wurde. Sie bietet Solidity-Entwicklern Hardhat, Foundry und MetaMask-Kompatibilität – und settled weiterhin zurück auf DuskDS.
Was die drei verbindet, ist eine native Bridge, keine Bridge für umhüllte Assets. Ein DUSK-Token bewegt sich durch alle drei Umgebungen, und ein Pre-Verifier auf Basis von MIPS prüft Zustandsübergänge, bevor diese überhaupt die Kette erreichen. Genau deshalb trägt Dusk Network nicht das typische sieben-Tage-Withdrawal-Fault-Window, das Optimism-artige Rollups üblicherweise erfordern. Withdrawals werden in etwa 15 Minuten finalisiert.
DuskTrade, die neobrokerartige Anwendung des Netzwerks, ist ein funktionierendes Beispiel dafür, wofür dieser Stack tatsächlich gedacht ist: direkte, On-Chain-Eigentümerschaft an Geldmarkt-Fonds, ETFs und Bonds, die sich in dem Moment begleichen, in dem ein Trade ausgeführt wird – und die sich in DeFi einfügen wie jeder andere Token.
Ich will nicht so tun, als wären drei Schichten automatisch besser als eine. Das Aufteilen von Ausführungsumgebungen schafft echte Koordinationsflächen: mehr Codepfade, mehr Orte, an denen sich Bugs verstecken können, und mehr Entscheidungen darüber, welche Schicht zu einem bestimmten Use Case passt. Dusk Network setzt darauf, dass es sich lohnt, Build-ern eine native Datenschutz-Umgebung und eine vertraute EVM-Umgebung unter einer einzigen Settlement-Schicht zu geben – vor allem für Ethereum-native Teams, die nicht alles neu schreiben wollen, nur um Datenschutz zu erhalten.
Ob die zusätzliche Angriffs- bzw. Fehlerfläche unter realen, adversarialen Bedingungen standhält – nicht nur in Diagrammen aus der Dokumentation – das ist das, worauf ich als Nächstes achten werde.
#dusk $DUSK @Dusk
Die Basis ist DuskDS: die Schicht für Settlement, Konsens und Datenverfügbarkeit. Sie betreibt Succinct Attestation, verwaltet den Genesis-Stake sowie die Transfer-Contracts und überträgt Daten über Kadcast – ein Peer-to-Peer-Netzwerkprotokoll, das den Bandbreitenverbrauch im Vergleich zu standardmäßigen Gossip-Netzwerken ungefähr um 25% bis 50% reduziert. Darauf sitzt DuskVM, die Heimat von Piecrust und nativen datenschutzfreundlichen Contracts, die auf dem Modell basieren. Dann gibt es DuskEVM: eine vollständig EVM-äquivalente Schicht, die über einen OP-Stack-Port erstellt wurde. Sie bietet Solidity-Entwicklern Hardhat, Foundry und MetaMask-Kompatibilität – und settled weiterhin zurück auf DuskDS.
Was die drei verbindet, ist eine native Bridge, keine Bridge für umhüllte Assets. Ein DUSK-Token bewegt sich durch alle drei Umgebungen, und ein Pre-Verifier auf Basis von MIPS prüft Zustandsübergänge, bevor diese überhaupt die Kette erreichen. Genau deshalb trägt Dusk Network nicht das typische sieben-Tage-Withdrawal-Fault-Window, das Optimism-artige Rollups üblicherweise erfordern. Withdrawals werden in etwa 15 Minuten finalisiert.
DuskTrade, die neobrokerartige Anwendung des Netzwerks, ist ein funktionierendes Beispiel dafür, wofür dieser Stack tatsächlich gedacht ist: direkte, On-Chain-Eigentümerschaft an Geldmarkt-Fonds, ETFs und Bonds, die sich in dem Moment begleichen, in dem ein Trade ausgeführt wird – und die sich in DeFi einfügen wie jeder andere Token.
Ich will nicht so tun, als wären drei Schichten automatisch besser als eine. Das Aufteilen von Ausführungsumgebungen schafft echte Koordinationsflächen: mehr Codepfade, mehr Orte, an denen sich Bugs verstecken können, und mehr Entscheidungen darüber, welche Schicht zu einem bestimmten Use Case passt. Dusk Network setzt darauf, dass es sich lohnt, Build-ern eine native Datenschutz-Umgebung und eine vertraute EVM-Umgebung unter einer einzigen Settlement-Schicht zu geben – vor allem für Ethereum-native Teams, die nicht alles neu schreiben wollen, nur um Datenschutz zu erhalten.
Ob die zusätzliche Angriffs- bzw. Fehlerfläche unter realen, adversarialen Bedingungen standhält – nicht nur in Diagrammen aus der Dokumentation – das ist das, worauf ich als Nächstes achten werde.
#dusk $DUSK @Dusk
