JP2019212241A - 情報処理装置、情報処理方法、プログラム及び取引システム - Google Patents

Abstract

【課題】差金決済を伴う取引を、中央管理者を不要として行うことができる情報処理装置等を提供する。【解決手段】情報処理装置２は、取引の条件を設定する設定部と、取引の条件に基づき、ユーザ及び相手方が仮想通貨をデポジットした第１トランザクションを生成する第１生成部と、第１トランザクションを出力する第１出力部と、中立者から公開鍵を取得する第１取得部と、公開鍵を用いて、デポジットされた仮想通貨をスポットレートに応じて配分する第２トランザクションを生成する第２生成部と、決定時点を経過した場合、決定時点のスポットレートと、中立者の電子署名とを取得する第２取得部と、スポットレートに対応する第２トランザクションを出力する第２出力部と、中立者の電子署名を用いて、ユーザに配分された仮想通貨を送金する第３トランザクションを生成する第３生成部と、第３トランザクションを出力する第３出力部とを備えることを特徴とする。【選択図】図１

Description

本発明は、情報処理装置、情報処理方法、プログラム及び取引システムに関する。

外国為替等の取引を行う場合において、ＮＤＦ（Non-Deliverable Forward）取引のように、外貨等の現物の受け渡しを行わず、価格変動に応じた差金決済を行う取引手法がある。例えば特許文献１では、銀行が顧客から外国為替予約の申込を受け付け、ＮＤＦ取引に係る差金決済、送金等を行う為替変動リスクヘッジ方法が開示されている。

特開２００３−９９６２１号公報

しかしながら、特許文献１に係る発明では銀行等の金融機関が顧客間に介在して差金決済を行っており、すなわち、中央管理者が必要となる。

一つの側面では、差金決済を伴う取引を、中央管理者を不要として行うことができる情報処理装置等を提供することを目的とする。

一つの側面では、情報処理装置は、差金決済を伴う取引の条件であって、経時的に取引レートが変動する取引対象について、ユーザ及び相手方の間で取り決めた前記取引対象の契約レートと、差金決済を行う前記取引レートの決定時点と、想定元本とを含む取引条件を設定する設定部と、前記取引条件に基づき、前記ユーザ及び相手方夫々が所定額の仮想通貨をデポジットした第１トランザクションを生成する第１生成部と、前記第１トランザクションを、前記仮想通貨のトランザクションデータを分散して管理する各ノードに出力する第１出力部と、前記相手方と異なる中立者から、該中立者の秘密鍵に基づき生成された公開鍵を取得する第１取得部と、取得した前記中立者の公開鍵を用いて、前記第１トランザクションでデポジットされた前記仮想通貨を、複数の前記取引レート夫々に応じて前記ユーザ及び相手方に配分する複数の第２トランザクションを生成する第２生成部と、前記決定時点を経過した場合、該決定時点の前記取引レートと、該取引レートから前記中立者の秘密鍵に基づき生成された電子署名とを取得する第２取得部と、取得した前記取引レートに対応する前記第２トランザクションを前記各ノードに出力する第２出力部と、前記中立者の電子署名を用いて、前記第２トランザクションで前記ユーザに配分された前記仮想通貨を前記ユーザ宛に送金する第３トランザクションを生成する第３生成部と、前記第３トランザクションを前記各ノードに出力する第３出力部とを備えることを特徴とする。

一つの側面では、差金決済を伴う取引を、中央管理者を不要として行うことができる。

取引システムの構成例を示す模式図である。 サーバ、端末及びマッチングサーバの構成例を示すブロック図である。 レートＤＢ、ユーザＤＢ、及び取引板ＤＢのレコードレイアウトの一例を示す説明図である。 取引システムの利用例を示す説明図である。 トランザクション生成処理に関する説明図である。 トランザクション生成処理に関する説明図である。 契約実行処理について説明するための説明図である。 ＮＤＦ取引の結果を示す説明図である。 契約生成処理の処理手順の一例を示すフローチャートである。 契約実行処理の処理手順の一例を示すフローチャートである。 実施の形態２の概要を示す説明図である。 実施の形態２に係る契約生成処理の処理手順の一例を示すフローチャートである。

以下、本発明をその実施の形態を示す図面に基づいて詳述する。
（実施の形態１）
図１は、取引システムの構成例を示す模式図である。本実施の形態ではＮＤＦ取引を一例に、仮想通貨を用いた差金決済取引を行う取引システムについて説明する。取引システムは、情報処理装置１、情報処理端末２、２、２…、マッチングサーバ３、仲介者装置４を有する。各装置は、インターネット等のネットワークＮを介して通信接続されている。

本システムについて説明する前に、ＮＤＦ取引について簡単に説明する。ＮＤＦ取引はフォワード取引（先渡取引）の一種であり、いわゆる為替予約取引の一種である。主にＮＤＦ取引は、流動性の低い国の法定通貨、あるいは法規制により国外への持ち出しが禁止されている国の法定通貨の為替予約を行う場合に用いられる。ＮＤＦ取引は、一般的な為替予約と比較した場合、取引対象である通貨（元本）の受け渡しを行わず、為替レートの変動に応じた差金のみを決済する点が大きく異なる。

一般的な為替予約について説明すると、例えば日本法人が米国法人に商品を販売して代金を得る場合に、売買契約の約定時と、売買代金の決済時とでは日本円とＵＳドルとの間で為替レートの変動が生じ、当初の見込みよりも日本円換算での売上が減少するリスクがある。このような場合、日本法人は、決済時のレート（スポットレート、実勢直物レート等と呼ばれる）に関わらず、事前に取り決めた契約レートでＵＳドルを売却し、日本円を購入するフォワード取引を行うことで、外国為替の変動リスクをヘッジする。

一方で、ＮＤＦ取引では取引対象である外国通貨の受け渡しを行わず、スポットレート（取引レート）と契約レートとの差額に想定元本を乗じた金額を、取引対象である外国通貨とは異なる主要通貨で差金決済する。例えば日本法人が人民元の為替予約を行う場合、人民元は法規制があるため、人民元と日本円との間の直接的な為替予約を行うことが難しい。そこで日本法人は、為替レートの変動による差額相当の金額を人民元ではなく、ＵＳドルなどの主要通貨で差金決済する。これにより、一般的な為替予約を行った場合と同様の効果を得ることができ、外国為替の変動リスクをヘッジすることができる。

しかしながら、ＮＤＦ取引は相対取引であり、当事者間に銀行などの金融機関が介在して、顧客（当事者）から注文を集めた上で取引をマッチングさせている。カウンターパーティリスク（取引相手の倒産等によって契約が実行されないリスク）や、マッチングの難しさなどの問題があるため、顧客は大口のみに限定され、取引に伴う仲介料も発生する。

そこで本実施の形態では、上述の問題を解決するため、ブロックチェーンに代表される分散型台帳技術を用いて、仮想通貨建てで差金決済を行う取引システムについて説明する。

情報処理装置１は、ユーザ間のＮＤＦ取引自体には関与しない中立者の情報処理装置であり、例えばオラクル（登録商標）のようなリレーショナルデータベース管理システムのサーバ装置である。以下の説明では簡潔のため、情報処理装置１をサーバ１と読み替える。後述するように、サーバ１はＮＤＦ取引に係るトランザクションの実行に必要なデータ（公開鍵、電子署名等）を公開し、ユーザ同士の信頼関係を不要としたＮＤＦ取引を可能とする。

情報処理端末２は、種々の情報処理、情報の送受信が可能な多機能端末、パーソナルコンピュータ等の情報処理装置であり、本システムを利用してＮＤＦ取引を行う各ユーザの端末装置である。以下の説明では簡潔のため、情報処理端末２を端末２と読み替える。端末２は、取引の相手方の端末２との間で通信を行い、後述する仮想通貨のトランザクション処理を実行してＮＤＦ取引を行う。本実施の形態で各端末２は、ビットコイン（登録商標）建てで差金決済を行うトランザクションを実行する。
なお、端末２が取り扱う仮想通貨はビットコインに限定されず、その他の既存の仮想通貨、あるいは本システム独自の仮想通貨であってもよい。

マッチングサーバ３は、本システムを提供するサービス事業者のサーバ装置であり、各ユーザから提示されたＮＤＦ取引の希望条件（オファー又はビッド）をマッチングさせる装置である。マッチングサーバ３は、各ユーザがＮＤＦ取引を申し込むためのいわゆる取引板を提供し、ＮＤＦ取引を希望する法定通貨、契約レート、レート決定日等の情報を含むオファー又はビッドを端末２から取得してマッチングを行い、希望条件が合致するユーザ同士を取引相手として通知する。

仲介者装置４は、ユーザ間のＮＤＦ取引を仲介する仲介者の装置であり、例えば本システムの管理者、あるいは投資家等の装置である。後述するように、サーバ１は、各ユーザが取引板に出力した希望条件、具体的にはＮＤＦ取引の想定元本が一致しない場合、仲介者を各ユーザに紹介（提示）する。サーバ１は、ユーザ間に仲介者を立てることでマッチングの不成立を防止する。

図２は、サーバ１、端末２及びマッチングサーバ３の構成例を示すブロック図である。サーバ１は、制御部１１、主記憶部１２、通信部１３、及び補助記憶部１４を備える。
制御部１１は、一又は複数のＣＰＵ（Central Processing Unit）、ＭＰＵ（Micro-Processing Unit）、ＧＰＵ（Graphics Processing Unit）等の演算処理装置を有し、補助記憶部１４に記憶されたプログラムＰ１を読み出して実行することにより、サーバ１に係る種々の情報処理、制御処理等を行う。主記憶部１２は、ＳＲＡＭ（Static Random Access Memory）、ＤＲＡＭ（Dynamic Random Access Memory）、フラッシュメモリ等の一時記憶領域であり、制御部１１が演算処理を実行するために必要なデータを一時的に記憶する。通信部１３は、通信に関する処理を行うための処理回路等を含み、端末２等と情報の送受信を行う。

