🔥🔥Hoy me fui a hacer un seguimiento de los avances relacionados con DuskEVM de @Dusk , y cuanto más lo miro, más siento que este diseño en realidad es bastante clave para los tenedores de $DUSK .
La oficialidad recalca repetidamente una cosa: el Gas de DuskEVM usa directamente $DUSK , sin emitir un token adicional para la capa de ejecución. Los desarrolladores usan Solidity y Hardhat para desplegar aplicaciones; las transacciones que se generan finalmente vuelven a la necesidad de $DUSK . Más builder → más aplicaciones → más actividad on-chain → más Dusk se usa para pagar el Gas.
Como programador retirado, creo que esta lógica está clara a nivel de diseño y la apoyo mucho: en muchas cadenas, las capas EVM suelen emitir después otro token de Gas, dividiendo la demanda en dos partes; al final, el valor se lo reparten entre el token nativo y el token de la capa de ejecución, lo que se conoce como “fragmentación”. @Dusk unifica las necesidades de ejecución directamente en $DUSK ; desde mi perspectiva de programador, se siente realmente limpio y muy contenido.
Pero el problema está en el tiempo.
La testnet de DuskEVM ya salió a principios de agosto y la oficialidad sigue impulsando que “la compatibilidad con EVM abrirá el ecosistema”. Pero a día de hoy, #dusk en la red principal, el volumen de transacciones diario de forma rutinaria todavía está apenas alrededor de doscientas. Que la testnet funcione no significa que la red principal vaya a tener de inmediato suficientes aplicaciones reales y volumen de operaciones de instituciones.
Desde la testnet hasta que en la red principal se genere un consumo de Gas capaz de compensar de forma clara el nuevo suministro diario, hay un periodo de vacío. En este momento, Dusk todavía está en la primera fase de emisión: cada bloque libera aproximadamente 19.86 unidades de $DUSK ; calculando a ojo unos más de ocho mil bloques al día, la nueva emisión diaria puede llegar a unas ciento diecisiete mil monedas. Si ese periodo de vacío se alarga demasiado, la actividad no despega y los tenedores de $DUSK tendrán que seguir enfrentándose a la presión de dilución que trae esta nueva oferta.
Por eso, un diseño “limpio” no significa que se vaya a concretar de inmediato. También he visto proyectos que subieron a capas compatibles con EVM, como Evmos: cuando salió en 2022, se enfocaba en la narrativa de “EVM + IBC”; pero el diseño de inflación en los primeros tiempos era bastante agresivo. Los desarrolladores entraron, pero el volumen real de transacciones y el consumo de Gas del token nativo no consiguieron despegar a largo plazo; la emisión siguió avanzando y los tenedores tuvieron que aguantar primero.
Así que lo que más me importa es esto: el motor de demanda de DuskEVM, tan esperado, ¿cuánto tiempo necesitará para realmente mover la actividad on-chain en la cadena Dusk? Cuando @Dusk proporcione una ventana de tiempo más clara para el lanzamiento en la red principal de DuskEVM, volveré a evaluar este diseño y su impulso real para $DUSK .
La oficialidad recalca repetidamente una cosa: el Gas de DuskEVM usa directamente $DUSK , sin emitir un token adicional para la capa de ejecución. Los desarrolladores usan Solidity y Hardhat para desplegar aplicaciones; las transacciones que se generan finalmente vuelven a la necesidad de $DUSK . Más builder → más aplicaciones → más actividad on-chain → más Dusk se usa para pagar el Gas.
Como programador retirado, creo que esta lógica está clara a nivel de diseño y la apoyo mucho: en muchas cadenas, las capas EVM suelen emitir después otro token de Gas, dividiendo la demanda en dos partes; al final, el valor se lo reparten entre el token nativo y el token de la capa de ejecución, lo que se conoce como “fragmentación”. @Dusk unifica las necesidades de ejecución directamente en $DUSK ; desde mi perspectiva de programador, se siente realmente limpio y muy contenido.
Pero el problema está en el tiempo.
La testnet de DuskEVM ya salió a principios de agosto y la oficialidad sigue impulsando que “la compatibilidad con EVM abrirá el ecosistema”. Pero a día de hoy, #dusk en la red principal, el volumen de transacciones diario de forma rutinaria todavía está apenas alrededor de doscientas. Que la testnet funcione no significa que la red principal vaya a tener de inmediato suficientes aplicaciones reales y volumen de operaciones de instituciones.
Desde la testnet hasta que en la red principal se genere un consumo de Gas capaz de compensar de forma clara el nuevo suministro diario, hay un periodo de vacío. En este momento, Dusk todavía está en la primera fase de emisión: cada bloque libera aproximadamente 19.86 unidades de $DUSK ; calculando a ojo unos más de ocho mil bloques al día, la nueva emisión diaria puede llegar a unas ciento diecisiete mil monedas. Si ese periodo de vacío se alarga demasiado, la actividad no despega y los tenedores de $DUSK tendrán que seguir enfrentándose a la presión de dilución que trae esta nueva oferta.
Por eso, un diseño “limpio” no significa que se vaya a concretar de inmediato. También he visto proyectos que subieron a capas compatibles con EVM, como Evmos: cuando salió en 2022, se enfocaba en la narrativa de “EVM + IBC”; pero el diseño de inflación en los primeros tiempos era bastante agresivo. Los desarrolladores entraron, pero el volumen real de transacciones y el consumo de Gas del token nativo no consiguieron despegar a largo plazo; la emisión siguió avanzando y los tenedores tuvieron que aguantar primero.
Así que lo que más me importa es esto: el motor de demanda de DuskEVM, tan esperado, ¿cuánto tiempo necesitará para realmente mover la actividad on-chain en la cadena Dusk? Cuando @Dusk proporcione una ventana de tiempo más clara para el lanzamiento en la red principal de DuskEVM, volveré a evaluar este diseño y su impulso real para $DUSK .
