#dusk $DUSK @Dusk
Seguí cómo DuskVM y DuskEVM dividen el trabajo en Dusk: ambos ejecutan contratos, pero claramente no son intercambiables.
DuskVM ejecuta contratos Rust/WASM, construidos sobre Wasmtime, directamente en el L1 de Dusk. es la vía diseñada para contratos que necesitan acceso directo a los propios modelos de transacción de Dusk, funciones de privacidad o capacidades de conocimiento cero: las funciones de host compatibles con ZK de Piecrust (PLONK, Groth16, BLS) viven aquí específicamente.
DuskEVM se ejecuta en otro lugar por completo. es un entorno equivalente a EVM basado en OP Stack: el ID de cadena de testnet está confirmado como 745 en la propia documentación de Dusk. esto permite a los desarrolladores desplegar contratos estándar de Solidity usando MetaMask, Hardhat o Foundry, mientras se liquidan y publican los datos de vuelta a través de DuskDS como blobs, mediante un secuenciador y un batcher en vez de ejecutarse de forma independiente.
Aislé lo que los separa más allá solo del lenguaje. los contratos de DuskVM obtienen privacidad y primitivas de ZK de forma nativa, en la capa de ejecución. los contratos de DuskEVM obtienen compatibilidad total con herramientas y los usuarios pagan gas en DUSK allí también, pero el flujo pasa por una capa que se liquida en otro lugar en vez de ejecutarse de forma nativa junto con los propios modelos de transacción de Dusk.
ambos se liquidan a través de la misma base — DuskDS — y ambos, en última instancia, pagan gas en DUSK. ninguno reemplaza al otro; cada uno existe porque el otro realmente no puede cubrir bien su trabajo específico.
así que la elección real para un creador no es “cuál es mejor”. es si el contrato necesita ejecución nativa con privacidad o herramientas EVM familiares y verificables por el ID de cadena — y Dusk construyó dos carriles separados en lugar de forzar que un solo entorno haga ambas cosas.
¿Mantener dos entornos de ejecución verdaderamente separados sirve mejor a los creadores que elegir uno e optimizarlo por completo?
Seguí cómo DuskVM y DuskEVM dividen el trabajo en Dusk: ambos ejecutan contratos, pero claramente no son intercambiables.
DuskVM ejecuta contratos Rust/WASM, construidos sobre Wasmtime, directamente en el L1 de Dusk. es la vía diseñada para contratos que necesitan acceso directo a los propios modelos de transacción de Dusk, funciones de privacidad o capacidades de conocimiento cero: las funciones de host compatibles con ZK de Piecrust (PLONK, Groth16, BLS) viven aquí específicamente.
DuskEVM se ejecuta en otro lugar por completo. es un entorno equivalente a EVM basado en OP Stack: el ID de cadena de testnet está confirmado como 745 en la propia documentación de Dusk. esto permite a los desarrolladores desplegar contratos estándar de Solidity usando MetaMask, Hardhat o Foundry, mientras se liquidan y publican los datos de vuelta a través de DuskDS como blobs, mediante un secuenciador y un batcher en vez de ejecutarse de forma independiente.
Aislé lo que los separa más allá solo del lenguaje. los contratos de DuskVM obtienen privacidad y primitivas de ZK de forma nativa, en la capa de ejecución. los contratos de DuskEVM obtienen compatibilidad total con herramientas y los usuarios pagan gas en DUSK allí también, pero el flujo pasa por una capa que se liquida en otro lugar en vez de ejecutarse de forma nativa junto con los propios modelos de transacción de Dusk.
ambos se liquidan a través de la misma base — DuskDS — y ambos, en última instancia, pagan gas en DUSK. ninguno reemplaza al otro; cada uno existe porque el otro realmente no puede cubrir bien su trabajo específico.
así que la elección real para un creador no es “cuál es mejor”. es si el contrato necesita ejecución nativa con privacidad o herramientas EVM familiares y verificables por el ID de cadena — y Dusk construyó dos carriles separados en lugar de forzar que un solo entorno haga ambas cosas.
¿Mantener dos entornos de ejecución verdaderamente separados sirve mejor a los creadores que elegir uno e optimizarlo por completo?
