Um Timeout de Saque Não Deve Criar uma Nova Identidade
Uma solicitação de saque expira. A resposta tentadora é simples: construir a transação novamente e reenviá-la.
No Dusk, isso pode tornar o problema operacional mais difícil.
Para saques do Moonlight, a orientação de integração diz que a transação deve ser construída e assinada uma única vez, com seus bytes serializados e ID da transação armazenados antes da transmissão. Se o envio atingir um timeout de transporte, a nova tentativa segura é reenviar exatamente esses mesmos bytes assinados. A transação mantém a mesma identidade enquanto seu status na cadeia é investigado.
Por que isso importa? Porque um timeout não prova que a primeira tentativa falhou. Mesmo um 202 Accepted apenas confirma o roteamento, não a inclusão nem a finalização. Criar outra transação antes de resolver essa incerteza introduz outro objeto para o sistema de saques acompanhar.
O Moonlight deixa essa distinção explícita. As transações usam nonces de conta sequenciais, e uma transação conflitante com o mesmo nonce substitui a entrada existente do mempool apenas quando seu preço de gás é estritamente maior. Essa substituição tem um ID de transação diferente. O Dusk, portanto, orienta operadores de exchange a reconciliar ambos os IDs e evitar debitar duas vezes.
Assim, “nova tentativa” e “substituição” não são ações intercambiáveis no backend. Uma nova tentativa preserva a identidade da tentativa de pagamento. Uma substituição, deliberadamente, cria uma nova identidade para o mesmo nonce.
Para a infraestrutura de custódia, a idempotência vai além do projeto de banco de dados: a construção da transação, a alocação de nonce, os bytes assinados e os registros contábeis precisam descrever o mesmo saque.
@Dusk $DUSK #dusk
Uma solicitação de saque expira. A resposta tentadora é simples: construir a transação novamente e reenviá-la.
No Dusk, isso pode tornar o problema operacional mais difícil.
Para saques do Moonlight, a orientação de integração diz que a transação deve ser construída e assinada uma única vez, com seus bytes serializados e ID da transação armazenados antes da transmissão. Se o envio atingir um timeout de transporte, a nova tentativa segura é reenviar exatamente esses mesmos bytes assinados. A transação mantém a mesma identidade enquanto seu status na cadeia é investigado.
Por que isso importa? Porque um timeout não prova que a primeira tentativa falhou. Mesmo um 202 Accepted apenas confirma o roteamento, não a inclusão nem a finalização. Criar outra transação antes de resolver essa incerteza introduz outro objeto para o sistema de saques acompanhar.
O Moonlight deixa essa distinção explícita. As transações usam nonces de conta sequenciais, e uma transação conflitante com o mesmo nonce substitui a entrada existente do mempool apenas quando seu preço de gás é estritamente maior. Essa substituição tem um ID de transação diferente. O Dusk, portanto, orienta operadores de exchange a reconciliar ambos os IDs e evitar debitar duas vezes.
Assim, “nova tentativa” e “substituição” não são ações intercambiáveis no backend. Uma nova tentativa preserva a identidade da tentativa de pagamento. Uma substituição, deliberadamente, cria uma nova identidade para o mesmo nonce.
Para a infraestrutura de custódia, a idempotência vai além do projeto de banco de dados: a construção da transação, a alocação de nonce, os bytes assinados e os registros contábeis precisam descrever o mesmo saque.
@Dusk $DUSK #dusk
