知識ベースのセクション ▾
ナビゲーション
▸ ここから始める 役割別カテゴリー
- GNKトークンの価値の源泉
- 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におけるガバナンス：分散型ネットワークの管理方法
投資家向け
Gonkaにおけるガバナンス：分散型ネットワークの管理方法
Gonka は、真のオンチェーンガバナンスを備えた数少ない AI ネットワークのひとつです。ここでは財団や投資家がプロトコルの進む方向を決めるのではなく、ネットワークに計算リソースを提供するホストたちが決定します。各 GPU は、確認済みの計算貢献に比例した発言権を持ちます — 計算が多ければ多いほど、影響力も大きくなります。
2026 年 1 月から 3 月までの 3 か月間で 11 回以上の投票が行われ、すべて承認されました。本記事では、2 層のガバナンス、アップデートの仕組み、GiP システム、Community Pool を通じたエコシステムの資金調達、そして初期段階の防御メカニズムを解説します。
2つの管理レベル
Gonka のガバナンスは 2 つの層で機能し、それぞれ意思決定のスピードと範囲が異なります。
Operational Voting（数分） — ネットワーク内の運用上の意思決定です。inference リクエストや PoC の結果の有効性をめぐって争いが生じた場合、ホストは Cosmos SDK の x/group モジュールを通じて投票します。投票の重みは PoC weight によって決まり、ノードが実行する計算が多いほど影響力が大きくなります。こうした投票は数分で終わり、inference が正しかったか、ノードが自分の仕事を果たしたかといった具体的な対立を解決します。
Governance Voting（数日） — プロトコルの発展に関する戦略的な意思決定です。ソフトウェアのアップデート、ネットワークパラメータの変更、新しいモデルの有効化、Community Pool の資金配分 — これらすべてが全ホストの投票にかけられます。投票期間は数日から 1 週間で、すべての参加者が提案を検討する時間を確保できます。
ほとんどのクリプトプロジェクトとの決定的な違い：投票の重みはステーキングではなく Proof of Compute によって決まります。Gonka では、ウォレットにトークンを貯めるだけでは「票を買う」ことはできません。影響力は実際の計算貢献に比例します — AI リクエストを処理し、作業証明を生成する GPU です。v0.2.16 のアップデート以降、前のエポックで確認された電力がカウントされます。新しいホストは最初のエポックでは重みゼロで投票し、電力の増加分は次のエポックから票を追加します。これにより、ガバナンスは投機的資本ではなく、ネットワークアーキテクチャを実際に支える人々に結びつきます。
実際には、8× H100 のサーバーを 2 台運用するオペレーターは、同じサーバーを 1 台だけ運用するオペレーターの約 2 倍の票を持ちます。処理する inference リクエストが約 2 倍だからです。このシステムは自己調整的です：ネットワークの運営により多く貢献する者ほど、その発展により大きな影響力を持ちます。
アップグレード提案：ネットワークの更新方法
Gonkaプロトコルのアップグレードは、コードからネットワークでの有効化に至るまで体系化されたプロセスです。すべてのステップが透明で検証可能です。
アップグレードプロセス：
- GitHubへのPull Request — 開発者（Gonkaチームまたはコントリビューター）が
gonka-ai/gonkaリポジトリにPRを作成します。 - コミュニティレビュー — コードが検証・議論・テストされます。重要な変更にはCertiKによる監査を実施。
- リリース — 新しいバイナリ
inferencedのバージョンがビルドされます。 - オンチェーン提案 — 変更内容を記載したネットワークアップグレード提案が作成されます。
- デポジット＋投票 — ホストがデポジット（有効化閾値）を拠出し、投票期間中に投票します。
- Cosmovisor — 承認されると、Cosmovisorが指定ブロック高でノードを自動更新します。
2026年1月から5月にかけて、ネットワークは13回以上の投票を成功裏に実施しました — v0.2.2からv0.2.13まで。すべての提案が承認されました。主要アップグレードの時系列：
- v0.2.11（2026年3月、proposal #31） — 賛成673,699票、反対0票。subnet inferenceを導入 — サブネット経由のオフチェーン計算機構で、スループットの100倍増加が期待されています。
- v0.2.13（2026年5月、proposal #54） — 2026年5月21日に可決（賛成62.8%、投票率39.9%、定足数33.4%）、ブロック4267300で有効化。MiniMax-M2.7をネットワークの3番目のモデルとして追加し、Ethereum bridge wiringを有効化、定足数を0.25に引き下げました。
投票オプション：
- Yes — アップグレードを支持します。
- No — アップグレードに反対します。
- No with Veto — 強く反対します。33%を超える票が集まると提案は否決され、デポジットは没収されます。
- Abstain — 棄権しますが、定足数には参加します。
すべての投票履歴はgonka.gg/network/proposalsで確認できます — 各提案、結果、投票者リストを閲覧できます。
GiP: Gonka改善提案
GiP — 2026年2月24日にGitHub Discussions (issue #795) を通じて開始された、Gonkaプロトコル開発のためのアイデア形式化システムです。
各GiPのフォーマット:
- Motivation — 提案が解決する課題。
- Solution — 技術的な解決策の説明。
- Roadmap — 実装段階ごとの計画。
- Open Questions — コミュニティで議論すべき未解決事項。
GiPはbinding（拘束力）を持たず、チームに実装を義務付けるものではありません。しかし、コミュニティのコンセンサスを形成し、将来のon-chain proposalsの方向性を決定します。実質的にGiPは「pre-governance」（投票前の議論）として機能します。
主要なGiP:
- #800 Multi-Model PoC — 複数のAIモデルの同時サポート。現在、ネットワークはMiniMax M2.7 (v0.2.13で追加)、DeepSeek V4 Flash (proposal #94)、GLM-5.3 Flash (proposal #101) で動作しています。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におけるGovernanceは静的なシステムではなく、進化し続けるプロセスです。以下は2026–2027年に向けた主要な開発方針です。
Multi-Model PoC (GiP #800) — 実装済み：2026年5月にDevShardsを通じてKimi K2.6が最初に加わり（現在はネットワークから離脱）、MiniMax-M2.7はv0.2.13 (proposal #54) で追加、DeepSeek V4 Flashは2026年8月 (proposal #94) に接続、GLM-5.3 Flashは2026年9月 (proposal #101) に接続されました。次の候補はRAGのためのembeddingモデルであり、これによりGonkaは新しいクラスのアプリケーション（検索エンジン、企業ナレッジベース、メモリ付きチャットボット）に開かれることになります。
Inference Quality Protocol (GiP #860) — 品質ベースのルーティング。現在はノードの可用性に基づいてリクエストが分散されていますが、将来的には回答の品質に基づいて分散されます。より良いハードウェアと安定した稼働を持つノードが優先されます。
On-chain governance migration (2026–2027) — Cosmos SDKのx/govモジュールへの完全移行。これにより、形式化されたproposal types、承認された変更の自動実行、IBC (Inter-Blockchain Communication) との統合、およびCosmos互換ウォレットを通じたgovernance proposalsの作成が可能になります。
投票の確認や参加は gonka.gg/network/proposals で行えます。