การกำกับดูแลใน Gonka: เครือข่ายกระจายอำนาจได้รับการบริหารจัดการอย่างไร

การกำกับดูแลใน Gonka ทำงานบนสองระดับ แต่ละระดับมีความเร็วและขนาดของการตัดสินใจที่แตกต่างกัน

Operational Voting (นาที) — การตัดสินใจเชิงปฏิบัติการภายในเครือข่าย เมื่อเกิดข้อพิพาทเกี่ยวกับความถูกต้องของคำขอ inference หรือผลลัพธ์ของ PoC โฮสต์จะลงคะแนนผ่านโมดูล x/group ของ Cosmos SDK น้ำหนักการลงคะแนนจะถูกกำหนดโดยน้ำหนัก PoC – ยิ่งโหนดทำการประมวลผลมากเท่าไหร่ อิทธิพลของมันก็จะยิ่งมากขึ้นเท่านั้น การลงคะแนนดังกล่าวใช้เวลาไม่กี่นาทีและแก้ไขความขัดแย้งเฉพาะ: การ inference ถูกต้องหรือไม่ โหนดทำงานสำเร็จหรือไม่

Governance Voting (วัน) — การตัดสินใจเชิงกลยุทธ์เกี่ยวกับการพัฒนาโปรโตคอล การอัปเดตซอฟต์แวร์ การเปลี่ยนแปลงพารามิเตอร์เครือข่าย การเปิดใช้งานโมเดลใหม่ การจัดสรรเงินทุนจาก Community Pool – ทั้งหมดนี้จะถูกนำเสนอให้โฮสต์ทั้งหมดลงคะแนน ระยะเวลาการลงคะแนนตั้งแต่ไม่กี่วันถึงหนึ่งสัปดาห์ เพื่อให้ผู้เข้าร่วมทุกคนมีเวลาทำความเข้าใจกับข้อเสนอ

ความแตกต่างที่สำคัญจากโปรเจกต์คริปโตส่วนใหญ่: น้ำหนักการลงคะแนนถูกกำหนดโดย Proof of Compute ไม่ใช่การ Stake ใน Gonka ไม่สามารถ “ซื้อสิทธิ์ออกเสียง” ได้เพียงแค่ถือโทเค็นในกระเป๋าเงิน อิทธิพลเป็นสัดส่วนกับการมีส่วนร่วมในการประมวลผลจริง – GPU ที่ประมวลผลคำขอ AI และสร้างหลักฐานการทำงาน สิ่งนี้เชื่อมโยงการกำกับดูแลกับผู้ที่สนับสนุน สถาปัตยกรรมเครือข่าย จริงๆ ไม่ใช่ทุนเก็งกำไร

ในทางปฏิบัติ หมายความว่า: ผู้ประกอบการฟาร์ม 10 H100 มีสิทธิ์ออกเสียงมากกว่าผู้ประกอบการที่มีการ์ดเดียวถึง 10 เท่า – เพราะพวกเขาประมวลผลคำขอ inference มากกว่าถึง 10 เท่า ระบบนี้เป็นระบบที่ปรับสมดุลเอง: ผู้ที่ลงทุนในการทำงานของเครือข่ายมากเท่าไหร่ ก็ยิ่งมีอิทธิพลต่อการพัฒนาของมันมากเท่านั้น

การอัปเดตโปรโตคอล Gonka เป็นกระบวนการที่เป็นทางการตั้งแต่โค้ดจนถึงการเปิดใช้งานในเครือข่าย ทุกขั้นตอนมีความโปร่งใสและตรวจสอบได้

กระบวนการอัปเดต:

1. Pull Request ใน GitHub — ผู้พัฒนา (ทีม Gonka หรือผู้มีส่วนร่วม) สร้าง PR ใน repository gonka-ai/gonka
2. Review โดยชุมชน — โค้ดได้รับการตรวจสอบ อภิปราย ทดสอบ การตรวจสอบโดย CertiK สำหรับการเปลี่ยนแปลงที่สำคัญ
3. Release — มีการรวบรวมไบนารี gonkad เวอร์ชันใหม่
4. On-chain proposal — มีการสร้างข้อเสนอการอัปเดตในเครือข่ายพร้อมคำอธิบายการเปลี่ยนแปลง
5. Deposit + Vote — โฮสต์ทำการฝากเงิน (เกณฑ์การเปิดใช้งาน) และลงคะแนนในช่วง voting period
6. Cosmovisor — เมื่อได้รับการอนุมัติ Cosmovisor จะอัปเดตโหนดโดยอัตโนมัติที่ความสูงของบล็อกที่ระบุ

