特開 2024-54815 ステートマシンレプリケーションのための２段階ビザンチン合意方法およびシステム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2024054815

(43)【公開日】2024-04-17

(54)【発明の名称】ステートマシンレプリケーションのための２段階ビザンチン合意方法およびシステム

(51)【国際特許分類】

   G06F 11/18 20060101AFI20240410BHJP

【ＦＩ】

G06F11/18 620

【審査請求】未請求

【請求項の数】17

【出願形態】ＯＬ

(21)【出願番号】P 2022208947

(22)【出願日】2022-12-26

(31)【優先権主張番号】10-2022-0127135

(32)【優先日】2022-10-05

(33)【優先権主張国・地域又は機関】KR

(71)【出願人】

【識別番号】515276668

【氏名又は名称】アイユーシーエフ－エイチワイユー（インダストリー－ユニバーシティ コーオペレーション ファウンデーション ハンヤン ユニバーシティ）

【氏名又は名称原語表記】ＩＵＣＦ－ＨＹＵ （ＩＮＤＵＳＴＲＹ－ＵＮＩＶＥＲＳＩＴＹ ＣＯＯＰＥＲＡＴＩＯＮ ＦＯＵＮＤＡＴＩＯＮ ＨＡＮＹＡＮＧ ＵＮＩＶＥＲＳＩＴＹ）

(74)【代理人】

【識別番号】110001519

【氏名又は名称】弁理士法人太陽国際特許事務所

(72)【発明者】

【氏名】ユ・ミンス

【テーマコード（参考）】

5B034

【Ｆターム（参考）】

5B034AA04

5B034CC01

(57)【要約】

【課題】ステートマシンレプリケーションのための２段階ビザンチン合意方法およびシステムを開示する。
【解決手段】一実施形態に係る合意システムによって実行される合意方法は、同意プロトコル（Ａｇｒｅｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ）にしたがい、クライアント要請に対してプライマリ（ｐｒｉｍａｒｙ）に指定されたプロセスが提案する処理番号（ｓｅｑｕｅｎｃｅ ｎｕｍｂｅｒ）をすべての正常なプロセスが合意を進める段階、およびビューチェンジプロトコル（Ｖｉｅｗ Ｃｈａｎｇｅ Ｐｒｏｔｏｃｏｌ）にしたがい、プライマリにビザンチン（Ｂｙｚａｎｔｉｎｅ）が疑われるときにプライマリを代替する段階を含む。
【選択図】図２

【特許請求の範囲】

【請求項1】

合意システムによって実行される合意方法であって、
同意プロトコル（Ａｇｒｅｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ）にしたがい、クライアント要請に対してプライマリ（ｐｒｉｍａｒｙ）に指定されたプロセスが提案する処理番号（ｓｅｑｕｅｎｃｅ ｎｕｍｂｅｒ）をすべての正常なプロセスが合意を進める段階、および
ビューチェンジプロトコル（Ｖｉｅｗ Ｃｈａｎｇｅ Ｐｒｏｔｏｃｏｌ）にしたがい、プライマリにビザンチン（Ｂｙｚａｎｔｉｎｅ）が疑われるときにプライマリを交換する段階
を含む、合意方法。

【請求項2】

前記同意プロトコル（Ａｇｒｅｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ）にしたがって合意を進める段階は、前記プライマリが準備メッセージを前記プロセスに送信して処理する準備（Ｐｒｅｐａｒｅ）段階、および
前記プロセスの各プロセスが実行メッセージを交換して処理する実行（Ｅｘｅｃｕｔｅ）段階
を含む、請求項１に記載の合意方法。

【請求項3】

前記同意プロトコル（Ａｇｒｅｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ）にしたがって合意を進める段階は、
プライマリがビューチェンジプロトコルを実行しながら指定されたクライアント要請メッセージが存在すれば、クライアントから受信した他の要請メッセージを使用して準備（ＰＲＥＰＡＲＥ）メッセージを生成し、前記指定されたクライアント要請がなくて新たなクライアント要請がない場合、プライマリでヌル（ｎｕｌｌ）要請メッセージを使用して準備（ＰＲＥＰＡＲＥ）メッセージを生成する段階
を含む、請求項１に記載の合意方法。

【請求項4】

前記同意プロトコル（Ａｇｒｅｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ）にしたがって合意を進める段階は、
プライマリでクライアント要請メッセージｍを使用して生成された準備（ＰＲＥＰＡＲＥ）メッセージを合計３ｆ＋１個のプロセスに送信し、前記プライマリを含む欠陥のないすべてのプロセスで現在状態を準備状態に設定する段階
を含む、請求項１に記載の合意方法。

【請求項5】

前記同意プロトコル（Ａｇｒｅｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ）にしたがって合意を進める段階は、
現在状態が準備（ＰＲＥＰＡＲＥ）状態である各プロセスから実行（ＥＸＥＣＵＴＥ）メッセージが他のプロセスに送信され、前記現在状態が準備（ＰＲＥＰＡＲＥ）状態である各プロセス自身を含んだ他のプロセスから２ｆ＋１個以上の合致した実行（ＥＸＥＣＵＴＥ）メッセージを受信する段階
を含む、請求項４に記載の合意方法。

【請求項6】

前記同意プロトコル（Ａｇｒｅｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ）にしたがって合意を進める段階は、
前記他のプロセスから２ｆ＋１個以上の合致した実行（ＥＸＥＣＵＴＥ）メッセージを受信した各プロセスでロールバック（ｒｏｌｌｂａｃｋ）するのに必要な情報を記録し、クライアント要請ｍに対する作業を実行して結果を取得し、前記取得した結果を含むリプライ（ＲＥＰＬＹ）メッセージをクライアントに送信し、以後に処理する新たなクライアント要請の処理番号を＋１増加させ、現在まで合意して処理されたクライアント要請メッセージのリストにｍを追加し、前記現在まで合意して処理されたクライアント要請に対して実行した要約された履歴を更新し、プロセスの現在状態をレディー（ＲＥＡＤＹ）状態に設定し、同意タイマーをΔ_１に初期化して再開する段階
を含む、請求項５に記載の合意方法。

【請求項7】

前記同意プロトコル（Ａｇｒｅｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ）にしたがって合意を進める段階は、
ロールバックが不可能であるかロールバック費用が予め設定された基準以上であると判断されれば、クライアント要請に対する作業の実行を保留してリプライメッセージの送信を省略する段階
を含む、請求項５に記載の合意方法。

【請求項8】

前記同意プロトコル（Ａｇｒｅｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ）にしたがって合意を進める段階は、
前記クライアントで前記クライアント要請に対して同じ結果を含む２ｆ＋１個以上のリプライメッセージが受信される場合には結果をコミット（ｃｏｍｍｉｔ）し、前記クライアントで一定の時間内に同じ結果を含む２ｆ＋１個以上のリプライメッセージが受信されない場合にはプロセスにリクエスト（ＲＥＱＵＥＳＴ）メッセージｍを送信し、各プロセスでリプライメッセージを前記クライアントに再送し、前記クライアントからリクエストメッセージｍを受信することができなかった場合には前記プライマリにリクエストメッセージｍを伝達して同意タイマーをΔ_１に初期化して再開する段階
を含む、請求項６に記載の合意方法。

【請求項9】

前記ビューチェンジプロトコル（Ｖｉｅｗ Ｃｈａｎｇｅ Ｐｒｏｔｏｃｏｌ）にしたがってプライマリを代替する段階は、
前記クライアント要請に合意して実行する前に同意タイマーが満了（ｅｘｐｉｒｅ）となる場合、プロポーズニュービュー（Ｐｒｏｐｏｓｅ Ｎｅｗ Ｖｉｅｗ）段階、アクセプトニュービュー（Ａｃｃｅｐｔ Ｎｅｗ Ｖｉｅｗ）段階で構成されたビューチェンジプロトコルを含む、
請求項１に記載の合意方法。

【請求項10】

前記ビューチェンジプロトコル（Ｖｉｅｗ Ｃｈａｎｇｅ Ｐｒｏｔｏｃｏｌ）にしたがってプライマリを代替する段階は、
各プロセスの現在状態をビュー－チェンジング（ＶＩＥＷ－ＣＨＡＮＧＩＮＧ）状態に設定し、プロポーズニュービューメッセージを他のプロセスに送信し、ビューチェンジタイマーを初期化して開始する段階
を含み、
前記プロポーズニュービューメッセージは、新たなプライマリを指定する新たなビュー値、最後に実行して返信したクライアント要請の処理番号値、最後に受信した有効な準備メッセージを含む、
請求項９に記載の合意方法。

【請求項11】

前記ビューチェンジプロトコル（Ｖｉｅｗ Ｃｈａｎｇｅ Ｐｒｏｔｏｃｏｌ）にしたがってプライマリを代替する段階は、
新たなビューの新たなプライマリに該当するプロセスにおいて、自身を含んだ２ｆ＋１個以上の他のプロセスから同じ新たなビュー値を有する２＋１個以上のプロポーズニュービューメッセージを受信する段階
を含む、請求項９に記載の合意方法。

