特許7562743 | 知財ポータル「IP Force」

知財求人 - 知財ポータルサイト「IP Force」

青山学院大学 (神奈川県相模原市中央区淵野辺)

▶ エヌチェーン　ホールディングス　リミテッドの特許一覧

特許7562743ブロックチェーン状態確認

書誌要約請求の範囲詳細な説明課題実施例実施するための形態図面の説明

目に優しい文字サイズ小中大 PDF Top

< >

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

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

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2024-09-27

(45)【発行日】2024-10-07

(54)【発明の名称】ブロックチェーン状態確認

(51)【国際特許分類】

G06Q 20/38 20120101AFI20240930BHJP

H04L 9/32 20060101ALI20240930BHJP

【ＦＩ】

G06Q20/38 316

H04L9/32 200Z

【請求項の数】 11

【外国語出願】

(21)【出願番号】P 2023063952

(22)【出願日】2023-04-11

(62)【分割の表示】P 2019563527の分割

【原出願日】2018-05-23

(65)【公開番号】P2023089101

(43)【公開日】2023-06-27

【審査請求日】2023-04-11

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

(32)【優先日】2017-05-26

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

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

(32)【優先日】2017-05-26

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

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

(32)【優先日】2017-05-26

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

(73)【特許権者】

【識別番号】318001991

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

(74)【代理人】

【識別番号】100107766

【弁理士】

【氏名又は名称】伊東忠重

(74)【代理人】

【識別番号】100070150

【弁理士】

【氏名又は名称】伊東忠彦

(74)【代理人】

【識別番号】100135079

【弁理士】

【氏名又は名称】宮崎修

(72)【発明者】

【氏名】チャン，イン

(72)【発明者】

【氏名】クラマー，ディーン

【審査官】岩橋龍太郎

(56)【参考文献】

【文献】米国特許出願公開第２０１７／００４６６９８（ＵＳ，Ａ１）

【文献】国際公開第２０１７／０２４０７１（ＷＯ，Ａ１）

【文献】国際公開第２０１７／００４５２７（ＷＯ，Ａ１）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｑ１０／００－９９／００

Ｈ０４Ｌ９／３２

(57)【特許請求の範囲】

【請求項1】

コンピュータにより実施される方法であって、
ブロックチェーンネットワーク内のノードにおいて、デジタルアセットに関連付けられた第１トランザクションを受信するステップであって、前記第１トランザクションは、少なくとも、
前記デジタルアセットの制御を転送するための第２トランザクションに対する第１制約セットであって、前記第１制約セットは、前記第２トランザクションにブロックチェーンからのデータセットを含ませる１つ以上の制約を含み、前記第１制約セットは、前記データセットが前記ブロックチェーンのブロックからの第３トランザクションを含むという制約を含み、前記第３トランザクションは、前記ブロックチェーンにおける前記第３トランザクションのトランザクションIDに基づき前記データセットに含まれる、第１制約セットと、
前記第２トランザクションに対する第２制約セットであって、前記第２制約セットは、前記データセットのデータアイテムに関連付けられた１つ以上の制約を含む、第２制約セットと、
を指定し、
前記第１制約セットは、前記第１トランザクションのロックスクリプトに含まれ、前記第２制約セットは、前記第１トランザクションのロックスクリプトに含まれ、
前記データセットは前記第２トランザクションのアンロックスクリプトに含まれる、ステップと、
前記ロックスクリプトを実行する前に、前記アンロックスクリプトを実行することにより、前記第１制約セット及び前記第２制約セットが満たされることを検証するステップと、
前記検証するステップに少なくとも部分的に基づき、前記デジタルアセットを再関連付けするステップと、
を含むコンピュータにより実施される方法。

【請求項2】

前記データセットは前記第２トランザクションの中で前記ノードにおいて受信される、請求項１に記載のコンピュータにより実施される方法。

【請求項3】

前記検証するステップの結果として、前記第２トランザクションを有効化するステップ、を更に含む請求項１又は２に記載のコンピュータにより実施される方法。

【請求項4】

前記第２トランザクションを有効化するステップは、前記第２トランザクションを生成したエンティティがシークレット情報へのアクセスを有することを検証することなく、成功裏に実行される、請求項３に記載のコンピュータにより実施される方法。

【請求項5】

前記第１制約セットは、前記データセットが、ブロックヘッダ順序セットを含むブロックヘッダチェーンを含むという制約を含み、前記ブロックヘッダ順序セットは、複数のブロックヘッダを含み、前記ブロックヘッダ順序セットは、前記複数のブロックヘッダに関連付けられた順序を指定する、請求項１乃至４のいずれか一項に記載のコンピュータにより実施される方法。

【請求項6】

前記第２制約セットは、前記データセットのデータアイテムの値に対する制約を含む、請求項１乃至５のいずれか一項に記載のコンピュータにより実施される方法。

【請求項7】

前記第２制約セットは、前記データセットの前記データアイテムに関連付けられた１つ以上の値から導出される制約を含む、請求項１乃至６のいずれか一項に記載のコンピュータにより実施される方法。

【請求項8】

前記第１制約セットは、前記データセットがパブリックブロックチェーンから受信されるという制約を含む、請求項１乃至７のいずれか一項に記載のコンピュータにより実施される方法。

【請求項9】

前記ノードは、前記データセットが前記パブリックブロックチェーンから受信されるという前記制約が満たされるか否かを、少なくとも、
前記第２トランザクションの中で、前記ブロックチェーンネットワークから受信したブロックの前のブロックを含む第１ブロックセットと、前記ブロックチェーンネットワークから受信した前記ブロックの後のブロックを含む第２ブロックセットと、を受信することと、
前記第１ブロックセットが、前記ブロックチェーンネットワークから受信した前記ブロックにチェーンされることを検証することと、
前記第２ブロックセットが、前記ブロックチェーンネットワークから受信した前記ブロックにチェーンされることを検証することと、
前記第１ブロックセット及び前記第２ブロックセットが有効であることを検証することと、
前記第１ブロックセット及び前記第２ブロックセットの各ブロックが、所定値より大きい採掘難易度を有することを検証することと、
により決定する、請求項８に記載のコンピュータにより実施される方法。

【請求項10】

システムであって、
プロセッサと、
前記プロセッサによる実行の結果として前記システムに請求項１乃至９のいずれか一項に記載のコンピュータにより実施される方法を実行させる実行可能命令を含むメモリと、
を含むシステム。

【請求項11】

実行可能命令を格納した非一時的コンピュータ可読記憶媒体であって、前記実行可能命令は、コンピュータシステムのプロセッサにより実行された結果として、前記コンピュータシステムに請求項１乃至９のいずれか一項に記載のコンピュータにより実施される方法を少なくとも実行させる、非一時的コンピュータ可読記憶媒体。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、概して、ブロックチェーントランザクションを含む分散台帳技術に関し、特に、ブロックチェーン、ブロックヘッダ、ブロック、及びブロックチェーントランザクションからトランザクションスクリプトへのフィールドの導入を生じさせることに関する。本発明は、限定ではないが、特に、ブロックチェーンの状態に基づくトランザクションにおける使用に適する。

【背景技術】

【0002】

本願明細書で、用語「ブロックチェーン」は、あらゆる形式の電子的な、コンピュータに基づく、分散台帳を含むよう使用される。これらは、総意に基づくブロックチェーン及びトランザクションチェーン技術、許可及び未許可台帳、共有台帳、及びそれらの変形を含む。最も広く知られているブロックチェーン技術の用途はビットコイン台帳であるが、他のブロックチェーンの実装が提案され開発されている。「ビットコイン」は本開示に記載の技術の有用な用途として、便宜上及び説明の目的で参照され得るが、ビットコインは、本開示に記載の技術が適用され得る多くの用途のうちのほんの１つである。しかしながら、留意すべきことに、本発明は、ビットコインブロックチェーン及び代替ブロックチェーン実装及びプロトコルと共に使用されることに限定されず、本発明の範囲内に包含される非商業的アプリケーションも含む。例えば、本開示に記載の技術は、暗号通貨の交換が発生するか否かに拘わらず、暗号通貨トランザクション内にエンコード可能な制約に関して、ブロックチェーン実装及びビットコインに類似する制限を有する他の暗号通貨を利用することの利点を提供し得る。

【0003】

本願明細書で使用されるとき、「デジタルアセット」は、ブロックチェーンにより管理されるリソースの単位である。デジタルアセットは、ブロックチェーンにより管理されるリソースの単位である。デジタルアセットは、幾つかの実施形態では、暗号通貨として使用され得るが、デジタルアセットは実施形態において追加又は代替で他のコンテキストにおいて使用可能であると想定される。本発明は、デジタルアセットの制御に適用可能であるが、本来技術的であり、ブロックチェーンデータ構造を利用する他のコンテキストにおいて使用可能であり、デジタルアセットの転送を含む必要がないことに留意する。「デジタルアセット」は、本開示で使用されるとき、１つ以上のデジタルアセットを表してよい。例えば、トランザクションは、複数のインプットを有してよく、該インプットの各々は異なるデジタルアセットを表してよい。制御が転送されるデジタルアセットは、本例では、複数のデジタルアセットの集合であってよく、集合自体がデジタルアセットである。同様に、トランザクションは、これらの複数のインプットを細分化し及び／又は結合して、１つ以上のアウトプットを生成してよい。その結果、例えば、インプットの数及びアウトプットの数は異なる。一実施形態では、暗号通貨は、トークンに基づく暗号通貨である。ここで、各トークンはアセットのシェア（例えば、集団のシェア）を表し、単一のトランザクションが複数種類のトークンを含む（例えば、１つ以上の異なる集団にシェアが含まれる）。

【0004】

本開示は、１つ以上のブロックチェーンに基づくコンピュータプログラムの技術的態様を記載する。ブロックチェーンに基づくコンピュータプログラムは、ブロックチェーントランザクション内に記録された機械可読実行可能プログラムである。ブロックチェーンに基づくコンピュータプログラムは、結果を生成するために、インプットを処理できるルールを含んでよい。該結果は、次に、該結果に依存してアクションを実行させ得る。ロックスクリプトがアンロック及び前のトランザクションの両方にアクセス可能な場合、ブロックチェーンは、高度に柔軟で複雑なブロックチェーンに基づくコンピュータプログラムを可能にするために利用できる。現在の研究の一分野は、「スマートコントラクト（smart contracts）」の実装のためのブロックチェーンに基づくコンピュータプログラムの使用である。自然言語で記述され得る伝統的な契約と異なり、スマートコントラクトは、機械可読契約又は合意の条項の実行を自動化するよう設計されたコンピュータプログラムである。

【0005】

実施形態では、特定エンティティとの相互作用はスマートコントラクト内の特定ステップでエンコードできるが、スマートコントラクトは、その他の場合に自動実行され自己実施できる。幾つかの例では、自動実行は、UTXOの転送を可能にするために成功裏に実行されるスマートコントラクトの実行を表す。このような例では、UTXOの転送を生じることのできる「エンティティ」は、何らかのシークレットの知識を証明することを要求されずに、アンロックスクリプトを生成できるエンティティであることに留意する。言い換えると、アンロックトランザクションは、データのソース（例えば、アンロックトランザクションを生成したエンティティ）が暗号シークレット（例えば、秘密非対称鍵、対称鍵、等）へのアクセスを有することを検証することなく、有効化できる。また、このような例では、自己実施は、ブロックチェーンネットワークの検証ノードが、制約に従いアンロックトランザクションを施行するようにされることを表す。幾つかの例では、UTXOの「アンロック」は、技術的意味で使用され、UTXOを参照し及び有効として実行するアンロックトランザクションを生成することを表す。UTXOのアンロックは、従来、UTXOを使用することとして知られている。

【0006】

ブロックチェーントランザクションアウトプットは、ロックスクリプトと、ビットコインのようなデジタルアセットの所有権に関する情報と、を含む。ロックスクリプトは、解除条件（encumbrance）とも呼ばれてよく、UTXOを転送するために満たされることを要求される条件を指定することにより、デジタルアセットを「ロック」する。例えば、ロックスクリプトは、関連するデジタルアセットをアンロックするために、アンロックスクリプト内で特定データが提供されることを要求し得る。ロックスクリプトは、ビットコインでは「scriptPubKey」としても知られている。デジタルアセットをアンロックするためのデータを提供することをロックパーティに要求する技術は、ロックスクリプトの内部にデータのハッシュを埋め込むことを含む。しかしながら、これは、ロックスクリプトが生成されるときに、データが未確定である（例えば、分からない、及び固定されない）場合に問題になる。

【0007】

さらに、ロックスクリプトがブロックチェーン自体の態様に基礎を置く場合（例えば、ブロック内の他のトランザクション、又はブロックヘッダの内容）、ロックスクリプトが生成されるときにデータが存在せず、該データを取得するためにブロックチェーンの状態をクエリするためのオペコードがブロックチェーン内に存在しない。したがって、ロックスクリプトは、特定ブロックヘッダを要求できず、ブロックチェーンの特定状態を要求できず、トランザクションがブロックチェーンの特定ブロック内に置かれることを要求できない。

【発明の概要】

【0008】

したがって、上述の態様のうちの１つ以上において、ブロックチェーン技術を向上する方法及び装置を提供することが望ましい。したがって、本発明によると、添付の請求の範囲に定められるような方法が提供される。

【0009】

以下に詳述するように、コンピュータにより実施される方法及び電子装置は、アンロックスクリプトがブロックヘッダ、ブロックチェーン、又はブロックヘッダのチェーンを含むことを要求するために、アンロックスクリプト内のデータに対する制約を実施するよう構成される。このような制約をアンロックスクリプト内のデータに対して実施することにより、及びこのようなデータをアンロックスクリプトに実行時に挿入することにより、トランザクションは、ブロックチェーンの側面に基づくことができる。

【0010】

したがって、本発明によると、添付の請求の範囲に定められるような方法（及び対応するシステム）が提供され得る。方法は、ブロックチェーンデータ制約方法として記載され得る。コンピュータにより実施される方法は、（ｉ）ブロックチェーンネットワーク内のノードにおいて、第２トランザクションに対する制約セットを指定する第１スクリプトを含む第１トランザクションを受信するステップであって、前記制約セットは、前記ノードにより取得されたデータセットが前記ブロックチェーンネットワークに関連付けられたブロックチェーンから取得される情報を含むという制約を含む、ステップと、（ｉｉ）前記第２トランザクションを取得するステップであって、前記第２トランザクションは、実行された結果として、ノードに前記データセットを取得させる第２スクリプトを含む、ステップと、（ｉｉｉ）前記第１スクリプト及び前記第２スクリプトを実行することにより、前記第２トランザクションを検証するステップと、を含む。

【0011】

以下に詳述するように、コンピュータにより実施される方法及び電子装置は、前記アンロックスクリプトが前記ロックスクリプトを解除するために使用可能になり、前記トランザクションのデジタルアセットにアクセスする前に、前記ブロックチェーンが特定状態になることを要求するために、前記アンロックスクリプト内のデータに対する制約を実装するよう構成される。アンロックスクリプトがブロックヘッダ、ブロックチェーン、又はブロックヘッダチェーンを含むことを要求するためにロックスクリプトに対する制約を実施することにより、及びこのようなデータをアンロックスクリプトに実行時に導入することにより、トランザクションは、ブロックチェーンの状態に基づくことができる。

【0012】

制約セットは、データセットがブロックチェーンのブロックのブロックヘッダを含むという制約を含んでよい。

【0013】

ノードは、データセットがブロックチェーンのブロックのブロックヘッダを含むという制約が満たされるか否かを、少なくともブロックヘッダが所定サイズを有することを検証することにより、決定してよい。追加又は代替で、ノードは、データセットがブロックチェーンのブロックのブロックヘッダを含むという制約が満たされるか否かを、少なくともブロックヘッダが採掘難易度値以上である採掘難易度値を含むことを検証することにより、決定してよい。追加又は代替で、ノードは、データセットがブロックチェーンのブロックのブロックヘッダを含むという制約が満たされるか否かを、少なくともブロックヘッダのハッシュがブロックヘッダに含まれる採掘難易度値から計算された目標値以下であることを検証することにより、決定してよい。

【0014】

制約セットは、データセットがブロックチェーンのブロックからの第３トランザクションを含むという制約を含んでよい。

【0015】

データセットは、ブロックチェーンのブロックのブロックヘッダを含んでよい。追加又は代替で、制約セットは、第３トランザクションがブロックに含まれるという制約を含んでよい。追加又は代替で、ノードは、第３トランザクションがブロックに含まれるという制約が満たされるか否かを、ブロックチェーンのブロックのブロックヘッダに少なくとも部分的に基づき決定してよい。

【0016】

ノードは、第３トランザクションがブロックに含まれるという制約が満たされるか否かを、少なくとも、第３トランザクションのハッシュ値を少なくとも部分的にブロックヘッダにより識別されるブロック内のトランザクションの符号化に基づき、決定してよい。追加又は代替で、ノードは、第３トランザクションがブロックに含まれるという制約が満たされるか否かを、少なくとも、第３トランザクションのハッシュ値がブロックヘッダに格納されたハッシュ値に等しいことを検証することにより、決定してよい。

【0017】

前記制約セットは、前記データセットが、ブロックヘッダ順序セットを含むブロックヘッダチェーンを含むという制約を含んでよく、前記ブロックヘッダ順序セットは、複数のブロックヘッダを含み、前記ブロックヘッダ順序セットは、前記複数のブロックヘッダに関連付けられた順序を指定する。

【0018】

ノードは、第２スクリプトがブロックヘッダチェーンを含むという制約が満たされるか否かを、少なくとも、少なくとも部分的に複数のブロックヘッダに関連付けられた順序に基づき、ブロックヘッダペアを選択することにより、決定してよく、ブロックヘッダのペアは、ブロックヘッダのペアの第１ブロックヘッダと、ブロックヘッダのペアの第２ブロックヘッダと、を含む。追加又は代替で、ノードは、第２スクリプトがブロックヘッダチェーンを含むという制約が満たされるか否かを、少なくともブロックヘッダペアについて、ブロックヘッダのペアの第１ブロックヘッダのハッシュがブロックヘッダのペアの第２ブロックヘッダに格納されたハッシュ値に等しいことを検証することにより、決定してよい。

【0019】

制約セットは、データセットがブロックチェーンネットワークのパブリックブロックチェーンから取得されるという制約を含んでよい。

【0020】

ブロックチェーンネットワークの１つ以上の特性は、第１スクリプト及び第２スクリプトを実行する前に、ノードに提供されてよい。

【0021】

第２トランザクションの検証は、第２トランザクションを生成したエンティティが秘密情報へのアクセスを有することを検証することなく、成功裏に実行されてよい。

【0022】

第１スクリプトは、第１トランザクションのロックスクリプトであってよく、第２トランザクションは第１スクリプトのアンロックスクリプトである。

【0023】

コンピュータにより実施される方法は、検証の結果に少なくとも部分的に基づき、デジタルアセットを移転するステップを更に含んでよい。したがって、本発明によると、添付の請求の範囲に定められるような方法（及び対応するシステム）が提供され得る。方法は、ブロックチェーン状態確認方法として記載され得る。コンピュータにより実施される方法は、（ｉ）ブロックチェーンネットワーク内のノードにおいて、第１トランザクションを受信するステップであって、前記第１トランザクションは、少なくとも、ａ）第２トランザクションに対する第１制約セットであって、前記第１制約セットは、前記第２トランザクションにブロックチェーンからのデータセットを含ませる１つ以上の制約を含む、第１制約セットと、ｂ）前記第２トランザクションに対する第２制約セットであって、前記第２制約セットは、前記データセットのデータアイテムに関連付けられた１つ以上の制約を含む、第２制約セットと、を指定する、ステップと、（ｉｉ）前記第１制約セット及び前記第２制約セットが満たされることを検証するステップの結果として、前記第２トランザクションを前記ブロックチェーンに格納させるステップと、を含む。

【0024】

以下に詳述するように、コンピュータにより実施される方法及び電子装置は、前記アンロックスクリプトが前記ロックスクリプトを解除するために使用可能になる前に、前記ブロックチェーンが特定状態になることを要求するために、及びそれらの状態にある前記トランザクションのデジタルアセットへのアクセスを調整するために、前記アンロックスクリプト内のデータに対する制約を実装するよう構成される。アンロックスクリプトがブロックヘッダ、ブロックチェーン、又はブロックヘッダチェーンを含むことを要求するためにロックスクリプトに対する制約を実施することにより、及びこのようなデータをアンロックスクリプトに実行時に導入することにより、トランザクションの結果は、ブロックチェーンの状態に基づくことができる。

【0025】

データセットは、第２トランザクションの中で、ノードにおいて受信されてよい。

【0026】

コンピュータにより実施される方法は、前記検証するステップの結果として、前記第２トランザクションを有効化するステップ、を更に含んでよい。

【0027】

第２トランザクションの有効化は、第２トランザクションを生成したエンティティが秘密情報へのアクセスを有することを検証することなく、成功裏に実行されてよい。

【0028】

第１制約セットは、データセットがブロックチェーンのブロックのブロックヘッダを含むという制約を含んでよい。

【0029】

第１制約セットは、データセットがブロックチェーンのブロックからの第３トランザクションを含むという制約を含んでよい。

【0030】

前記第１制約セットは、前記データセットが、ブロックヘッダ順序セットを含むブロックヘッダチェーンを含むという制約を含んでよく、前記ブロックヘッダ順序セットは、複数のブロックヘッダを含み、前記ブロックヘッダ順序セットは、前記複数のブロックヘッダに関連付けられた順序を指定する。

