知財求人 - 知財ポータルサイト「IP Force」
▶ エヌイーシー ラボラトリーズ ヨーロッパ ゲーエムベーハーの特許一覧
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2024-12-05
(54)【発明の名称】高速ブロックチェーン支払い方法およびシステム
(51)【国際特許分類】
G06Q 20/06 20120101AFI20241128BHJP
H04L 9/32 20060101ALI20241128BHJP
【ＦＩ】
G06Q20/06
H04L9/32 200Z
【審査請求】未請求
【予備審査請求】未請求
(21)【出願番号】P 2023552336
(86)(22)【出願日】2022-09-27
(85)【翻訳文提出日】2023-08-29
(86)【国際出願番号】 EP2022076860
(87)【国際公開番号】W WO2023083525
(87)【国際公開日】2023-05-19
(31)【優先権主張番号】21207778.8
(32)【優先日】2021-11-11
(33)【優先権主張国・地域又は機関】EP
(81)【指定国・地域】
(71)【出願人】
【識別番号】517451940
【氏名又は名称】エヌイーシー ラボラトリーズ ヨーロッパ ゲーエムベーハー
(74)【代理人】
【識別番号】100108453
【弁理士】
【氏名又は名称】村山 靖彦
(74)【代理人】
【識別番号】100110364
【弁理士】
【氏名又は名称】実広 信哉
(74)【代理人】
【識別番号】100133400
【弁理士】
【氏名又は名称】阿部 達彦
(72)【発明者】
【氏名】スヴェン・グナップ
(72)【発明者】
【氏名】カリ・コスティアイネン
(72)【発明者】
【氏名】ガッサン・カラメ
(72)【発明者】
【氏名】スルジャン・カプクン
【テーマコード（参考）】
5L020
【Ｆターム（参考）】
5L020AA12
(57)【要約】
高速ブロックチェーン支払いのための方法が開示され、支払いは、ユーザ(110)のアカウントからサービスプロバイダ(120)のプライベート担保アカウントへの資金の移動を伴う。実施形態によれば、方法は、サービスプロバイダ(120)によって、ユーザ(110)からプライベート支払い意図を受信するステップであって、プライベート支払い意図が、支払いインデックスと、ランダム支払いIDと、サービスプロバイダ(120)のプライベート担保アカウントのアドレスとを含む、ステップと、サービスプロバイダ(120)によって、サービスプロバイダ(120)の担保アカウントのアドレスをコミットメントによって置き換えることによって支払い意図を変更し、変更された支払い意図をブロックチェーン(140)のステートキーパー(130)の大多数に提供するステップと、サービスプロバイダ(120)によって、ブロックチェーン(140)のステートキーパー(130)から支払い承認を受信するステップであって、各支払い承認は、それぞれのステートキーパー(130)の秘密鍵を用いて署名された変更された支払い意図を含む、ステップと、サービスプロバイダ(120)によって、受信した支払い承認を評価し、正常に評価された支払い承認を集計し、集計結果をユーザ(110)に送信するステップと、サービスプロバイダ(120)によって、集計結果を検証した後にユーザ(110)によって作成された最終トランザクションを受信し、ユーザ(110)が所与のプロトコルに従って最終トランザクションを正しく構築したことを検証し、最終トランザクションの検証に成功した場合、支払いを受け入れるステップとを含む。
【特許請求の範囲】
【請求項1】
高速ブロックチェーン支払いのためのコンピュータ実装方法であって、支払いが、ユーザ(110)のアカウントからサービスプロバイダ(120)のプライベート担保アカウントへの資金の移動を伴い、前記方法が、前記サービスプロバイダ(120)によって、前記ユーザ(110)からプライベート支払い意図を受信するステップであって、前記プライベート支払い意図が、支払いインデックスと、ランダム支払いIDと、前記サービスプロバイダ(120)のプライベート担保アカウントのアドレスとを含む、ステップと、
前記サービスプロバイダ(120)によって、前記サービスプロバイダ(120)の担保アカウントの前記アドレスをコミットメントによって置き換えることによって支払い意図を変更し、前記変更された支払い意図をブロックチェーン(140)のステートキーパー(130)の大多数に提供するステップと、
前記サービスプロバイダ(120)によって、ブロックチェーン(140)のステートキーパー(130)から支払い承認を受信するステップであって、各支払い承認が、それぞれの前記ステートキーパー(130)の秘密鍵を用いて署名された前記変更された支払い意図を含む、ステップと、
前記サービスプロバイダ(120)によって、前記受信した支払い承認を評価し、正常に評価された支払い承認を集計し、集計結果を前記ユーザ(110)に送信するステップと、
前記サービスプロバイダ(120)によって、前記集計結果を検証した後に前記ユーザ(110)によって作成された最終トランザクションを受信し、前記ユーザ(110)が所与のプロトコルに従って前記最終トランザクションを正しく構築したことを検証し、前記最終トランザクションの検証に成功した場合、前記支払いを受け入れるステップと
を含む、コンピュータ実装方法。
【請求項2】
前記ユーザ(110)の支払い意図の前記ランダム支払いIDが、前記支払いインデックスの検証可能なランダム関数VRFハッシュを計算することによって生成される、請求項1に記載の方法。
【請求項3】
前記サービスプロバイダ(120)によって、前記ユーザ(110)から受信した前記支払い意図を変更するステップが、前記サービスプロバイダ(120)の担保アカウントの前記アドレスをコミットメントcm=C(m,rm)によって置き換えるステップを含み、mが、前記サービスプロバイダ(120)の担保アカウントの前記アドレスであり、rmが、ランダムなブラインド化係数であり、Cが、コミットメント関数である、請求項1または2に記載の方法。
【請求項4】
前記サービスプロバイダ(120)によって、前記ユーザ(110)の残高が前記支払いを実行するのに十分であることを示すために前記ユーザ(110)によって計算されたゼロ知識証明の正しさを検証することによって、前記ユーザ(110)から受信したプライベート支払い意図を評価するステップをさらに含む、請求項1から3のいずれか一項に記載の方法。
【請求項5】
前記サービスプロバイダ(120)によって、現在の支払いを含むすべての保留中の支払いの合計が前記ユーザ(110)の現在の担保残高よりも少ないことを示すために、ユーザの担保残高に対して、前記ユーザ(110)によって計算されたゼロ知識証明の正しさを検証することによって、前記ユーザ(110)から受信したプライベート支払い意図を評価するステップをさらに含む、請求項1から4のいずれか一項に記載の方法。
【請求項6】
前記ブロックチェーン(140)のステートキーパー(130)からの前記支払い承認が、それぞれの前記ステートキーパー(130)の前記秘密鍵を使用して、前記変更された支払い意図に対してそれぞれの前記ステートキーパー(130)によって計算されたBLS署名を含む、請求項1から5のいずれか一項に記載の方法。
【請求項7】
前記サービスプロバイダ(120)が、前記ステートキーパー(130)の少なくとも半分から支払い承認を受信すると、それぞれの前記ステートキーパー(130)の公開鍵を使用して、前記変更された支払い意図の前記ステートキーパー(130)の署名を検証し、集約された承認署名を取得するために、前記正常に検証された署名を集約する、請求項1から6のいずれか一項に記載の方法。
【請求項8】
前記ブロックチェーン(140)内で実行されるスマートコントラクト(150)が、前記ユーザ(110)の担保アカウント、前記サービスプロバイダ(120)の担保アカウント、および前記ブロックチェーン(140)のステートキーパー(130)の各々の担保アカウントを管理するために使用され、前記スマートコントラクトが、アカウントアドレスをElGamal準同型暗号化値にマッピングする辞書を記憶する、請求項1から7のいずれか一項に記載の方法。
【請求項9】
前記ブロックチェーン(140)内で実行されるスマートコントラクト(150)が、前記支払いを受け取ると、次のアクション、前記ユーザ(110)から前記サービスプロバイダ(120)に資金を転送する前記支払いをファイナライズするアクションと、
成功すると、前記ランダム支払いIDと、前記サービスプロバイダ(120)のコミットされたアドレスと、前記集約された承認署名と、前記承認するステートキーパー(130)の定足数とを、前記ユーザ(110)のファイナライズされたトランザクションのリスト内に記憶するアクションと
を実行する、請求項1から8のいずれか一項に記載の方法。
【請求項10】
前記スマートコントラクト(150)における前記ユーザ(110)の最終トランザクションが、前記ユーザ(110)および前記サービスプロバイダ(120)のプライベートアカウントにおける暗号化された支払い額を使用して実行される、請求項9に記載の方法。
【請求項11】
前記ブロックチェーン(140)内で実行されるスマートコントラクト(150)が、事前定義されたまたは設定可能な時間後にトランザクションが前記ブロックチェーン(140)上に現れない場合、前記サービスプロバイダ(120)によって開始される決済要求を処理するために使用される、請求項1から10のいずれか一項に記載の方法。
【請求項12】
前記サービスプロバイダ(120)によって、前記ユーザ(110)の前記プライベート担保アカウントまたはそれぞれの前記ステートキーパー(130)の前記プライベート担保アカウントのいずれかから機密の支払いを通じて払い戻されるように前記ユーザ(110)または前記ステートキーパー(130)に決済要求を指示するステップをさらに含む、請求項11に記載の方法。
【請求項13】
特に、請求項1から12のいずれか一項に記載の方法を実行するための、高速ブロックチェーン支払いのためのシステムであって、支払いが、ユーザ(110)のアカウントからサービスプロバイダ(120)のプライベート担保アカウントへの資金の移動を伴い、前記システムが、ユーザ（110）から、前記ユーザ(110)からのプライベート支払い意図を受信する動作であって、前記プライベート支払い意図が、支払いインデックスと、ランダム支払いIDと、前記サービスプロバイダ(120)のプライベート担保アカウントのアドレスとを含む、動作と、
前記サービスプロバイダ(120)の担保アカウントの前記アドレスをコミットメントによって置き換えることによって前記支払い意図を変更し、前記変更された支払い意図をブロックチェーン(140)のステートキーパー(130)の大多数に提供する動作と、
ブロックチェーン(140)のステートキーパー(130)から支払い承認を受信する動作であって、各支払い承認が、それぞれの前記ステートキーパー(130)の秘密鍵を用いて署名された前記変更された支払い意図を含む、動作と、
前記受信した支払い承認を評価し、正常に評価された支払い承認を集計し、集計結果を前記ユーザ(110)に送信する動作と、
前記集計結果を検証した後に前記ユーザ(110)によって作成された最終トランザクションを受信し、前記ユーザ(110)が所与のプロトコルに従って前記最終トランザクションを正しく構築したことを検証し、前記最終トランザクションの検証に成功した場合、前記支払いを受け入れる動作と
を行うように構成されたプロセッサ回路を備える、システム。
【請求項14】
高速ブロックチェーン支払いのための方法を実行するためのプロセッサ実行可能命令を記憶した非一時的なプロセッサ可読媒体であって、支払いが、ユーザ(110)のアカウントからサービスプロバイダ(120)のプライベート担保アカウントへの資金の移動を伴い、前記方法が、前記サービスプロバイダ(120)によって、前記ユーザ(110)からプライベート支払い意図を受信するステップであって、前記プライベート支払い意図が、支払いインデックスと、ランダム支払いIDと、前記サービスプロバイダ(120)のプライベート担保アカウントのアドレスとを含む、ステップと、
前記サービスプロバイダ(120)によって、前記サービスプロバイダ(120)の担保アカウントの前記アドレスをコミットメントによって置き換えることによって前記支払い意図を変更し、前記変更された支払い意図をブロックチェーン(140)のステートキーパー(130)の大多数に提供するステップと、
前記サービスプロバイダ(120)によって、ブロックチェーン(140)のステートキーパー(130)から支払い承認を受信するステップであって、各支払い承認が、それぞれの前記ステートキーパー(130)の秘密鍵を用いて署名された前記変更された支払い意図を含む、ステップと、
前記サービスプロバイダ(120)によって、前記受信した支払い承認を評価し、正常に評価された支払い承認を集計し、集計結果を前記ユーザ(110)に送信するステップと、
前記サービスプロバイダ(120)によって、前記集計結果を検証した後に前記ユーザ(110)によって作成された最終トランザクションを受信し、前記ユーザ(110)が所与のプロトコルに従って前記最終トランザクションを正しく構築したことを検証し、前記最終トランザクションの検証に成功した場合、前記支払いを受け入れるステップと
を含む、非一時的なプロセッサ可読媒体。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、高速ブロックチェーン支払いのための方法、システム、およびコンピュータ可読媒体に関する。
【背景技術】
【0002】
イーサリアムなどのパーミッションレス型ブロックチェーンとして実装されたデジタル通貨は、従来の支払いシステムとは根本的に異なる選択肢を提供する。最も顕著な違いの1つは、すべてのユーザアカウントの残高または支払いを管理する中央集権的エンティティが存在しないか、またはわずかしか存在しないことである。代わりに、各トランザクションは、誰でも参加することができる大規模な分散型システムによって承認される。これは、エンティティが支払いを検閲することを防止する強力な保証を提供する。
【0003】
しかしながら、そのようなシステムは、小売りまたはオンライン支払いなどのシナリオでは実用的ではない。特に、それらは、長い待ち時間を有し、オンチェーンのプライバシーを持たず、そのことは、日常の少額の支払いに使用することができなくする。これらの欠点に対処する手段が存在する。最も顕著な技法は、さらなる機能を提供するスマートコントラクトを活用することである。標準的なブロックチェーン支払いに加えて、短い待ち時間を提供するものと、オンチェーンプライバシーを提供するものの、小売り支払いに関連する2つのタイプのそのようなシステムが特定され得る。
【0004】
スマートコントラクトを通じて待ち時間の問題に対処する複数の技法が存在する。支払いチャネルは、ユーザが単一のサービスプロバイダとの関係を確立することを可能にする。しかしながら、それらは、そのような関係ごとに別々の固定された担保を必要とし、現実的ではない。支払いハブは、ユーザを複数のサービスプロバイダに接続するが、固定された担保は、大きく、したがって、より多数の登録ユーザに対して拡張できない。サイドチェーンは、検証エンティティのより小さいセットによって迅速に承認される支払いを可能にするが、追加の信頼仮定と高い通信の複雑さとを導入する。一方では、Snappy支払いシステム(参考のため、V. Mavroudis、K. Wust、A. Dhar、K. Kostiainen、およびS. Capkun:「Snappy: Fast On-Chain Payments with Practical Collaterals」、第27回Annual Network and Distributed System Security(NDSS)シンポジウム2020、2020年2月23～26日、米国カリフォルニア州サンディエゴ、https://www.ndss-symposium.org/wp-content/uploads/2020/02/24049-paper.pdfを参照)は、少額のユーザ担保を使用するが、パーミッションレス型ブロックチェーンの強力な検閲耐性保証に違反する。
【0005】
他方では、Zether支払いシステム(参考のため、B. Bunz、S. Agrawal、M. Zamani、およびD. Boneh:「Zether: Towards Privacy in a Smart Contract World」、2020年7月、423～443頁、https://crypto.stanford.edu/~buenz/papers/zether.pdfを参照)は、機密かつ匿名のトランザクションを提供することによって、オンチェーンプライバシーに対処する。これは、標準的なブロックチェーントランザクションよりもはるかに強力なセキュリティおよびプライバシーの保証を有するが、システムが待ち時間の問題に対処するいかなるメカニズムも提供しないので、その支払いは、遅い。
【0006】
大部分のシステムは、非常に特殊な追加の機能しか提供しない一方で、しばしば他の特性に違反していることがわかる。現在の先行技術において、(a)高速な支払い、(b)検閲に対する耐性、(c)少額の担保、(d)オンチェーンプライバシー、および(e)追加の信頼仮定がないことを提供するシステムは存在しない。
【先行技術文献】
【非特許文献】
【0007】
【非特許文献1】V. Mavroudis、K. Wust、A. Dhar、K. Kostiainen、およびS. Capkun:「Snappy: Fast On-Chain Payments with Practical Collaterals」、第27回Annual Network and Distributed System Security(NDSS)シンポジウム2020、2020年2月23～26日、米国カリフォルニア州サンディエゴ、https://www.ndss-symposium.org/wp-content/uploads/2020/02/24049-paper.pdf
【非特許文献2】B. Bunz、S. Agrawal、M. Zamani、およびD. Boneh:「Zether: Towards Privacy in a Smart Contract World」、2020年7月、423～443頁、https://crypto.stanford.edu/~buenz/papers/zether.pdf
【非特許文献3】S. Goldberg、L. Reyzin、D. Papadopoulos、およびJ. Vcelak、「Verifiable Random Functions (VRFs)」、Internet Engineering Task Force、Internet-Draft draft-irtf-cfrg-vrf-09、2021年5月、進行中[オンライン].利用可能: https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-vrf-09
【非特許文献4】T. P. Pedersen、「Non-interactive and information-theoretic secure verifiable secret sharing」、in Advances in Cryptology - CRYPTO '91、1992年、129～140頁
【非特許文献5】D. Boneh、B. Lynn、およびH. Shacham、「Short signatures from the Weil pairing」、in Advances in Cryptology - ASIACRYPT 2001、2001年、514～532頁
【非特許文献6】T. RistenpartおよびS. Yilek、「The power of proofs-of-possession: Securing multiparty signatures against rogue-key attacks」、in Advances in Cryptology - EUROCRYPT 2007、M. Naor、Ed. Berlin、Heidelberg: Springer Berlin Heidelberg、2007年、228～245頁
【非特許文献7】B. Bunz、J. Bootle、D. Boneh、A. Poelstra、P. Wuille、およびG. Maxwell、「Bulletproofs: Short proofs for confidential transactions and more」、Cryptology ePrint Archive、Report 2017/1066、2017年、https://eprint.iacr.org/2017/1066
【発明の概要】
【発明が解決しようとする課題】
【0008】
したがって、本発明の目的は、上述の欠点のうちの少なくともいくつかが軽減または克服されるように、高速ブロックチェーン支払いのための方法およびシステムを改善し、さらに開発することである。
【課題を解決するための手段】
【0009】
本発明によれば、前述の目的は、高速ブロックチェーン支払いのためのコンピュータ実装方法によって達成され、支払いは、ユーザのアカウントからサービスプロバイダのプライベート担保アカウントへの資金の移動を伴い、方法は、サービスプロバイダによって、ユーザからプライベート支払い意図を受信するステップであって、プライベート支払い意図が、支払いインデックスと、ランダム支払いIDと、サービスプロバイダのプライベート担保アカウントのアドレスとを含む、ステップと、サービスプロバイダによって、サービスプロバイダの担保アカウントのアドレスをコミットメントによって置き換えることによって支払い意図を変更し、変更された支払い意図をブロックチェーンのステートキーパー(statekeeper)の大多数に提供するステップと、サービスプロバイダによって、ブロックチェーンのステートキーパーから支払い承認を受信するステップであって、各支払い承認は、それぞれのステートキーパーの秘密鍵を用いて署名された変更された支払い意図を含む、ステップと、サービスプロバイダによって、受信した支払い承認を評価し、正常に評価された支払い承認を集計し、集計結果をユーザに送信するステップと、サービスプロバイダによって、集計結果を検証した後にユーザによって作成された最終トランザクションを受信し、ユーザが所与のプロトコルに従って最終トランザクションを正しく構築したことを検証し、最終トランザクションの検証に成功した場合、支払いを受け入れるステップとを含む。
【0010】
さらに、上述の目的は、独立請求項による、高速ブロックチェーン支払いのためのシステムによって、および非一時的なプロセッサ可読媒体によって達成される。
【0011】
本発明の実施形態は、ブロックチェーン支払い方法およびシステムを提供し、この方法およびシステムは、実際的な担保を伴う高速支払いおよびプライベート支払いの両方と、検閲耐性を含み、追加の信頼仮定を含まない強力なセキュリティ保証とを提供するハイブリッド手法をとる。
【0012】
本発明の一実施形態によれば、ユーザの支払い意図のランダム支払いIDは、支払いインデックスの検証可能なランダム関数VRFハッシュを計算することによって生成される。この点に関して、検証可能なランダム関数(VRF)は、鍵付き暗号ハッシュの公開鍵バージョンであることが留意される(参考のため、S. Goldberg、L. Reyzin、D. Papadopoulos、およびJ. Vcelak、「Verifiable Random Functions (VRFs)」、Internet Engineering Task Force、Internet-Draft draft-irtf-cfrg-vrf-09、2021年5月、進行中[オンライン].利用可能: https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-vrf-09を参照)。公開鍵pkを所有する誰もが、ハッシュの正しさを検証することができるが、秘密鍵skの所有者のみがハッシュを生成することができる。より正確には、入力値xが与えられると、秘密鍵skの所有者は、入力xに対するハッシュy=VRFhash(sk,x)を計算することができる。秘密鍵の所有者は、一致証明π=VRFprove(sk,x)を計算することもできる。VRFの重要な特性は、ハッシュアルゴリズムが、同じ入力のペア(sk,x)が与えられると、常に同じ出力yを生成するという意味において決定論的であることである。公開鍵と証明とを使用すると、ハッシュが正しく計算されたことを検証することができる。pk、x、およびπが与えられたとき、VRFverify(pk,x,π)出力が有効である場合、ハッシュは、有効である。誰もが、y=VRFproof2hash(π)を計算することによって、証明πからVRF出力yを決定論的に取得することができる。
【0013】
本発明の実施形態は、以下のVRFの特性のうちの1つまたは複数を利用する。
・信頼できる一意性:鍵が信頼できる方法において、すなわち、正しいランダム性で生成されたと仮定すると、計算的に制限された敵対者は、VRFverify(pk,x,π1)とVRFverify(pk,x,π2)の両方が有効に出力するようなpk、x、2つの異なるハッシュ出力y1およびy2、2つの証明π1およびπ2を見つけることができない。
・信頼できる衝突耐性:鍵が信頼できる方法で生成されたと仮定すると、敵対者が秘密鍵を知っている場合であっても、同じハッシュ出力を有するx1およびx2を見つけることは、計算的に実行不可能であるはずである。
・完全な疑似ランダム性:敵対的検証者は、本物のハッシュの証明を知ることなく、本物のハッシュ出力yとランダムなハッシュ出力とを区別することはできない。敵対者は、様々な選択された入力の出力ハッシュおよび証明を観察することをいつでも許可される。
・信頼できる一意性:鍵が信頼できる方法において、すなわち、正しいランダム性で生成されたと仮定すると、計算的に制限された敵対者は、VRFverify(pk,x,π1)とVRFverify(pk,x,π2)の両方が有効に出力するようなpk、x、2つの異なるハッシュ出力y1およびy2、2つの証明π1およびπ2を見つけることができない。
・信頼できる衝突耐性:鍵が信頼できる方法で生成されたと仮定すると、敵対者が秘密鍵を知っている場合であっても、同じハッシュ出力を有するx1およびx2を見つけることは、計算的に実行不可能であるはずである。
・完全な疑似ランダム性:敵対的検証者は、本物のハッシュの証明を知ることなく、本物のハッシュ出力yとランダムなハッシュ出力とを区別することはできない。敵対者は、様々な選択された入力の出力ハッシュおよび証明を観察することをいつでも許可される。
【0014】
本発明の一実施形態によれば、ユーザから受信した支払い意図のサービスプロバイダによる変更は、サービスプロバイダの担保アカウントのアドレスをコミットメントcm=C(m,rm)によって置き換えることを含み、ここで、mは、サービスプロバイダの担保アカウントのアドレスであり、rmは、ランダムなブラインド化係数であり、Cは、コミットメント関数である。一般に、暗号化コミットメントの目標は、隠されたままの値をコミットし、後の時点においてそれを明らかにすることである。Pedersenコミットメントは、そのようなスキームの1つの特定の変形である。これは、完全に隠蔽的であり(計算的に制限されていない敵対者は、元のメッセージについて何も学習することができない)、計算的に拘束的である(計算的に制限された敵対者は、同じコミットメントに関する2つの異なるメッセージを計算することができない)コミットメントを提供する。さらに、Pedersenコミットメントは、準同型であり、これは、2つのコミットメントが、元のメッセージの知識もブラインド化係数の知識も必要とせずに組み合わされ得ることを意味する。Pedersenコミットメントに関する詳細は、参照により本明細書に組み込まれるT. P. Pedersen、「Non-interactive and information-theoretic secure verifiable secret sharing」、in Advances in Cryptology - CRYPTO '91、1992年、129～140頁に記載されている。
【0015】
本発明の一実施形態によれば、サービスプロバイダが、ユーザの残高が支払いを実行するのに十分であることを示すためにユーザによって計算されたゼロ知識証明の正しさを検証することによって、ユーザから受信したプライベート支払い意図を評価することが規定され得る。
【0016】
本発明の一実施形態によれば、サービスプロバイダが、現在の支払いを含むすべての保留中の支払いの合計がユーザの現在の担保残高よりも少ないことを示すために、ユーザの担保残高に対して、ユーザによって計算されたゼロ知識証明の正しさを検証することによって、ユーザから受信したプライベート支払い意図を評価することが規定され得る。
【0017】
本発明の一実施形態によれば、ブロックチェーンのステートキーパーからの支払い承認は、それぞれのステートキーパーの秘密鍵を使用して、変更された支払い意図に対してそれぞれのステートキーパーによって計算されたBLS署名を含み得る。BLS(Boneh-Lynn-Shacham)デジタル署名(参考のため、D. Boneh、B. Lynn、およびH. Shacham、「Short signatures from the Weil pairing」、in Advances in Cryptology - ASIACRYPT 2001、2001年、514～532頁を参照)は、短く安全なデジタル署名を提供する署名スキームである。さらに、異なる署名者の複数の署名σ1、...、σnを単一の署名に集約することを可能にする。簡単にするために、ユーザは、それぞれ、署名作成、検証、および署名/公開鍵集約を実装する関数Sign(sk,m)、Vf(pk,m,σ)、AggrSig({σ1,...,σn})、AggrPk({pk1,...,pkn})を与えられると仮定することができる。
【0018】
本発明の一実施形態によれば、サービスプロバイダは、ステートキーパーの少なくとも半分から支払い承認を受信すると、それぞれのステートキーパーの公開鍵を使用して、変更された支払い意図のステートキーパーの署名を検証し、集約された承認署名を取得するために、正常に検証された署名を集約する。
【0019】
本発明の一実施形態によれば、ブロックチェーン内で実行されるスマートコントラクトが、ユーザの担保アカウント、サービスプロバイダの担保アカウント、およびブロックチェーンのステートキーパーの各々の担保アカウントを管理するために使用され得、スマートコントラクトは、アカウントアドレスをElGamal準同型暗号化値にマッピングする辞書を記憶する。スマートコントラクトは、ブロックチェーン上で実行され、データと対話するためのインターフェースを提供するソフトウェアである。言い換えれば、スマートコントラクトは、ブロックチェーン上で自動的に実行および動作するように構成されたコンピュータプログラムまたはトランザクションプロトコルである。具体的には、スマートコントラクトは、処理回路によって実行されると、処理回路にプログラム機能を実行させる、非一時的なプロセッサ可読媒体上に記憶されたプロセッサ実行可能プログラム(コード)である。コードは、ネットワーク上に存在するすべてのメンバーに利用可能である(すなわち、検査され得る)。当業者は、「スマートコントラクト」が、例えば、自動化のために使用されるブロックチェーンネットワークの技術的態様であり、人間の活動を制約する法的手段または他の手段ではないことを認識するであろう。
【0020】
本発明の一実施形態によれば、ブロックチェーン内で実行されるスマートコントラクトは、支払いを受け取ると、次のアクションで、ユーザからサービスプロバイダに資金を転送する支払いをファイナライズし得る。成功すると、スマートコントラクトは、ランダム支払いIDと、サービスプロバイダのコミットされたアドレスと、集約された承認署名と、承認するステートキーパーの定足数とを、ユーザのファイナライズされたトランザクションのリスト内に記憶し得る。
【0021】
本発明の一実施形態によれば、スマートコントラクトにおけるユーザの最終トランザクションは、ユーザおよびサービスプロバイダのプライベートアカウントにおける暗号化された支払い額を使用して実行されることが規定され得る。
【0022】
本発明の一実施形態によれば、ブロックチェーン内で実行されるスマートコントラクトは、事前定義されたまたは設定可能な時間後にトランザクションがブロックチェーン上に現れない場合、サービスプロバイダによって開始される決済要求を処理するために使用されることが規定され得る。
【0023】
本発明の一実施形態によれば、サービスプロバイダは、ユーザのプライベート担保アカウントまたはそれぞれのステートキーパーのプライベート担保アカウントのいずれかから機密の支払いを通じて払い戻されるようにユーザまたはステートキーパーに決済要求を指示することが規定され得る。
【0024】
本発明の教示を有利な方法において設計し、さらに発展させる方法は、いくつか存在する。この目的のため、一方では従属請求項を参照し、他方では、例として図において示される本発明の好ましい実施形態の以下の説明を参照すべきである。図の助けによる本発明の好ましい実施形態の説明に関連して、一般に好ましい実施形態および本教示のさらなる発展について説明する。
【図面の簡単な説明】
【0025】
【図1】本発明の実施形態によるシステムにおいて使用されるSnappyデータ構造を示す表である。
【図2】本発明の実施形態によるシステムにおいて使用されるZether関数を示す表である。
【図3】本発明の実施形態によるシステムにおいて使用されるトランザクションフォーマットのデータ構造を示す表である。
【図4】本発明の実施形態によるシステムにおいて使用されるスマートコントラクトのデータ構造を示す表である。
【図5】本発明の一実施形態による、ユーザとサービスプロバイダとの間の支払いプロセスを示す概略図である。
【図6】本発明の一実施形態に従って実行される支払い意図の変更を示す図である。
【発明を実施するための形態】
【0026】
【0027】
通常のブロックチェーントランザクションとは別に、スマートコントラクトとしてブロックチェーンの上に位置する無数の他の支払いシステムが存在する。これらのシステムは、主に、通常のブロックチェーントランザクションによって提供されない特定の特性を提供するために、任意の追加機能を導入する。現在の先行技術において、主に小売りまたはオンラインストアなどのシナリオに関連する3つの主要なタイプの支払いシステムに分類することができる。
【0028】
1.標準的なブロックチェーン支払い。例えば、イーサリアムにおいて、そのようなトランザクションは、送信者と、受信者と、支払い額と、送信者のアカウントによって作成されたデジタル署名とを含むだけである。トランザクションがブロックチェーン上でマイニングされ、ファイナライズされると、支払い値は、送信者のアカウントから受信者のアカウントに転送される。
【0029】
その単純さのため、そのような支払いは、手数料が低いが、トランザクションがブロックチェーン上で安全にファイナライズされるまで(通常は数分)待つ必要があるので、遅い。そのため、そのような支払いは、日常の使用での少額で高速な支払いには実用的ではない。しかしながら、例えば、クレジットカードプロバイダに対する主な利点は、これらのブロックチェーン支払いが分散型であり、したがって、トランザクションをブロックする可能性がある特定のエンティティが存在しないことである。
【0030】
2.高速ブロックチェーン支払い。待ち時間の問題に対処するために、支払いの高速な承認を可能にするスマートコントラクトとして実装されたシステムが存在する。主なアイデアは、ユーザがスマートコントラクトに担保を預けることである。この担保は、受信側サービスプロバイダがブロックチェーン上でファイナライズされる前に支払いを受け入れることができるように、受信側サービスプロバイダに保証を提供するために使用される。そのようなメカニズムを使用するいくつかのシステムが存在する。
【0031】
支払いチャネルは、特定のユーザとサービスプロバイダとの間に関係を確立することを可能にする。そのようなチャネルは、すべてのトランザクションをブロックチェーンネットワークに提出することなく、複数のトランザクションを作成することを可能にする。特に、数百または数千のトランザクションを単一のブロックチェーントランザクションに結合することが可能である。しかしながら、ユーザがすべてのサービスプロバイダと個別に支払いチャネルを設定する必要があるので、そのようなチャネルは、小売り支払いには現実的ではない。これは、固定された高い担保を結果として生じ、ユーザにとって拡張性がない。
【0032】
一方、支払いハブは、ユーザがいくつかのサービスプロバイダと通信することを可能にする。この場合、ユーザは、ユーザと複数のサービスプロバイダとを接続する単一のスマートコントラクトにおいて登録する。登録の際、ユーザは、保証として担保を預ける必要もある。そのようなシステムにおける主な欠点は、ハブオペレータが配置する必要がある担保のサイズが、システムにおける登録ユーザの総量に応じて拡大し、したがって、非常に大きくなることである。したがって、そのようなシステムは、より大規模な展開シナリオには拡張できない。
【0033】
サイドチェーンは、トランザクションバリデータのより小さいセットに依存する代替案である。これらのバリデータは、着信トランザクションを集合的に追跡して承認する。しかしながら、そのようなシステムの主な問題は、その信頼仮定である。特に、バリデータの少なくとも2/3が信頼されなければならない。さらに、これらのシステムは、通常、BFT(ビザンチンフォールトトレランス)プロトコルを介して通信し、BFTプロトコルは、高い複雑度を有し、したがって、待ち時間と計算量の点でコストがかかる。
【0034】
本発明の実施形態に対する評価基準を構築する(すでに上述した)Snappy支払いシステムは、少額のユーザ担保による支払いの高速承認を可能にする。これは、各トランザクションがステートキーピングエンティティによって承認されるメカニズムを通じて達成される。ステートキーパーは、Snappyトランザクションを集合的に追跡して承認する信頼できないエンティティとして機能する。(例えば、クレジットカードプロバイダからの価値ベースの手数料とは対照的に)固定された取引手数料をほとんどの加盟店に保証するので、ほとんどの加盟店もステートキーパーとして機能すると仮定することができる。ステートキーパーは、1回限りの登録プロセスに際して、担保を預ける必要もある。
【0035】
Snappyの主な利点は、ユーザ担保が特定のユーザの支出をカバーすることのみを必要とし、すなわち、いかなる他の要因にも依存しないことである。一方、ステートキーパー担保は、システム内の売上総額に応じて拡大する。サービスプロバイダがステートキーパーとして機能する場合、低額の固定された支払い手数料から利益を得るので、これは、許容され得る。これらの手数料は、クレジットカードプロバイダと比較してはるかに低い。
【0036】
3.プライベートブロックチェーン支払い。同様にスマートコントラクトを通じてオンチェーンプライバシーを達成することが可能である。本発明の実施形態は、(すでに上述した)プライベート支払いシステムZetherを評価基準として使用する。ゼロ知識証明システムΣ-Bulletsを使用することによって、暗号化された金額を記憶および転送するカスタムアカウントを管理する。したがって、パーミッションレス型ブロックチェーンの上で、機密の(およびオプションで匿名の)支払いを提供する。そのようなシステムは、標準的なブロックチェーン支払いとは対照的に、強力なセキュリティおよびプライバシーの保証を有する。
【0037】
上述した支払いシステムは、各々興味深い特性を提供する。しかしながら、それらは、注目すべき制限と欠点とを依然として有する。
【0038】
検閲に対する脆弱性。検閲に対する耐性は、支払いにパーミッションレスブロックチェーンを使用する主な動機の1つである。しかしながら、支払いハブ、サイドチェーン、およびSnappyのような高速支払いシステムにおいて、これらの保証は、破られる。これは、ステートキーピングエンティティの大多数の承認が受信された場合にのみ、トランザクションが安全に受け入れられ得るためである。ステートキーピングエンティティは、通常、他の競合サービスプロバイダであることが想起される。ステートキーパーは、支払い意図の詳細を有する承認要求を平文で受け取るので、特定のサービスプロバイダまたはユーザに対して恣意的な検閲を行うことができる。これは、小売りまたはオンラインストアなどの競合環境において現実的な脅威である。そのため、大多数の承認を活用する高速ブロックチェーン支払いシステムによって提供されるセキュリティ特性は、弱く、特に検閲に関して、クレジットカードプロバイダなどの他の既存のシステムを上回る利点を提供しない。
【0039】
機密性および匿名性の欠如。高速支払いシステムの別の特定の制限は、弱いプライバシーである。例えば、Snappyにおいて、ユーザは、自分のメインブロックチェーンアカウントを用いてシステムに登録する。したがって、すべてのトランザクションは、その身元まで追跡可能である。そのようなシステムにおけるすべてのデータは、公的に利用可能であり、したがって、誰もがすべてのユーザのプロファイリングを実行することを可能にする。これは、例えば、マーケティングの目的または政治的な目的に悪用される可能性がある。そのようなプロファイリングは、例えば、クレジットカードによる支払いよりもさらに強いプライバシー上の懸念を引き起こす可能性がある。
【0040】
ユーザプロファイリングとは別に、現在の高速支払いシステムは、サービスプロバイダの重要なビジネス情報も一般に公開する。特に、すべてのトランザクションの詳細は、スマートコントラクトの状態において平文で公的に記憶される。したがって、各サービスプロバイダのトランザクションを追跡し、したがって、その販売に関する情報を取得することが可能である。小売りまたはオンラインビジネスの競合シナリオにおいて、これは、そのようなシステムを使用することの現実的な欠点である。
【0041】
実用性よりも安全性。上記の問題がない支払いシステムが存在する。特に、プライベート支払いシステムは、高速支払いシステムとは対照的に、強力なセキュリティおよびプライバシーの保証を導入する。設計上、それらのシステムは、いかなる検閲にも耐性があり、そのユーザベースのいかなるプロファイリングも可能にしない。しかしながら、そのようなシステムは、小売りおよびオンライン支払いなどの現実世界のシナリオでは実用的ではない。特に、そのようなシステムは、承認待ち時間を短縮するいかなるメカニズムも提供せず、したがって、通常のブロックチェーン支払いと同じ待ち時間の問題に悩まされる。
【0042】
上記を考慮して、本発明の実施形態に従って提案されるシステムおよび方法は、高速支払いとプライベート支払いの両方を提供するハイブリッド手法を採用する。実施形態によれば、提案する支払い方法/システムは、設計上、柔軟であるというさらなる特性を有し、公的支払い、機密支払い、または匿名支払いのいずれが望まれるかに応じて、異なるシナリオにおいて展開することが可能である。特に、公的、機密、または匿名のいずれの展開シナリオが選択されても、いかなる検閲にも耐えるように設計される。
【0043】
本発明の一実施形態によれば、支払い方法/システムは、Snappyと同様に高速で支払いを受け付ける。すなわち、この支払い方法/システムは、支払いプロトコルと決済プロトコルの両方を提供し、これらのプロトコルは、Snappyと比較して、特に強力なセキュリティおよびプライバシーの保証を中心に設計される。さらに、プロセスは、支払い用および担保用の改善されたZetherスタイルのプライベートアカウントと互換性がある。
【0044】
Snappyとは対照的に、本発明の実施形態による支払い方法/システムは、それ自体の(プライベート)アカウントを提供および管理する。これは、プライベート支払いとプライベート決済の両方のより容易な統合を可能にする。管理は、専用のスマートコントラクトによって実行され得る。Zetherスタイルのアカウントに加えて、本発明の実施形態による支払い方法/システムは、新しいタイプのプライベート担保アカウントも導入する。決済請求が機密に転送されることを可能にするために、これらの担保アカウントは、一般的なZetherスタイルのアカウントと比較して完全に異なって管理される。
【0045】
本発明の実施形態による支払いプロセスにおける個々のステップの正確な詳細は、Zetherに対して完全に変更される。特に、サービスプロバイダおよびユーザは、すべての詳細を隠し、ステートキーパーからの任意の検閲への耐性を保証する新しいタイプの支払い意図を作成する。それに加えて、すべてのアカウントは、暗号化された残高を含むので、サービスプロバイダは、プライベート担保残高が保留中の支払いをカバーするのに十分であることを保証するために、ユーザによって作成されたゼロ知識証明を検証する。最後に、支払いシステムのスマートコントラクトにおけるファイナライズされたトランザクションは、プライベートアカウントにおける暗号化された支払い額を使用して実行される。これらのメカニズムのすべては、安全(検閲耐性)かつプライベート(機密および匿名)な高速支払いを提供する。
【0046】
本発明の実施形態によれば、決算プロセスは、Snappyとは対照的に、異なるエンティティに請求するための2つの別個の機能に分割され得る。特に、ユーザに請求するためのプロセス、およびステートキーパーに請求するためのプロセスが提供され得る。両方の場合において、プロセスは、サービスプロバイダが、新たに導入されたプライベート担保アカウントからの機密支払いを通じて払い戻されることを可能にするように完全に再設計される。
【0047】
前述のメカニズムのすべては、いかなる従来のシステムにおいても達成されなかった特性を有する新しい独自の支払いシステムに寄与する。結論として、本発明の実施形態による解決策は、高速で、検閲に強く、機密性で、匿名性であり、少額のユーザ担保を有し、いかなる追加の信頼仮定も必要としないシステムをもたらす。
【0048】
そのような新しいシステムを構築するために解決される必要がある主な技術的課題は、以下の通りである。
【0049】
検閲:
サービスプロバイダは、各支払いについて大多数の承認を必要とする。特に、ステートキーパーは、特定のユーザについて競合するトランザクションに署名していないことを確認する必要がある。したがって、サービスプロバイダは、ユーザの身元に関するなんらかの概念を必要とする。高速支払いシステム(Snappy)の以前の設計において、ステートキーパーは、ユーザの身元と、サービスプロバイダの身元と、支払い値とをすべて平文において含む支払い意図を承認する。ステートキーパーは、特定のユーザまたはサービスプロバイダを意図的に検閲することができるので、これは、失敗のリンクを自動的に導入する。サービスプロバイダがステートキーパーの大多数からの署名を受信しない場合、支払いを安全に受け入れることができないことが想起される。これは、サービスプロバイダがステートキーパーの役割を担う典型的な小売り支払いシナリオにおいて現実的な脅威であると考えられる。共謀するサービスプロバイダ(ステートキーパー)のセットは、別の競合する被害者サービスプロバイダのいかなる支払いも処理しないことを決定する可能性がある。Snappyのような分散型支払いシステムにおける検閲を防止するために、本発明の実施形態による支払い方法/システムは、以下の3つの高レベルの目標(a.～c.)を満たすように設計される。
サービスプロバイダは、各支払いについて大多数の承認を必要とする。特に、ステートキーパーは、特定のユーザについて競合するトランザクションに署名していないことを確認する必要がある。したがって、サービスプロバイダは、ユーザの身元に関するなんらかの概念を必要とする。高速支払いシステム(Snappy)の以前の設計において、ステートキーパーは、ユーザの身元と、サービスプロバイダの身元と、支払い値とをすべて平文において含む支払い意図を承認する。ステートキーパーは、特定のユーザまたはサービスプロバイダを意図的に検閲することができるので、これは、失敗のリンクを自動的に導入する。サービスプロバイダがステートキーパーの大多数からの署名を受信しない場合、支払いを安全に受け入れることができないことが想起される。これは、サービスプロバイダがステートキーパーの役割を担う典型的な小売り支払いシナリオにおいて現実的な脅威であると考えられる。共謀するサービスプロバイダ(ステートキーパー)のセットは、別の競合する被害者サービスプロバイダのいかなる支払いも処理しないことを決定する可能性がある。Snappyのような分散型支払いシステムにおける検閲を防止するために、本発明の実施形態による支払い方法/システムは、以下の3つの高レベルの目標(a.～c.)を満たすように設計される。
【0050】
a.支払い値ベースの検閲。検閲耐性に向かう第1の目標は、支払い価格を隠すことである。主な問題は、悪意のあるステートキーパーが支払い価格に基づいて受取人の身元を推測することが可能である場合があることである。特定の商品は、その価格に従ってほぼ一意に識別可能である。したがって、悪意のあるステートキーパーは、特定の場合において特定のサービスプロバイダを依然として差別する可能性がある。同様に、特定のシナリオにおいて、悪意のあるステートキーパーは、特定のユーザを差別する可能性がある。悪意のあるステートキーパーは、何が購入されたかをどうにかして推測することができる場合、ターゲットのユーザがなんらかの商品を買うのを防止する可能性がある。この軽減の目標は、ステートキーパーが取引額に基づいてサービスプロバイダ(またはユーザ)を差別することができないことである。
【0051】
b.サービスプロバイダの身元ベースの検閲。Snappyにおけるような単純な設計において、ステートキーパーは、サービスプロバイダの身元を平文において受信する。これは、承認されたトランザクションと競合する異なるトランザクションに対する第2のトランザクションを誰も作成することができないことを保証するためである。したがって、そのような設計において、ステートキーパーは、支払いの受取人が誰であるかを平文において依然として見ることができる。したがって、ステートキーパーは、サービスプロバイダの身元に基づいて検閲を実行する可能性がある(ステートキーパーは、通常、他の競合するサービスプロバイダであることを想起されたい)。したがって、すべてのサービスプロバイダが平等に扱われることが望まれる。より正確には、目標は、支払い承認プロセスに際して、サービスプロバイダの身元をステートキーパーから隠すことである。その理論的根拠は、ステートキーパーが支払い受取人(サービスプロバイダ)が誰であるかを知らない場合、その支払いを選択的に阻止することによって特定のサービスプロバイダを差別することはできないことである。ステートキーパーがいかなる支払いも承認しない全面的なDoS攻撃ももちろん可能であることが留意される。
【0052】
c.ユーザの身元ベースの検閲。ステートキーパーは、特定のユーザおよび支払いインデックスに関するトランザクションにすでに署名しているかどうかを確認する必要がある。従来のシステムにおけるように単純な設計では、支払い意図は、ユーザの身元を単に含むことになる。したがって、ユーザのアドレスが支払い意図において平文で利用可能であるので、ステートキーパーは、特定のユーザを差別することができる。ステートキーパーは、ユーザの身元とのなんらかの関連を知る必要があるので、これは、おそらく、解決するのが最も困難な問題である。
【0053】
プライバシー:
本発明の実施形態は、プライベート支払いシステムにおいて導入された技法を活用し、それを高速支払いをサポートするSnappyのようなシステムの設計と組み合わせる。この点について、問題の1つは、高速支払いシステムと同じセキュリティ保証を提供するが、プライベート支払いシステムによって提供されるいかなるプライバシー保証も損なわないシステムを考案することである。プライベート支払いおよびプライベート決済プロセス全体にわたる主な課題は、以下の通りである。
本発明の実施形態は、プライベート支払いシステムにおいて導入された技法を活用し、それを高速支払いをサポートするSnappyのようなシステムの設計と組み合わせる。この点について、問題の1つは、高速支払いシステムと同じセキュリティ保証を提供するが、プライベート支払いシステムによって提供されるいかなるプライバシー保証も損なわないシステムを考案することである。プライベート支払いおよびプライベート決済プロセス全体にわたる主な課題は、以下の通りである。
【0054】
プライベート支払いプロセス。単純な設計において、スマートコントラクトにおける最終ステップがZetherのような既存のプライベート支払いシステムにおける支払いを単にトリガするという違いだけで、例えば、Snappy支払いシステムと同じような支払いプロセスを考案することができる。そのような設計は、いくつかの欠点を有する。まず第1に、Snappyは、ユーザの詳細を開示するので、プライベート支払いシステムのプライバシー保証に違反することになる。さらに、Snappyのセキュリティ保証にも違反することになる。特に、サービスプロバイダは、ユーザまたはステートキーパーの担保が現在のおよびすべての保留中のトランザクションをカバーするのに十分であるかどうかをチェックする必要がある。すべての支払いは、暗号化された金額を含むので、支払いプロセスは、そのようなチェックを可能にする追加のメカニズムを提供する必要がある。
【0055】
プライベート決算プロセス。ほとんどの問題は、決算請求の正しい処理に関して発生する。特に、ステートキーパーは、システム内に競合するトランザクションが存在するかどうか、すなわち、特定のユーザが同じ支払いインデックスに関する2つの異なるトランザクションを作成したかどうかを検証する必要がある。
【0056】
実施形態によれば、本発明は、高速で、機密で、匿名の支払い、ならびに機密の決済をサポートする支払い方法/システムを提供する。
【0057】
検閲耐性を考慮するために、本発明の実施形態は、支払い値の難読化、サービスプロバイダの身元の難読化、およびユーザの身元の難読化のうちの少なくとも1つを実装する。
【0058】
支払い値の難読化。本発明者らの主な観察の1つは、ステートキーパーが各々の承認された支払いの額を知る必要がないことである。以前は、Snappyトランザクションは、4つの値すべて、すなわち、Snappyインデックス、ユーザのアドレス、サービスプロバイダのアドレス、および支払い値が与えられると、一意に識別されていた。しかしながら、支払いインデックスと、ユーザのアドレスと、サービスプロバイダのアドレスとのみを含むトリプレットが一意である場合、トランザクションを一意とみなすのに十分である。
【0059】
サービスプロバイダの身元の難読化。さらに、Snappyプロトコルは、支払い承認の際、サービスプロバイダのアドレスがステートキーパーから隠されたままであるように変更され得、サービスプロバイダに対する検閲を防止することが認識されている。主な技術的課題は、アドレスが支払い承認に依然として安全に結び付けられ、必要であれば後に決済のために明らかにされ得るように、アドレスを隠すことである。この状況において、本発明の実施形態は、サービスプロバイダが支払い承認の期間中にアドレスをブラインド化し、追加のコストを評価することができるPedersenコミットメントを活用する。
【0060】
このアイデアは、サービスプロバイダがユーザから最初の支払い意図INTcを受信すると、サービスプロバイダは、支払い意図内のアドレスを、rがランダムブラインド化値である、Pedersenコミットメントc=C(τm,r)によって置き換えるというものである。ステートキーパーは、ブラインド化されたサービスプロバイダの身元を含む支払い意図に署名する。コミットメントは、サービスプロバイダが決済を要求する必要がある場合にのみ開かれ、この場合、仲裁者として機能するエンティティがそれを検証する。
【0061】
ユーザの身元の難読化。本発明の実施形態によれば、検閲は、ユーザ支払い意図のアドレスを、各支払いについて別々に検証可能なランダム関数(VRF)を使用して生成されるランダム化支払いID(RPID)に置き換えることによって防止される。
【0062】
より正確には、登録時に、ユーザは、VRF鍵ペアを生成し得る。VRF公開鍵は、ユーザの預入と一緒に支払いシステムのスマートコントラクトに登録され、ユーザは、秘密鍵を自分自身で保持する。新しい支払いごとに、ユーザは、現在の(単調増加する)支払いインデックスをVRF入力として使用してVRF出力として新しいRPIDを生成するために、秘密鍵を使用する。ユーザは、サービスプロバイダが、現在の支払いインデックスに対してRPIDが正しく作成されたことを検証することを可能にするVRF証明も作成する。ステートキーパーは、RPIDごとに1つの支払いのみを承認する。
【0063】
そのような軽減のセキュリティおよびプライバシーの保証は、VRFの2つの特性に依存する。第1の特性は、一意性であり、これは、同じVRF入力(この場合、支払いインデックス)に対して1つの正しいVRF出力(この場合、RPID)のみが生成され得ることを保証する。悪意のあるユーザは、同じインデックスに対して複数のRPIDを作成することができず、ステートキーパーは、支払いインデックスごとに二重消費を追跡するので、悪意のあるユーザは、二重消費をすることができない。第2の特性は、疑似ランダム性であり、これは、すべてのRPIDがユーザのアドレス、または同じユーザによって使用された任意の以前のRPIDにリンクできないことを保証する。これは、ステートキーパーがユーザの身元に基づいて支払いを検閲するのを防止する。
【0064】
支払いのプライバシーを考慮するために、すなわち、支払い中の強力なプライバシー保証を提供するために、本発明の実施形態は、資金をユーザからサービスプロバイダに機密に(または場合によっては匿名で)転送するZetherスタイルのトランザクションを活用する。これらの支払いは、Zetherと同じ方法において処理され得る(すなわち、暗号化された支払い値が、ゼロ知識証明を使用して転送される)。しかしながら、実施形態によれば、サービスプロバイダに保証を提供するように、支払いプロセスにさらなる改善が導入され得る。これは、ユーザの追加のゼロ知識証明と、担保が支払い値をカバーするのに十分であることを示すために後に決済中に使用され得る決済要求に署名する署名とから構成される。
【0065】
このように、本発明の実施形態は、以下の態様を実現する支払い方法/システムを提供する。
1.コミットメント方式を使用して支払い値を隠し、ユーザの身元を隠すためにVRFを使用する。
2.支払い時に残高を証明するために範囲証明を使用する。
3.ブロックチェーンにおけるプライバシー保護および検閲耐性のある高速支払いを達成するために、上記と支払い担保システムとを組み合わせる。
1.コミットメント方式を使用して支払い値を隠し、ユーザの身元を隠すためにVRFを使用する。
2.支払い時に残高を証明するために範囲証明を使用する。
3.ブロックチェーンにおけるプライバシー保護および検閲耐性のある高速支払いを達成するために、上記と支払い担保システムとを組み合わせる。
【0066】
本発明の実施形態は、2つのタイプのアカウント、ユーザアカウントと担保アカウントとを用いる。ユーザアカウントは、他のユーザアカウントに資金を自由に転送するために使用され得る。一方、担保アカウントは、スマートコントラクトによってのみ管理され、決済請求の際に使用される。主なアイデアは、ユーザがスマートコントラクトに担保を預けることである。この担保は、受信側サービスプロバイダが支払いがブロックチェーン上でファイナライズされる前に支払いを受け入れることができるように、受信側サービスプロバイダに保証を提供するために使用される。
【0067】
両方のタイプのアカウントについて、残高は、暗号文として記憶される。この点について、スマートコントラクトは、アカウントアドレス(すなわち、ElGamal公開鍵)をElGamal準同型暗号化値にマッピングする辞書を記憶することが規定され得る。
【0068】
ユーザアカウントについて、本発明の実施形態は、Zether(参照により本明細書に組み込まれる、B. Bunz、S. Agrawal、M. Zamani、およびD. Boneh:「Zether: Towards Privacy in a Smart Contract World」、2020年7月、423～443頁、https://crypto.stanford.edu/~buenz/papers/zether.pdfにおいて開示されている)などの既存のプライベート支払いシステムと同じモデルを仮定する。特に、アカウントは、エポックにおいて管理される。受信側アカウントは、着信トランザクションを保留リスト内に記憶し、各エポックの終了時にのみアカウント残高にロールオーバーする。これは、トランザクションのフロントランニングを防止する。さらに、本発明の実施形態は、上記のZether参考文献に記載されているのと同じタイプのユーザアカウントのためのゼロ知識証明を活用し得る。
【0069】
担保アカウントは、ユーザアカウントに類似しているが、異なって管理される。特に、登録と登録解除とを除く転送は、決済中にスマートコントラクトによって内部的にのみトリガされ得る。さらに、ゼロ知識証明のステートメントは、ユーザアカウントに必要なステートメントとはわずかに異なる。具体的な詳細について、以下でさらに深く説明する。
【0070】
実施形態によれば、本発明によるシステムを使用するために、ユーザは、以下の条件を満たすことを確実とすべきである。
・ランダム支払いID(RPID)を作成するために使用されるVRF(検証可能なランダム関数)鍵ペアを所有する。
・ユーザの支払いのための主要な資金を保持するシステムユーザアカウントのためのElGamal鍵ペアを所有する。
・決済中に使用されるシステム担保アカウントのためのElGamal鍵ペアを所有する。
・ランダム支払いID(RPID)を作成するために使用されるVRF(検証可能なランダム関数)鍵ペアを所有する。
・ユーザの支払いのための主要な資金を保持するシステムユーザアカウントのためのElGamal鍵ペアを所有する。
・決済中に使用されるシステム担保アカウントのためのElGamal鍵ペアを所有する。
【0071】
システムにおいて詳細を登録するために、ユーザが以下の詳細を含むブロックチェーントランザクションを開始することによって登録プロセスをトリガすることが規定され得る。
・対応するVRF公開鍵をシステムに登録する。
・VRFに公開鍵にリンクされる担保アカウントアドレスを登録する。
・対応するVRF公開鍵をシステムに登録する。
・VRFに公開鍵にリンクされる担保アカウントアドレスを登録する。
【0072】
最後に、登録時に、システムのスマートコントラクトは、(図4に示す表におけるような)以下の詳細を含み得る、その状態における新しいユーザエントリC[c]を作成し得る。
・ユーザの担保アカウントに対応するアドレス。
・ファイナライズされたトランザクションの新しい辞書D。
・観察されたトランザクションハッシュの新しい辞書O。
・過去の決算請求の新しい辞書T(トレース)。その第1のエントリは、
C[c].T[0].idx←⊥
および
C[c].T[0].poolc←cb
のように初期化され、ここで、cbは、ユーザの担保アカウントの初期残高に対応する暗号文である。
・ユーザの担保アカウントに対応するアドレス。
・ファイナライズされたトランザクションの新しい辞書D。
・観察されたトランザクションハッシュの新しい辞書O。
・過去の決算請求の新しい辞書T(トレース)。その第1のエントリは、
C[c].T[0].idx←⊥
および
C[c].T[0].poolc←cb
のように初期化され、ここで、cbは、ユーザの担保アカウントの初期残高に対応する暗号文である。
【0073】
サービスプロバイダの登録に関して、システムを使用する前に、サービスプロバイダは、以下の条件を満たすことを保証する必要がある。
・支払いが転送される1つのメインユーザアカウントのための有効な鍵ペアを所有する。
・決算が転送される1つのセカンダリユーザアカウントのための有効な鍵ペアを所有する。
・サービスプロバイダは、各ステートキーパーから値viを受信した。この値は、ステートキーパーがサービスプロバイダに割り当てた各ステートキーパーの担保の一部である。
・支払いが転送される1つのメインユーザアカウントのための有効な鍵ペアを所有する。
・決算が転送される1つのセカンダリユーザアカウントのための有効な鍵ペアを所有する。
・サービスプロバイダは、各ステートキーパーから値viを受信した。この値は、ステートキーパーがサービスプロバイダに割り当てた各ステートキーパーの担保の一部である。
【0074】
当業者によって理解されるように、機密の支払いのみが要求および使用される場合、メインユーザアカウントおよびセカンダリユーザアカウントは、同じであり得る。
【0075】
システムにおいて詳細を登録するために、サービスプロバイダは、以下の詳細を含むブロックチェーントランザクションを開始することによってサービスプロバイダ登録プロセスをトリガし得る。
・セカンダリユーザアカウントのアドレスを登録する。
・セカンダリユーザアカウントのアドレスを登録する。
【0076】
最後に、登録時に、システムのスマートコントラクトは、(図4に示す表におけるように)以下を含むその状態において新しいユーザエントリM[m]を作成する。
・サービスプロバイダが提出したセカンダリユーザアカウントのアドレス。
・サービスプロバイダが提出したセカンダリユーザアカウントのアドレス。
【0077】
ステートキーパー登録に関して、システムを使用する前に、ステートキーパーは、以下の条件を満たすことを保証する必要がある。
・有効なBLS(Boneh-Lynn-Shacham)鍵ペアを所有する。
・決済中に使用される担保アカウントのためのElGamal鍵ペアを所有する。
・担保総額の一部を各サービスプロバイダに割り当て、すなわち、各サービスプロバイダに関するk値を作成し、すべての値は、合計して担保総額になるべきである。
・担保アカウントのElGamal公開鍵を用いて各値viを暗号文ciに暗号化する。
・各々の割り当てられた値viを対応するサービスプロバイダに送信する。
・すべての暗号文の合計
・有効なBLS(Boneh-Lynn-Shacham)鍵ペアを所有する。
・決済中に使用される担保アカウントのためのElGamal鍵ペアを所有する。
・担保総額の一部を各サービスプロバイダに割り当て、すなわち、各サービスプロバイダに関するk値を作成し、すべての値は、合計して担保総額になるべきである。
・担保アカウントのElGamal公開鍵を用いて各値viを暗号文ciに暗号化する。
・各々の割り当てられた値viを対応するサービスプロバイダに送信する。
・すべての暗号文の合計
【0078】
【数1】
【0079】
が担保総額に等しいことを示すゼロ知識証明πregを作成する。
【0080】
システムにおいて詳細を登録するために、ステートキーパーは、以下の詳細を含むブロックチェーントランザクションを開始することによってステートキーパー登録プロセスをトリガし得る。
・BLS公開鍵。
・(T. RistenpartおよびS. Yilek、「The power of proofs-of-possession: Securing multiparty signatures against rogue-key attacks」、in Advances in Cryptology - EUROCRYPT 2007、M. Naor、Ed. Berlin、Heidelberg: Springer Berlin Heidelberg、2007年、228～245頁に記載されているように)不正鍵攻撃を防ぐためのBLS秘密鍵の知識の証明。
・すべての暗号文ci、...、ck
・ゼロ知識証明πreg
・BLS公開鍵。
・(T. RistenpartおよびS. Yilek、「The power of proofs-of-possession: Securing multiparty signatures against rogue-key attacks」、in Advances in Cryptology - EUROCRYPT 2007、M. Naor、Ed. Berlin、Heidelberg: Springer Berlin Heidelberg、2007年、228～245頁に記載されているように)不正鍵攻撃を防ぐためのBLS秘密鍵の知識の証明。
・すべての暗号文ci、...、ck
・ゼロ知識証明πreg
【0081】
最後に、登録時に、システムのスマートコントラクトは、(図4に示す表におけるように)以下のアクションを実行し得る。
・BLS秘密鍵の知識の証明を検証する。
・ゼロ知識証明πregを検証する。
・(図4に示す表に従って)以下を含むその状態における新しいエントリS[s]を作成する。
- BLS公開鍵。
- ステートキーパーの担保アカウントアドレス
- 各サービスプロバイダへの割り当て部分に対応するk個の暗号文のリスト。
・BLS秘密鍵の知識の証明を検証する。
・ゼロ知識証明πregを検証する。
・(図4に示す表に従って)以下を含むその状態における新しいエントリS[s]を作成する。
- BLS公開鍵。
- ステートキーパーの担保アカウントアドレス
- 各サービスプロバイダへの割り当て部分に対応するk個の暗号文のリスト。
【0082】
システムにおける最も重要な機能は、支払いプロセスである。ユーザによって署名されたトランザクションによってトリガされ得るこのプロセスは、資金を特定のサービスプロバイダに機密に(または匿名で)転送する。これは、本発明の実施形態による意図されたユースケースであり、一般的に、この支払いプロセスは、ユーザまたはステートキーパーのいずれかが悪意を持って行動しない限り、成功するはずである。
【0083】
次に、本発明の実施形態による高速トランザクションの作成および処理に含まれる正確なプロセスおよびステップについて、方法ステップ1～8が示されている図5を参照して説明する。表記は、図1～図4、特に図4に示す、トランザクションの詳細の一覧を提供する表に従う。
【0084】
1 支払いの初期化
図5におけるステップ1に示すように、ユーザ110は、以下の、
・支払いインデックスi、
・ランダム支払いID RPID=VRFhash(skvrf,i)、
・サービスプロバイダのプライベート担保アカウントmのアドレス
含むプライベート支払い意図PINTcを作成する。
図5におけるステップ1に示すように、ユーザ110は、以下の、
・支払いインデックスi、
・ランダム支払いID RPID=VRFhash(skvrf,i)、
・サービスプロバイダのプライベート担保アカウントmのアドレス
含むプライベート支払い意図PINTcを作成する。
【0085】
次に、ユーザ110は、機密の(またはオプションで匿名の)トランザクションの詳細を作成し得る。
【0086】
機密の支払い。この場合、ユーザ110は、ユーザ110のElGamal公開鍵y、サービスプロバイダ120のElGamal公開鍵
【0087】
【数2】
【0088】
、ユーザ110のElGamal秘密鍵x、ユーザ110のユーザアカウント残高bf、および支払い額vを入力として、Zether関数、すなわち、CreateTransferTxを実行し得る。この方法は、暗号文
【0089】
【数3】
【0090】
と、ゼロ知識証明πtans(ユーザ110の残高が十分であり、
【0091】
【数4】
【0092】
であることを示す)と、署名σtransとを返す。
【0093】
匿名の支払い。匿名の支払いの場合、ユーザ110は、ユーザ110のアカウントとサービスプロバイダ120のアカウントの両方を含む匿名セット
【0094】
【数5】
【0095】
と、ユーザ110のユーザアカウントのインデックスifと、サービスプロバイダのユーザアカウントのインデックスitoと、ユーザ110のElGamal秘密鍵xと、ユーザ110のユーザアカウントの残高bfと、支払い額vと、システムのスマートコントラクト150の現在の状態とを入力として、別のZether関数、すなわち、CreateAnonTransferTxを実行し得る。この方法は、暗号文のセット
【0096】
【数6】
【0097】
と、ノンスuと、ゼロ知識証明πtransとを返す。
【0098】
それに加えて、ユーザ110は、第2のゼロ知識証明πcolを作成し得る。この証明は、ユーザのプライベート担保の残高に対する。特に、現在の支払いを含むすべての保留中の支払いの合計が、ユーザ110の現在のプライベート担保残高未満であることを示さなければならない。現在の担保残高は、トレースC[c]において確認され得る。より正式には、
【0099】
【数7】
【0100】
を保持しなければならず、ここで、nは、リストC[c].Tの最終インデックスを示す。そのような証明は、Bulletproofsと組み合わせたΣ-Protocolsに基づくハイブリッドシステムであることを示すΣ-Bulletsを使用して効率的に作成または検証され得る(参考のため、参照により本明細書に組み込まれる、B. Bunz、J. Bootle、D. Boneh、A. Poelstra、P. Wuille、およびG. Maxwell、「Bulletproofs: Short proofs for confidential transactions and more」、Cryptology ePrint Archive、Report 2017/1066、2017年、https://eprint.iacr.org/2017/1066を参照)。
【0101】
本発明の実施形態によれば、ユーザ110は、以下の詳細、
・支払い意図PINTc、
・VRF公開鍵pkvrf、
・VRF証明πvrf=VRFprove(skvrf,i)、
・暗号化された支払い額、
・ゼロ知識証明πcol、
・保留中のトランザクションのリストSc
をサービスプロバイダ120に送信し得る。
・支払い意図PINTc、
・VRF公開鍵pkvrf、
・VRF証明πvrf=VRFprove(skvrf,i)、
・暗号化された支払い額、
・ゼロ知識証明πcol、
・保留中のトランザクションのリストSc
をサービスプロバイダ120に送信し得る。
【0102】
2 ユーザ評価
図5に示すように、支払い初期化の後、ステップ2において、サービスプロバイダ120は、以下のチェック
・各インデックスj∈{1,...,PINTc[i]}について、τ∈BC[c]またはτ∈S[c]のいずれかになるように、インデックスjを有する承認されたトランザクションτ'が存在する、
・受信したpkvrfがシステムのスマートコントラクト150上に登録される、
・VRFverify (pkvrf,i,πvrf)=T、
・VRFproof2hash(πvrf)=RPID、
・機密/匿名支払いの詳細、特に、ゼロ知識証明πtransおよび署名σtransの正しさを検証する、
・ユーザ110のプライベート担保がすべての保留中トランザクションと現在のトランザクションとをカバーするのに十分であることを保証するために、追加のゼロ知識証明πcolを検証する
を実行し得る。
図5に示すように、支払い初期化の後、ステップ2において、サービスプロバイダ120は、以下のチェック
・各インデックスj∈{1,...,PINTc[i]}について、τ∈BC[c]またはτ∈S[c]のいずれかになるように、インデックスjを有する承認されたトランザクションτ'が存在する、
・受信したpkvrfがシステムのスマートコントラクト150上に登録される、
・VRFverify (pkvrf,i,πvrf)=T、
・VRFproof2hash(πvrf)=RPID、
・機密/匿名支払いの詳細、特に、ゼロ知識証明πtransおよび署名σtransの正しさを検証する、
・ユーザ110のプライベート担保がすべての保留中トランザクションと現在のトランザクションとをカバーするのに十分であることを保証するために、追加のゼロ知識証明πcolを検証する
を実行し得る。
【0103】
3 サービスプロバイダのアドレスの難読化
本発明の実施形態によれば、サービスプロバイダ120が、その担保アドレスを隠すために、支払い意図PINTcを変更することが規定され得る。すなわち、サービスプロバイダ120は、その担保アドレスをコミットメントcm=C(m,rm)によって置き換え、ここで、rmは、ランダムなブラインド化係数である。
本発明の実施形態によれば、サービスプロバイダ120が、その担保アドレスを隠すために、支払い意図PINTcを変更することが規定され得る。すなわち、サービスプロバイダ120は、その担保アドレスをコミットメントcm=C(m,rm)によって置き換え、ここで、rmは、ランダムなブラインド化係数である。
【0104】
次いで、サービスプロバイダ120は、変更された支払い意図PINTcを(例えば、ブロードキャスティングを介して)ステートキーパー130の大多数に送信し得る。
【0105】
【0106】
4 支払い承認
本発明の実施形態によれば、各ステートキーパー130は、サービスプロバイダ120から受信した支払い意図を以下のように評価し得る。
本発明の実施形態によれば、各ステートキーパー130は、サービスプロバイダ120から受信した支払い意図を以下のように評価し得る。
【0107】
ステートキーパー130は、ステートキーパー130のローカルリストから、ステートキーパー130が同じRPIDを有する支払いをまだ承認していないことをチェックする。一致するRPIDが見つかった場合、ステートキーパー130は、中止し、それに応じてサービスプロバイダ120に通知する。
【0108】
一方、ステートキーパー130が以前同じインデックスについてそれぞれのRPID値を見ていない場合、ステートキーパー130は支払いを承認し、サービスプロバイダ120に送り返す。本発明の実施形態によれば、支払いの承認は、BLS署名
σi=Sign(PINTc,sksk)
を計算することによって実行され得る。ステートキーパー130は、承認されたRPID値をそのローカルリストに追加し得る。
σi=Sign(PINTc,sksk)
を計算することによって実行され得る。ステートキーパー130は、承認されたRPID値をそのローカルリストに追加し得る。
【0109】
5 ステートキーパーの評価
ステートキーパー130の大多数が支払い意図を拒否した場合、サービスプロバイダ120は、ユーザ110に通知し、支払いプロセスを中止する。
ステートキーパー130の大多数が支払い意図を拒否した場合、サービスプロバイダ120は、ユーザ110に通知し、支払いプロセスを中止する。
【0110】
成功すると、すなわち、ステートキーパー130の少なくとも半数が支払い意図を承認すると、サービスプロバイダ120は、すべての署名について
Vf(PINTc,σi,pksk)
の成功をチェックし、成功すると、それらを
A=AggrSig({σi,...,σn})
に集約する。
Vf(PINTc,σi,pksk)
の成功をチェックし、成功すると、それらを
A=AggrSig({σi,...,σn})
に集約する。
【0111】
署名の検証およびその集約に加えて、サービスプロバイダ120は、意図を承認した各ステートキーパー130がサービスプロバイダ120に十分な担保を割り当てたことをチェックし得る。これは、サービスプロバイダ120が各ステートキーパー130の担保の対応する部分を平文で知っているので、容易に行われ得る。
【0112】
本発明の一実施形態によれば、サービスプロバイダ120は、支払い意図PINTcを、ブラインド化係数rm、VRF証明πvrf、およびゼロ知識証明πcolとともにそれらの長期状態において記憶する。これは、後に決済を請求することを可能にするためである。
【0113】
さらに、サービスプロバイダ120は、集約されたBLS署名Aと、ブラインド化係数rmとをユーザ110に送信し得る。
【0114】
6 コミットメントをチェックする
本発明の一実施形態によれば、図5におけるステップ6に示すように、ユーザ110は、集約されたBLS署名Aを検証する。
本発明の一実施形態によれば、図5におけるステップ6に示すように、ユーザ110は、集約されたBLS署名Aを検証する。
【0115】
さらに、ユーザ110は、支払い意図内に含まれるサービスプロバイダ120のコミットメントがC(m,rm)に等しいことをチェックし得る。
【0116】
7 トランザクションのファイナライゼーション
本発明の一実施形態によれば、図5におけるステップ7に示すように、ユーザ110は、以下の詳細、
・送信先:システムのスマートコントラクトアドレス、
・送信元:任意のブロックチェーンアドレス、
・支払いインデックス、
・RPID:RPID、
・コミットされたアドレスcm、
・機密支払い:支払いデータ
本発明の一実施形態によれば、図5におけるステップ7に示すように、ユーザ110は、以下の詳細、
・送信先:システムのスマートコントラクトアドレス、
・送信元:任意のブロックチェーンアドレス、
・支払いインデックス、
・RPID:RPID、
・コミットされたアドレスcm、
・機密支払い:支払いデータ
【0117】
【数8】
【0118】
、または匿名支払い:支払いデータ
【0119】
【数9】
【0120】
、
【0121】
【数10】
【0122】
、πtrans、σtrans、
・集約されたBLS署名A、
・承認定足数q、
・動作、
・ゼロ知識証明πtrans、
・ユーザのシステム署名σtrans、
・スキップされたインデックス
のうちの1つまたは複数を含む最終トランザクションを作成する。
・集約されたBLS署名A、
・承認定足数q、
・動作、
・ゼロ知識証明πtrans、
・ユーザのシステム署名σtrans、
・スキップされたインデックス
のうちの1つまたは複数を含む最終トランザクションを作成する。
【0123】
ユーザ110は、(σtransを通じて署名された)作成されたトランザクションをサービスプロバイダ120に送信する。一実施形態によれば、ユーザ110は、以下でより詳細に説明するように、(潜在的な)決済要求の詳細に署名する署名σclaimを追加で送信し得る。
【0124】
8 支払いの受け入れ
図5におけるステップ8bに示すように、ユーザ110から最終トランザクションを受け取ると、サービスプロバイダ120は、ユーザ110がトランザクションを正しく構築し、すべての詳細に正しく署名したこと、すなわち、事前定義された支払いプロトコルに従っていることを検証する。それらは、ユーザが値のいずれかを置換、省略、または変更していないことをチェックする。
図5におけるステップ8bに示すように、ユーザ110から最終トランザクションを受け取ると、サービスプロバイダ120は、ユーザ110がトランザクションを正しく構築し、すべての詳細に正しく署名したこと、すなわち、事前定義された支払いプロトコルに従っていることを検証する。それらは、ユーザが値のいずれかを置換、省略、または変更していないことをチェックする。
【0125】
ユーザ110のトランザクションが検証されると、サービスプロバイダ120は、(資金が意図された)商品をユーザ110に安全に引き渡すことができる。
【0126】
最後に、サービスプロバイダ120は、トランザクションをブロックチェーン140にブロードキャストする。
【0127】
9 支払いのロギング
本発明の一実施形態によれば、支払いを受け取ると、システムのスマートコントラクト150は、ユーザ110からサービスプロバイダ120に資金を転送する機密(または匿名)支払いをファイナライズする。
本発明の一実施形態によれば、支払いを受け取ると、システムのスマートコントラクト150は、ユーザ110からサービスプロバイダ120に資金を転送する機密(または匿名)支払いをファイナライズする。
【0128】
さらに、成功すると、スマートコントラクト150は、以下の詳細、
・RPID、
・サービスプロバイダのコミットされたアドレスcm、
・収集された承認署名A、
・承認ステートキーパーの定足数q
を、ユーザ110のファイナライズされたトランザクションのリストC[c].D[i]内に記憶し得、ここで、iは、現在のトランザクションのインデックスである。
・RPID、
・サービスプロバイダのコミットされたアドレスcm、
・収集された承認署名A、
・承認ステートキーパーの定足数q
を、ユーザ110のファイナライズされたトランザクションのリストC[c].D[i]内に記憶し得、ここで、iは、現在のトランザクションのインデックスである。
【0129】
当業者によって理解されるように、RPIDは、グループ
【0130】
【数11】
【0131】
のメンバーであるので、有限数のものが存在する。したがって、ユーザ110がすでに存在するRPID値を生成する、ゼロではないが、非常に低い確率が存在する。これが発生した場合、ステートキーパー130は、支払い意図を拒否し、サービスプロバイダ120は、それに応じてユーザ110に通知することができる。ユーザ110は、支払い手順を最初から再開することができるが、このときは、支払いインデックスi+1を用いる。本発明の一実施形態によれば、最終トランザクションにおいて、衝突のために1つのインデックスがスキップされたことを通知するために追加のフィールドが追加される。
【0132】
上記で説明したような支払いプロセスの単純な実装形態において、ステートキーパー130は、すでに承認されたRPID値の増加し続けるリストを維持することになる。本発明の一実施形態によれば、ステートキーパー130が、そのストレージ要件を低減するために、そのローカルリストを切り詰め、十分に古い(例えば、24時間よりも古い)RPID値を定期的に削除することができることが規定され得る。サービスプロバイダ120は、ブロックチェーン140から十分に古い支払いインデックス値の再利用を検出することができるので、そのような切り詰めは、実行するのが安全である。
【0133】
本発明の実施形態は、トランザクションが合理的な(例えば、事前定義されたまたは設定可能な)時間の後にブロックチェーン140上に現れない場合に対処する。そのような場合、サービスプロバイダ120が、決済プロセスを開始することができることが規定され得る。悪意のあるユーザ110が自分の資金を二重消費することにより、または曖昧なステートキーパーが矛盾するトランザクションに署名することにより、支払いが失敗する可能性がある。両方の場合において、サービスプロバイダ120が支払いプロトコルに従っていることを前提として、サービスプロバイダ120が、システムのスマートコントラクト150によって払い戻される資格があることが規定され得る。
【0134】
本発明の実施形態によれば、サービスプロバイダ120がステートキーパー130の担保またはユーザ110の担保のいずれかから決済を請求することができることが規定され得る。以下、両方の場合について説明し、ここで、τは、請求されているトランザクションを示し、τ'は、τと競合する別の承認されたトランザクションを示す。
【0135】
ステートキーパーに請求する
同じステートキーパー130によって署名された競合するトランザクションが存在する場合、サービスプロバイダ120は、曖昧なステートキーパー130の担保からの請求を開始することができる。決済要求を開始するためにサービスプロバイダ120は、トランザクションをシステムに提出し得、要求は、以下の詳細、
・サービスプロバイダ120が決済したい支払い意図PINTcの詳細、
・支払い意図PINTcに署名する集約されたBLS署名A、
・支払い意図に署名した署名者の定足数q、
・ブラインド化係数rm、
・VRF証明πvrf、
・システム内に登録されたサービスプロバイダ120のセカンダリアカウントに対応する公開鍵
同じステートキーパー130によって署名された競合するトランザクションが存在する場合、サービスプロバイダ120は、曖昧なステートキーパー130の担保からの請求を開始することができる。決済要求を開始するためにサービスプロバイダ120は、トランザクションをシステムに提出し得、要求は、以下の詳細、
・サービスプロバイダ120が決済したい支払い意図PINTcの詳細、
・支払い意図PINTcに署名する集約されたBLS署名A、
・支払い意図に署名した署名者の定足数q、
・ブラインド化係数rm、
・VRF証明πvrf、
・システム内に登録されたサービスプロバイダ120のセカンダリアカウントに対応する公開鍵
【0136】
【数12】
【0137】
を用いて決済要求の詳細に署名する署名σm、
・公開鍵yskおよび
・公開鍵yskおよび
【0138】
【数13】
【0139】
を用いて支払い額を暗号化する2つの暗号文
【0140】
【数14】
【0141】
(ここで、公開鍵yskは、曖昧なステートキーパー130の担保アカウントに対応し、公開鍵
【0142】
【数15】
【0143】
は、サービスプロバイダ120のセカンダリユーザアカウントに対応する)、
・サービスプロバイダ120のセカンダリユーザアカウントのアドレスm、
・曖昧なステートキーパー130の担保アカウントのアドレス、
・競合するトランザクションのリスト
・サービスプロバイダ120のセカンダリユーザアカウントのアドレスm、
・曖昧なステートキーパー130の担保アカウントのアドレス、
・競合するトランザクションのリスト
【0144】
【数16】
【0145】
(効率のため、
【0146】
【数17】
【0147】
がτ'の詳細を含むと仮定され得る)、
・c*と
・c*と
【0148】
【数18】
【0149】
の両方が同じ値を暗号化することと、曖昧なステートキーパー130の担保が請求されている現在のトランザクションをカバーするのに十分であることとを示すゼロ知識証明πclaim(効率のため、多くても1つのステートキーパー130が請求され、したがって、サービスプロバイダ120が、特定の曖昧なステートキーパー130に対してそのようなゼロ知識証明を1つだけ提出することを必要とすると仮定される)
のうちの1つまたは複数を含み得る。
のうちの1つまたは複数を含み得る。
【0150】
本発明の一実施形態によれば、決算要求は、以下のように処理され得る。支払いシステムのスマートコントラクト150は、ブロックチェーン140のトランザクションにおいて上記の詳細を受信すると、以下のアクション、
・決済されているトランザクションがその状態においてまだ含まれていないことを検証する、
・サービスプロバイダ120の担保アカウントが支払いシステムのスマートコントラクト150において登録されていることを検証する、
・曖昧なステートキーパー130の担保アカウントが支払いシステムのスマートコントラクト150において登録されていることを検証する、
・サービスプロバイダ120の署名σmを検証する、
・請求されているステートキーパー130が両方の定足数τqおよびτ'q内に本当に含まれていることを検証する、
・それぞれ、定足数τqおよびτ'qが与えられたときの集約されたBLS署名τAおよびτ'Aを検証する、
・τcm=C(m,rm)であることをチェックすることによってコミットメントを検証する、
・ VRFverify(C[c].pkvrf,i,πvrf)=T
VRFproof2hash(πvrf)=τRPID
であることをチェックすることによって、VRF証明πvrfの正しさを検証する、
・ステートキーパー130がサービスプロバイダ120に割り当てた担保残高の(暗号化された)部分に基づいて、ゼロ知識証明πclaimの正しさを検証する、
・すべてのチェックが成功すると、支払いシステムのスマートコントラクト150が、暗号化された額c*をステートキーパー130の担保アカウントから減算し、
・決済されているトランザクションがその状態においてまだ含まれていないことを検証する、
・サービスプロバイダ120の担保アカウントが支払いシステムのスマートコントラクト150において登録されていることを検証する、
・曖昧なステートキーパー130の担保アカウントが支払いシステムのスマートコントラクト150において登録されていることを検証する、
・サービスプロバイダ120の署名σmを検証する、
・請求されているステートキーパー130が両方の定足数τqおよびτ'q内に本当に含まれていることを検証する、
・それぞれ、定足数τqおよびτ'qが与えられたときの集約されたBLS署名τAおよびτ'Aを検証する、
・τcm=C(m,rm)であることをチェックすることによってコミットメントを検証する、
・ VRFverify(C[c].pkvrf,i,πvrf)=T
VRFproof2hash(πvrf)=τRPID
であることをチェックすることによって、VRF証明πvrfの正しさを検証する、
・ステートキーパー130がサービスプロバイダ120に割り当てた担保残高の(暗号化された)部分に基づいて、ゼロ知識証明πclaimの正しさを検証する、
・すべてのチェックが成功すると、支払いシステムのスマートコントラクト150が、暗号化された額c*をステートキーパー130の担保アカウントから減算し、
【0151】
【数19】
【0152】
をサービスプロバイダ120のセカンダリユーザアカウントに加算する(これは、通常の転送プロセスに沿って行われ得る)、
・対応する額が転送されると、支払いシステムのスマートコントラクト150は、請求されたトランザクションの詳細を、ユーザ110のファイナライズされたトランザクションのリストC[c].D内に記憶する、
・正常に戻る
を実行する。
・対応する額が転送されると、支払いシステムのスマートコントラクト150は、請求されたトランザクションの詳細を、ユーザ110のファイナライズされたトランザクションのリストC[c].D内に記憶する、
・正常に戻る
を実行する。
【0153】
ユーザに請求する
競合するトランザクションが存在しない場合、サービスプロバイダ120は、ユーザ110の担保から請求を開始することができる。決済要求を開始するために、サービスプロバイダ120は、以下の詳細、
・サービスプロバイダ120が決済したい支払い意図PINTcの詳細、
・支払い意図PINTcに署名する集約されたBLS署名A、
・支払い意図に署名した署名者の定足数q、
・ブラインド化係数rm、
・VRF証明πvrf、
・ユーザ110の担保アカウントに対応する公開鍵ycを用いて決済要求の詳細に署名する署名σc、
・システム内に登録されたサービスプロバイダ120のセカンダリアカウントに対応する公開鍵
競合するトランザクションが存在しない場合、サービスプロバイダ120は、ユーザ110の担保から請求を開始することができる。決済要求を開始するために、サービスプロバイダ120は、以下の詳細、
・サービスプロバイダ120が決済したい支払い意図PINTcの詳細、
・支払い意図PINTcに署名する集約されたBLS署名A、
・支払い意図に署名した署名者の定足数q、
・ブラインド化係数rm、
・VRF証明πvrf、
・ユーザ110の担保アカウントに対応する公開鍵ycを用いて決済要求の詳細に署名する署名σc、
・システム内に登録されたサービスプロバイダ120のセカンダリアカウントに対応する公開鍵
【0154】
【数20】
【0155】
を用いて決済要求の詳細に署名する署名σm、
・それぞれ、公開鍵ycおよび
・それぞれ、公開鍵ycおよび
【0156】
【数21】
【0157】
を用いて支払い額を暗号化する2つの暗号文
【0158】
【数22】
【0159】
、
・サービスプロバイダ120の担保アカウントのアドレスm、
・承認中に保留されていたトランザクションのリスト
・サービスプロバイダ120の担保アカウントのアドレスm、
・承認中に保留されていたトランザクションのリスト
【0160】
【数23】
【0161】
・c*と
【0162】
【数24】
【0163】
の両方が同じ値を暗号化することと、ユーザ110の担保が、請求されている現在のトランザクションとともに
【0164】
【数25】
【0165】
内のすべてのトランザクションをカバーするのに十分であることとを示すゼロ知識証明πcol
のうちの1つまたは複数を用いてトランザクションを作成し得る。
のうちの1つまたは複数を用いてトランザクションを作成し得る。
【0166】
本発明の一実施形態によれば、決済要求は、以下のように処理され得る。支払いシステムのスマートコントラクト150は、ブロックチェーン140のトランザクション内の上記の詳細を受信すると、以下のアクション、
・決済されているトランザクションがその状態においてまだ含まれていないことを検証する、
・サービスプロバイダ120の担保アカウントが支払いシステムのスマートコントラクト150において登録されていることを検証する、
・曖昧なステートキーパー130の担保アカウントが支払いシステムのスマートコントラクト150において登録されていることを検証する、
・サービスプロバイダ120の署名σmを検証する、
・トランザクションτに対するユーザ110の署名を検証する、
・τまたは保留中のトランザクションのいずれかと競合するその状態におけるトランザクションが存在しないことを検証する
を実行する。実施形態によれば、これは、
- 支払いシステムのスマートコントラクト150は、ファイナライズされたトランザクションのリストを検索し、すなわち、τおよびすべての
・決済されているトランザクションがその状態においてまだ含まれていないことを検証する、
・サービスプロバイダ120の担保アカウントが支払いシステムのスマートコントラクト150において登録されていることを検証する、
・曖昧なステートキーパー130の担保アカウントが支払いシステムのスマートコントラクト150において登録されていることを検証する、
・サービスプロバイダ120の署名σmを検証する、
・トランザクションτに対するユーザ110の署名を検証する、
・τまたは保留中のトランザクションのいずれかと競合するその状態におけるトランザクションが存在しないことを検証する
を実行する。実施形態によれば、これは、
- 支払いシステムのスマートコントラクト150は、ファイナライズされたトランザクションのリストを検索し、すなわち、τおよびすべての
【0167】
【数26】
【0168】
について、C[τc].D[τi]および
【0169】
【数27】
【0170】
をチェックする、
- 支払いシステムのスマートコントラクト150は、観察されたトランザクションのリストを検索し、すなわち、τおよびすべての
- 支払いシステムのスマートコントラクト150は、観察されたトランザクションのリストを検索し、すなわち、τおよびすべての
【0171】
【数28】
【0172】
について、
【0173】
【数29】
【0174】
をチェックする、
の2つのステップにおいて発生し得、
・
の2つのステップにおいて発生し得、
・
【0175】
【数30】
【0176】
内のトランザクションの各々についてユーザ110の署名を検証し、
・定足数τqが与えられたときの集約されたBLS署名τAを検証し、
・すべての
・定足数τqが与えられたときの集約されたBLS署名τAを検証し、
・すべての
【0177】
【数31】
【0178】
について定足数τ'qが与えられたときの集約されたBLS署名τ'Aを検証し、
・τcm=C(m,rm)であることをチェックすることによってコミットメントを検証し、
・ VRFverify(C[c].pkvrf,i,πvrf)=T
VRFproof2hash(πvrf)=τRPID
であることをチェックすることによって、VRF証明πvrfの正しさを検証し、
・C[c].T[j].pcolc内に記憶された過去の担保残高を探し、ここで、jは、
[c].T[j].idx<τiVC[c].T[j].idx=⊥
および
・τcm=C(m,rm)であることをチェックすることによってコミットメントを検証し、
・ VRFverify(C[c].pkvrf,i,πvrf)=T
VRFproof2hash(πvrf)=τRPID
であることをチェックすることによって、VRF証明πvrfの正しさを検証し、
・C[c].T[j].pcolc内に記憶された過去の担保残高を探し、ここで、jは、
[c].T[j].idx<τiVC[c].T[j].idx=⊥
および
【0179】
【数32】
【0180】
の条件が満たされ、言い換えれば、エントリが、その対応するシステムインデックスが決済されたトランザクションのインデックスτjよりも小さいことを満たさなければならず、同じシステムインデックスidxを有するトランザクションがサービスプロバイダ120によって提供される保留中のトランザクションのセット内に含まれないような、最も高いインデックスであり、
・ゼロ知識証明πcol、すなわち、以前のステップにおいて見出された過去の担保残高が、決済されたトランザクションと、
・ゼロ知識証明πcol、すなわち、以前のステップにおいて見出された過去の担保残高が、決済されたトランザクションと、
【0181】
【数33】
【0182】
内のすべてのトランザクションとをカバーするのに十分であること、および
【0183】
【数34】
【0184】
が同じ値を暗号化することを検証し、
・すべてのチェックが成功すると、支払いシステムのスマートコントラクト150は、暗号化された額c*をステートキーパー130の担保アカウントから減算し、
・すべてのチェックが成功すると、支払いシステムのスマートコントラクト150は、暗号化された額c*をステートキーパー130の担保アカウントから減算し、
【0185】
【数35】
【0186】
をサービスプロバイダ120のセカンダリユーザアカウントに加算し(これは、通常の転送プロセスに沿って行われ得る)、
・対応する額が転送されると、支払いシステムのスマートコントラクト150は、新しいエントリ
C[c].T[n+1].idx←τi
および
・対応する額が転送されると、支払いシステムのスマートコントラクト150は、新しいエントリ
C[c].T[n+1].idx←τi
および
【0187】
【数36】
【0188】
を追加し、ここで、nは、リストTの長さであり、
【0189】
【数37】
【0190】
は、ユーザ110の更新された担保残高であり、
・支払いシステムのスマートコントラクト150は、決済されたトランザクションの詳細を、ユーザ110のファイナライズされたトランザクションのリストC[c].D内に記憶し、
・最後に、
・支払いシステムのスマートコントラクト150は、決済されたトランザクションの詳細を、ユーザ110のファイナライズされたトランザクションのリストC[c].D内に記憶し、
・最後に、
【0191】
【数38】
【0192】
となるようにC[c].D内のまだファイナライズされていない保留中の各トランザクション
【0193】
【数39】
【0194】
について、支払いシステムのスマートコントラクト150は、
【0195】
【数40】
【0196】
を設定し、ここで、Hは、衝突耐性ハッシュ関数であり(言い換えれば、スマートコントラクトは、支払い意図がまだファイナライズされておらず、現在観測されているだけである場合、支払い意図のハッシュを記録する)、
・正常に戻る
を実行する。
・正常に戻る
を実行する。
【0197】
本明細書で開示される実施形態による高速支払い方法/システムは、検閲耐性の利点を提供する。承認中、ステートキーパーがトランザクションに関する追加情報を知る唯一の方法は、支払い意図を検査することによる。この場合、支払い額は、意図から完全に除去されているので、ステートキーパーは、支払い額に対して検閲を実行することができない。さらに、Pedersenコミットメントは、完全に隠れており、ブラインド化値は、決してステートキーパーに開示されないので、ステートキーパーは、サービスプロバイダの身元を知ることができない。ステートキーパーは、どの時点でもステートキーパーに提供されないVRF証明を知る必要があるので、RPIDに対する辞書攻撃は不可能であることがわかる。サービスプロバイダは、プライバシーを保護する経済的インセンティブを有することが想起される。したがって、ユーザの身元も隠されたままである。
【0198】
本明細書で開示される実施形態による高速支払い方法/システムは、保証された資金のさらなる利点を提供する。サービスプロバイダの支払い意図が承認され、サービスプロバイダがプロトコルに従うと、サービスプロバイダは、支払いが失敗した場合であっても、資金を受け取ることを保証されなければならない。支払いが成功した場合、この保証は、当然満たされる。支払いが失敗した場合、サービスプロバイダがプロトコルに従っている場合、支払いシステムのスマートコントラクトは、サービスプロバイダの決済要求を常に受け入れることが示されなければならない。
【0199】
ステートキーパーの決済において、Snappyなどの高速支払いシステムの従来の設計との唯一の違いは、ステートキーパーに請求している間の最終トランザクションが、機密に実行されることである。良性のサービスプロバイダは、担保アカウント残高に対して正しいゼロ知識証明を作成するので、そのようなトランザクションは、成功することが保証される。
【0200】
ユーザが請求される場合、提供されたゼロ知識証明πcolが常に成功することが示されなければならない。ここでの主なアイデアは、正しい証明が成功しない場合、支払いシステムのスマートコントラクトは、異なる過去の担保エントリを見つける必要があるということである。設計上、このエントリは、より低いインデックスを有し、より後に(ゼロ知識証明の作成後に)決済されたトランザクションτ'に対応することになる。ゼロ知識証明の作成中にτ'が保留されていた場合、サービスプロバイダは、証明においてこのトランザクションを考慮していなかったので、サービスプロバイダ自体の失敗となる。一方、τ'が保留中ではなかった(すなわち、ファイナライズされていた)場合、サービスプロバイダは、より最近の担保残高に対してゼロ知識証明を作成すべきであったので、プロトコルに従わなかったことになる。いずれの場合でも、証明が失敗した場合、サービスプロバイダは、プロトコルに従わなかったことがわかる。
【0201】
本明細書で開示される実施形態による高速支払い方法/システムは、正しい決済のさらなる利点を提供する。ステートキーパーの決済について、支払いシステムのスマートコントラクトは、プライベートステートキーパーの担保が現在のトランザクションとすべての保留中のトランザクションとをカバーするのに十分であることを示すゼロ知識証明を検証する。したがって、敵対者が偽の証明を作成することができないことを考えれば、ステートキーパーの担保が使われすぎないことが保証される。
【0202】
正しいユーザ決済に関する議論は、もう少し複雑であり、大まかな直感についてのみ説明する。主なアイデアは、ユーザが支払い中に現在の担保のゼロ知識証明を作成することである。決済中、支払いシステムのスマートコントラクトは、対応する過去の担保を見つけるために、その状態をバックトレースする。状態Sc(図1における表を参照)がトランザクションと互換性があり(すなわち、サービスプロバイダがそのデューデリジェンスを行っており)、システム内に競合するトランザクションが存在しない場合、ユーザの担保は、コストをカバーするのに十分である。したがって、支払いシステムのスマートコントラクトは、競合するトランザクションが存在しないことをチェックし、サービスプロバイダが提供した情報と互換性がある過去の担保を見つける。互換性の証明は、添付のゼロ知識証明を提供する。
【0203】
本明細書で開示される実施形態による高速支払い方法/システムは、支払いプライバシーのさらなる利点を提供する。支払い中、良性のサービスプロバイダもユーザも、支払い中のどの時点でも自分の身元または支払い額を明らかにしない。したがって、機密性および匿名性に関するZetherにおけるのと同じ保証が、本発明の実施形態による支払いプロセスに適用される。
【0204】
本明細書で開示される実施形態による高速支払い方法/システムは、決算プライバシーのさらなる利点を提供する。決算は、匿名性をサポートしない。しかしながら、ユーザとステートキーパーの両方の担保の機密性をサポートする。ステートキーパーについて、すべてのサービスプロバイダが担保総額のすべての割り当てられた部分を開示しない場合、ステートキーパーの担保の総残高は、非公開のままである。1つのサービスプロバイダのみがその割り当てを非公開に保つ場合、正確な合計金額は、非公開のままである。部分的割り当てを明らかにすることから知られ得る唯一の情報は、ステートキーパーの担保の下限である。これは、ステートキーパーが開示された合計値を任意の他の当事者と共有せず、各サービスプロバイダに対する一部のみを共有するという事実による。さらに、担保に対するすべての動作は、ゼロ知識証明、または暗号化された準同型動作のいずれかを通じて実行され得る。
【0205】
さらに、ユーザの担保は、完全に非公開のままである。ユーザもサービスプロバイダも、いかなる時点においても自分の身元と支払い額とを開示せず、ユーザ担保に対するすべての動作は、ゼロ知識証明を通じて実行される。したがって、Zetherにおけるのと同じプライバシー保証が適用されると結論付けられ得る。当業者によって理解されるように、これは、ユーザもサービスプロバイダも支払い額を平文において公に開示しないという仮定の下で成り立つ。両方の当事者は、互いのプライバシーを保護する経済的インセンティブを有するので、これは、公正な仮定である。
【0206】
本明細書に記載の本発明の多くの変更および他の実施形態が、前述の説明および関連する図面において提示した教示の利益を有する、本発明が関係する当業者に思い浮かぶであろう。したがって、本発明は、開示された特定の実施形態に限定されるものではなく、変更および他の実施形態が添付の特許請求の範囲内に含まれることが意図されていることが理解されるべきである。本明細書において特定の用語が用いられているが、それらは、一般的かつ説明的な意味においてのみ使用されており、限定の目的のために使用されていない。
【符号の説明】
【0207】
110 ユーザ
120 サービスプロバイダ
130 ステートキーパー
140 ブロックチェーン
150 スマートコントラクト
120 サービスプロバイダ
130 ステートキーパー
140 ブロックチェーン
150 スマートコントラクト
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【国際調査報告】