JP6545888B1 - 情報処理システム、公開鍵の変更方法、およびプログラム - Google Patents

Abstract

【課題】第三者によるリアルタイムでの残高照会機能を有したまま、より匿名性の高い公開鍵変更を可能とする情報処理システムを提供する。【解決手段】第１ノード１と、公開鍵の変更支援サービスを提供する第２ノード２と、ブロックチェーン３と、を備えた情報処理システム１００であって、第１ノード１は、新公開鍵作成部１５１と、第２ノード群選択部１５２と、新旧鍵情報要求部１５３と、契約書案作成部１５４と、署名依頼部１５５と、第１署名実行部１５６と、登録部１５７と、を備え、第２ノード２は、新旧鍵情報送信部２５１と、第２署名実行部２５２と、契約書案返信部２５３と、を備え、契約書案作成部１５４は、送付先の新公開鍵の順序をランダムで決定し、署名依頼部１５５および第１署名実行部１５６は、取引契約書案へ署名を行うノードの順番がランダムになるように、署名の依頼および実行をそれぞれ行うことを特徴とする、情報処理システム１００。【選択図】図２

Description

本発明は、暗号通貨などの取引に用いられる公開鍵を変更する情報処理システム、公開鍵の変更方法、プログラム、および情報処理システムの製造方法に関する。

暗号通貨などでは、取引契約書（トランザクション）がブロックチェーンに全て記載され、ブロックチェーンを構成する全ノードのユーザに公開される。したがって、原則として、どのユーザ（公開鍵）が、どのような取引を実施したのかが一目瞭然となる。

ブロックチェーン上では、ユーザは公開鍵（ビット列の識別子）としてしか表されないが、それでも取引を繰り返すうちに、実在のユーザ情報（名前や所在地など）と公開鍵が紐付いてしまうおそれがある。その場合、ユーザの匿名性を維持するためには、使用中の公開鍵を匿名で別の新しい公開鍵に変更することが求められる。

そのような匿名での公開鍵の変更が可能な暗号通貨としては、ＤＡＳＨ（旧名：ダークコイン）が知られている（例えば、非特許文献１）。ＤＡＳＨでは、一定以上の残高を保有するユーザ（マスターノード）が、不特定多数のユーザからのブロックチェーンへの取引登録（公開鍵変更）の依頼を複雑に合成することで、ブロックチェーン上における匿名での取引登録（公開鍵の変更）を実現している。

しかし、ＤＡＳＨにおける公開鍵の変更技術であっても、マスターノードにだけは、送金元（依頼元ユーザの変更前）の公開鍵（旧公開鍵）と送金先（変更後）の公開鍵（新公開鍵）との対応関係を把握されてしまうという問題がある。

これに対し、公開鍵の変更を実施する当人以外には、新旧公開鍵の対応関係を把握されることなく公開鍵の変更を可能とする暗号通貨として、モネロコインが知られている（例えば、非特許文献２）。

モネロコインの公開鍵変更技術では、以下の４つの要素技術が使用されている。
（１）複数の公開鍵から共同の電子署名を作成するリング署名技術。
（２）取引契約書に記載の送金額を準同型暗号技術により暗号化することで、ブロックチェーン上の各口座（公開鍵）残高をその口座所有者以外には秘匿化する技術。
（３）取引契約書（トランザクション）における真の送信元口座の暗号化された累積入金総額と、暗号化された送金総額が一致することを、第三者が復号することなく検証できるようにする技術。
（４）同じ口座からの２回目の送金をする取引契約書がブロックチェーンに登録されることを防ぐ技術。

具体的には、自身の公開鍵を匿名で交換したいユーザ（以下、交換実施者）が、ブロックチェーンに登録済みの取引契約書を閲覧して、ダミーとして用いる第三者の公開鍵情報（以下、第三者公開鍵Ａ，Ｂ，・・・，Ｚ）と各口座の暗号化された入金総額をそれぞれ取得する。なお、暗号化された入金総額は、準同型暗号技術の特性上，ブロックチェーンの情報から誰でも容易に取得可能であるが、その復号は困難である。次に、交換実施者は、公開鍵を交換するための取引契約書を以下のように作成する。

取引契約書の送金元口座情報においては、
・交換実施者の旧公開鍵と暗号化された入金総額
・第三者公開鍵Ａと暗号化された入金総額
・第三者公開鍵Ｂと暗号化された入金総額
・・・
・第三者公開鍵Ｚと暗号化された入金総額
を記載する。

また、取引契約書の送金先口座情報においては、
・手数料
・送金先である交換実施者の新公開鍵と暗号化された送金額（旧公開鍵の入金総額から手数料を引いた残額全額）
を記載する。

さらに、取引契約書に送金元の旧公開鍵に紐づく秘密鍵の識別情報を記載する。仮に、ブロックチェーンに既に同じの識別情報を含む取引契約書が登録済みの場合、今回の取引登録は拒否される。それにより、同じ口座（公開鍵）からの２度目の出金（２重支払い）を防止している。

最後に、この取引契約書（の記載内容）が正しいことを第三者に証明する電子署名がリング署名技術でなされることにより取引契約書が完成し、この取引契約書がブロックチェーンに登録されることにより、公開鍵の交換がなされる。

以上のように、モネロコインでは、（１）の技術により、送金元口座（公開鍵）に複数のダミー口座を含めることが可能になり、第三者に対して真の送金元を隠蔽できるようになる。さらに、（２）の技術のように送金額を暗号化して、ブロックチェーンの情報からは他人の口座残高の推移を分からなくすることで、第三者が送金元の各口座の残高の変化から当該取引契約書における真の送金元口座を推定できてしまうという問題を回避している。

一方、（１）と（２）の技術の副作用により、ブロックチェーンへの新規取引契約書の登録の役割を担う採掘者は、各口座の累積入金総額を把握できなくなる。その結果、採掘者は、取引契約書に記載の入力と出力の金額が釣り合うかどうかを検証できず、取引契約書がブロックチェーンに登録可能かどうかを判別できなくなる。

そこで、モネロコインでは、（３）の技術により、その取引契約書がブロックチェーンに登録可能かどうかを判別できるようにしている。ただし、当該取引契約書における真の送信元口座が過去に送金処理をしていた場合、採掘者達はその送金額を（暗号化されているために）正確に把握できないため、（３）の技術だけでは、当該取引契約書のブロックチェーンへの登録可否を判断できなくなる。その理由は、（３）の技術では、「暗号化された累積入金額」と「暗号化された取引額」が一致するかどうか判別可能であるが、「暗号化された累積入金額−累積出金額」と「暗号化された取引額」が一致するかどうかは判別不可能であるからである。

