#dusk Eu releio a documentação mais recente sobre o ciclo de vida das transações, @Dusk , e um detalhe que é fácil de ser escondido pela interface é este: quando um nó retorna “202 Accepted”, isso só quer dizer que ele recebeu a transação e está pronto para roteá-la; não significa que a transação já esteja em um pool de memória real, nem que tenha sido executada com sucesso ou que tenha sido finalmente confirmada. Muitos aplicativos de carteira transformam a “submissão bem-sucedida” em um aviso verde; usuários comuns, ao verem isso, naturalmente pensam que o dinheiro já chegou. Mas o estado real pode ainda estar a várias camadas de distância. $DUSK
No Dusk L1, uma transação anterior precisa passar por construção da assinatura, submissão, pré-validação no nó, entrada no pool de memória local, propagação para outros nós, seleção pelo produtor do bloco, execução e, por fim, aguardar o bloco atingir o estado de finalized. Mesmo que a transação já tenha sido executada dentro de um bloco aceito, é necessário verificar se o campo de erro está vazio; blocos aceitos ainda podem reverter. O Moonlight também envolve nonce em ordem: para substituir uma transação com o mesmo nonce, é preciso aumentar o preço de Gas, e o novo ID de transação também precisa ser reconciliado.
Esse fluxo, por si só, não é nada incomum; o verdadeiro “poço” é a aplicação comprimir estados diferentes em um único “sucesso”. Após um timeout na rede, se você gerar e assinar uma nova transação em vez de reenviar (replay) a mesma sequência de bytes já assinada, pode causar intenções duplicadas; se você ficar apenas observando o pool de memória local, também pode perder transações futuras de nonce que estejam temporariamente na fila de pré-ordem. A recomendação oficial para integrações com exchanges até exige de forma explícita: não creditar com base apenas em variações de saldo, registros do pool de memória ou em blocos não finalizados ainda sem confirmação final.
Por isso, ao avaliar a experiência on-chain, eu não considero apenas se a difusão é rápida. O mais importante é se a carteira consegue separar e exibir “enviada”, “executada” e “finalmente confirmada”; em caso de falha, se ela mantém o ID original da transação; e se o servidor consegue usar regras de idempotência para evitar contabilização duplicada. A velocidade pode virar animação, mas a finalização e a reconciliação é a parte que realmente não dá para economizar.
No Dusk L1, uma transação anterior precisa passar por construção da assinatura, submissão, pré-validação no nó, entrada no pool de memória local, propagação para outros nós, seleção pelo produtor do bloco, execução e, por fim, aguardar o bloco atingir o estado de finalized. Mesmo que a transação já tenha sido executada dentro de um bloco aceito, é necessário verificar se o campo de erro está vazio; blocos aceitos ainda podem reverter. O Moonlight também envolve nonce em ordem: para substituir uma transação com o mesmo nonce, é preciso aumentar o preço de Gas, e o novo ID de transação também precisa ser reconciliado.
Esse fluxo, por si só, não é nada incomum; o verdadeiro “poço” é a aplicação comprimir estados diferentes em um único “sucesso”. Após um timeout na rede, se você gerar e assinar uma nova transação em vez de reenviar (replay) a mesma sequência de bytes já assinada, pode causar intenções duplicadas; se você ficar apenas observando o pool de memória local, também pode perder transações futuras de nonce que estejam temporariamente na fila de pré-ordem. A recomendação oficial para integrações com exchanges até exige de forma explícita: não creditar com base apenas em variações de saldo, registros do pool de memória ou em blocos não finalizados ainda sem confirmação final.
Por isso, ao avaliar a experiência on-chain, eu não considero apenas se a difusão é rápida. O mais importante é se a carteira consegue separar e exibir “enviada”, “executada” e “finalmente confirmada”; em caso de falha, se ela mantém o ID original da transação; e se o servidor consegue usar regras de idempotência para evitar contabilização duplicada. A velocidade pode virar animação, mas a finalização e a reconciliação é a parte que realmente não dá para economizar.
