Una vez que existió DuskEVM, Dusk Network podría haber planteado un mensaje más sencillo: un único entorno de ejecución, Solidity para todos, y listo. En cambio, la documentación es explícita en que el desarrollo nativo de Dusk —es decir, contratos en Rust compilados a WASM y ejecutados por DuskVM— sigue siendo la ruta recomendada cada vez que una aplicación necesita control a nivel de protocolo, modelos de transacción personalizados o capacidades de conocimiento cero (zero-knowledge) que se sitúan cerca de la capa base. Me parece una decisión interesante de defender, porque mantener dos rutas de ejecución es más costoso de construir y de explicar que mantener solo una.
Parece que la lógica es que DuskEVM y DuskVM están optimizados para distintos tipos de clientes, más que compitiendo por el mismo. Un equipo que porta un protocolo DeFi existente de Ethereum quiere herramientas familiares, auditorías ya existentes y wallets que ya funcionan, para eso está DuskEVM. Un equipo que construye lógica de liquidación de valores con transferencias limitadas, distribución de dividendos o reglas de cumplimiento integradas directamente en un contrato está más cerca de lo que Zedger y los contratos nativos de DuskVM fueron diseñados desde el principio, ya que ese modelo híbrido de transacciones fue creado específicamente para este tipo de contabilidad de token de seguridad, en lugar de adaptarse a posteriori desde un patrón de propósito general.
No estoy del todo convencido de que este enfoque de doble vía evite fragmentar la base de desarrolladores de Dusk Network y el esfuerzo de documentación entre dos audiencias, en vez de concentrarlo detrás de una sola. Dos entornos de ejecución significan dos conjuntos de herramientas que mantener, dos modelos mentales para las nuevas personas contribuidoras y dos respuestas a la pregunta simple de dónde realmente debería construirse una nueva aplicación. Entiendo la apuesta, porque reducirse a una sola ruta tan pronto habría dejado en silencio a un público fuera. Si Dusk Network se mantiene lo bastante grande como para apoyar adecuadamente ambas rutas durante los próximos años es algo que vale la pena vigilar.
#dusk $DUSK @Dusk
Parece que la lógica es que DuskEVM y DuskVM están optimizados para distintos tipos de clientes, más que compitiendo por el mismo. Un equipo que porta un protocolo DeFi existente de Ethereum quiere herramientas familiares, auditorías ya existentes y wallets que ya funcionan, para eso está DuskEVM. Un equipo que construye lógica de liquidación de valores con transferencias limitadas, distribución de dividendos o reglas de cumplimiento integradas directamente en un contrato está más cerca de lo que Zedger y los contratos nativos de DuskVM fueron diseñados desde el principio, ya que ese modelo híbrido de transacciones fue creado específicamente para este tipo de contabilidad de token de seguridad, en lugar de adaptarse a posteriori desde un patrón de propósito general.
No estoy del todo convencido de que este enfoque de doble vía evite fragmentar la base de desarrolladores de Dusk Network y el esfuerzo de documentación entre dos audiencias, en vez de concentrarlo detrás de una sola. Dos entornos de ejecución significan dos conjuntos de herramientas que mantener, dos modelos mentales para las nuevas personas contribuidoras y dos respuestas a la pregunta simple de dónde realmente debería construirse una nueva aplicación. Entiendo la apuesta, porque reducirse a una sola ruta tan pronto habría dejado en silencio a un público fuera. Si Dusk Network se mantiene lo bastante grande como para apoyar adecuadamente ambas rutas durante los próximos años es algo que vale la pena vigilar.
#dusk $DUSK @Dusk
