Muitas discussões tratam o fato de o Dusk já ter sido lançado como uma conclusão completa, mas essa frase está faltando o sujeito mais importante. No snapshot do site oficial do provedor, o Dusk Native L1 está marcado como Live, o DuskEVM como Testnet, o Hedger como Testnet e o Dusk Trade como Building. Esses quatro nomes se referem a camadas diferentes: a rede em si, o caminho de execução compatível com EVM, os módulos relacionados à privacidade e a direção da camada de aplicação voltada a ativos financeiros tokenizados. Ao compactá-los em um único estado, as pessoas passam a confundir uma rede já existente, funcionalidades testáveis e um produto que ainda está em construção.
Se o problema da equipe é saber o que pode ser verificado agora, deve-se primeiro informar o nome do módulo e, depois, seu status público. O snapshot do Native L1 como Live não pode substituir a declaração de que o DuskEVM está pronto para uso em produção; o DuskEVM ou o Hedger em Testnet também não podem ser empurrados para uma implantação já totalmente concluída; e o Dusk Trade em Building é ainda mais diferente de já ter aberto negociações. Fazer isso não é “apagar o brilho” com desconfiança, e sim estabelecer limites claros para a avaliação: ao discutir a base de liquidação, o caminho de testes ou o plano da camada de aplicação, a força das evidências é diferente, e a conclusão também deve ser diferente.
Para o responsável pelo produto, a pergunta mais útil não é se o Dusk “de fato” foi lançado, mas sim como chamamos essa camada que vamos usar, em que estado ela está e quais conclusões esse estado permite. Primeiro completar o sujeito; depois falar do uso e dos próximos passos—assim, declarações genéricas se transformam em julgamentos técnicos que podem ser verificados.
Isso também explica por que, sob o mesmo nome de projeto, podem aparecer ao mesmo tempo Live, Testnet e Building. Essas etiquetas não são uma ordem de “bom versus ruim”; elas apenas sinalizam que o leitor deve usar métodos de verificação diferentes: a camada subjacente já lançada pode ser discutida como um fato de rede existente; os módulos em teste devem ficar limitados ao âmbito da experimentação; e a camada de aplicação em construção só deve discutir direções públicas.
@Dusk $DUSK #dusk
Se o problema da equipe é saber o que pode ser verificado agora, deve-se primeiro informar o nome do módulo e, depois, seu status público. O snapshot do Native L1 como Live não pode substituir a declaração de que o DuskEVM está pronto para uso em produção; o DuskEVM ou o Hedger em Testnet também não podem ser empurrados para uma implantação já totalmente concluída; e o Dusk Trade em Building é ainda mais diferente de já ter aberto negociações. Fazer isso não é “apagar o brilho” com desconfiança, e sim estabelecer limites claros para a avaliação: ao discutir a base de liquidação, o caminho de testes ou o plano da camada de aplicação, a força das evidências é diferente, e a conclusão também deve ser diferente.
Para o responsável pelo produto, a pergunta mais útil não é se o Dusk “de fato” foi lançado, mas sim como chamamos essa camada que vamos usar, em que estado ela está e quais conclusões esse estado permite. Primeiro completar o sujeito; depois falar do uso e dos próximos passos—assim, declarações genéricas se transformam em julgamentos técnicos que podem ser verificados.
Isso também explica por que, sob o mesmo nome de projeto, podem aparecer ao mesmo tempo Live, Testnet e Building. Essas etiquetas não são uma ordem de “bom versus ruim”; elas apenas sinalizam que o leitor deve usar métodos de verificação diferentes: a camada subjacente já lançada pode ser discutida como um fato de rede existente; os módulos em teste devem ficar limitados ao âmbito da experimentação; e a camada de aplicação em construção só deve discutir direções públicas.
@Dusk $DUSK #dusk