【0031】

第２制約セットは、データセットのデータアイテムの値に対する制約を含んでよい。

【0032】

第２制約セットは、データセットのデータアイテムに関連付けられた１つ以上の値から導出される制約を含んでよい。

【0033】

第１制約セットは、第１トランザクションのロックスクリプトに含まれてよい。

【0034】

第２制約セットは、第１トランザクションのロックスクリプトに含まれてよい。

【0035】

第１制約セットは、データセットがパブリックブロックチェーンから受信されるという制約を含んでよい。

【0036】

ノードは、データセットがパブリックブロックチェーンから受信されるという制約が満たされるか否かを、少なくとも、第２トランザクションの中で、ブロックチェーンネットワークから受信されるブロックの前のブロックを含む第１ブロックセットと、ブロックチェーンネットワークから受信されるブロックの後のブロックを含む第２ブロックセットと、を受信することにより、決定してよい。追加又は代替で、ノードは、データセットがパブリックブロックチェーンから受信されるという制約が満たされるか否かを、少なくとも、第１ブロックセットがブロックチェーンネットワークから受信したブロックにチェーン（chain）されることを検証することにより決定してよい。追加又は代替で、ノードは、データセットがパブリックブロックチェーンから受信されるという制約が満たされるか否かを、少なくとも、第２ブロックセットがブロックチェーンネットワークから受信したブロックにチェーンされることを検証することにより決定してよい。追加又は代替で、ノードは、データセットがパブリックブロックチェーンから受信されるという制約が満たされるか否かを、少なくとも、第１ブロックセット及び第２ブロックセットが有効であることを検証することにより決定してよい。追加又は代替で、ノードは、データセットがパブリックブロックチェーンから受信されるという制約が満たされるか否かを、少なくとも、第１ブロックセット及び第２ブロックセットの各ブロックが所定値より大きい採掘難易度値を有することを検証することにより決定してよい。

【0037】

したがって、本発明によると、添付の請求の範囲に定められるような方法（及び対応するシステム）が提供され得る。方法は、ブロックチェーン状態認識方法として記載され得る。コンピュータにより実施される方法は、（ｉ）ブロックチェーンネットワーク内のノードにおいて、第１トランザクションを受信するステップであって、前記第１トランザクションは、少なくとも、ａ）第２トランザクションに対する第１制約セットであって、前記第１制約セットは、前記第２トランザクションにブロックチェーンネットワークからのデータセットを含ませる１つ以上の制約を含む、第１制約セットと、ｂ）前記第２トランザクションに対する第２制約セットであって、前記第２制約セットは、前記データセットが前記第１トランザクションを含むブロックを含むという制約を含み、前記ブロックは前記ブロックチェーンネットワークに関連付けられたブロックチェーンに含まれる、第２制約セットと、を指定する、ステップと、（ｉｉ）前記第１制約セット及び前記第２制約セットが満たされることを検証するステップの成功の結果として、前記第２トランザクションを前記ブロックチェーンネットワークに記録させるステップと、を含む。

【0038】

データセットは、第２トランザクションの中で、ノードにおいて受信されてよい。

【0039】

第１制約セットは、データセットがブロックチェーンのブロックのブロックヘッダを含むという制約を含んでよい。

【0040】

第１制約セットは、データセットがブロックチェーンのブロックからの第３トランザクションを含むという制約を含んでよい。

【0041】

【0042】

ブロックチェーンネットワークの特性セットは、第１制約セット及び第２制約セットが満たされることを検証するステップの結果として、ノードに提供されてよい。

【0043】

ブロックチェーンネットワークの特性セットは、ブロックチェーンネットワークのブロックチェーンの各ブロックに関連付けられた対応するタイムスタンプを含んでよい。

【0044】

第１制約セットは、第２トランザクションがブロックに対するタイムスタンプを含むという制約を含んでよい。追加又は代替で、第２トランザクションがブロックに対するタイムスタンプを含むという制約を検証するステップは、少なくとも部分的に、ブロックチェーンネットワークの特性セットに基づいてよい。

【0045】

第１制約セットは、データセットがブロックヘッダを含むという制約を含んでよい。追加又は代替で、第２制約セットは、第２トランザクションが第１トランザクションの識別子を含むという制約を含んでよい。追加又は代替で、第２制約セットは、第１トランザクションの識別子がブロックヘッダの値に関連付けられるという制約を含んでよい。

【0046】

第１制約セット及び第２制約セットは、トランザクションのロックスクリプトに含まれてよい。

【0047】

第１トランザクションは、第２トランザクションに対する第３制約セットを指定してよく、第３制約セットは、データセットのデータアイテムの値に対する制約を含む。

【0048】

第１トランザクションは、第２トランザクションに対する第３制約セットを指定してよく、第３制約セットは、データセットのデータアイテムに関連付けられた１つ以上の値から導出される制約を含む。

【0049】

コンピュータにより実施される方法は、第１制約セット及び第２制約セットが満たされることを検証するステップの結果として、第２トランザクションを有効化するステップを更に含んでよい。ここで、第２トランザクションは、第２トランザクションを生成したエンティティが秘密情報へのアクセスを有することを検証することなく、成功裏に実行される。したがって、本発明によると、添付の請求の範囲に定められるような方法（及び対応するシステム）が提供され得る。方法は、ブロックチェーンデータ制約方法として記載され得る。コンピュータにより実施される方法は、（ｉ）ブロックチェーンネットワーク内のノードにおいて、デジタルアセットに関連付けられた第１トランザクションを受信するステップであって、前記第１トランザクションは、前記デジタルアセットの制御を移転するための第２トランザクションに対する制約セットを指定する第１スクリプトを含み、前記制約セットは、前記ノードにより取得されたデータセットが前記ブロックチェーンネットワークに関連付けられたブロックチェーンから取得された情報を含むという制約を含む、ステップと、（ｉｉ）前記第２トランザクションを取得するステップであって、前記第２トランザクションは、実行された結果として、ノードに前記データセットを取得させる第２スクリプトを含む、ステップと、（ｉｉｉ）前記第１スクリプト及び前記第２スクリプトを実行することにより、前記第２トランザクションを有効化するステップと、を含む。

【0050】

制約セットは、データセットがブロックチェーンのブロックのブロックヘッダを含むという制約を含んでよい。

【0051】

【0052】

制約セットは、データセットがブロックチェーンのブロックからの第３トランザクションを含むという制約を含んでよい。

【0053】

【0054】

【0055】

【0056】

【0057】

制約セットは、データセットがブロックチェーンネットワークのパブリックブロックチェーンから取得されるという制約を含んでよい。

【0058】

ブロックチェーンネットワークの１つ以上の特性は、第１スクリプト及び第２スクリプトを実行する前に、ノードに提供されてよい。

【0059】

【0060】

【0061】

コンピュータにより実施される方法は、検証の結果に少なくとも部分的に基づき、デジタルアセットを移転するステップを更に含んでよい。

【0062】

したがって、本発明によると、添付の請求の範囲に定められるような方法（及び対応するシステム）が提供され得る。方法は、ブロックチェーン状態確認方法として記載され得る。コンピュータにより実施される方法は、（ｉ）ブロックチェーンネットワーク内のノードにおいて、デジタルアセットに関連付けられた第１トランザクションを受信するステップであって、前記第１トランザクションは、少なくとも、ａ）前記デジタルアセットの制御を転送するための第２トランザクションに対する第１制約セットであって、前記第１制約セットは、前記第２トランザクションにブロックチェーンからのデータセットを含ませる１つ以上の制約を含む、第１制約セットと、ｂ）前記第２トランザクションに対する第２制約セットであって、前記第２制約セットは、前記データセットのデータアイテムに関連付けられた１つ以上の制約を含む、第２制約セットと、を指定する、ステップと、（ｉｉ）前記第１制約セット及び前記第２制約セットが満たされることを検証するステップと、（ｉｉｉ）前記検証するステップに少なくとも部分的に基づき、前記デジタルアセットを再関連付けするステップと、を含む。

【0063】

データセットは、第２トランザクションの中で、ノードにおいて受信されてよい。

【0064】

【0065】

【0066】

第１制約セットは、データセットがブロックチェーンのブロックのブロックヘッダを含むという制約を含んでよい。

【0067】

第１制約セットは、データセットがブロックチェーンのブロックからの第３トランザクションを含むという制約を含んでよい。

【0068】

【0069】

第２制約セットは、データセットのデータアイテムの値に対する制約を含んでよい。

【0070】

第２制約セットは、データセットのデータアイテムに関連付けられた１つ以上の値から導出される制約を含んでよい。

【0071】

第１制約セットは、第１トランザクションのロックスクリプトに含まれてよい。

【0072】

第２制約セットは、第１トランザクションのロックスクリプトに含まれてよい。

【0073】

第１制約セットは、データセットがパブリックブロックチェーンから受信されるという制約を含んでよい。

【0074】

ノードは、データセットがパブリックブロックチェーンから受信されるという制約が満たされるか否かを、少なくとも、第２トランザクションの中で、ブロックチェーンネットワークから受信されるブロックの前のブロックを含む第１ブロックセットと、ブロックチェーンネットワークから受信されるブロックの後のブロックを含む第２ブロックセットと、を受信することにより、決定してよい。追加又は代替で、ノードは、データセットがパブリックブロックチェーンから受信されるという制約が満たされるか否かを、少なくとも、第１ブロックセットがブロックチェーンネットワークから受信したブロックにチェーンされることを検証することにより決定してよい。追加又は代替で、ノードは、データセットがパブリックブロックチェーンから受信されるという制約が満たされるか否かを、少なくとも、第２ブロックセットがブロックチェーンネットワークから受信したブロックにチェーンされることを検証することにより決定してよい。追加又は代替で、ノードは、データセットがパブリックブロックチェーンから受信されるという制約が満たされるか否かを、少なくとも、第１ブロックセット及び第２ブロックセットが有効であることを検証することにより決定してよい。追加又は代替で、ノードは、データセットがパブリックブロックチェーンから受信されるという制約が満たされるか否かを、少なくとも、第１ブロックセット及び第２ブロックセットの各ブロックが所定値より大きい採掘難易度値を有することを検証することにより決定してよい。

【0075】

したがって、本発明によると、添付の請求の範囲に定められるような方法（及び対応するシステム）が提供され得る。方法は、ブロックチェーン状態認識方法として記載され得る。コンピュータにより実施される方法は、（ｉ）ブロックチェーンネットワーク内のノードにおいて、デジタルアセットに関連付けられた第１トランザクションを受信するステップであって、前記第１トランザクションは、少なくとも、ａ）前記デジタルアセットの制御を転送するための第２トランザクションに対する第１制約セットであって、前記第１制約セットは、前記第２トランザクションにブロックチェーンネットワークからのデータセットを含ませる１つ以上の制約を含む、第１制約セットと、ｂ）前記第２トランザクションに対する第２制約セットであって、前記第２制約セットは、前記データセットが前記１トランザクションを含むブロックを含むという制約を含み、前記ブロックは、前記ブロックチェーンネットワークに関連付けられたブロックチェーンに含まれる、第２制約セットと、を指定する、ステップと、（ｉｉ）前記第１制約セット及び前記第２制約セットが満たされることを検証するステップと、（ｉｉｉ）前記検証するステップに少なくとも部分的に基づき、前記デジタルアセットの制御を移転するステップと、を含む。

【0076】

データセットは、第２トランザクションの中で、ノードにおいて受信されてよい。

【0077】

第１制約セットは、データセットがブロックチェーンのブロックのブロックヘッダを含むという制約を含んでよい。

【0078】

第１制約セットは、データセットがブロックチェーンのブロックからの第３トランザクションを含むという制約を含んでよい。

【0079】

【0080】

【0081】

【0082】

【0083】

【0084】

第１制約セット及び第２制約セットは、トランザクションのロックスクリプトに含まれてよい。

【0085】

【0086】

【0087】

【0088】

また、システムであって、プロセッサと、前記プロセッサによる実行の結果として前記システムに上述の方法のいずれかを実行させる実行可能命令を含むメモリと、を含むシステムを提供することが望ましい。

【0089】

また、実行可能命令を格納した非一時的コンピュータ可読記憶媒体であって、前記実行可能命令は、コンピュータシステムのプロセッサにより実行された結果として、前記コンピュータシステムに上述の方法のいずれかを少なくとも実行させる、非一時的コンピュータ可読記憶媒体を提供することが望ましい。

【0090】

【0091】

本発明によると、電子装置が提供され得る。電子装置は、インタフェース装置と、前記インタフェース装置に結合されたプロセッサと、前記プロセッサに結合されたメモリとを含む。前記メモリは、実行されると、本願明細書に記載の方法を実行するよう前記プロセッサを構成するコンピュータ実行可能を格納している。

【0092】

本発明によると、コンピュータ可読記憶媒体が提供され得る。コンピュータ可読記憶媒体は、実行されると、本願明細書に記載の方法を実行するようプロセッサを構成するコンピュータ実行可能命令を含む。

【0093】

本発明の上述の及び他の態様は、本願明細書に記載される実施形態から明らかであり、それらの実施形態を参照して教示される。本発明の実施形態は、単なる例として添付の図面を参照して以下に説明される。

【図面の簡単な説明】

【0094】

【図1】種々の実施形態が実施できる例示的なブロックチェーンネットワークの図を示す。

【図2】一実施形態による、ブロックチェーンネットワーク内のノードとして機能し得る例示的な電子装置の図を示す。

【図3】スクリプトに基づくブロックチェーン相互作用に関連付けられたトランザクションの例示的な実施形態の図を示す。

【図4】一実施形態により解決される、スクリプトに基づくブロックチェーン相互作用に関連付けられたブロックチェーンへのアクセスに伴う例示的な問題の図を示す。

【図5】一実施形態により解決される、スクリプトに基づくブロックチェーン相互作用に関連付けられたブロックチェーン内のブロックへのアクセスに伴う例示的な問題の図を示す。

【図6】一実施形態による、データが、スクリプトに基づくブロックチェーン相互作用のためのブロックヘッダであることを検証される、例示的な環境の図を示す。

【図7】一実施形態による、データが、スクリプトに基づくブロックチェーン相互作用におけるブロックヘッダであることを検証する例示的な処理のフローチャートを示す。

【図8】一実施形態による、データが、スクリプトに基づくブロックチェーン相互作用のための前のブロックのブロックヘッダであることを検証される、例示的な環境の図を示す。

【図9】一実施形態による、データが、スクリプトに基づくブロックチェーン相互作用における前のブロックのブロックヘッダであることを検証する例示的な処理のフローチャートを示す。

【図10】一実施形態による、データが、スクリプトに基づくブロックチェーン相互作用のためのブロックヘッダチェーンであることを検証される、例示的な環境の図を示す。

【図11】一実施形態による、データが、スクリプトに基づくブロックチェーン相互作用におけるブロックヘッダチェーンであることを検証する例示的な処理のフローチャートを示す。

【図12】一実施形態による、データが、スクリプトに基づくブロックチェーン相互作用における、使用可能なブロックヘッダのマークル木を示す例示的な環境の図を示す。

【図13】一実施形態による、トランザクションが、スクリプトに基づくブロックチェーン相互作用のためのブロックヘッダに含まれることを検証される、例示的な環境の図を示す。

【図14】一実施形態による、トランザクションが、スクリプトに基づくブロックチェーン相互作用におけるブロックヘッダに含まれることを検証する例示的な処理のフローチャートを示す。

【図15】一実施形態による、本願明細書に記載の方法を用いて、スクリプトに基づくブロックチェーン相互作用に関連付けられたブロックチェーンへのアクセスに伴う問題がどのように解決され得るかを示す例示的な環境の図を示す。

【図16】一実施形態による、スクリプトに基づくブロックチェーン相互作用に関連付けられたブロックチェーンの状態を示す例示的な実施形態の図を示す。

【図17】一実施形態による、スクリプトに基づくブロックチェーン相互作用において、ブロックチェーンの状態が確認される、例示的な実施形態の図を示す。

【図18】一実施形態による、スクリプトに基づくブロックチェーン相互作用において、ブロックチェーンの状態を確認する例示的な処理のフローチャートを示す。

【図19】一実施形態により解決される、スクリプトに基づくブロックチェーン相互作用におけるロックスクリプトに伴う例示的な問題の図を示す。

【図20】一実施形態による、スクリプトに基づくブロックチェーン相互作用におけるアンロックスクリプトによる例示的なデータアクセスの図を示す。

【図21】一実施形態による、署名が、スクリプトに基づくブロックチェーン相互作用におけるトランザクションフィールドの連続セットから生成される、例示的な環境の図を示す。

【図22】一実施形態による、署名が、スクリプトに基づくブロックチェーン相互作用におけるアンロックトランザクションの連続セットの導入を生じる、例示的な処理のフローチャートを示す。

【図23】一実施形態により解決される、スクリプトに基づくブロックチェーン相互作用におけるロックスクリプトに伴う例示的な問題の図を示す。

【図24】一実施形態による、スクリプトに基づくブロックチェーン相互作用において、前の連続トランザクションの導入が引き起こされる、例示的な環境の図を示す。

【図25】一実施形態による、スクリプトに基づくブロックチェーン相互作用における署名ハッシュ種類に依存して利用可能にされるフィールドセットの一例の図を示す。

【図26】一実施形態による、スクリプトに基づくブロックチェーン相互作用において、連続トランザクションからトランザクション識別子を抽出する一例の図を示す。

【図27】一実施形態による、スクリプトに基づくブロックチェーン相互作用における前の連続トランザクションの導入を生じる、例示的な処理のフローチャートを示す。

【図28】一実施形態による、ブロックチェーンの状態がスクリプトに基づくブロックチェーン相互作用のために使用される、例示的な環境の図を示す。

【図29】一実施形態による、スクリプトに基づくブロックチェーン相互作用において、ブロックチェーンの状態を使用する例示的な処理のフローチャートを示す。

【図30】一実施形態による、スクリプトに基づくブロックチェーン相互作用において、ブロックチェーンの状態を使用する例示的な実装の図を示す。

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

【0095】

先ず、図１を参照する。図１は、図の形式で、種々の実施形態が実施され得る、ブロックチェーンに関連付けられた例示的なブロックチェーンネットワーク１００を示す。ブロックチェーンプロトコルの下でブロックチェーンネットワーク１００が動作し、該ブロックチェーンプロトコルのインスタンスを実行する分散型電子装置は、ブロックチェーンネットワーク１００に参加してよい。このような分散型電子装置は、ノード１０２として参照され得る。ブロックチェーンプロトコルは、例えばビットコインプロトコルであってよい。

【0096】

ブロックチェーンプロトコルを実行し、ブロックチェーンネットワーク１００のノード１０２を形成する電子装置は、例えばデスクトップコンピュータ、ラップトップコンピュータ、タブレットコンピュータ、サーバのようなコンピュータ、スマートフォンのようなモバイル装置、スマートウォッチのようなウェアラブルコンピュータ、又は他の電子装置を含む様々な種類であってよい。

【0097】

ブロックチェーンネットワーク１００のノード１０２は、有線及び無線通信技術を含み得る適切な通信技術を用いて互いに結合される。このような通信は、ブロックチェーンに関連付けられたプロトコルに従う。例えば、ブロックチェーンがビットコインブロックチェーンである場合、ビットコインプロトコルが使用されてよい。ノード１０２は、ブロックチェーン上の全てのトランザクションのグローバル台帳を維持する。したがって、グローバル台帳は分散台帳である。各ノード１０２は、グローバル台帳の完全コピー又は部分コピーを格納してよい。グローバル台帳に影響を与えるノード１０２によるトランザクションは、他のノード１０２により検証される。その結果、グローバル台帳の有効性が維持される。ブロックチェーンがproof－of－workに基づくブロックチェーンであるとき、ブロックも、ブロックと共に提出されるproof－of－workをチェックすることにより検証される。

【0098】

ノード１０２の少なくとも幾つかは、ブロックチェーンネットワーク１００のマイナー１０４として動作する。図１のブロックチェーンネットワーク１００は、ブロックチェーン上のトランザクションを促進するために、マイナー１０４が費用の掛かる計算を実行するproof－of－workブロックチェーンである。例えば、proof－of－workブロックチェーンは、マイナーが暗号化問題を解くことを要求し得る。ビットコインでは、マイナー１０４がノンスを発見する。その結果、ブロックヘッダは、double SHA－２５６により、現在の採掘難易度（difficultly）により定められた値より小さい数にハッシュされる。proof－of－workアルゴリズムのために必要なハッシュ能力は、特定数のブロックがその上でマイニングされた後に、トランザクションが事実上不可逆であると見なされることを意味する。暗号化問題を解くマイナー１０４は、ブロックチェーンの新しいブロックを生成し、新しいブロックを他のノード１０２にブロードキャストする。他のノード１０２は、ブロックがブロックチェーンに追加されるべきであると受け入れる前に、マイナー１０４が実際に暗号化問題を解き、したがって充分なproof－of－workを立証したことを検証する。他のノード１０２も、ブロック自体が有効であること（例えば、トランザクション及びブロックのブロックヘッダが有効であること）を、ブロックがブロックチェーンに追加されることを許諾する前に検証する。ブロックは、ノード１０２の総意により、ブロックチェーンに（つまり分散グローバル台帳に）追加される。

【0099】

