特許 7298716 送信制御方法、送信制御プログラム及び情報処理装置

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

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

(11)【特許番号】

(24)【登録日】2023-06-19

(45)【発行日】2023-06-27

(54)【発明の名称】送信制御方法、送信制御プログラム及び情報処理装置

(51)【国際特許分類】

   H04L 9/32 20060101AFI20230620BHJP

【ＦＩ】

H04L9/32 200Z

【請求項の数】 7

(21)【出願番号】P 2021566688

(86)(22)【出願日】2019-12-26

(86)【国際出願番号】 JP2019051156

(87)【国際公開番号】W WO2021130968

(87)【国際公開日】2021-07-01

【審査請求日】2022-06-30

(73)【特許権者】

【識別番号】000005223

【氏名又は名称】富士通株式会社

(74)【代理人】

【識別番号】100107766

【弁理士】

【氏名又は名称】伊東 忠重

(74)【代理人】

【識別番号】100070150

【弁理士】

【氏名又は名称】伊東 忠彦

(72)【発明者】

【氏名】米倉 裕貴

(72)【発明者】

【氏名】竹内 琢磨

【審査官】行田 悦資

(56)【参考文献】

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

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

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

Ｈ０４Ｌ ９／３２

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

【請求項1】

ブロックチェーンに含まれるブロックに格納されたトランザクションの送信制御方法において、
前記トランザクションの参照要求を受信すると、ブロックチェーンネットワークに含まれるノードに前記トランザクションの検証要求を送信し、
前記ノードによる検証結果を受信すると、前記検証結果を格納した検証ブロックを生成して、生成した前記検証ブロックを前記ブロックチェーンに接続するとともに、前記検証結果に基づき、前記トランザクションを前記参照要求の要求元に送信するか否かを制御する、
処理をコンピュータが実行することを特徴とする送信制御方法。

【請求項2】

前記制御する処理は、検証ブロックの前記ブロックチェーンへの接続時に、前記検証ブロックを前記トランザクションに対応付ける、
ことを特徴とする請求項１に記載の送信制御方法。

【請求項3】

前記送信する処理は、前記トランザクションの参照要求を受信すると、前記ブロックチェーンに前記トランザクションに対応付けられた検証ブロックが含まれるか否かを判定し、前記検証ブロックが含まれる場合、前記検証ブロックを生成することを抑制する、
ことを特徴とする請求項２に記載の送信制御方法。

【請求項4】

前記制御する処理は、前記ブロックチェーンに前記検証ブロックが含まれる場合、前記検証ブロックに格納された検証結果に基づき、前記トランザクションを前記参照要求の要求元に送信するか否かを制御する、
ことを特徴とする請求項３に記載の送信制御方法。

【請求項5】

生成した前記検証ブロックを前記ブロックチェーンネットワークに含まれるノードに送信する、
処理をコンピュータが実行することを特徴とする請求項１乃至４のいずれか一項に記載の送信制御方法。

【請求項6】

ブロックチェーンに含まれるブロックに格納されたトランザクションの送信制御方法をコンピュータに実行させる送信制御プログラムにおいて、
前記トランザクションの参照要求を受信すると、ブロックチェーンネットワークに含まれるノードに前記トランザクションの検証要求を送信し、
前記ノードによる検証結果を受信すると、前記検証結果を格納した検証ブロックを生成して、生成した前記検証ブロックを前記ブロックチェーンに接続するとともに、前記検証結果に基づき、前記トランザクションを前記参照要求の要求元に送信するか否かを制御する、
処理をコンピュータに実行させることを特徴とする送信制御プログラム。

【請求項7】

ブロックチェーンに含まれるブロックに格納されたトランザクションの送信を制御する情報処理装置において、
前記トランザクションの参照要求を受信すると、ブロックチェーンネットワークに含まれるノードに前記トランザクションの検証要求を送信する第１の送信部と、
前記ノードによる検証結果を受信すると、前記検証結果を格納した検証ブロックを生成して、生成した前記検証ブロックを前記ブロックチェーンに接続するとともに、前記検証結果に基づき、前記トランザクションを前記参照要求の要求元に送信するか否かを制御する制御部と、
を有することを特徴とする情報処理装置。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、送信制御方法、送信制御プログラム及び情報処理装置に関する。

