Governance in Gonka: Wie ein dezentrales Netzwerk verwaltet wird

Die Governance in Gonka funktioniert auf zwei Ebenen, jede mit ihrer eigenen Geschwindigkeit und ihrem Umfang an Entscheidungen.

Operational Voting (Minuten) – Operative Entscheidungen innerhalb des Netzwerks. Wenn ein Streit über die Gültigkeit einer Inference-Anfrage oder eines PoC-Ergebnisses entsteht, stimmen die Hosts über das Modul x/group des Cosmos SDK ab. Das Stimmgewicht wird durch das PoC-Gewicht bestimmt – je mehr Berechnungen ein Node durchführt, desto größer ist sein Einfluss. Solche Abstimmungen dauern Minuten und lösen spezifische Konflikte: war die Inference korrekt, hat der Node seine Arbeit erledigt.

Governance Voting (Tage) – Strategische Entscheidungen zur Protokollentwicklung. Software-Updates, Änderung der Netzwerkparameter, Aktivierung neuer Modelle, Verteilung der Mittel des Community Pools – all dies wird allen Hosts zur Abstimmung vorgelegt. Die Abstimmungsperiode dauert von einigen Tagen bis zu einer Woche, damit alle Teilnehmer die Vorschläge prüfen können.

Der Hauptunterschied zu den meisten Krypto-Projekten: Das Stimmgewicht wird durch Proof of Compute und nicht durch Staking bestimmt. In Gonka kann man nicht „eine Stimme kaufen“, indem man einfach Token in einer Wallet ansammelt. Der Einfluss ist proportional zum tatsächlichen Rechenbeitrag – GPUs, die KI-Anfragen verarbeiten und Arbeitsnachweise generieren. Dies bindet die Governance an diejenigen, die die Netzwerkarchitektur tatsächlich unterstützen, und nicht an spekulatives Kapital.

In der Praxis bedeutet dies: Ein Farmbetreiber mit 10 H100 hat 10-mal mehr Stimmen als ein Betreiber mit einer Karte – weil er 10-mal mehr Inference-Anfragen verarbeitet. Das System ist selbstbalancierend: Diejenigen, die mehr in die Netzwerkarbeit investieren, beeinflussen deren Entwicklung stärker.

Die Aktualisierung des Gonka-Protokolls ist ein formalisierter Prozess vom Code bis zur Aktivierung im Netzwerk. Jeder Schritt ist transparent und überprüfbar.

Aktualisierungsprozess:

1. Pull Request auf GitHub – Entwickler (das Gonka-Team oder Mitwirkende) erstellen einen PR im Repository gonka-ai/gonka.
2. Überprüfung durch die Community – Der Code wird überprüft, diskutiert und getestet. CertiK-Audit für kritische Änderungen.
3. Freigabe – Eine neue Version des Binärprogramms gonkad wird erstellt.
4. On-Chain-Vorschlag – Ein Vorschlag zur Netzaktualisierung mit einer Beschreibung der Änderungen wird erstellt.
5. Einzahlung + Abstimmung – Hosts zahlen einen Betrag ein (Aktivierungsschwelle) und stimmen während des Abstimmungszeitraums ab.
6. Cosmovisor – Bei Genehmigung aktualisiert Cosmovisor die Nodes automatisch auf der angegebenen Blockhöhe.

Von Januar bis Mai 2026 hat das Netzwerk über 13 erfolgreiche Abstimmungen durchlaufen – von Version v0.2.2 bis v0.2.13. Alle Vorschläge wurden angenommen. Chronologie der wichtigsten Upgrades:

