eine frage, die mir nach dem gestrigen post gekommen ist: wenn ihr auf dusk aufbaut – wie entscheidet man dann tatsächlich zwischen DuskEVM und DuskVM? denn beide werden als optionen erwähnt und es ist nicht sofort ersichtlich, welche davon „die richtige“ ist.
herausgestellt hat sich, dass es überhaupt keine besser-gegen-schlechter-situation ist – es ist rein zweckgebunden, und die kriterien sind ziemlich klar, sobald man sie einmal auflistet.
DuskEVM ist die richtige wahl, wenn ihr solidity oder vyper nutzen wollt, foundry/hardhat/viem/ethers verwenden möchtet oder einfach standard-evm-wallets und bestehende ethereum-bibliotheken nutzen wollt, ohne Anpassungen. im Grunde: Wenn euer team den EVM-stack bereits kennt und dieses wissen direkt mit rüberbringen möchte, dann ist das eure spur.
DuskVM ist die andere option – und zwar speziell für rust/wasm-verträge. die unterscheidung, die hier wirklich zählt, ist nicht nur „eine andere sprache“: DuskVM-verträge werden direkt auf dem Dusk L1 selbst ausgeführt und können sich eng mit den nativen Transaktionsmodellen von duskds, den Protokoll-Assets, den Privacy-Funktionen und den Zero-Knowledge-Fähigkeiten integrieren. wenn ihr also etwas baut, das direkt mit dusk’s privacy oder dem zk-stack interagieren muss – statt nur über eine EVM-kompatible schicht – dann ist DuskVM der ort, an dem diese zugriffe tatsächlich stattfinden.
das mentale modell, zu dem ich letztlich gekommen bin: DuskEVM tauscht etwas tiefe L1-integration gegen volle kompatibilität mit tooling, das eure teams bereits kennen. DuskVM tauscht diese vertrautheit gegen einen direkteren, stärker nativen zugang zu dem, was dusk’s L1 selbst einzigartig macht. keine der beiden ist die „fortgeschrittene“ oder „einfache“ option – sie lösen lediglich unterschiedliche vorgaben, je nachdem, was ihr baut und was euer team bereits weiß.
eine sache interessiert mich aber noch – kann eine einzelne anwendung realistisch beides nutzen? also z. B. eine evm-ausgerichtete frontend, die auf DuskEVM basiert, aber darunter trotzdem etwas DuskVM-natives berühren muss – oder ist das in der praxis eher kein unterstütztes muster.
#dusk $DUSK
@Dusk
herausgestellt hat sich, dass es überhaupt keine besser-gegen-schlechter-situation ist – es ist rein zweckgebunden, und die kriterien sind ziemlich klar, sobald man sie einmal auflistet.
DuskEVM ist die richtige wahl, wenn ihr solidity oder vyper nutzen wollt, foundry/hardhat/viem/ethers verwenden möchtet oder einfach standard-evm-wallets und bestehende ethereum-bibliotheken nutzen wollt, ohne Anpassungen. im Grunde: Wenn euer team den EVM-stack bereits kennt und dieses wissen direkt mit rüberbringen möchte, dann ist das eure spur.
DuskVM ist die andere option – und zwar speziell für rust/wasm-verträge. die unterscheidung, die hier wirklich zählt, ist nicht nur „eine andere sprache“: DuskVM-verträge werden direkt auf dem Dusk L1 selbst ausgeführt und können sich eng mit den nativen Transaktionsmodellen von duskds, den Protokoll-Assets, den Privacy-Funktionen und den Zero-Knowledge-Fähigkeiten integrieren. wenn ihr also etwas baut, das direkt mit dusk’s privacy oder dem zk-stack interagieren muss – statt nur über eine EVM-kompatible schicht – dann ist DuskVM der ort, an dem diese zugriffe tatsächlich stattfinden.
das mentale modell, zu dem ich letztlich gekommen bin: DuskEVM tauscht etwas tiefe L1-integration gegen volle kompatibilität mit tooling, das eure teams bereits kennen. DuskVM tauscht diese vertrautheit gegen einen direkteren, stärker nativen zugang zu dem, was dusk’s L1 selbst einzigartig macht. keine der beiden ist die „fortgeschrittene“ oder „einfache“ option – sie lösen lediglich unterschiedliche vorgaben, je nachdem, was ihr baut und was euer team bereits weiß.
eine sache interessiert mich aber noch – kann eine einzelne anwendung realistisch beides nutzen? also z. B. eine evm-ausgerichtete frontend, die auf DuskEVM basiert, aber darunter trotzdem etwas DuskVM-natives berühren muss – oder ist das in der praxis eher kein unterstütztes muster.
#dusk $DUSK
@Dusk
