Percebi o problema quando um provisioner parecia saudável, mas ainda assim parecia um pouco atrasado em relação ao turno. Rusk estava em execução, o estado parecia atualizado, a conexão de rede estava lá, mas algo na passagem de responsabilidade parecia fora do lugar. Minha primeira reação foi culpar o Kadcast. Talvez uma mensagem estivesse chegando devagar. Então comecei a pensar se isso era simples demais. Um nó pode receber a mensagem certa e, ainda assim, ficar mal posicionado para agir sobre ela se o estado, o timing ou a responsabilidade do consenso já tiverem avançado. É aí que a pilha de $DUSK fica mais interessante para mim. A evolução da SBA para a Succinct Attestation pode atribuir o trabalho de proposta, validação e ratificação, mas essas funções só importam se o sistema ao redor estiver pronto quando a seleção transformar elegibilidade em responsabilidade. O Kadcast cuida da coordenação. O Rusk precisa manter o suficiente da realidade local alinhada para que essa coordenação signifique algo. Parece bem organizado quando se escreve. Menos organizado quando um nó se reconecta no meio de uma atividade, perde um dever, ou se põe em dia bem quando outro turno começa. Não tenho certeza se a parte difícil é alcançar a finalização quando tudo se comporta. Eu preferiria observar o que acontece depois de algumas desconexões curtas, mensagens atrasadas e mudanças de software, e então ver o quão rápido esses provisioners voltam a ser realmente úteis.

@Dusk_Foundation #dusk