JP2020048195A - ブロックチェーンネットワークのノード間の合意をなす方法及び複数のノードの分散ネットワークで構成されたブロックチェーンシステム及びブロックチェーンシステムのプロセッサにより実行される複数のノード間の合意をなすための方法 - Google Patents

Abstract

【課題】複数のノードの分散ネットワークで構成されたブロックチェーン上の複数のノード間の合意をなすための方法及びブロックチェーンシステムを提供する。【解決手段】複数のノードの分散ネットワークで構成されたブロックチェーンシステムのプロセッサにより実行される複数のノード間の合意をなすための方法は、ラウンド毎に予め決められた時点にブロック生成地位を有するプロデューサーノードに昇格され得る複数のノードのうち、いずれか１つの第１のノードが第Ｎのラウンドで候補ブロックを受信すること、受信された候補ブロックが有効候補ブロックであるか判断すること、有効候補ブロックが未承認ブロックであるか判断すること、未承認ブロックが最初の受信候補ブロックであるか判断し、未承認ブロックに対する承認投票可否を決定することを含み、最初の受信候補ブロックは、第１のノードが第Ｎのラウンド内で最初に受信した候補ブロックである。【選択図】図２

Description

本発明は、複数のノードの分散ネットワークで構成されたブロックチェーン上の複数のノード間の合意をなすための方法及びブロックチェーンシステムに関する。

ブロックチェーンは、２００８年ナカモト・サトシのＢｉｔｃｏｉｎ：Ａ Ｐｅｅｒ−ｔｏ−Ｐｅｅｒ Ｅｌｅｃｔｒｏｎｉｃ Ｃａｓｈ Ｓｙｓｔｅｍにおいて、ブロックとブロックとを連結する方法に由来する。ブロックチェーンは、ピア（ｐｅｅｒ）に元帳が共有され、ブロック内の内容が透明に公開され、任意に変更が不可能な特性から、暗号貨幣において必須不可欠の技術と認められた。そして、ブロックチェーンは、暗号貨幣のみのための技術でなく、種々の産業分野にわたって活用可能性を見せている。

ブロックチェーンは、ネットワークに参加した各ピアが分散された元帳を共有し、これを管理するために合意アルゴリズムを使用する。ビットコインに代表される初期ブロックチェーン暗号貨幣の場合、ＰｏＷ（Ｐｒｏｏｆ ｏｆ Ｗｏｒｋ）合意アルゴリズムを使用する。これは完全に分散されたネットワークにピアがいつでも参加でき、拡張性が容易であるという長所がある。しかし、合意のためのピアの作業が競争的かつ非常にエネルギー消費的であり、全体のコンピューティング性能が落ちるという短所がある。また、ＰｏＷの特性上、ピアの作業に対する補償が必要なネットワーク構造が求められるので、コインやトークンの概念が必要ないブロックチェーンシステムでは適していない。そのため、種々のブロックチェーンプラットフォームでＰｏＷの短所を克服したＰｏＳ（Ｐｒｏｏｆ ｏｆ Ｓｔａｋｅ）、ＤＰｏＳ（Ｄｅｌｅｇａｔｅｄ Ｐｒｏｏｆ ｏｆ Ｓｔａｋｅ）、ＰＢＦＴ（Ｐｒａｃｔｉｃａｌ Ｂｙｚａｎｔｉｎｅ Ｆａｕｌｔ Ｔｏｌｅｒａｎｃｅ）、Ｃａｓｐｅｒ、Ｔｅｎｄｅｒｍｉｎｔなどのような改善された合意アルゴリズムを研究、開発、及び適用している。

ＰｏＳは、ＰｏＷとは異なり、持分がブロック生成者を決定する要因になる方式であって、エネルギー消費が求められず、ＰｏＷに比べて相対的にトランザクション処理に対する信頼性が高いという長所がある。しかしながら、ＰｏＳは、ＰｏＷと同様に、持分を有した有権者が投票に無関心になれば信頼性が落ちるという問題点を内在している。また、ブロックチェーンが２つに分けられるフォーク現象が発生したとき、持分による投票を介して１つのブロックチェーンを選択するようになる。このとき、分けられたブロックチェーンの全てに投票をしてもノードには損害が発生しないｎｏｔｈｉｎｇ ａｔ ｓｔａｋｅの問題点がある。すなわち、攻撃者が予め他のブロックチェーンを生成しておき、自分がブロック生成権限を得たとき、予め作っておいたブロックチェーンを伝播して強制的にフォークを発生させる。しかし、この場合にも、ノードは、損害を発生しない最も安全な方法である両方に投票するようになるので、結果的にフォーク状況が解決されないことがある。

ＤＰｏＳは、ＰｏＳに基づいた合意アルゴリズムであって、代表者を選出し、代表者達にブロック生成に対する権限を委任するアルゴリズムである。ＰｏＳに比べて速いトランザクション処理速度と拡張性を有し、ブロックチェーンの信頼性がさらに高くなるという長所がある。しかし、ブロックチェーンネットワークの中央集中度が高まり、分散ネットワークの長所が弱まるという短所がある。また、投票参加率が低い場合、相対的に低い持分を介して代表者になり得るという短所があり、代表者達間での談合の危険性、公開された代表者達に対するＤＤｏＳ攻撃の危険がある。

ＰＢＦＴは、既存の分散ネットワークで使用されていた合意アルゴリズムであって、悪意のあるノードがネットワークに参加していても、合意過程を導き出すことができ、非同期分散ネットワークにも適用できるという長所がある。ただし、ノード数が増加すれば、ブロックチェーンシステムの性能低下の問題が発生するので、ブロックチェーンが有するノードの数は、数十個が限界である。

Ｃａｓｐｅｒは、ＰｏＳとＰＢＦＴ基盤の合意アルゴリズムである。イーサリアム（Ｅｔｈｅｒｅｕｍ）は、ブロックチェーンプラットフォームで開発及び適用中のアルゴリズムであって、現在は、ＰｏＷとＰｏＳのハイブリッド（Ｈｙｂｒｉｄ）構造からなっているが、今後、ＰｏＳに切り換えられる予定である。このアルゴリズムは、Ｊｕｓｔｉｆｉｅｄ（認証）とＦｉｎａｌｉｔｙ（最終確定性）の２つの概念を適用してブロックチェーンの信頼性を高め、プロトコルを介して状況に対する安定性を保障する。特に、ＰｏＳの問題点のうちの１つであるｎｏｔｈｉｎｇ ａｔ ｓｔａｋｅを解決し、これを理論的に証明したアルゴリズムである。しかし、実現が複雑であり、速度が相対的に低いという短所がある。

Ｔｅｎｄｅｒｍｉｎｔは、ＤＰｏＳとＰＢＦＴ基盤の合意アルゴリズムである。ＰＢＦＴ合意アルゴリズム過程を介して悪意のあるノードがネットワークに参加しても合意過程が進行され得る構造を有する。また、ブロック生成プロトコルに参加したブロック生成者達に預け金を要求してネットワークで悪意的な行動に対する処罰を行うことにより、ｎｏｔｈｉｎｇ ａｔ ｓｔａｋｅの問題を解決し、ネットワークに対する安定性を高める。可用性を重視するＣａｓｐｅｒとは異なり、さらに高い安定性を提供するのに目的をおいている。しかし、３３％以上の悪意的投票権によってネットワークが遅延する可能性があり、６６％以上の悪意的投票権によって崩れる可能性があるというＰＢＦＴの問題が依然として存在する。

その他にも、ＰｏＥ（Ｐｒｏｏｆ ｏｆ Ｅｘｉｓｔｅｎｃｅ）、ＰｏＥＴ（Ｐｒｏｏｆ ｏｆ Ｅｌａｐｓｅｄ Ｔｉｍｅ）、ＰｏＩ（Ｐｒｏｏｆ ｏｆ Ｉｍｐｏｒｔａｎｃｅ）、Ｓｔｅｌｌａｒ、Ｅｔｈｅｒｅｕｍ ＰｏＡ（Ｃｌｉｑｕｅ）など、多くの合意アルゴリズムがあり、応用される分野（金融、物流、流通、港湾、自動車、データ通信、共有、認証等）、ブロックチェーンシステムの目的によって派生している。

特許文献１：韓国公開特許第１０−２０１７−０１３７３８８号

本発明の目的の１つは、従来のリーダー（Ｌｅａｄｅｒ）モデルでラウンド別の唯一リーダー選択問題及び選択されたリーダーが悪性リーダーである場合の問題を解決できるブロックチェーンネットワークのノード間の合意をなす方法及びブロックチェーンシステムを提供することにある。

また、本発明は、サイドチェーン（Ｓｉｄｅ ｃｈａｉｎ）の発生を防ぎ、Ｆｉｎａｌｉｔｙ（最終確定性）を保障できるブロックチェーンネットワークのノード間の合意をなす方法及びブロックチェーンシステムを提供することを目的とする。

また、本発明の他の目的は、ネットワーク資源を効率的に使用して、早いトランザクション承認を得るようにしたブロックチェーンネットワークのノード間の合意をなす方法及びブロックチェーンシステムを提供することにある。

