JP7003995B2

JP7003995B2 - ブロックチェーン管理装置、ブロックチェーン管理方法及びプログラム

Info

Publication number: JP7003995B2
Application number: JP2019537467A
Authority: JP
Inventors: 諒古川
Original assignee: NEC Corp
Current assignee: NEC Corp
Priority date: 2017-08-22
Filing date: 2017-08-22
Publication date: 2022-01-21
Anticipated expiration: 2037-08-22
Also published as: US20200356547A1; JPWO2019038839A1; WO2019038839A1; US11314727B2

Description

本発明は、ブロックチェーン管理装置、ブロックチェーン管理方法及びプログラムに関し、ネットワークに参加する複数のノード間で共通の台帳を管理するブロックチェーン管理装置、ブロックチェーン管理方法及びプログラムに関する。

近年、ビットコイン（非特許文献１を参照）を代表として、中央管理サーバーを必要とせず誰もが参加可能なピアツーピア（ＰｅｅｒｔｏＰｅｅｒ：Ｐ２Ｐ）ネットワークで、ネットワークに参加するすべてのノード間で共通の台帳を管理することが可能なブロックチェーンの普及が拡大している。

ビットコインに代表されるブロックチェーンは、複数のブロックチェーン管理ノード（ブロックチェーン管理装置）が相互接続されたシステムである。ブロックチェーン管理ノードは、台帳格納手段と、トランザクション検証手段と合意形成手段とを備える。台帳格納手段は、ブロックチェーン上に蓄積する履歴情報（以下、「トランザクション」と呼ぶ）を発行するトランザクション発行者から発行されたトランザクションを蓄積する。トランザクション検証手段は、トランザクションを検証する。合意形成手段は、ブロックチェーン管理ノード間で蓄積するトランザクションの内容を同一にする処理（「合意形成」という。「マイニング」とも呼ばれる。）を行う。台帳格納手段に蓄積されるトランザクションはデータ構造として一つまたは複数のトランザクションを集約した単位をブロックとし、当該ブロックの中に少なくとも前のブロックのハッシュ値を含むブロックヘッダを含むという特徴を持つ。このように蓄積されたブロックの集合を台帳と呼ぶ。

そして、ブロックチェーンは概略以下のように動作する。各ブロックチェーン管理ノードは一人または複数のトランザクション発行者から発行された一つまたは複数のトランザクション情報を受信する。トランザクション検証手段は、受信した一つまたは複数のトランザクション情報の検証を行い、検証を通過した少なくとも一つ以上のトランザクションを集約してブロックを作成する。各ブロックチェーン管理ノードでブロックの内容は異なりうる。このため、合意形成手段が、ブロックチェーン管理ノード間で蓄積するブロックの内容を同一にする。合意形成手段により各ブロックチェーン管理ノードで同一となったブロックが台帳格納手段に格納される。

また、ブロックチェーン管理ノードにはトランザクションを受け取り、ブロックを正しく生成・蓄積していくことにインセンティブがあるように設計される。例えば、ビットコインでは、ブロックを生成することで、ブロックチェーン管理ノードが仮想通貨を得ることができる。このため、多くのブロックチェーン管理ノードは正しくブロックの検証・生成を行うようにふるまう。

このような構成及び動作により、ブロックチェーン管理ノードとして悪意のあるノードが参加した場合でも改ざんが困難かつ、各ブロックチェーン管理ノードで台帳の内容が同一となり、トランザクションが同一の順序で蓄積されていく。

また、ブロックチェーンは上述した構成及び動作をするブロックチェーン管理ノードが複数存在し、すべてのデータを複製して管理することから、データが改ざんされないことに加えて、データの消失が起こらないことも期待されている。このようなブロックチェーンの性質を利用して、トランザクションの形でデータを登録してブロックチェーンをデータベースシステムとして利用するようなサービスが出現している。

特許文献１には、記した合意形成（マイニング）に必要な端末の処理能力及び記憶容量を低減することができるという仮想通貨管理プログラム及び仮想通貨管理方法が開示されている。

特開２０１６－２１８６３３号公報

ＳａｔｏｓｈｉＮａｋａｍｏｔｏ， "Ｂｉｔｃｏｉｎ：ＡＰｅｅｒ－ｔｏ－ＰｅｅｒＥｌｅｃｔｒｏｎｉｃＣａｓｈＳｙｓｔｅｍ"，２００８

