(57)【要約】【課題】ブロックチェーンに格納されるデータの順序付けを、高速に確定できるデータ管理システム、データ管理方法及びデータ管理プログラムを提供すること。【解決手段】データ管理システム１は、分散ハッシュテーブルにより定義されたハッシュ関数の値域に対応付けられた複数のノード１０を備え、ノード１０は、１又は複数の順序付きデータを格納したブロック２１を生成するブロック生成部１１１と、ブロック２１をブロックチェーン２０に登録するブロック登録部１１２と、を備え、ブロック生成部１１１は、ハッシュ関数を用いて順序付きデータに基づく第１のハッシュ値を算出し、ブロックチェーン２０により順序付けられる次のブロック２１を生成するリーダノードを指定するＩＤとして、第１のハッシュ値をブロック２１に格納し、複数のノード１０のうち、指定されたリーダノードのみが次のブロック２１を生成する。【選択図】図２
2020014056.tif 000002
【特許請求の範囲】
【請求項１】
分散ハッシュテーブルにより定義されたハッシュ関数の値域に対応付けられた複数のノードを備え、
前記ノードは、
１又は複数の順序付きデータを格納したブロックを生成するブロック生成部と、
前記ブロックをブロックチェーンに登録するブロック登録部と、を備え、
前記ブロック生成部は、前記ハッシュ関数を用いて前記順序付きデータに基づく第１のハッシュ値を算出し、前記ブロックチェーンにより順序付けられる次のブロックを生成するリーダノードを指定するＩＤとして、前記第１のハッシュ値を前記ブロックに格納し、
前記複数のノードのうち、指定された前記リーダノードのみが前記次のブロックを生成するデータ管理システム。
【請求項２】
前記ブロック生成部は、前記順序付きデータに対する自ノードによる署名に基づいて、前記第１のハッシュ値を算出する請求項１に記載のデータ管理システム。
【請求項３】
前記ブロックチェーンにおける最初のブロックを生成する前記リーダノードは、所定の定数に基づく前記第１のハッシュ値により指定される請求項１又は請求項２に記載のデータ管理システム。
【請求項４】
前記ノードは、前記リーダノードにより生成された前記ブロックを承認するブロック承認部を備え、
前記ブロック生成部は、前記ブロックを生成する際に、前記ハッシュ関数を用いて前記順序付きデータに基づく第２のハッシュ値を算出し、前記次のブロックを承認する検証ノードを指定するＩＤとして、当該第２のハッシュ値を前記ブロックに格納し、
前記ブロック登録部は、前記ブロックチェーンにより順序付けられた前のブロックにより指定された検証ノードにより承認されたことを条件に、当該検証ノードの署名を付加した前記ブロックを前記ブロックチェーンに登録する請求項１から請求項３のいずれかに記載のデータ管理システム。
【請求項５】
前記ブロック生成部は、前記順序付きデータに対する前記検証ノードによる署名に基づいて、前記第１のハッシュ値及び前記第２のハッシュ値を算出する請求項４に記載のデータ管理システム。
【請求項６】
前記ブロックチェーンにおける最初のブロックを承認する前記検証ノードは、所定の定数に基づく前記第２のハッシュ値により指定される請求項４又は請求項５に記載のデータ管理システム。
【請求項７】
前記検証ノードは、複数の前記第２のハッシュ値により複数指定され、
前記ブロック登録部は、所定数以上の前記検証ノードにより承認されたことを条件に、当該所定数以上の前記検証ノードのグループ署名を付加した前記ブロックを前記ブロックチェーンに登録する請求項４から請求項６のいずれかに記載のデータ管理システム。
【請求項８】
前記ブロック生成部は、前記検証ノードによる承認が前記所定数に満たない場合、前記順序付きデータを含まないブロックを生成する請求項７に記載のデータ管理システム。
【請求項９】
分散ハッシュテーブルにより定義されたハッシュ関数の値域に対応付けられた複数のノードが、
１又は複数の順序付きデータを格納したブロックを生成するブロック生成ステップと、
前記ブロックをブロックチェーンに登録するブロック登録ステップと、を実行し、
前記ブロック生成ステップにおいて、前記ハッシュ関数を用いて前記順序付きデータに基づく第１のハッシュ値を算出し、前記ブロックチェーンにより順序付けられる次のブロックを生成するリーダノードを指定するＩＤとして、前記第１のハッシュ値を前記ブロックに格納し、
前記複数のノードのうち、指定された前記リーダノードのみが前記次のブロックを生成するデータ管理方法。
【請求項１０】
分散ハッシュテーブルにより定義されたハッシュ関数の値域に対応付けられた複数のノードに、
１又は複数の順序付きデータを格納したブロックを生成するブロック生成ステップと、
前記ブロックをブロックチェーンに登録するブロック登録ステップと、を実行させ、
前記ブロック生成ステップにおいて、前記ハッシュ関数を用いて前記順序付きデータに基づく第１のハッシュ値を算出させ、前記ブロックチェーンにより順序付けられる次のブロックを生成するリーダノードを指定するＩＤとして、前記第１のハッシュ値を前記ブロックに格納させ、
前記複数のノードのうち、指定された前記リーダノードのみに前記次のブロックを生成させるためのデータ管理プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ブロックチェーンを利用したデータ管理システム、データ管理方法及びデータ管理プログラムに関する。
【背景技術】
【０００２】
従来、分散環境において、データの正当性を確認しつつ、順序付けて管理する仕組みとして、ブロックチェーンが利用されている（例えば、特許文献１参照）。
ブロックチェーンでは、参加者によるコンセンサスアルゴリズムにより、合意形成されたブロックが順次生成される。生成されたブロックは、一列に繋がり、一時的に分岐が発生したとしても、コンセンサスによりいずれか一つに収束する。これらのブロックは改ざんが困難であり、一列に繋がったブロックの順序及びブロック内のデータの順序が保証される。
【先行技術文献】
【非特許文献】
【０００３】
【非特許文献１】Ｎａｋａｍｏｔｏ，  Ｓ．：  Ｂｉｔｃｏｉｎ：  Ａ  ｐｅｅｒ−ｔｏ−ｐｅｅｒ  ｅｌｅｃｔｒｏｎｉｃ  ｃａｓｈ  ｓｙｓｔｅｍ  （２００８）
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかしながら、従来のプルーフ・オブ・ワーク等のコンセンサスアルゴリズムは、報酬に関係する計算量の重さがネックとなり、最新のブロックが確定されるまで、すなわちデータの順序付けが確定するまでに長時間を要していた。
【０００５】
本発明は、ブロックチェーンに格納されるデータの順序付けを、高速に確定できるデータ管理システム、データ管理方法及びデータ管理プログラムを提供することを目的とする。
【課題を解決するための手段】
【０００６】
本発明に係るデータ管理システムは、分散ハッシュテーブルにより定義されたハッシュ関数の値域に対応付けられた複数のノードを備え、前記ノードは、１又は複数の順序付きデータを格納したブロックを生成するブロック生成部と、前記ブロックをブロックチェーンに登録するブロック登録部と、を備え、前記ブロック生成部は、前記ハッシュ関数を用いて前記順序付きデータに基づく第１のハッシュ値を算出し、前記ブロックチェーンにより順序付けられる次のブロックを生成するリーダノードを指定するＩＤとして、前記第１のハッシュ値を前記ブロックに格納し、前記複数のノードのうち、指定された前記リーダノードのみが前記次のブロックを生成する。
【０００７】
前記ブロック生成部は、前記順序付きデータに対する自ノードによる署名に基づいて、前記第１のハッシュ値を算出してもよい。
【０００８】
前記ブロックチェーンにおける最初のブロックを生成する前記リーダノードは、所定の定数に基づく前記第１のハッシュ値により指定されてもよい。
【０００９】
前記ノードは、前記リーダノードにより生成された前記ブロックを承認するブロック承認部を備え、前記ブロック生成部は、前記ブロックを生成する際に、前記ハッシュ関数を用いて前記順序付きデータに基づく第２のハッシュ値を算出し、前記次のブロックを承認する検証ノードを指定するＩＤとして、当該第２のハッシュ値を前記ブロックに格納し、前記ブロック登録部は、前記ブロックチェーンにより順序付けられた前のブロックにより指定された検証ノードにより承認されたことを条件に、当該検証ノードの署名を付加した前記ブロックを前記ブロックチェーンに登録してもよい。
【００１０】
前記ブロック生成部は、前記順序付きデータに対する前記検証ノードによる署名に基づいて、前記第１のハッシュ値及び前記第２のハッシュ値を算出してもよい。
【００１１】
前記ブロックチェーンにおける最初のブロックを承認する前記検証ノードは、所定の定数に基づく前記第２のハッシュ値により指定されてもよい。
【００１２】
前記検証ノードは、複数の前記第２のハッシュ値により複数指定され、前記ブロック登録部は、所定数以上の前記検証ノードにより承認されたことを条件に、当該所定数以上の前記検証ノードのグループ署名を付加した前記ブロックを前記ブロックチェーンに登録してもよい。
【００１３】
前記ブロック生成部は、前記検証ノードによる承認が前記所定数に満たない場合、前記順序付きデータを含まないブロックを生成してもよい。
【００１４】
本発明に係るデータ管理方法は、分散ハッシュテーブルにより定義されたハッシュ関数の値域に対応付けられた複数のノードが、１又は複数の順序付きデータを格納したブロックを生成するブロック生成ステップと、前記ブロックをブロックチェーンに登録するブロック登録ステップと、を実行し、前記ブロック生成ステップにおいて、前記ハッシュ関数を用いて前記順序付きデータに基づく第１のハッシュ値を算出し、前記ブロックチェーンにより順序付けられる次のブロックを生成するリーダノードを指定するＩＤとして、前記第１のハッシュ値を前記ブロックに格納し、前記複数のノードのうち、指定された前記リーダノードのみが前記次のブロックを生成する。
【００１５】
本発明に係るデータ管理プログラムは、分散ハッシュテーブルにより定義されたハッシュ関数の値域に対応付けられた複数のノードに、１又は複数の順序付きデータを格納したブロックを生成するブロック生成ステップと、前記ブロックをブロックチェーンに登録するブロック登録ステップと、を実行させ、前記ブロック生成ステップにおいて、前記ハッシュ関数を用いて前記順序付きデータに基づく第１のハッシュ値を算出させ、前記ブロックチェーンにより順序付けられる次のブロックを生成するリーダノードを指定するＩＤとして、前記第１のハッシュ値を前記ブロックに格納させ、前記複数のノードのうち、指定された前記リーダノードのみに前記次のブロックを生成させるためのものである。
【発明の効果】
【００１６】
本発明によれば、ブロックチェーンに格納されるデータの順序付けを、高速に確定できる。
【図面の簡単な説明】
【００１７】
【図１】実施形態に係るデータ管理システムの構成を示す概要図である。
【図２】実施形態に係るノードの機能構成を示すブロック図である。
【図３】実施形態に係るブロックチェーンに登録されるブロックの構成を示す図である。
【図４】実施形態に係るデータ管理システムによるブロックの生成及び登録の処理を示すフローチャートである。
【発明を実施するための形態】
【００１８】
以下、本発明の実施形態の一例について説明する。
図１は、本実施形態に係るデータ管理システム１の構成を示す概要図である。
データ管理システム１は、ピアツーピア（Ｐ２Ｐ）のネットワークにより構成された複数のノード１０によりブロックチェーン２０を分散管理する。
【００１９】
ｎ個のノード１０は、分散ハッシュテーブル（ＤＨＴ）により定義されたハッシュ関数の値域Ｈ、すなわちＮ個のキー（ハッシュ値）のいずれかに対応付けられる（Ｎ＞＞ｎ）。
ＤＨＴには、例えば、Ｃｈｏｒｄが用いられてよい。Ｃｈｏｒｄでは、各ノード１０が有するルーティングテーブルを用いて、通常、Ｏ（ｌｏｇＮ）の経路長で任意のノード１０に到達する。
【００２０】
なお、複数のノード１０は、負荷分散のための仮想ノードであってよく、この場合、実ノード（端末）は、それぞれが複数の仮想ノードに割り当てられる。
【００２１】
ブロックチェーン２０を構成する各ブロック２１は、複数のノード１０のうち指定された一つのリーダノードにより生成される。
このとき、各ブロック２１には、次のブロック２１の生成を担当するリーダノードのＩＤが格納される。このＩＤは、ＤＨＴのＮ個のキー（ハッシュ値）のいずれかであり、ＤＨＴにおいてこのキーを管理するノード１０のみがリーダノードとして、次のブロック２１を生成する。
【００２２】
図１の例では、例えばノード１０ａがブロック２１ａを生成し、ブロック２１ａで指定されたノード１０ｂがブロック２１ｂを生成し、ブロック２１ｂで指定されたノード１０ｃがブロック２１ｃを生成し、ブロック２１ｃで指定されたノード１０ｄがブロック２１ｄを生成している。
【００２３】
また、最新のブロック２１ｄは、検証ノードにより承認されることでブロックチェーン２０に登録される構成であってもよい。この場合、検証ノードも複数のノード１０から指定され、次のブロック２１を承認する検証ノードのＩＤが複数、ブロック２１に格納される。
【００２４】
各ノード１０は、ＤＨＴによるルーティングを用いることにより、効率的にリーダノード及び検証ノードと通信し、また、リーダノードから最新のブロックを他のノード１０へ配信できる。
また、一時的なネットワーク遮断又は遅延等の問題により一部のノード１０で最新のブロックチェーン２０の同期が取れなかった場合、又は新たなノード１０が参加した場合であっても、これらのノード１０は、ルーティングテーブルに記述された他のノード、又は現在保持しているブロック２１から特定されるリーダノードから、ブロックチェーン２０のローカルコピーを取得できる。
【００２５】
なお、データ管理システム１を構成する全てのノード１０がＤＨＴに参加し、リーダノード又は検証ノードとして指定可能であってもよいが、これには限られない。例えば、一部のノード１０にのみブロックの生成及び検証の権限が与えられ、他のノード１０は、ＤＨＴにアクセスしてブロックチェーン２０のローカルコピーを保持する構成であってもよい。
以下では、全てのノード１０がＤＨＴに参加しているものとして説明する。
【００２６】
図２は、本実施形態に係るノード１０の機能構成を示すブロック図である。
ノード１０は、制御部１１と記憶部１２とを備えた情報処理装置（コンピュータ）であり、制御部１１は、記憶部１２に格納されたソフトウェアを実行することにより、ブロック生成部１１１、ブロック登録部１１２、及びブロック承認部１１３として機能する。
【００２７】
ブロック生成部１１１は、１又は複数の順序付きデータを格納したブロック２１を生成する。
このとき、ブロック生成部１１１は、所定のハッシュ関数ｈｄを用いて順序付きデータに基づく第１のハッシュ値μを算出し、ブロックチェーン２０により順序付けられる次のブロック２１を生成するためのリーダノードを指定するＩＤとして、この第１のハッシュ値μをブロック２１に格納する。
【００２８】
具体的には、ブロック生成部１１１は、ｔ番目のリーダノードを指定する第１のハッシュ値μｔを、例えば、
μｔ＝ｈｄ（ｓｉｇ（μｔ−１，Ｔｔ−１）‖ｉｄｔ）
と計算する。ハッシュ関数への引数は、さらに追加されてもよい。
ここで、ｔ−１番目のブロック２１には、複数（２λ個）のデータが、例えば、マークルツリーとして格納され、ルートハッシュＴｔ−１に対して、μｔ−１で示されるｔ−１番目のリーダノードの署名が付与される。ｔ番目のリーダノードを示す第１のハッシュ値μｔは、この署名ｓｉｇ（μｔ−１，Ｔｔ−１）とｔ番目のブロック２１の識別子ｉｄｔとの連結に対するハッシュ演算により算出される。
【００２９】
また、ブロック生成部１１１は、ブロック２１を生成する際に、ハッシュ関数を用いて順序付きデータに基づく第２のハッシュ値ｖを算出し、次のブロック２１を承認するための検証ノードを指定するＩＤとして、この第２のハッシュ値ｖをブロックに格納してもよい。
【００３０】
具体的には、ブロック生成部１１１は、ｔ番目のブロック２１を承認するための検証ノードのグループを指定する第２のハッシュ値ｖｉ∈Ｖｔを、例えば、
ｖｉ＝ｈｄ（ｓｉｇ（Ｖｔ−１，Ｔｔ−１）‖ｉｄｔ‖ｉ）
と計算する。ハッシュ関数への引数は、さらに追加されてもよい。
ここで、ｉは、同一のブロック２１を検証する検証ノードのグループ内における識別番号であり、これにより複数の第２のハッシュ値ｖｉが算出される。ブロック２１に格納される複数のデータには、第２のハッシュ値ｖｉで示される検証ノードのグループＶｔによりグループ署名が付与される。
【００３１】
また、検証ノードが設けられる場合、前述のリーダノードを示す第１のハッシュ値μｔは、
μｔ＝ｈｄ（ｓｉｇ（Ｖｔ−１，Ｔｔ−１）‖ｉｄｔ）
のように、検証ノードによるグループ署名に基づいて生成されてもよい。
【００３２】
ここで、ブロックチェーン２０に登録される最初のブロック２１を担当するリーダノード及び検証ノードは、直前のブロック２１が存在しないため、前述の式でＩＤを算出することはできない。
この場合、ブロック生成部１１１は、例えば、
μ０＝ｈｄ（κ）
ｖｉ＝ｈｄ（κ‖ｉ）
のように、所定の定数κに基づいて、第１のハッシュ値及び第２のハッシュ値を算出してよい。
【００３３】
図３は、本実施形態に係るブロックチェーン２０に登録されるブロック２１の構成を示す図である。
ブロック２１には、複数のデータ（イベント１〜ｍ）がマークルツリーとして格納される。すなわち、リーダノードがｍ個のデータを受信するまで、次のブロック２１を担当するリーダノード及び検証ノードは決定されない。
【００３４】
ｍ個のデータによりマークルツリーが完成し、ルートハッシュに対して署名が付与されると、リーダノードは、ＤＨＴにより定義されたハッシュ関数ｈｄにより、次のブロック２１のリーダノードのＩＤと検証ノードのＩＤとを算出し、ブロック２１に格納する。
なお、データの数ｍ＝２λ、及びブロック２１毎の検証ノードの数は、適宜、設計されてよい。
【００３５】
なお、リーダノードは、ｍ個のデータを記録すると、これを超えるデータの登録要求は受け付けない。この場合、受信したデータを新たに指定したリーダノードへ転送してもよいし、要求元へ差し戻してもよい。
【００３６】
また、ブロック２１は、直前のブロック２１へのポインタを有している。これにより、一連のブロック２１の順序が規定され、ブロックチェーン２０の全体で、格納されたデータの順序が確定する。
さらに、ブロック２１には、ブロック全体の正当性を保証し改ざんを防止するために、リーダノードの署名が付与される。
【００３７】
ブロック登録部１１２は、ブロックチェーン２０により順序付けられた前のブロック２１により指定された検証ノードが承認したことを条件に、これらの検証ノードの署名を付加したブロック２１をブロックチェーン２０に登録する。
【００３８】
ここで、検証ノードは、複数の第２のハッシュ値により複数指定される。
したがって、ブロック登録部１１２は、所定数以上の検証ノードにより承認されたことを条件に、これら所定数以上の検証ノードのグループ署名を付加したブロック２１をブロックチェーン２０に登録する。なお、所定数は、固定値、又は検証ノードの数に応じた割合（例えば、半数）により適宜、設定されてよい。
【００３９】
一方、検証ノードによる承認が所定数に満たない場合、ブロック登録部１１２は、生成されたブロック２１を登録せず、順序付きデータ（イベント）を含まない空のブロック２１をブロック生成部１１１に生成させる。
このとき、ブロック生成部１１１は、新たなリーダノード及び検証ノードを指定し、指定された新たなリーダノードが否認されたブロック２１のデータを入れ替えて新たなブロック２１を生成する。
【００４０】
ブロック承認部１１３は、自ノードが検証ノードに指定された場合に、リーダノードにより生成されたブロック２１を受け取り、署名を返信することで承認する。
【００４１】
図４は、本実施形態に係るデータ管理システム１によるブロックの生成及び登録の処理を示すフローチャートである。
ステップＳ１において、リーダノードは、ブロック生成部１１１によりデータをブロック２１に記録する。
ステップＳ２において、リーダノードは、マークルツリーの大きさ（ｍ個）までデータを記録したか否かを判定する。この判定がＹＥＳの場合、処理は、ステップＳ３に移り、判定がＮＯの場合、処理はステップＳ１に戻る。
【００４２】
ステップＳ３において、リーダノードは、生成したブロック２１に対する検証ノードの署名を取得する。
ステップＳ４において、リーダノードは、所定数の署名が得られたか否かを判定する。この判定がＹＥＳの場合、処理はステップＳ７に移り、判定がＮＯの場合、処理はステップＳ５に移る。
【００４３】
ステップＳ５において、リーダノードは、生成済みのブロック２１が否認されたので、ブロック生成部１１１により、データを含まない空のブロック２１を生成する。
ステップＳ６において、リーダノードは、全ての検証ノードから空のブロック２１に対する署名を取得する。
【００４４】
ステップＳ７において、リーダノードは、生成したブロック２１を、ブロック登録部１１２によりブロックチェーン２０に登録する。
ステップＳ８において、リーダノードは、最新のブロック２１を他のノード１０に対して配信しネットワーク内で同期させる。
【００４５】
本実施形態によれば、データ管理システム１は、ＤＨＴにより定義されたハッシュ関数の値域に対応付けられた複数のノード１０によりブロックチェーン２０を管理し、ブロックチェーン２０に登録するブロック２１を、それぞれ複数のノード１０の中から指定した一つのリーダノードに生成させる。このとき、ブロック２１に格納された順序付きデータに基づく第１のハッシュ値により次のリーダノードを指定する。
【００４６】
したがって、データ管理システム１は、ブロック２１毎にＤＨＴのハッシュ関数によりランダムに、かつ、一意に決定されるリーダノードに責任を負わせることで、ブロックチェーン２０に格納されるデータの順序付けを、高速に確定できる。また、一つのリーダノードのみがブロック２１を生成されることで、ブロックチェーン２０の分岐が発生しないため、正当なブロック２１が直ちに確定する。
この結果、データ管理システム１は、例えば、金融取引又はイベントログ等の即時性が要求される順序付きデータを遅滞なく確定させることができる。
【００４７】
データ管理システム１は、ブロック２１に格納された順序付きデータに基づく第２のハッシュ値により検証ノードを指定する。これにより、リーダノードとは異なる複数のノード１０による承認を経てブロック２１が登録されるため、順序付きデータの正当性がより確実に保証される。
【００４８】
データ管理システム１は、リーダノードにおいて、格納した順序付きデータに対する自ノードの署名又は検証ノードの署名に基づいて、次のリーダノード及び検証ノードのＩＤであるハッシュ値を算出する。
したがって、データ管理システム１は、データの正当性を保証する署名に基づいてハッシュ値を算出することで、正当なリーダノード及び検証ノードを一意に決定できる。
【００４９】
データ管理システム１は、ブロックチェーン２０に登録する最初のブロック２１について、リーダノード及び検証ノードを所定の定数に基づくハッシュ値により指定する。これにより、データ管理システム１は、ブロックチェーン２０の運用開始時からＤＨＴに基づくリーダノード及び検証ノードの指定が可能となる。
【００５０】
データ管理システム１は、所定数以上の検証ノードにより承認されたことを条件に、グループ署名を付加したブロック２１を登録する。
したがって、データ管理システム１は、署名を返信しない一部の検証ノードによりブロック２１が登録されない事態を抑制でき、利便性を向上できる。
また、データ管理システム１は、検証ノードによる承認が所定数に満たない場合には、順序付きデータを含まない空のブロック２１を生成してブロックチェーン２０に登録することで、否認の実績を記録しつつ、新たなブロック２１により正当な順序付きデータを格納できる。
【００５１】
以上、本発明の実施形態について説明したが、本発明は前述した実施形態に限るものではない。また、前述した実施形態に記載された効果は、本発明から生じる最も好適な効果を列挙したに過ぎず、本発明による効果は、実施形態に記載されたものに限定されるものではない。
【００５２】
データ管理システム１によるデータ管理方法は、ソフトウェアにより実現される。ソフトウェアによって実現される場合には、このソフトウェアを構成するプログラムが、情報処理装置（コンピュータ）にインストールされる。また、これらのプログラムは、ＣＤ−ＲＯＭのようなリムーバブルメディアに記録されてユーザに配布されてもよいし、ネットワークを介してユーザのコンピュータにダウンロードされることにより配布されてもよい。さらに、これらのプログラムは、ダウンロードされることなくネットワークを介したＷｅｂサービスとしてユーザのコンピュータに提供されてもよい。
【符号の説明】
【００５３】
１  データ管理システム
１０  ノード
１１  制御部
１２  記憶部
２０  ブロックチェーン
２１  ブロック
１１１  ブロック生成部
１１２  ブロック登録部
１１３  ブロック承認部
【図１】
2020014056.tif 000003
【図２】
2020014056.tif 000004
【図３】
2020014056.tif 000005
【図４】
2020014056.tif 000006