Ao avaliar o andamento de um projeto, eu não me importo com o que ele diz sobre a rede principal; eu olho para o repositório do GitHub. No código da @Dusk existe um sinal bem honesto: nas issues do repositório de documentação está escrito que, após a introdução de uma arquitetura modular, recomenda-se que os desenvolvedores usem o DuskEVM, mas grande parte da documentação existente ainda fala sobre o DuskVM. Ou seja, a direção do produto já mudou, mas a documentação e o código ainda não acompanharam completamente.
O GitHub público oficial da Dusk também comprova esse desencontro. O dusk-network/rusk é uma implementação de referência, com módulos centrais como dusk-vm, dusk-core e provas de conhecimento zero PLONK; porém, o repositório independente rusk-vm, que está mais alinhado com as capacidades nativas, não tem tanta tração, e o número de estrelas e os sinais de atualização parecem bem mais frios do que o discurso principal. Em contraste, a documentação oficial já colocou o quickstart do DuskEVM, o Solidity e a toolchain do ecossistema Ethereum nas posições mais convenientes. Um projeto que se vende como privacidade nativa e contratos inteligentes WASM, mas que na prática direciona novos desenvolvedores para o caminho do EVM — isso por si só já é uma declaração silenciosa. #dusk
Ainda não considero o número de estrelas como uma conclusão, porque a atividade do código também precisa ser avaliada pela frequência de commits, número de contribuidores e taxa de fechamento de issues. Mas, somando esses fragmentos, a direção já fica bem clara: $DUSK está com o foco na migração; a parte do VM nativo parece mais uma capacidade mantida a longo prazo do que a porta principal de desenvolvimento que está sendo empurrada agora. O “mainnet coming” dos comunicados oficiais precisa de um cronograma de entregas de código correspondente para sustentá-lo, e não apenas trocar a organização dos conteúdos baseada em documentação técnica.
A conclusão é: atualmente, os sinais de código publicados não são suficientes para sustentar a afirmação de que “as duas plataformas de execução têm a mesma maturidade”. O DuskEVM é claramente a direção mais ativa e mais impulsionada, enquanto o DuskVM parece mais um reservatório ainda não suficientemente lapidado. O verdadeiro progresso deve ser medido se as issues de alguns próximos marcos continuam sendo fechadas de forma consistente, e não pelo fato de terem surgido mais alguns textos de conceito na página inicial.
O GitHub público oficial da Dusk também comprova esse desencontro. O dusk-network/rusk é uma implementação de referência, com módulos centrais como dusk-vm, dusk-core e provas de conhecimento zero PLONK; porém, o repositório independente rusk-vm, que está mais alinhado com as capacidades nativas, não tem tanta tração, e o número de estrelas e os sinais de atualização parecem bem mais frios do que o discurso principal. Em contraste, a documentação oficial já colocou o quickstart do DuskEVM, o Solidity e a toolchain do ecossistema Ethereum nas posições mais convenientes. Um projeto que se vende como privacidade nativa e contratos inteligentes WASM, mas que na prática direciona novos desenvolvedores para o caminho do EVM — isso por si só já é uma declaração silenciosa. #dusk
Ainda não considero o número de estrelas como uma conclusão, porque a atividade do código também precisa ser avaliada pela frequência de commits, número de contribuidores e taxa de fechamento de issues. Mas, somando esses fragmentos, a direção já fica bem clara: $DUSK está com o foco na migração; a parte do VM nativo parece mais uma capacidade mantida a longo prazo do que a porta principal de desenvolvimento que está sendo empurrada agora. O “mainnet coming” dos comunicados oficiais precisa de um cronograma de entregas de código correspondente para sustentá-lo, e não apenas trocar a organização dos conteúdos baseada em documentação técnica.
A conclusão é: atualmente, os sinais de código publicados não são suficientes para sustentar a afirmação de que “as duas plataformas de execução têm a mesma maturidade”. O DuskEVM é claramente a direção mais ativa e mais impulsionada, enquanto o DuskVM parece mais um reservatório ainda não suficientemente lapidado. O verdadeiro progresso deve ser medido se as issues de alguns próximos marcos continuam sendo fechadas de forma consistente, e não pelo fato de terem surgido mais alguns textos de conceito na página inicial.
