#dusk $DUSK Hoje estou lendo a documentação da rede de testes do DuskEVM no @Dusk. No começo, achei que era aquela história de “o Dusk finalmente passou a suportar Solidity” — uma camada padrão compatível com EVM, em que os desenvolvedores apenas portam contratos de Ethereum e pronto. Mas, ao ver a relação entre o DuskEVM e o DuskDS no diagrama de arquitetura, percebi que não é tão simples.
O DuskEVM é construído sobre o OP Stack, usa uma interface padrão de Ethereum JSON-RPC, com Chain ID 745. O token de gas ainda é o $DUSK . Os devs conseguem implantar contratos com Foundry ou Hardhat, e o explorador da testnet também é o Blockscout. À primeira vista, parece não haver diferença para outras cadeias baseadas em OP Stack.
O ponto crucial é que o DuskEVM não faz o próprio gerenciamento de settlement e DA. Ele coloca a execução na camada EVM; settlement e disponibilidade de dados ficam a cargo do DuskDS — ou seja, a camada de consenso e finalização do Dusk L1. Isso significa que contratos EVM rodam em um ambiente compatível, mas o estado final é “travado” pela concordância de Succinct Attestation do DuskDS: você obtém finalidade determinística, não confirmações probabilísticas.
Faço uma analogia: não é como abrir, no centro da cidade, uma loja com as mesmas especificações. É como se as lojas dentro do shopping usassem um sistema de caixa que todos já conhecem (EVM), mas no fim cada conta ainda vai ser acertada no cofre da matriz (DuskDS). O cliente não nota a diferença, mas auditoria e conformidade olham para o livro-razão da matriz, não para o cache do caixa.
Há uma restrição fácil de passar despercebida: o DuskEVM e o Dusk L1 se conectam via bridge. O DUSK é o mesmo ativo nos sistemas de contas dos dois lados, mas transferências entre camadas exigem operação de bridge. Se a liquidez da bridge for insuficiente ou a latência for alta demais, a experiência DeFi na camada EVM sai prejudicada. Na fase atual de testnet, ainda há poucos dados reais sobre throughput e latência da bridge. @Dusk
Então, ao olhar para essa etapa do EVM com #dusk , eu vou focar na quantidade real de contratos implantados na testnet, na distribuição de atrasos da bridge e no custo de fricção para transferir ativos entre o DuskEVM e o Dusk L1. $DUSK Ter uma porta de entrada em EVM não significa que os devs vão vir; o mais importante é se, depois de virem, conseguem ficar.