特表 2024-515259 ユニフォームリソース識別子

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

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

(11)【公表番号】

(43)【公表日】2024-04-08

(54)【発明の名称】ユニフォームリソース識別子

(51)【国際特許分類】

   G06F 16/22 20190101AFI20240401BHJP

【ＦＩ】

G06F16/22

【審査請求】未請求

【予備審査請求】未請求

(21)【出願番号】P 2023561814

(86)(22)【出願日】2022-03-08

(85)【翻訳文提出日】2023-10-06

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

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

(87)【国際公開日】2022-10-13

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

(32)【優先日】2021-04-08

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

(81)【指定国・地域】

(71)【出願人】

【識別番号】318001991

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

(74)【代理人】

【識別番号】100108453

【弁理士】

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

(74)【代理人】

【識別番号】100110364

【弁理士】

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

(74)【代理人】

【識別番号】100133400

【弁理士】

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

(72)【発明者】

【氏名】クレイグ・スティーヴン・ライト

(72)【発明者】

【氏名】アレクサンダー・グレアム

(72)【発明者】

【氏名】ジャック・オーウェン・デイヴィーズ

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

5B175

【Ｆターム（参考）】

5B175AA02

5B175DA01

5B175KA04

(57)【要約】

本発明の第1の態様によれば、特定されたトランザクションがブロックチェーンに記憶されていることを検証するためのコンピュータで実施される方法が提供される。ブロックチェーンユニフォームリソースインジケータ(BURI)文字列が取得される。BURI文字列は、その中の区切り文字を特定するために構文解析され、それにより区切り文字によって分離されている1つまたは複数のマークル証明部分およびトランザクション識別子部分を抽出し、マークル証明部分は、特定されたトランザクションが特定されたブロックに属することを検証するためのものである。BURIの少なくとも一部が、マークル根ハッシュを取得するために使用される。マークル証明部分は、トランザクション識別子部分がマークル根ハッシュに対して有効であるかどうかを決定するために使用され、それにより、特定されたブロックのペイロードにアクセスすることなく、BURI文字列を使用して特定されたトランザクションを検証する。

【特許請求の範囲】

【請求項1】

特定されたトランザクションがブロックチェーンに記憶されていることを検証するためのコンピュータで実施される方法であって、前記方法が、
ブロックチェーンユニフォームリソースインジケータ(BURI)文字列を取得するステップと、
前記BURI文字列を構文解析して、その中の区切り文字を特定し、それにより前記区切り文字によって分離されている1つまたは複数のマークル証明部分およびトランザクション識別子部分を抽出するステップであって、前記マークル証明部分が、前記特定されたトランザクションが特定されたブロックに属することを検証するためのものである、ステップと、
前記BURIの少なくとも一部を使用して、マークル根ハッシュを取得するステップと、
前記マークル証明部分を使用して、前記トランザクション識別子部分が前記マークル根ハッシュに対して有効であるかどうかを決定し、それにより、前記特定されたブロックのペイロードにアクセスすることなく、前記BURI文字列を使用して前記特定されたトランザクションを検証するステップとを備える、方法。

【請求項2】

前記BURI文字列が、前記ブロックチェーンに記憶されている後続のトランザクションにおいて受信されるまたはそれから抽出される、請求項1に記載の方法。

【請求項3】

前記1つまたは複数のマークル証明部分が前記特定されたトランザクションのマークルインデックスを備える、請求項1または2に記載の方法。

【請求項4】

前記1つまたは複数のマークル証明部分が、前記特定されたトランザクションが前記マークル根ハッシュによって検証されるかどうかを決定するために必要とされるマークル証明ハッシュのサブセットをさらに備える、請求項3に記載の方法。

【請求項5】

前記方法が、第三者コンピューティングデバイスから、前記特定されたトランザクションが前記マークル根ハッシュによって検証されるかどうかを決定するために必要とされるマークル証明ハッシュのサブセットを取得するステップであって、
前記第三者コンピューティングデバイスに、前記マークルインデックスおよび前記トランザクション識別子部分を送信するステップと、
前記第三者コンピューティングデバイスから、前記特定されたトランザクションが前記マークル根ハッシュによって検証されるかどうかを決定するために必要とされるマークル証明ハッシュの前記サブセットを受信するステップとを実施することによって、取得するステップをさらに備える、請求項3に記載の方法。

【請求項6】

前記第三者コンピューティングデバイスが、それぞれのブロックチェーントランザクションのそれぞれのブロックチェーントランザクション識別子のトランザクション識別子のセットを記憶するが、ブロックチェーンネットワークに新しいブロックチェーンブロックを公開しないように構成されるマークル証明エンティティである、請求項5に記載の方法。

【請求項7】

前記マークルインデックスが2進形式である、請求項3または請求項3に従属するいずれか1項に記載の方法。

【請求項8】

前記BURI文字列を構文解析して、その中の区切り文字を特定する前記ステップが、それによりブロック識別部分をさらに抽出する、請求項1から7のいずれか一項に記載の方法。

【請求項9】

参照ブロックチェーントランザクションであって、前記参照ブロックチェーントランザクションの第1のインデックスにおける出力に、特定されたブロックにブロックチェーン上で以前に記憶された特定されたトランザクションを参照するためのブロックチェーンユニフォームリソースインジケータ(BURI)文字列を備え、前記BURIがトランザクション識別子部分およびさらなる部分を備え、前記トランザクション識別子部分および前記さらなる部分が少なくとも1つの区切り文字によって分離されており、前記さらなる部分が前記特定されたトランザクションをさらに定義するための階層的構成要素である、参照ブロックチェーントランザクション。

【請求項10】

前記さらなる部分が、少なくとも1つの区切り文字によって前記トランザクション識別子部分から分離されている、1つまたは複数のマークル証明部分を備える、請求項9に記載の参照ブロックチェーントランザクション。

【請求項11】

前記1つまたは複数のマークル証明部分が前記特定されたブロックにおける前記特定されたトランザクションのマークルインデックスを備える、請求項10に記載の参照ブロックチェーントランザクション。

【請求項12】

前記1つまたは複数のマークル証明部分が、前記特定されたトランザクションが前記特定されたブロックのマークル根ハッシュによって検証されるかどうかを決定するために必要とされるマークル証明ハッシュのサブセットをさらに備える、請求項11に記載の参照ブロックチェーントランザクション。

【請求項13】

前記マークルインデックスが2進形式である、請求項11または12に記載の参照ブロックチェーントランザクション。

【請求項14】

前記マークルインデックスの各2進数字が、ハッシュの順序付けられたリストのうちの対応するハッシュにプリペンドされる、請求項12または13に記載の参照ブロックチェーントランザクション。

【請求項15】

ブロック識別部分が前記特定されたブロックのブロック番号である、請求項9から14のいずれか一項に記載の参照ブロックチェーントランザクション。

【請求項16】

ブロック識別部分が前記特定されたブロックのブロックヘッダハッシュである、請求項9から14のいずれか一項に記載の参照ブロックチェーントランザクション。

【請求項17】

前記BURIが、少なくとも1つの区切り文字によって前記トランザクション識別子部分および1つまたは複数のマークル証明部分から分離されている、ブロック特定部分をさらに備える、請求項10から16のいずれか一項に記載の参照ブロックチェーントランザクション。

【請求項18】

前記BURIが、前記特定されたトランザクションのフラグメントを特定するためのフラグメント部分をさらに備える、請求項9から17のいずれか一項に記載の参照ブロックチェーントランザクション。

【請求項19】

特定されたトランザクションに記憶されているデータを検証エンティティに通信するコンピュータで実施される方法であって、前記方法が、
区切り文字によって分離されている1つまたは複数のマークル証明部分およびトランザクション識別子部分を備えるブロックチェーンユニフォームリソースインジケータ(BURI)文字列を生成するステップであって、前記マークル証明部分が、前記特定されたトランザクションが特定されたブロックに属することを検証するためのものである、ステップと、
前記データにアクセスするための前記検証エンティティに前記BURIを利用可能にするステップとを備える、方法。

【請求項20】

前記BURIを利用可能にする前記ステップが、前記BURIをブロックチェーンのトランザクションに記憶するステップを備える、請求項19に記載のコンピュータで実施される方法。

【請求項21】

前記1つまたは複数のマークル証明部分が前記特定されたトランザクションのマークルインデックスを備える、請求項19または20に記載のコンピュータで実施される方法。

【請求項22】

前記1つまたは複数のマークル証明部分が、前記特定されたトランザクションがマークル根ハッシュによって検証されるかどうかを決定するために必要とされるマークル証明ハッシュのサブセットをさらに備える、請求項21に記載のコンピュータで実施される方法。

【請求項23】

1つまたは複数のメモリユニットを備えるメモリと、
1つまたは複数の処理ユニットを備える処理装置とを備え、前記メモリが、前記処理装置上で実行するようになされるコードを記憶し、前記コードが、前記処理装置上で実行されると、請求項1から8のいずれか一項または請求項19から22のいずれか一項の方法を実行するように構成される、コンピュータ機器。

【請求項24】

コンピュータ可読ストレージ上に具現化され、1つまたは複数のプロセッサ上で実行されると、請求項1から8のいずれか一項または請求項19から22のいずれか一項の方法を実行するように構成される、コンピュータプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、概して相互関連するブロックチェーントランザクションを記憶、検証または別様に管理するための技法に関する。本技法は、オフチェーンとオンチェーンの両方の用途を有する。

【背景技術】

【0002】

ブロックチェーンとは、ある形式の分散型データ構造を指し、ブロックチェーンの複製は、分散型ピアツーピア(P2P)ネットワーク(以下では「ブロックチェーンネットワーク」と呼ばれる)の中の複数のノードの各々において維持され、広く公開される。ブロックチェーンは、データのブロックのチェーンを備え、各ブロックは、1つまたは複数のトランザクションを備える。いわゆる「コインベーストランザクション」以外の各トランザクションは、1つまたは複数のコインベーストランザクションまで戻る1つまたは複数のブロックにまたがり得るシーケンスの中の先行するトランザクションを指し示す。コインベーストランザクションは以下でさらに論じられる。ブロックチェーンネットワークに出されるトランザクションは、新しいブロックに含まれる。新しいブロックは「マイニング」と呼ばれることが多い処理により作成され、これは、複数のノードの各々が競争して「プルーフオブワーク」を実行すること、すなわち、ブロックチェーンの新しいブロックに含められることを待機している、順序付けられ妥当性確認された未処理のトランザクションの定められたセットの表現に基づいて、暗号パズルを解くことを伴う。ブロックチェーンは一部のノードにおいて枝刈りされてもよく、ブロックの公開はブロックヘッダだけの公開により達成され得ることに留意されたい。

【0003】

ブロックチェーンにおけるトランザクションは、デジタル資産(すなわち、ある数のデジタルトークン)を運ぶこと、仮想化された台帳もしくは登録簿の仕訳のセットを順序付けること、タイムスタンプエントリを受信して処理すること、および/またはインデックスポインタを時間的に順序付けることという、目的のうちの1つまたは複数のために使用され得る。ブロックチェーンは、ブロックチェーンに追加の機能を重ねるためにも利用され得る。たとえば、ブロックチェーンプロトコルは、トランザクションにおける追加のユーザデータまたはデータに対するインデックスの記憶を可能にし得る。単一のトランザクションに記憶され得る最大のデータ容量にはあらかじめ指定された限界はないので、ますます複雑になるデータを組み込むことができる。たとえば、これは、ブロックチェーンの中の電子文書、またはオーディオデータもしくはビデオデータを記憶するために使用され得る。

【0004】

ブロックチェーンネットワークのノード(「マイナー」と呼ばれることが多い)は、後でより詳しく説明される、分散型のトランザクションの登録および検証のプロセスを実行する。要約すると、この処理の間に、ノードはトランザクションを妥当性確認し、それらをブロックテンプレートに挿入し、ノードはそのブロックテンプレートについて有効なプルーフオブワークの解を特定することを試みる。有効な解が見つかると、新しいブロックがネットワークの他のノードに広められるので、各ノードがブロックチェーンに新しいブロックを記録することを可能にする。トランザクションがブロックチェーンに記録されるようにするために、ユーザ(たとえば、ブロックチェーンクライアントアプリケーション)は、トランザクションが広められるように、それをネットワークのノードのうちの1つに送信する。トランザクションを受信するノードは競って、妥当性確認されたトランザクションを新しいブロックへ組み込むプルーフオブワークの解を見つけることができる。各ノードは同じノードプロトコルを実施するように構成され、これは、トランザクションが有効になるための1つまたは複数の条件を含む。無効なトランザクションは、広められることも、ブロックに組み込まれることもない。トランザクションが妥当性確認され、それによりブロックチェーン上で受け入れられると仮定すると、トランザクション(あらゆるユーザデータを含む)は、イミュータブルな公開記録としてブロックチェーンネットワークの中のノードの各々において登録されインデクシングされたままになる。

【0005】

最新のブロックを作成するためにプルーフオブワークパズルを解くことに成功したノードは通常、ある額のデジタル資産、すなわちある数のトークンを分配する「コインベーストランザクション」と呼ばれる新しいトランザクションにより報酬を受ける。無効なトランザクションの検出および拒絶は、ネットワークのエージェントとして活動し不正を報告して阻止する動機のある、競合するノードの活動によって実施される。情報を広く公開することで、ユーザはノードの実績を継続的に監査することが可能になる。ブロックヘッダのみの公開により、参加者はブロックチェーンの完全性が継続中であることを確実にすることが可能になる。

【0006】

「出力ベース」モデル(UTXOベースのモデルと呼ばれることがある)では、所与のトランザクションのデータ構造は、1つまたは複数の入力および1つまたは複数の出力を備える。あらゆる消費可能な出力は、トランザクションの先行するシーケンスから導出可能であるデジタル資産の額を指定する要素を備える。消費可能な出力は、UTXO(「未消費トランザクション出力」)と呼ばれることがある。出力はさらに、出力のさらなる引き換えのための条件を指定するロッキングスクリプトを備え得る。ロッキングスクリプトは、デジタルトークンまたは資産を妥当性確認して移すために必要な条件を定義する述部である。トランザクション(コインベーストランザクション以外)の各入力は、先行するトランザクションにおけるそのような出力へのポインタ(すなわち、参照)を備え、指し示された出力のロッキングスクリプトをアンロックするためのアンロッキングスクリプトをさらに備え得る。よって、トランザクションのペアを考え、それらを第1のトランザクションおよび第2のトランザクション(または「標的」トランザクション)と呼ぶ。第1のトランザクションは、デジタル資産の額を指定し、出力をアンロッキングする1つまたは複数の条件を定義するロッキングスクリプトを備える、少なくとも1つの出力を備える。第2の標的トランザクションは、第1のトランザクションの出力へのポインタと、第1のトランザクションの出力をアンロックするためのアンロッキングスクリプトとを備える、少なくとも1つの入力を備える。

【0007】

そのようなモデルでは、第2の標的トランザクションが、ブロックチェーンにおいて広められて記録されるようにブロックチェーンネットワークに送信されるとき、各ノードにおいて適用される有効性の基準の1つは、アンロッキングスクリプトが第1のトランザクションのロッキングスクリプトにおいて定義される1つまたは複数の条件のすべてを満たすというものである。別の基準は、第1のトランザクションの出力が別のより前の有効なトランザクションによってまだ引き換えられていないということである。これらの条件のいずれかに従って標的トランザクションが無効であることを見出したいずれのノードも、トランザクションを広めず(場合によっては無効なトランザクションを登録するために有効なトランザクションとして広めない)、またブロックチェーンに記録されるべき新しいブロックにトランザクションを含めない。

【0008】

代替のタイプのトランザクションモデルは、アカウントベースのモデルである。この場合、各トランザクションは、過去のトランザクションのシーケンスの中の先行するトランザクションのUTXOを参照することによってではなく、絶対的なアカウント残高を参照することによって、移されるべき額を定義する。すべてのアカウントの現在の状態が、ブロックチェーンとは別に、ノードによって記憶され、定期的に更新される。

【発明の概要】

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

【0009】

本発明の第1の態様によれば、特定されたトランザクションがブロックチェーンに記憶されていることを検証するためのコンピュータで実施される方法が提供される。ブロックチェーンユニフォームリソースインジケータ(BURI)文字列が取得される。BURI文字列は、その中の区切り文字を特定するために構文解析され、それにより区切り文字によって分離されている1つまたは複数のマークル証明部分およびトランザクション識別子部分を抽出し、マークル証明部分は、特定されたトランザクションが特定されたブロックに属することを検証するためのものである。BURIの少なくとも一部が、マークル根ハッシュを取得するために使用される。マークル証明部分は、トランザクション識別子部分がマークル根ハッシュに対して有効であるかどうかを決定するために使用され、それにより、特定されたブロックのペイロードにアクセスすることなく、BURI文字列を使用して特定されたトランザクションを検証する。

【0010】

BURIによって提供されるブロックチェーントランザクションに対する階層的参照方式により、ユーザはトランザクションを参照し、そしてBURIに含まれる階層情報を使用して、参照されたトランザクションが実際にブロックチェーンに関与していることを効率的に検証することが可能になる。

【0011】

URIは、階層的名前空間を定義するために、たとえばワールドワイドウェブにおいて、長く使用されてきた。本明細書で説明されるようにブロックチェーントランザクションを参照するためにURIが使用される新規な方法は、参照されたトランザクションがブロックチェーンに関与していることを検証するための効率的な手段を提供する。BURIは、マークル根を計算し、前記計算された根がブロックチェーン上に記憶されているトランザクションのマークル根と同じであることを検証するために必要とされる情報を提供する。URI形式は、階層内のあらゆる任意のレベルにおけるリソースを参照するために最適化される。ここで、その構造は、ブロックチェーントランザクションを一意に参照するためだけでなく、参照されたトランザクションの効率的な検証を容易にするようにマークル証明の必要とされる階層要素を伝えるためにも活かされる。

【0012】

本開示の実施形態の理解を助けるために、およびそのような実施形態がどのように具体化され得るかを示すために、単なる例として、添付の図への参照が行われる。

【図面の簡単な説明】

【0013】

【図1】ブロックチェーンを実装するためのシステムの概略ブロック図である。

【図2】ブロックチェーンに記録され得るトランザクションのいくつかの例を概略的に示す図である。

【図3A】クライアントアプリケーションの概略ブロック図である。

【図3B】図3Aのクライアントアプリケーションによって提示され得る例示的なユーザインターフェースの概略的なモックアップの図である。

【図4】トランザクションを処理するためのあるノードソフトウェアの概略ブロック図である。

【図5】例示的なマークル木を概略的に示す図である。

【図6】例示的なマークル証明を概略的に示す図である。

【図7】第三者がマークル証明を提供する本発明のいくつかの実施形態による例示的なシステムを概略的に示す図である。

【図8】マークル証明がブロックチェーンユニフォーム参照識別子において提供される本発明のいくつかの実施形態による例示的な方法を示す図である。

【図9】参照トランザクションにおけるブロックチェーンユニフォーム参照識別子を使用してデータを参照することを示す概略図である。

【図10】ブロックチェーンユニフォーム参照識別子およびブロックチェーン上に記憶されるブロックの対応する構成要素を概略的に示す図である。

【図11】マークル証明がブロックチェーンユニフォーム参照識別子を使用して要求される本発明のいくつかの実施形態による例示的な方法を示す図である。

【図12】本発明のいくつかの実施形態によるマークル証明エンティティによって記憶されるデータを概略的に示す図である。

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

【0014】

ブロックチェーンユニフォームリソース識別子(BURI)は、同じ内容に基づく複数の関係者の間の対話を容易にするために使用され得る。

【0015】