以下の分析は、本発明によって与えられたものである。上記した典型的なブロックチェーンの枠組みにおいて、ブロックチェーン管理ノードが個々のトランザクションを保持するモチベーションは、インセンティブを得るために、新たなブロックを生成したりトランザクションやブロックを検証するためにあり、そのような処理に必要の無い余分なデータを保持するモチベーションは低くなる傾向にある。以下、この点について検討する。

ビットコインに代表される既存のブロックチェーン技術は、ブロック全体に対するハッシュ値を取るのではなく、ブロックヘッダに対してのみハッシュ値を取り次のブロックへ含める。ブロックヘッダには主に直前のブロックのハッシュ値、ブロックに含められたすべてのトランザクションを基に生成されたハッシュ値などが含まれる。この場合、ブロックヘッダのハッシュ値の検証には個々のトランザクションの詳細な情報は必要ない。

また、古くなったトランザクションは、新しいブロック及びトランザクションを検証する際に必要ないのであれば保持する必要はない。たとえば、ビットコインではトランザクションは、複数の使用するコインを指定するインプット情報とトランザクションによって生成される複数の新しいコインを表すアウトプット情報を含んでおり、新しいトランザクションを検証する際に必要なトランザクションは、アウトプット情報に含まれるコインに未使用なものが残っているトランザクションのみであり、トランザクションに含まれるすべてのコインが使用済みである場合には二度と検証時に参照されない。この点、特許文献１の段落０００５には、「マイニングに用いる端末には、取引の履歴すべてを自端末に保存しておく必要がある」との記載があるが、上記ビットコインに代表されるブロックチェーン技術ではそのような必要は無くなっている。

つまり、既存のブロックチェーンではブロックヘッダのハッシュの検証及び新しいブロックの検証に必要の無いトランザクションが存在するにも拘わらず、それらのトランザクションを保持し続けるモチベーションがブロックチェーン管理ノードにないため、一部のトランザクションが失われる可能性がある。ビットコインでは実際に不必要なトランザクションを捨てて台帳の容量を削減できるモードが実装されている。

このため、ブロックチェーン上にトランザクションの形でデータを登録してデータベースシステムとして利用するサービスは、データが消失してサービスの提供が困難になる可能性がある。

このように、背景技術に記載したブロックチェーンでは、ブロックチェーン管理ノードが台帳に含まれるトランザクションを永続的に保持するモチベーションが低いため、トランザクションの形で台帳に含まれる重要なデータが消失する可能性があるという問題点がある。これは、ブロックチェーンをデータベースシステムとして利用するサービスにとって特に問題となりうる。

本発明は、ブロックチェーン管理ノードにおいてトランザクションの形で台帳に含まれる重要なデータの消失可能性を低減させることのできるブロックチェーン管理装置、ブロックチェーン管理方法及びプログラムを提供することを目的とする。

第１の視点によれば、ブロックチェーン管理装置間で取り決めた所定のルールに基づいて台帳の所定の範囲の中から選択した参照情報の要約値を少なくとも一つ含むブロックヘッダを含むブロックを受信するブロック受信部を備えるブロックチェーン管理装置が提供される。このブロックチェーン管理装置は、さらに、前記所定のルールに基づいて前記台帳の所定の範囲の中から参照情報を選択し、前記ブロックに含まれる参照情報の要約値が前記参照情報に基づいて生成されているか否かにより、ブロックが正しく生成されたことを検証するブロック検証部を備える。このブロックチェーン管理装置は、さらに、前記ブロック検証部により前記ブロックが正しく生成されたと検証された場合に、他のブロックチェーン管理装置と当該ブロックを書き込むことに対して合意形成を行う合意形成部を備える。このブロックチェーン管理装置は、前記合意形成された前記ブロックを格納する台帳格納部と、を備える。

第２の視点によれば、台帳の所定の範囲の中から所定のルールに基づいて選択した参照情報の要約値を少なくとも一つ含むブロックヘッダを含むブロックを受信するステップと、前記台帳の所定の範囲の中から所定のルールに基づいて参照情報を選択し、前記ブロックに含まれる参照情報の要約値が前記参照情報に基づいて生成されているか否かにより、ブロックが正しく生成されたことを検証するステップと、前記検証により前記ブロックが正しく生成されたと検証された場合に、他のブロックチェーン管理装置と当該ブロックを書き込むことに対して合意形成を行うステップと、前記合意形成された前記ブロックを格納するステップと、を含むブロックチェーン管理方法が提供される。本方法は、他のブロックチェーン管理装置と連携して共通の台帳を管理するブロックチェーン管理装置という、特定の機械に結びつけられている。

