特許 7554871 ブロックチェーンに付加的なチェーンを追加する方法および装置、そのためのシャード生成方法および装置

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

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2024-09-11

(45)【発行日】2024-09-20

(54)【発明の名称】ブロックチェーンに付加的なチェーンを追加する方法および装置、そのためのシャード生成方法および装置

(51)【国際特許分類】

   H04L 9/32 20060101AFI20240912BHJP

【ＦＩ】

H04L9/32 200Z

【請求項の数】 15

(21)【出願番号】P 2023071534

(22)【出願日】2023-04-25

(65)【公開番号】P2024048336

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

【審査請求日】2023-04-25

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

(32)【優先日】2022-09-27

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

(31)【優先権主張番号】10-2023-0017703

(32)【優先日】2023-02-10

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

(73)【特許権者】

【識別番号】596099882

【氏名又は名称】エレクトロニクス アンド テレコミュニケーションズ リサーチ インスチチュート

【氏名又は名称原語表記】ＥＬＥＣＴＲＯＮＩＣＳ ＡＮＤ ＴＥＬＥＣＯＭＭＵＮＩＣＡＴＩＯＮＳ ＲＥＳＥＡＲＣＨ ＩＮＳＴＩＴＵＴＥ

(74)【代理人】

【識別番号】110002952

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

(72)【発明者】

【氏名】オー ジン－テイ

(72)【発明者】

【氏名】キム ユン－チャン

(72)【発明者】

【氏名】リ チャン－ヒュン

(72)【発明者】

【氏名】イム ジョン－チュル

【審査官】上島 拓也

(56)【参考文献】

【文献】米国特許出願公開第２０１９／０２６０５７４（ＵＳ，Ａ１）

【文献】特表２０２０－５２２１５０（ＪＰ，Ａ）

【文献】米国特許出願公開第２０２１／００９７５３７（ＵＳ，Ａ１）

【文献】松永 赳尭，Ｐｒｏｏｆ－ｏｆ－Ｓｔａｋｅ型ブロック・チェーンの参加ノードへのインセンティブづけに関する一検討，電子情報通信学会技術研究報告，日本，一般社団法人電子情報通信学会，2020年11月19日，Ｖｏｌ．１２０ Ｎｏ．２５７ ，ｐ．６２－６７

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｈ０４Ｌ ９／３２

(57)【特許請求の範囲】

【請求項1】

ブロックチェーンに付加的なチェーンを追加する方法において、
前記ブロックチェーンのノードが前記付加的なチェーンに相応する資産（ａｓｓｅｔ）を預ける（ｄｅｐｏｓｉｔ）ステップと、
前記資産に相応する持分値（ｓｈａｒｅ ｖａｌｕｅ）に基づいて、前記ノードを、前記付加的なチェーンに追加ブロックを連結するための合意体ノードの１つとして選択するステップと、
前記ノードが前記追加ブロックを連結するための分散合意を行うステップと、
を含み、
前記付加的なチェーンに参加するノードは、トランザクション処理のためのメジャーシェアホルダー（ｍａｊｏｒ ｓｈａｒｅｈｏｌｄｅｒ）ノードと、前記メジャーシェアホルダーノードではないマイナーシェアホルダー（ｍｉｎｏｒ ｓｈａｒｅｈｏｌｄｅｒ）ノードを含み、前記マイナーシェアホルダーノードにはトランザクションが伝達されず、
前記付加的なチェーンは、前記メジャーシェアホルダーノードに相応する第１合計持分値（ｆｉｒｓｔ ｔｏｔａｌ ｓｈａｒｅ ｖａｌｕｅ）と、前記マイナーシェアホルダーノードに相応する第２合計持分値（ｓｅｃｏｎｄ ｔｏｔａｌ ｓｈａｒｅ ｖａｌｕｅ）と、に基づいて、新規ノードの参加可能の有無を決定する、ブロックチェーンに付加的なチェーンを追加する方法。

【請求項2】

前記合意体ノードは、少なくとも１つのメジャーシェアホルダーノードと、少なくとも１つのマイナーシェアホルダーノードと、を含む、請求項１に記載のブロックチェーンに付加的なチェーンを追加する方法。

【請求項3】

前記合意体ノードは、初期に前記メジャーシェアホルダーノードだけを含む、請求項１に記載のブロックチェーンに付加的なチェーンを追加する方法。

【請求項4】

前記新規ノードの参加可能の有無は、前記第１合計持分値と前記第２合計持分値、および前記新規ノードの持分値の合計を比較した結果に基づいて決定される、請求項１に記載のブロックチェーンに付加的なチェーンを追加する方法。

【請求項5】

前記第１合計持分値は、前記新規ノードが前記付加的なチェーンに参加可能にするための、拡張プロセスによって増加する、請求項４に記載のブロックチェーンに付加的なチェーンを追加する方法。

【請求項6】

前記拡張プロセスは、
前記メジャーシェアホルダーノードのいずれか１つ以上に相応する持分値を増加させる第１プロセス、
新しいメジャーシェアホルダーノードを追加する第２プロセス、および
少なくとも１つの前記マイナーシェアホルダーノードをメジャーシェアホルダーノードに変更する第３プロセス、
のいずれか１つである、請求項５に記載のブロックチェーンに付加的なチェーンを追加する方法。

【請求項7】

前記ブロックチェーンの１つのブロックに前記付加的なチェーンに関するデータを記録する、請求項１に記載のブロックチェーンに付加的なチェーンを追加する方法。

【請求項8】

前記付加的なチェーンに関するデータは、前記付加的なチェーンに参加するノードの参加ノード情報と、前記付加的なチェーンに参加するノードの持分値と、を含む、請求項７に記載のブロックチェーンに付加的なチェーンを追加する方法。

【請求項9】

前記付加的なチェーンに関するデータは、前記付加的なチェーンの開始情報を含み、前記付加的なチェーンの開始ブロックは、前記付加的なチェーンに関するデータを記録した前記ブロックチェーンの少なくとも１つのブロックに関する情報を記録する、請求項８に記載のブロックチェーンに付加的なチェーンを追加する方法。

【請求項10】

前記マイナーシェアホルダーノードの少なくとも１つは、前記付加的なチェーン以外のチェーンにマイナーシェアホルダーノードとして参加する、請求項１に記載のブロックチェーンに付加的なチェーンを追加する方法。

【請求項11】

前記メジャーシェアホルダーノードは、前記付加的なチェーン以外のチェーンにメジャーシェアホルダーノードとして参加できない、請求項１に記載のブロックチェーンに付加的なチェーンを追加する方法。

【請求項12】

１つ以上のプロセッサと、
前記１つ以上のプロセッサによって実行される少なくとも１つのプログラムを格納する実行メモリと、
を含み、
前記少なくとも１つのプログラムは、
ブロックチェーンに追加される付加的なチェーンに相応する資産（ａｓｓｅｔ）を預け（ｄｅｐｏｓｉｔ）、
前記資産に相応する持分値（ｓｈａｒｅ ｖａｌｕｅ）に基づいて、前記付加的なチェーンに追加ブロックを連結するための合意体ノードの１つとして選択され、
前記追加ブロックを連結するための分散合意を行い、
前記付加的なチェーンに参加するノードは、トランザクション処理のためのメジャーシェアホルダー（ｍａｊｏｒ ｓｈａｒｅｈｏｌｄｅｒ）ノードと、前記メジャーシェアホルダーノードではないマイナーシェアホルダー（ｍｉｎｏｒ ｓｈａｒｅｈｏｌｄｅｒ）ノードを含み、前記マイナーシェアホルダーノードにはトランザクションが伝達されず、
前記付加的なチェーンは、前記メジャーシェアホルダーノードに相応する第１合計持分値（ｆｉｒｓｔ ｔｏｔａｌ ｓｈａｒｅ ｖａｌｕｅ）と、前記マイナーシェアホルダーノードに相応する第２合計持分値（ｓｅｃｏｎｄ ｔｏｔａｌ ｓｈａｒｅ ｖａｌｕｅ）と、に基づいて、新規ノードの参加可能の有無を決定する、ブロックチェーンに付加的なチェーンを追加する装置。

【請求項13】

前記マイナーシェアホルダーノードの少なくとも１つは、前記付加的なチェーン以外のチェーンにマイナーシェアホルダーノードとして参加する、請求項１２に記載のブロックチェーンに付加的なチェーンを追加する装置。

【請求項14】

前記メジャーシェアホルダーノードは、前記付加的なチェーン以外のチェーンにメジャーシェアホルダーノードとして参加できない、請求項１２に記載のブロックチェーンに付加的なチェーンを追加する装置。

【請求項15】

ブロックチェーンのシャード生成方法において、
付加的なチェーンにメジャーシェアホルダー（ｍａｊｏｒ ｓｈａｒｅｈｏｌｄｅｒ）ノードとして参加するステップと、
前記付加的なチェーンにマイナーシェアホルダー（ｍｉｎｏｒ ｓｈａｒｅｈｏｌｄｅｒ）ノードとして参加するステップと、
前記メジャーシェアホルダーノードおよび前記マイナーシェアホルダーノードのいずれか１つ以上を含む合意体を構成するステップと、
を含み、
前記メジャーシェアホルダーノードは、トランザクション処理のためのものであり、前記マイナーシェアホルダーノードにはトランザクションが伝達されず、
前記付加的なチェーンは、前記メジャーシェアホルダーノードに相応する第１合計持分値（ｆｉｒｓｔ ｔｏｔａｌ ｓｈａｒｅ ｖａｌｕｅ）と、前記マイナーシェアホルダーノードに相応する第２合計持分値（ｓｅｃｏｎｄ ｔｏｔａｌ ｓｈａｒｅ ｖａｌｕｅ）と、に基づいて、新規ノードの参加可能の有無を決定する、ブロックチェーンのシャード生成方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、ブロックチェーンに付加的なチェーンを追加する技術に関し、とりわけ、運用中のブロックチェーンでシャードを生成する技術に関する。

【背景技術】

【0002】

ブロックチェーンは、互いに信頼できない当事者間で第３の信頼機関（ｔｒｕｓｔｅｄ ｔｈｉｒｄ ｐａｒｔｙ）の介入なしに取引（トランザクション）が処理され、その結果を元帳に記録できる技術である。脱中央化されたブロックチェーンは、参加ノードのうち任意のノードが新しいブロックを生成できるので、取引内容はすべてのノードに伝達されて処理できなければならない。しかし、複数のノードが取引内容を重複処理することによって、多くのノードが参加したブロックチェーンのオンチェーン（ｏｎ－ｃｈａｉｎ）処理性能は１ノードの取引処理性能以下になることが一般的である。

【0003】

ブロックチェーンの合意性能を高める方法のほか、オフチェーンで処理された取引結果だけをオンチェーンに記録する方法や、マルチプルチェーン（ｍｕｌｔｉｐｌｅ ｃｈａｉｎｓ）を適用してブロックチェーンの処理性能を向上させる方法が提案されている。特に、マルチプルチェーンを用いる場合、チェーンごとに処理する取引が分散して並列処理できるので、性能向上を得ることができる。

【0004】

既存のイーサリアムなどで提案されたマルチプルチェーンにはエポック（ｅｐｏｃｈ）単位で各チェーンにノードが割当てられる。すなわち、エポック単位で各チェーンに割当てられるノードが再構成され、１つのブロックチェーンシステムが収容可能なマルチプルチェーンの最大個数が定められている。この場合、新しいチェーンの追加はエポック境界で行われるしかない。また、ブロックチェーンシステムに予め定められた最大個数を超えて新しいチェーンを追加することは不可能である。

【0005】

エポック単位でノードを再構成する理由は、特定チェーンに含まれるノードが処理する取引以外の取引を受信しても当該チェーンで処理が不可能なため、チェーンごとに処理可能な取引のみ伝達されるようにするためである。すなわち、当該チェーンに所属するノードにのみ処理される取引を伝達し、チェーンごとに並列処理を行って処理性能を高めることができる。したがって、特定エポックで１つのノードが同時に２つ以上のチェーンの合意に参加することは難しい。

