差分

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

--- ホワイトペーパー:v01:4_コンセンサス機構:start [2026/01/15 08:41] – d.azuma
+++ ホワイトペーパー:v01:4_コンセンサス機構:start [2026/01/17 21:27] (現在) – d.azuma
@@ 行 1: / 行 1: @@
 ====== 4 コンセンサスメカニズム (CONSENSUS MECHANISM) ======
-Qubicネットワークにおいて最も重要な要素の一つは、**Computor（コンピューター）**がブロックチェーンの状態に合意し、安全かつ効率的な方法で取引の処理を可能にするコンセンサスメカニズムです。Qubicは、セクション2.2（訳注：ホワイトペーパー内表記。ソース参照）で概説したように、**ビザンチン障害耐性（BFT）**を備えたクォーラムベースのコンセンサスメカニズムを使用しています。以下のセクションでは、詳細なプロトコルの記述とコンセンサスメカニズムのセキュリティ分析を行います。
-**ビザンチン障害耐性（BFT）とは何か？**\\
+{{indexmenu>./#2}}
-ビザンチン障害耐性（BFT）は、一部のノードが悪意を持って行動した場合でもネットワークが機能し続けることを可能にするセキュリティモデルです。QubicはクォーラムベースのコンセンサスにBFTを採用しており、ノードの最大3分の1が故障したり悪意を持って行動したりしても、セキュリティと信頼性を強化します。詳細な解説については、Lamport et al. (1982) を参照してください。
-==== 4.1 プロトコルの詳細説明 (Detailed Protocol Description) ====
+Qubic ネットワークにおいて最も重要な要素の一つは、**[[tag/Computor]]（コンピューター）**がブロックチェーンの状態に合意し、安全かつ効率的な方法で取引の処理を可能にする[[tag:コンセンサスメカニズム]]です。
-計算作業に依存してネットワークを保護するNakamoto (2008) のプルーフ・オブ・ワーク（PoW）モデルとは異なり、Qubicのコンセンサスは、ティック（Tick）と取引を確定させるためのComputor間の**クォーラム選定と投票**に依存しています。このアプローチは、マイナーが暗号パズルを解く必要性を排除し、代わりに分散投票と障害耐性を介して、Computorを通じてセキュリティと回復力を保証します。
-Qubicはマイナーの計算能力を役立つAIタスクに活用するために**有用なプルーフ・オブ・ワーク（UPoW）**に依存していますが、コンセンサスメカニズムは技術的に独立しています。UPoWはネットワークのAI関連の目標に対して計算能力を寄与させるインセンティブを与え、クォーラムベースのコンセンサスはブロックチェーンの状態に関する合意形成に機能します。これら二つを分離することで、QubicはPoWベースのコンセンサスモデルに特有の計算オーバーヘッドを強制することなく、コンセンサスにおける高い効率を達成できます。
+Qubicは、[[tag/../2/2/|セクション2.2]] で概説したように、**[[tag/ビザンチン障害耐性]]（BFT）**を備えた[[tag/クォーラム]]ベースの[[tag:コンセンサスメカニズム]]を使用しています。以下のセクションでは、詳細なプロトコルの記述と[[tag:コンセンサスメカニズム]]のセキュリティ分析を行います。
-このセクションでは、その効果と堅牢性を実証する数学的モデルと証明を含め、Qubicのコンセンサスアルゴリズムをステップバイステップで説明します。
+**[[tag/ビザンチン障害耐性]]（BFT）とは何か？**\\
-=== 4.1.1 クォーラムベース・コンセンサスアルゴリズムの概要 ===
+ビザンチン障害耐性（BFT）は、一部のノードが悪意を持って行動した場合でもネットワークが機能し続けることを可能にするセキュリティモデルです。
-Qubicのコンセンサスメカニズムは、ビザンチン障害を許容しながら、分散されたComputorのセット間で合意を形成するように設計されています。このアルゴリズムは、**エポック（Epoch）**と呼ばれる離散的な期間で動作し、その間に取引が提案、検証、およびブロックチェーンにコミットされます。エポック内には、**ティック（Tick）**と呼ばれるコンセンサスラウンドの連続したシーケンスがあり、Computorは独立して取引を検証・実行し、結果についての合意に達します。
-**主要な構成要素:**
+Qubic はクォーラムベースのコンセンサスにBFTを採用しており、ノードの最大3分の1が故障したり悪意を持って行動したりしても、セキュリティと信頼性を強化します。詳細な解説については、Lamport et al. (1982) を参照してください。
-  * **Computor（コンピューター）**: 取引の検証、スマートコントラクトの実行、およびコンセンサスへの参加を担当するノードに関連付けられたエンティティです。
-  * **Computor Index（コンピューター・インデックス）**: 各Computorは、エポックごとに特定のインデックス（0から675まで）を持ちます。
-  * **Tick（ティック）**: 1ラウンドのコンセンサスアルゴリズムで実行および合意される取引のセットであり、スマートコントラクトの状態、**Spectrum（スペクトラム）**、および**Universe（ユニバース）**のダイジェスト、ならびにティックをシーケンス内で一意に特定する時間情報を含みます。SpectrumとUniverseには、現時点でのQUBICコインやその他の資産の所有者に関するすべての情報が含まれます。
-  * **注記**: Qubicのソースコードにおいて、1つのティックは特定のComputorによる1つの投票を指します。
-  * **Tick leader（ティックリーダー）**: 特定のティックを担当するComputorです。ティックリーダーは、以下の数式でComputorインデックスを計算することで特定できます：\\ <code><COMPUTORINDEX> = <TICKNUMBER> % 676</code>
-  * **Quorum（クォーラム）**: コンセンサス達成に必要なComputorのサブセットです。Qubicにおけるクォーラムは以下で構成されます：\\ <code>Q = 451台のComputor（全N = 676台のうち）</code>
-  * **Epochs（エポック）**: 複数のティック（コンセンサスラウンド）で構成される、より長い時間間隔（1週間）です。各エポック中に一連のコンセンサスラウンドが完了し、それらのラウンドの結果に基づいてパフォーマンスや報酬が計算されます。
-  * **TickData（ティックデータ）**: ティックに含める取引のダイジェストをアナウンスする、ティックの定義です。ティックリーダーがTickDataを作成し、事前にネットワークへ伝播させます。
-  * **Arbitrator（アービトレイター）**: セクション3.2.3（訳注：ソース参照）に記載されている、紛争解決とネットワークの完全性を維持するためのメカニズムです。
-=== 4.1.2 Qubicのクォーラム・コンセンサスアルゴリズム ===
-コンセンサスプロセスは以下の通りです：
-  - 1. 各Computorは、0から675までの個別のComputorインデックスで初期化されます。与えられたティックTに対するティックリーダーは、インデックスCを持つComputorであり、T modulo 676によって与えられます。すなわち：\\ <code>C = T % 676</code>
-  - 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. 少なくとも451台の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からの手動介入が必要になる場合があります。
@@ 行 51: / 行 19: @@
+----
+{{page>/include/wp01-footer}}
 {{tag>コンセンサス  クォーラム computor }}