• v0.2.11 (März 2026, Vorschlag #31) – 673.699 Ja-Stimmen bei 0 Nein-Stimmen. Subnet Inference wurde eingeführt – ein Mechanismus für Off-Chain-Berechnungen über Subnetze, der eine 100-fache Steigerung des Durchsatzes verspricht.
• v0.2.13 (Mai 2026, Vorschlag #54) – angenommen am 21. Mai 2026 (62,8 % Ja-Stimmen, 39,9 % Beteiligung bei einem Quorum von 33,4 %), aktiviert auf Block 4267300. Fügte MiniMax-M2.7 als drittes Modell im Netzwerk hinzu, aktivierte die Ethereum-Bridge-Verkabelung und senkte das Quorum auf 0,25.

Optionen für die Abstimmung:

• Ja – Ich unterstütze die Aktualisierung.
• Nein – Ich bin gegen die Aktualisierung.
• Nein mit Veto – Ich bin kategorisch gegen; wenn mehr als 33 % der Stimmen – der Vorschlag wird abgelehnt und die Einzahlung verfällt.
• Enthalten – Ich enthalte mich, aber ich nehme am Quorum teil.

Die gesamte Abstimmungshistorie ist unter gonka.gg/network/proposals verfügbar – Sie können jeden Vorschlag, die Ergebnisse und die Liste der Wähler einsehen.

GiP ist ein System zur Formalisierung von Ideen zur Entwicklung des Gonka-Protokolls, das am 24. Februar 2026 über GitHub Discussions (Issue #795) gestartet wurde.

Format jedes GiP:

• Motivation — Welches Problem löst der Vorschlag.
• Solution — Technische Beschreibung der Lösung.
• Roadmap — Implementierungsplan in Phasen.
• Open Questions — Offene Fragen zur Diskussion durch die Community.

GiPs sind nicht binding – sie verpflichten das Team nicht zur Umsetzung. Sie bilden jedoch den Konsens der Community und geben die Richtung für zukünftige on-chain proposals vor. Tatsächlich ist GiP eine Art „Pre-Governance“: Diskussion vor der Abstimmung.

Wichtige GiPs:

• #800 Multi-Model PoC — Unterstützung mehrerer AI-Modelle gleichzeitig. Derzeit arbeitet das Netzwerk mit Kimi K2.6 und MiniMax M2.7. MiniMax-M2.7 wird in v0.2.13 hinzugefügt. Der GiP beschreibt die Architektur für den parallelen Betrieb verschiedener Modelle mit getrenntem Proof of Useful Work.
• #801 Inference Scaling — subnet architecture zur Skalierung. Ein Teil dieses GiP wurde bereits in v0.2.11 (subnet inference) implementiert.
• #860 Quality Protocol — Routing von Anfragen unter Berücksichtigung der Antwortqualität. Knoten, die die besten Ergebnisse liefern, erhalten mehr Traffic und Belohnungen.

Jeder Teilnehmer kann über GitHub Discussions einen GiP erstellen. Die Einstiegshürde ist minimal – man benötigt lediglich ein GitHub-Konto und ein Verständnis des Problems. Aktive Diskussionen unter Beteiligung des Gonka-Teams und der Hosts zeigen, dass das System funktioniert: Vorschläge erhalten Feedback, werden weiterentwickelt und schreiten in Richtung Implementierung voran.

Der Community Pool ist ein Fonds für die Entwicklung des Gonka-Ökosystems. Etwa 20 % der Genesis-Emission (~200 Millionen GNK) sind für Grants, Bounties und die Finanzierung von Community-Initiativen vorgesehen.

Bounties für Code-Beiträge – Der Hauptmechanismus zur Verteilung der Mittel des Community Pools. Entwickler erhalten Belohnungen für PRs im Repository gonka-ai/gonka: von der Fehlerbehebung bis zur Implementierung neuer Funktionen. Die Höhe der Bounty hängt von der Komplexität und Bedeutung des Beitrags ab:

Genehmigungsmechanismus: Bounties werden in die README zu den Upgrade-Vorschlägen aufgenommen. Wenn Hosts für ein Protokoll-Update stimmen, genehmigen sie gleichzeitig die Liste der Zahlungen für PRs, die in diesen Release aufgenommen wurden. Die Transparenz ist vollständig – jeder kann überprüfen, wofür und wie viel bezahlt wurde.

Neben Bounties kann der Community Pool Folgendes finanzieren: Entwicklung von Ökosystem-Tools, Marketing, Bildungsinitiativen und Forschungsstipendien. Mehr über das Verdienen über GitHub – in einem separaten Artikel.

Ein junges Netzwerk ist anfällig: wenige Nodes, wenig Staking, ein 51%-Angriff ist theoretisch möglich. Gonka löst dies mit mehreren Mechanismen.

Guardian System – Drei vertrauenswürdige Nodes, die vom Gonka-Team kontrolliert werden, mit einer Gesamt-Consensus-Power von 34 %. Guardians können keine Entscheidungen erzwingen (34 % < 67 % für die Annahme), aber sie können einen bösartigen Vorschlag blockieren (34 % > 33 % Veto-Schwelle). Wichtig: Guardians werden automatisch deaktiviert, wenn die gesamte Netzwerkleistung (total_network_power) 10 Millionen Einheiten erreicht. Dies ist kein manueller Schalter – die Deaktivierung ist im Protokoll programmiert.

Kollateralsystem – Hosts müssen eine Sicherheit in GNK hinterlegen, um das volle Gewicht zu erhalten:

• Base Weight (20 %) – Bedingungsloses Gewicht, das für die bloße Tatsache des Node-Betriebs gutgeschrieben wird.
• Collateral-Eligible (80 %) – Zusätzliches Gewicht, nur bei Vorhandensein einer Sicherheit in GNK verfügbar. Die Höhe der Sicherheit ist proportional zur Rechenleistung.

Slashing – Bestrafung für Verstöße:

• 20 % der Sicherheit – für INVALID Inference (Node lieferte ein falsches Ergebnis).
• 10 % der Sicherheit – für Downtime (Node ist über dem zulässigen Schwellenwert nicht verfügbar).

Grace Period – 180 Epochen (~6 Monate), in denen neue Hosts ohne Sicherheit arbeiten können. Dies senkt die Eintrittsbarriere: Man kann mit dem Mining beginnen, GNK durch Belohnungen verdienen und erst dann eine Sicherheit hinterlegen. Nach Ablauf der Grace Period erhält ein Node ohne Sicherheit nur 20 % des potenziellen Gewichts.

Alle diese Mechanismen sind in den Tokenomics von GNK beschrieben und verfolgen ein Ziel: das Netzwerk in der Frühphase zu schützen, ohne die Dezentralisierung langfristig zu opfern.

Governance in Gonka ist kein statisches System, sondern ein sich entwickelnder Prozess. Hier sind die wichtigsten Entwicklungsrichtungen für die Jahre 2026-2027.

Multi-Model PoC (GiP #800) – implementiert: Kimi K2.6 läuft bereits seit Mai 2026 in DevShards, MiniMax-M2.7 wird in v0.2.13 hinzugefügt (Vorschlag #54). Die nächsten Kandidaten sind Embedding-Modelle für RAG: Dies wird Gonka für eine neue Klasse von Anwendungen öffnen (Suchmaschinen, Unternehmensdatenbanken, Chatbots mit Gedächtnis).

Inference Quality Protocol (GiP #860) – Routing nach Qualität. Aktuell werden Anfragen basierend auf der Verfügbarkeit der Nodes verteilt; zukünftig basierend auf der Qualität der Antworten. Nodes mit besserer Hardware und stabilerem Betrieb erhalten Priorität.

On-chain governance migration (2026–2027) – Umstellung auf ein vollwertiges x/gov Modul aus dem Cosmos SDK. Dies ermöglicht: formalisierte proposal types, automatische Ausführung genehmigter Änderungen, Integration mit IBC (Inter-Blockchain Communication) und die Möglichkeit, governance proposals über jedes Cosmos-kompatible Wallet zu erstellen.

Abstimmungen verfolgen und teilnehmen können Sie unter gonka.gg/network/proposals.