マイナー１０４により生成されたブロックは、ノード１０２によりブロックチェーンにブロードキャストされているトランザクションを含む。例えば、ブロックは、ノード１０２のうちの１つに関連付けられたアドレスからノード１０２のうちの別のものに関連付けられたアドレスへのトランザクションを含んでよい。このように、ブロックは、あるアドレスから別のアドレスへのトランザクションのレコードとして機能する。トランザクションがブロックに含まれることを要求したパーティは、彼らが転送を開始すること（例えば、ビットコインの場合には、ビットコインを移転すること）を認可されていることを、彼らの公開鍵に対応する秘密鍵を用いて要求に署名することにより、証明する。要求が有効に署名された場合のみ、転送はブロックに追加されてよい。

【0100】

ビットコインの場合、公開鍵とアドレスとの間には１対１対応がある。つまり、各公開鍵は単一のアドレスに関連付けられる。したがって、本願明細書でデジタルアセットを公開鍵へ又は公開鍵から転送する（例えば、公開鍵に関連付けられたアドレスに支払う）、及びデジタルアセットを公開鍵に関連付けられたアドレスへ又は該アドレスから転送するという言及は、共通の動作を表す。

【0101】

ノード１０２のうちの幾つかは、マイナーとして動作しなくてよく、代わりに検証ノードとして参加してよい。トランザクションの検証は、署名又はロックスクリプト内で指定された他の条件をチェックすること、有効UTXOへの参照を確認すること、等に関連してよい。図１の例は、６個のノード１０２を含み、そのうちの２個はマイナー１０４として参加している。実際には、ノード１０２又はマイナー１０４の数は異なってよい。多くのブロックチェーンネットワークでは、ノード１０２及びマイナー１０４の数は、図１に示した数より遙かに多くてよい。

【0102】

図２は、一実施形態による、ブロック図形式で、ブロックチェーンネットワーク（例えば、図１と関連して説明したブロックチェーンネットワーク１００のようなブロックチェーンネットワーク）におけるノード（例えば、図１と関連して説明したノード１０２のうちの１つのようなノード）として機能し得る例示的な電子装置２００を示す。例示的な電子装置２００は、図１と関連して説明したブロックチェーンネットワークのようなブロックチェーンネットワークにおける、図１と関連して説明したノード１０２のうちの１つのようなノードとして機能してよい。一実施形態では、ブロックチェーンネットワークは、ピアツーピアブロックチェーンネットワークである。

【0103】

電子装置は、例えばデスクトップコンピュータ、ラップトップコンピュータ、タブレットコンピュータ、サーバ、スマートフォンのようなモバイル装置、スマートウォッチのようなウェアラブルコンピュータ、又は別の種類の形式を含む様々な形式をとってよい。

【0104】

電子装置２００は、プロセッサ２１０、メモリ２２０、及びインタフェース装置２３０を含む。これらのコンポーネントは、互いに直接又は間接に結合されてよく、互いに通信してよい。例えば、プロセッサ２１０、メモリ２２０、及びインタフェース装置２３０は、バス２４０を介して互いに通信してよい。メモリ２２０は、本願明細書に記載の機能を実行するための機械可読命令及びデータを含むコンピュータソフトウェアプログラムを格納する。例えば、メモリは、プロセッサ２１０により実行されると、電子装置に本願明細書に記載の方法を実行させるプロセッサ実行可能命令を含んでよい。プロセッサ実行可能命令は、プロセッサ２１０により実行されると、電子装置に、ブロックチェーンネットワーク（例えば図１と関連して記載したブロックチェーンネットワーク１００）に関連付けられたプロトコルを実装させる命令を含んでよい。例えば、命令は、ビットコインプロトコルを実装するための命令を含んでよい。

【0105】

メモリ２２０は、ブロックチェーンネットワーク（例えば図１と関連して記載したブロックチェーンネットワーク１００）のグローバル台帳又はその部分を格納してよい。つまり、メモリ２２０は、ブロックチェーンの全部のブロック、又は最近のブロックのようなブロックの部分、又は幾つかのブロックの中の情報の部分を格納してよい。

【0106】

メモリ２２０は図２では単一のブロックにより示されるが、実際には、電子装置２００は複数のメモリコンポーネントを含んでよい。メモリコンポーネントは、例えばRAM、HDD、SSD、フラッシュドライブ、等を含む様々な種類であってよい。異なる種類のメモリは、異なる目的に適してよい。さらに、メモリ２２０はプロセッサ２１０と別個に示されるが、プロセッサ２１０は内蔵メモリを含んでよい。

【0107】

図２に示すように、プロセッサ２１０は、信頼できる実行環境（Trusted Execution Environment：TEE）のようなセキュア領域を含んでよい。TEE２５０は、電子装置２００に、独立した実行、信頼できるアプリケーションの完全性及びアセット機密性のような追加セキュリティを提供する独立実行環境である。TEE２５０は、TEE２５０内部にロードされたコンピュータ命令及びデータが機密性及び完全性の観点で保護されることを保証する実行空間を提供する。TEE２５０は、暗号鍵のような重要リソースの完全性及び機密性を保護するために使用されてよい。TEE２５０は、少なくとも部分的にハードウェアレベルで実装される。その結果、TEE２５０内で実行される命令及びデータは、電子装置２００の残りの部分からの及び電子装置の所有者のような外部パーティからのアクセス及び操作に対して保護される。TEE２５０内のデータ及び計算は、TEE２５０を含むノード（例えば図１と関連して記載したノード１０２）を作動させるパーティからセキュアにされる。

【0108】

TEE２５０は、セキュア実行環境（本願明細書で「エンクレーブ（enclave、飛び地）」とも呼ばれる）をインスタンス化し、次にメモリページを１つずつ追加するよう動作し得ると同時に、追加したメモリページを累積的にハッシングする。一実施形態では、メモリページのハッシングは、リモートマシン（例えば、開発者の機械又は別の機械）上で実行される。その結果、リモートマシンは、期待されるハッシュを決定し及び格納する。enclaveの内容は、したがって、任意のリモートマシンにより検証でき、enclaveが承認済みアルゴリズムを実行していることを保証する。この検証は、ハッシュを比較することにより実行されてよい。enclaveは、完全に構築されると、固定化される。TEE２５０内でコードを実行すること、及びシークレットをコードに送信することが可能であるが、enclaveがロックされると、コードは変更できない。最終ハッシュは、アテステーション（attestation）鍵により署名されてよく、データ所有者が任意のシークレットをenclaveへ送信する前に、データ所有者がそれを検証するために利用可能にされてよい。

【0109】

TEE２５０は、TEE２５０内に格納された暗号化鍵の信頼性及び完全性を保護するために使用されてよい。例えば、TEE２５０は、秘密鍵シェアの生成及び記憶のために使用されてよい。TEE２５０は、いかなるメンバーもTEE２５０内に保持された秘密鍵シェア又は他の秘密鍵シェアに関する情報をメンバー間通信又はenclave間通信から直接取得できないことを保証するためのものである。プロトコルは、閾値のenclaveのセキュリティ侵害（compromise）に対してもロバストである。さらに、TEE２５０は、リモートアテステーションを可能にし得る。リモートアテステーションは、ノード（例えば、図１と関連して説明したノード１０２のうちの１つのようなノード）により、TEE２５０が確実であり且つブロックチェーンネットワーク１００により実施されるプロトコルのための承認済みコンピュータ実行可能命令を実行していることを他のノードに証明するために使用されてよい。リモートアテステーションは、TEE２５０により、特定のコードピースを実行すること、及びenclaveの内部で、enclaveの内部アテステーション鍵により署名されたコードのハッシュを送信することにより、提供されてよい。

【0110】

TEE２５０は、セキュアな乱数生成器を備えてよい。このセキュアな乱数生成器は、TEEのenclaveの内部にあり、秘密鍵、ランダムチャレンジ、又は他のランダムデータを生成するために使用できる。TEE２５０は、また、外部メモリからデータを読み出すよう構成されてよく、外部メモリにデータを書き込むよう構成されてよい。このようなデータは、enclave内部にのみ保持されたシークレット鍵により暗号化されてよい。

【0111】

TEE２５０は、信頼できるプラットフォームモジュール（Trusted Platform Module：TPM）又はIntel Software Guard Extensions（SGX）のような様々なプラットフォームを用いて実装されてよい。SGXは、例えば、リモートアテステーションをサポートする。リモートアテステーションは、enclaveが、署名されたステートメントを、クオート（quote）として知られるメンバーの与えられたハス（has）により特定のenclaveを実行しているプロセッサから取得することを可能にする。Intel Attestation Service（IAS）のような第三者アテステーションサービスは、これらの証明されたステートメントがSGX仕様に従う真正CPUから生じることを認定し得る。

【0112】

本発明は、別のトランザクションのアンロックスクリプト内で提供される未確定データを用いて、ブロックチェーントランザクション（Tx）のロックスクリプト内に埋め込まれる暗号公開鍵を変更するよう構成される方法（及び対応するシステム）を提供し得る。例えば、連続トランザクションをメッセージとして使用するビットコインプロトコルにおける署名チェックオペコード（例えばOP_CHECKSIG）と関連して使用されるとき、トランザクション及びデータの両方が、公開鍵の所有者からの認可又は認証を要求する。これは、それらを変更から守る。

【0113】

本願明細書に記載の方法は、１つ以上のデジタル署名方式を用いて、種々のトランザクションを検証する。デジタル署名方式は、楕円曲線デジタル署名アルゴリズム（Elliptic Curve Digital Signature Algorithm：ECDSA）方式であってよい。デジタル署名は、２者ECDSA方式であってもよい。デジタル署名は、閾値ECDSA方式であってもよい。この方式は、秘密鍵を再構成する必要がなく、及び任意のパーティが彼らの鍵シェアを別のパーティに開示する必要がなく、有効署名を構成するために使用されてよい。例えば、２者ECDSA方式では、２つのパーティが存在し、両者が秘密鍵を再構成する必要がある。

【0114】

このECDSA方式は、図１に関連して記載したノード１０２のようなノードにより、不正又は非協力的パーティを識別するために使用され得る様々なメカニズムを含む。例えば、検証可能シークレット共有（verifiable secret sharing：VSS）は、Shamirのシークレット共有（Shamir’s Secret Sharing：SSS）のために必要な多項式を共有するために使用され得る。SSSは、シークレットが部分に分けられ、それ自体のユニークな部分への各々の参加に提供される、シークレット共有の形式である。これらの部分は、シークレットを再構成するために必要であり得る。VSSは、矛盾したシェアが異なるノードに提供された場合、又はシェアが全ノードにブロードキャストされる隠れ（ブラインド）シェアと異なり、シェアがノードへ秘密に送信された場合、ノードにより、不正ノード又はメンバーを識別するために使用されてよい。矛盾したシェアは、ノードのうちのいずれかにより識別されてよい。シークレットの共有は、ノードがそれらのシェアを矛盾しないとして検証することを可能にする補助情報を含むことにより、検証可能にされ得る。

【0115】

不正シェアの個々のノードへの送信（つまり、ブロードキャストされる隠れシェアと異なるシェア）は、シェアの意図された受信ノードにより識別できる。ノードへ秘密に送信されている不正シェアの識別は、公然検証可能なシークレット共有（Publically Verifiable Secret Sharing：PVSS）の技術を用いて公に検証可能にできる。このような技術は、PVSSが使用されず及び不正シェアが送信されるときに不正シェアの受信側がオフラインである若しくはネットワークの根本部分から切り離されている場合に起こり得る、不正送信者の識別において起こり得る遅延を回避し得る。

【0116】

矛盾したシェアを異なるノードに提供するような不正行為は、悪意ある行為を阻止するネットワークにより解決され得る。例えば、ノードが他のノードにより悪意あるパーティとして識別されると、多数のノードが協力して該悪意あるパーティにペナルティを科してよい。例えば、ノードは、不正パーティによりブロックチェーンネットワークに預けられた（デジタル通貨、トークン、又は他の掛け金若しくは価値）デジタルアセットに関連する措置を行ってよい。例えば、ブロックチェーンネットワークは、デジタル通貨、トークン、掛け金若しくは価値を引き換え不可（unredeemable）アドレスへ転送することにより、それらを焼却（burn）してよい。或いは、ブロックチェーンネットワークは、拒否するという他のノードとの総意に達することにより、このようなデジタルアセットを没収してよい。不正を行うノードではないノードは、不正を行うノードを排除するために協力することにより（例えば、鍵シェアを効果的に無効化することにより、例えば、ノードが議会プロトコルに参加するのを排除することにより、又は秘密鍵を再共有し及び不正を行うノードにシェアを割り当てないことにより）、不正行為を阻止してもよい。

【0117】

上述のECDSA技術は、TEEの使用を通じて拡張されてよい。例えば、Ibrahim他に基づく閾値ECDSA署名技術は、ここではByzantine敵対者と呼ばれる強力な形式の敵対者を予期している。この種の敵対者は、勝手に振る舞うことがある。例えば、彼らは、署名処理に参加すること又は途中でパーティを停止することを拒否するだけでなく、誠実に参加するふりをして、不正情報を送信することもある。しかしながら、TEEを用い、及びシークレット秘密鍵シェアが格納されるTEEのenclave内で署名に使用するためのデータを生成することにより、enclaveが有意な数において危険に晒される可能性が非常に低いので、追加セキュリティが提供され得る。各TEEが１つより多くの鍵シェアに割り当てられる場合、例えば、起こり得る危険に晒されるTEEの数は、ｎが充分に大きいと仮定すると、敵対者に対するロバスト性の閾に近付かないことが無理なく期待され得る。これは、鍵シェアの合計数に対して少ない割合の不正敵対者に対して耐性がある場合、プロトコルがセキュアであることを可能にする。

【0118】

例えば、全ノードがTEEを有する場合、enclave内に格納されたシークレットの取得は、TEEの製造者が堕落していないならば、ノードへの物理アクセスによってのみ、多大な努力及び費用によってのみ、達成され得る。このような製造者レベルの堕落は、管理可能であることが期待される。例えば、製造者が、多数の公開鍵が誠実なTEEに対応すると偽って主張しようとした場合、彼らは、秘密鍵シェアへの直接アクセスを獲得し、攻撃を始める可能性がある。しかしながら、このような攻撃は、製造者が他のノードからの支援を伴わずに有効署名を生成できるために、充分な数の鍵シェアを要求し得る。これは、非常に高価になり得る全部の掛け金の大部分を蓄積することを意味し得る。さらに、攻撃を実行することにより、保持している掛け金の価値の大部分が破壊され得る。

【0119】

TEEが使用されるとき、「堕落したノード」に対するプロトコルのロバスト性を意図することが有用である。堕落したノードは、TEEの外部のハードウェアが間違いを含むが、TEEの完全性が危険に晒されないノードである。堕落したノードは、どんな情報をenclaveが受信し及び受信しないかについて制御を有してよい。特に、堕落したノードは、停止し、つまりプロトコルへの参加を控えてよい。プロトコルに提供される情報がenclave内に秘密に保持された秘密鍵により署名される必要のある場合（対応する公開鍵が、アテステーション中に認証された場合）、秘密鍵はenclave自体と同じくらい信頼できる。したがって、堕落したノードは、勝手な（認証された）情報をプロトコルに送信することができず、停止することにより、又は例えば古い情報を提供することにより誤って動作するようenclaveを欺くことを試みることにより、邪魔をしようとするだけである。次に、堕落したノードでは、成功した攻撃は、完全な署名を生成するのに充分な数の部分署名を収集することを必要とし得る。

【0120】

幾つかの実施形態では、非ECDSA署名方式を含む他の閾値方式が使用されてよい。

【0121】

図３は、スクリプトに基づくブロックチェーン相互作用に関連付けられたトランザクションの例示的な実施形態３００を、図の形式で示す。図３に示す例示的な実施形態３００は、ブロックチェーンの第１状態３０６をエンコードする前のブロックチェーントランザクション３０２と、ブロックチェーンの第２状態３０８をエンコードするアンロックブロックチェーントランザクション３０４と、を示す。例示的な実施形態３００では、第１時間における現在状態３０６は、前のトランザクション３０２に埋め込まれたパラメータとして表される。一実施形態では、アンロックトランザクション３０４は、次の状態３０８を表すパラメータを含む。

【0122】

例示的な実施形態３００では、トランザクション３０２及び３０４は、１つ以上のインプット及び１つ以上のアウトプットを含むフィールド値セットである。幾つかの実施形態では、インプット及びアウトプットは、デジタルアセットの制御を少なくとも１つのエンティティから少なくとも１つの別のエンティティへ移転する意図を反映する。例示的な実施形態３００では、前のトランザクション３０２は、ブロックチェーンに含まれる最も現在の確認済みトランザクションである。例示的な実施形態３００では、アンロックトランザクション３０４は、未だ確認されていない且つ未だブロックチェーンに含まれていない中間的な将来のトランザクションである。アンロックトランザクション３０４のインプットの各々は、前のトランザクション３０２のアウトプットを受信する。

【0123】

幾つかのブロックチェーン技術は、ビットコインと同様に、楕円曲線デジタル署名アルゴリズム（elliptic curve digital signature algorithm：ECDSA）をデジタル署名のための関数として使用する。実施形態では、ECDSAは、UTXOがそれ自体の正当な所有者へのみ移転されることを保証するために使用される暗号化デジタル署名である。ビットコインにおける楕円曲線デジタル署名（elliptic curve digital signature：ECDS）は、標準的に、末尾に付加される署名ハッシュフラグ（SIGHASH type）と共に現れる。しかしながら、本開示の技術は、SIGHASH typeを実装しないブロックチェーン技術と共に使用可能であることが想定される。このようなブロックチェーン技術では、ECDSは、特定のブロックチェーン技術の署名生成原理に準拠することが想定される。

【0124】

実施形態では、SIGHASH typeは、連続化され（serialized）（例えば正規化され（canonicalized））及びハッシュされる前に、トランザクションから抽出されるべきフィールドセットを表す。例えば、SIGHASH typeは、トランザクションのどのフィールドが署名に含まれるかに影響を与え得る。幾つかの例では、SIGHASH typeは、SIGHASH_ALL、SIGHASH_NONE、SIGHASH_SINGLE、又はSIGHASH_ANYONECANPAYのうちの１つ以上であり得る。一実施形態では、タイプSIGHASH_ALLは、インプットスクリプトを除く、トランザクション内の全部のフィールドがハッシュされ署名されるべきであることを示す。一実施形態では、タイプSIGHASH_NONEは、アウトプットが署名される必要のないことを示す。これは、他者がトランザクションを更新することを可能し得る。一実施形態では、タイプSIGHASH_SINGLEは、インプットが署名されるが、シーケンス番号は空白であることを示す。したがって、他者はトランザクションの新しいバージョンを生成できるが、署名されたアウトプットだけがインプットとして同じ位置に存在する。一実施形態では、タイプSIGHASH_ANYONECANPAYは、他のタイプと組み合わせられ、SIGHASH_ANYONECANPAYを含むインプットが署名されること、しかし他のインプットは署名される必要のないことを示す。SIGHASH typeは、SIGHASH typeを示す値により表すことができる。例えば、幾つかの実装では、SIGHASH_ALLは１の値を有するバイトにより表され、SIGHASH_NONEは２の値を有するバイトにより表され（例えば、「００００００１０」）、SIGHASH_SINGLEは３の値を有するバイトにより表され（例えば、「００００００１１」）、SIGHASH_ANYONECANPAYは８０の値を有するバイトにより表される（例えば、「０１０１００００」）。SIGHASH typeを組み合わせることは、幾つかの実施形態では、バイト値を一緒に加算することにより実行される。

【0125】

幾つかの例では、SIGHASH typeにより決定されるトランザクションフィールドセットは、SIGHASH typeにより決定されるような、バイトにエンコードされた対応するトランザクションのサブセットを表す。例えば、SIGHASH_ANYONECANPAYのSIGHASH typeにより、１つのトランザクションインプットのみが、署名に含まれる。

【0126】

一実施形態では、ECDSは、識別符号化規則（distinguished encoding rules：DER）フォーマットでエンコードされた２５６ビット数値のペア（r,s）により表される。しかしながら、本開示の技術は、基本符号化規則（basic encoding rules：BER）又は標準符号化規則（canonical encoding rules：CER）のような他の符号化フォーマットと共に使用可能であることに留意する。ECDSAで使用されるパラメータは、K（座標（x,y）を有する楕円曲線点）、k（２５６ビット数値、通常、秘密鍵を保護するためにランダムである）、G（次数nを有する楕円曲線上の基点、n×G＝０、ここで０はアイデンティティ楕円曲線点を表し、nは楕円曲線有限フィールド内のパラメータとして使用される大きな素数である）、r（ECDS内の２５６ビット数値のうちの一方である）、s（署名内の２５６ビット数値のうちの他方である）、k^－１（kのモジュラ逆数、つまりk^lk＝l mod n）、m（署名されているメッセージ／データ、実施形態では、これは、ハッシュ関数により２５６ビットにサイズ変更される）、a（秘密鍵、例えば２５６ビット数値）、を含む。実施形態では、ECDSは以下のように生成される。

【0127】

先ず、kに生成元（generator）を乗じることにより、楕円曲線点Kが決定される：K＝k×G。次に、Kから点xが決定され、ECDS内の２５６ビット数値の第１の数値rが、式r＝x mod nに従い決定される。次に、ECDS内の２５６ビット数値の第２の数値sが、式s＝k^l（m＋r×a） mod nに従い決定される。最後に、（r,s）がDERフォーマットにエンコードされる。署名（r,s）、メッセージ／データm、及び秘密鍵aに対応する公開鍵Aが与えられると、署名が検証できる。署名を検証するために、v=s^－l×（m×G＋r×y）が計算される。v＝rならば、署名は有効である。