また、本発明のさらに他の目的は、サイナーノードに対するネットワークの攻撃者の直接的な攻撃に剛健なブロックチェーンネットワークのノード間の合意をなす方法及びブロックチェーンシステムを提供することにある。

また、本発明のさらに他の目的は、プロデューサーノード（リーダー）選択規則を提示しない従来のＰＢＦＴ合意アルゴリズムとは異なり、時間が流れるにしたがってラウンドと許可期間の概念を介してプロデューサーノードを管理できるようにしたシステムを提供することにある。

本発明の一実施形態によると、複数のノードの分散ネットワークで構成されたブロックチェーンシステムのプロセッサにより実行される複数のノード間の合意をなすための方法は、ラウンド別毎に予め決められた時点にブロック生成地位を有するプロデューサーノードに昇格され得る前記複数のノードのうち、いずれか１つの第１のノードが第Ｎのラウンドで候補ブロックを受信すること、受信された候補ブロックが有効候補ブロックであるか判断すること、前記有効候補ブロックが未承認ブロックであるか判断すること、及び前記未承認ブロックが最初の受信候補ブロックであるか判断し、前記未承認ブロックに対する承認投票可否を決定することを含み、前記最初の受信候補ブロックは、前記第１のノードが前記第Ｎのラウンド内で最初に受信した候補ブロックである。

前記未承認ブロックを他のノードに送信すること、及び前記最初の受信候補ブロックを承認する投票情報を他のノードに送信することをさらに含んでもよい。

前記第Ｎのラウンドで生成された未承認ブロックのうち、投票数が既設定値以上である未承認ブロックを承認ブロックと認めることをさらに含んでもよい。

前記第Ｎのラウンドでプロデューサーノードに昇格された全てのノードは、第Ｎ＋１のラウンドでプロデューサーノードの地位が喪失され、前記承認ブロックと認められた候補ブロックを生成したノードの次の順番ノードが第Ｎ＋１のラウンドで１番目のプロデューサーノードに昇格することをさらに含んでもよい。

前記第Ｎのラウンドで複数の未承認ブロックのうち、投票数が既設定値以上である未承認ブロックが存在しない場合、再投票ラウンドを開始すること、及び前記再投票ラウンド期間の間、予め設定された優先順位によって前記複数の未承認ブロックに対する再投票を進行させることをさらに含み、前記再投票ラウンドの間、新しい候補ブロックの生成を中断してもよい。

前記再投票を進行させることは、投票可能な複数のノードが、前記複数の未承認ブロックのうち、既設定値以上の投票数を得た未承認ブロックに対して承認再投票することを含んでもよい。

前記再投票を進行させることは、前記複数の未承認ブロックのうち、既設定値以上の投票数を得た複数の未承認ブロックが存在する場合、前記複数の未承認ブロックの各々を生成したノードのうち、最初の昇格ノードが生成した未承認ブロックに対して承認再投票することをさらに含んでもよく、前記最初の昇格ノードは、前記第Ｎのラウンドでプロデューサーノードへの昇格順序が最も早いノードである。

前記有効候補ブロックであるか判断することは、前記受信された候補ブロックを生成したノードの昇格可否を判断すること、及び前記受信された候補ブロックが昇格されたノードが生成したブロックである場合、前記受信された候補ブロックを有効候補ブロックと認めることを含んでもよい。

前記有効候補ブロックが未承認ブロックであるか判断することは、前記有効候補ブロックに対する既設定値以上の投票結果を含む次のブロックの存否を判断すること、及び前記次のブロックが存在する場合、前記有効候補ブロックを承認ブロックと認めて、前記分散ネットワークに前記承認ブロックに対する同期化を要請することを含んでもよい。

任意のラウンドが進行する間、プロデューサーノードへの昇格の地位を有する複数のノードは、順序どおりに昇格されてもよい。

前記既設定値は、前記複数のノードの個数の２／３に該当してもよい。

前記ラウンド別毎に前記複数のノードの各々は、１回の投票権を有してもよい。

前記複数のノードのうち、いずれか１つのノードが投票情報を受信すること、受信された投票情報の有効性を検証すること、及び有効性が検証された投票情報を他のノードに伝播することをさらに含んでもよい。

特定ラウンドが進行する間、前記複数のノードのうち、いずれか１つのノードは、投票情報を受信すれば、既設定値以上の投票数を取得した候補ブロックの存在可否を判断し、既設定値以上の投票数を取得した候補ブロックが存在すれば、既設定値以上の投票数を得た未承認ブロックを承認ブロックと合意してもよい。

本発明の一実施形態によると、複数のノードの分散ネットワークで構成されたブロックチェーンのプロセッサにより実行される前記複数のノード間の合意をなすための方法は、ラウンド別毎に予め決められた時点にブロック生成地位を有するプロデューサーノードに昇格され得る前記複数のノードのうち、いずれか１つの第２のノードが第Ｎのラウンドで昇格すること、前記第Ｎのラウンド内で前記第２のノードが昇格前候補ブロックの受信可否を判断すること、昇格前候補ブロックの未受信時、新しいブロックが連結される前記ブロックチェーン上の最後のブロック内の投票情報を含む候補ブロックを生成すること、生成された候補ブロックを承認ブロックと認める投票をすること、及び前記候補ブロックと投票情報を他のノードに送信することを含む。

前記第Ｎのラウンドで昇格された前記第２のノードは、他のノードが生成した候補ブロックを受信すること、受信された候補ブロックが有効候補ブロックであるか判断すること、前記有効候補ブロックが未承認ブロックであるか判断すること、及び前記未承認ブロックを他のノードに送信することをさらに含んでもよい。

前記第２のノードが昇格前候補ブロックを受信した場合、前記第２のノードは、前記新しいブロックを生成しなくてもよい。

前記新しいブロックは、前記第Ｎのラウンドで前記新しいブロックを承認ブロックと承認する投票に対する投票数に基づいた、承認ブロックと合意可能なブロックであってもよい。

任意のラウンドが進行する間、プロデューサーノードへの昇格の地位を有する複数のノードは順序どおりに昇格されてもよい。

本発明の一実施形態によると、複数のノードの分散ネットワークで構成されたブロックチェーン上の前記複数のノードが合意規則にしたがって合意データを生成及び伝播して合意をなすための方法は、前記合意データは、候補ブロックデータ及び投票データのうち、少なくとも１つを含み、前記合意規則にしたがって既設定値以上の投票数を得た候補ブロックデータを含む候補ブロックを承認ブロックと合意し、前記承認ブロックは、前記ブロックチェーン上にアップデートされる。

前記合意規則ノードは、受信された合意データを検証すること、投票権を保有したノードは、受信された候補ブロックデータを承認する投票データを生成すること、ブロック生成権を保有したノードは、候補ブロックデータを生成し、ノードは、自分が生成した候補ブロックデータを承認する投票データを生成すること、ノードは、検証された合意データ及び生成した合意データを伝播し、ラウンド別毎に複数のノードが予め決められた順序によって予め決められた時点にプロデューサーノードの地位に昇格すること、前記プロデューサーノードの地位は、昇格時点のラウンドの終了時点まで維持され、前記プロデューサーノード地位の昇格前候補ブロックデータを未受信する規則を含んでもよい。

さらに他の側面において、前記合意データは、候補ブロックデータ及び投票データのうち、少なくとも１つを含み、前記合意データを受信したノードをして前記合意データを検証させ、前記合意データを検証した第１のサイナーノードをして前記検証された合意データ内の少なくとも一部データを他のノードに送信させ、前記合意データを検証した第２のサイナーノードをして検証された候補ブロックデータを承認する投票データを生成させ、前記第２のサイナーノードをして前記検証された合意データ内の少なくとも一部データ及び生成した投票データのうち、少なくとも１つを他のノードに送信させ、昇格前、前記候補ブロックデータを未受信したプロデューサーノードをして候補ブロックデータを生成させてもよく、前記プロデューサーノードをして生成した候補ブロックデータを承認する投票データを生成させてもよい。

本発明に係る実施形態は、従来のリーダー（Ｌｅａｄｅｒ）モデルでラウンド別の唯一リーダー選択問題及び選択されたリーダが悪性リーダーである場合の問題を解決することができる。

また、サイドチェーン（Ｓｉｄｅ ｃｈａｉｎ）の発生を防ぎ、Ｆｉｎａｌｉｔｙ（最終確定性）を保障することができる。

また、ネットワーク資源を効率的に使用して、早いトランザクション承認を得ることができる。

また、サイナーノードに対するネットワークの攻撃者の直接的な攻撃に剛健なブロックチェーンシステムを提供することができる。

また、時間の流れにしたがってラウンドと許可期間の概念を介してプロデューサーノードを管理できるようにしたシステムを提供することができる。

また、ネットワークディレイ（Ｐｒｏｐａｇａｔｉｏｎ ｄｅｌａｙ）に大きい影響を受けるタイムアウト（Ｔｉｍｅｏｕｔ）方式を有した合意アルゴリズムではない、各サイナーが相手時間によって非同期的に投票とブロック生成とを進行するようにし、必ず１つのラウンド内でブロックが決定されるようにすることで、ラウンドに対する相手時間の制限がなく、唯一プロデューサーノードを選出しないようにして早い合意が可能なようにする。

