JP2022533845A - 知識証明 - Google Patents

知識証明 Download PDF

Info

Publication number
JP2022533845A
JP2022533845A JP2021569312A JP2021569312A JP2022533845A JP 2022533845 A JP2022533845 A JP 2022533845A JP 2021569312 A JP2021569312 A JP 2021569312A JP 2021569312 A JP2021569312 A JP 2021569312A JP 2022533845 A JP2022533845 A JP 2022533845A
Authority
JP
Japan
Prior art keywords
transaction
signature
challenge
challenger
key
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2021569312A
Other languages
English (en)
Inventor
ワハブ，ジェド
ジャン，ウェイ
ドイロン，ブロック
ライト，クレイグ
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nchain Holdings Ltd
Original Assignee
Nchain Holdings Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nchain Holdings Ltd filed Critical Nchain Holdings Ltd
Publication of JP2022533845A publication Critical patent/JP2022533845A/ja
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/085—Secret sharing or secret splitting, e.g. threshold schemes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3218—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using proof of knowledge, e.g. Fiat-Shamir, GQ, Schnorr, ornon-interactive zero-knowledge proofs
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H04L9/3252—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures using DSA or related signature schemes, e.g. elliptic based signatures, ElGamal or Schnorr schemes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3271—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using challenge-response
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

知識証明は、ブロックチェーンネットワークに維持されるブロックチェーンに記録するためにトランザクションのセットを用いて実行される。被チャレンジャーは、競争チャレンジを受信する。競争チャレンジは、導出可能なチャレンジ解を有するが、チャレンジ鍵は、被チャレンジャーに直接通信されない。被チャレンジャーは、競争チャレンジからチャレンジ解の独立インスタンスを導出するよう１人以上の他の被チャレンジャーと競争する。被チャレンジャーが、他の１人以上の被チャレンジャーにいずれよりも前に、チャレンジ鍵の独立インスタンスを導出することに成功すると、被チャレンジャーは、そのデータを、少なくとも１つのメッセージに署名するためにシークレット被チャレンジャー鍵として使用し、それにより、少なくとも１つのトランザクション署名を生成し、ブロックチェーンネットワークのノードにおいて検証するために、少なくとも１つのトランザクション署名及び少なくとも１つのメッセージをブロックチェーンネットワークに提出する。

Description

