IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ エヌチェーン ホールディングス リミテッドの特許一覧

特許7589173ブロックチェーン・トランザクションのデータ・フィールドの検証
<>
  • 特許-ブロックチェーン・トランザクションのデータ・フィールドの検証 図1
  • 特許-ブロックチェーン・トランザクションのデータ・フィールドの検証 図2
  • 特許-ブロックチェーン・トランザクションのデータ・フィールドの検証 図3
  • 特許-ブロックチェーン・トランザクションのデータ・フィールドの検証 図4
  • 特許-ブロックチェーン・トランザクションのデータ・フィールドの検証 図5
  • 特許-ブロックチェーン・トランザクションのデータ・フィールドの検証 図6
  • 特許-ブロックチェーン・トランザクションのデータ・フィールドの検証 図7
  • 特許-ブロックチェーン・トランザクションのデータ・フィールドの検証 図8
  • 特許-ブロックチェーン・トランザクションのデータ・フィールドの検証 図9
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2024-11-15
(45)【発行日】2024-11-25
(54)【発明の名称】ブロックチェーン・トランザクションのデータ・フィールドの検証
(51)【国際特許分類】
   H04L 9/32 20060101AFI20241118BHJP
【FI】
H04L9/32 200Z
【請求項の数】 44
(21)【出願番号】P 2021568333
(86)(22)【出願日】2020-04-22
(65)【公表番号】
(43)【公表日】2022-07-22
(86)【国際出願番号】 IB2020053813
(87)【国際公開番号】W WO2020240296
(87)【国際公開日】2020-12-03
【審査請求日】2023-03-24
(31)【優先権主張番号】1907349.3
(32)【優先日】2019-05-24
(33)【優先権主張国・地域又は機関】GB
(73)【特許権者】
【識別番号】318001991
【氏名又は名称】エヌチェーン ライセンシング アーゲー
(74)【代理人】
【識別番号】100107766
【弁理士】
【氏名又は名称】伊東 忠重
(74)【代理人】
【識別番号】100070150
【弁理士】
【氏名又は名称】伊東 忠彦
(74)【代理人】
【識別番号】100135079
【弁理士】
【氏名又は名称】宮崎 修
(72)【発明者】
【氏名】デイヴィーズ,ジャック
(72)【発明者】
【氏名】マッケイ,アレグザンダー
(72)【発明者】
【氏名】ライト,クレイグ
【審査官】青木 重徳
(56)【参考文献】
【文献】米国特許出願公開第2019/0103973(US,A1)
【文献】国際公開第2019/034299(WO,A1)
【文献】韓国登録特許第10-1701131(KR,B1)
【文献】淵田 康之,特集:イノベーションと金融 ブロックチェーンと金融取引の革新,野村資本市場クォータリー,日本,株式会社野村資本市場研究所,2015年11月01日,第19巻第2号(通巻74号),p.11-35
(58)【調査した分野】(Int.Cl.,DB名)
H04L 9/32
(57)【特許請求の範囲】
【請求項1】
ターゲット・トランザクションの二次トランザクション識別子を生成する、コンピュータ実装される方法であって、前記ターゲット・トランザクションはトランザクション全体をハッシュすることによって生成された一次トランザクション識別子を含み、前記二次トランザクション識別子は、照会ユーザーが、ターゲット・トランザクションが候補データ・フィールドを含むかどうかを判定できるようにし、当該方法は、生成ユーザーの計算装置によって実行され:
前記ターゲット・トランザクションのデータ・フィールドの集合を識別するステップであって、各データ・フィールドは、前記ターゲット・トランザクションのそれぞれのデータを含む、ステップと;
トランザクション・ハッシュ木を生成するステップとを含み、前記トランザクション・ハッシュ木は:
i)複数のリーフ・ハッシュを含むリーフ層であって、各データ・フィールドはハッシュされて、前記複数のリーフ・ハッシュのそれぞれ1つを生成する、リーフ層、
ii)複数の内部ハッシュをそれぞれ含む一つまたは複数の内部層であって、各内部層における各内部ハッシュは、下位層からの少なくとも2つのハッシュの連結をハッシュすることによって生成され、前記一つまたは複数の内部層のうち最下位の内部層の各内部ハッシュは、少なくとも2つの異なるリーフ・ハッシュの連結をハッシュすることによって生成される、内部層、および
iii)前記二次トランザクション識別子を含むルート層を含み、前記二次トランザクション識別子は、前記一つまたは複数の内部層のうち最上位の内部層の内部ハッシュの連結をハッシュすることによって生成される、
方法。
【請求項2】
ロックチェーンのブロック内に含めるために前記二次トランザクション識別子をトランザクションにコミットすること;
前記ブロックチェーンのブロック内に含めるために前記二次トランザクション識別子を生成トランザクションにコミットすること;
ブロックチェーン・ネットワークのノードに前記二次トランザクション識別子を送信すること;
前記生成ユーザーの計算装置のメモリに前記二次トランザクション識別子を記憶すること
前記二次トランザクション識別子を前記ブロックチェーンにコミットすること
のうちの1つ、いくつか、またはすべてを含む、請求項1に記載の方法。
【請求項3】
照会ユーザーが、ブロックチェーンのブロック内のターゲット・トランザクションが候補データ・フィールドを含むかどうかを判定できるようにする方法であって、前記ターゲット・トランザクションはトランザクション全体をハッシュすることによって生成された一次トランザクション識別子を含み、当該方法は、コミット・ユーザーの計算装置によって実行され:
前記ターゲット・トランザクションの二次トランザクション識別子を取得するステップと;
前記二次トランザクション識別子を、前記ブロックチェーンのブロック内に含めるためにトランザクションにコミットするステップとを含み、
前記二次トランザクション識別子は:
前記ターゲット・トランザクションのデータ・フィールドの集合を識別するステップであって、各データ・フィールドは、前記トランザクションのそれぞれのデータを含む、ステップと;
トランザクション・ハッシュ木を生成するステップとによって生成されたものであり、前記トランザクション・ハッシュ木は:
i)データ・フィールドの順序付けられた集合に基づいて順序付けられた複数のリーフ・ハッシュを含むリーフ層であって、各データ・フィールドはハッシュされて、前記複数のリーフ・ハッシュのそれぞれ1つを生成する、リーフ層、
ii)複数の内部ハッシュをそれぞれ含む一つまたは複数の内部層であって、各内部層における各内部ハッシュは、下位層からの少なくとも2つのハッシュの連結をハッシュすることによって生成され、前記一つまたは複数の内部層のうち最下位の内部層の各内部ハッシュは、少なくとも2つの異なるリーフ・ハッシュの連結をハッシュすることによって生成される、内部層、および
iii)前記二次トランザクション識別子を含むルート層を含み、前記二次トランザクション識別子は、前記一つまたは複数の内部層のうち最上位の内部層の内部ハッシュの連結をハッシュすることによって生成される、
方法。
【請求項4】
前記取得することが:
前記二次トランザクション識別子を生成すること;
前記二次トランザクション識別子をブロックチェーン・ネットワークのノードから受信すること;
前記二次トランザクション識別子をブロックチェーン・ネットワークの外部のノードから受信すること、
のうちの少なくとも1つを含む、請求項に記載の方法。
【請求項5】
前記コミットすることが、前記二次トランザクション識別子をブロックチェーンのブロック内の生成トランザクションにコミットすることを含む、請求項またはに記載の方法。
【請求項6】
前記トランザクション・ハッシュ木は二分ハッシュ木であり、前記最下位の内部層の各内部ハッシュは2つの異なるリーフ・ハッシュの連結をハッシュすることによって生成され、各内部層の各内部ハッシュは下位層からの2つのハッシュの連結をハッシュすることによって生成され、最上位の内部層は2つの内部ハッシュを含む、請求項1ないしのうちいずれか一項に記載の方法。
【請求項7】
当該方法は、前記候補データ・フィールドについての認証経路を照会ユーザーの計算装置に送信することを含み、前記認証経路は、ハッシュの順序付けられた集合を含み、ハッシュの順序付けられた集合は、少なくとも1つのリーフ・ハッシュと内部ハッシュの一つまたは複数の集合とを含み、内部ハッシュの各集合は、トランザクション・ハッシュ木の内部層のそれぞれの1つに属する、請求項1ないしのうちいずれか一項に記載の方法。
【請求項8】
当該方法は、前記候補データ・フィールドまたはそのハッシュを照会当事者に送信するが、前記ターゲット・トランザクションの少なくとも1つの他のデータ・フィールドは送信しないことを含む、請求項1ないしのうちいずれか一項に記載の方法。
【請求項9】
データ・フィールドの前記集合は:
i)前記ターゲット・トランザクションの入力データを含む少なくとも1つのデータ・フィールドと;
ii)前記ターゲット・トランザクションの出力データを含む少なくとも1つのデータ・フィールドと;
iii)前記ターゲット・トランザクションの非入力かつ非出力データを含む少なくとも1つのデータ・フィールドとを含む、
請求項1ないしのうちいずれか一項に記載の方法。
【請求項10】
データ・フィールドの前記集合は:
i)前記ターゲット・トランザクションのスクリプト入力データを含む少なくとも1つのデータ・フィールドと;
ii)前記ターゲット・トランザクションの非スクリプト入力データを含む少なくとも1つのデータ・フィールドと;
iii)前記ターゲット・トランザクションのスクリプト出力データを含む少なくとも1つのデータ・フィールドと;
iv)前記ターゲット・トランザクションの非スクリプト出力データを含む少なくとも1つのデータ・フィールドとを含む、
請求項1ないしのうちいずれか一項に記載の方法。
【請求項11】
前記ターゲット・トランザクションは、複数の入力に対応するデータを含み、データ・フィールドの前記集合は、前記入力のそれぞれについて、その入力のスクリプト・データを含む少なくとも1つのデータ・フィールドと、その入力の非スクリプト・データを含む少なくとも1つのデータ・フィールドとを含む、および/または、
前記ターゲット・トランザクションは、複数の出力に対応するデータを含み、データ・フィールドの前記集合は、前記出力のそれぞれについて、その出力のスクリプト・データを含む少なくとも1つのデータ・フィールドと、その出力の非スクリプト・データを含む少なくとも1つのデータ・フィールドと、を含む、
の一つまたは複数である、請求項1ないしのうちいずれか一項に記載の方法。
【請求項12】
データ・フィールドの前記集合は:
i)一つまたは複数の署名を含む少なくとも1つのデータ・フィールドと、
ii)署名以外の前記ターゲット・トランザクションのスクリプト入力データを含む少なくとも1つのデータ・フィールドと、
iii)一つまたは複数の公開鍵ハッシュを含む少なくとも1つのデータ・フィールドと、
iv)公開鍵ハッシュ以外の前記ターゲット・トランザクションのスクリプト出力データを含む少なくとも1つのデータ・フィールドと、
を含む、請求項1ないし11のうちいずれか一項に記載の方法。
【請求項13】
データ・フィールドの前記集合のうちの少なくとも1つは、前記ターゲット・トランザクションの一次トランザクション識別子を含む、および/または、前記データ・フィールドのうちの少なくとも1つは、前記ターゲット・トランザクションの一次トランザクション識別子をアペンドされる、請求項1ないし12のうちいずれか一項に記載の方法。
【請求項14】
前記一次トランザクション識別子は、前記ターゲット・トランザクションをハッシュすることによって生成される、請求項13に記載の方法。
【請求項15】
前記識別は固定数のデータ・フィールドの集合を識別することを含む、請求項1ないし14のうちいずれか一項に記載の方法。
【請求項16】
前記識別は、それぞれが固定量のデータを含むデータ・フィールドの集合を識別することを含む、請求項1ないし14のうちいずれか一項に記載の方法。
【請求項17】
前記ターゲット・トランザクションは、コンテンツデータを含んでいてもよく、前記候補データ・フィールドは、そのコンテンツデータの少なくとも一部を含む、請求項1ないし16のうちいずれか一項に記載の方法。
【請求項18】
前記コンテンツデータが:
・画像データ、
・音声データ、
・ビデオデータ、および
・テキストデータ
のうちの1つ、いくつか、またはすべてを含む、請求項17に記載の方法。
【請求項19】
ブロックチェーンのブロック内のターゲット・トランザクションの候補二次トランザクション識別子が指定されたプロトコルに従って生成されたものであるかどうかを検証する、コンピュータ実装される方法であって、前記ターゲット・トランザクションはトランザクション全体をハッシュすることによって生成された一次トランザクション識別子を含み、当該方法は、検証ユーザーの計算装置によって実行され:
前記候補二次トランザクション識別子を取得するステップと;
前記ターゲット・トランザクションのデータ・フィールドの集合を識別するステップであって、各データ・フィールドは、前記トランザクションのそれぞれのデータを含む、ステップと;
トランザクション・ハッシュ木を生成するステップであって、前記トランザクション・ハッシュ木は:
i)複数のリーフ・ハッシュを含むリーフ層であって、各データ・フィールドはハッシュされて、それぞれのリーフ・ハッシュを生成する、リーフ層、
ii)複数の内部ハッシュをそれぞれ含む一つまたは複数の内部層であって、各内部層における各内部ハッシュは、下位層からの少なくとも2つのハッシュの連結をハッシュすることによって生成され、最下位の内部層の各内部ハッシュは、少なくとも2つの異なるリーフ・ハッシュの連結をハッシュすることによって生成される、内部層、および
iii)前記二次トランザクション識別子を含むルート層を含み、前記二次トランザクション識別子は、最上位の内部層の内部ハッシュの連結をハッシュすることによって生成される、ステップと;
前記二次トランザクション識別子が前記候補二次トランザクション識別子と一致するかどうかを検証するステップとを含む
方法。
【請求項20】
前記取得することは:
前記候補二次トランザクション識別子をブロックチェーン・ネットワークのノードから受信すること;
前記候補二次トランザクション識別子を前記ブロックチェーン・ネットワークの外部のノードから受信すること;および
前記候補二次トランザクション識別子を前記ブロックチェーンのブロック内のトランザクションから抽出すること、
のうちの一つまたは複数を含む、請求項19に記載の方法。
【請求項21】
ブロックチェーンのブロック内のターゲット・トランザクションが候補データ・フィールドを含むかどうかを判定する、コンピュータ実装される方法であって、前記ターゲット・トランザクションはトランザクション全体をハッシュすることによって生成された一次トランザクション識別子を含み、当該方法は、照会ユーザーの計算装置によって実行され:
候補リーフ・ハッシュを取得するステップであって、前記候補リーフ・ハッシュは前記候補データ・フィールドのハッシュである、ステップと;
前記ターゲット・トランザクションの候補二次トランザクション識別子を取得するステップであって、前記二次トランザクション識別子は、前記ターゲット・トランザクションのデータ・フィールドの集合を識別するステップであって、各データ・フィールドが前記トランザクションのそれぞれのデータを含む、ステップ、および、トランザクション・ハッシュ木を生成するステップであって、前記トランザクション・ハッシュ木のルート層が、前記二次トランザクション識別子を含む、ステップによって生成されたものである、ステップと;
前記候補データ・フィールドについての認証経路を取得するステップであって、前記認証経路は、順序付けられたハッシュの集合を含み、前記順序付けられたハッシュの集合は、少なくとも1つのリーフ・ハッシュおよび内部ハッシュの一つまたは複数の集合を含み、内部ハッシュの各集合は前記トランザクション・ハッシュ木のそれぞれの内部層に属する、ステップと;
取得された候補リーフ・ハッシュ、取得された候補二次トランザクション識別子、前記候補データ・フィールドについての取得された認証経路を使用してハッシュ木証明を実行するステップであって、該実行することは二次トランザクション識別子を生成する、ステップとを含み、
前記判定は、前記二次トランザクション識別子が前記候補二次トランザクション識別子と一致するかどうかに基づく、
方法。
【請求項22】
前記ハッシュ木証明の前記実行は:
前記候補リーフ・ハッシュの、前記順序付けられたハッシュの集合内の前記少なくとも1つのリーフ・ハッシュとの連結をハッシュし;
次いで、前のハッシュの結果の、前記認証経路における内部ハッシュの前記一つまたは複数の集合のうちの次のものとの連結をハッシュするプロセスを、内部ハッシュの前記一つまたは複数の集合のうちの最後のものが、前のハッシュと連結された後にハッシュされるまで繰り返すことを含み、前記二次トランザクション識別子は、前記最後のハッシュの結果である、
請求項21に記載の方法。
【請求項23】
前記候補リーフ・ハッシュの前記取得は:
前記候補リーフ・ハッシュを受信すること;または
前記候補データ・フィールドを受信して、前記候補データ・フィールドをハッシュして前記候補リーフ・ハッシュを生成することを含む、
請求項21または22に記載の方法。
【請求項24】
前記候補二次トランザクション識別子の前記取得は:
前記二次トランザクション識別子をブロックチェーン・ネットワークのノードから受信すること;
前記二次トランザクション識別子をブロックチェーン・ネットワークの外部のノードから受信すること;および
前記二次トランザクション識別子をブロックチェーンのブロック内のトランザクションから抽出すること、
のうちの少なくとも1つを含む、請求項21ないし23のうちいずれか一項に記載の方法。
【請求項25】
一つまたは複数のメモリユニットを備えるメモリと;
一つまたは複数の処理ユニットを備える処理装置とを備えるコンピュータ設備であって、前記メモリは、前記処理装置上で動作するように構成されたコードを記憶し、該コードは、前記処理装置上で実行されたときに、請求項ないし24のうちいずれか一項に記載の方法を実行するように構成される、
コンピュータ設備。
【請求項26】
照会ユーザーのコンピュータ設備上で実行されたときに請求項ないし24のうちいずれか一項に記載の方法を実行するように構成された、コンピュータ読み取り可能記憶装置上に具現されたコンピュータ・プログラム。
【請求項27】
ブロックチェーンのブロックの二次ブロック識別子を生成する、コンピュータ実装される方法であって、前記ブロックは、トランザクションの集合を含み、それらのターゲット・トランザクションはそれぞれトランザクション全体をハッシュすることによって生成された一次トランザクション識別子を含み、前記二次ブロック識別子は、照会ユーザーが、前記トランザクションの集合が候補データ・フィールドを含むかどうかを判定することを可能にし、当該方法は、生成ユーザーの計算装置によって実行され:
前記トランザクションの集合の各トランザクションについて、それぞれの二次トランザクション識別子を取得するステップと;
トランザクション集合ハッシュ木を生成するステップとを含み、該トランザクション集合ハッシュ木は:
i)複数のリーフ・ハッシュを含むリーフ層であって、各リーフ・ハッシュは、前記二次トランザクション識別子のそれぞれに対応する、リーフ層、
ii)複数の内部ハッシュをそれぞれ含む一つまたは複数の内部層であって、各内部層における各内部ハッシュは、下位層からの少なくとも2つのハッシュの連結をハッシュすることによって生成され、該一つまたは複数の内部層のうち最下位の内部層の各内部ハッシュは、少なくとも2つの異なるリーフ・ハッシュの連結をハッシュすることによって生成される、内部層、および
iii)前記二次ブロック識別子を含むルート層を含み、前記二次ブロック識別子は、前記一つまたは複数の内部層のうち最上位の内部層の内部ハッシュの連結をハッシュすることによって生成される、
方法。
【請求項28】
前記二次ブロック識別子を、前記ブロックチェーンのブロック内に含めるために、トランザクションにコミットすること;
前記二次ブロック識別子を、前記ブロックチェーンのブロック内に含めるために、生成トランザクションにコミットすること;
前記二次ブロック識別子を前記ブロックチェーン・ネットワークのノードに送信すること;および、
前記二次トランザクション識別子を生成ユーザーの計算装置のメモリに記憶すること
のうちの一つ、いくつか、またはすべてを含む、請求項27に記載の方法。
【請求項29】
それぞれの二次トランザクション識別子を取得することは:
それぞれの二次トランザクション識別子の一つ、いくつかまたは全部を生成すること;
それぞれの二次トランザクション識別子の一つ、いくつかまたは全部を前記ブロックチェーン・ネットワークから受信すること;
それぞれの二次トランザクション識別子の一つ、いくつかまたは全部を前記ブロックチェーン・ネットワークの外部のノードから受信すること;
それぞれの二次トランザクション識別子の一つ、いくつかまたは全部を前記ブロックチェーンのブロック内の少なくとも一つのトランザクションから抽出すること、
のうちの一つまたは複数を含む、請求項27または28に記載の方法。
【請求項30】
一つまたは複数のメモリユニットを備えるメモリと;
一つまたは複数の処理ユニットを備える処理装置とを備える、生成ユーザーのコンピュータ設備であって、前記メモリは、前記処理装置上で動作するように構成されたコードを記憶し、該コードは、前記処理装置上で実行されたときに、請求項27ないし29のうちいずれか一項に記載の方法を実行するように構成される、コンピュータ設備。
【請求項31】
生成ユーザーのコンピュータ設備上で実行されたときに請求項27ないし29のうちいずれか一項に記載の方法を実行するように構成された、コンピュータ読み取り可能記憶装置上に具現されたコンピュータ・プログラム。
【請求項32】
照会ユーザーが、ブロックチェーンのブロック内のトランザクションの集合が候補データ・フィールドを含むかどうかを判定することを可能にする方法であって、当該方法は、コミット・ユーザーの計算装置によって実行され:
前記トランザクションの集合を含む前記ブロックの二次ブロック識別子を取得するステップと;
前記二次ブロック識別子を前記ブロックチェーンのブロック内に含めるためにトランザクションにコミットするステップとを含み、
前記二次ブロック識別子は:
前記トランザクションの集合における各トランザクションについて、それぞれの二次トランザクション識別子を取得するステップと;
トランザクション集合ハッシュ木を生成するステップとによって生成されたものであり、該トランザクション集合ハッシュ木は:
i)複数のリーフ・ハッシュを含むリーフ層であって、各リーフ・ハッシュは、前記二次トランザクション識別子のそれぞれに対応する、リーフ層、
ii)複数の内部ハッシュをそれぞれ含む一つまたは複数の内部層であって、各内部層における各内部ハッシュは、下位層からの少なくとも2つのハッシュの連結をハッシュすることによって生成され、該一つまたは複数の内部層のうち最下位の内部層の各内部ハッシュは、少なくとも2つの異なるリーフ・ハッシュの連結をハッシュすることによって生成される、内部層、および
iii)前記二次ブロック識別子を含むルート層を含み、前記二次ブロック識別子は、前記一つまたは複数の内部層のうち最上位の内部層の内部ハッシュの連結をハッシュすることによって生成される、
方法。
【請求項33】
前記コミットすることが、前記二次トランザクション識別子を、前記ブロックチェーンのブロック内の生成トランザクションにコミットすることを含む、請求項32に記載の方法。
【請求項34】
当該方法が:
前記トランザクションの集合を含む前記ブロックの一次ブロック識別子を取得するステップと;
前記二次ブロック識別子を前記ブロックチェーンの前記ブロックの前記生成トランザクションにコミットするステップとを含み、
前記一次ブロック識別子は:
前記トランザクションの集合における各トランザクションについて、それぞれの一次トランザクション識別子をそのトランザクションをハッシュすることによって生成するステップと;
ブロック・ハッシュ木を生成するステップとによって生成されたものであり、該ブロック・ハッシュ木は:
i)複数のリーフ・ハッシュを含むリーフ層であって、各リーフ・ハッシュは、前記一次トランザクション識別子のそれぞれに対応する、リーフ層、
ii)複数の内部ハッシュをそれぞれ含む一つまたは複数の内部層であって、各内部層における各内部ハッシュは、下位層からの少なくとも2つのハッシュの連結をハッシュすることによって生成され、該一つまたは複数の内部層のうち最下位の内部層の各内部ハッシュは、少なくとも2つの異なるリーフ・ハッシュの連結をハッシュすることによって生成される、内部層、および
iii)前記ブロック識別子を含むルート層を含み、前記ブロック識別子は、前記一つまたは複数の内部層のうち最上位の内部層の内部ハッシュの連結をハッシュすることによって生成される、
請求項32または33に記載の方法。
【請求項35】
一つまたは複数のメモリユニットを備えるメモリと;
一つまたは複数の処理ユニットを備える処理装置とを備える、コミット・ユーザーのコンピュータ設備であって、前記メモリは、前記処理装置上で動作するように構成されたコードを記憶し、該コードは、前記処理装置上で実行されたときに、請求項32ないし34のうちいずれか一項に記載の方法を実行するように構成される、コンピュータ設備。
【請求項36】
コミット・ユーザーのコンピュータ設備上で実行されたときに請求項32ないし34のうちいずれか一項に記載の方法を実行するように構成された、コンピュータ読み取り可能記憶装置上に具現されたコンピュータ・プログラム。
【請求項37】
ブロックチェーンのブロックの候補二次ブロック識別子が指定されたプロトコルに従って生成されたかどうかを検証する、コンピュータ実装される方法であって、前記ブロックは、トランザクションの集合を含み、当該方法は、検証ユーザーの計算装置によって実行され:
前記候補二次ブロック識別子を取得するステップと;
前記トランザクションの集合における各トランザクションについて、それぞれの二次トランザクション識別子を取得するステップと;
トランザクション集合ハッシュ木を生成するステップであって、該トランザクション集合ハッシュ木は:
i)複数のリーフ・ハッシュを含むリーフ層であって、各リーフ・ハッシュは、前記二次トランザクション識別子のそれぞれに対応する、リーフ層、
ii)複数の内部ハッシュをそれぞれ含む一つまたは複数の内部層であって、各内部層における各内部ハッシュは、下位層からの少なくとも2つのハッシュの連結をハッシュすることによって生成され、該一つまたは複数の内部層のうち最下位の内部層の各内部ハッシュは、少なくとも2つの異なるリーフ・ハッシュの連結をハッシュすることによって生成される、内部層、および
iii)前記二次ブロック識別子を含むルート層を含み、前記二次ブロック識別子は、前記一つまたは複数の内部層のうち最上位の内部層の内部ハッシュの連結をハッシュすることによって生成される、ステップと;
前記二次ブロック識別子が前記候補二次ブロック識別子と一致するかどうかを検証するステップとを含む、
方法。
【請求項38】
前記取得することが:
前記候補二次ブロック識別子をブロックチェーン・ネットワークのノードから受信すること;
前記候補二次ブロック識別子を前記ブロックチェーン・ネットワークの外部のノードから受信すること;および
前記候補二次ブロック識別子を前記ブロックチェーンのブロックのトランザクションから抽出すること、
のうちの一つまたは複数を含む、請求項37に記載の方法。
【請求項39】
一つまたは複数のメモリユニットを備えるメモリと、一つまたは複数の処理ユニットを備える処理装置とを備える、検証ユーザーのコンピュータ設備であって、前記メモリは、前記処理装置上で動作するように構成されたコードを記憶し、該コードは、前記処理装置上で実行されたときに、請求項37または38の方法を実行するように構成される、コンピュータ設備。
【請求項40】
検証ユーザーのコンピュータ設備上で実行されたときに請求項37または38の方法を実行するように構成された、コンピュータ読み取り可能記憶装置上に具現されたコンピュータ・プログラム。
【請求項41】
ブロックチェーンのブロックが候補データ・フィールドを含むターゲット・トランザクションを含むかどうかを判定する、コンピュータ実装される方法であって、前記ブロックは前記ターゲット・トランザクションを含むトランザクションの集合を含み、本方法は、照会ユーザーの計算装置によって実行され:
i)前記候補データ・フィールドのハッシュである候補リーフ・ハッシュ、ii)前記ターゲット・トランザクションの候補二次トランザクション識別子、およびiii)前記候補データ・フィールドについての認証経路を取得するステップと;
i)、ii)およびiii)を使用してハッシュ木証明を実行して二次トランザクション識別子を生成するステップと;
iv)候補二次ブロック識別子、およびv)該候補二次ブロック識別子についての認証経路を取得するステップと;
iv)、v)および生成された二次トランザクション識別子を使用してハッシュ木証明を実行して、二次ブロック識別子を生成するステップと;
vi)前記ターゲット・トランザクションの候補一次トランザクション識別子、vii)前記トランザクションの集合を含む前記ブロックの候補一次ブロック識別子、およびviii)該一次ブロック識別子についての認証経路を取得するステップと;
vi)、vii)、およびviii)を用いてハッシュ木証明を実行して、一次ブロック識別子を生成するステップとを含み、
前記判定は:a)生成された二次トランザクション識別子が候補二次トランザクション識別子と一致するかどうか、b)生成された二次ブロック識別子が候補二次ブロック識別子と一致するかどうか、およびc)生成された一次ブロック識別子が候補一次ブロック識別子と一致するかどうかに基づく、
方法。
【請求項42】
前記判定がさらに、前記トランザクションの集合を含む前記ブロックが、前記候補一次ブロック識別子および前記候補二次ブロック識別子を含むかどうかに基づく、請求項41に記載の方法。
【請求項43】
一つまたは複数のメモリユニットを備えるメモリと;
一つまたは複数の処理ユニットを備える処理装置とを備える、照会ユーザーのコンピュータ設備であって、前記メモリは、前記処理装置上で動作するように構成されたコードを記憶し、該コードは、前記処理装置上で実行されたときに、請求項41または42の方法を実行するように構成される、コンピュータ設備。
【請求項44】
照会ユーザーのコンピュータ設備上で実行されたときに請求項41または42の方法を実行するように構成された、コンピュータ読み取り可能記憶装置上に具現されたコンピュータ・プログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は、ブロックチェーンのブロック内のトランザクションが候補データ・フィールドを含むかどうかを照会ユーザーが検証できるようにするための方法に関する。
【背景技術】
【0002】
ブロックチェーンとは、ピアツーピア(P2P)ネットワークにおける複数のノードのそれぞれにおいて該ブロックチェーンの重複コピーが維持される、分散データ構造の形態を指す。ブロックチェーンは、データのブロックのチェーンを含み、各ブロックは、一つまたは複数のトランザクションを含む。各トランザクションは、順次、先行トランザクションを指し、ブロックチェーンの先頭の創生ブロックへと遡る。トランザクションは、「マイニング」として知られているプロセスによって新しいブロックに含められるよう、ネットワークに提出されることができる。マイニングは、複数のマイニング・ノードのそれぞれが「作業証明(proof-of-work)」を実行するために競合する、すなわち、ブロックに含まれるのを待っている未決のトランザクションのプールに基づく暗号パズルを解くことに関わる。
【0003】
通常、ブロックチェーン内のトランザクションは、デジタル資産、すなわち、価値のストアのはたらきをするデータを伝達するために使用される。しかしながら、ブロックチェーンは、ブロックチェーンの上に追加の機能を上乗せするために活用されることもできる。たとえば、ブロックチェーン・プロトコルは、トランザクションの出力に追加のユーザー・データを格納することを許容してもよい。現代のブロックチェーンは、単一トランザクション内に格納できる最大データ容量を増加させつつあり、より複雑なデータを組み込むことを可能にしている。たとえば、これは、ブロックチェーン内に電子文書を、あるいはさらにはオーディオまたはビデオデータ格納するために使用されてもよい。
【0004】
ネットワーク内の各ノードは、転送、マイニング、および格納の3つの役割のいずれか1つ、2つ、またはすべてをもつことができる。転送ノードは、ネットワークのノード全体にトランザクションを伝播させる。マイニング・ノードは、ブロック中へのトランザクションの前記マイニングを実行する。格納ノードはそれぞれ、ブロックチェーンのマイニングされたブロックの、自分自身のコピーを格納する。トランザクションをブロックチェーンに記録させるために、ある当事者が、トランザクションを、伝搬されるよう、ネットワークのノードの1つに送信する。トランザクションを受信するマイニング・ノードは、トランザクションをマイニングして新しいブロックに入れるよう競争する可能性がある。各ノードは、同じノード・プロトコルを尊重するように構成される。このプロトコルには、トランザクションが有効であるための一つまたは複数の条件を含む。無効なトランザクションは、伝搬されたり、マイニングされてブロックに入れられたりしない。トランザクションが有効確認され、それによりブロックチェーンに受け入れられたとすると、前記追加のユーザー・データは、変更不可能な公開レコードとしてP2Pネットワーク内の前記ノードのそれぞれに格納されたままとなる。
【0005】
最新のブロックを作成するために作業証明パズルを成功裏に解いたマイナー〔採掘者〕は、典型的には、前記デジタル資産の新しい量を生成する「生成トランザクション」と呼ばれるトランザクションをもって報酬を受ける。作業証明は、マイナーにとって、自分のブロックに二重使用トランザクションを含めることによってシステムを欺こうとしない誘因を与える。ブロックをマイニングするには大量の計算資源が必要であり、二重使用の試みを含むブロックは他のノードによって受け入れられない可能性が高いからである。
【0006】
ブロックチェーン内の各ブロックは、通例、そのブロック内のすべてのトランザクションのサマリーを含む。このサマリーは「マークル木(Merkle tree)」を使って作成される。マークル木は暗号学的ハッシュを含むハッシュ木である。文献では「マークル木」という用語は時に二分ハッシュ木を指すために使用されることがあるが、マークルによる当初の開示は二分ハッシュ木に限定されておらず、文献の他所では「ハッシュ木」と「マークル木」は同義で使用される。ここではたまたま前者の定義が採用される。「木」〔ツリー〕という用語は、分岐のあるデータ構造を指し、ツリーはいちばん上に「ルート」をもち、いちばん下に「リーフ」をもつ。マークル木は、ハッシュがルートまたはマークル・ルートと呼ばれる一つだけになるまで、ノードの対を再帰的にハッシュしていくことによって構築される。ルート・ハッシュは、ブロック内のトランザクションの集合全体の全体的なデジタル・フィンガープリントを表し、そのブロックにあるトランザクションが含まれるかどうかを検証する効率的なプロセスを提供する。特定のトランザクションがそのブロックに含まれていることを証明するためには、ノードは、その特定のトランザクションをツリーのルートに接続する認証経路または「マークル経路」を構成する比較的少数のハッシュを生成する必要があるだけである。
【発明の概要】
【発明が解決しようとする課題】
【0007】
ほとんどのブロックチェーン・エコシステムにおいて、さまざまなタイプのノードの機能と能力は多様であろう。たとえば、マイナーは、ブロックチェーンの完全なコピーを記憶し、すべての入ってくるトランザクションを検証することができるように、はるかに多くの計算資源へのアクセスをもつ可能性が高く、一方で、ブロックチェーンの平均的なユーザーは、支払いを作成し、ブロードキャストするために、より軽量のクライアントをもつ可能性が高い。
【0008】
マークル木、または一般にハッシュ木は、所与のトランザクションがブロックチェーン中にマイニングされたことを検証するために、ノードによって使用されうる。これは、当技術分野で単純化支払検証(simplified payment verification、SPV)と呼ばれるが、支払トランザクションの検証に限定されない。この検証方法は、通例、ノード(これは軽量クライアントのみを実行しているものであってもよい)が完全なトランザクション・データを取得し、それをハッシュし、「マークル証明(Merkle proof)」を実行することを要求する。
【0009】
現在のところ、SPV法は、画像ファイルのようなブロックチェーン内の小さなサイズのデータの存在を検証する必要がある軽量クライアントに適している。しかしながら、ブロックチェーン・エコシステムが規模を拡大するにつれて、トランザクション・サイズは著しく増加する可能性が高く、それとともに、その中に埋め込まれる任意のデータ・パケットのサイズも増加する可能性が高い。これは、特に軽量クライアントにとっては、トランザクションを検証するときに問題である。トランザクション全体がハッシュされる必要があり、そのことは、ブロックチェーン上のトランザクション内にはるかに小さな(たとえばキロバイトの)データ・パケットが存在することを検証するために、大きな(たとえばメガバイトまたはギガバイトの)トランザクションを取得する必要がありうることを意味するからである。
【0010】
よって、ノード(たとえば、軽量クライアント)にとって、完全なトランザクションを得る必要なしに、トランザクションの一部(たとえば、前記の、より小さなデータ・パケット)の存在を証明できることが望ましいであろう。
【課題を解決するための手段】
【0011】
本明細書に開示されるある側面によれば、ターゲット・トランザクションの二次トランザクション識別子を生成する、コンピュータ実装される方法が提供される。前記二次トランザクション識別子は、照会ユーザーが、ターゲット・トランザクションが候補データ・フィールドを含むかどうかを判定できるようにする。本方法は、生成ユーザーによって実行され:前記ターゲット・トランザクションのデータ・フィールドの集合を識別するステップであって、各データ・フィールドは、前記トランザクションのそれぞれのデータを含む、ステップと;トランザクション・ハッシュ木を生成するステップとを含み、前記トランザクション・ハッシュ木は、i)複数のリーフ・ハッシュを含むリーフ層であって、各データ・フィールドはハッシュされて、前記複数のリーフ・ハッシュのそれぞれ1つを生成する、リーフ層、ii)複数の内部ハッシュをそれぞれ含む一つまたは複数の内部層であって、各内部層における各内部ハッシュは、下位層からの少なくとも2つのハッシュの連結をハッシュすることによって生成され、前記一つまたは複数の内部層のうち最下位の内部層の各内部ハッシュは、少なくとも2つの異なるリーフ・ハッシュの連結をハッシュすることによって生成される、内部層、およびiii)前記二次トランザクション識別子を含むルート層を含み、前記二次トランザクション識別子は、前記一つまたは複数の内部層のうち最上位の内部層の内部ハッシュの連結をハッシュすることによって生成される。
【0012】
本開示は、ノード(すなわち、照会ユーザー)がトランザクションの個々のデータ・フィールドを検証することを許容するために、マークル木、またはより一般的にはハッシュ木が活用できるさらなる方法を認識する。トランザクションは、ハッシュ木を生成するために、データ・フィールドの集合に分割(またはパース)される。すなわち、トランザクションの異なる部分が別個のデータ・フィールドとして識別される。ハッシュ木のルートは、トランザクションの新規な二次識別子として役立つ。たとえば、軽量クライアントを操作しているだけでありうる照会ユーザーは、完全なトランザクション・データを取得してハッシュする必要なく、トランザクションにおける(小さな)データ・フィールドの存在を証明するよう、二次識別子を使用して証明を実行できる。
【0013】
二次トランザクション識別子は、完全なトランザクション・データへのアクセスをもつ任意のユーザーによって生成されてもよい。たとえば、生成ユーザーは、トランザクションを受け取ったマイナー、ブロックチェーン・ネットワークのユーザー(たとえばトランザクションを生成したアリス)、あるいは、トランザクションを提供された、または閲覧できる、ブロックチェーン・ネットワークの外部のユーザーであってもよい。
【0014】
本明細書に開示される別の側面によれば、照会ユーザーが、ブロックチェーンのブロック内のターゲット・トランザクションが候補データ・フィールドを含むかどうかを判定できるようにする方法が提供される。本方法は、コミット・ユーザーによって実行され:前記ターゲット・トランザクションの二次トランザクション識別子を取得するステップと;前記二次トランザクション識別子を、前記ブロックチェーンのブロック内に含めるためにトランザクションにコミットするステップとを含み、前記二次トランザクション識別子は:前記ターゲット・トランザクションのデータ・フィールドの集合を識別するステップであって、各データ・フィールドは、前記トランザクションのそれぞれのデータを含む、ステップと;トランザクション・ハッシュ木を生成するステップとによって生成されたものであり、前記トランザクション・ハッシュ木は、i)データ・フィールドの順序付けられた集合に基づいて順序付けられた複数のリーフ・ハッシュを含むリーフ層であって、各データ・フィールドはハッシュされて、前記複数のリーフ・ハッシュのそれぞれ1つを生成する、リーフ層、ii)複数の内部ハッシュをそれぞれ含む一つまたは複数の内部層であって、各内部層における各内部ハッシュは、下位層からの少なくとも2つのハッシュの連結をハッシュすることによって生成され、前記一つまたは複数の内部層のうち最下位の内部層の各内部ハッシュは、少なくとも2つの異なるリーフ・ハッシュの連結をハッシュすることによって生成される、内部層、およびiii)前記二次トランザクション識別子を含むルート層を含み、前記二次トランザクション識別子は、前記一つまたは複数の内部層のうち最上位の内部層の内部ハッシュの連結をハッシュすることによって生成される。
【0015】
二次トランザクション識別子は、照会ユーザーがアクセスするためにチェーン上に(on-chain)記憶されてもよい。追加的または代替的に、Tx1の二次トランザクション識別子が、異なるトランザクションTx2に記録されてもよい。二次トランザクション識別子は、マイナーによって生成トランザクションにおいて記録されてもよい。
【0016】
任意のユーザーが、二次トランザクション識別子をチェーン上に記録する(すなわち、ブロックチェーン上に含まれるようにする)ことができる。たとえば、マイナーは、ブロック(ターゲット・トランザクションを含む同じブロックまたは異なるブロック)の生成トランザクションの中にそれを含めてもよい。あるいはまた、ある当事者(たとえば、アリス)は、二次トランザクション識別子を含む(有効な)トランザクションを、ブロックチェーン中にマイニングされるよう、一つまたは複数のノードに送信することによって、その識別子がブロックチェーンのブロック内に含まれるようにすることができる。
【0017】
本明細書に開示されるある側面によれば、ブロックチェーンのブロック内のターゲット・トランザクションの候補二次トランザクション識別子が指定されたプロトコルに従って生成されたものであるかどうかを検証する、コンピュータ実装される方法が提供される。本方法は、検証ユーザーによって実行され:前記候補二次トランザクション識別子を取得するステップと;前記ターゲット・トランザクションのデータ・フィールドの集合を識別するステップであって、各データ・フィールドは、前記トランザクションのそれぞれのデータを含む、ステップと;トランザクション・ハッシュ木を生成するステップであって、前記トランザクション・ハッシュ木は、i)複数のリーフ・ハッシュを含むリーフ層であって、各データ・フィールドはハッシュされて、それぞれのリーフ・ハッシュを生成する、リーフ層、ii)複数の内部ハッシュをそれぞれ含む一つまたは複数の内部層であって、各内部層における各内部ハッシュは、下位層からの少なくとも2つのハッシュの連結をハッシュすることによって生成され、最下位の内部層の各内部ハッシュは、少なくとも2つの異なるリーフ・ハッシュの連結をハッシュすることによって生成される、内部層、およびiii)前記二次トランザクション識別子を含むルート層を含み、前記二次トランザクション識別子は、最上位の内部層の内部ハッシュの連結をハッシュすることによって生成される、ステップと;前記二次トランザクション識別子が前記候補二次トランザクション識別子と一致するかどうかを検証するステップとを含む。
【0018】
これにより、完全なトランザクションへのアクセスをもつ任意のユーザー(たとえば、マイナーのような、ブロックチェーン・ネットワークのノード)は、生成ユーザーが前記二次トランザクション識別子を生成するために正しいプロトコルを使用したかどうか(たとえば、トランザクション・データ・フィールドの正しい識別、およびハッシュ木の正しい生成)を検証することができる。記録ユーザーが正しいプロトコルを使用したことを検証すると、検証ノードは、たとえば照会ユーザーのような他のブロックチェーン・ユーザーに知らせることによって、その事実を認証することができる。
【0019】
本明細書に開示される別の側面によれば、ブロックチェーンのブロック内のターゲット・トランザクションが候補データ・フィールドを含むかどうかを判定する、コンピュータ実装される方法が提供される。本方法は、照会ユーザーによって実行され:候補リーフ・ハッシュを取得するステップであって、前記候補リーフ・ハッシュは前記候補データ・フィールドのハッシュである、ステップと;前記ターゲット・トランザクションの候補二次トランザクション識別子を取得するステップであって、前記二次トランザクション識別子は、前記ターゲット・トランザクションのデータ・フィールドの集合を識別するステップであって、各データ・フィールドが前記トランザクションのそれぞれのデータを含む、ステップ、および、トランザクション・ハッシュ木を生成するステップであって、前記トランザクション・ハッシュ木のルート層が、前記二次トランザクション識別子を含む、ステップによって生成されたものである、ステップと;前記候補データ・フィールドについての認証経路を取得するステップであって、前記認証経路は、順序付けられたハッシュの集合を含み、前記順序付けられたハッシュの集合は、少なくとも1つのリーフ・ハッシュおよび内部ハッシュの一つまたは複数の集合を含み、前記内部ハッシュの各集合は前記トランザクション・ハッシュ木のそれぞれの内部層に属する、ステップと;取得された候補リーフ・ハッシュ、取得された二次トランザクション識別子、前記候補データ・フィールドについての取得された認証経路を使用してハッシュ木証明を実行するステップであって、該実行することは二次トランザクション識別子を生成する、ステップとを含み、前記判定は、前記二次トランザクション識別子が前記候補二次トランザクション識別子と一致するかどうかに基づく。
【0020】
上述のように、現在、ブロックチェーン上のトランザクションの存在を検証するためにSPV法が使用される。その方法では、ブロック内の各トランザクションがハッシュ木のリーフを形成する。対照的に、本開示は、個々のデータ・フィールドをハッシュ木のリーフとして使用して、それらのデータ・フィールドの1つの存在を検証する。N個のデータ・フィールドがハッシュされ、ルート・ハッシュにおいて要約されると、照会ユーザーは、ハッシュ木証明(ハッシュ木がマークル木の場合はマークル証明と呼ばれる)を実行することによって、任意のあるデータ・フィールド(候補データ・フィールド)がハッシュ木に(よってトランザクションに)含まれるかどうかを確認することができる。これを行うために、照会ユーザーは、ハッシュ木経路とも呼ばれる認証経路(ハッシュ木がマークル木の場合はマークル経路とも呼ばれる)を提供される。照会ユーザーは、候補二次トランザクション識別子(ルート・ハッシュ)が生成されるまで、ハッシュ木経路の一連のハッシュを用いて候補データ・フィールドを再帰的にハッシュする。二次トランザクション識別子は、それを生成するために使用される基礎となるハッシュ関数と同じくらい一意的である。よって、ハッシュ関数の特性のために、候補二次トランザクション識別子は、候補データ・フィールドがその同じトランザクションの一部である場合にのみ、トランザクションの二次トランザクション識別子と同一になる。候補二次トランザクション識別子と取得された二次トランザクション識別子が一致する場合、照会ユーザーは、候補データ・フィールドがトランザクションの一部をなすことを確信することができる。
【0021】
本明細書に開示される別の側面によれば、ブロックチェーンのブロックの二次ブロック識別子を生成する、コンピュータ実装される方法が提供される。前記ブロックは、トランザクションの集合を含み、前記二次ブロック識別子は、照会ユーザーが、前記トランザクションの集合が候補データ・フィールドを含むかどうかを判定することを可能にし、本方法は、生成ユーザーによって実行され:前記トランザクションの集合の各トランザクションについて、それぞれの二次トランザクション識別子を取得するステップと;トランザクション集合ハッシュ木を生成するステップとを含み、該トランザクション集合ハッシュ木は:i)複数のリーフ・ハッシュを含むリーフ層であって、各リーフ・ハッシュは、前記二次トランザクション識別子のそれぞれに対応する、リーフ層、ii)複数の内部ハッシュをそれぞれ含む一つまたは複数の内部層であって、各内部層における各内部ハッシュは、下位層からの少なくとも2つのハッシュの連結をハッシュすることによって生成され、該一つまたは複数の内部層のうち最下位の内部層の各内部ハッシュは、少なくとも2つの異なるリーフ・ハッシュの連結をハッシュすることによって生成される、内部層、およびiii)前記二次ブロック識別子を含むルート層を含み、前記二次ブロック識別子は、前記一つまたは複数の内部層のうち最上位の内部層の内部ハッシュの連結をハッシュすることによって生成される。
【0022】
ここで、ブロック内の各トランザクションのそれぞれの二次トランザクション識別子が「トランザクション・ハッシュ木の木」としてリーフとして使用される。つまり、各二次トランザクション識別子は、それ自体、トランザクション・ハッシュ木のルート・ハッシュである。トランザクション・ハッシュ木の木(トランザクション集合ハッシュ木とも呼ばれる)のルートは、ブロック内のすべてのトランザクションの圧縮であるため、二次ブロック識別子として機能する。二次ブロック識別子は、すべての二次トランザクション識別子を取得できる(たとえば生成できる)任意のユーザーによって生成されうる。たとえば、生成ユーザーは、二次トランザクション識別子を生成したマイナーであってもよい。あるいはまた、二次トランザクション識別子は、二次トランザクション識別子を含むトランザクション(たとえば生成トランザクション)から抽出されてもよい。
【0023】
ブロックを識別する他の方法、たとえばブロック・ヘッダ、ブロックの高さ、ブロックの深さ、ブロック番号があることに注意されたい。しかしながら、「ブロック識別子」という用語は、ハッシュ木の(マークル)ルートを指すために全体を通して使用される。たとえば、二次ブロック識別子は、トランザクション木の木のルートである。
【0024】
本明細書に開示される別の側面によれば、照会ユーザーが、ブロックチェーンのブロック内のトランザクションの集合が候補データ・フィールドを含むかどうかを判定することを可能にする方法が提供される。本方法は、コミット・ユーザーによって実行され:前記トランザクションの集合を含む前記ブロックの二次ブロック識別子を取得するステップと;前記二次ブロック識別子を前記ブロックチェーンのブロック内に含めるためにトランザクションにコミットするステップとを含み、前記二次ブロック識別子は:前記トランザクションの集合における各トランザクションについて、それぞれの二次トランザクション識別子を取得するステップと;トランザクション集合ハッシュ木を生成するステップとによって生成されたものであり、該トランザクション集合ハッシュ木は:i)複数のリーフ・ハッシュを含むリーフ層であって、各リーフ・ハッシュは、前記二次トランザクション識別子のそれぞれに対応する、リーフ層、ii)複数の内部ハッシュをそれぞれ含む一つまたは複数の内部層であって、各内部層における各内部ハッシュは、下位層からの少なくとも2つのハッシュの連結をハッシュすることによって生成され、該一つまたは複数の内部層のうち最下位の内部層の各内部ハッシュは、少なくとも2つの異なるリーフ・ハッシュの連結をハッシュすることによって生成される、内部層、およびiii)前記二次ブロック識別子を含むルート層を含み、前記二次ブロック識別子は、前記一つまたは複数の内部層のうち最上位の内部層の内部ハッシュの連結をハッシュすることによって生成される。
【0025】
ここでもまた、前記二次トランザクション識別子へのアクセスをもつ任意のユーザー(たとえば、それらの識別子を生成したユーザー)は、前記二次ブロック識別子を生成することができる。ただし、ブロックの生成トランザクションの中で、前記二次ブロック識別子を記録できるのは、マイナーのみである。
【0026】
本明細書に開示される別の側面によれば、ブロックチェーンのブロックの候補二次ブロック識別子が指定されたプロトコルに従って生成されたかどうかを検証する、コンピュータ実装される方法が提供される。前記ブロックは、トランザクションの集合を含み、本方法は、検証ユーザーによって実行され:前記候補二次ブロック識別子を取得するステップと;前記トランザクションの集合における各トランザクションについて、それぞれの二次トランザクション識別子を取得するステップと;トランザクション集合ハッシュ木を生成するステップであって、該トランザクション集合ハッシュ木は:i)複数のリーフ・ハッシュを含むリーフ層であって、各リーフ・ハッシュは、前記二次トランザクション識別子のそれぞれに対応する、リーフ層、ii)複数の内部ハッシュをそれぞれ含む一つまたは複数の内部層であって、各内部層における各内部ハッシュは、下位層からの少なくとも2つのハッシュの連結をハッシュすることによって生成され、該一つまたは複数の内部層のうち最下位の内部層の各内部ハッシュは、少なくとも2つの異なるリーフ・ハッシュの連結をハッシュすることによって生成される、内部層、およびiii)前記二次ブロック識別子を含むルート層を含み、前記二次ブロック識別子は、前記一つまたは複数の内部層のうち最上位の内部層の内部ハッシュの連結をハッシュすることによって生成される、ステップと;前記二次ブロック識別子が前記候補二次ブロック識別子と一致するかどうかを検証するステップとを含む。
【0027】
これは、前記トランザクションの各トランザクションの全体(たとえば、マイナーや記憶ノードのようなブロックチェーン・ネットワークのノード)へのアクセスをもつ任意のユーザーが、生成ユーザーが二次ブロック識別子を生成するために正しいプロトコルを使用したかどうか(たとえば、トランザクション集合ハッシュ木の正しい生成)を検証することを可能にする。
【0028】
本明細書に開示される別の側面によれば、ブロックチェーンのブロックが候補データ・フィールドを含むターゲット・トランザクションを含むかどうかを判定する、コンピュータ実装される方法が提供される。前記ブロックは前記ターゲット・トランザクションを含むトランザクションの集合を含み、本方法は、照会ユーザーによって実行され:i)前記候補データ・フィールドのハッシュである候補リーフ・ハッシュ、ii)前記ターゲット・トランザクションの候補二次トランザクション識別子、およびiii)前記候補データ・フィールドについての認証経路を取得するステップと;i)、ii)およびiii)を使用してハッシュ木証明を実行して二次トランザクション識別子を生成するステップと;iv)候補二次ブロック識別子、およびv)該候補二次ブロック識別子についての認証経路を取得するステップと;iv)、v)および生成された二次トランザクション識別子を使用してハッシュ木証明を実行して、二次ブロック識別子を生成するステップと;vi)前記ターゲット・トランザクションの候補一次トランザクション識別子、vii)前記トランザクションの集合を含む前記ブロックの候補一次ブロック識別子、およびviii)該一次ブロック識別子についての認証経路を取得するステップと;vi)、vii)、およびviii)を用いてハッシュ木証明を実行して、一次ブロック識別子を生成するステップとを含み、前記判定は:a)生成された二次トランザクション識別子が候補二次トランザクション識別子と一致するかどうか、b)生成された二次ブロック識別子が候補二次ブロック識別子と一致するかどうか、およびc)生成された一次ブロック識別子が候補一次ブロック識別子と一致するかどうかに基づく。
【0029】
候補ブロック識別子と生成されたブロック識別子(一次バージョンと二次バージョンのそれぞれについて)互いに一致することを確認すると、照会ユーザーは、ブロックチェーン中にマイニングされたブロックがターゲット・トランザクションを含み、ターゲット・トランザクションが候補データ・フィールドを含むことを確信することができる。これは、一次ブロック識別子と二次ブロック識別子の両方が、同じ入力データ(トランザクション)から構築されており、そのことが、作業証明コンセンサスのため、信頼されるからである。
【図面の簡単な説明】
【0030】
本開示の実施形態の理解を助け、そのような実施形態がどのように実施されうるかを示すために、単に例として添付の図面が参照される。
図1】ブロックチェーンを実装するシステムの概略ブロック図である。
図2】ブロックチェーンに記録されうるトランザクションのいくつかの例を概略的に示す。
図3】ブロックチェーンを実装するための別のシステムの概略ブロック図である。
図4】マークル木の概略図である。
図5】マークル経路を使用した、ルートによって表されるツリーにおけるデータ・ブロックのマークル存在証明を示す。
図6】トランザクション・マークル木の概略図である。
図7】ブロック・マークル木の概略図であり、そのルートは有効なブロックのブロック・ヘッダに含まれる。
図8】諸トランザクション・マークル木の木のルートが生成トランザクションに含まれるブロックの概略図である。
図9】aおよびbは、それぞれ、トランザクションに格納された例示的な学術論文データの完全版および軽量版を示す。
【発明を実施するための形態】
【0031】
図1は、ブロックチェーン150を一般的に実装するための例示的なシステム100を示す。システム100は、典型的にはインターネットのような広域インターネットワークであるパケット交換ネットワーク101を含む。パケット交換ネットワーク101は、パケット交換ネットワーク101内にピアツーピア(P2P)オーバーレイ・ネットワーク106を形成するように構成された複数のノード104を含む。各ノード104はピアのコンピュータ設備を含み、異なるノード104は異なるピアに属する。各ノード104は、一つまたは複数のプロセッサ、たとえば、一つまたは複数の中央処理装置(CPU)、アクセラレータ・プロセッサ、特定用途向けプロセッサ、および/またはフィールド・プログラマブル・ゲート・アレイ(ASIC)を含む処理装置を含む。各ノードはまた、メモリ、すなわち、非一時的なコンピュータ読み取り可能媒体またはメディアの形のコンピュータ読み取り可能記憶をも有する。メモリは、一つまたは複数のメモリ媒体、たとえば、ハードディスクなどの磁気媒体、固体ドライブ(SSD)、フラッシュメモリまたはEEPROMなどの電子媒体、および/または光ディスク・ドライブなどの光媒体を使用する一つまたは複数のメモリユニットを含んでいてもよい。
【0032】
ブロックチェーン150は、データ151のブロックのチェーンを含み、ブロックチェーン150のそれぞれのコピーは、P2Pネットワーク160内の複数のノードのそれぞれに維持される。チェーン内の各ブロック151は、一つまたは複数のトランザクション152を含み、ここで、この文脈におけるトランザクションは、一種のデータ構造をいう。データ構造の性質は、トランザクション・モデルまたはスキームの一部として使用されるトランザクション・プロトコルのタイプに依存する。所与のブロックチェーンは、典型的には、全体を通して、1つの特定のトランザクション・プロトコルを使用する。1つの一般的なタイプのトランザクション・プロトコルでは、各トランザクション152のデータ構造は、少なくとも1つの入力および少なくとも1つの出力を含む。各出力は、ユーザー103に属するある量のデジタル資産を表す量〔額〕を指定し、該出力は暗号学的にそのユーザーにロックされている(ロック解除され、それにより償還または使用されるためには、そのユーザーの署名を必要とする)。各入力は、先行するトランザクション152の出力に遡って参照し、それによりトランザクションをリンクする。
【0033】
ノード104の少なくともいくつかは、トランザクション152を転送し、それにより伝搬させる転送ノード104Fの役割を担う。ノード104の少なくともいくつかは、ブロック151を採掘するマイナー104Mの役割を担う。ノード104の少なくともいくつかは、記憶ノード104S(時に「完全コピー」ノードとも呼ばれる)の役割を担い、各記憶ノードは、それぞれのメモリに同じブロックチェーン150のそれぞれのコピーを記憶する。各マイナー・ノード104Mはまた、ブロック151中にマイニングされるのを待つトランザクション152のプール154を維持する。所与のノード104は、転送ノード104、マイナー104M、記憶ノード104S、またはこれらの2つもしくは全部の任意の組み合わせでありうる。
【0034】
所与の現在のトランザクション152jにおいて、入力(または各入力)は、トランザクションのシーケンスにおける先行するトランザクション152iの出力を参照するポインタを含み、それが、この出力が現在のトランザクション152jにおいて償還または「消費」されることを指定する。一般に、先行するトランザクションは、プール154または任意のブロック151における任意のトランザクションでありうる。先行するトランザクション152iは、現在のトランザクション152jが作成され、または、ネットワーク106に送信される時点では必ずしも存在する必要はないが、現在のトランザクションが有効であるためには、先行するトランザクション152iが存在し、かつ、有効確認される必要がある。よって、本明細書において、「先行」とは、必ずしも時間的なシーケンスにおける生成または送信の時ではなく、ポインタによってリンクされる論理的なシーケンスにおける先行者を意味し、よって、トランザクション152i、152jが順序外で生成または送信されることを必ずしも排除しない(オーファン・トランザクションに関する後述の議論を参照)。先行するトランザクション152iは、等価に、先立つトランザクションまたは先行者トランザクションと呼ばれることができる。
【0035】
現在のトランザクション152jの入力は、先行するトランザクション152iの出力がロックされているユーザー103aの署名も含む。そして、現在のトランザクション152jの出力は、新しいユーザー103bに暗号的にロックされることができる。よって、現在のトランザクション152jは、先行するトランザクション152iの入力において定義された量を、現在のトランザクション152jの出力において定義された新しいユーザー103bに移転することができる。いくつかの場合には、トランザクション152は、複数のユーザー間で入力量を分割するために複数の出力を有してもよい(おつりを与えるために、該複数のユーザーのうちの一はもとのユーザー103aであってもよい)。場合によっては、トランザクションが複数の入力をもち、一つまたは複数の先行トランザクションの複数の出力からの額を一緒に集め、現在のトランザクションの一つまたは複数の出力に再分配することもできる。
【0036】
上記は、「出力ベース」トランザクション・プロトコルと呼ばれることがあり、時には未使用トランザクション出力(unspent transaction output、UTXO)タイプのプロトコルとも呼ばれることもある。ユーザーの合計残高は、ブロックチェーンに格納されるどの1つの数字においても定義されず、その代わり、ユーザーは、ブロックチェーン151内の多くの異なるトランザクション152に散在する、そのユーザーのすべてのUTXOの値を照合するために、特別な「ウォレット」アプリケーション105を必要とする。
代替的なタイプのトランザクション・プロトコルは、アカウント〔口座〕ベースのトランザクション・モデルの一部として、「アカウント・ベースの」プロトコルと呼ばれることがある。アカウント・ベースの場合、各トランザクションは、過去のトランザクションのシーケンスにおける先行するトランザクションのUTXOを遡って参照することによってではなく、絶対的なアカウント残高を参照することによって、移転される金額を定義する。すべてのアカウントの現在の状態は、ブロックチェーンとは別個にマイナーによって記憶され、常時更新される。そのようなシステムでは、トランザクションは、アカウントのランニング・トランザクション記録(running transaction tally)(「ポジション」とも呼ばれる)を用いて順序付けられる。この値は、送信者によって暗号署名の一部として署名され、トランザクション参照計算の一部としてハッシュされる。さらに、任意的なデータ・フィールドもトランザクションで署名されることがある。このデータ・フィールドは、たとえば前のトランザクションIDが該データ・フィールドに含まれている場合、前のトランザクションを指してもよい。
【0037】
いずれのタイプのトランザクション・プロトコルでも、ユーザー103が新しいトランザクション152jを制定することを望む場合、ユーザーは、自分のコンピュータ端末102からP2Pネットワーク106のノード104の1つ(今日では、これは典型的にはサーバーまたはデータ・センターであるが、原理的には他のユーザー端末でもよい)に新しいトランザクションを送信する。このノード104は、各ノード104で適用されるノード・プロトコルに従って、そのトランザクションが有効であるかどうかをチェックする。ノード・プロトコルの詳細は、問題のブロックチェーン150において使用されているトランザクション・プロトコルのタイプに対応し、それらが一緒になって全体的なトランザクション・モデルをなす。ノード・プロトコルは、典型的には、新規トランザクション152jにおける暗号署名が、トランザクション152の順序付けされたシーケンスにおける先行するトランザクション152iに依存する期待される署名と一致することをチェックするために、ノード104を必要とする。出力ベースの場合、これは、新しいトランザクション152jの入力に含まれるユーザーの暗号署名が、新しいトランザクションが費やす先行トランザクション152iの出力において定義された条件にマッチすることをチェックすることを含んでいてもよく、この条件は、典型的には、新しいトランザクション152jの入力における暗号署名が、新しいトランザクションの入力がポイントする先行トランザクション152iの出力をロック解除することを少なくともチェックすることを含む。いくつかのトランザクション・プロトコルでは、条件は、少なくとも部分的には、入力および/または出力に含まれるカスタム・スクリプトによって定義されてもよい。あるいはまた、条件は、単にノード・プロトコルだけによって固定されてもよく、あるいは、これらの組み合わせによることもある。いずれにせよ、新しいトランザクション152jが有効であれば、現在のノードは、それをP2Pネットワーク106内のノード104のうちの一つまたは複数の他のノードに転送する。これらのノード104の少なくともいくつかは、転送ノード104Fとしても機能し、同じノード・プロトコルに従って同じテストを適用して、新しいトランザクション152jを一つまたは複数のさらなるノード104に転送する。このようにして、新しいトランザクションは、ノード104のネットワーク全体に伝搬させられる。
【0038】
出力ベースのモデルでは、所与の出力(たとえば、UTXO)が消費されるかどうかの定義は、それがノード・プロトコルに従った別の、前進(onward)トランザクション152jの入力によってすでに有効に償還されているかどうかである。トランザクションが有効であるための別の条件は、それが消費または償還しようとする先行トランザクション152iの出力が、別の有効なトランザクションによってすでに使用/償還されていないことである。ここでもまた、有効でない場合、トランザクション152jは、ブロックチェーンにおいて伝搬または記録されない。これは、使用者が同じトランザクションの出力を複数回使おうとする二重使用に対する防護となる。一方、アカウント・ベースのモデルは、アカウント残高を維持することによって、二重使用に対する防護とする。この場合も、トランザクションの順序が定義されているため、どの一つの時点でも、アカウント残高は単一の定義された状態をもつ。
【0039】
有効確認に加えて、ノード104Mの少なくとも一部は、「作業証明」によって裏付けられる、マイニングとして知られるプロセスにおいて、トランザクションのブロックを最初に生成するために競争する。マイニング・ノード104Mでは、まだブロックに現れていない有効なトランザクションのプールに新規トランザクションが追加される。次いで、マイナーは、暗号学的パズルを解こうと試みることによって、トランザクションのプール154からトランザクション152の新しい有効なブロック151を組み立てるために競争する。典型的には、これは、ナンスがトランザクションのプール154と連結され、ハッシュされるときに、ハッシュの出力が所定の条件を満たすように、「ナンス」値を探すことを含む。たとえば、所定の条件は、ハッシュの出力が、あるあらかじめ定義された数の先頭ゼロを有するというものであってもよい。ハッシュ関数の特性は、入力に関して予測不可能な出力をもつことである。よって、この探索は、力づくによってのみ実行でき、よって、パズルを解こうとしている各ノード104Mにおいて相当な量の処理資源を消費する。
【0040】
パズルを解いた最初のマイナー・ノード104Mは、これをネットワーク106に告知し、その解を証明として提供する。証明は、ネットワーク内の他のノード104によって容易にチェックすることができる(ひとたびハッシュに対する解が与えられたら、それによりハッシュの出力が条件に合致することをチェックすることは簡単である)。勝者がパズルを解いたトランザクションのプール154は、次いで、記憶ノード104Sとして機能するノード104の少なくとも一部によって、そのような各ノードにおいて勝者が発表した解をチェックしたことに基づいて、ブロックチェーン150内の新しいブロック151として記録される。チェーン内の先に生成されたブロック151n-1を遡ってポイントするブロック・ポインタ155も、新しいブロック151nに割り当てられる。作業証明は、二重使用のリスクを低減するのに役立つ。新しいブロック151を作成するためには多大な努力を要し、二重使用を含むブロックは他のノード104によって拒否される可能性が高いので、マイニング・ノード104Mにとって、自分のブロックに二重使用が含まれることを許容する動機がないのである。ひとたび生成されると、ブロック151は、P2Pネットワーク106内の記憶ノード104Sのそれぞれにおいて、同じプロトコルに従って認識され、維持されるので、修正できない。ブロック・ポインタ155はまた、ブロック151に逐次的な順序を課す。トランザクション152は、P2Pネットワーク106内の各記憶ノード104Sにおいて順序付けられたブロックに記録されるので、これは、トランザクションの変更不能な公開台帳を提供する。
【0041】
任意の所与の時点においてパズルを解くために競争する異なるマイナー104Mが、いつ解を探し始めたかに応じて、任意の所与の時点における、マイニングされていないトランザクション・プール154の異なるスナップショットに基づいて、そうすることがありうることに留意されたい。誰であれ最初にそれぞれのパズルを解いた者が、どのトランザクション152が次の新しいブロック151nに含まれるかを定義し、マイニングされていないトランザクションの現在のプール154が更新される。マイナー104Mは、次いで、新たに定義された未決のプール154からブロックを生成するために競争を続ける。生じ得る「フォーク」を解決するためのプロトコルも存在する。フォークとは、2人のマイナー104Mが互いの非常に短い時間以内にパズルを解き、ブロックチェーンの矛盾したビューが伝播するというものである。要するに、フォークのどちらの支流が伸びても、最も長いほうが確定的なブロックチェーン150となる。
【0042】
ほとんどのブロックチェーンでは、勝ったマイナー104Mは、自動的に、(あるユーザーから別のユーザーにある量のデジタル資産を移転する通常のトランザクションとは対照的に)新しい量のデジタル資産を無から創出する特別な種類の新しいトランザクションを用いて報酬を受ける。よって、勝ったノードは、ある量のデジタル資産を「採掘」したと言われる。この特殊なタイプのトランザクションは、「生成」トランザクションと呼ばれることもある。それは自動的に新しいブロック151nの一部を形成する。この報酬は、マイナー〔採掘者〕104Mが作業証明競争に参加するインセンティブを与える。通常の(非生成)トランザクション152は、しばしば、その出力の1つにおいて追加のトランザクション料をも指定し、そのトランザクションが含められたブロック151nを生成した勝ったマイナー104Mにさらに報酬を与える。
【0043】
マイニング〔採掘〕に関わる計算資源のため、典型的には、少なくともマイナー・ノード104Mのそれぞれは、一つまたは複数の物理的サーバー・ユニットを含むサーバー、またはさらにはデータ・センター全体の形をとる。各転送ノード104Mおよび/または記憶ノード104Sも、サーバーまたはデータ・センターの形をとることができる。しかしながら、原則として、任意の所与のノード104は、ユーザー端末または互いにネットワーク接続されたユーザー端末のグループの形をとることができる。
【0044】
各ノード104のメモリは、それぞれの役割(単数または複数)を実行し、ノード・プロトコルに従ってトランザクション152を処理するために、ノード104の処理装置上で動作するように構成されたソフトウェアを記憶する。本明細書においてノード104に帰されるいずれの動作も、それぞれのコンピュータ装置の処理装置上で実行されるソフトウェアによって実行されうることが理解されよう。また、本明細書で使用される用語「ブロックチェーン」は、当該種類の技術一般を指す一般的な用語であり、いかなる特定の固有のブロックチェーン、プロトコルまたはサービスにも限定しない。
【0045】
ネットワーク101には、消費ユーザーの役割の複数の当事者103の各当事者のコンピュータ設備102も接続されている。これらは、トランザクションにおける支払人および払受人として行動するが、必ずしも他の当事者のための採掘または伝播トランザクションには参加しない。必ずしもマイニング・プロトコルを実行しない。2の当事者103およびそれぞれの設備102が例解目的のために示されている:第1の当事者103aおよびそのそれぞれのコンピュータ設備102a、ならびに第2の当事者103bおよびそのそれぞれのコンピュータ設備102bである。より多くのそのような当事者103およびそれらのそれぞれのコンピュータ設備102がシステムに存在し、参加することがありうるが、便宜上、それらは図示されていないことが理解されよう。各当事者103は、個人または組織でありうる。純粋に例示として、第1の当事者103aは、本明細書においてアリスと称され、第2の当事者103bは、ボブと称されるが、これは限定するものではなく、本明細書におけるアリスまたはボブという言及は、それぞれ「第1の当事者」および「第2の当事者」と置き換えることができることは理解されるであろう。
【0046】
各当事者103のコンピュータ設備102は、一つまたは複数のプロセッサ、たとえば、一つまたは複数のCPU、GPU、他のアクセラレータ・プロセッサ、特定用途向けプロセッサ、および/またはFPGAを含むそれぞれの処理装置を備える。各当事者103のコンピュータ設備102は、さらに、メモリ、すなわち、非一時的なコンピュータ読み取り可能媒体またはメディアの形のコンピュータ読み取り可能記憶を備える。このメモリは、一つまたは複数のメモリ媒体、たとえばハードディスクなどの磁気媒体、SSD、フラッシュメモリまたはEEPROMなどの電子媒体、および/または光ディスク・ドライブなどの光媒体を使用する一つまたは複数のメモリユニットを含んでいてもよい。各当事者103のコンピュータ設備102上のメモリは、処理装置上で動作するように構成された少なくとも1つのクライアント・アプリケーション105のそれぞれのインスタンスを含むソフトウェアを記憶する。本明細書で所与の当事者103に帰されるいずれのアクションも、それぞれのコンピュータ設備102の処理装置上で実行されるソフトウェアを使用して実行されうることが理解されよう。各当事者103のコンピュータ設備102は、少なくとも1つのユーザー端末、たとえばデスクトップまたはラップトップコンピュータ、タブレット、スマートフォン、またはスマートウォッチのようなウェアラブルデバイスを含む。所与の当事者103のコンピュータ設備102は、ユーザー端末を介してアクセスされるクラウドコンピューティング資源のような、一つまたは複数の他のネットワーク化された資源を含んでいてもよい。
【0047】
クライアント・アプリケーションまたはソフトウェア105は、最初に、好適なコンピュータ読み取り可能な記憶媒体またはメディア上で任意の所与の当事者103のコンピュータ設備102に提供されてもよく、たとえばサーバーからダウンロードされ、あるいはリムーバブルSSD、フラッシュメモリ・キー、リムーバブルEEPROM、リムーバブル磁気ディスク・ドライブ、磁気フロッピー・ディスクまたはテープ、光ディスク、たとえばCDまたはDVD ROM、またはリムーバブル光学ドライブなどのリムーバブル記憶装置上で提供されてもよい。
【0048】
クライアント・アプリケーション105は、少なくとも「ウォレット」機能を備える。これには主に2つの機能をもつ。これらのうちの一方は、それぞれのユーザー当事者103が、ノード104のネットワーク全体にわたって伝搬され、それによってブロックチェーン150に含まれるトランザクション152を作成し、署名し、送信することを可能にすることである。他方は、それぞれの当事者に、現在所有しているデジタル資産の量を報告することである。出力ベースのシステムでは、この第2の機能は、ブロックチェーン150全体に散在する、当該当事者に属するさまざまな152トランザクションの出力において定義される量を照合することを含む。
【0049】
各コンピュータ設備102上のクライアント・アプリケーション105のインスタンスは、P2Pネットワーク106の転送ノード104Fの少なくとも1つに動作上結合される。これは、クライアント105のウォレット機能が、トランザクション152をネットワーク106に送信することを可能にする。クライアント105は、それぞれの当事者103が受領者である任意のトランザクションについてブロックチェーン150に照会するために(あるいは実は、諸実施形態においてブロックチェーン150は、部分的にはそれが公に見えることを通じてトランザクションの信用を提供する公共施設であるため、ブロックチェーン150内の他の当事者のトランザクションを検査するために)、記憶ノード104のうちの1つ、一部、または全部にコンタクトすることもできる。各コンピュータ設備102上のウォレット機能は、トランザクション・プロトコルに従ってトランザクション152を定式化し、送信するように構成される。各ノード104は、ノード・プロトコルに従ってトランザクション152を有効確認し、転送ノード104Fの場合は、ネットワーク106全体に伝播させるためにトランザクション152を転送するように構成されたソフトウェアを実行する。トランザクション・プロトコルとノード・プロトコルは互いに対応し、所与のトランザクション・プロトコルは所与のノード・プロトコルとともに、所与のトランザクション・モデルを実装する。同じトランザクション・プロトコルが、ブロックチェーン150内のすべてのトランザクション152について使用される(ただし、トランザクション・プロトコルは、その中でトランザクションの異なるサブタイプを許容してもよい)。同じノード・プロトコルが、ネットワーク106内のすべてのノード104によって使用される(ただし、トランザクションの異なるサブタイプを、そのサブタイプについて定義された規則に従って異なる仕方で扱ってもよく、また、異なるノードは異なる役割を担い、よって、プロトコルの異なる対応する側面を実装してもよい)。
【0050】
上述したように、ブロックチェーン150はブロック151のチェーンを含み、各ブロック151は、上述したように、作業証明プロセスによって作成された一つまたは複数のトランザクション152の集合を含む。各ブロック151は、また、ブロック151への逐次的順序を規定するように、チェーン内の先に生成されたブロック151を遡ってポイントするブロック・ポインタ155を含む。ブロックチェーン150はまた、作業証明プロセスによって新しいブロックに含まれることを待つ有効なトランザクション154のプールを含む。各トランザクション152は、トランザクションの諸シーケンスに対する順序を定義するよう、前のトランザクションを遡ってポイントするポインタを含む(トランザクション152の諸シーケンスは、分岐することが許容される)。ブロック151のチェーンは、チェーン内の最初のブロックであった生成ブロック(Gb)153まで遡る。チェーン150内の早期の一つまたは複数のオリジナル・トランザクション152は、先行トランザクションではなく創生ブロック(genesis block)153をポイントした。
【0051】
所与の当事者103、たとえばアリスが、ブロックチェーン150に含められるよう、新しいトランザクション152jを送信することを望む場合、アリスは、関連するトランザクション・プロトコルに従って(アリスのクライアント・アプリケーション105においてウォレット機能を使用して)新しいトランザクションを定式化する。アリスは次いで、トランザクション152を、クライアント・アプリケーション105から、自分が接続されている一つまたは複数の転送ノード104Fの1つに送信する。たとえば、これは、アリスのコンピュータ102に最も近いか、または最も良好に接続されている転送ノード104Fでありうる。任意の所与のノード104は、新しいトランザクション152jを受信すると、それをノード・プロトコルおよびそのそれぞれの役割に従って処理する。これは、まず、新たに受信されたトランザクション152jが「有効」であるためのある種の条件を満たすかどうかをチェックすることを含む。その例については、手短に、より詳細に論じる。いくつかのトランザクション・プロトコルでは、有効確認のための条件は、トランザクション152に含まれるスクリプトによってトランザクションごとに構成設定可能でありうる。あるいはまた、条件は単に、ノード・プロトコルの組み込み特徴であってもよく、あるいはスクリプトとノード・プロトコルの組み合わせによって定義されてもよい。
【0052】
新たに受信されたトランザクション152jが、有効であるとみなされるテストを通過するという条件で(すなわち、「有効確認される」という条件で)、トランザクション152jを受信する任意の記憶ノード104Sは、そのノード104Sにおいて維持されているブロックチェーン150のコピー内のプール154に、新たに有効確認されたトランザクション152を追加する。さらに、トランザクション152jを受信する任意の転送ノード104Fは、有効確認されたトランザクション152をP2Pネットワーク106内の一つまたは複数の他のノード104にさらに伝搬させる。各転送ノード104Fは同じプロトコルを適用するので、トランザクション152jが有効であると想定すると、これは、そのトランザクションがまもなくP2Pネットワーク106全体に伝搬させられることを意味する。
【0053】
ひとたび一つまたは複数の記憶ノード104で維持されるブロックチェーン150のコピー内のプール154に受け入れられたら、マイナー・ノード104Mは、新しいトランザクション152を含むプール154の最新バージョンに関する作業証明パズルを解くために競争を開始する(他のマイナー104Mが依然としてプール154の古いビューに基づいてパズルを解こうとしていることがありうるが、誰であれ先に到達した者が、どこで次の新しいブロック151が終了し、新しいプール154が始まるかを定義し、最終的には、誰かが、アリスのトランザクション152jを含むプール154の一部についてのパズルを解くであろう)。ひとたび新しいトランザクション152jを含むプール154について作業証明が行われると、それは、変更不能な形で、ブロックチェーン150内のブロック151のうちの1つのブロックの一部となる。各トランザクション152は、以前のトランザクションへのポインタを含むので、トランザクションの順序も、変更不能な形で記録される。
【0054】
図2は、例示的なトランザクション・プロトコルを示す。これは、UTXOベースのプロトコルの例である。トランザクション152(「Tx」と略す)は、ブロックチェーン150の基本的なデータ構造である(各ブロック151は一つまたは複数のトランザクション152を含む)。以下は、出力ベースまたは「UTXO」ベースのプロトコルを参照して説明される。しかしながら、これは、すべての可能な実施形態に対して限定するものではない。
【0055】
UTXOベースのモデルでは、各トランザクション(「Tx」)152は、一つまたは複数の入力202および一つまたは複数の出力203を含むデータ構造を含む。各出力203は、未使用のトランザクション出力(UTXO)を含んでいてもよく、これは、別の新しいトランザクションの入力202のためのソースとして使用できる(UTXOがまだ償還されていない場合)。UTXOは、デジタル資産(価値のストア)の量を指定する。UTXOは、他の情報の中でも、それが由来するところのトランザクションのトランザクションIDをも含んでいてもよい。トランザクション・データ構造はまた、入力フィールド(単数または複数)202および出力フィールド(単数または複数)203のサイズのインジケータを含んでいてもよいヘッダ201を含んでいてもよい。ヘッダ201はまた、トランザクションのIDを含んでいてもよい。諸実施形態において、トランザクションIDは、トランザクション・データ(トランザクションID自体を除く)のハッシュであり、マイナー104Mに提出された生のトランザクション152のヘッダ201に格納される。
【0056】
アリス103aは、問題のデジタル資産の量をボブ103bに移転するトランザクション152jを作成したいとする。図2において、アリスの新しいトランザクション152jは、「Tx1」とラベル付けされている。これは、シーケンスにおいて先行するトランザクション152iの出力203においてアリスにロックされているデジタル資産のうちのある量を取り、その少なくとも一部をボブに移転する。先行するトランザクション152iは、図2において「Tx0」とラベル付けされている。Tx0およびTx1は、単に任意のラベルである。これらは、必ずしも、Tx0がブロックチェーン151における最初のトランザクションであること、または、Tx1がプール154におけるすぐ次のトランザクションであることを意味しない。Tx1は、アリスにロックされた未使用出力203を依然として有する、任意の先行する(すなわち先立つ)トランザクションを遡ってポイントすることができる。
【0057】
先行するトランザクションTx0は、アリスがその新しいトランザクションTx1を作成する時点において、または少なくともアリスがそれをネットワーク106に送信する時点までに、すでに検証され、ブロックチェーン150に含められてもよい。それは、その時点ですでにブロック151のうちの1つに含まれてもよく、あるいは、プール154内でまだ待機していてもよく、その場合、まもなく新しいブロック151に含まれることになる。あるいはまた、Tx0およびTx1が一緒に生成されてネットワーク102に送信されることができ、あるいはさらには、ノード・プロトコルが「オーファン」トランザクションをバッファリングすることを許容する場合にはTx0がTx1の後に送信されることもできる。本明細書においてトランザクションのシーケンスの文脈で使用される「先行」および「後続」という用語は、トランザクション中に指定されたトランザクション・ポインタ(どのトランザクションがどの他のトランザクションをポイントするかなど)によって定義されるシーケンスにおけるトランザクションの順序のことをいう。それらの用語は、「先行者」および「後継者」または「先立つ」および「子孫」、「親」および「子」などに等しく置き換えることができる。これは、必ずしもそれらが作成される、ネットワーク106に送られる、または任意の所与のノード104に到達する順序を意味するわけではない。にもかかわらず、先行トランザクション(先立つトランザクションまたは「親」)をポイントする後続トランザクション(子孫トランザクションまたは「子」)は、親トランザクションが有効確認されない限り、有効確認されない。親より先にノード104に到着する子は、オーファンとみなされる。オーファンは、ノード・プロトコルおよび/またはマイナー挙動に依存して、破棄されてもよく、あるいは親を待つために、ある時間にわたってバッファリングされてもよい。
【0058】
先行するトランザクションTx0の一つまたは複数の出力203のうちの1つは、本明細書でUTXO0とラベル付けされる特定のUTXOを含む。各UTXOは、UTXOによって表されるデジタル資産の量を指定する値と、ロック・スクリプトとを含む。ロック・スクリプトは、後続のトランザクションが有効確認されるため、よってUTXOが正常に償還されるために、後続のトランザクションの入力202においてロック解除スクリプトによって満たされなければならない条件を定義する。典型的には、ロック・スクリプトは、前記量を特定の当事者(それが含まれているトランザクションの受益者)にロックする。すなわち、ロック・スクリプトは、ロック解除条件を定義し、典型的には、後続のトランザクションの入力におけるロック解除スクリプトが、先行するトランザクションがロックされている当事者の暗号署名を含むという条件を含む。
【0059】
ロック・スクリプト(別名scriptPubKey)は、ノード・プロトコルによって認識されるドメイン固有の言語で書かれたコードである。そのような言語の特定の例は、「Script」(大文字のS)と呼ばれる。ロック・スクリプトは、トランザクション出力203を使用するためにどんな情報が必要とされるか、たとえば、アリスの署名を要求することを指定する。トランザクションの出力には、ロック解除スクリプトが現れる。ロック解除スクリプト(別名scriptSig)は、ロック・スクリプト基準を満たすために必要とされる情報を提供する、ドメイン固有の言語で書かれたコードである。たとえば、ボブの署名を含んでいてもよい。ロック解除スクリプトは、トランザクションの入力202に現れる。
【0060】
図示した例では、Tx0の出力203におけるUTXO0は、ロック・スクリプト[Checksig PA]を含み、これは、UTXO0が償還されるために(厳密には、UTXO0を償還しようとする後続のトランザクションが有効であるために)、アリスの署名Sig PAを要求する。[Checksig PA]は、アリスの公開鍵・秘密鍵のペアからの公開鍵PAを含む。Tx1の入力202は、Tx1を指す(たとえば、諸実施形態ではトランザクションTx0全体のハッシュであるそのトランザクションID、TxID0によって)ポインタを含む。Tx1の入力202は、Tx0の任意の他の可能な出力の中でそれを識別するために、Tx0内のUTXO0を識別するインデックスを含む。Tx1の入力202は、さらに、鍵ペアからのアリスの秘密鍵をデータの所定の部分(暗号学において時に「メッセージ」と呼ばれる)に適用することによって作成された、アリスの暗号署名を含むロック解除スクリプト<Sig PA>を含む。有効な署名を提供するためにアリスによって署名される必要があるデータ(または「メッセージ」)は、ロック・スクリプトによって、またはノード・プロトコルによって、またはこれらの組み合わせによって定義されうる。
【0061】
新しいトランザクションTx1がノード104に到着すると、ノードはノード・プロトコルを適用する。これは、ロック解除スクリプトがロック・スクリプトにおいて定義されている条件を満たしているかどうかをチェックするために、ロック・スクリプトとロック解除スクリプトを一緒に実行する(この条件は一つまたは複数の基準を含みうる)。諸実施形態において、これは、2つのスクリプトを連結することを含む:
<Sig PA><PA>||[Checksig PA]
ここで、「||」は連結を表し、「<…>」は、データをスタック上に置くことを意味し、「[…]」はロック解除スクリプト(この例ではスタックベースの言語)に含まれる関数である。同様に、スクリプトは、スクリプトを連結するのではなく、共通のスタックを用いて順次実行されてもよい。いずれにせよ、一緒に実行されたとき、それらのスクリプトは、Tx0の出力におけるロック・スクリプトに含まれるアリスの公開鍵PAを使用して、Tx1の入力におけるロック・スクリプトが、データの期待される部分に署名するアリスの署名を含むことを認証する。この認証を実行するためには、データの期待される部分自体(「メッセージ」)もTx0に含める必要がある。諸実施形態において、署名されたデータは、Tx0の全体を含む(よって、データの署名された部分がすでに内在的に存在するので、データの署名された部分を平文で指定する別個の要素が含まれる必要はない)。
【0062】
公開‐秘密暗号による認証の詳細は、当業者にはおなじみであろう。基本的には、アリスが自分の秘密鍵を用いてメッセージを暗号化することによってメッセージに署名した場合、アリスの公開鍵と平文でのそのメッセージ(暗号化されていないメッセージ)を与えられると、ノード104のような別のエンティティは、そのメッセージの暗号化されたバージョンがアリスによって署名されたものであるはずであると認証することができる。署名することは、典型的には、メッセージをハッシュし、ハッシュに署名し、それを署名としてメッセージの平文バージョンにタグ付けし、それにより、公開鍵の任意の保持者が署名を認証することを可能にする。
【0063】
Tx1のロック解除スクリプトが、Tx0のロック・スクリプトにおいて指定された一つまたは複数の条件を満たす場合(示した例では、アリスの署名がTx1において提供され、認証された場合)、ノード104は、Tx1が有効であるとみなす。それが記憶ノード104Sである場合、このことは、それが作業証明を待つトランザクションのプール154にそれを追加することを意味する。それが転送ノード104Fである場合、それは、ネットワーク全体に伝搬されるよう、トランザクションTx1をネットワーク106内の一つまたは複数の他のノード104に転送する。ひとたびTx1が有効確認され、ブロックチェーン150に含められると、これは、Tx0からのUTXO0を使用済みとして定義する。Tx1は、未使用のトランザクション出力203を使用する場合にのみ有効でありうることに留意されたい。別のトランザクション152によってすでに使用された出力を使用しようとする場合、たとえ他のすべての条件が満たされていても、Tx1は無効となる。よって、ノード104は、先行するトランザクションTx0における参照されたUTXOがすでに使用されているかどうか(すでに別の有効なトランザクションへの有効な入力を形成しているかどうか)もチェックする必要がある。これが、ブロックチェーン150がトランザクション152に関する定義された順序を課すことが重要である理由の1つである。実際上は、所与のノード104は、トランザクション152が使用されたUTXO 203をマークする別個のデータベースを維持してもよいが、最終的には、UTXOが使用されたかどうかを定義するのは、ブロックチェーン150内の別の有効なトランザクションへの有効な入力をすでに形成しているかどうかである。
【0064】
UTXOベースのトランザクション・モデルでは、所定のUTXOが全体として使用される必要があることに注意されたい。使用されるUTXOにおいて定義されている量のうち、別の量が使用される一方で一部を「残しておく」ことはできない。ただし、UTXOからの前記量は、次のトランザクションの複数の出力のあいだで分割できる。たとえば、Tx0におけるUTXO0において定義された量は、Tx1における複数のUTXOの間で分割できる。よって、アリスがボブにUTXO0で定義された量のすべてを与えることを望まない場合、残りを使って、Tx1の第2の出力において自分自身におつりを与えたり、あるいは別の当事者に支払ったりすることができる。
【0065】
実際上は、アリスは通例、勝ったマイナーのための料金を含める必要もある。なぜなら、今日では、生成トランザクションの報酬だけでは、典型的には、採掘を動機づけるには十分ではないからである。アリスがマイナーのための手数料を含めない場合、Tx0は諸マイナー・ノード104Mによって拒否される可能性が高く、よって、技術的には有効であるが、それはまだ伝播され、ブロックチェーン150に含められることはない(マイナー・プロトコルは、マイナー104Mに望まない場合には、トランザクション152を受け入れるようマイナー104Mに強制しない)。いくつかのプロトコルでは、採掘料金は、独自の別個の出力203を必要としない(すなわち、別個のUTXOを必要としない)。その代わりに、所与のトランザクション152の入力(単数または複数)202によってポイントされる総量と出力(単数または複数)203において指定される総量との間の任意の差は、勝ったマイナー104に自動的に与えられる。たとえば、UTXO0へのポインタがTx1への唯一の入力であり、Tx1は1つの出力UTXO1しかもたないとする。UTXO0において指定されたデジタル資産の量がUTXO1において指定された量より多い場合、その差は自動的に勝ったマイナー104Mのものとなる。しかしながら、代替的または追加的に、トランザクション152のUTXO 203のうちの独自のものにおいてマイナー手数料が明示的に指定できることは必ずしも除外されない。
【0066】
また、所与のトランザクション152のすべての出力203において指定された総量が、そのすべての入力202によってポイントされた総量よりも大きい場合、これは、ほとんどのトランザクション・モデルにおいて無効性の別の根拠であることに留意されたい。したがって、そのようなトランザクションは、伝搬されたり、ブロック151中にマイニングされたりすることはない。
【0067】
アリスおよびボブのデジタル資産は、ブロックチェーン150内の任意のところで任意のトランザクション152において、両者にロックされた未使用UTXOからなる。よって、典型的には、所与の当事者103の資産は、ブロックチェーン150を通じて、さまざまなトランザクション152のUTXO全体に分散される。ブロックチェーン150内のどこにも、所与の当事者103の総残高を定義する1つの数は記憶されていない。それぞれの当事者にロックされ、別の前進(onward)トランザクションにまだ使用されていないすべてのさまざまなUTXOの値を一緒に照合することは、クライアント・アプリケーション105におけるウォレット機能の役割である。これは、記憶ノード104Sのいずれか、たとえばそれぞれの当事者のコンピュータ設備102に最も近いか、または最も良好に接続されている記憶ノード104Sに記憶されているブロックチェーン150のコピーを問い合わせることによってできる。
【0068】
スクリプト・コードは、概略的に表現されることが多い(すなわち、正確な言語ではない)ことに注意されたい。たとえば、[Checksig PA]と書いて、[Checksig PA]=OP_DUP OP_HASH160<Pa>OP_EQUALVERIFY OP_CHECKSIGを意味することができる。「OP_....」は、Script言語の特定のオペコードを指す。OP_CHECKSIG(「Checksig」とも呼ばれる)は、2つの入力(署名および公開鍵)を取り、楕円曲線デジタル署名アルゴリズム(ECDSA)を使用して署名の有効性を検証するScriptオペコードである。ランタイムでは、署名('sig')の発生はすべてスクリプトから除去されるが、ハッシュ・パズルなどの追加要件が、'sig'入力によって検証されるトランザクションに残る。別の例として、OP_RETURNは、トランザクション内にメタデータを格納し、それによりブロックチェーン150において変更不能な形でメタデータを記録することができるトランザクションの使用不能な(unspendable)出力を生成するためのScript言語のオペコードである。たとえば、メタデータは、ブロックチェーンに格納することが望まれる文書を含むことができる。
【0069】
署名PAは、デジタル署名である。諸実施形態において、これは楕円曲線secp256k1を使用するECDSAに基づく。デジタル署名は、特定のデータに署名する。諸実施形態において、所与のトランザクションについて、署名は、トランザクション入力の一部、およびトランザクション出力の全部または一部に署名する。署名される出力の特定の部分はSIGHASHフラグに依存する。SIGHASHフラグは、署名の末尾に含まれる4バイトのコードであり、どの出力が署名されるか(よって、署名の時点において固定されるか)を選択する。
【0070】
ロック・スクリプトは、それぞれのトランザクションがロックされる当事者の公開鍵を含んでいるという事実を指して、「scriptPubKey」と呼ばれることがある。ロック解除スクリプトは、対応する署名を供給するという事実を指して「scriptSig」と呼ばれることがある。しかしながら、より一般には、UTXOが償還されるための条件が署名を認証することを含むことは、ブロックチェーン150のすべてのアプリケーションにおいて必須ではない。より一般的には、スクリプト言語を使用して、一つまたは複数の条件を定義することができる。よって、より一般的な用語である「ロック・スクリプト」および「ロック解除スクリプト」が好まれることがある。
【0071】
図3は、ブロックチェーン150を実装するためのシステム100を示す。システム100は、追加の機能が含まれることを除いて、図1に関連して説明したものと実質的に同じである。ネットワークの一つまたは複数のノード104は、ブロックチェーン150のブロック151に記録されるべきターゲット・トランザクション152の二次トランザクション識別子を生成するためのソフトウェア301を含んでいてもよい。好ましくは、マイナー104Mのうちの1人、数人または全員が前記ソフトウェア(「マイナー・ソフトウェア」と呼ばれる)を含むことができるが、一または複数の当事者(たとえば、アリスおよび/またはボブ)のコンピュータ設備が前記ソフトウェアを含みうることは除外されない。
【0072】
図3は、一つまたは複数のモジュールを含みうるマイナー・ソフトウェアのブロック図をも示している。識別モジュール302は、ターゲット・トランザクションを取得し(たとえば、ターゲット・トランザクションはネットワークの転送ノード104Fから受信されてもよい)、ターゲット・トランザクションのデータ・フィールドの集合を識別するように構成される。集合内の各データ・フィールドは、ターゲット・トランザクションのデータを含む。たとえば、一つまたは複数のデータ・フィールドは、支払い関連データを含んでいてもよい。データ・フィールドの集合は、一緒になって、完全なトランザクションを形成する。トランザクションがメディアコンテンツを含む場合、一つまたは複数のデータ・フィールドがそのメディアコンテンツの一部または全部を含んでいてもよい。木生成モジュール303は、データ・フィールドの集合を使用してハッシュ木を生成するように構成される。データ・フィールドの集合は、ハッシュ木(たとえば、マークル木)を生成するアルゴリズムに入力される。ハッシュ木はルート・ハッシュを含み、ルート・ハッシュは以下の議論では、ターゲット・トランザクションの二次トランザクション識別子のはたらきをする。記録モジュール304は、ブロック152の第1のトランザクション・フィールドにおいて二次トランザクション識別子(ルート・ハッシュ)を記録するように構成される。次いで、ブロックはブロックチェーンに記録される。
【0073】
二次トランザクション識別子は、照会ユーザーが、完全なトランザクションを取得したりアクセスしたりすることなく、ターゲット・トランザクション内のデータ・フィールド(ここでは候補データ・フィールドと呼ばれる)の存在をチェックすることを可能にする。たとえば、ユーザー(たとえばボブ)のクライアント・アプリケーション105は、完全なトランザクションを得るのに十分な能力を有しないことがありうる。たとえば、ボブは、完全なトランザクションを得ることなく、ターゲット・トランザクションがメディアコンテンツ(たとえば、ムービークリップ)を含むかどうかを最初にチェックすることを望むことがありうる。別の例として、マイナーは、トランザクションの他の部分を記憶する必要なく、トランザクションの支払部分をチェックすることを望むことがありうる。さらなる例として、ノード(たとえば、マイナーまたは記憶ノード)は、トランザクションを枝刈りする(prune)ことを望むことがありうる。ここで、枝刈りとは、トランザクションの少なくとも一部を、もとのデータのハッシュで置き換えることを意味する。しかしながら、ノードは依然として、トランザクションが、今や「枝刈りされた」(すなわち、ハッシュで置き換えられた)候補データ・フィールド(たとえば、トランザクションの使用可能な出力)を含んでいたことを、照会ユーザーに対して証明する必要があることがありうる。
【0074】
ターゲット・トランザクションが候補データ・フィールドを含むかどうかをチェックするために、照会ユーザー(たとえば、ボブ103b)は、候補データ・フィールド(またはそのハッシュ)、ターゲット・トランザクションの二次トランザクション識別子、および認証経路(またはハッシュ経路)を取得する。認証経路は、ハッシュ木から取られたハッシュの集合を含む。照会ユーザーは、候補データ・フィールドのハッシュと認証経路のハッシュを使用して、ハッシュ木をたどり、候補二次トランザクション識別子を取得する。候補二次トランザクション識別子が取得された二次トランザクション識別子と一致する場合、トランザクションは候補データ・フィールドを含み、その逆も同様である。換言すれば、照会ユーザーは、候補データ・フィールドが、二次トランザクション識別子によって表されるトランザクションの一部を形成しているかどうかをチェックすることができる。ハッシュ木をたどることは、完全なトランザクションを必要としないことに注意されたい。候補データ・フィールドのハッシュと、その後に生成されるハッシュ値の両方のハッシュ・パートナーのみが必要とされる。このプロセスは、図5を参照して以下でより詳細に説明される。
【0075】
トランザクション
高レベルでは、トランザクションTxは、入力および出力を含みうるメッセージであり、デジタル資産の所有権を、第1の集合のアドレスから第2の集合のアドレス(第1の集合内の一つまたは複数のアドレスを含んでいてもいなくてもよい)に移転する。
【0076】
ある特定のブロックチェーン・プロトコルは、中でもversion、txin_count、txin、txout_count、txoutおよびlocktimeのうちの一つまたは複数を含むフィールドをもつトランザクションを使用する。他のプロトコルは、これらのフィールドの一部を含む、またはどれも含まないトランザクションを使用してもよい。本明細書に開示されている技術は、任意のブロックチェーン・プロトコルに適用される。以下で論じられるフィールドは、単に例として使用される。
【0077】
versionフィールドは、トランザクションの作成者が従うプロトコル規則の集合を示す整数(たとえば、4バイト整数)である。txin_countフィールドは、トランザクションにおける入力の数を指定する正の整数(たとえば、1バイトから9バイトまでの間)である。
【0078】
txinフィールドはトランザクション入力の配列である。各入力は、以下のサブフィールドのうちの一つまたは複数を含む:outpoint―使用されるUTXOについての対(TxIDn)を示す構造であって下記を含む;txid_prev―使用されるUTXOについてのトランザクション識別子TxID(たとえば、32バイトの文字列);vout―使用されるUTXOについての出力インデックス(たとえば、4バイトの整数)n;scriptSigLen―ロック解除スクリプトの整数長(バイト単位)(10,000バイトまで);scriptSig―ロック解除スクリプトの構造(これは、多くの別個の要素を含むことができる);sequence―トランザクションの現在のバージョンを示す整数(たとえば、4バイトの整数)。
【0079】
txout_countフィールドは、トランザクションにおける出力の数を指定する1バイトから9バイトまでの正の整数である。txoutフィールドはトランザクション出力の配列である。各出力は、以下のサブフィールドのうちの一つまたは複数を含んでいてもよい:value―出力の値を示す整数(たとえば、8バイトの整数);scriptPubKeyLen―ロック・スクリプトの整数長(バイト単位)(10,000バイトまで);scriptPubKey―ロック・スクリプトの構造(これは、多くの別個の要素を含むことができる);locktime―トランザクションがブロックに含められてもよい最も早い時刻を示す整数(たとえば、4バイトの整数)。
【0080】
この例示的なプロトコルでは、かなりのサイズのデータを含みうるトランザクションのフィールドは、スクリプト・フィールド、すなわち、scriptSigおよびscriptPubKeyだけであることが理解されるべきである。よって、これらの2つのフィールドは、大きなデータについての存在計算の軽量証明の問題に対処する際に考慮することが最も重要である。
【0081】
1つの入力と1つの出力を含むトランザクションの例が下記に示される。記法PおよびH(P)は、それぞれ公開鍵とRIPEMD-160ハッシュを指す。
【表1】
【0082】
照会ユーザーは、トランザクション(またはブロック内のすべてのトランザクション)が同じバージョンまたはプロトコルを使用して行われたかどうかを確認するために、トランザクションのバージョンをチェックすることを望むことがある。照会ユーザーは、たとえば研究目的のために、ブロックチェーンの解析を実行するためにtxin_countをチェックすることを望むことがある。照会ユーザー(たとえば、マイナー)は、トランザクションの出力(単数または複数)をチェックして、その出力を有効性についてチェックする(たとえば、デジタル資産が使用可能であることをチェックする)ことを望むだけであることがある。
【0083】
トランザクションは、トランザクション・データのハッシュまたはダブルハッシュを使用して、一意的に識別されうる。たとえば、トランザクションは、そのSHA-256ダブルハッシュによって識別されうる。トランザクション識別子TxIDは、たとえば、所与のトランザクションTxの関数として
TxID:=H2(Tx)
と書かれてもよい。ここで、Hはハッシュ関数(たとえば、SHA-256暗号学的ハッシュ関数)である。そのような暗号学的ハッシュ関数の衝突耐性特性は、正しいTxIDを生成するためにはトランザクション・メッセージm=Txの全体が必要とされることを意味する。言い換えると、代わりのメッセージTx'がハッシュされた場合、Tx'≠Txである限り、代わりの識別子TxID'が生成される。
【0084】
生成トランザクション
ブロックの最初のトランザクションは、マイナーが採掘インセンティブを回収できるようにするために用いられるため、一般的なトランザクションについて上述した構造とは異なる。これは「生成」トランザクションとしても知られる。新しいブロックが採掘されるたびに新しいデジタル資産が生成されるからである。これは、ブロック報酬として知られる。生成トランザクションは、マイナーは、ブロック内の他のトランザクションによって決定されたトランザクション手数料の総額を請求できるようにもする。生成トランザクションは、txin-countおよびtxinフィールドにおいて一般的な形と異なるだけである。生成トランザクションは単一の入力を含むので、txin_countフィールドは、整数「0 1」を含む。txinフィールド自体は、以下のように、そのサブフィールドのいくつかにおいて、非生成トランザクションと異なる。この場合、使用されるUTXOがないので、outpointのサブフィールドは以下のとおりである:txid_prev 前のoutpointがないことを示すヌル値(すべてゼロ、たとえば32バイト分のゼロ);vout―前のoutpointがないことを示す値(たとえば、0xffffffff)。scriptSigLenフィールドは、ロック解除スクリプトの整数長(バイト単位)で、100バイトまで。「ロック解除」すべきUTXOがないため、scriptSigフィールドは、heightフィールド(このトランザクションを含むブロックのブロック高さ(たとえば4バイト))とgeneration_script(最大96バイトまでの任意のデータ)の2つのフィールドで形成される。最終フィールドはsequenceフィールド―トランザクションの現在のバージョンを示す整数(たとえば4バイト)である。
【0085】
生成トランザクションのgeneration_scriptフィールドは、任意のデータをトランザクションに含めるために、ユーザー(たとえば、マイナー)によって使用されることができる。
【0086】
ブロック
ブロックは、データ構造であり、トランザクションの集合と、任意的に、どのようにしてブロックがブロックチェーンにアペンドされる(マイニングされる)かに関連する追加フィールドとを含む。特定のブロックチェーン・プロトコルのブロックのフィールドは、ブロック・ヘッダ、txn_count、およびtxnsとして要約されうる。ブロック・ヘッダは、ブロックがいつ、どのように採掘されたものであり、何を含むかについての情報を含む構造である。これは、以下の6つのサブフィールドのうちの一つまたは複数を含む:version―ブロック有効確認のために使用されるプロトコル規則の集合を示す整数(たとえば4バイトの整数);prev_block―前のブロック・ヘッダのダブルハッシュ(たとえば32バイトのSHA-256);Merkle_root―トランザクションのマークル木から導出されたダブルハッシュ(たとえば32バイトのSHA-256);timestamp―マイナーがヘッダを生成したUnix時刻をエンコードする整数(たとえば4バイトの整数);nbits―ブロックがマイニングされるために要求される目標困難さをエンコードする整数(たとえば4バイトの整数);nonce―要求される困難さのブロック・ヘッダ・ハッシュを達成するために選択された整数(たとえば4バイトの整数)。txn_countは、ブロック内のトランザクションの数を示す可変サイズの整数である。txnsフィールドは、ブロックに含まれるトランザクションの全リストのためのトランザクション・データを含む構造である。このリストにおける最初のトランザクションは常に生成トランザクションであり、残りは上記の一般的なトランザクション構造に従う。
【0087】
マークル木
マークル木は二分ハッシュ木としても知られ、ハッシュ木の特定の形式である。ツリー内の各ノード(円で示される)は、インデックス対(i,j)が与えられ、N(i,j)として表される。インデックスi,jは、ツリー内の特定の位置に関連する数値ラベルである。マークル木の特徴は、各ノードの構築が次式によって支配されるということである:
【数1】
ここで、k=(i+j-1)/2であり、Hは暗号学的ハッシュ関数である。
【0088】
これらの式に従って構築された二分ハッシュ木400が図4に示されている。図4は、i=jの場合が、単にデータDiの対応するi番目のブロックのハッシュであるリーフ・ノード401に対応することを示している。i≠jの場合は、特定のノードまたはルートに到達するまでツリー内の子ノードを再帰的にハッシュして連結することによって生成される内部ノード402またはルート・ノード403に対応する。ハッシュ木のリーフ・ノードは、本明細書ではリーフ・ハッシュとも呼ばれる。同様に、内部ノードとルート・ノードは内部ハッシュまたはルート・ハッシュとも呼ばれる。
【0089】
マークル木の構築は、暗号学的ハッシュ関数の使用を要する。一般に、ハッシュ関数は、以下の特性をもつ場合、暗号的に安全であるとみなされる:
1)原像耐性―h=H(m)が与えられたときに、mを見出すのは計算上困難である;
2)第2原像耐性―h=H(m)およびmが与えられたときに、H(m')=hとなるようなm'を見出すのは計算上困難である;
3)耐衝突性―H(m)=H(m')となるようなメッセージの対mとm'を見出すのは計算上困難である。
【0090】
トランザクションの一次トランザクション識別子TxIDは、そのようなハッシュ関数を使用して生成され、よって、識別子はハッシュ関数のダイジェストの特性を継承する。ハッシュ木のルートは、ハッシュ木のルートの一意性が、根底にある暗号学的ハッシュ関数の一意性に還元できるという点で、TxIDと非常によく似た特性をもつ。これは、両方の場合について同じハッシュ関数が使われる場合、データをハッシュすることによって生成される識別子と同じくらい一意的な、データについての識別子として、ルートが使用できるので、有益である。
【0091】
ほとんどのアプリケーションにおけるハッシュ木の主な機能は、あるデータ・ブロックDi 404がN個のデータ・ブロックD∈{D1,…,DN}のリストまたは集合の要素であることの証明を容易にすることである。ハッシュ木ルートと候補データ・ブロックDiが与えられるとき、これは集合内の前記ブロックの「存在証明」として扱うことができる。そのような証明のための機構は、ハッシュ木証明(または、マークル木についてのマークル証明)として知られており、所与のデータ・ブロックDiとルートRについてハッシュ経路または認証経路(または、マークル経路)として知られているハッシュの集合を得ることを含む。データ・ブロックについての認証経路は、繰り返されるハッシュと連結によってルートRを再構築するために必要なハッシュの最小リストである。すべてのブロックD1,…,DNが証明者に知られていれば、存在証明が実行できる。しかしながら、これは認証経路自体よりもはるかに大きな格納オーバーヘッドを必要とし、また、データセット全体が証明者にとって利用可能であることを必要とする。
【0092】
ハッシュ木は、データ・フィールドDiの存在だけでなく、それがデータセットDの要素であることも証明する。さらに、トランザクションがブロックチェーン上にある場合、ハッシュ木はデータ・フィールドDiがブロックチェーン上に記録されたトランザクションの一部であることを証明する。図5は、マークル経路を使用して、ルートRによって表されるツリー内における、データ・ブロックD1のマークル存在証明を示している。マークル・ルートRが与えられた場合、データ・ブロックD1がRによって表される集合D∈{D1,…,DN}に属することが、以下のようにしてマークル証明を実行することによって証明できる。
1)信頼されるソースからマークル・ルートを取得する。
2)ソースからマークル経路Γを取得する。この場合、Γはハッシュの集合:
Γ={N(2,2),N(3,4),N(5,8)}
である。
3)以下のようにしてD1およびΓを使ってマークル証明を計算する:
a.データ・ブロックをハッシュ(または、実装に依存してダブルハッシュ)して:
N(1,1)=H(D1)
を得る。
b.N(2,2)と連結し、ハッシュして:N(1,2)=H(N(1,1)||N(2,2))を得る。
c.N(3,4)と連結し、ハッシュして:N(1,4)=H(N(1,2)||N(3,4))を得る。
d.N(5,8)と連結し、ハッシュして、ルート:N(1,8)=H(N(1,4)||N(5,8))を得て、
R'=N(1,8)
e.計算されたルートを(1)で得られたルートを比較する:
I.R'=Rであれば、ツリー、したがってデータセットDにおけるD1の存在が確証される。
II.R'≠Rであれば、証明は失敗であり、D1はDの要素として確証されない。
【0093】
これは、所与のブロックD1とルートRについてマークル証明を実行することが、最小数の必要なハッシュ値のみを使用することによって、マークル木を「上向きに」効果的にたどることを例証する。これは、マークル木とそのルートによって表されるデータセットの一部として、一部のデータについて存在証明を提供するための効率的な機構である。たとえば、データD1がブロックチェーン・トランザクションに対応し、ルートRがブロック・ヘッダの一部として公に利用可能である場合、そのトランザクションがそのブロックに含まれていたことが迅速に証明できる。
【0094】
以下、データ・パケットDがルートRによって表される集合Dの一部であることのハッシュ木証明を表すために、タプル(D,R,Γ)が使用される。
【0095】
トランザクション木生成アルゴリズム
上述したように、本開示は、トランザクションが「候補データ・フィールド」と呼ばれる特定のデータ片を含むか否かを判定する際に使用する、トランザクションの二次トランザクション識別子を生成するための方法を提供する。二次トランザクション識別子は、ほとんどのブロックチェーン・プロトコルでは、各トランザクションは、通例、トランザクション全体のハッシュ(またはダブルハッシュ)によって生成される一次トランザクション識別子に関連付けられるため、そう呼ばれる。
【0096】
この方法は、トランザクションを、ハッシュ木、たとえばマークル木のリーフとして使用できるデータ・パケット(またはデータ・フィールド)の集合にフィールドごとに分割することを含む。ここで、ハッシュ木のルートが二次トランザクション識別子に対応する。ここで、分割は、トランザクションのデータ・フィールドを識別することと等価である。言い換えれば、トランザクションは実際には「分割」される必要はない。代わりに、トランザクションの異なる部分が、データ・フィールドの集合の異なるデータ・フィールドとして識別される(たとえば、割り当てられる)のでよい。二次トランザクション識別子は、所与のトランザクションに一意的である(たとえば、所与のトランザクションの一意的な256ビットの数値表現(ハッシュ値))。このハッシュ値は、集合全体(すなわち、完全なトランザクション)を得ることなく、いずれかの個別のフィールドがハッシュ木の有効なリーフであったかどうかを検証するために使用できる。
【0097】
トランザクションTxが与えられた場合、ブロックチェーン中にマイニングされたことを検証する1つの方法は、その対応するTxID(一次トランザクション識別子)がブロックに現れることを検証することである。このチェックは、ハッシュ木証明(たとえば、マークル証明)を実行して、TxIDに対応するトランザクションが、ブロック・ヘッダにおけるハッシュ・ルートによって表されるトランザクション集合の一部であることを検証することによってできる。しかしながら、このチェックは、検証者がまず完全なトランザクション・メッセージm=Txを取得し、TxID=H(Tx)が実際に所与のTxおよび想定されるTxIDについて成り立つことを確認することを要求する。ここで、Hはハッシュ関数である。これは、特にユーザーが軽量クライアントを実装する場合、および/またはメッセージが大きい場合、ブロックチェーンの一部のユーザーにとって問題となることがある。
【0098】
例において、次の定義:MTxID:=F(Tx,TxID)に従う二次トランザクション識別子MTxIDが生成されてもよい。アルゴリズムFは、二つの入力メッセージTxおよびTxIDから二次トランザクション識別子を生成する一方向性関数として機能する。TxIDがトランザクション・メッセージTxの関数としてTxID:=H2(Tx)と書くことができるという事実を考えると、これは、MTxIDが単一のメッセージm=Txの関数として、MTxID:=F(Tx,H2(Tx)):=F(Tx)と書けることを意味する。アルゴリズムFは、ハッシュ木生成器を含む。アルゴリズムは完全なトランザクションを入力Txとして受け取り、ハッシュ・ダイジェストMTxIDを返す。これはトランザクションについての二次識別子として使用できる。二次識別子は256ビットのハッシュ・ダイジェストであってもよい。二次識別子MTxIDは、このスキームにおける一次識別子TxIDに取って代わるものではないことが理解されるべきである。これを補強するために、アルゴリズムFの設計は、たとえば典型的な二重ハッシュ関数H2(Tx)を使用してのTxIDの生成を含む。これは、二次識別子を一次識別子に束縛する。
【0099】
二次トランザクション識別子MTxIDを生成する方法は、以下に要約するように、3つの主要な段階に分けることができる。
入力:Tx
F(Tx):
1)TxID:=H2(Tx)を計算する。
2)TxをN=2k個の順序付けられたデータ・パケットの集合Dに分離する。D:={D1,D2,…,DN}
3)集合Dのパケットをリーフとして用いて二分ハッシュ木Tを生成し、そのルートRを計算する。
出力:MTxID=R
【0100】
この例では、ハッシュ木は二分ハッシュ木(すなわち、マークル木)である。しかしながら、一般的には、任意のn分ハッシュ木が使用されてもよい。nは木の分岐を指す。たとえば、二分ハッシュ木では、2つの子ノードがハッシュされて親ノードを形成し、三分ハッシュ木では、3つの子ノードがハッシュされて親ノードを形成する、などである。
【0101】
段階1:TxIDの計算
生成ユーザーは、ブロックチェーン・ネットワークの一つまたは複数の異なる当事者(またはノード)からトランザクションを受信することができる。たとえば、トランザクションは、ネットワークの1つのノードによって生成ユーザーに直接送信されてもよく、または一つまたは複数の異なるノードを介して送信されてもよい。生成ユーザーは、該トランザクションをブロックチェーンのブロックに記録しようと意図するマイナーであってもよい。
【0102】
この方法は、トランザクションをハッシュすることによって一次トランザクション識別子を生成することを含んでいてもよい。第1段階は、Txに対して実行されるSHA-256ダブルハッシュ計算であり、これは一次トランザクション識別子TxIDを生成する。他のハッシュ関数が使用されてもよく、いくつかの例では、単一のハッシュ計算のみが実行される。通例、Txメッセージ自体はTxIDを明示的に含まない。よって、この一次識別子を明示的にエンコードする仕方でハッシュ木が構築できるように、その後の諸段階は、TxIDのこの明示的な事前計算を必要とする。
【0103】
段階2:Txの順序付けられたデータセットDへの分離
メッセージTxを含むトランザクション・データは、ハッシュ木Tのリーフとして使用できる離散的なパケットに分離される。トランザクションは、既存のフィールドに分割されてもよい。これらのフィールドのほとんどは、単純な数値データを含む。これは一般に非常に小さなサイズであり、典型的には1~32バイトの範囲である。したがって、全体的なトランザクション・サイズの増加に関する核心的な懸念は、それぞれ入力(ロック解除)と出力(ロック)に関連するsigScriptフィールドとscriptPubKeyフィールドに関連する。トランザクションのフィールドは、入力フィールド、出力フィールド、およびその他のフィールドの3つのカテゴリーを使用して区別されうる。いくつかの例では、トランザクションは、これらの3つのカテゴリー、たとえば、すべての入力フィールドを含む1つのデータ・フィールド、すべての出力フィールドを含む1つのデータ・フィールド、および他のフィールドを含む1つのデータ・フィールドに分割される。入力フィールドと出力フィールドは、非スクリプト・フィールドとスクリプト・フィールドとに分離されてもよく、非スクリプト・フィールドは数値データを含み、スクリプト・フィールドはスクリプト・データを含む。
【0104】
次の表は、トランザクションをデータ・フィールドの集合に分割されうる諸方法を示す。
【表2】
この表は、メッセージTxがいくつかの方法でパケットの集合Dを形成するために、その構成要素フィールドに分割できることを示す。
【0105】
いくつかの例では、トランザクションは、トランザクションの入力データ(たとえば、txid_prev)を含む少なくとも1つのデータ・フィールドと;トランザクションの出力データ(たとえば、値)を含む少なくとも1つのデータ・フィールドと;トランザクションの非入力および非出力データ(すなわち、前記その他のデータ、たとえばversion)を含む少なくとも1つのデータ・フィールドとに分割されてもよい。各データ・フィールドは、1つのタイプのみのデータ、たとえば、入力データのみで構成されてもよい。
【0106】
他の例では、トランザクションをより多くのデータ・フィールドに分割されてもよい。たとえば、データ・フィールドの集合は:トランザクションのスクリプト入力データ(たとえば、scriptSig)を含む少なくとも1つのデータ・フィールドと;トランザクションの非スクリプト入力データ(たとえば、vout)を含む少なくとも1つのデータ・フィールドと;トランザクションのトランザクションのスクリプト出力データ(たとえば、scriptPubkey)を含む少なくとも1つのデータ・フィールドと;トランザクションのトランザクションの非スクリプト出力データ(たとえば、scriptPubKeyLen)を含む少なくとも1つのデータ・フィールドとを含んでいてもよい。
【0107】
トランザクションTxは、以下の順序付けられたデータ・パケットの集合に分割されてもよい:
【数2】
【0108】
この方法でデータを分割する選択は、各パケットDiが二分ハッシュ木のリーフである場合、いくつかの利点がある。第一に、すべての非スクリプト入力が連結されてパケットD5を形成し、同様にすべての非スクリプト出力が連結されてD7を形成する。つまり、トランザクションのすべての入力と出力は、非スクリプト構成要素とスクリプト構成要素のちょうど2つの部分に分けられる。二分ハッシュ木では、これはすべての入力と出力が兄弟リーフとして対にできることを意味するので、これは特に有利である。したがって、入力および出力は、他のフィールドから完全に分離されてもよく、各入力または出力のスクリプト構成要素および非スクリプト構成要素も分離されうる。つまり、与えられたスクリプトが非常に大きい場合でも、大きなスクリプト自体を処理する必要なく、ハッシュ木証明を実行することによって、非スクリプト構成要素が検証できるのである。
【0109】
これらのフィールドに加えて、TxIDは、ハッシュ木Tにリーフとして含まれてもよい。上記の例に続いて、これはデータ・フィールドD9=<TxID>を含むことを意味する。一般に、トランザクションには多くの入力と多くの出力があることがあり、そのそれぞれはアルゴリズムFによって2つの構成要素に分割されてもよい。したがって、このツリーTにおけるデータ・ブロックの総数N=|D|は、次式で表される:
【数3】
ここで、nin、noutはそれぞれトランザクション入力および出力の数である。いくつかの例では、他のすべてのデータ・フィールドは、単一のデータ・フィールドを形成するよう連結されてもよい。これにより、リーフの総数がN=2+2(nin+nout)に減少する。
【0110】
N=2kとなるようなk∈Z*が存在しない場合、ヌル・パディング・データの2k-N>0個のデータ・パケットが追加されて、二分ハッシュ木の十分なリーフがあることを保証してもよい。このパディングは、ヌル・データであってもよいし、あるいは、一次トランザクション識別子と最終的な二次識別子MTxIDとの間のリンクを強化するためにTxIDの2k-N個のコピーであってもよい。
【0111】
所与のトランザクションは、複数の入力および/または複数の出力を含んでいてもよい。各入力は、スクリプト・データおよび非スクリプト・データを含んでいてもよい。同様に、各出力は、スクリプト・データおよび非スクリプト・データを含んでいてもよい。トランザクションは、1つのデータ・フィールドが各入力からのすべてのスクリプト・データを含み、1つのデータ・フィールドが各入力からのすべての非スクリプト・データを含むように分割されてもよい。出力データは、同様に分割されてもよい。あるいはまた、一つまたは複数のデータ・フィールドが、組み合わせて、各入力からのすべてのスクリプト・データを含んでいてもよく、一つまたは複数のデータ・フィールドが、組み合わせて、各入力からのすべての非スクリプト・データを含んでいてもよい。ここでもまた、出力データは同様に分割されてもよい。
【0112】
いくつかの場合には、所与のフィールド内からデータの一部を抽出し、これらをハッシュ木Tの追加のリーフとして使用することが望ましいことがある。scriptSigフィールドから抽出されうるデータの例は、署名<Sig(P,m)>であり、ScriptPubKeyフィールドから抽出されうるデータの例は、公開鍵ハッシュ<H(P)>である。例では、これらのいずれかまたは両方が抽出されて、別個のデータ・フィールドを形成してもよい。これらのデータ要素をスクリプトから抽出し、それらをハッシュ木において追加のデータ・パケットとして含めることにより、他のデータを処理する必要なく、トランザクションへの参加者およびその署名の軽量な検証が許容される。
【0113】
別の例として、トランザクション・タイプの識別子がハッシュ木においてリーフとして含められてもよい。TxIDと同様の意味で、これはトランザクション・メッセージに含まれるフィールドまたはデータ要素ではないが、標準的なトランザクション・タイプ、たとえば、公開鍵ハッシュに対する支払い(pay-to-public key hash、P2PKH)、スクリプト・ハッシュに対する支払い(pay-to-script hash、P2SH)、または非標準、の基準に基づいてメッセージを解釈することによって識別できる。トランザクション・タイプを示すデータ要素を含めることにより、軽量ユーザーが、トランザクションをローカルに取得したり分析したりする必要なく、トランザクションに関する重要な情報を識別することができる。
【0114】
いくつかのシナリオでは、たとえばトランザクションをブロックチェーン中にマイニングする時点で、二次トランザクション識別子を生成するのは、マイナーである。マイナーにとって最も簡単な方法でトランザクションを分割することが望ましいことがある。よい候補は、各ツリーについてのリーフ数(たとえばN=2k)を固定し、トランザクション・メッセージを
【数4】
となるようにN個のデータ・パケットに分割することによって、ハッシュ木を生成することであろう。ここで、共通のパケット・サイズは、全トランザクション・サイズとともに線形にスケーリングされる。
【0115】
あるいはまた、ハッシュ木のデータ・リーフのための共通のパケット・サイズSが固定されてもよい。その後、トランザクションは、必要な数Nのパケットに分割されてもよい。このオプションは、低帯域幅の軽量の検証ユーティリティが、好適に小さいSを選択することによって損なわれないことを保証するために使用できる。
【0116】
この方法は、トランザクションをデータ・フィールドの順序付けられた集合に分割することを含み、各データ・フィールドはトランザクションのそれぞれのデータを含む。トランザクション・メッセージTxは、データ・リーフの順序付けられた集合D:={D1,D2,…,DN}を含むN個の離散的なデータ・パケットに分離されてもよい。これは、上に詳述したように、いくつかの方法でできる。
【0117】
段階3:Dを使ったハッシュ木Tの生成およびルートRの計算
この方法は、トランザクション・ハッシュ木のリーフとしてデータ・フィールドの集合を使用することを含む。トランザクション・ハッシュ木は、リーフ層、一つまたは複数の内部層、およびルート層を含む。リーフ層は、複数のリーフ・ノード(各ノードがハッシュ・ダイジェストであるので、リーフ・ハッシュとも呼ばれる)を含む。各リーフ・ノードは、トランザクションのそれぞれのデータ・フィールドをハッシュすることによって生成される。リーフ・ハッシュの少なくとも1つは、一次トランザクション識別子に基づく。いくつかの例では、一つまたは複数のリーフ・ハッシュが、一次トランザクション識別子をハッシュすることによって生成される。いくつかの例では、トランザクションの一つまたは複数のデータ・フィールドが一次トランザクション識別子と連結され、次いでハッシュされて、それぞれのリーフ・ハッシュを生成する。各内部層は、複数の内部ノード(または内部ハッシュ)を含む。所与の内部層における各内部ハッシュは、下位層からの少なくとも2つのハッシュの連結をハッシュすることによって生成される。たとえば、第1または最下位の内部層(すなわち、リーフ層に直接接続された内部層)は、少なくとも2つのリーフ・ハッシュの連結をハッシュすることによって生成された内部ノードを含む。二分ハッシュ木については、所与の層からの2つのノードが連結され、次いでハッシュされて次の層のノードを生成する。n分ハッシュ木については、所与の層からのn個のノードが連結され、次いでハッシュされて、次の層のノードを生成する。ルート層は、トランザクション木のルート、すなわち、二次トランザクション識別子を含む。二次トランザクション識別子は、一つまたは複数の内部層の最上位の内部層(すなわち、ルート層に直接接続された内部層)の内部ハッシュの連結をハッシュすることによって生成される。
【0118】
二次トランザクション識別子(トランザクション・ハッシュ木のルート)は、ブロックの生成トランザクションに含まれてもよい。その後、ブロックはブロックチェーンに記録されてもよい。あるいはまた、後述するように、二次トランザクション識別子は、ネットワークの一つまたは複数のノードを介してマイナーに送信されるトランザクションに含まれてもよい。
【0119】
アルゴリズムFはデータ・パケットの順序付けされた集合Dをとり、これらのパケットをリーフとして用いてハッシュ木Tを構築する。図6は、二分ハッシュ木の例示的な構成を示す。この例では、最初の4つのデータ・フィールドD1,…,D4はトランザクションのその他のフィールドであり、次の2×(nin+nout)個のデータ・フィールドはスクリプトD5、D6と非スクリプトD7、D8フィールド・データの対として表された入力および出力フィールドである。残りのデータ・フィールドは、TxIDを含む少なくとも1つのフィールドD9、D10と、何らかの整数kについてN=2kに達するために必要な任意のパディングDNとを含む。
【0120】
これらのN個のデータ・フィールドがリーフとして与えられると、ハッシュ木生成アルゴリズムはマークル木Tを作成する。マークル木は、一次トランザクション識別子を生成するために使用されるのと同じアルゴリズムを使用して構築されてもよい。これは、Tが、ルートRB(一次トランザクション識別子)がブロック・ヘッダ内に見出されるトランザクション木TBと同じように構築されることを意味する。これには、リーフについてのハッシュ関数と、内部ノードについてのハッシュ関数との使用を含む。トランザクション木TBの構築は、以下で詳しく述べる。ハッシュ木Tと既存のTBの両方において、データ・フィールドがダブルハッシュされてツリーのリーフを生成することに注意されたい。これは、軽量の存在証明に有益である。あるいはまた、データ・フィールドは、シングルハッシュされてツリーのリーフを生成してもよい。ここで1つの違いは、Tのリーフは単一のトランザクションのフィールドを含むパケットD∈{D1,…,DN}であるのに対して、TBのリーフは所与のブロックに含まれる個々のトランザクションであるということである。好ましくは、ハッシュ木におけるリーフの順序は、段階3で指定されたパケットの順序と全く同じである。
【0121】
ノード(たとえば、ノードで実行されるマイナー・ソフトウェア)は、トランザクション・メッセージTxをリーフの順序付けられた集合にパースし、ハッシュの木全体を記憶するのではなく、単にリーフをルートRと一緒に記憶してもよい。あるいはまた、ハッシュの木全体が記憶されてもよい。順序付けられたリーフとルートのみを保持することによって、Txを記憶するのと比べ、記憶オーバーヘッドは32バイト増加するだけであり、ツリーは、この情報からいつでも再構成できる。この小さな記憶オーバーヘッドは、ノードがデータ・パケットを通常通りに記憶することを選択し、単に必要に応じてそれらのパケットからツリーとそのルートを構築する場合、緩和されることもできる。
【0122】
二次トランザクション識別子がマイナーによって生成される場合、マイナーはそれをブロックの生成トランザクションに含めてもよい。二次トランザクション識別子が、マイナー以外のユーザー、たとえばアリスによって生成される場合、そのユーザーは、マイナーによってブロック中にマイニングされるべく、ネットワークを通じて伝搬されるトランザクション内にそれを含めることができる。別の例として、二次トランザクション識別子は、ブロックチェーン・ネットワークに接続されていないが、ターゲット・トランザクションへのアクセスをもつユーザーによって生成されてもよい。そのユーザーは、たとえばインターネットを通じて、一人または複数の当時者(ブロックチェーン・ネットワークに接続されていてもいなくてもよい)に二次トランザクション識別子を送信してもよい。二次トランザクション識別子(トランザクション・ハッシュ木のルート)は、ブロック(ターゲット・トランザクションを含む同じブロック、または異なるブロック)の生成トランザクションに記録される(すなわち、コミットされるように書き込まれる)のでもよい。その後、ブロックはブロックチェーンに記録されてもよい。二次トランザクション識別子は、生成トランザクション以外のトランザクションにコミットされてもよい。たとえば、ユーザーは、二次トランザクション識別子を取得し、それをトランザクション(たとえば、トランザクションのスクリプト)内に含め、そのトランザクションを、ブロックチェーン中にマイニングされるよう、ネットワークの一つまたは複数のノードに送信してもよい。二次トランザクション識別子を生成するユーザーは、追加的または代替的に、識別子をローカルメモリに記憶してもよい。
【0123】
候補データ・フィールド検証
前述のように、二次トランザクション識別子は、照会ユーザーが、トランザクションが候補データ・フィールドを含むかどうかをチェックすることを許容する。照会ユーザーは、そのようなチェックを実行するために、候補データ・フィールド(またはそのハッシュ)、二次トランザクション識別子、およびハッシュ木経路(または認証経路)を要求する。生成ユーザーが、これらの要求要素のうちの一つまたは複数を照会ユーザーに送信してもよい。あるいはまた、照会ユーザーは、別のユーザーから、またはブロックチェーン自体から、一つまたは複数の要素を取得してもよい(たとえば、二次トランザクション識別子は、生成トランザクションから取得されてもよい)。
【0124】
いくつかの例では、生成ユーザーは、トランザクション全体を明かすことなく、トランザクションが候補データ・フィールドを含むことを照会ユーザーに対して証明することを望むことがある(あるいはまた、照会ユーザーは、トランザクションが候補データ・フィールドを含むかどうかをチェックすることを望んでいるだけであることがある)。その場合、生成ユーザーは、候補データ・フィールドのみを照会ユーザーに送信することができる。
【0125】
ハッシュ木経路は、ハッシュの順序付けられた集合を含む。ハッシュの集合は、少なくとも1つのリーフ・ハッシュを含む。集合は、一つまたは複数の内部ハッシュをさらに含んでいてもよい。内部ハッシュの数は、トランザクションが分割されるデータ・フィールドの数とハッシュ木のタイプ(たとえば、ハッシュ木が二分ハッシュ木であるか、三分ハッシュ木であるかなど)の両方に依存する。
【0126】
照会ユーザーは、候補データ・フィールド(またはそのハッシュ)とハッシュ経路を使用して、それらの要素を使用して生成されたハッシュ木のルートがトランザクションの二次トランザクション識別子と一致するかどうかを(ハッシュ木証明を実行することによって)判定する。ルートが二次トランザクション識別子と一致すれば、基礎になるハッシュ関数の一意性のため、照会ユーザーはトランザクションが候補データ・フィールドを含むことを確信することができる。
【0127】
ハッシュ木証明は、候補データ・フィールドのハッシュを、ハッシュの順序付けられた集合(ハッシュ木経路)内の少なくとも1つのリーフ・ハッシュと連結することを含む。これは内部ハッシュ(またはハッシュ木の内部ノード)を生成する。生成された内部ハッシュは、次いで、ハッシュ木経路内の一つまたは複数のハッシュ(ハッシュ木が二分ハッシュ木の場合、1つのハッシュ)と連結される。次いで、連結された内部ハッシュがハッシュされて、次のハッシュが生成される。ハッシュ木のサイズ(たとえば、データ・フィールドの数)に応じて、次のハッシュは別の内部ハッシュまたはルート・ハッシュである可能性がある。次のハッシュが別の内部ハッシュである場合、ハッシュ木経路からの一つまたは複数の内部ハッシュと連結し、結果をハッシュするプロセスが、ルート・ハッシュが生成されるまで続く。ハッシュ木経路の各ハッシュは、1回だけ使用されることに注意されたい。
【0128】
ルート・ハッシュは、候補二次トランザクション識別子と等価である。候補二次トランザクション識別子が取得された二次トランザクション識別子と一致する場合、候補データ・フィールドはトランザクションの一部を形成する。候補データ・フィールドがトランザクションの一部を形成しているかどうかを示すために、指示(たとえば、真または偽)が出力されてもよい(たとえば、ユーザー装置を介してユーザーに)。出力は、視覚的または音声的アラートであってもよい。
【0129】
いくつかの例では、トランザクションは、コンテンツデータ(たとえば、メディアデータ)を含む。一つまたは複数のデータ・フィールドがコンテンツデータを含むことができる。コンテンツデータは、たとえば、画像データ(たとえば、写真)、音声データ(たとえば、楽曲)、ビデオデータ(たとえば、映画)、または文書データ(たとえば、ワード文書またはpdf)でありうる。候補データ・フィールドはデータを含むデータ・フィールドであってもよい。よって、これにより、当事者は、トランザクションが前記コンテンツを含むかどうかを検証することができる。いくつかの例では、二次トランザクション識別子および候補データ・フィールドを提供する生成ユーザーは、ネットワークの信頼されるノードであってもよい。
【0130】
ここで、「ユーザー」は、エンドユーザーまたは消費者に限定されないことに留意されたい。たとえば、諸実施形態において、生成ユーザー(記録当事者)は、マイナー104Mであってもよい。照会ユーザーは、アリス103aのような消費者103、またはマイナー・ノード104Mであることができる。ユーザーによる照会も、手動で発される問い合せに限定されない。諸実施形態において、照会は、ユーザーによって実行される自動化されたプロセスによって行うことができる。たとえば、プロセスは、検証またはマイニングしている各トランザクションの支払部分をチェックすることのみを望むマイナーまたは他のノード104によって実行される自動化プロセスであってもよい。
【0131】
トランザクション木検証アルゴリズム
当事者(すなわち、検証ユーザー)は、トランザクション木生成アルゴリズムFを補完する検証アルゴリズムVFを実行してもよい。この検証アルゴリズムは、検証者アリスが、他の当事者ボブが候補MTxIDを生成するために生成アルゴリズムを正しく使用したかどうかをチェックすることを許容する。検証アルゴリズムVF(MTxID,Tx)は、ボブの候補識別子MTxIDと、MTxIDによって識別されるはずのトランザクションTxの2つの入力を取る。アルゴリズムは、候補識別子MTxIDが正しく生成されたかどうかを示すために、新または偽のいずれか(または何らかの他の指示)を出力してもよい。出力は、ユーザー装置を介してユーザーに出力されてもよい(たとえば、視覚的または音声的アラートとして)。
【0132】
検証アルゴリズムは、以下のように書くことができる。
入力:MTxID、Tx
VF(MTxID,Tx):
1)TxID:=H2(Tx)を計算する。
2)アルゴリズムFと同じ手順を用いて、TxをN=2k個の順序付けられたデータ・パケットの集合D={D1,D2,…,DN}に分割する。計算されるTxIDは、それらのパケットのうちの少なくとも1つである。
3)集合Dのパケットをリーフとして用いて二分マークル木Tを生成し、そのマークル・ルートRを計算する。
4)RとMTxIDが等しいかどうかをチェックする:
4.1 R=MTxIDであれば、「真」を返す。
4.2 R≠MTxIDであれば、「偽」を返す。
出力:「真」または「偽」
【0133】
このアルゴリズムは、二次トランザクション識別子を生成するために二分ハッシュ木を使用すべきであるとプロトコルが規定する場合に適用される。しかしながら、一般には、上述のように、任意のn分ハッシュ木が使用されうる。
【0134】
照会当事者(アリス)は、生成ユーザー(Bob)またはネットワークの他のノードから候補二次トランザクション識別子MTxIDを取得することができる。あるいはまた、検証当事者は、候補MTxIDを、ブロックチェーンのブロックから抽出することによって得ることができる(二次トランザクション識別子がブロックの生成トランザクションに記録されうることを想起されたい)。
【0135】
検証アルゴリズムは、他のピア(たとえば、マイナー)によって認証されたMTxIDが生成アルゴリズムFに従って正しく、正直に計算されたかどうかを、任意のネットワーク・ピアが独立に検証することを許容する。検証者は、VFを使用して検証を実行する時点で、候補MTxIDに対応する完全なトランザクション・データおよび生成アルゴリズムFの知識を有している。たとえば、生成アルゴリズムおよび/またはトランザクションは、ネットワークのノード間に分散されてもよい。
【0136】
MTxIDを信頼すること
二次トランザクション識別子MTxID:=Rを生成する1つの目的は、軽量のクライアント、アリスが、完全なトランザクションを取り出して解釈する必要なく、ブロックチェーン上の関心のあるトランザクション・フィールドまたはデータ要素の存在を検証することを許容することである。しかしながら、公知のMTxIDは必ずしもクライアントが信頼できるとは限らない。たとえば、アリスが信頼されない当事者ボブからMTxIDの値を受け取る場合、アリスはボブが正しい生成関数Fを使ったかどうかを判別できない。その理由は、あるデータ・パケットDiがブロックチェーン上のトランザクションTxに対応する順序付けられた集合Dの要素であることを証明できることは、2つの条件に関わるからである:
1)Di∈Dであることを証明する。ここで、Dは(上述のように)ルート・ハッシュR=MTxIDを計算するために使用される。
2)MTxIDが、TxIDによって識別される採掘されたトランザクションTxに対応することを証明する。
【0137】
トランザクションのハッシュ木T上でハッシュ証明(たとえば、マークル証明)を実行することは、これらの2つの条件のうちの第1の条件を満たすのに十分であるだけである。
MTxIDを信頼することのこの問題に対する解決策は、任意の所与のトランザクションについての識別子TxIDとMTxIDの両方の間の直接的なオンチェーン・リンク(on-chain link)を提供する「レイヤー2プロトコル(layer-2 protocol)」と呼ばれる。
【0138】
生成ユーザーは、追加のハッシュ木TM(ハッシュ木の木)を構築し、そのルート・ハッシュRMを生成トランザクションのスクリプト内のデータ要素として含めることができる。TMの構築は、各新規ブロックについての採掘プロセスの一部として、トランザクションの集計と並行なされてもよい。RMを含めることは、生成トランザクションにおいて、比較的小さな32バイトの値が格納されることを要求するだけである。
【0139】
プロトコルは、以下の段階を含む:
1)生成ユーザーは、次のブロック中にマイニングするべきN個のトランザクションの集合T={Tx1,Tx2,…,TxN}を受信する。
2)既存のブロックチェーン・プロトコルに従って、候補ブロックの集合Tを順序付ける。
3)2つのハッシュ木を生成する:
3.1)(2)で決定された順序で各トランザクションをリーフとして使ってブロック・ハッシュ木TBを生成する。これは、ブロック・ハッシュ木を生成するための標準的な方法を用いて行われる。この段階は、各トランザクションについて、そのトランザクションをハッシュすることによってそれぞれの一次トランザクション識別子を生成することを含む。
3.2)(2)で決定された順序で各トランザクションのMTxIDをリーフとして使って、トランザクション・ハッシュ木の木TMを生成する。MTxIDの順序は(3.1)における対応するTxの順序と同じであり、それぞれは関数MTxIDi=F(Txi)を使って生成される。
4)各ルートを候補ブロックに記録する:
4.1)候補ブロック・ヘッダのMerkle_root〔マークル・ルート〕フィールドに木TBのルートRBを記録する。
4.2)候補ブロック生成トランザクションのフィールドに木TMのルートRMを記録する。
【0140】
RMは、候補ブロック生成トランザクションの一つまたは複数のフィールドに記録されることができる。たとえば、そのトランザクションの出力スクリプトの1つにである。
【0141】
上述の検証アルゴリズムと同様に、検証ユーザーは、トランザクションの同じ集合を使用してトランザクション・ハッシュ木の木を生成し、結果として生じる木TMのルートRMが生成ユーザーによって生成されたものと等しいかどうかを検証することができる。
【0142】
図7は、ブロック・ハッシュ木TB 700の例を示す。示されるように、各トランザクション701はハッシュされてTBのそれぞれのリーフ702を形成し、ルートRBは、有効なブロックのブロック・ヘッダに含められる。
【0143】
図8は、ブロックの例示的構成を示している。ここで、トランザクション・ハッシュ木の木TMのルートRMが生成トランザクションのスクリプト・フィールドに含まれる。ブロック・ハッシュ木TBも示され、そのルートRBはブロック・ヘッダに格納される。
【0144】
このプロトコルは、ブロックに含まれるトランザクションのTxIDとそれらに対応するMTxIDとの間のマイナーによって認証されたリンク(miner-attested link)を確立することを許容する。なぜなら、みなブロックチェーンに格納されている、(RBで表される)ブロック内のトランザクションのリストおよび(RTで表される)対応するMTxIDのリストを生成するのが、常に同じマイナーだからである。どのブロックにおいても、作業証明(proof of work、PoW)コンセンサス・アルゴリズムは、RBの値と対応する木TBの値が信頼できることを保証する。RBへの信頼は、RMの値も、それがPoWによって保護された情報と整合的であるため、信頼されることを保証するために使われる。その理由は、両方のツリーが同じ入力データ、トランザクションの集合Tから構築され、該トランザクションの集合は、PoWコンセンサス・アルゴリズムによって保護される情報であるからである。TxIDとMTxIDの間の必要とされる一対一対応は、よって、軽量クライアントを含む任意のネットワーク・ノードにとって検証可能である。
【0145】
上記で詳述したように、生成ユーザーは、二次ブロック識別子が生成される「レイヤー2プロトコル」を実装してもよい。レイヤー2プロトコルは、基本ブロックチェーン・プロトコルの「上に」(on-top)実装されたプロトコルである。基本プロトコルは、そのようなレイヤー2プロトコルの影響を受けない(あるいはそれに「気づく」必要さえない)。レイヤー2プロトコルは、単にブロックチェーン・プロトコルに追加して、その拡張として何かを構築するだけである。
【0146】
二次ブロック識別子は、トランザクション集合ハッシュ木(またはトランザクション・ハッシュ木の木)のルートである。トランザクション集合ハッシュ木の各リーフは、ブロック内の異なるトランザクションの二次トランザクション識別子であってもよい(ブロック内のトランザクション数に応じて、一つまたは複数のハッシュ値がパディングとして使用されてもよい)。同じ生成ユーザーが、二次トランザクション識別子と二次ブロック識別子を生成してもよい。あるいはまた、第1の生成ユーザーが二次トランザクション識別子を生成し、第2の異なる生成ユーザーが、二次ブロック識別子を生成してもよい。いくつかの例では、マイナーだけが二次ブロック識別子を生成できる。たとえば、第1の生成ユーザーが、第1のトランザクション内に二次トランザクション識別子を含め、それをネットワークを通じて送信してもよい。同様に、第2の生成ユーザーが、第2の異なるトランザクションについて同じことを行ってもよい。第3の生成ユーザーが、第1および第2のトランザクションの二次トランザクション識別子を、一つまたは複数の異なるトランザクションの二次トランザクション識別子とともに取得し、次いで、二次ブロック識別子を生成してもよい。
【0147】
二次トランザクション識別子および/または二次ブロック識別子を生成するために生成ユーザーが使用したトランザクション(単数または複数)へのアクセスを有する任意のユーザー(検証ユーザー)は、それらの識別子が正しく生成されたか、すなわちブロックチェーンのプロトコルに従って生成されたどうかを検証することができる。検証ユーザーは、該トランザクション(単数または複数)を、たとえばトランザクションのソースまたはブロックチェーンの全部もしくは一部のコピーから取得することができる。検証ユーザーは、プロトコルに正しく従っていた場合に生成ユーザーが完了すべきであったものと同じプロセスを繰り返す。二次トランザクション識別子が生成ユーザーによって生成されたものと一致する場合、検証ユーザーはそれが正しく生成されたものであることを認証できる。二次ブロック識別子についても同様である。
【0148】
二次トランザクション識別子(単数または複数)と二次ブロック識別子は、ブロックチェーン中にマイニングされるために、同じトランザクションまたは異なるトランザクションにコミットされうる。二次トランザクション識別子がマイナーによって生成される場合、マイナーはそれをブロックの生成トランザクションに含めることができる。二次トランザクション識別子が、マイナー以外のユーザー、たとえばアリスによって生成される場合、そのユーザーはそれを、マイナーによってブロック中にマイニングされるよう、ネットワークを通じて伝搬されるトランザクション内に含めることができる。別の例として、二次トランザクション識別子は、ブロックチェーン・ネットワークに接続されていないが、ターゲット・トランザクションへのアクセスを有するユーザーによって生成されてもよい。そのユーザーは、たとえばインターネットを通じて、二次トランザクション識別子を、一人または複数の当事者(ブロックチェーン・ネットワークに接続されていてもいなくてもよい)に送信してもよい。二次トランザクション識別子(トランザクション・ハッシュ木のルート)は、ブロック(ターゲット・トランザクションを含む同じブロック、または異なるブロック)の生成トランザクションに記録されてもよい(すなわち、コミットされるように書き込まれてもよい)。そのブロックは、次いで、ブロックチェーンに記録されてもよい。二次トランザクション識別子は、生成トランザクション以外のトランザクションにコミットされてもよい。たとえば、ユーザーは、二次トランザクション識別子を入手し、それをトランザクション(たとえば、トランザクションのスクリプト)内に含め、そのトランザクションを、ブロックチェーン中にマイニングされるよう、ネットワークの一つまたは複数のノードに送信することができる。二次トランザクション識別子を生成するユーザーは、追加的または代替的に、識別子をローカルメモリに記憶してもよい。
【0149】
同じコミット・ユーザーが、ブロックチェーンのブロック(同じブロックまたは異なるブロック)内に含めるために、二次トランザクション識別子および二次ブロック識別子をコミットしてもよい。あるいはまた、第1のコミット・ユーザーが二次トランザクション識別子をトランザクションにコミットし、第2の異なるコミット・ユーザーが二次ブロック識別子をトランザクション(たとえば、生成トランザクション)にコミットしてもよい。たとえば、マイナーのみが二次ブロック識別子を生成トランザクションにコミットすることができ、他のユーザーは二次トランザクション識別子をトランザクションに含めることができる。
【0150】
存在証明
トランザクションの個々のフィールドは、以下の存在証明の集合を使用して、完全なトランザクションを必要とせずに、それがブロックチェーン上に存在するかどうかを確認するためにチェックされることができる:
1)(Di,R,Γ)についてハッシュ証明を取得する。ここで、R=MTxIDである。すなわち、候補データ・フィールドDiがRを二次識別子としてもつトランザクションの一部であることを検証する。
2)(MTxID,RM,Γ)についてハッシュ証明を取得する。すなわち、候補二次トランザクション識別子MTxIDが、RMをルートとしてもつハッシュ木の木TMの一部であることを検証する。
3)(TxID,RB,Γ)についてハッシュ証明を取得する。すなわち、候補トランザクション識別子TxIDが、RBをルートとしてもつブロック・ハッシュ木TBの一部であることを検証する。
4)RMとRBが同じブロックにあることを検証する。このことは、ブロックチェーン上のブロックを検査することによって確かめることができる。
【0151】
任意的に、存在証明は、TxIDおよびMTxIDがそれぞれTBおよびTMにおける同じリーフ・ノード位置にあることを検証することを含んでいてもよい。
【0152】
これらのテストは、DiがトランザクションTxの一部であったことを証明するのに十分である。さらに、これらのテストは、比較的少数の(32ビット)ハッシュ値を必要とするだけであり、これは、軽量クライアントが処理できるようにするために現実的である。これは、どんなシンクライアントでも、完全なトランザクション・データを得る必要なく、そのような軽量な存在証明を実行できることを意味する。上に詳述した同じ存在証明が、データ・ブロック自体の単一の(たとえば、SHA-256)ハッシュで実行されてもよいことに注意されたい。これは、DiではなくH(Di)に対する存在証明であろう。多くの場合、データのハッシュに関するそのような証明は、データ自体を提供または開示する必要なく、データの存在を効果的に証明することができるので、望ましいであろう。
【0153】
照会ユーザーは、候補データ・フィールドがブロックチェーンのブロック内に含まれるトランザクションの一部であるかどうかを知りたいことがある。少なくとも、照会ユーザーは、候補データ・フィールドのハッシュを必要とする(これはユーザーに提供されてもよいし、あるいは照会ユーザーは、候補データ・フィールドを提供され、次いでユーザーがそれをハッシュするのでもよい)。二次トランザクション識別子についての認証経路(またはハッシュ木経路)も必要とされる。
【0154】
レイヤー2の存在証明を実装するために、照会ユーザーは候補二次ブロック識別子と、候補二次ブロック識別子についての認証経路とを必要とする。さらに、ターゲット・トランザクションの候補一次トランザクション識別子、トランザクションの集合を含むブロックの候補一次ブロック識別子、および一次ブロック識別子についての認証経路も必要とされる。
【0155】
照会ユーザーは、上記の要件のそれぞれまたは一部を、ブロックチェーン・ネットワークの生成ユーザーまたは他のノードによって提供されてもよい。あるいはまた、それらは、ブロックチェーン自体から(たとえば、ブロックチェーンの完全なコピーまたは部分コピーから)得られてもよい。別の例として、ブロックチェーンとは別個の当事者(たとえば、サービスプロバイダー)が、上記の要件の一つまたは複数へのアクセスを有し、それを提供してもよい。
【0156】
不在期間についての扱い
このプロトコルに参加するマイナーは、自分が採掘したブロックについてのみ、(RMにおいてエンコードされた)貴重なMTxID情報をネットワークに提供することができる。場合によっては、すべてのマイナーがプロトコルに参加するわけではない。プロトコルに参加するマイナーMは、生成トランザクションのスクリプト・フィールドに別の(32バイトの)ハッシュ値RM Interを含めることができる。値RM Interは、第3のハッシュ木TM Interのルートである。この追加的なツリーは、TMと同じように構築されるが、ただし、Mによって成功裏に採掘されたブロックどうしの間の中間(interim)期間中に採掘されたすべてのトランザクション(採掘された順序で)についてのMTxIDを使用する。これは、追加的な32バイトがそのマイナーによってその生成トランザクションに記憶されることを要求するが、このことは、マイナーが信頼されるMTxIDを、よって他のマイナーの参加なしでの軽量の存在証明を提供できることを意味する。これも、有効確認のための必要な情報のすべてがオンチェーンで記憶されているためである。
【0157】
例示的な使用事例
図9aおよび図9bを参照して、以下は、生成ユーザーが、トランザクションが候補データ・フィールドを含むかどうかを検証することを望む例を提供する。トランザクションは、デジタル資産の移転とは無関係に、コンテンツデータを記憶するために使用されることができる。たとえば、いくつかのトランザクションは、デジタル資産受領者のアドレスに関係しなくてもよいOP_RETURN scriptPubkeyフィールドにデータを含んでいてもよい。デジタル資産の移転に明示的に関連するデータからの、コンテンツデータのこの分離のため、多くの場合において、ユーザーは、完全なトランザクション・データをダウンロードするは望まずに、ブロックチェーン内にトランザクション・スニペットが存在することを検証することのみを望むことがある。
【0158】
アリスは、上述の諸プロトコルに参加するマイナーの生成トランザクションからの生成スクリプト・データとブロック・ヘッダ情報との記録を保持するSPVノードであるとする。ボブはそのようなマイナーであり、やはりブロックチェーンの完全なコピーを有する。学術論文のデジタル版を含む、ブロックチェーン上でのトランザクションTxを考える。該文書のデータは2つの別個のOP_RETURN出力scriptPubKeyフィールドに含まれ、図9aのように、タイトルと抄録は第1のOP_RETURN(出力1)に含まれ、論文の残りは第2のOP_RETURN(出力2)に含まれる。
【0159】
アリスはTx1についてのTxIDを知っているが、完全なトランザクション・データはもっていない。アリスは、Tx1へのアクセスをもつことを望み、それをボブに要求するが、ボブは、アリスの完全なトランザクション・データを提供する見返りとして支払われることを望んでいる。一方、アリスは、受け取るトランザクション・データが論文を含むことを確信する前に、ボブに支払いをすることは望まない。ボブは、アリスにプレビューを、軽量の存在証明とともに送ることによって、この確信を提供できる。ボブはまず、アリスにTx1内のトランザクション・データから論文の大半を差し引いたものを送り、第2のOP_RETURN(出力2)に続くデータをデータのSHA256ハッシュで置き換える(図9b参照)。
【0160】
一方では、アリスは自分が受け取ったタイトルと抄録(トランザクション・スニペット)が変更されていないことを検証したいが、ボブはトランザクション全体を提供したくない。ボブは、アリスがトランザクションをダウンロードすることや、アリスのSPVウォレットが提供できる他の任意のデータ(ブロック・ヘッダおよび生成データ)を要求することなく、アリスが受け取ったデータがブロックチェーンに格納されていることを証明する必要がある。
【0161】
ボブによって送られたTx1の軽量バージョンが変更されていない(すなわち、ブロックチェーンからのものである)ことを検証するために、軽量存在証明が使用できる。軽量Tx1とともにボブはハッシュ証明を提供する。すなわち、ボブは、上記で概説した方法に基づくシーケンス・ハッシュを提供し、それにより、アリスは、受信したデータを、Tx1が格納されているブロックからの生成トランザクションに格納されている木ルートRMと突き合わせて検証することができる(図9a参照)。アリスはRMをもつので、アリスはボブによって送信されたデータの完全性を検証するためにハッシュ証明を実行することができる。
【0162】
ボブが完全な学術論文のスニペットを送ってくれたと確信して、アリスはトランザクション全体を見ることを望むことがありうる。その場合、アリスは完全なトランザクション・データを要求することができる。欠けているデータ(すなわち、完全なトランザクション)を受信すると、アリスは、第2のOP_RETURN(出力2)のデータがハッシュされると、軽量トランザクションにおいて与えられているOP_RETURN(出力2)データと同じ文字列になることをチェックすることによって、今一度、最後のチェックを行うことができる。あるいはまた、アリスは、トランザクション全体をハッシュして、最初にもっていたTxIDと突き合わせてチェックすることもできる。
【0163】
別の例として、当事者は、トランザクションからデータを枝刈りすることを望むことがある。たとえば、個人データ要件に従うため、または記憶スペースを節約するためである。しかしながら、当事者は、トランザクションが候補データ・フィールド(たとえば、トランザクションの使用可能な出力)を含んでいたことを他者に証明する必要があることがありうる。トランザクションの二次トランザクション識別子は、任意の当事者が、枝刈りされたトランザクションが候補データ・フィールドを含んでいたかどうかを検証することを許容する。枝刈りされたデータ(たとえば、個人情報)は、枝刈りされたデータのハッシュで置き換えられてもよい。可能性の高い枝刈りの候補は、OP_RETURNデータまたはスクリプト・フィールドである。これは、格納できるデータの量が増すためである。よって、ノードが、枝刈りされたトランザクションが候補データ・フィールドを含むかどうかを検証することを望む場合、当事者は、ハッシュ木のリーフ・ノードとして使用するために、枝刈りされたデータのハッシュを提供されることができる。
【0164】
上記の実施形態は、単に例として記載されたものであることが理解されるであろう。
【0165】
本明細書に開示される教示の第1の具体化によれば、ターゲット・トランザクションの二次トランザクション識別子を生成する、コンピュータ実装される方法が提供される。前記二次トランザクション識別子は、照会ユーザーが、ターゲット・トランザクションが候補データ・フィールドを含むかどうかを判定できるようにする。本方法は、生成ユーザーによって実行され:前記ターゲット・トランザクションのデータ・フィールドの集合を識別するステップであって、各データ・フィールドは、前記トランザクションのそれぞれのデータを含む、ステップと;トランザクション・ハッシュ木を生成するステップとを含み、前記トランザクション・ハッシュ木は、i)複数のリーフ・ハッシュを含むリーフ層であって、各データ・フィールドはハッシュされて、前記複数のリーフ・ハッシュのそれぞれ1つを生成する、リーフ層、ii)複数の内部ハッシュをそれぞれ含む一つまたは複数の内部層であって、各内部層における各内部ハッシュは、下位層からの少なくとも2つのハッシュの連結をハッシュすることによって生成され、前記一つまたは複数の内部層のうち最下位の内部層の各内部ハッシュは、少なくとも2つの異なるリーフ・ハッシュの連結をハッシュすることによって生成される、内部層、およびiii)前記二次トランザクション識別子を含むルート層を含み、前記二次トランザクション識別子は、前記一つまたは複数の内部層のうち最上位の内部層の内部ハッシュの連結をハッシュすることによって生成される。
【0166】
いくつかの例では、本方法は、ブロックチェーン・ネットワークの一つまたは複数のノード、たとえば、一または複数のエンドユーザーから、前記トランザクションを受信することを含んでいてもよい。トランザクションは、UTXOベースのモデルのトランザクションであってもよい。あるいはまた、アカウント・ベースのモデルのトランザクションであってもよい。
【0167】
いくつかの例では、内部ハッシュの各集合は、単一のハッシュから構成される(たとえば、ハッシュ木は二分ハッシュ木)。あるいはまた、内部ハッシュの各集合は、2つ以上のハッシュを含んでいてもよい(たとえば、ハッシュ木が三分ハッシュ木の場合、2つのハッシュ)。
【0168】
第2の任意的な具体化によれば、第1の具体化に従った方法であって、当該方法は、二次トランザクション識別子をブロックチェーンにコミットすることを含む、方法が提供されうる。
【0169】
生成ユーザーは、ブロックチェーン・ネットワークのノードにおけるマイナーであってもよい。照会ユーザーは、エンドユーザー、マイナー、またはネットワークの異なるタイプのノードであってもよい。
【0170】
第3の、任意的な具体化によれば、第1または第2の具体化に従った方法であって、当該方法は:ブロックチェーンのブロック内に含めるために二次トランザクション識別子をトランザクションにコミットすること;ブロックチェーンのブロック内に含めるために二次トランザクション識別子を生成トランザクションにコミットすること;ブロックチェーン・ネットワークのノードに二次トランザクション識別子を送信すること;および生成ユーザーの計算装置のメモリに二次トランザクション識別子を記憶することのうちの1つ、いくつか、またはすべてを含む、方法が提供されてもよい。
【0171】
生成トランザクションは、ブロック内の論理的に最初のトランザクションであってもよい。
【0172】
本明細書に開示された教示の第4の具体例によれば、照会ユーザーが、ブロックチェーンのブロック内のターゲット・トランザクションが候補データ・フィールドを含むかどうかを判定できるようにする方法が提供される。本方法は、コミット・ユーザーによって実行され:前記ターゲット・トランザクションの二次トランザクション識別子を取得するステップと;前記二次トランザクション識別子を、前記ブロックチェーンのブロック内に含めるためにトランザクションにコミットするステップとを含み、前記二次トランザクション識別子は:前記ターゲット・トランザクションのデータ・フィールドの集合を識別するステップであって、各データ・フィールドは、前記トランザクションのそれぞれのデータを含む、ステップと;トランザクション・ハッシュ木を生成するステップとによって生成されたものであり、前記トランザクション・ハッシュ木は、i)データ・フィールドの順序付けられた集合に基づいて順序付けられた複数のリーフ・ハッシュを含むリーフ層であって、各データ・フィールドはハッシュされて、前記複数のリーフ・ハッシュのそれぞれ1つを生成する、リーフ層、ii)複数の内部ハッシュをそれぞれ含む一つまたは複数の内部層であって、各内部層における各内部ハッシュは、下位層からの少なくとも2つのハッシュの連結をハッシュすることによって生成され、前記一つまたは複数の内部層のうち最下位の内部層の各内部ハッシュは、少なくとも2つの異なるリーフ・ハッシュの連結をハッシュすることによって生成される、内部層、およびiii)前記二次トランザクション識別子を含むルート層を含み、前記二次トランザクション識別子は、前記一つまたは複数の内部層のうち最上位の内部層の内部ハッシュの連結をハッシュすることによって生成される。
【0173】
第5の任意的な具体化によれば、第4の具体化に従った方法であって、前記取得することが:前記二次トランザクション識別子を生成すること;前記二次トランザクション識別子をブロックチェーン・ネットワークのノードから受信すること;前記二次トランザクション識別子をブロックチェーン・ネットワークの外部のノードから受信すること、のうちの少なくとも1つを含みうる、方法が提供されてもよい。
【0174】
第6の任意的な具体化によれば、第4または第5の具体化に従った方法であって、前記コミットすることが、前記二次トランザクション識別子をブロックチェーンのブロック内の生成トランザクションにコミットすることを含みうる、方法が提供されてもよい。
【0175】
第7の任意的な具体化によれば、第1ないし第6の具体化のいずれかによる方法であって、前記トランザクション・ハッシュ木は二分ハッシュ木であってもよく、前記最下位の内部層の各内部ハッシュは2つの異なるリーフ・ハッシュの連結をハッシュすることによって生成され、各内部層の各内部ハッシュは下位層からの2つのハッシュの連結をハッシュすることによって生成され、最上位の内部層は2つの内部ハッシュを含む、方法が提供されてもよい。
【0176】
ハッシュ木が二分ハッシュ木である場合、内部ハッシュの各集合は、単一の内部ハッシュから構成される。
【0177】
第8の、任意的な具体化によれば、第1ないし第7の具体化のいずれかに従った方法であって、当該方法は、前記候補データ・フィールドについての認証経路を照会ユーザーに送信することを含んでいてもよく、前記認証経路は、ハッシュの順序付けられた集合を含み、ハッシュの順序付けられた集合は、少なくとも1つのリーフ・ハッシュと内部ハッシュの一つまたは複数の集合とを含み、内部ハッシュの各集合は、トランザクション・ハッシュ木の内部層のそれぞれの1つに属する、方法が提供されてもよい。
【0178】
第9の、任意的な具体化によれば、第1ないし第8の具体化のいずれかに従った方法であって、当該方法は、前記候補データ・フィールドまたはそのハッシュを照会当事者に送信するが、前記ターゲット・トランザクションの少なくとも1つの他のデータ・フィールドは送信しないことを含む、方法が提供されてもよい。
【0179】
たとえば、同じノードが候補データ・フィールドと二次トランザクション識別子の両方を送信してもよい。ノードは、信頼されるノードであってもよい。
【0180】
いくつかの例では、前記候補フィールドのみが照会当事者に送信され、前記ターゲット・トランザクションの他のどのデータ・フィールドも送信されない。
【0181】
第10の任意的な具体化によれば、第1ないし第9の具体化のいずれかに従った方法であって、データ・フィールドの前記集合は:i)前記ターゲット・トランザクションの入力データを含む少なくとも1つのデータ・フィールドと;ii)前記ターゲット・トランザクションの出力データを含む少なくとも1つのデータ・フィールドと;iii)前記ターゲット・トランザクションの非入力かつ非出力データを含む少なくとも1つのデータ・フィールドとを含みうる、方法が提供されてもよい。
【0182】
いくつかの例では、各データ・フィールドは、1つのタイプのデータ、たとえば、入力データ、出力データまたは他のデータ(すなわち、非入力かつ非出力データ)のみを含んでいてもよい。
【0183】
第11の任意的な具体化によれば、第1ないし第10の具体化のいずれかに従った方法であって、データ・フィールドの前記集合は:i)前記ターゲット・トランザクションのスクリプト入力データを含む少なくとも1つのデータ・フィールドと;ii)前記ターゲット・トランザクションの非スクリプト入力データを含む少なくとも1つのデータ・フィールドと;iii)前記ターゲット・トランザクションのスクリプト出力データを含む少なくとも1つのデータ・フィールドと;iv)前記ターゲット・トランザクションの非スクリプト出力データを含む少なくとも1つのデータ・フィールドとを含んでいてもよい、方法が提供されてもよい。
【0184】
第12の任意的な具体化によれば、第1ないし第11の具体化のいずれかに従った方法であって、前記ターゲット・トランザクションは、複数の入力に対応するデータを含んでいてもよく、データ・フィールドの前記集合は、前記入力のそれぞれについて、その入力のスクリプト・データを含む少なくとも1つのデータ・フィールドと、その入力の非スクリプト・データを含む少なくとも1つのデータ・フィールドとを含む、および/または、前記ターゲット・トランザクションは、複数の出力に対応するデータを含んでいてもよく、データ・フィールドの前記集合は、前記出力のそれぞれについて、その出力のスクリプト・データを含む少なくとも1つのデータ・フィールドと、その出力の非スクリプト・データを含む少なくとも1つのデータ・フィールドと、を含む、の一つまたは複数である、方法が提供されてもよい。
【0185】
第13の任意的な具体化によれば、第1ないし第12の具体化のいずれかに従った方法であって、データ・フィールドの前記集合は、i)一つまたは複数の署名を含む少なくとも1つのデータ・フィールドと、ii)署名以外の前記ターゲット・トランザクションのスクリプト入力データを含む少なくとも1つのデータ・フィールドと、iii)一つまたは複数の公開鍵ハッシュを含む少なくとも1つのデータ・フィールドと、iv)公開鍵ハッシュ以外の前記ターゲット・トランザクションのスクリプト出力データを含む少なくとも1つのデータ・フィールドと、を含んでいてもよい、方法が提供されてもよい。
【0186】
第14の任意的な具体化によれば、第1ないし第13の具体化のいずれかに従った方法であって、データ・フィールドの前記集合のうちの少なくとも1つは、前記ターゲット・トランザクションの一次トランザクション識別子を含んでいてもよい、および/または、前記データ・フィールドのうちの少なくとも1つは、前記ターゲット・トランザクションの一次トランザクション識別子をアペンドされる、方法が提供されてもよい。
【0187】
いくつかの例では、各データ・フィールドは、前記一次トランザクション識別子をアペンドされてもよい。あるいはまた、前記一次トランザクション識別子を含まない各データ・フィールドは、前記一次トランザクション識別子をアペンドされてもよい。
【0188】
第15の任意的な具体化によれば、第1ないし第14の具体化のいずれかに従った方法であって、前記一次トランザクション識別子は、前記ターゲット・トランザクションをハッシュすることによって生成されてもよい。
【0189】
前記一次トランザクション識別子は、前記ターゲット・トランザクションをダブルハッシュすることによって生成されてもよい。
【0190】
第16の任意的な具体化によれば、第1ないし第15の具体化のいずれかに従った方法であって、前記識別は固定数のデータ・フィールドの集合を識別することを含んでいてもよい、方法が提供されてもよい。
【0191】
第17の任意的な具体化によれば、第1ないし第15の具体化のいずれかに従った方法であって、前記識別は、それぞれが固定量のデータを含むデータ・フィールドの集合を識別することを含んでいてもよい、方法が提供されてもよい。
【0192】
第18の任意的な具体化によれば、第1ないし第17の具体化のいずれかに従った方法であって、前記ターゲット・トランザクションは、コンテンツデータを含んでいてもよく、前記候補データ・フィールドは、そのコンテンツデータの少なくとも一部を含む、方法が提供されてもよい。
【0193】
第19の任意的な具体化によれば、第1ないし第18の具体化のいずれかに従った方法であって、前記コンテンツデータが、画像データ、音声データ、ビデオデータ、およびテキストデータのうちの1つ、いくつか、またはすべてを含む、方法が提供されてもよい。
【0194】
本明細書に開示された教示の第20の具体化によれば、一つまたは複数のメモリユニットを備えるメモリと、一つまたは複数の処理ユニットを備える処理装置とを備えるコンピュータ設備であって、前記メモリは、前記処理装置上で動作するように構成されたコードを記憶し、該コードは、前記処理装置上で実行されたときに、第1ないし第3の具体化のいずれか、および/または第8ないし第19の具体化のいずれかの方法を実行するように構成される、コンピュータ設備が提供される。
【0195】
本明細書に開示された教示の第21の具体化によれば、コンピュータ設備上で実行されたときに第1ないし第3の具体化のいずれか、および/または第8ないし第19の具体化のいずれかの方法を実行するように構成された、コンピュータ読み取り可能記憶装置上に具現されたコンピュータ・プログラムが提供される。
【0196】
本明細書に開示された教示の第22の具体化によれば、一つまたは複数のメモリユニットを備えるメモリと、一つまたは複数の処理ユニットを備える処理装置とを備えるコンピュータ設備であって、前記メモリは、前記処理装置上で動作するように構成されたコードを記憶し、該コードは、前記処理装置上で実行されたときに、第4ないし第19の具体化のいずれかの方法を実行するように構成される、コンピュータ設備が提供される。
【0197】
本明細書に開示された教示の第23の具体化によれば、コンピュータ設備上で実行されたときに第4ないし第19の具体化のいずれかの方法を実行するように構成された、コンピュータ読み取り可能記憶装置上に具現されたコンピュータ・プログラムが提供される。
【0198】
本明細書に開示された教示の第24の具体化によれば、ブロックチェーンのブロック内のターゲット・トランザクションの候補二次トランザクション識別子が指定されたプロトコルに従って生成されたものであるかどうかを検証する、コンピュータ実装される方法が提供される。本方法は、検証ユーザーによって実行され:前記候補二次トランザクション識別子を取得するステップと;前記ターゲット・トランザクションのデータ・フィールドの集合を識別するステップであって、各データ・フィールドは、前記トランザクションのそれぞれのデータを含む、ステップと;トランザクション・ハッシュ木を生成するステップであって、前記トランザクション・ハッシュ木は、i)複数のリーフ・ハッシュを含むリーフ層であって、各データ・フィールドはハッシュされて、それぞれのリーフ・ハッシュを生成する、リーフ層、ii)複数の内部ハッシュをそれぞれ含む一つまたは複数の内部層であって、各内部層における各内部ハッシュは、下位層からの少なくとも2つのハッシュの連結をハッシュすることによって生成され、最下位の内部層の各内部ハッシュは、少なくとも2つの異なるリーフ・ハッシュの連結をハッシュすることによって生成される、内部層、およびiii)前記二次トランザクション識別子を含むルート層を含み、前記二次トランザクション識別子は、最上位の内部層の内部ハッシュの連結をハッシュすることによって生成される、ステップと;前記二次トランザクション識別子が前記候補二次トランザクション識別子と一致するかどうかを検証するステップとを含む。
【0199】
第25の任意的な具体化によれば、第24の具体化に従った方法であって、前記取得することは:前記候補二次トランザクション識別子をブロックチェーン・ネットワークのノードから受信すること;前記候補二次トランザクション識別子を前記ブロックチェーン・ネットワークの外部のノードから受信すること;および前記候補二次トランザクション識別子を前記ブロックチェーンのブロック内のトランザクションから抽出すること、のうちの一つまたは複数を含んでいてもよい、方法が提供されてもよい。
【0200】
本明細書に開示された教示の第26の具体化によれば、一つまたは複数のメモリユニットを備えるメモリと、一つまたは複数の処理ユニットを備える処理装置とを備えるコンピュータ設備であって、前記メモリは、前記処理装置上で動作するように構成されたコードを記憶し、該コードは、前記処理装置上で実行されたときに、第24および第25の具体化のいずれかの方法を実行するように構成される、コンピュータ設備が提供される。
【0201】
本明細書に開示された教示の第27の具体化によれば、コンピュータ設備上で実行されたときに第24および第25の具体化のいずれかの方法を実行するように構成された、コンピュータ読み取り可能記憶装置上に具現されたコンピュータ・プログラムが提供される。
【0202】
本明細書に開示される教示の第28の具体化によれば、ブロックチェーンのブロック内のターゲット・トランザクションが候補データ・フィールドを含むかどうかを判定する、コンピュータ実装される方法が提供される。本方法は、照会ユーザーによって実行され:候補リーフ・ハッシュを取得するステップであって、前記候補リーフ・ハッシュは前記候補データ・フィールドのハッシュである、ステップと;前記ターゲット・トランザクションの候補二次トランザクション識別子を取得するステップであって、前記二次トランザクション識別子は、前記ターゲット・トランザクションのデータ・フィールドの集合を識別するステップであって、各データ・フィールドが前記トランザクションのそれぞれのデータを含む、ステップ、および、トランザクション・ハッシュ木を生成するステップであって、前記トランザクション・ハッシュ木のルート層が、前記二次トランザクション識別子を含む、ステップによって生成されたものである、ステップと;前記候補データ・フィールドについての認証経路を取得するステップであって、前記認証経路は、順序付けられたハッシュの集合を含み、前記順序付けられたハッシュの集合は、少なくとも1つのリーフ・ハッシュおよび内部ハッシュの一つまたは複数の集合を含み、内部ハッシュの各集合は前記トランザクション・ハッシュ木のそれぞれの内部層に属する、ステップと;取得された候補リーフ・ハッシュ、取得された候補二次トランザクション識別子、前記候補データ・フィールドについての取得された認証経路を使用してハッシュ木証明を実行するステップであって、該実行することは二次トランザクション識別子を生成する、ステップとを含み、前記判定は、前記二次トランザクション識別子が前記候補二次トランザクション識別子と一致するかどうかに基づく。
【0203】
いくつかの例では、前記候補データ・フィールドのハッシュを取得することは、前記候補データ・フィールドを取得して、前記候補データ・フィールドをハッシュすることを含んでいてもよい。あるいはまた、前記取得することは、前記候補データ・フィールドのハッシュを、たとえば、記録当事者または他のノードから受信することを含んでいてもよい。
【0204】
第29の任意的な具体化によれば、第28の具体化に従った方法であって、前記ハッシュ木証明の前記実行は:前記候補リーフ・ハッシュの、前記順序付けられたハッシュの集合内の前記少なくとも一つのリーフ・ハッシュとの連結をハッシュし;次いで、前のハッシュの結果の、前記認証経路における内部ハッシュの前記一つまたは複数の集合のうちの次のものとの連結をハッシュするプロセスを、内部ハッシュの前記一つまたは複数の集合のうちの最後のものが、前のハッシュと連結された後にハッシュされるまで繰り返すことを含み、前記二次トランザクション識別子は、前記最後のハッシュの結果である、方法が提供されてもよい。
【0205】
第30の任意的な具体化によれば、第28または第29の具体化に従った方法であって、前記候補リーフ・ハッシュの前記取得は:前記候補リーフ・ハッシュを受信すること;または前記候補データ・フィールドを受信して、前記候補データ・フィールドをハッシュして前記候補リーフ・ハッシュを生成することを含む、方法が提供されてもよい。
【0206】
第31の任意的な具体化によれば、第28ないし第31の具体化のいずれかに従った方法であって、前記候補二次トランザクション識別子の前記取得は:前記二次トランザクション識別子をブロックチェーン・ネットワークのノードから受信すること;前記二次トランザクション識別子をブロックチェーン・ネットワークの外部のノードから受信すること;および前記二次トランザクション識別子をブロックチェーンのブロック内のトランザクションから抽出すること、のうちの少なくとも1つを含んでいてもよい、方法が提供されてもよい。
【0207】
本明細書に開示された教示の第32の具体化によれば、一つまたは複数のメモリユニットを備えるメモリと、一つまたは複数の処理ユニットを備える処理装置とを備えるコンピュータ設備であって、前記メモリは、前記処理装置上で動作するように構成されたコードを記憶し、該コードは、前記処理装置上で実行されたときに、第28ないし第31の具体化のいずれかの方法を実行するように構成される、コンピュータ設備が提供される。
【0208】
本明細書に開示された教示の第33の具体化によれば、コンピュータ設備上で実行されたときに第28ないし第31の具体化のいずれかの方法を実行するように構成された、コンピュータ読み取り可能記憶装置上に具現されたコンピュータ・プログラムが提供される。
【0209】
本明細書に開示された教示の第34の具体化によれば、ブロックチェーンのブロックの二次ブロック識別子を生成する、コンピュータ実装される方法が提供される。前記ブロックは、トランザクションの集合を含み、前記二次ブロック識別子は、照会ユーザーが、前記トランザクションの集合が候補データ・フィールドを含むかどうかを判定することを可能にし、本方法は、生成ユーザーによって実行され:前記トランザクションの集合の各トランザクションについて、それぞれの二次トランザクション識別子を取得するステップと;トランザクション集合ハッシュ木を生成するステップとを含み、該トランザクション集合ハッシュ木は:i)複数のリーフ・ハッシュを含むリーフ層であって、各リーフ・ハッシュは、前記二次トランザクション識別子のそれぞれに対応する、リーフ層、ii)複数の内部ハッシュをそれぞれ含む一つまたは複数の内部層であって、各内部層における各内部ハッシュは、下位層からの少なくとも2つのハッシュの連結をハッシュすることによって生成され、該一つまたは複数の内部層のうち最下位の内部層の各内部ハッシュは、少なくとも2つの異なるリーフ・ハッシュの連結をハッシュすることによって生成される、内部層、およびiii)前記二次ブロック識別子を含むルート層を含み、前記二次ブロック識別子は、前記一つまたは複数の内部層のうち最上位の内部層の内部ハッシュの連結をハッシュすることによって生成される。
【0210】
前記一次ブロック識別子は、一次ブロック・マークル・ルートとも呼ばれうる。前記二次ブロック識別子は、二次ブロック・マークル・ルートとも呼ばれうる。
【0211】
第35の任意的な具体化によれば、第34の具体化に従った方法であって、当該方法は:前記二次ブロック識別子を、前記ブロックチェーンのブロック内に含めるために、トランザクションにコミットすること;前記二次ブロック識別子を、前記ブロックチェーンのブロック内に含めるために、生成トランザクションにコミットすること;前記二次ブロック識別子を前記ブロックチェーン・ネットワークのノードに送信すること;および、前記二次トランザクション識別子を生成ユーザーの計算装置のメモリに記憶することのうちの一つ、いくつか、またはすべてを含みうる、方法が提供されてもよい。
【0212】
いくつかの例では、前記ブロック・ハッシュ木および/または前記トランザクション集合ハッシュ木は、二分ハッシュ木である。
【0213】
第36の任意的な具体化によれば、第34または第35の具体化に従った方法であって、それぞれの二次トランザクション識別子を取得することは:それぞれの二次トランザクション識別子の一つ、いくつかまたは全部を生成すること;それぞれの二次トランザクション識別子の一つ、いくつかまたは全部を前記ブロックチェーン・ネットワークから受信すること;それぞれの二次トランザクション識別子の一つ、いくつかまたは全部を前記ブロックチェーン・ネットワークの外部のノードから受信すること;それぞれの二次トランザクション識別子の一つ、いくつかまたは全部を前記ブロックチェーンのブロック内の少なくとも一つのトランザクションから抽出することと、のうちの一つまたは複数を含んでいてもよい、方法が提供されてもよい。
【0214】
本明細書に開示された教示の第37の具体化によれば、一つまたは複数のメモリユニットを備えるメモリと、一つまたは複数の処理ユニットを備える処理装置とを備えるコンピュータ設備であって、前記メモリは、前記処理装置上で動作するように構成されたコードを記憶し、該コードは、前記処理装置上で実行されたときに、第34ないし第36の具体化のいずれかの方法を実行するように構成される、コンピュータ設備が提供される。
【0215】
本明細書に開示された教示の第38の具体化によれば、コンピュータ設備上で実行されたときに第34ないし第36の具体化のいずれかの方法を実行するように構成された、コンピュータ読み取り可能記憶装置上に具現されたコンピュータ・プログラムが提供される。
【0216】
本明細書に開示された教示の第39の具体化によれば、照会ユーザーが、ブロックチェーンのブロック内のトランザクションの集合が候補データ・フィールドを含むかどうかを判定することを可能にする方法が提供される。本方法は、コミット・ユーザーによって実行され:前記トランザクションの集合を含む前記ブロックの二次ブロック識別子を取得するステップと;前記二次ブロック識別子を前記ブロックチェーンのブロック内に含めるためにトランザクションにコミットするステップとを含み、前記二次ブロック識別子は:前記トランザクションの集合における各トランザクションについて、それぞれの二次トランザクション識別子を取得するステップと;トランザクション集合ハッシュ木を生成するステップとによって生成されたものであり、該トランザクション集合ハッシュ木は:i)複数のリーフ・ハッシュを含むリーフ層であって、各リーフ・ハッシュは、前記二次トランザクション識別子のそれぞれに対応する、リーフ層、ii)複数の内部ハッシュをそれぞれ含む一つまたは複数の内部層であって、各内部層における各内部ハッシュは、下位層からの少なくとも2つのハッシュの連結をハッシュすることによって生成され、該一つまたは複数の内部層のうち最下位の内部層の各内部ハッシュは、少なくとも2つの異なるリーフ・ハッシュの連結をハッシュすることによって生成される、内部層、およびiii)前記二次ブロック識別子を含むルート層を含み、前記二次ブロック識別子は、前記一つまたは複数の内部層のうち最上位の内部層の内部ハッシュの連結をハッシュすることによって生成される。
【0217】
第40の任意的な具体化によれば、第39の具体化に従った方法であって、前記コミットすることが、前記二次トランザクション識別子を、前記ブロックチェーンのブロック内の生成トランザクションにコミットすることを含んでいてもよい、方法が提供されてもよい。
【0218】
第41の任意的な具体化によれば、第39または第40の具体化に従った方法であって、当該方法は:前記トランザクションの集合を含む前記ブロックの一次ブロック識別子を取得するステップと;前記二次ブロック識別子を前記ブロックチェーンの前記ブロックの前記生成トランザクションにコミットするステップとを含み、前記一次ブロック識別子は:前記トランザクションの集合における各トランザクションについて、それぞれの一次トランザクション識別子をそのトランザクションをハッシュすることによって生成するステップと;ブロック・ハッシュ木を生成するステップとによって生成されたものであり、該ブロック・ハッシュ木は:i)複数のリーフ・ハッシュを含むリーフ層であって、各リーフ・ハッシュは、前記一次トランザクション識別子のそれぞれに対応する、リーフ層、ii)複数の内部ハッシュをそれぞれ含む一つまたは複数の内部層であって、各内部層における各内部ハッシュは、下位層からの少なくとも2つのハッシュの連結をハッシュすることによって生成され、該一つまたは複数の内部層のうち最下位の内部層の各内部ハッシュは、少なくとも2つの異なるリーフ・ハッシュの連結をハッシュすることによって生成される、内部層、およびiii)前記ブロック識別子を含むルート層を含み、前記ブロック識別子は、前記一つまたは複数の内部層のうち最上位の内部層の内部ハッシュの連結をハッシュすることによって生成される、方法が提供されてもよい。
【0219】
本明細書に開示された教示の第42の具体化によれば、一つまたは複数のメモリユニットを備えるメモリと、一つまたは複数の処理ユニットを備える処理装置とを備えるコンピュータ設備であって、前記メモリは、前記処理装置上で動作するように構成されたコードを記憶し、該コードは、前記処理装置上で実行されたときに、第39ないし第41の具体化のいずれかの方法を実行するように構成される、コンピュータ設備が提供される。
【0220】
本明細書に開示された教示の第43の具体化によれば、コンピュータ設備上で実行されたときに第39ないし第41の具体化のいずれかの方法を実行するように構成された、コンピュータ読み取り可能記憶装置上に具現されたコンピュータ・プログラムが提供される。
【0221】
本明細書に開示された教示の第44の具体化によれば、ブロックチェーンのブロックの候補二次ブロック識別子が指定されたプロトコルに従って生成されたかどうかを検証する、コンピュータ実装される方法が提供される。前記ブロックは、トランザクションの集合を含み、本方法は、検証ユーザーによって実行され:前記候補二次ブロック識別子を取得するステップと;前記トランザクションの集合における各トランザクションについて、それぞれの二次トランザクション識別子を取得するステップと;トランザクション集合ハッシュ木を生成するステップであって、該トランザクション集合ハッシュ木は:i)複数のリーフ・ハッシュを含むリーフ層であって、各リーフ・ハッシュは、前記二次トランザクション識別子のそれぞれに対応する、リーフ層、ii)複数の内部ハッシュをそれぞれ含む一つまたは複数の内部層であって、各内部層における各内部ハッシュは、下位層からの少なくとも2つのハッシュの連結をハッシュすることによって生成され、該一つまたは複数の内部層のうち最下位の内部層の各内部ハッシュは、少なくとも2つの異なるリーフ・ハッシュの連結をハッシュすることによって生成される、内部層、およびiii)前記二次ブロック識別子を含むルート層を含み、前記二次ブロック識別子は、前記一つまたは複数の内部層のうち最上位の内部層の内部ハッシュの連結をハッシュすることによって生成される、ステップと;前記二次ブロック識別子が前記候補二次ブロック識別子と一致するかどうかを検証するステップとを含む。
【0222】
第45の任意的な具体化によれば、第44の具体化に従った方法であって、前記取得することが:前記候補二次ブロック識別子をブロックチェーン・ネットワークのノードから受信すること;前記候補二次ブロック識別子を前記ブロックチェーン・ネットワークの外部のノードから受信すること;および前記候補二次ブロック識別子を前記ブロックチェーンのブロックのトランザクションから抽出することと、のうちの一つまたは複数を含んでいてもよい、方法が提供されてもよい。
【0223】
本明細書に開示された教示の第46の具体化によれば、一つまたは複数のメモリユニットを備えるメモリと、一つまたは複数の処理ユニットを備える処理装置とを備えるコンピュータ設備であって、前記メモリは、前記処理装置上で動作するように構成されたコードを記憶し、該コードは、前記処理装置上で実行されたときに、第44ないし第45の具体化のいずれかの方法を実行するように構成される、コンピュータ設備が提供される。
【0224】
本明細書に開示された教示の第47の具体化によれば、コンピュータ設備上で実行されたときに第44ないし第45の具体化のいずれかの方法を実行するように構成された、コンピュータ読み取り可能記憶装置上に具現されたコンピュータ・プログラムが提供される。
【0225】
本明細書に開示された教示の第48の具体化によれば、ブロックチェーンのブロックが候補データ・フィールドを含むターゲット・トランザクションを含むかどうかを判定する、コンピュータ実装される方法が提供される。前記ブロックは前記ターゲット・トランザクションを含むトランザクションの集合を含み、本方法は、照会ユーザーによって実行され:i)前記候補データ・フィールドのハッシュである候補リーフ・ハッシュ、ii)前記ターゲット・トランザクションの候補二次トランザクション識別子、およびiii)前記候補データ・フィールドについての認証経路を取得するステップと;i)、ii)およびiii)を使用してハッシュ木証明を実行して二次トランザクション識別子を生成するステップと;iv)候補二次ブロック識別子、およびv)該候補二次ブロック識別子についての認証経路を取得するステップと;iv)、v)および生成された二次トランザクション識別子を使用してハッシュ木証明を実行して、二次ブロック識別子を生成するステップと;vi)前記ターゲット・トランザクションの候補一次トランザクション識別子、vii)前記トランザクションの集合を含む前記ブロックの候補一次ブロック識別子、およびviii)該一次ブロック識別子についての認証経路を取得するステップと;vi)、vii)、およびviii)を用いてハッシュ木証明を実行して、一次ブロック識別子を生成するステップとを含み、前記判定は:a)生成された二次トランザクション識別子が候補二次トランザクション識別子と一致するかどうか、b)生成された二次ブロック識別子が候補二次ブロック識別子と一致するかどうか、およびc)生成された一次ブロック識別子が候補一次ブロック識別子と一致するかどうかに基づく。
【0226】
第49の任意的な具体化によれば、第48の具体化に従った方法であって、前記判定がさらに、前記トランザクションの集合を含む前記ブロックが、前記候補一次ブロック識別子および前記候補二次ブロック識別子を含むかどうかに基づいていてもよい、方法が提供されてもよい。
【0227】
本明細書に開示された教示の第50の具体化によれば、一つまたは複数のメモリユニットを備えるメモリと、一つまたは複数の処理ユニットを備える処理装置とを備えるコンピュータ設備であって、前記メモリは、前記処理装置上で動作するように構成されたコードを記憶し、該コードは、前記処理装置上で実行されたときに、第48ないし第49の具体化のいずれかの方法を実行するように構成される、コンピュータ設備が提供される。
【0228】
本明細書に開示された教示の第51の具体化によれば、コンピュータ設備上で実行されたときに第48ないし第49の具体化のいずれかの方法を実行するように構成された、コンピュータ読み取り可能記憶装置上に具現されたコンピュータ・プログラムが提供される。
【0229】
本明細書に開示される別の具体化によれば、生成ユーザー、照会ユーザー、関与しうる任意の第三者、およびノードの前記ネットワークの前記動作を含む方法が提供されてもよい。
【0230】
本明細書に開示される別の具体化によれば、生成ユーザーのコンピュータ設備、コミット・ユーザーのコンピュータ設備、検証ユーザーのコンピュータ設備、照会ユーザーのコンピュータ設備、任意の第三者のコンピュータ設備、およびノードの前記ネットワークを含むシステムが提供されてもよい。
【0231】
開示された技法の他の変形または使用事例が、ひとたび本明細書の開示を与えられれば、当業者に明白になりうる。本開示の範囲は、記載された実施形態によって限定されるものではなく、添付の特許請求の範囲によってのみ限定される。
図1
図2
図3
図4
図5
図6
図7
図8
図9