特表 2024-513084 ブロックチェーン実装ハッシュ関数

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

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

(11)【公表番号】

(43)【公表日】2024-03-21

(54)【発明の名称】ブロックチェーン実装ハッシュ関数

(51)【国際特許分類】

   H04L 9/32 20060101AFI20240313BHJP

【ＦＩ】

H04L9/32 200Z

【審査請求】未請求

【予備審査請求】未請求

(21)【出願番号】P 2023561211

(86)(22)【出願日】2022-03-07

(85)【翻訳文提出日】2023-12-04

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

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

(87)【国際公開日】2022-10-13

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

(32)【優先日】2021-04-07

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

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

(32)【優先日】2022-02-15

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

(81)【指定国・地域】

(71)【出願人】

【識別番号】318001991

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

(74)【代理人】

【識別番号】100108453

【弁理士】

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

(74)【代理人】

【識別番号】100110364

【弁理士】

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

(74)【代理人】

【識別番号】100133400

【弁理士】

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

(72)【発明者】

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

(72)【発明者】

【氏名】ウェイ・ジャン

(72)【発明者】

【氏名】アレック・バーンズ

(57)【要約】

ブロックチェーントランザクションを使用してハッシュ関数(HF)を実行するコンピュータ実装方法であって、前記方法は、第1の当事者によって実行され、第1のブロックチェーントランザクションを生成することと、第1のブロックチェーントランザクションをブロックチェーントランザクションの1つまたは複数のノードにサブミットすることとを含み、第1のブロックチェーントランザクションは、ターゲットデータ項目を含む第2のブロックチェーントランザクションのロック解除スクリプトと一緒に実行されたときに、ターゲットデータ項目のハッシュ結果を生成するように構成されているロックスクリプトを含む、コンピュータ実装方法が提供される。

【特許請求の範囲】

【請求項1】

ブロックチェーントランザクションを使用して、ハッシュ関数(HF)を実施するコンピュータ実装方法であって、前記方法が第1の当事者によって実行され、
第1のブロックチェーントランザクションを生成するステップと、
前記第1のブロックチェーントランザクションをブロックチェーンネットワークの1つまたは複数のノードにサブミットするステップとを含み、
前記第1のブロックチェーントランザクションは、ターゲットデータ項目を含む第2のブロックチェーントランザクションのロック解除スクリプトと一緒に実行されたときに、前記ターゲットデータ項目のハッシュ結果を生成するように構成されているロックスクリプトを含み、前記ロックスクリプトは、前記ハッシュ結果を生成することを、少なくとも
第1のパラメータに前記ターゲットデータ項目を乗算することに基づき第1の中間結果を生成するステップ、
前記第1の中間結果への第2のパラメータの加算に基づき第2の中間結果を生成するステップ、
第3のパラメータによる前記第2の中間結果のモジュロに基づき第3の中間結果を生成するステップ、および
第4のパラメータによる前記第3の中間結果のモジュロに基づき前記ハッシュ結果を生成するステップを実行することによって行うように構成されているHFスクリプトを含む、コンピュータ実装方法。

【請求項2】

前記ロックスクリプトは、少なくとも前記ハッシュ結果を出力するように構成される、請求項1に記載の方法。

【請求項3】

前記ロックスクリプトは、予期されるハッシュ結果を含み、前記ロックスクリプトは、前記ロック解除スクリプトによってロック解除されるように前記ターゲットハッシュ結果が前記予期されるハッシュ結果と一致することを必要とするように構成される、請求項1または請求項2に記載の方法。

【請求項4】

前記予期されるハッシュ結果は、予期される公開鍵に前記ハッシュ関数を適用することによって生成される、請求項3に記載の方法。

【請求項5】

前記ロックスクリプトは、前記ターゲットデータ項目が前記予期される公開鍵であることを必要とし、前記予期される公開鍵に対応する秘密鍵を使用して生成された署名を含むように構成される、請求項4に記載の方法。

【請求項6】

前記予期されるハッシュ結果、またはその略記バージョンを、前記予期される公開鍵、前記第1のブロックチェーントランザクションに関連付けられているデータ、および/または前記第1のブロックチェーントランザクションの出力を消費する消費トランザクションに関連付けられているデータのうちの少なくとも1つにマッピングされたルックアップテーブル内に記憶することを含む、請求項4または請求項5に記載の方法。

【請求項7】

前記第1のブロックチェーントランザクションに関連付けられている前記データは、前記第1のブロックチェーントランザクションのトランザクション識別子および/または前記第1のブロックチェーントランザクションそれ自体を含み、および/または
前記消費トランザクションに関連付けられている前記データは、前記消費トランザクションのトランザクション識別子および/または前記消費トランザクションそれ自体を含む、請求項6に記載の方法。

【請求項8】

前記ルックアップテーブルは、複数の異なるハッシュ結果またはその略記バージョンを含み、各々ユニバーサルハッシュ関数を異なる公開鍵に適用することによって生成され、各異なるハッシュ結果は、前記異なる公開鍵、前記異なるハッシュ結果を含むそれぞれのブロックチェーントランザクションに関連付けられているデータ、および/または前記それぞれのブロックチェーントランザクションの出力を消費するそれぞれの消費トランザクションに関連付けられているデータのうちの少なくとも1つにマッピングされる、請求項6または請求項7に記載の方法。

【請求項9】

前記ロックスクリプトは、親公開鍵の子公開鍵を生成するように構成されている公開鍵導出(PKD)スクリプトを含み、前記PKDスクリプトは、前記HFスクリプトを含み、前記ロック解除スクリプトは、前記親公開鍵を含み、前記ターゲットデータ項目は、少なくとも親公開鍵のチェーンコードおよび前記親公開鍵を含み、前記PKDスクリプトは、前記親公開鍵および前記ハッシュ結果に基づき前記子公開鍵を生成するように構成される、請求項1または請求項2に記載の方法。

【請求項10】

前記ターゲットデータ項目は、追加のデータを含む、請求項9に記載の方法。

【請求項11】

前記追加のデータは、前記子公開鍵のインデックス、タイムスタンプ、および/またはメッセージのうちの少なくとも1つを含む、請求項10に記載の方法。

【請求項12】

前記PKDスクリプトは、2進数変換スクリプト、点乗算スクリプト、および点加算スクリプトを含み、前記2進数変換スクリプトは、前記ハッシュ結果を2進数表現に変換するように構成され、前記点乗算スクリプトは、前記ハッシュ結果の前記2進数表現と楕円曲線の生成元との点乗算を実行して中間公開鍵を生成するように構成され、前記点加算スクリプトは、前記中間公開鍵と前記親公開鍵との点加算を実行して前記子公開鍵を生成するように構成される、請求項9から11のいずれか一項に記載の方法。

【請求項13】

前記ハッシュ結果は、10進数または16進数表現で表現され、前記2進数変換スクリプトは、前記ハッシュ結果の前記10進数または16進数表現を前記2進数表現に変換するように構成される、請求項12に記載の方法。

【請求項14】

前記第1のパラメータは任意の非ゼロの数であり、前記第2のパラメータは任意の数であり、前記第3のパラメータは正数であり、前記第4のパラメータは2^Lであり、Lは前記ハッシュ結果の長さを定義するように選択される、請求項1から13のいずれか一項に記載の方法。

【請求項15】

pは、sec9256k1楕円曲線を定義する素数である、請求項14に記載の方法。

【請求項16】

Lは、32、64、128、160、256、または512のうちの1つである、請求項14または請求項15に記載の方法。

【請求項17】

前記ハッシュ関数は、Hash_UHF(P)=[a_iP+b_i mod p] mod nとして定義され、ここで、a_iは前記第1のパラメータであり、b_iは前記第2のパラメータであり、pは前記第3のパラメータであり、nは前記第4のパラメータであり、前記方法は、
前記ハッシュ関数Hash_UHF(P)を、前記第1のパラメータ、前記第2のパラメータ、前記第3のパラメータ、前記第4のパラメータのうちの1つ、いくつか、またはすべての異なるそれぞれの値について前記予期される公開鍵Pに適用することによって前記予期される公開鍵Pについて複数の異なるそれぞれの予期されるハッシュ結果を生成するステップを含む、請求項1から16のいずれか一項に記載の方法。

【請求項18】

前記第1のブロックチェーントランザクションは、複数のそれぞれの出力を含み、各それぞれの出力はそれぞれのターゲット公開鍵を含む異なるそれぞれのブロックチェーントランザクションのそれぞれのロック解除スクリプトとともに実行されたときに、前記それぞれのターゲット公開鍵のそれぞれのハッシュ結果を生成するように構成されているそれぞれのロックスクリプトを含み、前記それぞれのロックスクリプトは、前記それぞれのハッシュ結果を生成することを、少なくとも
それぞれの第1のパラメータに前記ターゲットデータ項目を乗算することに基づきそれぞれの第1の中間結果を生成するステップ、
前記それぞれの第1の中間結果へのそれぞれの第2のパラメータの加算に基づきそれぞれの第2の中間結果を生成するステップ、
それぞれの第3のパラメータによる前記それぞれの第2の中間結果のモジュロに基づきそれぞれの第3の中間結果を生成するステップ、および
それぞれの第4のパラメータによる前記それぞれの第3の中間結果のモジュロに基づき前記それぞれのハッシュ結果を生成するステップを実行することによって行うように構成されているそれぞれのHFスクリプトを含み、
各それぞれのロックスクリプトは、前記複数の予期されるハッシュ結果のうちのそれぞれの1つを含み、前記それぞれのロックスクリプトは、a)前記それぞれのターゲットハッシュ結果が前記それぞれの予期されるハッシュ結果と一致することを必要とし、b)前記ロック解除スクリプトによってロック解除されるように前記それぞれのロック解除スクリプトが前記予期される公開鍵を使用して生成されるそれぞれの署名を含むことを必要とするように構成される、請求項17に記載の方法。

【請求項19】

1つまたは複数のさらなるブロックチェーントランザクションを生成するステップを含み、各さらなるトランザクションは、1つまたは複数のそれぞれの出力を含み、各それぞれの出力はそれぞれのターゲット公開鍵を含む異なるそれぞれのブロックチェーントランザクションのそれぞれのロック解除スクリプトとともに実行されたときに、前記それぞれのターゲット公開鍵のそれぞれのハッシュ結果を生成するように構成されているそれぞれのロックスクリプトを含み、前記それぞれのロックスクリプトは、前記それぞれのハッシュ結果を生成することを、少なくとも
それぞれの第1のパラメータに前記ターゲットデータ項目を乗算することに基づきそれぞれの第1の中間結果を生成するステップ、
前記それぞれの第1の中間結果へのそれぞれの第2のパラメータの加算に基づきそれぞれの第2の中間結果を生成するステップ、
それぞれの第3のパラメータによる前記それぞれの第2の中間結果のモジュロに基づきそれぞれの第3の中間結果を生成するステップ、および
それぞれの第4のパラメータによる前記それぞれの第3の中間結果のモジュロに基づき前記それぞれのハッシュ結果を生成するステップを実行することによって行うように構成されているそれぞれのHFスクリプトを含み、
各それぞれのロックスクリプトは、前記複数の予期されるハッシュ結果のうちのそれぞれの1つを含み、前記それぞれのロックスクリプトは、a)前記それぞれのターゲットハッシュ結果が前記それぞれの予期されるハッシュ結果と一致することを必要とし、b)前記ロック解除スクリプトによってロック解除されるように前記それぞれのロック解除スクリプトが前記予期される公開鍵を使用して生成されるそれぞれの署名を含むことを必要とするように構成される、請求項17または請求項18に記載の方法。

【請求項20】

前記予期される公開鍵Pに対する前記複数の異なるそれぞれの予期されるハッシュ結果を生成する前記ステップは、i)前記ハッシュ関数Hash_UHF(P)を、前記第1のパラメータ、前記第2のパラメータ、前記第3のパラメータ、前記第4のパラメータのうちの1つ、いくつか、またはすべての異なるそれぞれの値に対して前記予期される公開鍵Pに適用することによってそれぞれの中間ハッシュ結果を生成するステップと、ii)暗号学的ハッシュ関数により前記それぞれの中間ハッシュ結果をハッシュするステップとを含む、請求項17から19のいずれか一項に記載の方法。

【請求項21】

請求項18または請求項19に従属するときに、前記それぞれのHFスクリプトによって生成された前記それぞれの第4のパラメータによる前記それぞれの第3の中間結果の前記モジュロは、それぞれの中間ハッシュ結果であり、前記それぞれのHFスクリプトは、前記それぞれの中間ハッシュ結果を前記暗号学的ハッシュ関数によりハッシュすることによって前記それぞれの予期されるハッシュ結果を生成するように構成される、請求項20に記載の方法。

【請求項22】

前記暗号学的ハッシュ関数はRIPEMD160、SHA256、またはRIPEMD160とSHA256との組合せのうちの1つである、請求項20または請求項21に記載の方法。

【請求項23】

前記複数の予期されるハッシュ結果、またはそれぞれの略記バージョンを、前記予期される公開鍵またはそのインデックスのうちの少なくとも1つにマッピングされたルックアップテーブルに記憶するステップを含む、請求項17から22のいずれか一項に記載の方法。

【請求項24】

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

【請求項25】

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

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、ブロックチェーントランザクションを使用してハッシュ関数を実施するための方法に関する。

【背景技術】

【0002】

ブロックチェーンは、ブロックチェーンの複製が分散ピアツーピア(P2P)ネットワーク(以下、「ブロックチェーンネットワーク」と称される)内の複数のノードの各々において維持される、広く公開される分散データ構造の一形態を指す。ブロックチェーンは、データのブロックのチェーンを含み、各ブロックは、1つまたは複数のトランザクションを含む。いわゆる「コインベーストランザクション」以外の、各トランザクションは、1つまたは複数のコインベーストランザクションに遡る1つまたは複数のブロックにまたがり得るシーケンス内の前のトランザクションを指す。コインベーストランザクションについては後述する。ブロックチェーンネットワークに提出されたトランザクションは、新しいブロックに含まれる。新しいブロックは、しばしば「マイニング」と称されるプロセスによって作成され、このプロセスは複数のノードの各々が「プルーフオブワーク」を実行することを競う、すなわち、ブロックチェーンの新しいブロックに入れられるのを待つ順序付けられ承認された保留トランザクションの定義されたセットの表現に基づく暗号パズルを解くことを競い合うことを伴う。ブロックチェーンはいくつかのノードのところで剪定されることがあり、ブロックの公開は単なるブロックヘッダの公開を通じて達成され得ることに留意されたい。

【0003】

ブロックチェーンにおけるトランザクションは、デジタル資産(すなわち、多数のデジタルトークン)を伝達すること、仮想化台帳(virtualised ledger)またはレジストリ内の一連のエントリを順序付けること、タイムスタンプエントリを受信して処理すること、および/またはインデックスポインタを時間順序付けする(time-order)ことのうちの1つまたは複数の目的に使用され得る。ブロックチェーンは、また、ブロックチェーンの上に追加の機能を層化するために利用され得る。たとえば、ブロックチェーンプロトコルは、追加のユーザデータまたはデータへのインデックスをトランザクション内に記憶することを可能にし得る。単一のトランザクション内に記憶できる最大データ容量には事前指定された制限はなく、したがって次第により複雑になってゆくデータが組み込まれ得る。たとえば、これは、ブロックチェーンに電子文書を、またはオーディオもしくはビデオデータを記憶するために使用できる。

【0004】

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

【0005】

最新のブロックを作成するためにプルーフオブワークパズルを解くことに成功したノードは、典型的には、デジタル資産の額、すなわちトークンの数を分配する「コインベーストランザクション」と呼ばれる新しいトランザクションで報われる。無効なトランザクションの検出および拒否は、ネットワークのエージェントとして活動する競合ノードの活動によって強制され、違法行為を報告しブロックするインセンティブを与えられる。情報が広く公開されることは、ユーザがノードのパフォーマンスを継続的に監査することを可能にする。単なるブロックヘッダの公開は、参加者がブロックチェーンの継続的整合性を確実にすることを可能にする。

【0006】

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

【0007】

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

【0008】

トランザクションモデルの代替的タイプはアカウントベースモデルである。この場合、各トランザクションは、過去のトランザクションのシーケンス内において先行するトランザクションのUTXOを参照することによって振替金額を定義するのではなく、むしろ絶対的な口座残高を参照することによって振替金額を定義する。すべての口座の現在の状態は、ブロックチェーンとは別のノードによって記憶され、常に更新される。

【発明の概要】

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

【0009】

