Eu continuei voltando ao DuskEVM por um motivo diferente daquele que eu esperava. A proposta óbvia é compatibilidade com Ethereum, mas isso quase parece fácil demais para ser o ponto.
A EVM hoje já é uma camada enorme de infraestrutura: Solidity, Foundry, Hardhat, viem, ethers, wallets, RPCs, indexadores e fluxos de trabalho de desenvolvimento familiares.
Os desenvolvedores não precisam de mais um ecossistema para aprender.
Eles precisam de um motivo para realmente usar, em algum lugar novo, o que já conhecem.
Isso torna o DuskEVM mais interessante como uma ponte do que como “mais uma cadeia EVM”.
A ideia é manter a experiência voltada ao Ethereum enquanto o DuskDS cuida do settlement e da disponibilidade de dados por baixo.
@Dusk_Foundation é usado para gas, enquanto as aplicações recebem acesso ao resto da pilha do Dusk.
A parte sobre a qual eu continuei pensando era o custo de entrada.
Se um desenvolvedor puder trazer ferramentas familiares em vez de aprender uma pilha totalmente nova e reconstruir tudo do zero, $DUSK tem uma chance muito melhor de atrair aplicações reais.
E ativos regulados tornam essa distinção ainda mais importante.
A lógica de contratos inteligentes é apenas uma peça quando conformidade, privacidade e settlement importam.
Mas tem uma pegadinha.
Se as ferramentas do Ethereum são o principal motivo para usar o DuskEVM, por que não apenas construir no Ethereum ou em uma L2 e adicionar as peças de conformidade e privacidade que faltam?
É aí que só compatibilidade EVM deixa de ser suficiente.
O DuskEVM precisa de aplicações que façam a pilha subjacente do Dusk valer a pena atravessar a ponte.
Caso contrário, é apenas mais uma interface familiar em um mercado bem concorrido.

#dusk