補助記憶部１４は大容量メモリ、ハードディスク等であり、制御部１１が処理を実行するために必要なプログラムＰ１、その他のデータを記憶している。また、補助記憶部１４は、レートＤＢ１４１を記憶している。レートＤＢ１４１は、為替レートに関する情報と、後述するトランザクションに必要なデータとを記憶するデータベースである。

なお、補助記憶部１４はサーバ１に接続された外部記憶装置であってもよい。また、サーバ１は複数のコンピュータからなるマルチコンピュータであってもよく、ソフトウェアによって仮想的に構築された仮想マシンであってもよい。

また、本実施の形態においてサーバ１は上記の構成に限られず、例えば可搬型記憶媒体に記憶された情報を読み取る読取部等を含んでもよい。

端末２は、制御部２１、主記憶部２２、通信部２３、表示部２４、入力部２５、補助記憶部２６を備える。
制御部２１は、一又は複数のＣＰＵ、ＭＰＵ等の演算処理装置を有し、補助記憶部２６に記憶されたプログラムＰ２を読み出して実行することにより、端末２に係る種々の情報処理、制御処理等を行う。主記憶部２２は、ＲＡＭ等の一時記憶領域であり、制御部２１が演算処理を実行するために必要なデータを一時的に記憶する。通信部２３は、通信を行うためのアンテナ、処理回路等を含み、サーバ１等と情報の送受信を行う。表示部２４は、液晶ディスプレイ、有機ＥＬ（Electro Luminescence）ディスプレイ等の表示装置であり、制御部２１から与えられた画像を表示する。入力部２５は、例えばタッチパネル、メカニカルキー等の操作部品であり、ユーザからの操作入力を受け付ける。

補助記憶部２６は、ＲＯＭ（Read Only Memory）等の不揮発性メモリであり、制御部２１が処理を実行するために必要なプログラムＰ２、その他のデータを記憶している。また、補助記憶部２６は、ユーザが保有する仮想通貨を管理するためのウォレットデータ２６１を記憶している。ウォレットデータ２６１は、ウォレットアドレスの管理に用いる公開鍵方式の暗号鍵（秘密鍵、公開鍵）等の情報を含む。

マッチングサーバ３は、制御部３１、主記憶部３２、通信部３３、及び補助記憶部３４を備える。
制御部３１は、一又は複数のＣＰＵ、ＭＰＵ等の演算処理装置を有し、補助記憶部２６に記憶されたプログラムＰ３を読み出して実行することにより、マッチングサーバ３に係る種々の情報処理、制御処理等を行う。主記憶部３２は、ＲＡＭ等の一時記憶領域であり、制御部３１が演算処理を実行するために必要なデータを一時的に記憶する。通信部３３は、通信を行うための処理回路等を含み、端末２等と情報の送受信を行う。

補助記憶部３４は大容量メモリ、ハードディスク等であり、制御部３１が処理を実行するために必要なプログラムＰ３、その他のデータを記憶している。また、補助記憶部１４は、ユーザＤＢ３４１及び取引板ＤＢ３４２を記憶している。ユーザＤＢ３４１は、各ユーザの情報を格納するデータベースである。取引板ＤＢ３４２は、各ユーザが取引板に出力したＮＤＦ取引の申込情報（オファー又はビッド）を記憶するデータベースである。

図３は、レートＤＢ１４１、ユーザＤＢ３４１、及び取引板ＤＢ３４２のレコードレイアウトの一例を示す説明図である。
レートＤＢ１４１は、日付列、公開鍵列、スポットレート列、署名値列を含む。日付列は、ＮＤＦ取引のレート決定日となる各日付を記憶している。公開鍵列は、日付と対応付けて、各日付（レート決定日）での差金決済に用いられる、中立者（サーバ１）が生成した公開鍵を記憶している。公開鍵は、サーバ１が管理する秘密鍵を用いて生成される。スポットレート列は、日付と対応付けて、各日付における実際のスポットレートを記憶している。署名値列は、日付と対応付けて、各日付でのスポットレートから中立者の秘密鍵に基づき生成された署名値であって、公開鍵列にレコードされている公開鍵に対応する署名値を記憶している。

ユーザＤＢ３４１は、ユーザＩＤ列、氏名列、アカウント列を含む。ユーザＩＤ列は、各ユーザを識別するための識別情報を記憶している。氏名列は、ユーザＩＤと対応付けて、各ユーザの氏名を記憶している。アカウント列は、ユーザＩＤと対応付けて、各ユーザのアカウント情報を記憶している。

取引板ＤＢ３４２は、申込ＩＤ列、ユーザＩＤ列、決定日列、売買列、参照通貨列、元本列、契約レートを含む。申込ＩＤ列は、各ユーザが取引板に出力した申込情報を識別するための識別情報を記憶している。申込情報は、取引対象である法定通貨の売却を希望するオファーと、法定通貨の購入を希望するビッドとがある。ユーザＩＤ列は、申込ＩＤと対応付けて、申込情報を出力したユーザのユーザＩＤを記憶している。決定日列は、申込ＩＤと対応付けて、ＮＤＦ取引におけるレートの決定日（決定時点）を記憶している。売買列は、申込ＩＤと対応付けて、ユーザが申し込んだ売買の種別（オファー又はビッドの別）を記憶している。参照通貨列は、申込ＩＤと対応付けて、ＮＤＦ契約で取り扱う法定通貨の種類を記憶している。元本列は、申込ＩＤと対応付けて、ＮＤＦ取引の想定元本の金額を記憶している。契約レート列は、申込ＩＤと対応付けて、ユーザが申し込んだ為替予約の契約レートを記憶している。

図４は、取引システムの利用例を示す説明図である。図４に示す具体例を参照して、取引システムの概要について説明する。
上述の如く、本実施の形態ではＮＤＦ取引を一例に説明を行う。図４では、日本法人であるユーザＡと、ベトナム法人であるユーザＣとが商品の売買を行う場合に、ユーザＡ、Ｃがそれぞれ、為替ヘッジのためＮＤＦ取引を行う様子を図示してある。

ここではユーザＡがユーザＣに、１ヶ月後に商品を販売する売買契約を結ぶ場合を想定する。この場合に、契約時のスポットレートで、１ＪＰＹ（日本円）が１００ＶＮＤ（ベトナムドン）であるものとする。また、契約時において１ＢＴＣ（ビットコイン）が１００万ＪＰＹ、及び１億ＶＮＤに相当するものとする。

ユーザＡ及びＣは、日本円及びベトナムドンとは異なる通貨建てで代金の授受を行う。ここで、一般的なＮＤＦ取引ではＵＳドルのような主要通貨（法定通貨）建てで行うが、本実施の形態では仮想通貨建てで行う。ここでは、ユーザＡ、Ｃは契約時の仮想通貨のスポットレートを参照して、０．１ＢＴＣ（１０万ＪＰＹ、１０００万ＶＮＤ）の代金で合意したものとする。

売買契約を結んだユーザＡは、１ヶ月間の為替の変動リスクを考慮して、ＮＤＦによる為替予約を行いたいと考えている。例えば図４に示すように、ユーザＡは、契約時と同額のスポットレートである１ＢＴＣ＝１００万ＪＰＹで為替予約を行い、契約時と同額で決済を確定させたいと考えている。

この場合にユーザＡは、端末２を介して、ＮＤＦ取引の希望条件を規定した申込情報をマッチングサーバ３に出力する。上述の例ではユーザＡが売り手側であるため、ユーザＡの端末２は、取引対象（通貨）の売却を申し込むオファーをマッチングサーバ３に出力する。上述の如く、マッチングサーバ３は本システムに係るＮＤＦ取引の取引板を管理しており、各ユーザからＮＤＦ契約の希望条件を規定した申込情報（オファー又はビッド）を受け付ける。マッチングサーバ３は、各ユーザからの希望条件をマッチングさせ、マッチングした取引の相手方（第２のユーザ）をユーザ（第１のユーザ）に提示する。

例えばユーザＡの端末２は、取引対象とする法定通貨、ＮＤＦ取引において希望する契約レート、仮想通貨換算の想定元本、及びスポットレートの決定日（決定時点）等、種々の希望条件を規定したオファーを取引板（マッチングサーバ３）に出力する。上述の例では、ユーザＡの端末２は、取引対象とする法定通貨を日本円とし、契約レートを１ＢＴＣ＝１００万ＪＰＹとし、想定元本を０．１ＢＴＣ（１０万ＪＰＹ）とし、レート決定日を１ヶ月後とするオファーを出力する。マッチングサーバ３は、ユーザＡのオファーを他のユーザのビッドとマッチングさせ、希望条件が合致（同一又は類似）する他のユーザをＮＤＦ取引の相手方として検索する。マッチングサーバ３は、相手方の情報（例えば相手ユーザ自身の情報、相手方が提示した希望条件等）をユーザＡの端末２に送信する。図４の例では、ユーザＢがユーザＡの相手方としてマッチングされ、ユーザＡに提示されたものとする。

ユーザＡ、Ｂはそれぞれ端末２を介して、ＮＤＦ取引の詳細について合意し、取引条件を設定してＮＤＦの契約を約定させる。ユーザＡ、Ｂは、ＮＤＦ取引実行のためのトランザクションの生成に移り、仮想通貨を媒介にしたＮＤＦ取引を行う。当該処理の詳細については、図５以降で詳述する。

一方で、ユーザＣもまた、ＮＤＦによって為替予約を行いたいと考えている。例えばユーザＣも、ユーザＡと同様に、契約時のスポットレートと同じレートで決済を確定させたいと考えている。そこでユーザＣは、取引対象とする通貨をベトナムドン、契約レートを１ＢＴＣ＝１億ＶＮＤ、想定元本を０．１ＢＴＣ（＝１０００万ＶＮＤ）、レート決定日を１ヶ月後とするビッドを取引板に出力する。マッチングサーバ３は、ユーザＣの希望条件と合致する他のユーザを検索する。

