#dusk $DUSK @Dusk fiquei olhando os documentos do Dusk por quase quarenta minutos. Fiquei repetindo na cabeça uma pergunta: como, afinal, ficam as coisas entre Moonlight e Phoenix?
A Moonlight segue a rota de conta pública. Saldo, remetente, destinatário e valores ficam todos registrados na blockchain; qualquer pessoa pode ver. Isso é perfeito para cenários em que transparência é obrigatória, como recarga de exchanges e conciliação contábil institucional.
A Phoenix é outra lógica completamente diferente: os ativos viram um note criptografado, escondido dentro de uma árvore de Merkle. Quando você gasta um valor, não fica exposto exatamente qual note foi usado; você apenas envia um nullifier e uma prova ZKP. A rede consegue verificar que você tem saldo e que não houve double-spend, mas não dá para ver o valor nem o remetente. Quando for preciso auditar, dá para divulgar seletivamente usando uma chave de visualização.
No começo do mês, quando escrevi uma nota sobre transferências SEPA, me deparei com um problema parecido: conciliação entre dois sistemas bancários em que os status não batem é uma dor de cabeça enorme. Acabei sendo arrastado até duas da manhã.
Se uma blockchain também montasse dois livros-razão isolados, seria melhor que fosse como o sistema financeiro tradicional.
Naquela hora, eu estava meio irritado, sentindo que o documento não explicava esse ponto com clareza. Eu abri a seção de arquitetura de contratos do módulo Rusk. As duas primeiras partes não me disseram muito—basicamente só descreviam as estruturas de dados do Moonlight e da Phoenix. Foi só na quarta parte que eu entendi a intenção do design: ao ver que, na definição da interface do Transfer Contract, eles usaram um tipo enumerado para o payload.
O Transfer Contract é uma porta de entrada de coordenação. Ele recebe payloads em formatos diferentes—um no formato Moonlight, outro no formato Phoenix. O contrato não se importa de onde veio; ele só se importa com quais campos o payload traz e então faz o roteamento para a lógica de validação correspondente. A validação do Moonlight lê diretamente o estado da conta pública. A validação da Phoenix roda a proof de ZK. Depois que as duas validações passam, o resultado é gravado em uma mesma árvore global de estado.
Eu fiquei um tempo pensando para entender o ponto-chave dessa etapa: se você funde as árvores de estado dos dois sistemas em uma única árvore, então converter uma transação do livro público para uma privacy note nada mais é do que uma conversão de payload—não precisa de ponte entre cadeias, nem de protocolos complexos de sincronização. A atualização de estado é atômica: ou tudo funciona, ou tudo volta ao estado anterior.
A Moonlight segue a rota de conta pública. Saldo, remetente, destinatário e valores ficam todos registrados na blockchain; qualquer pessoa pode ver. Isso é perfeito para cenários em que transparência é obrigatória, como recarga de exchanges e conciliação contábil institucional.
A Phoenix é outra lógica completamente diferente: os ativos viram um note criptografado, escondido dentro de uma árvore de Merkle. Quando você gasta um valor, não fica exposto exatamente qual note foi usado; você apenas envia um nullifier e uma prova ZKP. A rede consegue verificar que você tem saldo e que não houve double-spend, mas não dá para ver o valor nem o remetente. Quando for preciso auditar, dá para divulgar seletivamente usando uma chave de visualização.
No começo do mês, quando escrevi uma nota sobre transferências SEPA, me deparei com um problema parecido: conciliação entre dois sistemas bancários em que os status não batem é uma dor de cabeça enorme. Acabei sendo arrastado até duas da manhã.
Se uma blockchain também montasse dois livros-razão isolados, seria melhor que fosse como o sistema financeiro tradicional.
Naquela hora, eu estava meio irritado, sentindo que o documento não explicava esse ponto com clareza. Eu abri a seção de arquitetura de contratos do módulo Rusk. As duas primeiras partes não me disseram muito—basicamente só descreviam as estruturas de dados do Moonlight e da Phoenix. Foi só na quarta parte que eu entendi a intenção do design: ao ver que, na definição da interface do Transfer Contract, eles usaram um tipo enumerado para o payload.
O Transfer Contract é uma porta de entrada de coordenação. Ele recebe payloads em formatos diferentes—um no formato Moonlight, outro no formato Phoenix. O contrato não se importa de onde veio; ele só se importa com quais campos o payload traz e então faz o roteamento para a lógica de validação correspondente. A validação do Moonlight lê diretamente o estado da conta pública. A validação da Phoenix roda a proof de ZK. Depois que as duas validações passam, o resultado é gravado em uma mesma árvore global de estado.
Eu fiquei um tempo pensando para entender o ponto-chave dessa etapa: se você funde as árvores de estado dos dois sistemas em uma única árvore, então converter uma transação do livro público para uma privacy note nada mais é do que uma conversão de payload—não precisa de ponte entre cadeias, nem de protocolos complexos de sincronização. A atualização de estado é atômica: ou tudo funciona, ou tudo volta ao estado anterior.