そこで、モネロコインでは、（４）の技術により、同じ口座からの出金は１回のみに限定している。それにより、ブロックチェーンに登録される取引契約書は常に「累積出金額が０」となるため、前述の問題を回避して、（３）の技術を有効に使えるようにしている。

"Whitepaper"、［online］、インターネット<URL: https://github.com/dashpay/dash/wiki/Whitepaper> Shen Noether、外２名、"Ring Confidential Transactions"、［online］、インターネット<URL: https://ledgerjournal.org/ojs/index.php/ledger/article/viewFile/34/61>

しかしながら、モネロコインでは、取引契約書において送金額を暗号化しているため、第三者は他人が所有する口座の残高をリアルタイムで把握できない。そのため、ユーザ毎の口座残高情報をサービス事業者が把握する必要がある応用サービスに、モネロコインを利用することは不可能である。つまり、モネロコインには、拡張性と発展性に乏しいという問題がある。

本発明は、上記問題を解決するためになされたものであって、第三者によるリアルタイムでの残高照会機能を有したまま、より匿名性の高い公開鍵変更を可能とする情報処理システムを提供することを課題とする。

本発明に係る情報処理システムは、
第１ノードと、公開鍵の変更支援サービスを提供する第２ノードと、データベースと、を備えた情報処理システムであって、
前記第１ノードは、
前記第１ノードの新公開鍵を作成する新公開鍵作成部と、
前記第２ノードから、少なくとも２つの異なる第２ノードを選択する第２ノード群選択部と、
前記選択された第２ノードの各々に対し、各自ノードの旧公開鍵および新公開鍵の情報を要求する新旧鍵情報要求部と、
前記第１ノードの前記旧公開鍵および前記第２ノードの各々から取得した前記旧公開鍵を送付元とし、前記第１ノードの前記新公開鍵および前記第２ノードの各々から取得した前記新公開鍵を送付先とする取引契約書案を作成する契約書案作成部と、
前記選択された第２ノードの各々に対し、前記取引契約書案の各自ノードに対応する箇所への署名を依頼する署名依頼部と、
前記取引契約書案の前記第１ノードに対応する箇所への署名を実行する第１署名実行部と、
全ての署名が完了した前記取引契約書案を、取引契約書として前記データベースに登録する登録部と、
を備え、
前記第２ノードは、
前記新旧鍵情報要求部からの前記要求に応じて、各自ノードの旧公開鍵および新公開鍵の情報を前記第１ノードに送信する新旧鍵情報送信部と、
前記署名依頼部からの前記依頼に応じて、前記取引契約書案における各自ノードの送付元および送付先の対応関係が妥当であるかを確認し、前記対応関係が妥当であった場合に、前記取引契約書案の各自ノードに対応する箇所への署名を実行する第２署名実行部と、
前記第２署名実行部によって署名された前記取引契約書案を前記第１ノードに返信する契約書案返信部と、
を備え、
前記契約書案作成部は、前記送付先の新公開鍵の順序をランダムで決定し、
前記署名依頼部および前記第１署名実行部は、前記取引契約書案へ署名を行うノードの順番がランダムになるように、前記署名の依頼および実行をそれぞれ行う。

本発明に係る公開鍵の変更方法は、
第１ノードと、公開鍵の変更支援サービスを提供する第２ノードと、データベースと、を備えた情報処理システムにおける公開鍵の変更方法であって、
前記第１ノードにおいて、新公開鍵を作成する新公開鍵作成ステップと、
前記第１ノードにおいて、前記第２ノードから、少なくとも２つの異なる第２ノードを選択する第２ノード群選択ステップと、
前記第１ノードにおいて、前記選択された第２ノードの各々に対し、各自ノードの旧公開鍵および新公開鍵の情報を要求する新旧鍵情報要求ステップと、
前記第２ノードにおいて、前記新旧鍵情報要求ステップの前記要求に応じて、各自ノードの旧公開鍵および新公開鍵の情報を前記第１ノードに送信する新旧鍵情報送信ステップと、
前記第１ノードにおいて、前記第１ノードの前記旧公開鍵および前記第２ノードの各々から取得した前記旧公開鍵を送付元とし、前記第１ノードの前記新公開鍵および前記第２ノードの各々から取得した前記新公開鍵を送付先とする取引契約書案を作成する契約書案作成ステップと、
前記第１ノードにおいて、前記選択された第２ノードの各々に対し、前記取引契約書案の各自ノードに対応する箇所への署名を依頼する署名依頼ステップと、
前記第２ノードにおいて、前記署名依頼ステップからの前記依頼に応じて、前記取引契約書案における各自ノードの送付元および送付先の対応関係が妥当であるかを確認し、前記対応関係が妥当であった場合に、前記取引契約書案の各自ノードに対応する箇所への署名を実行する第２署名実行ステップと、
前記第２ノードにおいて、前記第２署名実行ステップで署名された前記取引契約書案を前記第１ノードに返信する契約書案返信ステップと、
前記第１ノードにおいて、前記取引契約書案の前記第１ノードに対応する箇所への署名を実行する第１署名実行ステップと、
前記第１ノードにおいて、全ての署名が完了した前記取引契約書案を、取引契約書として前記データベースに登録する登録ステップと、
を有し、
前記契約書案作成ステップでは、前記送付先の新公開鍵の順序がランダムで決定され、
前記署名依頼ステップおよび前記第１署名実行ステップでは、前記取引契約書案へ署名を行うノードの順番がランダムになるように、前記署名の依頼および実行をそれぞれ行う。

本発明に係るプログラムは、
公開鍵の変更支援サービスを提供する第２ノード、およびデータベースに通信可能に接続された第１ノードの公開鍵の変更を支援するためのプログラムであって、
前記第１ノードの新公開鍵を作成する新公開鍵作成部、
前記第２ノードから、少なくとも２つの異なる第２ノードを選択する第２ノード群選択部、
前記選択された第２ノードの各々に対し、各自ノードの旧公開鍵および新公開鍵の情報を要求する新旧鍵情報要求部、
前記第１ノードの前記旧公開鍵および前記第２ノードの各々から取得した前記旧公開鍵を送付元とし、前記第１ノードの前記新公開鍵および前記第２ノードの各々から取得した前記新公開鍵を送付先とする取引契約書案を作成する契約書案作成部、
前記選択された第２ノードの各々に対し、前記取引契約書案の各自ノードに対応する箇所への署名を依頼する署名依頼部、
前記取引契約書案の前記第１ノードに対応する箇所への署名を実行する第１署名実行部、および、
全ての署名が完了した前記取引契約書案を、取引契約書として前記データベースに登録する登録部、
としてコンピュータを動作させ、
前記契約書案作成部は、前記送付先の新公開鍵の順序をランダムで決定し、
前記署名依頼部および前記第１署名実行部は、前記取引契約書案へ署名を行うノードの順番がランダムになるように、前記署名の依頼および実行をそれぞれ行う。

