特表 2024-521606 最良のチェーンを決定するためのヘッダクライアント

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

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

(11)【公表番号】

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

(54)【発明の名称】最良のチェーンを決定するためのヘッダクライアント

(51)【国際特許分類】

   G06F 16/182 20190101AFI20240528BHJP

   G06F 16/28 20190101ALI20240528BHJP

【ＦＩ】

G06F16/182

G06F16/28

【審査請求】未請求

【予備審査請求】未請求

(21)【出願番号】P 2023539022

(86)(22)【出願日】2022-04-29

(85)【翻訳文提出日】2023-08-18

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

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

(87)【国際公開日】2022-11-17

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

(32)【優先日】2021-05-14

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

(81)【指定国・地域】

【公序良俗違反の表示】

（特許庁注：以下のものは登録商標）

１．Ｌｉｎｕｘ

２．ＷＩＮＤＯＷＳ

３．ＪＡＶＡＳＣＲＩＰＴ

(71)【出願人】

【識別番号】318001991

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

(74)【代理人】

【識別番号】100108453

【弁理士】

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

(74)【代理人】

【識別番号】100110364

【弁理士】

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

(74)【代理人】

【識別番号】100133400

【弁理士】

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

(72)【発明者】

【氏名】アンドリュー・ジェームズ・ミー

(72)【発明者】

【氏名】マイケル・フレッチャー

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

5B175

【Ｆターム（参考）】

5B175AA01

5B175KA12

(57)【要約】

ブロックチェーンネットワークにおいてデータを管理するためのメカニズムが、提供される。一実施形態では、ヘッダクライアントにおいて実行され、以下のステップを含むコンピュータによって実施される方法が提供される。ヘッダクライアントの外部の少なくとも1つの外部ソースから複数のブロックヘッダを受信するステップ(210)であって、ブロックヘッダが、それぞれ、ブロックチェーンのブロックを参照する、ステップ(210)。受信された複数のブロックヘッダをストレージモジュールに記憶するステップ(220)。複数の受信されたヘッダに関するプルーフオブワークを確認することによって複数のブロックヘッダを分析するステップ(230)。分析された複数のブロックヘッダからブロックヘッダの最良のチェーンを決定し(240)、最良のチェーンをストレージモジュールに記憶するステップ。最良のチェーンは、ブロックチェーンの最初のブロックであるジェネシスから、ブロックチェーンの最新のブロックである現在の最良のブロックまでのブロックのチェーンであることが可能である。最良のブロックは、最も高い累積のプルーフオブワークを有する場合がある。

【特許請求の範囲】

【請求項1】

ヘッダクライアントにおいて実行されるコンピュータによって実施される方法であって、
前記ヘッダクライアントの外部の少なくとも1つの外部ソースから複数のブロックヘッダを受信するステップであって、前記ブロックヘッダが、それぞれ、ブロックチェーンのブロックを参照する、ステップと、
前記受信された複数のブロックヘッダをストレージモジュールに記憶するステップと、
前記受信された複数のブロックヘッダに関するプルーフオブワークを確認することによって前記複数のブロックヘッダを分析するステップと、
前記分析された複数のブロックヘッダからブロックヘッダの最良のチェーンを決定し、前記最良のチェーンを前記ストレージモジュールに記憶するステップと
を含む、コンピュータによって実施される方法。

【請求項2】

前記最良のチェーンが、ジェネシスから、最も高い累積のプルーフオブワークを有する前記ブロックチェーンの現在の最良のブロックまでのブロックのチェーンである請求項1に記載の方法。

【請求項3】

前記分析するステップが、
前記複数のブロックヘッダのうちのブロックヘッダの状態を決定することをさらに含み、前記状態を決定することが、前記ブロックヘッダが、
(i)前記最良のチェーン内、
(ii)孤児、
(iii)有効、
(iv)無効、
(v)争った、および/または
(vi)前記ブロックヘッダの状態が不明である場合
のうちの1つまたは複数であるかどうかを決定することを含む請求項1または請求項2に記載の方法。

【請求項4】

前記ブロックヘッダおよび/またはブロックヘッダの分岐の状態をマーキングし、前記状態を前記ストレージモジュールに記憶するステップをさらに含む請求項3に記載の方法。

【請求項5】

分析は、2つのブロックヘッダが前記ブロックチェーン内の同じ高さの2つの異なるブロックを参照することを明らかにし、前記方法が、
前記2つのブロックヘッダ内の前記プルーフオブワークを確認することによって、どちらのブロックヘッダが前記最良のチェーンの一部であるかを決定するステップと、
より高い難易度目標および最良のプルーフオブワークを有する、前記2つのブロックヘッダのうちの第1のブロックヘッダが最良のブロックであると決定するステップと、
前記最良のブロックを前記最良のチェーンに追加するステップと
をさらに含む請求項1から4のいずれか一項に記載の方法。

【請求項6】

前記2つのブロックヘッダのうちの第2のブロックが前記最良のチェーンの一部ではないと決定するステップをさらに含む請求項5に記載の方法。

【請求項7】

前記少なくとも1つの外部ソースが、ピアツーピアネットワーク内にある請求項1から6のいずれか一項に記載の方法。

【請求項8】

前記ピアツーピアネットワークから前記複数のブロックヘッダを調達することが、
前記ピアツーピアネットワークの第1のピアに第1のメッセージを送信することであって、前記第1のメッセージが、前記第1のピアにおいて利用可能な第1の複数のブロックヘッダがヘッダクライアントに送信される要求を含む、送信することと、
前記第1のメッセージに応答して、前記第1のピアに記憶された前記第1の複数のブロックヘッダを受信することと、
第1のノードが前記ピアツーピアネットワークにおいてインタラクションした1つまたは複数のその他のピアのアイデンティティの要求を含む第2のメッセージを前記第1のピアに送信することと、
前記第2のメッセージに応答して前記第1のピアによって送信された1つまたは複数のその他のピアのアイデンティティを受信することと、
1つまたは複数の受信されたアイデンティティに前記第1のメッセージを送信することと、
前記第1のメッセージに応答して前記1つまたは複数のその他のピアから第2の複数のブロックヘッダを受信することと
を含む請求項7に記載の方法。

【請求項9】

前記1つまたは複数の受信されたアイデンティティに前記第2のメッセージを送信するステップと、
前記ピアツーピアネットワークにおいて前記1つまたは複数のその他のピアがインタラクションしたさらなるピアのさらなるアイデンティティを受信するステップと、
複数のブロックヘッダが閾値の数のピアから受信されるまで、前記第1のメッセージおよび/または前記第2のメッセージを前記さらなるピアの前記さらなるアイデンティティに送信するステップと
をさらに含む請求項8に記載の方法。

【請求項10】

前記ストレージモジュールに記憶されたブロックヘッダの前記最良のチェーンまたはブロックヘッダの前記最良のチェーンへのポインタを出力するステップをさらに含む請求項1から9のいずれか一項に記載の方法。

【請求項11】

前記ストレージモジュールに記憶された特定のブロックヘッダまたは前記特定のブロックヘッダへのポインタを出力するステップをさらに含む請求項1から10のいずれか一項に記載の方法。

【請求項12】

出力が、特定のブロックの状態を含む請求項3に従属するときの請求項11に記載の方法。

【請求項13】

出力が、軽量クライアントからの要求に応答して出力される請求項10から12のいずれか一項に記載の方法。

【請求項14】

トランザクションに関連するブロックヘッダがブロックヘッダの前記最良のチェーン内にあると決定することによって、前記トランザクションが有効なトランザクションであることを検証するステップをさらに含む請求項1から13のいずれか一項に記載の方法。

【請求項15】

軽量クライアントにおいて前記トランザクションを検証するステップをさらに含む請求項14に記載の方法。

【請求項16】

ブロックヘッダを追跡するステップをさらに含む請求項1から15のいずれか一項に記載の方法。

【請求項17】

孤児であるヘッダを追跡するステップと、
前記最良のチェーンの一部でない孤児を刈り込む、および/または孤児を無効とマーキングするステップと
をさらに含む請求項16に記載の方法。

【請求項18】

前記少なくとも1つの外部ソースが、受信されたブロックヘッダの前記外部ソースに関連するURL、エンドポイントURL、前記ブロックヘッダによって参照されるブロックのマイナーID、コインベース、および/または包含証明のうちの1つまたは複数を含む追加情報を、前記ブロックヘッダに加えて、前記ヘッダクライアントに提供する請求項1から17のいずれか一項に記載の方法。

【請求項19】

特定の1人のマイナーもしくは複数のマイナーのリスクプロファイルを分析するステップ、1人もしくは複数のマイナーの評判を特定するステップ、および/またはどのマイナーが最も多くのブロックを生成するかを決定するステップのうちの1つまたは複数をさらに含む請求項18に記載の方法。

【請求項20】

請求項1から19のいずれか一項を実行するように構成されたヘッダクライアントであって、
インターフェースと、
前記インターフェースに結合されたプロセッサと、
前記プロセッサに結合されたメモリであって、実行されると、請求項1から19のいずれか一項に記載の方法を実行するように前記プロセッサを構成するコンピュータが実行可能な命令がインストールされた、メモリと
を含む、ヘッダクライアント。

【請求項21】

実行されると、請求項1から19のいずれか一項に記載の方法を実行するようにプロセッサを構成するコンピュータが実行可能な命令を記憶したコンピュータ可読ストレージ媒体。

【請求項22】

請求項20に記載のヘッダクライアントと、
前記ヘッダクライアントと通信する軽量クライアントと
を含むシステム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、ヘッダクライアントに関し、より詳細には、ブロックヘッダの最良のチェーンを決定するための方法およびシステムに関する。

【背景技術】

【0002】

ブロックチェーンは、分散型データ構造の形態を指し、分散型ピアツーピア(P2P)ネットワーク(以下、「ブロックチェーンネットワーク」と呼ばれる)の複数のノードの各々においてブロックチェーンの複製が維持され、広く公開される。ブロックチェーンは、データのブロックのチェーンを含み、各ブロックが、1つまたは複数のトランザクションを含む。いわゆる「コインベーストランザクション(coinbase transaction)」以外の各トランザクションは、1つまたは複数のコインベーストランザクションまで、1つまたは複数のブロックに及ぶ可能性があるシーケンス内の先行トランザクションを後ろ向きに指し示す。ブロックチェーンネットワークに提出されるトランザクションは、新しいブロックに含められる。新しいブロックは、多くの場合「マイニング」と呼ばれるプロセスによって作成され、マイニングは、複数のノードの各々が「プルーフオブワーク」、すなわち、ブロックチェーンの新しいブロックに含まれるのを待っている順序付けられた承認済みの保留トランザクションの定義されたセットの表現に基づく暗号パズルを解くことを競い合って実行することを含む。プルーフオブワークは、たとえば、ハッシュレートの形態で、特定の量のエネルギーが消費されることを必要とする。このエネルギーの不利益は、単一のエンティティがブロックチェーンを制御することを防止する。単一のエンティティがブロックチェーンを制御するためには、そのエンティティが、後続のブロックを一貫してマイニングするのに十分なハッシュレートを制御しなければならず、したがって、ブロックチェーンのそのエンティティのバージョンを正しいバージョンとして提示する。ブロックチェーンはノードにおいて刈り込まれる場合があり、ブロックの公開は単なるブロックヘッダの公開によって実現され得ることに留意されたい。