第３の視点によれば、上記したブロックチェーン管理装置の機能を実現するためのコンピュータプログラムが提供される。なお、このプログラムは、コンピュータが読み取り可能な（非トランジエントな）記憶媒体に記録することができる。即ち、本発明は、コンピュータプログラム製品として具現することも可能である。

本発明によれば、ブロックチェーン管理ノードにおいてトランザクションの形で台帳に含まれる重要なデータの消失可能性を低減させることが可能となる。

本発明の一実施形態の構成を示す図である。本発明の第１の実施形態の全体構成を示す図である。本発明の第１の実施形態のブロックチェーン管理装置の構成を示す機能ブロック図である。本発明の第１の実施形態のブロックチェーン管理装置が作成するブロックの一例を示す図である。本発明の第１の実施形態のブロックチェーン管理装置の動作を表したフローチャートである。本発明の第１の実施形態のブロックチェーン管理装置の台帳格納部に保持される台帳データの一例を示す図である。本発明の第１の実施形態のブロックチェーン管理装置の動作（ブロック検証）を表したフローチャートである。本発明の第１の実施形態のブロックチェーン管理装置の動作（合意形成）を表したフローチャートである。本発明の第２の実施形態のブロックチェーン管理装置の構成を示す機能ブロック図である。本発明の第２の実施形態の典型的な動作を示す図である。

はじめに本発明の一実施形態の概要について図面を参照して説明する。なお、この概要に付記した図面参照符号は、理解を助けるための一例として各要素に便宜上付記したものであり、本発明を図示の態様に限定することを意図するものではない。また、以降の説明で参照する図面等のブロック間の接続線は、双方向及び単方向の双方を含む。一方向矢印については、主たる信号（データ）の流れを模式的に示すものであり、双方向性を排除するものではない。

本発明は、その一実施形態において、図１に示すように、ブロック受信部１０１と、ブロック検証部１０２と、合意形成部１０３と、台帳格納部１０４と、を備えるブロックチェーン管理装置１００Ａと、同等の機能を持つブロックチェーン管理装置１００Ｂをピアツーピア接続した構成にて実現できる。

より具体的には、ブロック受信部１０１は、他のブロックチェーン管理装置から、ブロックチェーン管理装置間で取り決めた所定のルールに基づいて台帳の所定の範囲の中から選択した参照情報の要約値を少なくとも一つ含むブロックヘッダを含むブロックを受信する。ブロック検証部１０２は、前記所定のルールに基づいて前記台帳の所定の範囲の中から参照情報を選択し、前記ブロックに含まれる参照情報の要約値が前記参照情報に基づいて生成されているか否かにより、受信したブロックが正しく生成されたことを検証する。合意形成部１０３は、前記ブロック検証部１０２により前記ブロックが正しく生成されたと検証された場合に、他のブロックチェーン管理装置と当該ブロックを書き込むことに対して合意形成を行う。台帳格納部１０４は、前記合意形成された前記ブロックを格納する。

上記した構成によれば、ブロックチェーン管理ノードにおけるトランザクションを保持することに対するインセンティブが付与され、なるべく多くのトランザクションがブロックチェーン管理ノードによって保持されるようになる。

その理由は以下のように分析できる。上記したブロックチェーン管理装置（例えば、ブロックチェーン管理装置１００Ａ）のブロック検証部１０２は、台帳の部分的情報である参照情報を知らなければ生成できない参照情報の要約値がブロックに含まれる場合に、ブロックが正しいと判断する。このため、あるブロックチェーン管理装置１００Ｂが、ブロックを生成するためには台帳の任意の部分的情報にアクセスする必要がある。一方で、ブロック生成によるインセンティブを最大化するためにはブロックを生成できるノードが少ない方が良い。これらのことから、ブロックを生成するに足りる台帳情報を持たないブロックチェーン管理装置が、他のブロックチェーン管理装置から参照情報を取得することは困難であり、それぞれのブロックチェーン管理装置は、台帳上のなるべく多くの情報を保持するようになる。結果として、より多くのトランザクションが保持されるようになる。

