#dusk $DUSK Recentemente, passei um fim de semana tentando, seguindo a documentação de desenvolvedor de @Dusk , montar um ambiente local do zero; para ser sincero, o processo foi mais difícil do que eu esperava.
No nível conceitual, a documentação está bem escrita: o diagrama de arquitetura é claro, a divisão de responsabilidades dos módulos principais é explicada com clareza, e a lógica de design da máquina virtual Rusk também tem uma seção dedicada. Mas, assim que entrei na parte prática, os problemas começaram a aparecer. As versões de dependência no código de exemplo não batem com a versão mais recente do repositório; em certas descrições de parâmetros de entrada de algumas APIs, a documentação simplesmente omite informações, e eu tive que olhar o código-fonte para descobrir o formato dos parâmetros. Isso não é um problema fatal, mas consome bastante a paciência e a confiança do desenvolvedor.
O que mais me incomodou foi a estabilidade da testnet. Ao conectar localmente à testnet para depurar algumas transações simples, encontrei algumas vezes situações em que nós RPC não respondiam. Embora a conexão voltasse após novas tentativas, a documentação não explica o nível de serviço nem a janela de manutenção da testnet. Para desenvolvedores que estão apenas "vendo como é", esse tipo de incerteza pode afastar de imediato — e eles não vão te dizer por que foram embora.
Outra impressão é que a cadeia de ferramentas de desenvolvimento do Dusk e o ecossistema Ethereum têm diferenças claras, e isso é uma faca de dois gumes. A vantagem é que o Dusk pode fazer personalizações profundas voltadas às suas próprias características de privacidade e conformidade, sem ficar preso às limitações herdadas do EVM; a desvantagem é que o desenvolvedor não consegue reaproveitar diretamente habilidades em Solidity nem as ferramentas já existentes. Embora a documentação forneça o Rust SDK e exemplos de contratos, começar do zero aprendendo Rust e depois o paradigma de desenvolvimento do Dusk torna a curva de aprendizado bem mais íngreme do que "dar fork em um ERC-20".
Entendo que a construção da documentação e da cadeia de ferramentas leva tempo, e que a equipe priorizar recursos para a mainnet e para o protocolo central também faz sentido. Mas o arranque inicial de um ecossistema de desenvolvedores não depende do desempenho do protocolo, e sim de um "Hello World" que funcione logo no primeiro dia. Quando #dusk oferecer uma testnet mais estável, tutoriais de introdução com versões travadas e uma quantidade maior de casos de sucesso de implantação por desenvolvedores de terceiros, aí eu volto a avaliar se o ecossistema entrou de fato em um ciclo virtuoso. Para $DUSK , o número de desenvolvedores não é a quantidade de pessoas na comunidade, mas sim o número de contratos realmente implantados na cadeia. @Dusk