本発明に係る情報処理システムの製造方法は、
第１ノードと、公開鍵の変更支援サービスを提供する第２ノードと、データベースと、を備えた情報処理システムの製造方法であって、
前記第１ノードの新公開鍵を作成する新公開鍵作成部、
前記第２ノードから、少なくとも２つの異なる第２ノードを選択する第２ノード群選択部、
前記選択された第２ノードの各々に対し、各自ノードの旧公開鍵および新公開鍵の情報を要求する新旧鍵情報要求部、
前記第１ノードの前記旧公開鍵および前記第２ノードの各々から取得した前記旧公開鍵を送付元とし、前記第１ノードの前記新公開鍵および前記第２ノードの各々から取得した前記新公開鍵を送付先とする取引契約書案を作成する契約書案作成部、
前記選択された第２ノードの各々に対し、前記取引契約書案の各自ノードに対応する箇所への署名を依頼する署名依頼部、
前記取引契約書案の前記第１ノードに対応する箇所への署名を実行する第１署名実行部、および、
全ての署名が完了した前記取引契約書案を、取引契約書として前記データベースに登録する登録部、
としてコンピュータを動作させるためのプログラムを前記第１ノードに配信するステップと、
前記新旧鍵情報要求部からの前記要求に応じて、各自ノードの旧公開鍵および新公開鍵の情報を前記第１ノードに送信する新旧鍵情報送信部、
前記署名依頼部からの前記依頼に応じて、前記取引契約書案における各自ノードの送付元および送付先の対応関係が妥当であるかを確認し、前記対応関係が妥当であった場合に、前記取引契約書案の各自ノードに対応する箇所への署名を実行する第２署名実行部、および、
前記第２署名実行部によって署名された前記取引契約書案を前記第１ノードに返信する契約書案返信部、
としてコンピュータを動作させるためのプログラムを前記第２ノードに配信するステップと、
を有し、
前記契約書案作成部は、前記送付先の新公開鍵の順序をランダムで決定し、
前記署名依頼部および前記第１署名実行部は、前記取引契約書案へ署名を行うノードの順番がランダムになるように、前記署名の依頼および実行をそれぞれ行う。

前記データベースは、好ましくはブロックチェーンが用いられる。

本発明によれば、署名依頼部および第１署名実行部は、取引契約書案へ署名を行うノードの順番がランダムになるように、署名の依頼および実行をそれぞれ行うように設定されているため、第１ノードのユーザ以外の第三者は、第１ノードの旧公開鍵と新公開鍵との対応関係の推測が困難になる。また、モネロコインとは異なり、取引契約書において送金額を暗号化していないため、第三者は、他人が所有する口座の残高をリアルタイムで把握することができる。よって、第三者によるリアルタイムでの残高照会機能を有したまま、より匿名性の高い公開鍵変更が可能となる。

本発明の一実施形態に係る情報処理システムの概略図である。 第１ノードの構成を示す機能ブロックである。 第２ノードの構成を示す機能ブロックである。 情報処理システムにおいて、第１ノードの公開鍵の変更を行うための処理を示すシーケンスチャートである。 取引契約書案の具体例である。 （ａ）は、一方の第２ノードによって署名された取引契約書案であり、（ｂ）は、さらに第１ノードによって署名された取引契約書案であり、（ｃ）は、さらに他方の第２ノードによって署名され、署名が完了した取引契約書案である。

以下、本発明の実施形態について添付図面を参照して説明する。なお、本発明は、下記の実施形態に限定されるものではない。

（システム構成）
図１は、本発明の一実施形態に係る情報処理システム１００の概略図である。情報処理システム１００は、ブロックチェーン技術を利用したプラットフォームであり、第１ノード１と、第２ノード２と、ブロックチェーン３と、を備えている。第１ノード１、第２ノード２およびブロックチェーン３は、例えばインターネットなどの通信ネットワークＮを介して有線または無線により通信可能に接続されている。

第１ノード１は、公開鍵の交換を高い匿名性を維持しつつ実現するための第１プログラムがインストールされた情報処理装置である。第１ノード１は、デスクトップ型ＰＣ、ノート型ＰＣ、スマートフォン、タブレット端末、ＰＤＡなどの汎用のコンピュータで構成することができる。

第２ノード２は、公開鍵の変更支援サービス（以下、「鍵変更支援サービス」と称する）を提供する情報処理装置であり、第２ノード２には、鍵変更支援サービスを実現するための第２プログラムがインストールされている。なお、鍵変更支援サービスを提供するノードを中継ノードとも称する。

本発明の性質上、情報処理システム１００は、第２ノード２を少なくとも２つ備えている必要があり、好ましくは、第２ノード２を３つ以上備えている。実際には、第２ノード２は、手数料収入を目的に鍵変更支援サービスを行う事業者によって管理されていることが多いため、情報処理システム１００には多数の第２ノード２が存在している。

ブロックチェーン３は、情報処理システム１００に存在する全てのノード間で実施された取引契約書（トランザクション）群を一定時間毎に集約してブロック化して、各ブロックが直前ブロックとの連結条件を満たしていることを示す証拠情報を各ブロックに記載して、各ブロックをチェーン状に連結させたものである。ブロックチェーン３は、全てのトランザクションを記録しており、情報処理システム１００に存在する全てのノードによって分散管理されている。また、情報処理システム１００では、独自の暗号通貨による取引を発生させることができる。そのような暗号通貨の例として、ビットコイン（Bitcoin）やイーサリアム（Ethereum）などが挙げられるが、本実施形態では、暗号通貨がビットコインであるものとする。

なお、情報処理システム１００は、第１ノード１および第２ノード２以外のノード、すなわち、第１プログラムおよび第２プログラムのいずれもがインストールされていないノードを含むことができる。

（各ノードの構成）
図２は、第１ノード１の構成を示す機能ブロックであり、図３は、第２ノード２の構成を示す機能ブロックである。