［第１の実施形態］
続いて、本発明の第１の実施形態について図面を参照して詳細に説明する。図２は、本発明の第１の実施形態の構成を示す図である。図２を参照すると、４台のブロックチェーン管理装置（ブロックチェーン管理ノード）１００が相互に接続された構成が示されている。これらのブロックチェーン管理装置１００がトランザクション発行者から受け取ったトランザクションを検証する。そして、検証を通過したトランザクションを集約してブロックを作成する。ブロックを作成したブロックチェーン管理装置１００は、他のブロックチェーン管理装置１００に作成したブロックを配布する。それぞれのブロックチェーン管理装置１００がその正当性を検証した上で台帳にブロックの内容を追加する。なお、上記の過程で、ブロックチェーン管理装置１００がブロックの作成主体となりうるため、内容の異なるブロックが作成されることがある。また、悪意を持ったブロックチェーン管理装置１００が存在する場合、不正なブロックが生成、配布される可能性もある。その場合、合意形成という手続を行って、ブロックチェーン管理ノード１００間で蓄積するブロックの内容を同一にする。これにより、台帳の一貫性が保たれる。なお、図２の例では、４台のブロックチェーン管理装置を示しているが、ブロックチェーン管理装置の数は複数あればよく、図２の構成に限られない。

続いて、ブロックチェーン管理装置１００の構成について図面を参照して詳細に説明する。図３は、本発明の第１の実施形態のブロックチェーン管理装置の構成を示す機能ブロック図である。図３を参照すると、ブロック受信部１１０と、ブロック検証部１２０と、合意形成部１３０と、台帳格納部１４０と、を含むブロックチェーン管理装置１００が示されている。

ブロック受信部１１０は、ブロックチェーンのネットワークに送信されたブロックＢを受信する。このブロックＢは、図４に示すように、一つまたは複数のトランザクションに、ブロックヘッダＢＨを付加して構成される。さらに、このブロックヘッダＢＨは、直前のブロックに含まれるブロックヘッダを要約したブロックヘッダ要約値（図４のＨａｓｈ）と、特定のルールによって指定された台帳の部分的情報である参照情報に基づいて生成された少なくとも一つの参照情報の要約値（以下「参照情報要約値」）を含む。なお、参照情報は、台帳の複数の部分である場合も含まれる。この場合、参照情報は複数となり、参照情報要約値は、これら複数の参照情報から１つ、又は、複数生成される。

ブロック検証部１２０は、参照情報検証部１２１と、参照情報決定部１２２とを備え、受信したブロックが正しく生成されていることを検証する。具体的には、参照情報決定部１２２は、決定的なルール（所定のルール）を用いて、台帳の一部またはすべての情報に基づいた台帳の部分的情報である参照情報を決定する。参照情報検証部１２１は、参照情報要約値が前記参照情報に基づいて生成されていることを検証する。ここで、決定的なルールとは、すべてのブロックチェーン管理装置１００が、台帳の情報から、同一の部分的情報である参照情報を特定できるようなルールを意味する。

合意形成部１３０は、他のブロックチェーン管理装置との間で、前記受信したブロックが前記ブロック検証部１２０で正しく生成されたと判断された場合に、蓄積するかどうかについて合意する合意形成手順を実施する。

台帳格納部１４０は、前記合意形成部１３０によって合意されたすべてのブロックの集合である台帳の一部またはすべてを格納する。

次に、ブロックチェーン管理装置１００の動作について図面を参照して詳細に説明する。はじめに、図５を参照してブロックチェーン管理装置１００が受信したブロックを検証し、台帳格納部１４０に格納するまでの一連の動作について説明する。

ブロック受信部１１０が、他のブロックチェーン管理装置１００等からブロックを受信する（ステップＡ１）。ここでは、図４に示すブロックＢを受信したとする。図４に示したとおり、このブロックＢは、トランザクションの集合であるボディに、直前のブロックのブロックヘッダを要約したブロックヘッダ要約値（Ｈａｓｈ）と、合意形成部１３０で使用されるＮｏｎｃｅと呼ばれる値と、参照情報要約値を含んだブロックヘッダを付加した構成となっている。

次に、ブロック検証部１２０が前記受信したブロックＢに対して検証を行う（ステップＡ２）。ここでの検証の内容については、後に、図７のフローチャートを用いて説明する。

前記検証の結果、前記ブロックが正しく生成されていないと判定された場合（ステップＡ３のＮｏ）、ブロックチェーン管理装置１００はブロックを廃棄する（ステップＡ４）。

一方、ブロックが正しく生成されたと判定した場合（ステップＡ３のＹｅｓ）、合意形成部１３０が、他のブロックチェーン管理装置１００と合意形成を行う（ステップＡ５）。この合意形成の仕方については、後に、図８のフローチャートを用いて説明する。

