การกำกับดูแลใน 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. การตรวจสอบจากชุมชน – โค้ดจะถูกตรวจสอบ อภิปราย และทดสอบ การตรวจสอบ CertiK สำหรับการเปลี่ยนแปลงที่สำคัญ
3. Release – มีการสร้างไบนารีเวอร์ชันใหม่ gonkad
4. On-chain proposal – มีการสร้างข้อเสนอการอัปเดตในเครือข่ายพร้อมคำอธิบายการเปลี่ยนแปลง
5. ฝาก + โหวต – โฮสต์ฝาก (เกณฑ์การเปิดใช้งาน) และโหวตในช่วงเวลาการโหวต
6. Cosmovisor – เมื่อได้รับการอนุมัติ Cosmovisor จะอัปเดตโหนดโดยอัตโนมัติที่ความสูงของบล็อกที่กำหนด

ตั้งแต่เดือนมกราคมถึงพฤษภาคม 2026 เครือข่ายได้ผ่าน การลงคะแนนที่ประสบความสำเร็จมากกว่า 13 ครั้ง – ตั้งแต่เวอร์ชัน v0.2.2 ถึง v0.2.13 ข้อเสนอทั้งหมดได้รับการอนุมัติ ลำดับเหตุการณ์ของการอัปเกรดที่สำคัญ:

• v0.2.11 (มีนาคม 2026, proposal #31) – 673,699 เสียง “เห็นด้วย” โดยไม่มีเสียง “ไม่เห็นด้วย” แนะนำ subnet inference – กลไกการคำนวณ off-chain ผ่าน subnets ซึ่งสัญญาว่าจะเพิ่มปริมาณงานได้ 100 เท่า
• v0.2.13 (พฤษภาคม 2026, proposal #54) – ได้รับการอนุมัติเมื่อ 21 พฤษภาคม 2026 (62.8% “เห็นด้วย”, ผู้เข้าร่วม 39.9% ที่ quorum 33.4%) เปิดใช้งานที่บล็อก 4267300 เพิ่ม MiniMax-M2.7 เป็นโมเดลที่สามในเครือข่าย เปิดใช้งานการเชื่อมต่อ Ethereum bridge และลด quorum เหลือ 0.25

ตัวเลือกการโหวต:

• ใช่ – สนับสนุนการอัปเดต
• ไม่ – ไม่เห็นด้วยกับการอัปเดต
• ไม่เห็นด้วยและคัดค้าน – คัดค้านอย่างรุนแรง หากมีเสียงมากกว่า 33% ข้อเสนอจะถูกปฏิเสธและเงินฝากจะถูกริบ
• งดออกเสียง – งดออกเสียง แต่มีส่วนร่วมใน quorum

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

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

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

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

GiP ไม่ได้มีผลผูกพัน – ไม่ได้ обязывают ทีมงานต้องดำเนินการ แต่ก็สร้างความเห็นชอบร่วมกันของชุมชนและกำหนดทิศทางสำหรับข้อเสนอ on-chain ในอนาคต อันที่จริง GiP คือ “pre-governance”: การอภิปรายก่อนการโหวต.

GiP ที่สำคัญ:

• #800 Multi-Model PoC — รองรับโมเดล AI หลายตัวพร้อมกัน ปัจจุบันเครือข่ายทำงานร่วมกับ Qwen3-235B และ Kimi K2.6 (ผ่าน DevShards ตั้งแต่เดือนพฤษภาคม 2026) MiniMax-M2.7 จะถูกเพิ่มใน v0.2.13 GiP อธิบายสถาปัตยกรรมสำหรับการทำงานพร้อมกันของโมเดลต่างๆ ด้วย Proof of Useful Work แยกกัน.
• #801 Inference Scaling — สถาปัตยกรรม Subnet สำหรับการขยายขนาด ส่วนหนึ่งของ GiP นี้ได้ถูกนำไปใช้แล้วใน v0.2.11 (subnet inferenced).
• #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) — ได้รับการดำเนินการแล้ว: Kimi K2.6 ทำงานใน DevShards แล้วตั้งแต่เดือนพฤษภาคม 2026, MiniMax-M2.7 จะถูกเพิ่มใน v0.2.13 (proposal #54) ผู้สมัครถัดไปคือโมเดลฝังตัวสำหรับ RAG: ซึ่งจะเปิด Gonka ให้กับแอปพลิเคชันประเภทใหม่ (เครื่องมือค้นหา, ฐานความรู้ขององค์กร, แชทบอทที่มีหน่วยความจำ)

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

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

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