特表 2024-524794 ユーザイベントストリームをダストベースのランデブートランザクションに同期する方法およびシステム

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

(12)【公報種別】公表特許公報(A)

(11)【公表番号】

(43)【公表日】2024-07-09

(54)【発明の名称】ユーザイベントストリームをダストベースのランデブートランザクションに同期する方法およびシステム

(51)【国際特許分類】

   G06Q 20/06 20120101AFI20240702BHJP

   H04L 9/32 20060101ALI20240702BHJP

【ＦＩ】

G06Q20/06

H04L9/32 200Z

【審査請求】未請求

【予備審査請求】未請求

(21)【出願番号】P 2023543016

(86)(22)【出願日】2022-06-23

(85)【翻訳文提出日】2023-09-11

(86)【国際出願番号】 EP2022067260

(87)【国際公開番号】W WO2022268995

(87)【国際公開日】2022-12-29

(31)【優先権主張番号】2109064.2

(32)【優先日】2021-06-24

(33)【優先権主張国・地域又は機関】GB

(81)【指定国・地域】

(71)【出願人】

【識別番号】318001991

【氏名又は名称】エヌチェーン ライセンシング アーゲー

(74)【代理人】

【識別番号】100108453

【弁理士】

【氏名又は名称】村山 靖彦

(74)【代理人】

【識別番号】100110364

【弁理士】

【氏名又は名称】実広 信哉

(74)【代理人】

【識別番号】100133400

【弁理士】

【氏名又は名称】阿部 達彦

(72)【発明者】

【氏名】リッキー・チャールズ・ランド

【テーマコード（参考）】

5L020

【Ｆターム（参考）】

5L020AA12

(57)【要約】

資産に対する支払いがブロックチェーントランザクションを使用して記録され、トランザクションに関連付けられた不変のログに基づいて検証される方法が提供される。

【特許請求の範囲】

【請求項1】

少なくとも第1のユーザおよび第2のユーザが関与する資産譲渡イベントを記録するコンピュータによって実装される方法であって、前記方法が、コンピューティングリソースによって実施され、前記方法が、
指示データを受信するステップであって、前記指示データが、要求された資産譲渡イベントに関連し、前記指示データが、メタデータの第1のセットが前記資産の送信者に関連し、メタデータの第2のセットが前記資産の少なくとも1人の受信者に関連し、前記送信者と前記受信者の各々が、資産レジストリに関連するアカウントにそれぞれ関連する、ステップと、
前記資産の前記送信者を第1のイベントストリームに関連付けるとともに、前記資産の前記受信者を第2のイベントストリームに関連付けるステップと、
メタデータの前記第1のセットとメタデータの前記第2のセットを比較して、譲渡プロトコルに従って、前記送信者から前記少なくとも1人の受信者への前記資産の譲渡を実行できるかを判定するステップであって、前記譲渡プロトコルが、資産譲渡イベントが行われることを可能にするための少なくとも1つの基準を定義する、ステップと、
前記譲渡プロトコルに従ったメタデータのそれぞれのセット間の比較に基づいて、メタデータのそれぞれのセット間の1つまたは複数の対応アイテムを決定するステップと、
前記送信者および前記少なくとも1人の受信者に対して、決定した対応関係に基づいて、各それぞれの第1および第2のイベントストリームに関連する以前のブロックチェーントランザクションを識別するステップと、
それぞれの第1および第2のイベントストリームを前記資産譲渡イベントに同期するためのさらなるブロックチェーントランザクションを生成するステップであって、前記さらなるブロックチェーントランザクションが、前記送信者および前記少なくとも1人の受信者の各々に対して、
前記以前のトランザクションに関連するダスト出力およびそれぞれの未使用トランザクション出力に関連するダスト入力、および前記資産譲渡イベントに関連する未使用トランザクション出力を含む、ステップと
を備える、方法。

【請求項2】

メタデータのそれぞれのセット間の1つまたは複数の対応アイテムを決定するステップは、
i)メタデータのそれぞれのセットにおいて識別された支払いの通貨、
ii)前記送信者に対応するアカウントから支払われた通貨の量、および前記受信者に対応するアカウントから要求された通貨の量、および
iii)送信者アカウントおよび受信者アカウントに関連付けられた前記資産レジストリの識別子
の少なくとも1つの間の対応を決定するステップを含む、請求項1に記載の方法。

【請求項3】

前記コンピューティングリソースは、前記譲渡プロトコルに従って、前記譲渡の実行ができないと判定し、前記譲渡プロトコルとの一致の欠如を解決するためのメタデータのさらなるセットを生成する、請求項1または2に記載の方法。

【請求項4】

メタデータの前記さらなるセットの生成は、第1の通貨と第2の通貨の変換を可能にするメタデータを生成することを含む、請求項4に記載の方法。

【請求項5】

メタデータの前記さらなるセットの生成は、1つの資産レジストリに対してメタデータを生成して、所与の資産の譲渡を別の資産レジストリに記録することを含む、請求項3または4に記載の方法。

【請求項6】

前記方法はさらに、前記アカウントの少なくとも1つに関連する資産レジストリのための以前のブロックチェーントランザクションを識別するステップを備え、前記さらなるブロックチェーントランザクションが、前記レジストリに対して識別された前記以前のトランザクションに関連するダスト出力を使用するダスト入力を含み、前記さらなるブロックチェーントランザクションはまた、前記ダスト入力に対応するそれぞれの未使用トランザクション出力(UTXO)を含む、請求項3～5のいずれか一項に記載の方法。

【請求項7】

前記方法はさらに、
前記少なくとも1つのアカウントに関連付けられた前記レジストリに関連してイベントストリームを初期化するステップと、
前記コンピューティングリソースに関連する前記イベントストリームを、前記資産譲渡イベントに基づく前記第1および第2のイベントストリームに同期するステップと
を備える、請求項6に記載の方法。

【請求項8】

前記同期は、前記資産譲渡イベントに対応するメタデータを前記資産レジストリに関連する前記イベントストリームに付け加えることを含む、請求項7に記載の方法。

【請求項9】

前記コンピューティングリソースは、暗号署名をメタデータの前記さらなるセットに適用する、請求項3～8のいずれか一項に記載の方法。

【請求項10】

前記コンピューティングリソースは、前記送信者および前記受信者に対応する暗号署名を取り出し、それぞれの暗号署名を前記メタデータに適用する、請求項1～9のいずれか一項に記載の方法。

【請求項11】

前記それぞれの暗号署名は、前記送信者および前記受信者に関連したコンピューティングデバイスから取り出される、請求項10に記載の方法。

【請求項12】

第1のユーザから第2のユーザへの資産を譲渡するコンピュータによって実装される方法であって、前記方法が、前記資産の送信者に関連する第1のコンピューティングリソースによって実施され、前記方法が、
請求項1～11のいずれか一項に記載の方法を実施するように構成された第2のコンピューティングリソースからの資産の譲渡の要求を受信するステップと、
(i)前記譲渡に使用されるアカウント、
(ii)前記アカウントから引き出される前記資産の量、および
(iii)前記譲渡に使用される前記通貨のインジケータ
を示すメタデータの第1のセットを生成するステップと、
前記第2のコンピューティングリソースにメタデータの前記第1のセットを送信して、前記譲渡を開始するステップと、
前記第2のコンピューティングリソースから前記要求された譲渡に関連する指示データを受信するステップと、
暗号署名を使用して前記指示データに署名して、署名済み指示データを生成するステップと、
前記署名済み指示データを前記第2のコンピューティングリソースに送信するステップと
を備える、方法。

【請求項13】

請求項1～12のいずれか一項に記載の資産譲渡イベントを検証するコンピュータによって実装される方法であって、前記方法が、第1のコンピューティングリソースによって実施され、前記方法が、
コンピューティングリソースから、資産譲渡イベントに関連する識別子を有する資産譲渡イベントを検証する要求を受信するステップと、
前記識別子に関連するイベントストリームエントリを探索して、前記資産譲渡イベントに関連するメタデータを抽出するステップと、
資産譲渡イベントの確認をコンピューティングリソースに送信するステップと
を備える、方法。

【請求項14】

請求項1～13のいずれか一項に記載の方法を実施するように構成されたシステム。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、概して、1つまたは複数のクライアントのための、分散型台帳、すなわち、ブロックチェーンに関連する1つまたは複数のサービスのプラットフォームを実装するための方法およびシステムに関する。特に、本開示は、デジタルまたはトークン化された資産の譲渡を可能にすることなどの、1つまたは複数のクライアントのための、ブロックチェーンに関連する複数の機能およびアプリケーションへのアクセスの提供に関するが、これに限定されない。

【背景技術】

【0002】

本明細書において、我々は、電子的な、コンピュータベースの分散型台帳のすべての形態を含むように用語「ブロックチェーン」を用いる。これらは、コンセンサスベースのブロックチェーンおよびトランザクションチェーンテクノロジー、許可型および非許可型台帳、共有台帳、パブリックおよびプライベートブロックチェーン、ならびにそれらのバリエーションを含む。その他のブロックチェーンの実装が提案され、開発されてきたが、ブロックチェーンテクノロジーの最も広く知られている応用は、ビットコイン台帳である。便宜上および説明の目的で本明細書においてはビットコインが参照される場合があるが、本開示は、ビットコインのブロックチェーンとの使用に限定されず、任意の種類のデジタル資産またはデジタル資産の表現に関連する代替的なブロックチェーンの実装およびプロトコルは、本開示の範囲に入ることに留意されたい。用語「クライアント」、「エンティティ」、「ノード」、「ユーザ」、「送信者」、「受信者」、「支払者」、「被支払者」は、本明細書においては、コンピューティングまたはプロセッサベースのリソースを指す場合がある。用語「ビットコイン」は、本明細書においては、ビットコインプロトコルに由来するかまたはビットコインプロトコルに基づく任意のバージョンまたはバリエーションを含むように用いられる。用語「デジタル資産」は、暗号通貨、財産の少なくとも一部を表すトークン、スマートコントラクト、ライセンス、すなわち、ソフトウェアライセンス、またはメディアコンテンツのDRM契約などの任意の譲渡可能な資産を指す場合がある。用語「デジタル資産」が、本明細書全体を通じて、あるエンティティから別のエンティティにトランザクションの支払いとして譲渡または提供されてよい価値に関連付けられる可能性がある商品を表すために用いられることは理解されるであろう。

【0003】

ブロックチェーンは、ピアツーピアの電子台帳であり、その電子台帳は、ブロックから構成される、コンピュータベースの非集中的な分散型システムとして実装され、そしてさらに、それらのブロックは、トランザクションから構成される。各トランザクションは、ブロックチェーンシステムの参加者の間でのデジタル資産の制御の移転を符号化し、少なくとも1つの入力および少なくとも1つの出力を含むデータ構造である。各ブロックは、ブロックチェーンの開始以来、ブロックチェーンに書き込まれたすべてのトランザクションの永久的で変更不可能な記録を作成するために鎖状になるように、前のブロックのハッシュを含む。トランザクションは、トランザクションの出力がどのようにしておよび誰によってアクセスされ得るかを指定する、トランザクションの入力および出力に埋め込まれた、スクリプトとして知られる小さなプログラムを含む。ビットコインプラットフォームにおいて、これらのスクリプトは、スタックベースのスクリプト言語を用いて記述される。

【0004】

トランザクションがブロックチェーンに書き込まれるためには、トランザクションが、「有効化」されなければならない。ネットワークノード(マイナー)は、各トランザクションが有効であることを保証するための作業を実行し、無効なトランザクションは、ネットワークから拒否される。ノードにインストールされたソフトウェアクライアントが、未使用トランザクション(UTXO: unspent transaction)に対して、そのロックおよびロック解除スクリプトを実行することによってこの有効化作業を実行する。ロックおよびロック解除スクリプトの実行がTRUEと評価される場合、そのトランザクションは、有効であり、そして、トランザクションは、ブロックチェーンに書き込まれる。したがって、トランザクションがブロックチェーンに書き込まれるためには、トランザクションが、i)トランザクションを受信する第1のノードによって有効化され--トランザクションが有効化される場合、ノードはトランザクションをネットワークのその他のノードに中継する--、ii)マイナーによって構築された新しいブロックに追加され、iii)マイニングされ、つまり、過去のトランザクションの公開台帳に追加されなければならない。

【0005】

マイナーによって実行される作業の性質が、ブロックチェーンを維持するために用いられるコンセンサスメカニズムの種類に応じて決まることは理解されるであろう。プルーフオブワーク(PoW)が、元々のビットコインプロトコルに関連付けられるが、プルーフオブステーク(PoS)、委任型プルーフオブステーク(DPoS: delegated proof of stake)、プルーフオブキャパシティ(PoC: proof of capacity)、プルーフオブエラプストタイム(PoET: proof of elapsed time)、プルーフオブオーソリティ(PoA: proof of authority)などのその他のコンセンサスメカニズムが用いられてよいことは理解されるであろう。異なるコンセンサスメカニズムは、マイニングがノードの間にどのように分散されるかという点で異なり、ブロックを成功裏にマイニングする公算は、たとえば、マイナーのハッシュパワー(PoW)、マイナーによって保有される暗号通貨の量(PoS)、代行マイナー(delegate miner)に託された暗号通貨の量(DPoS)、暗号パズルの所定の解を記憶するマイナーの能力(PoC)、マイナーにランダムに割り振られた待ち時間(PoET)などに応じて決まる。通常、マイナーは、ブロックをマイニングすることに関するインセンティブまたは報酬を提供される。たとえば、ビットコインのブロックチェーンは、マイナーに新たに発行された暗号通貨(ビットコイン)とブロック内のトランザクションに関連する手数料(取引手数料)とを報酬として与える。ビットコインのブロックチェーンに関しては、発行される暗号通貨の量が、時間の経過とともに減少し、インセンティブは、最終的には取引手数料のみからなる。したがって、取引手数料の処理は、ビットコインのブロックチェーンなどのパブリックブロックチェーンにデータをコミットする(commit)ための基礎となるメカニズムの一部であることが理解されるであろう。

【0006】

上述のように、所与のブロック内の各トランザクションは、ブロックチェーンシステムの参加者の間のデジタル資産の制御の移転を符号化する。デジタル資産は、必ずしも暗号通貨に対応するとは限らない。たとえば、デジタル資産は、ドキュメント、画像、物理的な物体などのデジタル表現に関連する場合がある。マイナーへの暗号通貨および/または取引手数料の支払いは、単純に、必要な作業を行うことによってブロックチェーンの有効性を維持するためのインセンティブとして作用する可能性がある。ブロックチェーンに関連する暗号通貨は、マイナーのセキュリティとして働き、ブロックチェーン自体は、主に暗号通貨以外のデジタル資産に関連するトランザクションの台帳であることがある。場合によっては、参加者の間の暗号通貨の譲渡は、トランザクションの台帳を維持するためにブロックチェーンを用いるエンティティとは異なるおよび/または無関係なエンティティによって処理されることがある。

【0007】

UTXOとしてブロックチェーンに記憶されると、ユーザは、関連するリソースの制御を、別のトランザクションの入力に関連する別のアドレスに移転することができる。この移転は、通常、デジタルウォレットを用いて行われるが、絶対にはそうであるとは限らない。このデジタルウォレットは、デバイス、物理的な媒体、プログラム、デスクトップ、ラップトップ、もしくはモバイル端末などのコンピューティングデバイス上のアプリケーション(アプリ)、またはインターネットなどのネットワーク上のドメインに関連付けられたリモートでホストされたサービスであってよい。デジタルウォレットは、公開鍵および秘密鍵を記憶し、ユーザに関連するリソース、トークン、および資産などの所有権を追跡し、デジタル資産を受け取るかまたは消費し、暗号通貨、ライセンス、財産、もしくはその他の種類のリソースなどのデジタル資産に関連する場合があるトークンを転送するために用いられ得る。

【0008】

ブロックチェーンテクノロジーは、暗号通貨の実装の使用に関して最も広く知られているが、デジタル起業家たちは、新しいシステムを実装するための、ビットコインが基づいている暗号セキュリティシステムと、ブロックチェーン上に記憶され得るデータとの両方の使用を模索している。ブロックチェーンテクノロジーは、暗号通貨の領域に限定されない自動化されたタスクおよびプロセスにブロックチェーンが用いられる可能性がある場合、非常に有利である。そのような解決策は、それらの用途をより広げながら、ブロックチェーンの利点(たとえば、イベントの永久的な改ざん防止(tamper-proof)記録、分散処理など)を利用することができる。

【0009】

現在の研究の1つの分野は、「スマートコントラクト」の実装のためのブロックチェーンの使用である。機械可読コントラクトまたは合意の条項の実行を自動化するために設計されたコンピュータプログラムが、存在する。自然言語で書かれる従来の契約とは異なり、スマートコントラクトは、結果を生成するために入力を処理することができ、それらの結果に応じてアクションを実行させることができる規則を含む機械によって実行可能なプログラムである。

【0010】

特に、研究の1つの分野は、資産の譲渡と、譲渡がブロックチェーンの不変性の恩恵を受けることを保証するためにその譲渡がブロックチェーンにどのように記録され得るかとに関する。さらに、基礎となるブロックチェーンインフラストラクチャのサポートを受けて資産の譲渡が安全に記録され、ロギングされることを保証するためにそのような譲渡をロギングする手段に加えて、資産の譲渡のための効率的で安全なプロトコルを提供することが、特に関心を集めている。

【先行技術文献】

【特許文献】

【0011】

【特許文献1】英国特許出願第2102314.8号

【特許文献2】英国特許出願第2102217.3号

【発明の概要】

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

【0012】

本明細書全体を通じて、単語「～を含む(comprise)」、または「～を含む(includes)」、「～を含む(comprises)」、もしくは「～を含んでいる(comprising)」などの変化形は、記載の要素、完全体(integer)、ステップ、または要素、完全体、もしくはステップのグループの包含を示唆するが、いかなるその他の要素、完全体、ステップ、または要素、完全体、もしくはステップのグループの除外も示唆しないと理解される。

【0013】

本開示は、たとえば、商品と引き換えの通貨の支払いである可能性がある支払いイベントの記録を可能にすることができる方法およびシステムに関する。

【0014】

一部の実施形態においては、少なくとも第1のユーザおよび第2のユーザを含む資産譲渡イベントを記録するコンピュータによって実装される方法が提供される。資産は、ブロックチェーントークンを用いた物理的資産の表現と理解されてよい。資産は、ブロックチェーントークンを用いて表されている貴金属である場合がある。資産は、トークン化された資産である場合がある。トークン化された資産は、ある量の通貨である場合がある。資産は、製品またはサービスである場合がある。資産譲渡イベントは、製品、品物、またはサービスに対する通貨の支払いである場合がある。一部の実施形態は、通貨の支払いが記録されることを可能にする場合がある。通貨の支払いは、任意の通貨もしくは通貨の種類であってよく、商品もしくはサービスに対するものであってよく、または異なる通貨もしくは通貨の種類との両替であってよい。一部の実施形態は、コンピューティングリソースによって実施されてよい。コンピューティングリソースは、ハードウェアまたはソフトウェアによって実装される場合がある。コンピューティングリソースは、局所的にかまたは広い地理的エリアにかのどちらかに分散される場合がある複数の処理リソースを含んでよい。方法は、指示データを受信するステップであって、指示データが、要求された資産譲渡イベントに関連し、指示データが、資産譲渡の送信者に関連するメタデータの第1のセット、および資産譲渡の少なくとも1人の受信者に関連するメタデータの第2のセットを含む、ステップを含んでよい。メタデータは、たとえば、支払いの通貨、アカウント、譲渡を受け取るようにまたは譲渡を行うように指定された個人、支払いの条項および条件、ならびに支払いを承認する公開鍵またはデジタル署名の証拠のうちの少なくとも1つを特定する場合がある。送信者および受信者は、資産レジストリ(asset registry)に関連するアカウントにそれぞれ関連付けられてよい。資産の送信者は、第1のイベントストリームと関連し、資産の受信者は、第2のイベントストリームに関連してよい。

【0015】

資産レジストリは、個人または組織によって所有される資産のレジストリのことである。資産の例は、それぞれの個人または組織によって所有または制御される任意のリソースを含む。資産の例は、現金または金銭的価値のある他の任意のものを含む。資産レジストリの例は、たとえば、特定の通貨でトランザクションに資金を供給するために用いられ得るアカウントに対する現金預金を記録する銀行である場合がある。別の例は、個人によって所有される金預託の記録簿である金アカウントである場合がある。資産レジストリは、資産レジストリによって管理されるアカウントに関連する資産の発行者に関連付けられる。例示的な発行者は、王立造幣局である可能性がある。

【0016】

