JP7750832B2 - ブロックチェーントランザクションを使用したアイデンティティ検証プロトコル - Google Patents

Description

本開示は、ブロックチェーントランザクションを使用して当事者のアイデンティティを検証するための方法に関する。

ブロックチェーンは、分散型データ構造の形態を指し、ブロックチェーンの複製コピーが、ピアツーピア（Ｐ２Ｐ）ネットワーク内の複数のノードの各々において維持される。ブロックチェーンは、データブロックのチェーンを含み、各ブロックは１つまたは複数のトランザクションを含む。各トランザクションは、１つまたは複数のブロックにまたがり得るシーケンス内の先行するトランザクションを指し示し得る。トランザクションは、「マイニング」として知られるプロセスによって新しいブロックに含まれるためにネットワークにサブミットされ得、このプロセスは、複数のマイニングノードの各々が、「プルーフオブワーク」を実行しようと競うこと、すなわち、ブロックに含まれるのを待っている保留中のトランザクションのプールに基づいて暗号パズルを解くことを伴う。

従来、ブロックチェーンにおけるトランザクションは、デジタル資産、すなわち価値の蓄蔵として機能するデータを伝達するために使用される。しかしながら、ブロックチェーンは、ブロックチェーンの上に追加の機能を重ねるために活用することもできる。例えば、ブロックチェーンプロトコルは、トランザクションの出力における追加のユーザデータの格納を可能にし得る。最新のブロックチェーンでは、単一のトランザクション内に格納可能な最大データ容量が増えており、より複雑なデータを組み込むことが可能である。例えば、これを使用して、ブロックチェーンに電子文書を格納したり、さらにはオーディオまたはビデオデータを格納したりすることができる。

ネットワーク内の各ノードは、フォワード、マイニング、および格納という３つの役割のうちのいずれか１つ、２つ、またはすべてを担うことができる。フォワーディングノードは、ネットワークのノード全体にトランザクションを伝搬する。マイニングノードは、ブロックへのトランザクションのマイニングを実行する。ストレージノードは各々が、ブロックチェーンのマイニングされたブロックのそれら自体のコピーを格納する。ブロックチェーンにトランザクションを記録させるために、当事者は、伝搬されるべきネットワークのノードのうちの１つにトランザクションを送信する。トランザクションを受信するマイニングノードは、トランザクションを新しいブロックにマイニングしようと競い合い得る。各ノードは、同じノードプロトコルを尊重するように構成され、そのノードプロトコルには、トランザクションが有効であるための１つまたは複数の条件が含まれる。無効なトランザクションは、伝搬もブロックへのマイニングもされない。トランザクションが妥当性確認（validate）され、それによってブロックチェーン上に受け入れられたと仮定すると、追加のユーザデータは、不変の公開記録としてＰ２Ｐネットワーク内のノードの各々に格納されたままになる。

システムにアクセスしようとする個人またはエンティティの検証が必要とされる様々なシステムへの多要素認証（ＭＦＡ）の導入が増えている。例えば、オンライン銀行口座にアクセスしようとするときにＭＦＡが使用され得る。ＭＦＡは、システムへのアクセスを必要とするエンティティが、通常はクレデンシャルの独立したカテゴリから、複数の認証方法を提供するよう求められる検証プロトコルである。通常、第１の要素はパスワードであり、もう１つの要素はバイオメトリックデータからＳＭＳテキストまで多岐にわたる。これらのＭＦＡ方式は、それらが利用されるシステムのセキュリティレベルを高めることが期待される。

２要素認証（２ＦＡ）は、ユーザのアイデンティティを検証、すなわち認証するために２つの異なる形態のクレデンシャルが必要とされるＭＦＡの一種を指す。２ＦＡの場合、一般にＳＭＳテキストが使用される。そのような実装形態では、パスワードをサブミットした後に、特定コードを含むＳＭＳテキストがユーザに送信される。次いで、ユーザは、このコードを第２の認証要素として使用する。そのようなシステムのセキュリティの前提は、悪意のある行為者が（ターゲットのパスワードに加えて）そのターゲットのＳＭＳ電話および／またはテキストにアクセスできる可能性が低いことである。

しかしながら、検証プロトコルへの２ＦＡの組込みの普及にもかかわらず、このような２ＦＡ設計には問題および脆弱性が存在する。一例として、ＳＩＭスワップ機会により攻撃者はターゲットの電話番号を盗むことができるため、ＳＭＳメッセージを傍受することができ、よって、認証コードを取得することができる。

したがって、多要素認証に関する現在の問題に対処する、改善されたより安全なプロトコル、特に、個人のアイデンティティを盗もうと試みる攻撃者による認証コードの傍受に対して脆弱でないプロトコルが必要である。

本明細書に開示される一態様によれば、第２の当事者が第１の当事者のアイデンティティを検証することを可能にするクレデンシャルを提供する方法が提供され、第１の当事者は第１の公開鍵に関連付けられ、第１の公開鍵は第三者に登録され、方法は、１つまたは複数の第１のクレデンシャルを第２の当事者に提供することと、要求トランザクションを取得することと、ここで、要求トランザクションは、ブロックチェーンネットワークの１つまたは複数のノードに送信され、ａ）第三者のそれぞれの秘密鍵に基づいて生成された署名を含む入力と、ｂ）第１の当事者の第２の公開鍵にロックされた出力とを含むブロックチェーントランザクションであり、第２の公開鍵は第１の公開鍵に基づき、確認トランザクションを生成することと、ここで、確認トランザクションは、要求トランザクションの出力を参照する入力と、第１の当事者の第２の公開鍵に対応する秘密鍵に基づいて生成された署名とを含むブロックチェーントランザクションであり、ブロックチェーンに含めるためにブロックチェーンネットワークの１つまたは複数のノードに確認トランザクションが送信されることを生じさせることとを含む。

公開鍵－秘密鍵ペアの暗号的性質により、正しい秘密鍵へのアクセスを有する当事者のみが、第三者に登録された対応する公開鍵を使用して検証可能な署名を生成することができる。したがって、署名された確認トランザクションは、第１の当事者のアイデンティティを検証するために使用可能なさらなる（例えば、第２の）クレデンシャル（または、認証要素）として機能する。要求トランザクションは、登録された公開鍵にロックされた出力を有するので、第１の当事者のみが、その出力をロック解除する（すなわち、使用する）トランザクション（確認トランザクション）を生成することができる。したがって、どの当事者であっても、第１の当事者が確認トランザクションを生成したかどうかを確認すべくチェックすることによって、第１の当事者のアイデンティティを検証することができる。当事者が確認トランザクションを生成することができない場合、それらは、正しい秘密鍵へのアクセスを有していないので、第１の当事者ではない。

自身の公開鍵を第三者に登録するために、第１の当事者は、自身の秘密鍵を共有する必要がないことに留意されたい（秘密という単語の所以である）。実際、第１の当事者は、自身の秘密鍵を他の当事者と共有する必要はない。したがって、提供される方法は、任意の認証コードなどの共有に依存しないので、そのようなコードを傍受し、それらを使用して自らを第１の当事者と偽る機会を攻撃者に与えない。

方法は、署名された確認トランザクションが第２のクレデンシャル（または、認証要素）である２ＦＡプロトコルの一部として使用され得る。しかしながら、より一般的には、この方法は、署名された確認トランザクションが第ｎのクレデンシャルである任意のＭＦＡプロトコルとして使用され得る。

例示的な例として、ユーザ（第１の当事者）が、商人（第２の当事者）の顧客であり得、自身の公開鍵を自身の銀行（第三者）に登録している場合がある。商人から購入しようとするとき、顧客は、第１のクレデンシャル、例えば、クレジットカード情報、名前および住所、連絡先番号などを商人に提供する。商人は、ユーザのアイデンティティを検証するように銀行に求め得、そして、銀行は、第１の当事者によって登録された公開鍵に支払い可能な要求トランザクションを生成する。公開鍵は、銀行のＫＹＣ（ｋｎｏｗ－ｙｏｕｒ－ｃｕｓｔｏｍｅｒ）プロトコルの一部として登録され得る。ユーザは、例えばブロックチェーンをスキャンすることによって要求トランザクションを取得し、次いで、署名された確認トランザクションを生成する。銀行は、登録された公開鍵に対応する秘密鍵を有する場合に第１の当事者のみが生成することができる署名で確認トランザクションが署名されていることを確認すると、取引相手のユーザが実際に第１の当事者であることを商人に通知する。次いで、商人およびユーザは、例えば、商品またはサービスの購入といったトランザクションを継続することができる。

別の例として、ユーザ（第１の当事者）が、オンラインプロバイダ（第２の当事者）によってホストされる自身の電子メールアカウントにアクセスしようとしている場合がある。まずユーザがユーザ名およびパスワードを提供し、それに応答して、要求トランザクションがブロックチェーンネットワークのノードにサブミットされる。要求トランザクションは、オンラインプロバイダによって生成され得る（この場合、第三者は第２の当事者である）か、または信頼できる第三者機関によって生成され得る。署名された確認トランザクションが生成されると、ユーザは自身の電子メールアカウントへのアクセを許可される。

本明細書に開示される別の態様によれば、第１の当事者のアイデンティティを検証する方法が提供され、第１の当事者は第１の公開鍵に関連付けられ、第１の公開鍵は第三者に登録され、方法は、第１の当事者のアイデンティティを検証する要求を受信することと、要求トランザクションを生成することと、ここで、要求トランザクションは、ａ）第三者のそれぞれの秘密鍵に基づいて生成された署名を含む入力と、ｂ）第１の当事者の第２の公開鍵にロックされた出力とを含むブロックチェーントランザクションであり、第２の公開鍵は第１の公開鍵に基づき、ブロックチェーンに含めるためにブロックチェーンネットワークの１つまたは複数のノードに要求トランザクションが送信されることを生じさせることと、ブロックチェーンに含めるために確認トランザクションがブロックチェーンネットワークの１つまたは複数のノードに送信されたかどうかを決定することとを含み、ここで、確認トランザクションは、要求トランザクションの出力を参照する入力と、第１の当事者の第２の公開鍵に対応する秘密鍵に基づいて生成された署名とを含むブロックチェーントランザクションである。

上述のように、要求トランザクションの出力は、登録された公開鍵にロックされる。例えば、出力は、Ｐ２ＰＫＨ（pay-to-public-key-hash）出力であり得、これは、使用トランザクションの入力が、登録された公開鍵と、登録された公開鍵に対応する秘密鍵を用いて生成された署名とを含むことを必要とする。第１の当事者のみが、そのような入力を正しく生成するために必要とされる秘密鍵の知識を有する。したがって、当事者（例えば、第２の当事者または第三者）は、要求トランザクションを使用する確認トランザクションがブロックチェーンネットワークにサブミットされているかどうかを決定することによって、第１の当事者であると報告するユーザのアイデンティティを検証することができる。以下で説明するように、第１の当事者のアイデンティティが検証されるために要求トランザクションおよび確認トランザクションがいずれもブロックチェーンに記録されてはならないことに留意されたい。

場合によっては、第２の当事者は、当事者のアイデンティティを検証するためのプロトコルの一部として独立した第三者（例えば、信頼できる第三者機関）を使用し得る。他の場合には、第２の当事者自体が、第１の当事者の公開鍵を登録する第三者であってもよい。

本開示の実施形態の理解を助け、そのような実施形態がどのように実施され得るかを示すために、単なる例として添付の図面を参照する。
ブロックチェーンを実装するためのシステムの概略ブロック図である。 ブロックチェーンに記録され得るトランザクションのいくつかの例を概略的に示す。 ブロックチェーンを実装するための別のシステムの概略ブロック図である。 出力ベースモデルのノードプロトコルにしたがってトランザクションを処理するためのノードソフトウェアの一部分の概略ブロック図である。 ブロックチェーントランザクションを使用して当事者のアイデンティティを検証するためのシステムの概略ブロック図である。 ブロックチェーントランザクションを使用して当事者のアイデンティティを検証するための別のシステムの概略ブロック図である。 ブロックチェーンから取得されるブロックチェーントランザクションを使用して当事者のアイデンティティを検証するための例示的な方法のシーケンス図である。 ブロックチェーンから取得されるブロックチェーントランザクションを使用して当事者のアイデンティティを検証するための別の例示的な方法のシーケンス図である。 トランザクションのメモリプール（メムプール（ｍｅｍｐｏｏｌ））から取得されるブロックチェーントランザクションを使用して当事者のアイデンティティを検証するための例示的な方法のシーケンス図である。 メムプール内の未確認トランザクションのチェーンを概略的に示す。 メムプール内のトランザクションに対する二重支出試行を概略的に示す。 メムプールが通信媒体としてどのように機能し得るかを概略的に示す。

例示的なシステムの概要
図１は、一般的にブロックチェーン１５０を実装するための例示的なシステム１００を示す。システム１００は、典型的にはインターネットなど広域インターネットワークであるパケット交換ネットワーク１０１を含む。パケット交換ネットワーク１０１は、パケット交換ネットワーク１０１内にピアツーピア（Ｐ２Ｐ）オーバーレイネットワーク１０６を形成するように構成された複数のノード１０４を含む。各ノード１０４は、ピアのコンピュータ機器を含み、ノード１０４のうちの異なるものが異なるピアに属する。各ノード１０４は、１つまたは複数のプロセッサ、例えば１つまたは複数の中央処理装置（ＣＰＵ）、アクセラレータプロセッサ、特定用途向けプロセッサおよび／またはフィールドプログラマブルゲートアレイ（ＦＰＧＡ）を備える処理装置を含む。各ノードはまた、メモリ、すなわち、１つまたは複数の非一時的コンピュータ可読媒体の形態のコンピュータ可読ストレージを備える。メモリは、１つまたは複数のメモリ媒体、例えば、ハードディスクなどの磁気媒体、ソリッドステートドライブ（ＳＳＤ）、フラッシュメモリもしくはＥＥＰＲＯＭなどの電子媒体、および／または光ディスクドライブなどの光学媒体を使用する１つまたは複数のメモリユニットを備え得る。

ブロックチェーン１５０は、データブロック１５１のチェーンを含み、ブロックチェーン１５０のそれぞれのコピーは、Ｐ２Ｐネットワーク１６０内の複数のノードの各々において維持される。チェーン内の各ブロック１５１は、１つまたは複数のトランザクション１５２を含み、この文脈におけるトランザクションは、データ構造の一種を指す。データ構造の性質は、トランザクションモデルまたは方式の一部として使用されるトランザクションプロトコルのタイプに依存する。所与のブロックチェーンは、典型的には、全体を通して１つの特定のトランザクションプロトコルを使用する。１つの一般的なタイプのトランザクションプロトコルでは、各トランザクション１５２のデータ構造は、少なくとも１つの入力と少なくとも１つの出力とを含む。各出力は、出力が暗号的にロックされている（ロック解除され、それによって償還または使用されるためにはそのユーザの署名を必要とする）ユーザ１０３に属するデジタル資産の量を表す額を指定する。各入力は、先行するトランザクション１５２の出力を指し示し、それによってトランザクションをリンクする。

ノード１０４のうちの少なくともいくつかは、トランザクション１５２をフォワードし、それによって伝搬するフォワーディングノード１０４Ｆの役割を引き受ける。ノード１０４のうちの少なくともいくつかは、ブロック１５１をマイニングするマイナー１０４Ｍの役割を引き受ける。ノード１０４のうちの少なくともいくつかは、ストレージノード１０４Ｓ（「フルコピー」ノードと呼ばれることもある）の役割を引き受け、その各々が、同じブロックチェーン１５０のそれぞれのコピーをそれぞれのメモリに格納する。各マイナーノード１０４Ｍはまた、ブロック１５１にマイニングされるのを待っているトランザクション１５２のプール１５４を維持する。所与のノード１０４は、フォワーディングノード１０４、マイナー１０４Ｍ、ストレージノード１０４Ｓ、またはこれらのうちの２つもしくはすべての任意の組合せであり得る。

所与の現在のトランザクション１５２ｊにおいて、入力（または各入力）は、トランザクションのシーケンスにおける先行するトランザクション１５２ｉの出力を参照するポインタを含み、この出力が現在のトランザクション１５２ｊにおいて償還または「使用」されるべきであることを指定する。一般に、先行するトランザクションは、プール１５４または任意のブロック１５１内の任意のトランザクションであり得る。先行するトランザクション１５２ｉは、現在のトランザクションが有効となるために存在および妥当性確認される必要があるが、先行するトランザクション１５２ｉは、現在のトランザクション１５２ｊが作成されるときまたはネットワーク１０６に送信されるときに必ずしも存在する必要はない。したがって、本明細書における「先行する（preceding）」は、ポインタによってリンクされた論理シーケンスにおける先行するものを指し、必ずしも時間シーケンスにおける作成または送信の時間を指すものではなく、したがって、トランザクション１５２ｉ、１５２ｊが順不同に作成または送信されることを必ずしも除外するものではない（オーファントランザクションに関する以下の説明を参照）。先行するトランザクション１５２ｉは、先のトランザクション（ａｎｔｅｃｅｄｅｎｔ ｔｒａｎｓａｃｔｉｏｎ）または先行したトランザクション（ｐｒｅｄｅｃｅｓｓｏｒ ｔｒａｎｓａｃｔｉｏｎ）とも呼ばれる。

