@Dusk_Foundation

Eu continuava voltando à palavra “confirmado” ao seguir o caminho de finalização final da Dusk.

A parte surpreendente não são os quatro estados.

O que surpreende é que o caminho para a confirmação muda dependendo do que aconteceu anteriormente na rodada.

No modelo de finalização por iterações em andamento, a primeira iteração começa com n = 0 iterações anteriores não atestadas, então ela segue o caminho rápido.

Agora deixe duas iterações falharem em produzir a atestação exigida.

n = 2.

A regra passa a ser 2×n, o que significa que são necessários quatro blocos consecutivos com as atestações ou confirmações exigidas antes que o bloco que está sendo avaliado se torne confirmado.

O que me pegou é que isso acontece quando a rodada já está se comportando mal. A confirmação, na verdade, pode exigir mais evidências antes de avançar.

O histórico da rodada muda a quantidade de evidências de que o próximo bloco precisa.

Então a confirmação não é só sobre o bloco. É em parte sobre o que a rodada fez antes.

O que eu ainda não consigo ver no artigo é com que frequência essa profundidade extra aparece sob condições reais de rede.

$DUSK fica ainda mais interessante para mim se essa finalização adaptativa continuar previsível quando a rede ficar caótica.

#dusk