【0003】

暗号通貨の採用を広げるためには、暗号通貨の支払いは、不換通貨の支払いの機能の仕方と、特に、レジでの商品に対する通常の支払い方法により近い形で機能する必要がある。顧客は、オンラインでなくても自分の暗号通貨を使用することができる必要があり、トランザクションをブロードキャストするために商業者に負担をかける。これをするためには、小さい帯域幅の簡易支払い検証(SPV: Simplified Payment Verification)システムが好適なソリューションである。顧客は、含まれるブロックヘッダ、UTXO、入力トランザクション、およびマークルパス(Merkle path)によってトランザクションの支払いをする能力のみを有する、大部分の時間、オフラインであることが可能なウォレットを持つことになる。一方、商業者は、それらの支払いを受け取り、それらの支払いをブロックチェーンにブロードキャストする、中央ハブを有する、場所全体に分岐され得るシステムを持つことになる。

【先行技術文献】

【特許文献】

【0004】

【特許文献1】GB2002285.1

【特許文献2】米国特許出願第16/384696号

【特許文献3】GB2007597.4

【特許文献4】GB2102217.3

【特許文献5】GB1914043.3

【発明の概要】

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

【0005】

本発明の態様は、独立請求項に記載され、任意の特徴は、従属請求項に記載される。

【0006】

第1の態様によれば、ヘッダクライアントにおいて実行され、以下のステップを含むコンピュータによって実施される方法が提供される。ヘッダクライアントの外部の少なくとも1つの外部ソースから複数のブロックヘッダを受信するステップであって、ブロックヘッダが、それぞれ、ブロックチェーンのブロックを参照する、ステップ。受信された複数のブロックヘッダをストレージモジュールに記憶するステップ。複数の受信されたヘッダに関するプルーフオブワークを確認する(validate)ことによって複数のブロックヘッダを分析するステップ。分析された複数のブロックヘッダからブロックヘッダの最良のチェーンを決定し、最良のチェーンをストレージモジュールに記憶するステップ。最良のチェーンは、ジェネシスから現在の最良のブロックまでのブロックのチェーンであることが可能であり、現在の最良のブロックは、最も高い累積のプルーフオブワークを有する。

【0007】

第2の態様によれば、ヘッダクライアントが提供される。ヘッダクライアントは、インターフェースと、インターフェースに結合されたプロセッサと、プロセッサに結合されたメモリであって、実行されるときに、第1の態様の方法を実行するようにプロセッサを構成するコンピュータが実行可能な命令がインストールされた、メモリとを含む。

【0008】

第3の態様によれば、実行されるときに、第1の態様の方法を実行するようにプロセッサを構成するコンピュータが実行可能な命令を含むコンピュータ可読ストレージ媒体が存在する。

【0009】

第4の態様によれば、ヘッダクライアントと、ヘッダクライアントと通信する軽量クライアントとを含むシステムが提供される。

【0010】

本明細書全体を通じて、単語「～を含む(comprise)」、または「～を含む(includes)」、「～を含む(comprises)」、もしくは「～を含んでいる(comprising)」などの変化形は、記載の要素、完全体(integer)もしくはステップ、または要素、完全体、もしくはステップのグループの包含を示唆するが、いかなるその他の要素、完全体もしくはステップ、または要素、完全体、もしくはステップのグループの除外も示唆しないと理解される。

【0011】

本開示の態様および実施形態が、単に例として、添付の図面を参照して以降で説明される。

【図面の簡単な説明】

【0012】

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

【図2】ヘッダクライアントにおいてブロックヘッダの最良のチェーンを決定するための方法を示す図である。

【図3】ヘッダクライアントにおいて複数の外部ソースからブロックヘッダを調達することを示す図である。

【図4A】ここで開示されている方式の実施形態を実施するためのクライアントアプリケーションの例示的な実装を示す図である。

【図4B】軽量クライアント機器のクライアントアプリケーションのユーザインターフェースレイヤによってレンダリングされる場合があるユーザインターフェースの例のモックアップを示す図である。

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

【0013】

ブロックヘッダの最良のチェーンを提供するシステムを、本明細書において提示する。これは、軽量クライアントと連携して働くことができる、本明細書においてヘッダクライアントと呼ばれる中間ピアによって達成される。ヘッダクライアントは、ブロックチェーンのブロックに対応する1つまたは複数のブロックヘッダによって提供される情報を通じてブロックヘッダの最良のチェーンを決定する。本明細書において説明されるヘッダクライアントによって提供する利点は、少ない動作帯域幅、安価なストレージおよび処理、ならびに低いランニングコストおよびストレージコストである。

【0014】

本明細書において開示される態様および実施形態は、ブロックヘッダの最良のチェーンのビュー(view)を軽量クライアントシステムに提供することができ、このビューは、トランザクションの検証のためなど、軽量クライアントのアプリケーションに有用であり得る。

【0015】

ピアツーピアネットワークのノードがブロックチェーンの有効なバージョンとして受け入れるブロックのチェーンは、多くの場合、「最良の」または「最長の」チェーンと呼ばれる。ブロックチェーンに新しいブロックを追加するためには、処理能力が必要とされ、ブロックチェーンのあらゆるブロックはそこに到達するまでにエネルギーを使い果たす。より多くのブロックを含むブロックチェーン、「最長のチェーン」は、概して、より少ないブロックを含むチェーンよりも構築するのにより多くのエネルギーを要しているはずであり、原則として、ノードは、「より短い」チェーンよりもこのチェーンを採用する。より厳密には、最も多い作業量を含むチェーンを「最良のチェーン」と呼ぶ。ほとんどの場合、ブロックの最も長いチェーンが、有効なブロックの最良のチェーンでもある。しかし、これは、たとえば、より短いチェーンがより長いチェーンよりも多くの作業量を有する場合、必ずしも当てはまらない場合があることは理解されるであろう。ネットワークのすべてのノードがブロックの最良のチェーンを採用するという規則は、ネットワークのあらゆるノードがブロックチェーンがどのように見えるかについて合意し、したがって、同じ取引履歴について合意することを可能にする。これは、ネットワーク上で独立して働くコンピュータがブロックチェーンのグローバルに共有されたビューを維持することができることを意味する。ヘッダクライアントは、ヘッダクライアントに提供されたブロックヘッダを用いて、ブロックヘッダの最良のチェーンとも呼ばれる最良のチェーンを提供することができる。以降、単に説明を簡単にするために、最良のチェーンおよび最長のチェーンという用語は、本明細書においては交換可能であるように用いられる。

【0016】

本開示の第1の態様によれば、ヘッダクライアントにおいて実行され、以下のステップを含むコンピュータによって実施される方法が提供される。ヘッダのクライアントの外部の少なくとも1つの外部ソースから複数のブロックヘッダを受信するステップであって、ブロックヘッダが、それぞれ、ブロックチェーンのブロックを参照する、ステップ。受信された複数のブロックヘッダをストレージモジュールに記憶するステップ。複数の受信されたヘッダに関するプルーフオブワークを確認することによって複数のブロックヘッダを分析するステップ。分析された複数のブロックヘッダからブロックヘッダの最良のチェーンを決定し、最良のチェーンをストレージモジュールに記憶するステップ。

【0017】

最良のチェーンは、ブロックチェーンの最初のブロックであるジェネシスから、ブロックチェーンの最新のブロックである現在の最良のブロックまでのブロックのチェーンであることが可能である。最良のブロックは、ブロックチェーンのその特定の分岐を維持することにネットワークによって費やされた最も多いエネルギーと説明され得る最も高い累積のプルーフオブワークを有する場合がある。

【0018】

一部の例において、複数のブロックヘッダは、外部ソースに記憶されたすべての(すなわち、ジェネシスから現在の最良のブロックまでの)ブロックヘッダを含む。

【0019】

ヘッダクライアントを用いる利点は、ブロックヘッダがトランザクション情報を含まないために軽量であることである。ビットコインの軽量クライアントは、概して、ブロックチェーンの完全な複製を所有しておらず、したがって、「フル(full)」または「マイナー(miner)」ノードに比べて、実行するコストがはるかに安く、はるかに小さい帯域幅を必要とする。軽量クライアントは、たとえば、ブロックヘッダの最良のチェーンに関する、ヘッダクライアントによってその軽量クライアントに提供されるデータに依拠することができる。したがって、さらなる利点は、軽量クライアントが、各ブロックに入るデータおよびトランザクションの量にまったく影響されることなく、自身のデータ/トランザクションの量に合わせてスケーリングすることを可能にすることである場合がある。

【0020】

ヘッダクライアントは、軽量クライアントが容易にアクセス可能であり得る、およびブロックチェーンが拡張されるにつれて更新されることも可能であるブロックヘッダの最良のチェーンを決定することができる。ブロックヘッダは特にブロックチェーン自体のブロックに比べてデータ量が多くないので、ストレージモジュールのストレージ空間が、ブロックチェーンの「フル」ノードに比べて削減される場合がある。したがって、ヘッダクライアントにおいて実行される処理は、フルノードに比べて高速になり得る。より低いストレージ空間の要件に加えて、ヘッダクライアントを動作させるために必要とされる計算能力も、フルノードに比べて低い場合があり、ヘッダクライアントは、フルノードよりも実行および維持するコストが安くなり得る。たとえば、ヘッダクライアントは、Raspberry Piのようなシングルボードコンピューティングデバイス上で実行されてよい。

【0021】

ヘッダクライアントにおいて決定されたブロックヘッダの最良のチェーンは、たとえば、ブロックチェーンネットワークの一部であるノードとインタラクションする代わりに、ヘッダクライアントと「オフチェーン」でインタラクションすることができることが有利である軽量クライアントに利点を提供する可能性がある。

【0022】