ハッシュ関数は、任意の長さの入力を受け取り、固定長の出力を与える関数である。ハッシュ関数には一般的に2つの用途がある。1つは、テーブル検索のためにキー値ペアをインデックス値ペアに変換することであり、この場合、キーはインデックスにハッシュされる。この目的のために、プログラミングでは乗法的ハッシングがよく使用される。他の主要な用途は、暗号法での使用であり、その場合、ハッシュ関数は、一般的に、暗号学的ハッシュ関数と称される。この場合、セキュリティ要件の結果、ハッシュ関数はより複雑なものとなる。一例として、SHA256は、ブロックチェーン技術で使用される暗号的ハッシュ関数である。

【0010】

SHA256などの暗号学的ハッシュ関数は、ブロックチェーントランザクションのロックスクリプトにおいて頻繁に使用される。たとえば、よく知られているロックスクリプトは、以下で説明されるOP_HASH160オペコードを使用するpay-to-public-key-hash(P2PKH)ロックスクリプトである。

【0011】

大部分のブロックチェーン、たとえばビットコインは、限られた数の関数、すなわち演算子からなる限られたスクリプト言語を有する。たとえば、ビットコインでは、これらの関数はオペコードとして知られている。本稿執筆時点では、ビットコインのスクリプト言語(Script)は、ハッシュ関数を実施するために使用され得る5個だけのオペコードに制限されている。OP_RIPEMD160は、RIPEMD-160ハッシュ関数を使用して入力をハッシュするように構成されたオペコードである。OP_SHA1は、SHA-1ハッシュ関数を使用して入力をハッシュするように構成されたオペコードである。OP_SHA256は、SHA-256ハッシュ関数を使用して入力をハッシュするように構成されたオペコードである。OP_HASH160は、最初にSHA-256ハッシュ関数を使用し、次いでRIPEMD-160ハッシュ関数を使用して入力をハッシュするように構成されたオペコードである。最後に、OP_HASH256は、SHA-256ハッシュ関数を使用して入力を2回ハッシュするように構成されたオペコードである。たとえば、https://wiki.bitcoinsv.io/index.php/Opcodes_used_in_Bitcoin_Scriptを参照されたい。他のブロックチェーンも同様に制限される。オペコードの既存のセットによって実施されているものに限定されないハッシュ関数を使用することが有益であるシナリオは多数ある。しかしながら、新しいオペコードを導入することは、ブロックチェーンの安定性を損ない、信頼性を低下させるので望ましくない。したがって、オペコード(またはより一般的には関数)の既存のセットを使用して、スクリプトで実施され得るハッシュ関数の範囲を拡大することが望ましい。

【0012】

さらに、利用可能なオペコードのいくつか(たとえば、OP_HASH256)は、複数の暗号学的ハッシュ関数を入力に適用することを伴い、したがって計算コストがかかる。したがって、複数の暗号学的ハッシュ演算を伴うものに比べて計算コストの低いハッシュ関数を実施することができることが望ましいであろう。

【0013】

本明細書において開示されている一態様によれば、ブロックチェーントランザクションを使用してハッシュ関数、HFを実施するコンピュータ実装方法が提供され、方法は、第1の当事者によって実行され、第1のブロックチェーントランザクションを生成することと、第1のブロックチェーントランザクションをブロックチェーントランザクションの1つまたは複数のノードにサブミットすることとを含み、第1のブロックチェーントランザクションは、ターゲットデータ項目を含む第2のブロックチェーントランザクションのロック解除スクリプトと一緒に実行されたときに、ターゲットデータ項目のハッシュ結果を生成するように構成されているロックスクリプトを含み、ロックスクリプトは、ハッシュ結果を生成することを、少なくとも第1のパラメータにターゲットデータ項目を乗算することに基づき第1の中間結果を生成するステップ、第1の中間結果への第2のパラメータの加算に基づき第2の中間結果を生成するステップ、第3のパラメータによる第2の中間結果のモジュロに基づき第3の中間結果を生成するステップ、および第4のパラメータによる第3の中間結果のモジュロに基づきハッシュ結果を生成するステップを実行することによって行うように構成されているHFスクリプトを含む。

【0014】

ユニバーサルハッシュは、ハッシュ関数のセットからハッシュ関数を選択し、次いで、任意の所与の入力について、選択されたハッシュ関数に基づき出力を計算するアルゴリズムを指す。ユニバーサルハッシュの主な目標は、衝突の可能性を減らすことと、最悪の場合の入力を回避することである(いくつかのハッシュ関数については、ハッシュ値を計算するのに平均よりもかなり長い時間を要する最悪の場合の入力のセットが存在する)。

【0015】

第1のブロックチェーントランザクションのハッシュ関数(HF)スクリプトは、ハッシュ関数を実施するように構成される。いくつかの実施形態において、ハッシュ関数は、入力に第1のパラメータ(a)を乗算し、第2のパラメータ(b)を加算し、mod pを取り、次いでmod nを取ることを伴う。いくつかの例において、他の(マイナーな)演算が実行され得る。したがって、HFスクリプトは、ブロックチェーンのプリミティブスクリプト言語の一部として現在利用可能なものと比較して新しいハッシュ関数を実施するように構成される。それに加えて、HFスクリプトは、いくつかのブロックチェーンで提供されている既存のハッシュ関数(たとえば、OP_HASH160)と比較して計算コストが低い。

【0016】

いくつかの実施形態において、HFスクリプトは、OP_HASH160オペコードの代わりにP2PKHスクリプトの一部として使用され、したがって、より少ない計算で同じ結果(公開鍵ハッシュへの出力をロックすること)を達成する。

【0017】

いくつかの実施形態において、複数の異なるブロックチェーンアドレスが、ユニバーサルハッシュ関数を使用して同じ公開鍵から生成され得る。各アドレスは、トランザクションの異なる出力をロックするために、および/または異なるトランザクションの異なる出力をロックするために使用され得る。各異なる出力は、HFスクリプトのインスタンスを含むものとしてよく、各インスタンスはそれらのアドレスうちの異なるアドレスを含む(したがってそれにロックされる)。

【0018】

本開示の実施形態の理解を助け、そのような実施形態がどのように実施され得るかを示すために、例としてのみ、添付の図面が参照される。

【図面の簡単な説明】

【0019】

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

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

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

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

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

【図5】ブロックチェーントランザクションをブロックチェーンにサブミットするための例示的なシステムの概略ブロック図である。

【図6】ブロックチェーントランザクションをブロックチェーンにサブミットするための別の例示的なシステムの概略ブロック図である。

【図7】鍵の階層的決定論的セットの概略を例示する図である。

【図8】2進表現に変換するための例示的なスクリプトを示す図である。

【図9】点スカラー乗算を実行するための例示的なスクリプトを示す図である。

【図10】逆モジュロ計算を実行するための例示的なスクリプトを示す図である。

【図11】2つの異なる点の点加算を実行するための例示的なスクリプトを示す図である。

【図12】2つの同じ点の点加算を実行するための例示的なスクリプトを示す図である。

【図13】2つの点の点加算を実行するための例示的なスクリプトを示す図である。

【図14】データを圧縮鍵形式に変換するための例示的なスクリプトを示す図である。

【図15】ハイブリッドハッシュインデックススキームの概略を例示する図である。

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

【0020】

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

【0021】

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

【0022】

ブロックチェーン150は、データのブロック151を含み、ブロックチェーン150のそれぞれのコピーは、分散型またはブロックチェーンネットワーク106内の複数のブロックチェーンノード104の各々において維持される。上述のように、ブロックチェーン150のコピーを維持することは、必ずしもブロックチェーン150を完全に記憶することを意味しない。その代わりに、各ブロックチェーンノード150が各ブロック151のブロックヘッダ(後述)を記憶する限りブロックチェーン150はデータを剪定され得る。チェーン内の各ブロック151は、1つまたは複数のトランザクション152を含み、この文脈でのトランザクションは、一種のデータ構造を指す。データ構造の性質は、トランザクションモデルまたはスキームの一部として使用されるトランザクションプロトコルのタイプに依存する。所与のブロックチェーンは、全体を通して1つの特定のトランザクションプロトコルを使用する。トランザクションプロトコルの1つの共通のタイプにおいて、各トランザクション152のデータ構造は、少なくとも1つの入力と少なくとも1つの出力とを含む。各出力は、財産としてのデジタル資産の数量を表す額を指定し、その一例は、出力が暗号学的にロックされている(ロックを解除し、それによって償還または支出されるためにそのユーザの署名または他の解を必要とする)ユーザ103である。各入力は、先行するトランザクション152の出力を指し示し、それによってトランザクションをリンクする。

【0023】

各ブロック151は、また、ブロック151に順序を定義するように、チェーン内の以前に作成されたブロック151を指すブロックポインタ155を含んでいる。各トランザクション152(コインベーストランザクション以外の)は、トランザクションのシーケンスに順序を定義するように、前のトランザクションを指すポインタを含む(注:トランザクションのシーケンス152は分岐することが許されている)。ブロック151のチェーンは、チェーン内の最初のブロックであったジェネシスブロック(Gb)153にまで遡る。チェーン150内の初期の1つまたは複数の元のトランザクション152は、先行するトランザクションではなくむしろジェネシスブロック153を指していた。

【0024】

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

【0025】

所与の現在のトランザクション152jにおいて、その(または各)入力は、トランザクションのシーケンス内の先行するトランザクション152iの出力を参照するポインタを含み、この出力が現在のトランザクション152jにおいて償還されるかまたは「消費」されるべきであることを指定する。一般に、先行するトランザクションは、順序付きセット154または任意のブロック151内の任意のトランザクションである可能性がある。先行するトランザクション152iは、現在のトランザクション152jが作成されるか、またはさらにはネットワーク106に送信された時点では必ずしも存在している必要はないが、現在のトランザクションが有効であるためには先行するトランザクション152iが存在し、承認される必要がある。したがって、本明細書における「先行する」は、必ずしも時間的シーケンスにおける作成または送信の時点ではない、ポインタによってリンクされた論理的シーケンス内の先行要素を指し、したがって、トランザクション152i、152jが順序から外れて作成されるか、または送信されることを必ずしも排除しない(オーファントランザクションに関する以下の説明を参照)。先行するトランザクション152iは、等しく前のトランザクションまたは先行トランザクションと呼ばれることも可能である。

【0026】

本トランザクション152jの入力は、また、入力認可、たとえば先行するトランザクション152iの出力がロックされているユーザ103aの署名も含む。次に、本トランザクション152jの出力は、新規ユーザまたはエンティティ103bに暗号的にロックされ得る。本トランザクション152jは、したがって、本トランザクション152jの出力で定義されるように先行するトランザクション152iの入力で定義された額を新規ユーザまたはエンティティ103bに転送することができる。いくつかの場合において、トランザクション152は、複数のユーザまたはエンティティ(そのうちの1つは、釣り銭を渡すために元のユーザまたはエンティティ103aである可能性もある)の間で入力額を分割するために複数の出力を有し得る。いくつかの場合において、トランザクションは、1つまたは複数の先行するトランザクションの複数の出力から金額を集め、現在のトランザクションの1つまたは複数の出力に再分配するための複数の入力を有することもできる。

【0027】

ビットコインなどの出力ベースのトランザクションプロトコルによれば、個人ユーザまたは組織などの当事者103が、(手動または当事者によって採用される自動化プロセスによって)新規のトランザクション152jを制定することを望むときに、実施当事者は、そのコンピュータ端末102から受信者に新しいトランザクションを送信する。制定当事者または受信者は、最終的にこのトランザクションをネットワーク106のブロックチェーンノード104の1つまたは複数に送信する(現在では典型的にはサーバまたはデータセンターであるが、原理上、他のユーザ端末とすることも可能である)。また、新しいトランザクション152jを制定する当事者103が、このトランザクションをブロックチェーンノード104の1つまたは複数に直接的に送信し、いくつかの例では、受信者に送信しないことも排除されない。トランザクションを受信したブロックチェーンノード104は、ブロックチェーンノード104の各々で適用されるブロックチェーンノードプロトコルに従ってトランザクションが有効であるかどうかをチェックする。ブロックチェーンノードプロトコルは、典型的には、ブロックチェーンノード104が、新規トランザクション152jにおける暗号署名が、トランザクション152の順序付けられたシーケンス内の前のトランザクション152iに依存する、期待される署名と一致することをチェックすることを必要とする。そのような出力ベースのトランザクションプロトコルにおいて、これは、新規トランザクション152jの入力に含まれる当事者103の暗号署名または他の認可が、新規トランザクションが割り当てる先行するトランザクション152iの出力において定義された条件に一致することをチェックすることを含むものとしてよく、この条件は、典型的には、新規トランザクション152jの入力における暗号署名または他の認可が、新規トランザクションの入力がリンクされている前のトランザクション152iの出力をロック解除することを少なくともチェックすることを含む。この条件は、前のトランザクション152iの出力に含まれるスクリプトによって少なくとも部分的に定義され得る。代替的に、単純にブロックチェーンノードプロトコルだけで修正されるか、またはこれらの組合せに起因することもあり得る。いずれにせよ、新規トランザクション152jが有効である場合、ブロックチェーンノード104は、それをブロックチェーンネットワーク106内の1つまたは複数の他のブロックチェーンノード104に転送する。これらの他のブロックチェーンノード104は、同じブロックチェーンノードプロトコルに従って同じテストを適用するので、新規トランザクション152jを1つまたは複数のさらなるノード104に転送する、というように続く。このようにして、新規トランザクションは、ブロックチェーンノード104のネットワーク全体に伝播される。

【0028】

出力ベースモデルでは、所与の出力(たとえばUTXO)が割り当てられた(たとえば消費された)かどうかの定義は、ブロックチェーンノードプロトコルに従って、別の、前方のトランザクション152jの入力によってまだ有効に償還されているかどうかである。トランザクションが有効であるための別の条件は、償還することを試みる先行するトランザクション152iの出力が、別のトランザクションによってまだ償還されていないことである。ここでもまた有効でない場合、トランザクション152jは伝播されないか(警告のために無効であるとフラグが立てられ伝播されない限り)、またはブロックチェーン150に記録されない。これは、トランザクション実行者が同じトランザクションの出力を複数回割り当てようとする二重支払いから保護するものである。その一方で、アカウントベースモデルは、勘定残高を維持することによって二重支払いを防止する。ここでもまたトランザクションの定められた順序があるので、勘定残高はどの時点においても単一の定義済み状態を有する。

【0029】

トランザクションを承認することに加えて、ブロックチェーンノード104は、「プルーフオブワーク」によってサポートされる、マイニングと一般的に称されるプロセスでトランザクションのブロックを最初に作成するものとなる競争を行う。ブロックチェーンノード104では、新規トランザクションが、ブロックチェーン150上に記録されたブロック151内にまだ出現していない有効なトランザクションの順序付けられたプール154に追加される。次いで、ブロックチェーンノードは、暗号パズルを解くことを試みることによってトランザクション152の新しい有効なブロック151を、トランザクション154の順序付けられたセットから組み立てる競争をする。典型的には、これは、「ノンス」を探索することであって、ノンスが保留トランザクション154の順序付けられたプールの表現と連結されハッシュされたときにハッシュの出力が所定の条件を満たすような、探索することを含む。たとえば、所定の条件は、ハッシュの出力が特定の事前定義済みの数の先行ゼロを有することであり得る。これは1つの特定のタイプのプルーフオブワークパズルにすぎず、他のタイプは排除されない。ハッシュ関数の特性は、入力に対して予測不可能な出力を有するという性質である。したがって、この探索は総当りによってのみ実行することができ、したがって、パズルを解こうとしている各ブロックチェーンノード104において処理リソースの実質的な量が消費される。

【0030】

パズルを解いた最初のブロックチェーンノード104は、これをネットワーク106に発表し、ネットワーク内の他のブロックチェーンノード104が容易にチェックできる証明として解を提供する(ハッシュの解が与えられれば、それがハッシュの出力を条件に合致させることをチェックするのは容易である)。最初のブロックチェーンノード104は、ブロックを受け入れる他のノードの閾値コンセンサスにブロックを伝播し、したがって、プロトコルルールを強制する。次いで、トランザクション154の順序付けられたセットは、ブロックチェーンノード104の各々によってブロックチェーン150内に新しいブロック151として記録されるようになる。ブロックポインタ155も、チェーン内の以前に作成されたブロック151n-1を指す新しいブロック151nに割り当てられる。プルーフオブワークの解を作成するために必要な、たとえばハッシュの形態の、著しい量の労力は、ブロックチェーンプロトコルのルールに従う第1のノード104の意向をシグナリングする。そのようなルールは、以前に承認されたトランザクションと同じ出力を割り当てる場合にトランザクションを有効なものとして受け入れないことを含むが、これは他の場合には二重支払いとしても知られている。作成された後、ブロック151は、ブロックチェーンネットワーク106内のブロックチェーンノード104の各々で認識され維持されるので、修正できない。ブロックポインタ155は、また、ブロック151に順序を課す。トランザクション152は、ネットワーク106内の各ブロックチェーンノード104において順序付けられたブロックに記録されるので、これはしたがって、トランザクションの不変の公開台帳を提供する。

