(57)【要約】【課題】複数のブロックチェーンそれぞれの信頼性を向上できるブロックチェーン管理システム、ブロックチェーン管理方法及びブロックチェーン管理プログラムを提供すること。【解決手段】ブロックチェーン管理システム１は、複数のノード１０からなるグループがそれぞれ、互いに異なるブロックチェーンに属し、各ノード１０は、自身が属するブロックチェーンのブロックを生成する際に、当該ブロックに対するコンセンサスへの参加者として、当該ブロックチェーンに属するノード１０に加えて、他のブロックチェーンに属する複数のノード１０をランダムに選択する選択部１１を備える。【選択図】図１
2020061696.tif 000002
【特許請求の範囲】
【請求項１】
複数のノードからなるグループがそれぞれ、互いに異なるブロックチェーンに属し、
各ノードは、自ノードが属するブロックチェーンのブロックを生成する際に、当該ブロックに対するコンセンサスへの参加者として、当該ブロックチェーンに属するノードに加えて、他のブロックチェーンに属する複数のノードをランダムに選択する選択部を備えるブロックチェーン管理システム。
【請求項２】
前記選択部は、自ノードが属するブロックチェーンにおいて直前に生成されたブロックのハッシュ値の少なくとも一部を入力とした選択関数により、前記他のブロックチェーンに属する複数のノードを選択する請求項１に記載のブロックチェーン管理システム。
【請求項３】
前記選択関数は、暗号学的ハッシュ関数であり、
前記選択部は、前記ハッシュ関数の出力から所定のビット長のＩＤを複数抽出し、当該ＩＤに対応する、前記他のブロックチェーンに属する複数のノードを選択する請求項２に記載のブロックチェーン管理システム。
【請求項４】
前記選択部は、前記直前に生成したブロックに所定の初期ベクトルを連結した値を前記ハッシュ関数に入力する請求項３に記載のブロックチェーン管理システム。
【請求項５】
前記選択部は、前記コンセンサスが不成立の場合、前記初期ベクトルを更新する請求項４に記載のブロックチェーン管理システム。
【請求項６】
前記選択部は、自ノードが属するブロックチェーンのノードの数に応じて、選択する前記他のブロックチェーンに属する複数のノードの数を決定する請求項１から請求項５のいずれかに記載のブロックチェーン管理システム。
【請求項７】
複数のノードからなるグループがそれぞれ、互いに異なるブロックチェーンに属し、
各ノードは、自ノードが属するブロックチェーンのブロックを生成する際に、当該ブロックに対するコンセンサスへの参加者として、当該ブロックチェーンに属するノードに加えて、他のブロックチェーンに属する複数のノードをランダムに選択するブロックチェーン管理方法。
【請求項８】
複数のノードからなるグループがそれぞれ、互いに異なるブロックチェーンに属し、
各ノードに、自ノードが属するブロックチェーンのブロックを生成する際に、当該ブロックに対するコンセンサスへの参加者として、当該ブロックチェーンに属するノードに加えて、他のブロックチェーンに属する複数のノードをランダムに選択させるためのブロックチェーン管理プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数のブロックチェーンを管理するためのシステム、方法及びプログラムに関する。
【背景技術】
【０００２】
従来、分散データベースであるブロックチェーンは、改竄が困難なデータ記録方式として、様々なシステムへの活用方法が提案されている（例えば、非特許文献１〜３参照）。
【先行技術文献】
【非特許文献】
【０００３】
【非特許文献１】Ｓａｔｏｓｈｉ  Ｎａｋａｍｏｔｏ．  Ｂｉｔｃｏｉｎ：  Ａ  ｐｅｅｒ−ｔｏ−ｐｅｅｒ  ｅｌｅｃｔｒｏｎｉｃ  ｃａｓｈ  ｓｙｓｔｅｍ，  ２００８．
【非特許文献２】Ｓｏｍｐｏｌｉｎｓｋｙ，  Ｙ．，  Ｚｏｈａｒ，  Ａ．：  Ａｃｃｅｌｅｒａｔｉｎｇ  ｂｉｔｃｏｉｎ’ｓ  ｔｒａｎｓａｃｔｉｏｎ  ｐｒｏｃｅｓｓｉｎｇ．  Ｆａｓｔ  ｍｏｎｅｙ  ｇｒｏｗｓ  ｏｎ  ｔｒｅｅｓ，  ｎｏｔ  ｃｈａｉｎｓ．  ＩＡＣＲ  Ｃｒｙｐｔｏｌｏｇｙ  ｅＰｒｉｎｔ  Ａｒｃｈｉｖｅ  ２０１３  （２０１３）８８１．
【非特許文献３】Ｌｅｗｅｎｂｅｒｇ，  Ｙ．，  Ｓｏｍｐｏｌｉｎｓｋｙ，  Ｙ．，  Ｚｏｈａｒ，  Ａ．：  Ｉｎｃｌｕｓｉｖｅ  ｂｌｏｃｋ  ｃｈａｉｎ  ｐｒｏｔｏｃｏｌｓ．  Ｉｎ：Ｆｉｎａｎｃｉａｌ  Ｃｒｙｐｔｏｇｒａｐｈｙ  ａｎｄ  Ｄａｔａ  Ｓｅｃｕｒｉｔｙ  −  １９ｔｈ  Ｉｎｔｅｒｎａｔｉｏｎａｌ  Ｃｏｎｆｅｒｅｎｃｅ，  ＦＣ２０１５，  Ｓａｎ  Ｊｕａｎ，  Ｐｕｅｒｔｏ  Ｒｉｃｏ，  Ｊａｎｕａｒｙ  ２６−３０，  ２０１５，  Ｒｅｖｉｓｅｄ  Ｓｅｌｅｃｔｅｄ  Ｐａｐｅｒｓ．  （２０１５）５２８−５４７．
【発明の概要】
【発明が解決しようとする課題】
【０００４】
通常、ブロックチェーンでは、記録されたデータの正当性を保証するために、所定のコンセンサス・アルゴリズムによって利用者による合意形成を行う。
ところが、複数の組織（グループ）によってローカルなブロックチェーンがそれぞれ運用されると、各ブロックチェーンの規模の低下に伴って、コンセンサスにおける結託攻撃のリスクが増えるため、信頼性が低下していた。
【０００５】
本発明は、複数のブロックチェーンそれぞれの信頼性を向上できるブロックチェーン管理システム、ブロックチェーン管理方法及びブロックチェーン管理プログラムを提供することを目的とする。
【課題を解決するための手段】
【０００６】
本発明に係るブロックチェーン管理システムは、複数のノードからなるグループがそれぞれ、互いに異なるブロックチェーンに属し、各ノードは、自ノードが属するブロックチェーンのブロックを生成する際に、当該ブロックに対するコンセンサスへの参加者として、当該ブロックチェーンに属するノードに加えて、他のブロックチェーンに属する複数のノードをランダムに選択する選択部を備える。
【０００７】
前記選択部は、自ノードが属するブロックチェーンにおいて直前に生成されたブロックのハッシュ値の少なくとも一部を入力とした選択関数により、前記他のブロックチェーンに属する複数のノードを選択してもよい。
【０００８】
前記選択関数は、暗号学的ハッシュ関数であり、前記選択部は、前記ハッシュ関数の出力から所定のビット長のＩＤを複数抽出し、当該ＩＤに対応する、前記他のブロックチェーンに属する複数のノードを選択してもよい。
【０００９】
前記選択部は、前記直前に生成したブロックに所定の初期ベクトルを連結した値を前記ハッシュ関数に入力してもよい。
【００１０】
前記選択部は、前記コンセンサスが不成立の場合、前記初期ベクトルを更新してもよい。
【００１１】
前記選択部は、自ノードが属するブロックチェーンのノードの数に応じて、選択する前記他のブロックチェーンに属する複数のノードの数を決定してもよい。
【００１２】
本発明に係るブロックチェーン管理方法は、複数のノードからなるグループがそれぞれ、互いに異なるブロックチェーンに属し、各ノードは、自ノードが属するブロックチェーンのブロックを生成する際に、当該ブロックに対するコンセンサスへの参加者として、当該ブロックチェーンに属するノードに加えて、他のブロックチェーンに属する複数のノードをランダムに選択する。
【００１３】
本発明に係るブロックチェーン管理プログラムは、複数のノードからなるグループがそれぞれ、互いに異なるブロックチェーンに属し、各ノードに、自ノードが属するブロックチェーンのブロックを生成する際に、当該ブロックに対するコンセンサスへの参加者として、当該ブロックチェーンに属するノードに加えて、他のブロックチェーンに属する複数のノードをランダムに選択させるためのものである。
【発明の効果】
【００１４】
本発明によれば、複数のブロックチェーンそれぞれの信頼性が向上する。
【図面の簡単な説明】
【００１５】
【図１】実施形態に係るブロックチェーン管理システムの機能構成を示す図である。
【図２】実施形態に係るブロックの構成を示す図である。
【図３】実施形態に係るコンセンサスの処理に参加するノードを例示する図である。
【発明を実施するための形態】
【００１６】
以下、本発明の実施形態の一例について説明する。
図１は、本実施形態に係るブロックチェーン管理システム１において、管理対象である複数のブロックチェーンのそれぞれに属するノード１０（情報処理装置、又は情報処理装置群）の機能構成を示す図である。
ブロックチェーンのそれぞれを管理する各組織に配置された複数のノード１０からなるグループは、それぞれが互いに異なるブロックチェーンに属する。
ノード１０は、選択部１１と、生成部１２とを備える。
【００１７】
選択部１１は、自ノードが属するブロックチェーンＡに格納するブロックを生成する際に、このブロックに対するコンセンサスへの参加者として、ブロックチェーンＡに属するノード１０に加えて、他のブロックチェーンＢ、・・・に属する複数のノード１０をランダムに選択する。
このとき、選択部１１は、自ノード１０が属するブロックチェーンＡにおいて直前に生成されたブロックのハッシュ値の少なくとも一部を入力とした選択関数により、他のブロックチェーンＢ、・・・に属する複数のノード１０を選択する。
【００１８】
選択関数は、暗号学的ハッシュ関数であってよい。
具体的には、選択部１１は、例えばハッシュ関数の出力から所定のビット長のＩＤを複数抽出し、これらのＩＤに対応する複数のノード１０を選択する。
【００１９】
例えば、ハッシュ関数の出力が０００１０１０１１の場合、この出力を３分割し（０００／１０１／０１１）、それぞれを整数に変換すると、３つのＩＤ（０、５、３）が得られる。なお、ＩＤは、自ノード１０が属するブロックチェーンＡのノード１０が選択されないように、他のブロックチェーンＢ、・・・のノード１０に予め割り振られる。
【００２０】
ＩＤの抽出方法はこれに限られない。例えば、抽出されたＩＤを、ブロックチェーンを選択するＩＤとブロックチェーン内のノード１０を選択するＩＤとに、さらに分割してもよい。また、例えば、ブロックチェーン間での偏りを避けるために、全てのブロックチェーンを順番に選択しつつ、ブロックチェーン内のノード１０をＩＤによりランダムに選択してもよい。
【００２１】
このとき、選択部１１は、直前に生成されたブロックに所定の初期ベクトルを連結した値をハッシュ関数に入力する。
また、選択部１１は、コンセンサスが不成立の場合、初期ベクトルをインクリメントする等して更新することで、同一のノード１０群が抽出されないようにする。
【００２２】
なお、選択部１１は、自ノード１０が属するブロックチェーンＡのノード１０の数に応じて、選択する複数のノード１０の数を決定してもよく、例えば、コンセンサスへの自ノード１０が属するブロックチェーンＡから参加する数と他のブロックチェーンＢ、・・・から参加する数との比率を同程度に、あるいは、全参加者の数を一定数に調整してもよい。
【００２３】
生成部１２は、１又は複数のトランザクションデータを記録したブロックを生成し、ブロックチェーンに格納する。
このとき、生成部１２は、自ノード１０が属するブロックチェーンＡのノード１０と、選択部１１により選択されたノード１０とが参加するコンセンサスの処理を実行する。コンセンサスが成立した場合に限り、生成したブロックがブロックチェーンＡに格納され、このブロックは、ブロックチェーンＡに属するノード１０に配信され共有される。
【００２４】
コンセンサスの処理は、例えば、ＰＢＦＴ（Ｐｒａｃｔｉｃａｌ  Ｂｙｚａｎｔｉｎｅ  Ｆａｕｌｔ  Ｔｏｌｅｒａｎｃｅ）等、多数決に基づくプロトコルが採用されてよい。
なお、選択されたコンセンサスの参加者は、同意するか否かの意思表示を行うが、参加を拒否したノード１０については、例えば、自動的に不同意であるとみなしてもよい。
【００２５】
図２は、本実施形態に係るブロックチェーンに格納されるブロックの構成を示す図である。
ブロックチェーンの各ブロックに記録される複数のトランザクションデータは、例えばマークルハッシュツリー等の木構造により管理され、この木構造のルートハッシュがブロックに収納される。
また、ブロックには、直前のブロックのハッシュ値と、選択関数の入力に用いられた初期ベクトルとが収納され、これらを合わせて例えば代表者等の電子署名が付与される。
【００２６】
図３は、本実施形態に係るコンセンサスの処理に参加するノード１０を例示する図である。
この例では、５つのブロックチェーンＡ〜Ｅがそれぞれ異なるグループによりローカルに管理されており、ブロックチェーンＡでコンセンサスの処理が実行される場合を示している。
【００２７】
ここで、ブロックチェーンＡに属する複数のノード１０には、正常なノード１０と攻撃者である不正なノード１０とが含まれるとする。各ブロックチェーンは、規模が小さいほど、少数の攻撃者による結託攻撃を受けるリスクが高まる。例えば、ブロックチェーンＡでは、全体の１／２が攻撃者となり、正当なコンセンサスの処理が成立しなくなる。
【００２８】
そこで、ブロックチェーンＡにおいてコンセンサスの処理が実行される場合、参加者は、ブロックチェーンＡのノード１０に加えて、ブロックチェーンＢ〜Ｅからも選択される。これにより、参加者の母集団が大きくなるため、参加者に含まれる不正なノード１０の割合が低く抑えられる。
【００２９】
また、外部のブロックチェーン（例えば、ブロックチェーンＤ）からコンセンサスの参加者として不正なノード１０を送り込もうとしても、外部のノード１０はランダムに選択されるため、攻撃者は、複数のブロックチェーンに渡って多数の結託者を配置しなければならず、攻撃は困難となる。例えば、ブロックチェーンＤに不正なノード１０が多数存在したとしても、これらが選択されるとは限らず、さらに、他のブロックチェーンＢ、Ｃ、Ｅからもノード１０が選択されるため、結果として、コンセンサスの参加者全体のうち攻撃者の割合は低く抑えられる。
【００３０】
本実施形態によれば、ブロックチェーン管理システム１は、複数のブロックチェーンを複数の異なるグループにより分散して構成する。各ブロックチェーンにおいてブロックを生成する際には、コンセンサスへの参加者として、ブロックを格納するブロックチェーンに属するノード１０に加えて、他のブロックチェーンに属する複数のノード１０がランダムに選択される。
【００３１】
したがって、ブロックチェーン管理システム１は、複数のブロックチェーンのそれぞれでコンセンサスの処理を行う際に、他のブロックチェーンに属するノード１０を参加者として追加し、母集団を大きくすることで、結託攻撃に対する耐性を高められる。これにより、ブロックチェーン管理システムは、複数のブロックチェーンそれぞれの信頼性を向上できる。
特に、効率性又は利便性を重視してローカルのブロックチェーンの規模が小さくなると、従来は、このブロックチェーンに属するノード１０の数が少ないために、結託攻撃のリスクが高まり信頼性が低下していた。本実施形態のブロックチェーン管理システム１は、コンセンサスに参加するノード１０の数を増やすことができるため、ブロックチェーンの規模によらず、信頼性を向上できる。
【００３２】
また、ブロックチェーン管理システム１は、コンセンサスへの参加者を追加するのみで、採用しているコンセンサスの手法を変更することがないため、既存のプラットフォームを改変せず、容易に実現できる。
【００３３】
ブロックチェーン管理システム１において、各ノード１０は、自身が属するブロックチェーンにおいて直前に生成されたブロックのハッシュ値の少なくとも一部を入力とした選択関数により、他のブロックチェーンに属するノード１０を選択してコンセンサスに参加させる。
したがって、選択されるノード１０は、直前のブロックから一意に決まるので、事後にプロセスの正当性を検証することができる。
【００３４】
ブロックチェーン管理システム１は、選択関数として暗号学的ハッシュ関数を用いて、このハッシュ関数の出力から所定のビット長のＩＤを複数抽出することで、ＩＤに対応する複数のノード１０を容易に選択できる。
【００３５】
ブロックチェーン管理システム１は、直前に生成したブロックに所定の初期ベクトルを連結した値をハッシュ関数に入力することもできる。ブロックチェーン管理システム１は、用途別の初期ベクトルを用意することにより、本実施形態に専用の選択処理を、検証可能かつ容易に実現できる。
また、ブロックチェーン管理システム１は、コンセンサスが不成立の場合、初期ベクトルを更新することで、同一のノード１０群が再度選択される事態を回避できる。
【００３６】
ブロックチェーン管理システム１は、ブロックチェーンに属するノード１０の数に応じて、他のブロックチェーンから選択する複数のノード１０の数を決定することにより、ブロックチェーンの規模によらず、適切な数の参加者によりコンセンサスを実施できる。
【００３７】
以上、本発明の実施形態について説明したが、本発明は前述した実施形態に限るものではない。また、前述した実施形態に記載された効果は、本発明から生じる最も好適な効果を列挙したに過ぎず、本発明による効果は、実施形態に記載されたものに限定されるものではない。
【００３８】
ブロックチェーン管理システム１によるブロックチェーン管理方法は、ソフトウェアにより実現される。ソフトウェアによって実現される場合には、このソフトウェアを構成するプログラムが、情報処理装置（コンピュータ）にインストールされる。また、これらのプログラムは、ＣＤ−ＲＯＭのようなリムーバブルメディアに記録されてユーザに配布されてもよいし、ネットワークを介してユーザのコンピュータにダウンロードされることにより配布されてもよい。さらに、これらのプログラムは、ダウンロードされることなくネットワークを介したＷｅｂサービスとしてユーザのコンピュータに提供されてもよい。
【符号の説明】
【００３９】
１  ブロックチェーン管理システム
１０  ノード
１１  選択部
１２  生成部
【図１】
2020061696.tif 000003
【図２】
2020061696.tif 000004
【図３】
2020061696.tif 000005