Agregar soporte para EVM suele presentarse como una victoria de compatibilidad: más monederos, más herramientas, más desarrolladores de Solidity. Pero ese encuadre oculta una pregunta arquitectónica más grande: ¿la familiaridad del desarrollador también debe determinar dónde se asienta un sistema financiero?
El stack actual de Dusk separa esas decisiones. DuskEVM ofrece ejecución compatible con EVM liquidada a través de DuskDS, mientras que DuskVM ejecuta contratos Rust/WASM directamente sobre la L1. DuskDS sigue siendo la base de liquidación y de disponibilidad de datos. Eso hace que la compatibilidad con EVM sea una opción de ejecución en lugar de la definición de la capa base.
La implicación es más interesante que “Dusk admite dos VMs”. Una aplicación regulada puede elegir herramientas EVM familiares sin exigir que la capa de liquidación en sí se vuelva con forma de EVM.
Mientras tanto, los flujos de trabajo que necesitan acceso directo a la L1 a los modelos de transacción de Dusk, capacidades de privacidad o de conocimiento cero pueden mantenerse nativos.
El costo es la coordinación. Dos vías de ejecución no hacen que sus capacidades sean idénticas, y los creadores aún deben decidir qué garantías pertenecen a la ejecución y cuáles deben quedar ancladas en la liquidación.
Así que la verdadera prueba de modularidad no es cuántos entornos admite Dusk. Es si la ejecución puede variar sin fragmentar las suposiciones de liquidación que hay debajo.
@Dusk_Foundation $DUSK #dusk $BTW $ROBO
El stack actual de Dusk separa esas decisiones. DuskEVM ofrece ejecución compatible con EVM liquidada a través de DuskDS, mientras que DuskVM ejecuta contratos Rust/WASM directamente sobre la L1. DuskDS sigue siendo la base de liquidación y de disponibilidad de datos. Eso hace que la compatibilidad con EVM sea una opción de ejecución en lugar de la definición de la capa base.
La implicación es más interesante que “Dusk admite dos VMs”. Una aplicación regulada puede elegir herramientas EVM familiares sin exigir que la capa de liquidación en sí se vuelva con forma de EVM.
Mientras tanto, los flujos de trabajo que necesitan acceso directo a la L1 a los modelos de transacción de Dusk, capacidades de privacidad o de conocimiento cero pueden mantenerse nativos.
El costo es la coordinación. Dos vías de ejecución no hacen que sus capacidades sean idénticas, y los creadores aún deben decidir qué garantías pertenecen a la ejecución y cuáles deben quedar ancladas en la liquidación.
Así que la verdadera prueba de modularidad no es cuántos entornos admite Dusk. Es si la ejecución puede variar sin fragmentar las suposiciones de liquidación que hay debajo.
@Dusk_Foundation $DUSK #dusk $BTW $ROBO