【0031】

任意の所与の時点でパズルを解く競争をしている異なるブロックチェーンノード104は、解を探し始めた時期またはトランザクションが受信された順序に応じて、任意の所与の時点でまだ公開されていないトランザクション154のプールの異なるスナップショットに基づきそうするものとしてよいことに留意されたい。それぞれのパズルを最初に解いた者は、どのトランザクション152が次の新しいブロック151nに含まれ、どの順序で含まれるかを定義し、未公開トランザクションの現在のプール154は更新される。次いで、ブロックチェーンノード104は、未公開トランザクション154の新規に定義された順序付きプールからブロックを作成する競争をする、というように続ける。また、2つのブロックチェーンノード104がブロックチェーンの対立する見解がノード104間で伝播されるような互いの非常に短い時間内にパズルを解く場合である、発生し得る任意の「フォーク」を解決するためのプロトコルも存在する。要するに、フォークのどの分岐が最も長く成長しても、決定的なブロックチェーン150になる。これは同じトランザクションが両方のフォークに出現するときにネットワークのユーザまたはエージェントに影響を及ぼしてはならないことに留意されたい。

【0032】

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

【0033】

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

【0034】

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

【0035】

また、ネットワーク101に接続されているのは、消費ユーザの役割を担う複数の当事者103の各々のコンピュータ機器102である。これらのユーザは、ブロックチェーンネットワーク106とインタラクティブにやり取りし得るが、トランザクションを承認することまたはブロックを構築することに参加することはない。これらのユーザまたはエージェント103のいくつかは、トランザクションにおける送信者および受信者として働き得る。他のユーザは、必ずしも送信者または受信者として活動することなくブロックチェーン150とインタラクティブにやり取りし得る。たとえば、いくつかの当事者は、ブロックチェーン150のコピーを記憶する(たとえば、ブロックチェーンノード104からブロックチェーンのコピーを取得している)ストレージエンティティとして働き得る。

【0036】

当事者103の何人かまたは全員は、異なるネットワーク、たとえばブロックチェーンネットワーク106の上に重ねられたネットワークの一部として接続され得る。ブロックチェーンネットワークのユーザ(多くの場合に「クライアント」と称される)は、ブロックチェーンネットワーク106を含むシステムの一部であると言われ得るが、これらのユーザは、ブロックチェーンノードの必要な役割を実行しないのでブロックチェーンノード104ではない。その代わりに、各当事者103は、ブロックチェーンノード106に接続する(すなわち、通信する)ことによってブロックチェーンネットワーク106とインタラクティブにやり取りし、それによってブロックチェーン150を利用し得る。2つの当事者103およびそれぞれの機器102、すなわち第1の当事者103aおよびそのそれぞれのコンピュータ機器102a、ならびに第2の当事者103bおよびそのそれぞれのコンピュータ機器102bが例示を目的として示されている。さらに多くのそのような当事者103およびそのそれぞれのコンピュータ機器102が存在し、システム100に参加し得るが、便宜上、それらは例示されていないことは理解されるであろう。各当事者103は、個人であっても組織であってもよい。純粋に例示を用いて、第1の当事者103aは本明細書ではアリスと称され、第2の当事者103bはボブと称されるが、これは限定するものではなく、本明細書におけるアリスまたはボブへの参照は、それぞれ「第1の当事者」および「第2の当事者」と置き換えてもよいことは理解されるであろう。

【0037】

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

【0038】

クライアントアプリケーション105は、たとえばサーバからダウンロードされた、好適なコンピュータ可読記憶媒体上で任意の所与の当事者103のコンピュータ機器102に最初に提供され得るか、または取り外し可能SSD、フラッシュメモリキー、取り外し可能EEPROM、取り外し可能磁気ディスクドライブ、磁気フロッピーディスクもしくはテープなどの取り外し可能記憶デバイス、CDまたはDVD ROMなどの光ディスク、または取り外し可能光学式ドライブなど、で提供され得る。

【0039】

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

【0040】

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

【0041】

各コンピュータ機器102上のクライアントアプリケーションまたはソフトウェア105のインスタンスは、ネットワーク106のブロックチェーンノード104のうちの少なくとも1つに動作可能に結合される。これは、クライアント105のウォレット機能がネットワーク106にトランザクション152を送信することを可能にする。クライアント105は、また、それぞれの当事者103が受信者である任意のトランザクションについてブロックチェーン150を問い合わせる(または実施形態ではブロックチェーン150は、一部はその公共の可視性を通してトランザクションに信頼を提供する公共の施設であるので、実際にブロックチェーン150内の他の当事者のトランザクションを検査する)ためにブロックチェーンノード104と連絡を取ることができる。各コンピュータ機器102上のウォレット機能は、トランザクションプロトコルに従ってトランザクション152を定式化し送信するように構成される。上で述べたように、各ブロックチェーンノード104は、ブロックチェーンノードプロトコルに従ってトランザクション152を承認し、ブロックチェーンネットワーク106全体に伝播させるためにトランザクション152を転送するように構成されたソフトウェアを実行する。トランザクションプロトコルおよびノードプロトコルは互いに対応し、所与のトランザクションプロトコルは所与のノードプロトコルと一緒になり、一緒に所与のトランザクションモデルを実施する。同じトランザクションプロトコルは、ブロックチェーン150内のすべてのトランザクション152に使用される。同じノードプロトコルは、ネットワーク106内のすべてのノード104によって使用される。

【0042】

所与の当事者103、たとえばアリスは、ブロックチェーン150に含まれるべき新しいトランザクション152jを送信することを望むときに、アリスは、関連するトランザクションプロトコルに従って(アリスのクライアントアプリケーション105のウォレット機能を使用して)新しいトランザクションを定式化する。次いで、アリスは、クライアントアプリケーション105から、自分が接続されている1つまたは複数のブロックチェーンノード104にトランザクション152を送信する。たとえば、これはアリスのコンピュータ102に最もよく接続されているブロックチェーンノード104である可能性もある。任意の所与のブロックチェーンノード104が新規トランザクション152jを受信したときに、これは、ブロックチェーンノードプロトコルおよびそのそれぞれの役割に従ってそれを処理する。これは、新しく受信されたトランザクション152jが「有効」であるためのある条件を満たすかどうかを最初にチェックすることを含むが、その例は、まもなくより詳細に説明される。いくつかのトランザクションプロトコルでは、検証のための条件は、トランザクション152に含まれるスクリプトによってトランザクション毎に構成可能であり得る。代替的に、この条件は、単純にノードプロトコルの組み込み機能であるか、またはスクリプトとノードプロトコルとの組合せによって定義されることも可能である。

【0043】

新たに受信されたトランザクション152jが有効とみなされることについてのテストに合格するという条件で(すなわち、それが「承認される」という条件で)、トランザクション152jを受信する任意のブロックチェーンノード104は、そのブロックチェーンノード104で維持されているトランザクション154の順序付けられたセットに新しい承認されたトランザクション152を追加する。さらに、トランザクション152jを受信した任意のブロックチェーンノード104は、承認されたトランザクション152をネットワーク106内の1つまたは複数の他のブロックチェーンノード104に前方伝播される。各ブロックチェーンノード104は同じプロトコルを適用するので、次いで、トランザクション152jが有効であると仮定すると、これは、それがすぐにネットワーク106全体にわたって伝播されることを意味する。

【0044】

所与のブロックチェーンノード104で維持されている保留トランザクション154の順序付けられたプールに入るのを許された後、そのブロックチェーンノード104は、新しいトランザクション152を含むそれぞれのプール154の最新バージョンでプルーフオブワークパズルを解く競争を開始する(他のブロックチェーンノード104はトランザクション154の異なるプールに基づきパズルを解こうとしている可能性があるが、最初にそこに辿り着いた者が最新のブロック151に含まれるトランザクションの集合を定義するということを覚えておこう。最終的にブロックチェーンノード104は、アリスのトランザクション152jを含む順序付けられたプール154の一部に対するパズルを解くことになる)。新規トランザクション152jを含むプール154に対してプルーフオブワークが行われた後、それは、不変的に、ブロックチェーン150内のブロック151のうちの1つの一部となる。各トランザクション152は、以前のトランザクションを指すポインタを含み、したがってトランザクションの順序もまた、不変的に記録される。

【0045】

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

【0046】

いくつかのブロックチェーンネットワークによって運用されるトランザクションプロトコルの代替的タイプは、アカウントベーストランザクションモデルの一部として、「アカウントベース」プロトコルと称され得る。アカウントベースのケースでは、各トランザクションは、過去のトランザクションのシーケンス内において先行するトランザクションのUTXOを参照することによって振替金額を定義するのではなく、むしろ絶対的な口座残高を参照することによって振替金額を定義する。すべての口座の現在の状態は、ブロックチェーンとは別の、そのネットワークのノードによって記憶され、常に更新される。そのようなシステムでは、トランザクションは、口座の実行中トランザクション集計(「ポジション」とも呼ばれる)を使用して順序付けられる。この値は、暗号署名の一部として送信者によって署名され、トランザクション参照計算の一部としてハッシュ化される。それに加えて、任意のデータフィールドもトランザクションにおいて署名され得る。このデータフィールドは、たとえば以前のトランザクションIDがデータフィールドに含まれる場合に、以前のトランザクションを指してもよい。

【0047】

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

【0048】

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

【0049】

たとえば、アリス103aが、注目しているデジタル資産の額をボブ103bに転送するトランザクション152jを作成することを望んでいる。図2において、アリスの新規トランザクション152jは「Tx₁」とラベル付けされている。これは、シーケンス内の先行するトランザクション152iの出力203においてアリスにロックされているデジタル資産の額を取り、これの少なくとも一部をボブに転送する。先行するトランザクション152iは、図2において「Tx₀」とラベル付けされている。Tx₀およびTx₁は、任意のラベルにすぎない。これらは、必ずしも、Tx₀がブロックチェーン151の最初のトランザクションであることも、Tx₁がプール154内のすぐ次のトランザクションであることも意味しない。Tx₁は、アリスにロックされた未使用の出力203を依然として有する任意の先行する(すなわち前の)トランザクションを指すことも可能である。

【0050】

先行するトランザクションTx₀は、アリスが新規トランザクションTx₁を作成する時点、または少なくともネットワーク106に送信する時点までに、すでに正当性を確認され、ブロックチェーン150のブロック151に含まれているものとしてよい。それは、その時点でブロック151のうちの1つにすでに含まれているか、または順序付けられたセット154においてまだ待機しているものとしてよく、その場合、それはすぐに新しいブロック151に含まれることになる。代替的に、Tx₀およびTx₁は、一緒に作成されてネットワーク106に送信される可能性があるか、またはTx₀は、ノードプロトコルが「オーファン」トランザクションのバッファリングを可能にする場合にTx₁の後に送信され得ることすら可能である。トランザクションのシーケンスの文脈で本明細書において使用されている「先行する」および「後続の」という言い回しは、トランザクションで指定されたトランザクションポインタ(どのトランザクションがどの他のトランザクションを指しているか、など)によって定義されるようなシーケンス内のトランザクションの順序を指している。これらは、等しく、「先行要素」および「後続要素」、または「前要素」および「子孫」、「親」および「子」、またはそのようなものと置き換えられることも可能である。これは、必ずしも、それらが作成され、ネットワーク106に送信され、または任意の所与のブロックチェーンノード104に到着する順序を暗示するものではない。それでもなお、先行するトランザクション(前のトランザクションまたは「親」)を指す後続のトランザクション(子孫トランザクションまたは「子」)は、親トランザクションが承認されるまで、また承認がなされない限り、承認されない。親よりも先にブロックチェーンノード104に到着した子は、オーファンとみなされる。それは、ノードプロトコルおよび/またはノードの挙動に応じて、親を待つために廃棄されるか、または一定時間バッファリングされ得る。

【0051】

先行するトランザクションTx₀の1つまたは複数の出力203のうちの1つは、ここではUTXO₀とラベル付けされている、特定のUTXOを含む。各UTXOは、UTXOによって表されるデジタル資産の額を指定する値と、後続のトランザクションが承認され、したがってUTXOが首尾よく償還されるために後続のトランザクションの入力202のロック解除スクリプトによって満たされなければならない条件を定義するロックスクリプトとを含む。典型的には、ロックスクリプトは、金額を特定の当事者(それが含まれるトランザクションの受益者)にロックする。すなわち、ロックスクリプトは、典型的には、後続のトランザクションの入力におけるロック解除スクリプトが、先行するトランザクションがロックされている当事者の暗号署名を含む条件を含む、ロック解除条件を定義する。

【0052】

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

【0053】

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

【0054】

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

【0055】

公開秘密暗号による認証の詳細は、当業者には馴染み深いものであろう。基本的に、アリスが自分の秘密鍵を使用してメッセージを署名している場合、アリスの公開鍵および平文のメッセージが与えられれば、ノード104などの別のエンティティは、メッセージがアリスによって署名されたに違いないと認証することができる。署名は、典型的には、メッセージをハッシュ化し、ハッシュに署名し、これを署名としてメッセージにタグ付けすることを含み、したがって公開鍵の保有者は誰でも署名を認証することができる。したがって、特定のデータ部分またはトランザクションの一部などに署名するという本明細書の言及は、実施形態において、そのデータ部分またはトランザクションの一部のハッシュに署名することを意味し得ることに留意されたい。

【0056】

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

【0057】

所与のトランザクション152のすべての出力203で指定された総額が、そのすべての入力202によって指されている総額よりも大きい場合、これはほとんどのトランザクションモデルにおいて無効であることに対する別の基準である。したがって、そのようなトランザクションは伝播されず、ブロック151に含まれることもない。

【0058】

UTXOベーストランザクションモデルでは、所与のUTXOは全体として消費される必要があることに留意されたい。UTXOにおいて定義された金額の一部を、別の部分が消費されている間に、消費済みとして「残す」ことはできない。しかしながら、UTXOからの金額は、次のトランザクションの複数の出力の間に分割され得る。たとえば、Tx₀のUTXO₀で定義されている金額は、Tx₁における複数のUTXOの間に分割され得る。したがって、アリスがボブにUTXO₀で定義された金額のすべてを与えたくない場合、アリスは、残りをTx₁の第2の出力で自分自身に釣り銭を渡すか、または他の当事者に支払うために使用することができる。

【0059】

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

【0060】

アリスおよびボブのデジタル資産は、ブロックチェーン150内のどこかにある任意のトランザクション152において彼らにロックされたUTXOからなる。したがって、典型的には、所与の当事者103の資産は、ブロックチェーン150全体における様々なトランザクション152のUTXO全体を通して散らばっている。所与の当事者103の総残高を定義する1つの数がブロックチェーン150内のどこかに記憶されているわけではない。それぞれの当事者にロックされ、別の前方のトランザクションでまだ消費されていないすべての様々なUTXOの値をまとめて照合するのはクライアントアプリケーション105内のウォレット機能の役割である。ビットコインノード104のいずれかに記憶されているようなブロックチェーン150のコピーに問い合わせることによってこれを行うことができる。

【0061】

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

【0062】

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

【0063】

ロックスクリプトは、これが典型的にはそれぞれのトランザクションがロックされる当事者の公開鍵を含むという事実を指して、「scriptPubKey」と呼ばれることがある。ロック解除スクリプトは、典型的には対応する署名を提供するという事実を指す「scriptSig」と呼ばれることがある。しかしながら、より一般的に、ブロックチェーン150のすべてのアプリケーションにおいて、UTXOが償還されるための条件が署名を認証することを含むことは不可欠でない。より一般的には、スクリプト言語は、任意の1つまたは複数の条件を定義するために使用されることが可能である。したがって、より一般的な用語である「ロックスクリプト」および「ロック解除スクリプト」が好まれ得る。

【0064】

3. サイドチャネル
図1に示されているように、アリスおよびボブのコンピュータ機器102a、120bの各々の上のクライアントアプリケーションは、それぞれ、追加の通信機能を備え得る。この追加の機能は、アリス103aが、ボブ103bと(いずれかの当事者または第三者の扇動で)別個のサイドチャネル107を確立することを可能にする。サイドチャネル107は、ブロックチェーンネットワークから離れてデータを交換することを可能にする。そのような通信は、ときには「オフチェーン」通信と称される。たとえば、これは、当事者の一方がネットワーク106にブロードキャストすることを選択するまで、トランザクションが(まだ)ブロックチェーンネットワーク106に登録されることなく、またはチェーン150上を進むことなく、アリスとボブとの間でトランザクション152を交換するために使用され得る。このようにトランザクションを共有することは、ときには、「トランザクションテンプレート」を共有すると称される。トランザクションテンプレートは、完全なトランザクションを形成するために必要な1つまたは複数の入力および/または出力を欠いている場合がある。代替的に、またはそれに加えて、サイドチャネル107は、鍵、交渉された金額または条件、データコンテンツなどの任意の他のトランザクション関係データを交換するために使用され得る。

