O DuskEVM acabou de entrar no ar, e a parte que estou observando não é o lançamento em si.
É a rapidez com que os primeiros desenvolvedores realmente passam de “consigo fazer deploy aqui” para “quero continuar construindo aqui.”
Tenho analisado a configuração do DuskEVM, e a fricção óbvia é muito menor do que no caminho nativo de desenvolvedores do Dusk. Solidity e Vyper são suportados, e as ferramentas existentes de EVM deveriam ser aproveitadas. Isso importa porque pedir que os desenvolvedores aprendam uma nova stack é uma coisa. Pedir que eles mudem todo o fluxo de trabalho é outra.
Mas compatibilidade só o coloca na linha de largada.
O Dusk já tem 2 caminhos de contrato: DuskEVM e DuskVM. Então agora surge uma pergunta mais prática. Se eu sou um desenvolvedor com uma aplicação Solidity existente, o que me faz escolher o DuskEVM em vez das dezenas de lugares onde esse mesmo código já consegue rodar?
A resposta provavelmente não virá de outro anúncio de recurso.
Ela vai aparecer em implantações reais, atividade em carteiras, interações de contratos e se os desenvolvedores voltam após o primeiro experimento.
Até o lado do GitHub vale observar. O repositório público do genesis do DuskEVM foi atualizado em 28 de julho, o que mostra que as peças estão sendo encaixadas, mas a atividade do dia do lançamento é um teste diferente.
Agora, o que mais me interessa são os primeiros 30 dias, porque é quando “compatível com EVM” ou se torna realmente útil ou começa a soar como...
@Dusk_Foundation #dusk $DUSK $DEXE
É a rapidez com que os primeiros desenvolvedores realmente passam de “consigo fazer deploy aqui” para “quero continuar construindo aqui.”
Tenho analisado a configuração do DuskEVM, e a fricção óbvia é muito menor do que no caminho nativo de desenvolvedores do Dusk. Solidity e Vyper são suportados, e as ferramentas existentes de EVM deveriam ser aproveitadas. Isso importa porque pedir que os desenvolvedores aprendam uma nova stack é uma coisa. Pedir que eles mudem todo o fluxo de trabalho é outra.
Mas compatibilidade só o coloca na linha de largada.
O Dusk já tem 2 caminhos de contrato: DuskEVM e DuskVM. Então agora surge uma pergunta mais prática. Se eu sou um desenvolvedor com uma aplicação Solidity existente, o que me faz escolher o DuskEVM em vez das dezenas de lugares onde esse mesmo código já consegue rodar?
A resposta provavelmente não virá de outro anúncio de recurso.
Ela vai aparecer em implantações reais, atividade em carteiras, interações de contratos e se os desenvolvedores voltam após o primeiro experimento.
Até o lado do GitHub vale observar. O repositório público do genesis do DuskEVM foi atualizado em 28 de julho, o que mostra que as peças estão sendo encaixadas, mas a atividade do dia do lançamento é um teste diferente.
Agora, o que mais me interessa são os primeiros 30 dias, porque é quando “compatível com EVM” ou se torna realmente útil ou começa a soar como...
@Dusk_Foundation #dusk $DUSK $DEXE