Estos días he redibujado los Core Components de @Dusk y recién así logré separar los tres nombres: DuskVM, DuskEVM y DuskDS. Al principio yo también creía que era simplemente “una cadena compatible con dos tipos de máquinas virtuales”, pero en realidad el reparto se parece más a tres capas: DuskDS se encarga del consenso, la finalidad y la disponibilidad de datos; DuskVM permite que los contratos Rust/WASM se ejecuten directamente en L1; y DuskEVM es un entorno de ejecución equivalente a EVM basado en OP Stack, delegando la liquidación y la publicación de datos en DuskDS.
Esto significa que los desarrolladores no tienen que elegir “a ciegas” entre dos opciones. Si ya existen contratos Solidity, y se cuenta con carteras y toolchains basadas en EVM, ir por DuskEVM reduce los costos; pero si se quiere tocar directamente activos de L1, el modelo de privacidad de Phoenix, capacidades de conocimiento cero o un control de protocolo más de bajo nivel, entonces DuskVM es la vía nativa. Las dos rutas comparten la base de liquidación, pero eso no implica que las funcionalidades y las suposiciones de seguridad sean idénticas.
Me preocupa bastante la idea de que “compatible con EVM = la ecología se trae automáticamente”. La compatibilidad solo reduce el umbral de despliegue; no sustituye la conexión de la wallet, un RPC estable, indexadores, liquidez y usuarios reales. Y al revés: enfocarse solo en lo nativo de Rust/ZK tampoco alcanza; las herramientas pueden resultar demasiado ásperas, y los desarrolladores no van a reescribir todos sus productos por pureza técnica.
Por eso observo los avances técnicos de $DUSK y veo que van a desglosar las métricas: si DuskEVM tiene aplicaciones Solidity de terceros; si DuskVM tiene contratos no oficiales; y si las rutas que llevan la liquidación a DuskDS son estables. Si la barrera de #dusk se sostiene, debería ser “quienes conocen las herramientas pueden entrar, y cuando se necesita privacidad aún se puede bajar más”, no tres nombres nuevos apilados juntos. ¿Ustedes elegirán primero la compatibilidad o las capacidades nativas?
Esto significa que los desarrolladores no tienen que elegir “a ciegas” entre dos opciones. Si ya existen contratos Solidity, y se cuenta con carteras y toolchains basadas en EVM, ir por DuskEVM reduce los costos; pero si se quiere tocar directamente activos de L1, el modelo de privacidad de Phoenix, capacidades de conocimiento cero o un control de protocolo más de bajo nivel, entonces DuskVM es la vía nativa. Las dos rutas comparten la base de liquidación, pero eso no implica que las funcionalidades y las suposiciones de seguridad sean idénticas.
Me preocupa bastante la idea de que “compatible con EVM = la ecología se trae automáticamente”. La compatibilidad solo reduce el umbral de despliegue; no sustituye la conexión de la wallet, un RPC estable, indexadores, liquidez y usuarios reales. Y al revés: enfocarse solo en lo nativo de Rust/ZK tampoco alcanza; las herramientas pueden resultar demasiado ásperas, y los desarrolladores no van a reescribir todos sus productos por pureza técnica.
Por eso observo los avances técnicos de $DUSK y veo que van a desglosar las métricas: si DuskEVM tiene aplicaciones Solidity de terceros; si DuskVM tiene contratos no oficiales; y si las rutas que llevan la liquidación a DuskDS son estables. Si la barrera de #dusk se sostiene, debería ser “quienes conocen las herramientas pueden entrar, y cuando se necesita privacidad aún se puede bajar más”, no tres nombres nuevos apilados juntos. ¿Ustedes elegirán primero la compatibilidad o las capacidades nativas?
