#dusk $DUSK @Dusk
Toda la pila de Dusk está construida de forma modular. DuskDS es la capa de asentamiento y disponibilidad de datos: ejecuta el consenso de Attestation Succinct, gestiona el staking y mantiene el activo base de DUSK. DuskEVM es una capa de ejecución separada, compatible con Solidity, construida sobre OP Stack (un secuenciador que ejecuta op-geth, además de un batcher que publica los datos de transacciones de vuelta a DuskDS como blobs), y se asienta de nuevo en DuskDS en lugar de depender de su propia seguridad independiente. DuskVM es un entorno nativo de ejecución aún en evolución para contratos Rust/WASM, pensado para aplicaciones que necesitan privacidad nativa o integración a nivel de protocolo. Piecrust es el runtime WASM (construido sobre Wasmer) que originalmente estaba incrustado en DuskDS y ahora se está extrayendo hacia DuskVM. La red funciona con Kadcast: un protocolo de difusión estructurado tipo Kademlia en lugar de gossip aleatorio.
La lógica detrás de esta arquitectura es que "un solo entorno de ejecución para todo" no funciona para una cadena que intenta servir a la vez componibilidad estilo DeFi y emisión de activos regulados. En vez de forzar a los desarrolladores de Solidity a un entorno nativo Rust/WASM, o forzar a las aplicaciones de privacidad nativa a las limitaciones del EVM, el asentamiento y el consenso se asientan sobre una capa base compartida mientras que los entornos de ejecución se especializan por encima. Kadcast encaja con la misma lógica: la difusión estructurada significa más ancho de banda y latencia predecibles, algo que importa más para una cadena que afirma tener finalidad determinista que para una que trata la finalidad de manera probabilística.
Separar la ejecución del asentamiento también significa que las garantías de DuskEVM solo son tan sólidas como el puente y el mecanismo de batching que la conectan de vuelta a DuskDS. A medida que DuskVM madure junto con DuskEVM, la red termina ejecutando tres superficies de ejecución sobre una sola capa de asentamiento. ¿Ese desdoblamiento realmente reduce la fricción de integración para los desarrolladores, o simplemente traslada la complejidad de "qué VM uso" a "qué capa realmente mantiene mi garantía"?
Toda la pila de Dusk está construida de forma modular. DuskDS es la capa de asentamiento y disponibilidad de datos: ejecuta el consenso de Attestation Succinct, gestiona el staking y mantiene el activo base de DUSK. DuskEVM es una capa de ejecución separada, compatible con Solidity, construida sobre OP Stack (un secuenciador que ejecuta op-geth, además de un batcher que publica los datos de transacciones de vuelta a DuskDS como blobs), y se asienta de nuevo en DuskDS en lugar de depender de su propia seguridad independiente. DuskVM es un entorno nativo de ejecución aún en evolución para contratos Rust/WASM, pensado para aplicaciones que necesitan privacidad nativa o integración a nivel de protocolo. Piecrust es el runtime WASM (construido sobre Wasmer) que originalmente estaba incrustado en DuskDS y ahora se está extrayendo hacia DuskVM. La red funciona con Kadcast: un protocolo de difusión estructurado tipo Kademlia en lugar de gossip aleatorio.
La lógica detrás de esta arquitectura es que "un solo entorno de ejecución para todo" no funciona para una cadena que intenta servir a la vez componibilidad estilo DeFi y emisión de activos regulados. En vez de forzar a los desarrolladores de Solidity a un entorno nativo Rust/WASM, o forzar a las aplicaciones de privacidad nativa a las limitaciones del EVM, el asentamiento y el consenso se asientan sobre una capa base compartida mientras que los entornos de ejecución se especializan por encima. Kadcast encaja con la misma lógica: la difusión estructurada significa más ancho de banda y latencia predecibles, algo que importa más para una cadena que afirma tener finalidad determinista que para una que trata la finalidad de manera probabilística.
Separar la ejecución del asentamiento también significa que las garantías de DuskEVM solo son tan sólidas como el puente y el mecanismo de batching que la conectan de vuelta a DuskDS. A medida que DuskVM madure junto con DuskEVM, la red termina ejecutando tres superficies de ejecución sobre una sola capa de asentamiento. ¿Ese desdoblamiento realmente reduce la fricción de integración para los desarrolladores, o simplemente traslada la complejidad de "qué VM uso" a "qué capa realmente mantiene mi garantía"?