#dusk $DUSK Hoje estou lendo o documento do modelo de transação da Phoenix em @Dusk e travo em um conceito básico (mas fácil de ignorar) sobre cadeias de privacidade: a camada de protocolo de $DUSK simplesmente não tem “conta”.

Na Ethereum, uma cadeia transparente, cada endereço é uma conta; o saldo e o histórico de transações são visíveis para toda a rede. Mas a Phoenix usa uma abordagem UTXO — a camada de protocolo não armazena contas; ela armazena uma série de coisas chamadas “notes”. Cada note contém um valor e uma condição de gasto. A transação é o processo de consumir notes antigas e gerar novas notes. O hash das novas notes é adicionado a uma árvore Merkle, cujas folhas guardam as impressões digitais de todas as notes da rede.

O desenho para evitar gastos duplos aqui fica bem interessante. Cada transação vem acompanhada de um conjunto de valores determinísticos chamado “nullifier”; cada nullifier corresponde a uma note consumida, marcando-a como inválida. Mas a forma como o nullifier é gerado é tratada via criptografia: um observador externo, ao ver um nullifier aparecer, sabe que “houve uma note gasta”, porém não consegue relacionar aquele nullifier a uma note específica. A rede confirma a anulação, mas não sabe de quem era a anulação.

Vou fazer uma analogia: isso não é como auditoria de banco, em que você abre numa página específica e enxerga todo o fluxo de uma pessoa. É mais como triturar cada recibo e jogar no triturador de papel, e então avisar ao sistema via criptografia: “este recibo já foi anulado”. O sistema confirma que a anulação é válida, mas a pessoa que mexeu no triturador não consegue remontar o recibo original nem saber a quem o recibo pertencia.

Só que esse desenho não é custo zero. À medida que a quantidade de notes cresce, a árvore Merkle aumenta e cada nó precisa manter a estrutura completa da árvore; a geração do nullifier depende de pressupostos criptográficos de base e, se os parâmetros forem escolhidos de forma inadequada, a proteção de privacidade vira quase nada. A documentação oficial publica detalhes do protocolo, mas em ambiente de produção, a taxa de colisão dos nullifiers e a velocidade de crescimento da árvore precisam ser comparadas continuamente após o lançamento na rede principal.

Ao olhar para a camada de privacidade de #dusk , eu não vou ficar só na etiqueta “usa UTXO”. O que realmente precisa ser rastreado é a curva de crescimento do número de notes, o tamanho do conjunto de nullifiers e a carga de armazenamento dos nós de validação. $DUSK embute a privacidade na base do protocolo, mas o custo de manutenção do livro-razão na camada de baixo, no fim, vai aparecer no desempenho de toda a rede.

#dusk @Dusk