また、ブロック生成者競争方式を介して悪性リーダー問題を解決することができる。

また、コンソーシアム（Ｃｏｎｓｏｒｔｉｕｍ）やプライベート（Ｐｒｉｖａｔｅ）環境に最適化された合意アルゴリズムを提供することができる。

また、ラウンド別に許可期間にプロデューサーノードが生成される方式を介してプロデューサーノードがブロック生成を怠る場合、ブロックチェーンシステムが止まる現象を解決することができ、多量のブロック生成者が存在することを防止することができる。

本発明において得ることができる効果は、以上で言及した効果に限定されず、言及していないさらに他の効果は、下記の記載から明確に理解されることができる。

複数のノードの分散ネットワークで構成されたブロックチェーンシステムに対する概観を示す。 複数のノードの分散ネットワークで構成されたブロックチェーンのプロセッサにより実行される前記複数のノード間の合意をなすための方法を説明するための時間の流れにしたがうノードの昇格を示したタイムテーブルを示す概念図である。 ブロックチェーンに記録されたデータの種類を説明するための概念図である。 ノードが他のノードから候補ブロックを受信したときの合意をなすための方法に関すフローチャートである。 ノードが他のノードから投票情報を受信したとき、ブロックチェーンシステムがどのように駆動されるかを示すフローチャートものである。 サイナーノードがプロデューサーノードに昇格された状態で合意データがネットワーク上で伝播されるとき、合意をなすための方法に関するフローチャートである。 候補ブロックに対する投票数を確認して、候補ブロックを承認ブロックと認めるステップのフローチャートである。 再投票ラウンドを説明するためのフローチャートである。 ビザンチンサイナーノードの重複投票を説明するための概念図である。

本発明は、様々な変換を加えることができ、種々の実施形態を有することができるが、以下では特定の実施形態を図面に例示し、詳細な説明に詳しく説明する。本発明の効果及び特徴、そして、それらを達成する方法は、図面とともに詳しく後述されている実施形態を参照すれば明確になるであろう。しかし、本発明は、以下において開示される実施形態等に限定されるものではなく、様々な形態で実現されることができる。以下の実施形態において、第１、第２などの用語は、限定的な意味ではなく、１つの構成要素を他の構成要素と区別する目的として使用されている。また、単数の表現は、文脈上、明白に異なる意味にならない限り、複数の表現を含む。また、「含む」または「有する」などの用語は、明細書上に記載された特徴または構成要素が存在することを意味するものであり、１つ以上の他の特徴または構成要素が付加される可能性を予め排除するものではない。また、図面では、説明の都合上、構成要素等が、そのサイズが誇張または縮小され得る。

以下、添付された図面を参照して本発明の実施形態を具体的に説明する。図面を参照して説明するとき、同一、又は対応する類似の構成要素は、同じ図面符号を付与し、これについての重複する説明は省略する。

本発明の実施形態を具体的に説明するに先立ち、明細書に登場する用語を定義する。

サイナーノード（Ｓｉｇｎｅｒ Ｎｏｄｅ）：ブロックの有効性を検証できる権限を有することができる。また、プロデューサーノードに昇格されることができる。

プロデューサーノード（Ｐｒｏｄｕｓｅｒ Ｎｏｄｅ）：ブロックを生成できる権限を有することができる。許可期間にサイナーノードの地位からプロデューサーノードの地位に昇格されることができる。また、サイナーノードの役割を兼ねることができる。

許可期間（Ｐｅｒｍｉｓｓｉｏｎ ｐｅｒｉｏｄｅ）：ラウンドで各サイナーノードのプロデューサーノードへの昇格が発生する時間間隔である。

ラウンド（Ｒｏｕｎｄ）：ノード間の合意によってブロックが決定される単位を意味する。そして、ラウンドは、時間軸上の時間概念にしたがう。

相対時間（Ｒｅｌａｔｉｖｅ ｔｉｍｅ）：各サイナーノードが認識する相対時間である。

絶対時間（Ａｂｓｏｕｌｔｅ ｔｉｍｅ）：全てのサイナーノードが共有する現実の時間であって、絶対時間である。

ストップザワールド（Ｓｔｏｐ ｔｈｅ ｗｏｒｌｄ）：ブロックあるいは投票伝播過程で問題が生じてネットワークの動作が止まる時点である。

投票（Ｖｏｔｅ）：１つのラウンド内で生成された候補ブロックのうち、有効な１つのブロック（唯一ブロック）を選択するために、サイナーノードがやり取りする投票である。例えば、あるブロックに２／３以上の投票が収集されれば、そのブロックが選択され得る。

候補ブロック（Ｃａｎｄｉｄａｔｅ Ｂｌｏｃｋ）：チェーンの最後のブロックになり、最終的に承認ブロックと認められることができるブロックと定義される。まだ承認されていない候補ブロックを意味し、ラウンド別毎に生成された候補ブロックのうち、いずれか１つの候補ブロックのみが承認ブロックと認められることができる。

承認ブロック：候補ブロックのうち、合意により最終承認された候補ブロックである。

正式ブロック（Ｃａｎｏｎｉｃａｌ Ｂｌｏｃｋ）：以後、絶対にロールバックされないことと保障されるブロックを意味する。承認ブロックが、以後、絶対にロールバックされないことが保障されれば、正式ブロックになる。承認ブロックと正式ブロックとの区分は時々曖昧でありうる。第１の承認ブロックの次に連結された第２の承認ブロックが存在する場合、第１の承認ブロックは、正式ブロックになることができる。正式ブロックの認定に厳格性を加えるならば、第１の承認ブロックの次に連結された２個以上の承認ブロックが存在するとき、初めて第１の承認ブロックは、正式ブロックになることができる。

ペアレントブロック（Ｐａｒｅｎｔ Ｂｌｏｃｋ）：任意のブロックが参照する自分のすぐ前のブロックである。

リーダーブロック（ｌｅａｄｅｒ Ｂｌｏｃｋ）：１つのラウンドで作られた複数個の候補ブロックのうち、各ノードの判断において承認ブロックになることができる最も有力なブロックである。

ビザンチンノード（Ｂｙｚａｎｔｉｎｅ Ｎｏｄｅ）：規則にしたがわないサイナーノードあるいはプロデューサーノードを意味する。規則にしたがうサイナーノードあるいはプロデューサーノードであっても、システムダウンなどで、すべきことをすることができなければ、ビザンチンノードと取り扱われることがある。正直なサイナーノードは、自分が正直であるということを証明するために最善を尽くさなければならない。ここでの最善とは、合意データを受信したノードが合意データの有効性を検証し、合意データを他のノードに伝播するコンピューティング活動を尽くすことである。また、最善とは、合意データを生成したノードがこれを他のノードに伝播するコンピューティング活動を尽くすことである。また、最善のコンピューティング活動量は、ノード自体のコンピューティングパワーによって変わることができる。

２／３投票数：投票可能なノードのうち、２／３だけの数のノードが投票権を行使ことを意味する。

メジャーグループ（Ｍａｊｏｒ ｇｒｏｕｐ）：ラウンドで同じブロックに投票したサイナーノードのうち、最上位グループを意味する。また、承認グループ（Ｃａｎｏｎｉｃａｌ ｇｒｏｕｐ）の候補を意味する。

図１は、複数のノードの分散ネットワークで構成されたブロックチェーンシステムに対する概観を示す。

以下において説明するシステムは、ネットワーク上でピアツーピア（ｐｅｅｒ−ｔｏ−ｐｅｅｒ；Ｐ２Ｐ）ネットワークアーキテクチャ構造をなす。すなわち、システムに参加するユーザらは、みんな同等な地位を有しており、特別なノードは存在せず、全てのノード（ノード１〜ノードｎ）がネットワークサービスを構成する役割を分担する。ネットワーク上の種々のノード１００は、互いに同等なトポロジーを有しながら、網ネットワークで互いに接続される。ネットワーク内にあるノードが互いに同等な位置にあるとしても、支援する機能によって各自の役割は相違してもよい。

全てのノードは、ネットワーク内にルーティング機能を保有しており、他の機能を含むこともできる。全てのノードは、取引やブロックに関するデータをはじめとして、各種データを検証し、伝播し、隣接ノードとの接続を維持する機能を果たすことができる。ここでの取引とは、金銭的な取引や仮想貨幣の取引だけでなく、スマートコントラクトによる各種取引を全て含む。したがって、本明細書における取引の意味が特定の取引に限定されないことに注意しなければならない。

ユーザは、一般の個人から組織、コミュニティ、大規模集団に達するまで多様であり、他の類型の個体を含むことができる。

ネットワークに接続されたノード１００は、サイナーノード１１０とプロデューサーノード１２０とになることができ、その他、プロトコルを稼動するノードを接続させるプロトコルゲートウェイが含まれてもよい。

