JP2023547716A - マークル証明エンティティ - Google Patents

マークル証明エンティティ Download PDF

Info

Publication number
JP2023547716A
JP2023547716A JP2023527773A JP2023527773A JP2023547716A JP 2023547716 A JP2023547716 A JP 2023547716A JP 2023527773 A JP2023527773 A JP 2023527773A JP 2023527773 A JP2023527773 A JP 2023527773A JP 2023547716 A JP2023547716 A JP 2023547716A
Authority
JP
Japan
Prior art keywords
transaction
blockchain
target
merkle
proof
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2023527773A
Other languages
English (en)
Inventor
ウェイ・ジャン
バッセム・アマール
ジャック・オーウェン・デイヴィーズ
クレイグ・スティーヴン・ライト
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nchain Holdings Ltd
Original Assignee
Nchain Holdings Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nchain Holdings Ltd filed Critical Nchain Holdings Ltd
Publication of JP2023547716A publication Critical patent/JP2023547716A/ja
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/245—Query processing
    • G06F16/2455—Query execution
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Theoretical Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Data Mining & Analysis (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computational Linguistics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

ブロックチェーントランザクションがブロックチェーン上に存在することの証明を提供するコンピュータで実施される方法であって、方法が、それぞれのブロックチェーントランザクションのトランザクション識別子のセットを記憶するが、新しいブロックチェーンブロックをブロックチェーンネットワークに公開しないように構成されるマークル証明エンティティによって実行され、方法が、ターゲットブロックチェーントランザクションのターゲットトランザクション識別子を取得するステップであって、ターゲットトランザクション識別子がトランザクション識別子の記憶されているセットの一部を形成する、ステップと、ターゲットブロックチェーントランザクションのためのターゲットマークル証明を取得するステップであって、対応するターゲットマークルルートがブロックチェーンのブロックヘッダ内に含まれる、ステップと、ターゲットブロックチェーントランザクションがブロックチェーン上に存在することの証明として要求側の当事者が使用するためのターゲットマークル証明を出力するステップとを備える。

Description

本開示は、ブロックチェーントランザクションがブロックチェーン上に存在することの証明を提供して取得する方法に関する。
ブロックチェーンとは、ある形式の分散型データ構造を指し、ブロックチェーンの複製は、分散型ピアツーピア(P2P)ネットワーク(以下では「ブロックチェーンネットワーク」と呼ばれる)の中の複数のノードの各々において維持され、広く公開される。ブロックチェーンは、データのブロックのチェーンを備え、各ブロックは、1つまたは複数のトランザクションを備える。いわゆる「コインベーストランザクション」以外の各トランザクションは、1つまたは複数のコインベーストランザクションまで戻る1つまたは複数のブロックにまたがり得るシーケンスの中の先行するトランザクションを指し示す。コインベーストランザクションは以下でさらに論じられる。ブロックチェーンネットワークに出されるトランザクションは、新しいブロックに含まれる。新しいブロックは「マイニング」と呼ばれることが多い処理により作成され、これは、複数のノードの各々が競争して「プルーフオブワーク」を実行すること、すなわち、ブロックチェーンの新しいブロックに含められることを待機している、順序付けられ承認された未処理のトランザクションの定められたセットの表現に基づいて、暗号パズルを解くことを伴う。ブロックチェーンは一部のノードにおいて枝刈りされてもよく、ブロックの公開はブロックヘッダだけの公開により達成され得ることに留意されたい。
ブロックチェーンにおけるトランザクションは、デジタル資産(すなわち、ある数のデジタルトークン)を運ぶこと、仮想化された台帳もしくは登録簿の仕訳のセットを順序付けること、タイムスタンプエントリを受信して処理すること、および/またはインデックスポインタを時間的に順序付けることという、目的のうちの1つまたは複数のために使用され得る。ブロックチェーンは、ブロックチェーンに追加の機能を重ねるためにも利用され得る。たとえば、ブロックチェーンプロトコルは、トランザクションにおける追加のユーザデータまたはデータに対するインデックスの記憶を可能にし得る。単一のトランザクションに記憶され得る最大のデータ容量にはあらかじめ指定された限界はないので、ますます複雑になるデータを組み込むことができる。たとえば、これは、ブロックチェーンの中の電子文書、またはオーディオデータもしくはビデオデータを記憶するために使用され得る。
ブロックチェーンネットワークのノード(「マイナー」と呼ばれることが多い)は、後でより詳しく説明される、分散型のトランザクションの登録および検証のプロセスを実行する。要約すると、この処理の間に、ノードはトランザクションを承認し、それらをブロックテンプレートに挿入し、ノードはそのブロックテンプレートについて有効なプルーフオブワークの解を特定することを試みる。有効な解が見つかると、新しいブロックがネットワークの他のノードに広められるので、各ノードがブロックチェーンに新しいブロックを記録することを可能にする。トランザクションがブロックチェーンに記録されるようにするために、ユーザ(たとえば、ブロックチェーンクライアントアプリケーション)は、トランザクションが広められるように、それをネットワークのノードのうちの1つに送信する。トランザクションを受信するノードは競って、承認されたトランザクションを新しいブロックへ組み込むプルーフオブワークの解を見つけることができる。各ノードは同じノードプロトコルを実施するように構成され、これは、トランザクションが有効になるための1つまたは複数の条件を含む。無効なトランザクションは、広められることも、ブロックに組み込まれることもない。トランザクションが承認され、それによりブロックチェーン上で受け入れられると仮定すると、トランザクション(あらゆるユーザデータを含む)は、イミュータブルな公開記録としてブロックチェーンネットワークの中のノードの各々において登録されインデクシングされたままになる。
最新のブロックを作成するためにプルーフオブワークパズルを解くことに成功したノードは通常、ある金額のデジタル資産、すなわちある数のトークンを分配する「コインベーストランザクション」と呼ばれる新しいトランザクションにより報酬を受ける。無効なトランザクションの検出および拒絶は、ネットワークのエージェントとして活動し不正を報告して阻止する動機のある、競合するノードの活動によって実施される。情報を広く公開することで、ユーザはノードの実績を継続的に監査することが可能になる。ブロックヘッダのみの公開により、参加者はブロックチェーンの完全性が継続中であることを確実にすることが可能になる。
「出力ベース」モデル(UTXOベースのモデルと呼ばれることがある)では、所与のトランザクションのデータ構造は、1つまたは複数の入力および1つまたは複数の出力を備える。あらゆる消費可能な出力は、トランザクションの先行するシーケンスから導出可能であるデジタル資産の金額を指定する要素を備える。消費可能な出力は、UTXO(「未消費トランザクション出力」)と呼ばれることがある。出力はさらに、出力のさらなる引き換えのための条件を指定するロックスクリプトを備え得る。ロックスクリプトは、デジタルトークンまたは資産を承認して移すために必要な条件を定義する述部である。トランザクション(コインベーストランザクション以外)の各入力は、先行するトランザクションにおけるそのような出力へのポインタ(すなわち、参照)を備え、指し示された出力のロックスクリプトをロックを解除するためのロック解除スクリプトをさらに備え得る。よって、トランザクションのペアを考え、それらを第1のトランザクションおよび第2のトランザクション(または「ターゲット」トランザクション)と呼ぶ。第1のトランザクションは、デジタル資産の金額を指定し、出力をロック解除する1つまたは複数の条件を定義するロックスクリプトを備える、少なくとも1つの出力を備える。第2のターゲットトランザクションは、第1のトランザクションの出力へのポインタと、第1のトランザクションの出力をロックを解除するためのロック解除スクリプトとを備える、少なくとも1つの入力を備える。
そのようなモデルでは、第2のターゲットトランザクションが、ブロックチェーンにおいて広められて記録されるようにブロックチェーンネットワークに送信されるとき、各ノードにおいて適用される有効性の基準の1つは、ロック解除スクリプトが第1のトランザクションのロックスクリプトにおいて定義される1つまたは複数の条件のすべてを満たすというものである。別の基準は、第1のトランザクションの出力が別のより前の有効なトランザクションによってまだ引き換えられていないということである。これらの条件のいずれかに従ってターゲットトランザクションが無効であることを見出したいずれのノードも、トランザクションを広めず(場合によっては無効なトランザクションを登録するために有効なトランザクションとして広めない)、またブロックチェーンに記録されるべき新しいブロックにトランザクションを含めない。
代替のタイプのトランザクションモデルは、アカウントベースのモデルである。この場合、各トランザクションは、過去のトランザクションのシーケンスの中の先行するトランザクションのUTXOを参照することによってではなく、絶対的なアカウント残高を参照することによって、移されるべき金額を定義する。すべてのアカウントの現在の状態が、ブロックチェーンとは別に、ノードによって記憶され、定期的に更新される。
マークル証明(merkle proof)は、ブロックチェーン上にトランザクションが存在することを検証するために一般に使用される。ブロックチェーン上に特定のトランザクションが存在することを検証したい当事者(たとえば、ユーザ)は、ブロックチェーンノードからのマークル証明を探すことができる。受信されたマークル証明を使用して、ブロックチェーンのブロックに含まれるマークル証明と一致する値へとトランザクションを追跡できる場合、ユーザは、トランザクションがブロックチェーン上に存在することを確信できる。絶対的な確実性のためには、追加の確認が必要であり得ることに留意されたい。
現在、マークル証明を提供するエンティティのみが、ブロックチェーンノード(マイナーとしても知られている)である。上で言及されたように、ブロックチェーンノードは、トランザクションの承認、ならびにブロックの構築および公開が主な役割である。
ブロックチェーン技術の使用は増大し続けているので、ブロックチェーンシステムは増大する使用量および需要に見合うようにスケーリングすることが可能でなければならない。ブロックチェーンシステムをスケーリングすることの1つの手法は、ブロックのサイズ、トランザクションのレートを拡大すること、および様々なデータ応用のための変更不可能な台帳としてブロックチェーン技術を使用することである。これは、ブロックチェーンのサイズ、およびトランザクションの承認に対して消費される処理の量を劇的に増やす。したがって、ブロックチェーン全体を記憶し、トランザクションを承認し、トランザクションに対するクエリに応答するためのリソースは、エンドユーザおよびサービス提供者にとって(ストレージおよび処理要件の点で)あまりにも高価であり得る。したがって、ブロックチェーン全体を記憶する必要なく、トランザクションがブロックチェーン上に存在することの証明を提供できるエンティティが必要である。
したがって、トランザクションがブロックチェーン上に存在することの証明を提供できる、よりリソース効率の高いエンティティが必要である。
本明細書で開示される一態様によれば、ブロックチェーントランザクションがブロックチェーン上に存在することの証明を提供するコンピュータで実施される方法が提供され、方法は、それぞれのブロックチェーントランザクションのトランザクション識別子のセットを記憶するが、新しいブロックチェーンブロックをブロックチェーンネットワークに公開しないように構成されるマークル証明エンティティによって実行され、方法は、ターゲットブロックチェーントランザクションのターゲットトランザクション識別子を取得するステップであって、ターゲットトランザクション識別子がトランザクション識別子の記憶されているセットの一部を形成する、ステップと、ターゲットブロックチェーントランザクションのためのターゲットマークル証明を取得するステップであって、対応するターゲットマークルルートがブロックチェーンのブロックヘッダ内に含まれる、ステップと、ターゲットブロックチェーントランザクションがブロックチェーン上に存在することの証明として要求側のエンティティが使用するためのターゲットマークル証明を出力するステップとを備える。
マークル証明サーバ(MPS)とも以下で呼ばれるマークル証明エンティティは、新しいブロックチェーンブロックを構築すること、および/またはそれをブロックチェーンネットワークに公開する必要なく、要求側の当事者にマークル証明を提供することが可能であるので、ブロックチェーンノードよりリソース集約的ではない。新しいブロックをブロックチェーンネットワークに公開することは、ブロックチェーン上でブロックにおいてまだ公開されていないトランザクションを備えるまだ見られていないブロックを分配することを意味する。その上、いくつかの例では、MPSはブロックチェーン全体を記憶する必要がないので、ブロックチェーンノードと比較してストレージの要件が大きく低下する。データストレージ、データ検索、およびデータ取り出しが、関連する情報のみを記憶することによって最適化され、この場合、その関連する情報は記憶されているトランザクション識別子程度に少ない。
MPSは、あらゆる公開されたトランザクションのマークル証明を、そのトランザクションのそれぞれのトランザクション識別子だけ(すなわち、トランザクションデータ自体ではなく)を記憶することによって提供し得る。いくつかの事例では、MPSは、ブロックチェーントランザクションの特定のセット、たとえば特定のアプリケーションまたはサービスに関連するもの、たとえばTokenizedまたはMetanetトランザクションのトランザクション識別子のみを記憶し得る。そして、TokenizedまたはMetanetトランザクションの存在を検証するために、MPSが使用され得る。
MPSは、すべての公開されたトランザクション(または少なくとも公開されたトランザクションのセット)のトランザクションID(TxID)を記憶するために必要とされる。MPSは、トランザクション識別子(TxID)またはトランザクション全体によるクエリをサポートする。
MPSは、ブロックチェーン上でブロックを構築および/または公開する動作を実行しない。言い換えると、マークル証明エンティティはブロックチェーンノードではない。いくつかの例では、マークル証明エンティティはいずれのブロックチェーントランザクションも記憶しない。他の例では、マークル証明エンティティは、ブロックごとに1つのブロックチェーントランザクションだけを記憶する。さらに他の例では、マークル証明エンティティは、ブロックごとに1つよりは多いがすべてではないブロックチェーントランザクションを記憶する。
本明細書で開示される別に態様によれば、ブロックチェーントランザクションがブロックチェーン上に存在することの証明を取得するコンピュータで実施される方法が提供され、マークル証明エンティティは、それぞれのブロックチェーントランザクションのトランザクション識別子のセットを記憶し、マークル証明エンティティは、それぞれのブロックチェーントランザクションのトランザクション識別子のセットを記憶するが、新しいブロックチェーンブロックをブロックチェーンネットワークに公開しないように構成され、方法は、要求側の当事者によって実行され、マークル証明エンティティに、ターゲットブロックチェーントランザクションおよび/またはターゲットトランザクションのターゲットトランザクション識別子を送信するステップと、マークル証明エンティティから、ターゲットブロックチェーントランザクションのためのターゲットマークル証明を取得するステップであって、マークル証明がトランザクション識別子の記憶されているセットの1つまたは複数に基づく、ステップとを備える。
本開示の実施形態の理解を助けるために、およびそのような実施形態がどのように具体化され得るかを示すために、単なる例として、添付の図への参照が行われる。
ブロックチェーンを実装するためのシステムの概略ブロック図である。 ブロックチェーンに記録され得るトランザクションのいくつかの例を概略的に示す図である。 クライアントアプリケーションの概略ブロック図である。 図3Aのクライアントアプリケーションによって提示され得る例示的なユーザインターフェースの概略的なモックアップの図である。 例示的なマークルツリーを概略的に示す図である。 例示的なマークルツリーを概略的に示す図である。 本発明のいくつかの実施形態による例示的なシステムを概略的に示す図である。 本発明のいくつかの実施形態による例示的なシステムを概略的に示す図である。 本発明のいくつかの実施形態によるマークル証明エンティティによって記憶されるデータを概略的に示す図である。 本発明のいくつかの実施形態による例示的な方法を示す図である。
例示的なシステムの概要
図1は、ブロックチェーン150を実装するための例示的なシステム100を示す。システム100は、通常はインターネットなどのワイドエリアインターネットワークである、パケット交換ネットワーク101を備え得る。パケット交換ネットワーク101は、パケット交換ネットワーク101内でピアツーピア(P2P)ネットワーク106を形成するように並べられ得る複数のブロックチェーンノード104を備える。示されていないが、ブロックチェーンノード104は準完全グラフとして並べられ得る。したがって、各ブロックチェーンノード104は、他のブロックチェーンノード104に高度に接続される。
各ブロックチェーンノード104は、ピアのコンピュータ機器を備え、異なるノード104は異なるピアに属する。各ブロックチェーンノード104は、1つまたは複数のプロセッサ、たとえば1つまたは複数の中央処理装置(CPU)、アクセラレータプロセッサ、特定用途向けプロセッサおよび/またはフィールドプログラマブルゲートアレイ(FPGA)、ならびに特定用途向け集積回路(ASIC)などの他の機器を備える、処理装置を備える。各ノードはまた、メモリ、すなわち、非一時的コンピュータ可読媒体の形態のコンピュータ可読ストレージを備える。メモリは、1つまたは複数のメモリ媒体、たとえば、ハードディスクなどの磁気媒体、ソリッドステートドライブ(SSD)、フラッシュメモリ、もしくはEEPROMなどの電子媒体、および/または高金額ディスクドライブなどの光学媒体を利用する、1つまたは複数のメモリユニットを備え得る。
ブロックチェーン150はデータのブロック151のチェーンを備え、ブロックチェーン150のそれぞれのコピーが、分散ネットワークまたはブロックチェーンネットワーク101の中の複数のブロックチェーンノード104の各々において維持される。上で言及されたように、ブロックチェーン150のコピーを維持することは、ブロックチェーン150を完全に記憶することを必ずしも意味しない。代わりに、ブロックチェーン150は、各ブロックチェーンノード150が各ブロック151のブロックヘッダ(以下で論じられる)を記憶する限り、データを枝刈りされ得る。チェーンの中の各ブロック151は1つまたは複数のトランザクション152を備え、この文脈においてトランザクションはある種のデータ構造を指す。データ構造の性質は、トランザクションモデルまたはスキームの一部として使用されるトランザクションプロトコルのタイプに依存する。所与のブロックチェーンは、1つの特定のトランザクションプロトコルを全体で使用する。ある一般的なタイプのトランザクションプロトコルにおいて、各トランザクション152のデータ構造は、少なくとも1つの入力および少なくとも1つの出力を備える。各出力は、ある数量のデジタル資産を表す金額を財産として指定し、その例は、出力が暗号によりにロックされる対象であるユーザ103である(アンロック、および引き換えまたは消費のために、そのユーザの署名または他のソリューションを必要とする)。各入力は、先行するトランザクション152の出力を指し示し、それによりそれらのトランザクションをつなぐ。
各ブロック151はまた、ブロック151に対する逐次的な順序を定義するために、チェーンの中の以前に作成されたブロック151を指し示すブロックポインタ155を備える。各トランザクション152(コインベーストランザクション以外)は、トランザクションのシーケンスに対する順序を定義するために、以前のトランザクションへのポインタを備える(トランザクション152のシーケンスは分岐することが許容されることに留意されたい)。ブロック151のチェーンは、チェーンにおいて最初のブロックであったジェネシスブロック(Gb)153まで戻る。チェーン150の初期の1つまたは複数の元のトランザクション152は、先行するトランザクションではなくジェネシスブロック153を指し示していた。
ブロックチェーンノード104の各々は、トランザクション152を他のブロックチェーンノード104に転送し、それにより、トランザクション152がネットワーク106全体に広められるようにするように構成される。各ブロックチェーンノード104は、ブロック151を作成し、同じブロックチェーン150のそれぞれのコピーをそれぞれのメモリに記憶するように構成される。各ブロックチェーンノード104はまた、ブロック151へと組み込まれるのを待機しているトランザクション152の順序付けられたセット(または「プール」)154を維持する。順序付けられたプール154は、「メモリプール」と呼ばれることが多い。本明細書におけるこの用語は、任意の特定のブロックチェーン、プロトコル、またはモデルに限定することを意図しない。それは、ノード104が有効であるものとして受け入れた、かつ同じ出力を消費することを試みる他のトランザクションをノード104が受け入れることが義務付けられない、トランザクションの順序付けられたセットを指す。
所与の現在のトランザクション152jにおいて、入力(または各入力)は、トランザクションのシーケンスの中の先行するトランザクション152iの出力を参照するポインタを備え、これは、この出力が現在のトランザクション152jにおいて引き換えられる、または「消費される」ことになることを指定する。一般に、先行するトランザクションは、順序付けられたセット154または任意のブロック151における任意のトランザクションであり得る。先行するトランザクション152iは、現在のトランザクション152iが作成される時点で、またはネットワーク106に送信される時点ですら、必ずしも存在する必要はないが、現在のトランザクションが有効になるためには、先行するトランザクション152iが存在して承認される必要がある。したがって、本明細書における「先行する」は、ポインタにより連結される論理シーケンスにおいて先行するものを指し、時間的な順序における作成または送信の時間を必ずしも指さず、したがって、トランザクション152i、152jが順不同で作成または送信されることを必ずしも排除しない(オーファントランザクションについての以下の議論を参照)。先行するトランザクション152iは同様に、祖先トランザクションまたは先行者トランザクションと呼ばれ得る。
現在のトランザクション152jの入力はまた、入力承認、たとえば、先行するトランザクション152iの出力がロックされる対象であるユーザ103aの署名を備える。そして、現在のトランザクション152jの出力は、新しいユーザまたはエンティティ103bに暗号によりロックされ得る。したがって、現在のトランザクション152jは、現在のトランザクション152jの出力において定義されるような新しいユーザまたはエンティティ103bに、先行するトランザクション152iの入力において定義される金額を移すことができる。いくつかの場合、トランザクション152は、複数のユーザまたはエンティティ(そのうちの1つは、残金を与えるために元のユーザまたはエンティティ103aであり得る)の間で入力の金額を分割するために、複数の出力を有し得る。いくつかの場合、トランザクションはまた、1つまたは複数の先行するトランザクションの複数の出力からの金額を一緒に集めて、現在のトランザクションの1つまたは複数の出力を再分配するために、複数の入力を有し得る。
ビットコインなどの出力ベースのトランザクションプロトコルによれば、個々のユーザまたは組織などの当事者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のネットワーク全体に広められる。
出力ベースのモデルにおいて、所与の出力(たとえば、UXTO)が割り当てられる(たとえば、消費される)かどうかの定義は、それがブロックチェーンノードプロトコルに従って別の前方のトランザクション152jの入力によりすでに有効に引き換えられているかどうかである。トランザクションが有効になるための別の条件は、そのトランザクションが割り当てることまたは引き換えることを試みる先行するトランザクション152iの出力が、別のトランザクションによってまだ引き換えられていないことである。やはり、有効ではない場合、トランザクション152jは、ブロックチェーン150において広められず(無効であるものとしてフラグを立てられて警告のために広められない限り)、または記録されない。これは、取引者が同じトランザクションの出力を一度より多く割り当てることを試みるような、二重消費から守る。一方、アカウントベースのモデルは、アカウント残高を維持することによって二重消費から守る。やはり、トランザクションの定められた順序があるので、アカウント残高は任意のある時間において単一の定められた状態を有する。
トランザクションを検証することに加えて、ブロックチェーンノード104はまた、マイニングと一般に呼ばれるプロセスにおいて、トランザクションのブロックを最初に作成するのを競い、これは「プルーフオブワーク」により支援される。ブロックチェーンノード104において、新しいトランザクションは、ブロックチェーン150に記録されているブロック151にまだ表れていない有効なトランザクションの順序付けられたプール154に追加される。そして、ブロックチェーンノードは、暗号パズルを解こうとすることによって、トランザクションの順序付けられたセット154からトランザクション152の新しい有効なブロック151を競って組み立てる。通常、これは、「ノンス」が未処理のトランザクションの順序付けられたプール154の表現と連結されてハッシュされると、ハッシュの出力が所定の条件を満たすような、ノンス値を探すことを備える。たとえば、所定の条件は、ハッシュの出力がある定められた数の先頭の0を有するということであり得る。これは、プルーフオブワークパズルの1つの具体的なタイプにすぎず、他のタイプが排除されないことに留意されたい。ハッシュ関数の性質は、それがその入力に関して予測不可能な出力を有するというものである。したがって、この探索は、ブルートフォースによってのみ実行することができるので、パズルを解こうとしている各ブロックチェーンノード104において大量の処理リソースを消費する。
パズルを解こうとする第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において順序付けられるブロックに記録されるので、これはトランザクションのイミュータブルな公開台帳を提供する。
任意の所与の時間において競ってパズルを解く異なるブロックチェーンノード104は、それらのブロックチェーンノードがいつ解の探索を始めたか、またはトランザクションが受信された順序に応じて、任意の所与の時間におけるまだ公開されていないトランザクション154のプールの異なるスナップショットに基づいて、競ってパズルを解いていることがあることに留意されたい。それぞれのパズルを最初に解いた者が、どのトランザクション152が次の新しいブロック151nに含まれるか、およびどの順序で含まれるかを定義し、公開されていないトランザクションの現在のプール154は更新される。ブロックチェーンノード104は次いで、公開されていないトランザクション154の新しく定義された順序付けられたプールからブロックを競って作成し続け、以下同様である。生じ得るあらゆる「フォーク」を解決するためのプロトコルも存在し、これは、2つのブロックチェーンノード104が互いに非常に短い時間内にパズルを解き、その結果、ブロックチェーンの矛盾する景色がノード104間で広められるようになる状況である。つまり、フォークの先端がより長く成長した方が、最終的なブロックチェーン150になる。同じトランザクションが両方のフォークに現れるので、これはネットワークのユーザまたはエージェントに影響しないはずであることに留意されたい。
ビットコインブロックチェーン(および大半の他のブロックチェーン)では、新しいブロック104の構築に成功するノードは、追加の定められた量のデジタル資産を分配する新しい特別な種類のトランザクション(あるエージェントまたはユーザから別の者にある金額のデジタル資産を移転するエージェント間またはユーザ間トランザクションではなく)において、追加の受け入れられる金額のデジタル資産を新しく割り当てるための能力を与えられる。この特別なタイプのトランザクションは通常、「コインベーストランザクション」と呼ばれるが、「開始トランザクション」または「生成トランザクション」とも呼ばれることがある。それは通常、新しいブロック151nの最初のトランザクションを形成する。プルーフオブワークは、この特別なトランザクションが後で引き換えられることを可能にするプロトコルルールに従うという、新しいブロックを構築するノードの意図を示すものである。ブロックチェーンプロトコルルールは、この特別なトランザクションを引き換えられるようになるまで、成熟期間、たとえば100ブロックを必要とし得る。しばしば、通常の(非生成)トランザクション152はまた、そのトランザクションが公開されたブロック151nを作成したブロックチェーンノード104にさらに報酬を与えるために、その出力の1つにおいて追加のトランザクションフィーを指定する。この料金は普通は「トランザクションフィー」と呼ばれ、以下で論じられる。
トランザクションの承認および公開に関与するリソースにより、典型的にはブロックチェーンノード104の少なくとも各々が、1つまたは複数の物理サーバユニットを備えるサーバという形態をとり、またはデータセンター全体という形態すらとる。しかしながら、原理的には、あらゆる所与のブロックチェーンノード104は、一緒にネットワーク接続されたユーザ端末またはユーザ端末のグループという形態をとり得る。
各ブロックチェーンノード104のメモリは、それぞれの役割を実行し、ブロックチェーンノードプロトコルに従ってトランザクション152を扱うように、ブロックチェーンノード104の処理装置上で実行するように構成される、ソフトウェアを記憶する。ブロックチェーンノード104に対する本明細書に起因するあらゆる活動が、それぞれのコンピュータ機器の処理装置で実行されるソフトウェアによって実施され得ることが理解されるだろう。ノードソフトウェアは、アプリケーションレイヤにおける1つまたは複数のアプリケーションで、またはオペレーティングシステムレイヤもしくはプロトコルレイヤなどのより低次のレイヤで、またはこれらの任意の組合せで実装され得る。
消費するユーザの役割を果たす複数の当事者103の各々のコンピュータ機器102も、ネットワーク101に接続される。これらのユーザは、ブロックチェーンネットワーク106と対話し得るが、トランザクションの検証またはブロックの構築には参加しない。これらのユーザまたはエージェント103の一部は、トランザクションにおいて送信者または受信者として活動し得る。他のユーザは、必ずしも送信者または受信者として活動することなく、ブロックチェーン150と対話し得る。たとえば、一部の当事者は、ブロックチェーン150のコピーを記憶する(たとえば、ブロックチェーンノード104からブロックチェーンのコピーを取得した)ストレージエンティティとして活動し得る。
当事者103の一部またはすべてが、異なるネットワーク、たとえばブロックチェーンネットワーク106に重畳されるネットワークの一部として接続され得る。ブロックチェーンネットワークのユーザ(「クライアント」と呼ばれることが多い)は、ブロックチェーンネットワーク106を含むシステムの一部であると言われることがある。しかしながら、これらのユーザはブロックチェーンノード104ではなく、それは、ブロックチェーンノードに必要とされる役割を実行しないからである。代わりに、各当事者103は、ブロックチェーンネットワーク106と対話し、それにより、ブロックチェーンノード106に接続する(すなわち、それと通信する)ことによって、ブロックチェーン150を利用し得る。第1の当事者103aおよびそのそれぞれのコンピュータ機器102a、ならびに第2の当事者103bおよびそのそれぞれのコンピュータ機器102bという、2名の当事者103および彼らのそれぞれの機器102が例示を目的に示されている。より多くのそのような当事者103およびそれぞれのコンピュータ機器102が、システム100において存在して参加していてもよいが、便宜的にそれらは示されていないことが理解されるだろう。各当事者103は、個人または組織であり得る。純粋に例示として、第1の当事者103aはアリスと本明細書では呼ばれ、第2の当事者103bはボブと呼ばれるが、これは限定するものではなく、本明細書でのアリスまたはボブへのあらゆる言及は、それぞれ「第1の当事者」および「第2の当事者」で置き換えられ得ることが理解されるだろう。
各当事者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つまたは複数の他のネットワーク接続されたリソースを備え得る。
クライアントアプリケーション105は最初に、たとえばサーバからダウンロードされる、あるいは、リムーバブルSSD、フラッシュメモリキー、リムーバブルEEPROM、リムーバブル磁気ディスクドライブ、磁気フロッピーディスクもしくはテープ、CDもしくはDVD ROMなどの光学ディスク、またはリムーバブル光学ドライブなどの、リムーバブルストレージデバイス上で提供される、適切なコンピュータ可読記憶媒体上の任意の所与の当事者103のコンピュータ機器102に提供され得る。
クライアントアプリケーション105は、少なくとも「ウォレット」機能を備える。これには2つの主要な機能がある。これらのうちの1つは、それぞれの当事者103がトランザクション152を作成し、承認(たとえば署名)し、1つまたは複数のビットコインノード104に送信して、トランザクション152がブロックチェーンノード104のネットワーク全体に広められてブロックチェーン150に含まれるようにすることを可能にすることである。もう1つは、それぞれの当事者が現在所有するデジタル資産の金額をそれぞれの当事者に報告することである。出力ベースのシステムでは、この第2の機能は、対象の当事者に属するブロックチェーン150全体に散在する様々なトランザクション152の出力において定義される金額を照合することを備える。
注意:様々なクライアント機能は所与のクライアントアプリケーション105へと統合されるものとして説明されることがあるが、これは必ずしも限定するものではなく、代わりに、本明細書において説明されるあらゆるクライアント機能は、一連の2つ以上の別個の適用例、たとえばAPIを介してインターフェースすること、または一方が他方へのプラグインであることにおいて実装され得る。より一般的には、クライアント機能は、アプリケーションレイヤ、またはオペレーティングシステムなどのより低次のレイヤ、またはこれらの任意の組合せにおいて実装され得る。以下は、クライアントアプリケーション105に関して説明されるが、それは限定するものではないことが理解されるだろう。
各コンピュータ機器102上のクライアントアプリケーションまたはソフトウェア105のインスタンスは、ネットワーク106のブロックチェーンノード104のうちの少なくとも1つに動作可能に結合される。これは、クライアント105のウォレット機能がトランザクション152をネットワーク106に送信することを可能にする。クライアント105はまた、それぞれの当事者103が受信者であるあらゆるトランザクションについてブロックチェーン150にクエリするために、ブロックチェーンノード104に連絡することも可能である(または、実施形態では、ブロックチェーン150が、公的な存在であることにより一部トランザクションに信用をもたらす公的機関であるので、実際にブロックチェーン150における他の当事者のトランザクションを調査する)。各コンピュータ機器102のウォレット機能は、トランザクションプロトコルに従ってトランザクション152を編成して送信するように構成される。上で述べられたように、各ブロックチェーンノード104は、ブロックチェーンノードプロトコルに従ってトランザクション152を承認し、ブロックチェーンネットワーク106全体にトランザクション152を伝播するためにそれらを転送するように構成される、ソフトウェアを実行する。トランザクションプロトコルおよびノードプロトコルは互いに対応し、所与のトランザクションプロトコルは所与のノードプロトコルを伴い、一緒に所与のトランザクションモデルを実装する。ブロックチェーン150の中のすべてのトランザクション152に対して、同じトランザクションプロトコルが使用される。同じノードプロトコルが、ネットワーク106の中のすべてのノード104によって使用される。
所与の当事者103、たとえばアリスが、新しいトランザクション152jをブロックチェーン150に含まれるように送信することを望むとき、彼女は関連するトランザクションプロトコルに従って(彼女のクライアントアプリケーション105のウォレット機能を使用して)新しいトランザクションを編成する。彼女は次いで、クライアントアプリケーション105から、彼女が接続されている1つまたは複数のブロックチェーンノード104に、トランザクション152を送信する。たとえば、これは、アリスのコンピュータ102に最善に接続されるブロックチェーンノード104であり得る。任意の所与のブロックチェーンノード104が新しいトランザクション152jを受信するとき、ブロックチェーンノード104は、ブロックチェーンノードプロトコルおよびそのそれぞれの役割に従って、新しいトランザクション152jを扱う。これは、新しく受信されたトランザクション152jが「有効」であるための何らかの条件を満たすかどうかをまず確かめることを備え、その例がまもなくより詳しく論じられる。一部のトランザクションプロトコルでは、承認のための条件は、トランザクション152に含まれるスクリプトによってトランザクションごとに構成可能であり得る。代替として、この条件は単に、ノードプロトコルの内蔵機能であってもよく、またはスクリプトとノードプロトコルの組合せによって定義されてもよい。
新しく受信されるトランザクション152jが有効であるものとして見なされるように試験に合格する条件(すなわち、それが「承認される」条件)のもとで、トランザクション152jを受信する任意のブロックチェーンノード104が、新しい承認されたトランザクション152をそのブロックチェーンノード104に維持されているトランザクションの順序付けられたセット154に追加する。さらに、トランザクション152jを受信するあらゆるブロックチェーンノード104は、承認されたトランザクション152以降をネットワーク106の中の1つまたは複数の他のブロックチェーンノード104に伝播する。各ブロックチェーンノード104は同じプロトコルを適用するので、トランザクション152jが有効であると仮定すると、これは、それがまもなくネットワーク106全体に広められることを意味する。
所与のブロックチェーンノード104において維持される未処理のトランザクションの順序付けられたプール154の利用を認められると、そのブロックチェーンノード104は、新しいトランザクション152を含むそれぞれのプール154の最新のバージョンについてのプルーフオブワークパズルを競って解き始める(他のブロックチェーンノード104が、トランザクションの異なる順序付けられたセット154に基づいてパズルを解こうとしていることがあるが、最初にたどり着いた者が最新のブロック1511に含まれるトランザクションのセットを定義することを思い出されたい。最終的に、ブロックチェーンノード104は、アリスのトランザクション152jを含む順序付けられたプール154の一部のためのパズルを解く)。プルーフオブワークが、新しいトランザクション152jを含むプール154に対して行われると、それはイミュータブルに、ブロックチェーン150の中のブロック151のうちの1つの一部になる。各トランザクション152は、より前のトランザクションへのポインタを備えるので、トランザクションの順序もイミュータブルに記録される。
異なるブロックチェーンノード104は、所与のトランザクションの異なるインスタンスをまず受信するので、あるインスタンスが新しいブロック151において公開される前は、どのインスタンスが「有効」であるかについて矛盾した見方を有することがあり、それが公開される時点では、公開されるインスタンスが唯一の有効なインスタンスであることにすべてのブロックチェーンノード104が合意している。ブロックチェーンノード104があるインスタンスを有効であるものとして受け入れ、第2のインスタンスがブロックチェーン150に記録されていることを発見する場合、そのブロックチェーンノード104は、これを受け入れ、最初に受け入れたインスタンス(すなわち、ブロック151において公開されていないインスタンス)を廃棄する(すなわち、無効であるものとして扱う)。
一部のブロックチェーンネットワークによって運用される代替のタイプのトランザクションプロトコルは、アカウントベースのトランザクションモデルの一部として、「アカウントベース」プロトコルと呼ばれることがある。アカウントベースの場合、各トランザクションは、過去のトランザクションのシーケンスの中の先行するトランザクションのUTXOを参照することによってではなく、絶対的なアカウント残高を参照することによって、移されるべき金額を定義する。すべてのアカウントの現在の状態が、ブロックチェーンとは別に、そのネットワークのノードによって記憶され、定期的に更新される。そのようなシステムでは、トランザクションは、アカウントの実行中のトランザクションタリー(「ポジション」とも呼ばれる)を使用して順序付けられる。この値は、暗号署名の一部として送信者により署名され、トランザクション参照計算の一部としてハッシュされる。加えて、任意のデータフィールドはまた、署名されたトランザクションであってもよい。このデータフィールドは、たとえば以前のトランザクションIDがデータフィールドに含まれる場合、以前のトランザクションを指し示し得る。
UTXOベースのモデル
図2は、例示的なトランザクションプロトコルを示す。これは、UTXOベースのプロトコルの例である。トランザクション152(「Tx」と省略される)は、ブロックチェーン150の基本データ構造である(各ブロック151は1つまたは複数のトランザクション152を備える)。以下は、出力ベースまたは「UTXO」ベースのプロトコルに言及して説明される。しかしながら、これはすべての可能な実施形態への限定ではない。例示的なUTXOベースのプロトコルはビットコインに言及して説明されるが、それは他の例示的なブロックチェーンネットワーク上で等しく実装され得ることに留意されたい。
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に記憶される。
アリス 103aが、対象のある金額のデジタル資産をボブ 103bに移すトランザクション152jを作成することを望んでいるとする。図2において、アリスの新しいトランザクション152jは「Tx1」とラベリングされる。Tx1は、シーケンスの中の先行するトランザクション152iの出力203においてアリスにロックされるデジタル資産の金額をとり、その少なくとも一部をボブに移す。先行するトランザクション152iは、図2では「Tx0」とラベリングされる。Tx0およびTx1は任意のラベルにすぎない。それらは、Tx0がブロックチェーン151の最初のトランザクションであることを必ずしも意味せず、Tx1がプール154の中のすぐ次のトランザクションであることも意味しない。Tx1は、アリスにロックされている未消費の出力203をまだ有するあらゆる先行する(すなわち、祖先)トランザクションを指し示し得る。
先行するトランザクションTx0は、アリスが新しいトランザクションTx1を作成するとき、または少なくとも彼女がそれをネットワーク106に送信するときにはすでに、ブロックチェーン150のブロック151において承認されそれに含まれていることがある。それは、その時点ですでにブロック151のうちの1つに含まれていることがあり、または、順序付けられたセット154においてまだ待機していることがあり、その場合、それは新しいブロック151にまもなく含められる。代替として、Tx0およびTx1は、一緒に作成されてネットワーク106に送信されてもよく、または、ノードプロトコルが「オーファン」トランザクションのバッファリングを許容する場合、Tx0がTx1の後に送信されることすらあってもよい。トランザクションのシーケンスの文脈で本明細書において使用される「先行する」および「後続の」という用語は、トランザクションにおいて指定されるトランザクションポインタによって定義されるようなシーケンスにおけるトランザクションの順序を指す(どのトランザクションがどの他のトランザクションを指し示すか、など)。それらは、「先行者」および「後継者」、または「祖先」および「子孫」、「親」および「子」などにより等しく置き換えられ得る。これは、それらが作成される順序、ネットワーク106に送信される順序、または任意の所与のブロックチェーンノード104に到達する順序を必ずしも示唆しない。それでも、先行するトランザクション(祖先トランザクションまたは「親」)を指し示す後続のトランザクション(子孫トランザクションまたは「子」)は、親トランザクションが承認されるまでは、かつ承認されない限り、承認されない。親より前にブロックチェーンノード104に到達する子は、オーファンであると見なされる。それは、ノードプロトコルおよび/またはノード挙動に応じて、廃棄され、または親を待機するためにある時間の間バッファリングされ得る。
先行するトランザクションTx0の1つまたは複数の出力203のうちの1つは、ここでUTXO0とラベリングされる特定のUTXOを備える。各UTXOは、UTXOによって表されるデジタル資産の金額を指定する値と、後続のトランザクションが承認されるようにするために、したがってUTXOの引き換えが成功するために、後続のトランザクションの入力202におけるロック解除スクリプトによって満たされなければならない条件を定義するロックスクリプトとを備える。通常、ロックスクリプトは、金額を特定の当事者(ロックスクリプトが含まれるトランザクションの受益者)にロックする。すなわち、ロックスクリプトはロック解除条件を定義し、その条件は通常、後続のトランザクションの入力におけるロック解除スクリプトが、先行するトランザクションがロックされる対象である当事者の暗号署名を備えるという条件を備える。
ロックスクリプト(scriptPubKeyとしても知られている)は、ノードプロトコルによって認識される分野特有の言語で書かれるコードである。そのような言語の具体的な例は、ブロックチェーンネットワークによって使用される「Script」(大文字のS)と呼ばれる。ロックスクリプトは、トランザクション出力203を消費するためにどの情報が必要とされるか、たとえば、アリスの署名の要件を指定する。ロック解除スクリプトは、トランザクションの出力に現れる。ロック解除スクリプト(scriptSigとしても知られている)は、ロックスクリプト基準を満たすために必要とされる情報を提供する分野特有の言語で書かれるコードである。たとえば、それはボブの署名を含み得る。ロック解除スクリプトはトランザクションの入力202に現れる。
よって、示される例では、Tx0の出力203におけるUTXO0は、UXTO0が引き換えられるようにするために(厳密には、UTXO0を引き換えようとする後続のトランザクションが有効になるために)アリスの署名Sig PAを必要とするロックスクリプト[Checksig PA]を備える。[Checksig PA]は、アリスの公開-秘密鍵のペアからの公開鍵PAの表現(すなわち、ハッシュ)を含む。Tx1の入力202は、Tx1を指し示す(たとえば、そのトランザクションIDであるTxID0によって指し示す、TxID0は実施形態ではトランザクション全体Tx0のハッシュである)ポインタを備える。Tx1の入力202は、Tx0のあらゆる他のあり得る出力の中からUTXO0を特定するために、Tx0内でUTXO0を特定するインデックスを備える。Tx1の入力202はさらに、アリスが鍵のペアからの自身の秘密鍵をデータのあらかじめ定められた部分(暗号学では「メッセージ」と呼ばれることがある)に適用することによって作成される、アリスの暗号署名を備えるロック解除スクリプト<Sig PA>を備える。アリスにより有効な署名を提供するために署名される必要のあるデータ(または「メッセージ」)は、ロックスクリプトによって、またはノードプロトコルによって、またはこれらの組合せによって定義され得る。
新しいトランザクションTx1がブロックチェーンノード104に到達すると、ノードはノードプロトコルを適用する。これは、ロック解除スクリプトがロックスクリプトにおいて定義される条件(この条件は1つまたは複数の基準を備え得る)を満たすかどうかを確かめるために、ロックスクリプトおよびロック解除スクリプトを一緒に実行することを備える。実施形態では、これは2つのスクリプトを連結することを伴う。
<Sig PA><PA>||[Checksig PA]
ここで、「||」は連結を表し、「<...>」はスタックにデータを置くことを意味し、「[...]」はロックスクリプト(この例では、スタックベース言語)に含まれる関数である。等価的に、スクリプトを連結するのではなく、スクリプトは共通のスタックを用いて次々に実行されてもよい。いずれにしても、一緒に実行されると、スクリプトは、Tx0の出力の中のロックスクリプトに含まれるような、アリスの公開鍵PAを使用して、Tx1の入力の中のロック解除スクリプトがデータの予想される部分に署名するアリスの署名を含むことを認証する。データ自体(「メッセージ」)の予想される部分も、この認証を実行するために含まれる必要がある。実施形態では、署名されたデータはTx1の全体を備える(よって、平文でデータの署名された部分を指定する別個の要素が含まれる必要がなく、それは、もともと存在していたからである)。
公開-秘密暗号による認証の詳細は、当業者には馴染みがある。基本的に、アリスが自身の秘密鍵を使用してメッセージに署名した場合、平文のアリスの公開鍵およびメッセージを与えられると、ノード104などの別のエンティティは、メッセージがアリスによって署名されたに違いないことを認証することが可能である。署名することは通常、メッセージをハッシュし、ハッシュに署名し、これを署名としてメッセージへとタグ付けすることで、公開鍵のあらゆる保有者が署名を認証することを可能にすることを備える。したがって、本明細書における、特定のデータまたはトランザクションの一部に署名することなどへのあらゆる言及は、実施形態では、そのデータまたはトランザクション一部のハッシュに署名することを意味することに留意されたい。
Tx1におけるロック解除スクリプトがTx0のロックスクリプトにおいて指定される1つまたは複数の条件を満たす場合(よって示される例では、アリスの署名がTx1において提供されて認証される場合)、ブロックチェーンノード104はTx1を有効であると見なす。これは、ブロックチェーンノード104がTx1を未処理のトランザクションの順序付けられたプール154に追加することを意味する。ブロックチェーンノード104はまた、ネットワーク106の中の1つまたは複数の他のブロックチェーンノード104にトランザクションTx1を転送するので、それは、ネットワーク106全体に広められる。Tx1がブロックチェーン150において承認され含められると、これは消費されるものとしてTx0からのUTXO0を定義する。Tx1は、未消費のトランザクション出力203を消費する場合にのみ、有効であり得ることに留意されたい。別のトランザクション152によってすでに消費されている出力を消費しようとする場合、Tx1は、すべての他の条件が満たされている場合でも無効になる。したがって、ブロックチェーンノード104は、先行するトランザクションTx0の中の参照されるUTXOがすでに消費されているかどうか(すなわち、すでに有効な入力を別の有効なトランザクションへと形成したかどうか)を確かめる必要もある。これは、トランザクション152に定められた順序を課すことがブロックチェーン150にとって重要である1つの理由である。実際には、所与のブロックチェーンノード104は、トランザクション152がその中で消費されたどのUTXO203をマークする別個のデータベースを維持してもよいが、究極的には、UTXOが消費されたかどうかを定義するものは、UTXOが有効な入力をブロックチェーン150の中の別の有効なトランザクションへとすでに形成したかどうかである。
所与のトランザクション152のすべての出力203において指定される総金額が、すべてのその入力202によって指し示される総金額より大きい場合、これもまた、大半のトランザクションモデルにおいて、無効であることのルート拠になる。したがって、そのようなトランザクションは、広められず、ブロック151にも含められない。
UTXOベースのトランザクションモデルにおいて、所与のUTXOは全体として消費される必要があることに留意されたい。それは、消費されるものとしてUTXOにおいて定義される金額の一部を、別の一部が消費されながら「置き去りにする」ことができない。しかしながら、UTXOからの金額は、次のトランザクションの複数の出力の間で分割され得る。たとえば、Tx0の中のUTXO0において定義される金額は、Tx1の中の複数のUTXO間で分割され得る。したがって、アリスがUTXO0において定義される金額のすべてをボブに与えることを望まない場合、彼女はリマインダーを使用してTx1の第2の出力の残金を自分に与え、または別の当事者に支払うことができる。
実際には、アリスは普通は、アリスのトランザクション104をブロック151に含めることに成功するビットコインノード104に対する料金も含める必要がある。アリスがそのような料金を含めない場合、Tx0はブロックチェーンノード104によって拒絶されてもよく、したがって、技術的には有効であっても、広められず、ブロックチェーン150に含められなくてもよい(ノードプロトコルは、ブロックチェーンノード104がトランザクション152を受け入れることを望まない場合、それを強いることはない)。一部のプロトコルでは、トランザクションフィーは、固有の別々の出力203を必要としない(すなわち、別個のUTXOを必要としない)。代わりに、入力202によって指し示される総金額と所与のトランザクション152の出力203において指定される総金額とのあらゆる差が、トランザクションを公開するブロックチェーンノード104に自動的に与えられる。たとえば、UTXO0へのポインタがTx1への唯一の入力であり、Tx1が唯一の出力UTXO1を有するとする。UTXO0において指定されるデジタル資産の金額がUTXO1において指定される金額より大きい場合、その差が、UTXO1を含むブロックを作成するために、プルーフオブワークの競争に勝利するノード104によって割り当てられ得る。しかしながら、代替または追加として、トランザクションフィーが、トランザクション152のUTXO203のうちの自身固有のUTXOにおいて明示的に指定され得ることは、必ずしも排除されない。
アリスおよびボブのデジタル資産は、ブロックチェーン150のどこかにある任意のトランザクション152において彼らにロックされるUTXOからなる。したがって、通常は、所与の当事者103の資産は、ブロックチェーン150全体の、様々なトランザクション152のUTXO全体に分散している。所与の当事者103の総残高を定義する1つの数字が、ブロックチェーン150のどこかに保管されているということはない。それぞれの当事者にロックされており、別のその先のトランザクションにおいてまだ消費されていないすべての様々なUTXOの値を一緒に照合することが、クライアントアプリケーション150のウォレット機能の役割である。そのウォレット機能は、ビットコインノード104のいずれかに記憶されているようなブロックチェーン150のコピーをクエリすることによって、これを行うことができる。
スクリプトコードはしばしば、概略的(すなわち、厳密な言語を使用せずに)に表現されることに留意されたい。たとえば、特定の関数を表すためにオペレーションコード(オペコード)を使用することがある。「OP_...」は、Script言語の特定のオペコードを指す。例として、OP_RETURNは、ロックスクリプトの最初おいてOP_FALSEが前にあるとトランザクション内のデータを記憶できるトランザクションの消費不可能な出力を生み出し、それによりブロックチェーン150にデータをイミュータブルに記録するような、Script言語のオペコードである。たとえば、データは、ブロックチェーンに記憶することが望まれる文書を備え得る。
通常、トランザクションの入力は、公開鍵PAに対応するデジタル署名を含む。実施形態では、これは、楕円曲線secp256k1を使用するECDSAに基づく。デジタル署名は特定のデータに署名する。いくつかの実施形態では、所与のトランザクションに対して、署名はトランザクション入力の一部、およびトランザクション出力の一部またはすべてに署名する。署名する出力の具体的な部分は、SIGHASHフラグに依存する。SIGHASHフラグは普通は、どの出力が署名されるかを選択するために署名の最後に含まれる(したがって署名の時点で固定される)4バイトのコードである。
ロックスクリプトは時々「scriptPubKey」と呼ばれ、それぞれのトランザクションがロックされる対象である当事者の公開鍵をロックスクリプトが通常は備えるという事実を指している。ロック解除スクリプトは時々「scriptSig」と呼ばれ、ロック解除スクリプトが対応する署名を通常は供給するという事実を指している。しかしながら、より一般的には、UTXOが引き換えられるようにするための条件が署名を認証することを備えることは、ブロックチェーン150のすべての適用例において必須ではない。より一般的には、スクリプト言語は、任意の1つまたは複数の条件を定義するために使用され得る。したがって、より一般的な用語「ロックスクリプト」および「ロック解除スクリプト」が好まれることがある。
クライアントソフトウェア
図3Aは、ここで開示される方式の実施形態を実装するためのクライアントアプリケーション105の例示的な実装形態を示す。クライアントアプリケーション105は、トランザクションエンジン401およびユーザインターフェース(UI)レイヤ402を備える。トランザクションエンジン401は、上で論じられまもなくさらに詳しく論じられるような方式に従って、トランザクション152を編成すること、サイドチャネル310を介してトランザクションおよび/もしくは他のデータを受信および/もしくは送信すること、ならびに/またはブロックチェーンネットワーク106を通じて広められるようにトランザクションを1つまたは複数のノード104に送信することなどの、クライアント105の背後にあるトランザクション関連機能を実施することを行うように構成される。
UIレイヤ402は、それぞれのユーザのコンピュータ機器102のユーザ出力手段を介してそれぞれのユーザ103に情報を出力すること、および機器102のユーザ入力手段を介してそれぞれのユーザ103から入力を受け取ることを含む、機器102のユーザ入力/出力(I/O)手段を介してユーザインターフェースをレンダリングすることを行うように構成される。たとえば、ユーザ出力手段は、視覚的な出力を提供するための1つまたは複数の表示画面(タッチスクリーンまたは非タッチスクリーン)、オーディオ出力を提供するための1つまたは複数のスピーカー、および/または触覚出力を提供するための1つまたは複数の触覚出力デバイスなどを備え得る。ユーザ入力手段は、たとえば、1つもしくは複数のタッチスクリーンの入力アレイ(出力手段に使用されるものと同じまたは異なる)、マウス、トラックパッド、もしくはトラックボールなどの1つもしくは複数のカーソルベースのデバイス、発話もしくは声の入力を受け取るための1つもしくは複数のマイクロフォンおよび発話もしくは声認識アルゴリズム、手もしくは体のジェスチャの形態で入力を受け取るための1つもしくは複数のジェスチャベースの入力デバイス、または、1つもしくは複数の機械的なボタン、スイッチ、もしくはジョイスティックなどを備え得る。
注意:本明細書の様々な機能は、同じクライアントアプリケーション105へと統合されるものとして説明されることがあるが、これは必ずしも限定するものではなく、代わりにそれらは2つ以上の別個のアプリケーションのスイートにおいて実装されてもよく、たとえば、それらのアプリケーションは、一方が他方へのプラグインであり、またはAPI(アプリケーションプログラミングインターフェース)を介してインターフェースする。たとえば、トランザクションエンジン401の機能は、UIレイヤ402とは別のアプリケーションにおいて実装されてもよく、または、トランザクションエンジン401などの所与のモジュールの機能は、1つより多くのアプリケーション間で分割され得る。説明される機能の一部またはすべてが、たとえばオペレーティングシステムレイヤにおいて実装され得ることも排除されない。単一のまたは所与のアプリケーション105などへの言及が本明細書のどこかで行われる場合、それは例にすぎず、より一般的には、説明される機能は任意の形態のソフトウェアにおいて実装され得ることが理解されるだろう。
図3Bは、アリスの機器102aのクライアントアプリケーション105aのUIレイヤ402によってレンダリングされ得るユーザインターフェース(UI)500の例のモックアップを与える。同様のUIが、ボブの機器102bのクライアント105b、または任意の他の当事者のクライアントによってレンダリングされ得ることが理解されるだろう。
例として、図3Bはアリスの視点からUI500を示す。UI500は、ユーザ出力手段を介して別個のUI要素としてレンダリングされる1つまたは複数のUI要素501、502、503を備え得る。
たとえば、UI要素は1つまたは複数のユーザが選択可能な要素501を備えてもよく、これは、異なる画面上のボタン、またはメニューの中の異なるオプションなどであり得る。ユーザ入力手段は、UI要素を画面上でクリックもしくはタッチすること、または望まれるオプションの名前を話すことなどの、オプションの1つを選択することまたは別様に操作することをユーザ103(この場合アリス 103a)が行うことを可能にするようになされる(本明細書で使用される「手動」という用語は、自動と対比することのみが意図され、手を使用することに必ずしも限定されないことに留意されたい)。
代替または追加として、UI要素は、1つまたは複数のデータエントリフィールド502を備え得る。これらのデータエントリフィールドは、ユーザ出力手段を介して、たとえば画面上でレンダリングされ、データは、ユーザ入力手段、たとえばキーボードまたはタッチスクリーンを通じてフィールドへと入力され得る。代替として、データは、たとえば発話認識に基づいて、口頭で受信され得る。
代替または追加として、UI要素は、ユーザに情報を出力するための1つまたは複数の情報要素503を備え得る。たとえば、これ/これらは、画面上に、または音でレンダリングされ得る。
様々なUI要素をレンダリングし、オプションを選択し、データを入力する具体的な手段は、重要ではないことが理解されるだろう。これらのUI要素の機能は、まもなくより詳しく論じられる。図3に示されるUI500は図式化されたモックアップにすぎず、実際には、簡潔にするために示されない1つまたは複数のさらなるUI要素を備え得ることも理解されるだろう。
マークルツリー
マークルツリーは、データの集合のセキュアな検証を可能にする階レイヤ的データ構造である。マークルツリーにおいて、ツリーの中の各ノードは、インデックスペア(i,j)を与えられており、N(i,j)と表される。インデックスi、jは単に、ツリーの中の特定の位置に関連する数値ラベルである。
マークルツリーの重要な特徴は、そのノードの各々の構築が以下の式により支配されるということである。
ここでHは暗号学的ハッシュ関数である。
これらの式に従って構築される二進のマークルツリーが図4に示される。示されるように、i=jの事例はリーフノードに相当することがわかり、リーフノードは単に、データの対応するi番目のパケットDiのハッシュである。i≠jの事例は内部ノードまたは親ノードに相当し、これは1つの親(マークルルート)が発見されるまで子ノードを再帰的にハッシュして連結することによって生成される。
たとえば、ノードN(0,3)は、4つのデータパケットD0,...,D3から
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(D0)||H(D1))||H(H(D2)||H(D3))]
として構築される。
ツリーの深さMは、ツリーの中のノードの最低レベルとして定義され、ノードの深さmは、ノードが存在するレベルである。たとえば、mroot=0かつmleaf=Mであり、図4ではM=3である。
ビットコインおよびいくつかの他のブロックチェーンにおけるマークルツリーでは、ハッシュ関数はdouble SHA256であり、これは標準ハッシュ関数SHA-256 twice:H(x)=SHA256(SHA256(x))を適用することである。
マークル証明
マークルツリーの主要な機能は、いくつかのデータパケットDiがN個のデータパケットのリストまたは集合D∈{D0,...,DN-1}の要素であることを検証することである。検証のための機構は、マークル証明として知られており、所与のデータパケットDiおよびマークルルートRのためのマークルパスとして知られているハッシュのセットを取得することを伴う。データパケットのためのマークル証明は単に、反復的なハッシュ化と連結によりルートRを再構築するために必要なハッシュの最低限のリストであり、しばしば「認証証明」と呼ばれる。
存在の証明は、すべてのパケットD0,...,DN-1およびそれらの順序が証明者に知られていれば容易に実行され得る。しかしながら、これは、マークル証明よりはるかに大きなストレージのオーバーヘッドを必要とし、また、データセット全体が証明者に対して利用可能であることも必要とする。マークル証明を使用することとリスト全体を使用することとの比較が以下の表に示されており、そこでは、二進のマークルツリーを使用し、データブロックの数Nが2のべき乗に厳密に等しいと仮定した。
以下の表は、マークルツリーの中のリーフノードの数と、マークル証明(またはマークル証明)に必要とされるハッシュの数との関係を示す。
データパケットの数がリーフノードの数に等しいこの簡略化されたシナリオでは、マークル証明を計算するために必要なハッシュ値の数が対数的にスケーリングすることを発見した。明らかに、N個のデータハッシュを記憶して明白な証明を計算することよりも、log2N個のハッシュを伴うマークル証明を計算する方が、はるかにより効率的で現実的である。
方法
マークル証明Rが与えられており、データブロックD0がRにより表される順序付けられたリストD∈{D0,...,DN-1}に属していることを証明したいと仮定すると、マークル証明を次のように実行することができる。
i.信用されるソースからマークルルートRを取得する。
ii.ソースからマークル証明Γを取得する。この場合、Γはハッシュの集合
Γ={N(1,1),N(2,3),N(4,7)}
である。
iii.D1およびΓを使用してマークル証明を次のように計算する。
a.データブロックをハッシュして以下を得る。
N(0,0)=H(D0)
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である場合、ツリーにおける、したがってデータセットDにおけるD0の存在が確認される。
2.R'≠Rである場合、証明は失敗し、D0がDの要素であることは確認されない。
これは、何らかのデータが存在することの証明を、マークルツリーおよびそのルートにより表されるデータセットの一部として提供するための効率的な機構である。たとえば、データD0がブロックチェーントランザクションに対応し、ルートRがブロックヘッダの一部として公に利用可能である場合、トランザクションがそのブロックに含まれていたことを迅速に証明することができる。
例示的なマークルツリーの一部としてD0が存在することを認証する過程が、図5に示されている。これは、所与のブロックD0およびルートRのマークル証明を実行することが実質的には、必要最小限の数のハッシュ値しか使用しないことによってマークルツリーを「上向きに」走査することであることを示している。
マークル証明を構築するための最小限の情報
単一のリーフのマークル証明を構築するとき、必要とされる最小限の情報は、
1.リーフのインデックス:マークルツリーの中のリーフレイヤにおけるリーフの位置
2.ハッシュ値の順序付けられたリスト:マークルルートを計算するために必要とされるハッシュ値
である。
リーフのインデックスがどのように機能するかを説明するために、図5のマークルツリーを考える。ボブは、ルートRを知っているが、ツリーのすべてのリーフを知っているわけではない。D0のためのマークル枝は、1つのインデックス、0、および3つのハッシュ値(丸で囲まれた)からなる。インデックスは、提供されたハッシュ値が計算されたハッシュ値の左に連結されるべきかまたは右に連結されるべきかを示すためのものである。
マークルツリーはN=2M個のリーフを有すると仮定する。レイヤ0におけるインデックスiを仮定し、i0=1、b0=i0 mod 2、
、すなわち
とする。
p0は、インデックスがi0であるリーフノードのペアリーフノードのインデックスである。それらはマークルツリーにおいてそれらの親ハッシュノードを計算するために連結されハッシュされる(上記参照)ので、それらをペアと呼ぶ。インデックスがp0であるノードは「提供されるハッシュ」または「必要とされるデータ」とも呼ばれ、それは、i0リーフノードのマークルルートを計算するときに提供されなければならないからである。
したがって、レイヤmにおいて、
となることを定義することができる。
そうすると、提供されるハッシュのインデックスは
である。
上記の式は、インデックスが0で開始することを仮定する。
本発明の文脈では、インデックスがi0であるリーフノードは、ターゲットトランザクションのトランザクション識別子である。
存在の証明-トランザクション
図6は、本発明の実施形態を実装するための例示的なシステム600を示す。システムは、マークル証明エンティティ(またはマークル証明サーバ(MPS))601を備える。「マークル証明エンティティ」は、本明細書で説明される行為を実行するように構成されるエンティティのための便宜的なラベルとして使用されるにすぎないことに留意されたい。同様に、「マークル証明サーバ」という用語は、説明される行為がサーバ(すなわち、1つまたは複数のサーバユニット)によって実行されることを必ずしも意味しないが、それは1つのあり得る実装形態である。
MPS601は、トランザクションがブロックチェーン150上に存在することの証明を提供するように構成される。MPS601は、トランザクション識別子(TxID)のセットを記憶するように構成される。各TxIDは、それぞれのトランザクションを一意に識別する。TxIDは、トランザクションのハッシュ(たとえば、ダブルハッシュ)である。MPS601は、ブロックチェーン150上で公開されるあらゆる単一のトランザクションのそれぞれのTxIDを記憶し得る。代替として、MPS601は、公開されるトランザクションのすべてではなく一部だけのそれぞれのTxIDを記憶してもよい。たとえば、MPS601は、何かが共通しているすべてのトランザクション、たとえば、特定のブロックからのすべてのトランザクション、(UNIX(登録商標)時間またはブロックの高さにおいて)ある時間の後に公開されるすべてのトランザクション、特定のブロックチェーンノード104によって公開される1つまたは複数のブロックからのすべてのトランザクションなどのそれぞれのTxIDを記憶し得る。
MPS601はブロックチェーンノード104ではない。すなわち、MPS601はマイニングノードまたは「マイナー」ではない。MPS601は、ブロックチェーンノードによって操作され、またはそれに接続され得るが、MPS601自体が、プルーフオブワークを実行すること、ブロックを構築すること、ブロックを公開すること、コンセンサスルールを実施することなどの動作を実行することはない。いくつかの例では、MPS601はトランザクションを承認しない。しかしながら、MPS601がブロックを公開する動作を実行することなくトランザクションを承認し得ることは排除されない。
その上、MPS601はブロックチェーン全体150を記憶する必要はないが、それは排除されない。すなわち、MPS601は公開されたトランザクションのすべてを記憶する必要はない。いくつかの例では、MPS601はどのようなトランザクションも記憶しない。または、MPS601は、公開されたトランザクションの選択された少数、たとえば1つまたは複数のコインベーストランザクションを記憶し得る。
MPS601は、ターゲットトランザクション識別子、すなわちターゲットトランザクションのトランザクションを取得するように構成される。ターゲットトランザクションは、そのために存在の証明が必要とされるトランザクションである。たとえば、システム600は、1つまたは複数の要求側の当事者602を備え得る。要求側のエンティティ602は、ターゲットトランザクションのためのマークル証明に対する要求の一部として、ターゲットTxIDをMPS601に送信し得る。他の例では、第三者が、要求側の当事者602の代わりにターゲットTxIDをMPS601に送信し得る。いくつかの例では、MPS601へのターゲットTxIDの送信だけでも、マークル証明に対する要求として扱われる。
ターゲットTxIDを受信するのではなく、MPS601は代わりに、自身でターゲットトランザクションを受信し得る。すなわち、要求側の当事者602または第三者が、ターゲットトランザクションをMPS601に送信し得る。MPS601は次いで、ターゲットトランザクションをハッシュ(たとえば、ダブルハッシュ)してターゲットTxIDを取得し得る。MPS601がターゲットTxIDとターゲットトランザクションの両方を受信し得ることも排除されない。この例では、MPS601は、ターゲットトランザクションの(ダブル)ハッシュがターゲットTxIDと一致することを確認し、一致しない場合、要求側の当事者602に警告し得る。
MPS601はまた、ターゲットトランザクションのための「ターゲットマークル証明」、すなわち、ターゲットトランザクションがブロックチェーン上に存在することを証明するためのマークル証明を取得するように構成される。ターゲットマークル証明は、対応するマークルツリーのリーフが実際にはTxIDであるので、TxIDの記憶されているセットの1つまたは複数に基づく。マークル証明は上で説明されている。ターゲットマークル証明は少なくとも、ハッシュ値の順序付けられたセットを備える。ハッシュ値の順序付けられたセットの中のハッシュ値の数は、マークルツリーの中のリーフの数、すなわち、ターゲットトランザクションを含むブロック151の中のトランザクションの数に基づく。マークル証明はまた、ハッシュ値の順序付けられたセットの中の第1のハッシュ値がターゲットTxIDの左に連結されるべきかまたは右に連結されるべきかを示すリーフのインデックスを含み得る。
MPS601は、各トランザクションのための(すなわち、各TxIDのための)それぞれのマークル証明を記憶し得る。この例では、ターゲットマークル証明を取得することは、ターゲットマークル証明をストレージから抽出することを備える。たとえば、MPS601は各トランザクションのためのマークル証明を事前に計算し得る。ターゲットTxIDが取得されるとき、MPS601は対応するマークル証明を探す(各マークル証明はストレージの中のそれぞれのTxIDと関連付けられ得る)。
各トランザクションまたはTxIDのためのそれぞれのマークル証明を記憶するのではなく、またはそれに加えて、MPSは1つまたは複数のマークルツリーを事前に計算して記憶し得る。各マークルツリーは、TxIDの記憶されているセットのサブセット、内部ハッシュ値(または内部ノード)のセット、およびマークルルートを備える。この例では、ターゲットマークル証明を取得することは、ターゲットTxIDを含むマークルツリーからマークル証明(すなわち、必要とされるハッシュ値)を抽出することを備える。
別の例として、MPS601は、ターゲットTxIDを取得したことに応答してターゲットマークル証明を計算し得る。すなわち、MPS601は、TxIDの記憶されているセットの1つまたは複数を使用して、(たとえば、完全なマークルツリーを計算して必要とされているハッシュ値を抽出することによって)ターゲットマークル証明を計算し得る。この方法は、MPS601がターゲットトランザクションを備えるブロック151からのTxIDのすべてをストレージに有することを必要とすることに留意されたい。
ターゲットマークル証明は、対応するマークルツリーの1つまたは複数の内部ハッシュ、または内部ノードを備え得る。その場合、先行するハッシュ(たとえば、ターゲットTxID)を内部ハッシュの左に連結するかまたは右に連結するかを要求側の当事者が知るように、それらの内部ハッシュのインデックスを要求側の当事者に提供するのが有用である。したがって、ターゲットマークル証明を抽出するとき、MPS601は、リーフハッシュのインデックス、すなわちターゲットトランザクションのTxIDを使用して、ターゲットマークル証明の中の内部ハッシュのインデックスを計算する。MPSは、記憶されているツリーからマークル証明を抽出するためにこれらのインデックスを計算する必要があることがあり、すなわち、MPSはツリーを記憶しており、リーフインデックスにより、正しいマークル証明を抽出するためにツリーからどの内部ノードを選ぶべきかをMPSが決定することが可能になる。少なくともいくつかの例では、MPS601はターゲットTxIDのインデックスのみを計算すればよいことに留意されたい。必要とされる内部ハッシュを決定するには、この単一のインデックスで十分であり得る。
MPS601はまた、ターゲットマークル証明を出力するように構成される。たとえば、ターゲットマークル証明は、要求側の当事者602に直接送信され得る。または、ターゲットマークル証明は、たとえばウェブページで公開され得る。ターゲットマークル証明は、ターゲットトランザクションがブロックチェーン上に存在することの証明として使用され得る。
図8は、MPS601によって実行され得る例示的な方法800を示す。ステップ801において、MPSはTxIDのセットを記憶する。いくつかの例では、TxIDは、対応するトランザクションがブロック151において現れる順序に基づいて順序付けられる。ステップ802において、MPS601はターゲットTxIDを取得する(すなわち、受信する)。ステップ803において、MPS601はターゲットTxIDのための(すなわち、ターゲットトランザクションのための)マークル証明を取得する。MPS601は、たとえばメモリもしくはローカルストレージから、またはマークル証明を計算することによって、マークル証明を取得し得る。ステップ804において、MPSはマークル証明を出力する。
いくつかの例では、MPS601はまた、ターゲットトランザクションを含むブロック151のブロックヘッダからマークルルートを出力する。マークルルートは、マークルルートを含むブロックヘッダの一部として、またはそれ自体で、またはブロックヘッダの1つまたは複数の他のデータフィールド、たとえば以前のブロックハッシュと組み合わせて、出力され得る。マークルルートは、要求側の当事者602に直接出力され、または別様に公開され得る。
MPS601は、対応するトランザクションがその中で公開されるブロックに基づいて、TxIDをサブセットに記憶し得る。すなわち、ブロックnからのトランザクションのTxIDは1つのサブセットに記憶されてもよく、ブロックn-1からのトランザクションのTxIDは異なるサブセットに記憶されてもよく、以下同様である。各サブセットの中のTxIDは順序付けられたリストに記憶されてもよく、TxIDの順序は所与のブロックの中の対応するトランザクションの順序と一致する。
ブロックチェーン150の各ブロック151は、それぞれのブロックヘッダを備える。MPS601は1つまたは複数のブロックヘッダを記憶し得る。たとえば、MPS601は、それぞれの公開されるブロック151のためのブロックヘッダを記憶し得る。ブロックヘッダは、順序付けられたリストに記憶され得る。ブロックヘッダの順序は、ブロックチェーン150の中の対応するブロック151の順序と一致し得る。いくつかの例では、所与のブロック151からのTxIDは、そのブロック151のためのブロックヘッダと関連付けられて記憶され得る。
セキュリティのために、ブロックヘッダ値を再現してプルーフオブワークを承認することが可能であるためには、ブロックヘッダのすべてのフィールドが記憶されるべきである。しかしながら、完全なブロックヘッダを記憶する代わりに、いくつかの例では、MPS601がブロックヘッダのデータフィールドのすべてではなく1つまたは複数だけを記憶し得ることが排除されない。たとえば、MPS601は、ブロックヘッダ内に含まれるマークルルートだけを記憶し得る。または、MPS601は、ブロックヘッダ内に含まれるマークルルートおよび以前のハッシュを記憶し得る(ブロックヘッダnに記憶されている以前のハッシュはn-1番目のブロックヘッダに等しい)。
MPS601は、ブロックチェーンネットワーク106から、たとえばブロックチェーンノードから、記憶されているTxIDの一部またはすべてを取得し得る。TxIDのすべてが、単一のブロックチェーンノード104から取得され得る。代替として、TxIDは複数のノードから取得されてもよく、たとえば、1つのブロックチェーンノードからの何か、異なるブロックチェーンノードからの何かなどであってもよい。同じことがブロックヘッダに当てはまる。すなわち、記憶されているブロックヘッダの一部またはすべて(または記憶されているマークルルートおよび/または以前のブロックハッシュだけ)が、単一のブロックチェーンノード104から、または複数のノード104から取得され得る。いくつかの例では、MPS601は、同じブロックチェーンノード104からの所与のブロック(および任意選択でそのブロックのブロックヘッダ)からすべてのトランザクションのTxIDを取得し得る。
いくつかの例では、MPS601は、複数のノード104から同じTxIDおよび/またはブロックヘッダを取得することによって、取得されたTxIDおよび/またはブロックヘッダの一部またはすべてを検証し得る。
追加または代替として、図6に示されるように、ブロックヘッダの一部またはすべてが、1つまたは複数のsimplified payment verification(SPV)クライアント604から取得され得る。SPVクライアントは、ブロックチェーンのブロックヘッダの1つ、いくつか、またはすべてを記憶し、SPV方法を実行するように構成される、クライアントアプリケーションである。詳細については、たとえばhttps://wiki.bitcoinsv.io/index.php/Simplified_Payment_Verificationを参照されたい。たとえば、MPS601は、SPVクライアントを操作してもよく、または異なるエンティティ(必ずしも異なるMPSではない)によって操作されるSPVクライアントへの接続を有してもよい。
つまり、UTXOを消費するために、SPVウォレットを使用する送信者は、以下の情報を受信者に渡す。
1.出力としてUTXOを含むトランザクションTx0
2.Tx0のマークル証明
3.マークル証明(またはその識別子、たとえばブロックの高さ)から導出されたマークルルートを含むブロックヘッダ
4.UTXOを消費するトランザクションTx1
情報を承認するために、受信機は、Tx0のマークル証明からマークルルートを計算する。受信機は次いで、それをブロックヘッダにおいて指定されるマークルルートと比較する。それらが同じである場合、受信機は、Tx0がブロックチェーンの中にあることを受け入れる。
上で言及されたように、MPS601は1つまたは複数のトランザクション、すなわち生のトランザクションデータを記憶し得る。たとえば、MPS601はブロック当たり1つのトランザクションを記憶し得る。MPS601は、各ブロックのためのコインベーストランザクションを記憶し得る(ブロック当たり1つだけのコインベーストランザクションがあることを思い出されたい)。しかしながら、MPS601がコインベーストランザクション以外のトランザクションを記憶し得ること、または、MPS601がいくつかのブロックのそれぞれのコインベーストランザクション、および他のブロックの異なるトランザクションを記憶し得ることが排除されない。
所与のブロックのための記憶されているトランザクションは、「第1のトランザクション」と呼ばれる。これは、ブロックにおいて最初に現れるトランザクションを必ずしも意味しないが、コインベーストランザクションではそうである。これらの例では、MPS601は、ターゲットトランザクションと同じブロックにおいて公開される第1のトランザクションのためのマークル証明を取得し得る。MPS601は次いで、第1のトランザクション自体と一緒に、第1のトランザクションのためのマークル証明を、たとえば要求側の当事者602に出力し得る。これは、ターゲットマークル証明の長さが正しいことを検証するために、要求側の当事者602によって使用され得る。たとえば、第1のトランザクションのためのマークル証明の長さが10(たとえば、10個のハッシュ値)である場合、ターゲットマークル証明の長さも10であるべきである。
MPS601は、デスクトップコンピュータ、ラップトップコンピュータ、タブレット、スマートフォン、スマートウォッチなどのウェアラブルスマートデバイス、または車などの車両のオンボードコンピュータなどの、1つまたは複数のユーザ端末を備える(たとえば、図1に示されるものと同様の)コンピューティング装置の形態をとる。追加または代替として、コンピューティング装置はサーバを備え得る。本明細書では、サーバは、1つまたは複数の地理的な敷地に位置する1つまたは複数の物理サーバユニットを備え得る論理エンティティを指す。必要とされる場合、分散型または「クラウド」コンピューティング技法はそれら自体が当技術分野において知られている。1つもしくはまたは複数のユーザ端末および/またはサーバの1つもしくは複数のサーバユニットが、パケット交換ネットワークを介して互いに接続されてもよく、これは、たとえば、インターネット、3GPP(登録商標)ネットワークなどのモバイルセルラーネットワーク、イーサネットネットワークなどの有線ローカルエリアネットワーク(LAN)、またはWiFi、Thread、もしくは6LoWPANネットワークなどのワイヤレスLANなどのワイヤレスLANなどの、ワイドエリアインターネットワークを備えてもよい。コンピューティング装置は、コントローラおよびインターフェースを備える。コントローラは、インターフェース204に動作可能に結合される。コントローラは、MPSに起因する行為を実行するように構成される。インターフェースは、データ、たとえばTxID、ブロックヘッダ、マークル証明などを送信する、かつ受信するように構成される。
コントローラおよびインターフェースの各々は、コンピュータ可読ストレージ上で具現化され、CPUなどの1つまたは複数のプロセッサ、GPUなどのワークアクセラレータコプロセッサ、および/または他の特定用途向けプロセッサを備える処理装置上で実行され、1つまたは複数の地理的な敷地にある1つまたは複数のコンピュータ端末またはユニット上で実装される、ソフトウェアコードの形態で実装され得る。コードが記憶されるストレージは、やはり1つまたは複数の地理的な敷地にある1つまたは複数のコンピュータ端末またはユニット上で実装される、1つまたは複数のメモリ媒体(たとえば、電子または磁気媒体)を利用する1つまたは複数のメモリデバイスを備え得る。実施形態では、コントローラおよび/またはインターフェースはサーバ上で実装され得る。代替として、これらのコンポーネントの一方または両方のそれぞれのインスタンスは、1つまたは複数のユーザ端末の1つ、いくつか、またはすべての各々で、一部が実装されることがあり、または全体が実装されることすらある。さらなる例では、上で言及されたコンポーネントの機能は、ユーザ端末およびサーバのあらゆる組合せの間で分割されてもよい。やはり、必要とされる場合、分散型コンピューティング技法は、それら自体が当技術分野において知られていることに留意されたい。これらのコンポーネントの1つまたは複数が専用ハードウェアにおいて実装され得ることも、排除されない。
ここで、要求側の当事者602が説明される。要求側の当事者602は、マークル証明に対する要求をMPS601に送信するように構成される。要求側の当事者602は、ターゲットTxIDおよび/またはターゲットトランザクションをMPS601に送信し得る。それに応答して、要求側の当事者は、ターゲットマークル証明を受信し、または別様に取得するように構成される。要求側の当事者602は、ターゲットトランザクションがブロックチェーン上で存在することを証明するために、ターゲットマークル証明を使用し得る。たとえば、要求側の当事者602は、たとえばターゲットトランザクションとともに、受信側の当事者603にターゲットマークル証明を送信し得る。要求側の当事者602はまた、ターゲットトランザクションに基づくマークルツリーのマークルルートを(たとえば、ブロックヘッダの一部として)受信側の当事者603に送信し得る。マークルルートはMPS601から取得され得る。
いくつかの例では、要求側の当事者602は、1つまたは複数の親トランザクションの存在を証明するために、ターゲットマークル証明を使用し得る。この場合、ターゲットトランザクションが子トランザクションである場合、ターゲットマークル証明は、親トランザクションの各々がブロックチェーン150上で公開されたことを証明する(親トランザクションの各々がブロックチェーン150上で公開されることなく、子トランザクションがブロックチェーン150上で公開されたことはあり得ない)。一般に、トランザクションのチェーンにおける直近の公開されたトランザクションのためのマークル証明は、そのチェーンの中のすべての他のトランザクションの存在を証明する。
要求側の当事者602はSPVクライアントであり得る(またはそれを操作し得る)。すなわち、SPVクライアント(たとえば、消費者によって操作される)は、すなわちターゲットマークル証明を別の当事者(たとえば、受信者)603に提供することによって、SPV方法を実行するためのターゲットマークル証明を使用し得る。この場合、ターゲットトランザクションは、受信者にロックされるUTXOを備える消費トランザクションによって参照される、消費者にロックされるUTXOを備え得る。
要求側の当事者602は、ウォレットアプリケーションであり得る(またはそれを操作し得る)。ウォレットアプリケーションは、ターゲットトランザクションを記憶し得る。オンラインモードまたはオンライン状態(すなわち、MPS601に接続されている)では、ウォレットアプリケーションは、ターゲットトランザクションのためのターゲットマークル証明を取得し得る。ウォレットアプリケーションは次いで、オフラインモードまたはオフライン状態(すなわち、MPS601に接続されていない)で動作してもよく、ウォレットアプリケーションは、ターゲットトランザクションがブロックチェーン上で存在することの証明として、ターゲットトランザクションおよびターゲットマークル証明を受信側の当事者603に提供し得る。
要求側の当事者602は、アリス 103aまたはボブ 103bの形態をとり得る。
要求側の当事者602は、二次MPSであり得る。二次MPSまたは「完全性MPS」は、(ターゲットトランザクションを含む)ブロックチェーントランザクションのセットを記憶し、(一次MPSまたは「一般MPS」とも呼ばれる)MPS601にターゲットTxIDを送信し、ターゲットマークル証明を取得し、ターゲットマークル証明を二次的な要求側の当事者、たとえば受信側の当事者603、エンドユーザ(たとえば、アリス 103aまたはボブ 103b)などに出力するように構成される。
図6Bは、完全性MPS602と一般MPS601との間の対話を示す例示的なシステム600Bを示す。示されるように、システム600Bは、1つまたは複数のブロックチェーンノード104、完全性MPS602、一般MPS601、要求側の当事者(完全性MPSと異なる、たとえば第3の当事者ユーザ)603、およびSPVクライアント604を備える。システム600Bは、複数の要求側の当事者603および/またはSPVクライアント604を備え得る。
一般MPS601から始めると、それは所与のトランザクション識別子(TxID)のためのマークル証明を提供することが主な役割である。一般MPS601は、マークル証明を要求側の当事者603に、または完全性MPS602に出力し得る。たとえば、要求側の当事者603または完全性MPS602は、TxIDを一般MPS601に送信してもよく、それに返答して一般MPS601はマークル証明を提供する。一般MPS601は、1つまたは複数のソースからマークル証明を生み出すために必要とされるデータを取得し得る。たとえば、マークル証明自体がブロックチェーンノード104から取得され得る。追加または代替として、一般MPS601は、ブロックチェーンノード104から、またはSPVクライアント604から、TxIDおよび対応するブロックヘッダを取得し得る。一般MPS601は、TxIDおよび対応するブロックヘッダを使用してマークル証明を計算することができる。
完全性MPS602について言えば、それはマークル証明を要求側の当事者603に提供することが主な役割である。完全性MPS602は、要求側の当事者603からトランザクション構成要素(またはトランザクションデータフィールドまたはデータ項目)を受信し、それに返答してその構成要素を含むトランザクションのためのマークル証明を提供し得る。要求側の当事者603は、それに返答してトランザクションおよびマークル証明を別の当事者、たとえばSPVクライアント604に送信し得る。完全性MPS602は、ブロックチェーンノード104および/またはSPVクライアント604からトランザクションを取得し得る。完全性MPS601はまた、マークル証明の一部として使用するためにブロックチェーンノード104および/またはSPVクライアント604からブロックヘッダを取得してもよいが、十分なデータが利用可能であれば、ブロックヘッダは完全性MPS602によって計算されてもよい。
一般に、完全性MPS602は、一般MPS601から複数のマークル証明を、たとえば記憶されているトランザクションの各々に対して1つ取得し得る。たとえば、完全性MPSが新しいトランザクションを受信して記憶するとき、完全性MPS602は、新しいトランザクションのためのマークル証明に対する要求を一般MPS601に送信し得る。
本発明のいくつかの実施形態の例示的な実装形態が、ここで説明される。
一般MPS
一般MPS601は、受信側の当事者、たとえばユーザにマークル証明を提供するための専用サーバとして作動する。すなわち、一般MPS601は、トランザクションがブロックチェーン上で公開される場合、所与のトランザクションまたはトランザクションIDのためのマークル証明を提供するサーバである。一般MPS601は、完全なトランザクションデータを記憶しない。それは、マークルツリーのストレージを用いてブロックチェーンネットワークの中のSPVクライアントを補完するものとして見なされ得る。より正確には、一般MPSには以下に列挙されるストレージ要件がある。
1.プルーフオブワークが最大のチェーンを表すブロックヘッダの順序付けられたリスト(任意の要件)
2.各ブロックヘッダのためのトランザクションIDの順序付けられたリスト(中核の要件)
3.マークルルートがブロックヘッダにおいて指定されるものと一致するような、各ブロックヘッダのための事前に計算されたマークルツリー(任意の要件)
4.各ブロックの中のコインベーストランザクションの生のデータまたは各ブロックヘッダのためのブロックの中のトランザクションのあらゆる生のデータ(任意の要件)
第1の要件は、一般MPS601のデータ完全性を確保することである。ブロックヘッダの中のマークルルートは、トランザクションIDのリストに対する完全性の確認として使用され得る。すなわち、マークルツリーのリーフを形成するときに所与のブロックからのTxIDがブロックヘッダの中のマークルルートを与えることを確認するために、ブロックヘッダが使用され得る。たとえば、TxIDが信用される場合、または一般MPS601が、信用されるSPVクライアントへの、もしくはプルーフオブワークが最大のチェーンのブロックヘッダを記憶しているものと信用されるあらゆるエンティティへの、セキュアなアクセス権を有する場合、第1の要件は省略され得る。
第2の要件は中核であり、それは、この要件によりマークルリーフがマークルツリーにおいて現れる順序でマークルリーフが与えられ、マークルツリーを再構築できるようになるからである。コインベーストランザクションIDは常に、リストの中の第1のリーフまたは第1のハッシュであることに留意されたい。リーフの順序は、勝利したブロックを構築したブロックチェーンノードによって決定される。Bitcoin SVでは、この順序はトポロジカルな順序およびfirst-seenルールを反映すべきである。
第3の要件は、計算とストレージのトレードオフに対する選択肢を提供する。図7はストレージ要件を示し、実線のボックスは(いくつかの例では)必須であり、破線のボックスは任意選択である。ブロックヘッダは、示されるものに追加のフィールドを含むが、一般に、ルートハッシュのみがマークル証明のために必要とされることに留意されたい。以前のハッシュは、ルートハッシュをインデクシングするために使用され得る。重要な点は、一般MPS601がマークルツリーの内部ノードを記憶する必要がないということである。ブロックヘッダにおいてプルーフオブワークへのリンクを証明するには、ブロックヘッダのフィールドのすべてが必要とされることに留意されたい。「Prev Hash」フィールドが取り上げられており、それは、それがブロックヘッダ間のチェーン関係を示すからである。「Root Hash」フィールドが取り上げられており、それは、それがマークルツリーへのリンクを示すからである。しかしながら、プルーフオブワークへのリンクは、すべてのブロックヘッダ構成要素が提供されるときにのみ承認され得る。
第4の要件は、マークルツリーの深さの証明を提供することである。これは、一般MPS601によってそのユーザに提供され得る追加のサービスである。トランザクションの生データを提示されると、いずれの検証者も、そのマークル証明の中の第1のハッシュが実際にリーフであることに納得することができ、それは、リーフではない所与のハッシュ値に対して意味のあるトランザクションを構築するのは計算的に実現不可能であるからである。その上、マークル証明の長さはマークルツリーの深さを示唆するので、同じツリーからのすべてのマークル証明は同じ長さを有する。このサービスは、ユーザが関心対象のトランザクションの生データを持たないときには特に有用である。
トランザクションID、たとえばTxID1が与えられると、一般MPS601は、トランザクションIDの順序付けられたリストを調査する。一般MPS601がTxID1を発見する場合、それは、TxID1のためのマークル証明を構築または抽出し、出力する。それ以外の場合、一般MPS601は、たとえば「トランザクションが見つかりません」を出力する。トランザクションの生データが与えられると、一般MPS601は、データをハッシュして対応するトランザクションIDを取得し、上記のように進行することができる。
新しいブロックが公開されると、一般MPS601は以下のものを取得する。
1.新しいブロックヘッダ、
2.新しいブロックのためのトランザクションIDの順序付けられたリスト、および
3.生のコインベーストランザクション。
一般MPS601は任意選択で、以下のことを確認し得る。
1.新しいブロックヘッダが有効なプルーフオブワークを有する、
2.トランザクションIDから計算されるマークルルートがブロックヘッダの中のマークルルートに等しい、および
3.コインベーストランザクションのハッシュがリーフの中の第1の要素に等しい。
注意-サーバが生のトランザクションを得るための、またはトランザクションに対して署名検証を行うための要件はない。
以下は、マークルツリーの深さを提供することがなぜ価値のあるサービスであるかを説明する。SPVクライアントは、トランザクションIDおよびマークル証明を入力として取り込み、マークルルートがブロックヘッダの1つにおけるマークルルートと一致する場合には真を出力し、それ以外の場合には偽を出力する。しかしながら、この検証は、必要な情報の欠如により、マークル証明の長さがマークルツリーの長さと一致するかどうかを確認しない。場合によっては、敵対者が、存在しないトランザクションIDが存在することを証明しようとして、短縮されたマークル証明を提出する可能性がある。この短縮されたマークル証明は、リーフまたは後続のハッシュを完全に除去することによって得ることができる。
マークル証明提供者としての一般MPS601は、マークル証明の長さを検証するために必要とされる情報を提供するのに、最良の立場にある。マークルツリーの深さを明示的に提供するのではなく、一般MPS601は、コインベーストランザクションの生データおよびそのマークル証明を提供する。生のトランザクションデータおよびマークル証明を偽造することは計算的に実現不可能である。したがって、それはマークルツリーの深さの証明として機能する。ツリーの深さを知ることは、上で言及された重大な脆弱性を軽減することができる。SPVが関心対象のトランザクションの生データおよびマークル証明を提供されれば、SPVはこの脆弱性に対してセキュアであることに留意されたい。SPVが関心対象のトランザクションの生データを有しないとき、マークルツリーの深さまたはこのマークルツリーに関するマークル証明の正しい長さを確立するために、コインベーストランザクションの生データおよびそのマークル証明を使用することができる。
理論的には、この脆弱性は、そのリーフまたはあらゆる後続のレベルが完全に除去されるようなマークルツリーを受け入れるように一般MPS601を騙すためにも使用され得る。しかしながら、一般MPS601は、受信される情報の一貫性および正しさを確保するために、複数のブロックチェーンノード104に接続し得る。その上、一般MPS601はまた、新しいブロックのためのマークルツリーの深さを検証するために、コインベーストランザクションの生データをダウンロードすることを選ぶこともできる。
時には、一般MPS601は、競合するブロック、再編成、およびオーファンブロックに対処しなければならないことがあり、これらは、同じブロック高さに対して1つより多くのブロックが同時に見つかるときに起こる。幸い、この状況は、直近のヘッダを除けば起こらず、稀にしか起こらない。ブロックチェーン150は通常、1ブロックは2ブロック後に競合するチェーンのうちの1つに収束する。したがって、一般MPS601が1つより多くのブロック151を同じ高さで受信するとき、それは、プルーフオブワークが最大のチェーンへとブロックチェーンネットワークが収束するまでそれらのすべてを維持する。
ストレージの節約
現在、BSVグローバル台帳には全体でおよそ5億個のトランザクションがある(BTCについても同様のオーダーの数字である)。全体のTxIDは、およそ15GBのストレージ空間を必要とする。BSVブロックチェーン自体は、現在224GBである。一般MPS601は、ブロックチェーン全体の6.7%を記憶することが必要である。その上、ストレージは、サイズではなくトランザクションの数に依存する。ブロックの高さが638009であり、ブロックヘッダが80バイトである場合、ブロックヘッダは49MBのストレージを必要とし、毎年4MBが追加される。
一般MPS601がマークル証明生成を加速するためにマークルツリーの事前に計算された部分を記憶することになる場合、ルートノードの後の第1のレイヤは、2つのノードからなり、ツリー当たり2×32バイトを必要とする。よって、ブロックヘッダの80バイトに連結される64バイトは、MPSが任意のtxのマークル枝を生成するときに1回のハッシュ計算を節約する。すなわち、MPSはヘッダ当たり80バイトではなく144バイトを使用する。マークルツリーの第2のレイヤは、4つのノードからなり、すなわちヘッダ当たり272バイトである。以下同様である。第10のレイヤは、ヘッダ当たり65552バイトを必要とし、必要とされるストレージは全体で39GBに増える。これはTXIDの15GBを含むべきであり、各ブロックが1024個のトランザクションを有することを仮定している。
TxIDのみのMPSの制約
説明されるような一般MPS601にはいくつかの制約がある。公開されないトランザクション、たとえばTxIDpaymentを与えられると、一般MPS601は、入力において参照される出力点が存在することを検証することができない。理由は、出力点がトランザクションIDおよびインデックスの連結であるからである。一般MPS601は、トランザクションIDが存在するかどうかを決定することが可能であるが、トランザクションが有する出力の数、および出力が消費可能であるかどうかについての情報を持たない。これを克服する1つの方法は、TxIDpaymentにおいて参照されるトランザクションの生データを、入力の一部として一般MPS601に提供することである。代替の方法は、一般MPS601が未消費のトランザクションの生データを記憶することである。(ここで、未消費のトランザクションは、少なくとも1つの未消費の消費可能な出力を有するトランザクションを指す。)
一般MPS601がトランザクションIDおよび対応するインデックスのみを記憶する場合、一般MPS601は、インデックスが改竄されていないことを検証または証明できないことに留意されたい。一般MPS601は、インデックスの完全性を検証または証明するために、完全な生データを必要とする。
その上、それは、ロックスクリプトまたはフラグなどのトランザクションの内部の特定のデータ要素をユーザが探すことを実現することはできない。したがって、それは、たとえばユーザがブルームフィルタを使用するのをサポートすることはできず、それは、ブルームフィルタが、トランザクションに含まれるロックスクリプトおよび公開鍵に通常は基づいてトランザクションをフィルタリングするからである。
これにより、より詳細なレベルで情報を提供できるMPSが必要になる。これを完全性MPSと呼ぶ。完全性MPSは、一部のトランザクションの生データを記憶する。一般MPS601は、完全なトランザクションがユーザにより与えられる場合に、公開されたトランザクションの完全性を証明するために使用され得ることに留意されたい。完全性MPSは、関心対象の完全なトランザクションを記憶することによって、公開されたトランザクションから抽出された一部のデータの完全性を証明するために使用され得る。それは、ユーザが完全なトランザクションを提示することを必要としない。
完全性MPS
完全性MPSは、関心対象のトランザクションのセットのための生のトランザクションおよびそれらの対応するマークル証明を記憶する。このセットの中のトランザクションについてのクエリのために、このサーバは、生のトランザクションおよびそのマークル証明を、その完全性の証明として提供することができる。それは、トランザクションの内容の中の部分的なトランザクションまたはデータ要素を探すことも可能にする。関心対象のトランザクションは、Weather SV、Tokenized、Metanet、または任意の他のデータプロトコルなどのデータアプリケーションに基づいて決定されることがあり、または、ロックスクリプト、公開鍵、出力点などのデータストリングに基づいて決定されることすらある。したがって、Weather SVのみを搬送するトランザクションを記憶するように構成されるWeather SVアプリケーションだけのための完全性MPSがあり得る。
関心対象の生のトランザクションのセットは、完全性MPSに渡されて、公開される場合にはサーバに存続する。完全性MPSは、ゲートウェイとして見なすことができ、または特定用途向けトランザクションのためのゲートウェイへのアクセス権を有する。ブロックチェーンシステムがテラバイトブロックへとスケーリングするとき、これは完全性MPSを維持するための最も効率的な方法である。完全に非集権化されたピアツーピアデータ応用などの他の事例では、トランザクションの完全なブロックをダウンロードする機構に頼り、ブルームフィルタを使用したビットコイン改善提案37(BIP37)におけるように、関心対象ではないものを枝刈りし、またはそれらをフィルタリングしなければならない。
動作中
関心対象の生のトランザクションおよびマークルツリーにおけるそれらのマークル証明を維持する完全性MPSは、いくつかの実施形態では以下のステップを実行する。
ステップ1:関心対象の生のトランザクションを取得する。
ステップ2:生のトランザクションをハッシュしてトランザクションIDを取得する。
ステップ3:一般MPS601にそのマークル証明についてクエリする。
ステップ4:トランザクションがブロックにおいて公開されない場合、10分待ち再び試す。
ステップ3における一般MPS601への依存は、ダウンロードおよび枝刈りの機構により置き換えられ得るが、これはより効率が低い。ステップ4における公開されないトランザクションは、混雑を避けるためにあらかじめ定義された時間制限の後で省略され得る。この制限は、適用例ごとに変動し得る。
トランザクションは、そのマークル証明を提供することによって、ブロックチェーン150上で公開されることが証明され得る。代替として、それはその消費される出力の1つを通じて証明され得る。トランザクションtxiの出力がトランザクションtxjにおいて消費されるとき、txiを親トランザクションと呼び、txjを子トランザクションと呼ぶ。トランザクションが複数の出力を有することは、それが複数の子を有し得ることを示唆する。トランザクションが複数の入力を有することは、それが複数の親を有し得ることを示唆する。トランザクションの生データが利用可能である場合、このトランザクションのマークル証明は、そのすべての親が公開されていることを証明するのに十分であり、親のマークル証明を記憶する必要はない。
実際には、トランザクションのチェーンがある場合、チェーンの最後のトランザクションのマークル証明およびすべてのトランザクションの生データがチェーンにおけるすべてのトランザクションの存在を証明できると述べることによって、上記の考察を一般化することができる。
これにより、トランザクションのマークル証明を除去し、それをその子のいずれかのマークル証明で置き換えることが可能になる。これは、次の場合に有用になる。
1.ブロックサイズ - 子トランザクションが親トランザクションよりはるかに小さいブロックにおいて公開され、この場合、子トランザクションおよびそのマークル証明の全体のサイズは、親トランザクションのためのマークル証明のサイズより小さい、または、
2.複数の入力 - 子トランザクションが異なるトランザクションからの複数の入力を有し、この場合、子トランザクションおよびそのマークル証明の全体のサイズは、その親トランザクションのためのすべてのマークル証明の全体のサイズより小さい。
たとえば、ある特定の適用例では、すべてのトランザクションが専用のマークル証明出力を有し得る。時々、これらの出力は1つの子トランザクションにおいて収集され消費される。子トランザクションおよびそのマークル証明は、すべてのその親トランザクションの完全性および存在を証明することが可能である。したがって、親トランザクションのいずれのマークル証明も記憶しなくてもよい。
提供されたデータから導かれ得る証明を列挙する以下の表において、考察を要約することができる。
この表は、以下の場合に出力が存在することが証明されることを示す。
1.生のトランザクションが提供され、トランザクションが存在する場合、または
2.既存のトランザクションの支払においてその出力または高インデックスの出力が使用される場合。
結論
開示される技法の他の変形または使用事例は、本明細書の開示を与えられれば当業者に明らかになり得る。本開示の範囲は、説明される実施形態ではなく、添付の特許請求の範囲だけによって限定される。
たとえば、上のいくつかの実施形態は、ビットコインネットワーク106、ビットコインブロックチェーン150、およびビットコインノード104に関して説明されている。しかしながら、ビットコインブロックチェーンはブロックチェーン150の1つの特定の例であり、上の説明はあらゆるブロックチェーンに一般に当てはまり得ることが理解されるだろう。すなわち、本発明は、決してビットコインブロックチェーンに限定されない。より一般的には、ビットコインネットワーク106、ビットコインブロックチェーン150、およびビットコインノード104への上記のあらゆる言及は、それぞれ、ブロックチェーンネットワーク106、ブロックチェーン150、およびブロックチェーンノード104に関して置き換えられ得る。ブロックチェーン、ブロックチェーンネットワーク、および/またはブロックチェーンノードは、上で説明されたような、ビットコインブロックチェーン150、ビットコインネットワーク106、およびビットコインノード104の説明された性質の一部またはすべてを共有し得る。
本発明の好ましい実施形態では、ブロックチェーンネットワーク106はビットコインネットワークであり、ビットコインノード104は、ブロックチェーン150のブロック151を作成し、公開し、広め、記憶するという説明された機能の少なくともすべてを実行する。これらの機能のすべてではなく1つまたは一部だけを実行する他のネットワークエンティティ(またはネットワーク要素)があり得ることは排除されない。すなわち、ネットワークエンティティは、ブロックを作成して公開することなく、ブロックを伝播するおよび/または記憶する機能を実行し得る(これらのエンティティは好ましいビットコインネットワーク106のノードであるとは考えられないことを思い出されない)。
本発明の他の実施形態では、ブロックチェーンネットワーク106はビットコインネットワークではないことがある。これらの実施形態では、ノードが、ブロックチェーン150のブロック151を作成し、公開し、広め、記憶する機能のすべてではなく、少なくとも1つまたは一部を実行し得ることは排除されない。たとえば、それらの他のブロックチェーンネットワークでは、「ノード」は、ブロック151を作成して公開するが、それらのブロック151を記憶せず、かつ/または他のノードに広めないように構成される、ネットワークエンティティを指すために使用されることがある。
またさらに一般的には、上記の「ビットコインノード」104という用語へのあらゆる言及は、「ネットワークエンティティ」または「ネットワーク要素」という用語で置き換えられてもよく、そのようなエンティティ/要素は、ブロックを作成し、公開し、広め、記憶する役割の一部またはすべてを実行するように構成される。そのようなネットワークエンティティ/要素の機能は、ブロックチェーンノード104に関して上で説明されたのと同じ方法でハードウェアにおいて実装され得る。
上記の実施形態は、単なる例として説明されたことが理解されるだろう。より一般的には、以下の陳述の任意の1つまたは複数に従った方法、装置、またはプログラムが提供され得る。
陳述1 ブロックチェーントランザクションがブロックチェーン上に存在することの証明を提供するコンピュータで実施される方法であって、方法が、それぞれのブロックチェーントランザクションのトランザクション識別子のセットを記憶するが、新しいブロックチェーンブロックをブロックチェーンネットワークに公開しないように構成されるマークル証明エンティティによって実行され、方法が、
ターゲットブロックチェーントランザクションのターゲットトランザクション識別子を取得するステップであって、ターゲットトランザクション識別子がトランザクション識別子の記憶されているセットの一部を形成する、ステップと、
ターゲットブロックチェーントランザクションのためのターゲットマークル証明を取得するステップであって、対応するターゲットマークルルートがブロックチェーンのブロックヘッダ内に含まれる、ステップと、
ターゲットブロックチェーントランザクションがブロックチェーン上に存在することの証明として要求側の当事者が使用するためのターゲットマークル証明を出力するステップとを備える、方法。
マークル証明エンティティは、ブロックチェーン上でブロックを構築および/または公開する動作を実行しない。言い換えると、マークル証明エンティティはブロックチェーンノードではない。いくつかの例では、マークル証明エンティティは、いずれのブロックチェーントランザクションも記憶しない。他の例では、マークル証明エンティティは、ブロックごとに1つだけのブロックチェーントランザクションを記憶する。さらに他の例では、マークル証明エンティティは、ブロックごとのブロックチェーントランザクションのいくつかまたはすべてを記憶する。
陳述2 マークル証明エンティティがブロックチェーン全体を記憶しない、陳述1の方法。
陳述3 ターゲットマークル証明を取得するステップが、対応するターゲットマークルツリーのリーフレイヤ内のターゲットトランザクション識別子のインデックスを計算するステップを備える、陳述1または陳述2の方法。
陳述4 インデックスを要求側の当事者に出力するステップを備える、陳述3の方法。
陳述5 ターゲットトランザクション識別子を取得する前記ステップが、要求側の当事者からターゲットトランザクション識別子を取得するステップを備える、任意の先行する陳述の方法。
陳述6 ターゲットトランザクション識別子を取得する前記ステップが、ターゲットブロックチェーントランザクションを取得するステップと、ターゲットブロックチェーントランザクションに基づいてターゲットトランザクション識別子を構築するステップとを備える、任意の先行する陳述の方法。
ターゲットブロックチェーントランザクションは、要求側の当事者から受信され得る。
陳述7 ターゲットマークル証明を取得する前記ステップが、トランザクション識別子の記憶されているセットの1つまたは複数を使用してターゲットマークル証明を計算するステップを備える、任意の先行する陳述の方法。
陳述8 マークル証明エンティティが、ターゲットトランザクション識別子を含むトランザクション識別子の記憶されているセットの1つまたは複数のためのそれぞれのマークル証明を記憶し、ターゲットマークル証明を取得する前記ステップが、記憶位置からターゲットマークル証明を抽出するステップを備える、任意の先行する陳述の方法。
陳述9 ターゲットマークル証明を出力する前記ステップが、ターゲットマークル証明を要求側の当事者に送信するステップを備える、任意の先行する陳述の方法。
陳述10 ターゲットマークル証明を出力する前記ステップが、ターゲットマークル証明を公開するステップを備え得る、任意の先行する陳述の方法。
陳述11 マークル証明エンティティが1つまたは複数のマークルルートを記憶し、各マークルルートがトランザクション識別子の記憶されているセットのそれぞれのサブセットに基づく、任意の先行する陳述の方法。
陳述12 要求側の当事者に、ターゲットトランザクション識別子に基づいてマークルルートを出力するステップを備える、陳述11の方法。
陳述13 マークル証明エンティティが、1つまたは複数のマークルルートの各々のために、マークルツリーを記憶する、陳述11または陳述12の方法。
陳述14 ターゲットマークル証明を取得する前記ステップが、ターゲットトランザクション識別子を備える記憶されているマークルツリーからターゲットマークル証明を抽出するステップを備える、陳述13の方法。
陳述15 トランザクション識別子の記憶されているセットが、トランザクション識別子の複数のサブセットを備え、トランザクション識別子の各サブセットが、ブロックチェーンのそれぞれのブロックからのすべてのトランザクション識別子を備える、任意の先行する陳述の方法。
トランザクション識別子の各サブセットは、それぞれのブロックに記憶されているブロックチェーントランザクションの順序に対応する順序付けられたリストに記憶され得る。
陳述16 トランザクションの識別子の各サブセットが、ブロックチェーンのそれぞれのブロックのそれぞれのブロックヘッダに関連して記憶される、陳述15の方法。
それぞれのブロックヘッダは、ブロックチェーン上で公開されるブロックの順序に対応する順序付けられたリストに記憶され得る。
陳述17 ブロックチェーン上で公開される各ブロックチェーントランザクションのそれぞれのトランザクション識別子を記憶するステップを備える、任意の先行する陳述の方法。
陳述18 トランザクション識別子の記憶されているセットの少なくともいくつかが1つまたは複数のブロックチェーンノードから取得される、任意の先行する陳述の方法。
たとえば、記憶されているトランザクション識別子のすべてが、ブロックチェーンノードから取得され得る。
陳述19 ブロックヘッダの少なくともいくつかが、1つまたは複数のブロックチェーンノードから取得され、および/または、ブロックヘッダの少なくともいくつかが、1つまたは複数のsimplified payment verification(SPV)クライアントアプリケーションから取得される、陳述16またはそれに従属するいずれかの陳述の方法。
陳述20 マークル証明エンティティが、ブロックヘッダの1つもしくは複数を記憶するSPVクライアントアプリケーションを操作し、またはそれへのアクセス権を有する、陳述16またはそれに従属するいずれかの陳述の方法。
陳述21 マークル証明エンティティが、トランザクション識別子の各サブセットのために、それぞれのブロックからの第1のブロックチェーントランザクションを記憶する、陳述15またはそれに従属するいずれかの陳述の方法。
陳述22
第1のブロックチェーントランザクションのための第1のマークル証明を取得するステップであって、第1のマークル証明がトランザクション識別子の記憶されているセットの1つまたは複数に基づく、ステップと、
ターゲットマークル証明の長さが、対応するターゲットマークルツリーの長さと一致することを検証するために要求側の当事者が使用するための、第1のブロックチェーントランザクションおよび第1のマークル証明を出力するステップとを備える、陳述21の方法。
陳述23 第1のブロックチェーントランザクションが生成トランザクションである、陳述22の方法。
コインベーストランザクションまたは初期トランザクションとしても知られている生成トランザクションは、ブロックにおいて論理的に最初に公開されるトランザクションである。それは、そのブロックを公開したブロックチェーンノードによって作成される。
陳述24 要求側の当事者が、simplified payment verification(SPV)クライアントアプリケーションを操作する、任意の先行する陳述の方法。
要求側の当事者は、オフラインウォレットアプリケーションを操作し得る。
陳述25 要求側の当事者が、ターゲットブロックチェーントランザクションを備えるブロックチェーントランザクションのセットを記憶し、ターゲットマークル証明を第2の要求側の当事者に出力するように構成される、二次マークル証明エンティティを備える、陳述1から23のいずれかの方法。
たとえば、第2の要求側の当事者はエンドユーザであり得る。
陳述26 ブロックチェーントランザクションがブロックチェーン上に存在することの証明を取得するコンピュータで実施される方法であって、マークル証明エンティティが、それぞれのブロックチェーントランザクションのトランザクション識別子のセットを記憶し、マークル証明エンティティが、それぞれのブロックチェーントランザクションのトランザクション識別子のセットを記憶するが、新しいブロックチェーンブロックをブロックチェーンネットワークに公開しないように構成され、方法が、要求側の当事者によって実行され、
マークル証明エンティティに、ターゲットブロックチェーントランザクションおよび/またはターゲットトランザクションのターゲットトランザクション識別子を送信するステップと、
マークル証明エンティティから、ターゲットブロックチェーントランザクションのためのターゲットマークル証明を取得するステップとを備え、マークル証明がトランザクション識別子の記憶されているセットの1つまたは複数に基づく、方法。
陳述27 ターゲットブロックチェーントランザクションがブロックチェーン上に存在することの証明としてターゲットマークル証明を第2の要求側の当事者に送信するステップを備える、陳述26の方法。
陳述28 ターゲットブロックチェーントランザクションが、ブロックチェーントランザクションのチェーンの最も新しいトランザクションであり、要求側の当事者が、ブロックチェーントランザクションのチェーンの中の各トランザクションへのアクセス権を有し、ターゲットマークル証明が、ブロックチェーントランザクションのチェーンの中の各トランザクションがブロックチェーン上に存在することの証明である、陳述26または陳述27の方法。
陳述29 1つまたは複数のメモリユニットを備えるメモリと、
1つまたは複数の処理ユニットを備える処理装置とを備え、メモリが処理装置上で実行するようになされるコードを記憶し、コードが、処理装置上で実行されると、陳述1から25のいずれかの方法を実行するように構成される、コンピュータ機器。
陳述30 コンピュータ可読ストレージ上で具現化され、1つまたは複数のプロセッサ上で実行されると陳述1から25のいずれかの方法を実行するように構成される、コンピュータプログラム。
陳述31
1つまたは複数のメモリユニットを備えるメモリと、
1つまたは複数の処理ユニットを備える処理装置とを備え、メモリが処理装置上で実行するようになされるコードを記憶し、コードが、処理装置上で実行されると、陳述26から28のいずれかの方法を実行するように構成される、コンピュータ機器。
陳述32 コンピュータ可読ストレージ上で具現化され、1つまたは複数のプロセッサ上で実行されると陳述26から28のいずれかの方法を実行するように構成される、コンピュータプログラム。
本明細書で開示される別の態様によれば、マークル証明エンティティおよび要求側の当事者の行為を備える方法が提供され得る。
本明細書で開示される別の態様によれば、マークル証明エンティティおよび要求側の当事者のコンピュータ機器を備えるシステムが提供され得る。
100 システム
101 ブロックチェーンネットワーク、パケット交換ネットワーク、インターネット
102 コンピュータ機器、コンピュータ端末
103 ユーザ、当事者
104 ブロックチェーンノード
105 クライアントアプリケーション
106 ピアツーピア(P2P)ネットワーク、ネットワーク
150 ブロックチェーン
151 ブロック
152 トランザクション
153 ジェネシスブロック
154 セット、プール
155 ブロックポインタ
201 ヘッダ
202 入力フィールド、入力、
203 出力フィールド、出力、トランザクション出力、UTXO
500 UI
501 UI要素
502 UI要素
503 UI要素
601 一般マークルパスサーバ
602 完全性マークルパスサーバ
603 要求側の当事者
604 SPVクライアント

