特表 2024-525196 マルチレベルブロックチェーン

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

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

(11)【公表番号】

(43)【公表日】2024-07-10

(54)【発明の名称】マルチレベルブロックチェーン

(51)【国際特許分類】

   H04L 9/32 20060101AFI20240703BHJP

【ＦＩ】

H04L9/32 200Z

【審査請求】未請求

【予備審査請求】未請求

(21)【出願番号】P 2023578810

(86)(22)【出願日】2022-05-25

(85)【翻訳文提出日】2024-02-13

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

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

(87)【国際公開日】2022-12-29

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

(32)【優先日】2021-06-25

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

(81)【指定国・地域】

【公序良俗違反の表示】

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

１．ＵＮＩＸ

(71)【出願人】

【識別番号】318001991

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

(74)【代理人】

【識別番号】100108453

【弁理士】

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

(74)【代理人】

【識別番号】100110364

【弁理士】

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

(74)【代理人】

【識別番号】100133400

【弁理士】

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

(72)【発明者】

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

(72)【発明者】

【氏名】クロエ・タータン

(72)【発明者】

【氏名】キャサリン・モロイ

(57)【要約】

コアブロックチェーン上にデータチェーンを埋め込むためにマルチレベル(ML)データチェーンプロトコルを使用するコンピュータ実装方法であって、1つまたは複数のMLトランザクションを取得するステップであって、各MLトランザクションが、1つまたは複数のキャリアペアを備え、各キャリアペアが、入力および出力を備え、各出力が、データチェーンに関連付けられたデータを備え、各入力が、キャリアペアに署名する署名を備える、ステップと、MLデータチェーンの第1のMLブロックを生成するステップであって、第1のMLブロックが、コアブロックチェーントランザクションであり、a)取得された1つまたは複数のMLトランザクションのそれぞれのキャリアペアであって、キャリアペアごとに、それぞれの入力のそれぞれの位置インデックスが、それぞれの出力のそれぞれの位置インデックスに対応する、それぞれのキャリアペア、およびb)第1のチェーン出力であって、後続のMLブロックのそれぞれのチェーン入力によって消費されるためのものである、第1のチェーン出力を備える、ステップとを備える、コンピュータ実装方法。

【特許請求の範囲】

【請求項1】

コアブロックチェーン上にデータチェーンを埋め込むためにマルチレベル(ML)データチェーンプロトコルを使用するコンピュータにより実施される方法であって、MLブロックプロデューサによって実行され、かつ
1つまたは複数のMLトランザクションを取得するステップであって、
各MLトランザクションが、1つまたは複数のそれぞれのキャリアペアを備え、
各キャリアペアが、それぞれの入力およびそれぞれの出力を備え、
各それぞれの出力が、前記データチェーンに関連付けられたそれぞれのデータを備え、
各それぞれの入力が、前記それぞれのキャリアペアに署名するそれぞれの署名を備える、ステップと、
前記MLデータチェーンの第1のMLブロックを生成するステップであって、
前記第1のMLブロックが、コアブロックチェーントランザクションであり、a)前記取得された1つまたは複数のMLトランザクションの前記それぞれのキャリアペアであって、キャリアペアごとに、前記それぞれの入力のそれぞれの位置インデックスが、前記それぞれの出力のそれぞれの位置インデックスに対応する、前記それぞれのキャリアペア、およびb)第1のチェーン出力であって、後続のMLブロックのそれぞれのチェーン入力によって消費されるためのものである、第1のチェーン出力を備える、ステップと、
前記第1のMLブロックを前記コアブロックチェーン上に記録させるステップと
を備える、コンピュータにより実施される方法。

【請求項2】

前記コアブロックチェーンが、1つまたは複数の以前のMLブロックを備え、
各以前のMLブロックが、それぞれのコアブロックチェーントランザクションであり、a)1つまたは複数のキャリアペア、b)それぞれのチェーン出力、およびc)それぞれのチェーン入力を備え、
各それぞれのチェーン入力が、以前のMLブロックのそれぞれのチェーン出力を消費し、その結果、前記1つまたは複数の以前のMLブロックが、MLブロックチェーンを形成し、
前記第1のMLブロックが、c)以前のMLブロックのそれぞれのチェーン出力を消費する第1のチェーン入力を備える、請求項1に記載の方法。

【請求項3】

前記第1のMLブロックを前記コアブロックチェーン上に前記記録させるステップが、前記第1のMLブロックをコアブロックチェーンネットワークにサブミットするステップを備える、請求項1または2に記載の方法。

【請求項4】

前記第1のMLブロックを前記コアブロックチェーン上に前記記録させるステップが、第1のコアブロックを前記コアブロックチェーンネットワークにサブミットするステップを備え、
前記第1のコアブロックが前記第1のMLブロックを備える、請求項1から3のいずれか一項に記載の方法。

【請求項5】

前記1つまたは複数のMLトランザクションを前記取得するステップが、前記1つまたは複数のMLトランザクションのうちの少なくとも1つを受信するステップを備える、請求項1から4のいずれか一項に記載の方法。

【請求項6】

前記1つまたは複数のMLトランザクションを前記取得するステップが、前記1つまたは複数のMLトランザクションのうちの少なくとも1つを生成するステップを備える、請求項1から5のいずれか一項に記載の方法。

【請求項7】

キャリアペアの中に含められるべきデータを受信するステップと、
前記受信されたデータを前記少なくとも1つのMLトランザクションのキャリアペアの中に含めることによって前記1つまたは複数のMLトランザクションのうちの少なくとも1つを生成するステップと
を備える、請求項6に記載の方法。

【請求項8】

受信されたMLトランザクションのそれぞれのキャリアペアのメモリプールを維持するステップと、
前記メモリプールの中に記憶された前記それぞれのキャリアペアのうちの1つまたは複数に基づいて前記第1のMLブロックを生成するステップと
を備える、請求項5またはそれに従属するいずれかの請求項に記載の方法。

【請求項9】

前記取得されたMLトランザクションのうちの1つまたは複数を1つまたは複数のMLブロックプロデューサへ送るステップを備える、請求項1から8のいずれか一項に記載の方法。

【請求項10】

前記第1のMLブロックが複数のキャリアペアを備える、請求項1から9のいずれか一項に記載の方法。

【請求項11】

前記それぞれのデータが暗号化される、請求項1から10のいずれか一項に記載の方法。

【請求項12】

前記それぞれのデータが、ハッシュ関数を使用して暗号化される、請求項11に記載の方法。

【請求項13】

キャリアペアごとに、前記それぞれの署名が、前記キャリアペアの前記入力および出力にしか署名しない、請求項1から12のいずれか一項に記載の方法。

【請求項14】

キャリアペアごとに、前記それぞれの署名が、前記それぞれの署名が前記キャリアペアの前記入力および出力にしか署名しないことを示す署名フラグに関連付けられる、請求項13に記載の方法。

【請求項15】

各MLトランザクションが、コアブロックチェーンプロトコルに従って無効なトランザクションである、請求項1から14のいずれか一項に記載の方法。

【請求項16】

前記データチェーンが2次ブロックチェーンであり、
前記それぞれのデータが、2次ブロックチェーンのブロックチェーントランザクションを備える、請求項1から15のいずれか一項に記載の方法。

【請求項17】

前記第1のMLブロックの前記キャリアペアのうちの1つの前記それぞれのデータが、前記2次ブロックチェーンの一部または全部を備える、請求項16に記載の方法。

【請求項18】

前記それぞれのデータが、アプリケーション固有データを備える、請求項1から15のいずれか一項に記載の方法。

【請求項19】

それぞれのMLブロックのそれぞれのチェーン出力が、それぞれのブロックヘッダを備え、
前記それぞれのブロックヘッダが、マークルツリーのマークルルートを備え、
前記マークルツリーのそれぞれのリーフが、前記それぞれのMLブロックの前記それぞれのキャリアペアの前記それぞれのデータに基づく、請求項1から18のいずれか一項に記載の方法。

【請求項20】

前記それぞれのブロックヘッダが、前記それぞれのMLブロックが作成された、および/またはコアブロックチェーンネットワークにサブミットされた時間を示すタイムスタンプを備える、請求項19に記載の方法。

【請求項21】

前記第1のチェーン出力が、プルーフオブワーク(PoW)パズルを実施するように構成されたロックスクリプトを備え、
前記PoWパズルが、第1のブロックヘッダハッシュおよび難解ターゲットを備え、
前記第1のブロックヘッダハッシュが、前記第1のMLブロックの前記それぞれのブロックヘッダのハッシュであり、
前記ロックスクリプトは、後続のMLブロックのそれぞれのチェーン入力が、前記第1のMLブロックの前記第1のブロックヘッダハッシュと結合されたとき、それぞれのブロックヘッダハッシュを備えることを必要とするように構成され、
前記結合のハッシュが、前記難解ターゲットを満たす、請求項19または20に記載の方法。

【請求項22】

前記第1のMLブロックの前記第1のチェーン入力が、前記第1のMLブロックの第1のブロックヘッダを備え、
前記第1のMLブロックの前記第1のブロックヘッダが、前記以前のMLブロックの前記それぞれのチェーン出力のロックスクリプトによって実施されるPoWパズルによって設定された前記難解ターゲットを満たす、請求項2に従属するときの請求項21に記載の方法。

【請求項23】

前記第1のチェーン出力が、PoW rパズルを実施するように構成されたロックスクリプトを備え、
前記PoW rパズルが、第1のハッシュ値および難解ターゲットを備え、
前記第1のハッシュ値が、第1のr値と結合された第1のブロックヘッダのハッシュであり、ここで、前記r値が、デジタル署名の成分であり、
前記ロックスクリプトは、ロック解除されるために、後続のMLブロックのそれぞれのチェーン入力が、i)前記後続のMLブロックのそれぞれのブロックヘッダ、およびii)前記第1のr値を使用する署名を備えることを必要とされるように構成され、
第1のロックスクリプトが、前記署名から前記第1のr値を抽出し、前記抽出されたr値と結合された前記それぞれのブロックヘッダのハッシュとして第2のハッシュ値を生成し、前記第1のハッシュ値および前記第2のハッシュ値の結合のハッシュが前記難解ターゲットを満たすことを検証するように構成される、請求項19または20に記載の方法。

【請求項24】

前記第1のMLブロックの前記第1のチェーン入力が、i)前記第1のMLブロックの前記第1のブロックヘッダ、およびii)前記以前のMLブロックの前記それぞれのチェーン出力によって設定されたr値を使用する第1の署名を備え、
前記第1のMLブロックの前記第1のブロックヘッダが、前記以前のMLブロックの前記それぞれのチェーン出力のロックスクリプトによって実施されるPoW rパズルによって設定された前記難解ターゲットを満たす、請求項2に従属するときの請求項23に記載の方法。

【請求項25】

前記第1のチェーン出力が、
- MLブロックプロデューサに関連付けられた公開鍵にロックされたロックスクリプト、
- 公開鍵のセットのうちの1つまたは複数にロックされたマルチ署名ロックスクリプトであって、各公開鍵がそれぞれのMLブロックプロデューサに関連付けられる、マルチ署名ロックスクリプト、
- しきい値秘密鍵に対応する公開鍵にロックされたロックスクリプトであって、前記しきい値秘密鍵が複数の秘密鍵シェアに分割され、各秘密鍵シェアがそれぞれのMLブロックプロデューサに関連付けられる、ロックスクリプト、
- ハッシュパズルを実施するように構成されたロックスクリプトであって、前記ハッシュパズルに対する原像が1つまたは複数のMLブロックプロデューサに利用可能にされる、ロックスクリプト、
- 特定のr値の知識を用いて任意のブロックプロデューサによって前記ロックスクリプトがロック解除され得るような、rパズルを実施するように構成されたロックスクリプト
のうちの1つを備える、請求項1から20のいずれか一項に記載の方法。

【請求項26】

前記MLブロックプロデューサが、前記コアブロックチェーンのブロックチェーンノードである、請求項1から25のいずれか一項に記載の方法。

【請求項27】

前記MLブロックプロデューサが、前記コアブロックチェーンのブロックチェーンノードではない、請求項1から3または5から25のいずれか一項に記載の方法。

【請求項28】

前記MLブロックプロデューサが、簡易支払い検証クライアントである、請求項27に記載の方法。

【請求項29】

各MLブロックのそれぞれのチェーン出力が、それぞれのロックスクリプトをロック解除するための同じタイプのコンセンサスメカニズムを実施するように構成されたそれぞれのロックスクリプトを備える、請求項1から28のいずれか一項に記載の方法。

【請求項30】

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

【請求項31】

コンピュータ可読ストレージ上に組み込まれ、1つまたは複数のプロセッサ上で動作するときに請求項1から29のいずれか一項に記載の方法を実行するように構成された、コンピュータプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、マルチレベルデータチェーンプロトコルを使用するブロックチェーン上にデータを埋め込む方法に関する。

【背景技術】

【0002】

ブロックチェーンとは、ある形態の分散型データ構造を指し、ブロックチェーンの複製コピーが、分散ピアツーピア(P2P)ネットワーク(以下で「ブロックチェーンネットワーク」と呼ばれる)の中の複数のノードの各々において維持され広く公表される。ブロックチェーンはデータのブロックのチェーンを備え、各ブロックは1つまたは複数のトランザクションを備える。いわゆる「コインベーストランザクション」以外の各トランザクションは、1つまたは複数のコインベーストランザクションに戻る1つまたは複数のブロックに広がることがある、シーケンスの中の先行するトランザクションを戻って指し示す。コインベーストランザクションは以下でさらに説明される。ブロックチェーンネットワークにサブミットされるトランザクションは、新たなブロックの中に含められる。新たなブロックは、しばしば、「マイニング」と呼ばれる、プロセスによって作成され、そうしたプロセスは、複数のノードの各々が競合して「プルーフオブワーク」を実行すること、すなわち、ブロックチェーンの新たなブロックの中に含められるのを待っている、順序付けおよび有効化された保留トランザクションの規定されたセットの表記に基づいて、暗号パズルを解くことを伴う。いくつかのノードにおいてブロックチェーンがプルーニングされてよいこと、およびブロックの発行が単なるブロックヘッダの発行を通じて達成され得ることに留意されたい。

【0003】

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

【0004】

ブロックチェーンネットワークのノード(しばしば、「マイナー」と呼ばれる)は、後でより詳細に説明される分散トランザクション登録および検証プロセスを実行する。要約すれば、このプロセス中、ノードはトランザクションを有効化し、ノードがそれに対して有効なプルーフオブワーク解を識別することを試みるブロックテンプレートの中に、トランザクションを挿入する。有効な解が見つけられると、新たなブロックがネットワークの他のノードに伝搬され、したがって、各ノードがブロックチェーン上に新たなブロックを記録することを可能にする。トランザクションをブロックチェーンの中に記録させるために、ユーザ(たとえば、ブロックチェーンクライアントアプリケーション)は、伝搬されるべきネットワークのノードのうちの1つへトランザクションを送る。トランザクションを受信するノードは、有効化されたトランザクションを新たなブロックの中に組み込むプルーフオブワーク解を見つけるために競争してよい。各ノードは、トランザクションが有効となるための1つまたは複数の条件を含む、同じノードプロトコルを執行するように構成される。無効なトランザクションは、伝搬されることもブロックの中に組み込まれることもない。トランザクションが有効化され、それによって、ブロックチェーン上に受け入れられることを想定すると、その場合、(任意のユーザデータを含む)トランザクションは、不変の公的な記録としてブロックチェーンネットワークの中のノードの各々において、そのように登録およびインデックス付けされたままである。

【0005】

プルーフオブワークパズルを首尾よく解いて最新のブロックを作成したノードは、通常、「コインベーストランザクション」と呼ばれる新規トランザクションを用いて報酬が与えられ、新規トランザクションは、ある金額のデジタル資産、すなわち、いくつかのトークンを分配する。無効なトランザクションの検出および拒絶は、ネットワークのエージェントとして働く競合するノードのアクションによって執行され、不正行為を報告および遮断することが奨励される。情報の広範な発行は、ユーザがノードの実行を継続的に監査することを可能にする。単なるブロックヘッダの発行が、ブロックチェーンの進行中の完全性を参加者が保証することを可能にする。

【0006】

「出力ベースの」モデル(UTXOベースのモデルと呼ばれることがある)では、所与のトランザクションのデータ構造は、1つまたは複数の入力および1つまたは複数の出力を備える。任意の消費可能な出力は、トランザクションの前進しているシーケンスから導出可能な、ある金額のデジタル資産を指定する要素を備える。消費可能な出力は、UTXO(「未消費トランザクション出力」)と呼ばれることがある。出力は、出力の将来の償還に対する条件を指定するロックスクリプトをさらに備えてよい。ロックスクリプトは、デジタルトークンまたはデジタル資産を有効化および移転するために必要な条件を規定する述語である。(コインベーストランザクション以外の)トランザクションの各入力は、先行するトランザクションの中のそのような出力へのポインタ(すなわち、参照)を備え、指し示された出力のロックスクリプトをロック解除するためのロック解除スクリプトをさらに備えてよい。そのため、1対のトランザクションを考慮に入れると、それらを第1のトランザクションおよび第2のトランザクション(または「ターゲット」トランザクション)と呼ぶ。第1のトランザクションは、ある金額のデジタル資産を指定し、および出力をロック解除することの1つまたは複数の条件を規定するロックスクリプトを備える、少なくとも1つの出力を備える。第2の、ターゲットトランザクションは、第1のトランザクションの出力へのポインタ、および第1のトランザクションの出力をロック解除するためのロック解除スクリプトを備える、少なくとも1つの入力を備える。

【0007】

そのようなモデルでは、第2の、ターゲットトランザクションが、ブロックチェーンの中で伝搬および記録されるべきブロックチェーンネットワークへ送られるとき、各ノードにおいて適用される、有効性に対する基準のうちの1つは、第1のトランザクションのロックスクリプトの中で規定された1つまたは複数の条件のすべてをロック解除スクリプトが満たすことである。別の基準は、第1のトランザクションの出力が別のもっと前の有効なトランザクションによってすでに償還されていないことである。これらの条件のうちのいずれかに従って無効なターゲットトランザクションを見つける任意のノードは、それを(有効だが、場合によっては無効なトランザクションを登録するためのトランザクションとして)伝搬させることも、ブロックチェーンの中に記録されるべき新たなブロックの中にそれを含めることもしない。

【発明の概要】

【発明が解決しようとする課題】

【0008】

本明細書では、UTXOベースのトランザクションモデルを利用するブロックチェーンが2次データチェーンのキャリアとして使用され得ることが認識される。いくつかの例では、2次データチェーンは2次ブロックチェーン(すなわち、キャリアとして働くブロックチェーン以外のブロックチェーン)であってよい。このことは、たとえば、ハッシュパワーの欠如に起因して、既存の2次ブロックチェーンまたはそのネットワークが成長できなくなる場合に有益であり得る。たとえば、2次ネットワークのユーザによって保持されるデジタル通貨のユニットは、成長可能なコアブロックチェーン内に2次ブロックチェーンを埋め込むことによって保存されてよい。代替のシナリオは、プライベートブロックチェーンの所有者がデータ完全性の証明を必要とする場合であり得る。このことは、それの未加工の形態で、またはデータの不変のレコードとしての公的なコアブロックチェーン内での暗号委託として、プライベートデータを埋め込むことによって達成され得る。他の例では、2次データチェーンは非ブロックチェーン関連であってよく、一般に、チェーン、たとえば、アペンド専用ログとして、データが配置される、任意のデータ構造であってよい。そのようなデータ構造の例は、通信チェーン(たとえば、電子メールまたはテキストメッセージチェーン)、移動順序型のゲーム(たとえば、チェス)などを含む。2次データチェーンのキャリアとしてコアブロックチェーンを使用することによって、2次チェーンは、特に、データの不変性、追跡可能性、透明性、およびセキュリティを含む、コアブロックチェーンの利点を継承する。

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

【0009】

本明細書で開示する一態様によれば、コアブロックチェーン上にデータチェーンを埋め込むためにマルチレベル(ML:multi-level)データチェーンプロトコルを使用するコンピュータ実装方法が提供され、方法は、MLブロックプロデューサによって実行され、1つまたは複数のMLトランザクションを取得するステップであって、各MLトランザクションが、1つまたは複数のそれぞれのキャリアペアを備え、各キャリアペアが、それぞれの入力およびそれぞれの出力を備え、各それぞれの出力が、データチェーンに関連付けられたそれぞれのデータを備え、各それぞれの入力が、それぞれのキャリアペアに署名するそれぞれの署名を備える、ステップと、MLデータチェーンの第1のMLブロックを生成するステップであって、第1のMLブロックが、コアブロックチェーントランザクションであり、a)取得された1つまたは複数のMLトランザクションのそれぞれのキャリアペアであって、キャリアペアごとに、それぞれの入力のそれぞれの位置インデックスが、それぞれの出力のそれぞれの位置インデックスに対応する、それぞれのキャリアペア、およびb)第1のチェーン出力であって、後続のMLブロックのそれぞれのチェーン入力によって消費されるためのものである、第1のチェーン出力を備える、ステップと、第1のMLブロックをコアブロックチェーン上に記録させるステップとを備える。

【0010】