新しいノードがシステムに参加するために、まず、ネットワーク上に存在する他のノードを検索することができる。このようなプロセスを始めるために、新しいノードは、既存にネットワーク上に存在するノードを少なくとも１個は検索して、自分と検索されたノードとを接続することができる。新しいノードが既知の隣接ノードに接続されるために、各ノードは、特定番号のポートでＴＣＰコネクションを接続したり、代案ポートで接続することができる。新しいノードは、接続要請メッセージを隣接ノードに送信し、隣接ノードは、接続要請を承認する場合、承認メッセージを新しいノードに送信することにより、隣接ノードからの接続要請に応答することができる。１つ以上の接続が成立したら、新しいノードは、自分のＩＰ住所が入っているアドレスメッセージを隣接ノードに送信することができる。隣接ノードは、送信されたアドレスメッセージをそれらの隣接ノードに順に送信することにより、新しく接続されたノードがよりよく知られ、他のノードとよりよく接続させることができる。また、新しく接続されたノードは、アドレス要請メッセージを隣接ノードに送り、他の隣接ノードのＩＰ住所目録を再度送信することを要請することができる。このような方式を介してノードは、自分と接続されている隣接ノードを検索することができ、他のノードが自分を検索できるように自分の存在をネットワーク上に広報することができる。

複数のノード１００のうち、少なくとも一部のノードは、ブロックチェーン全体の複写本または少なくともブロックチェーンの部分集合に該当する複写本を有することができる。

ブロックチェーンは、トランザクション（取引）で構成される変更不可能なブロックで構成された分散型コンピュータシステムで構成される。ブロックチェーンを構成する各ブロックは、以前のブロックのハッシュを含むので、ブロックが共に連結されて、始めからブロックチェーンに書かれた全てのトランザクションのレコードを生成する。ブロックは、以前のブロックに従属的に連結されているので、解体、修正、及び再構成がほとんど不可能であり、ノードが各自保有するので、分散され、堅固である。一部の実施形態において、１つのブロックには、少なくとも１つの取引内訳が記録される。取引内訳は、ハッシュで計算されて、偽変造が発生しないように構成されることができる。各ブロックと取引は、ハッシュ値、データ発生時点のタイムスタンプ（ｔｉｍｅｓｔａｍｐ）を管理することにより、偽変造を防ぎ、取引内訳を追跡することができる。また、仮想貨幣などのような金銭的な手段の取引関係において、ノード１００は、ブロックチェーン元帳と財布アプリケーションとを格納し、ユーザが安全かつ信頼性のある方式でネットワークを介しての取引や他の関連機能を果たすことができるようにする。

それぞれのノードは、全てのプログラミング言語を読み込むことができるようにサーバ、インターフェース、システム、データベース、エージェント、ピア、エンジン、コントローラ、または個別的に或は集合的に作動するその他の類型のコンピュータ装置を含むか、コンピュータ装置等の適切な組み合わせで構成されることができる。コンピュータ装置は、非一過性のコンピュータ読み取り可能記録媒体（例えば、ハードドライブ、ソリッドステートドライブ、ＲＡＭ、フラッシュ、ＲＯＭ等）上に格納されたソフトウェア命令を実行するように構成されたプロセッサを備えることができる。望ましくは、コンピュータ装置が後述する各種機能を提供できるようにソフトウェア命令が構成される。また、開示された技術は、開示されたステップをプロセッサに実行させるソフトウェア命令を格納する非一過性のコンピュータ読み取り可能媒体を含むコンピュータプログラム製品として実現されることができる。望ましくは、様々なサーバ、システム、データベース、及びインターフェースは、ＨＴＴＰ、ＨＴＴＰＳ、ＡＥＳ、公開／個人キー交換、ウェブサービスＡＰＩ、知られた金融取引プロトコル、または他の電子基盤の標準化されたプロトコル、若しくはアルゴリズムを使用してデータを交換することができる。望ましくは、データ交換は、パケット交換ネットワーク、インターネット、ＬＡＮ、ＷＡＮ、ＶＰＮ、または他の類型のパケット交換ネットワークを介して行われることができる。

図２は、複数のノードの分散ネットワークで構成されたブロックチェーンシステムのプロセッサにより実行される複数のノード間の合意をなすための方法を説明するための時間の流れにしたがうノードの昇格を示したタイムテーブルであり、図３は、ブロックチェーンに記録されたデータの種類を説明するための概念図である。

図２に示すように、タイムテーブルは、ラウンド別に区分されることができる。すなわち、１つのラウンドが開始され、開始されたラウンドが終了されると、次のラウンドが始まる。ラウンドのそれぞれの時間間隔は同一であってもよいが、これに限定されるものではない。また、ＮラウンドとＮ＋１ラウンドとの間には再投票ラウンドが存在してもよい。再投票ラウンドは、Ｎラウンドで未合意状態の場合に発生する。再投票ラウンドの時間間隔は、未合意状態が合意状態に変更されれば終了される。そして、再投票ラウンドが終了されると、次のラウンドであるＮ＋１ラウンドが開始されてもよい。また、次のラウンドであるＮ＋１ラウンドは、再投票が終了される前までは開始されなくてもよい。

ラウンド毎に複数の許可期間が存在してもよい。許可期間の開始時点にサイナーノードがプロデューサーノードに昇格され、プロデューサーノードの地位は、許可期間の終了時点まで持続される。許可期間の終了時点は、当該ラウンドの終了時点と一致する。プロデューサーノードに昇格が可能なノードのそれぞれの許可期間の開始時点は互いに異なっていてもよい。したがって、ラウンド毎のプロデューサーノードの地位の持続期間は、プロデューサーノード毎に異なっていてもよい。

ネットワークに参加した複数のノード１００のうち、少なくとも一部のノードは、サイナーノード１１０に割り当てられる。そして、サイナーノード１１０のうち、少なくとも一部のノードは、ラウンド内でプロデューサーノード１２０への昇格の地位を有する。一部の実施形態において、サイナーノード１１０のうち、少なくとも一部は、順序どおりにプロデューサーノード１２０に昇格されてもよい。例えば、第１〜第ｎのサイナーノード１１０は、順序どおりに自分の許可期間の開始時点にプロデューサーノード１２０に昇格されてもよい。したがって、第１のサイナーノードが昇格された後、第２のサイナーノードが昇格され、その後、第３のサイナーノードが昇格されてもよい。特定ラウンドで昇格されたノードは、当該ラウンドが終了されると、昇格地位を一斉に喪失してもよい。一部の実施形態において、同じ時間間隔をおいてノードが昇格されてもよいが、これに限定されるものではない。

また、サイナーノード１１０のうち、プロデューサーノード１２０に昇格されることができるサイナーノード１１０は特に限定されるものではない。すなわち、全ラウンドにわたって全てのサイナーノード１１０は、プロデューサーノード１２０に昇格されてもよい。

次のラウンドであるＮ＋１ラウンドでは、Ｎラウンドで一番最後に昇格されたプロデューサーノードの次の順番であるサイナーノードが１番目のプロデューサーノードになってもよい。

他の側面において、図２に示されたように、Ｎラウンドで承認ブロックと認められた候補ブロックを生成したプロデューサーノードの次の順番のサイナーノードまたはプロデューサーノードがＮ＋１ラウンドの最初の昇格ノードになってもよい。すなわち、以前のラウンドの承認ブロックを生成したプロデューサーノードの次の順番のノードが次のラウンドの１番目のプロデューサーノードとなる。これは、次のラウンドで昇格されるノードの事前予測を困難にし、システムの保安性を向上させる。

一方、リーダーブロックのタイムスタンプ（ｔｉｍｅｓｔａｍｐ）を基準に、許可期間によってサイナーノードのプロデューサー昇格時点を決定してもよい。そして、サイナーノードは、相対時間を使用して昇格時点を自ら判断してもよい。そして、絶対時間を基準とみれば、サイナーノードは、互いに異なるプロデューサーノード目録を有していてもよい。また、ラウンドにおいて時間が経過するほど、より多くのプロデューサーノードが活動するようになる。

図３に示すように、ブロックチェーンを構成する各ブロックは、公開帳簿であるブロックチェーンに取引を含めるために、引きまとめたコンテナデータ構造になってもよい。ブロックは、メタデータを入れているヘッダと、その後にブロックサイズを決定する取引目録が長く並べられることができる。ブロックヘッダのサイズは、数十バイトであるのに対し、取引目録の平均サイズは、少なくとも数百バイトになってもよいが、これに限定されるものではない。平均的に各ブロックには、数百個の取引が入ることができるが、これに限定されるものではない。

ブロックヘッダは、ブロックメタデータ等の集合で構成されてもよい。ブロックヘッダには、現在ブロックがブロックチェーンにある以前のブロックと連結されたことを表す以前ブロックハッシュ値があってもよい。また、ブロックヘッダにはタイムスタンプがあってもよい。また、ブロックヘッダにはマックルツリールートがあってもよい。マックルツリールートは、ブロック内で取引全部を効率的に要約するために使用されるデータ構造である。

ブロックの主要識別子は、デジタル指紋の役割をする暗号化ハッシュになってもよい。例えば、暗号化ハッシュは、ＳＨＡ２５６アルゴリズムを介してブロックヘッダを２回ハッシングして得られる。ブロックハッシュは、唯一かつ確実な方法で当該ブロックを識別できるようにし、全てのノードは、ブロックヘッダを簡単にハッシングすることにより、独立的にブロックハッシュ値を得ることができる。ブロックを識別できる２番目の方法は、ブロックチェーン内での位置を把握することである。すなわち、ブロック高さを把握することである。生成された１番目のブロックは、ブロック高さが０であり、次のブロックで参照するブロックハッシュ値は、１番目のブロックを指している。

