12190 | Basculement automatique des validateurs inactifs à long terme – Choix du délégué (Testnet Development)

Source de :

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

Développer/tester (testnet) l’auto-failover pour LUNC : seuil d’emprisonnement par délégation (7-90d) + action requise-Redéléguer aux actifs les moins puissants ou Déprendre (21d). La pierre tombale se déclenche immédiatement ; la prison longue déclenche le bloc suivant.

Choix par délégué : Redelegate ou Unstake (Approbation du développement de Testnet)

TL;DR
Trop d’enjeux reposent sur des validateurs inactifs (emprisonnés/tombés) qui rapportent 0% et affaiblissent la décentralisation.
Je propose que nous développions et testions sur testnet un système de basculement automatique où chaque délégation doit choisir :

• Délégation automatique (diffusion aux validateurs actifs de faible puissance ; les plus petits obtiennent le plus), ou
• Auto-Unstake (démarrage du déblocage normal de 21 jours).
  Chaque délégant fixe également un seuil de détention (par exemple, 7-90 jours) pour le déclenchement de l’action.

---

Pourquoi maintenant ?

• Enjeu inactif = 0% de récompenses et une sécurité réelle plus faible.
• Les portefeuilles abandonnés peuvent rester bloqués pendant des mois ou des années.
• Cela permet à l’ensemble de s’auto-régénérer et incite les parties prenantes à se tourner vers des validateurs plus petits et plus fiables.

---

Ce qui est proposé (pour TESTNET d’abord)

1. Paramètres par délégué (stockés sur la chaîne) :

• Action de basculement (obligatoire) : Redelegate ou Unstake
• Seuil d’emprisonnement (obligatoire) : N jours d’emprisonnement consécutifs (entre le minimum et le maximum fixés par la gouvernance)

2. Déclencheur :

• Tombstone : basculement immédiat
• Seuil d’inactivité ≥ : basculement au bloc suivant

3. Règle de redélégation : choisissez K validateurs actifs ayant le plus faible pouvoir de vote et répondant aux filtres (temps de fonctionnement ≥ 99% sur les 10k derniers blocs ; commission ≤ 10% ; pas de réduction récente), attribuez-les en fonction de l’inverse du pouvoir de vote (les plus petits reçoivent proportionnellement plus).
4. Champ d’application : Cette proposition autorise uniquement la conception et le déploiement du réseau de test. Le réseau principal devra faire l’objet d’un vote de mise à niveau séparé après les résultats.

Paramètres initiaux du réseau de test (réglables) :

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

---

Avantages

• Pas d’enjeu inactif : chaque délégation se redélègue ou se désengage après le seuil choisi.
• Décentralisation : flux vers des validateurs actifs plus petits.
• Contrôle de l’utilisateur : les délégués choisissent quand et comment.
• Sécurité : participation active plus élevée.

---

Sauvegardes et anti-churn

• Seuil plancher/plafond (par exemple, 7 à 90 jours) pour éviter un désabonnement hyperréactif.
• K reste faible (par exemple, 4) pour limiter le gonflement de l’état.
• Les plafonds de traitement par bloc permettent de gérer en toute sécurité les validateurs de très grande taille.
• Les journaux d’événements permettent aux explorateurs et aux portefeuilles de savoir exactement ce qui s’est passé et pourquoi.

---

Ce qui n’est pas le cas

• Il ne s’agit pas d’une modification immédiate du réseau principal.
• Pas de garde de fonds d’utilisateurs par un contrat.
• Ne pas obliger tout le monde à redéléguer – l’enjeu est le même pour tous.

---

Questions ouvertes pour un retour d’information

1. Min/max préféré pour le seuil d’emprisonnement ? (par exemple, 7-90 vs. 14-60)
2. Destinations K = 3, 4 ou 5 ?
3. Filtres : fenêtre de temps de fonctionnement (10k blocs OK ?) et plafond de commission (10% OK ?)
4. Pondération : pouvoir de vote inverse ou simple remplissage de la médiane?
5. Les validateurs souhaitent-ils prendre en compte certaines exclusions (par exemple, abus récent de la gouvernance) ?

---

Calendrier proposé

• Semaine 0-2 : Retour d’information de la communauté sur les paramètres et la conception
• Semaine 3-6 : Mise en œuvre des modifications du module de jalonnement, des crochets wallet/CLI
• Semaine 7-10 : Réseau public de test: scénarios d’exécution (tombstone, long jail, mass failover)
• Semaine 11-12 : Publication du rapport + paramètres recommandés
• Après : Proposition séparée de mise à jour du logiciel du réseau principal si la communauté est satisfaite

---

Demandez

N’hésitez pas à partager :

• Si vous soutenez le développement du testnet pour le basculement obligatoire (choisissez Redelegate ou Unstake)
• Vos paramètres préférés (plage de seuils, K, filtres, pondération)
• Quels sont les signaux d’alerte à prendre en compte avant de coder ?

S’il y a un large soutien, j’ouvrirai un projet de PR et je me coordonnerai avec les développeurs du portefeuille pour une interface utilisateur de base (menu déroulant pour l’action + seuil numérique lors de la mise en jeu).

Merci de votre lecture – nous attendons avec impatience vos commentaires !