#dusk $DUSK @Dusk
Eu troquei meu telefone há algum tempo e a parte mais estranha não foi aprender as funções novas. Foi descobrir quais hábitos antigos ainda funcionavam. Os mesmos gestos, os mesmos apps, tudo parecia familiar… até eu estender a mão para alguma coisa e ela não estar onde meu cérebro esperava.
É mais ou menos assim que eu vejo a DuskEVM.
Eu já vi “EVM-compatible” tantas vezes que quase ignoro a expressão agora. O que eu realmente me importo com @dusk é algo mais simples: um desenvolvedor consegue sentar e simplesmente trabalhar? Solidity, Hardhat, Foundry, ethers, viem, a carteira que ele já conhece. Nenhuma semana perdida brigando com um ambiente totalmente novo antes de qualquer coisa útil ser construída.
Mas eu fico pensando no que acontece por baixo dessa superfície familiar.
$DUSK é usado para execução; ele pode se mover entre o Dusk L1 e o DuskEVM via bridge, e a atividade eventualmente volta a ancorar pelo DuskDS. Então você está trabalhando dentro de algo que parece familiar, enquanto depende de uma infraestrutura que realmente não é a configuração EVM usual.
E é aqui que eu ainda não tenho certeza sobre @dusk. Familiaridade é ótima quando tudo funciona. O teste real vem quando alguma coisa não funciona. Um problema de bridge, um atraso de liquidação, algum problema de integração estranho… de repente o desenvolvedor pode precisar entender toda a maquinário específico da Dusk sobre o qual ele mal estava pensando antes.
Talvez seja essa a parte que as pessoas ignoram.
Fazer desenvolvedores tentarem outro ambiente EVM já não é a parte difícil. Fazer com que eles esqueçam que estão usando uma arquitetura diferente até o momento em que essa diferença realmente importa… isso parece bem mais difícil.
$DUSK
Eu troquei meu telefone há algum tempo e a parte mais estranha não foi aprender as funções novas. Foi descobrir quais hábitos antigos ainda funcionavam. Os mesmos gestos, os mesmos apps, tudo parecia familiar… até eu estender a mão para alguma coisa e ela não estar onde meu cérebro esperava.
É mais ou menos assim que eu vejo a DuskEVM.
Eu já vi “EVM-compatible” tantas vezes que quase ignoro a expressão agora. O que eu realmente me importo com @dusk é algo mais simples: um desenvolvedor consegue sentar e simplesmente trabalhar? Solidity, Hardhat, Foundry, ethers, viem, a carteira que ele já conhece. Nenhuma semana perdida brigando com um ambiente totalmente novo antes de qualquer coisa útil ser construída.
Mas eu fico pensando no que acontece por baixo dessa superfície familiar.
$DUSK é usado para execução; ele pode se mover entre o Dusk L1 e o DuskEVM via bridge, e a atividade eventualmente volta a ancorar pelo DuskDS. Então você está trabalhando dentro de algo que parece familiar, enquanto depende de uma infraestrutura que realmente não é a configuração EVM usual.
E é aqui que eu ainda não tenho certeza sobre @dusk. Familiaridade é ótima quando tudo funciona. O teste real vem quando alguma coisa não funciona. Um problema de bridge, um atraso de liquidação, algum problema de integração estranho… de repente o desenvolvedor pode precisar entender toda a maquinário específico da Dusk sobre o qual ele mal estava pensando antes.
Talvez seja essa a parte que as pessoas ignoram.
Fazer desenvolvedores tentarem outro ambiente EVM já não é a parte difícil. Fazer com que eles esqueçam que estão usando uma arquitetura diferente até o momento em que essa diferença realmente importa… isso parece bem mais difícil.
$DUSK