また、ブロックヘッダには、以前のブロックの投票情報が含まれてもよい。すなわち、以前のブロックが予め設定された投票数以上の投票を得て、最終承認されたブロックであることを確認できる以前のブロックと関連した投票情報が現在ブロックのブロックヘッダに含まれてもよい。

複数のノード１００は、合意データを生成でき、複数のノード１００間で合意データが伝播される。

合意データは、候補ブロックデータを含んでもよい。候補ブロックデータは、候補ブロックを構成するデータである。

合意データは、投票データを含んでもよい。投票データは、投票情報を構成するデータである。

ラウンド毎に生成された合意データは、複数のノード１００間で伝播されながら合意をなすようになる。具体的には、ラウンド毎に生成された複数の候補ブロックのうち、いずれか１つの候補ブロックを承認ブロックと認める合意がなされる。合意のための意思決定は、複数のノード１００のそれぞれの投票によりなされる。すなわち、複数の候補ブロックのうち、最も多い投票数を得た候補ブロックが承認ブロックとして合意される。他の側面において、予め設定された基準値以上の投票数を得た候補ブロックが承認ブロックとして合意される。ここでの予め設定された基準値以上の投票数は、投票に参加できるノードの個数から２／３ノード個数だけの投票数であってもよいが、これに限定されるものではない。このように合意された承認ブロックは、ブロックチェーン上にアップデートされながら既存のブロックチェーン上の最後のブロックに続いて連結される。

合意のための意思決定は、予め設定された合意規則にしたがってなされる。ブロックチェーンシステムに参加することを望むノードがブロックチェーンシステムに接続すると、ブロックチェーン駆動のためのプログラムをダウンロードして自分のノードに設置するようになる。そして、ブロックチェーン駆動のためのプログラムは、当該ノードがブロックチェーンネットワーク上で合意規則にしたがって駆動できるようにする。したがって、ブロックチェーン駆動のためのプログラムは、合意規則にしたがって当該ノードがブロックチェーンシステムの一構成要素として駆動するようにプログラムされる。

図４は、本発明の実施形態に係る合意をなすための方法に対するフローチャートであって、ノードが他のノードから候補ブロックを受信したときの合意をなすための方法に関するものである。

ノードが受信した合意データは、候補ブロックデータになってもよい。

図４に示すように、本発明の実施形態に係る合意をなすための方法（Ｓ１００）においてノードは、受信した候補ブロックデータ（Ｓ１１０）及びブロックチェーンに基づいて、受信した候補ブロックデータの有効性を検証する（Ｓ１２０）。すなわち、ノードは、受信した候補ブロックが有効候補ブロックであるか判断することができる。具体的に、ノードは、受信した候補ブロックを生成したノードが昇格されたプロデューサーノードの地位下で生成したノードであるかを判断することができる。これを満たさない場合、ノードは、受信した候補ブロックを廃棄することができる（Ｓ１２１）。これを満たす場合であれば、ノードは、受信した候補ブロックを有効候補ブロックと認める。他の側面において、ノードは、受信した候補ブロックが過去ラウンドで生成された候補ブロックに過ぎず、過去ラウンドで生成された他の候補ブロックが（受信した候補ブロックでない他の候補ブロック）ブロックチェーン上で承認ブロックと認められた場合であれば、受信した候補ブロックを廃棄することができる（Ｓ１２１）。

ノードが受信した候補ブロックが有効候補ブロックと認められると、ノードは、有効候補ブロックが未承認ブロックであるかを判断する（Ｓ１３０）。例示的に、ノードは、有効候補ブロックに対する既設定値以上の投票結果を含む次のブロックの存否を判断する。そして、このような次のブロックが存在する場合、当該有効候補ブロックを承認ブロックと認めて、分散ネットワーク上に当該承認ブロックの同期化を要請する（Ｓ１３１）。一部の実施形態において、有効候補ブロックに対する２／３以上の投票が収集され、これをペアレントブロック（父母ブロック）として、その投票を含めた次のブロックが存在する場合、有効候補ブロックは、承認ブロックと認められることができる。

他の側面において、受信した候補ブロックが現在ラウンドで承認ブロックと認められたブロックであれば、ノードは分散ネットワーク上に当該承認ブロックの同期化を要請することもできる。すなわち、受信した候補ブロックが現在ラウンドで既設定値の承認投票数を得た承認ブロックであれば、ノードはネットワークに当該承認ブロックの同期化を要請することができる。合わせて、現在ラウンドで投票権を行使しなかったノード（それ以前に候補ブロックを受信しなかったノード）であるとしても、現在ラウンドで承認された承認ブロックを受信することができる。このような現象は、ネットワークの状態（Ｐｒｏｐａｇａｔｉｏｎ ｄｅｌａｙ等）によって現在ラウンドで既に特定候補ブロックが承認ブロックと認められたにもかかわらず、全てのノードが一時に当該承認ブロックの存在を把握することができない場合があるためである。

ノードが有効候補ブロックを未承認ブロックと判断すると、ノードは、現在ラウンドにおける最初の受信候補ブロックであるか否かを判断する（Ｓ１４０）。すなわち、Ｎラウンドでノードが受信した候補ブロックが未承認ブロックでありながらも、Ｎラウンドで最初に受信した未承認ブロックであるか否かを判断する。

未承認ブロックが最初の受信候補ブロックでなければ、ノードは、未承認ブロックを他のノードに伝播する（Ｓ１４１）。一方、未承認ブロックが最初の受信候補ブロックであれば、ノードは、最初の受信候補ブロックを承認する投票情報を生成することができる（Ｓ１５０）。そして、ノードは、最初の受信候補ブロック及び投票情報のうち、少なくとも１つを他のノードに伝播する（Ｓ１６０）。

一方、各ラウンド毎にノードの各々は、自分の投票権を１回行使することができる。そして、ノードの各々は、各ラウンドで最初に受信した候補ブロックに対してのみ自動で投票する。特定ラウンドで投票権を行使したノードが次のラウンドになる前に再度候補ブロックを受信し、受信した候補ブロックが未承認ブロックであるとしても、当該候補ブロックにはさらに投票しない。

図５は、本発明の実施形態に係る合意をなす方法に対するフローチャートであって、ノードが他のノードから投票情報を受信したとき、ブロックチェーンシステムがどのように駆動されるかを示すものである。

図５に示すように、本発明の実施形態に係る合意をなすための方法（Ｓ２００）において、ノードが受信した合意データは、投票データになることができる。

ノードは、他のノードから投票データを含む投票情報を受信する（Ｓ２１０）。

ノードは、受信した投票データの有効性を検証する（Ｓ２２０）。すなわち、ノードは、他のノードから受信した投票情報の有効性を検証する。具体的には、ノードは、受信した投票が現在ラウンドで生成された候補ブロックに対する投票情報であるか否かを判断することができる。ノードは、受信した投票が過去ラウンドで生成された候補ブロックに対する投票情報であれば、当該投票情報を廃棄する（Ｓ２２１）。

一方、ノードが受信した投票情報が現在ラウンドで生成された候補ブロックに対する投票の場合であれば、ノードは、受信した投票情報を他のノードに伝播する（Ｓ２３０）。

一方、投票情報は、ブロックナンバー、ブロックハッシュ、タイムスタンプ、サイナーノードの固有識別情報、ノードの署名情報、再投票情報を含むことができる。具体的に、特定候補ブロックを承認する投票情報である場合、ブロックナンバーは、前記特定候補ブロックを称するナンバーであり、ブロックハッシュは、前記特定候補ブロックのブロックハッシュである。そして、ノードの固有識別情報とノードの署名情報とは、前記特定候補ブロックを承認したノードの固有識別情報及び署名情報であってもよい。また、再投票情報は、投票情報が再投票ラウンドで生成されたことであるかを区別可能にする情報であってもよい。

図６は、本発明の実施形態に係る合意をなすための方法のフローチャートであって、サイナーノードがプロデューサーノードに昇格された状態で合意データがネットワーク上で伝播されるとき、合意をなすための方法に関するものである。

図６を参照して、本発明の実施形態に係る合意をなすための方法（Ｓ３００）を説明する。

許可期間の間、サイナーノードがプロデューサーノードに昇格される（Ｓ３１０）。

Ｎラウンドでプロデューサーの地位に昇格されたノードは、Ｎラウンド内で昇格前候補ブロックを受信したかを判断する（Ｓ３２０）。

プロデューサーノードは、昇格前に既に候補ブロックを受信していれば、新しい候補ブロックを生成しない。

これとは異なり、プロデューサーノードは、昇格前に候補ブロックを受信していなければ、新しい候補ブロックを生成する（Ｓ３３０）。

一部の実施形態において、サイナーノードがプロデューサーノードに昇格された後、ネットワーク状態によって候補ブロックを生成できないことがある。例えば、コンピューティングパワー問題やその他の原因でブロックチェーン上の以前のブロックの投票情報を収集できないか、取引を収集できなければ、候補ブロックを生成できない。したがって、プロデューサーノードが必ず１つの候補ブロックを生成することと限定されるわけではない。

