#dusk $DUSK Probé a seguir la documentación de desarrollo de Dusk de principio a fin, desde la configuración del entorno hasta el despliegue de un contrato sencillo. La conclusión es que existe una distancia considerable entre la “cobertura” de la documentación y su “utilidad”.
DuskEVM es compatible con Solidity, así que en teoría los desarrolladores de Ethereum pueden migrar sin fricciones. Pero cuando seguí los pasos de la documentación, el primer obstáculo fue el entorno de pruebas local: la estabilidad del endpoint RPC de DuskEVM Testnet es bastante normalita y, de vez en cuando, se producen timeouts; a veces el faucet no responde y hay que esperar varias horas para poder conseguir tokens de prueba. Para quienes están familiarizados con Ethereum, esto no es fatal, pero sí desanima a quienes solo quieren “probar”.
El segundo obstáculo es el mapeo de conceptos propios de Dusk. El modelo de cuentas, la estimación de gas y el ciclo de vida de las transacciones al que están acostumbrados los desarrolladores de Ethereum necesitan reinterpretarse en Dusk. Por ejemplo, el proceso de salida entre L1 y EVM requiere tres pasos, y el estado y las condiciones de espera de cada uno difieren de las de Ethereum L2. La documentación sí lo explica, pero carece de una guía de resolución de problemas: si un paso se queda atascado, el desarrollador no tiene más remedio que revisar el código fuente por su cuenta o preguntar en Discord.
El tercer obstáculo es la madurez de la cadena de herramientas. El explorador de bloques aún está mejorando su soporte para la parte EVM, y algunas funciones de verificación de contratos no están disponibles; la estabilidad de la API para la suscripción a eventos y la consulta de logs es inferior a la de cadenas más maduras. La ausencia de estas infraestructuras significa que, al depurar, los desarrolladores tienen que dedicar más tiempo a descartar problemas de herramientas en lugar de centrarse en la lógica de negocio.
No estoy diciendo que la experiencia de desarrollo en Dusk sea mala: para una cadena que aún itera rápidamente, todo esto entra dentro de una fase normal. Pero el problema es que el crecimiento del ecosistema depende de la incorporación de desarrolladores, y la cadena que elijan no suele depender del white paper, sino de cuánto tardan en hacer funcionar un demo por primera vez. Si solo la configuración del entorno ya consume una tarde entera, mucha gente cerrará la ventana directamente.@Dusk
Por eso, cuando observo el progreso del ecosistema de Dusk, no me fijo en la pared de logotipos de socios, sino en la frecuencia de actualización de la documentación para desarrolladores, en la velocidad de respuesta a los problemas técnicos en Discord y en si han surgido herramientas y tutoriales de terceros impulsados por “incentivos no oficiales”. Un verdadero ecosistema de desarrolladores se construye con experiencias de tropiezos y aprendizaje, no apilando blogs técnicos.