この場合に、例えばマッチングサーバ３は、契約レート、レート決定日等の条件は合致するが、想定元本が合致しないユーザＤを検索したものとする。例えばユーザＣの想定元本は０．１ＢＴＣであるが、ユーザＤの想定元本は０．０５ＢＴＣであるものとする。また、契約レート及びレート決定日が合致するその他のユーザはいないものとする。

上記の場合、ユーザＣ、Ｄは想定元本が同じユーザが現れない限り、マッチングが成立せず、ＮＤＦ取引を行うことができない。そこでマッチングサーバ３は、ユーザＣ、Ｄの間に仲介者を立ててマッチングを成立させる。仲介者は、上記のように想定元本が合致しないため相手方が見つからないユーザに対し、ユーザが希望する条件でＮＤＦ取引を行う第三者である。仲介者は、例えば本システムの運営者であってもよく、投資家等の第三者であってもよい。マッチングサーバ３は、ユーザＣと仲介者との間、及びユーザＤと仲介者との間でマッチングを成立させ、ユーザＣ、Ｄにそれぞれ仲介者を提示する。ユーザＣ、Ｄは、仲介者との間で取引条件の詳細を設定し、ＮＤＦ取引の契約を約定させる。このように、契約レート等の条件が一致するが、想定元本が一致しない複数のユーザの申込情報を取得した場合、マッチングサーバ３は、仲介者の情報をユーザに提示（紹介）する。これにより、マッチングの不成立を防止することができる。

図５及び図６は、トランザクション生成処理に関する説明図である。図５では、ＮＤＦ取引を実現するための仮想通貨のトランザクション生成処理について、概念的に図示している。図６では、想定され得る複数のスポットレートに応じて各ユーザに配分される供託金の取り分を説明するための説明図である。図５及び図６を用いて、マッチング成立後にユーザＡ、Ｂの端末２が生成するトランザクションについて説明する。

なお、以下の説明では、ユーザＡ、Ｂの端末２は各ユーザの秘密鍵に基づき公開鍵を生成し、交換（取得）済みであるものとして説明する。

まずユーザＡ、Ｂの端末２は、オフチェーンでトランザクションのやり取りを行うため、専用の通信路を確立する。当該通信路は、例えばライトニングネットワークのペイメントチャネルである。各端末２は、相手方の端末２との間でトランザクションの送受信を行う場合、当該通信路を介して送受信を行う。

次にユーザＡ、Ｂの端末２は、カウンターパーティリスクを考慮して、所定額の仮想通貨を互いに供託しておく。具体的には、端末２は、各々のユーザのウォレットアドレスから所定額の仮想通貨をマルチシグアドレスにデポジットしたトランザクション（第１トランザクション）を生成する。なお、以下の説明では当該トランザクションを「デポジットトランザクション」と呼ぶ。

図５において、白抜き矢印より上側に、デポジットトランザクションが生成され、ブロックチェーンに取り込まれる様子を図示している。例えば端末２は、ユーザＡ、Ｂから同額ずつ仮想通貨をデポジット（供託）したデポジットトランザクションを生成する。デポジットトランザクションは、ユーザＡ、Ｂそれぞれのウォレットアドレスから送金された仮想通貨をインプットとし、ユーザＡ、Ｂそれぞれからの送金額の総額をアウトプットとする。図５に従って説明すると、例えばユーザＡの端末２が、ユーザＡの供託額に相当する「０．０１ＢＴＣ」のインプットを記述したデポジットトランザクションを生成してユーザＢの端末２に受け渡し、ユーザＢの端末２が、ユーザＢの供託額「０．０１ＢＴＣ」のインプット、及びユーザＡ、Ｂの供託額の総額「０．０２ＢＴＣ」のアウトプットを当該トランザクションに追加する。なお、ユーザＡ、Ｂが供託する金額は、ＮＤＦ取引の想定元本に応じて定められ、例えばユーザＡ、Ｂはそれぞれ想定元本の１０％に相当する金額の仮想通貨を供託する。ユーザＢの端末２は、デポジットトランザクションをブロックチェーンネットワークの各ノードにブロードキャスト（出力）する。

なお、各ユーザからの供託額は同額でなくともよく、例えばユーザが合意すれば各々異なる額としてもよい。また、想定元本に対する供託額の比率も設計事項である。

また、ユーザＡ、Ｂの端末２が通信を行う通信路はライトニングネットワークのペイメントチャネルに限定されず、例えばマッチングサーバ３が取引板の一機能としてチャット機能を提供し、各端末２は当該機能を利用して通信を行ってもよい。つまり、各端末２の間の通信をある程度の秘匿性を確保しつつ行うことができればよく、その通信手段は特に限定されない。

本実施の形態において端末２はマルチシグネチャ技術を利用し、供託された仮想通貨の使用にユーザＡ、Ｂ両方の電子署名を必要とするマルチシグアドレスを送金先としたデポジットトランザクションを生成する。マルチシグアドレスは、定められた複数の当事者の秘密鍵のうち、一又は複数の秘密鍵に基づく電子署名によって利用可能となるウォレットアドレスである。端末２は、デポジットトランザクションを生成する場合、ユーザＡ、Ｂ両方の電子署名の検証を解除条件（第１の解除条件）としてアウトプットのロッキングスクリプトに記述する。端末２は、上述の解除条件を記述したデポジットトランザクションをブロードキャストする。これにより、一度供託された仮想通貨はユーザＡ、Ｂの合意がなければ使用できなくなる。

また、端末２は、デポジットトランザクションのアウトプットで規定するもう一つの解除条件（第２の解除条件）として、レート決定日から一定期間が経過し、かつ、ユーザＡ、Ｂのいずれかの電子署名が検証されること、を解除条件に設定する。具体的には、端末２は、デポジットトランザクションのロックタイムフィールドに所定の期間を記述し、もう一つの解除条件として、ユーザＡ、Ｂのいずれかの電子署名の検証をアウトプットのスクリプトに記述する。当該解除条件は、当事者のいずれかが契約違反を犯した場合のための罰則規定であり、後述するように、ＮＤＦ取引の実行のために必要な、デポジットトランザクションに続くトランザクションを一方当事者がブロードキャストしない場合に備えて加えられる規定である。当該規定について、詳しくは後述する。

上述の如く、ユーザＡ、Ｂは両者合意の上でマルチシグアドレスに所定額を供託する。続いてユーザＡ、Ｂそれぞれの端末２は、レート決定日にＮＤＦ取引を実行する（閉じる）ための後続のトランザクションを生成する。具体的には、端末２は、将来想定され得る複数のスポットレートそれぞれに対応して、供託金からユーザＡ、Ｂに配分される取り分（仮想通貨）をアウトプットとして定めたトランザクション（第２トランザクション）を複数生成する。なお、以下の説明では便宜上、「取引を閉じる」ことから、当該トランザクションをクロージングトランザクションと呼ぶ。

図５において、白抜き矢印の下側に、ユーザＡ、Ｂそれぞれがクロージングトランザクションを生成して交換する様子を図示している。クロージングトランザクションは、デポジットトランザクションのアウトプットをインプットとし、レート決定日のスポットレートに応じたユーザＡ、Ｂそれぞれの取り分をアウトプットとするトランザクションである。ユーザＡ、Ｂの端末２はそれぞれ、想定され得る複数のスポットレートに対応して、複数のクロージングトランザクションを生成して交換し、レート決定日まで保持しておく。

図５において白抜き矢印のすぐ下に示す、ユーザＡの端末２が生成するクロージングトランザクションを一例に説明を行う。図５に示すように、ユーザＡの端末２は、デポジットトランザクションのアウトプット「０．０２ＢＴＣ」を、クロージングトランザクションのインプットとして記述する。そして端末２は、想定されるスポットレートに応じて、ユーザＡの取り分に相当する「０．００９０ＢＴＣ」のアウトプットと、ユーザＢの取り分に相当する「０．０１１０ＢＴＣ」のアウトプットとを生成する。

図６に、複数のスポットレートと、各スポットレートに応じたユーザＡ、Ｂの取り分とを示す計算例を図示する。図６に示す例では、「８４万ＪＰＹ／ＢＴＣ」から「１０５万ＪＰＹ／ＢＴＣ」までの１万ＪＰＹ／ＢＴＣずつのスポットレートと、各スポットレートでのユーザＡ、Ｂそれぞれの取り分となる仮想通貨の金額と、日本円換算の金額とを示してある。なお、上述の例に則して、１００ＪＰＹ／ＢＴＣを契約レートとし、０．０２ＢＴＣを供託額として計算してある。

図５で示したユーザＡの端末２が生成するクロージングトランザクションは、図６においてスポットレート「１０１万ＪＰＹ／ＢＴＣ」に対応するクロージングトランザクションである。具体的には図６に示すように、「１０１万ＪＰＹ／ＢＴＣ」の場合、ユーザＡの取り分は約０．００９０ＢＴＣであり、ユーザＢの取り分は約０．０１１０ＢＴＣである。この場合の各ユーザの取り分は、日本円換算でユーザＡが９０８０ＪＰＹ、ユーザＢが１１１２０ＪＰＹとなる。

ここで、各ユーザの端末２は、自装置のユーザが不利なスポットレートに対応するクロージングトランザクションを生成する。具体的には、端末２は、ユーザが供託した金額よりも、ユーザに配分される取り分が少ないスポットレートのクロージングトランザクションを生成する。

図６において点線で示すように、ユーザＡ、Ｂが合意した予約レートを境界にして、ユーザＡに収益が発生するレートと、損益が発生するレートとで分かれている。例えば「９９万ＪＰＹ／ＢＴＣ」の場合、ユーザＡの取り分は約０．０１１０ＢＴＣであり、供託額０．０１ＢＴＣよりも多くなっている。すなわち、ユーザＡにとって有利なレートとなっている。一方で、「１０１万ＪＰＹ／ＢＴＣ」の場合、ユーザＡの取り分は約０．００９０ＢＴＣであり、供託額０．０１ＢＴＣよりも少なくなっている。すなわち、ユーザＡにとって不利なレートとなっている。