最後に、ブロックチェーン管理装置１００は、他のブロックチェーン管理装置１００と合意形成できたブロックを台帳格納部１４０に格納する。図６は、台帳格納部１４０に保持される台帳データの一例を示す図である。図６の例では、合意形成の結果、ブロックの高さ５０１のブロックが追加された状態を示している。なお、台帳格納部１４０における台帳の格納態様は、図６に示した例に限られず、種々の変更を加えることが可能である。例えば、図６の例では、ブロックの高さとブロック本体とを対応付けた構成としているが、この形態に限られるものではない。

続いて、図７のフローチャートを用いて、上記図５のステップＡ２におけるブロック検証部１２０によるブロックの検証処理について詳細に説明する。以下では、ブロックチェーン管理装置１００が、図４に示すブロックを受信したものとして説明する。

検証対象となるブロックが入力されると、まず、ブロック検証部１２０の参照情報決定部１２２が、決定的なルールに従い、台帳の中の部分的な情報を識別できる識別子を少なくとも一つ生成して、参照情報として指定する（ステップＢ１）。

前記参照情報の識別子には、例えば、ブロックの高さなどを用いることができる。参照情報を指定するルール（決定的なルール）は、たとえば、次のものを用いることができる。
・直前のブロックの一部（Ｎｏｎｃｅの値や直前のブロックのハッシュ値など）に対してＳＨＡ－２５６等のハッシュ関数を用いて１６進数の数値を作成する。
・この数値の一部分（下数桁など）に対して、最新のブロックの高さで剰余演算して得られた値に１を加える。
以上のようなルールを用いることで、どの高さのブロックを参照情報として指定するかを１～現在のブロック高さの間で決定することができる。

例えば、図６に示した台帳の中で直前のブロックである高さが５００のブロックに含まれる直前のブロックのハッシュ値（つまり高さ４９９のブロックヘッダのハッシュ値）についてＳＨＡ－２５６ハッシュ関数でハッシュ値を取る。ここで、ハッシュ値として‘9a796cbfa5cc884d7f3e7ddf6c743dfeb9a78e876766d3243e893e4ded4e638d’という値が得られたものとする。その下１６ケタの１６進数‘3e893e4ded4e638d’に対して現在のブロック高さである５００で剰余を取って＋１することで参照するブロックは‘２９４’となる。

なお、参照情報の識別子及びその決定方法はこの限りではない。例えば、たとえば参照情報の識別子は、ブロックの高さと、ブロック内のトランザクションを識別する番号といった複数の情報で構成されてもよい。また、これらの複数の情報で構成される識別子を直前のブロックの複数の部分的情報から取得してもよいし、直近の複数のブロックなどからそれぞれ生成することでもよい。また、参照情報の識別子が複数存在し、複数の参照情報を指定してもよい。

このように参照情報を選択するための識別子は、台帳のデータをより多くより長期に保持することにインセンティブが働くものであればよく、台帳の中から参照情報を識別できる情報でよければその形態を問わない。また、参照情報の識別子は決定的なルールであり、ある程度一様に台帳の部分的情報が選択されるのであれば、その決定方法は問わない。

次に、参照情報検証部１２１は、台帳から前記参照情報決定部１２２により決定された一つまたは複数の参照情報の識別子に基づいて、一つまたは複数の参照情報を取得する（ステップＢ２）。ここでは、図６に示す台帳からブロックの高さ２９４のブロックが参照情報として取得されたものとする。

次に、参照情報検証部１２１は、前記受信したブロックに含まれる少なくとも一つの参照情報要約値が、前記参照情報に基づいて生成されたものであることを検証し、検証結果の正否を返す（ステップＢ３）。ここでは、ステップＢ２で図６に示す高さ２９４のブロックである参照情報に対するＳＨＡ－２５６などのハッシュ関数で計算されるハッシュ値が図４のブロックに含まれる参照情報要約値と一致するかどうかで検証を行う。参照情報である高さ２９４のブロックのハッシュ値が‘678e82d907d3e6e71f81D5cf3ddacc3671dc618c38a1b7a9f9393a83d025b296’であった場合、図４のブロックに含まれる参照情報要約値 ‘678e82d907d3e6e71f81D5cf3ddacc3671dc618c38a1b7a9f9393a83d025b296’と一致したと判定される。