【請求項12】

前記ビューチェンジプロトコル（Ｖｉｅｗ Ｃｈａｎｇｅ Ｐｒｏｔｏｃｏｌ）にしたがってプライマリを代替する段階は、
前記同じ新たなビュー値を有するプロポーズニュービューメッセージを２ｆ＋１個以上受信すれば、前記新たなビューの新たなプライマリに該当するプロセスにおいて、前記受信した２＋１個のプロポーズニュービューメッセージのうちからプロセスが最後に実行して返信したクライアント要請の処理番号の最大値を探索し、前記探索された最大値を新たなビューで開始する処理番号として定めてこの値をアクセプトニュービューメッセージに含み、アクセプトニュービューメッセージを他のプロセスとクライアントに送信し、前記受信した２＋１個のプロポーズニュービューメッセージのうちから処理番号が最大値である準備メッセージを探索し、前記探索された準備メッセージの処理番号の最大値が新たなビューで開始する処理番号と同じであれば、前記新たなビューの新たなプライマリに該当するプロセスがビューチェンジ直後に処理しなければならないクライアント要請メッセージを前記探索された準備メッセージに含まれたクライアント要請メッセージｍに設定し、前記探索された準備メッセージの処理番号の最大値が新たなビューで開始する処理番号と同じでなければ、前記新たなビューの新たなプライマリに該当するプロセスがビューチェンジ直後に処理しなければならないクライアント要請メッセージをヌル（ｎｕｌｌ）に設定する段階
を含む、請求項１１に記載の合意方法。

【請求項13】

前記ビューチェンジプロトコル（Ｖｉｅｗ Ｃｈａｎｇｅ Ｐｒｏｔｏｃｏｌ）にしたがってプライマリを代替する段階は、
各プロセスが前記新たなビューの新たなプライマリに該当するプロセスからアクセプトニュービューメッセージを受信すれば、各プロセスの現在状態を新たなビュー値に設定し、ビューチェンジタイマーを中断し、同意タイマーをΔ_１に初期化して再開し、プロセスの現在状態をレディー（ＲＥＡＤＹ）段階に設定する段階
を含む、請求項１１に記載の合意方法。

【請求項14】

前記同意プロトコル（Ａｇｒｅｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ）にしたがって合意を進める段階と前記ビューチェンジプロトコル（Ｖｉｅｗ Ｃｈａｎｇｅ Ｐｒｏｔｏｃｏｌ）にしたがってプライマリを代替する段階は、
各プロセスから状態不一致（ｓｔａｔｅ ｉｎｃｏｎｓｉｓｔｅｎｃｙ）が見つかれば、最後のラウンド（ｌａｔｅｓｔ ｒｏｕｎｄ）で実行したクライアント要請を取り消す（ｕｎｄｏ）段階を含む、
請求項１に記載の合意方法。

【請求項15】

前記同意プロトコル（Ａｇｒｅｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ）にしたがって合意を進める段階は、
前記各プロセスで２ｆ＋１個以上の一致した実行メッセージを識別し、前記識別された実行メッセージに含まれた情報が前記プロセスと関連してクライアント要請の処理番号と一致しない場合、状態不一致が発生したと判断してロールバックを実行する段階
を含む、請求項１４に記載の合意方法。

【請求項16】

前記ビューチェンジプロトコル（Ｖｉｅｗ Ｃｈａｎｇｅ Ｐｒｏｔｏｃｏｌ）にしたがってプライマリを代替する段階は、
前記各プロセスで有効なアクセプトビューチェンジメッセージを受信したときに新たな処理番号値と前記プロセスと関連してクライアント要請の処理番号値が一致する場合、状態不一致が発生したと判断してロールバックを実行する段階
を含む、請求項１４に記載の合意方法。

【請求項17】

合意システムであって、
メモリに含まれるコンピュータ読み取り可能な命令を実行するように構成された少なくとも１つのプロセッサ
を含み、
前記少なくとも１つのプロセッサは、
クライアント要請に対する合意を進めるための通信段階を含むプロトコルを利用して、前記通信段階にしたがってプロセス間の通信によって前記クライアント要請に対する実行に基づいて合意を進めること
を特徴とする、合意システム。

【発明の詳細な説明】

【技術分野】

【0001】

以下の説明は、ビザンチン障害を許容しながらステートマシンレプリケーションに適用することができる合意アルゴリズムに関する。

【背景技術】

【0002】

合意（ｃｏｎｓｅｎｓｕｓ）の目標は、多数のプロセス間で合意に到達することにある。合意は分散プロセスを制御するための根本的な問題（ｆｕｎｄａｍｅｎｔａｌ ｐｒｏｂｌｅｍ）であって、ステートマシンレプリケーション（ｓｔａｔｅ ｍａｃｈｉｎｅ ｒｅｐｌｉｃａｔｉｏｎ）、分散データベース管理、原子的ブロードキャスト（ａｔｏｍｉｃ ｂｒｏａｄｃａｓｔ）、ブロックチェーン（ｂｌｏｃｋｃｈａｉｎ）などに主に適用される。このうちのステートマシンレプリケーションは、欠陥のないすべてのプロセス（ｐｒｏｃｅｓｓ）が内部状態（ｓｔａｔｅ）を維持し、同じ順序でクライアント要請を実行して同じ出力を生成する応用（ａｐｐｌｉｃａｔｉｏｎ）である。一般的な特性により、ステートマシンレプリケーションのための合意アルゴリズムは、分散データベース管理システムおよびブロックチェーンをはじめとする他の応用に適用することができる。

【0003】

注目すべき２つの合意アルゴリズムがある。１９９９年のＯＳＤＩ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍｓ Ｄｅｓｉｇｎ ａｎｄ Ｉｍｐｌｅｍｅｎｔａｔｉｏｎ）学術大会で発表されたＰＢＦＴ（Ｐｒａｃｔｉｃａｌ Ｂｙｚａｎｔｉｎｅ Ｆａｕｌｔ Ｔｏｌｅｒａｎｃｅ）は、ステートマシンレプリケーションのためのビザンチン合意アルゴリズムである。ＰＢＦＴは、従来のビザンチン合意アルゴリズムと比べると、指数レベル（ｅｘｐｏｎｅｎｔｉａｌ ｌｅｖｅｌ）から多項式レベル（ｐｏｌｙｎｏｍｉａｌ ｌｅｖｅｌ）に通信費用を大きく向上させることから、広く利用されている。ＰＢＦＴは、２回の全帯域通信段階を含んで３回の通信段階を使用するが、残念ながら少数のプロセスだけを含むアプリケーションに拡張性（ｓｃａｌａｂｉｌｉｔｙ）が制限される。２００７年のＡＣＭＳＯＳＰ（Ｓｙｍｐｏｓｉｕｍ ｏｎ Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍｓ Ｐｒｉｎｃｉｐｌｅｓ）学術大会で発表されたＺｙｚｚｙｖａ合意アルゴリズムは、一般的な場合に１回の通信段階だけを使用する推測方式である。しかし、障害プロセスが１つでも存在したり一部にネットワーク遅延が発生したりすれば、Ｚｙｚｚｙｖａは、原則的にＰＢＦＴと類似の通信パターンを有する、より遅い４段階アルゴリズムに切り替わる。さらに、プライマリと呼ばれるリーダープロセスがビザンチン欠陥である場合にはプロセス状態が無限定に分岐し、このような不一致はクライアントの助けがなければ感知または除去することができない。

【発明の概要】

【発明が解決しようとする課題】

【0004】

ビザンチン障害を許容しながらステートマシンレプリケーションに適用することができる、新たな合意アルゴリズムを提供する。

【課題を解決するための手段】

【0005】

合意システムによって実行される合意方法は、同意プロトコル（Ａｇｒｅｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ）にしたがい、クライアント要請に対してプライマリ（ｐｒｉｍａｒｙ）に指定されたプロセスが提案する処理番号（ｓｅｑｕｅｎｃｅ ｎｕｍｂｅｒ）をすべての正常なプロセスが合意を進める段階、およびビザンチン（Ｂｙｚａｎｔｉｎｅ）欠陥の疑いがあるプライマリを他のプロセスに代替するビューチェンジプロトコル（Ｖｉｅｗ Ｃｈａｎｇｅ Ｐｒｏｔｏｃｏｌ）で構成する段階を含む。

【0006】

合意方式は、プライマリで提示した一連番号を非欠陥プロセスがすべて合意する同意プロトコルと、ビザンチン欠陥の疑いがあるプライマリを他のプロセスに代替するビューチェンジプロトコルで構成される。

【0007】

同意プロトコルを使用すれば、プロセスが２回の通信段階で合意に到達することができる。最初の段階において、プライマリは、クライアント要請にシーケンス番号を割り当て、すべてのプロセスにＰＲＥＰＡＲＥメッセージをマルチキャストする。次の段階において、各プロセスは、ＥＸＥＣＵＴＥメッセージをすべてのプロセスにマルチキャストし、自身を含むプロセスの２／３以上である圧倒的多数から一致するＥＸＥＣＵＴＥメッセージを受信すればクライアント要請を実行する。Ｚｙｚｚｙｚａとは異なり、同意プロトコルは、誤ったプロセスや一部ネットワーク遅延がある場合にも２回の段階で作動するため、これを使用するシステムの全般的な性能、拡張性、および剛性を向上させる。

