📅8.22
Durante estes dias, as mensagens avassaladoras são sempre do tipo $BTC rompendo X valores, $BNB rompendo Y valores. Eu não tenho nenhuma oferta em mãos e só vejo vocês ganharem dinheiro. Acho que vou continuar escrevendo os textos em silêncio para ganhar pelo menos um troco.
Hoje cedo, quando eu mexi na documentação de desenvolvimento do Dusk, apareceu um paradoxo que não dá para ignorar: o senso de design na arquitetura técnica é realmente forte, mas na hora de colocar a mão na massa, os pontos que emperram são muito mais do que eu imaginava.
✅ Os pontos positivos existem. O DuskVM roda contratos Rust baseados em WebAssembly, sem necessidade de dependências locais — dá para desenvolver direto no navegador. O SDK W3sper, com a camada de bridge Contract Drivers, tem ideias bem interessantes: criou uma camada de abstração entre a carteira e o contrato, reduzindo trabalho repetido de desenvolvimento. Quando eu vi esses designs pela primeira vez, realmente senti um “uau” na hora.
⚠️ Mas quando eu tentei de fato executar uma transação de privacidade, os problemas começaram a aparecer.
Moonlight (conta pública) e Phoenix (endereços mascarados) usam lógicas de transação completamente diferentes na mesma cadeia. Ao ir de Moonlight para Phoenix, o contrato deduz o saldo público e gera um note para ser enviado ao endereço oculto; na operação inversa, ele consome primeiro a note e então credita o saldo público. Faz sentido na teoria, mas, no desenvolvimento real, o modelo de estado, o conjunto de instruções e a contabilização de Gas giram todos em torno de execução transparente. Eu tentei reutilizar diretamente a lógica de Gas das transações públicas para estimar as transações mascaradas, e o resultado foi que a transação falhou na hora.
O que mais me deixa com dor de cabeça é a documentação. A propaganda oficial diz “dá para desenvolver no navegador”, mas eu vasculhei a documentação e vi que há muitas lacunas nas explicações de cenários de borda. Um recurso central sequer tem orientação clara na documentação — eu só consegui encontrar consultando o código-fonte do contrato. Para desenvolver um projeto real, esse custo de tempo é muito maior do que eu tinha previsto inicialmente.
A inovação na arquitetura técnica merece reconhecimento — contratos WASM, modelo com duas transações e a ideia abstrata por trás do Contract Drivers têm visão. Mas a complexidade que essas inovações trazem, no momento, ainda não está totalmente coberta pela documentação e pela toolchain. Para mim, a dificuldade de colocar essa arquitetura em prática é muito maior do que a expectativa criada pela propaganda oficial de “dá para desenvolver no navegador”.
#dusk $DUSK @Dusk
Durante estes dias, as mensagens avassaladoras são sempre do tipo $BTC rompendo X valores, $BNB rompendo Y valores. Eu não tenho nenhuma oferta em mãos e só vejo vocês ganharem dinheiro. Acho que vou continuar escrevendo os textos em silêncio para ganhar pelo menos um troco.
Hoje cedo, quando eu mexi na documentação de desenvolvimento do Dusk, apareceu um paradoxo que não dá para ignorar: o senso de design na arquitetura técnica é realmente forte, mas na hora de colocar a mão na massa, os pontos que emperram são muito mais do que eu imaginava.
✅ Os pontos positivos existem. O DuskVM roda contratos Rust baseados em WebAssembly, sem necessidade de dependências locais — dá para desenvolver direto no navegador. O SDK W3sper, com a camada de bridge Contract Drivers, tem ideias bem interessantes: criou uma camada de abstração entre a carteira e o contrato, reduzindo trabalho repetido de desenvolvimento. Quando eu vi esses designs pela primeira vez, realmente senti um “uau” na hora.
⚠️ Mas quando eu tentei de fato executar uma transação de privacidade, os problemas começaram a aparecer.
Moonlight (conta pública) e Phoenix (endereços mascarados) usam lógicas de transação completamente diferentes na mesma cadeia. Ao ir de Moonlight para Phoenix, o contrato deduz o saldo público e gera um note para ser enviado ao endereço oculto; na operação inversa, ele consome primeiro a note e então credita o saldo público. Faz sentido na teoria, mas, no desenvolvimento real, o modelo de estado, o conjunto de instruções e a contabilização de Gas giram todos em torno de execução transparente. Eu tentei reutilizar diretamente a lógica de Gas das transações públicas para estimar as transações mascaradas, e o resultado foi que a transação falhou na hora.
O que mais me deixa com dor de cabeça é a documentação. A propaganda oficial diz “dá para desenvolver no navegador”, mas eu vasculhei a documentação e vi que há muitas lacunas nas explicações de cenários de borda. Um recurso central sequer tem orientação clara na documentação — eu só consegui encontrar consultando o código-fonte do contrato. Para desenvolver um projeto real, esse custo de tempo é muito maior do que eu tinha previsto inicialmente.
A inovação na arquitetura técnica merece reconhecimento — contratos WASM, modelo com duas transações e a ideia abstrata por trás do Contract Drivers têm visão. Mas a complexidade que essas inovações trazem, no momento, ainda não está totalmente coberta pela documentação e pela toolchain. Para mim, a dificuldade de colocar essa arquitetura em prática é muito maior do que a expectativa criada pela propaganda oficial de “dá para desenvolver no navegador”.
#dusk $DUSK @Dusk
