Pensé que DuskVM y DuskEVM eran básicamente dos formas de construir lo mismo.
Luego pasé un tiempo mirando las rutas reales de desarrollo y no.
Si construyes a través de DuskVM, estás mucho más cerca del @Dusk side nativo. Los contratos se escriben en Rust, se compilan a WASM y se ejecutan directamente en la L1. Eso te da acceso a los propios modelos de transacción de Dusk y a funciones de privacidad/ZK de nivel más bajo.
DuskEVM se siente como el intercambio contrario.
Obtienes Solidity, Foundry, Hardhat, carteras EVM normales.. básicamente las herramientas que los desarrolladores de Ethereum ya conocen. Pero la ejecución todavía termina liquidándose a través de DuskDS.
Lo que se me aclaró fue que en realidad no se trata de pedirle a los desarrolladores que elijan la VM “mejor”.
Más bien se trata de lo que la aplicación realmente necesita.
Si necesito control directo de la L1, lógica nativa de privacidad o ejecución a nivel de protocolo, DuskVM tiene más sentido.
Si ya tengo una app EVM y solo quiero una forma familiar de entrar en el stack de Dusk, forzar una reescritura en Rust sería una fricción innecesaria.
Así que sí, para mí al principio dos entornos de ejecución se veían redundantes.
Ahora se siente más como si Dusk estuviera intentando que la compatibilidad con desarrolladores y el control nativo no compitan entre sí.
Mismo ecosistema, puntos de entrada muy diferentes.
Me da curiosidad qué lado elegirán los desarrolladores en realidad cuando empiecen a moverse más apps.
$DUSK #dusk
Luego pasé un tiempo mirando las rutas reales de desarrollo y no.
Si construyes a través de DuskVM, estás mucho más cerca del @Dusk side nativo. Los contratos se escriben en Rust, se compilan a WASM y se ejecutan directamente en la L1. Eso te da acceso a los propios modelos de transacción de Dusk y a funciones de privacidad/ZK de nivel más bajo.
DuskEVM se siente como el intercambio contrario.
Obtienes Solidity, Foundry, Hardhat, carteras EVM normales.. básicamente las herramientas que los desarrolladores de Ethereum ya conocen. Pero la ejecución todavía termina liquidándose a través de DuskDS.
Lo que se me aclaró fue que en realidad no se trata de pedirle a los desarrolladores que elijan la VM “mejor”.
Más bien se trata de lo que la aplicación realmente necesita.
Si necesito control directo de la L1, lógica nativa de privacidad o ejecución a nivel de protocolo, DuskVM tiene más sentido.
Si ya tengo una app EVM y solo quiero una forma familiar de entrar en el stack de Dusk, forzar una reescritura en Rust sería una fricción innecesaria.
Así que sí, para mí al principio dos entornos de ejecución se veían redundantes.
Ahora se siente más como si Dusk estuviera intentando que la compatibilidad con desarrolladores y el control nativo no compitan entre sí.
Mismo ecosistema, puntos de entrada muy diferentes.
Me da curiosidad qué lado elegirán los desarrolladores en realidad cuando empiecen a moverse más apps.
$DUSK #dusk