BURIは、それがマークル証明検証を実行するために必要とされる情報(すなわちハッシュの順序付けられたリストおよびトランザクションインデックス)のすべてを含むように設計することができ、これによりユーザは、ある内容データに対する存在の証明を、そのデータを参照するBURIだけに基づいて独立して検証することが可能になる。

【0016】

BURIの1つの利点は、それにより、既存のオンチェーンデータとのあらゆる対話が、データ自体を複製するのではなく、それを参照することによって実行されることを可能にすることによって、データの複製を回避するということであり、これは、ソーシャルネットワークなどのオンチェーンコンテンツ指向のアプリケーションを実施するために空間および費用効率が高い。

【0017】

第2の利点は、ユーザ独立対リンク自体の空間効率のトレードオフがありながらも、異なる文脈で異なる形式のBURIが使用されることを可能にするようにBURIスキーマが柔軟であるということである。それにより、ユーザは、各BURIがマークル証明検証を実行するためのすべての情報を含むべきかまたはユーザが第三者からその情報を回収するのに十分な情報だけを含むべきかを選ぶことが可能になる。前者は完全独立を可能にするがコンパクトでなく、他方は、マークル証明データを扱うために第三者に頼ることに依存するが、BURIをオンチェーンで含むコストを削減する。

【0018】

例示的なシステムの概要
図1は、ブロックチェーン150を実装するための例示的なシステム100を示す。システム100は、通常はインターネットなどのワイドエリアインターネットワークである、パケット交換ネットワーク101を備え得る。パケット交換ネットワーク101は、パケット交換ネットワーク101内でピアツーピア(P2P)ネットワーク106を形成するように並べられ得る複数のブロックチェーンノード104を備える。示されていないが、ブロックチェーンノード104は準完全グラフとして並べられ得る。したがって、各ブロックチェーンノード104は、他のブロックチェーンノード104に高度に接続される。

【0019】

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

【0020】

ブロックチェーン150はデータのブロック151のチェーンを備え、ブロックチェーン150のそれぞれのコピーが、分散ネットワークまたはブロックチェーンネットワーク101の中の複数のブロックチェーンノード104の各々において維持される。上で言及されたように、ブロックチェーン150のコピーを維持することは、ブロックチェーン150を完全に記憶することを必ずしも意味しない。代わりに、ブロックチェーン150は、各ブロックチェーンノード150が各ブロック151のブロックヘッダ(以下で論じられる)を記憶する限り、データを枝刈りされ得る。チェーンの中の各ブロック151は1つまたは複数のトランザクション152を備え、この文脈においてトランザクションはある種のデータ構造を指す。データ構造の性質は、トランザクションモデルまたはスキームの一部として使用されるトランザクションプロトコルのタイプに依存する。所与のブロックチェーンは、1つの特定のトランザクションプロトコルを全体で使用する。ある一般的なタイプのトランザクションプロトコルにおいて、各トランザクション152のデータ構造は、少なくとも1つの入力および少なくとも1つの出力を備える。各出力は、ある数量のデジタル資産を表す額を財産として指定し、その例は、出力が暗号によりにロックされる対象であるユーザ103である(アンロック、および引き換えまたは消費のために、そのユーザの署名または他のソリューションを必要とする)。各入力は、先行するトランザクション152の出力を指し示し、それによりそれらのトランザクションをつなぐ。

【0021】

各ブロック151はまた、ブロック151に対する逐次的な順序を定義するために、チェーンの中の以前に作成されたブロック151を指し示すブロックポインタ155を備える。各トランザクション152(コインベーストランザクション以外)は、トランザクションのシーケンスに対する順序を定義するために、以前のトランザクションへのポインタを備える(トランザクション152のシーケンスは分岐することが許容されることに留意されたい)。ブロック151のチェーンは、チェーンにおいて最初のブロックであったジェネシスブロック(Gb)153まで戻る。チェーン150の初期の1つまたは複数の元のトランザクション152は、先行するトランザクションではなくジェネシスブロック153を指し示していた。

【0022】

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

【0023】

所与の現在のトランザクション152jにおいて、入力(または各入力)は、トランザクションのシーケンスの中の先行するトランザクション152iの出力を参照するポインタを備え、これは、この出力が現在のトランザクション152jにおいて引き換えられる、または「消費される」ことになることを指定する。一般に、先行するトランザクションは、順序付けられたセット154または任意のブロック151における任意のトランザクションであり得る。先行するトランザクション152iは、現在のトランザクション152iが作成される時点で、またはネットワーク106に送信される時点ですら、必ずしも存在する必要はないが、現在のトランザクションが有効になるためには、先行するトランザクション152iが存在して妥当性確認される必要がある。したがって、本明細書における「先行する」は、ポインタにより連結される論理シーケンスにおいて先行するものを指し、時間的な順序における作成または送信の時間を必ずしも指さず、したがって、トランザクション152i、152jが順不同で作成または送信されることを必ずしも排除しない(オーファントランザクションについての以下の議論を参照)。先行するトランザクション152iは同様に、祖先トランザクションまたは先行者トランザクションと呼ばれ得る。

【0024】

現在のトランザクション152jの入力はまた、入力承認、たとえば、先行するトランザクション152iの出力がロックされる対象であるユーザ103aの署名を備える。そして、現在のトランザクション152jの出力は、新しいユーザまたはエンティティ103bに暗号によりロックされ得る。したがって、現在のトランザクション152jは、現在のトランザクション152jの出力において定義されるような新しいユーザまたはエンティティ103bに、先行するトランザクション152iの入力において定義される額を移すことができる。いくつかの場合、トランザクション152は、複数のユーザまたはエンティティ(そのうちの1つは、残金を与えるために元のユーザまたはエンティティ103aであり得る)の間で入力の額を分割するために、複数の出力を有し得る。いくつかの場合、トランザクションはまた、1つまたは複数の先行するトランザクションの複数の出力からの額を一緒に集めて、現在のトランザクションの1つまたは複数の出力を再分配するために、複数の入力を有し得る。

【0025】

ビットコインなどの出力ベースのトランザクションプロトコルによれば、個々のユーザまたは組織などの関係者103が、新しいトランザクション152jを(手動で、または関係者により利用される自動化されたプロセスによってのいずれかで)規定することを望むとき、規定する関係者は、自身のコンピュータ端末102から受信者に新しいトランザクションを送信する。規定する関係者または受信者は最終的に、このトランザクションをネットワーク106のブロックチェーンノード104(これは今日では通常はサーバまたはデータセンターであるが、原理的には他のユーザ端末であってもよい)のうちの1つまたは複数に送信する。新しいトランザクション152jを実施する関係者103がトランザクションをブロックチェーンノード104のうちの1つまたは複数に直接送信でき、いくつかの例では受信者に送信できないことも、排除されない。トランザクションを受信するブロックチェーンノード104は、ブロックチェーンノード104の各々において適用されるブロックチェーンノードプロトコルに従って、トランザクションが有効であるかどうかを確認する。ブロックチェーンノードプロトコルは通常、新しいトランザクション152jの中の暗号署名が予想される署名と一致することをブロックチェーンノード104が確かめることを必要とし、予想される署名は、トランザクション152の順序付けられたシーケンスの中の以前のトランザクション152iに依存する。そのような出力ベースのトランザクションプロトコルでは、これは、新しいトランザクション152jの入力に含まれる関係者103の暗号署名または他の承認が、新しいトランザクションが割り当てる先行するトランザクション152iの出力において定義される条件と一致することを確かめることを備えることがあり、この条件は通常、新しいトランザクション152jの入力の中の暗号署名または他の承認が、新しいトランザクションの入力がつなげられる以前のトランザクション152iの出力をアンロックすることを、少なくとも確かめることを備える。この条件は、先行するトランザクション152iの出力に含まれるスクリプトによって少なくとも部分的に定義され得る。代替として、それは単純にブロックチェーンノードプロトコルだけによって固定されてもよく、または、それはこれらの組合せによるものであってもよい。いずれにしても、新しいトランザクション152jが有効である場合、ブロックチェーンノード104は、それをブロックチェーンネットワーク106の中の1つまたは複数の他のブロックチェーンノード104に転送する。これらの他のブロックチェーンノード104は、同じブロックチェーンノードプロトコルに従って同じ試験を適用し、新しいトランザクション152jを1つまたは複数のさらなるノード104に転送するなどする。このようにして、新しいトランザクションが、ブロックチェーンノード104のネットワーク全体に広められる。

【0026】

出力ベースのモデルにおいて、所与の出力(たとえば、UTXO)が割り当てられる(たとえば、消費される)かどうかの定義は、それがブロックチェーンノードプロトコルに従って別の前方のトランザクション152jの入力によりすでに有効に引き換えられているかどうかである。トランザクションが有効になるための別の条件は、そのトランザクションが割り当てることまたは引き換えることを試みる先行するトランザクション152iの出力が、別のトランザクションによってまだ引き換えられていないことである。やはり、有効ではない場合、トランザクション152jは、ブロックチェーン150において広められず(無効であるものとしてフラグを立てられて警告のために広められない限り)、または記録されない。これは、取引者が同じトランザクションの出力を一度より多く割り当てることを試みるような、二重消費から守る。一方、アカウントベースのモデルは、アカウント残高を維持することによって二重消費から守る。やはり、トランザクションの定められた順序があるので、アカウント残高は任意のある時間において単一の定められた状態を有する。

【0027】

トランザクションを検証することに加えて、ブロックチェーンノード104はまた、マイニングと一般に呼ばれるプロセスにおいて、トランザクションのブロックを最初に作成するのを競い、これは「プルーフオブワーク」により支援される。ブロックチェーンノード104において、新しいトランザクションは、ブロックチェーン150に記録されているブロック151にまだ表れていない有効なトランザクションの順序付けられたプール154に追加される。そして、ブロックチェーンノードは、暗号パズルを解こうとすることによって、トランザクションの順序付けられたセット154からトランザクション152の新しい有効なブロック151を競って組み立てる。通常、これは、「ノンス」が未処理のトランザクションの順序付けられたプール154の表現と連結されてハッシュされると、ハッシュの出力が所定の条件を満たすような、ノンス値を探すことを備える。たとえば、所定の条件は、ハッシュの出力がある定められた数の先頭の0を有するということであり得る。これは、プルーフオブワークパズルの1つの具体的なタイプにすぎず、他のタイプが排除されないことに留意されたい。ハッシュ関数の性質は、それがその入力に関して予測不可能な出力を有するというものである。したがって、この探索は、ブルートフォースによってのみ実行することができるので、パズルを解こうとしている各ブロックチェーンノード104において大量の処理リソースを消費する。

【0028】

パズルを解こうとする第1のブロックチェーンノード104は、これをネットワーク106に告知し、ネットワークの中の他のブロックチェーンノード104によって容易に確かめられ得る証明として解を提供する(ハッシュへの解が与えられると、それによりハッシュの出力が条件を満たすようになることを確かめるのは単純である)。第1のブロックチェーンノード104は、ブロックを受け入れしたがってプロトコルルールを実施する、他のノードの閾値コンセンサスにブロックを広める。トランザクションの順序付けられたセット154は次いで、ブロックチェーンノード104の各々によってブロックチェーン150の中の新しいブロック151として記録されるようになる。ブロックポインタ155はまた、チェーンの中の以前に作成されたブロック151n-1を指し示す新しいブロック151nに割り当てられる。プルーフオブワークの解を作成するために必要とされる、たとえばハッシュの形式のこの大量の労力は、ブロックチェーンプロトコルのルールに従うという第1のノードの104の意図を示すものである。そのようなルールは、以前に妥当性確認されたトランザクションと同じ出力を割り当てる場合(これは別様に二重消費として知られている)、有効であるものとしてトランザクションを受け入れないことを含む。作成されると、ブロック151を改変することはできず、それは、ブロック151が、ブロックチェーンネットワーク106の中のブロックチェーンノード104の各々において認識され維持されるからである。ブロックポインタ155はまた、逐次的な順序をブロック151に課す。トランザクション152は、ネットワーク106の中の各ブロックチェーンノード104において順序付けられるブロックに記録されるので、これはトランザクションのイミュータブルな公開台帳を提供する。

【0029】

任意の所与の時間において競ってパズルを解く異なるブロックチェーンノード104は、それらのブロックチェーンノードがいつ解の探索を始めたか、またはトランザクションが受信された順序に応じて、任意の所与の時間におけるまだ公開されていないトランザクション154のプールの異なるスナップショットに基づいて、競ってパズルを解いていることがあることに留意されたい。それぞれのパズルを最初に解いた者が、どのトランザクション152が次の新しいブロック151nに含まれるか、およびどの順序で含まれるかを定義し、公開されていないトランザクションの現在のプール154は更新される。ブロックチェーンノード104は次いで、公開されていないトランザクション154の新しく定義された順序付けられたプールからブロックを競って作成し続け、以下同様である。生じ得るあらゆる「フォーク」を解決するためのプロトコルも存在し、これは、2つのブロックチェーンノード104が互いに非常に短い時間内にパズルを解き、その結果、ブロックチェーンの矛盾する景色がノード104間で広められるようになる状況である。つまり、フォークの先端がより長く成長した方が、最終的なブロックチェーン150になる。同じトランザクションが両方のフォークに現れるので、これはネットワークのユーザまたはエージェントに影響しないはずであることに留意されたい。

【0030】

ビットコインブロックチェーン(および大半の他のブロックチェーン)では、新しいブロック104の構築に成功するノードは、追加の定められた量のデジタル資産を分配する新しい特別な種類のトランザクション(あるエージェントまたはユーザから別の者にある額のデジタル資産を移転するエージェント間またはユーザ間トランザクションではなく)において、追加の受け入れられる額のデジタル資産を新しく割り当てるための能力を与えられる。この特別なタイプのトランザクションは通常、「コインベーストランザクション」と呼ばれるが、「開始トランザクション」または「生成トランザクション」とも呼ばれることがある。それは通常、新しいブロック151nの最初のトランザクションを形成する。プルーフオブワークは、この特別なトランザクションが後で引き換えられることを可能にするプロトコルルールに従うという、新しいブロックを構築するノードの意図を示すものである。ブロックチェーンプロトコルルールは、この特別なトランザクションを引き換えられるようになるまで、成熟期間、たとえば100ブロックを必要とし得る。しばしば、通常の(非生成)トランザクション152はまた、そのトランザクションが公開されたブロック151nを作成したブロックチェーンノード104にさらに報酬を与えるために、その出力の1つにおいて追加のトランザクションフィーを指定する。この料金は普通は「トランザクションフィー」と呼ばれ、以下で論じられる。

【0031】

トランザクションの妥当性確認および公開に関与するリソースにより、典型的にはブロックチェーンノード104の少なくとも各々が、1つまたは複数の物理サーバユニットを備えるサーバという形態をとり、またはデータセンター全体という形態すらとる。しかしながら、原理的には、あらゆる所与のブロックチェーンノード104は、一緒にネットワーク接続されたユーザ端末またはユーザ端末のグループという形態をとり得る。

【0032】

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

【0033】

消費するユーザの役割を果たす複数の関係者103の各々のコンピュータ機器102も、ネットワーク101に接続される。これらのユーザは、ブロックチェーンネットワーク106と対話し得るが、トランザクションの検証またはブロックの構築には参加しない。これらのユーザまたはエージェント103の一部は、トランザクションにおいて送信者または受信者として活動し得る。他のユーザは、必ずしも送信者または受信者として活動することなく、ブロックチェーン150と対話し得る。たとえば、一部の関係者は、ブロックチェーン150のコピーを記憶する(たとえば、ブロックチェーンノード104からブロックチェーンのコピーを取得した)ストレージエンティティとして活動し得る。

【0034】

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

【0035】

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

【0036】

クライアントアプリケーション105は最初に、たとえばサーバからダウンロードされる、あるいは、リムーバブルSSD、フラッシュメモリキー、リムーバブルEEPROM、リムーバブル磁気ディスクドライブ、磁気フロッピーディスクもしくはテープ、CDもしくはDVD ROMなどの光学ディスク、またはリムーバブル光学ドライブなどの、リムーバブルストレージデバイス上で提供される、適切なコンピュータ可読記憶媒体上の任意の所与の関係者103のコンピュータ機器102に提供され得る。

【0037】

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

【0038】

注意:様々なクライアント機能は所与のクライアントアプリケーション105へと統合されるものとして説明されることがあるが、これは必ずしも限定するものではなく、代わりに、本明細書において説明されるあらゆるクライアント機能は、一連の2つ以上の別個の適用例、たとえばAPIを介してインターフェースすること、または一方が他方へのプラグインであることにおいて実装され得る。より一般的には、クライアント機能は、アプリケーション層、またはオペレーティングシステムなどのより低次の層、またはこれらの任意の組合せにおいて実装され得る。以下は、クライアントアプリケーション105に関して説明されるが、それは限定するものではないことが理解されるだろう。

【0039】

各コンピュータ機器102上のクライアントアプリケーションまたはソフトウェア105のインスタンスは、ネットワーク106のブロックチェーンノード104のうちの少なくとも1つに動作可能に結合される。これは、クライアント105のウォレット機能がトランザクション152をネットワーク106に送信することを可能にする。クライアント105はまた、それぞれの関係者103が受信者であるあらゆるトランザクションについてブロックチェーン150にクエリするために、ブロックチェーンノード104に連絡することも可能である(または、実施形態では、ブロックチェーン150が、公的な存在であることにより一部トランザクションに信用をもたらす公的機関であるので、実際にブロックチェーン150における他の関係者のトランザクションを調査する)。各コンピュータ機器102のウォレット機能は、トランザクションプロトコルに従ってトランザクション152を編成して送信するように構成される。上で述べられたように、各ブロックチェーンノード104は、ブロックチェーンノードプロトコルに従ってトランザクション152を妥当性確認し、ブロックチェーンネットワーク106全体にトランザクション152を広めるためにそれらを転送するように構成される、ソフトウェアを実行する。トランザクションプロトコルおよびノードプロトコルは互いに対応し、所与のトランザクションプロトコルは所与のノードプロトコルを伴い、一緒に所与のトランザクションモデルを実装する。ブロックチェーン150の中のすべてのトランザクション152に対して、同じトランザクションプロトコルが使用される。同じノードプロトコルが、ネットワーク106の中のすべてのノード104によって使用される。

【0040】

所与の関係者103、たとえばAliceが、新しいトランザクション152jをブロックチェーン150に含まれるように送信することを望むとき、彼女は関連するトランザクションプロトコルに従って(彼女のクライアントアプリケーション105のウォレット機能を使用して)新しいトランザクションを編成する。彼女は次いで、クライアントアプリケーション105から、彼女が接続されている1つまたは複数のブロックチェーンノード104に、トランザクション152を送信する。たとえば、これは、Aliceのコンピュータ102に最善に接続されるブロックチェーンノード104であり得る。任意の所与のブロックチェーンノード104が新しいトランザクション152jを受信するとき、ブロックチェーンノード104は、ブロックチェーンノードプロトコルおよびそのそれぞれの役割に従って、新しいトランザクション152jを扱う。これは、新しく受信されたトランザクション152jが「有効」であるための何らかの条件を満たすかどうかをまず確かめることを備え、その例がまもなくより詳しく論じられる。一部のトランザクションプロトコルでは、妥当性確認のための条件は、トランザクション152に含まれるスクリプトによってトランザクションごとに構成可能であり得る。代替として、この条件は単に、ノードプロトコルの内蔵機能であってもよく、またはスクリプトとノードプロトコルの組合せによって定義されてもよい。

【0041】

新しく受信されるトランザクション152jが有効であるものとして見なされるように試験に合格する条件(すなわち、それが「妥当性確認される」条件)のもとで、トランザクション152jを受信する任意のブロックチェーンノード104が、新しい妥当性確認されたトランザクション152をそのブロックチェーンノード104に維持されているトランザクションの順序付けられたセット154に追加する。さらに、トランザクション152jを受信するあらゆるブロックチェーンノード104は、妥当性確認されたトランザクション152以降をネットワーク106の中の1つまたは複数の他のブロックチェーンノード104に広める。各ブロックチェーンノード104は同じプロトコルを適用するので、トランザクション152jが有効であると仮定すると、これは、それがまもなくネットワーク106全体に広められることを意味する。

