12190 | Failover automatico dei validatori inattivi da lungo tempo – Scelta del delegatore (Sviluppo Testnet)

Fonte da:

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

Sviluppare/testare (testnet) l’auto-failover per LUNC: soglia di jail per delega (7-90d) + azione richiesta – Delega agli attivi con potere più basso o Unstake (21d). La pietra tombale si attiva immediatamente; la prigione lunga attiva il blocco successivo.

Scelta per delegante: Ridelegare o togliere la delega (Approvazione dello sviluppo di Testnet)

TL;DR
Troppa posta in gioco si trova su validatori inattivi (incarcerati/tombolati) che guadagnano lo 0% e indeboliscono la decentralizzazione.
Propongo di sviluppare e testare su testnet un sistema di failover automatico in cui ogni delegazione deve scegliere:

• Auto-Redelegate (diffusione ai validatori attivi a basso consumo; i più piccoli ottengono la maggior parte), oppure
• Auto-Unstake (avvia il normale vincolo di 21 giorni).
  Ogni delegante imposta anche una soglia di cauzione (ad esempio, 7-90 giorni) per l’attivazione dell’azione.

---

Perché ora?

• Puntate inattive = 0% di premi e minore sicurezza reale.
• I portafogli abbandonati possono rimanere bloccati per mesi/anni.
• Questo rende l’insieme autorigenerante e spinge a puntare su validatori più piccoli e affidabili.

---

Cosa viene proposto (prima per TESTNET)

1. Impostazioni per delegatore (memorizzate sulla catena):

• Azione di Failover (richiesta): Ridelegare o Disimpegnare
• Soglia di carcere (richiesto): N giorni consecutivi di carcere (tra il minimo e il massimo stabiliti dalla governance)

2. Innesco:

• Tombstone: failover immediato
• Soglia ≥ in carcere: failover al blocco successivo

3. Regola di rielegazione: scegliere i K validatori attivi con potere di voto più basso che soddisfano i filtri (uptime ≥ 99% negli ultimi 10k blocchi; commissione ≤ 10%; non tagliata di recente), assegnare in base all’inverso del potere di voto (i più piccoli ricevono proporzionalmente di più).
4. Ambito di applicazione: Questa proposta autorizza solo il progetto e il rollout della rete di prova. La rete principale richiederà una votazione separata per l’aggiornamento dopo i risultati.

Parametri iniziali della rete di test (regolabili):

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

---

Vantaggi

• Nessuna puntata a vuoto: ogni delegazione si rielegge o si dissocia dopo la soglia scelta.
• Decentralizzazione: flusso verso validatori attivi più piccoli.
• Controllo dell’utente: i delegati scelgono come e quando.
• Sicurezza: un maggior numero di punti attivi effettivi.

---

Salvaguardie e anti-cambio

• Soglia minima o massima (ad esempio, 7-90 giorni) per evitare un churn iper-reattivo.
• K mantenuto piccolo (ad esempio, 4) per limitare il gonfiore dello stato.
• I tappi di elaborazione per-blocco per gestire in modo sicuro validatori molto grandi.
• Registri degli eventi in modo che gli esploratori/wallet mostrino esattamente cosa è successo e perché.

---

Cosa non è

• Non è un cambiamento immediato della mainnet.
• Non la custodia dei fondi degli utenti tramite un contratto.
• Non obbligare tutti a ridelegare-Unstake è ugualmente disponibile.

---

Domande aperte per un feedback

1. Preferisci un minimo/massimo per la soglia del carcere? (ad esempio, 7-90 vs. 14-60)
2. Destinazioni K = 3, 4 o 5?
3. Filtri: finestra di uptime (10k blocchi OK?) e tetto massimo di commissioni (10% OK?)
4. Ponderazione: potere di voto inverso vs. semplice riempimento della mediana?
5. Ci sono esclusioni (ad esempio, abuso recente di governance) che i validatori vogliono prendere in considerazione?

---

Tempistica proposta

• Settimana 0-2: feedback della comunità su parametri e design
• Settimana 3-6: implementazione delle modifiche al modulo di staking, ganci per il portafoglio/CLI
• Settimana 7-10: Testnet pubblica: esecuzione di scenari (tombstone, long jail, mass failover)
• Settimana 11-12: Pubblicazione del rapporto + parametri consigliati
• Dopo: Proposta di aggiornamento del software della mainnet separata se la comunità è soddisfatta

---

Chiedi

Per favore, condividi:

• Se supporta lo sviluppo di testnet di failover obbligatorio (scegli Redelegate o Unstake)
• I tuoi parametri preferiti (intervallo di soglia, K, filtri, ponderazione)
• Ci sono segnali di allarme che dovremmo affrontare prima della codifica?

Se c’è un ampio sostegno, aprirò una bozza di PR e mi coordinerò con gli sviluppatori di portafogli per un’interfaccia utente di base (menu a tendina per le azioni + soglia numerica per le puntate).

Grazie per aver letto… non vedo l’ora di ricevere il tuo feedback!