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