JP2023036962A - ブロックチェーン上に検証鍵を記録するためのシステム - Google Patents

Abstract

【課題】ブロックチェーン上での安全な転送及び交換を可能にする方法システム及び記憶媒体を提供する。【解決手段】方法は、ブロックチェーントランザクションに関連付けられるリディームスクリプトを取得するステップと、コマンドの第２セットと、複数の要素が検証鍵を集合的に形成し、１つ以上のサブセットが検証鍵の各要素を集合的に含む、前記複数の要素の１つ以上のサブセットと、コマンドの第１セット及び１つ以上の暗号ハッシュ値を含む第１スクリプトと、第２スクリプトを生成するコンピュータに関連付けられる識別子とを含む、第２スクリプトを生成するステップと、１つ以上の暗号ハッシュ値が検証鍵の１つ以上のサブセットに一致するという決定に関連して、コマンドの第１セット及び第２セットを実行することに部分的に基づいて、コンピュータが検証鍵へのアクセスを有することの証明書を生成するステップと、を含む。【選択図】図４

Description

本発明は、一般に、コンピュータ実装されるセキュリティ及び／又は検証技術に関する。また、ブロックチェーン機能を拡張又は強化するためのソリューション、より具体的には、匿名又はほぼ匿名のデジタルトランザクションを実装することにも関する。本発明は、完全性（プロトコルに正しく従う場合、正当な検証者は出力の有効性を確信することになる）、健全性（不正な証明者は、出力の確実性が真実であることを正当な検証者に確信させることはできない）及び／又はゼロ知識（出力が有効である場合、不正な検証者はこの事実以外の何も学習しない）の暗号的に検証可能な保証を利用し、かつ／又はそれらから利益を得ることができるプロトコルにおける使用に特に適しているが、これらに限定されない。本明細書で説明される様々なプロトコルは、ブロックチェーン上に検証鍵を記録するのに適していてよく、作業者（ｗｏｒｋｅｒ）は正しい（例えばクライアントによって発行された）検証鍵Ｖ_ｋの所有を証明することができる。本発明は、暗号技術及び数学技術を利用して、ブロックチェーンネットワーク上で行われる電子転送に関連してセキュリティを実施することができる。

本明細書において、「ブロックチェーン」という用語は、いくつかのタイプの電子的なコンピュータベースの分散台帳のいずれかを指してよい。これらは、コンセンサスベースのブロックチェーン及びトランザクションチェーン技術、許可及び未許可台帳、共有台帳及びそれらの変形を含む。最も広く知られているブロックチェーン技術の用途はビットコイン台帳であるが、他のブロックチェーンの実装が提案され、開発されている。便宜性及び例示の目的のために、ビットコインが、本明細書で説明される技術の有益な用途として参照され得るが、ビットコインは、本開示で説明される技術が適用され得る多くの用途の１つに過ぎない。しかしながら、本発明は、ビットコインブロックチェーンでの使用に限定されず、非商業的用途を含む代替的なブロックチェーン実装及びプロトコルも本発明の範囲内に含まれることに留意されたい。例えば本開示に記載される技術は、エンティティが正しい又は適切な検証鍵Ｖ_ｋの所有を証明することができる、エンティティの検証鍵の記録に関してビットコインと同様の制限を有する他のブロックチェーン実装を利用する利点を提供するであろう。本明細書に記載されるように、ビットコインは、Ｂｉｔｃｏｉｎ Ｃａｓｈ及びＢｉｔｃｏｉｎ Ｃｌａｓｓｉｃのような、任意のブロックチェーンベースのブロックチェーンネットワークを指すことに留意されたい。

ブロックチェーンは、ブロックにより構成される、コンピュータベースの非集中型の分散システムとして実装されるピアツーピア電子台帳であり、ブロックはトランザクション及び他の情報により構成され得る。いくつかの例において、「ブロックチェーントランザクション」は、データ及び条件のセットを含むフィールド値の構造化されたコレクションを符号化する入力メッセージを指し、この場合、条件のセットを満たすことは、フィールドのセットがブロックチェーンデータ構造に書き込まれるための前提条件である。例えばビットコインでは、各トランザクションは、ブロックチェーンシステムの参加者間のデジタル資産の制御の移転を符号化し、少なくとも１つの入力及び少なくとも１つの出力を含む、データ構造である。いくつかの実施形態において、「デジタル資産」は、使用権に関連付けられるバイナリデータを指す。デジタル資産の例は、ビットコイン、イーサ、ライトコインを含む。いくつかの実装において、デジタル資産の制御を移転することは、デジタル資産の少なくとも一部を第１エンティティから第２エンティティに再関連付けすることによって実行され得る。ブロックチェーンの各ブロックは、ブロックが一緒にチェーン化されることになり、その始めからブロックチェーンに書き込まれたすべてのトランザクションの永続的で変更不能なレコードを作成するように、以前のブロックのハッシュを含んでよい。

いくつかの例において、「スタックベースのスクリプト言語」は、様々なスタックベース又はスタック指向の実行モデル及びオペレーションをサポートするプログラミング言語を指す。すなわち、スタックベースのスクリプト言語は、スタックを利用してもよい。スタックでは、値をスタックの先頭（ｔｏｐ）にプッシュすることができ、あるいはスタックの先頭からポップすることができる。スタックに対して実行される様々なオペレーションの結果、１つ以上の値を、スタックの先頭へプッシュすること又はスタックの先頭からポップすることになり得る。例えばＯＰ_ＥＱＵＡＬオペレーションは、スタックから上位２つのアイテムをポップし、それらを比較し、結果（例えば等しい場合は１、等しくない場合は０）をスタックの先頭にプッシュする。ＯＰ_ＰＩＣＫのようにスタックに対して実行される他のオペレーションは、スタックの先頭以外の位置からアイテムを選択することを可能にすることがある。本実施形態のいくつかで用いられるいくつかのスクリプト言語では、少なくとも２つのスタック、すなわち、メインスタックと代替スタックが存在し得る。スクリプト言語のいくつかのオペレーションは、あるスタックの先頭から別のスタックの先頭にアイテムを移動させることができる。例えばＯＰ_ＴＯＡＬＴＳＴＡＣＫは、メインスタックの先頭から代替スタックの先頭に値を移動させる。スタックベースのスクリプト言語は、場合によっては、厳密な後入先出（ＬＩＦＯ）方式のオペレーションのみに限定されないことに留意されたい。例えばスタックベースのスクリプト言語は、スタック内のｎ番目のアイテムを先頭にコピー又は移動させるオペレーション（例えばそれぞれ、ビットコインにおけるＯＰ_ＰＩＣＫ及びＯＰ_ＲＯＬＬ）をサポートしてもよい。スタックベースのスクリプト言語で書かれたスクリプトは、ベクトル、リスト又はスタックのような任意の適切なデータ構造を使用して実装することができる論理スタック上にプッシュされ得る。

トランザクションがブロックチェーンに書き込まれるためには、「検証（ｖａｌｉｄａｔｅ）」されなければならない。ネットワークノード（マイニングノード）は、各トランザクションが有効であることを保証するための作業を実行し、無効なトランザクションはネットワークから拒絶される。ノードは、他のノードとは異なる有効性の標準を有することができる。ブロックチェーンの有効性はコンセンサスベースであるので、トランザクションが有効であることに大多数のノードが同意した場合、トランザクションは有効であるとみなされる。ノードにインストールされているソフトウェアクライアントは、ＵＴＸＯのロッキングスクリプト及びアンロッキングスクリプトを実行することにより、部分的に未使用トランザクション（ＵＴＸＯ：ｕｎｓｐｅｎｔ ｔｒａｎｓａｃｔｉｏｎ）を参照するトランザクションに対するこの検証作業を実行する。ロッキングスクリプト及びアンロッキングスクリプトの実行がＴＲＵＥに評価され、適用可能である場合に他の検証条件が満たされる場合、トランザクションはノードによって検証される。検証されたトランザクションは、他のネットワークノードに伝搬され、そこで、マイニングノードは、トランザクションをブロックチェーンに含めるように選択することができる。したがって、トランザクションがブロックチェーンに書き込まれるためには、ｉ）トランザクションは、該トランザクションを受け取った最初のノードによって検証されなければならず、トランザクションが検証された場合、ノードはトランザクションをネットワーク内の他のノードに中継し；ｉｉ）トランザクションは、マイニングノードによって構築された新しいブロックに追加されなければならず；ｉｉｉ）マイニングされなければならない、すなわち、過去のトランザクションの公開台帳に追加されなければならない。トランザクションを実質的に不可逆にするために、十分な数のブロックがブロックチェーンに追加されると、トランザクションは確認されたとみなされる。

ブロックチェーン技術は、暗号通貨実装の使用について最も広く知られているが、デジタル起業家達は、新たなシステムを実装するために、ビットコインが基づいている暗号セキュリティシステムと、ブロックチェーン上に格納することができるデータとの双方の使用を探求し始めている。暗号通貨の領域に限定されない自動化タスク及びプロセスにブロックチェーンを使用することができれば非常に有利であろう。そのようなソリューションは、それらの用途はより多方面にわたるが、ブロックチェーンの利点（例えば永続性、イベントの改ざん防止レコード、分散処理等）を利用することができるであろう。

本開示は、１つ以上のブロックチェーンベースのコンピュータプログラムの技術的側面を説明する。ブロックチェーンベースのコンピュータプログラムは、ブロックチェーントランザクション内に記録される機械読取可能で実行可能なプログラムであってよい。ブロックチェーンベースのコンピュータプログラムは、結果を生成するために入力を処理することができ、次いで、それらの結果に依存してアクションを実行させることができるルールを含んでよい。現在の研究の１つの分野は、「スマートコントラクト」の実装のためのブロックチェーンベースのコンピュータプログラムの使用である。自然言語で書かれる伝統的な契約とは異なり、スマートコントラクトは、機械読み取り可能な契約又は合意の条件の実行を自動化するように設計されるコンピュータプログラムであってよい。

ブロックチェーンに関連する関心のある別の領域は、ブロックチェーンを介して実世界のエンティティを表し、転送するための「トークン」（又は「カラードコイン」）の使用である。潜在的に機密又は秘密のアイテムを、識別可能な意味又は値を有しないトークンによって表すことができる。したがって、トークンは、実世界のアイテムがブロックチェーンから参照されることを可能にする識別子として機能する。

実施形態において、特定のエンティティとの対話を、スマートコントラクトの特定のステップで符号化することができるが、スマートコントラクトは、そうでなければ、自動的に実行され、自己強制される可能性がある。それは、機械読み取り可能かつ実行可能である。いくつかの例では、自動実行は、ＵＴＸＯの移転を可能にするために成功裏に実行されるスマートコントラクトの実行を指す。なお、このような例では、ＵＴＸＯの移転送を可能にする「エンティティ」は、何らかの秘密の知識を証明することを必要とされることなく、アンロッキングスクリプトを作成することができるエンティティを指すことに留意されたい。言い換えると、データのソース（例えばアンロッキングトランザクションを作成したエンティティ）が暗号秘密（例えば秘密の非対称鍵、対称鍵等）へのアクセスを有することを確かめることなく、アンロッキングトランザクションを検証することができる。また、このような例では、自己強制とは、制約に応じてアンロッキングトランザクションを強制させているブロックチェーンネットワークの検証ノードを指す。いくつかの例では、ＵＴＸＯを「アンロック」すること（ＵＴＸＯの「消費（ｓｐｅｎｄｉｎｇ）」としても知られる）は、技術的な意味で使用されており、ＵＴＸＯを参照して、有効として実行するアンロッキングトランザクションを作成することを指す。

ブロックチェーントランザクションの出力は、ロッキングスクリプトと、ビットコイン等のデジタル資産の所有権に関する情報を含む。ロッキングスクリプトは、障害（ｅｎｃｕｍｂｒａｎｃｅ）とも呼ばれることがあり、ＵＴＸＯを移転するために満足する必要がある条件を指定することにより、デジタル資産を「ロック」する。例えばロッキングスクリプトは、関連するデジタル資産をアンロックするために、特定のデータがアンロッキングスクリプトで提供されることを必要とする可能性がある。ロッキングスクリプトは、ビットコインでは「ｓｃｒｉｐｔＰｕｂＫｅｙ」としても知られる。デジタル資産をアンロックするためにデータの提供を当事者に要求する技術は、ロッキングスクリプト内部にデータのハッシュを埋め込むことを伴う。しかしながら、これは、ロッキングスクリプトが作成される時点でデータが未定である（例えば未知で固定されていない）場合に問題を提示する。

本発明は、検証方法／システムとして、かつ／又はブロックチェーントランザクションの検証を制御するための制御方法／システムとして説明され得る。いくつかの実施形態では、検証されたブロックチェーントランザクションの結果、ブロックチェーン上のトランザクションの記録をもたらし、これは、いくつかの用途では、ブロックチェーンを介したデジタル資産の交換又は移転をもたらすことがある。デジタル資産は、ブロックチェーンによって管理されるリソースの単位であってよい。デジタル資産は、実施形態によっては、暗号通貨として使用され得るが、デジタル資産は、実施形態によっては、他のコンテキストにおいて追加的又は代替的に使用可能であるように企図される。本発明は、デジタル資産の制御に適用可能であるが、本質的に技術的であり、デジタル資産の移転を必ずしも伴わずに、ブロックチェーンデータ構造を利用する他のコンテキストで使用できることに留意されたい。

