Epoch 197
文書の過去の版を表示しています。
[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]
[cite_start]Qubic のコンセンサス機構は、ビザンチンフォールトを許容しながら、Computors の分散セット間で合意を達成するように設計されています。 [cite: 612] [cite_start]このアルゴリズムは、エポックと呼ばれる離散的な時間期間で動作し、その間にトランザクションが提案され、検証され、ブロックチェーンにコミットされます。 [cite: 613] [cite_start]エポック中には、ティックと呼ばれる連続的なコンセンサスラウドがあり、Computors はトランザクションを独立して検証および実行し、結果について合意に達します。 [cite: 614]
[cite_start]主要コンポーネント: [cite: 615]
[cite_start]スペクトラムとユニバースには、この時点での QUBIC コインと他の資産を誰がどれだけ所有しているかに関するすべての情報が含まれます。 [cite: 623]
[cite_start]注: Qubic のソースコードでは、Tick は特定の Computor の 1 つの投票です。 [cite: 624]
[cite_start]Tick leader は、その Computor インデックスを計算する次の式によって識別できます: [cite: 626]
[cite_start]$$\langle COMPUTOR INDEX\rangle = \langle TICK NUMBER\rangle \pmod{676}$$ [cite: 627]
Qubic では、クォーラムは以下で構成されます:
qubic whitepaper qubic.org 37
PAGE 39
[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]
