Eu vi pela primeira vez o sistema de contas duplas de @Dusk e, sem querer, entendi como “uma conta pública, uma conta privada e é só alternar na carteira”. Mas o verdadeiro problema dessa coisa não está nos botões da interface; é que, por baixo, a estrutura do livro-razão é completamente diferente. $DUSK
Moonlight usa um modelo de conta: relações entre saldo e endereços e o fluxo de fundos ficam mais fáceis de auditar. Para exchanges, custodiante e instituições que fazem KYC, esse caminho público é importante, porque as verificações de conformidade precisam explicar de onde o dinheiro vem e para onde vai. Já o Phoenix é outra lógica: ele combina a estrutura UTXO com provas de conhecimento zero PLONK para esconder o valor e as informações do contraparte. O verificador só confirma que a transação é válida, sem precisar ver os dados originais. $BTC
Então, ir do Moonlight para o Phoenix não é só trocar o modo de exibição. O saldo público precisa primeiro passar pelo shield, regenerar compromissos de privacidade; localmente também precisa gerar provas e, na cadeia, validar. Esse processo é como pegar uma conta aberta e remontá-la dentro de uma caixa lacrada — não é que o produto simplesmente tenha deixado de fazer um atalho; é que, entre o modelo de conta e o UTXO de privacidade, precisa haver uma transformação criptográfica.
Isso também explica por que operações entre “trilhos” ficam mais pesadas. O caminho comum do Moonlight para transferências é mais curto e barato; depois que entra no Phoenix, existem geração de provas, interações com contratos e esperas de confirmação. Para usuários de valores pequenos, esses custos ficam bem evidentes. No fim, era só para proteger a privacidade de uma transferência, mas a operação ficou mais complexa, e as taxas subiram — e a experiência naturalmente piora.
Mas, ao mudar para cenários de RWA ou negociações institucionais, o design de duplo trilho do Dusk mostra sua intenção. O Moonlight pode lidar com partes que “precisam ser vistas” — conformidade, custódia, auditoria; o Phoenix cuida de cotações, contraparte e ajustes de posição, que “não são adequados” para todo o mercado ficar olhando. O que ele quer resolver não é apenas transferências privadas; é como dividir responsabilidades quando privacidade e conformidade coexistem. $ETH
#dusk Agora, o maior obstáculo é que, quando o usuário move ativos entre duas trilhas, precisa perceber o processo de conversão e também pagar e esperar por ele. Se depois for possível fazer shield em lote, agregação de provas e abstração de roteamento, comprimindo várias operações para uma experiência mais parecida com um único acerto, então o uso do Phoenix terá muito mais alcance. Antes disso, o Moonlight ainda vai ser a porta de entrada principal para a maioria das pessoas.
Moonlight usa um modelo de conta: relações entre saldo e endereços e o fluxo de fundos ficam mais fáceis de auditar. Para exchanges, custodiante e instituições que fazem KYC, esse caminho público é importante, porque as verificações de conformidade precisam explicar de onde o dinheiro vem e para onde vai. Já o Phoenix é outra lógica: ele combina a estrutura UTXO com provas de conhecimento zero PLONK para esconder o valor e as informações do contraparte. O verificador só confirma que a transação é válida, sem precisar ver os dados originais. $BTC
Então, ir do Moonlight para o Phoenix não é só trocar o modo de exibição. O saldo público precisa primeiro passar pelo shield, regenerar compromissos de privacidade; localmente também precisa gerar provas e, na cadeia, validar. Esse processo é como pegar uma conta aberta e remontá-la dentro de uma caixa lacrada — não é que o produto simplesmente tenha deixado de fazer um atalho; é que, entre o modelo de conta e o UTXO de privacidade, precisa haver uma transformação criptográfica.
Isso também explica por que operações entre “trilhos” ficam mais pesadas. O caminho comum do Moonlight para transferências é mais curto e barato; depois que entra no Phoenix, existem geração de provas, interações com contratos e esperas de confirmação. Para usuários de valores pequenos, esses custos ficam bem evidentes. No fim, era só para proteger a privacidade de uma transferência, mas a operação ficou mais complexa, e as taxas subiram — e a experiência naturalmente piora.
Mas, ao mudar para cenários de RWA ou negociações institucionais, o design de duplo trilho do Dusk mostra sua intenção. O Moonlight pode lidar com partes que “precisam ser vistas” — conformidade, custódia, auditoria; o Phoenix cuida de cotações, contraparte e ajustes de posição, que “não são adequados” para todo o mercado ficar olhando. O que ele quer resolver não é apenas transferências privadas; é como dividir responsabilidades quando privacidade e conformidade coexistem. $ETH
#dusk Agora, o maior obstáculo é que, quando o usuário move ativos entre duas trilhas, precisa perceber o processo de conversão e também pagar e esperar por ele. Se depois for possível fazer shield em lote, agregação de provas e abstração de roteamento, comprimindo várias operações para uma experiência mais parecida com um único acerto, então o uso do Phoenix terá muito mais alcance. Antes disso, o Moonlight ainda vai ser a porta de entrada principal para a maioria das pessoas.