WO2021144888A1

WO2021144888A1 - 決済処理装置、決済処理プログラムおよび決済処理システム

Info

Publication number: WO2021144888A1
Application number: PCT/JP2020/001114
Authority: WO
Inventors: 玲大塚; 大成高橋
Original assignee: 株式会社ＦｉｎａｌｉｔｙＴｅｃｈｎｏｌｏｇｉｅｓ
Priority date: 2020-01-15
Filing date: 2020-01-15
Publication date: 2021-07-22

Abstract

本実施形態に係る決済処理装置は、生成部と、署名部と、証明部とを含む。生成部は、取引に関するトランザクションを生成する。署名部は、前記トランザクションに対して第１秘密鍵を用いてデジタル署名する。証明部は、取引において信頼される第三者により認証された第２公開鍵に対応する第２秘密鍵を用いてデジタル署名をすることにより、前記トランザクションの真正性を証明する。

Description

決済処理装置、決済処理プログラムおよび決済処理システム

　本発明は、決済処理装置、決済処理プログラムおよび決済処理システムに関する。

　暗号通貨に代表されるブロックチェーンを利用した取引において、取引が発生してから当該取引が承認される、すなわち決済が完了するまでにかなりの時間を要する。ビットコイン（登録商標）の例では、トランザクションが生成されてから決済が完了するまで１時間近くタイムラグを生じることになる。よって、例えば、実店舗での商品の購入のため、支払いに暗号通貨を用いることを想定すると、決済までに１時間を要する暗号通貨は決済手段としては現実的ではない。すなわち、ブロックチェーンを用いた決済取引の日常利用は、導入が難しいという課題がある。
　そのため、決済までの時間を短縮して暗号通貨により即時決済を実現することが望まれるが、上述のブロックチェーンの仕組みでは、無理に即時決済を行おうとすると、同じコインが２度使われる二重支払い問題が発生する可能性がある。
　このような即時決済を意識した二重支払い問題に対する対策として、メインのブロックチェーンの入金トランザクションを含むブロック周辺をサブチェーンとして抽出し、暗号通貨のウォレット側で入金を確認させる手法がある（例えば、非特許文献１）。

Dmitrienko et al., "Secure Wallet-Assisted Offline Bitcoin Payments with Double-Spender Revocation", Proceedings of the 2017 ACM on Asia Conference on Computer and Communications Security, April 2017, Pages 520-531.

　しかし、非特許文献１では、サブチェーンの生成に要した時間を正確に計測する必要があり、信頼できるタイムスタンプサーバが必要である。あるいは、入金したコインに使用期限を設け、一定期間を過ぎると入金したコインを使用できなくすることにより信頼できるタイムスタンプサーバを不要とする手法もあるが、この場合はユーザビリティに欠けるという問題がある。

　本発明は、上述した事情を考慮してなされたものであり、ブロックチェーンを用いた即時決済または即時契約を実行できることを目的とする。

　上述の課題を解決するため、本実施形態に係る決済処理装置は、生成部と、署名部と、証明部とを含む。生成部は、取引に関するトランザクションを生成する。署名部は、前記トランザクションに対して第１秘密鍵を用いてデジタル署名する。証明部は、取引において信頼される第三者により認証された第２公開鍵に対応する第２秘密鍵を用いてデジタル署名をすることにより、前記トランザクションの真正性を証明する。

　本発明の決済処理装置によれば、ブロックチェーンを用いた即時決済または即時契約を実行できる。

本実施形態に係る支払い側の決済処理装置を示すブロック図。本実施形態に係る受け取り側の決済処理装置を示すブロック図。本実施形態に係る支払い側の決済処理装置における入金処理を示すフローチャート。本実施形態に係る受け取り側の決済処理装置における決済処理を示すシーケンス図。本実施形態に係る受け取り側の決済処理装置における暗号通貨の償還処理を示すシーケンス図。

　暗号通貨に代表される、ブロックチェーンを用いた決済および契約（いわゆるスマートコントラクト）は、取引について当事者間で合意が成立して発行された後、次の２つのイベントを経て、取引が覆されない状態（ファイナリティともいう）に達し、この状態を取引が承認（コンファームともいう）された状態であるという。
　１つ目のイベントは、取引に関するトランザクションがブロックに取り込まれることである。２つ目のイベントは、当該ブロックの後に所定数以上の十分な数の新しいブロックが追加されることである。所定数以上の十分な数のブロックとは、暗号通貨の一種であるビットコインの場合は、５，６個のブロックであればよい。これは、ビットコインでは、１０分当たり１つのブロックがブロックチェーンに追加されるので、現状のマイニングの困難さとマイニングに用いる計算機の計算パワーとを考慮すると、不正を行なえない程度に安全であるといえ、十分な数のブロックであるとみなせるからである。一方、６個のブロックが追加された際に取引が承認されたと仮定する場合、決済までに１０分×６＝６０分かかるため、このままでは日常の決済手段としては導入しにくい。
　本実施形態に係る決済処理装置、決済処理プログラムおよび決済処理システムによれば、既存のブロックチェーンの仕組みをほとんど変更することなく、即時決済または即時契約を可能とする。