【0065】

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

【0066】

4. クライアントソフトウェア
図3Aは、現在開示されているスキームの実施形態を実施するためのクライアントアプリケーション105の例示的な実施形態を例示する。クライアントアプリケーション105は、トランザクションエンジン401とユーザインターフェース(UI)層402とを含む。トランザクションエンジン401は、上で述べられたスキームに従って、およびまもなくさらに詳細に説明されるように、トランザクション152を定式化し、サイドチャネル301を介してトランザクションおよび/もしくは他のデータを受信しおよび/または送信し、ならびに/またはブロックチェーンネットワーク106を通して伝搬されるように1つまたは複数のノード104にトランザクションを送信するなどのために、クライアント105の基礎となるトランザクション関係機能を実施するように構成される。

【0067】

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

【0068】

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

【0069】

図3Bは、アリスの機器102a上のクライアントアプリケーション105aのUI層402によってレンダリングされ得るユーザインターフェース(UI)500の例のモックアップを示している。類似のUIが、クライアント105bによって、ボブの機器102b、または他の当事者の機器上でレンダリングされ得ることは理解されるであろう。

【0070】

たとえば、図3Bは、アリスの視点からのUI500を示している。UI500は、ユーザ出力手段を介して異なるUI要素としてレンダリングされる1つまたは複数のUI要素501、502、502を含み得る。

【0071】

たとえば、UI要素は、異なるオンスクリーンボタン、もしくはメニュー内の異なるオプション、またはそのような同様のものなどであってもよい、1つまたは複数のユーザ選択可能要素501を含み得る。ユーザ入力手段は、ユーザ103(この場合、アリス103a)が、画面上のUI要素をクリックするかもしくはタッチするか、または所望のオプションの名前を発話することなどによって、それらのオプションのうちの1つを選択するか、または他の方法で操作することを可能にするように配置構成される(注:本明細書で使用される「手動」という用語は、自動と対比することのみを意味し、必ずしも手の使用に限定されない)。

【0072】

代替的にまたはそれに加えて、UI要素は、1つまたは複数のデータ入力フィールド502を含むものとしてよく、これを通じてユーザはデータを入力することができる。これらのデータ入力フィールドは、ユーザ出力手段を介して、たとえばオンスクリーンでレンダリングされ、データは、ユーザ入力手段、たとえばキーボードまたはタッチスクリーンを通してフィールドに入力され得る。代替的に、データは、たとえば音声認識に基づき口頭で受け取ることも可能である。

【0073】

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

【0074】

様々なUI要素をレンダリングし、オプションを選択し、データを入力する特定の手段は重要ではないことは理解されるであろう。これらのUI要素の機能については、まもなく詳しく説明される。また、図3に示されているUI500は、図式化されたモックアップにすぎず、実際には、簡潔にするために例示されていない1つまたは複数のさらなるUI要素を含み得ることも理解されるであろう。

【0075】

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

【0076】

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

【0077】

スクリプトを一緒に実行することによって、スクリプトエンジン452は、ロック解除スクリプトがロックスクリプトで定義された1つまたは複数の基準を満たすかどうか、すなわち、ロックスクリプトが含まれる出力を「ロック解除」するかどうかを決定する。スクリプトエンジン452は、この決定の結果をプロトコルエンジン451に返す。スクリプトエンジン452は、ロック解除スクリプトが対応するロックスクリプトで指定された1つまたは複数の基準を満たすと決定した場合、結果「真」を返す。そうでない場合は、結果「偽」を返す。

【0078】

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

【0079】

また、本明細書における「真」および「偽」という用語は、確かに1つの可能な実施形態ではあるけれども、必ずしも単一の2進数(ビット)のみの形式で表される結果を返すことに限定されないことに留意されたい。より一般的には、「真」は、成功または肯定的な結果を示す任意の状態を指すことができ、「偽」は、不成功または非肯定的な結果を示す任意の状態を指すことができる。たとえば、アカウントベースのモデルでは、「真」の結果は、署名の暗黙のプロトコルレベル承認と、スマートコントラクトの追加的な肯定的出力との組合せによって示される可能性がある(個々の結果が両方とも真である場合に全体的な結果は真を示すとみなされる)。

【0080】

6. 定義
定義1-乗算的ハッシュ
テーブルサイズが2^m、方法が2ⁿ、奇数整数a∈{1,...,2ⁿ-1}であると仮定する。次いで、乗法的ハッシュ関数hは、

【数1】

であるとして定義される。
すなわち、xを与えられた場合、
1.ax mod 2ⁿを計算する-axの最下位nビットを取る。
2.(n-m)ビットを右シフトする-ステップ1からの結果の最上位mビットを取る。

【0081】

定義2-ハッシュ関数のデルタ関数
f:A→Bをハッシュ関数とする。任意の2つの要素x,y∈Aについて、われわれは

【数2】

を定義する。

【0082】

定義3-ハッシュ関数のセットに対するデルタ関数
Hをハッシュ関数のセットとする。われわれは
δ_Η(x,y)=Σ_f∈Hδ_f(x,y)
を定義する。

【0083】

定義4-ユニバーサルハッシュ
HをAからBへのハッシュ関数のセットとする。Ηは、Aに含まれるすべてのx,yについて
δ_Η(x,y)≦|Η|/|B|
である場合にユニバーサルという。
δ_H(x,y)は、x≠yのときに衝突を誘発するセット内のハッシュ関数の数を数え、|Η|/|B|は、範囲のサイズに対するハッシュ関数の多さを示すことに留意されたい。

【0084】

例
p≧mは素数であり、m>nである場合に

【数3】

と置く。このとき、Hはユニバーサルである。
|Η|=p(p-1)、および|B|=nであることに留意されたい。この証明は、「Universal Classes of Hash Functions」、J. L. Carter M. N. Wegman.に載っている。

【0085】