Claims (32)

  1. ブロックチェーントランザクションがブロックチェーン上に存在することの証明を提供するコンピュータで実施される方法であって、
    前記方法が、それぞれのブロックチェーントランザクションのトランザクション識別子のセットを記憶するが、新しいブロックチェーンブロックをブロックチェーンネットワークに公開しないように構成されるマークル証明エンティティによって実行され、
    前記方法が、
    ターゲットブロックチェーントランザクションのターゲットトランザクション識別子を取得するステップであって、前記ターゲットトランザクション識別子がトランザクション識別子の前記記憶されているセットの一部を形成する、ステップと、
    前記ターゲットブロックチェーントランザクションのためのターゲットマークル証明を取得するステップであって、対応するターゲットマークルルートが前記ブロックチェーンのブロックヘッダ内に含まれる、ステップと、
    前記ターゲットブロックチェーントランザクションが前記ブロックチェーン上に存在することの証明として要求側の当事者が使用するための前記ターゲットマークル証明を出力するステップと
    を備える、方法。
  2. 前記マークル証明エンティティがブロックチェーン全体を記憶しない、請求項1に記載の方法。
  3. 前記ターゲットマークル証明を取得するステップが、対応するターゲットマークルツリーのリーフレイヤ内の前記ターゲットトランザクション識別子のインデックスを計算するステップを備える、請求項1または請求項2に記載の方法。
  4. 前記インデックスを前記要求側の当事者に出力するステップを備える、請求項3に記載の方法。
  5. 前記ターゲットトランザクション識別子を取得する前記ステップが、前記要求側の当事者から前記ターゲットトランザクション識別子を取得するステップを備える、請求項1から4のいずれか一項に記載の方法。
  6. 前記ターゲットトランザクション識別子を取得する前記ステップが、
    前記ターゲットブロックチェーントランザクションを取得するステップと、
    前記ターゲットブロックチェーントランザクションに基づいて前記ターゲットトランザクション識別子を構築するステップと
    を備える、請求項1から5のいずれか一項に記載の方法。
  7. 前記ターゲットマークル証明を取得する前記ステップが、トランザクション識別子の前記記憶されているセットの1つまたは複数を使用して前記ターゲットマークル証明を計算するステップを備える、請求項1から6のいずれか一項に記載の方法。
  8. 前記マークル証明エンティティが、前記ターゲットトランザクション識別子を含むトランザクション識別子の前記記憶されているセットの1つまたは複数のためのそれぞれのマークル証明を記憶し、
    前記ターゲットマークル証明を取得する前記ステップが、記憶位置から前記ターゲットマークル証明を抽出するステップを備える、請求項1から7のいずれか一項に記載の方法。
  9. 前記ターゲットマークル証明を出力する前記ステップが、前記ターゲットマークル証明を前記要求側の当事者に送信するステップを備える、請求項1から8のいずれか一項に記載の方法。
  10. 前記ターゲットマークル証明を出力する前記ステップが、前記ターゲットマークル証明を公開するステップを備え得る、請求項1から9のいずれか一項に記載の方法。
  11. 前記マークル証明エンティティが1つまたは複数のマークルルートを記憶し、
    各マークルルートがトランザクション識別子の前記記憶されているセットのそれぞれのサブセットに基づく、請求項1から10のいずれか一項に記載の方法。
  12. 前記要求側の当事者に、前記ターゲットトランザクション識別子に基づいて前記マークルルートを出力するステップを備える、請求項11に記載の方法。
  13. 前記マークル証明エンティティが、前記1つまたは複数のマークルルートの各々のために、マークルツリーを記憶する、請求項11または請求項12に記載の方法。
  14. 前記ターゲットマークル証明を取得する前記ステップが、前記ターゲットトランザクション識別子を備える記憶されているマークルツリーから前記ターゲットマークル証明を抽出するステップを備える、請求項13に記載の方法。
  15. トランザクション識別子の前記記憶されているセットが、トランザクション識別子の複数のサブセットを備え、
    トランザクション識別子の各サブセットが、前記ブロックチェーンのそれぞれのブロックからのすべてのトランザクション識別子を備える、請求項1から14のいずれか一項に記載の方法。
  16. トランザクションの識別子の各サブセットが、前記ブロックチェーンの前記それぞれのブロックのそれぞれのブロックヘッダに関連して記憶される、請求項15に記載の方法。
  17. 前記ブロックチェーン上で公開される各ブロックチェーントランザクションのそれぞれのトランザクション識別子を記憶するステップを備える、請求項1から16のいずれか一項に記載の方法。
  18. トランザクション識別子の前記記憶されているセットの少なくともいくつかが1つまたは複数のブロックチェーンノードから取得される、請求項1から17のいずれか一項に記載の方法。
  19. 前記ブロックヘッダの少なくともいくつかが、1つまたは複数のブロックチェーンノードから取得され、および/または、
    前記ブロックヘッダの少なくともいくつかが、1つまたは複数のsimplified payment verification(SPV)クライアントアプリケーションから取得される、請求項16または請求項16に従属するいずれかの請求項に記載の方法。
  20. 前記マークル証明エンティティが、前記ブロックヘッダの1つもしくは複数を記憶するSPVクライアントアプリケーションを操作するか、または前記SPVクライアントアプリケーションへのアクセス権を有する、請求項16または請求項16に従属するいずれかの請求項に記載の方法。
  21. 前記マークル証明エンティティが、トランザクション識別子の各サブセットのために、前記それぞれのブロックからの第1のブロックチェーントランザクションを記憶する、請求項15または請求項15に従属するいずれかの請求項に記載の方法。
  22. 前記第1のブロックチェーントランザクションのための第1のマークル証明を取得するステップであって、前記第1のマークル証明がトランザクション識別子の前記記憶されているセットの1つまたは複数に基づく、ステップと、
    前記ターゲットマークル証明の長さが、対応するターゲットマークルツリーの長さと一致することを検証するために前記要求側の当事者が使用するための、前記第1のブロックチェーントランザクションおよび前記第1のマークル証明を出力するステップと
    を備える、請求項21に記載の方法。
  23. 前記第1のブロックチェーントランザクションが生成トランザクションである、請求項22に記載の方法。
  24. 前記要求側の当事者が、simplified payment verification(SPV)クライアントアプリケーションを操作する、請求項1から23のいずれか一項に記載の方法。
  25. 前記要求側の当事者が、前記ターゲットブロックチェーントランザクションを備えるブロックチェーントランザクションのセットを記憶し、前記ターゲットマークル証明を第2の要求側の当事者に出力するように構成される、二次マークル証明エンティティを備える、請求項1から23のいずれか一項に記載の方法。
  26. ブロックチェーントランザクションがブロックチェーン上に存在することの証明を取得するコンピュータで実施される方法であって、
    マークル証明エンティティが、それぞれのブロックチェーントランザクションのトランザクション識別子のセットを記憶し、
    前記マークル証明エンティティが、それぞれのブロックチェーントランザクションのトランザクション識別子のセットを記憶するが、新しいブロックチェーンブロックをブロックチェーンネットワークに公開しないように構成され、
    前記方法が、要求側の当事者によって実行され、
    前記マークル証明エンティティに、ターゲットブロックチェーントランザクションおよび/または前記ターゲットブロックチェーントランザクションのターゲットトランザクション識別子を送信するステップと、
    前記マークル証明エンティティから、前記ターゲットブロックチェーントランザクションのためのターゲットマークル証明を取得するステップと
    を備え、前記ターゲットマークル証明がトランザクション識別子の前記記憶されているセットの1つまたは複数に基づく、方法。
  27. 前記ターゲットブロックチェーントランザクションが前記ブロックチェーン上に存在することの証明として前記ターゲットマークル証明を第2の要求側の当事者に送信するステップを備える、請求項26に記載の方法。
  28. 前記ターゲットブロックチェーントランザクションが、ブロックチェーントランザクションのチェーンの最も新しいトランザクションであり、
    前記要求側の当事者が、ブロックチェーントランザクションの前記チェーンの中の各トランザクションへのアクセス権を有し、
    前記ターゲットマークル証明が、ブロックチェーントランザクションの前記チェーンの中の各トランザクションが前記ブロックチェーン上に存在することの証明である、請求項26または請求項27に記載の方法。
  29. 1つまたは複数のメモリユニットを備えるメモリと、
    1つまたは複数の処理ユニットを備える処理装置と
    を備え、前記メモリが、前記処理装置上で実行するように構成されたコードを記憶し、前記コードが、前記処理装置上で実行されると、請求項1から25のいずれか一項に記載の方法を実行するように構成される、コンピュータ機器。
  30. コンピュータ可読ストレージ上で具現化され、1つまたは複数のプロセッサで実行されると請求項1から25のいずれか一項に記載の方法を実行するように構成される、コンピュータプログラム。
  31. 1つまたは複数のメモリユニットを備えるメモリと、
    1つまたは複数の処理ユニットを備える処理装置と
    を備え、前記メモリが、前記処理装置上で実行するように構成されたコードを記憶し、前記コードが、前記処理装置上で実行されると、請求項26から28のいずれか一項に記載の方法を実行するように構成される、コンピュータ機器。
  32. コンピュータ可読ストレージ上で具現化され、1つまたは複数のプロセッサで実行されると請求項26から28のいずれか一項に記載の方法を実行するように構成される、コンピュータプログラム。