プロデューサーノードは、候補ブロックを生成しながら、以前のラウンドで承認された承認ブロックの投票情報を新しく生成した候補ブロックに含めることができる。また、プロデューサーノードは、新しい候補ブロックに取引内訳を含めることができる。この場合、プロデューサーノードは、ネットワーク内の取引内訳を収集し、収集した取引内訳を新しい候補ブロックに含めることができる。

プロデューサーノードは、新しい候補ブロックを承認する投票情報を生成する（Ｓ３４０）。すなわち、プロデューサーノードは、自分が生成した候補ブロックを承認ブロックと認める承認投票を自動で行う。合わせて、プロデューサーノードがこのように投票権を行使すれば、当該ラウンドで再投票ラウンドが開始されない限り、それ以上の投票が進行しない。

プロデューサーノードは、新しい候補ブロックと投票情報のうち、少なくとも１つを他のノードに伝播する（Ｓ３５０）。

その後、プロデューサーノードが他のノードから候補ブロックを受信（Ｓ３６０）すると、受信した候補ブロックの有効性を検証する（Ｓ３７０）。プロデューサーノードは、有効性が検証されなかった候補ブロックを廃棄する（Ｓ３７１）。

プロデューサーノードは、有効性が検証された有効候補ブロックが未承認ブロックであるか否かを判断する（Ｓ３８０）。プロデューサーノードは、有効候補ブロックが既に承認された承認ブロックである場合、他のノードにブロックチェーン同期化を要請する（Ｓ３８１）。

プロデューサーノードは、未承認ブロックを他のノードに伝播する（Ｓ３９０）。

図７は、本発明の実施形態に係る合意をなすための方法に対するフローチャートであって、候補ブロックに対する投票数を確認して、候補ブロックを承認ブロックと認めるステップのフローチャートである。

図７を参照して、合意をなすための方法（Ｓ４００）を説明する。

Ｎラウンドでネットワーク上における投票情報の伝播によってノードの各々は、候補ブロックに対する投票情報を収集する（Ｓ４１０）。ノードの各々は、収集された投票情報に基づいて候補ブロックの各々に対する承認投票数を確認し、これに基づいて第１の既設定値の投票数を取得した候補ブロックが存在するか否かを判断する（Ｓ４２０）。また、ネットワークに参加したノードの目録は、ノード間で伝播されるので、ノードの各々は投票数の算定が可能である。

ネットワークに参加したノードのうち一部ノードに対してのみサイナーノードに割り当てられた場合、当該サイナーノードのみが投票権を有する場合であれば、前記ノードの目録は、サイナーノードに対する目録になってもよい。また、ノードの目録は、ノードを識別できる情報を含んでもよいが、これに限定されるものではなく、ノードの目録は、単に投票が可能なノードの個数情報であってもよい。また、ノードの目録は、現在ラウンドでプロデューサーノードへの昇格が可能なノードの目録を含んでもよい。ラウンド別に許可期間が設定されるので、ラウンド別に昇格可能なノードに関する情報を当該ラウンドの開始時点に把握することもできる。

Ｎラウンドで、ノードの各々は、Ｎラウンドで生成された候補ブロックのうち、第１の既設定値の承認投票を得た候補ブロックを承認ブロックと認める（Ｓ４３０）。そして、ノードが候補ブロックを承認ブロックと認めると、当該候補ブロックをブロックチェーンにアップデート（Ｓ４４０）し、承認ブロックをネットワークに伝播する（Ｓ４５０）。

他の側面において、Ｎラウンドで、ノードの各々は、Ｎラウンドで生成された候補ブロックのうち、いずれか１つの候補ブロックが第１の既設定値の承認投票を得たことと確認（Ｓ４２０）すると、当該候補ブロックを承認ブロックと認めて、自分のブロックチェーンにアップデートしてもよい（Ｓ４３０）。そして、当該承認ブロックは、ネットワークに伝播してもよい（Ｓ４４０）。ここでの第１の既設定値の投票数を得た候補ブロックとは、投票可能なノードのうち、２／３が承認した候補ブロックを意味するが、提示した第１の既設定値に制限されるものではない。

一部の実施形態において、Ｓ４２０ステップでノードが第１の既設定値の投票数を取得した候補ブロックが存在しないと判断した場合、ノードは、現在ラウンドであるＮラウンドの終了可否を判断する（Ｓ４２１）。Ｎラウンドが終了されない場合であれば、ノードは、引続き投票情報及び候補ブロックのうち、少なくとも１つを受信し続ける状態であるから、追加的に収集（Ｓ４１０）される投票情報を利用して第１の既設定値の投票数を取得した候補ブロックの存否を判断する（Ｓ４２０）。

図８は、本発明の実施形態に係る合意をなすための方法に対するフローチャートであって、再投票ラウンドを説明するためのフローチャートである。

図８に示すように、Ｎラウンドが終了された場合であれば、再投票ラウンドが進行される（Ｓ５００）。

再投票ラウンドにより最も優先順位の高い候補ブロックが承認ブロックと合意されることができる。優先順位が高い候補ブロックに対する例示は、次のとおりである。現在ラウンドで最も多い投票数を得た候補ブロックまたは複数の再投票過程のうち、以前の再投票過程で最も多い投票数を得た候補ブロックが優先順位が高くてもよい。投票数が同一であれば、プロデューサーノードへの昇格順序が早いほど、優先順位が高くてもよい。すなわち、優先順位が高いプロデューサーノードが生成した候補ブロックの優先順位が高くてもよい。

再投票ラウンドの開始のため、次のラウンドであるＮ＋１番目のラウンドは開始されない。Ｎ＋１番目のラウンドは、再投票ラウンドの終了後に開始されることができる。

再投票ラウンドが進行する間には、新しい候補ブロックの生成が中断されてもよい。

再投票ラウンド（Ｓ５００）の間、投票可能な複数のノードの各々は、複数の未承認ブロックのうち、第２の既設定値以上の投票数を得た未承認ブロックが存在するか否かを判断する（Ｓ５１０）。ただし、このような判断は、再投票ラウンド（Ｓ５００）の開始後に進行するものではなく、第１の既設定値の投票数を取得した候補ブロックの存在を判断（Ｓ４２０）する時点に既に完了したものであってもよい。

第２の既設定値の投票数を取得した候補ブロックが存在すれば、ノードは、当該候補ブロックを承認する１次再投票（Ｒｅｖｉｓｉｏｎ ０）に進行する（Ｓ５２０）。

他の側面において、再投票ラウンド（Ｓ５００）の間、投票可能な複数のノードの各々は、複数の未承認ブロックのうち、最も多い投票数を得た未承認ブロックが存在するか否かを判断してもよい（Ｓ５１０）。そして、ノードは、最も多い投票数を得た候補ブロックを承認する１次再投票に進行してもよい（Ｓ５２０）。

ノードは、１次再投票によって１次再投票情報が生成され（Ｓ５３０）、生成された１次再投票情報は、ネットワーク上に伝播される（Ｓ５４０）。合わせて、再投票を得た未承認ブロックもネットワーク上に伝播される（Ｓ５４０）。

一方、Ｓ５１０ステップにおける判断結果、第２の既設定値の投票数を取得した未承認ブロックが存在しない場合、現在ラウンドにおける最初昇格ノードが生成した候補ブロックへの再投票を進行する（Ｓ５１１）。

また、ノードは、他のノードから１次再投票情報を受信する（Ｓ５５０）。ノードは、受信された１次再投票情報に対する有効性を検証できる。ここでの有効性検証とは、現在再投票ラウンドで生成された１次再投票情報であるか否かを検証することである。

ノードは、自分が生成した１次再投票情報及び／又は受信した１次再投票情報に基づいて、第１の既設定値の投票数を取得した候補ブロックの存否を判断する（Ｓ５６０）。

第１の既設定値の投票数を取得した候補ブロックが存在すれば、当該候補ブロックを承認ブロックと認め（Ｓ５７０）、承認ブロックをブロックチェーンにアップデートして承認ブロックを他のノードに伝播する（Ｓ５８０、Ｓ５９０）。

投票可能なノードの各々が判断した結果が全て一致する場合であれば、特定候補ブロックに承認投票が集中され得る。そして、当該候補ブロックは、第１の既設定値以上の承認投票数を取得するようになるので、当該候補ブロックが承認ブロックと合意される。

他の側面において、投票可能なノードのそれぞれの判断が不一致である場合がある。すなわち、ネットワーク状態によってノードの各々が受信した合意データの種類と量が異なる場合があるためである。したがって、ノードのうち一部ノード間には、第２の既設定値の投票数を取得した候補ブロック（他の側面において、最も多い投票数を取得した候補ブロック）が互いに異なり、再投票する候補ブロックの種類も異なる場合がある。この場合でも、同じ判断結果を下したノードの数が第１の既設定値以上であれば、特定候補ブロック（複数のノードが第２の既設定値以上の投票数を得たものと判断した候補ブロック、または複数のノードが最も多い投票数を得たものと判断した候補ブロック）を承認する投票数も第１の既設定値以上になるので、最終的に当該候補ブロックが承認され得る。

一部の実施形態において、Ｓ５６０ステップの判断結果、第１の既設定値以上の投票数を取得した候補ブロックが存在しないことがある。この場合、２番目の再投票である２次再投票が開始されてもよい。

