La primera vez que vi el diagrama de la arquitectura de DUSK, me surgió una duda: ¿por qué se necesitan dos máquinas virtuales? DuskVM ejecuta contratos nativos, mientras que DuskEVM ejecuta contratos compatibles con Ethereum. ¿Acaso no aumenta eso la complejidad? Pero después de investigar a fondo, descubrí que este diseño en realidad busca resolver un problema muy real: el compromiso entre seguridad y rendimiento.
DuskVM es la máquina virtual nativa de DUSK; corre directamente sobre la capa de consenso y puede acceder a todas las funciones subyacentes, como pruebas de conocimiento cero, transacciones de privacidad, el protocolo Phoenix, etc. En cambio, DuskEVM está basado en OP Stack: ejecuta contratos inteligentes de estilo Ethereum, pero el asentamiento final lo realiza DuskDS. La diferencia clave es que los contratos en DuskVM están vinculados a la seguridad del consenso de DUSK, mientras que los contratos en DuskEVM dependen de una capa externa de puente.
Esto trae un reparto de funciones bastante interesante: los activos sensibles (por ejemplo, tokens RWA y activos regulados) deberían colocarse en DuskVM, porque necesitan aprovechar directamente las características de privacidad y cumplimiento de DUSK. Mientras tanto, las aplicaciones DeFi comunes (por ejemplo, DEXs y protocolos de préstamos) pueden colocarse en DuskEVM, porque los desarrolladores solo necesitan migrar el código existente de Ethereum, evitando la molestia de reescribir contratos.
Revisé los comentarios de los desarrolladores: desplegar un clon de Uniswap V2 en DuskEVM requiere modificar solo unas 20 líneas de código (principalmente para adaptar parámetros de red). Pero desarrollar desde cero en DuskVM requeriría cientos de líneas. Además, las transacciones en DuskVM son más rápidas (un bloque en promedio cada 1,5 segundos) y no hay que pagar costos de puente. En la práctica, esto es una decisión entre "eficiencia de desarrollo" y "rendimiento".
Otro punto a considerar es el aislamiento de seguridad. Los datos de DuskVM y DuskEVM están separados físicamente, y los contratos en DuskEVM no pueden acceder directamente al estado de privacidad de DuskVM. Esto evita escenarios como ataques tipo "flash loan" que aprovechen vulnerabilidades de acceso entre capas. En la auditoría de seguridad oficial de DUSK de septiembre de 2025, se puso especial énfasis en probar las llamadas entre VM; se encontró que todas las llamadas deben pasar por una "puerta de arena" (sandbox gateway). Esta puerta verifica los permisos y el tipo del solicitante, para impedir la infiltración de código malicioso. $BTC
Pero yo creo que esta doble arquitectura también tiene riesgos potenciales: si la lógica de puente entre las dos VM tiene alguna vulnerabilidad, podría ser explotada. Por ejemplo, un atacante podría falsificar una llamada de un contrato DuskEVM para consumir los recursos de DuskVM.
#dusk @Dusk $DUSK