【0128】

ビットコインは、「スクリプト（Script）」と呼ばれる記述システムを使用する。本開示では、種々のスクリプトオペコード及びキーワードが、種々の動作を実行するために参照される。しかしながら、他のブロックチェーン技術が異なる命令セットを実装し得ることが想定され、したがって本開示に記載のオペコードはScript内の特定オペコード以外のオペコードにより実行される動作の説明として考えられる。幾つかの実施形態では、記述システムは、チューリング（Turing）不完全命令セット（例えば、ループ、再帰、「goto」文、等をサポートしない）である。他の実施形態では、記述システムはチューリング完全命令セットである。

【0129】

本開示の特定の実施形態は、記述システム又は記載の命令セットを実装する他のシステムが、ビットコインの特定の実装では違反限度である、単一スクリプト内に２００個より多くの命令（例えば、オペコード）を可能にするという仮定の下で動作する。同様に、本開示の特定の実施形態は、本開示で参照されるオペコードにより提供される機能がオペコードスクリプト／命令セットを実行するシステム内に存在し可能にされることを更に仮定する。ビットコインの幾つかの実装では、これらのオペコードのうちの１つ以上は、デフォルトで無効にされ又は制限されてよい。

【0130】

本開示で参照されるオペコードの例は、以下を含む：
OP_ECPX：楕円曲線点のｘ座標を返す。
OP_ADD：スタックにある上位２個のアイテムを加算する。
OP_BIGMOD：スタックにある上位２個のアイテムを除算した後の余りを返す。
OP_BIGMODADD：スタックの上位２個のアイテムのモジュロ和の、スタックの３番目のアイテムのモジュロを実行する。
OP_BIGMODINVERSE：負の指数演算のモジュロを実行する。
OP_BIGMODMUL：スタックの上位２個のアイテムのモジュロ積の、スタックの３番目のアイテムのモジュロを実行する。
OP_CAT：スタックにある上位２個のアイテムを連結する。
OP_CHECKSIG：公開鍵及び署名がスタックからポップされ、SIGHASH typeに従いトランザクションフィールドの署名に対して検証される。署名が有効ならば１が、その他の場合に０が返される。
OP_CHECKSIGVERIFY：OP_CHECKSIGと同じ機能だが、OP_VERIFYが後に実行される。
OP_DERENCODE：スタックにある上位２個のアイテムをDERフォーマットでエンコードする。
OP_DUP：１番上のスタックアイテムを複製する。
OP_ECPMULT：スタックにある上位２個のアイテムの楕円曲線乗算を実行する。
OP_ELSE：先行するOP_IF又はOP_NOTIF又はOP_ELSEが実行されない場合、これらのステートメントが実行され、その他の場合に、先行するOP_IF又はOP_NOTIF又はOP_ELSEが実行された場合、これらのステートメントは実行されない。
OP_ENDIF：if／elseブロックを終了する。
OP_EQUAL：入力が正確に等しい場合に１を、その他の場合に０を返す。
OP_EQUALVERIFY：OP_EQUALと同じだが、OP_VERIFYを後に実行する。
OP_FROMALTSTACK：インプットを主スタックの１番上に置き、代替スタックから除去する。
OP_HASH２５６：最初にSHA－２５６で、次にRIPEMD－１６０で、インプットが２回ハッシュされる。
OP_IF：１番上の値が偽でないならば、ステートメントが実行され、１番上の値が除去される。
OP_NOTIF：１番上の値が偽ならば、ステートメントが実行され、１番上の値が除去される。
OP_ROLL：スタック内でnアイテムの深さにあるアイテムが１番上に移動される。
OP_SUBSTR：文字列のセクションを返す。
OP_SWAP：スタックにある上位２個のアイテムがスワップされる。
OP_TOALTSTACK：インプットを代替スタックの１番上に置き、主スタックから除去する。
OP_VERIFY：一番上のスタック値が真でない場合、トランザクションを無効としてマークする。

【0131】

一実施形態では、ECDS生成スクリプトはオペコードを用いて生成でき、末尾にSIGHASH typeを付加することにより、署名生成スクリプトOP_GENSIGを生成するよう拡張可能である。
［表１］

【表1】

【0132】

表１に示した上述のスクリプトでは、<SIGHASH Byte>、メッセージ<m>、秘密鍵<a>、及び数値<k>は、上述の順序で（例えば、４個のアイテムの挿入後に、数値<k>がスタックの１番上にあり、続いて秘密鍵<a>、続いてメッセージ<m>、最後に<SIGHASH Byte>が続く）主スタックに入力される（例えば、先出しの最後）。

【0133】

スクリプト演算「OP_DUP OP_TOALTSTACK<PubKG> OP_ECPMULT」の実行は、数値<k>を代替スタックにコピーさせる。ここで<k>は楕円曲線生成器<PubK G>に対して乗算されて、主スタックの一番上にある楕円曲線点Kを生成する。

【0134】

スクリプト演算「OP_ECPX <N> OP_BIGMOD OP_DUP OP_TOALTSTACK」の実行は、rをKのx座標 mod nから計算させる。rのコピーは代替スタックにプッシュされる。

【0135】

スクリプト演算「<N> OP_BIGMODMUL <N> OP_BIGMODADD」、「OP_FROMALTSTACK OP_SWAP OP_FROMALTSTACK <N>」、及び「OP_BIGMODINVERSE <N> OP_BIGMODMUL」の実行は、k^－l（m＋r×a） mod nからsを計算する。最後に、スクリプト演算「OP_DERENCODE OP_SWAP OP_CAT」の実行は、r及びsをDERフォーマットでエンコードさせ、<SIGHASH Byte>と連結させる。

【0136】

本開示では、このスクリプトはOP_GENSIGと呼ばれる。したがって、本開示の実施形態におけるOP_GENSIGへの参照は、上述のスクリプトで実行される演算の短縮表現と考えられるべきである。

【0137】

図４は、一実施形態により解決される、スクリプトに基づくブロックチェーン相互作用に関連付けられたブロックチェーンへのアクセスに伴う例示的な問題４００を図形式で示す。例示的な問題である図４に示される４００では、トランザクション４０２（例えば、図３に関連して記載した前のトランザクション３０２のような前のトランザクション又はアンロックトランザクション３０４）内のロックスクリプト４０６は、ブロックチェーン４０４にアクセスできない。

【0138】

上述のように、幾つかの実施形態では、トランザクション４０２は、ブロックチェーンに含まれる最も現在（most current、最近）の確認済みトランザクションである。同様に、幾つかの実施形態では、トランザクション４０２は、未だ確認されていない、未だブロックチェーンに含まれていない、前のトランザクションにより制御されるデジタルアセットの少なくとも一部の制御を移転しようとする試みを表す、将来のトランザクションである。

【0139】

幾つかの実施形態では、ロックスクリプト４０６は、アウトプットを移転するために満たす必要のある条件を指定することにより、トランザクションを妨げるスクリプトである。特に、ロックスクリプト４０６の実行は、ブロックチェーンシステムの検証ノードによる実行の結果として、実行したアンロックスクリプトからのデータを受け付け、該データに基づき特定の演算を実行し、アンロックスクリプトの実行がロックスクリプトを成功裏に「アンロック（unlocked、解除）」したか（つまり、ロックスクリプト内で設定された条件セットを満たしたか）否かを示す結果を返す。幾つかの実施形態では、ロックスクリプト４０６は、トランザクションの検証が成功するために（例えば、アンロックスクリプトにより提供されたデータにより）満たされなければならない１つ以上のデータ制約を定める。例えば、ロックスクリプト４０６は、トランザクション４０２の関連するデジタルアセットをアンロックするために、アンロックスクリプト内で特定データが提供されることを要求し得る。

【0140】

例示的な問題４００に示したように、トランザクション４０２のロックスクリプト４０６は、ブロックチェーン４０４をクエリし、例えばブロック数を決定できない。トランザクション４０２のロックスクリプト４０６は、ブロックチェーン４０４の最初のブロック４０８（「genesisブロック」とも呼ばれる）、ブロックチェーン４０４の内部ブロックのいずれか（例えば、ブロック４１０）、又はブロックチェーン４０４の最後のブロック４１２を含む、ブロックチェーン４０４のブロックもクエリできない。本願明細書に記載の方法は、トランザクション４０２のロックスクリプト４０６が、ブロックチェーン４０４の最初のブロック４０８、内部ブロック（例えば、ブロック４１０）、又は最後のブロック４１２を含む、ブロックチェーン４０４のブロックをクエリすることを可能にする。

【0141】

図５は、一実施形態により解決される、スクリプトに基づくブロックチェーン相互作用に関連付けられたブロックチェーン内のブロックへのアクセスに伴う例示的な問題５００を図形式で示す。例示的な問題である図５に示される５００では、トランザクション５０２（例えば、図３に関連して記載した前のトランザクション５０２のような前のトランザクション又は図３に関連して記載したアンロックトランザクション３０４のようなアンロックトランザクション）内のロックスクリプト５０６は、ブロック５０４（つまり、最初のブロック、内部ブロック、又は最後のブロック）のようなブロックチェーン内のブロックにアクセスできない。

【0142】

上述のように、幾つかの実施形態では、トランザクション５０２は、ブロックチェーンに含まれる最も現在（most current、最近）の確認済みトランザクションである。同様に、幾つかの実施形態では、トランザクション５０２は、未だ確認されていない、未だブロックチェーンに含まれていない、前のトランザクションにより制御されるデジタルアセットの少なくとも一部の制御を移転しようとする試みを表す、将来のトランザクションである。

【0143】

幾つかの実施形態では、本願明細書に記載のように、ロックスクリプト５０６は、アウトプットを移転するために満たす必要のある条件を指定することにより、トランザクションを妨げるスクリプトである。例示的な問題５００に示したように、トランザクション５０２のロックスクリプト５０６は、ブロックチェーンのブロック５０４をクエリし、例えばブロック数を決定し、又は特定のトランザクションにアクセスできない。例示的な問題５００に示したように、トランザクション５０２のロックスクリプト５０６は、ブロックチェーンのブロック５０４をクエリできず、ブロック５０４のブロックヘッダ５０８をクエリできず、及びブロック５０４のトランザクションをクエリできない。ブロック５０４がトランザクション５０２（ブロック５０４のトランザクション５１０のトランザクションＴx_i５１２として示される）を含む一実施形態では、トランザクション５０２のロックスクリプト５０６は、トランザクションＴx_i５１２にもクエリできない（例えば、ロックスクリプト５０６を含むトランザクションをクエリできない）。本願明細書に記載の方法は、トランザクション５０２のロックスクリプト５０６が、ブロックチェーンのブロック５０４にクエリし、ブロック５０４のブロックヘッダ５０８をクエリし、ブロック５０４のトランザクション５１０をクエリし、及びブロック５０４のトランザクション５１０のトランザクションTxi５１２をクエリすることを可能にする（例えば、ロックスクリプトが、ロックスクリプト５０６を含むトランザクションをクエリすることを可能にする）。

【0144】

図６は、一実施形態による、データが、スクリプトに基づくブロックチェーン相互作用のためのブロックヘッダであることを検証される、例示的な環境６００を図形式で示す。ブロックヘッダは、ブロックに関するデータを含む、ブロックチェーンのブロックの一部である。例えば、ブロックヘッダ６０２は、ブロックチェーン実装バージョン（「nVersion」）を格納する最初の４バイト、ブロックチェーンの前のブロックのハッシュを格納する次の３２バイト（又は２５６ビット）（「HashPrevBlock」）、ブロックのトランザクションのマークル木のハッシュを格納する次の３２バイト（「HashMerkleRoot」、これは本願明細書で詳述される）、ブロックの生成時間を格納する次の４バイト（「nTime」）、ブロックの３２ビット採掘難易度値を格納する次の４バイト（「nBits」）、及びブロックのランダムシードを格納する最後の４バイト（「nNonce」）、を有する８０バイトのデータである。

【0145】

図から分かるように、ブロックヘッダ６０２が、ロックスクリプトへのインプットとして使用される（例えば、アンロックスクリプトとして提供される）データである場合、ブロックヘッダ６０２に対する制約をロックスクリプトへとエンコードすることにより、アンロックスクリプトデータは有効ブロックヘッダを含まなければならなず、そうでなければ有効なアンロックスクリプトではない。ブロックヘッダ６０２のようなブロックヘッダに対する３つの制約は、（ｉ）８０バイトの長さである、（ｉｉ）ブロックヘッダのnBitsが特定の採掘難易度値以上でなければならない、（ｉｉｉ）ブロックヘッダのdouble SHA２５６が採掘難易度値以下でなければならない、である。これらの制約の各々は別個のスクリプトとしてここに説明され、スクリプト同士のリンクの詳細（例えば、分岐制約及びスタックの維持）は説明を容易にするために省略される。

【0146】

３つのスクリプトは、スクリプト同士のリンクの詳細が省略されて、一緒に結合されて単一のスクリプトを形成し、これは、アンロックスクリプト内の<Data>が有効ブロックヘッダであることを検証するOP_CHECKBLOCKVERIFYスクリプトの一例である。図示の例では、３つのスクリプトは真又は偽を返すが、単一のスクリプトに一緒にリンクされてOP_CHECKBLOCKVERIFYスクリプトを生成するとき、OP_VERIFYが標準的に各スクリプトの末尾に追加される。考えられるように、OP_CHECKBLOCKVERIFYスクリプトの他の実装が、実施されてよく、本開示の範囲内にあると考えられる。

【0147】

ステップ６０４で、意図されるブロックヘッダはアンロックスクリプトとして提供され、<Data>として示される。

【0148】

ステップ６０６で、<Data>のサイズが８０バイトであること（例えば、第１制約）を検証する第１スクリプトが実行される。<Data>のサイズが８０バイトであることを検証する第１スクリプトは、表２に示される。
［表２］

【表2】

【0149】

ステップ６０８で、ブロックヘッダの「nBits」フィールドがブロックヘッダ採掘難易度値以上であることを検証する第２スクリプトが実行される。ブロックヘッダの「nBits」フィールドがブロックヘッダ採掘難易度値以上であることを検証する第２スクリプトは、表３に示される。留意すべきことに、表３に示されるスクリプト内の採掘難易度値「<０x１D００FFFF>」は、ビットコイン仕様自体の最小採掘難易度である。一実施形態では、採掘難易度値は、アンロックスクリプトのデータアイテムとして提供される。一実施形態では、より大きな採掘難易度値（例えば、０x１D００FFFより大きな値）が目標採掘難易度として使用される。一実施形態では、より小さな採掘難易度値（例えば、０x１D００FFFより小さな値）が目標採掘難易度として使用される。
［表３］

【表3】

【0150】

ステップ６１０で、ブロックヘッダの（上述のオペコードOP_HASH２５６により実施される）double SHA２５６が示された採掘難易度値以下であることを検証する第３スクリプトが実行される。ブロックヘッダのdouble SHA２５６が示された採掘難易度値以下であることを検証する第３スクリプトは、表４に示される。表４に示される第３スクリプトは、以下の２つの追加オペコードを導入する。

【0151】

OP_LBYTESHIFT：任意のサイズのデータに対して左バイトシフトを実行する。
OP_BIGLESSTHANOREQUAL：任意のサイズのデータを数値として解釈し、２つの数値を比較して第１数値が第２数値以下であるかどうかを決定する。
［表４］

【表4】

【0152】

図７は、一実施形態による、データが、スクリプトに基づくブロックチェーン相互作用におけるブロックヘッダであることを検証する例示的な処理７００をフローチャート形式で示す。処理７００の一部又は全部は、実行可能命令及び／又は他のデータにより構成された１つ以上のコンピュータシステムの制御下で実行可能であり、１つ以上のプロセッサで共同で実行する実行可能命令として実装可能である。実行可能命令及び／又は他のデータは、非一時的コンピュータ可読記憶媒体に格納可能である（例えば、磁気、光、又はフラッシュ媒体に永続的に格納されたコンピュータプログラム）。例示的な処理７００は、図１と関連して説明したブロックチェーンネットワーク１００のようなブロックチェーンネットワークの、図１と関連して説明したノード１０２のうちの１つのようなノードにより実行されてよい。つまり、図１と関連して記載したノード１０２のうちの１つのようなノードは、データが図７と関連して記載したスクリプトに基づくブロックチェーン相互作用におけるブロックヘッダであることを検証する例示的な処理７００を実行してよい。このようなノードは、任意の適切なコンピューティング装置で（例えば、データセンタ内のサーバにより、クライアントコンピューティング装置により、コンピューティングリソースサービスプロバイダの分散システム内の複数のコンピューティング装置により、又は図２と関連して記載したコンピューティング装置２００のような適切な電子クライアント装置により）構成されてよい。

【0153】

例示的な処理７００のステップ７０２で、システムは<Data>を受信する。例示的な処理７００のステップ７０４で、システムは、図６と関連して上述したように、OP_CHECKBLOCKVERIFYスクリプトを開始する。例示的な処理７００のステップ７０６で、システムは、例えば上述の表２に示したスクリプトを実行することにより、<Data>のサイズが８０バイトであることを検証する。例示的な処理７００のステップ７０８で、前のスクリプト（上述の表２に示したスクリプト）が合格したか（passed）否かが決定される。

【0154】

例示的な処理７００のステップ７０８で、前のスクリプトが合格しなかったと決定された場合、例示的な処理７００のステップ７１８で、<Data>は有効ブロックヘッダではなく、ロックスクリプトの解除は失敗する。

【0155】

例示的な処理７００のステップ７０８で、前のスクリプトが合格したと決定された場合、例示的な処理７００のステップ７１０で、システムは、例えば上述の表３に示したスクリプトを実行することにより、<Data>の「nBits」フィールドがブロックチェーン採掘難易度以上であることを検証する。例示的な処理７００のステップ７１２で、前のスクリプト（例えば上述の表３に示したスクリプト）が合格したか否かが決定される。

【0156】

例示的な処理７００のステップ７１２で、前のスクリプトが合格しなかったと決定された場合、例示的な処理７００のステップ７１８で、<Data>は有効ブロックヘッダではなく、ロックスクリプトの解除は失敗する。

【0157】

例示的な処理７００のステップ７１２で、前のスクリプトが合格したと決定された場合、例示的な処理７００のステップ７１４で、システムは、例えば上述の表４に示したスクリプトを実行することにより、<Data>のSHA２５６が要求される目標以下であることを検証する。例示的な処理７００のステップ７１６で、前のスクリプト（例えば上述の表４に示したスクリプト）が合格したか否かが決定される。

【0158】

例示的な処理７００のステップ７１６で、前のスクリプトが合格しなかったと決定された場合、例示的な処理７００のステップ７１８で、<Data>は有効ブロックヘッダではなく、ロックスクリプトの解除は失敗する。

【0159】

例示的な処理７００のステップ７１６で、前のスクリプトが合格したと決定された場合、例示的な処理７００のステップ７２０で、<Data>は有効ブロックヘッダではなく、ロックスクリプトの解除は成功する。

【0160】

図７に示した例示的な処理７００で実行される動作のうちの１つ以上は、並列を含む種々の順序及び組み合わせで実行されてよいことに留意する。

【0161】

図８は、一実施形態による、データが、スクリプトに基づくブロックチェーン相互作用のための前のブロックのブロックヘッダであることを検証される、例示的な環境８００を図形式で示す。本願明細書に記載のように、ブロックヘッダは、ブロックに関するデータを含む、ブロックチェーンのブロックの一部である。ブロックヘッダの一部は、前のブロックヘッダのハッシュ（「HashPrevBlock」）である。第１ブロックヘッダがロックスクリプトのインプットとして提供され（例えば、アンロックスクリプトの一部として提供され）、ブロックチェーン内の次のブロックのために意図された第２ブロックヘッダもロックスクリプトのインプットとして提供される（例えば、アンロックスクリプトの一部として提供される）場合、第１ブロックヘッダのハッシュが第２ブロックのHashPrevBlockであるという制約をロックスクリプト内にエンコードすることにより、第１ブロックヘッダのハッシュが第２ブロックのHashPrevBlockではないならば、２つのブロックヘッダは有効なアンロックスクリプトではない。

【0162】

ステップ８０４で、第１ブロックヘッダ８０２は、アンロックスクリプトのためのデータ（<Data １>として示される）として提供され、ステップ８１０で、以下に示すように、第２ブロックヘッダ８０８はアンロックスクリプトのためのデータ（<Data ２>として示される）として提供される。ステップ８０６で、図６及び７と関連して上述したOP_CHECKBLOCKVERIFYスクリプトのようなスクリプトは、<Data １>がブロックヘッダであることを検証するために使用される。ステップ８１２で、図６及び７と関連して上述したOP_CHECKBLOCKVERIFYスクリプトのようなスクリプトは、<Data ２>がブロックヘッダであることを検証するために使用される。

【0163】

ステップ８１４で、第１ブロックヘッダ<Data １>のdouble SHA２５６が、第２ブロックヘッダ<Data ２>のHashPrevBlockと等しいことを検証するスクリプトが実行れる。第１ブロックヘッダ<Data １>のdouble SHA２５６が、第２ブロックヘッダ<Data ２>のHashPrevBlockと等しいことを検証するスクリプトの一例は、表５に示される。表５に示すスクリプトは、<Data １>が<Data ２>の有効な直前ブロックであることを検証するOP_CHECKCHAINVERIFYスクリプトの一例である。考えられるように、OP_CHECKCHAINVERIFYスクリプトの他の実装が、実施されてよく、本開示の範囲内にあると考えられる。留意すべきことに、表５に示すOP_CHECKCHAINVERIFYスクリプトの最終オペコードは、実行後に「真」値がスタックに残るべきなので、OP_EQUALである。OP_CHECKCHAINVERIFYスクリプトが他のスクリプトとの結合の中で使用される一実施形態では、スクリプトの最終OP_EQUALオペコードは、OP_EQUALVERIFYオペコードに変更される。
［表５］

