Quản trị trong Gonka: cách một mạng lưới phi tập trung được quản lý

Quản trị trong Gonka hoạt động ở hai cấp độ, mỗi cấp có tốc độ và phạm vi quyết định riêng.

Operational Voting (vài phút) — các quyết định vận hành trong mạng. Khi xảy ra tranh chấp về tính hợp lệ của một yêu cầu inference hoặc kết quả PoC, các host bỏ phiếu qua module x/group của Cosmos SDK. Trọng số phiếu được xác định bởi PoC weight — node càng thực hiện nhiều tính toán thì ảnh hưởng càng lớn. Những cuộc bỏ phiếu này chỉ kéo dài vài phút và giải quyết các xung đột cụ thể: liệu inference có chính xác không, node có hoàn thành công việc của mình không.

Governance Voting (vài ngày) — các quyết định chiến lược về phát triển giao thức. Nâng cấp phần mềm, thay đổi tham số mạng, kích hoạt mô hình mới, phân bổ vốn từ Community Pool — tất cả đều được đưa ra để toàn bộ các host bỏ phiếu. Thời gian bỏ phiếu kéo dài từ vài ngày đến một tuần để mọi thành viên kịp tìm hiểu đề xuất.

Điểm khác biệt then chốt so với hầu hết các dự án crypto: trọng số phiếu được xác định bởi Proof of Compute, không phải staking. Tại Gonka, bạn không thể \"mua phiếu\" chỉ bằng cách tích lũy token trong ví. Ảnh hưởng tỷ lệ thuận với đóng góp tính toán thực tế — những GPU xử lý yêu cầu AI và tạo ra bằng chứng công việc. Kể từ bản cập nhật v0.2.16, chỉ công suất đã được xác nhận trong epoch trước mới được tính: host mới sẽ bỏ phiếu với trọng số bằng không trong epoch đầu tiên, và phần công suất tăng thêm sẽ bổ sung phiếu từ epoch tiếp theo. Điều này gắn chặt quản trị với những ai thực sự duy trì kiến trúc mạng, chứ không phải với dòng vốn đầu cơ.

Trên thực tế, điều này có nghĩa là: một nhà vận hành có hai máy chủ 8× H100 sẽ có số phiếu gần gấp đôi so với nhà vận hành chỉ có một máy chủ như vậy — bởi vì họ xử lý lượng yêu cầu inference gần gấp đôi. Hệ thống tự cân bằng: ai đóng góp nhiều hơn cho hoạt động của mạng thì có ảnh hưởng lớn hơn đến sự phát triển của mạng.

Nâng cấp giao thức Gonka là một quy trình được chuẩn hóa từ khâu viết mã đến khi kích hoạt trên mạng lưới. Mỗi bước đều minh bạch và có thể kiểm chứng.

Quy trình nâng cấp:

1. Pull Request trên GitHub — các nhà phát triển (đội ngũ Gonka hoặc cộng tác viên) tạo PR trong kho lưu trữ gonka-ai/gonka.
2. Cộng đồng review — mã nguồn được kiểm tra, thảo luận và thử nghiệm. CertiK audit cho các thay đổi quan trọng.
3. Release — phiên bản binary inferenced mới được build.
4. On-chain proposal — đề xuất nâng cấp được tạo trên mạng lưới kèm mô tả các thay đổi.
5. Deposit + Vote — các host nộp deposit (ngưỡng kích hoạt) và bỏ phiếu trong voting period.
6. Cosmovisor — khi được thông qua, Cosmovisor tự động cập nhật các node tại chiều cao block đã chỉ định.

Từ tháng 1 đến tháng 5 năm 2026, mạng lưới đã trải qua hơn 13 cuộc bỏ phiếu thành công — từ phiên bản v0.2.2 đến v0.2.13. Tất cả đề xuất đều được thông qua. Dòng thời gian các bản nâng cấp chính:

• v0.2.11 (tháng 3 năm 2026, proposal #31) — 673.699 phiếu «thuận» với 0 phiếu «chống». Đưa vào subnet inference — cơ chế tính toán off-chain qua các subnet, hứa hẹn tăng thông lượng gấp 100 lần.
• v0.2.13 (tháng 5 năm 2026, proposal #54) — được thông qua ngày 21 tháng 5 năm 2026 (62,8% «thuận», tỷ lệ tham gia 39,9% với kvorum 33,4%), kích hoạt tại block 4267300. Bổ sung MiniMax-M2.7 làm mô hình thứ ba trong mạng lưới, kích hoạt Ethereum bridge wiring và giảm kvorum xuống 0.25.

Các lựa chọn bỏ phiếu:

• Yes — tôi ủng hộ nâng cấp.
• No — phản đối nâng cấp.
• No with Veto — phản đối kịch liệt; nếu hơn 33% phiếu — đề xuất bị bác bỏ và deposit bị đốt.
• Abstain — tôi không bỏ phiếu thuận chống, nhưng vẫn tham gia kvorum.

Toàn bộ lịch sử bỏ phiếu có tại gonka.gg/network/proposals — bạn có thể xem từng đề xuất, kết quả và danh sách người đã bỏ phiếu.

GiP — là một hệ thống chính thức hóa các ý tưởng nhằm phát triển giao thức Gonka, được ra mắt vào ngày 24 tháng 2 năm 2026 thông qua GitHub Discussions (issue #795).

Định dạng của mỗi GiP:

• Motivation — vấn đề mà đề xuất giải quyết.
• Solution — mô tả kỹ thuật về giải pháp.
• Roadmap — kế hoạch triển khai theo từng giai đoạn.
• Open Questions — các câu hỏi chưa được giải quyết để cộng đồng thảo luận.

GiP không mang tính binding — chúng không bắt buộc đội ngũ phải thực hiện. Nhưng chúng hình thành sự đồng thuận của cộng đồng và đặt ra hướng đi cho các on-chain proposals trong tương lai. Thực tế, GiP là «pre-governance»: thảo luận trước khi bỏ phiếu.

Các GiP chính:

• #800 Multi-Model PoC — hỗ trợ đồng thời nhiều mô hình AI. Hiện tại, mạng lưới đang hoạt động với MiniMax M2.7 (được thêm vào v0.2.13), DeepSeek V4 Flash (proposal #94) và GLM-5.3 Flash (proposal #101). GiP mô tả kiến trúc để vận hành song song các mô hình khác nhau với Proof of Useful Work riêng biệt.
• #801 Inference Scaling — kiến trúc subnet để mở rộng quy mô. Một phần của GiP này đã được triển khai trong v0.2.11 (subnet inference).
• #860 Quality Protocol — định tuyến yêu cầu dựa trên chất lượng phản hồi. Các node cung cấp kết quả tốt hơn sẽ nhận được nhiều lưu lượng truy cập và phần thưởng hơn.

Bất kỳ người tham gia nào cũng có thể tạo GiP thông qua GitHub Discussions. Rào cản gia nhập rất thấp — chỉ cần có tài khoản GitHub và hiểu rõ vấn đề. Các cuộc thảo luận tích cực với sự tham gia của đội ngũ Gonka và các host cho thấy hệ thống đang hoạt động: các đề xuất nhận được phản hồi, được cải tiến và tiến tới triển khai.

Community Pool — quỹ phát triển hệ sinh thái Gonka. Khoảng 20% tổng số GNK phát hành ban đầu (~200 triệu GNK) được phân bổ cho các khoản tài trợ, tiền thưởng và tài trợ cho các sáng kiến cộng đồng.

Tiền thưởng cho đóng góp mã nguồn — cơ chế phân phối quỹ Community Pool chính. Các nhà phát triển nhận được phần thưởng cho các PR trong kho lưu trữ gonka-ai/gonka: từ sửa lỗi đến triển khai các tính năng mới. Kích thước tiền thưởng phụ thuộc vào độ phức tạp và tầm quan trọng của đóng góp:

Cơ chế phê duyệt: tiền thưởng được bao gồm trong README của các đề xuất nâng cấp. Khi các máy chủ bỏ phiếu cho việc nâng cấp giao thức, họ đồng thời phê duyệt danh sách các khoản thanh toán cho các PR đã được đưa vào bản phát hành đó. Tính minh bạch hoàn toàn — bất kỳ ai cũng có thể kiểm tra xem đã được thanh toán bao nhiêu và cho cái gì.

Ngoài tiền thưởng, Community Pool có thể tài trợ: phát triển các công cụ hệ sinh thái, tiếp thị, các sáng kiến giáo dục và tài trợ nghiên cứu. Đọc thêm về việc kiếm tiền thông qua GitHub — trong một bài viết riêng.

Một mạng lưới non trẻ dễ bị tấn công: ít nút, ít stake, tấn công 51% về mặt lý thuyết có thể xảy ra. Gonka giải quyết điều này bằng một số cơ chế.

Hệ thống giám hộ — ba nút đáng tin cậy, được kiểm soát bởi đội ngũ Gonka, với tổng cộng 34% sức mạnh đồng thuận. Các giám hộ không thể áp đặt các quyết định (34% < 67% để thông qua), nhưng có thể chặn một đề xuất độc hại (34% > 33% ngưỡng phủ quyết). Điều quan trọng: Các giám hộ tự động bị vô hiệu hóa khi tổng sức mạnh mạng (total_network_power) đạt 10 triệu đơn vị. Đây không phải là công tắc thủ công — việc vô hiệu hóa được lập trình trong giao thức.

Hệ thống thế chấp — các máy chủ phải gửi tiền thế chấp bằng GNK để có được trọng số đầy đủ:

• Trọng số cơ bản (20%) — trọng số vô điều kiện, được tính cho chính việc hoạt động của một nút.
• Đủ điều kiện thế chấp (80%) — trọng số bổ sung, chỉ có sẵn khi có tiền thế chấp bằng GNK. Kích thước tiền thế chấp tỷ lệ thuận với sức mạnh tính toán.

Xử phạt — phạt cho các vi phạm:

• 20% tiền thế chấp — đối với suy luận KHÔNG HỢP LỆ (nút đưa ra kết quả không chính xác).
• 10% tiền thế chấp — đối với thời gian ngừng hoạt động (nút không khả dụng vượt quá ngưỡng cho phép).

Thời gian ân hạn — 180 kỷ nguyên (~6 tháng), trong thời gian đó các máy chủ mới có thể hoạt động mà không cần thế chấp. Điều này làm giảm rào cản gia nhập: bạn có thể bắt đầu khai thác, kiếm GNK thông qua phần thưởng và sau đó mới gửi tiền thế chấp. Sau khi kết thúc Thời gian ân hạn, một nút không có thế chấp chỉ nhận được 20% trọng số tiềm năng.

Tất cả các cơ chế này được mô tả trong tokenomics của GNK và hướng tới một mục tiêu: bảo vệ mạng lưới trong giai đoạn đầu mà không làm mất đi tính phi tập trung về lâu dài.

Governance trong Gonka không phải là một hệ thống tĩnh mà là một quá trình tiến hóa. Dưới đây là các hướng phát triển chính cho giai đoạn 2026–2027.

Multi-Model PoC (GiP #800) — đã triển khai: Kimi K2.6 là mô hình đầu tiên xuất hiện qua DevShards vào tháng 5 năm 2026 (sau đó đã được loại bỏ khỏi mạng), MiniMax-M2.7 được thêm vào trong v0.2.13 (proposal #54), DeepSeek V4 Flash được kết nối vào tháng 8 năm 2026 (proposal #94), và GLM-5.3 Flash vào tháng 9 năm 2026 (proposal #101). Các ứng cử viên tiếp theo là các mô hình embedding cho RAG: điều này sẽ mở ra Gonka cho một lớp ứng dụng mới (công cụ tìm kiếm, cơ sở tri thức doanh nghiệp, chatbot có bộ nhớ).

Inference Quality Protocol (GiP #860) — định tuyến dựa trên chất lượng. Hiện tại, các yêu cầu được phân phối theo tính khả dụng của node; trong tương lai — sẽ dựa trên chất lượng phản hồi. Các node có phần cứng tốt hơn và hoạt động ổn định hơn sẽ được ưu tiên.

On-chain governance migration (2026–2027) — chuyển đổi sang module x/gov hoàn chỉnh từ Cosmos SDK. Điều này sẽ mang lại: các loại proposal chính thức, tự động thực thi các thay đổi đã được phê duyệt, tích hợp với IBC (Inter-Blockchain Communication) và khả năng tạo các governance proposals thông qua bất kỳ ví tương thích Cosmos nào.

Bạn có thể theo dõi các cuộc bỏ phiếu và tham gia tại gonka.gg/network/proposals.