【0042】

所与のブロックチェーンノード104において維持される未処理のトランザクションの順序付けられたプール154の利用を認められると、そのブロックチェーンノード104は、新しいトランザクション152を含むそれぞれのプール154の最新のバージョンについてのプルーフオブワークパズルを競って解き始める(他のブロックチェーンノード104が、トランザクションの異なる順序付けられたセット154に基づいてパズルを解こうとしていることがあるが、最初にたどり着いた者が最新のブロック1511に含まれるトランザクションのセットを定義することを思い出されたい。最終的に、ブロックチェーンノード104は、Aliceのトランザクション152jを含む順序付けられたプール154の一部のためのパズルを解く)。プルーフオブワークが、新しいトランザクション152jを含むプール154に対して行われると、それはイミュータブルに、ブロックチェーン150の中のブロック151のうちの1つの一部になる。各トランザクション152は、より前のトランザクションへのポインタを備えるので、トランザクションの順序もイミュータブルに記録される。

【0043】

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

【0044】

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

【0045】

UTXOベースのモデル
図2は、例示的なトランザクションプロトコルを示す。これは、UTXOベースのプロトコルの例である。トランザクション152(「Tx」と省略される)は、ブロックチェーン150の基本データ構造である(各ブロック151は1つまたは複数のトランザクション152を備える)。以下は、出力ベースまたは「UTXO」ベースのプロトコルに言及して説明される。しかしながら、これはすべての可能な実施形態への限定ではない。例示的なUTXOベースのプロトコルはビットコインに言及して説明されるが、それは他の例示的なブロックチェーンネットワーク上で等しく実装され得ることに留意されたい。

【0046】

UTXOベースのモデルでは、各トランザクション(「Tx」)152は、1つまたは複数の入力202および1つまたは複数の出力203を備えるデータ構造を備える。各出力203は、未消費のトランザクション出力(UTXO)を備えてもよく、これは、別の新しいトランザクションの入力202のソースとして使用され得る(UTXOがまだ引き換えられていない場合)。UTXOは、デジタル資産の額を指定する値を含む。これは、分散型台帳上のある設定された数のトークンを表す。UTXOはまた、情報の中でもとりわけ、UTXOの由来であるトランザクションのトランザクションIDを含み得る。トランザクションデータ構造はヘッダ201も備えることがあり、これは入力フィールド202および出力フィールド203のサイズのインジケータを備えることがある。ヘッダ201はまた、トランザクションのIDを含むことがある。実施形態では、トランザクションIDは、トランザクションデータ(トランザクションID自体を除く)のハッシュであり、ノード104に出される生のトランザクション152のヘッダ201に記憶される。

【0047】

Alice 103aが、対象のある額のデジタル資産をBob 103bに移すトランザクション152jを作成することを望んでいるとする。図2において、Aliceの新しいトランザクション152jは「Tx₁」とラベリングされる。Tx₁は、シーケンスの中の先行するトランザクション152iの出力203においてAliceにロックされるデジタル資産の額をとり、その少なくとも一部をBobに移す。先行するトランザクション152iは、図2では「Tx₀」とラベリングされる。Tx₀およびTx₁は任意のラベルにすぎない。それらは、Tx₀がブロックチェーン151の最初のトランザクションであることを必ずしも意味せず、Tx₁がプール154の中のすぐ次のトランザクションであることも意味しない。Tx₁は、Aliceにロックされている未消費の出力203をまだ有するあらゆる先行する(すなわち、祖先)トランザクションを指し示し得る。

【0048】

先行するトランザクションTx₀は、Aliceが新しいトランザクションTx₁を作成するとき、または少なくとも彼女がそれをネットワーク106に送信するときにはすでに、ブロックチェーン150のブロック151において妥当性確認されそれに含まれていることがある。それは、その時点ですでにブロック151のうちの1つに含まれていることがあり、または、順序付けられたセット154においてまだ待機していることがあり、その場合、それは新しいブロック151にまもなく含められる。代替として、Tx₀およびTx₁は、一緒に作成されてネットワーク106に送信されてもよく、または、ノードプロトコルが「オーファン」トランザクションのバッファリングを許容する場合、Tx₀がTx₁の後に送信されることすらあってもよい。トランザクションのシーケンスの文脈で本明細書において使用される「先行する」および「後続の」という用語は、トランザクションにおいて指定されるトランザクションポインタによって定義されるようなシーケンスにおけるトランザクションの順序を指す(どのトランザクションがどの他のトランザクションを指し示すか、など)。それらは、「先行者」および「後継者」、または「祖先」および「子孫」、「親」および「子」などにより等しく置き換えられ得る。これは、それらが作成される順序、ネットワーク106に送信される順序、または任意の所与のブロックチェーンノード104に到達する順序を必ずしも示唆しない。それでも、先行するトランザクション(祖先トランザクションまたは「親」)を指し示す後続のトランザクション(子孫トランザクションまたは「子」)は、親トランザクションが妥当性確認されるまでは、かつ妥当性確認されない限り、妥当性確認されない。親より前にブロックチェーンノード104に到達する子は、オーファンであると見なされる。それは、ノードプロトコルおよび/またはノード挙動に応じて、廃棄され、または親を待機するためにある時間の間バッファリングされ得る。

【0049】

先行するトランザクションTx₀の1つまたは複数の出力203のうちの1つは、ここでUTXO₀とラベリングされる特定のUTXOを備える。各UTXOは、UTXOによって表されるデジタル資産の額を指定する値と、後続のトランザクションが妥当性確認されるようにするために、したがってUTXOの引き換えが成功するために、後続のトランザクションの入力202におけるアンロッキングスクリプトによって満たされなければならない条件を定義するロッキングスクリプトとを備える。通常、ロッキングスクリプトは、額を特定の関係者(ロッキングスクリプトが含まれるトランザクションの受益者)にロックする。すなわち、ロッキングスクリプトはアンロッキング条件を定義し、その条件は通常、後続のトランザクションの入力におけるアンロッキングスクリプトが、先行するトランザクションがロックされる対象である関係者の暗号署名を備えるという条件を備える。

【0050】

ロッキングスクリプト(scriptPubKeyとしても知られている)は、ノードプロトコルによって認識される分野特有の言語で書かれるコードである。そのような言語の具体的な例は、ブロックチェーンネットワークによって使用される「Script」(大文字のS)と呼ばれる。ロッキングスクリプトは、トランザクション出力203を消費するためにどの情報が必要とされるか、たとえば、Aliceの署名の要件を指定する。アンロッキングスクリプトは、トランザクションの出力に現れる。アンロッキングスクリプト(scriptSigとしても知られている)は、ロッキングスクリプト基準を満たすために必要とされる情報を提供する分野特有の言語で書かれるコードである。たとえば、それはBobの署名を含み得る。アンロッキングスクリプトはトランザクションの入力202に現れる。

【0051】

よって、示される例では、Tx₀の出力203におけるUTXO₀は、UTXO₀が引き換えられるようにするために(厳密には、UTXO₀を引き換えようとする後続のトランザクションが有効になるために)Aliceの署名Sig P_Aを必要とするロッキングスクリプト[Checksig P_A]を備える。[Checksig P_A]は、Aliceの公開-秘密鍵のペアからの公開鍵P_Aの表現(すなわち、ハッシュ)を含む。Tx₁の入力202は、Tx₁を指し示す(たとえば、そのトランザクションIDであるTxID₀によって指し示す、TxID₀は実施形態ではトランザクション全体Tx₀のハッシュである)ポインタを備える。Tx₁の入力202は、Tx₀のあらゆる他のあり得る出力の中からUTXO₀を特定するために、Tx₀内でUTXO₀を特定するインデックスを備える。Tx₁の入力202はさらに、Aliceが鍵のペアからの自身の秘密鍵をデータのあらかじめ定められた部分(暗号学では「メッセージ」と呼ばれることがある)に適用することによって作成される、Aliceの暗号署名を備えるアンロッキングスクリプト<Sig P_A>を備える。Aliceにより有効な署名を提供するために署名される必要のあるデータ(または「メッセージ」)は、ロッキングスクリプトによって、またはノードプロトコルによって、またはこれらの組合せによって定義され得る。

【0052】

新しいトランザクションTx₁がブロックチェーンノード104に到達すると、ノードはノードプロトコルを適用する。これは、アンロッキングスクリプトがロッキングスクリプトにおいて定義される条件(この条件は1つまたは複数の基準を備え得る)を満たすかどうかを確かめるために、ロッキングスクリプトおよびアンロッキングスクリプトを一緒に実行することを備える。実施形態では、これは2つのスクリプトを連結することを伴う。
<Sig P_A><P_A>||[Checksig P_A]
ここで、「||」は連結を表し、「<...>」はスタックにデータを置くことを意味し、「[...]」はロッキングスクリプト(この例では、スタックベース言語)に含まれる関数である。等価的に、スクリプトを連結するのではなく、スクリプトは共通のスタックを用いて次々に実行されてもよい。いずれにしても、一緒に実行されると、スクリプトは、Tx₀の出力の中のロッキングスクリプトに含まれるような、Aliceの公開鍵P_Aを使用して、Tx₁の入力の中のアンロッキングスクリプトがデータの予想される部分に署名するAliceの署名を含むことを認証する。データ自体(「メッセージ」)の予想される部分も、この認証を実行するために含まれる必要がある。実施形態では、署名されたデータはTx₁の全体を備える(よって、平文でデータの署名された部分を指定する別個の要素が含まれる必要がなく、それは、もともと存在していたからである)。

【0053】

公開-秘密暗号による認証の詳細は、当業者には馴染みがある。基本的に、Aliceが自身の秘密鍵を使用してメッセージに署名した場合、平文のAliceの公開鍵およびメッセージを与えられると、ノード104などの別のエンティティは、メッセージがAliceによって署名されたに違いないことを認証することが可能である。署名することは通常、メッセージをハッシュし、ハッシュに署名し、これを署名としてメッセージへとタグ付けすることで、公開鍵のあらゆる保有者が署名を認証することを可能にすることを備える。したがって、本明細書における、特定のデータまたはトランザクションの一部に署名することなどへのあらゆる言及は、実施形態では、そのデータまたはトランザクション一部のハッシュに署名することを意味することに留意されたい。

【0054】

Tx₁におけるアンロッキングスクリプトがTx₀のロッキングスクリプトにおいて指定される1つまたは複数の条件を満たす場合(よって示される例では、Aliceの署名がTx₁において提供されて認証される場合)、ブロックチェーンノード104はTx₁を有効であると見なす。これは、ブロックチェーンノード104がTx₁を未処理のトランザクションの順序付けられたプール154に追加することを意味する。ブロックチェーンノード104はまた、ネットワーク106の中の1つまたは複数の他のブロックチェーンノード104にトランザクションTx₁を転送するので、それは、ネットワーク106全体に広められる。Tx₁がブロックチェーン150において妥当性確認され含められると、これは消費されるものとしてTx₀からのUTXO₀を定義する。Tx₁は、未消費のトランザクション出力203を消費する場合にのみ、有効であり得ることに留意されたい。別のトランザクション152によってすでに消費されている出力を消費しようとする場合、Tx₁は、すべての他の条件が満たされている場合でも無効になる。したがって、ブロックチェーンノード104は、先行するトランザクションTx₀の中の参照されるUTXOがすでに消費されているかどうか(すなわち、すでに有効な入力を別の有効なトランザクションへと形成したかどうか)を確かめる必要もある。これは、トランザクション152に定められた順序を課すことがブロックチェーン150にとって重要である1つの理由である。実際には、所与のブロックチェーンノード104は、トランザクション152がその中で消費されたどのUTXO203をマークする別個のデータベースを維持してもよいが、究極的には、UTXOが消費されたかどうかを定義するものは、UTXOが有効な入力をブロックチェーン150の中の別の有効なトランザクションへとすでに形成したかどうかである。

【0055】

所与のトランザクション152のすべての出力203において指定される総額が、すべてのその入力202によって指し示される総額より大きい場合、これもまた、大半のトランザクションモデルにおいて、無効であることの根拠になる。したがって、そのようなトランザクションは、広められず、ブロック151にも含められない。

【0056】

UTXOベースのトランザクションモデルにおいて、所与のUTXOは全体として消費される必要があることに留意されたい。それは、消費されるものとしてUTXOにおいて定義される額の一部を、別の一部が消費されながら「置き去りにする」ことができない。しかしながら、UTXOからの額は、次のトランザクションの複数の出力の間で分割され得る。たとえば、Tx₀の中のUTXO₀において定義される額は、Tx₁の中の複数のUTXO間で分割され得る。したがって、AliceがUTXO₀において定義される額のすべてをBobに与えることを望まない場合、彼女はリマインダーを使用してTx₁の第2の出力の残金を自分に与え、または別の関係者に支払うことができる。

【0057】

実際には、Aliceは普通は、Aliceのトランザクション104をブロック151に含めることに成功するビットコインノード104に対する料金も含める必要がある。Aliceがそのような料金を含めない場合、Tx₀はブロックチェーンノード104によって拒絶されてもよく、したがって、技術的には有効であっても、広められず、ブロックチェーン150に含められなくてもよい(ノードプロトコルは、ブロックチェーンノード104がトランザクション152を受け入れることを望まない場合、それを強いることはない)。一部のプロトコルでは、トランザクションフィーは、固有の別々の出力203を必要としない(すなわち、別個のUTXOを必要としない)。代わりに、入力202によって指し示される総額と所与のトランザクション152の出力203において指定される総額とのあらゆる差が、トランザクションを公開するブロックチェーンノード104に自動的に与えられる。たとえば、UTXO₀へのポインタがTx₁への唯一の入力であり、Tx₁が唯一の出力UTXO₁を有するとする。UTXO₀において指定されるデジタル資産の額がUTXO₁において指定される額より大きい場合、その差が、UTXO₁を含むブロックを作成するために、プルーフオブワークの競争に勝利するノード104によって割り当てられ得る。しかしながら、代替または追加として、トランザクションフィーが、トランザクション152のUTXO203のうちの自身固有のUTXOにおいて明示的に指定され得ることは、必ずしも排除されない。

【0058】

AliceおよびBobのデジタル資産は、ブロックチェーン150のどこかにある任意のトランザクション152において彼らにロックされるUTXOからなる。したがって、通常は、所与の関係者103の資産は、ブロックチェーン150全体の、様々なトランザクション152のUTXO全体に分散している。所与の関係者103の総残高を定義する1つの数字が、ブロックチェーン150のどこかに保管されているということはない。それぞれの関係者にロックされており、別のその先のトランザクションにおいてまだ消費されていないすべての様々なUTXOの値を一緒に照合することが、クライアントアプリケーション150のウォレット機能の役割である。そのウォレット機能は、ビットコインノード104のいずれかに記憶されているようなブロックチェーン150のコピーをクエリすることによって、これを行うことができる。

【0059】

スクリプトコードはしばしば、概略的(すなわち、厳密な言語を使用せずに)に表現されることに留意されたい。たとえば、特定の関数を表すためにオペレーションコード(オペコード)を使用することがある。「OP_...」は、Script言語の特定のオペコードを指す。例として、OP_RETURNは、ロッキングスクリプトの最初おいてOP_FALSEが前にあるとトランザクション内のデータを記憶できるトランザクションの消費不可能な出力を生み出し、それによりブロックチェーン150にデータをイミュータブルに記録するような、Script言語のオペコードである。たとえば、データは、ブロックチェーンに記憶することが望まれる文書を備え得る。

【0060】

通常、トランザクションの入力は、公開鍵P_Aに対応するデジタル署名を含む。実施形態では、これは、楕円曲線secp256k1を使用するECDSAに基づく。デジタル署名は特定のデータに署名する。いくつかの実施形態では、所与のトランザクションに対して、署名はトランザクション入力の一部、およびトランザクション出力の一部またはすべてに署名する。署名する出力の具体的な部分は、SIGHASHフラグに依存する。SIGHASHフラグは普通は、どの出力が署名されるかを選択するために署名の最後に含まれる(したがって署名の時点で固定される)4バイトのコードである。

【0061】

ロッキングスクリプトは時々「scriptPubKey」と呼ばれ、それぞれのトランザクションがロックされる対象である関係者の公開鍵をロッキングスクリプトが通常は備えるという事実を指している。アンロッキングスクリプトは時々「scriptSig」と呼ばれ、アンロッキングスクリプトが対応する署名を通常は供給するという事実を指している。しかしながら、より一般的には、UTXOが引き換えられるようにするための条件が署名を認証することを備えることは、ブロックチェーン150のすべての適用例において必須ではない。より一般的には、スクリプト言語は、任意の1つまたは複数の条件を定義するために使用され得る。したがって、より一般的な用語「ロッキングスクリプト」および「アンロッキングスクリプト」が好まれることがある。

【0062】

サイドチャネル
図1に示されるように、AliceおよびBobのコンピュータ機器102a、120bの各々上のクライアントアプリケーションは、それぞれ、追加の通信機能を備え得る。この追加の機能は、Alice 103aがBob 103bと(関係者または第三者のいずれかの誘いで)別個のサイドチャネル107を確立することを可能にする。サイドチャネル107は、ブロックチェーンネットワークとは別にデータの交換を可能にする。そのような通信は「オフチェーン」通信と呼ばれることがある。たとえば、これは、トランザクション152が(まだ)ブロックチェーンネットワーク106上に登録されることなくまたはチェーン150上への途中でなくAliceとBobの間で、その関係者のうちの一方がネットワーク106にトランザクションをブロードキャストすることを選ぶまで、それを交換するために使用され得る。トランザクションをこのようにして共有することは、「トランザクションテンプレート」を共有することと呼ばれることがある。トランザクションテンプレートは、完全なトランザクションを形成するために必要とされる1つまたは複数の入力および/または出力を欠き得る。代替または追加として、サイドチャネル107は、鍵、交渉された額または条件、データ内容などの、任意の他のトランザクション関連データを交換するために使用され得る。

【0063】

サイドチャネル107は、ブロックチェーンネットワーク106と同じパケット交換ネットワーク101を介して確立され得る。代替または追加として、サイドチャネル301は、モバイルセルラーネットワークなどの異なるネットワーク、またはローカル無線ネットワークなどのローカルエリアネットワーク、またはAliceおよびBobのデバイス102a、102bの間のダイレクト有線もしくは無線リンクさえも介して確立され得る。一般的には、本明細書のどこでも言及されるサイドチャネル107は、データを「オフチェーン」で、すなわちブロックチェーンネットワーク106とは別に、交換するための1つまたは複数のネットワーク技術または通信媒体を介する任意の1つまたは複数のリンクを備え得る。2つ以上のリンクが使用される場合、オフチェーンリンク全体としての束または集合がサイドチャネル107と呼ばれ得る。したがってAliceおよびBobがサイドチャネル107を通じてある情報またはデータを交換するなどと言われる場合、これは、すべてのこれらのデータが厳密に同じリンクを、または同じタイプのネットワークさえも通じて送信されなければならないことを必ずしも示唆しないことに留意されたい。

【0064】

