#dusk $DUSK @Dusk
Ontem eu estava lendo a documentação de integração do exchange da Dusk quando fiquei preso em uma situação que parecia quase trivial: um saque havia sido enviado, mas a requisição teve timeout. Meu primeiro impulso foi enviá-lo novamente. Então eu parei: e se a primeira transação já tivesse chegado à rede?
A Dusk trata exatamente essa “zona cega”. Cada saque é construído e assinado uma única vez, com os bytes assinados exatos e o ID da transação armazenados antes do broadcast. Se ocorrer um timeout de transporte, o exchange reenvia a mesma transação em vez de, de forma cega, criar uma nova.
Esse detalhe me fez pausar. “Ainda não aconteceu” e “eu não sei se aconteceu” são dois estados completamente diferentes. Se um sistema trata esses estados como iguais, o que parece um retry pode virar outra transação que o sistema então precisa distinguir da primeira. Com a substituição por nonce (same-nonce replacement), a Dusk exige que ambos os IDs de transação sejam rastreados, sem debitar duas vezes.
Isso me levou a uma ideia maior: a infraestrutura financeira não precisa apenas distinguir sucesso de falha. Ela também precisa permanecer segura durante o período em que ainda não sabe em qual estado está.
Então é isso que me deixa curioso sobre a Dusk: conforme mais sistemas financeiros se conectam à rede, qual será o teste mais difícil—lidar com uma transação que falhou claramente, ou lidar com uma quando o remetente ainda não consegue ter certeza se aconteceu ou não?
Ontem eu estava lendo a documentação de integração do exchange da Dusk quando fiquei preso em uma situação que parecia quase trivial: um saque havia sido enviado, mas a requisição teve timeout. Meu primeiro impulso foi enviá-lo novamente. Então eu parei: e se a primeira transação já tivesse chegado à rede?
A Dusk trata exatamente essa “zona cega”. Cada saque é construído e assinado uma única vez, com os bytes assinados exatos e o ID da transação armazenados antes do broadcast. Se ocorrer um timeout de transporte, o exchange reenvia a mesma transação em vez de, de forma cega, criar uma nova.
Esse detalhe me fez pausar. “Ainda não aconteceu” e “eu não sei se aconteceu” são dois estados completamente diferentes. Se um sistema trata esses estados como iguais, o que parece um retry pode virar outra transação que o sistema então precisa distinguir da primeira. Com a substituição por nonce (same-nonce replacement), a Dusk exige que ambos os IDs de transação sejam rastreados, sem debitar duas vezes.
Isso me levou a uma ideia maior: a infraestrutura financeira não precisa apenas distinguir sucesso de falha. Ela também precisa permanecer segura durante o período em que ainda não sabe em qual estado está.
Então é isso que me deixa curioso sobre a Dusk: conforme mais sistemas financeiros se conectam à rede, qual será o teste mais difícil—lidar com uma transação que falhou claramente, ou lidar com uma quando o remetente ainda não consegue ter certeza se aconteceu ou não?