#dusk $DUSK @Dusk Nesta semana li de ponta a ponta o artigo sobre o modelo de transações do Dusk para Phoenix (aquele do Citadel que tem uma seção dedicada ao Phoenix). Antes eu achava que ele não tinha diferenças fundamentais em relação a outros esquemas de privacidade baseados em UTXO; depois de terminar a leitura, percebi que os detalhes de design são bem mais cuidadosos do que eu imaginava.
No Phoenix, cada “ativo” em uma transação não é chamado de UTXO — é chamado de note. A rede não armazena a note em si; ela só salva o hash da note como um valor em uma folha de uma árvore Merkle. Ao gastar uma note, o usuário precisa enviar uma prova de conhecimento zero chamada tx_proof. Essa prova faz duas coisas ao mesmo tempo: (1) “invalidar” a note que será gasta (gerando um nullifier único, para impedir que o mesmo dinheiro seja gasto duas vezes), e (2) provar que o total do valor das novas notes geradas corresponde ao total das notes invalidada, sem criar dinheiro do nada. Do lado de fora, o que se vê é apenas “uma note antiga foi invalidada” e “uma note nova foi criada”; valores exatos e participantes não são visíveis.
O que realmente me fez sentir que o design foi muito bem pensado é a divisão de chaves: gastar uma note requer uma Secret Key, que apenas o dono da note conhece; mas se a sua intenção é apenas que um auditor ou órgão regulador veja quais notes você tem e qual é o valor criptografado nelas, você não precisa entregar a chave capaz de movimentar os fundos — basta compartilhar a View Key separadamente. Em outras palavras, “ver” e “movimentar” são duas chaves totalmente independentes; essa separação em si é uma base criptográfica para viabilizar “divulgação seletiva”, não apenas um discurso de marketing.
Além disso, o contrato de Transfer tem um detalhe que pode passar despercebido: ele faz uma combinação (combine) ativa de várias notes pequenas, para evitar que as folhas da árvore Merkle cresçam sem limite e prejudiquem o desempenho da rede. Esse tipo de design em que o “ledger” faz sua própria coleta de lixo no nível de base mostra que o time já estava fazendo previsões de engenharia nos estágios iniciais para os custos de armazenamento e de provas em execuções de longo prazo — em vez de esperar a árvore crescer demais para só então remediar.
Para desenvolvedores, essa mecânica significa que, ao construir uma aplicação no Phoenix, a distribuição e a gestão da View Key serão um problema de design de produto que não dá para evitar — isso determina quem consegue ver a posição (holding) do usuário sob quais condições. Se essa etapa não for bem desenhada, a palavra “privacidade” vira apenas um botão na interface da carteira, sem nenhuma restrição prática.
No Phoenix, cada “ativo” em uma transação não é chamado de UTXO — é chamado de note. A rede não armazena a note em si; ela só salva o hash da note como um valor em uma folha de uma árvore Merkle. Ao gastar uma note, o usuário precisa enviar uma prova de conhecimento zero chamada tx_proof. Essa prova faz duas coisas ao mesmo tempo: (1) “invalidar” a note que será gasta (gerando um nullifier único, para impedir que o mesmo dinheiro seja gasto duas vezes), e (2) provar que o total do valor das novas notes geradas corresponde ao total das notes invalidada, sem criar dinheiro do nada. Do lado de fora, o que se vê é apenas “uma note antiga foi invalidada” e “uma note nova foi criada”; valores exatos e participantes não são visíveis.
O que realmente me fez sentir que o design foi muito bem pensado é a divisão de chaves: gastar uma note requer uma Secret Key, que apenas o dono da note conhece; mas se a sua intenção é apenas que um auditor ou órgão regulador veja quais notes você tem e qual é o valor criptografado nelas, você não precisa entregar a chave capaz de movimentar os fundos — basta compartilhar a View Key separadamente. Em outras palavras, “ver” e “movimentar” são duas chaves totalmente independentes; essa separação em si é uma base criptográfica para viabilizar “divulgação seletiva”, não apenas um discurso de marketing.
Além disso, o contrato de Transfer tem um detalhe que pode passar despercebido: ele faz uma combinação (combine) ativa de várias notes pequenas, para evitar que as folhas da árvore Merkle cresçam sem limite e prejudiquem o desempenho da rede. Esse tipo de design em que o “ledger” faz sua própria coleta de lixo no nível de base mostra que o time já estava fazendo previsões de engenharia nos estágios iniciais para os custos de armazenamento e de provas em execuções de longo prazo — em vez de esperar a árvore crescer demais para só então remediar.
Para desenvolvedores, essa mecânica significa que, ao construir uma aplicação no Phoenix, a distribuição e a gestão da View Key serão um problema de design de produto que não dá para evitar — isso determina quem consegue ver a posição (holding) do usuário sob quais condições. Se essa etapa não for bem desenhada, a palavra “privacidade” vira apenas um botão na interface da carteira, sem nenhuma restrição prática.