差分

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

--- ホワイトペーパー:v01:4_コンセンサス機構:1:start [2026/01/15 10:07] – [4.1.2 Qubicのクォーラム・コンセンサスアルゴリズム] d.azuma
+++ ホワイトペーパー:v01:4_コンセンサス機構:1:start [2026/01/17 21:27] (現在) – d.azuma
@@ 行 9: / 行 9: @@
 ===== 4.1.1 クォーラムベース・コンセンサスアルゴリズムの概要 =====
-Qubicのコンセンサスメカニズムは、ビザンチン障害を許容しながら、分散されたComputorのセット間で合意を形成するように設計されています。このアルゴリズムは、**エポック（Epoch）**と呼ばれる離散的な期間で動作し、その間に取引が提案、検証、およびブロックチェーンにコミットされます。エポック内には、**ティック（Tick）**と呼ばれるコンセンサスラウンドの連続したシーケンスがあり、Computorは独立して取引を検証・実行し、結果についての合意に達します。
+　Qubicの[[tag:コンセンサスメカニズム]]は、ビザンチン障害を許容しながら、分散された [[tag/Computor]] のセット間で合意を形成するように設計されています。
+　このアルゴリズムは、**[[tag/エポック]]（Epoch）**と呼ばれる離散的な期間で動作し、その間に取引が提案、検証、およびブロックチェーンにコミットされます。エポック内には、**[[tag/ティック]]（Tick）**と呼ばれるコンセンサスラウンドの連続したシーケンスがあり、Computorは 独立して取引を検証・実行し、結果についての合意に達します。
 **主要な構成要素:**
-  * **Computor（コンピューター）**: 取引の検証、スマートコントラクトの実行、およびコンセンサスへの参加を担当するノードに関連付けられたエンティティです。
+  * **[[tag/Computor]]（コンピューター）**:
-  * **Computor Index（コンピューター・インデックス）**: 各Computorは、エポックごとに特定のインデックス（0から675まで）を持ちます。
+    * 取引の検証、スマートコントラクトの実行、およびコンセンサスへの参加を担当するノードに関連付けられたエンティティです。
-  * **Tick（ティック）**: 1ラウンドのコンセンサスアルゴリズムで実行および合意される取引のセットであり、スマートコントラクトの状態、**Spectrum（スペクトラム）**、および**Universe（ユニバース）**のダイジェスト、ならびにティックをシーケンス内で一意に特定する時間情報を含みます。SpectrumとUniverseには、現時点でのQUBICコインやその他の資産の所有者に関するすべての情報が含まれます。
-  * **注記**: Qubicのソースコードにおいて、1つのティックは特定のComputorによる1つの投票を指します。
+  * **Computor Index（コンピューター・インデックス）**:
-  * **Tick leader（ティックリーダー）**: 特定のティックを担当するComputorです。ティックリーダーは、以下の数式でComputorインデックスを計算することで特定できます：\\ <code><COMPUTORINDEX> = <TICKNUMBER> % 676</code>
+    * 各Computorは、エポックごとに特定のインデックス（0から675まで）を持ちます。
-  * **Quorum（クォーラム）**: コンセンサス達成に必要なComputorのサブセットです。Qubicにおけるクォーラムは以下で構成されます：\\ <code>Q = 451台のComputor（全N = 676台のうち）</code>
-  * **Epochs（エポック）**: 複数のティック（コンセンサスラウンド）で構成される、より長い時間間隔（1週間）です。各エポック中に一連のコンセンサスラウンドが完了し、それらのラウンドの結果に基づいてパフォーマンスや報酬が計算されます。
+  * **Tick（[[tag/ティック]]）**:
-  * **TickData（ティックデータ）**: ティックに含める取引のダイジェストをアナウンスする、ティックの定義です。ティックリーダーがTickDataを作成し、事前にネットワークへ伝播させます。
+    * 1ラウンドのコンセンサスアルゴリズムで実行および合意される取引のセットであり、スマートコントラクトの状態、**Spectrum（スペクトラム）**、および**Universe（ユニバース）**のダイジェスト、ならびにティックをシーケンス内で一意に特定する時間情報を含みます。
-  * **Arbitrator（アービトレイター）**: セクション3.2.3（訳注：ソース参照）に記載されている、紛争解決とネットワークの完全性を維持するためのメカニズムです。
+    * Spectrum と Universe には、現時点での QUBICコインやその他の資産の所有者に関するすべての情報が含まれます。
+    * **注記**:
+      * Qubicのソースコードにおいて、1つのティックは特定の Computorによる1つの投票を指します。
+  * **Tick leader（ティックリーダー）**:
+    * 特定のティックを担当する Computor です。ティックリーダーは、以下の数式でComputorインデックスを計算することで特定できます：\\ <code><COMPUTORINDEX> = <TICKNUMBER> % 676</code>
+  * **Quorum（[[tag/クォーラム]]）**:
+    * コンセンサス達成に必要な Computor のサブセットです。Qubicにおけるクォーラムは以下で構成されます：\\ <code>Q = 451台のComputor（全N = 676台のうち）</code>
+  * **Epochs（[[tag/エポック]]）**:
+    * 複数のティック（コンセンサスラウンド）で構成される、より長い時間間隔（1週間）です。
+    * 各エポック中に一連のコンセンサスラウンドが完了し、それらのラウンドの結果に基づいてパフォーマンスや報酬が計算されます。
+  * **TickData（ティックデータ）**:
+    * ティックに含める取引のダイジェストをアナウンスする、ティックの定義です。ティックリーダーが TickData を作成し、事前にネットワークへ伝播させます。
+  * **Arbitrator（[[tag/アービトレーター]]）**: [[../../3_システムアーキテクチャ/2/|セクション3.2.3]] に記載されている、紛争解決とネットワークの完全性を維持するためのメカニズムです。
 ===== 4.1.2 Qubicのクォーラム・コンセンサスアルゴリズム =====
