特許 7384044 検証方法、検証装置及び検証プログラム

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

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

(11)【特許番号】

(24)【登録日】2023-11-13

(45)【発行日】2023-11-21

(54)【発明の名称】検証方法、検証装置及び検証プログラム

(51)【国際特許分類】

   G06F 21/64 20130101AFI20231114BHJP

   G06Q 20/06 20120101ALI20231114BHJP

【ＦＩ】

G06F21/64

G06Q20/06

【請求項の数】 7

(21)【出願番号】P 2020005200

(22)【出願日】2020-01-16

(65)【公開番号】P2021114029

(43)【公開日】2021-08-05

【審査請求日】2022-09-08

(73)【特許権者】

【識別番号】000005223

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

(74)【代理人】

【識別番号】100107766

【弁理士】

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

(74)【代理人】

【識別番号】100070150

【弁理士】

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

(72)【発明者】

【氏名】竹内 琢磨

(72)【発明者】

【氏名】米倉 裕貴

(72)【発明者】

【氏名】藤本 真吾

(72)【発明者】

【氏名】森永 正信

【審査官】上島 拓也

(56)【参考文献】

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

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

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

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

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

Ｇ０６Ｆ ２１／６４

Ｇ０６Ｑ ２０／０６

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

【請求項1】

ブロックチェーンに格納された取引データの検証実績データから、前記取引データの検証に用いられた検証ポリシーに含まれる複数の関数それぞれの入力値及び出力値を取得し、
取得した前記入力値及び前記出力値のうち、前記複数の関数に含まれる１以上の関数の集合である第１の関数の入力値及び出力値による前記第１の関数の検証要求をブロックチェーンネットワークに含まれる第１のノードに送信するとともに、取得した前記入力値及び前記出力値のうち、前記複数の関数に含まれる１以上の関数の集合である第２の関数の入力値及び出力値による前記第２の関数の検証要求を前記ブロックチェーンネットワークに含まれる第２のノードに送信することで、前記検証ポリシーの検証を複数のノードに検証させる、
処理をコンピュータが実行することを特徴とする検証方法。

【請求項2】

前記検証させる処理は、前記第１の関数と前記第１の関数の入力値及び出力値とを前記第１のノードに送信し、前記第２の関数と前記第２の関数の入力値及び出力値とを前記第２のノードに送信する、
ことを特徴とする請求項１記載の検証方法。

【請求項3】

ブロックチェーンに格納された取引データの検証実績データから、前記取引データの検証に用いられた検証ポリシーの各部分に対する入力値を取得し、
前記部分ごとに取得した前記入力値を、ブロックチェーンネットワークに含まれるノードのうち前記部分ごとに異なるノードに、前記検証ポリシーの前記部分の検証要求とともに送信する、
処理をコンピュータが実行することを特徴とする検証方法。

【請求項4】

ブロックチェーンに格納された取引データの検証実績データから、前記取引データの検証に用いられた検証ポリシーに含まれる複数の関数それぞれの入力値及び出力値を取得する取得部と、
取得した前記入力値及び前記出力値のうち、前記複数の関数に含まれる１以上の関数の集合である第１の関数の入力値及び出力値による前記第１の関数の検証要求をブロックチェーンネットワークに含まれる第１のノードに送信するとともに、取得した前記入力値及び前記出力値のうち、前記複数の関数に含まれる１以上の関数の集合である第２の関数の入力値及び出力値による前記第２の関数の検証要求を前記ブロックチェーンネットワークに含まれる第２のノードに送信することで、前記検証ポリシーの検証を複数のノードに検証させる送信部と、
を有することを特徴とする検証装置。

【請求項5】

ブロックチェーンに格納された取引データの検証実績データから、前記取引データの検証に用いられた検証ポリシーの各部分に対する入力値を取得する取得部と、
前記部分ごとに取得した前記入力値を、ブロックチェーンネットワークに含まれるノードのうち前記部分ごとに異なるノードに、前記検証ポリシーの前記部分の検証要求とともに送信する送信部と、
を有することを特徴とする検証装置。

【請求項6】

