Eu costumava ver @Dusk falando ao mesmo tempo de Moonlight e Phoenix e achava que era apenas “transferência comum” versus “transferência de privacidade”, cada uma com um conjunto de funções, repetindo o trabalho. Ao ler juntos a documentação do modelo de transações e as instruções de integração da exchange, percebi que os dois modelos não são para exibir tecnologia: é um reconhecimento ativo, na mesma camada de liquidação, de que alguns fluxos de fundos precisam ser públicos, enquanto outros não devem expor valores e relações a todos.
Moonlight é um modelo de contas públicas. Saldo, remetente, destinatário e valor ficam visíveis; isso torna cenários como recargas via exchange, tesouraria (fundo do tesouro) e situações que exigem reconciliação pública mais fáceis. Phoenix, por sua vez, coloca os fundos em um note criptografado e usa provas de conhecimento zero para confirmar que não há gasto duplo e que o saldo é suficiente, sem revelar ao público o valor específico e a note correspondente. Quando for necessária auditoria, é possível fazer divulgação seletiva por meio de uma viewing key.
O maior mal-entendido aqui é a ideia de que, “como há privacidade, então o navegador não consegue ver nada”. O navegador oficial ainda consegue ver metadados públicos como blocos, tipo de transação, taxas e gas—e o que exatamente fica visível depende do modelo de transação e do contrato. Do outro lado, uma exchange também não pode tratar Phoenix como se fosse Moonlight e simplesmente fazer um “scan” direto: a documentação oficial de integração recomenda explicitamente que recargas sejam feitas usando Moonlight; para saldo de privacidade, é necessário primeiro transferir para uma conta pública. A lógica de custódia e de varredura é completamente diferente.
Então o desafio do $DUSK não é provar que a privacidade funciona, e sim garantir que o usuário, ao alternar entre o modo público e o de privacidade, não siga o caminho errado. Se o #dusk realmente vai entrar em fluxos de fundos regulados, a privacidade padrão, a divulgação sob demanda e a custódia previsível precisam coexistir. Vocês estão mais preocupados com a transparência total vazar posições (exposições) ou com o fato de que os dois modelos tornam o produto excessivamente complexo?
Moonlight é um modelo de contas públicas. Saldo, remetente, destinatário e valor ficam visíveis; isso torna cenários como recargas via exchange, tesouraria (fundo do tesouro) e situações que exigem reconciliação pública mais fáceis. Phoenix, por sua vez, coloca os fundos em um note criptografado e usa provas de conhecimento zero para confirmar que não há gasto duplo e que o saldo é suficiente, sem revelar ao público o valor específico e a note correspondente. Quando for necessária auditoria, é possível fazer divulgação seletiva por meio de uma viewing key.
O maior mal-entendido aqui é a ideia de que, “como há privacidade, então o navegador não consegue ver nada”. O navegador oficial ainda consegue ver metadados públicos como blocos, tipo de transação, taxas e gas—e o que exatamente fica visível depende do modelo de transação e do contrato. Do outro lado, uma exchange também não pode tratar Phoenix como se fosse Moonlight e simplesmente fazer um “scan” direto: a documentação oficial de integração recomenda explicitamente que recargas sejam feitas usando Moonlight; para saldo de privacidade, é necessário primeiro transferir para uma conta pública. A lógica de custódia e de varredura é completamente diferente.
Então o desafio do $DUSK não é provar que a privacidade funciona, e sim garantir que o usuário, ao alternar entre o modo público e o de privacidade, não siga o caminho errado. Se o #dusk realmente vai entrar em fluxos de fundos regulados, a privacidade padrão, a divulgação sob demanda e a custódia previsível precisam coexistir. Vocês estão mais preocupados com a transparência total vazar posições (exposições) ou com o fato de que os dois modelos tornam o produto excessivamente complexo?