クライアントソフトウェア
図3Aは、ここで開示される方式の実施形態を実装するためのクライアントアプリケーション105の例示的な実装形態を示す。クライアントアプリケーション105は、トランザクションエンジン401およびユーザインターフェース(UI)層402を備える。トランザクションエンジン401は、上で論じられまもなくさらに詳しく論じられるような方式に従って、トランザクション152を編成すること、サイドチャネル310を介してトランザクションおよび/もしくは他のデータを受信および/もしくは送信すること、ならびに/またはブロックチェーンネットワーク106を通じて広められるようにトランザクションを1つまたは複数のノード104に送信することなどの、クライアント105の背後にあるトランザクション関連機能を実施することを行うように構成される。本明細書で開示される実施形態に従って、各クライアント105のトランザクションエンジン401は、ブロックチェーンユニフォームリソース識別子(BURI)を生成するためのまたはブロックチェーン上に記憶されるブロックチェーントランザクションを参照するための機能403を備える。

【0065】

UI層402は、それぞれのユーザのコンピュータ機器102のユーザ出力手段を介してそれぞれのユーザ103に情報を出力すること、および機器102のユーザ入力手段を介してそれぞれのユーザ103から入力を受け取ることを含む、機器102のユーザ入力/出力(I/O)手段を介してユーザインターフェースをレンダリングすることを行うように構成される。たとえば、ユーザ出力手段は、視覚的な出力を提供するための1つまたは複数の表示画面(タッチスクリーンまたは非タッチスクリーン)、オーディオ出力を提供するための1つまたは複数のスピーカー、および/または触覚出力を提供するための1つまたは複数の触覚出力デバイスなどを備え得る。ユーザ入力手段は、たとえば、1つもしくは複数のタッチスクリーンの入力アレイ(出力手段に使用されるものと同じまたは異なる)、マウス、トラックパッド、もしくはトラックボールなどの1つもしくは複数のカーソルベースのデバイス、発話もしくは声の入力を受け取るための1つもしくは複数のマイクロフォンおよび発話もしくは声認識アルゴリズム、手もしくは体のジェスチャの形態で入力を受け取るための1つもしくは複数のジェスチャベースの入力デバイス、または、1つもしくは複数の機械的なボタン、スイッチ、もしくはジョイスティックなどを備え得る。

【0066】

注意:本明細書の様々な機能は、同じクライアントアプリケーション105へと統合されるものとして説明されることがあるが、これは必ずしも限定するものではなく、代わりにそれらは2つ以上の別個のアプリケーションのスイートにおいて実装されてもよく、たとえば、それらのアプリケーションは、一方が他方へのプラグインであり、またはAPI(アプリケーションプログラミングインターフェース)を介してインターフェースする。たとえば、トランザクションエンジン401の機能は、UI層402とは別のアプリケーションにおいて実装されてもよく、または、トランザクションエンジン401などの所与のモジュールの機能は、1つより多くのアプリケーション間で分割され得る。説明される機能の一部またはすべてが、たとえばオペレーティングシステム層において実装され得ることも排除されない。単一のまたは所与のアプリケーション105などへの言及が本明細書のどこかで行われる場合、それは例にすぎず、より一般的には、説明される機能は任意の形態のソフトウェアにおいて実装され得ることが理解されるだろう。

【0067】

図3Bは、Aliceの機器102aのクライアントアプリケーション105aのUI層402によってレンダリングされ得るユーザインターフェース(UI)500の例のモックアップを与える。同様のUIが、Bobの機器102bのクライアント105b、または任意の他の関係者のクライアントによってレンダリングされ得ることが理解されるだろう。

【0068】

例として、図3BはAliceの視点からUI500を示す。UI500は、ユーザ出力手段を介して別個のUI要素としてレンダリングされる1つまたは複数のUI要素501、502、502を備え得る。

【0069】

たとえば、UI要素は1つまたは複数のユーザが選択可能な要素501を備えてもよく、これは、異なる画面上のボタン、またはメニューの中の異なるオプションなどであり得る。ユーザ入力手段は、UI要素を画面上でクリックもしくはタッチすること、または望まれるオプションの名前を話すことなどの、オプションの1つを選択することまたは別様に操作することをユーザ103(この場合Alice 103a)が行うことを可能にするようになされる(本明細書で使用される「手動」という用語は、自動と対比することのみが意図され、手を使用することに必ずしも限定されないことに留意されたい)。オプションは、ユーザ(Alice)が、ブロックチェーンユニバーサルリソースインジケータ(BURI)または以下で説明されるようにBURIによって参照されるべきトランザクション/データなどの、ブロックチェーントランザクションに含めるための情報を選択することを可能にする。オプションは、以下で説明されるように、ユーザがブロックチェーン上での参照されるトランザクションの存在の検証を要求することも可能にする。

【0070】

代替または追加として、UI要素は、1つまたは複数のデータエントリフィールド502を備えてもよく、これを通じて、ユーザは、BURIによって参照されるトランザクションに記憶されるデータに関するコメントなどの、ブロックチェーントランザクションに含めるためのテキストを提供すること、またはBURIにおいて参照されるべきトランザクションもしくはトランザクションに記憶されるデータを手動で定義することができる。これらのデータエントリフィールドは、ユーザ出力手段を介して、たとえば画面上でレンダリングされ、データは、ユーザ入力手段、たとえばキーボードまたはタッチスクリーンを通じてフィールドへと入力され得る。代替として、データは、たとえば発話認識に基づいて、口頭で受信され得る。

【0071】

代替または追加として、UI要素は、ユーザに情報を出力するための1つまたは複数の情報要素503を備え得る。たとえば、これ/これらは、画面上に、または音でレンダリングされ得る。

【0072】

様々なUI要素をレンダリングし、オプションを選択し、データを入力する具体的な手段は、重要ではないことが理解されるだろう。これらのUI要素の機能は、まもなくより詳しく論じられる。図3に示されるUI500は図式化されたモックアップにすぎず、実際には、簡潔にするために示されない1つまたは複数のさらなるUI要素を備え得ることも理解されるだろう。

【0073】

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

【0074】

したがって、スクリプトエンジン452は、Tx_iのロッキングスクリプトおよびTx_jの対応する入力からのアンロッキングスクリプトを有する。たとえば、Tx₀およびTx₁とラベリングされるトランザクションが図2に示されるが、同じことがトランザクションのあらゆるペアに対して当てはまり得る。スクリプトエンジン452は、前に論じられたように、2つのスクリプトを一緒に実行し、これには、使用されているスタックベースのスクリプト言語(たとえばScript)に従ってスタック453上にデータを置きそこからデータを読み出すことを含むだろう。

【0075】

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

【0076】

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

【0077】

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

【0078】

マークル木
マークル木は、データの集合のセキュアな検証を可能にする階層的データ構造である。マークル木において、木の中の各ノードは、インデックスペア(i,j)を与えられており、N(i,j)と表される。インデックスi、jは単に、木の中の特定の位置に関連する数値ラベルである。

【0079】

マークル木の重要な特徴は、そのノードの各々の構築が以下の式により支配されるということである。

【0080】

【数1】

【0081】

ここでHは暗号学的ハッシュ関数である。

【0082】

これらの式に従って構築される二進のマークル木が図5に示される。示されるように、i=jの事例は葉ノードに相当することがわかり、葉ノードは単に、データの対応するi番目のパケットD_iのハッシュである。i≠jの事例は内部ノードまたは親ノードに相当し、これは1つの親(マークル根)が発見されるまで子ノードを再帰的にハッシュして連結することによって生成される。

【0083】

たとえば、ノードN(0,3)は、4つのデータパケットD₀,...,D₃から
N(0,3)=H(N(0,1)||N(2,3))
=[H(N(0,0)||N(1,1))||H(N(2,2)||N(3,3))]
=[H(H(D₀)||H(D₁))||H(H(D₂)||H(D₃))]
として構築される。

【0084】

木の深さMは、木の中のノードの最低レベルとして定義され、ノードの深さmは、ノードが存在するレベルである。たとえば、m_root=0かつm_leaf=Mであり、図5ではM=3である。

【0085】

ビットコインおよびいくつかの他のブロックチェーンにおけるマークル木では、ハッシュ関数はdouble SHA256であり、これは標準ハッシュ関数SHA-256 twice:H(x)=SHA256(SHA256(x))を適用することである。

【0086】

マークル証明
マークル木の主要な機能は、いくつかのデータパケットD_iがN個のデータパケットのリストまたは集合

【0087】

【数2】

【0088】

の要素であることを検証することである。検証のための機構は、マークル証明として知られており、所与のデータパケットD_iおよびマークル根Rのためのマークルパスとして知られているハッシュのセットを取得することを伴う。データパケットのためのマークル証明は単に、反復的なハッシュ化と連結により根Rを再構築するために必要なハッシュの最低限のリストであり、しばしば「認証証明」と呼ばれる。

【0089】

存在の証明は、すべてのパケットD₀,...,D_N-1およびそれらの順序が証明者に知られていれば容易に実行され得る。しかしながら、これは、マークル証明よりはるかに大きなストレージのオーバーヘッドを必要とし、また、データセット全体が証明者に対して利用可能であることも必要とする。マークル証明を使用することとリスト全体を使用することとの比較が以下の表に示されており、そこでは、二進のマークル木を使用し、データブロックの数Nが2のべき乗に厳密に等しいと仮定した。

【0090】

以下の表は、マークル木の中の葉ノードの数と、マークル証明(またはマークル証明)に必要とされるハッシュの数との関係を示す。

【0091】

【表1】

【0092】

データパケットの数が葉ノードの数に等しいこの簡略化されたシナリオでは、マークル証明を計算するために必要なハッシュ値の数が対数的にスケーリングすることを発見した。明らかに、N個のデータハッシュを記憶して明白な証明を計算することよりも、log₂N個のハッシュを伴うマークル証明を計算する方が、はるかにより効率的で現実的である。

【0093】

方法
マークル証明Rが与えられており、データブロックD₀がRにより表される順序付けられたリスト

【0094】

【数3】

【0095】

に属していることを証明したいと仮定すると、マークル証明を次のように
実行することができる。
i.信用されるソースからマークル根Rを取得する。
ii.ソースからマークル証明Γを取得する。この場合、Γはハッシュの集合
Γ={N(1,1),N(2,3),N(4,7)}
である。
iii.D₁およびΓを使用してマークル証明を次のように計算する。
a.データブロックをハッシュして以下を得る。
N(0,0)=H(D₀)
b.N(1,1)と連結しハッシュして以下を得る。
N=(0,1)=H(N(0,0)||N(1,1))
c.N(2,3)と連結しハッシュして以下を得る。
N=(0,3)=H(N(0,1)||N(2,3))
d.N(4,7)と連結しハッシュして根を得る。
N=(0,7)=H(N(0,3)||N(4,7))
R'=N(0,7)
e.計算された根R'を(i)において得られた根Rと比較する。
1.R'=Rである場合、木における、したがってデータセット

【0096】

【数4】

【0097】

におけるD₀の存在が確認される。
2.R'≠Rである場合、証明は失敗し、D₀が

【0098】

【数5】

【0099】

の要素であることは確認されない。

【0100】

これは、何らかのデータが存在することの証明を、マークル木およびその根により表されるデータセットの一部として提供するための効率的な機構である。たとえば、データD₀がブロックチェーントランザクションに対応し、根Rがブロックヘッダの一部として公に利用可能である場合、トランザクションがそのブロックに含まれていたことを迅速に証明することができる。

【0101】

例示的なマークル木の一部としてD₀が存在することを認証する過程が、図6に示されている。これは、所与のブロックD₀および根Rのマークル証明を実行することが実質的には、必要最小限の数のハッシュ値しか使用しないことによってマークル木を「上向きに」走査することであることを示している。

【0102】

マークル証明を構築するための最小限の情報
単一の葉のマークル証明を構築するとき、必要とされる最小限の情報は、
1.葉のインデックス:マークル木の中の葉層における葉の位置
2.ハッシュ値の順序付けられたリスト:マークル根を計算するために必要とされるハッシュ値
である。

【0103】

葉のインデックスがどのように機能するかを説明するために、図5のマークル木を考える。Bobは、根Rを知っているが、木のすべての葉を知っているわけではない。D₀のためのマークル枝は、1つのインデックス、0、および3つのハッシュ値(丸で囲まれた)からなる。インデックスは、提供されたハッシュ値が計算されたハッシュ値の左に連結されるべきかまたは右に連結されるべきかを示すためのものである。

【0104】

マークル木はN=2^M個の葉を有すると仮定する。層0におけるインデックスiを仮定し、i₀=1、b₀=i₀ mod 2、

【0105】

【数6】

【0106】

、すなわち

【0107】

【数7】

【0108】

とする。

【0109】

p₀は、インデックスがi₀である葉ノードのペア葉ノードのインデックスである。それらはマークル木においてそれらの親ハッシュノードを計算するために連結されハッシュされる(上記参照)ので、それらをペアと呼ぶ。インデックスがp₀であるノードは「提供されるハッシュ」または「必要とされるデータ」とも呼ばれ、それは、i₀葉ノードのマークル根を計算するときに提供されなければならないからである。

【0110】

したがって、層mにおいて、

【0111】

【数8】

【0112】

となることを定義することができる。

【0113】

そうすると、提供されるハッシュのインデックスは

【0114】

【数9】

【0115】

である。

【0116】

上記の式は、インデックスが0で開始することを仮定する。

【0117】

本発明の文脈では、インデックスがi₀である葉ノードは、標的トランザクションのトランザクション識別子である。

【0118】

ユニフォームリソース識別子
インターネット上にリソースを位置付けるために多数の異なる識別子が使用される。これらの識別子は、データリソースのネットワーク交換を可能にし、ピアツーピアネットワークにおいて使用され得る。識別子は、リソースの命名における一意性も可能にする。

【0119】

ユニフォームリソース識別子(URI)は、コンテンツをオンラインで特定するスキーマである。ユーザは、インターネット上で利用可能なプロトコルおよびリソースに対処する一般的なスキーマを作成し得る。スキーマは、ユーザが定義し得る、多数の構成要素を有する。

【0120】

一般的なURI構文は、スキーム(scheme)、権限(authority)、パス(path)、クエリ(query)およびフラグメント(fragment)と呼ばれる構成要素の階層的シーケンスからなる:
URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ]
ここで「hier-part」は以下のオプションから選ぶことができる
hier-part = "//" authority path-abempty
/path-absolute
/path-rootless
/path-empty

【0121】

URIスキームは、プロトコル内の機能の他にリソース自体を説明するために使用され得る。ファイル転送およびメール機能は、所与のスキーム内で定義され得る。これは、ユニフォームリソースロケータ(URL)によって直接使用され得る。

【0122】

URI構文は階層的に組織化されており、構成要素が重要性の降順に列挙される。URIの構成要素は、少なくとも1つの区切り文字によって分離される。予約された文字のサブセットが、URI内の構文構成要素を区切るために使用され得る。本明細書で開示される例では、使用される区切り文字は「:」および「/」であるが、他の文字がURIの異なる階層的構文構成要素を分離する区切り文字として定義され、したがって使用され得ることが理解されるだろう。

【0123】

URIスキームが、リソースを画定するかつ対処する同一の方途として用いられることができる。

【0124】

他のURIスキームは当技術分野において知られている。

【0125】

ブロックチェーンユニフォームリソース識別子
ここで標的トランザクションの中の内容が参照されることを可能にするURIスキーマが説明される。URIスキーマはまた、標的トランザクションがブロックチェーン上に存在することを検証するために使用され得る。URIは、本明細書で参照トランザクションと呼ばれるブロックチェーントランザクションに含まれてもよく、それによりブロックチェーン上の標的トランザクションを参照するための手段を提供する。

【0126】

検証は、URIスキーマ自体内に、標的トランザクションのためのマークル木証明に関連した情報を含むことによって達成される。

【0127】

簡易ブロックチェーンURIスキーマ
簡易ブロックチェーンユニフォームリソース識別子(sBURI)は、ブロックチェーン上の以前に公開されたトランザクションの内容を参照するために使用され得る。sBURIスキーマは次のようである:
sBURI:[ブロック識別子]:[TxID]

【0128】

参照されているトランザクションを含むブロック(標的ブロック)を特定するブロック識別子としてブロック番号またはブロックヘッダハッシュのいずれかが提供され得る。

【0129】

sBURIスキーマにおいて標的トランザクションのTxIDだけの使用では、ブロックチェーン上の標的トランザクションの存在を検証するには不十分である。検証者は、マークル木証明を完成させるために、まだマークル木分岐情報を取得する必要があるだろう。しかしながら、TxIDは、標的トランザクションがブロックチェーン上で見つけられるには十分である。

【0130】

TxIDがjsf…38rである既存の標的トランザクションを参照するために、その出力においてsBURIを使用する例示的な参照トランザクションが以下に示される。この例示的なsBURIにブロック高さが使用されており、標的トランザクションがブロック番号630000に存在することを示す。

【0131】

【表2】

【0132】

上のsBURIがブロック識別子を含むが、標的トランザクションを見つけるためにはTxIDだけが必要とされることが留意される。

【0133】

完全ブロックチェーンURIスキーマ
よりロバストなブロックチェーンURIスキーマ(BURI)は、標的トランザクションの存在の証明の検証を可能にするためにマークル証明情報を追加として提供する。

【0134】

このBURIは、ブロックをその番号またはヘッダハッシュによって特定し、またマークル木情報および標的トランザクションに関連するトランザクションIDを含む。URIスキームの形式は、次のように完全に書かれる:
BURI:[ブロック識別子]:[マークル証明データ]:[TxID]

【0135】

検証者は、標的トランザクションがブロックチェーン上のブロックに含まれているという検証を支援するためにBURIを使用し得る。上に示されたBURIスキーマの一般化された形態では、マークル証明データ構成要素は、BURIを所有しているだれかにマークル証明検証のために必要とされる追加の情報の少なくとも一部を提供することによって検証を補助する一部である。

【0136】

BURIのマークル証明データは、
i.標的トランザクションのマークルインデックス、または
ii.標的トランザクションのマークルインデックスおよびマークル証明のハッシュの順序付けられたリスト
のいずれかを備え得る。

【0137】

BURIスキーマに標的トランザクション(すなわち標的トランザクションに対応するマークル木の葉)のインデックスを含めることの重要性が留意されるべきであるが、マークル証明においてマークル証明がハッシュの順序付けられたリストから正しく計算されることを可能にするのはこの情報であるからである。ハッシュの順序付けられたリストは、ブロックヘッダから取得される信頼されるマークル根によって標的トランザクションが検証されるかどうかを決定するために必要とされるマークル証明ハッシュのサブセットである。マークル根はまた、本明細書でマークル根ハッシュと呼ばれ得る。

【0138】

上で説明されるように、マークル分岐および対応するマークル証明ハッシュのインデックスは葉自体の葉層インデックスから完全に導出され得る。

【0139】

二進の葉のインデックスが、根から葉まで、マークル木における木の走査にマッピングし、したがって存在検証のマークル証明に関連する木における各インデックス点を決定することが図5に見られ得る。各ノードの左右の子は、それぞれ0および1でラベリングされ、したがって根から葉ノードに走査されるパスを示す。たとえば、根から走査されるパスではインデックス3における葉は単に2進数011₂=3₁₀で書かれる葉インデックスである。

【0140】

本明細書で説明されるBURIはブロックチェーン上でまたは外で使用され得る。例示的なオンチェーン使用が以下に述べられる。

【0141】

Aliceによって作成されるトランザクションTxID₁およびBobによって作成される別のトランザクションTxID₂を考える。BURIは、2つのトランザクションを関連してつなげるために使用され得る。このシナリオでは、TxID₁は画像のためのコンテンツデータを含み、標的トランザクションであるだろう。第2のトランザクションTxID₂は、Aliceのトランザクションの中の内容を参照するまたは指し示すBURIを含む。

【0142】

以下の標的トランザクションTxID₁は画像データを含む。この例では、トランザクションは、ブロック番号15においてマイニングされており、そのブロック内でのそのインデックスは5であり、それは、標的画像データを含む単一のOP_RETURN出力を有する。値δ₁は、トランザクションがブロックチェーン上で公開されるために必要とされるトランザクションフィーを表す。