【0006】

このような既存の技術は、エポック境界区間で取引処理が遅延したり不可能になり、このため、夜中など取引のない時間にノードの再構成が行われなければならない。また、１つのノードはマルチプルチェーンの１つのみに割当てられるので、ブロックチェーンに参加するノードの個数が多くない場合には、ビザンチン障害（Ｂｙｚａｎｔｉｎｅ Ｆａｕｌｔ）確率が増加する問題がある。

【0007】

２０２０年１０月２０日付で公開された論文「Ａｌｇｏｒｉｔｈｍ ｂａｓｅｄ ｏｎ Ｂｙｚａｎｔｉｎｅ ａｇｒｅｅｍｅｎｔ ａｍｏｎｇ ｄｅｃｅｎｔｒａｌｉｚｅｄ ａｇｅｎｔｓ（ＢＡＤＡ）」、米国特許出願公開第２０１９／０３２７０８４号明細書、米国特許出願公開第２０１９／０３７９５３８号明細書および米国特許出願公開第２０２０／０４０３７７６号明細書には、ナンス（ｎｏｎｃｅ）チェーンベースの合意体選定方法およびこれを用いたブロックチェーン生成方法が詳しく開示されている。しかし、前記論文および明細書に開示された技術は、１つのノードが成功確率ｐおよび失敗確率１－ｐである１回のコイントスをし、その結果に応じて合意ノードを選定する方式で任意の合意体を構成することができるが、すべてのノードにトランザクションを伝達しなければならないので、トランザクション伝達コストがブロックチェーン全体の性能を低下させざるを得なかった。

【0008】

したがって、処理するトランザクションを一部のノードだけが受信しながらも、ブロックごとに参加ノードのうち任意のノードが合意体として選抜され、新規ブロックを生成してブロックチェーンに連結することができ、ブロックチェーン運用中にいつでも付加的なチェーンを追加できる新たな技術の必要性が切実に求められる。

【発明の概要】

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

【0009】

本発明の目的は、ブロックチェーン運用中にいつでもチェーン（シャード）を追加することができ、ノードが２つ以上のチェーンに同時に合意体として参加できるようにすることである。

【0010】

また、本発明の目的は、エポックごとにマルチプルチェーンにノードを再び割当てる必要なく、動的に一部のノードが新しいチェーンに参加できるようにすることである。

【0011】

また、本発明の目的は、ブロックチェーンに参加するノードに特定チェーンに対する合意投票権限を付与し、当該チェーンの合意体に参加して当該チェーンを運用できるようにすることである。

【0012】

さらに、本発明の目的は、運用中のブロックチェーンでノードをチェーンごとに再び割当てるノードの再構成なしにリアルタイムに新規チェーンを追加することができ、追加されたチェーンが並列処理により全体ブロックチェーンの処理性能を向上させるようにすることである。

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

【0013】

上記の目的を達成するための、本発明によるブロックチェーンに付加的なチェーンを追加する方法は、前記ブロックチェーンのノードが前記付加的なチェーンに相応する資産（ａｓｓｅｔ）を預ける（ｄｅｐｏｓｉｔ）ステップと、前記資産に相応する持分値（ｓｈａｒｅ ｖａｌｕｅ）に基づいて、前記ノードを、前記付加的なチェーンに追加ブロックを連結するための合意体ノードの１つとして選択するステップと、前記ノードが前記追加ブロックを連結するための分散合意を行うステップと、を含む。

【0014】

ここで、前記付加的なチェーンに参加するノードは、トランザクション処理のためのメジャーシェアホルダー（ｍａｊｏｒ ｓｈａｒｅｈｏｌｄｅｒ）ノードを含むことができる。

【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】本発明の一実施例によるメジャーシェアホルダーノードを含むノードの持分保有状態およびトランザクション処理を示すテーブルである。

【図2】本発明の一実施例による分散合意方法を示す動作フローチャートである。

【図3】本発明の一実施例によるブロックチェーン生成方法により新規ブロックが合意されてブロックチェーンに追加される例を示すブロック図である。

【図4】本発明の一実施例によるブロックチェーン生成方法を示すテーブルである。

【図5】本発明の一実施例によるブロックチェーン生成方法を示す動作フローチャートである。

【図6】本発明の一実施例によるブロックチェーンを構成するノードがそれぞれ持分値に相応する回数だけ成功確率に相応する演算を行う過程を示す動作フローチャートである。

【図7】本発明の一実施例によるブロックチェーンを構成するノードが互いに異なる類型の持分値を有する場合の例を示すテーブルである。

【図8】本発明の一実施例によるコンピュータシステムの構成を示すブロック図である。

【図9】ブロックチェーン参加ノードの資産保有状況の一例を示す表である。

【図10】図９に示された例において１０番目チェーンに参加したノードの参加ノード情報の一例を示す表である。

【図11】図９に示された例において１５番目チェーンに参加したノードの参加ノード情報の一例を示す表である。

【図12】ブロックチェーンに付加的なチェーンが適用された例を示すブロック図である。

【図13】１０番目チェーンと１５番目チェーンがマイナーシェアホルダーノードを共有する例を示す図である。

【図14】本発明の一実施例によるブロックチェーンに新しいチェーンを追加する方法を示す動作フローチャートである。

【図15】本発明の一実施例によるブロックチェーンのシャード生成方法を示す動作フローチャートである。

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

【0040】

本発明の利点および特徴、そしてそれらを達成する方法は、添付した図面と共に詳細に後述する実施例を参照すれば明確になる。しかし、本発明は以下に開示される実施例に限定されるものではなく、互いに異なる多様な形態で実現され、単に本実施例は本発明の開示が完全となるようにし、本発明の属する技術分野における通常の知識を有する者に発明の範疇を完全に知らせるために提供されるものであり、本発明は請求項の範疇によってのみ定義される。明細書全体にわたって同一の参照符号は同一の構成要素を指す。

【0041】

「第１」または「第２」などが多様な構成要素を述べるために使われるが、このような構成要素は前記のような用語によって制限されない。前記のような用語は単に１つの構成要素を他の構成要素と区別するために使われる。したがって、以下に言及される第１構成要素は、本発明の技術的思想内で第２構成要素であってもよい。

【0042】

本明細書で使われる用語は実施例を説明するためのものであり、本発明を制限しようとするものではない。本明細書において、単数形は文言で特に言及しない限り、複数形も含む。明細書で使われる「含む（ｃｏｍｐｒｉｓｅｓ）」または「含む（ｃｏｍｐｒｉｓｉｎｇ）」は、言及された構成要素または段階が１つ以上の他の構成要素または段階の存在または追加を排除しないという意味を含む。

【0043】

他に定義がなければ、本明細書で使われるすべての用語は、本発明の属する技術分野における通常の知識を有する者に共通して理解できる意味で解釈される。また、一般的に使われる辞書に定義されている用語は、明らかに特別に定義されていない限り、理想的または過度に解釈されない。

【0044】

以下、添付した図面を参照して、本発明の実施例を詳細に説明し、図面を参照して説明するとき、同一または対応する構成要素は同一の図面符号を付し、これに関する重複した説明は省略する。

【0045】

一般的に、非競争合意を用いるブロックチェーンで参加ノードの数が増加する場合、合意メッセージ複雑度が上昇して性能が減少する。この場合、ノードの一部を合意体（ｃｏｎｓｅｎｓｕｓ）として選抜して、直接合意に参加するノードの数を減らして性能を増加させることができる。しかし、固定された一部のノードだけを合意体として用いると、再び中央化の問題が発生するので、ブロックごとに合意体を任意に再構成する技術が必要である。

【0046】

また、任意に選抜された合意体ノードは、メッセージ複雑度Ｏ（Ｎ）である合意アルゴリズムを用いて性能を増加させることができる。ここで、すべてのノードは合意体ノードとして選抜される可能性があるので、処理されるトランザクションをすべての参加ノードに伝達するためのトラフィックコスト（ｃｏｓｔ）はノード数に比例して増加し、これは性能低下の原因になりうる。したがって、ネットワーク全体のデータ量を減少させる方法が必要になる。例えば、Ｇｏｓｓｉｐプロトコルなどを用いた最適化によりデータ量を減らす研究があったが、任意に合意体を選抜する場合には、どのノードが合意体として選抜されるか予測できないので、各ノードに伝達されるトランザクションを減らすことができない。

【0047】

前述した論文「Ａｌｇｏｒｉｔｈｍ ｂａｓｅｄ ｏｎ Ｂｙｚａｎｔｉｎｅ ａｇｒｅｅｍｅｎｔ ａｍｏｎｇ ｄｅｃｅｎｔｒａｌｉｚｅｄ ａｇｅｎｔｓ（ＢＡＤＡ）」および米国特許出願公開第２０１９／０３７９５３８号明細書などを通して、任意に選抜された合意体によってビザンチン障害耐性合意を行う方法が紹介された。

【0048】

この合意アルゴリズムによれば、下記式１および式２を同時に満足するｐ（ｐは成功確率）とｆ（ｆはビザンチンの大きさで１以上の定数）を見つけることができ、３ｆ＋１を合意体の大きさに決定することができる。ここで、ｎは全体参加ノードの数、ｂはビザンチンノードの数で、全体ノードに含まれるビザンチンノードの比率がｂ_ｐの場合、ｂはｎ×ｂ_ｐになる。

【0049】

下記式１は、ｂ個のビザンチンノードがそれぞれ成功確率（ｓｕｃｃｅｓｓ ｐｒｏｂａｂｉｌｉｔｙ）ｐ、失敗確率１－ｐであるコイントス（ｃｏｉｎ ｔｏｓｓ）をする場合、成功したビザンチンノードがｆ個を超える確率がＰ_{ｍａｘ＿ｂｚｔ}以下になることを意味する。また、下記式２は、全体ｎ個のノードがそれぞれ成功確率ｐ、失敗確率１－ｐであるコイントスをする場合、成功したノードが３ｆ個以下の確率がＰ_{ｍｉｎ＿ｎｏｄｅ}以下になることを意味する。

【0050】

【数1】

【0051】

【数2】

【0052】

前述した論文などで紹介された合意アルゴリズムは、全体ノード数がｎであり、前記２つの式の条件を満足する成功確率ｐであるコイントスを行った結果、成功したノードの数が３ｆ＋１個以上の場合に、３ｆ＋１個のノードを任意に選択して合意体を構成する。この場合、コイントスに成功したノードを予め知ることができず、したがって、すべてのノードが合意体として選択される可能性があるため、すべてのノードに処理するトランザクションが伝達されなければならない。これは単に前述した論文などで紹介された合意アルゴリズムだけでなく、任意にノードを選抜して合意体を構成し、構成された合意体に相当するノードのみが合意に参加する方式のすべての合意アルゴリズムで共通して発生する問題である。

【0053】

本発明の一実施例によれば、ブロックチェーン分散合意でノードの持分比率に基づいてビザンチン障害耐性分散合意が行われる。特に、本発明の一実施例によれば、選択された一部のノードのみトランザクションを処理し、ブロックごとにすべてのノードのうち任意に（ｒａｎｄｏｍｌｙ）選択された合意体が新規ブロックを生成してブロックチェーンに連結することができる。

【0054】

本発明の一実施例によれば、前記２つの式において、ｎを全体ノードの数ではない全体ノードに発行された持分（ｓｈａｒｅｓ）の合計として用い、ｂはビザンチンノードの数（最大ビザンチンノード数）ではなくビザンチンノードが保有した持分（全体持分に含まれる最大ビザンチン持分）として用いることができる。

【0055】

