Na semana passada ajudei um cliente a fazer o acerto de uma transferência internacional. Como a rede estava lenta, precisei confirmar duas vezes; o sistema então classificou diretamente como “transação duplicada” e bloqueou. Ficou preso por horas, e ninguém dava uma explicação. Isso, na prática, na blockchain é o mesmo problema, mas a solução é completamente diferente.
O modelo de conta da Dusk para a Moonlight (ou seja, aquele modelo de conta transparente) depende do nonce para evitar replay — cada conta fica vinculada a um contador; o nonce de cada transação precisa ser exatamente 1 maior do que o valor atual. Se for mais ou menos, a rede rejeita diretamente. Não é “o sistema adivinha se você tocou de novo” depois, e sim os próprios números travam a ordem: ninguém consegue culpar ninguém, e não precisa esperar que o suporte ao cliente decida.
Isso não tem nada a ver com a abordagem da Phoenix para prevenir double-spend — a Phoenix usa nullifier: marca de forma única um UTXO para indicar que já foi gasto; depois de gasto, fica inválido. A Moonlight usa nonce: incrementa em ordem para travar o replay. São dois modelos de conta diferentes, com duas lógicas diferentes de anti-duplicação. O whitepaper separa isso com bastante clareza; não é a mesma base de código com nomes diferentes reutilizada dos dois lados.
Esse design resolve “o que fazer quando a mesma transação é recebida duas vezes pela rede”, mas não resolve “o que fazer quando o usuário escorrega e transfere para a conta errada” — o nonce controla a ordem e a unicidade, não se o conteúdo da transação em si está correto; nessa parte, ainda é necessário que a interação de confirmação no lado da carteira faça o papel de garantia.
$DUSK
#dusk @Dusk
O modelo de conta da Dusk para a Moonlight (ou seja, aquele modelo de conta transparente) depende do nonce para evitar replay — cada conta fica vinculada a um contador; o nonce de cada transação precisa ser exatamente 1 maior do que o valor atual. Se for mais ou menos, a rede rejeita diretamente. Não é “o sistema adivinha se você tocou de novo” depois, e sim os próprios números travam a ordem: ninguém consegue culpar ninguém, e não precisa esperar que o suporte ao cliente decida.
Isso não tem nada a ver com a abordagem da Phoenix para prevenir double-spend — a Phoenix usa nullifier: marca de forma única um UTXO para indicar que já foi gasto; depois de gasto, fica inválido. A Moonlight usa nonce: incrementa em ordem para travar o replay. São dois modelos de conta diferentes, com duas lógicas diferentes de anti-duplicação. O whitepaper separa isso com bastante clareza; não é a mesma base de código com nomes diferentes reutilizada dos dois lados.
Esse design resolve “o que fazer quando a mesma transação é recebida duas vezes pela rede”, mas não resolve “o que fazer quando o usuário escorrega e transfere para a conta errada” — o nonce controla a ordem e a unicidade, não se o conteúdo da transação em si está correto; nessa parte, ainda é necessário que a interação de confirmação no lado da carteira faça o papel de garantia.
$DUSK
#dusk @Dusk