計算作業に依存してネットワークを保護するNakamoto (2008) のプルーフ・オブ・ワーク（PoW）モデルとは異なり、Qubicのコンセンサスは、ティック（Tick）と取引を確定させるためのComputor間のクォーラム選定と投票に依存しています。このアプローチは、マイナーが暗号パズルを解く必要性を排除し、代わりに分散投票と障害耐性を介して、Computorを通じてセキュリティと回復力を保証します。

Qubicはマイナーの計算能力を役立つAIタスクに活用するために有用なプルーフ・オブ・ワーク（UPoW）に依存していますが、コンセンサスメカニズムは技術的に独立しています。UPoWはネットワークのAI関連の目標に対して計算能力を寄与させるインセンティブを与え、クォーラムベースのコンセンサスはブロックチェーンの状態に関する合意形成に機能します。これら二つを分離することで、QubicはPoWベースのコンセンサスモデルに特有の計算オーバーヘッドを強制することなく、コンセンサスにおける高い効率を達成できます。

このセクションでは、その効果と堅牢性を実証する数学的モデルと証明を含め、Qubic のコンセンサスアルゴリズムをステップバイステップで説明します。

　Qubicのコンセンサスメカニズムは、ビザンチン障害を許容しながら、分散された Computor のセット間で合意を形成するように設計されています。

　このアルゴリズムは、エポック（Epoch）と呼ばれる離散的な期間で動作し、その間に取引が提案、検証、およびブロックチェーンにコミットされます。エポック内には、ティック（Tick）と呼ばれるコンセンサスラウンドの連続したシーケンスがあり、Computorは 独立して取引を検証・実行し、結果についての合意に達します。

主要な構成要素:

• Computor（コンピューター）:
  • 取引の検証、スマートコントラクトの実行、およびコンセンサスへの参加を担当するノードに関連付けられたエンティティです。
• Computor Index（コンピューター・インデックス）:
  • 各Computorは、エポックごとに特定のインデックス（0から675まで）を持ちます。
• Tick（ティック）:
  • 1ラウンドのコンセンサスアルゴリズムで実行および合意される取引のセットであり、スマートコントラクトの状態、Spectrum（スペクトラム）、およびUniverse（ユニバース）のダイジェスト、ならびにティックをシーケンス内で一意に特定する時間情報を含みます。
  • Spectrum と Universe には、現時点での QUBICコインやその他の資産の所有者に関するすべての情報が含まれます。

• 注記:
  • Qubicのソースコードにおいて、1つのティックは特定のComputorによる1つの投票を指します。
• Tick leader（ティックリーダー）:
  • 特定のティックを担当する Computor です。ティックリーダーは、以下の数式でComputorインデックスを計算することで特定できます：
    

    <COMPUTORINDEX> = <TICKNUMBER> % 676

• Quorum（クォーラム）:
  • コンセンサス達成に必要な Computor のサブセットです。Qubicにおけるクォーラムは以下で構成されます：
    

    Q = 451台のComputor（全N = 676台のうち）

• Epochs（エポック）:
  • 複数のティック（コンセンサスラウンド）で構成される、より長い時間間隔（1週間）です。
  • 各エポック中に一連のコンセンサスラウンドが完了し、それらのラウンドの結果に基づいてパフォーマンスや報酬が計算されます。
• TickData（ティックデータ）:
  • ティックに含める取引のダイジェストをアナウンスする、ティックの定義です。ティックリーダーが TickData を作成し、事前にネットワークへ伝播させます。
• Arbitrator（アービトレーター）: セクション3.2.3 に記載されている、紛争解決とネットワークの完全性を維持するためのメカニズムです。

コンセンサスプロセスは以下の通りです：

1. 各 Computor は、0から675までの個別の Computor インデックスで初期化されます。
   • 与えられたティックTに対するティックリーダーは、インデックス C を持つ Computor であり、T modulo 676によって与えられます。すなわち：
     

     C = T % 676