実施形態では、送信者に対応する第1のイベントストリームと、少なくとも1人の受信者に対応する第2のイベントストリームとを初期化するステップをさらに含む方法を提供する。実施形態は、代替的または追加的に、それぞれ送信者および受信者に対応する第1のイベントストリームまたは第2のイベントストリームにアクセスステップを含み得る。イベントストリームは、任意の適切なハードウェアまたはデータ構造を使用して実装され得る。実施形態によって提供される方法はさらに、メタデータの第1のセットとメタデータの第2のセットを比較して、譲渡プロトコルに従って、前記第2のセットから少なくとも1人の受信者への譲渡を実行できるかどうかを判定するステップを備え得る。支払いプロトコルに従ったメタデータのそれぞれのセット間の比較に基づいて、実施形態によって提供される方法は、メタデータのそれぞれのセット間の1つまたは複数の対応アイテムを決定するステップを備える。譲渡プロトコルは、資産譲渡イベントが行われることを可能にするために満たされる必要がある少なくとも1つの基準を定義してよい。少なくとも1つの基準は、送信者および受信者が同じ資産レジストリに関連するアカウントに関連付けられることを必要とする場合がある。たとえば、少なくとも1つの基準は、アカウントが同じ銀行のものであることを必要とする場合がある。少なくとも1つの基準は、アカウントが同じ種類の資産に関連付けられることを必要とする場合がある。たとえば、そのような基準は、両方のアカウントがスターリングポンド(GBP)建てであることを必要とする場合がある。

【0017】

イベントストリームは、ブロックチェーン対応の追加専用ログを有し、ブロックチェーントランザクションに記録されたデータは、時系列に並んだログに追加される。すなわち、イベントストリームは、ブロックチェーンに記録されたデータを時間順に、すなわちブロックチェーン上に出現した順に記録できる。これは、ブロックチェーン上のブロック内のトランザクションの順序が、通常、イベントストリームに記録された対応するイベントの対応するインデックスによって反映されることを意味する。しかしながら、これは必ずしもそうである必要はない。2つの同時イベントは、イベントの順序がブロック内のトランザクションの順序に反映されないことを意味する。たとえば、インデックスN+1を持つイベントストリーム上のイベントはブロックBに記録され、インデックスNを持つイベント(すなわち、他のイベントの前にイベントストリームに記録される)はブロックB+1に記録されることがある。

【0018】

イベントストリームは、適切なデータ構造を使用して実装され得る。イベントストリームは、シーケンス内に格納された一連のエントリを含むことができ、シーケンス内の各エントリは、単調増加する数によってシーケンス内で参照される。つまり、イベントストリームの第1のエントリは、エントリ1、第2のエントリはエントリ2となる。基礎となるブロックチェーンの利用は、イベントストリーム内の個々のエントリが書き込まれてから変更されていないこと、以前に隣接したエントリの間にエントリが挿入されていないこと、エントリが削除されていないこと、およびエントリが再順序付けされていないことを保証できることを意味する。また、権限のない当事者がイベントストリームにイベントを付け加えることもできない。イベントストリームはオフチェーン、つまりブロックチェーン上にないことがある。悪意のある当事者がイベントストリームにイベントを追加することができるが、イベントストリームを初期化したユーザは、イベントを追加しようとする悪意のある当事者のインスタンスを検出可能にするように、イベントストリームに付け加えられるすべてのイベントに署名する必要がある。

【0019】

決定された対応関係に基づいて、送信者および少なくとも1人の受信者について、以前のブロックチェーントランザクションを識別することができる。実施形態によって提供される方法はさらに、支払いイベントのためのさらなるブロックチェーントランザクションを生成するステップであって、さらなるブロックチェーントランザクションが、送信者および少なくとも1人の受信者の各々に対する、以前のトランザクションに関連するダスト出力を使用するダスト入力および、ダスト入力に対応するそれぞれの未使用トランザクション出力(UTXO)、および譲渡イベントに関連する未使用トランザクション出力を含む、ステップと、それぞれの第1および第2のイベントストリームを支払いイベントに同期するステップとを備える。

【0020】

上記の方法により、ブロックチェーンの不変性に依存することができ、暗号通貨の支払いに関連する必要のない資産譲渡イベントを記録できるようになる。譲渡は、資産レジストリに関連するあるアカウントから資産レジストリに関連する別のアカウントに実行され、次いで、支払いに関連するメタデータを記録するイベントストリームに対して安全に検証され得る。

【0021】

ダスト入力は一般に、マイナーがその時点で処理しようとする暗号通貨の最小量に相当する。この値は、時間とともに変化し、したがって、特定の値に限定されないことがわかる。ダスト入力は一般に、マイナーが処理しようとする暗号通貨の最小量に相当し、マイナーがより小さな値を処理しないように、ダスト入力は実質的に分割できない。このことは、ダスト入力を分割することは事実上不可能であり、マイナーが処理できるダスト入力より小さいものは存在しないため、悪意のある第三者の攻撃者がダスト入力を使用してチェーンを分割することはより困難であることを意味する。言い換えると、ダスト入力が分割できないので、チェーンは依然としてほぼ分割不可能であるため、ダスト入力に対応する暗号通貨の量が経時的に変化し、任意の時点でマイナーが処理しようとする最小量を使用して、ダスト入力をサポートし、セキュリティを維持することができる。

【0022】

いくつかの実施形態では、アセットレジストリに関連する第1のアカウントからアセットレジストリに関連する第2のアカウントへの資産の譲渡のコンピュータによって実装される方法が提供される。実施形態によって提供される方法は、譲渡の送信者に関連する第1のコンピューティングリソースによって実施される。実施形態によって提供される方法は、第1の態様の方法を実施するように構成された第2のコンピューティングリソースから資産の譲渡の要求を受信するステップを含む。

【0023】

実施形態によって提供される方法はさらに、
(i)譲渡のために使用される少なくとも1つの送信者アカウントに関連する資産レジストリ、
(ii)送信者アカウントから引き出される資産の価値、および
(iii)譲渡のために使用される資産のインジケータ
を示すメタデータの第1のセットを生成するステップを含む。

【0024】

実施形態によって提供される方法はさらに、
メタデータの第1のセットを第2のコンピューティングリソースに送信して、譲渡を開始するステップと、
第2のコンピューティングリソースから要求された譲渡に関連する指示データを受信するステップと、
暗号署名を使用して指示データに署名して、署名済み指示データを生成するステップと、
署名済み指示データを第2のコンピューティングリソースに送信するステップと
を備える。

【0025】

譲渡を開始するために、メタデータの第1のセットが、第2のコンピューティングリソースのユーザから要求された指示データを要求するために、第2のコンピューティングリソースに送られる。

【0026】

上記方法によって、コンピューティングデバイスは、資産の譲渡が可能になり、第1の態様によって提供されるアプローチの不変性、機密性、およびセキュリティの恩恵を受けることができる。

【0027】

いくつかの実施形態では、第1の態様に従って記録された資産譲渡イベントを検証するコンピュータによって実装される方法であって、方法が、第1のコンピューティングリソースによって実施され、
要求を受信して、資産譲渡イベントを検証するステップであって、要求が、コンピューティングリソースからの資産譲渡イベントに関連する識別子を含む、ステップと、
識別子に関連するイベントストリームエントリを探索して、資産譲渡イベントに関連するメタデータを抽出するステップと、
資産譲渡イベントの確認をコンピューティングリソースに送信するステップと
を備える。

【0028】

本開示の態様および実施形態が、単に例として、添付の図面を参照して以降で説明される。

【図面の簡単な説明】

【0029】

【図1a】実施形態に係るシステムを示す図である。

【図1b】ブロックチェーントランザクションを有効化するためにビットコインソフトウェアを実装するように構成されたノードを示す図である。

【図1c】ブロックチェーンネットワークを示す図である。

【図2】実施形態によるアカウントのセットアップを詳細に示す流れ図である。

【図3a】実施形態による送信者から受信者への支払いを詳細に示す流れ図である。

【図3b】実施形態による送信者から受信者への支払いを詳細に示す流れ図である

【図3c】実施形態によるランデブートランザクションを示す図である。

【図3d】ダストトランザクションのチェーンとイベントストリームとの間の関係を示す図である。

【図3e】トランザクションの関係者に対応する複数のイベントストリームを示す図である。

【図4a】実施形態による送信者から受信者への支払いを詳細に示す流れ図である。

【図4b】実施形態によるランデブートランザクションを示す図である。

【図4c】トランザクションの関係者に対応する複数のイベントストリームを示す図である。

【図5a】実施形態による送信者から受信者への支払いを詳細に示す流れ図である。

【図5b】実施形態によるランデブートランザクションを示す図である。

【図5c】トランザクションの関係者に対応する複数のイベントストリームを示す図である。

【図6a】実施形態による送信者から受信者への支払いを詳細に示す流れ図である。

【図6b】実施形態による送信者から受信者への支払いを詳細に示す流れ図である

【図7】実施形態によって生成されるランデブーブロックチェーントランザクションを示す図である。

【図8】実施形態によるトランザクションの関係者のイベントストリームを示す図である。

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

【0030】

以降で、読者に本開示の最大限の完全な理解をもたらすために、本開示の態様および実施形態の詳細な検討を提供する。

【0031】

第1の態様から見ると、少なくとも第1のユーザおよび第2のユーザを含む資産譲渡イベントを記録するコンピュータによって実装される方法が提供される。方法は、通貨の支払いが記録されることを可能にする場合がある。通貨の支払いは、任意の通貨によるものであることが可能であり、商品またはサービスのためのものである場合がある。方法は、コンピューティングリソースによって実施されてよい。コンピューティングリソースは、ハードウェアまたはソフトウェアによって実装される場合がある。コンピューティングリソースは、局所的にかまたは広い地理的エリアにかのどちらかに分散される場合がある複数の処理リソースを含んでよい。方法は、指示データを受信するステップであって、指示データが、要求された資産譲渡イベントに関連し、指示データが、支払いの送信者に関連するメタデータの第1のセット、および支払いの少なくとも1人の受信者に関連するメタデータの第2のセットを含む、ステップを含んでよい。メタデータは、支払いの通貨、資産レジストリに関連するアカウント、支払いを受け取るようにまたは支払いを行うように指定された個人、支払いの条項および条件、ならびに支払いを承認する公開鍵またはデジタル署名の証拠のうちの少なくとも1つを特定する場合がある。送信者および受信者の各々は、資産レジストリに関連するアカウントにそれぞれ関連付けられてよい。

【0032】

資産の送信者は、第1のイベントストリームに関連付けられてよく、資産の受信者は、第2のイベントストリームに関連付けられてよい。イベントストリームとの関連付けは、ユーザが、そのイベントストリームにデータを付け加えることを可能にする暗号鍵を保持することを意味するか、および/または、ユーザまたはユーザによって動作されたコンピューティングリソースによってデータが付け加えられたイベントストリームをユーザが初期化および/または終了できることを意味する。イベントストリームの初期化は、イベントストリームの実施に必要なコンピューティングリソースの構成を含み得る。

【0033】

方法はさらに、送信者に対応する第1のイベントストリームと、少なくとも1人の受信者に対応する第2のイベントストリームとを初期化するステップを備える。イベントストリームは、任意の適切なハードウェアまたはデータ構造を使用して実装される。方法はさらに、送信者に対応する第1のイベントストリームの詳細を取り出すステップ、および/または少なくとも1人の受信者に対応する第2のイベントストリームの詳細を取り出すステップを備える。

【0034】

方法はさらに、メタデータの第1のセットとメタデータの第2のセットを比較して、譲渡プロトコルに従って、送信者から少なくとも1人の受信者への譲渡を実行できるかどうかを判定するステップと、譲渡プロトコルに従ったメタデータのそれぞれのセット間の比較に基づいて、メタデータのそれぞれのセット間の1つまたは複数の対応アイテムを決定するステップと、送信者および少なくとも1人の受信者に対して、決定した対応関係に基づいて、少なくとも1つの以前のブロックチェーントランザクションを識別するステップとを備え、この以前のブロックチェーントランザクションは、ダスト出力を含む。以前のブロックチェーントランザクションは、送信者および受信者のために識別される。ブロックチェーントランザクションはまた、資産レジストリと、送信者および受信者に対応するアカウントに関連する資産の発行者とのために識別される。

【0035】

方法はさらに、資産譲渡イベントのためのさらなるブロックチェーントランザクションを生成するステップであって、さらなるブロックチェーントランザクションが、送信者および少なくとも1人の受信者の各々について、ダスト入力が、以前のトランザクションに関連するダスト出力、ダスト出力に対応する(すなわち、トランザクションのインデックスが一致している)それぞれの未使用トランザクション出力(UTXO)、および資産譲渡イベントに関連する未使用トランザクション出力を使用する、ステップと、資産譲渡イベントにそれぞれ第1および第2のイベントストリームを同期するステップとを備える。

【0036】

有利なことに、第1の態様による方法は、資産譲渡イベントを記録できる。記録はブロックチェーンに関連付けられたデータストリームに記録されるため、資産譲渡イベントの記録はブロックチェーンの不変性に依存することができ、暗号通貨の支払いに関連する必要はない。あるアカウントから別のアカウントに譲渡を行うことができ、支払いに関連付けられたメタデータを記録するイベントストリームに対して安全に検証され得る。

【0037】

任意で、譲渡プロトコルに従って、メタデータのそれぞれのセット間の比較に基づいて、方法は、
i)メタデータのそれぞれのセットにおいて識別された資産のアイデンティティ、
ii)送信者に対応するアカウントから譲渡された資産の価値、および受信者に対応するアカウントから要求された資産の価値、および
iii)送信者アカウントおよび受信者アカウントに関連付けられた資産レジストリの識別子
の少なくとも1つの間の対応関係を決定するステップを備える。

【0038】

資産レジストリの例は、銀行、金保管所、または資産の所有権が詳細に記載されている別のレジストリが挙げられる。資産のアイデンティティ間の対応関係を決定することは、送信者と受信者が使用する通貨が同一であると決定することを含み得る。転送される資産の価値間の対応関係を決定することは、受信者のアカウントから支払われる通貨の量と送信者のアカウントに支払われる通貨の量、またはその逆が等しいことを決定することを含み得る。資産レジストリの識別子間の対応関係を決定することは、送信者と受信者の銀行が同一であるか、または貴金属造幣局(例えば、王立造幣局の金保管庫)が、送信者と受信者の両方の貴金属アカウントのためのレジストリとして使用されていることを決定することを含み得る。

【0039】

有利なことに、これにより、資産のアイデンティティ、資産の量、および資産レジストリを提供する当事者の識別のうちの少なくとも1つの間で対応が決定できる場合にのみ、資産の譲渡を記録できるようになる。これは、この方法では譲渡条件が一致している譲渡のみが記録されることを意味する。

【0040】

任意で、さらなるブロックチェーントランザクションは、複数のイベントストリームを同期させるためのランデブーブロックチェーントランザクションであってもよく、トランザクションは、資産譲渡イベントに関連付けられたメタデータを含む少なくとも1つのデータキャリアを含む。データキャリアは、資産譲渡イベントに関連付けられたメタデータのハッシュを含み得る。

【0041】

ランデブートランザクションは、複数のダストチェーン入力/出力ペアと、出力を無効にし、データキャリアの追加を可能にするためにOP_RETURNオペコードでマークされた出力とを含むブロックチェーントランザクションである。OP_RETURNオペコードは、対応する引き換えスクリプトの実行を即時に終了させ、スクリプトを無効にする、すなわち、出力を引き換えることはできない。これは、出力を使用することができず、データキャリアがランデブートランザクションの一部としてブロックチェーン上に残ることを意味する。ダストチェーンの入力/出力ペアは、トランザクション内で同じインデックスを持つことができ、それぞれ入力資金と交換出力を進めることができる。データキャリアは最終出力であってよい。ランデブートランザクションを形成する複数のダストチェーン入力は、それぞれ異なるイベントストリームからのものであってもよい。

【0042】

有利なことに、この効果は、トランザクションの複数の当事者をリソースによってメソッドに統合でき、各当事者がブロックチェーンの不変性の恩恵を受けて、セキュリティや機密性を損なうことなくそれぞれのイベントストリームにトランザクションを記録できることである。メタデータのハッシュを使用することにより、トランザクションの詳細を悪意のある行為者に公開することなく、トランザクションのメタデータを証明できる。2つの異なるメタデータセットが同じハッシュを生成しないことを考えると、これは、メタデータのハッシュを生成するデータがブロックチェーン上に存在することを示したい当事者が資産譲渡イベントを検証できることを意味する。

【0043】

任意で、ランデブートランザクションを使用してそれぞれの第1および第2のイベントストリームを資産譲渡イベントと同期させることは、資産譲渡イベントに関連付けられたメタデータの表現をそれぞれの第1および第2のイベントストリームのそれぞれに付け加えることを含む。

【0044】

有利なことに、これは、メタデータの表現を使用して支払いが行われたことを確認できることを意味する。メタデータの表現は、メタデータのハッシュであってもよい。メタデータのハッシュを使用する効果は、機密性を損なうことなく譲渡を記録できることを意味する。

【0045】

任意で、少なくとも1つのデータキャリアは、さらなるブロックチェーントランザクションの無効な出力に割り当てられる。すなわち、無効な出力は、出力が決して引き換えられないがデータキャリアがトランザクション内に残ることを保証するためのOP_RETURNオペコードを含む引き換えスクリプトを含むことがある。有利なことに、これにより、データキャリアに含まれるデータを対応するトランザクションに格納できるようになる。

【0046】

各データキャリアは、個別のdataDigestを保持してよい。dataDigestは、オフチェーンに格納されるイベントデータ、および/またはデータキャリアのペイロードのイベントデータ表現内のトランザクションに格納されるイベントデータのハッシュであある。

【0047】

各データキャリアは、個別のstreamDigestを保持してよい。streamDigestは、イベントストリームの先行状態のプリイメージのハッシュ(イベントストリームの先行状態のストリームダイジェスト、またはストリームダイジェスト参照とも記述され得る)、または最初のトランザクションのシード(最初のトランザクションはstreamDigestを含まないため、トランザクションがチェーン内の2番目のトランザクションである場合)である。プリイメージのハッシュのstreamDigestである。

【0048】

任意で、streamDigestはソルトされ得る。一意の値であるソルトは、イベントストリームに関連付けられたトランザクションごとにランダムに生成できる。ソルトは、任意でオフチェーンに格納される。データのソルティングには、何も明らかにせず、ブレインウォレット攻撃などのブルートフォースのプレイメージ攻撃を防ぐという利点がある。

【0049】

すべての当事者のデータキャリアのそれぞれは同一であり、同じデータと同じ支払い指示データセットに基づいていることがある。データキャリアは、キャリアが追加される特定のデータストリームのstreamStateに基づいて、いくつかの異なるデータを保持し、streamStateは、以前のstreamStateおよび/またはインデックス(またはシーケンス番号)および/またはそのデータキャリアの表記のために使用される個々のソルトに基づく。

【0050】

streamStateは、対応するイベントストリーム中の全データの現在の累積状態を指すパラメータとして定義され得る。これは、すべてのメッセージデータとストリーム内の各データアイテムの位置を組み込んだダイジェストとして表現され得る。streamStateがオンチェーンで記録されるとき、最新のリンクされたイベントのプリイメージと、任意でデータ項目自体が伴うことがある。

【0051】

streamStateは、各イベントがストリームに追加されるときに維持され得る。ダイジェストは、個々のイベントデータとともに、settStreamOnChainおよびSettleDataOnChainの値に従ってオンチェーンで決済され得る。

【0052】

プリイメージは、任意で以下のフィールドの任意の1つのまたは複数を有する:
・Txid_create:チェーン内の最初のトランザクションへの参照、好ましくはチェーン内の最初のトランザクションのトランザクションID、
・index:データまたはイベントのインデックス、
・whenRecorded:トランザクションおよび/またはデータアイテムの作成と関連する時間、
・dataDegest_n:オフチェーンで格納された(および、任意で、ペイロード([...])のイベントデータ表現中のトランザクション上に格納された)ときのイベントデータのハッシュ、および
streamDigest_n-1:イベントストリームの先行状態のプリイメージのハッシュ(イベントストリームの先行状態のストリームダイジェストまたはストリームダイジェスト参照とも呼ばれる)、または最初のトランザクションのシード(最初のトランザクションがstreamDigestを含まず、そのトランザクションがチェーン内の2番目のトランザクションである場合)。
ストリームダイジェスト(streamDigest)は、プリイメージのハッシュである。

【0053】

任意で、コンピューティングリソースは、譲渡プロトコルに従って、譲渡を実行できないと決定し、譲渡プロトコルとの一致の欠如を解決するためにメタデータのさらなるセットを生成する。一致の欠如とは、資産のアイデンティティ、資産レジストリの識別、または譲渡される金額の間の不一致であることがある。この効果は、コンピューティングリソースが、資産のアイデンティティ、資産レジストリ(例えば、銀行)、または譲渡される資産の金額の少なくとも1つの間に不一致が存在する場合であっても、譲渡を容易にするためにさらなるメタデータを導入できることである。

【0054】

メタデータのさらなるセットの生成は、資産レジストリから/資産レジストリへの資産譲渡(例えば、支払い)の詳細を有するさらなる支払い指示データ、および/または、譲渡される資産の価値の金額における不一致に対処するための資産および/または支払い詳細の間の変換を生成することを含む。メタデータのさらなるセットの生成はまた、資産レジストリまたは資産の発行者に対応する暗号署名を取得することを含む。