任意で、複数のブロックヘッダを分析するステップは、複数のブロックヘッダのうちのブロックヘッダの状態を決定することをさらに含んでよい。状態を決定することは、ブロックヘッダが
(i)最良のチェーン内、
(ii)孤児(orphan)、
(iii)有効、
(iv)無効、
(v)争った(contended)、および/または
(vi)ブロックヘッダの状態が不明である場合
のうちの1つまたは複数であるかどうかを決定することを含んでよい。

【0023】

ブロックの状態を知ることは、たとえば、トランザクションの検証において有利であり得る。ブロックヘッダが最良のチェーン内にある場合、ブロックヘッダの状態は、トランザクションの検証の際に軽量クライアントに有用である可能性がある。その他の状況において、ブロックヘッダは、最良のチェーン内にないことが知られている場合があり、したがって、(今までのところ)検証されていないトランザクションに対応する場合がある。さらなる状況においては、たとえば、ブロックヘッダが孤児または争ったブロックである場合、ブロックヘッダがブロックヘッダの最良のチェーン内にあるか否かがわからない場合がある。ブロックヘッダが孤児である場合、場合によっては、ブロックヘッダは、後でブロックヘッダの最良のチェーンの一部になる可能性があり、その他の場合、ブロックヘッダは、そうならない可能性がある。争ったブロックは、有効だがまだ孤児にされていないブロックを指し得る。ブロックヘッダが無効である場合、ブロックヘッダは、最良のチェーンの一部である可能性は低い。無効なブロックは、プロトコルに違反するブロック、たとえば、ブロックチェーンがビットコインブロックチェーンである場合、BSVブロックチェーンのフォーク(fork)内のBTCブロックまたはBCHブロックへの参照を含む場合がある。

【0024】

任意で、方法は、1つもしくは複数のブロックヘッダおよび/またはブロックヘッダの分岐の状態をマーキングし、状態をストレージモジュールに記憶するステップをさらに含んでよい。

【0025】

ブロックヘッダの状態を記憶することは、たとえば、軽量クライアントから問い合わされたときのその状態へのアクセスを向上させ得る。さらに、ヘッダクライアントは、ブロックヘッダの状態を決定するためにそのヘッダクライアントが既に行ったすべての作業をやり直すことを防止され得る。一部の例において、状態は、それが変化する場合、たとえば、争ったブロックが孤児になるときに更新され得る。

【0026】

状況によっては、2つのブロックヘッダが、ブロックチェーン内の同じ位置、たとえば、同じ高さの2つのブロックに関連し得る。任意で、分析が2つのブロックヘッダがブロックチェーン内の同じ高さの2つの異なるブロックを参照することを明らかにする場合、方法は、以下のステップをさらに含んでよい。2つのブロックヘッダ内のプルーフオブワークを確認することによって、どちらのブロックヘッダが最良のチェーンの一部であるかを決定するステップ。好ましくは、方法は、より高い難易度目標(difficulty target)および最良のプルーフオブワークを有する、2つのブロックヘッダのうちの第1のブロックヘッダが最良のブロックであると決定するステップと、好ましくは、決定された最良のブロックを最良のチェーンに追加するステップとをさらに含んでよい。一部の例において、方法は、ブロックヘッダの難易度目標を比較し、検証するステップをさらに含んでよい。

【0027】

状況によっては、2つのノードが同時に解を見つけ、2つの可能な次のブロックが同時に作成されるフォークが現れる。有利なことに、プルーフオブワークを比較することは、どのブロックがブロックヘッダの最良のチェーンの一部であるかを決定する。

【0028】

任意で、方法は、2つのブロックヘッダのうちの第2のブロックがブロックヘッダの最良のチェーンの一部ではないと決定するステップであって、たとえば、第2のブロックが、第1のブロックと比較してより低い難易度目標および/またはプルーフオブワークを有する、ステップをさらに含んでよい。第2のブロックヘッダの状態は、任意で、たとえば、孤児/無効なブロックとして記録され得る。検証されていない難易度目標を持つブロックは、任意で、状態「invalid」によってマーキングされ得る。

【0029】

一部の例において、少なくとも1つの外部ソースは、ピアツーピアネットワーク内にある。任意で、ピアツーピアネットワークは、ビットコインネットワークであってよい。ブロックヘッダは、ネットワークのノード、別のヘッダクライアント、または軽量クライアントから調達される場合がある。一部の例において、ブロックヘッダは、基本的なテキストファイルでヘッダクライアントに提供される可能性がある。ブロックヘッダは、サーバからダウンロードされるか、あるいはリムーバブルSSD、フラッシュメモリキー、リムーバブルEEPROM、リムーバブル磁気ディスクドライブ、磁気フロッピーディスクもしくはテープ、CDもしくはDVD ROMなどの光ディスク、またはリムーバブル光学ドライブなどのリムーバブルストレージデバイス上で提供される可能性がある。その他の例においては、nChain Holdings Limitedの名義で2019年9月30日に出願されたGB1914043.3に記載されている、商業者API(merchant API)またはM-APIとも呼ばれるAPIベースのサービスなどの機能も、ブロックヘッダを調達するために用いられてよい。これは、ヘッダクライアントが商業者APIにブロックヘッダ情報を要求することを含み、そして、商業者APIが、様々な異なるマイナーからブロックヘッダ情報を取得する。このシナリオにおいて、ヘッダクライアントは、中央ゲートウェイを通じて、複数の異なるマイナーに一度に問い合わせる可能性がある。

【0030】

ピアツーピアネットワークからブロックヘッダを調達する利点は、ブロックヘッダがネットワーク自体の複数のノードから入手されることが可能であり、これがヘッダクライアントに最新の情報を提供するのに役立つ可能性があることである。

【0031】

任意で、ピアツーピアネットワークから複数のブロックヘッダを調達することは、以下のステップを含んでよい。ピアツーピアネットワークの第1のピアに第1のメッセージを送信することであって、第1のメッセージが、第1のピアにおいて利用可能な第1の複数のブロックヘッダがヘッダクライアントに送信される要求を含む、送信すること。メッセージに応答して、第1のピアに記憶された第1の複数のブロックヘッダを受信すること。さらに、任意で、第1のノードがピアツーピアネットワークにおいてインタラクションした1つまたは複数のその他のピアのアイデンティティ(identity)の要求を含む第2のメッセージを第1のピアに送信することと、第2のメッセージに応答して第1のピアによって送信された1つまたは複数のその他のピアのアイデンティティを受信することとを含む。それから、1つまたは複数の受信されたアイデンティティに第1のメッセージを送信すること、ならびに第1のメッセージに応答して1つまたは複数のその他のピアから第2のおよび/またはさらなる複数のブロックヘッダを受信すること。外部ソースの各々から受信された第1の複数のブロックヘッダおよび/または第2の複数のブロックヘッダは、各外部ソースにそれぞれ記憶されたブロックヘッダのすべてに対応する場合がある。第1のピアによって提供されるアイデンティティは、ヘッダクライアントがピアツーピアネットワーク上の外部ソースとインタラクションすることができるような、外部ソースについての十分な情報、たとえば、外部ソースのIPアドレスをヘッダクライアントに提供してよい。

【0032】

任意で、ブロックヘッダを調達することは、ピアツーピアネットワーク内の1つまたは複数の受信されたアイデンティティに第2のメッセージを送信することと、ピアツーピアネットワークにおいて1つまたは複数のその他のピアがインタラクションしたさらなるピアのさらなるアイデンティティを受信することと、複数のブロックヘッダが閾値の数のピアから受信されるまで、第1のメッセージおよび/または第2のメッセージをさらなるアイデンティティに送信することとをさらに含んでよい。

【0033】

外部ソースからブロックヘッダを調達することは、ピアツーピアネットワークの複数のノードからブロックヘッダを調達することを含んでよい。ネットワークの複数のノードからブロックヘッダを調達することは、下でより詳細に説明されるエクリプス攻撃(eclipse attack)を防止するために有益であり得る。エクリプス攻撃を防止するためのノードの例示的な最小の数は、互いに厳密に独立している2つのノードである場合がある。3つ以上のノードからブロックヘッダを受信することは、さらに有利であることが可能であり、依然として実行するコストが非常に安く、実行が迅速であることが可能である。

【0034】

一部の例において、ヘッダクライアントは、情報を出力してよい。これは、ストレージモジュールに記憶されたブロックヘッダの最良のチェーンまたはブロックヘッダの最良のチェーンへのポインタを、たとえば、ヘッダクライアントから軽量クライアントに出力することを含む可能性がある。

【0035】

たとえば、軽量クライアントにおけるトランザクションの検証の際に、ブロックヘッダの最良のチェーンまたは最良のチェーンへのポインタを出力することは、有利であり得る。トランザクションは、それがブロックヘッダの最良のチェーン内のブロックヘッダに対応する場合、検証されると決定され、そうでない場合、検証されないと決定される場合がある。

【0036】

一部の例においては、ストレージモジュールに記憶された特定のブロックヘッダまたは特定のブロックヘッダへのポインタが、出力され得る。任意で、出力は、特定のブロックの状態を含む場合がある。

【0037】

軽量クライアントは、自身の活動に関連する特定のトランザクションに関心がある場合があり、場合によっては、ブロックヘッダの最良のチェーン全体ではなく、ブロックヘッダまたはブロックヘッダへのポインタを出力することが、より効率的である場合がある。

【0038】

一部の例において、出力は、軽量クライアントからの要求に応答して出力されることが可能であり、たとえば、軽量クライアントは、特定のブロックに関する特定の要求をヘッダクライアントに行ってよい。これは、たとえば、軽量クライアントにおいて実行されるアプリケーションを通じて実行されてよい。

【0039】

任意で、方法は、ブロックヘッダの最良のチェーンを用いる、トランザクションを検証するためのステップをさらに含む。たとえば、トランザクションに関連するブロックヘッダがブロックヘッダの最良のチェーン内にあると決定することによって、トランザクションが有効なトランザクションであることを検証するステップを含む。

【0040】

任意で、軽量クライアントにおいてトランザクションを検証するステップ。軽量クライアントは、概して、自身のトランザクションを検証することに関心を持ち得る。軽量クライアントは、自身のトランザクションに関連するブロックヘッダが最良のチェーン内に存在すると決定することによってこれを達成することができる。

【0041】

任意で、ブロックヘッダが追跡されてよく、追跡することは、ブロックチェーンの現在の最良のブロックを監視することを可能にする。ブロックヘッダを追跡することは、ブロックヘッダの最良のチェーンの最新バージョンおよびブロックヘッダの正確な状態を維持するのを助ける際に有利であり得る。ブロックヘッダは、ブロックチェーンネットワークへの接続を通じて、ローテーション式に前記ネットワークからブロックヘッダを受信することによって追跡され得る。

