#dusk $DUSK
Sinceramente, estoy sorprendido. Solo 5 puntos a pesar de haber logrado 5K vistas, se siente realmente injusto y decepcionante.
Publico hoy con el corazón encogido… pero antes de la publicación, aquí va un scalp rápido:
Long $PORTAL 📈
Short $CYS 📉
no olvides agradecerme cuando reserves la ganancia
originalmente pensé que que me recortaran en @Dusk significaba una cosa: perder la inversión y reiniciar el nodo
la guía de recuperación marca una línea mucho más precisa.
Una penalización suave puede suspender la elegibilidad de un provisioner y mover parte de su stake activo a stake bloqueado. Ese stake sigue perteneciendo al operador y puede retirarse.
Las penalizaciones duras se aplican a comportamientos de consenso probadamente inválidos, como votos contradictorios o equivocación. Parte del stake se quema, y reiniciar o volver a apostar no puede recuperarlo.
esa distinción fue la que se me quedó.
Dusk trata de forma diferente la participación ausente y la participación contradictoria. Una versión desactualizada, una caída de servicio prolongada, mala sincronización o tráfico de red bloqueado pueden causar un fallo operativo. Firmar mensajes contradictorios cruza hacia un comportamiento que el protocolo puede demostrar que era inválido.
La advertencia de clave duplicada hace que el límite sea práctico.
Ejecutar la misma clave de consenso en dos nodos activos puede hacer que ambas máquinas firmen mensajes incompatibles incluso si el operador pensó que el segundo nodo solo era una copia de seguridad.
Me gusta que la recuperación empiece por arreglar versión, sincronización, conectividad y configuración de la clave antes de crear una nueva posición de provisioner. Volver a apostar sin encontrar la causa solo colocaría una posición nueva detrás del mismo montaje roto
también significa que la redundancia tiene que diseñarse con cuidado. Una copia de seguridad pensada para mejorar la disponibilidad puede crear un riesgo de hard-slashing si se vuelve activa con la misma clave.
¿Separar el fallo operativo de la equivocación crea penalizaciones más justas o hace que la gestión de la clave de consenso sea la parte más implacable al ejecutar un provisioner?
El slashing del provisioner en @Dusk plantea una pregunta interesante
¿Qué importa más para mantener seguros a los validadores?
Sinceramente, estoy sorprendido. Solo 5 puntos a pesar de haber logrado 5K vistas, se siente realmente injusto y decepcionante.
Publico hoy con el corazón encogido… pero antes de la publicación, aquí va un scalp rápido:
Long $PORTAL 📈
Short $CYS 📉
no olvides agradecerme cuando reserves la ganancia
originalmente pensé que que me recortaran en @Dusk significaba una cosa: perder la inversión y reiniciar el nodo
la guía de recuperación marca una línea mucho más precisa.
Una penalización suave puede suspender la elegibilidad de un provisioner y mover parte de su stake activo a stake bloqueado. Ese stake sigue perteneciendo al operador y puede retirarse.
Las penalizaciones duras se aplican a comportamientos de consenso probadamente inválidos, como votos contradictorios o equivocación. Parte del stake se quema, y reiniciar o volver a apostar no puede recuperarlo.
esa distinción fue la que se me quedó.
Dusk trata de forma diferente la participación ausente y la participación contradictoria. Una versión desactualizada, una caída de servicio prolongada, mala sincronización o tráfico de red bloqueado pueden causar un fallo operativo. Firmar mensajes contradictorios cruza hacia un comportamiento que el protocolo puede demostrar que era inválido.
La advertencia de clave duplicada hace que el límite sea práctico.
Ejecutar la misma clave de consenso en dos nodos activos puede hacer que ambas máquinas firmen mensajes incompatibles incluso si el operador pensó que el segundo nodo solo era una copia de seguridad.
Me gusta que la recuperación empiece por arreglar versión, sincronización, conectividad y configuración de la clave antes de crear una nueva posición de provisioner. Volver a apostar sin encontrar la causa solo colocaría una posición nueva detrás del mismo montaje roto
también significa que la redundancia tiene que diseñarse con cuidado. Una copia de seguridad pensada para mejorar la disponibilidad puede crear un riesgo de hard-slashing si se vuelve activa con la misma clave.
¿Separar el fallo operativo de la equivocación crea penalizaciones más justas o hace que la gestión de la clave de consenso sea la parte más implacable al ejecutar un provisioner?
El slashing del provisioner en @Dusk plantea una pregunta interesante
¿Qué importa más para mantener seguros a los validadores?
- Fair penalty design
35%
- Consensus-key security
22%
- Reliable node uptime
13%
- All equally important
30%
23 Votos • Votación cerrada