　以下、図面を参照しながら本発明の実施形態に係る決済処理装置、決済処理プログラムおよび決済処理システムについて詳細に説明する。なお、以下の実施形態中では、同一の番号を付した部分については同様の動作を行うものとして、重ねての説明を省略する。

　本実施形態では、ビットコイン（登録商標）に代表される暗号通貨について、取引履歴が記録されたブロックチェーンネットワークを用いた決済を行う場合を例に説明する。なお、暗号通貨に限らず、電子マネー、仮想マネー、各社のポイントサービスで提供されるポイントなどの貨幣に可換な決済手段であってもよい。また、土地などの不動産の移転、保険の契約などの取引をブロックチェーンで実現するスマートコントラクトについても同様に、本実施形態に係る決済処理装置、決済処理プログラムおよび決済処理システムを適用可能である。

　本実施形態に係る暗号通貨の支払い側の決済処理装置について、図１のブロック図を参照して説明する。支払い側の決済処理装置は、支払装置とも呼ぶ。

　本実施形態に係る支払い側の決済処理装置１は、ハードウェアおよび／またはソフトウェアにより耐タンパー性を有してもよい。ハードウェアにより耐タンパー性を有するとは、決済処理装置１のみで耐タンパー性を有するように構成される場合と、耐タンパー性を有するデバイスに決済処理装置１が含まれる場合とを含む。
　例えば、ＳＩＭ（Subscriber Identity Module）、ＵＳＩＭ（Universal SIM）といったセキュアエレメントに代表される耐タンパー性を有するハードウェアに、決済処理装置１が格納されてもよい。また、セキュアエレメントに限らず、ＡＲＭ（登録商標）のＴｒｕｓｔＺｏｎｅ（登録商標）によるセキュア機構、Ｉｎｔｅｌ（登録商標）のＩｎｔｅｌ　ＳＧＸなどのセキュア機構があり、ハードウェアとソフトウェアとが協働したセキュア機構を有するハードウェアに決済処理装置１が格納されてもよい。
　難読化（Obfuscation）などによりソフトウェアが耐タンパー性を有すると見做される場合は、決済処理装置１をソフトウェアで実現してもよい。

　決済処理装置１は、処理回路１１と、メモリ１２と、通信インタフェース１３とを含む。処理回路１１は、管理部１１１と、生成部１１２と、署名部１１３と、証明部１１４と、送受信部１１５とを含む。処理回路１１は、ＣＰＵ（Central Processing Unit）やＧＰＵ（Graphics Processing Unit）などの１つの処理回路、またはＡＳＩＣ（Application Specific Integrated Circuit）やＦＰＧＡ（Field Programmable Gate Array）などの集積回路により構成される。処理回路１１と、メモリ１２と、通信インタフェース１３とはバスを介してデータを送受信可能に接続される。なお、これに限らず、各部が単独の処理回路または単独の集積回路として構成されてもよい。

　管理部１１１は、後述のメモリ１２に格納される暗号通貨のウォレットに含まれる、ユーザにより生成された秘密鍵（第１秘密鍵ともいう）と第１秘密鍵に対応する公開鍵（第１公開鍵ともいう）との１以上のペアを管理する。管理部１１１は、公開鍵に基づく１以上の口座と当該１以上の口座それぞれに対応する残高とを管理する。ビットコインのような残高の分割を許さないシステム（UTXO: Unspent Transaction Output)等の場合、残高は入金金額（未使用）か０（使用済）の２通りの値のみをとる。管理部１１１は、取引において信頼される第三者に認証された公開鍵（第２公開鍵ともいう）と第２公開鍵に対応する秘密鍵（第２秘密鍵あるいは、暗号通貨の取引において信頼される第三者に認証された秘密鍵ともいう）とのペアを管理する。
　取引において信頼される第三者とは、本実施形態では、暗号通貨の取引において信頼される第三者であり、例えば、上述したような耐タンパー性を実現するハードウェアまたはソフトウェアの製造業者またはサービス提供者である。暗号通貨以外の取引、例えば、不動産の取引を想定したスマートコントラクトの場合、取引において信頼される第三者とは、トークン化された不動産を管理する管理会社などであればよい。
　取引において信頼される第三者による第２公開鍵の認証は、例えば、決済処理装置１内で、ユーザにより第２秘密鍵および対応する第２公開鍵が生成され、第２公開鍵に対し暗号通貨の取引において信頼される第三者の証明書の発行がなされることで、認証が実現されてもよい。
　また、取引において信頼される第三者（例えば、製造業者）が、予め第２秘密鍵および対応する第２公開鍵を生成し、併せて第三者の証明書を発行しておく。取引において信頼される第三者が、耐タンパー性を有するハードウェアに第２秘密鍵、対応する第２公開鍵および証明書を予め格納しておくことで、信頼される第三者による第２公開鍵の認証が実現されてもよい。