【表5】

【0164】

図９は、一実施形態による、データが、スクリプトに基づくブロックチェーン相互作用における前のブロックのブロックヘッダであることを検証する例示的な処理９００をフローチャート形式で示す。処理９００の一部又は全部は、実行可能命令及び／又は他のデータにより構成された１つ以上のコンピュータシステムの制御下で実行可能であり、１つ以上のプロセッサで共同で実行する実行可能命令として実装可能である。実行可能命令及び／又は他のデータは、非一時的コンピュータ可読記憶媒体に格納可能である（例えば、磁気、光、又はフラッシュ媒体に永続的に格納されたコンピュータプログラム）。例示的な処理９００は、図１と関連して説明したブロックチェーンネットワーク１００のようなブロックチェーンネットワークの、図１と関連して説明したノード１０２のうちの１つのようなノードにより実行されてよい。つまり、図１と関連して記載したノード１０２のうちの１つのようなノードは、データが図９と関連して記載したスクリプトに基づくブロックチェーン相互作用における前のブロックのブロックヘッダであることを検証する例示的な処理９００を実行してよい。このようなノードは、任意の適切なコンピューティング装置で（例えば、データセンタ内のサーバにより、クライアントコンピューティング装置により、コンピューティングリソースサービスプロバイダの分散システム内の複数のコンピューティング装置により、又は図２と関連して記載したコンピューティング装置２００のような適切な電子クライアント装置により）構成されてよい。

【0165】

例示的な処理９００のステップ９０２で、システムは、２つの意図されたブロックヘッダである<Data １>及び<Data ２>を受信する。例示的な処理９００のステップ９０４で、システムは、図８と関連して上述したように、OP_CHECKCHAINVERIFY処理を<Data １>及び<Data ２>に対して開始する。例示的な処理９００のステップ９０６で、システムは、図６及び７と関連して上述したように、OP_CHECKCHAINVERIFYスクリプトを<Data １>に対して実行することにより、<Data １>がブロックヘッダであることを検証する。

【0166】

例示的な処理９００のステップ９０８で、前のスクリプト（例えば、<Data １>に対するOP_CHECKBLOCKVERIFYスクリプト）が合格したか（つまり、OP_CHECKBLOCKVERIFYスクリプトが真を返したか）否かが決定される。例示的な処理９００のステップ９０８で、前のスクリプトが合格しなかったと決定された場合、例示的な処理９００のステップ９１０で、<Data １>は<Data ２>の前のブロックではなく、したがってロックスクリプトの解除は失敗する。

【0167】

例示的な処理９００のステップ９０８で、前のスクリプトが合格したと決定された場合、例示的な処理９００のステップ９１２で、システムは、図６及び７と関連して上述したように、OP_CHECKBLOCKVERIFYスクリプトを<Data ２>に対して実行することにより、<Data ２>がブロックヘッダであることを検証する。

【0168】

例示的な処理９００のステップ９１４で、前のスクリプト（例えば、<Data ２>に対するOP_CHECKBLOCKVERIFYスクリプト）が合格したか（つまり、OP_CHECKBLOCKVERIFYスクリプトが真を返したか）否かが決定される。例示的な処理９００のステップ９１４で、前のスクリプトが合格しなかったと決定された場合、例示的な処理９００のステップ９１６で、<Data ２>は有効なブロックヘッダではなく、例示的な処理９００のステップ９２２で、<Data １>は<Data ２>の前のブロックではなく、したがってロックスクリプトの解除は失敗する。

【0169】

例示的な処理９００のステップ９１４で、前のスクリプトが合格したと決定された場合、例示的な処理９００のステップ９１８で、システムは、<Data １>のdouble SHA２５６が<Data ２>の「HashPrevBlock」フィールドに等しいことを検証する。

【0170】

例示的な処理９００のステップ９２０で、<Data １>のdouble SHA２５６が<Data ２>の「HashPrevBlock」フィールドに等しいか否かが決定される。例示的な処理９００のステップ９２０で、<Data １>のdouble SHA２５６が<Data ２>の「HashPrevBlock」フィールドに等しくないと決定された場合、例示的な処理９００のステップ９２２で、<Data １>は<Data ２>の前のブロックではなく、したがってロックスクリプトの解除は失敗する。

【0171】

例示的な処理９００のステップ９２０で、<Data １>のdouble SHA２５６が<Data ２>の「HashPrevBlock」フィールドに等しいと決定された場合、例示的な処理９００のステップ９２４で、<Data １>は<Data ２>の前のブロックであり、したがってロックスクリプトの解除は成功する。

【0172】

図９に示した例示的な処理９００で実行される動作のうちの１つ以上は、並列を含む種々の順序及び組み合わせで実行されてよいことに留意する。

【0173】

図１０は、一実施形態による、データが、スクリプトに基づくブロックチェーン相互作用のためのブロックヘッダであることを検証される、例示的な環境１０００を図形式で示す。図１０に示す例示的な環境１０００は、図８及び９と関連して記載した動作の拡張である。図１０に示す例示的な環境１０００では、ブロックヘッダチェーン１０１０（つまり、ブロックヘッダのチェーン）の第１ブロックヘッダ１００２のdouble SHA２５６は、ブロックヘッダチェーン１０１０の第２ブロックヘッダ１００４のHashPrevBlockと比較され、ロックヘッダチェーン１０１０の第２ブロックヘッダ１００４のdouble SHA２５６は、ブロックヘッダチェーン１０１０の第３ブロックヘッダ１００６のHashPrevBlockと比較され、ブロックヘッダチェーン１０１０の第２～最後のブロック（図示しない）のdouble SHA２５６がブロックヘッダチェーン１０１０の最後のブロックヘッダ１００８のHashPrevBlockと比較されるまで、同様である。

【0174】

例示的な環境１０００は、表５に示すスクリプトを各ブロックペアについて繰り返すことにより、表５に示すOP_CHECKCHAINVERIFYスクリプトが追加ブロックへと一般化できることを示す。このようなスクリプトは、本願明細書でOP_CHECKBLOCKCHAINVERIFYと呼ばれる。

【0175】

一例として、OP_CHECKBLOCKCHAINVERIFYスクリプトは、ブロックヘッダチェーンの中のブロックヘッダ数、及びブロックヘッダチェーンのブロックヘッダをインプットパラメータとして取り入れ、OP_CHECKCHAINVERIFYを繰り返し実行してよい。表６は、スクリプトが、６個のブロックヘッダのチェーンを検証するためにどのように使用されるかの一例を示す。
［表６］

【表6】

【0176】

表７は、多数のブロックについてOP_CHECKCHAINVERIFYの動作を繰り返すOP_CHECKBLOCKCHAINVERIFYの実装の一例を示す。表７に示すOP_CHECKBLOCKCHAINVERIFYの例示的な実装では、繰り返される部分は、ブロックヘッダを通じて<d－１>個のループの値範囲（例えば、<d>個のブロックヘッダに対して<d－１>個のループ）をカバーし、順序を保存し及び維持するために、代替スタックを用いてブロックヘッダペアの各々に対してOP_CHECKCHAINVERIFY動作を実行する。
［表７］

【表7】

【0177】

図１１は、一実施形態による、データが、スクリプトに基づくブロックチェーン相互作用におけるブロックヘッダチェーンであることを検証する例示的な処理１１００をフローチャート形式で示す。処理１１００の一部又は全部は、実行可能命令及び／又は他のデータにより構成された１つ以上のコンピュータシステムの制御下で実行可能であり、１つ以上のプロセッサで共同で実行する実行可能命令として実装可能である。実行可能命令及び／又は他のデータは、非一時的コンピュータ可読記憶媒体に格納可能である（例えば、磁気、光、又はフラッシュ媒体に永続的に格納されたコンピュータプログラム）。例示的な処理１１００は、図１と関連して説明したブロックチェーンネットワーク１００のようなブロックチェーンネットワークの、図１と関連して説明したノード１０２のうちの１つのようなノードにより実行されてよい。つまり、図１と関連して記載したノード１０２のうちの１つのようなノードは、データが図１１と関連して記載したスクリプトに基づくブロックチェーン相互作用におけるブロックヘッダチェーンであることを検証する例示的な処理１１００を実行してよい。このようなノードは、任意の適切なコンピューティング装置で（例えば、データセンタ内のサーバにより、クライアントコンピューティング装置により、コンピューティングリソースサービスプロバイダの分散システム内の複数のコンピューティング装置により、又は図２と関連して記載したコンピューティング装置２００のような適切な電子クライアント装置により）構成されてよい。

【0178】

例示的な処理１１００のステップ１１０２で、システムは<Data １>～<Data n>の順序付きセットを受信する。例示的な処理１１００のステップ１１０４で、システムは、図１０と関連して上述したように、OP_CHECKBLOCKCHAINVERIFYスクリプトを順序付きデータセットに対して開始する。

【0179】

例示的な処理１１００のステップ１１０６で、システムは、順序付きデータセットの順序に少なくとも部分的に基づき、順序付きデータセットから第１データアイテム（例えば<Data １>）を選択する。例示的な処理１１００のステップ１１０８で、システムは、順序付きデータセットの順序に少なくとも部分的に基づき、順序付きデータセットから第２データアイテム（例えば<Data ２>）を選択する。一実施形態では、システムは、例えば図６及び７と関連して上述したOP_CHECKBLOCKVERIFYスクリプトを用いて、第１データアイテム及び第２データアイテムが有効なブロックヘッダであることを検証する。

【0180】

例示的な処理１１００のステップ１１１０で、システムは、図８及び９と関連して記載されるように、表５に示すように第１データアイテム及び第２データアイテムに対してOP_CHECKCHAINVERIFYを実行することにより、第１データアイテムが第２データアイテムの前のブロックであることを検証する。

【0181】

例示的な処理１１００のステップ１１１２で、第１データアイテム及び第２データアイテムに対するOP_CHECKCHAINVERIFYスクリプトが合格したか否か（つまり、第１データアイテムが第２データアイテムの中のブロックヘッダの前のブロックヘッダであるか否か）が決定される。

【0182】

例示的な処理１１００のステップ１１１２で、第１データアイテム及び第２データアイテムに対するOP_CHECKCHAINVERIFYスクリプトが合格しなかったと決定された場合、例示的な処理１１００のステップ１１１４で、第１データアイテムは第２データアイテムの中のブロックヘッダの前のブロックヘッダではなく、例示的な処理１１００のステップ１１１６で、順序付きデータセットは有効なブロックヘッダチェーンではない。

【0183】

例示的な処理１１００のステップ１１１２で、第１データアイテム及び第２データアイテムに対するOP_CHECKCHAINVERIFYスクリプトが合格したと決定された場合、例示的な処理１１００のステップ１１１８で、順序付きデータセットの中に更にデータが存在するか否かが決定される。

【0184】

例示的な処理１１００のステップ１１１８で、順序付きデータセットの中に更にデータが存在すると決定された場合、例示的な処理１１００のステップ１１２０で、第２データアイテムが例示的な処理１１００において第１データアイテムになり、例示的な処理１１００のステップ１１２２で、データ順序に少なくとも部分的に基づき、新しい第２データアイテムが順序付きデータセットから選択され、例示的な処理１１００のステップ１１１０で、システムは、図８及び９と関連して記載した、表５に示されるような新しい第１データアイテム及び新しい第２データアイテムに対してOP_CHECKCHAINVERIFYを実行することにより、新しい第１データアイテムが新しい第２データアイテムの前のブロックであることを検証する。

【0185】

例示的な処理１１００のステップ１１１８で、順序付きデータセットの中に更にデータが存在しないと決定された場合、順序付きデータセットは有効なブロックヘッダチェーンである。

【0186】

図１１に示した例示的な処理１１００で実行される動作のうちの１つ以上は、並列を含む種々の順序及び組み合わせで実行されてよいことに留意する。

【0187】

図１２は、一実施形態による、スクリプトに基づくブロックチェーン相互作用における、使用可能なブロックヘッダのマークル木を示す例示的な環境１２００を図形式で示す。マークル木（「バイナリハッシュ木」とも呼ばれる）は、ブロック内のトランザクションのセットを検証するために使用されるデータ構造である。マークル木は、トランザクションの暗号ハッシュを含む二分木である。しかしながら、データのハッシュ及び連結を繰り返すことにより、マークル木は単一のハッシュ値（例えば、単一の３２バイト又は２５６ビット値）として格納され得る。

【0188】

例示的な環境１２００で、マークル木１２０４は、（ｉ）ブロックのトランザクションの各々のハッシュを計算し、（ｉｉ）ハッシュのペアを選択し、それらを一緒に連結し、（ｉｉｉ）連結値のハッシュを計算し、及び（ｉｖ）最終ハッシュ値（「マークルルート」）が生成されるまで、木の連続する上位レベルで処理を繰り返すことにより、生成される。このマークルルートは、次にブロックヘッダに「HashMerkleRoot」値として挿入される。

【0189】

例えば、トランザクション１２０６から開始して、トランザクションのハッシュ１２０８が計算される。本願明細書で使用されるように、トランザクションはT_Aとして参照され、トランザクション１２０６のハッシュ１２０８はH（T_A）として参照される。同様に、トランザクション（T_B）はハッシュ１２１２H（T_B）を有する。ハッシュ１２１６を生成するために、左の値は、ハッシュ１２１４される前に右の値と連結される。したがって、ハッシュ１２１６はH（H（T_A）＋H（T_B））である。ここで、「＋」演算子は、この場合、連結を表すためにオーバロードされる（overloaded）（例えば、H（T_A）が「１２３４」であり且つH（T_B）が「５６７８」である場合、H（T_A）＋H（T_B）は「１２３４５６７８」であり、H（H（T_A）＋H（T_B））は「１２３４５６７８」のハッシュである）。

【0190】

例示的な環境１２００は、マークル枝（Merkle branch）も示す。マークル枝は、マークルルートと結合された、マークル木の中のノードのセットであり、特定のリーフノード（つまり特定のトランザクション）のデータがマークル木の中にあることを検証するために使用できる。マークルルート及びマークル枝が与えられると、マークル木の中の所与のトランザクション（例えば、トランザクション１２１８）の存在は、以下のように検証できる。先ず、トランザクションのハッシュ１２２０が計算される。次に、マークル木の次のレベルのハッシュ１２２４が計算される。しかしながら、上述のように、マークル木の次のレベルのハッシュ１２２４は、他のトランザクション（例えば、マークル木の中のトランザクション１２１８の対の片方であるトランザクション）のハッシュ１２２２を必要とする。このハッシュ１２２２は、マークル枝の中の第１ノードである。

【0191】

ハッシュ１２２４が与えられると、マークル木の次のレベルのハッシュ１２２６が計算される。この計算は、マークル木の他方のトランザクション（例えば、他の枝）のハッシュ１２１６を必要とする。このハッシュ１２１６は、マークル枝の中の第２ノードである。考えられるように、マークル木の各レベルで、マークル枝は、木の「他の」枝の中のトランザクションセットのハッシュを必要とする。したがって、ハッシュ１２３０の左の枝がトランザクション２１１８を含む枝であると仮定すると（上述のように計算できる）、ハッシュ１２３０を計算するために、マークル枝の中のもう一方のノードである右の枝のハッシュ１２２８が必要である。最後に、マークルルートを計算するために、マークル木の右側全体のハッシュ１２３２が必要である。トランザクション１２１８がマークル木１２０４の中にあることを検証するために使用可能なマークル枝は、ハッシュ１２３０、ハッシュ１２２８、ハッシュ１２１６、及びハッシュ１２２２である。木が深さ４を有するので、４個のノードがマークル枝の中にある。留意すべきことに、マークル木の深さは、ブロック内のトランザクションの数に依存し、トランザクション数のlog_２である（つまり、５１２個のトランザクションでは、木は９の深さを有し、マークル枝はノードが９個のノードを有することを検証し、１０２４個のトランザクションでは、ツリーは１０の深さを有し、マークル枝はノードが１０個のノードを有することを検証し、２０４８個のトランザクションでは、木が１１の深さを有し、マークル枝がノードが１１個のノードを有することを検証し、以下同様である）。例えば、ビットコインブロックの中のブロック当たりの平均トランザクション数が約２０００である場合、標準的なブロックは深さ１１のマークル木を有する。

【0192】

図１３は、一実施形態による、トランザクションが、スクリプトに基づくブロックチェーン相互作用のためのブロックヘッダに含まれることを検証される、例示的な環境１３００を図形式で示す。本願明細書に記載のように、ブロックヘッダは、ブロックに関するデータを含む、ブロックチェーンのブロックの一部である。ブロックヘッダの一部は、ブロック内のトランザクションを検証できない、マークル木のマークルルートである（「HashMerkleRoot」）。ブロックヘッダが、トランザクションのマークル枝及びトランザクションと一緒にロックスクリプトのインプットとして提供される（例えば、アンロックスクリプトとして提供される）場合、ブロックヘッダのHashMerkleRootが、マークル枝及びトランザクションから計算された計算されたマークルルートと同じであるという制約をエンコードすることにより、ブロックヘッダのHashMerkleRootが計算されたマークルルートと同じでないならば、ブロックヘッダ、マークル枝、及びトランザクションは有効なアンロックスクリプトではない。

【0193】

ステップ１３０４で、第１ブロックヘッダ１３０２はアンロックスクリプトのためのデータ（<Data １>と示される）として提供される。ステップ１３０６で、図６及び７と関連して上述したOP_CHECKBLOCKVERIFYスクリプトのようなスクリプトは、<Data １>がブロックヘッダであることを検証するために使用される。ステップ１３０８で、HashMerkleRootは有効なブロックヘッダから抽出される。

【0194】

ステップ１３１２で、マークル枝１３１０はアンロックスクリプトのためのデータ（<Data ２>と示される）として提供される。本願明細書で示されないが、約１０、１１、又は１２であってよいマークル枝１３１０は、本願明細書に記載のように、特定ノードが連結動作への左のインプットであるか又は連結動作への右のインプットであるかを示す符号化形式で提供される。

【0195】

表８は、OP_CALCMERKLEROOTの例示的な実装を示す。ここで、マークル枝１３１０は、ペア<hash_１>、<x_１>、<hash_２>、<x_２>、...、<hash_d>、<x_d>及び値<d>の集合を含む符号化形式で提供される。ここで、<d>はどれ位多くのペアがペアの集合の中にあるかを示し、各<hash_i>はマークル木からの値のハッシュであり、各<x_i>は左連結又は右連結かを示す値（例えば、０又は１）である。表８に示すOP_CALCMERKLEROOTの例示的な実装では、<x_i>内の１の値は左連結を示し、<x_i>内の０の値は右連結を示す。
［表８］

【表8】

【0196】

ステップ１３１６で、トランザクション１３１４はアンロックスクリプトのためのデータ（<Data ３>と示される）として提供される。ステップ１３１８で、マークルルートは、マークルルート<Data ２>及びトランザクション<Data ３>から、ここに示されないOP_CALCMERKLEROOTスクリプトを用いて計算される。

【0197】

ステップ１３２０で、スクリプトは、<Data １>から抽出したHashMerkleRootが<Data ２>及び<Data ３>に対して実行されたOP_CALCMERKLEROOTスクリプトからの計算されたマークルルートと同じであることを検証するために実行される。<Data １>から抽出したHashMerkleRootが<Data ２>及び<Data ３>からの計算されたマークルルートと同じであることを検証するスクリプトの一例は、表９に示される。表９に示すスクリプトはブロックヘッダ<Data １>のブロックが<Data ３>のトランザクションを含むことを<Data ２>のマークル枝を用いて検証するOP_CHECKBLOCKTXVERIFYスクリプトの一例である。考えられるように、OP_CHECKBLOCKTXVERIFYスクリプトの他の実装が、実施されてよく、本開示の範囲内にあると考えられる。表９に示すOP_CHECKBLOCKTXVERIFYスクリプトでは、OP_CHECKBLOCKVERIFY動作は説明を容易にするために省略される。
［表９］

【表9】

【0198】

図１４は、一実施形態による、トランザクションが、スクリプトに基づくブロックチェーン相互作用におけるブロックヘッダに含まれることを検証する例示的な処理１４００をフローチャート形式で示す。処理１４００の一部又は全部は、実行可能命令及び／又は他のデータにより構成された１つ以上のコンピュータシステムの制御下で実行可能であり、１つ以上のプロセッサで共同で実行する実行可能命令として実装可能である。実行可能命令及び／又は他のデータは、非一時的コンピュータ可読記憶媒体に格納可能である（例えば、磁気、光、又はフラッシュ媒体に永続的に格納されたコンピュータプログラム）。例示的な処理１４００は、図１と関連して説明したブロックチェーンネットワーク１００のようなブロックチェーンネットワークの、図１と関連して説明したノード１０２のうちの１つのようなノードにより実行されてよい。つまり、図１と関連して記載したノード１０２のうちの１つのようなノードは、トランザクションが図１４と関連して記載したスクリプトに基づくブロックチェーン相互作用におけるブロックヘッダに含まれることを検証する例示的な処理１４００を実行してよい。このようなノードは、任意の適切なコンピューティング装置で（例えば、データセンタ内のサーバにより、クライアントコンピューティング装置により、コンピューティングリソースサービスプロバイダの分散システム内の複数のコンピューティング装置により、又は図２と関連して記載したコンピューティング装置２００のような適切な電子クライアント装置により）構成されてよい。