ノードの各々は、複数の候補ブロックのうち、最初の昇格ノードが生成した候補ブロックを承認する２次再投票（Ｒｅｖｉｓｉｏｎ １）を進行する（Ｓ５６１）。

２次再投票によって２次再投票情報が生成され（Ｓ５６２）、２次再投票情報は、ネットワーク上に伝播される（Ｓ５６３）。

ノードの各々は、他のノードから２次再投票情報を受信する（Ｓ５６４）。ノードの各々は、２次再投票情報の有効性を検証できる。ここでの有効性検証とは、現在再投票ラウンドで生成された２次再投票情報であるか否かを検証することである。

一部の実施形態において、ネットワーク事情によって２次再投票の開始にもかかわらず、一部のノードは、他のノードから１次再投票情報を受信し得る。この場合、現在は２次再投票が進行中であるから、受信した１次再投票情報を廃棄できる。

ノードの各々は、自分が生成した２次再投票情報及び／又は受信した２次再投票情報に基づいて、第１の既設定値の投票数を取得した候補ブロックの存在を判断（５６０）する。

ノードの各々は、第１の既設定値の投票数を取得した候補ブロックの存在を判断すれば、当該候補ブロックを唯一ブロックとして承認ブロックとして合意し（Ｓ５７０）、これをブロックチェーンにアップデートして（Ｓ５８０）、承認ブロックを他のノードに伝播する（Ｓ５９０）。

一部の実施形態において、Ｓ５６０ステップにおける判断結果、第１の既設定値の投票数を取得した候補ブロックが存在しないことがある。この場合、３次再投票（Ｒｅｖｉｓｉｏｎ ２）に進行することができる（Ｓ５６１〜Ｓ５６４）。再投票の繰り返しにもかかわらず、第１の既設定値の投票数を取得した候補ブロックが存在しない場合であるとしても、時間の流れにしたがって投票可能な全てのノードまたはネットワーク事情によっていくつかのノードを除いたほとんどのノードは、合意データを共有するようになる。したがって、合意データを共有したノードは、複数の候補ブロックのうち、最初の昇格ノードが生成した候補ブロックの存在を把握するようになり、当該候補ブロックを承認するようになるので、最終的に種々の候補ブロックのうち、唯一ブロックである承認ブロックに対する合意がなされる。

一方、特定ノードがシャットダウン（Ｓｈｕｔｄｏｗｎ）されてブロックチェーンネットワークから離脱することがある。そして、特定ノードがブロックチェーンネットワークに参加して、周辺のノードからブロックを送信される同期化が始まり得る。サイナーノードは、自分が有している合意データによって投票に参加することができる。この過程で投票情報は、重複投票と取り扱われるか、過去の投票として廃棄されることができる。そして、新しく参加したノードは、現在進行されている再投票ラウンドを優先し、先に自分に到着した投票を認めることができる。また、新しく参加したノードは、次回の再投票の開始時点（再投票ラウンド内で複数の再投票がなされる場合、参加した時点での再投票が終了され、次の再投票が進行される時点）から合意に参加することができる。一部の実施形態において、新しく参加したノードが参加時点に再投票が進行されている場合であり、当該再投票を介して承認ブロックが合意された場合であれば、前記新しく参加したノードは、他のラウンドの開始時点に前記次のラウンドにおける新しい承認ブロックの認定のための合意に参加することができる。

また、ブロックチェーンシステムは、ビザンチウムノードを判別して、ビザンチウムノードを合意過程で所定の期間の間、除外させることができる。例えば、プロデューサーノードが１つのラウンド内で複数個の候補ブロックを生成した場合であれば、当該プロデューサーノードを合意過程から除外させることができる。一部の実施形態において、ビザンチウムノードと判別されたノードが生成した候補ブロックは、投票対象から除外されることができる。

また、一部の実施形態において、再投票ラウンドでは、投票に記録されたブロックハッシュと合うブロックが収集されている場合にのみ、当該ブロックに対する収集された投票情報が有効得票として取り扱われることもできる。

また、同じブロックハッシュを有する投票が最も多いグループがメジャーグループになり得る。

また、再投票ラウンドで１次再投票に対してはＲｅｖｉｓｉｏｎ ０に配布され、その後、２次、３次などの再投票を施行する度にＲｅｖｉｓｉｏｎ ＋１が発生し得る。実施形態に係るブロックチェーンシステムは、Ｒｅｖｉｓｉｏｎ Ｎの再投票がＲｅｖｉｓｉｏｎ Ｎ−１の投票の２／３を収集した後に始めることができるように構成されてもよい。そして、時間が過ぎてもＲｅｖｉｓｉｏｎ Ｎ−１の投票に２／３だけ集めることができなければ、２／３投票収集がＮ−１以前に終了されたことを意味できる。

また、Ｒｅｖｉｓｉｏｎ Ｎの投票を２／３収集した時点に再投票が必要であると判断された場合、ノード自分が選択したメジャーグループのブロックをリーダーブロックとしてＲｅｖｉｓｉｏｎ Ｎ＋１として投票してもよい。

また、再投票過程が始まると、投票が終了されるまでブロック生成が中断されてもよい。１／３＋１以上の投票が確認された状態であるから、ビザンチンノードの他にも、正直なノードがブロックを保有している状態であるといえる。ただし、不正行為の発覚などのため、選択する候補ブロックがない場合、まだブロックを生成していない参加ノードが追加ブロックを生成してもよい。

また、ビザンチンノードとしてのプロデューサーノードによるブロックチェーンの分岐誘導現象を説明する。ビザンチンノードが各プロデューサーノードに互いに異なる正常ブロックを配布する状況が発生すれば、各参加ノードは、互いに異なるブロックをメジャーブロックとして選択し、ネットワークがストップザワールド状態になる虞がある。各ノードは、自分が受けたブロックと投票情報を周辺に再度伝播するので、他のノードも分岐誘導が発生したという事実を認識できる。１つのラウンド内で複数の候補ブロックを生成したことが発覚されれば、当該ブロックのプロデューサーノードは、ブロックが候補から除外される処罰を受けることになる。残ったブロックで投票が進行されるので、分岐誘導を試みたプロデューサーノードは、自然に淘汰され得る。

また、ビザンチンノードとしてのサイナーノードの重複投票現象を説明する。ビザンチンノードが重複投票を施行して、ブロックチェーンネットワークの総投票数が１００％を越えた場合である。この場合、２／３投票数を取得した候補ブロックが複数生じる現象が発生する虞がある。まず、全て正常ブロックに対する投票であるから、いずれが承認ブロックと選択されても問題がない。そして、プロデューサー地位を有さないビザンチンノードにより生成されたブロックの場合、既にブロックの有効性検証ステップで捨てられる。

また、図９に示すように、３Ｎ＋１条件（サイナーノード７（ＡＢＣＤＥＦＧ）のうち、ビザンチンノードが２）で、ＡＢがブロックを作り、ＣＤがビザンチンサイナーノードとすれば、ＣＤは、ＡＢブロックを共に賛成するものの、ＡＥにはＡブロックに対する賛成を、ＢＧにはＢブロックに対する賛成を送る。ＡＥは、ＡＣＤＥ（４票）を得たことを認識され、ＢＧは、ＢＣＤＧ（４票）を得たことを認識されるが、Ｆなしには、５票の条件が満たされない。Ｆがどれか１つのグループに属するとすれば、そのグループが承認グループとして選択されることができる。

以上で説明された本発明に係る実施形態は、様々なコンピュータ構成要素を介して実行され得るプログラム命令語の形態で実現されて、コンピュータ読み取り可能な記録媒体に記録されることができる。すなわち、複数のノードの分散ネットワークで構成されたブロックチェーンシステムの少なくとも１つのプロセッサにより実行される該複数のノード間の合意をなすための方法は、プログラム命令語の形態で実現されて、コンピュータ読み取り可能な記録媒体に記録されることができる。また、複数のノードの分散ネットワークで構成されたブロックチェーンシステムの少なくとも１つのノードの少なくとも１つのプロセッサにより実行されるが複数のノード間の合意をなすための方法は、プログラム命令語の形態で実現されて、コンピュータ読み取り可能な記録媒体に記録されることができる。該コンピュータ読み取り可能な記録媒体は、プログラム命令語、データファイル、データ構造などを単独でまたは組み合わせて含むことができる。該コンピュータ読み取り可能な記録媒体に記録されるプログラム命令語は、本発明のために特別に設計され、構成されたものであるか、コンピュータソフトウェア分野の当業者に公知されて使用可能なものである。コンピュータ読み取り可能な記録媒体の例には、ハードディスク、フロッピー（登録商標）ディスク、及び磁気テープのような磁気媒体、ＣＤ−ＲＯＭ及びＤＶＤのような光気録媒体、フロプティカルディスク（ｆｌｏｐｔｉｃａｌ ｄｉｓｋ）のような磁気−光媒体（ｍａｇｎｅｔｏ−ｏｐｔｉｃａｌ ｍｅｄｉｕｍ）、及びＲＯＭ、ＲＡＭ、フラッシュメモリ１４０などのような、プログラム命令語を格納し、実行するように特別に構成されたハードウェア装置が含まれる。プログラム命令語の例には、コンパイラによって作られるような機械語コードだけでなく、インタプリタなどを使用してコンピュータにより実行され得る高級言語コードも含まれる。ハードウェア装置は、本発明に係る処理を行うために、１つ以上のソフトウェアモジュールに変更されることができ、その反対も同様である。