したがって、ブロックチェーン上での安全な転送及び交換を可能にするように構成されるシステム及び方法を提供することが望ましい。好ましくは、これは公開ブロックチェーンであるが、必ずしもそうではない。（例えば）ブロックチェーントランザクションにおけるデジタル資産の受信者に関連する情報のような、転送／通信に関する情報が不明瞭である、匿名のデジタル転送及び／又は通信を実装することが更に望ましい。プロトコルに従って、適切な資格証明書が提示されない限り、メタデータを読むこと及び／又は修正することができないように、ブロックチェーン上のメタデータを読む／書くための資格証明書権限を提供することが更に望ましい。したがって、本発明は、強化された検証及び／又はセキュリティを提供する。

このような改善されたソリューションが、現在では考案されている。

したがって、本発明によれば、添付の特許請求の範囲で定義されるようなシステム及び方法が提供される。

本発明は、セキュリティ方法／システムとして説明され得る。あるいはまた、本発明は、検証方法／システムとして説明され得る。本発明は、完全性、健全性及び／又はゼロ知識の暗号的に検証可能な保証に関連する（がこれに限定されない）利点を提供することができる。あるいはまた、本発明は、エンティティが正しい又は適切な検証鍵Ｖ_ｋの所有を証明することができる、ブロックチェーンにおける検証鍵の記録を可能にするか又は少なくとも容易にすることができる。あるいはまた、本発明は、分散計算の性能を制御するための制御メカニズムを提供し、効率及びセキュリティを向上させるものとして説明され得る。

本発明によると、コンピュータ実施方法が提供されてよく、該コンピュータ実施方法は：ブロックチェーントランザクションに関連付けられるリディームスクリプト（ｒｅｄｅｅｍ ｓｃｒｉｐｔ）を取得する取得ステップであって、第１スクリプトが、コマンドの第１セットと、１つ以上の暗号ハッシュ値とを含む取得ステップと；コマンドの第２セットと、複数の要素の１つ以上のサブセットであって、複数の要素が検証鍵を集合的に形成し、１つ以上のサブセットが検証鍵の各要素を集合的に含む、前記複数の要素の１つ以上のサブセットと、第１スクリプトと、第２スクリプトを生成するコンピュータシステムに関連付けられる識別子とを含む、第２スクリプトを生成する生成ステップと；１つ以上の暗号ハッシュ値が検証鍵の１つ以上のサブセットに一致するという決定に関連して、コマンドの第１セット及びコマンドの第２セットを実行することに少なくとも部分的に基づいて、コンピュータシステムが検証鍵へのアクセスを有することの証明書を生成するステップと；を含む。

複数の要素のうちのある要素は、楕円曲線上の点であってよい。

コマンドの第１セット及びコマンドの第２セットは集合的に、検証鍵の１つ以上のサブセットのうちのあるサブセットに少なくとも部分的に基づいて、１つ以上の暗号ハッシュ値のうちの第１暗号ハッシュ値がハッシュ出力に一致するかどうかを判断する命令を含んでよい。

ハッシュ出力は、ＳＨＡ－２５６及びＲＩＰＥＭＤ－１６０のような暗号ハッシュアルゴリズムを使用して、例えばＳＨＡ－２５６と、次いでＲＩＰＥＭＤ－１６０を使用して入力を連続的にハッシュすることによって生成されてよい。

好ましくは、方法は、検証鍵の１つ以上のサブセットを識別することと、検証鍵の１つ以上のサブセットの各サブセットについて、１つ以上の暗号ハッシュ値は、各対応する暗号ハッシュ値を含む。

好ましくは、方法は、生成された証明書を検証することを条件として、トランザクションによって妨げられた（ｅｎｃｕｍｂｅｒｅｄ）デジタル資産の制御をコンピュータシステムに移転するステップを更に含んでよい。

好ましくは、方法は、第１スクリプトを第２コンピュータシステムから取得するステップを更に含んでよく、第２コンピュータシステムは、デジタル資産の少なくとも一部を寄与した。

トランザクションは、ビットコインベースのプロトコルに従うＰ２ＳＨトランザクションのような、Ｐａｙ－ｔｏ－Ｓｃｒｉｐｔ－Ｈａｓｈ（Ｐ２ＳＨ）トランザクションであってよい。

好ましくは、検証鍵の少なくとも一部は、５１２バイト以上のサイズであり、５２０以下のサイズである。場合によっては、検証鍵のすべてが、５１２バイト以上のサイズであり、５２０以下のサイズである。

好ましくは、第１スクリプトは、５８バイト以上のサイズであり、１０４バイト以下のサイズであり、第２スクリプトは、１６２８バイト以上のサイズであり、１６５０バイト以下のサイズである。

トランザクションは、ブロックチェーンプロトコルに従う標準のトランザクションであってよい。

１つ以上のサブセットはちょうど１つのサブセットであってよく、１つのサブセットは検証鍵を含む。

第１スクリプトは、コンピュータシステムに関連付けられる公開鍵を更に含んでよく、コンピュータシステムに関連付けられる識別子は、公開鍵に対応する秘密鍵を使用して生成されるデジタル署名であってよく、コンピュータシステムが検証鍵へのアクセスを有することの証明書は、少なくとも部分的にデジタル署名及び公開鍵に更に基づいてよい。

また、プロセッサと、該プロセッサによる実行の結果として、システムに、特許請求に係る方法のいずれかを実行させる実行可能命令を含むメモリとを含むシステムを提供することが望ましい。

また、コンピュータシステムのプロセッサによる実行の結果として、コンピュータシステムに、特許請求に係る方法のいずれかを少なくとも実行させる実行可能命令を格納している非一時的コンピュータ読取可能記憶媒体を提供することが望ましい。本発明の方法に関連して上述される任意の特徴は、対応システムにも適用され得る。

本発明のこれら及び他の態様は、本明細書で説明される実施形態から明らかになり、実施形態に関連して解明されるであろう。本発明の実施形態は、次に単なる例示として、添付の図面に関連して説明される：

様々な実施形態を実装することができるブロックチェーン環境を示す図である。 様々な実施形態に従ってプロトコルを実装するために利用され得るコンピューティング環境を示す図である。 検証可能な計算の実行に適した環境の図である。 ブロックチェーン上に検証鍵を記録するのに適した、ブロックチェーンプロトコルに従ったデータ構造の図であり、作業者は正しい検証鍵Ｖ_ｋの所有を証明することができる。 本開示で説明される様々な実施形態によるロッキングトランザクションの図である。 少なくとも１つの実施形態による、リディームスクリプトを生成するためのプロセスを示す図である。 スマートコントラクトの実行に基づいて、デジタル資産のアンロックするときに計算のプルーフ（ｐｒｏｏｆ）を含むようにプロトコルが修正される図である。 本開示の少なくとも１つの実施形態を実施するために使用され得るコンピューティングデバイスを示す図である。

まず、本開示の一実施形態によるブロックチェーンに関連付けられる例示のブロックチェーンネットワーク１００示す図１を参照する。本実施形態では、例示のブロックチェーンネットワーク１００は、ピアツーピア分散電子デバイスとして実装されるブロックチェーンノードを含み、その各々が、少なくとも部分的にノード１０２のオペレータ間で合意されるブロックチェーンプロトコルに従うオペレーションを実行するソフトウェア及び／又はハードウェアのインスタンスを実行する。いくつかの例において、「ノード」は、ブロックチェーンネットワークの間で分散されるピアツーピア電子デバイスを指す。ブロックチェーンプロトコルの一例がビットコインプロトコルである。

いくつかの実施形態において、ノード１０２は、（例えばデータセンター内のサーバによって、クライアントコンピューティングデバイス（例えばデスクトップコンピュータ、ラップトップコンピュータ、タブレットコンピュータ、スマートフォン等）によって、コンピューティングリソースサービスプロバイダの分散システム内の複数のコンピューティングデバイスによって、あるいは図８のコンピューティングデバイス８００のような任意の適切な電子クライアントデバイスによって）任意の適切なコンピューティングデバイスから構成され得る。いくつかの実施形態において、ノード１０２は、トランザクション１０４のように提案されたトランザクションを表すデータメッセージ又はオブジェクトを受け取るための入力を有する。ノードは、いくつかの実施形態では、ノードが維持する情報について、例えばトランザクション１０４の状態の情報についてクエリ可能である。

図１に示されるように、ノード１０２のいくつかは、ノード１０２のうちの１つ以上の他のノードに通信可能に結合される。このような通信結合は、有線又は無線通信のうちの１つ以上を含むことができる。実施形態において、ノード１０２は各々、ブロックチェーン内のすべてのトランザクションの「台帳」の少なくとも一部を維持する。このようにして、台帳は分散台帳となる。台帳に影響を与えるノードによって処理されるトランザクションは、台帳の完全性が維持されるように、他のノードのうちの１つ以上によって検証可能である。

どのノード１０２が他のどのノードと通信することができるかに関しては、メッセージが、ブロックチェーンプロトコルが転送すべきことを示すメッセージであると想定して、ノード間で渡されるメッセージが例示のブロックチェーンネットワーク１００全体（又はその何らかの重要な部分）に伝搬することができるように、例示のブロックチェーンネットワーク１００内のノードの各々が、ノード１０２のうちの１つ以上の他のノードと通信することができることで十分である。１つのそのようなメッセージは、ノード１０２のうちの１つ、例えばノード１０２Ａによる、提案されたトランザクションの公開であってよく、これは、次いでパス１０６のようなパスに沿って伝搬するであろう。別のそのようなメッセージは、ブロックチェーンに含めるために提案された新たなブロックの公開であってよい。

一実施形態において、ノード１０２のうちの少なくともいくつかは、暗号問題を解決することのように複雑な計算を実行するマイニングノードである。暗号問題を解決するマイニングノードは、ブロックチェーンのための新たなブロックを作成し、その新たなブロックをノード１０２のうちの他のノードにブロードキャストする。ノード１０２のうちの他のノードは、マイニングノードの作業を確認し、確認時に、（例えばブロックチェーンの分散台帳にブロックを追加することによって）ブロックをブロックチェーン内に受け入れる。いくつかの例では、ブロックはトランザクションのグループであり、しばしば、タイムスタンプと前のブロックの「フィンガープリント」（例えばハッシュ）でマークされる。このようにして、各ブロックは前のブロックにリンクされるようになってよく、それによりブロックチェーン内のブロックをリンクする「チェーン」が生成される。実施形態において、有効なブロックは、ノード１０２の合意によってブロックチェーンに追加される。また、いくつかの例では、ブロックチェーンは、検証されたブロックのリストを含む。

一実施形態において、ノード１０２のうちの少なくともいくつかは、本開示で説明されるように、トランザクションを検証する検証ノードとして動作する。いくつかの例では、トランザクションは、デジタル資産（例えば複数のビットコイン）の所有権のプルーフと、デジタル資産の所有権／制御を受け入れる又は移転するための条件を提供するデータを含む。いくつかの例において、「アンロッキングトランザクション」は、前のトランザクションのＵＴＸＯによって示されるデジタル資産の少なくとも一部を、ブロックチェーンアドレスに関連付けられるエンティティに再関連付けする（例えば所有権又は制御を移転する）ブロックチェーントランザクションを指す。いくつかの例において、「前のトランザクション」は、アンロッキングトランザクションによって参照されているＵＴＸＯを含むブロックチェーントランザクションを指す。いくつかの実施形態では、トランザクションは、所有権又は制御が移転され得る（「アンロックされる」）前に満たさなければならない条件で該トランザクションを妨げる「ロッキングスクリプト」を含む。

いくつかの実施形態では、ブロックチェーンアドレスは、デジタル資産の少なくとも一部の制御が移転／再関連付けされているエンティティに関連付けられる英数字の文字列である。いくつかの実施形態で実装されるいくつかのブロックチェーンプロトコルでは、エンティティに関連付けられる公開鍵とブロックチェーンアドレスとの間に１対１の対応が存在する。いくつかの実施形態において、トランザクションの検証は、ロッキングスクリプト及び／又はアンロッキングスクリプトで指定された１つ以上の条件の検証を含む。トランザクション１０４の検証が成功すると、検証ノードはトランザクション１０４をブロックチェーンに追加し、それをノード１０２に分配する。

本発明の例示的な適用に関連して本明細書で説明されるシステム及び方法は、ブロックチェーンシステムにおけるロッキングトランザクションの実行に関する。ロッキングトランザクションは、アンロッキングトランザクションを検証することができる制約を初期化するトランザクションを指してよい。本発明は、いくつかの例示的な用途において、トランザクションを安全に列挙して交換するために使用され得る。スマートコントラクトのコンテキストでは、作業者によって公開された回路の正しい実行のプルーフの公開記録（例えばブロックチェーンに記録される）と検証鍵を有することが有利である可能性があり、それによって、誰か（例えばブロックチェーンのノード）が計算とプルーフの有効性を検証することを可能にする。しかしながら、ブロックチェーン上にデータの大きなブロック（例えば複数の楕円曲線点を含み得る大きな鍵）を記録することには課題がある。例えばビットコインベースのブロックチェーンネットワークでは、標準トランザクションを利用するプロトコルは、全体として１６５０バイト以下のサイズのロッキングスクリプト及びアンロッキングスクリプトに制約される可能性があり、リディームスクリプト（ｒｅｄｅｅｍ ｓｃｒｉｐｔ）（利用される場合）は、５２０バイト以下のサイズに制限される可能性がある。

検証可能な計算は、計算のプルーフの生成を可能にする技術である。例示的な実施形態では、このような技術をクライアントによって利用して、入力ｘに対する関数ｆの評価を、本明細書で作業者と呼ばれる別のコンピューティングエンティティにアウトソースすることができる。場合によって、クライアントは計算上制限されており、クライアントは関数の評価を実行することが実行不可能となる（例えばクライアントが利用可能な計算リソースを使用する計算の期待されるランタイムは、最大許容しきい値を超える）が、そうである必要はなく、クライアントは、一般に言うと、計算ランタイムや計算コスト（例えば関数の評価を実行する計算リソースを割り当てるための経済的コスト）等の任意の適切な基準に基づいて、入力ｘに対する関数ｆの評価を委任してよい。