【0143】

【表3】

【0144】

トランザクションTxID₂は、標的トランザクションを参照するBURIを含み、以下に示される。このトランザクションは後の時点で(たとえばブロック30において)マイニングされるが、唯一の厳密な要件は、それがTxID₁の後に作成されるということである。

【0145】

Bobのトランザクションは、Aliceのトランザクションを、それが含まれるブロック(15)、そのブロック内でのトランザクションのインデックス(5)および最後に標的トランザクションID自体(jsf...38r)を指定することによって、参照するBURIを含む。

【0146】

これにより、これが、BURIのマークル証明データ構成要素が単にTxID₁のためのトランザクションインデックス(5)である例示的なBURI使用であることを意味する。これは、Bobのトランザクションまたは単にBURI自体を所有しているだれにでも、TxID₁のためのマークル証明を構成するマークル木の特定のハッシュを要求するための情報を与える。BURIを知っているだれでも、今では第三者からこれらのハッシュ(すなわちマークル証明)を取得して、ブロックチェーン上でのTxID₁の存在を検証することができる。

【0147】

【表4】

【0148】

マークル証明が取得される元となる第三者はブロックチェーンノード(マイナーとしても知られている)であり得る。代替として、第三者は、それぞれのブロックチェーントランザクションのトランザクション識別子のセットを記憶するが、ブロックチェーンネットワークに新しいブロックチェーンブロックを公開しない、以下により詳しく説明される、マークル証明サーバであり得る。

【0149】

しかしながら、Bobは、自分のトランザクションの中のBURIにより、だれもが証明を取得するために第三者に相談することなく存在の証明を検証することを可能にすることができることを確実にしたいと望むかもしれない。彼は、自分のトランザクションの中のBURIを、それがマークル証明自体全体を含むように構築することによって、これを達成することができ、BURIの形式は、
BURI:15:5:3be...f41/2ab...e5c/.../ff1...0de:jsf...38r
になり、ここで3be...f41/2ab...e5c/.../ff1...0deは、マークル証明におけるハッシュの順序付けられたセットである。

【0150】

Bobのトランザクションの代替の例TxID₂'が以下に示され、このようにマークル証明全体を含むBURIを使用する。

【0151】

【表5】

【0152】

上のBURIがTxID₁のインデックス(5)も保持しており、これが、証明における各ハッシュ値を左または右の相手として割り当てることによってマークル証明計算をどのように実行するべきかを決定するために必要とされるからであることが留意されるべきである。言い換えると、BURIの[マークル証明データ]要素は、TxID₂'に示される例では2つの部分要素へ分割されている:トランザクションインデックスおよびそのマークル証明ハッシュ
[マークル証明データ]=[インデックス]:[証明ハッシュ]=[5]:[3be...f41/2ab...e5c/.../ff1...0de]

【0153】

TxID₁のマークル証明についての情報がTxID₂に使用されるBURIに組み込まれ得る様々な異なる方法がある。第1のケースでは、情報はユーザが別のソースから正しいマークル証明を取得するのを補助する一方で、第2のケースでは、情報は完全なマークル証明自体を含む。第2の方法は、検証者が、たとえばSPV的にブロックヘッダのリストにアクセスできると仮定すると、ブロックチェーン上でのTxID₁の包含を検証するために必要とされるあらゆるものがBURI自体に含まれているという有意な利点を有する。

【0154】

しかしながら、マークル証明を含むことは、参照トランザクションTxID₂のサイズおよび料金を増加させるマークル証明のハッシュのデータによるオーバーヘッドをもたらす。その上、多くの人々が同じトランザクションTxID₁を参照する場合、このマークル証明データはオンチェーンで複数回複製され、これは非効率的なリソースの使用である。

【0155】

図9は、参照トランザクション906の中のBURI908を使用する標的トランザクション902の参照を概略的に示す図である。

【0156】

この例では、Charlieは、標的トランザクション902の中のブロックチェーンに記憶されている画像データを参照することを望む。そうするために、Charlieは、標的トランザクション902を特定するBURI908を生成、(または別様に取得)し、そして参照トランザクションの出力にBURI908を含める。

【0157】

Charlieは、少なくとも参照トランザクション906のためのトランザクションフィーを提供するために、参照トランザクション906のための入力も提供しなければならない。Charlieは、UTXOがCharlieにロックされている、より前のトランザクション904を特定する出力点を提供する。

【0158】

参照トランザクション906の出力にBURI 908を提供することによって、Charlieは、標的トランザクション902に記憶されるデータがCharlieに移されることを必要とすることなく標的トランザクション902に記憶されるデータを参照することが可能であることが図9から見られ得る。すなわち、Charlieは、自分には所有権がないデータを参照することが可能である。

【0159】

図10は、BURIの構成要素がどのように標的ブロックの構成要素に対応するかを説明する。BURIは、これらの構成要素の階層的シーケンスであり、BURIの各後続の構成要素が標的データをより詳細に定義する。

【0160】

BURIの第1の構成要素はブロック識別子であり、BURIにおいて参照されるトランザクションを含むブロックを示しかつ標的ブロックのブロックヘッダを指し示す。ブロック識別子は、ブロックヘッダの構成要素である、ブロック番号(高さ)、またはブロックヘッダハッシュのいずれかであり得る。これらの構成要素のいずれも、ブロックチェーン上でまたは代替としてブロックおよびトランザクションに関する情報を記憶しているデータベース内で標的ブロックを見つけるために使用され得る。

【0161】

ブロック番号(高さ)は、ジェネシスブロックからのブロックの順序付けられたシーケンスの中のブロックの位置として定義される。2つのブロックがブロックチェーンの並列分岐の一部である場合、それらは同じブロック番号を有し得る。

【0162】

ブロックヘッダハッシュは、ブロックヘッダのダブルハッシュとして定義され、ブロックが生じるときに生成される。それは、ブロックに一意であり、かつ時不変である。

【0163】

ブロック公開がチェーンに新しいブロックを追加する。時折、ブロックはオーファンプロセスにさらされることがあり、それらは永続的なブロックチェーンに参加せず見捨てられる。

【0164】

ブロック識別子としてのボック番号およびブロックヘッダハッシュの各々の使用に利点および不利点がある。

【0165】

ブロック番号/高さは、ブロックのよりコンパクトな識別子である。それは、短いストリング(たとえば4バイト)であることができ、したがって32バイトのハッシュ値を記憶するより空間効率が高い。

【0166】

しかしながら、ブロック番号は、必ずしもブロックに対して一意の識別子であるわけではない。同じ番号/高さを持つが同じチェーンの異なる分岐と関連付けられた2つの有効なブロックがあり得る。

【0167】

ブロックヘッダのハッシュは、このブロックに対して一意の識別子であり、かつブロックの公開時に作成される。

【0168】

しかしながら、ブロッカヘッダハッシュのサイズ(32バイト)は、現在ブロック番号よりコンパクトでない。いくつかのブロックはオーファンプロセスにさらされる。

【0169】

要約すると、ブロック番号の使用は、BURIと関連付けられたデータサイズを最小限にするために望ましいが、ブロックチェーンの中の十分に深いブロックに含まれる標的トランザクションに対しては、これがブロックと関連付けられたオーファンリスクを最小限にするので、最も適用可能である。対照的に、ブロックヘッダハッシュの使用は、特定のブロックを一意に特定する利点を有するが、これには、BURIを含むオンチェーントランザクションに記憶されなければならない追加のデータという代償を伴う。

【0170】

BURIの第2の構成要素は、本明細書でマークルインデックスとも呼ばれる、トランザクションインデックスである。前に説明されたように、トランザクションインデックスは、トランザクションと関連付けられた葉ノードにマークル木を通じて走査されるパスを示す。

【0171】

BURIの第3の構成要素は、マークル証明のハッシュの順序付けられたリストである。これらのハッシュは、標的トランザクションの特定の構成要素に対応するのではなく、検証のために提供される。

【0172】

トランザクションインデックスおよびハッシュの順序付けられたリストは、マークル証明データを形成する。上で述べられたように、マークル証明データは、インデックスを備えるだけでもよい。マークル証明データ構成要素は、BURIによって標的とされるトランザクションのためのマークル証明についての少なくとも部分的な情報を含む。

【0173】

トランザクションインデックスだけを備えるマークル証明データの場合、この形式のBURIは、ユーザがブロックチェーン上での標的トランザクションの存在を独立して検証するために必要とされる情報のすべてを含むわけではなく、彼らがまだマークル証明にハッシュのセットを必要とするからである。

【0174】

しかしながら、BURIにおけるトランザクションインデックスの包含は、検証者がインデックスに基づいて第三者にマークル証明を要求することを可能にする。これは、第三者が各ブロックのためのマークル木を記憶しているマークルパスサーバである場合には、インデックスにより彼らが木の中のどのハッシュが証明を構成するかを特定することを可能にするだろうから、有益であり得る。

【0175】

通常、トランザクションIDだけで、第三者にマークル証明を要求するのに十分であり得るが、しかしながらBURIにおけるインデックスの包含により、検証者が、トランザクションIDではなく、ブロック識別子およびトランザクションインデックスに基づいてマークル証明の要求に応答するために最適化され得る、より広範囲の専門サービスに相談することを可能にする。これは、サービス提供者にとっては、それらが、TxIDに基づいて証明ハッシュを総当たり検索する必要なく、直接正しいマークル証明にアクセスすることを可能にするという点で、より効率的であり得る。

【0176】

ハッシュのリストが提供されない場合、スキーマの形式は、
BURI:[ブロック識別子]:[マークル証明データ]:[TxID]
であり、たとえば:
BURI:01111:0101:jsf7r8urige84r43wekefh344iurrh438r
但しインデックスが2進形式である場合、そして、
BURI:01111:5:jsf7r8urige84r43wekefh344iurrh438r
但しインデックスが10進形式である場合。

【0177】

マークル木の標的葉のインデックスは、2進インデックスとして最もコンパクトに表現され得る。

【0178】

代替として、標的トランザクションインデックスおよびそのマークル証明のハッシュの完全な順序付けられたリストの両方がBURI自体に含まれる。これは、ブロックにおける標的トランザクションの存在を妥当性確認するために必要とされるあらゆるものがBURI内に内蔵されるという有意な利益を有する。

【0179】

ユーザは、単にこの形式のBURIを取得し、マークル証明ハッシュを抽出し、標的トランザクションハッシュをマークル証明ハッシュと順におよび同じくBURIにおいて提供されるインデックスに基づく左右割当てと組み合わせることによってマークル証明検証を実行することができる。ユーザはまた、元の標的トランザクションを取得することを、そのトランザクションの中の実際のコンテンツデータもオンチェーンで公開されていると証明されることを保証するため、そのダブルハッシュがBURIにおいて与えられるTxIDに対応することを保証するために、望み得る。

【0180】

マークル証明データがトランザクションインデックスおよびハッシュの順序付けられたリストの両方を備える場合、インデックスおよびハッシュは別々でもよく、またはハッシュにインデックス値がプリペンドされてもよい。

【0181】

第1のケースでは、スキーマの形式は、
BURI:[ブロック識別子]:[マークル証明データ]:[TxID]
であり、たとえば:
BURI:01111:0101:3be...f41/2ab...e5c/.../ff1...0de:jsf...38r

【0182】

ここで、BURIは、マークル証明ハッシュのフルセットの他にトランザクションのインデックスを含む。各ハッシュは、インデックス値(0101)に基づいて左または右の相手として割り当てられ得る。

【0183】

第2のケースでは、スキーマの形式は、
BURI:[ブロック識別子]:[マークル証明データ]:[TxID]
であり、たとえば、
BURI:01111:[0]3be...f41/[1]2ab...e5c/.../[1]ff1...0de:jsf...38r

【0184】

このBURI形式も、ハッシュのフルリストおよびインデックスを含み、対応するハッシュには、それが左の相手であるかまたは右の相手であるかを示すために各2進数字がプリペンドされている(たとえばハッシュ3be...f41に0がプリペンドされる)。

【0185】

各タイプのマークル証明データ、すなわちマークル証明ハッシュの有無による、は、他方のタイプに比べて利点を有する。
・効用 - ハッシュのリストを持つケースのBURIは、ユーザがいかなる第三者の支援もなしで標的トランザクションの存在の証明を独立して妥当性確認することを可能にする。これは、それにハッシュのないケースより有意に多くの効用を与える。
・サイズ - マークル証明ハッシュのフルセットの包含は、BURIにハッシュが含まれない場合においてよりBURIサイズが著しく大きいことを意味する。k個のマークル証明ハッシュのセットのサイズk×32バイトは、BURIの全体サイズにおける支配的な要因になるが、これは、それが含まれるブロックにおけるトランザクションnの数のk～log(n)として成長するだけである。
・複製 - 特定のトランザクションの中のコンテンツが複数回参照され得るので(たとえば同じ投稿に関してコメントする異なる人々によって)、オンチェーンで記憶されるあらゆるBURIが時間とともに複製されるおそれがある。これは、2つのタイプのマークル証明データの間のオンチェーンBURIの記憶コストの差を悪化させるだろうが、ハッシュを備えるBURIの複数のインスタンスがk×32のマークル証明全体をオンチェーンで重複させるだろう。
・持続性 - マークル証明全体をBURIにおいてオンチェーンに置くことは、ハッシュのないBURIによって参照されるコンテンツに対してより存在の証明が利用可能とされ、はるかに長く持続し得るという利益を有する。これは、以下で述べられるように、ハッシュを備えるBURIの方がリンク切れを解決する際に非常に良好であることを意味する。

【0186】

要約すると、BURIにマークル証明ハッシュを含めるか否かの選択は、BURIの作成者が達成したいと望むことに依存する。コストが主要な関心であれば、ハッシュのないBURIが好ましいかもしれないが、存在の証明の効用または長期持続性が関連するコストより重要であれば、ハッシュを備えるBURIが好ましいオプションであり得る。

【0187】

BURIの第4の構成要素はTxIDであり、標的ブロック内の標的トランザクションのトランザクション識別子を指し示す。上で述べられたように、これは、ブロックに一意であるので、ブロックチェーン上でトランザクションを見つけるために必要とされるBURIの唯一の構成要素である。しかしながら、ブロック識別子およびトランザクションインデックスは、これらの構成要素が標的トランザクションの位置についてのさらなる情報を提供して、標的トランザクションを見つけるために検索されるトランザクションおよびブロックの数を削減するので、標的トランザクションを見つける効率を改善する。

【0188】

トランザクションTxID₀だけが図10のブロックに示される。しかしながら、ブロックが複数のトランザクションをアレイ状に備えることが理解されるだろう。このトランザクションのアレイは、ブロックのペイロードと呼ばれる。

【0189】

追加の最後の構成要素であるフラグメント構成要素(図示せず)が、sBURIおよびBURIの両方のスキーマに含まれ得る。この構成要素は、ウェブページのサブセクションを特定すること、またはリソースへのロールベースのアクセスを可能にすることなどの、現代のインターネット上での既存のURL使用に即したURLの追加の機能を可能にする。

【0190】

URIスキームの形式は、次のように完全に書かれる:
BURI:[ブロック識別子]:[マークル証明データ]:[TxID][?details]
ここで[?details]構成要素は、フラグメント構成要素である。

【0191】

一般的なURI構文の「#fragment」構成要素は、標的リソース内の位置を指定するために「#」文字を使用する。たとえば、以下で示されるBitcoin SV wikiでは、URLはページを示し得るため、ページ上の特定のサブセクションまたはサブタイトルは、フラグメント名の始まりを意味する#文字で指定される。

【0192】

この形式を使用するURLのいくつかの例が、
https://wiki.bitcoinsv.io/index.php/Main_Page#Transactions
https://wiki.bitcoinsv.io/index.php/Opcodes_used_in_Bitcoin_Script#Stack
である。

【0193】

BURIの文脈では、これらの追加のフラグメントオプションは、特定の出力または出力内のデータプッシュなどの、標的トランザクションの具体的なトランザクションフィールドまたはデータ項目を見つけることに非常に役に立つ。そのようなBURI例は、前例を拡張して、
BURI:01111:0101:jsf...38r#0ut0#Push2
と書かれ得るが、ここで第1のフラグメント「#0ut0」は標的トランザクションのインデックス0における出力を特定し、第2のフラグメント「#Push2」はその出力のスクリプトの中の第2のプッシュデータ項目を特定する。このBURIの使用法を示す例示的なトランザクションのペアが以下に与えられており、第2のトランザクションTxID₂は、TxID₁の第0の出力の第2のデータプッシュを参照するためにBURIを使用する。

【0194】

【表6】

【0195】

【表7】

【0196】

したがってTxID₂のBURIは、具体的にはTxID₁の出力において提供される「段落2」を参照している。

【0197】

付属書Aでは、既存のURIスキーマ標準と本明細書で提示されるBURI方式の間の類似点を要約している。

【0198】

本明細書で提示されるBURIスキーマの主要な技術的利益は、次のように要約され得る。
・ブロックチェーン適合:BURIスキーマは、Bitcoinのようなブロックチェーンとして構築される、ブロックチェーンデータと適合するように設計されるURI標準である。
・データ完全性:スキーマは、URIによって標的とされるデータに関する存在の証明をユーザが検証するのを補助する情報を含む。これは、標的コンテンツの長期データ完全性を保証することによって既存のURI方式を改善し、これを達成するにはパブリックブロックチェーンの特性を活かす。
・重複排除:オンチェーンデータに対するBURIの提案された使用は、ユーザが、データに追加するときに(たとえばそれに関してコメントすることによる)データ自体を繰り返すのではなく、標的データをロバストに参照することを可能にすることによって、コンテンツデータの重複排除を容易にする。
・専門化を可能にする:BURIスキーマへの標的トランザクションインデックスとそのトランザクションIDの両方の組込みにより、マークル証明データを供給し得る第三者の間にさらなる専門化を可能にする。たとえば、種々のサービス提供者がインデックスおよびブロックハッシュに基づいてマークル証明の要求に応答するように専門化してよく、他者はTxIDだけに基づいて応答するだろう。この専門化はまた、サービスを提供する総コストを削減する最適化になり得る。
・「リンク切れ」を軽減する:URIスキーマ自体内に存在の証明のために必要とされるデータを含めることによって、ユーザは、特定のリソースが将来の任意の時点でもそのオンチェーン位置に存在したことを検証することが可能である。これは、インターネットリソースによる既存のリンク切れ問題を軽減し、それによりリソースは時間とともにリンクから消えてもよく、信頼されるサービス提供者が元のコンテンツを証明することを要求される。BURIスキーマは、これらの信頼される第三者への依存を排除してブロックチェーンネットワーク自体にデフォルト設定することによって、この問題を軽減するために、ブロックチェーンデータの不変性を使用する。
・柔軟性:BURIスキーマは一般的でありかつアプリケーションの必要に基づいて柔軟な実装を可能にする。これは、異なるユーザがサイズ/コストおよび効用の間の異なるトレードオフでBURIを作成する一方で、スキーマの最も一般的なインスタンスを使用してこれらの異なるBURI形式の間で変換することが可能であることを可能にする。

【0199】

標的ブロックおよび標的トランザクションは、本明細書でそれぞれ特定されたブロックおよび特定されたトランジションとも呼ばれ得る。BURIに少なくともトランザクション識別子を提供することによって、標的トランザクションは明示的に特定でき、そして、トランザクション識別子が標的トランザクションに一意であるので、標的トランザクションを備える標的ブロックも特定できる。BURIがブロック識別子も備える場合、標的ブロックは、標的トランザクションと独立して特定できる。

【0200】

例示的な使用事例
著者Bobがブロックチェーンを使用するソーシャルネットワーキングサイトに記事を追加することを考える。個人の読者、たとえばAliceが記事に関するコメントを作成して、それをブロックチェーン上に記録することを望む。

