#dusk $DUSK @Dusk Passei pela seção de incentivo de consenso esta semana porque queria entender se um participante (staker) maior poderia explorar o momento da geração de blocos.
Achado inesperado: o whitepaper nomeia esse problema exato. "Future-generator incentive problem" — geradores de iterações mais altas podem se beneficiar se iterações anteriores falharem, pois então vencem a recompensa do bloco. É uma vulnerabilidade nomeada, não escondida.
A atualização do protocolo Aegis na rede principal (3 de março de 2026) focou em resiliência de rede. Parte do motivo pelo qual a resiliência importa aqui: esse incentivo exato pode fazer com que geradores de iteração anterior tenham desempenho abaixo do esperado.
Três mecanismos resolvem isso: recompensas para eleitores (provedores ganham votando, não apenas gerando); créditos extras (o gerador perde o extra de 10% se excluir votos — então o sabotador também é penalizado); exclusão de geradores da próxima iteração do passo de votação atual.
A maioria dos sistemas PoS não tem esse problema: não há uma estrutura sequencial de iterações, então não existe um sucessor esperando se beneficiar da falha de um predecessor. A arquitetura do Dusk cria essa vulnerabilidade e depois a corrige.
Um protocolo que nomeia explicitamente sua própria falha de teoria dos jogos está fazendo algo incomum. Se as três correções se sustentam sob estresse real de rede com capital concentrado é a pergunta aberta e honesta. @Dusk
$DUSK #dusk
Achado inesperado: o whitepaper nomeia esse problema exato. "Future-generator incentive problem" — geradores de iterações mais altas podem se beneficiar se iterações anteriores falharem, pois então vencem a recompensa do bloco. É uma vulnerabilidade nomeada, não escondida.
A atualização do protocolo Aegis na rede principal (3 de março de 2026) focou em resiliência de rede. Parte do motivo pelo qual a resiliência importa aqui: esse incentivo exato pode fazer com que geradores de iteração anterior tenham desempenho abaixo do esperado.
Três mecanismos resolvem isso: recompensas para eleitores (provedores ganham votando, não apenas gerando); créditos extras (o gerador perde o extra de 10% se excluir votos — então o sabotador também é penalizado); exclusão de geradores da próxima iteração do passo de votação atual.
A maioria dos sistemas PoS não tem esse problema: não há uma estrutura sequencial de iterações, então não existe um sucessor esperando se beneficiar da falha de um predecessor. A arquitetura do Dusk cria essa vulnerabilidade e depois a corrige.
Um protocolo que nomeia explicitamente sua própria falha de teoria dos jogos está fazendo algo incomum. Se as três correções se sustentam sob estresse real de rede com capital concentrado é a pergunta aberta e honesta. @Dusk
$DUSK #dusk