作業者は、一実施形態において、図１及び図８に関連して説明されるもののような、本開示の他の箇所でより詳細に説明されるブロックチェーンノードのような任意の適切なコンピューティングエンティティである。一実施形態では、作業者（例えばブロックチェーンノード）は、入力ｘに対して関数ｆを評価し、上述のクライアント及び／又はブロックチェーンネットワークの他のノードのような他のコンピューティングエンティティによって確かめることができる出力ｙと出力ｙの正当性のプルーフπを生成する。プルーフは、引数とも呼ばれることがあるが、実際の計算よりも速く確かめることができ、したがって、上述の作業者によって生成された出力の正当性を決定するために、入力ｘに対して関数ｆを再計算する代わりに、プルーフの正当性を確かめることによって、計算オーバーヘッドを低減することができる（例えば電力オーバーヘッドと、電源投入及び実行する計算リソースに関連付けられるコストを低減する）。ゼロ知識検証可能計算では、作業者は、該作業者が特定の特性を有する入力を知っているという証明書をクライアントに提供する。

知識のゼロ知識証明（ｚｅｒｏ－ｋｎｏｗｌｅｄｇｅ ｐｒｏｏｆ ｏｆ ｋｎｏｗｌｅｄｇｅ）の有効な変形は、ｚｋ－ＳＮＡＲＫ（Ｓｕｃｃｃｉｎｃｔ Ｎｏｎ－ｉｎｔｅｒａｃｔｉｖｅ ＡＲｇｕｍｅｎｔ ｏｆ Ｋｎｏｗｌｅｄｇｅ）である。一実施形態では、全てのペアリングベースのｚｋ－ＳＮＡＲＫｓは、作業者が一般的なグループオペレーションを使用して複数のグループ要素を計算し、検証者が複数のペアリング積方程式を使用してプルーフをチェックするプロセスを含む。一実施形態では、線形対話型証明は有限のフィールドにわたって機能し、作業者及び検証者のメッセージは、フィールド要素のベクトルを決定するために使用可能な情報を含むか、符号化するか又は他の方法で含む。

一実施形態において、本明細書で説明されるシステム及び方法は、ブロックチェーンのマイニングノードが、計算（例えば入力ｘに対する関数ｆの評価）を１回実行し、出力の正当性を確かめるために使用できるプルーフを生成することを可能にし、ここで、プルーフの正当性を評価することは、関数を評価することよりも計算コストが低い。このコンテキストでは、オペレーション及びタスクのコスト（すなわち、どのくらい高価か）は、オペレーション又はタスクを実行する計算の複雑さを指し得る。一実施形態では、計算の複雑さは、ソートアルゴリズムを実行する平均計算コスト又は最悪ケースの計算コストを指す－例えばヒープソートアルゴリズム及びクイックソートアルゴリズムは両方ともｏ（ｎ ｌｏｇｎ）の平均計算コストを有するが、クイックソートは、ｏ（ｎ^２）の最悪ケースの計算コストを有し、一方、ヒープソートは、ｏ（ｎ ｌｏｇｎ）の最悪ケースの計算コストを有する。一実施形態では、入力ｘにおける関数ｆを評価する平均計算コスト及び／又は最悪ケースの計算コストは、プルーフの正当性を評価するコストよりも悪い。したがって、本明細書で説明されるシステム及び方法の使用は非常に有利であり、例えばより計算コストの高いコントラクトを実行することを可能にし得る。なぜなら、そのようなコントラクトは、そのようなコンタクトはブロックチェーンを比例的に検証するために必要な時間を増加させないからである。更なる利点は、検証者システムの電力消費の低減を含んでよく、それにより、検証者コンピュータシステムの効率を改善し、プルーフの正当性を評価する際に、そのような検証者コンピュータシステムを実行することに関連付けられるエネルギーコストを低減することができる。現在、スマートコントラクトはすべてのノードにおいて実行されて、検証されなければならない－この制約はスマートコントラクトの複雑さを制限する。本明細書で説明される方法及びシステムを使用して、正当性のプルーフを生成するためにコントラクトを一度実行することによってブロックチェーンの効率を改善し、作業者によって提供される正当性のプルーフ及びクライアントによって提供される検証鍵に基づいて、ブロックチェーンのすべてのノードがコントラクトの有効性を確かめることができるシステムを実装することができる。このようにして、ブロックチェーンのノードによって集合的に実行することができ、かつ／又は計算コストがより高いスマートコントラクトの計算を可能にするスマートコントラクトのスループットを増加させることによって、ブロックチェーンの効率が改善される。

一実施形態では、検証鍵Ｖ_ｋ又はその一部は、ゼロ知識プロトコルのセットアップ段階で生成され、かつプルーフπとともに使用される、公開パラメータ及び入力／出力データから抽出でき、作業者によって提供される正当性計算の主張されたプルーフ（ａｌｌｅｇｅｄ ｐｒｏｏｆ）を確かめる。例えば上記及び下記でより詳細に説明されるように、ロッキングスクリプトを許容するシステム及び方法は、検証鍵Ｖ_ｋを変更から保護し、プルーフπの有効性をチェックし、トランザクション検証中にブロックチェーン上でゼロ知識プロトコルの実行を可能にする。したがって、本開示は、ブロックチェーン上で検証鍵を記録するのに適したシステム及び方法を提示し、この場合、作業者は、オペレーションのセットの実行（例えばスマートコントラクトの実行）のためにデジタル資産を取り返すために、（例えばクライアントによって発行された）正しい検証鍵Ｖ_ｋの所有を証明することができる。

図２は、様々な実施形態に従って、プロトコルを実装するために利用され得るコンピューティング環境２００を示している。プロトコルは、正当性のプルーフを格納し、「ｃｏｒｒｅｃｔ－ｂｙ－ｃｏｎｓｔｒｕｃｔｉｏｎ」暗号手法とスマートコントラクトを組み合わせるために、ブロックチェーン技術を用いて実装されてよい。一実施形態では、公的な検証可能な計算スキームは、３つ段階、すなわちセットアップ段階、計算段階及び検証段階を含む。

セットアップ段階は、計算タスクの実行をアウトソースするためにプロセスの一部として実行され得る。クライアントは、以下で言及されるように、計算タスクの実行を作業者に委任する顧客又はクライアントコンピュータシステムのようなエンティティを指してよく、これは、異なるコンピュータシステムであってもよい。クライアントは、一般的に言うと、これらに限定されないが、計算リソース、計算リソースの欠如、タスクを実行するためにクライアントコンピュータシステムを利用することに関連付けられる経済的コスト、タスクを実行するためにクライアントコンピュータシステムを利用することに関連付けられるエネルギーコスト（例えば電力のためにバッテリに依存するモバイルデバイス又はラップトップは、作業者を利用して計算集約的タスクを実行し、それにより、電力を節約し、バッテリ駆動型デバイスの使用を延長し得る）等の様々な理由により、計算タスクの実行を委任してよい。

一実施形態において、セットアップ段階は、クライアント、顧客、組織の従業員又は他の任意の適切なエンティティが、正確な意味を有する正式な言語でコントラクトを書くことを含む。コントラクトは、Ｃ又はＪａｖａ（登録商標）のような高水準プログラミング言語で書かれてもよい。一般的に言うと、コントラクトは、コンピュータシステムによって操作できるフォーマットに変換される又は変換することができる任意の言語又はシンタックスで表現され得る。一実施形態では、限定された目的で、ドメイン固有の言語がタイプセーフティを提供してよく、制限された表現度が利用されてよい。生成されるソースコードは、コントラクトの正確な説明であってよい。

コンパイラ２０２は、コンピュータシステムの１つ以上のプロセッサによって実行されると、システムにソースコード２０６を入力として取らせ、回路を生成する実行可能なコードを含む、任意のハードウェア、ソフトウェア又はそれらの組合せであってよい。コンパイラ２０２は、バイナリコードのような機械読取可能フォーマットにコンパイルされた命令に基づいて命令を実行又は実施するコンピュータプログラムを指してよい。コンパイラ２０２が図示されているが、インタプリタ、アセンブラ及び他の適切なソフトウェア及び／又はハードウェアコンポーネントを利用してソースコードを回路に変換してもよいことに留意されたい。一実施形態では、回路は、フィールドＦから値を運び、論理及び／又は算術ゲートに接続するワイヤを備える算術回路である。一実施形態では、回路Ｃは、システムによって使用されて、元の回路Ｃの完全な説明を提供する多項式のセットを含む二次プログラムＱ ２０８を生成する。

一実施形態において、コンパイラ２０２は、これらに限定されないが、プリプロセッサ命令、スタティックイニシャライザ、グローバル及びローカル関数、ブロックスコープ変数、アレイ、データ構造、ポインタ、関数呼び出し、関数演算子（例えばファンクタ）、条件及びループ、算術及びビットワイズのブール演算子を含む、Ｃ又はＪａｖａ（登録商標）といったプログラミング言語の実質的なサブセットを認識することができる。一実施形態において、コンパイラ２０２は、プログラミング言語の規格によるコマンドのセット全体はサポートしない（これは、場合によっては、再帰的アルゴリズムを禁止することのように、特定のタイプのアルゴリズムがスマートコントラクトで実行されることを防止するよう意図されることがある）。一実施形態において、コンパイラは、ソースコードの表現を算術ゲート言語に拡張し、算術回路を生成する。回路の実装は、過去に、「ＺＥＲＯ－Ｋｎｏｗｌｅｄｇｅ Ｃｏｎｔｉｎｇｅｎｔ Ｐａｙｍｅｎｔｓ Ｒｅｖｉｓｉｔｅｄ:Ａｔｔａｃｋｓ ａｎｄ Ｐａｙｍｅｎｔｓ ｆｏｒ Ｓｅｒｖｉｃｅｓ」においてＣａｍｐａｎｅｌｌｉ,Ｍ.等（２０１７）により、「Ｃｉｒｃｕｉｔｓ ｏｆ Ｂａｓｉｃ Ｆｕｎｃｔｉｏｎｓ Ｓｕｉｔａｂｌｅ Ｆｏｒ ＭＰＣ ａｎｄ ＦＨＥ」において、Ｔｉｌｌｉｃｈ,Ｓ.及びＳｍａｒｔ,Ｂにより考えられている。算術回路は、コンパイラ２０２又は他の任意の適切なハードウェア、ソフトウェア又はそれらの組合せ（例えば図２に図示されていないソフトウェアモジュール）によって、二次算術問題（ＱＡＰ：Ｑｕａｄｒａｔｉｃ Ａｒｉｔｈｍｅｔｉｃ Ｐｒｏｂｌｅｍ）を構築するために利用されてよい。二次プログラム（ｑｕａｄｒａｔｉｃ ｐｒｏｇｒａｍ）は、一実施形態に従って、クライアント（例えば鍵生成及び検証）及び作業者（例えば計算及びプルーフ生成）のための暗号ルーチンのセットにコンパイルされる。いくつかの実施形態では、英国特許出願第１７１８５０５．９号に記載されるような算術回路最適化技術が、労働者がスマートコントラクトの結果を決定するために必要なリソースを減らすために利用されてよい。

一実施形態では、鍵生成器２０４は、コンピュータシステムの１つ以上のプロセッサによって実行されると、システムに二次プログラムを形成する評価鍵及び検証鍵を生成させる実行可能コードを含むハードウェア、ソフトウェア又はそれらの組合せである。二次プログラムとしての計算を符号化するための技術は、Ｇｅｎｎａｒｏ,Ｒ.等（２０１３）による「Ｑｕａｄｒａｔｉｃ Ｓｐａｎ Ｐｒｏｇｒａｍｓ ａｎｄ Ｓｕｃｃｉｎｃｔ ＮＩＺＫｓ ｗｉｔｈｏｕｔ ＰＣＰｓ」において考えられている。一実施形態では、二次算術問題（ＱＡＰ） Ｑは、フィールドＦ上の回路Ｃを符号化し、ｍ＋１多項式のセットを含む：
Ｖ＝｛ｖｋ（ｘ）｝，Ｗ＝｛ｗｋ（ｘ）｝，Ｙ＝｛ｙｋ（ｘ）｝
ここで、０≦ｋ≦ｍである。ターゲット多項式ｔ（ｘ）も定義される。Ｆのｎ個の要素を入力として取り、ｎ'個の要素を出力とする関数ｆとし、Ｎ＝ｎ＋ｎ'を所与とすると、Ｑは、｛ｃ_１,...,ｃ_Ｎ｝∈Ｆ^Ｎがｆの入力と出力のグループの有効な割り当てであり、係数のリスト｛ｃ_Ｎ＋１,...,ｃ_ｍ｝が存在する場合、ｔ（ｘ）がｐ（ｘ）を除算するように、ｆを計算する：

したがって、実施形態においてｈ（ｘ）・ｔ（ｘ）＝ｐ（ｘ）のような何らかの多項式ｈ（ｘ）が存在しなければならない。Ｑのサイズはｍであり、その次数（ｄｅｇｒｅｅ）はｔ（ｘ）の次数である。

一実施形態では、算術回路のＱＡＰを構築することは、回路内の各乗算ゲートｇに対して、任意のルートｒ_ｇ∈Ｆを選択することと、

となるようにターゲット多項式を定義することとを含む。一実施形態では、インデックスｋ∈｛１．．．ｍ｝は、回路の各入力及び乗算ゲートからの各出力に関連付けられる。Ｖにおける多項式は、各ゲートへの左入力を符号化し、Ｗは各ゲートへの右入力を符号化し、Ｙは出力を符号化する。例えばｋ番目のワイヤがゲートｇへの左入力の場合、ｖ_ｋ（ｒ_ｇ）＝１であり、そうでなければｖ_ｋ（ｒ_ｇ）＝０である。したがって、特定のゲートｇ及びそのルートｒ_ｇについて、前述の式を次のように簡略化することができる：