現在のトランザクション１５２ｊの入力はまた、先行するトランザクション１５２ｉの出力がロックされるユーザ１０３ａの署名を含む。次に、現在のトランザクション１５２ｊの出力は、新しいユーザ１０３ｂに暗号的にロックされ得る。したがって、現在のトランザクション１５２ｊは、先行するトランザクション１５２ｉの入力において定義された額を、現在のトランザクション１５２ｊの出力において定義されたように、新しいユーザ１０３ｂに転送することができる。場合によっては、トランザクション１５２は、複数のユーザ（残り（ｃｈａｎｇｅ）を与えるためにそのうちの１人が元のユーザ１０３ａであり得る）間で入力額を分割するために複数の出力を有し得る。場合によっては、トランザクションはまた、１つまたは複数の先行するトランザクションの複数の出力からの額をまとめ、現在のトランザクションの１つまたは複数の出力に再分配するために複数の入力を有することができる。

上記は、「出力ベース」トランザクションプロトコルと称され得、未使用トランザクション出力（ＵＴＸＯ）タイププロトコルと称されることもある（ここでは出力はＵＴＸＯと称される）。ユーザの総残高は、ブロックチェーンに格納された任意の１つの数字で定義されるのではなく、代わりに、ユーザは、ブロックチェーン１５１内の多くの異なるトランザクション１５２全体に散在しているそのユーザのすべてのＵＴＸＯの値を照合するための特別な「ウォレット」アプリケーション１０５を必要とする。

トランザクションプロトコルの代替的なタイプは、アカウントベースのトランザクションモデルの一部として、「アカウントベース」プロトコルと称され得る。アカウントベースの場合、各トランザクションは、一連の過去のトランザクションにおける先行するトランザクションのＵＴＸＯを参照することによってではなく、絶対アカウント残高を参照することによって転送されるべき額を定義する。すべてのアカウントの現在の状態は、ブロックチェーンとは別にマイナーによって格納され、絶えず更新される。そのようなシステムでは、トランザクションは、アカウントの実行中のトランザクションタリー（「ポジション」とも呼ばれる）を使用して順序付けられる。この値は、送信者によってその暗号署名の一部として署名され、トランザクション参照計算の一部としてハッシュされる。加えて、トランザクションにおける任意選択のデータフィールドも署名することができる。このデータフィールドは、例えば、前のトランザクションＩＤがデータフィールドに含まれている場合、前のトランザクションを指し示し得る。

いずれかのタイプのトランザクションプロトコルを用いて、ユーザ１０３が新しいトランザクション１５２ｊを成立させることを望む場合、ユーザは新しいトランザクションをユーザのコンピュータ端末１０２からＰ２Ｐネットワーク１０６のノード１０４（これは、今日では典型的にはサーバまたはデータセンタであるが、原理的には他のユーザ端末であってもよい）のうちの１つに送信する。このノード１０４は、ノード１０４の各々において適用されるノードプロトコルにしたがってトランザクションが有効であるかどうかをチェックする。ノードプロトコルの詳細は、当該ブロックチェーン１５０において使用されているトランザクションプロトコルのタイプに対応し、全体としてトランザクションモデルを形成する。ノードプロトコルは、典型的には、新しいトランザクション１５２ｊ内の暗号署名が、トランザクション１５２の順序付けられたシーケンス内で前のトランザクション１５２ｉに依存する予想される署名と一致することをチェックするようにノード１０４に求める。出力ベースの場合、これは、新しいトランザクション１５２ｊの入力に含まれるユーザの暗号署名が、新しいトランザクションが使用する先行するトランザクション１５２ｉの出力において定義される条件と一致することをチェックすることを含み得、この条件は、典型的には、新しいトランザクション１５２ｊの入力における暗号署名が、新しいトランザクションの入力が指し示す前のトランザクション１５２ｉの出力をロック解除することをチェックすることを少なくとも含む。いくつかのトランザクションプロトコルでは、条件は、入力および／または出力に含まれるカスタムスクリプトによって少なくとも部分的に定義され得る。代替的に、単にノードプロトコルのみによって固定されてもよく、またはこれらの組合せによるものであってもよい。いずれにしても、新しいトランザクション１５２ｊが有効である場合、現在のノードは、それをＰ２Ｐネットワーク１０６内のノード１０４のうちの１つまたは複数の他のノードにフォワードする。これらのノード１０４のうちの少なくともいくつかは、フォワーディングノード１０４Ｆとしても機能し、同じノードプロトコルにしたがって同じテストを適用し、そして、新しいトランザクション１５２ｊを１つまたは複数のさらなるノード１０４にフォワードし、以下同様である。このようにして、新しいトランザクションはノード１０４のネットワーク全体に伝搬される。

出力ベースのモデルでは、所与の出力（例えば、ＵＴＸＯ）が使用されたかどうかの定義は、それがノードプロトコルにしたがって別の前方のトランザクション１５２ｊの入力によって有効に償還されたかどうかかである。トランザクションが有効であるための別の条件は、それが使用または償還しようとする先行する遷移１５２ｉの出力が、別の有効なトランザクションによってまだ使用／償還されていないことである。同様に、有効でない場合、トランザクション１５２ｊは、ブロックチェーンに伝搬も記録もされない。これは、使用者が同じトランザクションの出力を複数回使用しようとする二重支出を防止する。一方、アカウントベースのモデルは、アカウント残高を維持することによって二重支出を防止する。ここでも、トランザクション順序が定義されているので、アカウント残高は常に単一の定義された状態にある。

妥当性確認に加えて、ノード１０４Ｍのうちの少なくともいくつかはまた、「プルーフオブワーク」に支えられるマイニングとして知られるプロセスにおいてトランザクションのブロックを最初に作成しようと競い合う。マイニングノード１０４Ｍにおいて、ブロック内にまだ現れていない有効なトランザクションのプールに新しいトランザクションが追加される。次いで、マイナーは、暗号パズルを解くことを試みることによって、トランザクション１５４のプールからトランザクション１５２の新しい有効ブロック１５１を組み立てようと競い合う。典型的には、これは、ノンスがトランザクションのプール１５４と連結されハッシュされたときにハッシュの出力が所定の条件を満たすような「ノンス」値を探索することを含む。例えば、所定の条件とは、ハッシュの出力が特定の所定の数の先行ゼロを有することであり得る。ハッシュ関数の特性は、その入力に対して予測不可能な出力を持つことである。したがって、この探索は、総当たりでしか実行することができないので、パズルを解こうとしている各ノード１０４Ｍでかなりの量の処理リソースを消費する。

最初にパズルを解いたマイナーノード１０４Ｍは、これをネットワーク１０６に公表し、後にネットワーク内の他のノード１０４によって容易にチェックすることができるその解を証明として提供する（ハッシュに対する解が与えられると、ハッシュの出力が条件を満たすことをチェックすることは簡単である）。勝者がパズルを解いたトランザクション１５４のプールは、次いで、ストレージノード１０４Ｓとして機能するノード１０４のうちの少なくともいくつかによって、そのような各ノードにおいて勝者が公表した解をチェックしたことに基づいて、ブロックチェーン１５０内に新しいブロック１５１として記録されるようになる。ブロックポインタ１５５はまた、チェーン内の前に作成されたブロック１５１ｎ－１を指し示す新しいブロック１５１ｎに割り当てられる。プルーフオブワークは、新たなブロック１５１を作成するのに多大な労力を要するので、二重支出のリスクを低減するのに役立ち、二重支出を含むブロックは他のノード１０４によって拒絶される可能性が高いので、マイニングノード１０４Ｍは、二重支出がそれらのブロックに含まれないようにインセンティブが与えられる。ブロック１５１は、一旦作成されると、同じプロトコルにしたがってＰ２Ｐネットワーク１０６内の格納ノード１０４Ｓの各々で認識および維持されるので、修正することができない。ブロックポインタ１５５はまた、ブロック１５１にシーケンシャル順序を付与する。トランザクション１５２は、Ｐ２Ｐネットワーク１０６内の各ストレージノード１０４Ｓにおいて順序付けられたブロックに記録されるので、これは、トランザクションの不変の公開台帳を提供する。

任意の所与の時間にパズルを解こうと競い合う異なるマイナー１０４Ｍは、それらがいつ解を探索し始めたかに応じて、任意の所与の時間におけるマイニングされていないトランザクションプール１５４の異なるスナップショットに基づいてそうしている可能性があることに留意されたい。誰がそれぞれのパズルを最初に解いても、どのトランザクション１５２が次の新しいブロック１５１ｎに含まれるかを定義し、マイニングされていないトランザクションの現在のプール１５４が更新される。次いで、マイナー１０４Ｍは、新しく定義された未処理プール１５４からブロックを作成しようと競い合い続け、以下同様である。２人のマイナー１０４Ｍが互いに非常に短い時間内にパズルを解いて、ブロックチェーンの相反する見解が伝搬される場合に発生し得る任意の「フォーク」を解決するためのプロトコルも存在する。要するに、フォークのどちらのプロングが最も長く成長しても、最終的なブロックチェーン１５０となる。

ほとんどのブロックチェーンでは、勝利マイナー１０４Ｍには、（あるユーザから別のユーザにある額のデジタル資産を転送する通常のトランザクションとは対照的に）突如新しい量のデジタル資産を作成する特別なタイプの新しいトランザクションで自動的に報酬が与えられる。したがって、勝者ノードは、ある量のデジタル資産を「マイニング」したと言われる。この特別なタイプのトランザクションは、「生成」トランザクションと称されることがある。それは自動的に新しいブロック１５１ｎの一部を形成する。この報酬は、マイナー１０４Ｍがプルーフオブワーク競争に参加するためのインセンティブを与える。多くの場合、通常の（非生成）トランザクション１５２はまた、そのトランザクションが含まれたブロック１５１ｎを作成した勝利マイナー１０４Ｍにさらに報酬を与えるために、その出力の１つにおいて追加のトランザクション手数料を指定する。

マイニングに関与する計算リソースに起因して、典型的には、マイナーノード１０４Ｍの少なくとも各々は、１つまたは複数の物理サーバユニットを含むサーバの形態をとるか、またはデータセンタ全体の形態をとる。各フォワーディングノード１０４Ｍおよび／またはストレージノード１０４Ｓもまた、サーバまたはデータセンタの形態をとり得る。しかしながら、原則として、任意の所与のノード１０４は、一緒にネットワーク化されたユーザ端末またはユーザ端末のグループの形態をとることができる。

各ノード１０４のメモリは、そのそれぞれの１つまたは複数の役割を実行し、ノードプロトコルにしたがってトランザクション１５２を処理するために、ノード１０４の処理装置上で実行ように構成されたソフトウェアを記憶する。本明細書においてノード１０４に帰する任意のアクションは、それぞれのコンピュータ機器の処理装置上で実行されるソフトウェアによって実行され得ることが理解されよう。また、本明細書で使用される「ブロックチェーン」という用語は、一般に、この種類の技術を指す総称であり、任意の特定の専有のブロックチェーン、プロトコルまたはサービスに限定されない。

消費ユーザの役割を果たす複数の当事者１０３の各々のコンピュータ機器１０２もネットワーク１０１に接続されている。これらは、トランザクションにおいて支払人および受取人として機能するが、他の当事者に代わってトランザクションのマイニングまたは伝搬に必ずしも参加するわけではない。それらは、マイニングプロトコルを必ずしも実行するわけではない。２つの当事者１０３およびそれらのそれぞれの機器１０２、すなわち、第１の当事者１０３ａおよびそのそれぞれのコンピュータ機器１０２ａ、ならびに第２の当事者１０３ｂおよびそのそれぞれのコンピュータ機器１０２ｂは、例示の目的で示されている。はるかに多くのそのような当事者１０３およびそれらのそれぞれのコンピュータ機器１０２が存在し、システムに参加し得るが、便宜上、それらは図示されていないことが理解されよう。各当事者１０３は、個人または組織であり得る。純粋に例示として、第１の当事者１０３ａは、本明細書ではアリスと称され、第２の当事者１０３ｂはボブと称されるが、これは限定的なものではなく、本明細書におけるアリスまたはボブへのいかなる言及も、それぞれ「第１の当事者」および「第２の当事者」と置き換えられ得ることが理解されよう。

各当事者１０３のコンピュータ機器１０２は、１つまたは複数のプロセッサ、例えば、１つまたは複数のＣＰＵ、ＧＰＵ、他のアクセラレータプロセッサ、特定用途向けプロセッサ、および／またはＦＰＧＡを含むそれぞれの処理装置を含む。各当事者１０３のコンピュータ機器１０２は、メモリ、すなわち、１つまたは複数の非一時的コンピュータ可読媒体の形態のコンピュータ可読ストレージを備える。このメモリは、１つまたは複数のメモリ媒体、例えば、ハードディスクなどの磁気媒体、ＳＳＤ、フラッシュメモリもしくはＥＥＰＲＯＭなどの電子媒体、および／または光ディスクドライブなどの光学媒体を使用する１つまたは複数のメモリユニットを備え得る。各当事者１０３のコンピュータ機器１０２上のメモリは、処理装置上で実行するように構成された少なくとも１つのクライアントアプリケーション１０５のそれぞれのインスタンスを含むソフトウェアを記憶する。本明細書において所与の当事者１０３に帰する任意のアクションは、それぞれのコンピュータ機器１０２の処理装置上で実行されるソフトウェアを使用して実行され得ることが理解されよう。各当事者１０３のコンピュータ機器１０２は、少なくとも１つのユーザ端末、例えば、デスクトップもしくはラップトップコンピュータ、タブレット、スマートフォン、またはスマートウォッチなどのウェアラブルデバイスを備える。所与の当事者１０３のコンピュータ機器１０２はまた、ユーザ端末を介してアクセスされるクラウドコンピューティングリソースなどの１つまたは複数の他のネットワーク化されたリソースを備え得る。

クライアントアプリケーションまたはソフトウェア１０５は、最初に、適切な１つまたは複数のコンピュータ可読記憶媒体上で任意の所与の当事者１０３のコンピュータ機器１０２に提供され得、例えば、サーバからダウンロードされ得るか、またはリムーバブルＳＳＤ、フラッシュメモリキー、リムーバブルＥＥＰＲＯＭ、リムーバブル磁気ディスクドライブ、磁気フロッピーディスクもしくはテープ、ＣＤもしくはＤＶＤ ＲＯＭなどの光ディスク、またはリムーバブル光学ドライブなどのリムーバブル記憶デバイス上で提供され得る。

クライアントアプリケーション１０５は、少なくとも「ウォレット」機能を備える。これは２つの主要な機能を有する。これらのうちの１つは、それぞれのユーザ当事者１０３が、ノード１０４のネットワーク全体に伝搬され、それによってブロックチェーン１５０に含まれることとなるトランザクション１５２を作成し、署名し、送信することを可能にすることである。もう１つは、それぞれの当事者に、その当事者が現在所有しているデジタル資産の額を報告することである。出力ベースのシステムでは、この第２の機能は、当該当事者に属するブロックチェーン１５０全体に散在している様々なトランザクション１５２の出力において定義された額を照合することを含む。

各コンピュータ機器１０２上のクライアントアプリケーション１０５のインスタンスは、Ｐ２Ｐネットワーク１０６のフォワーディングノード１０４Ｆのうちの少なくとも１つに動作可能に結合される。これにより、クライアント１０５のウォレット機能はトランザクション１５２をネットワーク１０６に送信することができる。クライアント１０５はまた、それぞれの当事者１０３が受信者である任意のトランザクションについてブロックチェーン１５０にクエリを行うために、ストレージノード１０４のうちの１つ、いくつか、またはすべてにコンタクトすることができる（または、実施形態では、ブロックチェーン１５０は、部分的にその公開可視性を通じてトランザクションにおける信頼を提供する公開施設であるので、実際にブロックチェーン１５０における他の当事者のトランザクションを検査する）。各コンピュータ機器１０２上のウォレット機能は、トランザクションプロトコルにしたがってトランザクション１５２を定式化し、送信するように構成される。各ノード１０４は、ノードプロトコルにしたがってトランザクション１５２を妥当性確認するように構成されたソフトウェアを実行し、フォワーディングノード１０４Ｆの場合には、トランザクション１５２をネットワーク１０６全体に伝搬させるためにそれらをフォワードするように構成される。トランザクションプロトコルおよびノードプロトコルは互いに対応し、所与のトランザクションプロトコルは所与のノードプロトコルと共に進行し、一緒に所与のトランザクションモデルを実装する。ブロックチェーン１５０内のすべてのトランザクション１５２に対して同じトランザクションプロトコルが使用される（ただし、トランザクションプロトコルは、その中のトランザクションの異なるサブタイプを可能にし得る）。ネットワーク１０６内のすべてのノード１０４によって同じノードプロトコルが使用される（ただし、これは、トランザクションの異なるサブタイプを、そのサブタイプに対して定義された規則にしたがって異なって処理し、また、異なるノードが異なる役割を担い、したがってプロトコルの異なる対応する態様を実装することができる）。