【背景技術】

【0002】

ブロックチェーンは、１以上のトランザクション（ＡさんがＢさんに１００円を送金する等という取引内容）を格納したブロックを、チェーン状に数珠繋ぎにしたものであり、Ｐ２Ｐネットワーク（ブロックチェーンネットワーク）を構成する複数のノードによって分散管理される。なお、各ブロックには、１つ前のブロックのハッシュ値が含められることで、各ブロックの改竄が困難にされている。

【0003】

新たなトランザクションが格納されたブロックをチェーンに接続する（以下、斯かる処理を「Ｗｒｉｔｅする」という。）際には、ブロックチェーンネットワークを構成する全ノードがトランザクションの検証を行う。当該検証は、主に、ブロック作成ノードの署名の検証、及びトランザクションのＩｎｐｕｔ／Ｏｕｔｐｕｔがノードの現在の状態と整合することの検証を行う処理であり、ノードが実行する処理の大部分を占めている。

【0004】

一方、ブロックチェーンに接続されているいずれかのブロック内のトランザクションを参照する（以下「Ｒｅａｄする」という。）際には、新規ブロックの生成や当該トランザクションの検証は行われない。

【先行技術文献】

【特許文献】

【0005】

【文献】特開２０１８－１２８７２３号公報

【発明の概要】

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

【0006】

しかしながら、Ｗｒｉｔｅのたびにブロックチェーンネットワークに参加する全ノードがトランザクションの検証を行う場合、例えば、以下のような問題が有る。
（１）ＲｅａｄよりもＷｒｉｔｅの頻度が多い（例えば、ブロックチェーンにデータを証跡として残すことが目的の）場合、に全ノードの処理効率が悪い（処理負荷が高い）。
（２）Ｒｅａｄされることのないデータを検証する場合も有り、効率が悪い。

【0007】

そこで、一側面では、ブロックチェーンネットワークに含まれるノードの処理負荷を抑制することを目的とする。

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

【0008】

一つの案では、ブロックチェーンに含まれるブロックに格納されたトランザクションの送信制御方法は、前記トランザクションの参照要求を受信すると、ブロックチェーンネットワークに含まれるノードに前記トランザクションの検証要求を送信し、前記ノードによる検証結果を受信すると、前記検証結果を格納した検証ブロックを生成して、生成した前記検証ブロックを前記ブロックチェーンに接続するとともに、前記検証結果に基づき、前記トランザクションを前記参照要求の要求元に送信するか否かを制御する、処理をコンピュータが実行する。

【発明の効果】

【0009】

一態様によれば、ブロックチェーンネットワークに含まれるノードの処理負荷を抑制することができる。

【図面の簡単な説明】

【0010】

【図1】本発明の実施の形態におけるトランザクション管理システム１の構成例を示す図である。

【図2】本発明の実施の形態におけるトランザクション管理システム１を構成する各ノードのハードウェア構成例を示す図である。

【図3】本発明の実施の形態におけるトランザクション管理システム１の機能構成例を示す図である。

【図4】Ｗｒｉｔｅ時においてトランザクション管理システム１が実行する処理手順の一例を説明するためのシーケンス図である。

【図5】ステートＤＢ２７の構成例を示す図である。

【図6】Ｒｅａｄ時においてトランザクション管理システム１が実行する処理手順の一例を説明するためのシーケンス図である。

【図7】検証ブロックが接続されたブロックチェーンの一例を示す図である。

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

【0011】

以下、図面に基づいて本発明の実施の形態を説明する。図１は、本発明の実施の形態におけるトランザクション管理システム１の構成例を示す図である。図１において、複数のユーザ端末５０は、インターネット等のネットワークを介してトランザクション管理システム１に接続される。

【0012】

ユーザ端末５０は、送金等の各種の取引（以下「トランザクション」という。）の当事者が利用する端末である。例えば、ＰＣ（Personal Computer）、スマートフォン又はタブレット端末等がユーザ端末５０として利用されてもよい。

