JP2023547715A - マークルプルーフエンティティ - Google Patents

マークルプルーフエンティティ Download PDF

Info

Publication number
JP2023547715A
JP2023547715A JP2023527771A JP2023527771A JP2023547715A JP 2023547715 A JP2023547715 A JP 2023547715A JP 2023527771 A JP2023527771 A JP 2023527771A JP 2023527771 A JP2023527771 A JP 2023527771A JP 2023547715 A JP2023547715 A JP 2023547715A
Authority
JP
Japan
Prior art keywords
blockchain
transaction
target
merkle
transactions
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
JP2023527771A
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 JP2023547715A publication Critical patent/JP2023547715A/ja
Pending legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic 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/3247Cryptographic 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
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24Querying
    • G06F16/245Query processing
    • G06F16/2455Query execution
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic 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/3236Cryptographic 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/3239Cryptographic 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
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/22Indexing; Data structures therefor; Storage structures
    • G06F16/2228Indexing structures
    • G06F16/2272Management thereof
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50Cryptographic 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)
  • Theoretical Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Databases & Information Systems (AREA)
  • Data Mining & Analysis (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computational Linguistics (AREA)
  • Computing Systems (AREA)
  • Software Systems (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (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を参照することによって送金される金額を定義するのではなく、絶対的なアカウント残高を参照することによって定義される。全てのアカウントの現在の状態は、ブロックチェーンとは別のノードによって格納され、常に更新される。
マークルプルーフは、ブロックチェーン上のトランザクションの存在を検証するために一般的に使用される。特定のトランザクションがブロックチェーン上に存在することを検証したい当事者(ユーザなど)は、ブロックチェーンノードからマークルプルーフを求めることができる。受け取ったマークルプルーフを使用して、ブロックチェーンのブロックに含まれるマークルルートと一致する値までトランザクションを追跡できる場合、ユーザはトランザクションがブロックチェーン上に存在することを確信できる。絶対的な確実性を得るために、追加のチェックが必要になる場合があることに留意されたい。
現在、マークルプルーフを提供する唯一のエンティティはブロックチェーンノード(別名マイナー)である。上で述べたように、ブロックチェーンノードは主にトランザクションの妥当性確認、ブロックの構築と公開に関係する。
ブロックチェーン技術の使用はますます増加しているため、ブロックチェーンシステムは、使用量と需要の増加に合わせて拡張可能である必要がある。ブロックチェーンシステムを拡張する1つのアプローチは、ブロックのサイズとトランザクションのレートを拡大すること、および様々なデータアプリケーションの不変の台帳としてブロックチェーン技術を使用することである。これにより、ブロックチェーンのサイズが大幅に増加し、トランザクションの妥当性確認に費やされる処理量が増加する。したがって、ブロックチェーン全体を格納し、トランザクションを妥当性確認し、トランザクションに関するクエリに応答するためのリソースは、エンドユーザやサービスプロバイダにとって(ストレージと処理要件の点で)コストが高すぎることがある。
したがって、トランザクションがブロックチェーン上に存在するという証明を提供できる、よりリソース効率の高いエンティティが必要となる。さらに、そのようなエンティティがトランザクションに格納された(すなわち、埋め込まれた)データの完全性の証明を提供できれば望ましい。これは、トラストレス環境では特に望ましい。
本明細書に開示の一態様によれば、ブロックチェーントランザクションのデータアイテムがブロックチェーン上に存在するという証明を提供するコンピュータ実装方法が提供され、方法は、マークルプルーフエンティティによって実行され、マークルプルーフエンティティは、それぞれのブロックチェーントランザクションのトランザクション識別子のセットを格納するが、ブロックチェーンネットワークに新しいブロックチェーンブロックを発行しないように構成され、方法は、要求側当事者から、標的ブロックチェーントランザクションの標的データアイテムを取得するステップと、標的ブロックチェーントランザクションを取得するステップと、標的ブロックチェーントランザクションのための標的マークルプルーフを取得するステップであって、対応する標的マークルルートがブロックチェーンのブロック内に含まれ、標的マークルプルーフを取得するステップが、対応する標的マークルツリーのリーフレイヤ内の標的ブロックチェーントランザクションの標的トランザクション識別子のインデックスを計算するステップを備える、ステップと、ブロックチェーン上の標的ブロックチェーントランザクションの一部として標的データアイテムが存在するという証明として、要求側当事者による使用のために、少なくとも標的マークルプルーフを出力するステップとを備える。
マークルプルーフエンティティは、ブロックチェーン上でブロックを構築および/または公開する動作を実行しない。換言すれば、マークルプルーフエンティティはブロックチェーンノードではない(当該技術分野でそのようなノードに使用される用語の一つによれば「マイナー」ではない)。マークルプルーフエンティティ(以下ではマークルプルーフサーバ(MPS)とも呼ばれる)は、要求側当事者にマークルプルーフを提供できるが、トランザクションの妥当性確認やブロックの構築には参加しないため、ブロックチェーンノードよりもリソースの消費が少なくなる。データの格納、データの検索、およびデータの取得は、関連情報(この場合は格納されたトランザクションのセット)のみを格納することによって最適化される。
いくつかの例では、MPSはブロックチェーン全体を格納することなくマークルプルーフを提供できるため、ブロックチェーンノードと比較してストレージ要件が大幅に削減される。例えば、MPSは、対象となるトランザクションのみを生の形式で格納できる。格納されたトランザクションは、特定のアプリケーションまたはサービスに関連することがある。特定の例として、格納されたトランザクションは、1人または複数の患者の医療データを含むことがある。別の例として、格納されたトランザクションには、特定のデータアイテム(公開鍵ハッシュなど)を含む任意のトランザクションが含まれることがある。MPSは、アドレス、公開鍵、データプロトコルフラグなどのトランザクション内のデータフィールド、または部分的なトランザクションデータによるクエリをサポートする。
他の例では、MPSはブロックチェーントランザクションのドメイン全体にサービスを提供することがある。トランザクションに関してはブロックチェーンノードと同じストレージ要件を有するが、MPSはトランザクションを妥当性確認する必要がないため、処理要件が軽減される。マークル証明を提供するために、MPSは、トランザクションを明示的に検証することなく、トランザクションデータまたは対応するTxIDからマークルツリーを構築するだけでよい。
MPSは、クエリされたデータを含むトランザクションを識別し、そのデータを含むトランザクションのマークルプルーフを出力する。マークルプルーフは、トランザクションがブロックチェーン上に存在することを証明する。したがって、クエリされたデータがトランザクションに存在する場合、クエリされたデータはブロックチェーン上のトランザクションに存在する。これは、生のトランザクション内のデータが変更されると、マークルプルーフが無効になることを意味するためであることに留意されたい。言い換えれば、生のトランザクションのわずかな変化は、トランザクションのトランザクション識別子(TxID)が変化することを意味し、TxIDはマークルプルーフの生成に使用されるマークルツリーのリーフハッシュであるため、マークルプルーフは必要なマークルルート(すなわち、トランザクションを含むブロックに格納されたマークルルート)にはつながらない。
標的トランザクション識別子のインデックス、すなわち標的トランザクションのリーフハッシュを決定することにより、MPSはマークルプルーフの一部として提供する正しいハッシュを正確に識別できる。
さらに、トランザクションのマークルプルーフが提供される場合、またはその出力の1つが使用され、支出トランザクションのマークルプルーフが生の支出トランザクションとともに提供される場合、トランザクションはブロックチェーン上に存在すると証明され得る。この観察は、一連の関連トランザクションに必要な証明の数を最小限に抑えるために使用できる。詳細については以下で説明する。
開示の実施形態の理解を助けるために、およびそのような実施形態がどのように実行に移され得るかを示すために、単に例として、添付の図面を参照する。
ブロックチェーンを実装するためのシステムの概略ブロック図である。 ブロックチェーンに記録され得るトランザクションのいくつかの例を概略的に示す図である。 クライアントアプリケーションの概略ブロック図である。 図3Aのクライアントアプリケーションによって提示され得る例示的なユーザインターフェースの概略モックアップの図である。 例示的なマークルツリーを概略的に示す図である。 例示的なマークルプルーフを概略的に示す図である。 本発明のいくつかの実施形態による例示的なシステムを概略的に示す図である。 本発明のいくつかの実施形態による例示的なシステムを概略的に示す図である。 本発明のいくつかの実施形態による第2のマークルプルーフエンティティによって格納されたデータを概略的に示す図である。 本発明のいくつかの実施形態による例示的な方法を示す図である。 気象SVマークルプルーフエンティティにおいて各ロケーションにマップされたデータを示す図である。
例示的なシステムの概要
図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のそれぞれのコピーが、分散ネットワークまたはブロックチェーンネットワーク106の中の複数のブロックチェーンノード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になる。同じトランザクションが両方のフォークに現れるので、これはネットワークのユーザまたはエージェントに影響しないはずであることに留意されたい。
ビットコインブロックチェーン(および大半の他のブロックチェーン)によれば、新しいブロックを構築することに成功するノードは、(あるエージェントまたはユーザから別のエージェントまたはユーザにある額のデジタル資産を移す、エージェント間またはユーザ間のトランザクションとは対照的に)追加の定められた数量のデジタル資産を分配する新しい特別な種類のトランザクションにおいて、追加の、許容される額のデジタル資産を新しく割り当てる能力を与えられる。この特別なタイプのトランザクションは普通、「コインベーストランザクション」と呼ばれるが、「開始トランザクション」または「生成トランザクション」とも呼ばれ得る。それは通常、新しいブロック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はAliceと本明細書では呼ばれ、第2の当事者103bはBobと呼ばれるが、これは限定するものではなく、本明細書でのAliceまたはBobへのあらゆる言及は、それぞれ「第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、例えばAliceが、新しいトランザクション152jをブロックチェーン150に含まれるように送信することを望むとき、彼女は関連するトランザクションプロトコルに従って(彼女のクライアントアプリケーション105のウォレット機能を使用して)新しいトランザクションを編成する。彼女は次いで、クライアントアプリケーション105から、彼女が接続されている1つまたは複数のブロックチェーンノード104に、トランザクション152を送信する。例えば、これは、Aliceのコンピュータ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に基づいてパズルを解こうとしていることがあるが、最初にたどり着いた者が最新のブロック151に含まれるトランザクションのセットを定義することを思い出されたい。最終的に、ブロックチェーンノード104は、Aliceのトランザクション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に記憶される。
Alice 103aが、対象のある額のデジタル資産をBob 103bに移すトランザクション152jを作成することを望んでいるとする。図2において、Aliceの新しいトランザクション152jは「Tx1」とラベリングされる。Tx1は、シーケンスの中の先行するトランザクション152iの出力203においてAliceにロックされるデジタル資産の額をとり、その少なくとも一部をBobに移す。先行するトランザクション152iは、図2では「Tx0」とラベリングされる。Tx0およびTx1は任意のラベルにすぎない。それらは、Tx0がブロックチェーン151の最初のトランザクションであることを必ずしも意味せず、Tx1がプール154の中のすぐ次のトランザクションであることも意味しない。Tx1は、Aliceにロックされている未消費の出力203をまだ有するあらゆる先行する(すなわち、祖先)トランザクションを指し示し得る。
先行するトランザクションTx0は、Aliceが新しいトランザクション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を消費するためにどの情報が必要とされるか、例えば、Aliceの署名の要件を指定する。アンロッキングスクリプトは、トランザクションの出力に現れる。アンロッキングスクリプト(scriptSigとしても知られている)は、ロッキングスクリプト基準を満たすために必要とされる情報を提供する分野特有の言語で書かれるコードである。例えば、それはBobの署名を含み得る。アンロッキングスクリプトはトランザクションの入力202に現れる。
よって、示される例では、Tx0の出力203におけるUTXO0は、UXTO0が引き換えられるようにするために(厳密には、UTXO0を引き換えようとする後続のトランザクションが有効になるために)Aliceの署名SIG PAを必要とするロッキングスクリプト[Checksig PA]を備える。[Checksig PA]は、Aliceの公開-秘密鍵のペアからの公開鍵PAの表現(すなわち、ハッシュ)を含む。Tx1の入力202は、Tx1を指し示す(例えば、そのトランザクションIDであるTxID0によって指し示す、TxID0は実施形態ではトランザクション全体Tx0のハッシュである)ポインタを備える。Tx1の入力202は、Tx0のあらゆる他のあり得る出力の中からUTXO0を特定するために、Tx0内でUTXO0を特定するインデックスを備える。Tx1の入力202はさらに、Aliceが鍵のペアからの自身の秘密鍵をデータのあらかじめ定められた部分(暗号学では「メッセージ」と呼ばれることがある)に適用することによって作成される、Aliceの暗号署名を備えるアンロッキングスクリプト<Sig PA>を備える。Aliceにより有効な署名を提供するために署名される必要のあるデータ(または「メッセージ」)は、ロッキングスクリプトによって、またはノードプロトコルによって、またはこれらの組合せによって定義され得る。
新しいトランザクションTx1がブロックチェーンノード104に到達すると、ノードはノードプロトコルを適用する。これは、アンロッキングスクリプトがロッキングスクリプトにおいて定義される条件(この条件は1つまたは複数の基準を備え得る)を満たすかどうかを確かめるために、ロッキングスクリプトおよびアンロッキングスクリプトを一緒に実行することを備える。実施形態では、これは2つのスクリプトを連結することを伴う:
<Sig PA><PA>||[Checksig PA]
ここで、「||」は連結を表し、「<...>」はスタックにデータを置くことを意味し、「[...]」はロッキングスクリプト(この例では、スタックベース言語)に含まれる関数である。等価的に、スクリプトを連結するのではなく、スクリプトは共通のスタックを用いて次々に実行されてもよい。いずれにしても、一緒に実行されると、スクリプトは、Tx0の出力の中のロッキングスクリプトに含まれるような、Aliceの公開鍵PAを使用して、Tx1の入力の中のアンロッキングスクリプトがデータの予想される部分に署名するAliceの署名を含むことを認証する。データ自体(「メッセージ」)の予想される部分も、この認証を実行するために含まれる必要がある。実施形態では、署名されたデータはTx1の全体を備える(よって、平文でデータの署名された部分を指定する別個の要素が含まれる必要がなく、それは、もともと存在していたからである)。
公開-秘密暗号による認証の詳細は、当業者には馴染みがある。基本的に、Aliceが自身の秘密鍵を使用してメッセージに署名した場合、平文のAliceの公開鍵およびメッセージを与えられると、ノード104などの別のエンティティは、メッセージがAliceによって署名されたに違いないことを認証することが可能である。署名することは通常、メッセージをハッシュし、ハッシュに署名し、これを署名としてメッセージへとタグ付けすることで、公開鍵のあらゆる保有者が署名を認証することを可能にすることを備える。したがって、本明細書における、特定のデータまたはトランザクションの一部に署名することなどへのあらゆる言及は、実施形態では、そのデータまたはトランザクション一部のハッシュに署名することを意味することに留意されたい。
Tx1におけるアンロッキングスクリプトがTx0のロッキングスクリプトにおいて指定される1つまたは複数の条件を満たす場合(よって示される例では、Aliceの署名が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間で分割され得る。したがって、AliceがUTXO0において定義される額のすべてをBobに与えることを望まない場合、彼女はリマインダーを使用してTx1の第2の出力の残金を自分に与え、または別の当事者に支払うことができる。
実際には、Aliceは通常、ブロック151に自分のトランザクション104を含めることに成功したビットコインノード104に対する料金を含める必要がある。Aliceがそのような料金を含めない場合、Tx0はブロックチェーンノード104によって拒絶されてもよく、したがって、技術的には有効であっても、広められず、ブロックチェーン150に含められなくてもよい(ノードプロトコルは、ブロックチェーンノード104がトランザクション152を受け入れることを望まない場合、それを強いることはない)。一部のプロトコルでは、トランザクションフィーは、固有の別々の出力203を必要としない(すなわち、別個のUTXOを必要としない)。代わりに、入力202によって指し示される総額と所与のトランザクション152の出力203において指定される総額とのあらゆる差が、トランザクションを公開するブロックチェーンノード104に自動的に与えられる。例えば、UTXO0へのポインタがTx1への唯一の入力であり、Tx1が唯一の出力UTXO1を有するとする。UTXO0において指定されるデジタル資産の額がUTXO1において指定される額より大きい場合、その差は、UTXO1を含むブロックを作成するプルーフオブワーク競争に勝ったノード104によって割り当てられ得る。しかしながら、代替または追加として、トランザクションフィーが、トランザクション152のUTXO203のうちの自身固有のUTXOにおいて明示的に指定され得ることは、必ずしも排除されない。
AliceおよびBobのデジタル資産は、ブロックチェーン150のどこかにある任意のトランザクション152において彼らにロックされるUTXOからなる。したがって、通常は、所与の当事者103の資産は、ブロックチェーン150全体の、様々なトランザクション152のUTXO全体に分散している。所与の当事者103の総残高を定義する1つの数字が、ブロックチェーン150のどこかに保管されているということはない。それぞれの当事者にロックされており、別のその先のトランザクションにおいてまだ消費されていないすべての様々なUTXOの値を一緒に照合することが、クライアントアプリケーション105のウォレット機能の役割である。そのウォレット機能は、ビットコインノード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を編成すること、サイドチャネル107を介してトランザクションおよび/もしくは他のデータを受信および/もしくは送信すること、ならびに/または、ブロックチェーンネットワーク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は、Aliceの機器102a上のクライアントアプリケーション105aのUI層402によってレンダリングされ得るユーザインターフェース(UI)500の例のモックアップを与える。同様のUIが、Bobの機器102b上のクライアント105b、または任意の他の当事者の機器のクライアントによってレンダリングされ得ることが理解されるだろう。
例示として、図3BはAliceの視点からのUI500を示す。UI500は、ユーザ出力手段を介して別個のUI要素としてレンダリングされる1つまたは複数のUI要素501、502、502を備え得る。
例えば、UI要素は、1つまたは複数のユーザ選択可能要素501を備えてもよく、これは、様々なオンスクリーンボタン、またはメニューの中の様々なオプションなどであってもよい。ユーザ入力手段は、ユーザ103(この場合はAlice103a)が、画面上のUI要素をクリックもしくはタッチすること、または望ましいオプションの名前を話すことなどによって、オプションのうちの1つを選択し、または別様に操作することを可能にするようになされる(本明細書において使用される「手動の」という用語は、自動であることと対比させることのみを意図しており、手を使用することに必ずしも限定しない)。
代替または追加として、UI要素は1つまたは複数のデータエントリフィールド502を備えてもよい。これらのデータエントリフィールドは、例えば画面上の、ユーザ出力手段を介してレンダリングされ、データは、ユーザ入力手段、例えばキーボードまたはタッチスクリーンを通じて、フィールドに入力され得る。代替として、データは、口頭で、例えば発話認識に基づいて受信され得る。
代替または追加として、UI要素は、情報をユーザに出力するための、1つまたは複数の情報要素503の出力を備え得る。例えば、これ/これらは、画面上で、または可聴にレンダリングされ得る。
様々なUI要素をレンダリングし、オプションを選択し、データを入力する特定の手段は、有形ではないことが理解される。これらのUI要素の機能は、まもなくより詳しく論じられる。図3に示されるUI500は、概略的なモックアップにすぎず、実際には、それは1つまたは複数のさらなるUI要素を備えてもよく、これは簡潔にするために示されていないことも理解される。
マークルツリー
マークルツリーは、データのコレクションを安全に検証できるようにする階層データ構造である。マークルツリーでは、ツリー内の各ノードがインデックスペア(i,j)を与えられ、N(i,j)と表される。インデックスi,jは、ツリー内の特定の位置に関連する数字ラベルにすぎない。
マークルツリーの特徴は、それのノードの各々の構築が次の式によって決定されることである。
ここで、Hは暗号化ハッシュ関数である。
これらの式に従って構築されたバイナリマークルツリーを図4に示す。示されるように、i=jのケースはリーフノードに対応し、これは、データDiの対応するi番目のパケットはハッシュにすぎない。i≠jのケースは、内部ノードまたは親ノードに対応し、これは、1つの親(マークルルート)が見つかるまで子ノードを再帰的にハッシュして連結することによって生成される。
例えば、ノードN(0,3)は、以下のように4つのデータパケットD0,...,D3から構築される。
ツリーの深さMは、ツリー内のノードの最下位レベルとして定義され、ノードの深さmはノードが存在するレベルである。例えば、mroot=0、かつmleaf=Mであり、M=3である。
ビットコインおよびいくつかの他のブロックチェーンのマークルツリーでは、ハッシュ関数はダブルSHA256であり、これは、標準ハッシュ関数SHA-256を2回適用すること、H(x)=SHA256(SHA256(x))である。
マークルプルーフ
マークルツリーの主要機能は、いくつかのデータパケットDi
が、N個のデータパケットのリストまたはセットのメンバーであることを検証することである。検証のメカニズムは、マークルプルーフとして知られ、所与のデータパケットDiおよびマークルルートRに対するマークルパスとして知られるハッシュのセットを取得することを含む。データパケットのマークルプルーフは、ハッシュ化と連結を繰り返してルートRを再構築するために必要なハッシュの最小リストにすぎず、多くの場合「認証証明」と呼ばれる。
存在証明は、すべてのパケットD0,...,DN-1とその順序が証明者にわかっている場合には自明に実行することができる。しかしながら、これには、マークルプルーフよりもはるかに大きなストレージオーバーヘッドが必要であり、かつ証明者がデータセット全体を利用できる必要がある。
マークルプルーフの使用とリスト全体の使用の比較を以下の表に示すが、ここではバイナリマークルツリーを使用し、データブロックの数Nが整数の2乗に正確に等しいと仮定している。
次の表は、マークルツリーのリーフノードの数とマークルプルーフに必要なハッシュの数の関係を示す。
この単純化されたシナリオ-データパケットの数がリーフノードの数と等しい-では、マークルプルーフの計算に必要なハッシュ値の数が対数的に増加することがわかる。N個のデータハッシュを格納して明示的なプルーフを計算するよりも、log2Nハッシュを含むマークルプルーフを計算する方が明らかに効率的かつ実用的である。
方法
マークルルートRが与えられると、データブロックD0が、Rによって表された順序付きリスト
に属することを証明することを望み、以下のようにマークルプルーフを実行できる。
i. 信頼されたソースからマークルルートを取得する
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である場合、ツリー内にD0が存在し、したがって、データセットDが確認される。
2. R’≠Rである場合、証明は失敗し、D0は、Dのメンバーであると確認されない。
これは、マークルツリーとそのルートによって表されるデータセットの一部として、一部のデータの存在証明を提供するための効率的なメカニズムである。例えば、データD0がブロックチェーントランザクションに対応し、ルートRがブロックヘッダの一部として公開されている場合、トランザクションがそのブロックに含まれていることをすぐに証明できる。
マークルツリーの例の一部としてD0の存在を認証するプロセスを図5に示す。これは、特定のブロックD0とルートRに対してマークルプルーフを実行すると、必要な最小数のハッシュ値のみを使用してマークルツリーを効果的に「上向きに」走査していることがわかる。
マークル証明を構築するための最小限の情報
単一のリーフのマークルプルーフを構築するとき、必要な最小限の情報は次のとおりである。
1. リーフのインデックス:マークルツリーのリーフ層のリーフの位置
2. ハッシュ値の順序付けリスト:マークルルートの算出に必要なハッシュ値
リーフのインデックスがどのように機能するかを説明するために、図5のマークルツリーを考える。ボブはルートRを知っているが、ツリーのすべてのリーフを知っているわけではない。D0のマークルブランチは、1つのインデックスである0、および3つのハッシュ値(丸で囲まれた部分)で構成される。インデックスは、提供されたハッシュ値を計算されたハッシュ値の左側に連結するか右側に連結するかを示す。
マークルツリーにN=2M個のリーフがあると仮定する。
p0は、インデックスi0を持つリーフノードのペアのリーフノードのインデックスである。マークルツリー(上記を参照)で親ハッシュノードを計算するために連結およびハッシュ化されるため、これらをペアと呼ぶ。インデックスp0を持つノードは、i0リーフノードのマークルルートを計算するときに提供する必要があるため、「提供されたハッシュ」または「必要なデータ」とも呼ばれる。
したがって、層mを定義でき、
である。
そして、与えられたハッシュのインデックスは、
である。
上記の式は、インデックスが0から始まることを前提としている。
本発明の文脈では、インデックスi0を有するリーフノードは、標的トランザクションのトランザクション識別子である。
存在の証明-トランザクションデータ
図6Aは、本発明の実施形態を実装するためのシステム例600を示す。システムは、マークルプルーフエンティティ(またはマークルプルーフサーバ(MPS))601を備える。「マークルプルーフエンティティ」という用語は、本明細書で説明されるアクションを実行するように構成されたエンティティの便宜的なラベルとしてのみ使用されることに留意されたい。同様に、「マークルプルーフサーバ」という用語は、考えられる実施形態の1つではあるが、必ずしも説明されたアクションがサーバ(すなわち、ラックやデータセンタなどの専用または従来のサーバユニットまたはシステム)によって実行されることを意味するわけではない。ブロックチェーンノード104、要求側当事者603、およびSPVクライアント604も示されている。これらの各エンティティのうちの1つだけが示されているが、システム600は一般に、これらの各エンティティを任意の数だけ備えることができることを理解されたい。
MPS601は、トランザクションの特定のデータアイテムがブロックチェーン150上に存在すること、すなわち、コンポーネントを含むトランザクションがブロックチェーン上に存在することの証明を提供するように構成されている。MPS601は、トランザクションのセットを格納するように構成されている。いくつかの例では、MPS601は、ブロックチェーン上に格納されるトランザクションのサブセットのみ、すなわち、ブロックチェーン150全体ではない、を格納し、例えば、MPS601は、対象のトランザクション、特定のアプリケーションまたはサービスに関連するトランザクション、特定のロックスクリプト、プロトコルフラグ、公開鍵などを含むトランザクション、メディアコンテンツを含むトランザクションなどを格納することができる。いくつかの例では、格納されたトランザクションのすべてに、例えば、特定のブロックからのすべてのトランザクション、特定の時間以降または2つの時間の間で公開されたすべてのトランザクション(時間はUNIX(登録商標)時間またはブロックの高さで測定され得る)、特定のブロックチェーンノード104によって公開された1つまたは複数のブロックからのすべてのトランザクションなどの共通点がある。あるいは、MPS601は完全なブロックチェーン、すなわち公開されたすべてのトランザクションを格納することもできる。
MPS601は、ブロックチェーンノード104ではない。すなわち、MPS601はマイニングノードまたは「マイナー」ではない。MPS601は、ブロックチェーンノードによって動作され、またはブロックチェーンノードに接続され得るが、MPS601自体は、トランザクションの妥当性確認、プルーフオブワークの実行、ブロックの構築、ブロックの公開、コンセンサスルールの強制などの動作を実行しない。
MPS601は、標的トランザクションの標的データアイテム、すなわちトランザクションのデータアイテム、またはトランザクションに関連付けられたデータアイテムを取得するように構成される。例えば、システム600は、1つまたは複数の要求側当事者603を含んでもよい。要求側当事者603は、標的データアイテムを含むトランザクションのマークルプルーフの要求の一部として、標的データアイテムをMPS601に送信することができる。いくつかの例では、単に標的データアイテムをMPS601に送信することが、マークルプルーフの要求とみなされる
MPS601は、標的トランザクションを取得するように構成される。標的トランザクションはストレージから取得できる(すなわち、トランザクションの格納されたセットには標的トランザクションが含まれる)。例えば、MPS601は、標的データアイテム、例えば、標的データアイテムを含むトランザクションを検索するために、標的データアイテムに基づいて標的トランザクションを識別することできる。特定の例として、標的データアイテムはトランザクション識別子(TxID)であってもよい。TxIDはトランザクションを一意に識別する。MPS601は、TxIDを使用してルックアップを実行できる。別の例として、標的データアイテムは、公開鍵または公開鍵ハッシュであってよい。MPS6021は、トランザクションの入力および/または出力において公開鍵または公開鍵ハッシュを含むトランザクションを検索できる。あるいは、標的トランザクションは、標的データアイテムとともにMPS601に提供され得る。
標的トランザクションを取得すると、MPS601はまた、標的トランザクションのための「標的マークルプルーフ」、すなわち、標的トランザクションがブロックチェーン上に存在することを証明するためのマークルプルーフを取得するように構成される。標的マークルプルーフは、少なくともハッシュ値の順序付きセットを含む。ハッシュ値の順序付きセット内のハッシュ値の数は、マークルツリー内のリーフの数、すなわち、標的トランザクションを含むブロック151内のトランザクションの数に基づいている。マークルプルーフにはまた、ハッシュ値の順序付きセット内の最初のハッシュ値を標的TxID(すなわち、標的トランザクションのTxID)の左側または右側に連結する必要があるかどうかを示すリーフのインデックスが含まれ得る。
MPS601は、格納されたトランザクションごとにそれぞれのマークルプルーフを格納することができる。すなわち、標的マークルプルーフは、後で必要になったときに使用できるように格納され得る。
標的マークルプルーフを取得することは、ストレージから標的マークルプルーフを抽出すること、またはオンザフライで標的マークルプルーフを算出することを含む。例えば、MPS601は、1つまたは複数のトランザクションのマークルプルーフを事前に計算することができ、あるいはその代わりに、要求側当事者からの要求の受信に応答してマークルプルーフを計算することができる。標的のマークルプルーフを計算するには、マークルツリーを生成できるように、特定のブロックのすべてのトランザクションが必要であることに留意されたい。MPS601は、トランザクションの完全なブロックを取得し、そのブロックのマークルツリーを計算し、その後、不要なトランザクションを取り除くことができる。あるいは、MPS601は、異なるソースからマークルツリーを取得してもよい。次いで、MPS601は、マークルツリーを格納することも、対象のトランザクションのマークルプルーフのみを格納することもできる。標的トランザクションが取得されると、MPS601は対応するマークルプルーフをメモリから検索する(各マークルプルーフは、ストレージ内のそれぞれのトランザクションまたはTxIDに関連付けることができる)。
標的マークルプルーフは、対応するマークルツリーの1つまたは複数の内部ハッシュまたは内部ノードを含むことができる。その場合、要求側当事者にそれらの内部ハッシュのインデックスを提供すると、要求側当事者が先行するハッシュ(標的TxIDなど)を内部ハッシュの左側または右側のどちらに連結するかを知ることができるため有用である。したがって、標的マークルプルーフを抽出するとき、MPS601は、リーフハッシュのインデックス、すなわち標的トランザクションのTxIDを使用して、標的マークルプルーフ内の内部ハッシュのインデックスを計算する。MPSは、格納されたツリー、すなわち、MPSは格納されたツリーを有する、からマークルプルーフを抽出するためにこれらのインデックスを計算する必要があり、リーフインデックスにより、正しいマークルプルーフを抽出するためにツリーからどの内部ノードを選択するかを決定できる。
少なくともいくつかの例では、MPS601は標的TxIDのインデックスのみを計算する必要があることに留意されたい。必要な内部ハッシュを決定するには、この単一のインデックスで十分な場合がある。
各トランザクションのそれぞれのマークルプルーフを格納するオプションに加えて、MPSは、1つまたは複数のマークルツリーを事前に計算して格納することができる。各マークルツリーは、複数の格納されたTxIDのセット、内部ハッシュ値のセット(または内部ノード)、およびマークルルートを含む。この例では、標的マークルプルーフを取得することは、標的TxIDの計算されたインデックスを使用して、標的TxIDを含むマークルツリーから標的マークルプルーフ(すなわち、必要なハッシュ値)を抽出することを含む。
別の例として、MPS601は、標的TxIDの取得に応じて、標的マークルプルーフを計算することができる。すなわち、MPS601は、格納されたTxIDのセットのうちの1つまたは複数を使用して、標的マークルプルーフを計算することができる(例えば、完全なマークルツリーを計算し、必要なハッシュ値を抽出するために標的TxIDのインデックスを使用することによって)。この方法では、MPS601が、標的トランザクションを構成するブロック151からのすべてのトランザクションをストレージ内に保持する必要があることに留意されたい。
標的マークルプルーフを取得するための別のオプションは、MPS601が、異なるエンティティ、例えば、ブロックチェーンノード104またはSPVクライアントアプリケーションから、1つまたは複数のマークルプルーフを受信し、格納することである。このエンティティに与えられる信頼のレベルに応じて、MPS601は、取得されたマークルプルーフが正しく計算されたことを検証することができる。例えば、マークルプルーフは、マークルプルーフの使用が意図されているそれぞれのトランザクションを含むそれぞれのブロックのそれぞれのブロックヘッダに対して検証することができる。この場合、MPS601は、検証された受信されたマークルプルーフのみを格納することを選択してもよい。
MPS601はまた、標的マークルプルーフを出力するように構成されている。例えば、標的マークルプルーフは、要求側当事者603に直接送信されてもよい。あるいは、標的のマークルプルーフは、例えば、ウェブページ上で公開されてもよい。標的マークルプルーフは、標的トランザクションがブロックチェーン上に存在することの証明として使用され得る。MPS601はまた、標的トランザクションを要求側当事者603に出力できる。要求側当事者603が標的トランザクションにアクセスできる場合、これは必要ない。
図8は、MPS601によって実行され得る例示的な方法800を示す。ステップ801で、MPS601は、選択されたトランザクションのセット(例えば、少なくとも1つの未消費のトランザクション出力を有するトランザクション)を記憶する。ステップ802で、MPS601は標的データアイテム(例えば、プロトコルフラグ、公開鍵など)を取得する。ステップ803で、MPS601は、標的データアイテムを含む1つまたは複数の標的トランザクションを取得する。ステップ804で、MPS601は、1つまたは複数のマークルプルーフ、例えば、標的トランザクションごとに1つを取得する。ステップ805で、MPS601はマークルプルーフを出力する。
ブロックチェーン150の各ブロック151は、それぞれのブロックヘッダを備える。MPS601は、1つまたは複数のブロックヘッダを格納できる。例えば、MPS601は、公開されたブロック151ごとにブロックヘッダを格納してもよい。ブロックヘッダは、順序付きリストに格納され得る。ブロックヘッダの順序は、ブロックチェーン150内の対応するブロック151の順序と一致してもよい。いくつかの例では、所与のブロック151からのトランザクションは、そのブロック151のブロックヘッダに関連付けて格納され得る。完全なブロックヘッダを格納するのではなく、MPS601は、いくつかの例では、ブロックヘッダのデータフィールドのすべてではなく、データフィールドの1つまたは複数のみを格納することができる。例えば、MPS601は、ブロックヘッダ内に含まれるマークルルートのみを格納することができる。あるいは、MPS601は、マークルルートおよびブロックヘッダ内に含まれる以前のハッシュを格納してもよい(ブロックヘッダnに格納された以前のハッシュは、n-1番目のブロックヘッダに等しい)。
いくつかの例では、MPS601はまた、標的トランザクションを含むブロック151のブロックヘッダからマークルルートを出力できる。マークルルートは、マークルルートを含むブロックヘッダの一部として、または単独で、またはブロックヘッダの1つまたは複数の他のデータフィールド、例えば、以前のブロックのハッシュ、と組み合わせて出力できる。マークルルートは、要求側当事者603に直接出力されるか、または公開され得る。
MPS601は、対応するトランザクションが公開されたブロックに基づいて、トランザクションをグループに格納できる。すなわち、ブロックnからのトランザクションが1つのグループに格納され、ブロックn-1からのトランザクションが別のグループに格納される、などとなる。各グループ内のトランザクションは、順序付きリストに格納することができ、リスト内のトランザクションの順序は、所与のブロック151内のトランザクションの順序と一致する。MPS601は完全なブロックチェーン150を格納していないため、格納されたトランザクションのリストには、対応するブロック151よりも少ないトランザクションが含まれ得ることに留意されたい。
MPS601は、例えば、ブロックチェーンノード104などブロックチェーンネットワーク106から、格納されたトランザクションの一部またはすべてを取得できる。すべてのトランザクションが、単一のブロックチェーンノード104から取得され得る。代替的に、トランザクションは、一部がブロックチェーンノード104から、一部が異なるブロックチェーンノード104からなど、複数のノードから取得することもできる。同じことがブロックヘッダにも当てはまる。すなわち、格納されたブロックヘッダの一部またはすべて(または格納されたマークルルートおよび/または以前のブロックハッシュだけ)は、単一のブロックチェーンノード104から、または複数のノード104から取得され得る。いくつかの例では、MPS601は、同じブロックチェーンノード104からの所与のブロック(および任意選択でそのブロックのブロックヘッダ)からすべてのトランザクション(または少なくとも関心のあるトランザクション)を取得することができる。MPS601は、ノード104からトランザクションの完全なブロックを取得し、その後、トランザクションのブロックをフィルタリングまたはプルーニングして、関心のあるもの(例えば、特定のデータフィールドまたはデータアイテムを含むもの)を取得することができる。残りのトランザクションはMPSによって格納される。
いくつかの例では、MPS601は、複数のノード104から同じトランザクションおよび/またはブロックヘッダを取得することによって、取得されたトランザクションおよび/またはブロックヘッダの一部またはすべてを検証することができる。
また、MPS601が、ブロックチェーンノード104以外のエンティティから格納されたトランザクションのうちの1つまたは複数を取得できるは排除されない。例えば、MPS601は、アプリケーションプロバイダからトランザクションを取得することができ、例えば、アプリケーションプロバイダは、対応するアプリケーションに関連するトランザクションをMPS601に送信する。別の例として、エンティティ(例えば、サービスプロバイダ)は、そのエンティティによって生成されたすべてのトランザクションをMPS601に送信できる。
いくつかの例では、MPS601は、それぞれのTxIDに対応する生のトランザクションデータを要求することができる。すなわち、MPS601は、1つまたは複数のTxIDを格納し、その後、異なるエンティティ、例えば、ブロックチェーンノード104またはSPVクライアントから、対応するトランザクションを取得することができる。MPS601は、生のトランザクションデータを取得すると、TxIDを生のデータから再生成できるため、TxIDを削除することができる。
同様に、MPS601は、ブロックチェーンノード104以外のエンティティから1つまたは複数のブロックヘッダを取得できる。例えば、MPS601は、1つまたは複数のSPVクライアントからブロックヘッダを取得することができる。
いくつかの例では、MPS601は、ブロックごとにコインベーストランザクションを格納することができる(ブロックごとにコインベーストランザクションが1つだけ存在することを思い出されたい)。これらの例では、MPS601は、標的トランザクションと同じブロックで公開されるコインベーストランザクションのマークルプルーフを取得することができる。次いで、MPS601は、コインベーストランザクション自体と一緒に、コインベーストランザクションのマークルプルーフを、例えば、要求側当事者603に出力することができる。これは、要求側当事者603が、標的のマークルプルーフが正しい長さであることを検証するために使用できる。例えば、コインベースのトランザクションのマークルプルーフの長さが10(すなわち、10個のハッシュ値)の場合、標的マークルプルーフの長さも10でなければならない。
いくつかの例では、MPS601によって格納されたトランザクションは、1つまたは複数のトランザクションチェーンを含むことができる。標的トランザクションのマークルプルーフは、1つまたは複数の親トランザクションの存在、すなわちそれらのトランザクション内のデータの存在を証明するために使用され得る。この場合、標的トランザクションが子トランザクションである場合、標的マークルプルーフは、親トランザクションのそれぞれがブロックチェーン150上で公開されたことを証明する(親トランザクションのそれぞれがブロックチェーン150上に公開されていなければ、子トランザクションはブロックチェーン150上に公開され得ない)。一般に、一連のトランザクションの中で最後に公開されたトランザクションのマークルプルーフは、そのチェーン内の他のすべてのトランザクションの存在を証明する。MPS601は、標的トランザクションの標的マークルプルーフとともに、トランザクションチェーン内の各トランザクションを、例えば、ユーザに直接出力することができる。
MPS601が格納されたトランザクションのマークルプルーフを格納する例では、ストレージを削減するために、MPS601は、標的トランザクションのマークルプルーフのみを格納し、トランザクションチェーン内の他のトランザクションは格納しないようにできる。
場合によっては、標的データアイテムが複数のトランザクションに存在することがある。すなわち、ブロックチェーン150上に複数のトランザクションが存在することがある。MPS601が標的データアイテムを含む複数のトランザクションを識別する場合、MPS601は、識別されたトランザクションのそれぞれについてそれぞれのマークルプルーフを取得して出力することができる。MPS601はまた、識別されたトランザクションのそれぞれを出力できる。あるいは、上述したように、識別されたトランザクションのそれぞれがトランザクションのチェーンを形成する場合、MPS601は、識別されたトランザクションのそれぞれと、トランザクションのうちの最新のもの(すなわち、標的トランザクション)のマークルプルーフのみとを出力することができる。
MPS601は、デスクトップコンピュータ、ラップトップコンピュータ、タブレット、スマートフォン、スマートウォッチなどのウェアラブルスマートデバイス、または自動車などの乗り物に搭載されたコンピュータなどの1つまたは複数のユーザ端末を備えるコンピューティング装置(例えば、図1に示されるものと同様)の形態をとる。加えて、または代わりに、コンピューティング装置はサーバを備えていてもよい。ここでのサーバとは、1つまたは複数の地理的サイトに配置された1つまたは複数の物理サーバユニットを含む論理エンティティを指す。必要な場合には、分散型または「クラウド」コンピューティング技術が当技術分野で知られている。1つまたは複数のユーザ端末および/またはサーバの1つまたは複数のサーバユニットは、パケット交換ネットワークを介して互いに接続することができ、パケット交換ネットワークは、例えば、インターネットなどのワイドエリアインターネットワーク、3GPP(登録商標)ネットワークなどのモバイルセルラネットワーク、イーサネットネットワークなどのワイヤードローカルエリアネットワーク(LAN)、またはWi-Fi、Thread、6LoWPANネットワークなどのワイヤレスLANなどを備える。コンピューティング装置は、コントローラとインターフェースを備える。コントローラは、インターフェース204に動作可能に接続される。コントローラは、MPSに起因するアクションを実行するように構成される。インターフェースは、例えば、トランザクション、ブロックヘッダ、マークルプルーフなどのデータを送受信するように構成される。
コントローラおよびインターフェースの各々は、コンピュータ可読ストレージ上に具体化されるソフトウェアコードの形式で実装され、CPUなどの1つまたは複数のプロセッサ、GPUなどのワークアクセラレータコプロセッサ、および/または他のアプリケーション固有のプロセッサを備え得た処理装置上で実行され、1つまたは複数の地理的サイトにある1つまたは複数のコンピュータ端末またはユニットに実装される。コードが格納される記憶装置は、1つまたは複数の記憶媒体(例えば、電子媒体または磁気媒体)を使用する1つまたは複数の記憶装置を備えることができ、1つまたは複数の地理的サイトの1つまたは複数のコンピュータ端末またはユニット上に実装される。実施形態では、コントローラおよび/またはインターフェースはサーバ上に実装され得る。あるいは、これらのデータアイテムの1つまたは両方のそれぞれのインスタンスは、1つまたは複数のユーザ端末の1つ、一部、またはすべてのそれぞれに部分的または完全に実装されてもよい。さらなる例では、上述のデータアイテムの機能は、ユーザ端末とサーバの任意の組み合わせの間で分割されてもよい。ここでも、必要に応じて、分散コンピューティング技術自体が当技術分野で知られていることに留意されたい。これらのデータアイテムの1つまたは複数が専用のハードウェアで実装される可能性も排除されない。
次に、要求側当事者603について説明する。要求側当事者603は、マークルプルーフを求める要求をMPS601に送信するように構成される。要求側当事者603は、標的データアイテムおよび/または標的トランザクションをMPS601に送信することができる。これに応答して、要求側当事者は、標的マークルプルーフを受信または取得するように構成される。要求側当事者603は、標的マークルプルーフを使用して、標的データアイテムを含む標的トランザクションがブロックチェーン150上に存在することを証明できる。例えば、要求側当事者603は、標的マークルプルーフを二次受信側当事者、例えば、標的トランザクションと一緒に受信側当事者に送信することができる。要求側当事者603はまた、標的トランザクションに基づいてマークルツリーのマークルルート(例えば、ブロックヘッダの一部として)を二次受信側当事者に送信できる。マークルルートはMPS601から取得できる。要求側当事者603は、SPVクライアントであってよい(またはSPVクライアントを動作させてよい)。SPVクライアントは、SPVメソッドを実行するように構成されたクライアントアプリケーションである。詳細については、https://wiki.bitcoinsv.io/index.php/Simplified_Payment_Verificationを参照されたい。すなわち、SPVクライアント(例えば、支出者によって動作される)は、SPV方法を実行するために、すなわち、別の当事者(例えば、受信者)に標的マークルプルーフを提供することによって、標的マークルプルーフを使用することができる。この場合、標的トランザクションは、支出者にロックされ、受信者にロックされたUTXOを含む支出トランザクションによって参照されるUTXO(標的データアイテム)を含むことができる。
要するに、UTXOを消費するために、SPVウォレットを使用する送信者は、次の情報を受信者に渡すことになる:
1. 出力としてUTXOを含むトランザクションTx0
2. Tx0のマークルプルーフ、
3. マークルプルーフから導出したマークルルート(またはその識別子、例えば、ブロックの高さなど)を含むブロックヘッダ、
4. UTXOを消費するトランザクションTx1
情報を検証するために、受信者は、Tx0のマークルプルーフからマークルルートを計算する。次に、受信者はそれをブロックヘッダに指定されたマークルルートと比較する。それらが同じである場合、受信者はTx0がブロックチェーン内にあることを承認する。
要求側当事者603は、Alice 103aまたはBob 103bの形態をとることができる。
ここでMPS601に戻る。MPS601は、二次MPS、または「完全性MPS」と呼ばれることがある。これらの実施形態では、完全性MPS601は、一次MPS、または「一般MPS」602から標的マークルプルーフを取得することができる。一般MPSは、各トランザクションのトランザクション識別子の集合を格納するように構成されたエンティティである。一般MPS602は、完全なブロックチェーンデータ、すなわち、公開されたすべてのトランザクション全体を格納しない。一般MPS602は、標的トランザクションの標的トランザクション識別子を取得し、標的ブロックチェーントランザクションの標的マークルプルーフを取得し、標的マークルプルーフを出力するように構成され、標的マークルプルーフは、トランザクション識別子の格納されたセットのうちの1つまたは複数に基づく。したがって、完全性MPS601は、標的トランザクションまたは標的トランザクションTxIDを一般MPS602に送信し、その返しとして標的マークルプルーフを受信することができる。
図6Bは、完全性MPS601と一般MPS602との間の相互作用を示す例示的なシステム600Bを示す。図示のように、システム600Bは、1つまたは複数のブロックチェーンノード104、完全性MPS601、一般MPS602、要求側当事者603、およびSPVクライアント604を備える。システム600Bは、複数の要求側当事者および/またはSPVクライアントを備えることができる。
一般MPS602から始めると、一般MPS602は主に、所与のトランザクション識別子(TxID)に対するマークルプルーフを提供することに関係する。一般MPS602は、マークルプルーフを要求側当事者603または完全性MPS601に出力することができる。例えば、要求側当事者603または完全性MPS601は、一般MPS602にTxIDを送信することができ、一般MPS602は、その返しとしてマークルプルーフを提供する。一般MPS602は、マークルプルーフを作成するために必要なデータを1つまたは複数のソースから取得することができる。例えば、マークルプルーフ自体はブロックチェーンノード104から取得され得る。あるいは、一般MPS602は、ブロックチェーンノード104から、またはSPVクライアント604から、TxIDおよび対応するブロックヘッダを取得できる。一般MPS602は、TxIDおよび対応するブロックヘッダを使用してマークルプルーフを計算できる。
完全性MPS601に関しては、主としてマークルプルーフを要求側当事者603に提供することに関係する。完全性MPS601は、要求側当事者603からトランザクションコンポーネント(またはトランザクションデータフィールドまたはデータアイテム)を受信し、その返しとして、そのコンポーネントを含むトランザクションのマークルプルーフを提供できる。要求側当事者603は、今度は、トランザクションおよびマークルプルーフを別の当事者、例えば、SPVクライアント604に送信することができる。完全性MPS601は、ブロックチェーンノード104および/またはSPVクライアント604からトランザクションを取得することができる。また、完全性MPS601は、ブロックチェーンノード104および/またはSPVクライアント604からブロックヘッダを取得して、マークルプルーフの一部として使用することもできるが、十分なデータが利用可能であれば、ブロックヘッダは完全性MPSによって計算されてもよい。
一般に、完全性MPS601は、一般MPS602から複数のマークルプルーフを、例えば、格納されたトランザクションごとに1つずつ取得することができる。例えば、完全性MPSが新しいトランザクションを受信して格納するとき、完全性MPS601は、新しいトランザクションのマークルプルーフを求める要求を一般MPS602に送信することができる。
次に、本発明のいくつかの実施形態の実装例について説明する。
一般MPS
一般MPS602は、マークルプルーフを受信側当事者、例えばユーザに提供する専用サーバとして機能する。すなわち、一般MPS602は、トランザクションがブロックチェーン上で公開されている場合に、所与のトランザクションまたはトランザクションIDに対するマークルプルーフを提供するサーバである。一般MPS602は完全なトランザクションデータを格納していない。これは、マークルツリーのストレージを備えたブロックチェーンネットワーク内のSPVクライアントを補完するものと考えることができる。より正確には、一般MPSには次のようなストレージ要件のリストがある:
1. 最も多くのプルーフオブワークを持つチェーンを表すブロックヘッダの順序付きリスト(オプション要件)、
2. 各ブロックヘッダのトランザクションIDの順序付きリスト(コア要件)、
3. マークルルートがブロックヘッダで指定されたマークルルートと一致する、ブロックヘッダごとに事前に計算されたマークルツリー(オプションの要件)、
4. 各ブロック内のコインベーストランザクションの生データ、または各ブロックヘッダのブロック内のトランザクションの生データ(オプションの要件)。
第1の要件は、一般MPS602のデータ完全性を保証することである。ブロックヘッダのマークルルートは、トランザクションIDのリストの整合性チェックとして使用できる。すなわち、ブロックヘッダは、マークルツリーのリーフを形成するときに、特定のブロックからのTxIDがブロックヘッダ内のマークルルートを示すことを確認するために使用できる。例えば、TxIDが信頼できるか、または一般MPS602が信頼できるSPVクライアント、または最も多くのプルーフオブワークを有するチェーンのブロックヘッダを記憶していると信頼できる任意のエンティティへの安全なアクセスを有する場合、第1の要件をドロップすることができる。
第2の要件は、マークルツリーを再構築できるように、マークルツリーに出現する順序でマークルリーフを提供することである。コインベーストランザクションIDは常にリストの最初のリーフまたは最初のハッシュであることに留意されたい。リーフの順序は、ウィニングブロックを構築したブロックチェーンノードによって決定される。ビットコインSVでは、順序はトポロジー的順序と最初に見られたルールを反映する必要がある。
第3の要件は、計算とストレージとの間のトレードオフのオプションを提供する。図7はストレージ要件を示しており、実線のボックスは必須(いくつかの例では)、破線のボックスはオプションである。ブロックヘッダには、示されているフィールドへの追加のフィールドを含むが、一般にマークルプルーフにはルートハッシュのみが必要であることに留意されたい。以前のハッシュは、ルートハッシュのインデックス付けに使用され得る。重要な点は、一般MPS602が内部ノードを格納する必要がないことである。
第4の要件は、マークルツリーの深さの証明を提供することである。これは、一般MPS602がユーザに提供できる追加サービスである。トランザクションの生データが提示されると、リーフではない所与のハッシュ値に対して意味のあるトランザクションを構築することは計算上不可能であるため、検証者はマークルプルーフの最初のハッシュが実際にリーフであると確信できる。さらに、マークルプルーフの長さはマークルツリーの深さを意味するため、同じツリーからのすべてのマークルプルーフは同じ長さを有する。このサービスは、関心のあるトランザクションの生データをユーザが所有していない場合に特に役立つ。
トランザクションID、例えばTxID_1が与えられると、一般MPS602はトランザクションIDの順序付きリストを調べる。一般MPS602は、TxID_1を見つけると、TxID_1に対するマークルプルーフを構築または抽出し、それを出力する。それ以外の場合、一般MPS602は、例えば、「トランザクションが見つかりません」と出力する。トランザクションの生データが与えられると、一般MPS602は、データをハッシュ化して対応するトランザクションIDを取得し、上記のように進めることができる。
新しいブロックが公開されると、一般MPS602は以下を取得する:
1. 新しいブロックヘッダ、
2. 新しいブロックのトランザクションIDの順序付きリスト、および
3. 生のコインベーストランザクション。
一般MPS602は、オプションで以下をチェックできる:
1. 新しいブロックヘッダには有効なプルーフオブワークを有すること、
2. トランザクションIDから計算されたマークルルートは、ブロックヘッダのマークルルートと等しいこと、および
3. コインベーストランザクションのハッシュが、リーフの最初の要素と等しいこと。
注意-サーバが生のトランザクションを取得する、あるいはトランザクションの署名検証を実行する必要はない。
以下では、マークルツリーの深さを提供することが価値のあるサービスである理由を説明する。SPVクライアントは、トランザクションIDとマークルプルーフを入力として受け取り、マークルルートがブロックヘッダの1つと一致する場合はtrueを出力し、そうでない場合はfalseを出力する。しかしながら、必要な情報が不足しているため、この検証ではマークルプルーフの長さがマークルツリーの長さと一致するかどうかはチェックされない。いくつかの場合では、攻撃者は、存在しないトランザクションIDが存在することを証明しようとして、短縮されたマークルプルーフを送信することがある。この短縮されたマークルプルーフは、リーフまたは後続のハッシュを完全に削除することで取得できる。
マークルプルーフプロバイダとしての一般MPS602は、マークルプルーフの長さを検証するために必要な情報を提供するのに最適な位置にある。一般MPS602は、マークルツリーの深さを明示的に提供する代わりに、コインベーストランザクションの生データとそのマークルプルーフを提供する。生のトランザクションデータとマークルプルーフを偽造することは計算上不可能である。したがって、それはマークルツリーの深さの証明として機能する。ツリーの深さを知ることで、上記の重大な脆弱性を軽減できる。SPVに関心のあるトランザクションの生データとマークルプルーフが提供されている場合、この脆弱性に対して安全であることに留意されたい。関心のあるトランザクションの生データをSPVが持っていない場合、コインベーストランザクションの生データとそのマークルプルーフを使用して、マークルツリーの深さ、またはこのマークルツリーに関するマークルプルーフの正しい長さを確立できる。
理論的には、この脆弱性を利用して、一般MPS602をだまして、リーフまたは後続のレベルが完全に削除されたマークルツリーを受け入れるようにすることもできる。しかしながら、一般MPS602は、受信した情報の一貫性および正確性を保証するために複数のブロックチェーンノード104に接続することができる。さらに、一般MPS602はまた、コインベーストランザクションの生データをダウンロードして、新しいブロックのマークルツリーの深さを検証することを選択できる。
一般MPS602は、同じブロック高さで同時に複数のブロックが見つかった場合に起こる、競合するブロック、再編成、および孤立ブロックを処理しなければならない場合がある。幸いなことに、この状況は最新のヘッダ以外では発生せず、また発生するものではない。ブロックチェーン150は、通常、1つまたは2つのブロックの後に、競合するチェーンの1つに収束する。したがって、一般MPS602が同じ高さで2以上のブロック151を受信すると、ブロックチェーンネットワークが最も多くのプルーフオブワークを有するチェーンに収束するまで、それらのすべてを保持する。
TxID-only MPSの制限
説明した一般MPS602には、いくつかの制限がある。未公開のトランザクション、例えば、TxIDpaymentが与えられると、一般MPS602は、入力で参照されるアウトポイントが存在することを検証できない。その理由は、アウトポイントがトランザクションIDとインデックスを連結したものであるためである。一般MPS602は、トランザクションIDが存在するかどうかを判定することができるが、トランザクションが有する出力の数、または出力が使用可能か否かについての情報を持たない。これを克服する1つの方法は、TxIDpaymentで参照されるトランザクションの生データを入力の一部として一般MPS602に提供することである。別の方法は、一般MPS602が未消費のトランザクションの生データを格納することである。(ここでの未消費のトランザクションとは、未消費の出力と使用可能な出力が少なくとも1つあるトランザクションを指す。)
一般MPS602がトランザクションIDと対応するインデックスのみを記憶している場合、一般MPS602はインデックスが改ざんされていないことを検証または証明することができないことに留意されたい。一般MPS602は、インデックスの完全性を検証または証明するために完全な生データを必要とする。
さらに、ロッキングスクリプトやフラグなど、トランザクション内の特定のデータ要素を検索するユーザに提供することはできない。したがって、通常、トランザクションに含まれるロッキングスクリプトと公開鍵に基づいてトランザクションをフィルタリングするため、例えばブルームフィルタを使用してユーザをサポートすることができない。
これは、より粒度の高いレベルで情報を提供できるMPSの必要性につながる。これを完全性MPS601と呼ぶ。完全性MPS601は、いくつかのトランザクションの生データを格納する。完全なトランザクションがユーザによって与えられた場合、一般MPS602を使用して、公開されたトランザクションの完全性を証明できることに留意されたい。完全性MPS601は、関心のある完全なトランザクションを格納することによって、公開されたトランザクションから抽出された一部のデータの完全性を証明するために使用され得る。ユーザが完全なトランザクション全体を提示する必要はない。
完全性MPS
完全性MPS601は、関心のあるトランザクションのセットに対する生のトランザクションと、それらに対応するマークルプルーフを格納する。このセット内のトランザクションに関するクエリの場合、このサーバは生のトランザクションとその完全性の証拠としてマークルプルーフを提供できる。また、トランザクション内容の部分的なトランザクションまたはデータ要素の検索が可能である。関心のあるトランザクションは、Weather SV、Tokenized、Metanet、その他のデータプロトコルなどのデータアプリケーション、さらにはロッキングスクリプト、公開鍵、アウトポイントなどのデータ文字列に基づいて決定され得る。したがって、Weather SVのみを運ぶトランザクションを格納するように構成されたWeather SVアプリケーション専用の完全性MPSが存在し得る。
関心のある生のトランザクションのセットは、完全性MPS601に渡され、公開される場合にはサーバ上に存続する。完全性MPS601は、ゲートウェイとして考えることができ、またはアプリケーション固有のトランザクションのためにゲートウェイにアクセスすることができる。ブロックチェーンシステムがテラバイトブロックまで拡張される場合、このことは完全性MPS601を維持する最も効率的な方法になる。完全に分散化されたピアツーピアデータアプリケーションなどの他の例では、ブルームフィルタを使用したビットコイン改善提案37(BIP37)のように、トランザクションのブロック全体をダウンロードし、関心のないトランザクションをプルーニングするかフィルタリングするメカニズムに頼らなければならない。動作中
完全性MPS601は、関心のある生のトランザクションおよびそのマークルプルーフをマークルツリー内に維持し、いくつかの実施形態では以下のステップを実行する:
ステップ1: 関心のある生のトランザクションを取得する。
ステップ2: 生のトランザクションをハッシュしてトランザクションIDを取得する。
ステップ3: 一般MPS602にそのマークルプルーフをクエリする。
ステップ4: トランザクションがブロックに公開されていない場合は、10分間待ってから再試行する。
ステップ3における一般MPS602への依存は、ダウンロードおよびプルーニングのメカニズムによって置き換えることができるが、これは効率が劣るであろう。ステップ4の未公開トランザクションは、輻輳を避けるために、事前に定義された制限時間が経過するとドロップされ得る。制限はアプリケーションごとに異なることができる。
使用例の例
Weather SV(WSV)は、ユーザが気象データをビットコイン台帳に記録できるようにするアプリケーションである。各場所には一意の公開鍵(すなわち、一意のロッキングスクリプト)が与えられる。次のような特徴を有する:
・アクティブ化された場所は、ほぼ1時間ごとに、その時点のその場所の気象測定値を含むWSVトランザクションのアップロードを開始できる。
・各WSVトランザクションは1つの入力と2つの出力を有する。・出力は次のもので構成される:
〇 0 satoshiの非消費型出力。OP_FALSE OP_RETURNとそれに続く次の連結がある。
・すべてのWSVトランザクションに対して定数であるフラグ、flag_WSV、および
・その場所の天気予報、気象データ
〇 場所の一意の公開鍵アドレスに送信される消費可能な出力。このアドレスをチャネルと呼ぶ。各場所には独自の住所がある。
・入力は、その場所に対する以前のWSVトランザクションの消費可能な出力を消費する。
注意-これは、公開鍵が場所ごとに再利用されることを意味する。
上の表は、チャネルAのWSVトランザクションの例を示す。
これには、OP_RETURNの後にWSVアプリケーションフラグとチャネルAに関連付けられた場所の気象データが連結された、非消費型出力を有する。
現在、このアプリケーションには6240チャンネルがあり、総ブロードキャスト数は3.27×107トランザクションである。2020年3月にかけて、WSVトランザクションの数はBSVブロックチェーン上のトランザクションの約27%を占めていた。
Weather SVのための完全性MPS601は、次のことを実現するように設計できる。
・WSVトランザクションまたはWSVトランザクションから部分的に抽出されたデータでクエリされると、完全性MPS601は、完全性証明を有する完全なデータを提供できる。
部分的に抽出されたデータは、トランザクションのOP_RETURNペイロード内のデータ文字列、場所を表す公開アドレス、または単なるトランザクションIDである可能性があることに留意されたい。
単一の場所のWSVトランザクションが一連のトランザクションであることを観察すると、親トランザクションのマークルプルーフをプルーニングすることができる。例えば、TX1、TX2、…、TX10という10個のトランザクションのチェーンがある場合、TX10のマークルプルーフを保持するだけでよい。ただし、完全性MPSがTX1の完全性証明を提供するように求められた場合、TX2、TX3、…、TX10のすべての生データとTX10のマークルプルーフを提供する必要がある。これは帯域幅とストレージの間のトレードオフである。バランスを取るために、チェーン内の他のトランザクションをすべてプルーニングできる。すなわち、TX1、TX3、…、TX9のマークルプルーフを取り除くことができる。このようにして、チェーン内のトランザクションでクエリが実行されると、完全性MPSは、最悪の場合2つの生のトランザクションと1つのマークルプルーフを提供する。
以下をチェックすることにより、WSVトランザクションの信頼性を識別する:
・アウトポイント(トランザクション入力)は、以前のWSVトランザクションの消費可能な出力である。
・トランザクション入力と消費可能な出力は両方とも同じWSVウォレットアドレスに対するものである。
したがって、本物のトランザクションは、その特定の気象SVアドレスのロックスクリプトの公開鍵に対する秘密鍵を知っているエンティティによってのみ生成できるトランザクションである。
各気象アドレス(すなわち、気象チャネルまたはロッキングスクリプト)について、MPS601は以下を保持する:
・最新のマイニングされたトランザクションとそれに関連するマークルツリー、
・そのアドレスに関連付けられたすべての使用済みトランザクションの生のトランザクションデータ。WSVプロトコルの場合、以前に使用されたトランザクションのマークルツリーを格納する必要はない。
図9に示すように、WSVトランザクションのための完全性MPS601のインスタンスは、各場所に対して以下を格納する:
・関連付けられたアドレス、および各アドレスについて
・未消費の消費可能出力TxIDi||1を含む生のトランザクションTxIDi
・TxIDiに関連付けられたブロックヘッダ、
・そのブロックヘッダのマークルプルーフ、および
・そのIDがTxIDi-1、TxIDi-2、…、TxIDi-rである生の親トランザクション。
親トランザクションは、マークルプルーフを格納する必要はない。生データのトランザクション形式は維持されるため、常に現在のTxIDiにリンクできる。
ストレージの節約
現在のブロックサイズ、レートなどについて、少なくとも最後の6ブロックのそれぞれについて、およそ128Kバイトx6=768Kbであるマークルツリーが必要である。30日間の各チャネルの生データトランザクションは、現在、300x30x24=0.2Mbである。すべての6240チャネルに対して、必要なストレージは1.26GBのみである。一方、先月のみのブロックチェーンは、4.8GBで、ブロックチェーン全体は200Gbである。結論として、WSVアプリケーションのための完全性MPS601は、同じ期間にわたってブロックチェーンの4分の1だけを格納する必要がある。
データアプリケーションが大量のトランザクションを生成する場合、それらのトランザクションを分割する複数の完全性MPS601を有することによってプロセスを並列化することが可能である。ブロックの高さに基づく分割が良い解決策になる。ブロックの高さが不明な場合は、クエリがすべてのMPSに送信される。トレードオフは、大規模なデータセット内の1つのルックアップと、少数のはるかに小さいデータセット内のいくつかのルックアップの間で行われる。
結論
開示される技法の他の変形または使用事例は、本明細書の開示を与えられれば当業者に明らかになり得る。本開示の範囲は、説明される実施形態ではなく、添付の特許請求の範囲だけによって限定される。
例えば、上のいくつかの実施形態は、ビットコインネットワーク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. ブロックチェーントランザクションのデータアイテムがブロックチェーン上に存在するという証明を提供するコンピュータ実装方法であって、方法は、マークルプルーフエンティティによって実行され、マークルプルーフエンティティは、それぞれのブロックチェーントランザクションのトランザクション識別子のセットを格納するが、ブロックチェーンネットワークに新しいブロックチェーンブロックを発行しないように構成され、方法は、要求側当事者から、標的ブロックチェーントランザクションの標的データアイテムを取得するステップと、標的ブロックチェーントランザクションを取得するステップと、標的ブロックチェーントランザクションのための標的マークルプルーフを取得するステップであって、対応する標的マークルルートがブロックチェーンのブロック内に含まれ、標的マークルプルーフを取得するステップが、対応する標的マークルツリーのリーフレイヤ内の標的ブロックチェーントランザクションの標的トランザクション識別子のインデックスを計算するステップを備える、ステップと、ブロックチェーン上の標的ブロックチェーントランザクションの一部として標的データアイテムが存在するという証明として、要求側当事者による使用のために、少なくとも標的マークルプルーフを出力するステップとを備える。
言い換えれば、この方法は、標的データアイテムを含むブロックチェーントランザクションがブロックチェーン上に存在することの証明を提供する。
いくつかの実施形態では、複数のブロックチェーントランザクションが標的データアイテムを構成することができる。マークルプルーフエンティティは、それらの複数の標的トランザクションを取得し、複数の標的トランザクションのそれぞれについてそれぞれの標的マークルプルーフを取得し、要求側当事者による使用のために少なくともそれぞれの標的マークルプルーフを要求側当事者に出力することができる。マークルプルーフエンティティはまた、複数の標的ブロックチェーントランザクションの各々を出力できる。
ブロックチェーンのブロック内に含まれるマークルルートは、ブロックチェーンのブロックのブロックヘッダ内に含まれるマークルルートを含むことができる。
ステートメント2. 要求側当事者にインデックスを出力するステップを備える、ステートメント1に記載の方法。
ステートメント3. マークルプルーフがインデックスを含む、ステートメント2に記載の方法。
ステートメント4. マークルプルーフエンティティが完全なブロックチェーンを格納していない、ステートメント1~3のいずれかに記載の方法。
換言すれば、ブロックチェーントランザクションのセットはブロックチェーン上に公開されたすべてのトランザクションを含むわけではない。
ステートメント5. ブロックチェーン上の標的ブロックチェーントランザクションの一部として標的データアイテムが存在するという証明として、要求側当事者による使用のために標的ブロックチェーントランザクションを出力するステップを備える、ステートメント1~4のいずれかに記載の方法。
ステートメント6. ブロックチェーントランザクションの格納されたセットは、1つまたは複数のブロックチェーンノードから取得される、ステートメント1~5のいずれかに記載の方法。
ステートメント7. 1つまたは複数のブロックチェーンノードから複数のブロックチェーントランザクションを取得するステップと、
複数のブロックチェーンノードをプルーニングおよび/またはフィルタリングして、ブロックチェーントランザクションの格納されたセットうちの1つまたは複数を取得するステップとを備える、ステートメント5に記載の方法。
ステートメント8. ブロックチェーントランザクションの格納されたセットのうちの1つまたは複数は、サービスプロバイダから取得され、ブロックチェーントランザクションの格納されたセットは、サービスプロバイダによって提供されたサービスに関連する、ステートメント1~7のいずれかに記載の方法。
ステートメント9. 標的ブロックチェーントランザクションを取得するステップは、格納されたセットのブロックチェーントランザクションから標的ブロックチェーントランザクションを取得するステップを含む、ステートメント1~8のいずれかに記載の方法。
例えば、標的データアイテムを有するブロックチェーントランザクションを検索することによってなされる。
ステートメント10. 標的ブロックチェーントランザクションを取得するステップは、要求側当事者から標的ブロックチェーントランザクションを受け取るステップを含む、ステートメント1~9のいずれかに記載の方法。
ステートメント11. 標的マークルプルーフを取得するステップは、
標的ブロックチェーントランザクションまたは標的ブロックチェーントランザクションの標的トランザクション識別子を、それぞれのブロックチェーントランザクションのトランザクション識別子のセットを格納するように構成された一次マークルプルーフエンティティに送るステップと、
一次マークルプルーフエンティティから標的マークルプルーフを受け取るステップであって、標的マークルプルーフは、トランザクション識別子の格納されたセットのうちの1つまたは複数に基づいている、ステップと
を含む、ステートメント1~10のいずれかに記載の方法。
ステートメント12. 標的マークルプルーフは、要求側当事者から標的データアイテムを取得する前に取得される、ステートメント11に記載の方法。
ステートメント13. ブロックチェーントランザクションの格納されたセットのうちの各々のブロックチェーントランザクションのためのそれぞれのマークルプルーフを取得するステップを備える、ステートメント11または12に記載の方法。
ステートメント14. 標的マークルプルーフを取得するステップは、標的マークルプルーフを計算するステップを含む、ステートメント1~13のいずれかに記載の方法。
ステートメント15. 標的マークルプルーフを出力するステップは、標的マークルプルーフを要求側当事者に送信するステップおよび/または標的マークルプルーフを発行するステップを含む、ステートメント1~14のいずれかに記載の方法。
ステートメント16. 標的ブロックチェーントランザクションを出力するステップは、標的ブロックチェーントランザクションを要求側当事者に送信するステップおよび/または標的ブロックチェーントランザクションを発行するステップを含む、ステートメント5またはステートメント5に従属するステートメントのいずれかに記載の方法。
ステートメント17. ブロックチェーントランザクションの格納されたセットは、ブロックチェーントランザクションの複数のサブセットを含み、ブロックチェーントランザクションの各サブセットは、ブロックチェーンのそれぞれのブロックからのものである、ステートメント1~16のいずれかに記載の方法。
トランザクション識別子の各サブセットは、それぞれのブロックに格納されたブロックチェーントランザクションの順序に対応した順序付きリストに格納されて得る。
ステートメント18. ブロックチェーントランザクションの各サブセットは、ブロックチェーンのそれぞれのブロックのそれぞれのブロックヘッダに関連して格納される、ステートメント17に記載の方法。
それぞれのブロックヘッダは、ブロックチェーン上で公開されるブロックの順序に対応する順序付きリストに格納され得る。
ステートメント19. それぞれのブロックヘッダは、1つまたは複数のブロックチェーンノードから取得される、ステートメント1~18のいずれかに記載の方法。
ブロックヘッダのすべてが単一のノードから取得されてよい。代替として、ブロックヘッダが、例えば、一部は1つのノードから、一部は別のノードからなど、複数のノードから取得されてよい。
いくつかの例では、マークルプルーフエンティティは、複数のノードから同じブロックヘッダを取得することによって、取得されたブロックヘッダの一部またはすべてを検証することができる。
追加または代替として、ブロックヘッダの一部またはすべてを1つまたは複数の簡易支払検証(SPV)クライアントから取得することができる。
ステートメント20. マークルプルーフエンティティは、ブロックチェーントランザクションの各サブセットに対して、ブロックチェーントランザクションのサブセットを含むそれぞれのブロックからの生成ブロックチェーントランザクションを格納する、ステートメント17またはステートメント17に従属するステートメントのいずれかに記載の方法。
ステートメント21. 生成ブロックチェーントランザクションのためのマークルプルーフを取得するステップと、
標的マークルプルーフの長さが対応する標的マークルツリーの長さと一致することを証明するために、要求側当事者による使用のために、少なくともマークルプルーフを出力するステップと
を備える、ステートメント20に記載の方法。
ステートメント22. マークルプルーフを出力するステップは、生成ブロックチェーントランザクションを出力するステップを含む、ステートメント21に記載の方法。
ステートメント23. 標的データアイテムは、
標的ブロックチェーントランザクションのトランザクション識別子、
標的ブロックチェーントランザクションの入力、
標的ブロックチェーントランザクションの出力、
標的ブロックチェーントランザクションの入力のデータフィールド、および/または、
標的ブロックチェーントランザクションの出力のデータフィールドの少なくとも一つを含む、ステートメント1~22のいずれかに記載の方法。
ステートメント24. 標的ブロックチェーントランザクションの入力のデータフィールドまたは出力のデータフィールドは、ブロックチェーンアドレス、公開鍵、プロトコルフラグ、ロッキングスクリプト、および/またはメディアコンテンツの少なくとも一つを含む、ステートメント23に記載の方法。
ステートメント25. ブロックチェーントランザクションの格納されたセットは、複数のブロックチェーントランザクションのチェーンを含み、標的ブロックチェーンは、複数のブロックチェーントランザクションのチェーンのうちの最新のものである、ステートメント1~24のいずれかに記載の方法。
ステートメント26. ブロックチェーントランザクションのチェーンの各トランザクションがブロックチェーン上に存在することの証明として要求側当事者による使用のために、ブロックチェーントランザクションのチェーンに各トランザクションを出力するステップを備える、ステートメント25に記載の方法。
ステートメント27. ブロックチェーントランザクションのチェーンにいずれの他のトランザクションのためのマークルプルーフを格納せずに、標的マークルプルーフのみを格納するステップを備える、ステートメント25または26に記載の方法。
ステートメント28. 要求側当事者はエンドユーザである、ステートメント1~27のいずれかに記載の方法。
ステートメント29. 1つまたは複数のメモリユニットを備えたメモリと、
1つまたは複数の処理ユニットを備えた処理装置とを備え、メモリは処理装置上で実行するように配置されたコードを格納し、コードは、処理装置上で実行されると、ステートメント1~28のいずれかに記載の方法を実行するように構成される、コンピュータ機器。
ステートメント30. コンピュータ可読ストレージ上に具現化されたコンピュータプログラムであって、1つまたは複数のプロセッサ上で実行されると、ステートメント1~28のいずれかに記載の方法を実行するように構成されたコンピュータプログラム。
100 システム
101 ブロックチェーンネットワーク、パケット交換ネットワーク、インターネット
102 コンピュータ機器、コンピュータ端末
102a Aliceのコンピュータ機器、Aliceのデバイス
102b Bobのコンピュータ機器、Bobのデバイス
103 ユーザ、エンティティ、当事者、エージェント
103a ユーザ、エンティティ、第1の当事者、Alice
103b ユーザ、エンティティ、第2の当事者、Bob
104 ブロックチェーンノード、第1のノード、ビットコインノード、トランザクション
105 クライアントアプリケーション、ソフトウェア、クライアント
105a クライアントアプリケーション
105b クライアント
106 ブロックチェーンネットワーク、ビットコインネットワーク
150 ブロックチェーン、クライアントアプリケーション、ビットコインブロックチェーン
151 ブロック、ブロックチェーン
151n-1 ブロック
151n ブロック
152 トランザクション
152i トランザクション
152j トランザクション
153 ジェネシスブロック(Gb)
154 順序付けられたセット、トランザクション、プール
155 ブロックポインタ
160 ブロックチェーンネットワーク

Claims (30)

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

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
GB2017731.7 2020-11-10
GB2017731.7A GB2600770A (en) 2020-11-10 2020-11-10 Merkle proof entity
PCT/EP2021/078213 WO2022100946A1 (en) 2020-11-10 2021-10-12 Merkle proof entity

Publications (1)

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

Family

ID=74046369

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2023527771A Pending JP2023547715A (ja) 2020-11-10 2021-10-12 マークルプルーフエンティティ

Country Status (8)

Country Link
US (1) US20230394063A1 (ja)
EP (1) EP4245010A1 (ja)
JP (1) JP2023547715A (ja)
KR (1) KR20230101843A (ja)
CN (1) CN116547945A (ja)
GB (1) GB2600770A (ja)
TW (1) TW202220411A (ja)
WO (1) WO2022100946A1 (ja)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2024097406A1 (en) * 2022-11-04 2024-05-10 Interdigital Patent Holdings, Inc. Methods, architectures, apparatuses and systems directed to application-aware computing and communication management in a blockchain system

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113508410A (zh) * 2019-02-15 2021-10-15 区块链控股有限公司 用于通过区块链网络实现转账的计算机实现的***和方法

Also Published As

Publication number Publication date
TW202220411A (zh) 2022-05-16
US20230394063A1 (en) 2023-12-07
WO2022100946A1 (en) 2022-05-19
CN116547945A (zh) 2023-08-04
KR20230101843A (ko) 2023-07-06
EP4245010A1 (en) 2023-09-20
GB202017731D0 (en) 2020-12-23
GB2600770A (en) 2022-05-11

Similar Documents

Publication Publication Date Title
US20230237477A1 (en) Methods and devices for validating data in a blockchain network
US20230388136A1 (en) Merkle proof entity
GB2606195A (en) Methods and devices for enabling single page retrieval of merkle tree data
JP2023547715A (ja) マークルプルーフエンティティ
WO2023012127A1 (en) A computer implemented method and system
JP2023529467A (ja) カスタムトランザクションスクリプト
US20240205030A1 (en) Uniform resource identifier
US20240106670A1 (en) Headers client for determining the best chain
US20240121118A1 (en) Blockchain tree structure
GB2606194A (en) Methods and devices for pruning stored merkle tree data
WO2023285053A1 (en) Blockchain blocks &amp; proof-of-existence
EP4371271A1 (en) Blockchain blocks &amp; proof-of-existence
GB2606196A (en) Subtree-based storage and retrieval of merkle tree data
WO2024033010A1 (en) Efficient identification of blockchain transactions
EP4371269A1 (en) Blockchain blocks &amp; proof-of-existence
JP2024500923A (ja) トランザクション署名フラグ
WO2024017786A1 (en) Proving and verifying input data