【0055】

例えば、メタデータのさらなるセットの生成は、第1の通貨と第2の通貨の間の変換を可能にするメタデータを生成することを含む。第1の通貨と第2の通貨の間の変換を可能にするメタデータは、第1の通貨の発行者に関連する資産レジストリへの第1の通貨の支払いを詳述するデータ、および/または、第2の通貨の発行者に関連する資産レジストリからの第2の通貨の支払いを詳述するデータを含む。これにより、マルチ通貨取引、つまり国境を越えた取引をその態様に従って記録できるようになる。

【0056】

例えば、メタデータのさらなるセットの生成は、資産の異なる発行者が存在する場合でも、資産の譲渡を可能にするメタデータを生成することを含む。

【0057】

任意で、方法はさらに、資産レジストリおよび/または資産の発行者のために以前のブロックチェーントランザクションを識別するステップを備える。これらのブロックチェーントランザクションは、それぞれの以前のトランザクションに関連するダスト出力を使用するダスト入力を含む。

【0058】

方法はさらに、コンピューティングリソースまたは任意の資産レジストリに関連して、イベントストリームを初期化するステップと、資産譲渡イベントをコンピューティングリソースに関連するイベントストリームと同期するステップとを備える。任意で、資産譲渡イベントをコンピューティングリソースまたは資産レジストに関連するイベントストリームと同期することは、資産レジストリまたはコンピューティングリソースと関連するイベントストリームに、資産譲渡イベントに対応するメタデータの表現を付け加えることを含む。

【0059】

有利なことに、これは、資産レジストリがイベントストリームを使用して支払いを検証できることを意味し、すなわち、資産レジストリの関与はブロックチェーンの不変性によってサポートされることを意味する。すなわち、例えば銀行などのアカウントの提供者は、資産譲渡を記録するために追加されたイベントストリームも有するため、資産譲渡が行われたことを検証できる。追加的または代替的に、コンピューティングリソースに関連するイベントストリームはまた、コンピューティングリソースに関与するトランザクションを記録するために初期化され得る。

【0060】

イベントストリームの初期化は、コンピューティングリソースおよび特定のイベントストリームを実施するのに必要なデータ構造のセットアップおよび設定を意味する。

【0061】

任意で、コンピューティングリソースは、メタデータのさらなるセットに暗号署名を適用する。暗号署名は、公開鍵基盤(PKI)技術を使用して生成される。暗号署名は、データストアから、または送信者または受信者のいずれかによって動作されるデバイスから取得される。任意で、コンピューティングリソースは、送信者および受信者に対応する暗号署名を取得し、それぞれの暗号署名をメタデータに適用する。それぞれの暗号署名は、例えば、送信者および受信者に関連するコンピューティングデバイスから取得され得る。

【0062】

これについての有益な効果は、コンピューティングリソースが、メタデータのさらなるセットが暗号署名され得るように、メタデータのさらなるセットに署名を適用できることである。

【0063】

第2の態様では、第1のユーザから第2のユーザへの資産の譲渡のコンピュータ実装方法が提供される。アカウントは、例えば銀行など資産レジストリによって提供され得る。方法は、譲渡された資産の送信者に関連する第1のコンピューティングリソースによって実施される。コンピューティングリソースは、ハードウェアまたはソフトウェアによって実装される場合がある。コンピューティングリソースは、局所的にかまたは広い地理的エリアにかのどちらかに分散される場合がある複数の処理リソースを含んでよい。方法は、第1の態様の方法を実施するように構成された第2のコンピューティングリソースから資産の譲渡の要求を受信するステップを備える。方法は、メタデータの第1のセットを生成するステップを備え、メタデータの第1のセットが、
(i)譲渡に使用されるアカウント、
(ii)アカウントから取り出される資産の量、および
(iii)譲渡に使用される資産のインジケータを示す。

【0064】

方法はさらに、メタデータの第1のセットを第2のコンピューティングリソースに送信して、譲渡を初期化するステップを備える。方法はさらに、第2のコンピューティングリソースからの要求された譲渡に関連する指示データを受信するステップを備える。方法はさらに、暗号署名を使用して指示データに署名をして、署名済み指示データを生成するステップを備える。方法はさらに、署名済みの指示データを第2のコンピューティングリソースに送信するステップを備える。

【0065】

第2の態様に関連する方法は、コンピューティングデバイスが、ユーザによる資産の譲渡を実行できるようにし、第1の態様によって提供されたアプローチの不変性、信頼性、安全性からの利点を得る。

【0066】

第3の態様に関連する方法は、第1の態様に従って記録された資産譲渡イベントを検証するコンピュータ実装方法である。方法は、定義されたハードウェアまたはソフトウェアである第1のコンピューティングリソースによって実施される。方法は、コンピューティングリソースから資産譲渡イベントに関連する識別子を含む資産譲渡イベントを検証する要求を受信するステップを備える。方法はさらに、識別子に関連するイベントストリームエントリを探索して、資産譲渡イベントに関連するメタデータを抽出するステップを備える。方法はさらに、資産譲渡イベントの確認をコンピューティングリソースに送信するステップを備える。

【0067】

第3の態様に従う方法は、探索の基礎として使用されるイベントに関連する識別子を送信すること、および、識別子に関連するイベントが見つかったときに発生を検証することによって資産譲渡イベントの発生を検証できるようにする。

【0068】

特定の実施形態が、同様の参照番号が同様の特徴を指す添付の図面を参照して例示として以降で説明される。

【0069】

システムの概要
以降で、図1aを参照して、システム100の第1のユーザと第2のユーザとの間の資産の譲渡が記録されることを可能にするシステム100を説明する。

【0070】

システム100は、第1のコンピューティングデバイス102および第2のコンピューティングデバイス104を含む。第1のコンピューティングデバイス102および第2のコンピューティングデバイス104は、任意のコンピューティングリソースであってよい。第1のコンピューティングデバイス102および第2のコンピューティングデバイス104の各々は、それぞれの第1のおよび第2のアプリケーションプログラミングインターフェース(API)108を介して支払い処理リソース106とインタラクションするように構成される。

【0071】

支払い処理リソース106は、イベントストリームリソース110を用いて、Aliceという名前の第1のユーザ(110a)、Bobという名前の第2のユーザ(110b)、および支払い処理リソース(110c)の少なくとも各々に関して提供されるイベントストリームを初期化するおよび/またはそれらのイベントストリームとインタラクションするように構成される。支払い処理リソース106によるイベントストリームの初期化およびイベントストリームとのインタラクションは、nChain Holdings Limitedの名義で2021年2月18日に出願された英国特許出願第2102314.8号から理解されるであろう。

【0072】

支払い処理リソース106は、ブロックチェーン112とインタラクションするようにさらに構成される。ブロックチェーン112は、それがトランザクションから構成されるブロック(BSV1、BSV2、BSV3)の追加専用台帳であるという点で、ビットコイン・サトシ・ビジョン(BSV: Bitcoin Satoshi Vision)プロトコルに従う少なくとも1つのパブリックプルーフオブワークブロックチェーンを含んでよい。

【0073】

ブロックチェーン112は、以降で図1bに関連して説明されるソフトウェアによって構成される複数のノード126を含む。各ノードは、図1cに関連して下で説明されるように、このソフトウェアによって、ブロックチェーンの一部として構成される。

【0074】

図1bは、UTXOまたは出力ベースのモデルの例において、ネットワーク132の各ブロックチェーンノード126上で実行されるノードソフトウェア450の例を示す。別のエンティティが、ネットワーク132上でノード126として分類されることなく、すなわち、ノード126の必要とされるアクションを実行することなく、ノードソフトウェア450を実行する場合があることに留意されたい。ノードソフトウェア450は、プロトコルエンジン451、スクリプトエンジン452、スタック453、アプリケーションレベル決定エンジン454、および1つまたは複数のブロックチェーン関連機能モジュール455のセットを含んでよいがこれらに限定されない。各ノード126は、コンセンサスモジュール455C(たとえば、プルーフオブワーク)、伝播モジュール455P、およびストレージモジュール455S(たとえば、データベース)の3つすべてを含むがこれらに限定されないノードソフトウェアを実行してよい。プロトコルエンジン451は、典型的には、トランザクション152の異なるフィールドを認識し、ノードプロトコルにしたがってそれらのフィールドを処理するように構成される。別の先行トランザクション152i(Tx_m-1)の出力(たとえば、UTXO)を指し示す入力を有するトランザクション152j(Tx_j)が受信されるとき、プロトコルエンジン451は、Tx_jのロック解除スクリプトを特定し、そのロック解除スクリプトをスクリプトエンジン452に渡す。また、プロトコルエンジン451は、Tx_jの入力のポインタに基づいてTx_iを特定し、取り出す。Tx_iは、ブロックチェーン150上で公開されている場合があり、その場合、プロトコルエンジンは、ノード126に記憶されたブロックチェーン150のブロック151のコピーからTx_iを取り出してよい。代替的に、Tx_iは、ブロックチェーン150上でまだ公開されていない場合がある。その場合、プロトコルエンジン451は、ノード126によって維持される未公開トランザクションの順序付けられたセット154からTx_iを取り出してよい。いずれにせよ、プロトコルエンジン451は、Tx_iの参照された出力のロックスクリプトを特定し、これをスクリプトエンジン452に渡す。

【0075】

したがって、スクリプトエンジン452は、Tx_iのロックスクリプトと、Tx_jの対応する入力からロック解除スクリプトとを有する。たとえば、Tx₀およびTx₁とラベル付けされたトランザクションが図2に示されるが、同じことがトランザクションのどのペアにも当てはまる可能性がある。スクリプトエンジン452は、既に検討されたように2つのスクリプトを一緒に実行し、これは、用いられているスタックベースのスクリプト言語(たとえば、Script)に従って、スタック453にデータを入れることと、スタック453からデータを取り出すこととを含む。

【0076】

スクリプトを一緒に実行することによって、スクリプトエンジン452は、ロック解除スクリプトがロックスクリプトにおいて定義された1つまたは複数の基準を満たすか否か -- すなわち、ロック解除スクリプトがロックスクリプトが含まれる出力を「ロック解除する」かどうか -- を判定する。スクリプトエンジン452は、この判定の結果をプロトコルエンジン451に返す。スクリプトエンジン452は、ロック解除スクリプトが対応するロックスクリプトにおいて指定された1つまたは複数の基準を満たすと判定する場合、結果「真」を返す。それ以外の場合、スクリプトエンジン452は、「偽」を返す。

【0077】

出力ベースのモデルにおいて、スクリプトエンジン452からの結果「真」は、トランザクションの有効性の条件のうちの1つである。概して、Tx_jにおいて指定されたデジタル資産の総量がその入力によって指し示された総量を超えないこと、およびTx_iの指し示された出力が別の有効なトランザクションによって既に消費されていないことなどの、同様に満たされなければならない、プロトコルエンジン451によって評価される1つまたは複数のさらなるプロトコルレベルの条件も存在する。プロトコルエンジン451は、スクリプトエンジン452からの結果を1つまたは複数のプロトコルレベルの条件と一緒に評価し、それらがすべて真である場合にのみ、トランザクションTx_jを有効化する。プロトコルエンジン451は、トランザクションが有効であるかどうかのインジケーションをアプリケーションレベル決定エンジン454に出力する。Tx_jが確かに有効化されるという条件でのみ、決定エンジン454は、コンセンサスモジュール455Cと伝播モジュール455Pとの両方を制御して、Tx_jに関してそれらのそれぞれのブロックチェーン関連機能を実行することを選択してよい。これは、コンセンサスモジュール455Cが、ブロック151に組み込むためのトランザクションのノードのそれぞれの順序付けられたセット154にTx_jを追加することと、伝播モジュール455Pが、Tx_jをネットワーク106の別のブロックチェーンノード126に転送することとを含む。任意で、実施形態において、アプリケーションレベル決定エンジン454は、これらの機能のどちらかまたは両方をトリガする前に、1つまたは複数の追加の条件を適用する場合がある。たとえば、決定エンジンは、トランザクションが有効であり、かつ十分な取引手数料を残すという条件でのみ、トランザクションを公開することを選択する場合がある。

【0078】

本明細書における用語「真」および「偽」は必ずしも2進数1桁(ビット)のみの形態で表された結果を返すことに限定されないが、それは確かに1つの可能な実装であることに留意されたい。より広く、「真」は、成功したまたは肯定的な結果を示す任意の状態を指すことが可能であり、「偽」は、失敗したまたは非肯定的な結果を示す任意の状態を指すことが可能である。たとえば、アカウントベースのモデルにおいて、「真」の結果は、署名の暗黙的なプロトコルレベルの有効化とスマートコントラクトの追加の肯定的な出力との組合せによって示される可能性がある(個々の結果が両方とも真である場合に、全体の結果が真を知らせるとみなされる)。

【0079】

開示された技術のその他の変形またはユースケースは、本明細書の開示が与えられれば、当業者に明らかになるであろう。本開示の範囲は、記載された実施形態によって限定されず、添付の請求項によってのみ限定される。

【0080】

たとえば、上記のいくつかの実施形態は、ビットコインネットワーク106、ビットコインブロックチェーン150、およびビットコインノード126の観点で説明された。しかし、ビットコインブロックチェーンは、ブロックチェーン150の1つの特定の例であり、上の説明は、任意のブロックチェーンに広く当てはまる可能性があることが理解されるであろう。すなわち、本発明は、ビットコインブロックチェーンに決して限定されない。より広く、ビットコインネットワーク106、ビットコインブロックチェーン150、およびビットコインノード126への上記のすべての言及は、それぞれ、ブロックチェーンネットワーク106、ブロックチェーン150、およびブロックチェーンノード126への言及に置き換えられてよい。ブロックチェーン、ブロックチェーンネットワーク、および/またはブロックチェーンノードは、上述のビットコインブロックチェーン150、ビットコインネットワーク106、およびビットコインノード126の説明された特性の一部またはすべてを共有する場合がある。

【0081】

本発明の好ましい実施形態において、ブロックチェーンネットワーク132は、ビットコインネットワークであり、ビットコインノード126が、ブロックチェーン150のブロック151を作成し、公開し、伝播し、記憶する説明された機能の少なくともすべてを実行する。これらの機能のうちの1つまたは一部だけを実行するが、すべては実行しないその他のネットワークエンティティ(またはネットワーク要素)が存在する可能性があることは、排除されない。すなわち、ネットワークエンティティが、ブロックを作成および公開することなく、ブロックを伝播および/または記憶する機能を実行する場合がある(これらのエンティティは、好ましいビットコインネットワーク132のノードとはみなされないことを思い出されたい)。

【0082】

本発明の好ましくない実施形態において、ブロックチェーンネットワーク132は、ビットコインネットワークではない場合がある。これらの実施形態においては、ノードが、ブロックチェーン150のブロック151を作成し、公開し、伝播し、記憶する機能の少なくとも1つまたは一部を実行するが、すべては実行しない場合があることは排除されない。たとえば、それらのその他のブロックチェーンネットワーク上で、「ノード」は、ブロック151を作成および公開するように構成されるが、それらのブロック151を記憶および/またはその他のノードに伝播するように構成されないネットワークエンティティを指すために用いられる場合がある。

【0083】

さらに一層広く、上記の用語「ビットコインノード」126へのあらゆる言及は、用語「ネットワークエンティティ」または「ネットワーク要素」に置き換えられてよく、そのようなエンティティ/要素は、ブロックを作成し、公開し、伝播し、記憶する役割の一部またはすべてを実行するように構成される。そのようなネットワークエンティティ/要素の機能は、ブロックチェーンノード126に関連して上で説明された同じ方法でハードウェアに実装されてよい。

【0084】

さらに一層広く、上記の用語「ビットコインノード」126へのあらゆる言及は、用語「ネットワークエンティティ」または「ネットワーク要素」に置き換えられてよく、そのようなエンティティ/要素は、ブロックを作成し、公開し、伝播し、記憶する役割の一部またはすべてを実行するように構成される。そのようなネットワークエンティティ/要素の機能は、ブロックチェーンノード126に関連して上で説明された同じ方法でハードウェアに実装されてよい。

【0085】

図1cは、ブロックチェーン150を実装するための例示的なシステム100を示す。システム100は、パケット交換ネットワーク130、典型的には、インターネットなどの広域インターネットワークで構成されてよい。パケット交換ネットワーク130は、パケット交換ネットワーク130内でピアツーピア(P2P)ネットワーク132を形成するように配置される場合がある複数のブロックチェーンノード126を含む。図示されていないが、ブロックチェーンノード126は、ほぼ完全なグラフ(near-complete graph)として配置される場合がある。したがって、各ブロックチェーンノード126は、その他のブロックチェーンノード126と緊密に接続される。

【0086】

各ブロックチェーンノード126は、ピアのコンピュータ機器を含み、ノード126のうちの異なるノードは、異なるピアに属する。各ブロックチェーンノード126は、1つまたは複数のプロセッサ、たとえば、1つまたは複数の中央演算処理装置(CPU)、アクセラレータプロセッサ、特定用途向けプロセッサおよび/またはフィールドプログラマブルゲートアレイ(FPGA)、ならびに特定用途向け集積回路(ASIC)などのその他の機器を含む処理装置を含む。各ノードは、メモリ、すなわち、1つの非一時的コンピュータ可読媒体または複数の非一時的コンピュータ可読媒体の形態のコンピュータ可読ストレージも含む。メモリは、1つまたは複数のメモリ媒体、たとえば、ハードディスクなどの磁気媒体、ソリッドステートドライブ(SSD)、フラッシュメモリ、もしくはEEPROMなどの電子媒体、および/または光ディスクドライブなどの光媒体を採用する1つまたは複数のメモリユニットを含んでよい。

【0087】

ブロックチェーン150は、データのブロック151のチェーンを含み、ブロックチェーン150のそれぞれのコピーが、分散型またはブロックチェーンネットワーク130の複数のブロックチェーンノード126の各々において維持される。上述のように、ブロックチェーン150のコピーを維持することは、必ずしもブロックチェーン150をすべて記憶することを意味しない。そうではなく、各ブロックチェーンノード150が各ブロック151のブロックヘッダ(下で検討される)を記憶する限り、ブロックチェーン150は、データを刈り込まれる場合がある。チェーンの各ブロック151は、1つまたは複数のトランザクション152を含み、この文脈におけるトランザクションは、データ構造の一種を指す。データ構造の性質は、トランザクションモデルまたは方式の一部として用いられるトランザクションプロトコルの種類に依存する。所与のブロックチェーンは、全体を通じて1つの特定のトランザクションプロトコルを用いる。1つのよくある種類のトランザクションプロトコルにおいて、各トランザクション152のデータ構造は、少なくとも1つの入力および少なくとも1つの出力を含む。各出力は、財産としてのデジタル資産の量を表す額を指定し、その例は、出力が暗号的にロックされるユーザ103である(ロックを解除され、それによって、履行または消費されるためにはそのユーザの署名またはその他の解決策を必要とする)。各入力は、先行トランザクション152の出力を後ろ向きに指し示し、それによって、トランザクションをリンクする。

【0088】

各ブロック151は、ブロック151までの発生順を定義するように、チェーン内の前に作成されたブロック151を後ろ向きに指し示すブロックポインタ155も含む。(コインベーストランザクション(coinbase transaction)以外の)各トランザクション152は、トランザクションのシーケンスに順序を定義するように、前のトランザクションに戻るポインタを含む(トランザクション152のシーケンスは分岐することを許されることに注意されたい)。ブロック151のチェーンは、チェーンの最初のブロックであったジェネシスブロック(Gb)153までさかのぼる。チェーン150の初期の1つまたは複数の当初のトランザクション152は、先行トランザクションではなくジェネシスブロック153を指し示していた。

【0089】

ブロックチェーンノード126の各々は、トランザクション152をその他のブロックチェーンノード126に転送し、それによって、トランザクション152をネットワーク132全体に伝播させるように構成される。各ブロックチェーンノード126は、ブロック151を作成し、同じブロックチェーン150のそれぞれのコピーをそれらのブロックチェーンノード126のそれぞれのメモリに記憶するように構成される。また、各ブロックチェーンノード126は、ブロック151に組み込まれるのを待っているトランザクション152の順序付けられたセット154を維持する。順序付けられたセット154は、多くの場合「メムプール(mempool)」と呼ばれる。本明細書におけるこの用語は、いかなる特定のブロックチェーン、プロトコル、またはモデルにも限定するように意図されていない。この用語は、ノード126が有効であるものとして受け入れ、ノード126が同じ出力を消費しようとするいかなるその他のトランザクションも受け入れないことを義務付けられるトランザクションの順序付けられたセットを指す。

【0090】

