12190 | การสำรองข้อมูลอัตโนมัติจากตัวตรวจสอบที่ไม่ได้ใช้งานในระยะยาว — ตัวเลือกผู้มอบหมาย (การพัฒนา Testnet)

แหล่งที่มาจาก :

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

พัฒนา/ทดสอบ (testnet) การทำงานแบบ Failover อัตโนมัติสำหรับ LUNC: เกณฑ์เจลต่อหนึ่งการมอบหมาย (7–90 วัน) + การดำเนินการที่จำเป็น—มอบหมายใหม่ไปยังแอคทีฟที่มีกำลังต่ำที่สุด หรือยกเลิกการเดิมพัน (21 วัน) Tombstone จะทำงานทันที เจลระยะยาวจะทริกเกอร์บล็อกถัดไป

ตัวเลือกต่อผู้มอบหมาย: มอบหมายใหม่หรือยกเลิกการเดิมพัน (การอนุมัติการพัฒนา Testnet)

สรุปสั้นๆ
มีเดิมพันมากเกินไปกับ ผู้ตรวจสอบที่ไม่ได้ใช้งาน (ถูกจำคุก/ถูกฝัง) ที่ได้รับ 0% และทำให้การกระจายอำนาจอ่อนแอลง
ฉันเสนอให้เราพัฒนาและทดสอบระบบ เฟลโอเวอร์ อัตโนมัติ บนเทสต์เน็ต ซึ่ง ผู้แทนทุกคนจะต้องเลือก :

• การมอบหมายใหม่อัตโนมัติ (กระจายไปยังตัวตรวจสอบที่ใช้งานพลังงานต่ำ; เล็กที่สุดได้รับมากที่สุด) หรือ
• ยกเลิกการผูกมัดอัตโนมัติ (เริ่มการยกเลิกพันธะปกติ 21 วัน)
  ผู้มอบหมายแต่ละรายยังกำหนด เกณฑ์การจำคุก (เช่น 7–90 วัน) สำหรับเวลาที่การดำเนินการเกิดขึ้น

---

ทำไมต้องตอนนี้?

• เดิมพันแบบไม่ได้ใช้งาน = รางวัล 0% และ ความปลอดภัยที่แท้จริงลดลง
• กระเป๋าสตางค์ที่ถูกละทิ้ง อาจดักจับเงินไว้ได้นานหลายเดือนหรือหลายปี
• การกระทำนี้ทำให้ชุด การรักษาตัวเอง และผลักดันการเดิมพันไปยัง ตัวตรวจสอบที่เล็กกว่าและเชื่อถือได้

---

สิ่งที่กำลังได้รับการเสนอ (สำหรับ TESTNET ก่อน)

1. การตั้งค่าต่อผู้มอบหมาย (จัดเก็บบนเชน):

• การดำเนินการล้มเหลว (จำเป็น): มอบหมายใหม่ หรือ ยกเลิกการเดิมพัน
• เกณฑ์การจำคุก (จำเป็น): N วันจำคุกติดต่อกัน (ระหว่างขั้นต่ำ/สูงสุดที่กำหนดโดยหน่วยงานกำกับดูแล)

2. สิ่งกระตุ้น:

• Tombstone: การสำรองข้อมูลทันที
• เกณฑ์การจำคุก ≥: ล้มเหลวที่บล็อกถัดไป

3. กฎการมอบหมายใหม่: เลือกผู้ตรวจสอบที่ใช้งานอยู่ซึ่งมีอำนาจการโหวตต่ำที่สุด K รายที่ตรงตามตัวกรอง (เวลาใช้งาน ≥ 99% ในบล็อก 10,000 ล่าสุด; คอมมิชชัน ≤ 10%; ไม่ได้ถูกตัดไปเมื่อเร็วๆ นี้) จัดสรรตาม อำนาจการโหวตแบบผกผัน (ผู้น้อยที่สุดจะได้รับมากกว่าตามสัดส่วน)
4. ขอบเขต: ข้อเสนอนี้ อนุญาตให้เฉพาะการออกแบบและการเปิดตัว Testnet เท่านั้น Mainnet จะต้องมี การโหวตอัปเกรดแยกต่างหาก หลังจากประกาศผล

พารามิเตอร์ทดสอบเน็ตเริ่มต้น (ปรับได้):

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

---

ประโยชน์