ตั้งแต่เดือนมกราคมถึงมีนาคม 2026 เครือข่ายได้ผ่าน การลงคะแนนที่ประสบความสำเร็จมากกว่า 11 ครั้ง — ตั้งแต่เวอร์ชัน v0.2.2 ถึง v0.2.11 ข้อเสนอทั้งหมดได้รับการอนุมัติ การลงคะแนนครั้งใหญ่ล่าสุด — proposal #31 (v0.2.11) — ได้รับ 673,699 เสียง “เห็นด้วย” และ 0 เสียง “ไม่เห็นด้วย” การอัปเดตนี้ได้นำ subnet inference มาใช้ — กลไกการประมวลผล off-chain ผ่าน subnets ซึ่งสัญญาว่าจะเพิ่มปริมาณงานได้ 100 เท่า

ตัวเลือกการลงคะแนน:

• Yes — สนับสนุนการอัปเดต
• No — ไม่เห็นด้วยกับการอัปเดต
• No with Veto — ไม่เห็นด้วยอย่างรุนแรง; หากมีมากกว่า 33% ของเสียง – ข้อเสนอจะถูกปฏิเสธและเงินฝากจะถูกริบ
• Abstain — งดออกเสียง แต่มีส่วนร่วมในการนับจำนวนผู้ผ่านการลงคะแนน

ประวัติการลงคะแนนทั้งหมดสามารถดูได้ที่ gonka.gg/network/proposals — สามารถดูข้อเสนอแต่ละรายการ ผลลัพธ์ และรายชื่อผู้ลงคะแนนได้