【0042】

一部の例において、ブロックヘッダを追跡することは、孤児であるブロックヘッダを追跡することをさらに含む。方法は、最良のチェーンの一部でない孤児を刈り込む、および/または孤児を無効とマーキングするステップをさらに含んでよい。孤児を追跡することは、最良のチェーンの現在の最良のブロックを決定する際に有利であり得る。

【0043】

任意で、少なくとも1つの外部ソースは、受信されたブロックヘッダの外部ソースに関連するURL、エンドポイントURL、ブロックヘッダによって参照されるブロックのマイナーID、コインベース、および/または包含証明(inclusion proof)のうちの1つまたは複数を含む追加情報を、ブロックヘッダに加えて、ヘッダクライアントに提供してよい。

【0044】

MinerReputationは、マイナーのパフォーマンス、すなわち、マイナーが約束されたまたは見積もられた現在の手数料でトランザクションをいかに良く実行するかの尺度に関する。評判スコア/インジケータは、各支払いプロセッサによって計算され、維持され、管理されてよい。

【0045】

マイナーIDは、ブロックがマイニングされるときにコインベーストランザクションに追加される2つの部分からなるデータである場合がある。マイナーIDが存在しない場合、支払いプロセッサは、そのマイナーを「NULL」のまたは単に空白のままにされたマイナーIDによってタグ付けする場合がある。

【0046】

任意で、追加情報を用いて、方法は、特定の1人のマイナーもしくは複数のマイナーのリスクプロファイル(risk profile)を分析するステップ、1人もしくは複数のマイナーの評判を特定するステップ、および/またはどのマイナーが最も多くのブロックを生成するかを決定するステップのうちの1つまたは複数をさらに含んでよい。ブロックヘッダを介してヘッダクライアントに提供されたデータから、さらなる統計情報が決定される可能性がある。経時的なハッシュパワーのシェア、またはネットワーク内の孤児の数など。

【0047】

例示的なシステムの概要
図1は、ブロックチェーン150を実装するための例示的なシステム100を示す。システム100は、パケット交換ネットワーク101、典型的には、インターネットなどの広域インターネットワークで構成されてよい。パケット交換ネットワーク101は、パケット交換ネットワーク101内でピアツーピア(P2P)ネットワーク106を形成するように配置される場合がある複数のブロックチェーンノード104を含む。図示されていないが、ブロックチェーンノード104は、ほぼ完全なグラフ(near-complete graph)として配置される場合がある。したがって、各ブロックチェーンノード104は、その他のブロックチェーンノード104と緊密に接続される。

【0048】

ブロックチェーンノード104は、ブロックチェーンノードプロトコルに従ってトランザクション152を承認し、ブロックチェーンネットワーク106全体にトランザクション152を伝播させるためにトランザクション152を転送するように構成されたソフトウェアを実行する。

【0049】

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

【0050】

ブロックチェーン150は、データのブロック151のチェーンを含み、ブロックチェーン150のそれぞれのコピーが、分散型またはブロックチェーンネットワーク106の複数のブロックチェーンノード104の各々において維持される。ブロックチェーン150のコピーを維持することは、必ずしもブロックチェーン150をすべて記憶することを意味しない。その代わりに、たとえば、ヘッダクライアント102aまたは軽量クライアント102bにおいて、ブロックチェーン150は、各ブロック151のブロックヘッダ156などの、ブロックに関連する限られた情報を記憶してよい。チェーンの各ブロック151は、1つまたは複数のトランザクション152を含み、この文脈におけるトランザクションは、データ構造の一種を指す。

【0051】

各ブロック151は、ブロック151までの連続的な順序を定義するように、チェーン内の前に作成されたブロック151を後ろ向きに指し示すブロックポインタ155も含む。ブロックヘッダ156を受信するヘッダクライアントは、ポインタを用いてブロックヘッダ156を順々に配列して、それらのブロックヘッダ156を連続的な順序に順序付けることによってブロックチェーンのバージョンを効果的に構築することができる。(コインベーストランザクション以外)各トランザクション152は、トランザクションのシーケンスに順序を定義するように、前のトランザクションに戻るポインタを含む(トランザクション152のシーケンスは分岐することを許されることに注意されたい)。ブロック151のチェーンは、チェーンの最初のブロックであったジェネシスブロック(Gb)153までさかのぼる。チェーン150の初期の1つまたは複数の当初のトランザクション152は、先行トランザクションではなくジェネシスブロック153を指し示していた。

【0052】

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

【0053】

所与の現在のトランザクション152jにおいて、その(または各)入力は、トランザクションのシーケンス内の先行トランザクション152iの出力を参照するポインタを含み、この出力が現在のトランザクション152jにおいて履行されるまたは「消費される」ことを指定する。概して、先行トランザクションは、順序付けられたセット154または任意のブロック151内の任意のトランザクションである可能性がある。先行トランザクション152iは、現在のトランザクション152jが作成される時点、またはネットワーク106に送信される時点でさえも必ずしも存在する必要はないが、現在のトランザクションが有効であるためには、先行トランザクション152iが存在し、承認される必要がある。したがって、本明細書における「先行」は、ポインタによってリンクされた論理的なシーケンスにおける先任者(predecessor)を指し、必ずしも時間的なシーケンスにおける作成または送信の時間を指すものではなく、したがって、トランザクション152i、152jが順不同で作成または送信されることを必ずしも除外しない。先行トランザクション152iは、同様に先祖(antecedent)または先任者トランザクションと呼ばれる可能性がある。その他の適格なブロックと比較して、ブロックチェーンへの当該ブロックの受け入れの際のタイムラグが原因でブロックチェーンネットワークに受け入れられないブロックである孤児ブロックが存在する場合がある。

【0054】

ブロックチェーンノード104は、トランザクションを承認し、さらに、「プルーフオブワーク」によってサポートされる、通常、マイニングと呼ばれるプロセスでトランザクションのブロックを最初に作成するノードになろうと競争する。ブロックチェーンノード104において、新しいトランザクションは、ブロックチェーン150に記録されたブロック151にまだ現れていない有効なトランザクションの順序付けられたセット154に追加される。それから、ブロックチェーンノードは、暗号パズルを解くことを試みることによって、トランザクションの順序付けられたセット154からトランザクション152の新しい有効なブロック151を組み立てようと競争する。概して、これは、ナンスがトランザクションの順序付けられたセット154の表現と連結され、ハッシュされるときに、ハッシュの出力が所定の条件を満たすような「ナンス」値を探索することを含む。たとえば、所定の条件は、ハッシュの出力が特定の予め定義された数の先頭のゼロを有することである場合がある。これは、プルーフオブワークのパズルの単なる1つの特定の種類であり、その他のパズルは除外されないことに留意されたい。ハッシュ関数の特性は、ハッシュ関数がその入力に対して予測不可能な出力を有することである。したがって、この探索は、総当たりによってのみ実行されることが可能であり、したがって、パズルを解こうとしている各ブロックチェーンノード104において相当大量の処理リソースを消費する。

【0055】

パズルを解いた最初のブロックチェーンノード104は、これをネットワーク106に告知し、ネットワークのその他のブロックチェーンノード104によってその後容易にチェックされ得る証明として解を提供する(ハッシュの解が与えられると、それがハッシュの出力に条件を満足させることをチェックすることは簡単である)。最初のブロックチェーンノード104は、ブロックを受け入れ、したがって、プロトコルの規則を施行するその他のノードの閾値のコンセンサスまでブロックを伝播する。そして、トランザクションの順序付けられたセット154は、ブロックチェーンノード104の各々によってブロックチェーン150に新しいブロック151として記録されるようになる。新しいブロック151のブロックヘッダ156は、バージョン、前のブロックのハッシュ、マークルルート、タイムスタンプ、難易度目標、およびナンスを含む情報を記録する。また、チェーン内の前に作成されたブロック151n-1を後ろ向きに指し示すブロックポインタ155が、新しいブロック151nに割り振られる。プルーフオブワークの解を作成するために必要とされる、たとえば、ハッシュの形態の著しい量の労力は、ブロックチェーンプロトコルの規則に従うという最初のノード104の意図を知らせる。そのような規則は、二重支払いとしても知られている、トランザクションが前に承認されたトランザクションと同じ出力を割り振る場合、トランザクションを有効であるものとして受け入れないことを含む。作成されると、ブロック151は、ブロックチェーンネットワーク106のブロックチェーンノード104の各々において認識され、維持されるので、修正され得ない。各ブロックチェーンノード104において維持されるブロックチェーンのバージョンは、問い合わせられたとき、ブロックヘッダの形態でヘッダクライアントに送信され得る。また、ブロックポインタ155は、ブロック151に連続的な順序を付与する。トランザクション152がネットワーク106の各ブロックチェーンノード104の順序付けられたブロックに記録されるので、これは、したがって、トランザクションの不変の公開台帳を提供する。

【0056】

任意の所与の時間にパズルを解こうと競争している異なるブロックチェーンノード104は、それらのブロックチェーンノード104がいつ解を探索し始めたか、またはトランザクションが受信された順序に応じて、任意の所与の時間にまだ公開されていないトランザクションの順序付けられたセット154の異なるスナップショットに基づいてそうしている場合があり、したがって、ネットワーク106のいくつかの異なるノード104からヘッダクライアント102aによって受信されたブロックヘッダ156は、検証されたトランザクションを含む場合があり、もしくは含まない場合があり、および/または様々な順序のブロックヘッダ156を含む場合があることに留意されたい。最良のチェーンを決定するためには、したがって、複数のブロックチェーンノード104からブロックヘッダを受信することが好ましくなり得る。

【0057】

ブロックチェーンネットワークのフルブロックチェーンノード104は、ノードのハッシュの解を確認し、提案されたブロックが、上述のように、ほとんどの場合、最長のチェーンでもある場合がある有効なプルーフオブワークの最良のチェーンの最上部のリンクとしてその場所を確保するために必要とされるさらなるチェックを保証するかどうかを決定することができる。ブロックヘッダは、ネットワーク全体に伝播される。それらのブロックヘッダの一部は、(まだ)最良のチェーンの一部ではない場合があるブロックを参照する。

【0058】

トランザクションの承認および公開に関わるリソースが原因で、概して、少なくとも、ブロックチェーンノード104の各々は、1つもしくは複数の物理サーバユニットを含むサーバ、またはさらにはデータセンター全体の形態をとる。しかし、原理的には、任意の所与のブロックチェーンノード104は、ユーザ端末、または一緒にネットワーク化されたユーザ端末のグループの形態をとる可能性がある。

