Al volver a revisar la arquitectura de Dusk hoy, noté algo que es relativamente fácil de pasar por alto.

¿Por qué aún conservar DuskVM?

Después de todo, ya existe DuskEVM, y los desarrolladores pueden usar directamente herramientas más maduras como Solidity, Vyper, Hardhat y Foundry. Para la mayoría de las aplicaciones, la compatibilidad con EVM por sí sola suele ser suficiente y resulta bastante conveniente.

Pero Dusk no abandonó, por ello, el entorno de ejecución nativo.

DuskVM se ejecuta directamente sobre Dusk L1 y está orientado principalmente a contratos Rust/WASM. Si una aplicación necesita acceder de forma directa a activos a nivel subyacente, al modelo de transacciones, a capacidades de privacidad o a funciones relacionadas con pruebas de conocimiento cero, entonces DuskVM ofrece una opción más a nivel bajo.

Creo que aquí se refleja una toma de decisiones técnica bastante clara por parte de Dusk.

DuskEVM busca resolver “cómo hacer que entren más desarrolladores”; mientras que DuskVM busca “cuando una aplicación realmente necesita capacidades a nivel bajo, ¿se puede seguir avanzando hacia abajo?”.

Estos dos enfoques no son excluyentes.

Para DeFi o aplicaciones tokenizadas comunes, es posible que EVM ya sea suficiente; pero si en el futuro el mercado financiero presenta reglas de activos más complejas, lógica de privacidad y necesidades de liquidación, entonces los desarrolladores necesitarán algo más que compatibilidad.

Así que, al observar ahora el doble entorno de ejecución de Dusk, prefiero interpretarlo como un diseño de infraestructura a largo plazo, y no simplemente como agregar otro EVM.

Lo verdaderamente digno de observar quizá sea cuántas aplicaciones comenzarán, en el futuro, a necesitar esas capacidades a nivel bajo que ofrece DuskVM.#dusk $DUSK @Dusk
¿Crees que el doble entorno de ejecución de Dusk es necesario?