official_blog:260119_network_guardians
差分
このページの2つのバージョン間の差分を表示します。
| 次のリビジョン | 前のリビジョン | ||
| official_blog:260119_network_guardians [2026/01/19 11:28] – 作成 d.azuma | official_blog:260119_network_guardians [2026/01/19 20:33] (現在) – d.azuma | ||
|---|---|---|---|
| 行 1: | 行 1: | ||
| - | ====== QUBIC NETWORK GUARDIANS: 分散型ノード運用のための新しいインセンティブ・システム ====== | + | ====== |
| - | 執筆者: Qubic チーム | + | |
| - | 公開日: 2026年1月19日 | + | 原文 [[https:// |
| + | |||
| + | 執筆者: Qubic チーム | ||
| + | |||
| + | {{.: | ||
| **軽量ノードへの報酬を通じて Qubic ネットワークを強化する** | **軽量ノードへの報酬を通じて Qubic ネットワークを強化する** | ||
| 行 7: | 行 11: | ||
| ===== はじめに ===== | ===== はじめに ===== | ||
| - | Qubic ネットワークは、CertiK によって検証された秒間 1,550 万件(TPS)という圧倒的なスピードでその名声を築いてきました。このパフォーマンスの裏側には、ベアメタル・ハードウェア上でプロトコルを直接実行する高性能マシンのネットワークが存在します。このアーキテクチャは効果的である一方、一つの課題を提示していました。それは、ハードウェア要件の高さが、ネットワークの維持に参加できる人々を限定してしまっていた点です。 | + | Qubic ネットワークは、CertiK によって検証された秒間 1,550 万件(TPS)という圧倒的なスピードでその名声を築いてきました。このパフォーマンスの裏側には、[[tag/ベアメタル]]・ハードウェア上でプロトコルを直接実行する高性能マシンのネットワークが存在します。このアーキテクチャは効果的である一方、一つの課題を提示していました。それは、ハードウェア要件の高さが、ネットワークの維持に参加できる人々を限定してしまっていた点です。 |
| + | |||
| + | 「Qubic Network Guardians([[tag/ | ||
| - | 「Qubic Network Guardians(ネットワーク・ガーディアン)」は、この現状を変えるために設計されました。ハードウェア要件の低い軽量ノードの選択肢を導入することで、参入障壁を取り除き、誰もがネットワーク参加を可能にします。参加者が増えることは、より強力で分散化されたネットワークを意味します。 | + | ハードウェア要件の低い軽量ノードの選択肢を導入することで、参入障壁を取り除き、誰もがネットワーク参加を可能にします。参加者が増えることは、より強力で分散化されたネットワークを意味します。 |
| ===== 課題:ネットワーク参加への高い障壁 ===== | ===== 課題:ネットワーク参加への高い障壁 ===== | ||
| - | 現在、Qubic のフルノード(Computor)を運営するには、膨大なリソースが必要です。公式の要件には、AVX2 対応(2027年までに AVX-512 が必須化予定)の 8 コア以上の高周波 CPU(> | + | 現在、Qubic のフルノード([[tag/Computor]])を運営するには、膨大なリソースが必要です。 |
| - | 運営者が少ないことは、冗長性の低下を意味します。ノードが少人数のグループに集中すると、ネットワークは停止や潜在的な中央集権化に対して脆弱になります。これはブロックチェーン設計における既知の緊張関係です。つまり、パフォーマンス要件が、分散型ネットワークの価値である「分散化」を妨げる可能性があるのです。 | + | 公式の要件には、AVX2 対応(2027年までに AVX-512 |
| - | Computor に高いハードウェア要件が課されているのには正当な理由があります。これらのマシンは、Qubic の性能を正当化するスピードでトランザクションを処理し、スマートコントラクトを実行し、合意に達しなければなりません。これらの仕様を下げてしまえば、ネットワークのスループットが損なわれます。解決策は Computor の要件を下げることではなく、貢献するための「追加の方法」を作り出すことでした。 | + | 運営者が少ないことは、冗長性の低下を意味します。ノードが少人数のグループに集中すると、ネットワークは停止や潜在的な中央集権化に対して脆弱になります。これはブロックチェーン設計における既知の緊張関係です。つまり、パフォーマンス要件が、分散型ネットワークの価値である「分散化」を妨げる可能性があるのです。 |
| + | |||
| + | [[tag/Computor]] に高いハードウェア要件が課されているのには正当な理由があります。これらのマシンは、Qubic の性能を正当化するスピードでトランザクションを処理し、スマートコントラクトを実行し、合意に達しなければなりません。これらの仕様を下げてしまえば、ネットワークのスループットが損なわれます。解決策は Computor の要件を下げることではなく、貢献するための「追加の方法」を作り出すことでした。 | ||
| ===== 解決策:軽量ノードへのインセンティブ付与 ===== | ===== 解決策:軽量ノードへのインセンティブ付与 ===== | ||
| - | Network Guardians は、**Bobノード**および**コア・ライトノード**の運用に対して経済的な報酬を導入します。これらの軽量な代替手段は、フル Computor のような極端なハードウェアを必要とせず、ネットワークに有意義な利益をもたらします。 | + | [[tag/ |
| ==== Bobノードとコア・ライトノードとは? ==== | ==== Bobノードとコア・ライトノードとは? ==== | ||
| - | * **Bobノード (Bob Node):** Qubic ブロックチェーン用の高性能インデクサーです。Ethereum と同様の JSON-RPC 2.0 API や、リアルタイムデータストリーミング用の WebSocket サブスクリプションを提供します。取引所の統合や dApp 開発向けに設計されており、残高照会、トランザクション追跡、ログフィルタリング、スマートコントラクト照会などの機能を提供します。 | + | * **[[tag:bob|Bob]]ノード (Bob Node):** |
| - | * **コア・ライトノード (Core Lite Node):** Qubic コアネットワークに接続し、Computor として合意形成に参加することなく、ブロックチェーンデータ(ティック、トランザクション、ログ)を受信・検証する軽量ノードです。重い計算や投票を行うフルノードとは異なり、データのインデックス作成と提供に焦点を当てているため、API、ウォレット、取引所統合の運用に最適です。 | + | |
| + | * Ethereum と同様の JSON-RPC 2.0 API や、リアルタイムデータストリーミング用の WebSocket サブスクリプションを提供します。 | ||
| + | * 取引所の統合や dApp 開発向けに設計されており、残高照会、トランザクション追跡、ログフィルタリング、スマートコントラクト照会などの機能を提供します。 | ||
| + | |||
| + | * **コア・ライトノード ([[tag/Core-Lite]] Node):** | ||
| + | | ||
| + | * 重い計算や投票を行うフルノードとは異なり、データのインデックス作成と提供に焦点を当てているため、API、ウォレット、取引所統合の運用に最適です。 | ||
| + | |||
| + | どちらのノードタイプも、データの可用性を向上させ、冗長性を高め、ネットワーククエリのための追加アクセスポイントを提供することで、ネットワークの健全性に貢献します。 | ||
| + | |||
| + | {{.: | ||
| - | どちらのノードタイプも、データの可用性を向上させ、冗長性を高め、ネットワーククエリのための追加アクセスポイントを提供することで、ネットワークの健全性に貢献します。 | ||
| ===== Network Guardians の仕組み ===== | ===== Network Guardians の仕組み ===== | ||
| - | このプログラムは、「監視」「スコアリング」「報酬」という分かりやすいサイクルで運営されます。 | + | このプログラムは、「監視」「スコアリング」「報酬」という分かりやすいサイクルで運営されます。 |
| ==== ステップ 1: ノードの登録と発見 ==== | ==== ステップ 1: ノードの登録と発見 ==== | ||
| - | 運営者は、自身の Bobノードまたはコア・ライトノードにオペレーターIDと任意の表示名を設定します。システムはネットワークのクローリングとノード通知を通じて、参加ノードを自動的に発見します。適切なノード設定以外に、手動での登録プロセスは必要ありません。 | + | |
| + | 運営者は、自身の Bobノードまたはコア・ライトノードにオペレーターIDと任意の表示名を設定します。 | ||
| + | |||
| + | システムはネットワークのクローリングとノード通知を通じて、参加ノードを自動的に発見します。適切なノード設定以外に、手動での登録プロセスは必要ありません。 | ||
| ==== ステップ 2: 継続的な監視 ==== | ==== ステップ 2: 継続的な監視 ==== | ||
| - | 発見されたノードは継続的な監視対象となります。システムは多角的にパフォーマンスを評価し、運営者が単にソフトウェアをアイドル状態で動かしているのではなく、真にネットワークの健全性に貢献しているかを確認します。 | + | |
| + | 発見されたノードは継続的な監視対象となります。 | ||
| + | |||
| + | システムは多角的にパフォーマンスを評価し、運営者が単にソフトウェアをアイドル状態で動かしているのではなく、真にネットワークの健全性に貢献しているかを確認します。 | ||
| ==== ステップ 3: スコアリング・システム ==== | ==== ステップ 3: スコアリング・システム ==== | ||
| - | ポイントは、実際のネットワーク価値を反映した以下の加重基準に基づいて蓄積されます。 | + | |
| + | ポイントは、実際のネットワーク価値を反映した以下の加重基準に基づいて蓄積されます。 | ||
| ^ メトリクス ^ 重み ^ 測定内容 ^ | ^ メトリクス ^ 重み ^ 測定内容 ^ | ||
| 行 51: | 行 75: | ||
| ==== ステップ 4: 公開リーダーボード ==== | ==== ステップ 4: 公開リーダーボード ==== | ||
| - | すべての参加オペレーターは、累積スコア順にランク付けされた透明なリーダーボードに表示されます。誰でも、誰がどれだけ貢献しているかを検証できます。この可視化は説明責任を生み出し、コミュニティが優れたパフォーマンスを発揮している運営者を認めることを可能にします。 | + | |
| + | すべての参加オペレーターは、累積スコア順にランク付けされた透明なリーダーボードに表示されます。 | ||
| + | |||
| + | 誰でも、誰がどれだけ貢献しているかを検証できます。この可視化は説明責任を生み出し、コミュニティが優れたパフォーマンスを発揮している運営者を認めることを可能にします。 | ||
| ==== ステップ 5: エポックベースの報酬 ==== | ==== ステップ 5: エポックベースの報酬 ==== | ||
| - | QU 報酬は、各エポック(Qubic の週間サイクル)の終了時に、オペレーターのスコアに比例して分配されます。高ランクのオペレーターほど、報酬プールのより大きなシェアを受け取ります。これはメインネットワークにおける Computor 報酬の仕組みと同様のモデルを軽量ノード運営者に拡張したものです。 | + | |
| + | QU 報酬は、各[[tag/エポック]](Qubic の週間サイクル)の終了時に、オペレーターのスコアに比例して分配されます。高ランクのオペレーターほど、報酬プールのより大きなシェアを受け取ります。 | ||
| + | |||
| + | これはメインネットワークにおける | ||
| ===== 技術要件 ===== | ===== 技術要件 ===== | ||
| - | Network Guardians の参加仕様はフルノードの要件を大きく下回りますが、依然として有能なマシンを必要とします。 | + | {{.: |
| - | ^ コンポーネント ^ Bobノード要件 ^ コア・ライトノード要件 ^ | + | [[tag/ |
| + | |||
| + | ^ コンポーネント ^ [[tag:bob|Bob]]ノード要件 ^ [[tag: | ||
| | **RAM** | 最低 16 GB | 最低 64 GB | | | **RAM** | 最低 16 GB | 最低 64 GB | | ||
| | **CPU** | AVX2対応 4コア | AVX2 または AVX512対応 8コア | | | **CPU** | AVX2対応 4コア | AVX2 または AVX512対応 8コア | | ||
| 行 66: | 行 98: | ||
| | **OS** | Linux | Linux | | | **OS** | Linux | Linux | | ||
| - | 比較として、フルノード(Computor)の運用には、8コア以上のベアメタル、AVX-512対応、2TB RAM、および専用サーバーインフラが必要です。軽量な代替案により、参入障壁は大幅に下がります。 | + | 比較として、フルノード([[tag/Computor]])の運用には、8コア以上のベアメタル、AVX-512対応、2TB RAM、および専用サーバーインフラが必要です。 |
| + | |||
| + | 軽量な代替案により、参入障壁は大幅に下がります。 | ||
| ===== 不正行為の防止 ===== | ===== 不正行為の防止 ===== | ||
| - | いかなる報酬システムも不正の試みに直面します。Network Guardians はいくつかの対抗策を計画しています。 | + | いかなる報酬システムも不正の試みに直面します。[[tag/ |
| - | * **リレーおよびプロキシ検出: | + | * **リレーおよびプロキシ検出: |
| - | * **ID 制限:** 単一のオペレーターIDが登録できるノード数の制限。これにより、一人の参加者が低負荷のインスタンスを大量に作成して不当に報酬を得ることを防ぎます。 | + | |
| + | |||
| + | * **ID 制限:** | ||
| + | | ||
| ===== 長期ビジョン:オンチェーンへの移行 ===== | ===== 長期ビジョン:オンチェーンへの移行 ===== | ||
| - | Network Guardians の初期段階は、スマートコントラクトなしで運営されます。報酬の計算は既存のインフラで行われ、分配は確立されたプロセスに従います。 | + | [[tag/ |
| + | |||
| + | ロードマップでは、以下の開発を通じて完全なオンチェーン運用を目指しています。 | ||
| + | |||
| + | * **[[tag/ | ||
| + | * 報酬プールと分配ロジックを管理する専用コントラクト。 | ||
| - | ロードマップでは、以下の開発を通じて完全なオンチェーン運用を目指しています。 | + | * **[[tag: |
| + | * Qubic プロトコルインターフェースを通じて、[[tag/ | ||
| - | * **スマートコントラクトのデプロイ: | + | * **自動分配:** |
| - | * **オラクルマシンとの統合:** Qubic プロトコルインターフェースを通じて、スマートコントラクトを実世界のデータに接続する「オラクルマシン」から提供されるネットワーク統計。 | + | * コントラクトロジックによって完全に処理される報酬計算と支払い。これにより手動プロセスが排除され、透明性が向上します。 |
| - | * **自動分配: | + | |
| ===== 分散化が重要な理由 ===== | ===== 分散化が重要な理由 ===== | ||
| - | Qubic ネットワークを検証する 676 台の Computor は、トランザクションを確定させるためにクォーラム(451 台以上の合意)に達する必要があります。このビザンチン障害耐性(BFT)設計により、一部の検証者が故障したり悪意を持って行動したりしても、ネットワークは機能し続けることができます。 | + | Qubic ネットワークを検証する 676 台の |
| - | 軽量ノードは合意形成に直接参加しませんが、別の方法でネットワークを強化します。 | + | この[[tag/ |
| - | | + | 軽量ノードは合意形成に直接参加しませんが、別の方法でネットワークを強化します。 |
| - | * **地理的分散: | + | |
| - | * **クエリ負荷の分散: | + | |
| - | * **攻撃耐性: | + | |
| + | |||
| + | * **地理的分散: | ||
| + | | ||
| + | |||
| + | * **クエリ負荷の分散: | ||
| + | | ||
| + | |||
| + | * **攻撃耐性: | ||
| + | | ||
| ===== はじめ方 ===== | ===== はじめ方 ===== | ||
| - | Network Guardians はシンプルさを追求して設計されています。Bobノードとコア・ライトノードの両方が **Docker イメージ**として提供され、ほぼワンクリックでのデプロイが可能になります。 | + | [[tag/ |
| ==== なぜ Docker なのか? ==== | ==== なぜ Docker なのか? ==== | ||
| - | これらのノードは単一の実行ファイルではなく、コアノード、Redis、kvrocks など、連携して動作する必要がある複数のサービスで構成されたシステムです。Docker はこのスタック全体を、単一の再現可能なユニットとしてパッケージ化します。 | ||
| - | | + | これらのノードは単一の実行ファイルではなく、コアノード、Redis、kvrocks など、連携して動作する必要がある複数のサービスで構成されたシステムです。 |
| - | * **依存関係管理が不要: | + | |
| - | * **シンプルな操作: | + | Docker はこのスタック全体を、単一の再現可能なユニットとしてパッケージ化します。 |
| + | |||
| + | | ||
| + | | ||
| + | |||
| + | * **依存関係管理が不要: | ||
| + | | ||
| + | |||
| + | * **シンプルな操作: | ||
| + | | ||
| ===== ロードマップ:共に築く ===== | ===== ロードマップ:共に築く ===== | ||
| 行 113: | 行 172: | ||
| | パブリックローンチ | 2月中旬〜下旬 | | | パブリックローンチ | 2月中旬〜下旬 | | ||
| - | この道のり自体がキャンペーンの一部です。初期参加者からのフィードバックが、最終的な実装、スコアリングの重み、報酬メカニズムを形作ります。これは与えられるシステムではなく、共に構築されるインフラです。 | + | この道のり自体がキャンペーンの一部です。初期参加者からのフィードバックが、最終的な実装、スコアリングの重み、報酬メカニズムを形作ります。 |
| + | |||
| + | これは与えられるシステムではなく、共に構築されるインフラです。 | ||
| ---- | ---- | ||
| ===== 結論 ===== | ===== 結論 ===== | ||
| - | Network Guardians は、Qubic のスループットを維持しつつ、分散化の精神をハードウェアの制約から解放する重要なステップです。Computor が「筋肉」であるならば、これら軽量ノードのネットワークは、エコシステム全体にデータを届ける「血管」の役割を果たします。 | + | [[tag/ |
| + | |||
| + | [[tag/Computor]] が「筋肉」であるならば、これら軽量ノードのネットワークは、エコシステム全体にデータを届ける「血管」の役割を果たします。 | ||
| - | {{tag> | + | {{tag> |
official_blog/260119_network_guardians.1768822107.txt.gz · 最終更新: by d.azuma