ノードではない持分を前記式に適用することにより、一部のノード（後述するメジャーシェアホルダーノード）だけがトランザクション（ｔｒａｎｓａｃｔｉｏｎｓ）を処理しながらも、全体ノードが合意に参加できるようになる。これによってランダム合意体を構成して分散合意を進行させ、合意されたブロックをブロックチェーンに連結することができる。

【0056】

ノード数に基づいて、前記式１および式２を用いて合意体を構成すれば、合意体を構成する可能性があるすべてのノードがトランザクションを受信しなければならないので、トランザクション処理のための負荷による性能低下が発生しうる。

【0057】

本発明の一実施例によれば、トランザクションを処理するノードが選定され、このノードを用いて合意ノードが選定され、合意ノードを用いて分散合意が行われて新規ブロックをブロックチェーンに連結することができる。

【0058】

まず、トランザクション処理のためのノードは、次のように選定できる。

【0059】

ブロックチェーンを構成する各ノードが所有した持分値（ｓｈａｒｅ ｖａｌｕｅ、ｓｈａｒｅ ｓｉｚｅ）を降順に整列し、大きい持分値を有するノードからメジャーシェアホルダーノード（ｍａｊｏｒ ｓｈａｒｅｈｏｌｄｅｒ ｎｏｄｅｓ）として選定する。ここで、メジャーシェアホルダーノードは、それぞれ所有した持分の合計が、予め設定された値以上のノードであってもよい。ここで、メジャーシェアホルダーノードは、選定されたメジャーシェアホルダーノードの累積持分が全体持分の特定持分比率以上になるまで選定されてもよく、予め定義された個数だけ持分値が大きいノードから選定されてもよい。

【0060】

このように選定されたメジャーシェアホルダーノードのみ選択的にトランザクションを処理するために、処理されるトランザクションを受信することができる。ここで、メジャーシェアホルダーノードを除いた残りのノードは、トランザクション仲介役だけを行うことができる。

【0061】

このように、全体ノードの中から、トランザクション処理のためのメジャーシェアホルダーノードを別個に選定すれば、分散合意に参加するすべての合意ノードのうちメジャーシェアホルダーノードのみ、処理されるトランザクションを受ける。したがって、全体ネットワークのトラフィックコストを低減することができる。ここで、メジャーシェアホルダーノードは、合意体が構成されると、自ら有するトランザクションを分散合意に用いることができる。

【0062】

図１は、本発明の一実施例によるメジャーシェアホルダーノードを含むノードの持分保有状態およびトランザクション処理を示すテーブルである。

【0063】

図１を参照すれば、全体ノードの個数は１００個であり、発行された総持分は１８０個であり、上位１０個のノードが所有した累積持分が９０個で全体持分の５０％であることが分かる。

【0064】

ここで、全体持分の５０％を所有したノード１、ノード２、ノード３、ノード４、ノード５、ノード６、ノード７、ノード８、ノード９およびノード１０がメジャーシェアホルダーノードとして選定される。ここで、選定されたメジャーシェアホルダーノードであるノード１、ノード２、ノード３、ノード４、ノード５、ノード６、ノード７、ノード８、ノード９およびノード１０のみ、処理されるトランザクションを受け、残りのノード１１、ノード１２、．．．、ノード９９およびノード１００は、トランザクション仲介役だけを行うことができる。

【0065】

以下、本発明の一実施例による分散合意のための合意ノード選定方法を説明する。

【0066】

基本的に、本発明の一実施例による合意ノードの選定は、前記式１および式２を持分ベースで用いて行われる。

【0067】

全体参加ノードが保有した持分の合計がｎ、ビザンチン比率がｂ_ｐの場合、最大ビザンチン持分はｂ（＝ｎ×ｂ_ｐ）になり、このとき、前記式１および式２を同時に満足するｐとｆを見つけることができる。

【0068】

すなわち、ブロックチェーンを構成するノードは、それぞれ自身の持分値だけ成功確率がｐであるコイントス（ｃｏｉｎ ｔｏｓｓ）を繰り返し行い、すべてのノードの結果を収集した後、成功した持分の合計が３ｆ＋１以上の場合、３ｆ＋１の持分を所有した任意のノードを合意ノード（合意体）として選定する。ここで、特定ノードが過度に多い合意体持分（コイントスに成功した持分）を保有するのを防止するために、参加持分のうち上限までのみ有効な持分として認める方式を適用してもよい。

【0069】

許容可能なビザンチン比率ｂ_ｐを２０％、Ｐ_{ｍｉｎ＿ｎｏｄｅ}＝１．０ｅ^－６、Ｐ_{ｍａｘ＿ｂｚｔ}＝２．０ｅ^－１６であると想定すれば、図１の例において、１００個のノードが保有した総持分ｎは１８０であるので、式１および式２を同時に満足するｆは３６であり、ｐは０．７６６６６６６６６６６６６６６７である。

【0070】

下記表１は、ビザンチン比率ｂ_ｐを２０％、Ｐ_{ｍｉｎ＿ｎｏｄｅ}＝１．０ｅ^－６、Ｐ_{ｍａｘ＿ｂｚｔ}＝２．０ｅ^－１６であると想定した場合、前述した論文「Ａｌｇｏｒｉｔｈｍ ｂａｓｅｄ ｏｎ Ｂｙｚａｎｔｉｎｅ ａｇｒｅｅｍｅｎｔ ａｍｏｎｇ ｄｅｃｅｎｔｒａｌｉｚｅｄ ａｇｅｎｔｓ（ＢＡＤＡ）」、米国特許出願公開第２０１９／０３２７０８４号明細書、米国特許出願公開第２０１９／０３７９５３８号明細書および米国特許出願公開第２０２０／０４０３７７６号明細書などに開示された分散合意アルゴリズムによって、ノードを基準として前記式１および式２を満足するｆとｐを見つけた場合と、本発明の一実施例により持分を基準として前記式１および式２を満足するｆを見つけた場合の結果を比較した表である。

【0071】

【表1】

【0072】

前記表１中、ノードベース（ＮＯＤＥ ＢＡＳＥＤ）方式の場合、ｎはすべてのノードの個数であり、３ｆ＋１は合意体（ｃｏｎｓｅｎｓｕｓ ｃｏｎｇｒｅｓｓ）に相当する合意ノード（ｃｏｎｓｅｎｓｕｓ ｎｏｄｅｓ）の個数であり、２ｆ＋１は合意定足数（ｃｏｎｓｅｎｓｕｓ ｑｕｏｒｕｍ）に相当する定足数ノード（ｑｕｏｒｕｍ ｎｏｄｅｓ）の個数であり、ｆは確率Ｐ_{ｍａｘ＿ｂｚｔ}に相応するビザンチンノードの個数である。

【0073】

前記表１中、持分ベース（ＳＨＡＲＥ ＢＡＳＥＤ）方式の場合、ｎはすべてのノードが保有した持分の総計であり、３ｆ＋１は合意体（ｃｏｎｓｅｎｓｕｓ ｃｏｎｇｒｅｓｓ）に相当する合意持分（ｃｏｎｓｅｎｓｕｓ ｓｈａｒｅｓ）の個数であり、２ｆ＋１は合意定足数（ｃｏｎｓｅｎｓｕｓ ｑｕｏｒｕｍ）に相当する定足数持分（ｑｕｏｒｕｍ ｓｈａｒｅｓ）の個数であり、ｆは確率Ｐ_{ｍａｘ＿ｂｚｔ}に相応するビザンチン持分の個数である。

【0074】

すなわち、参加ノードが成功確率ｐであるコイントスを自ら所有した持分値（ｓｈａｒｅ ｖａｌｕｅ）だけ繰り返し行うとき、成功した総持分の数は二項分布に従い、１回以上成功したすべてのノードは合意体候補ノードになる。言い換えれば、成功した持分を保有したすべてのノードが合意体候補ノードになる。

【0075】

表１の例において、条件を満足する総持分ｎと成功確率ｐを考慮すれば、平均的に１３８（＝ｎ×ｐ＝１８０×０．７６７）個程度の持分がコイントスに成功する。したがって、約１３８個の成功した持分の中から、１０９個（３ｆ＋１）の成功した持分（合意体持分）を所有したノードを合意体（ｃｏｎｓｅｎｓｕｓ ｃｏｎｇｒｅｓｓ）に相当する合意ノード（ｃｏｎｓｅｎｓｕｓ ｎｏｄｅｓ）として選択することができる。

【0076】

合意体持分１０９個を構成するとき、優先的にメジャーシェアホルダーノード（ｍａｊｏｒ ｓｈａｒｅｈｏｌｄｅｒ ｎｏｄｅｓ）から成功した持分を選択すれば、平均的に６９（＝９０×０．７６７）個程度のメジャーシェアホルダーノードの成功した持分が合意体持分として選択されるはずである。このとき、残りの４０個の合意体持分は、ノード１１からノード１００の間のノードの成功した持分から任意に（ｒａｎｄｏｍｌｙ）選択される。実際に選択される持分は確率分布によって決定されるが、ここでは、概念説明のために、簡単に平均値を例に挙げた。

【0077】

選択されたメジャーシェアホルダーノードの成功した持分６９個が、図１の１０個のメジャーシェアホルダーノードに分散していれば、合意体持分（ｃｏｎｓｅｎｓｕｓ ｓｈａｒｅｓ）を保有した合意体ノード（ｃｏｎｓｅｎｓｕｓ ｎｏｄｅｓ）は、１０個のメジャーシェアホルダーノードと残りの４０個のノード（残りのノードは持分が１であるので）とをあわせて計５０個になる。これは、前記表１から分かるように、ノードを基準として合意体を選抜すれば、１００個のノードが参加した場合、６１個の合意ノードが必要になるのに対し、より少ない数の合意ノードで分散合意が可能であることを意味する。

【0078】

また、既存のＤＰｏＳなどの委任方式の分散合意アルゴリズムでは、合意権限が委任されたノード（ＥＯＳの場合、ｂｐ ｎｏｄｅ）だけが合意に参加し、残りのノードは合意に参加できない。これに対し、本発明の一実施例による合意アルゴリズムは、全体合意体ノード５０個のうち１０個のみメジャーシェアホルダーノードとして選抜されるので、所有した持分が１以上である他のノードが依然として合意に参加できる。したがって、本発明の一実施例による合意アルゴリズムは、トランザクション処理のための別のノードを備えながらも、合意にはすべてのノードが参加可能で脱中央化の維持が可能である。

【0079】

図２は、本発明の一実施例による分散合意方法を示す動作フローチャートである。

【0080】

図２を参照すれば、本発明の一実施例による分散合意方法によれば、ブロックチェーンを構成するノードが、それぞれ持分値（ｓｈａｒｅ ｖａｌｕｅ）に相応する回数だけ成功確率ｐに相応する演算（ｏｐｅｒａｔｉｏｎ）を行う（Ｓ２１０）。

【0081】

ここで、ブロックチェーンを構成するノードは、トランザクション処理のためのメジャーシェアホルダー（ｍａｊｏｒ ｓｈａｒｅｈｏｌｄｅｒ）ノードを含むことができる。

【0082】

ここで、演算は、前記演算を行うノードのナンスチェーン（ｎｏｎｃｅ ｃｈａｉｎ）を用いて生成されたランダム値を用いて、前記成功確率に相応する基準値（ｔｈｒｅｓｈｏｌｄ）と比較することができる。

【0083】

また、本発明の一実施例による分散合意方法によれば、少なくとも１つの成功した前記演算に相応する持分（ａｔ ｌｅａｓｔ ｏｎｅ ｓｈａｒｅ ｃｏｒｒｅｓｐｏｎｄｉｎｇ ｔｏ ｔｈｅ ｏｐｅｒａｔｉｏｎ ｗｈｉｃｈ ｉｓ ｓｕｃｃｅｓｓｆｕｌ）を保有したノードが、合意体ノード（ｃｏｎｓｅｎｓｕｓ ｎｏｄｅｓ）として選定されるためのメッセージを送る（Ｓ２２０）。