述べたように、ブロックチェーン１５０は、ブロック１５１のチェーンを含み、各ブロック１５１は、前述したようなプルーフオブワークプロセスによって作成された１つまたは複数のトランザクション１５２のセットを含む。各ブロック１５１はまた、ブロック１５１へのシーケンシャル順序を定義するために、チェーン内の前に作成されたブロック１５１を指し示すブロックポインタ１５５を含む。ブロックチェーン１５０は、プルーフオブワークプロセスによって新しいブロックに含まれるのを待っている有効なトランザクション１５４のプールも含む。各トランザクション１５２（生成トランザクション以外）は、トランザクションのシーケンスへの順序を定義するように、前のトランザクションへ戻るポインタを含む（注意：トランザクション１５２のシーケンスは分岐することが可能である）。ブロック１５１のチェーンは、チェーン内の最初のブロックであった発生ブロック（Ｇｂ）１５３までずっと戻る。チェーン１５０内の早期にある１つまたは複数の元のトランザクション１５２は、先行するトランザクションではなく発生ブロック１５３を指し示していた。

所与の当事者１０３、例えばアリスが、ブロックチェーン１５０に含まれるべき新しいトランザクション１５２ｊを送信することを望むとき、アリスは、関連トランザクションプロトコルにしたがって（アリスのクライアントアプリケーション１０５内のウォレット機能を使用して）新しいトランザクションを定式化する。次いで、アリスは、クライアントアプリケーション１０５から、アリスが接続されている１つまたは複数のフォワーディングノード１０４Ｆのうちの１つにトランザクション１５２を送信する。例えば、これは、アリスのコンピュータ１０２に最も近いまたは最良に接続されたフォワーディングノード１０４Ｆであり得る。任意の所与のノード１０４が新しいトランザクション１５２ｊを受信すると、それはノードプロトコルおよびそのそれぞれの役割にしたがってそれを処理する。これは、新たに受信されたトランザクション１５２ｊが「有効」であるための特定の条件を満たすか否かを最初にチェックすることを含み、その例については、以下でより詳細に説明する。いくつかのトランザクションプロトコルでは、妥当性確認のための条件は、トランザクション１５２に含まれるスクリプトによってトランザクションごとに構成可能であり得る。代替的に、条件は、単にノードプロトコルの組込み特徴であってもよく、またはスクリプトとノードプロトコルとの組合せによって定義されてもよい。

新たに受信されたトランザクション１５２ｊが有効であると見なされるためのテストにパスすることを条件として（すなわち、それが「妥当性確認される」ことを条件として）、トランザクション１５２ｊを受信する任意のストレージノード１０４Ｓは、そのノード１０４Ｓにおいて維持されるブロックチェーン１５０のコピー内のプール１５４に新たな妥当性確認済みトランザクション１５２を追加する。さらに、トランザクション１５２ｊを受信する任意のフォワーディングノード１０４Ｆは、妥当性確認済みトランザクション１５２をＰ２Ｐネットワーク１０６内の１つまたは複数の他のノード１０４へと前方に伝搬する。各フォワーディングノード１０４Ｆは同じプロトコルを適用するので、トランザクション１５２ｊが有効であると仮定すると、これは、それがすぐにＰ２Ｐネットワーク１０６全体にわたって伝搬されることを意味する。

１つまたは複数のストレージノード１０４において維持されるブロックチェーン１５０のコピー内のプール１５４に認められると、マイナーノード１０４Ｍは、新しいトランザクション１５２を含むプール１５４の最新バージョンに対してプルーフオブワークパズルを解こうと競い始める（他のマイナー１０４Ｍは、プール１５４の古いビューに基づいてパズルを解こうと試みている可能性があるが、誰が最初に到達しても、次の新しいブロック１５１がどこで終わり新しいプール１５４がどこで開始するかを定義することとなり、最終的には、誰かが、アリスのトランザクション１５２ｊを含むプール１５４の一部についてパズルを解く）。新しいトランザクション１５２ｊを含むプール１５４に対してプルーフオブワークが行われると、それは不変的にブロックチェーン１５０内のブロック１５１のうちの１つの一部となる。各トランザクション１５２は、前のトランザクションへ戻るポインタを含むので、トランザクションの順序も不変的に記録される。

ＵＴＸＯベースのモデル
図２は、例示的なトランザクションプロトコルを示す。これは、ＵＴＸＯベースのプロトコルの一例である。トランザクション１５２（「Ｔｘ」と略記される）は、ブロックチェーン１５０の基本的なデータ構造である（各ブロック１５１は１つまたは複数のトランザクション１５２を含む）。以下では、出力ベースまたは「ＵＴＸＯ」ベースのプロトコルを参照して説明する。しかしながら、これはすべての可能な実施形態に限定されない。

ＵＴＸＯベースのモデルでは、各トランザクション（「Ｔｘ」）１５２は、１つまたは複数の入力２０２および１つまたは複数の出力２０３を含むデータ構造を含む。各出力２０３は、未使用トランザクション出力（ＵＴＸＯ）を含み得、これは、（ＵＴＸＯがまだ償還されていない場合）別の新しいトランザクションの入力２０２のソースとして使用され得る。ＵＴＸＯは、デジタル資産（価値の蓄蔵）の額を指定する。それはまた、他の情報の中でも、元となるトランザクションのトランザクションＩＤを含み得る。トランザクションデータ構造は、入力フィールド（複数可）２０２および出力フィールド（複数可）２０３のサイズを示すインジケータを含み得るヘッダ２０１も含み得る。ヘッダ２０１はまた、トランザクションのＩＤを含み得る。実施形態では、トランザクションＩＤは、（トランザクションＩＤ自体を除く）トランザクションデータのハッシュであり、マイナー１０４Ｍにサブミットされる生のトランザクション１５２のヘッダ２０１に格納される。

図２の各出力はＵＴＸＯとして示されているが、トランザクションは、追加的にまたは代替的に、１つまたは複数の使用不可能なトランザクション出力を含み得ることに留意されたい。

アリス１０３ａが、当該デジタル資産の額をボブ１０３ｂに転送するトランザクション１５２ｊを作成することを望むとする。図２では、アリスの新しいトランザクション１５２ｊは「Ｔｘ_１」とラベル付けされている。これは、シーケンス内の先行するトランザクション１５２ｉの出力２０３においてアリスにロックされたデジタル資産の額を取り、これのうちの少なくとも一部をボブに転送する。先行するトランザクション１５２ｉは、図２では「Ｔｘ_０」とラベル付けされている。Ｔｘ_０およびＴｘ_１は、単なる任意のラベルである。それらは、Ｔｘ_０がブロックチェーン１５１内の最初のトランザクションであることも、Ｔｘ_１がプール１５４内のすぐ次のトランザクションであることも必ずしも意味するものではない。Ｔｘ_１は、アリスにロックされた未使用の出力２０３を依然として有する任意の先行する（すなわち先の）トランザクションを指し示すことができる。

先行するトランザクションＴｘ_０は、アリスが新しいトランザクションＴｘ_１を作成した時点では、または少なくともアリスがそれをネットワーク１０６に送信する時点までには、すでに妥当性確認されブロックチェーン１５０に含まれている可能性がある。それは、その時点でブロック１５１のうちの１つにすでに含まれていてもよいし、プール１５４で依然として待機していてもよく、その場合には、すぐに新しいブロック１５１に含まれることになる。代替的に、Ｔｘ_０およびＴｘ_１を作成してネットワーク１０２に一緒に送信することができるか、またはノードプロトコルが「オーファン」トランザクションのバッファリングを可能にする場合には、Ｔｘ_０をＴｘ_１の後に送信することさえもできる。トランザクションのシーケンスの文脈において本明細書で使用される「先行する」および「後続の」という用語は、トランザクション内で指定されているトランザクションポインタ（どのトランザクションがどの他のトランザクションを指し示すかなど）によって定義されるシーケンス内のトランザクションの順序を指す。それらは、同様に、「先行するもの」および「後続するもの」、または「先の」および「後の」、「親」および「子」などと置き換えられ得る。これは、それらの作成、ネットワーク１０６への送信、または任意の所与のノード１０４への到着の順序を必ずしも意味するものではない。それにもかかわらず、先行するトランザクション（先のトランザクションまたは「親」）を指し示す後続するトランザクション（後のトランザクションまたは「子」）は、親トランザクションが妥当性確認されるまでおよび妥当性確認されない限り、妥当性確認されない。その親より前にノード１０４に到着する子は、オーファンとみなされる。それは、ノードプロトコルおよび／またはマイナー挙動に応じて、親を待つために特定の時間バッファされるかまたは破棄され得る。

先行するトランザクションＴｘ_０の１つまたは複数の出力２０３のうちの１つは、本明細書ではＵＴＸＯ_０とラベル付けされた特定のＵＴＸＯを含む。各ＵＴＸＯは、ＵＴＸＯによって表されるデジタル資産の額を指定する値と、ロックスクリプトとを含み、ロックスクリプトは、後続のトランザクションが妥当性確認され、したがってＵＴＸＯが正常に償還されるために、後続のトランザクションの入力２０２内のロック解除スクリプトが満たさなければならない条件を定義する。典型的には、ロックスクリプトは、その額を特定の当事者（それが含まれるトランザクションの受益者）にロックする。すなわち、ロックスクリプトは、典型的には、後続のトランザクションの入力内のロック解除スクリプトに、先行するトランザクションがロックされる当事者の暗号署名が含まれるという条件を含むロック解除条件を定義する。

ロックスクリプト（通称ｓｃｒｉｐｔＰｕｂＫｅｙ）は、ノードプロトコルによって認識されるドメイン固有言語で書かれたコードの一部分である。そのような言語の特定の例は、「スクリプト」（大文字Ｓ）と呼ばれる。ロックスクリプトは、トランザクション出力２０３を使用するためにどの情報が必要とされるか、例えばアリスの署名の要件を指定する。ロック解除スクリプトはトランザクションの出力に現れる。ロック解除スクリプト（通称ｓｃｒｉｐｔＳｉｇ）は、ロックスクリプト基準を満たすのに必要な情報を提供するドメイン固有言語で書かれたコードの一部分である。例えば、ボブの署名を含み得る。ロック解除スクリプトは、トランザクションの入力２０２に現れる。