ブロックチェーンに格納された取引データの検証実績データから、前記取引データの検証に用いられた検証ポリシーに含まれる複数の関数それぞれの入力値及び出力値を取得し、
取得した前記入力値及び前記出力値のうち、前記複数の関数に含まれる１以上の関数の集合である第１の関数の入力値及び出力値による前記第１の関数の検証要求をブロックチェーンネットワークに含まれる第１のノードに送信するとともに、取得した前記入力値及び前記出力値のうち、前記複数の関数に含まれる１以上の関数の集合である第２の関数の入力値及び出力値による前記第２の関数の検証要求を前記ブロックチェーンネットワークに含まれる第２のノードに送信することで、前記検証ポリシーの検証を複数のノードに検証させる、
処理をコンピュータに実行させることを特徴とする検証プログラム。

【請求項7】

ブロックチェーンに格納された取引データの検証実績データから、前記取引データの検証に用いられた検証ポリシーの各部分に対する入力値を取得し、
前記部分ごとに取得した前記入力値を、ブロックチェーンネットワークに含まれるノードのうち前記部分ごとに異なるノードに、前記検証ポリシーの前記部分の検証要求とともに送信する、
処理をコンピュータに実行させることを特徴とする検証プログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、検証方法、検証装置及び検証プログラムに関する。

【背景技術】

【0002】

ブロックチェーンは原則として、各取引について、多数のノードによる検証をベースとして、中央機関不在の信頼性を保っている。ＢｉｔｃｏｉｎやＥｔｈｅｒｅｕｍに代表されるパブリックブロックチェーンは、参加するプレイヤーの非中央集権的な運用を可能としているが、各取引は仮想通貨と紐づいており、金銭面でブロックチェーンネットワークの参加に対するインセンティブを確保している。

【先行技術文献】

【特許文献】

【0003】

【文献】特開２０１９－７４９１０号公報

【発明の概要】

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

【0004】

しかしながら、コンソーシアムブロックチェーンの場合、そもそも仮想通貨自体をデフォルトで備えてないプログラムもあり、ノードとして参加するためのインセンティブを確保できない。上記したように、ブロックチェーンの信頼性は、多数のノードによる検証をベースとしているため、多数のノードの参加を確保することは、ブロックチェーンの信頼性の確保にとって非常に重要である。

【0005】

そこで、一側面では、ブロックチェーンネットワークへの参加意欲を増進させることを目的とする。

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

【0006】

一つの態様では、ブロックチェーンに格納された取引データの検証実績データから、前記取引データの検証に用いられた検証ポリシーに含まれる複数の関数それぞれの入力値及び出力値を取得し、取得した前記入力値及び前記出力値のうち、前記複数の関数に含まれる１以上の関数の集合である第１の関数の入力値及び出力値による前記第１の関数の検証要求をブロックチェーンネットワークに含まれる第１のノードに送信するとともに、取得した前記入力値及び前記出力値のうち、前記複数の関数に含まれる１以上の関数の集合である第２の関数の入力値及び出力値による前記第２の関数の検証要求を前記ブロックチェーンネットワークに含まれる第２のノードに送信することで、前記検証ポリシーの検証を複数のノードに検証させる、処理をコンピュータが実行する。

【発明の効果】

【0007】

一側面として、ブロックチェーンネットワークへの参加意欲を増進させることができる。

【図面の簡単な説明】

【0008】

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

【図2】本発明の実施の形態における各ピア１０のハードウェア構成例を示す図である。

【図3】本発明の実施の形態における各ピア１０の機能構成例を示す図である。

【図4】固有ポリシーの登録時に実行される処理手順の一例を説明するためのシーケンス図である。

【図5】固有ポリシーのポリシーグラフへの変換例を示す図である。

【図6】秘匿構造データの一例を示す図である。

【図7】固有ポリシーの検証対象となる取引の発生時に実行される処理手順の一例を説明するためのシーケンス図である。

【図8】固有ポリシーの検証処理の処理手順の一例を説明するためのシーケンス図である。

【図9】秘匿構造データの部分グラフへの分割例を示す図である。

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

【0009】

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

【0010】

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

【0011】

取引管理システム１は、ユーザ端末２０間で行われる取引を管理するＰ２Ｐネットワーク（ブロックチェーンネットワーク）であり、分散型台帳技術が適用された複数のコンピュータ又は情報処理装置であるノードの集合を含む。本実施の形態では、便宜上、各ノードをピア（Peer）１０という。各ピア１０は、ブロックチェーンネットワークによって接続され、共通の台帳情報を分散して管理する記憶部（以下、「台帳」という。）を有する。台帳には、取引の履歴を示すブロックチェーンが記録される。図１において、ブロックチェーンＣ１は、各ピア１０が有する台帳に記憶されている、ピア１０間において共通のブロックチェーンを示す。なお、図１では、便宜上、４つのピア１０が取引管理システム１に含まれる例が示されているが、ピア１０の数は、４つに限定されない。

