Hubo un tiempo en que dejé el nodo ejecutándose y fui a hacer café; volví y vi que los logs seguían fluyendo de manera constante... fue entonces cuando empecé a pensar que el uptime más estable también es lo más fácil para que te vuelvas complaciente.
Entré en config.rs: proposal = 1 credit, validation = 64, ratification = 64, quorum = 33.
Si tener suficiente stake fuera lo único que se necesitara, ¿para qué servirían todos estos parámetros?
Me moví a sortition.rs: score = hash mod total_staking_weight.
a medida que aumenta el peso del stake, puede aumentar la probabilidad de selección, pero la probabilidad no es un derecho.
luego llegué a core/src/stake.rs, línea 46: DEFAULT_MINIMUM_STAKE = 1000.
para ser honesto, antes veía el stake mínimo como la línea de llegada, cuando en realidad es más una condición de inicialización que un estado garantizado.
apostar 1500 DUSK significa superar el mínimo en 500 DUSK.
pero perder votos trae una penalización leve, la suspensión de elegibilidad y, una vez que parte del stake pasa a estar bloqueado, ese número deja de verse tan bien de inmediato.
el “top-up” funciona igual: 90% activo de inmediato, 10% bloqueado.
500 DUSK significa 450 DUSK activos, 50 DUSK bloqueados... suena pequeño, pero las consecuencias no lo son.
desde entonces, cada vez que audito un protocolo, inspecciono el tipo de dato, la implementación, la transición de estado, la participación en la votación, las condiciones del runtime, la disponibilidad de la máquina y la salida completa del staking.
quorum = 33.
pero ¿son esos 33 votos o 33%?
tomar una conclusión sin comprobar el tipo de dato es ciertamente rápido, pero la respuesta más rápida a veces puede ser la más incorrecta.
score, hash, committee, estado bloqueado, validation, ratification... cuanto más los rastreo, más veo que un validador no es un montón de stake inmóvil, sino un sistema que tiene que mantenerse vivo de forma continua.
para mí, un validador confiable no es el nodo con el mayor stake, sino el nodo con la disciplina operativa más sólida cuando nadie está a su lado recordándole que vote.
si tuvieras que elegir entre aumentar el peso del stake en un 20% y reducir los votos perdidos, el tiempo de inactividad y la penalización en operaciones del mundo real, ¿qué lado elegirías?
#dusk $DUSK @Dusk
Entré en config.rs: proposal = 1 credit, validation = 64, ratification = 64, quorum = 33.
Si tener suficiente stake fuera lo único que se necesitara, ¿para qué servirían todos estos parámetros?
Me moví a sortition.rs: score = hash mod total_staking_weight.
a medida que aumenta el peso del stake, puede aumentar la probabilidad de selección, pero la probabilidad no es un derecho.
luego llegué a core/src/stake.rs, línea 46: DEFAULT_MINIMUM_STAKE = 1000.
para ser honesto, antes veía el stake mínimo como la línea de llegada, cuando en realidad es más una condición de inicialización que un estado garantizado.
apostar 1500 DUSK significa superar el mínimo en 500 DUSK.
pero perder votos trae una penalización leve, la suspensión de elegibilidad y, una vez que parte del stake pasa a estar bloqueado, ese número deja de verse tan bien de inmediato.
el “top-up” funciona igual: 90% activo de inmediato, 10% bloqueado.
500 DUSK significa 450 DUSK activos, 50 DUSK bloqueados... suena pequeño, pero las consecuencias no lo son.
desde entonces, cada vez que audito un protocolo, inspecciono el tipo de dato, la implementación, la transición de estado, la participación en la votación, las condiciones del runtime, la disponibilidad de la máquina y la salida completa del staking.
quorum = 33.
pero ¿son esos 33 votos o 33%?
tomar una conclusión sin comprobar el tipo de dato es ciertamente rápido, pero la respuesta más rápida a veces puede ser la más incorrecta.
score, hash, committee, estado bloqueado, validation, ratification... cuanto más los rastreo, más veo que un validador no es un montón de stake inmóvil, sino un sistema que tiene que mantenerse vivo de forma continua.
para mí, un validador confiable no es el nodo con el mayor stake, sino el nodo con la disciplina operativa más sólida cuando nadie está a su lado recordándole que vote.
si tuvieras que elegir entre aumentar el peso del stake en un 20% y reducir los votos perdidos, el tiempo de inactividad y la penalización en operaciones del mundo real, ¿qué lado elegirías?
#dusk $DUSK @Dusk
