Eu me lembro de quando eu costumava olhar para um novo design de consenso e fazer uma pergunta primeiro.

Como um atacante quebra isso?

Estudar o Dusk mudou esse hábito.

Com a Attestation Succinct, comecei a pensar em um cenário diferente.

Imagine que você é um provisionador. Você está votando na iteração atual, mas já sabe que foi selecionado para gerar um bloco em uma iteração posterior.

Agora existe uma escolha estranha diante de você.

Você ajuda o bloco atual a avançar e coletar sua recompensa de eleitor?

Ou você fica em silêncio, permite que a iteração atual falhe e potencialmente melhora sua posição como gerador futuro?

Esse é o Future Generator Incentive Problem (Problema de Incentivo do Gerador Futuro) que o Dusk identificou no seu design de consenso. A parte interessante é que isso não tem a ver com um hacker encontrando uma falha de fora.

Isso vem dos incentivos disponíveis para um participante legítimo.

@Dusk_Foundation response foi remodelar esses incentivos, incluindo separar as recompensas de gerador e de eleitor e restringir o gerador da próxima iteração da votação atual.

Esse detalhe ficou comigo.

Porque é fácil dizer que um consenso é seguro.

É mais difícil projetar um em que o movimento mais racional também seja o honesto.

Esse é o jogo real acontecendo por baixo da criptografia.

#dusk $DUSK #Dusk