所与の現在のトランザクション152jにおいて、その(または各)入力は、トランザクションのシーケンス内の先行トランザクション152iの出力を参照するポインタを含み、この出力が現在のトランザクション152jにおいて履行されるまたは「消費される」ことを指定する。概して、先行トランザクションは、順序付けられたセット154または任意のブロック151内の任意のトランザクションである可能性がある。先行トランザクション152iは、現在のトランザクション152jが作成される時点、またはネットワーク132に送信される時点でさえも必ずしも存在する必要はないが、現在のトランザクションが有効であるためには、先行トランザクション152iが存在し、有効化される必要がある。したがって、本明細書における「先行」は、ポインタによってリンクされた論理的なシーケンスにおける先任者(predecessor)を指し、必ずしも時間的なシーケンスにおける作成または送信の時間を指すものではなく、したがって、トランザクション152i、152jが順不同で作成または送信されることを必ずしも除外しない(孤児(orphan)トランザクションに関する下の検討を参照されたい)。先行トランザクション152iは、同様に先祖(antecedent)または先任者トランザクションと呼ばれる可能性がある。

【0091】

現在のトランザクション152jの入力は、入力の認可、たとえば、先行トランザクション152iの出力がロックされているユーザ103aの署名も含む。そして今度は、現在のトランザクション152jの出力が、新しいユーザまたはエンティティ103bに暗号的にロックされ得る。したがって、現在のトランザクション152jは、先行トランザクション152iの入力において定義された額を、現在のトランザクション152jの出力において定義されたように新しいユーザまたはエンティティ103bに送金することができる。場合によっては、トランザクション152は、複数のユーザまたはエンティティ(そのうちの1つは、お釣りを渡すために元のユーザまたはエンティティ103aである可能性がある)の間で入力額を分けるために複数の出力を有する場合がある。場合によっては、トランザクションは、1つまたは複数の先行トランザクションの複数の出力からの金額を集め、現在のトランザクションの1つまたは複数の出力に再分配するために複数の入力を有することも可能である。

【0092】

ビットコインのような出力ベースのトランザクションプロトコルによれば、ユーザまたは機械などのエンティティ103が新しいトランザクション152jを定めたいとき、エンティティは、そのコンピュータ端末から受取人に新しいトランザクションを送信する。エンティティまたは受取人は、最終的に、このトランザクションを(現在では概してサーバまたはデータセンターであるが、原理的にはその他のユーザ端末である可能性がある)ネットワーク132のブロックチェーンノード126のうちの1つまたは複数に送信する。また、新しいトランザクション152jを定めるエンティティ103が、トランザクションをブロックチェーンノード126のうちの1つまたは複数に送信し、一部の例においては、受取人に送信しない可能性があることも除外されない。トランザクションを受信するブロックチェーンノード126は、ブロックチェーンノード126の各々において適用されるブロックチェーンノードプロトコルに従って、トランザクションが有効であるかどうかをチェックする。ブロックチェーンノードプロトコルは、概して、新しいトランザクション152jの暗号署名が、トランザクション152の順序付けられたシーケンス内の前のトランザクション152iに依存する期待される署名と一致することをブロックチェーンノード126がチェックすることを要求する。そのような出力ベースのトランザクションプロトコルにおいて、これは、新しいトランザクション152jの入力に含まれるエンティティ103の暗号署名またはその他の認可が、新しいトランザクションが割り振る先行トランザクション152iの出力において定義された条件と一致することをチェックすることを含む場合があり、この条件は、概して、少なくとも、新しいトランザクション152jの入力の暗号署名またはその他の認可が、新しいトランザクションの入力がリンクされる前のトランザクション152iの出力のロックを解除することをチェックすることを含む。条件は、先行トランザクション152iの出力に含まれるスクリプトによって少なくとも部分的に定義されてよい。代替的に、条件は、単にブロックチェーンノードプロトコルのみによって決められている可能性があり、またはこれらの組合せに起因する可能性がある。いずれにせよ、新しいトランザクション152jが有効である場合、ブロックチェーンノード126は、それをブロックチェーンネットワーク132の1つまたは複数のその他のブロックチェーンノード126に転送する。これらのその他のブロックチェーンノード126は、同じブロックチェーンノードプロトコルに従って同じテストを適用し、したがって、新しいトランザクション152jを1つまたは複数のさらなるノード126に転送し、以下同様である。このようにして、新しいトランザクションは、ブロックチェーンノード126のネットワーク全体に伝播される。

【0093】

出力ベースのモデルにおいて、所与の出力(たとえば、UTXO)が割り振られるかどうかの定義は、その出力がブロックチェーンノードプロトコルに従って別のオンワードトランザクション(onward transaction)152jの入力によって既に有効に履行されたかどうかということである。トランザクションが有効であるための別の条件は、それが割り振ろうとまたは履行しようと試みる先行トランザクション152iの出力が別のトランザクションによって既に割り振られて/履行されていないことである。やはり、有効でない場合、トランザクション152jは(警告のために無効であるものとしてフラグを立てられ、伝播されるのでない限り)伝播されず、ブロックチェーン150に記録されない。これは、トランザクションを行う者が同じトランザクションの出力を2回以上割り振ろうとする二重支払いを防ぐ。一方、アカウントベースのモデルは、アカウントの残高を維持することによって二重支払いを防止する。やはり、トランザクションの定義された順序が存在するので、アカウントの残高は、常に単一の定義された状態を有する。

【0094】

トランザクションを有効化することに加えて、ブロックチェーンノード126は、「プルーフオブワーク」によってサポートされる、通常、マイニングと呼ばれるプロセスでトランザクションのブロックを最初に作成するノードになろうとさらに競争する。ブロックチェーンノード126において、新しいトランザクションは、ブロックチェーン150に記録されたブロック151にまだ現れていない有効なトランザクションの順序付けられたセット154に追加される。それから、ブロックチェーンノードは、暗号パズルを解くことを試みることによって、トランザクションの順序付けられたセット154からトランザクション152の新しい有効なブロック151を組み立てようと競争する。概して、これは、ナンスがトランザクションの順序付けられたセット154の表現と連結され、ハッシュされるときに、ハッシュの出力が所定の条件を満たすような「ナンス」値を探索することを含む。たとえば、所定の条件は、ハッシュの出力が特定の予め定義された数の先頭のゼロを有することである場合がある。これは、プルーフオブワークのパズルの単なる1つの特定の種類であり、その他のパズルは除外されないことに留意されたい。ハッシュ関数の特性は、ハッシュ関数がその入力に対して予測不可能な出力を有することである。したがって、この探索は、総当たりによってのみ実行されることが可能であり、したがって、パズルを解こうとしている各ブロックチェーンノード126において相当大量の処理リソースを消費する。

【0095】

パズルを解いた最初のブロックチェーンノード126は、これをネットワーク132に告知し、ネットワークのその他のブロックチェーンノード126によってその後容易にチェックされ得る証明として解を提供する(ハッシュの解が与えられると、それがハッシュの出力に条件を満足させることをチェックすることは簡単である)。最初のブロックチェーンノード126は、ブロックを受け入れ、したがって、プロトコルの規則を施行するその他のノードの閾値のコンセンサスまでブロックを伝播する。そして、トランザクションの順序付けられたセット154は、ブロックチェーンノード126の各々によってブロックチェーン150に新しいブロック151として記録されるようになる。また、チェーン内の前に作成されたブロック151n-1を後ろ向きに指し示すブロックポインタ155が、新しいブロック151nに割り振られる。プルーフオブワークの解を作成するために必要とされる、たとえば、ハッシュの形態の著しい量の労力は、ブロックチェーンプロトコルの規則に従うという最初のノード126の意図を知らせる。そのような規則は、二重支払いとしても知られている、トランザクションが前に有効化されたトランザクションと同じ出力を割り振る場合、トランザクションを有効であるものとして受け入れないことを含む。作成されると、ブロック151は、ブロックチェーンネットワーク132のブロックチェーンノード126の各々において認識され、維持されるので、修正され得ない。また、ブロックポインタ155は、ブロック151に発生順を付与する。トランザクション152がネットワーク132の各ブロックチェーンノード126の順序付けられたブロックに記録されるので、これは、したがって、トランザクションの不変の公開台帳を提供する。

【0096】

任意の所与の時間にパズルを解こうと競争している異なるブロックチェーンノード126は、それらのブロックチェーンノード126がいつ解を探索し始めたか、またはトランザクションが受信された順序に応じて、任意の所与の時間にまだ公開されていないトランザクションの順序付けられたセット154の異なるスナップショットに基づいてそうしている場合があることに留意されたい。最初にそれらのそれぞれのパズルを解いた者は誰でも、どのトランザクション152が次の新しいブロック151nにどの順序で含まれるかを定義し、未公開トランザクションの現在のセット154が、更新される。それから、ブロックチェーンノード126は、未公開トランザクションの新たに定義された未処理の順序付けられたセット154からブロックを作成しようと競争を続け、以下同様である。発生する可能性があるすべての「フォーク(fork)」を解決するためのプロトコルも存在し、フォークは、ブロックチェーンの相反するビュー(view)がノード126の間で伝播されるように、2つのブロックチェーンノード126が互いに非常に短い時間内にそれらのブロックチェーンノード126のパズルを解く地点である。手短に言えば、どちらでも最も長くなる方のフォークの爪が、最終的なブロックチェーン150となる。これは、同じトランザクションが両方のフォークに現れるので、ネットワークのユーザまたはエージェントに影響を与えないはずであることに留意されたい。

【0097】

ビットコインブロックチェーン(およびほとんどのその他のブロックチェーン)によれば、新しいブロック126を成功裏に構築するノードは、(ある額のデジタル資産をあるエージェントまたはユーザから別のエージェントまたはユーザに送金するエージェント間またはユーザ間トランザクションとは対照的に)定義された量のデジタル資産を分配する新しい特別な種類のトランザクションにおいて認められた額のデジタル資産を割り振る能力を付与される。この特別な種類のトランザクションは、通常「コインベーストランザクション」と呼ばれるが、「イニシエーション(initiation)トランザクション」と呼ばれる場合もある。この特別な種類のトランザクションは、概して、新しいブロック151nの最初のトランザクションを形成する。プルーフオブワークは、この特別なトランザクションが後で履行されることを可能にするプロトコルの規則に従うという、新しいブロックを構築するノードの意図を知らせる。ブロックチェーンプロトコルの規則は、この特別なトランザクションが履行されてよい前に、満期期間(maturity period)、たとえば、100ブロックを必要とする場合がある。多くの場合、通常の(非生成(non-generation))トランザクション152は、トランザクションが公開されたブロック151nを作成したブロックチェーンノード126にさらに報酬を与えるために、その出力の1つにおいて追加の取引手数料も指定する。この手数料は、通常「取引手数料」と呼ばれ、下で検討される。

【0098】

トランザクションの有効化および公開に関わるリソースが原因で、概して、少なくとも、ブロックチェーンノード126の各々は、1つもしくは複数の物理サーバユニットを含むサーバ、またはさらにはデータセンター全体の形態をとる。しかし、原理的には、任意の所与のブロックチェーンノード126は、ユーザ端末、または一緒にネットワーク化されたユーザ端末のグループの形態をとる可能性がある。

【0099】

各ブロックチェーンノード126のメモリは、ブロックチェーンノードプロトコルに従ってそのそれぞれの1つの役割または複数の役割を実行し、トランザクション152を処理するために、ブロックチェーンノード126の処理装置上で実行されるように構成されたソフトウェアを記憶する。本明細書においてブロックチェーンノード126に帰せられるすべてのアクションは、それぞれのコンピュータ機器の処理装置上で実行されるソフトウェアによって実行されてよいことが理解されるであろう。ノードソフトウェアは、アプリケーションレイヤの1つもしくは複数のアプリケーションに、またはオペレーティングシステムレイヤもしくはプロトコルレイヤなどのより下位のレイヤに、またはこれらの任意の組合せで実装されてよい。

【0100】

ネットワーク130にさらに接続されるのは、消費ユーザの役割の複数の関係者103の各々のコンピュータ機器である。これらのユーザは、ブロックチェーンネットワークとインタラクションする場合があるが、トランザクションおよびブロックの有効化、構築、または伝播には参加しない。これらのユーザまたはエージェント103の一部は、トランザクションにおいて送信者および受信者として働く場合がある。その他のユーザは、必ずしも送信者または受信者として働くことなく、ブロックチェーン150とインタラクションしてよい。たとえば、一部の関係者は、(たとえば、ブロックチェーンノード126からブロックチェーンのコピーを取得した)ブロックチェーン150のコピーを記憶するストレージエンティティとして働く場合がある。

【0101】

関係者103の一部またはすべては、異なるネットワーク、たとえば、ブロックチェーンネットワーク132の上に重ねられたネットワークの一部として接続される場合がある。ブロックチェーンネットワークのユーザ(多くの場合「クライアント」と呼ばれる)は、ブロックチェーンネットワークを含むシステムの一部であると言われる場合があるが、これらのユーザは、ブロックチェーンノードの必要とされる役割を果たさないので、ブロックチェーンノード126ではない。その代わりに、各関係者103は、ブロックチェーンネットワーク132とインタラクションし、それによって、ブロックチェーンノード132に接続すること(すなわち、通信すること)によりブロックチェーン150を利用してよい。例示を目的として、2人の関係者103およびそれらのそれぞれの機器、すなわち、第1の関係者103aおよびそのそれぞれのコンピュータ機器102a、ならびに第2の関係者103bおよびそのそれぞれのコンピュータ機器102bが示される。第1のコンピューティングデバイス102および第2のコンピューティングデバイス104は、それぞれのコンピュータ機器102aまたは102bの機能のいずれかを実装するように構成されてよい。多くのさらなるそのような関係者103およびそれらのそれぞれのコンピュータ機器が存在し、システム100に参加していてよいが、便宜上、それらは図示されていないことは理解されるであろう。各関係者103は、個人または組織である場合がある。純粋に例示のために、第1の関係者103aは、本明細書においてはAliceと呼ばれ、第2の関係者103bは、Bobと呼ばれるが、これは限定的でなく、AliceまたはBobに対する本明細書のすべての言及は、それぞれ「第1の関係者」および「第2の関係者」によって置き換えられてよいことが理解されるであろう。

【0102】

各関係者103のコンピュータ機器は、1つまたは複数のプロセッサ、たとえば、1つまたは複数のCPU、GPU、その他のアクセラレータプロセッサ、特定用途向けプロセッサ、および/またはFPGAを含むそれぞれの処理装置を含む。各関係者103のコンピュータ機器は、メモリ、すなわち、1つの非一時的コンピュータ可読媒体または複数の非一時的コンピュータ可読媒体の形態のコンピュータ可読ストレージをさらに含む。このメモリは、1つまたは複数のメモリ媒体、たとえば、ハードディスクなどの磁気媒体、SSD、フラッシュメモリ、もしくはEEPROMなどの電子媒体、および/または光ディスクドライブなどの光媒体を採用する1つまたは複数のメモリユニットを含んでよい。各関係者103のコンピュータ機器のメモリは、処理装置上で実行されるように配置された少なくとも1つのクライアントアプリケーション105のそれぞれのインスタンスを含むソフトウェアを記憶する。本明細書において所与の関係者103に帰せられるすべてのアクションは、それぞれのコンピュータ機器の処理装置上で実行されるソフトウェアを用いて実行されてよいことが理解されるであろう。各関係者103のコンピュータ機器は、少なくとも1つのユーザ端末、たとえば、デスクトップもしくはラップトップコンピュータ、タブレット、スマートフォン、またはスマートウォッチなどのウェアラブルデバイスを含む。所与の関係者103のコンピュータ機器は、ユーザ端末を介してアクセスされるクラウドコンピューティングリソースなどの1つまたは複数のその他のネットワーク化されたリソースも含む場合がある。

【0103】

クライアントアプリケーション105は、最初に、1つの好適なコンピュータ可読ストレージ媒体または複数の好適なコンピュータ可読ストレージ媒体上で任意の所与の関係者103のコンピュータ機器に提供され、たとえば、サーバからダウンロードされるか、あるいはリムーバブルSSD、フラッシュメモリキー、リムーバブルEEPROM、リムーバブル磁気ディスクドライブ、磁気フロッピーディスクもしくはテープ、CDもしくはDVD ROMなどの光ディスク、またはリムーバブル光学ドライブなどのリムーバブルストレージデバイス上で提供される場合がある。クライアントアプリケーション105は、図1cに示されたデバイス102aおよび102b上の105aおよび105bにそれぞれ対応する。

【0104】

クライアントアプリケーション105は、少なくとも「ウォレット」機能を含む。これは、2つの主な機能を有する。これらのうちの一方は、それぞれの関係者103が、トランザクション152を作成し、認可し(たとえば、署名し)、その後ブロックチェーンノード126のネットワーク全体に伝播され、それによって、ブロックチェーン150に含められるように1つまたは複数のビットコインノード126に送信することを可能にすることである。他方は、それぞれの関係者が現在所有しているデジタル資産の額の報告をその関係者に返すことである。出力ベースのシステムにおいて、この第2の機能は、問題にしている関係者に属する、ブロックチェーン150全体に散在する様々なトランザクション152の出力に定義された額を照合することを含む。

【0105】

注:様々なクライアント機能が所与のクライアントアプリケーション105に統合されているものとして説明される場合があるが、これは、必ずしも限定的ではなく、むしろ、本明細書において説明される任意のクライアント機能は、その代わりに、たとえば、APIによってインターフェースをとる、または1つがそれ以外に対するプラグインである、2つ以上の異なるアプリケーションのスイートに実装されてよい。より広く、クライアント機能は、アプリケーションレイヤ、またはオペレーティングシステムなどのより下位のレイヤ、またはこれらの任意の組合せに実装される可能性がある。以下は、クライアントアプリケーション105の観点で説明されるが、これが限定的でないことは、理解されるであろう。

【0106】

各コンピュータ機器上のクライアントアプリケーションまたはソフトウェア105のインスタンスは、ネットワーク132のブロックチェーンノード126のうちの少なくとも1つに動作可能なように結合される。これは、クライアント105のウォレット機能がネットワーク132にトランザクション152を送信することを可能にする。また、クライアント105は、それぞれの関係者103が受信者である任意のトランザクションに関してブロックチェーン150に問い合わせる(または実施形態において、ブロックチェーン150は、その公開された可視性(public visibility)によって部分的にトランザクションに対する信頼を提供する公共機関(public facility)であるので、ブロックチェーン150内のその他の関係者のトランザクションを確かに検査する)ためにブロックチェーンノード126に連絡することができる。各コンピュータ機器のウォレット機能は、トランザクションプロトコルに従ってトランザクション152を組み立て、送信するように構成される。上述のように、各ブロックチェーンノード126は、ブロックチェーンノードプロトコルに従ってトランザクション152を有効化し、ブロックチェーンネットワーク132全体にトランザクション152を伝播させるためにトランザクション152を転送するように構成されたソフトウェアを実行する。トランザクションプロトコルおよびノードプロトコルは、互いに対応し、所与のトランザクションプロトコルが、所与のノードプロトコルと一緒になって、所与のトランザクションモデルを実装する。ブロックチェーン150のすべてのトランザクション152のために、同じトランザクションプロトコルが用いられる。ネットワーク132のすべてのノード126によって同じノードプロトコルが用いられる。

【0107】

所与の関係者103、たとえば、Aliceが、ブロックチェーン150に含められるように新しいトランザクション152jを送信したいとき、その関係者103は、(その関係者103のクライアントアプリケーション105のウォレット機能を用いて)関連するトランザクションプロトコルに従って新しいトランザクションを組み立てる。そして、その関係者103は、クライアントアプリケーション105から、自分が接続されている1つまたは複数のブロックチェーンノード126にトランザクション152を送信する。たとえば、これは、Aliceのコンピュータに最良に接続されているブロックチェーンノード126である可能性がある。任意の所与のブロックチェーンノード126は、新しいトランザクション152jを受信するとき、ブロックチェーンノードプロトコルおよびそのそれぞれの役割に従ってその新しいトランザクション152jを処理する。これは、新しく受信されたトランザクション152jが「有効」であるための特定の条件を満たすかどうかを最初にチェックすることを含み、その例は、まもなくより詳細に検討される。一部のトランザクションプロトコルにおいて、有効化のための条件は、トランザクション152に含まれるスクリプトによってトランザクションごとに構成可能である場合がある。代替的に、条件は、単にノードプロトコルの組み込まれた特徴であるか、またはスクリプトとノードプロトコルとの組合せによって定義される可能性がある。

【0108】

新しく受信されたトランザクション152jが有効とみなされるためのテストに合格することを条件に(すなわち、新しく受信されたトランザクション152jが「有効化される」ことを条件に)、トランザクション152jを受信するすべてのブロックチェーンノード126は、そのブロックチェーンノード126において維持されるトランザクション154の順序付けられたセットに、新しい有効化されたトランザクション152を追加する。さらに、トランザクション152jを受信するすべてのブロックチェーンノード126は、有効化されたトランザクション152をネットワーク132の1つまたは複数のその他のブロックチェーンノード126に向かって伝播させる。各ブロックチェーンノード126が同じプロトコルを適用するので、トランザクション152jが有効であると仮定すると、これは、トランザクション152jがネットワーク132全体にすぐに伝播されることを意味する。

【0109】

