A questão que realmente me fez parar e pensar foi: por que a Dusk projetou, ao mesmo tempo, os dois modelos de negociação Moonlight e Phoenix?
Moonlight é o modelo account-based divulgado publicamente no DuskDS. O estado das contas, os saldos e as informações de transações relacionadas são publicamente verificáveis; já o Phoenix segue a rota de shielded notes, confirmando transações válidas, fundos suficientes e ausência de double-spend por meio de provas de conhecimento zero, enquanto oculta as informações sensíveis das transações.
Depois gastei um pouco de tempo analisando o Transfer Contract, e senti que talvez esse seja o ponto-chave para entender toda a arquitetura. Ele não é apenas uma porta de entrada para transferências; é responsável por receber payloads de diferentes tipos de transações e encaminhá-los para as lógicas de validação correspondentes, permitindo que transações públicas e transações de privacidade funcionem dentro do mesmo sistema de liquidação. Nos históricos oficiais de transações, também dá para encontrar registros de conversão como Phoenix-to-Moonlight.
Ao chegar aqui, minha compreensão do que a Dusk chama de “privacidade” também mudou um pouco. Não é simplesmente esconder ativos; é mais como redefinir, dentro da mesma infraestrutura, o escopo de visibilidade das informações para diferentes participantes: quem consegue ver o quê e em que momento.
Indo mais adiante, no Phoenix 2.0, essa ideia fica ainda mais clara: as informações das transações não são divulgadas ao público, mas o destinatário consegue identificar o remetente; e a viewing key oferece a capacidade de divulgação seletiva.
Esses modelos de transações finalmente operam no sistema de liquidação do DuskDS, enquanto o DuskEVM fornece o ambiente de execução compatível com EVM. Agora, olhando para $DUSK , o que me preocupa não é apenas o rótulo de “privacidade”, mas sim como a Dusk tenta encontrar um ponto de equilíbrio mais razoável entre verificabilidade pública, proteção de privacidade e necessidades de cenários financeiros.
#dusk $DUSK @Dusk
Moonlight é o modelo account-based divulgado publicamente no DuskDS. O estado das contas, os saldos e as informações de transações relacionadas são publicamente verificáveis; já o Phoenix segue a rota de shielded notes, confirmando transações válidas, fundos suficientes e ausência de double-spend por meio de provas de conhecimento zero, enquanto oculta as informações sensíveis das transações.
Depois gastei um pouco de tempo analisando o Transfer Contract, e senti que talvez esse seja o ponto-chave para entender toda a arquitetura. Ele não é apenas uma porta de entrada para transferências; é responsável por receber payloads de diferentes tipos de transações e encaminhá-los para as lógicas de validação correspondentes, permitindo que transações públicas e transações de privacidade funcionem dentro do mesmo sistema de liquidação. Nos históricos oficiais de transações, também dá para encontrar registros de conversão como Phoenix-to-Moonlight.
Ao chegar aqui, minha compreensão do que a Dusk chama de “privacidade” também mudou um pouco. Não é simplesmente esconder ativos; é mais como redefinir, dentro da mesma infraestrutura, o escopo de visibilidade das informações para diferentes participantes: quem consegue ver o quê e em que momento.
Indo mais adiante, no Phoenix 2.0, essa ideia fica ainda mais clara: as informações das transações não são divulgadas ao público, mas o destinatário consegue identificar o remetente; e a viewing key oferece a capacidade de divulgação seletiva.
Esses modelos de transações finalmente operam no sistema de liquidação do DuskDS, enquanto o DuskEVM fornece o ambiente de execução compatível com EVM. Agora, olhando para $DUSK , o que me preocupa não é apenas o rótulo de “privacidade”, mas sim como a Dusk tenta encontrar um ponto de equilíbrio mais razoável entre verificabilidade pública, proteção de privacidade e necessidades de cenários financeiros.
#dusk $DUSK @Dusk