Nestes dois dias eu reli de novo toda a estrutura de transações da Phoenix; desta vez, em vez disso, desmontei uma transação em partes para ver exatamente o que dá para observar on-chain e o que não dá.
━━━━━━━━━━━━━━
▎O que existe escondido na nota (note)
A Phoenix usa um modelo UTXO: cada parte de um ativo na blockchain é chamada de note. Dentro de uma note, são empacotados três itens: um compromisso (commitment) do valor (não é um número em texto claro, e sim o valor comprometido criptografado), um fator de cegamento (em termos simples, é um “sal” aleatório adicionado ao commitment para impedir que alguém adivinhe o valor por colisão), e também um número aleatório único (para garantir que cada note seja única e não colida com nenhuma outra).
Esses três itens juntos fazem com que, na cadeia, o que se veja seja apenas um monte de dados criptografados: quanto foi transferido, quanto essa note “vale” de fato, um observador externo não consegue determinar. Mesmo assim, a rede ainda consegue verificar que as somas desses commitments fecham (saldo) sem precisar descriptografar nenhum número específico.
━━━━━━━━━━━━━━
▎Para evitar double-spend usando nullifier
Um ponto que achei bem engenhoso nesse design é que ele não depende de “apagar a note antiga” para impedir gasto repetido. Em vez disso, ele se baseia em publicar uma credencial de consumo (consumption proof) que não pode ser vinculada de volta à note original.
Quando você gasta uma note, é gerado um nullifier correspondente. Isso é calculado de forma determinística, mas para um terceiro ele não consegue, de forma alguma, deduzir a qual note original aquele nullifier corresponde. A rede só precisa observar se “esse nullifier apareceu antes”; se apareceu, significa que a note correspondente já foi gasta. Se alguém tentar gastar a mesma note novamente, o sistema vai gerar o mesmo nullifier e ele vai colidir com o registro existente, então a operação é rejeitada imediatamente.
No processo inteiro, não fica exposto “quem gastou o quê”; basta usar detecção de colisão.
━━━━━━━━━━━━━━
▎Hash Poseidon — a base que sustenta todo o estado de privacidade
O estado de privacidade precisa ser guardado em uma Merkle tree, para permitir provas de inclusão de membros (ou seja, provar que “essa note de fato existe dentro da árvore de estado”).
Colocar funções de hash comuns dentro de um circuito zk custa caro. O Poseidon foi desenhado especificamente para ser amigável a zk: a estrutura do algoritmo combina melhor com o sistema de provas, reduzindo bastante o custo de cálculos de hash dentro do circuito. Sem esse tipo de hash amigável a zk, a geração das provas da árvore de estado de privacidade ficaria lenta demais para ser utilizável.
@Dusk_Foundation $DUSK #dusk
Na transação da Phoenix, qual mecanismo impede que ativos ocultos sejam gastos duas vezes (double-spend)?