Eu estava acompanhando uma liberação aduaneira no porto de Karachi que ficou em "em análise" por três dias antes de mudar diretamente para "liberada", sem nenhuma etapa intermediária exibida no portal. Eu esperava que a finalização em Dusk funcionasse da mesma forma: pendente e depois final, um salto. Não é assim que a finalização progressiva (rolling finality) funciona.
Existem quatro estados distintos pelos quais um bloco passa, e o salto entre eles depende totalmente do que aconteceu nas iterações anteriores. Um bloco começa como atestado se nenhuma das iterações anteriores naquela rodada falhou, ou seja, nenhum outro candidato poderia ter superado-o até o consenso. Se alguma iteração anterior falhou sem uma atestação de falha (fail attestation), ele começa como aceito (accepted) em vez disso, o que significa que um bloco de uma iteração inferior ainda poderia, teoricamente, substituí-lo.
A parte que realmente remodelou meu modo de pensar é que confirmado e final não são, na prática, sobre o bloco em si. Um bloco atestado se torna confirmado quando um único sucessor é atestado ou confirmado. Mas um bloco aceito precisa de 2 vezes n blocos consecutivos atestados ou confirmados empilhados sobre ele, onde n é a contagem de iterações anteriores que não foram atestadas (non attested). Assim, dois blocos com idade semelhante podem levar quantidades completamente diferentes de tempo para atingir o mesmo nível de confiança, dependendo apenas de quão "limpo" foi o histórico de iteração.
O whitepaper não me dá o que eu preciso: um prazo médio real, em segundos ou em blocos, para algo ir de aceito até final na infraestrutura real do Dusk. Eu não consigo gerar esse número.
O teste real para o DUSK é se esse caminho variável até a finalização ainda parece rápido o suficiente para usuários do dia a dia que movimentam fundos.
Alguém acompanhou quanto tempo uma transação real levou para chegar ao status final no Dusk?
#dusk $DUSK @Dusk
Existem quatro estados distintos pelos quais um bloco passa, e o salto entre eles depende totalmente do que aconteceu nas iterações anteriores. Um bloco começa como atestado se nenhuma das iterações anteriores naquela rodada falhou, ou seja, nenhum outro candidato poderia ter superado-o até o consenso. Se alguma iteração anterior falhou sem uma atestação de falha (fail attestation), ele começa como aceito (accepted) em vez disso, o que significa que um bloco de uma iteração inferior ainda poderia, teoricamente, substituí-lo.
A parte que realmente remodelou meu modo de pensar é que confirmado e final não são, na prática, sobre o bloco em si. Um bloco atestado se torna confirmado quando um único sucessor é atestado ou confirmado. Mas um bloco aceito precisa de 2 vezes n blocos consecutivos atestados ou confirmados empilhados sobre ele, onde n é a contagem de iterações anteriores que não foram atestadas (non attested). Assim, dois blocos com idade semelhante podem levar quantidades completamente diferentes de tempo para atingir o mesmo nível de confiança, dependendo apenas de quão "limpo" foi o histórico de iteração.
O whitepaper não me dá o que eu preciso: um prazo médio real, em segundos ou em blocos, para algo ir de aceito até final na infraestrutura real do Dusk. Eu não consigo gerar esse número.
O teste real para o DUSK é se esse caminho variável até a finalização ainda parece rápido o suficiente para usuários do dia a dia que movimentam fundos.
Alguém acompanhou quanto tempo uma transação real levou para chegar ao status final no Dusk?
#dusk $DUSK @Dusk