「マルチレベル」(ML:multi-level)プロトコルという用語は、下位のコアブロックチェーン(すなわち、第1のレベルのブロックチェーン)の上方への(すなわち、それを使用する)データのより高いレベルのチェーンとして2次データチェーンを埋め込むプロトコルを指す。そのデータチェーンは、第1のレベルのブロックチェーンのコアトランザクションの形態でデータのブロック(すなわち、MLブロック)を備えるので、第2のレベルのブロックチェーンとして解釈されてよい。2次データチェーン自体がブロックチェーン(たとえば、通信チェーン)でない例においてさえ、2次データが、MLブロックと呼ばれるブロックを使用してコアブロックチェーン上にやはり構造化される(すなわち、埋め込まれる)ことに、留意されたい。MLプロトコルによれば、MLブロックはコアブロックチェーントランザクションである。MLブロックは、1つまたは複数のMLトランザクションに基づいて構築される。MLトランザクションは、1つまたは複数のキャリアペアを備える。キャリアペアは入力出力ペアであり、ここで、出力は2次チェーンの埋込みデータを備え、そうした埋込みデータは、暗号化された形態をなしてもなさなくてもよく、たとえば、ハッシュ関数を使用してハッシュされてもされなくてもよい。各キャリアペアは、それぞれの署名を使用して署名される。すなわち、単一の署名が単一のキャリアペアに署名する。このことは、署名を無効化することなくMLブロックの中にキャリアペアが配置されることを可能にする。MLブロックはまた、MLブロックを一緒にチェーン結合するために使用されるチェーン入力およびチェーン出力を含み、そのことは、コアブロックチェーンのブロックヘッダがどのようにコアブロックを一緒にチェーン結合するために使用されるのかと類似である。MLトランザクションがキャリアペアからなってよく、その場合、MLトランザクションがMLブロックの一部を形成してよいことに留意されたい。他の例では、MLトランザクションは、キャリアペアが抽出されMLブロックの中に配置され得るMLブロックの中に含められることを必要とされない、他のデータを含んでよい。

【0011】

要約すると、コアブロックチェーントランザクションのチェーンは、MLデータチェーン(または、MLブロックチェーン)のブロックのチェーンとして働く。各MLブロックは、1つまたは複数のキャリアペアを含み、ここで、各キャリアペアは、2次データチェーン、たとえば、2次ブロックチェーンの埋込みデータを含む。

【0012】

本開示の実施形態の理解を支援するために、またそのような実施形態がどのように効果に注ぎ込まれ得るのかを示すために、単に例として添付図面への参照が行われる。

【図面の簡単な説明】

【0013】

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

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

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

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

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

【図5】マルチレベルブロックチェーンプロトコルを実施するための例示のシステムを概略的に示す図である。

【図6】例示のコアブロックチェーントランザクションの概略図である。

【図7】S|ACP署名によって署名されるトランザクション情報が特定の入力の消費を許可するためにどのように使用されるのかを概略的に示す図である。

【図8】a)UTXOベースのトランザクション、b)トランザクション入力、およびc)トランザクション出力のための、例示のシリアル化フォーマットを概略的に示す図である。

【図9】例示のコアブロックチェーンブロックの構造およびブロックチェーンの中の以前のブロックへの関係を概略的に示す図である。

【図10】埋め込まれたTxデータがOP_RETURNコードの後に含まれるS|ACP署名された入力出力キャリアペアを含むMLトランザクションの一例を概略的に示す図である。

【図11】OP_RETURN出力の中にブロック情報が埋め込まれるMLブロックの一例を概略的に示す図である。

【図12】MLプロトコルにおけるステップの例示のセットを示すシーケンス図である。

【図13】2次ブロックチェーントランザクションの一例を示す図である。

【図14】2次ブロックチェーントランザクションを埋め込むMLトランザクションの一例を示す図である。

【図15】2次ブロックチェーンのコインベーストランザクションの一例を示す図である。

【図16】候補MLブロックの一例を示す図である。

【図17】コアブロックチェーン上のそれらの均等物へのMLブロックの要素のマッピングを示す図である。

【図18】UTXOチェーンがMLブロックをリンクする概略図である。

【図19】例示のブロックプールプロトコルを概略的に示す図である。

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

【0014】

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

【0015】

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

【0016】

ブロックチェーン150は、データ151のブロックのチェーンを備え、ブロックチェーン150のそれぞれのコピーは、分散ネットワークまたはブロックチェーンネットワーク106の中の複数のブロックチェーンノード104の各々において維持される。上述のように、ブロックチェーン150のコピーを維持することとは、必ずしも全体的にブロックチェーン150を記憶することを意味するとは限らない。代わりに、ブロックチェーン150は、各ブロックチェーンノード150が各ブロック151のブロックヘッダ(以下で説明する)を記憶する限り、データからプルーニングされてよい。チェーンの中の各ブロック151は、1つまたは複数のトランザクション152を備え、トランザクションとは、このコンテキストでは、ある種類のデータ構造を指す。そのデータ構造の性質は、トランザクションモデルまたはトランザクション方式の一部として使用されるトランザクションプロトコルのタイプに依存する。所与のブロックチェーンは、全体にわたって、ある特定のトランザクションプロトコルを使用する。1つの一般のタイプのトランザクションプロトコルでは、各トランザクション152のデータ構造は、少なくとも1つの入力および少なくとも1つの出力を備える。各出力は、特性としてデジタル資産の数量を表す金額を指定し、特性の一例は、出力が暗号学的にロックされるユーザ103である(ロック解除され、それによって、償還すなわち消費されるために、そのユーザの署名または他の解を必要とする)。各入力は、先行するトランザクション152の出力を戻って指し示し、それによって、トランザクションをリンクする。

【0017】

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

【0018】

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

【0019】

所与の現在のトランザクション152jにおいて、その(または、各)入力は、トランザクションのシーケンスの中の先行するトランザクション152iの出力を参照するポインタを備え、現在のトランザクション152jの中でこの出力が償還すなわち「消費」されることになることを指定する。概して、先行するトランザクションは、順序付きセット154または任意のブロック151の中の任意のトランザクションであり得る。先行するトランザクション152iは、現在のトランザクション152jが作成され、さらにはネットワーク106へ送られる時間において、必ずしも存在することを必要とするとは限らないが、現在のトランザクションが有効となるために、先行するトランザクション152iが存在し有効化される必要がある。したがって、本明細書における「先行する」とは、必ずしも時間的なシーケンスの中で作成するかまたは送ることの時間とは限らない、ポインタによってリンクされた、論理シーケンスの中の先行要素(predecessor)を指し、したがって、そのことは、順序が狂ってトランザクション152i、152jが作成されるかまたは送られることを必ずしも除外するとは限らない(オーファン(orphan)トランザクションにおける以下の説明を参照)。先行するトランザクション152iは、先行者(antecedent)トランザクションまたは先行要素トランザクションと等しく呼ばれることがある。

【0020】

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

【0021】

ビットコインなどの出力ベースのトランザクションプロトコルによれば、個々のユーザまたは団体などのパーティ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のネットワーク全体にわたって伝搬される。

【0022】

出力ベースのモデルでは、所与の出力(たとえば、UTXO)が割り当てられる(たとえば、消費される)かどうかの規定は、それがまだ、前方に位置する別のトランザクション152jの入力によって、ブロックチェーンノードプロトコルに従って有効に償還されているかどうかである。トランザクションが有効となるための別の条件は、それが償還することを試みる先行するトランザクション152iの出力が、すでに別のトランザクションによって償還されていないことである。再び、有効でない場合、トランザクション152jは、(無効としてフラグ付けされ警告のために伝搬されない限り)伝搬されないか、またはブロックチェーン150の中に記録されない。このことは、同じトランザクションの出力を取引人が2回以上割り当てようとする二重消費に対して保護する。勘定ベースのモデルは、一方、勘定残高を維持することによって二重消費に対して保護する。再び、トランザクションの規定された順序があるので、任意の1つの時間において勘定残高は規定された単一の状態を有する。

【0023】

トランザクションを有効化することに加えて、ブロックチェーンノード104はまた、通常はマイニングと呼ばれるプロセスの中でトランザクションのブロックを作成すべき最初となるために競争し、マイニングは「プルーフオブワーク」によってサポートされる。ブロックチェーンノード104において、ブロックチェーン150上に記録されるブロック151の中にまだ出現していない有効なトランザクションの順序付きプール154に、新規トランザクションが加えられる。ブロックチェーンノードは、次いで、暗号パズルを解くことを試みることによって、トランザクション154の順序付きセットからトランザクション152の新たな有効なブロック151を組み立てるために競争する。通常、このことは、ナンスが保留トランザクション154の順序付きプールの表記に連結およびハッシュされると、次いで、ハッシュの出力が所定の条件を満たすような、「ナンス」値を求めて探索することを備える。たとえば、所定の条件とは、ハッシュの出力がいくつかの既定の数の先頭に立つ0を有することであってよい。これがある特定のタイプのプルーフオブワークパズルにすぎず、他のタイプが除外されないことに留意されたい。ハッシュ関数の特性とは、それの入力に関して予測できない出力をハッシュ関数が有することである。したがって、この探索は、ブルートフォースのみによって実行されることが可能であり、したがって、パズルを解こうとしている各ブロックチェーンノード104において、かなりの量の処理リソースを費やす。

【0024】

パズルを解くべき第1のブロックチェーンノード104は、このことをネットワーク106に告知し、証明として解を提供し、その証明は、次いで、ネットワークの中の他のブロックチェーンノード104によって容易にチェックされ得る(ハッシュに解が与えられると、その解がハッシュの出力に条件を満足させることをチェックすることは簡単である)。第1のブロックチェーンノード104は、ブロックを受け入れ、したがって、プロトコル規則を執行する他のノードのしきい値コンセンサスにブロックを伝搬させる。トランザクション154の順序付きセットが、次いで、ブロックチェーンノード104の各々によって、新たなブロック151としてブロックチェーン150の中に記録されるようになる。チェーンの中の以前に作成されたブロック151n-1を新たなブロック151nが戻って指し示すことにも、ブロックポインタ155が割り当てられる。プルーフオブワーク解を作成するために必要とされる、たとえば、ハッシュの形態をなす、著しい量の取組みが、ブロックチェーンプロトコルの規則に従うべき、第1のノード104の意図をシグナリングする。そのような規則は、さもなければ二重消費として知られる、以前に有効化されたトランザクションと同じ出力をそれが割り当てる場合、トランザクションを有効として受け入れないことを含む。作成されると、ブロック151は、ブロックチェーンネットワーク106の中のブロックチェーンノード104の各々において認識および維持されるので修正され得ない。ブロックポインタ155はまた、連続した順序をブロック151に課する。ネットワーク106の中の各ブロックチェーンノード104において、順序付きブロックの中にトランザクション152が記録されるので、したがって、このことはトランザクションの不変の公的な台帳を提供する。

【0025】

任意の所与の時間においてパズルを解くために競争する異なるブロックチェーンノード104が、それらがいつ解を求めて探索し始めたのかまたはトランザクションが受信された順序に応じて、任意の所与の時間においてまだ発行されていないトランザクション154のプールの異なるスナップショットに基づいて、そのことを行っている場合があることに留意されたい。それらのそれぞれのパズルを最初に解く人は誰でも、どのトランザクション152が次の新たなブロック151nの中にどの順序で含められるのかを規定し、未発行トランザクションの現在のプール154が更新される。ブロックチェーンノード104は、次いで、未発行トランザクション154の新たに規定された順序付きプールからブロックを作成するために競争することを継続する等々である。2つのブロックチェーンノード104が互いの極めて短い時間内にそれらのパズルを解き、その結果、ブロックチェーンの矛盾する見方がノード104間で伝搬させられる場合である、起こり得る任意の「フォーク」を解決するためのプロトコルも存在する。要するに、最も長く伸びる、フォークのどのプロングも、最終的なブロックチェーン150になる。同じトランザクションが両方のフォークの中に出現するので、このことがネットワークのユーザまたはエージェントに影響を及ぼさないはずであることに留意されたい。

【0026】

ビットコインブロックチェーン(および、ほとんどの他のブロックチェーン)によれば、新たなブロック104を首尾よく構築するノードは、(ある金額のデジタル資産を、あるエージェントまたはユーザから別のエージェントまたはユーザに移転する、エージェント間またはユーザ間のトランザクションとは反対に)規定された追加の数量のデジタル資産を分配する、新たな特別な種類のトランザクションの中に、受け入れられた追加の金額のデジタル資産を新たに割り当てるための能力が与えられる。この特別なタイプのトランザクションは、通常、「コインベーストランザクション」と呼ばれるが、「開始トランザクション(initiation transaction)」または「生成トランザクション(generation transaction)」と呼ばれることもある。それは、通常、新たなブロック151nの最初のトランザクションを形成する。この特別なトランザクションが後で償還されることを可能にするプロトコル規則に従うために、プルーフオブワークは、新たなブロックを構築するノードの意図をシグナリングする。ブロックチェーンプロトコル規則は、この特別なトランザクションが償還され得る前に、償還期間、たとえば、100個のブロックを必要とすることがある。しばしば、通常の(非生成)トランザクション152も、そのトランザクションがその中で発行されたブロック151nを作成したブロックチェーンノード104にさらに報酬を与えるために、それの出力のうちの1つの中で追加のトランザクション料金を指定する。この料金は、通常、「トランザクション料金」と呼ばれ、以下で説明される。

【0027】

トランザクション有効化および発行にリソースが関与することに起因して、一般に、ブロックチェーンノード104の少なくとも各々は、1つまたは複数の物理サーバユニットを備えるサーバ、またはさらにはデータセンター全体の形態を取る。しかしながら、原理上、任意の所与のブロックチェーンノード104が、一緒にネットワーク化されたユーザ端末またはユーザ端末のグループの形態を取ることができる。

【0028】

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

【0029】

消費するユーザの役割における複数のパーティ103の各々のコンピュータ機器102も、ネットワーク101に接続される。これらのユーザはブロックチェーンネットワーク106と相互作用してよいが、トランザクションを有効化することまたはブロックを構築することに参加しない。これらのユーザまたはエージェント103のうちのいくつかは、トランザクションにおいて送出者および受信者として働くことがある。他のユーザは、必ずしも送出者または受信者として働くことなくブロックチェーン150と相互作用してよい。たとえば、いくつかのパーティは、ブロックチェーン150のコピーを記憶する(たとえば、ブロックチェーンノード104からブロックチェーンのコピーを取得した)記憶エンティティとして働いてよい。

【0030】

パーティ103の一部または全部は、異なるネットワーク、たとえば、ブロックチェーンネットワーク106の上部に重ねられたネットワークの一部として接続されてよい。ブロックチェーンネットワークのユーザ(しばしば、「クライアント」と呼ばれる)は、ブロックチェーンネットワーク106を含むシステムの一部であると言われてよいが、これらのユーザは、ブロックチェーンノードの必要とされる役割を実行しないのでブロックチェーンノード104ではない。代わりに、各パーティ103はブロックチェーンネットワーク106と相互作用してよく、それによって、ブロックチェーンノード106に接続すること(すなわち、それと通信すること)によってブロックチェーン150を利用してよい。2つのパーティ103およびそれらのそれぞれの機器102、すなわち、ファーストパーティ103aおよびその人のそれぞれのコンピュータ機器102a、ならびにセカンドパーティ103bおよびその人のそれぞれのコンピュータ機器102bが、例示のために図示される。はるかに多くのそのようなパーティ103およびそれらのそれぞれのコンピュータ機器102が存在しシステム100に参加していることがあるが、便宜上、それらが図示されないことが理解されよう。各パーティ103は、個人または団体であってよい。純粋に例として、ファーストパーティ103aは本明細書でアリスと呼ばれ、セカンドパーティ103bはボブと呼ばれるが、このことが限定的でなく、アリスまたはボブへの本明細書における任意の参照が、それぞれ、「ファーストパーティ」および「セカンドパーティ」と置き換えられてよいことが、諒解されよう。

【0031】

各パーティ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つまたは複数の他のネットワーク化リソースを備えてよい。

【0032】

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

【0033】

クライアントアプリケーション105は、少なくとも「金銭管理(wallet)」機能を備える。これは2つの主な機能性を有する。これらのうちの一方は、次いで、ブロックチェーンノード104のネットワーク全体にわたって伝搬され、それによって、ブロックチェーン150の中に含められるべき、トランザクション152を、それぞれのパーティ103が作成し、許可し(たとえば、署名し)、1つまたは複数のビットコインノード104へ送ることを可能にすることである。他方は、その人が現在所有するデジタル資産の金額をそれぞれのパーティに戻って報告することである。出力ベースのシステムでは、この第2の機能性は、当該のパーティに属するブロックチェーン150全体にわたって散乱される様々なトランザクション152の出力の中で規定された金額を照合することを備える。

【0034】

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

【0035】

各コンピュータ機器102上のクライアントアプリケーションまたはソフトウェア105のインスタンスは、ネットワーク106のブロックチェーンノード104のうちの少なくとも1つに動作可能に結合される。このことは、クライアント105の金銭管理機能がトランザクション152をネットワーク106へ送ることを可能にする。クライアント105はまた、それぞれのどのパーティ103が受信者であるのかを、任意のトランザクションのためのブロックチェーン150に照会するために、ブロックチェーンノード104に接触することができる(または、実施形態では、ブロックチェーン150は、部分的にそれの公的な視界を通じてトランザクションの中に信用を与える公的な機構であるので、ブロックチェーン150の中の他のパーティのトランザクションを確かに検査する)。各コンピュータ機器102上の金銭管理機能は、トランザクションプロトコルに従ってトランザクション152を編成し送るように構成される。上記で提示したように、各ブロックチェーンノード104は、ブロックチェーンノードプロトコルに従ってトランザクション152を有効化し、およびブロックチェーンネットワーク106全体にわたってそれらを伝搬させるためにトランザクション152を転送するように構成された、ソフトウェアを動作させる。トランザクションプロトコルおよびノードプロトコルは互いに対応し、所与のトランザクションプロトコルは、所与のトランザクションモデルを一緒に実装して、所与のノードプロトコルとともに進む。同じトランザクションプロトコルが、ブロックチェーン150の中のすべてのトランザクション152に対して使用される。同じノードプロトコルが、ネットワーク106の中のすべてのノード104によって使用される。

【0036】

所与のパーティ103、たとえば、アリスは、ブロックチェーン150の中に含められるべき新規トランザクション152jを送ることを望むとき、(アリスのクライアントアプリケーション105の中の金銭管理機能を使用して)関連するトランザクションプロトコルに従って新規トランザクションを編成する。アリスは、次いで、アリスが接続されている1つまたは複数のブロックチェーンノード104へ、クライアントアプリケーション105からトランザクション152を送る。たとえば、これは、アリスのコンピュータ102に最も良好に接続されているブロックチェーンノード104であり得る。任意の所与のブロックチェーンノード104は、新規トランザクション152jを受信すると、ブロックチェーンノードプロトコルおよびそれのそれぞれの役割に従ってそれを処理する。このことは、新たに受信されたトランザクション152jが「有効」であるためのいくつかの条件を満たすかどうかを最初にチェックすることを備え、そのことの例がより詳細に手短に説明される。いくつかのトランザクションプロトコルでは、有効化のための条件は、トランザクション152の中に含まれるスクリプトによって、トランザクションごとに構成可能であってよい。代替として、条件は、単にノードプロトコルの内蔵機能であり得るか、またはスクリプトとノードプロトコルとの組合せによって規定され得る。

【0037】

新たに受信されたトランザクション152jが有効と見なされるためのテストをパスする条件において(すなわち、それが「有効化」される条件において)、トランザクション152jを受信する任意のブロックチェーンノード104は、そのブロックチェーンノード104において維持される、トランザクション154の順序付きセットに、有効化された新たなトランザクション152を加える。さらに、トランザクション152jを受信する任意のブロックチェーンノード104は、有効化されたトランザクション152をネットワーク106の中の1つまたは複数の他のブロックチェーンノード104に前方へ伝搬させる。各ブロックチェーンノード104は同じプロトコルを適用するので、次いで、トランザクション152jが有効であることを想定すると、このことは、それがまもなく全体的なネットワーク106全体にわたって伝搬されることを意味する。

【0038】

所与のブロックチェーンノード104において維持される保留トランザクション154の順序付きプールに入ることが許されると、そのブロックチェーンノード104は、新規トランザクション152を含む154のそれらのそれぞれのプールの最新のバージョンにおいてプルーフオブワークパズルを解くことを競合し始める(他のブロックチェーンノード104が、トランザクション154の異なるプールに基づいてパズルを解こうとしている場合があるが、そこに最初に達する人は誰でも、最新のブロック151の中に含められるトランザクションのセットを規定することを、想起されたい。最終的に、ブロックチェーンノード104は、アリスのトランザクション152jを含む順序付きプール154の一部に対してパズルを解く)。新規トランザクション152jを含むプール154に対してプルーフオブワークが行われていると、それは不変にブロックチェーン150の中のブロック151のうちの1つの一部になる。各トランザクション152は、もっと前のトランザクションに戻るポインタを備え、そのため、トランザクションの順序も不変に記録される。

【0039】

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

【0040】

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

【0041】

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

【0042】

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

【0043】

たとえば、アリス103aは、当該の、ある金額のデジタル資産をボブ103bに移転するトランザクション152jを作成することを望む。図2では、アリスの新規トランザクション152jは「Tx₁」とラベル付けされる。それは、シーケンスの中の先行するトランザクション152iの出力203の中でアリスにロックされている、ある金額のデジタル資産を取り、このうちの少なくともいくらかをボブに移転する。図2では、先行するトランザクション152iは「Tx₀」とラベル付けされる。Tx₀およびTx₁は任意のラベルにすぎない。それらは必ずしも、Tx₀がブロックチェーン151の中の最初のトランザクションであることも、Tx₁がプール154の中のすぐ次のトランザクションであることも、意味するとは限らない。Tx₁は、アリスにロックされた未消費出力203を依然として有する任意の先行する(すなわち、先行者)トランザクションを戻って指し示すことができる。

【0044】