ゲートの出力値は、その入力の積に等しい。可分性チェックは、ｐ（ｒ_ｇ）＝０となるように、ｔ（ｘ）の各ゲートｇとルートｒ_ｇに対して１つずつ、ｄｅｇ（ｔ（ｘ））分離チェック（ｓｅｐａｒａｔｅ ｃｈｅｃｋｓ）に分解される。加算ゲートと乗算定数ゲート（ｍｕｌｔｉｐｌｉｃａｔｉｏｎ－ｂｙ－ｃｏｎｓｔａｎｔ ｇａｔｅｓ）はＱＡＰのサイズ又は次数に寄与しない。

一実施形態では、ＱＡＰは、フィールドＦ_ｐ上で定義され、ここで、ｐは、大きい素数（ｌａｒｇｅ ｐｒｉｍｅ）である。一実施形態では、Ｆ_ｐ上のＱＡＰが、加算及び乗算モジュロｐに関して表すことができる任意の関数を効率的に計算することが望ましい。算術分割ゲートは、［０,２^ｋ－１］内であることが知られている算術ワイヤａ∈Ｆｐをｋ個のバイナリ出力ワイヤに変換するよう設計されることがある。したがって、ブール関数は、算術ゲートを用いて表現できることになる。例えばＮＡＮＤ（ａ,ｂ）＝１－ａｂである。各埋め込みブールゲートには１つの乗算演算のみかかる。さらに、分割（ｓｐｌｉｔ）のような新しいゲートは、スタンドアロンとして定義でき、他のゲートとともに構成できる。［０,２^ｋ－１］内にあることが知られている入力ａ∈Ｆ_ｐを所与として、分割ゲートは、Σ^ｋΣ^２ｉ－１ａ_ｉ＝ａのようなａの２進数ａ１，．．．，ａｋを保持する、ｋ個のワイヤを出力し、各ａ_ｉは０又は１のいずれかである。

最終的に、すべての証明者及び検証者によって使用される公開パラメータは、セットアップ段階の一部としてシステムによって生成される。評価鍵Ｅ_Ｋ及び検証鍵Ｖ_Ｋは、クライアントによって選択された秘密値を使用して導出されることに留意されたい。鍵生成器２０４は、鍵生成アルゴリズムに関連して二次算術プログラム（ＱＡＰ）を利用して、評価鍵Ｅ_Ｋ２１０及び検証鍵Ｖ_Ｋ２１２を生成することができる。

一実施形態では、計算タスクを実行することは、作業者による入力２１６に対する関数の計算（すなわち、ｆ（ｘ）を評価するプロセス）を含む。実施形態において、作業者は、クライアントが計算タスクを委任することができる任意の適切なコンピュータシステムである。入力２１６は、一実施形態では、作業者に関連付けられる秘密鍵を使用して生成されたデジタル署名のような、作業者の身元を証明する情報を含む。一実施形態では、作業者は、成功した計算の結果として、クライアントがデジタル資産を転送するコンピュータシステムである。クライアントは、一実施形態において、入力ｘ及び評価鍵Ｅ_Ｋを作業者に提供し、作業者は、計算ルーチンに対して評価モジュール２１４を使用して、出力ｙを計算し（すなわち、ｙ＝ｆ（ｘ）であり、入力はｘであり、関数はｆである）、評価鍵Ｅ_Ｋ２１０を使用して、正当性のプルーフ２１８を生成する。評価モジュールは、一実施形態では、コンピュータシステムの１つ以上のプロセッサによって実行されると、コンピュータシステムに、ＱＡＰ２０８の内部回路ワイヤの値を評価させ、ＱＡＰの出力ｙを生成させる命令を含むハードウェア及び／又はソフトウェアである。

一実施形態では、二次プログラムの各多項式ｖ_ｋ（ｘ）∈Ｆは、双線形グループ内の要素ｇ^{ｖｋ（ｓ）}にマッピングされ、ここで、ｓは、クライアントによって選択された秘密値であり、ｇは、グループの生成器であり、Ｆは、ｇの離散対数のフィールドである。一実施形態では、所与の入力に対して、作業者は回路を評価して、二次プログラムの係数ｃ_ｉに対応する内部回路ワイヤの出力及び値を得る。したがって、作業者は、ｖ（ｓ）＝Σ_{ｋ∈｛ｍ｝}ｃｋ・ｖｋ（ｓ）を評価してｇ^ｖ（ｓ）を取得し；ｗ（ｓ）及びｙ（ｓ）を計算し；ｈ（ｘ）＝ｐ（ｘ）／ｔ（ｘ）＝Σ^ｄｈ_ｉ・ｘ^ｉを計算し；評価鍵内のｈ_ｉ及びｇ^ｓ（ｉ）項を使用してｇ^ｈ（ｓ）を計算する。一実施形態では、正当性のプルーフ２１８は、（ｇ^ｖ（ｓ）、ｇ^ｗ（ｓ）、ｇ^ｙ（ｓ）、ｇ^ｈ（ｓ））を含み、検証者は双線形マップを使用して、ｐ（ｓ）＝ｈ（ｓ）・ｔ（ｓ）をチェックする。一実施形態では、プルーフπは、後に使用するためにブロックチェーン２２２上に格納されるか、あるいは証明者がこれらの各々と別々に対話することを必要とせずに、複数の当事者によって確認され得る。一実施形態では、正当性のプルーフの回路ストレージの評価は、トランザクションのロッキングスクリプトによって妨げられているリソース（例えばデジタル資産）をアンロックするために実行され得る。

一実施形態では、プルーフπはブロックチェーンネットワークにブロードキャストされ、検証者２２０はプルーフを検証するために使用される。一実施形態では、検証者２２０は、ブロックチェーンのノードのような計算エンティティである。場合によって、プルーフを確認するコンピューティングエンティティは、評価鍵Ｅ_Ｋ及び検証鍵Ｖ_Ｋを生成する同じコンピューティングエンティティであることに更に留意されたい。一実施形態では、ブロックチェーンのノードは、検証鍵Ｖ_Ｋとプルーフπを使用して支払いトランザクションを検証することができ、確認が成功した場合にコントラクトを検証することができる。プロトコルの１つの要件は、検証鍵Ｖ_Ｋを知っているとしても、作業者は不正確なプルーフを提供できないことである。したがって、このプロトコルでは、共通参照文字列（ＣＲＳ：ｃｏｍｍｏｎ ｒｅｆｅｒｅｎｃｅ ｓｔｒｉｎｇ）は、少なくとも評価鍵Ｅ_Ｋ及び検証鍵Ｖ_Ｋを公開するクライアント又は信頼できる第三者によって生成される。一実施形態では、公開された検証鍵Ｖ_Ｋは、任意の計算エンティティによって計算を確認するために使用され得る。いくつかの実施形態では、検証段階は、英国特許出願第１７１９９９８.５号に記載された技術に従うことができる、計算の検証に使用される要素を格納するブロックチェーンスクリプト（例えばビットコインベースのネットワーク）を使用して実行される。

本明細書で説明される技術を使用して、クライアントは、ブロックチェーントランザクションの受信者の身元等のトランザクションデータを部分的に難読化することができる。一実施形態では、アンロッキングスクリプトは、受信者のアドレス及び受信者の公開鍵を公開しない。しかしながら、場合によっては、トランザクションの値（例えば転送されるデジタル資産の量）が、ブロックチェーンネットワークのノードに対して可視であることがある。一実施形態では、上述及び下述される暗号技術は、クライアントによって、ロッキングスクリプトを二次算術プログラムへ変換し、作業者が算術プログラムを解いてプルーフを生成するために利用される。

一般的に言うと、クライアントは、カウンターパーティ又は作業者に支払うために、Ｐ２ＰＫ及びＰ２ＰＫＨのような標準トランザクション（例えばビットコインベースのブロックチェーンネットワークで定義される標準トランザクション）を使用することができる。例えば一実施形態では、クライアントは、Ｐ２ＰＫロッキングスクリプトを算術回路に変換し、回路から導出されたパズルを含む支払いトランザクションをブロードキャストする。カウンターパーティ又は作業者は、回路を受け取り、適切な入力（例えばクライアントと作業者との間の共有秘密又は作業者の秘密鍵を使用して生成されたデジタル署名等、作業者の身元を証明する情報）を提供し、回路を実行して正当性のプルーフπを生成する。一実施形態では、プルーフは、リソース（例えばデジタル資産）をアンロックするために使用され、さらに、カウンターパーティ又は作業者を識別する情報（例えばカウンターパーティ又は作業者に関連付けられる公開鍵及び／又はデジタル署名）が、難読化されたフォーマットでブロックチェーンに記録されない場合があり得る。

実施形態において、検証鍵及び対応するプルーフは、上述及び／又は下述される技術に従って生成される。したがって、検証者は、該検証者が、複数の楕円曲線乗算（例えば各公開入力変数に対して１つ）と５つのペアチェックを計算し、そのうちの１つが追加のペアリング乗算を含むように、検証鍵Ｖ_Ｋとプルーフπを与えられる：

検証鍵Ｖ_Ｋ、プルーフπ及び（ａ_１，ａ_２，．．．，ａ_Ｎ）を所与とすると、ｔ（ｘ）がｐ（ｘ）を分割すること、したがって、（ｘ_Ｎ＋１，．．．，ｘ_ｍ）＝ｆ（ｘ_０，．．．，ｘ_Ｎ）を確かめるために、検証者は、以下に従って進む。最初に、３つのα項：

のすべてをチェックする。ここで、

及び

である。次いで、検証者は、項β：

及び

をチェックする。最終的に、検証者は、可分性要件をチェックする：

ここで、

及び

である。

したがって、上述のセクションからの表記及び本開示で記載される例を検討すると、検証は、一実施形態に従って、以下の要素のペアチェックのセットを含む：

図３は、検証可能な計算の性能を調整するための図３００を示している。クライアント３０２、作業者３０４及び検証者３０６は、ブロックチェーンネットワークのノードであってよい。クライアント３０２は、任意の適切なコンピュータシステムであってよく、コンピュータシステムの１つ以上のプロセッサによって実行されると、コンピュータシステムにスマートコントラクト３０８を受け取らせる実行可能コードを含んでよい。一実施形態では、スマートコントラクト３０８は、Ｃ、Ｃ＋＋又はＪａｖａ（登録商標）のようなソースコードのような高水準プログラミング言語で符号化される。一実施形態では、コンパイラ、インタプリタ及び／又はアセンブラのようなソフトウェアを利用して、スマートコントラクト３０８を、フィールド

からの値を担持し、加算及び乗算ゲートに接続する「ワイヤ」からなる算術回路３１０に変換し得る。算術回路は、物理的ワイヤによって接続される一連の物理ゲート（例えば７４００シリーズのゲート、フリップフロップ、バッファ、デコーダ、マルチプレクサ等のトランジスタ－トランジスタ論理（ＴＴＬ）集積回路を使用する）を含む物理回路によって実装することができる論理回路を指してよいことに留意されたい。

一実施形態において、クライアント３０２は、算術回路３１０及び該回路への入力３１２を作業者３０４に提供する。回路３１０を使用して、元の回路の完全な説明を提供する多項式のセットを含む二次プログラムＱを生成してもよい。いずれの場合も、作業者３０４は、入力３１２において回路Ｃ又は二次プログラムＱを実行して、１つ以上の出力３１４を生成してよい。いくつかの実施形態では、作業者（すなわち、証明者）は、入力ワイヤに割り当てられた値がｘのそれらであり、中間値が、Ｃ内の各ゲートの正しいオペレーションに対応し、出力ワイヤに割り当てられた値がｙであるように、回路ワイヤへの値の割り当てである｛Ｃ，ｘ，ｙ｝についての有効なトランスクリプトを出力として取得することが期待され；請求された出力が正しくない（すなわち、ｙ≠Ｐ（ｘ））である場合には｛Ｃ，ｘ，ｙ｝についての有効なトランスクリプトが存在しない。実施形態において、作業者は、回路ワイヤの値のサブセットを提供することが期待され、回路ワイヤの値の選択されたサブセットは、作業者に事前には知られていない。

実施形態において、出力ｙ、内部回路ワイヤの値（又はそのサブセット）及び評価鍵ＥＫは、正当性のプルーフ３１６を生成するために使用される。プルーフπは、ブロックチェーン上に格納されることができ、作業者３０４が複数の当事者と別個に対話することを必要とせずに、それらの複数の当事者によって検証されることができる。このようにして、検証者３０６は、公開検証鍵ＶＫとプルーフπを使用して支払いトランザクションを検証することができ、それによりコントラクトを検証することができる。場合によっては、クライアント３０２は、検証に失敗した場合、支払いトランザクションによって妨げられているデジタル資産を取り戻してよい。

ブロックチェーンネットワーク上に検証鍵を記録するためのシステム及び方法が、本明細書で説明される。多くの場合、ブロックチェーンシステム又はネットワークは、上記のような通常の（標準的な）トランザクションに使用される。本開示の実施形態によれば、知識のゼロ知識の簡潔な非対話型引数（ｚｋ－ＳＮＡＲＫ）の実装を適用することによって、スマートコントラクトの作成及び処理のための提供システムを提供することが可能である。