各ユーザの端末２は、自装置のユーザの取り分が供託額未満となるスポットレートのクロージングトランザクションを生成する。上述の例に則して説明すれば、ユーザＡの端末２は、１００万ＪＰＹ／ＢＴＣを超過する各スポットレートに対応したクロージングトランザクションを生成する。一方で、ユーザＢの端末２は、１００万ＪＰＹ／ＢＴＣ未満の各スポットレートのクロージングトランザクションを生成する。
なお、予約レート（１００万ＪＰＹ／ＢＴＣ）に対応するクロージングトランザクションは、ユーザＡ、Ｂのいずれの端末２が生成してもよい。

図５に戻って説明を続ける。上述の如く、各ユーザの端末２は、自装置のユーザに不利なスポットレートのクロージングトランザクションを生成する。図５では図示の便宜上、ユーザＡ、Ｂそれぞれの端末２が生成するクロージングトランザクションを一つずつしか図示していないが、端末２は、実際には複数のスポットレートそれぞれに対応する複数のクロージングトランザクションを生成する。また、図６では簡潔のため、１万ＪＰＹ／ＢＴＣずつスポットレートを記載したが、実際にはさらに小さな桁数でスポットレートは計算され、各端末２は数千のクロージングトランザクションを生成する。

端末２は、クロージングトランザクションのインプットに対し、ユーザの秘密鍵を用いて生成した電子署名を付加する。例えばユーザＡの端末２がクロージングトランザクションを生成する場合、ユーザＡの秘密鍵を用いて電子署名を生成する。そして端末２は、ユーザＡの電子署名を、クロージングトランザクションのインプットのアンロッキングスクリプトに記述する。これにより、後述するように、相手方（ユーザＢ）が電子署名を付加してクロージングトランザクションをブロードキャストすることで、クロージングトランザクションをブロックチェーンに取り込み可能となる。

また、端末２は、クロージングトランザクションの各アウトプットの解除条件を以下のように設定した上で、相手方の端末２に送信する。具体的には、端末２は、取り分が少ない自装置のユーザのアウトプットに関しては、当該ユーザの公開鍵のハッシュ値をスクリプトに記述することで、当該ユーザの電子署名のみの検証を解除条件として設定する。一方で、端末２は、取り分が多い相手方のアウトプットに関しては、相手方及び中立者（サーバ１）の電子署名の検証を解除条件として設定する。

以下、クロージングトランザクションの電子署名方式について説明する。本実施の形態で端末２は、Ｐ２ＰＫＨ（Pay-to-Public-Key-Hash）の形式でクロージングトランザクションのアウトプットのスクリプトを記述し、Ｓｃｈｎｏｒｒ署名方式の電子署名を用いる。ただし、一般的なＳｃｈｎｏｒｒ署名とは使い方が異なる。一般的なＳｃｈｎｏｒｒ署名では、署名者は自らの秘密鍵ｘと、ジェネレータＧ（楕円曲線のベースポイント）とからポイントＸ＝ｘＧを計算し、ポイントＸを公開鍵として公開する。さらに署名者は、秘密鍵ｘとは異なる秘密の乱数値ｋを計算し、ポイントＲ＝ｋＧを計算する。続いて、次の式（１）を計算する。

ｓ（ｍ）＝ｋ−ｈ（ｍ，Ｒ）ａ …（１）

式（１）においてｈ（ｐ，ｑ）はハッシュ関数であり、ｍは署名対象のメッセージである。本実施の形態では、メッセージｍはスポットレートに相当する。一般的なＳｃｈｎｏｒｒ署名では（Ｒ，ｓ（ｍ））が電子署名に相当する。
式（１）で与えられる電子署名の検証は、ポイントＸ、Ｒ、メッセージｍ、及びｓ（ｍ）に基づき、以下の式（２）が成立するか否かを検証することである。

ｓ（ｍ）Ｇ＝Ｒ−ｈ（ｍ，Ｒ）Ａ
＝ｋＧ−ｈ（ｍ，Ｒ）ａＧ …（２）

本実施の形態では、一般的なＳｃｈｎｏｒｒ署名と同じく式（１）及び（２）の計算式を用いるが、公開鍵及び電子署名の定義が異なる。具体的には、公開鍵は（Ｘ，Ｒ）とし、電子署名はｓ（ｍ）のみとする。すなわち、乱数値ｋに基づき算出されたポイントＲは公開鍵の一部として事前に公開される。ポイントＲが公開されているため、端末２は、任意のメッセージｍ＝ｉ、すなわち任意のスポットレートｉに対応する式（２）のｓ（ｉ）Ｇを、電子署名ｓ（ｉ）が未知であっても計算することができる。

サーバ１は中立者αとして機能し、中立者αの秘密鍵ｘ＝ｖと、秘密の乱数値ｋとを管理している。そしてサーバ１は、秘密鍵ｖから生成されるポイントＶ＝ｖＧと、ポイントＲ＝ｋＧとからなる公開鍵（Ｖ、Ｒ）を公開している。具体的には図３でレートＤＢ１４１に図示したように、サーバ１は、将来の日付毎に別々の公開鍵を生成し、公開している。ユーザＡ、Ｂそれぞれの端末２は、相手方との間で設定したレート決定日に応じて、対応する公開鍵をサーバ１から取得する。

端末２は、取り分が多い相手方のアウトプットに対して、ユーザＢ及び中立者αの電子署名の検証を解除条件に設定する。図５の例では、ユーザＡの端末２は、相手方であるユーザＢの取り分に相当する「０．０１１０ＢＴＣ」のアウトプットのスクリプトに、ユーザＢ及び中立者αの電子署名の検証を解除条件として記述する。

ここで、端末２は一般的なマルチシグネチャ（例えばPay to Multisig）と同じように、中立者αの公開鍵とユーザＢの公開鍵とを用いてユーザＢのアウトプットのスクリプトを記述し、中立者αの電子署名と、ユーザＢの電子署名とを個別に検証するように解除条件を設定してもよい。しかし、本実施の形態で端末２は、Ｐ２ＰＫＨ形式のスクリプトを特殊に構成することで、解除条件を設定する。具体的には、端末２は中立者αの公開鍵とユーザＢの公開鍵とを集約した一の公開鍵を生成し、当該一の公開鍵のハッシュ値をアウトプットのスクリプトに記述する。これにより、当該一の公開鍵に対応する秘密鍵に基づき、一の電子署名のみでアウトプットを利用できるように設定する。
なお、以下の説明では便宜上、ユーザＡ、Ｂそれぞれの秘密鍵ｘを符号ａ、ｂで表し、秘密鍵ａ、ｂから生成される公開鍵をＰｕｂ（ａ）＝ａＧ、Ｐｕｂ（ｂ）＝ｂＧと表す。

まず端末２は、式（２）に従い、中立者αの公開鍵（Ｖ，Ｒ）よりｓ（ｉ）Ｇを計算する。次に端末２は、ｓ（ｉ）Ｇと、ユーザＢの公開鍵Ｐｕｂ（ｂ）とを加算することで、次の式（３）のように中立者α及びユーザＢの公開鍵を集約した一の公開鍵Ｐｕｂ（ｂ，ｉ）を記述する。

Ｐｕｂ（ｂ，ｉ）＝Ｐｕｂ（ｂ）＋ｓ（ｉ）Ｇ …（３）

端末２は、公開鍵Ｐｕｂ（ｂ，ｉ）のハッシュ値をユーザＢの取り分に相当するアウトプットのスクリプトに記述し、公開鍵Ｐｕｂ（ｂ，ｉ）に対応する秘密鍵Ｐｒｉｖ（ｂ，ｉ）によってアウトプットを解除可能なように設定する。後述するように、秘密鍵Ｐｒｉｖ（ｂ，ｉ）はユーザＢの秘密鍵ｂと中立者αの電子署名ｓ（ｉ）とから計算可能であるため、ユーザＢの端末２は、中立者αの電子署名ｓ（ｉ）を用いて自らの取り分を利用することができる。

また、併せて端末２は、相手方のアウトプットの解除条件として、レート決定日から一定期間が経過し、かつ、自装置のユーザの電子署名が検証されること、をもう一つの解除条件（第２の解除条件）として設定する。上述の例では、ユーザＡの端末２は、クロージングトランザクションのロックタイムフィールドに一定期間を記述し、かつ、ユーザＢの取り分に相当するアウトプットのスクリプトに、ユーザＡの電子署名の検証を解除条件として設定する。当該解除条件は、当事者のいずれかが契約違反を犯した場合のための罰則規定であり、後述するように、レート決定日において実際のスポットレートとは異なるレートのクロージングトランザクションを一方当事者がブロードキャストする場合に備えた規定である。

各ユーザの端末２は、各々のユーザの取り分に相当するアウトプットの解除条件を上記のように規定して、クロージングトランザクションを生成する。そして端末２は、相手方の端末２との間でクロージングトランザクションの送受信を行い、相手方が生成したクロージングトランザクションを保持する。端末２は、互いに自らのユーザが不利なスポットレートのクロージングトランザクションを生成したため、ユーザに有利なスポットレートのクロージングトランザクションを保持することになる。各端末２は、レート決定日まで処理を待機し、レート決定日となった場合、以下の処理を実行する。

図７は、契約実行処理について説明するための説明図である。図７に基づき、レート決定日に端末２が実行する処理の概要を説明する。
レート決定日に至った場合、中立者αであるサーバ１は、当日のスポットレートｍ＝ｉを公表する。さらにサーバ１は、当日のスポットレート（メッセージ）ｍ＝ｉと、秘密鍵ａ及び乱数値ｋとに基づき、式（１）で表す中立者αの電子署名ｓ（ｉ）を生成して公開する。

ユーザＡ、Ｂの端末２は、サーバ１からスポットレートｍ＝ｉと、スポットレートｍ＝ｉから生成された電子署名ｓ（ｉ）とを取得する。そして各端末２は、当該スポットレートに対応するクロージングトランザクションを保持しているか否かを判定する。ここでは、スポットレートがユーザＡにとって有利なレートであり、ユーザＡの端末２がクロージングトランザクションを保持していたものとする。

