プログラマーの観点から見た Neo コンセンサス メカニズム |ネオコラム

メンバーのリストを取得する

Neo ネットワーク ノードには、コンセンサス ノードと通常ノードの 2 種類があります。通常のノードと比較して、コンセンサスノードはコンセンサスプロセスに参加し、新しいブロックの生成を主導するスピーカーになる機会があります。

次に、ソースコード解析を通じてNeoのサーバーを通じて評議員を登録する方法を紹介します。ソース コードでは、ConsensusContext.cs の Reset メソッドが各コンセンサス ラウンドの開始時に呼び出されます。コンセンサスをリセットすると、メンバーのリストを取得するために Blockchain.Default.GetValidators() が呼び出されます。 GetValidators() ソースコードに従います:

ソースコードの場所:

neo/実装/ブロックチェーン/LevelDB/LevelDBBlockChain.cs

ここで、内部の GetValidators(IEnumerable<Transaction> others) メソッドが呼び出されていることがわかります。この内部 GetValidators メソッドを見てください:

ソースコードの場所:

neo/Core/ブロックチェーン.cs

渡されたその他のパラメータは明らかに 0 なので、最初の foreach ループ内のすべてのコードを削除しました。そのため、ループ本体のコードはまったく実行されません。このメソッドの戻り値は result であり、その値データは 2 つのソースから取得されます。 1つ目はpubkeysです。公開キーは、ローカル キャッシュ内の議員情報から取得されます。この情報はブロックチェーンを同期するときに保存されます。つまり、コンセンサスノードがブロック同期のためにブロックチェーンネットワークにアクセスし始めると、コングレスマン情報が取得されます。メンバー情報がキャッシュされていないか失われた場合、組み込みのデフォルトのメンバー リストがコンセンサスに使用され、コンセンサス プロセス中にメンバー情報がキャッシュされます。組み込みのデフォルトのメンバー リストを使用する 2 番目の方法は、構成ファイル protocol.json のデータを StandbyValidators フィールドに直接読み込むことです。

次に、主に1つ目のアプローチについて紹介します。 GetValidators メソッドの 2 行目は GetStates を呼び出し、渡されるクラスの型は ValidatorState です。このメソッドは、LevelDBBlockChain.cs ファイルにあります。完全なコードは次のとおりです。

ソースコードの場所:

neo/実装/ブロックチェーン/LevelDB/LevelDBBlockChain.cs

議員のデータが leveldb データベースから直接読み取られていることがわかります。つまり、データを読み取る前に、まずデータベースを作成して開く必要があります。この操作については、neo-cli プロジェクトを参照してください。このプロジェクトは、MainService クラスの OnStart メソッドでデータベース アドレスを渡します。もちろん、これはデータベースから議員の情報を取得するだけです。評議員情報をデータベースに保存する作業は、主に LevelDBBlockChain.cs ファイルの Persist(Block ブロック) メソッドによって処理されます。このメソッドはブロック タイプをパラメーターとして受け取り、同期されたブロック情報を解析して保存することが主なタスクです。会員情報に関連するキーコードは以下の通りです。

ソースコードの場所:

neo/実装/ブロックチェーン/LevelDB/LevelDBBlockChain.cs/永続化

取得された議員アカウントは、GetAndChange メソッドを呼び出すことによってデータベース キャッシュに追加されます。

スピーカーを決定する

コンセンサス ノードは、ConsensusService クラスの Start メソッドを呼び出すことによってコンセンサスへの参加を開始します。 Start メソッドでは、まずメッセージ受信やデータ保存などのイベント通知を登録し、次に InitializeConsensus を呼び出してコンセンサスを開始し、「ビュー番号」という整数パラメータを受け取ります。渡されたビュー番号が 0 の場合、新しいラウンドのコンセンサスでコンセンサス状態をリセットする必要があります。コンセンサス状態をリセットするコードは次のとおりです。

ソースコードの場所:

コンセンサスコンテキスト

コード内に詳細なコメントを追加しました。スピーカーを決定するアルゴリズムは、現在のブロックの高さ + 1 から現在のビュー番号を引いたもので、その結果は現在のメンバー数を法として、スピーカーのサブスクリプトになります。メンバー自身の番号は、メンバーのリスト内の位置です。このポジションの順序は各メンバーの重みに基づいているため、理論的には、各メンバーの数はすべてのコンセンサス ノードで一貫しています。コンセンサス ノードでは、コンセンサスがリセットされたときにスピーカーが決定されるだけでなく、ローカル ビューが更新されるたびにスピーカーが再決定されます。

ソースコードの場所:

neo/コンセンサス/コンセンサスContex.cs

議長が合意形成を始める

スピーカーがビュー番号を更新した後、新しいブロックが最後に書き込まれた時点からの現在の時間が、各コンセンサス ラウンド間のスケジュールされた間隔 (15 秒) を超えると、新しいコンセンサス ラウンドが直ちに開始されます。それ以外の場合は、間隔後にコンセンサスが開始されます。時間制御コードは次のとおりです。

ソースコードの場所:

neo/コンセンサス/ConsencusService.cs/コンセンサスの初期化

スピーカーが合意に達するために使用する関数は、タイマーによって定期的に実行される OnTimeout です。以下は、スピーカーがコンセンサスを開始するためのコア コードです。

