Cuando leí la documentación de desarrollo de Dusk esta vez, lo que realmente me hizo detenerme no fue su funcionalidad de privacidad, sino por qué no se limitan a hacer EVM.
Ahora Dusk conserva tanto DuskVM como DuskEVM: el primero se ejecuta directamente en Dusk L1, orientado a contratos Rust/WASM; el segundo, en cambio, ofrece Solidity, Vyper y una cadena de herramientas de EVM familiar. La respuesta oficial para los desarrolladores, en realidad, es muy directa: los dos caminos no resuelven el mismo problema.
> Esto parece una duplicación, pero en realidad se está cambiando “facilidad de desarrollo” por “capacidad nativa”.
Desde la perspectiva de un desarrollador típico de EVM, DuskEVM sin duda resulta más sencillo. Billeteras, lenguaje y cadena de herramientas son más conocidas, el costo de migración es menor y el equipo no necesita aprender de nuevo una forma de desarrollo totalmente desconocida.
Pero si la aplicación necesita tocar directamente los activos nativos de Dusk, sus capacidades de privacidad, la lógica de cero conocimiento, o un entorno de ejecución más cercano a L1, entonces DuskVM sí tiene sentido.
La documentación oficial distingue claramente estos dos caminos, en lugar de obligar a que todas las aplicaciones sigan una sola ruta.
El problema está justamente aquí.
Tener dos entornos de ejecución implica una mayor complejidad de desarrollo y mantenimiento, y las herramientas del ecosistema no pueden unificarse por completo.
Pero si solo se busca compatibilidad con EVM, Dusk podría estar encerrando su capacidad más especial dentro de un marco de ejecución universal.
Cada vez siento más que el verdadero riesgo que Dusk está asumiendo no es si “quiero o no ser compatible con Ethereum”, sino esto:
**si pueden permitir que los desarrolladores entren primero con cosas conocidas y, cuando de verdad necesiten capacidades nativas, recién entonces estén dispuestos a tomar otro camino.**
Si eres desarrollador, ¿elegirías salir a producción rápidamente con el EVM más familiar, o asumirías el costo de aprendizaje de un nuevo entorno de ejecución para tener privacidad y capacidades nativas? @Dusk
#dusk $DUSK
Ahora Dusk conserva tanto DuskVM como DuskEVM: el primero se ejecuta directamente en Dusk L1, orientado a contratos Rust/WASM; el segundo, en cambio, ofrece Solidity, Vyper y una cadena de herramientas de EVM familiar. La respuesta oficial para los desarrolladores, en realidad, es muy directa: los dos caminos no resuelven el mismo problema.
> Esto parece una duplicación, pero en realidad se está cambiando “facilidad de desarrollo” por “capacidad nativa”.
Desde la perspectiva de un desarrollador típico de EVM, DuskEVM sin duda resulta más sencillo. Billeteras, lenguaje y cadena de herramientas son más conocidas, el costo de migración es menor y el equipo no necesita aprender de nuevo una forma de desarrollo totalmente desconocida.
Pero si la aplicación necesita tocar directamente los activos nativos de Dusk, sus capacidades de privacidad, la lógica de cero conocimiento, o un entorno de ejecución más cercano a L1, entonces DuskVM sí tiene sentido.
La documentación oficial distingue claramente estos dos caminos, en lugar de obligar a que todas las aplicaciones sigan una sola ruta.
El problema está justamente aquí.
Tener dos entornos de ejecución implica una mayor complejidad de desarrollo y mantenimiento, y las herramientas del ecosistema no pueden unificarse por completo.
Pero si solo se busca compatibilidad con EVM, Dusk podría estar encerrando su capacidad más especial dentro de un marco de ejecución universal.
Cada vez siento más que el verdadero riesgo que Dusk está asumiendo no es si “quiero o no ser compatible con Ethereum”, sino esto:
**si pueden permitir que los desarrolladores entren primero con cosas conocidas y, cuando de verdad necesiten capacidades nativas, recién entonces estén dispuestos a tomar otro camino.**
Si eres desarrollador, ¿elegirías salir a producción rápidamente con el EVM más familiar, o asumirías el costo de aprendizaje de un nuevo entorno de ejecución para tener privacidad y capacidades nativas? @Dusk
#dusk $DUSK