#dusk $DUSK Eu tentei seguir um dos guias de desenvolvimento do Dusk, do setup do ambiente até a implantação de um contrato simples. A conclusão é: existe uma distância considerável entre a “cobertura” e a “disponibilidade” da documentação.
O Dusk EVM é compatível com Solidity e, em teoria, desenvolvedores do Ethereum podem migrar sem problemas. Mas, seguindo o manual, a primeira barreira que encontrei foi o ambiente de testes local — a estabilidade do endpoint RPC do DuskEVM Testnet é, em geral, mediana, com timeouts ocasionais; o faucet às vezes não responde e é preciso esperar algumas horas para receber tokens de teste. Para quem já está familiarizado com desenvolvimento no Ethereum isso não é fatal, mas desanima aqueles que só querem “testar”.
A segunda barreira é a adequação de conceitos específica do Dusk. Desenvolvedores do Ethereum estão acostumados com o modelo de contas, estimativa de Gas e o ciclo de vida de transações; no Dusk, é necessário redescobrir tudo isso. Por exemplo, o fluxo de saída entre L1 e EVM exige três etapas, e o estado e as condições de espera de cada etapa são diferentes do que ocorre no Ethereum L2. A documentação realmente descreve isso, mas carece de um guia de troubleshooting — se travar em alguma etapa, o desenvolvedor só consegue procurar no código-fonte ou perguntar no Discord.
A terceira barreira é a maturidade da toolchain. O suporte do explorador de blocos para o lado EVM ainda está em aprimoramento, e algumas funcionalidades de verificação de contratos não estão disponíveis; a estabilidade das APIs para monitoramento de eventos e consultas de logs é menor do que em cadeias mais maduras. A falta dessas infraestruturas significa que, durante a depuração, os desenvolvedores precisam gastar mais tempo descartando problemas de ferramenta, em vez de focar na lógica do negócio.
Não estou dizendo que a experiência de desenvolvimento do Dusk seja ruim — para uma cadeia que ainda está iterando rápido, essas questões fazem parte do estágio normal. O problema é que o crescimento do ecossistema depende da entrada de desenvolvedores; e a escolha de uma cadeia por parte dos desenvolvedores, muitas vezes, não se baseia no whitepaper, mas no tempo que leva para rodar o demo pela primeira vez. Se montar o ambiente já consome uma tarde inteira, muita gente simplesmente fecha a janela. @Dusk
Então, quando olho o progresso do ecossistema do Dusk, não olho o mural de logos de parceiros; olho a frequência de atualização da documentação para desenvolvedores, a velocidade de resposta a problemas técnicos no Discord e se surgiram ferramentas e tutoriais de terceiros guiados por “incentivos não oficiais”. O verdadeiro ecossistema de desenvolvedores é construído a partir de experiências de aprendizado com erros, não algo empilhado por posts de blog técnicos.
O Dusk EVM é compatível com Solidity e, em teoria, desenvolvedores do Ethereum podem migrar sem problemas. Mas, seguindo o manual, a primeira barreira que encontrei foi o ambiente de testes local — a estabilidade do endpoint RPC do DuskEVM Testnet é, em geral, mediana, com timeouts ocasionais; o faucet às vezes não responde e é preciso esperar algumas horas para receber tokens de teste. Para quem já está familiarizado com desenvolvimento no Ethereum isso não é fatal, mas desanima aqueles que só querem “testar”.
A segunda barreira é a adequação de conceitos específica do Dusk. Desenvolvedores do Ethereum estão acostumados com o modelo de contas, estimativa de Gas e o ciclo de vida de transações; no Dusk, é necessário redescobrir tudo isso. Por exemplo, o fluxo de saída entre L1 e EVM exige três etapas, e o estado e as condições de espera de cada etapa são diferentes do que ocorre no Ethereum L2. A documentação realmente descreve isso, mas carece de um guia de troubleshooting — se travar em alguma etapa, o desenvolvedor só consegue procurar no código-fonte ou perguntar no Discord.
A terceira barreira é a maturidade da toolchain. O suporte do explorador de blocos para o lado EVM ainda está em aprimoramento, e algumas funcionalidades de verificação de contratos não estão disponíveis; a estabilidade das APIs para monitoramento de eventos e consultas de logs é menor do que em cadeias mais maduras. A falta dessas infraestruturas significa que, durante a depuração, os desenvolvedores precisam gastar mais tempo descartando problemas de ferramenta, em vez de focar na lógica do negócio.
Não estou dizendo que a experiência de desenvolvimento do Dusk seja ruim — para uma cadeia que ainda está iterando rápido, essas questões fazem parte do estágio normal. O problema é que o crescimento do ecossistema depende da entrada de desenvolvedores; e a escolha de uma cadeia por parte dos desenvolvedores, muitas vezes, não se baseia no whitepaper, mas no tempo que leva para rodar o demo pela primeira vez. Se montar o ambiente já consome uma tarde inteira, muita gente simplesmente fecha a janela. @Dusk
Então, quando olho o progresso do ecossistema do Dusk, não olho o mural de logos de parceiros; olho a frequência de atualização da documentação para desenvolvedores, a velocidade de resposta a problemas técnicos no Discord e se surgiram ferramentas e tutoriais de terceiros guiados por “incentivos não oficiais”. O verdadeiro ecossistema de desenvolvedores é construído a partir de experiências de aprendizado com erros, não algo empilhado por posts de blog técnicos.
文档够用就行,不影响开发
0%
开发者体验决定生态天花板
100%
测试网不稳定很正常
0%
1 Votos • Votação encerrada