【0013】

トランザクション管理システム１は、ユーザ端末５０間で行われるトランザクションを管理するＰ２Ｐネットワーク（ブロックチェーンネットワーク）であり、分散型台帳技術が適用された複数のコンピュータ又は情報処理装置（ノード）の集合を含む。各ノードは、ブロックチェーンネットワークによって接続され、共通の台帳情報を分散して管理する記憶部（以下、「台帳」という。）を有する。台帳には、トランザクションの履歴を示すブロックチェーンが記録される。本実施の形態において、台帳に記録されているブロックチェーンに対して新たなブロックを接続（追加）する処理を「Ｗｒｉｔｅ」といい、ブロックチェーンに接続されているいずれかのブロック内のトランザクションを参照する処理を「Ｒｅａｄ」という。

【0014】

本実施の形態において、トランザクション管理システム１は、Ｗｒｉｔｅ時ではなく、Ｒｅａｄ時にトランザクションの検証を実施することにより、トランザクションの検証に費やすリソースを削減しつつ、効率よく確実にトランザクションの検証を可能とする。なお、斯かる効果を顕著に得るために、トランザクション管理システム１において、ブロックチェーンへのＷｒｉｔｅの頻度の方がＲｅａｄの頻度よりも相対的に多い方が好ましい。

【0015】

また、トランザクション管理システム１としては、ノードの参加が許可制であり、ブロックチェーンが分岐しないコンソーシアム型ブロックチェーン（例えば、Hyperledger Fabric等）が好適である。

【0016】

また、トランザクション管理システム１には、従来のブロックチェーンに関する以下の仕組みは備わっていることとする。
・単一又は複数のノードにスマートコントラクトを配備、共有、実行する仕組み。
・トランザクションの生成及び参照をスマートコントラクトを介して行う仕組み。
・途中から起動、再起動したノードが、最新ブロックまでのブロックチェーンを共有する仕組み。
・トランザクションを生成するノードが全ノードに当該トランザクションを含むブロックを配信する仕組み（ブロックの順序は何かしらの方法で保証されている。）。

【0017】

更に、トランザクション管理システム１は、以下の４つの機能を有する。

【0018】

（１）［トランザクション生成・書き込み機能］
スマートコントラクト等を用いてトランザクションを生成したノードが、ブロックを生成してブロックチェーンネットワークに参加する全ノードにブロックを配布すると、当該ブロックを受信した各ノードが、トランザクションの検証を行わずに当該ブロックをＷｒｉｔｅする。また、トランザクションを参照するための情報（トランザクションＩＤ等のトランザクションを特定する情報）がノード内のデータベースに格納される。

【0019】

（２）［トランザクション参照機能］
スマートコントラクト等を用いてトランザクションを参照したノードが、自身を含む、ブロックチェーンネットワークに参加する全ノードに、当該トランザクションを配布して当該トランザクションの検証を要求すると、要求を受けた各ノードがトランザクションを検証して検証結果と検証に対する署名を返却する。また、トランザクションを参照したノードが収集した全ノードの検証結果と署名をブロック（以下「検証ブロック」という。）に格納し、検証ブロックを全ノードに配布する。なお、検証ブロックは、１つ前のブロックのハッシュ値、検証対象のトランザクションのハッシュ値等を格納する。

【0020】

（３）［依存トランザクションの参照・検証機能］
（１）のトランザクション生成・書き込み機能に関して、スマートコントラクト等を用いてトランザクションを生成した直後に、生成したトランザクションが依存する過去のトランザクションについて、（２）のトランザクション参照機能が実行される。

【0021】

（４）［トランザクション検証結果のキャッシュ機能］
（２）のトランザクション参照機能に関して、一度参照（Ｒｅａｄ）されたトランザクションの検証結果がノード内のデータベースにキャッシュされる。トランザクションが参照される際は、参照されたトランザクションの検証結果がノード内のデータベースから検索され、検証結果が存在しない場合にトランザクションの検証が行われる。

【0022】

