====== 260119 QUBIC ネットワーク・ガーディアン（NETWORK GUARDIANS）: 分散型ノード運用のための新しいインセンティブ・システム ======

原文 [[https://qubic.org/blog-detail/qubic-network-guardians-a-new-incentive-system-for-decentralized-node-operation|Qubic Network Guardians: A New Incentive System for Decentralized Node Operation | Qubic Blog]]

執筆者: Qubic チーム ／ 公開日: 2026年1月19日

{{.:pasted:20260119-120100.png?800}}

**軽量ノードへの報酬を通じて Qubic ネットワークを強化する**

===== はじめに =====

　Qubic ネットワークは、CertiK によって検証された秒間 1,550 万件（TPS）という圧倒的なスピードでその名声を築いてきました。このパフォーマンスの裏側には、[[tag/ベアメタル]]・ハードウェア上でプロトコルを直接実行する高性能マシンのネットワークが存在します。このアーキテクチャは効果的である一方、一つの課題を提示していました。それは、ハードウェア要件の高さが、ネットワークの維持に参加できる人々を限定してしまっていた点です。

　「Qubic Network Guardians（[[tag/ネットワークガーディアン]]）」は、この現状を変えるために設計されました。

　ハードウェア要件の低い軽量ノードの選択肢を導入することで、参入障壁を取り除き、誰もがネットワーク参加を可能にします。参加者が増えることは、より強力で分散化されたネットワークを意味します。

===== 課題：ネットワーク参加への高い障壁 =====

　現在、Qubic のフルノード（[[tag/Computor]]）を運営するには、膨大なリソースが必要です。

　公式の要件には、AVX2 対応（2027年までに AVX-512 が必須化予定）の 8 コア以上の高周波 CPU（>3.5GHz）、2TB の RAM、および専用の[[tag/ベアメタル]]環境（UEFIアプリ）が含まれます。これらの仕様は、ネットワークが並外れたスループットを維持するために不可欠ですが、同時に実質的な障壁となっていました。

　運営者が少ないことは、冗長性の低下を意味します。ノードが少人数のグループに集中すると、ネットワークは停止や潜在的な中央集権化に対して脆弱になります。これはブロックチェーン設計における既知の緊張関係です。つまり、パフォーマンス要件が、分散型ネットワークの価値である「分散化」を妨げる可能性があるのです。

　[[tag/Computor]] に高いハードウェア要件が課されているのには正当な理由があります。これらのマシンは、Qubic の性能を正当化するスピードでトランザクションを処理し、スマートコントラクトを実行し、合意に達しなければなりません。これらの仕様を下げてしまえば、ネットワークのスループットが損なわれます。解決策は Computor の要件を下げることではなく、貢献するための「追加の方法」を作り出すことでした。

===== 解決策：軽量ノードへのインセンティブ付与 =====

　[[tag/ネットワークガーディアン|Network Guardians]] は、**[[tag:bob|Bob]]ノード**および**[[tag:core-lite|コア・ライト]]ノード**の運用に対して経済的な報酬を導入します。これらの軽量な代替手段は、フル Computor のような極端なハードウェアを必要とせず、ネットワークに有意義な利益をもたらします。

==== Bobノードとコア・ライトノードとは？ ====

  * **[[tag:bob|Bob]]ノード (Bob Node):** 
    * Qubic ブロックチェーン用の高性能インデクサーです。
    * Ethereum と同様の JSON-RPC 2.0 API や、リアルタイムデータストリーミング用の WebSocket サブスクリプションを提供します。
    * 取引所の統合や dApp 開発向けに設計されており、残高照会、トランザクション追跡、ログフィルタリング、スマートコントラクト照会などの機能を提供します。

  * **コア・ライトノード ([[tag/Core-Lite]] Node):** 
    * Qubic コアネットワークに接続し、[[tag/Computor]] として合意形成に参加することなく、ブロックチェーンデータ（[[tag/ティック]]、トランザクション、ログ）を受信・検証する軽量ノードです。
    * 重い計算や投票を行うフルノードとは異なり、データのインデックス作成と提供に焦点を当てているため、API、ウォレット、取引所統合の運用に最適です。

　どちらのノードタイプも、データの可用性を向上させ、冗長性を高め、ネットワーククエリのための追加アクセスポイントを提供することで、ネットワークの健全性に貢献します。

{{.:pasted:20260119-115842.png?800}}


===== Network Guardians の仕組み =====

　このプログラムは、「監視」「スコアリング」「報酬」という分かりやすいサイクルで運営されます。

==== ステップ 1: ノードの登録と発見 ====

　運営者は、自身の Bobノードまたはコア・ライトノードにオペレーターIDと任意の表示名を設定します。

　システムはネットワークのクローリングとノード通知を通じて、参加ノードを自動的に発見します。適切なノード設定以外に、手動での登録プロセスは必要ありません。

==== ステップ 2: 継続的な監視 ====

　発見されたノードは継続的な監視対象となります。

　システムは多角的にパフォーマンスを評価し、運営者が単にソフトウェアをアイドル状態で動かしているのではなく、真にネットワークの健全性に貢献しているかを確認します。

==== ステップ 3: スコアリング・システム ====

　ポイントは、実際のネットワーク価値を反映した以下の加重基準に基づいて蓄積されます。

^ メトリクス ^ 重み ^ 測定内容 ^
| 稼働時間 (Uptime) | 50% | 一貫した可用性と信頼性 |
| 同期状態 (Sync Status) | 30% | 現在のネットワーク状態への追従 |
| データの正確性 (Data Correctness) | 20% | 提供されるデータと応答の正確さ |

> **注意:** スコアリングの枠組みは現在開発中であり、上記の数値は例示であり変更される可能性があります。最終的な数値は後日通知されます。

==== ステップ 4: 公開リーダーボード ====

　すべての参加オペレーターは、累積スコア順にランク付けされた透明なリーダーボードに表示されます。

　誰でも、誰がどれだけ貢献しているかを検証できます。この可視化は説明責任を生み出し、コミュニティが優れたパフォーマンスを発揮している運営者を認めることを可能にします。

==== ステップ 5: エポックベースの報酬 ====

　QU 報酬は、各[[tag/エポック]]（Qubic の週間サイクル）の終了時に、オペレーターのスコアに比例して分配されます。高ランクのオペレーターほど、報酬プールのより大きなシェアを受け取ります。

　これはメインネットワークにおける [[tag/Computor]] 報酬の仕組みと同様のモデルを軽量ノード運営者に拡張したものです。

===== 技術要件 =====

{{.:pasted:20260119-115800.png?800}}

　[[tag/ネットワークガーディアン|Network Guardians]] の参加仕様はフルノードの要件を大きく下回りますが、依然として有能なマシンを必要とします。

^ コンポーネント ^ [[tag:bob|Bob]]ノード要件 ^ [[tag:core-lite|コア・ライト]]ノード要件 ^
| **RAM** | 最低 16 GB | 最低 64 GB |
| **CPU** | AVX2対応 4コア | AVX2 または AVX512対応 8コア |
| **ネットワーク** | 安定したインターネット接続 | 1 Gbps 推奨 |
| **OS** | Linux | Linux |

　比較として、フルノード（[[tag/Computor]]）の運用には、8コア以上のベアメタル、AVX-512対応、2TB RAM、および専用サーバーインフラが必要です。

　軽量な代替案により、参入障壁は大幅に下がります。

===== 不正行為の防止 =====

　いかなる報酬システムも不正の試みに直面します。[[tag/ネットワークガーディアン|Network Guardians]] はいくつかの対抗策を計画しています。

  * **リレーおよびプロキシ検出:** 
    * 稼働しているように見せかけて、実際には他のインフラを介してリクエストをルーティングしているノードを特定するメカニズム。

  * **ID 制限:** 
    * 単一のオペレーターIDが登録できるノード数の制限。これにより、一人の参加者が低負荷のインスタンスを大量に作成して不当に報酬を得ることを防ぎます。

===== 長期ビジョン：オンチェーンへの移行 =====

　[[tag/ネットワークガーディアン|Network Guardians]] の初期段階は、[[tag/スマートコントラクト]]なしで運営されます。報酬の計算は既存のインフラで行われ、分配は確立されたプロセスに従います。

　ロードマップでは、以下の開発を通じて完全なオンチェーン運用を目指しています。

  * **[[tag/スマートコントラクト]]のデプロイ:** 
    * 報酬プールと分配ロジックを管理する専用コントラクト。

  * **[[tag:オラクルマシン]]との統合:** 
    * Qubic プロトコルインターフェースを通じて、[[tag/スマートコントラクト]]を実世界のデータに接続する「オラクルマシン」から提供されるネットワーク統計。

  * **自動分配:** 
    * コントラクトロジックによって完全に処理される報酬計算と支払い。これにより手動プロセスが排除され、透明性が向上します。

===== 分散化が重要な理由 =====

　Qubic ネットワークを検証する 676 台の [[tag/Computor]] は、トランザクションを確定させるために[[tag/クォーラム]]（451 台以上の合意）に達する必要があります。

　この[[tag/ビザンチン障害耐性]]（BFT）設計により、一部の検証者が故障したり悪意を持って行動したりしても、ネットワークは機能し続けることができます。

　軽量ノードは合意形成に直接参加しませんが、別の方法でネットワークを強化します。

  * **データの冗長性:** 
    * ネットワークデータを保存・提供するノードが増えるほど、障害や攻撃時の可用性が高まります。

  * **地理的分散:** 
    * ハードウェア要件が下がることで、より多くの場所で運営者が参加可能になり、データセンターへの集中を軽減できます。

  * **クエリ負荷の分散:** 
    * API リクエストやデータクエリを処理するノードが増えることで [[tag/Computor]] の負担が軽減され、[[tag/Computor]] は合意形成に集中できます。

  * **攻撃耐性:** 
    * ノード数が増えることで、標的を絞った攻撃の実行がより困難かつコスト高になります。

===== はじめ方 =====

　[[tag/ネットワークガーディアン|Network Guardians]] はシンプルさを追求して設計されています。[[tag:bob|Bob]]ノードと[[tag:core-lite|コア・ライト]]ノードの両方が **Docker イメージ**として提供され、ほぼワンクリックでのデプロイが可能になります。

==== なぜ Docker なのか？ ====

　これらのノードは単一の実行ファイルではなく、コアノード、Redis、kvrocks など、連携して動作する必要がある複数のサービスで構成されたシステムです。

　Docker はこのスタック全体を、単一の再現可能なユニットとしてパッケージ化します。

  * **一貫した環境:** 
    * 全ユーザーが同じバージョンを実行でき、設定の齟齬がありません。

  * **依存関係管理が不要:** 
    * Redis や kvrocks の手動インストールが不要です。

  * **シンプルな操作:** 
    * Docker Compose でスタック全体を一括で起動・停止できます。

===== ロードマップ：共に築く =====

^ フェーズ ^ 予定時期 ^
| クローズドベータ | 1月末 |
| パブリックローンチ | 2月中旬〜下旬 |

　この道のり自体がキャンペーンの一部です。初期参加者からのフィードバックが、最終的な実装、スコアリングの重み、報酬メカニズムを形作ります。

　これは与えられるシステムではなく、共に構築されるインフラです。

----
===== 結論 =====

　[[tag/ネットワークガーディアン|Network Guardians]] は、Qubic のスループットを維持しつつ、分散化の精神をハードウェアの制約から解放する重要なステップです。

　[[tag/Computor]] が「筋肉」であるならば、これら軽量ノードのネットワークは、エコシステム全体にデータを届ける「血管」の役割を果たします。

{{tag>news 260119 ネットワークガーディアン エポック報酬 ノード Bob Core-Lite }}