特開 2024-131172 通信システム、ノード、及びプログラム

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

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

(11)【公開番号】P2024131172

(43)【公開日】2024-09-30

(54)【発明の名称】通信システム、ノード、及びプログラム

(51)【国際特許分類】

   G06Q 10/06 20230101AFI20240920BHJP

   G06Q 50/26 20240101ALI20240920BHJP

   H04L 9/32 20060101ALI20240920BHJP

   G06F 21/62 20130101ALI20240920BHJP

【ＦＩ】

G06Q10/06

G06Q50/26

H04L9/32 200Z

G06F21/62 318

【審査請求】未請求

【請求項の数】10

【出願形態】ＯＬ

(21)【出願番号】P 2023041267

(22)【出願日】2023-03-15

(71)【出願人】

【識別番号】000006633

【氏名又は名称】京セラ株式会社

(74)【代理人】

【識別番号】110001106

【氏名又は名称】弁理士法人キュリーズ

(72)【発明者】

【氏名】▲高▼橋 良浩

(72)【発明者】

【氏名】山下 裕之

(72)【発明者】

【氏名】石原 聡子

(72)【発明者】

【氏名】鄭 亥勝

(72)【発明者】

【氏名】藤澤 將

(72)【発明者】

【氏名】小山 亮

(72)【発明者】

【氏名】須藤 大貴

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

5L010

5L049

5L050

【Ｆターム（参考）】

5L010AA06

5L049AA06

5L049CC35

5L050CC35

(57)【要約】

【課題】低性能ノードに適用することが容易なコンセンサスアルゴリズムを実現する。
【解決手段】通信システムは、ブロックチェーン技術を用いて台帳を分散管理する複数のノードを備える。前記複数のノードは、前記台帳に追加する候補として生成されたブロックに賛成するか否かの投票を行う権利を有する複数の第１ノードと、前記複数の第１ノードの投票内容を集計する第２ノードと、を含む。前記第２ノードは、前記複数の第１ノードにおいて前記投票に参加した参加ノード及び前記投票に参加しなかった不参加ノードが存在することに基づいて、前記不参加ノードが前記参加ノードに前記投票を委任したとみなし、前記不参加ノードの投票内容として前記参加ノードの投票内容を採用する。
【選択図】図９

【特許請求の範囲】

【請求項1】

ブロックチェーン技術を用いて台帳を分散管理する複数のノードを備え、
前記複数のノードは、
前記台帳に追加する候補として生成されたブロックに賛成するか否かの投票を行う権利を有する複数の第１ノードと、
前記複数の第１ノードの投票内容を集計する第２ノードと、を含み、
前記第２ノードは、前記複数の第１ノードにおいて前記投票に参加した参加ノード及び前記投票に参加しなかった不参加ノードが存在することに基づいて、前記不参加ノードが前記参加ノードに前記投票を委任したとみなし、前記不参加ノードの投票内容として前記参加ノードの投票内容を採用する
通信システム。

【請求項2】

前記第２ノードは、前記不参加ノードが存在し、且つ複数の参加ノードが存在する場合、前記複数の参加ノードのそれぞれの信頼度情報に基づいて、前記複数の参加ノードの中から前記投票の委任先とみなす参加ノードを決定する
請求項１に記載の通信システム。

【請求項3】

前記第２ノードは、複数の不参加ノードが存在し、且つ前記複数の参加ノードが存在する場合、前記複数の参加ノードの中から優先度が高い順に前記複数の不参加ノードの数と同じ数の参加ノードを前記委任先として決定する
請求項２に記載の通信システム。

【請求項4】

前記第２ノードは、前記不参加ノードの数が前記参加ノードの数よりも多い場合、１つの参加ノードを２以上の不参加ノードの前記委任先として決定する
請求項３に記載の通信システム。

【請求項5】

前記第２ノードは、１つの参加ノードに対して委任を行う数が上限を超えないように、前記１つの参加ノードを前記複数の不参加ノードの委任先として決定する
請求項３に記載の通信システム。

【請求項6】

前記信頼度情報は、前記複数の参加ノードのそれぞれの過去の投票の参加状況及び／又は過去の投票の投票内容の妥当性に基づく情報である
請求項２に記載の通信システム。

【請求項7】

前記第２ノードは、前記不参加ノードが存在し、且つ前記不参加ノードが前記投票の委任に承諾していない場合、前記不参加ノードが前記委任を行わないとみなす
請求項１乃至６のいずれか１項に記載の通信システム。

【請求項8】

前記第２ノードは、前記不参加ノードが存在し、且つ前記不参加ノードが前記投票の委任に承諾すること又は前記投票を常に委任することを選択している場合、前記不参加ノードが前記委任を行うとみなす
請求項１乃至６のいずれか１項に記載の通信システム。

【請求項9】