本発明において説明する特定実行等は、一実施形態であって、いかなる方法でも本発明の範囲を限定するものではない。明細書の簡潔さのために、従来の電子的な構成、制御システム、ソフトウェア、該システムの他の機能的な側面等の記載は省略されることができる。また、図面に図示された構成要素間の線等の接続または接続部材などは、機能的な接続及び／又は物理的または回路的接続を例示的に示したものであって、実際装置では、代替可能であるか、追加の様々な機能的な接続、物理的な接続、または回路接続として表されることができる。また、「必須な」、「重要に」などのように、具体的な言及がなければ、本発明の適用のために必要な構成要素でない場合がある。

また、説明した本発明の詳細な説明では、本発明の好ましい実施形態を参照して説明したが、当該技術分野の熟練された当業者または当該技術分野における通常の知識を有する者であれば、後述する特許請求の範囲に記載された本発明の思想及び技術領域から逸脱しない範囲内で本発明を様々に修正及び変更させ得ることが理解できるであろう。したがって、本発明の技術的範囲は、明細書の詳細な説明に記載された内容に限定されるものではなく、特許請求の範囲により決められなければならない。

Claims (19)

1. ラウンド毎に予め決められた時点にブロック生成地位を有するプロデューサーノードに昇格され得る複数のノードのうち、いずれか１つの第１のノードが第Ｎのラウンドで候補ブロックを受信すること、
   受信された候補ブロックが有効候補ブロックであるか判断すること、
   前記有効候補ブロックが未承認ブロックであるか判断すること、及び
   前記未承認ブロックが最初の受信候補ブロックであるか判断し、前記未承認ブロックに対する承認投票可否を決定すること、
   を含み、
   前記最初の受信候補ブロックは、前記第１のノードが前記第Ｎのラウンド内で最初に受信した候補ブロックである、複数のノードの分散ネットワークで構成されたブロックチェーン上の複数のノード間の合意をなすための方法。
2. 前記未承認ブロックを他のノードに送信すること、及び
   前記最初の受信候補ブロックを承認する投票情報を他のノードに送信すること、
   をさらに含む、請求項１に記載の複数のノードの分散ネットワークで構成されたブロックチェーン上の複数のノード間の合意をなすための方法。
3. 前記第Ｎのラウンドで生成された未承認ブロックのうち、投票数が既設定値以上である未承認ブロックを承認ブロックと認めることをさらに含む、請求項２に記載の複数のノードの分散ネットワークで構成されたブロックチェーン上の複数のノード間の合意をなすための方法。
4. 前記第Ｎのラウンドでプロデューサーノードに昇格された全てのノードは、第Ｎ＋１のラウンドでプロデューサーノード地位が喪失され、前記承認ブロックと認められた候補ブロックを生成したノードの次の順番ノードが第Ｎ＋１のラウンドで１番目のプロデューサーノードに昇格することをさらに含む、請求項３に記載の複数のノードの分散ネットワークで構成されたブロックチェーン上の複数のノード間の合意をなすための方法。
5. 前記第Ｎのラウンドで複数の未承認ブロックのうち、投票数が既設定値以上である未承認ブロックが存在しない場合、再投票ラウンドが開始されること、及び
   前記再投票ラウンド期間の間、予め設定された優先順位によって前記複数の未承認ブロックに対する再投票を進行させること、
   をさらに含み、
   前記再投票ラウンドの間、新しい候補ブロックの生成を中断する、請求項２に記載の複数のノードの分散ネットワークで構成されたブロックチェーン上の複数のノード間の合意をなすための方法。
6. 前記再投票を進行させることは、
   投票可能な複数のノードが前記複数の未承認ブロックのうち、既設定値以上の投票数を得た未承認ブロックに対して承認再投票することを含む、請求項５に記載の複数のノードの分散ネットワークで構成されたブロックチェーン上の複数のノード間の合意をなすための方法。
7. 前記再投票を進行させるステップは、
   前記複数の未承認ブロックのうち、既設定値以上の投票数を得た複数の未承認ブロックが存在する場合、前記複数の未承認ブロックの各々を生成したノードのうち、最初の昇格ノードが生成した未承認ブロックに対して承認再投票することをさらに含み、
   前記最初の昇格ノードは、前記第Ｎのラウンドでプロデューサーノードへの昇格順序が最も早いノードである、請求項６に記載の複数のノードの分散ネットワークで構成されたブロックチェーン上の複数のノード間の合意をなすための方法。
8. 前記有効候補ブロックであるか判断することは、
   前記受信された候補ブロックを生成したノードの昇格可否を判断することと、及び
   前記受信された候補ブロックが昇格されたノードが生成したブロックである場合、前記受信された候補ブロックを有効候補ブロックと認めること、
   を含む、請求項１に記載の複数のノードの分散ネットワークで構成されたブロックチェーン上の複数のノード間の合意をなすための方法。
9. 前記有効候補ブロックが未承認ブロックであるか判断することは、
   前記有効候補ブロックに対する既設定値以上の投票結果を含む次のブロックの存否を判断すること、及び
   前記次のブロックが存在する場合、前記有効候補ブロックを承認ブロックと認めて、前記分散ネットワークに前記承認ブロックに対する同期化を要請すること、
   を含む、請求項１に記載の複数のノードの分散ネットワークで構成されたブロックチェーン上の複数のノード間の合意をなすための方法。
10. 任意のラウンドが進行される間、プロデューサーノードへの昇格の地位を有する複数のノードは、順序どおりに昇格される、請求項１に記載の複数のノードの分散ネットワークで構成されたブロックチェーン上の複数のノード間の合意をなすための方法。
11. 前記既設定値は、前記複数のノードの個数の２／３に該当する、請求項３または４に記載の複数のノードの分散ネットワークで構成されたブロックチェーン上の複数のノード間の合意をなすための方法。
12. 前記ラウンド毎に前記複数のノードの各々は、１回の投票権を有する、請求項２に記載の複数のノードの分散ネットワークで構成されたブロックチェーン上の複数のノード間の合意をなすための方法。
13. 前記複数のノードのうち、いずれか１つのノードが投票情報を受信すること、
    受信された投票情報の有効性を検証すること、及び
    有効性が検証された投票情報を他のノードに伝播すること、
    をさらに含む、請求項２に記載の複数のノードの分散ネットワークで構成されたブロックチェーン上の複数のノード間の合意をなすための方法。
14. 特定ラウンドが進行される間、前記複数のノードのうち、いずれか１つのノードは、投票情報を受信すれば、既設定値以上の投票数を取得した候補ブロックの存在可否を判断し、既設定値以上の投票数を取得した候補ブロックが存在すれば、既設定値以上の投票数を得た未承認ブロックを承認ブロックと合意する、請求項２に記載の複数のノードの分散ネットワークで構成されたブロックチェーン上の複数のノード間の合意をなすための方法。
15. ラウンド毎に予め決められた時点にブロック生成地位を有するプロデューサーノードに昇格され得る複数のノードのうち、いずれか１つの第２のノードが第Ｎのラウンドで昇格されること、
    前記第Ｎのラウンド内で前記第２のノードが昇格前の候補ブロックを受信したかを判断すること、
    前記昇格前の候補ブロックの未受信時、新しいブロックが連結される前記ブロックチェーン上の最後のブロック内の投票情報を含む候補ブロックを生成すること、
    生成された候補ブロックを承認ブロックと認める投票をすること、及び
    前記候補ブロックと投票情報を他のノードに送信すること、
    を含む、複数のノードの分散ネットワークで構成されたブロックチェーン上の複数のノード間の合意をなすための方法。
16. 前記第２のノードが前記昇格前の候補ブロックを受信した場合、前記第２のノードは、前記新しいブロックを生成しない、請求項１５に記載の複数のノードの分散ネットワークで構成されたブロックチェーン上の複数のノード間の合意をなすための方法。
17. 前記新しいブロックは、前記第Ｎのラウンドで前記新しいブロックを承認ブロックと承認する投票に対する投票数に基づいた、承認ブロックと合意可能なブロックである、請求項１５に記載の複数のノードの分散ネットワークで構成されたブロックチェーン上の複数のノード間の合意をなすための方法。
18. 前記第Ｎのラウンドで昇格された前記第２のノードは、他のノードが生成した候補ブロックを受信すること、
    受信された前記候補ブロックが有効候補ブロックであるか判断すること、
    前記有効候補ブロックが未承認ブロックであるか判断すること、及び
    前記未承認ブロックを他のノードに送信すること、
    をさらに含む、請求項１５に記載の複数のノードの分散ネットワークで構成されたブロックチェーン上の複数のノード間の合意をなすための方法。
19. 任意のラウンドが進行される間、プロデューサーノードへの昇格の地位を有する複数のノードは順序どおりに昇格される、請求項１５に記載の複数のノードの分散ネットワークで構成されたブロックチェーン上の複数のノード間の合意をなすための方法。