【0201】

記事およびコメントがブロックチェーンに記録されるので、それらは公的で、変化せず、したがって著作物として「不変性」を達成した。ブロックチェーンは、元の記事およびさらにあらゆるなされたコメントの「不変性」を確認する方法である。加えて、Aliceは、Bobにチップする自分のコメントにマイクロトランザクションを含めることを望んでもよく、コメントデータおよび支払の両方が単一のトランザクションで生じ得るので、ブロックチェーンが対話全体のための自然な選択肢となる。

【0202】

AliceおよびBobはパブリックアドレスを有しており、コメントがなされると彼らの間でトランザクションが発生し得る。

【0203】

この例では、Bobは、以前に記事を作成して、それをブロックチェーン上でトランザクションTxID₁に公開した。Bobのトランザクションはブロック401に公開され、ブロックにおいて150番目のトランザクションとして位置付けられた。Aliceは、今第2のトランザクションTxID₂を作成し、
○Bobの記事に関する自分のコメント、
○Bobの記事を参照するBURI、および
○Bobへのマイクロペイメント
を含める。

【0204】

Aliceによって作成されたトランザクションが以下に示される。

【0205】

【表8】

【0206】

Aliceのトランザクションの第1の出力は、BobへのV BSVのマイクロペイメントを含み、第2の出力は、Bobの記事を参照するBURIおよびその記事に関するAliceのコメントを含むOP_RETURNスクリプトを含む。

【0207】

ここに含まれるBURIは、Bobの元のトランザクションTxID₁のためのマークル証明ハッシュa4b...g10/.../e7a...24bの順序付けられたリストおよび前記トランザクションのインデックス150の両方を備える。ここでδがネットワークによってトランザクションが受け入れられるためのマイニングフィーであることに留意されたい。

【0208】

存在の証明
図11は、BURIが検証を実行するのに必要なデータを備えていない場合に標的トランザクションの存在を検証するための例示的な方法1100を示す。すなわち、検証を実行するためにマークル証明は第三者から取得されなければならない。

【0209】

ステップ1で、ユーザ103は、クライアント105にBURIを提供する。BURIは、参照トランザクションなどのブロックチェーントランザクションにユーザによって、またはウェブページからなど、インターネットを介して取得されてもよく、またはユーザ103は、関係情報を選択および/または入力することによってBURIを導出してもよい。

【0210】

クライアント105は、リゾルバ1102にデータ要求を送信する。要求はBURIを含んでもよい。代替として、クライアント105が、要求に入れて送信するためにBURIからBURIの構成要素を抽出してもよい。たとえば、BURIがブロック識別子、トランザクションインデックスおよびTxIDを備える場合、クライアント105は、これらの構成要素の各々を抽出して、構成要素の1つまたは複数をリゾルバ1102に送信してもよい。いくつかの実施形態では、リゾルバ1102にBURI、またはBURIの構成要素を送信する行為が要求である。

【0211】

リゾルバ1102は、ステップ3で、ブロックチェーンネットワーク106に標的トランザクションの標的データを要求する。この要求は少なくともTxIDを含み、その結果標的トランザクションを見つけることができる。要求は、標的ブロック識別子および/または標的トランザクションインデックスも備えてもよい。リゾルバ1102に利用可能であれば、標的ブロック識別子および/または標的トランザクションインデックスを使用することによって、標的トランザクションはより効率的に見つけることができる。

【0212】

標的データがブロックチェーン上で見つけられると、それはステップ4でブロックチェーンネットワーク106からリゾルバ1102に送信される。

【0213】

ステップ5で、リゾルバ1102は、証明提供者1104に標的トランザクションと関連付けられたマークル証明を要求する。証明提供者1104は、以下により詳しく説明されるようにマークル証明サーバでもよい。要求は少なくともTxIDを備える。それは、ブロック識別子および/またはトランザクションインデックスなど、標的トランザクションのマークル証明に関する記憶情報を見つけるために使用され得るリゾルバに利用可能な他のデータをさらに含んでもよく、よってマークル根を取得する効率を改善する。

【0214】

証明提供者1104は、TxIDおよび任意の他の受信データを使用してマークル証明を見つけ、ステップ6で、要求されたマークル証明をリゾルバ1102に送信する。証明提供者1104からリゾルバ1102に送信されるマークル証明は、マークル証明の順序付けられたハッシュのリストを備える。

【0215】

いくつかの場合、標的トランザクションインデックスも、証明提供者1104からリゾルバ1102に送信される。上で論じられたように、2進形式のトランザクションインデックスは、ノードが右の相手であるかまたは左の相手であるかを、したがってハッシュが右に連結されるべきかまたは左に連結されるべきかを示す。証明提供者1104はインデックスを2進形式で提供してもよく、またはそれは10進形式で提供されて後で2進へ変換されてもよい。

【0216】

BURIが標的トランザクションインデックスを備えない場合、標的トランザクションインデックスを送信することは特に重要である。BURIが10進形式の標的トランザクションインデックスを備える場合、2進インデックスは導出され得るため、したがって2進インデックスは証明提供者1104によって提供される必要はない。いくつかの実施形態では、証明提供者1104は、標的トランザクションインデックスを常に2進形式で提供する。

【0217】

リゾルバ1102がデータおよびマークル証明の両方を受信すると、ステップ7においてデータおよびマークル証明は、リゾルバ1102からクライアント105に送信される。

【0218】

クライアント105は、そしてステップ8で、トランザクションデータ、ハッシュのリスト、トランザクションインデックスおよび信頼されるマークル根を使用して、上で述べられたように、マークル証明を検証することが可能である。クライアント105は、それに利用可能なブロックヘッダのリストから信頼されるマークル根を取得する。これは、以下により詳しく説明されるように、クライアント105がSPVクライアントであるケースである。クライアント105によってブロックヘッダのリストにアクセスするための方法は当技術分野において知られている。

【0219】

クライアント105はまた、現在の最長のプルーフオブワークチェーンを知り得る。この場合、クライアント105によって取得される証明に対応するマークル根は、ステップ8で確かめられる。

【0220】

クライアント105がマークル証明を検証する場合、すなわちトランザクションデータおよびハッシュのリストから計算された計算マークル証明が標的トランザクションの信頼されるマークル証明と同じであれば、データがブロックチェーン上に存在することが検証される。

【0221】

データは、そしてステップ9においてクライアント105によってユーザ103に表示される。データが検証されたことを示す表示メッセージもクライアント105によってユーザ103に提供される。

【0222】

データが検証されない場合、この結果を示すメッセージがクライアント105によってユーザ103に表示される。トランザクションデータは、この失敗メッセージとともに、まだ表示されていてもよい。代替として、トランザクションデータは、それが検証されなければユーザ103に表示されなくてもよい。

【0223】

上の方法のステップが異なる順序で実行され得ることが理解されるだろう。たとえば、マークル証明を要求するステップは、ブロックチェーンネットワークにデータを要求するステップの前に、または同時に実行されてもよい。トランザクションデータおよびマークル証明は、別々のステップにおいてリゾルバからクライアントに送信されてもよく、たとえばデータおよびマークル証明は、リゾルバがそれぞれの情報を受信したらすぐに送信されてもよい。

【0224】

いくつかの実施形態では、ユーザは、クライアントにトランザクションデータを提供する。たとえば、ユーザは、BURIとともに、ウェブページを介してトランザクションデータにアクセスし、BURIおよびトランザクションデータの両方をクライアントに提供してもよい。クライアントは、この場合、計算マークル根を計算するためにブロックチェーンネットワークにデータを要求する必要がない。

【0225】

リゾルバは、ユーザがクライアントにトランザクションデータを提供する場合、それにもかかわらず、ブロックチェーンネットワークにトランザクションデータを要求し、それをクライアントに送信してもよい。そして、クライアントは、ユーザによって送信されたトランザクションデータがブロックチェーン上に記憶されるトランザクションデータであることを確認するためにトランザクションデータに追加のチェックを実行することができる。

【0226】

代替または追加として、クライアントは、予想される標的トランザクション識別子を生成するためにクライアントまたはリゾルバから受信されるトランザクションデータをハッシュしてもよい。これは、トランザクションデータをさらに検証するためにBURIの標的TxIDと比較することができる。

【0227】

いくつかの実施形態では、トランザクションデータは、計算マークル根を計算するために使用されない。代わりに、BURIにおいて提供されるTxIDがトランザクションデータのハッシュであるので、TxIDが使用される。

【0228】

ユーザに、たとえばウェブページを介して、トランザクションデータが提供され、BURIがマークルインデックスを備える場合、標的ブロックのペイロード、すなわちトランザクションにアクセスする必要がないことが留意されるだろう。

【0229】

BURIがマークル証明を備える場合、クライアント105は、リゾルバ1102を介して証明提供者1104にマークル証明を要求する必要はない。代わりに、BURIにおいて提供されるマークル証明が、データを検証するために使用される。

【0230】

したがって、いくつかの実施形態では、マークル証明およびデータが他の手段を介してクライアント105に利用可能であるので、データを検証するためにリゾルバ1102を使用する必要はないかもしれない。

【0231】

いくつかの実施形態では、ブロックヘッダおよび/またはマークル根は、ブロックチェーンネットワーク106または証明提供者1104から取得されてもよい。このマークル根は、マークル証明を検証するために使用されるのではなく、以下で述べられるように、さらなる検証として使用されてもよい。

【0232】

リゾルバ1102が図11において別個のエンティティとして示されるが、それは、データ要求を受けて(ステップ2)データおよびマークル証明の要求を実施する(それぞれステップ3および5)ことができるいかなるサービスであってもよい。たとえば、リゾルバ1102は、クライアントのウェブブラウザにおいてまたは検索エンジンによって実行されるコードでもよい。リゾルバ1102の機能は、クライアント105によって実行されてもよい。

【0233】

図11のシステムにおいて、クライアント105は、ブロックチェーンネットワーク106から取得されるデータの完全性を信頼しておらず、したがってデータ完全性は明示的に検証される必要がある。

【0234】

トランザクションデータは、ネットワーク上のいかなるノードまたはピアも意味する、ブロックチェーンネットワーク1106から取得されてもよい。ユーザ/クライアントは、それらがデータのソースを信頼していないので、それ自身の上のこのデータの完全性を信頼しておらず、それらがデータのためのマークル証明を検証する(ステップ8)ことができる場合にだけ、それらはそれを信頼し、そして対応するマークル根は、クライアント105に利用可能な最長のプルーフオブワークチェーン上のブロックヘッダにおいて見つけられる。

【0235】

上で言及された明示的な完全性チェックの利益は、トランザクションデータのソースに信頼の必要性が決して置かれず、このデータはいかなるソースからも取得され得るということである。

【0236】

リゾルバ1102もブロックチェーンネットワーク106上のピアからのデータのソースも図11のシステムにおいて信頼される必要がないが、但しクライアント/ユーザは、それらが正しいブロックヘッダリストを有していると確信している。

【0237】

マークル証明を提供し、したがって検証結果におけるユーザの信頼を改善するための第三者への依存を排除するために、ハッシュの順序付けられたリストは、BURIに含めることができる。

【0238】

図8は、BURIがハッシュの順序付けられたリストを備える場合にBURIを使用して標的トランザクションの存在を検証するために実行される例示的な方法800を示す。

【0239】

S802で、ユーザは、BURIを取得する。BURIは、参照トランザクション908を介してオンチェーンで取得されてもよく、またはBURIは、たとえばウェブページから、オフチェーンで取得されてもよい。

【0240】

標的トランザクションを見つけるために使用される位置情報がステップS804でBURIから抽出される。この位置情報はTxIDを備える。位置情報は、トランザクションインデックスおよび/またはブロック識別子をさらに備えてもよい。

【0241】

ステップS804で抽出された位置情報は、ステップS810で標的データをおよびステップS812でブロックヘッダを取得するためにブロックチェーン上で標的トランザクションを見つけるために使用される。

【0242】

ステップS806で、マークル証明がBURIから抽出される。この例におけるマークル証明は、トランザクションインデックスおよびハッシュの順序付けられたリストを備える。

【0243】

計算マークル根がステップS808で計算される。計算マークル根は、ステップS810において取得される標的トランザクションの標的データおよびBURIからのハッシュのリストを使用して計算される。標的データは、標的トランザクションに対応する葉ノードのハッシュを見つけるためにハッシュされる。計算されたマークル証明は、その後、図6を参照しつつ説明されるマークル木のパスに沿って順にハッシュが連結およびハッシュされることによって計算される。代替として、ステップS808において計算される標的データのハッシュの代わりに、標的トランザクションのハッシュであるTxIDが使用されてもよい。

【0244】

ステップS814で、計算マークル根は取得されたマークル根と比較される。取得されたマークル根は、クライアント105によって取得される標的ブロックのブロックヘッダにおいて規定される標的ブロックのマークル根である。ステップS814において使用される取得されたマークル根は、クライアント105に既知であるもの、またはクライアント105が、たとえばSPVクライアントとしてのその機能によって、アクセスするものである。すなわち、ステップS812で得られたブロックヘッダは、ステップS814の比較に使用されない。クライアント105は、たとえば、ブロックヘッダのリストにアクセスし、そしてマークルが抽出された対応するブロックヘッダを選択するためにBURIの少なくとも一部を使用してもよい。使用されるBURIの一部は、トランザクション特定部分またはブロック特定部分でもよい。

【0245】

これらの2つの根が同じであるかどうかがステップS816で判定される。根が同じである場合、計算マークル根を計算するために使用されたハッシュがブロックチェーン上に記憶されるブロックに対応するので、標的データは、ブロックチェーン上に存在するとして検証される、ステップS818。

【0246】

しかしながら、根が一致しないことがわかると、標的データはブロックチェーン上に存在せず、よって存在するとして検証されない、ステップS820。

【0247】

方法800において、マークル証明を抽出(S806)し、予想される根を計算(S808)し、根を比較(S816)し、そしてブロックチェーン上でのデータの存在を検証/非検証(S816、S818およびS820)するステップはオフチェーンで実行される一方で、標的ブロックを取得(S810)し、そしてブロックヘッダを取得(S812)することはオンチェーンで実行される。

【0248】

いくつかの実施形態では、ブロックヘッダは、オフチェーンソースから取得されてもよい。たとえば、ブロックヘッダは、上で説明されたように、マークル証明サーバから取得されてもよい。

【0249】

方法800のオフチェーンステップは、ユーザ103と関連付けられたクライアント105によって実行されてもよい。クライアントは、以下で述べられるように、トランザクションデータに関してさらなるチェックを実行するように構成されてもよい。

【0250】

方法800は、標的データがブロックチェーン上に存在するとして検証されるかどうかの指示をユーザに提供するステップをさらに備えてもよい。標的データが検証される場合、標的データはユーザに提示されるだけでもよい。

【0251】

いくつかの実施形態では、ブロックヘッダ全体を取得するのではなく、信頼されるマークル証明だけが取得される。他の実施形態では、ブロックヘッダもマークル根もブロックチェーンまたはブロックチェーンネットワークから直接には取得されない。

【0252】

いくつかの実施形態では、標的データは、ステップS810でブロックチェーンから取得されない。代わりに、標的データは、たとえばウェブページを介して、ユーザに提供されてもよい。提供されたトランザクションデータは、計算マークル根を計算するために使用することができる。このトランザクションデータは、データのさらなる検証としてハッシュされてBURIのTxIDと比較されてもよい。

【0253】

いくつかの実施形態では、標的データは、ブロックチェーンから取得されて、ユーザに提供されるトランザクションデータと比較される。データが一致しない場合、提供されたデータが検証されないことがユーザに通知されてもよく、および/または提供されたデータがユーザに表示されるのを妨げられてもよい。

【0254】

BURIから位置情報およびマークル証明を抽出するステップ、ステップS806およびS808は、BURIを、その中の区切り文字を特定するために構文解析すること、および区切り文字によって分割されるBURIの部分を抽出することを備える。

【0255】

本明細書で使用される「信頼されるマークル根」という用語は、比較ステップS814において使用されるマークル根を指し、本明細書では「取得されたマークル根」とも呼ばれる。「信頼される」という用語は、マークル根が真であると知られているという意味で根が信頼されることは必要としない。むしろ、それは信頼の相対レベルであり、信頼されるマークル根は、マークル証明から計算されるマークル根より信頼される。

【0256】

図7は、図11の方法を実施するための例示的なシステム600を示す。システムは、マークル証明エンティティ(またはマークル証明サーバ(MPS))601を備える。「マークル証明エンティティ」は、本明細書で説明される行為を実行するように構成されるエンティティのための便宜的なラベルとして使用されるにすぎないことに留意されたい。同様に、「マークル証明サーバ」という用語は、説明される行為がサーバ(すなわち、1つまたは複数のサーバユニット)によって実行されることを必ずしも意味しないが、それは1つのあり得る実装形態である。

【0257】

MPS601は、トランザクションがブロックチェーン150上に存在することの証明を提供するように構成される。MPS601は、トランザクション識別子(TxID)のセットを記憶するように構成される。各TxIDは、それぞれのトランザクションを一意に識別する。TxIDは、トランザクションのハッシュ(たとえば、ダブルハッシュ)である。MPS601は、ブロックチェーン150上で公開されるあらゆる単一のトランザクションのそれぞれのTxIDを記憶し得る。代替として、MPS601は、公開されるトランザクションのすべてではなく一部だけのそれぞれのTxIDを記憶してもよい。たとえば、MPS601は、何かが共通しているすべてのトランザクション、たとえば、特定のブロックからのすべてのトランザクション、(UNIX時間またはブロックの高さにおいて)ある時間の後に公開されるすべてのトランザクション、特定のブロックチェーンノード104によって公開される1つまたは複数のブロックからのすべてのトランザクションなどのそれぞれのTxIDを記憶し得る。

【0258】

MPS601はブロックチェーンノード104ではない。すなわち、MPS601はマイニングノードまたは「マイナー」ではない。MPS601は、ブロックチェーンノードによって操作され、またはそれに接続され得るが、MPS601自体が、プルーフオブワークを実行すること、ブロックを構築すること、ブロックを公開すること、コンセンサスルールを実施することなどの動作を実行することはない。いくつかの例では、MPS601はトランザクションを妥当性確認しない。しかしながら、MPS601がブロックを公開する動作を実行することなくトランザクションを妥当性確認し得ることは排除されない。

【0259】

その上、MPS601はブロックチェーン全体150を記憶する必要はないが、それは排除されない。すなわち、MPS601は公開されたトランザクションのすべてを記憶する必要はない。いくつかの例では、MPS601はどのようなトランザクションも記憶しない。または、MPS601は、公開されたトランザクションの選択された少数、たとえば1つまたは複数のコインベーストランザクションを記憶し得る。

【0260】

MPS601は、標的トランザクション識別子を取得するように構成される。たとえば、システム600は、1つまたは複数の要求側の関係者602を備え得る。要求側の関係者602は、標的トランザクションのためのマークル証明に対する要求の一部として、標的TxIDをMPS601に送信し得る。いくつかの例では、MPS601への標的TxIDの送信だけでも、マークル証明に対する要求として扱われる。要求側の関係者602に利用可能であれば、ブロック識別子およびトランザクションインデックスも要求に入れてMPS601に送信され得る。要求側の関係者602は、代替としてMPS601に完全なBURIを送信し得る。

【0261】

標的TxIDを受信するのではなく、MPS601は代わりに、自身で標的トランザクションを受信し得る。すなわち、要求側の関係者602が、標的トランザクションをMPS601に送信し得る。MPS601は次いで、標的トランザクションをハッシュ(たとえば、ダブルハッシュ)して標的TxIDを取得し得る。MPS601が標的TxIDと標的トランザクションの両方を受信し得ることも排除されない。この例では、MPS601は、標的トランザクションの(ダブル)ハッシュが標的TxIDと一致することを確認し、一致しない場合、要求側の関係者602に警告し得る。