【0012】

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

【0013】

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

【0014】

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

【0015】

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

【0016】

図３は、本発明の実施の形態における各ピア１０の機能構成例を示す図である。図３において、ピア１０は、通信部１１、ポリシー登録部１２、取引検証判定部１３及び固有ポリシー検証部１４等を有する。これら各部は、ピア１０にインストールされた１以上のプログラムが、ＣＰＵ１０４に実行させる処理により実現される。ピア１０は、また、ポリシーＤＢ１５及び検証実績データＤＢ１６等のデータベース（記憶部）を利用する。これら各記憶部は、例えば、補助記憶装置１０２、又はピア１０にネットワークを介して接続可能な記憶装置等を用いて実現可能である。

【0017】

通信部１１は、ユーザ端末２０又は他のピア１０との通信を行う。また、或るピア１０の通信部１１は、取引データをブロックチェーンＣ１へ記録する。ポリシー登録部１２は、取引の検証ポリシーであって、各ピア１０に固有のポリシー（以下「固有ポリシー」という。）の入力を受け付け、入力された固有ポリシーをポリシーＤＢ１５に登録する。すなわち、本実施の形態では、取引の検証ポリシーとして全ピア１０において共通のポリシー（以下「共通ポリシー」という。）とは別に、ピア１０ごとに個別の固有ポリシーの設定が可能とされる。

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

続いて、各ピア１０の通信部１１は、当該各ピア１０の固有ポリシー検証部１４による判定結果をピア１０ｘへ送信する（Ｓ３０８）。

【0054】

ピア１０ｘの通信部１１ｘによって各ピア１０の判定結果が受信されると、ピア１０ｘの固有ポリシー検証部１４ｘは、各ピア１０からの判定結果に基づいて、対象固有ポリシーの検証結果を判定する（Ｓ３０９）。例えば、他ピア１０による全ての判定結果がＯＫである場合に、対象ポリシーは正当である（検証結果はＯＫである）と判定されてもよいし、そうでない場合に、対象ポリシーは不正である（検証結果はＮＧである（他のピア１０に無断で変更されている））と判定されてもよい。続いて、ピア１０ｘの通信部１１ｘは、固有ポリシー検証部１４ｘによる判定結果をブロックチェーンＣ１へ格納する（Ｓ３１０）。

【0055】

なお、上記では、固有ポリシーの内容がセンサデータに関するものである例について示したが（図５参照）、その他の固有ポリシーの例について以下に記す。

【0056】

［固有ポリシーの具体例１：銀行取引の場合］
銀行の預金取引に対して本実施の形態を適用する場合について述べる。特に、「送金額が送金者の預金残高を超えてないか」等の表面的な取引検証だけでなく、ブロックチェーンネットワークの参加者（ピア１０）が各々の固有なロジック（固有ポリシー）で送金の可否を検証する場合を考える。

【0057】

検証に利用する入力値の例としては以下の通りである。
（１）送金者の１週間以内の送金回数
（２）送金者の１週間以内の合計送金金額
（３）送金する通貨のドル比率レート値
（４）送金者の所属する企業の株価変動比率
この場合、各ピア１０の固有ポリシーとして以下のポリシー１及びポリシー２が一例として挙げられる。

【0058】

［ポリシー１］
（送金回数≦１０ ａｎｄ 合計送金金額＜５０００００） ｏｒ レート値＜２．５ ならば、送金取引の検証結果をＯＫとし、そうでなければ当該検証結果をＮＧとする。

【0059】

［ポリシー２］
（合計送金金額＜１０００００ ｏｒ レート値＜１．５） ａｎｄ ０．８＜企業株価変動率＜１．２ ならば、送金取引の検証結果をＯＫとし、そうでなければ当該検証結果をＮＧとする。

【0060】

［固有ポリシーの具体例２：サプライチェーンの場合］
サプライチェーンにおける配送システムに対して本実施の形態を適用する場合について述べる。前述の具体例１と同様に、ブロックチェーンネットワークの参加者（ピア１０）が各々の固有なロジック（固有ポリシー）で送金の可否を検証する場合を考える。

【0061】

検証に利用する入力値の例としては以下の通りである：
（１）各配送業者Ａ、Ｂ、Ｃ、Ｄの工数見積もり値
（２）各配送業者Ａ、Ｂ、Ｃ、Ｄの配送品質の見積もり値
（３）当日の天候（晴れ：１，曇り：２，雨：３，その他：４）
この場合、各ピア１０の固有ポリシーとして以下のポリシー１及びポリシー２が一例として挙げられる。