【0059】

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

【0060】

ネットワーク101にさらに接続されるのは、消費ユーザの役割の複数の関係者103の各々のコンピュータ機器102、たとえば、ヘッダクライアント103aおよび軽量クライアント103bである。これらのユーザは、ブロックチェーンネットワークとインタラクションする場合があるが、トランザクションおよびブロックの構築または伝播には参加しない。これらのユーザまたはエージェント103の一部は、トランザクションにおいて送信者および受信者として働く場合があるが、必ずしも送信者または受信者として働くことなく、ブロックチェーン150とインタラクションしてよい。たとえば、一部の関係者は、(たとえば、ブロックチェーンノード104からブロックチェーンのコピーを取得した)ブロックチェーン150のコピーを記憶するストレージエンティティとして働く場合がある。

【0061】

関係者103の一部またはすべては、異なるネットワーク、たとえば、ブロックチェーンネットワーク106の上に重ねられたネットワークの一部として接続される場合がある。ブロックチェーンネットワークのユーザ(多くの場合「クライアント」と呼ばれ、ヘッダクライアントおよび軽量クライアントを含む)は、ブロックチェーンネットワークを含むシステムの一部であると言われる場合があるが、これらのユーザは、ブロックチェーンノードの必要とされる役割を果たさないので、ブロックチェーンノード104ではない。その代わりに、各関係者103は、ブロックチェーンネットワーク106とインタラクションし、それによって、ブロックチェーンネットワーク106の1つまたは複数のブロックチェーンノード104に接続すること(すなわち、通信すること)によりブロックチェーン150を利用してよい。例示を目的として、2つのそのようなクライアント103およびそれらのそれぞれの機器102、すなわち、ヘッダクライアント103aおよびそれぞれのコンピュータ機器102a、ならびに軽量クライアント103bおよびそれぞれのコンピュータ機器102bが示される。多くのさらなるそのような関係者103およびそれらのそれぞれのコンピュータ機器102が存在し、システム100に参加していてよいが、便宜上、それらは図示されていないことは理解されるであろう。クライアント103a、103bは、例示を目的として別々のエンティティとして示されており、一部の例において、ヘッダクライアント103aおよび軽量クライアント103bは、同じコンピュータ機器102a/b上で実行されてもよいことも理解されるであろう。その他の例においては、1つのヘッダクライアント103aが複数の軽量クライアント103bとインタラクションする場合があり、および/または軽量クライアント103bがいくつかのヘッダクライアント103aとインタラクションする場合がある。各関係者103は、個人または組織である場合がある。

【0062】

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

【0063】

ヘッダクライアント102aおよび軽量クライアント102bは、全取引履歴を含むフルブロックチェーンを記憶する能力を持たず、スペースおよび電力に制約のあるデバイスで実行されるように設計されている。しかし、一部の例においては、ブロックヘッダおよび/またはブロックヘッダの最良のチェーンのローカルコピーが、ローカルストレージモジュールに記憶される場合がある。

【0064】

ヘッダおよび軽量クライアントデバイスは、たとえば、コンピュータ機器102、スマートフォン、タブレット、または他の組み込みシステムを含む場合がある。一部の例において、クライアント103は、所与のブロックヘッダの状態を問い合わせるためのAPIを提供する、たとえば、linuxおよびWindows上のサーバサイドソフトウェアとして展開され得る。

【0065】

図1に示されたように、各コンピュータ機器102a、102bのクライアントアプリケーションは、それぞれ、追加の通信機能を含む場合がある。この追加の機能は、ヘッダクライアント103aが、(どちらかの関係者または第三者の勧めによって)軽量クライアント103bとの別個のサイドチャネル301を確立することを可能にする。サイドチャネル301は、ブロックチェーンネットワークとは別にデータのやりとりを可能にする。そのような通信は、「オフチェーン」通信と呼ばれることがある。たとえば、これは、ヘッダクライアント103aにおいて維持される鍵、ネゴシエーションされた金額もしくは条項、データコンテンツ、ブロックヘッダ、または最良のチェーンのブロックのステータスなどの任意のトランザクション関連データをやりとりするために、ヘッダクライアント103aと軽量クライアント103bとの間でトランザクションデータ152をやりとりするために用いられてよい。

【0066】

サイドチャネル301は、ブロックチェーンネットワーク106と同じパケット交換ネットワーク101を介して確立されてよい。代替的または追加的に、サイドチャネル301は、モバイルセルラネットワーク、またはローカルワイヤレスネットワークなどのローカルエリアネットワーク、またはさらにはデバイス102a、102bの間の直接有線もしくはワイヤレスリンクなどの異なるネットワークを介して確立されてよい。概して、本明細書のどこで言及されるサイドチャネル301も、「オフチェーン」、すなわち、ブロックチェーンネットワーク106とは別でデータをやりとりするための1つまたは複数のネットワーキングテクノロジーまたは通信媒体を介した任意の1つまたは複数のリンクを含んでよい。2つ以上のリンクが用いられる場合、オフチェーンリンクの束または集合が全体としてサイドチャネル301と呼ばれる場合がある。したがって、ヘッダクライアント103aおよび軽量クライアント103bがサイドチャネル301を介して特定の情報またはデータなどをやりとりすると言われる場合、これは、これらのデータすべてがまったく同じリンクまたはさらには同じ種類のネットワーク上で送信されなければならないことを必ずしも示唆しないことに留意されたい。

【0067】

各コンピュータ機器102上のクライアントアプリケーションまたはソフトウェア105のインスタンスは、任意で、ネットワーク106のブロックチェーンノード104のうちの少なくとも1つに動作可能なように結合される。これは、クライアント105がネットワーク106からブロックヘッダ、または適切な場合にはフルブロックを受信することを可能にする。また、クライアント105は、それぞれの関係者103が受信者である任意のトランザクションに関してブロックチェーン150に問い合わせる(または実施形態において、ブロックチェーン150は、その公開された可視性(public visibility)によって部分的にトランザクションに対する信頼を提供する公共機関(public facility)であるので、ブロックチェーン150内のその他の関係者のトランザクションを確かに検査する)ためにブロックチェーンノード104に連絡することができる。コンピュータ機器102bのウォレット機能は、トランザクションプロトコルに従ってトランザクション152を組み立て、送信するように構成される。

【0068】

一部の例において、ヘッダクライアント102aおよび/または軽量クライアント102bは、仲介プラットフォームまたはサービスを介してブロックチェーン150とインタラクションする場合がある。一例において、2020年2月19日に出願されたGB2002285.1に記載されているプラットフォームプロセッサ。プラットフォームプロセッサは、ヘッダクライアント102および/または軽量クライアント102bとブロックチェーン150との間の通信を中継する責任を担ってよい。別の例においては、nChain Holdings Limitedの名義で2019年4月15日に出願された米国特許出願第16/384696号に記載されているようなエイリアスベースのアドレス指定サービスが、ブロックチェーン150とのインタラクションのために用いられることも可能である。別の例においては、nChain Holdings Limitedの名義で2020年5月21日に出願されたGB2007597.4に記載されているような、ブロックチェーントランザクションに関連するデータまたは情報の転送のためにエンティティまたはエンドユーザ間の直接またはピアツーピアの安全な通信を可能にするためのチャネルサービスが、ヘッダクライアント102aまたは軽量クライアント102bによって用いられてもよい。別の例においては、2019年9月30日に出願されたGB1914043.3に記載されているような、クライアントまたは商業者エンティティ間の支払いまたはその他のトランザクションのための、商業者APIまたはM-APIとも呼ばれるAPIベースの支払いサービスなどの機能が用いられてもよい。上で参照された出願のすべては、nChain Holdings Limitedの名義で出願された。

【0069】

ネットワークトランザクション
ブロックチェーンにおけるトランザクションは、以下、すなわち、デジタル資産(すなわち、多数のデジタルトークン)の伝達、仮想台帳またはレジストリのジャーナルエントリ(journal entry)のセットの順序付け、タイムスタンプエントリの受信および処理、ならびに/またはインデックスポインタの時間順序付け(time-order)のうちの1つまたは複数を実行するために用いられる。

【0070】

ブロックチェーンネットワークのノード(多くの場合「マイナー」と呼ばれる)は、分散型トランザクション登録および検証プロセスを実行する。要約すると、このプロセス中に、ノードは、トランザクションを承認し、それらが有効なプルーフオブワークの解を特定しようとするブロックテンプレートにトランザクションを挿入する。有効な解が見つかると、新しいブロックが、ネットワークのその他のノードに伝播され、したがって、各ノードがブロックチェーンに新しいブロックを記録することを可能にする。ブロックチェーンにトランザクションを記録させるために、ユーザ(たとえば、軽量クライアント103aなどのブロックチェーンクライアントアプリケーション)は、伝播されるようにネットワークのノードのうちの1つにトランザクションを送信する。トランザクションを受信するノードは、承認されたトランザクションを新しいブロックに組み込むプルーフオブワークの解を見つけるために競争してよい。各ノードは、トランザクションが有効であるための1つまたは複数の条件を含む同じノードプロトコルを施行するように構成される。無効なトランザクションは伝播されず、ブロックにも組み込まれないが、場合によっては、ノード104のローカルに短期間記憶される場合がある。トランザクションが承認され、それによってブロックチェーンに受け入れられると仮定すると、(任意のユーザデータを含む)トランザクションは、したがって、不変の公的記録としてブロックチェーンネットワークのノードの各々に登録され、インデックス付けされたままとなる。

【0071】

プルーフオブワークのパズルを解いて最新のブロックまたは最後のブロックを作ることに成功したノードは、概して、ある額のデジタル資産、すなわち、いくつかのトークンを分配する「コインベーストランザクション」と呼ばれる新しいトランザクションによって報酬を与えられる。無効なトランザクションの検出および拒否は、ネットワークのエージェントとして働く競い合うノードのアクションによって施行され、不正行為を報告し、ブロックするようにインセンティブを与えられる。それにもかかわらず、無効なトランザクションの(ブロックヘッダを含む)ブロックが、ネットワークになおも存在する場合がある。情報の広範な公開は、ユーザがノードの性能を継続的に監査することを可能にする。単なるブロックヘッダの公開は、参加者がブロックチェーンの継続している完全性を保証することを可能にする。ヘッダクライアントにおけるブロックヘッダの分析は、これをさらに改善する。

【0072】

