知財求人 - 知財ポータルサイト「IP Force」
特表2024-523071コミットメントのユーザチェーンにランデブーブロックチェーントランザクションを付け加えるための方法およびシステム
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2024-06-28
(54)【発明の名称】コミットメントのユーザチェーンにランデブーブロックチェーントランザクションを付け加えるための方法およびシステム
(51)【国際特許分類】
G06Q 20/08 20120101AFI20240621BHJP
H04L 9/32 20060101ALI20240621BHJP
【ＦＩ】
G06Q20/08
H04L9/32 200Z
【審査請求】未請求
【予備審査請求】未請求
(21)【出願番号】P 2023533371
(86)(22)【出願日】2022-06-22
(85)【翻訳文提出日】2023-08-25
(86)【国際出願番号】 EP2022067065
(87)【国際公開番号】W WO2022268908
(87)【国際公開日】2022-12-29
(31)【優先権主張番号】2109064.2
(32)【優先日】2021-06-24
(33)【優先権主張国・地域又は機関】GB
(31)【優先権主張番号】2209173.0
(32)【優先日】2022-06-22
(33)【優先権主張国・地域又は機関】GB
(81)【指定国・地域】
(71)【出願人】
【識別番号】318001991
【氏名又は名称】エヌチェーン ライセンシング アーゲー
(74)【代理人】
【識別番号】100108453
【弁理士】
【氏名又は名称】村山 靖彦
(74)【代理人】
【識別番号】100110364
【弁理士】
【氏名又は名称】実広 信哉
(74)【代理人】
【識別番号】100133400
【弁理士】
【氏名又は名称】阿部 達彦
(72)【発明者】
【氏名】リッキー・チャールズ・ランド
(72)【発明者】
【氏名】アンドリュー・ジェームズ・ミー
(72)【発明者】
【氏名】ジャック・オーウェン・デイヴィーズ
(72)【発明者】
【氏名】ポール・クラーク
(72)【発明者】
【氏名】アレックス・ウッズ
【テーマコード（参考）】
5L020
【Ｆターム（参考）】
5L020AA21
(57)【要約】
資産の支払いがブロックチェーントランザクションを用いて記録され、トランザクションに関連する不変のログに基づいて検証される方法が、提供される。
【特許請求の範囲】
【請求項1】
少なくとも第1のユーザおよび第2のユーザを含む資産譲渡イベントを記録するコンピュータによって実装される方法であって、コンピューティングリソースによって実施され、指示データを受信するステップであって、
前記指示データが、要求された資産譲渡イベントに関連し、
前記指示データが、資産の送信者に関連するメタデータの第1のセット、および前記資産の少なくとも1人の受信者に関連するメタデータの第2のセットを含み、
前記送信者および前記受信者の各々が、資産レジストリに関連するアカウントにそれぞれ関連付けられる、ステップと、
前記資産の前記送信者をコミットメントの第1のチェーンに関連付け、前記資産の前記受信者をコミットメントの第2のチェーンに関連付けるステップであって、
コミットメントの各チェーンが、イベントストリームを複数のブロックチェーントランザクションに関連付ける、ステップと、
譲渡プロトコルに従って、前記送信者から前記少なくとも1人の受信者への前記資産の譲渡が行われ得るかどうかを判定するために、メタデータの前記第1のセットとメタデータの前記第2のセットとを比較するステップであって、
前記譲渡プロトコルが、資産譲渡イベントが行われることを可能にする少なくとも1つの基準を定義する、ステップと、
前記譲渡プロトコルに従ったメタデータのそれぞれのセットの間の比較に基づいて、メタデータの前記それぞれのセットの間の対応の1つまたは複数のアイテムを決定するステップと、
前記送信者および前記受信者の各々に関して、少なくとも1つの入力および少なくとも1つの出力を含むランデブーブロックチェーントランザクションを生成するステップであって、
前記少なくとも1つの出力が、メタデータの前記第1のセットおよびメタデータの前記第2のセットに関連するデータを含み、
メタデータの前記第1のセットおよびメタデータの前記第2のセットに関連する前記データが、将来のブロックチェーントランザクションに関するデータに基づく、ステップと、
前記ランデブーブロックチェーントランザクションをコミットメントの前記第1のチェーンおよびコミットメントの前記第2のチェーンにそれぞれ付け加えるステップと、
前記ランデブーブロックチェーントランザクションをそれぞれのイベントストリームのそれぞれのエントリに関連付けるステップと
を含む、方法。
【請求項2】
前記ランデブーブロックチェーントランザクションが、ブロックチェーンに送信される請求項1に記載の方法。
【請求項3】
前記送信者に対応する前記出力が、メタデータの前記第1のセットに基づいて生成されたメタデータを含むデータペイロードを含み、前記受信者に対応する前記出力が、メタデータの前記第2のセットに基づいて生成されたメタデータを含むデータペイロードを含む請求項1に記載の方法。
【請求項4】
前記メタデータが、データダイジェストおよび状態ダイジェストを含む請求項3に記載の方法。
【請求項5】
前記データダイジェストが、メタデータの前記第1のセットおよびメタデータの前記第2のセットのハッシュに基づいて生成される請求項4に記載の方法。
【請求項6】
前記データダイジェストが、メタデータの前記第1のセットとメタデータの前記第2のセットとの組合せおよびソルトに基づいて生成される請求項5に記載の方法。
【請求項7】
メタデータの前記第1のセットとメタデータの前記第2のセットとの前記組合せが、メタデータの前記第1のセットとメタデータの前記第2のセットとの組合せの二重ハッシュを取得することと、
メタデータの前記第1のセットとメタデータの前記第2のセットとの前記組合せの前記二重ハッシュを前記ソルトの二重ハッシュと連結することと
を含む請求項6に記載の方法。
【請求項8】
前記状態ダイジェストが、前記データダイジェストおよび将来のトランザクションに基づいて生成される請求項4に記載の方法。
【請求項9】
前記状態ダイジェストが、さらに、前のトランザクションに基づいて生成される請求項4に記載の方法。
【請求項10】
状態ダイジェストが、マークル木のルートである請求項4から8のいずれか一項に記載の方法。
【請求項11】
メタデータの前記それぞれのセットの間の対応の前記1つまたは複数のアイテムを決定するステップが、i)メタデータの前記それぞれのセット内で特定された支払いの通貨、
ii)前記送信者に対応するアカウントから支払われている通貨の量、および前記受信者に対応するアカウントから要求された通貨の量、ならびに
iii)前記送信者のアカウントおよび前記受信者のアカウントに関連する前記資産レジストリの識別子
のうちの少なくとも1つの間の対応を決定することを含む請求項1から10のいずれか一項に記載の方法。
【請求項12】
前記コンピューティングリソースが、前記譲渡プロトコルに従って、前記譲渡が行われ得ないと判定し、
前記譲渡プロトコルとの一致の欠如を解決するためにメタデータのさらなるセットを生成する請求項1から11のいずれか一項に記載の方法。
【請求項13】
メタデータの前記さらなるセットの生成が、第1の通貨と第2の通貨との間の変換を可能にするメタデータを生成することを含む請求項12に記載の方法。
【請求項14】
メタデータの前記さらなるセットの生成が、別の資産レジストリに所与の資産の譲渡を記録するために1つの資産レジストリのためのメタデータを生成することを含む請求項12または請求項13に記載の方法。
【請求項15】
請求項1から14のいずれか一項に記載の方法を実装するように構成されたシステム。
【発明の詳細な説明】
【技術分野】
【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号
【特許文献3】英国特許出願第2204293.1号
【発明の概要】
【課題を解決するための手段】
【0012】
本明細書全体を通じて、単語「～を含む(comprise)」、または「～を含む(includes)」、「～を含む(comprises)」、もしくは「～を含んでいる(comprising)」などの変化形は、記載の要素、完全体(integer)、ステップ、または要素、完全体、もしくはステップのグループの包含を示唆するが、いかなるその他の要素、完全体、ステップ、または要素、完全体、もしくはステップのグループの除外も示唆しないと理解される。
【0013】
本開示は、たとえば、商品と引き換えの通貨の支払いである可能性がある支払いイベントの記録を可能にすることができる方法およびシステムに関する。
【0014】
一部の実施形態においては、少なくとも第1のユーザおよび第2のユーザを含む資産譲渡イベントを記録するコンピュータによって実装される方法が提供される。資産は、ブロックチェーントークンを用いた物理的資産の表現と理解されてよい。資産は、ブロックチェーントークンを用いて表されている貴金属である場合がある。資産は、トークン化された資産である場合がある。トークン化された資産は、ある量の通貨である場合がある。資産は、製品またはサービスである場合がある。資産譲渡イベントは、製品、品物、またはサービスに対する通貨の支払いである場合がある。一部の実施形態は、通貨の支払いが記録されることを可能にする場合がある。通貨の支払いは、任意の通貨もしくは通貨の種類であってよく、商品もしくはサービスに対するものであってよく、または異なる通貨もしくは通貨の種類との両替であってよい。一部の実施形態は、コンピューティングリソースによって実施されてよい。コンピューティングリソースは、ハードウェアまたはソフトウェアによって実装される場合がある。コンピューティングリソースは、局所的にかまたは広い地理的エリアにかのどちらかに分散される場合がある複数の処理リソースを含んでよい。方法は、指示データを受信するステップであって、指示データが、要求された資産譲渡イベントに関連し、指示データが、資産譲渡の送信者に関連するメタデータの第1のセット、および資産譲渡の少なくとも1人の受信者に関連するメタデータの第2のセットを含む、ステップを含んでよい。メタデータは、たとえば、支払いの通貨、アカウント、譲渡を受け取るようにまたは譲渡を行うように指定された個人、支払いの条項および条件、ならびに支払いを承認する公開鍵またはデジタル署名の証拠のうちの少なくとも1つを特定する場合がある。送信者および受信者は、資産レジストリ(asset registry)に関連するアカウントにそれぞれ関連付けられてよい。
【0015】
方法は、資産の送信者をコミットメントの第1のチェーンに関連付け、資産の受信者をコミットメントの第2のチェーンに関連付けるステップであって、コミットメントの各チェーンが、イベントストリームを複数のブロックチェーントランザクションに関連付ける、ステップをさらに含んでよい。イベントストリームは、「オフチェーン」であってよい、すなわち、ブロックチェーン上になくてよい。複数のブロックチェーントランザクションとイベントストリームとの間の関連付けは、コミットメントがコミットメントのチェーンに追加されるたびに、エントリがイベントストリームに付け加えられることを意味する場合がある。イベントストリームに付け加えられるエントリは、コミットメントからのメタデータの一部を含む場合がある。メタデータは、コミットメントのデータペイロード内に含まれてよく、メタデータの少なくとも一部は、イベントストリームのエントリ内に記憶されてよい。
【0016】
イベントストリームは、ブロックチェーントランザクションに記録されたデータが時間的に順序付けられたログに追加されてよい、ブロックチェーンに支援された追加専用ログを含んでよい。つまり、イベントストリームは、ブロックチェーン上に記録されたデータを時間順に、すなわち、それらのデータがブロックチェーン上に現れるとおりにロギングしてよい。これは、ブロックチェーン上のブロック内のトランザクションの順序が、概して、イベントストリームにロギングされた対応するイベントの対応するインデックスによって反映されることを意味する。しかし、これは、そうであるとは限らない。2つの同時に起こるイベントは、イベントの順序がブロック内のトランザクションの順序に反映されないことを意味する。イベントストリーム上の、インデックス、たとえば、N+1を有するイベントがブロックBに記録され、一方、インデックスNを有する(すなわち、イベントストリーム上で他方のイベントの前に記録された)イベントがブロックB+1に記録される場合があることがあり得る。イベントストリームは、任意の好適なデータ構造を用いて実装され得る。イベントストリームは、シーケンスに記憶される一連のエントリを含んでよく、シーケンス内の各エントリは、単調に増加する番号によってシーケンス内で参照される。つまり、イベントストリームの最初のエントリは、エントリ1であり、2番目のエントリは、エントリ2であり、以下同様である。基礎となるブロックチェーンの利用は、イベントストリームへのすべての変更が検出可能であることを意味し、イベントストリームの個々のエントリが書き込まれてから変更されておらず、以前は連続していたエントリの間にエントリが挿入されておらず、エントリが削除されておらず、エントリが順序を変更されていないことを保証する。
【0017】
悪意のある者がシステムによって検出されることなくイベントをイベントストリームに付け加えることは可能である場合があるが、イベントストリームを初期化したユーザは、そのユーザがイベントストリームに付け加えるあらゆるイベントに署名してよく、したがって、悪意のある者がイベントを付け加えようとする事実は、検出可能である。
【0018】
それぞれの送信者または受信者とのコミットメントの第1のチェーンおよび第2のチェーンのどちらかまたは両方の関連付けは、コミットメントのチェーンの初期化と、コミットメントのチェーンをそれぞれの送信者または受信者に関連付けることとを含んでよい。方法は、その他のエンティティをコミットメントのそれぞれのチェーンに関連付けるステップをさらに含んでよい。その他のエンティティは、資産レジストリに関連するレジストリマネージャ、または別のエンティティの署名者(signatory)である場合がある。
【0019】
資産レジストリは、個人または組織によって所有される資産のレジストリのことである。資産の例は、それぞれの個人または組織によって所有または制御される任意のリソースを含む。資産の例は、現金または金銭的価値のある他の任意のものを含む。資産レジストリの例は、たとえば、特定の通貨でトランザクションに資金を供給するために用いられ得るアカウントに対する現金預金を記録する銀行である場合がある。別の例は、個人によって所有される金預託の記録簿である金アカウントである場合がある。資産レジストリは、資産レジストリによって管理されるアカウントに関連する資産の発行者に関連付けられる。例示的な発行者は、王立造幣局である可能性がある。
【0020】
方法は、譲渡プロトコル(transfer protocol)に従って、送信者から少なくとも1人の受信者への資産の譲渡が行われ得るかどうかを判定するために、メタデータの第1のセットとメタデータの第2のセットとを比較するステップであって、譲渡プロトコルが、資産譲渡イベントが行われることを可能にする少なくとも1つの基準を定義する、ステップをさらに含んでよい。
【0021】
譲渡プロトコルは、資産譲渡イベントが行われることを可能にするために満たされる必要がある少なくとも1つの基準を定義してよい。少なくとも1つの基準は、送信者および受信者が同じ資産レジストリに関連するアカウントに関連付けられることを必要とする場合がある。たとえば、少なくとも1つの基準は、アカウントが同じ銀行のものであることを必要とする場合がある。少なくとも1つの基準は、アカウントが同じ種類の資産に関連付けられることを必要とする場合がある。たとえば、そのような基準は、両方のアカウントがスターリングポンド(GBP)建てであることを必要とする場合がある。
【0022】
譲渡プロトコルに従ったメタデータのそれぞれのセットの間の比較に基づいて、方法は、メタデータのそれぞれのセットの間の1つまたは複数の対応を決定するステップをさらに含んでよい。
【0023】
コミットメントは、自身をその他のトランザクションに関連付けるブロックチェーントランザクションである。それらのトランザクションは、必ずしもブロックチェーン上の同じブロックからのものでない場合がある。
【0024】
本明細書において説明されるように、コミットメントのチェーンは、各トランザクションが前のトランザクションへの参照および次のトランザクションへの参照を含む(またはそれらの参照に基づくデータを含む)という点で複数のトランザクションを含む。
【0025】
方法は、送信者および受信者の各々に関して、少なくとも1つの入力および少なくとも1つの出力を含むランデブーブロックチェーントランザクション(rendezvous blockchain transaction)を生成するステップであって、少なくとも1つの出力が、メタデータの第1のセットおよびメタデータの第2のセットに関連する出力データを含み、メタデータに関連するデータが、将来のトランザクションに関するデータにさらに基づく、ステップをさらに含んでよい。少なくとも1つの入力は、資産譲渡イベントに関連するその他のエンティティに関する入力に加えて、送信者および受信者の各々に関して1つの入力を含んでよい。各入力は、それがランデブーブロックチェーントランザクション内に一致する入力インデックスおよび出力インデックスを有するという点で、出力に対応してよい。これは、入力・出力ペアを形成する。
【0026】
ランデブーブロックチェーントランザクションは、コミットメントの第1のチェーンおよび第2のチェーンにそれぞれ追加されてよい。つまり、ランデブーブロックチェーントランザクションは、コミットメントのチェーンの中のコミットメントを形成する。
【0027】
方法は、コミットメントのチェーンの次のコミットメントを形成するために、それぞれのランデブートランザクションが生成されたときに、コミットメントの第1のチェーンおよび第2のチェーンに関連するそれぞれのイベントストリームにエントリを付け加えるステップであって、エントリが、メタデータの第1のセットおよび第2のセットに関連するデータを含む、ステップをさらに含んでよい。
【0028】
方法は、ランデブーブロックチェーントランザクションをそれぞれのオフチェーンイベントストリームのそれぞれのエントリに関連付けるステップをさらに含んでよい。それぞれのエントリとのランデブーブロックチェーントランザクションの関連付けは、それぞれのオフチェーンイベントストリームにそれぞれのエントリを有するランデブートランザクションに関連するトランザクションの識別子をストレージ手段に記憶することを含んでよい。
【0029】
方法は、ランデブーブロックチェーントランザクションをコミットメントの第1のチェーンおよびコミットメントの第2のチェーンにそれぞれ付け加えるステップをさらに含んでよい。
【0030】
メタデータの第1のセットおよび第2のセットは、資産譲渡イベントの支払い指示データセットを共同で形成してよい。
【0031】
上記の方法は、ブロックチェーンをイベントストリームに関連付け、将来のトランザクションデータを用いて、各トランザクションが次のトランザクションにコミットするトランザクションのチェーンを形成するブロックチェーントランザクションを生成するコミットメントのチェーンを用いて、資産譲渡イベントが記録されることを可能にする。これは、資産譲渡イベントを記録する、安全で、あまり複雑でなく、ユーザフレンドリーで、効率的で、堅牢な手法を提供する。これは、送信者または受信者などのユーザが、資産譲渡イベントの自分の履歴に迅速で容易にアクセスし、インタラクションすることができるようになることを可能にする。
【0032】
本開示の態様および実施形態が、単に例として、添付の図面を参照して以降で説明される。
【図面の簡単な説明】
【0033】
【図1a】実施形態に係るシステムを示す図である。
【図1b】ブロックチェーントランザクションを有効化するためにビットコインソフトウェアを実装するように構成されたノードを示す図である。
【図1c】ブロックチェーンネットワークを示す図である。
【図2】実施形態によるアカウントのセットアップを詳細に示す流れ図である。
【図3a】実施形態による送信者から受信者への支払いを詳細に示す流れ図である。
【図3b】実施形態による送信者から受信者への支払いを詳細に示す流れ図である
【図3c】実施形態によるランデブートランザクションを示す図である。
【図3d】ダストトランザクションのチェーンとイベントストリームとの間の関係を示す図である。
【図3e】トランザクションの関係者に対応する複数のイベントストリームを示す図である。
【図4a】実施形態による送信者から受信者への支払いを詳細に示す流れ図である。
【図4b】実施形態によるランデブートランザクションを示す図である。
【図4c】トランザクションの関係者に対応する複数のイベントストリームを示す図である。
【図5a】実施形態による送信者から受信者への支払いを詳細に示す流れ図である。
【図5b】実施形態によるランデブートランザクションを示す図である。
【図5c】トランザクションの関係者に対応する複数のイベントストリームを示す図である。
【図6a】実施形態による送信者から受信者への支払いを詳細に示す流れ図である。
【図6b】実施形態による送信者から受信者への支払いを詳細に示す流れ図である
【図7】実施形態によって生成されるランデブーブロックチェーントランザクションを示す図である。
【図8】実施形態によるトランザクションの関係者のイベントストリームを示す図である。
【図8a】コミットメントのチェーンを示す図である。
【図9】コミットメントのチェーンを用いて資産譲渡イベントを記録するための方法のステップを示す図である。
【図10】コミットメントの複数のチェーンを同期するランデブートランザクションを示す図である。
【図11】状態ダイジェスト(state digest)を表すマークル木を示す図である。
【図12】データダイジェスト(data digest)を表すマークル木を示す図である。
【図13】コミットメントの複数のチェーンを同期する代替的なランデブートランザクションを示す図である。
【発明を実施するための形態】
【0034】
以降で、読者に本開示の最大限の完全な理解をもたらすために、本開示の態様および実施形態の詳細な検討を提供する。
【0035】
第1の態様から見ると、少なくとも第1のユーザおよび第2のユーザを含む資産譲渡イベントを記録するコンピュータによって実装される方法が提供される。方法は、通貨の支払いが記録されることを可能にする場合がある。通貨の支払いは、任意の通貨によるものであることが可能であり、商品またはサービスのためのものである場合がある。方法は、コンピューティングリソースによって実施されてよい。コンピューティングリソースは、ハードウェアまたはソフトウェアによって実装される場合がある。コンピューティングリソースは、局所的にかまたは広い地理的エリアにかのどちらかに分散される場合がある複数の処理リソースを含んでよい。方法は、指示データを受信するステップであって、指示データが、要求された資産譲渡イベントに関連し、指示データが、支払いの送信者に関連するメタデータの第1のセット、および支払いの少なくとも1人の受信者に関連するメタデータの第2のセットを含む、ステップを含んでよい。メタデータは、支払いの通貨、資産レジストリに関連するアカウント、支払いを受け取るようにまたは支払いを行うように指定された個人、支払いの条項および条件、ならびに支払いを承認する公開鍵またはデジタル署名の証拠のうちの少なくとも1つを特定する場合がある。送信者および受信者の各々は、資産レジストリに関連するアカウントにそれぞれ関連付けられてよい。
【0036】
資産の送信者は、コミットメントの第1のチェーンに関連付けられてよく、資産の受信者は、コミットメントの第2のチェーンに関連付けられてよく、コミットメントの各チェーンは、イベントストリームを複数のブロックチェーントランザクションに関連付ける。コミットメントのチェーンは、イベントストリームに関連付けられるブロックチェーントランザクションの関連するセットを提供してよい。そのセットのブロックチェーントランザクションは、出力データペイロードに含まれてよい情報によってリンクされる。
【0037】
方法は、譲渡プロトコルに従って、送信者から少なくとも1人の受信者への資産の譲渡が行われ得るかどうかを判定するために、メタデータの第1のセットとメタデータの第2のセットとを比較するステップであって、譲渡プロトコルが、資産譲渡イベントが行われることを可能にする少なくとも1つの基準を定義する、ステップを含んでよい。
【0038】
方法は、譲渡プロトコルに従ったメタデータのそれぞれのセットの間の比較に基づいて、メタデータのそれぞれのセットの間の1つまたは複数の対応を決定するステップを含んでよい。
【0039】
方法は、コミットメントの第1のチェーンおよび第2のチェーンに関連するそれぞれのイベントストリームにエントリを付け加えるステップであって、エントリが、メタデータの第1のセットおよび第2のセットに関連するデータを含む、ステップをさらに含んでよい。
【0040】
方法は、少なくとも1つの入力および少なくとも1つの出力を含むランデブーブロックチェーントランザクションを生成するステップであって、少なくとも1つの出力が、メタデータの第1のセットおよび第2のセットに関連する出力データを含み、メタデータに関連するデータが、将来のトランザクションに関連し、前のトランザクションにも基づく場合があるデータにさらに基づく、ステップをさらに含んでよい。少なくとも1つの入力および出力は、対応する複数の入力および出力であってよい。
【0041】
方法は、ランデブーブロックチェーントランザクションをそれぞれのイベントストリームのそれぞれのエントリに関連付けるステップをさらに含んでよい。それぞれのエントリとのランデブーブロックチェーントランザクションの関連付けは、対応するイベントストリームエントリにランデブーブロックチェーントランザクションへの参照を記憶することを含んでよい。
【0042】
ランデブーブロックチェーントランザクションは、ブロックチェーンに送信されてよい。ランデブートランザクションは、その他のブロックチェーントランザクションのセットとともに送信される場合がある。
【0043】
ランデブーブロックチェーントランザクションは、送信者および受信者の各々に対応する入力と出力とのペアを含んでよい。入力と出力とのペアは、それらのインデックスの観点で対応する入力および出力を意味するものと理解されてよい。つまり、たとえば、入力がインデックス0を有する場合、入力と出力とのペアの出力も、インデックス0を有する。たとえば、資産レジストリなどのその他のエンティティに対応する入力と出力とのペアが存在する場合もある。
【0044】
少なくとも1つの出力は、メタデータの第1のセットおよび第2のセットならびに将来のトランザクションに基づいて生成された出力メタデータを含むデータペイロードを含んでよい。出力メタデータは、データダイジェストおよび状態ダイジェストを含んでよい。少なくとも1つの出力は、使用不可能であってよい。メタデータの第1のセットおよび第2のセットは、データペイロードに含める前にハッシュされるかまたは二重ハッシュされてよい。将来のトランザクションデータは、将来のトランザクションの識別子であってよい。つまり、データペイロードは、現在のトランザクションを将来のトランザクションにリンクし、さらに、前のトランザクションを将来のトランザクションにリンクする場合がある、将来のトランザクションにコミットする情報を含んでよい。
【0045】
データダイジェストは、メタデータの第1のセットおよび第2のセットのハッシュに基づいて生成されてよい。さらなるハッシュが、メタデータの第1のセットおよび第2のセットのハッシュに適用される場合があり、これは、伸長攻撃に対する耐性を提供する。
【0046】
データダイジェストは、メタデータの第1のセットとメタデータの第2のセットとの組合せおよびソルトに基づいて生成されてよい。つまり、メタデータの第1のセットおよび第2のセットのハッシュに対して、ソルト化(salting)の動作が用いられてよい。メタデータの第1のセットおよび第2のセットは、支払い指示データセットなどのデータの単一のセットを形成するために組み合わされる場合がある。
【0047】
ハッシュをソルト化することは、ハッシュ関数への入力の一部として(ハッシュされているデータと一緒に)、任意の自由に決められるデータである「ソルト」を用いることを意味する。ソルトは、ハッシュ関数へのその他の入力と連結されてよい。任意で、ソルトはランダムである。ハッシュされている各データアイテムのために異なるソルトが選択される場合がある。
【0048】
メタデータの第1のセットおよび第2のセットの組合せは、メタデータの第1のセットおよび第2のセットの組合せの二重ハッシュを取得することと、メタデータの第1のセットおよび第2のセットの組合せの二重ハッシュをソルトの二重ハッシュと連結することとを含んでよい。
【0049】
状態ダイジェストは、データダイジェストおよび将来のトランザクションに基づいて生成されてよく、前のトランザクションに基づいてさらに生成されてよい。
【0050】
状態ダイジェストは、マークル木のルートである場合がある。
【0051】
メタデータのそれぞれのセットの間の1つまたは複数の対応を決定するステップは、
i)メタデータのそれぞれのセット内で特定された支払いの通貨、
ii)送信者に対応するアカウントから支払われている通貨の量、および受信者に対応するアカウントから要求された通貨の量、ならびに
iii)送信者および受信者のアカウントに関連する資産レジストリの識別子
のうちの少なくとも1つの間の対応を決定することを含んでよい。
i)メタデータのそれぞれのセット内で特定された支払いの通貨、
ii)送信者に対応するアカウントから支払われている通貨の量、および受信者に対応するアカウントから要求された通貨の量、ならびに
iii)送信者および受信者のアカウントに関連する資産レジストリの識別子
のうちの少なくとも1つの間の対応を決定することを含んでよい。
【0052】
コンピューティングリソースは、譲渡プロトコルに従って、譲渡が行われ得ないと判定し、譲渡プロトコルと一致していないことを解決するためにメタデータのさらなるセットを生成し、それは、第1の通貨と第2の通貨との間の変換を可能にするメタデータを生成することを含んでよい。
【0053】
メタデータのさらなるセットの生成は、別の資産レジストリに所与の資産の譲渡を記録するために1つの資産レジストリのためのメタデータを生成することを含んでよい。
【0054】
特定の実施形態が、同様の参照番号が同様の特徴を指す添付の図面を参照して例示として以降で説明される。
【0055】
システムの概要
以降で、図1aを参照して、システム100の第1のユーザと第2のユーザとの間の資産の譲渡が記録されることを可能にするシステム100を説明する。
以降で、図1aを参照して、システム100の第1のユーザと第2のユーザとの間の資産の譲渡が記録されることを可能にするシステム100を説明する。
【0056】
システム100は、第1のコンピューティングデバイス102および第2のコンピューティングデバイス104を含む。第1のコンピューティングデバイス102および第2のコンピューティングデバイス104は、任意のコンピューティングリソースであってよい。第1のコンピューティングデバイス102および第2のコンピューティングデバイス104の各々は、それぞれの第1のおよび第2のアプリケーションプログラミングインターフェース(API)108を介して支払い処理リソース106とインタラクションするように構成される。
【0057】
支払い処理リソース106は、イベントストリームリソース110を用いて、Aliceという名前の第1のユーザ(110a)、Bobという名前の第2のユーザ(110b)、および支払い処理リソース(110c)の少なくとも各々に関して提供されるイベントストリームを初期化するおよび/またはそれらのイベントストリームとインタラクションするように構成される。支払い処理リソース106によるイベントストリームの初期化およびイベントストリームとのインタラクションは、nChain Holdings Limitedの名義で2021年2月18日に出願された英国特許出願第2102314.8号から理解されるであろう。
【0058】
支払い処理リソース106は、ブロックチェーン112とインタラクションするようにさらに構成される。ブロックチェーン112は、それがトランザクションから構成されるブロック(BSV1、BSV2、BSV3)の追加専用台帳であるという点で、ビットコイン・サトシ・ビジョン(BSV: Bitcoin Satoshi Vision)プロトコルに従う少なくとも1つのパブリックプルーフオブワークブロックチェーンを含んでよい。
【0059】
ブロックチェーン112は、以降で図1bに関連して説明されるソフトウェアによって構成される複数のノード126を含む。各ノードは、図1cに関連して下で説明されるように、このソフトウェアによって、ブロックチェーンの一部として構成される。
【0060】
図1bは、UTXOまたは出力ベースのモデルの例において、ネットワーク132の各ブロックチェーンノード126上で実行されるノードソフトウェア450の例を示す。別のエンティティが、ネットワーク132上でノード126として分類されることなく、すなわち、ノード126の必要とされるアクションを実行することなく、ノードソフトウェア450を実行する場合があることに留意されたい。ノードソフトウェア450は、プロトコルエンジン451、スクリプトエンジン452、スタック453、アプリケーションレベル決定エンジン454、および1つまたは複数のブロックチェーン関連機能モジュール455のセットを含んでよいがこれらに限定されない。各ノード126は、コンセンサスモジュール455C(たとえば、プルーフオブワーク)、伝播モジュール455P、およびストレージモジュール455S(たとえば、データベース)の3つすべてを含むがこれらに限定されないノードソフトウェアを実行してよい。プロトコルエンジン451は、典型的には、トランザクション152の異なるフィールドを認識し、ノードプロトコルにしたがってそれらのフィールドを処理するように構成される。別の先行トランザクション152i(Txm-1)の出力(たとえば、UTXO)を指し示す入力を有するトランザクション152j(Txj)が受信されるとき、プロトコルエンジン451は、Txjのロック解除スクリプトを特定し、そのロック解除スクリプトをスクリプトエンジン452に渡す。また、プロトコルエンジン451は、Txjの入力のポインタに基づいてTxiを特定し、取り出す。Txiは、ブロックチェーン150上で公開されている場合があり、その場合、プロトコルエンジンは、ノード126に記憶されたブロックチェーン150のブロック151のコピーからTxiを取り出してよい。代替的に、Txiは、ブロックチェーン150上でまだ公開されていない場合がある。その場合、プロトコルエンジン451は、ノード126によって維持される未公開トランザクションの順序付けられたセット154からTxiを取り出してよい。いずれにせよ、プロトコルエンジン451は、Txiの参照された出力のロックスクリプトを特定し、これをスクリプトエンジン452に渡す。
【0061】
したがって、スクリプトエンジン452は、Txiのロックスクリプトと、Txjの対応する入力からロック解除スクリプトとを有する。たとえば、Tx0およびTx1とラベル付けされたトランザクションが図2に示されるが、同じことがトランザクションのどのペアにも当てはまる可能性がある。スクリプトエンジン452は、既に検討されたように2つのスクリプトを一緒に実行し、これは、用いられているスタックベースのスクリプト言語(たとえば、Script)に従って、スタック453にデータを入れることと、スタック453からデータを取り出すこととを含む。
【0062】
スクリプトを一緒に実行することによって、スクリプトエンジン452は、ロック解除スクリプトがロックスクリプトにおいて定義された1つまたは複数の基準を満たすか否か -- すなわち、ロック解除スクリプトがロックスクリプトが含まれる出力を「ロック解除する」かどうか -- を判定する。スクリプトエンジン452は、この判定の結果をプロトコルエンジン451に返す。スクリプトエンジン452は、ロック解除スクリプトが対応するロックスクリプトにおいて指定された1つまたは複数の基準を満たすと判定する場合、結果「真」を返す。それ以外の場合、スクリプトエンジン452は、「偽」を返す。
【0063】
出力ベースのモデルにおいて、スクリプトエンジン452からの結果「真」は、トランザクションの有効性の条件のうちの1つである。概して、Txjにおいて指定されたデジタル資産の総量がその入力によって指し示された総量を超えないこと、およびTxiの指し示された出力が別の有効なトランザクションによって既に消費されていないことなどの、同様に満たされなければならない、プロトコルエンジン451によって評価される1つまたは複数のさらなるプロトコルレベルの条件も存在する。プロトコルエンジン451は、スクリプトエンジン452からの結果を1つまたは複数のプロトコルレベルの条件と一緒に評価し、それらがすべて真である場合にのみ、トランザクションTxjを有効化する。プロトコルエンジン451は、トランザクションが有効であるかどうかのインジケーションをアプリケーションレベル決定エンジン454に出力する。Txjが確かに有効化されるという条件でのみ、決定エンジン454は、コンセンサスモジュール455Cと伝播モジュール455Pとの両方を制御して、Txjに関してそれらのそれぞれのブロックチェーン関連機能を実行することを選択してよい。これは、コンセンサスモジュール455Cが、ブロック151に組み込むためのトランザクションのノードのそれぞれの順序付けられたセット154にTxjを追加することと、伝播モジュール455Pが、Txjをネットワーク106の別のブロックチェーンノード126に転送することとを含む。任意で、実施形態において、アプリケーションレベル決定エンジン454は、これらの機能のどちらかまたは両方をトリガする前に、1つまたは複数の追加の条件を適用する場合がある。たとえば、決定エンジンは、トランザクションが有効であり、かつ十分な取引手数料を残すという条件でのみ、トランザクションを公開することを選択する場合がある。
【0064】
本明細書における用語「真」および「偽」は必ずしも2進数1桁(ビット)のみの形態で表された結果を返すことに限定されないが、それは確かに1つの可能な実装であることに留意されたい。より広く、「真」は、成功したまたは肯定的な結果を示す任意の状態を指すことが可能であり、「偽」は、失敗したまたは非肯定的な結果を示す任意の状態を指すことが可能である。たとえば、アカウントベースのモデルにおいて、「真」の結果は、署名の暗黙的なプロトコルレベルの有効化とスマートコントラクトの追加の肯定的な出力との組合せによって示される可能性がある(個々の結果が両方とも真である場合に、全体の結果が真を知らせるとみなされる)。
【0065】
開示された技術のその他の変形またはユースケースは、本明細書の開示が与えられれば、当業者に明らかになるであろう。本開示の範囲は、記載された実施形態によって限定されず、添付の請求項によってのみ限定される。
【0066】
たとえば、上記のいくつかの実施形態は、ビットコインネットワーク106、ビットコインブロックチェーン150、およびビットコインノード126の観点で説明された。しかし、ビットコインブロックチェーンは、ブロックチェーン150の1つの特定の例であり、上の説明は、任意のブロックチェーンに広く当てはまる可能性があることが理解されるであろう。すなわち、本発明は、ビットコインブロックチェーンに決して限定されない。より広く、ビットコインネットワーク106、ビットコインブロックチェーン150、およびビットコインノード126への上記のすべての言及は、それぞれ、ブロックチェーンネットワーク106、ブロックチェーン150、およびブロックチェーンノード126への言及に置き換えられてよい。ブロックチェーン、ブロックチェーンネットワーク、および/またはブロックチェーンノードは、上述のビットコインブロックチェーン150、ビットコインネットワーク106、およびビットコインノード126の説明された特性の一部またはすべてを共有する場合がある。
【0067】
本発明の好ましい実施形態において、ブロックチェーンネットワーク132は、ビットコインネットワークであり、ビットコインノード126が、ブロックチェーン150のブロック151を作成し、公開し、伝播し、記憶する説明された機能の少なくともすべてを実行する。これらの機能のうちの1つまたは一部だけを実行するが、すべては実行しないその他のネットワークエンティティ(またはネットワーク要素)が存在する可能性があることは、排除されない。すなわち、ネットワークエンティティが、ブロックを作成および公開することなく、ブロックを伝播および/または記憶する機能を実行する場合がある(これらのエンティティは、好ましいビットコインネットワーク132のノードとはみなされないことを思い出されたい)。
【0068】
本発明の好ましくない実施形態において、ブロックチェーンネットワーク132は、ビットコインネットワークではない場合がある。これらの実施形態においては、ノードが、ブロックチェーン150のブロック151を作成し、公開し、伝播し、記憶する機能の少なくとも1つまたは一部を実行するが、すべては実行しない場合があることは排除されない。たとえば、それらのその他のブロックチェーンネットワーク上で、「ノード」は、ブロック151を作成および公開するように構成されるが、それらのブロック151を記憶および/またはその他のノードに伝播するように構成されないネットワークエンティティを指すために用いられる場合がある。
【0069】
さらに一層広く、上記の用語「ビットコインノード」126へのあらゆる言及は、用語「ネットワークエンティティ」または「ネットワーク要素」に置き換えられてよく、そのようなエンティティ/要素は、ブロックを作成し、公開し、伝播し、記憶する役割の一部またはすべてを実行するように構成される。そのようなネットワークエンティティ/要素の機能は、ブロックチェーンノード126に関連して上で説明された同じ方法でハードウェアに実装されてよい。
【0070】
さらに一層広く、上記の用語「ビットコインノード」126へのあらゆる言及は、用語「ネットワークエンティティ」または「ネットワーク要素」に置き換えられてよく、そのようなエンティティ/要素は、ブロックを作成し、公開し、伝播し、記憶する役割の一部またはすべてを実行するように構成される。そのようなネットワークエンティティ/要素の機能は、ブロックチェーンノード126に関連して上で説明された同じ方法でハードウェアに実装されてよい。
【0071】
図1cは、ブロックチェーン150を実装するための例示的なシステム100を示す。システム100は、パケット交換ネットワーク130、典型的には、インターネットなどの広域インターネットワークで構成されてよい。パケット交換ネットワーク130は、パケット交換ネットワーク130内でピアツーピア(P2P)ネットワーク132を形成するように配置される場合がある複数のブロックチェーンノード126を含む。図示されていないが、ブロックチェーンノード126は、ほぼ完全なグラフ(near-complete graph)として配置される場合がある。したがって、各ブロックチェーンノード126は、その他のブロックチェーンノード126と緊密に接続される。
【0072】
各ブロックチェーンノード126は、ピアのコンピュータ機器を含み、ノード126のうちの異なるノードは、異なるピアに属する。各ブロックチェーンノード126は、1つまたは複数のプロセッサ、たとえば、1つまたは複数の中央演算処理装置(CPU)、アクセラレータプロセッサ、特定用途向けプロセッサおよび/またはフィールドプログラマブルゲートアレイ(FPGA)、ならびに特定用途向け集積回路(ASIC)などのその他の機器を含む処理装置を含む。各ノードは、メモリ、すなわち、1つの非一時的コンピュータ可読媒体または複数の非一時的コンピュータ可読媒体の形態のコンピュータ可読ストレージも含む。メモリは、1つまたは複数のメモリ媒体、たとえば、ハードディスクなどの磁気媒体、ソリッドステートドライブ(SSD)、フラッシュメモリ、もしくはEEPROMなどの電子媒体、および/または光ディスクドライブなどの光媒体を採用する1つまたは複数のメモリユニットを含んでよい。
【0073】
ブロックチェーン150は、データのブロック151のチェーンを含み、ブロックチェーン150のそれぞれのコピーが、分散型またはブロックチェーンネットワーク130の複数のブロックチェーンノード126の各々において維持される。上述のように、ブロックチェーン150のコピーを維持することは、必ずしもブロックチェーン150をすべて記憶することを意味しない。そうではなく、各ブロックチェーンノード150が各ブロック151のブロックヘッダ(下で検討される)を記憶する限り、ブロックチェーン150は、データを刈り込まれる場合がある。チェーンの各ブロック151は、1つまたは複数のトランザクション152を含み、この文脈におけるトランザクションは、データ構造の一種を指す。データ構造の性質は、トランザクションモデルまたは方式の一部として用いられるトランザクションプロトコルの種類に依存する。所与のブロックチェーンは、全体を通じて1つの特定のトランザクションプロトコルを用いる。1つのよくある種類のトランザクションプロトコルにおいて、各トランザクション152のデータ構造は、少なくとも1つの入力および少なくとも1つの出力を含む。各出力は、財産としてのデジタル資産の量を表す額を指定し、その例は、出力が暗号的にロックされるユーザ103である(ロックを解除され、それによって、履行または消費されるためにはそのユーザの署名またはその他の解決策を必要とする)。各入力は、先行トランザクション152の出力を後ろ向きに指し示し、それによって、トランザクションをリンクする。
【0074】
各ブロック151は、ブロック151までの発生順を定義するように、チェーン内の前に作成されたブロック151を後ろ向きに指し示すブロックポインタ155も含む。(コインベーストランザクション(coinbase transaction)以外の)各トランザクション152は、トランザクションのシーケンスに順序を定義するように、前のトランザクションに戻るポインタを含む(トランザクション152のシーケンスは分岐することを許されることに注意されたい)。ブロック151のチェーンは、チェーンの最初のブロックであったジェネシスブロック(Gb)153までさかのぼる。チェーン150の初期の1つまたは複数の当初のトランザクション152は、先行トランザクションではなくジェネシスブロック153を指し示していた。
【0075】
ブロックチェーンノード126の各々は、トランザクション152をその他のブロックチェーンノード126に転送し、それによって、トランザクション152をネットワーク132全体に伝播させるように構成される。各ブロックチェーンノード126は、ブロック151を作成し、同じブロックチェーン150のそれぞれのコピーをそれらのブロックチェーンノード126のそれぞれのメモリに記憶するように構成される。また、各ブロックチェーンノード126は、ブロック151に組み込まれるのを待っているトランザクション152の順序付けられたセット154を維持する。順序付けられたセット154は、多くの場合「メムプール(mempool)」と呼ばれる。本明細書におけるこの用語は、いかなる特定のブロックチェーン、プロトコル、またはモデルにも限定するように意図されていない。この用語は、ノード126が有効であるものとして受け入れ、ノード126が同じ出力を消費しようとするいかなるその他のトランザクションも受け入れないことを義務付けられるトランザクションの順序付けられたセットを指す。
【0076】
所与の現在のトランザクション152jにおいて、その(または各)入力は、トランザクションのシーケンス内の先行トランザクション152iの出力を参照するポインタを含み、この出力が現在のトランザクション152jにおいて履行されるまたは「消費される」ことを指定する。概して、先行トランザクションは、順序付けられたセット154または任意のブロック151内の任意のトランザクションである可能性がある。先行トランザクション152iは、現在のトランザクション152jが作成される時点、またはネットワーク132に送信される時点でさえも必ずしも存在する必要はないが、現在のトランザクションが有効であるためには、先行トランザクション152iが存在し、有効化される必要がある。したがって、本明細書における「先行」は、ポインタによってリンクされた論理的なシーケンスにおける先任者(predecessor)を指し、必ずしも時間的なシーケンスにおける作成または送信の時間を指すものではなく、したがって、トランザクション152i、152jが順不同で作成または送信されることを必ずしも除外しない(孤児(orphan)トランザクションに関する下の検討を参照されたい)。先行トランザクション152iは、同様に先祖(antecedent)または先任者トランザクションと呼ばれる可能性がある。
【0077】
現在のトランザクション152jの入力は、入力の認可、たとえば、先行トランザクション152iの出力がロックされているユーザ103aの署名も含む。そして今度は、現在のトランザクション152jの出力が、新しいユーザまたはエンティティ103bに暗号的にロックされ得る。したがって、現在のトランザクション152jは、先行トランザクション152iの入力において定義された額を、現在のトランザクション152jの出力において定義されたように新しいユーザまたはエンティティ103bに送金することができる。場合によっては、トランザクション152は、複数のユーザまたはエンティティ(そのうちの1つは、お釣りを渡すために元のユーザまたはエンティティ103aである可能性がある)の間で入力額を分けるために複数の出力を有する場合がある。場合によっては、トランザクションは、1つまたは複数の先行トランザクションの複数の出力からの金額を集め、現在のトランザクションの1つまたは複数の出力に再分配するために複数の入力を有することも可能である。
【0078】
ビットコインのような出力ベースのトランザクションプロトコルによれば、ユーザまたは機械などのエンティティ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のネットワーク全体に伝播される。
【0079】
出力ベースのモデルにおいて、所与の出力(たとえば、UTXO)が割り振られるかどうかの定義は、その出力がブロックチェーンノードプロトコルに従って別のオンワードトランザクション(onward transaction)152jの入力によって既に有効に履行されたかどうかということである。トランザクションが有効であるための別の条件は、それが割り振ろうとまたは履行しようと試みる先行トランザクション152iの出力が別のトランザクションによって既に割り振られて/履行されていないことである。やはり、有効でない場合、トランザクション152jは(警告のために無効であるものとしてフラグを立てられ、伝播されるのでない限り)伝播されず、ブロックチェーン150に記録されない。これは、トランザクションを行う者が同じトランザクションの出力を2回以上割り振ろうとする二重支払いを防ぐ。一方、アカウントベースのモデルは、アカウントの残高を維持することによって二重支払いを防止する。やはり、トランザクションの定義された順序が存在するので、アカウントの残高は、常に単一の定義された状態を有する。
【0080】
トランザクションを有効化することに加えて、ブロックチェーンノード126は、「プルーフオブワーク」によってサポートされる、通常、マイニングと呼ばれるプロセスでトランザクションのブロックを最初に作成するノードになろうとさらに競争する。ブロックチェーンノード126において、新しいトランザクションは、ブロックチェーン150に記録されたブロック151にまだ現れていない有効なトランザクションの順序付けられたセット154に追加される。それから、ブロックチェーンノードは、暗号パズルを解くことを試みることによって、トランザクションの順序付けられたセット154からトランザクション152の新しい有効なブロック151を組み立てようと競争する。概して、これは、ナンスがトランザクションの順序付けられたセット154の表現と連結され、ハッシュされるときに、ハッシュの出力が所定の条件を満たすような「ナンス」値を探索することを含む。たとえば、所定の条件は、ハッシュの出力が特定の予め定義された数の先頭のゼロを有することである場合がある。これは、プルーフオブワークのパズルの単なる1つの特定の種類であり、その他のパズルは除外されないことに留意されたい。ハッシュ関数の特性は、ハッシュ関数がその入力に対して予測不可能な出力を有することである。したがって、この探索は、総当たりによってのみ実行されることが可能であり、したがって、パズルを解こうとしている各ブロックチェーンノード126において相当大量の処理リソースを消費する。
【0081】
パズルを解いた最初のブロックチェーンノード126は、これをネットワーク132に告知し、ネットワークのその他のブロックチェーンノード126によってその後容易にチェックされ得る証明として解を提供する(ハッシュの解が与えられると、それがハッシュの出力に条件を満足させることをチェックすることは簡単である)。最初のブロックチェーンノード126は、ブロックを受け入れ、したがって、プロトコルの規則を施行するその他のノードの閾値のコンセンサスまでブロックを伝播する。そして、トランザクションの順序付けられたセット154は、ブロックチェーンノード126の各々によってブロックチェーン150に新しいブロック151として記録されるようになる。また、チェーン内の前に作成されたブロック151n-1を後ろ向きに指し示すブロックポインタ155が、新しいブロック151nに割り振られる。プルーフオブワークの解を作成するために必要とされる、たとえば、ハッシュの形態の著しい量の労力は、ブロックチェーンプロトコルの規則に従うという最初のノード126の意図を知らせる。そのような規則は、二重支払いとしても知られている、トランザクションが前に有効化されたトランザクションと同じ出力を割り振る場合、トランザクションを有効であるものとして受け入れないことを含む。作成されると、ブロック151は、ブロックチェーンネットワーク132のブロックチェーンノード126の各々において認識され、維持されるので、修正され得ない。また、ブロックポインタ155は、ブロック151に発生順を付与する。トランザクション152がネットワーク132の各ブロックチェーンノード126の順序付けられたブロックに記録されるので、これは、したがって、トランザクションの不変の公開台帳を提供する。
【0082】
任意の所与の時間にパズルを解こうと競争している異なるブロックチェーンノード126は、それらのブロックチェーンノード126がいつ解を探索し始めたか、またはトランザクションが受信された順序に応じて、任意の所与の時間にまだ公開されていないトランザクションの順序付けられたセット154の異なるスナップショットに基づいてそうしている場合があることに留意されたい。最初にそれらのそれぞれのパズルを解いた者は誰でも、どのトランザクション152が次の新しいブロック151nにどの順序で含まれるかを定義し、未公開トランザクションの現在のセット154が、更新される。それから、ブロックチェーンノード126は、未公開トランザクションの新たに定義された未処理の順序付けられたセット154からブロックを作成しようと競争を続け、以下同様である。発生する可能性があるすべての「フォーク(fork)」を解決するためのプロトコルも存在し、フォークは、ブロックチェーンの相反するビュー(view)がノード126の間で伝播されるように、2つのブロックチェーンノード126が互いに非常に短い時間内にそれらのブロックチェーンノード126のパズルを解く地点である。手短に言えば、どちらでも最も長くなる方のフォークの爪が、最終的なブロックチェーン150となる。これは、同じトランザクションが両方のフォークに現れるので、ネットワークのユーザまたはエージェントに影響を与えないはずであることに留意されたい。
【0083】
ビットコインブロックチェーン(およびほとんどのその他のブロックチェーン)によれば、新しいブロック126を成功裏に構築するノードは、(ある額のデジタル資産をあるエージェントまたはユーザから別のエージェントまたはユーザに送金するエージェント間またはユーザ間トランザクションとは対照的に)定義された量のデジタル資産を分配する新しい特別な種類のトランザクションにおいて認められた額のデジタル資産を割り振る能力を付与される。この特別な種類のトランザクションは、通常「コインベーストランザクション」と呼ばれるが、「イニシエーション(initiation)トランザクション」と呼ばれる場合もある。この特別な種類のトランザクションは、概して、新しいブロック151nの最初のトランザクションを形成する。プルーフオブワークは、この特別なトランザクションが後で履行されることを可能にするプロトコルの規則に従うという、新しいブロックを構築するノードの意図を知らせる。ブロックチェーンプロトコルの規則は、この特別なトランザクションが履行されてよい前に、満期期間(maturity period)、たとえば、100ブロックを必要とする場合がある。多くの場合、通常の(非生成(non-generation))トランザクション152は、トランザクションが公開されたブロック151nを作成したブロックチェーンノード126にさらに報酬を与えるために、その出力の1つにおいて追加の取引手数料も指定する。この手数料は、通常「取引手数料」と呼ばれ、下で検討される。
【0084】
トランザクションの有効化および公開に関わるリソースが原因で、概して、少なくとも、ブロックチェーンノード126の各々は、1つもしくは複数の物理サーバユニットを含むサーバ、またはさらにはデータセンター全体の形態をとる。しかし、原理的には、任意の所与のブロックチェーンノード126は、ユーザ端末、または一緒にネットワーク化されたユーザ端末のグループの形態をとる可能性がある。
【0085】
各ブロックチェーンノード126のメモリは、ブロックチェーンノードプロトコルに従ってそのそれぞれの1つの役割または複数の役割を実行し、トランザクション152を処理するために、ブロックチェーンノード126の処理装置上で実行されるように構成されたソフトウェアを記憶する。本明細書においてブロックチェーンノード126に帰せられるすべてのアクションは、それぞれのコンピュータ機器の処理装置上で実行されるソフトウェアによって実行されてよいことが理解されるであろう。ノードソフトウェアは、アプリケーションレイヤの1つもしくは複数のアプリケーションに、またはオペレーティングシステムレイヤもしくはプロトコルレイヤなどのより下位のレイヤに、またはこれらの任意の組合せで実装されてよい。
【0086】
ネットワーク130にさらに接続されるのは、消費ユーザの役割の複数の関係者103の各々のコンピュータ機器である。これらのユーザは、ブロックチェーンネットワークとインタラクションする場合があるが、トランザクションおよびブロックの有効化、構築、または伝播には参加しない。これらのユーザまたはエージェント103の一部は、トランザクションにおいて送信者および受信者として働く場合がある。その他のユーザは、必ずしも送信者または受信者として働くことなく、ブロックチェーン150とインタラクションしてよい。たとえば、一部の関係者は、(たとえば、ブロックチェーンノード126からブロックチェーンのコピーを取得した)ブロックチェーン150のコピーを記憶するストレージエンティティとして働く場合がある。
【0087】
関係者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の関係者」によって置き換えられてよいことが理解されるであろう。
【0088】
各関係者103のコンピュータ機器は、1つまたは複数のプロセッサ、たとえば、1つまたは複数のCPU、GPU、その他のアクセラレータプロセッサ、特定用途向けプロセッサ、および/またはFPGAを含むそれぞれの処理装置を含む。各関係者103のコンピュータ機器は、メモリ、すなわち、1つの非一時的コンピュータ可読媒体または複数の非一時的コンピュータ可読媒体の形態のコンピュータ可読ストレージをさらに含む。このメモリは、1つまたは複数のメモリ媒体、たとえば、ハードディスクなどの磁気媒体、SSD、フラッシュメモリ、もしくはEEPROMなどの電子媒体、および/または光ディスクドライブなどの光媒体を採用する1つまたは複数のメモリユニットを含んでよい。各関係者103のコンピュータ機器のメモリは、処理装置上で実行されるように配置された少なくとも1つのクライアントアプリケーション105のそれぞれのインスタンスを含むソフトウェアを記憶する。本明細書において所与の関係者103に帰せられるすべてのアクションは、それぞれのコンピュータ機器の処理装置上で実行されるソフトウェアを用いて実行されてよいことが理解されるであろう。各関係者103のコンピュータ機器は、少なくとも1つのユーザ端末、たとえば、デスクトップもしくはラップトップコンピュータ、タブレット、スマートフォン、またはスマートウォッチなどのウェアラブルデバイスを含む。所与の関係者103のコンピュータ機器は、ユーザ端末を介してアクセスされるクラウドコンピューティングリソースなどの1つまたは複数のその他のネットワーク化されたリソースも含む場合がある。
【0089】
クライアントアプリケーション105は、最初に、1つの好適なコンピュータ可読ストレージ媒体または複数の好適なコンピュータ可読ストレージ媒体上で任意の所与の関係者103のコンピュータ機器に提供され、たとえば、サーバからダウンロードされるか、あるいはリムーバブルSSD、フラッシュメモリキー、リムーバブルEEPROM、リムーバブル磁気ディスクドライブ、磁気フロッピーディスクもしくはテープ、CDもしくはDVD ROMなどの光ディスク、またはリムーバブル光学ドライブなどのリムーバブルストレージデバイス上で提供される場合がある。クライアントアプリケーション105は、図1cに示されたデバイス102aおよび102b上の105aおよび105bにそれぞれ対応する。
【0090】
クライアントアプリケーション105は、少なくとも「ウォレット」機能を含む。これは、2つの主な機能を有する。これらのうちの一方は、それぞれの関係者103が、トランザクション152を作成し、認可し(たとえば、署名し)、その後ブロックチェーンノード126のネットワーク全体に伝播され、それによって、ブロックチェーン150に含められるように1つまたは複数のビットコインノード126に送信することを可能にすることである。他方は、それぞれの関係者が現在所有しているデジタル資産の額の報告をその関係者に返すことである。出力ベースのシステムにおいて、この第2の機能は、問題にしている関係者に属する、ブロックチェーン150全体に散在する様々なトランザクション152の出力に定義された額を照合することを含む。
【0091】
注:様々なクライアント機能が所与のクライアントアプリケーション105に統合されているものとして説明される場合があるが、これは、必ずしも限定的ではなく、むしろ、本明細書において説明される任意のクライアント機能は、その代わりに、たとえば、APIによってインターフェースをとる、または1つがそれ以外に対するプラグインである、2つ以上の異なるアプリケーションのスイートに実装されてよい。より広く、クライアント機能は、アプリケーションレイヤ、またはオペレーティングシステムなどのより下位のレイヤ、またはこれらの任意の組合せに実装される可能性がある。以下は、クライアントアプリケーション105の観点で説明されるが、これが限定的でないことは、理解されるであろう。
【0092】
各コンピュータ機器上のクライアントアプリケーションまたはソフトウェア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によって同じノードプロトコルが用いられる。
【0093】
所与の関係者103、たとえば、Aliceが、ブロックチェーン150に含められるように新しいトランザクション152jを送信したいとき、その関係者103は、(その関係者103のクライアントアプリケーション105のウォレット機能を用いて)関連するトランザクションプロトコルに従って新しいトランザクションを組み立てる。そして、その関係者103は、クライアントアプリケーション105から、自分が接続されている1つまたは複数のブロックチェーンノード126にトランザクション152を送信する。たとえば、これは、Aliceのコンピュータに最良に接続されているブロックチェーンノード126である可能性がある。任意の所与のブロックチェーンノード126は、新しいトランザクション152jを受信するとき、ブロックチェーンノードプロトコルおよびそのそれぞれの役割に従ってその新しいトランザクション152jを処理する。これは、新しく受信されたトランザクション152jが「有効」であるための特定の条件を満たすかどうかを最初にチェックすることを含み、その例は、まもなくより詳細に検討される。一部のトランザクションプロトコルにおいて、有効化のための条件は、トランザクション152に含まれるスクリプトによってトランザクションごとに構成可能である場合がある。代替的に、条件は、単にノードプロトコルの組み込まれた特徴であるか、またはスクリプトとノードプロトコルとの組合せによって定義される可能性がある。
【0094】
新しく受信されたトランザクション152jが有効とみなされるためのテストに合格することを条件に(すなわち、新しく受信されたトランザクション152jが「有効化される」ことを条件に)、トランザクション152jを受信するすべてのブロックチェーンノード126は、そのブロックチェーンノード126において維持されるトランザクション154の順序付けられたセットに、新しい有効化されたトランザクション152を追加する。さらに、トランザクション152jを受信するすべてのブロックチェーンノード126は、有効化されたトランザクション152をネットワーク132の1つまたは複数のその他のブロックチェーンノード126に向かって伝播させる。各ブロックチェーンノード126が同じプロトコルを適用するので、トランザクション152jが有効であると仮定すると、これは、トランザクション152jがネットワーク132全体にすぐに伝播されることを意味する。
【0095】
所与のブロックチェーンノード126において維持されるトランザクションの順序付けられたセット154に入れられると、そのブロックチェーンノード126は、新しいトランザクション152を含むトランザクションのそれらのそれぞれの順序付けられたセット154の最新バージョンに関するプルーフオブワークのパズルを解く競い合いを開始する(その他のブロックチェーンノード126はトランザクションの異なる順序付けられたセット154に基づくパズルを解こうとしている可能性があるが、誰であれ最初に成功する者が最新のブロック151に含まれるトランザクションの順序付けられたセットを定義することを思い出されたい。最終的に、ブロックチェーンノード126は、Aliceのトランザクション152jを含む順序付けられたセット154の一部に関するパズルを解く)。新しいトランザクション152jを含む順序付けられたセット154に関してプルーフオブワークが行われると、順序付けられたセット154は、不変的にブロックチェーン150のブロック151のうちの1つの一部となる。各トランザクション152は、それ以前のトランザクションに戻るポインタを含み、したがって、トランザクションの順序も不変的に記録される。
【0096】
異なるブロックチェーンノード126は、最初に、所与のトランザクションの異なるインスタンスを受信し、したがって、1つのインスタンスが新しいブロック151で公開される前は、どのインスタンスが「有効」であるかについての相反するビューを有する可能性があり、1つのインスタンスが新しいブロック151で公開された時点で、すべてのブロックチェーンノード126は、公開されたインスタンスが唯一の有効なインスタンスであると合意する。ブロックチェーンノード126が1つのインスタンスを有効であるものとして受け入れ、その後、第2のインスタンスがブロックチェーン150に記録されたことを発見する場合、そのブロックチェーンノード126は、これを受け入れなければならず、そのブロックチェーンノード126が最初に受け入れたインスタンス(すなわち、ブロック151で公開されなかったインスタンス)を破棄する(すなわち、無効であるものとして扱う)。
【0097】
一部のブロックチェーンネットワークによって運用される代替的な種類のトランザクションプロトコルは、アカウントベースのトランザクションモデルの一部として、「アカウントベース」のプロトコルと呼ばれる場合がある。アカウントベースの場合、各トランザクションは、過去のトランザクションのシーケンス内の先行トランザクションのUTXOを後ろ向きに参照することによって送金される額を定義するのではなく、絶対的なアカウントの残高を参照することによって送金される額を定義する。すべてのアカウントの現在の状態は、ブロックチェーンとは別のそのネットワークのノードによって記憶され、絶えず更新される。そのようなシステムにおいて、トランザクションは、アカウントの実行中の取引勘定(running transaction tally)(「ポジション」とも呼ばれる)を用いて順序付けられる。この値は、送信者によって送信者の暗号署名の一部として署名され、トランザクション参照計算(transaction reference calculation)の一部としてハッシュされる。さらに、任意のデータフィールドが、トランザクションに署名される場合もある。このデータフィールドは、たとえば、前のトランザクションIDがデータフィールドに含まれる場合、前のトランザクションを後ろ向きに指し示す場合がある。
【0098】
ブロックチェーン112に記録されるトランザクションは、使用されるかまたは使用されないかのどちらかであり、ロックスクリプトによって保護される価値の譲渡をモデル化する。トランザクションは、その入力によって価値を消費し、その出力によって価値を別の者に送る。トランザクションに入力される価値は、前のトランザクションによって出力された価値以上でなければならず、任意の余分な入力が、取引手数料として徴収される。ロックスクリプトに提示された解、すなわち、ロック解除スクリプトが間違っている場合、トランザクションが入力として取得されるよりも多い価値を出力する場合、トランザクションが既に消費された出力を消費する場合、またはトランザクションがまったく存在しない価値を消費しようとする場合、トランザクションは無効である。
【0099】
ロックスクリプトとロック解除スクリプトとの両方は、任意のデータを(使用不可能であることが証明可能な出力(provably unspendable output)の形態で)データキャリア出力(data carrier output)として埋め込むことができるスクリプトを含む、多種多様なスクリプト化された使用条件を可能にする機械可読スクリプト言語で表現される。
【0100】
図1aの支払い処理リソース106は、ブロックチェーン112とインタラクションするように構成される。支払い処理リソースは、ブロックチェーントランザクションを取り出し、ブロックチェーントランザクションからの既に使用されていない出力(UTXO)を消費するためのロック解除スクリプトを提供するように構成される。未使用トランザクションは、分散ハッシュテーブル(DHT)に記憶されてよい。支払い処理リソース106は、既に使用されていない出力を用いてブロックチェーントランザクションを生成し、それらのトランザクションへの入力として自身の資金を提供するように構成される。支払い処理リソース106は、トランザクションによって消費されている出力が既に消費された出力ではないこと、すなわち、トランザクションによって消費されている出力が未使用出力であり、二重支払いではないことを、出力の存在に関してDHTまたは一時的/二次メムプールをチェックすることによってチェックするように構成される。そして、支払い処理リソース106は、ブロックチェーントランザクションをブロックチェーン112に送信し、トランザクションが受信されたときにブロックチェーン112から通知を受信するようにさらに構成される。トランザクションがブロックチェーン112によって受信されたという通知を受信すると、支払い処理リソース106は、トランザクションの識別子を生成するように構成される。識別子は、英数字であってよい。支払い処理リソース106は、それが生成するブロックチェーントランザクションに使用不可能であることが証明可能な出力を追加し、それらの出力を用いて、支払い処理リソース106によって提供されるデータのハッシュを含むデータキャリアを付け加えるよう構成される。
【0101】
支払い処理リソース106によって識別子が生成されると、支払い処理リソース106は、(下でさらに説明されるように)データがイベントストリームに記録されることを要求するように構成される。
【0102】
支払い処理リソース106は、支払い処理リソース106のユーザによって用いられるアカウントに関連する情報を記憶するように構成される。支払い処理リソース106は、データベース管理システム(DBMS)140を利用して、これらのアカウントに関連する情報を作成、削除、および管理してよい。DBMS 140は、支払い処理リソース106に対してローカルにまたはリモートに置かれる場合があり、支払い処理リソース106は、任意の好適な電気通信媒体を用いてDBMS 140にアクセスしてよい。
【0103】
図1aの支払い処理リソース106は、鍵ストレージモジュール122および支払いデータストア124とインタラクションするように構成される。鍵ストレージモジュール122は、トランザクションが行われることを可能にするために支払い処理リソース106を用いる関係者のアカウントに対応する暗号鍵を記憶するように構成される。鍵ストレージモジュール122は、任意の好適なストレージを利用してよく、データベース管理システム(DBMS)を利用して、鍵ストレージモジュール122に暗号鍵を記憶する関係者のデータベース内のレコードからのデータを初期化し、記憶し、取り出す。支払いデータストア124は、支払い処理リソース106を用いて実施されるすべての支払いに関連するデータを記憶するように構成される。
【0104】
第1のコンピューティングデバイス102かまたは第2のコンピューティングデバイス126かのどちらかのユーザは、支払い処理リソース106にアカウントを確立してよい。そのようなアカウントの確立が、以降で図2を参照して説明される。
【0105】
Aliceが、ステップS200において、支払い処理リソース106へのアクセスを要求する入力を与えることによってセットアッププロセスを初期化する。第1のコンピューティングデバイス102が、ステップS202においてAPI 108にアクセスし、支払い処理リソース106とのインタラクションが行われることを可能にするためにAPI 108に認証データを提供する。認証データは、第1のコンピューティングデバイス102のユーザを一意に特定することができる任意のデータを含んでよい。例は、パスワード、氏名と生年月日との組合せ、またはユーザを一意に特定することができる任意のその他のデータアイテムである。認証データを承認すると、支払い処理リソース106が、ステップS204において、支払い処理リソース106にアカウントをセットアップするために必要とされる情報の要求を送信する。
【0106】
支払い処理リソース106がアカウントをセットアップするために必要とされる情報は、アカウントを管理するための帳簿管理機関(bookkeeping authority)として働く資産レジストリ、すなわち、銀行アカウントを提供する銀行のアイデンティティ(identity)、たとえば、HSBC、ユーザを特定する情報、たとえば、ユーザの公開暗号鍵、発行者の条項および条件の署名されたバージョンに対応するデータ、ユーザが用いたい通貨の識別情報、たとえば、GBP(スターリングポンド)、発行者の公開暗号鍵、ならびにアカウントの最小値を設定する最小残高値である。各資産レジストリは、資産レジストリによって管理されるすべてのアカウントに関連付けられる対応する資産の少なくとも1つの発行者に関連付けられる。たとえば、銀行は、GBPおよびEURの発行者に関連付けられる。銀行は、金およびその他の貴金属などのその他の資産の発行者に関連付けられる場合もある。金の発行者の例は、英国の王立造幣局である場合がある。情報は、支払い処理リソース106によってDBMS 140のレコードに記憶される。
【0107】
それから、Aliceが、必要とされる情報を提供する。情報は、ステップS206において、API 108を介して支払い処理リソース106に送信される。詳細を受信すると、支払い処理リソース106は、ステップS208において、資産レジストリデータベースにレコードを生成し、ステップS210において、提供された詳細をレコードに投入する。
【0108】
次に、支払い処理リソース106は、ステップS212において、イベントストリームがまだ初期化されていない場合、Aliceのアカウントに対応する、英国特許出願第2102314.8号に従ったイベントストリーム110aを初期化する。代替的または追加的に、支払い処理リソース106は、Aliceのためのイベントストリーム110aを既に記憶した可能性がある。
【0109】
そして、支払い処理リソース106は、ステップS214において、Aliceのためにアカウントが確立されたことを確認するための確認メッセージを第1のコンピューティングデバイス102に送信する。ステップS200からS214は、(HSBCのような銀行に関連する)支払い処理リソース106上のアカウントを確立するためにBobによっても用いられる。Bobのアカウントに対応するイベントストリーム110bも、初期化される。
【0110】
イベントストリームは、ブロックチェーンベースの追加専用ログである。AliceまたはBobなどの支払い処理リソース106のユーザは、自分のアカウントに対応するイベントストリームを作成すること、そのイベントストリームに付け加えること、およびそのイベントストリームを閉じることができる。これらは、後で説明される。
【0111】
代替的に、AliceまたはBobは、既に用いている資産レジストリに関連するアカウントの詳細を提供し、必要な情報のすべてを提供したことを条件に、ステップS200からS214を回避する場合がある。
【0112】
記録するための支払いデータの準備
ここで、支払い処理リソース106によって資産の譲渡が可能にされる複数の例示的なシナリオを説明する。これらの例は、各例の特徴がその他の例の特徴と組み合わされ得るという点で、例示的および非限定的であるように意図される。
ここで、支払い処理リソース106によって資産の譲渡が可能にされる複数の例示的なシナリオを説明する。これらの例は、各例の特徴がその他の例の特徴と組み合わされ得るという点で、例示的および非限定的であるように意図される。
【0113】
以降、図3aおよび図3bを参照して、Aliceが支払い処理リソース106を用いてBobに5GBPを送信する例示的なシナリオを説明する。この例において、譲渡されている資産は現金であり、資産レジストリは銀行である。
【0114】
ステップS300において、Aliceは、Bobに連絡を取って、Aliceが今度のBobの誕生日にBobに5GBPを送りたいことをBobに知らせる。ステップS302において、Bobは、Aliceにその気前のよさを感謝するために任意の好適な媒体を用いてメッセージを送る。
【0115】
それから、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に送信される支払いメタデータのセットを形成する。
【0116】
支払い処理リソース106は、Aliceから支払いメタデータを受信すると、ステップS308においてAliceが提供したメタデータに基づいて、Bobのアカウントからメタデータを取り出す。これが、ステップS310である。支払い処理リソース106は、Bobのアカウントが関連する通貨、すなわち、スターリングポンド(GBP)および銀行をBobのアカウントから取り出す。
【0117】
次に、支払い処理リソース106は、ステップS312において、Aliceから受信された支払いメタデータおよびBobのアカウントから取り出された情報を用いて、支払い指示データセットを生成する。
【0118】
この例において、Bobの銀行アカウントの提供者は「hsbc.com」であり、通貨はGBPと特定され、支払いの額(すなわち、Bobによって受け取られている金額)は5GBPであり、アカウントの識別情報は<Bob:HSBC>によって与えられ、ユーザは「kyc」値によってBobと特定され、行為者(actor)は支払いの受取人(beneficiary)、すなわち、支払いを受ける個人と特定される。これは、支払い指示データセットの一部を形成する。支払い指示データセットは、任意で、署名<Bob_sig>を用いてBobによって署名された条項および条件のバージョンも含む場合がある。
【0119】
支払い指示データセットの別の部分は、Aliceの詳細によって形成される。すなわち、アカウントの提供者は「hsbc.com」であり、通貨はGBPと特定され、Bobに送金されている支払いの額は5GBPであり(すなわち、Bobに支払われるAliceからの5GBPの引き落とし(debit)であり、したがって、支払い指示データセットにおいては-5と表現される)、アカウントの識別情報は<Alice:HSBC>によって与えられ、ユーザは「kyc」値によってAliceと特定される。支払い指示データセットは、ユニフォームリソースロケータ(URL)からアクセスされてよいドキュメントに含まれる場合があるAliceによって署名された条項および条件も含んでよい。また、支払い指示データセットは、行為者を支払いの送金人(originator)、すなわち、支払いを行う個人として特定する。
【0120】
それから、ステップS314において、支払い指示データセットへのAliceの署名の要求とともに、メッセージが第1のコンピューティングデバイス102に送信される。そして、Aliceは、Bobへの5GBPの支払いを承認するために、ステップS316において自分の暗号署名を提供する。そのとき、Aliceの署名は、支払い処理モデル132によって支払い指示データセットに適用される。つまり、Aliceは、自分の暗号署名によって支払い指示データセットに署名する。手短に言えば、Aliceのアカウントは引き落とされ、Bobのアカウントは入金されている。したがって、Aliceの署名が必要とされる。Bobの署名は、Bobがt&cリンク(すなわち、Bobが署名した条項および条件のドキュメントへのURL)と条項および条件を含むドキュメントのハッシュとを提供した場合にのみ必要される場合がある。これは、Aliceが送金された資金と引き換えにBobから何かを購入している場合、Bobが支払いの見返りとして条項および条件を提示したことを証明可能なように示され得ることを意味する。
【0121】
銀行が同一であり、金額が釣り合っているので、この例においては1つの署名のみが必要とされる。上述のように、Bobがt&cリンクを提供した場合は、2つの署名が必要とされる場合がある。
【0122】
次に、支払い処理リソース106は、ステップS318において、支払い指示データセットに支払いプロトコル基準を適用する。支払い処理リソース106は、ステップS320において、支払いプロトコルモジュール120にアクセスする。
【0123】
支払いプロトコルモジュール120は、まず、支払い指示データセットが、金額が一致しているという点でゼロサム規則を遵守すること、すなわち、Aliceのアカウントから引き出されている額がBobのアカウントに支払われている額と等しいことをチェックする。これが、ステップS322である。Aliceのアカウントから5GBPが引き出されており、Bobのアカウントに5GBPが支払われている、つまり、金額が同一であり、銀行が同一であるので、ゼロサム規則は遵守される。つまり、Aliceのアカウントに-5GBPが加えられており、Bobのアカウントに+5GBPが加えられているので、それぞれの金額は合計すると0になる。銀行が同一であるので、このステップは満たされ、データセットはゼロサム規則を遵守する。
【0124】
それから、支払いプロトコルモジュール120は、AliceからBobに送金されている額がAliceの残高を何らかの最小値未満にしないことをチェックする。これが、ステップS324である。つまり、Aliceはお金を使いすぎなのか? Aliceがお金を使いすぎている場合、すなわち、Aliceの残高(引く5GBP)が最小値未満になる場合、支払いプロトコルモジュール120は、Aliceにエラーメッセージを発行して、Aliceが使いたいお金を使うことができないこと、つまり、Bobに5GBPを支払うための資金がないことをAliceに知らせる。さらに言えば、与信枠が用いられている場合、最小値はマイナスになることがあり得る。支払いプロトコルモジュール120は、再び開始する指示が与えられるまで、すなわち、Aliceがより多くの資金を自分の銀行アカウントに預け入れたか、またはAliceの最低残高が変更されたとき、ステップS320に戻る。
【0125】
次に、支払いプロトコルモジュール120は、資産の識別情報に対応するデータ中でフィールドをチェックすることによって、支払いに関連するデータがトランザクションの2人の関係者間で一致しているかどうかをチェックする。これが、ステップS326である。この例のデータは、ゼロサム規則が満たされ、銀行が同じ、すなわち、「hsbc.com」であり、通貨が同じであるので一致している。つまり、銀行および資産の識別情報が釣り合う。下のさらなる例に見られるように、銀行および資産の識別情報が釣り合わないとき、必要とされる釣り合いを提供するためにさらなるメタデータが生成される必要がある。
【0126】
これを示す別の方法は、銀行および資産の識別情報を示すためのテンプレート(XXX_BBBB:AAAA)を利用してよく、XXXは、アカウントの運用者であり、BBBBは、銀行の識別情報であり、AAAAは、資産の識別情報である。このテンプレートを用いて、Alice_HSBC:GBPからBob_HSBC:GBPに5GBPが支払われることを示すことができ、銀行および資産の識別情報が釣り合っていることが分かる。
【0127】
支払い処理モジュール120は、AliceおよびBobの暗号署名が確認されるステップS328に移る。支払い処理モジュール120は、各署名のハッシュを生成し、ハッシュをステップS200からS214において生成されたレコードに記憶されたものと比較することによって、AliceおよびBobの暗号署名を確認する。これは、AliceおよびBobのアイデンティティも確認する。代替的または追加的に、プライベート/公開暗号鍵ペアに基づく標準的なPKI技術も、各署名を確認するために用いられてよい。これらの技術は、クライアントのアイデンティティを検証するためにも用いられ得る。
【0128】
ステップS322、S324、S326、およびS328の充足は、支払いプロトコルによって規定された基準が満たされたことを意味し、したがって、支払い処理リソース106は、支払い指示データセットに従って、AliceからBobへの5GBPの支払いが行われることを可能にする。
【0129】
そのとき、支払い処理リソース106は、ステップS330において、AliceおよびBobの各々に関して、ブロックチェーン112からブロックチェーントランザクションを取り出す。これは、図3cの例示的な概略図を参照して説明される。
【0130】
Aliceのブロックチェーントランザクション402は、ダスト出力(Tx0, Alice)を含み、Bobのブロックチェーントランザクション404は、ダスト出力(Tx0, Bob)を含む。
【0131】
ランデブートランザクションの生成
そして、支払い処理リソース106は、ステップS330において取り出されたブロックチェーントランザクションからのそれぞれのダスト出力を使用するAliceおよびBobの各々のダスト入力を含む新しいランデブーブロックチェーントランザクション406を生成する。ダスト出力は、AliceおよびBobに関連するイベントストリームに対応するダストチェーンから取り出される場合がある。これも、図3cに示される。トランザクション402および404から406へのチェーンは、ダストトランザクションのチェーンとして説明され得る。ダスト入力/出力は、暗号通貨のフィールドによって「ダスト」であると示される暗号通貨の量の入力/出力である。本開示のブロックチェーントランザクションの文脈における「ダスト」は、低いまたは極小の値の出力を有するデジタル資産または暗号通貨に関する使用可能なトランザクションであると理解され、つまり、値は、ブロックチェーンにおいて出力をマイニングするための手数料よりもはるかに少ない場合がある。
そして、支払い処理リソース106は、ステップS330において取り出されたブロックチェーントランザクションからのそれぞれのダスト出力を使用するAliceおよびBobの各々のダスト入力を含む新しいランデブーブロックチェーントランザクション406を生成する。ダスト出力は、AliceおよびBobに関連するイベントストリームに対応するダストチェーンから取り出される場合がある。これも、図3cに示される。トランザクション402および404から406へのチェーンは、ダストトランザクションのチェーンとして説明され得る。ダスト入力/出力は、暗号通貨のフィールドによって「ダスト」であると示される暗号通貨の量の入力/出力である。本開示のブロックチェーントランザクションの文脈における「ダスト」は、低いまたは極小の値の出力を有するデジタル資産または暗号通貨に関する使用可能なトランザクションであると理解され、つまり、値は、ブロックチェーンにおいて出力をマイニングするための手数料よりもはるかに少ない場合がある。
【0132】
代替的に、支払い処理リソース106は、英国特許出願第2102217.3号に記載されているように、既存のイベントストリームの一部を形成しないダストと、階層的決定性(HD: hierarchical deterministic)鍵チェーンとの組合せを用いて新しいダストトランザクションを生成する場合がある。言い換えると、ダストを入力として用い、AliceおよびBobの各々に対応する入力からを含むダストトランザクションが生成され、そのダストは、イベントストリームで既に用いられていない。HD鍵チェーンを所有する関係者は、サブ鍵のうちの1つおよびダストを用いて、新しいイベントストリームの最初のトランザクションを生成してよい。要するに、ブロックチェーン112上の既存のトランザクションから取り出され、新しいイベントストリームの開始のための基礎として用いられ得るダストに基づいて、新しいイベントストリームが開始されてよい。つまり、ダストは、(新しいイベントストリームを開始するために)トランザクションを生成するために用いられ、それから、別のイベントストリームの開始に用いられる前にプラットフォームに返される場合がある。
【0133】
ダストトランザクションのチェーンとイベントストリームとの間の関係が、図3dを参照して以降でさらに明らかにされる。
【0134】
図3dは、本開示の第1の態様に関するものであり、順序付けられた追加専用データストレージシステムの基本的なデータ構造およびパラダイムを示す。これは、データロギングシステムとして説明されることも可能である。図3dに示される特定のシステムは、イベントをロギングするためのイベントストリームシステムである。例として、イベントストリームが、全体を通じて例示を目的として用いられるが、当業者は、本明細書において説明される提案されるシステムおよび態様が、広くデータアイテムとともに、および順序付けられた追加専用データアイテムロギングまたはストレージシステムとともに用いられてよいことを理解するであろう。図4および図6と一貫して、データアイテムは、実際のデータのハッシュを指す。有利なことに、データ自体の代わりにハッシュを用いることは、(大きい場合があり、トランザクションには大きすぎさえする場合がある)データがトランザクションに記憶されることを要求することなく、データの存在の証明を提供する。また、これは、たとえハッシュがチェーン上で公開されるとしても、データがハッシュと見分けられないので、データのプライバシーを守る。ここで説明されるデータは、支払い処理リソース106によって記録されている支払いに関連する支払い指示データである。
【0135】
追加専用ログの各イベント502は、ブロックチェーントランザクション504にマッピングされ、ブロックチェーントランザクションのシーケンスは、「ダストのチェーン」を用いて順序付けられ、リンクされる(506)。各イベントに関連するデータは、各トランザクションの一部として(下で説明される)ペイロードに記憶される。データペイロード(すなわち、支払い指示メタデータのハッシュ)は、トランザクションの使用不可能なOP_RETURN出力に保持される -- そのようなトランザクションの例は、上述のランデブートランザクション406である。これは、ブロックチェーンに任意のデータを書き込み、また、トランザクションの出力を無効とマーキングするために用いられ得るScriptオペコードである。別の例として、OP_RETURNは、トランザクション内にメタデータなどのデータを記憶し、それによって、ブロックチェーン上にメタデータを不変的に記録することができる、トランザクションの使用不可能な出力を作成するためのScript言語のオペコードである。
【0136】
ダストのチェーンは、ここでは、シーケンスの各ブロックチェーントランザクションの、その直接の先任者への支出の依存関係を課すために用いられる暗号通貨の入力および出力の切れ目のない連鎖である。
【0137】
トランザクションにおけるダスト出力の使用は、イベントストリームなどの順序付けられた追加専用データストレージシステムに関して、トランザクションが発生するとおりにすべてのそれらのトランザクションの不変の連続的な記録を維持するために有利であり、重要である。これは、ブロックチェーンにトランザクションを記帳することによって、すべてのブロックチェーントランザクションが、それらがブロックチェーン上で確認されるかまたはブロックチェーンに追加されると、タイムスタンプを付けられ、特定の順序であり続けるが、これが、それらのトランザクションの発生順の保存を保証しないからである。これは、トランザクションが異なる時間にブロックにマイニングされる可能性があり、および/またはトランザクションが同じブロック内でさえも異なる順序であるからである。有利なことに、シーケンスの次のトランザクションの最初の入力によって使用されるダスト出力の使用は、トランザクションの順序が時系列的に追跡され、イベント自体とイベントの発生順との両方の改ざん防止記録が作成されることを保証する。これは、ブロックにマイニングされると、シーケンスの前のトランザクションから次のトランザクションへのダストの支払いが、ビットコインのプロトコル規則に合致して、ペイロードと呼ばれ、下で検討される埋め込まれたデータキャリア要素のシーケンスが順序を変更され得ず、イベントストリームが侵害されたことが直ちに明らかなることなくシーケンスを変更する可能性がある挿入または削除が発生しない可能性があることを保証するからである。一部の実施形態においては、ビットコインプロトコルに固有の二重支払い防止メカニズムが、異なるトランザクションの入力と出力との間の暗号通貨(たとえば、ダスト)の移動が時系列順のままであることを保証する。ダストトランザクションの連鎖は、ブロック間およびブロック内のトランザクション(ならびに、したがって、関連するイベントおよびデータ)の順序の保存を提供するために、トポロジカルな順序付け(topological ordering)を利用する。したがって、これは、順序付けられた追加専用データアイテムストレージの完全性を改善する。
【0138】
このようにして、ブロックチェーントランザクション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」に言及する箇所に見つけられ得る。
【0139】
図3cに示されたトランザクション406などのランデブーブロックチェーントランザクションは、それぞれが上述の所与のエンティティ/ユーザに関連する複数のイベントストリームを同期するためのブロックチェーントランザクションである。これは、複数のダスト出力を対応する入力として使用することによって実現される。この例において、これは、Alice、Bob、およびHSBCの各々に対応するダストのチェーン(すなわち、ダスト入力/出力ペア)が単一のトランザクションを通過することを可能にする。ダストチェーン入力/出力ペアは、トランザクション内に対応する入力/出力インデックスを有していなければならない。この場合、ダストチェーン入力/出力ペアは、下記のように、トランザクションに関連するすべてのイベントストリームに支払いが記録されることを可能にするために用いられる。
【0140】
Aliceのダスト出力を使用するダスト入力は、Tx1, Aliceと表記され、Bobのダスト出力を使用するダスト入力は、Tx1, Bobと表記される。ステップS332において、新しいランデブーブロックチェーントランザクション406が生成される。
【0141】
ランデブーブロックチェーントランザクション406への資金は、支払い処理リソース106によって追加され、支払い処理リソース106に払い戻される。これは、ランデブーブロックチェーントランザクション406が有効化のためにブロックチェーン112に送信される場合、ランデブーブロックチェーントランザクション406の有効化後に任意のマイナーの手数料を引かれる場合がある。
【0142】
ランデブーブロックチェーントランザクション406は、Tx1, AliceおよびTx1, Bobをそれぞれ使用するさらなるダスト出力を含む。それがランデブートランザクションであるとき、AliceおよびBobにそれぞれ対応する入力/出力ペアのインデックスは、たとえば、Tx1, Aliceの入力インデックスが番号1として割り振られる場合があり、対応するダスト出力の出力インデックスが出力インデックス番号1として割り振られるという点で同一である。
【0143】
また、支払い処理リソース106は、データキャリア412aおよび412bの形態で、AliceおよびBobの各々に関して、ブロックチェーントランザクション406に使用不可能であることが証明可能な出力を追加する。
【0144】
データキャリアの各々は、異なるdataDigestおよび/または異なるstreamDigestを保持してよく、streamDigestは、ソルト化される場合もある。
【0145】
それぞれのデータキャリア内に保持されるデータペイロード(すなわち、支払い指示メタデータのハッシュ)は、トランザクションの使用不可能なOP_RETURN出力に保持され、これは、データペイロードが、その後、使用不可能な出力としてブロックチェーンに記憶され得ることを意味する。これは、データキャリア内に保持されるデータペイロード(すなわち、支払い指示メタデータのハッシュ)が、トランザクションの使用不可能なOP_RETURN出力に保持されることを意味し、これは、データペイロードが、その後、使用不可能な出力としてブロックチェーンに記憶され得ることを意味する。
【0146】
データキャリア412内のデータは、ステップS300からS328において支払い処理リソースによって生成された支払い指示データセットのハッシュを含む。これは、ステップS334において生成される。使用不可能であることが証明可能な出力は、ランデブートランザクション406がトランザクション内で支払い指示データセットのハッシュを運ぶことを可能にし、ハッシュがブロックチェーン上に記憶されることを可能にする。これは、支払い指示データセットと、ひいては支払いのレコードとがブロックチェーン上に記憶されることを意味する。これは、支払いのレコードがブロックチェーンの不変性の恩恵を受けることを意味する。
【0147】
それから、ブロックチェーントランザクション406は、トランザクションとのユーザの対応が正しく、ユーザ、すなわち、AliceおよびBobに対応するかどうかを確かめるためにチェックされてよい。これが、ステップS336である。
【0148】
支払い処理リソース106は、ステップS338において、イベントストリーム、すなわち、AliceおよびBobに関するイベントストリームにデータを付け加えるための基礎としてブロックチェーントランザクション406が用いられ得ることを確認する通知をイベントストリームリソース110に発行する。
【0149】
イベントストリームは、ブロックチェーンによって支援された追加専用ログである。この例において、AliceおよびBobは、それぞれ、自分のイベントストリームを持っているが、持っていない場合は、イベントストリームが初期化されてよい。つまり、Aliceは、イベントストリーム(E-Alice)を有し、Bobは、イベントストリーム(E-Bob)を有する。イベントストリームのエントリは、ESnと表記される場合があり、nは、ゼロでない正の整数または非負の整数である場合がある。
【0150】
図3dに示されるように、イベントストリームは、一連のエントリとして示されることが可能であり、ストリーム内のいずれのエントリも、単調に増加する連番によって参照されてよく、すなわち、最初のエントリが、ES1と呼ばれる場合があり、2番目のエントリが、ES2と呼ばれる場合がある。
【0151】
支払い処理リソース106は、AliceおよびBobがイベントストリームにアクセスするまたは付け加えることを認可される場合にのみ、それぞれのイベントストリームに付け加える。認可は、たとえば、署名を支払い処理リソース106において記憶された署名と比較することによってチェックされてよい。支払いデータをイベントストリームに付け加えることによって、支払いは、記録され、ブロックチェーン112に関連付けられる不変のログに記録されることから恩恵を受けることができる。手短に言えば、イベントストリームは、AliceおよびBobに関連するアカウントからのトランザクションの順序を追跡するために用いられる。つまり、イベントストリームのエントリは、ブロックチェーン112に関連する不変のログである。上述のイベントストリームは、以下を保証する。
・イベントストリームの個々のエントリが、書き込まれてから修正されていないこと
・以前に連続していたエントリの間にエントリが挿入されていないこと
・エントリが削除されていないこと
・エントリが順序を変更されていないこと
・認可されていない関係者が、ストリームにイベントを付け加えてはならないこと
・イベントストリームの個々のエントリが、書き込まれてから修正されていないこと
・以前に連続していたエントリの間にエントリが挿入されていないこと
・エントリが削除されていないこと
・エントリが順序を変更されていないこと
・認可されていない関係者が、ストリームにイベントを付け加えてはならないこと
【0152】
支払い処理リソース106は、ランデブートランザクション406を用いて、ブロックチェーントランザクション406のデータキャリアに含まれる支払い指示メタデータのハッシュを含むエントリをそれらのイベントストリームの各々に付け加えることによって、支払いをイベントストリームE-AliceおよびE-Bobと同期する。これが、ステップS340である。これは、図3eに概略的に示される。
【0153】
次に、支払い処理リソース106は、イベントストリームの各々に追加されたエントリの識別子を生成する。これが、ステップS342である。識別子は、英数字であってよく、または支払い指示メタデータのハッシュに基づいて生成される数字であってよい。たとえば、支払い指示メタデータのハッシュがSHA256暗号によって生成される場合、識別子は、支払い指示メタデータのハッシュにさらなるSHA256暗号を適用することによって生成されてよい。つまり、識別子は、支払い指示メタデータのハッシュのハッシュであってよい。
【0154】
そして、支払い処理リソース106は、識別子を、支払い指示メタデータのコピーと一緒に支払いデータストア124に記憶する。これは、要求に応じた、AliceとBobとの間の支払いの検証を可能にする。
【0155】
以降、やはりAliceがBobに5GBPの総和を支払うが、BobのアカウントがHSBCではなくRevolutによって提供されるさらなる例示的なシナリオを説明する。これは、図4aおよび図4bを参照して説明される。この例は、ステップS326までは図3aから図3eを参照して説明された例と同一である。したがって、簡潔にするために、ステップS326を参照して説明された段階から説明を始める。
【0156】
言い換えると、ステップS326が肯定的な結果をもたらし、トランザクションが進むためには、銀行の釣り合いがとれている必要がある。つまり、銀行と資産の識別情報との両方を釣り合わせるメタデータが作成される必要がある。
【0157】
つまり、関係者に対応するデータ中でフィールドをチェックすることによって、支払いに関連するデータがトランザクションの2人の関係者間で一致しているかどうかを(ステップS326において)支払いプロトコルモジュール120によってチェックすると。通貨が同じであり、金額が互いに補完し合っている、すなわち、Aliceが-5GBPの引き落としを受け、Bobが5GBPの入金を受けるが、アカウントの提供者は異なっており、すなわち、Aliceのアカウントの提供者は「hsbc.com」であり、Bobのアカウントの提供者は「Revolut」であることが分かる。
【0158】
これを示す別の方法は、銀行および資産の識別情報を示すためのテンプレート(XXX_BBBB:AAAA)を利用してよく、XXXは、アカウントの運用者であり、BBBBは、銀行の識別情報であり、AAAAは、資産の識別情報である。この場合、Alice_HSBC:GBPからBob_REVOLUT:GBPに5GBPを送金する試みは、完了され得なかった。
【0159】
そのとき、支払いプロトコルモジュール120は、支払いプロトコル基準に対する支払い指示データセットのチェックを停止する。そして、支払い処理リソース106が、支払い指示データセットに追加されるさらなるメタデータを生成する。
【0160】
2つの異なる銀行に関するさらなるメタデータの生成
支払い処理リソース106は、「Revolut.com」および「HSBC」に対応する暗号鍵の要求によって鍵ストレージモジュール122にアクセスする。これが、ステップS400である。
支払い処理リソース106は、「Revolut.com」および「HSBC」に対応する暗号鍵の要求によって鍵ストレージモジュール122にアクセスする。これが、ステップS400である。
【0161】
鍵ストレージモジュール122は、複数の暗号鍵を記憶する。各暗号鍵は、「Revolut.com」または「HSBC」などの銀行に対応するレコードに記憶され、これらの銀行によって管理されるアカウントへの支払いおよびそれらのアカウントからの支払いに関して、支払い処理リソース106が独自の支払い指示データを生成することを可能にする.これは、たとえ関係者が自分のアカウントのために選択する銀行が異なっていても、支払いが支払い処理リソース106によって安全に可能にされ得ることを意味するので、異なる銀行のアカウントの間で支払いが行われているときに特に有利である。
【0162】
鍵ストレージモジュール122がアクセスされるとき、鍵ストレージモジュール122は、要求された鍵に対応する銀行を特定する入力を受信する。鍵ストレージモジュール122は、銀行に対応する鍵を返す。この例においては、銀行「Revolut.com」および「HSBC」に対応する鍵が返される。これが、ステップS402である。
【0163】
次に、支払い処理リソース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によって不一致が解決される。
【0164】
上述したテンプレートを用いて、さらなるメタデータを含むように支払い指示データセットを修正することは、Alice_HSBC:GBPからHSBC_HSBC:GBPに5GBPが支払われ、次に、HSBC_HSBC:GBPからHSBC_REVOLUT:GBPに5GBPが支払われ、そして、HSBC_REVOLUT:GBPからBob_REVOLUT:GBPに支払いが行われることを意味し、これは、銀行の識別情報および資産の識別情報が釣り合っており、トランザクションが完了され得ることを意味する。
【0165】
銀行が一致していなかったために、ステップS326が最初に否定的な結果を返したので、支払いプロトコルモジュール120は、支払いプロトコルに鑑みて支払い指示データセットを評価するために再び開始する必要がある。支払い指示データセットは、ステップS322およびS324に関連して示されたように、ゼロサム規則およびAliceの支出限度の充足に関する肯定的な判定を既に返した。銀行間の一致の欠如を解決し、資産の識別情報および銀行が釣り合っていることを保証するために支払い処理リソース106によって導入された支払いを含むように支払い指示データセットが今や修正されたので、支払い処理モジュール120は、AliceおよびBobの暗号署名が確認されるステップS406に移る。
【0166】
支払い処理モジュール120は、各署名のハッシュを生成し、ハッシュをステップS200からS214において生成されたレコードに記憶されたものと比較することによって、AliceおよびBobの暗号署名を確認する。これは、AliceおよびBobのアイデンティティも確認する。代替的または追加的に、プライベート/公開暗号鍵ペアに基づく標準的なPKI技術も、各署名を確認するために用いられてよい。これらの技術は、クライアントのアイデンティティを検証するためにも用いられ得る。また、支払い処理モジュール120は、同様の技術を用いて、2つの銀行、すなわち、HSBCおよびRevolutの署名を確認する。
【0167】
ステップS406が完了すると、支払い処理リソース106は、支払い指示データセットに従って、AliceからBobへの5GBPの支払いが行われることを可能にする。つまり、支払い処理リソース106は、2つのさらなる支払いを適用して一致の欠如を解決し、支払い指示データセットを、支払い指示データセットを用いて支払いを行うのに好適にすることによって支払い指示データセットにおける一致の欠如を解決する。
【0168】
2つの銀行によるランデブートランザクション
次に、支払い処理リソース106は、ステップS408において、AliceおよびBobの各々に関して、ブロックチェーン112からブロックチェーントランザクションを取り出す。これは、図4bの例示的な概略図を参照して説明される。
次に、支払い処理リソース106は、ステップS408において、AliceおよびBobの各々に関して、ブロックチェーン112からブロックチェーントランザクションを取り出す。これは、図4bの例示的な概略図を参照して説明される。
【0169】
Aliceのブロックチェーントランザクション602は、ダスト出力(Tx0, Alice)を含み、Bobのブロックチェーントランザクション604は、ダスト出力(Tx0, Bob)を含む。支払い処理リソース106は、支払いに関わる銀行、すなわち、HSBCとRevolutのブロックチェーントランザクションも取り出す。HSBCの取り出されたブロックチェーントランザクション608は、ダスト出力(Tx0, HSBC)を含む。Revolutの取り出されたブロックチェーントランザクション610は、ダスト出力(Tx0, Revolut)を含む。
【0170】
そして、支払い処理リソース106は、ステップS408において取り出されたブロックチェーントランザクションからのそれぞれのダスト出力を使用するAliceおよびBobの各々のダスト入力を含む新しいランデブーブロックチェーントランザクション606を生成する。ダスト出力は、AliceおよびBobに関連するイベントストリームに対応するダストチェーンから取り出される場合がある。これも、図4bに示される。ランデブーブロックチェーントランザクション606は、それぞれブロックチェーントランザクション408および410から取り出されたHSBCおよびRevolutのダスト入力をさらに含む。
【0171】
代替的に、第1の例と同様に、支払い処理リソース106は、既存のイベントストリームの一部を形成しないダストと、階層的決定性(HD)鍵チェーンとを用いて新しいダストトランザクションを生成する場合がある。
【0172】
ダストトランザクションのチェーンとイベントストリームとの間の関係は、図3dを参照して既に明らかにされた。
【0173】
ランデブーブロックチェーントランザクション606は、Alice、Bob、Revolut、およびHSBCの各々に対応する複数のイベントストリームを同期するためのブロックチェーントランザクションである。
【0174】
Aliceのダスト出力を使用するダスト入力は、(Tx1, Alice)と表記され、Bobのダスト出力を使用するダスト入力は、(Tx1, Bob)と表記される。ステップS410において、新しいランデブーブロックチェーントランザクション606が生成される。また、新しいランデブートランザクションは、それぞれ(Tx1, HSBC)と表記されるHSBCに対応するダスト入力と、それぞれ(Tx1, Revolut)と表記されるRevolutに対応するダスト入力を含む。
【0175】
ランデブーブロックチェーントランザクション606への資金は、支払い処理リソース106によって追加され、支払い処理リソース106に払い戻される。これは、ランデブーブロックチェーントランザクション606が有効化のためにブロックチェーン112に送信される場合、ランデブーブロックチェーントランザクション606の有効化後に任意のマイナーの手数料を引かれる場合がある。
【0176】
ランデブーブロックチェーントランザクション606は、Tx1, AliceおよびTx1, Bobをそれぞれ使用するさらなるダスト出力を含む。ランデブーブロックチェーントランザクション606は、HSBCおよびRevolut.comに関してブロックチェーンから取り出されたダスト入力に対応するダスト出力も含む。
【0177】
また、支払い処理リソース106は、ブロックチェーントランザクション606に、使用不可能であることが証明可能な出力を追加する。これは、データキャリア612として用いられる。データキャリアの各々は、同一であり、同じデータに基づき、同じ支払い指示データセットに基づく場合がある。データキャリアは、キャリアが付け加えられている特定のデータストリームのstreamStateに基づくいくつかの異なるデータを保持する場合があり、streamStateは、前のstreamStateおよび/またはインデックス(もしくはシーケンス番号)ならびに/またはそのデータキャリアの公証(notarisation)に用いられる個々のソルトに基づく。代替的または追加的に、ブロックチェーントランザクション606に入力を与えるすべての関係者の各々に関するデータキャリアを付け加えるために、それらの関係者に対応するように、さらなる使用不可能であることが証明可能な出力が追加されてよい。つまり、それぞれのデータキャリアは、それぞれのデータキャリアがそれぞれの関係者に応じて異なっていてよいという点で、それぞれの関係者に関連するデータを含む場合がある。たとえば、違いは、Aliceに関するデータキャリアがAliceにのみ関連するデータ、すなわち、Aliceの名前およびAliceのアカウント番号を含み、Bobに関するデータキャリアがBobにのみ関連するデータ、すなわち、Bobの名前およびBobアカウント番号を含んでよいことである場合がある。
【0178】
第1の例と同様に、データキャリア内に保持されるデータペイロード(すなわち、支払い指示メタデータのハッシュ)が、トランザクションの使用不可能なOP_RETURN出力に保持され、これは、データペイロードが、その後、使用不可能な出力としてブロックチェーンに記憶され得ることを意味する。
【0179】
データキャリア612の各々の中のデータは、支払い処理リソース106によって生成された支払い指示データセットのハッシュを含む。これは、ステップS412において生成される。使用不可能であることが証明可能な出力は、ランデブートランザクション606がトランザクション内で支払い指示データセットのハッシュを運ぶことを可能にし、ハッシュがブロックチェーン上に記憶されることを可能にする。これは、支払い指示データセットと、ひいては支払いのレコードとがブロックチェーン上に記憶されることを意味する。これは、支払いのレコードがブロックチェーンの不変性の恩恵を受けることを意味する。
【0180】
それから、ブロックチェーントランザクション606は、トランザクションならびにHSBCおよびRevolutによって提供されるアカウントとのユーザの対応が正しく、ユーザ、すなわち、AliceおよびBobに対応するかどうかを確かめるためにチェックされてよい。これが、ステップS412である。
【0181】
支払い処理リソース106は、(ステップS416において)イベントストリーム、すなわち、Alice、Bob、Revolut、およびHSBCに関するイベントストリームにデータを付け加えるための基礎としてブロックチェーントランザクション606が用いられ得ることを確認する通知をイベントストリームリソース110に発行する。
【0182】
この例において、Alice、Bob、およびHSBCは、それぞれ、自分のイベントストリームを持っているが、持っていない場合は、イベントストリームが初期化されてよい。つまり、Aliceは、イベントストリーム(E-Alice)を有し、Bobは、イベントストリーム(E-Bob)を有し、HSBCは、イベントストリーム(E-HSBC)を有し、Revolutも(E-Revolut)を有する。
【0183】
支払い処理リソース106は、ランデブートランザクション606を用いて、ブロックチェーントランザクション606のデータキャリアに含まれる支払い指示メタデータのハッシュを含むエントリをそれらのイベントストリームの各々に付け加えることによって、支払いをイベントストリームE-Alice、E-Bob、E-Revolut、およびE-HSBCと同期する。これが、ステップS418である。これは、図4cに概略的に示される。イベントストリームE-Alice、E-Bob、E-Revolut、およびE-HSBCは、異なる長さであってよく、支払い指示データのハッシュは、それぞれのイベントストリーム内の異なる位置(インデックスとしても知られる)に付け加えられてよい。これは、各イベントストリームが異なる数のイベントを含む場合があるからである。たとえば、銀行のような特に活動的な関係者は、個人よりも大幅に長いイベントストリームを有する場合があり、支払い指示データは、個人に関してよりもはるかに大きなインデックスにおいて銀行のイベントストリームに追加される場合がある。イベントストリームに付け加えられたエントリの数が予め決められた量を超えた後、銀行が新しいイベントストリームを開始することを選択する可能性もある。
【0184】
その他の例と同様に、データキャリアの各々は、異なるdataDigestおよび/または異なるstreamDigestを保持する場合がある。streamDigestは、ソルト化される場合もある。RevolutおよびHSBCは、AliceおよびBobによって用いられるハッシュ方法とは異なるハッシュ方法を用いてソルト化されたstreamDigestを生成することを選択する場合がある。
【0185】
次に、支払い処理リソース106は、イベントストリームの各々に追加されたエントリの識別子を生成する。これが、ステップS420である。識別子は、英数字であってよく、または支払い指示メタデータのハッシュに基づいて生成される数字であってよい。たとえば、支払い指示メタデータのハッシュがSHA256暗号によって生成される場合、識別子は、支払い指示メタデータのハッシュにさらなるSHA256暗号を適用することによって生成されてよい。つまり、識別子は、支払い指示メタデータのハッシュのハッシュであってよい。
【0186】
そして、支払い処理リソース106は、識別子を、支払い指示メタデータのコピーと一緒に支払いデータストア124に記憶する。これは、要求に応じた、AliceとBobとの間の支払いの検証を可能にする。
【0187】
以降、やはりAliceがBobに5GBPを支払うが、BobのアカウントがHSBCによって管理されるが、GBPではなくEuroアカウントであるさらなる例示的なシナリオを説明する。
【0188】
これは、図5aおよび図5bを参照して説明される。この例は、ステップS326までは図3aから図3eを参照して説明された例とやはり同一である。したがって、簡潔にするために、ステップS326を参照して説明された段階から説明を始める。
【0189】
つまり、関係者に対応するデータ中でフィールドをチェックすることによって、支払いに関連するデータがトランザクションの2人の関係者間で一致しているかどうかを(ステップS326において)支払いプロトコルモジュール120によってチェックすると。AliceおよびBobのアカウントの通貨が異なっていることが分かる。言い換えると、Aliceは、HSBCにGBPでアカウントを有し、Bobは、HSBCにEuroでアカウントを有し、つまり、同じ銀行であるが通貨が異なり、つまり、資産識別子が異なる。
【0190】
そのとき、支払いプロトコルモジュール120は、通貨が異なるので、支払いプロトコル基準に対する支払い指示データセットのチェックを停止する。そして、支払い処理リソース106が、支払い指示データセットに追加されるさらなるメタデータを生成する。
【0191】
アカウントの通貨が異なる場合のさらなるメタデータの生成
支払い処理リソース106は、GBPに関してHSBCが所有するアカウントおよびEURに関してHSBCが所有するアカウントに対応する暗号鍵の要求によって鍵ストレージモジュール122にアクセスする。これが、ステップS500である。
支払い処理リソース106は、GBPに関してHSBCが所有するアカウントおよびEURに関してHSBCが所有するアカウントに対応する暗号鍵の要求によって鍵ストレージモジュール122にアクセスする。これが、ステップS500である。
【0192】
鍵ストレージモジュール122がアクセスされるとき、鍵ストレージモジュール122は、要求された鍵に対応する銀行ならびにそれぞれの資産識別子、すなわち、GBPおよびEURを特定する入力を受信する。鍵ストレージモジュール122は、銀行のGBPアカウントおよびEURアカウントに対応する鍵を返す。この例においては、HSBCによって管理されるGBPアカウントおよびEURアカウントに対応する鍵が返される。これが、ステップS502である。
【0193】
つまり、この場合、(GBPおよびEURが同じ通貨ではないので)資産は同じ識別情報を有していないが、AliceおよびBobは同じ銀行を確かに有する。これが、この例において、ステップS326が否定的な結果となる原因である。つまり、通貨が異なるので、資産の識別情報および銀行は、完全には一致していない。
【0194】
言い換えると、資産の種類の釣り合いがとれている必要があるので、ステップS326が肯定的な結果をもたらすためには、通貨の釣り合いがとれている必要がある。
【0195】
したがって、支払い処理モジュール120は、この不一致を解決するさらなるメタデータを生成する必要がある。HSBCによって管理されるGBPアカウントおよびEURアカウントに対応する鍵を取得した支払い処理モジュール120は、次に、このメタデータを生成することができる。
【0196】
ステップS504において、支払い処理モジュール120は、2つのさらなる支払いに対応するメタデータを生成する。1つ目は、AliceのGBP HSBCアカウントからHSBCのGBPアカウントへの5GBPの支払いであり(すなわち、AliceがHSBCに5GBPを返し)、そして、2つ目は、HSBCのEURアカウントからBobのEUR HSBCアカウントへの5.81EURの支払いである。
【0197】
ステップS506において、支払い処理モジュール120は、各署名のハッシュを生成し、ハッシュをステップS200からS214において生成されたレコードに記憶されたものと比較することによって、(必要があれば)AliceおよびBobの暗号署名を確認する。これは、AliceおよびBobのアイデンティティも確認する。代替的または追加的に、プライベート/公開暗号鍵ペアに基づく標準的なPKI技術も、各署名を確認するために用いられてよい。これらの技術は、クライアントのアイデンティティを検証するためにも用いられ得る。
【0198】
銀行および資産の識別情報が今や一致しているので、ステップS326の要件が満たされ、支払いプロトコル基準が満たされ得る。つまり、銀行および資産の識別情報を釣り合わせるメタデータが作成される。
【0199】
これを示す別の方法は、銀行および資産の識別情報を示すためのテンプレート(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に換算した額)が支払われることを意味し、これは、銀行の識別情報および資産の識別情報が釣り合っていることを意味し、これは、トランザクションが完了され得ることを意味する。
【0200】
ステップS506が完了すると、支払い処理リソース106は、支払い指示データセットに従って、AliceからBobへの5GBPの支払いが行われることを可能にする。つまり、支払い処理リソース106は、2つのさらなる支払いを適用して一致の欠如を解決し、支払い指示データセットを、支払い指示データセットを用いて支払いを行うのに好適にすることによって支払い指示データセットにおける一致の欠如を解決する。
【0201】
2つの通貨によるランデブートランザクション
次に、支払い処理リソース106は、ステップS508において、AliceおよびBobの各々に関して、ブロックチェーン112からブロックチェーントランザクションを取り出す。これは、図5bの例示的な概略図を参照して説明される。
次に、支払い処理リソース106は、ステップS508において、AliceおよびBobの各々に関して、ブロックチェーン112からブロックチェーントランザクションを取り出す。これは、図5bの例示的な概略図を参照して説明される。
【0202】
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アカウントに関連するイベントストリームに対応するダストチェーンから取り出されてよい。
【0203】
そして、支払い処理リソース106は、ステップS508において取り出されたブロックチェーントランザクションからのそれぞれのダスト出力を使用するAliceおよびBobの各々のダスト入力を含む新しいランデブーブロックチェーントランザクション706を(ステップS510において)生成する。これも、図5bに示される。ランデブーブロックチェーントランザクション706は、それぞれブロックチェーントランザクション708および710から取り出されたHSBC-GBPおよびHSBC-EURのダスト入力をさらに含む。
【0204】
ダストトランザクションのチェーンとイベントストリームとの間の関係は、図3dを参照して既に明らかにされた。
【0205】
ランデブーブロックチェーントランザクション606は、Alice、Bob、Revolut、およびHSBCの各々に対応する複数のイベントストリームを同期するためのブロックチェーントランザクションである。
【0206】
Aliceのダスト出力を使用するダスト入力は、(Tx1, Alice)と表記され、Bobのダスト出力を使用するダスト入力は、(Tx1, Bob)と表記される。新しいランデブートランザクションは、それぞれ(Tx1, HSBC-GBP)および(Tx1, HSBC-EUR)と表記される、HSBCのGBPアカウントおよびEURアカウントに対応するダスト入力も含む。
【0207】
ランデブーブロックチェーントランザクション706への資金は、支払い処理リソース106によって追加され、支払い処理リソース106に払い戻される。これは、ランデブーブロックチェーントランザクション706が有効化のためにブロックチェーン112に送信される場合、ランデブーブロックチェーントランザクション706の有効化後に任意のマイナーの手数料を引かれる場合がある。
【0208】
ランデブーブロックチェーントランザクション706は、Tx1, AliceおよびTx1, Bobをそれぞれ使用するさらなるダスト出力を含む。ランデブーブロックチェーントランザクション706は、HSBC-GBPおよびHSBC-EURに関してブロックチェーンから取り出されたダスト入力に対応するダスト出力も含む。
【0209】
また、支払い処理リソース106は、Alice、Bob、ならびにHSBC-GBPアカウントおよびHSBC-EURアカウントの各々に関して、ブロックチェーントランザクション706に使用不可能であることが証明可能な出力を追加する。これらは、データキャリア712a、712b、712c、および712dとして用いられる。
【0210】
第1の例と同様に、データキャリア内に保持されるデータペイロード(すなわち、支払い指示メタデータのハッシュ)が、トランザクションの使用不可能なOP_RETURN出力に保持され、これは、データペイロードが、その後、使用不可能な出力としてブロックチェーンに記憶され得ることを意味する。
【0211】
第1および第2の例と同様に、支払い処理リソース106は、既存のイベントストリームの一部を形成しないダストと、HD鍵チェーンとを用いて新しいダストトランザクションを生成するように構成される場合がある。既存のダストチェーンからのダスト入力と新しいダストトランザクションとの組合せが、ブロックチェーントランザクション706を生成するために用いられる場合がある。
【0212】
データキャリア712a、712b、712c、および712d内のデータは、支払い処理リソース106によって生成された支払い指示データセットのハッシュを含む。データキャリアは、それらが同じ支払い指示データセットに基づくので同一である場合がある。代替的または追加的に、データキャリア内のデータは、それぞれが異なる関係者に関連するので異なる場合がある。
【0213】
つまり、それぞれのデータキャリアは、それぞれのデータキャリアがそれぞれの関係者に応じて異なっていてよいという点で、それぞれの関係者に関連するデータを含む場合がある。たとえば、違いは、Aliceに関するデータキャリアがAliceにのみ関連するデータ、すなわち、Aliceの名前およびAliceのアカウント番号を含み、Bobに関するデータキャリアがBobにのみ関連するデータ、すなわち、Bobの名前およびBobアカウント番号を含んでよいことである場合がある。
【0214】
したがって、データキャリアは、異なるハッシュを生成する。これは、ステップS512において生成される。使用不可能であることが証明可能な出力は、ランデブートランザクション706がトランザクション内で支払い指示データセットのハッシュを運ぶことを可能にし、ハッシュがブロックチェーン上に記憶されることを可能にする。これは、支払い指示データセットと、ひいては支払いのレコードとがブロックチェーン上に記憶されることを意味する。これは、支払いのレコードがブロックチェーンの不変性の恩恵を受けることを意味する。
【0215】
上述の例と同様に、データキャリアの各々は、異なるdataDigestおよび/または異なるstreamDigestを保持する場合がある。
【0216】
それから、ブロックチェーントランザクション706は、トランザクションならびに(GBPとEURとの両方に関する)HSBCによって提供されるアカウントとのユーザの対応が正しく、ユーザ、すなわち、AliceおよびBobに対応するかどうかを確かめるためにチェックされてよい。これが、ステップS514である。
【0217】
支払い処理リソース106は、(ステップS516において)イベントストリーム、すなわち、Alice、Bob、Revolut、およびHSBCに関するイベントストリームにデータを付け加えるための基礎としてブロックチェーントランザクション606が用いられ得ることを確認する通知をイベントストリームリソース110に発行する。
【0218】
この例において、Alice、Bob、および(GBPとEURとの両方に関する)HSBCは、それぞれ、自分のイベントストリームを持っているが、持っていない場合は、イベントストリームが初期化されてよい。つまり、Aliceは、イベントストリーム(E-Alice)を有し、Bobは、イベントストリーム(E-Bob)を有し、HSBCは、両方の通貨に関するイベントストリーム、すなわち、(E-HSBC-GBP)および(E-HSBC-EUR)を有する。
【0219】
支払い処理リソース106は、ランデブートランザクション706を用いて、ブロックチェーントランザクション706のデータキャリアに含まれる支払い指示メタデータのハッシュを含むエントリをそれらのイベントストリームの各々に付け加えることによって、支払いをイベントストリームE-Alice、E-Bob、E-HSBC-GBP、およびE-HSBC-EURと同期する。これが、ステップS518である。つまり、データ出力712aがAliceに対応する場合、データ出力712aは、ハッシュされ、Aliceのイベントストリームに追加される。これは、図5cに概略的に示される。各エントリは、そのエントリまでのストリームに含まれるデータのハッシュされたダイジェストを含む。ストリームのそのようなハッシュされたダイジェストは、ストリームにエントリとともに記憶される。
【0220】
次に、支払い処理リソース106は、イベントストリームの各々に追加されたエントリの識別子を生成する。これが、ステップS520である。その他の例と同様に、識別子は、英数字であってよく、または支払い指示メタデータのハッシュに基づいて生成される数字であってよい。たとえば、支払い指示メタデータのハッシュがSHA256暗号によって生成される場合、識別子は、支払い指示メタデータのハッシュにさらなるSHA256暗号を適用することによって生成されてよい。つまり、識別子は、支払い指示メタデータのハッシュのハッシュであってよい。
【0221】
そして、支払い処理リソース106は、識別子を、支払い指示メタデータのコピーと一緒に支払いデータストア124に記憶する。これは、要求に応じた、AliceとBobとの間の支払いの検証を可能にする。
【0222】
以降、図6aおよび図6bを参照して、Aliceが支払い処理リソース106を用いてBobに支払いを送信する例示的なシナリオを説明する。支払いは、ある量の金に関する場合がある。ある量の金は、資産の一例であり、その譲渡およびその支払いが、下で説明される方法によって記録される。
【0223】
ステップS600において、Aliceは、Bobに連絡を取って、Aliceが49.20GBPと引き換えに1gの金を獲得したいことをBobに知らせる。ステップS602において、BobはAliceに価格、すなわち、49.20GBPを知らせる。AliceとBobとの両方は、たとえば、Ynysmaerdy, Pontyclun CF72 8YT(royalmint.com)に住所を持つ英国の王立造幣局などの金の発行者にアカウントを登録済みである。これは、下で説明されるように、AliceおよびBobが合法的で記録可能な方法で金を売買することを可能にする。
【0224】
それから、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に送信される支払いメタデータのセットを形成する。
【0225】
つまり、支払い処理リソース106に対して、資産がGBPであるものとして特定され、銀行も特定される。
【0226】
支払い処理リソース106は、Aliceから支払いメタデータを受信すると、ステップS608においてAliceが提供したメタデータに基づいて、Bobのアカウントからメタデータを取り出す。これが、ステップS610である。支払い処理リソース106は、Bobのアカウントが関連する通貨、すなわち、スターリングポンド(GBP)および金の発行者のアカウント、すなわち、王立造幣局をBobのアカウントから取り出す。
【0227】
次に、支払い処理リソース106は、ステップS612において、Aliceから受信された支払いメタデータおよびBobのアカウントから取り出された情報を用いて、支払い指示データセットを生成する。
【0228】
この例において、Bobの銀行アカウントの提供者は「HSBC」(すなわち、Aliceと同じ)であり、通貨はGBPと特定され、支払いの額(すなわち、Bobによって受け取られている金額)は49.20GBPであり、アカウントの識別情報は<Bob:HSBC>によって与えられ、ユーザは「kyc」値によってBobと特定され、行為者は支払いの受取人、すなわち、支払いを受ける個人と特定される。これは、支払い指示データセットのさらなる部分を形成する。支払い指示データセットは、任意で、署名<Bob_sig>を用いてBobによって署名された条項および条件のバージョンも含む場合がある。
【0229】
支払い指示データセットのさらなる部分が、金のトランザクションの詳細によって形成される。支払い処理リソース106は、Bobの金アカウントの発行者、すなわち、王立造幣局におけるBobの金アカウントへのアクセスを要求する。支払い処理リソース106は、アクセスが許可されることを可能にするためのBobの署名の要求を与えられる。そのとき、支払い処理リソース106は、Bobに対応するユーザプロファイルからBobの暗号署名を取り出すか、またはBobの金アカウントに対応する署名の、Bobへの個別の要求によってBobの暗号署名を取り出すかのどちらかである場合がある。署名は、Bobの「HSBC」アカウントのBobの署名と同じである場合がありまたは異なる場合がある。Bobの署名は、特に、大量の金または金に関連する商取引のために必要とされる場合があり、条項および条件のセットが含まれる場合があり、それらの条項および条件に対するAliceまたはBobによる証明の必要性がある場合がある。
【0230】
支払い指示データセットの別の部分は、Aliceの詳細によって形成される。すなわち、Aliceのアカウントの提供者は「hsbc.com」であり、通貨はGBPと特定され、Bobに送金されている支払いの額は49.20GBPであり(すなわち、Bobに支払われるAliceからの49.20GBPの引き落としであり、したがって、支払い指示データセットにおいては-49.20と表現される)、アカウントの識別情報は<Alice:HSBC>によって与えられ、ユーザは「kyc」値によってAliceと特定され、Aliceによって署名された条項および条件はAliceによって与えられるURLにおいて提供される署名されたドキュメントおよび前記ドキュメントのハッシュによって特定される。行為者は、支払いの送金人、すなわち、支払いを行う個人として特定される。
【0231】
支払い処理リソース106は、発行者、すなわち、王立造幣局におけるAliceの金アカウントへのアクセスも要求する。支払い処理リソース106は、アクセスが許可されることを可能にするためのAliceの署名の要求を与えられる。
【0232】
それから、ステップS614において、支払い指示データセットへのAliceの署名の要求とともに、メッセージが第1のコンピューティングデバイス102に送信される。そして、Aliceは、Bobへの49.20GBPの支払いを承認するために、ステップS516において自分の暗号署名を提供する。そのとき、署名は、支払い処理リソース120によって支払い指示データセットに適用される。Aliceの金アカウントに対応する署名は、「hsbc.com」のAliceのアカウントに関する署名とは異なる署名である場合がある。署名が異なる場合、Aliceは、ステップS616において両方の署名を提供する。支払い処理リソース106は、代替的に、Aliceの金アカウントの署名に既にアクセスした可能性がある。つまり、支払い処理リソース106がAliceによって信頼されている場合、Aliceからの署名の取り出しは任意である。
【0233】
次に、支払い処理リソース106は、Bobの金アカウントからAliceの金アカウントへの金の譲渡に対応するさらなるメタデータを生成する。メタデータは、AliceからBobへの支払いと、一方の金アカウントから他方の金アカウントへの譲渡を詳述する。
【0234】
それから、支払い処理リソース106は、ステップS618において、支払い指示データセットに支払いプロトコル基準を適用する。支払い処理リソース106は、ステップS620において、支払いプロトコルモジュール120にアクセスする。
【0235】
支払いプロトコルモジュール120は、まず、支払い指示データセットが、金額が一致しているという点でゼロサム規則を遵守すること、すなわち、Aliceのアカウントから引き出されている額がBobのアカウントに支払われている額と等しいことをチェックする。これが、ステップS622である。Aliceのアカウントから49.20GBPが引き出されており、Bobのアカウントに49.20GBPが支払われているので、ゼロサム規則は遵守される。金額の不一致は、たとえば、異なる通貨に起因する可能性がある。つまり、支払いプロトコルモジュール120は、資産の識別情報および銀行の識別情報が一致していると判定する(それは、上記のテンプレートに従って、Alice_HSBC:GBPがBob_HSBC:GBPと釣り合い、Alice_MINT:GOLDがBob_MINT:GOLDと釣り合うからである)。
【0236】
代替的または追加的に、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の支払いとを詳述する。このさらなるメタデータも、それらのアカウントに対応する暗号署名によって署名される。
【0237】
任意でまたは追加的に、第1のブローカーがRevolutアカウント内のみの、すなわち、異なる銀行間でないEURからGBPへの両替を提供するだけであった場合、支払いプロトコルモジュール120は、第1のブローカーに加えて第2のブローカーによって担われる役目に対応するさらなるメタデータを生成する必要がある。このメタデータは、Bobの金アカウント(Bob_MINT:GOLD)からAliceの金アカウント(Alice_MINT:GOLD)への合意された量の金の譲渡と、AliceのEURアカウント(Alice_REVOLUT:GOLD)から第1のブローカーによって保有されるEURアカウント(すなわち、Broker1_REVOLUT:EURと特定されるRevolutのEURアカウント)への支払いと、第1のブローカーのGBPアカウント(すなわち、Broker1_REVOLUT:GBPと特定されるRevolutのGBPアカウント)から第2のブローカーのHSBCのGBPアカウント(Broker2_HSBC:GBP)への支払いと、第2のブローカーのGBPアカウント(Broker2_HSBC:GBP)からBobのHSBCのGBPアカウント(Bob_HSBC:GBP)への支払いとを詳述する。つまり、支払いプロトコルモジュール120は、ステップS622においてチェックされた支払い指示メタデータの側面の間の不一致(または対応の欠如)に対処するためのメタデータのセットを構築するために用いられ得る。
【0238】
それから、支払いプロトコルモジュール120は、AliceからBobに送金されている額がAliceの残高を何らかの最小値未満にしないことをチェックする。これが、ステップS624である。つまり、AliceはBobから獲得している金にお金を使いすぎているのか?Aliceがお金を使いすぎている場合、すなわち、Aliceの残高が最小値を未満になる場合、支払いプロトコルモジュール120は、Aliceにエラーメッセージを発行して、Aliceが使いたいお金を使うことができないことをAliceに知らせる。さらに言えば、与信枠が用いられている場合、最小値はマイナスになることがあり得る。支払いプロトコルモジュール120は、再び開始する指示が与えられるまで、すなわち、Aliceがより多くの資金を自分のアカウントに預け入れたか、またはAliceの最低残高が変更されたとき、ステップS520に戻る。
【0239】
次に、支払いプロトコルモジュール120は、発行者に対応するデータ中でフィールドをチェックすることによって、支払いに関連するデータがトランザクションの2人の関係者間で一致しているかどうかをチェックする。これが、ステップS626である。アカウントを提供する関係者が同一であり、資産の識別情報が同一であるか、または資産識別子もしくは資産レジストリが一致していない資産の譲渡において不一致を解決する際にブローカーが果たすことができる役割に対応するさらなるメタデータを支払いプロトコルモジュール120が導入することによって一致の欠如が解決されたので、データは2人の関係者間で一致している。譲渡が金に関するとき、BobからAliceに譲渡されている金の量は、Aliceのアカウントに追加されている金の量を補完しなければならない。
【0240】
つまり、譲渡が可能にされるためには、譲渡の両側で特定される銀行および資産識別子の間に一致がなければならないという要件がある。GBPと金との両方に関してゼロサム規則が満たされる要件もある。
【0241】
支払い処理モジュール120は、各署名のハッシュを生成し、ハッシュをステップS200からS214において生成されたレコードに記憶されたものと比較することによって、AliceおよびBobの暗号署名を確認する。これが、ステップS628である。これは、AliceおよびBobのアイデンティティも確認する。代替的または追加的に、プライベート/公開暗号鍵ペアに基づく標準的なPKI技術も、各署名を確認するために用いられてよい。これらの技術は、クライアントのアイデンティティを検証するためにも用いられ得る。支払い処理モジュール120は、同様の技術を用いてAliceおよびBobの金アカウントの署名も確認する。また、支払い処理モジュール120は、Bobのアカウントに対するチェックを実行して、必要な量の金がBobの名義で記録され、したがって、それがBobからAliceに譲渡され得ると判定する。ブローカーも用いられた場合、仲介アカウントに対応する暗号署名も確認される。
【0242】
ステップS622、S624、S626、およびS628の充足は、支払いプロトコルによって規定された基準が満たされたことを意味し、したがって、支払い処理リソース106は、支払い指示データセットに従って、AliceからBobへの49.20GBPの支払いが行われることを可能にする。そしてまた、金の譲渡は、金アカウントの発行者によって記録され得る。
【0243】
次に、支払い処理リソース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の金アカウントに関連するイベントストリームに対応するダストチェーンから取り出される場合がある。
【0244】
追加の発行者によるランデブートランザクションの生成
そして、支払い処理リソース106は、ステップS530において取り出されたブロックチェーントランザクションからのそれぞれのダスト出力を使用するAliceおよびBobの各々のダスト入力を含む新しいランデブーブロックチェーントランザクション806を生成する。これは、図7に示される。ランデブーブロックチェーントランザクション806は、ブロックチェーントランザクション808および810から、すなわち、AliceおよびBobの金アカウントに関して取り出された対応する出力を使用するダスト入力をさらに含む。
そして、支払い処理リソース106は、ステップS530において取り出されたブロックチェーントランザクションからのそれぞれのダスト出力を使用するAliceおよびBobの各々のダスト入力を含む新しいランデブーブロックチェーントランザクション806を生成する。これは、図7に示される。ランデブーブロックチェーントランザクション806は、ブロックチェーントランザクション808および810から、すなわち、AliceおよびBobの金アカウントに関して取り出された対応する出力を使用するダスト入力をさらに含む。
【0245】
取り出されたブロックチェーントランザクションの各々は、OP_RETURNスクリプト、すなわち、使用不可能であることが証明可能な出力に関連するデータキャリアも含む場合がある。
【0246】
Aliceのダスト出力を使用するダスト入力は、Tx1, Aliceと表記され、Bobのダスト出力を使用するダスト入力は、Tx1, Bobと表記される。新しいランデブートランザクションは、それぞれ(Tx1, RYA)および(Tx1, RYB)と表記される、AliceおよびBobが保有する金アカウントに対応するダスト入力も含む。ランデブーブロックチェーントランザクション806は、ステップS632において生成される。
【0247】
ランデブーブロックチェーントランザクション806への資金は、支払い処理リソース106によって追加され、支払い処理リソース106に払い戻される。これは、ランデブートランザクション806が有効化のためにブロックチェーン112に送信される場合、ランデブートランザクション806の有効化後に任意のマイナーの手数料を引かれる場合がある。
【0248】
ランデブーブロックチェーントランザクション806は、Tx1, AliceおよびTx1, Bobをそれぞれ使用するさらなるダスト出力を含む。ランデブーブロックチェーントランザクション806は、2つの金アカウントに関してブロックチェーンから取り出されたダスト入力に対応するダスト出力も含む。それがランデブートランザクションであるとき、Alice、Bob、および2つの金アカウントにそれぞれ対応する入力/出力ペアのインデックスは、たとえば、Tx1, Aliceの入力インデックスが番号1として割り振られる場合があり、対応するダスト出力の出力インデックスが出力インデックス番号1として割り振られるという点で同一である。
【0249】
また、支払い処理リソース106は、Alice、Bob、および2つの金アカウントに関してブロックチェーントランザクション806に使用不可能であることが証明可能な出力を追加する。これらは、データキャリア812a、812b、812c、および812dとそれぞれ表記される。
【0250】
トランザクションに関与するブローカーに対応する使用不可能であることが証明可能な出力も、追加される場合がある。それらの使用不可能であることが証明可能な出力は、ブローカーのデータキャリアに対応する。
【0251】
その他の例と同様に、データキャリアの各々は、異なるdataDigestおよび/またはstreamDigestを保持する場合がある。streamDigestは、その他の例と同様に、ソルト化される場合がある。
【0252】
また、ブロックチェーントランザクション806は、イベントストリームの基礎として既に使用されていないダストを用いて生成される場合がある。この「新しいダスト」は、その他の例と同様にブロックチェーントランザクション806を生成するために、英国特許出願第2102217.3号に記載されているように、HD鍵チェーンと組み合わせて用いられる。
【0253】
その他の例と同様に、それぞれデータキャリア内に保持されるデータペイロード(すなわち、支払い指示メタデータのハッシュ)が、トランザクションの使用不可能なOP_RETURN出力に保持され、これは、データペイロードが、その後、使用不可能な出力としてブロックチェーンに記憶され得ることを意味する。第1の例と同様に、トランザクションの使用不可能なOP_RETURN出力に保持されるデータキャリア内に保持されるデータペイロード(すなわち、支払い指示メタデータのハッシュ)を保持することは、データペイロードが、その後、使用不可能な出力としてブロックチェーンに記憶され得ることを意味する。
【0254】
データキャリア内のデータは、ステップS600からS628において支払い処理リソースによって生成された支払い指示データセットのハッシュを含む。データキャリア内のデータは、それが同一の支払い指示データセットに基づくという点で同一である場合がある。代替的または追加的に、各データキャリアのそれぞれのハッシュは、データが異なるので異なる場合がある。たとえば、Aliceのデータは、それがAliceのアカウントの活動に関連し、Bobのアカウントの活動に関連しないのでBobのデータとは異なる。これが、ステップS634である。使用不可能であることが証明可能な出力(provably unspendable output)は、ランデブートランザクション806がトランザクション内で支払い指示データセットのハッシュを運ぶことを可能にし、ハッシュがブロックチェーン上に記憶されることを可能にする。これは、支払い指示データセットと、ひいては支払いのレコードとがブロックチェーン上に記憶されることを意味する。これは、支払いのレコードがブロックチェーンの不変性の恩恵を受けることを意味する。金の譲渡の場合、これは、ブロックチェーンが一方の金アカウントから他方の金アカウントへのトランザクションのレコードをサポートするために用いられ得ることを意味する。また、ブロックチェーンおよび本明細書に記載のシステムによって提供される匿名性は、金の譲渡の機密性を維持され得ることを意味する。
【0255】
それから、ブロックチェーントランザクション806は、トランザクションならびにAliceおよびBobによって所有されるものに対応する金アカウントとのユーザの対応が正しいかどうかを確かめるためにチェックされてよい。これが、ステップS636である。
【0256】
支払い処理リソース106は、ステップS638において、イベントストリーム、すなわち、Alice、Bob、および2つの金アカウントに関するイベントストリームにデータを付け加えるための基礎としてブロックチェーントランザクション806が用いられ得ることを確認する通知をイベントストリームリソース110に発行する。
【0257】
支払い処理リソース106は、ランデブートランザクション806を用いて、ブロックチェーントランザクション806のそれぞれデータキャリアに含まれる支払い指示メタデータのハッシュを含むエントリをそれらのイベントストリームの各々に付け加えることによって、支払いをイベントストリームE-Alice、E-Bob、E-RYA(すなわち、Aliceの金アカウント、およびE-RYB(すなわち、Bobの金アカウント)と同期する。つまり、データ出力812aに対応するハッシュが、E-Aliceに追加されてよく、データ出力812bに対応するハッシュが、E-Bobに追加されてよい。これが、ステップS640である。これは、図8に概略的に示される。また、金の譲渡に関与したブローカーに対応するイベントストリームにも、エントリが付け加えられ得る。
【0258】
次に、支払い処理リソース106は、イベントストリームの各々に追加されたエントリの識別子を生成する。これが、ステップS642である。識別子は、英数字であってよく、または支払い指示メタデータのハッシュに基づいて生成される数字であってよい。たとえば、支払い指示メタデータのハッシュがSHA256暗号によって生成される場合、識別子は、支払い指示メタデータのハッシュにさらなるSHA256暗号を適用することによって生成されてよい。つまり、識別子は、支払い指示メタデータのハッシュのハッシュであってよい。
【0259】
そして、支払い処理リソース106は、識別子を、支払い指示メタデータのコピーと一緒に支払いデータストア124に記憶する。
【0260】
代替的または追加的に、支払い処理リソース106は、トランザクションを記録するためにコミットメントのチェーンの原理を利用してよい。コミットメントのチェーンの原理は、英国特許出願第2204293.1号(2022年3月25日出願)においてすべて説明されているが、以下で、資産譲渡イベントの記録へのその応用を説明する。
【0261】
トランザクションの記録へのコミットメントのチェーンの適用は、上述のダストのチェーンの手法に関連するフォーク不可能(unforkable)な利点を提供するが、さらなる利点もある。それらのさらなる利点は、チェーン上で不可視であるトランザクション間のリンクを含み、不可視である理由は、それらが、下で説明されるように、手短に言えば、前のおよび将来のトランザクションからのハッシュされたデータを含むデータペイロードに含まれるからであり、これは、前のおよび将来のトランザクションからのデータが観察者によって見分けられ得ないことを意味する。
【0262】
上で、ダストのチェーンを同期することによって資産譲渡イベントに関与する複数の関係者に対応するイベントストリームを同期するためにランデブートランザクションが用いられる、複雑さの異なる4つの例を説明した。代替として、資産譲渡イベントを記録するためにコミットメントのチェーンを利用することを提案する。簡潔にする目的で、説明された例のうち4つ目だけを、コミットメントのチェーンとの関連で説明するために選択するが、これは、4つ目の例だけに限定するものと決して受け取られるべきでない。
【0263】
まず、図8aを用いて、図8に示されたイベントストリームを参照しながら、コミットメントのチェーンの概念を簡潔に示す。コミットメントの各チェーンに対応するイベントストリームは、オフチェーン、すなわち、ブロックチェーン外にあり、データをオフチェーンで(不変的に)記憶する方法を表す。
【0264】
システム1400は、いくつかのログエントリ1406a～dを記憶するオフチェーン(すなわち、ブロックチェーン上にない)データストレージシステム1404を含む。ログエントリ1406a～dは、イベントストリームマネージャ110によって初期化されたイベントストリームのエントリに対応する場合がある。
【0265】
図8aのシステム1400は、(資産譲渡イベントなどの)イベントをブロックチェーントランザクションにマッピングする、イベントをロギングするためのイベントストリームベースのシステムの一部として用いられてよい。
【0266】
オフチェーンデータストレージ1404の各イベント1406a～dは、ブロックチェーントランザクション1408a～dにマッピングされ、ブロックチェーントランザクションのシーケンスは、コミットメントのチェーンを用いて順序付けられ、リンクされる。コミットメントのチェーンは、トランザクションのセットとみなされることが可能であり、それらのトランザクションは、それらが互いに関連付けられ得るおよび/または横断可能であり得るトランザクションのセットとみなされ得るような情報を含む。ランデブートランザクション1000に関連して下で検討される例において、コミットメントのチェーンは、記録されている資産譲渡イベントに対応する支払い指示メタデータに基づいて生成されるデータダイジェストおよび状態ダイジェストによってリンクされるトランザクションのセットである。
【0267】
下で説明されるように、トランザクションのセットは、各トランザクションが前のトランザクションへの参照および次のトランザクションへの参照を含む(またはそれらの参照に基づくデータを含む)という点で「チェーン」として構築される。ランデブートランザクション1000を参照して下の例において説明されるように、ランデブートランザクションの出力のペイロードは、前のトランザクションおよび次のトランザクションへの参照に基づく。
【0268】
各トランザクションは、トランザクションがブロックチェーン上にマイニングされるため代金を支払う「資金供給入力(funding in)」入力1410a～dを含む。各トランザクションは、それぞれのトランザクションの使用不可能な出力に保持されてよいデータペイロード1412a～dも含んでよい。データペイロード1412a～dは、OP_RETURNオペコードを先頭に付け加えられてよい。これは、ブロックチェーン上に任意のデータを書き込み、また、トランザクション出力に無効(すなわち、使用不可能)として印を付けるために用いられ得るスクリプトオペコードであり、トランザクション出力に無効(すなわち、使用不可能)とマーキングすることは、それぞれのトランザクションがブロックチェーン上に記録されるときに、ペイロードに保持されたデータをブロックチェーン上に不変的に記録させる。
【0269】
図8aに示された「データおよび参照」は、出力に含まれる状態ダイジェストおよびデータダイジェストを指す。ランデブートランザクション1000を参照して下で説明される例において、これらは、対応するイベントストリームエントリに記録される支払い指示データセットに基づく。
【0270】
手短に言えば、Aliceが金の量に関してBobに支払いを送信する上記の4つ目の例を参照する。やはり署名を必要とする王立造幣局のアカウントの存在に起因する複雑さ。例においては、資産譲渡イベント(ある王立造幣局のアカウントから別の王立造幣局のアカウントへの金の譲渡)が、それぞれがダストのチェーンに対応する4つの別々のイベントストリームに記録されることを説明する。代替的な手法は、ランデブートランザクションを用いてコミットメントの4つのチェーンをアトミックに同期して、金の譲渡をコミットメントの4つのチェーンに記録することである。
【0271】
以降、図9を参照して、コミットメントのチェーンが、AliceからBobへの金の譲渡、すなわち、上述の4つ目の例に示された資産譲渡イベントを不変的に記録するためにどのように用いられ得るかを説明する。支払い処理リソース106は、コミットメント管理モジュール160を利用するように構成される。コミットメント管理モジュール160は、任意の好適な手段を用いて、支払い処理リソース106およびイベントストリーム管理モジュール110とインタラクションするように構成される。AliceおよびBobの各々ならびにAliceおよびBobの王立造幣局のそれぞれの金アカウントは、ステップS900においてコミットメント管理モジュール160を用いて初期化されたコミットメントの対応するチェーンを有する。コミットメントのチェーンの初期化は、コミットメントのチェーンに割り当てられ得るハードウェアリソースのセットアップを含む場合がある。コミットメントのチェーンは、既に初期化されている場合があり、またはコミットメント管理モジュール160への要求に応答して初期化される場合がある。ステップS900は、資産譲渡イベントの関係者に対応するイベントストリームにアクセスするためにイベントストリーム管理モジュール110にアクセスすることを含んでよい。
【0272】
支払い処理リソース106は、コミットメントのチェーンとそれぞれのエンティティ(この例においては、AliceおよびBobならびにそれらの金アカウント)との間の関連付けを決定するように構成される。関連付けを決定する際、支払い処理リソース106は、コミットメントのチェーンが初期化されたことを示すユーザプロファイル内のエントリを特定し、コミットメント管理モジュール160がコミットメントの正しいチェーンを特定するために用いることができる識別子を提供する。コミットメントのチェーンの初期化は、AliceがBobに連絡を取って、Aliceが49.20GBPと引き換えに1gの金を獲得したいことをBobに知らせるS600のステップの前に行われた可能性がある。コミットメントのチェーンの初期化は、コミットメント管理モジュール160への好適な要求によって、ステップS600からS642のいずれかの実行中に行われた可能性がある。コミットメントのチェーンの初期化は、ステップS628の肯定的な完了の後に、すなわち、支払いプロトコル基準が満たされたときに行われる場合がある。このステップ、すなわち、ステップS628の後、ステップS630～S642の代替として、ステップ900を初期化されてよい。
【0273】
コミットメントの各チェーンは、イベントストリーム管理モジュール110によって管理される、それぞれの関係者に対応するイベントストリームに対応する。しかし、疑義を避けるために付言すると、イベントストリームが、コミットメントのチェーンの対応するペイロードに記憶されるものよりも多くの情報を各エントリで運ぶ場合があるという点で、コミットメントの連鎖は、対応するイベントストリームと正確に対応する必要が確かにある。ステップS902において、支払いプロトコルによって決定された基準が満たされている、すなわち、(図6aに示されたように)ステップS622、S624、S626、およびS628が満たされており、金の譲渡が行われることが可能であり、資産譲渡イベントとして記録されることが可能であると判定される。これは、金の譲渡が資産譲渡イベントとして記録される必要があることを示す、支払い処理リソース106によって生成されたフラグにアクセスすることによる場合がある。代替的または追加的に、ステップS622、S624、S626、およびS628は、支払い処理リソースによって生成された最初のフラグが生成されてから予め決められた量の時間が経過した場合、繰り返されてよい。
【0274】
ステップS904において、支払い処理リソース106は、Alice、Bob、およびそれぞれの王立造幣局のアカウントの各々に対応するコミットメントのチェーンに金の譲渡が記録される要求によって、コミットメント管理モジュール160に要求を与える。支払い処理リソース106によって生成されたフラグが、ステップS904の実行中にコミットメント管理モジュール160に提供されてよい。
【0275】
コミットメント管理モジュール160は、Alice、Bob、ならびにAliceとBobとの両方に対応する王立造幣局のアカウントの各々に関して(コミットメント管理モジュール160によって提供される)資金供給入力を含むランデブートランザクション1000を生成するように構成される。これが、ステップS906である。ランデブートランザクションは、図10を参照して説明される。説明するランデブートランザクションは、金の譲渡に関与する関係者のために初期化されたコミットメントのチェーンに対応するイベントストリームを同期する。これは、ダストのチェーンにリンクされたイベントストリームを同期するその他の例のランデブートランザクションとは異なる。
【0276】
図10に示されるランデブートランザクション1000は、Alice、Bob、および王立造幣局のアカウントの各々に関する出力を含む。各出力は、データダイジェストHDniおよび状態ダイジェストSniを含む。下付き添え字iは、資産譲渡イベントに関与した関係者の番号を指す。下付き添え字1は、AliceのHSBCアカウントに対応する。下付き添え字2は、BobのHSBCアカウントに対応する。下付き添え字3は、Aliceの王立造幣局アカウントに対応する。下付き添え字4は、Bobの王立造幣局アカウントに対応する。出力は、1004、1006、1008、および1010として列挙されている。
【0277】
各データダイジェストおよび状態ダイジェストは、それがOP_RETURNオペコードを先頭に付け加えられるという点でトランザクションの使用不可能な出力内に保持されるトランザクションのデータペイロード内にある。これは、ブロックチェーンに任意のデータを書き込み、また、トランザクションの出力を無効、すなわち、使用不可能とマーキングするために用いられ得るスクリプトオペコードである。したがって、対応するデータは、ブロックチェーンに不変的に記録される。
【0278】
図10に見られるように、ランデブートランザクション1000の各出力は、コミットメントのチェーンにおける対応するリンクの状態ダイジェストの使用を通じた対応する前のブロックチェーントランザクション(すなわち、それはコミットメントのそれぞれのチェーンにおける前のトランザクションである可能性がある)への参照に基づく。前のブロックチェーントランザクションは、ランデブートランザクションまたは非ランデブートランザクションである可能性がある。図10に示されるように、それらのトランザクションは、1012(AliceのHSBCアカウント、すなわち、Alice_HSBC:GBPに対応する)、1014(BobのHSBCアカウント、すなわち、Bob_HSBC:GBPに対応する)、1016(Aliceの金アカウント、すなわち、Alice_MINT:GOLDに対応する)、および1018(Bobの金アカウント、すなわち、Bob_MINT:GOLDに対応する)である。また、各ランデブートランザクションの出力は、次のトランザクションの参照の資金供給入力の参照を用いる、(ランデブートランザクションである場合もある)その対応する次のトランザクションへの参照に基づく。図10に示されるように、それらのトランザクションは、1020(AliceのHSBCアカウントに対応する)、1022(BobのHSBCアカウントに対応する)、1024(Aliceの金アカウントに対応する)、および1026(Bobの金アカウントに対応する)である。ランデブートランザクション1000の出力と次のトランザクションとの間の関係は、下の、データダイジェストおよび状態ダイジェストの生成について説明する箇所で明らかになる。トランザクションの各々およびランデブートランザクション1000への入力は、プラットフォームによって提供されてよい。トランザクション1012、1014、1016、および1018によって与えられた入力が十分な資金を提供しない場合、さらなる入力が提供される場合がある。入力は、コミットメント資金(commitment fund)N-1、N、およびN+1に対応する。
【0279】
データダイジェストおよび状態ダイジェストを生成するために、コミットメント管理モジュール160は、ステップS600からS628において生成された支払い指示データセットを取り出す。これが、ステップS908である。以降で説明するように、支払い指示データセットは、それから、データダイジェストおよび状態ダイジェストを決定するために用いられる。
【0280】
データダイジェストが、ステップS910において、(データアイテムDniとして列挙された)支払い指示データセットを用いて、数式を用いて導出される。
HDni := H2(H2(Di)||H2(SALT))
式中、||は、その前後の要素の連結であり、H2は、二重ハッシュ関数であるが、1回ハッシュ関数(H)が用いられる可能性もある。Diは、対応する関係者の支払い指示データセットである。つまり、i = 1である場合、関係者はAliceであり、以下同様である。支払い指示データセットは、すべての関係者に関して同一である場合があり、または各関係者に関して異なる異なる場合がある。
HDni := H2(H2(Di)||H2(SALT))
式中、||は、その前後の要素の連結であり、H2は、二重ハッシュ関数であるが、1回ハッシュ関数(H)が用いられる可能性もある。Diは、対応する関係者の支払い指示データセットである。つまり、i = 1である場合、関係者はAliceであり、以下同様である。支払い指示データセットは、すべての関係者に関して同一である場合があり、または各関係者に関して異なる異なる場合がある。
【0281】
ハッシュは、本明細書において、一方向関数の主な例として提供される。当業者は、その他の一方向関数が用いられてもよいことを理解するであろう。本明細書全体を通じて用いられる「ハッシュ」は、少なくとも1回ハッシュすることを意味し、それぞれのハッシュアプリケーションの数回の適用を含む可能性がある。2回以上ハッシュすることは、伸長攻撃に対する耐性を提供する。2回(以上)ハッシュする代わりに、伸長攻撃に対して脆弱でない異なるハッシュ関数または方法が用いられる。たとえば、(任意で、鍵として同じソルトまたは異なるソルトを用いる)SHA-3および/またはHMACが、そのような機能を提供する。さらなる代替は、葉アイテム{支払い指示データセット,ソルト}を持つマークル木を生成することであり、データダイジェストは、マークル木のルートである。
【0282】
ハッシュをソルト化することは、ハッシュ関数への入力の一部として(ハッシュされている支払い指示データセットと一緒に)、任意の自由に決められるデータである「ソルト」を用いることを意味する。ソルトは、ハッシュ関数へのその他の入力と連結されてよい。任意で、ソルトはランダムである。
【0283】
異なるソルトは、ハッシュされている各データアイテム、すなわち、イベントストリームの各イベントに対して選択されてよく、またはこの例においては、Alice、Bob、およびそれぞれの金アカウントの各々に対して異なるソルトが用いられてよい。
【0284】
データダイジェスト(HD)は、(主な例においては、イベントストリームに送られた)その支払い指示データセットの一意のフィンガープリントとみなされ得る。(支払い指示データセット自体と比較して)データダイジェストを記憶することによって、このシステムを用いるクライアントは、支払い指示データセットの内容を開示することなく、(クライアントデータのサイズに関係なく)知られている一貫したサイズの支払い指示データセットの存在の証明をブロックチェーン上に記憶することができる。
【0285】
次に、状態ダイジェストが、ステップS912において、図11に示されるようにマークル木のルートとして導出され、マークル木の葉は、前のトランザクションの参照、次のトランザクションの参照、およびクライアントデータに基づく。代替的または追加的に、状態ダイジェストは、JSONオブジェクトおよびソルト化されたパスに基づいて導出されてもよい。
【0286】
特に、マークル木は、前のトランザクションの参照、次のトランザクションの参照、および状態クライアントデータダイジェスト(state client data digest)(HD')に基づく。状態クライアントデータダイジェストは、データダイジェスト(HD)と、任意で、イベントおよび/またはイベントストリームに関連する任意のメタデータとに基づく。状態クライアントデータダイジェストは、下でより詳細に説明される。
【0287】
状態ダイジェスト(S)(単に便宜上、添え字niを無視する)は、以下の式に従って(例示的な前のトランザクションの参照、状態クライアントデータダイジェスト(HD')(やはり単に便宜上、添え字niを無視する)、および次のトランザクションの参照を用いて)決定され得る。
【0288】
【数1】
【0289】
式中、「Merklize」関数は、葉としてのデータ要素の順序付けられたセットからマークルルートを生成し、
【0290】
【数2】
【0291】
は、要素に基づく葉の順序付けられたセットである。Merklize関数は、Sの計算に用いられてよいその他のデータに対応する追加の入力パラメータを受け取る場合もある。たとえば、復元プロトコルが呼び出される場合に、悪意のある第三者がストリームを分岐させることを防止する秘密も含まれる場合がある。葉の各々は、最初にMerklize関数において二重ハッシュされる。注目すべきことに、ハッシュおよびマークル木がどのように機能するかが原因で、それに対する入力のセットの順序が問題となり、したがって、同じ入力データに対して同じ木(およびしたがって同じ状態ダイジェスト)が生成されるように、マークル木が作成、再作成、または検証されるときにはいつでも、入力の順序が同じでなければならない。
【0292】
任意で、状態ダイジェストは、バージョン番号に基づく。後述のようにバージョン番号がMerklize関数の呼び出しに対して指定される場合、各葉ノードは、バージョン番号に基づく。各葉ノードの原像は、バージョン番号を先頭に付け加えられる場合がある。代替的に、各葉ノードの原像は、バージョン番号を後ろに付け加えられる場合がある。有利なことに、バージョン番号の使用は、(たとえ同じ入力データが用いられても、異なるバージョン番号が異なるマークル木のルートをもたらすので)状態ダイジェストが特定のバージョンに結びつけられることを可能にする。バージョン番号の変更の使用は、マークル木がどのように構築されるかの仕様に対する任意の変更(たとえば、新しいおよび/または異なる葉ノード)と協調して用いられてよい。各バージョン番号は、生成されるマークル木の一意の仕様に結びつけられる場合がある。
【0293】
Merklize関数は、任意で、次の式に従ってバージョン番号(v)をさらなる引数として取り込む。
【0294】
【数3】
【0295】
Merklize関数は、以下のように記述され得る。
【0296】
【数4】
【0297】
1. If v == null:
1.1.
1.1.
【0298】
【数5】
【0299】
としてマークル木Tを生成する
1.2. 木TのルートRTを取得する。
1.3. RTを返す
2. Else:
2.1. バージョン番号を先頭に付け加えることによって葉のリストの各葉を更新する:
2.1.1. PREV ← v||PREV
2.1.2.
1.2. 木TのルートRTを取得する。
1.3. RTを返す
2. Else:
2.1. バージョン番号を先頭に付け加えることによって葉のリストの各葉を更新する:
2.1.1. PREV ← v||PREV
2.1.2.
【0300】
【数6】
【0301】
2.1.3. NEXT ← v||NEXT
2.2. 更新された葉のセットを用いてマークル木Tを生成する:
2.2. 更新された葉のセットを用いてマークル木Tを生成する:
【0302】
【数7】
【0303】
2.3. 木TのルートRTを取得する。
2.4. RTを返す
2.4. RTを返す
【0304】
Merklize関数は、上述の入力に加えてその他の追加の入力を受け取る場合がある。
【0305】
関数GenMerkleTreeは、葉データアイテムのセットを与えられた場合にマークル木を生成するための標準的な方法を意味すると理解されてよい。GenMerkleTreeの最初のステップは、葉のセット(この例においては
【0306】
【数8】
【0307】
)のアイテムの各々をハッシュすることであってよい。
【0308】
図11を参照すると、例示的な生成されたマークル木1100が、葉ノードPREV 1102、HD' 1104、およびNEXT 1106を用いて示されている。マークル木のルート1108は、ランデブートランザクション1000の出力の各々に用いられる状態ダイジェスト(S)である。この例示的なマークル木は、(葉を除いて)各ノードが2つの子を持つ2分木として構築される。奇数個の入力データアイテム(およびしたがって奇数個の葉)が存在するので、最後の対になっていない葉ノード(すなわち、最も遠い「NEXT」)は2倍にされる。当業者は、マークル木のこの提示された形態に厳密に従う必要はなく、同様に機能する可能性があるその他の形態が存在することを理解するであろう。上で検討されたように、入力セットの各アイテムは、2回ハッシュされ(1110)、それぞれの2回ハッシュされたアイテムが、マークル木の葉として用いられる。
【0309】
図11に示されたマークル木構造の代替として、状態ダイジェストは、原像をハッシュすることによって生成されることが可能であり、原像は、状態データが基づいている対象を連結することによって構築される。したがって、状態ダイジェストが、前のトランザクションの参照、状態クライアントデータダイジェスト、および次のトランザクションの参照に基づいている例において、式は、
【0310】
【数9】
【0311】
という形態である可能性がある。任意で、ソルトも、原像に組み込まれる場合がある。たとえば、ソルトは、原像の始めまたは終わりに連結される場合がある。
【0312】
マークル木のルートのさらなる代替として、状態ダイジェストは、ハッシュチェーンまたは規範的JSON構造体(canonical JSON structure)を用いることによって生成され得る。ハッシュチェーンは、各中間ハッシュ結果が状態ダイジェストが基づいているアイテムを先頭に付け加えられるように構築される。たとえば、状態ダイジェストが、前のトランザクションの参照、クライアントデータダイジェスト(HD')、および次のトランザクションの参照に基づいている場合、式は、
【0313】
【数10】
【0314】
という形態である可能性がある。任意で、ソルトが、ハッシュチェーンに組み込まれる。任意で、ソルトは、ソルトを各中間原像の先頭に付け加えることによって組み込まれる。
【0315】
PREVは、前のトランザクションへの参照であり、参照されている前記前のトランザクションの状態データである場合がある。図10に示されたランデブートランザクション1000において、Sn1は、Aliceに対応するコミットメントのチェーンからの前のトランザクション、トランザクション1012の構成要素であるSn1-1に基づく。Sn2は、同様にSn2-1に基づき、以下同様である。つまり、前のトランザクションへの参照は、参照されている前記前のトランザクションの状態データがブロックチェーンに記録されるので、参照されている前記前のトランザクションの状態データである。前のトランザクションの参照は、任意で、親トランザクションの参照と呼ばれ、現在のトランザクションは、その子である。
【0316】
参照される前のトランザクションがない(すなわち、それがコミットメントのチェーンの最初のトランザクションである)場合、前のトランザクションの参照は、ゼロの列であってよいヌル参照とみなされ得る。ゼロの列のサイズは、もしもそれがヌルでなかったとした場合の前のトランザクションの参照のサイズと同じサイズであってよい。列は、32バイトの長さであってよい。下の表は、PREVの例を説明する。
【0317】
【表1】
【0318】
任意でまたは代替的に、PREVの原像は、JSON構造体であり、および/またはJSON構造体を用いて表され得る。JSON構造体は、上述のデータオプションを含む。有利なことに、JSONオブジェクトの使用は、能力を提供し、その理由は、もしもより多くのデータ要素が追加されるとした場合に、それらが簡単に追加され、参照される可能性があるからである。
【0319】
NEXTは、次のトランザクションへの参照である。有利なことに、次のトランザクションの構成要素の多くは(次のトランザクションが存在するのが将来であること、およびクライアントによって送られたデータの結果として)知られておらず、したがって、前記知られていない構成要素は参照として用いられ得ないが、トランザクションに資金を供給するために用いられる1つの入力UTXOまたは複数のUTXOは、事前に決定されることが可能であり、そのトランザクションがブロックチェーンにコミットされるとき、そのトランザクション、すなわち、「NEXT」トランザクションのみに固有である。入力UTXOは、アウトポイント(outpoint)によって参照されてよい。アウトポイントは、UTXOが属するトランザクションのトランザクションID(TxIDと呼ばれる)と、前記参照されるトランザクション上の出力のインデックス(voutと呼ばれる)とを含む。次のトランザクションの参照は、任意で、子トランザクションの参照と呼ばれ、現在のトランザクションは、親である。
【0320】
前のトランザクションの参照と同様に、参照される次のトランザクションがない(すなわち、現在のトランザクションがコミットメントのチェーンの最後である)場合、次のトランザクションの参照は、ヌル参照とみなされ得る。ヌル参照は、もしもそれがヌルでなかったとした場合の次のトランザクション参照のサイズ(すなわち、トランザクションアウトポイントのサイズ)と同じサイズであってよいゼロの列である場合がある。列は、32バイトの長さであってよい。下の表は、NEXTを説明する。
【0321】
【表2】
【0322】
任意でまたは代替的に、NEXTの原像は、JSON構造体であり、および/またはJSON構造体として表され得る。JSON構造体は、上述のデータオプションを含む。有利なことに、JSONオブジェクトの使用は、能力を提供し、その理由は、もしもより多くのデータ要素が追加されるとした場合に、それらが簡単に追加され、参照される可能性があるからである。
【0323】
下の表は、状態クライアントデータダイジェスト(HD')が基づいている内容を説明する。
【0324】
【表3】
【0325】
いくつかのメタデータ要素が存在する場合、それらのメタデータ要素が、M1、M2などと列挙される。これは、図12にマークル木によって示される。
【0326】
例示的なメタデータ要素は、以下のうちのいずれか1つまたは複数を含んでもよい。
・whenRecorded -- 支払い指示メタデータがクライアントから受信された、および/もしくはオフチェーンログに記憶された時間、
・appVersion -- コミットメントのチェーンのバージョン番号、
・seed -- イベントストリームの生成の始めに用いられるシード値、
・delWriteIV -- イベントストリームに書き込むための委任された認可トークン(delegated authorisation token)の生成に用いられる初期値、
・delWriteH0 -- イベントストリームに書き込むための委任された認可トークンの有効化に用いられる最終ハッシュ値、
・timeAC -- イベントストリームが書き込みのために開いているとみなされる開始時間および/もしくは終了時間、
・delAuthIndex -- クライアントがイベントを送るために用いた委任されたトークンのインデックス、
・TxIDcreate -- コミットメントのチェーンの最初のトランザクションのトランザクションID、ならびに/または
・index -- イベントストリームにおける現在のイベントのインデックス(すべてのイベントがコミットメントのチェーンに記録される必要はないので、必ずしもコミットメントのチェーンにおけるインデックスと同じであるとは限らない)。
・nextHashSalt -- 次のイベントで用いられるソルトのハッシュ。ソルトは、コミットメントのチェーンの次のイベントのために予め生成される場合があり、このソルトは、ハッシュされ、状態クライアントデータダイジェストのマークル木の生成に用いられる
当業者は、その他のメタデータ要素が用いられてもよいことを理解するであろう。
・whenRecorded -- 支払い指示メタデータがクライアントから受信された、および/もしくはオフチェーンログに記憶された時間、
・appVersion -- コミットメントのチェーンのバージョン番号、
・seed -- イベントストリームの生成の始めに用いられるシード値、
・delWriteIV -- イベントストリームに書き込むための委任された認可トークン(delegated authorisation token)の生成に用いられる初期値、
・delWriteH0 -- イベントストリームに書き込むための委任された認可トークンの有効化に用いられる最終ハッシュ値、
・timeAC -- イベントストリームが書き込みのために開いているとみなされる開始時間および/もしくは終了時間、
・delAuthIndex -- クライアントがイベントを送るために用いた委任されたトークンのインデックス、
・TxIDcreate -- コミットメントのチェーンの最初のトランザクションのトランザクションID、ならびに/または
・index -- イベントストリームにおける現在のイベントのインデックス(すべてのイベントがコミットメントのチェーンに記録される必要はないので、必ずしもコミットメントのチェーンにおけるインデックスと同じであるとは限らない)。
・nextHashSalt -- 次のイベントで用いられるソルトのハッシュ。ソルトは、コミットメントのチェーンの次のイベントのために予め生成される場合があり、このソルトは、ハッシュされ、状態クライアントデータダイジェストのマークル木の生成に用いられる
当業者は、その他のメタデータ要素が用いられてもよいことを理解するであろう。
【0327】
図12を参照すると、ルートが(図11を参照して上で説明されたように状態データマークル木1100で用いられる)状態クライアントデータダイジェスト(HD')1104である例示的なマークル木1200が示される。
【0328】
葉ノード1206、1208、1210、1212、1214のセットは、データダイジェスト(HD)およびメタデータの葉ノードがソルトとインターリーブされるように配列される。このインターリーブは、第三者がマークル木を総当たりすることを法外に高コストにすることによってマークル木内のデータのセキュリティを高める。もしも第三者がコミットメントのチェーンに関するプロトコルの記述を取得するとした場合、HD(データダイジェスト)がトランザクション上に公開で記憶される場合があるとすると、第三者は、M1、...、Mmの値が多くの場合予測可能であるかまたは容易に数え上げられ得る場合がある(たとえば、メタデータ要素のうちの1つがタイムスタンプである場合、これはトランザクションがブロックチェーンに送られた時間が与えられれば推測可能である場合があり、またはメタデータ要素のうちの1つが単調増加するインデックスである可能性があり、これは前の状態から推測可能である場合がある)ことを考えれば、これらのメタデータの値を総当たりする可能性がある。第三者がこれらの値を総当たりし、値HD'(すなわち、木のルート)を正しく再構築することができる場合、第三者は、メタデータの値M1、...、Mmに関する自分の知識を成功裏に確認したであろう。場合によっては、これらのメタデータは機密である場合があり、たとえば、whenRecordedまたはwriteAccessControl.regionプロパティが、EventStreamトランザクションにおいてメタデータとして用いられ、悪意のある第三者にとって重要である場合がある。
【0329】
葉ノードの基礎を形成する原像は、プロトコルバージョン番号を先頭に付け加えられる場合がある。
【0330】
したがって、例示的なマークル木1200を作成するプロセスは、以下のように記述され得る。
DataDigestCommit(HD, SALT, M1, ..., Mm, v):
1. SALTのm個のコピーを生成する
2. {HD, SALT, M1, SALT, ..., Mm, SALT}のようにデータアイテムを順序付ける
3.
DataDigestCommit(HD, SALT, M1, ..., Mm, v):
1. SALTのm個のコピーを生成する
2. {HD, SALT, M1, SALT, ..., Mm, SALT}のようにデータアイテムを順序付ける
3.
【0331】
【数11】
【0332】
を生成する
4.
4.
【0333】
【数12】
【0334】
を返す
【0335】
注目すべきことに、上で検討された状態ダイジェストの作成と同様に、ここで、同じMerklize関数が用いられる。同じMerklize関数が用いられるので、葉ノードの原像は、同様に、任意で2回ハッシュされる。Merklize関数は、H'Dの計算に用いられてよいその他のパラメータに対応するその他の追加の入力を受け取る場合がある。
【0336】
上記のマークル木の生成の検討と同様に、入力を連結し、結果をハッシュすること、およびハッシュチェーンを生成することを含む、マークル木のいくつかの代替があり得る。
【0337】
状態クライアントデータダイジェストHD'の生成のために、(v = nullを与える場合がある上で検討された状態ダイジェスト(S)と比較して)プロトコルバージョン番号が用いられてよい。状態ダイジェスト(S)は状態クライアントデータダイジェスト(HD')に依存するので、HD'をプロトコルバージョン番号(v)に依存させることによって、Sも、(たとえその生成に直接用いられないとしても)結局vに依存することになる。ここで、「依存する」は、HD'の生成に用いられた異なるプロトコルバージョン番号以外は同じ入力が用いられたとした場合に、Sが異なることを意味する。これは、それによって、プロトコルバージョン番号が2つのマークル木の生成に2回用いられることがなければ、Sがプロトコルバージョン番号に依存することを可能にする。
【0338】
ステップS914において、ランデブートランザクション1000が、ブロックチェーンに含めるために送られる。そして、支払い指示データセットのハッシュがそれぞれのイベントストリームに追加される要求によってイベントストリーム管理モジュール110にアクセスすることにより、ステップS916において、Alice、Bob、ならびにAliceおよびBobに対応する金アカウントに対応するイベントストリームは、支払い指示データセットのハッシュを付け加えられ得る。状態ダイジェストおよびデータダイジェストが、イベントストリームのエントリに含まれてもよく、追加的または代替的に、状態ダイジェストのハッシュおよび/またはデータダイジェストのハッシュが、イベントストリームのエントリに含まれてもよい。そのとき、ランデブートランザクション1000は、それが対応するイベントストリームのエントリにリンクされるという点で、Alice、Bob、および金アカウントに対応するコミットメントのチェーンの各々の一部を形成する。そして、ランデブートランザクションは、イベントストリームのエントリに不変的および安全な方法でリンクされ、資産譲渡イベントは、詳細を開示することなく不変的および安全に記録される。
【0339】
つまり、資産譲渡の基準が満たされるという支払い処理リソースによる判定に続いて、コミットメント管理モジュール160は、Alice、Bob(すなわち、それらのHSBCのGBPアカウント)、ならびにAliceおよびBobに対応する2つの金アカウントに対応するコミットメントのチェーンを同期するランデブートランザクション1000を生成する。ランデブートランザクション1000の出力が生成され、支払い指示データセット、状態クライアントデータダイジェスト、および状態データダイジェストに基づく要素を含む。その後、ランデブートランザクション1000は、ブロックチェーンに送られ、関係者に対応するコミットメントのチェーンにリンクされ得る。
【0340】
代替的または追加的に、図13に示されるように、コミットメント管理モジュール160によって生成されてよいランデブートランザクション1300の代替的な形態が存在する。ランデブートランザクション1000と同様にコミットメントのチェーンごとに異なる入力および出力の代わりに、単一のトランザクション入力1302および出力1304が用いられ得る。この場合も、入力は、コミットメント管理モジュール160によって提供されてよい。
【0341】
出力は、対応するPREVトランザクションとNEXTトランザクションとの組合せに基づいて組み立てられ得るデータダイジェストおよび状態ダイジェストを含む。組合せは、連結、加算、または関連する量を組み合わせる任意のその他の方法によって実現されてよい。データダイジェストおよび状態ダイジェストが生成されるとき、トランザクション1300は、ブロックチェーンに含めるために送られてよく、ランデブートランザクション1300は、(ランデブートランザクション1000と)同様に、Alice、Bob、ならびにAliceおよびBobに対応する金アカウントに対応するイベントストリームの対応するエントリにリンクされ得る。
【0342】
上述の態様および実施形態は、本開示を限定するのではなく、例示し、当業者は、添付の請求項によって定義される本開示の範囲を逸脱することなく多くの代替的な実施形態を設計することができることに留意されたい。請求項において、括弧に入れられた参照符号は、特許請求の範囲を限定するものと解釈されないものとする。単語「～を含む(comprising)」および「～を含む(comprises)」などは、任意の請求項または本明細書全体において列挙された要素またはステップ以外の要素またはステップの存在を除外しない。本明細書において、「～を含む(comprise)」は、「～を含む(includes)かまたは～からなる」を意味し、「～を含む(comprising)」は、「～を含む(including)かまたは～からなる(consisting of)」を意味する。ある要素の単数形の言及は、そのような要素の複数形の言及を除外せず、その逆も同様である。本開示は、いくつかの異なる要素を含むハードウェアによって、および適切にプログラミングされたコンピュータによって実施されてよい。いくつかの手段を列挙するデバイスの請求項においては、これらの手段のうちのいくつかが、1つの同じハードウェアによって具現化される場合がある。単に特定の手段が互いに異なる従属請求項に記載されているという事実は、これらの手段の組合せが有利に用いられ得ないことを示さない。
【符号の説明】
【0343】
100 システム
102 第1のコンピューティングデバイス
102a コンピュータ機器
102b コンピュータ機器
103 ユーザ、エンティティ、関係者、エージェント
103a ユーザ、エンティティ、第1の関係者
103b ユーザ、エンティティ、第2の関係者
104 第2のコンピューティングデバイス
105 クライアントアプリケーション
106 支払い処理リソース、ネットワーク、ビットコインネットワーク、ブロックチェーンネットワーク
108 アプリケーションプログラミングインターフェース(API)
110 イベントストリームリソース、イベントストリームマネージャ
110a イベントストリーム
112 ブロックチェーン
120 支払いプロトコルモジュール、支払い処理モジュール
122 鍵ストレージモジュール
124 支払いデータストア
126 ノード、ビットコインノード、ブロックチェーンノード
130 パケット交換ネットワーク
132 ブロックチェーンネットワーク、ビットコインネットワーク、ピアツーピア(P2P)ネットワーク、ネットワーク
140 データベース管理システム(DBMS)
150 ブロックチェーン、ビットコインブロックチェーン
151、151n、151n-1 ブロック
152、152i、152j トランザクション
153 ジェネシスブロック(Gb)
154 未公開トランザクションの順序付けられたセット
155 ブロックポインタ
160 コミットメント管理モジュール
401 プロトコルエンジン
402 ブロックチェーントランザクション
404 ブロックチェーントランザクション
406 ランデブーブロックチェーントランザクション
412、412a、412b データキャリア
450 ノードソフトウェア
451 プロトコルエンジン
452 スクリプトエンジン
453 スタック
454 アプリケーションレベル決定エンジン
455 ブロックチェーン関連機能モジュール
455C コンセンサスモジュール
455P 伝播モジュール
455S ストレージモジュール
502 イベント
504 ブロックチェーントランザクション
506 エッジ
602 ブロックチェーントランザクション
604 ブロックチェーントランザクション
606 ランデブーブロックチェーントランザクション
608 ブロックチェーントランザクション
610 ブロックチェーントランザクション
612 データキャリア
702 ブロックチェーントランザクション
704 ブロックチェーントランザクション
706 ランデブーブロックチェーントランザクション
708 ブロックチェーントランザクション
710 ブロックチェーントランザクション
712a、712b、712c、712d データキャリア
802 ブロックチェーントランザクション
804 ブロックチェーントランザクション
806 ランデブーブロックチェーントランザクション
808 ブロックチェーントランザクション
810 ブロックチェーントランザクション
1000 ランデブートランザクション
1004、1006、1008、1010 出力
1012、1014、1016、1018、1020、1022、1024、1026 トランザクション
1100 マークル木
1102 葉ノードPREV
1104 状態クライアントデータダイジェスト、葉ノードHD'
1106 葉ノードNEXT
1108 マークル木のルート
1200 マークル木
1206、1208、1210、1212、1214 葉ノード
1300 ランデブートランザクション
1302 トランザクション入力
1304 トランザクション出力
1400 システム
1404 オフチェーンの(すなわち、ブロックチェーン上にない)データストレージシステム
1406a～d ログエントリ、イベント
1408a～d ブロックチェーントランザクション
1410a～d 「資金供給入力」入力
1412a～d データペイロード
102 第1のコンピューティングデバイス
102a コンピュータ機器
102b コンピュータ機器
103 ユーザ、エンティティ、関係者、エージェント
103a ユーザ、エンティティ、第1の関係者
103b ユーザ、エンティティ、第2の関係者
104 第2のコンピューティングデバイス
105 クライアントアプリケーション
106 支払い処理リソース、ネットワーク、ビットコインネットワーク、ブロックチェーンネットワーク
108 アプリケーションプログラミングインターフェース(API)
110 イベントストリームリソース、イベントストリームマネージャ
110a イベントストリーム
112 ブロックチェーン
120 支払いプロトコルモジュール、支払い処理モジュール
122 鍵ストレージモジュール
124 支払いデータストア
126 ノード、ビットコインノード、ブロックチェーンノード
130 パケット交換ネットワーク
132 ブロックチェーンネットワーク、ビットコインネットワーク、ピアツーピア(P2P)ネットワーク、ネットワーク
140 データベース管理システム(DBMS)
150 ブロックチェーン、ビットコインブロックチェーン
151、151n、151n-1 ブロック
152、152i、152j トランザクション
153 ジェネシスブロック(Gb)
154 未公開トランザクションの順序付けられたセット
155 ブロックポインタ
160 コミットメント管理モジュール
401 プロトコルエンジン
402 ブロックチェーントランザクション
404 ブロックチェーントランザクション
406 ランデブーブロックチェーントランザクション
412、412a、412b データキャリア
450 ノードソフトウェア
451 プロトコルエンジン
452 スクリプトエンジン
453 スタック
454 アプリケーションレベル決定エンジン
455 ブロックチェーン関連機能モジュール
455C コンセンサスモジュール
455P 伝播モジュール
455S ストレージモジュール
502 イベント
504 ブロックチェーントランザクション
506 エッジ
602 ブロックチェーントランザクション
604 ブロックチェーントランザクション
606 ランデブーブロックチェーントランザクション
608 ブロックチェーントランザクション
610 ブロックチェーントランザクション
612 データキャリア
702 ブロックチェーントランザクション
704 ブロックチェーントランザクション
706 ランデブーブロックチェーントランザクション
708 ブロックチェーントランザクション
710 ブロックチェーントランザクション
712a、712b、712c、712d データキャリア
802 ブロックチェーントランザクション
804 ブロックチェーントランザクション
806 ランデブーブロックチェーントランザクション
808 ブロックチェーントランザクション
810 ブロックチェーントランザクション
1000 ランデブートランザクション
1004、1006、1008、1010 出力
1012、1014、1016、1018、1020、1022、1024、1026 トランザクション
1100 マークル木
1102 葉ノードPREV
1104 状態クライアントデータダイジェスト、葉ノードHD'
1106 葉ノードNEXT
1108 マークル木のルート
1200 マークル木
1206、1208、1210、1212、1214 葉ノード
1300 ランデブートランザクション
1302 トランザクション入力
1304 トランザクション出力
1400 システム
1404 オフチェーンの(すなわち、ブロックチェーン上にない)データストレージシステム
1406a～d ログエントリ、イベント
1408a～d ブロックチェーントランザクション
1410a～d 「資金供給入力」入力
1412a～d データペイロード
【図1a】
【図1b】
【図1c】
【図2】
【図3a】
【図3b】
【図3c】
【図3d】
【図3e】
【図4a】
【図4b】
【図4c】
【図5a】
【図5b】
【図5c】
【図6a】
【図6b】
【図7】
【図8】
【図8a】
【図9】
【図10】
【図11】
【図12】
【図13】
【国際調査報告】