したがって、上述の態様のうちの1つ以上において、ブロックチェーン技術を向上する方法及び装置を提供することが望ましい。したがって、本発明によると、添付の請求の範囲に定められるような方法が提供される。
以下に詳述するように、コンピュータにより実施される方法及び電子装置は、アンロックスクリプトがブロックヘッダ、ブロックチェーン、又はブロックヘッダのチェーンを含むことを要求するために、アンロックスクリプト内のデータに対する制約を実施するよう構成される。このような制約をアンロックスクリプト内のデータに対して実施することにより、及びこのようなデータをアンロックスクリプトに実行時に挿入することにより、トランザクションは、ブロックチェーンの側面に基づくことができる。
したがって、本発明によると、添付の請求の範囲に定められるような方法(及び対応するシステム)が提供され得る。方法は、ブロックチェーンデータ制約方法として記載され得る。コンピュータにより実施される方法は、(i)ブロックチェーンネットワーク内のノードにおいて、第2トランザクションに対する制約セットを指定する第1スクリプトを含む第1トランザクションを受信するステップであって、前記制約セットは、前記ノードにより取得されたデータセットが前記ブロックチェーンネットワークに関連付けられたブロックチェーンから取得される情報を含むという制約を含む、ステップと、(ii)前記第2トランザクションを取得するステップであって、前記第2トランザクションは、実行された結果として、ノードに前記データセットを取得させる第2スクリプトを含む、ステップと、(iii)前記第1スクリプト及び前記第2スクリプトを実行することにより、前記第2トランザクションを検証するステップと、を含む。
以下に詳述するように、コンピュータにより実施される方法及び電子装置は、前記アンロックスクリプトが前記ロックスクリプトを解除するために使用可能になり、前記トランザクションのデジタルアセットにアクセスする前に、前記ブロックチェーンが特定状態になることを要求するために、前記アンロックスクリプト内のデータに対する制約を実装するよう構成される。アンロックスクリプトがブロックヘッダ、ブロックチェーン、又はブロックヘッダチェーンを含むことを要求するためにロックスクリプトに対する制約を実施することにより、及びこのようなデータをアンロックスクリプトに実行時に導入することにより、トランザクションは、ブロックチェーンの状態に基づくことができる。
制約セットは、データセットがブロックチェーンのブロックのブロックヘッダを含むという制約を含んでよい。
ノードは、データセットがブロックチェーンのブロックのブロックヘッダを含むという制約が満たされるか否かを、少なくともブロックヘッダが所定サイズを有することを検証することにより、決定してよい。追加又は代替で、ノードは、データセットがブロックチェーンのブロックのブロックヘッダを含むという制約が満たされるか否かを、少なくともブロックヘッダが採掘難易度値以上である採掘難易度値を含むことを検証することにより、決定してよい。追加又は代替で、ノードは、データセットがブロックチェーンのブロックのブロックヘッダを含むという制約が満たされるか否かを、少なくともブロックヘッダのハッシュがブロックヘッダに含まれる採掘難易度値から計算された目標値以下であることを検証することにより、決定してよい。
制約セットは、データセットがブロックチェーンのブロックからの第3トランザクションを含むという制約を含んでよい。
データセットは、ブロックチェーンのブロックのブロックヘッダを含んでよい。追加又は代替で、制約セットは、第3トランザクションがブロックに含まれるという制約を含んでよい。追加又は代替で、ノードは、第3トランザクションがブロックに含まれるという制約が満たされるか否かを、ブロックチェーンのブロックのブロックヘッダに少なくとも部分的に基づき決定してよい。
ノードは、第3トランザクションがブロックに含まれるという制約が満たされるか否かを、少なくとも、第3トランザクションのハッシュ値を少なくとも部分的にブロックヘッダにより識別されるブロック内のトランザクションの符号化に基づき、決定してよい。追加又は代替で、ノードは、第3トランザクションがブロックに含まれるという制約が満たされるか否かを、少なくとも、第3トランザクションのハッシュ値がブロックヘッダに格納されたハッシュ値に等しいことを検証することにより、決定してよい。
前記制約セットは、前記データセットが、ブロックヘッダ順序セットを含むブロックヘッダチェーンを含むという制約を含んでよく、前記ブロックヘッダ順序セットは、複数のブロックヘッダを含み、前記ブロックヘッダ順序セットは、前記複数のブロックヘッダに関連付けられた順序を指定する。
ノードは、第2スクリプトがブロックヘッダチェーンを含むという制約が満たされるか否かを、少なくとも、少なくとも部分的に複数のブロックヘッダに関連付けられた順序に基づき、ブロックヘッダペアを選択することにより、決定してよく、ブロックヘッダのペアは、ブロックヘッダのペアの第1ブロックヘッダと、ブロックヘッダのペアの第2ブロックヘッダと、を含む。追加又は代替で、ノードは、第2スクリプトがブロックヘッダチェーンを含むという制約が満たされるか否かを、少なくともブロックヘッダペアについて、ブロックヘッダのペアの第1ブロックヘッダのハッシュがブロックヘッダのペアの第2ブロックヘッダに格納されたハッシュ値に等しいことを検証することにより、決定してよい。
制約セットは、データセットがブロックチェーンネットワークのパブリックブロックチェーンから取得されるという制約を含んでよい。
ブロックチェーンネットワークの1つ以上の特性は、第1スクリプト及び第2スクリプトを実行する前に、ノードに提供されてよい。
第2トランザクションの検証は、第2トランザクションを生成したエンティティが秘密情報へのアクセスを有することを検証することなく、成功裏に実行されてよい。
第1スクリプトは、第1トランザクションのロックスクリプトであってよく、第2トランザクションは第1スクリプトのアンロックスクリプトである。
コンピュータにより実施される方法は、検証の結果に少なくとも部分的に基づき、デジタルアセットを移転するステップを更に含んでよい。したがって、本発明によると、添付の請求の範囲に定められるような方法(及び対応するシステム)が提供され得る。方法は、ブロックチェーン状態確認方法として記載され得る。コンピュータにより実施される方法は、(i)ブロックチェーンネットワーク内のノードにおいて、第1トランザクションを受信するステップであって、前記第1トランザクションは、少なくとも、a)第2トランザクションに対する第1制約セットであって、前記第1制約セットは、前記第2トランザクションにブロックチェーンからのデータセットを含ませる1つ以上の制約を含む、第1制約セットと、b)前記第2トランザクションに対する第2制約セットであって、前記第2制約セットは、前記データセットのデータアイテムに関連付けられた1つ以上の制約を含む、第2制約セットと、を指定する、ステップと、(ii)前記第1制約セット及び前記第2制約セットが満たされることを検証するステップの結果として、前記第2トランザクションを前記ブロックチェーンに格納させるステップと、を含む。
以下に詳述するように、コンピュータにより実施される方法及び電子装置は、前記アンロックスクリプトが前記ロックスクリプトを解除するために使用可能になる前に、前記ブロックチェーンが特定状態になることを要求するために、及びそれらの状態にある前記トランザクションのデジタルアセットへのアクセスを調整するために、前記アンロックスクリプト内のデータに対する制約を実装するよう構成される。アンロックスクリプトがブロックヘッダ、ブロックチェーン、又はブロックヘッダチェーンを含むことを要求するためにロックスクリプトに対する制約を実施することにより、及びこのようなデータをアンロックスクリプトに実行時に導入することにより、トランザクションの結果は、ブロックチェーンの状態に基づくことができる。
データセットは、第2トランザクションの中で、ノードにおいて受信されてよい。
コンピュータにより実施される方法は、前記検証するステップの結果として、前記第2トランザクションを有効化するステップ、を更に含んでよい。
第2トランザクションの有効化は、第2トランザクションを生成したエンティティが秘密情報へのアクセスを有することを検証することなく、成功裏に実行されてよい。
第1制約セットは、データセットがブロックチェーンのブロックのブロックヘッダを含むという制約を含んでよい。
第1制約セットは、データセットがブロックチェーンのブロックからの第3トランザクションを含むという制約を含んでよい。
前記第1制約セットは、前記データセットが、ブロックヘッダ順序セットを含むブロックヘッダチェーンを含むという制約を含んでよく、前記ブロックヘッダ順序セットは、複数のブロックヘッダを含み、前記ブロックヘッダ順序セットは、前記複数のブロックヘッダに関連付けられた順序を指定する。
第2制約セットは、データセットのデータアイテムの値に対する制約を含んでよい。
第2制約セットは、データセットのデータアイテムに関連付けられた1つ以上の値から導出される制約を含んでよい。
第1制約セットは、第1トランザクションのロックスクリプトに含まれてよい。
第2制約セットは、第1トランザクションのロックスクリプトに含まれてよい。
第1制約セットは、データセットがパブリックブロックチェーンから受信されるという制約を含んでよい。
ノードは、データセットがパブリックブロックチェーンから受信されるという制約が満たされるか否かを、少なくとも、第2トランザクションの中で、ブロックチェーンネットワークから受信されるブロックの前のブロックを含む第1ブロックセットと、ブロックチェーンネットワークから受信されるブロックの後のブロックを含む第2ブロックセットと、を受信することにより、決定してよい。追加又は代替で、ノードは、データセットがパブリックブロックチェーンから受信されるという制約が満たされるか否かを、少なくとも、第1ブロックセットがブロックチェーンネットワークから受信したブロックにチェーン(chain)されることを検証することにより決定してよい。追加又は代替で、ノードは、データセットがパブリックブロックチェーンから受信されるという制約が満たされるか否かを、少なくとも、第2ブロックセットがブロックチェーンネットワークから受信したブロックにチェーンされることを検証することにより決定してよい。追加又は代替で、ノードは、データセットがパブリックブロックチェーンから受信されるという制約が満たされるか否かを、少なくとも、第1ブロックセット及び第2ブロックセットが有効であることを検証することにより決定してよい。追加又は代替で、ノードは、データセットがパブリックブロックチェーンから受信されるという制約が満たされるか否かを、少なくとも、第1ブロックセット及び第2ブロックセットの各ブロックが所定値より大きい採掘難易度値を有することを検証することにより決定してよい。
したがって、本発明によると、添付の請求の範囲に定められるような方法(及び対応するシステム)が提供され得る。方法は、ブロックチェーン状態認識方法として記載され得る。コンピュータにより実施される方法は、(i)ブロックチェーンネットワーク内のノードにおいて、第1トランザクションを受信するステップであって、前記第1トランザクションは、少なくとも、a)第2トランザクションに対する第1制約セットであって、前記第1制約セットは、前記第2トランザクションにブロックチェーンネットワークからのデータセットを含ませる1つ以上の制約を含む、第1制約セットと、b)前記第2トランザクションに対する第2制約セットであって、前記第2制約セットは、前記データセットが前記第1トランザクションを含むブロックを含むという制約を含み、前記ブロックは前記ブロックチェーンネットワークに関連付けられたブロックチェーンに含まれる、第2制約セットと、を指定する、ステップと、(ii)前記第1制約セット及び前記第2制約セットが満たされることを検証するステップの成功の結果として、前記第2トランザクションを前記ブロックチェーンネットワークに記録させるステップと、を含む。
データセットは、第2トランザクションの中で、ノードにおいて受信されてよい。
第1制約セットは、データセットがブロックチェーンのブロックのブロックヘッダを含むという制約を含んでよい。
第1制約セットは、データセットがブロックチェーンのブロックからの第3トランザクションを含むという制約を含んでよい。
前記第1制約セットは、前記データセットが、ブロックヘッダ順序セットを含むブロックヘッダチェーンを含むという制約を含んでよく、前記ブロックヘッダ順序セットは、複数のブロックヘッダを含み、前記ブロックヘッダ順序セットは、前記複数のブロックヘッダに関連付けられた順序を指定する。
ブロックチェーンネットワークの特性セットは、第1制約セット及び第2制約セットが満たされることを検証するステップの結果として、ノードに提供されてよい。
ブロックチェーンネットワークの特性セットは、ブロックチェーンネットワークのブロックチェーンの各ブロックに関連付けられた対応するタイムスタンプを含んでよい。
第1制約セットは、第2トランザクションがブロックに対するタイムスタンプを含むという制約を含んでよい。追加又は代替で、第2トランザクションがブロックに対するタイムスタンプを含むという制約を検証するステップは、少なくとも部分的に、ブロックチェーンネットワークの特性セットに基づいてよい。
第1制約セットは、データセットがブロックヘッダを含むという制約を含んでよい。追加又は代替で、第2制約セットは、第2トランザクションが第1トランザクションの識別子を含むという制約を含んでよい。追加又は代替で、第2制約セットは、第1トランザクションの識別子がブロックヘッダの値に関連付けられるという制約を含んでよい。
第1制約セット及び第2制約セットは、トランザクションのロックスクリプトに含まれてよい。
第1トランザクションは、第2トランザクションに対する第3制約セットを指定してよく、第3制約セットは、データセットのデータアイテムの値に対する制約を含む。
第1トランザクションは、第2トランザクションに対する第3制約セットを指定してよく、第3制約セットは、データセットのデータアイテムに関連付けられた1つ以上の値から導出される制約を含む。
コンピュータにより実施される方法は、第1制約セット及び第2制約セットが満たされることを検証するステップの結果として、第2トランザクションを有効化するステップを更に含んでよい。ここで、第2トランザクションは、第2トランザクションを生成したエンティティが秘密情報へのアクセスを有することを検証することなく、成功裏に実行される。したがって、本発明によると、添付の請求の範囲に定められるような方法(及び対応するシステム)が提供され得る。方法は、ブロックチェーンデータ制約方法として記載され得る。コンピュータにより実施される方法は、(i)ブロックチェーンネットワーク内のノードにおいて、デジタルアセットに関連付けられた第1トランザクションを受信するステップであって、前記第1トランザクションは、前記デジタルアセットの制御を移転するための第2トランザクションに対する制約セットを指定する第1スクリプトを含み、前記制約セットは、前記ノードにより取得されたデータセットが前記ブロックチェーンネットワークに関連付けられたブロックチェーンから取得された情報を含むという制約を含む、ステップと、(ii)前記第2トランザクションを取得するステップであって、前記第2トランザクションは、実行された結果として、ノードに前記データセットを取得させる第2スクリプトを含む、ステップと、(iii)前記第1スクリプト及び前記第2スクリプトを実行することにより、前記第2トランザクションを有効化するステップと、を含む。
制約セットは、データセットがブロックチェーンのブロックのブロックヘッダを含むという制約を含んでよい。
ノードは、データセットがブロックチェーンのブロックのブロックヘッダを含むという制約が満たされるか否かを、少なくともブロックヘッダが所定サイズを有することを検証することにより、決定してよい。追加又は代替で、ノードは、データセットがブロックチェーンのブロックのブロックヘッダを含むという制約が満たされるか否かを、少なくともブロックヘッダが採掘難易度値以上である採掘難易度値を含むことを検証することにより、決定してよい。追加又は代替で、ノードは、データセットがブロックチェーンのブロックのブロックヘッダを含むという制約が満たされるか否かを、少なくともブロックヘッダのハッシュがブロックヘッダに含まれる採掘難易度値から計算された目標値以下であることを検証することにより、決定してよい。
制約セットは、データセットがブロックチェーンのブロックからの第3トランザクションを含むという制約を含んでよい。
データセットは、ブロックチェーンのブロックのブロックヘッダを含んでよい。追加又は代替で、制約セットは、第3トランザクションがブロックに含まれるという制約を含んでよい。追加又は代替で、ノードは、第3トランザクションがブロックに含まれるという制約が満たされるか否かを、ブロックチェーンのブロックのブロックヘッダに少なくとも部分的に基づき決定してよい。
ノードは、第3トランザクションがブロックに含まれるという制約が満たされるか否かを、少なくとも、第3トランザクションのハッシュ値を少なくとも部分的にブロックヘッダにより識別されるブロック内のトランザクションの符号化に基づき、決定してよい。追加又は代替で、ノードは、第3トランザクションがブロックに含まれるという制約が満たされるか否かを、少なくとも、第3トランザクションのハッシュ値がブロックヘッダに格納されたハッシュ値に等しいことを検証することにより、決定してよい。
前記第1制約セットは、前記データセットが、ブロックヘッダ順序セットを含むブロックヘッダチェーンを含むという制約を含んでよく、前記ブロックヘッダ順序セットは、複数のブロックヘッダを含み、前記ブロックヘッダ順序セットは、前記複数のブロックヘッダに関連付けられた順序を指定する。
ノードは、第2スクリプトがブロックヘッダチェーンを含むという制約が満たされるか否かを、少なくとも、少なくとも部分的に複数のブロックヘッダに関連付けられた順序に基づき、ブロックヘッダペアを選択することにより、決定してよく、ブロックヘッダのペアは、ブロックヘッダのペアの第1ブロックヘッダと、ブロックヘッダのペアの第2ブロックヘッダと、を含む。追加又は代替で、ノードは、第2スクリプトがブロックヘッダチェーンを含むという制約が満たされるか否かを、少なくともブロックヘッダペアについて、ブロックヘッダのペアの第1ブロックヘッダのハッシュがブロックヘッダのペアの第2ブロックヘッダに格納されたハッシュ値に等しいことを検証することにより、決定してよい。
制約セットは、データセットがブロックチェーンネットワークのパブリックブロックチェーンから取得されるという制約を含んでよい。
ブロックチェーンネットワークの1つ以上の特性は、第1スクリプト及び第2スクリプトを実行する前に、ノードに提供されてよい。
第2トランザクションの有効化は、第2トランザクションを生成したエンティティが秘密情報へのアクセスを有することを検証することなく、成功裏に実行されてよい。
第1スクリプトは、第1トランザクションのロックスクリプトであってよく、第2トランザクションは第1スクリプトのアンロックスクリプトである。
コンピュータにより実施される方法は、検証の結果に少なくとも部分的に基づき、デジタルアセットを移転するステップを更に含んでよい。
したがって、本発明によると、添付の請求の範囲に定められるような方法(及び対応するシステム)が提供され得る。方法は、ブロックチェーン状態確認方法として記載され得る。コンピュータにより実施される方法は、(i)ブロックチェーンネットワーク内のノードにおいて、デジタルアセットに関連付けられた第1トランザクションを受信するステップであって、前記第1トランザクションは、少なくとも、a)前記デジタルアセットの制御を転送するための第2トランザクションに対する第1制約セットであって、前記第1制約セットは、前記第2トランザクションにブロックチェーンからのデータセットを含ませる1つ以上の制約を含む、第1制約セットと、b)前記第2トランザクションに対する第2制約セットであって、前記第2制約セットは、前記データセットのデータアイテムに関連付けられた1つ以上の制約を含む、第2制約セットと、を指定する、ステップと、(ii)前記第1制約セット及び前記第2制約セットが満たされることを検証するステップと、(iii)前記検証するステップに少なくとも部分的に基づき、前記デジタルアセットを再関連付けするステップと、を含む。
データセットは、第2トランザクションの中で、ノードにおいて受信されてよい。
コンピュータにより実施される方法は、前記検証するステップの結果として、前記第2トランザクションを有効化するステップ、を更に含んでよい。
第2トランザクションの有効化は、第2トランザクションを生成したエンティティが秘密情報へのアクセスを有することを検証することなく、成功裏に実行されてよい。
第1制約セットは、データセットがブロックチェーンのブロックのブロックヘッダを含むという制約を含んでよい。
第1制約セットは、データセットがブロックチェーンのブロックからの第3トランザクションを含むという制約を含んでよい。
前記第1制約セットは、前記データセットが、ブロックヘッダ順序セットを含むブロックヘッダチェーンを含むという制約を含んでよく、前記ブロックヘッダ順序セットは、複数のブロックヘッダを含み、前記ブロックヘッダ順序セットは、前記複数のブロックヘッダに関連付けられた順序を指定する。
第2制約セットは、データセットのデータアイテムの値に対する制約を含んでよい。
第2制約セットは、データセットのデータアイテムに関連付けられた1つ以上の値から導出される制約を含んでよい。
第1制約セットは、第1トランザクションのロックスクリプトに含まれてよい。
第2制約セットは、第1トランザクションのロックスクリプトに含まれてよい。
第1制約セットは、データセットがパブリックブロックチェーンから受信されるという制約を含んでよい。
ノードは、データセットがパブリックブロックチェーンから受信されるという制約が満たされるか否かを、少なくとも、第2トランザクションの中で、ブロックチェーンネットワークから受信されるブロックの前のブロックを含む第1ブロックセットと、ブロックチェーンネットワークから受信されるブロックの後のブロックを含む第2ブロックセットと、を受信することにより、決定してよい。追加又は代替で、ノードは、データセットがパブリックブロックチェーンから受信されるという制約が満たされるか否かを、少なくとも、第1ブロックセットがブロックチェーンネットワークから受信したブロックにチェーンされることを検証することにより決定してよい。追加又は代替で、ノードは、データセットがパブリックブロックチェーンから受信されるという制約が満たされるか否かを、少なくとも、第2ブロックセットがブロックチェーンネットワークから受信したブロックにチェーンされることを検証することにより決定してよい。追加又は代替で、ノードは、データセットがパブリックブロックチェーンから受信されるという制約が満たされるか否かを、少なくとも、第1ブロックセット及び第2ブロックセットが有効であることを検証することにより決定してよい。追加又は代替で、ノードは、データセットがパブリックブロックチェーンから受信されるという制約が満たされるか否かを、少なくとも、第1ブロックセット及び第2ブロックセットの各ブロックが所定値より大きい採掘難易度値を有することを検証することにより決定してよい。
したがって、本発明によると、添付の請求の範囲に定められるような方法(及び対応するシステム)が提供され得る。方法は、ブロックチェーン状態認識方法として記載され得る。コンピュータにより実施される方法は、(i)ブロックチェーンネットワーク内のノードにおいて、デジタルアセットに関連付けられた第1トランザクションを受信するステップであって、前記第1トランザクションは、少なくとも、a)前記デジタルアセットの制御を転送するための第2トランザクションに対する第1制約セットであって、前記第1制約セットは、前記第2トランザクションにブロックチェーンネットワークからのデータセットを含ませる1つ以上の制約を含む、第1制約セットと、b)前記第2トランザクションに対する第2制約セットであって、前記第2制約セットは、前記データセットが前記1トランザクションを含むブロックを含むという制約を含み、前記ブロックは、前記ブロックチェーンネットワークに関連付けられたブロックチェーンに含まれる、第2制約セットと、を指定する、ステップと、(ii)前記第1制約セット及び前記第2制約セットが満たされることを検証するステップと、(iii)前記検証するステップに少なくとも部分的に基づき、前記デジタルアセットの制御を移転するステップと、を含む。
データセットは、第2トランザクションの中で、ノードにおいて受信されてよい。
第1制約セットは、データセットがブロックチェーンのブロックのブロックヘッダを含むという制約を含んでよい。
第1制約セットは、データセットがブロックチェーンのブロックからの第3トランザクションを含むという制約を含んでよい。
前記第1制約セットは、前記データセットが、ブロックヘッダ順序セットを含むブロックヘッダチェーンを含むという制約を含んでよく、前記ブロックヘッダ順序セットは、複数のブロックヘッダを含み、前記ブロックヘッダ順序セットは、前記複数のブロックヘッダに関連付けられた順序を指定する。
ブロックチェーンネットワークの特性セットは、第1制約セット及び第2制約セットが満たされることを検証するステップの結果として、ノードに提供されてよい。
ブロックチェーンネットワークの特性セットは、ブロックチェーンネットワークのブロックチェーンの各ブロックに関連付けられた対応するタイムスタンプを含んでよい。
第1制約セットは、第2トランザクションがブロックに対するタイムスタンプを含むという制約を含んでよい。追加又は代替で、第2トランザクションがブロックに対するタイムスタンプを含むという制約を検証するステップは、少なくとも部分的に、ブロックチェーンネットワークの特性セットに基づいてよい。
第1制約セットは、データセットがブロックヘッダを含むという制約を含んでよい。追加又は代替で、第2制約セットは、第2トランザクションが第1トランザクションの識別子を含むという制約を含んでよい。追加又は代替で、第2制約セットは、第1トランザクションの識別子がブロックヘッダの値に関連付けられるという制約を含んでよい。
第1制約セット及び第2制約セットは、トランザクションのロックスクリプトに含まれてよい。
第1トランザクションは、第2トランザクションに対する第3制約セットを指定してよく、第3制約セットは、データセットのデータアイテムの値に対する制約を含む。
第1トランザクションは、第2トランザクションに対する第3制約セットを指定してよく、第3制約セットは、データセットのデータアイテムに関連付けられた1つ以上の値から導出される制約を含む。
コンピュータにより実施される方法は、第1制約セット及び第2制約セットが満たされることを検証するステップの結果として、第2トランザクションを有効化するステップを更に含んでよい。ここで、第2トランザクションは、第2トランザクションを生成したエンティティが秘密情報へのアクセスを有することを検証することなく、成功裏に実行される。
また、システムであって、プロセッサと、前記プロセッサによる実行の結果として前記システムに上述の方法のいずれかを実行させる実行可能命令を含むメモリと、を含むシステムを提供することが望ましい。
また、実行可能命令を格納した非一時的コンピュータ可読記憶媒体であって、前記実行可能命令は、コンピュータシステムのプロセッサにより実行された結果として、前記コンピュータシステムに上述の方法のいずれかを少なくとも実行させる、非一時的コンピュータ可読記憶媒体を提供することが望ましい。
また、システムであって、プロセッサと、前記プロセッサによる実行の結果として前記システムに上述の方法のいずれかを実行させる実行可能命令を含むメモリと、を含むシステムを提供することが望ましい。
本発明によると、電子装置が提供され得る。電子装置は、インタフェース装置と、前記インタフェース装置に結合されたプロセッサと、前記プロセッサに結合されたメモリとを含む。前記メモリは、実行されると、本願明細書に記載の方法を実行するよう前記プロセッサを構成するコンピュータ実行可能を格納している。
本発明によると、コンピュータ可読記憶媒体が提供され得る。コンピュータ可読記憶媒体は、実行されると、本願明細書に記載の方法を実行するようプロセッサを構成するコンピュータ実行可能命令を含む。
本発明の上述の及び他の態様は、本願明細書に記載される実施形態から明らかであり、それらの実施形態を参照して教示される。本発明の実施形態は、単なる例として添付の図面を参照して以下に説明される。
先ず、図1を参照する。図1は、図の形式で、種々の実施形態が実施され得る、ブロックチェーンに関連付けられた例示的なブロックチェーンネットワーク100を示す。ブロックチェーンプロトコルの下でブロックチェーンネットワーク100が動作し、該ブロックチェーンプロトコルのインスタンスを実行する分散型電子装置は、ブロックチェーンネットワーク100に参加してよい。このような分散型電子装置は、ノード102として参照され得る。ブロックチェーンプロトコルは、例えばビットコインプロトコルであってよい。
ブロックチェーンプロトコルを実行し、ブロックチェーンネットワーク100のノード102を形成する電子装置は、例えばデスクトップコンピュータ、ラップトップコンピュータ、タブレットコンピュータ、サーバのようなコンピュータ、スマートフォンのようなモバイル装置、スマートウォッチのようなウェアラブルコンピュータ、又は他の電子装置を含む様々な種類であってよい。
ブロックチェーンネットワーク100のノード102は、有線及び無線通信技術を含み得る適切な通信技術を用いて互いに結合される。このような通信は、ブロックチェーンに関連付けられたプロトコルに従う。例えば、ブロックチェーンがビットコインブロックチェーンである場合、ビットコインプロトコルが使用されてよい。ノード102は、ブロックチェーン上の全てのトランザクションのグローバル台帳を維持する。したがって、グローバル台帳は分散台帳である。各ノード102は、グローバル台帳の完全コピー又は部分コピーを格納してよい。グローバル台帳に影響を与えるノード102によるトランザクションは、他のノード102により検証される。その結果、グローバル台帳の有効性が維持される。ブロックチェーンがproof−of−workに基づくブロックチェーンであるとき、ブロックも、ブロックと共に提出されるproof−of−workをチェックすることにより検証される。
ノード102の少なくとも幾つかは、ブロックチェーンネットワーク100のマイナー104として動作する。図1のブロックチェーンネットワーク100は、ブロックチェーン上のトランザクションを促進するために、マイナー104が費用の掛かる計算を実行するproof−of−workブロックチェーンである。例えば、proof−of−workブロックチェーンは、マイナーが暗号化問題を解くことを要求し得る。ビットコインでは、マイナー104がノンスを発見する。その結果、ブロックヘッダは、double SHA−256により、現在の採掘難易度(difficultly)により定められた値より小さい数にハッシュされる。proof−of−workアルゴリズムのために必要なハッシュ能力は、特定数のブロックがその上でマイニングされた後に、トランザクションが事実上不可逆であると見なされることを意味する。暗号化問題を解くマイナー104は、ブロックチェーンの新しいブロックを生成し、新しいブロックを他のノード102にブロードキャストする。他のノード102は、ブロックがブロックチェーンに追加されるべきであると受け入れる前に、マイナー104が実際に暗号化問題を解き、したがって充分なproof−of−workを立証したことを検証する。他のノード102も、ブロック自体が有効であること(例えば、トランザクション及びブロックのブロックヘッダが有効であること)を、ブロックがブロックチェーンに追加されることを許諾する前に検証する。ブロックは、ノード102の総意により、ブロックチェーンに(つまり分散グローバル台帳に)追加される。
マイナー104により生成されたブロックは、ノード102によりブロックチェーンにブロードキャストされているトランザクションを含む。例えば、ブロックは、ノード102のうちの1つに関連付けられたアドレスからノード102のうちの別のものに関連付けられたアドレスへのトランザクションを含んでよい。このように、ブロックは、あるアドレスから別のアドレスへのトランザクションのレコードとして機能する。トランザクションがブロックに含まれることを要求したパーティは、彼らが転送を開始すること(例えば、ビットコインの場合には、ビットコインを移転すること)を認可されていることを、彼らの公開鍵に対応する秘密鍵を用いて要求に署名することにより、証明する。要求が有効に署名された場合のみ、転送はブロックに追加されてよい。
ビットコインの場合、公開鍵とアドレスとの間には1対1対応がある。つまり、各公開鍵は単一のアドレスに関連付けられる。したがって、本願明細書でデジタルアセットを公開鍵へ又は公開鍵から転送する(例えば、公開鍵に関連付けられたアドレスに支払う)、及びデジタルアセットを公開鍵に関連付けられたアドレスへ又は該アドレスから転送するという言及は、共通の動作を表す。
ノード102のうちの幾つかは、マイナーとして動作しなくてよく、代わりに検証ノードとして参加してよい。トランザクションの検証は、署名又はロックスクリプト内で指定された他の条件をチェックすること、有効UTXOへの参照を確認すること、等に関連してよい。図1の例は、6個のノード102を含み、そのうちの2個はマイナー104として参加している。実際には、ノード102又はマイナー104の数は異なってよい。多くのブロックチェーンネットワークでは、ノード102及びマイナー104の数は、図1に示した数より遙かに多くてよい。
図2は、一実施形態による、ブロック図形式で、ブロックチェーンネットワーク(例えば、図1と関連して説明したブロックチェーンネットワーク100のようなブロックチェーンネットワーク)におけるノード(例えば、図1と関連して説明したノード102のうちの1つのようなノード)として機能し得る例示的な電子装置200を示す。例示的な電子装置200は、図1と関連して説明したブロックチェーンネットワークのようなブロックチェーンネットワークにおける、図1と関連して説明したノード102のうちの1つのようなノードとして機能してよい。一実施形態では、ブロックチェーンネットワークは、ピアツーピアブロックチェーンネットワークである。
電子装置は、例えばデスクトップコンピュータ、ラップトップコンピュータ、タブレットコンピュータ、サーバ、スマートフォンのようなモバイル装置、スマートウォッチのようなウェアラブルコンピュータ、又は別の種類の形式を含む様々な形式をとってよい。
電子装置200は、プロセッサ210、メモリ220、及びインタフェース装置230を含む。これらのコンポーネントは、互いに直接又は間接に結合されてよく、互いに通信してよい。例えば、プロセッサ210、メモリ220、及びインタフェース装置230は、バス240を介して互いに通信してよい。メモリ220は、本願明細書に記載の機能を実行するための機械可読命令及びデータを含むコンピュータソフトウェアプログラムを格納する。例えば、メモリは、プロセッサ210により実行されると、電子装置に本願明細書に記載の方法を実行させるプロセッサ実行可能命令を含んでよい。プロセッサ実行可能命令は、プロセッサ210により実行されると、電子装置に、ブロックチェーンネットワーク(例えば図1と関連して記載したブロックチェーンネットワーク100)に関連付けられたプロトコルを実装させる命令を含んでよい。例えば、命令は、ビットコインプロトコルを実装するための命令を含んでよい。
メモリ220は、ブロックチェーンネットワーク(例えば図1と関連して記載したブロックチェーンネットワーク100)のグローバル台帳又はその部分を格納してよい。つまり、メモリ220は、ブロックチェーンの全部のブロック、又は最近のブロックのようなブロックの部分、又は幾つかのブロックの中の情報の部分を格納してよい。
メモリ220は図2では単一のブロックにより示されるが、実際には、電子装置200は複数のメモリコンポーネントを含んでよい。メモリコンポーネントは、例えばRAM、HDD、SSD、フラッシュドライブ、等を含む様々な種類であってよい。異なる種類のメモリは、異なる目的に適してよい。さらに、メモリ220はプロセッサ210と別個に示されるが、プロセッサ210は内蔵メモリを含んでよい。
図2に示すように、プロセッサ210は、信頼できる実行環境(Trusted Execution Environment:TEE)のようなセキュア領域を含んでよい。TEE250は、電子装置200に、独立した実行、信頼できるアプリケーションの完全性及びアセット機密性のような追加セキュリティを提供する独立実行環境である。TEE250は、TEE250内部にロードされたコンピュータ命令及びデータが機密性及び完全性の観点で保護されることを保証する実行空間を提供する。TEE250は、暗号鍵のような重要リソースの完全性及び機密性を保護するために使用されてよい。TEE250は、少なくとも部分的にハードウェアレベルで実装される。その結果、TEE250内で実行される命令及びデータは、電子装置200の残りの部分からの及び電子装置の所有者のような外部パーティからのアクセス及び操作に対して保護される。TEE250内のデータ及び計算は、TEE250を含むノード(例えば図1と関連して記載したノード102)を作動させるパーティからセキュアにされる。
TEE250は、セキュア実行環境(本願明細書で「エンクレーブ(enclave、飛び地)」とも呼ばれる)をインスタンス化し、次にメモリページを1つずつ追加するよう動作し得ると同時に、追加したメモリページを累積的にハッシングする。一実施形態では、メモリページのハッシングは、リモートマシン(例えば、開発者の機械又は別の機械)上で実行される。その結果、リモートマシンは、期待されるハッシュを決定し及び格納する。enclaveの内容は、したがって、任意のリモートマシンにより検証でき、enclaveが承認済みアルゴリズムを実行していることを保証する。この検証は、ハッシュを比較することにより実行されてよい。enclaveは、完全に構築されると、固定化される。TEE250内でコードを実行すること、及びシークレットをコードに送信することが可能であるが、enclaveがロックされると、コードは変更できない。最終ハッシュは、アテステーション(attestation)鍵により署名されてよく、データ所有者が任意のシークレットをenclaveへ送信する前に、データ所有者がそれを検証するために利用可能にされてよい。
TEE250は、TEE250内に格納された暗号化鍵の信頼性及び完全性を保護するために使用されてよい。例えば、TEE250は、秘密鍵シェアの生成及び記憶のために使用されてよい。TEE250は、いかなるメンバーもTEE250内に保持された秘密鍵シェア又は他の秘密鍵シェアに関する情報をメンバー間通信又はenclave間通信から直接取得できないことを保証するためのものである。プロトコルは、閾値のenclaveのセキュリティ侵害(compromise)に対してもロバストである。さらに、TEE250は、リモートアテステーションを可能にし得る。リモートアテステーションは、ノード(例えば、図1と関連して説明したノード102のうちの1つのようなノード)により、TEE250が確実であり且つブロックチェーンネットワーク100により実施されるプロトコルのための承認済みコンピュータ実行可能命令を実行していることを他のノードに証明するために使用されてよい。リモートアテステーションは、TEE250により、特定のコードピースを実行すること、及びenclaveの内部で、enclaveの内部アテステーション鍵により署名されたコードのハッシュを送信することにより、提供されてよい。
TEE250は、セキュアな乱数生成器を備えてよい。このセキュアな乱数生成器は、TEEのenclaveの内部にあり、秘密鍵、ランダムチャレンジ、又は他のランダムデータを生成するために使用できる。TEE250は、また、外部メモリからデータを読み出すよう構成されてよく、外部メモリにデータを書き込むよう構成されてよい。このようなデータは、enclave内部にのみ保持されたシークレット鍵により暗号化されてよい。
TEE250は、信頼できるプラットフォームモジュール(Trusted Platform Module:TPM)又はIntel Software Guard Extensions(SGX)のような様々なプラットフォームを用いて実装されてよい。SGXは、例えば、リモートアテステーションをサポートする。リモートアテステーションは、enclaveが、署名されたステートメントを、クオート(quote)として知られるメンバーの与えられたハス(has)により特定のenclaveを実行しているプロセッサから取得することを可能にする。Intel Attestation Service(IAS)のような第三者アテステーションサービスは、これらの証明されたステートメントがSGX仕様に従う真正CPUから生じることを認定し得る。
本発明は、別のトランザクションのアンロックスクリプト内で提供される未確定データを用いて、ブロックチェーントランザクション(Tx)のロックスクリプト内に埋め込まれる暗号公開鍵を変更するよう構成される方法(及び対応するシステム)を提供し得る。例えば、連続トランザクションをメッセージとして使用するビットコインプロトコルにおける署名チェックオペコード(例えばOP_CHECKSIG)と関連して使用されるとき、トランザクション及びデータの両方が、公開鍵の所有者からの認可又は認証を要求する。これは、それらを変更から守る。
本願明細書に記載の方法は、1つ以上のデジタル署名方式を用いて、種々のトランザクションを検証する。デジタル署名方式は、楕円曲線デジタル署名アルゴリズム(Elliptic Curve Digital Signature Algorithm:ECDSA)方式であってよい。デジタル署名は、2者ECDSA方式であってもよい。デジタル署名は、閾値ECDSA方式であってもよい。この方式は、秘密鍵を再構成する必要がなく、及び任意のパーティが彼らの鍵シェアを別のパーティに開示する必要がなく、有効署名を構成するために使用されてよい。例えば、2者ECDSA方式では、2つのパーティが存在し、両者が秘密鍵を再構成する必要がある。
このECDSA方式は、図1に関連して記載したノード102のようなノードにより、不正又は非協力的パーティを識別するために使用され得る様々なメカニズムを含む。例えば、検証可能シークレット共有(verifiable secret sharing:VSS)は、Shamirのシークレット共有(Shamir’s Secret Sharing:SSS)のために必要な多項式を共有するために使用され得る。SSSは、シークレットが部分に分けられ、それ自体のユニークな部分への各々の参加に提供される、シークレット共有の形式である。これらの部分は、シークレットを再構成するために必要であり得る。VSSは、矛盾したシェアが異なるノードに提供された場合、又はシェアが全ノードにブロードキャストされる隠れ(ブラインド)シェアと異なり、シェアがノードへ秘密に送信された場合、ノードにより、不正ノード又はメンバーを識別するために使用されてよい。矛盾したシェアは、ノードのうちのいずれかにより識別されてよい。シークレットの共有は、ノードがそれらのシェアを矛盾しないとして検証することを可能にする補助情報を含むことにより、検証可能にされ得る。
不正シェアの個々のノードへの送信(つまり、ブロードキャストされる隠れシェアと異なるシェア)は、シェアの意図された受信ノードにより識別できる。ノードへ秘密に送信されている不正シェアの識別は、公然検証可能なシークレット共有(Publically Verifiable Secret Sharing:PVSS)の技術を用いて公に検証可能にできる。このような技術は、PVSSが使用されず及び不正シェアが送信されるときに不正シェアの受信側がオフラインである若しくはネットワークの根本部分から切り離されている場合に起こり得る、不正送信者の識別において起こり得る遅延を回避し得る。
矛盾したシェアを異なるノードに提供するような不正行為は、悪意ある行為を阻止するネットワークにより解決され得る。例えば、ノードが他のノードにより悪意あるパーティとして識別されると、多数のノードが協力して該悪意あるパーティにペナルティを科してよい。例えば、ノードは、不正パーティによりブロックチェーンネットワークに預けられた(デジタル通貨、トークン、又は他の掛け金若しくは価値)デジタルアセットに関連する措置を行ってよい。例えば、ブロックチェーンネットワークは、デジタル通貨、トークン、掛け金若しくは価値を引き換え不可(unredeemable)アドレスへ転送することにより、それらを焼却(burn)してよい。或いは、ブロックチェーンネットワークは、拒否するという他のノードとの総意に達することにより、このようなデジタルアセットを没収してよい。不正を行うノードではないノードは、不正を行うノードを排除するために協力することにより(例えば、鍵シェアを効果的に無効化することにより、例えば、ノードが議会プロトコルに参加するのを排除することにより、又は秘密鍵を再共有し及び不正を行うノードにシェアを割り当てないことにより)、不正行為を阻止してもよい。
上述のECDSA技術は、TEEの使用を通じて拡張されてよい。例えば、Ibrahim他に基づく閾値ECDSA署名技術は、ここではByzantine敵対者と呼ばれる強力な形式の敵対者を予期している。この種の敵対者は、勝手に振る舞うことがある。例えば、彼らは、署名処理に参加すること又は途中でパーティを停止することを拒否するだけでなく、誠実に参加するふりをして、不正情報を送信することもある。しかしながら、TEEを用い、及びシークレット秘密鍵シェアが格納されるTEEのenclave内で署名に使用するためのデータを生成することにより、enclaveが有意な数において危険に晒される可能性が非常に低いので、追加セキュリティが提供され得る。各TEEが1つより多くの鍵シェアに割り当てられる場合、例えば、起こり得る危険に晒されるTEEの数は、nが充分に大きいと仮定すると、敵対者に対するロバスト性の閾に近付かないことが無理なく期待され得る。これは、鍵シェアの合計数に対して少ない割合の不正敵対者に対して耐性がある場合、プロトコルがセキュアであることを可能にする。
例えば、全ノードがTEEを有する場合、enclave内に格納されたシークレットの取得は、TEEの製造者が堕落していないならば、ノードへの物理アクセスによってのみ、多大な努力及び費用によってのみ、達成され得る。このような製造者レベルの堕落は、管理可能であることが期待される。例えば、製造者が、多数の公開鍵が誠実なTEEに対応すると偽って主張しようとした場合、彼らは、秘密鍵シェアへの直接アクセスを獲得し、攻撃を始める可能性がある。しかしながら、このような攻撃は、製造者が他のノードからの支援を伴わずに有効署名を生成できるために、充分な数の鍵シェアを要求し得る。これは、非常に高価になり得る全部の掛け金の大部分を蓄積することを意味し得る。さらに、攻撃を実行することにより、保持している掛け金の価値の大部分が破壊され得る。
TEEが使用されるとき、「堕落したノード」に対するプロトコルのロバスト性を意図することが有用である。堕落したノードは、TEEの外部のハードウェアが間違いを含むが、TEEの完全性が危険に晒されないノードである。堕落したノードは、どんな情報をenclaveが受信し及び受信しないかについて制御を有してよい。特に、堕落したノードは、停止し、つまりプロトコルへの参加を控えてよい。プロトコルに提供される情報がenclave内に秘密に保持された秘密鍵により署名される必要のある場合(対応する公開鍵が、アテステーション中に認証された場合)、秘密鍵はenclave自体と同じくらい信頼できる。したがって、堕落したノードは、勝手な(認証された)情報をプロトコルに送信することができず、停止することにより、又は例えば古い情報を提供することにより誤って動作するようenclaveを欺くことを試みることにより、邪魔をしようとするだけである。次に、堕落したノードでは、成功した攻撃は、完全な署名を生成するのに充分な数の部分署名を収集することを必要とし得る。
幾つかの実施形態では、非ECDSA署名方式を含む他の閾値方式が使用されてよい。
図3は、スクリプトに基づくブロックチェーン相互作用に関連付けられたトランザクションの例示的な実施形態300を、図の形式で示す。図3に示す例示的な実施形態300は、ブロックチェーンの第1状態306をエンコードする前のブロックチェーントランザクション302と、ブロックチェーンの第2状態308をエンコードするアンロックブロックチェーントランザクション304と、を示す。例示的な実施形態300では、第1時間における現在状態306は、前のトランザクション302に埋め込まれたパラメータとして表される。一実施形態では、アンロックトランザクション304は、次の状態308を表すパラメータを含む。
例示的な実施形態300では、トランザクション302及び304は、1つ以上のインプット及び1つ以上のアウトプットを含むフィールド値セットである。幾つかの実施形態では、インプット及びアウトプットは、デジタルアセットの制御を少なくとも1つのエンティティから少なくとも1つの別のエンティティへ移転する意図を反映する。例示的な実施形態300では、前のトランザクション302は、ブロックチェーンに含まれる最も現在の確認済みトランザクションである。例示的な実施形態300では、アンロックトランザクション304は、未だ確認されていない且つ未だブロックチェーンに含まれていない中間的な将来のトランザクションである。アンロックトランザクション304のインプットの各々は、前のトランザクション302のアウトプットを受信する。
幾つかのブロックチェーン技術は、ビットコインと同様に、楕円曲線デジタル署名アルゴリズム(elliptic curve digital signature algorithm:ECDSA)をデジタル署名のための関数として使用する。実施形態では、ECDSAは、UTXOがそれ自体の正当な所有者へのみ移転されることを保証するために使用される暗号化デジタル署名である。ビットコインにおける楕円曲線デジタル署名(elliptic curve digital signature:ECDS)は、標準的に、末尾に付加される署名ハッシュフラグ(SIGHASH type)と共に現れる。しかしながら、本開示の技術は、SIGHASH typeを実装しないブロックチェーン技術と共に使用可能であることが想定される。このようなブロックチェーン技術では、ECDSは、特定のブロックチェーン技術の署名生成原理に準拠することが想定される。
実施形態では、SIGHASH typeは、連続化され(serialized)(例えば正規化され(canonicalized))及びハッシュされる前に、トランザクションから抽出されるべきフィールドセットを表す。例えば、SIGHASH typeは、トランザクションのどのフィールドが署名に含まれるかに影響を与え得る。幾つかの例では、SIGHASH typeは、SIGHASH_ALL、SIGHASH_NONE、SIGHASH_SINGLE、又はSIGHASH_ANYONECANPAYのうちの1つ以上であり得る。一実施形態では、タイプSIGHASH_ALLは、インプットスクリプトを除く、トランザクション内の全部のフィールドがハッシュされ署名されるべきであることを示す。一実施形態では、タイプSIGHASH_NONEは、アウトプットが署名される必要のないことを示す。これは、他者がトランザクションを更新することを可能し得る。一実施形態では、タイプSIGHASH_SINGLEは、インプットが署名されるが、シーケンス番号は空白であることを示す。したがって、他者はトランザクションの新しいバージョンを生成できるが、署名されたアウトプットだけがインプットとして同じ位置に存在する。一実施形態では、タイプSIGHASH_ANYONECANPAYは、他のタイプと組み合わせられ、SIGHASH_ANYONECANPAYを含むインプットが署名されること、しかし他のインプットは署名される必要のないことを示す。SIGHASH typeは、SIGHASH typeを示す値により表すことができる。例えば、幾つかの実装では、SIGHASH_ALLは1の値を有するバイトにより表され、SIGHASH_NONEは2の値を有するバイトにより表され(例えば、「00000010」)、SIGHASH_SINGLEは3の値を有するバイトにより表され(例えば、「00000011」)、SIGHASH_ANYONECANPAYは80の値を有するバイトにより表される(例えば、「01010000」)。SIGHASH typeを組み合わせることは、幾つかの実施形態では、バイト値を一緒に加算することにより実行される。
幾つかの例では、SIGHASH typeにより決定されるトランザクションフィールドセットは、SIGHASH typeにより決定されるような、バイトにエンコードされた対応するトランザクションのサブセットを表す。例えば、SIGHASH_ANYONECANPAYのSIGHASH typeにより、1つのトランザクションインプットのみが、署名に含まれる。
一実施形態では、ECDSは、識別符号化規則(distinguished encoding rules:DER)フォーマットでエンコードされた256ビット数値のペア(r,s)により表される。しかしながら、本開示の技術は、基本符号化規則(basic encoding rules:BER)又は標準符号化規則(canonical encoding rules:CER)のような他の符号化フォーマットと共に使用可能であることに留意する。ECDSAで使用されるパラメータは、K(座標(x,y)を有する楕円曲線点)、k(256ビット数値、通常、秘密鍵を保護するためにランダムである)、G(次数nを有する楕円曲線上の基点、n×G=0、ここで0はアイデンティティ楕円曲線点を表し、nは楕円曲線有限フィールド内のパラメータとして使用される大きな素数である)、r(ECDS内の256ビット数値のうちの一方である)、s(署名内の256ビット数値のうちの他方である)、k−1(kのモジュラ逆数、つまりklk=l mod n)、m(署名されているメッセージ/データ、実施形態では、これは、ハッシュ関数により256ビットにサイズ変更される)、a(秘密鍵、例えば256ビット数値)、を含む。実施形態では、ECDSは以下のように生成される。
先ず、kに生成元(generator)を乗じることにより、楕円曲線点Kが決定される:K=k×G。次に、Kから点xが決定され、ECDS内の256ビット数値の第1の数値rが、式r=x mod nに従い決定される。次に、ECDS内の256ビット数値の第2の数値sが、式s=kl(m+r×a) mod nに従い決定される。最後に、(r,s)がDERフォーマットにエンコードされる。署名(r,s)、メッセージ/データm、及び秘密鍵aに対応する公開鍵Aが与えられると、署名が検証できる。署名を検証するために、v=s−l×(m×G+r×y)が計算される。v=rならば、署名は有効である。
ビットコインは、「スクリプト(Script)」と呼ばれる記述システムを使用する。本開示では、種々のスクリプトオペコード及びキーワードが、種々の動作を実行するために参照される。しかしながら、他のブロックチェーン技術が異なる命令セットを実装し得ることが想定され、したがって本開示に記載のオペコードはScript内の特定オペコード以外のオペコードにより実行される動作の説明として考えられる。幾つかの実施形態では、記述システムは、チューリング(Turing)不完全命令セット(例えば、ループ、再帰、「goto」文、等をサポートしない)である。他の実施形態では、記述システムはチューリング完全命令セットである。
本開示の特定の実施形態は、記述システム又は記載の命令セットを実装する他のシステムが、ビットコインの特定の実装では違反限度である、単一スクリプト内に200個より多くの命令(例えば、オペコード)を可能にするという仮定の下で動作する。同様に、本開示の特定の実施形態は、本開示で参照されるオペコードにより提供される機能がオペコードスクリプト/命令セットを実行するシステム内に存在し可能にされることを更に仮定する。ビットコインの幾つかの実装では、これらのオペコードのうちの1つ以上は、デフォルトで無効にされ又は制限されてよい。
本開示で参照されるオペコードの例は、以下を含む:
OP_ECPX:楕円曲線点のx座標を返す。
OP_ADD:スタックにある上位2個のアイテムを加算する。
OP_BIGMOD:スタックにある上位2個のアイテムを除算した後の余りを返す。
OP_BIGMODADD:スタックの上位2個のアイテムのモジュロ和の、スタックの3番目のアイテムのモジュロを実行する。
OP_BIGMODINVERSE:負の指数演算のモジュロを実行する。
OP_BIGMODMUL:スタックの上位2個のアイテムのモジュロ積の、スタックの3番目のアイテムのモジュロを実行する。
OP_CAT:スタックにある上位2個のアイテムを連結する。
OP_CHECKSIG:公開鍵及び署名がスタックからポップされ、SIGHASH typeに従いトランザクションフィールドの署名に対して検証される。署名が有効ならば1が、その他の場合に0が返される。
OP_CHECKSIGVERIFY:OP_CHECKSIGと同じ機能だが、OP_VERIFYが後に実行される。
OP_DERENCODE:スタックにある上位2個のアイテムをDERフォーマットでエンコードする。
OP_DUP:1番上のスタックアイテムを複製する。
OP_ECPMULT:スタックにある上位2個のアイテムの楕円曲線乗算を実行する。
OP_ELSE:先行するOP_IF又はOP_NOTIF又はOP_ELSEが実行されない場合、これらのステートメントが実行され、その他の場合に、先行するOP_IF又はOP_NOTIF又はOP_ELSEが実行された場合、これらのステートメントは実行されない。
OP_ENDIF:if/elseブロックを終了する。
OP_EQUAL:入力が正確に等しい場合に1を、その他の場合に0を返す。
OP_EQUALVERIFY:OP_EQUALと同じだが、OP_VERIFYを後に実行する。
OP_FROMALTSTACK:インプットを主スタックの1番上に置き、代替スタックから除去する。
OP_HASH256:最初にSHA−256で、次にRIPEMD−160で、インプットが2回ハッシュされる。
OP_IF:1番上の値が偽でないならば、ステートメントが実行され、1番上の値が除去される。
OP_NOTIF:1番上の値が偽ならば、ステートメントが実行され、1番上の値が除去される。
OP_ROLL:スタック内でnアイテムの深さにあるアイテムが1番上に移動される。
OP_SUBSTR:文字列のセクションを返す。
OP_SWAP:スタックにある上位2個のアイテムがスワップされる。
OP_TOALTSTACK:インプットを代替スタックの1番上に置き、主スタックから除去する。
OP_VERIFY:一番上のスタック値が真でない場合、トランザクションを無効としてマークする。
一実施形態では、ECDS生成スクリプトはオペコードを用いて生成でき、末尾にSIGHASH typeを付加することにより、署名生成スクリプトOP_GENSIGを生成するよう拡張可能である。
[表1]
表1に示した上述のスクリプトでは、<SIGHASH Byte>、メッセージ<m>、秘密鍵<a>、及び数値<k>は、上述の順序で(例えば、4個のアイテムの挿入後に、数値<k>がスタックの1番上にあり、続いて秘密鍵<a>、続いてメッセージ<m>、最後に<SIGHASH Byte>が続く)主スタックに入力される(例えば、先出しの最後)。
スクリプト演算「OP_DUP OP_TOALTSTACK<PubKG> OP_ECPMULT」の実行は、数値<k>を代替スタックにコピーさせる。ここで<k>は楕円曲線生成器<PubK G>に対して乗算されて、主スタックの一番上にある楕円曲線点Kを生成する。
スクリプト演算「OP_ECPX <N> OP_BIGMOD OP_DUP OP_TOALTSTACK」の実行は、rをKのx座標 mod nから計算させる。rのコピーは代替スタックにプッシュされる。
スクリプト演算「<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>と連結させる。
本開示では、このスクリプトはOP_GENSIGと呼ばれる。したがって、本開示の実施形態におけるOP_GENSIGへの参照は、上述のスクリプトで実行される演算の短縮表現と考えられるべきである。
図4は、一実施形態により解決される、スクリプトに基づくブロックチェーン相互作用に関連付けられたブロックチェーンへのアクセスに伴う例示的な問題400を図形式で示す。例示的な問題である図4に示される400では、トランザクション402(例えば、図3に関連して記載した前のトランザクション302のような前のトランザクション又はアンロックトランザクション304)内のロックスクリプト406は、ブロックチェーン404にアクセスできない。
上述のように、幾つかの実施形態では、トランザクション402は、ブロックチェーンに含まれる最も現在(most current、最近)の確認済みトランザクションである。同様に、幾つかの実施形態では、トランザクション402は、未だ確認されていない、未だブロックチェーンに含まれていない、前のトランザクションにより制御されるデジタルアセットの少なくとも一部の制御を移転しようとする試みを表す、将来のトランザクションである。
幾つかの実施形態では、ロックスクリプト406は、アウトプットを移転するために満たす必要のある条件を指定することにより、トランザクションを妨げるスクリプトである。特に、ロックスクリプト406の実行は、ブロックチェーンシステムの検証ノードによる実行の結果として、実行したアンロックスクリプトからのデータを受け付け、該データに基づき特定の演算を実行し、アンロックスクリプトの実行がロックスクリプトを成功裏に「アンロック(unlocked、解除)」したか(つまり、ロックスクリプト内で設定された条件セットを満たしたか)否かを示す結果を返す。幾つかの実施形態では、ロックスクリプト406は、トランザクションの検証が成功するために(例えば、アンロックスクリプトにより提供されたデータにより)満たされなければならない1つ以上のデータ制約を定める。例えば、ロックスクリプト406は、トランザクション402の関連するデジタルアセットをアンロックするために、アンロックスクリプト内で特定データが提供されることを要求し得る。
例示的な問題400に示したように、トランザクション402のロックスクリプト406は、ブロックチェーン404をクエリし、例えばブロック数を決定できない。トランザクション402のロックスクリプト406は、ブロックチェーン404の最初のブロック408(「genesisブロック」とも呼ばれる)、ブロックチェーン404の内部ブロックのいずれか(例えば、ブロック410)、又はブロックチェーン404の最後のブロック412を含む、ブロックチェーン404のブロックもクエリできない。本願明細書に記載の方法は、トランザクション402のロックスクリプト406が、ブロックチェーン404の最初のブロック408、内部ブロック(例えば、ブロック410)、又は最後のブロック412を含む、ブロックチェーン404のブロックをクエリすることを可能にする。
図5は、一実施形態により解決される、スクリプトに基づくブロックチェーン相互作用に関連付けられたブロックチェーン内のブロックへのアクセスに伴う例示的な問題500を図形式で示す。例示的な問題である図5に示される500では、トランザクション502(例えば、図3に関連して記載した前のトランザクション502のような前のトランザクション又は図3に関連して記載したアンロックトランザクション304のようなアンロックトランザクション)内のロックスクリプト506は、ブロック504(つまり、最初のブロック、内部ブロック、又は最後のブロック)のようなブロックチェーン内のブロックにアクセスできない。
上述のように、幾つかの実施形態では、トランザクション502は、ブロックチェーンに含まれる最も現在(most current、最近)の確認済みトランザクションである。同様に、幾つかの実施形態では、トランザクション502は、未だ確認されていない、未だブロックチェーンに含まれていない、前のトランザクションにより制御されるデジタルアセットの少なくとも一部の制御を移転しようとする試みを表す、将来のトランザクションである。
幾つかの実施形態では、本願明細書に記載のように、ロックスクリプト506は、アウトプットを移転するために満たす必要のある条件を指定することにより、トランザクションを妨げるスクリプトである。例示的な問題500に示したように、トランザクション502のロックスクリプト506は、ブロックチェーンのブロック504をクエリし、例えばブロック数を決定し、又は特定のトランザクションにアクセスできない。例示的な問題500に示したように、トランザクション502のロックスクリプト506は、ブロックチェーンのブロック504をクエリできず、ブロック504のブロックヘッダ508をクエリできず、及びブロック504のトランザクションをクエリできない。ブロック504がトランザクション502(ブロック504のトランザクション510のトランザクションTxi512として示される)を含む一実施形態では、トランザクション502のロックスクリプト506は、トランザクションTxi512にもクエリできない(例えば、ロックスクリプト506を含むトランザクションをクエリできない)。本願明細書に記載の方法は、トランザクション502のロックスクリプト506が、ブロックチェーンのブロック504にクエリし、ブロック504のブロックヘッダ508をクエリし、ブロック504のトランザクション510をクエリし、及びブロック504のトランザクション510のトランザクションTxi512をクエリすることを可能にする(例えば、ロックスクリプトが、ロックスクリプト506を含むトランザクションをクエリすることを可能にする)。
図6は、一実施形態による、データが、スクリプトに基づくブロックチェーン相互作用のためのブロックヘッダであることを検証される、例示的な環境600を図形式で示す。ブロックヘッダは、ブロックに関するデータを含む、ブロックチェーンのブロックの一部である。例えば、ブロックヘッダ602は、ブロックチェーン実装バージョン(「nVersion」)を格納する最初の4バイト、ブロックチェーンの前のブロックのハッシュを格納する次の32バイト(又は256ビット)(「HashPrevBlock」)、ブロックのトランザクションのマークル木のハッシュを格納する次の32バイト(「HashMerkleRoot」、これは本願明細書で詳述される)、ブロックの生成時間を格納する次の4バイト(「nTime」)、ブロックの32ビット採掘難易度値を格納する次の4バイト(「nBits」)、及びブロックのランダムシードを格納する最後の4バイト(「nNonce」)、を有する80バイトのデータである。
図から分かるように、ブロックヘッダ602が、ロックスクリプトへのインプットとして使用される(例えば、アンロックスクリプトとして提供される)データである場合、ブロックヘッダ602に対する制約をロックスクリプトへとエンコードすることにより、アンロックスクリプトデータは有効ブロックヘッダを含まなければならなず、そうでなければ有効なアンロックスクリプトではない。ブロックヘッダ602のようなブロックヘッダに対する3つの制約は、(i)80バイトの長さである、(ii)ブロックヘッダのnBitsが特定の採掘難易度値以上でなければならない、(iii)ブロックヘッダのdouble SHA256が採掘難易度値以下でなければならない、である。これらの制約の各々は別個のスクリプトとしてここに説明され、スクリプト同士のリンクの詳細(例えば、分岐制約及びスタックの維持)は説明を容易にするために省略される。
3つのスクリプトは、スクリプト同士のリンクの詳細が省略されて、一緒に結合されて単一のスクリプトを形成し、これは、アンロックスクリプト内の<Data>が有効ブロックヘッダであることを検証するOP_CHECKBLOCKVERIFYスクリプトの一例である。図示の例では、3つのスクリプトは真又は偽を返すが、単一のスクリプトに一緒にリンクされてOP_CHECKBLOCKVERIFYスクリプトを生成するとき、OP_VERIFYが標準的に各スクリプトの末尾に追加される。考えられるように、OP_CHECKBLOCKVERIFYスクリプトの他の実装が、実施されてよく、本開示の範囲内にあると考えられる。
ステップ604で、意図されるブロックヘッダはアンロックスクリプトとして提供され、<Data>として示される。
ステップ606で、<Data>のサイズが80バイトであること(例えば、第1制約)を検証する第1スクリプトが実行される。<Data>のサイズが80バイトであることを検証する第1スクリプトは、表2に示される。
[表2]
ステップ608で、ブロックヘッダの「nBits」フィールドがブロックヘッダ採掘難易度値以上であることを検証する第2スクリプトが実行される。ブロックヘッダの「nBits」フィールドがブロックヘッダ採掘難易度値以上であることを検証する第2スクリプトは、表3に示される。留意すべきことに、表3に示されるスクリプト内の採掘難易度値「<0x1D00FFFF>」は、ビットコイン仕様自体の最小採掘難易度である。一実施形態では、採掘難易度値は、アンロックスクリプトのデータアイテムとして提供される。一実施形態では、より大きな採掘難易度値(例えば、0x1D00FFFより大きな値)が目標採掘難易度として使用される。一実施形態では、より小さな採掘難易度値(例えば、0x1D00FFFより小さな値)が目標採掘難易度として使用される。
[表3]
ステップ610で、ブロックヘッダの(上述のオペコードOP_HASH256により実施される)double SHA256が示された採掘難易度値以下であることを検証する第3スクリプトが実行される。ブロックヘッダのdouble SHA256が示された採掘難易度値以下であることを検証する第3スクリプトは、表4に示される。表4に示される第3スクリプトは、以下の2つの追加オペコードを導入する。
OP_LBYTESHIFT:任意のサイズのデータに対して左バイトシフトを実行する。
OP_BIGLESSTHANOREQUAL:任意のサイズのデータを数値として解釈し、2つの数値を比較して第1数値が第2数値以下であるかどうかを決定する。
[表4]
図7は、一実施形態による、データが、スクリプトに基づくブロックチェーン相互作用におけるブロックヘッダであることを検証する例示的な処理700をフローチャート形式で示す。処理700の一部又は全部は、実行可能命令及び/又は他のデータにより構成された1つ以上のコンピュータシステムの制御下で実行可能であり、1つ以上のプロセッサで共同で実行する実行可能命令として実装可能である。実行可能命令及び/又は他のデータは、非一時的コンピュータ可読記憶媒体に格納可能である(例えば、磁気、光、又はフラッシュ媒体に永続的に格納されたコンピュータプログラム)。例示的な処理700は、図1と関連して説明したブロックチェーンネットワーク100のようなブロックチェーンネットワークの、図1と関連して説明したノード102のうちの1つのようなノードにより実行されてよい。つまり、図1と関連して記載したノード102のうちの1つのようなノードは、データが図7と関連して記載したスクリプトに基づくブロックチェーン相互作用におけるブロックヘッダであることを検証する例示的な処理700を実行してよい。このようなノードは、任意の適切なコンピューティング装置で(例えば、データセンタ内のサーバにより、クライアントコンピューティング装置により、コンピューティングリソースサービスプロバイダの分散システム内の複数のコンピューティング装置により、又は図2と関連して記載したコンピューティング装置200のような適切な電子クライアント装置により)構成されてよい。
例示的な処理700のステップ702で、システムは<Data>を受信する。例示的な処理700のステップ704で、システムは、図6と関連して上述したように、OP_CHECKBLOCKVERIFYスクリプトを開始する。例示的な処理700のステップ706で、システムは、例えば上述の表2に示したスクリプトを実行することにより、<Data>のサイズが80バイトであることを検証する。例示的な処理700のステップ708で、前のスクリプト(上述の表2に示したスクリプト)が合格したか(passed)否かが決定される。
例示的な処理700のステップ708で、前のスクリプトが合格しなかったと決定された場合、例示的な処理700のステップ718で、<Data>は有効ブロックヘッダではなく、ロックスクリプトの解除は失敗する。
例示的な処理700のステップ708で、前のスクリプトが合格したと決定された場合、例示的な処理700のステップ710で、システムは、例えば上述の表3に示したスクリプトを実行することにより、<Data>の「nBits」フィールドがブロックチェーン採掘難易度以上であることを検証する。例示的な処理700のステップ712で、前のスクリプト(例えば上述の表3に示したスクリプト)が合格したか否かが決定される。
例示的な処理700のステップ712で、前のスクリプトが合格しなかったと決定された場合、例示的な処理700のステップ718で、<Data>は有効ブロックヘッダではなく、ロックスクリプトの解除は失敗する。
例示的な処理700のステップ712で、前のスクリプトが合格したと決定された場合、例示的な処理700のステップ714で、システムは、例えば上述の表4に示したスクリプトを実行することにより、<Data>のSHA256が要求される目標以下であることを検証する。例示的な処理700のステップ716で、前のスクリプト(例えば上述の表4に示したスクリプト)が合格したか否かが決定される。
例示的な処理700のステップ716で、前のスクリプトが合格しなかったと決定された場合、例示的な処理700のステップ718で、<Data>は有効ブロックヘッダではなく、ロックスクリプトの解除は失敗する。
例示的な処理700のステップ716で、前のスクリプトが合格したと決定された場合、例示的な処理700のステップ720で、<Data>は有効ブロックヘッダではなく、ロックスクリプトの解除は成功する。
図7に示した例示的な処理700で実行される動作のうちの1つ以上は、並列を含む種々の順序及び組み合わせで実行されてよいことに留意する。
図8は、一実施形態による、データが、スクリプトに基づくブロックチェーン相互作用のための前のブロックのブロックヘッダであることを検証される、例示的な環境800を図形式で示す。本願明細書に記載のように、ブロックヘッダは、ブロックに関するデータを含む、ブロックチェーンのブロックの一部である。ブロックヘッダの一部は、前のブロックヘッダのハッシュ(「HashPrevBlock」)である。第1ブロックヘッダがロックスクリプトのインプットとして提供され(例えば、アンロックスクリプトの一部として提供され)、ブロックチェーン内の次のブロックのために意図された第2ブロックヘッダもロックスクリプトのインプットとして提供される(例えば、アンロックスクリプトの一部として提供される)場合、第1ブロックヘッダのハッシュが第2ブロックのHashPrevBlockであるという制約をロックスクリプト内にエンコードすることにより、第1ブロックヘッダのハッシュが第2ブロックのHashPrevBlockではないならば、2つのブロックヘッダは有効なアンロックスクリプトではない。
ステップ804で、第1ブロックヘッダ802は、アンロックスクリプトのためのデータ(<Data 1>として示される)として提供され、ステップ810で、以下に示すように、第2ブロックヘッダ808はアンロックスクリプトのためのデータ(<Data 2>として示される)として提供される。ステップ806で、図6及び7と関連して上述したOP_CHECKBLOCKVERIFYスクリプトのようなスクリプトは、<Data 1>がブロックヘッダであることを検証するために使用される。ステップ812で、図6及び7と関連して上述したOP_CHECKBLOCKVERIFYスクリプトのようなスクリプトは、<Data 2>がブロックヘッダであることを検証するために使用される。
ステップ814で、第1ブロックヘッダ<Data 1>のdouble SHA256が、第2ブロックヘッダ<Data 2>のHashPrevBlockと等しいことを検証するスクリプトが実行れる。第1ブロックヘッダ<Data 1>のdouble SHA256が、第2ブロックヘッダ<Data 2>のHashPrevBlockと等しいことを検証するスクリプトの一例は、表5に示される。表5に示すスクリプトは、<Data 1>が<Data 2>の有効な直前ブロックであることを検証するOP_CHECKCHAINVERIFYスクリプトの一例である。考えられるように、OP_CHECKCHAINVERIFYスクリプトの他の実装が、実施されてよく、本開示の範囲内にあると考えられる。留意すべきことに、表5に示すOP_CHECKCHAINVERIFYスクリプトの最終オペコードは、実行後に「真」値がスタックに残るべきなので、OP_EQUALである。OP_CHECKCHAINVERIFYスクリプトが他のスクリプトとの結合の中で使用される一実施形態では、スクリプトの最終OP_EQUALオペコードは、OP_EQUALVERIFYオペコードに変更される。
[表5]
図9は、一実施形態による、データが、スクリプトに基づくブロックチェーン相互作用における前のブロックのブロックヘッダであることを検証する例示的な処理900をフローチャート形式で示す。処理900の一部又は全部は、実行可能命令及び/又は他のデータにより構成された1つ以上のコンピュータシステムの制御下で実行可能であり、1つ以上のプロセッサで共同で実行する実行可能命令として実装可能である。実行可能命令及び/又は他のデータは、非一時的コンピュータ可読記憶媒体に格納可能である(例えば、磁気、光、又はフラッシュ媒体に永続的に格納されたコンピュータプログラム)。例示的な処理900は、図1と関連して説明したブロックチェーンネットワーク100のようなブロックチェーンネットワークの、図1と関連して説明したノード102のうちの1つのようなノードにより実行されてよい。つまり、図1と関連して記載したノード102のうちの1つのようなノードは、データが図9と関連して記載したスクリプトに基づくブロックチェーン相互作用における前のブロックのブロックヘッダであることを検証する例示的な処理900を実行してよい。このようなノードは、任意の適切なコンピューティング装置で(例えば、データセンタ内のサーバにより、クライアントコンピューティング装置により、コンピューティングリソースサービスプロバイダの分散システム内の複数のコンピューティング装置により、又は図2と関連して記載したコンピューティング装置200のような適切な電子クライアント装置により)構成されてよい。
例示的な処理900のステップ902で、システムは、2つの意図されたブロックヘッダである<Data 1>及び<Data 2>を受信する。例示的な処理900のステップ904で、システムは、図8と関連して上述したように、OP_CHECKCHAINVERIFY処理を<Data 1>及び<Data 2>に対して開始する。例示的な処理900のステップ906で、システムは、図6及び7と関連して上述したように、OP_CHECKCHAINVERIFYスクリプトを<Data 1>に対して実行することにより、<Data 1>がブロックヘッダであることを検証する。
例示的な処理900のステップ908で、前のスクリプト(例えば、<Data 1>に対するOP_CHECKBLOCKVERIFYスクリプト)が合格したか(つまり、OP_CHECKBLOCKVERIFYスクリプトが真を返したか)否かが決定される。例示的な処理900のステップ908で、前のスクリプトが合格しなかったと決定された場合、例示的な処理900のステップ910で、<Data 1>は<Data 2>の前のブロックではなく、したがってロックスクリプトの解除は失敗する。
例示的な処理900のステップ908で、前のスクリプトが合格したと決定された場合、例示的な処理900のステップ912で、システムは、図6及び7と関連して上述したように、OP_CHECKBLOCKVERIFYスクリプトを<Data 2>に対して実行することにより、<Data 2>がブロックヘッダであることを検証する。
例示的な処理900のステップ914で、前のスクリプト(例えば、<Data 2>に対するOP_CHECKBLOCKVERIFYスクリプト)が合格したか(つまり、OP_CHECKBLOCKVERIFYスクリプトが真を返したか)否かが決定される。例示的な処理900のステップ914で、前のスクリプトが合格しなかったと決定された場合、例示的な処理900のステップ916で、<Data 2>は有効なブロックヘッダではなく、例示的な処理900のステップ922で、<Data 1>は<Data 2>の前のブロックではなく、したがってロックスクリプトの解除は失敗する。
例示的な処理900のステップ914で、前のスクリプトが合格したと決定された場合、例示的な処理900のステップ918で、システムは、<Data 1>のdouble SHA256が<Data 2>の「HashPrevBlock」フィールドに等しいことを検証する。
例示的な処理900のステップ920で、<Data 1>のdouble SHA256が<Data 2>の「HashPrevBlock」フィールドに等しいか否かが決定される。例示的な処理900のステップ920で、<Data 1>のdouble SHA256が<Data 2>の「HashPrevBlock」フィールドに等しくないと決定された場合、例示的な処理900のステップ922で、<Data 1>は<Data 2>の前のブロックではなく、したがってロックスクリプトの解除は失敗する。
例示的な処理900のステップ920で、<Data 1>のdouble SHA256が<Data 2>の「HashPrevBlock」フィールドに等しいと決定された場合、例示的な処理900のステップ924で、<Data 1>は<Data 2>の前のブロックであり、したがってロックスクリプトの解除は成功する。
図9に示した例示的な処理900で実行される動作のうちの1つ以上は、並列を含む種々の順序及び組み合わせで実行されてよいことに留意する。
図10は、一実施形態による、データが、スクリプトに基づくブロックチェーン相互作用のためのブロックヘッダであることを検証される、例示的な環境1000を図形式で示す。図10に示す例示的な環境1000は、図8及び9と関連して記載した動作の拡張である。図10に示す例示的な環境1000では、ブロックヘッダチェーン1010(つまり、ブロックヘッダのチェーン)の第1ブロックヘッダ1002のdouble SHA256は、ブロックヘッダチェーン1010の第2ブロックヘッダ1004のHashPrevBlockと比較され、ロックヘッダチェーン1010の第2ブロックヘッダ1004のdouble SHA256は、ブロックヘッダチェーン1010の第3ブロックヘッダ1006のHashPrevBlockと比較され、ブロックヘッダチェーン1010の第2〜最後のブロック(図示しない)のdouble SHA256がブロックヘッダチェーン1010の最後のブロックヘッダ1008のHashPrevBlockと比較されるまで、同様である。
例示的な環境1000は、表5に示すスクリプトを各ブロックペアについて繰り返すことにより、表5に示すOP_CHECKCHAINVERIFYスクリプトが追加ブロックへと一般化できることを示す。このようなスクリプトは、本願明細書でOP_CHECKBLOCKCHAINVERIFYと呼ばれる。
一例として、OP_CHECKBLOCKCHAINVERIFYスクリプトは、ブロックヘッダチェーンの中のブロックヘッダ数、及びブロックヘッダチェーンのブロックヘッダをインプットパラメータとして取り入れ、OP_CHECKCHAINVERIFYを繰り返し実行してよい。表6は、スクリプトが、6個のブロックヘッダのチェーンを検証するためにどのように使用されるかの一例を示す。
[表6]
表7は、多数のブロックについてOP_CHECKCHAINVERIFYの動作を繰り返すOP_CHECKBLOCKCHAINVERIFYの実装の一例を示す。表7に示すOP_CHECKBLOCKCHAINVERIFYの例示的な実装では、繰り返される部分は、ブロックヘッダを通じて<d−1>個のループの値範囲(例えば、<d>個のブロックヘッダに対して<d−1>個のループ)をカバーし、順序を保存し及び維持するために、代替スタックを用いてブロックヘッダペアの各々に対してOP_CHECKCHAINVERIFY動作を実行する。
[表7]
図11は、一実施形態による、データが、スクリプトに基づくブロックチェーン相互作用におけるブロックヘッダチェーンであることを検証する例示的な処理1100をフローチャート形式で示す。処理1100の一部又は全部は、実行可能命令及び/又は他のデータにより構成された1つ以上のコンピュータシステムの制御下で実行可能であり、1つ以上のプロセッサで共同で実行する実行可能命令として実装可能である。実行可能命令及び/又は他のデータは、非一時的コンピュータ可読記憶媒体に格納可能である(例えば、磁気、光、又はフラッシュ媒体に永続的に格納されたコンピュータプログラム)。例示的な処理1100は、図1と関連して説明したブロックチェーンネットワーク100のようなブロックチェーンネットワークの、図1と関連して説明したノード102のうちの1つのようなノードにより実行されてよい。つまり、図1と関連して記載したノード102のうちの1つのようなノードは、データが図11と関連して記載したスクリプトに基づくブロックチェーン相互作用におけるブロックヘッダチェーンであることを検証する例示的な処理1100を実行してよい。このようなノードは、任意の適切なコンピューティング装置で(例えば、データセンタ内のサーバにより、クライアントコンピューティング装置により、コンピューティングリソースサービスプロバイダの分散システム内の複数のコンピューティング装置により、又は図2と関連して記載したコンピューティング装置200のような適切な電子クライアント装置により)構成されてよい。
例示的な処理1100のステップ1102で、システムは<Data 1>〜<Data n>の順序付きセットを受信する。例示的な処理1100のステップ1104で、システムは、図10と関連して上述したように、OP_CHECKBLOCKCHAINVERIFYスクリプトを順序付きデータセットに対して開始する。
例示的な処理1100のステップ1106で、システムは、順序付きデータセットの順序に少なくとも部分的に基づき、順序付きデータセットから第1データアイテム(例えば<Data 1>)を選択する。例示的な処理1100のステップ1108で、システムは、順序付きデータセットの順序に少なくとも部分的に基づき、順序付きデータセットから第2データアイテム(例えば<Data 2>)を選択する。一実施形態では、システムは、例えば図6及び7と関連して上述したOP_CHECKBLOCKVERIFYスクリプトを用いて、第1データアイテム及び第2データアイテムが有効なブロックヘッダであることを検証する。
例示的な処理1100のステップ1110で、システムは、図8及び9と関連して記載されるように、表5に示すように第1データアイテム及び第2データアイテムに対してOP_CHECKCHAINVERIFYを実行することにより、第1データアイテムが第2データアイテムの前のブロックであることを検証する。
例示的な処理1100のステップ1112で、第1データアイテム及び第2データアイテムに対するOP_CHECKCHAINVERIFYスクリプトが合格したか否か(つまり、第1データアイテムが第2データアイテムの中のブロックヘッダの前のブロックヘッダであるか否か)が決定される。
例示的な処理1100のステップ1112で、第1データアイテム及び第2データアイテムに対するOP_CHECKCHAINVERIFYスクリプトが合格しなかったと決定された場合、例示的な処理1100のステップ1114で、第1データアイテムは第2データアイテムの中のブロックヘッダの前のブロックヘッダではなく、例示的な処理1100のステップ1116で、順序付きデータセットは有効なブロックヘッダチェーンではない。
例示的な処理1100のステップ1112で、第1データアイテム及び第2データアイテムに対するOP_CHECKCHAINVERIFYスクリプトが合格したと決定された場合、例示的な処理1100のステップ1118で、順序付きデータセットの中に更にデータが存在するか否かが決定される。
例示的な処理1100のステップ1118で、順序付きデータセットの中に更にデータが存在すると決定された場合、例示的な処理1100のステップ1120で、第2データアイテムが例示的な処理1100において第1データアイテムになり、例示的な処理1100のステップ1122で、データ順序に少なくとも部分的に基づき、新しい第2データアイテムが順序付きデータセットから選択され、例示的な処理1100のステップ1110で、システムは、図8及び9と関連して記載した、表5に示されるような新しい第1データアイテム及び新しい第2データアイテムに対してOP_CHECKCHAINVERIFYを実行することにより、新しい第1データアイテムが新しい第2データアイテムの前のブロックであることを検証する。
例示的な処理1100のステップ1118で、順序付きデータセットの中に更にデータが存在しないと決定された場合、順序付きデータセットは有効なブロックヘッダチェーンである。
図11に示した例示的な処理1100で実行される動作のうちの1つ以上は、並列を含む種々の順序及び組み合わせで実行されてよいことに留意する。
図12は、一実施形態による、スクリプトに基づくブロックチェーン相互作用における、使用可能なブロックヘッダのマークル木を示す例示的な環境1200を図形式で示す。マークル木(「バイナリハッシュ木」とも呼ばれる)は、ブロック内のトランザクションのセットを検証するために使用されるデータ構造である。マークル木は、トランザクションの暗号ハッシュを含む二分木である。しかしながら、データのハッシュ及び連結を繰り返すことにより、マークル木は単一のハッシュ値(例えば、単一の32バイト又は256ビット値)として格納され得る。
例示的な環境1200で、マークル木1204は、(i)ブロックのトランザクションの各々のハッシュを計算し、(ii)ハッシュのペアを選択し、それらを一緒に連結し、(iii)連結値のハッシュを計算し、及び(iv)最終ハッシュ値(「マークルルート」)が生成されるまで、木の連続する上位レベルで処理を繰り返すことにより、生成される。このマークルルートは、次にブロックヘッダに「HashMerkleRoot」値として挿入される。
例えば、トランザクション1206から開始して、トランザクションのハッシュ1208が計算される。本願明細書で使用されるように、トランザクションはTAとして参照され、トランザクション1206のハッシュ1208はH(TA)として参照される。同様に、トランザクション(TB)はハッシュ1212H(TB)を有する。ハッシュ1216を生成するために、左の値は、ハッシュ1214される前に右の値と連結される。したがって、ハッシュ1216はH(H(TA)+H(TB))である。ここで、「+」演算子は、この場合、連結を表すためにオーバロードされる(overloaded)(例えば、H(TA)が「1234」であり且つH(TB)が「5678」である場合、H(TA)+H(TB)は「12345678」であり、H(H(TA)+H(TB))は「12345678」のハッシュである)。
例示的な環境1200は、マークル枝(Merkle branch)も示す。マークル枝は、マークルルートと結合された、マークル木の中のノードのセットであり、特定のリーフノード(つまり特定のトランザクション)のデータがマークル木の中にあることを検証するために使用できる。マークルルート及びマークル枝が与えられると、マークル木の中の所与のトランザクション(例えば、トランザクション1218)の存在は、以下のように検証できる。先ず、トランザクションのハッシュ1220が計算される。次に、マークル木の次のレベルのハッシュ1224が計算される。しかしながら、上述のように、マークル木の次のレベルのハッシュ1224は、他のトランザクション(例えば、マークル木の中のトランザクション1218の対の片方であるトランザクション)のハッシュ1222を必要とする。このハッシュ1222は、マークル枝の中の第1ノードである。
ハッシュ1224が与えられると、マークル木の次のレベルのハッシュ1226が計算される。この計算は、マークル木の他方のトランザクション(例えば、他の枝)のハッシュ1216を必要とする。このハッシュ1216は、マークル枝の中の第2ノードである。考えられるように、マークル木の各レベルで、マークル枝は、木の「他の」枝の中のトランザクションセットのハッシュを必要とする。したがって、ハッシュ1230の左の枝がトランザクション2118を含む枝であると仮定すると(上述のように計算できる)、ハッシュ1230を計算するために、マークル枝の中のもう一方のノードである右の枝のハッシュ1228が必要である。最後に、マークルルートを計算するために、マークル木の右側全体のハッシュ1232が必要である。トランザクション1218がマークル木1204の中にあることを検証するために使用可能なマークル枝は、ハッシュ1230、ハッシュ1228、ハッシュ1216、及びハッシュ1222である。木が深さ4を有するので、4個のノードがマークル枝の中にある。留意すべきことに、マークル木の深さは、ブロック内のトランザクションの数に依存し、トランザクション数のlog2である(つまり、512個のトランザクションでは、木は9の深さを有し、マークル枝はノードが9個のノードを有することを検証し、1024個のトランザクションでは、ツリーは10の深さを有し、マークル枝はノードが10個のノードを有することを検証し、2048個のトランザクションでは、木が11の深さを有し、マークル枝がノードが11個のノードを有することを検証し、以下同様である)。例えば、ビットコインブロックの中のブロック当たりの平均トランザクション数が約2000である場合、標準的なブロックは深さ11のマークル木を有する。
図13は、一実施形態による、トランザクションが、スクリプトに基づくブロックチェーン相互作用のためのブロックヘッダに含まれることを検証される、例示的な環境1300を図形式で示す。本願明細書に記載のように、ブロックヘッダは、ブロックに関するデータを含む、ブロックチェーンのブロックの一部である。ブロックヘッダの一部は、ブロック内のトランザクションを検証できない、マークル木のマークルルートである(「HashMerkleRoot」)。ブロックヘッダが、トランザクションのマークル枝及びトランザクションと一緒にロックスクリプトのインプットとして提供される(例えば、アンロックスクリプトとして提供される)場合、ブロックヘッダのHashMerkleRootが、マークル枝及びトランザクションから計算された計算されたマークルルートと同じであるという制約をエンコードすることにより、ブロックヘッダのHashMerkleRootが計算されたマークルルートと同じでないならば、ブロックヘッダ、マークル枝、及びトランザクションは有効なアンロックスクリプトではない。
ステップ1304で、第1ブロックヘッダ1302はアンロックスクリプトのためのデータ(<Data 1>と示される)として提供される。ステップ1306で、図6及び7と関連して上述したOP_CHECKBLOCKVERIFYスクリプトのようなスクリプトは、<Data 1>がブロックヘッダであることを検証するために使用される。ステップ1308で、HashMerkleRootは有効なブロックヘッダから抽出される。
ステップ1312で、マークル枝1310はアンロックスクリプトのためのデータ(<Data 2>と示される)として提供される。本願明細書で示されないが、約10、11、又は12であってよいマークル枝1310は、本願明細書に記載のように、特定ノードが連結動作への左のインプットであるか又は連結動作への右のインプットであるかを示す符号化形式で提供される。
表8は、OP_CALCMERKLEROOTの例示的な実装を示す。ここで、マークル枝1310は、ペア<hash
1>、<x
1>、<hash
2>、<x
2>、...、<hash
d>、<x
d>及び値<d>の集合を含む符号化形式で提供される。ここで、<d>はどれ位多くのペアがペアの集合の中にあるかを示し、各<hash
i>はマークル木からの値のハッシュであり、各<x
i>は左連結又は右連結かを示す値(例えば、0又は1)である。表8に示すOP_CALCMERKLEROOTの例示的な実装では、<x
i>内の1の値は左連結を示し、<x
i>内の0の値は右連結を示す。
[表8]
ステップ1316で、トランザクション1314はアンロックスクリプトのためのデータ(<Data 3>と示される)として提供される。ステップ1318で、マークルルートは、マークルルート<Data 2>及びトランザクション<Data 3>から、ここに示されないOP_CALCMERKLEROOTスクリプトを用いて計算される。
ステップ1320で、スクリプトは、<Data 1>から抽出したHashMerkleRootが<Data 2>及び<Data 3>に対して実行されたOP_CALCMERKLEROOTスクリプトからの計算されたマークルルートと同じであることを検証するために実行される。<Data 1>から抽出したHashMerkleRootが<Data 2>及び<Data 3>からの計算されたマークルルートと同じであることを検証するスクリプトの一例は、表9に示される。表9に示すスクリプトはブロックヘッダ<Data 1>のブロックが<Data 3>のトランザクションを含むことを<Data 2>のマークル枝を用いて検証するOP_CHECKBLOCKTXVERIFYスクリプトの一例である。考えられるように、OP_CHECKBLOCKTXVERIFYスクリプトの他の実装が、実施されてよく、本開示の範囲内にあると考えられる。表9に示すOP_CHECKBLOCKTXVERIFYスクリプトでは、OP_CHECKBLOCKVERIFY動作は説明を容易にするために省略される。
[表9]
図14は、一実施形態による、トランザクションが、スクリプトに基づくブロックチェーン相互作用におけるブロックヘッダに含まれることを検証する例示的な処理1400をフローチャート形式で示す。処理1400の一部又は全部は、実行可能命令及び/又は他のデータにより構成された1つ以上のコンピュータシステムの制御下で実行可能であり、1つ以上のプロセッサで共同で実行する実行可能命令として実装可能である。実行可能命令及び/又は他のデータは、非一時的コンピュータ可読記憶媒体に格納可能である(例えば、磁気、光、又はフラッシュ媒体に永続的に格納されたコンピュータプログラム)。例示的な処理1400は、図1と関連して説明したブロックチェーンネットワーク100のようなブロックチェーンネットワークの、図1と関連して説明したノード102のうちの1つのようなノードにより実行されてよい。つまり、図1と関連して記載したノード102のうちの1つのようなノードは、トランザクションが図14と関連して記載したスクリプトに基づくブロックチェーン相互作用におけるブロックヘッダに含まれることを検証する例示的な処理1400を実行してよい。このようなノードは、任意の適切なコンピューティング装置で(例えば、データセンタ内のサーバにより、クライアントコンピューティング装置により、コンピューティングリソースサービスプロバイダの分散システム内の複数のコンピューティング装置により、又は図2と関連して記載したコンピューティング装置200のような適切な電子クライアント装置により)構成されてよい。
例示的な処理1400のステップ1402で、システムは、図13と関連して上述したように<Data 1>、<Data 2>、及び<Data 3>を受信する。例示的な処理1400のステップ1402で、システムは、図13と関連して上述したように、OP_CHECKBLOCKTXVERIFYスクリプトの実行を<Data 1>、<Data 2>、及び<Data 3>に対して開始する。
例示的な処理1400のステップ1406で、システムは、図6及び7と関連して上述したように、OP_CHECKBLOCKVERIFYスクリプトを用いて、<Data 1>が有効なブロックヘッダであることを検証する。
例示的な処理1400のステップ1408で、<Data 1>に対するOP_CHECKBLOCKVERIFYスクリプトが合格したか否かが決定される。例示的な処理1400のステップ1408で、<Data 1>に対するOP_CHECKBLOCKVERIFYスクリプトが合格しなかったと決定された場合、例示的な処理1400のステップ1410で<Data 1>は有効なブロックヘッダではなく、例示的な処理1400のステップ1412で、<Data 3>のトランザクションは、<Data 1>内のブロックヘッダを有するブロック内にあると証明されない。
例示的な処理1400のステップ1408で、<Data 1>に対するOP_CHECKBLOCKVERIFYスクリプトが合格したと決定された場合、例示的な処理1400のステップ1414で、システムは、図13と関連して上述したように、<Data 1>からHashMerkleRootフィールドを抽出する。例示的な処理1400のステップ1416で、システムは、図13と関連して上述したように<Data 2>及び<Data 3>からマークルルートを計算する。
例示的な処理1400のステップ1418で、システムは、図13と関連して上述したように、<Data 1>から抽出したHashMerkleRootが<Data 2>及び<Data 3>から計算されたマークルルートと等しいことを検証する。
例示的な処理1400のステップ1420で、<Data 1>から抽出したHashMerkleRootが<Data 2>及び<Data 3>から計算されたマークルルートと等しいか否かが決定される。例示的な処理1400のステップ1420で、<Data 1>から抽出したHashMerkleRootが<Data 2>及び<Data 3>から計算されたマークルルートと等しくないと決定された場合、例示的な処理1400のステップ1412で、<Data 3>のトランザクションは<Data 1>内のブロックヘッダを有するブロックの中にあることが証明されない。
例示的な処理1400のステップ1420で、<Data 1>から抽出したHashMerkleRootが<Data 2>及び<Data 3>から計算されたマークルルートと等しいと決定された場合、例示的な処理1400のステップ1422で、<Data 3>のトランザクションは<Data 1>内のブロックヘッダを有するブロックの中にあることが証明される。
図14に示した例示的な処理1400で実行される動作のうちの1つ以上は、並列を含む種々の順序及び組み合わせで実行されてよいことに留意する。
図15は、一実施形態による、本願明細書に記載の方法を用いて、スクリプトに基づくブロックチェーン相互作用に関連付けられたブロックチェーンへのアクセスに伴う問題がどのように解決され得るかを示す例示的な環境1500を図形式で示す。例示的な環境1500では、トランザクション1502(例えば、図3に関連して記載した前のトランザクション302のような前のトランザクション又はアンロックトランザクション304)内のロックスクリプト1504は、図6〜14と関連して記載した方法のうちの1つ以上を用いてブロックチェーン1504にクエリできない。これは、図4と関連して記載した例示的な問題400と対照的である。同様に、例示的な環境1500では、トランザクション1502内のロックスクリプト1506は、図6〜14と関連して記載された方法のうちの1つ以上を用いてブロックチェーン1504のブロック1508にクエリできない。これは、図5と関連して記載した例示的な問題500と対照的である。一実施形態では、ブロック1508のトランザクション1510は、トランザクション1502と同じである(例えば、トランザクションTxiである)。
図16は、一実施形態による、スクリプトに基づくブロックチェーン相互作用に関連付けられたブロックチェーンの状態を示す例示的な環境1600を図形式で示す。ブロックチェーンは、ブロックチェーンが開始して以来の全てのブロックを含む。例示的な環境1600では、ブロックチェーン1602の第1ブロック1604のブロックヘッダは、最も小さいnTimeで(例えば、最も最近の又は時間において最初である)ブロックチェーン1602の状態1606のレコードである。本願明細書に記載の方法を用いて、トランザクションのロックスクリプトは、ブロックチェーン1602をクエリでき、第1ブロック1604をクエリでき、最も小さいnTimeにおけるブロックチェーン1602の状態1606をクエリできる。本願明細書に記載の方法を用いて、トランザクションのロックスクリプトは、ブロックチェーン1602をクエリでき、ブロックチェーン1602のブロック1608(トランザクションを含むブロックであってよい)をクエリでき、したがってブロックのnTimeにおけるブロックチェーン1602の状態1610をクエリできる。本願明細書に記載の方法を用いて、トランザクションのロックスクリプトは、ブロックチェーン1602をクエリでき、ブロックチェーン1602の最新ブロック1612をクエリでき、したがって最新ブロックのnTimeにおけるブロックチェーン1602の状態1614をクエリできる(例えば、ブロックチェーンの現在状態をクエリできる)。このような状態クエリの使用は図17及び18に詳述される。
図17は、一実施形態による、スクリプトに基づくブロックチェーン相互作用において、ブロックチェーンの状態が確認される、例示的な環境1700を図形式で示す。本願明細書に記載のように、ブロックヘッダは、ブロックに関するデータを含む、ブロックチェーンのブロックの一部である。ブロックヘッダの一部は、ブロック内のトランザクションを検証できない、マークル木のマークルルートである(「HashMerkleRoot」)。ブロックヘッダが、トランザクションのマークル枝及びトランザクションと一緒にロックスクリプトのインプットとして提供される(例えば、アンロックスクリプトとして提供される)場合、ブロックヘッダのHashMerkleRootが、マークル枝及びトランザクションから計算された計算されたマークルルートと同じであるという制約をエンコードすることにより、ブロックヘッダのHashMerkleRootが計算されたマークルルートと同じでないならば、ブロックヘッダ、マークル枝、及びトランザクションは有効なアンロックスクリプトではない。
一実施形態では、ブロックチェーンの状態のチェック及び/又はブロックチェーンの状態の確認は、ブロックチェーンの他の側面のチェックを含む。これは、限定ではないが、ブロックチェーンの1つ以上のブロックのブロックヘッダのチェック、ブロックチェーンの1つ以上のブロックの間の関係のチェック、ブロックチェーンのブロック数のチェック、ブロックチェーンの単一ブロック内の1つ以上のトランザクションのチェック、又はブロックチェーンの複数のブロック内の複数のトランザクションのチェックを含む。
ステップ1708で、ブロックヘッダ1706はアンロックスクリプトのためのデータ(<Data 1>と示される)として提供される。一実施形態では、図6及び7と関連して上述したOP_CHECKBLOCKVERIFYスクリプトのようなスクリプトは、<Data 1>がブロックヘッダであることを検証するために使用される。ステップ1712で、図13及び14と関連して上述したように、マークル枝1710はアンロックスクリプトのためのデータ(<Data 2>と示される)として提供される。ステップ1716で、トランザクション1714はアンロックスクリプトのためのデータ(<Data 3>と示される)として提供される。一実施形態で、マークルルートは、マークルルート<Data 2>及びトランザクション<Data 3>から、図13及び14と関連して上述したようなOP_CALCMERKLEROOTスクリプトを用いて計算される。
ステップ1718で、OP_CHECKBLOCKTXVERIFYスクリプトは、<Data 1>から抽出したHashMerkleRootが上述の表9に示したような<Data 2>及び<Data 3>に対して実行されたOP_CALCMERKLEROOTスクリプトからの計算されたマークルルートと同じであることを検証するために実行される。
理解されるべきことに、ステップ1718は、例示的な環境1700のような環境で実行可能であるスクリプトの種類の一例を示し、ここで、ブロックチェーンの状態は一実施形態によりスクリプトに基づくブロックチェーン相互作用の中で確認される。ステップ1718は、ブロックチェーンからのデータセットをオペコードを用いてトランザクションへ導入させる第1制約セットを示す。一実施形態では、OP_CHECKBLOCKVERIFYは、本願明細書に記載されるように、データセットがブロックヘッダを含むことを検証するために使用される。一実施形態では、OP_CHECKBLOCKTXVERIFY(つまり、ステップ1718に示される)は、データセットがトランザクションを含むこと、及びトランザクションがブロックヘッダに含まれることを検証するために使用される。考えられるように、本願明細書に記載される第1制約セットの中の制約の例は説明のための例であり、第1制約セットの他の種類の制約が本開示の範囲内として考えられてよい。第2制約セットは、以下にステップ1722に関して記載される。
例示的な環境1700では、ステップ1704で、スクリプトは、上述のOP_CHECKBLOCKCHAINVERIFYのような検証スクリプトを用いて、ブロックヘッダ<Data 1>が、パブリックブロックチェーンを模倣するために特別に生成されたブロックではなく、パブリックブロックチェーンの部分であるブロックのブロックヘッダであることを検証するために使用される。一実施形態では、スクリプトは、上述のように、ブロックヘッダ<Data 1>が、ブロックチェーン1702と共に又は完全な若しくは部分的ブロックヘッダチェーンと共に提供され得るパブリックブロックチェーンの部分であるブロックのブロックヘッダであることを検証するために使用される。
例示的な環境1700では、ステップ1722で、スクリプトは、トランザクションの他の側面を検証するために使用される。ステップ1720で、トランザクション1714は、ステップ1722におけるアンロックスクリプトのためのデータ(<Data 3>と示される)として提供される。留意すべきことに、幾つかの実施形態では、例えばステップ1718におけるOP_CHECKBLOCKTXVERIFYスクリプトが、ステップ1716におけるトランザクション<Data 3>を消費するとき、ステップ1720におけるトランザクション<Data 3>は、ステップ1716におけるトランザクション<Data 3>のコピーである。
上述のステップ1718と同様に、留意すべきことに、ステップ1722は例示的な環境1700のような環境で実行可能であるスクリプトの種類の一例を示し、ここで、ブロックチェーンの状態は一実施形態によりスクリプトに基づくブロックチェーン相互作用の中で確認される。ステップ1722は、ステップ1718と関連して上述したように、オペコードを用いてトランザクションに導入される、ブロックチェーンからのデータセットに関連付けられる第2制約セットを示す。一実施形態では、第2制約セットは、データセットのデータアイテムの値に関する制約を含む(つまり、データセットのデータアイテムが、例えば値より小さい、等しい、又は大きいという制約を含む)。一実施形態では、第2制約セットは、データから決定される制約を含む(例えば、ブロックヘッダに関連付けられたブロックの中のトランザクションの数が100より多い場合に、動作「A」を行う、その他の場合に動作「B」を行う、という制約)。考えられるように、本願明細書に記載される第2制約セットの中の制約の例は説明のための例であり、第2制約セットの他の種類の制約が本開示の範囲内として考えられてよい。
ステップ1704で、ブロックヘッダ<Data 1>が、パブリックブロックチェーンのブロックを模倣するために特別に生成されたブロックではなく、パブリックブロックチェーンの部分であるブロックのためのブロックヘッダであることを検証するために使用されるスクリプトが、合格した場合、ステップ1718で、OP_CHECKBLOCKTXVERIFYスクリプトは、<Data 1>から抽出したHashMerkleRootが、<Data 2>及び<Data 3>に対して実行されたOP_CALCMERKLEROOTスクリプトから計算したマークルルートと同じであることを検証し、ステップ1722で、トランザクションの他の側面を検証するために使用されるスクリプトが合格した場合、ステップ1724でロックスクリプトが成功する。一実施形態では、ステップ1704は、オペコードを用いてトランザクションに導入される、ブロックチェーンからのデータセットに関連付けられた第3制約セットを示す(例えば、ブロックがパブリックブロックチェーンのブロックであるという制約)。
留意すべきことに、上述のように、ステップ1722で、トランザクションの他の側面を検証するために使用されるスクリプトは、オペコードを用いてトランザクションに導入される、ブロックチェーンからのデータセットに関連付けられた第2制約セットを含む。このように、第2制約セットは、一実施形態では、限定ではないが、譲受人(transferee)、譲渡人(transferor)、トランザクションの量、又はトランザクションの他の側面、を含むトランザクションの多数の側面の検証を含む。さらに、留意すべきことに、ステップ1722で、トランザクションの他の側面を検証するために使用されるスクリプトは、ブロックチェーンの側面、ブロックヘッダチェーンの側面、ブロックの側面、又はブロックチェーン環境の他の側面を含んでよい。例えば、ステップ1722で、トランザクションの他の側面を検証するために使用され、第2制約セットの制約を含むスクリプトは、ブロックのnTimeを検証するための、ブロック内のトランザクションの数を検証するための、2つのブロック間の経過時間量を決定するための、最小ブロック高を決定するための、又はブロックチェーン環境の他のこのような側面を決定するための、制約を含み得る。また留意すべきことに、スクリプトの末尾に、ステップ1722のトランザクションの他の側面を検証するために使用される「検証(verify)」オペコードを含まないことにより、分岐条件が導入され得る(例えば、1000個より多くのトランザクションがブロック内にある場合、アリスは解除でき、1000個より多くのトランザクションがブロック内にない場合、ボブが解除できる)。分岐条件の例は、図30と関連して以下に詳述される。
ステップ1704に関連付けられる1つの問題、つまり、ブロックヘッダ<Data 1>が、パブリックブロックチェーンのブロックを模倣するために特別に生成されたブロックではなく、パブリックブロックチェーンの部分であるブロックのためのブロックヘッダであることを検証するために使用されるスクリプトが、幾つかの実施形態では、パブリックブロックチェーンのブロックを模倣するために特別にブロックを生成することが計算上極めて容易であり得ることである。例えば、ブロックヘッダに含むべきアンロックスクリプト内のデータを必要とする(例えば、アンロックスクリプトは単なるブロックヘッダ<Data 1>以上のものを含んでよい)、表10のロックスクリプトを検討する。
[表10]
ビットコイン実装では、採掘難易度(nBits)が最小値に設定される場合、データは、パブリックブロックチェーン内のブロックのブロックヘッダであり得るが、最小採掘難易度でブロックを生成するためには膨大な量の計算能力を必要としないので、完全に無関係なブロックでもあり得る。この実施を阻止するために、ロックスクリプト生成者は、ロックスクリプトに対する制約を充分に困難にするべきである。その結果、パブリックブロックチェーンを模倣する代替ブロックチェーンを生成するために必要な計算能力のコストが、解除可能なものの価値よりも有意に大きくなる。ビットコインでは、これは、(例えば、表3に示した、図6及び7と関連して記載したスクリプトにおける)採掘難易度を増大することにより、又は(例えば、表6に示した、図10及び11と関連して記載したスクリプトにおける)ブロックヘッダの長いチェーンを要求することにより、達成できる。
表11は、ステップ1724におけるようなトランザクションの他の側面を検証するために(つまり、第2制約セット及び/又は第1制約セットの側面が満たされるか否かを決定するために)使用されるスクリプトの一例を示す。表11に示したトランザクションの他の側面を検証するために使用される例示的なスクリプトでは、データ<Data 1>は、トランザクション<Data 3>を含むブロックヘッダであり、トランザクションがボブの公開鍵に支払われる、という制約を受ける。留意すべきことに、「<Scriptto Check Output of Data 3 is to P2KH of Bob>」は、説明の目的でここでは省略される。
[表11]
図18は、一実施形態による、スクリプトに基づくブロックチェーン相互作用において、ブロックチェーンの状態を確認する例示的な処理1800をフローチャート形式で示す。処理1800の一部又は全部は、実行可能命令及び/又は他のデータにより構成された1つ以上のコンピュータシステムの制御下で実行可能であり、1つ以上のプロセッサで共同で実行する実行可能命令として実装可能である。実行可能命令及び/又は他のデータは、非一時的コンピュータ可読記憶媒体に格納可能である(例えば、磁気、光、又はフラッシュ媒体に永続的に格納されたコンピュータプログラム)。例示的な処理1800は、図1と関連して説明したブロックチェーンネットワーク100のようなブロックチェーンネットワークの、図1と関連して説明したノード102のうちの1つのようなノードにより実行されてよい。つまり、図1と関連して記載したノード102のうちの1つのようなノードは、図18と関連して記載したスクリプトに基づくブロックチェーン相互作用におけるブロックチェーンの状態を確認する例示的な処理1800を実行してよい。このようなノードは、任意の適切なコンピューティング装置で(例えば、データセンタ内のサーバにより、クライアントコンピューティング装置により、コンピューティングリソースサービスプロバイダの分散システム内の複数のコンピューティング装置により、又は図2と関連して記載したコンピューティング装置200のような適切な電子クライアント装置により)構成されてよい。
例示的な処理1800のステップ1802で、システムは、図17と関連して上述したように<Data 1>、<Data 2>、及び<Data 3>を受信する。
例示的な処理1800のステップ1804で、図17と関連して上述したように、OP_CHECKBLOCKCHAINVERIFYを用いて、<Data 1>がパブリックブロックチェーンのブロックであることを検証する。上述のように、OP_CHECKBLOCKCHAINVERIFYは、データセットに対する制約(例えば、上述の第3制約セット)が満たされるか否かを決定するために使用可能なスクリプトの一例である。
例示的な処理1800のステップ1806で、<Data 1>がパブリックブロックチェーンのブロックであるか否かが決定される。例示的な処理1800のステップ1806で、<Data 1>がパブリックブロックチェーンのブロックではないと決定された場合、例示的な処理1800のステップ1808で、<Data 3>のトランザクションは、<Data 1>のブロックヘッダを有するブロックであることが証明されず、例示的な処理1800のステップ1810で、ロックスクリプトが失敗する。
例示的な処理1800のステップ1806で、<Data 1>がパブリックブロックチェーンのブロックであると決定された場合、例示的な処理1800のステップ1812で、システムは、表9に示した例のようなOP_CHECKBLOCKTXVERIFYスクリプトを用いて、<Data 3>のトランザクションが<Data 1>のブロックヘッダを有するブロックの中にあることを検証する。上述のように、OP_CHECKBLOCKTXVERIFYは、データセットに対する制約(例えば、上述の第1制約セット)が満たされるか否かを決定するために使用可能なスクリプトの一例である。一実施形態では、OP_CHECKBLOCKTXVERIFYは、データセットがトランザクションを含むことを検証するために、及びトランザクションがブロックヘッダにより識別されるブロックに含まれることを検証するために使用される。一実施形態では、OP_CHECKBLOCKVERIFYは、データセットがブロックヘッダを含むことを検証するために使用される。
例示的な処理1800のステップ1814で、OP_CHECKBLOCKTXVERIFYが合格したか否かが決定される。例示的な処理1800のステップ1814で、OP_CHECKBLOCKTXVERIFYが合格しなかった場合、例示的な処理1800のステップ1816で、<Data 3>のトランザクションは<Data 1>のブロックヘッダを有するブロックの中になく、例示的な処理1800のステップ1810で、ロックスクリプトは失敗する。
例示的な処理1800のステップ1814で、OP_CHECKBLOCKTXVERIFYが合格した場合、例示的な処理1800のステップ1818で、システムは、本願明細書に記載のようなトランザクションの1つ以上の他の側面を検証する(つまり、データセットに関連付けられた第2制約セットの制約が満たされることを検証する)。
例示的な処理1800のステップ1820で、トランザクションの1つ以上の他の側面が検証されるか否かが決定される。例示的な処理1800のステップ1820で、トランザクションの1つ以上の他の側面が検証されないと決定された場合、例示的な処理1800のステップ1810で、ロックスクリプトの解除が失敗する。
例示的な処理1800のステップ1820で、トランザクションの1つ以上の他の側面が検証されると決定された場合、例示的な処理1800のステップ1822で、ロックスクリプトの解除が成功する。
図18に示した例示的な処理1800で実行される動作のうちの1つ以上は、並列を含む種々の順序及び組み合わせで実行されてよいことに留意する。
図19は、一実施形態により解決される、スクリプトに基づくブロックチェーン相互作用におけるロックスクリプトに伴う例示的な問題1900を図形式で示す。例示的な問題、つまり図19に示した1900では、前のトランザクション1902の中のロックスクリプト1906は、アンロックトランザクション1904のフィールドを直接読み出せない。
上述のように、幾つかの実施形態では、前のトランザクション1902は、ブロックチェーンに含まれる最も現在(most current、最近)の確認済みトランザクションである。同様に、幾つかの実施形態では、アンロックトランザクション1904は、未だ確認されていない、未だブロックチェーンに含まれていない、前のトランザクション1902により制御されるデジタルアセットの少なくとも一部の制御を移転しようとする試みを表す、将来のトランザクションである。
ここで留意すべきことに、幾つかの実施形態では、ロックスクリプト1906は、アウトプットを移転するために満たす必要のある条件を指定することにより、トランザクションを妨げるスクリプトである。特に、ロックスクリプト1906の実行は、ブロックチェーンシステムの検証ノードによる実行の結果として、実行したアンロックスクリプトからのデータを受け付け、該データに基づき特定の演算を実行し、アンロックスクリプトの実行がロックスクリプトを成功裏に「アンロック(unlocked、解除)」したか(つまり、ロックスクリプト内で設定された条件セットを満たしたか)否かを示す結果を返す。幾つかの実施形態では、ロックスクリプト1906は、トランザクションの検証が成功するために(例えば、アンロックスクリプトにより提供されたデータにより)満たされなければならない1つ以上のデータ制約を定める。例えば、ロックスクリプト1906は、前のトランザクション1902の関連するデジタルアセットをアンロックするために、アンロックスクリプト内で特定データが提供されることを要求し得る。
図20は、一実施形態による、スクリプトに基づくブロックチェーン相互作用におけるアンロックスクリプトによるデータアクセスを示す例示的な環境2000を図形式で示す。図20は、一実施形態における、本開示の、前のトランザクション2002のアンロックスクリプト2006と異なる、アンロックスクリプト2008が、アンロックトランザクション2004のフィールド(例えば、SIGHASH typeに従い決定されたアンロックトランザクションフィールドのセット)へのアクセスを有することを示す例示的な環境2000を示す。幾つかの実施形態では、前のトランザクション2002は、図19の前のトランザクション1902と同様である。幾つかの実施形態では、アンロックトランザクション2004は、図19のアンロックトランザクション1904と同様である。幾つかの実施形態では、ロックスクリプト2006は、図19のロックスクリプト1906と同様である。
幾つかの実施形態では、アンロックスクリプト2008は、ロックスクリプトによりトランザクションのアウトプットに対して課される条件セットを満たすことを試みるトランザクションのインプットに対して課される実行可能スクリプトである。ロックスクリプトは「scriptSig」としても知られている。上述のように、アンロックスクリプト2008は、ロックスクリプトへのインプットとしてSIGHASH typeに従い決定されたアンロックトランザクションフィールドのセットを提供するよう設計され、それによりロックスクリプトのアンロックトランザクションのフィールドへのアクセスを与える。連続トランザクションの内容及び構成に関する更なる詳細は、以下の図21の説明において分かる。
図21は、一実施形態による、署名が、スクリプトに基づくブロックチェーン相互作用におけるトランザクションフィールドの連続セットから生成される、例示的な環境2100を図形式で示す。図21に示すように、連続トランザクション2110(つまり、特定フォーマットのバイトのシリーズで表されるトランザクション)は、トランザクションのフィールド値のセットを含む。署名者は、2112で、SIGHASH type及び数値kを選択する。数値kは、秘密鍵をマスクし/保護するために、標準的にランダム又は疑似乱数であり、したがって本開示では時折「マスク数値(mask number)」と呼ばれる。トランザクション2114の変更されたコピーは、(例えば、例示的な環境2100においては、SIGHASH_NONE+ANYONECANPAYである)指定されたSIGHASH typeに従い選択された連続トランザクション2110のフィールドのセットの一例である。署名者は、トランザクション2114の変更されたコピーをハッシュし(例えば、OP_HASH256を実行し)、結果としてメッセージm2116を生じる。署名者は、次に、SIGHASH type、メッセージm、署名者の秘密鍵(例えば、a)、及び数値kを用いて、図3と関連して上述した方法のように、署名を生成する。
表12は、標準的なアンロック及びアンロックスクリプトの一例を示す。これにより、アンロックスクリプト内で指定されたエンティティAの想定される署名が、OP_CHECKSIGオペコードを用いてエンティティAの公開鍵に対してチェックされる。
[表12]
したがって、図21の署名生成の理解により、表13は、例示的環境2100に示された手順の部分がアンロックスクリプト内へと移動された場合の、アンロック及びロックスクリプトの一例を示す。
[表13]
アンロックスクリプトは、表14に示されるように、アンロックスクリプト内のメッセージmを計算するステップを含むよう更に変更できる。
[表14]
しかしながら、SIGHASH type及びSIGHASH typeに従い決定したアンロックトランザクションフィールドのセットを除き、手順の他の動作は、表15に示されるようにロックスクリプトへと移動できる。
[表15]
したがって、ロックスクリプト内の「OP_HASH256 <a> <k> OP_GENSIG」の動作を移動することにより、アンロックスクリプトは、有効であるために、SIGHASH type及びSIGHASH typeに従い決定されるアンロックトランザクションフィールドのセットを含むようにされる。
このように、連続した前のトランザクションは、ロックスクリプト内に導入させられる。表16は、ロックスクリプト及びアンロックスクリプトが、例示的環境2100の各ステップの手順をどのように実行しトランザクションを検証するかを示す。
[表16]
しかしながら、SIGHASH type及びSIGHASH typeに従い決定されるアンロックトランザクションフィールドのセットを提供する任意のエンティティは、トランザクションアウトプットを受信できることに留意する。これは、本願明細書に記載の方法の有用な特徴になり得る。例えば、スマートコントラクトの一実装は、コントラクトがブロックチェーントランザクションとして実装されることを可能にし得る。これは、コントラクトの生成者及び/又は任意の他のパーティをコントラクトから解放し、これらのパーティに互いを信頼することを要求せずに、且つこれらのパーティにコントラクトを管理すること若しくは監視することを要求せずに、コントラクトが満たされることを保証する。一実装では、コントラクトとの幾つかの相互作用が要求される。一実装では、コントラクトは、コントラクトとの相互作用を伴わずに自動的に実行される。
上述のように、SIGHASH type及びSIGHASH typeに従い決定されるアンロックトランザクションフィールドのセットを提供する任意のエンティティは、トランザクションアウトプットを受信できるので、スマートコントラクトは、自動的に(又は部分的に自動的に)実行され得る。一実施形態では、この特性は、アンロックトランザクションに対して追加制約を課すことにより制限できる。その結果、SIGHASH type及びSIGHASH typeに従い決定されるアンロックトランザクションフィールドのセットを提供する幾つかのエンティティだけが、トランザクションアウトプットを受信できる。さらに、SIGHASH type及びSIGHASH typeに従い決定されるアンロックトランザクションフィールドのセットを提供するエンティティは、特定方法でトランザクションアウトプットを取得できるだけであるように、スマートコントラクトが符号化されてよい。
一実施形態では、スマートコントラクトは、他のコンピュータシステムにトランザクションを検証させるためにコンピュータシステムにより検出可能な信号として機能する値を含む。つまり、デジタルアセットの少なくとも一部、スマートコントラクトに関連付けられたトランザクションの検証を実行すると取得可能な条件(contingent)を提供することにより、検証エンティティはトランザクションを検証するよう誘導される。例えば、1.0のデジタルアセットに関連付けられたスマートコントラクトが生成され、0.9のデジタルアセットが指名された受信者へ渡り、残りの0.1のデジタルアセットが検証エンティティにより請求可能にする。このように、スマートコントラクトが実行される。考えられるように、トランザクションアウトプットを取得するために及び/又はスマートコントラクトを実行するためにエンティティに影響する他の方法が、本開示の範囲内にあると考えられる。
本願明細書で使用されるように、スマートコントラクトは、自動実行特性及び自己施行特性の両方を有する。スマートコントラクトの自動実行特性は、2つの要素の結合である。スマートコントラクトの自動実行特性の第1要素は、任意のエンティティがロックスクリプトを有効に解除できることである。任意のエンティティがロックスクリプトを有効に解除できるとき、任意のエンティティは、UTXO及び/又はロックスクリプトを参照する有効なアンロックトランザクションを生成できる。これは、エンティティが何らかの秘密(例えば、秘密鍵、又は特定のハッシュを生成する値)の知識を有することを証明するようエンティティに要求する制約がないからである。しかしながら、留意すべきことに、スマートコントラクトの自動実行特性のこの第1要素は、本願明細書に記載のように制限される。スマートコントラクトの自動実行特性の第2要素は、(例えば、本願明細書に記載のようにビットコイン報酬により)ロックスクリプトを解除するよう他のパーティを動機づけし得るという点で、スマートコントラクトが自動であることである。スマートコントラクトの自己施行特性も、2つの要素の結合である。スマートコントラクトの自己施行特性の第1要素は、アンロックトランザクションフィールドの連続セットに対して制約が課されてよく、次にこれらの制約がアンロックトランザクション内に反映されることである。スマートコントラクトの自己施行特性の第2要素は、ロックスクリプト内の制約がブロックチェーンネットワークにより施行されることである。
図22は、一実施形態による、署名が、スクリプトに基づくブロックチェーン相互作用におけるアンロックトランザクションの連続セットの導入を生じる、例示的な処理2200をフローチャート形式で示す。例示的な処理2200の一部又は全部は、実行可能命令及び/又は他のデータにより構成された1つ以上のコンピュータシステムの制御下で実行可能であり、1つ以上のプロセッサで共同で実行する実行可能命令として実装可能である。実行可能命令及び/又は他のデータは、非一時的コンピュータ可読記憶媒体に格納可能である(例えば、磁気、光、又はフラッシュ媒体に永続的に格納されたコンピュータプログラム)。例示的な処理2200は、図1と関連して説明したブロックチェーンネットワーク100のようなブロックチェーンネットワークの、図1と関連して説明したノード102のうちの1つのようなノードにより実行されてよい。つまり、図1と関連して記載したノード102のうちの1つのようなノードは、アンロックトランザクションフィールドの連続セットを、図22と関連して記載したスクリプトに基づくブロックチェーン相互作用に導入させる例示的な処理2200を実行してよい。このようなノードは、任意の適切なコンピューティング装置で(例えば、データセンタ内のサーバにより、クライアントコンピューティング装置により、コンピューティングリソースサービスプロバイダの分散システム内の複数のコンピューティング装置により、又は図2と関連して記載したコンピューティング装置200のような適切な電子クライアント装置により)構成されてよい。
例示的な処理2200は、一連の動作を含む。ここで、例示的な処理2200を実行するシステムは、図21に記載した方法と関連して未検証トランザクションのアンロックスクリプト及びロックスクリプトを実行し、結果としてSIGHASH typeとトランザクションフィールド値のセットとを取得し、署名を生成し、署名を検証する。
例示的な処理2200のステップ2202で、システムは、未検証トランザクションを、デジタルアセットの制御の移転を求めているエンティティから取得する。未検証トランザクションは、ロックスクリプト及びアンロックスクリプトを含む。アンロックスクリプトは、ロックスクリプトを実行する前に、システムにより実行される。アンロックスクリプトは、上述の表15及び16に示したアンロックスクリプトと同様であってよく、SIGHASH type及び未検証トランザクションのフィールドの連続セットを示す。例示的な処理2200のステップ2204で、例示的な処理2200を実行するシステムは、示されたSIGHASH typeを取得し、例示的な処理2200のステップ2206で、未検証トランザクションのトランザクションフィールド値の連続セットを取得する。一実施形態では、アンロックスクリプトの実行が成功裏に完了すると、システムは、アンロックスクリプトの実行が完了したときの主スタックの状態(幾つかの実装では、代替スタックの状態)を用いてロックスクリプトの実行を開始する。ロックスクリプトは、上述の表15及び16に示したロックスクリプトと同様であってよい。
例示的な処理2200のステップ2208で、ロックスクリプトに従い、システムは、少なくともSIGHASH type及びアンロックスクリプトの実行結果として主スタックに置かれたトランザクションフィールド値のセット、並びに公開秘密鍵ペアに関連付けられた秘密鍵を用いて、署名を生成する。例示的な処理2200のステップ2210で、ロックスクリプトに従い、システムは、鍵ペアの公開鍵に対する署名の検証に成功する。このように、トランザクションフィールドのセットは、アンロックスクリプトによりロックスクリプト内に導入させられる。
図22に示した例示的な処理2200で実行される動作のうちの1つ以上は、並列を含む種々の順序及び組み合わせで実行されてよいことに留意する。
図23は、一実施形態により解決される、スクリプトに基づくブロックチェーン相互作用におけるロックスクリプトに伴う例示的な問題2300を図形式で示す。図23に示した例示的な問題2300では、ロックスクリプト2306は、前のトランザクションのフィールドに埋め込まれたトランザクションのインプットを読み出すことができず、結果として該フィールドを直接読み出せない。
幾つかの実施形態では、トランザクション2304は、前のトランザクションにより制御されるデジタルアセットの少なくとも一部の制御を移転しようとする試みを表す、本願明細書に記載のアンロックトランザクションと同様である。上述のように、幾つかの実施形態では、ロックスクリプト2306は、本願明細書に記載のロックスクリプトと同様に、アウトプットを移転するために満たす必要のある条件を指定することにより、トランザクションを妨げるスクリプトである。
図24は、一実施形態による、スクリプトに基づくブロックチェーン相互作用において、前の連続トランザクションの導入が引き起こされる、例示的な環境2400を図形式で示す。図24に示した例示的な環境2400は、前のトランザクション2402A〜02Bからのアウトプットを利用するアンロックスクリプト2408を有するアンロックトランザクション2404を示す。図から分かるように、アンロックスクリプトは、連続する前のトランザクションを読み出させる。幾つかの例では、連続する前のトランザクションは、前のトランザクションのフィールド値のセットの未変更バージョンを表す。
図24に示す実施形態は、トランザクションIDが連続トランザクションのdouble SHA256であること、及びトランザクションIDがトランザクションとの1対1マッピングを有すること、に気付くことにより理解できる。したがって、トランザクションは、表17に示す制約を適用することにより、アンロックスクリプトに導入可能である。
[表17]
本開示の実施形態は、任意の連続トランザクションの導入によるだけでなく、アンロックトランザクション2404のインプットにおいて参照される1つ以上の連続する前のトランザクション(例えば、前のトランザクション2404A〜02B)の導入により、この導入により更に向上する。図21を参照して上述したように、SIGHASH typeに従い決定されたアンロックトランザクションフィールドのセットは、アンロックスクリプト2406を介してロックスクリプトへと導入可能である。図25は、どのフィールドがSIGHASH typeに依存して連続トランザクションに含まれるかを示す。
図25は、一実施形態による、フィールドセットが、スクリプトに基づくブロックチェーン相互作用における署名ハッシュ種類に依存して利用可能にされる、例示的な環境2500を図形式で示す。しかしながら、図25は、説明を意図しており、種々の実施形態において、図25に示したものより多くのSIGHASH typeが存在することに留意する。図25に示すように、異なるSIGHASH typeにより、前のトランザクションIDの異なるセットが、SIGHASH typeに従い決定されたアンロックトランザクションフィールドのセットに含まれる(「ハッシュ(hash)」フィールドはトランザクションIDをビッグエンディアン形式で表すことに留意する)。幾つかの実施形態では、ロックスクリプトを埋め込む前のトランザクションのトランザクションIDは、どのSIGHASH typeが指定されるかに拘わらず、常に利用可能である。
したがって、特定フィールドが、以下の方法でSIGHASH typeを制約することにより、決定されたアンロックトランザクションフィールドのセットの中に存在するようにできる。先ず、SIGHASH typeを複製する。次に、SIGHASH typeをスタックにプッシュする(例えばSIGHASH_ALL)。最後に、OP_EQUALVERIFYを呼び出す。図25で分かるように、SIGHASH_ALL(アンロックトランザクション2504Aと共に示される)は、前のトランザクション「y」及び「z」の、上述のようにトランザクションIDを表すハッシュを含む。対照的に、SIGHASH_ALL+ANYONECANPAY(アンロックトランザクション2504Bと共に示される)は、直前のトランザクション「y」のハッシュのみを含む。幾つかの実施形態では、アンロックトランザクション2504A〜04Bは、前のトランザクション(例えば、トランザクションy及び/又はx)により制御されるデジタルアセットの少なくとも一部の制御を移転しようとする試みを表す、図19のアンロックトランザクション1904と同様である。トランザクションIDの抽出は、図26に示される、所望のフィールドに到達するまで、サブストリングオペコードを用いて連続トランザクションをパースすることにより達成できる。
図26は、一実施形態による、トランザクション識別子が、スクリプトに基づくブロックチェーン相互作用における連続トランザクションから抽出される、例示的な環境2600を図形式で示す。図26に示される例示的な環境2600では、ビッグエンディアン形式のトランザクションIDを含むハッシュ2620は、スクリプト内のサブストリングオペコードを用いて抽出できる連続トランザクション2610のサブストリングである。幾つかの実施形態では、幾つかのフィールド(例えば、#vin、scriptSigLen、scriptSig、scriptPubKeyLen、及びscriptPubKey)が可変バイト長であるので、連続トランザクション1020は、トランザクションIDが抽出可能になる前に、先ず、ハッシュ2620の位置を特定するためにパースされる。しかしながら、フィールドが固定長を有する実装では、パースは必要なくてよいと考えられる。
したがって、幾つかの実施形態では、図22を参照して記載した方法でアンロックトランザクションで参照される特定の連続した前のトランザクションの導入を強制するロックスクリプトを構築することにより、前のトランザクションIDがアクセス可能にされ得る。例えば、先ず、SIGHASH type制約が決定され、トランザクションIDが抽出され、そして連続する前のトランザクションが複製され及び(SIGHASH typeに従い)アンロックトランザクションの連続フィールドセットから抽出されたトランザクションIDに対してチェックされる。この処理は、複数の異なる連続する前のトランザクションの導入を強制するために実行され得ることに留意する。一例として、表18は、トランザクションXのインプットに対応する前のトランザクションの導入を生じるスクリプトを表す。表18に示すスクリプトは、OP_PREVTXINJECTIONスクリプトの一例であり、アンロックトランザクションのインプットXに対応する前のトランザクションの導入を生じる。
[表18]
しかしながら、SIGHASH type及びSIGHASH typeに従い決定されるアンロックトランザクションフィールドのセット、及び連続する前のトランザクションを提供する任意のエンティティは、本願明細書に記載のようにトランザクションアウトプットを取得できることに留意する。
別の例として、表19は、署名されているインプットに対応する前のトランザクションの導入を生じるスクリプトを表す。表19に示すスクリプトは、OP_SELFTXINJECTIONスクリプトの一例であり、署名されているインプットに対応する前のトランザクションの導入を生じる。
[表19]
SIGHASH type及びSIGHASH typeに従い決定されるアンロックトランザクションフィールドのセット、及び連続する前のトランザクションを提供する任意のエンティティは、本願明細書に記載のようにトランザクションアウトプットを受信できることに留意する。
図27は、一実施形態による、スクリプトに基づくブロックチェーン相互作用における前の連続トランザクションの導入を生じる、例示的な処理2700をフローチャート形式で示す。処理2700の一部又は全部は、実行可能命令及び/又は他のデータにより構成された1つ以上のコンピュータシステムの制御下で実行可能であり、1つ以上のプロセッサで共同で実行する実行可能命令として実装可能である。実行可能命令及び/又は他のデータは、非一時的コンピュータ可読記憶媒体に格納可能である(例えば、磁気、光、又はフラッシュ媒体に永続的に格納されたコンピュータプログラム)。例示的な処理2700は、図1と関連して説明したブロックチェーンネットワーク100のようなブロックチェーンネットワークの、図1と関連して説明したノード102のうちの1つのようなノードにより実行されてよい。つまり、図1と関連して記載したノード102のうちの1つのようなノードは、前の連続トランザクションを、図27と関連して記載したスクリプトに基づくブロックチェーン相互作用に導入させる例示的な処理2700を実行してよい。このようなノードは、任意の適切なコンピューティング装置で(例えば、データセンタ内のサーバにより、クライアントコンピューティング装置により、コンピューティングリソースサービスプロバイダの分散システム内の複数のコンピューティング装置により、又は図2と関連して記載したコンピューティング装置200のような適切な電子クライアント装置により)構成されてよい。
例示的な処理2700は、一連の動作を含む。ここで、例示的な処理2700を実行するシステムは、未検証トランザクションのアンロックスクリプト及びロックスクリプトを共に実行し、結果として、未検証トランザクションから抽出したトランザクションIDに対応する連続した前のトランザクションを取得する。
例示的な処理2700のステップ2702で、システムは、未検証トランザクションを、デジタルアセットの制御の移転を求めているエンティティから取得する。未検証トランザクションは、ロックスクリプト及びアンロックスクリプトを含む。ロックスクリプト及びアンロックスクリプトは、表18及び19に示したロックスクリプト及びアンロックスクリプトと同様であってよい。つまり、ロックスクリプトは、例えばアンロックスクリプトにより主スタック及び代替スタックに格納された値を入力として取り入れる命令セットを含む。命令セットの実行は、真と評価された場合、未検証トランザクションの検証に成功する。したがって、アンロックスクリプトは、ロックスクリプトの前に実行され、ロックスクリプトにより使用されるために、主スタック及び代替スタック内に値を設定する。図27の実施形態における未検証トランザクションのアンロックスクリプトは、連続する前のトランザクション、SIGHASH type、及びアンロックトランザクションフィールドの連続セットを示す。
後にロックスクリプトの続くアンロックスクリプトの実行の結果として、例示的な処理2700のステップ2704で、システムは、連続する前のトランザクション、SIGHASH type、及びアンロックスクリプト内で指定されたアンロックトランザクションフィールドの連続セットを取得する。例示的な処理2700のステップ2706で、システムは、SIGHASHに基づき、未検証トランザクションのフィールド値の連続セットの署名を生成する。SIGHASH typeはどのフィールドが署名生成で使用されるかに影響を与え、所望のSIGHASHは求められた特定の前のトランザクションに依存してよいことに留意する。例えば、表18は、必ずしも同じロックスクリプトを含む前のトランザクションである必要のない前のトランザクションを抽出するロックスクリプト及びアンロックスクリプトを示し、SIGHASH_ALLのSIGHASH typeを利用する。図25に示すように、SIGHASH_ALLタイプは、アンロックトランザクションの他の前のトランザクションのインプットの読み出しを可能にする。対照的に、表19は、同じロックスクリプトを有する前のトランザクションを抽出するロックスクリプト及びアンロックスクリプトを示し、SIGHASH_ALL|ANYONECANPAYのSIGHASH typeを利用する。図25に示すように、SIGHASH_ALL|ANYONECANPAYのSIGHASH typeは、署名されているインプットを有する前のトランザクション以外の、他の前のトランザクションのインプットを除去する。
例示的な処理2700のステップ2708で、システムは前に生成された署名を検証する。例示的な処理2700のステップ2710で、システムは、取得した連続した前のトランザクションのdouble SHA256を実行することにより、アンロックトランザクションのトランザクションIDと一致すべき値(つまり、フィールド値の連続セット)を生成する。サブストリングオペコードを用いて、例示的な処理2700のステップ2712で、システムは、フィールド値の連続セットのトランザクションIDを抽出し、例示的な処理2700のステップ2714で、システムは、連続する前のトランザクションのdouble SHA256により生成されたトランザクションIDがフィールド値の連続セットのトランザクションIDと一致するか否かを決定する。種々の実施形態で、一致は必ずしも同等であることを要求しないことに留意する。例えば、2つの値は、それらが等しくないが数学的に等価である場合に、一致してよい。別の例として、2つの値は、それらが共通オブジェクト(例えば、値)に対応する、又は何らかの所定の方法で補完的である、及び/又はそれらが1つ以上の一致基準を満たす場合に、一致してよい。通常、一致するか否かを決定する任意の方法が使用されてよい。
図27に示した例示的な処理2700で実行される動作のうちの1つ以上は、並列を含む種々の順序及び組み合わせで実行されてよいことに留意する。
図28は、一実施形態による、スクリプトに基づくブロックチェーン相互作用のために、ブロックチェーンの状態が使用される、例示的な環境2800を図形式で示す。本願明細書に記載のように、ブロックヘッダは、ブロックに関するデータを含む、ブロックチェーンのブロックの一部である。
本願明細書に記載のように、ステップ2804で、ブロックヘッダ2802はアンロックスクリプトのためのデータ(<Data 1>と示される)として提供される。一実施形態では、図6及び7と関連して上述したOP_CHECKBLOCKVERIFYスクリプトのようなスクリプトは、<Data 1>がブロックヘッダであることを検証するために使用される。ステップ2808で、図13及び14と関連して上述したように、マークル枝2806はアンロックスクリプトのためのデータ(<Data 2>と示される)として提供される。ステップ2812で、トランザクション2810はアンロックスクリプトのためのデータ(<Data 3>と示される)として提供される。一実施形態で、マークルルートは、マークルルート<Data 2>及びトランザクション<Data 3>から、図13及び14と関連して上述したようなOP_CALCMERKLEROOTスクリプトを用いて計算される。
ステップ2814で、OP_CHECKBLOCKTXVERIFYスクリプトは、<Data 1>から抽出したHashMerkleRootが図13、14、及び17と関連して記載したように上述の表9に示したような<Data 2>及び<Data 3>に対して実行されたOP_CALCMERKLEROOTスクリプトからの計算されたマークルルートと同じであることを検証するために実行される。
ステップ2816で、OP_SELFTXINJECTIONスクリプトは、<Data 3>のトランザクションのアンロックスクリプトが、図26、27、及び28と関連した記載したように、表18及び19に示されるようなロックスクリプトを含む連続トランザクションを含むことを検証するために実行される。
ステップ2818で、ステップ2814のOP_CHECKBLOCKTXVERIFYスクリプト及びステップ2816のOP_SELFTXINJECTIONが成功した場合、上述のように、<Data 1>のブロックヘッダを有するブロックがトランザクション<Data 3>を含むこと、<Data 3>のアンロックスクリプトがロックスクリプトの連続トランザクションを含むこと、及びロックスクリプトがブロックチェーン状態にアクセスできること、が分かる。このようなロックスクリプトは、限定ではないが、時間(つまり、1つ以上のブロックヘッダのnTimeフィールドから)、疑似乱数(つまり、nNonce又はHashMerkleRootから、両者は疑似乱数の良好な発生源である)、又は他の情報、を含む情報へのアクセスを有してよく、これらの情報の一部又は全部はロックスクリプト内で使用されてよい。このような追加情報の例は、図30に示される例の中で説明される。
一実施形態では、スクリプトは、上述のOP_CHECKBLOCKCHAINVERIFYのような検証スクリプトを用いて、ブロックヘッダ<Data 1>が、パブリックブロックチェーンを模倣するために特別に生成されたブロックではなく、パブリックブロックチェーンの部分であるブロックのブロックヘッダであることを検証するために使用される。一実施形態では、スクリプトは、上述のように、ブロックヘッダ<Data 1>が、ブロックチェーンと共に又は完全な若しくは部分的ブロックヘッダチェーンと共に提供され得るパブリックブロックチェーンの部分であるブロックのブロックヘッダであることを検証するために使用される。
一実施形態では、スクリプトは、図17と関連して上述したように、トランザクションの他の側面及び/又はブロックチェーン状態を検証するためにも使用されてよい。上述のように、トランザクションの他の側面を検証するために使用されるスクリプトは、限定ではないが、譲受人、譲渡人、トランザクションの量、又はトランザクションの他の側面、を含むトランザクションの多数の側面の検証を含んでよい。さらに、留意すべきことに、トランザクションの他の側面を検証するために使用されるスクリプトは、ブロックチェーンの側面、ブロックチェーン状態の側面、ブロックヘッダチェーンの側面、ブロックの側面、又はブロックチェーン環境の他の側面を含んでよい。例えば、トランザクションの他の側面を検証するために使用されるスクリプトは、ブロックのnTime、ブロック内のトランザクションの数、2つのブロック間の経過時間の量、最小ブロック高、又はブロックチェーン環境の他の側面を検証してよい。また留意すべきことに、スクリプトの末尾に、トランザクションの他の側面を検証するために使用される「検証(verify)」オペコードを含まないことにより、分岐条件が導入され得る(例えば、1000個より多くのトランザクションがブロック内にある場合、アリスは解除でき、1000個より多くのトランザクションがブロック内にない場合、ボブが解除できる)。分岐条件の例は、図30と関連して以下に詳述される。
例示的な環境2800内に示されないが、一実施形態では、図17と関連して記載された、表11に示すスクリプトのようなトランザクションの他の側面を検証するための追加スクリプトは、図28に記載の例示的な環境2800の部分として実行されてよい。
図29は、一実施形態による、スクリプトに基づくブロックチェーン相互作用において、ブロックチェーンの状態を使用する例示的な処理2900をフローチャート形式で示す。処理2900の一部又は全部は、実行可能命令及び/又は他のデータにより構成された1つ以上のコンピュータシステムの制御下で実行可能であり、1つ以上のプロセッサで共同で実行する実行可能命令として実装可能である。実行可能命令及び/又は他のデータは、非一時的コンピュータ可読記憶媒体に格納可能である(例えば、磁気、光、又はフラッシュ媒体に永続的に格納されたコンピュータプログラム)。例示的な処理2900は、図1と関連して説明したブロックチェーンネットワーク100のようなブロックチェーンネットワークの、図1と関連して説明したノード102のうちの1つのようなノードにより実行されてよい。つまり、図1と関連して記載したノード102のうちの1つのようなノードは、図29と関連して記載したスクリプトに基づくブロックチェーン相互作用におけるブロックチェーンの状態を使用する例示的な処理2900を実行してよい。このようなノードは、任意の適切なコンピューティング装置で(例えば、データセンタ内のサーバにより、クライアントコンピューティング装置により、コンピューティングリソースサービスプロバイダの分散システム内の複数のコンピューティング装置により、又は図2と関連して記載したコンピューティング装置200のような適切な電子クライアント装置により)構成されてよい。
例示的な処理2900のステップ2902で、システムは、図17と関連して上述したように<Data 1>、<Data 2>、及び<Data 3>を受信する。
例示的な処理2900のステップ2904で、図17と関連して上述したように、OP_CHECKBLOCKCHAINVERIFYを用いて、<Data 1>がパブリックブロックチェーンのブロックであることを検証する。
例示的な処理2900のステップ2906で、<Data 1>がパブリックブロックチェーンのブロックであるか否かが決定される。例示的な処理2900のステップ2906で、<Data 1>がパブリックブロックチェーンのブロックではないと決定された場合、例示的な処理2900のステップ2908で、<Data 3>のトランザクションは、<Data 1>のブロックヘッダを有するブロックであることが証明されず、例示的な処理2900のステップ2910で、ロックスクリプトはブロックチェーン状態にアクセスできない。
例示的な処理2900のステップ2906で、<Data 1>がパブリックブロックチェーンのブロックであると決定された場合、例示的な処理2900のステップ2912で、システムは、表9に示した例のようなOP_CHECKBLOCKTXVERIFYスクリプトを用いて、<Data 3>のトランザクションが<Data 1>のブロックヘッダを有するブロックの中にあることを検証する。
例示的な処理2900のステップ2914で、OP_CHECKBLOCKTXVERIFYが合格したか否かが決定される。例示的な処理2900のステップ2914で、OP_CHECKBLOCKTXVERIFYが合格しなかった場合、例示的な処理2900のステップ2916で、<Data 3>のトランザクションは<Data 1>のブロックヘッダを有するブロックの中になく、例示的な処理2900のステップ2910で、ロックスクリプトはブロックチェーン状態にアクセスできない。
例示的な処理2900のステップ2914で、OP_CHECKBLOCKTXVERIFYが合格したと決定された場合、例示的な処理2900のステップ2918で、システムは、表19に示したスクリプトのようなOP_SELFTXINJECTIONスクリプトを用いて、<Data 3>のトランザクションがロックスクリプトの連続トランザクションを含むことを検証する。
例示的な処理2900のステップ2920で、<Data 3>内のトランザクションのアンロックスクリプトが、ロックスクリプトの連続トランザクションを含むか否かが決定される。例示的な処理2900のステップ2920で、<Data 3>内のトランザクションのアンロックスクリプトが、ロックスクリプトの連続トランザクションを含まないと決定された場合、例示的な処理2900のステップ2910で、ロックスクリプトはブロックチェーン状態にアクセスできない。
例示的な処理2900のステップ2920で、<Data 3>内のトランザクションのアンロックスクリプトが、ロックスクリプトの連続トランザクションを含むと決定された場合、例示的な処理2900のステップ2922で、ロックスクリプトはブロックチェーン状態にアクセスできる。
図29に示した例示的な処理2900で実行される動作のうちの1つ以上は、並列を含む種々の順序及び組み合わせで実行されてよいことに留意する。
図30は、一実施形態による、スクリプトに基づくブロックチェーン相互作用において、ブロックチェーンの状態を使用する例示的な実装3000を図形式で示す。例示的な実装3000は、本願明細書に記載の方法の幾つかの態様を説明する。例示的な実装3000では、彼らのベット(bet、掛け金)を含むトランザクションのブロックと直前のブロックとの間の時間差に基づき、彼らのベットを含むトランザクションのブロックがパブリックブロックチェーンに追加されるのに、どれ位の時間を要するかについて、彼らはベットを生成したいと決定する。それぞれが単一のビットコインを提出し、時間差が10分より少ない場合には、2つのビットコインがアリスに渡る。逆に言えば、時間差が10分より少なくない場合、2つのビットコインはボブに渡る。
アリスは、ベットトランザクション3002の彼女の半分をビットコイン3004により出資する。ボブは、ベットトランザクション3002の彼の半分をビットコイン3006により出資する。ベットトランザクション3002は、時間差(t2−t1)が10分より少ない場合にはアリスが2つのビットコイン3008を得ることを記述する。逆に言えば、時間差(t2−t1)が10分より少なくない場合、ボブが2つのビットコインを得る。
本願明細書に記載の方法を用いて、ベットトランザクション3002が、ブロックヘッダ3014を有するブロックB2の中にあるか否かが決定できる。同様に、本願明細書に記載の方法を用いて、ブロックヘッダ3012を有するブロックB1が直前ブロックであるかどうかが決定できる。最後に、ブロックヘッダ3014のnTimeが、ブロックヘッダ3012のnTimeの後の10分より少ないかどうかが決定できる。したがって、2つのビットコイン3008はアリス又はボブに移転され得る。
表20は、このベットトランザクション3002の例示的なロックスクリプトを示す。表20に示されるスクリプトで使用されるOP_EXTRACTTIMEスクリプトは、本願明細書に示されないが、考えられるように、表3に示したnBitsを抽出するためのスクリプトと同様のブロックヘッダから時間エントリを抽出するためのスクリプトである。
[表20]
したがって本明細書と添付図面は限定的ではなく例示的であると解釈すべきである。しかしながら、請求の範囲に記載された本発明の広範な精神及び範囲から逸脱することなく種々の変更を行うことができることが明らかである。
他の変形は本開示の精神の範囲内にある。したがって、開示の技術は、種々の変形及び代替構成の影響を受けるが、その特定の図示の実施形態が図面に示され、以上に詳細に記載された。しかしながら、理解されるべき点は、本発明が開示された1又は複数の特定の形式に限定されないこと、むしろ、添付の請求の範囲に記載のように、全ての変形、代案構成及び均等物が本発明の精神及び範囲に包含されることが意図される。
開示の実施形態を説明する文脈における用語「a」、「an」、及び「the」、並びに同様の指示対象は(特に、以下の請求項の文脈において)、特に断りの無い限り又は文脈により明確に矛盾しないかぎり、単数及び複数の両方をカバーすると考えられるべきである。用語「含む」、「有する」、「含む」、「伴う」、「備える」(comprising、having、including、containing)は、特に断りのない限り広義の語として考えられるべきである(つまり、「を含む、しかし限定されない」を意味する)。用語「接続される」は、変更されず物理的接続を表すとき、何かが仲介する場合でも、部分的又は全体的に含まれる、取り付けられる又は一緒に結合される、として考えられるべきである。本願明細書において値の範囲の詳述は、本願明細書に特に断りの無い限り、単に、範囲に包含される各々の別個の値を個別に参照することの簡単明瞭な言い方として機能することを意図し、各々の個別の値は、それが本願明細書に個々に詳述されたかのように、本願明細書に組み込まれる。用語「セット」(例えば、「アイテムのセット」)又は「サブセット」の使用は、特に断りの無い限り又は文脈に矛盾しない限り、1つ以上の構成要素を含む空ではない集合として考えられるべきである。さらに、特に注記されない又は文脈に矛盾しない限り、対応するセットの用語「サブセット」は、必ずしも対応するセットの適正なサブセットを示さないが、サブセット及び対応するサブセットは等しくてよい。
「A、B、及びCのうちの少なくとも1つ」又は「少なくとも1つのA、B、及びC」の形式の句のような論理的言語は、特に断りの無い限り又は特に明確に文脈に矛盾しない限り、アイテム、後、等がA又はB又はCのいずれか、又はA及びB及びCのセットの任意の空でないサブセットであってよいことを表すために使用されることが理解される。例えば、3つの構成要素を有するセットの説明のための例では、論理的言語「A、B、及びCのうちの少なくとも1つ」又は「少なくとも1つのA、B、及びC」は、以下のセット:{A}、{B}、{C}、{A,B}、{A,C}、{B,C}、{A,B,C}のうちのいずれかを表す。したがって、このような論理的言語は、通常、特定の実施形態が少なくとも1つのA、少なくとも1つのB、及び少なくとも1つのCのそれぞれが存在必要があることを意味することを意図しない。
本願明細書に記載の処理の動作は、本願明細書に示されない限り、又は文脈上明らかに矛盾しない限り、任意の適切な順序で実行できる。本願明細書に記載の処理(又はその変形及び/又は結合)は、実行可能命令により構成される1つ以上のコンピュータシステムの制御下で実行されてよく、1つ以上のプロセッサ上で集合的に実行するコード(例えば、実行可能命令、1つ以上のコンピュータプログラム又は1つ以上のアプリケーション)として、ハードウェアにより、又はそれらの組み合わせで実装されてよい。コードは、コンピュータ可読記憶媒体に、例えば1つ以上のプロセッサにより実行可能な複数の命令を含むコンピュータプログラムの形式で格納されてよい。コンピュータ可読記憶媒体は、非一時的であってよい。
本願明細書で与えられる任意の及び全ての例又は例示的言語(例えば、「のような」)の使用は、単に、本発明の実施形態をより良好に解明することを意図しており、特に断りのない限り本発明の範囲を限定することを意図しない。明細書中のいかなる言語も、本発明の実施に不可欠な任意の非請求要素を示すと考えられるべきではない。
本開示の実施形態は、本願明細書に記載され、本発明を実施するために発明者に知られている最適モードを含む。これらの実施形態の変形は、前述の説明を読んだ当業者に明らかになり得る。発明者は、熟練技術者が、これらの変形を適切に利用することを期待し、発明者は、本開示の実施形態が本願明細書に特に記載されたものと異なる方法で実施されることを意図する。したがって、本開示の範囲は、適切な法により許可されるように、添付の請求の範囲に詳述された主題の全ての変形及び均等物を含む。さらに、それらの全ての可能な変形における上述の要素の任意の組み合わせは、本願明細書に特に断りの無い限り又は文脈に明確に矛盾しない限り、本開示の範囲に包含される。
留意すべきことに、開示の実施形態を説明する文脈において、特に断りのない限り、「命令」が通常単独で実行しない動作(例えば、データの送信、計算、等)を実行する実行可能命令(コード、アプリケーション、エージェント、等とも呼ばれる)に関する表現の使用は、命令が機械により実行されることを示し、それにより機械に指定された演算を実行させる。
留意すべきことに、上述の実施形態は、本発明を限定するのではなく、当業者は添付の請求項により定められる本発明の範囲から逸脱することなく多数の代替の実施形態を考案できる。請求項中、括弧内に記載された如何なる参照符号も、請求項を制限すると見なされるべきではない。用語「有する(comprising又はcomprises)」等は、全体としていかなる請求項中に及び明細書に列挙された以外の要素又はステップの存在を排除するものではない。本願明細書において、「有する(comprises)」は「含む(includes)又は構成される(consists of)」を意味し、「有する(comprising)」は「含む(including)又は構成される(including of)」を意味する。要素の単数の参照は、該要素の複数の存在を排除するものではなく、逆も同様である。本発明は、複数の別個の要素を有するハードウェアにより又は適切にプログラムされたコンピュータにより、実施され得る。複数の手段を列挙している装置の請求項では、これらの複数の手段は、1つの同一のハードウェア要素により実装することができる。特定の量が相互に異なる従属請求項に記載されるという事実は、これらの量の組合せが有利に用いることが出来ないことを示すものではない。