No começo, presumi que a “vivacidade” no consenso de Dusk era apenas uma função de participação e de stake — bastava haver provisioners honestos online, e a cadeia continuaria a avançar por conta própria. Mas, quanto mais eu analisei a seção do modo de emergência, mais o quadro ficou silencioso em relação a isso. Quando falham iterações consecutivas suficientes e nenhum candidato alcança quórum, a rede não fica apenas tentando indefinidamente nos seus próprios termos. Os provisioners podem solicitar um bloco de emergência, e a produção dele depende de uma seed assinada por uma chave que o artigo simplesmente chama de “Dusk”, verificada em relação a uma chave pública listada como um parâmetro global. A própria solicitação precisa de uma maioria do peso alocado (staked) por trás dela, então não é unilateral. Ainda assim, o fallback para o pior caso do sistema acaba sendo direcionado por meio de uma única parte específica, nomeada, em vez da ordenação (sortition) aberta usada em todos os outros casos. Talvez seja uma troca razoável para uma cadeia construída em torno de finanças reguladas. Fico me perguntando se a descentralização é melhor avaliada pelo caso comum, ou pelo que acontece quando o caso comum se rompe.
#dusk #Consensus @Dusk $DUSK