一実施形態において、トランザクションは、それらの入力及び出力に埋め込まれたスクリプトとして知られる小さなプログラムを含み、これは、トランザクションの出力がどのようにして誰によってアクセスされ得るかを指定する。ビットコインプラットフォームでは、これらのスクリプトはスタックベースのスクリプト言語を使用して書かれる。ブロックチェーンは更に、ブロック内に格納することができるデータ量の最大データ閾値に関連する制約を課してよく、プロトコルは、最大許容サイズに関連する鍵のサイズ（例えば複数の楕円曲線点を符号化する検証鍵Ｖ_ｋ）に基づいて選択されてよい。例えばビットコインベースのプロトコルでは、ロッキングスクリプトとアンロッキングスクリプトの合計サイズは、一実施形態では、１６５０バイトを超えず、また、リディームスクリプトのサイズは５２０バイトを超えない。一実施形態では、アンロッキングスクリプト及び／又はリディームスクリプトは、検証鍵を符号化することに加えて命令（例えばオペコード）を含み、（例えばデジタル署名を検証することによって）作業者が検証鍵を所有していることを検証するための追加の命令及び／又はデータを更に含んでもよい。したがって、特に、実施形態において、より大きなセキュリティ及び／又はセキュリティの暗号的保証を提供し得る、より大きな鍵サイズの使用に関連して、上述の機能の一部又は全部を提供するスクリプトを生成することは難しい。

一実施形態では、ロッキングトランザクションの一部として、クライアントは、評価及び検証鍵を含む共通参照文字列（ＣＲＳ）を公開する。一実施形態では、ＣＲＳ＝｛Ｅ_Ｋ，ＶＫ｝であるが、前述のように、共通参照文字列は、任意の追加の適切な情報を含むことができることに留意されたい。評価鍵Ｅ_Ｋのサイズは、検討中の回路のサイズに少なくとも部分的に基づいている（例えば評価鍵Ｅ_Ｋを構成する要素の数は、回路の内部ゲートの数に対応し、かつ／又はそれに比例する）。検証鍵のサイズは、一実施形態では、入力及び出力のみに依存する。多くの場合、プルーフの公開記録（例えば証明者／作業者によって公開される、プルーフオブワーク又は正しい実行のプルーフ）及び対応する検証鍵Ｖ_Ｋを有することが有用であり－したがって、プルーフ及び検証鍵Ｖ_Ｋへのアクセスを有する任意のエンティティは、計算及びプルーフの有効性を検証することができる。一実施形態では、検証者３０６は、ブロックチェーンのノードのような任意の適切なエンティティである。いくつかの実施態様において、検証者３０６及びクライアント３０２は、同一のコンピュータシステムであることに更に留意されたい。言い換えると、いくつかの実施形態では、ブロックチェーンネットワークへのアクセスを有する任意のコンピュータシステムは、主張される証明者／作業者によって提供される計算及びプルーフの有効性を決定する検証プロセスを実行することができる。

いくつかのシステムでは、作業者の身元が分かっており、クライアントは作業者にコントラクトディレクトリの実行の支払いをすることができる。一実施形態では、クライアントは、作業者に関連付けられるアドレスを取得し、作業者に関連付けられるアドレスにデジタル資産を転送することによって、作業者に直接支払う。

様々な実施形態によると、図４は、ブロックチェーン上に検証鍵を記録するのに適した、ブロックチェーンプロトコルに従うデータ構造の図４００を示しており、ここでは、作業者は、オペレーションのセットの実行（例えばスマートコントラクトの実行）のためにデジタル資産を引き換える（ｒｅｄｅｅｍ）ために、（例えばクライアントによって発行された）正しい検証鍵Ｖ_Ｋの所有を証明することができる。さらに、いくつかの実施態様において、プロトコルは、コントラクトの実行に対する報酬を引き換える際に、正当性のプルーフを含めることを可能にする。一実施形態では、プロトコルは、既存のブロックチェーンプロトコルに従って実装される－例えば本明細書で説明されるシステム及び方法は、ビットコインプロトコルに対する修正を必要とせずに、既存のビットコインネットワークにおいて実装されることができる。

一実施形態では、ブロックチェーンシステムは、様々なタイプのトランザクションをサポートする。一実施形態では、サポートされるトランザクション（例えば標準トランザクション）は、ビットコインベースのシステムに従ったＰａｙ－ｔｏ－Ｓｃｒｉｐｔ－Ｈａｓｈ（Ｐ２ＳＨ）トランザクションのようなスクリプトハッシュベースのトランザクションである。一般的に言うと、スクリプトハッシュベースのトランザクションは、任意のトランザクションを指し、この場合、アンロッキングスクリプトの有効性を確認することは、指定された暗号ハッシュ値に一致するスクリプトを提供することを含む。例えばビットコインベースのＰ２ＳＨトランザクションでは、アンロッキングスクリプトは、リディームスクリプトを含み、ロッキングスクリプトは、アンロッキングスクリプトによって供給されるリディームスクリプトのハッシュが、指定された値に一致するという、少なくとも１つの条件を含む。例えばビットコインベースのシステムでは、ロッキングスクリプトは、以下に基づいて記述されてよい：
OP_HASH160 <20-byte hash of redeem script> OP_EQUAL

一実施形態では、図４に示す図４００は、検証鍵を符号化するのに適した構造の概要を示しており、この場合、作業者は、正しい検証鍵Ｖ_Ｋの所有を証明することができる。アンロッキングスクリプト４０２及びリディームスクリプト４０４は、Ｐａｙ－Ｔｏ－Ｓｃｒｉｐｔ－Ｈａｓｈ（Ｐ２ＳＨ）トランザクションに従って説明されるものに従って実装されてよい。場合によっては、ブロックチェーンプロトコルは、アンロッキングスクリプト４０２及び対応するロッキングスクリプトに対して最大合計サイズを強制し、かつ／又はリディームスクリプト４０４に対して最大合計サイズを強制する。例えばビットコインベースのシステムでは、Ｐ２ＳＨ標準トランザクションのリディームスクリプトは５２０バイト以下でなければならない。

アンロッキングスクリプト４０２は、対応するロッキングスクリプトに置かれる条件のセットを満たすデータパラメータの集合を含む。Ｐ２ＳＨトランザクションでは、ロッキングスクリプトは典型的に、ハッシュ値を含み、アンロッキングスクリプトがリディームスクリプトを含むことを要し、この場合、リディームスクリプトのハッシュは、ロッキングスクリプトで符号化されたハッシュ値と一致する。したがって、一実施形態では、ロッキングスクリプトは、制約のセットに少なくとも部分的に基づいてハッシュ値を符号化し、アンロッキングスクリプト内で提示されたリディームスクリプトが制約のセットを符号化することを要求することにより、条件のセットを間接的に符号化する。

具体的に言うと、図４に示されるアンロッキングスクリプト４０２は、デジタル署名４０６と、検証鍵Ｖ_Ｋの１つ以上のサブセット（例えば第１サブセット４１２及び最後のサブセット４１６）と、リディームスクリプト４０４と、実行された場合に、作業者が検証鍵Ｖ_Ｋを所有していることの暗号的に検証可能な保証を提供する追加のオペコード（本開示全体を通じてコマンド、オペレーション、関数及び命令とも呼ばれる）を含む。一実施形態では、デジタル署名４０６は、作業者の秘密鍵を使用して生成され、デジタル署名４０６の真正性は、作業者に関連付けられる公開鍵４０８を使用して暗号的に検証可能である。作業者に関連付けられる公開鍵４０８は、リディームスクリプト４０４内で符号化されてよい。したがって、デジタル署名４０６は、作業者が検証鍵Ｖ_Ｋを所有していることの証明書として作用する。

検証鍵Ｖ_Ｋは、一実施形態では、複数の要素

を含み、各要素は楕円曲線上の点である。検証鍵Ｖ_Ｋの要素は、１つ以上のサブセットに分割されてよい。例えば図４において、図４００は、少なくとも２つのサブセット、すなわち、第１サブセット４１２と最後のサブセット４１６が存在する例を示している－楕円は、第１サブセットと最後のサブセットとの間に追加のサブセットが存在してもよいことを示すが、必ずしもがそうである必要はない－例えば第２サブセットが最後のサブセット４１６である２つのサブセットが存在してもよい。実施形態において、このコンテキストで説明される各サブセットは、任意の他のサブセットと重複しない－言い換えると、要素

が１つのサブセット内にある場合、それは、いずれの他のサブセットのメンバーでもない。さらに、一実施形態において、検証鍵Ｖ_Ｋの各要素は、正確に１つのサブセットのメンバー内にある。

場合によっては、検証鍵Ｖ_Ｋは、複数の重複しないサブセットに分割されず、代わりに、アンロッキングスクリプト４０２内の単一ブロック（すなわち、その全体）として符号化され、単一ハッシュが、リディームスクリプト４０４内で符号化されることに留意されたい。アンロッキングスクリプトは、図４の説明に関連して上述及び下述される実施形態と同様の方法で機能し、この場合、ただ１つのハッシュ値が、検証鍵Ｖ_Ｋ全体をハッシュする出力に対して比較される。

アンロッキングスクリプト４０２の上述の説明を続けると、アンロッキングスクリプトは、リディームスクリプト４１０を更に含んでよい。一実施形態では、リディームスクリプトは、対応するロッキングスクリプト内で符号化された値に一致するハッシュ出力を生成するパラメータのセットである。一実施形態では、ロッキングスクリプト、アンロッキングスクリプト及びリディームスクリプトは、２ステップのプロセスで利用され、この場合、第１ステップ中に、リディームスクリプトがロッキングスクリプトに対してチェックされて、リディームスクリプトがロッキングスクリプトの条件を満たすかどうかを判断する。このロッキングスクリプトの条件は、リディームスクリプトのハッシュが所定の値に一致するという条件を含んでよい。一実施形態では、ＯＰ_ＨＡＳＨ１６０オペコードが利用され、これは、入力をまずＳＨＡ－２５６でハッシュ化し、次にＲＩＰＥＭＤ－１６０でハッシュ化してハッシュ出力を生成する。一実施形態では、ＯＰ_ＨＡＳＨ１６０オペレーションのハッシュ出力は、サイズが２０バイト（０ｘ１４バイト）である。

上述のように、アンロッキングスクリプト４０２は、オペコードを更に含んでよく、この場合、アンロッキングスクリプト４０２は、実行されると、作業者が検証鍵Ｖ_Ｋを所有していることを暗号的に検証可能な保証を提供するコマンド及びデータを含む。例えば検証鍵Ｖ_Ｋが２つのサブセットに分割される実施形態では、１つのそのようなアンロッキングスクリプトは、これは、ビットコインベースのシステムによって利用されるようなスタックベースのスクリプト言語に従って、命令及びデータ（角括弧内）を使用して示される、以下の方法で説明されてもよい：
OP_PUSHDATA1 <length of signature> <signature> OP_PUSHDATA1 <byte-length of VK1> VK1 OP_PUSHDATA1 <byte-length of VK2> VK2 OP_PUSHDATA1 <length of redeem script> <redeem script>
ここで、上述のように、コマンド（例えば「ＯＰ_ＰＵＳＨＤＡＴＡ１」）は角括弧を用いずに記述され、データは角括弧を用いて記述される（例えば「＜ｌｅｎｇｔｈ ｏｆ ｓｉｇｎａｔｕｒｅ＞」は、デジタル署名４０６のバイト単位のサイズに対応する１バイトの整数である）。ＶＫ１という表記は、検証鍵Ｖ_Ｋの第１サブセットを指し、ＶＫ２は、検証鍵Ｖ_Ｋの第２サブセットを指し、これにより、検証鍵Ｖ_Ｋ＝ＶＫ１||ＶＫ２及び

及び

となる。場合によっては、検証鍵Ｖ_Ｋの様々なサブセットは、同じサイズを有する（例えばすべて又は一部のサブセットが、検証鍵Ｖ_Ｋの同じ数の要素を含む）が、そうである必要はないことに留意されたい。加えて、＜ｒｅｄｅｅｍ ｓｃｒｉｐｔ＞は、以下で説明される例示のリディームスクリプトのような、リディームスクリプトの関数及びデータを指す。

一実施形態では、リディームスクリプト４０４は、ロッキングスクリプト内で符号化された１つ以上の条件を満たすために利用される。例えばロッキングスクリプトは、ハッシュ値と、アンロッキングスクリプトがルーチンを含むという条件を含んでよく、この場合、ルーチン上のハッシュ出力は、ロッキングスクリプトに含まれるハッシュ値に一致する出力値となる。ルーチンは、一実施形態では、リディームスクリプト４０４である。一実施形態では、リディームスクリプト４０４は、検証鍵Ｖ_Ｋのサブセットごとに、対応するハッシュ値と、作業者に関連付けられる公開鍵４１４と、実行された場合には、作業者が検証鍵Ｖ_Ｋを所有していることの暗号的に検証可能な保証を提供する追加のオペコード（本開示全体を通じてコマンド、オペレーション、関数及び命令とも呼ばれる）を含む。一実施形態では、リディームスクリプト４０４は、アンロッキングスクリプト４０２のコンテキストで実行される。一実施形態では、リディームスクリプトで符号化されたハッシュ値は、検証鍵Ｖ_Ｋの対応するサブセットがアンロッキングスクリプト４０２で現れるのと逆の順序で符号化される。例えば第１サブセット４１２がアンロッキングスクリプト４０２に最初に現れる場合、次いで、対応する第１ハッシュ４１４が、リディームスクリプト４０４に現れる最後のハッシュ値である。同様に、検証鍵の最後のサブセットに対応するハッシュ４１８は、検証鍵の他のサブセットのハッシュに対して、リディームスクリプト内に最初に現れる。このコンテキストでは、順序は、ハッシュ値の相対的順序を指すが、リディームスクリプト４０４内に符号化される他のデータ及び他のコマンドに対する順序を暗示するものでも、課するものではないことに留意されたい。前述の例を続けると、適切なリディームスクリプトは以下のように説明される：
OP_HASH160 <HVK1> OP_EQUALVERIFY OP_HASH160 <HVK2> OP_EQUALVERIFY <PubKey worker> OP_CHECKSIG
ここで、上述のように、コマンド（例えば「ＯＰ_ＨＡＳＨ１６０」）は角括弧を用いずに記述され、データは角括弧を用いて記述される（例えば＜ＨＶＫ１＞は、ＯＰ_ＨＡＳＨ１６０オペレーションをＶＫ１に適用した結果に対応する２０バイトの値である）。一実施形態では、リディームスクリプトは、クライアントによって作業者に提供される。リディームスクリプト４０４は、一実施形態では、暗号化攻撃（ｃｒｙｐｔｏｇｒａｐｈｉｃ ａｔｔａｃｋ）を容易にして検証鍵Ｖ_Ｋを決定するために使用可能な検証鍵Ｖ_Ｋの値に関するいずれの情報も直接提供しないことに留意されたい。