【0008】

ビューチェンジプロトコルは、プライマリが失敗するときに活性を提供する。プライマリが失敗すれば、プロセスは要請が実行されるまで無期限待機となる。このような無期限待機を防ぐために、各プロセスはタイマーを使用する。プロセスのタイマーが満了となれば、プロセスは新たなプロセスを指定するために新たなビュー値を決定し、すべてのプロセスにＰＲＯＰＯＳＥ－ＮＥＷ－ＶＩＥＷメッセージをマルチキャストする。新たなビュー値によって指定されたプロセスは、大多数のプロセスから有効なＰＲＯＰＯＳＥ－ＮＥＷ－ＶＩＥＷメッセージを受信すれば、他のすべてのプロセスにＡＣＣＥＰＴ－ＮＥＷ－ＶＩＥＷメッセージをマルチキャストし、新たなビューにおいてプライマリとしての動作を開始する。

【0009】

本発明は、一時的に一貫しないプロセス状態を導入することができる。このために、障害のないプロセスは、同一のビュー内でクライアント要請に対する単一総命令（ｏｒｄｅｒ）に同意することができるが、障害のない他のプロセスは、他のビューで同一のシーケンス番号によって他のクライアント要請を実行することがある。一般的に高価な３相アルゴリズムを実行せずには、このような不一致を完全に除去することは不可能である。しかし、提案する２段階合意方法は、実行履歴という概念を使用することで、制限的で探知可能な不一致を保障する。このために、各プロセスは、自身が実行したクライアント要請を順に並べた実行履歴を暗号ハッシュ値形態で維持し、他のプロセスと通信するときに自身の実行履歴が他の実行履歴と一致するかを確認する。これは、クライアント要請のここ最近の実行だけがプロセスの大多数の実行記録と一致しないという点において制限された不一致を許容する。実行記録を使用すれば、プロセスでクライアントが介入しなくても不一致を感知することもできる。

【0010】

また、不一致を最大限に防ぐために、ビューチェンジプロトコルは、予測の繰り越しを使用する。ビューチェンジの間、新たなプライマリは、絶対多数よりも少ない、数個のプロセスによって実行された以前のビューからクライアント要請を探し出して繰り越しを試みる。新たなプライマリがこのようなクライアント要請をニュービューに伝達しない限り、プロセスは新たなビューの同一のシーケンス番号で他のクライアント要請を実行することができる。不幸にもビザンチン欠陥プロセスが存在するときに、新たなプライマリは、このようなクライアント要請を２つ以上発見することがある。この場合、ほとんどのプライマリで一致するＥＸＥＣＵＴＥメッセージが必要となるため、欠陥のないプロセスによって１つのクライアント要請だけが実行された。しかし、新たなプライマリは、正しいクライアント要請を他の要請と区分することができず、誤ったクライアント要請を選択すれば新たなビューで不一致を誘発する恐れがある。しかし、推測をしなければ依然として不一致が発生するため、行わないよりはましである。

【発明の効果】

【0011】

推測を活用して２回の通信段階で合意に到達することにより、３回以上の通信段階を使用する従来の比推論的アルゴリズムの待機時間と処理量を向上させることできる。

【0012】

また、欠陥のあるプロセスが１つしかない場合にも４段階アルゴリズムを実行しなければならないＺｙｚｚｙｚａよりも、実用的な性能を提供することができる。

【0013】

さらに、プロセス状態間の不一致が制限され、クライアントが介入しなくても感知が可能であることを保障する。

【図面の簡単な説明】

【0014】

【図1】一実施形態における、プロセスの合意方式およびイベントキューに対する状態図を説明するための図である。

【図2】一実施形態における、同意プロトコルの２回のメッセージ通信段階を説明するための図である。

【図3】一実施形態における、ビューチェンジプロトコルのメッセージ通信段階を説明するための図である。

【図4】一実施形態における、合意にステートマシンで参加するプロセスの構成を説明するためのブロック図である。

【図5】一実施形態における、合意方法を説明するためのフローチャートである。

【図6】一実施形態における、合意方法を説明するためのフローチャートである。

【図7】一実施形態における、合意方法を説明するためのフローチャートである。

【図8】一実施形態における、合意方法を説明するためのフローチャートである。

【図9】一実施形態における、合意方法を説明するためのフローチャートである。

【図10】一実施形態における、合意方法を説明するためのフローチャートである。

【図11】一実施形態における、合意方法を説明するためのフローチャートである。

【発明を実施するための形態】

【0015】

以下、実施形態について、添付の図面を参照しながら詳しく説明する。

【0016】

実施形態で提案するステートマシンレプリケーションのための２段階ビザンチン合意動作についての説明に先立ち、実行環境、モデル、過程、性質について説明する。

【0017】

実施形態で提案する合意のための実行環境は、ステートマシンとして見なされるｎ個（ｎは自然数）のプロセスと、プロセスにクエリ（ｑｕｅｒｙ）または更新（ｕｐｄａｔｅ）作業を要請するクライアントで構成されてよい。ステートマシンレプリケーション（ｓｔａｔｅ ｍａｃｈｉｎｅ ｒｅｐｌｉｃａｔｉｏｎ）は、すべての正常（ｎｏｎ－ｆａｕｌｔｙ）プロセスが同じ状態（ｓｔａｔｅ）を維持しながらすべてのクライアント要請に対して同じ結果（ｏｕｔｐｕｔ）を出力することを目的とする。このためには、すべての正常（ｎｏｎ－ｆａｕｌｔｙ）プロセスが同じクライアント要請を同じ順序（ｔｈｅ ｓａｍｅ ｏｒｄｅｒ）で実行しなければならない。

【0018】

実施形態で提案する合意動作では、１つのプロセスをプライマリ（ｐｒｉｍａｒｙ）として定め、プライマリがクライアント要請を受信して残りのプロセスに処理番号（ｓｅｑｕｅｎｃｅ ｎｕｍｂｅｒ）を提案する。プロセスは、プライマリから提案された処理番号に合意して決定をし、クライアント要請を決定した順番に実行（ｅｘｅｃｕｔｅ）をして結果（ｒｅｓｕｌｔ）をクライアントに送信する。

【0019】

一般的に、合意問題では、安全性（ｓａｆｅｔｙ）と活性（ｌｉｖｅｎｅｓｓ）という２つの条件が満たされなければならない。安全性（ｓａｆｅｔｙ）とは、正常（ｎｏｎ－ｆａｕｌｔｙ）クライアントの要請ｍが処理番号ｎにコミット（ｃｏｍｍｉｔ）されれば他の要請であるｍ’は処理番号ｎにコミットされてはならず、ｍも他の処理番号ｎ’にコミットされてはならないという条件を意味する。活性（ｌｉｖｅｎｅｓｓ）とは、正常（ｎｏｎ－ｆａｕｌｔｙ）クライアントの要請ｍがいつかは（ｅｖｅｎｔｕａｌｌｙ）コミットされなければならないという条件を意味する。

【0020】

実施形態では、同期的（ｓｙｎｃｈｒｏｎｏｕｓ）または非同期的（ａｓｙｎｃｈｒｏｎｏｕｓ）に動作するシステムに適用されてよい。同期的（ｓｙｎｃｈｒｏｎｏｕｓ）システムとは、メッセージの送信時間とプロセス（ｐｒｏｃｅｓｓ）の処理時間に対する上限値（ｕｐｐｅｒ ｂｏｕｎｄ）が存在するシステムを意味する。非同期的（ａｓｙｎｃｈｒｏｎｙ）システムとは、メッセージの送信時間とプロセス（ｐｒｏｃｅｓｓ）の処理時間に対する上限値（ｕｐｐｅｒ ｂｏｕｎｄ）が存在しないシステムを意味し、メッセージが重複送信されたりメッセージの到着順序が変わることもある。

【0021】

実施形態で提案する合意動作は、同期的または非同期的システムの両方に対して安全性（ｓａｆｅｔｙ）を保障し、システムが十分な時間を経て同期的に動作することができれば活性（ｌｉｖｅｎｅｓｓ）を保障する。

【0022】

実施形態では、プロセス（ｐｒｏｃｅｓｓ）とクライアント（ｃｌｉｅｎｔ）のビザンチン障害（Ｂｙｚａｎｔｉｎｅ ｆａｕｌｔ）を許容する。ビザンチン障害とは、実行が中断されるｆａｉｌ－ｓｔｏｐ障害はもちろん、合意アルゴリズムで定めた規則を違反するすべての種類の障害を意味する。実施形態で提案する合意動作を正しく動作するためには、ｆ個以下のプロセスでビザンチン（Ｂｙｚａｎｔｉｎｅ）障害が発生しなければならず、このとき、ｎは３ｆ＋１と同じかこれよりも大きくなければならない。実施形態では、ｎ＝３ｆ＋１と仮定する。また、実施形態では、クライアントのビザンチン障害を許容し、ビザンチンクライアントが合意速度に影響を与えることがあっても安全性（ｓａｆｅｔｙ）と活性（ｌｉｖｅｎｅｓｓ）には影響を与えない。