【0262】

MPS601はまた、標的トランザクションのための「標的マークル証明」、すなわち、標的トランザクションがブロックチェーン上に存在することを証明するためのマークル証明を取得するように構成される。標的マークル証明は、対応するマークル木の葉が実際にはTxIDであるので、TxIDの記憶されているセットの1つまたは複数に基づく。マークル証明は上で説明されている。標的マークル証明は少なくとも、ハッシュ値の順序付けられたセットを備える。ハッシュ値の順序付けられたセットの中のハッシュ値の数は、マークル木の中の葉の数、すなわち、標的トランザクションを含むブロック151の中のトランザクションの数に基づく。マークル証明はまた、ハッシュ値の順序付けられたセットの中の第1のハッシュ値が標的TxIDの左に連結されるべきかまたは右に連結されるべきかを示す葉のインデックスを含み得る。すなわち、BURIは標的トランザクションインデックスを含まなくてもよく、代わりにこのインデックスはMPS601によって取得および提供される。

【0263】

MPS601は、各トランザクションのための(すなわち、各TxIDのための)それぞれのマークル証明を記憶し得る。この例では、標的マークル証明を取得することは、標的マークル証明をストレージから抽出することを備える。たとえば、MPS601は各トランザクションのためのマークル証明を事前に計算し得る。標的TxIDが取得されるとき、MPS601は対応するマークル証明を探す(各マークル証明はストレージの中のそれぞれのTxIDと関連付けられ得る)。

【0264】

各トランザクションまたはTxIDのためのそれぞれのマークル証明を記憶するのではなく、またはそれに加えて、MPSは1つまたは複数のマークル木を事前に計算して記憶し得る。各マークル木は、TxIDの記憶されているセットのサブセット、内部ハッシュ値(または内部ノード)のセット、およびマークル根を備える。この例では、標的マークル証明を取得することは、標的TxIDを含むマークル木からマークル証明(すなわち、必要とされるハッシュ値)を抽出することを備える。

【0265】

別の例として、MPS601は、標的TxIDを取得したことに応答して標的マークル証明を計算し得る。すなわち、MPS601は、TxIDの記憶されているセットの1つまたは複数を使用して、(たとえば、完全なマークル木を計算して必要とされているハッシュ値を抽出することによって)標的マークル証明を計算し得る。この方法は、MPS601が標的トランザクションを備えるブロック151からのTxIDのすべてをストレージに有することを必要とすることに留意されたい。

【0266】

標的マークル証明は、対応するマークル木の1つまたは複数の内部ハッシュ、または内部ノードを備え得る。その場合、BURIがトランザクションインデックスを2進形式で備えない場合、先行するハッシュ(たとえば、標的TxID)を内部ハッシュの左に連結するかまたは右に連結するかを要求側の関係者が知るように、それらの内部ハッシュのインデックスを要求側の関係者602に提供するのが有用である。したがって、標的マークル証明を抽出するとき、MPS601は、葉ハッシュのインデックス、すなわち標的トランザクションのTxIDを使用して、標的マークル証明の中の内部ハッシュのインデックスを計算する。MPSは、記憶されている木からマークル証明を抽出するためにこれらのインデックスを計算する必要があることがあり、すなわち、MPSは木を記憶しており、葉インデックスにより、正しいマークル証明を抽出するために木からどの内部ノードを選ぶべきかをMPSが決定することが可能になる。少なくともいくつかの例では、MPS601は標的TxIDのインデックスのみを計算すればよいことに留意されたい。必要とされる内部ハッシュを決定するには、この単一のインデックスで十分であり得る。

【0267】

MPS601はまた、標的マークル証明を出力するように構成される。たとえば、標的マークル証明は、要求側の関係者602に直接送信され得る。または、標的マークル証明は、たとえばウェブページで公開され得る。標的マークル証明は、標的トランザクションがブロックチェーン上に存在することの証明として使用され得る。

【0268】

いくつかの例では、MPS601はまた、標的トランザクションを含むブロック151のブロックヘッダからマークル根を出力する。マークル根は、マークル根を含むブロックヘッダの一部として、またはそれ自体で、またはブロックヘッダの1つまたは複数の他のデータフィールド、たとえば以前のブロックハッシュと組み合わせて、出力され得る。マークル根は、要求側の関係者602に直接出力され、または別様に公開され得る。

【0269】

MPS601は、対応するトランザクションがその中で公開されるブロックに基づいて、TxIDをサブセットに記憶し得る。すなわち、ブロックnからのトランザクションのTxIDは1つのサブセットに記憶されてもよく、ブロックn-1からのトランザクションのTxIDは異なるサブセットに記憶されてもよく、以下同様である。各サブセットの中のTxIDは順序付けられたリストに記憶されてもよく、TxIDの順序は所与のブロックの中の対応するトランザクションの順序と一致する。

【0270】

ブロックチェーン150の各ブロック151は、それぞれのブロックヘッダを備える。MPS601は1つまたは複数のブロックヘッダを記憶し得る。たとえば、MPS601は、それぞれの公開されるブロック151のためのブロックヘッダを記憶し得る。ブロックヘッダは、順序付けられたリストに記憶され得る。ブロックヘッダの順序は、ブロックチェーン150の中の対応するブロック151の順序と一致し得る。いくつかの例では、所与のブロック151からのTxIDは、そのブロック151のためのブロックヘッダと関連付けられて記憶され得る。

【0271】

セキュリティのために、ブロックヘッダ値を再現してプルーフオブワークを妥当性確認することが可能であるためには、ブロックヘッダのすべてのフィールドが記憶されるべきである。しかしながら、完全なブロックヘッダを記憶する代わりに、いくつかの例では、MPS601がブロックヘッダのデータフィールドのすべてではなく1つまたは複数だけを記憶し得ることが排除されない。たとえば、MPS601は、ブロックヘッダ内に含まれるマークル根だけを記憶し得る。または、MPS601は、ブロックヘッダ内に含まれるマークル根および以前のハッシュを記憶し得る(ブロックヘッダnに記憶されている以前のハッシュはn-1番目のブロックヘッダに等しい)。

【0272】

MPS601は、ブロックチェーンネットワーク106から、たとえばブロックチェーンノードから、記憶されているTxIDの一部またはすべてを取得し得る。TxIDのすべてが、単一のブロックチェーンノード104から取得され得る。代替として、TxIDは複数のノードから取得されてもよく、たとえば、1つのブロックチェーンノードからの何か、異なるブロックチェーンノードからの何かなどであってもよい。同じことがブロックヘッダに当てはまる。すなわち、記憶されているブロックヘッダの一部またはすべて(または記憶されているマークル根および/または以前のブロックハッシュだけ)が、単一のブロックチェーンノード104から、または複数のノード104から取得され得る。いくつかの例では、MPS601は、同じブロックチェーンノード104からの所与のブロック(および任意選択でそのブロックのブロックヘッダ)からすべてのトランザクションのTxIDを取得し得る。

【0273】

いくつかの例では、MPS601は、複数のノード104から同じTxIDおよび/またはブロックヘッダを取得することによって、取得されたTxIDおよび/またはブロックヘッダの一部またはすべてを検証し得る。

【0274】

追加または代替として、図7に示されるように、ブロックヘッダの一部またはすべてが、1つまたは複数のsimplified payment verification(SPV)クライアント604から取得され得る。SPVクライアントは、ブロックチェーンのブロックヘッダの1つ、いくつか、またはすべてを記憶し、SPV方法を実行するように構成される、クライアントアプリケーションである。詳細については、たとえばhttps://wiki.bitcoinsv.io/index.php/Simplified_Payment_Verificationを参照されたい。たとえば、MPS601は、SPVクライアントを操作してもよく、または異なるエンティティ(必ずしも異なるMPSではない)によって操作されるSPVクライアントへの接続を有してもよい。

【0275】

上で言及されたように、MPS601は1つまたは複数のトランザクション、すなわち生のトランザクションデータを記憶し得る。たとえば、MPS601はブロック当たり1つのトランザクションを記憶し得る。MPS601は、各ブロックのためのコインベーストランザクションを記憶し得る(ブロック当たり1つだけのコインベーストランザクションがあることを思い出されたい)。しかしながら、MPS601がコインベーストランザクション以外のトランザクションを記憶し得ること、または、MPS601がいくつかのブロックのそれぞれのコインベーストランザクション、および他のブロックの異なるトランザクションを記憶し得ることが排除されない。

【0276】

所与のブロックのための記憶されているトランザクションは、「第1のトランザクション」と呼ばれる。これは、ブロックにおいて最初に現れるトランザクションを必ずしも意味しないが、コインベーストランザクションではそうである。これらの例では、MPS601は、標的トランザクションと同じブロックにおいて公開される第1のトランザクションのためのマークル証明を取得し得る。MPS601は次いで、第1のトランザクション自体と一緒に、第1のトランザクションのためのマークル証明を、たとえば要求側の関係者602に出力し得る。これは、標的マークル証明の長さが正しいことを検証するために、要求側の関係者602によって使用され得る。たとえば、第1のトランザクションのためのマークル証明の長さが10(たとえば、10個のハッシュ値)である場合、標的マークル証明の長さも10であるべきである。

【0277】

MPS601は、デスクトップコンピュータ、ラップトップコンピュータ、タブレット、スマートフォン、スマートウォッチなどのウェアラブルスマートデバイス、または車などの車両のオンボードコンピュータなどの、1つまたは複数のユーザ端末を備える(たとえば、図1に示されるものと同様の)コンピューティング装置の形態をとる。追加または代替として、コンピューティング装置はサーバを備え得る。本明細書では、サーバは、1つまたは複数の地理的な敷地に位置する1つまたは複数の物理サーバユニットを備え得る論理エンティティを指す。必要とされる場合、分散型または「クラウド」コンピューティング技法はそれら自体が当技術分野において知られている。1つもしくはまたは複数のユーザ端末および/またはサーバの1つもしくは複数のサーバユニットが、パケット交換ネットワークを介して互いに接続されてもよく、これは、たとえば、インターネット、3GPP(登録商標)ネットワークなどのモバイルセルラーネットワーク、イーサネットネットワークなどの有線ローカルエリアネットワーク(LAN)、またはWiFi、Thread、もしくは6LoWPANネットワークなどのワイヤレスLANなどのワイヤレスLANなどの、ワイドエリアインターネットワークを備えてもよい。コンピューティング装置は、コントローラおよびインターフェースを備える。コントローラは、インターフェース204に動作可能に結合される。コントローラは、MPSに起因する行為を実行するように構成される。インターフェースは、データ、たとえばTxID、ブロックヘッダ、マークル証明などを送信する、かつ受信するように構成される。

【0278】

コントローラおよびインターフェースの各々は、コンピュータ可読ストレージ上で具現化され、CPUなどの1つまたは複数のプロセッサ、GPUなどのワークアクセラレータコプロセッサ、および/または他の特定用途向けプロセッサを備える処理装置上で実行され、1つまたは複数の地理的な敷地にある1つまたは複数のコンピュータ端末またはユニット上で実装される、ソフトウェアコードの形態で実装され得る。コードが記憶されるストレージは、やはり1つまたは複数の地理的な敷地にある1つまたは複数のコンピュータ端末またはユニット上で実装される、1つまたは複数のメモリ媒体(たとえば、電子または磁気媒体)を利用する1つまたは複数のメモリデバイスを備え得る。実施形態では、コントローラおよび/またはインターフェースはサーバ上で実装され得る。代替として、これらのコンポーネントの一方または両方のそれぞれのインスタンスは、1つまたは複数のユーザ端末の1つ、いくつか、またはすべての各々で、一部が実装されることがあり、または全体が実装されることすらある。さらなる例では、上で言及されたコンポーネントの機能は、ユーザ端末およびサーバのあらゆる組合せの間で分割されてもよい。やはり、必要とされる場合、分散型コンピューティング技法は、それら自体が当技術分野において知られていることに留意されたい。これらのコンポーネントの1つまたは複数が専用ハードウェアにおいて実装され得ることも、排除されない。

【0279】

ここで、要求側の関係者602が説明される。要求側の関係者602は、マークル証明に対する要求をMPS601に送信するように構成される。要求側の関係者602は、標的TxIDおよび/または標的トランザクションをMPS601に送信し得る。それに応答して、要求側の関係者は、標的マークル証明を受信し、または別様に取得するように構成される。要求側の関係者602は、上で説明されたように、標的トランザクションがブロックチェーン上で存在することを証明するために、標的マークル証明を使用し得る。

【0280】

いくつかの例では、要求側の関係者602は、1つまたは複数の親トランザクションの存在を証明するために、標的マークル証明を使用し得る。この場合、標的トランザクションが子トランザクションである場合、標的マークル証明は、親トランザクションの各々がブロックチェーン150上で公開されたことを証明する(親トランザクションの各々がブロックチェーン150上で公開されることなく、子トランザクションがブロックチェーン150上で公開されたことはあり得ない)。一般に、トランザクションのチェーンにおける直近の公開されたトランザクションのためのマークル証明は、そのチェーンの中のすべての他のトランザクションの存在を証明する。

【0281】

要求側の関係者602はSPVクライアントであり得る(またはそれを操作し得る)。すなわち、SPVクライアント(たとえば、消費者によって操作される)は、SPV方法を実行するための標的マークル証明を使用し得る。この場合、標的トランザクションは、受信者にロックされるUTXOを備える消費トランザクションによって参照される、消費者にロックされるUTXOを備え得る。

【0282】

要求側の関係者602は、ウォレットアプリケーションであり得る(またはそれを操作し得る)。ウォレットアプリケーションは、標的トランザクションを記憶し得る。オンラインモードまたはオンライン状態(すなわち、MPS601に接続されている)では、ウォレットアプリケーションは、標的トランザクションのための標的マークル証明を取得し得る。ウォレットアプリケーションは次いで、オフラインモードまたはオフライン状態(すなわち、MPS601に接続されていない)で動作してもよく、ウォレットアプリケーションは、標的トランザクションがブロックチェーン上で存在することの証明として、標的トランザクションおよび標的マークル証明を要求側の関係者602に提供し得る。

【0283】

要求側の関係者602は、Alice 103aまたはBob 103bの形態をとり得る。

【0284】

一般MPS
一般MPS601は、受信側の関係者、たとえばユーザにマークル証明を提供するための専用サーバとして作動する。すなわち、一般MPS601は、トランザクションがブロックチェーン上で公開される場合、所与のトランザクションまたはトランザクションIDのためのマークル証明を提供するサーバである。一般MPS601は、完全なトランザクションデータを記憶しない。それは、マークル木のストレージを用いてブロックチェーンネットワークの中のSPVクライアントを補完するものとして見なされ得る。より正確には、一般MPSには以下に列挙されるストレージ要件がある。
1.プルーフオブワークが最大のチェーンを表すブロックヘッダの順序付けられたリスト(任意選択の要件)
2.各ブロックヘッダのためのトランザクションIDの順序付けられたリスト(中核の要件)
3.マークル根がブロックヘッダにおいて指定されるものと一致するような、各ブロックヘッダのための事前に計算されたマークル木(任意選択の要件)
4.各ブロックの中のコインベーストランザクションの生のデータまたは各ブロックヘッダのためのブロックの中のトランザクションのあらゆる生のデータ(任意選択の要件)

【0285】

第1の要件は、一般MPS601のデータ完全性を確保することである。ブロックヘッダの中のマークル根は、トランザクションIDのリストに対する完全性の確認として使用され得る。すなわち、マークル木の葉を形成するときに所与のブロックからのTxIDがブロックヘッダの中のマークル根を与えることを確認するために、ブロックヘッダが使用され得る。たとえば、TxIDが信用される場合、または一般MPS601が、信用されるSPVクライアントへの、もしくはプルーフオブワークが最大のチェーンのブロックヘッダを記憶しているものと信用されるあらゆるエンティティへの、セキュアなアクセス権を有する場合、第1の要件は省略され得る。

【0286】

第2の要件は中核であり、それは、この要件によりマークル葉がマークル木において現れる順序でマークル葉が与えられ、マークル木を再構築できるようになるからである。コインベーストランザクションIDは常に、リストの中の第1の葉または第1のハッシュであることに留意されたい。葉の順序は、勝利したブロックを構築したブロックチェーンノードによって決定される。Bitcoin SVでは、この順序はトポロジカルな順序およびfirst-seenルールを反映すべきである。

【0287】

第3の要件は、計算とストレージのトレードオフに対する選択肢を提供する。図12はストレージ要件を示し、実線のボックスは(いくつかの例では)必須であり、破線のボックスは任意選択である。ブロックヘッダは、示されるものに追加のフィールドを含むが、一般に、ルートハッシュのみがマークル証明のために必要とされることに留意されたい。以前のハッシュは、ルートハッシュをインデクシングするために使用され得る。重要な点は、一般MPS601がマークル木の内部ノードを記憶する必要がないということである。ブロックヘッダにおいてプルーフオブワークへのリンクを証明するには、ブロックヘッダのフィールドのすべてが必要とされることに留意されたい。「Prev Hash」フィールドが取り上げられており、それは、それがブロックヘッダ間のチェーン関係を示すからである。「Root Hash」フィールドが取り上げられており、それは、それがマークル木へのリンクを示すからである。しかしながら、プルーフオブワークへのリンクは、すべてのブロックヘッダ構成要素が提供されるときにのみ妥当性確認され得る。

【0288】

第4の要件は、マークル木の深さの証明を提供することである。これは、一般MPS601によってそのユーザに提供され得る追加のサービスである。トランザクションの生データを提示されると、いずれの検証者も、そのマークル証明の中の第1のハッシュが実際に葉であることに納得することができ、それは、葉ではない所与のハッシュ値に対して意味のあるトランザクションを構築するのは計算的に実現不可能であるからである。その上、マークル証明の長さはマークル木の深さを示唆するので、同じ木からのすべてのマークル証明は同じ長さを有する。このサービスは、ユーザが関心対象のトランザクションの生データを持たないときには特に有用である。

【0289】

トランザクションID、たとえばTxID₁が与えられると、一般MPS601は、トランザクションIDの順序付けられたリストを調査する。一般MPS601がTxID₁を発見する場合、それは、TxID₁のためのマークル証明を構築または抽出し、出力する。それ以外の場合、一般MPS601は、たとえば「トランザクションが見つかりません」を出力する。トランザクションの生データが与えられると、一般MPS601は、データをハッシュして対応するトランザクションIDを取得し、上記のように進行することができる。

【0290】

新しいブロックが公開されると、一般MPS601は以下のものを取得する。
1.新しいブロックヘッダ、
2.新しいブロックのためのトランザクションIDの順序付けられたリスト、および
3.生のコインベーストランザクション。

【0291】

一般MPS601は任意選択で、以下のことを確認し得る。
1.新しいブロックヘッダが有効なプルーフオブワークを有する、
2.トランザクションIDから計算されるマークル根がブロックヘッダの中のマークル根に等しい、および
3.コインベーストランザクションのハッシュが葉の中の第1の要素に等しい。

【0292】

注意-サーバが生のトランザクションを得るための、またはトランザクションに対して署名検証を行うための要件はない。

【0293】

以下は、マークル木の深さを提供することがなぜ価値のあるサービスであるかを説明する。SPVクライアントは、トランザクションIDおよびマークル証明を入力として取り込み、マークル根がブロックヘッダの1つにおけるマークル根と一致する場合には真を出力し、それ以外の場合には偽を出力する。しかしながら、この検証は、必要な情報の欠如により、マークル証明の長さがマークル木の長さと一致するかどうかを確認しない。場合によっては、敵対者が、存在しないトランザクションIDが存在することを証明しようとして、短縮されたマークル証明を提出する可能性がある。この短縮されたマークル証明は、葉または後続のハッシュを完全に除去することによって得ることができる。