ユーザＡの端末２は、レート決定日のスポットレートに対応するクロージングトランザクションをブロードキャストする。端末２が保持するクロージングトランザクションはユーザＡにとって有利なものであるため、ユーザＡには、当該トランザクションをブロードキャストしてＮＤＦ取引を実行するインセンティブが働く。端末２は、クロージングトランザクションのインプットに対してユーザＡの電子署名を付加し、ブロードキャストする。ユーザＢの電子署名はすでに記述されているため、ユーザＡ、Ｂ両方の電子署名がクロージングトランザクションに記述されたことになる。これにより、クロージングトランザクションのインプットはデポジットトランザクションのアウトプットの解除条件を満たし、クロージングトランザクションはブロックチェーンに正常に取り込まれる。

ここで、ユーザＡがクロージングトランザクションをブロードキャストしない場合、ユーザＢは自らの取り分を引き出せなくなる虞がある。この場合、デポジットトランザクションのアウトプットで規定された罰則規定が働き、ユーザＢは、供託金の全額を引き出すことができる。すなわち、ユーザＡがクロージングトランザクションをいつまでもブロードキャストせず、レート決定日から一定期間が経過した場合、デポジットトランザクションで定められたタイムロックが解除される。ユーザＢの端末２は、ユーザＢの秘密鍵に基づき電子署名を生成して、デポジットトランザクションから供託金の全額をユーザＢのウォレットアドレスに送金するトランザクションを生成し、ブロードキャストする。これにより、取引の安全が担保される。

クロージングトランザクションにおいて、取り分が少ないユーザＢのアウトプットは、ユーザＢの電子署名の検証を解除条件としてあり、ユーザＢの公開鍵のハッシュ値によってロックされている。すなわち、ユーザＢの取り分はすでにユーザＢのウォレットアドレスに送金済みの状態であり、ユーザＢは自らの秘密鍵を用いて取り分を自由に使うことができる。

一方で、取り分が多いユーザＡのアウトプットは、式（３）と同様に、ユーザＡの公開鍵Ｐｕｂ（ａ）と中立者αの公開鍵（Ｖ，Ｒ）とを集約した公開鍵Ｐｕｂ（ａ，ｉ）によってロックされている。従って、端末２はユーザＡの秘密鍵ａのみではユーザＡの取り分を取り出すことができず、中立者αの秘密鍵ｖも用いなければならない。しかし、公開鍵Ｐｕｂ（ａ）＝ａＧであることから、式（３）より次の式（４）の関係が成立する。

Ｐｕｂ（ａ，ｉ）＝（ａ＋ｓ（ｉ））Ｇ …（４）

従って、ユーザＡのアウトプットを使用するために必要な秘密鍵Ｐｒｉｖ（ａ，ｉ）は、ａ＋ｓ（ｉ）と同じになる。すなわち、ユーザＡの端末２は、ユーザＡの秘密鍵ａに中立者αの電子署名ｓ（ｉ）を加算することで、秘密鍵Ｐｒｉｖ（ａ，ｉ）を特定することができる。端末２は当該秘密鍵を用いて電子署名を生成し、ユーザＡの取り分をユーザＡのウォレットアドレスに送金するトランザクション（第３トランザクション）を生成して、ブロードキャストする。

なお、上記ではユーザＡが適切なスポットレート、つまり実際のレート通りのクロージングトランザクションをブロードキャストした場合について説明したが、ユーザＡが不正行為に及び、実際とは異なるレートのクロージングトランザクションがブロードキャストされる虞がある。この場合、クロージングトランザクションに設定された罰則規定が働き、ユーザＢは、ユーザＡの取り分を含めて供託金の全額を引き出すことができる。具体的には、実際とは異なるレートのクロージングトランザクションをブロードキャストした場合、サーバ１が管理している秘密鍵ｖ及び乱数値ｋが未知であるため、ユーザＡは、ユーザＡの取り分に相当するアウトプットを利用するために必要な中立者αの電子署名ｓ（ｉ）を知得できない。従って、ユーザＡは自らの取り分を引き出すことができない。この状態で一定期間が経過した場合、クロージングトランザクションに設定されたタイムロックが解除される。そしてユーザＢの端末２は、ユーザＢの電子署名を用いてユーザＡのアウトプットをユーザＢのウォレットアドレスに送金するトランザクションをブロードキャストすることで、ユーザＢの取り分を含め、供託額の全額を引き出すことができる。これにより、取引の安全性が確保される。

図８は、ＮＤＦ取引の結果を示す説明図である。図８では、図４で示した利用例に対応して、ＮＤＦ取引の結果の一例を示している。
図８では、レート決定日のスポットレートは、１ＢＴＣが９０万ＪＰＹ及び１憶１０００万ＶＮＤであり、１ＪＰＹが１２２ＶＮＤであったものとして説明する。この場合、売買契約に従ってユーザＡは商品をユーザＣに引き渡し、代金として０．１ＢＴＣを受け取る。１ＢＴＣが９０万ＪＰＹであるため、ユーザＡが受け取る代金の日本円換算の金額は９万ＪＰＹまで下がっている。

しかし、上述のＮＤＦ取引に係るトランザクションにより、ユーザＡは、契約レート及びスポットレートの差額に相当する０．００９１ＢＴＣを得る。ユーザＡは、代金０．１ＢＴＣに０．００９１ＢＴＣを加えた０．１０９１ＢＴＣを両替所等で日本円に交換することで、予約時の価格である１０万ＪＰＹとほぼ同額での売買が保証される。一方で、ユーザＢは期待値を外したため、ユーザＢに差金を支払う形になる。

ユーザＣは、代金としてユーザＡに０．１ＢＴＣを支払う。１ＢＴＣが１憶１０００万ＶＮＤであるため、ユーザＣが支払う代金のベトナムドン換算の金額は１１００万ＶＮＤまで上がっている。しかし、ユーザＣもＮＤＦ契約に係るトランザクションにより、契約レート及びスポットレートの差額に相当する０．００９１ＢＴＣを得る。ユーザＢは、１０００万ＶＮＤを両替所等で０．０９０９ＢＴＣに換金し、これに０．００９１ＢＴＣを加えた０．１ＢＴＣを支払いに充てることで、予約時と同じ価格である１０００万ＶＮＤでの売買が保証される。一方で、ユーザＤは期待値を外したため、仲介者を介してユーザＣに差金を支払う形になる。

図９は、契約生成処理の処理手順の一例を示すフローチャートである。図９に基づき、ＮＤＦ契約の生成処理について説明する。
端末２の制御部２１は、ユーザ（第１のユーザ）による操作入力に基づき、ＮＤＦ取引に係るユーザの希望条件を規定した申込情報をマッチングサーバ３に出力する（ステップＳ１１）。希望条件は、取引対象とする法定通貨、ＮＤＦ取引の契約レート、スポットレートの決定日（決定時点）、想定元本等の情報を含む。マッチングサーバ３は、各ユーザから受け付けた申込情報が示す希望条件のマッチングを行い、希望条件が合致（一致又は類似）するユーザを示すマッチング結果を返信する。あるいは、マッチングサーバ３は、ユーザ間での契約レート、レート決定日等の条件は一致するが、想定元本が一致しない場合、仲介者の情報をマッチング結果として返信する。制御部２１は、マッチングサーバ３から、ステップＳ１１で出力した申込情報に基づくマッチング結果を取得する（ステップＳ１２）。マッチング結果は、ＮＤＦ取引の相手方（第２のユーザ、又は仲介者）の情報、相手方が提示した希望条件等の情報を含む。

制御部２１は、ユーザによる操作入力に基づき、ＮＤＦ取引の契約を約定させるか否かを判定する（ステップＳ１３）。約定させないと判定した場合（Ｓ１３：ＮＯ）、制御部２１は処理をステップＳ１１に戻す。約定させると判定した場合（Ｓ１３：ＹＥＳ）、制御部２１は、各々のユーザが所定額の仮想通貨をマルチシグアドレスにデポジットするデポジットトランザクション（第１のトランザクション）を生成し、ブロックチェーンネットワークの各ノードに出力する（ステップＳ１４）。具体的には、制御部２１は、各々のユーザのウォレットアドレスから入金される所定額の仮想通貨をインプットとし、入金された仮想通貨の総額をアウトプットとするトランザクションを生成する。また、制御部２１は、両ユーザの秘密鍵に基づく電子署名の検証をアウトプットの解除条件（第１の解除条件）に設定する。さらに制御部２１は、一定期間が経過し、かつ、いずれか一方のユーザの電子署名が検証されることをアウトプットのもう一つの解除条件（第２の解除条件）に設定する。制御部２１は、デポジットトランザクションを、仮想通貨のトランザクションデータを分散して管理する、ブロックチェーンネットワークの各ノードにブロードキャストする。

制御部２１は、中立者として機能するサーバ１から、サーバ１が管理する秘密鍵に基づき生成された公開鍵を取得する（ステップＳ１５）。具体的には上述の如く、制御部２１はサーバ１から、秘密鍵ｖを用いて生成されたポイントＶと、乱数値ｋを用いて生成されたポイントＲとを公開鍵（Ｖ，Ｒ）として取得する。

制御部２１は、取得した中立者の公開鍵に基づき、デポジットトランザクションでデポジットされた仮想通貨を、レート決定日において想定され得る複数のスポットレートそれぞれに応じて各ユーザに配分する複数のクロージングトランザクション（第２トランザクション）を生成する（ステップＳ１６）。具体的には、制御部２１は、デポジットトランザクションのアウトプットをインプットとし、各ユーザの取り分に相当する２つのアウトプットを有するトランザクションを生成する。制御部２１は、想定され得る複数のスポットレート夫々に対応して各ユーザの取り分を計算し、各レートに対応する複数のクロージングトランザクションを生成する。

より詳細には、制御部２１は、取引条件として設定済みの契約レートと、想定元本とを参照して、自装置のユーザ（第１のユーザ）に配分される仮想通貨の金額が、当該ユーザがデポジットした仮想通貨の金額未満であるスポットレート、すなわちユーザにとって不利なスポットレートのデポジットトランザクションを生成する。