なお、複数の参照情報があった場合に、それを連結して一つの参照情報要約値を検証してもよいし、複数の参照情報要約値をそれぞれ対応する参照情報で検証してもよい。また検証の方法は上記の方法に限定せず、参照情報要約値が参照情報から生成されたものであると検証できればよい。

続いて、図８のフローチャートを用いて、上記図５のステップＡ５における合意形成部１３０による合意形成処理について詳細に説明する。なお、以下の説明では、一例としてビットコインで採用されているＰｒｏｏｆｏｆＷｏｒｋと呼ばれる仕組みによる合意形成について説明するが、他の合意形成方法でもよく、合意形成の方法については問わない。

図８を参照すると、まず、合意形成部１３０は、ブロックのハッシュ値を取得する（ステップＣ１）。ハッシュ値はブロック全体に対して取るのでもよいし、ブロックの特徴を要約した値について取るのでもよい。ここでは、図４に示すブロックのハッシュ値として、１６進数で “0000000000000000000000000000000000000000000000002bcad85e7b40d3a4”という値が得られたものとして説明する。

最後に、合意形成部１３０は、ブロックのハッシュ値が目標値より小さいかどうかを判定し、ブロックのハッシュ値が小さい場合に合意形成ができたと判定とする（ステップＣ２）。ここで、目標値は事前にシステムに固有の値が決定されているのでもよいし、以前のブロックを参照して計算して生成されるのでもよい。ここで、図４に示されたブロックに対する目標値が、“0000000000000000000000000000000000000000000000010000000000000000”であった場合、前述した図４のブロックのハッシュ値＜当該目標値となるため、合意形成ができたと判定される。

このような合意形成の方法はＰｒｏｏｆｏｆＷｏｒｋと呼ばれ、ブロックを生成する際に、図４のブロックに示すようなＮｏｎｃｅと呼ばれる値を変化させ、ブロックのハッシュ値が目標値より小さくなるようにブロックを生成する。ハッシュ値からＮｏｎｃｅを逆算することはできないことから、ブロックチェーン管理装置１００は、総当たりでＮｏｎｃｅを試す必要がある。このため、ブロックの生成には、ある程度の計算コストと時間を所要する。ブロックの生成にかかる時間は目標値によってコントロールでき、たとえばビットコインでは直近のいくつかのブロックの生成間隔から、今後もブロックの生成にかかる時間が１０分程度になるように調整される。ＰｒｏｏｆｏｆＷｏｒｋを用いる合意形成手段１３０は、計算コストを掛けて生成されたブロックかどうかを、ブロックのハッシュ値によって検証できる。ブロックチェーンのネットワークに参加している大部分のブロックチェーン管理装置１００が同じルールに従ってブロックのハッシュ値を検証し、検証を通過したブロックのみを台帳格納手段１４０に格納するブロックとすることで、ネットワーク全体では合意を形成することができる。

以上説明したように、本実施形態のブロックチェーン管理装置１００によれば、トランザクションを保持することに対するインセンティブが働くようにすることができ、より多くのトランザクションがブロックチェーン管理装置１００に保持されるようになる。

その理由は、ブロック検証部１２０におけるブロック検証の際に、より多くのトランザクションを保持しているノードがインセンティブを得られるように構成したことにある。具体的には、ブロック検証部１２０の参照情報検証部１２１はブロックに含まれる参照情報の要約値が、決定的なルールで決定される台帳の部分的情報である参照情報から生成されたものであると検証された場合にのみブロックが正しいと判断する。そして、合意形成部１３０は、他のブロックチェーン管理装置１００と合意形成を行い、合意形成されたブロックが台帳格納部１４０に格納されることになる。このため、ブロックチェーン管理装置１００が台帳に登録されるブロックを生成するためには台帳の任意の部分的情報にアクセスする必要がある。ブロック生成によるインセンティブを最大化するためにはブロックを生成できるノードが少ない方が良いことから、他のノードから参照情報を取得することは困難であり、それぞれのブロックチェーン管理装置１００が台帳上のより多くの望ましくは全部の情報を保持する必要がある。このため、すべてのトランザクションがより多く、より長期に保持されることになる。

［第２の実施形態］
上記した実施形態では、ブロックチェーン管理装置１００がトランザクション発行者からトランザクションを受け取ってブロックを生成する仕組みについては省略したが、ブロックチェーン管理装置１００がこれらの機能を備えていてもよい。例えば、図９のように、ブロックチェーン管理装置１００Ｃが、トランザクション受信部１５０と、ブロック生成部１６０と備えていてもよい（第２の実施形態）。

