O verão finalmente está quase acabando e a temperatura vai baixando aos poucos. Na semana passada, peguei o carro para passear com a família. Quando estávamos na estrada, na via expressa, ocorreu um acidente inesperado à frente, e o GPS temporariamente me indicou uma rota alternativa. Mas os carros atrás não mudaram; eles continuaram pela rota original. As duas rotas ficaram paralelas por quase dez minutos. Depois que o acidente foi resolvido, o sistema só então redirecionou todo mundo de volta para a via principal — durante esse período, ninguém sabia qual era a "rota final" a seguir.
Na lógica de consenso do Dusk existe um cenário semelhante de "bifurcação", chamado fallback (retorno). Como a rede é assíncrona, mensagens podem atrasar ou se perder; em uma mesma rodada, às vezes mais de um bloco candidato pode atingir consenso ao mesmo tempo. Isso é a bifurcação. As regras de tratamento são diretas: é aceito o bloco que alcançou consenso na iteração (iteration) mais baixa. Blocos de iterações mais altas serão substituídos por outros de iteração mais baixa; a cadeia faz um rollback para o bloco que existia antes da bifurcação e então segue pela linha de blocos cujo consenso foi atingido primeiro. A cadeia que foi substituída deixa de valer, junto com todos os blocos que vieram depois dela.
Há um detalhe fácil de ignorar: o bloco que atinge consenso na iteration 0 é o único que não será "substituído", porque não existe uma rodada menor que ele. Mas mesmo ele, se o seu próprio "bloco pai" mais tarde for revertido pelo rollback, ele também terá de voltar — não é segurança absoluta, é apenas relativamente mais estável.
Esse mecanismo resolve "como lidar com bifurcações temporárias causadas por atraso de mensagens na rede", mas o custo é que, temporariamente, pode haver incerteza na cadeia: os blocos recém-criados, especialmente os de iteração mais alta, teoricamente podem ser substituídos. É preciso esperar que blocos futuros o "soldem" de vez à cadeia para então ficar realmente tranquilo.
$DUSK
#dusk @Dusk