定義5-暗号学的ハッシュ
ハッシュ関数Hが暗号学的に安全であるのは、次の場合である。
1.原像計算困難性-h=H(m)が与えられた場合、mを見つけることは計算的に困難である。
2.第二原像計算困難性-h=H(m)およびmが与えられた場合、H(m')=hであるようなm'を見つけることは計算的に困難である。
3.衝突困難性-H(m)=H(m')であるようなメッセージmおよびm'のペアを見つけることは計算的に困難である。

【0086】

7. インスクリプトハッシュ関数
図5は、ブロックチェーントランザクションを使用してハッシュ関数を実施するための例示的なシステム500を例示している。このシステムは、第1の当事者、たとえばアリス103aと、第2の当事者、たとえばボブ103bとを含む。システムは、また、ブロックチェーンネットワーク106の1つまたは複数のノード104を含む。アリス103aおよびボブ103bは、それぞれ第1の当事者および第2の当事者に対する便利なラベルとして単に使用されるだけであり、図1から図4を参照しつつ上でアリス103aおよびボブ103bに関連付けられるとして説明されているアクションのすべてを実行するように必ずしも構成される必要はないが、それが排除されるわけではないことに留意されたい。

【0087】

図示されているように、アリス103aは、第1のブロックチェーントランザクションTx1を生成し、第1のブロックチェーントランザクションTx1をブロックチェーンネットワーク106にサブミットするように構成される。第1のブロックチェーントランザクションは1つまたは複数の入力および1つまたは複数の出力を含む。出力の少なくとも1つ(「第1の出力」)は、ハッシュ関数(HF)スクリプトを含むロックスクリプト(「第1のロックスクリプト」)を含む。ここでの「第1」は単にラベルとしてだけ使用されており、必ずしも任意の形式の順序付けを意味しないことに留意されたい。HFスクリプトは、第2のトランザクションTx2のロック解除スクリプトと並行して実行されたときに、ロック解除スクリプトに含まれる入力(「ターゲット入力」)のハッシュ(「ハッシュ結果」)を生成(すなわち、計算、算出など)するように構成されたスクリプトの一部である。ターゲット入力は、数値、文字列など、任意のタイプのデータ項目であってよい。たとえば、ターゲット入力は、公開鍵であり得る。第1のロックスクリプトは、HFスクリプトからなり得るか、またはHFスクリプトおよび1つもしくは複数のデータ項目および/もしくはスクリプトの追加部分を含み得る。たとえば、HFスクリプトは、より大きなスクリプトの一部を形成し得る。

【0088】

図5において、第2のトランザクションTx2は、ボブ103bによってブロックチェーンネットワーク106に伝送されているものとして図示されている。また、第2のトランザクションTx2がアリス103aによってブロックチェーンネットワーク106にサブミットされ得ることも排除されない。

【0089】

HFスクリプトは、少なくとも4つの数学的演算を実行するように構成されている。各演算は、ブロックチェーンスクリプト言語(たとえば、Bitcoin Script)の単一関数(たとえばオペコード)によって実行され得る。代替的に、演算のいくつかまたはすべては、複数の関数によって実行され得る。第1の演算は、ターゲットデータ項目に第1のパラメータを乗算することによって第1の中間結果を計算することを含む。第1の演算は、前記乗算からなるものとしてよい。代替的に、第1の演算は、1つまたは複数の付加的な副演算(たとえば、加算、減算など)を伴い得る。第2の演算は、第2のパラメータを第1の中間結果に加算することによって第2の中間結果を計算することを伴う。第2の演算は、前記加算からなるものとしてよい。第3の演算は、第3のパラメータを使用して第2の中間結果に対して第1のモジュロ演算を実行することに基づき第3の中間結果を計算することを伴う。言い換えると、第3の中間結果は、第2の中間結果を第3のパラメータで除算した後の余りに基づく。第3の演算は、前記第1のモジュロ演算からなるものとしてよい。第4の演算は、第4のパラメータを使用して第3の中間結果に対して第2のモジュロ演算を実行することに基づきハッシュ結果を計算することを伴う。言い換えると、第4の中間結果は、第3の中間結果を第4のパラメータで除算した後の余りに基づく。第4の演算は、前記第2のモジュロ演算からなるものとしてよい。いくつかの例では、HFスクリプトによって実施されるハッシュ関数は、ユニバーサルハッシュの定義(定義4)を満たすので、「ユニバーサルハッシュ関数」と称され得る。

【0090】

たとえば、HFスクリプトは以下の形式を取り得る。
<a> OP_MUL <b> OP_ADD <p> OP_MOD <n> OP_MOD,
ここで、aは第1のパラメータであり、bは第2のパラメータであり、pは第3のパラメータであり、nは第4のパラメータである。当業者であれば、このオペコードを熟知しているであろう。

【0091】

HFスクリプトは、第1の中間結果、第2の中間結果、第3の中間結果、および第4の中間結果のうちの1つ、いくつか、またはすべてを出力するように構成され得る。たとえば、結果は、メモリに出力され得る。スクリプト言語がスタックベースのスクリプト言語である場合、メモリはメモリスタックであり得る。いくつかの例において、ハッシュ結果のみが、たとえばメモリに出力される。

【0092】

第1のパラメータaは、0でない任意の数であってよく、ランダムに選択され得る。第2のパラメータbは、任意の数であってよく、ランダムに選択され得る。第3のパラメータpは、任意の正の数、たとえば、特定の楕円曲線に関連付けられる素数などの素数であってよい。たとえば、pは、いくつかのブロックチェーンによって使用されるSecp256k1楕円曲線を定義する素数であってよい。第4のパラメータnは2^Lの形式を取り、Lはハッシュ結果の長さを定義するように選択される。一般に、Lは、任意の好適な数、たとえば160、256、512などであってよい。パラメータのいくつかの例示的な値のさらなる詳細は、以下でさらに提供される。

【0093】

いくつかの実施形態において、第1のロックスクリプトは、予期されたハッシュ結果を含み得る。予期されるハッシュ結果は、予期されるデータ項目(たとえば、予期される値)にユニバーサルハッシュ関数を適用することによって生成される。ここで、「予期される」は、予め決定されていることを意味する。アリス103aは、予期されるハッシュ結果を自分で生成し得るか、または他の場所、たとえば異なる当事者、ブロックチェーンそれ自体、ウェブページなどから入手してもよい。ユニバーサルハッシュ関数は、予期されるデータ項目「オフチェーン」、すなわちブロックチェーントランザクションを使用しないことに適用される。たとえば、予期されるハッシュ結果は、アリスのコンピューティング機器105a上で計算され得る。

【0094】

第1のロックスクリプトは、予期されるハッシュ結果と一致するようにHFスクリプトによって(すなわちスクリプト実行中に)生成されたハッシュ結果を必要とするように構成される。すなわち、第1のブロックチェーントランザクションの第1のロックスクリプトをロック解除する第2のトランザクションTx2のロック解除スクリプトの条件は、ロック解除スクリプトが予期されるデータ項目を含み、予期されるデータ項目が予期されるハッシュ結果にハッシュすることである。これは、ハッシュパズルを使用して実施され得る。ハッシュパズルを実施すること自体は、当業者にはおなじみであろう。

【0095】

予期されるデータ項目は、予期される公開鍵、たとえばBobの公開鍵PK_Bであってもよい。この例では、予期されるハッシュ結果は、ブロックチェーンアドレスとして使用され得る。予期されるデータ項目が予期される公開鍵であることを要求するだけでなく、第1のロックスクリプトは、Tx2のロック解除スクリプトが予期される公開鍵に対応する秘密鍵を使用して生成する署名を含むことを必要とし得る。たとえば、第1のロックスクリプトは、ロック解除スクリプトが、Bobの公開鍵PK_B(予期されるハッシュ結果にハッシュする)およびBobの秘密鍵sk_Bを使用して生成されたBobの署名を含むことを必要とし得る。この形式のロックスクリプトは、Pay-to-Public-key-hash(P2PKH)スクリプトと称されることが多い。しかしながら、第1のブロックチェーントランザクションは、必ずしもボブ103bへの支払いを伴う必要はなく、一般に、ボブ103bにメッセージを送信すること、ブロックチェーン150上にデータを記憶することなど、任意の目的に使用され得ることに留意されたい。

【0096】

たとえば、第1のロックスクリプトは以下の形式を取り得る。
OP_DUP [UHF_a,b,p,n] <UHF_a,b,p,n(PK)>OP_EQUALVERIFY OP_CHECKSIG
ここで、[UHF_a,b,p,n]はHFスクリプトの略記であり、<UHF_a,b,p,n(PK)>はユニバーサルハッシュ関数(UHF)を予期される公開鍵に適用することによって生成される予期されるハッシュ結果である。

【0097】

したがって、第1のロックスクリプトは、ロック解除スクリプトが次に示す形式を取ることを必要とする。
<Signature> <PK>
これは、標準P2PKHスクリプトと同じである。

【0098】

これまでは、P2PKHスクリプトは次に示す形式を取っていた。
OP_DUP OP_HASH160 <HASH160(PK)> OP_EQUALVERIFY OP_CHECKSIG

【0099】

このスクリプトでは、OP_HASH160は、所与の公開鍵PKを受け取り、そのハッシュ値を出力する。このハッシュ値は、次いで、スクリプト<HASH160(PK)>で与えられる予期されるハッシュ値と比較される。HASH160は、合成関数(すなわち、アルゴリズム)であり、以下のように記述され得る。
1.SHA256を入力公開鍵に適用する。
2.RIPEMD160をステップ1の出力に適用する。
3.プレフィックスをステップ2の出力に適用してネットワークタイプ(mainnet、testnet、regtest)を指示する。
4.二重SHA256(double SHA256)をステップ3の出力に適用する。
5.ステップ4の出力の最初の8バイトをチェックサムとして取る。
6.チェックサムをステップ3の出力に加える。
7.base58エンコーディングをステップ6の出力に適用する。

【0100】

ステップ7は可逆であることに留意されたい。すなわち、ステップ7の出力が与えられた場合、base58デコーディングを適用してステップ6の出力を出すことができる。しかしながら、使用されている暗号学的関数の一方向性により、入力公開鍵を取得する道筋をすべて逆に辿ることは計算上不可能である。

【0101】

ロックスクリプトでHASH160を使用する主な目的は、予期される公開鍵のみがロック解除スクリプトで使用されることを確実にすることである。上に示されているように、HASH160は、4つのハッシュ(1つのSHA256、1つのRIPEMD160、および1つの二重SHA256)を必要とする。HFスクリプトによって実施されるユニバーサルハッシュ関数は、より少ない計算で同じ結果を達成する。また、HFスクリプトは、1回の乗算、1回の加算、2回の剰余演算のみを伴うので、P2PKHにおけるHASH160よりかなり効率的である。

【0102】

ここでHFスクリプトのパラメータに戻ると、いくつかの例では、第3のパラメータpは、
y²=x³+7 mod p
が成り立つ、Bitcoinで使用されている楕円曲線であるSecp256k1に付属する素数となるように選択され、
ここで、p=2²⁵⁶-2³²-2⁹-2⁸-2⁷-2⁶-2⁴-1である。

【0103】

第4のパラメータは、関数の出力がHASH160の出力と同じ長さを有するようにn=2¹⁶⁰として選択され得る。

【0104】

第1および第2のパラメータaおよびbは、ユーザによって

【数4】

からランダムに選択され得るが、ただし、aが0でなく、

【数5】

である。aの範囲およびサイズが衝突確率に影響することに留意されたい。これについて以下で説明する。

【0105】

次に、qは、q個の点を含むSecp256k1によって定義される群の位数を示すために使用され、qは素数である。これは、q-1個の非恒等点があることを意味する。いずれも位数2を有しないので(qは奇素数なので)、各点はそれ自身と等しくない逆数を有すると結論づけることができる。これは、異なるx座標を有する(q-1)/2個の非恒等点があり、これはi=1,...,(q-1)/2について(x_i,±y_i)と表され得る。

【0106】

公開鍵は、(x_i,+)または(x_i,-)として圧縮形式で表され得る。Secp256k1を知っていることで、y座標が何であるかを計算し、その符号を使用して一意的なy値を識別することができる。われわれはx_i∈[0,p-1]を仮定し、(x_i,-)に対するユニバーサルハッシュ関数の入力として-x_iを使用する。

【0107】

これは、ユニバーサルハッシュ関数の入力空間

【数6】

を確立するが、ただし、m=pおよび|D|=q-1である。これらの表記を用意して、次の主張を行うことができる。

【0108】

h=UHF_a,b,p,n(x)が与えられた場合、UHF_a,b,p,n(x')=hとしてランダムに選択された公開鍵x'∈Dである確率は

【数7】

より小さい。

【0109】

n=2¹⁶⁰である場合、確率は

【数8】

より小さく、無視できることに留意されたい。このことは、これが衝突困難を達成することができ、一方向性要件を落とすことによってHASH160よりも高い効率を達成できることを意味している。一方向性は離散対数問題により自然に得られ、これは次の証明の後に詳しく説明される。

【0110】

公開鍵x'∈Dがランダムに選択される場合、式UHF_a,b,p,n(x')=hを満たすx'の数が|D|/nより小さいことを示すだけでよい。

【0111】

解く必要がある制約条件を有する式は、以下の通りである。
ax'+b≡h mod p mod n (1)
ただし以下を条件とする。
1≦a<≦p-1 (2)
0≦b≦p-1 (3)
0≦h≦n-1 (4)
-p<x'<p (5)

【0112】

最後の不等式は、x'の解の数を数えるのに必要な範囲である。前に説明されているように、xの符号はy座標がどの値を取るかを示す。第1のステップは、合同算術を整数演算に変換することである。以下が成り立つ整数k₁が存在する。
ax'+b≡h+k₁n mod p (6)
-p<h+k₁n<p (7)

【0113】

(4)および(7)から、

【数9】

を得る。

【0114】

k₁の可能な値の数は、したがって

【数10】

によって制約される。

【0115】

同様に、以下が成り立つ整数k₂が存在する。
ax'+b=h+k₁n+k₂p (9)

【0116】

(2)、(3)および(5)から、
-ap<ax'+b<ap+p (10)
を得る。

【0117】

(7)と(9)とを組み合わせて、次が得られる。
-ap-p<k₂p<ap+p (11)
-a-1<k₂<a+1 (12)
(9)は、また、h-b+k₁n+k₂pがaで除算可能であり、以下のように書き換えることができる。
h-b+k₁n+k₂p≡0 mod a (13)

【0118】

k₁の任意の選択された値について、k₂≡-(h-b+k₁n)p^-1 mod aがある。これは、k₂∈[0,a)の一意解、および[-a,a]内の最大の別の2つの解を与える。k₂=0が解であるときに、aと-aは別の2つの解である。(12)からの制約が与えられた場合、k₂が取り得る値の最大数は3であると結論され得る。したがって、x'が取り得る値の総数は、

【数11】

によって制約される。

【0119】

したがって、式UHF_a,b,p,n(x')=hを満たすランダムに選択された公開鍵x'の確率は、

【0120】

【数12】

【0121】

によって制約される。

【0122】

最後の不等式は、p<2q-2および|D|=q-1であるという事実から導かれ、pはSecp256k1からの素数であり、qは対応する群の位数である。

【0123】

結果は、

【数13】

の形式の確率の上界を残すことによって一般化され得ることに留意されたい。
ここで、pおよびnはユニバーサルハッシュ関数における法であり、|D|は入力空間のサイズである。

【0124】

さらに、公開鍵がランダムに選択されることがなぜ仮定され得るか正当化することもできる。所与のユニバーサルハッシュ出力に一致する公開鍵を計算するのは簡単である。しかしながら、その公開鍵に対する秘密鍵を計算するのは計算的に実現不可能である。したがって、所与のユニバーサルハッシュ出力に対応する署名を生成するのを成功させるためには、まず最初に秘密鍵を生成し、次いで対応する公開鍵が一致するハッシュ値を有するかどうかをチェックしなければならない。離散対数問題の困難性を仮定すると、この文脈では公開鍵はランダムにしか選べないと言える。

【0125】

上記の説明では、スクリプトにおいてHASH160の代わりにユニバーサルハッシュ関数を使用することは、衝突の確率が無視できるくらいに小さくできるという意味で安全であることの証明を提示している。さらに、一方向性は、ECDSA署名からの離散対数問題を通して効果的に達成され得ることが正当化された。したがって、いくつかの実施形態は、ユニバーサルハッシュ関数を使用するP2PKHスクリプトのより効率的な実施形態を提供する。

【0126】

図6は、公開鍵をインスクリプトで生成するための例示的なシステム600を例示している。これらの実施形態では、第1のトランザクションTx1の第1のロックスクリプトは、公開鍵導出(PKD)スクリプトを含み得、PKDスクリプトは、HFスクリプトを含み得る。PKDスクリプトは、実行されたときに、第2のトランザクションTx2のロック解除スクリプトに含まれる親公開鍵PK_parentに基づき子公開鍵PK_childを生成するように構成される。すなわち、第2のトランザクションのロック解除スクリプトは、親公開鍵PK_parent、たとえばアリス103aまたはボブ103bによって所有される公開鍵を含むものとしてよく、PKDスクリプトは、親公開鍵PK_parentの子公開鍵PK_childを計算するように構成される。これらの例では、ターゲットデータ項目は、親公開鍵のチェーンコードc_parentと、親公開鍵PK_parentと、子公開鍵のインデックスとを含む。第1のロックスクリプトは、子公開鍵PK_childを、たとえばスタックなどのメモリに出力するように構成され得る。

【0127】

図7は、HDウォレットとしても知られている、鍵の階層的決定論的(HD)セットの一例を例示している。ここで、マスター鍵はシードに基づき生成される。子鍵の各セット内の子鍵は、各々マスター鍵に基づき生成される。孫鍵の各それぞれのセット内の孫鍵は、各々子鍵のそれぞれのセットに基づき生成される。この例では、マスター鍵は親鍵である。しかしながら、「親」および「子」というラベルは、第nのレベルの公開鍵および第(n+1)のレベルの公開鍵を指すために使用されてよく、第(n+1)のレベルの公開鍵は、第nのレベルの公開鍵に基づき生成される。

【0128】

PKDスクリプトは、式
PK_child=PK_parent+UHF_a,b,p,n(c_parent||P_parent||index)・G
を使用して子公開鍵を生成するように構成され得る。
ここで、UHF_a,b,p,nはHFスクリプトによって実施され、c_parent||P_parent||indexはターゲットデータ項目であり、UHF_a,b,p,n(c_parent||P_parent||index)はハッシュ結果である。上記の式からわかるように、PKDスクリプトは、ハッシュ結果と生成点Gの点乗算(・)を実行するように構成される。PKDスクリプトは、また、その乗算の結果と親公開鍵との点加算(+)を実行するように構成される。

【0129】

いくつかの例では、PKDスクリプトは、式

【数14】

を使用して子公開鍵を生成するように構成され得、
ここで、

【数15】

は、HFスクリプトによって生成されたハッシュ結果の左256バイトである。この例では、n=2⁵¹²であることに留意されたい。

【0130】

一例として、PKDスクリプトは、擬似形式

【数16】

を取ることができ、
ここで、入力は親チェーンコード、インデックス、親公開鍵であり、結果は上で説明されているように子公開鍵となる。

【0131】

HFスクリプトフラグメント

【数17】

は、端順に、
<a> OP_MUL <b> OP_ADD <p> OP_MOD <n⁵¹²> OP_MOD
として実施され得る。
ここで、aおよびbは、少なくとも512ビットの整数であり、理想的には、pは出力の一様分布を保証するためにnの倍数となるように選択される。[Hex to binary]、[Point scalar multiplication]、および[Point addition]は、擬似スクリプトで、以下にその例を示す。

【0132】

PKDスクリプトは、HDウォレットの代替子鍵として使用され得る。ビットコイン改善提案(BIP)32 HDウォレットは、ブロックチェーンエコシステムにおいて広く使用されている。これは、単一の秘密シードから多数のECDSA鍵ペアを導出するためのメカニズムを提供する。鍵導出アルゴリズムは、HMAC-SHA512を使用し、親チェーンコード、親公開鍵、およびインデックスから256ビットの2つの文字列、HMAC-SHA512_L (c_parent,P_parent∥index)およびHMAC-SHA512_R(c_parent,P_parent∥index)を生成する。左256ビット文字列は、子鍵ペア導出において使用され、右256ビット文字列は、さらなる鍵ペア導出のためのチェーンコードとして使用される。BIP32に対してHMAC-SHA512が選択される理由は、出力の必要なビット長を提供すること以外には明確ではない。HMAC-SHA512は、当事者間のメッセージの真正性および完全性を保証するための対称認証スキームとして設計されている。HDウォレットのコンテキストでは、真正性や完全性の要件はない。したがって、HMAC-SHA512は、n=2⁵¹²のユニバーサルハッシュ関数で置き換えられ得る。SHA512はブロックチェーンスクリプト言語のオペコードとして利用可能でなかったのでこれまでは実現不可能であった階層的決定論的方法でのインスクリプト鍵導出を可能にする。

【0133】

チェーン上で明示的に鍵を導出することの利点は、所有する2つの公開鍵の間のリンクを当事者が証明することができることであり、したがってその証明の不変の記録が存在することである。これは、公開鍵基盤(PKI)の文脈において特に有用であり、単一の公開鍵(たとえば、恒等鍵)が認定され得る。たとえば、ある当事者は、トランザクションに署名するのに使用された公開鍵が、認定された公開鍵にリンクされていることを証明することができる。リンクがチェーン上にあることのこの証明により、関係する公開鍵が拡張により認定され得る。

【0134】

チェーン上の子公開鍵を計算するもう1つの利点は、この子公開鍵はトランザクションを署名するのに使用され得るが、チェーン上に決して明示的に記憶されることはないという点である。その結果、敵対者が所与の子公開鍵を含むトランザクションを探している場合に、この方法を使用するトランザクションを見つけず、したがってプライバシーが高まる。

【0135】

上で提示されているPKDスクリプトの例に戻る。第1のオペコードOP_DUP <0x20> OP_SPLIT OP_SWAP OP_ROTは、入力された親鍵P_parentを複製するが、親鍵が子鍵P_childの計算で2回必要になるからである。これは、次いで、コピーをそれぞれ左32バイトおよび右32バイトに対応するそのx座標とy座標とに分割し、これらをスタックの一番下に置くが、これが最終的な関数[Point addition]に対する必要な形式であるからである。これらのオペコードが実行された後、スタックの状態は以下のようになる。

【表1】

【0136】

次いで、HFスクリプトフラグメント

【数18】

は、実行される。この関数が実行された後、スタックの状態は以下のようになる。

【表2】

【0137】

次いで、次のオペコード<0x20> OP_SPLIT OP_DROPは、HFスクリプトの結果の右32バイトを削除する。次にこの点の後のスタックの状態は、次のようになる。

【表3】

【0138】

次いで、その結果得られる数

【数19】

は、16進数から2進数に変更される。ハッシュ結果がすでに2進数である場合には、この変換は必要ないことに留意されたい。次に、[Point scalar multiplication]を計算するために、関数への入力は、2進数である必要があり、したがって関数(すなわち2進数変換スクリプト)がHMACの16進数の結果を各々2進数を表すバイトに変換するように定義される。この概念に対する例示的なスクリプトが、図8に示されている。

【0139】

次に、実行されたときの[Hex to binary]関数の例が例示されている。この例では、16進数の<0x07>が2進数の0111に変換される。この場合、n=1である。左側の列はスタックを表し、右側の列はオルトスタック(altstack)を表す。スタックの流れは左から右へ、次いで上から下へである。

【表4】

【0140】

この関数は、16進数<0x07>を2進数<0x00010101>に変換し、各バイトは1ビットを表す。0xというプレフィックスは、それに続くバイトが16進数であることを示し、したがって<0x00010101>は実際には2進数では0x07と等価ではないが、次のオペコードがこの表現を読み取る方法ではそのようなものとして取り扱うことに留意されたい。これが書かれている通りに正確に読み取られる場合、<0x00010101>は10進数の65793と等価である。関数[Hex to binary]の実行後のスタックの状態は次の通りである。

【表5】

【0141】

関数[Hex to binary]は結果として、各バイトが現在1ビットを表している文字列をもたらす。この特定の例示的なPKDスクリプトについて、文字列は、オペコード
[OP_1 OP_SPLIT OP_SWAP]²⁵⁶
を使用して配列に分割されなければならず、
角括弧のべき乗は、これが繰り返されるべき回数を示し、この場合は256回である。この結果、長さ256の2進数配列が得られ、最下位ビットを表すバイトはスタックの一番上にある。配列内の各バイトは1ビットを表し、<0x01>または<0x00>のいずれかである。上で説明されているプロセスは、2進数への変換で2進数表現を連結し、次いでその結果を配列に分割することを伴う。この分割に対する理由は、結果がリトルエンディアン形式である必要があることである。この結果は、連結しなくても達成され得るが、スタックの深さを追跡し、順序を保ちながらスタック項目を一番上に持ってくる必要がある。上記のスクリプトで達成されるように、結果を1つの文字列に連結し、オルトスタックを利用し、その後それを分割するのがかなり単純である。

【0142】

次は、Scriptにおいて点スカラー乗算を実行する方法の一例を例示している。[Point scalar multiplication]関数(すなわちPSMスクリプト)。[Point scalar multiplication]関数は、HMAC関数の結果(いくつかの例では、HMAC関数の結果の左32バイトのみ)を2進数表現として受け取り、

【数20】

を返す。表記を簡単にするため、定義

【数21】

が使用される。次いで、対応する点q・Gが計算され得る。スクリプトでq・Gを計算するには、まず最初に、q₀=2⁰・G、q₁=2¹・G、...、q₂₅₅=2²⁵⁵・Gを事前計算する。これは、0≦q<2²⁵⁶に対する任意の可能なq・Gの計算を可能にする。これは、2進数表現を入力として取ると、2進数表現の第iの桁が1であれば、対応する2ⁱがq・Gの計算の現在の状態に追加される。第iの桁が0である場合、対応する2ⁱはq・Gの計算の現在の状態に加えられない。これを達成するための例示的なPSMスクリプトが、図9に例示されている。リトルエンディアン2進数配列の形式の入力qを仮定すると、図9の例示的なスクリプトは、q・Gを計算し、ここで、<q_i(x)>は2ⁱ・Gのx座標を表し、<q_i(y)>は2ⁱ・Gのy座標を表す。

【0143】

この関数は、qの対応するビットが1に等しいときに点2ⁱ・Gをq・Gの現在の状態に加える。この関数は、以下で説明される[Point addition](すなわち点加算スクリプト)を使用する。[Point scalar multiplication]関数は、<0x00><0x00>をスタックにプッシュすることから始まるが、その目的は、この場合には恒等元である、初期点として作用することである。[Point addition]は、入力として2つの点を取るので、最初に<0x00><0x00>をスタックにプッシュしないと、これの最初の実行では、入力が1つしかなく、その結果エラーになる。要するに、<0x00><0x00>は恒等元であるが、それは、[Point addition]は、一方の点が<0x00><0x00>である場合にこの関数が他方の点を単純に出力するだけであるように定義されているからである。この表記を恒等元として選択することが安全である理由は、点(0,0)がsecp256k1楕円曲線上の点ではないからであることに留意されたい。次にこの点でのスタックの状態は、次のようになる。

【表6】

ここで、一番上の2つの項目は、q・Gの計算の結果のxおよびy座標である。

【0144】

[Point addition]関数は、子鍵導出で使用される最終的な関数である。これは、[Point scalar multiplication]の結果と、[P_child derivation]関数の最初のいくつかのオペコードで重複していたことからスタックの一番下に収められていたP_parent鍵を取り、P_childをスタックに返す。完全な関数を定義する前に計算される必要のある関数がいくつかある。これらは、以下の通りである。
・[Inverse mod p]
・[Different Point addition]
・[Same Point addition]

【0145】

まず最初に、2つの点の加算で使われる、スクリプト内のpを法とする逆数の一例が説明される。フェルマーの小定理によれば、m^-1=m^p-2 mod pである。ここでのpはHFスクリプトの第4のパラメータと同じではないことに留意されたい。入力pが既知であると仮定すると、図11に示されているコードは、pを法とするmの逆数を求める、すなわち、m^p-2 mod pを計算するために使用され得る。<p_n-1><p_n-2>...<p₀>は、配列を表し、配列の各項目は(p-2)の2進数インデックスに対応する、すなわち、p'=p-2=p₀2⁰+p₁2¹+...+p_n-12^n-1であり、図10のオペコードは、入力<m>が与えられた場合に関数[Inverse mod p]を計算する。

【0146】

この例では、nはpの2進数長である256である。OP_ROLLと組み合わされたオペコード<(n+1)>は、p-2の2進数配列がスタックにプッシュされた後、<m>をスタックの一番上に移動する。この時点でp-2はスタックにプッシュされ、この逆関数が自己完結的なものとなり、したがって他の場合にも簡単に適用され得ることを確実にする。ここでもまた、角括弧のべき乗の表記は、このコードが繰り返される回数を示している。

【0147】

図11は、点加算を実行するための例示的なスクリプトを例示している。この場合、例示的なスクリプトは、2つの異なる点の加算を実行する。2つの異なる点を加算するときに、入力は、<y₂><x₂><y₁><x₁>であり、各座標は32バイトの16進数である。次いで、図12のコードは、関数[Different Point addition]を計算し、<y₃><x₃>をスタックに返す。次に、図11のコード内のすべての行の終わりにおけるスタックの状態を例示している。スタックの状態は、入力から始まり、次いで例示的なコードの各行が順に実行される。

【表7】

これは、スクリプトで異なる点を加算する計算を完了させる。

【0148】

図12は、点加算を実行するための別の例示的なスクリプトを例示している。この場合、例示的なスクリプトは、同じ点の加算を実行する。2つの同じ点を加算するときに、入力は、<y₁><x₁><y₁><x₁>であり、各座標は32バイトの16進数である。次いで、図12のコードは、関数[Same Point addition]を計算し、<y₂><x₂>をスタックに返す。次に、図12のコード内のすべての行の終わりにおけるスタックの状態を例示している。スタックの状態は、入力から始まり、次いで例示的なコードの各行が順に実行される。a(HFスクリプトの最初のパラメータと同じでない)は、楕円曲線によって定義される定数であり、この例ではsecp256k1であり、したがってa=7であることに留意されたい。

【表8】

【0149】

図13は、点加算を実行するための別の例示的なスクリプトを例示している。この場合、例示的なスクリプトは、加算されるべき2つの点が同じ点であるか異なる点であるかのチェックを実行し、しかるべく動作する。図13内の太字のテキストは、コードのその行が何をしているかを説明するものであり、数字(i)は上で与えられている点加算の定義に対応していることに留意されたい。入力は、<y₂><x₂><y₁><x₁>の形式を取ると仮定され、各座標は32バイトの16進数である。

【0150】

第1の行は第2の点が<0x00><0x00>であるかどうかのチェックであり、これは選択された表記では無限遠の点であるが、それはこの点がsecp256k1曲線上にないことが知られているからである。第2の点が無限遠の点である場合、第1の点<y₁><x₁>がスタックに戻され、これは点加算の定義(4)に対応する。例示的なコードにおいて、無限遠の点は、第2の点としてのみ現れることに留意されたい。

【0151】

次いで、第1のOP_ELSEの中の第1の行は、x座標が等価であるかどうかをチェックする。等価であれば、y座標も等価であるかどうかのチェックが実行される。そうであることが分かった場合、y=0かどうかのチェックが実行され、その場合、無限遠の点が返され、これは点加算の定義(3)に対応する。y≠0である場合、このコードは点をそれ自体に加え、これは上で定義されている関数[Same Point addition]であり、点加算定義の定義(2)に対応する。次に、y値が異なる場合、点は互いに逆でなければならず、無限遠の点を返すので、<0x00><0x00>が返される。これは、点加算の定義(3)に対応する。最後に、x値が異なる場合、このコードは、異なる点加算[Different Point addition]を実行し、これは点加算の定義(1)に対応する。

【0152】

これは、スクリプトにおける点加算の計算を完了させ、最終的にスクリプトにおける子鍵の計算を完了させる。スタックの最終状態は、次のようになる。

【表9】

【0153】

図14は、スタック上のデータを圧縮鍵形式に変換するための例示的なスクリプトを例示している。この例示的な関数は、鍵のxとy座標を入力として取り、圧縮された公開鍵形式を返す。入力<P(y)><P(x)>に対して、図14のオペコードは、関数[Compressed Key format]を定義する。最初の3つのオペコードは、子鍵のy座標が偶数か奇数かをチェックする。次いで、この結果に応じて、次のオペオペコードは、正しいプレフィックスをx座標に付加する。この結果、圧縮された子鍵が得られ、スタックの最終状態は次のようになる。

【表10】

【0154】

代替的に、実際に、非圧縮形式の結果が望ましい場合、関数
[Uncompressed Key format]= OP_SWAP OP_CAT <0x04> OP_SWAP OP_CAT
が使用され得る。

【0155】

いくつかの実施形態において、HFスクリプトは、ルックアップテーブルに使用され得る、鍵値ペアの鍵を生成するために使用され得る。ウォレットを含む、多くのアプリケーションは、消費済み、未消費、またはアプリケーション関係公開鍵を識別するために効率的なルックアップ操作を必要とする。ルックアップテーブルを構築するための効率的な方法の1つは、ユニバーサルハッシュ関数を使用して鍵値ペアの鍵を作成することである。上で説明されているインスクリプトユニバーサルハッシュアプローチは、鍵値ペアの鍵のコピーを効果的にチェーン上に置く。これは、同じ鍵(ハッシュ値)を共有するので、ローカルルックアップテーブルへのシームレスな統合を可能にする。公開鍵の量が少ないアプリケーションについては、チェーン上に完全な値を維持しながらハッシュ値を切り詰めることによってユニバーサルハッシュ出力のバイト数を減らすことができる。

【0156】

たとえば、アリス103aは、予期されるハッシュ結果、または予期されるハッシュ結果の略記バージョン(たとえば、第1の4つの先行バイト)を、対応する予期される公開鍵および/または第1のトランザクションのトランザクション識別子と一緒にルックアップテーブル内に記憶する(すなわち、マッピングされる)。言い換えると、(略記された)予期されるハッシュ結果は、鍵値ペアの鍵であり、値は予期される公開キーおよび/またはトランザクション識別子である。ルックアップテーブルは、異なるハッシュ結果、公開鍵、およびトランザクション識別子に対するこのタイプの複数の鍵値ペアを含み得る。アリス103aは(略記された)予期されるハッシュ値をルックアップとして使用し、対応する公開鍵および/またはトランザクション識別子を見つけるものとしてよい。

【0157】

これまで説明されている例では、所与の公開鍵に対して単一の予期されるハッシュ結果を生成することだけを考えてきた。すなわち、これらの例は、<UHF_a,b,p,n(PK)>を生成することだけを説明してきたが、ここで<UHF_a,b,p,n(PK)>は、予期される公開鍵PKにユニバーサルハッシュ関数(UHF)を適用することによって生成される予期されるハッシュ結果である。これは、トランザクションの出力を公開鍵にロックするために使用され、公開鍵および(任意選択で)対応する署名が、出力をロック解除するために必要とされる。次に、UHFを使用して、所与の公開鍵に対する複数の予期されるハッシュ結果を導出する方法について説明する。これらの予期されるハッシュ結果は、ブロックチェーンアドレスと称される。

【0158】

上で説明されているように、UHFは、a、b、n、およびqの4つのパラメータに依存する。上記の例では、パラメータの固定されたセットによりUHFを公開鍵に適用することによって公開鍵から単一のアドレス(予期されるハッシュ結果)がどのように生成され得るかを説明している。次に、パラメータの値を変更することによって、同じ公開鍵から複数のアドレスが導出され得る。すなわち、パラメータa、b、n、およびqの値が、異なるアドレスを生成するために変更され得る。いくつかの例では、単一のパラメータのみが変更される。他の例では、複数のパラメータの複数の値が変更される。たとえば、すべてのパラメータの値が変更されてもよい。

【0159】

アドレスは、パラメータaのすべての可能な値に対して生成され得る。同様に、アドレスは、パラメータbのすべての可能な値に対して生成され得る。いくつかの例において、アドレスは、aおよびbのすべての可能な組合せに対して生成され得る。これらの例では、パラメータnおよびqの値は固定され得る。代替的に、パラメータnおよびqの値は可変であってよい。

【0160】

パラメータは、上で説明されている任意の値を含む、任意の好適な値を取り得る。

【0161】

異なるアドレスは、異なるトランザクション出力をロックするために使用されてもよい。たとえば、同じトランザクションの1つまたは複数の出力は、同じ公開鍵から導出されたアドレスのうちの異なる1つのアドレスを使用してロックされ得る。それに加えてまたは代替的に、1つまたは複数の異なるトランザクションの1つまたは複数の出力は、同じ公開鍵から導出されるアドレスの異なる1つのアドレスを使用してロックされ得る。

【0162】

出力をロックするロックスクリプトは、上で説明されているのと同じ形式を取る。たとえば、ロックスクリプトは、以下の形式を取り得る。
OP_DUP [UHF_a,b,p,n]<UHF_a,b,p,n(PK)>OP_EQUALVERIFY OP_CHECKSIG
ここで、[UHF_a,b,p,n]は、
<a> OP_MUL <b> OP_ADD <p> OP_MOD <n> OP_MOD
に対する略記である。

【0163】

a、b、n、およびqの値は、ロックスクリプトで定義され、対応するアドレスを生成するために使用される値に対応する。すなわち、アドレスを生成するために使用されるパラメータの値は、その同じアドレスを含むロックスクリプト内に現れる値と同じ値である。

【0164】

対応するロック解除スクリプトは、以下の形式を取る。
<Signature> <PK>

【0165】

ロック解除スクリプトの形式は、各アドレスについて同じままであることが分かる。すなわち、アドレスは、アドレスを導出するために使用されるパラメータに応じて変わるけれども、ロックスクリプトは、アドレスが導出される公開鍵および公開鍵に対応する署名(すなわち、公開鍵に対応する秘密鍵を使用して生成される)を使用してそのままロック解除される。

【0166】

再び図5を参照すると、アリス103aは、ボブの同じ公開鍵を使用して複数のアドレスを生成し得る。各アドレスは、ユニバーサルハッシュ関数を使用して公開鍵をハッシュすることによって生成され、UHFの少なくとも1つのパラメータの値は、異なるアドレス毎に変更される。アリス103aによって生成され、ネットワーク106にサブミットされる第1のトランザクションは複数の出力を含むものとしてよく、出力の各々は出力をアドレスの1つにロックするロックスクリプトのインスタンスを含む。すなわち、ロックスクリプトは、アドレスを含み、HFスクリプトによってハッシュされアドレスを与える公開鍵を含むロック解除スクリプトを必要とする。それに加えて、または代替的に、アリス103aは、1つまたは複数の追加トランザクションを生成し得る。各トランザクションは、ボブの公開鍵から導出されるアドレスの1つにロックされた少なくとも1つの出力を含む。

【0167】

いくつかの例において、アドレスは、ユニバーサルハッシュ関数の結果を暗号学的ハッシュ関数でハッシュすることによって生成され得る。すなわち、アリス103aは、ユニバーサルハッシュ関数を使用して複数のアドレスを導出し(ここでもまた、異なる各アドレスを生成するためにUHFの1つまたは複数のパラメータの値を変更する)、次いで暗号学的ハッシュ関数を使用してそれらのアドレスの各々をハッシュするものとしてよい。便宜上、UHFによって出力されるアドレスは、ここで「中間アドレス」または「中間ハッシュ結果」と称される。したがって、アリス103aは複数の異なる中間アドレスを生成し、各中間アドレスをハッシュして対応する最終アドレスを生成する。これらの例では、ブロックチェーンアドレス、すなわちブロックチェーントランザクションの出力内に現れるアドレスとして使用されるのは最終アドレスである。

【0168】

これらの例では、各ロックスクリプトは、中間アドレスを生成し、次いで中間アドレスをハッシュして最終アドレスを生成するように構成されている。最終アドレスは、ロックスクリプトに含まれる予期される最終アドレスと比較される。ロックスクリプトの形式に応じて、UHFのパラメータは、ロックスクリプトではなくむしろロック解除スクリプトに含まれ得る。一例が以下に与えられている。

【0169】

暗号学的ハッシュ関数は、任意の好適なハッシュ関数であってよい。たとえば、暗号学的ハッシュ関数は、RIPEMD160、SHA256、SHA512などであってよい。いくつかの例において、暗号学的ハッシュ関数は、複数のハッシュ関数の組合せであってもよい。たとえば、暗号学的ハッシュ関数は、最初にSHA256でハッシュし、次いでRIPEMD160でハッシュするHASH160であってもよい。

【0170】

単一のアドレスを生成する場合について上で説明されているように、アリス103aは、参照を容易にするために複数の異なるアドレス(中間アドレスおよび/または最終アドレス)をルックアップテーブル内に記憶してもよい。アドレスは、インデックス、またはアドレスが導出される公開鍵に関連付けられ得る。

【0171】

8. インデックスハッシュ
このセクションでは、説明されている実施形態のさらなる例を提示する。

【0172】

8.1 暗号学的ハッシュ
暗号学的ハッシュ関数は、任意のサイズの入力から予測不可能な固定長の出力を生成する一方向性関数である。暗号学的ハッシュ関数は、ビットコイントランザクションスクリプトで頻繁に使用され、原像入力を隠蔽する。これの最も一般的な例の1つは、P2PKHトランザクションにおける公開鍵をマスクすることである。強調されているように、P2PKHトランザクションは、P2PKトランザクションよりも大きく、したがって全体的にトランザクションを行うコストが高くなる。P2PKHは、典型的には、ロックスクリプト
OP_DUP OP_HASH160 <HASH160(PK)> OP_EQUALVERIFY OP_CHECKSIG
を伴う。

【0173】

このセットアップでは、資金をロックする人は、受信側の、アドレスと称される、公開鍵のハッシュ値を知っていなければならない。送信側は、このハッシュ値に資金をロックする。これは、公開鍵をマスクする効果を有する。HASH160は、これを実行するためにチェーン上で使用されるアルゴリズムであり、8つのステップから構成される。
1.SHA256();
2.RIPEMD160();
3.ネットワークタイプに対する出力にプレフィックスを加える。
4.SHA256();
5.SHA256();
6.ステップ5の出力の最初の8バイトを取る。
7.これをステップ3の出力に加える。
8.base58エンコーディング

【0174】

HASH160の出力は、予測不可能であり、決定論的であり、たとえば、同じ入力は、常に同じ出力を生成する。

【0175】

公開鍵は、典型的には、個人のアイデンティティにリンクされることはなく、したがって個人のプライバシーを維持するためにマスキングは必要でない。しかしながら、攻撃者が複数のトランザクションの間の共通点をリンクすることは可能である。たとえば、攻撃者であるボブがアリスに関する実世界情報を知っていた場合、ボブが公開鍵をアリスにリンクすることは可能であり得る。これは、アリスの資金の安全性を何ら損なうものではないが、ボブがこの公開鍵に関係するアリスのトランザクションを追跡することを可能にし、したがってアリスのプライバシーを低下させる可能性がある。

【0176】

HASH160アルゴリズムは、上記の方式でロックされたP2PKHトランザクションスクリプト内の公開鍵に対するマスクを提供し、当事者がチェーン上に利用可能なハッシュ値から公開鍵を導出することは計算的に実現不可能である。しかしながら、アルゴリズムは決定論的であるので、同じ公開鍵は、常に同じハッシュ値を生成する。したがって、これは、複数回使用された場合に攻撃者が同じオンチェーンP2PKHハッシュ値を単純に一致させることを可能にする。

【0177】

さらに、資金をロック解除するために、受信側は、なおもオンチェーンで原像公開鍵を提供しなければならない。受理されると、ネットワークは、この公開鍵をP2PKHハッシュ値に関連付けることができ、その公開鍵に関連付けられている任意の他のオンチェーンP2PKHトランザクションを接続することも可能である。したがって、プライバシーを高めるために、当事者は新しいトランザクションに対して公開鍵を常に変更するべきであることが強く推奨される。特に、P2PKよりもP2PKHを利用する際に発生する追加コストを考慮すると、このようにマスキングすることでどのような機能が得られるのか疑問が生じる。公開鍵がすべてのトランザクションについて変更されるべきである場合、アカウントを公開鍵にリンクすることが不可能となり、したがって公開鍵をマスクする必要性が低下する。さらに、ECDSAのセキュリティは、破ることが計算的に実現不可能であると現在のところは考えられており、したがってハッシュにより提供される追加のセキュリティ層は不要と思われる。

【0178】

8.2 ユニバーサルハッシュ
上で説明されているように、ユニバーサルハッシュは、典型的には
Hash_UHF(x)=((ax+b) mod p ) mod n
という形式を取るハッシュの一形態を指す。
ここで、xは入力であり、a、b、p、およびnは事前決定されたランダムな整数であり、典型的には秘密に保たれる。ユニバーサルハッシュ関数(UHF)は、次のような2つの主要な特性を有する。
1.決定論的-Hash_UHF(x)=Hash_UHF(y)、x=yのとき
2.一様なマッピング分布-2つのランダムに選択された入力x、yに対して

【数22】

である。

【0179】

この第2の条件は、UHFが出力を均等に分配させることを定義し、したがって2つの異なる入力が同じ値にハッシュされる確率は、出力サイズn上で1以下となる。

【0180】

図示されているように、UHFは1回の乗算、1回の加算、および2回の剰余演算しか利用しない。したがって、このスタイルのハッシュを何回も実行して出力のインデックスを作成するのはきわめて効率的である。上に示されているように、より多くのステップを利用する、これらの各々がより複雑であるHASH160よりもかなり効率的である。

【0181】

さらに、暗号学的ハッシュ関数と比較すると、UHFは、計算する当事者から使用されるパラメータに対するある程度選択を可能にする。この柔軟性は、HASH160では現在利用できない機能を提供するために使用することができる。

【0182】

8.3. インデックスハッシュ
P2PKHトランザクションにおける公開鍵ハッシュは、公開鍵の所有者が資金を消費する前に公開鍵が他のユーザに公開されないことを確実にする。これは、ユーザの秘密鍵と公開ネットワークとの間にセキュリティの追加の層を形成し、高度のプライバシーを提供する。しかしながら、公開鍵から秘密鍵を導出することは、現在のところ計算的に実現不可能であると考えられているので、これは不要であると考えられ得る。さらに、HASH160は、決定論的であるので、攻撃者は、公開鍵の同じハッシュ値を一緒に簡単に接続し、ユーザによって資金がロック解除された後それらを公開鍵にリンクすることができる。その結果、ユーザは、プライバシーを高めるために、トランザクション毎に公開鍵を変更することを推奨される。したがって、P2PKトランザクションに対してP2PKHトランザクションにおいてHASH160を使用するマスキングは、ロックスクリプトのサイズを13バイトだけ減らすがロック解除スクリプトのサイズを33バイトだけ増やすことに制限されているように見える。

【0183】

UHFは、現在スクリプトで使用されている暗号学的ハッシュ関数よりもかなり多くの機能を生成するパラメータに対する制御のレベルを可能にする。本開示では、この機能が単一の公開鍵から複数のハッシュされたアドレスを生成し、複数の公開鍵を共通のハッシュされたアドレスにリンクするために使用され、暗号学的ハッシュと併せて、単一のアドレスから複数の安全なアドレスを提供するために使用され得ることがどのように行われるかについて説明する。UHFは、それらが利用する単純な算術演算に起因して非常に効率的である。

【0184】

8.4 ユニバーサルハッシュ関数
ハッシュされたアドレスA_iを生成する例示的なユニバーサルハッシュ関数(UFH)が、本明細書では、
A_i=Hash_UHF(P_i)=[aP_i+b mod n] mod n
として定義され、
ここで、P_iは、第iのユーザに対する公開鍵の圧縮バージョンを表し、これは、2つの可能な対応するy値に対して正または負のインジケータを有するx座標に対する整数値である。われわれはx_i∈[0,p-1]を仮定し、(x_i,-)に対するユニバーサルハッシュ関数の入力として-x_iを使用する。

【0185】

HASH160は、常に同じ公開鍵に対して同じ出力アドレスを生成する。攻撃者は、秘密鍵-公開鍵ペアが再利用される場合に同じハッシュされた公開鍵の値を単純に関連付けることができる。ロック解除された公開鍵がトランザクション実行時に公開された後、攻撃者は、すべてのそれらのハッシュされた値を公開鍵にリンクすることができ、マスクは冗長になる。したがって、ユーザは各トランザクションについて新しい公開鍵を作成することを推奨される。これは、手間がかかり、新しいトランザクション毎に各新しい公開鍵が資金提供当事者に伝送されることを必要とする。

【0186】

乗法ハッシュ関数を使用することで、単一の公開鍵からインデックス付きアドレスを生成し得る。ここで、aおよびbは、作成される新しいアドレス毎にランダムに生成される(pおよびnも、ユースケースに応じて変更され得る)。これは、オフラインで記憶されるルックアップテーブルに効率的に記録され得る。公開鍵は、インデックスに関連付けられ得、対応するアドレスは、インデックスまたは公開鍵を使用して検索され得る。
Hash_UHF(P_i)=[a_iP_i+b_i mod p] mod n.

【表11】

【0187】

上記の表は、a_i、b_iがランダムに選択される、単一の公開鍵に対して最大n個の異なるマスクされたアドレスを生成するために使用されることが可能である。これは、資金提供当事者が、受信側に対する単一の公開鍵を知っていれば、重複するロックスクリプトアドレスを有することなく、その当事者に対して多数のトランザクションを生成することを可能にする。さらに、受信側は、このプロセスについて知る必要はなく、公開鍵および署名を入力するだけでよい。これは、受信者が各トランザクションについて新しい公開鍵を生成し、これを資金提供当事者に送信しなければならないことに比べて効率的なソリューションである。

【0188】

ありそうもないけれども、nを法とする同じアドレスを生成する別個のa_i、b_iに対する衝突をチェックすることは賢明であり得る。説明されるように、このマスクシステムのセキュリティは、値nに関係する。したがって、これらが所望のレベルのセキュリティに対して選択され、アドレス指定スキームに対して固定されることはあり得る。

【0189】

ランダムに選択された2つの公開鍵P_iおよびP_jが同じハッシュされたアドレスと衝突する確率(たとえば、UHF_a,b,p,n(P_i)=UHF_a,b,p,n(P_j))は

【数23】

によって制約される。
ここで、pはUHFへの入力空間と同じ値に設定され、この場合、Secp256k1に付属する素数pである。

【0190】

8.5 パラメータ選択
P_i-受取人はどの公開鍵に対して送金を行うか選択できないので、この圧縮公開鍵値はランダムとみなされる。
p-ビットコインアドレス指定に使用される楕円曲線である、Secp256k1に付属する素数としてpを選択し得る。われわれはこの値を使用し得るが、それは第1の法に対する衝突困難性を最大化するからである。より大きな数値は、小さな入力サイズ(p)を大きな出力サイズに効果的に広げることになるので有益ではない。これは2²⁵⁶-2³²-2⁹-2⁸-2⁷-2⁶-2⁴-1の固定値を有する。pの他の値も選択され得る。
n-衝突確率を増減させるために選択される。nの値を小さくすると出力サイズが小さくなり、衝突の回数が増える。すべてのセキュリティがビットコインのECC鍵ペアのセキュリティから導出される場合、nが大きければ大きいほど、衝突回数が少なくなり資金にアクセスするためのアドレスに解決される意図しない公開鍵が少なくなるので、より「安全」であるとみなされる。われわれは、このn値を変えて固定長出力サイズを変更する、たとえば、最大n=2¹⁶⁰に設定することもでき、したがって、たとえば、Hash160と同じ固定長出力を有する。典型的に、要件に応じてnを固定することができる。
a、b-値aおよび値bは、ユーザによって

【数24】

からランダムに選択され得る。しかしながら、aはゼロに等しくなり得ない、すなわち

【数25】

である。われわれは、1≦a≦p-1、0≦b≦p-1となるように範囲pからa、bを選択し得る。これは、ハッシュスキームに対する最大量の選択および可変性を提供する。aまたはbの範囲およびサイズは、衝突確率には影響しない。

【0191】

8.6 スクリプト
トランザクションのロックおよびロック解除の方法を以下に強調して示す。
ロックスクリプト:OP_DUP <a> OP_MUL <b> OP_ADD <p> OP_MOD <q> OP_MOD <A_i> OP_EQUALVERIFY OP_CHECKSIGVERIFY
ロック解除スクリプト:<Sig_i> <P_i>
ここで、P_iは公開アドレスの圧縮形式を表す。

【0192】

8.7 トランザクションサイズ
上記のロックスクリプトは、7つのオペコード(OP_MUL、OP_ADD、OP_MOD、OP_MOD、OP_EQUAL、およびOP_CHECKSIGVERIFY)を含み、各々サイズが1バイトである。ハッシュされたアドレスA_iは、スクリプト上で最大32バイトを必要とするが、この値は、説明されているようにnを法とする変数に基づいている。

【0193】

ロックスクリプトのサイズは、4つの入力パラメータのサイズa、b、p、およびnに大部分依存する。前述のように、これらはユーザによって決定され得る。p値は、最大32バイトであり得る(これはSecp256k1から2²⁵⁶を法として取った最大入力空間であるからである)。ここから、a、b、およびnのサイズが、要件に応じて選択され得る。

【表12】

【0194】

図示されているように、UHFトランザクションを使用するトランザクションは、標準的なP2PKおよびP2PKHよりも大きい。上記のUHFロックスクリプトでは、a、b、p、およびnの値は合計121バイトのうち80バイトに相当する。われわれは、適切であるときにより小さなパラメータを選択することによってトランザクションサイズをかなり小さくすることも可能である。これは、次のセクションで説明されるように、セキュリティおよび可変性の意味あいを有する。

【0195】

スクリプトのパラメータサイズを小さくする別の方法は、ビットを直接的にプッシュすることによって値を表現することである。たとえば、nがその範囲内の何らかの値ではなく、むしろ正確に値2²⁵⁶として選択された場合、2²⁵⁶を16⁶⁴として表現することも可能である。これを使用することで、オペコード
OP_1 <64> OP_LSHIFT
を使用してスクリプトにおいて値16⁶⁴(16進数で、1の後に0が64個続く)を単純にプッシュすることも可能である。

【0196】

このようにすると、0～2²⁵⁶の範囲内の数値を表現するのに必要な32バイトの代わりに4バイトのメモリしか使用しないことになる。しかしながら、そのような方法は、パラメータに16の正確な累乗が使用される場合にのみ効率的である。たとえば、いわゆる法pは、2²⁵⁶-2³²-977(Secp256k1から)に固定される。われわれは、これを上記の方法を使用してより効率的に表現することができ、
OP_1 <64> OP_LSHIFT OP_1 OP_8 OP_LSHIFT OP_SUB <977> OP_SUB
となる。

【0197】

上記では、以下を行う。
1. 1をプッシュし、これを64桁分左シフトして値2²⁵⁶を形成する。
2. 1をプッシュし、これを8桁分左シフトして値2³²を形成する。
3. 2²⁵⁶から2³²を減算する。
4. 値977をプッシュし、これを前の出力から減算する。

【0198】

この方法は、p値Secp256k1を32バイトではなく12バイトで形成する。

【0199】

8.8 セキュリティ
UHFは、複数の異なる公開鍵が同じロック解除アドレスにハッシュすることを可能にする。これは、ロック解除される前に公開鍵にマスキングを施す。第一に、ハッシュされたオンチェーンアドレスは、それが意図される公開鍵と異なる。第二に、攻撃者がどの公開鍵がスクリプトをロック解除することが可能であるかを導き出す取り組みを望んだ場合、そのアドレスと衝突する可能性のある可能なすべての公開鍵を計算する必要がある。

【0200】

たとえば、単一のオンチェーンのハッシュされたアドレスに対して結果として10億回の可能な公開鍵の衝突を引き起こした法nの値を選択することを考える。これは、攻撃者がオンチェーンロックスクリプトを解く可能性のある10億個の公開鍵を導出する必要があることを意味する。これは、攻撃者がUHFを解き、次いで入力空間pから、この法nに対して衝突するすべての値を導出することを必要とする。したがって、攻撃者はすべてのp/n個の値を導出し、記憶することも可能であるが、これは攻撃者が単一のユーザの公開鍵アドレスの活動を識別/追跡するのを大きく助けることはしない。攻撃者がこの方法で多くのUHFロックスクリプトを追跡しなければならないことを考慮したときに、われわれは、UHFをセキュリティをある程度犠牲にしたマスキング機能として表現することができる。

【0201】

前述のように、UHFのセキュリティは、ECC鍵ペアセキュリティから導出される。スクリプトアドレスをロック解除することができる公開鍵に対応する秘密鍵を算出することは計算的に実現不可能である。ロックスクリプト内の同じアドレスを形成するように解くことが可能である公開鍵が10億個あったとしても、これは、試行1回あたりの公開鍵を形成する秘密鍵を導出する約

【数26】

の確率を攻撃者になおも与える。

【0202】

8.9 ハイブリッドハッシュ
説明されているように、UHFは、暗号学的ハッシュからは利用不可能な追加機能を提供する。しかしながら、オンチェーンUHFを解くことが可能である潜在的な公開鍵P_iを導出することは以下のように幾分自明な作業である:
A_i=[aP_i+b mod p] mod n
ただし、a、b、p、n、およびA_iはチェーン上ですべて見えているものとする。

【0203】

この脆弱性は、UHF出力A_iをHASH160などの暗号学的ハッシュ関数に通すことによって対処され得る。これは、暗号学的ハッシュの原像計算困難性とUHFの柔軟性とを組み合わせることになる。われわれは、両方の形式のハッシュ関数を伴うので、これをハイブリッドハッシュと称することにする。これは、図15に概略として例示されている。

【0204】

HASH160によって提供される原像計算困難性は、公に見えるアドレスハッシュ

【数27】

からA_iを導出することを計算的に実現不可能にし、次いで、

【数28】

を解く潜在的な公開鍵P_iを計算することも実現不可能にする。より多くの演算を必要とするけれども、このハイブリッドハッシュは、上で説明されているすべての機能を提供する。当事者は、UHFパラメータを変化させることによって、単一の公開鍵から複数のアドレスを効率的に出力するハッシュインデックステーブルを作成し得る。これらの異なるアドレス値は、また、HASH160に通されたときに非常に異なる値

【数29】

を有することになる。しかしながら、次に、

【数30】

から原像値A_iを計算することは実現不可能になり、したがって、このアドレスを解く公開鍵を計算することも実現不可能である。ハッシュインデックステーブルは、以下の形式を取り得る。

【表13】

ここで、

【数31】

である。

【0205】

ロックスクリプトおよびロック解除スクリプトは、以下の形式を取り得る。
ロックスクリプト:

【数32】

ロック解除スクリプト:<Sig_i><n> <p> <b_i> <a_i> <Pi>

【0206】

ハイブリッドハッシュにおける原像計算困難性を使用することで、われわれは、ロック解除スクリプトにすべてのUHFパラメータをオフセットして、ロックスクリプトをよりコンパクトにすることを選択し得る。これは、UTXOの記憶領域を大幅に削減する利点を有するが、ロック解除当事者がハッシュインデックステーブルを知ることを必要とする。さらに、UHF値a、b、p、およびnは、それらをそのアドレスに連結し、この値を検証することによって強制され得る。

【0207】

そこで、UHF(インデックス付きハッシュ)の機能は、チェーン上のUHFを解くことが可能である公開鍵を計算することが計算的に実現不可能であるので、強化される。さらに、ロックスクリプトのサイズは多重署名トランザクションの場合と比べて著しく小さく、ノードによって使用するUTXOメモリサイズを削減する。図示されているように、これは暗号学的ハッシュおよびユニバーサルハッシュの両方を含み、アドレスを最適な形で見えなくする。

【表14】

【0208】

9. 例示的なユースケース
9.1 単一のユーザ
このセクションでは、説明されている実施形態に対するユースケースを説明する。アリス103aはオンラインゲームを運営している。ボブ103bはアリスのゲームのレギュラープレイヤーである。アリス103aは定期的にボブ103bに賞金のためのトランザクションを生成する。ボブ103bは怠惰であり、コールドストレージウォレットを使用しており、ゲームをするたび毎に常時新しい秘密鍵-公開鍵ペアを生成するのは不便である。通信コストを削減するために、ボブ103bは、アリス103が彼へのすべての決済トランザクションにおいて同じ公開鍵を使用することを要求する。ボブ103bは、これらの別個のトランザクションで彼に割り当てられたUTXOが、消費されてしまうまで外部当事者によってリンクされ得ないことを確実にしたい。したがって、アリス103aは、ボス103bに定期的支払いを伝送するために説明されているインデックスハッシュシステムを使用する。

【0209】

ボブ103bは、アリス103aに対して1回限りの公開鍵Pを生成する。次いで、アリス103aは、この単一の公開鍵に対する安全なオフチェーンルックアップテーブルを作成する。以下の方法で、n個の最大アドレス

【数33】

を生成する。

【表15】

【0210】

そこで、アリス103aは、これらのインデックス付きハイブリッドハッシュを使用して、最大n個の異なるアドレス

【数34】

を生成することができる。アリス103aおよびボブ103bは、これらのトランザクションの各々が異なるオンチェーンアドレスを有することを知っているということで安全性であり得、バッドアクターがそれらを関連付けることを困難にする。さらに、暗号学的ハッシュ関数は、この同じバッドアクターがこれらを導出するために使用される公開鍵Pを計算することができないことを確実にする。

【0211】

ボブ103bは、単純に、同じ公開鍵および関連するデジタル署名を使用してこれらすべてのトランザクションをロック解除するだけでよく、自分の公開鍵を常時に更新して伝送するのに比べてボブの側ではこのプロセスがかなり単純になる。

【0212】

9.2 オープンパズルコンペティション(Open Puzzle Competition)
上記の例と同様に、アリス103aは、いくつかの公に利用可能な記録の検証をアウトソーシングすることを望んでいる。しかしながら、今度は、アリスは、それらを特定の公開鍵に結び付けず、単純に、その記録を検証することができる人であれば誰でも関連付けられている資金をロック解除することができることを望んでいる。これは、
A_i=[aP_i+b mod p] mod n
から、リンクされたアドレススキームに十分に小さなnを設定することを通じて達成され得る。

【0213】

たとえば、q=2の場合、すべての公開鍵および対応する署名の半分がスクリプトをロック解除することが可能である。これは理想的ではないが、それは、ビットコインノードがトランザクションソリューションを、所有する公開鍵および署名に単純に置き換えるだけで、彼らが目的外の資金を要求することが極端に自明なものとなるからである。

【0214】

しかしながら、アリスは、未知の解く側の当事者がアドレスシステムの条件を満たした秘密鍵-公開鍵ペアを、たとえば平均して何日もかけてオフラインで生成することが可能であるようにq値を十分に高く設定することが可能である。これは、不正なビットコインノードが1ブロックに対する平均採掘時間(10分)内に所有する満足のいく秘密鍵公開鍵ペアを生成することが実現不可能になることを確実にする。少なくとも何人かの良いマイナーがいると仮定すると、悪いビットコインノードが関連付けられている資金を盗むために代替的トランザクションを生成する前に元のトランザクションの承認が行われ、ビットコインネットワークに公開されることになる。

【0215】

10. 結論
開示された技術の他の変更形態またはユースケースは、本明細書において開示を示した後に当業者にとって明らかになるであろう。本開示の範囲は、説明されている実施形態によって限定されず、付属の請求項によってのみ限定される。

【0216】

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

【0217】

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

【0218】

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

【0219】

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

【0220】

上記の実施形態は、例としてのみ説明されていることは理解されるであろう。より一般的には、次のステートメントのいずれか1つまたは複数による方法、装置、またはプログラムが提供され得る。

【0221】

ステートメント1。ブロックチェーントランザクションを使用してハッシュ関数HFを実施するコンピュータ実装方法であって、方法が第1の当事者によって実行され、
第1のブロックチェーントランザクションを生成することと、
第1のブロックチェーントランザクションをブロックチェーントランザクションの1つまたは複数のノードにサブミットすることとを含み、
第1のブロックチェーントランザクションは、ターゲットデータ項目を含む第2のブロックチェーントランザクションのロック解除スクリプトと一緒に実行されたときに、ターゲットデータ項目のハッシュ結果を生成するように構成されているロックスクリプトを含み、ロックスクリプトは、ハッシュ結果を生成することを、少なくとも
第1のパラメータにターゲットデータ項目を乗算することに基づき第1の中間結果を生成するステップ、
第1の中間結果への第2のパラメータの加算に基づき第2の中間結果を生成するステップ、
第3のパラメータによる第2の中間結果のモジュロに基づき第3の中間結果を生成するステップ、および
第4のパラメータによる第3の中間結果のモジュロに基づきハッシュ結果を生成するステップを実行することによって行うように構成されているHFスクリプトを含む、コンピュータ実装方法。

【0222】

ステートメント2。第1のロックスクリプトは、少なくともハッシュ結果を出力するように構成される、ステートメント1に記載の方法。たとえば、ハッシュ結果は、メモリ、たとえばスタックに出力され得る。

【0223】

ステートメント3。ロックスクリプトは、予期されるハッシュ結果を含み、ロックスクリプトは、ロック解除スクリプトによってロック解除されるようにターゲットハッシュ結果が予期されるハッシュ結果と一致することを必要とするように構成される、ステートメント1またはステートメント2に記載の方法。

【0224】

ステートメント4。予期されるハッシュ結果は、予期される公開鍵にハッシュ関数を適用することによって生成される、ステートメント3に記載の方法。

【0225】

ステートメント5。ロックスクリプトは、ターゲットデータ項目が予期される公開鍵であることを必要とし、予期される公開鍵に対応する秘密鍵を使用して生成された署名を含むように構成される、ステートメント4に記載の方法。

【0226】

ステートメント6。予期されるハッシュ結果、またはその略記バージョンを、予期される公開鍵、第1のブロックチェーントランザクションに関連付けられているデータ、および/または第1のブロックチェーントランザクションの出力を消費する消費トランザクションに関連付けられているデータのうちの少なくとも1つにマッピングされたルックアップテーブル内に記憶することを含む、ステートメント4またはステートメント5に記載の方法。

【0227】

ステートメント7。第1のブロックチェーントランザクションに関連付けられているデータは、第1のブロックチェーントランザクションのトランザクション識別子および/または第1のブロックチェーントランザクションそれ自体を含み、および/または
消費トランザクションに関連付けられているデータは、消費トランザクションのトランザクション識別子および/または消費トランザクションそれ自体を含む、ステートメント6に記載の方法。

【0228】

ステートメント8。ルックアップテーブルは、複数の異なるハッシュ結果またはその略記バージョンを含み、各々ユニバーサルハッシュ関数を異なる公開鍵に適用することによって生成され、各異なるハッシュ結果は、異なる公開鍵、異なるハッシュ結果を含むそれぞれのブロックチェーントランザクションに関連付けられているデータ、および/またはそれぞれのブロックチェーントランザクションの出力を消費するそれぞれの消費トランザクションに関連付けられているデータのうちの少なくとも1つにマッピングされる、ステートメント6またはステートメント7に記載の方法。

【0229】

ステートメント9。ロックスクリプトは、親公開鍵の子公開鍵を生成するように構成されている公開鍵導出、PKD、スクリプトを含み、PKDスクリプトは、HFスクリプトを含み、ロック解除スクリプトは、親公開鍵を含み、ターゲットデータ項目は、少なくとも親公開鍵のチェーンコードおよび親公開鍵を含み、PKDスクリプトは、親公開鍵およびハッシュ結果に基づき子公開鍵を生成するように構成される、ステートメント1またはステートメント2に記載の方法。第1のロックスクリプトは、子公開鍵を出力するように構成され得る。

【0230】

ステートメント10。ターゲットデータ項目は、追加のデータを含む、ステートメント9に記載の方法。

【0231】

ステートメント11。追加のデータは、子公開鍵のインデックス、タイムスタンプ、および/またはメッセージのうちの少なくとも1つを含む、ステートメント10に記載の方法。

【0232】

ステートメント12。PKDスクリプトは、2進数変換スクリプト、点乗算スクリプト、および点加算スクリプトを含み、2進数変換スクリプトは、ハッシュ結果を2進数表現に変換するように構成され、点乗算スクリプトは、ハッシュ結果の2進数表現と楕円曲線の生成元との点乗算を実行して中間公開鍵を生成するように構成され、点加算スクリプトは、中間公開鍵と親公開鍵との点加算を実行して子公開鍵を生成するように構成される、ステートメント9から11のいずれか一項に記載の方法。

【0233】

ステートメント13。ハッシュ結果は、10進数または16進数表現で表現され、2進数変換スクリプトは、ハッシュ結果の10進数または16進数表現を2進数表現に変換するように構成される、ステートメント12に記載の方法。

【0234】

ステートメント14。第1のパラメータは任意の非ゼロの数であり、第2のパラメータは任意の数であり、第3のパラメータは正数であり、第4のパラメータは2^Lであり、Lはハッシュ結果の長さを定義するように選択される、先行するステートメントのいずれかに記載の方法。

【0235】

ステートメント15。pは、sec9256k1楕円曲線を定義する素数である、ステートメント14に記載の方法。

【0236】

ステートメント16。Lは、32、64、128、160、256、または512のうちの1つである、ステートメント14またはステートメント15に記載の方法。

【0237】

ステートメント17。ハッシュ関数は、Hash_UHF(P)=[a_iP+b_i mod p] mod nとして定義され、ここで、a_iは第1のパラメータであり、b_iは第2のパラメータであり、pは第3のパラメータであり、nは第4パラメータであり、方法は、
ハッシュ関数Hash_UHF(P)を、第1のパラメータ、第2のパラメータ、第3のパラメータ、第4のパラメータのうちの1つ、いくつか、またはすべての異なるそれぞれの値について予期される公開鍵Pに適用することによって予期される公開鍵Pについて複数の異なるそれぞれの予期されるハッシュ結果を生成することを含む、先行するステートメントのいずれかに記載の方法。

【0238】

ステートメント18。第1のブロックチェーントランザクションは、複数のそれぞれの出力を含み、各それぞれの出力はそれぞれのターゲット公開鍵を含む異なるそれぞれのブロックチェーントランザクションのそれぞれのロック解除スクリプトとともに実行されたときに、それぞれのターゲット公開鍵のそれぞれのハッシュ結果を生成するように構成されているそれぞれのロックスクリプトを含み、それぞれのロックスクリプトは、それぞれのハッシュ結果を生成することを、少なくとも
それぞれの第1のパラメータにターゲットデータ項目を乗算することに基づきそれぞれの第1の中間結果を生成するステップ、
それぞれの第1の中間結果へのそれぞれの第2のパラメータの加算に基づきそれぞれの第2の中間結果を生成するステップ、
それぞれの第3のパラメータによるそれぞれの第2の中間結果のモジュロに基づきそれぞれの第3の中間結果を生成するステップ、および
それぞれの第4のパラメータによるそれぞれの第3の中間結果のモジュロに基づきそれぞれのハッシュ結果を生成するステップを実行することによって行うように構成されているそれぞれのHFスクリプトを含み、
各それぞれのロックスクリプトは、複数の予期されるハッシュ結果のうちのそれぞれの1つを含み、それぞれのロックスクリプトは、a)それぞれのターゲットハッシュ結果がそれぞれの予期されるハッシュ結果と一致することを必要とし、b)ロック解除スクリプトによってロック解除されるようにそれぞれのロック解除スクリプトが予期される公開鍵を使用して生成されるそれぞれの署名を含むことを必要とするように構成される、ステートメント17に記載の方法。

【0239】

ステートメント19。1つまたは複数のさらなるブロックチェーントランザクションを生成することであって、各さらなるトランザクションは、1つまたは複数のそれぞれの出力を含み、各それぞれの出力はそれぞれのターゲット公開鍵を含む異なるそれぞれのブロックチェーントランザクションのそれぞれのロック解除スクリプトとともに実行されたときに、それぞれのターゲット公開鍵のそれぞれのハッシュ結果を生成するように構成されているそれぞれのロックスクリプトを含み、それぞれのロックスクリプトは、それぞれのハッシュ結果を生成することを、少なくとも
それぞれの第1のパラメータにターゲットデータ項目を乗算することに基づきそれぞれの第1の中間結果を生成するステップ、
それぞれの第1の中間結果へのそれぞれの第2のパラメータの加算に基づきそれぞれの第2の中間結果を生成するステップ、
それぞれの第3のパラメータによるそれぞれの第2の中間結果のモジュロに基づきそれぞれの第3の中間結果を生成するステップ、および
それぞれの第4のパラメータによるそれぞれの第3の中間結果のモジュロに基づきそれぞれのハッシュ結果を生成するステップを実行することによって行うように構成されているそれぞれのHFスクリプトを含む、生成することを含み、
各それぞれのロックスクリプトは、複数の予期されるハッシュ結果のうちのそれぞれの1つを含み、それぞれのロックスクリプトは、a)それぞれのターゲットハッシュ結果がそれぞれの予期されるハッシュ結果と一致することを必要とし、b)ロック解除スクリプトによってロック解除されるようにそれぞれのロック解除スクリプトが予期される公開鍵を使用して生成されるそれぞれの署名を含むことを必要とするように構成される、ステートメント17またはステートメント18に記載の方法。

