Construir una blockchain como un único stack monolítico es más sencillo de explicar y más fácil de entregar. El consenso, la ejecución y el settlement viven en la misma ruta de código, y un cambio en cualquier parte afecta a todo. Dusk Network eligió el camino más difícil en lugar de eso, separando DuskDS, la capa de consenso y settlement, de los entornos que realmente ejecutan contratos inteligentes.
DuskDS gestiona la Atentación Sucinta (Succinct Attestation), la finality, la disponibilidad de datos y los modelos de transacciones Moonlight y Phoenix. No ejecuta lógica de aplicaciones por sí misma. Ese trabajo corresponde a DuskVM, un entorno basado en Wasmtime para contratos en Rust y WASM con acceso directo a las herramientas nativas de privacidad de Dusk, o a DuskEVM, un entorno de ejecución OP Stack para aplicaciones en Solidity que realiza el settlement de vuelta a través de DuskDS con DUSK como gas. Rusk, la implementación del nodo, une todo y expone las interfaces que realmente usan las wallets y los indexers.
¿Por qué meterse en el trabajo? Porque las garantías de settlement y la experiencia del desarrollador cambian a ritmos completamente distintos. Las instituciones que emiten valores tokenizados necesitan reglas de finality y controles de acceso que permanezcan estables durante años. Los desarrolladores que construyen aplicaciones necesitan herramientas que sigan mejorando, nuevos SDKs, mejor compatibilidad con EVM, iteraciones más rápidas. Conectar esas dos necesidades en una sola capa te hace o congelar la innovación para proteger la estabilidad, o romper la estabilidad persiguiendo la comodidad del desarrollador. Separarlas permite que DuskDS se mantenga aburrido y confiable mientras DuskVM y DuskEVM evolucionan por debajo, o por encima, según cómo lo mires.
Es una decisión que intercambia simplicidad a corto plazo por flexibilidad a largo plazo, y seis años dentro de este proyecto, creo que ese intercambio empieza a dar frutos, incluso si hizo que la arquitectura inicial fuera más difícil de explicar a los recién llegados. Lo que todavía quiero ver probado es el costo de coordinación cuando DuskDS en sí mismo necesita cambiar, ya que una capa de settlement compartida por dos entornos de ejecución no puede evolucionar con tanta libertad como cualquiera de ellos podría por sí solo, y esa restricción solo se vuelve más visible a medida que ambos entornos llevan más valor real#dusk $DUSK @Dusk
DuskDS gestiona la Atentación Sucinta (Succinct Attestation), la finality, la disponibilidad de datos y los modelos de transacciones Moonlight y Phoenix. No ejecuta lógica de aplicaciones por sí misma. Ese trabajo corresponde a DuskVM, un entorno basado en Wasmtime para contratos en Rust y WASM con acceso directo a las herramientas nativas de privacidad de Dusk, o a DuskEVM, un entorno de ejecución OP Stack para aplicaciones en Solidity que realiza el settlement de vuelta a través de DuskDS con DUSK como gas. Rusk, la implementación del nodo, une todo y expone las interfaces que realmente usan las wallets y los indexers.
¿Por qué meterse en el trabajo? Porque las garantías de settlement y la experiencia del desarrollador cambian a ritmos completamente distintos. Las instituciones que emiten valores tokenizados necesitan reglas de finality y controles de acceso que permanezcan estables durante años. Los desarrolladores que construyen aplicaciones necesitan herramientas que sigan mejorando, nuevos SDKs, mejor compatibilidad con EVM, iteraciones más rápidas. Conectar esas dos necesidades en una sola capa te hace o congelar la innovación para proteger la estabilidad, o romper la estabilidad persiguiendo la comodidad del desarrollador. Separarlas permite que DuskDS se mantenga aburrido y confiable mientras DuskVM y DuskEVM evolucionan por debajo, o por encima, según cómo lo mires.
Es una decisión que intercambia simplicidad a corto plazo por flexibilidad a largo plazo, y seis años dentro de este proyecto, creo que ese intercambio empieza a dar frutos, incluso si hizo que la arquitectura inicial fuera más difícil de explicar a los recién llegados. Lo que todavía quiero ver probado es el costo de coordinación cuando DuskDS en sí mismo necesita cambiar, ya que una capa de settlement compartida por dos entornos de ejecución no puede evolucionar con tanta libertad como cualquiera de ellos podría por sí solo, y esa restricción solo se vuelve más visible a medida que ambos entornos llevan más valor real#dusk $DUSK @Dusk