Desmontei a arquitetura de privacidade do @Dusk e encontrei alguns problemas que foram encobertos por certas narrativas de "privacidade compatível L1".
Primeira camada: duas trilhas, dois tipos de custo. $DUSK . A mainnet roda, ao mesmo tempo, Moonlight (transparente) e Phoenix (privado). O Moonlight oferece uma experiência EVM convencional; mas no Phoenix, cada transação exige que o cliente gere uma prova zk-SNARK. O wallet-core suporta terceirizar a geração de provas para um Prover externo — e esse desenho, por si só, indica que o dispositivo local não aguenta a carga computacional de circuitos de alta frequência.
Segunda camada: KYC como porta de entrada
O modelo de licenciamento da Citadel usado em RWA exige que o KYC seja concluído antes. Isso não é um problema em si, mas faz com que o tráfego atual da mainnet fique preso ao intervalo de "pequenos lotes institucionais, liquidações de alto valor". A estabilidade que você vê é resultado de um cenário de baixa concorrência.
Terceira camada: restrições distorcem a validação
Como a participação de transações do Phoenix ainda não é alta, a carga de provas é limitada. O sistema é estável em ambiente controlado, mas isso não significa que, após uma adoção massiva de varejo com alta concorrência, o poder de computação do cliente, a fila do Prover e o throughput dos validadores ainda consigam manter a eficiência. A mainnet consegue provar que "a privacidade funciona", mas não prova que "a privacidade aguenta o volume".
Quarta camada: o usuário pode ficar travado no último passo
Depois que o usuário conclui o KYC, bloqueia os ativos e inicia uma transação no Phoenix, se o poder de computação local não for suficiente ou se a fila do Prover estiver congestionada, a última etapa não sai. Se a DUSK quiser levar privacidade DeFi ao varejo, a expansão do Prover e os feedbacks de falha não podem ficar restritos apenas a atualizações técnicas.
Minha visão
Não vou usar o custo de ZK ou o KYC para negar #dusk ; privacidade L1 e blockchains sem permissão são caminhos diferentes. Mas "dar para rodar o fluxo" e "dar para aguentar volume" são coisas distintas. Quando a participação do Phoenix subir, a rede do Prover amadurecer e a otimização de circuitos complexos de contratos ficar em dia, aí sim vale observar a taxa de falhas, o tempo de prova e a fluidez na conversão entre modelos — para saber se é "privacidade que roda" ou "privacidade que aguenta volume".
Primeira camada: duas trilhas, dois tipos de custo. $DUSK . A mainnet roda, ao mesmo tempo, Moonlight (transparente) e Phoenix (privado). O Moonlight oferece uma experiência EVM convencional; mas no Phoenix, cada transação exige que o cliente gere uma prova zk-SNARK. O wallet-core suporta terceirizar a geração de provas para um Prover externo — e esse desenho, por si só, indica que o dispositivo local não aguenta a carga computacional de circuitos de alta frequência.
Segunda camada: KYC como porta de entrada
O modelo de licenciamento da Citadel usado em RWA exige que o KYC seja concluído antes. Isso não é um problema em si, mas faz com que o tráfego atual da mainnet fique preso ao intervalo de "pequenos lotes institucionais, liquidações de alto valor". A estabilidade que você vê é resultado de um cenário de baixa concorrência.
Terceira camada: restrições distorcem a validação
Como a participação de transações do Phoenix ainda não é alta, a carga de provas é limitada. O sistema é estável em ambiente controlado, mas isso não significa que, após uma adoção massiva de varejo com alta concorrência, o poder de computação do cliente, a fila do Prover e o throughput dos validadores ainda consigam manter a eficiência. A mainnet consegue provar que "a privacidade funciona", mas não prova que "a privacidade aguenta o volume".
Quarta camada: o usuário pode ficar travado no último passo
Depois que o usuário conclui o KYC, bloqueia os ativos e inicia uma transação no Phoenix, se o poder de computação local não for suficiente ou se a fila do Prover estiver congestionada, a última etapa não sai. Se a DUSK quiser levar privacidade DeFi ao varejo, a expansão do Prover e os feedbacks de falha não podem ficar restritos apenas a atualizações técnicas.
Minha visão
Não vou usar o custo de ZK ou o KYC para negar #dusk ; privacidade L1 e blockchains sem permissão são caminhos diferentes. Mas "dar para rodar o fluxo" e "dar para aguentar volume" são coisas distintas. Quando a participação do Phoenix subir, a rede do Prover amadurecer e a otimização de circuitos complexos de contratos ficar em dia, aí sim vale observar a taxa de falhas, o tempo de prova e a fluidez na conversão entre modelos — para saber se é "privacidade que roda" ou "privacidade que aguenta volume".