Dois vendedores no mercado Saddar de Karachi, uma vez ambos alegaram que venderam para mim a mesma capinha de celular primeiro, e o lojista simplesmente foi com quem pegou primeiro o livro de recibos. Eu entendi que a Dusk lida com blocos concorrentes do mesmo jeito grosseiro: vence aquele que a rede vê primeiro.
Isso está ao contrário de como o fallback realmente funciona. Quando dois blocos candidatos chegam ao consenso na mesma rodada, o que pode acontecer por mensagens atrasadas ou perdidas durante a congestão da rede, a Dusk não favorece aquele que chegou primeiro. Ela favorece aquele que alcançou o consenso no menor número de iteração. Um bloco na iteração 5 pode ser substituído por outro na iteração 2 se o bloco de iteração menor também atingir o quórum. O procedimento de fallback reverte a cadeia local para imediatamente antes do bloco de iteração maior, aceita o bloco de iteração menor e descarta todos os sucessores que foram construídos em cima do bloco descartado.
O que realmente mudou meu raciocínio foi a exceção da iteração 0. Um bloco que chega ao consenso na iteração 0 nunca pode ser substituído por um bloco de iteração menor, já que não existe uma iteração menor. Ele ainda pode ser revertido mais tarde, mas apenas se algo a montante dele, um de seus ancestrais, for revertido primeiro. Então, a finalização na Dusk não é realmente sobre o status de um único bloco; é herdada de tudo o que está por baixo dele.
O whitepaper não quantifica com que frequência esse tipo de fork realmente acontece quando a rede está sob congestão real em escala, e não apenas em teoria.
Alguém já viu um evento real de fallback acontecer em um bloco da Dusk?
#dusk $DUSK @Dusk
Isso está ao contrário de como o fallback realmente funciona. Quando dois blocos candidatos chegam ao consenso na mesma rodada, o que pode acontecer por mensagens atrasadas ou perdidas durante a congestão da rede, a Dusk não favorece aquele que chegou primeiro. Ela favorece aquele que alcançou o consenso no menor número de iteração. Um bloco na iteração 5 pode ser substituído por outro na iteração 2 se o bloco de iteração menor também atingir o quórum. O procedimento de fallback reverte a cadeia local para imediatamente antes do bloco de iteração maior, aceita o bloco de iteração menor e descarta todos os sucessores que foram construídos em cima do bloco descartado.
O que realmente mudou meu raciocínio foi a exceção da iteração 0. Um bloco que chega ao consenso na iteração 0 nunca pode ser substituído por um bloco de iteração menor, já que não existe uma iteração menor. Ele ainda pode ser revertido mais tarde, mas apenas se algo a montante dele, um de seus ancestrais, for revertido primeiro. Então, a finalização na Dusk não é realmente sobre o status de um único bloco; é herdada de tudo o que está por baixo dele.
O whitepaper não quantifica com que frequência esse tipo de fork realmente acontece quando a rede está sob congestão real em escala, e não apenas em teoria.
Alguém já viu um evento real de fallback acontecer em um bloco da Dusk?
#dusk $DUSK @Dusk
