Eu estava voltando a olhar para o @Dusk e acabei aprofundando em como a confirmação de bloco realmente funciona. O que parecia ser um simples status “confirmed” acaba sendo um processo bem mais em camadas.
O Dusk usa um modelo de Rolling Finality com várias etapas: accepted, attested, confirmed e, por fim, finalized. Cada etapa fornece um nível diferente de confiança, em vez de tratar a finalização como uma resposta simples de sim ou não.
O que realmente chamou minha atenção é que o tempo de confirmação pode depender de quantas iterações falhas aconteceram antes de um bloco ser aceito. À medida que esse número aumenta, o bloco precisa de mais blocos posteriores para alcançar uma finalidade mais forte.
Eu gosto da lógica de segurança por trás disso, mas também existe uma questão de usabilidade: a maioria das carteiras esconde toda essa complexidade e simplesmente mostra “confirmed”.
Então estou curioso—você realmente olha o status de finalidade subjacente, ou a mensagem de confirmação da carteira é suficiente para você?
#dusk $DUSK @Dusk
O Dusk usa um modelo de Rolling Finality com várias etapas: accepted, attested, confirmed e, por fim, finalized. Cada etapa fornece um nível diferente de confiança, em vez de tratar a finalização como uma resposta simples de sim ou não.
O que realmente chamou minha atenção é que o tempo de confirmação pode depender de quantas iterações falhas aconteceram antes de um bloco ser aceito. À medida que esse número aumenta, o bloco precisa de mais blocos posteriores para alcançar uma finalidade mais forte.
Eu gosto da lógica de segurança por trás disso, mas também existe uma questão de usabilidade: a maioria das carteiras esconde toda essa complexidade e simplesmente mostra “confirmed”.
Então estou curioso—você realmente olha o status de finalidade subjacente, ou a mensagem de confirmação da carteira é suficiente para você?
#dusk $DUSK @Dusk
