Anoche terminé de leer la documentación de arquitectura de @Dusk y hay una contradicción que no se puede evitar: ¿coexisten dos rutas de ejecución para agradar a ambos lados, o existe una división de trabajo claramente definida?
La documentación oficial es muy clara en su planteamiento. DuskDS, como capa de liquidación y disponibilidad de datos, sobre la cual Dusk ofrece dos rutas de contratos inteligentes: DuskVM (antes llamado Piecrust) ejecuta contratos en Rust/WASM, directamente en Dusk L1; mientras que DuskEVM es un entorno de ejecución equivalente a EVM basado en OP Stack, que completa la liquidación y la disponibilidad de datos a través de DuskDS.
Esta separación de funciones no es una duplicación del trabajo.
DuskVM está orientado a lógica de negocio a nivel de protocolo. Abarca la lógica de liquidación de privacidad de dos modelos de transacción, Phoenix/Moonlight. Los contratos se compilan a WASM en lugar de bytecode de EVM, por lo que se adaptan de forma natural al sistema de pruebas de conocimiento cero. Cuando se necesita invocar capacidades de privacidad a nivel de fondo, se utiliza DuskVM.
DuskEVM, en cambio, es una “capa de compatibilidad”. Los desarrolladores acostumbrados a Solidity no necesitan reestructurar su código: pueden usar directamente herramientas familiares como Hardhat y Foundry, y también integrar sin problemas MetaMask. Tras la ejecución, los datos de la transacción se envían a DuskDS en forma de blob mediante el batcher para el registro probatorio final.
La división de funciones en sí es razonable: la privacidad a nivel de fondo y la lógica de cumplimiento corren en el entorno nativo, mientras que la capa superior de compatibilidad con EVM funciona como punto de entrada de flujo; cada parte cumple su rol. Pero que sea razonable no significa que ya haya sido validado.
El punto clave es: ¿cuántas aplicaciones se despliegan en cada tipo de entorno? Según información pública, en la red de pruebas de DuskEVM ya existen 17 proyectos DeFi desplegados, pero en cuanto al número de aplicaciones, su proporción y tipos en el entorno nativo de DuskVM, no se ven datos de estadísticas claras. Sin datos de distribución de aplicaciones, “la división razonable” todavía queda en el nivel del diseño de arquitectura. La lógica arquitectónica se puede inferir, pero el impacto en el ecosistema solo puede responderse con datos.
#dusk $DUSK
La documentación oficial es muy clara en su planteamiento. DuskDS, como capa de liquidación y disponibilidad de datos, sobre la cual Dusk ofrece dos rutas de contratos inteligentes: DuskVM (antes llamado Piecrust) ejecuta contratos en Rust/WASM, directamente en Dusk L1; mientras que DuskEVM es un entorno de ejecución equivalente a EVM basado en OP Stack, que completa la liquidación y la disponibilidad de datos a través de DuskDS.
Esta separación de funciones no es una duplicación del trabajo.
DuskVM está orientado a lógica de negocio a nivel de protocolo. Abarca la lógica de liquidación de privacidad de dos modelos de transacción, Phoenix/Moonlight. Los contratos se compilan a WASM en lugar de bytecode de EVM, por lo que se adaptan de forma natural al sistema de pruebas de conocimiento cero. Cuando se necesita invocar capacidades de privacidad a nivel de fondo, se utiliza DuskVM.
DuskEVM, en cambio, es una “capa de compatibilidad”. Los desarrolladores acostumbrados a Solidity no necesitan reestructurar su código: pueden usar directamente herramientas familiares como Hardhat y Foundry, y también integrar sin problemas MetaMask. Tras la ejecución, los datos de la transacción se envían a DuskDS en forma de blob mediante el batcher para el registro probatorio final.
La división de funciones en sí es razonable: la privacidad a nivel de fondo y la lógica de cumplimiento corren en el entorno nativo, mientras que la capa superior de compatibilidad con EVM funciona como punto de entrada de flujo; cada parte cumple su rol. Pero que sea razonable no significa que ya haya sido validado.
El punto clave es: ¿cuántas aplicaciones se despliegan en cada tipo de entorno? Según información pública, en la red de pruebas de DuskEVM ya existen 17 proyectos DeFi desplegados, pero en cuanto al número de aplicaciones, su proporción y tipos en el entorno nativo de DuskVM, no se ven datos de estadísticas claras. Sin datos de distribución de aplicaciones, “la división razonable” todavía queda en el nivel del diseño de arquitectura. La lógica arquitectónica se puede inferir, pero el impacto en el ecosistema solo puede responderse con datos.
#dusk $DUSK