アリスがアリスの新規トランザクションTx₁を作成する時間において、または少なくともアリスがそれをネットワーク106へ送る時間までに、先行するトランザクションTx₀が、すでに有効化されていてよく、ブロックチェーン150のブロック151の中に含められていてよい。先行するトランザクションTx₀は、その時間においてすでにブロック151のうちの1つの中に含められていることがあるか、または依然として順序付きセット154の中で待っていることがあり、その場合、新たなブロック151の中にまもなく含められる。代替として、Tx₀およびTx₁は、作成されることおよび一緒にネットワーク106へ送られることが可能であるか、またはノードプロトコルが「オーファン」トランザクションをバッファリングすることを許容する場合、Tx₁の後にTx₀が送られることさえ可能である。トランザクションのシーケンスのコンテキストにおいて本明細書で使用する「先行する(preceding)」および「後続の(subsequent)」という用語は、トランザクションの中で指定されるトランザクションポインタによって規定されるような、シーケンスの中のトランザクションの順序を指す(どのトランザクションが他のどのトランザクションを戻って指し示すのかなど)。それらは、「先行要素」および「後継者」、または「先行者」および「子孫(descendant)」、「親(parent)」、および「子(child)」などに等しく置き換えられる場合がある。そのことは、それらが作成され、ネットワーク106へ送られ、または任意の所与のブロックチェーンノード104に到着する順序を、必ずしも暗示するとは限らない。とはいえ、先行するトランザクション(先行者トランザクションまたは「親」)を指し示す後続のトランザクション(子孫トランザクションまたは「子」)は、親トランザクションが有効化されるまで、また親トランザクションが有効化されない限り、有効化されない。それの親の前にブロックチェーンノード104に到着する子は、オーファンと見なされる。ノードプロトコルおよび/またはノード挙動に応じて、オーファンは廃棄されてよく、または親を待つためのいくらかの時間にわたってバッファリングされてもよい。

【0045】

先行するトランザクションTx₀の1つまたは複数の出力203のうちの1つは、ここではUTXO₀とラベル付けされる特定のUTXOを備える。各UTXOは、UTXOによって表されるある金額のデジタル資産を指定する値、および後続のトランザクションが有効化されるために、したがって、UTXOが首尾よく償還されるために、後続のトランザクションの入力202の中のロック解除スクリプトによって満たされなければならない条件を規定するロックスクリプトを備える。通常、ロックスクリプトは、特定のパーティ(それがその中に含まれるトランザクションの受益者)に金額をロックする。すなわち、ロックスクリプトは、通常、後続のトランザクションの入力の中のロック解除スクリプトが、先行するトランザクションがロックされるパーティの暗号署名を備える条件を備える、ロック解除条件を規定する。

【0046】

ロックスクリプト(scriptPubKeyとも呼ばれる)は、ノードプロトコルによって認識されるドメイン固有の言語で書かれたコードの断片である。そのような言語の特定の例は、ブロックチェーンネットワークによって使用される「Script」(大文字のS)と呼ばれる。ロックスクリプトは、トランザクション出力203を消費するためにどんな情報が必要とされるのか、たとえば、アリスの署名の要件を指定する。ロック解除スクリプトは、トランザクションの出力の中に出現する。ロック解除スクリプト(scriptSigとも呼ばれる)は、ロックスクリプト基準を満足するのに必要とされる情報を提供するドメイン固有の言語で書かれたコードの断片である。たとえば、それはボブの署名を含んでよい。ロック解除スクリプトは、トランザクションの入力202の中に出現する。

【0047】

そのため、図示の例では、Tx₀の出力203の中のUTXO₀は、UTXO₀が償還されるために(厳密には、UTXO₀を償還することを試みる後続のトランザクションが有効となるために)アリスの署名Sig P_Aを必要とするロックスクリプト[Checksig P_A]を備える。[Checksig P_A]は、アリスの公開鍵-秘密鍵ペアからの公開鍵P_Aの表記(すなわち、ハッシュ)を含む。Tx₁の入力202は、(たとえば、実施形態ではトランザクションTx₀全体のハッシュである、それのトランザクションID、TxID₀によって)Tx₁を戻って指し示すポインタを備える。Tx₁の入力202は、Tx₀の任意の他の可能な出力の間でそれを識別するために、Tx₀内でUTXO₀を識別するインデックスを備える。Tx₁の入力202は、アリスが鍵ペアからのアリスの秘密鍵をデータの既定の部分(暗号法では「メッセージ」と呼ばれることがある)に適用することによって作成される、アリスの暗号署名を備えるロック解除スクリプト<Sig P_A>をさらに備える。有効な署名を提供するためにアリスによって署名される必要があるデータ(すなわち、「メッセージ」)は、ロックスクリプトによって、もしくはノードプロトコルによって、またはこれらの組合せによって規定されてよい。

【0048】

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

【0049】

公開-秘密暗号法による認証の詳細は当業者に熟知されよう。基本的に、アリスがアリスの秘密鍵を使用してメッセージに署名しており、次いで、アリスの公開鍵および平文でのメッセージが与えられる場合、ノード104などの別のエンティティは、メッセージがアリスによって署名されているにちがいないことを認証することができる。署名することは、通常、メッセージをハッシュすること、そのハッシュに署名すること、およびこれをメッセージ上に署名としてタグ付けすることを備え、したがって、公開鍵の任意の保持者が署名を認証することを可能にする。したがって、データの特定の断片、もしくはトランザクションの一部などに署名することへの、本明細書における任意の参照は、実施形態において、データのその断片またはトランザクションの一部のハッシュに署名することを意味することができることに留意されたい。

【0050】

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

【0051】

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

【0052】

UTXOベースのトランザクションモデルでは、所与のUTXOが全体として消費される必要があることに留意されたい。UTXOは、別の小部分が消費されながらUTXOの中で規定される金額の小部分を消費されたものとして「後に残して行く」ことができない。ただし、UTXOからの金額は、次のトランザクションの複数の出力の間で分割され得る。たとえば、Tx₀の中のUTXO₀の中で規定される金額は、Tx₁の中の複数のUTXOの間で分割され得る。したがって、アリスは、UTXO₀の中で規定される金額のすべてをボブに与えることを希望しない場合、Tx₁の第2の出力の中でアリス自身に釣銭を与えるために、または別のパーティに支払うために、その残りを使用することができる。

【0053】

実際には、アリスはまた、通常、アリスのトランザクション104をブロック151の中に首尾よく含めるビットコインノード104のための料金を含める必要がある。アリスがそのような料金を含めない場合、Tx₀はブロックチェーンノード104によって拒絶されてよく、したがって、技術的には有効であるが、伝搬されなくてよくブロックチェーン150の中に含められなくてよい(ノードプロトコルは、それらが希望しない場合、トランザクション152を受け入れることをブロックチェーンノード104に強制しない)。いくつかのプロトコルでは、トランザクション料金は、それ自体の別個の出力203を必要としない(すなわち、別個のUTXOを必要としない)。代わりに、入力202によって指し示される総額と所与のトランザクション152の出力203の中で指定される総額との間の任意の差分が、トランザクションを発行するブロックチェーンノード104に自動的に与えられる。たとえば、UTXO₀へのポインタはTx₁への入力でしかなく、Tx₁は1つの出力UTXO₁しか有しない。UTXO₀の中で指定されるデジタル資産の金額が、UTXO₁の中で指定される金額よりも大きい場合、UTXO₁を含むブロックを作成するためのプルーフオブワーク競争に勝利するノード104によって差分が割り当てられてよい。しかしながら、代替または追加として、トランザクション料金が、トランザクション152のUTXO203のうちのそれ自体の1つの中で明示的に指定され得ることが、必ずしも除外されるとは限らない。

【0054】

アリスおよびボブのデジタル資産は、ブロックチェーン150の中のどこかで任意のトランザクション152の中で彼らにロックされたUTXOからなる。したがって、通常、所与のパーティ103の資産は、ブロックチェーン150全体にわたって様々なトランザクション152のUTXO全体にわたって散乱される。所与のパーティ103の合計残高を規定する、ブロックチェーン150の中のどこかに記憶された1つの数はない。それぞれのパーティにロックされており前方に位置する別のトランザクションの中でまだ消費されていないすべての様々なUTXOの値を一緒に照合することは、クライアントアプリケーション105の中の金銭管理機能の役割である。それは、ビットコインノード104のうちのいずれかにおいて記憶されるようなブロックチェーン150のコピーを照会することによって、このことを行うことができる。

【0055】

スクリプトコードが、しばしば、概略的に(すなわち、厳密な言語を使用せずに)表されることに留意されたい。たとえば、特定の機能を表すために動作コード(オペコード)を使用してよい。「OP_...」は、Script言語の特定のオペコードを指す。一例として、OP_RETURNは、ロックスクリプトの冒頭においてOP_FALSEに先行されるとき、トランザクション内にデータを記憶できるトランザクションの消費不可能な出力を作成し、それによって、ブロックチェーン150の中に不変にデータを記録する、Script言語のオペコードである。たとえば、データは、ブロックチェーンの中に記憶することが望まれる文書を備える場合がある。

【0056】

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

【0057】

ロックスクリプトは、それが通常はそれぞれのトランザクションがロックされるパーティの公開鍵を備えるという事実を参照して、「scriptPubKey」と呼ばれることがある。ロック解除スクリプトは、それが通常は対応する署名を供給するという事実を参照して、「scriptSig」と呼ばれることがある。しかしながら、より一般的には、ブロックチェーン150のすべての適用において、UTXOが償還されるための条件が、署名を認証することを備えることは必須でない。より一般的には、任意の1つまたは複数の条件を規定するためにスクリプト言語が使用され得る。したがって、「ロックスクリプト」および「ロック解除スクリプト」というもっと一般的な用語が好ましいことがある。

【0058】

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

【0059】

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

【0060】

4. クライアントソフトウェア
図3Aは、本開示の方式の実施形態を実施するためのクライアントアプリケーション105の例示の実装形態を示す。クライアントアプリケーション105は、トランザクションエンジン401およびユーザインターフェース(UI)レイヤ402を備える。トランザクションエンジン401は、上記で説明した方式に従って、手短にさらに詳細に説明するように、トランザクション152を編成すること、サイドチャネル301を介してトランザクションおよび/もしくは他のデータを受信しおよび/もしくは送ること、ならびに/またはブロックチェーンネットワーク106を通じて伝搬されるべき1つもしくは複数のノード104へトランザクションを送ることなどの、クライアント105の下位トランザクション関連の機能性を実施するように構成される。本明細書で開示する実施形態によれば、各クライアント105のトランザクションエンジン401は関数403などを備える。

【0061】

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

【0062】

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

【0063】

図3Bは、アリスの機器102a上のクライアントアプリケーション105aのユーザインターフェース(UI)レイヤ402によってレンダリングされてよいUI500の一例のモックアップを与える。類似のUIが、ボブの機器102b上のクライアント105bまたは任意の他のパーティのクライアントによってレンダリングされてよいことが、諒解されよう。

【0064】

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

【0065】

たとえば、UI要素は、異なるオンスクリーンボタン、もしくはメニューの中の異なるオプションなどであってよい、1つまたは複数のユーザ選択可能要素501を備えてよい。ユーザ入力手段は、スクリーン上のUI要素をクリックもしくはタッチすること、または所望のオプションの名称を話すことなどによって、ユーザ103(この場合、アリス103a)がオプションのうちの1つを選択または別のやり方で操作することを、可能にするように配置される(本明細書で使用する「手作業で」という用語が、自動に対して対比をなすことを意図するにすぎず、必ずしも1つまたは複数の手の使用に限定するとは限らないことに、注意されたい)。そのオプションは、ユーザ(アリス)がすることを可能にする。

【0066】

代替または追加として、UI要素は、ユーザがそれを通じてすることができる1つまたは複数のデータエントリフィールド502を備えてよい。これらのデータエントリフィールドは、たとえば、スクリーン上の、ユーザ出力手段を介してレンダリングされ、データは、ユーザ入力手段、たとえば、キーボードまたはタッチスクリーンを通じてフィールドの中に入力され得る。代替として、たとえば、音声認識に基づいて、データが口頭で受信され得る。

【0067】

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

【0068】

様々なUI要素をレンダリングし、オプションを選択し、データを入力する特定の手段が材料でないことが諒解されよう。これらのUI要素の機能性が、より詳細に手短に説明される。図3に示すUI500が図式化されたモックアップにすぎず、実際には、簡潔のために図示されない1つまたは複数のさらなるUI要素を備えてよいことも諒解される。

【0069】

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

【0070】

したがって、スクリプトエンジン452は、Tx_iのロックスクリプト、およびTx_jの対応する入力からのロック解除スクリプトを有する。たとえば、Tx₀およびTx₁とラベル付けされたトランザクションが図2に示されるが、トランザクションの任意のペアに対して同じことが適用され得る。スクリプトエンジン452は、前に説明したように2つのスクリプトを一緒に動作させ、そのことは、使用されているスタックベースのスクリプト言語(たとえば、Script)に従って、スタック453上にデータを配置すること、およびスタック453からデータを取り出すことを含む。

【0071】

スクリプトを一緒に動作させることによって、スクリプトエンジン452は、ロックスクリプトの中で規定される1つまたは複数の基準をロック解除スクリプトが満たすか- すなわち、ロックスクリプトがその中に含まれる出力をそれが「ロック解除する」か否かを決定する。スクリプトエンジン452は、この決定の結果をプロトコルエンジン451に戻す。スクリプトエンジン452は、対応するロックスクリプトの中で指定される1つまたは複数の基準をロック解除スクリプトが満たすことを決定する場合、結果「真(true)」を戻す。そうでない場合、スクリプトエンジン452は結果「偽(false)」を戻す。

【0072】

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

【0073】

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

【0074】

6. コアブロックチェーン例
このセクションは、本発明の実施形態による、2次データチェーンのキャリアとして使用され得るコア(すなわち、第1のティア)ブロックチェーンの一例を説明する。これらの例が例示目的にすぎないことに留意されたい。

【0075】

6.1 コアトランザクション
トランザクションとは、入力および出力を備えるメッセージであり、入力および出力は、通常、ある金額のデジタル資産の所有権または制御をアドレスのあるセットから別のセットに移転するために使用される。図6は、公開鍵PK₀、PK₁、PK₂によって制御される3つの入力からのある金額のデジタル資産を、公開鍵PK₃、PK₄、PK₅、PK₆によって制御される4つの出力に割り当てるトランザクションを示す。

【0076】

例示のフィールドは以下の情報に対応する。
・バージョン: その値に対する関数または制約を有しない4バイトの整数。
・入力: 以下のサブフィールドを各々が備えるトランザクション入力のアレイ。
〇出力点: 消費されつつあるUTXOを識別する構造であって、以下を備える。
・TxID: 消費されつつあるUTXOに対する32バイトのトランザクション識別子TxID。
・インデックス: 消費されつつあるUTXOに対する4バイトの出力インデックスn。
〇ロック解除スクリプト: 入力のためのロックスクリプトと結合されたとき、コインが消費されるのを有効化するスクリプト。
〇nSeq: 0xFFFFFFFFにデフォルト設定される4バイトの整数。このデフォルト(最大)よりも小さい値は、このトランザクションが最終でなくてよく、同じ入力を消費するとともにもっと大きいシーケンス番号を有するトランザクションによって取って代わられ得ることを示す。すべてのシーケンス番号が最大に設定されているとき、またはロックタイムに達しているとき、トランザクションは最終と見なされる。
・出力: 以下のサブフィールドを各々が備えるトランザクション出力のアレイ。
〇値: 出力の(サトシ(Satoshi)単位での)値を示す8バイトの整数。
〇ロックスクリプト: コインを消費するために満たされなければならない条件を含むロックスクリプト。
・ロックタイム: 0にデフォルト設定される4バイトの整数。0よりも大きい値は遅延を執行し、ブロックの高さ(値<500,000,000の場合)またはさもなければUNIX時間のいずれかによる、トランザクションがブロックの中に含められてよい最も早い時間を示す。

【0077】

6.2 署名
署名を作成するとき、ECDSAアルゴリズムは秘密鍵とメッセージの両方を必要とする。メッセージは、トランザクションの詳細のうちのいくつかに基づいて形成される。署名の検証は以下のことを行う。
・署名が適用されるUTXO入力を消費するための許可、および
・署名メッセージにおけるトランザクション詳細の認証。

【0078】

各署名は、どの入力および出力が署名されるのかを示すsighashフラグを含む。SINGLE|ANYONE CAN PAY (S|ACP)フラグ変形形態は、その消費を署名が有効化する入力および対応するインデックス位置における出力をセキュアにする。図7は、インデックス2における入力の中のロック解除スクリプトに対してS|ACP署名が作成された場合にセキュアにされることになる情報を(灰色で)強調する。S|ACPを使用して署名される入力出力ペアは、他の入力または出力の中の情報に対して制約を置かず、そのため、S|ACP署名された複数のペアは、署名のうちのいずれも無効化されることなく単一のトランザクションの中に一緒に結合され得る。しかしながら、署名された出力よりもその値が大きい入力をペアが有する場合、情報は、(ユーザとネットワークとの間で動作する)悪意のあるインターセプタによって、競合するトランザクションの中にコピーされる場合があり、ここで、割り当てられていない過剰な値がインターセプタのアドレスに再ルーティングされる。したがって、そのようなトランザクションは、しばしば、ネットワークの中の信頼されるノードに直接ルーティングされる。

【0079】

6.3 データ出力
コアブロックチェーントランザクション内で、1つまたは複数の出力は、データペイロードが出力の中に含められることを可能にする1つまたは複数のオペコードを含んでよい。たとえば、OP_RETURNコードは、(文字列の形式で)いくつかのデータが後続してよい。そのオペコードはロック解除スクリプトの末尾に配置され、そのことは、署名有効化プロセスを途絶させることなくトランザクションがデータキャリアの働きをすることを可能にする。ブロックチェーン上でデータトランザクションが発行されるとき、出力の中に埋め込まれるデータの不変のレコードが存在する。OP_RETURNコードは、消費不可能な出力によって作成されるUTXOを表現するOP_FALSE(0)によって先行され得るか(すなわち、UTXOセットの中の完全なノードによって記憶されることを必要としない)、または消費可能なUTXOを作成するためにOP_FALSEを伴わずに使用され得るかのいずれかである。出力の中にデータを含むために、代替のオペコード、たとえば、OP_PUSHおよびOP_DROPが使用されてよい。

【0080】

6.4 バージョン番号
トランザクションバージョン番号は、数を含む4バイトのフィールドである。現在、nVersionフィールドの使用が行われない。したがって、もっと大きいブロックチェーン内でトランザクションのサブセットを識別する際の使用のために、nVersionフィールドが利用可能である。4バイトのフィールドサイズは、2³²個の可能な値を与える。このことは、様々な使用事例に対して、トランザクションバージョンを割り当てるための大きい範囲を提示する。非標準のトランザクションバージョンは、現在のコンセンサス規則の下で無効なトランザクションを表現せず、そのため、デフォルトのノードによって、それらのバージョンにかかわらずすべてのトランザクションに同等に応答する。

【0081】

6.5 シリアル化フォーマット
トランザクションは、図8に示すシリアル化フォーマットを使用して単一のデータ文字列として表され得る。トランザクション全体が(a)に示され、(b)および(c)は、txinおよびtxoutフィールド(それぞれ、入力および出力ごとに、それらのうちの1つが作成される)の拡張されたフォーマットを示す。txinおよびtxoutシリアル化は、それらのインデックス位置の順序で連結され、(a)における完全なトランザクションシリアル化内に配置される。これは、単一のトランザクションについてのすべての情報を含む、可変長の文字列を与える。

【0082】

6.6 コアブロック
ブロックとは、トランザクションのセット、および最長のチェーン(すなわち、最も多くのプルーフオブワークを伴うチェーン)にブロックがどのようにアペンドされるのかに関係するいくつかの追加のフィールドを含む、データ構造である。図9は、例示のブロック構造を示す。例示のブロックのフィールドは以下の通りである。
・ブロックヘッダ: ブロックがどのようにおよびいつマイニングされたのかならびにブロックが含むものについての情報を与える構造。これは以下の6つのサブフィールドを備える。
〇バージョン: ブロック有効化のために使用されるプロトコル規則のセットを示す4バイトの整数。
〇以前のブロックヘッダのハッシュ: 以前のブロックヘッダの32バイトのSHA-256二重ハッシュ。
〇マークルルート: トランザクションのマークルツリーから導出される32バイトのSHA-256二重ハッシュ。
〇タイムスタンプ: ブロックプロデューサがヘッダを生成したUnix時間を符号化する4バイトの整数。
〇難解ターゲット: ブロックがマイニングされるために必要とされるターゲットの難解さを符号化する4バイトの整数。
〇ナンス: 必要とされる難解さのブロックヘッダハッシュを達成するように選ばれる4バイトの整数。
・トランザクション: ブロック内のトランザクションを詳述する構造。以下のものを備える。
〇トランザクションカウント: ブロック内に含まれるトランザクションの数を示す可変長の整数。
〇トランザクションリスト: ブロックの中に含まれるトランザクションの完全なリストに対するトランザクションデータを含む構造。このリストの中の最初のトランザクションは、常にコインベーストランザクションである(以下を参照)。

【0083】

6.7 コインベーストランザクション
通常、ブロックの中の最初のトランザクションは、マイニング報奨を主張するためにブロックプロデューサによって使用されるので、一般にトランザクションのための構造とは異なる。これは、ブロックごとに新たな金額のデジタル資産が生成されるので、「生成」トランザクションとしても知られる。その新たな金額は「ブロック報酬」と呼ばれ、トランザクション出力の中に含められる。コインベーストランザクションデータ構造は、入力を備えるフィールドだけが標準形式とは異なる。コインベーストランザクションは、以下で規定されるように、単一の入力のみを含むことを許容する。
・出力点: この場合には消費されつつあるUTXOがない。したがって、サブフィールドは次の通りである。
〇TxID: 以前の出力点がないことを示す空のフィールド。
〇インデックス: 以前の出力点がないことを示す値0。
・ロック解除スクリプト: 「ロック解除」するためのUTXOがない。このスクリプトは、ここでは2つの要素から形成される。
〇高さ: このトランザクションを含むブロックの、4バイトのブロック高さ。
〇コインベーススクリプト: 最大96バイトまでの任意のデータ。
・nSeq: 0xFFFFFFFFにデフォルト設定される4バイトの整数。