ヘッダおよび軽量クライアントソフトウェア
クライアントアプリケーション105a、105bは、最初に、1つの好適なコンピュータ可読ストレージ媒体または複数の好適なコンピュータ可読ストレージ媒体上で任意の所与の関係者103a、103bのコンピュータ機器102a、102bに提供され、たとえば、サーバからダウンロードされるか、あるいはリムーバブルSSD、フラッシュメモリキー、リムーバブルEEPROM、リムーバブル磁気ディスクドライブ、磁気フロッピーディスクもしくはテープ、CDもしくはDVD ROMなどの光ディスク、またはリムーバブル光学ドライブなどのリムーバブルストレージデバイス上で提供される場合がある。一部の例においては、ブロックヘッダも、この方法でヘッダクライアントアプリケーション105aに提供される場合がある。

【0073】

ヘッダクライアントアプリケーション105aは、少なくとも、ブロックヘッダの最良のチェーンを導出する機能と、軽量クライアント102aと通信するための手段とを含む。ヘッダクライアントアプリケーション105aは、たとえば、ピアツーピアネットワーク106からブロックヘッダを調達するための手段も含む場合がある。ブロックヘッダを調達することは、代替的に、上述の商業者APIを通じて実行される可能性がある。

【0074】

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

【0075】

注:様々なクライアント機能が所与のクライアントアプリケーション105に統合されているものとして説明される場合があるが、これは、必ずしも限定的ではなく、むしろ、本明細書において説明される任意のクライアント機能は、その代わりに、たとえば、APIによってインターフェースをとる、または1つがそれ以外に対するプラグインである、2つ以上の異なるアプリケーションのスイートに実装されてよい。より広く、クライアント機能は、アプリケーションレイヤ、またはオペレーティングシステムなどのより下位のレイヤ、またはこれらの任意の組合せに実装される可能性がある。以下は、クライアントアプリケーション105の観点で説明されるが、これが限定的でないことは、理解されるであろう。

【0076】

図2は、ヘッダクライアント102aにおいてブロックヘッダの最良のチェーンを決定するための方法を示す。方法は、クライアントアプリケーション105aによって実行され、ヘッダクライアント102a自体で、ならびに/または軽量クライアント102bおよび/もしくはノード104などのピアツーピアネットワーク106のピアなどの別の外部ソースと共同で実行され得るステップを含む。

【0077】

ステップ210において、複数のブロックヘッダが、少なくとも1つの外部ソースからヘッダクライアント102aで受信される。外部ソースは、たとえば、ピアツーピアネットワーク106のブロックチェーンノード104のランダムなまたはローテーションするサブセットであることが可能である。外部ソースから複数のブロックヘッダを調達することは、図3に関連して下でより詳細に説明される。複数のブロックヘッダは、ブロックチェーンノード104に記憶されたブロックチェーンのバージョンを参照してよい。場合によっては、2つ以上の複数のブロックヘッダがヘッダクライアントで受信される場合があり、たとえば、ブロックチェーンノード104などの複数の異なる外部ソースから受信される場合がある。

【0078】

ブロックヘッダは、バージョン、前のブロックのハッシュ、マークルルート(ブロックのトランザクションのマークル木のルートのハッシュ)、タイムスタンプ、難易度目標(ブロックのプルーフオブワークアルゴリズムの難易度目標)、およびナンス(プルーフオブワークアルゴリズムのために用いられるカウンタ)を含む。ブロックヘッダは、ノードが有効なブロックの解を見つけるときにノードによって伝播される第1の情報であり、ヘッダクライアント102aに、そのブロックヘッダが関連するトランザクションまたはブロックについての情報を提供する。
ブロックヘッダは、以下のフィールドを含む:

【0079】

【表1】

【0080】

hashPrevBlock
前のブロックヘッダのハッシュは、ブロックヘッダをブロックチェーン内の前のブロックに接続する。この情報は、外部ソースから受信された複数のブロックヘッダを、ジェネシスから現在の最良のブロックまでのブロックチェーンを表す連続的な順序に配列するためにヘッダクライアントによって用いられることが可能であり、現在の最良のブロックは、ブロックチェーンに追加される最新のブロックである。ブロックヘッダを正しい順序に配列することは、ハッシュ値が順次一致してお互いを参照するかどうかをチェックすることによって実行される。

【0081】

hashMerkleRoot
これは、ブロックのトランザクションのマークル木のルートのハッシュを表す。これは、ブロック内のすべてのトランザクションの要約を含む。マークル木は、大きなデータセットを効率的に要約し、そのデータセットの完全性を検証するために用いられ、暗号学的ハッシュを含む二分木を含むデータ構造である。マークル木は、マークルルートと呼ばれる1つのハッシュのみが存在するまでノードのペアを再帰的にハッシュすることによって構築される。ビットコインのマークル木に用いられる暗号学的ハッシュアルゴリズムは、double-SHA256である。

【0082】

特定のトランザクションがブロックに含まれていることを証明するために、フルノードは、そのトランザクションを木のルートに接続するマークルパスを生成する。

【0083】

時間
ブロックのおおよその作成時間。

【0084】

ビット
ビットコインネットワークにおいて、目標は、すべてのビットコインクライアントが共有する256ビットの数である。ブロックがネットワークによって受け入れられるためには、ブロックのヘッダのdouble SHA-256ハッシュが現在の目標以下でなければならない。目標が低いほど、ブロックを生成することが難しくなる。

【0085】

難易度は、所与の目標未満のハッシュを見つけることがどれだけ難しいかの尺度である。難易度は、目標と密接な関係があるが、同じものではない。もっと正確に言えば、難易度は、より高い難易度がより低い目標値を示唆するという逆相関関係を有する。ビットコインネットワークは、グローバルブロック難易度(global block difficulty)を有し、有効なブロックは、この目標未満のハッシュを持たなければならない。概して、難易度が高いほど、対応する目標未満のハッシュ値を取得するために必要とされる計算処理能力は高くなる。

【0086】

ヘッダクライアントは、正しくない難易度目標を有するブロックヘッダを受信する場合、そのブロックヘッダの状態が「無効」であると決定することができる。

【0087】

ナンス
ナンスは、プルーフオブワークアルゴリズムのために用いられるカウンタである。プルーフオブワークは、作成するのは困難である(コストが高いおよび/または時間がかかる)が、他者が検証するのは容易なデータである。プルーフオブワークの生成は、通常、成功確率の低い確率過程(random process)を含む計算タスクを含み、したがって、有効なプルーフオブワークが生成されるまでに、平均して多くの試行錯誤が必要とされる。ビットコインにおいて、プルーフオブワークの方式は、SHA-256ハッシュアルゴリズムに基づいている。

【0088】

ビットコインは、マイニングの過程でプルーフオブワークシステムを用いる。ブロックが受け入れられるためには、ブロードキャストするノードが、ブロック内のデータのすべてを包含する有効な作業の証明を示さなければならない。ブロックチェーンの平均成長率を制限するために、有効な作業結果を発見する難易度が調整される。

【0089】

ブロックが有効であるためには、現在の目標未満の値へのブロックヘッダのdouble SHA-256ハッシュをもたらすナンスが発見されなければならない。これは、このブロックを発見したノードがネットワークのアクティブな参加者であることを示す。各ブロックのヘッダは、それが基づいて構築されているブロックのハッシュを含み、したがって、台帳を構成するブロックのチェーンを生成する。ブロックを変更することは、同じ先任者を含む新しいブロックを作ることによってのみ行われることが可能であり、すべての後続のブロックが含む作業をやり直すことによってそれらのすべての後続のブロックを再生成することを必要とする。これは、ブロックチェーンを改ざんから保護する。

【0090】

ブロックがビットコインネットワークによって受け入れられるためには、マイナーが、ブロック内のデータのすべてを包含するプルーフオブワークを完了しなければならない。この作業の難易度は、新しいブロックがネットワークによって生成され得るレートを制限するために調整される。生成が成功する確率が非常に低いため、どのコンピュータが次のブロックを生成するのかを予測することは不可能である。有効なプルーフオブワークの解を成功裏に見つける低い確率は、2人以上のマイナーが同じ時間付近でブロックを生成する見込みを小さくする。しかし、これは、時折起こり得る。

【0091】

ステップ220において、受信された複数のブロックヘッダが、ストレージモジュールに記憶される。一部の例において、ストレージモジュールは、ヘッダクライアント102aのローカルに置かれてよく、またはその他の例において、ストレージモジュールは、ヘッダクライアントの外部に置かれてよい。ストレージモジュールは、一部の例において、データベースであってよい。ストレージモジュールは、ブロックヘッダ、ブロックヘッダの最良のチェーン、無効な分岐を含むブロックチェーンの履歴、および/またはブロックヘッダの状態のうちの1つまたは複数を記憶する。軽量クライアント102bは、ストレージモジュールにアクセスするか、ストレージモジュールに記憶された特定のブロックヘッダについてヘッダクライアント102aに問い合わせることができてよい。一部の例において、ヘッダクライアントは、軽量クライアント102a上のソフトウェアとして実行される場合がある。

【0092】

ステップ230において、複数のブロックヘッダに対して分析が実行される。分析は、受信されたブロックヘッダに含まれる情報を用いて、その受信されたブロックヘッダのプルーフオブワークを確認することを含み得る。ブロックヘッダがブロックヘッダの最良のチェーン内にあるかどうかが、難易度および/またはプルーフオブワークを分析し、たとえば、高い難易度および有効なプルーフオブワークを有するブロックヘッダが最良のチェーンの一部であると決定することによってブロックヘッダから決定され得る。代替的に、ブロックヘッダが低い難易度を有するか、または何らかの形で無効である場合、これも決定され得る。

【0093】

ブロックヘッダを分析することは、一部の例においては、ヘッダクライアントで独立して実行され、一方、その他の例においては、分析は、軽量クライアントおよび/またはブロックチェーンノード104と連携して実行され得る。

【0094】

第4のステップ240において、ブロックヘッダの最良のチェーンが決定される。ブロックヘッダの最良のチェーンは、さらにストレージモジュールで記憶され得る。最良のチェーンは、上記のように、ブロックチェーンの最初のブロックであるジェネシスから、ブロックチェーンの最後のブロックである現在の最良のブロックまでのブロックのチェーンである。「現在の最良のブロック」は、ブロックチェーン上で検証される最新のブロックであり、最も高い累積のプルーフオブワークを有するブロックを指す場合がある。ブロックヘッダのこの最良のチェーンは、軽量クライアント102bに閲覧されるかまたは提供されることが可能である。最良のチェーンの一部ではない分岐および/またはブロックをさらに含む、ジェネシスから現在の最良のブロックまでのブロックチェーンのバージョンまたはグラフが、ヘッダクライアントによってさらに構築され、任意でストレージモジュールに記憶され得る。