【0062】

［ポリシー１］
（配送業者Ａの工数≧３ ｏｒ 配送業者Ｂの工数≧４） ａｎｄ 天候＜３ ならば、配送の取引の検証結果をＯＫとし、そうでなければ当該検証結果をＮＧとする。

【0063】

［ポリシー２］
（（配送業者Ｂの工数≧２ ａｎｄ 配送業者Ｂの品質値≧５） ｏｒ 配送業者Ｃの工数≧５） ａｎｄ 天候＜２ ならば、配送の取引の検証結果をＯＫとし、そうでなければ当該検証結果をＮＧとする。

【0064】

上述したように、本実施の形態によれば、各ピア１０は検証ポリシーとして共通ポリシーとは別に固有ポリシーを用いることができる。したがって、各参加者（ピア１０）は、自らの意図を取引データの検証に反映させることができる。例えば、各ピア１０が企業であれば、各企業は自社にとって都合の良い検証ポリシーを取引データの検証に用いることができる。その結果、ブロックチェーンネットワークへの参加意欲を増進させることができる。

【0065】

また、本実施の形態では、検証ポリシーの部分ごと（関数ごと）に別のピア１０によって当該部分の検証が行われる。その結果、各ピア１０が取引の検証に固有ポリシーを用いた場合であっても、当該固有ポリシーが各ピア１０の都合によって不正に（他ピア１０に無断で）変更されるのを防ぐことができる。したがって、各ピア１０が固有ポリシーを用いること（取引の検証ポリシーの多角化）を可能とすることができ、固有ポリシーを用いることができるということで、ブロックチェーンネットワークへの参加意欲を増進させることができる。

【0066】

また、固有ポリシーは、ピア１０にとって非公開にしたい情報である可能性が有るところ、本実施の形態では、固有ポリシーの各検証要求先に対して公開されるのは、当該固有ポリシーの一部分である。したがって、或るピア１０に対して固有ポリシーの全部が公開されるのを回避することができる。

【0067】

すなわち、ピア１０ごとに検証ポリシーが異なるブロックチェーンネットワークを構築する際、固有ポリシーの正当性（変更されていないこと）の保証が必要となるが、或るピア１０の固有ポリシーを他のピア１０が検証を要求する際に、当該固有ポリシーの生の値を公開したくない。すなわち、「あるピア１０の固有ポリシーの生の値を他のピア１０に晒さない」、「固有ポリシーが正しいことを他のピア１０が検証可能とする」という、相反する要求を本実施の形態によれば満たすことができる。

【0068】

なお、本実施の形態において、ピア１０は、検証装置の一例である。固有ポリシー検証部１４は、取得部及び検証部の一例である。通信部１１は、送信部の一例である。ピア１０が保有する秘密鍵に対応付く公開鍵又は各ピア１０が保有する共通鍵は、暗号鍵の一例である。

【0069】

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

【0070】

