Eu antes achava que confirmar blocos era simples: a transação entra no bloco, depois você conta alguns blocos adiante, e basicamente dá para considerar como seguro. Mas esta noite, ao ler a documentação do ciclo de vida da transação @Dusk , uma frase me travou: “accepted blocks can still be reverted”. Se já foi aceito, por que ainda pode ser revertido?
Eu relacionei isso ao ler o Whitepaper de 2024. O consenso em rodadas do Dusk passa por múltiplas iterações (iterations). Na mesma rodada, podem surgir blocos concorrentes. Mesmo que um bloco de uma iteração mais alta já tenha sido “accepted”, ainda pode ser revertido se um bloco concorrente de iteração mais baixa satisfizer as condições e disparar um fallback.
“Ver no blockchain” não significa que algo seja insubstituível.
A Finalidade em Contínuo (Rolling Finality) é ainda mais contraintuitiva. O whitepaper usa n para representar a quantidade de iterações antes que a determinidade (certeza) do attestation esteja completa. Então, um bloco “accepted” precisa esperar 2×n blocos subsequentes consecutivos atestados ou confirmados para entrar no estado “confirmed”. Suponha n=3: é preciso observar os próximos 6 blocos que atendam às condições.
Foi aqui que percebi: “número de confirmações” não é uma régua única. Mesmo para transações já registradas na cadeia, o histórico do consenso é diferente — e, portanto, o grau de estabilidade também muda.
As recomendações atuais da documentação são ainda mais diretas: não trate “included”, “accepted” e nem mesmo “confirmed” como um sinal de que o pagamento chegou. Espere até que esteja realmente “finalized”.
Uma transferência pequena pode diferir apenas alguns segundos; mas quando isso entra em um fechamento/entrega (DvP) de grandes valores em OTC ou RWA, “ver a transação” e “liquidação irreversível” são completamente coisas diferentes. Daqui em diante, ao analisar transações grandes no Dusk, só pergunte: já foi “finalized”?
#dusk $DUSK @Dusk
Eu relacionei isso ao ler o Whitepaper de 2024. O consenso em rodadas do Dusk passa por múltiplas iterações (iterations). Na mesma rodada, podem surgir blocos concorrentes. Mesmo que um bloco de uma iteração mais alta já tenha sido “accepted”, ainda pode ser revertido se um bloco concorrente de iteração mais baixa satisfizer as condições e disparar um fallback.
“Ver no blockchain” não significa que algo seja insubstituível.
A Finalidade em Contínuo (Rolling Finality) é ainda mais contraintuitiva. O whitepaper usa n para representar a quantidade de iterações antes que a determinidade (certeza) do attestation esteja completa. Então, um bloco “accepted” precisa esperar 2×n blocos subsequentes consecutivos atestados ou confirmados para entrar no estado “confirmed”. Suponha n=3: é preciso observar os próximos 6 blocos que atendam às condições.
Foi aqui que percebi: “número de confirmações” não é uma régua única. Mesmo para transações já registradas na cadeia, o histórico do consenso é diferente — e, portanto, o grau de estabilidade também muda.
As recomendações atuais da documentação são ainda mais diretas: não trate “included”, “accepted” e nem mesmo “confirmed” como um sinal de que o pagamento chegou. Espere até que esteja realmente “finalized”.
Uma transferência pequena pode diferir apenas alguns segundos; mas quando isso entra em um fechamento/entrega (DvP) de grandes valores em OTC ou RWA, “ver a transação” e “liquidação irreversível” são completamente coisas diferentes. Daqui em diante, ao analisar transações grandes no Dusk, só pergunte: já foi “finalized”?
#dusk $DUSK @Dusk
