Il y a eu un temps où je laissais le nœud en marche, puis je partais faire un café, je revenais et je voyais que les journaux continuaient de défiler régulièrement... c’est là que j’ai commencé à penser que la disponibilité la plus stable est aussi la chose la plus simple à utiliser pour vous rendre complaisant.
Je suis allé dans config.rs : proposal = 1 credit, validation = 64, ratification = 64, quorum = 33.
Si avoir suffisamment de capital était tout ce qu’il fallait, à quoi serviraient tous ces paramètres ?
Je suis passé à sortition.rs : score = hash mod total_staking_weight.
à mesure que le poids du stake augmente, la probabilité de sélection peut augmenter, mais la probabilité n’est pas une attribution.
ensuite, je suis arrivé à core/src/stake.rs, ligne 46 : DEFAULT_MINIMUM_STAKE = 1000.
Pour être honnête, je voyais autrefois le minimum de stake comme la ligne d’arrivée, alors que c’est plutôt une condition d’initialisation qu’un état garanti.
Staker 1500 DUSK signifie dépasser le minimum de 500 DUSK.
mais le fait de manquer un vote entraîne une pénalité souple : suspension de l’éligibilité, et une fois qu’une partie du stake passe en verrouillé, ce chiffre cesse de paraître aussi intéressant immédiatement.
le complément (top-up) fonctionne de la même façon : 90% actifs immédiatement, 10% verrouillés.
500 DUSK signifie 450 DUSK actifs, 50 DUSK verrouillés... ça paraît petit, mais les conséquences ne le sont pas.
depuis lors, chaque fois que j’audite un protocole, j’inspecte le type de données, l’implémentation, la transition d’état, la participation au vote, les conditions d’exécution, la disponibilité de la machine, le déblocage complet (full unstaking).
quorum = 33.
mais ces 33 votes correspondent-ils à 33 votes, ou à 33% ?
tirer une conclusion sans vérifier le type de données est certainement rapide, mais la réponse la plus rapide peut parfois être la plus fausse.
score, hash, comité, état verrouillé, validation, ratification... plus je les suis dans leurs traces, plus je vois qu’un validateur n’est pas juste une pile de stake posée là immobile, mais un système qui doit rester vivant en permanence.
Pour moi, un validateur digne de confiance n’est pas le nœud qui a le plus gros stake, mais celui qui fait preuve de la discipline opérationnelle la plus solide quand personne n’est à côté pour lui rappeler de voter.
si vous deviez choisir entre augmenter le poids du stake de 20% et réduire le nombre de votes manqués, les temps d’arrêt et la pénalité dans des opérations réelles, quel côté choisiriez-vous ?
#dusk $DUSK @Dusk
Je suis allé dans config.rs : proposal = 1 credit, validation = 64, ratification = 64, quorum = 33.
Si avoir suffisamment de capital était tout ce qu’il fallait, à quoi serviraient tous ces paramètres ?
Je suis passé à sortition.rs : score = hash mod total_staking_weight.
à mesure que le poids du stake augmente, la probabilité de sélection peut augmenter, mais la probabilité n’est pas une attribution.
ensuite, je suis arrivé à core/src/stake.rs, ligne 46 : DEFAULT_MINIMUM_STAKE = 1000.
Pour être honnête, je voyais autrefois le minimum de stake comme la ligne d’arrivée, alors que c’est plutôt une condition d’initialisation qu’un état garanti.
Staker 1500 DUSK signifie dépasser le minimum de 500 DUSK.
mais le fait de manquer un vote entraîne une pénalité souple : suspension de l’éligibilité, et une fois qu’une partie du stake passe en verrouillé, ce chiffre cesse de paraître aussi intéressant immédiatement.
le complément (top-up) fonctionne de la même façon : 90% actifs immédiatement, 10% verrouillés.
500 DUSK signifie 450 DUSK actifs, 50 DUSK verrouillés... ça paraît petit, mais les conséquences ne le sont pas.
depuis lors, chaque fois que j’audite un protocole, j’inspecte le type de données, l’implémentation, la transition d’état, la participation au vote, les conditions d’exécution, la disponibilité de la machine, le déblocage complet (full unstaking).
quorum = 33.
mais ces 33 votes correspondent-ils à 33 votes, ou à 33% ?
tirer une conclusion sans vérifier le type de données est certainement rapide, mais la réponse la plus rapide peut parfois être la plus fausse.
score, hash, comité, état verrouillé, validation, ratification... plus je les suis dans leurs traces, plus je vois qu’un validateur n’est pas juste une pile de stake posée là immobile, mais un système qui doit rester vivant en permanence.
Pour moi, un validateur digne de confiance n’est pas le nœud qui a le plus gros stake, mais celui qui fait preuve de la discipline opérationnelle la plus solide quand personne n’est à côté pour lui rappeler de voter.
si vous deviez choisir entre augmenter le poids du stake de 20% et réduire le nombre de votes manqués, les temps d’arrêt et la pénalité dans des opérations réelles, quel côté choisiriez-vous ?
#dusk $DUSK @Dusk