【0084】

さらに、本発明の一実施例による分散合意方法によれば、成功した前記演算に相応する持分（ｓｈａｒｅｓ ｃｏｒｒｅｓｐｏｎｄｉｎｇ ｔｏ ｔｈｅ ｏｐｅｒａｔｉｏｎ ｗｈｉｃｈ ｉｓ ｓｕｃｃｅｓｓｆｕｌ）の中から選択された合意体持分（ｃｏｎｓｅｎｓｕｓ ｓｈａｒｅｓ）を保有したノードが、前記合意体ノードとして分散合意を行う（Ｓ２３０）。

【0085】

ここで、メジャーシェアホルダーノードが保有した持分のうち成功した前記演算に相応する持分は、合意体持分として選択されるための優先権（ｐｒｉｏｒｉｔｙ）を有することができる。

【0086】

ここで、メジャーシェアホルダーノードは、合意体持分の上限（ｕｐｐｅｒ ｌｉｍｉｔ）を有することができる。

【0087】

ここで、メジャーシェアホルダーノードは、持分保有順番に基づいて、持分を多く保有した順に前記ノードの中から選択される。

【0088】

ここで、メジャーシェアホルダーノードは、選択されたメジャーシェアホルダーノードの累積持分が全体持分の予め設定された比率以上になったり、選択されたメジャーシェアホルダーノードの個数が予め設定された個数以上になるまで選択される。

【0089】

ここで、メジャーシェアホルダーノードは、合意体ノードとして選定されれば、トランザクション（ｔｒａｎｓａｃｔｉｏｎｓ）を含むデリゲートリクエスト（ｄｅｌｅｇａｔｅ ｒｅｑｕｅｓｔ）メッセージを送り、合意体ノードのうちメジャーシェアホルダーノードではない他のノードは、トランザクションを含まないデリゲートリクエストメッセージを送ることができる。

【0090】

ここで、ブロックチェーンを構成するノードは、前記持分値（ｓｈａｒｅ ｖａｌｕｅ）のほか、少なくとも１つの他の持分値（ａｔ ｌｅａｓｔ ｏｎｅ ｏｔｈｅｒ ｓｈａｒｅ ｖａｌｕｅ）を有し、前記持分値と、前記他の持分値とに基づいて、他の種類のサービスを並列処理することができる。

【0091】

ここで、前記ナンスチェーンに相応するナンス値は、前記持分値と、前記他の持分値とを共有することができる。このようにナンス値を共有する場合、前ブロックの持分関連ハッシュを用いれば、２つ以上の持分値に対するコイントスが可能である。

【0092】

図３は、本発明の一実施例によるブロックチェーン生成方法により新規ブロックが合意されてブロックチェーンに追加される例を示すブロック図である。

【0093】

図３を参照すれば、現在ブロック１００まで合意完了してブロックチェーンに連結されている状態でブロック１０１に対する分散合意が行われて合意に成功すれば、ブロック１０１がブロックチェーンに連結されることが分かる。

【0094】

ここで、ブロック１００の合意過程でブロック１０１の合意体を決定するためのノード（ノードごとに持分値だけ）のコイントス結果が収集され、前述した例のように、１０９個の成功持分を所有した５０個のノードが合意体（合意ノード）として選定される。

【0095】

図４は、本発明の一実施例によるブロックチェーン生成方法を示すテーブルである。

【0096】

図４を参照すれば、本発明の一実施例によるブロックチェーン生成方法は、合意ノードのうちノード５がブロック１０１のチェアノードであることが分かる。

【0097】

図４の例は、図１～図３により説明した本発明の一実施例に相応するもので、合意ノードは１０９個の成功持分を保有した５０個のノードで、ノード１～ノード１０のメジャーシェアホルダーノードを含む。図４に明示的に示さないものの、合意ノードは、１０個のメジャーシェアホルダーノードを除いてノード１１～ノード１００から選択された４０個のノードを含む。

【0098】

図４の例において、合意体が構成されるとき、各ノードの成功持分も公開されたものと想定する。

【0099】

ブロック１００の合意後、まだ処理されていないトランザクションｔ１、ｔ２、ｔ３、ｔ４がそれぞれのメジャーシェアホルダーノードに伝達されて、ノード１～ノード１０がトランザクションｔ１、ｔ２、ｔ３、ｔ４を有している。

【0100】

ブロック１０１のデリゲートリクエスト（ｄｅｌｅｇａｔｅ ｒｅｑｕｅｓｔ）ステップで合意ノードそれぞれが自ら受信したトランザクション入りのメッセージをチェアノード（ｃｈａｉｒ ｎｏｄｅ）に伝達する。ここで、メッセージ形態はＤｒ（ｎｏｄｅ、｛ｔｘｓ｝）であってもよく、メッセージ完全性のために電子署名などの付加情報がメッセージに含まれてもよい。以下、説明の便宜のために、付加情報を除いた必須データについてのみ簡略に説明する。

【0101】

合意ノードのうちメジャーシェアホルダーノードであるノード１～ノード１０は、図３に示されるように、トランザクション｛ｔ１、ｔ２、ｔ３、ｔ４｝を含むＤｒ（ｎｏｄｅ、｛ｔ１、ｔ２、ｔ３、ｔ４｝）メッセージをチェアノードに伝達する。ここで、ノード１１～ノード１００から選択された４０個の合意ノードは持っているトランザクションがないので、Ｄｒ（ｎｏｄｅ、｛｝）のようなメッセージをチェアノードのノード５に送信する。

【0102】

デリゲートリクエスト（ｄｅｌｅｇａｔｅ ｒｅｑｕｅｓｔ）ステップで、チェアノードのノード５は、Ｄｒ（）メッセージ（ｄｅｌｅｇａｔｅ ｒｅｑｕｅｓｔ ｍｅｓｓａｇｅｓ）を送信したノードの成功した持分の合計が定足数（ｑｕｏｒｕｍ）の大きさである７３（２ｆ＋１）より大きく、同時にノード１～ノード１０から受信したＤｒ（）メッセージの成功した持分の合計が３７（ｆ＋１）個以上の場合に、プリペア（ｐｒｅｐａｒｅ）メッセージを生成して定足数ノード（ｑｕｏｒｕｍ ｎｏｄｅｓ）に伝達し、チェアノードの状態をプリペア（Ｐｒｅｐａｒｅ）に変更する。図４の例において、定足数ノードは、チェアノードを含む計１４個（ノード１、ノード２、ノード３、ノード４、ノード５、ノード６、ノード７、ノード８、ノード９、ノード１０、ノード１２、ノード３５、ノード７６、ノード１００）である。

【0103】

チェアノードによって生成されたプリペアメッセージ（ｐｒｅｐａｒｅ ｍｅｓｓａｇｅ）は、受信されたデリゲートリクエストメッセージそれぞれに含まれるトランザクション｛ｔ１、ｔ２、ｔ３、ｔ４｝のうち３７（ｆ＋１）個以上の成功した持分を所有したノードが処理要求したトランザクションと、付加情報とが含まれる。ここで、付加情報は、含まれたトランザクションに相応する証拠や多重署名のためのデータなどであってもよい。多重署名を用いた合意技術は、前述した論文および明細書に詳しく説明されている。

【0104】

前述のように、合意ノードのうちメジャーシェアホルダーノードが各自の持分だけコイントスを繰り返し行うとき、成功した総回数の平均は６９である。前述のように、ｆが３６であるので、このうち３７個（５３．６２％）の成功した持分の同意を取得したトランザクションを含むプリペアメッセージがチェアノードによって生成されるはずである。図４により説明された例において、トランザクション｛ｔ１、ｔ２、ｔ３、ｔ４｝を処理要求したノード１～ノード１０の１０個のノードが所有した成功した持分が６９個で３７（ｆ＋１）個以上であるので、トランザクションｔ１、ｔ２、ｔ３、ｔ４と、各トランザクションの処理要求ノードの成功持分証拠を含むプリペア（ｐｒｅｐａｒｅ）メッセージが生成され、定足数（ｑｕｏｒｕｍ）ノードに送信される。

【0105】

１０，０００ＴＰＳ（Ｔｒａｎｓａｃｔｉｏｎｓ Ｐｅｒ Ｓｅｃｏｎｄ）性能のために必要なトランザクションデータのノードあたりの負荷が２０Ｍｂｉｔｓ／ｓであり、ノード１～ノード１０は、１秒あたり１０，０００個のトランザクションを受信して異常の有無を確認しなければならず、１０，０００個のトランザクションを含むＤｒ（ｎｏｄｅ、｛１０，０００ｔｘｓ｝）メッセージを生成してチェアノードに送信しなければならない。この場合、チェアノードを除いた９個のノードからチェアノードに伝達されるロー（ｒａｗ）トランザクション伝達のためのトラフィックは１８０Ｍｂｉｔｓ／ｓが必要である。もちろん、トランザクションハッシュを用いれば、ネットワークコストを低減することができる。

【0106】

ノード１１～ノード１００の中から選択された４０個の合意ノードは受信して格納したトランザクションがないため、空のトランザクション入りのＤｒ（ｎｏｄｅ、｛｝）メッセージをチェアノードに伝達するので、トランザクション伝達のためのネットワークコストが０である。

【0107】

さらに、チェアノードの立場では、４０個のノードから受信したＤｒ（ｎｏｄｅ、｛｝）メッセージがトランザクションを含んでいないので、トランザクション処理のためのコンピューティング負荷が減少する。

【0108】

前述した論文および明細書に紹介された合意アルゴリズムの場合、前記表１に記載されたように、合意体ノード６１個のうちチェアノードを除いた６０個のノードがそれぞれ１０，０００個のトランザクションを含むＤｒ（ｎｏｄｅ、｛１０，０００ｔｘｓ｝）メッセージをチェアノードに送らなければならず、この場合、チェアノードが受信すべきトラフィックは６０×２０Ｍｂｉｔｓ／ｓ＝１，２００Ｍｂｐｓ／ｓにもなり、１Ｇｂｉｔｓ性能のネットワーク帯域幅でも処理が不可能である。もし、ネットワーク帯域幅に制限がない場合にも、チェアノードは６０個のメッセージがすべてトランザクションを含んでいるので、これを処理するためのコンピューティング資源を消耗するしかない。

【0109】

図４の例において、定足数ノードは、７３（２ｆ＋１）個の成功持分を所有した１４個のノード（ノード１、ノード２、ノード３、ノード４、ノード５、ノード６、ノード７、ノード８、ノード９、ノード１０、ノード１２、ノード３５、ノード７６、ノード１００）である。表１に記載されたように、ノードベース方式の場合、４１個のノードが定足数ノードにならなければならなかったため、本発明によれば、定足数ノードが４１個から１４個に減少して、合意処理過程のコンピューティング資源とネットワーク資源を低減する効果が発生する。下記表２は、ノードベース合意アルゴリズムと持分ベース合意アルゴリズムのノード個数の差を示す。

【0110】

【表2】

【0111】

再び図４を参照すれば、合意ノードのうちプリペア（ｐｒｅｐａｒｅ）メッセージを受信した定足数ノード（ｑｕｏｒｕｍ ｎｏｄｅｓ）は、ノード状態をプリペア（ｐｒｅｐａｒｅ）ステップに変更する。ノード状態がプリペアステップである定足数ノードのみコミット（ｃｏｍｍｉｔ）メッセージを生成することができる。ノード状態がプリペアステップである定足数ノードは、それぞれ受信したプリペアメッセージの異常の有無を確認し、異常がない場合、当該ノードの署名を含むコミットメッセージを生成してチェアに伝達し、ノード状態をコミット（ｃｏｍｍｉｔ）に変更する。

【0112】

