#dusk $DUSK Últimamente he estado leyendo el libro blanco de @Dusk y he notado algo que casi nadie comenta: tiene dos máquinas virtuales, no una.
Una se llama DuskEVM, corre Solidity y es totalmente compatible con el conjunto de herramientas de Ethereum; la otra se llama DuskVM, corre WASM compilado desde Rust y se ejecuta directamente en la L1.
Al principio pensé que era redundante: ¿no bastaría con hacer una sola? Pero luego lo entendí: estas dos cosas están pensadas para personas completamente distintas.
DuskEVM está para desarrolladores. Si llevas tres años escribiendo contratos en Ethereum, tu equipo ya domina Solidity y usa herramientas como Hardhat, entonces simplemente lo adaptas: no tienes que aprender de nuevo. Esta capa resuelve el costo de la migración; en pocas palabras, reduce la barrera de entrada.
DuskVM resuelve otra cosa. Se basa en Wasmtime, un runtime preparado específicamente para escenarios que requieren privacidad y pruebas de conocimiento cero (zero-knowledge). Implementar esta lógica con el conjunto de instrucciones de EVM es muy difícil y el rendimiento no aguanta. Así que Dusk hace que esa parte del código corra directamente en la L1, evitando el “encapsulado” de la capa de EVM.
Por eso su división de trabajo es así: la lógica de aplicaciones habituales va por la ruta EVM, buscando ecosistema y mano de obra; lo verdaderamente relacionado con computación de privacidad y la base de los activos va por la ruta WASM, buscando capacidad y eficiencia. Ambas rutas comparten la misma capa de liquidación.
Creo que este enfoque es más pragmático que el típico “de todo un poco”. Muchas cadenas en el mercado anuncian que son compatibles con EVM y también soportan privacidad, pero en la práctica meten funciones de privacidad a la fuerza dentro de EVM. Y el resultado es que ninguno de los dos extremos queda bien. Dusk reconoce que estas dos cosas, en realidad, no deberían hacerse con el mismo conjunto de herramientas.
Por supuesto, el costo es mantener dos máquinas virtuales, lo que duplica el trabajo de ingeniería; también hay que hacer dos juegos de documentación y de cadena de herramientas. Para los desarrolladores, además hay un costo extra de elección: qué escenarios usar con cuál. Debe haber alguien que lo explique claramente. Recomiendo que Dusk publique una guía de selección bien definida, idealmente con una comparación real de rendimiento entre ambos lados.
Entonces, ¿ustedes qué opinan? ¿Que una cadena mantenga dos máquinas virtuales a la vez es una división inteligente del trabajo o una dispersión de recursos? Nos vemos en la sección de comentarios.
Una se llama DuskEVM, corre Solidity y es totalmente compatible con el conjunto de herramientas de Ethereum; la otra se llama DuskVM, corre WASM compilado desde Rust y se ejecuta directamente en la L1.
Al principio pensé que era redundante: ¿no bastaría con hacer una sola? Pero luego lo entendí: estas dos cosas están pensadas para personas completamente distintas.
DuskEVM está para desarrolladores. Si llevas tres años escribiendo contratos en Ethereum, tu equipo ya domina Solidity y usa herramientas como Hardhat, entonces simplemente lo adaptas: no tienes que aprender de nuevo. Esta capa resuelve el costo de la migración; en pocas palabras, reduce la barrera de entrada.
DuskVM resuelve otra cosa. Se basa en Wasmtime, un runtime preparado específicamente para escenarios que requieren privacidad y pruebas de conocimiento cero (zero-knowledge). Implementar esta lógica con el conjunto de instrucciones de EVM es muy difícil y el rendimiento no aguanta. Así que Dusk hace que esa parte del código corra directamente en la L1, evitando el “encapsulado” de la capa de EVM.
Por eso su división de trabajo es así: la lógica de aplicaciones habituales va por la ruta EVM, buscando ecosistema y mano de obra; lo verdaderamente relacionado con computación de privacidad y la base de los activos va por la ruta WASM, buscando capacidad y eficiencia. Ambas rutas comparten la misma capa de liquidación.
Creo que este enfoque es más pragmático que el típico “de todo un poco”. Muchas cadenas en el mercado anuncian que son compatibles con EVM y también soportan privacidad, pero en la práctica meten funciones de privacidad a la fuerza dentro de EVM. Y el resultado es que ninguno de los dos extremos queda bien. Dusk reconoce que estas dos cosas, en realidad, no deberían hacerse con el mismo conjunto de herramientas.
Por supuesto, el costo es mantener dos máquinas virtuales, lo que duplica el trabajo de ingeniería; también hay que hacer dos juegos de documentación y de cadena de herramientas. Para los desarrolladores, además hay un costo extra de elección: qué escenarios usar con cuál. Debe haber alguien que lo explique claramente. Recomiendo que Dusk publique una guía de selección bien definida, idealmente con una comparación real de rendimiento entre ambos lados.
Entonces, ¿ustedes qué opinan? ¿Que una cadena mantenga dos máquinas virtuales a la vez es una división inteligente del trabajo o una dispersión de recursos? Nos vemos en la sección de comentarios.
