12190 | Automatisches Failover von langfristig inaktiven Validatoren – Delegator-Auswahl (Testnet-Entwicklung)

Quelle von:

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

Entwickeln/testen Sie (testnet) eine automatische Ausfallsicherung für LUNC: Gefängnisschwelle pro Delegation (7-90d) + erforderliche Aktion – Delegieren an Aktive mit der geringsten Macht oder Aufheben (21d). Tombstone wird sofort ausgelöst; langes Gefängnis löst den nächsten Block aus.

Wahl pro Bevollmächtigtem: Neu delegieren oder freigeben (Testnet-Entwicklungsgenehmigung)

TL;DR
Zu viele Einsätze liegen auf inaktiven (inhaftierten/versteinerten) Validatoren, die 0% verdienen und die Dezentralisierung schwächen.
Ich schlage vor, dass wir im Testnet ein automatisches Failover-System entwickeln und testen, bei dem jede Delegation wählen muss:

• Auto-Redelegate (Verteilung auf aktive Prüfer mit geringem Stromverbrauch; die kleinsten erhalten die meisten), oder
• Auto-Unstake (Start der normalen 21-tägigen Aufhebung der Bindung).
  Jeder Delegator legt auch einen Jail Threshold (z.B. 7-90 Tage) fest, ab dem die Aktion ausgelöst wird.

---

Warum gerade jetzt?

• Untätiger Einsatz = 0% Belohnungen und geringere reale Sicherheit.
• Verlassene Geldbörsen können den Einsatz für Monate/Jahre festhalten.
• Dadurch wird das Set selbstheilend und der Anteil an kleineren, zuverlässigen Prüfern wird erhöht.

---

Was vorgeschlagen wird (zunächst für TESTNET)

1. Einstellungen pro Delegator (in der Kette gespeichert):

• Failover-Aktion (erforderlich): Neu delegieren oder Freigabe
• Gefängnisschwelle (erforderlich): N aufeinanderfolgende Tage im Gefängnis (zwischen dem von der Regierung festgelegten Minimum/Maximum)

2. Auslöser:

• Tombstone: sofortige Ausfallsicherung
• Jailed ≥ Schwellenwert: Failover beim nächsten Block

3. Redelegate-Regel: Wählen Sie K aktive Prüfer mit der geringsten Stimmkraft aus, die die Filter erfüllen (Betriebszeit ≥ 99% über die letzten 10k Blöcke; Provision ≤ 10%; nicht kürzlich gesenkt), und verteilen Sie sie nach umgekehrter Stimmkraft (die kleinsten erhalten proportional mehr).
4. Umfang: Dieser Vorschlag genehmigt nur die Einführung von Design + Testnet. Das Mainnet würde nach den Ergebnissen eine separate Upgrade-Abstimmung erfordern.

Ursprüngliche Testnetz-Parameter (abstimmbar):

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

---

Vorteile

• Kein ungenutzter Einsatz: Jede Delegation gibt nach dem gewählten Schwellenwert entweder einen neuen Einsatz ab oder hebt den Einsatz auf.
• Dezentralisierung: Fluss zu kleineren aktiven Prüfern.
• Benutzerkontrolle: Die Delegierten wählen sowohl das Wie als auch das Wann.
• Sicherheit: höherer effektiver aktiver Einsatz.

---

Sicherheitsvorkehrungen & Anti-Abwanderung

• Schwellenwert (z.B. 7-90 Tage), um eine übermäßige Abwanderung zu vermeiden.
• K wird klein gehalten (z.B. 4), um die Aufblähung des Zustands zu begrenzen.
• Pro-Block-Verarbeitungs-Caps, um sehr große Validatoren sicher zu handhaben.
• Ereignisprotokolle, damit Explorer/Handys genau zeigen, was passiert ist und warum.

---

Was dies nicht ist

• Keine unmittelbare Änderung des Mainnets.
• Keine Verwahrung von Nutzergeldern durch einen Vertrag.
• Nicht jeder ist gezwungen, seine Stimme abzugeben – Unstake ist gleichermaßen verfügbar.

---

Offene Fragen für Feedback

1. Bevorzugtes Minimum/Maximum für die Knastschwelle? (z.B. 7-90 vs. 14-60)
2. K Ziele = 3, 4 oder 5?
3. Filter: Betriebszeitfenster (10k Blöcke OK?) und Provisionsobergrenze (10% OK?)
4. Gewichtung: inverse Stimmkraft vs. einfaches Cap-Fill zum Median?
5. Gibt es Ausnahmen (z.B. Missbrauch der Governance in jüngster Zeit), die die Prüfer berücksichtigen möchten?

---

Vorgeschlagener Zeitplan

• Woche 0-2: Feedback der Gemeinschaft zu Parametern und Design
• Woche 3-6: Implementierung von Änderungen am Staking-Modul, Wallet/CLI-Hooks
• Woche 7-10: Öffentliches Testnetz: Ausführen von Szenarien (Tombstone, Long Jail, Massenfailover)
• Woche 11-12: Bericht veröffentlichen + empfohlene Parameter
• Danach: Separater Vorschlag für ein Mainnet-Software-Upgrade, wenn die Community zufrieden ist

---

Fragen Sie

Bitte teilen Sie es:

• Ob Sie die Entwicklung eines Testnetzes mit obligatorischem Failover unterstützen (wählen Sie Redelegate oder Unstake)
• Ihre bevorzugten Parameter (Schwellenwertbereich, K, Filter, Gewichtung)
• Gibt es rote Fahnen, die wir vor der Codierung beachten sollten?

Wenn es breite Unterstützung gibt, werde ich einen PR-Entwurf öffnen und mich mit den Entwicklern der Brieftasche abstimmen, um eine grundlegende Benutzeroberfläche zu schaffen (Dropdown für die Aktion + numerischer Schwellenwert beim Einsatz).

Danke fürs Lesen – ich freue mich auf Ihr Feedback!