【0294】

マークル証明提供者としての一般MPS601は、マークル証明の長さを検証するために必要とされる情報を提供するのに、最良の立場にある。マークル木の深さを明示的に提供するのではなく、一般MPS601は、コインベーストランザクションの生データおよびそのマークル証明を提供する。生のトランザクションデータおよびマークル証明を偽造することは計算的に実現不可能である。したがって、それはマークル木の深さの証明として機能する。木の深さを知ることは、上で言及された重大な脆弱性を軽減することができる。SPVが関心対象のトランザクションの生データおよびマークル証明を提供されれば、SPVはこの脆弱性に対してセキュアであることに留意されたい。SPVが関心対象のトランザクションの生データを有しないとき、マークル木の深さまたはこのマークル木に関するマークル証明の正しい長さを確立するために、コインベーストランザクションの生データおよびそのマークル証明を使用することができる。

【0295】

理論的には、この脆弱性は、その葉またはあらゆる後続のレベルが完全に除去されるようなマークル木を受け入れるように一般MPS601を騙すためにも使用され得る。しかしながら、一般MPS601は、受信される情報の一貫性および正しさを確保するために、複数のブロックチェーンノード104に接続し得る。その上、一般MPS601はまた、新しいブロックのためのマークル木の深さを検証するために、コインベーストランザクションの生データをダウンロードすることを選ぶこともできる。

【0296】

時には、一般MPS601は、競合するブロック、再編成、およびオーファンブロックに対処しなければならないことがあり、これらは、同じブロック高さに対して1つより多くのブロックが同時に見つかるときに起こる。幸い、この状況は、直近のヘッダを除けば起こらず、稀にしか起こらない。ブロックチェーン150は通常、1ブロックは2ブロック後に競合するチェーンのうちの1つに収束する。したがって、一般MPS601が1つより多くのブロック151を同じ高さで受信するとき、それは、プルーフオブワークが最大のチェーンへとブロックチェーンネットワークが収束するまでそれらのすべてを維持する。

【0297】

ストレージの節約
現在、BSVグローバル台帳には全体でおよそ5億個のトランザクションがある(BTCについても同様のオーダーの数字である)。全体のTxIDは、およそ15GBのストレージ空間を必要とする。BSVブロックチェーン自体は、現在224GBである。一般MPS601は、ブロックチェーン全体の6.7%を記憶することが必要である。その上、ストレージは、サイズではなくトランザクションの数に依存する。ブロックの高さが638009であり、ブロックヘッダが80バイトである場合、ブロックヘッダは49MBのストレージを必要とし、毎年4MBが追加される。

【0298】

一般MPS601がマークル証明生成を加速するためにマークル木の事前に計算された部分を記憶することになる場合、ルートノードの後の第1の層は、2つのノードからなり、木当たり2×32バイトを必要とする。よって、ブロックヘッダの80バイトに連結される64バイトは、MPSが任意のtxのマークル枝を生成するときに1回のハッシュ計算を節約する。すなわち、MPSはヘッダ当たり80バイトではなく144バイトを使用する。マークル木の第2の層は、4つのノードからなり、すなわちヘッダ当たり272バイトである。以下同様である。第10の層は、ヘッダ当たり65552バイトを必要とし、必要とされるストレージは全体で39GBに増える。これはTXIDの15GBを含むべきであり、各ブロックが1024個のトランザクションを有することを仮定している。

【0299】

TxIDのみのMPSの制約
説明されるような一般MPS601にはいくつかの制約がある。公開されないトランザクション、たとえばTxID_paymentを与えられると、一般MPS601は、入力において参照される出力点が存在することを検証することができない。理由は、出力点がトランザクションIDおよびインデックスの連結であるからである。一般MPS601は、トランザクションIDが存在するかどうかを決定することが可能であるが、トランザクションが有する出力の数、および出力が消費可能であるかどうかについての情報を持たない。これを克服する1つの方法は、TxID_paymentにおいて参照されるトランザクションの生データを、入力の一部として一般MPS601に提供することである。代替の方法は、一般MPS601が未消費のトランザクションの生データを記憶することである。(ここで、未消費のトランザクションは、少なくとも1つの未消費の消費可能な出力を有するトランザクションを指す。)

【0300】

一般MPS601がトランザクションIDおよび対応するインデックスのみを記憶する場合、一般MPS601は、インデックスが改竄されていないことを検証または証明できないことに留意されたい。一般MPS601は、インデックスの完全性を検証または証明するために、完全な生データを必要とする。

【0301】

その上、それは、ロッキングスクリプトまたはフラグなどのトランザクションの内部の特定のデータ要素をユーザが探すことを実現することはできない。したがって、それは、たとえばユーザがブルームフィルタを使用するのをサポートすることはできず、それは、ブルームフィルタが、トランザクションに含まれるロッキングスクリプトおよび公開鍵に通常は基づいてトランザクションをフィルタリングするからである。

【0302】

これにより、より詳細なレベルで情報を提供できるMPSが必要になる。これを完全性MPSと呼ぶ。完全性MPSは、一部のトランザクションの生データを記憶する。一般MPS601は、完全なトランザクションがユーザにより与えられる場合に、公開されたトランザクションの完全性を証明するために使用され得ることに留意されたい。完全性MPSは、関心対象の完全なトランザクションを記憶することによって、公開されたトランザクションから抽出された一部のデータの完全性を証明するために使用され得る。それは、ユーザが完全なトランザクションを提示することを必要としない。

【0303】

完全性MPS
完全性MPSは、関心対象のトランザクションのセットのための生のトランザクションおよびそれらの対応するマークル証明を記憶する。このセットの中のトランザクションについてのクエリのために、このサーバは、生のトランザクションおよびそのマークル証明を、その完全性の証明として提供することができる。それは、トランザクションの内容の中の部分的なトランザクションまたはデータ要素を探すことも可能にする。関心対象のトランザクションは、Weather SV、Tokenized、Metanet、または任意の他のデータプロトコルなどのデータアプリケーションに基づいて決定されることがあり、または、ロッキングスクリプト、公開鍵、出力点などのデータストリングに基づいて決定されることすらある。したがって、Weather SVのみを搬送するトランザクションを記憶するように構成されるWeather SVアプリケーションだけのための完全性MPSがあり得る。

【0304】

関心対象の生のトランザクションのセットは、完全性MPSに渡されて、公開される場合にはサーバに存続する。完全性MPSは、ゲートウェイとして見なすことができ、または特定用途向けトランザクションのためのゲートウェイへのアクセス権を有する。ブロックチェーンシステムがテラバイトブロックへとスケーリングするとき、これは完全性MPSを維持するための最も効率的な方法である。完全に非集権化されたピアツーピアデータ応用などの他の事例では、トランザクションの完全なブロックをダウンロードする機構に頼り、ブルームフィルタを使用したビットコイン改善提案37(BIP37)におけるように、関心対象ではないものを枝刈りし、またはそれらをフィルタリングしなければならない。

【0305】

動作中
関心対象の生のトランザクションおよびマークル木におけるそれらのマークル証明を維持する完全性MPSは、いくつかの実施形態では以下のステップを実行する。
ステップ1:関心対象の生のトランザクションを取得する。
ステップ2:生のトランザクションをハッシュしてトランザクションIDを取得する。
ステップ3:一般MPS601にそのマークル証明についてクエリする。
ステップ4:トランザクションがブロックにおいて公開されない場合、10分待ち再び試す。

【0306】

ステップ3における一般MPS601への依存は、ダウンロードおよび枝刈りの機構により置き換えられ得るが、これはより効率が低い。ステップ4における公開されないトランザクションは、混雑を避けるためにあらかじめ定義された時間制限の後で省略され得る。この制限は、適用例ごとに変動し得る。

【0307】

トランザクションは、そのマークル証明を提供することによって、ブロックチェーン150上で公開されることが証明され得る。代替として、それはその消費される出力の1つを通じて証明され得る。トランザクションtx_iの出力がトランザクションtx_jにおいて消費されるとき、tx_iを親トランザクションと呼び、tx_jを子トランザクションと呼ぶ。トランザクションが複数の出力を有することは、それが複数の子を有し得ることを示唆する。トランザクションが複数の入力を有することは、それが複数の親を有し得ることを示唆する。トランザクションの生データが利用可能である場合、このトランザクションのマークル証明は、そのすべての親が公開されていることを証明するのに十分であり、親のマークル証明を記憶する必要はない。

【0308】

実際には、トランザクションのチェーンがある場合、チェーンの最後のトランザクションのマークル証明およびすべてのトランザクションの生データがチェーンにおけるすべてのトランザクションの存在を証明できると述べることによって、上記の考察を一般化することができる。

【0309】

これにより、トランザクションのマークル証明を除去し、それをその子のいずれかのマークル証明で置き換えることが可能になる。これは、次の場合に有用になる。
1.ブロックサイズ - 子トランザクションが親トランザクションよりはるかに小さいブロックにおいて公開され、この場合、子トランザクションおよびそのマークル証明の全体のサイズは、親トランザクションのためのマークル証明のサイズより小さい、または、
2.複数の入力 - 子トランザクションが異なるトランザクションからの複数の入力を有し、この場合、子トランザクションおよびそのマークル証明の全体のサイズは、その親トランザクションのためのすべてのマークル証明の全体のサイズより小さい。

【0310】

たとえば、ある特定の適用例では、すべてのトランザクションが専用のマークル証明出力を有し得る。時々、これらの出力は1つの子トランザクションにおいて収集され消費される。子トランザクションおよびそのマークル証明は、すべてのその親トランザクションの完全性および存在を証明することが可能である。したがって、親トランザクションのいずれのマークル証明も記憶しなくてもよい。

【0311】

提供されたデータから導かれ得る証明を列挙する以下の表において、考察を要約することができる。

【0312】

【表9】

【0313】

この表は、以下の場合に出力が存在することが証明されることを示す。
1.生のトランザクションが提供され、トランザクションが存在する場合、または
2.既存のトランザクションの支払においてその出力または高インデックスの出力が使用される場合。

【0314】

結論
開示される技法の他の変形または使用事例は、本明細書の開示を与えられれば当業者に明らかになり得る。本開示の範囲は、説明される実施形態ではなく、添付の特許請求の範囲だけによって限定される。

【0315】

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

【0316】

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

【0317】

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

【0318】

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

【0319】

上記の実施形態は、単なる例として説明されたことが理解されるだろう。より一般的には、以下の陳述の任意の1つまたは複数に従った方法、装置、またはプログラムが提供され得る。

【0320】

陳述1 特定されたトランザクションがブロックチェーンに記憶されていることを検証するためのコンピュータで実施される方法であって、方法が、ブロックチェーンユニフォームリソースインジケータ(BURI)文字列を取得するステップと、BURI文字列を構文解析して、その中の区切り文字を特定し、それにより区切り文字によって分離されている1つまたは複数のマークル証明部分およびトランザクション識別子部分を抽出するステップであって、マークル証明部分が、特定されたトランザクションが特定されたブロックに属することを検証するためのものである、ステップと、BURIの少なくとも一部を使用して、マークル根ハッシュを取得するステップと、マークル証明部分を使用して、トランザクション識別子部分がマークル根ハッシュに対して有効であるかどうかを決定し、それにより、特定されたブロックのペイロードにアクセスすることなく、BURI文字列を使用して特定されたトランザクションを検証するステップとを備える、方法。

【0321】

陳述2 BURI文字列が、ブロックチェーンに記憶されている後続のトランザクションにおいて受信されるまたはそれから抽出される、陳述1の方法。

【0322】

陳述3 1つまたは複数のマークル証明部分が、特定されたトランザクションのマークルインデックスを備える、陳述1または陳述2に記載の方法。

【0323】

陳述4 1つまたは複数のマークル証明部分が、特定されたトランザクションがマークル根ハッシュによって検証されるかどうかを決定するために必要とされるマークル証明ハッシュのサブセットをさらに備える、陳述3に記載の方法。

【0324】

陳述5 方法が、第三者コンピューティングデバイスから、特定されたトランザクションがマークル根ハッシュによって検証されるかどうかを決定するために必要とされるマークル証明ハッシュのサブセットを取得するステップであって、第三者コンピューティングデバイスに、マークルインデックスおよびトランザクション識別子部分を送信するステップと、第三者コンピューティングデバイスから、特定されたトランザクションがマークル根ハッシュによって検証されるかどうかを決定するために必要とされるマークル証明ハッシュのサブセットを受信するステップとを実施することによって、取得するステップをさらに備える、陳述3に記載の方法。

【0325】

陳述6 第三者コンピューティングデバイスが、それぞれのブロックチェーントランザクションのそれぞれのブロックチェーントランザクション識別子のトランザクション識別子のセットを記憶するが、ブロックチェーンネットワークに新しいブロックチェーンブロックを公開しないように構成されるマークル証明エンティティである、陳述5に記載の方法。

【0326】

陳述7 マークルインデックスが2進形式である、陳述3またはそれに従属するいずれかの陳述に記載の方法。

【0327】

陳述8 BURI文字列を構文解析して、その中の区切り文字を特定するステップが、それによりブロック識別部分をさらに抽出する、任意の先行する陳述に記載の方法。

【0328】

陳述9 参照ブロックチェーントランザクションであって、参照ブロックチェーントランザクションの第1のインデックスにおける出力に、特定されたブロックにブロックチェーン上で以前に記憶された特定されたトランザクションを参照するためのブロックチェーンユニフォームリソースインジケータ(BURI)文字列を備え、BURIがトランザクション識別子部分およびさらなる部分を備え、トランザクション識別子部分およびさらなる部分が少なくとも1つの区切り文字によって分離されており、さらなる部分が特定されたトランザクションをさらに定義するための階層的構成要素である、参照ブロックチェーントランザクション。

【0329】

陳述10 さらなる部分が、少なくとも1つの区切り文字によってトランザクション識別子部分から分離されている、1つまたは複数のマークル証明部分を備える、陳述9に記載の参照ブロックチェーントランザクション。

【0330】

陳述11 1つまたは複数のマークル証明部分が、特定されたブロックにおける特定されたトランザクションのマークルインデックスを備える、陳述10に記載の参照ブロックチェーントランザクション。

【0331】

陳述12 1つまたは複数のマークル証明部分が、特定されたトランザクションが前記特定されたブロックのマークル根ハッシュによって検証されるかどうかを決定するために必要とされるマークル証明ハッシュのサブセットをさらに備える、陳述11に記載の参照ブロックチェーントランザクション。

【0332】

陳述13 マークルインデックスが2進形式である、陳述11または陳述12に記載の参照ブロックチェーントランザクション。

【0333】

陳述14 マークルインデックスの各2進数字が、ハッシュの順序付けられたリストのうちの対応するハッシュにプリペンドされる、陳述12および13に記載の参照ブロックチェーントランザクション。

【0334】

陳述15 ブロック識別部分が、特定されたブロックのブロック番号である、陳述9から14のいずれかに記載の参照ブロックチェーントランザクション。

【0335】

陳述16 ブロック識別部分が、特定されたブロックのブロックヘッダハッシュである、陳述9から14のいずれかに記載の参照ブロックチェーントランザクション。

【0336】

陳述17 BURIが、少なくとも1つの区切り文字によってトランザクション識別子部分および1つまたは複数のマークル証明部分から分離されている、ブロック特定部分をさらに備える、陳述10から16のいずれかに記載の参照ブロックチェーントランザクション。

【0337】

陳述18 BURIが、特定されたトランザクションのフラグメントを特定するためのフラグメント部分をさらに備える、陳述9から17のいずれかに記載の参照ブロックチェーントランザクション。

【0338】

陳述19 特定されたトランザクションに記憶されているデータを検証エンティティに通信するコンピュータで実施される方法であって、方法が、区切り文字によって分離されている1つまたは複数のマークル証明部分およびトランザクション識別子部分を備えるブロックチェーンユニフォームリソースインジケータ(BURI)文字列を生成するステップであって、マークル証明部分が、特定されたトランザクションが特定されたブロックに属することを検証するためのものである、ステップと、データにアクセスするための検証エンティティにBURIを利用可能にするステップとを備える、方法。

【0339】

陳述20 BURIを利用可能にするステップが、BURIをブロックチェーンのトランザクションに記憶するステップを備える、陳述19に記載のコンピュータで実施される方法。

【0340】

陳述21 1つまたは複数のマークル証明部分が、特定されたトランザクションのマークルインデックスを備える、陳述19または陳述20に記載のコンピュータで実施される方法。

【0341】

陳述22 1つまたは複数のマークル証明部分が、特定されたトランザクションがマークル根ハッシュによって検証されるかどうかを決定するために必要とされるマークル証明ハッシュのサブセットをさらに備える、陳述21に記載のコンピュータで実施される方法。

【0342】

陳述23 1つまたは複数のメモリユニットを備えるメモリと、1つまたは複数の処理ユニットを備える処理装置とを備え、メモリが、処理装置上で実行するようになされるコードを記憶し、コードが、処理装置上で実行されると、陳述1から8のいずれかまたは陳述19から22のいずれかの方法を実行するように構成される、コンピュータ機器。

【0343】

陳述24 コンピュータ可読ストレージ上に具現化され、1つまたは複数のプロセッサ上で実行されると、陳述1から8のいずれかまたは陳述19から22のいずれかの方法を実行するように構成される、コンピュータプログラム。

【0344】

付属書A
以下の表は、既存のURIスキーマ標準と本明細書で提示されるBURI方式の間の類似点を要約している。

【0345】

【表10】

【0346】

本明細書で開示されるBURIの第1の要素はブロック識別子であり、通常のインターネットベースのURIにおける「権限(authority)」に相当する。ここでの類似は、BURIの正当性を生成および検証する際に使用され得る、現在のブロックヘッダの最長チェーンに関する真実の権威源を提供し得る、Bitcoinノードネットワーク内の、およびそれと対話しているエージェントによりなされ得る。

【0347】

たとえば、BURIのブロック識別子構成要素は、マイナーID標準の下で特定可能なマイナーなど、その情報の特定の信頼される提供者と関連付けられ得る。特定のブラウザは、複数のそのようなマイナーがSPVパラダイムに合わせて正規のブロックヘッダの最新リストを保ち、Bitcoinマイニングネットワークの有意な部分がBURIスキーマにおけるブロック識別子と関連付けられた「権限」になることを意味するよう、問い合わせるように設計され得る。

【符号の説明】

【0348】

100 システム
101 ブロックチェーンネットワーク、パケット交換ネットワーク、インターネット
102 コンピュータ機器、コンピュータ端末
103 ユーザ、関係者
104 ブロックチェーンノード
105 クライアントアプリケーション
106 ピアツーピア(P2P)ネットワーク、ネットワーク
150 ブロックチェーン
151 ブロック
152 トランザクション
153 ジェネシスブロック
154 セット、プール
155 ブロックポインタ
201 ヘッダ
202 入力フィールド、入力
203 出力フィールド、出力、トランザクション出力、UTXO
450 ノードソフトウェア
451 プロトコルエンジン
452 スクリプトエンジン
453 スタック
454 アプリケーションレベル判定エンジン
455 ブロックチェーン関連機能モジュールのセット
455C コンセンサスモジュール
455P 伝搬モジュール
455S 記憶モジュール
500 UI
501 UI要素
502 UI要素
503 UI要素
600 システム
601 マークル証明エンティティ、マークル証明サーバ(MPS)、マークルパスサーバ
602 要求側の関係者
604 simplified payment verification(SPV)クライアント
800 方法
902 標的トランザクション
904 より前のトランザクション
906 参照トランザクション
908 BURI
1100 方法
1102 リゾルバ
1104 証明提供者
1106 ブロックチェーンネットワーク

【図1】

【図2】

【図3A】

【図3B】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【国際調査報告】