Mi primo dirige dos talleres separados detrás de su casa: uno para carpintería y otro para soldadura. Una vez le pregunté por qué no construía un solo cobertizo y lo usaba para todo. Me dijo que, en el momento en que intentas hacer que un solo espacio haga bien ambos trabajos, terminas comprometiendo los dos.
Asumí que la capa de ejecución de Dusk funcionaría como la mayoría de las cadenas que había visto: elegir EVM, enviarlo y listo. Esa suposición se vino abajo cuando seguí lo que en realidad es DuskVM.
DuskVM funciona sobre Wasmtime, ejecutando contratos Rust/WASM directamente en la L1 de Dusk: un entorno completamente separado de DuskEVM, no una capa añadida encima de él. Existe específicamente para contratos que necesitan acceso directo a los modelos nativos de transacción de Dusk, a su privacidad y a sus capacidades de conocimiento cero (zero-knowledge). Es decir, las cosas para las que el modelo de ejecución de EVM nunca se diseñó para exponerlas de forma nativa.
Piecrust, el motor que está debajo, reemplazó a RuskVM, que era el RuskVM original de Dusk, específicamente porque RuskVM alcanzó límites de crecimiento del estado y de rendimiento que Dusk necesitaba resolver antes de escalar la tokenización de activos regulados. Las propias notas de ingeniería de Dusk indican que Piecrust supera a RuskVM por más de diez veces: no es una estimación, es una comparación publicada y directa, con funciones host de PLONK, Groth16 y BLS integradas directamente en el runtime.
DuskEVM cubre el otro trabajo por completo: equivalencia total con EVM, herramientas estándar de Solidity, y liquidación a través de DuskDS para desarrolladores que quieren flujos de trabajo familiares sin necesidad de primitivas nativas de privacidad.
La prueba real para DUSK es si mantener estos dos entornos genuinamente separados —en lugar de forzar contratos nativos de privacidad a través de un modelo de ejecución diseñado para otra cosa— realmente compensa a medida que crece la adopción en ambos lados.
¿Tener dos entornos dedicados supera a tener uno solo comprometido, o simplemente significa el doble de mantenimiento para la mitad de la claridad?
#dusk $DUSK @Dusk
Asumí que la capa de ejecución de Dusk funcionaría como la mayoría de las cadenas que había visto: elegir EVM, enviarlo y listo. Esa suposición se vino abajo cuando seguí lo que en realidad es DuskVM.
DuskVM funciona sobre Wasmtime, ejecutando contratos Rust/WASM directamente en la L1 de Dusk: un entorno completamente separado de DuskEVM, no una capa añadida encima de él. Existe específicamente para contratos que necesitan acceso directo a los modelos nativos de transacción de Dusk, a su privacidad y a sus capacidades de conocimiento cero (zero-knowledge). Es decir, las cosas para las que el modelo de ejecución de EVM nunca se diseñó para exponerlas de forma nativa.
Piecrust, el motor que está debajo, reemplazó a RuskVM, que era el RuskVM original de Dusk, específicamente porque RuskVM alcanzó límites de crecimiento del estado y de rendimiento que Dusk necesitaba resolver antes de escalar la tokenización de activos regulados. Las propias notas de ingeniería de Dusk indican que Piecrust supera a RuskVM por más de diez veces: no es una estimación, es una comparación publicada y directa, con funciones host de PLONK, Groth16 y BLS integradas directamente en el runtime.
DuskEVM cubre el otro trabajo por completo: equivalencia total con EVM, herramientas estándar de Solidity, y liquidación a través de DuskDS para desarrolladores que quieren flujos de trabajo familiares sin necesidad de primitivas nativas de privacidad.
La prueba real para DUSK es si mantener estos dos entornos genuinamente separados —en lugar de forzar contratos nativos de privacidad a través de un modelo de ejecución diseñado para otra cosa— realmente compensa a medida que crece la adopción en ambos lados.
¿Tener dos entornos dedicados supera a tener uno solo comprometido, o simplemente significa el doble de mantenimiento para la mitad de la claridad?
#dusk $DUSK @Dusk