【0084】

7. マルチレベルブロックチェーン
図5は、マルチレベル(ML)ブロックチェーンプロトコルを実施するための例示のシステム500を示す。システム500は、MLトランザクションをMLブロックプロデューサ501にサブミットするように構成された1つまたは複数のエンティティを備える。たとえば、システム500は、MLトランザクションを生成するように各々が構成される1人または複数のユーザ、たとえば、アリス103a、ボブ103b、およびチャーリー103cを備えてよい。システム500が任意の数のユーザを備えてよいことが諒解されよう。MLトランザクションをサブミットするように構成されたエンティティが、人間がデバイスを操作しているという意味でのユーザである必要がないことにも、留意されたい。すなわち、そのようなエンティティのうちの1つまたは複数は、機械、スマート契約などであってよい。MLブロックプロデューサ501は、MLトランザクションを受信および/または生成し、MLブロック、すなわち、コアブロックチェーントランザクションを生成し、MLブロックをコアブロックチェーンネットワーク106にサブミットするように構成される。MLブロックプロデューサ501は、コアブロックチェーンネットワーク106のブロックチェーンノード104であってよい。すなわち、MLブロックプロデューサは、MLブロックとコアブロックチェーンブロック151の両方を生成するように構成されてよい。他の例では、MLブロックプロデューサは、簡易支払い検証(SPV:simplified payment verification)クライアントアプリケーション、すなわち、SPV方法を実施するように構成されたクライアントアプリケーションであってよい。当業者はSPV方法を熟知されよう。MLブロックプロデューサがユーザ、たとえば、アリス103aであってよいことも除外されない。すなわち、ユーザ103はMLトランザクションおよびMLブロックを生成してよい。システム500は、複数のMLブロックプロデューサ501を備えてよい。

【0085】