【0240】

ステートメント20。予期される公開鍵Pに対する複数の異なるそれぞれの予期されるハッシュ結果を前記生成することは、i)ハッシュ関数Hash_UHF(P)を、第1のパラメータ、第2のパラメータ、第3のパラメータ、第4のパラメータのうちの1つ、いくつか、またはすべての異なるそれぞれの値に対して予期される公開鍵Pに適用することによってそれぞれの中間ハッシュ結果を生成することと、ii)暗号学的ハッシュ関数によりそれぞれの中間ハッシュ結果をハッシュすることとを含む、ステートメント17から19のいずれか一項に記載の方法。

【0241】

ステートメント21。ステートメント18またはステートメント19に従属するときに、それぞれのHFスクリプトによって生成されたそれぞれの第4のパラメータによるそれぞれの第3の中間結果のモジュロは、それぞれの中間ハッシュ結果であり、それぞれのHFスクリプトは、それぞれの中間ハッシュ結果を暗号学的ハッシュ関数によりハッシュすることによってそれぞれの予期されるハッシュ結果を生成するように構成される、ステートメント20に記載の方法。

【0242】

ステートメント22。暗号学的ハッシュ関数はRIPEMD160、SHA256、またはRIPEMD160とSHA256との組合せのうちの1つである、ステートメント20またはステートメント21に記載の方法。

