La verdadera ventaja del modelo de ejecución dual de Dusk no es la compatibilidad con EVM. Es una elección arquitectónica.
@Dusk separa el settlement (liquidación) de la ejecución: DuskVM ejecuta contratos Rust/WASM directamente sobre la Dusk L1, mientras que DuskEVM proporciona una ejecución compatible con EVM con settlement y disponibilidad de datos a través de DuskDS.
La consecuencia más profunda es que los desarrolladores pueden elegir dónde reside la lógica de la aplicación, en lugar de obligar a que cada carga de trabajo encaje en un solo modelo de ejecución.
Si un contrato necesita acceso directo a la L1 de los modelos de transacción de Dusk, capacidades de privacidad o de conocimiento cero, DuskVM es la vía nativa. Si la prioridad es Solidity, las carteras existentes y las herramientas de Ethereum, DuskEVM reduce la barrera de migración. Dusk presenta explícitamente las dos rutas como opciones basadas en los requisitos de la aplicación.
Pero esa flexibilidad plantea una pregunta arquitectónica que encuentro más interesante que la compatibilidad:
¿Dónde debería vivir un invariante?
En mi opinión, las reglas vinculadas únicamente a un entorno de ejecución pueden permanecer locales dentro de ese entorno. Las reglas que abarcan distintos caminos de ejecución o que dependen del settlement requieren una propiedad explícita y límites de coordinación.
Esa distinción importa porque las capas de Dusk no son intercambiables. DuskDS proporciona consenso, finalidad, settlement y disponibilidad de datos, mientras que DuskVM y DuskEVM proporcionan entornos de ejecución diferentes.
El puente hace que el límite sea concreto. En el flujo de retiro (withdrawal) de la DuskEVM Testnet documentado, un retiro se inicia en DuskEVM, luego se prueba y se finaliza en Dusk L1. El flujo, por lo tanto, cruza capas de ejecución en lugar de comportarse como una operación monolítica.
Mi conclusión es que la modularidad no solo reduce la complejidad. Permite a los desarrolladores decidir dónde debe vivir la complejidad.
Para aplicaciones financieras, eso puede ser una ventaja arquitectónica significativa: mantener la lógica específica de la ejecución local mientras se tratan las reglas entre capas (Cross-layer) como restricciones arquitectónicas explícitas.
¿Qué reglas deberían permanecer dentro de un entorno de ejecución y cuáles son lo suficientemente importantes como para aplicarse en toda la arquitectura?
$DUSK #dusk
@Dusk separa el settlement (liquidación) de la ejecución: DuskVM ejecuta contratos Rust/WASM directamente sobre la Dusk L1, mientras que DuskEVM proporciona una ejecución compatible con EVM con settlement y disponibilidad de datos a través de DuskDS.
La consecuencia más profunda es que los desarrolladores pueden elegir dónde reside la lógica de la aplicación, en lugar de obligar a que cada carga de trabajo encaje en un solo modelo de ejecución.
Si un contrato necesita acceso directo a la L1 de los modelos de transacción de Dusk, capacidades de privacidad o de conocimiento cero, DuskVM es la vía nativa. Si la prioridad es Solidity, las carteras existentes y las herramientas de Ethereum, DuskEVM reduce la barrera de migración. Dusk presenta explícitamente las dos rutas como opciones basadas en los requisitos de la aplicación.
Pero esa flexibilidad plantea una pregunta arquitectónica que encuentro más interesante que la compatibilidad:
¿Dónde debería vivir un invariante?
En mi opinión, las reglas vinculadas únicamente a un entorno de ejecución pueden permanecer locales dentro de ese entorno. Las reglas que abarcan distintos caminos de ejecución o que dependen del settlement requieren una propiedad explícita y límites de coordinación.
Esa distinción importa porque las capas de Dusk no son intercambiables. DuskDS proporciona consenso, finalidad, settlement y disponibilidad de datos, mientras que DuskVM y DuskEVM proporcionan entornos de ejecución diferentes.
El puente hace que el límite sea concreto. En el flujo de retiro (withdrawal) de la DuskEVM Testnet documentado, un retiro se inicia en DuskEVM, luego se prueba y se finaliza en Dusk L1. El flujo, por lo tanto, cruza capas de ejecución en lugar de comportarse como una operación monolítica.
Mi conclusión es que la modularidad no solo reduce la complejidad. Permite a los desarrolladores decidir dónde debe vivir la complejidad.
Para aplicaciones financieras, eso puede ser una ventaja arquitectónica significativa: mantener la lógica específica de la ejecución local mientras se tratan las reglas entre capas (Cross-layer) como restricciones arquitectónicas explícitas.
¿Qué reglas deberían permanecer dentro de un entorno de ejecución y cuáles son lo suficientemente importantes como para aplicarse en toda la arquitectura?
$DUSK #dusk
