特許 6859293 データ管理システム、データ管理方法及びデータ管理プログラム

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

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

(11)【特許番号】6859293

(24)【登録日】2021年3月29日

(45)【発行日】2021年4月14日

(54)【発明の名称】データ管理システム、データ管理方法及びデータ管理プログラム

(51)【国際特許分類】

   H04L 9/32 20060101AFI20210405BHJP

   G06F 21/64 20130101ALI20210405BHJP

   G06F 9/50 20060101ALI20210405BHJP

【ＦＩ】

   H04L9/00 675Z

   G06F21/64

   G06F9/50 150D

【請求項の数】10

【全頁数】11

(21)【出願番号】特願2018-133453(P2018-133453)

(22)【出願日】2018年7月13日

(65)【公開番号】特開2020-14056(P2020-14056A)

(43)【公開日】2020年1月23日

【審査請求日】2020年6月1日

(73)【特許権者】

【識別番号】000208891

【氏名又は名称】ＫＤＤＩ株式会社

(74)【代理人】

【識別番号】100106002

【弁理士】

【氏名又は名称】正林 真之

(74)【代理人】

【識別番号】100120891

【弁理士】

【氏名又は名称】林 一好

(72)【発明者】

【氏名】オニバン バス

(72)【発明者】

【氏名】仲野 有登

(72)【発明者】

【氏名】清本 晋作

【審査官】 行田 悦資

(56)【参考文献】

【文献】 国際公開第２０１７／１７０９１２（ＷＯ，Ａ１）

【文献】 特開２０１４−１２３２１８（ＪＰ，Ａ）

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

【文献】 特開２０１５−２２３２７（ＪＰ，Ａ）

【文献】 特開２０１２−２２１０１６（ＪＰ，Ａ）

【文献】 特開２０１０−１０３９４２（ＪＰ，Ａ）

【文献】 石黒尚久ほか，図解入門最新ブロックチェーンがよ〜くわかる本，株式会社秀和システム，２０１７年 ８月 １日，第1版，p.183-188

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

Ｈ０４Ｌ ９／３２

Ｇ０６Ｆ ９／５０

Ｇ０６Ｆ ２１／６４

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

【請求項1】

分散ハッシュテーブルにより定義されたハッシュ関数の値域に対応付けられた複数のノードを備え、
前記ノードは、
１又は複数の順序付きデータを格納したブロックを生成するブロック生成部と、
前記ブロックをブロックチェーンに登録するブロック登録部と、を備え、
前記ブロック生成部は、前記ハッシュ関数を用いて前記順序付きデータに基づく第１のハッシュ値を算出し、前記ブロックチェーンにより順序付けられる次のブロックを生成するリーダノードを指定するＩＤとして、前記第１のハッシュ値を前記ブロックに格納し、
前記複数のノードのうち、指定された前記リーダノードのみが前記次のブロックを生成するデータ管理システム。

【請求項2】

前記ブロック生成部は、前記順序付きデータに対する自ノードによる署名に基づいて、前記第１のハッシュ値を算出する請求項１に記載のデータ管理システム。

【請求項3】

前記ブロックチェーンにおける最初のブロックを生成する前記リーダノードは、所定の定数に基づく前記第１のハッシュ値により指定される請求項１又は請求項２に記載のデータ管理システム。

【請求項4】

前記ノードは、前記リーダノードにより生成された前記ブロックを承認するブロック承認部を備え、
前記ブロック生成部は、前記ブロックを生成する際に、前記ハッシュ関数を用いて前記順序付きデータに基づく第２のハッシュ値を算出し、前記次のブロックを承認する検証ノードを指定するＩＤとして、当該第２のハッシュ値を前記ブロックに格納し、
前記ブロック登録部は、前記ブロックチェーンにより順序付けられた前のブロックにより指定された検証ノードにより承認されたことを条件に、当該検証ノードの署名を付加した前記ブロックを前記ブロックチェーンに登録する請求項１から請求項３のいずれかに記載のデータ管理システム。

【請求項5】

前記ブロック生成部は、前記順序付きデータに対する前記検証ノードによる署名に基づいて、前記第１のハッシュ値及び前記第２のハッシュ値を算出する請求項４に記載のデータ管理システム。

【請求項6】