【0023】

実施形態では、合意を進める区間をビュー（ｖｉｅｗ）とラウンド（ｒｏｕｎｄ）に区分する。ビュー（ｖｉｅｗ）は１つのプライマリが合意を進める区間を、ラウンドは１つのクライアント要請に合意して実行する区間を意味し、１つのビュー（ｖｉｅｗ）は複数のラウンド（ｒｏｕｎｄ）で構成されてよい。

【0024】

プライマリにビザンチン障害が疑われる場合は、ビュー（ｖｉｅｗ）が変わることがある。ビューが変わるということは、プライマリが他のプロセスに代替されることと同じ意味を有し、これをビューチェンジ（ｖｉｅｗ ｃｈａｎｇｅ）と呼ぶ。新たなプライマリを決定する方法は多様に存在するが、実施形態ではプロセスを識別子ｉで区分し、ｋ番目のビュー（ｖｉｅｗ）のプライマリをｋ＝ｉ％ｎであるプロセスｉに決定することにする。

【0025】

実施形態において、プロトコルは、２つのサブプロトコル（ｓｕｂ－ｐｒｏｔｏｃｏｌ）で構成されてよい。１つはクライアント要請に対する合意および実行を処理する同意プロトコル（ａｇｒｅｅｍｅｎｔ ｐｒｏｔｏｃｏｌ）であり、他の１つはビザンチンが疑われるプライマリ（ｐｒｉｍａｒｙ）を代替するビューチェンジプロトコル（ｖｉｅｗ ｃｈａｎｇｅ ｐｒｏｔｏｃｏｌ）である。

【0026】

実施形態で提案する合意動作を説明する前に、プロセスが使用する変数（ｖａｒｉａｂｌｅｓ）とタイマー（ｔｉｍｅｒｓ）を以下のように定義する。

【0027】

ｃｕｒｒｅｎｔＶｉｅｗは現在のビュー（ｖｉｅｗ）値を示す。各プロセスｉは初期値としてｃｕｒｒｅｎｔＶｉｅｗ_ｉ＝１に設定する。

【0028】

ｃｕｒｒｅｎｔＳｔａｔｅはプロセスの現在状態を示し、ＲＥＡＤＹ、ＰＲＥＰＡＲＥＤ、ＶＩＥＷ－ＣＨＡＮＧＩＮＧのうちの１つの値を有する。各プロセスｉは初期値としてｃｕｒｒｅｎｔＳｔａｔｅ_ｉ＝ＲＥＡＤＹに設定する。

【0029】

ｅｘｅｃｕｔｅＩｎｄｅｘは、プロセスがここ最近に（ｌａｔｅｓｔ）実行したクライアント要請の処理番号（ｓｅｑｕｅｎｃｅ ｎｕｍｂｅｒ）を示す。各プロセスｉは初期値としてｅｘｅｃｕｔｅＩｎｄｅｘ_ｉ＝０に設定する。

【0030】

ｅｘｅｃｕｔｅＬｏｇは、プロセスが実行したクライアント要請メッセージのリストを示す。各プロセスｉは初期値としてｅｘｅｃｕｔｅＬｏｇ_ｉ［０］＝ｎｕｌｌに設定し、プロセスｉがｋ番目に実行したクライアント要請メッセージをｍ_ｉ、ｋとすればｅｘｅｃｕｔｅＬｏｇ_ｉ［ｋ］＝ｍ_ｉ、ｋである。

【0031】

ｅｘｅｃｕｔｅＨｉｓｔｏｒｙは、暗号学的ハッシュ関数（ｃｒｙｐｔｏｇｒａｐｈｉｃ ｈａｓｈ ｆｕｎｃｔｉｏｎ）Ｈａｓｈ（）を利用してプロセスが実行したクライアント要請メッセージの要約された履歴を示す。各プロセスｉの初期値としてｅｘｅｃｕｔｅＨｉｓｔｏｒｙ_ｉ［０］＝０に設定し、ｅｘｅｃｕｔｅＨｉｓｔｏｒｙ_ｉ［ｋ］＝Ｈａｓｈ（ｅｘｅｃｕｔｅＨｉｓｔｏｒｙ_ｉ［ｋ－１］、ｍ_ｉ、ｋ）で計算される。使用される暗号学的ハッシュ関数は十分な衝突抵抗性（ｃｏｌｌｉｓｉｏｎ ｒｅｓｉｓｔａｎｃｅ）を有しており、互いに異なる入力に対してハッシュ関数値が一致する確率は０であると仮定する。したがって、２つのプロセスのｅｘｅｃｕｔｅＨｉｓｔｏｒｙが一致すれば、２つのプロセスは今まで同じクライアント要請を同じ順序で実行してきたことを意味する。

【0032】

ｒｅｐｌｙＬｏｇは、プロセスがクライアントに返信したメッセージのリストを示す。各プロセスｉの初期値としてｒｅｐｌｙＬｏｇ_ｉ［０］＝ｎｕｌｌに設定し、プロセスＰ_ｉは、ｋ番目に返信したメッセージをＲ_ｉ、ｋとすればｒｅｐｌｙＬｏｇ_ｉ［ｋ］＝Ｒ_ｉ、ｋである。

【0033】

ｕｎｄｏＬｏｇは、プロセスがここ最近に実行したクライアント要請を取り消す（ｕｎｄｏ）のに必要な情報の集合を示す。各プロセスｉは、クライアント要請を実行する前にｕｎｄｏＬｏｇ_ｉに必要な情報を記録しなければならない。

【0034】

ｒｅｓｅｒｖｅｄＰｒｅｐａｒｅは、新たに選出されたプライマリｐがビューチェンジ直後に処理しなければならないクライアント要請メッセージｍを示し、クライアント要請メッセージがなければｒｅｓｅｒｖｅｄＰｒｅｐａｒｅｐ＝ｎｕｌｌに設定する。

【0035】

ｄｅｆｅｒｒｅｄＥｘｅｃｕｔｉｏｎは、不可能であるかロールバック費用が極めて大きい場合にクライアント要請作業の実行を保留するときに使用するブール（ｂｏｏｌ）変数である。各プロセスｉの初期値としてｄｅｆｅｒｒｅｄＥｘｅｃｕｔｉｏｎ_ｉ＝ｆａｌｓｅに設定し、実行を保留する場合はｔｒｕｅに設定する。

【0036】

同意タイマーＴ_{ａｇｒｅｅｍｅｎｔ}は、合意が円滑に進むかを判断するのに使用されるタイマーを示す。各プロセスｉは、新たなクライアント要請に対する合意を開始するたびにＴ_{ａｇｒｅｅｍｅｎｔ、}ｉをΔ_１値に初期化し、タイマーが満了（ｅｘｐｉｒｅ）となればビューチェンジによってプライマリの代替を試みる。

【0037】

ビューチェンジタイマーＴ_{ｖｉｅｗ－ｃｈａｎｇｅ}は、ビューチェンジが円滑に進むかを判断するのに使用されるタイマーを示す。各プロセスｉは、ビューチェンジを始めて開始するときにＴ_{ｖｉｅｗ－ｃｈａｎｇｅ、}ｉをΔ_２値に初期化し、タイマーが満了（ｅｘｐｉｒｅ）となるたびに変更される新たなビュー（ｎｅｗ ｖｉｅｗ）値を１だけ増加させ、タイマー値は２倍に増加させる。

【0038】

図１は、一実施形態における、プロセスの合意方式およびイベントキューに対する状態図を説明するための図である。図１は、プロセス１０１の状態ダイヤグラム（ｓｔａｔｅ ｄｉａｇｒａｍ）とイベントキュー（ｅｖｅｎｔ ｑｕｅｕｅ）に基づいてソフトウェアまたはハードウェア形態でプロセスを示した図である。プロセス１０１は、レディー（ＲＥＡＤＹ）１１０、準備（ＰＲＥＰＡＲＥ）１２０、およびビューチェンジング（ＶＩＥＷ－ＣＨＡＮＧＩＮＧ）１３０という３つの状態を有してよく、７種類のイベントによって状態遷移（ｓｔａｔｅ ｔｒａｎｓｉｔｉｏｎ）およびアルゴリズムで定義された動作を実行してよい。すべてのイベントは発生して直ぐにイベントキューに保存されてよく、プロセス１０１は状態遷移が完了するたびにイベントキューからイベントを１つずつ取り出して実行するイベントプロセッシングループ（ｅｖｅｎｔ ｐｒｏｃｅｓｓｉｎｇ ｌｏｏｐ）を繰り返す。

【0039】

以下の表１はイベントを示したものである。

【表1】

【0040】