MLブロックチェーンプロトコルは、コアブロックチェーンのトランザクションを使用して、データチェーン(「2次データチェーン」、(たとえば、2次ブロックチェーン)に関連付けられたデータを構造化する(または埋め込む)ために使用される。2次データチェーンに関連付けられたデータ(たとえば、2次ブロックチェーントランザクション)は、入力出力ペア(キャリアペアと呼ばれる)の出力の中に埋め込まれる。キャリアペアは、署名、たとえば、ECDSA署名を用いて署名される。データは暗号化されてよい。MLブロックプロデューサ501は、その各々が1つまたは複数のキャリアペアを備えるMLトランザクションを取得するように構成される。MLブロックプロデューサ501は、1つまたは複数のMLトランザクションを生成してよい。すなわち、MLブロックプロデューサ501は、キャリアペアの中に埋め込められるべきデータを取得(たとえば、受信または生成)してよい。好ましくは、データはセキュアな通信チャネルを介して通信される。追加または代替として、MLブロックプロデューサ501は、その各々が1つまたは複数のキャリアペアを備える1つまたは複数のMLトランザクションを受信してよい。MLトランザクションは、コアブロックチェーンネットワークを介して通信されてよい。たとえば、MLブロックプロデューサ501は、1人または複数のユーザ103からMLトランザクションを受信してよい。

【0086】

MLブロックプロデューサ501は、取得された(たとえば、受信された)MLトランザクションに基づいてMLブロックを生成するように構成される。すなわち、MLブロックプロデューサ501は、1つまたは複数のMLトランザクションからの1つまたは複数のキャリアペアを使用して(コアブロックチェーントランザクションである)MLブロックを構築するように構成される。各キャリアペアの入力および出力は、それぞれ、MLブロックの入力のリストおよび出力のリストの中の同じ位置を占有する。キャリアペアは、キャリアペア(または、対応するMLトランザクション)が取得された順序に基づいてMLブロックの中に配置されてよい。他の例では、MLブロックの中のキャリアペアの位置は任意に割り当てられてよい。MLブロックは、MLブロックをチェーン結合するために使用されるチェーン出力を含む。チェーン出力は、MLブロックの中で論理的に最初に出現する出力であってよいが、このことは必須ではない。MLブロックはまた、MLブロックチェーンの中の以前のMLブロックのチェーン出力を参照およびロック解除するチェーン入力を含む。再び、チェーン出力は、MLブロックの中で論理的に最初に出現する入力であってよい。

【0087】

MLブロックプロデューサ501は、MLブロックをコアブロックチェーントランザクションとしてコアブロックチェーン上に記録させるように構成される。MLブロックプロデューサ501の能力に応じて、このことは、コアブロックチェーンのコアブロックの中にMLブロックを含めることを伴ってよい。追加または代替として、MLブロックプロデューサ501は、MLブロックをコアブロックチェーンネットワーク106の1つまたは複数のノードにサブミットしてよい。

【0088】

いくつかの例では、MLブロックプロデューサ501は、受信および/または生成されているMLトランザクション(または、MLトランザクションから抽出されるキャリアペア)のプール(すなわち、リスト)を維持(すなわち、メモリの中に記憶)してよい。MLブロックプロデューサ501は、プールからキャリアペアを取ることによってMLブロックを構築してよい。たとえば、MLブロックプロデューサ501は、ある一定の量またはある一定の量未満のキャリアペアをMLブロックの中に含めることを選んでよい。その場合、MLブロックプロデューサ501は、いくつかのキャリアペアを第1のMLブロックの中に配置してよく、第1のMLブロックをコアネットワーク106にサブミットしてよく、次いで、いくつかのキャリアペアを第2のMLブロックの中に配置してよい等々である。言い換えれば、MLブロックプロデューサ501は、キャリアペアのソースとしてプールを使用してMLブロックを構築する。

【0089】

次に、キャリアペアに署名する署名に戻ると、いくつかの例では、署名は、署名がそのキャリアペアにしか署名しないことを示す署名フラグ(「sighashフラグ」と呼ばれることがある)に関連付けられてよい。このことは、署名が署名するメッセージを検証者に気づかせるので、署名を有効化することにとって有用である。署名フラグはコアブロックチェーンプロトコルに依存する。たとえば、一例では、コアブロックチェーンプロトコルは、この目的のために署名フラグ「SINGLE|ANYONECANPAY」を使用してよい。

【0090】

任意選択の特徴として、各MLトランザクションは、キャリアペアを備える無効なコアブロックチェーントランザクションであってよい。すなわち、キャリアペアは、無効なコアブロックチェーントランザクションとしてMLブロックプロデューサ501にサブミットされてよい。このことは、キャリアペアがMLブロックの外側のコアブロックチェーンの中に誤って含められることを防止する。トランザクションを無効化するための1つの技法は、任意のトランザクション料金を含めないことである。別の技法は、署名、したがって、トランザクションが無効であるようなトランザクションを生成した後に、キャリアペアの一部を修正することである。無効なトランザクションを受信すると、MLブロックプロデューサ501は、署名が有効であるような、キャリアペアの中のデータを再修正してよい。このことを行うために、MLブロックプロデューサ501は、キャリアペアのどの部分がどのように修正されているのかを知っていなければならない。このことは、MLプロトコルの一部として合意されてよい。

【0091】

いくつかの例では、各MLブロックはブロックヘッダを備えてよい。ブロックヘッダは、MLブロックのチェーン出力の中に配置されてよい。ブロックヘッダは、MLブロックに関係する1つまたは複数の値を備えてよい。それらの値のうちの1つは、MLブロックの中のキャリアペアに基づいて生成されたマークルルートであってよい。マークルルートは、全体としてキャリアペア(すなわち、対応するマークルツリーの各リーフハッシュがそれぞれのキャリアペアのハッシュである)、またはキャリアペアのデータ出力のみ(すなわち、対応するマークルツリーの各リーフハッシュがそれぞれのキャリアペアのそれぞれのデータ出力のハッシュである)に基づいて、生成されてよい。このことは、マークルツリーが2次データチェーンにしか関連しないことを意味する。ブロックヘッダの中に含まれてよい他の値は、以下のもの、すなわち、MLブロックが作成またはコアネットワーク106にサブミットされたタイムスタンプ、以前のMLブロック(すなわち、現在のMLブロックのチェーン入力によって参照されるMLブロック)のブロックヘッダのハッシュ、難解ターゲットおよびナンス(以下で説明する)、MLブロックの中のキャリアペアの個数などのうちの、いずれか1つまたは複数である。

【0092】

上述のように、MLブロックは、チェーン入力およびチェーン出力を介して一緒にチェーン結合される。すなわち、n番目のMLブロックのチェーン入力は、n-1番目のブロックのチェーン出力を消費し、n+1番目のブロックのチェーン入力は、n番目のブロックのチェーン出力を消費する。いくつかの例では、各チェーン出力はパズルを備えてよく、各チェーン入力は、消費されつつあるチェーン出力のパズルを解く解を備えてよい。パズルはプルーフオブワーク(PoW:proof-of-work)ハッシュパズルであってよい。すなわち、所与のチェーン出力のロックスクリプトは、PoWハッシュパズルを執行するように構成されてよい。このことは、新たなコアブロックをアペンドするためにPoWパズルが解かれることを、いくつかのコアブロックチェーンがどのように必要とするのかに関して類似である。所与のMLブロックのPoWハッシュパズルは、そのMLブロックのブロックヘッダおよびターゲットの難解さの関数である。当業者は、本質的にPoWハッシュパズルおよびターゲットの難解さの概念を熟知されよう。ターゲットの難解さは、あらゆるMLブロックにとって同じであってよく、またはハッシュパズルを解くことをもっと簡単もしくはもっと困難にさせるために変更されてよく、そのことは、MLチェーンに新たなMLブロックが追加され得るレートに影響を及ぼす。より詳細には、所与のMLブロックのPoWハッシュパズルは、そのMLブロックのブロックヘッダハッシュ(すなわち、ブロックヘッダのハッシュ)の関数である。PoWハッシュパズルは、次のMLブロックのチェーン入力からの入力として次のMLブロックのブロックヘッダハッシュを取り、現在のMLブロックのブロックヘッダハッシュを次のMLブロックのブロックヘッダハッシュと結合(たとえば、連結)し、その結合のハッシュが難解ターゲットを満たすかどうかを決定するように構成される。特定のPoWハッシュパズルに応じて、このことは、その結合のハッシュが難解ターゲットよりも小さい(または、それ以下である)かどうかを決定することを備えてよく、難解ターゲットは、それ自体が数である。PoWハッシュパズルは、難解ターゲットが満たされる場合にしかロックスクリプトがロック解除しないように構成される。PoWハッシュパズルを実施するように構成された例示のロックスクリプトが、セクション8において以下でさらに示される。

【0093】

これらの例では、新たなMLブロックを構築するとき、MLブロックプロデューサ501は、以前のMLブロックのPoWパズルによって処理されたときに以前のMLブロックのロックスクリプトによって設定されその中に配置される現在のMLブロックの難解ターゲットを満たす、ブロックヘッダハッシュ(「解」)を見つけなければならない。そのような解を見つけるために、MLブロックプロデューサ501は、ブロックヘッダハッシュが結合およびハッシュされると難解ターゲットが満たされるようにブロックヘッダの一部を修正してよい。修正されるロックヘッダの一部はナンス値であってよい。たとえば、MLブロックプロデューサは、PoWハッシュパズルに解をもたらすナンス値を見つけるまでナンス値のシーケンスを通じて反復してよい。

【0094】

上記で説明したPoWハッシュパズルの代替として、各MLブロックは、そのチェーン出力の中に、PoW Rパズルを備えてよい。Rパズルは、ECDSA署名のr値を導出するために使用されるエフェメラル鍵kの知識を証明するために使用され、すなわち、
r=[R]_xであり、ただし、R=k・G mod n=(x,y)である。

【0095】

エフェメラル鍵は公開鍵-秘密鍵ペアとは無関係であるが、ECDSA署名における重要なセキュリティパラメータである。それらは、秘密鍵の危殆化を防止するための単一の使用のために設計される。Rパズルの主な特徴は以下の通りである。
1. 知識証明を解くときにユーザが任意の公開鍵-秘密鍵ペアを使用することを可能にする。
2. 証明を妨害する何者かによる署名鍛造性を防止するために、通常、余分な署名が使用される。
3. P2PKHの代替すなわちハッシュパズルをスクリプトの中に提示する。

【0096】

PoW rパズルは、消費者がrパズルを解くことだけでなく、ある一定の難解ターゲットDを下回るハッシュ値をもたらす値(たとえば、ナンス)を見つけるための作業を行うことも必要とする。連続するUTXOをPoWハッシュパズルがチェーン結合するための、上記で説明した同じ論理に従って、Pow rパズルは、スクリプトの中の下の式のチェックを容易にする。
H(H(r_h||BlockHeader_h)||H(r_h-1||BlockHeader_h-1))<D

【0097】

計算を簡単にするためにECDSA署名のr値に基づいてパズルが作成されるが、Rに基づくパズルもカバーされ得る。MLブロックのチェーン出力は、次のようなロックスクリプトを備えてよい。
OP_DUP OP_3 OP_SPLIT OP_NIP OP_1 OP_SPLIT OP_SWAP OP_SPLIT OP_DROP
OP_2 OP_ROLL OP_CAT OP_SHA256 <H(r_h||BlockHeader_h)> OP_CAT OP_SHA256
<D> OP_LESSTHAN OP_VERIFY
OP_OVER OP_CHECKSIGVERIFY OP_CHECKSIG

【0098】

(高さh+1における)次のMLブロックのチェーン入力は、次のようなロック解除スクリプトを備える。

【0099】

【数1】

【0100】

署名sig_rは、必要とされるr値を使用する。Pは、MLブロックプロデューサの公開鍵である。余分な署名sig'は異なるr値に基づき、上記で述べたようにセキュリティ理由のために追加され、署名sig=(r,s)の中のr値の実際の知識を伴わずにRパズルをロック解除する署名を悪意のあるノードが鍛造することを防止する。いくつかの例では、この追加の署名は必要とされない。

【0101】

ロックスクリプトの中の1番目の行は、rを抽出する。2番目の行は、PoW式の左辺を構築する。3番目の行は、PoW式の右辺における条件が成り立つことをチェックする。4番目の行は、ロック解除スクリプトの中の両方の署名に対して署名検証チェックを実行する。

【0102】

上のロックスクリプトが、PoW rパズルがどのように実施され得るのかの一例にすぎないことが、諒解されよう。より一般的には、PoW rパズルは、第1のハッシュ値および難解ターゲットを備える。第1のハッシュ値は、r値と連結された現在のMLブロックのブロックヘッダのハッシュである。PoW rパズルは、次のMLブロックのチェーン入力からの入力として、次のMLブロックのブロックヘッダおよび署名を取るように構成される。PoW rパズルは、署名からr値を抽出し、抽出されたr値を次のMLブロックのブロックヘッダと結合(たとえば、連結)し、結合されたr値とブロックヘッダとをハッシュすることによって第2のハッシュ値を生成するように構成される。PoWパズルはまた、第1のハッシュ値と第2のハッシュ値との結合(たとえば、連結)のハッシュが難解ターゲットを満たすことをチェックするように構成される。

【0103】

MLブロックをチェーン結合するための代替方法が使用されてよい。たとえば、MLブロックの所与のチェーン出力は、たとえば、ペイツーパブリックキーハッシュ(P2PKH:pay-to-public-key-hash)ロックスクリプトを使用して、特定のMLブロックプロデューサに関連付けられた公開鍵にロックされてよい。公開鍵は、新たなMLブロックをチェーンにアペンドするために複数のMLブロックプロデューサ501が寄与することを必要とする、しきい値秘密鍵に相当してよい。あるいは、MLブロックの所与のチェーン出力は、公開鍵のセットのうちの1つまたは複数にロックされたマルチ署名ロックスクリプトを備えてよい。

【0104】

各チェーン出力は、同じロックメカニズム、すなわち、ロックスクリプトのフォーマットまたは関数ではなく、特定のデータのみが異なる、特定のタイプのロックメカニズムを実施してよい。たとえば、各チェーン出力は、PoWパズルなどの同じコンセンサスメカニズムを実施するように構成されたロックスクリプトを備えてよい。データ(たとえば、以前のブロックヘッダのハッシュ、および現在のブロックヘッダ)のうちの少なくともいくつかが所与のMLブロックに固有であるが、ロックスクリプト(たとえば、オペコード)のフォーマットが同じであるという意味で、各PoWパズルは一意である。別の例として、P2PKHロックスクリプトの場合には、フォーマットは同じであるが、各ロックスクリプトの中に含まれる公開鍵ハッシュは異なる。

【0105】

実際には、MLブロックプロデューサは、コアネットワークのノードである可能性がある。しかしながら、少なくともいくつかの実施形態では、MLブロックプロデューサはSPVクライアントまたはユーザであってよい。SPVクライアントおよびユーザは、ブロックチェーンノードと比較して小さい能力しか有しないことがあり、たとえば、コアブロックをコアネットワークにサブミットすることができず、またはこのことのためにそれらがUTXOセットへのアクセスを必要とすることになるときにコアチェーンプロトコルに従ってコアトランザクション(MLブロック)を有効化することができない。そのため、これらの実施形態では、SPVクライアントは、コアトランザクションを有効化するようにコアブロックチェーンのUTXOセットを定期的にチェックする方法を必要とすることになる。SPVクライアントは、この目的のためにノードとの通信チャネルを有してよい。いくつかの例では、トランザクションがコアノードによって有効化され無効な場合には拒絶されるので、SPVクライアントがトランザクションを有効化することは必要でない。

【0106】

MLブロックプロデューサが、ユーザ、たとえば、アリスである場合、アリスはUTXOセットへのアクセスではなく、代わりに、2次データチェーン(たとえば、特定のアプリケーション)に関連するUTXOチェーン(すなわち、MLデータチェーン)の先端部を識別するための方法を必要とすることになる。このことは、UTXOセットを照会すること、またはそのチェーンのための任意の他の許可されたユーザすなわちコアノードと通信することによって、実行されてよい。

【0107】

MLブロックプロデューサは、好ましくは、UTXOチェーン先端部、すなわち、直近の有効なMLブロックを識別することができることが可能である。それが単一のP2PKHにロックされる場合、ユーザは、UTXOチェーンの中のコアトランザクションを他の誰も許可できないことを知っているので、このことは容易である。このことはまた、ノードが(メモリプールおよびUTXOセットを含む)ブロックチェーン履歴の完全なコピーを有するので、ノードにとって簡単である。しかしながら、PoWを実行するSPVクライアントの場合、またはもっと大きいグループ内の1つのパーティもしくはサブグループがコアトランザクションを許可できる状況では、SPVクライアントは、たとえば、クライアントがオフラインであってそれらのMLブロックを受信していない場合、UTXOチェーン先端部、および任意の消失した先行するMLブロックに気づいている必要がある場合がある。SPVクライアントは、直近のMLブロックをノードに要求してよい。

【0108】

7. 例示のマルチレベルブロックチェーンプロトコル
説明する実施形態を実施するための例示のプロトコルがここで説明される。以下の特徴のうちのいくつかが任意選択であることが諒解されよう。

【0109】

7.1 マルチレベルトランザクション
マルチレベルトランザクション(MLT:multi-level transaction)とは、2次チェーン上の1つまたは複数のトランザクションのデータがその中に埋め込まれるコアトランザクションである。それらは、コアネットワーク基盤を介してユーザからマルチレベル(ML)ノードへ2次チェーントランザクションデータを送信するように設計されている。その結果、MLプロトコルのために新たなネットワークまたは認証されたチャネルをセットアップする必要がない。MLTは、次の3つの主な要件を有する。
1. コアネットワークによって受け入れられるフォーマットで2次チェーントランザクションデータを搬送すべきであり、
2. 標準ノードがコアブロックの中でMLTを直接発行することを阻止すべき「最終でないもの」と見なされ、
3. 「確定された」コアトランザクションの構築の際に他のMLTと結合され得る。

【0110】

7.2 2次チェーントランザクションの埋込み
トランザクションを2次ネットワークにブロードキャストするために、ユーザは、最初に2次チェーントランザクションを作成するとともにそれに署名する。このトランザクションデータは、次いで、MLTの中に埋め込まれる前にシリアル化される。埋込みトランザクションの構造およびシリアル化のためのプロトコルは、2次ブロックチェーンのプロトコルに応じて異なる。たとえば、UTXOベースの2次ブロックチェーンは、セクション6.5の中で上記で説明したシリアル化フォーマットに従うことができる。

【0111】

7.3 MLT構造
コアネットワーク基盤を介してデータを搬送することの第1のMLT要件は、標準のコアブロックチェーントランザクションフォーマットに順守することによって満たされる。MLTは、出力のロックスクリプトの中のOP_RETURNとともに、1つ(または複数)のキャリアペア、すなわち、整合するインデックス位置における入力および出力を含む。OP_RETURNは、単一の埋込みトランザクションからのシリアル化されたデータを含む。キャリアペアは、コアチェーン上の入力および出力が、出力の中に埋め込まれる2次データから独立しているように、設計されている。任意のコアチェーンUTXOが、キャリアペアの入力として使用されることが可能であり、出力は、後続の任意のコアチェーントランザクションの中で、後で消費され得る。

【0112】

図10は、単一のキャリアペアを含むMLTを示す。MLTに対するnSequenceおよびロックタイム値がそれらのデフォルトに設定される。他のフィールドは以下の特性を有する。
バージョン 非標準の値。MLプロトコルのためのフラグとして働く。
入力 出力点- コアチェーン上のユーザに属する任意の有効なUTXOを指定することができる。
ロック解除スクリプト- フラグSINGLE|ANYONECANPAY (S|ACP)とともにユーザの公開鍵およびユーザの署名を含む。
出力: 値- 入力の値に等しい。
ロックスクリプト- ユーザに属する新たなコアチェーン公開鍵にUTXOを割り当てる。埋込みトランザクションデータに続いてOP_RETURNを含む。

【0113】

ここで、2次チェーン上のトランザクションを作成するすべてのユーザも、コアチェーン上のUTXOを制御し、したがって、彼ら自身のキャリアペアを作成できることが想定される。代替のシナリオが以下で探求される。

【0114】

7.4 バージョン番号
MLTは、MLプロトコルのためのフラグとして非標準トランザクションバージョン番号を使用する。非標準バージョン番号は、コアブロックチェーンネットワークのコンセンサス規則に基づいて無効なトランザクションを表現せず、むしろ、バージョン番号に関連するプロトコルによって決定されたトランザクションに追加の機能性をもたらす。所与のバージョン番号に対するそれらのポリシー文書を更新するノードは、追加されたこの機能性をそれらが解釈することを示す。標準ノードは、標準ビットコイントランザクションを成し遂げようとしたようにMLTを処理するが、MLノードは、MLプロトコルによって割り付けられた規則に従って、適切なバージョン番号でフラグ付けされたトランザクションを処理する。バージョンフラグも、埋込みデータのためのコアブロックチェーンを照会するための簡単な方法を提供する。

【0115】

7.5 トランザクション料金
MLTが最終でないものと見なされる第2のMLT要件は、オンチェーンでの発行に対してトランザクションを処理するために必要とされるトランザクション料金を省略することによって満たされ得る。トランザクション料金を除去することは、標準ノードによってMLTが発行されないことを保証するのに十分であり得る。いくつかのシナリオでは、代替のメカニズムは、個々のMLTがコアチェーンに発行されることを防止することを必要とされることがあり、このことが以下で探求される。トランザクション料金を伴わないキャリアペアの使用が、もしMLTが不注意にコアブロックチェーンに発行されるなら(出力UTXOが入力値に等しいので)ユーザが任意の値を失わないことを意味することに、留意されたい。この場合、余分なコストなしに、同じ埋込みデータを搬送するために新たなMLTが発行され得る。

【0116】

7.6 署名
MLTの中の各キャリアペアは、MLノードへ送られる前にユーザによって署名される。署名は、出力の詳細、すなわち、MLTの値、出力アドレス、および埋込みトランザクションデータをロックしながら、コアブロックチェーン上での入力UTXOの消費を許可する。

【0117】

(データの2次ブロックを表すために)MLTを結合して確定されたビットコイントランザクションにすることができることを伴う第3のMLT要件は、S|ACPを使用して成分であるすべてのキャリアペアに署名することによって満たされる。このsighashフラグは、キャリアペアが、MLTから抽出またはコピーされること、およびユーザによって提供される署名のうちのいずれかを無効化することなくもっと大きいトランザクションに結合されることを可能にする。

【0118】

7.7 マルチレベルブロック
マルチレベルブロック(MLB:multi-level block)とは、2次チェーンブロック全体がその中に埋め込まれる、コアブロックチェーン上の単一のトランザクションである。MLノードは、異なるユーザからMLTを受信し、成分であるそれらのキャリアペアを結合して候補MLBにする。確定されたMLBはまた、MLノードによって生成され埋め込まれる2次ブロックメタデータを含み、2次ブロックチェーンのコンセンサスメカニズムを満たさなければならない。

【0119】

7.8 マルチレベルノード
MLノードは、コアネットワークの中で動作するノードのサブセットであってよい。MLノードは、MLプロトコルの一部としてそれら自体を識別するためにそれらのポリシーを更新してよく、コアネットワークの中の「特殊」ノードとして機能し得る。このことは、2次ネットワークの中のピアが互いに直接接続を識別および確立することを可能にし、ユーザのMLTをユーザがブロードキャストできるノードをユーザが識別することも可能にする。

【0120】

コアネットワークの中のすべてのノードは、コアブロックチェーン、メモリプール、およびUTXOセットのコピーを維持すること、ならびにコアブロックチェーンの上部に新たなブロックを生成するためにそれらのピアと競合することなどの、重要な機能を実行する。MLノードは、コアブロックチェーンノードとしてのそれらの役目と並行して、2次ブロックチェーンに関係する役割の追加のセットを実行する。これらは以下のことである。
1. 以下のデータセットを維持すること。
・2次ブロックチェーンデータベース、
・MLTからのキャリアペアのメモリプール、および
・2次チェーンのためのトランザクション関連データ。
2. ユーザによって2次ネットワークにブロードキャストされるMLTを収集し、コアブロックチェーンプロトコルと2次ブロックチェーンプロトコルの両方に従ってそれらの有効性をチェックすること。
3. 有効なMLTを2次ネットワークの中のそれらのピアに転送すること。
4. 以下のことによって候補MLBを生成すること。
・有効なキャリアペアが受信されるとき、それらを組み込むこと、および
・候補MLB内に埋め込まれた2次チェーントランザクションのリストに基づいてマークルツリーおよび他のメタ情報を作成および更新すること。
5. 2次ブロックチェーンのコンセンサスメカニズムを満たすように他のMLノードと競合および/または協力すること。

【0121】

MLトランザクションのメモリプールは、必ずしもコアブロックチェーンのためにMLノードが保持するメモリプールとは別々であるとは限らない。トランザクションバージョン番号は、2つの別個のデータベースを作成する必要なく、それらのメモリプールの中のトランザクションを有効化するときにどのプロトコルに従うべきかをMLノードが識別することを可能にする。

【0122】

7.9 マルチレベル検証
MLTは、コアブロックチェーンプロトコルと2次ブロックチェーンプロトコルの両方によって割り付けられた規則、すなわち、マルチレベル検証(MLV:multi-level verification)と呼ばれるプロセスに従って検証されてよい。これらのチェックは互いに独立しており、並行して実行され得る。検証プロセスの一態様は、コアブロックチェーンのプロトコルの規則、すなわち、ビットコインの有効化規則によって統率される。MLT内の各キャリアペアは、以下のことをチェックすることによって検証される。
・コアネットワークのUTXOセットの中の有効なUTXOが、出力点の中で参照され、
・参照されるUTXOをロック解除するために、有効なロック解除スクリプトが入力の中で適用されており、
・入力の値が少なくとも出力の値に等しい。

【0123】

検証の他の態様は、埋込みトランザクションごとにキャリアペア内のシリアル化されたデータの有効性をチェックすることである。これらのチェックは、2次チェーンの規則に依存する。2次ブロックチェーン規則とコアブロックチェーン規則の両方に従って有効なMLTだけがMLBの中に含まれる。

【0124】

7.10 MLB構造
MLBは、図11に示すように一連の入力出力ペアから形成される。各ペアは、OP_RETURNの中に埋め込まれた2次チェーンブロックに関して、情報の別個のユニットを搬送する。MLノードは、2次チェーンブロックメタデータ、および関連する場合には2次チェーンブロック報酬を割り振るための埋込みトランザクションを含む、インデックス0(淡い陰影を用いて示す)およびインデックス1に対するキャリアペアを作成する。前方のインデックス2(暗い陰影を用いて示す)は、ユーザによって送られたMLTからコピーされるキャリアペアを含む。

【0125】

インデックス0における入力および出力は、2次チェーンのブロックヘッダデータを搬送する。入力として使用されるUTXOはダスト(dust)値を有し、出力は同じ値を新たなUTXOに再割り当てする。このようにしてインデックス0におけるUTXOをチェーン結合することによって、2次チェーンからのブロックヘッダが、コアチェーン上の単一のUTXOのトランザクション履歴内に記憶される。ブロックヘッダUTXOが任意のMLノードによって消費可能でなければならないことに留意されたい。ここで、このことは、出力を特定の公開鍵にロックするのではなく、ブロックヘッダUTXOに対するロックスクリプトの中のパズルを使用して達成される。パズルは、MLノードが2次チェーンに対するコンセンサスメカニズムを満たしていることを解が必要とするように設定される。

【0126】

インデックス1における入力および出力は次の3つの目的を果たす。
・コアチェーンの要件を満たすために必要なトランザクション料金を供給し、
・2次チェーン上で任意のブロック報酬を割り振り、
・MLBの完全性を保証するためにsighash ALLを使用して署名する。

【0127】

入力は、コアチェーンによって定められたレートでトランザクション料金をカバーするための十分な値を保持する、MLノードによって制御されるコアUTXOである。このモデルでは、MLノードは、コアチェーン上で料金をカバーするために小さい金額を消耗する。ブロック報酬および/またはトランザクション料金を通じてMLノードに奨励する2次ブロックチェーンプロトコルの場合、コアチェーントランザクション料金は、2次チェーンブロックからMLノードに割り振られた全報酬だけオフセット(および超過)されるべきである。他の2次ブロックチェーンプロトコルは、特に、それらのブロックチェーンデータの記憶および不変性の観点からMLプロトコルが与えることができる利点に起因して、少額の料金を負う意思がある場合がある。

【0128】

インデックス1の出力は、入力から残っている釣銭を、MLノードに属するアドレス(PK₁)に割り当てる。ブロックの発行時にMLノードに割り振られた報酬がある2次ブロックチェーン(たとえば、ビットコインにおけるコインベーストランザクション)の場合、報酬トランザクションのシリアル化されたデータも、インデックス1出力のOP_RETURNの中に埋め込まれる。

【0129】

入力を有効化するために提供される署名はsighash ALLを使用し、その結果、署名メッセージは、すべての入力およびすべての出力、すなわち、MLBの中のキャリアペアの詳細を含む。このことは、MLノードによってMLBが署名されると、インデックス1における署名を無効化することなくMLBトランザクションの詳細および候補2次ブロックが変更され得ないことを保証する。

【0130】

前方のインデックス2は、MLTの中でユーザによってブロードキャストされるキャリアペアを含む。ユーザがS|ACPフラグを用いてそれらのキャリアペアに署名するので、MLノードは、MLTから候補MLBトランザクションの中にキャリアペアを直接コピーすることができる。各キャリアペアの詳細(入力、出力、OP_RETURNデータ、および署名)、ならびに署名メッセージの中に含まれる他のトランザクション情報(バージョン番号、ロックタイム)が未変更のままであるとすれば、任意のキャリアペアは任意のコアブロックチェーントランザクションの中で有効なままである。その結果、すべての候補MLBの中でキャリアペアが同時に有効となる。このことは、各ノードのローカルメモリプールの中に記憶されたトランザクションの類似のセットからのコアブロックチェーンブロックの従来の構築を反映する。

【0131】

7.11 コンセンサスメカニズム
多くのブロックチェーンシステムでは、ブロックプロデューサは候補ブロックに勝利するために競合する。競合の結果は、ブロックチェーンのコンセンサスメカニズムに従って決定される。コンセンサスメカニズムの例は以下を含む。
・ブロックに勝利する確率が、ブロックプロデューサによって委託される計算リソースに比例する、プルーフオブワーク(PoW)。
・プルーフオブステーク(Proof of Stake)、すなわち、ネットワーク内でのブロックプロデューサの現在の所有財産または年功に基づく重み付き決定プロセス。
・ブロックプロデューサのセットが保証および信頼される、プルーフオブオーソリティ(Proof of Authority)。
・ノード間の投票。

【0132】

2次ブロックチェーンは、コアブロックチェーンと同じかまたはそれとは異なるコンセンサスメカニズムに従ってよい。MLノードは、コアブロックチェーンおよび2次ブロックチェーンに対してコンセンサスメカニズムを満たすために独立した取組みを行う。

【0133】

7.12 スクリプトの中でのコンセンサスメカニズムの執行
いくつかのコンセンサスメカニズムは、ビットコインのネイティブなスクリプト言語での暗号条件として表され得る。たとえば、ビットコインブロックチェーンにおいて使用されるPoWシステムは、ブロックプロデューサがハッシュパズルを解くことを必要とし、そうしたPoWシステムは、ブロックヘッダのハッシュがある一定の値(難解ターゲットD)を下回る候補ブロックを見つけなければならない。このタイプのハッシュパズルは、スクリプトの中で次のように表され得る。
< BlockHeader > OP_SHA256 < D > OP_LESSTHAN

【0134】

連続するMLBのインデックス0においてUTXOをチェーン結合するために、類似のスクリプトが使用され得る(図11参照)。MLBごとに、入力0は以前のMLBからの出力点0を参照する。以前のこの出力点は、以前の2次チェーンブロックヘッダに基づくハッシュパズルを含むロックスクリプトを有する。そのUTXOの消費を有効化するために、MLノードは、それらの現在の2次チェーンブロックヘッダに基づき以前のMLBからのハッシュパズルを満たす値を提供しなければならない。

【0135】

各候補MLB_h(高さhにおいて作成される)のインデックス0における次の条件は、UTXOチェーンの有効性を保証する。
1. 出力点が、以前のMLB、すなわち、MLB_h-1のインデックス0において生成されたUTXOを参照する。
2. ロック解除スクリプトが、現在の2次チェーンブロックヘッダのハッシュに設定される。
<H(BlockHeader_h)>
3. 出力が、新たなロックスクリプトを設定する。
< H(BlockHeader_h)> OP_CAT OP_SHA256 < D > OP_LESSTHAN
ただし、Dは2次チェーンの現在の難解ターゲットである。

【0136】

これらの条件を用いて、MLB_hのインデックス0を有効化するとき、ロック解除スクリプトがMLB_h-1のインデックス0のロックスクリプトと連結され、以下を与える。
< H(BlockHeader_h) > < H(BlockHeader_h-1) > OP_CAT OP_SHA256 < D > OP_LESSTHAN

【0137】

以下の場合、この組み合わせられたスクリプトは真と評価される。
H(H(BlockHeader_h)||H(BlockHeader_h-1))<D

【0138】

ハッシュパズル実装形態の一例がセクション8において与えられる。

【0139】

ビットコイン用のPoWシステムでは、たとえば、現在のブロックヘッダだけが明示的に有効性条件の中に含まれる。しかしながら、各ブロックヘッダが以前のブロックヘッダのハッシュを含むので、以前のブロックへの関係が暗黙的に執行される。MLプロトコルでは、隣接するブロック間にチェーンを構築するハッシュパズルはまた、UTXOのためのロックスクリプトの働きをする。各ロックスクリプトパズルの一部として一意の値を有することが重要であり、さもなければ、難解ターゲットを下回るハッシュを有することが知られている任意の値が、UTXOを消費するために使用され得る。同じか(または、もっと難しい)難解ターゲットが使用されていた、すべての以前のブロックヘッダは、この特性を有し、悪意のある行為者は、UTXOを消費するためにこれらのうちのいずれかを使用することができ、UTXOチェーンを破壊する。この脆弱性を解決するために、MLプロトコルは、直近の2次チェーンブロックヘッダの値を各ロックスクリプトの中に明示的に含める。この値は予測不可能であり、ハッシュパワーを適用することによってしか解が見つけられ得ないことを保証する。

【0140】

難解ターゲットは2次ブロックチェーン規則に従って設定され、組み合わせられたハッシュパワーが2次ブロック生成の中に注がれることに従って変わることがある。上記のスクリプト内パズルがPoW計算の反復ごとに2つのハッシュ演算を必要とし、すなわち、現在の(2次チェーン)ブロックヘッダが、ハッシュされなければならず、固定値H(BlockHeader_h-1)と連結されなければならず、2度目にハッシュされなければならないことに、留意されたい。第1のハッシュは厳密には必要でないが、ロック解除スクリプトのサイズ、したがって、MLBトランザクション料金を低減する。この余分なハッシュ演算が使用される場合、2次チェーン難解ターゲットも、補償するように調整され得る。

【0141】

7.13 候補MLBの有効化
2次チェーンコンセンサスに固有の要件に加えて、候補MLBはまた、MLプロトコル内の有効性の追加の条件を満たさなければならず、すなわち、
・インデックス2+の中のすべてのキャリアペアが、MLV規則に基づいて有効であり、
・ブロックヘッダおよびコインベーストランザクションが、2次チェーンプロトコルに従って正しくフォーマットされ、
・MLBが、コアネットワークの規則に基づいて十分なトランザクション料金を提供する。

【0142】

MLBの有効化は、2次ネットワークの中のピアノードによって実行され、MLBが標準ビットコインノードに利用可能にされる前に行われるべきである。このことは、コアチェーン上でMLBが発行されると、キャリアペアの中のUTXOは取り消せないように消費されるからである。候補MLBが有効化される前にコアチェーン上で発行されないことを保証するために、MLノードは、当初はインデックス1に対するそれらの署名を保留してよい。これは、標準コアノードにとって無効なトランザクションを表現するが、MLプロトコルの下では、MLBが検証を必要とすることを、消失した署名がMLノードにシグナリングする。ピアによってMLBが承認された後に署名が追加される。ピアは、候補MLBを受信すると有効化チェックを実行する。MLBが有効である場合、ピアは、
・候補MLBが有効であることを2次ネットワークの中のすべてのピアに通知し、
・そのキャリアペアがMLBの中に含められた任意のMLTを除去することによってそれらのメモリプールを更新し、
・有効なMLBの上部に新たな候補MLBを構築し始める。現在の2次チェーンブロックがすでに確定されインデックス0出力がすでに設定されているので、インデックス1に対する署名を保留することが、承認されたMLBの上部に新たな候補2次チェーンブロックを構築することからMLノードを遅延させないことに留意されたい。

【0143】

7.14 コアチェーン上でのMLBの発行
最終の署名を追加するとともにコアネットワークにブロードキャストすることによってMLノードに勝利することによって、候補MLBが確定される。MLBは、すべてのノードによる通常のトランザクションとして扱われ、コアチェーンに対する候補ブロックの中に含められる。

【0144】

2次ネットワークとコアネットワークの両方の可変のブロック生成時間に起因して、MLノードがコンセンサスに至ることと、勝利するMLBがコアチェーンの中で発行されることとの間に、短い遅延があり得る。その結果、2次チェーン上で生成されるブロックとコアチェーン上で発行されるブロックとの間に必ずしも1:1マッピングがあり得るとは限らない。各MLBが埋込みトランザクションの異なるブロックを含み、各MLBのコアチェーントランザクションIDが一意であるので、このことは問題にならない。したがって、コアチェーン上の同じブロック内で2つ以上のMLBが発行される場合、各2次チェーンブロックは、コアチェーン上でそれ自体の一意識別子(ブロック、TxID)を有する。

【0145】

類似の時間において2つのMLBが生成される状況では、従来のブロックチェーンは、一時的なチェーン分割を経験する場合があり、再編成に対応する必要があることになる。MLプロトコルでは、任意の競合をコアネットワークが解決することに依拠することができ、2次チェーンの中の所与の高さにおける2つのバージョンのMLBがコアネットワークへ送られる場合、一方しか発行されない。このことは、2つのMLBが(それらの親MLTの中のキャリアペアからの)同じUTXOを含み、そのため標準コアノードがそれらの候補ブロックの中に一方のMLBしか含めないからである。コアブロックチェーン上の勝利するブロックの中に含められるどのMLBも、2次チェーン上での事実上の勝利者である。

【0146】

7.15 誤り訂正: 2次チェーントランザクションの再発行
無効なMLBが誤ってコアブロックチェーンへ送られること、またはMLTがMLBの中に含まれる前にコアチェーン上でそれ自体の権限において発行されることが起こり得る。これらの状況では、キャリアペアに対する入力として使用されるUTXOは、コアネットワーク上で消費されているのでもはや有効でないが、それらが搬送する埋込みトランザクションは有効なMLBの中に含められておらず、したがって、2次ブロックチェーンの一部ではない。そのような誤りを矯正するために、MLノードは、(それらが制御するUTXOを使用して)置換キャリアペアを作成するとともにそれに署名すること、および時期尚早に消費されたMLTの中の元のデータ出力からの埋込みトランザクション情報をコピーすることによって、その埋込みトランザクションを「再発行」することができる。すべてのキャリアペアにとって入力および出力の値が整合されるので、MLノードは、標準のMLBにおけるよりも多くのコインを投資しない。このシナリオでは、ユーザは、もはやそれらのキャリアトランザクションのUTXO入力に彼ら自身の署名を適用しないが、2次チェーントランザクションデータは、埋込みトランザクション内で適用される署名に起因して、依然として修正に対して保護される。

【0147】

7.16 例示のフロー
図12は、以下の11ステップに対応する、MLプロトコルにおけるステップのシーケンス図を示し、ステップ1～8は2次ネットワーク内で(すなわち、MLノードによって)実行され、ステップ9～11はコアネットワークの中で(すなわち、MLノードと標準コアノードの両方によって)実行される。
1. ユーザが、各々が埋込みトランザクションを含む1つまたは複数のキャリアペアを構築する。
2. ユーザが、キャリアペアを含むMLTをMLノードにブロードキャストする。
3. MLノードが、着信MLTを2次ネットワークの中のそれらのピアに転送する。
4. MLノードが、各キャリアペアおよびそれの埋込みトランザクションを有効化するためにMLVプロセスを実行する。
i. MLVプロセスが失敗する場合、キャリアペアは廃棄される。
5. MLノードが候補MLBを構築する。
6. 候補MLBが、2次ネットワークの中のピアにブロードキャストされる。
7. 2次ネットワークの中のピアが、候補MLBをそれらが受信される順序で検証する。
i. 検証が失敗する場合、MLノードはそれらの候補MLBを構築することに進む(ステップ5)。
ii. 候補MLBが有効である場合、MLノードはすべてのピアに通知し、それらのメモリプールを更新し、承認されたMLBの上部に新たな候補MLBを構築する。
8. 勝利するMLノードが、インデックス1に対する署名を行いMLBをコアネットワークにブロードキャストすることによって候補MLBを確定する。
9. コアネットワークの中のノードが、コアコンセンサス規則に従って(通常のトランザクションとしてのMLBを含む)候補ブロックを構築する。
10. 勝利する候補ブロック(コアチェーン)が、コアネットワークの中のピアにブロードキャストされる。
11. MLBキャリアトランザクションを含む勝利するブロックがコアネットワークの中のピアによって検証され、埋め込まれた2次チェーンブロックがコアチェーン上で発行される。

【0148】

コアチェーン上で発行されると、MLBは、2次ブロックチェーンデータの公的な不変のレコードを提供する。2次チェーンから埋め込まれた各ブロックは、コアチェーン上での一意識別子、埋込みブロックを含むMLBのブロック高さおよびTxIDを有する。同様に、各埋込みトランザクションはまた、ブロック高さ、TxID、およびインデックス値によってコアチェーン上で一意に識別され得る。埋込みトランザクションごとのデータが、専用のOP_RETURN内に含まれるという事実は、2次チェーントランザクションデータの効率的な照会を可能にするはずである。

【0149】

2次ブロックチェーンはそれ自体のプロトコルに従うが、MLプロトコルは、コアブロックチェーンにあるものとされるいくつかの特徴から2次チェーンが恩恵を受けるための機会を与える。そのような特徴のいくつかの例は、以下の通りである。
・マイナーID- ビットコインSVネットワークにネイティブであり、マイナーIDは、どのMLノードが特定のMLBを発行することを担当したのかを2次チェーンのユーザが識別することを可能にすることができる。MLノードは、2次チェーンブロックヘッダの一部としてそれらのマイナーIDをMLBの中に含めることができる。ビットコインプロトコルに従う2次チェーンの場合、この情報は、埋込みコインベーストランザクションのコインベーススクリプトの中に含められることが可能である。
・ブロックキャップ(block cap)- いくつかのブロックチェーンは各ブロックのサイズに対して制限を有することがある。したがって、MLノードは、それらのブロック報酬を最大化するために、トランザクション料金レートがより高いトランザクションを選んでよい。ビットコインSVプロトコルに基づくコアブロックチェーンの場合、ブロックサイズに対する制約がない。2次ブロックチェーンコンセンサス規則の調停者は、コアブロックチェーンの特性を利用することができ、より大きいブロックサイズを求めてそれらのコンセンサスを更新することができる。
・プライベートブロックチェーン- 閉じたネットワーク内で動作するプライベートブロックチェーンのセキュリティは、たとえば、監査目的のために、コア公的台帳におけるトランザクションまたはブロックの委託を発行すること、プライベートデータの公的な不変のレコードを作成することによって、強化され得る。埋込みデータは、プライバシーを維持するために符号化またはハッシュされ得る。

【0150】

7.17 マルチレベルプロトコル変形形態
7.17.1 ユーザが2次チェーントランザクションを直接MLノードへ送る
場合によっては、2次ネットワークの中のユーザは、コアチェーン上の任意のUTXOを制御しないことがあり、またはそれらの2次チェーントランザクションの上部に第2の(コア)トランザクションを生成しそれに署名することを望まない場合がある。このことに対応するために、MLノードは、ユーザに代わってサービスとしてキャリアペアを生成しそれに署名することを提示することができる。この場合、ユーザは、別個のメッセージングチャネルを介してそれらの2次チェーントランザクションを直接MLノードへ送る。トランザクションデータは、2次チェーンプロトコルに従ってユーザによって署名されているので修正され得ない。

【0151】

MLノードは、2次チェーントランザクションを(それらが制御するUTXOを使用してキャリアペアを生成する)MLTの中に埋め込み、S|ACPフラグを使用してキャリアペアに署名する。元のプロトコルにおけるように、キャリアペアを許可する署名は、埋込みトランザクション内の署名から独立しており、ここで、それらは異なるパーティによって提供される。MLノードは、すべての候補MLBの中に埋込みトランザクションが含まれることを保証するために、署名されたMLTを2次ネットワークの中のそれらのピアに転送する。

【0152】

このシステムは、コアネットワーク上のUTXOを制御しないユーザにサービスを提供するが、ユーザは、キャリアペアを介して2次チェーントランザクションデータをMLノードにブロードキャストすることができない(すなわち、もはや既存のコアネットワーク基盤から離れてピギーバックすることができない)。代わりに、それらは別個の通信チャネルまたはネットワークを介してMLノードと直接通信するものとする。このことは、ユーザとMLノードとの間の認証の余分なステージを必要とすることがあり、ユーザは、それらの2次チェーントランザクションを(MLTを介して)2次ネットワークの残部まで運ぶためにMLノードを信頼しなければならない。

【0153】

7.17.2 埋込みデータのサイズの縮小
ベースMLプロトコルでは、データはそれの未加工のシリアル化された形式で埋め込まれる。このことは、MLBが大量のデータを含むことがあり、コアネットワーク上で大きいトランザクション料金を負い、コアネットワーク内のデータ記憶上に重い負担を置くことを意味する。代替形態は、2次チェーントランザクションデータが、キャリアペアの中に埋め込まれる前にハッシュされ、その結果、2次チェーンのフィンガープリントだけがコアチェーン上に記録されることである。2次チェーンデータのハッシュだけが埋め込まれる場合、ユーザがまた、MLノードが埋込みトランザクションを検証できるように各キャリアペアの中のハッシュされたトランザクションの原像をMLノードにサブミットしてよいことに、留意されたい。ハッシュする方法はコアチェーン上での記憶の負担を減らすが、2次チェーンデータがもはやコアチェーンデータベースから直接読み取られることができないので、データ取出しの容易さにおいてトレードオフがある。代わりに、MLノードは、完全な2次ブロックチェーンデータベースを記憶および維持することを担当する。2次ブロックチェーンの完全性を証明するために、MLノードによって記憶される完全なデータが、コアブロックチェーン上に存在する委託と結合されるものとする。

【0154】

これらの例における未加工のデータが、別個の2次ブロックチェーンデータベースの中に記憶されるので、埋込みトランザクションごとにコアチェーン上で一意の委託を有することは必要でなくてよい。たとえば、トランザクションごとに完全性証明を提供するために、2次チェーンブロック全体を表すマークルルートがマークル証明と結合され得る。完全な2次ブロックチェーンデータベースを維持するノードは、必要とされるマークル証明を提供することができ、これはコアチェーンの中に埋め込まれたもののマークルルートに対して検証され得る。

【0155】

これらの場合、MLノードは完全な2次チェーンブロックを単一のOP_RETURN内に埋め込むことができる。この設計を用いると、キャリアペアがもはや最終のMLBの一体部分ではないことに留意されたい。コアネットワーク基盤を介してそれらの2次チェーントランザクションをMLノードへ送信するために、依然としてキャリアペアがユーザによって生成されてよい。しかしながら、2次チェーントランザクションデータをMLノードへ送るために代替のネットワークまたは(たとえば、プライベートネットワーク内の)メッセージングシステムが使用される場合がある。

【0156】

2次ブロックチェーンが、コアチェーンの中に埋め込まれる前に存在した場合には、このプロトコル変形形態が有益であり得る。MLノードは、MLプロトコルへの転送の時間において、コアチェーン上のトランザクションの中に履歴的台帳の委託を含めることを望む場合がある。このことは、検証目的のために、2次ブロックチェーンの中の以前のトランザクションの不変のレコードを提供することになる。2次ブロックチェーンデータベースからのすべての履歴的トランザクション(または、サイズが縮小された委託)は、1つのヌルデータ出力(OP_FALSE OP_RETURN)において、コアブロックチェーン上の単一のトランザクションの中に埋め込まれ得る。

【0157】

7.17.3 しきい値コンセンサスメカニズム
上記で説明したハッシュパズルコンセンサスメカニズムの代替形態として、インデックス0におけるMLBの入力および出力から形成されるUTXOチェーンは、代わりに、しきい値方式の一部であり、MLノードとして働くパーティがそれに対してシェアを保持する、秘密鍵にロックされてよい。UTXO(したがって、MLB)を有効化するために、鍵シェアを保持するしきい値数のノードが、MLBが有効であることに合意しなければならない。ピア承認のためにそれらの候補MLBをサブミットするMLノードがそれらの署名シェアを提供することを想定すると、次いで、n個のうちの2個というしきい値方式は、ブロックが有効となるために2次ネットワークの中の許可された1つのピアの承認を必要とすることになる。もっと大きいしきい値を伴う方式は、MLBを有効化するために2つ以上のピアの承認を必要とすることになる。

【0158】

この変形形態を実施することへの1つの障害は、任意の所与の時間においてアクティブであるMLノードのセットを予測することが困難であり得ることである。しきい値方式は、通常、鍵シェアを保持するパーティの固定のセットを有することに依拠し、それによって、有効な署名を生成するために任意の1つの時間においてしきい値数が利用可能である。しかしながら、しきい値署名方式においてシェアを更新することおよびシェア保持者を追加または除去することが、下位の秘密鍵を変更することなく実現可能であることが、最近示されている。したがって、定期的にシェアを更新することによって、アクティブなMLノードのセットにおけるいくつかの変形に応じようとするための、フレキシビリティを有するしきい値方式を設計することが可能であり得る。

【0159】

7.17.4 コアネットワークへのMLBの遅延したブロードキャスト
コアブロックチェーン上でMLBが発行されると、MLBが含むすべてのキャリアペアのUTXOは取り消せないように消費される。したがって、MLBが有効化される前にコアネットワークへ送られないことが重要である。元のMLプロトコルは、候補MLBがコアネットワークへ送られる前に有効であることを、2次ネットワークの中の少なくとも1つのピアが確証することを必要とした。

【0160】

代替の誤り防止技法は、2次ネットワークがしきい値数の2次チェーンブロックを上部に構築してしまうまで、MLBをコアネットワークへ送ることを遅延させることである。コアネットワークのブロック生成時間とは異なるブロック生成時間、たとえば、各コアブロックの中で複数の2次チェーンブロックが発行されるのを期待される極めて短いブロック生成期間を、2次ブロックチェーンが有する状況において、この変形形態は特に有用であることを証明し得る。

【0161】

有効化されたMLBは、それらがコアネットワークにブロードキャストされる前のある一定の期間に、2次ネットワークの中のノードによってメモリの中に記憶され得る。これらのMLBは、標準ブロックチェーンの中でまだ発行されていないトランザクションのメモリプールと類似の、ブロックプールを形成することになる。各MLノードは、それら自体のブロックプールを局所的に維持することになり、他のMLノードによって生成されたMLBを、それらが有効化されていると含めることになる。

【0162】

7.17.5 ブロックプールプロトコル
2次チェーンの中の高さhにおけるブロックを考える。MLノードが高さh+cにおけるブロックを有効化すると、高さhにおけるブロックはc個の確認を有するものと見なされる。cというしきい値において、2次ネットワークは、高さhの確認されたMLBをコアネットワークにブロードキャストし、ブロックプールからそれを除去する。チェーンの中の後続のブロック(すなわち、r<cに対してh+1...h+r)は、それらが必須のc個の確認を受信してしまうまでブロックプールの中にとどまる。

【0163】

ブロックプールが空として始まることを想定する。以下のプロトコルは、ピアからMLBが受信されるときのMLB有効化およびブロックプールプロセスを表す。表記法Z_YXはMLB、すなわち、MLB Y上に構築されるZを示し、MLB YはX上に構築される等々である。。この例は、すべての可能なシナリオをカバーするように設計されているが(たとえば、2次ブロックチェーンにおけるマルチブロック分割)、このことが起こる可能性が極めて低いことが諒解される。

【0164】

図19は、異なるステージにおける、特定のMLノードPのブロックプールの内容を示す。
1. PがMLB Aを受信する。2次ブロックチェーン規則に従って有効である場合、
〇Pはそれらのブロックプールの中にAを配置し、
〇それらのメモリプールを更新して、Aの中に含まれるキャリアペアを除去し、
〇Aの上部に新たな候補MLBを構築するように動作する。
2. PはAと同じ高さのMLB Bを受信する。
〇Pは、B上のチェーンがA上よりも速く構築される場合にはBを記憶するが、
〇それが最長の有効なチェーンの一部になるまでBを有効化しない。
3. PはブロックC_Aを完成させピアへ送る。
〇Pはそれらのブロックプールの中にC_Aを配置し、
〇それらのメモリプールを更新し、
〇C_Aの上部に新たなMLBを構築するように動作する。
4. PはブロックE_DBを受信する。
〇現在知られていないとき、PはD_Bを要求する。
〇PはB、D_B、およびE_DBを検証する。すべてが有効である場合、
・Pはブロックプールの中にB、D_B、およびE_DBを配置し、
・それらのメモリプールを更新し、
・E_DBの上部に新たなMLBを構築するように動作する。
...
N. Pは相対的な高さcを有するブロックN_…Aを受信する。有効である場合、
〇PはAをコアネットワークにブロードキャストし、
〇それらのブロックプールから、Aと同じ高さにおける競合する任意のブロック(すなわち、B)、およびすべての関連付けられた子ブロック(D_BおよびE_DB)を除去し、
〇それらのメモリプールを更新し、
〇Nの上部に新たなMLBを構築するように動作する。

【0165】

7.17.6 MLTが時期尚早にコアチェーンに発行されないことの保証
元のMLプロトコルは、コアネットワークの中のノードが、現在、トランザクションがコアブロックチェーンの中に含められるための最小トランザクション料金レートを有するという事実に依拠する。すべてのMLTにおける料金を0に設定することによって、標準コアノードがそれらのブロックの中にMLTを含めるための任意の経済上の報奨を除去する。しかしながら、標準コアノードが、それらのブロックの中に料金が0のトランザクションを含めるようにそれらのポリシーを変更する場合、それらがネットワークにブロードキャストされる前にMLTを意図的に無効化するために余分な尺度が取られ得る。

【0166】

たとえば、署名生成の前に1に設定され、署名が適用された後に0に編集される、OP_RETURNデータの第1のバイトとして、フラグを含めてよい。これは、標準コアノードがMLTを無効であるものと見なすように、署名をアクティブに無効化する。しかしながら、MLプロトコルおよびバージョン番号に基づいて、MLノードは、署名有効化が実行される前にOP_RETURNの第1のバイトが1に戻されなければならないことを知ることになる。MLTの有効性の意図的な違反(および、その後の訂正)の均等な任意のプロセスは、この例と同じ目的を果たすことになる。

【0167】

7.17.7 ネットワーク構造: コアネットワーク上のSPVクライアント
ベースプロトコルでは、MLノードが、コアネットワークの中で動作するノードのサブセットであることを想定した。MLノードは、コアネットワークの中の通常の(バージョンが付けられていない)トランザクションに対する規則の異なるセットに従って、MLプロトコルバージョンフラグを有するトランザクションを処理するように、それらのポリシーを変える。それらは、2次ネットワークおよびコアネットワークに対して並行してブロックプロデューサとしての役割を実行する。

【0168】

代替形態は、MLノードが、2次ネットワークの中で排他的に完全なノードである(ブロックプロデューサとして機能する)ような、コアネットワークの中のSPVクライアントであることである。この変形形態への1つの障害は、キャリアペアの中の入力として使用されるUTXOがコアブロックチェーンの現在のUTXOセット内に存在することを、それらがその間に検証しなければならないMLVプロセスを実行することを、MLノードが必要とされることである。コアネットワークによってMLBが拒絶される場合、有効なブロックを生成するためにMLノードによって消耗されるリソースが無駄にされることになるので、この検証ステップは、無効なUTXOが候補MLBの中に含められないように極めて重要である。MLノードは、コアチェーン上の唯一のSPVクライアントである場合、これらのUTXOセットチェックを実行することを必要とされる完全なコアブロックチェーンデータベースを有しないことになる。1つの解決策は、UTXO委託を提供する、すなわち、コアチェーンのUTXOセットの検証された最新のコピーを供給できるサービスを、MLノードが採用することである。

【0169】

7.17.8 コアブロックチェーン上での包括的データの埋込み
MLプロトコルは、コアチェーン内に2次ブロックチェーンを埋め込み、コアブロックチェーン上のUTXOのチェーンを介して2次チェーンブロックを搬送するトランザクションをリンクするための、システムを示す。しかしながら、埋込みデータは、実際は任意のフォーマットをとることができる。ここで、パブリックブロックチェーン上のトランザクションのチェーン内にデータが埋め込まれる他の使用事例を考える。システムが2つのレベルの粒度、すなわち、UTXOチェーン内のトランザクション、および各トランザクション内の(OP_RETURNデータを有する)キャリアペアを提供することに留意されたい。

【0170】

ビットコインSVブロックチェーン上での限定されないブロックサイズに起因して、このようにして記憶され得るデータの量に対してほとんど制約がない。同様に、OP_RETURNコードが、シリアル化されて文字列になり得る任意のデータを保持できるので、記憶され得るデータのタイプに対してほとんど制約がない。データ不変性の証明を提供するためにコアブロックチェーンが使用され得るように、プライバシーのためにデータが暗号化されること、または未加工のデータの代わりに暗号委託(たとえば、データのハッシュ)が埋め込まれることが可能である。 コアチェーンデータベース内から埋込みデータのセットを識別する2つの手段、すなわち、トランザクションバージョンまたは特定のUTXOチェーンがある。いずれの識別子も、特定のトランザクションを隔離しコアブロックチェーンから埋込みデータにアクセスするために、外部システムまたはオーバーレイシステムによって使用され得る。トランザクションバージョンは極めてフレキシブルであり、ブロックチェーン内のデータキャリアトランザクションの一般的なカテゴリー分類にとって適切であり得る。しかしながら、他のパーティが、同じバージョン番号をそれら自体のトランザクションに自由に割り当てるので、トランザクションバージョン番号はセキュアな排他的識別子としては機能しない。一方、UTXOチェーンはもっと精密な制御を行い、それを介してパーティは、各UTXOロックスクリプトにおける消費条件に基づいてデータをある一定のチェーンに追加するためのパワーを有する。

【0171】

7.17.9 トランザクションバージョン番号に基づくレイヤ2アプリケーションデータの統合
ブロックチェーンがスケーリングするとき、サイズが縮小されたバージョンのブロックチェーンデータベースを維持することに向かってノードが動く可能性がある。たとえば、大きいデータペイロードを含むトランザクションをパージ(purge)すること、およびそれらのトランザクションに関連付けられるブロックヘッダデータだけを保持することによって。これらの場合、オンチェーンでデータを定期的に記憶するブロックチェーンアプリケーションは、それらのトランザクションデータの完全なコピーがネットワーク内に維持されることを保証するために、特定のノードまたはサーバとパートナーを組んでよい。これらの場合、トランザクションがブロックチェーンの一部であるという証明は、元のトランザクションデータとマークル証明の両方を必要とし、これらは、すべてのノードによって記憶されることになる、ブロックのマークルルートに対してチェックされ得る。
特定のアプリケーションに関係するトランザクションは、トランザクションバージョンに基づいてフラグ付けされ得る。このことは関連するトランザクションの簡単な識別を可能にするが、それらのトランザクションは、もっと広いブロックチェーン全体にわたって断片化されてよい。トランザクションごとにマークル証明が記憶されなければならないので、大量のマイクロトランザクションを(ソーシャルネットワークサイト、ゲームサーバ、またはトークンシステムを介して)生成するアプリケーションは、データとマークル証明の両方にとってかなりの記憶要件をもたらす場合がある。このことに対処するために、アプリケーションは、あるバージョンのMLBプロトコルを使用して、複数のユーザトランザクションを一緒に単一の「ブロック」トランザクションの中に照合することができ、その結果、大きな塊のマイクロトランザクションを表すために単一のマークル証明が記憶され得る。

【0172】

このシステムでは、ユーザは、(S|ACPを使用して)キャリアペアに署名することになり、OP_RETURNは、2次チェーントランザクションではなくアプリケーション関連データを含むことになる。キャリアペア入力および出力が同じ値を有するMLプロトコルとは対照的に、ここではキャリアペア値は、ユーザがブロックを生成するときにアプリケーションプロバイダがユーザからサービス料金を収集することを可能にするために、出力が入力よりも小さくなるように調整され得る。このことが、割り当てられていないいくつかの値を残すキャリアペアにユーザが署名することに依拠するので、料金がインターセプタによって収集されないようにユーザからサービスプロバイダへの直接の通信チャネルを有することが極めて重要であることに、留意されたい。セキュアなチャネルが可能でない場合には、アプリケーションプロバイダは、料金が0のキャリアペアを受け入れること、およびトランザクションの統合された大型のブロックによって与えられる利益に基づいてブロック自体に資金を供給することを選んでよい。料金がユーザによって寄与されるのかそれともサービスプロバイダによって寄与されるのかにかかわらず、マイクロトランザクションをブロックの中に統合することはまた、各マイクロトランザクションが個別にブロードキャストされた場合と比較してトランザクション料金の小さい節約を提示する。

【0173】

7.17.10 UTXOチェーン執行: ロックスクリプト
UTXOチェーンを作成することは、それらのバージョン番号によってフラグ付けされたトランザクションと比較して、埋込みデータトランザクションのセットのためのより大きい制御およびセキュリティを可能にする。UTXOチェーンは、チェーンの中の各UTXOが生成されるときに規定されるロックスクリプトによって保護され、これらのスクリプトは、そのセットに新たなデータトランザクションを追加するための許可権を有するパーティを制御するために使用され得る。たとえば、
・P2PKH: 関連付けられた秘密鍵を有する人物だけが、リンクされる次のトランザクションを作成できるように、チェーンの中の新たな各UTXOは特定の公開鍵にロックされる。
・マルチ署名: n個のうちの1個という要件を伴うマルチ署名消費条件は、公開鍵のリストに対応するn個の秘密鍵のうちのいずれか1つによって有効な署名が作成されることを可能にする。このことは、承認されたパーティのグループが確立されることが可能であり、グループのいずれか1人が、リンクされた新たなトランザクションをUTXOチェーンに追加し得ることを意味する。
・しきい値署名: チェーンの中のすべてのUTXOが、しきい値方式に関連する公開鍵にロックされることが可能であり、ここで、グループ内の設定された数のパーティは、リンクされた新たなトランザクションを生成するために、署名することに合意することを必要とされる。
・ハッシュパズル: ハッシュパズルは、ハッシュされたときにある一定のターゲットを下回る入力を必要とする。これはブルートフォース方式で解くことができるが、解くためにハッシュパワーのかなりの投資を必要とし、リンクされた新たなトランザクションを生成するためのPoW要件に影響を及ぼす。
・ハッシュ/HMAC原像: 非可逆の暗号関数(たとえば、ハッシュまたはHMAC)を適用するとともに解が正確な値であることを必要とする消費条件。上記で説明したハッシュパズルとは異なり、これはブルートフォースされ得ず、そのため、関連する原像をすでに知っているパーティしかUTXOを消費することができない。新たなUTXOが生成されるたびに(原像および出力値が備えられた)新たなペアが作成されなければならず、チェーンにアペンドすることが許可されるすべてのパーティとともに原像が共有される。代替として、一連の原像および関連付けられた出力は、あらかじめ生成されること、および許可されたすべてのパーティに分配されることが可能である。この解決策は、すべての有効な公開鍵のリストを各ロックスクリプトの中に含める必要がないとき、許可されたパーティのセットのうちのいずれか1つがUTXOチェーンに追加してよく、より低いトランザクション料金を提示し得るという点で、マルチ署名条件と機能的に類似である。

【0174】

7.17.11 順序付きデータ
UTXOチェーンの別の態様とは、チェーン内の後続のトランザクションの中に記憶されるデータに対して、固定の順序付けを行うことである。このことは、以前のブロック上に各ブロックが構築されるコアブロックチェーンモデルにとって基本であるが、多くの他のデータセット、たとえば、財務会計、文書またはコードの反復、電子メールまたはメッセージチェーン、順番ベースのゲームにおける移動などに適用可能な特徴である。

【0175】

主なMLプロトコルでは、2次チェーン内のブロックのセットは、ブロックヘッダ間のハッシュチェーンを用いて順序付けられるが、2次チェーンブロック内のトランザクションは、必ずしも設定された順序をなすとは限らない。S|ACP署名された各キャリアペアは、MLBトランザクション内のすべてのインデックス位置において等しく有効である。しかしながら、所望される場合、キャリアペアのレベルならびにトランザクション間で順序付けを執行することが可能である。このことを行うための1つの方法とは、第2のインデックス位置の中に埋め込まれるデータの冒頭において、第1のインデックス位置の中に埋め込まれるデータのハッシュ(または代替として、署名のハッシュもしくは全体的なキャリアペア)を含めることなどである。このことは、現在のインデックス位置に署名する時間において、以前のインデックス位置におけるデータが知られていたことを証明する。この方法を使用すると、マルチレベル順序付けデータセットが生成されコアブロックチェーン上に記憶されることが可能である。

【0176】

たとえば、順番ベースのゲームでは、プレーヤAが最初に移動させる。彼らは、彼らの移動の詳細をキャリアペアのOP_RETURNの中に配置し、S|ACPを使用して署名する。キャリアペアは、(ブロックプロデューサの役割を果たす)信頼されるゲームサーバへ送られる。サーバは、第1の移動キャリアペアのハッシュを計算し、これをプレーヤBへ送る。プレーヤBは、プレーヤAの移動のハッシュ、およびOP_RETURNの中のそれら自体の移動の詳細を含む、キャリアペアを生成し、これが署名されゲームサーバへ送られる。ゲームが終了すると、正しいシーケンスで彼らの移動が行われたという不変の証明を両方のプレーヤに提供するために、すべてのゲーム移動を順序通りに含む「ブロック」がブロックチェーンに発行される。

【0177】

7.17.12 UTXOチェーンの価値の切下げ
MLプロトコルに記載されるUTXOチェーンは、無期限に永続させられるように設計され、したがって、チェーンの中の新たな各UTXOが生成されるときに同じ値を維持する。代替形態は、価値が切り下がるUTXOチェーンを有して、システム/サービスが制限または制御されることを可能にすることである。たとえば、この制限は以下に基づくことができる。
・固定の時間期間、
・埋込みデータを含むトランザクションのある一定の個数、または
・コアチェーンの中に埋め込まれたデータのある一定の量。

【0178】

埋込みデータを含むトランザクションをユーザがブロックチェーンへ送ることをサービスプロバイダが可能にする場合を考え、ここで、サーバは完全なトランザクションデータを維持する。ユーザがサービスに登録すると、サービスプロバイダは、ユーザの公開鍵に割り当てられる設定された値、たとえば、1000サトシを有すべき第1のUTXOを、チェーンの中に鋳造する。このUTXOは、トークンとしてのものと考えることができるが、その主要な機能が、リンクされた一連のトランザクションをチェーン結合することであるので、それをUTXOまたはUTXOチェーンと呼ぶ。ユーザは、データをアップロードすることを望むたびに、現在のUTXOを消費し、低減された値(いくつかの、オプションが以下で説明される)を出力として有する新たなUTXOを生成する、キャリアペアを作成する。UTXOチェーンの中に新たなリンクを作成するこのキャリアペアは、(ベースプロトコルにおけるMLTに類似して)ユーザによって署名され、サービスプロバイダへ送られる。

【0179】

サービスプロバイダは、値の正確な低減がユーザのUTXOに適用されていることをチェックし、(ベースプロトコルにおけるMLBに対してMLノードが行うように)コアネットワークトランザクション料金をカバーするために第2の入力を提供する。サービスプロバイダは、複数のユーザからのデータキャリアペアを結合して単一のトランザクションにしてよく、各ユーザが彼ら自身の独立したUTXO、したがって、インデックスを有するので、各ユーザの個人用UTXOチェーンが維持される。

【0180】

7.17.13 トランザクションの個数
トランザクションが作成したデータ記憶の数に基づいてUTXO値の価値を切り下げるために、チェーンの中で新たなUTXOが作成されるたびに、その値は、以前の値未満の固定量であるべきである。たとえば、チェーンの中の各UTXOが、その先行要素よりも小さい100サトシという値を有する場合、1000サトシという初期鋳造から10個のトランザクションが作成されることが可能である。このシステムは、特に、一定の間隔でアップロードが行われないことがある、たとえば、文書またはコーディングライブラリの現在のバージョンおよび履歴を維持する状況に、適することになる。

【0181】

7.17.14 固定の時間期間
設定された時間期間にわたってUTXOチェーンの価値が切り下がることを可能にするために、類似のプロセスが使用され得る。ユーザは、データアップロードを行うことを望むたびに、キャリアペアを作成するとともにそれに署名し、鋳造から経過した時間に比例する金額(たとえば、10サトシ/日)だけ出力UTXOの値を低減する。サーバは、適切な値が使用されていることを検証する。代替として、各ユーザのUTXOは、ユーザまたはサービスプロバイダのいずれかがチェーンを更新できるようなMultiSigまたはハッシュ原像消費要件を用いて生成され得る。このセットアップを用いて、サービスプロバイダは、一定の間隔で(空であってよい)トランザクションを自動的に生成し、毎回、出力UTXOにおける値を低減する。このシステムは、定期的に行われるようにスケジュールされる自動バックアップ、たとえば、日々の電子メールまたは企業財務記録のバックアップにとって適している。

【0182】

7.17.15 固定量のデータ
第3のオプションは、アップロードされるデータのサイズに基づいて、チェーン結合されたUTXOにおける値を低減することである。ユーザはキャリアペアを形成し、埋め込まれているデータのサイズに従って(入力値と比較して)出力の値を低減する。サービスプロバイダは、トランザクションがコアチェーンへ送られる前に、埋込みデータのサイズ、およびサービス料金レートに基づいて、低減が適切であることをチェックする。サービスの条件に応じて、チェーンUTXOまたはサービスプロバイダのいずれかによってトランザクション料金がカバーされることが可能である。このシステムは、データアップロードが低頻度であってよく、サイズが大きいか、またはサイズの大幅な変動を有する、たとえば、ユーザが彼らの写真およびビデオをバックアップするかの、いずれかの状況にとって適切である。

【0183】

上記で説明したすべての場合、チェーンの中の現在のUTXOが入力として使用されるトランザクションを作成することによってUTXOチェーンを上積みすることは簡単であり、追加の入力が、トランザクションの出力においてチェーンの中の新たなUTXOに割り当てられる余分な資金を提供する。この上積みトランザクションは、チェーンUTXOの値およびサービスプロバイダへの適切な支払いの増大をカバーするのに十分な入力を含めることになるユーザによって生成され得る。代替として、ユーザは、オフチェーンでサービスプロバイダに支払うことができ、サービスプロバイダは、チェーンUTXOの値を増大させるためにトランザクションを生成することができる。

【0184】

これらのシステムは、それらのサービスおよび必要なときには上積みに対してユーザが前払いすることを可能にするために、サービスプロバイダによって実施され得る。サービスプロバイダのアクションは、ユーザが彼らのキャリアペアをサービスプロバイダへ送ることによってデータアップロードが誘発されるように自動化され得る。いくつかの状況では、ユーザはまた、ある一定の条件が満たされると(たとえば、日常的に、または設定された量の新たなデータが生成された後に)それらが自動的に行われるように設定されるように、キャリアペアの生成を自動化させることを望むことがある。

【0185】

これらのシステムは、命令またはコードのセットを実行するようにスマート契約が設定される、イーサリアムブロックチェーンにおけるガス概念を模倣する。ある一定の金額のガスがスマート契約に提供され、スクリプト(または、スクリプト内の各動作)の各反復は、ある比率のガスを使い尽くし、ガスが使い果たされていると実行するのをやめるようにスクリプトに強制する。ここで説明するシステムは、ビットコインがコアチェーンとして機能して、埋込みデータとしてスマート契約を実行するために使用され得る。スクリプトを実行するオーバーレイシステムは、出力UTXOの値が各反復とともに価値を切り下げて、UTXOチェーンの中の新たなトランザクションの中に各反復を記録することができる。所望される場合、たとえば、中間状態の値が表され保持される必要がある場合、各トランザクション内の別個のキャリアペアの中でコードの下位セクションが表され得る。システムはまた、一連の計算が「オフチェーンで」実行され、結果が有効であるという暗号証明と一緒に最終の結果だけがチェーン上に記録される、ロールアップと互換性がある。ロールアップが生成されるたびに、結果および証明がUTXOチェーン内のトランザクションの中に埋め込まれることが可能であり、出力の値は、オフチェーン計算に対するガス消費のレートに従って減少される。

【0186】

8. 例示の使用事例
以下は、2次チェーンとコアチェーンの両方に対して同じブロックチェーン規則が適用される例示の実装形態を提供する。これは、ある一定の特徴、すなわち、以下のものの再現を可能にする。
・トランザクションモデル- これは、2次トランザクションとコアトランザクションの両方に対して同じシリアル化フォーマットおよびMLVプロセスを有するUTXOベースのトランザクションをもたらす。
・ブロックモデル- ブロック構造、構築、および有効化が、2次ブロックとコアブロックの両方にとって基本的に類似であるが、2次ブロックのためのデータが、MLBキャリアトランザクション内に埋め込まれる。
・コンセンサスアルゴリズム- 同じコンセンサス規則が適用されるとき、ノードはすでに、有効なビットコインブロックを生成するために必要とされるPoW計算を実行するようにセットアップされたシステムを有する。

【0187】

以下の参加者を考える。
・2次ブロックチェーンのユーザ- アリス

【0188】

【数2】

【0189】

・2次ブロックチェーン上でビットコインを受け入れる小売商- マイク(PK_M)
・MLノードとして機能する参加ノード- ボブ

【0190】

【数3】

【0191】

使用中のMLプロトコル規則が以下であることを想定する。
・使用中の特定のバージョン番号、Version_MLB= 0x0000002A。
・遅延のないロックタイムがすべてのMLTに設定される、Locktime_MLB= 0x00000000。
・すべてのMLTが最終のシーケンス番号を使用する、n_MLB=0xFFFFFFFF。
・2次チェーン用のPoWがコアチェーンのPoWと類似であり、ブロックヘッダUTXOのロックスクリプトの中に構築される。MLノードは、ナンス、および
H(H(EBH_h)||H(EBH_h-1))<EDT
となるような(埋込み)ブロックヘッダEBH_hを見つけることによって、セクション3.2.4で説明したハッシュパズルを解かなければならず、ただし、EDTは埋め込まれるべきブロックの難解ターゲットである。2次チェーンに対する平均ブロック生成時間が一定のままであることを保証するために、MLBを生成することにMLノードが適用する結合されたハッシュパワーに従って、ターゲットが変更される。

【0192】

ここで、上記の参加者を参照しながら例を提供する、MLプロトコルにおけるステップをウォークスルーする。2次チェーンおよびコアチェーンにおけるトランザクションの間を区別するために、トランザクション図は、2次チェーントランザクションを表す緑色のセル、およびコアチェーントランザクションを表す青色のセルを有する。2次チェーン上の公開鍵は英字識別子(たとえば、PK_A)を有し、コアチェーン上の公開鍵は数値識別子(たとえば、PK₀)を有する。
(1)アリスが、2次ブロックチェーンの規則に従ってビットコイントランザクションを作成する。
(a)アリスは、アリスが通常のビットコイントランザクションを成し遂げようとしたように、2次チェーントランザクションTxID_embeddedを生成する。図13はアリスのトランザクションを示し、簡単なP2PKHが、ビットコインx₀のいくつかの値をマイクのアドレスPK_Mへ送り、残りの値を釣銭アドレス

【0193】

【数4】

【0194】

に割り当てる。2次チェーントランザクションは、アリスの公開鍵PK_Aを使用して許可され、sighash ALLを用いて署名される。
(a)アリスは、図8に示すフォーマットに従ってTxID_embeddedにおける入力および出力をシリアル化する。アリスは、次いで、結果として得られたシリアル化を連結し、図8に示す完全なトランザクションシリアル化の中にそれらを配置する。結果として得られたフォーマットは、TxID_embeddedについてのすべての情報を含む可変長の文字列である。
(2)アリスは、MLプロトコルの規則に従ってMLTを作成およびブロードキャストする。
(a)アリスは、図14に示すMLTを作成する。キャリアペアは、アリスがコアチェーン上で入力として制御し出力の中でアリスのアドレス

【0195】

【数5】

【0196】

に同じ値を割り当てる、任意のUTXOを使用する。出力ロックスクリプトは、シリアル化された形式のTxID_embeddedを含む。sighash S|ACPとともにアリスの公開鍵PK₂を使用してキャリアペアが署名される。
(3)ボブはアリスのMLTを受信し、2次ネットワークの中のボブのピアにそれを転送する。
(4)ボブは、コアブロックチェーンおよび2次ブロックチェーンの規則に従ってアリスのMLTおよび埋込みトランザクションを検証する。
(a)均等な2次ブロックチェーンプロトコルおよびコアブロックチェーンプロトコルにとってMLVプロセスの2つのステージは同一である。したがって、MLTおよび埋込みトランザクションに対して以下のチェックが独立して行われる。
・各入力は対応するUTXOセットの中の有効なUTXOを参照する。
・出力+任意のトランザクション料金をカバーするために入力の中に十分な値がある。ユーザは、埋込みトランザクションに対するトランザクション料金を含めなければならないが、キャリアペアはトランザクション料金を必要としない。
・すべての入力が、有効な署名を用いて署名される。ビットコインブロックチェーンの規則に従って、複数のパーティが協力して単一のトランザクションを生成してよい。すべてのキャリアペアは、S|ACP sighashフラグを使用して署名されなければならない。
(5)ボブは、アリスのキャリアペアを含む候補MLBを構築し始める。
(a)ボブは、アリスおよび2次ネットワークの中の他のユーザからサブミットされたキャリアペアを、前方のインデックス2からの候補MLBの中に含める。ボブは、各着信2次チェーントランザクションを用いて2次チェーンに対するマークルツリーを作成し定期的に更新する。
(b)ボブは、ボブが通常のコインベーストランザクションを成し遂げようとしたのと同様の方法で2次チェーンコインベーストランザクションを構築する。一例が図15に示される。ヌル入力は、TxID=[ ]およびインデックス=0を用いて出力点を与える、入力に対応するUTXOがないことを示すための設定値を有する。出力の中のロック解除スクリプトは、2つの値、すなわち、2次チェーン内の現在のブロックのブロック高さ、および任意選択のデータ文字列を含んでよい「コインベーススクリプト」フィールドを含む。ボブは、出力の中の2次チェーンブロック報酬およびトランザクション料金を彼自身に割り当てる。
(b)ボブは、2次チェーンコインベーストランザクションをシリアル化し、MLBのインデックス1のOP_RETURNの中にそれを埋め込む(それに応じて埋込みブロックヘッダの中のマークルツリーを更新する)。
(c)ボブは、ボブがPoWを実行するように(また、新たな2次チェーントランザクションが受信されMLBの中に埋め込まれると)、ボブが通常のビットコインブロックヘッダを成し遂げようとしたのと同様の方法で2次チェーンブロックヘッダデータを作成および更新する。
(d)ボブは、PoWアルゴリズムを解くと、インデックス0におけるブロックヘッダUTXOチェーンリンクを作成する。
・出力点:

【0197】

【数6】

【0198】

・ロック解除スクリプト: hash(EBH_h)
・出力値: ダスト
・ロックスクリプト: <hash(EBH_h)> OP_CAT OP_SHA256 <EDT> OP_LESSTHAN
・OP_RETURNデータ: EBH_h
(e)ボブは、コアネットワークの中のMLBキャリアトランザクションのトランザクション料金をカバーするために、ボブが制御するUTXOをインデックス1において追加する。ボブは、ボブの釣銭アドレス

【0199】

【数7】

【0200】

として出力を設定し、シリアル化された2次チェーンコインベーストランザクションデータをOP_RETURNの中に埋め込む。依然としてMLBが検証されなければならないので、ボブはこのステージにおいてインデックス1に対して署名を提供しない。図16はボブの候補MLBを示す。
(6)ボブは、ボブの候補MLBを2次ネットワークの中のピアにブロードキャストする。
(7)ボブのピアは、ボブの候補MLBを検証する。
(a)ピアは、有効性の確認をボブへ送る。
(b)2次ネットワークの中のすべてのノードが、ボブのブロックを2次ブロックチェーンデータベースに追加する。
(8)ボブは、インデックス1におけるボブの署名Sig₁ ALLを追加してボブのMLBを確定し、それをコアネットワークにブロードキャストする。
(9)コアネットワークの中のノードは、コアコンセンサス規則に従って候補ブロックを構築する。
(a)ボブのMLBがメモリプールに追加され、コアネットワークにおける候補ブロックの中に含められる。
(10)勝利する候補ブロックが、コアネットワークの中のピアにブロードキャストされる。
(11)MLBを含む勝利するブロックが、コアネットワークの中のピアによって検証される。
(a)ボブのMLBがコアチェーン上で発行される。図18は、MLBキャリアトランザクションを接続するUTXOチェーンを示し、図17は、2次チェーンブロックデータとコアチェーン上のMLBの中に出現するデータとの間のマッピングを示す。

【0201】

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

【0202】

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

【0203】

本発明の好ましい実施形態では、ブロックチェーンネットワーク106はビットコインネットワークであり、ビットコインノード104は、ブロックチェーン150のブロック151を作成すること、発行すること、伝搬させること、および記憶することの、説明する機能の少なくともすべてを実行する。これらの機能の全部ではなく、1つまたはいくつかしか実行しない他のネットワークエンティティ(または、ネットワーク要素)があってよいことが、除外されない。すなわち、ネットワークエンティティは、ブロックを作成および発行することなく、ブロックを伝搬させることおよび/または記憶することの機能を実行してよい(これらのエンティティが好適なビットコインネットワーク106のノードとは見なされないことを想起されたい)。

【0204】

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

【0205】

さらにより一般的には、上記の「ビットコインノード」104という用語への任意の参照は、「ネットワークエンティティ」または「ネットワーク要素」という用語と置き換えられてよく、そのようなエンティティ/要素は、ブロックを作成すること、発行すること、伝搬させること、および記憶することの役割の一部または全部を実行するように構成される。そのようなネットワークエンティティ/要素の機能は、ブロックチェーンノード104を参照しながら上記で説明した同様の方法で、ハードウェアで実装されてよい。

【0206】

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

【0207】

声明1. コアブロックチェーン上にデータチェーンを埋め込むためにマルチレベル(ML)データチェーンプロトコルを使用するコンピュータ実装方法であって、方法は、MLブロックプロデューサによって実行され、かつ
1つまたは複数のMLトランザクションを取得するステップであって、各MLトランザクションが、1つまたは複数のそれぞれのキャリアペアを備え、各キャリアペアが、それぞれの入力およびそれぞれの出力を備え、各それぞれの出力が、データチェーンに関連付けられたそれぞれのデータを備え、各それぞれの入力が、それぞれのキャリアペアに署名するそれぞれの署名を備える、ステップと、
MLデータチェーンの第1のMLブロックを生成するステップであって、第1のMLブロックが、コアブロックチェーントランザクションであり、a)取得された1つまたは複数のMLトランザクションのそれぞれのキャリアペアであって、キャリアペアごとに、それぞれの入力のそれぞれの位置インデックスが、それぞれの出力のそれぞれの位置インデックスに対応する、それぞれのキャリアペア、およびb)第1のチェーン出力であって、後続のMLブロックのそれぞれのチェーン入力によって消費されるためのものである、第1のチェーン出力を備える、ステップと、
第1のMLブロックをコアブロックチェーン上に記録させるステップとを備える。