　生成部１１２は、暗号通貨の取引に関するトランザクションを生成する。
　署名部１１３は、トランザクションに対して第１秘密鍵を用いてデジタル署名する。
　証明部１１４は、第２秘密鍵を用いてデジタル署名をすることにより、トランザクションの真正性を証明する。証明部１１４の具体的な処理については後述する。
　送受信部１１５は、受け取り側から公開鍵と要求金額などの情報を受信し、トランザクションなどを送信する。

　メモリ１２は、支払い側のユーザのウォレットを格納する。ウォレットには、第１秘密鍵と第１公開鍵とのペア、第２秘密鍵と第２公開鍵とのペアが含まれる。メモリ１２は、ＲＯＭ（Read Only Memory）やＲＡＭ（Random Access Memory）、ＨＤＤ（Hard Disk Drive）、ＳＳＤ（Solid State Drive）、集積回路記憶装置等の記憶装置により構成される。

　通信インタフェース１３は、所定の通信規格に準拠した、決済処理装置１と外部装置との間でデータ送受信を行うためのインタフェースである。通信規格としては、４Ｇ，５Ｇなどのモバイルネットワーク、Ｗｉ－Ｆｉ（登録商標）などの無線ＬＡＮ、Ｂｌｕｅｔｏｏｔｈ（登録商標）、ＮＦＣ（Near Field Communication）などの無線ネットワーク、あるいはＬＡＮ、ＵＳＢ(Universal Serial Bus)などの有線ネットワークなどを想定する。

　次に、本実施形態に係る暗号通貨の受け取り側の決済処理装置について、図２のブロック図を参照して説明する。受け取り側の決済処理装置は、決済装置とも呼ぶ。
　なお、受け取り側の決済処理装置２についても、支払い側の決済処理装置１と同様に耐タンパー性を有してもよい。

　受け取り側の決済処理装置２は、処理回路２１と、メモリ２２と、通信インタフェース２３とを含む。処理回路２１は、管理部２１１と、送受信部２１２と、検証部２１３と、受理部２１４と、生成部２１５と、署名部２１６とを含む。

　管理部２１１は、ブロックチェーンの全部または一部分であるローカルのブロックチェーンを管理する。ローカルのブロックチェーンとは、決済処理装置２が最後にネットワーク接続した時点での最新のブロックチェーンを示す。一般に、最新のブロックチェーンは最新のブロックから所定数過去のブロックまではフォークと呼ばれる現象により合意が達成されていないことがある。しかし、ブロックチェーンが正常に動作していれば、最新のブロックから所定数過去のブロックを除いたブロックチェーン（プレフィックス）については完全に合意が達成されていると見做すことができる。
　送受信部２１２は、第２公開鍵と、支払い取引に関する支払トランザクションを受信する。また、後述の償還処理の場合は、損失を補償するための償還トランザクションを送信する。

　検証部２１３は、支払い元の残高が支払額以上であり、支払トランザクションが有効であり、支払トランザクションの出所が信頼できる否かを検証する。
　受理部２１４は、支払い元の残高が支払額以上であり、支払トランザクションが有効であり、支払トランザクションの出所を証明する信頼できる場合、当該支払トランザクションがその後にブロックチェーンによって承認されると判定できるため、支払トランザクションに示される取引を受理する。なお、受理部２１４により受理された後は、支払トランザクションの取引内容に応じ、暗号通貨の受け取り側のユーザが契約を実行してもよいし、外部の実行部が、受理された取引を実行してもよい。

　生成部２１５は、後述の償還処理において、償還トランザクションを生成する。
　署名部２１６は、償還トランザクションに対して、メモリ２２に格納されるウォレットに含まれる秘密鍵でデジタル署名する。

　メモリ２２は、受け取り側のユーザのウォレットと直近のネットワーク接続時に取得したブロックチェーンをローカルのブロックチェーンとして格納する。ウォレットには、受け取り側のユーザにより生成された秘密鍵（第３秘密鍵ともいう）と第３秘密鍵に対応する公開鍵（第３公開鍵ともいう）とのペアが含まれる。
　通信インタフェース２３は、通信インタフェース１３と同様であるため、具体的な説明を省略する。

　なお、図１に示す支払い側の決済処理装置と図２に示す受け取り側の決済処理装置とは、図１および図２に示すそれぞれの構成を含む１つの決済処理装置として構成されてもよい。この場合、支払い側として決済処理装置が動作する場合は、図１に示す構成が機能すればよいし、受け取り側として決済処理装置が動作する場合は、図２に示す構成が機能すればよい。