一実施形態では、ブロックチェーンプロトコルは、アンロッキングスクリプト４０２の最大サイズを１６５０バイトまでと定義する。ブロックチェーンプロトコルは、スタック上でプッシュすることができるデータの最も大きな全体のチャンクとして、最大５２０バイトのサイズを更に定義してもよい。一実施形態では、検証鍵の要素は、各々３２ビットサイズである。したがって、上述の制約に従ったアンロッキングスクリプト４０２は、以下を含み得る：

したがって、上述のアンロッキングスクリプト及びリディームスクリプトは、各要素が３２バイトのサイズである４５個の要素を有する検証鍵Ｖ_Ｋを符号化するために利用され得る。

図５は、本開示で説明される様々な実施形態に従ったロッキングトランザクションの図５００を示す。実施形態において、第１当事者５０２及び第２当事者５０４は、任意の適切な方法でコントラクトの条件に合意する。例えば両当事者は、オフラインでの契約条件のセット（例えば両当事者の代表者間の対面交渉、電話、電子メール又は任意の他の適切な通信媒体）に合意し得る。一実施形態では、契約条件はプログラム的に合意される－例えばコンピュータシステムは、契約（例えば履行価格（ｆｕｌｆｉｌｍｅｎｔ ｐｒｉｃｅ））についてのオファーを評価し、そのオファーを受け入れるかどうかを決定するためのパラメータを有するように構成される。例えば第１当事者と第２当事者は、第１当事者が、第２当事者が支払いに合意する価格の代価のトークンを第２当事者に売却し、発行することに合意する。一実施形態では、トークンは、物理的資産（例えば消費財及びサービス）、デジタル資産及びそれらの任意の組合せのために引き換えられ得る。

一実施形態では、第１当事者は、２つの入力（例えば入力５０８及び５１０）と２つの出力（例えば出力５１２及び５１４）を含むロッキングトランザクション５０６を作成し、署名がどのように検証されるべきか（例えばＯＰ_ＣＨＥＣＫＳＩＧを使用する）に関する指示（ｉｎｄｉｃａｔｉｏｎ）でそれらに署名する。一実施形態では、この指示は、動作モードの表示と、誰が支払うことができるか（例えば誰でも（ａｎｙｏｎｅ）支払うことができる）を示す修飾子を含む。一実施形態では、入力及び出力は、ＳＩＧＨＡＳＨ_ＳＩＮＧＬＥ及びＳＩＧＨＡＳＨ_ＡＮＹＯＮＥＣＡＮＰＡＹで署名される。一実施形態では、入力は、公称値（ｎｏｍｉｎａｌ ｖａｌｕｅ）のトランザクション量（例えば少数のサトシ（ｓａｔｏｓｈｉ））を含み、出力は、作業者のためのデジタル資産（その価値は、コントラクトの価値等の様々な要因に基づいて選択され得る）及びコントラクトの価値（例えば第２当事者５０４が、コントラクト条件に従って、第１当事者５０２に支払うことに同意する金額）を含むトランザクション量を含む。

一般的に言うと、動作モードは、ロッキングトランザクションの様々なフィールドのどのフィールドが、かつ／又はどのように署名されているかの指示を提供し得る。例えば第１動作モード（例えばＳＩＧＨＡＳＨ_ＡＬＬ）では、すべての署名可能なパラメータが署名されている。一実施形態では、これは、入力スクリプトを除くトランザクションのすべてのフィールドを含む。サポートされ得る動作モードの第２の例は、出力が署名されない動作モード（例えばＳＩＧＨＡＳＨ_ＮＯＮＥ）である－したがって、他のエンティティは、それらの入力シーケンス番号を変更することによってトランザクションを修正することができる。サポートされ得る動作モードの更に別の例は、入力が署名されるが、シーケンス番号がブランクであるモードである（例えばＳＩＧＨＡＳＨ_ＳＩＮＧＬＥ）。一実施形態では、一部の又はすべての動作モードがサポートされる。さらに、動作モードに加えて、単一の出力（又はより一般的には、出力の任意のサブセット）のみが署名されており、他の出力が任意のものであることに関して、別個の指示（例えばＳＩＧＨＡＳＨ_ＡＮＹＯＮＥＣＡＮＰＡＹ）が行われてもよい。

次に、ロッキングトランザクション５０６が第２当事者５０４に提供される。ロッキングトランザクションは、ロッキングトランザクションが正しいことを確認する第２当事者によって受け取られる。このコンテキストにおいて、ロッキングトランザクションの正当性とは、当事者間の事前の合意を正確に反映しているロッキングトランザクションを指し、正当性の検証は、例えばトークンに符号化された価格が当事者間で合意された費用（ａｇｒｅｅｄ－ｕｐｏｎ ｃｏｓｔ）であることと、コントラクトの条件が事前に合意された形式であることを確かめることを含む。一実施形態では、ロッキングトランザクションの正当性を判断することは、デジタル署名の真正性を確かめることを含む。

ロッキングトランザクションが正しいと判断すると、第２当事者５０４は、デジタル資産（例えば両当事者間の合意条件の一部として合意された支払い）及び作業者がコントラクトの実行のために支払うデジタル資産を含むことができる、新しい入力５１６を追加する。また、第２当事者５０４は、共通参照文字列を制約し、ＳＩＧＨＡＳＨ_ＳＩＮＧＬＥ又はＳＩＧＨＡＳＨ_ＡＬＬで署名する出力５１８を追加してよく、それを（例えばブロックチェーンネットワークに）ブロードキャストする。ロッキングトランザクションがブロードキャストされると、第１当事者がコントラクトの所有者とみなされ得る。一実施形態では、鍵（例えばＣＲＳの一部として含まれる検証鍵Ｖ_Ｋ及び評価鍵Ｅ_Ｋ）は、フィールドＦを使用して生成される。ここで、

は、フィールド及び対応する算術回路Ｃにおける関数であり、ここで、Ｑ＝（ｔ（ｘ），Ｖ，Ｗ，Ｙ）は、サイズｍで次数ｄの対応する二次算術プログラム（例えばＱＡＰ）である。加えて、実施形態において、

は、双線形マッピングであり、ｇは、

の生成器である。このコンテキストで説明される表現は、明瞭性のために選択される加法的表現（ａｄｄｉｔｉｖｅ ｒｅｐｒｅｓｅｎｔａｔｉｏｎ）であるが、他の表現（例えば指数関数的表現）が、本開示に従った実施形態のコンテキストで使用されてもよいことに留意されたい

一実施形態では、評価鍵Ｅ_Ｋ及び検証鍵Ｖ_Ｋは、ランダム値又は疑似ランダム値

を選択すること及び

を設定することによって構築される。言い換えると、一般的には：<a>＝a・gである。したがって、評価鍵Ｅ_Ｋは、

と定義され、検証鍵Ｖ_Ｋは、

と定義される。ここで、N＝N_in＋N_out、すなわち入力と出力の数である。一実施形態では、ペアリングマッピングを有する非対称ペアリングは、

と定義され、g_iは、

の生成器である。この場合、Ｖ_Ｋは以下のように定義される：

ここで、ry＝r_v・r_wである

上述のように、評価鍵Ｅ_Ｋと検証鍵Ｖ_Ｋはグループ要素で構成される。十分に高いカーディナリティ（ｃａｒｄｉｎａｌｉｔｙ）の任意のグループが適しているが、明確化の目的のために、本明細書で議論されるグループは楕円曲線であることに留意されたい。

一実施形態では、ペアリング関数の楕円曲線ベースの実装が存在する。一実施形態では、ブロックチェーンネットワークの暗号化は、ｓｅｃｐ２５６ｋ１楕円曲線のような楕円曲線に基づく。いくつかの実施形態では、ブロックチェーンにおいて鍵を割り当てるために必要とされる空間の量を決定及び／又は推定することが可能である。上述したように、検証鍵Ｖ_Ｋの要素のサブセットは、回路のサイズに関係せず、そのようなフィールドに必要とされる空間は、回路のサイズに依存しない。

場合によっては、標準ブロックチェーントランザクションの最大サイズは、ブロックの最大サイズに対応する。様々なブロックチェーンシステムは、ビットコインベースのシステムのように、様々な上限を有してもよく、例えば標準トランザクションは、定義された最大ブロックサイズが１ＭＢであり、最大標準トランザクションサイズが１００ＫＢである。ビットコインベースのシステムのようなブロックチェーンシステムでは、リディームスクリプトのサイズは５２０バイト以下である。リディームスクリプトの最大サイズは、一実施形態では、標準トランザクションの条件に依然として適合しているが、スタック上でプッシュできるデータの最大の全体的なチャンクである。アンロッキング入力スクリプト及びロッキングスクリプト（例えばＰ２ＰＫ、Ｐ２ＰＨ及び他）における上限は、一実施形態では、１６５０バイトである。一実施形態では、これは、スクリプトが１５個の公開鍵を格納するか又は他の方法で符号化することと同等である。一実施形態では、アンロッキングスクリプトは、入力スクリプト又は署名スクリプト（例えばＳｃｒｉｐｔＳｉｇ）と呼ばれ、出力スクリプト又はｓｃｒｉｐｔＰｕｂＫｅｙと呼ばれ得る以前のロッキングスクリプトに置かれた条件を満たすデータパラメータの集合を含む。

したがって、一実施形態では、リディームスクリプト及び対応する入力スクリプトは、可能な最大量のデータが添付されるように配置され、リディームスクリプト、対応する入力スクリプト及び／又は他のデータの配置は、少なくとも部分的に最大サイズに基づく。一実施形態では、アンロッキングスクリプトは、デジタル署名を含むか又は他の方法で符号化する。一実施形態では、図４は、ビットコインベースのシステムの標準タイプのトランザクションに従う署名を含む、最大の可能なアンロッキング及びロッキングスクリプトの構造を示す。一実施形態では、図４に示される構造は、ブロックチェーンシステムの制約内で可能な最大量のデータ（例えば標準トランザクションの最大サイズ）を添付するために利用されるが、他の実施形態では、その構造は、添付されるデータの最大量よりも少ない構造など、任意の他の適切な方法で定義されることに留意されたい。

一実施形態では、データは、標準トランザクションに加えて及び／又は標準トランザクションの代わりに、非標準トランザクションに記録される。一実施形態では、ハードコードされたスクリプト長は、１０キロバイト（ＫＢ）であり、ブロックチェーンのマイニングノードのセットは、そうでなければ非標準とみなされるスマート・トランザクションのためのトランザクションを受け入れる。言い換えると、いくつかの実施形態は、スマート・トランザクションとして識別可能な非標準トランザクションを利用し、ブロックチェーンネットワークの１つ以上のノードは、このようなトランザクションを受け入れる。

図６は、少なくとも１つの実施形態による、リディームスクリプトを生成するためのプロセス６００を説明するフローチャートを示す。プロセス６００は、例えば図３に関連して本開示の他の箇所で説明されるクライアントのような、任意の適切なコンピュータシステムによって実行されてよい。一実施形態では、リディームスクリプトは、図４に関連して説明されているもののように他の実施形態のコンテキストで生成される。回路Ｃ及び秘密に基づいて、クライアントは、プロセス６００を実行することによって、検証鍵Ｖ_Ｋを含む共通参照文字列ＣＲＳを決定する。一実施形態では、プロセスは、種々の関数を実行する種々のサブルーチンに依存するプロトコルに従う。例えばｎｏ_ＴＸ（ＡＲＧ）関数は、実施形態においてバイト（例えばビット）への変換を有する引数ＡＲＧのサイズをバイト単位で又は任意の適切な測定単位で測定するために使用される。一実施形態では、この関数を使用して、作成すべきロッキングスクリプトの数を決定する６０２。一実施形態では、ｎｏ_ＴＸ（ＡＲＧ）関数は、ＡＲＧ入力パラメータのバイトサイズを測定し、データ量を標準スクリプトに格納できる場合には１を返し、ＡＲＧが標準トランザクションにおけるスクリプトの最大サイズを超える場合には、関数ＡＲＧの入力に対応するデータ量を収容するのに必要とされる、出力（スクリプト）に必要なトランザクション数を返す。一実施形態では、関数は単に、入力ＡＲＧに対応するデータ量が、標準トランザクションにおけるスクリプトの最大サイズを超えるかどうかの指示、例えばＴＲＵＥ又はＦＡＬＳＥのブール指示又はそれらの任意の同等物（例えばＦＡＬＳＥ指示に等しい０の整数値及びＴＲＵＥ指示に等しいゼロ以外の値）を返す。一実施形態では、（例えば上述のような）ｎｏ_ＴＸ（）サブルーチンに検証鍵Ｖ_Ｋを入力として供給することは、何回ロッキングトランザクションを作成するべきかを決定するのに利用可能な情報を提供する。