【0095】

最良のチェーンおよびネットワークの状態は、どこかに、たとえば、一部の例においてはヘッダクライアント102aまたは軽量クライアント102bのローカルにある可能性があるストレージモジュールに記憶および/または維持され得る。ローカルにコピーを記憶することは、たとえば、ヘッダクライアントソフトウェアの再起動後に、ブロックヘッダのチェーン全体をジェネシスから再度ダウンロードする必要をなくす。

【0096】

ヘッダクライアントにおいて受信された2つのブロックヘッダが、場合によっては、ブロックチェーンの同じ高さの、すなわち、「フォーク」の2つの異なるブロックを指す場合がある。ブロックチェーンの相反するビューがノード104の間で伝播されるように、2つのブロックチェーンノード104が互いに非常に短い時間内にそれらのブロックチェーンノード104のパズルを解く、発生する可能性があるすべてのフォークを解決するためのプロトコルが存在する。手短に言えば、どちらでも最も長くなる方のフォークの爪が、最長のチェーンの一部となり、したがって、最終的なブロックチェーン150およびブロックヘッダの最良のチェーンの一部になる可能性が高い。これは、同じトランザクションが両方のフォークに現れるので、ネットワークのユーザまたはエージェントに影響を与えないはずであり、両方のブロックが有効であることが可能であることに留意されたい。

【0097】

一部の例において、ヘッダクライアントは、孤児に関連するブロックヘッダをマーキングおよび/または追跡することができる。追跡は、ネットワークからの新しいおよび/または更新された複数のブロックヘッダの受信と併せて、ブロックチェーンネットワークへの維持された接続によって達成され得る。

【0098】

2つのフォークした分岐のうちのどちらが最良のチェーンであるかを決定する方法は、ブロックチェーンにおけるトランザクションに関連するブロックの深さを決定することである。ブロックがそのブロックの上に構築された特定の数のブロック(たとえば、6個のブロック)を有する場合、これが、最良のチェーンでもあることが多い最長のチェーンであると推論され得る。

【0099】

ブロックまたはブロックの分岐の状態が、保存および記憶され得る。状態は、以下、すなわち、「ブロックヘッダの最良のチェーン内」、「有効」、「孤児」、「無効」、「不明」のうちの1つを含んでよい。一部の実施形態においては、ブロックヘッダが、上述の決定に沿って有効または無効としてマーキングされ得る。この情報は、たとえば、データベースまたはストレージモジュールに記憶されることが可能であり、ジェネシスブロックからのブロックチェーンのグラフを構築するために用いられ得る。

【0100】

一部の実施形態において、軽量クライアント102bは、特定のブロックヘッダの状態をヘッダクライアント102aに尋ねてよい。たとえば、トランザクションがブロックヘッダの最良のチェーン内にあるかどうかをチェックするため。

【0101】

ブロックヘッダの調達
ヘッダクライアント102aおよび/または軽量クライアント102bがアクセス可能なデータベースが、ネットワーク106のすべてのピアのローテーションするサブセットからリアルタイムでヘッダメッセージを同期することによって、ネットワーク106、たとえば、ビットコインネットワークからデータを投入されてよい。最長/最良のチェーンは、有利なことに、すべてのピアのランダムでローテーションする選択から独立して調達されて、最終的にすべてのピアと同期する。これは、有利なことに、検証プロセスに対するエクリプス攻撃を防止し、したがって、悪意のある者がブロックチェーンネットワークの多数のノードまたはIPアドレスにアクセスすることができるかまたはそれらを制御する場合に敵対的なフォークの作成を防止するのに役立ち得る。エクリプス攻撃は、悪意のある者が、数学的にあるブロックまで引き続き遡られ得る正しくない証明を提供することによってブロックの有効なチェーンを隠そうとする場合があるが、そのブロックが無効なブロックである場合があり、または悪意のある者によって生成された可能性がある攻撃である。ヘッダクライアント102aにおいて複数のソースからブロックヘッダを受信することは、ヘッダクライアント102aが受信する情報がブロックチェーンおよび現在の最良のブロックの最も正確な表現を表すことも保証する。一部の例において、ヘッダクライアント102aは、インタラクションされた外部ソースの数が所定の閾値を超えるまで、外部ソースからブロックヘッダを調達してよい。一例において、所定の閾値は、厳密に独立した2つのノードである場合があるが、その他の例においては、最大でネットワークのすべてのノードまでであり、ネットワークのすべてのノードを含む可能性がある。一部の例において、ヘッダクライアントは、外部ソースのローテーションするセットから、たとえば、一度に約12個の外部ソースからブロックヘッダを調達する場合がある。

【0102】

図3は、ヘッダクライアント102aにおいて複数の外部ソース305-1、305-2、... 305-nからブロックヘッダを調達することを示す。一例において、ブロックヘッダは、ヘッダクライアントアプリケーション105aによって、一部の例においてはネットワーク106のノード104またはその他のピアである場合がある外部ソース305-1、305-2、... 305-nとのインタラクションを通じて取り出されるかまたは調達され得る。

【0103】

第1のステップ310において、ヘッダクライアント102aは、ブロックヘッダを求める第1のメッセージを第1の外部ソース305-1に送信し、および/またはその他の外部ソースのアイデンティティを求めるさらなる第2のメッセージを第1の外部ソース305-1に送信する。1つのブロックヘッダまたは複数のブロックヘッダを1つまたは複数の外部ソース305-1、305-2から取得するために、ヘッダクライアント102aは、「getheaders」メッセージなどの第1のメッセージを送信する。このメッセージは、ブロックロケータオブジェクト(block locator object)内の最後の知られているハッシュから始まり、hash_stopまたは2000ブロックのどちらか先に来る方までのブロックのヘッダを含むヘッダパケットを返す。次のブロックヘッダを受信するために、ヘッダクライアント102aは、新しいブロックロケータオブジェクトを用いて再びgetheadersメッセージを発行することを求められる。

【0104】

第2のステップ315において、第1の外部ソース305-1は、ヘッダクライアント102aによって送信された第1のメッセージおよび/または第2のメッセージを受信する。

【0105】

ステップ320において、第1の外部ソース305-1は、第1のメッセージに応答する外部ソースに記憶された複数のブロックヘッダと、第2の外部ソース305-2のアイデンティティとを送信する。複数のブロックヘッダは、外部ソース305-1に記憶されたすべてのブロックヘッダを含む場合がある。ノード104などの複数の外部ソースとインタラクションすることによって、ヘッダクライアントは、非常に迅速に多くの複数のブロックヘッダを提供され得る。

【0106】

ステップ325において、ヘッダクライアント102aは、第1の外部ソース305-1からブロックヘッダと第2の外部ソース305-2のアイデンティティとを受信する。第1の外部ソース305-1は、さらなる外部ソースの2つ以上のアイデンティティ、たとえば、最大n個の外部ソース305-nの複数のアイデンティティを送信する場合があることが理解されるであろう。

【0107】

ステップ330において、ヘッダクライアント102aは、第1のメッセージおよび/または第2のメッセージを送信することによってステップ310を繰り返すが、今回は、第1の外部ソース305-1によってヘッダクライアント102aにアイデンティティが供給された可能性がある第2の外部ソース305-2にメッセージを送信する。

【0108】

ステップ335において、第2の外部ソース305-2は、ヘッダクライアント102aによって送信された第1のメッセージおよび/または第2のメッセージを受信する。

【0109】

ステップ340において、外部ソース305-2は、第1のメッセージに応答する第2の外部ソース305-2に記憶されたブロックヘッダ、および/またはさらなる外部ソースの1つのアイデンティティもしくは複数のアイデンティティを送信する。

【0110】

ステップ345において、ヘッダクライアント102aは、第2の外部ソース305-2からブロックヘッダおよび/または外部ソースのアイデンティティを受信する。

【0111】

ステップ350において、ヘッダクライアント102aは、第1のメッセージおよび/または第2のメッセージを送信することによってステップ310を繰り返すが、今回は、外部ソース305-nにメッセージを送信する。一部の例において、ステップ330および350は、たとえば、外部ソース305-nのアイデンティティが第1の外部ソース305-1によって供給された場合、同時に起こる場合がある。

【0112】

ステップ335および360は、それぞれ、第1の外部ソース305-1におけるステップ315および320と、第2の外部ソース305-2におけるステップ335および340との繰り返しである。

【0113】

ステップ365において、複数のブロックヘッダおよび/またはその他の外部ソースのアイデンティティが、ヘッダクライアント102aで受信される。

【0114】

プロセスステップ310から365は、任意の数の外部ソースにおいて任意の回数繰り返されてよい。ブロックヘッダを調達することは、たとえば、閾値の数の外部ソースがインタラクションされたときに停止してよい。一部の例において、図3に示された調達プロセスは、ネットワーク106からより多くのブロックヘッダを収集するために、定期的にまたはオペレータの要求に応じて繰り返されてよい。これは、ブロックチェーンネットワーク106のブロックチェーン150にさらに多くのブロックが追加されるにつれて、ブロックヘッダの最良のチェーンの最新バージョンを維持するために行われ得る。

【0115】

一部の例において、ヘッダクライアント102aは、ブロックヘッダおよび追加情報を要求することができる。そのような追加情報は、受信されたブロックヘッダの外部ソースに関連するURL、ブロックヘッダによって参照されるブロックのマイナーID(これはマイナーノードの一意識別子である)、エンドポイントURL、包含証明、および/またはコインベースである場合がある。

【0116】

この追加情報は、たとえば、特定の1人のマイナーもしくは複数のマイナーのリスクプロファイルを分析し、1人もしくは複数のマイナーの評判を特定もしくは決定し、および/またはどのマイナーが最も多くのブロックを生成するかを決定するために軽量クライアントによって用いられてよい。この情報は、たとえば、トランザクションをどのノードに送信するかについての判断を知らせるために、どのマイナーが信頼できるおよび/または評判が良いかを知りたい軽量クライアント102bにとって有用であり得る。追加情報から、経時的なハッシュパワーのシェア、孤児の数などの統計データが決定される場合がある。

【0117】

その他の例において、ブロックヘッダは、別のヘッダクライアント102aまたは別の「オフチェーン」のソースなどのその他の外部ソースから調達され得る。

【0118】

