#dusk $DUSK @Dusk
Quanto mais eu me aprofundo em @Dusk , mais eu percebo que a parte realmente interessante do consenso não é simplesmente como os validadores chegam a um acordo. É o que acontece quando esses validadores têm seus próprios incentivos. Uma coisa que realmente chamou minha atenção é o problema do gerador futuro. Se um gerador sabe que poderia ser selecionado em uma iteração posterior, pode haver um motivo para permitir que a iteração atual falhe se isso melhorar sua própria posição. É aí que o consenso se torna mais do que um problema técnico. Você precisa pensar também em comportamento humano e em economia, porque validadores não são máquinas perfeitamente cooperativas. Eles são participantes que naturalmente vão buscar o resultado que mais lhes favorece.
É aqui que o design do Dusk fica interessante para mim. As recompensas aos eleitores dão aos participantes um motivo para apoiar a iteração atual, enquanto os créditos extras dão aos geradores outro incentivo para incluir votos válidos. A exclusão do próximo gerador também ajuda a reduzir o conflito óbvio, mantendo o gerador esperado seguinte fora do comitê de votação atual. Então o limite de iterações coloca uma restrição de quanto tempo esse jogo estratégico pode continuar. Eu gosto do raciocínio por trás disso porque o protocolo parece ter sido desenhado com uma suposição realista: se houver um incentivo para explorar algo, eventualmente alguém vai tentar. Mas isso também levanta a questão que considero mais importante. O que acontece quando os participantes procuram ativamente a forma mais lucrativa de fazer o sistema “jogar” a favor deles? Se a cooperação ainda lhes der o melhor resultado, então o design de incentivos está fazendo seu trabalho. Para mim, esse é o teste real do consenso do Dusk. Não é se todo mundo se comporta perfeitamente, mas se o sistema faz a escolha racional — aquela que é cooperativa.
Quanto mais eu me aprofundo em @Dusk , mais eu percebo que a parte realmente interessante do consenso não é simplesmente como os validadores chegam a um acordo. É o que acontece quando esses validadores têm seus próprios incentivos. Uma coisa que realmente chamou minha atenção é o problema do gerador futuro. Se um gerador sabe que poderia ser selecionado em uma iteração posterior, pode haver um motivo para permitir que a iteração atual falhe se isso melhorar sua própria posição. É aí que o consenso se torna mais do que um problema técnico. Você precisa pensar também em comportamento humano e em economia, porque validadores não são máquinas perfeitamente cooperativas. Eles são participantes que naturalmente vão buscar o resultado que mais lhes favorece.
É aqui que o design do Dusk fica interessante para mim. As recompensas aos eleitores dão aos participantes um motivo para apoiar a iteração atual, enquanto os créditos extras dão aos geradores outro incentivo para incluir votos válidos. A exclusão do próximo gerador também ajuda a reduzir o conflito óbvio, mantendo o gerador esperado seguinte fora do comitê de votação atual. Então o limite de iterações coloca uma restrição de quanto tempo esse jogo estratégico pode continuar. Eu gosto do raciocínio por trás disso porque o protocolo parece ter sido desenhado com uma suposição realista: se houver um incentivo para explorar algo, eventualmente alguém vai tentar. Mas isso também levanta a questão que considero mais importante. O que acontece quando os participantes procuram ativamente a forma mais lucrativa de fazer o sistema “jogar” a favor deles? Se a cooperação ainda lhes der o melhor resultado, então o design de incentivos está fazendo seu trabalho. Para mim, esse é o teste real do consenso do Dusk. Não é se todo mundo se comporta perfeitamente, mas se o sistema faz a escolha racional — aquela que é cooperativa.