所与のブロックチェーンノード126において維持されるトランザクションの順序付けられたセット154に入れられると、そのブロックチェーンノード126は、新しいトランザクション152を含むトランザクションのそれらのそれぞれの順序付けられたセット154の最新バージョンに関するプルーフオブワークのパズルを解く競い合いを開始する(その他のブロックチェーンノード126はトランザクションの異なる順序付けられたセット154に基づくパズルを解こうとしている可能性があるが、誰であれ最初に成功する者が最新のブロック151に含まれるトランザクションの順序付けられたセットを定義することを思い出されたい。最終的に、ブロックチェーンノード126は、Aliceのトランザクション152jを含む順序付けられたセット154の一部に関するパズルを解く)。新しいトランザクション152jを含む順序付けられたセット154に関してプルーフオブワークが行われると、順序付けられたセット154は、不変的にブロックチェーン150のブロック151のうちの1つの一部となる。各トランザクション152は、それ以前のトランザクションに戻るポインタを含み、したがって、トランザクションの順序も不変的に記録される。

【0110】

異なるブロックチェーンノード126は、最初に、所与のトランザクションの異なるインスタンスを受信し、したがって、1つのインスタンスが新しいブロック151で公開される前は、どのインスタンスが「有効」であるかについての相反するビューを有する可能性があり、1つのインスタンスが新しいブロック151で公開された時点で、すべてのブロックチェーンノード126は、公開されたインスタンスが唯一の有効なインスタンスであると合意する。ブロックチェーンノード126が1つのインスタンスを有効であるものとして受け入れ、その後、第2のインスタンスがブロックチェーン150に記録されたことを発見する場合、そのブロックチェーンノード126は、これを受け入れなければならず、そのブロックチェーンノード126が最初に受け入れたインスタンス(すなわち、ブロック151で公開されなかったインスタンス)を破棄する(すなわち、無効であるものとして扱う)。

【0111】

一部のブロックチェーンネットワークによって運用される代替的な種類のトランザクションプロトコルは、アカウントベースのトランザクションモデルの一部として、「アカウントベース」のプロトコルと呼ばれる場合がある。アカウントベースの場合、各トランザクションは、過去のトランザクションのシーケンス内の先行トランザクションのUTXOを後ろ向きに参照することによって送金される額を定義するのではなく、絶対的なアカウントの残高を参照することによって送金される額を定義する。すべてのアカウントの現在の状態は、ブロックチェーンとは別のそのネットワークのノードによって記憶され、絶えず更新される。そのようなシステムにおいて、トランザクションは、アカウントの実行中の取引勘定(running transaction tally)(「ポジション」とも呼ばれる)を用いて順序付けられる。この値は、送信者によって送信者の暗号署名の一部として署名され、トランザクション参照計算(transaction reference calculation)の一部としてハッシュされる。さらに、任意のデータフィールドが、トランザクションに署名される場合もある。このデータフィールドは、たとえば、前のトランザクションIDがデータフィールドに含まれる場合、前のトランザクションを後ろ向きに指し示す場合がある。

【0112】

ブロックチェーン112に記録されるトランザクションは、使用されるかまたは使用されないかのどちらかであり、ロックスクリプトによって保護される価値の譲渡をモデル化する。トランザクションは、その入力によって価値を消費し、その出力によって価値を別の者に送る。トランザクションに入力される価値は、前のトランザクションによって出力された価値以上でなければならず、任意の余分な入力が、取引手数料として徴収される。ロックスクリプトに提示された解、すなわち、ロック解除スクリプトが間違っている場合、トランザクションが入力として取得されるよりも多い価値を出力する場合、トランザクションが既に消費された出力を消費する場合、またはトランザクションがまったく存在しない価値を消費しようとする場合、トランザクションは無効である。

【0113】

ロックスクリプトとロック解除スクリプトとの両方は、任意のデータを(使用不可能であることが証明可能な出力(provably unspendable output)の形態で)データキャリア出力(data carrier output)として埋め込むことができるスクリプトを含む、多種多様なスクリプト化された使用条件を可能にする機械可読スクリプト言語で表現される。

【0114】

図1aの支払い処理リソース106は、ブロックチェーン112とインタラクションするように構成される。支払い処理リソースは、ブロックチェーントランザクションを取り出し、ブロックチェーントランザクションからの既に使用されていない出力(UTXO)を消費するためのロック解除スクリプトを提供するように構成される。未使用トランザクションは、分散ハッシュテーブル(DHT)に記憶されてよい。支払い処理リソース106は、既に使用されていない出力を用いてブロックチェーントランザクションを生成し、それらのトランザクションへの入力として自身の資金を提供するように構成される。支払い処理リソース106は、トランザクションによって消費されている出力が既に消費された出力ではないこと、すなわち、トランザクションによって消費されている出力が未使用出力であり、二重支払いではないことを、出力の存在に関してDHTまたは一時的/二次メムプールをチェックすることによってチェックするように構成される。そして、支払い処理リソース106は、ブロックチェーントランザクションをブロックチェーン112に送信し、トランザクションが受信されたときにブロックチェーン112から通知を受信するようにさらに構成される。トランザクションがブロックチェーン112によって受信されたという通知を受信すると、支払い処理リソース106は、トランザクションの識別子を生成するように構成される。識別子は、英数字であってよい。支払い処理リソース106は、それが生成するブロックチェーントランザクションに使用不可能であることが証明可能な出力を追加し、それらの出力を用いて、支払い処理リソース106によって提供されるデータのハッシュを含むデータキャリアを付け加えるよう構成される。

【0115】

支払い処理リソース106によって識別子が生成されると、支払い処理リソース106は、(下でさらに説明されるように)データがイベントストリームに記録されることを要求するように構成される。

【0116】

支払い処理リソース106は、支払い処理リソース106のユーザによって用いられるアカウントに関連する情報を記憶するように構成される。支払い処理リソース106は、データベース管理システム(DBMS)140を利用して、これらのアカウントに関連する情報を作成、削除、および管理してよい。DBMS 140は、支払い処理リソース106に対してローカルにまたはリモートに置かれる場合があり、支払い処理リソース106は、任意の好適な電気通信媒体を用いてDBMS 140にアクセスしてよい。

【0117】

図1aの支払い処理リソース106は、鍵ストレージモジュール122および支払いデータストア124とインタラクションするように構成される。鍵ストレージモジュール122は、トランザクションが行われることを可能にするために支払い処理リソース106を用いる関係者のアカウントに対応する暗号鍵を記憶するように構成される。鍵ストレージモジュール122は、任意の好適なストレージを利用してよく、データベース管理システム(DBMS)を利用して、鍵ストレージモジュール122に暗号鍵を記憶する関係者のデータベース内のレコードからのデータを初期化し、記憶し、取り出す。支払いデータストア124は、支払い処理リソース106を用いて実施されるすべての支払いに関連するデータを記憶するように構成される。

【0118】

第1のコンピューティングデバイス102かまたは第2のコンピューティングデバイス126かのどちらかのユーザは、支払い処理リソース106にアカウントを確立してよい。そのようなアカウントの確立が、以降で図2を参照して説明される。

【0119】

Aliceが、ステップS200において、支払い処理リソース106へのアクセスを要求する入力を与えることによってセットアッププロセスを初期化する。第1のコンピューティングデバイス102が、ステップS202においてAPI 108にアクセスし、支払い処理リソース106とのインタラクションが行われることを可能にするためにAPI 108に認証データを提供する。認証データは、第1のコンピューティングデバイス102のユーザを一意に特定することができる任意のデータを含んでよい。例は、パスワード、氏名と生年月日との組合せ、またはユーザを一意に特定することができる任意のその他のデータアイテムである。認証データを承認すると、支払い処理リソース106が、ステップS204において、支払い処理リソース106にアカウントをセットアップするために必要とされる情報の要求を送信する。

【0120】

支払い処理リソース106がアカウントをセットアップするために必要とされる情報は、アカウントを管理するための帳簿管理機関(bookkeeping authority)として働く資産レジストリ、すなわち、銀行アカウントを提供する銀行のアイデンティティ(identity)、たとえば、HSBC、ユーザを特定する情報、たとえば、ユーザの公開暗号鍵、発行者の条項および条件の署名されたバージョンに対応するデータ、ユーザが用いたい通貨の識別情報、たとえば、GBP(スターリングポンド)、発行者の公開暗号鍵、ならびにアカウントの最小値を設定する最小残高値である。各資産レジストリは、資産レジストリによって管理されるすべてのアカウントに関連付けられる対応する資産の少なくとも1つの発行者に関連付けられる。たとえば、銀行は、GBPおよびEURの発行者に関連付けられる。銀行は、金およびその他の貴金属などのその他の資産の発行者に関連付けられる場合もある。金の発行者の例は、英国の王立造幣局である場合がある。情報は、支払い処理リソース106によってDBMS 140のレコードに記憶される。

【0121】

それから、Aliceが、必要とされる情報を提供する。情報は、ステップS206において、API 108を介して支払い処理リソース106に送信される。詳細を受信すると、支払い処理リソース106は、ステップS208において、資産レジストリデータベースにレコードを生成し、ステップS210において、提供された詳細をレコードに投入する。

【0122】

次に、支払い処理リソース106は、ステップS212において、イベントストリームがまだ初期化されていない場合、Aliceのアカウントに対応する、英国特許出願第2102314.8号に従ったイベントストリーム110aを初期化する。代替的または追加的に、支払い処理リソース106は、Aliceのためのイベントストリーム110aを既に記憶した可能性がある。

【0123】

そして、支払い処理リソース106は、ステップS214において、Aliceのためにアカウントが確立されたことを確認するための確認メッセージを第1のコンピューティングデバイス102に送信する。ステップS200からS214は、(HSBCのような銀行に関連する)支払い処理リソース106上のアカウントを確立するためにBobによっても用いられる。Bobのアカウントに対応するイベントストリーム110bも、初期化される。

【0124】

イベントストリームは、ブロックチェーンベースの追加専用ログである。AliceまたはBobなどの支払い処理リソース106のユーザは、自分のアカウントに対応するイベントストリームを作成すること、そのイベントストリームに付け加えること、およびそのイベントストリームを閉じることができる。これらは、後で説明される。

【0125】

代替的に、AliceまたはBobは、既に用いている資産レジストリに関連するアカウントの詳細を提供し、必要な情報のすべてを提供したことを条件に、ステップS200からS214を回避する場合がある。

【0126】

記録するための支払いデータの準備
ここで、支払い処理リソース106によって資産の譲渡が可能にされる複数の例示的なシナリオを説明する。これらの例は、各例の特徴がその他の例の特徴と組み合わされ得るという点で、例示的および非限定的であるように意図される。

【0127】

以降、図3aおよび図3bを参照して、Aliceが支払い処理リソース106を用いてBobに5GBPを送信する例示的なシナリオを説明する。この例において、譲渡されている資産は現金であり、資産レジストリは銀行である。

【0128】

ステップS300において、Aliceは、Bobに連絡を取って、Aliceが今度のBobの誕生日にBobに5GBPを送りたいことをBobに知らせる。ステップS302において、Bobは、Aliceにその気前のよさを感謝するために任意の好適な媒体を用いてメッセージを送る。

【0129】

それから、Aliceは、第1のコンピューティングデバイス102を用いて、5GBPを支払うという自分の希望を支払い処理リソース106に示す。第1のコンピューティングデバイス102は、ステップS200からS214に従ってAliceによって作成されたアカウントを用いて支払いプロセスを開始するためにAPI 108にアクセスする。これが、ステップS306である。デバイス102からAPI 108への呼び出しは、AliceがBobに支払いたい金額を示す。デバイス102からの呼び出しは、Aliceがそこから支払いたいアカウントと、Aliceが支払いたい通貨と、Aliceが支払いたい相手、すなわち、Bobとをさらに示す。AliceがBobに支払いたい金額、Bobの識別情報、Aliceがそこから支払いたいアカウントの識別情報(すなわち、GBP)は、ステップS308において支払い処理リソース106に送信される支払いメタデータのセットを形成する。

【0130】

支払い処理リソース106は、Aliceから支払いメタデータを受信すると、ステップS308においてAliceが提供したメタデータに基づいて、Bobのアカウントからメタデータを取り出す。これが、ステップS310である。支払い処理リソース106は、Bobのアカウントが関連する通貨、すなわち、スターリングポンド(GBP)および銀行をBobのアカウントから取り出す。

【0131】

次に、支払い処理リソース106は、ステップS312において、Aliceから受信された支払いメタデータおよびBobのアカウントから取り出された情報を用いて、支払い指示データセットを生成する。

【0132】

この例において、Bobの銀行アカウントの提供者は「hsbc.com」であり、通貨はGBPと特定され、支払いの額(すなわち、Bobによって受け取られている金額)は5GBPであり、アカウントの識別情報は<Bob:HSBC>によって与えられ、ユーザは「kyc」値によってBobと特定され、行為者(actor)は支払いの受取人(beneficiary)、すなわち、支払いを受ける個人と特定される。これは、支払い指示データセットの一部を形成する。支払い指示データセットは、任意で、署名<Bob_sig>を用いてBobによって署名された条項および条件のバージョンも含む場合がある。

【0133】

支払い指示データセットの別の部分は、Aliceの詳細によって形成される。すなわち、アカウントの提供者は「hsbc.com」であり、通貨はGBPと特定され、Bobに送金されている支払いの額は5GBPであり(すなわち、Bobに支払われるAliceからの5GBPの引き落とし(debit)であり、したがって、支払い指示データセットにおいては-5と表現される)、アカウントの識別情報は<Alice:HSBC>によって与えられ、ユーザは「kyc」値によってAliceと特定される。支払い指示データセットは、ユニフォームリソースロケータ(URL)からアクセスされてよいドキュメントに含まれる場合があるAliceによって署名された条項および条件も含んでよい。また、支払い指示データセットは、行為者を支払いの送金人(originator)、すなわち、支払いを行う個人として特定する。

【0134】

それから、ステップS314において、支払い指示データセットへのAliceの署名の要求とともに、メッセージが第1のコンピューティングデバイス102に送信される。そして、Aliceは、Bobへの5GBPの支払いを承認するために、ステップS316において自分の暗号署名を提供する。そのとき、Aliceの署名は、支払い処理モデル132によって支払い指示データセットに適用される。つまり、Aliceは、自分の暗号署名によって支払い指示データセットに署名する。手短に言えば、Aliceのアカウントは引き落とされ、Bobのアカウントは入金されている。したがって、Aliceの署名が必要とされる。Bobの署名は、Bobがt&cリンク(すなわち、Bobが署名した条項および条件のドキュメントへのURL)と条項および条件を含むドキュメントのハッシュとを提供した場合にのみ必要される場合がある。これは、Aliceが送金された資金と引き換えにBobから何かを購入している場合、Bobが支払いの見返りとして条項および条件を提示したことを証明可能なように示され得ることを意味する。

【0135】

銀行が同一であり、金額が釣り合っているので、この例においては1つの署名のみが必要とされる。上述のように、Bobがt&cリンクを提供した場合は、2つの署名が必要とされる場合がある。

【0136】

次に、支払い処理リソース106は、ステップS318において、支払い指示データセットに支払いプロトコル基準を適用する。支払い処理リソース106は、ステップS320において、支払いプロトコルモジュール120にアクセスする。

【0137】

支払いプロトコルモジュール120は、まず、支払い指示データセットが、金額が一致しているという点でゼロサム規則を遵守すること、すなわち、Aliceのアカウントから引き出されている額がBobのアカウントに支払われている額と等しいことをチェックする。これが、ステップS322である。Aliceのアカウントから5GBPが引き出されており、Bobのアカウントに5GBPが支払われている、つまり、金額が同一であり、銀行が同一であるので、ゼロサム規則は遵守される。つまり、Aliceのアカウントに-5GBPが加えられており、Bobのアカウントに+5GBPが加えられているので、それぞれの金額は合計すると0になる。銀行が同一であるので、このステップは満たされ、データセットはゼロサム規則を遵守する。

【0138】

それから、支払いプロトコルモジュール120は、AliceからBobに送金されている額がAliceの残高を何らかの最小値未満にしないことをチェックする。これが、ステップS324である。つまり、Aliceはお金を使いすぎなのか? Aliceがお金を使いすぎている場合、すなわち、Aliceの残高(引く5GBP)が最小値未満になる場合、支払いプロトコルモジュール120は、Aliceにエラーメッセージを発行して、Aliceが使いたいお金を使うことができないこと、つまり、Bobに5GBPを支払うための資金がないことをAliceに知らせる。さらに言えば、与信枠が用いられている場合、最小値はマイナスになることがあり得る。支払いプロトコルモジュール120は、再び開始する指示が与えられるまで、すなわち、Aliceがより多くの資金を自分の銀行アカウントに預け入れたか、またはAliceの最低残高が変更されたとき、ステップS320に戻る。

【0139】

次に、支払いプロトコルモジュール120は、資産の識別情報に対応するデータ中でフィールドをチェックすることによって、支払いに関連するデータがトランザクションの2人の関係者間で一致しているかどうかをチェックする。これが、ステップS326である。この例のデータは、ゼロサム規則が満たされ、銀行が同じ、すなわち、「hsbc.com」であり、通貨が同じであるので一致している。つまり、銀行および資産の識別情報が釣り合う。下のさらなる例に見られるように、銀行および資産の識別情報が釣り合わないとき、必要とされる釣り合いを提供するためにさらなるメタデータが生成される必要がある。

【0140】

これを示す別の方法は、銀行および資産の識別情報を示すためのテンプレート(XXX_BBBB:AAAA)を利用してよく、XXXは、アカウントの運用者であり、BBBBは、銀行の識別情報であり、AAAAは、資産の識別情報である。このテンプレートを用いて、Alice_HSBC:GBPからBob_HSBC:GBPに5GBPが支払われることを示すことができ、銀行および資産の識別情報が釣り合っていることが分かる。

【0141】

支払い処理モジュール120は、AliceおよびBobの暗号署名が確認されるステップS328に移る。支払い処理モジュール120は、各署名のハッシュを生成し、ハッシュをステップS200からS214において生成されたレコードに記憶されたものと比較することによって、AliceおよびBobの暗号署名を確認する。これは、AliceおよびBobのアイデンティティも確認する。代替的または追加的に、プライベート/公開暗号鍵ペアに基づく標準的なPKI技術も、各署名を確認するために用いられてよい。これらの技術は、クライアントのアイデンティティを検証するためにも用いられ得る。

【0142】

ステップS322、S324、S326、およびS328の充足は、支払いプロトコルによって規定された基準が満たされたことを意味し、したがって、支払い処理リソース106は、支払い指示データセットに従って、AliceからBobへの5GBPの支払いが行われることを可能にする。

【0143】

そのとき、支払い処理リソース106は、ステップS330において、AliceおよびBobの各々に関して、ブロックチェーン112からブロックチェーントランザクションを取り出す。これは、図3cの例示的な概略図を参照して説明される。

【0144】

Aliceのブロックチェーントランザクション402は、ダスト出力(Tx0, Alice)を含み、Bobのブロックチェーントランザクション404は、ダスト出力(Tx0, Bob)を含む。

【0145】

ランデブートランザクションの生成
そして、支払い処理リソース106は、ステップS330において取り出されたブロックチェーントランザクションからのそれぞれのダスト出力を使用するAliceおよびBobの各々のダスト入力を含む新しいランデブーブロックチェーントランザクション406を生成する。ダスト出力は、AliceおよびBobに関連するイベントストリームに対応するダストチェーンから取り出される場合がある。これも、図3cに示される。トランザクション402および404から406へのチェーンは、ダストトランザクションのチェーンとして説明され得る。ダスト入力/出力は、暗号通貨のフィールドによって「ダスト」であると示される暗号通貨の量の入力/出力である。本開示のブロックチェーントランザクションの文脈における「ダスト」は、低いまたは極小の値の出力を有するデジタル資産または暗号通貨に関する使用可能なトランザクションであると理解され、つまり、値は、ブロックチェーンにおいて出力をマイニングするための手数料よりもはるかに少ない場合がある。

【0146】

代替的に、支払い処理リソース106は、英国特許出願第2102217.3号に記載されているように、既存のイベントストリームの一部を形成しないダストと、階層的決定性(HD: hierarchical deterministic)鍵チェーンとの組合せを用いて新しいダストトランザクションを生成する場合がある。言い換えると、ダストを入力として用い、AliceおよびBobの各々に対応する入力からを含むダストトランザクションが生成され、そのダストは、イベントストリームで既に用いられていない。HD鍵チェーンを所有する関係者は、サブ鍵のうちの1つおよびダストを用いて、新しいイベントストリームの最初のトランザクションを生成してよい。要するに、ブロックチェーン112上の既存のトランザクションから取り出され、新しいイベントストリームの開始のための基礎として用いられ得るダストに基づいて、新しいイベントストリームが開始されてよい。つまり、ダストは、(新しいイベントストリームを開始するために)トランザクションを生成するために用いられ、それから、別のイベントストリームの開始に用いられる前にプラットフォームに返される場合がある。

【0147】

ダストトランザクションのチェーンとイベントストリームとの間の関係が、図3dを参照して以降でさらに明らかにされる。