図２に示すように、第１ノード１は、入力部１１と、表示部１２と、通信部１３と、記憶部１４と、制御部１５と、を備えている。

入力部１１は、例えばキーボード、マウスまたはタッチパネルで構成することができ、表示部１２は、例えば液晶ディスプレイや有機ＥＬディスプレイで構成することができる。通信部１３は、第１ノード１が通信ネットワークＮを介して他のノード等と通信を行うためのインターフェースである。

記憶部１４は、第１ノード１で用いられる各種プログラムやデータを記憶するための不揮発性の補助記憶装置であり、例えばハードディスクドライブ（ＨＤＤ）やソリッドステートドライブ（ＳＳＤ）で構成することができる。

記憶部１４には、本実施形態に係る第１プログラムＰ１および第１鍵情報Ｋ１が記憶されている。第１プログラムＰ１は、情報処理システム１００において提供される鍵変更支援サービスの処理の一部を第１ノード１に実行させるためのプログラムである。第１プログラムＰ１を第１ノード１に配信する方法は特に限定されず、通信ネットワークＮを介して第１プログラムＰ１を第１ノード１にダウンロードしてもよいし、コンピュータ読み取り可能な非一時的な記録媒体に第１プログラムＰ１を記録しておき、当該記憶媒体を介して第１プログラムＰ１を第１ノード１にインストールしてもよい。例えば、第１ノード１がスマートフォンである場合、Ａｐｐｌｅ社のＡｐｐＳｔｏｒｅ（登録商標）やＧｏｏｇｌｅ社のＧｏｏｇｌｅＰｌａｙ（登録商標）などを介して、第１プログラムＰ１を第１ノード１に配信することができる。

第１鍵情報Ｋ１は、第１ノード１が情報処理システム１００における取引に用いる公開鍵の情報である。具体的には、第１鍵情報Ｋ１には、第１ノード１で現在用いられている公開鍵およびこれに紐づく秘密鍵のペア群が含まれている。なお、秘密鍵については、第１ノード１以外に保存してもよい。

制御部１５は、第１ノード１が備えるＣＰＵやＭＰＵなどの演算処理装置が、記憶部１４に記憶されている第１プログラムＰ１をＲＡＭなどの主記憶装置に読み出して実行することにより実現される機能ブロックである。制御部１５は、新公開鍵作成部１５１と、第２ノード群選択部１５２と、新旧鍵情報要求部１５３と、契約書案作成部１５４と、署名依頼部１５５と、第１署名実行部１５６と、登録部１５７と、を備えている。これらの各部の機能については、後述する。

図３に示すように、第２ノード２は、入力部２１と、表示部２２と、通信部２３と、記憶部２４と、制御部２５と、を備えている。入力部２１、表示部２２、通信部２３および記憶部２４はそれぞれ、第１ノード１の入力部１１、表示部１２、通信部１３および記憶部１４と同様に構成することができる。

記憶部２４には、本実施形態に係る第２プログラムＰ２および第２鍵情報Ｋ２が記憶されている。第２プログラムＰ２は、情報処理システム１００において提供される鍵変更支援サービスの処理の一部を第２ノード２に実行させるためのプログラムである。第２プログラムＰ２を第２ノード２に配信する方法は特に限定されず、通信ネットワークＮを介して第２プログラムＰ２を第２ノード２にダウンロードしてもよいし、コンピュータ読み取り可能な非一時的な記録媒体に第２プログラムＰ２を記録しておき、当該記憶媒体を介して第２プログラムＰ２を第２ノード２にインストールしてもよい。

第２鍵情報Ｋ２は、第２ノード２が情報処理システム１００における取引に用いる公開鍵の情報である。具体的には、第２鍵情報Ｋ２には、第２ノード２で現在用いられている公開鍵およびこれに紐づく秘密鍵のペア群が含まれている。なお、秘密鍵については、第２ノード２以外に保存してもよい。

制御部２５は、第２ノード２が備えるＣＰＵやＭＰＵなどの演算処理装置が、記憶部２４に記憶されている第２プログラムＰ２をＲＡＭなどの主記憶装置に読み出して実行することにより実現される機能ブロックである。制御部２５は、新旧鍵情報送信部２５１と、第２署名実行部２５２と、契約書案返信部２５３と、を備えている。これらの各部の機能については、後述する。

（処理手順）
図４は、情報処理システム１００において、第１ノード１の公開鍵の変更を行うための処理を示すシーケンスチャートである。図４においてノード間の通信を示す矢印について、実線矢印はブロードキャストを示し、破線矢印は送信元を匿名化と通信路の暗号化を実施した匿名暗号通信を示している。なお、各処理における通信の形態は上記に限定されない。

本実施形態では、図２および図３にそれぞれ示す第１ノード１の制御部１５および第２ノード２の制御部２５によって図４の主な処理が実行される。なお、図４の処理の一部を、ユーザが第１ノード１の入力部１１または第２ノードの入力部２１を介して操作することによりマニュアルで行ってもよい。

まず、第１ノード１において、新公開鍵作成部１５１が、第１ノード１の旧公開鍵に対応する新公開鍵を作成する（ステップＳ１、新公開鍵作成ステップ）。旧公開鍵とは、鍵変更支援サービスの利用開始時において、第１ノード１が所有している公開鍵であって、ユーザが変更を所望している公開鍵を意味する。新公開鍵とは、旧公開鍵の代わりとなる新たな公開鍵である。

公開鍵の変更処理では、通常、複数の旧公開鍵を複数の新公開鍵に変更することが多いが、説明の便宜上、本実施形態では、１つの旧公開鍵を１つの新公開鍵に変更する例について説明する。旧公開鍵をＰＫｏ［Ｕ］とし、新公開鍵をＰＫｎ［Ｕ］とする。また、旧公開鍵に対応する通貨金額（旧公開鍵の残高）は１．５ＢＴＣであるとする。新公開鍵が作成されると、新公開鍵の情報が記憶部１４に記憶され、第１鍵情報Ｋ１が更新される。

続いて、第１ノード１の第２ノード群選択部１５２が、情報処理システム１００に設けられている多数の第２ノード２から、少なくとも２つの異なる第２ノード２を選択する（ステップＳ２、第２ノード群選択ステップ）。第２ノード２の選択基準は特に限定されないが、第２ノード群選択部１５２は、情報処理システム１００に関する最新情報を収集・取得して、例えば信頼性の高い鍵変更支援サービスを提供している第２ノード２を選択する。