また、制御部２１は、クロージングトランザクションの２つのアウトプットそれぞれの解除条件を設定する。制御部２１は、自装置のユーザの取り分に相当するアウトプットに関しては、当該ユーザの秘密鍵に基づく電子署名の検証を解除条件に設定する。一方で、制御部２１は、相手方（第２のユーザ）の取り分に相当するアウトプットに関しては、相手方及び中立者の電子署名の検証を解除条件（第１の解除条件）に設定する。より詳細には、制御部２１は、中立者αの公開鍵（Ｖ，Ｒ）に基づき生成されるｓ（ｉ）Ｇと、相手方の秘密鍵ｘに基づき生成された公開鍵Ｐｕｂ（ｘ）とを加算することで、中立者α及び相手方の公開鍵を集約した一の公開鍵Ｐｕｂ（ｘ、ｉ）を生成する。制御部２１は、生成した公開鍵Ｐｕｂ（ｘ、ｉ）のハッシュ値をアウトプットのスクリプトに記述し、公開鍵Ｐｕｂ（ｘ、ｉ）に対応する秘密鍵Ｐｒｉｖ（ｘ，ｉ）に基づく電子署名の検証を解除条件として設定する。

さらに制御部２１は、相手方のアウトプットの解除条件として、一定期間が経過し、かつ、自装置のユーザの電子署名が検証されることをもう一つの解除条件（第２の解除条件）に設定する。

制御部２１は、各々が生成したクロージングトランザクションを相手方の端末２との間で送受信する（ステップＳ１７）。具体的には、制御部２１は、自身が生成したクロージングトランザクションに自装置のユーザの電子署名を付加し、相手方に送信する。制御部２１は、同様に相手方の電子署名が付加されたクロージングトランザクションを相手方の端末２から受信する。制御部２１は、相手方の端末２から受信したクロージングトランザクションを補助記憶部２６に記憶（保持）し（ステップＳ１８）、一連の処理を終了する。

図１０は、契約実行処理の処理手順の一例を示すフローチャートである。図１０に基づき、ＮＤＦ契約の実行処理について説明する。
端末２の制御部２１は、現在の日付がレート決定日であるか否かを判定する（ステップＳ３１）。レート決定日でないと判定した場合（Ｓ３１：ＮＯ）、制御部２１は処理を待機する。レート決定日であると判定した場合（Ｓ３１：ＹＥＳ）、制御部２１はサーバ１から、レート決定日におけるスポットレート（取引レート）と、当該スポットレートから中立者の秘密鍵に基づいて生成された電子署名とをサーバ１から取得する（ステップＳ３２）。具体的には、サーバ１は、レート決定日のスポットレートｍ＝ｉを公開すると共に、スポットレートｉと、秘密に管理している秘密鍵ｖ及び乱数値ｋとを用いて、式（１）に基づき電子署名ｓ（ｉ）を生成して公開する。端末２の制御部２１は、サーバ１が公開したスポットレートｉと、電子署名ｓ（ｉ）とを取得する。

制御部２１は、レート決定日のスポットレートに対応するクロージングトランザクションを、自装置で保持（記憶）しているか否かを判定する（ステップＳ３３）。保持していると判定した場合（Ｓ３３：ＹＥＳ）、制御部２１は、自装置のユーザの電子署名を付加した上で、当該クロージングトランザクションをブロックチェーンネットワークの各ノードに出力する（ステップＳ３４）。その後、制御部２１は、サーバ１から取得した中立者の電子署名を用い、クロージングトランザクションで自装置のユーザに配分された仮想通貨を、当該ユーザのウォレットアドレスに送金するトランザクション（第３トランザクション）を生成し、出力する（ステップＳ３５）。

具体的には上述の如く、制御部２１は、ユーザの秘密鍵ｘに紐付く公開鍵Ｐｕｂ（ｘ）と、中立者αの電子署名ｓ（ｉ）とに基づき、ユーザ及び中立者αそれぞれの公開鍵Ｐｕｂ（ｘ）及び（Ｖ、Ｒ）を集約した公開鍵Ｐｕｂ（ｘ，ｉ）に対応する秘密鍵Ｐｒｉｖ（ｘ，ｉ）を特定する。制御部２１は、特定した秘密鍵Ｐｒｉｖ（ｘ，ｉ）を用いて電子署名を生成し、当該電子署名を付加したトランザクションを生成してブロードキャストする。制御部２１は、一連の処理を終了する。

スポットレートに対応するクロージングトランザクションを保持していないと判定した場合（Ｓ３３：ＮＯ）、制御部２１は、相手方の端末２からクロージングトランザクションがブロックチェーン上に出力されたか否かを判定する（ステップＳ３６）。クロージングトランザクションが出力されたと判定した場合（Ｓ３６：ＹＥＳ）、制御部２１は、相手方が自らの取り分に相当するアウトプットを相手方のウォレットアドレスに送金する、ステップＳ３５のトランザクションをブロックチェーン上に出力したか否かを判定する（ステップＳ３７）。相手方がトランザクションを出力したと判定した場合（Ｓ３７：ＹＥＳ）、制御部２１は一連の処理を終了する。

相手方がトランザクションを出力していないと判定した場合（Ｓ３７：ＮＯ）、制御部２１は、クロージングトランザクションで規定された一定期間を経過したか否かを判定する（ステップＳ３８）。一定期間が経過していないと判定した場合（Ｓ３８：ＮＯ）、制御部２１は処理をステップＳ３７に戻す。一定期間が経過したと判定した場合（Ｓ３８：ＹＥＳ）、制御部２１は、相手方の取り分に相当するクロージングトランザクションのアウトプットを自装置のユーザのウォレットアドレスに送金するトランザクションを生成し、ブロックチェーン上に出力する（ステップＳ３９）。具体的には、制御部２１は、相手方のアウトプットのスクリプトで規定された解除条件に従い、自装置のユーザの電子署名を付加したトランザクションを生成してブロードキャストする。制御部２１は、一連の処理を終了する。

相手方からクロージングトランザクションが出力されていないと判定した場合（Ｓ３６：ＮＯ）、制御部２１は、デポジットトランザクションで規定された一定期間が経過したか否かを判定する（ステップＳ４０）。一定期間が経過していないと判定した場合（Ｓ４０：ＮＯ）、制御部２１は処理をステップＳ３６に戻す。一定期間が経過したと判定した場合（Ｓ４０：ＹＥＳ）、制御部２１は、デポジットトランザクションにデポジットされた仮想通貨の全額をユーザのウォレットアドレスに送金するトランザクションを生成し、ブロックチェーン上に出力する（ステップＳ４１）。具体的には、制御部２１はアウトプットのスクリプトで規定された解除条件に従い、自装置のユーザの電子署名を付加したトランザクションを生成してブロードキャストする。制御部２１は、一連の処理を終了する。

なお、上記では、Ｓｃｈｎｏｒｒ署名を一般的な使い方とは異なる使い方で用い、これに対応して、クロージングトランザクションのアウトプットを、Ｐ２ＰＫＨ形式の特殊なスクリプトで構成した。しかし、本実施の形態はこれに限定されるものではない。例えば一般的な使い方と同じく、秘密鍵ｖに基づくポイントＶのみをＳｃｈｎｏｒｒ署名の公開鍵として用いてもよい。この場合、端末２は任意のスポットレートｍ＝ｉのｓ（ｉ）Ｇを計算できないため、代わりにサーバ１が任意のスポットレートｍ＝ｉのｓ（ｉ）Ｇを計算した上で各端末２に配信すればよい。また、例えば各端末２は、一般的なマルチシグネチャと同じく、中立者αの公開鍵のハッシュ値と、ユーザＡ又はＢの公開鍵のハッシュ値とをクロージングトランザクションのアウトプットのスクリプトに記述することで、中立者α及びユーザＡ、Ｂの電子署名を個別に検証させるようにしてもよい。

また、可能であるならば、Pay to PubKeyやＰ２ＳＨ（Pay to Script Hash）のアルゴリズムを用いて各トランザクションのスクリプトを記述してもよい。また、電子署名はＳｃｈｎｏｒｒ署名だけでなく、ＤＳＡ等のその他の電子署名であってもよい。すなわち、端末２は、少なくとも中立者の公開鍵に用いてクロージングトランザクションを生成し、中立者の電子署名によってクロージングトランザクションに続く後続のトランザクションを生成可能であればよく、スクリプトの記述形式、電子署名の方式等は特に限定されない。

また、上記でサーバ１が中立者として機能し、マッチングサーバ３がマッチング機能を有するものとして説明したが、両機能を一の装置（サーバ）に実装してもよい。

また、上記で端末２は、中立者として機能するサーバ１からスポットレートを取得するものとしたが、必ずしも中立者からスポットレートを取得する必要はなく、中立者以外の第三者（例えば為替レートを発表する金融機関等）から取得するようにしてもよい。

また、上記ではＮＤＦ取引を一例に説明したが、本実施の形態はこれに限定されるものではない。例えば法定通貨と仮想通貨との間の両替取引、ＦＸ（Foreign Exchange）取引等の価格変動リスクをヘッジする取引を行うようにしてもよい。また、後述する実施の形態２のように、取引対象とする現物は通貨自体の価格（為替）でなくともよい。また、金融取引に限定されず、例えばゲーム内の取引であってもよい。すなわち、取引システムは、経時的に取引レートが変動する取引対象について、取引価格の変動リスクをヘッジする処理を、仮想通貨を用いた差金決済によって行うことができればよく、その取引対象は特に限定されない。