【0243】

ステートメント23。複数の予期されるハッシュ結果、またはそれぞれの略記バージョンを、予期される公開鍵またはそのインデックスのうちの少なくとも1つにマッピングされたルックアップテーブルに記憶することを含む、ステートメント17から22のいずれか一項に記載の方法。

【0244】

ステートメント24。コンピュータ機器であって、
1つまたは複数のメモリユニットを含むメモリと、
1つまたは複数の処理ユニットを含む処理装置とを備え、メモリは、処理装置上で実行するように配置構成されているコードを記憶し、コードは処理装置上にあるときに任意の先行するステートメントのいずれか一項に記載の方法を実行するように構成される、コンピュータ機器。

【0245】

ステートメント25。コンピュータ可読ストレージ上に具現化され、1つまたは複数のプロセッサ上で実行されたときに、ステートメント1から16のいずれか一項に記載の方法を実行するように構成されている、コンピュータプログラム。

【0246】

本明細書において開示されている別の態様によれば、第1の当事者および第2の当事者のアクションを含む方法が提供され得る。

【0247】

本明細書において開示されている別の態様によれば、第1の当事者および第2の当事者のコンピュータ機器を備えるシステムが提供され得る。

【符号の説明】

【0248】

100 システム
101 パケット交換ネットワーク
102 コンピュータ機器、機器
102a コンピュータ機器、アリスの機器
102b コンピュータ機器、ボブの機器
103 ユーザ、当事者
103a ユーザ、第1の当事者、アリス
103b 新規ユーザまたはエンティティ、第2の当事者、ボブ
104 ブロックチェーンノード、ノード
105 クライアントアプリケーション
105a クライアントアプリケーション
105b クライアント
106 ピアツーピア(P2P)ネットワーク、ブロックチェーンネットワーク
107 サイドチャネル
150 ブロックチェーン
151 ブロック
151n ブロック
152 トランザクション、ブロックチェーントランザクション
152i トランザクション
152j トランザクション
153 ジェネシスブロック
154 順序付けられたセット(または「プール」)、トランザクション
155 ブロックポインタ
201 ヘッダ
202 入力、入力フィールド
203 出力、出力フィールド
301 サイドチャネル
401 トランザクションエンジン
402 ユーザインターフェース(UI)層
450 ノードソフトウェア
451 プロトコルエンジン
452 スクリプトエンジン
453 スタック
454 アプリケーションレベル決定エンジン
455 ブロックチェーン関係機能モジュール
455C コンセンサスモジュール
455P 伝搬モジュール
455S ストレージモジュール
500 ユーザインターフェース(UI)
501 UI要素
502 UI要素
502 UI要素
600 システム

【図1】

【図2】

【図3A】

【図3B】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【国際調査報告】