すなわち、本実施の形態では、スマートコントラクトの実行により生成されたトランザクションのＷｒｉｔｅ時にはトランザクションの検証は行われずに当該トランザクションを格納したブロックが全ノードに配布される。但し、Ｗｒｉｔｅ対象のトランザクションが過去のトランザクションに依存する場合（例えば、Ｗｒｉｔｅ対象のトランザクションが過去の残高に依存する金銭取引のトランザクションである場合等）、過去のトランザクションのＲｅａｄが実行される。また、トランザクションのＲｅａｄ時には、スマートコントラクトの実行によりトランザクションを参照したノードが全ノードに当該トランザクションの検証を要求し、検証結果と署名を収集し、当該検証結果及び署名を検証ブロックに格納して当該検証ブロックを全ノードに配布する。この際、検証結果はノード内のデータベースにキャッシュされる。したがって、トランザクションのＲｅａｄ時において、ノード内のデータベースに検証結果がキャッシュされている場合は、当該トランザクションの検証の要求以降は実行されず、検証ブロックの生成が抑制される。

【0023】

図２は、本発明の実施の形態におけるトランザクション管理システム１を構成する各ノードのハードウェア構成例を示す図である。図２に示されるように、各ノードは、それぞれバスＢで相互に接続されているドライブ装置１０１、補助記憶装置１０２、メモリ装置１０３、ＣＰＵ１０４、及びインタフェース装置１０５等を有する。

【0024】

ノードでの処理を実現するプログラムは、記録媒体１０６によって提供される。プログラムを記録した記録媒体１０６がドライブ装置１０１にセットされると、プログラムが記録媒体１０６からドライブ装置１０１を介して補助記憶装置１０２にインストールされる。但し、プログラムのインストールは必ずしも記録媒体１０６より行う必要はなく、ネットワークを介して他のコンピュータよりダウンロードするようにしてもよい。補助記憶装置１０２は、インストールされたプログラムを格納すると共に、必要なファイルやデータ等を格納する。

【0025】

メモリ装置１０３は、プログラムの起動指示があった場合に、補助記憶装置１０２からプログラムを読み出して格納する。ＣＰＵ１０４は、メモリ装置１０３に格納されたプログラムに従ってノードに係る機能を実行する。インタフェース装置１０５は、ネットワークに接続するためのインタフェースとして用いられる。

【0026】

なお、記録媒体１０６の一例としては、ＣＤ－ＲＯＭ、ＤＶＤディスク、又はＵＳＢメモリ等の可搬型の記録媒体が挙げられる。また、補助記憶装置１０２の一例としては、ＨＤＤ（Hard Disk Drive）又はフラッシュメモリ等が挙げられる。記録媒体１０６及び補助記憶装置１０２のいずれについても、コンピュータ読み取り可能な記録媒体に相当する。

【0027】

図３は、本発明の実施の形態におけるトランザクション管理システム１の機能構成例を示す図である。本実施の形態では、便宜上、トランザクション管理システム１が、コンソーシアム型ブロックチェーン基盤「Hyperledger Fabric」に基づく例を示す。但し、他のブロックチェーン基盤が採用されてもよい。

【0028】

図３において、トランザクション管理システム１は、ピア（Ｐｅｅｒ）２０として機能する複数のノード、オーダラー（Orderer）３０として機能する１つのノード、及びチェーンコード（Chaincode）４０として機能する１つのノードを含む。ここで、ノードは、１又は複数のコンピュータである。但し、トランザクション管理システム１は、複数のオーダラー３０及び複数のチェーンコード４０を含んでもよい。

【0029】

オーダラー３０は、ブロックを生成し、当該ブロックを各ピア２０に配布するノードである。図３において、オーダラー３０は、Ｔｘブロック生成部３１及び検証ブロック生成部３２等を有する。これら各部は、オーダラー３０にインストールされた１以上のプログラムが、オーダラー３０のＣＰＵ１０４に実行させる処理により実現される。

【0030】

Ｔｘブロック生成部３１は、トランザクションに関するデータ（以下「トランザクションデータ」という。）を含むブロック（以下「Ｔｘブロック」という。）を生成する。検証ブロック生成部３２は、検証ブロックを生成する。