本開示は、ブロックチェーンに記録するためのトランザクションのセットにより実装される形式の知識証明に関連する。
ブロックチェーンとは、分散型データ構造の形式を指し、ブロックチェーンの複製のコピーは、ピアツーピア(peer-to-peer (P２P))ネットワーク内の複数のノードのそれぞれにおいて維持される。ブロックチェーンは、データのブロックのチェーンを含み、各ブロックは１つ以上のトランザクションを含む。各トランザクションは、シーケンスの中の先行するトランザクションを指してよい。トランザクションは、新しいブロックに含まれるようネットワークへ提出され得る。新しいブロックは、「マイニング」として知られる処理により生成される。「マイニング」は、複数のマイニングノードの各々が「proof-of-work」を実行するために競争する、つまりブロックに含まれることを待っている保留中のトランザクションのプールに基づき、暗号パズルを解くことを含む。
従来、ブロックチェーン内のトランザクションは、デジタルアセット、すなわち、価値のストアとして機能するデータを伝達するために使用される。しかし、ブロックチェーンの上に追加の機能を積み重ねるために、ブロックチェーンを利用することもできる。例えば、ブロックチェーンプロトコルは、トランザクションのアウトプットに追加のユーザデータを格納することを可能にしてよい。現代のブロックチェーンは、単一トランザクション内に格納できる最大データ容量を増加させ、より複雑なデータを組み込むことを可能にしている。例えば、これは、ブロックチェーン内に電子ドキュメント（electronic document）、或いはオーディオ若しくはビデオデータを格納するために使用され得る。
ネットワーク内の各ノードは、転送、マイニング、及び記憶のうちの任意の１、２、又は３つ全部の役割を有することができる。転送ノードは、ネットワークのノードを通じてトランザクションを伝播させる。マイニングノードは、トランザクションのマイニングを実行してブロックにする。記憶ノードは、それぞれ、ブロックチェーンのマイニングされたブロックの彼ら自身のコピーを格納する。トランザクションをブロックチェーンに記録させるために、パーティは、該トランザクションを、伝播させるようにネットワークのノードのうちの１つへ送信する。トランザクションを受信したマイニングノードは、トランザクションをマイニングして新しいブロックにするよう競争してよい。各ノードは、トランザクションが有効であるための１つ以上の条件を含む同じノードプロトコルに関するよう構成される。無効なトランザクションは、伝播されず、マイニングされてブロックにされることもない。トランザクションが検証され、それによってブロックチェーンに受け入れられたと仮定すると、（任意のユーザデータを含む）トランザクションは、従って、不変の公開レコードとしてP２Pネットワークの各ノードに格納されたままである。
最新のブロックを生成するためにproof-of-workパズルを解くことに成功したマイナーは、標準的に、デジタルアセットの新しい額を生成する「生成トランザクション（generation transaction）」と呼ばれる新しいトランザクションにより報酬を受ける。proof-of-workは、ブロックをマイニングするために膨大な量の計算リソースを必要とするので、及び二重支払いの企てを含むブロックは他のノードにより受け入れられない可能性があるので、マイナーが、彼らのブロックに二重支払いトランザクションを含めることによりシステムを騙さないことを奨励する。
「アウトプットに基づく」モデル（UTXOに基づくモデルと呼ばれることもある）では、所与のトランザクションのデータ構造は、１つ以上のインプット及び１つ以上のアウトプットを含む。任意の使用可能アウトプットは、時にUTXO（「unspent transaction output（未使用トランザクションアウトプット）」）と呼ばれる、デジタルアセットの額を指定する要素を含む。アウトプットは、アウトプットを償還（redeem）するための条件を指定するロックスクリプトを更に含んでよい。各インプットは、先行するトランザクション内のそのようなアウトプットへのポインタを含み、ポイントされたアウトプットのロックスクリプトをアンロックするためのアンロックスクリプトを更に含んでよい。従って、トランザクションのペアを考えるとき、それらを、第１トランザクション及び第２トランザクションと呼ぶ。第１トランザクションは、デジタルアセットの額を指定する、及びアウトプットをアンロックする１つ以上の条件を定義するロックスクリプトを含む、少なくとも１つのアウトプットを含む。第２トランザクションは、第１トランザクションのアウトプットへのポインタと、第１トランザクションのアウトプットをアンロックするためのアンロックスクリプトと、を含む少なくとも１つのインプットを含む。
このようなモデルでは、第２トランザクションが伝播されてブロックチェーンに記録されるようP２Pネットワークへ送信されると、各ノードにおいて適用される有効性のための条件のうちの１つは、アンロックスクリプトが第１トランザクションのロックスクリプト内で定義された１つ以上の条件のうちの全部を満たすことである。もう１つは、第１トランザクションのアウトプットが、別の前の有効なトランザクションによって未だ償還されていないことである。これらの条件のうちのいずれかに従い第２トランザクションが無効であると分かった任意のノードは、該トランザクションを伝播させず、ブロックチェーンに記録させるためにマイニングしてブロックに含めることもしない。
トランザクションモデルの代替のタイプは、アカウントに基づくモデルである。この場合、各トランザクションは、過去の一連のトランザクションにおいて、先行するトランザクションのUTXOに戻って参照することによって移転される量を定義するのではなく、絶対的な口座（アカウント）残高を参照することによって移転される。全てのアカウントの現在の状態は、ブロックチェーンとは別個のマイナーによって格納され、絶えず更新される。アカウントに基づくモデルのトランザクションは、トランザクションを検証するのと同時に各ノードで実行するスマートコントラクトを含むこともできる。
いずれかのモデルのトランザクションは、知識証明を含むことができる。「知識証明（Knowledge proof）」又は「知識の証明（proof of knowledge）」は、パーティがデータの何らかのピース、例えばこれをdと呼ぶ、を知っていることをテストすることを表す従来の用語である。例として、アウトプットに基づくトランザクションモデルの場合には、１つのトランザクションTx１のアウトプット内のロックスクリプトはハッシュパズルを含むことができる。第２トランザクションTx２のインプットがTx１のこのアウトプットを指す場合、Tx２の該インプット内のアンロックスクリプトは、Tx１のアウトプットを償還することに成功するためには、ハッシュパズルを解かなければならない。ハッシュパズルは、dのハッシュであるハッシュ値hを含む。つまり、h=Hpuz(d)。パズルは、スクリプトのピースを含むこともできる。該スクリプトのピースは、ノードにおいてTx２のアンロックスクリプトと一緒に実行されると、Tx２のアンロックスクリプトからdであるとされているデータ値d'を取り入れ、それをハッシュ関数Hpuzによりハッシングし、Tx１のロックスクリプトに含まれるハッシュ値hと比較する。つまり、該スクリプトのピースは、h=Hpuz(d')であるかどうかをチェックし、比較の結果がyes（肯定）である（又は従来の用語で「真」である）場合にのみ、Tx１のアウトプットをアンロックする。従って、Tx２の受取人は、dの知識を証明するTx２のアンロックスクリプトにdが含まれる場合にのみ、Tx１のアウトプットをアンロックできる。
従来のハッシュパズルを単独で使用することに伴う問題は、不徳なマイナー又は他のノードがTx２のアンロックスクリプト内にdを観察し、従って、彼自身のバージョンTx２*を生成し及びマイニングする（又は発行する）ことができ、Tx２内の意図された受信者（例えばBob）の代わりにTx２*のアウトプット内で彼自身に支払うことができることである。
本開示は、本願明細書で「知識チャレンジ（knowledge challenge）」と呼ばれるもの、つまり、チャレンジャーがチャレンジ（競争チャレンジ（competition challenge））を設定し、複数の被チャレンジャー（challengee、被挑戦者）がチャレンジに対する解（チャレンジ解）を独立に導出するよう互いに競争するシナリオにおける、知識署名に関する。この状況では、被チャレンジャーがチャレンジ解の正しい導出を証明するために何らかのメカニズムが必要である。
本開示は、ブロックチェーン技術がそのような証明を通信し及び記録するために優れた枠組みを提供することを認識している。更に、その枠組みの中で、本開示は、そのような証明を提供する手段としてデジタル署名を利用し、チャレンジを最初に解決した被チャレンジャーが、チャレンジ解自体を開示することなく、その事実を証明できるという利点を有する。
本発明の主題の第１の態様は、ブロックチェーンネットワーク内に維持されるブロックチェーンに記録するためにトランザクションのセットを使用する知識証明を提供する、コンピュータにより実施される方法を提供する。被チャレンジャーは、競争チャレンジを決定し、該競争チャレンジは該競争チャレンジから導出可能なチャレンジ解を有し、競争チャレンジのための署名チャレンジはチャレンジャー装置において決定される。署名チャレンジは、ブロックチェーンに記録するために少なくとも１つのチャレンジトランザクションの中でブロックチェーンネットワークに提供される。競争チャレンジは、複数の競争する被チャレンジャーに通信され、チャレンジ解を直接通信しないので、競争する被チャレンジャーに、競争チャレンジからチャレンジ解の独立インスタンスを導出するよう競争させる。チャレンジ解の独立インスタンスを導出することに成功した、被チャレンジャーのうちの最初の者は、そのデータを、被チャレンジャー装置において少なくとも１つのメッセージに署名するためにシークレット被チャレンジャー鍵として使用し、それにより、少なくとも１つのトランザクション署名を生成する。被チャレンジャーのうちの最初の者は、少なくとも１つのトランザクション署名及び少なくとも１つのメッセージをブロックチェーンネットワークに、少なくとも１つの証明トランザクションの中で提出し、それにより、ブロックチェーンネットワーク内のノードに、少なくとも１つのトランザクション署名が署名チャレンジを満たすかどうかを決定させる。
従って、最初の被チャレンジャーは、チャレンジ解の独立インスタンスの知識をトランザクション署名に埋め込む。トランザクション署名は、メッセージを認証すること及びチャレンジ解（これは、トランザクション署名が署名チャレンジを満たすと決定された場合に、成功裏に証明される）の知識を証明することの両方の二重の役割を有する。その知識はシークレット被チャレンジャー鍵により埋め込まれるので、チャレンジ解自体は、トランザクション署名から導出可能ではない。つまり、チャレンジ解の知識は、解自体を開示することなく、証明される。
特定の実施形態では、署名チャレンジは、本願明細書において「rチャレンジ（r-challenge）」（rパズル、r-puzzle）と呼ばれる形式を取る。楕円曲線デジタル署名アルゴリズム（Elliptic Curve Digital Signature Algorithm）では、r部分は、シークレット一時鍵から導出される値であり、rチャレンジは、満たされるために、特定の一時鍵により生成されている必要がある。知識チャレンジでは、チャレンジ解の知識は、rチャレンジを満たすトランザクション署名を生成するために、一時鍵によりトランザクション署名に埋め込まれてよく、それによりその知識を証明する。rパズルの枠組みは、以下に説明する種々の利点を有する。
本開示の実施形態の理解を助け、そのような実施形態がどのように実施され得るかを示すために、例としてのみ、以下の添付の図面を参照する。
ブロックチェーンを実装するためのシステムの概略ブロック図である。 ブロックチェーンに記録されるトランザクションの幾つかの例を概略的に示している。 ブロックチェーンを実装するための別のシステムの概略ブロック図である。 アウトプットに基づくモデルのノードプロトコルに従う、トランザクションを処理するノードソフトウェアのピースの概略ブロック図である。 トランザクションの例示的なセットの概略図である。 楕円曲線デジタル署名アルゴリズム（ECDSA）の背後にある原理の幾つかを概略的に示す。 楕円曲線デジタル署名アルゴリズム（ECDSA）の背後にある原理の幾つかを概略的に示す。 楕円曲線デジタル署名アルゴリズム（ECDSA）の背後にある原理の幾つかを概略的に示す。 楕円曲線デジタル署名アルゴリズム（ECDSA）の背後にある原理の幾つかを概略的に示す。 本願明細書でrパズル（又は同義的にrチャレンジ）と呼ばれるタイプの知識証明の１つの可能な実装の概略図である。 rパズルの別の可能な実装の概略図である。 rパズルの別の可能な実装の概略図である。 rパズルの更に別の可能な実装の概略図である。 アカウントに基づくモデルのノードプロトコルに従う、トランザクションを処理するノードソフトウェアのピースの概略ブロック図である。 ECDSA署名の例示的なフォーマットを概略的に示す。 rパズルの１つの形式のロック及びアンロックスクリプトの例示的な実装のステップ毎のスクリプト分析である。 rパズルを用いて実装される知識チャレンジの例を示す。 本願明細書においてPパズルと呼ばれるものを用いて実施される知識証明の代替例を示す。 ハッシュ衝突バウンティ（bounty）トランザクション署名及び対応する証明トランザクションを示す。 （ａ）演算回路ゲート、及び（ｂ）演算回路を示す。 別の例示的な演算回路を示す。 演算回路証明を検証する方法の処理フローを示す。
上述のように、本発明の主題の特定の実施形態は、「rパズル」の枠組みの中で知識チャレンジを策定する。１つのそのような例は、後述する図１４に示される。rパズルの枠組みの種々の利点は、以下に説明され、図１４の例では、それらの利点は、知識チャレンジの中で利用される。
他の実施形態は、rパズルの枠組みを利用しない。１つのそのような例は、これも後述する図１５に示される。
前述の実施形態を説明する前に、それらの実施形態の幾らかの有用な背景が提供される。これは、図１４の例及び他のそのような実施形態の状況のような、rパズルの枠組みの説明を含む。
幾つかの暗号方式では、検証者は、ある人（証明者又は被挑戦者又は被チャレンジャーと呼ばれる）が知識証明と呼ばれる情報の何らかのピースを有することを納得させる必要がある場合がある。単純に、これは、検証者に情報のピースを直接提供することにより行うことができる。代替として、証明者は、情報のピースに依存する計算を実行することを要求され得る。望ましくは、関連する計算は、検証者自身がチャレンジを設定するために情報のピースを知る必要がない、又は証明者が情報のピースを知っていることを検証するために情報のピースが検証者に開示される必要がないようなものである。計算方法について、検証計算は入力データに対して実行されなければならない。シークレット値の知識を証明する直接的な方法は、暗号ハッシュ関数の原像（preimage、プリイメージ）及び衝突耐性の特徴により、暗号ハッシュ関数の使用を通じるものである。このハッシュ方法は、ハッシュ関数が多くのブロックチェーンアプリケーションの秘密鍵－公開鍵暗号システムの基本部分を形成するので、多くのブロックチェーンアプリケーションに容易に統合できる。この種の知識証明は、標準的にハッシュパズルと呼ばれるブロックチェーンアプリケーションにおいて非常に多い。
UTXOに基づくブロックチェーンでは、ハッシュパズルに対する解（ハッシュ値の原像）は、使用条件として設定できる。従って、検証は、トランザクション検証の部分としてマイナーにより実行される。しかしながら、このアプローチでは、トランザクションは、特定の秘密鍵を用いる署名も要求しなければならない。そうでなければ、マイナーは、ブロックにトランザクションを含める前に、ハッシュパズル解を受け取るからである。これは、悪意あるマイナーに、マイナーに属するアドレスに向けられたアウトプットを有する支払いトランザクションを生成する機会を与え得る。
本開示では、知識証明は、検証がマイナー（又は転送ノード）により実行されることを可能にしたまま、この問題を回避する知識証明が提供される。これを行うために、知識証明は、楕円曲線デジタル署名アルゴリズム（elliptic curve digital signature algorithm (ECDSA)）署名に対応する一時鍵に接続される。このアルゴリズムで使用される暗号プリミティブは多くのブロックチェーンに固有のものであるので、現在のインフラストラクチャに直ちに統合できる。
＜例示的なシステムの概要＞
図１は、ブロックチェーン１５０を実装するための例示的なシステム１００を示す。システム１００は、典型的にはインターネットのような広域インターネットワークであるパケット交換ネットワーク１０１を含む。パケット交換ネットワーク１０１は、パケット交換ネットワーク１０１内にピアツーピア(P２P)オーバレイネットワーク１０６を形成するように配置された複数のノード１０４を含む。各ノード１０４は、異なるピアに属する異なるノード１０４を有するピアのコンピュータ装置を含む。各ノード１０４は、１つ以上のプロセッサ、例えば、１つ以上の中央処理装置（ＣＰＵ）、アクセラレータプロセッサ、特定用途向けプロセッサ、及び/又はフィールドプログラマブルゲートアレイ（ＦＰＧＡ）を含む処理装置を含む。各ノードはまた、メモリ、すなわち、１つ以上の非一時的コンピュータ読取可能媒体の形態のコンピュータ読取可能記憶装置を備える。メモリは、１つ以上のメモリ媒体、例えば、ハードディスクなどの磁気媒体、固体ドライブ（solid-state drive (SSD)）、フラッシュメモリ又はEEPROMなどの電子媒体、及び/又は光ディスクドライブなどの光学的媒体を使用する１つ以上のメモリユニットを含んでもよい。
ブロックチェーン１５０は、データのブロック１５１のチェーンを指し、ブロックチェーン１５０のそれぞれのコピーは、ピアツーピア(peer-to-peer (P２P))ネットワーク１６０内の複数のノードのそれぞれにおいて維持される。チェーン内の各ブロック１５１は、１つ以上のトランザクション１５２を含み、この文脈ではトランザクションは、一種のデータ構造を参照する。データ構造の性質は、トランザクションモデル又はスキームの一部として使用されるトランザクションプロトコルのタイプに依存する。所与のブロックチェーンは、典型的には、全体を通して、１つの特定のトランザクションプロトコルを使用する。１つの一般的なタイプのトランザクションプロトコルでは、各トランザクション１５２のデータ構造は、少なくとも１つのインプット及び少なくとも１つのアウトプットを含む。各アウトプットは、そのアウトプットが暗号的にロックされている(アンロックされ、それによって償還又は使用されるために、そのユーザ１０３の署名を必要とする)ユーザに属するデジタルアセットの数量を表す額（amount）を指定する。各インプットは、先行するトランザクション１５２のアウトプットを逆にポイントし、それによってトランザクションをリンクする。
ノード１０４の少なくとも幾つかは、トランザクション１５２を転送し、それによって伝播する転送ノード１０４Fの役割を引き受ける。ノード１０４の少なくともいくつかは、ブロック１５１をマイニングするマイナー１０４Mの役割を担う。ノード１０４の少なくとも幾つかは、記憶ノード１０４S（「フルコピー（full-copy）」ノードとも呼ばれる）の役割を引き受け、各ノードは、それぞれのメモリに同じブロックチェーン１５０のそれぞれのコピーを格納する。各マイナーノード１０４Mは、マイニングされてブロック１５１にされることを待ってるトランザクション１５２のプール１５４も維持する。所与のノード１０４は、転送ノード１０４、マイナー１０４M、記憶ノード１０４S、又はこれらの２つ若しくは全部の任意の組み合わせであり得る。
所与の現在のトランザクション１５２jにおいて、インプット（又はそのそれぞれ）は、トランザクションのシーケンスの中の先行トランザクション１５２iのアウトプットを参照するポインタを含み、このアウトプットが現在のトランザクション１５２jにおいて償還されるか又は「消費される（spent）」ことを指定する。一般に、先行するトランザクションは、プール１５４又は任意のブロック１５１内の任意のトランザクションであり得る。先行するトランザクション１５２iは、必ずしも、現在のトランザクション１５２jが生成された又はネットワーク１０６へ送信されたときに存在する必要はないが、先行するトランザクション１５２iは、現在のトランザクションが有効であるために存在し検証されている必要がある。従って、本願明細書で「先行する」は、ポインタによりリンクされた論理的シーケンスの中で先行するものを表し、必ずしも時系列の中での生成又は送信の時間を表さない。従って、それは、必ずしも、トランザクション１５２i,１５２jが順不同で生成され又は送信されることを排除しない（以下の親のない（orphan）トランザクションに関する議論を参照する）。先行するトランザクション１５２iは、等しく、祖先（antecedent）又は先行（predecessor）トランザクションと呼ばれ得る。
現在のトランザクション１５２jのインプットは、先行するトランザクション１５２iのアウトプットがロックされているユーザ１０３aの署名も含む。また、現在のトランザクション１５２jのアウトプットは、新しいユーザ１０３bに暗号的にロックできる。従って、現在のトランザクション１５２jは、先行するトランザクション１５２iのインプットで定義された量を、現在のトランザクション１５２jのアウトプットで定義された新しいユーザ１０３bに移転することができる。幾つかの場合には、トランザクション１５２が複数のアウトプットを有し、複数のユーザ間でインプット量を分割してよい(変更を行うために、そのうちの１人がオリジナルユーザとなる)。場合によっては、トランザクションが複数のインプットを有し、１つ以上の先行するトランザクションの複数のアウトプットから量をまとめ、現在のトランザクションの１つ以上のアウトプットに再分配することもできる。
上記は「アウトプットベースの」トランザクションプロトコルと呼ばれることがあり、時には「未使用のトランザクションアウトプット(unspent transaction output (UTXO))タイプのプロトコル」(アウトプットはUTXOと呼ばれる)とも呼ばれる。ユーザの合計残高は、ブロックチェーンに格納されている１つの数値で定義されるのではなく、代わりに、ユーザは、ブロックチェーン１５１内の多くの異なるトランザクション１５２に分散されている該ユーザの全てのUTXOの値を照合するために、特別な「ウォレット」アプリケーション１０５を必要とする。
アカウントベースのトランザクションモデルの一部として、別のタイプのトランザクションプロトコルを「アカウントベース」のプロトコルと呼ぶことがある。アカウントベースの場合、各トランザクションは、過去の一連のトランザクションにおいて、先行するトランザクションのUTXOに戻って参照することによって移転される量を定義するのではなく、絶対的な口座（アカウント）残高を参照することによって移転される。全てのアカウントの現在の状態は、ブロックチェーンとは別個のマイナーによって格納され、絶えず更新される。このようなシステムでは、トランザクションは、アカウントの連続したトランザクション記録(いわゆる「ポジション」)を用いて発注される。この値は、送信者により彼らの暗号署名の一部として署名され、トランザクション参照計算の一部としてハッシュされる。さらに、任意的なデータフィールドもトランザクションに署名することができる。このデータフィールドは、例えば、前のトランザクションIDがデータフィールドに含まれている場合、前のトランザクションを遡ってポイントしてよい。
どちらのタイプのトランザクションプロトコルでも、ユーザ１０３が新しいトランザクション１５２jを実行したい場合、ユーザは、自分のコンピュータ端末１０２からP２Pネットワーク１０６のノードの１つ１０４(現在は、通常、サーバ又はデータセンタであるが、原則として、他のユーザ端末でもよい)に新しいトランザクションを送信する。このノード１０４は、各ノード１０４に適用されるノードプロトコルに従って、トランザクションが有効であるかどうかをチェックする。ノードプロトコルの詳細は、問題のブロックチェーン１５０で使用されているトランザクションプロトコルのタイプに対応し、全体のトランザクションモデルを一緒に形成する。ノードプロトコルは、典型的には、ノード１０４に、新しいトランザクション１５２j内の暗号署名が、トランザクション１５２の順序付けされたシーケンスの中の前のトランザクション１５２iに依存する、期待される署名と一致することをチェックすることを要求する。アウトプットベースの場合、これは、新しいトランザクション１５２jのインプットに含まれるユーザの暗号署名が、新しいトランザクションが消費する先行するトランザクション１５２jのアウトプットに定義された条件と一致することをチェックすることを含んでよく、この条件は、典型的には、新しいトランザクション１５２jのインプット内の暗号署名が、新しいトランザクションのインプットがポイントする前のトランザクション１５２iのアウトプットをアンロックすることを少なくともチェックすることを含む。幾つかのトランザクションプロトコルでは、条件は、少なくとも部分的に、インプット及び/又はアウトプットに含まれるカスタムスクリプトによって定義されてもよい。或いは、単にノードプロトコルだけで固定することもできるし、或いは、これらの組み合わせによることもある。いずれにせよ、新しいトランザクション１５２jが有効であれば、現在のノードは新しいトランザクションをP２Pネットワーク１０６内のノード１０４の１つ以上の他のノードに転送する。これらのノード１０４の少なくともいくつかは、同じノードプロトコルに従って同じテストを適用し、新しいトランザクション１５２jを１つ以上のさらなるノード１０４に転送するなど、転送ノード１０４Fとしても機能する。このようにして、新しいトランザクションは、ノード１０４のネットワーク全体に伝播される。
アウトプットベースのモデルでは、与えられたアウトプット(例えば、UTXO)が消費されるかどうかの定義は、ノードプロトコルに従って別の今後の（onward）トランザクション１５２jのインプットによって既に有効に償還されているかどうかである。トランザクションが有効であるための別の条件は、それが消費又は償還を試みる先行するトランザクション１５２iのアウトプットが、別の有効なトランザクションによって未だ消費/償還されていないことである。ここでも、有効でない場合、トランザクション１５２jは、ブロックチェーンに伝播又は記録されない。これは、支払者が同じトランザクションのアウトプットを複数回消費しようとする二重支出を防ぐ。一方、アカウントベースのモデルは、口座残高を維持することによって、二重支出を防ぐ。この場合も、トランザクションの順序が定義されているため、口座残高は、一度に単一の定義された状態を有する。
検証に加えて、ノード１０４Mのうちの少なくともいくつかは、「proof of work」に支えられているマイニングと呼ばれるプロセスで、トランザクションのブロックを最初に作成するために競合する。マイニングノード１０４Mでは、まだブロックに現れていない有効なトランザクションのプールに新しいトランザクションが追加される。そして、マイナーは、暗号パズルを解決しようと試みることにより、トランザクションのプール１５４からトランザクション１５２の新しい有効なブロック１５１を組み立てるために競争する。これは、典型的には、ノンスがトランザクションのプール１５４と連結され、ハッシュされるときに、ハッシュのアウトプットが所定の条件を満たすような「ノンス」値を探すことを含む。例えば、所定の条件は、ハッシュのアウトプットが、所定の数の先行ゼロを有することであってもよい。ハッシュ関数の特性は、インプットに関して予測不可能なアウトプットを持つことである。従って、この探索は、ブルートフォースによってのみ実行することができ、従って、パズルを解決しようとしている各ノード１０４Mにおいて、相当量の処理リソースを消費する。
パズルを解く最初のマイナーノード１０４Mは、これをネットワーク１０６に通知し、その解を証明として提供する。この解は、ネットワーク内の他のノード１０４によって簡単にチェックすることができる(ハッシュが対する解が与えられれば、ハッシュのアウトプットが条件を満たすことを確認することは簡単である)。勝者がパズルを解いたトランザクションのプール１５４は、各ノードで勝者が発表した解をチェックしたことに基づいて、記憶ノード１０４Sとして機能するノード１０４のうちの少なくともいくつかによってブロックチェーン１５０の新しいブロック１５１として記録される。また、新しいブロック１５１nにはブロックポインタ１５５が割り当てられ、チェーン内で前に作成されたブロック１５１n-１を指すようになっている。proof-of-workは、新しいブロックを１５１作成するのに多大な労力を要し、二重の支出を含むブロックは他のノード１０４によって拒否される可能性が高く、従ってマイニングノード１０４Mが二重支払いを彼らのブロックに含まないようにする動機が働くので、二重の支出のリスクを減じるのを助ける。一旦生成されると、ブロック１５１は、同じプロトコルに従ってP２Pネットワーク１０６内の各格納ノード１０４Siで認識され、維持されるため、変更することはできない。また、ブロックポインタ１５５は、ブロック１５１に順序を課す。トランザクション１５２は、P２Pネットワーク１０６内の各記憶ノード１０４Sで順序付けられたブロックに記録されるので、これはトランザクションの不変の公開台帳を提供する。
パズルを解決するために常に競争している異なるマイナー１０４Mは、いつ解を探し始めたかによって、いつでもマイニングされていないトランザクションプール１５４の異なるスナップショットに基づいてパズルを解いているかもしれないことに留意する。パズルを解く者は誰でも、最初に次の新しいブロック１５１nに含まれるトランザクション１５２を定義し、現在のマイニングされていないトランザクションのプール１５４が更新される。そして、マイナー１０４Mは、新たに定義された未解決のプール１５４からブロックを作り出すために、競争を続ける。また、生じ得る「分岐（フォーク、fork）」を解決するためのプロトコルも存在する。これは、２人のマイナー１０４Mが互いに非常に短い時間内にパズルを解決し、ブロックチェーンの矛盾したビューが伝播する場合である。要するに、分岐の枝が伸びるときは常に、最長のものが最終的なブロックチェーン１５０になる。
ほとんどのブロックチェーンでは、勝ったマイナー１０４Mは、何も無いものから新しい量のデジタルアセットを生み出す特別な種類の新しいトランザクションによって自動的に報酬を受けている(通常のトランザクションでは、あるユーザから別のユーザにデジタルアセットの量を移転する)。したがって、勝ったノードは、ある量のデジタルアセットを「マイニング」したと言える。この特殊なタイプのトランザクションは「生成（generation）」トランザクションと呼ばれることもある。それは自動的に新しいブロック１５１nの一部を形成する。この報酬は、マイナー１０４Mがproof-of-work競争に参加する動機を与える。多くの場合、通常の（非生成）トランザクションは、そのトランザクションが含まれたブロック１５１nを生成した勝ったマイナー１０４Mにさらに報酬を与えるために、追加のトランザクション手数料をそのアウトプットの１つにおいて指定する。
マイニングに含まれる計算リソースのために、典型的には、少なくともマイナーノード１０４Mの各々は、１つ以上の物理的サーバユニットを含むサーバ、又はデータセンタ全体の形態をとる。各転送ノード１０４M及び/又は記憶ノード１０４Sは、サーバ又はデータセンタの形態をとることもできる。しかしながら、原則として、任意の所与のノード１０４は、ユーザ端末又は互いにネットワーク接続されたユーザ端末のグループを含むことができる。
各ノード１０４のメモリは、それぞれの１つ以上の役割を実行し、ノードプロトコルに従ってトランザクション１５２を処理するために、ノード１０４の処理装置上で動作するように構成されたソフトウェア４００を格納する。ノード１０４に属するいずれの動作も、それぞれのコンピュータ装置の処理装置上で実行されるソフトウェア４００によって実行され得ることが理解されよう。ノードソフトウェア４００は、アプリケーションレイヤにおける１つ以上のアプリケーション、又はオペレーティングシステムレイヤ若しくはプロトコルレイヤのような下位レイヤ、又はこれらの任意の組合せの中に実装されてよい。また、本明細書で使用される「ブロックチェーン」という用語は、一般的な技術の種類を指す一般的な用語であり、任意の特定の専有のブロックチェーン、プロトコル又はサービスに限定されない。
また、ネットワーク１０１には、消費者ユーザの役割を果たす複数のパーティ１０３の各々のコンピュータ装置１０２も接続されている。これらは、トランザクションにおける支払人及び被支払人の役割を果たすが、他のパーティの代わりにトランザクションをマイニングし又は伝播することに必ずしも参加しない。それらは必ずしもマイニングプロトコルを実行するわけではない。２つのパーティ１０３及びそれぞれの機器１０２が説明のために示されており、第１パーティ１０３ａ及びそのそれぞれのコンピュータ機器１０２a、幾つかの第２パーティ１０３ｂ及びそのそれぞれのコンピュータ機器１０２bである。より多くのこのようなパーティ１０３及びそれらのそれぞれのコンピュータ機器１０２がシステムに存在し、参加することができるが、便宜上、それらは図示されていないことが理解されよう。各パーティ１０３は、個人又は組織であってもよい。純粋に例示として、第１パーティ１０３ａは、本明細書においてAliceと称され、第２パーティ１０３ｂは、Bobと称されるが、これは限定的なものではなく、本明細書においてAlice又はBobという言及は、それぞれ「第１パーティ」及び「第２パーティ」と置き換えることができることは理解されるであろう。
各パーティ１０３のコンピュータ機器１０２は、１つ以上のプロセッサ、例えば１つ以上のCPU、GPU、他のアクセラレータプロセッサ、特定用途向けプロセッサ、及び/又はFPGAを備えるそれぞれの処理装置を備える。各パーティ１０３のコンピュータ機器１０２は、さらに、メモリ、すなわち、非一時的コンピュータ読取可能媒体又は媒体の形態のコンピュータ読取可能記憶装置を備える。このメモリは、例えば、ハードディスクなどの磁気媒体、ＳＳＤ、フラッシュメモリ又はEEPROMなどの電子媒体、及び/又は光ディスクドライブなどの光学的媒体を使用する１つ以上のメモリユニットを含んでもよい。各パーティ１０３のコンピュータ機器１０２上のメモリは、処理装置上で動作するように配置された少なくとも１つのクライアントアプリケーション１０５のそれぞれのインスタンスを含むソフトウェアを記憶する。所与のノード１０４に属するいずれの動作も、それぞれのコンピュータ機器１０２の処理装置上で実行されるソフトウェアを使用することにより実行され得ることが理解されよう。各パーティ１０３のコンピュータ機器１０２は、少なくとも１つのユーザ端末、例えばデスクトップ又はラップトップコンピュータ、タブレット、スマートフォン、又はスマートウォッチのようなウェアラブルデバイスを備えている。所与のパーティ１０３のコンピュータ装置１０２は、ユーザ端末を介してアクセスされるクラウドコンピューティングリソースのような、１つ以上の他のネットワーク接続されたリソースを含んでもよい。
クライアントアプリケーション１０５は、最初に、１つ以上の適切なコンピュータ読取可能な記憶媒体、例えばサーバからダウンロードされたもの、又はリムーバブルSSD、フラッシュ・メモリ・キー、リムーバブルEEPROM、リムーバブル磁気ディスクドライブ、磁気フロッピー・ディスク又はテープ、光ディスク、例えばCD又はDVD ROM、又はリムーバブル光学ドライブなどのリムーバブル記憶装置上で、任意の所与のパーティ１０３のコンピュータ機器１０２に提供され得る。
クライアントアプリケーション１０５は、少なくとも「ウォレット」機能を備える。これには主に２つの機能を有する。これらのうちの１つは、それぞれのユーザパーティ１０３が、ノード１０４のネットワーク全体にわたって伝播され、それによってブロックチェーン１５０に含まれるトランザクション１５２を作成し、署名し、送信することを可能にすることである。もう１つは、現在所有しているデジタルアセットの量をそれぞれのパーティに報告することである。アウトプットベースのシステムでは、この第２の機能は、当該パーティに属するブロックチェーン１５０全体に散在する様々なトランザクション１５２のアウトプットの中で定義される量を照合することを含む。
注：種々のクライアント機能が所与のクライアントアプリケーション１０５に統合されるとして説明されることがあるが、これは、必ずしも限定的ではなく、代わりに、本願明細書に記載される任意のクライアント機能が２つ以上の異なるアプリケーションのスーツに実装されてよく、例えばAPIを介してインタフェースし、又は一方が他方へのプラグインである。より一般的には、クライアント機能は、アプリケーションレイヤ、又はオペレーティングシステムのような下位レイヤ、又はこれらの任意の組合せにおいて実装され得る。以下は、クライアントアプリケーション１０５の観点で説明されるが、これは限定的ではないことが理解される。
各コンピュータ機器１０２上のクライアントアプリケーション又はソフトウェア１０５のインスタンスは、P２Pネットワーク１０６の転送ノード１０４Fの少なくとも１つに動作可能に結合される。これにより、クライアント１０５のウォレット機能は、トランザクション１５２をネットワーク１０６に送信することができる。クライアント１０５は、また、記憶ノード１０４のうちの１つ、一部、又は全部にコンタクトして、それぞれのパーティ１０３が受領者である任意のトランザクションについてブロックチェーン１５０に問い合わせることができる(又は、実施形態では、ブロックチェーン１５０は、部分的にその公開視認性を通じてトランザクションの信頼を提供する公開的設備であるため、実際には、ブロックチェーン１５０内の他のパーティのトランザクションを検査する)。各コンピュータ機器１０２上のウォレット機能は、トランザクションプロトコルに従ってトランザクション１５２を形成し、送信するように構成される。各ノード１０４は、ノードプロトコルに従ってトランザクション１５２を検証するように構成されたソフトウェア４００を実行し、転送ノード１０４Fの場合は、ネットワーク１０６全体にトランザクション１５２を伝播させるためにトランザクション１５２を転送する。トランザクションプロトコルとノードプロトコルは互いに対応し、所与のトランザクションプロトコルは所与のノードプロトコルと共に所与のトランザクションモデルを実装する。同じトランザクションプロトコルが、ブロックチェーン１５０内の全てのトランザクション１５２に使用される(ただし、トランザクションプロトコルは、トランザクションの異なるサブタイプを許可することができる)。同じノードプロトコルは、ネットワーク１０６内の全てのノード１０４によって使用される(ただし、多くのノードは、そのサブタイプに対して定義されたルールに従って異なるトランザクションのサブタイプを異なるように処理し、また、異なるノードは異なる役割を引き受け、従って、プロトコルの異なる対応する側面を実装することができる)。
上述のように、ブロックチェーン１５０は、ブロック１５１のチェーンを含み、各ブロック１５１は、前述のように、proof-of-workプロセスによって作成された１つ以上のトランザクション１５２のセットを含む。各ブロック１５１は、また、ブロック１５１への逐次的順序を定義するように、チェーン内の先に生成されたブロック１５１を遡ってポイントするブロックポインタ１５５を含む。ブロックチェーン１５０はまた、proof-of-workプロセスによって新しいブロックに含まれることを待つ有効なトランザクション１５４のプールを含む。各トランザクション１５２は、トランザクションのシーケンスに順序を定義するために、前のトランザクションへのポインタを含む(注：トランザクション１５２のシーケンスは、分岐することが許される)。ブロック１５１のチェーンは、チェーンの最初のブロックであったジェネシスブロック（genesis block (Gb)）１５３にまで戻る。チェーン１５０の初期に１つ以上のオリジナルトランザクション１５２は、先行するトランザクションではなくジェネシスブロック１５３を指し示した。
所与のパーティ１０３、例えばAliceがブロックチェーン１５０に含まれる新たなトランザクション１５２jを送信したいと望む場合、彼女は関連するトランザクションプロトコルに従って(彼女のクライアントアプリケーション１０５のウォレット機能を使用して)新たなトランザクションを定式化する（formulate）。次に、クライアントアプリケーション１０５からトランザクション１５２を、彼女が接続されている１つ以上の転送ノード１０４Fの１つに送信する。例えば、これは、Aliceのコンピュータ１０２に最も近いか又は最も良好に接続されている転送ノード１０４Fであってもよい。任意の所与のノード１０４が新しいトランザクション１５２jを受信すると、ノードプロトコル及びそのそれぞれの役割に従って、それを処理する。これは、最初に、新たに受信されたトランザクション１５２jが「有効」であるための特定の条件を満たしているかどうかをチェックすることを含み、その例については、簡単に詳述する。幾つかのトランザクションプロトコルでは、検証のための条件は、トランザクション１５２に含まれるスクリプトによってトランザクションごとに構成可能であってよい。或いは、条件は単にノードプロトコルの組み込み機能であってもよく、或いはスクリプトとノードプロトコルの組み合わせによって定義されてもよい。
新たに受信されたトランザクション１５２jが、有効であると見なされるテストに合格したという条件で(すなわち、「有効である」という条件で)、トランザクション１５２jを受信した任意の記憶ノード１０４Sは、そのノード１０４Sに維持されているブロックチェーン１５０のコピー内のプール１５４に、新たに有効とされたトランザクション１５２を追加する。さらに、トランザクション１５２jを受信する任意の転送ノード１０４Fは、検証済みトランザクション１５２をP２Pネットワーク１０６内の１つ以上の他のノード１０４に伝播する。各転送ノード１０４Fは同じプロトコルを適用するので、トランザクション１５２jが有効であると仮定すると、これは、P２Pネットワーク１０６全体に間もなく伝播されることを意味する。
ひとたび１つ以上の記憶ノード１０４で維持されるブロックチェーン１５０のコピー内のプール１５４に入ると、マイナーノード１０４Mは、新しいトランザクション１５２を含むプール１５４の最新バージョンのproof-of-workパズルを解決するために競争を開始する(他のマイナー１０４Mは、依然として、プール１５４の古いビューに基づいてパズルを解決しようとしているが、そこに到達した者は誰でも、最初に、次の新しいブロック１５１が終了し、新しいプール１５４が開始する場所を定義し、最終的には、誰かが、Aliceのトランザクション１５２jを含むプール１５４の一部のパズルを解決する)。一旦、新しいトランザクション１５２jを含むプール１５４についてproof-of-workが行われると、ブロックチェーン１５０内のブロック１５１の１つの一部となる。各トランザクション１５２は、以前のトランザクションへのポインタを含むので、トランザクションの順序もまた、不変的に記録される。
異なるノード１０４は、最初に所与のトランザクションの異なるインスタンスを受信する可能性があり、従って、１つのインスタンスがマイニングされてブロック１５０になる前に、どのインスタンスが「有効」であるかについて矛盾するビューを有することがあり、その時点で、全部のノード１０４は、マイニングされたインスタンスのみが有効なインスタンスであることに合意する。ノード１０４が１つのインスタンスを有効であるとして受け入れ、次に第２のインスタンスがブロックチェーン１５０に記録されていることを発見した場合、該ノード１０４は、これを受け入れなければならず、最初に受け入れた未だマイニングされていないインスタンスを破棄する（つまり、無効であるとして扱う）。
＜UTXOに基づくモデル＞
図２は、トランザクションプロトコルの例を示している。これは、UTXOベースのプロトコルの例である。トランザクション１５２(「Tx」と略す)は、ブロックチェーン１５０(各ブロック１５１は１つ以上のトランザクション１５２を含む)の基本的なデータ構造である。以下は、アウトプットベース又は「UTXO」ベースのプロトコルを参照して説明される。しかし、これは、全ての可能な実施形態に限定されるものではない。
UTXOベースのモデルでは、各トランザクション(「Tx」)１５２は、１つ以上のインプット２０２及び１つ以上のアウトプット２０３を含むデータ構造を含む。各アウトプット２０３は、未使用トランザクションアウトプット(UTXO)を含んでもよく、これは、別の新しいトランザクションのインプット２０２のソースとして使用することができる(UTXOが未だ償還されていない場合)。UTXOは、デジタルアセット（値のストア）の量を指定する。それは、情報の中でも特にその元となったトランザクションのトランザクションIDを含む。トランザクションデータ構造はまた、ヘッダ２０１も含んでよく、ヘッダ２０１は、インプットフィールド２０２及びアウトプットフィールド２０３のサイズの指示子を含んでもよいヘッダ２０１を含んでよい。ヘッダ２０１は、トランザクションのIDも含んでもよい。実施形態において、トランザクションIDは、トランザクションデータのハッシュ(トランザクションID自体を除く)であり、マイナー１０４Mに提出された未処理トランザクション１５２のヘッダ２０１に格納される。
例えばAlice１０３aは、問題のデジタルアセットの量をBob１０３bに移転するトランザクション１５２jを作成したいと考えているとする。図２において、Aliceの新しいトランザクション１５２jは「Tx１」とラベル付けされている。これは、Aliceにロックされているデジタルアセットの量を、シーケンス内の先行するトランザクション１５２iのアウトプット２０３に取り入れ、その少なくとも一部をBobに移転する。先行するトランザクション１５２iは、図２において「Tx０」とラベル付けされている。Tx０とTx１は、単なる任意のラベルである。これらは、必ずしも、Tx０がブロックチェーン１５１の最初のトランザクションであること、又は、Tx１がプール１５４の直ぐ次のトランザクションであることを意味しない。Tx１は、まだAliceへのロックされた未使用アウトプット２０３を有する任意の先行する（つまり祖先）トランザクションのいずれかを指し示すことができる。
先行するトランザクションTx０は、Aliceがその新しいトランザクションTx１を作成するとき、又は少なくとも彼女がそれをネットワーク１０６に送信するときまでに、既に検証され、ブロックチェーン１５０に含まれていてもよい。それは、その時点で既にブロック１５１のうちの１つに含まれていてもよく、或いは、プール１５４内でまだ待機していてもよく、その場合、新しいブロック１５１にすぐに含まれることになる。あるいは、Tx０及びTx１が生成されネットワーク１０２に送信されることができ、あるいは、ノードプロトコルが「孤児（orphan）」トランザクションのバッファリングを許容する場合にはTx１の後にTx０が送信されることもできる。ここでトランザクションのシーケンスの文脈で使用される「先行する」及び「後の」という用語は、トランザクション内で指定されたトランザクションポインタ(どのトランザクションがどの他のトランザクションを指すかなど)によって定義されるシーケンス内のトランザクションの順序を指す。それらは、「先行する」及び「相続する」又は「祖先」及び「子孫」、「親」及び「子」、等により、等しく置き換えられ得る。これは、必ずしも、それらが作成され、ネットワーク１０６に送られ、又は任意の所与のノード１０４に到達する順序を意味しない。それにもかかわらず、先行するトランザクション(祖先トランザクション又は「親」)を指す後続のトランザクション(子孫トランザクション又は「子」)は、親トランザクションが検証されない限り、検証されない。親の前にノード１０４に到着した子は孤児とみなされる。それは、ノードプロトコル及び/又はマイナーの行動に応じて、親を待つために特定の時間、破棄又はバッファリングされることがある。
先行するトランザクションTx０の１つ以上のアウトプット２０３のうちの１つは、本明細書でUTXO０とラベル付けされた特定のUTXOを含む。各UTXOは、UTXOによって表されるデジタルアセットの量を指定する値と、後続のトランザクションが検証されるために、従ってUTXOが正常に償還されるために、後続のトランザクションのインプット２０２の中のアンロックスクリプトによって満たされなければならない条件を定義するロックスクリプトとを含む。典型的には、ロックスクリプトは、特定のパーティ(それが含まれているトランザクションの受益者)に量をロックする。すなわち、ロックスクリプトは、標準的に以下のようなアンロック条件を定義する：後続のトランザクションのインプット内のアンロックスクリプトは、先行するトランザクションがロックされたパーティの暗号署名を含む。
ロックスクリプト(別名scriptPubKey)は、ノードプロトコルによって認識されるドメイン固有の言語で書かれたコードの一部である。そのような言語の特定の例は、「スクリプト」(Script，capital S)と呼ばれる。ロックスクリプトは、トランザクションアウトプット２０３を消費するために必要な情報、例えば、Aliceの署名の必要条件を指定する。トランザクションのアウトプットには、アンロックスクリプトが現れる。アンロックスクリプト(別名：scriptSig)は、ロックスクリプトの基準を満たすために必要な情報を提供するドメイン固有の言語で書かれたコードの一部である。例えば、Bobの署名を含んでもよい。アンロックスクリプトは、トランザクションのインプット２０２に現れる。
図示の例では、Tx０のアウトプット２０３のUTXO０は、ロックスクリプト[ChecksigPA]を含み、これは、UTXO０が償還されるために(厳密には、UTXO０を償還しようとする後続のトランザクションが有効であるために)、Aliceの署名SigPAを必要とする。[ChecksigPA]は、Aliceの公開－秘密鍵ペアからの公開鍵PAを含む。Tx１のインプット２０２は、Tx１を指すポインタ(例えば、そのトランザクションID、実施形態ではトランザクションTx０全体のハッシュであるTxID０による)を含む。Tx１のインプット２０２は、Tx０の任意の他の可能なアウトプットの中でそれを識別するために、Tx０内のUTXO０を識別するインデックスを含む。Tx１のインプット２０２は、さらに、Aliceが鍵ペアからのAliceの秘密鍵をデータの所定の部分(暗号において「メッセージ」と呼ばれることもある)に適用することによって作成された、Aliceの暗号署名を含むアンロックスクリプト<SigPA>を含む。有効な署名を提供するためにAliceが署名する必要があるデータ(又は「メッセージ」)は、ロックスクリプトにより、又はノードプロトコルにより、又はこれらの組み合わせによって定義され得る。
新しいトランザクションTx１がノード１０４に到着すると、ノードはノードプロトコルを適用する。これは、ロックスクリプトとアンロックスクリプトを一緒に実行して、アンロックスクリプトがロックスクリプトで定義されている条件(この条件は１つ以上の基準を含むことができる)を満たしているかどうかをチェックすることを含む。実施形態では、これは、２つのスクリプトの連結を含む。
Figure 2022533845000002
ここで、「||」は連結を表し、「<...>」はスタックにデータを配置することを意味し、「[...]」はアンロックスクリプトに含まれる機能である（本例では、スタックベースの言語）。同等に、スクリプトは。、スクリプトを連結するのではなく共通のスタックにより１つずつ実行されてよい。いずれの方法でも、一緒に実行する場合、スクリプトは、Tx０のアウトプット内のロックスクリプトに含まれるAliceの公開鍵PAを使用して、Tx１のインプット内のロックスクリプトが、データの期待部分に署名するAliceの署名を含むことを認証する。また、データの期待部分自体(「メッセージ」)も、この認証を実行するためにTx０に含まれる必要がある。実施形態において、署名されたデータは、Tx０の全体を含む(従って、別個の要素は、データの署名された部分がすでに本質的に存在するので、データの署名された部分の指定に明確に含まれる必要がある)。
公開－秘密暗号法による認証の詳細は、当業者には周知であろう。基本的に、Aliceが彼女の秘密鍵によりメッセージを暗号化することによってメッセージに署名した場合、Aliceの公開鍵とそのメッセージが明らか(暗号化されていないメッセージ)ならば、ノード１０４のような別のエンティティは、そのメッセージの暗号化されたバージョンがAliceによって署名されていなければならないことを認証することができる。署名は、典型的には、メッセージをハッシュし、ハッシュに署名し、署名としてメッセージのクリアなバージョンにこれをタグ付けすることによって、公開鍵の所有者が署名を認証することを可能にする。従って、実施形態では、特定のデータ片又はトランザクションの部分等に署名するという言及は、データ片又はトランザクションの部分のハッシュに署名することを意味し得る。
Tx１内のアンロックスクリプトが、Tx０のロックスクリプトで指定された１つ以上の条件を満たす場合(示される例では、Aliceの署名がTx１内で提供され、認証されている場合)、ノード１０４は、Tx１が有効であるとみなす。それが記憶ノード１０４Sである場合、これは、proof-of-workを待つトランザクションのプール１５４にそれを追加することを意味する。それが転送ノード１０４Fである場合、それはトランザクションTx１をネットワーク１０６内の１つ以上の他のノード１０４に転送し、それによって、それがネットワーク全体に伝搬されることになる。一旦、Tx１が検証され、ブロックチェーン１５０に含まれると、これは、Tx０からのUTXO０を消費したものとして定義する。Tx１は、未使用トランザクションアウトプット２０３を使用する場合にのみ有効であることに留意されたい。別のトランザクション１５２によってすでに消費されたアウトプットを消費しようとする場合、Tx１は、たとえ他のすべての条件が満たされていても無効となる。従って、ノード１０４は、先行するトランザクションTx０において参照されたUTXOが既に使用されているかどうか(既に別の有効なトランザクションへの有効なインプットを形成しているかどうか)もチェックする必要がある。これが、ブロックチェーン１５０がトランザクション１５２に定義された順序を課すことが重要である理由の１つである。実際には、所与のノード１０４は、トランザクション１５２が消費されたUTXO２０３をマークする別個のデータベースを維持することができるが、最終的には、UTXOが消費されたかどうかを定義するのは、ブロックチェーン１５０内の別の有効なトランザクションへの有効なインプットを既に形成しているかどうかである。
所与のトランザクション１５２の全部のアウトプット２０３の中で指定された総量が全部のそのインプット２０２により指される総量より大きい場合、これは、殆どのトランザクションモデルにおいて無効の別の基礎である。従って、このようなトランザクションは、伝播されず、マイニングされてブロック１５１にされることもない。
UTXOベースのトランザクションモデルでは、所定のUTXOを全体として使用する必要があることに注意する。UTXOで定義されている量のうち、別の分量が消費されている一方で、分量を「残しておく」ことはできない。ただし、UTXOからの量は、次のトランザクションの複数のアウトプットに分割できる。例えば、Tx０のUTXO０で定義された量は、Tx１の複数のUTXOに分割できる。したがって、AliceがBobにUTXO０で定義された量のすべてを与えることを望まない場合、彼女は残りの量を使って、Tx１の第２のアウトプットの中で自分自身にお釣りを与えるか、又は別のパーティに支払うことができる。
実際には、Aliceは通常、勝ったマイナーのための手数料も含める必要がある。なぜなら、今日では、生成トランザクションの報酬だけでは、マイニングを動機付けるには通常十分ではないからである。Aliceがマイナーのための手数料を含まない場合、Tx０はマイナーのノード１０４Mによって拒否される可能性が高く、したがって、技術的には有効であるが、それは依然として伝搬されず、ブロックチェーン１５０に含まれない（マイナーのプロトコルは、マイナーが望まない場合には、マイナー１０４Mにトランザクション１５２を受け入れるよう強制しない)。一部のプロトコルでは、マイニング料金は、独自の別個のアウトプット２０３を必要としない(すなわち、別個のUTXOを必要としない)。代わりに、インプット２０２によって指される総量と、所与のトランザクション１５２のアウトプット２０３の中で指定される総量との間の差は、勝ったマイナー１０４に自動的に与えられる。例えば、UTXO０へのポインタがTx１への唯一のインプットであり、Tx１は１つのアウトプットUTXO１しか持っていないとする。UTXO０で指定されたデジタルアセットの量がUTXO１で指定された量より多い場合、その差は自動的に勝ったマイナー１０４Mへ行く。しかし、代替的又は追加的に、必ずしも、トランザクション１５２のUTXO２０３のうちの独自のものにおいて、マイナー手数料を明示的に指定できることは除外されない。
Alice及びBobのデジタルアセットは、ブロックチェーン１５０内の任意のトランザクション１５２の中で彼らにロックされた未使用UTXOで構成されている。従って、典型的には、所与のパーティ１０３のアセットは、ブロックチェーン１５０を通して、様々なトランザクション１５２のUTXO全体に分散される。ブロックチェーン１５０内のどこにも、所与のパーティ１０３の総残高を定義する１つの数値は記憶されていない。各パーティへのロックされた、別の将来の（onward）トランザクションに未だ消費されていない全ての様々なUTXOの値をまとめることは、クライアントアプリケーション１０５におけるウォレット機能の役割である。これは、記憶ノード１０４Sのいずれかに記憶されたブロックチェーン１５０のコピーを、例えば、各パーティのコンピュータ機器０２に最も近いか、又は最も良好に接続されている記憶ノード１０４Sに問い合わせることによって行うことができる。
スクリプトコードは、概略的に表現されることが多い(すなわち、正確な言語ではない)ことに注意する。例えば、[Checksig PA]を以下を意味するように記述しできる：
Figure 2022533845000003
「OP_....」は、スクリプト言語の特定のオペコードを表す。OP_CHECKSIG(「Checksig」とも呼ばれる)は、２つのインプット(署名と公開鍵)を取り込み、楕円曲線デジタル署名アルゴリズム(Elliptic Curve Digital Signature Algorithm (ECDSA))を使用して署名の妥当性を検証するスクリプトオペコードである。ランタイムでは、署名(「sig」')の発生はスクリプトから削除されるが、ハッシュパズルなどの追加要件は、「sig」インプットによって検証されるトランザクションに残る。別の例として、OP_RETURNは、トランザクション内にメタデータを格納することができ、それによってメタデータをブロックチェーン１５０に不変に記録することができるトランザクションの使用不可能アウトプットを生成するためのスクリプト言語のオペコードである。例えば、メタデータは、ブロックチェーンに格納することが望ましいドキュメントを含むことができる。
注：表記<H(x)>は、「値hをスタックにプッシュする」を意味する。ここで、値h=H(x)は、アンロックスクリプト内で提供され、H又はxを提供しない。
署名PAは、デジタル署名である。実施形態において、これは楕円曲線secp２５６k１を使用するECDSAに基づく。デジタル署名は、特定のデータに署名する。実施形態では、所与のトランザクションについて、署名はトランザクションインプットの一部、及びトランザクションアウトプットの全部又は一部に署名する。署名するアウトプットの特定の部分はSIGHASHフラグに依存する。SIGHASHフラグは、署名の最後に含まれる４バイトのコードであり、どのアウトプットが署名されるかを選択する(従って、署名の時点で固定される)。
ロックスクリプトは、それぞれのトランザクションがロックされているパーティの公開鍵を含んでいることを表す「scriptPubKey」と呼ばれることがある。アンロックスクリプトは、対応する署名を提供することを表す「scriptSig」と呼ばれることがある。しかし、より一般的には、UTXOが償還される条件が署名を認証することを含むことは、ブロックチェーン１５０の全てのアプリケーションにおいて必須ではない。より一般的には、スクリプト言語は、１つ以上の条件を定義するために使用され得る。したがって、より一般的な用語「ロックスクリプト」及び「アンロックスクリプト」が好ましい。
＜任意的なサイドチャネル＞
図３は、ブロックチェーン１５０を実装するための更なるシステム１００を示す。システム１００は、追加の通信機能が含まれることを除いて、図１に関連して説明したものと実質的に同じである。Alice及びBobのコンピュータ機器１０２a、１０２bの各々に存在するクライアントアプリケーションは、それぞれ、追加通信機能を含む。つまり、それは、Alice１０３ａが、(いずれかのパーティ又は第三者の勧誘で)Bob１０３ｂとの別個のサイドチャネル３０１を確立することを可能にする。サイドチャネル３０１は、P２Pネットワークと別個にデータの交換を可能にする。このような通信は、時に「オフチェーン」と呼ばれる。例えば、これは、パーティのうちの一方がトランザクションをネットワーク１０６にブロードキャストすることを選択するまで、トランザクションがネットワークP２P１０６に（未だ）発行されることなく、又はチェーン１５０上でそのようにすることなく、AliceとBobとの間でトランザクション１５２を交換するために使用されてよい。代替又は追加で、サイドチャネル３０１は、任意の他のトランザクションに関連するデータ、例えば、鍵、交渉される量又は条項、データコンテンツ、等を交換するために使用されてよい。
サイドチャネル３０１は、P２Pオーバレイネットワーク１０６と同じパケット交換ネットワーク１０１を介して確立されてもよい。代替又は追加で、サイドチャネル３０１は、モバイルセルラネットワーク、又はローカル無線ネットワークのようなローカルエリアネットワーク、又はAliceとBobの装置１０２a、１０２bの間の直接有線若しくは無線リンクのような異なるネットワークを介して確立されてよい。一般に、本願明細書のどこかで言及されるサイドチャネル３０１は、「オフチェーン」で、つまりP２Pオーバレイネットワーク１０６と別個にデータを交換するための１つ以上のネットワーキング技術又は通信媒体を介する任意の１つ以上のリンクを含んでよい。１つより多くのリンクが使用されるとき、全体としてのオフチェーンリンクのバンドル又は集合がサイドチャネル３０１と呼ばれてよい。従って、Alice及びBobが特定の情報又はデータ片等をサイドチャネル３０１を介して交換すると言われる場合、これは、必ずしも全部のこれらのデータ片が正確に同じリンク又は同じ種類のネットワークを介して送信される必要があることを意味しないことに留意する。
＜ノードソフトウェア＞
図４は、UTXO又はアウトプットに基づくモデルの例における、P２Pネットワーク１０６の各ノード１０４で実行され得るノードソフトウェア４００の例を示す。ノードソフトウェア４００は、プロトコルエンジン４０１、スクリプトエンジン４０２、スタック４０３、アプリケーションレベルの決定エンジン４０４、及び１つ以上のブロックチェーン関連機能モジュールのセット４０５を含む。任意の所与のノード１０４で、これらは、（ノードの１つ以上の役割に依存して）マイニングモジュール４０５M、転送モジュール４０５F、及び格納モジュール４０５S、のうちの任意の１、２、又は３個全部を含んでよい。プロトコルエンジン４０１は、トランザクション１５２の異なるフィールドを認識し、それらをノードプロトコルに従い処理するよう構成される。トランザクション１５２m（Txm）が受信され、別の先行するトランザクション１５２m-１（Txm-１）のアウトプット（例えばUTXO）をポイントするインプットを有するとき、プロトコルエンジン４０１は、Txm内のアンロックスクリプトを識別し、それをスクリプトエンジン４０２に渡す。プロトコルエンジン４０１は、更に、Txmのインプットの中のポインタに基づき、Txm-１を識別し検索する。それは、Txm-１が未だブロックチェーン１５０上にない場合、それぞれのノード自身の保留中トランザクションのプール１５４から、又はTxm-１が既にブロックチェーン１５０上にある場合、それぞれのノード若しくは別のノード１０４に格納されたブロックチェーン１５０内のブロック１５１のコピーから、Txm-１を検索してよい。いずれの方法も、スクリプトエンジン４０１は、Txm-１のポイントされるアウトプットの中のロックスクリプトを識別し、これをスクリプトエンジン４０２に渡す。
スクリプトエンジン４０２は、従って、Txm-１のロックスクリプト、及びTxmの対応するインプットからのアンロックスクリプトを有する。例えば、Tx１及びTx２が図４に示されるが、Tx０及びTx１等のようなトランザクションの任意のペアについても同様である。スクリプトエンジン４０２は、前述のように２つのスクリプトを一緒に実行し、これらは、使用されているスタックに基づくスクリプト言語（例えばScript）に従い、スタック４０３にデータを置くことと、データを検索することとを含む。
スクリプトを一緒に実行することにより、スクリプトエンジン４０２は、アンロックスクリプトがロックスクリプトの中で定義された１つ以上の基準を満たすか否か、つまり、それがロックスクリプトが含まれるアウトプットを「アンロック」するか否かを決定する。スクリプトエンジン４０２は、この決定の結果をプロトコルエンジン４０１に返す。スクリプトエンジン４０２は、アンロックスクリプトは対応するロックスクリプトの中で指定された１つ以上の基準を満たすと決定した場合、結果「真」を返す。その他の場合、それは結果「偽」を返す。
アウトプットに基づくモデルでは、スクリプトエンジン４０２からの結果「真」は、トランザクションの有効性についての条件のうちの１つである。標準的に、同様に満たされなければならない、プロトコルエンジン４０１により評価される１つ以上の更なるプロトコルレベルの条件が更にあり、Txmのアウトプットの中で指定されたデジタルアセットの総量がそのインプットによりポイントされる総量を超えないこと、Txm-１のポイントされるアウトプットは別の有効なトランザクションにより未だ使用されていないこと、等である。プロトコルエンジン４０１は、１つ以上のプロトコルレベルの条件と一緒にスクリプトエンジン４０２からの結果を評価し、それら全部が真である場合、トランザクションTxmを検証する。プロトコルエンジン４０１は、トランザクションが有効であるかどうかの指示を、アプリケーションレベル決定エンジン４０４に出力する。Txmが実際に検証されたことのみを条件として、決定エンジン４０４は、マイニングモジュール４０５M及び転送モジュール４０５Fの一方又は両方を、それらのそれぞれのブロックチェーンに関連する機能をTxmに関して実行するよう制御することを選択してよい。これは、マイニングモジュール４０５Mがマイニングしてブロック１５１にするためにTxmをノードのそれぞれのプール１５４に追加すること、及び／又は、転送モジュール４０５FがTxmをP２Pネットワーク１０６内の別のノード１０４へ転送することを含んでよい。しかしながら、実施形態では、決定エンジン４０４は無効なトランザクションを転送し又はマイニングすることを選択しないが、逆に言えば、これは必ずしも、単に有効であるという理由で、有効なトランザクションのマイニング又は転送をトリガしなければならないことを意味するものではないことに留意する。任意的に、実施形態では、決定エンジン４０４は、これらの機能のうちのいずれか又は両方をトリガする前に、１つ以上の追加条件を適用してよい。例えば、ノードがマイニングノード１０４Mである場合、決定エンジンは、トランザクションが有効であること、及び十分なマイニング手数料が残されることの両方を条件としてのみ、トランザクションをマイニングすることを選択してよい。
用語「真（true）」及び「偽（false）」は、本願明細書では、必ずしも単一の２進数字（ビット）のみの形式で表現される結果を返すことに限定しないが、それは勿論１つの可能な実装であることに留意する。より一般的には、「真」は、成功又は肯定的な結果を示す任意の状態を表すことができ、「偽」は、不成功又は非肯定的な結果を示す任意の状態を表すことができる。例えば、アカウントに基づくモデルでは（図４に示されない）、「真」の結果は、ノード１０４による署名の暗示的なプロトコルレベルの検証と、スマートコントラクトの追加の肯定的なアウトプットとの組合せにより示され得る（全体の結果は、両方の個々の結果が真である場合に、真を伝達すると考えられる）。
＜例示的なトランザクションセット＞
図５は、本願明細書に開示される実施形態に従い使用するためのトランザクション１５２のセットを示す。セットは、第０トランザクションTx０、第１トランザクションTx１、及び第２トランザクションTx２.を含む。「第０」、「第１」、及び「第２」は、単なる便宜上のラベルであることに留意する。それらは、必ずしも、これらのトランザクションが直ちに１つずつブロック１５１又はブロックチェーン１５０内に置かれること、又は第０トランザクションがブロック１５１又はブロックチェーン１５０内の最初のトランザクションであることを意味しない。また、これらのラベルは、それらのトランザクションがネットワーク１０６へ送信される順序に関して何も示唆しない。それらは、単に、１つのトランザクションのアウトプットが次のトランザクションのインプットによりポイントされる論理的シリーズを表す。幾つかのシステムでは、親をその子の後にネットワーク１０６へ送信することが可能であることを思い出してほしい（この場合、「親のない」子がある期間の間、１つ以上のノード１０４においてバッファされ、その間、親が到着するのを待っている）。
第０トランザクションTx０は、本発明の目的のためにソーストランザクションと呼ばれてもよく、Alice１０３aへのロックされたデジタルアセットの量のソースとして機能する。第１トランザクションTx１は、本発明の目的のためにチャレンジトランザクション又はパズルトランザクションと呼ばれてもよい。それは、第２トランザクションTx２がrパズルに対する解を提供することに依存して、ソーストランザクションTx０からデジタルアセットの量を条件付きで移転するための仲介として機能する。第２トランザクションTx２は、証明トランザクション又は支払いトランザクションと呼ばれてもよく、第１トランザクションTx１内に設定されたrパズルに対する解を提供し、結果として生じる証明者（又は場合によっては、証明者が代表を務める受益者）への支払いをロックするトランザクションである。実施形態は、証明者（第２パーティ）がBobになるが、後の議論に基づき認められ、実際にrパズルが、任意の第２パーティがrパズルを解く有効な署名を提供する限り、アイデンティティに関係なく、彼らが証明者になることを許容する例を用いて説明され得る。
図５に示すように、ソーストランザクションTx０は、デジタルアセットの量を指定する少なくとも１つのアウトプット２０３０（例えば、Tx０のアウトプット０）、及びAlice１０３aへのこのアウトプットをロックするロックスクリプトを更に含む。これは、ソーストランザクションTx０のロックスクリプトが、少なくとも１つの条件が満たされることを要求することを意味する。この条件は、アウトプットをアンロックしようとする（従って、デジタルアセットの量を償還する）任意のトランザクションのインプットが、そのアンロックスクリプト内にAliceの暗号署名（つまり、Aliceの公開鍵を使用する）を含まなければならないことである。この意味で、Tx０のアウトプット内で定義される量は、Aliceにより所有されると言える。アウトプットは、 UTXOと呼ばれてよい。どの先行するトランザクションのアウトプットがTx０のインプットをポイントするかは（それらが、Tx０の合計アウトプットをカバーするのに十分である限り）、本発明の目的のために特に重要ではない。
本発明の場合には、ソーストランザクションTx０のアウトプットをアンロックするトランザクションは、第１トランザクションTx１（チャレンジトランザクション）である。従って、Tx１は、Tx０の関連するアウトプット（図示の例ではTx０のアウトプット０）へのポインタを含み及び該アウトプットのロックスクリプト内で定義された条件に従いTx０のポイントされたアウトプットをアンロックするよう構成される、少なくともAliceの署名を要求するアンロックスクリプトを更に含む、少なくとも１つのインプット２０２１（例えばTx１のインプット０）を有する。Tx０のロックスクリプトにより要求されるAliceからの署名は、Tx１の特定の部分に署名することが要求される。幾つかのプロトコルでは、署名される必要のあるTx１の部分は、Tx１のアンロックスクリプト内で定義された設定であり得る。例えば、これは、署名に付加される１バイトであるSIGHASHフラグにより設定されてよい。従って、データの観点では、アンロックスクリプトは次の通りである：<Sig PA><sighashflag><PA>代替として、署名される必要のある部分は、単にTx１.の固定又はデフォルト部分であってよい。いずれの方法も、署名されるべき部分は、標準的に、アンロックスクリプト自体を除き、及びTx１のインプットの一部又は全部を除いてよい。しかしながら、Tx１の署名済み部分は、少なくとも、rパズルを含むアウトプット２０３１を含む（以下を参照、本例ではTx１のアウトプット０）。
第１トランザクションTx１は、少なくとも１つのアウトプット２０３１（例えば、ここでもアウトプットがUTXOと呼ばれてよいTx１のアウトプット０）を有する。第１トランザクションTx１のアウトプットは、任意の１つのパーティにロックされない。Tx０と同様に、それは、転送されるべきデジタルアセットの量を指定する少なくとも１つのアウトプット（例えば、Tx１のアウトプット０）を有する。該アウトプットは、該アウトプットをアンロックする、従って該量を償還するために何が必要かを定義するロックスクリプトを更に含む。しかしながら、このロックスクリプトは、rパズルの解を提供する任意のパーティによりアンロックされることが可能である。
第２トランザクション（支払いトランザクション）Tx２は、少なくとも１つのインプット２０２２（例えば、Tx２のインプット０）を有し、該インプットは、Tx１の上述のアウトプット（図示の例ではTx１のアウトプット０）へのポインタを含み、Tx１のロックスクリプトの中で定義されたアンロックスクリプトの１つ以上の要件を満たすことに基づきTx１の該アウトプットをアンロックするよう構成されるアンロックスクリプトも更に含む。本願明細書に開示される実施形態によると、アンロック条件は、少なくとも、対応するアンロックスクリプトがrパズルに対する解を含むという要件を含む。rパズルは、楕円曲線暗号（elliptical curve cryptography (ECC)）署名のr部分に基づきTx１のロックスクリプト内で定義されるチャレンジを含む。これは、Tx２のアンロックスクリプトに彼らの署名（又は少なくともそのs部分）を含む任意のパーティ（この場合にはたまたまBobである）により満たされることができる。Tx０のロックスクリプトと異なり、任意のパーティの署名は、それがrチャレンジ（つまり、rパズル）を満たす有効な署名である限り、Tx１のロック条件をアンロックするために使用できる。これの例は、間もなく更に詳細に議論される。Bobは、単に、証明者又は第２パーティの例としてここで選択されたが、rパズルは、実際には、任意の第２パーティ、例えば、Charlie、Dora、Ezekiel、等が証明者になることを許容する。幾つかの実施形態では、Tx）１内のアンロック条件は、１つ以上の更なる条件を条件としても生成され得る。例えば、Aliceの署名がTx２のアンロックスクリプトにも含まれることを要求する。
第２トランザクションTx２は、少なくとも１つのアウトプット２０２２（例えば、Tx２のアウトプット０）を有し、該アウトプットは、Bobへ移転すべきデジタルアセットの量、及びこれをBobに対してロックするロックスクリプトを指定する（つまり、これは、更なる、今後のトランザクションが、使用するためにアンロックスクリプトの中にBobの署名を含むことが要求される）。この意味で、ターゲットトランザクションTx２のアウトプットは、Bobにより所有されると言える。このアウトプットは、ここでもUTXOと呼ばれてよい。
証明者の署名（例えば、Bobの場合にはSig PB）により署名されたTx２の部分は、少なくとも、このアウトプット２０３２、つまり証明者への支払いをロックするアウトプット（本例では、Tx２）のアウトプット０）を含む。
実施形態では、Tx１内のアウトプット２０３１内のロックスクリプトがアウトプットをアンロックするための複数の代替条件、例えば複数の代替のｒパズルを定義することが可能である。この場合、Ｔｘ２のインプット２０２２内のアンロックスクリプトは、それが代替アンロック条件のうちのいずれか１つを満たす場合、Tx１のアウトプットをアンロックする。
第０（つまり、ソース）トランザクションTx０は、Alice、証明者（例えば、Bob）、又は第三者により生成されてよい。それは、標準的に、AliceがTx０のインプット内に定義された量を取得した先行するパーティの署名を要求する。それは、Alice、Bob、先行するパーティ、又は別の第三者によりネットワーク１０６へ送信されてよい。
第１トランザクション（つまり、チャレンジトランザクション）Tx１は、Alice、証明者（例えば、Bob）、又は第三者により生成されてもよい。実施形態では、それはAliceの署名を要求するので、それはAliceにより生成されてよい。代替として、それは、Bob又は第三者によりテンプレートとして生成され、次に署名のためにAliceへ送信されてよく、例えばサイドチャネル３０１を介して送信される。Aliceは、次に、署名付きトランザクションをネットワーク１０６へ彼女自身で送信し、又はそれをBob若しくは第三者へ送信してそれらをネットワーク１０６へ転送し、又は単に彼女の署名をBob若しくは第三者へ送信して、署名付きTx１に構成してネットワーク１０６へ転送できる。Tx１をネットワーク１０６へ送信する前の任意のオフチェーン交換は、サイドチャネル３０１を介して実行されてよい。
第２トランザクション（つまり、証明又は支払いトランザクション）Tx２は、Alice、証明者（例えば、Bob）、又は第三者により生成されてよい。第１バージョンは証明者の署名及び／又はデータを要求するので、Bobにより生成されてよい。代替として、それは、Alice又は第三者によりテンプレートとして生成され、次に、署名するためにBobへ送信されてよく、例えば、サイドチャネル３０１を介してBobへ送信される。Bobは、次に、署名付きトランザクションをネットワーク１０６へ彼自身で送信し、又はそれをAlice若しくは第三者へ送信してそれらをネットワーク１０６へ転送し、又は単に彼の署名をAlice若しくは第三者へ送信して、署名付きTx２に構成してネットワークへ転送できる。
トランザクションの異なる要素が生成され構成され得る種々の位置があり、それが直接に又は間接的にP２Pネットワーク１０６の最終的な宛先へと送信される種々の方法があることが理解される。開示の技術の実装の範囲は、これらのいずれに関しても限定されない。
「Aliceにより」、「Bobにより」、及び「第三者により」のような語句は、本願明細書では、それぞれ「Aliceのコンピュータ機器１０２aにより」、「Bobのコンピュータ機器１０２bにより」、及び「第三者のコンピュータ機器１０２により」の短縮表現として使用されることがある。また、所与のパーティの機器は、該パーティにより使用される１つ以上のユーザ装置、又は該パーティにより利用されるクラウドリソースのような幾つかのサーバリソース、又はそれらの任意の組合せを含み得ることに留意する。それは、必ずしも動作が単一のユーザ装置上で実行されることに限定しない。
＜楕円曲線デジタル署名アルゴリズム（ELIPTICAL CURVE DIGITAL SIGNATURE ALGORITHM (ECDSA)）＞
公開鍵暗号法は、多数の異なるブロックチェーンアーキテクチャにおいてトランザクションをセキュアにするための基礎として使用される。公開鍵暗号法の使用は、公開鍵暗号化及びデジタル署名方式を含む。公開鍵暗号法は、特定の関数が、計算するのは容易だが、何からの特定の知識が無くては逆算（reverse）することが困難であるという原理に基づいている。そのような関数は、落とし戸関数（trapdoor function）と呼ばれ、それを逆算するために必要な特定の知識は該関数の落とし戸（トラップドア）と呼ばれる。計算するのが容易であることは、所与の入力（又は入力のセット）について妥当な時間枠内で落とし戸関数を計算することが計算上実現可能であることを意味し、逆算が困難であることは、落とし戸の知識を有しないで結果から該入力（又は複数の該入力）を推定することが計算上不可能であることを意味する。
公開鍵暗号法の文脈では、鍵ペアは、公開鍵（これは誰にでも自由に入手可能にできる）及び対応する秘密鍵（これは、特定のエンティティ又はグループにのみ知られているという意味で、秘密であると想定される）を意味する。公開鍵は落とし戸関数を定義し、対応する秘密鍵は該関数を逆算するために必要な落とし戸である。
公開鍵暗号の文脈では、暗号化は、落とし戸関数に基づき（つまり、暗号化は「順方向」に実行され）、一方で、復号は、落とし戸が分かっているときにのみ実現可能である落とし戸関数の逆算に基づく（つまり、復号は、「逆方向」に実行される）。
デジタル署名の文脈では、署名検証は、公開鍵を用いて順方向に実行され、署名生成は、逆方向に実行され、秘密鍵を用いてのみ実行可能である。
ブロックチェーンの文脈では、公開鍵暗号法に基づくデジタル署名は、トランザクションに暗号法で署名するため及びトランザクション署名を検証するための基礎として使用される。
ECCは、楕円曲線の数学的特性を利用する形式の公開鍵暗号法であり、DSA（Digital Secure Algorithm）のような他の暗号方式に対して種々の利点を有する。
「楕円曲線デジタル署名アルゴリズム（Elliptic Curve Digital Signature Algorithm (ECDSA)）」は、デジタル署名生成及び検証のための基礎としてECCを使用するクラスのデジタル署名方式を表す。ECDSAの特定の原理は以下に概説される。
数学的用語では、ECCは、素数位数の有限体上の楕円曲線の代数的構造を利用する。有限体は、要素の有限の集合、並びに、集合内の要素に適用されるとき通常の算術規則（結合法則、可換性、等）を満たす乗算、加算、減算、及び除算の関連する演算のセットを意味する。つまり、「通常」の意味で、加算、乗算、等を必要としないが、本質的に同じように振る舞う、演算である。
楕円曲線演算：
ECCの文脈では、加算、減算、及び乗算演算は、それぞれ、本願明細書で「+」で示される楕円曲線点加算、本願明細書で「-」で示される楕円曲線点減算、及び本願明細書で「・」で示される楕円曲線点乗算である。加算及び減算演算は、それぞれ、楕円曲線上の２個の点に適用され、楕円曲線上の第３の点を返す。しかしながら、乗算演算は、スカラー及び楕円曲線上の単一の点に適用され、楕円曲線上の第２の点を返す。これに対して、除算は、スカラー上で定義される。
説明を目的として、図６Aは、全ての実数値の２次元座標の集合：
Figure 2022533845000004
 における楕円曲線εを示し、
Figure 2022533845000005
 は
Figure 2022533845000006
 の要素を示す。楕円曲線εは、次式を満たす点の集合である：
Figure 2022533845000007
加算：εの数学的特性は、楕円曲線ε上の任意の２個の点A、Bが与えられると、A及びBと交差する直線はεとCと示される１個の追加の点でのみ再び交差し；A及びBの楕円曲線加算、つまりA+Bは、Cの「反射（reflection）」として定義され、Cと交差する水平線を取ると、Cの反射は、該直線が交差する楕円曲線上の他方の点である。この定義は、∞と示される無限遠点を楕円曲線上の点として及びそこで任意の垂直線が楕円曲線と交差すると定義することにより（例えば、D及びEとラベル付けされた点が垂直方向及び水平方向に揃えられ、従ってD+E=∞である）、２個の点と交差する線が垂直である場合に当てはまる。この定義は、∞と示される無限遠点を楕円曲線上の点として及びそこで任意の垂直線が楕円曲線と交差すると定義することにより（例えば、D及びEとラベル付けされた点が垂直方向及び水平方向に揃えられ、従ってD+E=∞である）、２個の点と交差する線が垂直である場合に当てはまる。
減算／加算反数（Subtraction/additive inverse）：上述の反射の定義は、任意の点に適用され、楕円曲線点減算の定義を提供する。A-Bは、AとBの反射との和である。Bの反射は、より正式にはBの「加算反数」と呼ばれ、-Bと示される。この表記を用いて、楕円曲線減算は、数学的表記で定義できる：
Figure 2022533845000008
ここで、図６Bにおいて、C=-(A+B)及び(A+B)=-C。この定義の下で、D=-Eであり、代数構造の一般的規則を反映すること、つまり、楕円曲線上の任意の点とその加算反数との楕円点加算が無限遠点であることにも留意する。つまり、
Figure 2022533845000009
無限遠点∞は、より正式には、「単位元」と呼ばれる（通常の算術計算の平行と偏差の両方に留意する：通常の算術計算では、任意の数aとその加算反数-aとの和は０であり、０は通常の算術計算の単位元である）。単位元、通常の算術計算をミラーリングする∞の別の特性は、∞自体を含むε上の任意の点Aについて、A+∞=Aであることである（任意の実数aについて、ステートメントa+０=０と同様である）。
乗算：楕円曲線点加算の定義から、楕円曲線スカラー乗算の定義は以下の通りである。楕円曲線点Aの整数vとの乗算は次式のように定義される：
Figure 2022533845000010
つまり、Aのそれ自体とのv回の楕円曲線点加算としてである。
注：楕円曲線スカラー乗算は、従来、楕円曲線点乗算とも呼ばれている。これらの２つの用語は、本開示において同じ意味を有する。
除算／乗算反数（Division/multiplicative Inverse）：除算の延安は、スカラーに関して定義される。スカラーvが与えられると、「乗算反数」はスカラーv-１として定義され、その結果、以下の通りである：
Figure 2022533845000011
図６Aは、上述の演算の直感的視覚化を提供する。ここで、εは、全部の実数：
Figure 2022533845000012
 を含む無限体に渡り定義される。
図６Bは、次式により定義される楕円曲線εnを示すので、上述の演算が、ECCの文脈で実際にどのように適用されるかをより厳密に表す：
Figure 2022533845000013
ここで、pは素数（素数モジュラス）であり、modはモジュロ演算を示す。上式を満たす点の集合は有限であり、それらの点のうちの１つを除き全部が白丸として図６Bに示され、残りの点は単位元∞である。
素数pは、楕円曲線の定義の部分を形成し、自由に選択できる。楕円曲線が良好な暗号特性を有するためには、pは十分に大きくなければならない。例えば、２６５ビットのpが特定のブロックチェーンモデルにおいて指定される。
添え字「n」は、本願明細書では、以上に定義された点加算の下で楕円曲線点により形成されるグループの次数を表す（簡単に言うと、これは、楕円曲線εnの次数と呼ばれてよい）。以下を参照する。
言い換えると、nはグループの次数であり、pはフィールドの次数である。全部でn個の楕円曲線点がある。楕円曲線上の各点は、２個の数／座標（x,y）により表され、ここで、x及びyは、全部、範囲－(p-１),…０,…,(p-１)の中にある。
図６Bのεnは図６Aのεnと同様に水平対称性であることが分かる。これは、素数ファイル（prime file）に対する楕円曲線の一般的特性であり、従って、εn上の点の加算反数の定義が依然として当てはまる。幾つかの点は水平方向に揃えられた対称点を有しない（例えば、（０,０））。そのような点は、それら自体の加算反数である。
εn上の２点A及びBと交差する「直線」lA,Bは、有限点集合になり、小さな黒丸により示され、同様の幾何学的要件を満たし、楕円曲線スカラー乗算の定義が依然として当てはまる。図６Aと同様に、図６Bは、点C=-(A+B)の加算反数である点A+B=-Cを示し、ここで直線lA,Bがεnと再び交差する。
εn上の２点の楕円曲線加算A+B=-Cは、次式により代数的に定義できる：
Figure 2022533845000014
上述の目的のために、整数vの乗算反数v-１の定義は、以下のように変更される：
Figure 2022533845000015
つまり、整数vの乗算反数は、v mod pのモジュラ反数である。
B=-Aの場合は特別であり、単位元∞の導入により解決され、上述のように、この場合、A+B=A+(-A)=∞である。B=∞の場合も特別であり、上述のようにA+∞=Aと表記して解決される。
楕円曲線スカラー乗算の定義は、楕円曲線加算のこの定義を採用し、その他の場合には同じままである。
他の文脈では、関連するスカラーvの乗算反数v-１の定義は：
Figure 2022533845000016
 乗算反数がmod n又はmod pに関して定義されるかは、文脈上明らかである。
実際に、数がmod n又はmod pとして扱われるべきかを識別するために、以下のチェックが適用されてよい：
（１）EC点の座標を表す数であるか？
a）Yesの場合、mod p
（２）EC点を乗算するために使用される数であるか？
a）Yesの場合、mod n
両方のチェックが肯定的結果を与えたる場合があることに留意する。この場合、その数はmod p且つmod nでなければならない。
＜楕円曲線暗号法（Elliptic Curve Cryptography (ECC)）＞
楕円曲線演算は、シークレット値を不明瞭にするユニークな能力を提供し、多くの現代の暗号システムの基礎を形成する。特に、有限体に渡る楕円曲線点のスカラー乗算を逆算することは、至難問題である（実行することが計算上不可能である）。
秘密鍵Vは整数の形式をとり、対応する公開鍵Pは、楕円曲線εn上の点である「生成元（generator point）」Gから導出される、楕円曲線εn上の点Pであり、次式の通りである：
Figure 2022533845000017
ここで、「・」は、a、b、及びn（楕円曲線パラメータ）により定められる、楕円曲線εn上の楕円曲線スカラー乗算を示す。
十分に大きなVについて、Pを導出するために実際にV回の楕円曲線加算を実行することは困難である、つまり計算上不可能である。しかしながら、Vが知られている場合、Pは、楕円曲線演算の代数特性を利用することにより、遙かに効率的に計算できる。Pを計算するために使用できる効率的なアルゴリズムの例は、「Double and Add」アルゴリズムである。重大なことに、これはVが知られている場合にのみ実施できる。
反対に、Vが分からない場合、G及びPの両方が分かっていたとしても、Vを導出する（つまり、スカラー乗算を逆算する）計算上実行可能な方法は存在しない（これは、所謂「離散対数問題」である）。攻撃者は、Gから開始して、Pを得るまで楕円曲線点加算を繰り返し実行することにより、「力ずくで」Pを破ろうとし得る。この点において、攻撃者は、Vが、彼が実行すべき楕円曲線点加算の数であることを知っているが、それは計算上不可能であることが分かる。従って、Vは、上述の意味において落とし戸の要件を満たす。
ECCでは、公開鍵P、生成鍵G、及び楕円曲線εnは、公開されており、知られていると想定されるが、秘密鍵Vは秘密である。
＜楕円曲線デジタル署名検証アルゴリズム（ECDSA)）＞
ブロックチェーンシステムでは、ユーザ又は他のエンティティは、標準的に、彼らのアイデンティティを証明するために使用される秘密鍵Vを保持し、対応する公開鍵Pは次式により計算され得る：
Figure 2022533845000018
秘密鍵Vは、ECDSAを用いてデータのピースm（「メッセージ」）に署名するために使用できる。
ECDSAの更なる詳細は、参照によりその全体が本願明細書に組み込まれる次の文献で与えられる："RFC６９７９-Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA)", Tools.ietf.org, ２０１９。
図６Cは、公開鍵－秘密鍵ペア（V,P）についてECDSA署名（r,s）を生成する署名生成機能（署名生成器６００）の概略機能ブロック図を示す。EDSA署名は、本願明細書ではそれぞれr部分（r-par (r)）及びs部分（s-part (s)）と呼ばれる値のペアである。
署名生成は、公開鍵Pを導出するために使用された同じ楕円曲線εn及び生成元Gに基づく。従って、楕円曲線パラメータa、b、及びn、並びに生成元Gは、署名生成器６００への入力として示される。
署名生成器６００の一時鍵生成器６０２は、「一時」鍵k∈[１,n-１]を、つまり両端を含む１～n-１の範囲で生成する。
r部分生成器６０４は、kから対応する一時鍵を以下のように計算する。
Figure 2022533845000019
そして次に、計算される点のx座標を取り入れる（楕円曲線点のx座標を取り入れる処理を示す[]xによる）：
Figure 2022533845000020
上式は署名のr部分である。
s部分生成器６０６は、k mod nのモジュラ反数k-１を用いて署名のs部分を計算し（つまり、次式であり、先の説明を参照する）：
Figure 2022533845000021
 H(m)と示される（必要な場合にはトランケートされる）、メッセージmのハッシュは以下の通りである：