本実施形態では、第２ノード群選択部１５２は２つの第２ノード２を選択する。図４にでは、選択された第２ノード２の一方を第２ノード２Ａとし、他方を第２ノード２Ｂとする。

なお、ステップＳ１およびステップＳ２の順序は逆でもよい。

続いて、第１ノード１の新旧鍵情報要求部１５３が、選択された第２ノード２Ａ，２Ｂの各々に対し、鍵変更支援のための各自ノードの旧公開鍵および当該旧公開鍵に対応する新公開鍵の情報を要求する（ステップＳ３，Ｓ５、新旧鍵情報要求ステップ）。具体的には、新旧鍵情報要求部１５３は、第２ノード２Ａに対し、第２ノード２Ａの旧公開鍵およびこれに対応する新公開鍵の情報を要求し（ステップＳ３）、第２ノード２Ｂに対し、第２ノード２Ｂの旧公開鍵およびこれに対応する新公開鍵の情報を要求する（ステップＳ５）。１つの第２ノード２に対し要求する旧公開鍵および新公開鍵のペア数は特に限定されないが、本実施形態では、新旧鍵情報要求部１５３は、第２ノード２Ａ，２Ｂの各々に対し、１つの旧公開鍵および新公開鍵のペアの情報を要求する。

第２ノード２では、新旧鍵情報送信部２５１が、新旧鍵情報要求部１５３からの要求に応じて、各自ノードの旧公開鍵および新公開鍵の情報を第１ノード１に送信する（ステップＳ４，Ｓ６、新旧鍵情報送信ステップ）。具体的には、第２ノード２Ａの新旧鍵情報送信部２５１は、第２ノード２Ａの旧公開鍵および新公開鍵の情報を第１ノード１に送信し（ステップＳ４）、第２ノード２Ｂの新旧鍵情報送信部２５１は、第２ノード２Ｂの旧公開鍵および新公開鍵の情報を第１ノード１に送信する（ステップＳ６）。

第２ノード２の新旧鍵情報送信部２５１は、新旧鍵情報要求部１５３からの要求を受信する度に、旧公開鍵および新公開鍵のペアを作成して、作成した旧公開鍵および新公開鍵の情報を第１ノード１に返送してもよい。あるいは、第２ノード２の記憶部２４に記憶されている第２鍵情報Ｋ２に、鍵変更支援サービスのために旧公開鍵および新公開鍵のペアをあらかじめ多数用意しておき、新旧鍵情報要求部１５３からの要求を受信した場合に、新旧鍵情報送信部２５１が用意された旧公開鍵および新公開鍵のペアから１つのペアを選択し、選択したペアの情報を第１ノード１に返送してもよい。

なお、本実施形態では、第２ノード２Ａから返送（取得）された旧公開鍵をＰＫｏ［Ａ］とし、新公開鍵をＰＫｎ［Ａ］とする。また、第２ノード２Ｂから返送（取得）された旧公開鍵をＰＫｏ［Ｂ］とし、新公開鍵をＰＫｎ［Ｂ］とする。

続いて、第１ノード１において、契約書案作成部１５４が、第１ノード１の旧公開鍵および第２ノード２Ａ，２Ｂの各々から取得した旧公開鍵を送付元とし、第１ノード１の新公開鍵および第２ノード２Ａ，２Ｂの各々から取得した新公開鍵を送付先とする取引契約書（トランザクション）案を作成する（ステップＳ７，Ｓ８，Ｓ９、契約書案作成ステップ）。

具体的には、ステップＳ７において、契約書案作成部１５４は、第２ノード２Ａ，２Ｂから取得された旧公開鍵ＰＫｏ［Ａ］，ＰＫｏ［Ｂ］の残高をブロックチェーン３にアクセスして照会する。これにより、ステップＳ８において、残高情報を確認することができる。本実施形態では、旧公開鍵ＰＫｏ［Ａ］，ＰＫｏ［Ｂ］の残高は、いずれも１．０ＢＴＣであるとする。なお、第１ノード１とブロックチェーン３との通信形態は、非暗号通信、非匿名暗号通信またはブロードキャストであってもよい。

続いて、ステップＳ９において、契約書案作成部１５４は、第１ノード１の旧公開鍵および第２ノード２Ａ，２Ｂから取得した旧公開鍵の３つの旧公開鍵、第１ノード１の新公開鍵および第２ノード２Ａ，２Ｂから取得した新公開鍵の３つの新公開鍵、ならびに、各旧公開鍵の残高に基づき、取引契約書案を作成する。取引契約書案の具体例を図５に示す。

取引契約書案では、左側から順に署名（Ｓｉｇｎ）、送付元（ＩＮ）および送付先（ＯＵＴ）の各表示領域が設けられており、右上に、有効期限の表示領域が設けられている。送付元には、３つの旧公開鍵およびこれに対応する通貨金額（残高）が記載され、送付先には、３つの新公開鍵およびこれに対応する通貨金額（送金額）が記載される。

本実施形態では、第２ノード２Ａ，２Ｂは、鍵交換支援サービスの手数料をいずれも０．１ＢＴＣと設定しているものとする。また、ブロックチェーン３への登録手数料（Ｆｅｅ）が０．２ＢＴＣであるとする。そのため、第２ノード２Ａ，２Ｂの新公開鍵ＰＫｎ［Ａ］，ＰＫｎ［Ｂ］の通貨金額は、いずれも１．１ＢＴＣとなる。また、ブロックチェーン３への登録手数料は、通常は鍵交換の依頼者である第１ノード１のユーザの負担である。そのため、第１ノード１の新公開鍵ＰＫｎ［Ｕ］の通貨金額は、１．５−０．１×２−０．２＝１．１ＢＴＣとなる。

ここで、取引契約書に記載される送付元の旧公開鍵群および送付先の新公開鍵群の順序関係に規則性がある場合を考える。例えば、送付先の新公開鍵の順序が、旧公開鍵とそれに対応する規則性を有する場合、送付元に旧公開鍵がＰＫｏ［Ｕ］，ＰＫｏ［Ａ］，ＰＫｏ［Ｂ］の順で記載されると、送付先の新公開鍵はＰＫｎ［Ｕ］，ＰＫｎ［Ａ］，ＰＫｎ［Ｂ］の順で記載される。この場合、その規則性が第三者に漏洩することで、取引契約書の記載内容から、新旧の公開鍵の対応関係も、第三者に漏洩してしまう危険性が生じる。

これに対し本実施形態では、契約書案作成部１５４は、送付先の新公開鍵の順序をランダムで決定することで、送付元の旧公開鍵の順序と送付先の進行鍵の順序の対応関係をランダムにする。