の値は、圧縮された鍵のサイズとして参照されてよい。例えば検証鍵Ｖ_Ｋは、複数の３２ビットサブシーケンスに分割されてもよい。

は、<k>の特定の表現であってよく、例えば

は、<k>の１６進数の同等物とすることができる。

システムは、実施形態に従って、検証鍵を複数の要素に直列化（ｓｅｒｉａｌｉｚｅ）する６０４。一般的に言うと、データを直列化することは、データを、例えば何らかの規格又はプロトコルによって設定された長さに従って、より小さなチャンクに分割することを意味する。例えば検証鍵Ｖ_Ｋは、３２ビットのチャンクに分けられてよく、すなわち、

である。一実施形態では、チャンクサイズは、圧縮された鍵のような鍵のサイズに少なくとも部分的に基づいて選択される。一実施形態では、直列化（ＡＲＧ）関数は、ＡＲＧ入力を、規格又はプロトコルによって設定される長さに従ってより小さなデータシーケンスに分割する－例えば一実施形態では、直列化（ＡＲＧ）関数は、データのシーケンスを、連続する３２バイトのサブシーケンスに直列化するが、他の実施形態では、サブシーケンスは、任意の適切なプロトコルによって定義されるように、異なる固定／可変長とすることができる。

一般的に言うと、システムは、検証鍵の要素の少なくともサブセットを選択する６０６。一実施形態では、サブセットは、閾値サイズを超えない合計サイズ（例えばビットコインベースのシステムのスタックオブジェクトに対する５２０バイトの制限）を有する連続サブセット（例えば上記の例で記載されるもののような）である。一実施形態では、サブセットは、規定されたサイズ制限内に適合する多くの検証鍵Ｖ_Ｋ要素を順次選択することによって決定される。

一実施形態では、システムは、各ロッキングトランザクションに対して、ルールのセットに従って、対応するアンロッキングスクリプトに含まれるべき鍵のセットを割り当てる。一実施形態では、プロトコルは、スタックにプッシュされ得るデータオブジェクトのサイズの上限を有する－例えばビットコインでは、５２０バイトが、ブロックに対して許容可能な最大サイズである。したがって、検証鍵Ｖ_Ｋが５２０バイト以下のサイズの場合（すなわち、システムが、複数のサブセットに分割することなく検証鍵を符号化できると判断した場合）。一実施形態では、システムは、選択された要素に対してハッシュを計算する６０８。選択された要素は、上述したように、検証鍵Ｖ_Ｋ全体であってもよい。一実施形態では、ＯＰ_ＨＡＳＨ１６０のようなオペコードがサブセットをハッシュするために利用される。一実施形態では、オブジェクトのハッシュ化は、ＳＨＡ－２５６及びＲＩＰＥＭＤ－１６０のような複数の暗号ハッシュアルゴリズムを利用してハッシュ出力ＨＶＫを生成し、以下のリディームスクリプトのようなリディームスクリプト内で符号化される：
OP_HASH160 <HVK> OP_EQUALVERIFY <PubKey worker> OP_CHECKSIG

もちろん、他のハッシュアルゴリズム及び対応するハッシュ化オペコードが、様々な実施形態において利用されてもよい。リディームスクリプトは、作業者が検証鍵Ｖ_Ｋを所有していることの証明書を提供するアンロッキングスクリプトに関連して実行されると、対応するロッキングスクリプトによって妨げられているデジタル資産をアンロックするために使用可能である。したがって、対応するアンロッキングスクリプトが、計算されたハッシュに少なくとも部分的に基づいて一致する１つ以上のパラメータを含む、という１つ以上の条件を有するリディームスクリプトが生成される６１０。実施態様において、リディームスクリプトは更に、出力スクリプトが、リディームスクリプト内で符号化された公開鍵に対応する作業者の秘密鍵を使用して生成されたデジタル署名を含む、という条件を含む。

一実施形態では、システムは、検証鍵Ｖ_Ｋが、スタック上のデータブロックの許容可能な最大サイズを超えていると判断し、検証鍵Ｖ_Ｋを２つ以上のサブセットに分割する。一実施形態では、システムは、例えばプロトコルのサイズ制限内で符号化され得る最大数のチャンクを計算することによって、各サブセットに含まれるべきチャンクの数を決定する。一実施形態では、システムは、最大数のチャンク又は符号化されていない残りのチャンクの数を有する各サブセットを符号化する。例えば各チャンク

が３２バイトであり、

であるビットコインベースのシステムにおいて、検証鍵Ｖ_Ｋが、第１サブセット

及び第２サブセット

のような少なくとも２つのサブセットに分割される。この例では、ＶＫ１は、ビットコインベースのシステムの最大スタックデータブロックサイズ内で許容可能な最大数のチャンク（すなわち、スタック上でプッシュできるデータの最大の全体チャンクとして、最大５２０バイトサイズ内で許容可能な最大数のチャンクである、１６×３２＝５１２バイト）を含むことに留意されたい。一実施形態では、サブセットＶＫ１、ＶＫ２等は各々、入力として暗号ハッシュアルゴリズムに提供されてハッシュ出力を生成し、ハッシュ出力は、リディームスクリプトの条件として符号化され、この場合、有効なアンロッキングスクリプトが検証鍵Ｖ_Ｋ又はその一部を供給する。一例として、

及び第２サブセット

である例において、適切なリディームスクリプトは以下のように記述されてよい：
OP_HASH160 <HVK2> OP_EQUALVERIFY OP_HASH160 <HVK1> OP_EQUALVERIFY <PubKey worker> OP_CHECKSIG
ここで、

であり、

である。一実施形態において、システムは、第１ハッシュ＜ＨＶＫ１＞を生成して、第２ハッシュ＜ＨＶＫ２＞が、検証鍵要素の第２サブセットＶＫ２から生成されるべきであると決定する。

第３の例として、図４に関連して説明された実施形態を考える。この場合、アンロッキングスクリプトの最大サイズは１６５０バイトであり、データのブロックの最大サイズは５２０バイトである。システムは検証鍵のサイズを最大化し、

第１サブセット

第２サブセット

及び第３サブセット

を選択する。対応するハッシュ＜ＨＶＫ１＞、＜ＨＶＫ２＞及び＜ＨＶＫ３＞が計算され、ロッキングスクリプトが計算されたハッシュに一致するパラメータを含むという条件が、例えば以下のように生成される：
OP_HASH160 <HVK3> OP_EQUALVERIFY OP_HASH160 <HVK2> OP_EQUALVERIFY OP_HASH160 <HVK1> OP_EQUALVERIFY <PubKey worker> OP_CHECKSIG

ハッシュが生成されるたびに、システムは、追加サブセットを識別してハッシュすべきであるかどうかを判断してよい６１２。一実施形態では、システムは、検証鍵Ｖ_Ｋの各要素が、アンロッキングスクリプトの一部としてそれぞれの要素を供給する作業者に基づいて満たされる、リディームスクリプト内に対応する条件を有するという決定に基づいて、追加のサブセットは必要ないと判断する。一実施形態では、システムは、リディームスクリプトを使用して、対応するロッキングスクリプトを生成することができる作業者等に対して、リディームスクリプトを利用可能にする６１４。

作業者（例えば＜ＰｕｂＫｅｙ ｗｏｒｋｅｒ＞に関連付けられるエンティティ）に対する支払いを引き換える（ｒｅｄｅｅｍ）するために、作業者は、一実施形態において、正しい検証鍵Ｖ_Ｋの所有を実証する。一実施形態では、正しい検証鍵Ｖ_Ｋの所有についての任意の適切な証明書がシステムによって使用可能であり、この場合、カウンターパーティは、所有されると称される作業者の証明書を暗号的に確かめることができる。一実施形態では、作業者は、各ロッキングスクリプトに対して、アンロッキングスクリプトを作成し、このアンロッキングスクリプトは、リディームスクリプトの作成の場合と同様に、直列化された検証鍵Ｖ_Ｋの長さに依存して異なる。

直列化された検証鍵Ｖ_Ｋの長さが十分に小さいカーディナリティ（例えば分割することなく検証鍵全体をスタック上にプッシュすることができるほど十分にＶ_Ｋが小さい）の場合、作業者はアンロッキングスクリプトを作成する：
OP_PUSHDATA1 <length of signature> <signature> OP_PUSHDATA1 <byte-length of VK> VK OP_PUSHDATA1 <length of redeem script> <redeem script>

そうでなければ、直列化された検証鍵の長さが適用可能な閾値を超える場合、作業者はＶ_Ｋを２つ以上のサブセットに分割する。例えば

が３２バイトであるビットコインベースのプロトコルの場合、

及び

であり、アンロッキングスクリプト：
OP_PUSHDATA1 <length of signature> <signature> OP_PUSHDATA1 <byte-length of VK1 > VK1 OP_PUSHDATA1 <byte-length of VK2> VK2 OP_PUSHDATA1 <length of redeem script> <redeem script>
を作成する。

第３の例として、図４に関連して説明された実施形態を考える。この場合、アンロッキングスクリプトの最大サイズは１６５０バイトであり、データのブロックの最大サイズは５２０バイトである。作業者はＶ_Ｋを３つのサブセット：

及び

に分割し、アンロッキングスクリプト：
OP_PUSHDATA1 <length of signature> <signature> OP_PUSHDATA1 <byte-length of VK1> VK1 OP_PUSHDATA1 <byte-length of VK2> VK2 OP_PUSHDATA1 <byte-length of VK3> VK3 OP_PUSHDATA1 <length of redeem script> <redeem script>
を作成する。

本開示で説明される実施形態に対する種々の拡張が、明示的に議論されたものに加えて企図される。一実施形態では、ビットコインベースのプロトコルのようなプロトコルを使用して、本明細書で説明されるシステム及び方法を実装する－場合によっては、既存のプロトコルが、追加の機能性をサポートするように拡張されてもよい。

例えば実施形態において、出力は、複数の移転（ｔｒａｎｓｆｅｒｓ）に分割される－例えば出力は、２つの部分、すなわち、一方は第１グループＧ１に属する要素の部分と、他方は第２グループＧ２のための要素の部分に分割される。したがって、この例では、作業者の公開鍵に支払いを行う２つの入力（スクリプトに含まれる各グループからのグループ要素の１６進数表現）が存在する。対称ペアリングのためのこのプロトコルのステップは、２つの入力の各々に対して繰り返される。一実施形態では、プロトコルは、それに応じて検証鍵を継ぎ合わせるように拡張される。

第２の例として、鍵（例えばグループＧ１及びＧ２からそれぞれ生じる要素の順序で）は、そのまま維持され、プロトコル（例えば既存のビットコインベースのプロトコル）は鍵を符号化及び復号し、例えばハッシュマップ又は他の任意の適切なデータ構造の使用を通して、グループ要素の３２バイト表現がどのグループに属するかを分離するために拡張される。一実施形態では、既存のプロトコルの上で実行されるソフトウェア（例えばブロックチェーンネットワークのノードのセットの少なくともサブセットによって使用されるプロトコルの拡張）は、鍵を符号化及び復号し、グループ要素の３２バイトの１６進数表現がどのグループに属するかを分離するために使用される。

一実施形態では、図７は、プロトコルが、コントラクトを実行するためにデジタル資産を引き換えるときに計算７０４のプルーフを含むように修正された実施形態の図７００を示す。例えばビットコインベースのプロトコルは、コントラクトを実行するためにデジタル資産を引き換えるときに計算のプルーフを含むことをサポートするように拡張される。一実施形態では、計算のプルーフは、固定数の要素を含み、固定長特性を有する。図７は、ブロックチェーンにおいて計算のプルーフをどのように記録するかの１つのそのような例を示しており、ここでは、第１データブロック７０２（例えば第１データブロック Ｄａｔａ１）は、該第１データブロック７０２が計算７０４のプルーフに対応する要素を含むように分割され、それらの要素は、対応する公開鍵に対する署名チェックのためのスペースを作るために、アルトスタック（alt stack）（例えばＯＰ_ＴＯＡＬＴＳＴＡＣＫのようなコマンドを使用して）にプッシュされる。一実施形態では、検証鍵に対応する要素の第１バッチは、「Ｄａｔａ１」７０８とラベル付けされたブロック内にある。データブロックサイズの注釈は純粋に例示的なものであることに留意されたい。

更なる強化が、本開示の範囲内で考えられる。他の箇所で論じられたように、本明細書で説明されるようなプロトコルは、確認された鍵のハッシュ値（例えばＨＡＳＨ１６０（Ｖ_Ｋ））及び検証鍵Ｖ_Ｋ自体を読み取り、ロッキングのトランザクション識別子及び作業者が引き換えるトランザクション（ｗｏｒｋｅｒｓ ｒｅｄｅｅｍｉｎｇ ｔｒａｎｓａｃｔｉｏｎｓ）それぞれに関連してその２つを公開する、追加のサポートを用いて強化され得る。したがって、このようにして、作業者によって公開された正当性のプルーフを後に確かめるエンティティは、鍵がクライアントによって最初に公開されたものであるという保証を用いて、そのようにすることができる。

一実施形態では、本明細書で説明されるプロトコル（例えばビットコインベースのプロトコル）は、（例えば上述の方法で）正当性のプルーフに対するチェックを実行する追加のオペコード、コマンド又はステートメントで拡張される。一実施形態では、ＯＰ_ＣＨＥＣＫＰＯＣオペコードがサポートされ、トランザクション入力に対する署名が有効であることをＯＰ_ＣＨＥＣＫＳＩＧがチェックする方法と同様の方法で、正当性のプルーフ、検証鍵、入力（ｕ）及び出力（ｙ）に対して作用する。一実施形態では、ＯＰ_ＣＨＥＣＫＰＯＣは、ＴＲＵＥ又はＦＡＬＳＥの値、１又は０の値等を返し、正当性のプルーフが確認されたかどうかを示す。

