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.

Update-Prozess:

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. Release – Eine neue Version des Binärprogramms gonkad wird erstellt.
4. On-Chain-Proposal – Ein Upgrade-Vorschlag wird im Netzwerk mit einer Beschreibung der Änderungen erstellt.
5. Deposit + Vote – Hosts leisten eine Einzahlung (Aktivierungsschwelle) und stimmen während des Voting-Zeitraums ab.
6. Cosmovisor – Bei Genehmigung aktualisiert Cosmovisor die Nodes automatisch auf der angegebenen Blockhöhe.

Von Januar bis März 2026 hat das Netzwerk über 11 erfolgreiche Abstimmungen durchlaufen – von Version v0.2.2 bis v0.2.11. Alle Vorschläge wurden genehmigt. Die letzte große Abstimmung – proposal #31 (v0.2.11) – erhielt 673.699 Ja-Stimmen bei 0 Nein-Stimmen. Dieses Update führte Subnet Inference ein – einen Mechanismus für Off-Chain-Berechnungen über Subnetze, der eine 100-fache Steigerung des Durchsatzes verspricht.

Abstimmungsoptionen:

• Yes – Ich unterstütze das Update.
• No – Ich bin gegen das Update.
• No with Veto – Ich bin kategorisch dagegen; wenn mehr als 33 % der Stimmen – wird der Vorschlag abgelehnt und die Einzahlung verfällt.
• Abstain – Ich enthalte mich, nehme aber 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 Abstimmenden einsehen.

GiP ist ein System zur Formalisierung von Ideen für die 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 – Umsetzungsplan nach Phasen.
• Open Questions – Offene Fragen zur Diskussion in der Community.

GiP sind nicht bindend – sie verpflichten das Team nicht zur Umsetzung. Aber sie bilden einen Community-Konsens und geben die Richtung für zukünftige On-Chain-Vorschläge vor. Tatsächlich ist GiP „Pre-Governance“: Diskussion vor der Abstimmung.

Wichtige GiPs:

• #800 Multi-Model PoC – Unterstützung mehrerer KI-Modelle gleichzeitig. Derzeit arbeitet das Netzwerk mit Qwen3-235B; dieses GiP beschreibt die Architektur für die parallele Arbeit verschiedener Modelle mit separatem Proof of Useful Work.
• #801 Inference Scaling – Subnet-Architektur 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. Nodes, die bessere Ergebnisse liefern, erhalten mehr Traffic und Belohnungen.

Jeder Teilnehmer kann ein GiP über GitHub Discussions erstellen. Die Einstiegshürde ist minimal – man benötigt lediglich einen GitHub-Account 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 der Umsetzung zugeführt.

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) – Unterstützung mehrerer Modelle gleichzeitig. Der erste Kandidat sind Embedding-Modelle für RAG. Dies wird Gonka für eine völlig neue Klasse von Anwendungen öffnen: Suchmaschinen, Unternehmenswissensdatenbanken, Chatbots mit Speicher.

Inference Quality Protocol (GiP #860) – Routing nach Qualität. Derzeit werden Anfragen nach der Verfügbarkeit von Nodes verteilt; in Zukunft – nach der Qualität der Antworten. Nodes mit besserer Hardware und stabilerem Betrieb erhalten Priorität.

On-chain governance migration (2026–2027) – Übergang zu einem vollwertigen x/gov-Modul aus dem Cosmos SDK. Dies wird ermöglichen: formalisierte Proposal-Typen, automatische Ausführung genehmigter Änderungen, Integration mit IBC (Inter-Blockchain Communication) und die Möglichkeit, Governance-Vorschläge über jede Cosmos-kompatible Wallet zu erstellen.

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