#dusk $DUSK @Dusk
Lendo os documentos de “Dusk” sobre cortes (“slashing”), uma linha me travou: alertas e falhas só são redefinidos quando um provisionador recebe uma recompensa — ou seja, ele realmente produziu ou votou em um bloco. Sem timer. Sem decaimento automático. Apenas a participação limpa o registro.
Soft slashing no $DUSK SK não queima o stake. Uma falha move uma parte dele para o pool de recompensas e reduz o tamanho efetivo do nó, o que diminui as chances de ele ser escolhido para o próximo comitê. Então, um provisionador punido precisa ser selecionado novamente para zerar suas falhas — mas é justamente essa penalidade que torna a seleção menos provável em primeiro lugar.
Essa foi a parte que eu não tinha percebido. Não é apenas “nós ruins são punidos”. É um sistema em que a recuperação passa pela mesma porta que ficou mais difícil de atravessar. #dusk vende isso como proteção à confiabilidade, e mecanicamente é — os atrasados são colocados em segundo plano, e o uptime é recompensado. Mas o caminho de volta depende inteiramente de ser escolhido de novo, não de esperar.
Vale checar: quantos epochs normalmente leva um provisionador suspenso no @Dusk para voltar a um comitê ativo após uma única falha.
Lendo os documentos de “Dusk” sobre cortes (“slashing”), uma linha me travou: alertas e falhas só são redefinidos quando um provisionador recebe uma recompensa — ou seja, ele realmente produziu ou votou em um bloco. Sem timer. Sem decaimento automático. Apenas a participação limpa o registro.
Soft slashing no $DUSK SK não queima o stake. Uma falha move uma parte dele para o pool de recompensas e reduz o tamanho efetivo do nó, o que diminui as chances de ele ser escolhido para o próximo comitê. Então, um provisionador punido precisa ser selecionado novamente para zerar suas falhas — mas é justamente essa penalidade que torna a seleção menos provável em primeiro lugar.
Essa foi a parte que eu não tinha percebido. Não é apenas “nós ruins são punidos”. É um sistema em que a recuperação passa pela mesma porta que ficou mais difícil de atravessar. #dusk vende isso como proteção à confiabilidade, e mecanicamente é — os atrasados são colocados em segundo plano, e o uptime é recompensado. Mas o caminho de volta depende inteiramente de ser escolhido de novo, não de esperar.
Vale checar: quantos epochs normalmente leva um provisionador suspenso no @Dusk para voltar a um comitê ativo após uma única falha.