A página de pagamento ficou travada por cinco segundos e, com um leve tremor no dedo, toquei de novo. No pagamento comum ainda dá para consultar duas movimentações; mas em transações de privacidade, quando valores e participantes são ocultados, como é que a rede pode saber que você não gastou duas vezes o mesmo dinheiro?
Seguindo essa pergunta, eu analisei novamente o Phoenix do @Dusk . Em vez de registrar o dinheiro como saldo público, ele o divide em notas criptografadas (notes) e grava o comprometimento (commitment) dessas notas na árvore de Merkle. Na hora de gastar, as provas de conhecimento zero (zero-knowledge) fazem a verificação de que aquela note realmente existe, está sob controle do usuário e que há conservação entre entradas e saídas — sem revelar o valor específico nem as notes correspondentes.
O que realmente “detecta o double-spend” são os nullifiers. Dá para entendê-los como uma marca de inutilização (tag) única que fica quando uma note é usada. O mundo externo não consegue, a partir dela, reconstruir a note original, mas a rede consegue checar se essa marca já apareceu. Se a mesma note for construída para duas transações diferentes, elas entram em conflito no mesmo nullifier, e as duas não podem ser válidas ao mesmo tempo.
A documentação do Dusk também esclarece: quando ocorre conflito de nullifier entre transações no mempool, apenas uma transação nova com Gas estritamente mais alto pode substituir a antiga. Reenviar com um aumento de taxa pode ser, na prática, uma tentativa de substituir o pagamento, não de criar uma nova transação. Porém, uma vez que a transação entra em um bloco aceito e é executada, mesmo que o contrato retorne erro, as notes e o Gas envolvidos são consumidos; e só depois que o bloco for considerado finalized é que aquilo vira um desfecho realmente definitivo (final).
Então, o que a criptografia resolve é a impossibilidade de copiar ativos — mas a carteira ainda precisa explicar ao usuário o que está pendente, o que foi substituído, o que falhou na execução e o que acabou confirmado. Exibir apenas “falhou” não impede que o usuário tente repetidas vezes.
$DUSK é Gas e também o ativo em garantia (staking), mas isso não deve ser usado como endosso da experiência do produto. Eu preferiria ver se a carteira consegue mostrar a relação de substituição, o motivo do consumo das notes e o status de finalidade. A privacidade pode esconder detalhes, mas não pode esconder se a transação aconteceu.
#dusk $DUSK
Seguindo essa pergunta, eu analisei novamente o Phoenix do @Dusk . Em vez de registrar o dinheiro como saldo público, ele o divide em notas criptografadas (notes) e grava o comprometimento (commitment) dessas notas na árvore de Merkle. Na hora de gastar, as provas de conhecimento zero (zero-knowledge) fazem a verificação de que aquela note realmente existe, está sob controle do usuário e que há conservação entre entradas e saídas — sem revelar o valor específico nem as notes correspondentes.
O que realmente “detecta o double-spend” são os nullifiers. Dá para entendê-los como uma marca de inutilização (tag) única que fica quando uma note é usada. O mundo externo não consegue, a partir dela, reconstruir a note original, mas a rede consegue checar se essa marca já apareceu. Se a mesma note for construída para duas transações diferentes, elas entram em conflito no mesmo nullifier, e as duas não podem ser válidas ao mesmo tempo.
A documentação do Dusk também esclarece: quando ocorre conflito de nullifier entre transações no mempool, apenas uma transação nova com Gas estritamente mais alto pode substituir a antiga. Reenviar com um aumento de taxa pode ser, na prática, uma tentativa de substituir o pagamento, não de criar uma nova transação. Porém, uma vez que a transação entra em um bloco aceito e é executada, mesmo que o contrato retorne erro, as notes e o Gas envolvidos são consumidos; e só depois que o bloco for considerado finalized é que aquilo vira um desfecho realmente definitivo (final).
Então, o que a criptografia resolve é a impossibilidade de copiar ativos — mas a carteira ainda precisa explicar ao usuário o que está pendente, o que foi substituído, o que falhou na execução e o que acabou confirmado. Exibir apenas “falhou” não impede que o usuário tente repetidas vezes.
$DUSK é Gas e também o ativo em garantia (staking), mas isso não deve ser usado como endosso da experiência do produto. Eu preferiria ver se a carteira consegue mostrar a relação de substituição, o motivo do consumo das notes e o status de finalidade. A privacidade pode esconder detalhes, mas não pode esconder se a transação aconteceu.
#dusk $DUSK