プロセス１０１は、プロセス１０１の状態とは無関係に発生するすべての有効なイベントをイベントキューに保存し、有効でないイベントをイベントに保存せずに無視してよい。例外的に、プロセス１０１は、有効でないイベントのうちでプライマリのビザンチン障害を判断するために必要なイベントをイベントキューに保存してよい。例えば、有効でない準備（ＰＲＥＰＡＲＥ）メッセージはプライマリのビザンチン障害を意味し、準備メッセージを受信する場合、イベントキューに受信された準備メッセージを保存して以後にビューチェンジが開始されるようにする。

【0041】

図２は、一実施形態における、同意プロトコルの２回のメッセージ通信段階を説明するための図である。

【0042】

クライアントｃがリクエスト（ＲＥＱＵＥＳＴ）メッセージｍ＝＜ＲＥＱＵＥＳＴ、ｏ、ｔ、ｃ＞σ_Ｃをプライマリｐに送信すれば、同意プロトコルのラウンド（ｒｏｕｎｄ）が始まる。リクエストメッセージにおいて、ｏはクライアントが要請する作業、ｔはタイムスタンプ、ｃはクライアントの識別子、σ_Ｃはクライアントの電子署名を示す。この後、プロセスは、準備（Ｐｒｅｐａｒｅ）段階と実行（Ｅｘｅｃｕｔｅ）段階からなる２段階の同意プロトコルを実行する。

【0043】

準備段階において、プライマリｐがｒｅｓｅｒｖｅｄＰｒｅｐａｒｅ_ｐに保存されたクライアント要請メッセージ、またはクライアント要請メッセージが存在しない場合は新たなクライアント要請メッセージｍを使用して準備（ＰＲＥＰＡＲＥ）メッセージ＜＜ＰＲＥＰＡＲＥ、ｖ、ｎ、Ｈ、Ｈａｓｈ（ｍ）、ｐ＞σ_ｐ、ｍ＞をすべてのプロセスに送信してよい。プライマリｐは、自身の現在状態ｃｕｒｒｅｎｔＳｔａｔｅ_ｐを準備（ＰＲＥＰＡＲＥＤ）状態に設定してよい。このとき、準備メッセージにおいて、ｖはプライマリｐの現在ビュー（ｃｕｒｒｅｎｔ ｖｉｅｗ）値ｃｕｒｒｅｎｔＶｉｅｗ_ｐを、ｎはプライマリｐがクライアント要請ｍに割り当てた処理番号（ｓｅｑｕｅｎｃｅ ｎｕｍｂｅｒ）としてｅｘｅｃｕｔｅＩｎｄｅｘｐ＋１で計算され、Ｈは合意が成功する場合に取得するようになる実行履歴（ｅｘｅｃｕｔｅＨｉｓｔｏｒｙ）の値としてＨ＝Ｈａｓｈ（ｅｘｅｃｕｔｅＨｉｓｔｏｒｙ_ｐ［ｅｘｅｃｕｔｅＩｎｄｅｘ_ｐ］、ｍ）で計算され、Ｈａｓｈ（ｍ）はｍのハッシュ値を、σ_ｐはプライマリの電子署名を示す。処理しなければならないクライアント要請が１つも存在しない場合には、プライマリｐはＮＵＬＬリクエスト（ＲＥＱＵＥＳＴ）メッセージｍ＝＜ＮＵＬＬ－ＲＥＱＵＥＳＴ、ｏ_ｎｕｌｌ、ｔ、ｐ＞σ_ｐを利用して準備メッセージを発送してよい。ＮＵＬＬリクエストメッセージは、不必要なビューチェンジを防ぐためのｈｅａｒｔ ｂｅａｔの役割を担う。プライマリｐから準備メッセージを受信した各プロセスｉは、ｍを実行したことがなく、ｖ＝ｃｕｒｒｅｎｔＶｉｅｗ_ｉ、ｎ＝ｅｘｅｃｕｔｅＩｎｄｅｘ_ｉ＋１、Ｈ＝Ｈａｓｈ（ｅｘｅｃｕｔｅＨｉｓｔｏｒｙ_ｉ［ｅｘｅｃｕｔｅＩｎｄｅｘ_ｉ］、ｍ）条件がすべて満たされる場合はｃｕｒｒｅｎｔＳｔａｔｅ_ｉ＝ＰＲＥＰＡＲＥＤに設定してよい。

【0044】

実行段階において、現在状態が準備状態（ｃｕｒｒｅｎｔＳｔａｔｅ_ｉ＝ＰＲＥＰＡＲＥＤ）である各プロセスｉの実行（ＥＸＥＣＵＴＥ）メッセージ＜ＥＸＥＣＵＴＥ、ｖ、ｎ、Ｈ、Ｈａｓｈ（ｍ）、ｉ＞σ_ｉを他のすべてのプロセスに送信してよい。現在状態が準備状態（ｃｕｒｒｅｎｔＳｔａｔｅ_ｉ＝ＰＲＥＰＡＲＥＤ）である各プロセスｉが、各プロセスｉを含んだ他のプロセスから２ｆ＋１個以上の合致した（ｍａｔｃｈｉｎｇ）実行（ＥＸＥＣＵＴＥ）メッセージを受信する場合、次の一連の作業を実行してよい。

【0045】

各プロセスｉは、ｕｎｄｏＬｏｇ_ｉにロールバック（ｒｏｌｌｂａｃｋ）に必要な情報を記録してよい。各プロセスｉは、クライアント要請を実行し、取得した結果をクライアントにリプライ（ＲＥＰＬＹ）メッセージ＜ＲＥＰＬＹ、ｖ、ｔ、ｃ、ｉ、ｒｅｓｕｌｔ＞σ_ｉで送信してよい。各プロセスｉは、変数ｅｘｅｃｕｔｅＩｎｄｅｘ_ｉを＋１増加させ、実行ログｅｘｅｃｕｔｅＬｏｇ_ｉ［ｅｘｅｃｕｔｅＩｎｄｅｘ_ｉ］をｍに設定し、ｃｕｒｒｅｎｔＳｔａｔｅ_ｉ＝ＲＥＡＤＹに設定し、同意タイマーＴ_{ａｇｒｅｅｍｅｎｔ、ｉ}をΔ_１に初期化して再開（ｒｅｓｔａｒｔ）してよい。

【0046】

追加で、実行段階において、予想ロールバック費用が極めて高かったり、とある理由によってロールバックが不可能な場合、プロセスは、クライアント要請に対する実行（ｅｘｅｃｕｔｉｏｎ）およびリプライメッセージ送信を省略してよい。この場合、各プロセスｉがｄｅｆｅｒｒｅｄＥｘｅｃｕｔｉｏｎ_ｉ＝ｔｒｕｅに設定してクライアント要請を実行し、次のラウンドの実行段階で実行するようになるが、これを遅延実行（ｄｅｆｅｒｒｅｄ ｅｘｅｃｕｔｉｏｎ）と呼ぶ。これにより、各プロセスｉは、実行段階に進んだときにｄｅｆｅｒｒｅｄＥｘｅｃｕｔｉｏｎ_ｉ＝ｔｒｕｅに設定されていれば、現在のラウンドで新たなクライアント要請を実行する前に、以前のラウンドで保留となった作業を先行しなければならない。

【0047】

クライアントは、クライアントが要請した作業に対して同じ実行結果（ｒｅｓｕｌｔ）を含む２ｆ＋１個以上のリプライメッセージを受信すれば、結果をコミット（ｃｏｍｍｉｔ）してよい。クライアントは、一定の時間内に同じ実行結果を含む２ｆ＋１個以上のリプライメッセージを受信することができなければ、すべてのプロセスにリクエストメッセージｍを送信してよい。各プロセスｉは、クライアントから送信されたリクエストメッセージｍを受信してよい。各プロセスｉは、ｍに対してリプライメッセージを既に送信していれば同じリプライメッセージをクライアントに再送（ｒｅｔｒａｎｓｍｉｔ）し、ｍに対してリプライメッセージが送信されていなければ、プライマリにｍを伝達して同意タイマーＴ_{ａｇｒｅｅｍｅｎｔ、ｉ}をΔ_１に初期化して再開（ｒｅｓｔａｒｔ）してよい。

【0048】

図３は、一実施形態における、ビューチェンジプロトコルのメッセージ通信段階を説明するための図である。

【0049】

各プロセスｉは、プライマリのビザンチン障害が疑われれば、ビューチェンジプロトコルを開始してよい。各プロセスｉは、プライマリのビザンチン障害を判断するために同意タイマーＴ_{ａｇｒｅｅｍｅｎｔ、ｉ}を使用してよい。各プロセスｉは、クライアント要請を実行する前にタイマーＴ_{ａｇｒｅｅｍｅｎｔ、ｉ}が満了（ｅｘｐｉｒｅ）となれば、ビューチェンジプロトコルを開始してよい。ビューチェンジプロトコルは、プロポーズニュービュー（Ｐｒｏｐｏｓｅ Ｎｅｗ Ｖｉｅｗ）とアクセプトニュービュー（Ａｃｃｅｐｔ Ｎｅｗ Ｖｉｅｗ）の２段階で動作してよい。

【0050】

