Agora minha maior dúvida sobre @Dusk não é se dá para fazer do ponto de vista técnico, mas se o usuário comum realmente ousa usar.
Recentemente revisei de novo o fluxo operacional real. Do lado da engenharia, as atualizações estão acontecendo com frequência; porém, quando chega na mão do usuário, nessas ações básicas — migração, cross-chain e staking — a taxa de tolerância a falhas ainda é um pouco baixa.
Por exemplo, para migrar ERC20/BEP20 DUSK para a mainnet, não é só clicar uma vez e pronto: primeiro é o Approve, depois o Execute; se faltar um desses passos, já não conta como migração concluída. O tempo típico de espera indicado pela equipe oficial ainda é de cerca de 1 hora, e além disso é preciso preparar ETH/BNB com antecedência para pagar o gas.
O que mais me preocupa, porém, é a transferência da mainnet para a BSC. O endereço de recebimento precisa ser indicado via memo. A própria documentação oficial já lembra diretamente: se o memo for deixado em branco ou for inválido, a transação pode não ser processada automaticamente e até existe o risco de os ativos não poderem ser recuperados.
Para jogadores antigos, talvez pareça “basta ler com atenção”, mas se o produto estiver mirando um público maior de usuários, não dá para continuar jogando para o usuário toda a responsabilidade de prevenção a erros.
O staking também é parecido. Fazer staking diretamente com o mínimo de 1000 DUSK ainda exige que a pessoa execute o provisioner; o nó precisa ficar online, manter sincronização e estar com a versão correta. Para ativar normalmente, ainda são cerca de 6–12 horas. Tecnicamente não há nada de errado, mas do ponto de vista de quem apenas mantém moedas, claramente ainda não é uma operação tão leve.
Além disso, em janeiro deste ano, o serviço de ponte sofreu um incidente de invasão em uma carteira com assinatura. Embora a equipe oficial depois tenha deixado claro que não foi uma vulnerabilidade na camada de consenso da Dusk, usuários comuns na prática não vão separar “segurança do protocolo” de “segurança da camada de serviço”; eles só se importam com uma coisa: se eu operar errado minhas moedas ou se o sistema tiver algum problema, será que dá para recuperar?
Então, agora eu acho o contrário: a próxima etapa da Dusk precisa melhorar não só desempenho na base.
Mas sim transformar de verdade uma experiência padrão de produto em que “não dá para preencher errado”, “o status é legível” e “se der erro, tem como resolver/recuperar”.
Complexidade técnica pode até haver, mas a experiência do usuário não precisa ser complicada.
#dusk $DUSK @Dusk
Recentemente revisei de novo o fluxo operacional real. Do lado da engenharia, as atualizações estão acontecendo com frequência; porém, quando chega na mão do usuário, nessas ações básicas — migração, cross-chain e staking — a taxa de tolerância a falhas ainda é um pouco baixa.
Por exemplo, para migrar ERC20/BEP20 DUSK para a mainnet, não é só clicar uma vez e pronto: primeiro é o Approve, depois o Execute; se faltar um desses passos, já não conta como migração concluída. O tempo típico de espera indicado pela equipe oficial ainda é de cerca de 1 hora, e além disso é preciso preparar ETH/BNB com antecedência para pagar o gas.
O que mais me preocupa, porém, é a transferência da mainnet para a BSC. O endereço de recebimento precisa ser indicado via memo. A própria documentação oficial já lembra diretamente: se o memo for deixado em branco ou for inválido, a transação pode não ser processada automaticamente e até existe o risco de os ativos não poderem ser recuperados.
Para jogadores antigos, talvez pareça “basta ler com atenção”, mas se o produto estiver mirando um público maior de usuários, não dá para continuar jogando para o usuário toda a responsabilidade de prevenção a erros.
O staking também é parecido. Fazer staking diretamente com o mínimo de 1000 DUSK ainda exige que a pessoa execute o provisioner; o nó precisa ficar online, manter sincronização e estar com a versão correta. Para ativar normalmente, ainda são cerca de 6–12 horas. Tecnicamente não há nada de errado, mas do ponto de vista de quem apenas mantém moedas, claramente ainda não é uma operação tão leve.
Além disso, em janeiro deste ano, o serviço de ponte sofreu um incidente de invasão em uma carteira com assinatura. Embora a equipe oficial depois tenha deixado claro que não foi uma vulnerabilidade na camada de consenso da Dusk, usuários comuns na prática não vão separar “segurança do protocolo” de “segurança da camada de serviço”; eles só se importam com uma coisa: se eu operar errado minhas moedas ou se o sistema tiver algum problema, será que dá para recuperar?
Então, agora eu acho o contrário: a próxima etapa da Dusk precisa melhorar não só desempenho na base.
Mas sim transformar de verdade uma experiência padrão de produto em que “não dá para preencher errado”, “o status é legível” e “se der erro, tem como resolver/recuperar”.
Complexidade técnica pode até haver, mas a experiência do usuário não precisa ser complicada.
#dusk $DUSK @Dusk