【0031】

ピア２０は、ブロックチェーンを記録した共通の台帳情報を分散して管理する。ピア２０は、ユーザ端末５０からトランザクションのＷｒｉｔｅ要求又はＲｅａｄ要求を受け付け、これらの要求に応じた処理を制御する。図３において、ピア２０は、Ｔｘ送受信部２１、依存Ｔｘ検索部２２、Ｔｘブロック送受信部２３、Ｔｘ検証部２４、検証結果送受信部２５及び検証ブロック送受信部２６等を有する。これら各部は、ピア２０にインストールされた１以上のプログラムが、ピア２０のＣＰＵ１０４に実行させる処理により実現される。ピア２０は、また、ステートＤＢ２７及び台帳２８等の記憶部を利用する。これら各記憶部は、例えば、補助記憶装置１０２、又はピア２０にネットワークを介して接続可能な記憶装置等を用いて実現可能である。

【0032】

Ｔｘ送受信部２１は、ユーザ端末５０からＷｒｉｔｅ要求又はＲｅａｄ要求を受信し、これらの要求に応じた処理を制御する。

【0033】

依存Ｔｘ検索部２２は、Ｗｒｉｔｅ要求の対象のトランザクションが依存する（当該トランザクションの依存先の）トランザクションをステートＤＢ２７から検索する。ステートＤＢ２７には、各トランザクションに関するデータが記憶される。本実施の形態において、ステートＤＢ２７は、各トランザクションの検証結果をキャッシュするための記憶部としても利用される。なお、WorldState等がステートＤＢ２７として利用されてもよい。

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

例えば、ブロックチェーン基盤「Hyperledger Fabric」の場合、検証にかかる時間はＷｒｉｔｅにかかる時間の約２０％なので、Ｗｒｉｔｅにかかる処理時間について約２０％の削減を期待することができる。

【0075】

また、例えば、３０分に１度のＰ２Ｐ電力取引の場合、おおよそＷｒｉｔｅ（電力メータの値記録）は、１トランザクション／ｍｉｎ、Ｒｅａｄ（電力取引時の電力量参照）は、１トランザクション／３０ｍｉｎである。単純計算で全データ量の１／３０をＲｅａｄすることになるので、全体として検証に費やすリソース（時間、データ量）について約９７％の削減を期待することができる。

【0076】

また、本実施の形態によれば、トランザクションをＷｒｉｔｅする前段階（ノードがスマートコントラクトを実行した直後）に、当該トランザクションに関係する他のトランザクション（依存トランザクション）のＲｅａｄが実行されるため、Ｗｒｉｔｅしようとするトランザクションが過去のトランザクションに依存している場合でも、過去のトランザクションが正当であることを保証することができる。

【0077】

また、本実施の形態によれば、１度Ｒｅａｄされたトランザクションの検証結果がノード内のデータベース（ステートＤＢ２７）にキャッシュされ、過去に検証されたトランザクションについてＲｅａｄが要求された際には、当該キャッシュに基づいて検証が抑制される。したがって、同一のトランザクションについて検証が重複して行われることを回避することができる。

【0078】

以上、本発明の実施の形態について詳述したが、本発明は斯かる特定の実施形態に限定されるものではなく、請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。

【符号の説明】

【0079】

１ トランザクション管理システム
２０ ピア
２１ Ｔｘ送受信部
２２ 依存Ｔｘ検索部
２３ Ｔｘブロック送受信部
２４ Ｔｘ検証部
２５ 検証結果送受信部
２６ 検証ブロック送受信部
２７ ステートＤＢ
２８ 台帳
３０ オーダラー
３１ Ｔｘブロック生成部
３２ 検証ブロック生成部
４０ チェーンコード
４１ Ｔｘ生成部
４２ Ｔｘ参照部
５０ ユーザ端末
５１ クライアント部
１０１ ドライブ装置
１０２ 補助記憶装置
１０３ メモリ装置
１０４ ＣＰＵ
１０５ インタフェース装置
１０６ 記録媒体
Ｂ バス

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】