【0199】

例示的な処理１４００のステップ１４０２で、システムは、図１３と関連して上述したように<Data １>、<Data ２>、及び<Data ３>を受信する。例示的な処理１４００のステップ１４０２で、システムは、図１３と関連して上述したように、OP_CHECKBLOCKTXVERIFYスクリプトの実行を<Data １>、<Data ２>、及び<Data ３>に対して開始する。

【0200】

例示的な処理１４００のステップ１４０６で、システムは、図６及び７と関連して上述したように、OP_CHECKBLOCKVERIFYスクリプトを用いて、<Data １>が有効なブロックヘッダであることを検証する。

【0201】

例示的な処理１４００のステップ１４０８で、<Data １>に対するOP_CHECKBLOCKVERIFYスクリプトが合格したか否かが決定される。例示的な処理１４００のステップ１４０８で、<Data １>に対するOP_CHECKBLOCKVERIFYスクリプトが合格しなかったと決定された場合、例示的な処理１４００のステップ１４１０で<Data １>は有効なブロックヘッダではなく、例示的な処理１４００のステップ１４１２で、<Data ３>のトランザクションは、<Data １>内のブロックヘッダを有するブロック内にあると証明されない。

【0202】

例示的な処理１４００のステップ１４０８で、<Data １>に対するOP_CHECKBLOCKVERIFYスクリプトが合格したと決定された場合、例示的な処理１４００のステップ１４１４で、システムは、図１３と関連して上述したように、<Data １>からHashMerkleRootフィールドを抽出する。例示的な処理１４００のステップ１４１６で、システムは、図１３と関連して上述したように<Data ２>及び<Data ３>からマークルルートを計算する。

【0203】

例示的な処理１４００のステップ１４１８で、システムは、図１３と関連して上述したように、<Data １>から抽出したHashMerkleRootが<Data ２>及び<Data ３>から計算されたマークルルートと等しいことを検証する。

【0204】

例示的な処理１４００のステップ１４２０で、<Data １>から抽出したHashMerkleRootが<Data ２>及び<Data ３>から計算されたマークルルートと等しいか否かが決定される。例示的な処理１４００のステップ１４２０で、<Data １>から抽出したHashMerkleRootが<Data ２>及び<Data ３>から計算されたマークルルートと等しくないと決定された場合、例示的な処理１４００のステップ１４１２で、<Data ３>のトランザクションは<Data １>内のブロックヘッダを有するブロックの中にあることが証明されない。

【0205】

例示的な処理１４００のステップ１４２０で、<Data １>から抽出したHashMerkleRootが<Data ２>及び<Data ３>から計算されたマークルルートと等しいと決定された場合、例示的な処理１４００のステップ１４２２で、<Data ３>のトランザクションは<Data １>内のブロックヘッダを有するブロックの中にあることが証明される。

【0206】

図１４に示した例示的な処理１４００で実行される動作のうちの１つ以上は、並列を含む種々の順序及び組み合わせで実行されてよいことに留意する。

【0207】

図１５は、一実施形態による、本願明細書に記載の方法を用いて、スクリプトに基づくブロックチェーン相互作用に関連付けられたブロックチェーンへのアクセスに伴う問題がどのように解決され得るかを示す例示的な環境１５００を図形式で示す。例示的な環境１５００では、トランザクション１５０２（例えば、図３に関連して記載した前のトランザクション３０２のような前のトランザクション又はアンロックトランザクション３０４）内のロックスクリプト１５０４は、図６～１４と関連して記載した方法のうちの１つ以上を用いてブロックチェーン１５０４にクエリできない。これは、図４と関連して記載した例示的な問題４００と対照的である。同様に、例示的な環境１５００では、トランザクション１５０２内のロックスクリプト１５０６は、図６～１４と関連して記載された方法のうちの１つ以上を用いてブロックチェーン１５０４のブロック１５０８にクエリできない。これは、図５と関連して記載した例示的な問題５００と対照的である。一実施形態では、ブロック１５０８のトランザクション１５１０は、トランザクション１５０２と同じである（例えば、トランザクションTx_iである）。

【0208】

図１６は、一実施形態による、スクリプトに基づくブロックチェーン相互作用に関連付けられたブロックチェーンの状態を示す例示的な環境１６００を図形式で示す。ブロックチェーンは、ブロックチェーンが開始して以来の全てのブロックを含む。例示的な環境１６００では、ブロックチェーン１６０２の第１ブロック１６０４のブロックヘッダは、最も小さいnTimeで（例えば、最も最近の又は時間において最初である）ブロックチェーン１６０２の状態１６０６のレコードである。本願明細書に記載の方法を用いて、トランザクションのロックスクリプトは、ブロックチェーン１６０２をクエリでき、第１ブロック１６０４をクエリでき、最も小さいnTimeにおけるブロックチェーン１６０２の状態１６０６をクエリできる。本願明細書に記載の方法を用いて、トランザクションのロックスクリプトは、ブロックチェーン１６０２をクエリでき、ブロックチェーン１６０２のブロック１６０８（トランザクションを含むブロックであってよい）をクエリでき、したがってブロックのnTimeにおけるブロックチェーン１６０２の状態１６１０をクエリできる。本願明細書に記載の方法を用いて、トランザクションのロックスクリプトは、ブロックチェーン１６０２をクエリでき、ブロックチェーン１６０２の最新ブロック１６１２をクエリでき、したがって最新ブロックのnTimeにおけるブロックチェーン１６０２の状態１６１４をクエリできる（例えば、ブロックチェーンの現在状態をクエリできる）。このような状態クエリの使用は図１７及び１８に詳述される。

【0209】

図１７は、一実施形態による、スクリプトに基づくブロックチェーン相互作用において、ブロックチェーンの状態が確認される、例示的な環境１７００を図形式で示す。本願明細書に記載のように、ブロックヘッダは、ブロックに関するデータを含む、ブロックチェーンのブロックの一部である。ブロックヘッダの一部は、ブロック内のトランザクションを検証できない、マークル木のマークルルートである（「HashMerkleRoot」）。ブロックヘッダが、トランザクションのマークル枝及びトランザクションと一緒にロックスクリプトのインプットとして提供される（例えば、アンロックスクリプトとして提供される）場合、ブロックヘッダのHashMerkleRootが、マークル枝及びトランザクションから計算された計算されたマークルルートと同じであるという制約をエンコードすることにより、ブロックヘッダのHashMerkleRootが計算されたマークルルートと同じでないならば、ブロックヘッダ、マークル枝、及びトランザクションは有効なアンロックスクリプトではない。

【0210】

一実施形態では、ブロックチェーンの状態のチェック及び／又はブロックチェーンの状態の確認は、ブロックチェーンの他の側面のチェックを含む。これは、限定ではないが、ブロックチェーンの１つ以上のブロックのブロックヘッダのチェック、ブロックチェーンの１つ以上のブロックの間の関係のチェック、ブロックチェーンのブロック数のチェック、ブロックチェーンの単一ブロック内の１つ以上のトランザクションのチェック、又はブロックチェーンの複数のブロック内の複数のトランザクションのチェックを含む。

【0211】

ステップ１７０８で、ブロックヘッダ１７０６はアンロックスクリプトのためのデータ（<Data １>と示される）として提供される。一実施形態では、図６及び７と関連して上述したOP_CHECKBLOCKVERIFYスクリプトのようなスクリプトは、<Data １>がブロックヘッダであることを検証するために使用される。ステップ１７１２で、図１３及び１４と関連して上述したように、マークル枝１７１０はアンロックスクリプトのためのデータ（<Data ２>と示される）として提供される。ステップ１７１６で、トランザクション１７１４はアンロックスクリプトのためのデータ（<Data ３>と示される）として提供される。一実施形態で、マークルルートは、マークルルート<Data ２>及びトランザクション<Data ３>から、図１３及び１４と関連して上述したようなOP_CALCMERKLEROOTスクリプトを用いて計算される。

【0212】

ステップ１７１８で、OP_CHECKBLOCKTXVERIFYスクリプトは、<Data １>から抽出したHashMerkleRootが上述の表９に示したような<Data ２>及び<Data ３>に対して実行されたOP_CALCMERKLEROOTスクリプトからの計算されたマークルルートと同じであることを検証するために実行される。

【0213】

理解されるべきことに、ステップ１７１８は、例示的な環境１７００のような環境で実行可能であるスクリプトの種類の一例を示し、ここで、ブロックチェーンの状態は一実施形態によりスクリプトに基づくブロックチェーン相互作用の中で確認される。ステップ１７１８は、ブロックチェーンからのデータセットをオペコードを用いてトランザクションへ導入させる第１制約セットを示す。一実施形態では、OP_CHECKBLOCKVERIFYは、本願明細書に記載されるように、データセットがブロックヘッダを含むことを検証するために使用される。一実施形態では、OP_CHECKBLOCKTXVERIFY（つまり、ステップ１７１８に示される）は、データセットがトランザクションを含むこと、及びトランザクションがブロックヘッダに含まれることを検証するために使用される。考えられるように、本願明細書に記載される第１制約セットの中の制約の例は説明のための例であり、第１制約セットの他の種類の制約が本開示の範囲内として考えられてよい。第２制約セットは、以下にステップ１７２２に関して記載される。

【0214】

例示的な環境１７００では、ステップ１７０４で、スクリプトは、上述のOP_CHECKBLOCKCHAINVERIFYのような検証スクリプトを用いて、ブロックヘッダ<Data １>が、パブリックブロックチェーンを模倣するために特別に生成されたブロックではなく、パブリックブロックチェーンの部分であるブロックのブロックヘッダであることを検証するために使用される。一実施形態では、スクリプトは、上述のように、ブロックヘッダ<Data １>が、ブロックチェーン１７０２と共に又は完全な若しくは部分的ブロックヘッダチェーンと共に提供され得るパブリックブロックチェーンの部分であるブロックのブロックヘッダであることを検証するために使用される。

【0215】

例示的な環境１７００では、ステップ１７２２で、スクリプトは、トランザクションの他の側面を検証するために使用される。ステップ１７２０で、トランザクション１７１４は、ステップ１７２２におけるアンロックスクリプトのためのデータ（<Data ３>と示される）として提供される。留意すべきことに、幾つかの実施形態では、例えばステップ１７１８におけるOP_CHECKBLOCKTXVERIFYスクリプトが、ステップ１７１６におけるトランザクション<Data ３>を消費するとき、ステップ１７２０におけるトランザクション<Data ３>は、ステップ１７１６におけるトランザクション<Data ３>のコピーである。

【0216】

上述のステップ１７１８と同様に、留意すべきことに、ステップ１７２２は例示的な環境１７００のような環境で実行可能であるスクリプトの種類の一例を示し、ここで、ブロックチェーンの状態は一実施形態によりスクリプトに基づくブロックチェーン相互作用の中で確認される。ステップ１７２２は、ステップ１７１８と関連して上述したように、オペコードを用いてトランザクションに導入される、ブロックチェーンからのデータセットに関連付けられる第２制約セットを示す。一実施形態では、第２制約セットは、データセットのデータアイテムの値に関する制約を含む（つまり、データセットのデータアイテムが、例えば値より小さい、等しい、又は大きいという制約を含む）。一実施形態では、第２制約セットは、データから決定される制約を含む（例えば、ブロックヘッダに関連付けられたブロックの中のトランザクションの数が１００より多い場合に、動作「A」を行う、その他の場合に動作「B」を行う、という制約）。考えられるように、本願明細書に記載される第２制約セットの中の制約の例は説明のための例であり、第２制約セットの他の種類の制約が本開示の範囲内として考えられてよい。

【0217】

ステップ１７０４で、ブロックヘッダ<Data １>が、パブリックブロックチェーンのブロックを模倣するために特別に生成されたブロックではなく、パブリックブロックチェーンの部分であるブロックのためのブロックヘッダであることを検証するために使用されるスクリプトが、合格した場合、ステップ１７１８で、OP_CHECKBLOCKTXVERIFYスクリプトは、<Data １>から抽出したHashMerkleRootが、<Data ２>及び<Data ３>に対して実行されたOP_CALCMERKLEROOTスクリプトから計算したマークルルートと同じであることを検証し、ステップ１７２２で、トランザクションの他の側面を検証するために使用されるスクリプトが合格した場合、ステップ１７２４でロックスクリプトが成功する。一実施形態では、ステップ１７０４は、オペコードを用いてトランザクションに導入される、ブロックチェーンからのデータセットに関連付けられた第３制約セットを示す（例えば、ブロックがパブリックブロックチェーンのブロックであるという制約）。

【0218】

留意すべきことに、上述のように、ステップ１７２２で、トランザクションの他の側面を検証するために使用されるスクリプトは、オペコードを用いてトランザクションに導入される、ブロックチェーンからのデータセットに関連付けられた第２制約セットを含む。このように、第２制約セットは、一実施形態では、限定ではないが、譲受人（transferee）、譲渡人（transferor）、トランザクションの量、又はトランザクションの他の側面、を含むトランザクションの多数の側面の検証を含む。さらに、留意すべきことに、ステップ１７２２で、トランザクションの他の側面を検証するために使用されるスクリプトは、ブロックチェーンの側面、ブロックヘッダチェーンの側面、ブロックの側面、又はブロックチェーン環境の他の側面を含んでよい。例えば、ステップ１７２２で、トランザクションの他の側面を検証するために使用され、第２制約セットの制約を含むスクリプトは、ブロックのnTimeを検証するための、ブロック内のトランザクションの数を検証するための、２つのブロック間の経過時間量を決定するための、最小ブロック高を決定するための、又はブロックチェーン環境の他のこのような側面を決定するための、制約を含み得る。また留意すべきことに、スクリプトの末尾に、ステップ１７２２のトランザクションの他の側面を検証するために使用される「検証（verify）」オペコードを含まないことにより、分岐条件が導入され得る（例えば、１０００個より多くのトランザクションがブロック内にある場合、アリスは解除でき、１０００個より多くのトランザクションがブロック内にない場合、ボブが解除できる）。分岐条件の例は、図３０と関連して以下に詳述される。

【0219】

ステップ１７０４に関連付けられる１つの問題、つまり、ブロックヘッダ<Data １>が、パブリックブロックチェーンのブロックを模倣するために特別に生成されたブロックではなく、パブリックブロックチェーンの部分であるブロックのためのブロックヘッダであることを検証するために使用されるスクリプトが、幾つかの実施形態では、パブリックブロックチェーンのブロックを模倣するために特別にブロックを生成することが計算上極めて容易であり得ることである。例えば、ブロックヘッダに含むべきアンロックスクリプト内のデータを必要とする（例えば、アンロックスクリプトは単なるブロックヘッダ<Data １>以上のものを含んでよい）、表１０のロックスクリプトを検討する。
［表１０］

【表10】

【0220】

ビットコイン実装では、採掘難易度（nBits）が最小値に設定される場合、データは、パブリックブロックチェーン内のブロックのブロックヘッダであり得るが、最小採掘難易度でブロックを生成するためには膨大な量の計算能力を必要としないので、完全に無関係なブロックでもあり得る。この実施を阻止するために、ロックスクリプト生成者は、ロックスクリプトに対する制約を充分に困難にするべきである。その結果、パブリックブロックチェーンを模倣する代替ブロックチェーンを生成するために必要な計算能力のコストが、解除可能なものの価値よりも有意に大きくなる。ビットコインでは、これは、（例えば、表３に示した、図６及び７と関連して記載したスクリプトにおける）採掘難易度を増大することにより、又は（例えば、表６に示した、図１０及び１１と関連して記載したスクリプトにおける）ブロックヘッダの長いチェーンを要求することにより、達成できる。

【0221】

表１１は、ステップ１７２４におけるようなトランザクションの他の側面を検証するために（つまり、第２制約セット及び／又は第１制約セットの側面が満たされるか否かを決定するために）使用されるスクリプトの一例を示す。表１１に示したトランザクションの他の側面を検証するために使用される例示的なスクリプトでは、データ<Data １>は、トランザクション<Data ３>を含むブロックヘッダであり、トランザクションがボブの公開鍵に支払われる、という制約を受ける。留意すべきことに、「<Scriptto Check Output of Data ３ is to P２KH of Bob>」は、説明の目的でここでは省略される。
［表１１］

【表11】

【0222】

図１８は、一実施形態による、スクリプトに基づくブロックチェーン相互作用において、ブロックチェーンの状態を確認する例示的な処理１８００をフローチャート形式で示す。処理１８００の一部又は全部は、実行可能命令及び／又は他のデータにより構成された１つ以上のコンピュータシステムの制御下で実行可能であり、１つ以上のプロセッサで共同で実行する実行可能命令として実装可能である。実行可能命令及び／又は他のデータは、非一時的コンピュータ可読記憶媒体に格納可能である（例えば、磁気、光、又はフラッシュ媒体に永続的に格納されたコンピュータプログラム）。例示的な処理１８００は、図１と関連して説明したブロックチェーンネットワーク１００のようなブロックチェーンネットワークの、図１と関連して説明したノード１０２のうちの１つのようなノードにより実行されてよい。つまり、図１と関連して記載したノード１０２のうちの１つのようなノードは、図１８と関連して記載したスクリプトに基づくブロックチェーン相互作用におけるブロックチェーンの状態を確認する例示的な処理１８００を実行してよい。このようなノードは、任意の適切なコンピューティング装置で（例えば、データセンタ内のサーバにより、クライアントコンピューティング装置により、コンピューティングリソースサービスプロバイダの分散システム内の複数のコンピューティング装置により、又は図２と関連して記載したコンピューティング装置２００のような適切な電子クライアント装置により）構成されてよい。

【0223】

例示的な処理１８００のステップ１８０２で、システムは、図１７と関連して上述したように<Data １>、<Data ２>、及び<Data ３>を受信する。

【0224】

例示的な処理１８００のステップ１８０４で、図１７と関連して上述したように、OP_CHECKBLOCKCHAINVERIFYを用いて、<Data １>がパブリックブロックチェーンのブロックであることを検証する。上述のように、OP_CHECKBLOCKCHAINVERIFYは、データセットに対する制約（例えば、上述の第３制約セット）が満たされるか否かを決定するために使用可能なスクリプトの一例である。

【0225】

例示的な処理１８００のステップ１８０６で、<Data １>がパブリックブロックチェーンのブロックであるか否かが決定される。例示的な処理１８００のステップ１８０６で、<Data １>がパブリックブロックチェーンのブロックではないと決定された場合、例示的な処理１８００のステップ１８０８で、<Data ３>のトランザクションは、<Data １>のブロックヘッダを有するブロックであることが証明されず、例示的な処理１８００のステップ１８１０で、ロックスクリプトが失敗する。

【0226】

例示的な処理１８００のステップ１８０６で、<Data １>がパブリックブロックチェーンのブロックであると決定された場合、例示的な処理１８００のステップ１８１２で、システムは、表９に示した例のようなOP_CHECKBLOCKTXVERIFYスクリプトを用いて、<Data ３>のトランザクションが<Data １>のブロックヘッダを有するブロックの中にあることを検証する。上述のように、OP_CHECKBLOCKTXVERIFYは、データセットに対する制約（例えば、上述の第１制約セット）が満たされるか否かを決定するために使用可能なスクリプトの一例である。一実施形態では、OP_CHECKBLOCKTXVERIFYは、データセットがトランザクションを含むことを検証するために、及びトランザクションがブロックヘッダにより識別されるブロックに含まれることを検証するために使用される。一実施形態では、OP_CHECKBLOCKVERIFYは、データセットがブロックヘッダを含むことを検証するために使用される。

【0227】

例示的な処理１８００のステップ１８１４で、OP_CHECKBLOCKTXVERIFYが合格したか否かが決定される。例示的な処理１８００のステップ１８１４で、OP_CHECKBLOCKTXVERIFYが合格しなかった場合、例示的な処理１８００のステップ１８１６で、<Data ３>のトランザクションは<Data １>のブロックヘッダを有するブロックの中になく、例示的な処理１８００のステップ１８１０で、ロックスクリプトは失敗する。

【0228】

例示的な処理１８００のステップ１８１４で、OP_CHECKBLOCKTXVERIFYが合格した場合、例示的な処理１８００のステップ１８１８で、システムは、本願明細書に記載のようなトランザクションの１つ以上の他の側面を検証する（つまり、データセットに関連付けられた第２制約セットの制約が満たされることを検証する）。

【0229】

例示的な処理１８００のステップ１８２０で、トランザクションの１つ以上の他の側面が検証されるか否かが決定される。例示的な処理１８００のステップ１８２０で、トランザクションの１つ以上の他の側面が検証されないと決定された場合、例示的な処理１８００のステップ１８１０で、ロックスクリプトの解除が失敗する。

【0230】

例示的な処理１８００のステップ１８２０で、トランザクションの１つ以上の他の側面が検証されると決定された場合、例示的な処理１８００のステップ１８２２で、ロックスクリプトの解除が成功する。

【0231】

図１８に示した例示的な処理１８００で実行される動作のうちの１つ以上は、並列を含む種々の順序及び組み合わせで実行されてよいことに留意する。

【0232】

図１９は、一実施形態により解決される、スクリプトに基づくブロックチェーン相互作用におけるロックスクリプトに伴う例示的な問題１９００を図形式で示す。例示的な問題、つまり図１９に示した１９００では、前のトランザクション１９０２の中のロックスクリプト１９０６は、アンロックトランザクション１９０４のフィールドを直接読み出せない。

【0233】

