venho lendo a campanha do creator pad @Dusk e acabei indo até os docs de recompensas da Dusk, esperando que o APY fosse a parte mais interessante.
Em vez disso, continuei voltando a quem recebe pagamento, quanto e quando.
Isso ficou mais interessante por causa do que aconteceu em 16 de agosto.
A Dusk sinalizou uma atividade suspeita envolvendo uma carteira gerenciada por equipe conectada às operações da bridge. A resposta foi rápida: os endereços das bridges afetados foram desativados/reciclados, a bridge foi pausada e uma lista de bloqueio para destinatários de Web Wallet foi publicada no mesmo dia.
Bom incident response. Mas também me fez olhar com mais atenção para o outro lado da segurança: como os participantes do consenso são realmente recompensados.
Veja o que se destacou:
• Os geradores de blocos recebem 70% da recompensa como fatia-base.
• Eles podem receber até mais 10%, dependendo dos créditos agregados ao certificado.
• Os provissioners, os participantes que votam e atestam blocos, dividem o restante da recompensa.
• Se parte da recompensa não for alocada, ela pode ser queimada em vez de distribuída.
Isso cria uma estrutura de recompensas em que a pessoa que gera o bloco pode receber uma parcela significativamente maior logo de início, enquanto os participantes que ajudam a finalizar o consenso competem pela parcela restante.
E é essa a parte que eu acho fácil de perder quando você simplesmente lê “consensus participants share rewards”.
O design em si não é necessariamente um problema. Redes PoS diferentes usam incentivos diferentes para equilibrar produção de blocos, votação e segurança da rede.
Mas depois de olhar os números, uma pergunta parece mais importante do que o APY em destaque:
Com que frequência esses 10% adicionais realmente são pagos aos geradores e com que frequência acabam sendo queimados?
Porque a divisão teórica e o fluxo real de recompensas podem parecer bem diferentes.
E depois de um incidente na bridge, entender para onde os incentivos realmente se movem parece tão importante quanto entender o quão rapidamente a equipe consegue reagir.
#dusk $DUSK @Dusk
Em vez disso, continuei voltando a quem recebe pagamento, quanto e quando.
Isso ficou mais interessante por causa do que aconteceu em 16 de agosto.
A Dusk sinalizou uma atividade suspeita envolvendo uma carteira gerenciada por equipe conectada às operações da bridge. A resposta foi rápida: os endereços das bridges afetados foram desativados/reciclados, a bridge foi pausada e uma lista de bloqueio para destinatários de Web Wallet foi publicada no mesmo dia.
Bom incident response. Mas também me fez olhar com mais atenção para o outro lado da segurança: como os participantes do consenso são realmente recompensados.
Veja o que se destacou:
• Os geradores de blocos recebem 70% da recompensa como fatia-base.
• Eles podem receber até mais 10%, dependendo dos créditos agregados ao certificado.
• Os provissioners, os participantes que votam e atestam blocos, dividem o restante da recompensa.
• Se parte da recompensa não for alocada, ela pode ser queimada em vez de distribuída.
Isso cria uma estrutura de recompensas em que a pessoa que gera o bloco pode receber uma parcela significativamente maior logo de início, enquanto os participantes que ajudam a finalizar o consenso competem pela parcela restante.
E é essa a parte que eu acho fácil de perder quando você simplesmente lê “consensus participants share rewards”.
O design em si não é necessariamente um problema. Redes PoS diferentes usam incentivos diferentes para equilibrar produção de blocos, votação e segurança da rede.
Mas depois de olhar os números, uma pergunta parece mais importante do que o APY em destaque:
Com que frequência esses 10% adicionais realmente são pagos aos geradores e com que frequência acabam sendo queimados?
Porque a divisão teórica e o fluxo real de recompensas podem parecer bem diferentes.
E depois de um incidente na bridge, entender para onde os incentivos realmente se movem parece tão importante quanto entender o quão rapidamente a equipe consegue reagir.
#dusk $DUSK @Dusk