ソースコードの場所:

neo/コンセンカス/コンセンサスサービス.cs/OnTimeOut

スピーカーは、ローカル トランザクションの新しいヘッダーを生成して署名し、PrepareRequest を送信してこのヘッダーをネットワーク内のメンバーにブロードキャストします。

国会議員が合意形成に参加

PrepareRequest ブロードキャストを受信すると、MP は OnPrepareReceived メソッドをトリガーします。

ソースコードの場所:

neo/コンセンサス/コンセンサスサービス.cs

議長からの合意要求を受け取った後、議員はまず議長の公開鍵を使用して、受け取った合意情報を検証します。検証に合格すると、発言者の署名が署名リストに追加されます。次に、スピーカーのヘッダー トランザクション ハッシュ リスト内のトランザクションをメモリ キャッシュからコンテキストに追加します。

ここでは、メモリからコンテキストにトランザクション情報を追加する AddTransaction メソッドについて説明する必要があります。このメソッドは、トランザクションが追加されるたびに、現在のコンテキスト内のトランザクションの数と、スピーカーから取得されたトランザクション ハッシュ番号を比較します。これらが同一であり、アカウント所有者の契約アドレスが検証された場合、その署名がネットワークにブロードキャストされます。この部分のコアコードは次のとおりです。

ソースコードの場所:

neo/コンセンサス/コンセンサスサービス.cs/トランザクションの追加

すべてのメンバーは各コンセンサス ノードの署名を同期する必要があるため、メンバー ノードは、スピーカーのコンセンサス情報に対するネットワーク内の他のノードの応答を監視し、署名情報を記録する必要もあります。コンセンサス応答を受信し、受信した署名情報が記録されるたびに、ノードは CheckSignatures メソッドを呼び出して、現在受信している署名情報が有効かどうかを判断する必要があります。 CheckSignatures コードは次のとおりです。

ソースコードの場所:

neo/コンセンサス/コンセンサスサービス.cs

CheckSignatures メソッドの最初のステップは、現在の署名数の正当性を判断することです。つまり、取得される正当な署名の数は M 以上である必要があります。M の値は ConsensusContext クラスで取得されます。

この値の取得には、Neo コンセンサス アルゴリズムのフォールト トレランスが関係します。式は？ = ⌊ (?−1) / 3 ⌋。つまり、ネットワーク内のコンセンサス ノードの 2/3 以上が一致していれば、結果は信頼できます。つまり、取得された署名の数が正当である限り、現在のノードは既存の情報に基づいて新しいブロックを生成し、それをネットワークにブロードキャストすることができます。

更新を表示

Neo ネットワークのコンセンサス間隔は、ネットワーク全体の計算能力に基づいて各ブロックの生成にかかるおおよその時間を数学的に保証するのではなく、スケジュールされたタスクに基づいています。各ラウンドのコンセンサスは現在選択されているスピーカーによって開始されますが、現在選択されているスピーカーが悪意を持って行動した場合はどうなるでしょうか?話し手がコンセンサスを開始しなかったり、意図的に間違ったコンセンサス情報を開始したりして、このラウンドのコンセンサスを完了できない場合はどうなるでしょうか?

この問題を解決するために、ビューの概念が生まれました。ビューのライフ サイクルが完了したときに、合意に達していない場合、メンバーはブロードキャスト要求を送信して次のビュー サイクルに入り、スピーカーを再選出します。ビューの更新要求の数がメンバー数の 2/3 を超えると、ネットワーク全体が合意に達し、次のビュー サイクルに入り、コンセンサス プロセスを再開します。スピーカー選択アルゴリズムはビュー番号に関連しており、各ビューラウンドで選択されるスピーカーが同じではないことが保証されます。ビューの有効期間は t*2^(view_number+1) です。ここで、t はデフォルトのブロック生成間隔、view_number は現在のビュー番号です。各コンセンサスの開始時に、評議員は 0 番のビュー サイクルに入ります。現在のサイクルが完了したときにコンセンサスに達しなかった場合は、ビュー番号が 1 増加し、次のビュー サイクルに入ります。ビューの有効期間を定義するコードは、ConsensusServer クラスの InitializeConsensus メソッドにあります。

ソースコードの場所:

neo/コンセンサス/コンセンサスサービス.cs/コンセンサスの初期化

ビュー サイクルのラウンドが完了したときに、コンセンサスに達しない場合は、ビューを更新する要求が発行されます。

ソースコードの場所:

neo/コンセンサス/コンセンサスサービス.cs

ビューを更新すると、現在の目的のビューが 1 つ増加し、ビューを更新する要求がすべてのメンバーにブロードキャストされます。ここで注意すべき点は、現在のノードがビューの更新要求を送信した後、ノードの現在のビュー番号は変更されず、予想されるビュー番号のみが変更されることです。ビュー更新のブロードキャストを受信すると、他のメンバーは OnChangeViewReceived メソッドをトリガーして、自身のメンバーの予想されるビュー リストを更新します。

ソースコードの場所:

neo/コンセンサス/コンセンサスサービス.cs

各ビュー更新リクエストを受信した後、現在受信されているリクエストの数が評議員総数の 2/3 を超えているかどうかを確認する必要があります。条件が満たされると、コンセンサス プロセスは新しいビュー サイクルで再開されます。