Figure 2022533845000022
本例では、メッセージmは、トランザクション６０８に含まれるべき日を含む（本例では１つ以上のトランザクションアウトプット）。これは、メッセージmに署名する処理と呼ばれてよく、メッセージmは、トランザクションの署名済み部分と呼ばれてよい。
メッセージm及び署名（r,s）は、また、トランザクション６０８の部分を形成する。本例では、署名（r,s）は、アンロックスクリプトの部分としてトランザクション６０８のインプットに含まれる。
図６Dは、トランザクション６０８を検証する署名検証機能（署名検証器）６２０の概略機能ブロック図を示す。署名検証器６２０により実行される計算は、留意すべきことに公開されている同じ楕円曲線εn及び生成元Gに基づく。
署名は秘密鍵Vをインプットとして要求するが、つまり有効な署名を生成するためにその知識を要求するが、署名（r,s）を検証するためには、署名ペア（r,s）、メッセージm、及び公開鍵Pしか必要ない。署名を検証するために、署名検証器６２０は、トランザクションmの署名済み部分をハッシングする（署名（r,s）を生成するために使用されたのと同じハッシュ関数Hを適用する）。検証処理は、次に、以下の計算を用いて実行される。
Figure 2022533845000023
[R’]x=rの場合及びその場合にのみ、署名は有効である（つまり、署名検証器が成功する）。その他の場合、無効である（つまり署名検証が失敗する）。本例では、rは、トランザクション６０８に含まれる署名のr部分を示す。
署名検証器処理で使用される公開鍵Pは、例えば、先行するトランザクションのロックスクリプト内で指定される。署名検証は、この場合には、先行するトランザクションのロックスクリプト内で指定された公開鍵、（後の）トランザクション６０８の署名された部分m及び署名（r,s）を用いて実行され、署名（r,s）が先行するトランザクション内で指定された公開鍵Pに対応する秘密鍵V及びのりのトランザクション６０８の署名された部分mに基づき生成されたものでない限り、失敗する。従って、秘密鍵Vを肘する人物のみが、（標準的には、彼ら自身の公開鍵を後のトランザクション６０８のアウトプットに含めることにより）先行するトランザクションのアウトプットを請求でき、後のトランザクション６０８の署名された部分mは署名（R,S）を無効にすることなく変更できない。
Rパズル
以下は、ECDSAに基づく知識証明の新しい形式を記載する。説明により、チャレンジャーは、彼女自身でTx１を生成しP２Pブロックチェーンネットワークに発行することにより、又はTx１を構成し発行するための必要な詳細を第三者に提供することにより、第１トランザクションTx１内でrパズルを設定する第１パーティAliceである。検証者（実際に証明を実行するパーティ）は、ネットワークのノード１０４のオペレータ、例えばマイナーである。ｒパズルの回は、ネットワーク１０６にTx２を発行することにより、提供される。ｒパズルがアイデンティティに本質的に結び付けられないので、証明者は任意の第２パーティであり得る。しかし、例として、以下は、証明者がたまたまBobであるシナリオの観点で記載されることがある。証明者は、彼自身でTx２を生成し発行するか、又は必要な詳細を第三者に提供してそれらをTx２に構成し発行するようにしてよい。
暗号ハッシュ関数は、インプットの小さな変更がアウトプットの予測できない変更をもたらす場合に、インプットを決定論的に不明確にする手段を提供する。従来のハッシュ関数は、MD５、RIPEMD-１６０、SHA-１、及びSHA-２５６[５]を含む。これらはそれぞれ、衝突耐性（同じアウトプットを生成する２つのインプットを見付ける確率が極めて小さい）、及びプリイメージ耐性（ハッシュ値h=H(d)が与えられた場合に、インプットdを見付けることが極めて困難である）。
従来のハッシュパズルは以下のように設定できる。考え方は、第１トランザクションTx１を設定することである。第１トランザクションTx１は、第２トランザクションTx２がそのインプットに何らかの特定のデータのピースを含むことを条件として、自身のアウトプットが第２トランザクションTx２により償還されることを可能にする。
ブロックチェーントランザクションでは、単純に、以下のように、ロックスクリプト内でハッシュ値ｈを用いて、第１パーティ（Alice）は、非標準トランザクションTx１を生成し得る：
Figure 2022533845000024
ここで、h=Hpuz(d)であり、Hpuzは、パズルの中で使用されるハッシュ関数である（上述の例では、ロックスクリプトによると、このハッシュ関数はHASH１６０でなければならないが、他の実装では他の形式のハッシュ関数が使用され得る）。このロックスクリプトが含まれるUTXOを償還することは、後のトランザクションのアンロックスクリプト内にあるハッシュパズル解を要求する。従って、アドレスAddr_Bobを有する第２パーティのための支払いトランザクションTx２は、dを含むだけでよいアンロックスクリプトにより構成され得る。
Figure 2022533845000025
ここで、TxIDiはTxiのトランザクションIDである。ロックスクリプトは以下を記述する：Tx２のインプット内のアンロックスクリプトからデータ値dを取り込み、それをハッシングし、それがTx１のアウトプット内のロックスクリプトに含まれるハッシュ値ｈと等しいかどうかをチェックする。従って、アウトプットは、Tx２のアンロックスクリプト内のdを提供することにより、アンロックされる。
この素朴な例では、Tx２内のハッシュパズル解を有するユーザのトランザクションが分かった後に、このトランザクションを最初に受信したマイナーは、悪意をもってトランザクションを拒否し、ハッシュパズルに対する同じ解を有するが、彼ら自身のアドレスAdd_Minerにアウトプットを変更している、新しい柔軟な（malleated）バージョンTx２*を生成することができる。悪意あるマイナーは、次に、彼／彼女自身でTx２*をマイニングしてブロック１５１にすることができる。Tx２がマイニングされる前に、彼らがTx２*をマイニングすることに成功すれば、悪意あるマイナーはBobの代わりに支払いを受け取るだろう。
Figure 2022533845000026
デジタル署名は、所有権を証明し未使用トランザクションアウトプット（unspent transaction output (UTXO)）を償還するために、ブロックチェーントランザクションの中で一般的に使用されている。これは、Tx１のようなトランザクションのアウトプットが、特定のパーティにロックされることを可能にする。最も一般的な例は、トランザクションのアウトプットが公開鍵の特定のハッシュ（これは、そのパーティのアドレスとしても機能する）にロックされるP２PKH（pay-to-public-key-hash）トランザクションである。公開鍵Pのロックスクリプトは：
Figure 2022533845000027
ここで、hＰ=Hsig(Ｐ)であり、Hsigは、署名の中で使用されるハッシュ関数である（上述の例では、ロックスクリプトによると、このハッシュ関数はHASH１６０でなければならないが、他の実装では他の形式のハッシュ関数が使用され得る）。このUTXOを別のトランザクションへのインプットとして使用可能にするためには、Pを用いて有効なECDSA署名を有するアンロックスクリプトを提供する必要がある：
Figure 2022533845000028
文字列全体（アンロック＋ロックスクリプト）は、マイナーにより評価される。マイナーは、正しい公開鍵が提供されるか、及び署名が有効でありPに対応するか、をチェックする。ロックスクリプトは、基本的に以下を記述する：Tx２のインプット内のアンロックスクリプトから公開鍵Pを取り入れ、それをハッシングし、それがTx１のアウトプット内のロックスクリプトに含まれるハッシュ値hPと等しいかどうかをチェックし、更に、Tx２の署名済み部分の知識が与えられた場合に、Tx２のアンロックスクリプトから公開鍵Pを用いて、ECDSA検証関数に基づき署名sigを検証する。ECDSA検証関数はOP_CHECKSIGオペコードにより呼び出される。
従って、アウトプットは、Tx２のアンロックスクリプト内で、Pに対応する秘密鍵Vに基づき署名された有効な署名sigを提供することによってのみ、アンロックできる。
これをハッシュパズルと一緒にすると、上述の脆弱性は、ハッシュパズル解と一緒に、意図された受信者からのデジタル署名を要求することにより、修正できる。ロックスクリプトは以下のように構成され得る：
Figure 2022533845000029
対応するアンロックスクリプトは次のようになる：
Figure 2022533845000030
しかしながら、これは、それを償還できる人を、公開鍵Pの所有者に制限する。ここで、これは幾つかの適用では、例えば、Aliceがパズルを設定した後にのみ署名権限を選定する能力を保持したい場合、望ましくないことがあることが分かる。
ここで、ハッシュパズル機能は、一時的なランダム値であってよいECDSA署名の中のr部分を利用することにより、エミュレートできることが分かる。ECDSA署名は、２つの部分r及びsで構成される。以上から分かるように、r=[k・G]xである。従来のハッシュパズルh=H(d)の代わりに、楕円曲線加算の逆算の困難さは、本願明細書でrパズルと呼ばれる類似のパズルを形成できる。パズルを解くためには、解の値kを取得する必要があり、ここで、kは、rに対応する一時鍵である。
従来のハッシュパズルでは、パズルを解くときに、ブロックチェーン上にｄを開示するリスクがある。しかしながら、rパズルでは、kは決して開示されない。その代わり、rが開示され、署名と共にrから、kの知識が証明できる。
kは固定サイズでなければならないが、ハッシュパズルのプリイメージデータは任意の長さにできるので（そして、ハッシュ関数の１つの特徴は、インプットデータの長さに拘わらず、固定長の値を出力することである）、ハッシュパズル機能をエミュレートするために、rパズルの生成者は、先ず、何らかの多のプリイメージデータをハッシングして値kを取得してよい。例えば、２５６ビット長の秘密／一時鍵を使用する場合、kを得るために、rパズルに対するプリイメージデータはハッシングされなければならない。代替として、しかしながら、何らかの適切な長さ値のkは、単に選択され、それ自体の能力で直接シークレット値として使用され得る（つまり、何らかの他の選考するプリイメージからそれを導出する必要がない）。
この方法は、支払い（spending）のためにECDSA署名を使用する任意のブロックチェーンシステムと共に使用できる。説明のために、以下は、UTXOに基づくモデルにおける例示的な実装を説明する。スクリプト言語では、OP_CHECKSIGオペコードは、スタック上で署名及び公開鍵を要求する（スタックの一番上には公開鍵があり、その直下に署名がある）。rパズルについて、スクリプトは、提供された署名の中のr値がrパズルチャレンジのっために使用されたものと同じであるかをチェックするよう構成される。言い換えると、スクリプトは、（OP_CHECKSIGを通じて）署名が公開鍵に基づき有効であることをチェックするだけでなく、署名が、ブロックチェーン上で事前に発行されているｒパズルのr値を用いて生成されたことも確かめる。
rパズルの幾つかの例示的な実装は、図７～１０を参照して以下に議論される。それぞれの場合に、証明者、例えばBobは、Tx２の部分に署名することにより、署名（r,s）を生成している。この形式の署名は、時に、「sig」と呼ばれることもある。暗号書名の文脈では、署名済み部分は「メッセージ」（m）とも呼ばれる。署名済み部分（メッセージ）mは、少なくとも、結果として生じるBobへの支払いをロックする、Tx２のアウトプットを含む。１つより多くのアウトプットが存在する場合、mは、アウトプットのうちの一部又は全部を含んでよい。mは、使用される場合には、ロックタイム（locktime）のような他の部分も含んでよい。しかしながら、それは、アンロックスクリプト自体を除く（及び、勿論、少なくとも、署名自体を除く）。メッセージmとして署名されるべきTx２の部分は、Sighashにより設定され、又はデフォルトであり、マラはプロトコルの固定的特徴であることもできる。
おそらく、rパズルの最も簡単な実装は図７に示される。Tx１内のロックスクリプトは、ここではr'とラベル付けされる、参照インスタンス又はr部分を含む。この方法では、Tx２内のアンロックスクリプトは、少なくとも、Bobの署名のs部分（s）のみを含めばよい。それは、Bobがmに署名するために使用した秘密鍵Vに対応する公開鍵Pも含んでよい。Tx１のロックスクリプトは、ノード１０４でスクリプトエンジン４０２により実行されると、s及びPをTx２のアンロックスクリプトから取り入れ、以下の演算を実行するように構成される。
Figure 2022533845000031
ここで、r'は、Tx１のロックスクリプトから取り入れられ、s及びmは、Tx２のアンロックスクリプトから取り入れられる。Bobの公開鍵Pも、Tx２のアンロックスクリプトから取り入れられてよく、又は他の手段により知られていてよい。Hsigは、第１ECDSA署名を生成する際にmをハッシングするために使用されたハッシュ関数である。それは、任意の形式のハッシュ関数であってよい。それがどんな形式であっても、このハッシュ関数の形式（タイプ）は、所定の両者に知られているものであると考えられてよい。Gは固定の公衆に知られたベクトル値である。
ロックスクリプトは、前記のチェックが真であることを条件に「真」の結果を返し、その他の場合に「偽」の結果を返すよう構成される。UTXOの場合には、アンロックスクリプトと一緒にロックを実行した真（つまり、成功）の結果は、トランザクションの有効性の要件である。従って、Tx２の有効性は、rパズルの結果のプロキシとして使用できる。或いは、別の方法では、Tx２の有効性は、rパズルに対する解を提供することを条件とする。つまり、Bobがrパズルに合格しない場合、彼のトランザクションTx２は、ネットワーク１０６に渡り伝播されず、ブロックチェーン１５０に記録もされない（Tx１のアウトプット内に定義されたいかなる支払いも償還されない）。
図７の例は数学的意味において最も単純であるが、これは、必ずしも、任意の所与のノードプロトコル又はスクリプト言語と統合することが最も単純であることを意味しない。支払者（spender）が、<r,s>及び<P>ではなく、アンロックスクリプトの中で<s>及び<P>しか提供しない場合、スクリプトはこれに対応しなければならない。演算I)～ＩＩ）は、標準的なChecksigタイプのオペコードの演算ではない。OP_CHECKSIGオペコードは、署名がDERフォーマットであることを期待しているので、<s>値のみがアンロックスクリプト内で提供された場合、有効な署名をDERフォーマットで生成するために、ロックスクリプト内に幾つかの追加のオペコード（連結するためにOP_CAT等）が存在する必要がある。図８は、数学的に言うと追加ステップを含むが、実際には、両方ともTx２のインプットから取り入れられるr及びsに基づくECDSA署名検証を呼び出すための専用オペコードを既に有するScriptのようなスクリプト言語と統合しているより簡単な代替の例を簡単に記載し示す。
全部の可能な実施形態においてTx２にPを含むことは本質的ではないことにも留意する。実際に、メッセージm及び（r,s）又はこの場合には（r’,s）の知識から、公開鍵の２つの可能な値P及び-P（しかしどちらがどちらかは分からない）を計算することが可能である。２つの検証は、次に、どちらが正しい方かを識別するために使用できる。又は代替として、２つの可能な解のうちのどちらを使用すべきかをシグナリングするための１ビットフラグがTx２に含まれることが可能である。この後者のアプローチは、幾つかのアカウントに基づくプロトコルで現在使用されている。しかしながら、それは、スクリプト言語（例えば、Script）がP及び-Pを（r,s）及びmから計算する演算のためのオペコードを有しない現在のUTXOに基づくプロトコルでは使用されない傾向にある。しかしながら、演算がロックスクリプト内に明示的にコーディングされること、又は導入される可能性を排除すべきではない。別の可能性は、Aliceが既に知っている、或いはPへのアクセスを有するか又はそれをサイドチャネル３０１を介して受信することである。しかしながら、それは、PをTx２にマッピングするために別のルックアップを必要とする。
別の例示的な実装は図８に示される。ここで、rパズルは、Tx２のアンロックスクリプトがr部分の提出されたインスタンスrを明示的に含むことを要求する。Tx１のロックスクリプトは、r部分についてのテストを含み、該テストは、r部分の参照インスタンスr'が提出されたインスタンスrに対して比較されることを含む。この方法では、Tx２内のアンロックスクリプトは、少なくとも、Bobの署名のr部分（r）及びs部分（s）を含まなければならない。それは、Bobがmに署名するために使用した秘密鍵Vに対応する公開鍵Pも含んでよい。Tx１のロックスクリプトは、ノード１０４でスクリプトエンジン４０２により実行されると、r、s及びPをTx２のアンロックスクリプトから取り入れ、以下の演算を実行するように構成される。
Figure 2022533845000032
ここで、r'は、Tx１のロックスクリプトから取り入れられ、s、r、及びmは、Tx２のアンロックスクリプトから取り入れられる。Bobの公開鍵Pも、Tx２のアンロックスクリプトから取り入れられてよく、又は他の手段により知られていてよく、例えば（r,s）及びmから導出され、又は前述のような（r,s）及びmであってよい。
ロックスクリプトは、ステップＩ）及びＩＩ）の両方のチェックが真であることを条件に「真」の結果を返し、その他の場合に「偽」の結果を返すよう構成される。UTXOに基づく場合にも、これは、トランザクションの有効性がrパズル知識証明の結果に依存して決定されることを可能にする。番号I～ＩＩＩは、必ずしも順序を意味しないことに留意する。ＩＩＩ）はＩＩ）の後に実行される必要があるが、チェックＩ）はII）～ＩＩＩ）の前又は後に実行できる。
図８の方法では、ステップＩＩ）及びＩＩＩ）は、単独で、ECDSA検証関数により実行される従来の演算である。大部分のプロトコルでは、それらは、従って、Scriptにおける既存のChecksigオペコード(OP_CHECKSIG)のような専用オペコードにより呼び出される。ステップＩ）は、汎用オペコードを用いてロックスクリプトに別個にコーディングできる（例は後述する）。ステップＩＩ）及びＩＩＩ）がChecksigのような専用オペコードを用いる代わりに、汎用オペコードを用いて明示的に符号化されることも原理的に除外されない。
１つの例示的なトランザクションプロトコルでは、図１２に示すように、トランザクションECDSA署名は、ASN.１(Abstract Syntax Notation One)DER(Distinguished Encoding Rules)符号化フォーマットを使用する。第１バイトフィールドは、ASN.１シーケンス番号を示すフラグ０x３０を含む。次のバイトフィールドは、シーケンスの長さを１６進数で含む。第３バイトフィールドは、ASN.１整数（integer.を示すフラグ０x０２を含む。その後に、ECDSA署名のr値が、次の３２又は３３バイトに含まれる。フィールドは３２バイトであるべきだが、rの第１バイトが０x７fより大きい場合（第１ビットは１である）、０の追加バイトがr値の前に追加され、３３バイトの長さにする。これは、整数の第１ビットを署名として解釈するDERフォーマット符号化の結果として行われる。０の追加バイトは値の始めに追加され、その結果、負の値として解釈されない。同じことが、ECDSA署名のs値に行われる。最終的に、１バイトフィールド、ハッシュタイプ（ht）が、DER符号化に追加され、これはトランザクション内のビットコイン署名のタイプ（SIGHASH_ALL、SIGHASH_NONE、等）に対応する。
Alice（A）が、パズルの解を取得した者が誰でも使用できるrパズルトランザクションを生成したい場合を検討する。これを達成するために、彼女は、以下に一例を示すような新しいトランザクションTx１を生成する。インプット部分は、使用されている前のトランザクションTx０のアンロックスクリプトを含む。簡単のため、それは、Aliceの署名及び公開鍵を用いて使用される標準的なP２PKHであると仮定する。アウトプット部分は、ロックスクリプト（スクリプト公開鍵）、又は言い換えるとrパズルチャレンジを含む。図１２に示すように、署名は、幾つかのプロトコルではDER符号化フォーマットを使用してよい。従って、スクリプトは、符号化署名からrの値を抽出し、次に、それが<r>に等しいかをチェックしなければならない。その後、スクリプトは、署名が公開鍵に基づき有効であることをチェックしなければならない。スクリプトがどのように動作するかの更に詳細な説明は図５に示される。太字のオペコードは、基本的に、署名からrを抽出する方法である。
Figure 2022533845000033
対応するアンロックスクリプトは、以下に示される。ここで、署名sigrはrを使用し、支払者Bob（B）は任意の秘密／公開鍵ペアを用いて署名を計算できる。sigrは(r,s)であることに留意する。
Figure 2022533845000034
図１３は、ステップ毎のスクリプト分析を示す。
一時鍵kは、Aliceにより生成され、Bob（及び任意的に１人以上の他の可能な証明者）に与えられてよい。代替として、kは、Bobにより生成され、Bob（又はkを共有するためにBobが選択した誰か）だけが解くことができるrパズルを設定するためにAliceに与えられてよい。いずれの場合にも、証明者Bobは、送信者Aliceはrパズルの解（k）を知っているので、彼女がトランザクションを彼女自身で使用しないことを信じなければならない。これを防ぐために、証明者Bobは、パズルを生成し、Aliceがｒパズルトランザクションを生成するときに使用するために、Aliceにr値を送信し得る。その後、Bobは、彼がrパズルの解であり鍵の一形態として見られる値kを保持している限り、任意の秘密／公開鍵ペアを用いて後日、アウトプットを償還できる。他方で、幾つかの場合には、Aliceがkを知っているという事実は、有利な特徴になり得る。例えば、これは、秘密鍵パズルを生成するために、それを通じて一般化されたアトミックスワップ（atomic swap）を生成するために使用できる。
図９は、rパズルの別の例を示す。これは、P２PKH（pay to public key hash）と同様に、本願明細書で「P２RPH（pay to r-puzzle hash）」と命名される。追加されるセキュリティ及びプライバシのために、r値は、（ネットワーク１０６のノード１０４を通じて伝播されブロックチェーン１５０上に置かれる）Tx１内に置かれる前に、ハッシングされ得る。P２PKHと同様に、公開鍵自体ではなく、公開鍵のハッシュのみがブロックチェーン上にある場合、rパズルにより同じことが行われる。
ここでも、rパズルは、Tx２のアンロックスクリプトがr部分の提出されたインスタンスrを含むことを要求する。Tx１のロックスクリプトは、ここでも、r部分についてのテストを含むが、今回は、r'のハッシュの形式のr部分の圧縮されたインスタンスの形式である。つまり、h=H(r’)。これは、提出されたインスタンスrに対して比較される。この方法では、Tx２内のアンロックスクリプトは、ここでも、少なくとも、Bobの署名のr部分（r）及びs部分（s）を含まなければならない。それは、Bobがmに署名するために使用した秘密鍵Vに対応する公開鍵Pも含んでよい。Tx１のロックスクリプトは、ノード１０４でスクリプトエンジン４０２により実行されると、r、s及びPをTx２のアンロックスクリプトから取り入れ、以下の演算を実行するように構成される。
Figure 2022533845000035
ここで、hは、Tx１のロックスクリプトから取り入れられ、s、r、及びmは、Tx２のアンロックスクリプトから取り入れられる。ハッシュ値h=Hpuz(r)であり、ここで、Hpuzはrパズルのハッシュ（hash-of-r puzzle）で使用されるハッシュ関数である。それは、任意の形式のハッシュ関数であってよい。それは、Hsigと同じ又は異なる形式のハッシュ関数であってよい。それがどんな形式であっても、Hpuzの形式は、所定の両者に知られているものであると考えられてよい。Bobの公開鍵Pも、Tx２のアンロックスクリプトから取り入れられてよく、又は他の手段により知られていてよく、例えば（r,s）及びmから導出され、又は前述のような（r,s）及びmであってよい。
ロックスクリプトは、ステップＩ）及びＩＩ）の両方のチェックが真であることを条件に「真」の結果を返し、その他の場合に「偽」の結果を返すよう構成される。ＩＩＩ）はＩＩ）の後に実行される必要があるが、チェックＩ）はII）～ＩＩＩ）の前又は後に実行できる。
ここでも、図８の場合のように、ステップＩＩ）及びＩＩＩ）は、単独で、ECDSA検証関数により実行される従来の演算である。大部分のプロトコルでは、それらは、従って、Scriptにおける既存のChecksigオペコード(OP_CHECKSIG)のような専用オペコードにより呼び出される。ステップＩ）は、汎用オペコードを用いてロックスクリプトに別個にコーディングできる。
トランザクションチャレンジTx１内のロックスクリプトの例は以下に示される。
Figure 2022533845000036
送信者及び受信者の両方のパーティの間で一貫している任意のタイプのハッシュ関数が使用され得る。しかしながら、P２PKH標準と調和していながら、私たちは、OP_HASH１６０、SHA-２５６のダブルハッシュ、及びRIPEMD-１６０を使用する。
対応するアンロックスクリプトは、以下に示される（前の章と同じである）。ここで、署名sigrはrを使用し、支払者Bob（B）は任意の秘密／公開鍵ペアを用いて署名を計算できる。
Figure 2022533845000037
従って、図９の例は、rの未変換インスタンスの代わりに、r部分のハッシュをrチャレンジの基礎として使用することを除き、図８と同様である。
これらの場合のいずれでも、Tx１のアンロックスクリプトが「真」の結果について追加基準を課すことに留意する。例えば、例は、ロックタイムまたは追加署名に対する要件であり得る。
上述の技術のいずれかの例示的な使用例は、汎用知識チャレンジとしてである。何らかの解kを有する任意のチャレンジ、又はハッシングされてkになる何らかの解を検討する。Aliceは、パズルに結合されるrパズルを生成する。つまり、彼女は、r=[k・G]xを定義できる。
例として、Aliceは数学の教授である。彼女は、rパズルトランザクションTx１を構成できる。ここで、基礎にあるk値は、学生が解くように促される数学の問題に対する解である。解を考え出すことができた者は誰でも、署名（r,s）を生成するためにそれを使用でき、従って報酬を請求できる。ここで、rはロックスクリプト内の値と一致する。署名は、真正さを提供するだけでなく、解を誰か他の者に開示することなく、解の知識証明としても機能する。従って、rパズルは、何からの解の知識又は情報を、それを公開するリスクを伴わずに一般的に証明するためのセキュアなメカニズムを提供する。それは、アンロックスクリプト内で要求される署名をエレガントに再利用し、任意の公開鍵Pが使用できるので、解を見付けた者が誰でもプライバシと共に報酬を請求できるようにする。
この方式は、トークン又はデジタルチケットの形式として使用されることもできる。例えば、イベント主催者は、デジタルチケットとしてkの異なる値を、出席者に発行できる。出席者がイベントに出席したいとき、彼らは、rパズルの使用を通じてシークレットトークンの知識を証明できる。
別の例示的な使用例として、rパズルは、あるパーティが別のパーティに署名する権利を委任できる署名権限付与方式として使用できる。ロックスクリプトに一致するr値を有する署名が提供された場合にのみアンロックできるrパズルトランザクションTx１を検討する。これは、値k、ここで[k・G]x=r、を知っている人物だけがそのような署名を生成できることを意味する。しかしながら、人物がkの知識を誰か他の者に渡した場合、これは、事実上、彼又は彼女の代わりに署名する権利を他の人物に与える。
例えば、Aliceは配達を受け取りたいとする。彼女は彼女が配達を受け取るためにそこに居ないかもしれないことを心配している。彼女は、Bob及びCharlieの両者にkのコピーを与え、彼らは彼女の代わりに配達を受け取ることができる。Daveが小包を配達している場合、彼女は、Bobに小包を解放するために、期待されるr値を有する署名を得なければならない。
このようなシナリオでは、kは一時秘密鍵として、rは一時公開鍵として、k及びrが特定のアイデンティティにリンクされないことを除き、それぞれV及びPと同様に、動作すると考えることができる。
＜共同値（JOINT-VALUE）rパズル＞
図９のハッシングされたrパズル（P２PKH）への拡張として、（h=Hpuz(r||d)を得るために）ハッシングの前にrと連結される追加の値dを含むことが可能である。その場合、証明者（例えば、Bob）は、rパズルを解くだけでなく、dも知っていなければならない。この例は図１０に示される。
Tx１のロックスクリプトは、ノード１０４でスクリプトエンジン４０２により実行されると、r、s、P及びdをTx２のアンロックスクリプトから取り入れ、以下の演算を実行するように構成される。
Figure 2022533845000038
r||dは、いずれかの順序で（rが最初、又はdが最初）、r及びdの連結を表す。チャレンジトランザクションTx１内のロックスクリプトの例は以下に示される。
Figure 2022533845000039
対応するアンロックスクリプトは、以下に示される（dが含まれることを除き、前の章と同じである）。署名sigrPBはrを使用し、証明者Bob（B）は任意の秘密／公開鍵ペアを用いて署名を計算できる。
Figure 2022533845000040
追加の署名sig'は、セキュリティのために追加された特徴である（後述する任意的なセキュリティ特徴についての章を参照する）。しかし、これは、全ての可能な実施形態で必要とされるものではない。
例示的な使用例は、CLTVにリンクされたｒパズル（CLTV Linked R-Puzzle）であってよい。この場合、データ値dは、CLTV（Check Lock Time Verify）トランザクションアウトプットにリンクされた時間値tであり得る。この背後にある動機は時間tを隠すことであり、この時間tの前には、P２RPHハッシュの中でアウトプットは使用できず、rパズルにリンクする。その場合、証明者（例えば、Bob）は、rパズルを解くだけでなく、tも知っていなければならず、それを使用するためには特定の時間まで待機しなければならない。トランザクション内のロックスクリプトの例は以下に示される。
Figure 2022533845000041
対応するアンロックスクリプトは、以下に示される。ここで、署名sigrPBはrを使用し、支払者Bob（B）は任意の秘密／公開鍵ペアを用いて署名を計算できる。
Figure 2022533845000042
追加の署名sig'は、セキュリティのために追加された特徴である（後述する任意的なセキュリティ特徴についての章を参照する）。しかし、これは、全ての可能な実施形態で必要とされるものではない。
以上は、連結の観点で説明された。しかしながら、これを特定の関数f(r,d)へと一般化することも可能である。例えば、fはr及びdの加算であってよく、例えば<r><d>OP_ADDとして実装できる。
＜複数のr値のステートメント＞
別の可能性は、rの複数の所定の値、例えば、異なるステートメントに関連付けられそれらをアンロックするr１、r２、及びr３を有することである。ステートメントSiをそれぞれのriに割り当てた場合、私たちは、署名の中で対応するriを用いることにより、特定のステートメントに肯定応答できる。例えば、これは、合意した１又は複数の代替の可能な項目を承諾することを示すよう、署名するために使用されてよい。
どのr値がアンロックスクリプト内で使用されるかをチェックするロックスクリプトを構成することが可能であり、rの値に解釈を割り当てることができる。上述の思想を実装するロックスクリプトは以下のようであってよい。
Figure 2022533845000043
全ての<statement i>は、対応するrパズルを解いた後にのみアクセスできる異なるロック条件により置き換えられるべきである。アンロックスクリプトが以下に示され、ここで、riは、設定されたステートメントにアクセスするために必要な異なるr値である。
Figure 2022533845000044
追加の署名sig'は、ここでも、セキュリティのための、任意的に追加された特徴である（以下を参照する）。しかし、これは、全ての可能な実施形態で必要とされるものではない。
＜任意的なセキュリティ特徴＃１＞
kに基づく署名が公開された場合、kの値を知っている者は誰でも、署名を生成するために使用されたシークレット鍵Vの値を導出できる。これは、以下の署名式の中のVについて解くことにより行うことができる。
Figure 2022533845000045
多くの場合にトランザクションの受信者はkを知っている者だけなので、これは有意なリスクを引き起こさない。他の場合には、支払者は、rパズルの解に署名するために使用された秘密鍵Vを決して再利用しないよう注意しなければならない。良好なセキュリティの慣習は、ユーザが公開／秘密鍵ペア（P,V）を決して再利用しないことが望ましく、むしろ、新しい金銭を受け取るとき、常に新鮮な新しい公開／秘密鍵ペアを使用する。
原則的に、公開－秘密鍵ペア（P,V）は「永久的」である。つまり、それは、何回も使用できる。ランダム一時鍵kの使用はこれを保証するべきである。しかしながら、乱数生成器の実装が不十分である場合には、問題が起こる。
同じ一時鍵k及び同じ秘密鍵を用いて２つの異なるメッセージに署名した場合、２つの署名から秘密鍵Vを導出できる。つまり、所与の（r,s）及びｋが与えられると、Vを算出できる。ここで、r=[k・G]xであり、Vは署名で使用された公開鍵Pに対する秘密鍵である。乱数生成器が署名処理中に障害になった場合、最後に同じ乱数を生成することがあり、従って、秘密鍵が公衆に漏洩する。この問題を解決するために、人々は、乱数生成器を固定する代わりに、公開鍵を再利用することを避け始めた。
本例では、Aliceがkを知っているが、彼女が、Bobの公開鍵に対する秘密鍵であるVを知らない場合。AliceがBobにkを渡すとき。Bobは、彼の秘密鍵を用いて（r,s）を提供することにより、rパズルを解くことができる。Aliceは署名を見ると、彼女はkを知っているので、彼女はVを導出できる。これは、Bobにとって望ましくない場合がある。従って、Bobは、望ましくは（P,V）の再利用を回避すべきである。
しかしながら、これに伴う問題は、Bobの公開鍵PがBobを識別する持続的な手段として使用できないことである。
これを解決するために、本願明細書に開示される実施形態によると、Bobは、対応する公開鍵P２を有する別個の秘密鍵V２を用いて、Tx２にBobの追加署名sig２を含めてよい。彼は、追加署名と一緒にP２も含める。従って、２種類の公開－秘密鍵ペアがある。第１種類は、１回限りの使用のためにオンザフライで生成されるものである。他の種類は、何らかの追加プロトコル、例えばHDウォレットに従い生成されるものである。Bobは、rパズル署名のために第１種類の鍵ペアを使用し、第２署名のために第２種類を使用できる。
Aliceは、公開鍵とアイデンティティとの間のマッピングに基づき、Bobのアイデンティティ、例えばBobの正式名、ユーザ名、又はネットワークアドレスを検索するために、第２公開鍵を使用できる。マッピングは、例えば、公開鍵をアイデンティティにマッピングする公開データベースの中で利用可能にされ得る。或いは、マッピングは、単にAliceとBobとの間で予め合意され得る（例えば、Aliceのコンピュータ機器１０２aにプライベートに格納される）。
ここで再び、署名権限の使用例を検討する。例えば、Aliceは、配達を受け取りたいが、彼女自身で配達を受け付けることが可能ではないかも知れない。彼女は、Bob及びCharlieの両者にkのコピーを与え、彼らは彼女の代わりに配達を受け取ることができる。Daveは、小包を配達している。彼は、期待されるr値を有する署名を得なければならない。ここで、彼の記録又は規則対応では、Daveは受取人のアイデンティティを検証する必要もあることを考える。
Bobは配達を受け付けるためにそこに居るとする。Bobが彼の公開鍵及び署名をkに基づき生成した場合、Alice及びCharlieの両者は、Bobの秘密鍵Vを算出できる。これは、公開鍵が１回限りの使用のために指定された場合には、問題ではない。しかしながら、Bobがこの公開鍵を将来に彼のアイデンティティを証明するために必要とする場合には、理想的ではない。
この問題を解決するために、実施形態は、Tx２に、Bobを識別するために使用できるBobからのrパズルと独立した１つ以上の署名を含めてよい。例えば、追加署名及び対応する公開鍵P２を、Daveが受け付けるのと同じトランザクション内のOP_RETURNアウトプット（未使用アウトプット）に追加できる。代替案は、rパズルトランザクションのロックスクリプト内に追加OP_CHECKSIGを含めることである。トランザクション及び追加署名のために使用された公開鍵を閲覧することにより、Aliceは、誰が彼女の代わりに署名したかを教えることができる。
幾つかの他の場合には、値kが使用する前に漏洩する可能性があるという心配があり得る。これを解決するために、AliceはrパズルトランザクションにP２PKHを追加して、それをよりセキュアにすることができる。Aliceは彼女の署名権限をBobに委任したいとする。AliceがBobから１回限り公開鍵P２を取得し、r値を指定するだけでなく追加公開鍵P２も指定するrパズルトランザクションを生成する。
Alice自身も署名できるようにするために、任意的に、Aliceは１-out-of-２ MultiSigを生成できる。ロックスクリプトの一例は以下に与えられる。
Figure 2022533845000046
Aliceはｒパズルの解、つまり署名権をBobに渡すべきときを選択できるので、rパズルが一層の柔軟性を提供することに留意する。彼女は、トランザクションがマイニングされた後でも、渡すか渡さないかを決定できる。
kが漏洩した場合、人々は、漏洩したkにより署名に署名するために使用される秘密鍵を発見できる。しかしながら、別の秘密鍵V２、つまりBobを識別するために使用できる公開鍵にリンクされる秘密鍵がある。アウトプットを損傷させるために、攻撃者は、２つの独立したシークレットを取得しなければならない。これは、それらのうちの１つのみを損傷させることより遙かに可能性が低い。
上述の例では、Tx２のロックスクリプトは、従来のP２PKHを用いて、Bobの追加公開鍵P２にロックされる（rパズルで使用されたものではなく、追加署名によりアンロックされる）。rパズル技術は、ユーザにとって追加の選択肢を可能にする。幾つかの適用では、証明者がアイデンティティに関係なくチャレンジを満たすことができるように、rパズルを使用することが望ましい場合がある。他方で、幾つかの他の適用では、ハッシュパズルとP２PKHの組合せが、依然として望ましい場合があり、rパズルはそれに関連して任意的に使用できる。これは、間もなく更に詳細に議論される。
しかしながら、P２に対応する追加署名がアイデンティティ検索及び／又はセキュリティのために必要であるが、P２PKHにおけるようにTx１のロックスクリプトが特定の証明者のアイデンティティに予め結び付けられることがない場合、上述のロックスクリプトが相応して採用できる。つまり、対応する公開鍵P２にOP_EQUALVERIFYではなく、追加署名にChecksigを単に含めることができる。
＜任意的なセキュリティ特徴＃２＞
上述の方法における別の可能なセキュリティ脆弱性は、署名の鍛造性（forgeability）である。これは、（ハッシュパズルと同様に）資金を請求しようとするマイナーにより利用されることがある。トランザクションを（支払者から）受信したマイナーは、支払者が元のトランザクションで使用したものと同じ署名を使用しながら、トランザクションを変更して、自分自身に資金を送ることができる。これは以下のように行われる。
P=V・Gを、mにより示される元のトランザクションに署名して、以下のように署名（r,s）を得るために使用された公開／秘密鍵ペアとする。
Figure 2022533845000047
そのトランザクションを使用するために、支払者は、以下のアンロックスクリプトを使用する。
Figure 2022533845000048
このトランザクションを受信したマイナーは、トランザクションを、以下の新しいアンロックスクリプトを使用して自分自身に資金を送信する、m'により示される新しいものに変更できる。
Figure 2022533845000049
マイナーは（Vを知らないので）V'を知る必要がないことに留意する。検証処理は、次に、以下の計算を用いて実行される。
Figure 2022533845000050
署名は、(R')x=rの場合及びその場合にのみ有効であり、その他の場合に無効である。
新しいトランザクションm’及び新しいアンロックスクリプトにより、検証処理は以下の通りである。
Figure 2022533845000051
この潜在的な脆弱性を解決するために、実施形態では、マイナーがシークレット鍵Vを知らない限り提供することができない別のメッセージmsighashに対するアンロックスクリプト内に別の追加署名sig'を含めてよい。その場合、アンロックスクリプトは、以下の通りであってよい。
Figure 2022533845000052
sig'は、同じメッセ維持m又は異なるメッセージmsighashに対する署名であってよい。異なるメッセージに署名するために、元のものと異なるsighashフラグを使用することができる（例えば、デフォルトフラグであるSIGHASH_ALLの代わりにSIGHASH_NONE）。しかしながら、両方の署名が同じメッセージ上に存在できるので、これは任意である。また、sig'は異なる値のrを使用しなければならない。その結果、それは秘密鍵を漏洩しない（何故なら、秘密鍵は、同じ一時鍵を使用する２つの署名から導出できるからである）。最後に、トランザクションは、以下に示すように末尾に別のOP_CHECKSIGを含む必要がある。
Figure 2022533845000053
これは、同じ公開鍵Pをrパズルとして使用しなければならない。その結果、公開鍵Pに対する秘密鍵Vを知っている者だけが別の署名を生成でき、上述の攻撃は不可能である。
攻撃者は、公開鍵を、攻撃者が秘密鍵の知識を有しない別の公開鍵で置き換えようとする。この攻撃を防ぐために、チャレンジは、秘密鍵の知識についても尋ねる。この場合、１つの署名は十分ではない。従って、２つの署名が要求される。両方の署名は、同じ秘密鍵の知識の証明として考えられる。チャレンジはそれらが異なる一時鍵を有することを要求するので、これはセキュアである。
＜知識チャレンジ＞
前述のように、知識チャレンジのシナリオでは、複数の被チャレンジャーが、基礎にあるチャレンジCに対する解（チャレンジ解）を独立に導出するよう競争する。
表記法により、チャレンジャーに知られているチャレンジ解はSC'と表され、一方で、被チャレンジャーにより導出されたチャレンジ解の独立インスタンスはSCと表される。被チャレンジャーがチャレンジCを正しく解決したとすると、SC’=SCである。
基礎にあるチャレンジCは「競争チャレンジ（competition challenge）」と呼ばれてよく、チャレンジ解の主張された知識を検証するために使用される対応する「署名チャレンジ（signature challenge）」と区別される。
SCを導出し及びそれを有効な証明トランザクションにより証明する最初の被チャレンジャーは、知識チャレンジの「勝者」であると考えられる。被チャレンジャーは、SCの知識を、解SCの知識を符号化する、つまりSCを含むか又はそれから導出される何らかの形式のシークレット被チャレンジャー鍵を用いて被チャレンジャーにより生成されたトランザクション署名により証明する。被チャレンジャーの解SCが正しい場合、署名は、チャレンジャーによりチャレンジトランザクション内に設定された「署名チャレンジ」を満たす。
図１４は、rパズルの枠組みの中で知識チャレンジの第１の例を概略的に示す。
本例では、署名チャレンジは、rパズルトランザクション１４０２内のrパズル１４０３である。従って、チャレンジ解SCの知識は、ECDSAを用いて、証明トランザクション１４０４に署名するために使用される一時鍵kに符号化される。
図１５は、rパズルに基づかない知識競争の第２の例を概略的に示す。むしろ、本例では、チャレンジ解SCの知識は、代わりに、証明トランザクション１５０４に署名するために使用される秘密鍵Ｖに符号化される。従って、チャレンジトランザクション１５０２は、公開鍵に基づく署名チャレンジ１５０３を含む。従って、証明トランザクション１５０２及び署名チャレンジ１５０３は、それぞれPパズルトランザクション１５０２及びPパズル１５０３と呼ばれてよい。
それらが共通の特徴を有するならば、図１４及び１５は同様の参照符号を使用する。それらの共通の特徴がここで説明され、説明は図１４及び１５の両方に等しく適用される。
チャレンジャーは、参照符号１４０６で示される。本例では、チャレンジャー１４０６は競争チャレンジC及びチャレンジ解SC'の両方の知識を有すると仮定する。被チャレンジャーが、どのようにその知識を取得するかは重要ではない。彼は、チャレンジCを彼自身で生成するか又はそれをどこかから取得してよい。同様に、彼は、解SC'を彼自身で導出するか又はそれをどこかから取得してよい。チャレンジ解SC'は、それぞれの図で右向きのCからSC'への点線矢印により示されるように、競争チャレンジCから実行可能な方法で導出できる。
競争チャレンジCは、集合的に参照符号１４０８で示される競争する被チャレンジャーの各々に通信される。純粋に例として、図１４及び１５は、参照符号１４０８a、１４０８b、及び１４０８cによりそれぞれ個別に第１、第２、及び第３競争被チャレンジャーを示す。勿論、より少数の又はより多数の競争被チャレンジャー１４０８が存在してよい。競争被チャレンジャー１４０８は、競争チャレンジCを独立に解決し、チャレンジ解SC（の独立インスタンス）を導出するよう、互いに競争する。
競争チャレンジCは、「オンチェーンで」、つまり、ブロックチェーンネットワーク１０１へ提出される１つ以上のトランザクションの中で、被チャレンジャー１４０８に通信されてよい。該トランザクションは、チャレンジトランザクション（１４０２又は１５０２）自体であってよく又はそれを含んでよい。或いは、競争チャレンジCは、（図３のサイドチャネル３０１のような）１つ以上のサイドチャネルを介して「オフチェーンで」通信されてよい。
第１被チャレンジャー１４０８aは、図１４及び１５の中で勝者、つまり、解SCを導出し、その解の知識を証明する最初の者として示される。その知識は、その独立に導出した解SCのデータをシークレット被チャレンジャー鍵（図１４のk、図１５のV）として使用して、それによりトランザクション署名を生成する、適用可能な証明トランザクション（図１４の１４０４、図１５の１５０４）のメッセージ（部分）mに署名する第１被チャレンジャー１４０８aにより証明される。
トランザクション署名は、図１４及び１５の両方で、(r,s)と示される。しかしながら、上述のように、特定のrパズル実装では、トランザクション１４０４はs部分sのみを含めば十分であり、rの任意の存在は点線を用いて示される。以下の説明はトランザクション署名(r,s)を参照するが、トランザクション署名はs部分のみで構成されてよいことが理科され、関連する説明の全部が依然として適用される。
図１４及び図１５の両方で、チャレンジャー１４０６は、自身に分かっているチャレンジ解SC'のデータを、そこから何らかの形式の「公開署名データ」を生成するために、「シークレットチャレンジャー鍵」（図１４のk'、図１５のV'）として使用する。それは、つまり、受信したトランザクション署名が一致するシークレット被チャレンジャー鍵（図１４のk、図１５のV）を用いて生成されたかどうかを検証するために使用されてよいデータである。その公開署名検証データは、チャレンジトランザクション（１４０２又は１５０２）の署名チャレンジ（１４０３又は１５０３）（の部分）を形成する。
証明トランザクション（１４０４又は１５０４）は、証明トランザクション（１４０４又は１５０４）を受信するブロックチェーンノードに、トランザクション署名(r,s)が署名チャレンジ（１４０３又は１５０３）を満たすかどうかを決定させるために、チャレンジトランザクション（１４０２又は１５０２）の署名チャレンジ（１４０３又は１５０３）を示す。
例えば、UTXOモデルでは、トランザクション署名(r,s)は、証明トランザクション（適用可能な場合、１４０４又は１５０４）の少なくとも１つのインプットのアンロックスクリプトに含まれ、それは、チャレンジトランザクション（適用可能な場合、１４２０又は１５０２）の少なくとも１つの使用可能アウトプットを示す。逆に言えば、署名チャレンジ（１４０３又は１５０３）は、その使用可能なアウトプットのロックスクリプトの部分を形成する。トランザクション署名(r,s)は、証明トランザクション（１４０４又は１５０４）の検証の部分としてノードにより検証される。ノードは、署名検証自体の部分として又は別のチェックとして、トランザクション署名(r,s)が署名チャレンジを満たすこともチェックする。従って、被チャレンジャー１４０８bが独立に導出した解SCにより署名チャレンジ（１４０３又は１５０３）を満たすトランザクション署名(r,s)を提供できる勝者被チャレンジャー１４０８bは、チャレンジトランザクション（１４０２又は１５０２）のアウトプットを償還（redeem、使用（spend））できる。
用語に関して、用語「鍵のデータ」及び「解のデータ」は、適用可能な場合、鍵又は解自体の一部又は全部を表してよいが、そのハッシュのような鍵又は解の変形（つまり、ハッシュのような鍵又は解に変換を適用することにより、それらから導出されたデータ）も表してよい。変換は、元の鍵又は解がそれから復元できないような、一方向変換であってよいことに留意する。
＜知識チャレンジ－rパズル＞
図１４のrパズルの例を更に拡張すると、この場合には、チャレンジャー１４０６は、チャレンジ解SC'のデータを、一時鍵k'として使用する。これは、一方で、rパズル１４０３の基礎を形成するチャレンジャーr部分r'を導出するために使用される。言い換えると、チャレンジャー一時鍵k'は、シークレットチャレンジャー鍵の役割を想定し、公開署名検証データは、チャレンジャーr部分r’又はその変換を含む。そのような公開署名検証データは、（それが、rパズルトランザクション１４０２に包含されることにより、ブロックチェーン上に存在し又は発行されることに基づき）本願明細書で「発行r部分データ（published r-part data）」と呼ばれてよい。発行r部分データは、rパズルトランザクション１４０２内のパズル１４０３（の部分）を形成し、ECDSA署名（又は、少なくともそのs部分、以上を参照）が一致する一時鍵kを用いて生成されているかどうかを検証するために使用されてよい。そうであるならば、署名（又はs部分）はrチャレンジ１４０３を満たすと言える。
勝者被チャレンジャー１４０８aは、彼のチャレンジ解SCのデータを、対応する一時鍵kとして使用して、署名の少なくともs部分sを生成する。これは、証明トランザクション１４０２のメッセージmに署名するために使用される。これは、秘密鍵Vを要求するが、上述のrパズルの枠組みにより、任意の秘密鍵Vが使用されてよい。つまり、対応する公開鍵がrパズルトランザクション１４０２内で又は（その他の場合に）ブロックチェーン内のどこかで指定されないからである。
例として、数学の教授は、rパズルトランザクション１４０４を構成できる。ここで、基礎にあるk'値は、学生が解くように促される数学の問題（本例では、競争チャレンジ）に対する解である。解を考え出すことができた者は誰でも、署名（r,s）を生成するためにそれを使用でき、従って報酬を請求できる。ここで、rはロックスクリプト内の値と一致する。署名は、真正さを提供するだけでなく、解を誰か他の者に開示することなく、解の知識証明としても機能する。rパズルは、何からの解の知識又は情報を、それを公開するリスクを伴わずに一般的に証明するためのセキュアなメカニズムを提供する。それは、アンロックスクリプト内で要求される署名をエレガントに再利用し、公開鍵を自由に選択できるので、解を見付けた者が誰でもプライバシと共に報酬を請求できるようにする。
＜知識チャレンジ－Ｐパズル＞
図１５のPパズルの例を更に拡張すると、この場合には、チャレンジャー１４０６は、代わりにチャレンジ解SC'のデータを、一時鍵Ｖ'として使用する。これは、一方で、Pパズル１５０３の基礎を形成するチャレンジャー公開鍵Ｐ'を導出するために使用される。言い換えると、チャレンジャーの秘密鍵Ｖ'は、シークレットチャレンジャー鍵の役割を想定し、公開署名検証データは、チャレンジャー公開鍵Ｐ’又はその変換を含む。そのような公開署名検証データは、本願明細書で「発行公開鍵データ」と呼ばれてよい。発行公開鍵データは、Pパズルトランザクション１５０２内のPパズル１５０３（の部分）を形成し、トランザクションを署名が一致する秘密鍵Ｖを用いて生成されているかどうかを検証するために使用されてよい。そうであるならば、トランザクション署名はPチャレンジ１５０３を満たすと言える。
図１５の例はECDSAにも基づくが、これは要件ではないことに留意する。公開－秘密鍵ペアに基づく任意のデジタル署名方式が、この状況で適用されてよい（例えばDSA）。
勝者被チャレンジャー１４０８aは、彼のチャレンジ解SCのデータを、対応する秘密鍵Ｖとして使用して、トランザクション署名(r,s)を生成する。これは、証明トランザクション１５０２のメッセージmに署名するために使用される。ECDSAの文脈では、任意の有効な(k,r)ペアがこの目的のために使用されてよい。
rパズル解と対照的に、図１５の解は、特定に秘密鍵、つまりVの使用を必要としない。しかしながら、被チャレンジャー１４０８のうちのいずれかがVを導出する能力を有するので、これは、本発明の知識証明の文脈で許容できる。
秘密鍵Vは、上述のように（被チャレンジャーが）導出した公開鍵Pに対応する。これは、また、被チャレンジャー１４０８aがチャレンジCを正しく解決したとすると、つまり被チャレンジャーの解SCがチャレンジャーの解SCに一致するとすると、チャレンジャー公開鍵P'に一致する。
上述のように、公開鍵Pをトランザクション署名(r,s)自体から（場合によっては、フラグと関連して）導出することが可能であってよい。従って、別個の符号化文字列として証明トランザクション１４０４にPを包含することは、任意であり、これは図１５に点線を用いて示される。いずれの方法も、Pは証明トランザクション１５０４により識別される。
＜代替の実装－チャレンジャーが解を知らない＞
以上では、チャレンジャー１４０６がチャレンジ解SCを知っていると仮定した。しかしながら、知識チャレンジは、チャレンジャー１４０６が解を知らなくても、実施できる。
図１６を参照して、この例がここで説明される。本例では、チャレンジトランザクション１６０２は、本願明細書で「ハッシュ衝突バウンティ（bounty）」トランザクションと呼ばれる形式を取る。この場合、チャレンジャー１６０２はトランザクション１６０２内でハッシュ関数Hを定義し、被チャレンジャー１４０８は、ハッシュ関数Hに対して「衝突攻撃」を決定するよう、つまり、同じ値、つまりH(d１)=H(d２)を有する２つの値（プリイメージ）d１,d２を見付けるよう競争する。そうした最初の被チャレンジャー１４０８aは、プリイメージd１,d２を開示することなく、衝突するプリイメージd１,d２の彼の知識のゼロ知識証明を提供するプリイメージ証明トランザクション１６０４を構成する。
以下では、ゼロ知識証明は、（上述の図１４と同様に）ECDSA署名のr部分に基づき構成される。しかしながら、代替の実装sでは、ゼロ知識証明は、代わりに、（図１５と同様に）デジタル署名に関連付けられた公開鍵Pに基づき構成されてよい。その場合、以下の説明は、k及びRの代わりにそれぞれV及びPが適用される。
＜ハッシュ衝突バウンティ＞
ハッシュ関数バウンティは、ハッシュ関数（以下の例ではSHA１）に対する衝突を発見できた者なら誰によっても償還（使用）可能な、表１に示す種類のトランザクションアウトプットを構成することにより、ブロックチェーン上で実施され得る。
［表１］ハッシュ衝突バウンティトランザクション
Figure 2022533845000054
バウンティ（bounty）は、対応するアンロックスクリプトを有する証明トランザクションにより、「請求」できる（つまり、ハッシュバウンティトランザクションのアウトプットが使用できる）。
Figure 2022533845000055
バウンティは、同じ値にへとハッシングされる２つの異なるプリイメージを発見した者には誰にでも報酬を与える。
バウンティに伴う問題は、報酬を請求しようとする者が解を開示しなければならないことである。従って、証明トランザクションを見た者は誰でも、答えをハイジャックでき、彼ら自身のためにバウンティを請求するために彼ら自身の証明トランザクションを生成できる。更に、悪意ある攻撃者は、セキュリティリスクをもたらし得る攻撃を無制限に複製できる。
この問題は、ECDSA署名のr部分に基づきゼロ知識証明を構成する、プリイメージバウンティのためのある形式のrパズルトランザクションを用いて解決される。
ハッシュ衝突バウンティトランザクションは、以下のトリプレットを導出できた者には誰にでも実質的に報酬を与える：
Figure 2022533845000056
ここで、Hはバウンティにおけるハッシュ関数である。
バウンティトランザクションを構成するパーティは、どんな値(x１,x２,h)が取り入れられるかの知識を有しないので、これらはバウンティトランザクション内で指定できない。
解は、ゼロ知識証明ハッシュ回路を使用し、参照により全内容がここに組み込まれる国際出願番号第PCT/IB２０１９/０５２１８４号［１］に説明された話を適用する。
例示的な証明検証アルゴリズムVの更なる詳細は以下に説明される。
図１６は、バウンティトランザクション１６０２（本例ではチャレンジトランザクション）及び対応する証明トランザクション１６０４を示す。バウンティトランザクション１６０２は、後述するように、ハッシュ衝突攻撃が成功したことの証明に報酬を与える。
以下の例では、ハッシュ関数は、ハッシュ関数であるSHA２５６であると定義される。これは、バウンティトランザクション１６０２のロックスクリプト内で定義される。
［１］の方法を適用することにより、ゼロ知識証明が以下のステートメントに基づき構成される。
「hのプリイメージは、ECDSA公開鍵Rに対するECDSA秘密鍵と同じである。」
証明は、証明トランザクションに含まれるゼロ知識証明コンポーネントπとして埋め込まれる。これは、ECDSA署名のr部分及びハッシュ値h（これも証明トランザクションに含まれる）に関して上述のステートメントを証明する。
証明検証アルゴリズムVは、３つのインプット(h,R,π)を取り入れ、πが(h,R)に対して有効な証明である場合に１（真）を出力し、その他の場合に偽である。Vが１を出力するとき、それは、証明者が、H(x)=h及びd・G=Rのような、シークレット値dを知っていることを意味する。証明トランザクションアルゴリズムVは、[ZK_VERIFY]のような擬似コードで示される。このアルゴリズムは、R及びπに関して証明トランザクションのゼロ知識署名コンポーネントπにより満たされなければならない１つ以上の証明要件を符号化する。
EDCSAに関連する用語を適用すると、dは一時鍵の役割を満たすことが分かる（つまり、上述の表記で、d=k）。
SHA２５６衝突(d１,d２,h)が存在すると仮定する。ここで、３つの全部の値は未知であり、以下であるとする：
Figure 2022533845000057
証明者は、２つの証明(π１,π２)を提供しなければならない。ここで、π１は(h,R１)に対する証明であり、π２は(h,R２)に対する証明である。両方の証明は、同じハッシュ値hに対するものであり、hは、本発明の文脈では、事前に分からず、バウンティトランザクション内で又は（その他の場合に）ブロックチェーン内のいずれの場所でも指定されない。
バウンティトランザクション１６０２は、以下のような擬似コードで表現され得るロックスクリプトにより構成されるSHA２５６衝突バウンティのRパズルトランザクションである。
Figure 2022533845000058
ここで、[EXTRACT_r]は、ECDSA署名(r,s)からrを抽出する関数を表す。
本発明の例では、ハッシュ関数Hは、チャレンジトランザクション１６０２のロックスクリプト内で、SHA２５６として、証明検証アルゴリズムV([ZK_VERIFY])の部分として、定義される。
証明トランザクション１６０４内のアンロックスクリプトは：
Figure 2022533845000059
バウンティトランザクション１６０２内のロックスクリプトが証明トランザクション１６０４内のアンロックスクリプトに適用されるとき、r１≠r２のチェックが実行されることが分かる。そうである場合を仮定すると、検証アルゴリズムの第１インスタンスは、r２を抽出し、r２からR２を導出し、次に(h,R２)に対して証明π２を検証する。証明が有効である場合、r１が抽出され、r１からR１が導出され、(h,R１)に対してπ１が検証される。
特定のrl値は、２つの可能な楕円曲線点に対応し、Rl +及びRl -と示される。この場合、２つの点Rl +及びRl -のうちのどちらが意図されるかを示すために、rlに関連付けられてフラグが含まれてよい。代替として、フラグは省略されてよく、証明アルゴリズムはRl +及びRl -の両方に適用されてよく、その場合には、証明はRl +及びRl -の一方に関して正しければ十分である。２つのr部分r１,r２により、４個のユニークなRペアが構成されてよい。つまり、
Figure 2022533845000060
これらのうちの１つが正しければ、つまり衝突するプリイメージに対応することが証明されれば、十分である。
代替として、楕円曲線上の点R１及びR２は、証明トランザクション１６０４に明示的に含まれてよい。その場合、関連署名(ri,si)の「r部分」は、その点のy座標と一緒に証明πiをチェックするために使用される、点Riのx座標である。
証明も有効である場合、全部の署名が検証される。簡単のために、セキュリティ署名を検証するステップは、ロックスクリプトから省略されていることに留意する。実際には、それらは、当業者に明らかな方法でロックスクリプトに含まれる。これらのステップは、関連付けられた（上述のようなアンロックスクリプトに含まれる又はその他の場合にはそれから導出可能な）それぞれの公開鍵P１,P２、及びm１,m２と示されるトランザクションのそれぞれの署名された部分に基づき、署名(r１,s１),(r２,s２)のそれれぞれを検証する。通常、署名された部分は、同じ（つまり、m１=m２）又は異なって（m１≠m２）よい。同様に、公開鍵P１及びP２は、同じ(P１=P２)又は異なって(P１≠P２)よい。しかしながら、P１=P２及びm１≠m２のとき（以下を参照）、特定の利益が得られる。
証明者のアイデンティティに対して制約がない、つまり、証明トランザクション１６０４の公開鍵P１及びP２は、バウンティトランザクション１６０２内で又は（その他の場合に）ブロックチェーン内の他の場所で指定されない。つまり、バウンティは、異なるr部分を有する有効な署名ペア、及びそれらの署名のそれぞれのr部分について正しいゼロ知識署名コンポーネント、を提供する任意のパーティにより、誰の１又は複数の公開鍵がそれらの署名に関連付けられているかに関係なく（つまり、それらを検証するために使用された１又は複数の秘密鍵P１,P２に関係なく）、請求され得る。
＜証明検証アルゴリズムV＞
表記πは、以下の説明で、説明される種類のゼロ知識証明コンポーネントを示すために使用される。πに関連する全部の説明は、π１及びπ２に等しく適用される。同様に、表記kは、一時鍵におけるような本文脈ではrパズルであるシークレット値を表すために使用され、kに関する全部の説明は上述のk１及びk２に等しく適用される。同様に、トランザクション署名は、(r,s)と呼ばれそれにより示され、全部の関連する説明は、(r１,s１)及び(r２,s２)に等しく適用される。Rに関連する全部の説明は、R１及びR２に等しく適用される。
提供されなければならない１つの態様は、証明者が、ハッシュ関数Hに関するハッシュ値hのプリイメージである値kを知っているものである。これは、ゼロ知識において証明される。ゼロ知識では、ハッシュ関数H及びハッシュ値hは知られているが（後者は、ハッシュ衝突バウンティの場合に証明トランザクション１６０４内で提供される）、k自体（つまりプリイメージ）は秘密のままである。従来使用されている用語によると、kは、この文脈では「目撃者」（witness）（w）と呼ばれてよい。ステートメント「k（目撃者w）は、Hに関するhのプリイメージである」は、目撃者wを開示することなく証明できるならば、ゼロ知識において証明されると言える。本発明の文脈では、これは、ゼロ知識において証明されなければならない２つの態様のうちの１つ目である。再びゼロ知識において証明されなければならない第２の態様は、kが、ECDSA署名 (r,s)を生成するために使用された一時鍵でもあることである。
種々のハッシュ関数H（SHA２５６を含む）に関して、ゼロ知識における第１の態様を証明するために適用可能な多数の既存のメカニズムがある。幾つかのそのようなメカニズムは、「演算回路」を利用する。
例えば、ゼロ知識「zkSNARKs（succinct non-interactive arguments of knowledge）」は、ゼロ知識において、演算回路として表現できる任意の計算の有効性を証明する方法を提供する。zkSNARKsの２つの特性は、それらが非対話型であり（証明者が検証者へ１回の動作で証明を送信する）、簡易である（証明が軽量であり検証することが容易である）ことである。演算回路は、「ゲート」及びゲートを接続する「ワイヤ」で構成される論理回路である。問題となるハッシュ関数Hは、演算回路として実装される。ハッシュ関数のそのような演算回路実装は、従来知られている。種々のライブラリがSNKARKsを実装するために存在し、当業者によく知られている。
更なる例によると、「Zcash」は、zk-SNARKsをハッシュ関数に適用する知られているメカニズムであり、hを開示することなく、所与のハッシュ値hのプリイメージの知識を提供することを目的とする。これは、問題のハッシュ関数Hの演算回路実装に基づく。例えば、SHA２５６の知られている実装は、２７９０４個の演算ゲートを使用し、Zcashの環境で適用されている。
第２の態様、つまり、プリイメージ及び一時鍵の等価性は、ハッシュ関数H及び楕円曲線スカラー乗算演算「・」（以下で等価的に×と表される）の両方を演算回路として実装し、及びそれに（後述するSigmaプロトコルのような）ゼロ知識証明プロトコルを適用することにより、本枠組みの中で証明できる。「・」の演算回路実装が与えられると、本願明細書で提示される教示の観点から、当業者には、これがどのようにそのような証明を構成するために使用され得るかが明らかである。
しかしながら、楕円曲線スカラー乗算の演算回路実装の必要を回避するために、以上で参照された国際出願番号第PCT/IB２０１９/０５２１８４号［１］に説明されたアプローチが代わりに適用されてよい。これは、hのプリイメージの知識を証明すること、及び該プリイメージが、署名を生成するために使用された一時鍵に対応することを証明することに加えて（楕円曲線スカラー乗算の演算回路実装を要求することなく）、両方の必要な態様を効率的に提供するために適用可能な方法を提供する。
本発明に関連する方法の態様、及びその方法の背景は、以下に説明される。
＜Σ－Pプロトコル＞
Σ（シグマ）プロトコルは、ある種の対話型ゼロ知識署名システムであり、証明者と検証者との間の多数の移動（通信）を含む。通常、Σプロトコルは、３回の移動を含む。つまり、証明者が初期の委託を検証者へ送信し（a）、次に検証者がランダムチャレンジにより応答し（ξ）、最後に、証明者が最終応答又は「開放（opening）」により応答する（z）。検証者は、次に、トランスクリプト(a,ξ,z)に基づき、ステートメントを受け入れ又は拒否する。
Σプロトコルは、証明にのみ知られている目撃者（w）又はそれに関するステートメントの知識を証明するために使用できる。プロトコルは、目撃者に関連するステートメントが真であるという事実を除き、目撃者に関する情報を検証者に開示しない場合、ゼロ知識である。更なる詳細については、参照により全体がここに組み込まれるBootle, Jonathan, et al. "Efficient zero-knowledge proof systems.」 Foundations of Security Analysis and Design VIII. Springer, Cham, ２０１５. １-３１, [Bootle２０１５]を参照する。
＜Pedersenコミットメント＞
コミットメント方式は、多くの暗号プトロコルの中心部分であり、回路の充足可能性のための対話型ゼロ知識プロトコルのコンポーネントである。コミットメントは、証明者が、シークレット値を予めコミットすること、及び、シークレット値を後に検証可能に開示する（開放する）ことを可能にする。コミットメント方式は２つの主な特性を有する：（１）それは隠れている：つまり、コミットメントは、値を秘密に保持する。（２）それは拘束力がある：つまり、コミットメントは、始めにコミットされた値に対してのみ開放できる。
本発明の文脈で利用されて得る方式の例は、Pedersenコミットメント[Bootle ２０１５]である。この方式は、２つの楕円曲線生成点：
Figure 2022533845000061
 に関与する。コミッター（committer、コミット側）は、
Figure 2022533845000062
 の中のセキュアな乱数ρを生成し、次に（楕円曲線加算／乗算により）シークレット値σに対するコミットメントを計算する（ここで、×は楕円曲線乗算を表す）：
Figure 2022533845000063
コミッターは、後の段階で、値ρ及びσを提供することにより、コミットメントを完全に開放できる（つまり、それが検証され得る）。コミッターは、Sigmaプロトコルの部分として特定のチャレンジ値に応答して、（ρ及びσを開示することなく）コミットも開放できる。
Pedersenコミットメントの有用な特性は、それらが相加的に準同形であることであり、（楕円曲線上の）２つのコミットメントを加算することがコミットされた値の和に対するコミットメントを生じることを意味する。つまり、
Figure 2022533845000064
 この準同形特性は、演算回路従属性のゼロ知識証明において利用される。
＜ゼロ知識における演算回路従属性の証明＞
演算回路
Figure 2022533845000065
 は、ワイヤにより接続される演算ゲートの論理構成であり（有向非巡回グラフを形成する）、これは、任意の複素計算を実行できる（計算は、整数演算に限定され、データに依存するループ又は可変状態を有しない）。各ゲートは、２本の入力ワイヤ及び１本の出力ワイヤを有し、入力に対して乗算（×）又は加算（＋）のいずれかを実行する。完全な回路は、外部（回路）入力及び出力値を定義する自由な入力ワイヤ及び自由な出力ワイヤを有する。
ワイヤの値の正当な割り当ては、回路を満たす、割り当てられたワイヤ値のセットとして定義される。つまり、各ワイヤは、値に割り当てられ、ここで、各ゲートの出力は入力の積又は和に正しく対応する（つまり、ゲートが矛盾しない）。
図１７は以下を示す：（ａ）左（wL）及び右（wR）ワイヤ入力及び１本のワイヤ出力（wO）を有する乗算ゲート、及び（ｂ）３本の入力ワイヤ（w１,w２,w３）と１本の出力ワイヤ（w６）と２本の内部ワイヤ（w５,w６）とを有する３個のゲートを有する単純な演算回路。
所与の演算回路について、証明者は、彼らが該回路の正当な割り当てを知っていることを、ワイヤ値を開示することなく、先ず（Pedersenコミットメントにより）正当な割り当ての中の各ワイヤ値にコミットして、次にワイヤ値を目撃者として回路内の各ゲートについて検証者と共に特定のSigmaプロトコルを実行することにより（これは並列に実行できる）、検証者に対して証明できる。これらのSigmaプロトコルは、後述するように、Pedersenコミットメントの準同形特性を利用する。
（回路が満たされるという）証明を生成するために、最初に、証明者は、回路内の各ワイヤwi（i=１,…,m、ここで、mはワイヤの数である）へのコミットメントを生成し、これらを検証者へ送信する：
Figure 2022533845000066
＜Σzeroプトロコル＞
回路内の各加算ゲートについて、Σzeroプトロコルが実行される。これは、（ゼロ知識で）wL+wR-wO=０（つまり、加算ゲートが以下を満たすこと：入力ワイヤwL及びwRが出力ワイヤwOに等しいこと）を証明することを含む。
注：添え字Rは、ワイヤインデックスであり、この文脈では点R=k・Gを示さない。
Figure 2022533845000067
４によると、証明を検証するために、証明検証アルゴリズムVは以下を必要とする：
Figure 2022533845000068
 これは、単一の加算ゲートについてであることに留意する。
＜Σprodプトロコル＞
各乗算ゲートについて、Σprodプトロコルが実行される。これは、（ゼロ知識で）、乗算ゲート毎に、wL・wR=wO（つまり、乗算ゲートが満たされること）を証明することを含む。
Figure 2022533845000069
５によると、検証アルゴリズムVは以下を必要とする：
Figure 2022533845000070
＜回路証明＞
Σzero及びΣprodプトロコルは、回路内の各ゲートの検証のために並列に動作でき、同じ検証者チャレンジ値（ξ）が全部のゲートについて使用できる。
例として、図１７（ｂ）の回路を検討する。証明者は、彼らが正当な割り当て（つまり、回路を満たすワイヤ値）を知っていることを、検証者に対してゼロ知識で証明する。証明者は、最初に、各ゲートのワイヤコミットメント（W１,…,W６）及びΣプロトコルコミットメント（これは、各加算ゲートについて１個の加算コミットメント、及び各乗算ゲートについて５個）を検証者へ送信する。
検証者は、次に、ランダムチャレンジ：
Figure 2022533845000071
 により応答し、証明者は、各ゲートについて開放値を計算し（各加算について１個、及び各乗算について５個）、それらを検証者へ返送する。検証者は、次に、Σプトロコルチェックを実行して、以下を検証する：
Figure 2022533845000072
従って、コミットメントW１,…,W６が満足の行くワイヤ値w１,…,w６に対応することを検証する。
証明者は、回路を満たすことに加えて、特定のワイヤが特定の値を有することを示したいと望む場合、彼らは、関連するワイヤへのコミットメントを完全に開放できる。例では、証明者は、検証者へ、値w６及びρ６を追加で送信でき（検証者は、次に、W６=Com(w６,ρ６)を確認でき）、w６が特定の正当な割り当てからの実際の出力であることを実証する。
説明を目的として簡易な回路が図１７（ｂ）に示された。実際の有用な回路は、より多くのゲートで構成される。特に関心があるのは、SHA２５６ハッシュ関数のための演算回路である。この回路は、証明者が、彼らが、プリイメージを開示することなく、特定の（出力）値へとハッシングされるSHA２５６関数へのプリイメージ（入力）を知っていることを実証することを可能にする。SHA２５６アルゴリズムのための回路の最も効率的な実装のうちの１つは、（例えば、Zcashで実装される）２７,９０４個の演算ゲートで構成される。SHA２５６の知識を証明するために、プリイメージは、次に、上述のプロトコルの初期コミットメント及び開放ラウンドの両方で、～５MBのデータを送信することを要求し、及び証明者及び検証者の両方に対して～２００,０００回の楕円曲線演算（それぞれ、数秒のプロセッサ時間を要する）を要求する。コミットメントの特性に制限を導入することなく、これらの計算コスト及び証明サイズを実質的に削減するための幾つかの最近公開されたプロトコルがある。
＜ペアリングを有しない演算回路充足可能性のための効率的なゼロ知識の議論＞
前の章で説明した演算回路充足可能性を証明するための並列Σプロトコルのアプローチの性能を有意に向上するために開発された幾つかの方法がある。参照により全体がここに組み込まれる以下のそれぞれの文献を参照する：
Groth, Jens. "Linear Algebra with Sub-linear Zero-Knowledge Arguments.」 CRYPTO. Vol.５６７７. ２００９. [Groth ２００９];
Bootle, Jonathan, etal. "Efficient zero-knowledge arguments for arithmetic circuits in the discrete log setting." Annual International Conference on the Theory and Applications of Cryptographic Techniques. Springer, Berlin, Heidelberg, ２０１６. [Bootle２０１６].
[Bootle ２０１６]及び[Groth ２００９]に記載されたアプローチは、証明者から検証者へ送信されなければならないデータのサイズを有意に削減する為に、回路ワイヤ値へのコミットメントを一括（バッチ処理、batch）することを含む（つまり、計算の複雑さを低減する）。これらの方法は、証明システムを可能にし、
Figure 2022533845000073
ここでも、同じSHA回路の充足可能性を証明するための比較として、[Bootle ２０１６]のプロトコルは、たった５KBのサイズの証明鍵及び１８０msの鍵生成時間しか有しない。証明サイズは２４KBであり、生成するのに～４sを要し、証明も検証するのに～４sを要する。
これらの方法は、後述する主要なベクトルバッチ処理プロトコルが利用されることを除き、ここで完全に説明されている。これは、標準的なPedersenコミットメントと同じ特性に従うが、n個の要素：
Figure 2022533845000074
 にコミットすることは、単一のグループ要素の送信しか必要としない：
Figure 2022533845000075
＜証明検証アルゴリズム(V)-例＞
この章は、証明検証アルゴリズムV（上述の[ZK_VERIFY]）の異なる例、及びバッチ処理及び非バッチ処理コミットメントに基づくゼロ知識証明システムについて、その実装を説明する。
２つのパーティ：証明者（P）及び検証者（V）が、ゼロ知識証明プロトコルに関与する。プロトコルの目的は、ステートメントの目撃者に関する情報を秘密にしたまま、証明者が、所与のステートメント（S）が真であると検証者を説得することである。ステートメントは、q個のゲート及びm本のワイヤ並びに回路ワイヤ値：pklのうちの１つ（以上）に対応する楕円曲線公開鍵に関する依存アサーション（dependent assertions）を有する演算回路（C）で構成される（ここで、添え字lは、鍵ステートメントのワイヤインデックスである）。更に、ステートメントは、完全に開放された（公開）ワイヤ値（つまり、回路の公開入力／出力）に関するアサーションも含んでよい。
ステートメント内で指定された楕円曲線公開鍵は、目標楕円曲線仕様（これは、楕円曲線パラメータの完全なセット：T=(p,a,b,G,n,h)により定義される）に対応する。Bitcoinスクリプトの場合には、これらのパラメータは、secp２５６k１の仕様により定義される。この仕様は、基本生成元（base generator point）Gを含む。
ベースポイントを指定することに加えて、ステートメントは、第２の点Fも指定しなければならない。
Figure 2022533845000076
 fの値は証明可能にランダム（例えば、Bitcoinジェネシスブロックハッシュ）、又はπの２進表現の最初の２５６個のビットのような「nothing up my sleeve」番号でなければならない。（証明者にfについての自由な選択を許可することは、彼らが偽の証明を生成することを可能にする。）
図１８は、４個のゲート及び５個のワイヤを有する例示的な回路を示す。１本の入力ワイヤ（w１）は、「鍵開放」値ko１を有するワイヤコミットメント（W１）からの、その開示された（開放された）公開鍵を有する。
＜例１：個別ワイヤコミットメント＞
本章は、検証者が回路内の各ワイヤへの個別コミットメントを有するときの鍵開放を説明する（つまり、演算回路充足可能性のためにΣプロトコルに従う、以上を参照）。
Figure 2022533845000077
図１９は、ステートメントSの証明のための、証明者（P、証明トランザクション１６０４を提供する者）と検証者（V）（チャレンジトランザクション１６０２を設定するチャレンジャー）との間の例示的なプロトコルフローを示す。ステートメントは、回路の説明、及びワイヤlが公開鍵pklを有することを含む。
＜例２：バッチ処理ベクトルコミットメント＞
ベクトルコミットメントのバッチ処理を含む回路充足可能性のための圧縮された証明システム[Bootle ２０１６, Groth ２００９]の場合には、以下に説明する方法は、バッチ処理された回路ワイヤコミットメントから鍵ステートメント証明を抽出するために使用できる。完全な証明プロトコルは説明されず、バッチ処理されたワイヤコミットメントの生成、及びそれを実証するプロトコルが指定された公開鍵を含むことのみを説明する。
バッチ処理されたコミットメントは、以下のように生成される。ここで、ワイヤlは、鍵開放により供給されるべきである。m本のワイヤは、ベクトルコミットメントにおいて一緒にバッチ処理される。
Figure 2022533845000078
＜ハッシュプリイメージ及び楕円曲線秘密鍵の等価性の証明＞
本章は、ハッシュ攻撃バウンティの文脈で利用可能な鍵ステートメントのゼロ知識証明の例を説明する。
単に例として、バウンティを請求するために証明されるべきステートメントSは、具体的に本例において以下のように策定される。
Ｓ：「公開出力h及びsecp２５６k１楕円曲線上の公開点Rを有するSHA-２５６ハッシュ関数（H）が与えられると、ハッシュのシークレットプリイメージd（つまり、h=H(d)）は、楕円曲線点乗算に等しい（つまり、対応する一時鍵、つまりR=d×G）。
上述のアプローチでは、このステートメントは、入力ワイヤ（w１）が公開点Rの秘密鍵であること、及び出力ワイヤ（wm）がhに等しいことの証明と一緒に、（m本のワイヤwi、（i=１,…,m）、及びq個のゲートを有する）SHA２５６ハッシュ関数CSHA２５６のための単一の演算回路で構成される。つまり、
Figure 2022533845000079
従って、このステートメントを完全に検証するために、証明者は、secp２５６k１に基づくコミットメント方式を用いて、彼らがSHA２５６回路に対する満足の行く割り当てを知っていることを検証者に実証しなければならなず、次に単にワイヤ１の鍵開放（ko１）及びワイヤmの完全開放（wm,ρm）を提供する。検証者は、完全に開放された出力ワイヤwnを除いて、入力ワイヤ（w１）、又は他のワイヤのうちの何れかの値を知らない。
証明検証アルゴリズムVは、従って、以下のようにrパズルの枠組みの中で構成され得る。
上述のステートメントSを検証するために、証明検証アルゴリズムは以下を要求する：
Figure 2022533845000080
一緒に、E１～E７は、証明トランザクション１６０４の証明πを構成し、本願明細書において証明πの要素と呼ばれてよい。
ξは、ここでは意図的に省略される。ξは、検証者により設定されたチャレンジであると定義される。非対話型AKPでは、ξは、WL、WR、及びB又はCiのハッシュ値であると定義されてよい。従って、検証者は上述の与えられた情報からξを算出できる。言い換えると、チャレンジトランザクション１６０２は、ξの実際の値を指定する必要がなく、ξを導出するためのステップを指定するだけで十分である。検証アルゴリズムVは、一方で、証明π自体からξの値を導出できる。
検証アルゴリズムVは、以下のように所与の公開一時鍵Rについて実施され得る。
Figure 2022533845000081
注：ステップe)は、hが予め指定された場合に適用可能である。しかしながら、ハッシュ衝突バウンティの場合には、それは省略でき、これを以下に説明する。
ハッシュ衝突バウンティについて、２個のそのような証明π１、π２が受信される。
証明者が要求された２つの証明π１、π２を提供するために、証明者により発見された衝突するプリイメージに関して、演算回路の２つのインスタンスが、証明（第１、第２インスタンス）により構成される。
注意すべきことに、第１証明π１の要素は、上述のように正確に記述されたE１～E７であり、第２証明π’は同じ特性を用いて示されるが、「’」を付される（primed）：
Figure 2022533845000082
検証アルゴリズムVは、以下のように所与の公開一時鍵Ｒ１、R２について実施され得る。
Figure 2022533845000083
注：３a)から明らかなように、hは、図１６の証明トランザクション１６０４のπ１及びπ２と別個に示されるが、実際に別個の要素であることは要求されず、wm=wm'により暗示的に定義できる。
入力ワイヤw１,w１’は差し控えられ、それらの値は入力ワイヤw１,w１’における提供された鍵開放ko１,ko１’から導出できない。この方法では、鍵開放は、入力ワイヤを開示することなく、開示される。
＜アカウントに基づくモデルにおける代替の実装＞
以上は、大まかに、アウトプットに基づくモデル（例えば、UTXOに基づくモデル）における実装の観点で説明された。しかしながら、これは限定的ではないことが理解される。図１１は、アカウントに基づくモデルを使用する可能な代替の実装を示す。
要するに、アカウントに基づくモデルでは、rパズル機能は、ユーザにより呼び出されるスマートコントラクト関数に含まれ得る。あるパーティは、スマートコントラクト内にrパズル値（又はハッシングされたrパズル値）を設定できる。次に、他のパーティは、その後にスマートコントラクトに署名を提供し得る。
UTXOブロックチェーンアーキテクチャでは、第１トランザクションのアンロックスクリプト内に埋め込まれた要件は、第２トランザクションが有効であるとして受け入れられブロックチェーンに記録されるためには、第２トランザクションのロックスクリプトにより満たされなければならない。この状況で、トランザクション検証処理の部分としてマイナーにより既に行われた作業を利用するので、これは有利である。この状況における具体例として、トランザクションがブロックチェーンに追加されたという事実は、ブロックチェーンネットワーク全体に渡るノードにより検証されたことを意味し、また、そのロックスクリプトが特定の有用な要件を満たすことを意味する。関心のあるパーティは、彼ら自身のために、それらの要件が満たされるかどうかをチェックする必要がなく、トランザクションがブロックチェーンに記録されることに成功しているという事実により、彼らは、単に、それらの要件が満たされていると想定できる。これは、トランザクションが有効であるためには、スクリプトが完了すると「真」の結果を返さなければならないという事実に起因し（トランザクションが有効であるための他の要件が存在してもよい）、スクリプトが「偽」の結果を返した場合には（これは、本願明細書で使用される用語によると、例えばOP_VERIFYオペコードがスクリプトを終了したために、スクリプトが失敗した場合を含む）、トランザクションは無効である。
しかしながら、他のブロックチェーンモデル（例えば、特定のアカウントに基づくアーキテクチャ）では、トランザクション有効性と実行トランザクションコードの結果との間の相互依存性は必ずしもミラーリングされない。例えば、特定のスマートコントラクトブロックチェーンでは、トランザクションは、それらがブロックチェーンプロトコルにより課される「基本的」有効性要件のセットを満たすならば、有効であり、従って、ブロックチェーンに記録するために受け入れられてよい。従って、第２トランザクションは、第１トランザクションのコードに埋め込まれた特定の要件を満たさない場合でも、依然として有効であるとして受け入れられ、ブロックチェーンに記録されてよい。第１トランザクションのコードは、例えば、スマートコントラクトコードであってよい。
第２トランザクションが、第１トランザクションにより生成されたスマートコントラクトアカウントにアドレスされているとすると、それは次に、該トランザクションにどのように応答するかを決定するためにスマートコントラクトコードへと落とされる。例えば、何らかの要件が乱されない場合にそれを無視し（又は偽の結果を返し）、一方で、要件が正しい場合には、スマートコントラクトアカウントの残額から減額されクレジットされたデジタルアセットの額で、証明者に報酬を与える（又は真の値を返す）。ある意味、これは、ノードにより「暗示的に」実行される「プロトコルレベル」の処理、つまりブロックチェーンネットワークが動作するブロックチェーンプロトコルにより課される有効性の要件を満たすかどうかを決定するトランザクションに対して実行される処理から、スマートコントラクト（エージェント）による、つまりスマートコントラクトコード内に明示的にコーディングされた、「エージェントレベル」の処理を抽象化する。従って、そのようなブロックチェーンアーキテクチャでは、トランザクションそれぞれのプロトコルレベルにおけるノードによる「有効／無効」の決定は、スマートコントラクトによりエージェントレベルで該トランザクションに関して返される「真／偽」の結果から分離されてよい。ここで、トランザクションは、プロトコルレベルで有効であると決定されてよいが、エージェントレベルでは偽の結果を返してよい。
これは、トランザクションが有効であるために「スクリプトが真」の結果を返すことが必要であるUTXOアーキテクチャと対照的に、トランザクションは、スクリプトが終了した又はスタック上に真以外のものを残して完了した場合に、無効である。
トランザクション有効性のための基本的要件のうちの１つは、トランザクションが有効な署名を含むことであってよい。従って、上述のUTXIの例では、署名はチャレンジトランザクション自体のコードにより（例えば、署名を検証し署名検証について真／偽を返すOP_CHECKSIGオペコード、又は同じ方法で署名をチェックし、更に結果が真であることを検証し、否である場合にスクリプトが終了するOP_CHECKSIGVERIFYオペコードを用いて）検証されたが、代替のブロックチェーンアーキテクチャでは、署名は、上述の意味では暗示的に処理ノードにより検証されてよく、これは、トランザクションコード自体に署名チェックをコーディングする必要を回避できる。
本願の文脈では、具体的な例として、トランザクションは、例えば有効な署名を含むので、プロトコルレベルで有効であると考えられる。しかし、例えば、何らかの他の要件が満たされないので、アプリケーションレベルでは依然として偽の結果を返してよい。
図１１は、アカウントに基づくモデルによる、トランザクションを処理するノードソフトウェア４００の代替案を示す。ノードソフトウェアはここでは４００accとラベル付けされる。このノードソフトウェア４００accのインスタンスは、ネットワーク１０６のアカウントに基づくバージョンのノード１０４の各々に実装されてよい。アカウントに基づくノードソフトウェア４００accは、アカウントに基づくプロトコルエンジン４０１acc、コントラクトエンジン４０２acc(スクリプトエンジン４０２と同様のもの）、アプリケーションレベルの決定エンジン４０４、及び１つ以上のブロックチェーン関連機能モジュールのセット４０５を含む。任意の所与のノード１０４で、これらは、（ノードの１つ以上の役割に依存して）マイニングモジュール４０５M、転送モジュール４０５F、及び格納モジュール４０５S、のうちの任意の１、２、又は３個全部を含んでよい。プロトコルエンジン４０１accは、トランザクションの異なるフィールドを認識し、それらをノードプロトコルに従い処理するよう構成される。ノードソフトウェア４００accは、それぞれのノード１０４のメモリに、複数のアカウントの各々のアカウント状態４０６も維持している。これらは、例えば、Alice、証明者（例えば、Bob）、及び／又はAliceと証明者との間で制定されるコントラクトに依存して借り方又は貸し方である別のパーティのアカウントを含み得る。コントラクトエンジン４０２accは、トランザクション内で受信したスマートコントラクトの結果に依存して、アカウント状態を変更するよう構成される。スマートコントラクトは、「エージェント」とも呼ばれる。
図１１は、図７～１０に関して上述したものと同じ又は同様のrパズル機能を実装し得るトランザクションTx１ acc及びTx２ accのペアも示す。それぞれは、（ソースアドレスフィールド内の）ソースアカウントアドレス１１０２、及び（宛先アドレスフィールド内の）宛先アカウントアドレス１１０３を含む。第１トランザクションTx１ accは、ソースアカウントアドレス１１０２a及び宛先アカウントアドレス１１０３aを含む。第２トランザクションTx２ accは、ソースアカウントアドレス１１０２b及び宛先アカウントアドレス１１０３bを含む。第１トランザクションTx１ accは、スマートコントラクト１１０１も含む。スマートコントラクト１１０１は、Aliceによるチャレンジ（パズル）を含んでよい。それは、Aliceにより、又はAliceにより提供された詳細を用いてAliceに代わる第三者により生成されてよい。第２トランザクションTx２ accは、任意的に、ユーザの指定したペイロードデータを運ぶ１つ以上の手数料データフィールド１１０４を含んでよい。これ／これらは、証明者、例えばBobにより提供されたパズルに対する解の少なくとも部分を含んでよい。トランザクションTx１ acc及びTx２ accは、更にAlice及び証明者によりそれぞれ署名される。各トランザクションは、それぞれのパーティの署名１１０５a、１１０５bも含む。
トランザクションは、ネットワーク１０６に渡りブロードキャストされる。プロトコルエンジン４０１accは、各トランザクションを受信すると、署名１１０５が有効か否かを自動的に検証する。つまり、これは、プロトコルエンジン４０１accの固有の機能であり、スマートコントラクト１１０１内で指定される必要がない。プロトコルエンジン４０１accは、従って、少なくともそれぞれの署名が有効であることを条件に、転送及び／又はマイニングのために各トランザクションを検証する。それは、満たされるべき、有効性のための１つ以上の追加条件を要求してもよい。有効ならば、アプリケーションレベル決定エンジン４０４は、それぞれトランザクションをマイニング及び／又は転送するよう、マイニングモジュール４０５M及び／又は転送モジュール４０５Fを制御するかを選択できる。
そのようなアカウントに基づくモデルでは、Alice、Bob、及びスマートコントラクト自体は、異なるアカウントアドレスを有する別個のアカウントを割り当てられる。トランザクションは、そのソースアドレスフィールド内のアドレス「から」、その宛先アドレスフィールド内のアドレス「へ」、送信されると言える。スマートコントラクト用にアカウントを生成するために、スマートコントラクトのバイトコードを含むトランザクションが、トランザクションの中でブロックチェーンにアップロードされる。そのようなアカウント生成トランザクションでは、宛先フィールド内の宛先アドレス１１０３は、ブロックチェーンにおいて以前に使用されたことがないアドレスでなければならない。一旦、トランザクションが受け付けると、そのアドレスは、新たに生成されたスマートコントラクトアカウントのアドレスになる。その後、更なるトランザクションは、スマートコントラクトを「呼び出す」ためにそのアドレスへ送信されることができ、つまり、更なるトランザクションに依存して、スマートコントラクトのバイトコードを実行させる。「宛先」アドレス１１０３は、コントラクトを制定するために中間アドレスとして動作する。Aliceは、１つ以上の要件を指定するスマートコントラクトを生成するために、TX１ accをそのアドレスへ送信する。Bobは、スマートコントラクトを呼び出すために、TX２ accをその同じアドレスへ送信する。また、スマートコントラクトに、TX２ accがそれらの指定された要件を満たすか否かを検証させる。「ソース」アドレス１１０２は、コントラクトに対するパーティであるユーザのアカウントを指定する。スマートコントラクトがTX２ accは指定された要件を満たすと決定した場合、スマートコントラクトは、自身の口座（アカウント）残高からデジタルアセットの額を控除し、TX２ acc内のソースアドレス１１０２bを有するアカウント（つまり、Bobのアカウント）の残高をその額だけクレジットさせる（credit、貸し方に記入する）（直感的には、TX２ accを送信することにより、Bobは、事実上、（ソースアドレスフィールド内で識別される）彼のアカウントをクレジットするよう（宛先アドレスフィールド内で識別される）スマートコントラクトに依頼する）。
プロトコルエンジン４０１accは、TX２ accを受信すると、それが有効であることを条件に、TX２ acc内の宛先アドレス１１０３bと一致するアカウントを探す。Tx１ accが処理され、有効であるとすると、そのアカウントは、TX１ accのお陰で存在し、TX１内で提供されたスマートコントラクトコードに関連付けられる。応答して、プロトコルエンジン４０１accは、Tx１ accからのスマートコントラクト１１０１を実行するよう、コントラクトエンジン４０２accを制御し、コントラクト内にどんな基準が定義されているかに依存して、スマートコントラクトの１つ以上のフィールドからのデータをオペランドデータとして取り入れる。オペランドデータは、例えば、自由データフィールド１１０４の１つ以上からのデータ、及び／又は署名フィールド１１０５bからの署名を含んでよい。Tx２ accからのオペランドデータがTx１ accのスマートコントラクト１１０１内に定義された１つ以上の基準を満たすことを条件として、コントラクトエンジン４０２accは、スマートコントラクト１１０１内に定義された変更に従い、１つ以上のパーティ（Alice、証明者、及び／又は１人以上の第三者）のアカウント状態４０６を変更する。その他の場合、アカウント状態４０６に対するこの変更は行われない。しかしながら、幾つかのアカウントに基づくシステムでは、スマートコントラクトの結果は、トランザクションの有効性のための条件ではない。従って、Tx２ accがTx１ accのスマートコントラクト１１０１内に設定された基準を満たさない場合、Tx２ accは、失敗したトランザクションのレコードとして、依然として伝播されブロックへとマイニングされる。それは、依然としてマイニング手数料ももたらし得る（従って、プロトコルエンジン４０１は、依然として、パーティのうちの１つ及び勝者であるマイナーのアカウント状態４０６を変更してよい）。
rパズルを実装するために、rパズル機能の少なくとも一部は、Tx１ accのスマートコントラクト１１０１内にコーディングされることができ、解は、Tx２ accのデータフィールド１１０４の１つ以上の中で提示できる。例えば、これは、図７の変形を実装するために使用され得る。任意的に、プロトコルエンジン４０１accの暗示的署名検証機能の一部は、例えば、図８～１０の変形のうちの１つを実装するために、利用され得る。図８～１０の場合には、ステップＩＩ）及びＩＩＩ）は、Tx２ accの署名を検証するとき、プロトコルエンジン４０１accの陰関数であってよい（署名検証自体はプロトコルエンジン４０１accにより実装されるノードプロトコルの固有機能であることを思い出してほしい）。従って、Tx１ accのスマートコントラクト１１０１では、これの上にステップＩ）を積み重ねるだけでよい。スマートコントラクトは、Ｉ）の結果が真であるかどうか、及びプロトコルエンジン４０１accがTx２ accは有効であると示すかどうか、をチェックする。両方がYesである場合、それは、検証について「真」の全体の結果を宣言する。つまり、Bobは、rパズルにより設定されたチャレンジを満たすことに成功する。図８～１０の実装のうち、図９及び１０の場合にデータ値dのみが、自由データフィールド１１０４に含まれる必要があるだけであることに留意する。署名情報は、署名フィールド１１０５bに含まれる。
スマートコントラクトアカウントは、アカウントに関連付けられた（論理的）データ記憶要素である「データレジスタ」（図示しない）ともインデックスを付される。以上に概説したUTXOモデルでは、値は、ロックスクリプト自体に埋め込まれ、同じことがスマートコントラクトコード１１０１の特定のピースについても言える。しかしながら、スマートコントラクトのスマートコントラクトバイトコードは、代替として又は追加で、そのアカウントレジスタのうちの１つ以上に格納されたデータで実行されてよい。更に、通常、スマートコントラクトアカウントが生成された後に、スマートコントラクトアカウントレジスタに値を格納することが可能である。従って、例えば、スマートコントラクトアカウントは、スマートコントラクトバイトコードを含むチャレンジトランザクションTx１,α accにより生成されてよい。別個の「中間」トランザクションTx１,β accは、次に、（今や存在する）スマートコントラクトアカウントへ送信されてよく、スマートコントラクトアカウントのレジスタ＄Rに特定の値vを格納する効果を有する。スマートコントラクトは、（例えば）指定されたソースアカウントアドレス、例えば第１の場所（Alice）でスマートコントラクトを生成した同じパーティからのそのようなデータのみを受け付けるよう構成されてよい。Tx２ accが受信されると、コントラクトエンジン４０２accにより実行される演算（例えば、「レジスタ＄Rにアクセスし、値をTx２ accのデータフィールド内の値＄Dと比較する」）は、チャレンジトランザクションTx１,α acc内で提供されるスマートコントラクトバイトコードにより定義される。しかし、$Rに格納された値は、中間トランザクションTx１,β accにより設定されている。本願明細書で使用される用語によると、Tx１,α accは、依然として、１つ以上の要件を設定するチャレンジトランザクションと言える。今や、それらの要件のみが、１つ以上の中間トランザクション（例えば、Tx１,β acc）内で提供されるデータを参照して定義されてよい。
従って、幾つかの実装では、チャレンジトランザクションTx１,α accは、ｒパズルの演算（例えば、証明トランザクションTx２ accの署名のr部分をレジスタ$R内の値と比較し、それらが一致するかを調べる、等）を定義してよい。しかし、証明トランザクションTx２ accのr部分と比較される$R内の値は、中間トランザクションTx１,βaccにより送信されてよい。
幾つかのアカウントに基づくモデルは、署名１１０５と一緒に公開鍵Pが含まれることを必要としないことにも留意する。代わりに、単に１ビットフラグflgを含む。上述のように、（r,s）及びメッセージから２つの可能な鍵P及び-Pを導出することが可能である。フラグflgは、これらの２つの可能な解のうちのどちらが、実際に、Tx２ accにおいてメッセージに署名するために証明者により使用された秘密鍵Vに対応する公開鍵であるかをシグナリングするために使用される。プロトコルエンジン４０１accは、この（r,s）及びflgを使用して、Tx２ accの中で明示的に受信する代わりに、署名者の公開鍵Pを導出する。この技術は、アウトプットに基づくモデルでも可能であり、アカウントに基づくモデル専用ではない。しかし、多くの現在のアウトプットに基づくモデルで使用されるスクリプト言語では、r及びsからPを導出するための専用オペコードが存在しない。従って、この機能を、スタックに基づく言語の既存の汎用オペコードを用いてアンロックスクリプト内に明示的にコーディングすることは複雑になるだろう。更に、特定のアカウントに基づくモデルは、トランザクションに署名するために使用された公開鍵から該トランザクションのソースアドレスを導出することに留意する。従って、ソースアドレスは、必ずしも、トランザクション内で別個に符号化されず、公開鍵が署名から導出される場合には、これは、ソースアドレスも署名から間接的に導出され得ることを意味する。
上記の実施形態は、単なる例示として説明したものであることが理解されるであろう。
より一般的には、本願明細書に開示された第１の態様によると、（「例１」）ブロックチェーンネットワーク内に維持されるブロックチェーンに記録するためにトランザクションのセットを用いて知識証明を実行する、コンピュータにより実施される方法であって、前記方法は、
チャレンジャーにより、競争チャレンジを決定するステップであって、前記競争チャレンジは該競争チャレンジから導出可能なチャレンジ解を有する、ステップと、
チャレンジャー装置において、前記競争チャレンジの署名チャレンジを決定するステップと、
前記ブロックチェーンに記録するために、前記ブロックチェーンネットワークに、少なくとも１つのチャレンジトランザクションの中で前記署名チャレンジを提出するステップと、
を含み、
前記競争チャレンジは、複数の競争する被チャレンジャーに通信され、前記チャレンジ解を直接通信せずに、それにより競争する被チャレンジャーに前記競争チャレンジから前記チャレンジ解の独立インスタンスを導出するよう競争させ、
前記被チャレンジャーのうち、前記チャレンジ解の独立インスタンスを導出することに成功した最初のものが、そのデータを、被チャレンジャー装置において少なくとも１つのメッセージに署名するためにシークレット被チャレンジャー鍵として使用し、それにより、少なくとも１つのトランザクション署名を生成し、前記少なくとも１つのトランザクション署名及び前記少なくとも１つのメッセージを少なくとも１つの証明トランザクションの中で前記ブロックチェーンネットワークに提出し、それにより、前記ブロックチェーンネットワークのノードに、前記少なくとも１つのトランザクション署名が前記署名チャレンジを満たすかどうかを決定させる、方法が提供される。
第１の態様の例示的な実施形態は、列挙される例として以下に記載される。
例２。前記署名チャレンジは、公開署名検証データを含み、前記チャレンジャーは、前記チャレンジ解を決定し、前記チャレンジ解のデータを、前記公開署名検証データを生成するためにシークレットチャレンジャー鍵として使用し、それにより、前記ノードは、前記メッセージ及び前記公開署名検証データに基づき、前記トランザクション署名を検証するようにされる、例１に記載の方法の実施形態。
例３。前記トランザクション署名は、楕円曲線デジタル署名アルゴリズム（ECDSA）を用いて生成される、例１又は２に記載の方法の実施形態。
例４。前記シークレットチャレンジャー鍵及び前記シークレット被チャレンジャー鍵は、一時鍵として使用され、前記公開署名検証データは、前記シークレット被チャレンジャー鍵から導出される公開されたr部分データであり、前記ノードは、署名検証関数を以下：
（ｉ）前記トランザクション署名のs部分、及び
（ｉｉ）以下のうちの１つ：
（ｉｉａ）前記トランザクション署名のｒ部分であって、その場合には、前記ノードは、更に、前記公開されたr部分データが前記トランザクション署名の前記r部分に一致することをチェックするようにされ、
（ｉｉｂ）前記少なくとも１つのチャレンジトランザクションの前記公開されたr部分データの公開されたr部分、
に適用することにより、前記少なくとも１つのトランザクション署名が前記署名チャレンジを満たすかどうかを決定する、例２及び３に記載の方法の実施形態。
例５。前記公開されたr部分データは、公開されたr部分ハッシュを含み、前記ノードは、以下：
前記署名検証関数を前記トランザクション署名の前記r部分及び前記s部分に適用し、
前記トランザクション署名の前記r部分に基づきトランザクションr部分ハッシュを計算し、
前記トランザクションr部分ハッシュが前記公開されたr部分ハッシュに一致するかどうかを決定する、
ことにより前記トランザクション署名を検証する、例４に記載の方法の実施形態。
例６。前記トランザクション署名は、前記少なくとも１つの証明トランザクションにより識別されるが前記少なくとも１つのチャレンジトランザクションにより指定されない公開鍵を用いて検証され、それにより、前記署名チャレンジを満たす少なくとも１つのトランザクション署名を生成するために、任意の秘密鍵が使用できる、例４又は５に記載の方法の実施形態。
例７。前記少なくとも１つの証明トランザクションは、第２トランザクション署名を含み、前記トランザクション署名及び前記第２トランザクション署名は、共通秘密鍵を用いて生成されるが、前記第２トランザクション署名は、異なる一時鍵を使用する、例３～５のいずれかに記載の方法の実施形態。
例８。前記シークレットチャレンジャー鍵及び前記シークレット被チャレンジャー鍵は、秘密鍵として使用され、前記公開署名検証データは、前記シークレット被チャレンジャー鍵から導出される公開された公開鍵データであり、前記ノードは、署名検証関数を以下：
（ｉ）前記トランザクション署名、及び
（ｉｉ）以下のうちの１つ：
（ｉｉａ）前記トランザクション署名に関連付けられた公開鍵であって、その場合には、前記ノードは、更に、前記関連付けられた公開鍵が前記公開された公開鍵データに一致するかどうかを決定するようにされる、又は、
（ｉｉ）前記少なくとも１つのチャレンジトランザクションの前記公開された公開鍵データの公開された公開鍵、
に適用することにより、前記トランザクション署名を検証する、例２、又は例２に依存する例３に記載の方法の実施形態。
例９。前記公開された公開鍵データは、公開された公開鍵ハッシュを含み、前記ノードは、以下：
前記署名検証関数を前記トランザクション署名及び前記トランザクション署名に関連付けられた前記公開鍵に適用し、
前記トランザクション署名に関連付けられた前記公開鍵に基づきトランザクション公開鍵ハッシュを計算し、
前記トランザクション公開鍵ハッシュが前記公開された公開鍵ハッシュに一致するかどうかを決定する、
ことにより前記トランザクション署名を検証する、例８に記載の方法の実施形態。
例１０。前記チャレンジ解のハッシュは、前記シークレット被チャレンジャー鍵として使用され、前記チャレンジ鍵の前記独立インスタンスのハッシュは、前記シークレット被チャレンジャー鍵として使用される、例１～９のいずれかに記載の方法の実施形態。
例１１。前記競争チャレンジは、前記ブロックチェーンネットワークと独立した１つ以上のサイドチャネルを介して競争する被チャレンジャーに通信される、例１～１０のいずれかに記載の方法の実施形態。
例１２。前記少なくとも１つのチャレンジトランザクションは、前記競争チャレンジを前記競争する被チャレンジャーに通信する効果を有する、例１～１１のいずれかに記載の方法の実施形態。
例１３。本開示の第２の態様（「例１３」）によるうと、ブロックチェーンネットワーク内に維持されるブロックチェーンに記録するためにトランザクションのセットを用いて知識証明を実行する、コンピュータにより実施される方法であって、前記方法は、
被チャレンジャーにより、競争チャレンジを受信するステップであって、前記競争チャレンジは導出可能なチャレンジ解を有するが、前記チャレンジ解は前記被チャレンジャーに直接通信されず、前記被チャレンジャーは前記競争チャレンジから前記チャレンジ解の独立インスタンスを導出するよう１つ以上の他の被チャレンジャーと競争する、ステップと、
を含み、
前記被チャレンジャーが、前記他の１つ以上の被チャレンジャーのうちのいずれよりも前に、前記チャレンジ解の前記独立インスタンスを導出することに成功すると、前記被チャレンジャーは、そのデータを、被チャレンジャー装置において少なくとも１つのメッセージに署名するためにシークレット被チャレンジャー鍵として使用し、それにより、少なくとも１つのトランザクション署名を生成し、前記少なくとも１つのトランザクション署名及び前記少なくとも１つのメッセージを少なくとも１つの証明トランザクションの中で前記ブロックチェーンネットワークに提出し、それにより、前記ブロックチェーンネットワークのノードに、前記少なくとも１つのトランザクション署名が前記少なくとも１つの証明トランザクションにより示されるチャレンジトランザクションの署名チャレンジを満たすかどうかを決定させる、方法が提供される。
例１４。例１３の前記トランザクション署名は、楕円曲線デジタル署名アルゴリズム（ECDSA）を用いて生成され、前記被チャレンジャー鍵は、前記トランザクション署名を生成するために秘密鍵と関連して使用される一時鍵であり、前記秘密鍵は、前記チャレンジトランザクションにより指定されずに、前記被チャレンジャーにより自由に決定される、例１３に記載の方法の実施形態。
例１５。前記トランザクション署名は、s部分のみで構成される、例１４に記載の方法の実施形態。
例１６。前記トランザクション署名は、s部分及びr部分を含む、例４に記載の方法の実施形態。
例１７。例２の代替の前記チャレンジ解は、前記署名チャレンジを決定するときに前記被チャレンジャーに知られていない、例２に記載の方法。
実施形態では、上述のトランザクションのうちの何れかは、ノードにより証明トランザクショントランザクションを検証するために、ノードにより処理されてよく、前記証明トランザクションが有効であると決定された場合、前記ノードは、前記証明トランザクションに有効化され、前記ノード前記は証明トランザクションをブロックチェーンネットワークにより維持されているブロックチェーンに記録させる。
例えば、そのような検証は、UTXOモデルにおいて適用されてよい。
代替又は追加で、上述のトランザクションのうちの何れかがノードにより処理されてよく、ノードは、真の結果、及び偽の結果のうちの１つを返す（そして、真の結果は、トランザクションが有効である場合に要求されてよく又はされなくてよい）。
しかしながら、例えば、アカウントに基づくモデルでは、有効なトランザクションは、偽の結果を返してよい。
任意のrパズルの文脈で、少なくとも１つの証明トランザクションのECDSA署名を検証するために使用される公開鍵は、少なくとも１つの証明トランザクション内で示されるが、少なくとも１つのチャレンジトランザクションによっては（或いはその他の場合にはブロックチェーン上で又はその他で）指定されないことがあり得る。従って、任意の秘密鍵は、ECDSA署名を生成するために使用されてよい（従って、署名は、それを生成するために誰の秘密鍵が使用されるかに関係なく、有効であってよい）。
公開鍵は、少なくとも１つの証明トランザクション内の文字列（string）として符号化され、それにより、少なくとも１つの証明トランザクション内で示され、マラは少なくとも１つの証明トランザクションのECDSA署名から導出されてよく、それにより、公開鍵はECDSA署名自体により示される。
少なくとも１つの証明トランザクションは、チャレンジトランザクションのトランザクション識別子を含み、それにより、チャレンジトランザクション（又はその適用可能な、rパズル、コード、等のようなコンポーネント）を示してよい。
代替として、少なくとも１つのチャレンジトランザクションは、rパズル、コード、又は他のコンポーネントを、アカウントアドレスに関連付けてよく、少なくとも１つの証明トランザクションは、一致するアカウントアドレスを含み、それにより、チャレンジトランザクションの該コンポーネントを示してよい。
本明細書に開示される別の態様によれば、第１パーティ（チャレンジャー）、第２パーティ（証明者）、関連し得る任意の第３者、及びノードのネットワーク（ブロックチェーンネットワーク）を備える方法を提供することができる。
本明細書に開示される別の態様によれば、第１パーティのコンピュータ機器、第２パーティのコンピュータ機器、任意の第３者のコンピュータ機器、及びノードのネットワークを備えるシステムを提供することができる。
開示された技術の他の変形例又は使用事例は、本明細書で開示されると、当業者に明らかになり得る。本開示の範囲は、記載された実施形態によって限定されるものではなく、添付の特許請求の範囲によってのみ限定される。

Claims (17)

  1. ブロックチェーンネットワーク内に維持されるブロックチェーンに記録するためにトランザクションのセットを用いて知識証明を実行する、コンピュータにより実施される方法であって、前記方法は、
    チャレンジャーにより、競争チャレンジを決定するステップであって、前記競争チャレンジは該競争チャレンジから導出可能なチャレンジ解を有する、ステップと、
    チャレンジャー装置において、前記競争チャレンジの署名チャレンジを決定するステップと、
    前記ブロックチェーンに記録するために、前記ブロックチェーンネットワークに、少なくとも１つのチャレンジトランザクションの中で前記署名チャレンジを提出するステップと、
    を含み、
    前記競争チャレンジは、複数の競争する被チャレンジャーに通信され、前記チャレンジ解を直接通信せずに、それにより競争する被チャレンジャーに前記競争チャレンジから前記チャレンジ解の独立インスタンスを導出するよう競争させ、
    前記被チャレンジャーのうち、前記チャレンジ解の独立インスタンスを導出することに成功した最初のものが、そのデータを、被チャレンジャー装置において少なくとも１つのメッセージに署名するためにシークレット被チャレンジャー鍵として使用し、それにより、少なくとも１つのトランザクション署名を生成し、前記少なくとも１つのトランザクション署名及び前記少なくとも１つのメッセージを少なくとも１つの証明トランザクションの中で前記ブロックチェーンネットワークに提出し、それにより、前記ブロックチェーンネットワークのノードに、前記少なくとも１つのトランザクション署名が前記署名チャレンジを満たすかどうかを決定させる、方法。
  2. 前記署名チャレンジは、公開署名検証データを含み、前記チャレンジャーは、前記チャレンジ解を決定し、前記チャレンジ解のデータを、前記公開署名検証データを生成するためにシークレットチャレンジャー鍵として使用し、それにより、前記ノードは、前記メッセージ及び前記公開署名検証データに基づき、前記トランザクション署名を検証するようにされる、請求項１に記載の方法。
  3. 前記トランザクション署名は、楕円曲線デジタル署名アルゴリズム（ECDSA）を用いて生成される、請求項１又は２に記載の方法。
  4. 前記シークレットチャレンジャー鍵及び前記シークレット被チャレンジャー鍵は、一時鍵として使用され、前記公開署名検証データは、前記シークレット被チャレンジャー鍵から導出される発行r部分データであり、前記ノードは、署名検証関数を以下：
    （ｉ）前記トランザクション署名のs部分、及び
    （ｉｉ）以下のうちの１つ：
    （ｉｉａ）前記トランザクション署名のｒ部分であって、その場合には、前記ノードは、更に、前記発行r部分データが前記トランザクション署名の前記r部分に一致することをチェックするようにされ、
    （ｉｉｂ）前記少なくとも１つのチャレンジトランザクションの前記発行r部分データの発行r部分、
    に適用することにより、前記少なくとも１つのトランザクション署名が前記署名チャレンジを満たすかどうかを決定する、請求項２又は３に記載の方法。
  5. 前記発行r部分データは、発行r部分ハッシュを含み、前記ノードは、以下：
    前記署名検証関数を前記トランザクション署名の前記r部分及び前記s部分に適用し、
    前記トランザクション署名の前記r部分に基づきトランザクションr部分ハッシュを計算し、
    前記トランザクションr部分ハッシュが前記発行r部分ハッシュに一致するかどうかを決定する、
    ことにより前記トランザクション署名を検証する、請求項４に記載の方法。
  6. 前記トランザクション署名は、前記少なくとも１つの証明トランザクションにより識別されるが前記少なくとも１つのチャレンジトランザクションにより指定されない公開鍵を用いて検証され、それにより、前記署名チャレンジを満たす少なくとも１つのトランザクション署名を生成するために、任意の秘密鍵が使用できる、請求項４又は５に記載の方法。
  7. 前記少なくとも１つの証明トランザクションは、第２トランザクション署名を含み、前記トランザクション署名及び前記第２トランザクション署名は、共通秘密鍵を用いて生成されるが、前記第２トランザクション署名は、異なる一時鍵を使用する、請求項３～５のいずれかに記載の方法。
  8. 前記シークレットチャレンジャー鍵及び前記シークレット被チャレンジャー鍵は、秘密鍵として使用され、前記公開署名検証データは、前記シークレット被チャレンジャー鍵から導出される発行公開鍵データであり、前記ノードは、署名検証関数を以下：
    （ｉ）前記トランザクション署名、及び
    （ｉｉ）以下のうちの１つ：
    （ｉｉａ）前記トランザクション署名に関連付けられた公開鍵であって、その場合には、前記ノードは、更に、前記関連付けられた公開鍵が前記発行公開鍵データに一致するかどうかを決定するようにされる、又は、
    （ｉｉ）前記少なくとも１つのチャレンジトランザクションの前記発行公開鍵データの発行公開鍵、
    に適用することにより、前記トランザクション署名を検証する、請求項２、又は請求項２に従属する請求項３に記載の方法。
  9. 前記発行公開鍵データは、発行公開鍵ハッシュを含み、前記ノードは、以下：
    前記署名検証関数を前記トランザクション署名及び前記トランザクション署名に関連付けられた前記公開鍵に適用し、
    前記トランザクション署名に関連付けられた前記公開鍵に基づきトランザクション公開鍵ハッシュを計算し、
    前記トランザクション公開鍵ハッシュが前記発行公開鍵ハッシュに一致するかどうかを決定する、
    ことにより前記トランザクション署名を検証する、請求項８に記載の方法。
  10. 前記チャレンジ解のハッシュは、前記シークレット被チャレンジャー鍵として使用され、前記チャレンジ鍵の前記独立インスタンスのハッシュは、前記シークレット被チャレンジャー鍵として使用される、請求項１～９のいずれかに記載の方法。
  11. 前記競争チャレンジは、前記ブロックチェーンネットワークと独立した１つ以上のサイドチャネルを介して競争する被チャレンジャーに通信される、請求項１～１０のいずれかに記載の方法。
  12. 前記少なくとも１つのチャレンジトランザクションは、前記競争チャレンジを前記競争する被チャレンジャーに通信する効果を有する、請求項１～１１のいずれかに記載の方法。
  13. ブロックチェーンネットワーク内に維持されるブロックチェーンに記録するためにトランザクションのセットを用いて知識証明を実行する、コンピュータにより実施される方法であって、前記方法は、
    被チャレンジャーにより、競争チャレンジを受信するステップであって、前記競争チャレンジは導出可能なチャレンジ解を有するが、前記チャレンジ解は前記被チャレンジャーに直接通信されず、前記被チャレンジャーは前記競争チャレンジから前記チャレンジ解の独立インスタンスを導出するよう１つ以上の他の被チャレンジャーと競争する、ステップと、
    を含み、
    前記被チャレンジャーが、前記他の１つ以上の被チャレンジャーのうちのいずれよりも前に、前記チャレンジ解の前記独立インスタンスを導出することに成功すると、前記被チャレンジャーは、そのデータを、被チャレンジャー装置において少なくとも１つのメッセージに署名するためにシークレット被チャレンジャー鍵として使用し、それにより、少なくとも１つのトランザクション署名を生成し、前記少なくとも１つのトランザクション署名及び前記少なくとも１つのメッセージを少なくとも１つの証明トランザクションの中で前記ブロックチェーンネットワークに提出し、それにより、前記ブロックチェーンネットワークのノードに、前記少なくとも１つのトランザクション署名が前記少なくとも１つの証明トランザクションにより示されるチャレンジトランザクションの署名チャレンジを満たすかどうかを決定させる、方法。
  14. 前記トランザクション署名は、楕円曲線デジタル署名アルゴリズム（ECDSA）を用いて生成され、前記被チャレンジャー鍵は、前記トランザクション署名を生成するために秘密鍵と関連して使用される一時鍵であり、前記秘密鍵は、前記チャレンジトランザクションにより指定されずに、前記被チャレンジャーにより自由に決定される、請求項１３に記載の方法。
  15. 前記トランザクション署名は、s部分のみで構成される、請求項１４に記載の方法。
  16. 前記トランザクション署名は、s部分及びr部分を含む、請求項１４に記載の方法。
  17. 前記チャレンジ解は、前記署名チャレンジを決定するときに前記被チャレンジャーに知られていない、請求項１に記載の方法。
JP2021569312A 2019-05-24 2020-05-13 知識証明 Pending JP2022533845A (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
GB1907394.9 2019-05-24
GBGB1907394.9A GB201907394D0 (en) 2019-05-24 2019-05-24 Knowledge proof
PCT/IB2020/054515 WO2020240320A1 (en) 2019-05-24 2020-05-13 Knowledge proof

Publications (1)

Publication Number Publication Date
JP2022533845A true JP2022533845A (ja) 2022-07-26

Family

ID=67385539

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2021569312A Pending JP2022533845A (ja) 2019-05-24 2020-05-13 知識証明

Country Status (8)

Country Link
US (1) US20220239486A1 (ja)
EP (2) EP3973661B1 (ja)
JP (1) JP2022533845A (ja)
KR (1) KR20220024124A (ja)
CN (1) CN113875185A (ja)
GB (1) GB201907394D0 (ja)
SG (1) SG11202112908VA (ja)
WO (1) WO2020240320A1 (ja)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB202108385D0 (en) * 2021-06-11 2021-07-28 Nchain Licensing Ag A computer implemented method and system
GB2618094A (en) * 2022-04-26 2023-11-01 Nchain Licensing Ag Blockchain transaction

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR3027177B1 (fr) * 2014-10-13 2016-11-04 Morpho Procede d'authentification d'un dispositif client aupres d'un serveur a l'aide d'un element secret
US11107048B2 (en) * 2017-04-17 2021-08-31 International Business Machines Corporation Providing out-of-band verification for blockchain transactions
US10530585B2 (en) * 2017-06-07 2020-01-07 Bar-Ilan University Digital signing by utilizing multiple distinct signing keys, distributed between two parties
US10761877B2 (en) * 2017-07-21 2020-09-01 Intel Corporation Apparatuses, methods, and systems for blockchain transaction acceleration
EP3662636B1 (en) * 2017-08-05 2022-07-20 Proclus Technologies Limited Method and system for securing blockchain with proof-of-transactions
WO2019052184A1 (zh) 2017-09-12 2019-03-21 上海蔚来汽车有限公司 电动汽车的自动换电系统
US10855473B1 (en) * 2017-12-15 2020-12-01 Wells Fargo Bank, N.A. Systems and methods for biometric electronic signature agreement and intention
EP3502941B1 (en) * 2017-12-19 2021-01-20 Riddle & Code GmbH Dongles and method for providing a digital signature

Also Published As

Publication number Publication date
EP3973661B1 (en) 2024-02-28
EP4333368A3 (en) 2024-05-15
CN113875185A (zh) 2021-12-31
WO2020240320A1 (en) 2020-12-03
US20220239486A1 (en) 2022-07-28
EP4333368A2 (en) 2024-03-06
SG11202112908VA (en) 2021-12-30
EP3973661A1 (en) 2022-03-30
GB201907394D0 (en) 2019-07-10
KR20220024124A (ko) 2022-03-03

Similar Documents

Publication Publication Date Title
EP3966998B1 (en) Hash function attacks
EP3966991B1 (en) Knowledge proof
EP3977673B1 (en) Blockchain transaction comprising runnable code for hash-based verification
US20220263664A1 (en) Blockchain transaction comprising runnable code for hash-based verification
US20220239501A1 (en) Knowledge proof
CN114747172A (zh) 加密链接身份
JP2022533845A (ja) 知識証明
TW202345545A (zh) 用於證明與驗證子金鑰真實性之技術
JP7516425B2 (ja) 知識証明
US20240243918A1 (en) Knowledge proof
WO2024041866A1 (en) Blockchain transaction
CN117941317A (zh) 生成区块链事务

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20230417

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20240410

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20240521