12190 | Fallo Automático de Validadores Inactivos de Larga Duración – Elección del Delegado (Desarrollo de Testnet)

Fuente de:

• https://validator.info/terra-classic/governance/12190
• https://discourse.luncgoblins.com/t/automatic-failover-from-long-term-inactive-validators/107

Desarrollar/probar (red de pruebas) la recuperación automática para LUNC: umbral de encarcelamiento por delegación (7-90d) + acción requerida: Reasignar a los activos de menor potencia o Desasignar (21d). Tombstone desencadena inmediatamente; long jail desencadena el siguiente bloque.

Elección por Delegador: Redelegar o Deselegar (Aprobación del desarrollo de Testnet)

TL;DR
Demasiada participación recae en validadores inactivos (encarcelados/tombstoned) que ganan un 0% y debilitan la descentralización.
Propongo que desarrollemos y probemos en testnet un sistema automático de conmutación por error en el que cada delegación deba elegir:

• Auto-Redelegación (se reparte entre los validadores activos de baja potencia; los más pequeños son los que más reciben), o
• Autodespido (iniciar la desvinculación normal de 21 días).
  Cada delegador también establece un Umbral de Cárcel (por ejemplo, de 7 a 90 días) para cuando se desencadena la acción.

---

¿Por qué ahora?

• Apuesta ociosa = 0% de recompensas y menor seguridad real.
• Los monederos abandonados pueden atrapar estacas durante meses/años.
• Esto hace que el conjunto se autocure e impulsa la apuesta por validadores más pequeños y fiables.

---

Lo que se propone (primero para TESTNET)

1. Ajustes por delegado (almacenados en la cadena):

• Acción de conmutación por error (obligatoria): Reasignar o Desasignar
• Umbral de encarcelamiento (obligatorio): N días consecutivos de cárcel (entre el mínimo/máximo fijado por el gobierno)

2. Disparador:

• Tombstone: conmutación por error inmediata
• Jailed ≥ umbral: conmutación por error en el siguiente bloque

3. Regla de redelegación: elige a los K validadores activos con menor poder de voto que cumplan los filtros (tiempo de actividad ≥ 99% en los últimos 10.000 bloques; comisión ≤ 10%; no han sido recortados recientemente), asigna por poder de voto inverso (los más pequeños reciben proporcionalmente más).
4. Alcance: Esta propuesta sólo autoriza el diseño + el despliegue de la red de pruebas. La mainnet requeriría una votación de actualización separada tras los resultados.

Parámetros iniciales de la red de pruebas (sintonizables):

• min_threshold_days = 7, max_threshold_days = 90
• auto_failover_k = 4
• auto_failover_min_uptime = 99%
• auto_failover_max_commission = 10%

---

Beneficios

• No hay apuesta ociosa: cada delegación redelega o desdelega tras el umbral elegido.
• Descentralización: flujo hacia validadores activos más pequeños.
• Control del usuario: los delegados eligen cómo y cuándo.
• Seguridad: mayor participación activa efectiva.

---

Salvaguardas y anti-vuelta

• Umbral mínimo/máximo (por ejemplo, 7-90 días) para evitar el churn hiperreactivo.
• K se mantiene pequeño (por ejemplo, 4) para limitar la hinchazón del estado.
• Tapones de procesamiento por bloque para manejar con seguridad validadores muy grandes.
• Registros de eventos para que los exploradores/carpetas muestren exactamente qué ocurrió y por qué.

---

Lo que no es

• No es un cambio inmediato de la red principal.
• No custodia los fondos de los usuarios mediante un contrato.
• No obligar a todo el mundo a redelegarse-Unstake está igualmente disponible.

---

Preguntas abiertas para comentarios

1. ¿Mínimo/máximo preferido para el umbral de la cárcel? (por ejemplo, 7-90 frente a 14-60)
2. ¿Destinos K = 3, 4 ó 5?
3. Filtros: ventana de tiempo de actividad (¿está bien 10k bloques?) y tope de comisión (¿está bien 10%?)
4. Ponderación: ¿poder de voto inverso vs. simple cap-fill a la mediana?
5. ¿Hay alguna exclusión (por ejemplo, abuso de gobierno reciente) que los validadores quieran que se tenga en cuenta?

---

Calendario propuesto

• Semana 0-2: Comentarios de la comunidad sobre los parámetros y el diseño
• Semana 3-6: Implementar cambios en el módulo de estacas, ganchos de monedero/CLI
• Semana 7-10: Testnet público: ejecutar escenarios (tombstone, long jail, mass failover)
• Semana 11-12: Publicar informe + parámetros recomendados
• Después: Propuesta de actualización del software de mainnet por separado si la comunidad está satisfecha

---

Pregunta a

Compártelo, por favor:

• Si apoyas el desarrollo de testnet de conmutación por error obligatoria (elige Redelegate o Unstake)
• Tus parámetros preferidos (rango de umbral, K, filtros, ponderación)
• Alguna señal de alarma que debamos abordar antes de codificar

Si hay un amplio apoyo, abriré un borrador de PR y me coordinaré con los desarrolladores del monedero para una IU básica (desplegable para la acción + umbral numérico al apostar).

Gracias por leer, ¡esperamos tus comentarios!