A altas horas de la noche de ayer, tenía abierto mi script de monitoreo de nodos “masticando” las normas de validadores de <@Dusk _Foundation> y, justo entonces, me topé con las reglas del código que activan el <Soft Penalty>. En ese momento sentí un vuelco. Cuando todos estaban haciendo staking, por ejemplo <$DUSK >, muchas veces solo se quedaban mirando el APY que se muestra y se alegraban como si nada, pero siendo honestos: lo que de verdad decide si tu rendimiento se te descuenta en seco hasta quedarte sin nada—o incluso perder el capital—está totalmente en el nivel de <locked> y en esa frecuencia de castigos oculta.
En el marco de consenso de <#dusk > de <Succinct Attestation>, tanto el <Block Generator> que se encarga de proponer bloques como el <Committee> que luego valida las firmas, los tokens que tienen no son solo “combustible”: son una garantía lista para que la red los retenga. El umbral de entrada de 1,000 tokens, en pocas palabras, es tu pase. Si el nodo, por cualquier fluctuación de la red, llega a fallar en validar y se le aplica un <Soft Penalty>, de inmediato ese monto se captura y pasa a <locked>. La parte bloqueada no solo no alcanza para dividendos; si además tu <active stake> se mete por debajo del mínimo, en el siguiente epoch el nodo queda directamente fuera de la lista de candidatos. Y cuando eso ocurre, toda ganancia de delegaciones que estaba colgada arriba queda en cero. <$BTC >
No hace mucho, al montar mi propio nodo para pruebas y hacer un test de carga en la red de pruebas, yo mismo caí en esa trampa. Al hacer un <top-up> de reposición, el protocolo venía con una dilución del 10% ya incluida en el <locked>: de pronto, aunque agregué 4,000 monedas, lo que realmente podía ponerse a trabajar al instante eran solo 3,600. Y lo peor es que las porciones congeladas por la penalización no se pueden usar “cuando te plazca”: hay que esperar a que llegue el momento exacto del cambio de epoch para que se descongelen y vuelvan a estar disponibles. Algunos nodos de custodia de terceros, con tasas anuales aparentemente altísimas en la vitrina, te pintan un cuadro precioso; pero en los registros del backend, cada dos por tres aparece <missed participation>. En la práctica, el rendimiento real resulta desolador. <$ETH >
Ahora, al seleccionar nodos, ya dejé de hacerme el ciego persiguiendo alzas sin sentido. Necesito, sí o sí, usar un indexador para revisar bien cuántas veces al nodo le han descontado penalizaciones en el historial y qué proporción de su <locked> tiene. Esto no es una tarea de copiar y pegar sin pensar: depende de cuánto trabajo de validación estés dispuesto a hacer para priorizar la seguridad de tu capital. <@Dusk >
En el marco de consenso de <#dusk > de <Succinct Attestation>, tanto el <Block Generator> que se encarga de proponer bloques como el <Committee> que luego valida las firmas, los tokens que tienen no son solo “combustible”: son una garantía lista para que la red los retenga. El umbral de entrada de 1,000 tokens, en pocas palabras, es tu pase. Si el nodo, por cualquier fluctuación de la red, llega a fallar en validar y se le aplica un <Soft Penalty>, de inmediato ese monto se captura y pasa a <locked>. La parte bloqueada no solo no alcanza para dividendos; si además tu <active stake> se mete por debajo del mínimo, en el siguiente epoch el nodo queda directamente fuera de la lista de candidatos. Y cuando eso ocurre, toda ganancia de delegaciones que estaba colgada arriba queda en cero. <$BTC >
No hace mucho, al montar mi propio nodo para pruebas y hacer un test de carga en la red de pruebas, yo mismo caí en esa trampa. Al hacer un <top-up> de reposición, el protocolo venía con una dilución del 10% ya incluida en el <locked>: de pronto, aunque agregué 4,000 monedas, lo que realmente podía ponerse a trabajar al instante eran solo 3,600. Y lo peor es que las porciones congeladas por la penalización no se pueden usar “cuando te plazca”: hay que esperar a que llegue el momento exacto del cambio de epoch para que se descongelen y vuelvan a estar disponibles. Algunos nodos de custodia de terceros, con tasas anuales aparentemente altísimas en la vitrina, te pintan un cuadro precioso; pero en los registros del backend, cada dos por tres aparece <missed participation>. En la práctica, el rendimiento real resulta desolador. <$ETH >
Ahora, al seleccionar nodos, ya dejé de hacerme el ciego persiguiendo alzas sin sentido. Necesito, sí o sí, usar un indexador para revisar bien cuántas veces al nodo le han descontado penalizaciones en el historial y qué proporción de su <locked> tiene. Esto no es una tarea de copiar y pegar sin pensar: depende de cuánto trabajo de validación estés dispuesto a hacer para priorizar la seguridad de tu capital. <@Dusk >