Minha primeira reação ao ler o consenso SA foi: como é que o número 1000 DUSK foi definido. O whitepaper só mostra o resultado, não traz o processo de dedução. Então eu fui ao encontro dos seus parâmetros para chegar ao ponto de trás.
Ele define um epoch de 2160 blocos. Pelo ritmo atual de produção de blocos da Dusk, isso dá aproximadamente 6 horas por epoch. Depois, ele fornece uma fórmula de maturidade: M = 2 × epoch - (height mod epoch). Ou seja, se você fizer um staking de uma quantia em DUSK, precisa esperar algo próximo de meio epoch até completar um epoch inteiro para só então começar a trabalhar de verdade.
O interessante desse desenho é que ele alinha o tempo de efetivação de todo novo staking ao limite do epoch. Não é “vale assim que cair”, e sim que o grupo ativa em um mesmo ponto de início. Acho que o objetivo é fazer com que o algoritmo de sorteio determinístico do protocolo DS tenha um snapshot estável de um pool de stake. Se alguém pudesse entrar a qualquer momento, e a efetividade começasse imediatamente, o conjunto de candidatos a provisioner de cada bloco mudaria. Aí a alocação determinística fica difícil de realizar.
$DUSK
E quanto aos próprios 1000 DUSK? Eu calculei: se o limiar (threshold) fosse 100, a quantidade de provisioners iria explodir. A concorrência entre os 64 slots por epoch ficaria mais intensa. Porém, o volume de staking por nó seria muito baixo, e a segurança da rede poderia ser diluída. Se fosse 10000, a maioria dos pequenos investidores quase não entraria; os provisioners virariam um “jogo” dominado por poucos nós grandes, e a descentralização perde força.
@Dusk
Então esse número 1000 fica justamente no meio. Eu conferi os parâmetros de outras cadeias PoS: o limiar da Dusk não parece especialmente alto, mas também não é baixo. É como se estivesse dizendo: “não quero que você venha rodar um nó com qualquer troco; mas também não quero que você precise necessariamente ser um grande detentor para participar”.
#dusk
Mas ainda assim tenho uma questão que não ficou totalmente clara. O whitepaper não define uma faixa de meta para o número total de provisioners, nem diz em que proporção a disputa entre os 64 slots deve ficar para ser o melhor cenário. Sem esses dados, eu não consigo realmente avaliar se 1000 é um valor correto. Talvez a sua racionalidade só possa ser verificada com dados reais após o lançamento na mainnet.
Ele define um epoch de 2160 blocos. Pelo ritmo atual de produção de blocos da Dusk, isso dá aproximadamente 6 horas por epoch. Depois, ele fornece uma fórmula de maturidade: M = 2 × epoch - (height mod epoch). Ou seja, se você fizer um staking de uma quantia em DUSK, precisa esperar algo próximo de meio epoch até completar um epoch inteiro para só então começar a trabalhar de verdade.
O interessante desse desenho é que ele alinha o tempo de efetivação de todo novo staking ao limite do epoch. Não é “vale assim que cair”, e sim que o grupo ativa em um mesmo ponto de início. Acho que o objetivo é fazer com que o algoritmo de sorteio determinístico do protocolo DS tenha um snapshot estável de um pool de stake. Se alguém pudesse entrar a qualquer momento, e a efetividade começasse imediatamente, o conjunto de candidatos a provisioner de cada bloco mudaria. Aí a alocação determinística fica difícil de realizar.
$DUSK
E quanto aos próprios 1000 DUSK? Eu calculei: se o limiar (threshold) fosse 100, a quantidade de provisioners iria explodir. A concorrência entre os 64 slots por epoch ficaria mais intensa. Porém, o volume de staking por nó seria muito baixo, e a segurança da rede poderia ser diluída. Se fosse 10000, a maioria dos pequenos investidores quase não entraria; os provisioners virariam um “jogo” dominado por poucos nós grandes, e a descentralização perde força.
@Dusk
Então esse número 1000 fica justamente no meio. Eu conferi os parâmetros de outras cadeias PoS: o limiar da Dusk não parece especialmente alto, mas também não é baixo. É como se estivesse dizendo: “não quero que você venha rodar um nó com qualquer troco; mas também não quero que você precise necessariamente ser um grande detentor para participar”.
#dusk
Mas ainda assim tenho uma questão que não ficou totalmente clara. O whitepaper não define uma faixa de meta para o número total de provisioners, nem diz em que proporção a disputa entre os 64 slots deve ficar para ser o melhor cenário. Sem esses dados, eu não consigo realmente avaliar se 1000 é um valor correto. Talvez a sua racionalidade só possa ser verificada com dados reais após o lançamento na mainnet.