プリペア状態のチェアノードは、自らを除いたすべての定足数ノードからコミットメッセージを受信した場合、最終的に合意されたトランザクションｔ１、ｔ２、ｔ３、ｔ４とノードの署名を結合した多重署名を含むコミッテッド（ｃｏｍｍｉｔｔｅｄ）ブロックを作って、自身のブロックチェーンでブロック１００の次にブロック１０１として追加する。これと同時に、チェアノードは、すべてのノードに合意されたブロック１０１を伝播し、ノード状態をコミッテッド（ｃｏｍｍｉｔｔｅｄ）状態に変更する。

【0113】

また、ブロック１０１に対してコミッテッド状態ではないすべてのノードは、コミッテッドブロックを受信してブロックの多重署名の異常の有無を確認して、異常がない場合にのみ、自分のブロックチェーンのブロック１００の次にブロック１０１を追加し、自身の状態をコミッテッド状態に変更する。ブロック１０１に対してコミッテッド状態であるすべてのノードは、ブロック１０２を合意する準備状態になる。

【0114】

図５は、本発明の一実施例によるブロックチェーン生成方法を示す動作フローチャートである。

【0115】

図５を参照すれば、本発明の一実施例によるブロックチェーン生成方法によれば、ブロックチェーンに追加ブロックを連結するために決定された合意体ノードの１つであるチェア（ｃｈａｉｒ）ノードが、前記合意体ノードのうちメジャーシェアホルダー（ｍａｊｏｒ ｓｈａｒｅｈｏｌｄｅｒ）ノードから前記ブロックチェーンに連結された前ブロックの合意後に処理されなければならないトランザクションを含むデリゲートリクエスト（ｄｅｌｅｇａｔｅ ｒｅｑｕｅｓｔ）メッセージを受信する（Ｓ５１０）。

【0116】

ここで、合意体ノードは、前記ブロックチェーンを構成するノードそれぞれの持分値（ｓｈａｒｅ ｖａｌｕｅ）に相応する回数だけ行われる、成功確率ｐに相応する演算（ｏｐｅｒａｔｉｏｎ）に基づいて選定される。

【0117】

ここで、合意体ノードは、成功した前記演算に相応する持分（ｓｈａｒｅｓ ｃｏｒｒｅｓｐｏｎｄｉｎｇ ｔｏ ｔｈｅ ｏｐｅｒａｔｉｏｎ ｗｈｉｃｈ ｉｓ ｓｕｃｃｅｓｓｆｕｌ）の中から選択された合意体持分（ｃｏｎｓｅｎｓｕｓ ｓｈａｒｅｓ）を保有したノードであってもよい。

【0118】

ここで、メジャーシェアホルダーノードは、持分保有順番に基づいて、持分を多く保有した順に前記ノードの中から選択される。

【0119】

ここで、メジャーシェアホルダーノードは、前記合意体持分の上限（ｕｐｐｅｒ ｌｉｍｉｔ）を有することができる。

【0120】

また、本発明の一実施例によるブロックチェーン生成方法によれば、前記チェアノードが、前記合意体ノードのうち前記メジャーシェアホルダーノードを除いた残りのノードから前記トランザクションを含まないデリゲートリクエストメッセージを受信する（Ｓ５２０）。

【0121】

ここで、ステップＳ５１０およびステップＳ５２０は、図１に示された順に順次に行われるのではなく、デリゲートリクエストメッセージを送信する合意ノードがデリゲートリクエストメッセージを送信する順序により行われる。すなわち、ステップＳ５１０およびステップＳ５２０は、図５に示された順序、その逆順または同時に行われる。

【0122】

また、本発明の一実施例によるブロックチェーン生成方法によれば、前記チェアノードが、前記トランザクションを含むデリゲートリクエストメッセージと、前記トランザクションを含まないデリゲートリクエストメッセージとを用いて、持分ベース検証を行う（Ｓ５３０）。

【0123】

ここで、持分ベース検証は、前記トランザクションを含むデリゲートリクエストメッセージおよび前記トランザクションを含まないデリゲートリクエストメッセージに相応する成功した持分の合計が、定足数の大きさ（２ｆ＋１）より大きいか否かを含むことができる。ここで、前記プリペアメッセージは、成功した持分の合計が前記定足数の大きさに１を加えた数の半分（ｆ＋１）に相当する基準自然数（ｒｅｆｅｒｅｎｃｅ ｎａｔｕｒａｌ ｎｕｍｂｅｒ）を用いて検証されたトランザクションを含むことができる。

【0124】

前記持分ベース検証が成功した場合、前記チェアノードは、定足数（ｑｕｏｒｕｍ）ノードにプリペア（ｐｒｅｐａｒｅ）メッセージを送る（Ｓ５４０）。

【0125】

また、本発明の一実施例によるブロックチェーン生成方法によれば、前記チェアノードが、前記定足数ノードからコミット（ｃｏｍｍｉｔ）メッセージを受信する（Ｓ５５０）。

【0126】

さらに、本発明の一実施例によるブロックチェーン生成方法によれば、前記チェアノードが、前記コミットメッセージに基づいて、前記ブロックチェーンに前記追加ブロックを連結する（Ｓ５６０）。

【0127】

図６は、本発明の一実施例によるブロックチェーンを構成するノードがそれぞれ持分値に相応する回数だけ成功確率に相応する演算を行う過程を示す動作フローチャートである。

【0128】

図６は、各ノードがＶＲＦ（Ｖｅｒｉｆｉａｂｌｅ Ｒａｎｄｏｍ Ｆｕｎｃｔｉｏｎ）や前述した論文および明細書で説明されたナンスチェーン（ｎｏｎｃｅ ｃｈａｉｎ）を用いて１回のコイントスを行う技術に基づいて、各ノードが保有した持分値（ｓｈａｒｅ ｖａｌｕｅ）だけコイントスを繰り返す技術を説明する。

【0129】

図６を参照すれば、まず、ランダム値Ｒｎが生成され、変数ｐａｓｓとｌｏｏｐが初期化されることが分かる（Ｓ６１０）。

【0130】

図６に示された例において、Ｒｎ＝Ｈａｓｈ（Ｎｏｎｃｅ（ｋ）、ＨＡＳＨ ＶＡＬＵＥ ＯＦ ＰＲＥＶＩＯＵＳ ＢＬＯＣＫ）は、前述した論文および明細書で詳しく説明されたように、ナンスチェーンを用いて任意のランダム値を１つ生成するプロセスである。ここで、「ＨＡＳＨ ＶＡＬＵＥ ＯＦ ＰＲＥＶＩＯＵＳ ＢＬＯＣＫ」は、前ブロックのヘッドハッシュに相応するものであってもよい。「ｌｏｏｐ＝ＳＨＡＲＥ ＶＡＬＵＥ」は、各ノードの持分値で、変数ｌｏｏｐを初期化することを意味する。変数ｐａｓｓは０に初期化される。

【0131】

変数ｌｏｏｐが０より大きいか否かが判断される（Ｓ６２０）。

【0132】

ステップＳ６２０でｌｏｏｐが０より大きいと判断されれば、コイントスを行う持分があることを意味するので、ステップＳ６３０へ進んで、コイントスに相当する演算を行う（Ｓ６３０）。

【0133】

ここで、ステップＳ６３０は、ランダム値Ｒｎが基準値（ｔｈｒｅｓｈｏｌｄ）より小さいか否かを判断することができる。基準値（ｔｈｒｅｓｈｏｌｄ）は、前記式１および式２により決定されたｐ値に相応する値で、ｐ値から決定できる。例えば、演算を３２ｂｉｔｓ単位とする場合、すべてのビットが１である３２ｂｉｔｓとｐとを乗じた値を基準値（ｔｈｒｅｓｈｏｌｄ）として用いることができる。

【0134】

ステップＳ６３０でＲｎが基準値（ｔｈｒｅｓｈｏｌｄ）より小さいと判断されれば、コイントスに成功したとみて、ステップＳ６４０へ進んで、変数ｐａｓｓを１だけ増加させる。

【0135】

以後、変数ｌｏｏｐは１だけ減少する（Ｓ６５０）。

【0136】

ステップＳ６３０でＲｎが基準値（ｔｈｒｅｓｈｏｌｄ）より小さいと判断されなければ、コイントスに失敗したとみて、変数ｐａｓｓを増加させずに、ステップＳ６５０へ進む。

【0137】

以後、現在Ｒｎをハッシュしてランダム値Ｒｎをアップデートする（Ｓ６６０）。

【0138】

ランダム値がアップデートされた後には、ステップＳ６２０が再び行われる。

【0139】

ステップＳ６２０でｌｏｏｐが０より大きくないと判断されれば、ステップＳ６７０が行われて、変数ｐａｓｓが０より大きいか否かを確認する。

【0140】

ステップＳ６７０の判断の結果、変数ｐａｓｓが０より大きいと判断されれば、Ｎｅｘｔ Ｃｏｎｇｒｅｓｓｍａｎメッセージを出力して、自身が次ブロックの合意体候補になりうることを知らせる（Ｓ６８０）。

【0141】

ここで、Ｎｅｘｔ Ｃｏｎｇｒｅｓｓｍａｎメッセージは、計算されたｐａｓｓ値を含むので、Ｎｅｘｔ Ｃｏｎｇｒｅｓｓメッセージを受信したノードは、Ｎｅｘｔ Ｃｏｎｇｒｅｓｓｍａｎメッセージを送信したノードがコイントスに成功した回数が分かる。

【0142】

ステップＳ６７０の判断の結果、変数ｐａｓｓが０より大きくないと判断されれば、動作を終了する。

【0143】

Ｎｅｘｔ Ｃｏｎｇｒｅｓｓｍａｎメッセージを受信した他のノードは、再び図６に示された段階を行って、異常の有無を確認することができる。

【0144】

図７は、本発明の一実施例によるブロックチェーンを構成するノードが互いに異なる類型の持分値を有する場合の例を示すテーブルである。

【0145】

図７を参照すれば、それぞれのノードが互いに異なる複数の持分値（ＳＨＡＲＥ ＶＡＬＵＥ１、ＳＨＡＲＥ ＶＡＬＵＥ２）を有することが分かる。

【0146】

このように、参加ノードそれぞれが互いに異なる複数の持分値を含むと、参加ノードが２つ以上の他の合意を並列処理することができる。

【0147】

持分値（ＳＨＡＲＥ ＶＡＬＵＥ１）に対してはノード１～ノード１０がメジャーシェアホルダーノードになって合意が進み、持分値（ＳＨＡＲＥ ＶＡＬＵＥ２）に対してはノード１１～２０がメジャーシェアホルダーノードになって合意が進む。したがって、持分値（ＳＨＡＲＥ ＶＡＬＵＥ１、ＳＨＡＲＥ ＶＡＬＵＥ２）は、それぞれ異なるブロックチェーンに新規ブロックを連結するのに用いられる。

【0148】

このように複数の持分値を用いると、ノードが過度に多い場合にも、互いに異なる種類のサービスをシャード（ｓｈａｒｄ）分離なしに処理可能である。

【0149】

複数の持分値を用いる場合、証明可能なランダム値を持分値ごとに別途に生成すれば、管理および運用に困難がありうる。この場合、持分値ごとに図６のＲｎを生成するとき、各ノードは１つのｎｏｎｃｅ（ｋ）のみを生成し、ノードが所有した持分値ごとに異なる「前ブロックの持分関連ハッシュ値」を用いれば、１つのｎｏｎｃｅ（ｋ）のみをもって２つ以上の持分値に対するコイントスを行うことができる。

【0150】

図８は、本発明の一実施例によるコンピュータシステムの構成を示すブロック図である。

【0151】

実施例による分散合意装置、ブロックチェーン生成装置およびブロックチェーンを構成するノードは、コンピュータで読み込み可能な記録媒体のようなコンピュータシステム７００で実現される。

【0152】