【0148】

図3dは、本開示の第1の態様に関するものであり、順序付けられた追加専用データストレージシステムの基本的なデータ構造およびパラダイムを示す。これは、データロギングシステムとして説明されることも可能である。図3dに示される特定のシステムは、イベントをロギングするためのイベントストリームシステムである。例として、イベントストリームが、全体を通じて例示を目的として用いられるが、当業者は、本明細書において説明される提案されるシステムおよび態様が、広くデータアイテムとともに、および順序付けられた追加専用データアイテムロギングまたはストレージシステムとともに用いられてよいことを理解するであろう。図4および図6と一貫して、データアイテムは、実際のデータのハッシュを指す。有利なことに、データ自体の代わりにハッシュを用いることは、(大きい場合があり、トランザクションには大きすぎさえする場合がある)データがトランザクションに記憶されることを要求することなく、データの存在の証明を提供する。また、これは、たとえハッシュがチェーン上で公開されるとしても、データがハッシュと見分けられないので、データのプライバシーを守る。ここで説明されるデータは、支払い処理リソース106によって記録されている支払いに関連する支払い指示データである。

【0149】

追加専用ログの各イベント502は、ブロックチェーントランザクション504にマッピングされ、ブロックチェーントランザクションのシーケンスは、「ダストのチェーン」を用いて順序付けられ、リンクされる(506)。各イベントに関連するデータは、各トランザクションの一部として(下で説明される)ペイロードに記憶される。データペイロード(すなわち、支払い指示メタデータのハッシュ)は、トランザクションの使用不可能なOP_RETURN出力に保持される -- そのようなトランザクションの例は、上述のランデブートランザクション406である。これは、ブロックチェーンに任意のデータを書き込み、また、トランザクションの出力を無効とマーキングするために用いられ得るScriptオペコードである。別の例として、OP_RETURNは、トランザクション内にメタデータなどのデータを記憶し、それによって、ブロックチェーン上にメタデータを不変的に記録することができる、トランザクションの使用不可能な出力を作成するためのScript言語のオペコードである。

【0150】

ダストのチェーンは、ここでは、シーケンスの各ブロックチェーントランザクションの、その直接の先任者への支出の依存関係を課すために用いられる暗号通貨の入力および出力の切れ目のない連鎖である。

【0151】

トランザクションにおけるダスト出力の使用は、イベントストリームなどの順序付けられた追加専用データストレージシステムに関して、トランザクションが発生するとおりにすべてのそれらのトランザクションの不変の連続的な記録を維持するために有利であり、重要である。これは、ブロックチェーンにトランザクションを記帳することによって、すべてのブロックチェーントランザクションが、それらがブロックチェーン上で確認されるかまたはブロックチェーンに追加されると、タイムスタンプを付けられ、特定の順序であり続けるが、これが、それらのトランザクションの発生順の保存を保証しないからである。これは、トランザクションが異なる時間にブロックにマイニングされる可能性があり、および/またはトランザクションが同じブロック内でさえも異なる順序であるからである。有利なことに、シーケンスの次のトランザクションの最初の入力によって使用されるダスト出力の使用は、トランザクションの順序が時系列的に追跡され、イベント自体とイベントの発生順との両方の改ざん防止記録が作成されることを保証する。これは、ブロックにマイニングされると、シーケンスの前のトランザクションから次のトランザクションへのダストの支払いが、ビットコインのプロトコル規則に合致して、ペイロードと呼ばれ、下で検討される埋め込まれたデータキャリア要素のシーケンスが順序を変更され得ず、イベントストリームが侵害されたことが直ちに明らかなることなくシーケンスを変更する可能性がある挿入または削除が発生しない可能性があることを保証するからである。一部の実施形態においては、ビットコインプロトコルに固有の二重支払い防止メカニズムが、異なるトランザクションの入力と出力との間の暗号通貨(たとえば、ダスト)の移動が時系列順のままであることを保証する。ダストトランザクションの連鎖は、ブロック間およびブロック内のトランザクション(ならびに、したがって、関連するイベントおよびデータ)の順序の保存を提供するために、トポロジカルな順序付け(topological ordering)を利用する。したがって、これは、順序付けられた追加専用データアイテムストレージの完全性を改善する。

【0152】

このようにして、ブロックチェーントランザクション504は、トランザクションの有向グラフを形成する。グラフの方向は、エッジ506によって示されるように、シーケンスの前のトランザクションから次のトランザクションに向けられた一方向と考えられ得ることに留意されたい。図3dのエッジ506の矢印は、トランザクションが次のトランザクションを指し示していることを示すが、ビットコイントランザクションにおける支出の関係は、実際には、あるトランザクションから先行トランザクションに向かう。このグラフは、トランザクションの間の支出の関係によって作成される。これらの支出の関係は、一種の参照と考えられ得る。どのようにしてイベントをイベントストリームに付け加えるべきかについてのさらなる詳細は、英国特許出願第2102314.8号ならびに、特に、ただし非排他的に、それが「Ordered, Append-only data Storage」、「Event Stream and the Chain of Dust」、および「Backward Referencing in the Chain of Dust」に言及する箇所に見つけられ得る。

【0153】

図3cに示されたトランザクション406などのランデブーブロックチェーントランザクションは、それぞれが上述の所与のエンティティ/ユーザに関連する複数のイベントストリームを同期するためのブロックチェーントランザクションである。これは、複数のダスト出力を対応する入力として使用することによって実現される。この例において、これは、Alice、Bob、およびHSBCの各々に対応するダストのチェーン(すなわち、ダスト入力/出力ペア)が単一のトランザクションを通過することを可能にする。ダストチェーン入力/出力ペアは、トランザクション内に対応する入力/出力インデックスを有していなければならない。この場合、ダストチェーン入力/出力ペアは、下記のように、トランザクションに関連するすべてのイベントストリームに支払いが記録されることを可能にするために用いられる。

【0154】

Aliceのダスト出力を使用するダスト入力は、Tx1, Aliceと表記され、Bobのダスト出力を使用するダスト入力は、Tx1, Bobと表記される。ステップS332において、新しいランデブーブロックチェーントランザクション406が生成される。

【0155】

ランデブーブロックチェーントランザクション406への資金は、支払い処理リソース106によって追加され、支払い処理リソース106に払い戻される。これは、ランデブーブロックチェーントランザクション406が有効化のためにブロックチェーン112に送信される場合、ランデブーブロックチェーントランザクション406の有効化後に任意のマイナーの手数料を引かれる場合がある。

【0156】

ランデブーブロックチェーントランザクション406は、Tx1, AliceおよびTx1, Bobをそれぞれ使用するさらなるダスト出力を含む。それがランデブートランザクションであるとき、AliceおよびBobにそれぞれ対応する入力/出力ペアのインデックスは、たとえば、Tx1, Aliceの入力インデックスが番号1として割り振られる場合があり、対応するダスト出力の出力インデックスが出力インデックス番号1として割り振られるという点で同一である。

【0157】

また、支払い処理リソース106は、データキャリア412aおよび412bの形態で、AliceおよびBobの各々に関して、ブロックチェーントランザクション406に使用不可能であることが証明可能な出力を追加する。

【0158】

データキャリアの各々は、異なるdataDigestおよび/または異なるstreamDigestを保持してよく、streamDigestは、ソルト化される場合もある。

【0159】

それぞれのデータキャリア内に保持されるデータペイロード(すなわち、支払い指示メタデータのハッシュ)は、トランザクションの使用不可能なOP_RETURN出力に保持され、これは、データペイロードが、その後、使用不可能な出力としてブロックチェーンに記憶され得ることを意味する。これは、データキャリア内に保持されるデータペイロード(すなわち、支払い指示メタデータのハッシュ)が、トランザクションの使用不可能なOP_RETURN出力に保持されることを意味し、これは、データペイロードが、その後、使用不可能な出力としてブロックチェーンに記憶され得ることを意味する。

【0160】

データキャリア412内のデータは、ステップS300からS328において支払い処理リソースによって生成された支払い指示データセットのハッシュを含む。これは、ステップS334において生成される。使用不可能であることが証明可能な出力は、ランデブートランザクション406がトランザクション内で支払い指示データセットのハッシュを運ぶことを可能にし、ハッシュがブロックチェーン上に記憶されることを可能にする。これは、支払い指示データセットと、ひいては支払いのレコードとがブロックチェーン上に記憶されることを意味する。これは、支払いのレコードがブロックチェーンの不変性の恩恵を受けることを意味する。

【0161】

それから、ブロックチェーントランザクション406は、トランザクションとのユーザの対応が正しく、ユーザ、すなわち、AliceおよびBobに対応するかどうかを確かめるためにチェックされてよい。これが、ステップS336である。

【0162】

支払い処理リソース106は、ステップS338において、イベントストリーム、すなわち、AliceおよびBobに関するイベントストリームにデータを付け加えるための基礎としてブロックチェーントランザクション406が用いられ得ることを確認する通知をイベントストリームリソース110に発行する。

【0163】

イベントストリームは、ブロックチェーンによって支援された追加専用ログである。この例において、AliceおよびBobは、それぞれ、自分のイベントストリームを持っているが、持っていない場合は、イベントストリームが初期化されてよい。つまり、Aliceは、イベントストリーム(E-Alice)を有し、Bobは、イベントストリーム(E-Bob)を有する。イベントストリームのエントリは、ESnと表記される場合があり、nは、ゼロでない正の整数または非負の整数である場合がある。

【0164】

図3dに示されるように、イベントストリームは、一連のエントリとして示されることが可能であり、ストリーム内のいずれのエントリも、単調に増加する連番によって参照されてよく、すなわち、最初のエントリが、ES1と呼ばれる場合があり、2番目のエントリが、ES2と呼ばれる場合がある。

【0165】

支払い処理リソース106は、AliceおよびBobがイベントストリームにアクセスするまたは付け加えることを認可される場合にのみ、それぞれのイベントストリームに付け加える。認可は、たとえば、署名を支払い処理リソース106において記憶された署名と比較することによってチェックされてよい。支払いデータをイベントストリームに付け加えることによって、支払いは、記録され、ブロックチェーン112に関連付けられる不変のログに記録されることから恩恵を受けることができる。手短に言えば、イベントストリームは、AliceおよびBobに関連するアカウントからのトランザクションの順序を追跡するために用いられる。つまり、イベントストリームのエントリは、ブロックチェーン112に関連する不変のログである。上述のイベントストリームは、以下を保証する。
・イベントストリームの個々のエントリが、書き込まれてから修正されていないこと
・以前に連続していたエントリの間にエントリが挿入されていないこと
・エントリが削除されていないこと
・エントリが順序を変更されていないこと
・認可されていない関係者が、ストリームにイベントを付け加えてはならないこと

【0166】

支払い処理リソース106は、ランデブートランザクション406を用いて、ブロックチェーントランザクション406のデータキャリアに含まれる支払い指示メタデータのハッシュを含むエントリをそれらのイベントストリームの各々に付け加えることによって、支払いをイベントストリームE-AliceおよびE-Bobと同期する。これが、ステップS340である。これは、図3eに概略的に示される。

【0167】

次に、支払い処理リソース106は、イベントストリームの各々に追加されたエントリの識別子を生成する。これが、ステップS342である。識別子は、英数字であってよく、または支払い指示メタデータのハッシュに基づいて生成される数字であってよい。たとえば、支払い指示メタデータのハッシュがSHA256暗号によって生成される場合、識別子は、支払い指示メタデータのハッシュにさらなるSHA256暗号を適用することによって生成されてよい。つまり、識別子は、支払い指示メタデータのハッシュのハッシュであってよい。

【0168】

そして、支払い処理リソース106は、識別子を、支払い指示メタデータのコピーと一緒に支払いデータストア124に記憶する。これは、要求に応じた、AliceとBobとの間の支払いの検証を可能にする。

【0169】

以降、やはりAliceがBobに5GBPの総和を支払うが、BobのアカウントがHSBCではなくRevolutによって提供されるさらなる例示的なシナリオを説明する。これは、図4aおよび図4bを参照して説明される。この例は、ステップS326までは図3aから図3eを参照して説明された例と同一である。したがって、簡潔にするために、ステップS326を参照して説明された段階から説明を始める。

【0170】

言い換えると、ステップS326が肯定的な結果をもたらし、トランザクションが進むためには、銀行の釣り合いがとれている必要がある。つまり、銀行と資産の識別情報との両方を釣り合わせるメタデータが作成される必要がある。

【0171】

つまり、関係者に対応するデータ中でフィールドをチェックすることによって、支払いに関連するデータがトランザクションの2人の関係者間で一致しているかどうかを(ステップS326において)支払いプロトコルモジュール120によってチェックすると。通貨が同じであり、金額が互いに補完し合っている、すなわち、Aliceが-5GBPの引き落としを受け、Bobが5GBPの入金を受けるが、アカウントの提供者は異なっており、すなわち、Aliceのアカウントの提供者は「hsbc.com」であり、Bobのアカウントの提供者は「Revolut」であることが分かる。

【0172】

これを示す別の方法は、銀行および資産の識別情報を示すためのテンプレート(XXX_BBBB:AAAA)を利用してよく、XXXは、アカウントの運用者であり、BBBBは、銀行の識別情報であり、AAAAは、資産の識別情報である。この場合、Alice_HSBC:GBPからBob_REVOLUT:GBPに5GBPを送金する試みは、完了され得なかった。

【0173】

そのとき、支払いプロトコルモジュール120は、支払いプロトコル基準に対する支払い指示データセットのチェックを停止する。そして、支払い処理リソース106が、支払い指示データセットに追加されるさらなるメタデータを生成する。

【0174】

2つの異なる銀行に関するさらなるメタデータの生成
支払い処理リソース106は、「Revolut.com」および「HSBC」に対応する暗号鍵の要求によって鍵ストレージモジュール122にアクセスする。これが、ステップS400である。

【0175】

鍵ストレージモジュール122は、複数の暗号鍵を記憶する。各暗号鍵は、「Revolut.com」または「HSBC」などの銀行に対応するレコードに記憶され、これらの銀行によって管理されるアカウントへの支払いおよびそれらのアカウントからの支払いに関して、支払い処理リソース106が独自の支払い指示データを生成することを可能にする。これは、たとえ関係者が自分のアカウントのために選択する銀行が異なっていても、支払いが支払い処理リソース106によって安全に可能にされ得ることを意味するので、異なる銀行のアカウントの間で支払いが行われているときに特に有利である。

【0176】

鍵ストレージモジュール122がアクセスされるとき、鍵ストレージモジュール122は、要求された鍵に対応する銀行を特定する入力を受信する。鍵ストレージモジュール122は、銀行に対応する鍵を返す。この例においては、銀行「Revolut.com」および「HSBC」に対応する鍵が返される。これが、ステップS402である。

【0177】

次に、支払い処理リソース106は、2つのさらなる支払いを詳述するさらなるメタデータを含むように支払い指示データセットを修正する。メタデータは、第1の支払いがAliceからHSBCへの5GBP分のものであり、それがAliceのHSBCアカウントからの支払いであるが、Aliceが既に署名した支払い、すなわち、Bobへの支払いではないので、鍵ストレージモジュール122から取り出されたHSBCの鍵によって署名されることを詳述する。メタデータは、第2の支払いがHSBCからRevolutへのものであり(5GBP分、つまり、HSBCのアカウントが5GBP引き落とされる)、それが鍵ストレージモジュール122から取り出されたRevolut.comの鍵によって署名されることをさらに詳述する。そして、メタデータは、さらなる支払いがRevolutからBobのRevolutアカウントに行われる(つまり、Bobの残高が5GBP増やされるが、そのとき、RevolutはそれをHSBCのアカウントから引き落とさなければならない)ことをさらに詳述する。これは、Bobの鍵によって署名される。これは、ステップS326において特定されたデータ間の不一致が支払い処理リソース106によって解決されることを意味する。これが、ステップS404である。つまり、不一致の存在を決定すると、銀行が一致し、金額が一致することを保証するために、支払い処理リソース106によって不一致が解決される。

【0178】

上述したテンプレートを用いて、さらなるメタデータを含むように支払い指示データセットを修正することは、Alice_HSBC:GBPからHSBC_HSBC:GBPに5GBPが支払われ、次に、HSBC_HSBC:GBPからHSBC_REVOLUT:GBPに5GBPが支払われ、そして、HSBC_REVOLUT:GBPからBob_REVOLUT:GBPに支払いが行われることを意味し、これは、銀行の識別情報および資産の識別情報が釣り合っており、トランザクションが完了され得ることを意味する。

【0179】

銀行が一致していなかったために、ステップS326が最初に否定的な結果を返したので、支払いプロトコルモジュール120は、支払いプロトコルに鑑みて支払い指示データセットを評価するために再び開始する必要がある。支払い指示データセットは、ステップS322およびS324に関連して示されたように、ゼロサム規則およびAliceの支出限度の充足に関する肯定的な判定を既に返した。銀行間の一致の欠如を解決し、資産の識別情報および銀行が釣り合っていることを保証するために支払い処理リソース106によって導入された支払いを含むように支払い指示データセットが今や修正されたので、支払い処理モジュール120は、AliceおよびBobの暗号署名が確認されるステップS406に移る。

【0180】

支払い処理モジュール120は、各署名のハッシュを生成し、ハッシュをステップS200からS214において生成されたレコードに記憶されたものと比較することによって、AliceおよびBobの暗号署名を確認する。これは、AliceおよびBobのアイデンティティも確認する。代替的または追加的に、プライベート/公開暗号鍵ペアに基づく標準的なPKI技術も、各署名を確認するために用いられてよい。これらの技術は、クライアントのアイデンティティを検証するためにも用いられ得る。また、支払い処理モジュール120は、同様の技術を用いて、2つの銀行、すなわち、HSBCおよびRevolutの署名を確認する。

【0181】

ステップS406が完了すると、支払い処理リソース106は、支払い指示データセットに従って、AliceからBobへの5GBPの支払いが行われることを可能にする。つまり、支払い処理リソース106は、2つのさらなる支払いを適用して一致の欠如を解決し、支払い指示データセットを、支払い指示データセットを用いて支払いを行うのに好適にすることによって支払い指示データセットにおける一致の欠如を解決する。

【0182】

2つの銀行によるランデブートランザクション
次に、支払い処理リソース106は、ステップS408において、AliceおよびBobの各々に関して、ブロックチェーン112からブロックチェーントランザクションを取り出す。これは、図4bの例示的な概略図を参照して説明される。

【0183】

Aliceのブロックチェーントランザクション602は、ダスト出力(Tx0, Alice)を含み、Bobのブロックチェーントランザクション604は、ダスト出力(Tx0, Bob)を含む。支払い処理リソース106は、支払いに関わる銀行、すなわち、HSBCとRevolutのブロックチェーントランザクションも取り出す。HSBCの取り出されたブロックチェーントランザクション608は、ダスト出力(Tx0, HSBC)を含む。Revolutの取り出されたブロックチェーントランザクション610は、ダスト出力(Tx0, Revolut)を含む。

【0184】

そして、支払い処理リソース106は、ステップS408において取り出されたブロックチェーントランザクションからのそれぞれのダスト出力を使用するAliceおよびBobの各々のダスト入力を含む新しいランデブーブロックチェーントランザクション606を生成する。ダスト出力は、AliceおよびBobに関連するイベントストリームに対応するダストチェーンから取り出される場合がある。これも、図4bに示される。ランデブーブロックチェーントランザクション606は、それぞれブロックチェーントランザクション408および410から取り出されたHSBCおよびRevolutのダスト入力をさらに含む。

【0185】

代替的に、第1の例と同様に、支払い処理リソース106は、既存のイベントストリームの一部を形成しないダストと、階層的決定性(HD)鍵チェーンとを用いて新しいダストトランザクションを生成する場合がある。

【0186】

ダストトランザクションのチェーンとイベントストリームとの間の関係は、図3dを参照して既に明らかにされた。

【0187】

ランデブーブロックチェーントランザクション606は、Alice、Bob、Revolut、およびHSBCの各々に対応する複数のイベントストリームを同期するためのブロックチェーントランザクションである。

【0188】

Aliceのダスト出力を使用するダスト入力は、(Tx1, Alice)と表記され、Bobのダスト出力を使用するダスト入力は、(Tx1, Bob)と表記される。ステップS410において、新しいランデブーブロックチェーントランザクション606が生成される。また、新しいランデブートランザクションは、それぞれ(Tx1, HSBC)と表記されるHSBCに対応するダスト入力と、それぞれ(Tx1, Revolut)と表記されるRevolutに対応するダスト入力を含む。

【0189】

ランデブーブロックチェーントランザクション606への資金は、支払い処理リソース106によって追加され、支払い処理リソース106に払い戻される。これは、ランデブーブロックチェーントランザクション606が有効化のためにブロックチェーン112に送信される場合、ランデブーブロックチェーントランザクション606の有効化後に任意のマイナーの手数料を引かれる場合がある。

【0190】