旧公開鍵および新公開鍵は、実際は不規則な文字列で構成されている。そのため、図５に示す取引契約書案が取引契約書としてブロックチェーン３に登録された場合、取引契約書は誰でも確認することができるようになるが、第１ノード１のユーザ以外の第三者は、旧公開鍵ＰＫｏ［Ｕ］，ＰＫｏ［Ａ］，ＰＫｏ［Ｂ］と新公開鍵ＰＫｎ［Ｕ］，ＰＫｎ［Ａ］，ＰＫｎ［Ｂ］との対応関係を特定することはできない。また、第２ノード２Ａのユーザは、自身の旧公開鍵ＰＫｏ［Ａ］と新公開鍵ＰＫｎ［Ａ］を特定することはできるが、それ以外の旧公開鍵ＰＫｏ［Ｕ］，ＰＫｏ［Ｂ］と新公開鍵ＰＫｎ［Ｕ］，ＰＫｎ［Ｂ］との対応関係を特定することはできない。同様に、第２ノード２Ｂのユーザは、自身の旧公開鍵ＰＫｏ［Ｂ］と新公開鍵ＰＫｎ［Ｂ］を特定することはできるが、それ以外の旧公開鍵ＰＫｏ［Ｕ］，ＰＫｏ［Ａ］と新公開鍵ＰＫｎ［Ｕ］，ＰＫｎ［Ａ］との対応関係を特定することはできない。すなわち、鍵交換支援サービスを提供する第２ノード２Ａ，２Ｂのユーザであっても、取引契約書案に基づいて第１ノード１の旧公開鍵ＰＫｏ［Ｕ］および新公開鍵ＰＫｎ［Ｕ］を特定することはできない。よって、従来技術のように、鍵変更支援サービスを行うマスターノードに、鍵交換依頼者の旧公開鍵と新公開鍵との対応関係を把握されるといった問題が生じることはなく、より匿名性の高い公開鍵の変更が可能となる。

ただし、取引契約書案をブロックチェーン３に登録するためには、取引に関わる全てのノードによる電子署名が必要となる。そのため、第１ノード１では、署名依頼部１５５が、選択された第２ノード２Ａ，２Ｂの各々に対し、取引契約書案の各自ノードの旧公開鍵に対応する箇所への署名を依頼するとともに（ステップＳ１０，Ｓ１４、署名依頼ステップ）、第１署名実行部１５６が、取引契約書案の第１ノード１に対応する箇所への署名を実行する（ステップＳ１３、第１署名実行ステップ）。

具体的には、第１ノード１において、取引契約書案の署名欄への署名順序をランダムに決定する。本実施形態では、第２ノード２Ａ、第１ノード１、第２ノード２Ｂの順に決定されたものとする。

まず、ステップＳ１０において、署名依頼部１５５が、第２ノード２Ａに対し、取引契約書案を送信し、取引契約書案の第２ノード２Ａの旧公開鍵に対応する箇所への署名を依頼する。第２ノード２Ａでは、第２署名実行部２５２が、署名依頼部１５５からの依頼に応じて、取引契約書案における各自ノードの送付元および送付先の対応関係が妥当であるかを確認し、対応関係が妥当であった場合に、取引契約書案の各自ノードの旧公開鍵に対応する箇所への署名を実行する（ステップＳ１１、第２署名実行ステップ）。本実施形態では、第２ノード２Ａの鍵交換支援サービスの最低手数料が０．１ＢＴＣであるため、第２署名実行部２５２は、取引契約書案において、送付先に記載されている新公開鍵ＰＫｎ［Ａ］に対応する通貨金額（送金額）から、送付元に記載されている旧公開鍵ＰＫｏ［Ａ］に対応する通貨金額（残高）を差し引いた金額が０．１ＢＴＣ以上である場合に、各自ノードの送付元および送付先の対応関係が妥当であると判断し、図６（ａ）に示すように、旧公開鍵ＰＫｏ［Ａ］に対応する署名欄に署名する。

その後、第２ノード２Ａの契約書案返信部２５３は、第２署名実行部２５２によって署名された取引契約書案を第１ノード１に返信する（ステップＳ１２、契約書案返信ステップ）。

続いて、第１ノード１の第１署名実行部１５６が、返信された取引契約書案の第１ノード１の旧公開鍵に対応する箇所への署名を実行する（ステップＳ１３）。これにより、図６（ｂ）に示すように、取引契約書案の旧公開鍵ＰＫｏ［Ｕ］に対応する署名欄に署名される。

続いて、第１ノード１の署名依頼部１５５が、第２ノード２Ｂに対し、取引契約書案を送信し、取引契約書案の第２ノード２Ａの旧公開鍵に対応する箇所への署名を依頼する（ステップＳ１４）。第２ノード２Ｂでは、第２署名実行部２５２が、署名依頼部１５５からの依頼に応じて、取引契約書案における各自ノードの送付元および送付先の対応関係が妥当であるかを確認し、対応関係が妥当であった場合に、取引契約書案の各自ノードの旧公開鍵に対応する箇所への署名を実行する（ステップＳ１５、第２署名実行ステップ）。本実施形態では、第２ノード２Ｂの鍵交換支援サービスの最低手数料が、第２ノード２Ａと同じく０．１ＢＴＣであるため、第２署名実行部２５２は、取引契約書案において、送付先に記載されている新公開鍵ＰＫｎ［Ｂ］に対応する通貨金額（送金額）から、送付元に記載されている旧公開鍵ＰＫｏ［Ｂ］に対応する通貨金額（残高）を差し引いた金額が０．１ＢＴＣ以上である場合に、各自ノードの送付元および送付先の対応関係が妥当であると判断し、図６（ｃ）に示すように、旧公開鍵ＰＫｏ［Ｂ］に対応する署名欄に署名する。これにより、取引契約書案への全ての署名が完了する。

その後、第２ノード２Ｂの契約書案返信部２５３は、第２署名実行部２５２によって署名された取引契約書案を第１ノード１に返信する（ステップＳ１６、契約書案返信ステップ）。

続いて、第１ノード１の登録部１５７は、全ての署名が完了した取引契約書案を、取引契約書としてブロックチェーン３に登録する（ステップＳ１７、登録ステップ）。より詳細には、取引契約書が採掘者達によって承認され、取引契約書に記載された有効期限までにブロックチェーン３に追加されると、取引契約書の登録が完了する（ステップＳ１８）。第１ノード１を含む全てのノードは、ブロックチェーン３に照会することにより（ステップＳ１９）、登録された取引契約書を確認することができる（ステップＳ２０）。