ブロックチェーン技術を用いて台帳を分散管理する複数のノードを備える通信システムにおいて、前記台帳に追加する候補として生成されたブロックに賛成するか否かの投票を行う権利を有する複数の第１ノードの投票内容を集計する第２ノードであって、
前記複数の第１ノードにおいて前記投票に参加した参加ノード及び前記投票に参加しなかった不参加ノードが存在することに基づいて、前記不参加ノードが前記参加ノードに前記投票を委任したとみなし、前記不参加ノードの投票内容として前記参加ノードの投票内容を採用する制御部を備える
第２ノード。

【請求項10】

ブロックチェーン技術を用いて台帳を分散管理する複数のノードを備える通信システムにおいて、前記台帳に追加する候補として生成されたブロックに賛成するか否かの投票を行う権利を有する複数の第１ノードの投票内容を集計する第２ノードに、
前記複数の第１ノードにおいて前記投票に参加した参加ノード及び前記投票に参加しなかった不参加ノードが存在することに基づいて、前記不参加ノードが前記参加ノードに前記投票を委任したとみなし、前記不参加ノードの投票内容として前記参加ノードの投票内容を採用する処理を実行させる
プログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、通信システム、ノード、及びプログラムに関する。

【背景技術】

【0002】

近年、ブロックチェーン技術が注目されている。ブロックチェーン技術では、複数のノードによって自律分散型のネットワーク、具体的には、ピアツーピア（Ｐ２Ｐ）ネットワークが形成されるため、システムダウンが起きないというメリットがある。

【0003】

ブロックチェーン技術は、Ｐ２Ｐネットワーク内の取引（トランザクション）の履歴を各ノードが台帳として管理する仕組みを有する。このような仕組みは分散型台帳技術とも称され、台帳は分散台帳とも称される。１つのノードでトランザクションが発生した場合、参加している全てのノードで計算（検算）処理を行う。これにより、参加しているノードの中に不正がある場合や正常に動作しなかった場合でも、改ざんが非常に困難な正しい取引の履歴が残る仕組みが提供される。

【0004】

ブロックチェーン技術において、Ｐ２Ｐネットワークに所属する各ノードが、台帳に追加されるブロックの正当性を評価するためにコンセンサスアルゴリズムが用いられている。コンセンサスアルゴリズムの１つにＰｏＳ（Ｐｒｏｏｆ ｏｆ Ｓｔａｋｅ）がある。ＰｏＳでは、参加ノードは、保有する保証金（Ｓｔａｋｅ）に応じて、新規ブロックの正当性を検証するバリデータに選出される。バリデータは、プロポーザと称されるノードが生成した新規ブロックについて不正がないか等を検証し、その正当性について投票を行う。新規ブロックに賛成する旨の投票が一定の割合で集まった場合、当該ブロックが正当であるという合意が形成され、当該ブロックが台帳に追加される。

【0005】

ＰｏＳの欠点として、ノード数が多くなるとブロックの合意形成に時間がかかるという問題がある。この問題を解決する手法として、ＤＰｏＳ（Ｄｅｌｅｇａｔｅｄ Ｐｒｏｏｆ ｏｆ Ｓｔａｋｅ）がある（例えば、特許文献１参照）。ＤＰｏＳでは、各ノードの事前の投票によってブロックの生成及び承認を行うノードを選出し、選出したノードに対してブロックの生成及び承認を委任する。

【先行技術文献】

【特許文献】

【0006】

【特許文献1】特開２０２２－１６０６２０号公報

【発明の概要】

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

【0007】

しかしながら、既存のコンセンサスアルゴリズムは、ノードが十分な性能を有することを前提としたものが多く、ＩｏＴ（Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ）機器等の低性能ノードに適用することが難しい。例えば、予めノード同士の投票によりブロック生成・承認者を決定しておくＤＰｏＳでは、事前の選出処理を行う必要がある。また、ＤＰｏＳでは、不正や改ざんの可能性を考慮して、ブロック生成・承認者の入れ替えを行うために選定処理を定期的に行う必要がある。上述のように、既存のコンセンサスアルゴリズムは、低性能ノードには負担が大きいという問題がある。

【0008】

そこで、本開示は、低性能ノードに適用することが容易なコンセンサスアルゴリズムを実現する通信システム、ノード、及びプログラムを提供することを目的とする。

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

【0009】

第１の態様に係る通信システムは、ブロックチェーン技術を用いて台帳を分散管理する複数のノードを備える。前記複数のノードは、前記台帳に追加する候補として生成されたブロックに賛成するか否かの投票を行う権利を有する複数の第１ノードと、前記複数の第１ノードの投票内容を集計する第２ノードと、を含む。前記第２ノードは、前記複数の第１ノードにおいて前記投票に参加した参加ノード及び前記投票に参加しなかった不参加ノードが存在することに基づいて、前記不参加ノードが前記参加ノードに前記投票を委任したとみなし、前記不参加ノードの投票内容として前記参加ノードの投票内容を採用する。

【0010】