GiP — เป็นระบบการจัดรูปแบบความคิดสำหรับการพัฒนาโปรโตคอล Gonka ซึ่งเปิดตัวเมื่อวันที่ 24 กุมภาพันธ์ 2026 ผ่าน GitHub Discussions (issue #795)

รูปแบบของ GiP แต่ละรายการ:

• Motivation — ปัญหาที่ข้อเสนอแก้ไข
• Solution — คำอธิบายทางเทคนิคของวิธีแก้ไข
• Roadmap — แผนการดำเนินงานตามขั้นตอน
• Open Questions — คำถามที่ยังไม่ได้แก้ไขสำหรับการอภิปรายในชุมชน

GiP ไม่ binding — พวกเขาไม่ได้บังคับให้ทีมดำเนินการ แต่พวกเขาจะสร้างฉันทามติของชุมชนและกำหนดทิศทางสำหรับข้อเสนอ on-chain ในอนาคต อันที่จริง GiP คือ “การกำกับดูแลล่วงหน้า”: การอภิปรายก่อนการลงคะแนน

GiP ที่สำคัญ:

• #800 Multi-Model PoC — รองรับโมเดล AI หลายตัวพร้อมกัน ตอนนี้เครือข่ายทำงานกับ Qwen3-235B; GiP นี้อธิบายสถาปัตยกรรมสำหรับการทำงานพร้อมกันของโมเดลต่างๆ ด้วย Proof of Useful Work แยกต่างหาก
• #801 Inference Scaling — สถาปัตยกรรม subnet สำหรับการปรับขนาด บางส่วนของ GiP นี้ได้ถูกนำมาใช้แล้วใน v0.2.11 (subnet inference)
• #860 Quality Protocol — การกำหนดเส้นทางคำขอโดยพิจารณาคุณภาพของคำตอบ โหนดที่ให้ผลลัพธ์ที่ดีที่สุดจะได้รับปริมาณการใช้งานและรางวัลมากขึ้น

ผู้เข้าร่วมคนใดก็ได้สามารถสร้าง GiP ผ่าน GitHub Discussions จุดเริ่มต้นต่ำมาก — เพียงแค่มีบัญชี GitHub และเข้าใจปัญหา การอภิปรายอย่างกระตือรือร้นโดยมีทีม Gonka และโฮสต์เข้าร่วม แสดงให้เห็นว่าระบบกำลังทำงาน: ข้อเสนอได้รับการตอบรับ ปรับปรุง และกำลังดำเนินการสู่การนำไปใช้

Community Pool — แหล่งเงินทุนสำหรับการพัฒนาระบบนิเวศ Gonka ประมาณ 20% ของการออก Genesis (~200 ล้าน GNK) ถูกจัดสรรสำหรับทุนรางวัล, bounty และการสนับสนุนโครงการริเริ่มของชุมชน

Bounty สำหรับการมีส่วนร่วมในโค้ด — กลไกหลักในการจัดสรรเงินทุนจาก Community Pool นักพัฒนาจะได้รับรางวัลสำหรับ PR ใน repository gonka-ai/gonka: ตั้งแต่การแก้ไขข้อผิดพลาดไปจนถึงการนำคุณสมบัติใหม่มาใช้ ขนาดของ bounty ขึ้นอยู่กับความซับซ้อนและความสำคัญของการมีส่วนร่วม:

กลไกการอนุมัติ: bounties จะรวมอยู่ใน README ของข้อเสนอการอัปเกรด เมื่อโฮสต์ลงคะแนนเสียงสำหรับการอัปเดตโปรโตคอล พวกเขาจะอนุมัติรายการการชำระเงินสำหรับ PRs ที่รวมอยู่ในรุ่นนั้นด้วย ความโปร่งใสสมบูรณ์ — ทุกคนสามารถตรวจสอบได้ว่าจ่ายไปเท่าไหร่และเพื่ออะไร

นอกจาก bounties แล้ว Community Pool ยังสามารถให้เงินสนับสนุน: การพัฒนาเครื่องมือระบบนิเวศ, การตลาด, โครงการริเริ่มทางการศึกษา และทุนสำหรับการวิจัย รายละเอียดเพิ่มเติมเกี่ยวกับ การสร้างรายได้ผ่าน GitHub — ในบทความแยกต่างหาก

เครือข่ายที่อายุน้อยมีความเปราะบาง: มีโหนดน้อย, มีส่วนได้ส่วนเสียน้อย, การโจมตี 51% เป็นไปได้ทางทฤษฎี Gonka แก้ไขปัญหานี้ด้วยกลไกหลายอย่าง

Guardian System — โหนดที่ได้รับความเชื่อถือสามโหนด ซึ่งควบคุมโดยทีม Gonka โดยมีอำนาจการเห็นชอบรวม 34% Guardians ไม่สามารถบังคับการตัดสินใจได้ (34% < 67% สำหรับการยอมรับ) แต่สามารถบล็อกข้อเสนอที่เป็นอันตรายได้ (34% > 33% เกณฑ์การ Veto) สิ่งสำคัญคือ: Guardians จะถูกปิดการใช้งานโดยอัตโนมัติ เมื่อกำลังของเครือข่ายทั้งหมด (total_network_power) ถึง 10 ล้านหน่วย นี่ไม่ใช่สวิตช์แบบแมนนวล — การปิดการใช้งานถูกตั้งโปรแกรมไว้ในโปรโตคอล

ระบบหลักประกัน — โฮสต์จะต้องวางหลักประกันใน GNK เพื่อให้ได้รับน้ำหนักเต็มที่:

• Base Weight (20%) — น้ำหนักที่ไม่มีเงื่อนไข ซึ่งจะถูกมอบให้สำหรับการทำงานของโหนด
• Collateral-Eligible (80%) — น้ำหนักเพิ่มเติม ซึ่งจะได้รับก็ต่อเมื่อมีหลักประกันใน GNK เท่านั้น ขนาดของหลักประกันเป็นสัดส่วนกับพลังงานในการประมวลผล

การถูกลงโทษ/Slashing — การลงโทษสำหรับการละเมิด:

• 20% ของหลักประกัน — สำหรับ INVALID inference (โหนดให้ผลลัพธ์ที่ไม่ถูกต้อง)
• 10% ของหลักประกัน — สำหรับ downtime (โหนดไม่สามารถใช้งานได้เกินเกณฑ์ที่กำหนด)

Grace Period — 180 epochs (~6 เดือน) ซึ่งเป็นช่วงเวลาที่โฮสต์ใหม่สามารถทำงานได้โดยไม่ต้องมีหลักประกัน สิ่งนี้ช่วยลดอุปสรรคในการเข้า: สามารถเริ่มขุด สร้าง GNK ผ่านรางวัล และหลังจากนั้นจึงวางหลักประกัน หลังจากสิ้นสุด Grace Period โหนดที่ไม่มีหลักประกันจะได้รับเพียง 20% ของน้ำหนักที่มีศักยภาพเท่านั้น

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

การกำกับดูแลใน Gonka ไม่ใช่ระบบคงที่ แต่เป็นกระบวนการที่วิวัฒนาการ นี่คือทิศทางการพัฒนาที่สำคัญสำหรับปี 2026–2027

Multi-Model PoC (GiP #800) — รองรับโมเดลหลายตัวพร้อมกัน ผู้สมัครคนแรกคือ embedding-models สำหรับ RAG สิ่งนี้จะเปิด Gonka ให้กับแอปพลิเคชันประเภทใหม่ทั้งหมด: ระบบค้นหา, ฐานความรู้ขององค์กร, แชทบอทที่มีหน่วยความจำ

Inference Quality Protocol (GiP #860) — การกำหนดเส้นทางตามคุณภาพ ตอนนี้คำขอจะถูกกระจายตามความพร้อมใช้งานของโหนด; ในอนาคต — ตามคุณภาพของคำตอบ โหนดที่มีฮาร์ดแวร์ที่ดีกว่าและเสถียรภาพในการทำงานที่ดีกว่าจะได้รับความสำคัญ

On-chain governance migration (2026–2027) — การเปลี่ยนไปใช้โมดูล x/gov เต็มรูปแบบจาก Cosmos SDK สิ่งนี้จะให้: ประเภทข้อเสนอที่เป็นทางการ, การดำเนินการเปลี่ยนแปลงที่ได้รับอนุมัติโดยอัตโนมัติ, การรวมเข้ากับ IBC (Inter-Blockchain Communication) และความสามารถในการสร้างข้อเสนอการกำกับดูแลผ่านกระเป๋าเงินที่เข้ากันได้กับ Cosmos ใดๆ

สามารถติดตามการลงคะแนนและเข้าร่วมได้ที่ gonka.gg/network/proposals