【0208】

声明2. 声明1の方法であって、コアブロックチェーンは、1つまたは複数の以前のMLブロックを備え、各以前のMLブロックは、それぞれのコアブロックチェーントランザクションであり、a)1つまたは複数のキャリアペア、b)それぞれのチェーン出力、およびc)それぞれのチェーン入力を備え、各それぞれのチェーン入力は、以前のMLブロックのそれぞれのチェーン出力を消費し、その結果、1つまたは複数の以前のMLブロックは、MLブロックチェーンを形成し、第1のMLブロックは、c)以前のMLブロックのそれぞれのチェーン出力を消費する第1のチェーン入力を備える。

【0209】

声明3. 声明1または声明2の方法であって、第1のMLブロックをコアブロックチェーン上に前記記録させるステップは、第1のMLブロックをコアブロックチェーンネットワークにサブミットするステップを備える。

【0210】

声明4. 前述の任意の声明の方法であって、第1のMLブロックをコアブロックチェーン上に前記記録させるステップは、第1のコアブロックをコアブロックチェーンネットワークにサブミットするステップを備え、第1のコアブロックは第1のMLブロックを備える。

【0211】

声明5. 前述の任意の声明の方法であって、1つまたは複数のMLトランザクションを前記取得するステップは、1つまたは複数のMLトランザクションのうちの少なくとも1つを受信するステップを備える。