コンピュータシステム７００は、バス７２０を介して互いに通信する１つ以上のプロセッサ７１０と、メモリ７３０と、ユーザインターフェース入力装置７４０と、ユーザインターフェース出力装置７５０と、ストレージ７６０とを含むことができる。また、コンピュータシステム７００は、ネットワーク７８０に接続されるネットワークインターフェース７７０をさらに含むことができる。プロセッサ７１０は、中央処理装置またはメモリ７３０やストレージ７６０に格納されたプログラムまたは処理命令を実行する半導体装置であってもよい。メモリ７３０およびストレージ７６０は、揮発性媒体、不揮発性媒体、分離型媒体、非分離型媒体、通信媒体、または情報伝達媒体の少なくとも１つ以上を含む記憶媒体であってもよい。例えば、メモリ７３０は、ＲＯＭ７３１やＲＡＭ７３２を含むことができる。

【0153】

ここで、メモリ７３０には少なくとも１つのプログラムが記録される。

【0154】

ここで、プロセッサ７１０は、前記プログラムを実行することができる。ここで、前記プログラムは、ブロックチェーンを構成するノードそれぞれの持分値（ｓｈａｒｅ ｖａｌｕｅ）に相応する回数だけ成功確率ｐに相応する演算（ｏｐｅｒａｔｉｏｎ）を行い、少なくとも１つの成功した前記演算に相応する持分（ａｔ ｌｅａｓｔ ｏｎｅ ｓｈａｒｅ ｃｏｒｒｅｓｐｏｎｄｉｎｇ ｔｏ ｔｈｅ ｏｐｅｒａｔｉｏｎ ｗｈｉｃｈ ｉｓ ｓｕｃｃｅｓｓｆｕｌ）を保有したノードが合意体ノード（ｃｏｎｓｅｎｓｕｓ ｎｏｄｅｓ）として選定されるための、メッセージを送り、成功した前記演算に相応する持分（ｓｈａｒｅｓ ｃｏｒｒｅｓｐｏｎｄｉｎｇ ｔｏ ｔｈｅ ｏｐｅｒａｔｉｏｎ ｗｈｉｃｈ ｉｓ ｓｕｃｃｅｓｓｆｕｌ）の中から選択された合意体持分（ｃｏｎｓｅｎｓｕｓ ｓｈａｒｅｓ）を保有したノードを前記合意体ノードとして用いて分散合意を行うことができる。

【0155】

ここで、前記ブロックチェーンを構成するノードは、トランザクション処理のためのメジャーシェアホルダー（ｍａｊｏｒ ｓｈａｒｅｈｏｌｄｅｒ）ノードを含むことができる。

【0156】

ここで、前記メジャーシェアホルダーノードは、前記合意体ノードとして選定されれば、トランザクション（ｔｒａｎｓａｃｔｉｏｎｓ）を含むデリゲートリクエスト（ｄｅｌｅｇａｔｅ ｒｅｑｕｅｓｔ）メッセージを送り、前記合意体ノードのうちメジャーシェアホルダーノードではない他のノードは、トランザクションを含まないデリゲートリクエストメッセージを送ることができる。

【0157】

ここで、前記メジャーシェアホルダーノードが保有した持分のうち成功した前記演算に相応する持分は、前記合意体持分として選択されるための優先権（ｐｒｉｏｒｉｔｙ）を有することができる。

【0158】

ここで、前記メジャーシェアホルダーノードは、前記合意体持分の上限（ｕｐｐｅｒ ｌｉｍｉｔ）を有することができる。

【0159】

ここで、前記メジャーシェアホルダーノードは、持分保有順番に基づいて、持分を多く保有した順に前記ノードの中から選択される。

【0160】

本発明の一実施例による持分ベース分散合意方法は、図１の例により分かるように、トランザクションが伝達されるノードの数が１／１０に減少する効果がある。また、表２により分かるように、合意体の大きさがノードをｎとする場合に６１個であるのに対し、持分をｎとする場合は５０個に減少する。さらに、定足数の大きさは、ノードをｎとする場合に４１個であるが、持分をｎとする場合は１４個に減少するので、合意のためのメッセージ複雑度およびトラフィック量が大きく減少する。

【0161】

それだけでなく、図７の例のように、各ノードが互いに異なる持分値を２個以上有する場合、別々のサービスが１つのブロックチェーンで並列に処理できる。かつてこのような並列効果のためには物理的なシャード（ｓｈａｒｄ）分割を必要としていたが、本発明によれば、グループを分けなくても並列処理が可能である。

【0162】

以下、エポック単位でシャード（ｓｈａｒｄ）を分割せず、ブロックチェーンに付加的なチェーンを付加し、チェーンごとに並列処理を行う技術に関してより詳しく説明する。

【0163】

一般的なブロックチェーンシステムにおいてすべてのノードが新規ブロックを生成できるので、処理されるべきトランザクションはすべてのノードに伝達される必要がある。この場合、ブロックチェーンにあるすべてのノードがトランザクションを処理するために同一の処理を繰り返さなければならないので、ノードの増加による処理性能の増加を期待することが難しい。これを解決するために、シャードごとに別のトランザクションを処理するようにするシャーディングを適用すれば、シャードごとに処理されるトランザクションが分割されて並列処理されるので、全体ブロックチェーンの性能が向上する。

【0164】

シャードを運用するためには、エポック（ｅｐｏｃｈ）単位で各シャードに適切にノードを割当てることを繰り返して中央化を防止する。ここで、シャードは、ブロックチェーンに参加する１つ以上のノードの集合に相応するものであってもよい。しかし、エポック単位でノードを再び割当てる場合、エポックの中間（ｔｈｅ ｍｉｄｄｌｅ ｏｆ ｔｈｅ ｅｐｏｃｈ）にシャードを追加したり、１つのノードが同時に２つ以上のシャードに参加することが許容できない。一般的に、合意に参加するノードの数が増加すれば、セキュリティ性などブロックチェーンの特性に肯定的な効果が発生するが、シャードごとにノードを分散させれば、合意に参加するノードの数が減少する。

【0165】

イーサリアムでは、ＰｏＳ（Ｐｒｏｏｆ ｏｆ Ｓｔａｋｅ）を収容するために、３２イーサを預けたアカウントがバリデータ（ｖａｌｉｄａｔｏｒ）になり、これらの投票により合意が行われる。２つ以上のシャードがある場合には、これらのバリデータが任意に割当てられる。

【0166】

図１～図７により説明した分散合意方法、分散合意装置およびブロックチェーン生成方法によれば、ブロックチェーンに参加するノードが所有した資産（ａｓｓｅｔ）を用いて投票権（持分値）を取得することができる。ここで、資産と持分値との交換比率は１：１であってもよく、１：Ｋ（Ｋは正の実数）であってもよい。

【0167】

例えば、ブロックチェーンに参加する特定ノードは、特定チェーンの持分（ｓｈａｒｅ）のために保有した残高（ｂａｌａｎｃｅ）から１００の資産を預ける（ｄｅｐｏｓｉｔ）ことができ、資産と持分値との交換比率が１：１の場合、１００の持分値を得ることができる。ここで、前述のように、持分値は、結局、投票権に相当すると考えられる。

【0168】

図９は、ブロックチェーン参加ノードの資産保有状況の一例を示す表である。

【0169】

図９を参照すれば、ユーザＡ、Ｂ、Ｃ、Ｄ、Ｅ、Ｆ、Ｇ、Ｈ、Ｉ、Ｊ、Ｋは、各自のアカウントに資産（ａｓｓｅｔ）を保有しており、追加的なブロックチェーン（１０番目ブロックチェーンおよび１５番目ブロックチェーン）のためにユーザの一部は資産を預ける（ｄｅｐｏｓｉｔ）ことが分かる。以下、説明の便宜のために、資産と持分値との交換比率が１：１の場合を例に挙げて説明する。

【0170】

本発明の一実施例によれば、初期にメジャーシェアホルダー（ｍａｊｏｒ ｓｈａｒｅｈｏｌｄｅｒ）ノードだけで構成された合意体によって新しい付加的なチェーンを開始することができる。また、新たに生成された１つの付加的なチェーンに参加可能なノードの最大数をコントロールするために、マイナーシェアホルダー（ｍｉｎｏｒ ｓｈａｒｅｈｏｌｄｅｒ）ノードが所有したすべての持分値の合計が、メジャーシェアホルダー（ｍａｊｏｒ ｓｈａｒｅｈｏｌｄｅｒ）ノードが所有した持分値の合計より小さいか、等しい場合にのみ、新しいノードが当該チェーンに追加されるようにする。

【0171】

ここで、マイナーシェアホルダーノードは、特定チェーンに対して、図１～図８の例により説明したメジャーシェアホルダーノードを除いた他のすべてのノードに相応するものであってもよい。

【0172】

図９に示された例において、付加的なチェーン（１０番目チェーン）を追加するために、ノードＣ、Ｆ、Ｇがそれぞれ１０ずつの資産（ａｓｓｅｔ）を預け、１０番目チェーンのメジャーシェアホルダー（ｍａｊｏｒ ｓｈａｒｅｈｏｌｄｅｒ）ノードになり、１０番目チェーンで合意が開始できるようにする。ここで、１０番目チェーンのメジャーシェアホルダーノードが所有した持分値（ｓｈａｒｅ ｖａｌｕｅｓ）の合計が３０であるので、１０番目チェーンに追加できる残りのノードの持分値の合計が３０以下の場合にのみ、ノード追加が可能である。

【0173】

このように、１つのチェーンで許容される最大個数のノードが当該チェーンに参加した場合、より多くのノードが当該チェーンに追加されるためには、メジャーシェアホルダーノードの持分値の合計（第１合計持分値）を増加させなければならず、メジャーシェアホルダーノードの持分値の合計は拡張プロセスによって増加できる。ここで、拡張プロセスは、第１プロセス、第２プロセス、および第３プロセスのいずれか１つであってもよく、これについては、後により詳しく説明する。

【0174】

図９に示された例において、１０番目チェーンに参加するマイナーシェアホルダー（ｍｉｎｏｒ ｓｈａｒｅｈｏｌｄｅｒ）ノードの個数が３０個より少ない場合、投票の結果が常にメジャーシェアホルダーノードによって決定できるので、メジャーシェアホルダーノードの実際の適用投票数を制限してもよい。例えば、６個のマイナーシェアホルダーノードが１０番目チェーンに参加する場合、メジャーシェアホルダーノードＣ、Ｆ、Ｇそれぞれの最大投票権（ｓｈａｒｅ ｖａｌｕｅｓ）は、１０ではない２に制限されて、メジャーシェアホルダーノードの投票権（ｓｈａｒｅ ｖａｌｕｅ）の総計が、マイナーシェアホルダーノードの投票権の総計と一定比率維持されるようにする。この場合、メジャーシェアホルダーノードの投票が合意結果に過度の影響を及ぼさない。

【0175】

図９の例により説明された技術は、新しいサービスを提供するために新しいチェーンを生成するとき、試験的に少ない個数のノードだけが新しいチェーンに参加してサービスを運用し、サービスが活性化されれば、当該チェーンに参加するノードの個数を増加させるようにする。ここで、新しいチェーンのための初期メジャーシェアホルダーノードを構成する方法や条件などは、スマートコントラクトなどによって定められる。

【0176】

ここで、メジャーシェアホルダーノードだけでなく、マイナーシェアホルダーノードも、最小１の資産（ａｓｓｅｔ）を預け（ｄｅｐｏｓｉｔ）、合意体の構成に参加可能にして、無分別な参加や攻撃を予防することができる。ここで、メジャーシェアホルダーノードのための資産と持分値との交換比率と、マイナーシェアホルダーノードのための資産と持分値との交換比率が互いに異なっていてもよい。

【0177】