• ไม่มีการเดิมพันที่ไม่ได้ใช้งาน: การมอบหมายแต่ละครั้งจะมอบหมายใหม่หรือยกเลิกการเดิมพันหลังจากถึงเกณฑ์ที่เลือก
• การกระจายอำนาจ: การไหลไปสู่ผู้ตรวจสอบที่ใช้งานอยู่ขนาดเล็กกว่า
• การควบคุมของผู้ใช้: ผู้มอบหมายเลือกได้ทั้ง วิธี และ เวลา
• ความปลอดภัย: การเดิมพันที่มีประสิทธิภาพสูงกว่า

---

การป้องกันและป้องกันการเปลี่ยนแปลง

• กำหนดพื้น/เพดานขั้นต่ำ (เช่น 7–90 วัน) เพื่อหลีกเลี่ยงการเปลี่ยนแปลงที่ตอบสนองมากเกินไป
• K เก็บไว้ให้มีขนาดเล็ก (เช่น 4) เพื่อจำกัดการขยายตัวของรัฐ
• การประมวลผลแบบต่อบล็อก เพื่อจัดการกับตัวตรวจสอบขนาดใหญ่ได้อย่างปลอดภัย
• บันทึกเหตุการณ์ เพื่อให้ผู้สำรวจ/กระเป๋าเงินสามารถระบุได้ว่าเกิดอะไรขึ้นและเพราะเหตุใด

---

นี่ ไม่ใช่ อะไร

• ไม่ใช่การเปลี่ยนแปลงเมนเน็ตทันที
• ไม่ใช่การควบคุมเงินทุนของผู้ใช้ตามสัญญา
• ไม่บังคับให้ทุกคนมอบหมายงานใหม่ – Unstake มีให้ใช้เท่าเทียมกัน

---

คำถามเปิดสำหรับการตอบรับ

1. ค่าต่ำสุด/สูงสุด ที่ต้องการสำหรับเกณฑ์การจำคุก? (เช่น 7–90 เทียบกับ 14–60)
2. K จุดหมายปลายทาง = 3, 4 หรือ 5?
3. ตัวกรอง: หน้าต่างเวลาใช้งาน (บล็อก 10,000 โอเค?) และค่าคอมมิชชันสูงสุด (10% โอเค?)
4. การถ่วงน้ำหนัก: อำนาจการโหวตผกผัน กับ การเติมค่าแคปธรรมดาเป็นค่ามัธยฐาน ?
5. ผู้ตรวจสอบต้องการให้พิจารณาข้อยกเว้นใดๆ (เช่น การละเมิดการกำกับดูแลล่าสุด) หรือไม่

---

ไทม์ไลน์ที่เสนอ

• สัปดาห์ที่ 0–2: ข้อเสนอแนะจากชุมชนเกี่ยวกับพารามิเตอร์และการออกแบบ
• สัปดาห์ที่ 3–6: การนำการเปลี่ยนแปลงโมดูลการสเตกกิ้งมาใช้, การเชื่อมต่อกระเป๋าเงิน/CLI
• สัปดาห์ที่ 7–10: เครือข่ายทดสอบสาธารณะ : สถานการณ์จำลองการรัน (หลุมศพ, คุกยาว, การเฟลโอเวอร์จำนวนมาก)
• สัปดาห์ที่ 11–12: เผยแพร่รายงาน + พารามิเตอร์ที่แนะนำ
• หลังจากนี้: แยกข้อเสนอ การอัพเกรดซอฟต์แวร์เมนเน็ต หากชุมชนพอใจ

---

ถาม

กรุณาแบ่งปัน:

• ไม่ว่าคุณ จะสนับสนุนการพัฒนาเทสต์เน็ตเวิร์ก ของ Failover ที่จำเป็น (เลือก Redelegate หรือ Unstake)
• พารามิเตอร์ ที่คุณต้องการ (ช่วงเกณฑ์, K, ตัวกรอง, การถ่วงน้ำหนัก)
• สัญญาณเตือน ใดๆ ที่เราควรแก้ไขก่อนเขียนโค้ด

หากมีการสนับสนุนอย่างกว้างขวาง ฉันจะเปิดร่าง PR และประสานงานกับนักพัฒนากระเป๋าเงินสำหรับ UI ขั้นพื้นฐาน (เมนูแบบดรอปดาวน์สำหรับการดำเนินการ + เกณฑ์ตัวเลขเมื่อสเตก)

ขอบคุณที่อ่าน—รอคอยที่จะได้รับคำติชมจากคุณ!