　次に、本実施形態に係る支払い側の決済処理装置１に関する暗号通貨の入金処理について図３のフローチャートを参照して説明する。
　本実施形態では、ウォレットＷは、決済処理装置１のメモリ１２に格納されてもよいし、外部装置（図示せず）に格納されてもよい。以下では、ユーザのウォレットＷから新しい口座ｗに暗号通貨を移動することを想定し、ウォレットＷの残高はゼロ以上であることを想定する。

　ステップＳ３０１では、生成部１１２が、新しい第１秘密鍵と第１公開鍵のペアと対応する口座ｗを生成する。口座ｗは、文字列で表現されるアドレスであり、例えば、第１公開鍵のハッシュ値を計算し、当該ハッシュ値をＢａｓｅ５８Ｃｈｅｃｋなどのエンコード形式で文字列にエンコードした文字列を口座ｗとすればよい。
　ステップＳ３０２では、ウォレットＷが、新しい口座ｗに金額ｂ_ｌの暗号通貨を移動させるための入金取引に関する入金トランザクションτ_ｌを生成する。入金トランザクションτ_ｌは、暗号通貨の移動元の口座（ここではウォレットＷのアドレス）、暗号通貨の移動先の口座（ここでは口座ｗのアドレス）、移動する金額（ここではｂ_ｌ）に関する情報を含む。

　ステップＳ３０３では、ウォレットＷが、入金トランザクションτ_ｌに対して第１秘密鍵を用いてデジタル署名する。第１秘密鍵でデジタル署名を行うことで、入金トランザクションτ_ｌが有効となる。
　ステップＳ３０４では、ウォレットＷが、入金トランザクションτ_ｌをブロックチェーンネットワークにブロードキャスト送信する。
　ステップＳ３０５では、ウォレットＷが、ブロックチェーンネットワークからブロックＢ_iを取得する。

　ステップＳ３０６では、ウォレットＷが、入金トランザクションτ_ｌが承認済みであるか否か、すなわち、取得したブロックＢ_ｉに入金トランザクションτ_ｌが取り込まれているか否かを判定する。具体的には例えば、ブロックＢ_ｉがマークルツリー形式のトランザクション集合情報を含んでいれば、ブロックＢ_ｉのマークルルートおよびマークルパスを計算することで、既存の手法により、ブロックＢ_ｉに入金トランザクションτ_ｌが含まれているか否かを判定できる。
　取得したブロックＢ_ｉに入金トランザクションτ_ｌが取り込まれていれば、ステップＳ３０７に進み、取得したブロックＢ_ｉに入金トランザクションτ_ｌが取り込まれていなければ、ステップＳ３０５に戻り同様の処理を繰り返す。

　ステップＳ３０７では、ウォレットＷが、入金トランザクションτ_ｌがブロックＢ_ｉに取り込まれていることを示す入金証明情報τ_ｌ ^*を生成する。入金証明情報τ_ｌ ^*は、τ_ｌがブロックＢ_ｉが持つトランザクションの集合に含まれていることを証明する補助情報（witness）である。
　入金証明情報τ_ｌ ^*は、例えば、マークルツリーにおけるマークルルートから入金トランザクションτ_ｌを示すマークルリーフまでの経路における各節において兄弟にあたる節のハッシュ値の集合である。入金証明情報τ_ｌ ^*は、ゼロ知識証明におけるWitnessでもよい。入金証明情報τ_ｌ ^*を用いることで、（１）式のメンバーシップ検査関数が定義でき、トランザクションがブロックに含まれることを示すメンバーシップ証明を実現できる。