つまり、図示の例では、Ｔｘ_０の出力２０３内のＵＴＸＯ_０は、ＵＴＸＯ_０が償還されるために（厳密には、ＵＴＸＯ_０を償還しようとする後続のトランザクションが有効となるために）アリスの署名Ｓｉｇ Ｐ_Ａを必要とするロックスクリプト［Ｃｈｅｃｋｓｉｇ Ｐ_Ａ］を含む。[Ｃｈｅｃｋｓｉｇ Ｐ_Ａ］は、アリスの公開鍵－秘密鍵ペアからの公開鍵Ｐ_Ａを含む。Ｔｘ_１の入力２０２は、（例えば、実施形態ではトランザクションＴｘ_０全体のハッシュであるそのトランザクションＩＤ、ＴｘＩＤ_０によって）Ｔｘ_１を指し示すポインタを含む。Ｔｘ_１の入力２０２は、Ｔｘ_０の任意の他の可能な出力の中から、ＵＴＸＯ_０を識別するために、Ｔｘ_０内のそれを識別するインデックスを含む。Ｔｘ_１の入力２０２は、アリスが鍵ペアからのアリスの秘密鍵をデータの所定の部分（暗号では「メッセージ」と呼ばれることもある）に適用することによって作成された、アリスの暗号署名を含むロック解除スクリプト＜Ｓｉｇ Ｐ_Ａ＞をさらに含む。有効な署名を提供するためにどのデータ（または「メッセージ」）がアリスによって署名される必要があるかは、ロックスクリプトによって、またはノードプロトコルによって、またはこれらの組合せによって定義され得る。

新しいトランザクションＴｘ_１がノード１０４に到着すると、ノードはノードプロトコルを適用する。これは、ロックスクリプトおよびロック解除スクリプトを一緒に実行して、ロック解除スクリプトがロックスクリプトで定義されている条件（この条件は１つまたは複数の基準を含み得る）を満たすかどうかをチェックすることを含む。実施形態では、これは２つのスクリプトを連結することを含む。
＜Ｓｉｇ Ｐ_Ａ＞＜Ｐ_Ａ＞｜｜［Ｃｈｅｃｋｓｉｇ Ｐ_Ａ］
ここで、「｜｜」は連結を表し、「＜…＞」はデータをスタックに置くことを意味し、「［…］」はロック解除スクリプト（この例ではスタックベースの言語）で構成される関数である。同等に、スクリプトは、スクリプトを連結するのではなく、共通スタックを用いて次々に実行され得る。いずれにしても、一緒に実行されるとき、スクリプトは、Ｔｘ_０の出力内のロックスクリプトに含まれるようなアリスの公開鍵Ｐ_Ａを使用して、Ｔｘ_１の入力内のロックスクリプトが、データの予想される部分に署名したアリスの署名を含むことを認証する。データの予想される部分自体（「メッセージ」）はまた、この認証を実行するためにＴｘ_０命令に含まれる必要がある。実施形態では、署名されたデータは、Ｔｘ_０の全体を含む（つまり、平文のデータの署名された部分を指定する別個の要素は、すでに本質的に存在するので、含まれる必要はない）。

公開－秘密暗号法による認証の詳細は、当業者によく知られている。基本的に、アリスが自身の秘密鍵でメッセージを暗号化することによってメッセージに署名した場合、アリスの公開鍵および平文のメッセージ（暗号化されていないメッセージ）が与えられると、ノード１０４などの別のエンティティは、メッセージの暗号化バージョンがアリスによって署名されたものに違いないことを認証することができる。署名は、典型的には、メッセージをハッシュし、ハッシュに署名し、これを署名としてメッセージの平文バージョンにタグ付けすることを含み、これにより、公開鍵の任意の保持者が署名を認証することができる。

Ｔｘ_１内のロック解除スクリプトが、Ｔｘ_０のロックスクリプト内で指定されている１つまたは複数の条件を満たす場合（つまり、図示の例では、アリスの署名がＴｘ_１内で提供され、認証された場合）、ノード１０４は、Ｔｘ_１が有効であると見なす。それがマイニングノード１０４Ｍである場合、これは、ワークオブプルーフを待つトランザクション１５４のプールにそれを追加することを意味する。それがフォワーディングノード１０４Ｆである場合、トランザクションＴｘ_１をネットワーク１０６内の１つまたは複数の他のノード１０４にフォワードして、トランザクションＴｘ_１がネットワーク全体に伝搬されるようにする。Ｔｘ_１が妥当性確認されてブロックチェーン１５０に含まれると、これは、Ｔｘ_０からのＵＴＸＯ_０を使用済みとして定義する。Ｔｘ_１は、未使用のトランザクション出力２０３を使用する場合にのみ有効であり得ることに留意されたい。別のトランザクション１５２によってすでに使用された出力を使用しようとする場合、Ｔｘ_１は、他のすべての条件が満たされたとしても無効になる。したがって、ノード１０４はまた、先行するトランザクションＴｘ_０内の参照されたＵＴＸＯがすでに使用済みである（別の有効なトランザクションへの有効な入力をすでに形成している）かどうかをチェックする必要がある。これは、ブロックチェーン１５０がトランザクション１５２に定義された順序を課すことが重要である１つの理由である。実際には、所与のノード１０４は、どのトランザクション１５２内のどのＵＴＸＯ２０３が使用されたかをマーキングする別個のデータベースを維持し得るが、最終的には、ＵＴＸＯが使用されたかどうかを定義するものは、ブロックチェーン１５０内の別の有効なトランザクションへの有効な入力をすでに形成しているかどうかである。

ＵＴＸＯベースのトランザクションモデルでは、所与のＵＴＸＯが全体として使用される必要があることに留意されたい。ＵＴＸＯにおいて使用済みとして定義された額の一部を「後に残す」ことはできず、別の一部が使用される。しかしながら、次のトランザクションの複数の出力間でＵＴＸＯからの額を分割することはできる。例えば、Ｔｘ_０内のＵＴＸＯ_０において定義された額は、Ｔｘ_１内の複数のＵＴＸＯ間で分割され得る。したがって、アリスが、ＵＴＸＯ_０において定義された額のすべてをボブに与えたくない場合、アリスは、リマインダを使用して、Ｔｘ_１の第２の出力において自分自身に残りを与えるか、または別の当事者に支払うことができる。

実際には、今日、生成トランザクションの報酬だけでは、典型的には、マイニングを動機付けるのに十分ではないので、アリスは通常、勝利マイナーに対する手数料を含む必要もある。アリスがマイナーに対する手数料を含めない場合、Ｔｘ_０は、マイナーノード１０４Ｍによって拒否される可能性が高く、したがって、技術的に有効であっても、それは依然として伝搬されず、ブロックチェーン１５０に含まれない（マイナープロトコルは、マイナー１０４Ｍが望まない場合にトランザクション１５２を受け入れることを強制しない）。いくつかのプロトコルでは、マイニング手数料は、それ自体の別個の出力２０３を必要としない（すなわち、別個のＵＴＸＯを必要としない）。代わりに、所与のトランザクション１５２の入力（複数可）２０２によって指し示される総額と出力（複数可）２０３で指定されている総額との間の差が自動的に勝利マイナー１０４に与えられる。例えば、ＵＴＸＯ_０へのポインタがＴｘ_１への唯一の入力であり、Ｔｘ_１は唯一の出力ＵＴＸＯ_１を有するとする。ＵＴＸＯ_０で指定されているデジタル資産の額がＵＴＸＯ_１で指定されている額より大きい場合、その差が自動的に勝利マイナー１０４Ｍに贈られる。しかしながら、代替的にまたは追加的に、マイナー手数料がトランザクション１５２のＵＴＸＯ２０３のうちのそれ自体の１つにおいて明示的に指定され得ることが必ずしも除外されるものではなない。

所与のトランザクション１５２のすべての出力２０３で指定されている総額が、そのすべての入力２０２によって指し示された総額よりも大きい場合、これは、ほとんどのトランザクションモデルにおいて無効性の別の根拠であることにも留意されたい。したがって、そのようなトランザクションは、ブロック１５１に伝搬もマイニングもされない。

アリスおよびボブのデジタル資産は、ブロックチェーン１５０内のどこにでもある任意のトランザクション１５２においてそれらにロックされた未使用ＵＴＸＯから構成される。したがって、典型的には、所与の当事者１０３の資産は、ブロックチェーン１５０全体にわたる様々なトランザクション１５２のＵＴＸＯ全体に散在している。ブロックチェーン１５０内のどこにも、所与の当事者１０３の総残高を定義する数字は格納されない。クライアントアプリケーション１０５におけるウォレット機能の役割は、それぞれの当事者にロックされ、別の前方のトランザクションでまだ使用されていない様々なＵＴＸＯすべての値を一緒に照合することである。これは、ストレージノード１０４Ｓのいずれか、例えば、それぞれの当事者のコンピュータ機器１０２に最も近いまたは最良に接続されたストレージノード１０４Ｓに格納されたブロックチェーン１５０のコピーにクエリを行うことによって行うことができる。

スクリプトコードは、しばしば、概略的に表される（すなわち、正確な言語ではない）ことに留意されたい。例えば、［Ｃｈｅｃｋｓｉｇ Ｐ_Ａ］と書いて［Ｃｈｅｃｋｓｉｇ Ｐ_Ａ］＝ＯＰ＿ＤＵＰ ＯＰ＿ＨＡＳＨ１６０＜Ｈ（Ｐａ）＞ＯＰ＿ＥＱＵＡＬＶＥＲＩＦＹ ＯＰ＿ＣＨＥＣＫＳＩＧを意味し得る。「ＯＰ＿…」は、スクリプト言語の特定のオペコードを指す。ＯＰ＿ＣＨＥＣＫＳＩＧ（「Ｃｈｅｃｋｓｉｇ」とも呼ばれる）は、２つの入力（署名および公開鍵）を取り、楕円曲線デジタル署名アルゴリズム（ＥＣＤＳＡ）を使用して署名の有効性を検証するスクリプトオペコードである。実行時に、署名（「ｓｉｇ」）の存在（occurrence）はスクリプトから除去されるが、ハッシュパズルなどの追加要件は、「ｓｉｇ」入力によって検証されたトランザクションに残る。別の例として、ＯＰ＿ＲＥＴＵＲＮは、トランザクション内にメタデータを格納することができ、それによってメタデータをブロックチェーン１５０に不変に記録することができる、トランザクションの使用不可能な出力を作成するためのスクリプト言語のオペコードである。例えば、メタデータは、ブロックチェーンに格納することが望まれる文書を含み得る。

署名Ｐ_Ａはデジタル署名である。実施形態において、これは、楕円曲線ｓｅｃｐ２５６ｋ１を使用するＥＣＤＳＡに基づく。デジタル署名は、特定のデータの一部分に署名する。実施形態では、所与のトランザクションについて、署名は、トランザクション入力の一部、およびトランザクション出力の全部または一部に署名する。署名された出力の特定の部分は、ＳＩＧＨＡＳＨフラグに依存する。ＳＩＧＨＡＳＨフラグは、どの出力が署名されるかを選択するために署名の最後に含まれる４バイトコードである（したがって、署名時に固定される）。

ロックスクリプトは、それぞれのトランザクションがロックされる当事者の公開鍵を含むという事実を指して、「ｓｃｒｉｐｔＰｕｂＫｅｙ」と呼ばれることがある。ロック解除スクリプトは、それが対応する署名を供給するという事実を指して「ｓｃｒｉｐｔＳｉｇ」と呼ばれることがある。しかしながら、より一般的には、ＵＴＸＯが償還されるための条件が署名を認証することを含むことは、ブロックチェーン１５０のすべてのアプリケーションにおいて必須ではない。より一般的には、スクリプト言語を使用して、任意の１つまたは複数の条件を定義することができる。したがって、より一般的な用語「ロックスクリプト」および「ロック解除スクリプト」が好まれ得る。

任意選択のサイドチャネル
図３は、ブロックチェーン１５０を実装するためのさらなるシステム１００を示す。システム１００は、追加の通信機能が含まれることを除いて、図１に関連して説明したものと実質的に同じである。アリスおよびボブのそれぞれのコンピュータ機器１０２ａ、１２０ｂ上のクライアントアプリケーションは、それぞれ、追加の通信機能を含む。すなわち、これは、（いずれかの当事者または第三者の指示で）アリス１０３ａがボブ１０３ｂとの別個のサイドチャネル３０１を確立することを可能にする。サイドチャネル３０１は、Ｐ２Ｐネットワークとは別でのデータの交換を可能にする。このような通信は、「オフチェーン」と称されることがある。例えば、これは、当事者の一方がトランザクションをネットワーク１０６にブロードキャストすることを選択するまで、トランザクションが（まだ）ネットワークＰ２Ｐ１０６上に公開されたりチェーン１５０上に進んだりすることなくことなく、アリスとボブとの間でトランザクション１５２を交換するために使用され得る。代替的にまたは追加的に、サイドチャネル３０１は、鍵、交渉された額または条件、データコンテンツなどの任意の他のトランザクション関連データを交換するために使用され得る。

サイドチャネル３０１は、Ｐ２Ｐオーバーレイネットワーク１０６と同じパケット交換ネットワーク１０１を介して確立され得る。代替的にまたは追加的に、サイドチャネル３０１は、モバイルセルラーネットワークなどの異なるネットワーク、またはローカルワイヤレスネットワークなどのローカルエリアネットワーク、またはさらにはアリスのデバイス１０２１とボブのデバイス１０２ｂとの間の直接の有線またはワイヤレスリンクを介して確立され得る。一般に、本明細書のどこかで参照されるサイドチャネル３０１は、「オフチェーン」すなわちＰ２Ｐオーバーレイネットワーク１０６とは別でデータを交換するための１つまたは複数のネットワーキング技術または通信媒体を介した任意の１つまたは複数のリンクを含み得る。２つ以上のリンクが使用される場合、全体としてのオフチェーンリンクの束または集合は、サイドチャネル３０１と称され得る。したがって、アリスおよびボブがサイドチャネル３０１上で情報またはデータの特定の部分などを交換すると言われている場合、これは、これらのデータの部分のすべてが全く同じリンクまたは同じタイプのネットワーク上で送信されなければならないことを必ずしも意味するものではないことに留意されたい。

ノードソフトウェア
図４は、ＵＴＸＯまたは出力ベースのモデルの例において、Ｐ２Ｐネットワーク１０６の各ノード１０４上で実行されるノードソフトウェア４００の例を示す。ノードソフトウェア４００は、プロトコルエンジン４０１と、スクリプトエンジン４０２と、スタック４０３と、アプリケーションレベル決定エンジン４０４と、１つまたは複数のブロックチェーン関連機能モジュール４０５のセットとを含む。任意の所与のノード１０４において、これらは、マイニングモジュール４０５Ｍ、フォワーディングモジュール４０５Ｆ、および格納モジュール４０５Ｓ（ノードの１つまたは複数の役割に応じて）のうちのいずれか１つ、２つ、または３つすべてを含み得る。プロトコルエンジン４０１は、トランザクション１５２の異なるフィールドを認識し、ノードプロトコルにしたがってそれらを処理するように構成される。別の先行するトランザクション１５２ｍ－１（Ｔｘ_ｍ－１）の出力（例えば、ＵＴＸＯ）を指し示す入力を有するトランザクション１５２ｍ（Ｔｘ_ｍ）が受信されると、プロトコルエンジン４０１は、Ｔｘ_ｍ内のロック解除スクリプトを識別し、それをスクリプトエンジン４０２に渡す。プロトコルエンジン４０１はまた、Ｔｘ_ｍの入力内のポインタに基づいて、Ｔｘ_ｍ－１を識別し、取り出す。それは、Ｔｘ_ｍ－１がまだブロックチェーン１５０上にない場合には保留中のトランザクションのそれぞれのノード自体のプール１５４から、またはＴｘ_ｍ－１がすでにブロックチェーン１５０上にある場合にはそれぞれのノードまたは別のノード１０４に格納されたブロックチェーン１５０内のブロック１５１のコピーからＴｘ_ｍ－１を取り出し得る。いずれにしても、スクリプトエンジン４０１は、Ｔｘ_ｍ－１の指し示された出力におけるロックスクリプトを識別し、これをスクリプトエンジン４０２に渡す。

したがって、スクリプトエンジン４０２は、Ｔｘ_ｍ－１のロックスクリプトと、Ｔｘ_ｍの対応する入力からのロック解除スクリプトとを有する。例えば、Ｔｘ_１およびＴｘ_２が図４に示されているが、同じことが、Ｔｘ_０とＴｘ_１などの任意のペアのトランザクションにも当てはまる。スクリプトエンジン４０２は、前述したように２つのスクリプトを一緒に実行し、これは、使用されているスタックベースのスクリプト言語（例えば、Ｓｃｒｉｐｔ）にしたがって、スタック４０３上にデータを配置し、そこからデータを取り出すことを含む。

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

出力ベースのモデルでは、スクリプトエンジン４０２からの結果「真」は、トランザクションの有効性の条件のうちの１つである。典型的には、Ｔｘ_ｍの出力（複数可）で指定されているデジタル資産の総額が入力（複数可）によって指し示された総額を超えないこと、およびＴｘ_ｍ－１の指し示された出力が別の有効なトランザクションによってまだ使用されていないことなど、同様に満たされなければならないプロトコルエンジン４０１によって評価される１つまたは複数のさらなるプロトコルレベル条件も存在する。プロトコルエンジン４０１は、スクリプトエンジン４０２からの結果を１つまたは複数のプロトコルレベル条件と共に評価し、それらがすべて真である場合にのみ、トランザクションＴｘ_ｍを妥当性確認する。プロトコルエンジン４０１は、トランザクションが有効であるかどうかの指示をアプリケーションレベル決定エンジン４０４に出力する。Ｔｘ_ｍが実際に妥当性確認されるという条件でのみ、決定エンジン４０４は、Ｔｘ_ｍに関してそれぞれのブロックチェーン関連機能を実行するために、マイニングモジュール４０５Ｍおよびフォワーディングモジュール４０５Ｆの一方または両方を制御することを選択し得る。これは、マイニングモジュール４０５Ｍが、ブロック１５１にマイニングするためにＴｘ_ｍをノードのそれぞれのプール１５４に追加すること、および／またはフォワーディングモジュール４０５ＦがＴｘ_ｍをＰ２Ｐネットワーク１０６内の別のノード１０４にフォワードすることを含み得る。しかしながら、実施形態では、決定エンジン４０４は無効なトランザクションをフォワードまたはマイニングすることを選択しないが、これは、逆に、単に有効であるという理由で有効なトランザクションのマイニングまたはフォワードをトリガする義務があることを必ずしも意味するものではないことに留意されたい。任意選択で、実施形態では、決定エンジン４０４は、一方または両方の機能をトリガする前に、１つまたは複数の追加の条件を適用することができる。例えば、ノードがマイニングノード１０４Ｍである場合、決定エンジンは、トランザクションが有効であり、かつ十分なマイニング手数料を残しているという条件でのみトランザクションをマイニングすることを選択し得る。

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

アイデンティティ検証プロトコル
ＳＭＳテキストを介した２ＦＡは、データおよびシステムのセキュリティを強化するために利用が増加しているプロトコルである。民間および公共システムの継続的な違反ならびにますます厳しくなるデータ規制により、会社は、２ＦＡプロトコルを介して顧客のデータおよびサービスを保護するために、顧客に対して電話番号の提供を奨励または強制するようになってきている。この電話番号を用いて、初期要素（例えば、パスワードログイン）を提供した後、英数字値を含むＳＭＳが顧客の電話に送信される。次いで、顧客は、この追加の値をシステムログインに入力し、正しければ、顧客は「認証」され、アクセスが与えられる。システムのセキュリティは、悪意のある行為者が顧客のパスワードの知識を有し、かつ顧客の電話を所持している可能性が低いという前提に基づく。しかしながら、そのようなシステムにはいくつかの脆弱性および欠点があることが分かっている。１つの脆弱性は、攻撃者が公開情報（例えば、名前および住所）を使用して偽の身分証明書を作成し、次いでその身分証明書を電話プロバイダの店舗で使用して電話の所有者になりすます「ＳＩＭスワッピング」として知られている。これにより、攻撃者は、所有者の電話番号を有する新しいＳＩＭカードを発行してもらうことができるため、攻撃者が英数字値を含むＳＭＳテキストを傍受することができるようになる。

概説した欠点は、本明細書で説明する提案されたアイデンティティ検証プロトコルによって対処される。ブロックチェーンの使用により、携帯電話操作の仲介者が必要なくなり、ブロックチェーンの透明性により、何らかの理由で悪意のある行為者がユーザの秘密鍵を盗むことができた場合に、盗まれた秘密鍵を使用して生成されたトランザクションがブロックチェーン上に不変的に文書化され、詐欺の場合の証拠として使用され得る。

２ＦＡの別の既知の例は、ユーザ（または悪意のある行為者）が認証器アプリケーションを実行する物理デバイスへのアクセスを必要とする２段階検証サービスを実装するソフトウェアベースの認証器である。そのような認証器は、ＳＭＳベースのプロトコルに勝るいくつかの利点を有する一方で、集中システムの利用可能性への依存およびフィッシングに対する感受性などの欠点を有する。対照的に、アイデンティティ検証プロトコルは、分散型システム（ブロックチェーンネットワーク）を利用し、結果として、いずれか１つのノードが故障してもシステムが利用不可能にならないようにする。

以下で説明するように、本開示の実施形態は、クレデンシャルを検証するものとして第１の当事者が署名されたブロックチェーントランザクションを使用することを可能にするとともに、第１の当事者のアイデンティティを検証するために第２の当事者および／または第三者がそれらの署名されたブロックチェーントランザクションを使用することを可能にするアイデンティティ検証プロトコルを提供する。実施形態は、マルチファクタ認証プロトコルの一部として使用され得る。

図５は、アイデンティティ検証プロトコルを実装するための例示的なシステム５００を示す。システムは、第１の当事者５０１と第２の当事者５０２（図５では「ユーザ」および「アクセス権限者」と呼ばれる）とを含む。第１の当事者５０１は、ブロックチェーントランザクション１５２を生成してブロックチェーンネットワーク１０６に送信するとともに、例えばブロックチェーン１５０からブロックチェーントランザクション１５２を取得するように構成されたクライアントアプリケーションを含むそれぞれのコンピュータ機器を操作する。例えば、第１の当事者は、図１～図３を参照して説明したように、ウォレットアプリケーション１０５ａを操作するアリス１０３ａの役割を果たし得る。図５の例では、第２の当事者５０２はまた、ブロックチェーントランザクション１５２を生成してブロックチェーンネットワーク１０６に送信するとともに、例えばブロックチェーン１５０からブロックチェーントランザクション１５２を取得するように構成されたクライアントアプリケーションを含むそれぞれのコンピュータ機器を操作する。その場合、第２の当事者５０２は、図１～図３を参照して説明したように、ウォレットアプリケーション１０５ｂを操作するボブ１０３ｂの役割を果たし得る。第１の当事者５０１および第２の当事者５０２は、アリス１０３ａおよびボブ１０３ｂの両方のアクションの一部またはすべてを実行し得ることは理解されよう。すなわち、原則として、第１の当事者５０１および第２の当事者５０２は、同じブロックチェーン関連能力を有し得、命名規則は、例示目的のみのために使用される。

第２の当事者５０２は、「アクセス権限者」として機能し、すなわち、リソースまたはサービスへのアクセスを制御する。例えば、第２の当事者５０２は、物理的なリソース、例えば物理的な製品、またはデジタルリソース、例えばデジタルチケット、投票、トークンなどへのアクセスを制御し得る。サービスの例には、例えば銀行口座、電子メールアカウント、オンライン小売アカウントなどのオンラインアカウント、デジタルストリーミングサービスなどが含まれる。第２の当事者５０２は、小売業者、会社、大学、慈善団体などであり得る。第１の当事者５０１は、顧客、従業員、学生、寄付者などであり得る。

一例として、第２の当事者５０２は、不動産の所有者であり得、第１の当事者５０１は、週末にその不動産にアクセスするために第２の当事者５０２に支払った行楽客であり得る。

第１の当事者５０１は、公開鍵を第２の当事者に登録する。上述したように、公開鍵（および公開鍵－秘密鍵ペア）は当業者によく知られている。例えば、第１の当事者５０１は、第２の当事者５０２との最初の対話中に、例えば、ＫＹＣプロトコルまたはアカウント設定の一部として、公開鍵を登録し得る。

図５に示すように、第１の当事者５０１は、第２の当事者５０２に１つまたは複数の第１のクレデンシャル（１－ＦＡ）を提供する。例えば、第１のクレデンシャルは、ユーザ名、パスワード、クレジットカード、氏名、住所、運転免許証、パスポート、メモラブルワード、キーカードなどであり得る。第１のクレデンシャル（複数可）は、有線またはワイヤレス接続５０３、例えば、図３を参照して説明したサイドチャネル３０１上で第２の当事者５０２に提供され得る。例えば、第１の当事者は、電子メール、ＳＭＳテキスト、Ｗｉ－Ｆｉ、Ｂｌｕｅｔｏｏｔｈ、ＮＦＣなどを介して第１のクレデンシャル（複数可）を第２の当事者に送信し得る。第１のクレデンシャル（複数可）は、例えばオンライン購入またはアカウントログインの一部として、第２の当事者５０２からのチャレンジ（または要求）に応答して提供され得る。代替的に、第１の当事者５０１は、直接要求を受信することなく、第１のクレデンシャル（複数可）を第２の当事者５０２に提供し得る。例えば、第１の当事者５０１が行楽客である例を続けると、第１の当事者５０１は、不動産への入り口においてキーカードまたはコード（第１のクレデンシャル）を提示し得る。

第１のクレデンシャル（複数可）の受信に応答して、第２の当事者５０２は、要求トランザクションＴｘ_ｒｔを生成し、ブロックチェーンネットワーク１０６に要求トランザクションＴｘ_ｒｔが送信されることを生じさせる。例えば、第２の当事者５０２は、要求トランザクションＴｘ_ｒｔをネットワーク１０６の１つまたは複数のノードに送信するか、または要求トランザクションＴｘ_ｒｔをネットワーク１０６に送信する異なるエンティティに送信する。要求トランザクションＴｘ_ｒｔは、少なくとも第１の入力および第１の出力を含む。要求トランザクションＴｘ_ｒｔは、追加の入力および／または出力を含んでもよい。第１の入力は、第２の当事者５０２の署名を含む。すなわち、第２の当事者５０２は、第１の当事者５０１または一般公衆に知られている公開鍵に対応し得る第２の当事者５０２の秘密鍵を使用して生成された署名でトランザクションに署名する。第１の出力は、第１の当事者５０１の登録された公開鍵にロックされるため、それをロック解除して償還または使用するためには、第１の当事者５０１の登録された公開鍵に対応する秘密鍵を使用して生成された署名が必要となる。

出力は、登録された公開鍵のハッシュ（公開鍵ハッシュ）を含むＰ２ＰＫＨ出力であり得る。Ｐ２ＰＫＨ出力を使用するために、使用トランザクションの入力は、公開鍵のハッシュ（例えば、ＯＰ＿ＨＡＳＨ１６０）がＰ２ＰＫＨ出力内の公開鍵ハッシュと一致するような公開鍵を含まなければならない。言い換えれば、Ｐ２ＰＫＨ出力は、必ずしもその順序ではないが、公開鍵のハッシュがＰ２ＰＫＨ出力内のアドレスと一致するような公開鍵と、公開鍵およびトランザクションメッセージに対して有効である署名という２つのアイテムを提供するように、使用者にチャレンジする。

第１の当事者５０１は、第２の当事者５０２から要求トランザクションＴｘ_ｒｔを取得し得る。しかしながら、好ましくは、第１の当事者は、ブロックチェーン１５０またはブロックチェーンネットワーク１０６のメムプールをスキャンすることによって要求トランザクションＴｘ_ｒｔを取得する。トランザクションがネットワーク上で行われると、それは送信され、マイニングノードがそれを次のブロック１５１に含めるまで、メムプール（メモリプール）として知られているものに保持される。ネットワーク１０６上の各ノードは、それら自体のメムプールを動作させる。要求トランザクションＴｘ_ｒｔは、公開鍵または公開鍵アドレスに支払い可能なＵＴＸＯについてブロックチェーンまたはメムプールをスキャンすることによって取得され得る。言い換えれば、第１の当事者のウォレットアプリケーションは、その登録された公開鍵または登録された公開鍵のハッシュに支払い可能なトランザクションについてブロックチェーンまたはメムプールをスキャンする。

要求トランザクションＴｘ_ｒｔを取得すると、第１の当事者５０１は、確認トランザクションＴｘ_ｃｔを生成する。確認トランザクションＴｘ_ｃｔは、要求トランザクションＴｘ_ｒｔの出力を使用する。すなわち、第１の当事者５０１の登録された公開鍵にロックされた要求トランザクションＴｘ_ｒｔの出力を参照する。要求トランザクションＴｘ_ｒｔの出力を使用するために、確認トランザクションＴｘ_ｃｔの入力は、登録された公開鍵に対応する秘密鍵を使用して生成された署名を含む。要求トランザクションＴｘ_ｒｔの出力のタイプに応じて、入力はまた、登録された公開鍵を含み得る。これは、出力がＰ２ＰＫＨ出力である場合である。確認トランザクションＴｘ_ｃｔは、第２の当事者５０２、第１の当事者５０１、または異なる当事者にロックされ得る出力を含む。好ましくは、出力は第２の当事者５０２にロックされ、その結果、第２の当事者（すなわち、第２の当事者のウォレットアプリケーション）は、第２の当事者５０２の公開鍵（またはそのハッシュ）に支払い可能なＵＴＸＯについてブロックチェーンまたはメムプールをスキャンすることができる。

確認トランザクションＴｘ_ｃｔの取得に応答して、および任意選択で任意のさらなる検証ステップに加えて、第２の当事者５０２は、第１の当事者５０１にリソースまたはサービスへのアクセスを許可する。

したがって、ブロックチェーン１５０またはメムプール内の確認トランザクションＴｘ_ｃｔの存在は、第１の当事者５０１のアイデンティティを検証するための追加のクレデンシャルまたは認証要素として機能する。

図６は、アイデンティティ検証プロトコルを実装するための別の例示的なシステム６００を示す。図６のシステムは、第三者（「信頼できる第三者機関」と称される）６０１を含む。この例では、第２の当事者（アクセス権限者）５０２は、リソースまたはサービスへのアクセスを依然として制御するが、第１の当事者５０１の公開鍵の登録および要求トランザクションの生成に対する責任は、第三者６０１に委任される。第三者６０１は、認証局、例えば公開鍵を証明することを託された当事者であってもよい。例えば、第三者は、個人に対して厳密な初期アイデンティティチェックを行って、個人をそれらの公開鍵とリンクさせることができる。一例として、第三者６０１は、第１の当事者５０１と対面会議を行って、それらが公文書、例えばパスポートまたは運転免許証と一致することをチェックし得る。

この例では、第２の当事者５０２は、ブロックチェーンネットワークにアクセスするように構成されたコンピュータ機器を操作してもしなくてもよく、一方、第三者６０１は、ブロックチェーントランザクション１５２を生成してブロックチェーンネットワーク１０６に送信するとともに、例えばブロックチェーン１５０からブロックチェーントランザクション１５２を取得するように構成されたクライアントアプリケーションを含むそれぞれのコンピュータ機器を操作する。事実上、第三者６０１は、図１～図３を参照して説明したアリス１０３ａまたはボブ１０３ｂに帰するアクションの一部またはすべてを実行し得る。

図５の例では、後述する第三者６０１に帰するアクションは、第２の当事者５０２によって実行され得、すなわち、この例では、第２の当事者５０２および第三者６０１は同じ当事者であることに留意されたい。

第１の当事者５０１は、例えば上記第１のクレデンシャル（複数可）に対する要求に応答して、１つまたは複数の第１のクレデンシャルを第２の当事者５０２に提供する。第２の当事者は、第１の当事者５０１であると報告するユーザのアイデンティティを検証するために、要求（２ＦＡ－要求）を第三者６０１に送信する。２ＦＡ－要求は、サイドチャネル５０４、例えばインターネットを介して、またはブロックチェーントランザクション１５２を使用して送信され得る。

第三者６０１は、要求トランザクションＴｘ_ｒｔを生成する。上記に示したように、要求トランザクションは、第１の当事者５０１の登録された公開鍵にロックされた出力を含む。図５の例とこの例との違いは、要求トランザクションＴｘ_ｒｔの入力が、第三者６０１によって生成された署名を含むことである。しかしながら、これは、要求トランザクションが第２の当事者５０２および第三者６０１の両方からのそれぞれの署名を含み得ることを除外するものではない。第三者６０１は、要求トランザクションＴｘ_ｒｔをブロックチェーンネットワーク１０６に送信する。

第１の当事者５０１は、例えばブロックチェーン１５０またはメムプールをスキャンすることによって要求トランザクションＴｘ_ｒｔを取得し、確認トランザクションＴｘ_ｃｔを生成し、確認トランザクションＴｘ_ｃｔをブロックチェーンネットワーク１０６に送信する。

第三者６０１は、例えばブロックチェーン１５０をスキャンすることによって、またはネットワーク１０６の１つまたは複数のノードのメムプールをスキャンすることによって、確認トランザクションＴｘ_ｃｔがブロックチェーンネットワーク１０６に送信されたかどうかを決定する。確認トランザクションＴｘ_ｃｔがブロックチェーンに記録されているか、または１つまたは複数のそれぞれのメムプールに存在する場合、第三者は、第１の当事者のアイデンティティが検証されたことを第２の当事者５０２に通知する指示を第２の当事者に送信する。例えば、第三者６０１は、サイドチャネル５０４上で指示を送信してもよく、または指示を含むブロックチェーントランザクション１５２を第２の当事者５０２に送信してもよい。いくつかの例では、第三者６０１は、確認トランザクションＴｘ_ｃｔ（したがって要求トランザクションＴｘ_ｒｔ）がブロックチェーン１５０に記録された後にのみ指示を送信する。

指示の受信に応答して、第２の当事者５０２は、第１の当事者５０１にリソースまたはサービスへのアクセスを許可する。

図７は、第１の当事者５０１のアイデンティティを検証するための例示的なシーケンス図を示す。図７は、第１の当事者が、（必須ではないが）それぞれのウォレットアプリケーション７０２ａを操作する「ユーザＡ」７０１ａと、それぞれのウォレットアプリケーション７０２ｂを操作する「ユーザＢ」７０１ｂという２人の異なるユーザをどのように含み得るかを示す。第１の当事者５０１が単一のユーザを含む場合、ユーザＡ７０１ａはユーザＢ７０１ｂと同じユーザである。

ユーザＡ７０１ａは、１つまたは複数のクレデンシャルをアクセス権限者５０２に提供する。アクセス権限者は、ユーザＡのアイデンティティを検証するよう求める要求を信頼できる第三者機関６０１に送信する。信頼できる第三者機関６０１は、ユーザＢの公開鍵にロックされたブロックチェーン１５０に要求トランザクションＴｘ_ｒｔを送信する。ユーザＢのウォレットアプリケーション７０２ｂは、ブロックチェーン１５０から要求トランザクションＴｘ_ｒｔを取得し、第２のクレデンシャルを提供するよう求める要求をユーザＢ７０１ａに通知する。ユーザＢは、ウォレットアプリケーション７０２ｂを使用して確認トランザクションＴｘ_ｃｔを生成し、ウォレットアプリケーション７０２ｂは、確認トランザクションＴｘ_ｃｔをブロックチェーン１５０に送信する。信頼できる第三者機関６０１は、ブロックチェーン１５０から確認トランザクションＴｘ_ｃｔを取得し、第１の当事者のアイデンティティが検証されたという指示をアクセス権限者５０２に送信する。アクセス権限者５０２は、ユーザＢ７０１ａにリソースまたはサービスへのアクセスを許可する。この例では、ユーザＢ７０１ｂがユーザＡ７０１ａのアイデンティティを証明する。例えば、ユーザＡは、商人から購入すること、またはストリーミングサービス上のコンテンツにアクセスすることを望む子供であり得、ユーザＢは、購入またはアクセスが適切であるかどうかをまず判断し、次いで子供のアイデンティティを証明することができる親であり得る。しかしながら、好ましくは、ユーザＡがユーザＢであり、ユーザＡが、自身のアイデンティティを検証するために確認トランザクションを提供している。

任意選択の特徴として、第１の当事者の公開鍵にロックされた要求トランザクションの出力は、要求トランザクションを生成した当事者、すなわち第２の当事者５０２または第三者６０１の公開鍵に追加でロックされ得る。その場合、出力はマルチシグネチャ出力である。マルチシグネチャ（ｍｕｌｔｉ－ｓｉｇとしても知られる）出力は、ｍｕｌｔｉ－ｓｉｇ出力におけるｎ－ｏｆ－ｍ公開鍵に対応する署名を含むように使用トランザクションの入力にチャレンジする。したがって、これらの例では、出力は、第１の当事者５０１によってロック解除（すなわち、使用）され得る。出力は、代替的に、（どの当事者が要求トランザクションを生成したかに応じて）第２の当事者５０２または第三者６０１によってロック解除されてもよい。例えば、第２の当事者５０２が要求トランザクションを生成した場合、出力は、１－ｏｆ－２のｍｕｌｔｉ－ｓｉｇ出力であってもよく、これは、第１の当事者５０１または第２の当事者５０２が独立してロック解除することができるものである。出力が当事者の一方によってロック解除（すなわち、使用）されると、他方の当事者がロック解除（すなわち、二重支出）することができない点に留意されたい。第１の当事者５０１がｍｕｌｔｉ－ｓｉｇ出力をロック解除する場合、使用トランザクションは確認トランザクションである。第２の当事者５０２または第三者６０１がｍｕｌｔｉ－ｓｉｇ出力をロック解除する場合、使用トランザクションはキャンセルトランザクションである。キャンセルトランザクションは、例えば、要求トランザクションがネットワーク１０６にサブミットされてからある期間が経過した場合、第２の当事者５０２または第三者６０１がＵＴＸＯセットから要求トランザクションを除去することを可能にする。

別の任意選択の特徴として、第１の当事者５０２のプライバシーを高めるために、第１の当事者５０２は、第１の公開鍵を第２の当事者５０２または第三者６０１に登録することができ、第２の当事者または第三者は、要求トランザクションの出力を、第１の公開鍵に基づいて生成された第２の公開鍵にロックし得る。第２の公開鍵は、第１の当事者５０１および第２の当事者５０２または第三者６０１の両方に知られている所定の方法で生成される。これにより、第１の当事者５０１は、要求トランザクションを取得するために、第２の公開鍵またはそのハッシュについてブロックチェーン１５０またはメムプールをスキャンすることができる。例えば、第１の当事者５０１は、擬似乱数を生成し、それを第２の当事者５０２または第三者６０１と共有してもよく、またはその逆であってもよい。擬似乱数を第１の公開鍵と組み合わせて第２の公開鍵が生成され得る。使用される公開鍵方式に応じて、例えばＥＣＤＳＡ方式が使用される場合、擬似乱数は最初に生成点が乗算されなければならない場合がある。擬似乱数は、ディフィーヘルマン交換またはその変形を使用して当事者間で共有され得る。その後、第１の当事者５０１が、例えば別のリソースまたはサービスへのアクセスを得るために第２の当事者５０２と対話する場合、第２の当事者または第三者は、同じ擬似乱数を第２の公開鍵に適用して第３の公開鍵を生成し、後続の要求トランザクションの出力を第３の公開鍵にロックし得る。

別の任意選択の特徴は、要求トランザクションＴｘ_ｒｔの出力におけるチャレンジの使用である。チャレンジは、所定の応答を含むように確認トランザクションＴｘ_ｃｔの入力にチャレンジする。このチャレンジは、確認トランザクションＴｘ_ｃｔの入力が第１の当事者５０１の署名を含むという要件に追加されることに留意されたい。

第１に、第１の当事者５０１がメッセージを第２の当事者５０２に送信し得るか、または第２の当事者５０２がメッセージを第１の当事者５０１に送信し得る。いくつかの例では、第１の当事者５０１および第２の当事者５０２は、情報を交換することによって共同でメッセージを生成し得る。メッセージは、アイデンティティ検証要求の詳細、例えば、第１の当事者５０１がアクセスしようとしているリソースまたはサービスに関する情報、時間および／または日付情報などを含み得る。一般に、メッセージは任意の形式の情報を含み得る。いくつかの例では、メッセージは、第２の公開鍵を生成するために使用される擬似乱数を含む。メッセージは、暗号化された形態で送信され得、その場合、第１の当事者５０１および第２の当事者５０２は、復号鍵を知っているか、または共有しなければならない。復号鍵を共有する方法は、当業者にはよく知られている。１つのそのような方法は、ディフィーヘルマン交換である。

第１の当事者５０１は、要求トランザクションＴｘ_ｒｔを取得すると、要求トランザクションＴｘ_ｒｔがメッセージをその元の形態（すなわち、平文として）含むかその暗号化された形態（例えば、暗号文として）で含むかを決定し得る。代替的に、第１の当事者５０１は、要求トランザクションＴｘ_ｒｔがメッセージのハッシュ（またはマルチハッシュ）をその元の形態で含むか暗号化された形態で含むかを決定し得る。マルチハッシュは、ハッシュ関数をメッセージに２回以上適用した結果である。特定のハッシュ関数はそれ自体がメッセージを複数回ハッシュすることができることに留意されたい。一般に、マルチハッシュ関数、例えばダブルハッシュ関数を適用することは、第１のハッシュ関数を１回または複数回適用し、続いて第２のハッシュ関数を１回または複数回適用することを含み得、ここで、第１および第２のハッシュ関数は、同じハッシュ関数であっても異なるハッシュ関数であってもよい。加えて、第１のハッシュ関数および／または第２のハッシュ関数はそれら自体がハッシュ関数を１回または複数回適用し得る。以下ではメッセージＸにダブルハッシュ関数を適用することを指すために表記Ｈ^２（Ｘ）が使用され、ここで、Ｈ^２（Ｘ）＝Ｈ^Ａ（Ｈ^Ｂ（Ｘ））であり、Ｈ^ＡおよびＨ^Ｂは、同じまたは異なるハッシュ（またはマルチハッシュ）関数であり得る。一例として、ハッシュ関数Ｈ１６０はそれ自体が、ＲＩＰＥＭＤ１６０およびＳＨＡ２５６という２つの異なるハッシュ関数を利用するハッシュ関数であり、すなわち、ｈａｓｈ１６０（Ｘ）＝ＲＩＰＥＭＤ１６０（ＳＨＡ２５６（Ｘ））である。

第１の当事者５０１は、要求トランザクションＴｘ_ｒｔが予想されるメッセージまたはメッセージの予想されるハッシュ（これはマルチハッシュであってもよい）を含む場合にのみ、確認トランザクションＴｘ_ｃｔを生成し得る。好ましくは、第１の当事者５０１は、要求トランザクションＴｘ_ｒｔがメッセージのダブルハッシュを含む場合にのみ確認トランザクションＴｘ_ｃｔを生成し得る。第三者６０１が要求トランザクションＴｘ_ｒｔを生成する場合、第２の当事者５０２は、メッセージまたはその（マルチ）ハッシュを第三者６０１と共有する。

要求トランザクションＴｘ_ｒｔの出力は、予想されるメッセージまたはメッセージの予想されるハッシュ（これはマルチハッシュであってもよい）を含み得る。好ましくは、出力は、確認トランザクションＴｘ_ｃｔの入力がその出力をロック解除するためにメッセージの知識を必要とするチャレンジを含む。例えば、出力はハッシュパズルを含み得る。ハッシュパズルは、入力値を取り、ハッシュ関数を入力値に適用し、それを所定のハッシュと比較する。入力値のハッシュが所定のハッシュと一致する場合、１または「真」などの値が出力される。トランザクションの出力にハッシュパズルを含めることは、使用トランザクションの入力が、所定のハッシュにハッシュする正確な入力値（またはプレイメージ）を含むことを必要とする。

一例として、要求トランザクションＴｘ_ｒｔの出力がメッセージのハッシュを含む場合、確認トランザクションＴｘ_ｃｔの入力は、メッセージ自体を含む必要がある。要求トランザクションＴｘ_ｒｔの出力がメッセージのダブルハッシュを含む場合、確認トランザクションＴｘ_ｃｔの入力は、メッセージのハッシュを含む必要がある。一般に、確認トランザクションＴｘ_ｃｔの入力は、要求トランザクションＴｘ_ｒｔの出力に含まれる（マルチ）ハッシュのプレイメージを含むことが必要とされる。

以下の例は、２要素認証システムにおけるアイデンティティ検証プロトコルの使用を説明する。この例では、ユーザは、アイテムを購入する過程におり（以下では「販売トランザクション」と称される）、クレジットカードトランザクションを進める許可を与えることを示すブロックチェーントランザクションに署名することが予想される。そのような署名されたトランザクションの生成後、クレジットカード会社および／または企業は販売の完了手続きを続行することが予想される。販売は、不換通貨用のペイメントカードの使用を必要とし、第１のクレデンシャル（または要素）は、ペイメント（クレジットまたはデビット）カード自体（または少なくとも関連する番号）である。

好ましくは、ＭＦＡシステムを実装する際、いくつかの重要な側面を考慮しなければならない。悪意のある行為者が、システムを危険にさらしたり、望ましくない結果を生じさせたりすることを防止する努力がなされなければならない。個人は、ほとんどの場合ではないにしても多くの場合、自身の金融トランザクションの詳細がパブリックドメインになることを好まない。２ＦＡプロセスは短時間で完了することが望ましい。最終的に当事者間で不一致が生じた場合に監査する目的で、ある程度の透明性が望まれ得る。

単一の設計の２ＦＡＢ解決策では、上記の基準の各々を同時に完全に満たすことができない場合がある。そのため、基本設計が提示され、その後、前述の考慮事項をターゲットとする追加の設計が提示される。

以下の例において以下の頭字語を使用する。ＰＦ１ ７０１ａ（例えば、第１の当事者５０１）は、商品またはサービスの支払いをしようとしている個人である。これは、商品をレジに持っていく店内の人物を含むか、またはインターネット対応デバイスからオンライン購入を行う人物であり得る。ＷＦ１ ７０２ａは、ＰＦ１のブロックチェーンウォレットである。このウォレットは、ＰＦ１に代わってアクセスし、トランザクションをブロックチェーン１５０にサブミットすることを担う。ＷＦ１はまた、文字列／テキストのハッシュを計算するととともに、これらのハッシュおよび関連付けられたテキストを格納および記録することもできる。企業７０３（例えば、第２の当事者５０２）は、ＰＦ１が商品およびサービスに対して支払いを行うべき会社である。銀行７０４（例えば、第三者６０１）は、クレジット／デビットカードを発行し、支配し、その使用を管理する機関を表す。ＰＦ２ ７０１ｂは、第２の要素を表す確認トランザクションに署名することを担う個人である。ＰＦ２はＰＦ１と同じ人であってもよい。実際、これは所望の選択肢であり、同じ個人が第１および第２の要素を証明する。しかしながら、ＰＦ１およびＰＦ２は必ずしも同じ個人ではない。この理由から、ＰＦ１およびＰＦ２は、ＷＰ全体にわたって、それら自体のアイデンティティを有するものとして表されており、それらが同じ人物でない場合を考慮する。ＷＦ２ ７０２ｂは、ＰＦ２のブロックチェーンウォレットである。このウォレットは、ＰＦ２に代わってアクセスし、トランザクションをブロックチェーンにサブミットすることを担う。ＷＦ２はまた、銀行からの任意の２ＦＡ要求についてブロックチェーンを観察し、次いで、この要求をＰＦ２に通信することもできる。

２ＦＡシステムの設計を容易にするために、以下の仮定が行われる。第１に、クレジットカード会社または銀行７０４によってクレジットカードが付与されると、個人は公開鍵（例えば、ＥＣＤＳＡ公開鍵）が登録される。この公開鍵は、個人の銀行口座に結び付けられる。ユーザまたは銀行がセキュリティ上の理由またはその他の理由で必要とする場合、ユーザは、新しい公開鍵を銀行に登録する（以前の公開鍵を置き換える）ことができる。第２の仮定は、銀行７０４によってクレジットカードが付与されると、個人および銀行は、ブロックチェーン上の販売トランザクションデータを暗号化する必要性／要求がある場合に銀行７０４が利用する秘密値Ｓに関して互いに合意するということである。この秘密Ｓは、クレジットカード所有者と銀行７０４との間でディフィーヘルマンプロトコルを使用して安全に生成および交換されることができ、カード所有者の口座に結び付けられる。ユーザまたは銀行７０４が、セキュリティ上の理由または他の理由で、以前のＳが危険にさらされていると信じる場合、ユーザは、銀行７０４と再契約（ｒｅ－ｅｎｇａｇｅ）して、新しい秘密値Ｓを生成する（以前の秘密値を置き換える）ことができる。

２ＦＡシステムの例示的なシーケンス図を図８に示す。最初の３つのステップ（上から下）は、人が商品およびサービスを決定したときのＰＦ１と企業７０３との間の対話を表す。ここで、ＰＦ１は、必要なアイテムを決定した後、正式な購入注文またはその他の形式でこのリストを企業７０３に提示する。企業７０３は、ＰＦ１に通信されるインボイスまたは請求書を構築する（このインボイスには、企業の識別情報が含まれると予想される）。ＰＦ１がインボイスの詳細に満足すると、ＰＦ１は企業７０３に自身の必要なクレジットカードの詳細を与える。注文書、インボイス、クレジットカードは、必ずしも物理的に相手に与えられる必要はなく、これらは、カードリーダ、キャッシュレジスタ、携帯電話などの電子デバイスを使用して通信され得ることに留意されたい。企業７０３がクレジットカード情報を得た後、キャッシャーは、メッセージ、例えば、正式な「販売トランザクションのデジタル表現」（ＳＴＤＲ）を構築する。これは、インボイスとＰＦ１のクレジットカード情報との組合せであり得る。企業７０３は、トランザクションの要約（すなわちハッシュ）Ｈ（ＳＴＤＲ）を生成し、これをＰＦ１に通信する。ＰＦ１は、Ｈ（ＳＴＤＲ）値が正しいかどうかをチェックすることができるコンピューティングデバイス、例えば、スマートフォンを所有している必要がある。この機能は、スマートフォン上で利用可能なＷＦ１によって実行され得る。Ｈ（ＳＴＤＲ）が正しく計算されたと仮定すると、ウォレットは、もっと後の２ＦＡ要求を予想して、このハッシュおよびＳＴＤＲ自体の記録を保持する。

ＰＦ１がＨ（ＳＴＤＲ）値を確認したと仮定すると、企業７０３は、ユーザのクレジットカードの処理を進めることができる。企業７０３は、ＳＴＤＲ情報をＰＦ１の銀行７０４に渡す。

銀行７０４は、情報（例えば、ビジネス識別子、クレジットカード情報、ＳＴＤＲフォーマットなど）を妥当性確認し、そのクレジットカードについて現在登録されている公開鍵（Ｐ_ＣＣ＝ｖ_ＣＣＧ）を取り出す。ここで、ｖ_ＣＣは秘密鍵であり、Ｇは生成点である。上記妥当性確認の後、銀行７０４は、Ｈ（・）＝ＳＨＡ２５６などのハッシュ関数を使用して、ＳＴＤＲのダブルハッシュＨ^２（ＳＴＤＲ）を生成し、ブロックチェーンにサブミットされるべき「２ＦＡ要求トランザクション」（Ｔｘ_ｒｔ）を作成し、ここで、上記トランザクションの出力（例示の目的で出力－２ＦＡとラベル付けされる）は、ダブルハッシュを利用して「ロック」される。「２ＦＡ要求トランザクション」Ｔｘ_ｒｔは、販売トランザクションに対する第２の認証要素についての銀行７０４による正式な要求であるトランザクションである。「要求」されている第２の要素は、ブロックチェーントランザクションに署名するＰ_ＣＣによって生成されるデジタル署名（ＥＣＤＳＡ）である。前述の出力された出力－２ＦＡを使用するために、このデジタル署名は、上記出力を利用する使用トランザクションの入力スクリプトに存在しなければならない。Ｔｘ_ｒｔの例を以下の表に示す：

Ｔｘ_ｒｔについては、トランザクションの入力は、提案されたシステムのすべての利害関係者によって知られておりかつ信頼されると予想される公開鍵Ｐ_Ｂａｎｋ＝ｖ_ｂａｎｋＧを用いて銀行７０４によって署名される。トランザクションには２つの出力があり、１つ目は出力－２ＦＡであり、２つ目は使用不可能な（例えば、ＯＰ＿ＲＥＴＵＲＮ）出力である。使用不可能な出力は、トランザクションに関連するメタデータを格納するためのものである。ＯＰ＿ＲＥＴＵＲＮ出力以外のトランザクション内にメタデータを格納する代替方法が存在する。ＯＰ＿ＲＥＴＵＲＮ出力は、トランザクション内に含まれ得るメタデータの例を示す。これらを以下の表で説明する：

出力－２ＦＡの場合、これは、以下に複製されるロックスクリプトによって保護される。

このスクリプトの前半は、Ｈ（ＳＴＤＲ）であり得るＨ^２（ＳＴＤＲ）のプレイメージを求め、後半は、クレジットカードに登録された公開鍵に結び付けられたＥＣＤＳＡ署名Ｓｉｇ（Ｐ_ＣＣ）を求める。ＰＦ２が２ＦＡ要求に気づいていないか、または（例えば、販売トランザクションを思い出せずに承認を行わないため）トランザクションを確認したくないシナリオがあると仮定すると、要求トランザクションＴｘ_ｒｔは以下のように変更することができる。１つの方法は、銀行７０４がトランザクションＴｘ_ｒｔの出力－２ＦＡを使用する選択肢を有することを可能にすることである。ある期間の後、例えば銀行の裁量で、ＰＦ２が出力－２ＦＡを使用しなかった（すなわち第２の認証要素を提供した）場合、銀行７０４は、出力－２ＦＡをそれ自体に「返金」することができる。したがって、出力－２ＦＡのロックスクリプトは、銀行７０４またはＰＦ２の両方が出力をロック解除できるように調整される。

上記のスクリプトに示されるように、これは、２つの公開鍵Ｐ_ＢａｎｋまたはＰ_ＣＣのいずれかに対する署名を求めるｍ－ｏｆ－ｎのｍｕｌｔｉｓｉｇ条件を含むことによって行われ得る。ここで、ロックスクリプトは、必要とされる有効な署名の数（ｍ）で始まり、次いで、ｍ個の署名が対応しなければならないｎ個の公開鍵のセット、次いで値ｎ、およびｍ個の署名すべてが有効であるかどうかをチェックするオペコードＯＰ＿ＣＨＥＣＫＭＵＬＴＩＳＩＧを列挙する。このようにして、銀行７０４は、必要に応じて出力－２ＦＡを使用することができる。その作成後、トランザクションＴｘ_ｒｔは、銀行７０４によってブロックチェーンにサブミットされる。

Ｔｘ_ｒｔが成功裏にマイニングされると（すなわち、ブロックチェーン１５０上のブロック１５１に含まれると）、２ＦＡ要求についてブロックチェーン（ＵＴＸＯ）を常にスキャンしているＰＦ２のウォレット（ＷＦ２）は、最終的にブロックチェーン１５０上のトランザクションの存在に気付き、この要求の存在をＰＦ２に警告する。ウォレットＷＦ２は、Ｐ_ＣＣをターゲットとする出力－２ＦＡ、および任意選択で＜２ＦＡＢ－ＩＤ＞＜Ｔｘ_ｒｔ－ＩＤ＞を含むトランザクションを特に求めている。

ＰＦ２がＰＦ１であると仮定すると（タンデムウォレットでは、ＷＦ２はＷＦ１であり得る）、ウォレットは、ＰＦ１と企業７０３との間の最初の接触点から受信された格納されたＨ（ＳＴＤＲ）が、ＯＰ＿ＲＥＴＵＲＮ出力内のＳＴＤＲの復号されたバージョンおよび出力－２ＦＡ内のＨ^２（ＳＴＤＲ）に対応することをチェックすることができるであろう。値が一致し（または一致せず）、ＰＦ２が販売トランザクションを続行することを望む場合、ＰＦ２はウォレットＷＦ２内のその選択肢を選択する。

ＰＦ２の命令で、ＷＦ２はトランザクションＴｘ_ｃｔを作成する。このトランザクションは、２ＦＡ確認トランザクションとなる。このトランザクションは、ＰＦ２が販売トランザクションの完了に対して銀行７０４に承認を与える正式な確認である。

Ｔｘ_ｃｔトランザクションの入力は、Ｔｘ_ｒｔの出力－２ＦＡである。したがって、出力－２ＦＡのロック解除スクリプトは以下のようになる：
または、銀行７０４がＴｘ_ｒｔをキャンセルすることを許可されている場合には、以下である：

ＰＦ２は、秘密鍵ｖ_ＣＣを利用するトランザクションの署名を含まなければならない。加えて、ＰＦ２はＨ（ＳＴＤＲ）を提供しなければならない。ＰＦ２がこのハッシュ値を含むことは、ＰＦ２がすべき正確な販売トランザクションに応答していることをＰＦ２が確認する方法である。ＳＴＤＲにおいて変更された文字がある場合、完全に異なるハッシュ値が生成されることに留意されたい。

トランザクションには、銀行７０４にｙ値を返す少なくとも１つの出力が含まれ得る。第２のＯＰ＿ＲＥＴＵＲＮ出力を使用して、必要なメタデータを格納し得る。メタデータは、トランザクションが２ＦＡＢトランザクションであることを示す＜２ＦＡＢ－ＩＤ＞と、トランザクションが具体的には２ＦＡＢ確認トランザクションであることを示す＜Ｔｘ_ｃｔ－ＩＤ＞とを含み得る。トランザクションはブロックチェーンに提出されることとなる。

Ｔｘ_ｃｔが成功裏にマイニングされると、銀行７０４は、そのウォレットソフトウェアがＴｘ_ｃｔについてブロックチェーン１５０を常にスキャンしているため、最終的にブロックチェーン１５０上のＴｘ_ｃｔの存在に気付く。銀行７０４は、銀行の公開鍵Ｐ_Ｂａｎｋおよび任意選択で＜２ＦＡＢ－ＩＤ＞＜２ＦＡ－ｃｔ－ＩＤ＞タグをターゲットとする出力を含むトランザクションを具体的に求めことになる。

銀行７０４は、他の非２ＦＡ妥当性確認プロセスを行う必要あれば何でも行い、それに応じてユーザのクレジットカード残高を調整し、次いで、販売トランザクションが銀行７０４によって承認されたという署名された認証を企業７０３に送信する。認証はブロックチェーントランザクションの形態であり得る。次いで、企業７０３は、ユーザに商品またはサービスを提供する。

図８の例では、トランザクションがブロックチェーン１５０上で確認されるのにかかる時間に対して遅延が存在する。プルーフオブワークブロックチェーンの場合、トランザクションがマイニングされる（すなわちブロックチェーン１５０に含まれる）ための平均時間は１０分である。要求トランザクションＴｘ_ｒｔがマイニングされることと確認トランザクションＴｘ_ｃｔがマイニングされることとを組み合わせるということは、販売の詳細を定式化する際のＰＦ１間の最初の対話から、顧客が商品またはサービスに対する権利を与えられるまでに約２０分かかることを意味する。これは、いくつかの状況では非実用的であり得る。

ブロックチェーンネットワーク１０６のノードは、それらが受信する未確認トランザクションを、未確認トランザクションメモリプールと呼ばれ、単にメムプールと呼ばれることが多いデータベースに格納する。すべての受信されたトランザクションがメムプールに追加されるわけではない。トランザクションが、すでにメムプール内にある別のトランザクションの入力を二重支出する場合、それはドロップされる。トランザクションは、それが標準トランザクションでない場合にもドロップされる。ノードが新しいブロックを受信するか、またはブロック自体をマイニングすると、未確認トランザクションメモリプールが更新され、ブロックに含まれるすべてのトランザクションが除去される。トランザクションが作成されると、少量のノードを通してブロックチェーンネットワーク１０６に中継される。新しいトランザクションを受信するノードは、それが有効であることと、すでにメムプール内にあるトランザクションの二重支出ではないこととをチェックする。トランザクションがチェックにパスした場合はネットワーク内の他のノードに中継され、パスしなかった場合はドロップされる。メムプールは、本質的に、ブロックチェーンにおける確認を待つトランザクションのための一時的なストアとして機能する。これは、トランザクション（フォーマッティングおよび二重支出を含む）の有効性をチェックするブロックチェーンネットワーク１０６のノードによって維持される。各ノードは、メムプールのコピーを保持し、新しい有効なトランザクションを他のノードに渡し、他のノードからの有効なトランザクションをそのバージョンのメムプールに受け入れる。

この妥当性確認プロセスがノードのそれぞれのメムプール内のトランザクションに対してノードの各々によって実行されることを考慮すると、複数のメムプール内のトランザクションの存在は、完全ではないが十分なトランザクションの正当性を示すと見なされ得る。メムプール内のトランザクションの正当性は、特に、最初の（有効な）トランザクションブロードキャストが次のブロックに含まれるものであるプルーフオブワークブロックチェーンに適用可能である。トランザクションが、ノードにわたってアップロードされ、妥当性確認され、ブロードキャストされるのが、非常に迅速に－ほぼ即時に－発生することを考慮すると、支払いの対象の受信者が、十分な信頼レベルで（マイニングされていないにもかかわらず）有効であるとしてメムプール内のトランザクションを受け入れる意思がある場合、支払人がトランザクションを送信してから受取人がトランザクションを「見ることができ、受け入れる」までの時間が劇的に短縮される。メムプールは、マイニングされたトランザクションのＵＴＸＯを使用する有効なトランザクションを格納するだけでなく、メムプールはまた、メムプールにあるがまだマイニングされていないトランザクションの出力を使用するトランザクションを格納し、有効なものとして受け入れる。これは、各トランザクションが前のトランザクションの出力（複数可）を使用し、最初のトランザクションがマイニングされたトランザクションの出力を使用する唯一のトランザクションである、メムプール内のトランザクションのチェーンを作成することができる。現在、このチェーンは、２５個のトランザクション程度の長さであり得る。

図９は、メムプールを利用する修正された２ＦＡプロトコルのシーケンス図を示す。この例では、ＷＦ２は、メムプール９０１（およびブロックチェーン１５０）をスキャンし、ＰＦ２に対する確認要求がある場合にＰＦ２に警告する。ＰＦ２が第２の認証要素を提供する意思がある場合、ＰＦ２は、メムプール内のトランザクションＴｘ_ｒｔの出力－２ＦＡを使用する確認トランザクションＴｘ_ｃｔに署名する。ＰＦ２は、トランザクションをメムプールにサブミットする。

銀行のウォレットは、そのような２ＦＡ確認トランザクションのためにメムプールをスキャンし、銀行７０４は、Ｔｘ_ｃｔが販売トランザクションのためのメムプールに実際に存在する場合、販売トランザクションを進めるように企業７０３に通知する。図１０は、メムプール９０１内の未確認トランザクションのチェーンを示す。図１１は、メムプール９０１内の要求トランザクションに対する二重支出試行を示す。メムプール内のトランザクションを（ＭＦＡプロトコルについてまたは一般に）有効なものとして「受け入れる」際の主な懸念は、二重支出の脅威である。二重支出は、トランザクション、例えば「Ｔｒａｎｓ ＤＳ」が別のもの、例えばＴｘ_ｃｔと同じ出力を使用する場合であり、この結果、Ｔｘ_ｃｔは「無効」と見なされ、ノードのメムプール９０１から除去され、決してマイニングされたりブロックに含まれたりしなくなる。

しかしながら、二重支出は、実際に達成することが困難または非実用的であることが証明されている。

一方で、二重支出が成功したとしても、これはＭＦＡプロトコルに対して問題を引き起こさない。販売トランザクションが必要とする第２の要素は、ｖ_ｃｃを使用する署名されたＴｘ_ｃｔである。銀行７０４がメムプール内でｖ_ｃｃ署名されたＴｘ_ｃｔを見た場合、そのトランザクションが（二重支出または他の理由で）ブロックに確認されない場合であっても、依然として、ＰＦ２がトランザクションＴｘ_ｃｔに署名したことに変わりはない。これは、第２の要素の十分な確認と捉えることができる。このような理解におけるメムプール９０１は、図１２に示すように、要求および確認トランザクションのための通信媒体として機能することとなる。それらの便宜上、銀行７０４は、二重支出の場合にＴｘ_ｃｔのコピーをその記録に保存することができ、トランザクションには決してマイニングされない。これは、監査または紛争に利用可能である。しかしながら、ほとんどの場合、それぞれのサブミット後約１０分で、Ｔｘ_ｒｔおよびＴｘ_ｃｔはブロックチェーンにマイニングされる。

一部の当事者（例えば、顧客および企業）は、販売トランザクションを実行するときに、あるレベルのプライバシーを必要とするかまたは所望し得る。先に説明した実装形態では、顧客のプライバシーを保護するために特定の措置がとられており、例えば、販売トランザクション（ＳＴＤＲ）の詳細は必ずしもトランザクションに含まれる必要はなく、代わりに販売トランザクション（ＳＴＤＲ）のハッシュおよび／または暗号化バージョンが使用され得る。ブロックチェーン１５０が公開されており不変であることを考慮すると、これらの措置は望ましい。出力－２ＦＡのロックスクリプトは、ハッシュＨ（ＳＴＤＲ）が使用トランザクションの（Ｔｘ_ｃｔ）入力スクリプトに存在することを義務付ける方法で、ダブルハッシュ（Ｈ^２（ＳＴＤＲ））を含み得る。悪意のある行為者が生のＳＴＤＲを決定することができる場合、行為者は、ＳＴＤＲが同じであれば、ブロックチェーン１５０上に表される他のすべての販売トランザクションを識別することができてしまう。これを防止するために、各ＳＴＤＲを一意にすることが賢明であろう。いくつかの例では、ＳＴＤＲは、以下の情報の１つまたは複数から構成される：インボイス（購入されるものに関する詳細）、クレジットカードの詳細、およびビジネスＩＤ（企業７０３を識別する情報、例えば、名称、住所、登録番号など）。

顧客が同じクレジットカードを使用して同じ店から同じアイテムを繰り返し購入する場合、ＳＴＤＲが毎回同じであるという危険がある。各販売トランザクションを区別するために、いくつかの一意のデータがＳＴＤＲに含められ得る。場合によっては、販売トランザクションのインボイスは、一般に「送り状番号」と呼ばれる一意の識別子を含む。これは、一意のＳＴＤＲの必要性に対処するが、ある程度までしか対処しない。新しい販売トランザクションが作成されるたびにその番号が固定値だけ単純に増分される場合、関心のある当事者が、「同じカードを使用して同じ企業７０３から同じアイテムを購入する」各新しい販売トランザクションを識別することは計算上容易である。番号が重複の確率が低い十分に大きい集合から選択された乱数である場合、これは理想的となる。一意のＳＴＤＲハッシュを生成する方法として、トランザクションの時間の日付－時刻値を使用することができる。しかしながら、これでは、日付－時刻が予測可能な方法で増加する値であるという同じ課題に直面する。このため、少なくとも１つのＳＴＤＲを知っていれば、日付－時刻を反復し、「同じカードを使用して同じ企業から同じアイテムを購入する」販売トランザクションのハッシュを計算し、識別することができる。乱数（２ＦＡＢ＿Ｒａｎｄ）が販売トランザクションのＩＤであることは好ましい選択肢である。これは、先に説明したように、企業７０３によって作成され得るか、または人ＰＦ１によって生成された乱数であり得る。別の選択肢として、それは、最初の対話において企業７０３およびＰＦ１の両方からの入力を用いて共同で生成された乱数であってもよい。２ＦＡＢ＿Ｒａｎｄの生成および妥当性確認のプロセスは、図９に示すように、ＰＦ１と企業７０３との間の対話に組み込まれ得る。

ＰＦ１および企業のランダム値をｋ_ＰＦ１およびｋ_Ｂｕｓとして使用することを考慮し、この場合以下である：
０＜ｋ_ＰＦ１，ｋ_Ｂｕｓ＜ｑ
ここで、ｑは大きな素数である。

値２ＦＡＢ＿Ｒａｎｄは、以下となり得る：
２ＦＡＢ＿Ｒａｎｄ＝（ｋ_ＰＦ１＋ｋ_Ｂｕｓ）ｍｏｄ ｑ

修正されたＳＴＤＲ（ＳＴＤＲ_Ｒ）値は、ここでは、以下となるように修正される：
ＳＴＤＲ_Ｒ＝ＳＴＤＲ｜｜２ＦＡＢ＿Ｒａｎｄ
ここで、｜｜は連結を表す。

２ＦＡＢ＿Ｒａｎｄ値は、ＰＦ１のウォレットに格納されることが予想される。いくつかの事例では、２ＦＡＢ＿Ｒａｎｄ値は、メタデータとして２ＦＡＢ－ｒｔトランザクションに含まれてもよく、例えば、値Ｓを使用して暗号化されてもよい。

ＳＴＤＲの一意性に関する懸念に加えて、Ｐ_ＣＣ公開鍵の一意性に関する懸念も存在する。クレジットカードの所有者は、カードが付与された時点で銀行７０４に公開鍵Ｐ_ＣＣを登録することを想起されたい。各２ＦＡトランザクションが同じ値Ｐ_ＣＣに送信される場合、関心のある（場合によっては悪意のある）当事者は、正確に何が買われたか知らないままでも、Ｐ_ＣＣカード所有者の身元を暴くことができた場合には、人ＰＦ１が行うすべての購入を容易に追跡することができる。ＰＦ１が行うすべての販売トランザクションの前に新しいＰ_ＣＣ値を銀行７０４に通信および登録することが実行不可能であることを考慮すると、一意のＰ_ＣＣ値を利用する他の選択肢が探索され得る。例えば、先に説明した２ＦＡＢ＿Ｒａｎｄ値を使用して、新しい公開鍵を生成し得る。楕円曲線および以下を含むパラメータのセット（例えば、ｓｅｃｐ２５６ｋ１楕円曲線）に関してすべての当事者が合意したと仮定する：
・ Ｇ － 次数ｑ：ｑ×Ｇ＝０を有する楕円曲線上の基点、および
・ ｑ － 大きな素数
その場合、Ｐ_ＣＣ公開鍵は、次のように修正され得る：
Ｐ^＊ _ＣＣ＝Ｐ_ＣＣ＋（２ＦＡＢ_Ｒａｎｄ）Ｇ
＝ｖ_ＣＣＧ＋（２ＦＡＢ_Ｒａｎｄ）Ｇ
＝（ｖ_ＣＣ＋２ＦＡＢ_Ｒａｎｄ）Ｇ

要求トランザクションＴｘ_ｒｔの出力された出力－２ＦＡは、公開鍵Ｐ^＊ _ＣＣにアドレス指定されるように修正される。顧客ＰＦ１／ＰＦ２は、確認トランザクションＴｘ_ｃｔを成功裏にサブミットするのに必要な署名を作成するためにこの値をｖ_ＣＣと対にするための２ＦＡＢ＿Ｒａｎｄの知識を保持することを担う。企業７０３は、銀行７０４に値２ＦＡＢ_ＲａｎｄＧを通信することを担う。

本開示は、ブロックチェーントランザクションを第２の認証要素として利用するアイデンティティ検証プロトコル（例えば、ＭＦＡプロトコル）を説明する。第２の認証要素に対する要求はブロックチェーントランザクションにおいて表され、その第２の認証要素の知識の確認は、対象の受信者が、要求トランザクションの出力を使用する確認トランザクションをサブミットすることによって達成されることが予想される。

ブロックチェーンの利用はそれ自体の複雑さを導入するものであり、まず、トランザクションがブロックに確認されるまでの長い（約１０分）待ち時間である。プロトコルは、メムプール内の未確認トランザクションがプロトコルの目的に対して正当であると見なされることを可能にすることによって、これに対処する。これは、要求トランザクションと、未確認の要求トランザクションの出力を使用する確認トランザクションとに適用される。未確認トランザクションを受け入れることは、認証プロセスをほぼ即時にする。

そのようなシナリオでは、ブロックチェーンは、要求および確認変換のための通信媒体として機能用し、重要なこと、両方のトランザクションが最終的にブロックチェーン上で確認される確率がほぼ確実である。

ブロックチェーンの使用に関する別の懸念は、プライバシーに関するものである。顧客は、第三者が自分の購入を識別することができることを嫌がる可能性がある。ＭＦＡプロトコルは、各一意のイベント（販売トランザクション）に対して生成される乱数の使用を含めることによって、これらの懸念を軽減する。この一意のランダム値は、２ＦＡ要求が送信されている公開鍵を偽装するため、ならびにイベント詳細の表現を偽装するために使用される。

ブロックチェーン１５０に固有の制限を緩和することに加えて、ＭＦＡプロトコルは、既存の解決策に勝る利点を提供する。ブロックチェーン１５０が分散システムであるという事実は、単一障害点の利用可能性に依存しないことを意味する。同時に、ブロックチェーン１５０の透明性および不変性は、送信された２ＦＡ要求および確認の証明が存在することを意味する。規制機関、政府、または法人に関連する監査は、ＭＦＡ確認またはその欠如に関連する任意の調査に関して容易に進められ、すなわち、銀行は、要求トランザクションを送信したことを拒否することができず、ＰＦ２／ＰＦ１は、確認トランザクションが署名されていることを拒否することができない。悪意のある行為者は、ＰＦ２／ＰＦ１が気づくことなくひそかに２ＦＡ確認を提供することはできない。銀行または企業が、ＰＦ１／ＰＦ２によって署名された確認トランザクションなしで販売トランザクションを処理すると、これは明らかになる。

不換通貨を利用する販売トランザクションの観点からプロトコルを説明してきたが、プロトコルは、ＭＦＡ認証を必要とする他の「トランザクション」、例えば、ファイルまたは物理的な建物への安全なアクセスを管理するのに適切であり得る。そのような場合、以下が考察される：
－ 販売トランザクションは一般的なイベントによって置き換えられる；
－ 企業は、ここでは、ゲートキーパーまたはアクセス権限者として記述される；および
－ 銀行は、ここでは、認証局の信頼できる第三者機関として記述され、とりわけＰＦ１の公開鍵を登録する責任を負う任意のエンティティまたはシステムと見なされる。

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

ステートメント１．第２の当事者が第１の当事者のアイデンティティを検証することを可能にするクレデンシャルを提供する方法であって、第１の当事者は第１の公開鍵に関連付けられ、第１の公開鍵は第三者に登録され、方法は以下を含む：
１つまたは複数の第１のクレデンシャルを第２の当事者に提供すること、
要求トランザクションを取得すること、ここで、要求トランザクションは、ａ）第三者のそれぞれの秘密鍵に基づいて生成された署名を含む入力と、ｂ）第１の当事者の第２の公開鍵にロックされた出力とを含むブロックチェーントランザクションであり、第２の公開鍵は第１の公開鍵に基づき、
確認トランザクションを生成すること、ここで、確認トランザクションは、要求トランザクションの出力を参照する入力と、第１の当事者の第２の公開鍵に対応する秘密鍵に基づいて生成された署名とを含むブロックチェーントランザクションであり、および
ブロックチェーンに含めるためにブロックチェーンネットワークの１つまたは複数のノードに確認トランザクションが送信されることを生じさせること。

１つまたは複数の第１のクレデンシャルの例には、ユーザ名、パスワード、バイオメトリック識別子、電話番号、住所、ＳＭＳテキストで（第三者から）受信したコード、ペイメントカード（またはその情報）、銀行の詳細、メモラブルワードなどが含まれる。

ステートメント２．上記取得することは、ブロックチェーンから要求トランザクションを取得することを含む、ステートメント１に記載の方法。

ステートメント３．上記取得することは、ブロックチェーンネットワークの１つまたは複数のノードのそれぞれのメモリプールから要求トランザクションを取得することを含み、各それぞれのメモリプールは、未確認のブロックチェーントランザクションのそれぞれのセットを含む、ステートメント１に記載の方法。

ステートメント４．１つまたは複数の第１のクレデンシャルを上記提供することは、第２の当事者からアイデンティティチャレンジを受信することに応答する、ステートメント１から３のいずれかに記載の方法。

ステートメント５．上記生じさせることは、トランザクションをブロックチェーンネットワークの１つまたは複数のノードに送信することを含む、ステートメント１から４のいずれかに記載の方法。

ステートメント６．ステートメント１から５のいずれかに記載の方法であって、以下を含む：
メッセージおよび／またはメッセージのハッシュのうちの少なくとも１つを第２の当事者から受信すること、または第２の当事者に送信すること、ならびに
要求トランザクションが、メッセージ、メッセージのハッシュ、および／またはメッセージのマルチハッシュのうちの少なくとも１つを含むかどうかを決定すること、ここで、確認トランザクションを上記生成することは、要求トランザクションが、メッセージ、メッセージのハッシュ、および／またはメッセージのマルチハッシュのプレイメージのうちの少なくとも１つを含むことを条件とする。

ステートメント７．要求トランザクションの出力は、ロック解除されるためにメッセージおよび／またはメッセージのハッシュの知識を必要とするチャレンジを含み、確認トランザクションの入力は、メッセージ、メッセージのハッシュおよび／またはメッセージのマルチハッシュのプレイメージを含む、ステートメント６に記載の方法。

ステートメント８．メッセージは第１の擬似乱数を含む、ステートメント６またはステートメント７に記載の方法。

ステートメント９．第２の公開鍵は、第１の公開鍵を第２の擬似乱数と組み合わせることによって生成される、ステートメント１から８のいずれかに記載の方法。

ステートメント１０．第２の公開鍵は第１の公開鍵である、ステートメント１から８のいずれかに記載の方法。

ステートメント１１．第１の擬似乱数および／または第２の擬似乱数は、第１の当事者によって生成された第３の擬似乱数および第２の当事者によって生成された第４の擬似乱数に基づく、ステートメント８またはステートメント９に記載の方法。

ステートメント１２．第２の擬似乱数は第１の擬似乱数である、ステートメント９またはステートメント１１に記載の方法。

ステートメント１３．第三者は第２の当事者である、ステートメント１から１２のいずれかに記載の方法。

ステートメント１４．第１の当事者のアイデンティティを検証する方法であって、第１の当事者は第１の公開鍵に関連付けられ、第１の公開鍵は第三者に登録され、方法は以下を含む：
第１の当事者のアイデンティティを検証する要求を受信すること、
要求トランザクションを生成すること、ここで、要求トランザクションは、ａ）第三者のそれぞれの秘密鍵に基づいて生成された署名を含む入力と、ｂ）第１の当事者の第２の公開鍵にロックされた出力とを含むブロックチェーントランザクションであり、第２の公開鍵は第１の公開鍵に基づき、
ブロックチェーンに含めるためにブロックチェーンネットワークの１つまたは複数のノードに要求トランザクションが送信されることを生じさせること、ならびに
ブロックチェーンに含めるために確認トランザクションがブロックチェーンネットワークの１つまたは複数のノードに送信されたかどうかを決定すること、ここで、確認トランザクションは、要求トランザクションの出力を参照する入力と、第１の当事者の第２の公開鍵に対応する秘密鍵に基づいて生成された署名とを含むブロックチェーントランザクションである。

要求はブロックチェーントランザクションであり得る。

ステートメント１５．ステートメント１４に記載の方法であって、ブロックチェーンに含めるために確認トランザクションがブロックチェーンネットワークの１つまたは複数のノードに送信されたかどうかを上記決定することは以下を含む：
確認トランザクションがブロックチェーンに含まれているかどうかを決定すること。

ステートメント１６．ステートメント１５に記載の方法であって、ブロックチェーンに含めるために確認トランザクションがブロックチェーンネットワークの１つまたは複数のノードに送信されたかどうかを上記決定することは以下を含む：
確認トランザクションがブロックチェーンネットワークの１つまたは複数のノードのそれぞれのメモリプールに含まれているかどうかを決定すること、ここで、各それぞれのメモリプールは、未確認のブロックチェーントランザクションのそれぞれのセットを含む。

ステートメント１７．ステートメント１４から１６のいずれかに記載の方法であって、以下を含む：
確認トランザクションがブロックチェーンネットワークの１つまたは複数のノードに送信されたかどうかに基づいて、第１の当事者のアイデンティティを検証すること。

ステートメント１８．ステートメント１７に記載の方法であって、要求は第２の当事者から受信され、方法は以下を含む：
第１の当事者のアイデンティティが検証されたという指示を第２の当事者に送信すること。

指示はブロックチェーントランザクションであり得る。

ステートメント１９．要求を受信することは、第１の当事者が１つまたは複数の第１のクレデンシャルを第２の当事者に提供したという指示を受信することを含む、ステートメント１８に記載の方法。

ステートメント２０．要求は、メッセージまたはメッセージのハッシュのうちの少なくとも１つを含み、要求トランザクションの出力は、ロック解除されるためにメッセージおよび／またはメッセージのハッシュの知識を必要とするチャレンジを含む、ステートメント１８またはステートメント１９に記載の方法。

ステートメント２１．メッセージは第１の擬似乱数を含む、ステートメント２０に記載の方法。

ステートメント２２．第２の公開鍵は、第１の公開鍵を第２の擬似乱数と組み合わせることによって生成される、ステートメント１４から２１のいずれかに記載の方法。

ステートメント２３．第１の擬似乱数および／または第２の擬似乱数は、第１の当事者によって生成された第３の擬似乱数および第三者によって生成された第４の擬似乱数に基づく、ステートメント２１またはステートメント２２に記載の方法。

ステートメント２４．第２の公開鍵は第１の公開鍵である、ステートメント１４から２１のいずれかに記載の方法。

ステートメント２５．要求トランザクションの出力は、第１の当事者の第２の公開鍵または第三者の公開鍵にロックされる、ステートメント１４から２４のいずれかに記載の方法。

ステートメント２６．ステートメント２５に記載の方法であって、以下を含む：
キャンセルトランザクションを生成すること、ここで、キャンセルトランザクションは、要求トランザクションの出力を参照する入力と、第１の当事者の公開鍵に対応する秘密鍵に基づいて生成された署名とを含むブロックチェーントランザクションであり、および
ブロックチェーンに含めるためにブロックチェーンネットワークの１つまたは複数のノードにキャンセルトランザクションが送信されることを生じさせること。

ステートメント２７．第２の当事者は、リソースまたはサービスのアクセスまたは所有権を制御し、リソースまたはサービスのアクセスまたは所有権は、第１の当事者のアイデンティティの検証に基づいて第１の当事者に許可される、ステートメント１７およびそれに従属する任意のステートメントに記載の方法。

リソースまたはサービスの例には、物理的またはデジタル商品、電子メールアカウント、ソーシャルメディアまたは他のオンラインアカウント、ストリーミングサービス、デジタルトークン（例えば、チケットまたは投票）などが含まれる。

ステートメント２８．第２の当事者は第三者である、ステートメント１４から２７のいずれかに記載の方法。

ステートメント２９．以下を備えるコンピュータ機器：
１つまたは複数のメモリユニットを備えるメモリ、および
１つまたは複数の処理ユニットを備える処理装置、ここで、メモリは、処理装置上で実行されるように構成されたコードを記憶し、コードは、処理装置上にあるときに、ステートメント１から２８のいずれかに記載の方法を実行するように構成される。

ステートメント３０．コンピュータ可読ストレージ上に具現化され、ステートメント２９に記載のコンピュータ機器上で実行されると、ステートメント１から２８のいずれかに記載の方法を実行するように構成されたコンピュータプログラム。

他の変形形態は、本明細書の開示が与えられれば、当業者に明らかになり得る。本開示の範囲は、開示された実施形態によっては限定されず、添付の特許請求の範囲によってのみ限定される。

Claims (15)

1. 第２の当事者が第１の当事者のアイデンティティを前記第１の当事者の２つ以上のクレデンシャルに基づいて検証することを可能にするクレデンシャルを提供する方法であって、前記第１の当事者は第１の公開鍵に関連付けられ、前記第１の公開鍵は第三者に登録され、前記方法は前記第１の当事者によって実行され、
   前記第１の当事者の１つまたは複数の第１のクレデンシャルを前記第２の当事者に提供することと、
   要求トランザクションを取得することであって、前記要求トランザクションは、ブロックチェーンネットワークの１つまたは複数のノードに送信され、ａ）前記第三者のそれぞれの秘密鍵に基づいて生成された署名を含む入力と、ｂ）前記第１の当事者の第２の公開鍵にロックされた出力とを含むブロックチェーントランザクションであり、前記第２の公開鍵は前記第１の公開鍵に基づく、ことと、
   確認トランザクションを生成することであって、前記確認トランザクションは、前記要求トランザクションの前記出力を参照する入力と、前記第１の当事者の前記第２の公開鍵に対応する秘密鍵に基づいて生成された署名とを含むブロックチェーントランザクションであり、前記確認トランザクションが前記要求トランザクションの前記出力をロック解除するようにし、前記確認トランザクションは、前記第１の当事者の第２のクレデンシャルであり、前記第１の当事者の前記アイデンティティを検証するべく前記１つまたは複数の第１のクレデンシャルと共に使用されるためのものである、ことと、
   ブロックチェーンに含めるためにブロックチェーンネットワークの１つまたは複数のノードに前記確認トランザクションが送信されることを生じさせることと、
   を含む方法。
2. 前記取得することは、前記ブロックチェーンから前記要求トランザクションを取得することを含む、請求項１に記載の方法。
3. 前記取得することは、前記ブロックチェーンネットワークの１つまたは複数のノードのそれぞれのメモリプールから前記要求トランザクションを取得することを含み、各それぞれのメモリプールは、未確認のブロックチェーントランザクションのそれぞれのセットを含む、請求項１に記載の方法。
4. 前記１つまたは複数の第１のクレデンシャルを前記提供することは、前記第２の当事者からアイデンティティチャレンジを受信することに応答する、請求項１～３のいずれか一項に記載の方法。
5. 前記生じさせることは、前記確認トランザクションを前記ブロックチェーンネットワークの前記１つまたは複数のノードに送信することを含む、請求項１～４のいずれか一項に記載の方法。
6. メッセージおよび／または前記メッセージのハッシュのうちの少なくとも１つを前記第２の当事者から受信すること、または前記第２の当事者に送信することと、
   前記要求トランザクションが、前記メッセージ、前記メッセージの前記ハッシュ、および／または前記メッセージのマルチハッシュのうちの少なくとも１つを含むかどうかを決定することと、
   を含み、前記確認トランザクションを前記生成することは、前記要求トランザクションが、前記メッセージ、前記メッセージの前記ハッシュ、および／または前記メッセージの前記マルチハッシュのプレイメージのうちの少なくとも１つを含むことを条件とする、
   請求項１～５のいずれか一項に記載の方法。
7. 前記要求トランザクションの前記出力は、ロック解除されるために前記メッセージおよび／または前記メッセージの前記ハッシュの知識を必要とするチャレンジを含み、前記確認トランザクションの前記入力は、前記メッセージ、前記メッセージの前記ハッシュおよび／または前記メッセージの前記マルチハッシュのプレイメージを含む、請求項６に記載の方法。
8. 前記メッセージは第１の擬似乱数を含む、請求項６または７に記載の方法。
9. 前記第２の公開鍵は、前記第１の公開鍵を第２の擬似乱数と組み合わせることによって生成される、請求項１～８のいずれか一項に記載の方法。
10. 前記第２の公開鍵は前記第１の公開鍵である、請求項１～８のいずれか一項に記載の方法。
11. 前記第１の擬似乱数は、前記第１の当事者によって生成された第３の擬似乱数および前記第２の当事者によって生成された第４の擬似乱数に基づく、請求項８に記載の方法。
12. 前記第２の擬似乱数は、前記第１の当事者によって生成された第３の擬似乱数および前記第２の当事者によって生成された第４の擬似乱数に基づく、請求項９に記載の方法。
13. 前記第三者は前記第２の当事者である、請求項１～１２のいずれか一項に記載の方法。
14. コンピュータ機器であって、
    １つまたは複数のメモリユニットを備えるメモリと、
    １つまたは複数の処理ユニットを備える処理装置と
    を備え、前記メモリは、前記処理装置上で実行されるように構成されたコードを記憶し、前記コードは、前記処理装置上にあるときに、請求項１～１３のいずれか一項に記載の方法を実行するように構成される、
    コンピュータ機器。
15. コンピュータ可読ストレージ上に具現化され、請求項１４に記載のコンピュータ機器上で実行されると、請求項１～１３のいずれか一項に記載の方法を実行するように構成されたコンピュータプログラム。