JP2023527773A 2020-11-10 2021-10-12 マークル証明エンティティ Pending JP2023547716A (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
GB2017729.1 2020-11-10
GB2017729.1A GB2600769A (en) 2020-11-10 2020-11-10 Merkle proof entity
PCT/EP2021/078206 WO2022100945A1 (en) 2020-11-10 2021-10-12 Merkle proof entity

Publications (1)

Publication Number Publication Date
JP2023547716A true JP2023547716A (ja) 2023-11-13

Family

ID=74046336

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2023527773A Pending JP2023547716A (ja) 2020-11-10 2021-10-12 マークル証明エンティティ

Country Status (8)

Country Link
US (1) US20230388136A1 (ja)
EP (1) EP4245009A1 (ja)
JP (1) JP2023547716A (ja)
KR (1) KR20230101883A (ja)
CN (1) CN116508291A (ja)
GB (1) GB2600769A (ja)
TW (1) TW202220410A (ja)
WO (1) WO2022100945A1 (ja)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11902426B2 (en) * 2021-06-26 2024-02-13 Ceremorphic, Inc. Efficient storage of blockchain in embedded device
US12008472B2 (en) * 2022-06-29 2024-06-11 David Cook Apparatus and method for generating a compiled artificial intelligence (AI) model
CN115277179B (zh) * 2022-07-26 2024-08-13 湖南三湘银行股份有限公司 一种基于多步保护的开放平台综合安全保护方法

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
SG11202108154TA (en) * 2019-02-15 2021-08-30 Nchain Holdings Ltd Computer-implemented systems and methods for implementing transfers over a blockchain network

Also Published As

Publication number Publication date
EP4245009A1 (en) 2023-09-20
WO2022100945A1 (en) 2022-05-19
GB2600769A (en) 2022-05-11
KR20230101883A (ko) 2023-07-06
TW202220410A (zh) 2022-05-16
GB202017729D0 (en) 2020-12-23
US20230388136A1 (en) 2023-11-30
CN116508291A (zh) 2023-07-28

Similar Documents

Publication Publication Date Title
JP2023547716A (ja) マークル証明エンティティ
KR20230028439A (ko) 블록체인 네트워크에서 데이터를 유효성 검증하기 위한 방법 및 디바이스
US20230394063A1 (en) Merkle proof entity
JP2023515368A (ja) ブロックチェーンネットワークと共に使用される証明サービス
JP2023554148A (ja) 機密データのブロック
US20230308292A1 (en) Digital signatures
US20240205030A1 (en) Uniform resource identifier
US20240323018A1 (en) A computer implemented system and method
US20240320667A1 (en) Blockchain blocks &amp; proof-of-existence
US20230300191A1 (en) Connecting to the blockchain network
CN117561697A (zh) 部分基于sha的哈希函数
JP2023529467A (ja) カスタムトランザクションスクリプト
WO2024041862A1 (en) Blockchain transaction
TW202329668A (zh) 證明及驗證有序事件序列之技術
JP2024525888A (ja) ブロックチェーントランザクションに対する条件の強制
CN118525484A (zh) 区块链区块和存在证明
WO2023285053A1 (en) Blockchain blocks &amp; proof-of-existence
JP2024525887A (ja) ブロックチェーントランザクションに対する条件の強制
CN117678193A (zh) 区块链区块和存在证明

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20240924