Governance in Gonka: Wie ein dezentrales Netzwerk verwaltet wird

Die Governance in Gonka läuft auf zwei Ebenen, jede mit eigener Geschwindigkeit und eigenem Entscheidungsumfang.

Operational Voting (Minuten) — operative Entscheidungen innerhalb des Netzwerks. Wenn ein Streit über die Validität einer Inference-Anfrage oder eines PoC-Ergebnisses entsteht, stimmen die Hosts über das x/group-Modul des Cosmos SDK ab. Das Stimmgewicht wird durch das PoC weight bestimmt — je mehr Berechnungen eine Node ausführt, desto größer ihr Einfluss. Solche Abstimmungen dauern Minuten und lösen konkrete Konflikte: War die Inference korrekt, hat die Node ihre Arbeit erledigt.

Governance Voting (Tage) — strategische Entscheidungen über die Weiterentwicklung des Protokolls. Software-Updates, Änderung von Netzwerkparametern, Aktivierung neuer Modelle, Verteilung der Mittel des Community Pool — all das wird allen Hosts zur Abstimmung vorgelegt. Die Abstimmungsphase dauert von einigen Tagen bis zu einer Woche, damit alle Teilnehmer Zeit haben, sich mit dem Vorschlag vertraut zu machen.

Der entscheidende Unterschied zu den meisten Krypto-Projekten: Das Stimmgewicht wird durch Proof of Compute bestimmt, nicht durch Staking. Bei Gonka kann man sich keine Stimme „kaufen“, indem man einfach Token in der Wallet anhäuft. Der Einfluss ist proportional zum tatsächlichen Rechenbeitrag — den GPUs, die AI-Anfragen verarbeiten und Proofs of Work generieren. Seit dem Update v0.2.16 zählt die in der vorherigen Epoche bestätigte Leistung: Ein neuer Host stimmt in seiner ersten Epoche mit null Gewicht ab, und Leistungszuwächse bringen ab der nächsten Epoche zusätzliche Stimmen. Das bindet die Governance an diejenigen, die tatsächlich die Netzwerkarchitektur tragen, und nicht an spekulatives Kapital.

In der Praxis bedeutet das: Ein Betreiber mit zwei Servern à 8× H100 hat ungefähr doppelt so viele Stimmen wie ein Betreiber mit einem solchen Server — denn er verarbeitet ungefähr doppelt so viele Inference-Anfragen. Das System balanciert sich selbst: Wer mehr in den Betrieb des Netzwerks investiert, hat mehr Einfluss auf seine Entwicklung.

Ein Gonka-Protokoll-Upgrade ist ein formalisierter Prozess – vom Code bis zur Aktivierung im Netzwerk. Jeder Schritt ist transparent und nachprüfbar.

Der Upgrade-Prozess:

1. Pull Request auf GitHub – Entwickler (das Gonka-Team oder Contributors) erstellen einen PR im Repository gonka-ai/gonka.
2. Community-Review – der Code wird geprüft, diskutiert und getestet. Bei kritischen Änderungen erfolgt ein CertiK-Audit.
3. Release – eine neue Version des inferenced-Binaries wird gebaut.
4. On-Chain-Proposal – im Netzwerk wird ein Upgrade-Vorschlag mit Beschreibung der Änderungen erstellt.
5. Deposit + Vote – Hosts hinterlegen ein Deposit (Aktivierungsschwelle) und stimmen während der Voting Period ab.
6. Cosmovisor – bei Zustimmung 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. Die Chronologie der wichtigsten Upgrades:

• v0.2.11 (März 2026, Proposal #31) – 673.699 Ja-Stimmen bei 0 Gegenstimmen. Eingeführt wurde Subnet Inference – ein Mechanismus für Off-Chain-Berechnungen über Subnets, der einen 100-fachen Anstieg des Durchsatzes verspricht.
• v0.2.13 (Mai 2026, Proposal #54) – angenommen am 21. Mai 2026 (62,8 % Ja, Wahlbeteiligung 39,9 % bei einem Quorum von 33,4 %), aktiviert auf Block 4267300. Fügte MiniMax-M2.7 als drittes Modell im Netzwerk hinzu, aktivierte das Ethereum-Bridge-Wiring und senkte das Quorum auf 0.25.

Stimmoptionen:

• Yes – ich unterstütze das Upgrade.
• No – ich bin gegen das Upgrade.
• No with Veto – ich bin kategorisch dagegen; bei mehr als 33 % der Stimmen wird der Vorschlag abgelehnt und das Deposit verbrannt.
• Abstain – ich enthalte mich, zähle aber fürs Quorum.

Die gesamte Abstimmungshistorie ist unter gonka.gg/network/proposals verfügbar – dort lassen sich jeder Vorschlag, die Ergebnisse und die Liste der Abstimmenden 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 der Vorschlag löst.
• Solution — technische Beschreibung der Lösung.
• Roadmap — Implementierungsplan nach Phasen.
• Open Questions — offene Fragen zur Diskussion durch die Community.

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

Wichtige GiPs:

• #800 Multi-Model PoC — Unterstützung mehrerer KI-Modelle gleichzeitig. Derzeit arbeitet das Netzwerk mit MiniMax M2.7 (hinzugefügt in v0.2.13), DeepSeek V4 Flash (proposal #94) und GLM-5.3 Flash (proposal #101). 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 bessere Ergebnisse liefern, erhalten mehr Traffic und Belohnungen.

Jeder Teilnehmer kann ein GiP über GitHub Discussions erstellen. Die Eintrittsschwelle ist minimal — man benötigt nur 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 verfeinert und bewegen sich in Richtung Umsetzung.

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 bei Gonka ist kein statisches System, sondern ein sich entwickelnder Prozess. Hier sind die wichtigsten Entwicklungsrichtungen für 2026–2027.

Multi-Model PoC (GiP #800) — implementiert: Die erste war im Mai 2026 über DevShards Kimi K2.6 (später aus dem Netzwerk entfernt), MiniMax-M2.7 wurde in v0.2.13 (proposal #54) hinzugefügt, DeepSeek V4 Flash wurde im August 2026 verbunden (proposal #94), GLM-5.3 Flash — im September 2026 (proposal #101). Die nächsten Kandidaten sind Embedding-Modelle für RAG: Dies wird Gonka für eine neue Klasse von Anwendungen öffnen (Suchmaschinen, Unternehmenswissensdatenbanken, Chatbots mit Gedächtnis).

Inference Quality Protocol (GiP #860) — Routing nach Qualität. Derzeit werden Anfragen nach der Verfügbarkeit der Knoten verteilt; in Zukunft nach der Qualität der Antworten. Knoten mit besserer Hardware und stabilerer Leistung werden Priorität erhalten.

On-chain governance migration (2026–2027) — Umstellung auf das vollständige x/gov Modul aus dem Cosmos SDK. Dies bietet: 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 können auf gonka.gg/network/proposals verfolgt und dort mitgestaltet werden.