Digo uma coisa bem na prática: esse fluxo de contratos WASM do Dusk, eu abri o editor no Chrome, conectei a carteira, cliquei em compilar — sem instalar nenhum dependência local antes ou depois. A experiência, de fato, foi bem suave.#[contract] A macro já “embrulha” a exportação e a serialização; a camada de bridge do Contract Drivers também poupa bastante o tempo que você gastaria procurando ABI. Se você só rodar a transferência pública do Moonlight, do zero até o deploy, talvez seja mais rápido do que você preparar uma xícara de café coado artesanal.
A alta do “grande pão” voltou a disparar, e o BTC continua muito forte.
Mas o que me fez parar e pensar por meia hora foi quando eu estava depurando uma lógica de consulta do Moonlight e enfiando ali uma transferência de blindagem (shielded) da Phoenix.
As jogadas do Dusk são de duas pernas: o Moonlight é um livro-razão transparente, o saldo é direto “na conta”; a Phoenix é um UTXO com endereços ofuscados, então o saldo fica escondido dentro do note. Entre essas duas coisas, o Transfer Contract atua como tradutor — na transferência do público para o blindado, primeiro você deduz o saldo e depois cunha o note; na transferência do blindado para o público, primeiro queima o note e depois aumenta o saldo. Soa bem claro, certo? Só que, quando você escreve uma API de consulta e quer exibir de uma vez a soma dos saldos dos dois lados, precisa tratar ao mesmo tempo o estado da conta e dois conjuntos de dados em formatos totalmente diferentes: um para a conta e outro para o conteúdo cifrado do note. Os novatos da minha equipe, na primeira reação, somaram o value do note como se fosse saldo — e a transação vai direto pro brejo quando você transmite, porque o note da Phoenix precisa primeiro validar a prova de propriedade para poder decifrar o valor; isso não tem nada a ver com o timing de leitura de saldo do Moonlight.
O “buraco” de Gas é ainda mais invisível. Nas transações públicas, você estima normalmente e, na prática, fica bem perto; mas nas blindadas, precisa gerar e verificar provas ZK, e a complexidade do circuito de prova fica diretamente acoplada à quantidade de notes e às condições/constraints daquela transação. Eu testei uma transferência Phoenix com 2 inputs de note e 3 outputs de note: o consumo de Gas ficou quase dois níveis acima do de uma transação pública na mesma ordem de grandeza. As constantes de Gas que aparecem na documentação só servem como referência de piso; antes de ir para produção, se você não rodar algumas simulações na testnet com parâmetros reais, nem dá para você colocar aquele teto de Gas com confiança — coloca pouco e a transação reverte, coloca muito e você só queima dinheiro à toa.
O que eu ainda não entendi completamente é que, nos tutoriais oficiais do Dusk, as explicações para cenários “de borda” desse tipo — consulta híbrida + chamada cruzada entre modelos — são bem vagas. @Dusk $DUSK #dusk
A alta do “grande pão” voltou a disparar, e o BTC continua muito forte.
Mas o que me fez parar e pensar por meia hora foi quando eu estava depurando uma lógica de consulta do Moonlight e enfiando ali uma transferência de blindagem (shielded) da Phoenix.
As jogadas do Dusk são de duas pernas: o Moonlight é um livro-razão transparente, o saldo é direto “na conta”; a Phoenix é um UTXO com endereços ofuscados, então o saldo fica escondido dentro do note. Entre essas duas coisas, o Transfer Contract atua como tradutor — na transferência do público para o blindado, primeiro você deduz o saldo e depois cunha o note; na transferência do blindado para o público, primeiro queima o note e depois aumenta o saldo. Soa bem claro, certo? Só que, quando você escreve uma API de consulta e quer exibir de uma vez a soma dos saldos dos dois lados, precisa tratar ao mesmo tempo o estado da conta e dois conjuntos de dados em formatos totalmente diferentes: um para a conta e outro para o conteúdo cifrado do note. Os novatos da minha equipe, na primeira reação, somaram o value do note como se fosse saldo — e a transação vai direto pro brejo quando você transmite, porque o note da Phoenix precisa primeiro validar a prova de propriedade para poder decifrar o valor; isso não tem nada a ver com o timing de leitura de saldo do Moonlight.
O “buraco” de Gas é ainda mais invisível. Nas transações públicas, você estima normalmente e, na prática, fica bem perto; mas nas blindadas, precisa gerar e verificar provas ZK, e a complexidade do circuito de prova fica diretamente acoplada à quantidade de notes e às condições/constraints daquela transação. Eu testei uma transferência Phoenix com 2 inputs de note e 3 outputs de note: o consumo de Gas ficou quase dois níveis acima do de uma transação pública na mesma ordem de grandeza. As constantes de Gas que aparecem na documentação só servem como referência de piso; antes de ir para produção, se você não rodar algumas simulações na testnet com parâmetros reais, nem dá para você colocar aquele teto de Gas com confiança — coloca pouco e a transação reverte, coloca muito e você só queima dinheiro à toa.
O que eu ainda não entendi completamente é que, nos tutoriais oficiais do Dusk, as explicações para cenários “de borda” desse tipo — consulta híbrida + chamada cruzada entre modelos — são bem vagas. @Dusk $DUSK #dusk