以上のように、取引契約書がブロックチェーン３に登録されることにより、第１ノード１（および第２ノード２Ａ，２Ｂ）の公開鍵の変更（ＰＫｏ［Ｕ］→ＰＫｎ［Ｕ］）が完了する。上述のように、第１ノード１のユーザ以外の第三者は、ブロックチェーン３に登録された取引契約書（＝取引契約書案）を参照しても、第１ノード１の旧公開鍵ＰＫｏ［Ｕ］に対応する新公開鍵ＰＫｎ［Ｕ］を特定することはできない。

なお、第２ノード２Ａ，２Ｂの旧公開鍵と新公開鍵との対応関係は、第１ノード１には把握されているが、通常、第２ノード２Ａ，２Ｂは、鍵変更支援サービスを提供する業者であるため、サービスに供される公開鍵がノード情報と関連付けられても問題はない。

本実施形態では、鍵交換の匿名性をさらに高めるために、以下の処理を行っている。

上述のように、本実施形態では、取引契約書案への署名を、第２ノード２Ａ、第１ノード１、第２ノード２Ｂの順に行っているが、第１ノード１が公開鍵の交換を複数回行う場合に、取引契約書案へ署名を行うノードの順番に規則性があると、その規則性が第三者に漏洩することで、取引契約書の記載内容から、新旧の公開鍵の対応関係が、その規則性を知る第三者に推測されてしまう危険性が生じる。

そのため、署名依頼部１５５および第１署名実行部１５６は、取引契約書案へ署名を行うノードの順番がランダムになるように、署名の依頼および実行をそれぞれ行うように設定されている。例えば、取引契約書案へ署名を行うノードが、第１ノード１、第２ノード２Ａおよび第２ノード２Ｂの３つである場合、署名を行う順番は６通りあるが、署名依頼部１５５および第１署名実行部１５６は、公開鍵交換のたびに、６通りの順番の中からランダムに順番を選択する。これにより、第１ノード１のユーザ以外の第三者は、第１ノード１の旧公開鍵と新公開鍵との対応関係の推測が困難になる。

また本実施形態では、モネロコインとは異なり、取引契約書において送金額を暗号化していないため、第三者は、他人が所有する口座の残高をリアルタイムで把握することができる。よって、第三者によるリアルタイムでの残高照会機能を有したまま、より匿名性の高い公開鍵変更が可能となる。

また、取引契約書案に記載されている旧公開鍵または新公開鍵の残高のばらつきが大きい場合、残高の傾向に基づいて、旧公開鍵と新公開鍵との対応関係が推測しやすくなる。そのため、取引契約書案に記載されている旧公開鍵と新公開鍵の残高のばらつきを少なくすることが好ましい。すなわち、第１ノード１の新旧鍵情報要求部１５３は、取引契約書案の送付元および送付先における、各公開鍵に対応する残高の最大値に対する最小値の比率が１に近くなるように、残高の範囲を指定して新旧鍵情報を第２ノード２に要求することが好ましい。例えば、新旧鍵情報要求部１５３は、第１ノード１の旧公開鍵の残高の１／２から２倍の残高の旧公開鍵の新旧鍵情報を、第２ノード２に要求する。

図５に示す取引契約書案では、送付元に記載されている旧公開鍵の残高の最大値に対する最小値の比率が２／３と比較的１に近い（ばらつきが少ない）。そのため、送付先に記載されている新公開鍵の残高の最大値に対する最小値の比率も１と等しくすることが可能であり、どの新公開鍵が第１ノード１の新公開鍵であるのかを特定できない。

このように、取引契約書案に記載されている旧公開鍵と新公開鍵の残高のばらつきを少なくすることで、鍵交換の匿名性をさらに高めることができる。

（付記事項）
以上、本発明の実施形態について説明したが、本発明は上記実施形態に限定されるものではなく、その趣旨を逸脱しない限りにおいて、種々の変更が可能である。

上記実施形態では、１つの旧公開鍵を１つの新公開鍵に変更する例について説明したが、１度に変更する旧公開鍵の数は、特に限定されない。１度に変更する旧公開鍵が多いほど、取引契約書案において、旧公開鍵と新公開鍵との対応関係が複雑になるため、鍵交換の匿名性が高くなる。

同様に、上記実施形態では、第２ノード２の各々が第１ノード１に返送する旧公開鍵および新公開鍵のペア数が１であったが、ペア数は特に限定されない。ペア数が多くなるほど、取引契約書案において、旧公開鍵と新公開鍵との対応関係が複雑になるため、鍵交換の匿名性が高くなる。

また、上記実施形態では、第２ノード群選択部１５２が選択する第２ノード２は２つであったが、３つ以上の第２ノード２を選択してもよい。第２ノード群選択部１５２が選択する第２ノード２の数が大きくなるほど、取引契約書案において記載される旧公開鍵と新公開鍵との対応関係が複雑になるため、鍵交換の匿名性が高くなる。しかし、第２ノード群選択部１５２が選択する第２ノード２が多くなるほど、第１ノード１が負担する鍵交換支援サービスの手数料が増加する。そのため、一度の公開鍵交換において選択される第２ノード２の数は、費用対効果を勘案して決定することが好ましい。

なお、第２ノード２の鍵交換サービスの手数料は特に限定されず、第２ノード２が無料で鍵交換サービスを提供する形態も本発明に含まれる。

また、上記実施形態では、情報処理システムがブロックチェーン技術を利用したプラットフォームであったが、本発明はこれに限定されず、通常のサーバ・クライアントシステムであってもよい。この場合、取引契約書は、ブロックチェーンの代わりに、サーバ等に設けられるデータベースに登録される。

１ 第１ノード
２ 第２ノード
２Ａ 第２ノード
２Ｂ 第２ノード
３ ブロックチェーン
１１ 入力部
１２ 表示部
１３ 通信部
１４ 記憶部
１５ 制御部
１５１ 新公開鍵作成部
１５２ 第２ノード群選択部
１５３ 新旧鍵情報要求部
１５４ 契約書案作成部
１５５ 署名依頼部
１５６ 第１署名実行部
１５７ 登録部
２１ 入力部
２２ 表示部
２３ 通信部
２４ 記憶部
２５ 制御部
２５１ 新旧鍵情報送信部
２５２ 第２署名実行部
２５３ 契約書案返信部
１００ 情報処理システム
Ｋ１ 第１鍵情報
Ｋ２ 第２鍵情報
Ｎ 通信ネットワーク
Ｐ１ 第１プログラム
Ｐ２ 第２プログラム
ＰＫｎ 新公開鍵
ＰＫｏ 旧公開鍵