プロポーズニュービュー段階において、各プロセスｉは、現在状態をビューチェンジング（ｃｕｒｒｅｎｔＳｔａｔｅ_ｉ＝ＶＩＥＷ－ＣＨＡＮＧＩＮＧ）に設定し、プロポーズニュービュー（ＰＲＯＰＯＳＥ－ＮＥＷ－ＶＩＥＷ）メッセージ＜＜ＰＲＯＰＯＳＥ－ＮＥＷ－ＶＩＥＷ、ｖ_ｎｅｗ、ｎ_ｌａｓｔ、ｎ_{ｐｒｅｐａｒｅｄ}、Ｈａｓｈ（Ｍ_{ＰＲＥＰＡＲＥ}）、ｉ＞σ_ｉ、ＥＣ_ｌａｓｔ、Ｍ_{ＰＲＥＰＡＲＥ}＞を他のプロセスに送信してビューチェンジタイマーＴ_{ｖｉｅｗ－ｃｈａｎｇｅ、ｉ}を初期化して開始（ｓｔａｒｔ）してよい。ここで、ｖ_ｎｅｗは新たなビュー値（ｎｅｗ ｖｉｅｗ）を、ｎ_ｌａｓｔはｅｘｅｃｕｔｅＩｎｄｅｘ_ｉを、ｎ_{ｐｒｅｐａｒｅｄ}はここ最近に受信した受諾された準備メッセージＭ_{ＰＲＥＰＡＲＥ}で提案された処理番号（ｓｅｑｕｅｎｃｅ ｎｕｍｂｅｒ）を、Ｈａｓｈ（Ｍ_{ＰＲＥＰＡＲＥ}）はｎ_{ｐｒｅｐａｒｅｄ}＝ｎ_ｌａｓｔ＋１の場合にここ最近に受信した準備メッセージＭ_{ＰＲＥＰＡＲＥ}のハッシュ値を、またはｎ_{ｐｒｅｐａｒｅｄ}＝ｎ_ｌａｓｔの場合には、ｎｕｌｌ、ＥＣ_ｌａｓｔはｎ_ｌａｓｔの有効性を証明するための実行証明（Ｅｘｅｃｕｔｉｏｎ Ｃｅｒｔｉｆｉｃａｔｅ）であって、各プロセスｉが受信した２ｆ＋１個の実行メッセージの集合を示す。

【0051】

アクセプトニュービュー段階において、新たなビューｖ_ｎｅｗのプライマリに該当するプロセス（新たなプライマリ）ｐ’はプロセスｐ’を含み、２ｆ＋１個以上の他のプロセスから同じｖ_ｎｅｗを有するプロポーズニュービュー（ＰＲＯＰＯＳＥ－ＮＥＷ－ＶＩＥＷ）メッセージを受信する場合、次の一連の作業を実行してよい。

【0052】

新たなビューｖ_ｎｅｗのプライマリに該当するプロセスｐ’は、アクセプトニュービュー（ＡＣＣＥＰＴ－ＮＥＷ－ＶＩＥＷ）メッセージ＜＜ＡＣＣＥＰＴ－ＮＥＷ－ＶＩＥＷ、ｖ_ｎｅｗ、ｎ_ｎｅｗ、ｐ’＞σ_ｐ’、ＶＣＣ_ｎｅｗ、ＥＣ_ｍａｘ＞メッセージを他のすべてのプロセスとクライアントに送信してよい。ここで、ｎ_ｎｅｗは、新たなビューｖ_ｎｅｗで最初に合意される処理番号（ｓｅｑｕｅｎｃｅ ｎｕｍｂｅｒ）であって、２ｆ＋１個プロポーズニュービューメッセージのｎ_ｌａｓｔのうちから最大値を探索した後に１を加えた値に設定され、ＶＣＣ_ｎｅｗは、ビューチェンジの有効性を証明するためのビューチェンジ証明（Ｖｉｅｗ Ｃｈａｎｇｅ Ｃｅｒｔｉｆｉｃａｔｅ）であって、ＥＣ_ｌａｓｔとＭ_{ＰＲＥＰＡＲＥ}が除去された２ｆ＋１個のプロポーズニュービューメッセージの集合、ＥＣｍａｘは、２ｆ＋１個プロポーズニュービューメッセージのうちで最も大きいｎ_ｌａｓｔを有するＥＣ_ｌａｓｔを示す。

【0053】

また、新たなビューｖ_ｎｅｗのプライマリに該当するプロセスｐ’は、他のプロセスとクライアントから受信された２ｆ＋１個のプロポーズニュービューメッセージのうちからｎ_{ｐｒｅｐａｒｅｄ}値が最大であるメッセージを探索し、探索されたメッセージの最大値がｎ_ｎｅｗと同じであればｒｅｓｅｒｖｅｄＰｒｅｐａｒｅ_ｉを前記メッセージに含まれたクライアント要請メッセージｍに設定し、ｎ_{ｐｒｅｐａｒｅｄ}の最大値がｎ_ｎｅｗよりも小さければｒｅｓｅｒｖｅｄＰｒｅｐａｒｅ_ｉをｎｕｌｌに設定してよい。条件を満たすクライアント要請メッセージが２つ以上であれば最も多い数のプロポーズニュービューメッセージに含まれたｍを選択し、同数であれば任意に選択してよい。

【0054】

各プロセスｉは、新たなプライマリｐ’からアクセプトニュービューメッセージを受信すれば、次の一連の作業を実行してよい。各プロセスｉは、ｖ_ｎｅｗ＞ｃｕｒｒｅｎｔＶｉｅｗ_ｉであればｃｕｒｒｅｎｔＶｉｅｗ_ｉ＝ｖ_ｎｅｗに設定し、ビューチェンジタイマーＴ_{ｖｉｅｗ－ｃｈａｎｇｅ、ｉ}を中断（ｓｔｏｐ）し、同意タイマーＴ_{ａｇｒｅｅｍｅｎｔ、ｉ}をΔ_１に初期化して再開（ｒｅｓｔａｒｔ）し、現在状態をｃｕｒｒｅｎｔＳｔａｔｅ_ｉ＝ＲＥＡＤＹに設定してよい。

【0055】

また、各プロセスｉは、状態不一致（ｓｔａｔｅ ｉｎｃｏｎｓｉｓｔｅｎｃｙ）が見つかれば、クライアント要請に対するここ最近の作業を取り消し（ｕｎｄｏ）てロールバック（ｒｏｌｌｂａｃｋ）してよい。各プロセスｉは、受信した実行（ＥＸＥＣＵＴＥ）またはアクセプトニュービュー（ＡＣＣＥＰＴ－ＮＥＷ－ＶＩＥＷ）メッセージを確認して状態不一致（ｓｔａｔｅ ｉｎｃｏｎｓｉｓｔｅｎｃｙ）を見つけることができる。

【0056】

２ｆ＋１個以上の一致した実行メッセージ＜ＥＸＥＣＵＴＥ、ｖ、ｎ、Ｈ、Ｈａｓｈ（ｍ）、ｊ＞σ_ｊを受信した場合、各プロセスｉは、ｎが自身のｅｘｅｃｕｔｅＩｎｄｅｘ_ｉ値と同じであるか（ｎ＝ｅｘｅｃｕｔｅＩｎｄｅｘ_ｉ）、またはｎがｅｘｅｃｕｔｅＩｎｄｅｘ_ｉ＋１であるとき（ｎ＝ｅｘｅｃｕｔｅＩｎｄｅｘ_ｉ＋１）にＨとＨａｓｈ（ｅｘｅｃｕｔｅＨｉｓｔｏｒｙ_ｉ［ｅｘｅｃｕｔｅＩｎｄｅｘ_ｉ］、ｍ）値が一致しなければ（Ｈ≠Ｈａｓｈ（ｅｘｅｃｕｔｅＨｉｓｔｏｒｙ_ｉ［ｅｘｅｃｕｔｅＩｎｄｅｘ_ｉ］、ｍ））状態不一致（ｓｔａｔｅ ｉｎｃｏｎｓｉｓｔｅｎｃｙ）が発生したことを感知することができる。

【0057】

また、各プロセスｉは、有効なアクセプトビューチェンジメッセージ＜＜ＡＣＣＥＰＴ－ＮＥＷ－ＶＩＥＷ、ｖ_ｎｅｗ、ｎ_ｎｅｗ、ｐ’＞σ_ｐ’、ＶＣＣ_ｎｅｗ、ＥＣ_ｍａｘ＞を受信したとき、各プロセスｉは、ｎ_ｎｅｗ値と自身のｅｘｅｃｕｔｅＩｎｄｅｘ_ｉ値が同じであれば（ｎ＝ｅｘｅｃｕｔｅＩｎｄｅｘ_ｉ）状態不一致（ｓｔａｔｅ ｉｎｃｏｎｓｉｓｔｅｎｃｙ）が発生したことを感知してロールバックを実行してよい。

【0058】

図４は、一実施形態における、合意にステートマシンで参加するプロセスの構成を説明するためのブロック図である。

【0059】