ここで、図４および図５により説明した合意アルゴリズムを用いる場合、メジャーシェアホルダーノードのみ処理する取引を受信しても合意が可能になる。ここで、図９の例のように、ノードが同時に２つのチェーンでメジャーシェアホルダーノードにならないように制限すれば、チェーンごとにメジャーシェアホルダーノードが分けられて処理する取引を分離して処理することができる。例えば、図９の例において、１０番目チェーンのメジャーシェアホルダーノードＣ、Ｆ、Ｇと、１５番目チェーンのメジャーシェアホルダーノードＡ、Ｂ、Ｄ、Ｅとは分離され、１０番目チェーンのメジャーシェアホルダーノードＣ、Ｆ、Ｇが処理するトランザクションと、１５番目チェーンのメジャーシェアホルダーノードＡ、Ｂ、Ｄ、Ｅが処理するトランザクションとは分離されて処理できる。ここで、マイナーシェアホルダーノードは、１０番目チェーンと１５番目チェーンの両方に参加できるが、トランザクションを受信しない。

【0178】

図９の例において、１０番目チェーンを開始した後、新たに１５番目チェーンが生成される。ここで、４個のノードＡ、Ｂ、Ｄ、Ｅがそれぞれ１５番目チェーンのために資産（ａｓｓｅｔ）を交換比率に相応するだけ預け、メジャーシェアホルダーノードになる。図９の例において、４個のノードＡ、Ｂ、Ｄ、Ｅは、それぞれ３００の資産を預け（ｄｅｐｏｓｉｔ）、３００の持分値（ｓｈａｒｅ ｖａｌｕｅ）を確保（交換比率１：１）してメジャーシェアホルダーノードになる。この場合、１５番目チェーンには、最大１２００個のノードがマイナーシェアホルダーノードとして参加可能になる。

【0179】

図１０は、図９に示された例において１０番目チェーンに参加したノードの参加ノード情報の一例を示す表である。

【0180】

図１０を参照すれば、１０番目チェーンに参加したノードの参加ノード情報には、１０番目チェーンに参加した参加ノードの識別子、参加ノードそれぞれが保有した持分値および当該ノードのメジャー／マイナーの如何が含まれる。

【0181】

図１０により例示された参加ノード情報は、１０番目チェーンに参加したノードの特性を示すデータ構造と考えられ、すべてのノードに公開される。

【0182】

図１０の例に相当する状態で、新規ノードが１０番目チェーンに参加しようとする場合、下記の条件を満足する場合にのみ、ノード追加が可能である。
＜ノード追加の条件＞
メジャーシェアホルダーノードの持分値の合計＊適用比率＞＝マイナーシェアホルダーノードの持分値の合計＋新規ノードの持分値

【0183】

ここで、適用比率は０より大きい実数値で、１より小さいか、等しく、例えば、１であってもよい。

【0184】

もし、特定チェーンに参加したノードの個数が許容最大値に達する場合、参加ノードの規模を増加させるための拡張プロセスが行われる。ここで、拡張プロセスは、前記メジャーシェアホルダーノードのいずれか１つ以上に相応する持分値を増加させる第１プロセス、新しいメジャーシェアホルダーノードを追加する第２プロセス、および少なくとも１つの前記マイナーシェアホルダーノードをメジャーシェアホルダーノードに変更する第３プロセス、のいずれか１つであってもよい。

【0185】

まず、第１プロセスは、メジャーシェアホルダーノードの個数は増加させず、既存のメジャーシェアホルダーノードの少なくとも１つ以上の持分値（ｓｈａｒｅ ｖａｌｕｅ）を増加させて参加ノード数を増加させることである。例えば、１０番目チェーンに参加するマイナーシェアホルダーノードの持分値の合計（第２合計持分値）が３１になる場合、ノードＣ、ＦおよびＧがそれぞれ１以上の持分値を増加させてより多くのノードがチェーンに参加できるようにする。

【0186】

次に、第２プロセスは、既存のメジャーシェアホルダーノードと類似の持分値を有する他のノードをチェーンに新しいメジャーシェアホルダーノードとして追加して、チェーンが収容できるノードの個数を増加させることである。例えば、１０番目チェーンに参加するマイナーシェアホルダーノードの持分値の合計（第２合計持分値）が３１になる場合、任意の新しいノードＸが持分値１０をもって１０番目チェーンの新しいメジャーシェアホルダーノードになる。

【0187】

最後に、第３プロセスは、参加ノードが最大値に達する場合、マイナーシェアホルダーノードのうち最も多い持分値を保有したノードがメジャーシェアホルダーノードに昇格されて、チェーンに参加可能なノードの個数を増加させることである。例えば、図１２に示された２０２番ブロックで１０番目チェーンに参加したマイナーシェアホルダーノードの持分値の合計（第２合計持分値）が３１になる場合、ユーザＩ（ＵＳＥＲ Ｉ）がマイナーシェアホルダーノードのうち最大持分値（２）を有しているので、メジャーシェアホルダーノードに昇格される。ここで、昇格結果は、図１２に示された１０３番ブロック（２０２番ブロックの生成タイミングに相応するメインブランチのブロック）に記録されてもよい。

【0188】

図１１は、図９に示された例において１５番目チェーンに参加したノードの参加ノード情報の一例を示す表である。

【0189】

図１１を参照すれば、１５番目チェーンに参加したノードの参加ノード情報には、１５番目チェーンに参加した参加ノードの識別子、参加ノードそれぞれが保有した持分値および当該ノードのメジャー／マイナーの如何が含まれる。

【0190】

図１１により例示された参加ノード情報は、１５番目チェーンに参加したノードの特性を示すデータ構造と考えられ、ブロックチェーンのすべてのノードに公開される。

【0191】

図１０および図１１に明示的に示さないものの、参加ノード情報には参加ノードそれぞれが預けた資産に関する情報が含まれてもよい。

【0192】

図９～図１１により説明された例のように、１つのノードが同時に１０番目チェーンおよび１５番目チェーンのメジャーシェアホルダーノードになることが不可能である。しかし、１つのノードがマイナーシェアホルダーノードとして２つ以上のチェーンに参加することは可能である。

【0193】

図１２は、ブロックチェーン（既存のチェーン）に付加的なチェーンが適用された例を示すブロック図である。

【0194】

図１２を参照すれば、まず、１００番～１０３番ブロックは、新規チェーンの生成に関する情報を記録するブロックチェーン（既存のチェーン）に相応し、１００番～１０３番ブロックに相応する既存のチェーンは、参加するノードの合意によって正常にブロックが連結される状態であることが想定できる。

【0195】

ここで、１０番目チェーン（付加的なチェーン）を新たに生成するために、ノードＣ、Ｆ、Ｇがそれぞれ１０の持分値（ｓｈａｒｅ ｖａｌｕｅ）をもって１０番目チェーンに参加できる。ここで、図１０の参加ノード情報が、図１２の１０１番ブロックに記録され、１０番目チェーンはブロック番号２００から始まる。ここで、２００番ブロックのブロックヘッドに記録される前ブロックのヘッダーハッシュ値は、１０１番ブロックのヘッダーハッシュ値に設定できる。

【0196】

以後、１５番目チェーン（付加的なチェーン）を新たに生成するために、付加的なチェーンを開始するメジャーシェアホルダーノードであるノードＡ、Ｂ、Ｄ、Ｅに関する参加ノード情報（図１１）が１０２番ブロックに記録される。前述のように、参加ノード情報は、１５番目チェーンに参加するノードそれぞれの識別子、持分値およびメジャー／マイナーの如何を含むことができる。ここで、１５番目チェーンは、図１２に示された３００番ブロックから始まる。ここで、１０２番ブロックのヘッダーハッシュ値が３００番ブロックのヘッダーに記録されて、既存のチェーンに枝（ｂｒａｎｃｈ）が新たに生成されたかのようになる。このような構造は、付加的なチェーンの個数が増加するにつれて、木（ｔｒｅｅ）のような構造を有するようになる。

【0197】

ここで、既存のチェーンに相応するブロック１００、１０１、．．．、１０３、付加的なチェーン（１０番目チェーン）に相応するブロック２００、２０１、．．．、２０２および付加的なチェーン（１５番目チェーン）に相応するブロック３００、１０１は、図１～図８により説明された合意アルゴリズムを用いて分散合意を行うことができる。ここで、既存のチェーンの合意体（ｃｏｎｓｅｎｓｕｓ ｃｏｎｇｒｅｓｓ）、付加的なチェーン（１０番目チェーン）の合意体および付加的なチェーン（１５番目チェーン）の合意体は互いに異なり、それぞれの合意体の合意は互いに独立していてもよい。

【0198】

すなわち、図１２に示された例では、新規チェーンの生成情報を記録するチェーン（１００番～１０３番ブロックを含む）を用いて、１０番目チェーンおよび１５番目チェーンが追加されてブロックが生成される。

【0199】

図９～図１２により説明された付加的なチェーンの追加は、図１～図８により説明された合意アルゴリズムと異なる他のアルゴリズムを用いた合意に基づいて行われてもよい。

【0200】

例えば、ＰＢＦＴ（Ｐｒａｃｔｉｃａｌ Ｂｙｚａｎｔｉｎｅ Ｆａｕｌｔ Ｔｏｌｅｒａｎｃｅ）合意アルゴリズムを用いて付加的なチェーンの追加が行われてもよい。ここで、合意体のチェアノードが処理されるべきトランザクションを有している場合には、自ら持っているすべてのトランザクションをすべて入れたブロックを候補ブロックとして提案して合意を行ってもよく、合意体のチェアノードが処理されるべきトランザクションを持っていない場合には、トランザクションのない候補ブロックを提案して合意を進行させてもよい。トランザクションのない候補ブロックに基づいた合意は、合意メッセージの大きさが非常に小さくて、非常に早い合意の実行が可能である。

【0201】

さらに、合意体のチェアノードが処理されるべきトランザクションを持っていない場合、候補ブロックを提案する前に、他のノードからトランザクションを受信してもよい。ここで、合意体のチェアノードは、確保されたトランザクションを含む候補ブロックを用いて分散合意を行うことができる。

【0202】

図１３は、１０番目チェーンと１５番目チェーンがマイナーシェアホルダーノードを共有する例を示す図である。

【0203】

図１３を参照すれば、メジャーシェアホルダーノードは、チェーン（シャード）ごとに処理するトランザクションを受信し処理しなければならないので、同時に２つ以上のチェーン（シャード）に参加できないが、残りのマイナーシェアホルダーノードは、２つ以上のチェーンに同時に参加できることが分かる。

【0204】

図１４は、本発明の一実施例によるブロックチェーンに新しいチェーンを追加する方法を示す動作フローチャートである。

【0205】

図１４を参照すれば、本発明の一実施例によるブロックチェーンに新しいチェーンを追加する方法は、ブロックチェーンのノードが前記付加的なチェーン（ａｄｄｉｔｉｏｎａｌ ｃｈａｉｎ）に相応する資産（ａｓｓｅｔ）を預ける（ｄｅｐｏｓｉｔ）（Ｓ１４１０）。

【0206】

また、本発明の一実施例によるブロックチェーンに新しいチェーンを追加する方法は、前記資産に相応する持分値（ｓｈａｒｅ ｖａｌｕｅ）に基づいて、前記ノードが前記付加的なチェーンに追加ブロックを連結するための合意体ノードの１つとして選択される（Ｓ１４２０）。

【0207】

ここで、合意体ノードは、少なくとも１つのメジャーシェアホルダーノードを含むことができ、少なくとも１つのマイナーシェアホルダーノードを含むこともできる。

【0208】

ここで、合意体ノードは、初期にメジャーシェアホルダーノードのみを含むことができる。

【0209】

ここで、ステップＳ１４２０のために、前記ノードは、図２に示されたステップＳ２１０、Ｓ２２０を行うことができる。

【0210】

また、本発明の一実施例によるブロックチェーンに新しいチェーンを追加する方法は、前記ノードが前記追加ブロックを連結するための分散合意を行う（Ｓ１４３０）。

【0211】

ここで、前記付加的なチェーンに参加するノードは、トランザクション処理のためのメジャーシェアホルダー（ｍａｊｏｒ ｓｈａｒｅｈｏｌｄｅｒ）ノードを含むことができる。

