ユーザ用ツール

サイト用ツール


qubic:ホワイトペーパー:4_コンセンサス機構:1:start

差分

このページの2つのバージョン間の差分を表示します。

この比較画面へのリンク

qubic:ホワイトペーパー:4_コンセンサス機構:1:start [2025/12/01 20:58] – 作成 d.azumaqubic:ホワイトペーパー:4_コンセンサス機構:1:start [2026/01/15 08:39] (現在) – [4.1 詳細なプロトコル説明] d.azuma
行 1: 行 1:
-====== 4.1 詳細なプロトコル説明 ====== 
- 
- 
-[cite_start]ネットワークを保護するために**計算作業に依存**する Nakamoto の (2008) プルーフ・オブ・ワークモデルとは異なり、Qubic のコンセンサスは、**ティックとトランザクションを確定するために、Computors 間のクォーラム選択と投票**に依存しています。 [cite: 605] 
-[cite_start]このアプローチは、**マイナーが暗号パズルを解く必要性を排除**し、代わりに**分散型投票と耐障害性**を通じて **Computors を介してセキュリティと回復力**を保証します。 [cite: 606] 
- 
-[cite_start]Qubic は、**有用な AI タスクのためにマイナーの計算能力を活用**するために **有用なプルーフ・オブ・ワーク (UPoW)** に依存していますが、**コンセンサス機構は技術的に独立**しています。 [cite: 607] 
-[cite_start]UPoW は、ネットワークの**AI 関連の目標のための計算能力の貢献**をインセンティブ化し、**クォーラムベースのコンセンサスは、ブロックチェーンの状態に関する合意に達すること**に機能します。 [cite: 608] 
-[cite_start]この 2 つの分離により、Qubic は、PoW ベースのコンセンサスモデルを特徴づけることが多い**計算オーバーヘッドを強制することなく**、**コンセンサスにおける高い効率**を達成できます。 [cite: 609] 
- 
-[cite_start]このセクションでは、Qubic のコンセンサスアルゴリズムの**ステップバイステップのウォークスルー**を提示し、**その有効性と堅牢性**を実証する**数学モデルと証明**を含めます。 [cite: 610] 
- 
-====4.1.1 クォーラムベースのコンセンサスアルゴリズムの概要==== 
- 
-[cite_start]Qubic のコンセンサス機構は、**ビザンチンフォールトを許容しながら、Computors の分散セット間で合意を達成**するように設計されています。 [cite: 612] 
-[cite_start]このアルゴリズムは、**エポック**と呼ばれる**離散的な時間期間**で動作し、その間に**トランザクションが提案され、検証され、ブロックチェーンにコミット**されます。 [cite: 613] 
-[cite_start]エポック中には、**ティック**と呼ばれる**連続的なコンセンサスラウド**があり、Computors は**トランザクションを独立して検証および実行**し、**結果について合意**に達します。 [cite: 614] 
- 
-[cite_start]**主要コンポーネント**: [cite: 615] 
- 
-  * [cite_start]**Computors**: **トランザクションの検証、スマートコントラクトの実行、およびコンセンサスへの参加**を担当するノードに関連付けられたエンティティ。 [cite: 619] 
-  * [cite_start]**Computor Index**: 各 Computor は、エポックごとに**独自のインデックス**を持ちます。インデックスは **0 から 675** までです。 [cite: 620] 
-  * [cite_start]**Tick**: **コンセンサスアルゴリズムの 1 ラウンドで実行され、合意されるトランザクションのセット**であり、**スマートコントラクト、スペクトラム、およびユニバースの状態のダイジェスト**、ならびに**ティックをティックのシーケンス内で一意に識別する時間情報**が含まれます。 [cite: 621, 622] 
-    [cite_start]**スペクトラムとユニバース**には、**この時点での QUBIC コインと他の資産を誰がどれだけ所有しているか**に関するすべての情報が含まれます。 [cite: 623] 
- 
-> [cite_start]注: Qubic のソースコードでは、**Tick は特定の Computor の 1 つの投票**です。 [cite: 624] 
- 
-  * [cite_start]**Tick leader**: **特定のティックを担当する Computor**。 [cite: 625] 
-    [cite_start]Tick leader は、**その Computor インデックスを計算する**次の式によって識別できます: [cite: 626] 
- 
-[cite_start]$$\langle COMPUTOR INDEX\rangle = \langle TICK NUMBER\rangle \pmod{676}$$ [cite: 627] 
- 
-  * [cite_start]**Quorum**: **コンセンサスに達するために必要な Computors のサブセット**。 [cite: 628] 
-    Qubic では、クォーラムは以下で構成されます: 
-    * [cite_start]**Q = 451 Computors** (合計 $N=676$ のうち) [cite: 629] 
-  * [cite_start]**Epochs**: **複数のティック (コンセンサスラウンド) で構成される、より広範な時間間隔** (1 週間)。 [cite: 630] [cite_start]各エポック中に、**一連のコンセンサスラウンドが完了**し、これらのラウンドの結果に基づいて**パフォーマンスまたは報酬が計算**されます。 [cite: 631] 
-  * [cite_start]**TickData**: **ティックの定義**であり、**ティックに含まれるトランザクションのダイジェスト**を発表します。 [cite: 632] [cite_start]**Tick leader** は **TickData を作成**し、**ネットワークに事前に TickData を伝播**します。 [cite: 633, 634] 
-  * [cite_start]**Arbitrator**: **セクション 3.2.3** で説明されているように、**紛争解決とネットワークの整合性の維持のためのメカニズム**。 [cite: 635] 
- 
-qubic whitepaper 
-qubic.org 
-37 
- 
-//PAGE 39// 
- 
-====4.1.2 Qubic のクォーラムコンセンサスアルゴリズム==== 
- 
-[cite_start]コンセンサスプロセスは、次のように概説できます: [cite: 640] 
- 
-1. [cite_start]**各 Computor** は、**0 から 675 までの範囲の個別の Computor インデックスで初期化**されます。 [cite: 641] 
-[cite_start]特定のティック $T$ の **tick leader** は、**$T$ モジュロ 676 によって与えられるインデックス $C$** を持つ Computor です。すなわち: [cite: 641] 
- 
-[cite_start]例: [cite: 642] 
-* [cite_start]Tick: 15104383 [cite: 643] 
-* [cite_start]ComputorIndex: 515 [cite: 644] 
-* [cite_start]これにより、以下に解決されます: [cite: 645] 
- 
-[cite_start]$$C = T \pmod{676}$$ [cite: 646] 
-[cite_start]$$C = 15104383 \pmod{676} = 515$$ [cite: 647] 
- 
-2. [cite_start]**Tick leader は "TickData" を作成**します。 [cite: 648] 
-[cite_start]スケジュールされた**トランザクションの識別子**、**contractFees** をパックし、**タイムスタンプ、ティック番号、およびエポック**ですべてをマークします。 [cite: 649] 
-[cite_start]各トランザクションは、**トランザクションの Kangaroo Twelve ハッシュ**である**そのダイジェスト**によって識別されます。 [cite: 650] 
-[cite_start]**完全なパケットは tick leader によって署名**され、**ネットワークにブロードキャスト**されます。 [cite: 651] 
-[cite_start]**ブロードキャストの時間**は、**TICK\_TRANSACTIONS\_PUBLICATION\_OFFSET** によって定義されます。 [cite: 652] 
-[cite_start]このパラメータは、**tick leader が TickData を送信するティックの数**を制御します。 [cite: 653] 
- 
-3. [cite_start]ネットワーク内の**他のすべての Computors** は **TickData を受信し、署名を検証**します。 [cite: 654] 
-[cite_start]**既知の tick leader Computor によって署名されている場合**にのみ受け入れられます。 [cite: 655] 
-[cite_start]TickData が**特定の Computor に時間内に到着しない場合**、この特定の Computor は**独自のバージョン**を使用します。これは "**空**" になります (TickData なし)。 [cite: 656] 
- 
-4. [cite_start]ティックを処理するために、Computors は、**tick leader によって TickData にパックされたすべてのトランザクションの完全なデータ**を持っている必要があります。 [cite: 657] 
-[cite_start]Computor は、**すべてのトランザクションがすでにローカルに保存されているかどうか**をチェックし、**1 つ以上が欠落している場合**は、**他の Computors にそれらのトランザクションを送信するように要求**します。 [cite: 661] 
-[cite_start]Computor は、**すべてのトランザクションがローカルで利用可能である場合にのみ続行**できます。 [cite: 662] 
- 
-5. [cite_start]**TickData が検証され**、**すべてのトランザクションが利用可能で検証されている**場合、Computor は**ティックに投票**します。 [cite: 663] 
- 
-qubic whitepaper 
-qubic.org 
-38 
- 
-//PAGE 40// 
- 
-6. [cite_start]**すべての Computor** は、**他の Computors からの投票を個別に受信**します。 [cite: 664] 
-[cite_start]ティック投票には、**ティック番号、エポック、Computor インデックス、タイムスタンプ、および送信側 Computor の暗号学的状態**が含まれます。 [cite: 665] 
-[cite_start]理想的には、**各 Computor は 676 の投票** (自身の投票を含む) を確認します。 [cite: 666] 
-[cite_start]しかし、受信した投票は、**クォーラムルールを適用するために、そのコンテンツによって継続的にグループ化**されます。 [cite: 666] 
-[cite_start]**少なくとも 451 の投票が 1 つのグループで連携している場合**、それは "**連携状態**" と呼ばれ、Computors は**続行することに同意**します。 [cite: 667] 
-Lamport et al. (1982) [cite_start]によって概説され、後に Castro and Liskov (1999) によって採用された**ビザンチン耐障害性 (BFT) の原則**によると、**ネットワークが安定性を維持するために 3 分の 2 の過半数を達成**し、**少なくとも 451 の Computors が同じ見解を持っている場合**にのみ、ネットワークは**ティックを継続**できます。 [cite: 668, 669] 
-[cite_start]**225 を超える Computors が空のティックに投票した場合**、**他のグループは 451 の投票を超えることはありません**。 [cite: 670] 
-[cite_start]その結果、ネットワークは**そのティックをスキップすることを決定**し、**計画されたトランザクションを破棄**します (**226+ ルール**)。 [cite: 671] 
- 
-7. [cite_start]**少なくとも 451 の Computors がそのティックのコンテンツについて合意** (コンセンサス) した**場合**、ティックは**処理**され、**トランザクションが実行**され、**次のティックに進みます**。 [cite: 672] 
-[cite_start]**226 以上の Computors が空のティックに投票した場合**、Computors は**トランザクションを実行せずに次のティックに進みます**。 [cite: 673] 
- 
-[cite_start]**障害のある状態** [cite: 674] 
- 
-[cite_start]**障害のある状態**は、**疑わしい行動を実行する Computors をマーク**するために使用されます。 [cite: 678] 
-[cite_start]**Computor A が Computor B から TickData (または TickVote) の 2 つの異なるバージョンを検出した場合**、Computor A は**Computor B を障害のあるものとしてマーク**します。 [cite: 679] 
-[cite_start]**Arbitrator** は、**障害のある Computors を潜在的に置き換える**ために、この情報を使用します。 [cite: 680] 
- 
-[cite_start]**トランザクションがネットワーク全体で送信および伝播される方法** [cite: 681] 
- 
-[cite_start]Qubic トランザクションは、**単純なコイン転送に限定されません**。それらは、**スマートコントラクトの実行**または**Computors 間の通信**も容易にします。 [cite: 682] 
-[cite_start]他のブロックチェーンと同様に、Qubic トランザクションは、**送信元と宛先のアドレス、および転送される金額**など、いくつかの**不可欠なフィールド**で構成されています。 [cite: 683] 
-[cite_start]これらの標準フィールドに加えて、Qubic トランザクションには、**トランザクションの包含のために望ましいティック番号**を指定する "**Tick**" フィールドと、**宛先スマートコントラクトのプロシージャ番号**を指定する "**InputType**" フィールドがあります。 [cite: 684] 
-[cite_start]"**InputData**" フィールドは、**指定されたスマートコントラクトプロシージャに提供される入力データ**を提供します。 [cite: 685] 
- 
-[cite_start]ノードにブロードキャストされたトランザクションは、**DISSEMINATION\_MULTIPLIER パラメータ**によって構成されているように、**デフォルトで 6 つの追加ノードに伝播**されます。 [cite: 686] 
- 
-[cite_start]**オペレーターからの手動介入** [cite: 687] 
- 
-[cite_start]投票は単に次のティックに対する YES/NO を意味しますが、**オペレーターがカスタムコードを実行したり**、**互換性のないハードウェアからのバグ**のために**ノードの状態ダイジェストが一致しない場合**は、**投票が 2 つ以上のグループに分割される可能性**があります。 [cite: 688] 
-[cite_start]**コンセンサスに到達できない**という**ありそうもないイベント**では、**ティックの進行を確実にするために Computors からの手動介入が必要**になる場合があります。 [cite: 689] 
  
qubic/ホワイトペーパー/4_コンセンサス機構/1/start.1764622733.txt.gz · 最終更新: by d.azuma