【0212】

声明6. 前述の任意の声明の方法であって、1つまたは複数のMLトランザクションを前記取得するステップは、1つまたは複数のMLトランザクションのうちの少なくとも1つを生成するステップを備える。

【0213】

声明7. 声明6の方法であって、
キャリアペアの中に含められるべきデータを受信するステップと、
受信されたデータを少なくとも1つのMLトランザクションのキャリアペアの中に含めることによって1つまたは複数のMLトランザクションのうちの少なくとも1つを生成するステップとを備える。

【0214】

声明8. 声明5またはそれに従属する任意の声明の方法であって、
受信されたMLトランザクションのそれぞれのキャリアペアのメモリプールを維持するステップと、
メモリプールの中に記憶されたそれぞれのキャリアペアのうちの1つまたは複数に基づいて第1のMLブロックを生成するステップとを備える。

【0215】

声明9. 前述の任意の声明の方法であって、取得されたMLトランザクションのうちの1つまたは複数を1つまたは複数のMLブロックプロデューサへ送るステップを備える。

【0216】

声明10. 前述の任意の声明の方法であって、第1のMLブロックは複数のキャリアペアを備える。

【0217】

声明11. 前述の任意の声明の方法であって、それぞれのデータは暗号化される。

【0218】

声明12. 声明11の方法であって、それぞれデータは、ハッシュ関数を使用して暗号化される。