Claims (6)

1. 第１ノードと、公開鍵の変更支援サービスを提供する第２ノードと、データベースと、を備えた情報処理システムであって、
   前記第１ノードは、
   前記第１ノードの新公開鍵を作成する新公開鍵作成部と、
   前記第２ノードから、少なくとも２つの異なる第２ノードを選択する第２ノード群選択部と、
   前記選択された第２ノードの各々に対し、各自ノードの旧公開鍵および新公開鍵の情報を要求する新旧鍵情報要求部と、
   前記第１ノードの前記旧公開鍵および前記第２ノードの各々から取得した前記旧公開鍵を送付元とし、前記第１ノードの前記新公開鍵および前記第２ノードの各々から取得した前記新公開鍵を送付先とする取引契約書案を作成する契約書案作成部と、
   前記選択された第２ノードの各々に対し、前記取引契約書案の各自ノードに対応する箇所への署名を依頼する署名依頼部と、
   前記取引契約書案の前記第１ノードに対応する箇所への署名を実行する第１署名実行部と、
   全ての署名が完了した前記取引契約書案を、取引契約書として前記データベースに登録する登録部と、
   を備え、
   前記第２ノードは、
   前記新旧鍵情報要求部からの前記要求に応じて、各自ノードの旧公開鍵および新公開鍵の情報を前記第１ノードに送信する新旧鍵情報送信部と、
   前記署名依頼部からの前記依頼に応じて、前記取引契約書案における各自ノードの送付元および送付先の対応関係が妥当であるかを確認し、前記対応関係が妥当であった場合に、前記取引契約書案の各自ノードに対応する箇所への署名を実行する第２署名実行部と、
   前記第２署名実行部によって署名された前記取引契約書案を前記第１ノードに返信する契約書案返信部と、
   を備え、
   前記契約書案作成部は、前記送付先の新公開鍵の順序をランダムで決定し、
   前記署名依頼部および前記第１署名実行部は、前記取引契約書案へ署名を行うノードの順番がランダムになるように、前記署名の依頼および実行をそれぞれ行うことを特徴とする、情報処理システム。
2. 前記データベースは、ブロックチェーンであることを特徴とする、請求項１に記載の情報処理システム。
3. 第１ノードと、公開鍵の変更支援サービスを提供する第２ノードと、データベースと、を備えた情報処理システムにおける公開鍵の変更方法であって、
   前記第１ノードにおいて、新公開鍵を作成する新公開鍵作成ステップと、
   前記第１ノードにおいて、前記第２ノードから、少なくとも２つの異なる第２ノードを選択する第２ノード群選択ステップと、
   前記第１ノードにおいて、前記選択された第２ノードの各々に対し、各自ノードの旧公開鍵および新公開鍵の情報を要求する新旧鍵情報要求ステップと、
   前記第２ノードにおいて、前記新旧鍵情報要求ステップの前記要求に応じて、各自ノードの旧公開鍵および新公開鍵の情報を前記第１ノードに送信する新旧鍵情報送信ステップと、
   前記第１ノードにおいて、前記第１ノードの前記旧公開鍵および前記第２ノードの各々から取得した前記旧公開鍵を送付元とし、前記第１ノードの前記新公開鍵および前記第２ノードの各々から取得した前記新公開鍵を送付先とする取引契約書案を作成する契約書案作成ステップと、
   前記第１ノードにおいて、前記選択された第２ノードの各々に対し、前記取引契約書案の各自ノードに対応する箇所への署名を依頼する署名依頼ステップと、
   前記第２ノードにおいて、前記署名依頼ステップからの前記依頼に応じて、前記取引契約書案における各自ノードの送付元および送付先の対応関係が妥当であるかを確認し、前記対応関係が妥当であった場合に、前記取引契約書案の各自ノードに対応する箇所への署名を実行する第２署名実行ステップと、
   前記第２ノードにおいて、前記第２署名実行ステップで署名された前記取引契約書案を前記第１ノードに返信する契約書案返信ステップと、
   前記第１ノードにおいて、前記取引契約書案の前記第１ノードに対応する箇所への署名を実行する第１署名実行ステップと、
   前記第１ノードにおいて、全ての署名が完了した前記取引契約書案を、取引契約書として前記データベースに登録する登録ステップと、
   を有し、
   前記契約書案作成ステップでは、前記送付先の新公開鍵の順序がランダムで決定され、
   前記署名依頼ステップおよび前記第１署名実行ステップでは、前記取引契約書案へ署名を行うノードの順番がランダムになるように、前記署名の依頼および実行をそれぞれ行うことを特徴とする、公開鍵の変更方法。
4. 前記データベースは、ブロックチェーンであることを特徴とする、請求項３に記載の公開鍵の変更方法。
5. 公開鍵の変更支援サービスを提供する第２ノード、およびデータベースに通信可能に接続された第１ノードの公開鍵の変更を支援するためのプログラムであって、
   前記第１ノードの新公開鍵を作成する新公開鍵作成部、
   前記第２ノードから、少なくとも２つの異なる第２ノードを選択する第２ノード群選択部、
   前記選択された第２ノードの各々に対し、各自ノードの旧公開鍵および新公開鍵の情報を要求する新旧鍵情報要求部、
   前記第１ノードの前記旧公開鍵および前記第２ノードの各々から取得した前記旧公開鍵を送付元とし、前記第１ノードの前記新公開鍵および前記第２ノードの各々から取得した前記新公開鍵を送付先とする取引契約書案を作成する契約書案作成部、
   前記選択された第２ノードの各々に対し、前記取引契約書案の各自ノードに対応する箇所への署名を依頼する署名依頼部、
   前記取引契約書案の前記第１ノードに対応する箇所への署名を実行する第１署名実行部、および、
   全ての署名が完了した前記取引契約書案を、取引契約書として前記データベースに登録する登録部、
   としてコンピュータを動作させ、
   前記契約書案作成部は、前記送付先の新公開鍵の順序をランダムで決定し、
   前記署名依頼部および前記第１署名実行部は、前記取引契約書案へ署名を行うノードの順番がランダムになるように、前記署名の依頼および実行をそれぞれ行うことを特徴とする、プログラム。
6. 前記データベースは、ブロックチェーンであることを特徴とする、請求項５に記載のプログラム。

Images