@@ 行 26: / 行 45: @@
 コンセンサスプロセスは以下の通りです：
-  -  各 Computor は、0から675までの個別の Computor インデックスで初期化されます。
+  -  各 [[tag/Computor]] は、0から675までの個別の Computor インデックスで初期化されます。
-    * 与えられたティックTに対するティックリーダーは、インデックスCを持つComputorであり、T modulo 676によって与えられます。すなわち：\\ <code>C = T % 676</code>
+    * 与えられたティックTに対するティックリーダーは、インデックス C を持つ Computor であり、T modulo 676によって与えられます。すなわち：\\ <code>C = T % 676</code>
   -  ティックリーダーは「TickData」を作成します。
     * これにはスケジュールされた取引の識別子、スマートコントラクトの手数料（contractFees）が含まれ、タイムスタンプ、ティック番号、エポックですべてにマークを付けます。
-    * 各取引はそのダイジェスト（KangarooTwelveハッシュ）によって識別されます。
+    * 各取引はそのダイジェスト（[[tag/KangarooTwelve]]ハッシュ）によって識別されます。
     * 完全なパケットはティックリーダーによって署名され、ネットワークにブロードキャストされます。
     * ブロードキャストの時間は ''TICK_TRANSACTIONS_PUBLICATION_OFFSET'' によって定義され、ティックリーダーがどれだけ先のティックのTickDataを送信するかを制御します。
   -  ネットワーク内の他のすべての Computor はTickDataを受信し、署名を検証します。
-    * TickDataは、既知のティックリーダーによって署名されている場合にのみ受け入れられます。
+    * TickData は、既知のティックリーダーによって署名されている場合にのみ受け入れられます。
-    * 特定の Computo rに TickData が時間内に届かない場合、そのComputorは自身のバージョン（空のTickData）を使用します。
+    * 特定の Computor に TickData が時間内に届かない場合、その Computor は自身のバージョン（空のTickData）を使用します。
   -  ティックを処理するために、Computor はティックリーダーによって TickData にパックされたすべての取引の完全なデータを持っている必要があります。
     * Computor はすべての取引がローカルに保存されているか確認し、不足している場合は他の Computor に送信を要求します。
     * すべての取引がローカルで利用可能になった後にのみ、続行できます。
-  -  TickDataが検証され、すべての取引が利用可能かつ検証済みになると、Computorはティックに対する投票を投じます。
+  -  TickDataが検証され、すべての取引が利用可能かつ検証済みになると、Computor はティックに対する投票を投じます。
   -  各 Computor は他の Computor からの投票を個別に受信します。
-    * ティック投票にはティック番号、エポック、Computorインデックス、タイムスタンプ、および送信 Computor の暗号学的状態が含まれます。
+    * ティック投票にはティック番号、エポック、Computor インデックス、タイムスタンプ、および送信 Computor の暗号学的状態が含まれます。
     * 理想的には各 Computor は（自身のものを含め）676の投票を確認しますが、受信した投票はクォーラムルールを適用するために内容ごとに継続的にグループ化されます。
     * 少なくとも**451の投票**が一つのグループで一致した場合、それは「整列した状態（aligned state）」と呼ばれ、Computorは進行に同意します。
@@ 行 52: / 行 71: @@
 **故障状態 (Faulty State):**\\
-故障状態は、疑わしい行動をとる Computor をマークするために使用されます。もし Computor [A] が、Computor [B] から送信された2つの異なるバージョンの TickData（またはTickVote）を検知した場合、Computor [A] は Computor [B] を「故障（faulty）」としてマークします。[[tag:アービトレーター|]]（Arbitrator）はこの情報を使用して、故障したComputor を交換する可能性があります。
+　故障状態は、疑わしい行動をとる Computor をマークするために使用されます。もし Computor [A] が、Computor [B] から送信された2つの異なるバージョンの TickData（またはTickVote）を検知した場合、Computor [A] は Computor [B] を「故障（faulty）」としてマークします。
+　[[tag:アービトレーター|]]（Arbitrator）はこの情報を使用して、故障した Computor を交換する可能性があります。
 **取引の送信とネットワークへの伝播:**\\
@@ 行 64: / 行 85: @@
 **オペレーターによる手動介入:**\\
-　投票は次のティックに対しての [YES] / [NO] を意味しますが、オペレーターがカスタムコードを実行していたり、互換性のないハードウェアによるバグがあったりしてノード状態のダイジェストが不一致となった場合、投票が2つ以上のグループに分かれる可能性があります。
+　投票は次のティックに対しての [YES] / [NO] を意味しますが、オペレーターがカスタムコードを実行していたり、互換性のないハードウェアによるバグがあったりしてノード状態のダイジェストが不一致となった場合、投票が 2つ以上のグループに分かれる可能性があります。
-コンセンサスに達することができないという万が一の分裂事態においては、ティックの進行を確実にするためにComputorからの手動介入が必要になる場合があります。
+　コンセンサスに達することができないという万が一の分裂事態においては、ティックの進行を確実にするために Computor からの手動介入が必要になる場合があります。
+{{tag>エポック クォーラム ティック }}