@Dusk_Foundation
16 iterações falhas consecutivas é o suficiente para fazer o Dusk parar de se comportar normalmente.
Eu li esse número algumas vezes antes dele se confirmar.
Em condições normais, as etapas de consenso são executadas com um limite de tempo. Se uma etapa não produzir um resultado a tempo, ela não retorna nada e a rodada tenta novamente.
Tente. Timeout. Tente novamente.
Eu assumi que esse caminho de falha permanecia no lugar não importa o quão ruim as coisas ficassem.
Não fica.
Após 16 falhas consecutivas, o Dusk desabilita esses timeouts. As etapas não podem mais retornar NoCandidate ou NoQuorum. As iterações continuam rodando até que um candidato de fato alcance o quorum para validação e ratificação.
Isso cria um segundo modo de falha que eu não tinha separado antes.
A falha normal é limitada pelo relógio. O modo de emergência remove essa fronteira.
E isso introduz outro problema: múltiplas iterações sem fim podem rodar ao mesmo tempo, criando a possibilidade de candidatos concorrentes alcançarem quorum na mesma rodada.
O Dusk já tem uma regra para esse caso: o candidato que alcança quorum na menor iteração vence.
O que eu ainda não sei é como são exatamente essas 16 falhas consecutivas em uma rede real.
Que tipo de condição de rede sustentada te leva até aí, e com que frequência a regra de resolução de fork seria realmente aplicada em vez de permanecer como um caminho teórico?
$DUSK becomes more interesting to me if this emergency path proves reliable when the network actually needs it.
#dusk
16 iterações falhas consecutivas é o suficiente para fazer o Dusk parar de se comportar normalmente.
Eu li esse número algumas vezes antes dele se confirmar.
Em condições normais, as etapas de consenso são executadas com um limite de tempo. Se uma etapa não produzir um resultado a tempo, ela não retorna nada e a rodada tenta novamente.
Tente. Timeout. Tente novamente.
Eu assumi que esse caminho de falha permanecia no lugar não importa o quão ruim as coisas ficassem.
Não fica.
Após 16 falhas consecutivas, o Dusk desabilita esses timeouts. As etapas não podem mais retornar NoCandidate ou NoQuorum. As iterações continuam rodando até que um candidato de fato alcance o quorum para validação e ratificação.
Isso cria um segundo modo de falha que eu não tinha separado antes.
A falha normal é limitada pelo relógio. O modo de emergência remove essa fronteira.
E isso introduz outro problema: múltiplas iterações sem fim podem rodar ao mesmo tempo, criando a possibilidade de candidatos concorrentes alcançarem quorum na mesma rodada.
O Dusk já tem uma regra para esse caso: o candidato que alcança quorum na menor iteração vence.
O que eu ainda não sei é como são exatamente essas 16 falhas consecutivas em uma rede real.
Que tipo de condição de rede sustentada te leva até aí, e com que frequência a regra de resolução de fork seria realmente aplicada em vez de permanecer como um caminho teórico?
$DUSK becomes more interesting to me if this emergency path proves reliable when the network actually needs it.
#dusk