以上より、本実施の形態１によれば、ＮＤＦ取引を行う各ユーザの端末２は、所定額をデポジットトランザクションによって供託した後、想定され得る複数のスポットレートそれぞれに対応して、複数のクロージングトランザクションを生成しておく。ここで端末２は、各ユーザとは異なる中立者の公開鍵を用いて、クロージングトランザクションのアウトプットをロックする。そして端末２は、レート決定日を経過した場合、レート決定日のスポットレートに対応するクロージングトランザクションをブロードキャストする。そして端末２は、中立者の秘密鍵に基づき生成された電子署名を用いて、自らのウォレットアドレスに取り分を送金する。所定額が事前に供託されているためカウンターパーティリスクが解消されていると共に、中立者の公開鍵及び電子署名を用いてＮＤＦ取引を実行するため、各ユーザは互いの信頼関係を不要としてＮＤＦ取引を行うことができる。これにより、小口での取引も可能な、中央管理者を不要としたＮＤＦ取引を行うことができる。

また、本実施の形態１によれば、各ユーザはマルチシグアドレスに供託金をデポジットしておくと共に、互いに生成したクロージングトランザクションに電子署名を付加して交換しておき、レート決定日に対応するクロージングトランザクションを保持するユーザが、当該クロージングトランザクションをブロードキャストする。これにより、ＮＤＦ取引を好適に実施することができる。

また、本実施の形態１によれば、各ユーザは自らに不利なスポットレートのクロージングトランザクションを生成し、交換する。これにより、各ユーザは自らに有利なスポットレートのクロージングトランザクションを保持することになり、レート決定日のスポットレートが自らに有利なスポットレートである場合、クロージングトランザクションをブロードキャストするインセンティブが働く。これにより、好適にＮＤＦ取引を実現することができる。

また、本実施の形態１によれば、クロージングトランザクションを生成する場合、端末２は、取り分が多い相手方のアウトプットに関して、相手方及び中立者の電子署名の検証を第１の解除条件を設定すると共に、一定期間が経過し、かつ、ユーザの電子署名が検証されることを第２の解除条件に設定する。第１の解除条件により、クロージングトランザクションをブロードキャストする側のユーザ（つまり有利なユーザ）は中立者の電子署名を用いて自らのウォレットアドレスへの送金を行うよう強制され、中立者による間接的な取引の承認を行うことができる。また、第２の解除条件により、有利なユーザは一定期間内に正しいスポットレートのクロージングトランザクションをブロードキャストするよう強制され、不正行為が是正される。

また、本実施の形態１によれば、式（３）で示したようにユーザ（相手方）及び中立者それぞれの公開鍵を一の公開鍵に集約し、当該公開鍵に基づいてクロージングトランザクションのアウトプットをロックする。これにより、ユーザ及び中立者の秘密鍵を別々に検証する必要がなく、トランザクションのデータサイズを圧縮し、スケーラビリティの問題に対応することができる。

また、本実施の形態１によれば、クロージングトランザクションを生成する場合、端末２は、取り分が少ないユーザのアウトプットに関しては、当該ユーザのみの電子署名の検証を解除条件に設定する。すなわち、クロージングトランザクションがブロードキャストされた場合、すでにユーザの取り分に相当するアウトプットはユーザの秘密鍵に紐付けられた形になり、ユーザのウォレットアドレスに送金済みの状態となる。従って、取り分が少ないユーザはクロージングトランザクションに続く後続のトランザクションを生成する必要がなく、ユーザの負担を減らすことができる。

また、本実施の形態１によれば、デポジットトランザクションのアウトプットの第２の解除条件として、一定期間が経過し、かつ、いずれか一方のユーザのみの電子署名が検証されることを解除条件に設定する。これにより、クロージングトランザクションをブロードキャストすべきユーザが当該トランザクションを出力しない事態に対応することができる。

また、本実施の形態１によれば、サーバ１はＮＤＦ取引の取引板を提供する。これにより、各ユーザは不特定のユーザとの間で取引を行うことができる。

また、本実施の形態１によれば、サーバ１は、各ユーザの希望条件で規定された想定元本が揃わない場合、仲介者を取引相手として紹介する。これにより、マッチングの不成立を防止することができる。

（実施の形態２）
実施の形態１では、仮想通貨を用いて外国為替のヘッジを行う形態について述べた。本実施の形態では、仮想通貨のマイニングに伴う報酬をヘッジする形態について述べる。なお、実施の形態１と重複する内容については同一の符号を付して説明を省略する。
図１１は、実施の形態２の概要を示す説明図である。図１１では、ユーザがマイニングに伴う報酬のリスクヘッジを行うため、取引板にオファーを出力する様子を概念的に図示している。図１１に基づき、本実施の形態の概要について説明する。

本実施の形態で取引システムが実行するトランザクションの処理内容は実施の形態１と同様であるが、取り扱う取引の内容が異なる。具体的には、取引システムは、マイニングの難易度（difficulty）調整に伴うマイニング報酬の変動リスクをヘッジする取引を取り扱う。

ビットコイン等のブロックチェーンシステムでは、マイナーが各ブロックの検証（マイニング）に要する時間を調整するため、マイニングに係る計算問題の難易度を定期的に変更している。ビットコインを例にした場合、Ｐｒｏｏｆ ｏｆ Ｗｏｒｋに係るナンス値を探索する時間が１ブロック当たり約１０分間となるように、２０１６ブロック（約２週間に相当）がブロックチェーンに追加される毎に、１ブロック当たりの平均計算時間を求め、難易度を調整している。その難易度は徐々に上がる傾向にある。

一方で、難易度が変更されるということは、マイナーにとって、マイニングの報酬として得る手数料の期待値が変動することを意味する。周知のように、多くのマイナーがＡＳＩＣ（Application Specific Integrated Circuit）等の高い計算能力（Hash Power）を有する計算機を用いて、電気代、水道代等を投資して報酬を得ている。また、近年ではマイニングプールへの投資も行われており、計算機を所持する直接的なマイナーではないが、マイニングプールの運営主体に投資してマイニングを行わせ、対価として報酬を得ている者も存在する。このようなマイナー等にとって、難易度が上がった場合、マイニングによって得る報酬の期待値が下がることになる。

そこで本実施の形態に係る取引システムでは、将来のマイニングの難易度変更に備え、マイニングの報酬が変動するリスクをヘッジする取引の市場を提供する。具体的には、取引システムはＮＤＦ取引の場合と同様に、マイニングの報酬を取引対象にするが、報酬自体の受け渡しは行わず、マイニングの難易度調整に伴う報酬の変動額（差額）分のみを差金決済する取引の市場を提供する。つまり、本実施の形態ではマイニングの難易度が為替レートに相当し、マイニングの報酬が想定元本に相当する。

売り手側であるユーザの端末２は、当該取引に係る希望条件を規定したオファーをマッチングサーバ３に出力する。具体的には、端末２は、契約レートに相当するマイニングの難易度、スポットレートに相当する難易度の決定日（決定時点）、想定元本に相当するマイニングの報酬額等を規定した申込情報を出力する。

マッチングサーバ３は同様に、買い手側のユーザの端末２からビッドを受け付け、売り手側のユーザのオファーと希望条件をマッチングさせる。マッチングサーバ３は、マッチング結果を端末２に返信する。各ユーザの端末２は、取引条件の詳細を設定して取引に合意し、実施の形態１と同様、差金決済を行うためのデポジットトランザクション及びクロージングトランザクションの生成に移る。

図１２は、実施の形態２に係る契約生成処理の処理手順の一例を示すフローチャートである。図１２に基づき、本実施の形態に係る契約生成処理について説明する。
端末２の制御部２１は、マイニングの難易度調整に伴うマイニング報酬の変動リスクをヘッジする取引であって、マイニング報酬を取引対象にして、マイニングの難易度の変更に基づく差金決済を行う取引の希望条件を規定した申込情報を出力する（ステップＳ２０１）。より詳細には、当該取引は、ユーザが取り決めた難易度を契約レートにして、レート決定日における実際の難易度（スポットレート）と契約レートとの差分に、マイニングによって得られるであろう報酬の期待値（想定元本）を乗算した金額を差金決済する取引である。オファーする希望条件は、取り扱う仮想通貨、契約レートに相当する難易度、スポットレートに相当する難易度の決定日、想定元本に相当するマイニング報酬の期待値等の情報を含む。

制御部２１は、マッチングサーバ３から、ステップＳ１１で出力した申込情報に基づくマッチング結果を取得する（ステップＳ２０２）。制御部２１は処理をステップＳ１３に移行し、取引が約定した場合、実施の形態１と同様にトランザクションの生成に移る。

以上より、本実施の形態２によれば、マイニングの報酬の変動リスクをヘッジすることができる。

今回開示された実施の形態はすべての点で例示であって、制限的なものではないと考えられるべきである。本発明の範囲は、上記した意味ではなく、特許請求の範囲によって示され、特許請求の範囲と均等の意味及び範囲内でのすべての変更が含まれることが意図される。

１ サーバ（情報処理装置）
１１ 制御部
１２ 主記憶部
１３ 通信部
１４ 補助記憶部
Ｐ１ プログラム
１４１ レートＤＢ
２ 端末（情報処理端末）
２１ 制御部
２２ 主記憶部
２３ 通信部
２４ 表示部
２５ 入力部
２６ 補助記憶部
Ｐ２ プログラム
２６１ ウォレットデータ
３ マッチングサーバ
３１ 制御部
３２ 主記憶部
３３ 通信部
３４ 補助記憶部
Ｐ３ プログラム
３４１ ユーザＤＢ
３４２ 取引板ＤＢ
４ 仲介者装置

Claims (13)