以上の説明に関し、更に以下の項を開示する。
（付記１）
ブロックチェーンに格納された取引データの検証実績データから、前記取引データの検証に用いられた検証ポリシーに含まれる複数の関数それぞれの入力値及び出力値を取得し、
取得した前記入力値及び前記出力値のうち、前記複数の関数に含まれる１以上の関数の集合である第１の関数の入力値及び出力値による前記第１の関数の検証要求をブロックチェーンネットワークに含まれる第１のノードに送信するとともに、取得した前記入力値及び前記出力値のうち、前記複数の関数に含まれる１以上の関数の集合である第２の関数の入力値及び出力値による前記第２の関数の検証要求を前記ブロックチェーンネットワークに含まれる第２のノードに送信することで、前記検証ポリシーの検証を複数のノードに検証させる、
処理をコンピュータが実行することを特徴とする検証方法。
（付記２）
前記検証させる処理は、前記第１の関数と前記第１の関数の入力値及び出力値とを前記第１のノードに送信し、前記第２の関数と前記第２の関数の入力値及び出力値とを前記第２のノードに送信する、
ことを特徴とする付記１記載の検証方法。
（付記３）
ブロックチェーンに格納された取引データの検証実績データから、前記取引データの検証に用いられた検証ポリシーの入力値を取得し、
取得した前記入力値を、ブロックチェーンネットワークに含まれるノードが保有する暗号鍵により暗号化して、前記検証ポリシーの検証要求とともに前記ノードに送信する、
処理をコンピュータが実行することを特徴とする検証方法。
（付記４）
ブロックチェーンネットワークに含まれるノードとしてのコンピュータが、
他のノードの異なる検証ポリシーを用いて取引データを検証し、
前記取引データの検証結果を送信する、
処理を実行することを特徴とする検証方法。
（付記５）
ブロックチェーンに格納された取引データの検証実績データから、前記取引データの検証に用いられた検証ポリシーに含まれる複数の関数それぞれの入力値及び出力値を取得する取得部と、
取得した前記入力値及び前記出力値のうち、前記複数の関数に含まれる１以上の関数の集合である第１の関数の入力値及び出力値による前記第１の関数の検証要求をブロックチェーンネットワークに含まれる第１のノードに送信するとともに、取得した前記入力値及び前記出力値のうち、前記複数の関数に含まれる１以上の関数の集合である第２の関数の入力値及び出力値による前記第２の関数の検証要求を前記ブロックチェーンネットワークに含まれる第２のノードに送信することで、前記検証ポリシーの検証を複数のノードに検証させる送信部と、
を有することを特徴とする検証装置。
（付記６）
前記送信部は、前記第１の関数と前記第１の関数の入力値及び出力値とを前記第１のノードに送信し、前記第２の関数と前記第２の関数の入力値及び出力値とを前記第２のノードに送信する、
ことを特徴とする付記５記載の検証装置。
（付記７）
ブロックチェーンに格納された取引データの検証実績データから、前記取引データの検証に用いられた検証ポリシーの入力値を取得する取得部と、
取得した前記入力値を、ブロックチェーンネットワークに含まれるノードが保有する暗号鍵により暗号化して、前記検証ポリシーの検証要求とともに前記ノードに送信する送信部と、
を有することを特徴とする検証装置。
（付記８）
ブロックチェーンネットワークに含まれるノードとしての検証装置であって、
他のノードの異なる検証ポリシーを用いて取引データを検証する検証部と、
前記取引データの検証結果を送信する送信部と、
を有することを特徴とする検証装置。
（付記９）
ブロックチェーンに格納された取引データの検証実績データから、前記取引データの検証に用いられた検証ポリシーに含まれる複数の関数それぞれの入力値及び出力値を取得し、
取得した前記入力値及び前記出力値のうち、前記複数の関数に含まれる１以上の関数の集合である第１の関数の入力値及び出力値による前記第１の関数の検証要求をブロックチェーンネットワークに含まれる第１のノードに送信するとともに、取得した前記入力値及び前記出力値のうち、前記複数の関数に含まれる１以上の関数の集合である第２の関数の入力値及び出力値による前記第２の関数の検証要求を前記ブロックチェーンネットワークに含まれる第２のノードに送信することで、前記検証ポリシーの検証を複数のノードに検証させる、
処理をコンピュータに実行させることを特徴とする検証プログラム。
（付記１０）
前記検証させる処理は、前記第１の関数と前記第１の関数の入力値及び出力値とを前記第１のノードに送信し、前記第２の関数と前記第２の関数の入力値及び出力値とを前記第２のノードに送信する、
ことを特徴とする付記９記載の検証プログラム。
（付記１１）
ブロックチェーンに格納された取引データの検証実績データから、前記取引データの検証に用いられた検証ポリシーの入力値を取得し、
取得した前記入力値を、ブロックチェーンネットワークに含まれるノードが保有する暗号鍵により暗号化して、前記検証ポリシーの検証要求とともに前記ノードに送信する、
処理をコンピュータに実行させることを特徴とする検証プログラム。
（付記１２）
ブロックチェーンネットワークに含まれるノードとしてのコンピュータに、
他のノードの異なる検証ポリシーを用いて取引データを検証し、
前記取引データの検証結果を送信する、
処理を実行させることを特徴とする検証プログラム。

【符号の説明】

【0071】

１ 取引管理システム
１０ ピア
１１ 通信部
１２ ポリシー登録部
１３ 取引検証判定部
１４ 固有ポリシー検証部
１５ ポリシーＤＢ
１６ 検証実績データＤＢ
２０ ユーザ端末
１００ ドライブ装置
１０１ 記録媒体
１０２ 補助記憶装置
１０３ メモリ装置
１０４ ＣＰＵ
１０５ インタフェース装置
Ｂ バス
Ｃ１ ブロックチェーン

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】