ランデブーブロックチェーントランザクション606は、Tx1, AliceおよびTx1, Bobをそれぞれ使用するさらなるダスト出力を含む。ランデブーブロックチェーントランザクション606は、HSBCおよびRevolut.comに関してブロックチェーンから取り出されたダスト入力に対応するダスト出力も含む。

【0191】

また、支払い処理リソース106は、ブロックチェーントランザクション606に、使用不可能であることが証明可能な出力を追加する。これは、データキャリア612として用いられる。データキャリアの各々は、同一であり、同じデータに基づき、同じ支払い指示データセットに基づく場合がある。データキャリアは、キャリアが付け加えられている特定のデータストリームのstreamStateに基づくいくつかの異なるデータを保持する場合があり、streamStateは、前のstreamStateおよび/またはインデックス(もしくはシーケンス番号)ならびに/またはそのデータキャリアの公証(notarisation)に用いられる個々のソルトに基づく。代替的または追加的に、ブロックチェーントランザクション606に入力を与えるすべての関係者の各々に関するデータキャリアを付け加えるために、それらの関係者に対応するように、さらなる使用不可能であることが証明可能な出力が追加されてよい。つまり、それぞれのデータキャリアは、それぞれのデータキャリアがそれぞれの関係者に応じて異なっていてよいという点で、それぞれの関係者に関連するデータを含む場合がある。たとえば、違いは、Aliceに関するデータキャリアがAliceにのみ関連するデータ、すなわち、Aliceの名前およびAliceのアカウント番号を含み、Bobに関するデータキャリアがBobにのみ関連するデータ、すなわち、Bobの名前およびBobアカウント番号を含んでよいことである場合がある。

【0192】

第1の例と同様に、データキャリア内に保持されるデータペイロード(すなわち、支払い指示メタデータのハッシュ)が、トランザクションの使用不可能なOP_RETURN出力に保持され、これは、データペイロードが、その後、使用不可能な出力としてブロックチェーンに記憶され得ることを意味する。

【0193】

データキャリア612の各々の中のデータは、支払い処理リソース106によって生成された支払い指示データセットのハッシュを含む。これは、ステップS412において生成される。使用不可能であることが証明可能な出力は、ランデブートランザクション606がトランザクション内で支払い指示データセットのハッシュを運ぶことを可能にし、ハッシュがブロックチェーン上に記憶されることを可能にする。これは、支払い指示データセットと、ひいては支払いのレコードとがブロックチェーン上に記憶されることを意味する。これは、支払いのレコードがブロックチェーンの不変性の恩恵を受けることを意味する。

【0194】

それから、ブロックチェーントランザクション606は、トランザクションならびにHSBCおよびRevolutによって提供されるアカウントとのユーザの対応が正しく、ユーザ、すなわち、AliceおよびBobに対応するかどうかを確かめるためにチェックされてよい。これが、ステップS412である。

【0195】

支払い処理リソース106は、(ステップS416において)イベントストリーム、すなわち、Alice、Bob、Revolut、およびHSBCに関するイベントストリームにデータを付け加えるための基礎としてブロックチェーントランザクション606が用いられ得ることを確認する通知をイベントストリームリソース110に発行する。

【0196】

この例において、Alice、Bob、およびHSBCは、それぞれ、自分のイベントストリームを持っているが、持っていない場合は、イベントストリームが初期化されてよい。つまり、Aliceは、イベントストリーム(E-Alice)を有し、Bobは、イベントストリーム(E-Bob)を有し、HSBCは、イベントストリーム(E-HSBC)を有し、Revolutも(E-Revolut)を有する。

【0197】

支払い処理リソース106は、ランデブートランザクション606を用いて、ブロックチェーントランザクション606のデータキャリアに含まれる支払い指示メタデータのハッシュを含むエントリをそれらのイベントストリームの各々に付け加えることによって、支払いをイベントストリームE-Alice、E-Bob、E-Revolut、およびE-HSBCと同期する。これが、ステップS418である。これは、図4cに概略的に示される。イベントストリームE-Alice、E-Bob、E-Revolut、およびE-HSBCは、異なる長さであってよく、支払い指示データのハッシュは、それぞれのイベントストリーム内の異なる位置(インデックスとしても知られる)に付け加えられてよい。これは、各イベントストリームが異なる数のイベントを含む場合があるからである。たとえば、銀行のような特に活動的な関係者は、個人よりも大幅に長いイベントストリームを有する場合があり、支払い指示データは、個人に関してよりもはるかに大きなインデックスにおいて銀行のイベントストリームに追加される場合がある。イベントストリームに付け加えられたエントリの数が予め決められた量を超えた後、銀行が新しいイベントストリームを開始することを選択する可能性もある。

【0198】

その他の例と同様に、データキャリアの各々は、異なるdataDigestおよび/または異なるstreamDigestを保持する場合がある。streamDigestは、ソルト化される場合もある。RevolutおよびHSBCは、AliceおよびBobによって用いられるハッシュ方法とは異なるハッシュ方法を用いてソルト化されたstreamDigestを生成することを選択する場合がある。

【0199】

次に、支払い処理リソース106は、イベントストリームの各々に追加されたエントリの識別子を生成する。これが、ステップS420である。識別子は、英数字であってよく、または支払い指示メタデータのハッシュに基づいて生成される数字であってよい。たとえば、支払い指示メタデータのハッシュがSHA256暗号によって生成される場合、識別子は、支払い指示メタデータのハッシュにさらなるSHA256暗号を適用することによって生成されてよい。つまり、識別子は、支払い指示メタデータのハッシュのハッシュであってよい。

【0200】

そして、支払い処理リソース106は、識別子を、支払い指示メタデータのコピーと一緒に支払いデータストア124に記憶する。これは、要求に応じた、AliceとBobとの間の支払いの検証を可能にする。

【0201】

以降、やはりAliceがBobに5GBPを支払うが、BobのアカウントがHSBCによって管理されるが、GBPではなくEuroアカウントであるさらなる例示的なシナリオを説明する。

【0202】

これは、図5aおよび図5bを参照して説明される。この例は、ステップS326までは図3aから図3eを参照して説明された例とやはり同一である。したがって、簡潔にするために、ステップS326を参照して説明された段階から説明を始める。

【0203】

つまり、関係者に対応するデータ中でフィールドをチェックすることによって、支払いに関連するデータがトランザクションの2人の関係者間で一致しているかどうかを(ステップS326において)支払いプロトコルモジュール120によってチェックすると。AliceおよびBobのアカウントの通貨が異なっていることが分かる。言い換えると、Aliceは、HSBCにGBPでアカウントを有し、Bobは、HSBCにEuroでアカウントを有し、つまり、同じ銀行であるが通貨が異なり、つまり、資産識別子が異なる。

【0204】

そのとき、支払いプロトコルモジュール120は、通貨が異なるので、支払いプロトコル基準に対する支払い指示データセットのチェックを停止する。そして、支払い処理リソース106が、支払い指示データセットに追加されるさらなるメタデータを生成する。

【0205】

アカウントの通貨が異なる場合のさらなるメタデータの生成
支払い処理リソース106は、GBPに関してHSBCが所有するアカウントおよびEURに関してHSBCが所有するアカウントに対応する暗号鍵の要求によって鍵ストレージモジュール122にアクセスする。これが、ステップS500である。

【0206】

鍵ストレージモジュール122がアクセスされるとき、鍵ストレージモジュール122は、要求された鍵に対応する銀行ならびにそれぞれの資産識別子、すなわち、GBPおよびEURを特定する入力を受信する。鍵ストレージモジュール122は、銀行のGBPアカウントおよびEURアカウントに対応する鍵を返す。この例においては、HSBCによって管理されるGBPアカウントおよびEURアカウントに対応する鍵が返される。これが、ステップS502である。

【0207】

つまり、この場合、(GBPおよびEURが同じ通貨ではないので)資産は同じ識別情報を有していないが、AliceおよびBobは同じ銀行を確かに有する。これが、この例において、ステップS326が否定的な結果となる原因である。つまり、通貨が異なるので、資産の識別情報および銀行は、完全には一致していない。

【0208】

言い換えると、資産の種類の釣り合いがとれている必要があるので、ステップS326が肯定的な結果をもたらすためには、通貨の釣り合いがとれている必要がある。

【0209】

したがって、支払い処理モジュール120は、この不一致を解決するさらなるメタデータを生成する必要がある。HSBCによって管理されるGBPアカウントおよびEURアカウントに対応する鍵を取得した支払い処理モジュール120は、次に、このメタデータを生成することができる。

【0210】

ステップS504において、支払い処理モジュール120は、2つのさらなる支払いに対応するメタデータを生成する。1つ目は、AliceのGBP HSBCアカウントからHSBCのGBPアカウントへの5GBPの支払いであり(すなわち、AliceがHSBCに5GBPを返し)、そして、2つ目は、HSBCのEURアカウントからBobのEUR HSBCアカウントへの5.81EURの支払いである。

【0211】

ステップS506において、支払い処理モジュール120は、各署名のハッシュを生成し、ハッシュをステップS200からS214において生成されたレコードに記憶されたものと比較することによって、(必要があれば)AliceおよびBobの暗号署名を確認する。これは、AliceおよびBobのアイデンティティも確認する。代替的または追加的に、プライベート/公開暗号鍵ペアに基づく標準的なPKI技術も、各署名を確認するために用いられてよい。これらの技術は、クライアントのアイデンティティを検証するためにも用いられ得る。

【0212】

銀行および資産の識別情報が今や一致しているので、ステップS326の要件が満たされ、支払いプロトコル基準が満たされ得る。つまり、銀行および資産の識別情報を釣り合わせるメタデータが作成される。

【0213】

これを示す別の方法は、銀行および資産の識別情報を示すためのテンプレート(XXX_BBBB:AAAA)を利用してよく、XXXは、アカウントの運用者であり、BBBBは、銀行の識別情報であり、AAAAは、資産の識別情報である。つまり、ステップS504におけるメタデータの生成の前に、Alice_HSBC:GBPからBob_HSBC:EURに5GBPを送金する試みは完了され得なかった。しかし、ステップS504のメタデータの作成は、Alice_HSBC:GBPからHSBC_HSBC:GBPに5GBPが支払われ、それから、HSBC_HSBC:EURからBob_HSBC:EURに5.81EUR(5GBPをEURに換算した額)が支払われることを意味し、これは、銀行の識別情報および資産の識別情報が釣り合っていることを意味し、これは、トランザクションが完了され得ることを意味する。

【0214】

ステップS506が完了すると、支払い処理リソース106は、支払い指示データセットに従って、AliceからBobへの5GBPの支払いが行われることを可能にする。つまり、支払い処理リソース106は、2つのさらなる支払いを適用して一致の欠如を解決し、支払い指示データセットを、支払い指示データセットを用いて支払いを行うのに好適にすることによって支払い指示データセットにおける一致の欠如を解決する。

【0215】

2つの通貨によるランデブートランザクション
次に、支払い処理リソース106は、ステップS508において、AliceおよびBobの各々に関して、ブロックチェーン112からブロックチェーントランザクションを取り出す。これは、図5bの例示的な概略図を参照して説明される。

【0216】

Aliceのブロックチェーントランザクション702は、ダスト出力(Tx0, Alice_HSBC:GBP)を含み、Bobのブロックチェーントランザクション704は、ダスト出力(Tx0, Bob_HSBC:EUR)を含む。ダスト出力は、AliceおよびBobに関連するイベントストリームに対応するダストチェーンから取り出される場合がある。支払い処理リソース106は、支払いにやはり関与している通貨アカウントのブロックチェーントランザクションも取り出す。HSBCのGBP(すなわち、HSBC_HSBC:GBP)アカウントの取り出されたブロックチェーントランザクション708は、ダスト出力(Tx0, HSBC-GBP)を含む。HSBCのEUR(すなわち、HSBC_HSBC:EUR)アカウントの取り出されたブロックチェーントランザクション710は、ダスト出力(Tx0, HSBC-EUR)を含む。図5bに示されるように、ブロックチェーントランザクション702、704、708、および710の各々は、使用不可能であることが証明可能な出力も含み、使用不可能であることが証明可能な出力は、その出力が使用され得ないが、出力に関連するデータキャリアがブロックチェーン上に残り続けることを保証するためにOP_RETURNコマンドを含む履行スクリプト(redeem script)を有する。ダスト出力(Tx0, HSBC-GBP)および(Tx0, HSBC-EUR)は、HSBCのEURアカウントおよびGBPアカウントに関連するイベントストリームに対応するダストチェーンから取り出されてよい。

【0217】

そして、支払い処理リソース106は、ステップS508において取り出されたブロックチェーントランザクションからのそれぞれのダスト出力を使用するAliceおよびBobの各々のダスト入力を含む新しいランデブーブロックチェーントランザクション706を(ステップS510において)生成する。これも、図5bに示される。ランデブーブロックチェーントランザクション706は、それぞれブロックチェーントランザクション708および710から取り出されたHSBC-GBPおよびHSBC-EURのダスト入力をさらに含む。

【0218】

ダストトランザクションのチェーンとイベントストリームとの間の関係は、図3dを参照して既に明らかにされた。

【0219】

ランデブーブロックチェーントランザクション606は、Alice、Bob、Revolut、およびHSBCの各々に対応する複数のイベントストリームを同期するためのブロックチェーントランザクションである。

【0220】

Aliceのダスト出力を使用するダスト入力は、(Tx1, Alice)と表記され、Bobのダスト出力を使用するダスト入力は、(Tx1, Bob)と表記される。新しいランデブートランザクションは、それぞれ(Tx1, HSBC-GBP)および(Tx1, HSBC-EUR)と表記される、HSBCのGBPアカウントおよびEURアカウントに対応するダスト入力も含む。

【0221】

ランデブーブロックチェーントランザクション706への資金は、支払い処理リソース106によって追加され、支払い処理リソース106に払い戻される。これは、ランデブーブロックチェーントランザクション706が有効化のためにブロックチェーン112に送信される場合、ランデブーブロックチェーントランザクション706の有効化後に任意のマイナーの手数料を引かれる場合がある。

【0222】

ランデブーブロックチェーントランザクション706は、Tx1, AliceおよびTx1, Bobをそれぞれ使用するさらなるダスト出力を含む。ランデブーブロックチェーントランザクション706は、HSBC-GBPおよびHSBC-EURに関してブロックチェーンから取り出されたダスト入力に対応するダスト出力も含む。

【0223】

また、支払い処理リソース106は、Alice、Bob、ならびにHSBC-GBPアカウントおよびHSBC-EURアカウントの各々に関して、ブロックチェーントランザクション706に使用不可能であることが証明可能な出力を追加する。これらは、データキャリア712a、712b、712c、および712dとして用いられる。

【0224】

第1の例と同様に、データキャリア内に保持されるデータペイロード(すなわち、支払い指示メタデータのハッシュ)が、トランザクションの使用不可能なOP_RETURN出力に保持され、これは、データペイロードが、その後、使用不可能な出力としてブロックチェーンに記憶され得ることを意味する。

【0225】

第1および第2の例と同様に、支払い処理リソース106は、既存のイベントストリームの一部を形成しないダストと、HD鍵チェーンとを用いて新しいダストトランザクションを生成するように構成される場合がある。既存のダストチェーンからのダスト入力と新しいダストトランザクションとの組合せが、ブロックチェーントランザクション706を生成するために用いられる場合がある。

【0226】

データキャリア712a、712b、712c、および712d内のデータは、支払い処理リソース106によって生成された支払い指示データセットのハッシュを含む。データキャリアは、それらが同じ支払い指示データセットに基づくので同一である場合がある。代替的または追加的に、データキャリア内のデータは、それぞれが異なる関係者に関連するので異なる場合がある。

【0227】

つまり、それぞれのデータキャリアは、それぞれのデータキャリアがそれぞれの関係者に応じて異なっていてよいという点で、それぞれの関係者に関連するデータを含む場合がある。たとえば、違いは、Aliceに関するデータキャリアがAliceにのみ関連するデータ、すなわち、Aliceの名前およびAliceのアカウント番号を含み、Bobに関するデータキャリアがBobにのみ関連するデータ、すなわち、Bobの名前およびBobアカウント番号を含んでよいことである場合がある。

【0228】

したがって、データキャリアは、異なるハッシュを生成する。これは、ステップS512において生成される。使用不可能であることが証明可能な出力は、ランデブートランザクション706がトランザクション内で支払い指示データセットのハッシュを運ぶことを可能にし、ハッシュがブロックチェーン上に記憶されることを可能にする。これは、支払い指示データセットと、ひいては支払いのレコードとがブロックチェーン上に記憶されることを意味する。これは、支払いのレコードがブロックチェーンの不変性の恩恵を受けることを意味する。

【0229】

上述の例と同様に、データキャリアの各々は、異なるdataDigestおよび/または異なるstreamDigestを保持する場合がある。

【0230】

それから、ブロックチェーントランザクション706は、トランザクションならびに(GBPとEURとの両方に関する)HSBCによって提供されるアカウントとのユーザの対応が正しく、ユーザ、すなわち、AliceおよびBobに対応するかどうかを確かめるためにチェックされてよい。これが、ステップS514である。

【0231】

支払い処理リソース106は、(ステップS516において)イベントストリーム、すなわち、Alice、Bob、Revolut、およびHSBCに関するイベントストリームにデータを付け加えるための基礎としてブロックチェーントランザクション606が用いられ得ることを確認する通知をイベントストリームリソース110に発行する。

【0232】

この例において、Alice、Bob、および(GBPとEURとの両方に関する)HSBCは、それぞれ、自分のイベントストリームを持っているが、持っていない場合は、イベントストリームが初期化されてよい。つまり、Aliceは、イベントストリーム(E-Alice)を有し、Bobは、イベントストリーム(E-Bob)を有し、HSBCは、両方の通貨に関するイベントストリーム、すなわち、(E-HSBC-GBP)および(E-HSBC-EUR)を有する。

【0233】

支払い処理リソース106は、ランデブートランザクション706を用いて、ブロックチェーントランザクション706のデータキャリアに含まれる支払い指示メタデータのハッシュを含むエントリをそれらのイベントストリームの各々に付け加えることによって、支払いをイベントストリームE-Alice、E-Bob、E-HSBC-GBP、およびE-HSBC-EURと同期する。これが、ステップS518である。つまり、データ出力712aがAliceに対応する場合、データ出力712aは、ハッシュされ、Aliceのイベントストリームに追加される。これは、図5cに概略的に示される。各エントリは、そのエントリまでのストリームに含まれるデータのハッシュされたダイジェストを含む。ストリームのそのようなハッシュされたダイジェストは、ストリームにエントリとともに記憶される。

【0234】

次に、支払い処理リソース106は、イベントストリームの各々に追加されたエントリの識別子を生成する。これが、ステップS520である。その他の例と同様に、識別子は、英数字であってよく、または支払い指示メタデータのハッシュに基づいて生成される数字であってよい。たとえば、支払い指示メタデータのハッシュがSHA256暗号によって生成される場合、識別子は、支払い指示メタデータのハッシュにさらなるSHA256暗号を適用することによって生成されてよい。つまり、識別子は、支払い指示メタデータのハッシュのハッシュであってよい。

【0235】

そして、支払い処理リソース106は、識別子を、支払い指示メタデータのコピーと一緒に支払いデータストア124に記憶する。これは、要求に応じた、AliceとBobとの間の支払いの検証を可能にする。

【0236】

以降、図6aおよび図6bを参照して、Aliceが支払い処理リソース106を用いてBobに支払いを送信する例示的なシナリオを説明する。支払いは、ある量の金に関する場合がある。ある量の金は、資産の一例であり、その譲渡およびその支払いが、下で説明される方法によって記録される。

【0237】

ステップS600において、Aliceは、Bobに連絡を取って、Aliceが49.20GBPと引き換えに1gの金を獲得したいことをBobに知らせる。ステップS602において、BobはAliceに価格、すなわち、49.20GBPを知らせる。AliceとBobとの両方は、たとえば、Ynysmaerdy, Pontyclun CF72 8YT(royalmint.com)に住所を持つ英国の王立造幣局などの金の発行者にアカウントを登録済みである。これは、下で説明されるように、AliceおよびBobが合法的で記録可能な方法で金を売買することを可能にする。

【0238】

それから、Aliceは、第1のコンピューティングデバイス102を用いて、1gの金に49.20GBPを支払うというBobとのAliceの合意を支払い処理リソース106に示す。第1のコンピューティングデバイス102は、ステップS200からS214に従ってAliceによって作成されたアカウントを用いて支払いプロセスを開始するためにAPI 108にアクセスする。金は、第1のコンピューティングデバイスがAPI 108にアクセスして支払いプロセスを開始するときに、第1のコンピューティングデバイス102によって特定される。これは、支払い処理リソース106が金に関するものとして送金を特定することを可能にする。金は、英数字の識別子を用いて、数値のコードによって、または任意のその他の好適な識別子によって特定され得る。これが、ステップS606である。デバイス102からAPI 108への要求は、AliceがBobに支払いたい金額を示す。デバイス102からの要求は、Aliceがそこから支払いたいアカウントと、Aliceが支払いたい通貨と、Aliceが支払いたい相手、すなわち、Bobとをさらに示す。AliceがBobに支払いたい金額、Bobの識別情報、Aliceがそこから支払いたいアカウントの識別情報、およびAliceが支払いたい通貨は、ステップS608において支払い処理リソース106に送信される支払いメタデータのセットを形成する。