1. 差金決済を伴う取引の条件であって、経時的に取引レートが変動する取引対象について、ユーザ及び相手方の間で取り決めた前記取引対象の契約レートと、差金決済を行う前記取引レートの決定時点と、想定元本とを含む取引条件を設定する設定部と、
   前記取引条件に基づき、前記ユーザ及び相手方夫々が所定額の仮想通貨をデポジットした第１トランザクションを生成する第１生成部と、
   前記第１トランザクションを、前記仮想通貨のトランザクションデータを分散して管理する各ノードに出力する第１出力部と、
   前記相手方と異なる中立者から、該中立者の秘密鍵に基づき生成された公開鍵を取得する第１取得部と、
   取得した前記中立者の公開鍵を用いて、前記第１トランザクションでデポジットされた前記仮想通貨を、複数の前記取引レート夫々に応じて前記ユーザ及び相手方に配分する複数の第２トランザクションを生成する第２生成部と、
   前記決定時点を経過した場合、該決定時点の前記取引レートと、該取引レートから前記中立者の秘密鍵に基づき生成された電子署名とを取得する第２取得部と、
   取得した前記取引レートに対応する前記第２トランザクションを前記各ノードに出力する第２出力部と、
   前記中立者の電子署名を用いて、前記第２トランザクションで前記ユーザに配分された前記仮想通貨を前記ユーザ宛に送金する第３トランザクションを生成する第３生成部と、
   前記第３トランザクションを前記各ノードに出力する第３出力部と
   を備えることを特徴とする情報処理装置。
2. 前記第１生成部は、前記ユーザ及び相手方夫々の電子署名が必要なマルチシグアドレスに前記仮想通貨をデポジットする前記第１トランザクションを生成し、
   前記第２生成部が生成した前記複数の第２トランザクションに、前記ユーザの電子署名を付加して前記相手方に送信する送信部と、
   該相手方の電子署名が付加された、前記相手方が生成した前記複数の第２トランザクションを前記相手方から受信する受信部と、
   受信した前記複数の第２トランザクションを保持する保持部と
   を備え、
   前記第２出力部は、前記保持部が保持している前記複数の第２トランザクションのうち、前記決定時点の前記取引レートに対応する前記第２トランザクションに、前記ユーザの電子署名を付加して出力する
   ことを特徴とする請求項１に記載の情報処理装置。
3. 前記第２生成部は、前記ユーザに配分される前記仮想通貨の金額が、前記ユーザが前記マルチシグアドレスにデポジットした前記仮想通貨の金額未満となる前記取引レートに対応した前記第２トランザクションを生成し、
   前記受信部は、前記ユーザに配分される前記仮想通貨の金額が、前記ユーザが前記マルチシグアドレスにデポジットした前記仮想通貨の金額を超える前記取引レートに対応した前記第２トランザクションを前記相手方から受信し、
   前記第２出力部は、前記決定時点の前記取引レートに対応する前記第２トランザクションを前記保持部が保持している場合、該第２トランザクションを出力する
   ことを特徴とする請求項２に記載の情報処理装置。
4. 前記第２生成部は、前記相手方に配分される前記仮想通貨に相当するアウトプットに関し、前記相手方及び中立者の電子署名の検証を第１の解除条件に、前記決定時点から一定期間が経過し、かつ、前記ユーザの電子署名が検証されることを第２の解除条件に設定した前記第２トランザクションを生成し、
   前記受信部は、前記ユーザに配分される前記仮想通貨に相当するアウトプットに関し、前記ユーザ及び中立者の電子署名の検証を第１の解除条件に、前記決定時点から一定期間が経過し、かつ、前記相手方の電子署名が検証されることを第２の解除条件に設定した前記第２トランザクションを受信する
   ことを特徴とする請求項３に記載の情報処理装置。
5. 前記相手方の秘密鍵に基づき生成された公開鍵を取得する第３取得部を備え、
   前記第２生成部は、
   前記相手方及び中立者夫々の公開鍵に基づき、一の公開鍵を生成し、
   前記一の公開鍵を用いて、前記第２トランザクションに前記第１の解除条件を設定し、
   前記第３生成部は、
   前記ユーザの公開鍵及び前記中立者の電子署名に基づき、前記一の公開鍵に対応する秘密鍵を特定し、
   特定した秘密鍵を用いて、前記第１の解除条件を満たす電子署名を生成して前記第３トランザクションに付加する
   ことを特徴とする請求項４に記載の情報処理装置。
6. 前記第２生成部は、前記ユーザに配分される前記仮想通貨に相当するアウトプットに関し、前記ユーザの電子署名の検証を解除条件に設定した前記第２トランザクションを生成し、
   前記受信部は、前記相手方に配分される前記仮想通貨に相当するアウトプットに関し、前記相手方の電子署名の検証を解除条件に設定した前記第２トランザクションを取得する
   ことを特徴とする請求項４又は５に記載の情報処理装置。
7. 前記第１生成部は、前記ユーザ及び相手方夫々の電子署名の検証をアウトプットの第１の解除条件に、前記決定時点から一定期間が経過し、かつ、前記ユーザ又は相手方の電子署名が検証されることをアウトプットの第２の解除条件に設定した前記第１トランザクションを生成する
   ことを特徴とする請求項２〜６のいずれか１項に記載の情報処理装置。
8. 前記ユーザによる前記取引の希望条件を外部装置に出力する条件出力部と、
   前記ユーザと前記希望条件が合致する他の前記ユーザを示すマッチング結果を、前記外部装置から取得する第４取得部と
   を備え、
   前記設定部は、前記他のユーザとの間で前記取引条件を設定する
   ことを特徴とする請求項１〜７のいずれか１項に記載の情報処理装置。
9. 前記想定元本に係る前記希望条件が前記他のユーザのいずれとも合致しない場合、前記ユーザと前記他のユーザとの間で前記取引を仲介する仲介者の情報を前記外部装置から取得する
   ことを特徴とする請求項８に記載の情報処理装置。
10. 前記設定部は、前記仮想通貨のマイニングに伴う報酬を前記取引対象にして、前記契約レートに相当する前記マイニングの難易度と、前記取引レートに相当する難易度の決定時点と、前記想定元本に相当する前記報酬の金額とを含む前記取引条件を設定する
    ことを特徴とする請求項１〜９のいずれか１項に記載の情報処理装置。
11. 差金決済を伴う取引の条件であって、経時的に取引レートが変動する取引対象について、ユーザ及び相手方の間で取り決めた前記取引対象の契約レートと、差金決済を行う前記取引レートの決定時点と、想定元本とを含む取引条件を設定し、
    前記取引条件に基づき、前記ユーザ及び相手方夫々が所定額の仮想通貨をデポジットした第１トランザクションを生成し、
    前記第１トランザクションを、前記仮想通貨のトランザクションデータを分散して管理する各ノードに出力し、
    前記相手方と異なる中立者から、該中立者の秘密鍵に基づき生成された公開鍵を取得し、
    取得した前記中立者の公開鍵を用いて、前記第１トランザクションでデポジットされた前記仮想通貨を、複数の前記取引レート夫々に応じて前記ユーザ及び相手方に配分する複数の第２トランザクションを生成し、
    前記決定時点を経過した場合、該決定時点の前記取引レートと、該取引レートから前記中立者の秘密鍵に基づき生成された電子署名とを取得し、
    取得した前記取引レートに対応する前記第２トランザクションを前記各ノードに出力し、
    前記中立者の電子署名を用いて、前記第２トランザクションで前記ユーザに配分された前記仮想通貨を前記ユーザ宛に送金する第３トランザクションを生成し、
    前記第３トランザクションを前記各ノードに出力する
    処理をコンピュータに実行させることを特徴とする情報処理方法。
12. 差金決済を伴う取引の条件であって、経時的に取引レートが変動する取引対象について、ユーザ及び相手方の間で取り決めた前記取引対象の契約レートと、差金決済を行う前記取引レートの決定時点と、想定元本とを含む取引条件を設定し、
    前記取引条件に基づき、前記ユーザ及び相手方夫々が所定額の仮想通貨をデポジットした第１トランザクションを生成し、
    前記第１トランザクションを、前記仮想通貨のトランザクションデータを分散して管理する各ノードに出力し、
    前記相手方と異なる中立者から、該中立者の秘密鍵に基づき生成された公開鍵を取得し、
    取得した前記中立者の公開鍵を用いて、前記第１トランザクションでデポジットされた前記仮想通貨を、複数の前記取引レート夫々に応じて前記ユーザ及び相手方に配分する複数の第２トランザクションを生成し、
    前記決定時点を経過した場合、該決定時点の前記取引レートと、該取引レートから前記中立者の秘密鍵に基づき生成された電子署名とを取得し、
    取得した前記取引レートに対応する前記第２トランザクションを前記各ノードに出力し、
    前記中立者の電子署名を用いて、前記第２トランザクションで前記ユーザに配分された前記仮想通貨を前記ユーザ宛に送金する第３トランザクションを生成し、
    前記第３トランザクションを前記各ノードに出力する
    処理をコンピュータに実行させることを特徴とするプログラム。
13. 各ユーザの情報処理端末と、前記ユーザと異なる中立者の情報処理装置とを有する取引システムであって、
    前記情報処理端末は、
    差金決済を伴う取引の条件であって、経時的に取引レートが変動する取引対象について、第１及び第２のユーザの間で取り決めた前記取引対象の契約レートと、差金決済を行う前記取引レートの決定時点と、想定元本とを含む取引条件を設定する設定部と、
    前記取引条件に基づき、前記第１及び第２のユーザ夫々が所定額の仮想通貨をデポジットした第１トランザクションを生成する第１生成部と、
    前記第１トランザクションを、前記仮想通貨のトランザクションデータを分散して管理する各ノードに出力する第１出力部と、
    前記情報処理装置から、前記中立者の秘密鍵に基づき生成された公開鍵を取得する第１取得部と、
    取得した前記中立者の公開鍵を用いて、前記第１トランザクションでデポジットされた前記仮想通貨を、複数の前記取引レート夫々に応じて前記第１及び第２のユーザに配分する複数の第２トランザクションを生成する第２生成部と、
    前記決定時点を経過した場合、該決定時点の前記取引レートと、該取引レートから前記中立者の秘密鍵に基づき生成された電子署名とを取得する第２取得部と、
    取得した前記取引レートに対応する前記第２トランザクションを前記各ノードに出力する第２出力部と、
    前記中立者の電子署名を用いて、前記第２トランザクションで前記第１又は第２のユーザに配分された前記仮想通貨を前記第１又は第２のユーザ宛に送金する第３トランザクションを生成する第３生成部と、
    前記第３トランザクションを前記各ノードに出力する第３出力部と
    を備えることを特徴とする取引システム。

Images