【0219】

声明13. 前述の任意の声明の方法であって、キャリアペアごとに、それぞれの署名は、そのキャリアペアの入力および出力にしか署名しない。

【0220】

声明14. 声明13の方法であって、キャリアペアごとに、それぞれの署名は、それぞれの署名がそのキャリアペアの入力および出力にしか署名しないことを示す署名フラグに関連付けられる。

【0221】

声明15. 前述の任意の声明の方法であって、各MLトランザクションは、コアブロックチェーンプロトコルに従って無効なトランザクションである。

【0222】

声明16. 前述の任意の声明の方法であって、データチェーンは2次ブロックチェーンであり、それぞれのデータは、2次ブロックチェーンのブロックチェーントランザクションを備える。

【0223】

声明17. 声明16の方法であって、第1のMLブロックの前記キャリアペアのうちの1つのそれぞれのデータは、2次ブロックチェーンの一部または全部を備える。

【0224】

声明18. 声明1～15のうちのいずれかの方法であって、それぞれのデータは、アプリケーション固有データを備える。

【0225】

たとえば、特定の通信またはメッセージングアプリケーションに関係するデータ、たとえば、電子メールアプリケーションまたはソーシャルメディアアプリケーション。

【0226】

声明19. 前述の任意の声明の方法であって、各それぞれのMLブロックのそれぞれのチェーン出力は、それぞれのブロックヘッダを備え、それぞれのブロックヘッダは、マークルツリーのマークルルートを備え、マークルツリーのそれぞれのリーフは、それぞれのMLブロックのそれぞれのキャリアペアのそれぞれのデータに基づく。

【0227】

声明20. 声明19の方法であって、それぞれのブロックヘッダは、それぞれのMLブロックが作成されたおよび/またはコアブロックチェーンネットワークにサブミットされた時間を示すタイムスタンプを備える。

【0228】

声明21. 声明19または声明20の方法であって、第1のチェーン出力は、プルーフオブワークPoWパズルを実施するように構成されたロックスクリプトを備え、PoWパズルは、第1のブロックヘッダハッシュおよび難解ターゲットを備え、第1のブロックヘッダハッシュは、第1のMLブロックのそれぞれのブロックヘッダのハッシュであり、ロックスクリプトは、後続のMLブロックのそれぞれのチェーン入力が、第1のMLブロックの第1のブロックヘッダハッシュと結合されたとき、それぞれのブロックヘッダハッシュを備えることを必要とするように構成され、結合のハッシュは、難解ターゲットを満たす。

【0229】

声明22. 声明2に従属するときの声明21の方法であって、第1のMLブロックの第1のチェーン入力は、第1のMLブロックの第1のブロックヘッダを備え、第1のMLブロックの第1のブロックヘッダは、以前のMLブロックのそれぞれのチェーン出力のロックスクリプトによって実施されるPoWパズルによって設定された難解ターゲットを満たす。

【0230】

声明23. 声明19または声明20の方法であって、第1のチェーン出力は、PoW rパズルを実施するように構成されたロックスクリプトを備え、PoW rパズルは、第1のハッシュ値および難解ターゲットを備え、第1のハッシュ値は、第1のr値と結合された第1のブロックヘッダのハッシュであり、ここで、r値は、デジタル署名の成分であり、ロックスクリプトは、ロック解除されるために、後続のMLブロックのそれぞれのチェーン入力が、i)後続のMLブロックのそれぞれのブロックヘッダ、およびii)第1のr値を使用する署名を備えることを必要とされるように構成され、第1のロックスクリプトは、署名から第1のr値を抽出し、抽出されたr値と結合されたそれぞれのブロックヘッダのハッシュとして第2のハッシュ値を生成し、第1および第2のハッシュ値の結合のハッシュがターゲットの難解さを満たすことを検証するように構成される。

【0231】

声明24. 声明2に従属するときの声明23の方法であって、第1のMLブロックの第1のチェーン入力は、i)第1のMLブロックの第1のブロックヘッダ、およびii)以前のMLブロックのそれぞれのチェーン出力によって設定されたr値を使用する第1の署名を備え、第1のMLブロックの第1のブロックヘッダは、以前のMLブロックのそれぞれのチェーン出力のロックスクリプトによって実施されるPoW rパズルによって設定された難解ターゲットを満たす。

【0232】

声明25. 声明1～20のうちのいずれかの方法であって、第1のチェーン出力は、
- MLブロックプロデューサに関連付けられた公開鍵にロックされたロックスクリプト、
- 公開鍵のセットのうちの1つまたは複数にロックされたマルチ署名ロックスクリプトであって、各公開鍵がそれぞれのMLブロックプロデューサに関連付けられる、マルチ署名ロックスクリプト、
- しきい値秘密鍵に対応する公開鍵にロックされたロックスクリプトであって、しきい値秘密鍵が複数の秘密鍵シェアに分割され、各秘密鍵シェアがそれぞれのMLブロックプロデューサに関連付けられる、ロックスクリプト、
- ハッシュパズルを実施するように構成されたロックスクリプトであって、ハッシュパズルに対する原像が1つまたは複数のMLブロックプロデューサに利用可能にされる、ロックスクリプト、
- 特定のr値の知識を用いて任意のブロックプロデューサによってロックスクリプトがロック解除され得るような、rパズルを実施するように構成されたロックスクリプトのうちの1つを備える。

【0233】

声明26. 前述の任意の声明の方法であって、MLブロックプロデューサは、コアブロックチェーンのブロックチェーンノードである。

【0234】

声明27. 声明1～3または5～25のうちのいずれかの方法であって、MLブロックプロデューサは、コアブロックチェーンのブロックチェーンノードではない。

【0235】

声明28. 声明27の方法であって、MLブロックプロデューサは、簡易支払い検証クライアントである。

【0236】

声明29. 前述の任意の声明の方法であって、各MLブロックのそれぞれのチェーン出力は、それぞれのロックスクリプトをロック解除するための同じタイプのコンセンサスメカニズムを実施するように構成されたそれぞれのロックスクリプトを備える。

【0237】

すなわち、各チェーン出力のコンセンサスメカニズムは機能的に均等であり、たとえば、各チェーン出力は、PoWパズルを実施するように構成されたロックスクリプトを備える。各チェーン出力は、そのチェーン出力に固有のデータ、たとえば、特定の難解ターゲット、公開鍵、以前のブロックヘッダハッシュなどを備える。

【0238】

声明30. コンピュータ機器であって、
1つまたは複数のメモリユニットを備えるメモリと、
1つまたは複数の処理ユニットを備える処理装置とを備え、メモリは、処理装置上で動作するように構成されたコードを記憶し、コードは、処理装置上にあるときに前述の任意の声明の方法を実行するように構成される。

【0239】

声明31. コンピュータ可読ストレージ上に組み込まれ、1つまたは複数のプロセッサ上で動作するときに声明1～29のうちのいずれかの方法を実行するように構成された、コンピュータプログラム。

【符号の説明】

【0240】

100 システム
101 パケット交換ネットワーク
102 コンピュータ端末、コンピュータ機器
103 ユーザ、パーティ
104 ブロックチェーンノード、ビットコインノード
105 クライアント、クライアントアプリケーション
106 ピアツーピア(P2P)ネットワーク、コアブロックチェーンネットワーク、コアネットワーク
107 サイドチャネル
150 ブロックチェーン
151 データ、ブロック、コアブロックチェーンブロック
152 トランザクション
153 ジェネシスブロック(Gb)
154 順序付きセット、順序付きプール、トランザクション
155 ブロックポインタ
201 ヘッダ
202 入力、入力フィールド
203 出力、出力フィールド、未消費出力、トランザクション出力、未消費トランザクション出力、UTXO
301 サイドチャネル
401 トランザクションエンジン
402 ユーザインターフェース(UI)レイヤ
403 関数
450 ノードソフトウェア
451 プロトコルエンジン
452 スクリプトエンジン
453 スタック
454 アプリケーションレベル決定エンジン
455 ブロックチェーン関連機能モジュール
455C コンセンサスモジュール
455P 伝搬モジュール
455S 記憶モジュール
500 ユーザインターフェース(UI)、システム
501 ユーザ選択可能要素、MLブロックプロデューサ
502 データエントリフィールド
503 情報要素

【図1】

【図2】

【図3A】

【図3B】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】

【手続補正書】

【提出日】2024-02-21

【手続補正1】

【補正対象書類名】特許請求の範囲

【補正対象項目名】全文

【補正方法】変更

【補正の内容】

【特許請求の範囲】

【請求項1】

コアブロックチェーン上にデータチェーンを埋め込むためにマルチレベル(ML)データチェーンプロトコルを使用するコンピュータにより実施される方法であって、MLブロックプロデューサによって実行され、かつ
1つまたは複数のMLトランザクションを取得するステップであって、
各MLトランザクションが、1つまたは複数のそれぞれのキャリアペアを備え、
各キャリアペアが、それぞれの入力およびそれぞれの出力を備え、
各それぞれの出力が、前記データチェーンに関連付けられたそれぞれのデータを備え、
各それぞれの入力が、前記それぞれのキャリアペアに署名するそれぞれの署名を備える、ステップと、
MLデータチェーンの第1のMLブロックを生成するステップであって、
前記第1のMLブロックが、コアブロックチェーントランザクションであり、a)前記取得された1つまたは複数のMLトランザクションの前記それぞれのキャリアペアであって、キャリアペアごとに、前記それぞれの入力のそれぞれの位置インデックスが、前記それぞれの出力のそれぞれの位置インデックスに対応する、前記それぞれのキャリアペア、およびb)第1のチェーン出力であって、後続のMLブロックのそれぞれのチェーン入力によって消費されるためのものである、第1のチェーン出力を備える、ステップと、
前記第1のMLブロックを前記コアブロックチェーン上に記録させるステップと
を備える、コンピュータにより実施される方法。

【請求項2】

前記コアブロックチェーンが、1つまたは複数の以前のMLブロックを備え、
各以前のMLブロックが、それぞれのコアブロックチェーントランザクションであり、a)1つまたは複数のキャリアペア、b)それぞれのチェーン出力、およびc)それぞれのチェーン入力を備え、
各それぞれのチェーン入力が、以前のMLブロックのそれぞれのチェーン出力を消費し、その結果、前記1つまたは複数の以前のMLブロックが、MLブロックチェーンを形成し、
前記第1のMLブロックが、c)以前のMLブロックのそれぞれのチェーン出力を消費する第1のチェーン入力を備える、請求項1に記載の方法。

【請求項3】

前記第1のMLブロックを前記コアブロックチェーン上に前記記録させるステップが、前記第1のMLブロックをコアブロックチェーンネットワークにサブミットするステップを備える、請求項1に記載の方法。

【請求項4】

前記第1のMLブロックを前記コアブロックチェーン上に前記記録させるステップが、第1のコアブロックをコアブロックチェーンネットワークにサブミットするステップを備え、
前記第1のコアブロックが前記第1のMLブロックを備える、請求項1に記載の方法。

【請求項5】

前記1つまたは複数のMLトランザクションを前記取得するステップが、前記1つまたは複数のMLトランザクションのうちの少なくとも1つを受信するステップを備える、請求項1に記載の方法。

【請求項6】

前記1つまたは複数のMLトランザクションを前記取得するステップが、前記1つまたは複数のMLトランザクションのうちの少なくとも1つを生成するステップを備える、請求項1に記載の方法。

【請求項7】

キャリアペアの中に含められるべきデータを受信するステップと、
前記受信されたデータを前記少なくとも1つのMLトランザクションのキャリアペアの中に含めることによって前記1つまたは複数のMLトランザクションのうちの少なくとも1つを生成するステップと
を備える、請求項6に記載の方法。

【請求項8】

受信されたMLトランザクションのそれぞれのキャリアペアのメモリプールを維持するステップと、
前記メモリプールの中に記憶された前記それぞれのキャリアペアのうちの1つまたは複数に基づいて前記第1のMLブロックを生成するステップと
を備える、請求項5に記載の方法。

【請求項9】

前記取得されたMLトランザクションのうちの1つまたは複数を1つまたは複数のMLブロックプロデューサへ送るステップを備える、請求項1に記載の方法。

【請求項10】

前記第1のMLブロックが複数のキャリアペアを備える、請求項1に記載の方法。

【請求項11】

前記それぞれのデータが暗号化される、請求項1に記載の方法。

【請求項12】

前記それぞれのデータが、ハッシュ関数を使用して暗号化される、請求項11に記載の方法。

【請求項13】

キャリアペアごとに、前記それぞれの署名が、前記キャリアペアの前記入力および出力にしか署名しない、請求項1に記載の方法。

【請求項14】

キャリアペアごとに、前記それぞれの署名が、前記それぞれの署名が前記キャリアペアの前記入力および出力にしか署名しないことを示す署名フラグに関連付けられる、請求項13に記載の方法。

【請求項15】

各MLトランザクションが、コアブロックチェーンプロトコルに従って無効なトランザクションである、請求項1に記載の方法。

【請求項16】

前記データチェーンが2次ブロックチェーンであり、
前記それぞれのデータが、2次ブロックチェーンのブロックチェーントランザクションを備える、請求項1に記載の方法。

【請求項17】

前記第1のMLブロックの前記キャリアペアのうちの1つの前記それぞれのデータが、前記2次ブロックチェーンの一部または全部を備える、請求項16に記載の方法。

【請求項18】

前記それぞれのデータが、アプリケーション固有データを備える、請求項1に記載の方法。

【請求項19】

それぞれのMLブロックのそれぞれのチェーン出力が、それぞれのブロックヘッダを備え、
前記それぞれのブロックヘッダが、マークルツリーのマークルルートを備え、
前記マークルツリーのそれぞれのリーフが、前記それぞれのMLブロックの前記それぞれのキャリアペアの前記それぞれのデータに基づく、請求項1に記載の方法。

【請求項20】

前記それぞれのブロックヘッダが、前記それぞれのMLブロックが作成された、および/またはコアブロックチェーンネットワークにサブミットされた時間を示すタイムスタンプを備える、請求項19に記載の方法。

【請求項21】

前記第1のチェーン出力が、プルーフオブワーク(PoW)パズルを実施するように構成されたロックスクリプトを備え、
前記PoWパズルが、第1のブロックヘッダハッシュおよび難解ターゲットを備え、
前記第1のブロックヘッダハッシュが、前記第1のMLブロックの前記それぞれのブロックヘッダのハッシュであり、
前記ロックスクリプトは、後続のMLブロックのそれぞれのチェーン入力が、前記第1のMLブロックの前記第1のブロックヘッダハッシュと結合されたとき、それぞれのブロックヘッダハッシュを備えることを必要とするように構成され、
前記結合のハッシュが、前記難解ターゲットを満たす、請求項19に記載の方法。

【請求項22】

前記第1のMLブロックが、c)以前のMLブロックのそれぞれのチェーン出力を消費する第1のチェーン入力を備え、
前記第1のMLブロックの前記第1のチェーン入力が、前記第1のMLブロックの第1のブロックヘッダを備え、
前記第1のMLブロックの前記第1のブロックヘッダが、前記以前のMLブロックの前記それぞれのチェーン出力のロックスクリプトによって実施されるPoWパズルによって設定された前記難解ターゲットを満たす、請求項21に記載の方法。

【請求項23】

前記第1のチェーン出力が、PoW rパズルを実施するように構成されたロックスクリプトを備え、
前記PoW rパズルが、第1のハッシュ値および難解ターゲットを備え、
前記第1のハッシュ値が、第1のr値と結合された第1のブロックヘッダのハッシュであり、ここで、前記r値が、デジタル署名の成分であり、
前記ロックスクリプトは、ロック解除されるために、後続のMLブロックのそれぞれのチェーン入力が、i)前記後続のMLブロックのそれぞれのブロックヘッダ、およびii)前記第1のr値を使用する署名を備えることを必要とされるように構成され、
第1のロックスクリプトが、前記署名から前記第1のr値を抽出し、前記抽出されたr値と結合された前記それぞれのブロックヘッダのハッシュとして第2のハッシュ値を生成し、前記第1のハッシュ値および前記第2のハッシュ値の結合のハッシュが前記難解ターゲットを満たすことを検証するように構成される、請求項19に記載の方法。

【請求項24】

前記第1のMLブロックが、c)以前のMLブロックのそれぞれのチェーン出力を消費する第1のチェーン入力を備え、
前記第1のMLブロックの前記第1のチェーン入力が、i)前記第1のMLブロックの第1のブロックヘッダ、およびii)前記以前のMLブロックの前記それぞれのチェーン出力によって設定されたr値を使用する第1の署名を備え、
前記第1のMLブロックの前記第1のブロックヘッダが、前記以前のMLブロックの前記それぞれのチェーン出力のロックスクリプトによって実施されるPoW rパズルによって設定された前記難解ターゲットを満たす、請求項23に記載の方法。

【請求項25】

前記第1のチェーン出力が、
- MLブロックプロデューサに関連付けられた公開鍵にロックされたロックスクリプト、
- 公開鍵のセットのうちの1つまたは複数にロックされたマルチ署名ロックスクリプトであって、各公開鍵がそれぞれのMLブロックプロデューサに関連付けられる、マルチ署名ロックスクリプト、
- しきい値秘密鍵に対応する公開鍵にロックされたロックスクリプトであって、前記しきい値秘密鍵が複数の秘密鍵シェアに分割され、各秘密鍵シェアがそれぞれのMLブロックプロデューサに関連付けられる、ロックスクリプト、
- ハッシュパズルを実施するように構成されたロックスクリプトであって、前記ハッシュパズルに対する原像が1つまたは複数のMLブロックプロデューサに利用可能にされる、ロックスクリプト、
- 特定のr値の知識を用いて任意のブロックプロデューサによって前記ロックスクリプトがロック解除され得るような、rパズルを実施するように構成されたロックスクリプト
のうちの1つを備える、請求項1に記載の方法。

【請求項26】

前記MLブロックプロデューサが、前記コアブロックチェーンのブロックチェーンノードである、請求項1に記載の方法。

【請求項27】

前記MLブロックプロデューサが、前記コアブロックチェーンのブロックチェーンノードではない、請求項1に記載の方法。

【請求項28】

前記MLブロックプロデューサが、簡易支払い検証クライアントである、請求項27に記載の方法。

【請求項29】

各MLブロックのそれぞれのチェーン出力が、それぞれのロックスクリプトをロック解除するための同じタイプのコンセンサスメカニズムを実施するように構成されたそれぞれのロックスクリプトを備える、請求項1に記載の方法。

【請求項30】

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

【請求項31】

コンピュータ可読ストレージ上に組み込まれ、1つまたは複数のプロセッサ上で動作するときに請求項1から29のいずれか一項に記載の方法を実行するように構成された、コンピュータプログラム。

【国際調査報告】