第２の態様に係るノードは、ブロックチェーン技術を用いて台帳を分散管理する複数のノードを備える通信システムにおいて、前記台帳に追加する候補として生成されたブロックに賛成するか否かの投票を行う権利を有する複数の第１ノードの投票内容を集計する第２ノードである。前記第２ノードは、前記複数の第１ノードにおいて前記投票に参加した参加ノード及び前記投票に参加しなかった不参加ノードが存在することに基づいて、前記不参加ノードが前記参加ノードに前記投票を委任したとみなし、前記不参加ノードの投票内容として前記参加ノードの投票内容を採用する制御部を備える。

【0011】

第３の態様に係るプログラムは、ブロックチェーン技術を用いて台帳を分散管理する複数のノードを備える通信システムにおいて、前記台帳に追加する候補として生成されたブロックに賛成するか否かの投票を行う権利を有する複数の第１ノードの投票内容を集計する第２ノードに、前記複数の第１ノードにおいて前記投票に参加した参加ノード及び前記投票に参加しなかった不参加ノードが存在することに基づいて、前記不参加ノードが前記参加ノードに前記投票を委任したとみなし、前記不参加ノードの投票内容として前記参加ノードの投票内容を採用する処理を実行させる。

【発明の効果】

【0012】

本開示の一態様によれば、低性能ノードに適用することが容易なコンセンサスアルゴリズムを実現する通信システム、ノード、及びプログラムを提供できる。

【図面の簡単な説明】

【0013】

【図1】一般的なブロックチェーン技術を用いる通信システムにおけるネットワーク構成例を示す図である。

【図2】各ノードが管理する台帳の構成例を示す図である。

【図3】台帳に新たなブロックを追加する際の動作例を示す図である。

【図4】台帳に新たなブロックを追加する際の動作例を示す図である。

【図5】各ノードの構成例を示す図である。

【図6】一実施形態に係る自動的な投票委任について説明するための図である。

【図7】一実施形態に係る自動的な投票委任について説明するための図である。

【図8】一実施形態に係る第３ノードが管理する情報の一例を示す図である。

【図9】一実施形態に係る自動的な投票委任に関する第２ノードの動作フロー例を示す図である。

【図10】一実施形態に係る自動的な投票委任に関する信頼度情報（信頼性リスト）の管理フロー例を示す図である。

【図11】一実施形態に係るグループ署名を説明するための図である。

【図12】一実施形態に係るグループ署名に関する概略動作フロー例を示す図である。

【図13】一実施形態に係るグループ署名に関する第１動作パターンの一例を示す図である。

【図14】一実施形態に係るグループ署名に関する第１動作パターンの変更例を示す図である。

【図15】一実施形態に係るグループ署名に関する第２動作パターンの一例を示す図である。

【図16】一実施形態に係るグループ署名に関する第３動作パターンの一例を示す図である。

【図17】一実施形態に係るネットワーク構成例を示す図である。

【図18】一実施形態に係る台帳の管理方法について説明するための図である。

【図19】一実施形態に係る台帳の管理方法について説明するための図である。

【図20】一実施形態に係る階層構造ネットワークを一般的なネットワーク構成と比較した場合の計算量の削減効果を説明するための図である。

【図21】一実施形態に係る上位階層台帳と下位階層台帳とのリンクについて説明するための図である。

【図22】一実施形態に係る上位階層台帳と下位階層台帳とのリンクについて説明するための図である。

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

【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】

なお、不参加ノードは、投票締め切りのタイミングまでに投票を行わなかった第１ノード１００Ａである。投票締め切りのタイミングは、投票の受け付け開始から所定時間が経過（すなわち、タイマの満了によるタイムアウト）したタイミングであってもよい。また、投票の受け付けは、新規ブロックに賛成する旨の投票（委任を含む）が一定の割合（例えば、２／３）で集まったタイミングで終了する。その場合、新規ブロックが確定（承認）されて台帳に追加される。さらに、投票の受け付けは、新規ブロックに反対する旨の投票（委任を含む）が一定の割合（例えば、１／３）で集まったタイミングで終了する。その場合、新規ブロックが否決されて破棄される。

【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】

ステップＳ３３において、第２ノード１００Ｂは、次の新規ブロックを生成及び提案し、投票処理（第１ノード１００Ａからの投票の受け付け）を行う。

【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】

図１６は、一実施形態に係るグループ署名に関する第３動作パターンの一例を示す図である。第３動作パターンは、上述の自動的な投票委任を、上述のグループ署名の第１動作パターンと組み合わせた動作例である。ここでは、ノードＤが委任を行うものとし、上述のグループ署名の第１動作パターンと重複する動作については重複する説明を省略する。

【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】

１０ ：階層構造ネットワーク
１００ ：ノード
１１０ ：通信部
１２０ ：制御部
１２１ ：プロセッサ
１３０ ：記憶部
１４０ ：バッテリ
２００ ：Ｐ２Ｐネットワーク（グループ）

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】

【図20】

【図21】

【図22】