#dusk $DUSK @Dusk
Ei, você sabe… tem uma pergunta sobre @DuskFoundation que ficou comigo: se uma exchange recebe “202 Accepted” para o meu saque, por que o job não termina?
Estamos acostumados a ler uma resposta como “concluída”. Mas, em uma blockchain, submissão e liquidação são momentos diferentes.
No Dusk L1, “202 Accepted” só significa que um nó aceitou a transação para roteamento. Isso não prova que a transação entrou no mempool, chegou a peers, executou com sucesso ou se tornou final.
O Dusk separa essas etapas. “transactions/included” indica admissão no mempool local. “transactions/executed” significa que a transação foi executada dentro de um bloco aceito, onde o campo “err” precisa ser nulo. A finalização chega quando um evento “blocks/statechange” é marcado como “finalized”. Antes disso, um bloco aceito ainda pode ser revertido.
Hipoteticamente, suponha que eu saque DUSK de uma exchange. O sistema dela assina a transação Moonlight, armazena seus bytes e ID e então a transmite. A resposta 202 confirma o roteamento — não a conclusão. A exchange precisa verificar a execução e o status do bloco finalizado.
Mas eu parei aqui por um momento.
Talvez a finalidade não seja apenas um recurso de consenso. É uma responsabilidade operacional.
Então quando um saque fica, de fato, completo: quando a API responde, ou quando a reversão já não é mais possível? Ainda estou pensando nisso. 🤔
Ei, você sabe… tem uma pergunta sobre @DuskFoundation que ficou comigo: se uma exchange recebe “202 Accepted” para o meu saque, por que o job não termina?
Estamos acostumados a ler uma resposta como “concluída”. Mas, em uma blockchain, submissão e liquidação são momentos diferentes.
No Dusk L1, “202 Accepted” só significa que um nó aceitou a transação para roteamento. Isso não prova que a transação entrou no mempool, chegou a peers, executou com sucesso ou se tornou final.
O Dusk separa essas etapas. “transactions/included” indica admissão no mempool local. “transactions/executed” significa que a transação foi executada dentro de um bloco aceito, onde o campo “err” precisa ser nulo. A finalização chega quando um evento “blocks/statechange” é marcado como “finalized”. Antes disso, um bloco aceito ainda pode ser revertido.
Hipoteticamente, suponha que eu saque DUSK de uma exchange. O sistema dela assina a transação Moonlight, armazena seus bytes e ID e então a transmite. A resposta 202 confirma o roteamento — não a conclusão. A exchange precisa verificar a execução e o status do bloco finalizado.
Mas eu parei aqui por um momento.
Talvez a finalidade não seja apenas um recurso de consenso. É uma responsabilidade operacional.
Então quando um saque fica, de fato, completo: quando a API responde, ou quando a reversão já não é mais possível? Ainda estou pensando nisso. 🤔