トランザクション受信部１５０は、トランザクション発行者または他のブロックチェーン管理装置１００からトランザクションを受信する（図１０の（１）参照）。そして、ブロック生成部１６０は、台帳格納部１４０に格納された直前のブロックのハッシュ値と参照情報決定部１２２によって決定された参照情報を要約した参照情報要約値と受信したトランザクションを一つ以上まとめてブロックを生成し、他のブロックチェーン管理装置１００に配布する（図１０の（２））。そして、このブロック生成部１６０が生成するブロックは、前述したＰｒｏｏｆｏｆＷｏｒｋで合意形成をするために、一定の条件を満たすブロック（即ち、決定的ルールを用いて選択された参照情報の要約値を含むブロック）であることが望ましい。

以上のように、本発明は、トランザクションを受け取ってブロックを生成する機能を備えているブロックチェーン管理装置１００にも適用可能である。

以上、本発明の各実施形態を説明したが、本発明は、上記した実施形態に限定されるものではなく、本発明の基本的技術的思想を逸脱しない範囲で、更なる変形・置換・調整を加えることができる。例えば、各図面に示したネットワーク構成、各要素の構成、台帳、ブロック等の表現形態は、本発明の理解を助けるための一例であり、これらの図面に示した構成に限定されるものではない。

例えば、図１、３、９に示したブロックチェーン管理装置の各部（処理手段）は、ブロックチェーン管理装置に搭載されたプロセッサに、そのハードウェアを用いて、上記した各処理を実行させるコンピュータプログラムにより実現することもできる。

最後に、本発明の好ましい形態を要約する。
［第１の形態］
（上記第１の視点によるブロックチェーン管理装置参照）
［第２の形態］
上記した所定のルールとして、
一つまたは複数の直近のブロックのすべてまたは一部の情報を用いて参照情報を決定するルールを用いることができる。
［第３の形態］
上記した所定のルールは、
前記台帳の一部またはすべての情報を入力として前記台帳の部分的情報を識別する識別子を一つまたは複数計算し、前記台帳から当該一つまたは複数の識別子に基づいて一つまたは複数の参照情報を抽出するルールであってもよい。
［第４の形態］
上記した台帳の部分的情報を識別する識別子として、一つまたは複数のブロックの高さを用いることができる。
［第５の形態］
上記した台帳の部分的情報を識別する識別子として、一つまたは複数のブロックの高さとトランザクションを識別する情報を用いることができる。
［第６の形態］
前記識別子は、０から前記台帳に格納された最新のブロックの高さの範囲で決定することが好ましい。
［第７の形態］
上記したブロックチェーン管理装置は、
さらに、
他の装置からトランザクションを受信するトランザクション受信部と、
前記台帳格納部に格納された最新のブロックから算出されるハッシュ値と、前記トランザクション受信部が受信したトランザクションを一つ以上まとめてブロックを生成するブロック生成部と
を備えていてもよい。
［第８の形態］
上記したブロックチェーン管理装置の前記ブロック生成部は、
前記ブロックから所定のルールで算出されるハッシュ値が所定の目標値と比較して事前に定められた条件を満たすようにブロックを生成するように構成することもできる。
［第９の形態］
（上記第２の視点によるブロックチェーン管理方法参照）
［第１０の形態］
（上記第３の視点によるコンピュータプログラム参照）
なお、上記第８～第９の形態は、第１の形態と同様に、第２～第７の形態に展開することが可能である。

なお、上記の特許文献および非特許文献の各開示を、本書に引用をもって繰り込むものとする。本発明の全開示（請求の範囲を含む）の枠内において、さらにその基本的技術思想に基づいて、実施形態ないし実施例の変更・調整が可能である。また、本発明の開示の枠内において種々の開示要素（各請求項の各要素、各実施形態ないし実施例の各要素、各図面の各要素等を含む）の多様な組み合わせ、ないし選択が可能である。すなわち、本発明は、請求の範囲を含む全開示、技術的思想にしたがって当業者であればなし得るであろう各種変形、修正を含むことは勿論である。特に、本書に記載した数値範囲については、当該範囲内に含まれる任意の数値ないし小範囲が、別段の記載のない場合でも具体的に記載されているものと解釈されるべきである。

１００、１００Ａ～１００Ｃブロックチェーン管理装置
１０１、１１０ブロック受信部
１０２、１２０ブロック検証部
１０３、１３０合意形成部
１０４、１４０台帳格納部
１２１参照情報検証部
１２２参照情報決定部
１５０トランザクション受信部
１６０ブロック生成部
Ｂブロック
ＢＨブロックヘッダ