2. ティックリーダーは「TickData」を作成します。
   • これにはスケジュールされた取引の識別子、スマートコントラクトの手数料（contractFees）が含まれ、タイムスタンプ、ティック番号、エポックですべてにマークを付けます。
   • 各取引はそのダイジェスト（KangarooTwelveハッシュ）によって識別されます。
   • 完全なパケットはティックリーダーによって署名され、ネットワークにブロードキャストされます。
   • ブロードキャストの時間は TICK_TRANSACTIONS_PUBLICATION_OFFSET によって定義され、ティックリーダーがどれだけ先のティックのTickDataを送信するかを制御します。
3. ネットワーク内の他のすべての Computor はTickDataを受信し、署名を検証します。
   • TickData は、既知のティックリーダーによって署名されている場合にのみ受け入れられます。
   • 特定の Computor に TickData が時間内に届かない場合、その Computor は自身のバージョン（空のTickData）を使用します。
4. ティックを処理するために、Computor はティックリーダーによって TickData にパックされたすべての取引の完全なデータを持っている必要があります。
   • Computor はすべての取引がローカルに保存されているか確認し、不足している場合は他の Computor に送信を要求します。
   • すべての取引がローカルで利用可能になった後にのみ、続行できます。
5. TickDataが検証され、すべての取引が利用可能かつ検証済みになると、Computor はティックに対する投票を投じます。
6. 各 Computor は他の Computor からの投票を個別に受信します。
   • ティック投票にはティック番号、エポック、Computor インデックス、タイムスタンプ、および送信 Computor の暗号学的状態が含まれます。
   • 理想的には各 Computor は（自身のものを含め）676の投票を確認しますが、受信した投票はクォーラムルールを適用するために内容ごとに継続的にグループ化されます。
   • 少なくとも451の投票が一つのグループで一致した場合、それは「整列した状態（aligned state）」と呼ばれ、Computorは進行に同意します。
   • BFTの原則（Lamport et al., 1982; Castro & Liskov, 1999）に基づき、ネットワークの安定性を維持するために3分の2の多数派にあたる少なくとも 451台の Computor が同じ見解を持ったときにのみ、ネットワークはティックを継続できます。
   • もし 225台を超える Computor が「空のティック」に投票した場合、他のどのグループも451票を超えることはありません。
   • その結果、ネットワークはそのティックをスキップすることを決定し、計画された取引を破棄します（226+ ルール）。
7. 少なくとも4 51台の Computor が投票によってティックの内容に同意（コンセンサス）した場合、ティックが処理され、取引が実行されて次のティックに進みます。
   • もし226台以上が空のティックに投票した場合、取引を実行せずに次のティックに進みます。

故障状態 (Faulty State):

　故障状態は、疑わしい行動をとる Computor をマークするために使用されます。もし Computor [A] が、Computor [B] から送信された2つの異なるバージョンの TickData（またはTickVote）を検知した場合、Computor [A] は Computor [B] を「故障（faulty）」としてマークします。

　アービトレーター（Arbitrator）はこの情報を使用して、故障した Computor を交換する可能性があります。

取引の送信とネットワークへの伝播:

　Qubic の取引は単なるコインの送金に留まらず、スマートコントラクトの実行や Computor 間の通信も促進します。

　他のブロックチェーンと同様に、Qubic の取引は、送信元・送信先アドレス、および送金額といういくつかの必須フィールドで構成されます。これらの標準フィールドに加え、取引を含めたいティック番号を指定する「Tick」フィールド、送信先スマートコントラクトのプロシージャ番号を指定する「InputType」フィールドがあります。「InputData」フィールドは、指定されたスマートコントラクトプロシージャに提供される入力データを提供します。

　ノードにブロードキャストされた取引は、デフォルトで DISSEMINATION_MULTIPLIER パラメータによって設定された通り、追加で6つのノードに伝播されます。

オペレーターによる手動介入:

　投票は次のティックに対しての [YES] / [NO] を意味しますが、オペレーターがカスタムコードを実行していたり、互換性のないハードウェアによるバグがあったりしてノード状態のダイジェストが不一致となった場合、投票が2つ以上のグループに分かれる可能性があります。

コンセンサスに達することができないという万が一の分裂事態においては、ティックの進行を確実にするためにComputorからの手動介入が必要になる場合があります。