図4Aは、ここで開示されている方式の実施形態を実装するための、ヘッダクライアントアプリケーション105aまたは軽量クライアントアプリケーション105bなどのクライアントアプリケーション105の例示的な実装を示す。クライアントアプリケーション105は、エンジン401およびユーザインターフェース(UI)レイヤ402を含む。エンジン401は、ヘッダクライアント105aおよび/または軽量クライアント105bの基礎となる機能を適宜実施するように構成される。ヘッダクライアントアプリケーション105bは、ブロックヘッダおよび/または特定のブロックヘッダの状態および/またはその他のデータを受信するならびに/あるいはサイドチャネル301を介して軽量クライアントに送信するなどの機能を実装してよい。軽量クライアントアプリケーション105bは、ブロックヘッダの最良のチェーンを問い合わせるための機能を実装してよい。

【0119】

本明細書に開示された実施形態によれば、たとえば、nChain Holdings Limitedの名義で2021年2月17日に出願されたGB2102217.3にさらに詳細に記載されているように、軽量クライアント105bのエンジン401は、ブロックヘッダの最良なチェーンに関連してヘッダクライアントに問い合わせを行うための機能403を含む。軽量クライアント102bは、トランザクションを構築し、それらのトランザクションをブロックチェーンに含めるために送ることができる。また、軽量クライアント102bは、自身のトランザクション(またはその他のクライアントからのトランザクション)の状態を外部ソースから知ることができる。軽量クライアント102bは、以下のデータを持っている場合に、トランザクションがブロックチェーンに含められたと確信してよい。
・包含が証明されるトランザクション。
・トランザクションがマークルルートの値に寄与したことを示す、そのトランザクションのマークル包含証明(Merkle inclusion proof)。
・マークルルートを含むビットコインSVブロックヘッダ。
・プルーフオブワークによって測られたブロックヘッダの最良のチェーン。

【0120】

軽量クライアントのためのトランザクションの包含の検証は、以下のように実行され得る。まず、軽量クライアント102bは、特定のトランザクションに関連する、ヘッダクライアントに記憶されたブロックヘッダを要求または閲覧し、たとえば、軽量クライアントは、最良のチェーンを閲覧する場合がある。軽量クライアントは、ソーストランザクションおよび包含証明からマークル木のルートを計算する。証明を偽造することは、暗号学的に強力なハッシュ関数を逆算するのと同じくらい難しく、つまり、事実上不可能と考えられる。軽量クライアントは、前のステップで計算されたマークルルートが、指定されたブロックヘッダにおいて宣言されたマークルルートと一致することを検証する。また、軽量クライアントは、ブロックヘッダの最良のチェーンを用いて、指定されたブロックヘッダが最良のチェーン内に存在することを検証する。これらのチェックのすべてが成功する場合、トランザクションはブロックチェーンに含まれ、軽量クライアントは、トランザクションが検証されたと決定する。

【0121】

マークル証明(Merkle proof)は、以下のデータを含む場合がある。
・マークル証明が関連するブロックチェーントランザクションのトランザクション識別子(TxID)、
・ブロックチェーントランザクションが含まれるブロックのブロックヘッダ、および
・トランザクション識別子(TxID)の兄弟ハッシュ(sibling hash)の配列。

【0122】

トランザクションの存在を確立することは、プルーフオブワークにおけるマークルパス証明(Merkle path proof)を要求または決定し、プルーフオブワークを承認することによって着手され得る。

【0123】

ヘッダクライアント102aは、上述のように動作し、ヘッダの最長/最良のチェーンを調達するために用いられてよい。ヘッダクライアント102aは、オープンソースであることが可能であるので、誠実で正直に特定されたチェーンがブロックヘッダの最長/最良のチェーンを表すことを保証するために、独立した検証者エンティティによって検査されてもよい。代替的に、その他の含意が、利用可能である場合があり、または独立した検証者が、必要とされるデータを調達するために独自のヘッダクライアント102aを実装する場合がある。

【0124】

公開されているブロックエクスプローラサービスが、存在する。これらのサービスがウェブインターフェースを通じたものであろうがまたはAPIを通じたものであろうが、これらの公開されているブロックエクスプローラは、通常、ブロックのハッシュが与えられたときにブロックのメタデータをフェッチする機能を提供する。ヘッダの調達と同様に、第三者のまたは独立したデータソースを用いる場合、様々なソースが用いられることが好ましい場合がある。これは、任意の独立した検証者によって見られるブロックチェーンのビューを単一のまたは少数の外部の行為者(actor)が制御する可能性を有利に減らすためである。

【0125】

注:本明細書の様々な機能は、同じまたは異なるクライアントアプリケーション105a、105bに統合されているものとして説明される場合があるが、これは、必ずしも限定的でなく、代わりに、それらの機能は、組み合わされたヘッダクライアント-軽量クライアントデバイス上の単一のアプリケーションとして実装される可能性がある。代替的に、それらの機能は、2つ以上の異なるアプリケーションのスイートとして実装される可能性があり、たとえば、一方が他方のプラグインであるか、またはAPI(アプリケーションプログラミングインターフェース)を介してインターフェースを取る。たとえば、エンジン401の機能は、UIレイヤ402とは別個のアプリケーションに実装されてよく、またはエンジン401などの所与のモジュールの機能は、2つ以上のアプリケーションの間で分けられる可能性がある。説明される機能の一部またはすべてが、たとえば、オペレーティングシステムレイヤに実装される可能性があることも排除されない。本明細書の任意の箇所で単一のまたは所与のアプリケーション105などへの言及がなされる場合、これは単なる例示であり、より広く、説明された機能は任意の形態のソフトウェアで実装される可能性があることが理解されるであろう。

【0126】

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

【0127】

例において、軽量クライアント102aは、特定のブロックの状態を知りたい場合がある。ヘッダクライアントは、API get header by hashによって、完全なブロックヘッダをその現在の状態(最良のチェーン内、孤児、不明など)と一緒に返すことができる。一部の実施形態において、チャネルまたはメッセージ機能は、クライアントまたはその他のエンティティによる1つまたは複数のメッセージのアクセス、作成、および/または管理を可能にするための、アカウント用のJavaScriptオブジェクト表記法(JSON: JavaScript Object Notation)オーバーハイパーテキスト転送プロトコル(HTTP)APIを含む。

【0128】

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

【0129】

例示として、図2Bは、軽量クライアントの観点でUI500を示す。UI500は、ユーザ出力手段を介して異なるUI要素としてレンダリングされる1つまたは複数のUI要素501、502、502を含んでよい。

【0130】

たとえば、UI要素は、異なる画面上のボタン、またはメニューの異なる選択肢などである場合がある1つまたは複数のユーザが選択可能な要素501を含んでよい。ユーザ入力手段は、ユーザ103が、画面上のUI要素をクリックもしくはタッチするか、または所望の選択肢の名前を言うことによるなどして、選択肢のうちの1つを選択するかまたはそれ以外の方法で操作することを可能にするように配置される(本明細書において使用される用語「手動」は、自動と対照を成すことを意図されているに過ぎず、必ずしも1つの手または複数の手の使用に限定されないことに注意されたい)。選択肢は、ユーザ(軽量クライアント)が特定のブロックヘッダの状態または最良のチェーンのバージョンを要求することを可能にする。

【0131】

代替的または追加的に、UI要素は、1つまたは複数のデータ入力フィールド502を含んでよく、それらのデータ入力フィールド502を通じて、ユーザは、たとえば、ヘッダクライアントに記憶されたブロックヘッダを参照することによってブロックの状態を要求することができる。一部の実施形態においては、フルブロックヘッダが要求され、ヘッダクライアントから軽量クライアントに送信される場合がある。これらのデータ入力フィールドは、ユーザ出力手段を介して、たとえば、画面上にレンダリングされ、データは、ユーザ入力手段、たとえば、キーボードまたはタッチスクリーンを通じてフィールドに入力され得る。代替的に、データは、たとえば、音声認識に基づいて口述でデータを受け取る可能性がある。

【0132】

代替的または追加的に、UI要素は、ユーザに対して情報を出力するための1つまたは複数の情報要素503の出力を含んでよい。たとえば、これ/これらは、画面上にまたは聞こえるようにレンダリングされる可能性がある。

【0133】

様々なUI要素をレンダリングし、選択肢を選択し、データを入力する特定の手段は重要ではないことが理解されるであろう。これらのUI要素の機能は、まもなくより詳細に検討される。図3に示されたUI500は図式化されたモックアップであるに過ぎず、実際には、簡潔にするために図示されていない1つまたは複数のさらなるUI要素を含む場合があることも理解されるであろう。

【0134】

開示された技術のその他の変形またはユースケースは、本明細書の開示が与えられれば、当業者に明らかになるであろう。本開示の範囲は、記載された実施形態によって限定されず、添付の特許請求の範囲によってのみ限定される。

【0135】

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

【0136】

本発明の好ましい実施形態において、ブロックチェーンネットワーク106は、ビットコインネットワークであり、ビットコインノード104が、ブロックチェーン150のブロック151を作成し、公開し、伝播し、記憶する説明された機能の少なくともすべてを実行する。ヘッダクライアント102aまたは軽量クライアント102bなどのその他のネットワークエンティティ(またはネットワーク要素)は、これらの機能の1つまたは一部を実行するが、すべては実行しない。

【0137】

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

【0138】

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

【符号の説明】

【0139】

100 システム
101 パケット交換ネットワーク、ネットワーク
102 コンピュータ端末、コンピュータ機器、機器
102a ヘッダクライアント、コンピュータ機器
102b 軽量クライアント、コンピュータ機器
103 ユーザ、エージェント、関係者
103a ヘッダクライアント
103b 関係者、軽量クライアント
104 ブロックチェーンノード、ビットコインノード
105 クライアントアプリケーションまたはソフトウェア
105a クライアントアプリケーション
105b クライアントアプリケーション
106 ピアツーピア(P2P)ネットワーク、ビットコインネットワーク、ブロックチェーンネットワーク
150 ブロックチェーン、ビットコインブロックチェーン
151 データのブロック、ブロック
152 トランザクション、トランザクションデータ
152i 先行トランザクション
152j 現在のトランザクション、トランザクション
153 ジェネシスブロック(Gb)
154 順序付けられたセット
155 ブロックポインタ
156 ブロックヘッダ
301 サイドチャネル
305-1、305-2、... 305-n 外部ソース
401 トランザクションエンジン、エンジン
402 ユーザインターフェース(UI)レイヤ
403 機能
500 ユーザインターフェース(UI)
501 UI要素
502 UI要素、データ入力フィールド

【図1】

【図2】

【図3】

【図4A】

【図4B】

【国際調査報告】