Houve um tempo em que deixei o nó rodando e fui fazer um café; voltei e vi os logs ainda fluindo de forma constante... foi quando comecei a pensar que a maior estabilidade de uptime também é a coisa mais fácil de te deixar complacente.
Entrei em config.rs: proposal = 1 credit, validation = 64, ratification = 64, quorum = 33.
se ter stake suficiente fosse tudo o que fosse necessário, para que serviriam todos esses parâmetros?
Mudei para sortition.rs: score = hash mod total_staking_weight.
à medida que o peso do stake aumenta, a probabilidade de seleção pode aumentar, mas probabilidade não é sinônimo de direito.
depois fui para core/src/stake.rs, linha 46: DEFAULT_MINIMUM_STAKE = 1000.
sinceramente, eu costumava ver o stake mínimo como a linha de chegada, quando na verdade é mais uma condição de inicialização do que um estado garantido.
fazer staking de 1500 DUSK significa exceder o mínimo em 500 DUSK.
mas perder a votação traz uma penalidade branda, suspensão de elegibilidade e, quando parte do stake passa a ficar bloqueada, aquele número deixa de parecer tão bom imediatamente.
o top-up funciona da mesma forma: 90% imediatamente ativo, 10% bloqueado.
500 DUSK significa 450 DUSK ativos, 50 DUSK bloqueados... parece pouco, mas as consequências não são.
desde então, toda vez que audito um protocolo, eu inspeciono datatype, implementação, transição de estado, participação em votação, condições de runtime, disponibilidade da máquina, e a desistência total do staking.
quorum = 33.
mas esses 33 votos ou 33%?
chegar a uma conclusão sem verificar o datatype é certamente rápido, mas a resposta mais rápida às vezes pode ser a mais errada.
score, hash, comitê, estado bloqueado, validation, ratification... quanto mais eu rastreio, mais eu vejo que um validador não é apenas um monte de stake parado, mas um sistema que precisa permanecer vivo continuamente.
para mim, um validador confiável não é o nó com o maior stake, mas o nó com a disciplina operacional mais forte quando ninguém está ao lado dele lembrando-o de votar.
se você tivesse que escolher entre aumentar o peso do stake em 20% e reduzir votos perdidos, downtime, penalidade em operações do mundo real, qual lado você escolheria?
#dusk $DUSK @Dusk
Entrei em config.rs: proposal = 1 credit, validation = 64, ratification = 64, quorum = 33.
se ter stake suficiente fosse tudo o que fosse necessário, para que serviriam todos esses parâmetros?
Mudei para sortition.rs: score = hash mod total_staking_weight.
à medida que o peso do stake aumenta, a probabilidade de seleção pode aumentar, mas probabilidade não é sinônimo de direito.
depois fui para core/src/stake.rs, linha 46: DEFAULT_MINIMUM_STAKE = 1000.
sinceramente, eu costumava ver o stake mínimo como a linha de chegada, quando na verdade é mais uma condição de inicialização do que um estado garantido.
fazer staking de 1500 DUSK significa exceder o mínimo em 500 DUSK.
mas perder a votação traz uma penalidade branda, suspensão de elegibilidade e, quando parte do stake passa a ficar bloqueada, aquele número deixa de parecer tão bom imediatamente.
o top-up funciona da mesma forma: 90% imediatamente ativo, 10% bloqueado.
500 DUSK significa 450 DUSK ativos, 50 DUSK bloqueados... parece pouco, mas as consequências não são.
desde então, toda vez que audito um protocolo, eu inspeciono datatype, implementação, transição de estado, participação em votação, condições de runtime, disponibilidade da máquina, e a desistência total do staking.
quorum = 33.
mas esses 33 votos ou 33%?
chegar a uma conclusão sem verificar o datatype é certamente rápido, mas a resposta mais rápida às vezes pode ser a mais errada.
score, hash, comitê, estado bloqueado, validation, ratification... quanto mais eu rastreio, mais eu vejo que um validador não é apenas um monte de stake parado, mas um sistema que precisa permanecer vivo continuamente.
para mim, um validador confiável não é o nó com o maior stake, mas o nó com a disciplina operacional mais forte quando ninguém está ao lado dele lembrando-o de votar.
se você tivesse que escolher entre aumentar o peso do stake em 20% e reduzir votos perdidos, downtime, penalidade em operações do mundo real, qual lado você escolheria?
#dusk $DUSK @Dusk