前記ブロックチェーンにおける最初のブロックを承認する前記検証ノードは、所定の定数に基づく前記第２のハッシュ値により指定される請求項４又は請求項５に記載のデータ管理システム。

【請求項7】

前記検証ノードは、複数の前記第２のハッシュ値により複数指定され、
前記ブロック登録部は、所定数以上の前記検証ノードにより承認されたことを条件に、当該所定数以上の前記検証ノードのグループ署名を付加した前記ブロックを前記ブロックチェーンに登録する請求項４から請求項６のいずれかに記載のデータ管理システム。

【請求項8】

前記ブロック生成部は、前記検証ノードによる承認が前記所定数に満たない場合、前記順序付きデータを含まないブロックを生成する請求項７に記載のデータ管理システム。

【請求項9】

分散ハッシュテーブルにより定義されたハッシュ関数の値域に対応付けられた複数のノードが、
１又は複数の順序付きデータを格納したブロックを生成するブロック生成ステップと、
前記ブロックをブロックチェーンに登録するブロック登録ステップと、を実行し、
前記ブロック生成ステップにおいて、前記ハッシュ関数を用いて前記順序付きデータに基づく第１のハッシュ値を算出し、前記ブロックチェーンにより順序付けられる次のブロックを生成するリーダノードを指定するＩＤとして、前記第１のハッシュ値を前記ブロックに格納し、
前記複数のノードのうち、指定された前記リーダノードのみが前記次のブロックを生成するデータ管理方法。

【請求項10】

分散ハッシュテーブルにより定義されたハッシュ関数の値域に対応付けられた複数のノードに、
１又は複数の順序付きデータを格納したブロックを生成するブロック生成ステップと、
前記ブロックをブロックチェーンに登録するブロック登録ステップと、を実行させ、
前記ブロック生成ステップにおいて、前記ハッシュ関数を用いて前記順序付きデータに基づく第１のハッシュ値を算出させ、前記ブロックチェーンにより順序付けられる次のブロックを生成するリーダノードを指定するＩＤとして、前記第１のハッシュ値を前記ブロックに格納させ、
前記複数のノードのうち、指定された前記リーダノードのみに前記次のブロックを生成させるためのデータ管理プログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、ブロックチェーンを利用したデータ管理システム、データ管理方法及びデータ管理プログラムに関する。

【背景技術】

【0002】

従来、分散環境において、データの正当性を確認しつつ、順序付けて管理する仕組みとして、ブロックチェーンが利用されている（例えば、特許文献１参照）。
ブロックチェーンでは、参加者によるコンセンサスアルゴリズムにより、合意形成されたブロックが順次生成される。生成されたブロックは、一列に繋がり、一時的に分岐が発生したとしても、コンセンサスによりいずれか一つに収束する。これらのブロックは改ざんが困難であり、一列に繋がったブロックの順序及びブロック内のデータの順序が保証される。

【先行技術文献】

【非特許文献】

【0003】

【非特許文献1】Ｎａｋａｍｏｔｏ， Ｓ．： Ｂｉｔｃｏｉｎ： Ａ ｐｅｅｒ−ｔｏ−ｐｅｅｒ ｅｌｅｃｔｒｏｎｉｃ ｃａｓｈ ｓｙｓｔｅｍ （２００８）

【発明の概要】

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

【0004】

しかしながら、従来のプルーフ・オブ・ワーク等のコンセンサスアルゴリズムは、報酬に関係する計算量の重さがネックとなり、最新のブロックが確定されるまで、すなわちデータの順序付けが確定するまでに長時間を要していた。

【0005】

本発明は、ブロックチェーンに格納されるデータの順序付けを、高速に確定できるデータ管理システム、データ管理方法及びデータ管理プログラムを提供することを目的とする。

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

【0006】

本発明に係るデータ管理システムは、分散ハッシュテーブルにより定義されたハッシュ関数の値域に対応付けられた複数のノードを備え、前記ノードは、１又は複数の順序付きデータを格納したブロックを生成するブロック生成部と、前記ブロックをブロックチェーンに登録するブロック登録部と、を備え、前記ブロック生成部は、前記ハッシュ関数を用いて前記順序付きデータに基づく第１のハッシュ値を算出し、前記ブロックチェーンにより順序付けられる次のブロックを生成するリーダノードを指定するＩＤとして、前記第１のハッシュ値を前記ブロックに格納し、前記複数のノードのうち、指定された前記リーダノードのみが前記次のブロックを生成する。