図８は、本開示の少なくとも１つの実施形態を実施するために使用することができるコンピューティングデバイス８００の例示的な簡略化されたブロック図である。様々な実施形態において、コンピューティングデバイス８００を使用して、上記で図示及び説明されたシステムのいずれかを実装することができる。例えばコンピューティングデバイス８００は、データサーバ、ウェブサーバ、ポータブルコンピューティングデバイス、パーソナルコンピュータ又は任意の電子コンピューティングデバイスとして使用するために構成され得る。図８に図示されるように、コンピューティングデバイス８００は、実施形態において、バスサブシステム８０４を介して複数の周辺サブシステムと通信し、動作可能に結合される１つ以上のプロセッサ８０２を含むことができる。いくつかの実施形態において、これらの周辺サブシステムは、メモリサブシステム８０８及びファイル／ディスクストレージサブシステム８１０を含むストレージサブシステム８０６と、１つ以上のユーザインタフェース入力デバイス８１２と、１つ以上のユーザインタフェース出力デバイス８１４と、ネットワークインタフェースサブシステム８１６を含む。このようなストレージサブシステム８０６は、情報の一時的又は長期的な記憶のために使用され得る。

いくつかの実施形態において、バスサブシステム８０４は、コンピューティングデバイス８００の様々な構成要素及びサブシステムが、意図されるとおりに互いに通信することを可能にする機構を提供する。バスサブシステム８０４は、単一のバスとして概略的に示されているが、バスサブシステムの代替の実施形態は、複数のバスを利用する。いくつかの実施形態では、ネットワークインタフェースサブシステム８１６は、他のコンピューティングデバイス及びネットワークへのインタフェースを提供する。ネットワークインタフェースサブシステム８１６は、いくつかの実施形態では、コンピューティングデバイス８００からデータを受け取り、他のシステムにデータを送信するためのインタフェースとして機能する。いくつかの実施態様において、バスサブシステム８０４は、詳細、検索語等のようなデータを通信するために利用される。

いくつかの実施形態において、ユーザインタフェース入力デバイス８１２は、キーボード等の１つ以上のユーザ入力デバイス；一体型マウス、トラックボール、タッチパッド又はグラフィックスタブレット等のポインティングデバイス；スキャナ；バーコードスキャナ；ディスプレイに組み込まれたタッチスクリーン；音声認識システム、マイクロフォン等のオーディオ入力デバイス；及び他のタイプの入力デバイスを含む。一般に、「入力デバイス」という用語の使用は、情報をコンピューティングデバイス８００に入力するためのあらゆる可能なタイプのデバイス及び機構を含むように意図される。いくつかの実施形態において、１つ以上のユーザインタフェース出力デバイス８１４は、ディスプレイサブシステム、プリンタ又はオーディオ出力デバイス等の非視覚的ディスプレイ等を含む。いくつかの実施形態において、ディスプレイサブシステムは、陰極線管（ＣＲＴ）、液晶ディスプレイ（ＬＣＤ）や発光ダイオード（ＬＥＤ）ディスプレイ、投影装置等のフラットパネルデバイス又は他のディスプレイデバイスを含む。一般に、「出力デバイス」という用語の使用は、コンピューティングデバイス８００からの情報を出力するためのあらゆる可能なタイプのデバイス及び機構を含むように意図される。１つ以上のユーザインタフェース出力デバイス８１４を使用して、例えばユーザインタフェースを提示し、そのような対話が適切であり得るときに、説明されたプロセス及びその変形を実行するアプリケーションとのユーザ対話を容易にすることができる。

いくつかの実施形態において、ストレージサブシステム８０６は、本開示の少なくとも１つの実施形態の機能を提供する基本プログラミング及びデータ構成体を記憶するためのコンピュータ読取可能記憶媒体を提供する。アプリケーション（プログラム、コードモジュール、命令）は、いくつかの実施形態において１つ以上のプロセッサによって実行されるとき、本開示の１つ以上の実施形態の機能を提供し、実施形態においては、ストレージサブシステム８０６に記憶される。これらのアプリケーションモジュール又は命令を、１つ以上のプロセッサ８０２によって実行することができる。様々な実施形態において、ストレージサブシステム８０６は更に、本開示に従って使用されるデータを記憶するためのリポジトリを提供する。いくつかの実施形態では、ストレージサブシステム８０６は、メモリサブシステム８０８及びファイル／ディスクストレージサブシステム８１０を含む。

実施形態において、メモリサブシステム８０８は、複数のメモリ、例えばプログラム実行中の命令及びデータの格納のためのメインランダムアクセスメモリ（ＲＡＭ）８１８及び／又は固定命令を格納することができる読取専用メモリ（ＲＯＭ）８２０を含む。いくつかの実施形態において、ファイル／ディスクストレージサブシステム８１０は、プログラムファイル及びデータファイルのための非一時的な永続的（不揮発性）ストレージを提供し、ハードディスクドライブ、関連する取り外し可能媒体とともにフロッピーディスクドライブ、コンパクトディスク読取専用メモリ（ＣＤ－ＲＯＭ）ドライブ、光学ドライブ、取り外し可能媒体カートリッジ又は他の同様の記憶媒体を含むことができる。

いくつかの実施形態において、コンピューティングデバイス８００は、少なくとも１つのローカルクロック８２４を含む。ローカルクロック８２４は、いくつかの実施形態では、特定の開始日から発生したティック（ｔｉｃｋｓ）の数を表すカウンタであり、いくつかの実施形態では、コンピューティングデバイス８００内に一体的に配置される。様々な実施形態では、ローカルクロック８２４は、特定のクロックパルスにおいてコンピューティングデバイス８００のためのプロセッサ及びそこに含まれるサブシステム内でデータ転送を同期させるために使用され、コンピューティングデバイス８００と、データセンター内の他のシステムとの間の同期オペレーションを調整するために使用され得る。別の実施形態では、ローカルクロックは、プログラム可能な間隔のタイマである。

コンピューティングデバイス８００は、ポータブルコンピュータデバイス、タブレットコンピュータ、ワークステーション又は以下に説明される任意の他のデバイスを含む、様々なタイプのいずれかとすることができる。加えて、コンピューティングデバイス８００は、いくつかの実施形態では、１つ以上のポート（例えばＵＳＢ、ヘッドフォンジャック、ライトニングコネクタ等）を通してコンピューティングデバイス８００に接続することができる別のデバイスを含むことができる。実施形態において、このようなデバイスは、光ファイバコネクタを受け入れるポートを含む。したがって、いくつかの実施形態において、このデバイスは、光信号を、処理のためにデバイスをコンピューティングデバイス８００に接続するポートを通して伝送される電気信号に変換する。コンピュータ及びネットワークの絶えず変化する性質のために、図８に示されるコンピューティングデバイス８００の説明は、デバイスの好ましい実施形態を説明する目的のための特定の例としてのみ意図されている。図８に示されるシステムよりも多くの又は少ない構成要素を有する多くの他の構成も可能である。

上述の実施形態は、本発明を限定するものではなく、例示するものであり、当業者は、添付の特許請求の範囲によって定義される本発明の範囲から逸脱することなく、多くの代替の実施形態を設計することができることに留意されたい。請求項において、括弧内に付したすべての引用符号は、請求項を限定するものと解釈されるべきではない。「備えた（ｃｏｍｐｒｉｓｉｎｇ）」及び「備える（ｃｏｍｐｒｉｓｅｓ）」等の用語は、いずれかの請求項又は明細書全体に列挙されるもの以外の要素又はステップの存在を除外するものではない。本明細書において、「備える」は「含む又はから構成される」を意味し、「備えた」又は「含む又はから構成された」を意味する。要素の単数形参照は、そのような要素の複数形参照を除外するものではなく、その逆もまた同様である。本発明は、いくつかの別個の要素を含むハードウェアによって及び適切にプログラムされたコンピュータによって実装されてよい。いくつかの手段を列挙するデバイスクレームにおいては、これらの手段のいくつかが、１つの同じハードウェアアイテムによって具体化されてよい。特定の手段が相互に異なる従属請求項に記載されているという単なる事実は、これらの手段の組合せを有利に利用することができないことを示すものではない。

本明細書において引用された刊行物、特許出願及び特許を含むすべての文献は、それにより、参照によって組み込まれるように各文献を個々に具体的に示し、本明細書においてその全体を述べたものと同じ限度で、参照によって本明細書に組み込まれる。

Claims (15)

1. コンピュータ実施される検証方法であって：
   ブロックチェーントランザクションに関連付けられる第１スクリプトを取得する取得ステップであって、前記第１スクリプトが、
   コマンドの第１セットと、
   １つ以上の暗号ハッシュ値と、
   を含む取得ステップと；
   第２スクリプトを生成する生成ステップであって、前記第２スクリプトが、
   コマンドの第２セットと、
   複数の要素の１つ以上のサブセットであって、前記複数の要素が検証鍵を集合的に形成し、前記１つ以上のサブセットが前記検証鍵の各要素を集合的に含む、前記複数の要素の１つ以上のサブセットと、
   前記第１スクリプトと、
   前記第２スクリプトを生成するコンピュータシステムに関連付けられる識別子と、
   を含む生成ステップと；
   前記１つ以上の暗号ハッシュ値が前記検証鍵の１つ以上のサブセットに一致するという決定に関連して、前記コマンドの第１セット及び前記コマンドの第２セットを実行することに少なくとも部分的に基づいて、前記コンピュータシステムが前記検証鍵へのアクセスを有することの証明書を生成するステップと；
   を含む、コンピュータ実施される方法。
2. 前記第２スクリプトを生成する生成ステップは、
   作成すべきロッキングスクリプトの数を決定するステップと、
   前記検証鍵を前記複数の要素に直列化するステップと、
   前記複数の要素のあるサブセットを選択するステップと、
   前記複数の要素の前記選択されたサブセットのハッシュを決定するステップと、
   前記第２スクリプトを生成するステップと、
   を含む、請求項１に記載のコンピュータ実施される方法。
3. 前記第２スクリプトは、前記決定されたハッシュに少なくとも部分的に基づいて一致する１つ以上のパラメータを含む、
   請求項２に記載のコンピュータ実施される方法。
4. リディームスクリプトは、出力スクリプトが、作業者の秘密鍵を使用して生成されたデジタル署名を含む、という条件を更に含む、
   請求項２又は３に記載のコンピュータ実施される方法。
5. 前記複数の要素のうちのある要素は、楕円曲線上の点である、
   請求項１に記載のコンピュータ実施される方法。
6. 前記コマンドの第１セット及び前記コマンドの第２セットは集合的に、前記検証鍵の前記１つ以上のサブセットのうちのあるサブセットに少なくとも部分的に基づいて、前記１つ以上の暗号ハッシュ値のうちの第１暗号ハッシュ値がハッシュ出力に一致するかどうかを判断する命令を含む、
   請求項１乃至５のいずれかに記載のコンピュータ実施される方法。
7. 前記ハッシュ出力は、少なくともＳＨＡ－２５６及びＲＩＰＥＭＤ－１６０暗号ハッシュアルゴリズムを使用して生成される、
   請求項６に記載のコンピュータ実施される方法。
8. 前記第１スクリプトを取得する取得ステップは、
   前記検証鍵の前記１つ以上のサブセットを識別するステップと、
   前記検証鍵の前記１つ以上のサブセットの各サブセットについて、対応する暗号ハッシュ値を計算するステップと、を含み、前記１つ以上の暗号ハッシュ値が、各対応する暗号ハッシュ値を含む、
   請求項１乃至７のいずれかに記載のコンピュータ実施される方法。
9. 前記生成された証明書を検証することを条件として、前記トランザクションによって妨げられたデジタル資産の制御を前記コンピュータシステムに移転するステップ、
   を更に含む、請求項１乃至８のいずれかに記載のコンピュータ実施される方法。
10. 前記第１スクリプトを第２コンピュータシステムから取得するステップを更に含み、前記第２コンピュータシステムは、前記デジタル資産の少なくとも一部を寄与した、
    請求項９に記載のコンピュータ実施される方法。
11. 前記検証鍵の各要素は、前記サブセットのうちのちょうど１つ内にある、
    請求項１乃至１０のいずれかに記載のコンピュータ実施される方法。
12. 前記１つ以上のサブセットは１つのサブセットであり、該１つのサブセットは前記検証鍵を含む、
    請求項１乃至１１のいずれかに記載のコンピュータ実施される方法。
13. 前記第１スクリプトは、前記コンピュータシステムに関連付けられる公開鍵を更に含み、
    前記コンピュータシステムに関連付けられる前記識別子は、前記コンピュータシステムに関連付けられる前記公開鍵に対応する秘密鍵を使用して生成されるデジタル署名であり、
    前記コンピュータシステムが前記検証鍵へのアクセスを有することの前記証明書は、少なくとも部分的に前記デジタル署名及び前記公開鍵に更に基づく、
    請求項１乃至１２のいずれかに記載のコンピュータ実施される方法。
14. システムにおいて、
    プロセッサと；
    前記プロセッサによって実行された結果として、当該システムに、請求項１乃至１３のいずれかに記載のコンピュータ実施される方法を実行させる実行可能命令を含むメモリと；
    を備える、システム。
15. コンピュータシステムのプロセッサによって実行された結果として、前記コンピュータシステムに、請求項１乃至１３のいずれかに記載のコンピュータ実施される方法を少なくとも実行させる実行可能命令を格納している非一時的コンピュータ読取可能記憶媒体。
    

Images