Claims

ブロックチェーン管理装置間で取り決めた所定のルールに基づいて台帳の所定の範囲の中から選択した参照情報の要約値を少なくとも一つ含むブロックヘッダを含むブロックを受信するブロック受信部と、
前記所定のルールに基づいて前記台帳の所定の範囲の中から参照情報を選択し、前記ブロックに含まれる参照情報の要約値が前記参照情報に基づいて生成されているか否かにより、ブロックが正しく生成されたことを検証するブロック検証部と、
前記ブロック検証部により前記ブロックが正しく生成されたと検証された場合に、他のブロックチェーン管理装置と当該ブロックを書き込むことに対して合意形成を行う合意形成部と、
前記合意形成された前記ブロックを格納する台帳格納部と、
を備え、
前記所定のルールは、
前記台帳の一部またはすべての情報を入力として前記台帳の部分的情報を識別する識別子を一つまたは複数計算し、前記台帳から当該一つまたは複数の識別子に基づいて一つまたは複数の参照情報を抽出するルールである、ことを特徴とするブロックチェーン管理装置。
前記所定のルールとして、
一つまたは複数の直近のブロックのすべてまたは一部の情報を用いて参照情報を決定するルールを用いる
請求項１に記載のブロックチェーン管理装置。
前記台帳の部分的情報を識別する識別子として、一つまたは複数のブロックの高さを用いる
請求項１又は２に記載のブロックチェーン管理装置。
前記台帳の部分的情報を識別する識別子として、一つまたは複数のブロックの高さとトランザクションを識別する情報を用いる
請求項１又は２に記載のブロックチェーン管理装置。
前記識別子は、０から前記台帳に格納された最新のブロックの高さの範囲で決定される
請求項３又は４に記載のブロックチェーン管理装置。
さらに、
他の装置からトランザクションを受信するトランザクション受信部と、
前記台帳格納部に格納された最新のブロックから算出されるハッシュ値と、前記トランザクション受信部が受信したトランザクションを一つ以上まとめてブロックを生成するブロック生成部と
を備える請求項１から５いずれか一に記載のブロックチェーン管理装置。
前記ブロック生成部は、
前記ブロックから所定のルールで算出されるハッシュ値が所定の目標値と比較して事前に定められた条件を満たすようにブロックを生成することを特徴とする、
請求項６に記載のブロックチェーン管理装置。
台帳の所定の範囲の中から所定のルールに基づいて選択した参照情報の要約値を少なくとも一つ含むブロックヘッダを含むブロックを受信するステップと、
前記台帳の所定の範囲の中から所定のルールに基づいて参照情報を選択し、前記ブロックに含まれる参照情報の要約値が前記参照情報に基づいて生成されているか否かにより、ブロックが正しく生成されたことを検証するステップと、
前記検証により前記ブロックが正しく生成されたと検証された場合に、他のブロックチェーン管理装置と当該ブロックを書き込むことに対して合意形成を行うステップと、
前記合意形成された前記ブロックを格納するステップと、
を含み、
前記所定のルールは、
前記台帳の一部またはすべての情報を入力として前記台帳の部分的情報を識別する識別子を一つまたは複数計算し、前記台帳から当該一つまたは複数の識別子に基づいて一つまたは複数の参照情報を抽出するルールである、ブロックチェーン管理方法。
ブロックチェーン管理装置を構成するコンピュータに、
台帳の所定の範囲の中から所定のルールに基づいて選択した参照情報の要約値を少なくとも一つ含むブロックヘッダを含むブロックを受信する処理と、
前記台帳の所定の範囲の中から所定のルールに基づいて参照情報を選択し、前記ブロックに含まれる参照情報の要約値が前記参照情報に基づいて生成されているか否かにより、ブロックが正しく生成されたことを検証する処理と、
前記検証により前記ブロックが正しく生成されたと検証された場合に、他のブロックチェーン管理装置と当該ブロックを書き込むことに対して合意形成を行う処理と、
前記合意形成された前記ブロックを格納する処理と、
を実行させ、
前記所定のルールは、
前記台帳の一部またはすべての情報を入力として前記台帳の部分的情報を識別する識別子を一つまたは複数計算し、前記台帳から当該一つまたは複数の識別子に基づいて一つまたは複数の参照情報を抽出するルールである、
プログラム。