【0212】

ここで、付加的なチェーンに参加するノードは、前記メジャーシェアホルダーノードではないマイナーシェアホルダー（ｍｉｎｏｒ ｓｈａｒｅｈｏｌｄｅｒ）ノードを含み、前記マイナーシェアホルダーノードにはトランザクションが伝達されない。

【0213】

ここで、付加的なチェーンは、前記メジャーシェアホルダーノードに相応する第１合計持分値（ｆｉｒｓｔ ｔｏｔａｌ ｓｈａｒｅ ｖａｌｕｅ）と、前記マイナーシェアホルダーノードに相応する第２合計持分値（ｓｅｃｏｎｄ ｔｏｔａｌ ｓｈａｒｅ ｖａｌｕｅ）とに基づいて、新規ノードの参加可能の有無を決定できる。

【0214】

ここで、新規ノードの参加可能の有無は、前記第１合計持分値と前記第２合計持分値、および前記新規ノードの持分値の合計を比較した結果に基づいて決定される。

【0215】

ここで、第１合計持分値は、前記新規ノードが前記付加的なチェーンに参加可能にするための、拡張プロセスによって増加できる。

【0216】

ここで、拡張プロセスは、前記メジャーシェアホルダーノードのいずれか１つ以上に相応する持分値を増加させる第１プロセス、新しいメジャーシェアホルダーノードを追加する第２プロセス、および少なくとも１つの前記マイナーシェアホルダーノードをメジャーシェアホルダーノードに変更する第３プロセス、のいずれか１つであってもよい。

【0217】

ここで、前記ブロックチェーンの１つのブロックに前記付加的なチェーンに関するデータを記録することができる。

【0218】

ここで、前記付加的なチェーンに関するデータは、前記付加的なチェーンに参加するノードの参加ノード情報と、前記付加的なチェーンに参加するノードの持分値とを含むことができる。

【0219】

ここで、前記付加的なチェーンに関するデータは、前記付加的なチェーンの開始情報を含み、前記付加的なチェーンの開始ブロックは、前記付加的なチェーンに関するデータを記録した前記ブロックチェーンの少なくとも１つのブロックに関する情報を記録することができる。ここで、付加的なチェーンの開始情報は、前記付加的なチェーンが始まる時点での参加ノード情報に相応するものであってもよい。

【0220】

ここで、前記マイナーシェアホルダーノードの少なくとも１つは、前記付加的なチェーン以外のチェーンにマイナーシェアホルダーノードとして参加できる。

【0221】

ここで、前記メジャーシェアホルダーノードは、前記付加的なチェーン以外のチェーンにメジャーシェアホルダーノードとして参加できない。

【0222】

図１５は、本発明の一実施例によるブロックチェーンのシャード生成方法を示す動作フローチャートである。

【0223】

図１５を参照すれば、本発明の一実施例によるブロックチェーンのシャード生成方法は、付加的なチェーンにメジャーシェアホルダー（ｍａｊｏｒ ｓｈａｒｅｈｏｌｄｅｒ）ノードとして参加する（Ｓ１５１０）。

【0224】

ここで、ステップＳ１５１０は、ブロックチェーンの１つのノードによって行われるものであってもよい。

【0225】

ここで、メジャーシェアホルダーノードは、トランザクション処理のためのものであってもよい。

【0226】

また、本発明の一実施例によるブロックチェーンのシャード生成方法は、前記付加的なチェーンにマイナーシェアホルダー（ｍｉｎｏｒ ｓｈａｒｅｈｏｌｄｅｒ）ノードとして参加する（Ｓ１５２０）。

【0227】

ここで、ステップＳ１５２０は、ブロックチェーンの１つのノードによって行われるものであってもよく、ステップＳ１５２０を行うノードは、ステップＳ１５１０を行うノードとは異なるノードであってもよい。

【0228】

ここで、マイナーシェアホルダーノードにはトランザクションが伝達されない。

【0229】

また、本発明の一実施例によるブロックチェーンのシャード生成方法は、前記メジャーシェアホルダーノードおよび前記マイナーシェアホルダーノードのいずれか１つ以上を含む合意体（ｃｏｎｓｅｎｓｕｓ ｃｏｎｇｒｅｓｓ）を構成する（Ｓ１５３０）。

【0230】

ステップＳ１５３０で合意体を構成する方式は、図１～図８により説明された合意アルゴリズムに従ってもよく、図１～図８により説明された合意アルゴリズムと異なる他のＰＢＦＴなどの合意アルゴリズムに従ってもよい。

【0231】

以上に説明されたシャード（ｓｈａｒｄ）は、ブロックチェーンを構成するノードの集合に相応するものであってもよく、それぞれのシャードは、それぞれのチェーンに対応するものであってもよい。

【0232】

また、本発明の一実施例によるブロックチェーンに付加的なチェーンを追加する装置およびブロックチェーンのシャード生成装置は、図８に示されたハードウェアを用いて実現される。

【0233】

すなわち、メモリ７３０に記録され、プロセッサ７１０によって実行されるプログラムは、ブロックチェーンに追加される付加的なチェーンに相応する資産（ａｓｓｅｔ）を預け（ｄｅｐｏｓｉｔ）、前記資産に相応する持分値（ｓｈａｒｅ ｖａｌｕｅ）に基づいて、前記付加的なチェーンに追加ブロックを連結するための合意体ノードの１つとして選択されるようにし、前記追加ブロックを連結するための分散合意を行うことができる。

【0234】

ここで、前記付加的なチェーンに参加するノードは、トランザクション処理のためのメジャーシェアホルダー（ｍａｊｏｒ ｓｈａｒｅｈｏｌｄｅｒ）ノードを含むことができる。

【0235】

ここで、前記付加的なチェーンに参加するノードは、前記メジャーシェアホルダーノードではないマイナーシェアホルダー（ｍｉｎｏｒ ｓｈａｒｅｈｏｌｄｅｒ）ノードを含み、前記マイナーシェアホルダーノードにはトランザクションが伝達されない。

【0236】

ここで、前記付加的なチェーンは、前記メジャーシェアホルダーノードに相応する第１合計持分値（ｆｉｒｓｔ ｔｏｔａｌ ｓｈａｒｅ ｖａｌｕｅ）と、前記マイナーシェアホルダーノードに相応する第２合計持分値（ｓｅｃｏｎｄ ｔｏｔａｌ ｓｈａｒｅ ｖａｌｕｅ）とに基づいて、新規ノードの参加可能の有無を決定できる。

【0237】

ここで、前記マイナーシェアホルダーノードの少なくとも１つは、前記付加的なチェーン以外のチェーンにマイナーシェアホルダーノードとして参加できる。

【0238】

ここで、前記メジャーシェアホルダーノードは、前記付加的なチェーン以外のチェーンにメジャーシェアホルダーノードとして参加できない。

【0239】

また、メモリ７３０に記録され、プロセッサ７１０によって実行されるプログラムは、付加的なチェーンにメジャーシェアホルダー（ｍａｊｏｒ ｓｈａｒｅｈｏｌｄｅｒ）ノードとして参加し、前記付加的なチェーンにマイナーシェアホルダー（ｍｉｎｏｒ ｓｈａｒｅｈｏｌｄｅｒ）ノードとして参加し、前記メジャーシェアホルダーノードおよび前記マイナーシェアホルダーノードのいずれか１つ以上を含む合意体を構成することができる。

【0240】

本発明の一実施例によれば、運用中のブロックチェーンでノードが資産に連動した持分値を用いて付加的なチェーンのメジャーシェアホルダーノードになり、付加的なチェーンを直ちに追加することができる。

【0241】

ここで、付加的なチェーンは、メジャーシェアホルダーノードとしてのみ開始できる。

【0242】

以後、付加的なチェーンに新規ノードが参加する場合、新規ノードが有する持分値（ｓｈａｒｅ ｖａｌｕｅ）と付加的なチェーンのマイナーシェアホルダーノードが所有した持分値の合計（第２合計持分値）との合計が、付加的なチェーンのメジャーシェアホルダーノードが所有した持分値の合計（第１合計持分値）の一定比率より小さいか、等しい場合にのみ、新規ノードが付加的なチェーンに参加可能である。

【0243】

ここで、より多くのノードが付加的なチェーンに参加することを可能にするために、第１合計持分値は拡張プロセスによって増加でき、拡張プロセスは、前記メジャーシェアホルダーノードのいずれか１つ以上に相応する持分値を増加させる第１プロセス、新しいメジャーシェアホルダーノードを追加する第２プロセス、および少なくとも１つの前記マイナーシェアホルダーノードをメジャーシェアホルダーノードに変更する第３プロセス、のいずれか１つであってもよい。

【0244】

ここで、運用中のブロックチェーンで新たに付加的なチェーンを追加するために、既存のチェーンの特定ブロックに新しい付加的なチェーンのメジャーシェアホルダーノードに対するデータ（持分値、メジャー／マイナーの如何など）を記録することができる。

【0245】

以後、運用中の付加的なチェーンの変更事項（メジャーシェアホルダーノード、マイナーシェアホルダーノード、ノードの持分値など）を既存のチェーンにアップデートすることができる。ここで、付加的なチェーンの変更事項が記録される既存のチェーンのブロックは、付加的なチェーンの変更時点に相応するブロックであってもよい。

【0246】

前述のように、１つのノードが互いに異なるチェーンのメジャーシェアホルダーノードにならないようにすれば、各チェーンの取引処理ノードが互いに分離されるので、全体処理性能を向上させることができる。ここで、１つのノードが同時に互いに異なるチェーンのマイナーシェアホルダーノードになるので、複数のチェーンで行われる合意に参加できる。

【0247】

ここで、新しいチェーンの開始ブロックには、新しいチェーンの開始情報を記録した既存のチェーンのブロックに関する情報が記録される。これによって、既存のチェーンで新規チェーンが新しい枝（ｂｒａｎｃｈ）のように生成可能で、ツリー構造で付加的なチェーンが生成できる。

【0248】

本発明の一実施例によるブロックチェーンに付加的なチェーンを追加する方法、装置、このためのブロックチェーンのシャード生成方法および装置によれば、ブロックチェーン運用中にリアルタイムに付加的なチェーンを追加することができる。既存のブロックチェーンシャーディング技術では、シャードごとに担当ノードを分けて指定しなければならず、これらが同時に他のチェーンの合意体に参加できないので、リアルタイムにチェーンを追加することが不可能であった。

【0249】

また、本発明の一実施例によれば、メジャーシェアホルダーノードが有する持分値の合計（第１合計持分値）によって参加ノードの個数を調節することができる。これは、新しいビジネスを新規チェーンで始める場合、初期には少ない個数の参加ノードでビジネスを試し、必要に応じて、最大参加ノード数を調節することを可能にする。

【0250】

さらに、本発明の一実施例によれば、１つのノードが同時に２つ以上のチェーンにメジャーシェアホルダーノードとして参加できないようにすることで、トランザクションを受信し処理するノードをチェーンごとに分離可能で、動的にブロックチェーンに付加的なチェーンを追加する場合にも、重複トラフィックの発生を最小化することができる。

【0251】

以上、本発明によるブロックチェーンに付加的なチェーンを追加する方法、装置、そのためのブロックチェーンのシャード生成方法および装置は、上記のように説明された実施例の構成と方法が限定されて適用できるのではなく、上記の実施例は多様な変形が行われるように各実施例の全部または一部が選択的に組み合わされて構成されてもよい。

【符号の説明】

【0252】

７００：コンピュータシステム
７１０：プロセッサ
７２０：バス
７３０：メモリ
７３１：ＲＯＭ
７３２：ＲＡＭ
７４０：ユーザインターフェース入力装置
７５０：ユーザインターフェース出力装置
７６０：ストレージ
７７０：ネットワークインターフェース
７８０：ネットワーク

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】