Acho que geralmente estamos fazendo a pergunta errada quando uma transação Dusk “falha”.
Uma resposta 202 Accepted só significa que o nó aceitou a solicitação para roteamento. Isso não quer dizer que a transação já esteja no mempool ou em um bloco. Um exemplo que achei interessante é um nonce futuro. Se uma transação Moonlight chegar com um nonce futuro enquanto um nonce anterior ainda está faltando, o Dusk pode mantê-la fora do mempool real e esperar o intervalo de nonce ser fechado em vez de rejeitá-la imediatamente. Nesse período, ela fica em um estado adiado.
Isso é apenas uma parte da história. Depois que uma transação passa pela admissão, ela entra no mempool local daquele nó. Outros nós mantêm seus próprios mempools e executam suas próprias verificações de admissão também. Mais tarde, uma transação pode ser selecionada para um bloco, executada e, eventualmente, finalizada. Ela também pode sair do mempool local sem que isso automaticamente signifique que falhou. Expiração, substituição, limites de capacidade e conflitos podem levar à remoção.
É aqui que acho que a diferença importa para carteiras e exchanges. A orientação de integração do próprio Dusk diz para manter a transação assinada exata, tratar 202 Accepted apenas como roteamento bem-sucedido e reenviar os mesmos bytes assinados após um timeout de transporte, em vez de criar uma nova transação de forma cega. Uma retirada deve ser marcada como concluída somente depois que a execução for verificada e o bloco for finalizado.
Quanto mais eu olhava para isso, menos “transação enviada” parecia um status útil por si só. Uma transação pode estar esperando um nonce, parada no mempool de um nó, executada com erro, ou parada em um bloco que ainda não é final. Essas são situações bem diferentes, mesmo que todas possam parecer “ainda está pendente” do lado de fora.
Para mim, esse é o aprendizado útil do fluxo de transações do Dusk: enviada é só o começo. O que importa é o estado que você realmente consegue comprovar que a transação chegou.
$DUSK @Dusk #dusk
Uma resposta 202 Accepted só significa que o nó aceitou a solicitação para roteamento. Isso não quer dizer que a transação já esteja no mempool ou em um bloco. Um exemplo que achei interessante é um nonce futuro. Se uma transação Moonlight chegar com um nonce futuro enquanto um nonce anterior ainda está faltando, o Dusk pode mantê-la fora do mempool real e esperar o intervalo de nonce ser fechado em vez de rejeitá-la imediatamente. Nesse período, ela fica em um estado adiado.
Isso é apenas uma parte da história. Depois que uma transação passa pela admissão, ela entra no mempool local daquele nó. Outros nós mantêm seus próprios mempools e executam suas próprias verificações de admissão também. Mais tarde, uma transação pode ser selecionada para um bloco, executada e, eventualmente, finalizada. Ela também pode sair do mempool local sem que isso automaticamente signifique que falhou. Expiração, substituição, limites de capacidade e conflitos podem levar à remoção.
É aqui que acho que a diferença importa para carteiras e exchanges. A orientação de integração do próprio Dusk diz para manter a transação assinada exata, tratar 202 Accepted apenas como roteamento bem-sucedido e reenviar os mesmos bytes assinados após um timeout de transporte, em vez de criar uma nova transação de forma cega. Uma retirada deve ser marcada como concluída somente depois que a execução for verificada e o bloco for finalizado.
Quanto mais eu olhava para isso, menos “transação enviada” parecia um status útil por si só. Uma transação pode estar esperando um nonce, parada no mempool de um nó, executada com erro, ou parada em um bloco que ainda não é final. Essas são situações bem diferentes, mesmo que todas possam parecer “ainda está pendente” do lado de fora.
Para mim, esse é o aprendizado útil do fluxo de transações do Dusk: enviada é só o começo. O que importa é o estado que você realmente consegue comprovar que a transação chegou.
$DUSK @Dusk #dusk
