#dusk $DUSK Kürzlich habe ich mir die Entwicklerarchitektur von Dusk angesehen und festgestellt, dass das Verhältnis zwischen DuskVM und DuskEVM ein eigenes Gespräch wert ist. Die Namen sind sich ähnlich, aber die Aufgaben sind nicht einfach nur eine Wiederholung. DuskVM kommt Dusk’s nativer Ausführungsumgebung am nächsten und eignet sich für Anwendungen, die direkt auf zugrunde liegende Asset-Modelle, Privacy-Fähigkeiten und Mechanismen zur Zero-Knowledge-Verifikation zugreifen müssen. DuskEVM richtet sich dagegen an Entwickler, die mit Solidity und dem Ethereum-Tooling vertraut sind, sodass sie mit geringeren Umstellungskosten in das Dusk-Ökosystem einsteigen können.$SPCXB
Die Bedeutung dieser beiden Wege liegt darin, einen lang bestehenden Widerspruch in der Blockchain-Entwicklung zu lösen. Native Architekturen können die Performance und Privatsphäre auf der Ebene der Basisressourcen in der Regel besser zur Geltung bringen, aber Entwickler müssen neue Sprachen, Tools und Kontomodelle erlernen. EVM-Kompatibilität hingegen ermöglicht den Rückgriff auf ausgereifte Tools wie Solidity, Hardhat und Foundry, wodurch die Einstiegshürde beim Deployment sinkt. Gleichzeitig müssen jedoch die Beziehung zwischen nativen Privacy-Funktionen und der Asset-Abrechnung möglicherweise neu behandelt werden. Dusk zwingt nicht alle Entwickler, denselben Weg zu gehen, sondern platziert besondere Fähigkeiten und Ökosystem-Kompatibilität jeweils in unterschiedlichen Ausführungsumgebungen.$SNDKB
Man kann es sich als zwei Produktionslinien in demselben Industriepark vorstellen. Die eine ist eine Maßschneiderei, die für die Verarbeitung von Privatsphäre, nativen Assets und komplexen Verifikationsanforderungen geeignet ist; die andere ist eine standardisierte Montagelinie, über die externe Teams mit vertrauten Werkzeugen schnell in den Prozess einsteigen können. Am Ende müssen beide Arten von Anwendungen weiterhin das zugrunde liegende Dusk-Netzwerk für die Abrechnung nutzen und spielen dabei während Transaktionen und Ausführung eine Rolle bei den grundlegenden Kosten.
Allerdings besteht noch ein Abstand zwischen der Unterstützung für Entwickler beim Deployment und der Ausbildung eines reifen Ökosystems. Was wirklich zu beobachten ist, ist nicht, wie viele Einstiege es auf den Architekturdiagrammen gibt, sondern ob es ein anhaltendes Wachstum von Verträgen, Nutzern, Kapital und Interaktionen über Ebenen hinweg gibt. Ob DuskEVM mehr EVM-Teams anzieht und ob DuskVM echte Anwendungen mit Bedarf an nativer Privatsphäre im Kern halten kann—diese beiden Punkte werden mitentscheiden, ob die Dual-Execution-Umgebungen letztlich sinnvoll aufgeteilt sind und nicht nur technisch nebeneinander existieren.#dusk @Dusk