🔥🔥Hoje fui acompanhar de perto o andamento da @Dusk sobre o DuskEVM e, quanto mais eu olho, mais sinto que esse design é, na prática, bastante fundamental para quem detém $DUSK .
A equipe oficial reforça uma coisa repetidas vezes: o Gas do DuskEVM usa diretamente o $DUSK , sem criar uma segunda moeda de token para a camada de execução. Os desenvolvedores usam Solidity e Hardhat para fazer deploy de aplicações; as transações geradas acabam retornando para a demanda de $DUSK . Mais builders → mais aplicações → mais atividades on-chain → mais moedas Dusk usadas para pagar Gas.
Como um programador aposentado, acho que esse raciocínio é bem claro no desenho; eu concordo bastante. Em muitas chains EVM, depois se emite outro token de Gas, separando a demanda em duas partes e, no fim, o token nativo e o token da camada de execução acabam competindo entre si por valor — isso é o chamado de “fragmentação”. A @Dusk unifica a demanda de execução diretamente em $DUSK ; do ponto de vista de programador, isso realmente parece limpo e contido.
Mas o problema está no tempo.
A testnet do DuskEVM já entrou no ar no início de agosto, e a equipe oficial segue empurrando a narrativa de que “a compatibilidade EVM vai abrir a ecossistema”. Só que até agora, a quantidade diária de transações na mainnet da #dusk ainda está em torno de apenas duzentas. A testnet funcionar não significa que a mainnet, imediatamente, terá quantidade suficiente de aplicações reais e volume de transações de instituições.
Entre a testnet e a mainnet começar a gerar um consumo de Gas capaz de compensar de forma visível o aumento diário de emissão, existe um período de vácuo. Neste momento, o Dusk ainda está na fase inicial de emissão: cerca de 19,86 moedas de $DUSK por bloco. Aproximando, com mais de oito mil blocos por dia, a emissão diária extra pode chegar a algo como cento e dezessete mil moedas. Se esse período de vácuo for longo demais, as atividades não decolam e os detentores de $DUSK precisam continuar lidando com a pressão de diluição causada por essa oferta adicional.
Então, um design “limpo” não significa que vá ser colocado em prática imediatamente. Eu também já vi alguns projetos entrarem em camadas de compatibilidade EVM — como o Evmos: quando foi lançado em 2022, ele apostou na narrativa “EVM + IBC”, mas, no início, o desenho inflacionário foi bastante agressivo. Os desenvolvedores entraram, mas o volume de transações reais e o consumo de Gas do token nativo não decolaram por muito tempo; a emissão continuou, e os detentores tiveram de aguentar primeiro.
Por isso, o que eu mais me preocupo é: esse motor de demanda do DuskEVM, que foi colocado em tanta expectativa, provavelmente levará quanto tempo para realmente puxar as atividades on-chain da rede Dusk? Quando a @Dusk der uma janela de tempo mais clara para o lançamento do DuskEVM na mainnet, eu reavaliarei novamente como esse design impulsiona, na prática, a demanda de $DUSK .
A equipe oficial reforça uma coisa repetidas vezes: o Gas do DuskEVM usa diretamente o $DUSK , sem criar uma segunda moeda de token para a camada de execução. Os desenvolvedores usam Solidity e Hardhat para fazer deploy de aplicações; as transações geradas acabam retornando para a demanda de $DUSK . Mais builders → mais aplicações → mais atividades on-chain → mais moedas Dusk usadas para pagar Gas.
Como um programador aposentado, acho que esse raciocínio é bem claro no desenho; eu concordo bastante. Em muitas chains EVM, depois se emite outro token de Gas, separando a demanda em duas partes e, no fim, o token nativo e o token da camada de execução acabam competindo entre si por valor — isso é o chamado de “fragmentação”. A @Dusk unifica a demanda de execução diretamente em $DUSK ; do ponto de vista de programador, isso realmente parece limpo e contido.
Mas o problema está no tempo.
A testnet do DuskEVM já entrou no ar no início de agosto, e a equipe oficial segue empurrando a narrativa de que “a compatibilidade EVM vai abrir a ecossistema”. Só que até agora, a quantidade diária de transações na mainnet da #dusk ainda está em torno de apenas duzentas. A testnet funcionar não significa que a mainnet, imediatamente, terá quantidade suficiente de aplicações reais e volume de transações de instituições.
Entre a testnet e a mainnet começar a gerar um consumo de Gas capaz de compensar de forma visível o aumento diário de emissão, existe um período de vácuo. Neste momento, o Dusk ainda está na fase inicial de emissão: cerca de 19,86 moedas de $DUSK por bloco. Aproximando, com mais de oito mil blocos por dia, a emissão diária extra pode chegar a algo como cento e dezessete mil moedas. Se esse período de vácuo for longo demais, as atividades não decolam e os detentores de $DUSK precisam continuar lidando com a pressão de diluição causada por essa oferta adicional.
Então, um design “limpo” não significa que vá ser colocado em prática imediatamente. Eu também já vi alguns projetos entrarem em camadas de compatibilidade EVM — como o Evmos: quando foi lançado em 2022, ele apostou na narrativa “EVM + IBC”, mas, no início, o desenho inflacionário foi bastante agressivo. Os desenvolvedores entraram, mas o volume de transações reais e o consumo de Gas do token nativo não decolaram por muito tempo; a emissão continuou, e os detentores tiveram de aguentar primeiro.
Por isso, o que eu mais me preocupo é: esse motor de demanda do DuskEVM, que foi colocado em tanta expectativa, provavelmente levará quanto tempo para realmente puxar as atividades on-chain da rede Dusk? Quando a @Dusk der uma janela de tempo mais clara para o lançamento do DuskEVM na mainnet, eu reavaliarei novamente como esse design impulsiona, na prática, a demanda de $DUSK .
