Hoy estaba mirando la arquitectura de Dusk y una cosa me cobró más sentido después de profundizar:
Dusk no obliga a todos los desarrolladores al mismo entorno de ejecución.
En su lugar, separa la liquidación de la ejecución.
En la base está DuskDS, que se encarga del consenso, la finalidad y la disponibilidad de datos.
Luego, hay dos caminos diferentes por encima.
DuskVM ejecuta contratos Rust/WASM directamente en la Dusk L1.
DuskEVM ofrece a los desarrolladores un entorno compatible con EVM para Solidity y Vyper, mientras que la liquidación sigue realizándose mediante DuskDS.
Al principio, tener dos entornos me pareció una complejidad innecesaria.
Pero la razón se hizo más clara.
Una aplicación que necesita acceso directo a los modelos nativos de transacciones de Dusk, capacidades de privacidad o de conocimiento cero puede usar DuskVM.
Un equipo que ya vive dentro del ecosistema de desarrolladores de Ethereum puede usar DuskEVM, con herramientas familiares y Solidity, en lugar de reconstruir por completo su flujo de trabajo de desarrollo.
Ese es un intercambio interesante.
Dusk en realidad no le está pidiendo a los desarrolladores que elijan entre infraestructura nativa y compatibilidad con EVM.
Está intentando conservar ambas cosas poniendo la liquidación debajo de ellas.
La pregunta que aún me queda es la importante:
¿Tener ambos caminos de ejecución atraerá realmente a suficientes creadores diferentes como para justificar la complejidad arquitectónica adicional?
Para mí, eso es algo más interesante de observar que simplemente llamar a Dusk “compatible con EVM”.
#dusk $DUSK @Dusk
Dusk no obliga a todos los desarrolladores al mismo entorno de ejecución.
En su lugar, separa la liquidación de la ejecución.
En la base está DuskDS, que se encarga del consenso, la finalidad y la disponibilidad de datos.
Luego, hay dos caminos diferentes por encima.
DuskVM ejecuta contratos Rust/WASM directamente en la Dusk L1.
DuskEVM ofrece a los desarrolladores un entorno compatible con EVM para Solidity y Vyper, mientras que la liquidación sigue realizándose mediante DuskDS.
Al principio, tener dos entornos me pareció una complejidad innecesaria.
Pero la razón se hizo más clara.
Una aplicación que necesita acceso directo a los modelos nativos de transacciones de Dusk, capacidades de privacidad o de conocimiento cero puede usar DuskVM.
Un equipo que ya vive dentro del ecosistema de desarrolladores de Ethereum puede usar DuskEVM, con herramientas familiares y Solidity, en lugar de reconstruir por completo su flujo de trabajo de desarrollo.
Ese es un intercambio interesante.
Dusk en realidad no le está pidiendo a los desarrolladores que elijan entre infraestructura nativa y compatibilidad con EVM.
Está intentando conservar ambas cosas poniendo la liquidación debajo de ellas.
La pregunta que aún me queda es la importante:
¿Tener ambos caminos de ejecución atraerá realmente a suficientes creadores diferentes como para justificar la complejidad arquitectónica adicional?
Para mí, eso es algo más interesante de observar que simplemente llamar a Dusk “compatible con EVM”.
#dusk $DUSK @Dusk