上述のように、幾つかの実施形態では、前のトランザクション１９０２は、ブロックチェーンに含まれる最も現在（most current、最近）の確認済みトランザクションである。同様に、幾つかの実施形態では、アンロックトランザクション１９０４は、未だ確認されていない、未だブロックチェーンに含まれていない、前のトランザクション１９０２により制御されるデジタルアセットの少なくとも一部の制御を移転しようとする試みを表す、将来のトランザクションである。

【0234】

ここで留意すべきことに、幾つかの実施形態では、ロックスクリプト１９０６は、アウトプットを移転するために満たす必要のある条件を指定することにより、トランザクションを妨げるスクリプトである。特に、ロックスクリプト１９０６の実行は、ブロックチェーンシステムの検証ノードによる実行の結果として、実行したアンロックスクリプトからのデータを受け付け、該データに基づき特定の演算を実行し、アンロックスクリプトの実行がロックスクリプトを成功裏に「アンロック（unlocked、解除）」したか（つまり、ロックスクリプト内で設定された条件セットを満たしたか）否かを示す結果を返す。幾つかの実施形態では、ロックスクリプト１９０６は、トランザクションの検証が成功するために（例えば、アンロックスクリプトにより提供されたデータにより）満たされなければならない１つ以上のデータ制約を定める。例えば、ロックスクリプト１９０６は、前のトランザクション１９０２の関連するデジタルアセットをアンロックするために、アンロックスクリプト内で特定データが提供されることを要求し得る。

【0235】

図２０は、一実施形態による、スクリプトに基づくブロックチェーン相互作用におけるアンロックスクリプトによるデータアクセスを示す例示的な環境２０００を図形式で示す。図２０は、一実施形態における、本開示の、前のトランザクション２００２のアンロックスクリプト２００６と異なる、アンロックスクリプト２００８が、アンロックトランザクション２００４のフィールド（例えば、SIGHASH typeに従い決定されたアンロックトランザクションフィールドのセット）へのアクセスを有することを示す例示的な環境２０００を示す。幾つかの実施形態では、前のトランザクション２００２は、図１９の前のトランザクション１９０２と同様である。幾つかの実施形態では、アンロックトランザクション２００４は、図１９のアンロックトランザクション１９０４と同様である。幾つかの実施形態では、ロックスクリプト２００６は、図１９のロックスクリプト１９０６と同様である。

【0236】

幾つかの実施形態では、アンロックスクリプト２００８は、ロックスクリプトによりトランザクションのアウトプットに対して課される条件セットを満たすことを試みるトランザクションのインプットに対して課される実行可能スクリプトである。ロックスクリプトは「scriptSig」としても知られている。上述のように、アンロックスクリプト２００８は、ロックスクリプトへのインプットとしてSIGHASH typeに従い決定されたアンロックトランザクションフィールドのセットを提供するよう設計され、それによりロックスクリプトのアンロックトランザクションのフィールドへのアクセスを与える。連続トランザクションの内容及び構成に関する更なる詳細は、以下の図２１の説明において分かる。

【0237】

図２１は、一実施形態による、署名が、スクリプトに基づくブロックチェーン相互作用におけるトランザクションフィールドの連続セットから生成される、例示的な環境２１００を図形式で示す。図２１に示すように、連続トランザクション２１１０（つまり、特定フォーマットのバイトのシリーズで表されるトランザクション）は、トランザクションのフィールド値のセットを含む。署名者は、２１１２で、SIGHASH type及び数値kを選択する。数値kは、秘密鍵をマスクし／保護するために、標準的にランダム又は疑似乱数であり、したがって本開示では時折「マスク数値（mask number）」と呼ばれる。トランザクション２１１４の変更されたコピーは、（例えば、例示的な環境２１００においては、SIGHASH_NONE＋ANYONECANPAYである）指定されたSIGHASH typeに従い選択された連続トランザクション２１１０のフィールドのセットの一例である。署名者は、トランザクション２１１４の変更されたコピーをハッシュし（例えば、OP_HASH２５６を実行し）、結果としてメッセージm２１１６を生じる。署名者は、次に、SIGHASH type、メッセージm、署名者の秘密鍵（例えば、a）、及び数値kを用いて、図３と関連して上述した方法のように、署名を生成する。

【0238】

表１２は、標準的なアンロック及びアンロックスクリプトの一例を示す。これにより、アンロックスクリプト内で指定されたエンティティAの想定される署名が、OP_CHECKSIGオペコードを用いてエンティティAの公開鍵に対してチェックされる。
［表１２］

【表12】

【0239】

したがって、図２１の署名生成の理解により、表１３は、例示的環境２１００に示された手順の部分がアンロックスクリプト内へと移動された場合の、アンロック及びロックスクリプトの一例を示す。
［表１３］

【表13】

【0240】

アンロックスクリプトは、表１４に示されるように、アンロックスクリプト内のメッセージmを計算するステップを含むよう更に変更できる。
［表１４］

【表14】

【0241】

しかしながら、SIGHASH type及びSIGHASH typeに従い決定したアンロックトランザクションフィールドのセットを除き、手順の他の動作は、表１５に示されるようにロックスクリプトへと移動できる。
［表１５］

【表15】

【0242】

したがって、ロックスクリプト内の「OP_HASH２５６ <a> <k> OP_GENSIG」の動作を移動することにより、アンロックスクリプトは、有効であるために、SIGHASH type及びSIGHASH typeに従い決定されるアンロックトランザクションフィールドのセットを含むようにされる。

【0243】

このように、連続した前のトランザクションは、ロックスクリプト内に導入させられる。表１６は、ロックスクリプト及びアンロックスクリプトが、例示的環境２１００の各ステップの手順をどのように実行しトランザクションを検証するかを示す。
［表１６］

【表16】

【0244】

しかしながら、SIGHASH type及びSIGHASH typeに従い決定されるアンロックトランザクションフィールドのセットを提供する任意のエンティティは、トランザクションアウトプットを受信できることに留意する。これは、本願明細書に記載の方法の有用な特徴になり得る。例えば、スマートコントラクトの一実装は、コントラクトがブロックチェーントランザクションとして実装されることを可能にし得る。これは、コントラクトの生成者及び／又は任意の他のパーティをコントラクトから解放し、これらのパーティに互いを信頼することを要求せずに、且つこれらのパーティにコントラクトを管理すること若しくは監視することを要求せずに、コントラクトが満たされることを保証する。一実装では、コントラクトとの幾つかの相互作用が要求される。一実装では、コントラクトは、コントラクトとの相互作用を伴わずに自動的に実行される。

【0245】

上述のように、SIGHASH type及びSIGHASH typeに従い決定されるアンロックトランザクションフィールドのセットを提供する任意のエンティティは、トランザクションアウトプットを受信できるので、スマートコントラクトは、自動的に（又は部分的に自動的に）実行され得る。一実施形態では、この特性は、アンロックトランザクションに対して追加制約を課すことにより制限できる。その結果、SIGHASH type及びSIGHASH typeに従い決定されるアンロックトランザクションフィールドのセットを提供する幾つかのエンティティだけが、トランザクションアウトプットを受信できる。さらに、SIGHASH type及びSIGHASH typeに従い決定されるアンロックトランザクションフィールドのセットを提供するエンティティは、特定方法でトランザクションアウトプットを取得できるだけであるように、スマートコントラクトが符号化されてよい。

【0246】

一実施形態では、スマートコントラクトは、他のコンピュータシステムにトランザクションを検証させるためにコンピュータシステムにより検出可能な信号として機能する値を含む。つまり、デジタルアセットの少なくとも一部、スマートコントラクトに関連付けられたトランザクションの検証を実行すると取得可能な条件（contingent）を提供することにより、検証エンティティはトランザクションを検証するよう誘導される。例えば、１．０のデジタルアセットに関連付けられたスマートコントラクトが生成され、０．９のデジタルアセットが指名された受信者へ渡り、残りの０．１のデジタルアセットが検証エンティティにより請求可能にする。このように、スマートコントラクトが実行される。考えられるように、トランザクションアウトプットを取得するために及び／又はスマートコントラクトを実行するためにエンティティに影響する他の方法が、本開示の範囲内にあると考えられる。

【0247】

本願明細書で使用されるように、スマートコントラクトは、自動実行特性及び自己施行特性の両方を有する。スマートコントラクトの自動実行特性は、２つの要素の結合である。スマートコントラクトの自動実行特性の第１要素は、任意のエンティティがロックスクリプトを有効に解除できることである。任意のエンティティがロックスクリプトを有効に解除できるとき、任意のエンティティは、UTXO及び／又はロックスクリプトを参照する有効なアンロックトランザクションを生成できる。これは、エンティティが何らかの秘密（例えば、秘密鍵、又は特定のハッシュを生成する値）の知識を有することを証明するようエンティティに要求する制約がないからである。しかしながら、留意すべきことに、スマートコントラクトの自動実行特性のこの第１要素は、本願明細書に記載のように制限される。スマートコントラクトの自動実行特性の第２要素は、（例えば、本願明細書に記載のようにビットコイン報酬により）ロックスクリプトを解除するよう他のパーティを動機づけし得るという点で、スマートコントラクトが自動であることである。スマートコントラクトの自己施行特性も、２つの要素の結合である。スマートコントラクトの自己施行特性の第１要素は、アンロックトランザクションフィールドの連続セットに対して制約が課されてよく、次にこれらの制約がアンロックトランザクション内に反映されることである。スマートコントラクトの自己施行特性の第２要素は、ロックスクリプト内の制約がブロックチェーンネットワークにより施行されることである。

【0248】

図２２は、一実施形態による、署名が、スクリプトに基づくブロックチェーン相互作用におけるアンロックトランザクションの連続セットの導入を生じる、例示的な処理２２００をフローチャート形式で示す。例示的な処理２２００の一部又は全部は、実行可能命令及び／又は他のデータにより構成された１つ以上のコンピュータシステムの制御下で実行可能であり、１つ以上のプロセッサで共同で実行する実行可能命令として実装可能である。実行可能命令及び／又は他のデータは、非一時的コンピュータ可読記憶媒体に格納可能である（例えば、磁気、光、又はフラッシュ媒体に永続的に格納されたコンピュータプログラム）。例示的な処理２２００は、図１と関連して説明したブロックチェーンネットワーク１００のようなブロックチェーンネットワークの、図１と関連して説明したノード１０２のうちの１つのようなノードにより実行されてよい。つまり、図１と関連して記載したノード１０２のうちの１つのようなノードは、アンロックトランザクションフィールドの連続セットを、図２２と関連して記載したスクリプトに基づくブロックチェーン相互作用に導入させる例示的な処理２２００を実行してよい。このようなノードは、任意の適切なコンピューティング装置で（例えば、データセンタ内のサーバにより、クライアントコンピューティング装置により、コンピューティングリソースサービスプロバイダの分散システム内の複数のコンピューティング装置により、又は図２と関連して記載したコンピューティング装置２００のような適切な電子クライアント装置により）構成されてよい。

【0249】

例示的な処理２２００は、一連の動作を含む。ここで、例示的な処理２２００を実行するシステムは、図２１に記載した方法と関連して未検証トランザクションのアンロックスクリプト及びロックスクリプトを実行し、結果としてSIGHASH typeとトランザクションフィールド値のセットとを取得し、署名を生成し、署名を検証する。

【0250】

例示的な処理２２００のステップ２２０２で、システムは、未検証トランザクションを、デジタルアセットの制御の移転を求めているエンティティから取得する。未検証トランザクションは、ロックスクリプト及びアンロックスクリプトを含む。アンロックスクリプトは、ロックスクリプトを実行する前に、システムにより実行される。アンロックスクリプトは、上述の表１５及び１６に示したアンロックスクリプトと同様であってよく、SIGHASH type及び未検証トランザクションのフィールドの連続セットを示す。例示的な処理２２００のステップ２２０４で、例示的な処理２２００を実行するシステムは、示されたSIGHASH typeを取得し、例示的な処理２２００のステップ２２０６で、未検証トランザクションのトランザクションフィールド値の連続セットを取得する。一実施形態では、アンロックスクリプトの実行が成功裏に完了すると、システムは、アンロックスクリプトの実行が完了したときの主スタックの状態（幾つかの実装では、代替スタックの状態）を用いてロックスクリプトの実行を開始する。ロックスクリプトは、上述の表１５及び１６に示したロックスクリプトと同様であってよい。

【0251】

例示的な処理２２００のステップ２２０８で、ロックスクリプトに従い、システムは、少なくともSIGHASH type及びアンロックスクリプトの実行結果として主スタックに置かれたトランザクションフィールド値のセット、並びに公開秘密鍵ペアに関連付けられた秘密鍵を用いて、署名を生成する。例示的な処理２２００のステップ２２１０で、ロックスクリプトに従い、システムは、鍵ペアの公開鍵に対する署名の検証に成功する。このように、トランザクションフィールドのセットは、アンロックスクリプトによりロックスクリプト内に導入させられる。

【0252】

図２２に示した例示的な処理２２００で実行される動作のうちの１つ以上は、並列を含む種々の順序及び組み合わせで実行されてよいことに留意する。

【0253】

図２３は、一実施形態により解決される、スクリプトに基づくブロックチェーン相互作用におけるロックスクリプトに伴う例示的な問題２３００を図形式で示す。図２３に示した例示的な問題２３００では、ロックスクリプト２３０６は、前のトランザクションのフィールドに埋め込まれたトランザクションのインプットを読み出すことができず、結果として該フィールドを直接読み出せない。

【0254】

幾つかの実施形態では、トランザクション２３０４は、前のトランザクションにより制御されるデジタルアセットの少なくとも一部の制御を移転しようとする試みを表す、本願明細書に記載のアンロックトランザクションと同様である。上述のように、幾つかの実施形態では、ロックスクリプト２３０６は、本願明細書に記載のロックスクリプトと同様に、アウトプットを移転するために満たす必要のある条件を指定することにより、トランザクションを妨げるスクリプトである。

【0255】

図２４は、一実施形態による、スクリプトに基づくブロックチェーン相互作用において、前の連続トランザクションの導入が引き起こされる、例示的な環境２４００を図形式で示す。図２４に示した例示的な環境２４００は、前のトランザクション２４０２Ａ～０２Ｂからのアウトプットを利用するアンロックスクリプト２４０８を有するアンロックトランザクション２４０４を示す。図から分かるように、アンロックスクリプトは、連続する前のトランザクションを読み出させる。幾つかの例では、連続する前のトランザクションは、前のトランザクションのフィールド値のセットの未変更バージョンを表す。

【0256】

図２４に示す実施形態は、トランザクションIDが連続トランザクションのdouble SHA２５６であること、及びトランザクションIDがトランザクションとの１対１マッピングを有すること、に気付くことにより理解できる。したがって、トランザクションは、表１７に示す制約を適用することにより、アンロックスクリプトに導入可能である。
［表１７］

【表17】

【0257】

本開示の実施形態は、任意の連続トランザクションの導入によるだけでなく、アンロックトランザクション２４０４のインプットにおいて参照される１つ以上の連続する前のトランザクション（例えば、前のトランザクション２４０４Ａ～０２Ｂ）の導入により、この導入により更に向上する。図２１を参照して上述したように、SIGHASH typeに従い決定されたアンロックトランザクションフィールドのセットは、アンロックスクリプト２４０６を介してロックスクリプトへと導入可能である。図２５は、どのフィールドがSIGHASH typeに依存して連続トランザクションに含まれるかを示す。

【0258】

図２５は、一実施形態による、フィールドセットが、スクリプトに基づくブロックチェーン相互作用における署名ハッシュ種類に依存して利用可能にされる、例示的な環境２５００を図形式で示す。しかしながら、図２５は、説明を意図しており、種々の実施形態において、図２５に示したものより多くのSIGHASH typeが存在することに留意する。図２５に示すように、異なるSIGHASH typeにより、前のトランザクションIDの異なるセットが、SIGHASH typeに従い決定されたアンロックトランザクションフィールドのセットに含まれる（「ハッシュ（hash）」フィールドはトランザクションIDをビッグエンディアン形式で表すことに留意する）。幾つかの実施形態では、ロックスクリプトを埋め込む前のトランザクションのトランザクションIDは、どのSIGHASH typeが指定されるかに拘わらず、常に利用可能である。

【0259】

したがって、特定フィールドが、以下の方法でSIGHASH typeを制約することにより、決定されたアンロックトランザクションフィールドのセットの中に存在するようにできる。先ず、SIGHASH typeを複製する。次に、SIGHASH typeをスタックにプッシュする（例えばSIGHASH_ALL）。最後に、OP_EQUALVERIFYを呼び出す。図２５で分かるように、SIGHASH_ALL（アンロックトランザクション２５０４Ａと共に示される）は、前のトランザクション「y」及び「z」の、上述のようにトランザクションIDを表すハッシュを含む。対照的に、SIGHASH_ALL＋ANYONECANPAY（アンロックトランザクション２５０４Ｂと共に示される）は、直前のトランザクション「y」のハッシュのみを含む。幾つかの実施形態では、アンロックトランザクション２５０４Ａ～０４Ｂは、前のトランザクション（例えば、トランザクションy及び／又はx）により制御されるデジタルアセットの少なくとも一部の制御を移転しようとする試みを表す、図１９のアンロックトランザクション１９０４と同様である。トランザクションIDの抽出は、図２６に示される、所望のフィールドに到達するまで、サブストリングオペコードを用いて連続トランザクションをパースすることにより達成できる。

【0260】

図２６は、一実施形態による、トランザクション識別子が、スクリプトに基づくブロックチェーン相互作用における連続トランザクションから抽出される、例示的な環境２６００を図形式で示す。図２６に示される例示的な環境２６００では、ビッグエンディアン形式のトランザクションIDを含むハッシュ２６２０は、スクリプト内のサブストリングオペコードを用いて抽出できる連続トランザクション２６１０のサブストリングである。幾つかの実施形態では、幾つかのフィールド（例えば、#vin、scriptSigLen、scriptSig、scriptPubKeyLen、及びscriptPubKey）が可変バイト長であるので、連続トランザクション１０２０は、トランザクションIDが抽出可能になる前に、先ず、ハッシュ２６２０の位置を特定するためにパースされる。しかしながら、フィールドが固定長を有する実装では、パースは必要なくてよいと考えられる。

【0261】

したがって、幾つかの実施形態では、図２２を参照して記載した方法でアンロックトランザクションで参照される特定の連続した前のトランザクションの導入を強制するロックスクリプトを構築することにより、前のトランザクションIDがアクセス可能にされ得る。例えば、先ず、SIGHASH type制約が決定され、トランザクションIDが抽出され、そして連続する前のトランザクションが複製され及び（SIGHASH typeに従い）アンロックトランザクションの連続フィールドセットから抽出されたトランザクションIDに対してチェックされる。この処理は、複数の異なる連続する前のトランザクションの導入を強制するために実行され得ることに留意する。一例として、表１８は、トランザクションXのインプットに対応する前のトランザクションの導入を生じるスクリプトを表す。表１８に示すスクリプトは、OP_PREVTXINJECTIONスクリプトの一例であり、アンロックトランザクションのインプットXに対応する前のトランザクションの導入を生じる。
［表１８］

【表18】

【0262】

しかしながら、SIGHASH type及びSIGHASH typeに従い決定されるアンロックトランザクションフィールドのセット、及び連続する前のトランザクションを提供する任意のエンティティは、本願明細書に記載のようにトランザクションアウトプットを取得できることに留意する。

【0263】

別の例として、表１９は、署名されているインプットに対応する前のトランザクションの導入を生じるスクリプトを表す。表１９に示すスクリプトは、OP_SELFTXINJECTIONスクリプトの一例であり、署名されているインプットに対応する前のトランザクションの導入を生じる。
［表１９］

【表19】

【0264】

SIGHASH type及びSIGHASH typeに従い決定されるアンロックトランザクションフィールドのセット、及び連続する前のトランザクションを提供する任意のエンティティは、本願明細書に記載のようにトランザクションアウトプットを受信できることに留意する。

【0265】

図２７は、一実施形態による、スクリプトに基づくブロックチェーン相互作用における前の連続トランザクションの導入を生じる、例示的な処理２７００をフローチャート形式で示す。処理２７００の一部又は全部は、実行可能命令及び／又は他のデータにより構成された１つ以上のコンピュータシステムの制御下で実行可能であり、１つ以上のプロセッサで共同で実行する実行可能命令として実装可能である。実行可能命令及び／又は他のデータは、非一時的コンピュータ可読記憶媒体に格納可能である（例えば、磁気、光、又はフラッシュ媒体に永続的に格納されたコンピュータプログラム）。例示的な処理２７００は、図１と関連して説明したブロックチェーンネットワーク１００のようなブロックチェーンネットワークの、図１と関連して説明したノード１０２のうちの１つのようなノードにより実行されてよい。つまり、図１と関連して記載したノード１０２のうちの１つのようなノードは、前の連続トランザクションを、図２７と関連して記載したスクリプトに基づくブロックチェーン相互作用に導入させる例示的な処理２７００を実行してよい。このようなノードは、任意の適切なコンピューティング装置で（例えば、データセンタ内のサーバにより、クライアントコンピューティング装置により、コンピューティングリソースサービスプロバイダの分散システム内の複数のコンピューティング装置により、又は図２と関連して記載したコンピューティング装置２００のような適切な電子クライアント装置により）構成されてよい。

【0266】

例示的な処理２７００は、一連の動作を含む。ここで、例示的な処理２７００を実行するシステムは、未検証トランザクションのアンロックスクリプト及びロックスクリプトを共に実行し、結果として、未検証トランザクションから抽出したトランザクションIDに対応する連続した前のトランザクションを取得する。