　　　　member（Ｂ，τ_ｌ，τ_ｌ ^*）＝１（if　τ_ｌ∈Ｂ） otherwise 0　　　（１）
　ステップＳ３０８では、決済処理装置１が、送受信部１１５において通信インタフェース１３を介して (Ｂ，τ_ｌ，τ_ｌ ^*）を受信し、証明部１１４でmember（Ｂ，τ_ｌ，τ_ｌ ^*）＝１を確認したときに限り、管理部１１１が、入金トランザクションτ_ｌと入金証明情報τ_ｌ ^*との組（τ_ｌ、τ_ｌ ^*）をメモリ１２に格納する。
　ステップＳ３０９では、管理部１１１が、口座ｗの残高を更新する。ここでは、入金トランザクションτ_ｌに従って、口座ｗの残高がｂ_ｌに設定される。

　なお、１つの口座についての暗号通貨の入金は、１回のみに限らず、１つの口座について複数回暗号通貨が入金されてもよい。また、１つの口座からの暗号通貨の出金は、残高がある限り複数回の出金が可能なものに限らず、１つの口座からの暗号通貨の出金が１回のみに限定されてもよい。

　次に、本実施形態に係る受け取り側の決済処理装置２の決済処理について図４のフローチャートを参照して説明する。図４に示す決済処理は、支払い側の決済処理装置１（Ｘ）と受け取り側の決済処理装置２（Ｙ）との間でオフラインの状態で実行することができる。図４に示す決済処理装置１および決済処理装置２により、決済処理システムを実現できる。

　ステップＳ４０１では、例えば受け取り側の決済処理装置２の送受信部２１２から、通信インタフェース１３を介して、受け取り側の第３公開鍵ＰＫｙに対応する口座yと暗号通貨の要求金額ｂ_０とを支払い側の決済処理装置１に送信する。
　ステップＳ４０２では、支払い側の決済処理装置１の管理部１１１が、口座ｗの残高を確認する。ここでは、口座ｗの残高ｂ_ｌがｂ_０以上である、つまりｂ_ｌ≧ｂ_０であるとする。なお、残高がｂ_０未満であれば、処理を終了する。ただし、決済処理装置１が複数の口座を管理しており、合計の残高がｂ_０以上であれば、複数の口座からの支払いとして処理する。

　ステップＳ４０３では、支払い側の決済処理装置１の管理部１１１が、口座ｗの残高からｂ_０を引いた新たな残高を計算する。
　ステップＳ４０４では、支払い側の決済処理装置１の生成部１１２が、口座ｗから受け取り側にｂ_ｏの暗号通貨を支払う内容を示す支払トランザクションτ_０を生成する。さらに生成部１１２は、口座ｗに関する入金情報を含む支払証明情報を生成する。支払証明情報は、入金トランザクションτ_ｌと入金証明情報τ_ｌ ^*との組（τ_ｌ、τ_ｌ ^*）でもよいし、受け取り側で効率化が要求される場合は、さらに支払トランザクションτ_０を含む組（τ_０，τ_ｌ，τ_ｌ ^*）であってもよい。

　ステップＳ４０５では、支払い側の決済処理装置１の署名部１１３が、支払トランザクションτ_０に対して第１秘密鍵ｓｋ_ｗでデジタル署名をする。
　ステップＳ４０６では、支払い側の決済処理装置１の証明部１１４が、支払証明情報に対して第２秘密鍵ｓｋ_Ｔでデジタル署名をする。

　ステップＳ４０７では、支払い側の決済処理装置１の送受信部１１５、通信インタフェース１３を介して、デジタル署名された支払トランザクションτ_０とデジタル署名された支払証明情報とを受け取り側の決済処理装置２に送信する。なお、支払い側の決済処理装置１から、受け取り側の決済処理装置２に対して、暗号通貨の取引において信頼される第三者が発行した第２公開鍵ＰＫ_Ｔに関する証明書が併せて送信されてもよい。

　ステップＳ４０８では、受け取り側の決済処理装置２の検証部２１３が、検証処理を実行する。具体的には、以下の３つの要件を全て満たすか否かを判定する。
　（ａ）入金トランザクションτ_ｌがブロックＢに取り込まれ、ブロックチェーンネットワークで入金トランザクションτ_ｌが承認されること。
　（ｂ）第１秘密鍵ｓｋ_ｗでデジタル署名された支払トランザクションτ_０が有効であること。
　（ｃ）第２秘密鍵ｓｋ_Ｔでデジタル署名された支払証明情報が暗号通貨の取引において信頼される第三者に認証された装置からの証明として有効であること。

　（ａ）の要件では、検証部２１３は、決済処理装置２のローカルにあるブロックチェーンＣ_Ｙの中に、入金トランザクションτ_ｌを含むブロックが含まれるか否か（つまり、τ_ｌ∈Ｃ_Ｙ ^「kであるか否か）を確認する。この場合、トランザクションをマークルツリーの形式で表現してマークルルートを示すハッシュ値を含むようブロックチェーンＣ_Ｙのブロックを保持しておけば、ブロックチェーンの全トランザクションを維持する必要が無い。よって、メモリ及び処理量において効率的に入金トランザクションτ_ｌの承認状況を検証できる。例えば、検証部２１３は、ブロックのマークルツリーのハッシュ値と、支払証明情報に含まれるマークルルートから入金トランザクションτ_ｌを示すマークルリーフまでのハッシュ値が連結して要約された値とを比較計算することで、（ａ）の要件を満たすと判定できる。

　（ｂ）では、第１秘密鍵ｓｋ_ｗでデジタル署名がなされ、かつ、支払トランザクションτ_０ローカルにあるブロックチェーンＣ_Ｙに照らして口座ｗの残高が負にならないようであれば、（ｂ）の要件を満たすと判定できる。

　（ｃ）では、第２秘密鍵ｓｋ_Ｔのデジタル署名が第２公開鍵ＰＫ_Ｔで検証でき、かつ暗号通貨の取引において信頼される第三者が発行した第２公開鍵ＰＫ_Ｔに関する証明書などで第２公開鍵ＰＫ_Ｔが有効であると検証できる場合、（ｃ）の要件を満たすと判定できる。

　検証部２１３により上述の（ａ）から（ｃ）までの要件がすべて満たされると検証できた場合に、支払い元の口座にも残高があり、信頼できるウォレットから生成された支払トランザクションτ_０であり、当該支払トランザクションτ_０がその後ブロックチェーンにおいて承認されるトランザクションであると判定できる。すなわち、支払トランザクションτ_０は即時に受理可能と判定できる。

　一方、上述の（ａ）から（ｃ）までの要件のうちの１つでも満たされない場合、支払トランザクションτ_０は正当でも即時に受理できるとは判断できないか、または不正なトランザクションであると考えられる。そのため、即時受理を断念し、支払トランザクションτ_０が正当なトランザクションの場合は通常のトランザクションとして、ブロックチェーンネットワークにブロードキャストする。なお、ここでは、支払トランザクションτ_０が即時受理可能であり、その後ブロックチェーンにおいて承認されるトランザクションであると判定したとする。

　ステップＳ４０９では、受け取り側の決済処理装置２の受理部２１４が、支払トランザクションτ_０に示される取引を受理し、即時決済または即時契約が実行される。例えば、自動販売機において暗号通貨での支払いがステップＳ４０９で受理された後、ユーザが指定した商品を排出するように自動販売機が設定されればよい。

　受け取り側の決済処理装置２は、取引を受理した場合、支払い側の決済処理装置１に取引が受理され、決済または契約が完了した旨を通知してもよい。また、受け取り側の決済処理装置２は、取引を受理しない、つまり支払トランザクションτ_０が即時受理不可能と判定した場合、支払トランザクションτ_０が即時受理不可能である旨を通知してもよい。

　なお、検証部２１３は、ステップＳ４０８の（１）の要件を検証する場合に、ローカルにあるブロックチェーンＣ_Ｙのブロックから所定数ｋ（ｋは自然数）のブロックを最新のブロック（末尾のブロック）から除いた残りのブロックチェーンの中に、入金トランザクションτ_ｌが含まれることを入金証明情報によって確認してもよい。これは、ステップＳ４０８の処理はオフラインでの処理を想定しているため、ローカルで取得しているブロックチェーンＣ_Ｙは最新のものではない可能性がある。また、ローカルで取得しているブロックチェーンＣ_Ｙの末尾にある数ブロックは、ブロックチェーンネットワークの状態によってはフォークなどの影響で合意が達成されていない可能性があるため、当該ブロックに含まれる入金トランザクションτ_ｌが承認されていない可能性があるからである。

　一方、現在から所定期間前のブロックに入金トランザクションτ_ｌが取り込まれていれば、取引が覆されずに入金トランザクションτ_ｌが承認されない確率をkに応じていくらでも小さくできる。すなわち、ｋ個のブロックが除かれた残りのブロックチェーンに入金トランザクションτ_ｌを含むブロックが取り込まれていれば、取引の信頼性が十分に高いといえる。なお、所定数ｋをどのような値にするかは、例えばビットコインでは、一般的にブロックチェーンのメインチェーンが維持されると考えられるブロック数である「ｋ=６」としてもよいし、取引の額に応じて決定してもよい。例えば、支払トランザクションの取引の金額が大きいほど、ブロックチェーンにブロックが取り込まれている可能性（取引の信頼性）が高くなるように、ｋが大きな値に設定されればよい。

　次に、受け取り側の決済処理装置２における暗号通貨の償還処理について図５のフローチャートを参照して説明する。ここでは、支払トランザクションτ₀が本当は無効であるにもかかわらず、上述したステップＳ４０８における条件が満たされていたため、受け取り側が即時決済又は即時契約を行い損失が発生した場合に、当該損失を補償する場合である。ここで、損失を補償する業者は、ウォレットを格納するためのデバイスを製造した製造業者などの取引において信頼される第三者でもよいし、補償を専門とする保険会社などの業者でもよい。

　ステップＳ５０１では、受け取り側の決済処理装置２の送受信部２１２が、ブロックチェーンネットワークに、支払トランザクションτ₀をブロードキャストする。
　ステップＳ５０２では、受け取り側の決済処理装置２の管理部２１１が、ブロックチェーンネットワークを監視し、保有するローカルのブロックチェーンのブロックＢを更新する。

　ステップＳ５０３では、受け取り側の決済処理装置２の検証部２１３が、支払トランザクションτ_０がブロックチェーンネットワークにおいて承認されるか、支払トランザクションτ_０が無効であるかを判定する。支払トランザクションτ_０がブロックチェーンネットワークにおいて承認されれば、通常のトランザクションによる暗号通貨の受け取り処理となる。ここでは、支払トランザクションτ_０が無効である場合を想定する。
　ステップＳ５０４では、受け取り側の決済処理装置２の生成部２１５が、償還処理を行うため、償還トランザクションτ_ｒを生成する。償還トランザクションτ_ｒは、支払証明情報と、支払トランザクションτ_０を含み、支払トランザクションτ_０を決済処理装置２が即時受理したことの正当性を証明する。

　ステップＳ５０５では、受け取り側の決済処理装置２の生成部２１５が、償還トランザクションτ_ｒに対して第３秘密鍵を用いてデジタル署名する。
　ステップＳ５０６では、受け取り側の決済処理装置２の送受信部２１２が、デジタル署名された償還トランザクションτ_ｒを補償業者Ｔに送信する。

　ステップＳ５０７では、補償業者Ｔが、償還トランザクションτ_ｒを調査する。ここでは、償還トランザクションτ_ｒの内容が正当であると判定されたとする。
　ステップＳ５０８では、補償業者Ｔが、受け取り側の損失ｂ_ｏを補償するために、補償トランザクションτ_Ｔを生成する。
　ステップＳ５０９では、補償業者Ｔが、補償トランザクションτ_Ｔをブロックチェーンネットワークにブロードキャストする。補償トランザクションτ_Ｔが真正であれば、補償トランザクションτ_Ｔがブロックチェーンネットワークに承認されるので、受け取り側に対して暗号通貨が補償される。

　以上に示した本実施形態によれば、支払い側は、ウォレットを格納する耐タンパー性を有するデバイスの製造業者など、取引において信頼される第三者により認証された第２秘密鍵を用いて支払証明情報にデジタル署名する。受け取り側は、支払証明情報が取引において信頼される第三者により認証された鍵を用いて署名され、かつ一定の条件を満たしていることが確認できれば、支払い側のトランザクションを受理する。
　これによって、ビットコインなどの暗号通貨に代表されるブロックチェーンネットワークに修正を加えることなしに、即時決済および即時契約を実行可能とする。また、トランザクションの真正性の検証は受け取り側で確認するため、支払い側のウォレットは、検証のためのブロックチェーンをウォレットに格納する必要がない。よって支払い側では、ブロックチェーンの検証のためのタイムスタンプサーバが不要であり、また入金から一定時間経過すると使用できなくなるという制約を設けることなく、軽量な耐タンパー性のウォレットを実現できる。

　なお、本実施形態に係る決済処理装置１、決済処理装置２および決済処理システムの利用例としては、上述したもののほか、コンビニエンスストアのレジでの支払いに暗号通貨を用いることもできる。また、インターネットによりデジタルコンテンツまたはデジタルサービスの提供を受ける場合にも適用できる。
　また、インターネットにより証券取引またはデリバティブ取引を行う場合でも、証券会社に預かり金を供託することなく即時取引を成立させることができる。また、インターネットによりユーザの行動の直前に保険商品を購入することもできる。また、その場で当落が判明するスピードくじなどの購入においても適用できる。その他、即時完了性が要求される取引について本実施形態に係る決済処理システムを導入することができる。

　上述の実施形態の中で示した処理手順に示された指示は、ソフトウェアであるプログラムに基づいて実行されることが可能である。汎用の計算機システムが、このプログラムを予め記録媒体に記憶しておき、記憶されたプログラムを読み込むことにより、上述した識別装置による効果と同様な効果を得ることも可能である。さらに、本実施形態における記録媒体は、コンピュータあるいは組み込みシステムと独立した媒体に限らず、ＬＡＮやインターネット等により伝達されたプログラムをダウンロードして記憶または一時記憶した記録媒体も含まれる。

　なお、本願発明は、上記実施形態に限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で種々に変形することが可能である。また、各実施形態は可能な限り適宜組み合わせて実施してもよく、その場合組み合わせた効果が得られる。更に、上記実施形態には種々の段階の発明が含まれており、開示される複数の構成要件における適当な組み合わせにより種々の発明が抽出され得る。

１，２…決済処理装置
１１，２１…処理回路
１２，２２…メモリ
１３，２３…通信インタフェース
１１１，２１１…管理部
１１２，２１５…生成部
１１３，２１６…署名部
１１４…証明部
１１５，２１２…送受信部
２１３…検証部
２１４…受理部

Claims

　取引に関するトランザクションを生成する生成部と、
　前記トランザクションに対して第１秘密鍵を用いてデジタル署名する署名部と、
　取引において信頼される第三者により認証された第２公開鍵に対応する第２秘密鍵を用いてデジタル署名をすることにより、前記トランザクションの真正性を証明する証明部と、
　を具備する決済処理装置。
　前記署名部は、前記トランザクションが第１口座からの支払い取引に関する支払トランザクションである場合、前記支払トランザクションに対して前記第１秘密鍵を用いてデジタル署名し、
　前記証明部は、前記第１口座に関する入金情報を含む支払証明情報に対して前記第２秘密鍵を用いてデジタル署名する、請求項１に記載の決済処理装置。
　前記支払証明情報は、前記第１口座への入金取引に関する入金トランザクションと、取引履歴が記録されたブロックチェーンのブロックに前記入金トランザクションが取り込まれていることを示す入金証明情報とを含む情報、または、前記第１秘密鍵でデジタル署名された支払トランザクションと、前記入金トランザクションと、前記入金証明情報とを含む情報である、請求項２に記載の決済処理装置。
　１以上の口座と、前記１以上の口座それぞれに対応する残高とを管理する管理部をさらに具備し、
　前記管理部は、
　　第１口座への入金取引に関する入金トランザクションが存在する場合、取引履歴が記録されたブロックチェーンのブロックに前記入金トランザクションが取り込まれていることを示す入金証明情報と前記入金トランザクションとの組を保持し、
　　前記入金取引の内容に基づき、前記第１口座の残高を更新する、請求項１から請求項３のいずれか１項に記載の決済処理装置。
　前記ブロックは、前記ブロックに含まれるトランザクションの集合を特定するマークルツリー形式の情報を含み、
　前記入金トランザクションは、前記マークルツリーにおけるマークルリーフの１つであり、
　前記入金証明情報は、前記入金トランザクションに対応するマークルリーフからマークルルートまでの経路におけるハッシュ値の集合を含む、請求項４に記載の決済処理装置。
　耐タンパー性を有する請求項１から請求項５のいずれか１項に記載の決済処理装置。
　取引履歴が記録されたブロックチェーンの全部または一部分を管理する管理部と、
　取引において信頼される第三者の公開鍵と、デジタル署名された、支払い元の第１口座からの支払い取引に関する支払トランザクションと、デジタル署名された、前記支払トランザクションの支払い元である口座に関する入金情報を含む支払証明情報を受信する受信部と、
　前記支払トランザクションが前記ブロックチェーンに照らして有効であり、前記支払トランザクションのデジタル署名が有効であり、前記支払証明情報に対するデジタル署名が前記公開鍵に基づき真正であると検証できた場合、前記支払トランザクションに示される取引を受理する受理部と、
　を具備する決済処理装置。
　前記支払証明情報は、前記第１口座への入金取引に関する入金トランザクションと、ブロックチェーンのブロックに前記入金トランザクションが取り込まれていることを示す入金証明情報とを含み、
　前記管理部で管理される前記ブロックチェーンから所定数のブロックを末尾から除いた残りのブロックチェーンの中に、前記入金トランザクションが含まれることを前記入金証明情報を用いて検証する検証部をさらに具備し、
　前記受理部は、前記残りのブロックチェーンの中に前記入金トランザクションが含まれることが検証できた場合、前記支払トランザクションに示される取引を受理する、請求項７に記載の決済処理装置。
　コンピュータに、
　取引に関するトランザクションを生成する生成機能と、
　前記トランザクションに対して第１秘密鍵を用いてデジタル署名する署名機能と、
　取引において信頼される第三者により認証された第２公開鍵に対応する第２秘密鍵を用いて、前記トランザクションの真正性を証明する証明機能と、
を実現させるための決済処理プログラム。
　コンピュータに、
　取引において信頼される第三者の公開鍵と、支払い元の第１口座からの支払い取引に関するデジタル署名された支払トランザクションとを取得する取得機能と、
　取引履歴が記録されたブロックチェーンの全部または一部分に照らして前記支払トランザクションが有効であり、前記支払トランザクションのデジタル署名が有効であり、前記支払トランザクションの支払い元である口座に関する入金情報を含む支払証明情報に対するデジタル署名が前記公開鍵に基づき真正であるか否かを検証する検証機能と、
　前記検証機能による検証が成功した場合、前記支払トランザクションに示される取引を受理する受理機能と、
を実現させるための決済処理プログラム。
　支払い側の支払装置と受け取り側の決済装置とを含む決済処理システムであって、
　前記支払装置は、
　　第１口座からの支払い取引に関する支払トランザクションを生成する生成部と、
　　前記支払トランザクションに対して第１秘密鍵を用いてデジタル署名する署名部と、
　　第１口座に関する入金情報を含む支払証明情報に対して、取引において信頼される第三者により認証された第２公開鍵に対応する第２秘密鍵を用いてデジタル署名する証明部と、
　を具備し、
　前記決済装置は、
　　取引履歴が記録されたブロックチェーンの全部または一部分を管理する管理部と、
　　第２秘密鍵に対応する公開鍵と、デジタル署名された前記支払トランザクションと、デジタル署名された前記支払証明情報とを受信する受信部と、
　　前記支払トランザクションが前記ブロックチェーンに照らして有効であり、前記支払トランザクションのデジタル署名が有効であり、前記支払証明情報に対するデジタル署名が前記公開鍵に基づき真正であると検証できた場合、前記支払トランザクションに示される取引を受理する受理部と、
　を具備する、決済処理システム。