メモリ４１０は、コンピュータ読み取り可能な命令語、データ構造、プログラムモジュール、またはその他のデータのような情報の記録のための任意の方法または技術によって実現された揮発性および不揮発性、分離型および非分離型媒体をすべて含んで構成されてよく、プロセス１００の少なくとも１つの他の構成要素と関連する命令語またはデータを記録する。

【0060】

プロセッサ４２０は、中央処理装置、アプリケーションプロセッサ、またはコミュニケーションプロセッサのうちの１つまたはそれ以上を含んでよい。例えば、プロセッサ４２０は、プロセス１００の少なくとも１つの他の構成要素の制御および／または通信に関する演算やデータ処理を実行してよい。

【0061】

図５は、一実施形態における、合意方法を説明するためのフローチャートである。

【0062】

図５の段階５１０で、プロセスｉは、許容可能なイベント発生を探して一連の条件を確認してよい。 段階５２０で、タイムアウトイベントが見つかれば、図６のフローチャートを実行する。 段階５３０で、一致する（２ｆ＋１）プロポーズニュービュー（ＰＲＯＰＯＳＥ－ＮＥＷ－ＶＩＥＷ）メッセージが見つかれば、図７のフローチャートを実行する。 段階５４０で、許容可能なアクセプトニュービュー（ＡＣＣＥＰＴ－ＮＥＷ－ＶＩＥＷ）メッセージが見つかれば、図８のフローチャートを実行する。 段階５５０で、一致する許容可能な準備（ＰＲＥＰＡＲＥ）メッセージが見つかれば、図９のフローチャートを実行する。 段階５６０で、一致する（２ｆ＋１）実行（ＥＸＥＣＵＴＥ）メッセージが見つかれば、図１０のフローチャートを実行する。条件５７０で、許容可能なリクエスト（ＲＥＱＵＥＳＴ）メッセージが見つかれば、図１１のフローチャートを実行する。

【0063】

図６の条件６１０で、同意タイマーによってタイムアウトが発生した場合、プロセスは段階６３０を実行する。

【0064】

プロセスｉは、現在状態をＶＩＥＷ－ＣＨＡＮＧＩＮＧ（ｃｕｒｒｅｎｔＳｔａｔｅ_ｉ＝ＶＩＥＷ－ＣＨＡＮＧＩＮＧ）に設定し、プロポーズニュービュー（ＰＲＯＰＯＳＥ－ＮＥＷ－ＶＩＥＷ）メッセージ＜＜ＰＲＯＰＯＳＥ－ＮＥＷ－ＶＩＥＷ、ｖｎｅｗ、ｎｌａｓｔ、ｎｐｒｅｐａｒｅｄ、Ｈａｓｈ（Ｍ_{ＰＲＥＰＡＲＥ}）、ｉ＞σ_ｉ、ＥＣｌａｓｔ、Ｍ_{ＰＲＥＰＡＲＥ}＞を他のプロセスに送信し、ビューチェンジタイマーをＴ_{Ｖｉｅｗ－Ｃｈａｎｇｅ，ｉ}をΔ_２に初期化して開始する。

【0065】

図６の条件６２０で、ビューチェンジタイマーによってタイムアウトが発生した場合、プロセスは段階６４０を実行する。プロセスは、ニュービュー値を１ずつ増加させ、タイマー値を以前の値の２倍に増加させてよい。

【0066】

図７の段階７１０で、プロセスｉが一致する（２ｆ＋１）プロポーズニュービュー（ＰＲＯＰＯＳＥ－ＮＥＷ－ＶＩＥＷ）メッセージ＜＜ＰＲＯＰＯＳＥ－ＮＥＷ－ＶＩＥＷ、Ｖ_ｎｅｗ、ｎ_ｌａｓｔ、ｎ_{ｐｒｅｐａｒｅｄ}、Ｈａｓｈ（Ｍ_{ＰＲＥＰＡＲＥ}）、ｉ＞σ_ｉ、ＥＣ_ｌａｓｔ、プロセスｉを新たなプライマリとして指定するＭ_{ＰＲＥＰＡＲＥ}＞は、受信した（２ｆ＋１）プロポーズニュービュー（ＰＲＯＰＯＳＥ－ＮＥＷ－ＶＩＥＷ）メッセージのうちで最も大きいｎ_{ｐｒｅｐａｒｅｄ}をもつクライアント要請メッセージｍを探し出し、最も大きいｎ_{ｐｒｅｐａｒｅｄ}がｎ_ｎｅｗと同じときにはｒｅｓｅｒｖｅｄＰｒｅｐａｒｅ_ｉ＝ｍに設定し、最も大きいｎ_{ｐｒｅｐａｒｅｄ}がｎ_ｎｅｗよりも小さいときにはｒｅｓｅｒｖｅｄＰｒｅｐａｒｅ_ｉ＝ｎｕｌｌに設定する。受信された（２ｆ＋１）プロポーズニュービュー（ＰＲＯＰＯＳＥ－ＮＥＷ－ＶＩＥＷ）メッセージで最大ｎが準備された同じクライアント要請メッセージが２つ以上ある場合、ｍは任意に選択されてよい。

【0067】

図７の段階７２０で、プロセスは、アクセプトニュービュー（ＡＣＣＥＰＴ－ＮＥＷ－ＶＩＥＷ）メッセージ＜＜ＡＣＣＥＰＴ－ＮＥＷ－ＶＩＥＷ、Ｖ_ｎｅｗ、ｎ_ｎｅｗ、ｐ’＞σ_ｐ’、ＶＣＣ_ｎｅｗ、ＥＣ_ｍａｘ＞を他のプロセスおよびクライアントに送信する。

【0068】

図８の段階８１０で、プロセスｉが＜＜ＡＣＣＥＰＴ－ＮＥＷ－ＶＩＥＷ、Ｖ_ｎｅｗ、ｎ_ｎｅｗ、ｐ’＞、ＶＣＣ_ｎｅｗ、ＥＣ_ｍａｘ＞メッセージを見つければ、メッセージを検査して、状態に欠陥のない他のプロセスと一致するかを確認する。段階８４０で、プロセスが不一致を発見すれば、クライアント要請のここ最近の実行を取り消してロールバックを実行する。

【0069】

段階８の段階８３０で、プロセスｉは、ｃｕｒｒｅｎｔＶｉｅｗ_ｉ＝Ｖ_ｎｅｗを設定し、ビューチェンジ変更タイマーＴ_{Ｖｉｅｗ－Ｃｈａｎｇｅ、ｉ}を中止し、同意タイマーをΔ_１に初期化することにより、同意タイマーＴ_{ａｇｒｅｅｍｅｎｔ、ｉ}を再開し、現在状態をｃｕｒｒｅｎｔＳｔａｔｅ_ｉ＝ＲＥＡＤＹに設定する。

【0070】

図９の段階９１０で、プロセスｉが許容可能な準備（ＰＲＥＰＡＲＥ）メッセージ＜＜ＰＲＥＰＡＲＥ、ｖ、ｎ、Ｈ、Ｈａｓｈ（ｍ）、ｐ＞、ｍ＞を見つければ、ｃｕｒｒｅｎｔＳｔａｔｅ_ｉ＝ＲＥＡＤＹに設定し、実行（ＥＸＥＣＵＴＥ）メッセージ＜ＥＸＥＣＵＴＥ、ｖ、ｎ、Ｈ、Ｈａｓｈ（ｍ）、ｉ＞を他のプロセスに送信する。

【0071】

図１０の段階１０１０で、プロセスｉが一致する（２ｆ＋１）実行（ＥＸＥＣＵＴＥ）メッセージ＜ＥＸＥＣＵＴＥ、ｖ、ｎ、Ｈ、Ｈａｓｈ（ｍ）、ｉ＞を見つけた場合、メッセージを検査して、状態が他の障害のないプロセスと一致するかを確認する。段階１０４０で、プロセスが状態不一致を発見すれば、クライアント要請のここ最近の実行を取り消してロールバックを実行する。

【0072】

図１０の段階１０１０で、プロセスは、ｅｘｅｃｕｔｅＩｎｄｅｘ_ｉを＋１増加させ、ｅｘｅｃｕｔｅＬｏｇ_ｉ［ｅｘｅｃｕｔｅＩｎｄｅｘ_ｉ］をｍに設定し、ｅｘｅｃｕｔｅＨｉｓｔｏｒｙ_ｉ［ｎ］＝Ｈａｓｈ（ｅｘｅｃｕｔｅＨｉｓｔｏｒｙ_ｉ［ｎ－１］、ｍ、）を設定し、ｃｕｒｒｅｎｔＳｔａｔｅ_ｉ＝ＲＥＡＤＹを設定し、同意タイマーΔ_１を初期化して同意タイマーＴ_{ａｇｒｅｅｍｅｎｔ、ｉ}で再開する。ロールバック予想費用が極めて高いか、とある理由によってロールバックが不可能でない場合、プロセスはクライアント要請ｍを実行して結果を得ることができ、得た結果をリプライ（ＲＥＰＬＹ）メッセージ＜ＲＥＰＬＹ、ｖ、ｔ、ｃ、ｉ、ｒｅｓｕｌｔ＞σ_ｉでクライアントに送信する。そうでない場合、プロセスは、クライアント要請の実行およびクライアント要請に対するリプライ（ＲＥＰＬＹ）メッセージの送信を遅延させてよい。