【0239】

つまり、支払い処理リソース106に対して、資産がGBPであるものとして特定され、銀行も特定される。

【0240】

支払い処理リソース106は、Aliceから支払いメタデータを受信すると、ステップS608においてAliceが提供したメタデータに基づいて、Bobのアカウントからメタデータを取り出す。これが、ステップS610である。支払い処理リソース106は、Bobのアカウントが関連する通貨、すなわち、スターリングポンド(GBP)および金の発行者のアカウント、すなわち、王立造幣局をBobのアカウントから取り出す。

【0241】

次に、支払い処理リソース106は、ステップS612において、Aliceから受信された支払いメタデータおよびBobのアカウントから取り出された情報を用いて、支払い指示データセットを生成する。

【0242】

この例において、Bobの銀行アカウントの提供者は「HSBC」(すなわち、Aliceと同じ)であり、通貨はGBPと特定され、支払いの額(すなわち、Bobによって受け取られている金額)は49.20GBPであり、アカウントの識別情報は<Bob:HSBC>によって与えられ、ユーザは「kyc」値によってBobと特定され、行為者は支払いの受取人、すなわち、支払いを受ける個人と特定される。これは、支払い指示データセットのさらなる部分を形成する。支払い指示データセットは、任意で、署名<Bob_sig>を用いてBobによって署名された条項および条件のバージョンも含む場合がある。

【0243】

支払い指示データセットのさらなる部分が、金のトランザクションの詳細によって形成される。支払い処理リソース106は、Bobの金アカウントの発行者、すなわち、王立造幣局におけるBobの金アカウントへのアクセスを要求する。支払い処理リソース106は、アクセスが許可されることを可能にするためのBobの署名の要求を与えられる。そのとき、支払い処理リソース106は、Bobに対応するユーザプロファイルからBobの暗号署名を取り出すか、またはBobの金アカウントに対応する署名の、Bobへの個別の要求によってBobの暗号署名を取り出すかのどちらかである場合がある。署名は、Bobの「HSBC」アカウントのBobの署名と同じである場合がありまたは異なる場合がある。Bobの署名は、特に、大量の金または金に関連する商取引のために必要とされる場合があり、条項および条件のセットが含まれる場合があり、それらの条項および条件に対するAliceまたはBobによる証明の必要性がある場合がある。

【0244】

支払い指示データセットの別の部分は、Aliceの詳細によって形成される。すなわち、Aliceのアカウントの提供者は「hsbc.com」であり、通貨はGBPと特定され、Bobに送金されている支払いの額は49.20GBPであり(すなわち、Bobに支払われるAliceからの49.20GBPの引き落としであり、したがって、支払い指示データセットにおいては-49.20と表現される)、アカウントの識別情報は<Alice:HSBC>によって与えられ、ユーザは「kyc」値によってAliceと特定され、Aliceによって署名された条項および条件はAliceによって与えられるURLにおいて提供される署名されたドキュメントおよび前記ドキュメントのハッシュによって特定される。行為者は、支払いの送金人、すなわち、支払いを行う個人として特定される。

【0245】

支払い処理リソース106は、発行者、すなわち、王立造幣局におけるAliceの金アカウントへのアクセスも要求する。支払い処理リソース106は、アクセスが許可されることを可能にするためのAliceの署名の要求を与えられる。

【0246】

それから、ステップS614において、支払い指示データセットへのAliceの署名の要求とともに、メッセージが第1のコンピューティングデバイス102に送信される。そして、Aliceは、Bobへの49.20GBPの支払いを承認するために、ステップS516において自分の暗号署名を提供する。そのとき、署名は、支払い処理リソース120によって支払い指示データセットに適用される。Aliceの金アカウントに対応する署名は、「hsbc.com」のAliceのアカウントに関する署名とは異なる署名である場合がある。署名が異なる場合、Aliceは、ステップS616において両方の署名を提供する。支払い処理リソース106は、代替的に、Aliceの金アカウントの署名に既にアクセスした可能性がある。つまり、支払い処理リソース106がAliceによって信頼されている場合、Aliceからの署名の取り出しは任意である。

【0247】

次に、支払い処理リソース106は、Bobの金アカウントからAliceの金アカウントへの金の譲渡に対応するさらなるメタデータを生成する。メタデータは、AliceからBobへの支払いと、一方の金アカウントから他方の金アカウントへの譲渡を詳述する。

【0248】

それから、支払い処理リソース106は、ステップS618において、支払い指示データセットに支払いプロトコル基準を適用する。支払い処理リソース106は、ステップS620において、支払いプロトコルモジュール120にアクセスする。

【0249】

支払いプロトコルモジュール120は、まず、支払い指示データセットが、金額が一致しているという点でゼロサム規則を遵守すること、すなわち、Aliceのアカウントから引き出されている額がBobのアカウントに支払われている額と等しいことをチェックする。これが、ステップS622である。Aliceのアカウントから49.20GBPが引き出されており、Bobのアカウントに49.20GBPが支払われているので、ゼロサム規則は遵守される。金額の不一致は、たとえば、異なる通貨に起因する可能性がある。つまり、支払いプロトコルモジュール120は、資産の識別情報および銀行の識別情報が一致していると判定する(それは、上記のテンプレートに従って、Alice_HSBC:GBPがBob_HSBC:GBPと釣り合い、Alice_MINT:GOLDがBob_MINT:GOLDと釣り合うからである)。

【0250】

代替的または追加的に、BobがHSBCのGBPアカウントのみを有し、AliceがRevolutのEURアカウントのみを有する場合、不一致、すなわち、異なる資産の識別情報および異なる資産レジストリが存在する可能性がある(つまり、Bob_HSBC:GBPへの支払いはAlice_REVOLUT:EURから行われ得ない)。そのとき、支払いプロトコルモジュール120は、トランザクションの仲介部分に対応するさらなるメタデータを生成する。このメタデータは、通貨および銀行が異なり、それが資産の識別情報および銀行の不釣り合いを引き起こす例において上述されているのと同様に、通貨および銀行の不一致を解決するために金融ブローカー(ここでは第1のブローカーとして挙げられる)が取引において果たす役割に対応する。この例において、ブローカーは、HSBCのGBPアカウントおよびRevolutのEURアカウントを有する。支払いプロトコルモジュール120は、それらの2つのアカウントに対応する暗号署名にアクセスする。メタデータは、銀行の識別情報および資産の種類を釣り合わせるために、Bobの金アカウントからAliceの金アカウントへの合意された量の金の譲渡と、AliceのEURのRevolutアカウント(すなわち、Alice_REVOLUT:EUR)からブローカーのRevolutのEURアカウント(すなわち、Broker_Revolut:EUR)へのEURの支払いと、ブローカーのGBPアカウント(すなわち、Broker_Revolut:GBP)からBob(Bob_HSBC:GBP)への対応する額のGBPの支払いとを詳述する。このさらなるメタデータも、それらのアカウントに対応する暗号署名によって署名される。

【0251】

任意でまたは追加的に、第1のブローカーがRevolutアカウント内のみの、すなわち、異なる銀行間でないEURからGBPへの両替を提供するだけであった場合、支払いプロトコルモジュール120は、第1のブローカーに加えて第2のブローカーによって担われる役目に対応するさらなるメタデータを生成する必要がある。
このメタデータは、Bobの金アカウント(Bob_MINT:GOLD)からAliceの金アカウント(Alice_MINT:GOLD)への合意された量の金の譲渡と、AliceのEURアカウント(Alice_REVOLUT:GOLD)から第1のブローカーによって保有されるEURアカウント(すなわち、RevolutのEURアカウント)への支払いと、第1のブローカーのGBPアカウント(すなわち、Broker1_REVOLUT:GBPと特定されるRevolutのGBPアカウント)から第2のブローカーのHSBCのGBPアカウントへの支払いと、第2のブローカーのGBPアカウントからBobのHSBCのGBPアカウントへの支払いとを詳述する。つまり、支払いプロトコルモジュール120は、ステップS622においてチェックされた支払い指示メタデータの側面の間の不一致(または対応の欠如)に対処するためのメタデータのセットを構築するために用いられ得る。

【0252】

それから、支払いプロトコルモジュール120は、AliceからBobに送金されている額がAliceの残高を何らかの最小値未満にしないことをチェックする。これが、ステップS624である。つまり、AliceはBobから獲得している金にお金を使いすぎているのか?Aliceがお金を使いすぎている場合、すなわち、Aliceの残高が最小値を未満になる場合、支払いプロトコルモジュール120は、Aliceにエラーメッセージを発行して、Aliceが使いたいお金を使うことができないことをAliceに知らせる。さらに言えば、与信枠が用いられている場合、最小値はマイナスになることがあり得る。支払いプロトコルモジュール120は、再び開始する指示が与えられるまで、すなわち、Aliceがより多くの資金を自分のアカウントに預け入れたか、またはAliceの最低残高が変更されたとき、ステップS520に戻る。

【0253】

次に、支払いプロトコルモジュール120は、発行者に対応するデータ中でフィールドをチェックすることによって、支払いに関連するデータがトランザクションの2人の関係者間で一致しているかどうかをチェックする。これが、ステップS626である。アカウントを提供する関係者が同一であり、資産の識別情報が同一であるか、または資産識別子もしくは資産レジストリが一致していない資産の譲渡において不一致を解決する際にブローカーが果たすことができる役割に対応するさらなるメタデータを支払いプロトコルモジュール120が導入することによって一致の欠如が解決されたので、データは2人の関係者間で一致している。譲渡が金に関するとき、BobからAliceに譲渡されている金の量は、Aliceのアカウントに追加されている金の量を補完しなければならない。

【0254】

つまり、譲渡が可能にされるためには、譲渡の両側で特定される銀行および資産識別子の間に一致がなければならないという要件がある。GBPと金との両方に関してゼロサム規則が満たされる要件もある。

【0255】

支払い処理モジュール120は、各署名のハッシュを生成し、ハッシュをステップS200からS214において生成されたレコードに記憶されたものと比較することによって、AliceおよびBobの暗号署名を確認する。これが、ステップS628である。これは、AliceおよびBobのアイデンティティも確認する。代替的または追加的に、プライベート/公開暗号鍵ペアに基づく標準的なPKI技術も、各署名を確認するために用いられてよい。これらの技術は、クライアントのアイデンティティを検証するためにも用いられ得る。支払い処理モジュール120は、同様の技術を用いてAliceおよびBobの金アカウントの署名も確認する。また、支払い処理モジュール120は、Bobのアカウントに対するチェックを実行して、必要な量の金がBobの名義で記録され、したがって、それがBobからAliceに譲渡され得ると判定する。ブローカーも用いられた場合、仲介アカウントに対応する暗号署名も確認される。

【0256】

ステップS622、S624、S626、およびS628の充足は、支払いプロトコルによって規定された基準が満たされたことを意味し、したがって、支払い処理リソース106は、支払い指示データセットに従って、AliceからBobへの49.20GBPの支払いが行われることを可能にする。そしてまた、金の譲渡は、金アカウントの発行者によって記録され得る。

【0257】

次に、支払い処理リソース106は、ステップS630において、AliceおよびBobの各々に関して、ブロックチェーン112からブロックチェーントランザクションを取り出す。Aliceのブロックチェーントランザクション802は、ダスト出力(Tx0, Alice)を含み、Bobのブロックチェーントランザクション804は、ダスト出力(Tx0, Bob)を含む。ダスト出力は、AliceおよびBobに関連するイベントストリームに対応するダストチェーンから取り出される場合がある。支払い処理リソース106は、支払いに関わる金アカウント、すなわち、Royal Mint - AliceとRoyal Mint - Bobとの両方のブロックチェーントランザクションも取り出す。Royal Mint - Bobの取り出されたブロックチェーントランザクション808は、ダスト出力(Tx0, RYB)を含み、Royal Mint - Aliceの取り出されたブロックチェーントランザクション810は、ダスト出力(Tx0, RYA)を含む。ブローカーも関与している場合、ブローカーの各々に関してもブロックチェーン112からブロックチェーントランザクションが取り出されてよい。ダスト出力(Tx0, RYB)および(Tx0, RYA)は、AliceおよびBobの金アカウントに関連するイベントストリームに対応するダストチェーンから取り出される場合がある。

【0258】

追加の発行者によるランデブートランザクションの生成
そして、支払い処理リソース106は、ステップS530において取り出されたブロックチェーントランザクションからのそれぞれのダスト出力を使用するAliceおよびBobの各々のダスト入力を含む新しいランデブーブロックチェーントランザクション806を生成する。これは、図7に示される。ランデブーブロックチェーントランザクション806は、ブロックチェーントランザクション808および810から、すなわち、AliceおよびBobの金アカウントに関して取り出された対応する出力を使用するダスト入力をさらに含む。

【0259】

取り出されたブロックチェーントランザクションの各々は、OP_RETURNスクリプト、すなわち、使用不可能であることが証明可能な出力に関連するデータキャリアも含む場合がある。

【0260】

Aliceのダスト出力を使用するダスト入力は、Tx1, Aliceと表記され、Bobのダスト出力を使用するダスト入力は、Tx1, Bobと表記される。新しいランデブートランザクションは、それぞれ(Tx1, RYA)および(Tx1, RYB)と表記される、AliceおよびBobが保有する金アカウントに対応するダスト入力も含む。ランデブーブロックチェーントランザクション806は、ステップS632において生成される。

【0261】

ランデブーブロックチェーントランザクション806への資金は、支払い処理リソース106によって追加され、支払い処理リソース106に払い戻される。これは、ランデブートランザクション806が有効化のためにブロックチェーン112に送信される場合、ランデブートランザクション806の有効化後に任意のマイナーの手数料を引かれる場合がある。

【0262】

ランデブーブロックチェーントランザクション806は、Tx1, AliceおよびTx1, Bobをそれぞれ使用するさらなるダスト出力を含む。ランデブーブロックチェーントランザクション806は、2つの金アカウントに関してブロックチェーンから取り出されたダスト入力に対応するダスト出力も含む。それがランデブートランザクションであるとき、Alice、Bob、および2つの金アカウントにそれぞれ対応する入力/出力ペアのインデックスは、たとえば、Tx1, Aliceの入力インデックスが番号1として割り振られる場合があり、対応するダスト出力の出力インデックスが出力インデックス番号1として割り振られるという点で同一である。

【0263】

また、支払い処理リソース106は、Alice、Bob、および2つの金アカウントに関してブロックチェーントランザクション806に使用不可能であることが証明可能な出力を追加する。これらは、データキャリア812a、812b、812c、および812dとそれぞれ表記される。

【0264】

トランザクションに関与するブローカーに対応する使用不可能であることが証明可能な出力も、追加される場合がある。それらの使用不可能であることが証明可能な出力は、ブローカーのデータキャリアに対応する。

【0265】

その他の例と同様に、データキャリアの各々は、異なるdataDigestおよび/またはstreamDigestを保持する場合がある。streamDigestは、その他の例と同様に、ソルト化される場合がある。

【0266】

また、ブロックチェーントランザクション806は、イベントストリームの基礎として既に使用されていないダストを用いて生成される場合がある。この「新しいダスト」は、その他の例と同様にブロックチェーントランザクション806を生成するために、英国特許出願第2102217.3号に記載されているように、HD鍵チェーンと組み合わせて用いられる。

【0267】

その他の例と同様に、それぞれデータキャリア内に保持されるデータペイロード(すなわち、支払い指示メタデータのハッシュ)が、トランザクションの使用不可能なOP_RETURN出力に保持され、これは、データペイロードが、その後、使用不可能な出力としてブロックチェーンに記憶され得ることを意味する。第1の例と同様に、トランザクションの使用不可能なOP_RETURN出力に保持されるデータキャリア内に保持されるデータペイロード(すなわち、支払い指示メタデータのハッシュ)を保持することは、データペイロードが、その後、使用不可能な出力としてブロックチェーンに記憶され得ることを意味する。

【0268】

データキャリア内のデータは、ステップS600からS628において支払い処理リソースによって生成された支払い指示データセットのハッシュを含む。データキャリア内のデータは、それが同一の支払い指示データセットに基づくという点で同一である場合がある。代替的または追加的に、各データキャリアのそれぞれのハッシュは、データが異なるので異なる場合がある。たとえば、Aliceのデータは、それがAliceのアカウントの活動に関連し、Bobのアカウントの活動に関連しないのでBobのデータとは異なる。これが、ステップS634である。使用不可能であることが証明可能な出力(provably unspendable output)は、ランデブートランザクション806がトランザクション内で支払い指示データセットのハッシュを運ぶことを可能にし、ハッシュがブロックチェーン上に記憶されることを可能にする。これは、支払い指示データセットと、ひいては支払いのレコードとがブロックチェーン上に記憶されることを意味する。これは、支払いのレコードがブロックチェーンの不変性の恩恵を受けることを意味する。金の譲渡の場合、これは、ブロックチェーンが一方の金アカウントから他方の金アカウントへのトランザクションのレコードをサポートするために用いられ得ることを意味する。また、ブロックチェーンおよび本明細書に記載のシステムによって提供される匿名性は、金の譲渡の機密性を維持され得ることを意味する。

【0269】

それから、ブロックチェーントランザクション806は、トランザクションならびにAliceおよびBobによって所有されるものに対応する金アカウントとのユーザの対応が正しいかどうかを確かめるためにチェックされてよい。これが、ステップS636である。

【0270】

支払い処理リソース106は、ステップS638において、イベントストリーム、すなわち、Alice、Bob、および2つの金アカウントに関するイベントストリームにデータを付け加えるための基礎としてブロックチェーントランザクション806が用いられ得ることを確認する通知をイベントストリームリソース110に発行する。

【0271】

支払い処理リソース106は、ランデブートランザクション806を用いて、ブロックチェーントランザクション806のそれぞれデータキャリアに含まれる支払い指示メタデータのハッシュを含むエントリをそれらのイベントストリームの各々に付け加えることによって、支払いをイベントストリームE-Alice、E-Bob、E-RYA(すなわち、Aliceの金アカウント、およびE-RYB(すなわち、Bobの金アカウント)と同期する。つまり、データ出力812aに対応するハッシュが、E-Aliceに追加されてよく、データ出力812bに対応するハッシュが、E-Bobに追加されてよい。これが、ステップS640である。これは、図8に概略的に示される。また、金の譲渡に関与したブローカーに対応するイベントストリームにも、エントリが付け加えられ得る。

【0272】

次に、支払い処理リソース106は、イベントストリームの各々に追加されたエントリの識別子を生成する。これが、ステップS642である。識別子は、英数字であってよく、または支払い指示メタデータのハッシュに基づいて生成される数字であってよい。たとえば、支払い指示メタデータのハッシュがSHA256暗号によって生成される場合、識別子は、支払い指示メタデータのハッシュにさらなるSHA256暗号を適用することによって生成されてよい。つまり、識別子は、支払い指示メタデータのハッシュのハッシュであってよい。

【0273】

そして、支払い処理リソース106は、識別子を、支払い指示メタデータのコピーと一緒に支払いデータストア124に記憶する。

【0274】

上述の態様および実施形態は、本開示を限定するのではなく、例示し、当業者は、添付の請求項によって定義される本開示の範囲を逸脱することなく多くの代替的な実施形態を設計することができることに留意されたい。請求項において、括弧に入れられた参照符号は、特許請求の範囲を限定するものと解釈されないものとする。単語「～を含む(comprising)」および「～を含む(comprises)」などは、任意の請求項または本明細書全体において列挙された要素またはステップ以外の要素またはステップの存在を除外しない。本明細書において、「～を含む(comprise)」は、「～を含む(includes)かまたは～からなる」を意味し、「～を含む(comprising)」は、「～を含む(including)かまたは～からなる(consisting of)」を意味する。ある要素の単数形の言及は、そのような要素の複数形の言及を除外せず、その逆も同様である。本開示は、いくつかの異なる要素を含むハードウェアによって、および適切にプログラミングされたコンピュータによって実施されてよい。いくつかの手段を列挙するデバイスの請求項においては、これらの手段のうちのいくつかが、1つの同じハードウェアによって具現化される場合がある。単に特定の手段が互いに異なる従属請求項に記載されているという事実は、これらの手段の組合せが有利に用いられ得ないことを示さない。

【符号の説明】

【0275】

102 第1のコンピューティングデバイス
104 第2のコンピューティングデバイス
105 クライアントアプリケーション
106 支払い処理リソース
112 ブロックチェーン
120 支払いプロトコルモジュール
122 鍵ストレージモジュール
124 支払いデータストア

【図1a】

【図1b】

【図1c】

【図2】

【図3a】

【図3b】

【図3c】

【図3d】

【図3e】

【図4a】

【図4b】

【図4c】

【図5a】

【図5b】

【図5c】

【図6a】

【図6b】

【図7】

【図8】

【国際調査報告】