official-blog:260119_network_guardians
差分
このページの2つのバージョン間の差分を表示します。
| 両方とも前のリビジョン前のリビジョン次のリビジョン | 前のリビジョン | ||
| official-blog:260119_network_guardians [2026/01/26 02:07] – 削除 - 外部編集 (不明な日付) 127.0.0.1 | official-blog:260119_network_guardians [2026/02/12 13:02] (現在) – [結論] d.azuma | ||
|---|---|---|---|
| 行 1: | 行 1: | ||
| + | ====== 260119 QUBIC ネットワーク・ガーディアン(NETWORK GUARDIANS): | ||
| + | 原文 [[https:// | ||
| + | |||
| + | 執筆者: Qubic チーム / 公開日: 2026年1月19日 | ||
| + | |||
| + | {{.: | ||
| + | |||
| + | **軽量ノードへの報酬を通じて Qubic ネットワークを強化する** | ||
| + | |||
| + | ===== はじめに ===== | ||
| + | |||
| + | Qubic ネットワークは、CertiK によって検証された秒間 1,550 万件(TPS)という圧倒的なスピードでその名声を築いてきました。このパフォーマンスの裏側には、[[tag/ | ||
| + | |||
| + | 「Qubic Network Guardians([[tag/ | ||
| + | |||
| + | ハードウェア要件の低い軽量ノードの選択肢を導入することで、参入障壁を取り除き、誰もがネットワーク参加を可能にします。参加者が増えることは、より強力で分散化されたネットワークを意味します。 | ||
| + | |||
| + | ===== 課題:ネットワーク参加への高い障壁 ===== | ||
| + | |||
| + | 現在、Qubic のフルノード([[tag/ | ||
| + | |||
| + | 公式の要件には、AVX2 対応(2027年までに AVX-512 が必須化予定)の 8 コア以上の高周波 CPU(> | ||
| + | |||
| + | 運営者が少ないことは、冗長性の低下を意味します。ノードが少人数のグループに集中すると、ネットワークは停止や潜在的な中央集権化に対して脆弱になります。これはブロックチェーン設計における既知の緊張関係です。つまり、パフォーマンス要件が、分散型ネットワークの価値である「分散化」を妨げる可能性があるのです。 | ||
| + | |||
| + | [[tag/ | ||
| + | |||
| + | ===== 解決策:軽量ノードへのインセンティブ付与 ===== | ||
| + | |||
| + | [[tag/ | ||
| + | |||
| + | ==== Bobノードとコア・ライトノードとは? ==== | ||
| + | |||
| + | * **[[tag: | ||
| + | * Qubic ブロックチェーン用の高性能インデクサーです。 | ||
| + | * Ethereum と同様の JSON-RPC 2.0 API や、リアルタイムデータストリーミング用の WebSocket サブスクリプションを提供します。 | ||
| + | * 取引所の統合や dApp 開発向けに設計されており、残高照会、トランザクション追跡、ログフィルタリング、スマートコントラクト照会などの機能を提供します。 | ||
| + | |||
| + | * **コア・ライトノード ([[tag/ | ||
| + | * Qubic コアネットワークに接続し、[[tag/ | ||
| + | * 重い計算や投票を行うフルノードとは異なり、データのインデックス作成と提供に焦点を当てているため、API、ウォレット、取引所統合の運用に最適です。 | ||
| + | |||
| + | どちらのノードタイプも、データの可用性を向上させ、冗長性を高め、ネットワーククエリのための追加アクセスポイントを提供することで、ネットワークの健全性に貢献します。 | ||
| + | |||
| + | {{.: | ||
| + | |||
| + | |||
| + | ===== Network Guardians の仕組み ===== | ||
| + | |||
| + | このプログラムは、「監視」「スコアリング」「報酬」という分かりやすいサイクルで運営されます。 | ||
| + | |||
| + | ==== ステップ 1: ノードの登録と発見 ==== | ||
| + | |||
| + | 運営者は、自身の Bobノードまたはコア・ライトノードにオペレーターIDと任意の表示名を設定します。 | ||
| + | |||
| + | システムはネットワークのクローリングとノード通知を通じて、参加ノードを自動的に発見します。適切なノード設定以外に、手動での登録プロセスは必要ありません。 | ||
| + | |||
| + | ==== ステップ 2: 継続的な監視 ==== | ||
| + | |||
| + | 発見されたノードは継続的な監視対象となります。 | ||
| + | |||
| + | システムは多角的にパフォーマンスを評価し、運営者が単にソフトウェアをアイドル状態で動かしているのではなく、真にネットワークの健全性に貢献しているかを確認します。 | ||
| + | |||
| + | ==== ステップ 3: スコアリング・システム ==== | ||
| + | |||
| + | ポイントは、実際のネットワーク価値を反映した以下の加重基準に基づいて蓄積されます。 | ||
| + | |||
| + | ^ メトリクス ^ 重み ^ 測定内容 ^ | ||
| + | | 稼働時間 (Uptime) | 50% | 一貫した可用性と信頼性 | | ||
| + | | 同期状態 (Sync Status) | 30% | 現在のネットワーク状態への追従 | | ||
| + | | データの正確性 (Data Correctness) | 20% | 提供されるデータと応答の正確さ | | ||
| + | |||
| + | > **注意:** スコアリングの枠組みは現在開発中であり、上記の数値は例示であり変更される可能性があります。最終的な数値は後日通知されます。 | ||
| + | |||
| + | ==== ステップ 4: 公開リーダーボード ==== | ||
| + | |||
| + | すべての参加オペレーターは、累積スコア順にランク付けされた透明なリーダーボードに表示されます。 | ||
| + | |||
| + | 誰でも、誰がどれだけ貢献しているかを検証できます。この可視化は説明責任を生み出し、コミュニティが優れたパフォーマンスを発揮している運営者を認めることを可能にします。 | ||
| + | |||
| + | ==== ステップ 5: エポックベースの報酬 ==== | ||
| + | |||
| + | QU 報酬は、各[[tag/ | ||
| + | |||
| + | これはメインネットワークにおける [[tag/ | ||
| + | |||
| + | ===== 技術要件 ===== | ||
| + | |||
| + | {{.: | ||
| + | |||
| + | [[tag/ | ||
| + | |||
| + | ^ コンポーネント ^ [[tag: | ||
| + | | **RAM** | 最低 16 GB | 最低 64 GB | | ||
| + | | **CPU** | AVX2対応 4コア | AVX2 または AVX512対応 8コア | | ||
| + | | **ネットワーク** | 安定したインターネット接続 | 1 Gbps 推奨 | | ||
| + | | **OS** | Linux | Linux | | ||
| + | |||
| + | 比較として、フルノード([[tag/ | ||
| + | |||
| + | 軽量な代替案により、参入障壁は大幅に下がります。 | ||
| + | |||
| + | ===== 不正行為の防止 ===== | ||
| + | |||
| + | いかなる報酬システムも不正の試みに直面します。[[tag/ | ||
| + | |||
| + | * **リレーおよびプロキシ検出: | ||
| + | * 稼働しているように見せかけて、実際には他のインフラを介してリクエストをルーティングしているノードを特定するメカニズム。 | ||
| + | |||
| + | * **ID 制限: | ||
| + | * 単一のオペレーターIDが登録できるノード数の制限。これにより、一人の参加者が低負荷のインスタンスを大量に作成して不当に報酬を得ることを防ぎます。 | ||
| + | |||
| + | ===== 長期ビジョン:オンチェーンへの移行 ===== | ||
| + | |||
| + | [[tag/ | ||
| + | |||
| + | ロードマップでは、以下の開発を通じて完全なオンチェーン運用を目指しています。 | ||
| + | |||
| + | * **[[tag/ | ||
| + | * 報酬プールと分配ロジックを管理する専用コントラクト。 | ||
| + | |||
| + | * **[[tag: | ||
| + | * Qubic プロトコルインターフェースを通じて、[[tag/ | ||
| + | |||
| + | * **自動分配: | ||
| + | * コントラクトロジックによって完全に処理される報酬計算と支払い。これにより手動プロセスが排除され、透明性が向上します。 | ||
| + | |||
| + | ===== 分散化が重要な理由 ===== | ||
| + | |||
| + | Qubic ネットワークを検証する 676 台の [[tag/ | ||
| + | |||
| + | この[[tag/ | ||
| + | |||
| + | 軽量ノードは合意形成に直接参加しませんが、別の方法でネットワークを強化します。 | ||
| + | |||
| + | * **データの冗長性: | ||
| + | * ネットワークデータを保存・提供するノードが増えるほど、障害や攻撃時の可用性が高まります。 | ||
| + | |||
| + | * **地理的分散: | ||
| + | * ハードウェア要件が下がることで、より多くの場所で運営者が参加可能になり、データセンターへの集中を軽減できます。 | ||
| + | |||
| + | * **クエリ負荷の分散: | ||
| + | * API リクエストやデータクエリを処理するノードが増えることで [[tag/ | ||
| + | |||
| + | * **攻撃耐性: | ||
| + | * ノード数が増えることで、標的を絞った攻撃の実行がより困難かつコスト高になります。 | ||
| + | |||
| + | ===== はじめ方 ===== | ||
| + | |||
| + | [[tag/ | ||
| + | |||
| + | ==== なぜ Docker なのか? ==== | ||
| + | |||
| + | これらのノードは単一の実行ファイルではなく、コアノード、Redis、kvrocks など、連携して動作する必要がある複数のサービスで構成されたシステムです。 | ||
| + | |||
| + | Docker はこのスタック全体を、単一の再現可能なユニットとしてパッケージ化します。 | ||
| + | |||
| + | * **一貫した環境: | ||
| + | * 全ユーザーが同じバージョンを実行でき、設定の齟齬がありません。 | ||
| + | |||
| + | * **依存関係管理が不要: | ||
| + | * Redis や kvrocks の手動インストールが不要です。 | ||
| + | |||
| + | * **シンプルな操作: | ||
| + | * Docker Compose でスタック全体を一括で起動・停止できます。 | ||
| + | |||
| + | ===== ロードマップ:共に築く ===== | ||
| + | |||
| + | ^ フェーズ ^ 予定時期 ^ | ||
| + | | クローズドベータ | 1月末 | | ||
| + | | パブリックローンチ | 2月中旬〜下旬 | | ||
| + | |||
| + | この道のり自体がキャンペーンの一部です。初期参加者からのフィードバックが、最終的な実装、スコアリングの重み、報酬メカニズムを形作ります。 | ||
| + | |||
| + | これは与えられるシステムではなく、共に構築されるインフラです。 | ||
| + | |||
| + | ---- | ||
| + | ===== 結論 ===== | ||
| + | |||
| + | [[tag/ | ||
| + | |||
| + | [[tag/ | ||
| + | |||
| + | {{tag> | ||