Testei aquele esquema de duas contas que faz transbordo/transferência no Dusk e senti um calafrio na nuca — privacidade é para ser usada pelos usuários, não para servir de alvo para desenvolvedores xingarem.
Ontem à noite vi um post de testes em que o autor foi mexendo no Moonlight e no Phoenix do Dusk, alternando algumas transações, e quanto mais brincava, mais estranho ficava.
Dois endereços derivados do mesmo conjunto de seed/frase mnemônica — um transparente como um aquário de vidro, outro uma caixa-preta em que nem o saldo dá para ver. No lado do usuário, você toca em “trocar” e pronto; mas, na camada mais baixa do protocolo, são duas lógicas de contabilidade completamente diferentes: o Moonlight é um modelo de conta, em que o saldo é escrito diretamente em contratos; o Phoenix é UTXO + note, montado com compromissos Pedersen e nullifiers. @Dusk
Você me diz: o design é bom, não é? É. Mas tenta escrever um contrato de empréstimo/devolução em cima disso — na liquidação você precisa gerenciar os dois estados ao mesmo tempo; o saldo em ETH e os nullifiers das notas de privacidade têm que ser contabilizados juntos. Escrever a lógica do Moonlight dá medo de atacarem grandes contas; escrever a lógica do Phoenix dá medo de o regulador simplesmente cortar suas interfaces. Na documentação, uma frase bem leve tipo “escolha conforme a necessidade”. Para quem é dev, isso dá vontade de xingar — isso não é modularização; é jogar uma questão de múltipla escolha para a comunidade pagar a conta.
O que mais me deu calafrios foi outra análise. A história dos tokens de valores mobiliários da NPEX é bem contada, mas no fim tudo ficou de joelhos no Moonlight. A turma do MiCA nem quer deixar passar auditoria trimestral das reservas de stablecoin; você vai lá e diz: “tenho zk-proof, consigo escolher uma visão ofuscada”? A reação do regulador é sempre a mesma: o código consegue exportar o Excel em um clique? Aquele “divulgação seletiva” do Phoenix, aos olhos de advogados, é uma caixa-preta tecnológica — se der ruim, quem assina? Instituições não são bobas: se é coisa de ouro e dinheiro de verdade, elas preferem até “peladas” a não ter como responsabilizar.
Agora, a taxa de staking on-chain de 36% parece ok, mas gente do meio sabe: é todo mundo dando show para si mesmo nos nós. O DuskEVM foi lançado, mas se no ano que vem a coluna Phoenix ainda estiver vazia na lista de Dapps, o projeto vai virar uma chain EVM com plugin de privacidade — a narrativa desaba pela metade.
Não é que eu diga que a tecnologia não presta — essa combinação de UTXO + ZK realmente é nível pesado. O maior fracasso é o produto não ter dado uma resposta padrão. Usuário comum nem consegue guardar a seed; e ainda por cima você faz ele ficar em dúvida, a cada transferência, “hoje eu abro a privacidade ou não?”.
Eu ia deixar um acompanhamento no observatório, mas desisti. Vou ver o primeiro caso em que alguém jogue uma pool de liquidez central dentro do Phoenix e que receba um endosso por escrito do regulador da União Europeia — aí sim.
#dusk $DUSK
Ontem à noite vi um post de testes em que o autor foi mexendo no Moonlight e no Phoenix do Dusk, alternando algumas transações, e quanto mais brincava, mais estranho ficava.
Dois endereços derivados do mesmo conjunto de seed/frase mnemônica — um transparente como um aquário de vidro, outro uma caixa-preta em que nem o saldo dá para ver. No lado do usuário, você toca em “trocar” e pronto; mas, na camada mais baixa do protocolo, são duas lógicas de contabilidade completamente diferentes: o Moonlight é um modelo de conta, em que o saldo é escrito diretamente em contratos; o Phoenix é UTXO + note, montado com compromissos Pedersen e nullifiers. @Dusk
Você me diz: o design é bom, não é? É. Mas tenta escrever um contrato de empréstimo/devolução em cima disso — na liquidação você precisa gerenciar os dois estados ao mesmo tempo; o saldo em ETH e os nullifiers das notas de privacidade têm que ser contabilizados juntos. Escrever a lógica do Moonlight dá medo de atacarem grandes contas; escrever a lógica do Phoenix dá medo de o regulador simplesmente cortar suas interfaces. Na documentação, uma frase bem leve tipo “escolha conforme a necessidade”. Para quem é dev, isso dá vontade de xingar — isso não é modularização; é jogar uma questão de múltipla escolha para a comunidade pagar a conta.
O que mais me deu calafrios foi outra análise. A história dos tokens de valores mobiliários da NPEX é bem contada, mas no fim tudo ficou de joelhos no Moonlight. A turma do MiCA nem quer deixar passar auditoria trimestral das reservas de stablecoin; você vai lá e diz: “tenho zk-proof, consigo escolher uma visão ofuscada”? A reação do regulador é sempre a mesma: o código consegue exportar o Excel em um clique? Aquele “divulgação seletiva” do Phoenix, aos olhos de advogados, é uma caixa-preta tecnológica — se der ruim, quem assina? Instituições não são bobas: se é coisa de ouro e dinheiro de verdade, elas preferem até “peladas” a não ter como responsabilizar.
Agora, a taxa de staking on-chain de 36% parece ok, mas gente do meio sabe: é todo mundo dando show para si mesmo nos nós. O DuskEVM foi lançado, mas se no ano que vem a coluna Phoenix ainda estiver vazia na lista de Dapps, o projeto vai virar uma chain EVM com plugin de privacidade — a narrativa desaba pela metade.
Não é que eu diga que a tecnologia não presta — essa combinação de UTXO + ZK realmente é nível pesado. O maior fracasso é o produto não ter dado uma resposta padrão. Usuário comum nem consegue guardar a seed; e ainda por cima você faz ele ficar em dúvida, a cada transferência, “hoje eu abro a privacidade ou não?”.
Eu ia deixar um acompanhamento no observatório, mas desisti. Vou ver o primeiro caso em que alguém jogue uma pool de liquidez central dentro do Phoenix e que receba um endosso por escrito do regulador da União Europeia — aí sim.
#dusk $DUSK
