UMA TRANSAÇÃO DE FIM DE DIA PODE SER “ACEITA” ANTES DE A TROCA DEVER CONSIDERÁ-LA COMO CONCLUÍDA.
Eu estava lendo a API de transação do @Dusk e um código de status acabou me incomodando mais do que a discussão habitual sobre finalização:
202 Accepted.
Quando um nó Dusk retorna 202 depois que uma transação é propagada, isso significa que a transação foi aceita para roteamento.
Ainda não prova que ela entrou de fato no mempool, chegou aos pares, executou com sucesso ou se tornou final.
Isso soa como um detalhe pequeno de API.
Mas, para um processamento de saques por uma exchange, eu não acho que seja.
Eu vinha tratando mentalmente o processamento de saque como algo próximo de:
enviar transação → a rede aceita → aguardar finalização → fechar o saque.
Mas existe um estado estranho no meio em que a exchange enviou algo e ainda não tem informações suficientes para, com segurança, chamar a ação econômica como concluída.
Isso muda o problema.
Enviar uma transação não é o mesmo que concluir uma transação.
E repetir uma requisição de API que falhou não é necessariamente a mesma coisa que decidir que o saque original nunca existiu.
A documentação do Dusk ainda avisa que um serviço de assinatura precisa serializar a alocação de nonce, reter transações enviadas e verificar o estado da conta pendente e comprometida antes de reutilizar um nonce.
É essa a parte que eu acho interessante.
A finalidade determinística pode deixar o fim de uma transação muito claro.
Ela não pode automaticamente tornar qualquer estado antes da finalidade igualmente fácil para uma exchange lidar.
Então, se eu estivesse avaliando uma integração séria do Dusk, eu não mediria apenas a velocidade de liquidação.
Eu gostaria de saber o que acontece durante falhas de nós, timeouts e envios ambíguos:
Quantos saques conseguem se recuperar automaticamente sem criar instruções duplicadas ou sem exigir que alguém decida manualmente o que aconteceu?
A melhor infraestrutura de transações pode ser aquela em que o caminho de falha fica “chato”.
Parece muito mais difícil do que fazer o caminho feliz ser rápido.
#dusk $DUSK @Dusk
$GPS $TUT
Eu estava lendo a API de transação do @Dusk e um código de status acabou me incomodando mais do que a discussão habitual sobre finalização:
202 Accepted.
Quando um nó Dusk retorna 202 depois que uma transação é propagada, isso significa que a transação foi aceita para roteamento.
Ainda não prova que ela entrou de fato no mempool, chegou aos pares, executou com sucesso ou se tornou final.
Isso soa como um detalhe pequeno de API.
Mas, para um processamento de saques por uma exchange, eu não acho que seja.
Eu vinha tratando mentalmente o processamento de saque como algo próximo de:
enviar transação → a rede aceita → aguardar finalização → fechar o saque.
Mas existe um estado estranho no meio em que a exchange enviou algo e ainda não tem informações suficientes para, com segurança, chamar a ação econômica como concluída.
Isso muda o problema.
Enviar uma transação não é o mesmo que concluir uma transação.
E repetir uma requisição de API que falhou não é necessariamente a mesma coisa que decidir que o saque original nunca existiu.
A documentação do Dusk ainda avisa que um serviço de assinatura precisa serializar a alocação de nonce, reter transações enviadas e verificar o estado da conta pendente e comprometida antes de reutilizar um nonce.
É essa a parte que eu acho interessante.
A finalidade determinística pode deixar o fim de uma transação muito claro.
Ela não pode automaticamente tornar qualquer estado antes da finalidade igualmente fácil para uma exchange lidar.
Então, se eu estivesse avaliando uma integração séria do Dusk, eu não mediria apenas a velocidade de liquidação.
Eu gostaria de saber o que acontece durante falhas de nós, timeouts e envios ambíguos:
Quantos saques conseguem se recuperar automaticamente sem criar instruções duplicadas ou sem exigir que alguém decida manualmente o que aconteceu?
A melhor infraestrutura de transações pode ser aquela em que o caminho de falha fica “chato”.
Parece muito mais difícil do que fazer o caminho feliz ser rápido.
#dusk $DUSK @Dusk
$GPS $TUT