【0073】

図１１の条件１１１０で、プロセスｉがリクエスト（ＲＥＱＵＥＳＴ）メッセージに対するリプライ（ＲＥＰＬＹ）メッセージを既に送信した場合、プロセスは、段階１１３０と同一のリプライ（ＲＥＰＬＹ）メッセージをクライアントに再送してよい。

【0074】

プロセスｉがリクエスト（ＲＥＱＵＥＳＴ）メッセージｍに対してリプライ（ＲＥＰＬＹ）メッセージを送信しない場合、プロセスは、リクエスト（ＲＥＱＵＥＳＴ）メッセージｍをプライマリにリレーし、段階１１２０のように、同意タイマーをΔ_１に初期化して同意タイマーＴ_{ａｇｒｅｅｍｅｎｔ、ｉ}を再開してよい。

【0075】

実施形態によると、２回のプロセス間の通信段階だけで合意に到達することができるため、３回の通信段階を必要とする従来のＰＢＦＴ（Ｐｒａｃｔｉｃａｌ Ｂｙｚａｎｔｉｎｅ Ｆａｕｌｔ Ｔｏｌｅｒａｎｃｅ）アルゴリズムに比べて向上した処理速度と処理量を提供することができる。

【0076】

実施形態によると、クライアントが介入しなくてもプロセス間の状態不一致（ｓｔａｔｅ ｉｎｃｏｎｓｉｓｔｅｎｃｙ）を感知することができ、従来のＺｙｚｚｙｖａアルゴリズムのクライアント依存性を解決し、状態不一致による費用を改善することができる。

【0077】

実施形態によると、ビザンチン障害およびネットワーク遅延とは関係なく常に２回の通信段階で動作するため、Ｚｙｚｚｙｖａに比べて安定的な性能を提供することができる。また、クライアントが介入しなくてもプロセスが自ら状態不一致（ｓｔａｔｅ ｉｎｃｏｎｓｉｓｔｅｎｃｙ）を感知することができ、特に状態不一致（ｓｔａｔｅ ｉｎｃｏｎｓｉｓｔｅｎｃｙ）が発生したとしても、プロセスが実行した直前の（ｌａｔｅｓｔ）クライアント要請１つに対してのみ発生する。したがって、Ｚｙｚｚｙｖａに比べて状態不一致によって誘発する費用が極めて低いと言える。

【0078】

また、実施形態によると、状態不一致（ｓｔａｔｅ ｉｎｃｏｎｓｉｓｔｅｎｃｙ）を最小化するために、新たなプライマリは、新たなプライマリ自身が受信したプロポーズニュービューメッセージに含まれた準備メッセージを利用して予測の繰り越しを使用することができる。新たなプライマリが受信したプロポーズニュービューメッセージに含まれた準備メッセージがすべて同じであれば、準備メッセージを新たなビュー（ｎｅｗ ｖｉｅｗ）の最初のラウンドで処理して状態不一致（ｓｔａｔｅ ｉｎｃｏｎｓｉｓｔｅｎｃｙ）を防ぐ。相異する準備メッセージが２つ以上見つかる場合には、プライマリの選択によって状態不一致（ｓｔａｔｅ ｉｎｃｏｎｓｉｓｔｅｎｃｙ）が発生することもあるし発生しないこともある。これは、システムが非同期的（ａｓｙｎｃｈｒｏｎｏｕｓ）に動作する状況でプライマリの有効な電子署名を含んだ２つ以上の不一致準備メッセージがプロセスに伝達しなければならない場合に限って発生する。例えば、ビザンチンプライマリが同じ順番に対して２つ以上の不一致準備メッセージを送信し、他のビザンチンプロセスがこれに協調する場合に状態不一致が発生することがある。このような談合は一般的でないため、一般的に状態不一致が発生する可能性はほぼない。

【0079】

また、実施形態によると、遅延実行（ｄｅｆｅｒｒｅｄ ｅｘｅｃｕｔｉｏｎ）によって状態不一致（ｓｔａｔｅ ｉｎｃｏｎｓｉｓｔｅｎｃｙ）によるロールバック（ｒｏｌｌｂａｃｋ）を事前に防ぐ手段を提供することもできる。実行履歴ｅｘｅｃｕｔｅＨｉｓｔｏｒｙを使用するために現在のラウンドで実行段階に進むということは、直前のラウンドで実行された実行（ｅｘｅｃｕｔｉｏｎ）が最終的合意（ｆｉｎａｌ ａｇｒｅｅｍｅｎｔ）状態に到達することを意味する。したがって、以前のラウンドで保留した作業を新たなラウンドの実行段階で実行すれば、以後にはロールバックしなければならない状況が決して発生しない。

【0080】

上述した装置は、ハードウェア構成要素、ソフトウェア構成要素、および／またはハードウェア構成要素とソフトウェア構成要素との組み合わせによって実現されてよい。例えば、実施形態で説明された装置および構成要素は、例えば、プロセッサ、コントローラ、ＡＬＵ（ａｒｉｔｈｍｅｔｉｃ ｌｏｇｉｃ ｕｎｉｔ）、デジタル信号プロセッサ、マイクロコンピュータ、ＦＰＧＡ（ｆｉｅｌｄ ｐｒｏｇｒａｍｍａｂｌｅ ｇａｔｅ ａｒｒａｙ）、ＰＬＵ（ｐｒｏｇｒａｍｍａｂｌｅ ｌｏｇｉｃ ｕｎｉｔ）、マイクロプロセッサ、または命令を実行して応答することができる様々な装置のように、１つ以上の汎用コンピュータまたは特殊目的コンピュータを利用して実現されてよい。処理装置は、オペレーティングシステム（ＯＳ）およびＯＳ上で実行される１つ以上のソフトウェアアプリケーションを実行してよい。また、処理装置は、ソフトウェアの実行に応答し、データにアクセスし、データを記録、操作、処理、および生成してもよい。理解の便宜のために、１つの処理装置が使用されるとして説明される場合もあるが、当業者であれば、処理装置が複数個の処理要素および／または複数種類の処理要素を含んでもよいことが理解できるであろう。例えば、処理装置は、複数個のプロセッサまたは１つのプロセッサおよび１つのコントローラを含んでよい。また、並列プロセッサのような、他の処理構成も可能である。

【0081】

ソフトウェアは、コンピュータプログラム、コード、命令、またはこれらのうちの１つ以上の組み合わせを含んでもよく、思うままに動作するように処理装置を構成したり、独立的または集合的に処理装置に命令したりしてよい。ソフトウェアおよび／またはデータは、処理装置に基づいて解釈されたり、処理装置に命令またはデータを提供したりするために、いかなる種類の機械、コンポーネント、物理装置、仮想装置（ｖｉｒｔｕａｌ ｅｑｕｉｐｍｅｎｔ）、コンピュータ記録媒体または装置に具現化されてよい。ソフトウェアは、ネットワークによって接続されたコンピュータシステム上に分散され、分散された状態で記録されても実行されてもよい。ソフトウェアおよびデータは、１つ以上のコンピュータ読み取り可能な記録媒体に記録されてよい。

【0082】

実施形態に係る方法は、多様なコンピュータ手段によって実行可能なプログラム命令の形態で実現されてコンピュータ読み取り可能な媒体に記録されてよい。前記コンピュータで読み取り可能な媒体は、プログラム命令、データファイル、データ構造などを単独でまたは組み合わせて含んでよい。前記媒体に記録されるプログラム命令は、実施形態のために特別に設計されて構成されたものであっても、コンピュータソフトウェア当業者に公知されて使用可能なものであってもよい。コンピュータ読み取り可能な記録媒体の例としては、ハードディスク、フロッピー（登録商標）ディスク、および磁気テープのような磁気媒体、ＣＤ－ＲＯＭおよびＤＶＤのような光媒体、フロプティカルディスク（ｆｌｏｐｔｉｃａｌ ｄｉｓｋ）のような光磁気媒体、およびＲＯＭ、ＲＡＭ、フラッシュメモリなどのようなプログラム命令を記録して実行するように特別に構成されたハードウェア装置が含まれる。プログラム命令の例は、コンパイラによって生成されるもののような機械語コードだけではなく、インタプリタなどを使用してコンピュータによって実行される高級言語コードを含む。

【0083】

以上のように、実施形態を、限定された実施形態と図面に基づいて説明したが、当業者であれば、上述した記載から多様な修正および変形が可能であろう。例えば、説明された技術が、説明された方法とは異なる順序で実行されたり、かつ／あるいは、説明されたシステム、構造、装置、回路などの構成要素が、説明された方法とは異なる形態で結合されたりまたは組み合わされたり、他の構成要素または均等物によって代替されたり置換されたとしても、適切な結果を達成することができる。

【0084】

したがって、異なる実施形態であっても、特許請求の範囲と均等なものであれば、添付される特許請求の範囲に属する。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】