知識ベースのセクション ▾
ナビゲーション
▸ ここから始める 役割別カテゴリー
- GNKトークンの価値の源泉
- Gonka vs 競合他社:Render、Akash、io.net
- リーバーマン家:生物物理学から分散型AIへ
- GNK トークノミクス
- Gonkaのリスクと見通し: 客観的分析
- Gonka vs Render Network: 詳細な比較
- Gonka vs Akash: AI推論 vs コンテナ
- Gonka vs io.net: 推論 vs GPUマーケットプレイス
- Gonka vs Bittensor:AIへの2つのアプローチの詳細な比較
- Gonka vs Flux:有用なマイニングへの2つのアプローチ
- Gonkaにおけるガバナンス:分散型ネットワークの管理方法
- GNKトークンの購入方法:ステップバイステップガイド
投資家向け
Gonkaにおけるガバナンス:分散型ネットワークの管理方法
Gonkaは、実際のオンチェーンガバナンスを持つ数少ないAIネットワークの1つです。ここでは、財団や投資家がプロトコルの方向性を決定するのではなく、ネットワークに計算能力を提供するホストが決定します。各GPUは計算貢献に比例した投票権を持ちます。つまり、計算量が多いほど影響力も大きくなります。
2026年1月から3月までの3か月間で、11以上の投票が行われ、すべて承認されました。この記事では、2つの管理レベル、更新メカニズム、GiPシステム、コミュニティプールを通じたエコシステムの資金調達、および初期段階の保護メカニズムについて説明します。
2つの管理レベル
Gonkaの管理は2つのレベルで行われ、それぞれに異なる速度と決定規模があります。
Operational Voting (分単位) — ネットワーク内の運用上の決定。インファレンス要求またはPoCの結果の有効性について紛争が発生した場合、ホストはCosmos SDKのモジュールx/groupを介して投票します。投票の重みはPoC weightによって決定されます。ノードが実行する計算が多いほど、その影響力は大きくなります。このような投票は数分間続き、特定の問題を解決します。例えば、インファレンスが正しかったか、ノードがその役割を適切に果たしたかなどです。
Governance Voting (日単位) — プロトコルの開発に関する戦略的決定。ソフトウェアの更新、ネットワークパラメータの変更、新しいモデルのアクティブ化、コミュニティプールの資金配分など、これらすべてはすべてのホストの投票にかけられます。投票期間は数日から1週間で、すべての参加者が提案を検討するのに十分な時間があります。
ほとんどの暗号プロジェクトとの主な違い:投票の重みはステーキングではなく、Proof of Computeによって決定されます。Gonkaでは、ウォレットにトークンを蓄積するだけで「投票を購入」することはできません。影響力は実際の計算貢献、つまりAI要求を処理し、作業の証明を生成するGPUに比例します。これにより、管理は投機的な資本ではなく、ネットワークアーキテクチャを実際にサポートする者に関連付けられます。
実際には、これは、10台のH100を持つファームオペレーターが1枚のカードを持つオペレーターよりも10倍多くの投票を持つことを意味します。なぜなら、彼らは10倍多くのインファレンス要求を処理するからです。システムは自己均衡的です。ネットワークの運用により多く貢献する者は、その開発により大きな影響を与えます。
アップグレード提案:ネットワークの更新方法
Gonkaプロトコルの更新は、コードからネットワークでのアクティベーションまで、形式化されたプロセスです。すべてのステップは透明で検証可能です。
更新プロセス:
- GitHubでのプルリクエスト — 開発者(Gonkaチームまたはコントリビューター)が
gonka-ai/gonkaリポジトリにPRを作成します。 - コミュニティレビュー — コードがレビューされ、議論され、テストされます。重要な変更についてはCertiKの監査が行われます。
- リリース — 新しい
gonkadバイナリバージョンがビルドされます。 - オンチェーンプロポーザル — 変更の説明を含む更新提案がネットワークで作成されます。
- デポジット+投票 — ホストはデポジット(アクティベーションしきい値)を行い、投票期間中に投票します。
- Cosmovisor — 承認されると、Cosmovisorは指定されたブロック高さでノードを自動的に更新します。
2026年1月から5月にかけて、ネットワークは13以上の成功した投票を経て、v0.2.2からv0.2.13に更新されました。すべての提案が承認されました。主要なアップグレードの履歴:
- v0.2.11(2026年3月、提案#31) — 賛成票673,699、反対票0。サブネット推論が導入されました。これはサブネットを介したオフチェーン計算メカニズムで、スループットが100倍に向上すると期待されています。
- v0.2.13(2026年5月、提案#54) — 2026年5月21日採択(賛成62.8%、投票率39.9%、定足数33.4%)、ブロック4267300で有効化。MiniMax-M2.7をネットワークの3番目のモデルとして追加し、Ethereumブリッジ配線をアクティベートし、定足数を0.25に引き下げました。
投票オプション:
- Yes — 更新を支持します。
- No — 更新に反対します。
- No with Veto — 断固として反対します。33%以上の票が集まると、提案は否決され、デポジットは失効します。
- Abstain — 棄権しますが、定足数には参加します。
すべての投票履歴はgonka.gg/network/proposalsで確認でき、個々の提案、結果、投票者リストを見ることができます。
GiP: Gonka改善提案
GiP は、Gonkaプロトコルの発展に向けたアイデアを体系化する仕組みであり、2026年2月24日にGitHub Discussions(issue #795)を通じて開始されました。
各GiPのフォーマット:
- Motivation — 提案が解決する問題。
- Solution — ソリューションの技術的説明。
- Roadmap — 段階的な実装計画。
- Open Questions — コミュニティで議論すべき未解決の質問。
GiPはbinding(拘束力)を持たず、チームに実装を義務付けるものではありません。しかし、コミュニティのコンセンサスを形成し、将来のon-chain proposalsへの方向性を定めます。実質的にGiPは「pre-governance」(投票前の議論)の役割を果たします。
主要なGiP:
- #800 Multi-Model PoC — 複数のAIモデルの同時サポート。現在ネットワークはKimi K2.6とMiniMax M2.7で動作しています。MiniMax-M2.7はv0.2.13で追加されます。GiPは、個別の Proof of Useful Work を持つ異なるモデルを並行稼働させるアーキテクチャを記述しています。
- #801 Inference Scaling — スケーリングのためのsubnet architecture。このGiPの一部はv0.2.11(subnet inference)で既に実装済みです。
- #860 Quality Protocol — 回答品質を考慮したリクエストのルーティング。より良い結果を出すノードが、より多くのトラフィックと報酬を獲得します。
参加者は誰でもGitHub Discussionsを通じてGiPを作成できます。参入障壁は最小限で、GitHubアカウントと課題への理解があれば十分です。Gonkaチームとホストが参加する活発な議論を見る限り、システムは機能しています。提案はフィードバックを受け、改善され、実装へと向かっています。
コミュニティプール:エコシステムの資金調達
コミュニティプールは、Gonkaエコシステム開発のための基金です。創世記発行の約20%(約2億GNK)が、助成金、バウンティ、コミュニティイニシアチブの資金として割り当てられています。
コードへの貢献に対するバウンティ — コミュニティプールの資金を分配する主要なメカニズムです。開発者は、gonka-ai/gonkaリポジトリへのPRに対して報酬を受け取ります。バグ修正から新機能の実装まで。バウンティのサイズは、貢献の複雑さと重要性によって異なります。
| 貢献の種類 | 例 | バウンティ (GNK) |
|---|---|---|
| 脆弱性 (重要) | セキュリティ修正、エクスプロイト | 5,000 — 10,000 |
| 計画されたタスク | ロードマップからの機能 | 1,000 — 2,500 |
| コードレビュー | 重要なPRのレビュー | 1,500 — 2,500 |
| ドキュメント | 技術文書 | 500 — 1,500 |
| 軽微な修正 | バグ修正、リファクタリング | 100 — 700 |
承認メカニズム: バウンティはアップグレード提案のREADMEに含まれます。ホストがプロトコルアップグレードに投票する際、同時にそのリリースに含まれるPRの支払いリストを承認します。透明性は完全で、誰でも何に対していくら支払われたかを確認できます。
バウンティの他に、コミュニティプールはエコシステムツールの開発、マーケティング、教育イニシアチブ、研究助成金に資金を提供できます。GitHubを通じて稼ぐことについての詳細な情報は、別の記事で確認できます。
初期段階での保護
新しいネットワークは脆弱です。ノードが少なく、ステークが少ないため、51%攻撃が理論的に可能です。Gonkaはいくつかのメカニズムでこれを解決します。
ガーディアンシステム — Gonkaチームが管理する3つの信頼されたノードで、合計34%のコンセンサスパワーを持ちます。ガーディアンは決定を強制することはできませんが(承認には34% < 67%)、悪意のある提案をブロックすることはできます(34% > 33%の拒否権閾値)。重要な点:ガーディアンは、ネットワークの総パワー(total_network_power)が1,000万ユニットに達すると自動的に非アクティブ化されます。これは手動のスイッチではなく、非アクティブ化はプロトコル内でプログラムされています。
担保システム — ホストは、完全な重みを得るためにGNKで担保を預ける必要があります。
- 基本重み (20%) — 無条件の重みであり、ノードの動作自体に対して付与されます。
- 担保対象 (80%) — GNKで担保がある場合にのみ利用可能な追加の重み。担保のサイズは計算能力に比例します。
スラッシング — 違反に対するペナルティ。
- 担保の20% — INVALIDインファレンス(ノードが不正確な結果を出した場合)。
- 担保の10% — ダウンタイム(ノードが許容閾値を超えて利用できない場合)。
グレース期間 — 180エポック(約6か月)の間、新しいホストは担保なしで作業できます。これにより、参入障壁が低くなります。マイニングを開始し、報酬を通じてGNKを獲得し、その後担保を預けることができます。グレース期間終了後、担保なしのノードは潜在的な重みの20%しか受け取れません。
これらのメカニズムはすべてGNKのトークノミクスに記載されており、長期的な分散化を犠牲にすることなく、初期段階でネットワークを保護することを目的としています。
次のステップ:ガバナンスのロードマップ
Gonka のガバナンスは静的なシステムではなく、進化するプロセスです。以下は 2026 年から 2027 年の主要な開発方向です。
Multi-Model PoC (GiP #800) — 実装済み: Kimi K2.6 は 2026 年 5 月から DevShards で稼働しており、MiniMax-M2.7 は v0.2.13 (提案 #54) で追加されています。次の候補は RAG 用の埋め込みモデルです。これにより Gonka は新しい種類のアプリケーション(検索エンジン、企業知識ベース、記憶を持つチャットボット)に対応できるようになります。
Inference Quality Protocol (GiP #860) — 品質によるルーティング。現在、リクエストはノードの可用性に基づいて分散されますが、将来的には応答品質に基づいて分散されます。より良いハードウェアと安定した稼働を持つノードが優先されます。
On-chain governance migration (2026–2027) — Cosmos SDK の完全な x/gov モジュールへの移行。これにより、形式化された提案タイプ、承認された変更の自動実行、IBC (Inter-Blockchain Communication) との統合、および任意の Cosmos 互換ウォレットを介したガバナンス提案の作成機能が提供されます。
投票の追跡と参加は gonka.gg/network/proposals で行えます。