【0007】

前記ブロック生成部は、前記順序付きデータに対する自ノードによる署名に基づいて、前記第１のハッシュ値を算出してもよい。

【0008】

前記ブロックチェーンにおける最初のブロックを生成する前記リーダノードは、所定の定数に基づく前記第１のハッシュ値により指定されてもよい。

【0009】

前記ノードは、前記リーダノードにより生成された前記ブロックを承認するブロック承認部を備え、前記ブロック生成部は、前記ブロックを生成する際に、前記ハッシュ関数を用いて前記順序付きデータに基づく第２のハッシュ値を算出し、前記次のブロックを承認する検証ノードを指定するＩＤとして、当該第２のハッシュ値を前記ブロックに格納し、前記ブロック登録部は、前記ブロックチェーンにより順序付けられた前のブロックにより指定された検証ノードにより承認されたことを条件に、当該検証ノードの署名を付加した前記ブロックを前記ブロックチェーンに登録してもよい。

【0010】

前記ブロック生成部は、前記順序付きデータに対する前記検証ノードによる署名に基づいて、前記第１のハッシュ値及び前記第２のハッシュ値を算出してもよい。

【0011】

前記ブロックチェーンにおける最初のブロックを承認する前記検証ノードは、所定の定数に基づく前記第２のハッシュ値により指定されてもよい。

【0012】

前記検証ノードは、複数の前記第２のハッシュ値により複数指定され、前記ブロック登録部は、所定数以上の前記検証ノードにより承認されたことを条件に、当該所定数以上の前記検証ノードのグループ署名を付加した前記ブロックを前記ブロックチェーンに登録してもよい。

【0013】

前記ブロック生成部は、前記検証ノードによる承認が前記所定数に満たない場合、前記順序付きデータを含まないブロックを生成してもよい。

【0014】

本発明に係るデータ管理方法は、分散ハッシュテーブルにより定義されたハッシュ関数の値域に対応付けられた複数のノードが、１又は複数の順序付きデータを格納したブロックを生成するブロック生成ステップと、前記ブロックをブロックチェーンに登録するブロック登録ステップと、を実行し、前記ブロック生成ステップにおいて、前記ハッシュ関数を用いて前記順序付きデータに基づく第１のハッシュ値を算出し、前記ブロックチェーンにより順序付けられる次のブロックを生成するリーダノードを指定するＩＤとして、前記第１のハッシュ値を前記ブロックに格納し、前記複数のノードのうち、指定された前記リーダノードのみが前記次のブロックを生成する。

【0015】

本発明に係るデータ管理プログラムは、分散ハッシュテーブルにより定義されたハッシュ関数の値域に対応付けられた複数のノードに、１又は複数の順序付きデータを格納したブロックを生成するブロック生成ステップと、前記ブロックをブロックチェーンに登録するブロック登録ステップと、を実行させ、前記ブロック生成ステップにおいて、前記ハッシュ関数を用いて前記順序付きデータに基づく第１のハッシュ値を算出させ、前記ブロックチェーンにより順序付けられる次のブロックを生成するリーダノードを指定するＩＤとして、前記第１のハッシュ値を前記ブロックに格納させ、前記複数のノードのうち、指定された前記リーダノードのみに前記次のブロックを生成させるためのものである。

【発明の効果】

【0016】

本発明によれば、ブロックチェーンに格納されるデータの順序付けを、高速に確定できる。

【図面の簡単な説明】

【0017】

【図1】実施形態に係るデータ管理システムの構成を示す概要図である。

【図2】実施形態に係るノードの機能構成を示すブロック図である。

【図3】実施形態に係るブロックチェーンに登録されるブロックの構成を示す図である。

【図4】実施形態に係るデータ管理システムによるブロックの生成及び登録の処理を示すフローチャートである。

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

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

１ データ管理システム
１０ ノード
１１ 制御部
１２ 記憶部
２０ ブロックチェーン
２１ ブロック
１１１ ブロック生成部
１１２ ブロック登録部
１１３ ブロック承認部

【図1】

【図2】

【図3】

【図4】