Cuando una cadena pública añade compatibilidad con EVM, normalmente asumo que el entorno de ejecución nativo va perdiendo prioridad de forma gradual. Las herramientas de EVM atraen a más desarrolladores, Solidity se convierte en el valor predeterminado y un runtime nativo separado empieza a parecer una carga de mantenimiento que se va relegando en silencio.
Pero la arquitectura actualizada de @Dusk evita deliberadamente ese patrón.
Ahora DuskDS se encarga del procesamiento de liquidación y de la disponibilidad de datos en la base, DuskEVM ejecuta aplicaciones compatibles con EVM, y DuskVM se mantiene en L1 específicamente para contratos de Rust y WASM que requieren acceso directo a la privacidad nativa y a funcionalidades ZK.
Al principio lo leí como una duplicación innecesaria, pero creo que en realidad es lo contrario: está tratando el onboarding de desarrolladores y la capacidad del protocolo como dos problemas separados que no deberían forzarse a estar en el mismo lugar.
DuskEVM se ocupa del lado del onboarding. Los contratos en Solidity, las carteras existentes y las herramientas de Ethereum funcionan aquí sin modificaciones. DuskVM se ocupa de algo distinto: cuando una aplicación necesita el modelo de transacciones nativo de Dusk, funciones de confidencialidad o pruebas ZK, no tiene que traducir todo eso mediante código compatible con EVM. La documentación oficial presenta a DuskVM como un entorno de ejecución WASM que corre de forma nativa en la Dusk L1.
Esto me ayudó a replantearme qué es lo que #dusk realmente está construyendo.
No se trata simplemente de dividir la cadena en capas. Es reconocer algo más específico: el EVM es una puerta de entrada efectiva para la adopción de desarrolladores, pero quizá no sea el lugar adecuado para alojar capacidades que están pensadas para ser nativas del propio protocolo.
Lo que realmente vale la pena observar no es si $DUSK puede operar dos entornos de ejecución a la vez, sino si los desarrolladores elegirán caminos distintos en función de lo que necesiten.
Si la mayor parte del desarrollo se mantiene en el EVM, DuskVM se convertirá en una capacidad que existe pero que se usa poco. Si las aplicaciones nativas de privacidad y los protocolos financieros empiezan a enrutarse por la vía de ejecución nativa porque el EVM no puede cumplir esos requisitos, entonces la complejidad de mantener dos entornos tendrá algún valor.
Pero la arquitectura actualizada de @Dusk evita deliberadamente ese patrón.
Ahora DuskDS se encarga del procesamiento de liquidación y de la disponibilidad de datos en la base, DuskEVM ejecuta aplicaciones compatibles con EVM, y DuskVM se mantiene en L1 específicamente para contratos de Rust y WASM que requieren acceso directo a la privacidad nativa y a funcionalidades ZK.
Al principio lo leí como una duplicación innecesaria, pero creo que en realidad es lo contrario: está tratando el onboarding de desarrolladores y la capacidad del protocolo como dos problemas separados que no deberían forzarse a estar en el mismo lugar.
DuskEVM se ocupa del lado del onboarding. Los contratos en Solidity, las carteras existentes y las herramientas de Ethereum funcionan aquí sin modificaciones. DuskVM se ocupa de algo distinto: cuando una aplicación necesita el modelo de transacciones nativo de Dusk, funciones de confidencialidad o pruebas ZK, no tiene que traducir todo eso mediante código compatible con EVM. La documentación oficial presenta a DuskVM como un entorno de ejecución WASM que corre de forma nativa en la Dusk L1.
Esto me ayudó a replantearme qué es lo que #dusk realmente está construyendo.
No se trata simplemente de dividir la cadena en capas. Es reconocer algo más específico: el EVM es una puerta de entrada efectiva para la adopción de desarrolladores, pero quizá no sea el lugar adecuado para alojar capacidades que están pensadas para ser nativas del propio protocolo.
Lo que realmente vale la pena observar no es si $DUSK puede operar dos entornos de ejecución a la vez, sino si los desarrolladores elegirán caminos distintos en función de lo que necesiten.
Si la mayor parte del desarrollo se mantiene en el EVM, DuskVM se convertirá en una capacidad que existe pero que se usa poco. Si las aplicaciones nativas de privacidad y los protocolos financieros empiezan a enrutarse por la vía de ejecución nativa porque el EVM no puede cumplir esos requisitos, entonces la complejidad de mantener dos entornos tendrá algún valor.
