Tenho mantido uma posição pequena em $DUSK há algumas semanas, principalmente observando. Nada dramático: aumentei um pouco mais ontem depois que notei algo nos documentos do protocolo que eu ainda não tinha visto ninguém comentar.

É sobre o que acontece quando o consenso simplesmente... para de funcionar. Não por causa de um ataque. Nem de um bug. Apenas porque os validadores ficam em silêncio.

A Dusk tem algo chamado Modo de Emergência, e a minha primeira leitura foi que ele existia para produzir blocos de emergência. Não é bem isso.

O ponto real é preservar a vivacidade quando a participação de stake se torna pouco confiável.

O que me chamou a atenção: a Dusk não congela se os validadores continuarem faltando. Em vez disso, ela deixa iterações anteriores de consenso permanecerem abertas enquanto novas começam simultaneamente. Os provisioners restantes recebem mais tentativas para encontrar acordo, em vez de baterem numa barreira rígida.

A regra de prioridade também importa. Se várias iterações tiverem sucesso ao mesmo tempo, o protocolo sempre favorece a iteração de menor número. É assim que ele resolve o problema do bloco concorrente sem precisar de intervenção manual.

E se nem isso funcionar, entra a Solicitação de Bloco de Emergência (EBR).

Quando as EBRs que representam a maior parte do stake se acumulam, a cadeia produz um bloco vazio! sem transações, apenas continuidade e uma semente fresca para o próximo turno.

Essa escolha de design me diz que @Dusk não está sendo construída para condições ideais.

Está sendo construída para o momento em que essas condições falham.

O que eu realmente ainda não sei é como esse caminho de recuperação se sustenta se a participação continuar degradada ao longo de múltiplas rodadas consecutivas. Esse é o teste de estresse que eu gostaria de ver documentado.

#Dusk #EmergencyMode #DuskEVM
O que mais importa no design do Modo de Emergência da Dusk?