【0267】

例示的な処理２７００のステップ２７０２で、システムは、未検証トランザクションを、デジタルアセットの制御の移転を求めているエンティティから取得する。未検証トランザクションは、ロックスクリプト及びアンロックスクリプトを含む。ロックスクリプト及びアンロックスクリプトは、表１８及び１９に示したロックスクリプト及びアンロックスクリプトと同様であってよい。つまり、ロックスクリプトは、例えばアンロックスクリプトにより主スタック及び代替スタックに格納された値を入力として取り入れる命令セットを含む。命令セットの実行は、真と評価された場合、未検証トランザクションの検証に成功する。したがって、アンロックスクリプトは、ロックスクリプトの前に実行され、ロックスクリプトにより使用されるために、主スタック及び代替スタック内に値を設定する。図２７の実施形態における未検証トランザクションのアンロックスクリプトは、連続する前のトランザクション、SIGHASH type、及びアンロックトランザクションフィールドの連続セットを示す。

【0268】

後にロックスクリプトの続くアンロックスクリプトの実行の結果として、例示的な処理２７００のステップ２７０４で、システムは、連続する前のトランザクション、SIGHASH type、及びアンロックスクリプト内で指定されたアンロックトランザクションフィールドの連続セットを取得する。例示的な処理２７００のステップ２７０６で、システムは、SIGHASHに基づき、未検証トランザクションのフィールド値の連続セットの署名を生成する。SIGHASH typeはどのフィールドが署名生成で使用されるかに影響を与え、所望のSIGHASHは求められた特定の前のトランザクションに依存してよいことに留意する。例えば、表１８は、必ずしも同じロックスクリプトを含む前のトランザクションである必要のない前のトランザクションを抽出するロックスクリプト及びアンロックスクリプトを示し、SIGHASH_ALLのSIGHASH typeを利用する。図２５に示すように、SIGHASH_ALLタイプは、アンロックトランザクションの他の前のトランザクションのインプットの読み出しを可能にする。対照的に、表１９は、同じロックスクリプトを有する前のトランザクションを抽出するロックスクリプト及びアンロックスクリプトを示し、SIGHASH_ALL｜ANYONECANPAYのSIGHASH typeを利用する。図２５に示すように、SIGHASH_ALL｜ANYONECANPAYのSIGHASH typeは、署名されているインプットを有する前のトランザクション以外の、他の前のトランザクションのインプットを除去する。

【0269】

例示的な処理２７００のステップ２７０８で、システムは前に生成された署名を検証する。例示的な処理２７００のステップ２７１０で、システムは、取得した連続した前のトランザクションのdouble SHA２５６を実行することにより、アンロックトランザクションのトランザクションIDと一致すべき値（つまり、フィールド値の連続セット）を生成する。サブストリングオペコードを用いて、例示的な処理２７００のステップ２７１２で、システムは、フィールド値の連続セットのトランザクションIDを抽出し、例示的な処理２７００のステップ２７１４で、システムは、連続する前のトランザクションのdouble SHA２５６により生成されたトランザクションIDがフィールド値の連続セットのトランザクションIDと一致するか否かを決定する。種々の実施形態で、一致は必ずしも同等であることを要求しないことに留意する。例えば、２つの値は、それらが等しくないが数学的に等価である場合に、一致してよい。別の例として、２つの値は、それらが共通オブジェクト（例えば、値）に対応する、又は何らかの所定の方法で補完的である、及び／又はそれらが１つ以上の一致基準を満たす場合に、一致してよい。通常、一致するか否かを決定する任意の方法が使用されてよい。

【0270】

図２７に示した例示的な処理２７００で実行される動作のうちの１つ以上は、並列を含む種々の順序及び組み合わせで実行されてよいことに留意する。

【0271】

図２８は、一実施形態による、スクリプトに基づくブロックチェーン相互作用のために、ブロックチェーンの状態が使用される、例示的な環境２８００を図形式で示す。本願明細書に記載のように、ブロックヘッダは、ブロックに関するデータを含む、ブロックチェーンのブロックの一部である。

【0272】

本願明細書に記載のように、ステップ２８０４で、ブロックヘッダ２８０２はアンロックスクリプトのためのデータ（<Data １>と示される）として提供される。一実施形態では、図６及び７と関連して上述したOP_CHECKBLOCKVERIFYスクリプトのようなスクリプトは、<Data １>がブロックヘッダであることを検証するために使用される。ステップ２８０８で、図１３及び１４と関連して上述したように、マークル枝２８０６はアンロックスクリプトのためのデータ（<Data ２>と示される）として提供される。ステップ２８１２で、トランザクション２８１０はアンロックスクリプトのためのデータ（<Data ３>と示される）として提供される。一実施形態で、マークルルートは、マークルルート<Data ２>及びトランザクション<Data ３>から、図１３及び１４と関連して上述したようなOP_CALCMERKLEROOTスクリプトを用いて計算される。

【0273】

ステップ２８１４で、OP_CHECKBLOCKTXVERIFYスクリプトは、<Data １>から抽出したHashMerkleRootが図１３、１４、及び１７と関連して記載したように上述の表９に示したような<Data ２>及び<Data ３>に対して実行されたOP_CALCMERKLEROOTスクリプトからの計算されたマークルルートと同じであることを検証するために実行される。

【0274】

ステップ２８１６で、OP_SELFTXINJECTIONスクリプトは、<Data ３>のトランザクションのアンロックスクリプトが、図２６、２７、及び２８と関連した記載したように、表１８及び１９に示されるようなロックスクリプトを含む連続トランザクションを含むことを検証するために実行される。

【0275】

ステップ２８１８で、ステップ２８１４のOP_CHECKBLOCKTXVERIFYスクリプト及びステップ２８１６のOP_SELFTXINJECTIONが成功した場合、上述のように、<Data １>のブロックヘッダを有するブロックがトランザクション<Data ３>を含むこと、<Data ３>のアンロックスクリプトがロックスクリプトの連続トランザクションを含むこと、及びロックスクリプトがブロックチェーン状態にアクセスできること、が分かる。このようなロックスクリプトは、限定ではないが、時間（つまり、１つ以上のブロックヘッダのnTimeフィールドから）、疑似乱数（つまり、nNonce又はHashMerkleRootから、両者は疑似乱数の良好な発生源である）、又は他の情報、を含む情報へのアクセスを有してよく、これらの情報の一部又は全部はロックスクリプト内で使用されてよい。このような追加情報の例は、図３０に示される例の中で説明される。

【0276】

一実施形態では、スクリプトは、上述のOP_CHECKBLOCKCHAINVERIFYのような検証スクリプトを用いて、ブロックヘッダ<Data １>が、パブリックブロックチェーンを模倣するために特別に生成されたブロックではなく、パブリックブロックチェーンの部分であるブロックのブロックヘッダであることを検証するために使用される。一実施形態では、スクリプトは、上述のように、ブロックヘッダ<Data １>が、ブロックチェーンと共に又は完全な若しくは部分的ブロックヘッダチェーンと共に提供され得るパブリックブロックチェーンの部分であるブロックのブロックヘッダであることを検証するために使用される。

【0277】

一実施形態では、スクリプトは、図１７と関連して上述したように、トランザクションの他の側面及び／又はブロックチェーン状態を検証するためにも使用されてよい。上述のように、トランザクションの他の側面を検証するために使用されるスクリプトは、限定ではないが、譲受人、譲渡人、トランザクションの量、又はトランザクションの他の側面、を含むトランザクションの多数の側面の検証を含んでよい。さらに、留意すべきことに、トランザクションの他の側面を検証するために使用されるスクリプトは、ブロックチェーンの側面、ブロックチェーン状態の側面、ブロックヘッダチェーンの側面、ブロックの側面、又はブロックチェーン環境の他の側面を含んでよい。例えば、トランザクションの他の側面を検証するために使用されるスクリプトは、ブロックのnTime、ブロック内のトランザクションの数、２つのブロック間の経過時間の量、最小ブロック高、又はブロックチェーン環境の他の側面を検証してよい。また留意すべきことに、スクリプトの末尾に、トランザクションの他の側面を検証するために使用される「検証（verify）」オペコードを含まないことにより、分岐条件が導入され得る（例えば、１０００個より多くのトランザクションがブロック内にある場合、アリスは解除でき、１０００個より多くのトランザクションがブロック内にない場合、ボブが解除できる）。分岐条件の例は、図３０と関連して以下に詳述される。

【0278】

例示的な環境２８００内に示されないが、一実施形態では、図１７と関連して記載された、表１１に示すスクリプトのようなトランザクションの他の側面を検証するための追加スクリプトは、図２８に記載の例示的な環境２８００の部分として実行されてよい。

【0279】

図２９は、一実施形態による、スクリプトに基づくブロックチェーン相互作用において、ブロックチェーンの状態を使用する例示的な処理２９００をフローチャート形式で示す。処理２９００の一部又は全部は、実行可能命令及び／又は他のデータにより構成された１つ以上のコンピュータシステムの制御下で実行可能であり、１つ以上のプロセッサで共同で実行する実行可能命令として実装可能である。実行可能命令及び／又は他のデータは、非一時的コンピュータ可読記憶媒体に格納可能である（例えば、磁気、光、又はフラッシュ媒体に永続的に格納されたコンピュータプログラム）。例示的な処理２９００は、図１と関連して説明したブロックチェーンネットワーク１００のようなブロックチェーンネットワークの、図１と関連して説明したノード１０２のうちの１つのようなノードにより実行されてよい。つまり、図１と関連して記載したノード１０２のうちの１つのようなノードは、図２９と関連して記載したスクリプトに基づくブロックチェーン相互作用におけるブロックチェーンの状態を使用する例示的な処理２９００を実行してよい。このようなノードは、任意の適切なコンピューティング装置で（例えば、データセンタ内のサーバにより、クライアントコンピューティング装置により、コンピューティングリソースサービスプロバイダの分散システム内の複数のコンピューティング装置により、又は図２と関連して記載したコンピューティング装置２００のような適切な電子クライアント装置により）構成されてよい。

【0280】

例示的な処理２９００のステップ２９０２で、システムは、図１７と関連して上述したように<Data １>、<Data ２>、及び<Data ３>を受信する。

【0281】

例示的な処理２９００のステップ２９０４で、図１７と関連して上述したように、OP_CHECKBLOCKCHAINVERIFYを用いて、<Data １>がパブリックブロックチェーンのブロックであることを検証する。

【0282】

例示的な処理２９００のステップ２９０６で、<Data １>がパブリックブロックチェーンのブロックであるか否かが決定される。例示的な処理２９００のステップ２９０６で、<Data １>がパブリックブロックチェーンのブロックではないと決定された場合、例示的な処理２９００のステップ２９０８で、<Data ３>のトランザクションは、<Data １>のブロックヘッダを有するブロックであることが証明されず、例示的な処理２９００のステップ２９１０で、ロックスクリプトはブロックチェーン状態にアクセスできない。

【0283】

例示的な処理２９００のステップ２９０６で、<Data １>がパブリックブロックチェーンのブロックであると決定された場合、例示的な処理２９００のステップ２９１２で、システムは、表９に示した例のようなOP_CHECKBLOCKTXVERIFYスクリプトを用いて、<Data ３>のトランザクションが<Data １>のブロックヘッダを有するブロックの中にあることを検証する。

【0284】

例示的な処理２９００のステップ２９１４で、OP_CHECKBLOCKTXVERIFYが合格したか否かが決定される。例示的な処理２９００のステップ２９１４で、OP_CHECKBLOCKTXVERIFYが合格しなかった場合、例示的な処理２９００のステップ２９１６で、<Data ３>のトランザクションは<Data １>のブロックヘッダを有するブロックの中になく、例示的な処理２９００のステップ２９１０で、ロックスクリプトはブロックチェーン状態にアクセスできない。

【0285】

例示的な処理２９００のステップ２９１４で、OP_CHECKBLOCKTXVERIFYが合格したと決定された場合、例示的な処理２９００のステップ２９１８で、システムは、表１９に示したスクリプトのようなOP_SELFTXINJECTIONスクリプトを用いて、<Data ３>のトランザクションがロックスクリプトの連続トランザクションを含むことを検証する。

【0286】

例示的な処理２９００のステップ２９２０で、<Data ３>内のトランザクションのアンロックスクリプトが、ロックスクリプトの連続トランザクションを含むか否かが決定される。例示的な処理２９００のステップ２９２０で、<Data ３>内のトランザクションのアンロックスクリプトが、ロックスクリプトの連続トランザクションを含まないと決定された場合、例示的な処理２９００のステップ２９１０で、ロックスクリプトはブロックチェーン状態にアクセスできない。

【0287】

例示的な処理２９００のステップ２９２０で、<Data ３>内のトランザクションのアンロックスクリプトが、ロックスクリプトの連続トランザクションを含むと決定された場合、例示的な処理２９００のステップ２９２２で、ロックスクリプトはブロックチェーン状態にアクセスできる。

【0288】

図２９に示した例示的な処理２９００で実行される動作のうちの１つ以上は、並列を含む種々の順序及び組み合わせで実行されてよいことに留意する。

【0289】

図３０は、一実施形態による、スクリプトに基づくブロックチェーン相互作用において、ブロックチェーンの状態を使用する例示的な実装３０００を図形式で示す。例示的な実装３０００は、本願明細書に記載の方法の幾つかの態様を説明する。例示的な実装３０００では、彼らのベット（bet、掛け金）を含むトランザクションのブロックと直前のブロックとの間の時間差に基づき、彼らのベットを含むトランザクションのブロックがパブリックブロックチェーンに追加されるのに、どれ位の時間を要するかについて、彼らはベットを生成したいと決定する。それぞれが単一のビットコインを提出し、時間差が１０分より少ない場合には、２つのビットコインがアリスに渡る。逆に言えば、時間差が１０分より少なくない場合、２つのビットコインはボブに渡る。

【0290】

アリスは、ベットトランザクション３００２の彼女の半分をビットコイン３００４により出資する。ボブは、ベットトランザクション３００２の彼の半分をビットコイン３００６により出資する。ベットトランザクション３００２は、時間差（t_２－t_１）が１０分より少ない場合にはアリスが２つのビットコイン３００８を得ることを記述する。逆に言えば、時間差（t_２－t_１）が１０分より少なくない場合、ボブが２つのビットコインを得る。

【0291】

本願明細書に記載の方法を用いて、ベットトランザクション３００２が、ブロックヘッダ３０１４を有するブロックB_２の中にあるか否かが決定できる。同様に、本願明細書に記載の方法を用いて、ブロックヘッダ３０１２を有するブロックB_１が直前ブロックであるかどうかが決定できる。最後に、ブロックヘッダ３０１４のnTimeが、ブロックヘッダ３０１２のnTimeの後の１０分より少ないかどうかが決定できる。したがって、２つのビットコイン３００８はアリス又はボブに移転され得る。

【0292】

表２０は、このベットトランザクション３００２の例示的なロックスクリプトを示す。表２０に示されるスクリプトで使用されるOP_EXTRACTTIMEスクリプトは、本願明細書に示されないが、考えられるように、表３に示したnBitsを抽出するためのスクリプトと同様のブロックヘッダから時間エントリを抽出するためのスクリプトである。
［表２０］

【表20】

【0293】

したがって本明細書と添付図面は限定的ではなく例示的であると解釈すべきである。しかしながら、請求の範囲に記載された本発明の広範な精神及び範囲から逸脱することなく種々の変更を行うことができることが明らかである。

【0294】

他の変形は本開示の精神の範囲内にある。したがって、開示の技術は、種々の変形及び代替構成の影響を受けるが、その特定の図示の実施形態が図面に示され、以上に詳細に記載された。しかしながら、理解されるべき点は、本発明が開示された１又は複数の特定の形式に限定されないこと、むしろ、添付の請求の範囲に記載のように、全ての変形、代案構成及び均等物が本発明の精神及び範囲に包含されることが意図される。

【0295】

開示の実施形態を説明する文脈における用語「a」、「an」、及び「the」、並びに同様の指示対象は（特に、以下の請求項の文脈において）、特に断りの無い限り又は文脈により明確に矛盾しないかぎり、単数及び複数の両方をカバーすると考えられるべきである。用語「含む」、「有する」、「含む」、「伴う」、「備える」（comprising、having、including、containing）は、特に断りのない限り広義の語として考えられるべきである（つまり、「を含む、しかし限定されない」を意味する）。用語「接続される」は、変更されず物理的接続を表すとき、何かが仲介する場合でも、部分的又は全体的に含まれる、取り付けられる又は一緒に結合される、として考えられるべきである。本願明細書において値の範囲の詳述は、本願明細書に特に断りの無い限り、単に、範囲に包含される各々の別個の値を個別に参照することの簡単明瞭な言い方として機能することを意図し、各々の個別の値は、それが本願明細書に個々に詳述されたかのように、本願明細書に組み込まれる。用語「セット」（例えば、「アイテムのセット」）又は「サブセット」の使用は、特に断りの無い限り又は文脈に矛盾しない限り、１つ以上の構成要素を含む空ではない集合として考えられるべきである。さらに、特に注記されない又は文脈に矛盾しない限り、対応するセットの用語「サブセット」は、必ずしも対応するセットの適正なサブセットを示さないが、サブセット及び対応するサブセットは等しくてよい。

【0296】

「A、B、及びCのうちの少なくとも１つ」又は「少なくとも１つのA、B、及びC」の形式の句のような論理的言語は、特に断りの無い限り又は特に明確に文脈に矛盾しない限り、アイテム、後、等がA又はB又はCのいずれか、又はA及びB及びCのセットの任意の空でないサブセットであってよいことを表すために使用されることが理解される。例えば、３つの構成要素を有するセットの説明のための例では、論理的言語「A、B、及びCのうちの少なくとも１つ」又は「少なくとも１つのA、B、及びC」は、以下のセット：｛A｝、｛B｝、｛C｝、｛A,B｝、｛A,C｝、｛B,C｝、｛A,B,C｝のうちのいずれかを表す。したがって、このような論理的言語は、通常、特定の実施形態が少なくとも１つのA、少なくとも１つのB、及び少なくとも１つのCのそれぞれが存在必要があることを意味することを意図しない。

【0297】

本願明細書に記載の処理の動作は、本願明細書に示されない限り、又は文脈上明らかに矛盾しない限り、任意の適切な順序で実行できる。本願明細書に記載の処理（又はその変形及び／又は結合）は、実行可能命令により構成される１つ以上のコンピュータシステムの制御下で実行されてよく、１つ以上のプロセッサ上で集合的に実行するコード（例えば、実行可能命令、１つ以上のコンピュータプログラム又は１つ以上のアプリケーション）として、ハードウェアにより、又はそれらの組み合わせで実装されてよい。コードは、コンピュータ可読記憶媒体に、例えば１つ以上のプロセッサにより実行可能な複数の命令を含むコンピュータプログラムの形式で格納されてよい。コンピュータ可読記憶媒体は、非一時的であってよい。

【0298】

本願明細書で与えられる任意の及び全ての例又は例示的言語（例えば、「のような」）の使用は、単に、本発明の実施形態をより良好に解明することを意図しており、特に断りのない限り本発明の範囲を限定することを意図しない。明細書中のいかなる言語も、本発明の実施に不可欠な任意の非請求要素を示すと考えられるべきではない。

【0299】

本開示の実施形態は、本願明細書に記載され、本発明を実施するために発明者に知られている最適モードを含む。これらの実施形態の変形は、前述の説明を読んだ当業者に明らかになり得る。発明者は、熟練技術者が、これらの変形を適切に利用することを期待し、発明者は、本開示の実施形態が本願明細書に特に記載されたものと異なる方法で実施されることを意図する。したがって、本開示の範囲は、適切な法により許可されるように、添付の請求の範囲に詳述された主題の全ての変形及び均等物を含む。さらに、それらの全ての可能な変形における上述の要素の任意の組み合わせは、本願明細書に特に断りの無い限り又は文脈に明確に矛盾しない限り、本開示の範囲に包含される。

【0300】

留意すべきことに、開示の実施形態を説明する文脈において、特に断りのない限り、「命令」が通常単独で実行しない動作（例えば、データの送信、計算、等）を実行する実行可能命令（コード、アプリケーション、エージェント、等とも呼ばれる）に関する表現の使用は、命令が機械により実行されることを示し、それにより機械に指定された演算を実行させる。

【0301】

留意すべきことに、上述の実施形態は、本発明を限定するのではなく、当業者は添付の請求項により定められる本発明の範囲から逸脱することなく多数の代替の実施形態を考案できる。請求項中、括弧内に記載された如何なる参照符号も、請求項を制限すると見なされるべきではない。用語「有する（comprising又はcomprises）」等は、全体としていかなる請求項中に及び明細書に列挙された以外の要素又はステップの存在を排除するものではない。本願明細書において、「有する（comprises）」は「含む（includes）又は構成される（consists of）」を意味し、「有する（comprising）」は「含む（including）又は構成される（including of）」を意味する。要素の単数の参照は、該要素の複数の存在を排除するものではなく、逆も同様である。本発明は、複数の別個の要素を有するハードウェアにより又は適切にプログラムされたコンピュータにより、実施され得る。複数の手段を列挙している装置の請求項では、これらの複数の手段は、１つの同一のハードウェア要素により実装することができる。特定の量が相互に異なる従属請求項に記載されるという事実は、これらの量の組合せが有利に用いることが出来ないことを示すものではない。

【0302】

１０２ノード

【図1】