#dusk $DUSK @Dusk
Eu costumava achar que o Modo de Emergência da Dusk era apenas um plano de backup quando a rede não conseguia produzir um bloco.
Mas depois de analisar mais a fundo, acho que existe uma ideia mais interessante aqui: como manter uma blockchain em movimento quando o consenso normal começa a falhar?
A Dusk normalmente avança por iterações em que blocos são propostos, validados e ratificados. Mas se muitos provisionadores ficarem offline, várias iterações podem falhar uma após a outra.
Após 16 iterações consecutivas falhas, a Dusk pode entrar em Modo de Emergência.
O que muda aqui é bem interessante. Os timeouts normais do passo deixam de ser a principal restrição, e múltiplas iterações abertas podem continuar tentando até que uma obtenha quórum.
Claro, isso cria outro problema. Múltiplos candidatos também significam uma chance maior de blocos concorrentes.
A Dusk lida com isso aceitando o bloco bem-sucedido da iteração de menor número e encerrando as iterações abertas restantes.
Mas o que acontece se nem mesmo a última iteração conseguir atingir o quórum?
É aí que entram as Solicitações de Bloco de Emergência.
Se uma maioria ponderada por participação dos provisionadores solicitar uma, a Dusk pode criar um bloco especial vazio, assinado pela própria Dusk, permitindo que a cadeia avance em vez de ficar travada indefinidamente.
A parte que acho mais interessante é o equilíbrio.
A Dusk está adicionando um fallback centralizado e controlado para proteger a continuidade da rede durante um cenário extremo de falha.
Então talvez a verdadeira pergunta não seja se o Modo de Emergência é descentralizado o suficiente.
É se manter a rede viva durante uma situação de pior caso vale essa pequena concessão.
Esse equilíbrio entre descentralização e liveness é o que torna o design de consenso da Dusk interessante para mim.
Eu costumava achar que o Modo de Emergência da Dusk era apenas um plano de backup quando a rede não conseguia produzir um bloco.
Mas depois de analisar mais a fundo, acho que existe uma ideia mais interessante aqui: como manter uma blockchain em movimento quando o consenso normal começa a falhar?
A Dusk normalmente avança por iterações em que blocos são propostos, validados e ratificados. Mas se muitos provisionadores ficarem offline, várias iterações podem falhar uma após a outra.
Após 16 iterações consecutivas falhas, a Dusk pode entrar em Modo de Emergência.
O que muda aqui é bem interessante. Os timeouts normais do passo deixam de ser a principal restrição, e múltiplas iterações abertas podem continuar tentando até que uma obtenha quórum.
Claro, isso cria outro problema. Múltiplos candidatos também significam uma chance maior de blocos concorrentes.
A Dusk lida com isso aceitando o bloco bem-sucedido da iteração de menor número e encerrando as iterações abertas restantes.
Mas o que acontece se nem mesmo a última iteração conseguir atingir o quórum?
É aí que entram as Solicitações de Bloco de Emergência.
Se uma maioria ponderada por participação dos provisionadores solicitar uma, a Dusk pode criar um bloco especial vazio, assinado pela própria Dusk, permitindo que a cadeia avance em vez de ficar travada indefinidamente.
A parte que acho mais interessante é o equilíbrio.
A Dusk está adicionando um fallback centralizado e controlado para proteger a continuidade da rede durante um cenário extremo de falha.
Então talvez a verdadeira pergunta não seja se o Modo de Emergência é descentralizado o suficiente.
É se manter a rede viva durante uma situação de pior caso vale essa pequena concessão.
Esse equilíbrio entre descentralização e liveness é o que torna o design de consenso da Dusk interessante para mim.