知財求人 - 知財ポータルサイト「IP Force」
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2024-12-26
(54)【発明の名称】ゼロ知識証明に基づく子鍵の真正性
(51)【国際特許分類】
H04L 9/32 20060101AFI20241219BHJP
G06F 21/64 20130101ALI20241219BHJP
【ＦＩ】
H04L9/32 200C
G06F21/64
【審査請求】未請求
【予備審査請求】未請求
(21)【出願番号】P 2024533790
(86)(22)【出願日】2022-12-06
(85)【翻訳文提出日】2024-06-05
(86)【国際出願番号】 EP2022084661
(87)【国際公開番号】W WO2023110551
(87)【国際公開日】2023-06-22
(31)【優先権主張番号】2118449.4
(32)【優先日】2021-12-17
(33)【優先権主張国・地域又は機関】GB
(81)【指定国・地域】
(71)【出願人】
【識別番号】318001991
【氏名又は名称】エヌチェーン ライセンシング アーゲー
(74)【代理人】
【識別番号】100107766
【弁理士】
【氏名又は名称】伊東 忠重
(74)【代理人】
【識別番号】100229448
【弁理士】
【氏名又は名称】中槇 利明
(72)【発明者】
【氏名】キラズ，メフメット サビル
(72)【発明者】
【氏名】ペティット，ミカエラ
(72)【発明者】
【氏名】タータン，クローイー
(57)【要約】
本開示の一実施形態では、エンティティに関連付けられた子公開鍵の真正性を検証するコンピュータ実装方法が提供される。この方法は、コンピューティングデバイス上で実行され、子公開鍵を取得するステップと、証明コンピューティングデバイスからゼロ知識証明を受信するステップと、ゼロ知識証明が有効であることを、証明、子公開鍵、および検証鍵を使用して検証して、鍵導出プロトコルが、親鍵から子公開鍵を導出するために使用されたことを決定するステップと、検証に基づいて子公開鍵の真正性を決定するステップとを含む。
【特許請求の範囲】
【請求項1】
エンティティに関連付けられた子公開鍵の真正性を検証するコンピュータ実装方法であって、前記方法は、コンピューティングデバイス上で実行され、前記子公開鍵を取得するステップと、
証明コンピューティングデバイスからゼロ知識証明を受信するステップと、
前記ゼロ知識証明が有効であることを、前記証明、前記子公開鍵、および検証鍵を使用して検証して、鍵導出プロトコルが、親鍵から前記子公開鍵を導出するために使用されたことを決定するステップと、
前記検証に基づいて前記子公開鍵の前記真正性を決定するステップと
を含むコンピュータ実装方法。
【請求項2】
前記子公開鍵を取得するステップは、前記証明コンピューティングデバイスから前記子公開鍵を受信するステップを含む、請求項１に記載のコンピュータ実装方法。
【請求項3】
前記方法は、前記子公開鍵が真正であることの証明を求める要求を前記証明コンピュータデバイスに送信するステップ
を含み、
前記ゼロ知識証明は、前記要求に応答して受信される、
請求項１に記載のコンピュータ実装方法。
【請求項4】
前記親鍵は、私有親鍵であり、前記子公開鍵は、強化された子公開鍵である、請求項１に記載のコンピュータ実装方法。
【請求項5】
前記親鍵は親公開鍵である、請求項１に記載のコンピュータ実装方法。
【請求項6】
前記私有親鍵に対応する親公開鍵のコピーを取得するステップをさらに含み、
前記ゼロ知識証明が有効であることを検証するステップは前記親公開鍵をさらに使用する、
請求項４に記載のコンピュータ実装方法。
【請求項7】
前記証明を生成するために前記証明コンピュータデバイスによって使用される親公開鍵を前記証明コンピュータデバイスから受信するステップをさらに含み、
前記子公開鍵の前記真正性を決定するステップは、前記証明を生成するために前記証明コンピュータデバイスによって使用される前記親公開鍵が前記親公開鍵の前記取得されたコピーと一致するかどうかにさらに基づく、
請求項６に記載のコンピュータ実装方法。
【請求項8】
前記親鍵は、認証局によって発行された署名済みデジタル証明書の証明された親公開鍵である、請求項６に記載のコンピュータ実装方法。
【請求項9】
前記署名済みデジタル証明書は、前記エンティティの一意識別子を含み、前記ゼロ知識証明が有効であることを検証するステップは、前記エンティティの公開一意識別子が、前記署名済みデジタル証明書内の前記エンティティの前記一意識別子と一致することをチェックするステップを含む、請求項８に記載のコンピュータ実装方法。
【請求項10】
前記署名済みデジタル証明書は、前記認証局の私有鍵を使用して署名され、前記ゼロ知識証明が有効であることを検証するステップは、前記認証局の公開鍵を使用して前記認証局の署名を検証するステップを含む、請求項８に記載のコンピュータ実装方法。
【請求項11】
署名機関に関連付けられた第１のアイデンティティ証明書を受信するステップであって、前記第１のアイデンティティ証明書は、認証局の第１の署名を含む、ステップと、前記エンティティに関連付けられた第２のアイデンティティ証明書を受信するステップであって、前記第２のアイデンティティ証明書は、署名機関の第２の署名とメッセージとを含み、前記メッセージは、前記親鍵の難読化バージョンと前記エンティティの一意識別子とを含む、ステップ
を含み、
前記ゼロ知識証明が有効であることを検証するステップは、前記メッセージをさらに使用する、
請求項１に記載のコンピュータ実装方法。
【請求項12】
前記子公開鍵の前記真正性を決定するステップは、前記認証局の公開鍵を使用して前記第１の署名を検証し、前記署名機関の公開鍵を使用して前記第２の署名を検証することによって、前記第２のアイデンティティ証明書内の前記親鍵の前記難読化バージョンの前記完全性を検証すること
にさらに基づく、請求項１１に記載のコンピュータ実装方法。
【請求項13】
前記証明を生成するために前記証明コンピュータデバイスによって使用されるメッセージを取得するステップをさらに含み、
前記子公開鍵の前記真正性を決定するステップは、前記証明を生成するために前記証明コンピュータデバイスによって使用される前記メッセージが前記第２のアイデンティティ証明書内の前記メッセージと一致することを検証することにさらに基づく、
請求項１１に記載のコンピュータ実装方法。
【請求項14】
前記証明コンピュータデバイスに要求を送信するステップであって、前記要求は前記子公開鍵を要求する、ステップと、前記要求に応答して、前記子公開鍵、前記ゼロ知識証明、前記第１のアイデンティティ証明書、および前記第２のアイデンティティ証明書を受信するステップと
をさらに含む、請求項１１に記載のコンピュータ実装方法。
【請求項15】
エンティティに関連付けられた子公開鍵の真正性の証明を提供するコンピュータ実装方法であって、前記方法は、コンピューティングデバイス上で実行され、前記子公開鍵を導出するために使用される親鍵、前記子公開鍵、および証明鍵を使用してゼロ知識証明を生成するステップと、
前記ゼロ知識証明を検証コンピューティングデバイスに送信して、前記検証コンピューティングデバイスが、前記親鍵から前記子公開鍵を導出するために鍵導出プロトコルが使用されたことを証明できるようにするステップと
を含むコンピュータ実装方法。
【請求項16】
前記親鍵は、ハッシュ関数出力の第１の部分を使用して生成され、前記方法は、前記ハッシュ関数出力の残りの部分を使用して前記ゼロ知識証明を生成するステップを含む、請求項１５に記載のコンピュータ実装方法。
【請求項17】
前記親鍵は、前記検証コンピューティングデバイスに公開されていない親私有鍵であり、前記子公開鍵は、強化された子公開鍵である、請求項１５に記載のコンピュータ実装方法。
【請求項18】
前記親鍵は親公開鍵である、請求項１５に記載のコンピュータ実装方法。
【請求項19】
コンピュータ可読命令を含む非一時的コンピュータ可読記憶媒体であって、前記コンピュータ可読命令は、コンピューティングデバイスによって読み取られると、前記コンピューティングデバイスに、請求項１から１８のいずれか一項に記載の方法を実行させる、非一時的コンピュータ可読記憶媒体。
【請求項20】
プロセッサとメモリとを備えるコンピューティングデバイスであって、前記メモリは、前記プロセッサによって実行されると、前記コンピューティングデバイスに、請求項１から１８のいずれか一項に記載の方法を実行させる命令を記憶する、コンピューティングデバイス。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は、子鍵の真正性を証明および検証することに関する。
【背景技術】
【0002】
ブロックチェーンは、分散型データ構造の形態を指し、ブロックチェーンの複製コピーが、分散型ピアツーピア（Ｐ２Ｐ）ネットワーク（以下、「ブロックチェーンネットワーク」と呼ぶ）内の複数のノードの各々において維持され、広く公開されている。ブロックチェーンはデータブロックのチェーンを含み、各ブロックは１つまたは複数のトランザクションを含む。いわゆる「コインベーストランザクション」以外の各トランザクションは、１つまたは複数のコインベーストランザクションまで遡る１つまたは複数のブロックにまたがり得るシーケンス内の先行するトランザクションを指し示す。コインベーストランザクションについては以下でさらに説明する。ブロックチェーンネットワークにサブミットされたトランザクションは、新しいブロックに含まれる。新しいブロックは、「マイニング（mining）」と呼ばれることが多いプロセスによって作成され、このプロセスは、複数のノードの各々が「プルーフオブワーク（proof-of-work）」を実行しようと競うこと、すなわち、ブロックチェーンの新しいブロックに含まれるのを待っている、順序付けられ妥当性確認（validate）された保留中のトランザクションの表現に基づいて暗号パズルを解くことを伴う。ブロックチェーンはいくつかのノードでプルーニング（prune）され得、ブロックの公開は、単なるブロックヘッダの公開を通して達成され得ることに留意されたい。
【0003】
ブロックチェーン内のトランザクションは、デジタル資産（すなわち、いくつかのデジタルトークン）を伝達すること、仮想台帳またはレジストリにおけるエントリのセットを順序付けること、タイムスタンプエントリを受信および処理すること、および／またはインデックスポインタを時間順にすることという目的のうちの１つまたは複数のために使用され得る。ブロックチェーンは、ブロックチェーンの上に追加の機能を重ねるために活用することもできる。例えば、ブロックチェーンプロトコルは、トランザクションにおける追加のユーザデータまたはデータへのインデックスの記憶を可能にし得る。単一のトランザクション内に記憶することができる最大データ容量に対してあらかじめ指定された制限はなく、したがって、より複雑なデータを組み込むことができる。例えば、これを使用して、ブロックチェーンに電子文書を記憶したり、オーディオまたはビデオデータを記憶したりすることができる。
【0004】
ブロックチェーンネットワークのノード（「マイナー（miner）」と呼ばれることが多い）は、以下でより詳細に説明する分散型のトランザクション登録および検証プロセスを実行する。要するに、このプロセスの間に、ノードは、トランザクションを妥当性確認し、有効なプルーフオブワークの解の識別を試みるブロックテンプレートにそれらを挿入する。有効な解が見つかると、ネットワークの他のノードに新しいブロックが伝搬され、これにより、各ノードが、新しいブロックをブロックチェーンに記録することができる。トランザクションをブロックチェーンに記録させるために、ユーザ（例えば、ブロックチェーンクライアントアプリケーション）は、ネットワークのノードのうちの１つにトランザクションを送信して、伝搬させる。トランザクションを受信したノードは、妥当性確認済みトランザクションを新しいブロックに組み込むプルーフオブワークの解を見つけようと競い合い得る。各ノードは、同じノードプロトコルを実施するように構成され、そのノードプロトコルには、トランザクションが有効であるための１つまたは複数の条件が含まれる。無効なトランザクションは、伝搬もブロックへの組込みもされない。トランザクションが妥当性確認され、それによってブロックチェーン上に受け入れられたと仮定すると、トランザクション（任意のユーザデータを含む）は、不変の公開記録としてブロックチェーンネットワーク内のノードの各々において登録およびインデックス付けされたままになる。
【0005】
プルーフオブワークパズルを解くのに成功して最新のブロックを作成したノードは、典型的には、ある額のデジタル資産、すなわちいくつかのトークンを配布する「コインベーストランザクション」と呼ばれる新しいトランザクションで報酬が与えられる。無効なトランザクションの検出および拒否は、ネットワークのエージェントとして機能し、不正を報告および阻止するようにインセンティブが与えられる競合ノードのアクションによって実施される。情報の広範な公開により、ユーザは、ノードの性能を連続的に監査することができる。単なるブロックヘッダの公開により、参加者は、ブロックチェーンの継続的な完全性を確実にすることができる。
【0006】
「出力ベースの」モデル（ＵＴＸＯベースモデルと呼ばれることもある）では、所与のトランザクションのデータ構造は、１つまたは複数の入力と１つまたは複数の出力とを含む。任意の使用可能な出力は、トランザクションの先行するシーケンスから導出可能なデジタル資産の額を指定する要素を含む。使用可能な出力は、ＵＴＸＯ（「未使用トランザクション出力」）と呼ばれることがある。出力は、出力を将来償還するための条件を指定するロックスクリプトをさらに含み得る。ロックスクリプトは、デジタルトークンまたは資産を妥当性確認および転送するために必要な条件を定義する述語（predicate）である。トランザクション（コインベーストランザクションを除く）の各入力は、先行するトランザクションにおけるそのような出力へのポインタ（すなわち、参照）を含み、指し示された出力のロックスクリプトをロック解除するためのロック解除スクリプトをさらに含み得る。そのため、トランザクションのペアを考慮して、それらを第１のトランザクションおよび第２のトランザクション（または「ターゲット」トランザクション）と呼ぶ。第１のトランザクションは、デジタル資産の額を指定する少なくとも１つの出力を含み、出力をロック解除する１つまたは複数の条件を定義するロックスクリプトを含む。第２のターゲットトランザクションは、第１のトランザクションの出力へのポインタを含む少なくとも１つの入力と、第１のトランザクションの出力をロック解除するためのロック解除スクリプトとを含む。
【0007】
そのようなモデルでは、第２のターゲットトランザクションがブロックチェーンネットワークに送信されて伝搬されブロックチェーンに記録されるとき、各ノードで適用される有効性の基準のうちの１つは、ロック解除スクリプトが第１のトランザクションのロックスクリプトで定義された１つまたは複数の条件のすべてを満たすことである。もう１つは、第１のトランザクションの出力が別の先の有効なトランザクションによってまだ償還されていないということである。これらの条件のいずれかにしたがってターゲットトランザクションが無効であることを発見したノードは、（無効なトランザクションを登録するために伝搬する可能性はあるが、有効なトランザクションとしては）それを伝搬することも、ブロックチェーンに記録されるように新しいブロックにそれを含めることもしない。
【0008】
トランザクションモデルの別のタイプは、アカウントベースのモデルである。このケースでは、各トランザクションは、過去のトランザクションのシーケンスにおける先行するトランザクションのＵＴＸＯを参照することによってではなく、絶対アカウント残高を参照することによって転送されるべき額を定義する。すべてのアカウントの現在の状態は、ブロックチェーンとは別個にノードによって記憶され、絶えず更新される。
【0009】
ＢＩＰ３２鍵導出プロトコルに基づく階層的決定論的（ＨＤ）ウォレットは、多くのデジタル鍵を導出するための便利で効率的な方法を提供する。ＢＩＰ３２ウォレットは、本質的に軽量で汎用性が高い。なぜなら、ユーザは、すべての鍵が導出されるウォレットシードをバックアップするだけでよく、ユーザの要件に基づいて異なる鍵導出経路を定義することができるからである。
【0010】
ウォレットプロバイダは、デジタルウォレットをより一層ユーザフレンドリにする追加の機能を提供する。１つのそのような例は、ユーザが自分のアイデンティティを自分のウォレット内の鍵にリンクすることができる場合である。ユーザが、自分のアイデンティティにリンクされた公に知られているＢＩＰ３２マスタ鍵を有すると仮定する。次いで、ユーザ（証明者）は、支払いを受け取るために別のユーザ（検証者）に与える子鍵を生成する。子鍵が強化されていない場合、検証者は、子鍵と証明者のアイデンティティとの間のリンクを検証することができる。トレードオフは、検証者が、公的に記録されたトランザクションにおいて、すなわち、オンチェーンで、証明者によって使用される他の強化されていない子鍵も決定する可能性があることである。代替的に、子鍵が強化されている場合、検証者は、子鍵を証明者のアイデンティティに直接リンクする必要があり、どちらの場合も最適ではない。強化されていない子鍵は、公開親鍵およびインデックスから導出することができるが、強化された子鍵は、私有親鍵およびインデックスからのみ導出することができる。
【発明の概要】
【0011】
本明細書に開示される一態様によれば、エンティティに関連付けられた子公開鍵の真正性を検証するコンピュータ実装方法が提供される。本方法は、コンピューティングデバイス上で実行され、子公開鍵を取得するステップと、証明コンピューティングデバイス（例えば、上記エンティティに関連付けられた証明コンピューティングデバイス）からゼロ知識証明を受信するステップと、ゼロ知識証明が有効であることを、証明、子公開鍵、および検証鍵を使用して検証して、鍵導出プロトコルが、親鍵から子公開鍵を導出するために使用されたことを決定するステップと、検証に基づいて子公開鍵の真正性を決定するステップとを含む。
【0012】
本明細書に開示される別の態様によれば、エンティティに関連付けられた子公開鍵の真正性の証明を提供するコンピュータ実装方法が提供される。本方法は、コンピューティングデバイス上で実行され、子公開鍵を導出するために使用される親鍵、子公開鍵、および証明鍵を使用してゼロ知識証明を生成するステップと、ゼロ知識証明を検証コンピューティングデバイスに送信して、検証コンピューティングデバイスが、親鍵から子公開鍵を導出するために鍵導出プロトコルが使用されたことを証明できるようにするステップとを含む。
【0013】
ゼロ知識証明（ＺＫＰ）は、証明者として知られる当事者が、検証者として知られる別の当事者に対して、ステートメントが真であることを、ステートメントが真であるという事実以外のいかなる情報も明らかにすることなく証明し得る方法である。本開示の実施形態では、ＺＫＰは、検証者に親鍵を明らかにすることなく、親鍵から子公開鍵を導出するために鍵導出プロトコル（例えば、ＢＩＰ３２鍵導出プロトコルまたは任意の他の鍵導出プロトコル）が使用されたことの証明を提供するために生成される。すなわち、「ゼロ知識証明」という用語は、本明細書では、機密／秘密データに関する情報が明らかにされない、証明者と検証者との間の知識の証明を意味するために使用される。
【0014】
本開示の実施形態は、特権エスカレーション攻撃に対してＨＤウォレットをセキュアにするために使用されることができ、子公開鍵を導出するために使用される親鍵を隠すことによって証明者のプライバシーを守る。
【図面の簡単な説明】
【0015】
本開示の実施形態の理解を助け、そのような実施形態がどのように実施され得るかを示すために、単なる例として、添付の図面を参照する。
【図1】ブロックチェーンを実装するためのシステムの概略ブロック図である。
【図2】ブロックチェーンに記録され得るトランザクションのいくつかの例を概略的に示す。
【図3A】クライアントアプリケーションの概略ブロック図である。
【図4】入力および出力のセットのためのＧｒｏｔｈ１６様ｚｋＳＮＡＲＫ構築のフェーズの概略ブロック図である。
【図5】ＢＩＰ３２鍵導出プロトコルを示す。
【図6】子公開鍵の真正性を証明および検証するためのプロセスを示す。
【図7】本発明の実施形態によるＢＩＰ３２子鍵導出関数を表す回路を示し、証明生成および証明検証プロセスにおいて、どの入力および出力が公開および秘密であるかを示す。
【図8】本発明のさらなる実施形態によるＢＩＰ３２子鍵導出関数を表す回路を示し、証明生成および証明検証プロセスにおいて、どの入力および出力が公開および秘密であるかを示す。
【図9】本発明の別の実施形態によるＢＩＰ３２子鍵導出関数を表す回路を示し、証明生成および証明検証プロセスにおいて、どの入力および出力が公開および秘密であるかを示す。
【図10】本発明のさらなる実施形態によるＢＩＰ３２子鍵導出関数を表す回路を示し、証明生成および証明検証プロセスにおいて、どの入力および出力が公開および秘密であるかを示す。
【図11a】子公開鍵の真正性を証明および検証するためのプロセスを示す。
【図11b】子公開鍵の真正性を証明および検証するためのプロセスを示す。
【図12】Ｘ．５０９デジタル証明書のデータ構造を示す。
【発明を実施するための形態】
【0016】
例示的なシステムの概要
図１は、ブロックチェーン１５０を実装するための例示的なシステム１００を示す。システム１００は、典型的にはインターネットなどの広域インターネットワークであるパケット交換ネットワーク１０１で構成され得る。パケット交換ネットワーク１０１は、パケット交換ネットワーク１０１内にピアツーピア（Ｐ２Ｐ）ネットワーク１０６を形成するように構成され得る複数のブロックチェーンノード１０４を含む。図示されていないが、ブロックチェーンノード１０４は、ほぼ完全なグラフとして構成され得る。したがって、各ブロックチェーンノード１０４は、他のブロックチェーンノード１０４に高度に接続される。
図１は、ブロックチェーン１５０を実装するための例示的なシステム１００を示す。システム１００は、典型的にはインターネットなどの広域インターネットワークであるパケット交換ネットワーク１０１で構成され得る。パケット交換ネットワーク１０１は、パケット交換ネットワーク１０１内にピアツーピア（Ｐ２Ｐ）ネットワーク１０６を形成するように構成され得る複数のブロックチェーンノード１０４を含む。図示されていないが、ブロックチェーンノード１０４は、ほぼ完全なグラフとして構成され得る。したがって、各ブロックチェーンノード１０４は、他のブロックチェーンノード１０４に高度に接続される。
【0017】
各ブロックチェーンノード１０４は、ピアのコンピュータ機器を含み、ノード１０４の異なるものは、異なるピアに属する。各ブロックチェーンノード１０４は、１つまたは複数のプロセッサ、例えば、１つまたは複数の中央処理装置（ＣＰＵ）、アクセラレータプロセッサ、特定用途向けプロセッサおよび／またはフィールドプログラマブルゲートアレイ（ＦＰＧＡ）、ならびに特定用途向け集積回路（ＡＳＩＣ）などの他の機器を含む処理装置を備える。各ノードはまた、メモリ、すなわち、１つまたは複数の非一時的コンピュータ可読媒体の形態のコンピュータ可読ストレージを備える。メモリは、１つまたは複数のメモリ媒体、例えば、ハードディスクなどの磁気媒体、ソリッドステートドライブ（ＳＳＤ）、フラッシュメモリもしくはＥＥＰＲＯＭなどの電子媒体、および／または光ディスクドライブなどの光学媒体を採用する１つまたは複数のメモリユニットを備え得る。
【0018】
ブロックチェーン１５０は、データブロック１５１のチェーンを含み、ブロックチェーン１５０のそれぞれのコピーは、分散型またはブロックチェーンネットワーク１０６内の複数のブロックチェーンノード１０４の各々で維持される。上述したように、ブロックチェーン１５０のコピーを維持することは、ブロックチェーン１５０を完全に記憶することを必ずしも意味しない。代わりに、ブロックチェーン１５０は、各ブロックチェーンノード１５０が各ブロック１５１のブロックヘッダ（後述する）を記憶している限り、データがプルーニングされ得る。チェーン内の各ブロック１５１は、１つまたは複数のトランザクション１５２を含み、この文脈におけるトランザクションは、データ構造の一種を指す。データ構造の性質は、トランザクションモデルまたは方式の一部として使用されるトランザクションプロトコルのタイプに依存する。所与のブロックチェーンは、全体を通して１つの特定のトランザクションプロトコルを使用する。１つの一般的なタイプのトランザクションプロトコルでは、各トランザクション１５２のデータ構造は、少なくとも１つの入力および少なくとも１つの出力を含む。各出力は、プロパティとしてデジタル資産の量を表す額を指定し、その例は、出力が暗号的にロックされている（ロック解除され、それによって償還または使用されるためにはそのユーザの署名または他の解決策を必要とする）ユーザ１０３である。各入力は、先行するトランザクション１５２の出力を指し示し、それによってトランザクションをリンクする。
【0019】
各ブロック１５１はまた、ブロック１５１への順番を定義するために、チェーン内の前に作成されたブロック１５１を指し示すブロックポインタ１５５を含む。各トランザクション１５２（コインベーストランザクション以外）は、トランザクションのシーケンスへの順序を定義するために、前のトランザクションへ戻るポインタを含む（注意：トランザクション１５２のシーケンスは分岐することが可能である）。ブロック１５１のチェーンは、チェーン内の最初のブロックであったジェネシスブロック（Ｇｂ：genesis block）１５３まで戻る。チェーン１５０内の早期にある１つまたは複数の元のトランザクション１５２は、先行するトランザクションではなくジェネシスブロック１５３を指し示していた。
【0020】
ブロックチェーンノード１０４の各々は、トランザクション１５２を他のブロックチェーンノード１０４にフォワードし、それによってトランザクション１５２をネットワーク１０６全体に伝搬させるように構成される。各ブロックチェーンノード１０４は、ブロック１５１を作成し、同じブロックチェーン１５０のそれぞれのコピーをそれらのそれぞれのメモリに記憶するように構成される。各ブロックチェーンノード１０４はまた、ブロック１５１に組み込まれるのを待っているトランザクション１５２の順序付きセット（またはプール）１５４を維持する。順序付きプール１５４は、「メムプール（mempool）」と呼ばれることが多い。本明細書におけるこの用語は、任意の特定のブロックチェーン、プロトコル、またはモデルに限定することを意図するものではない。これは、ノード１０４が有効であるとして受け入れたトランザクションの順序付きセットを指し、それに対して、ノード１０４は、同じ出力を使用しようとする他のトランザクションを受け入れないように義務付けられている。
【0021】
所与の現在のトランザクション１５２ｊにおいて、その入力（または各入力）は、トランザクションのシーケンスにおける先行するトランザクション１５２ｉの出力を参照するポインタを含み、この出力が現在のトランザクション１５２ｊにおいて償還または「使用」されるべきであることを指定する。一般に、先行するトランザクションは、順序付きセット１５４または任意のブロック１５１内の任意のトランザクションであり得る。先行するトランザクション１５２ｉは、現在のトランザクションが有効となるためには存在および妥当性確認される必要があるが、先行するトランザクション１５２ｉは、現在のトランザクション１５２ｊが作成されるときまたはネットワーク１０６に送信されるときに必ずしも存在する必要はない。したがって、本明細書における「先行する（preceding）」は、ポインタによってリンクされた論理シーケンスにおける先行するものを指し、必ずしも時間シーケンスにおける作成または送信の時間を指すものではなく、したがって、トランザクション１５２ｉ、１５２ｊが順不同に作成または送信されることを必ずしも除外するものではない（オーファントランザクションに関する以下の説明を参照）。先行するトランザクション１５２ｉは、同様に、先のトランザクション（antecedent transaction）または先行したトランザクション（predecessor transaction）とも呼ばれる。
【0022】
現在のトランザクション１５２ｊの入力はまた、入力認可、例えば、先行するトランザクション１５２ｉの出力がロックされている対象のユーザ１０３ａの署名を含む。次に、現在のトランザクション１５２ｊの出力は、新しいユーザまたはエンティティ１０３ｂに暗号的にロックされ得る。したがって、現在のトランザクション１５２ｊは、先行するトランザクション１５２ｉの入力において定義された額を、現在のトランザクション１５２ｊの出力において定義されたように、新しいユーザまたはエンティティ１０３ｂに転送することができる。いくつかのケースでは、トランザクション１５２は、複数のユーザまたはエンティティ（そのうちの１つは残り（change）を与えるために元のユーザまたはエンティティ１０３ａであり得る）間で入力額を分割するために複数の出力を有し得る。いくつかのケースでは、トランザクションはまた、１つまたは複数の先行するトランザクションの複数の出力からの額をまとめ、現在のトランザクションの１つまたは複数の出力に再分配するために複数の入力を有することができる。
【0023】
ビットコインなどの出力ベースのトランザクションプロトコルによれば、個々のユーザまたは組織などの当事者１０３が（手動でまたは当事者によって採用される自動プロセスによって）新しいトランザクション１５２ｊを制定することを望むとき、制定を行う当事者は、新しいトランザクションをそのコンピュータ端末１０２から受信者に送信する。制定を行う当事者または受信者は、最終的に、このトランザクションをネットワーク１０６のブロックチェーンノード１０４の１つまたは複数（これは、現在では、典型的にはサーバまたはデータセンタであるが、原則として他のユーザ端末であってもよい）に送信する。新しいトランザクション１５２ｊを制定する当事者１０３がトランザクションをブロックチェーンノード１０４の１つまたは複数に直接送信し、いくつかの例では、受信者に送信しないことも除外されない。トランザクションを受信するブロックチェーンノード１０４は、ブロックチェーンノード１０４の各々で適用されるブロックチェーンノードプロトコルにしたがって、トランザクションが有効であるかどうかをチェックする。ブロックチェーンノードプロトコルは、典型的には、新しいトランザクション１５２ｊ内の暗号署名が、トランザクション１５２の順序付きシーケンス内で前のトランザクション１５２ｉに依存する予想される署名と一致することをチェックするようにブロックチェーンノード１０４に要求する。そのような出力ベースのトランザクションプロトコルでは、これは、新しいトランザクション１５２ｊの入力に含まれる当事者１０３の暗号署名または他の認可が、新しいトランザクションが割り当てる先行するトランザクション１５２ｉの出力において定義される条件と一致することをチェックすることを含み得、この条件は、典型的には、新しいトランザクション１５２ｊの入力における暗号署名または他の認可が、新しいトランザクションの入力がリンクされている前のトランザクション１５２ｉの出力をロック解除することを少なくともチェックすることを含む。条件は、先行するトランザクション１５２ｉの出力に含まれるスクリプトによって少なくとも部分的に定義され得る。代替的に、それは、単にブロックチェーンノードプロトコルのみによって固定されてもよいし、これらの組合せによるものであってもよい。いずれにしても、新しいトランザクション１５２ｊが有効である場合、ブロックチェーンノード１０４は、それをブロックチェーンネットワーク１０６内の１つまたは複数の他のブロックチェーンノード１０４にフォワードする。これらの他のブロックチェーンノード１０４は、同じブロックチェーンノードプロトコルにしたがって同じテストを適用し、そして、新しいトランザクション１５２ｊを１つまたは複数のさらなるノード１０４にフォワードし、以下同様である。このようにして、新しいトランザクションはブロックチェーンノード１０４のネットワーク全体に伝搬される。
【0024】
出力ベースのモデルでは、所与の出力（例えば、ＵＴＸＯ）が割り当てられる（例えば、「使用される」）かどうかの定義は、それがブロックチェーンノードプロトコルにしたがって別の以降のトランザクション１５２ｊの入力によって有効に償還されたかどうかである。トランザクションが有効であるための別の条件は、それが償還しようとする先行するトランザクション１５２ｉの出力が、別のトランザクションによってまだ償還されていないことである。この場合も同様に、有効ではない場合、トランザクション１５２ｊは、（無効としてフラグ付けされ、警告のために伝搬されない限り）伝搬されることも、ブロックチェーン１５０内に記録されることもない。これは、トランザクタ（transactor）が同じトランザクションの出力を複数回割り当てようとする二重使用（double-spending）を防止する。一方、アカウントベースのモデルは、アカウント残高を維持することによって二重使用を防止する。ここでも、トランザクション順序が定義されているので、アカウント残高は常に単一の定義された状態にある。
【0025】
トランザクションを妥当性確認することに加えて、ブロックチェーンノード１０４はまた、「プルーフオブワーク」によって支持される、一般にマイニングと呼ばれるプロセスにおいてトランザクションのブロックを最初に作成しようと競い合う。ブロックチェーンノード１０４において、新しいトランザクションが、ブロックチェーン１５０上に記録されたブロック１５１内にまだ現れていない有効なトランザクションの順序付きプール１５４に追加される。次いで、ブロックチェーンノードは、暗号パズルを解こうとすることで、トランザクションの順序付きセット１５４からトランザクション１５２の新しい有効なブロック１５１を組み立てようと競い合う。典型的には、これは、ナンスが保留中のトランザクションの順序付きプール１５４の表現と連結されハッシュされたときにハッシュの出力が所定の条件を満たすような「ナンス」値を探索することを含む。例えば、所定の条件とは、ハッシュの出力が特定の所定の数の先行ゼロを有することであり得る。これは、プルーフオブワークパズルの１つの特定のタイプにすぎず、他のタイプが除外されないことに留意されたい。ハッシュ関数のプロパティは、その入力に対して予測不可能な出力を持つことである。したがって、この探索は、総当たりでしか実行することができないので、パズルを解こうとしている各ブロックチェーンノード１０４でかなりの量の処理リソースを消費する。
【0026】
最初にパズルを解いたブロックチェーンノード１０４は、これをネットワーク１０６に公表し、後にネットワーク内の他のブロックチェーンノード１０４によって容易にチェックすることができるその解をプルーフとして提供する（ハッシュに対する解が与えられると、ハッシュの出力が条件を満たすことをチェックすることは簡単である）。この最初のブロックチェーンノード１０４は、ブロックを、このブロックを受け入れる他のノードのしきい値コンセンサスに伝搬し、プロトコルルールを施行する。次いで、トランザクションの順序付きセット１５４は、ブロックチェーンノード１０４の各々によってブロックチェーン１５０内に新しいブロック１５１として記録されるようになる。ブロックポインタ１５５はまた、チェーン内の前に作成されたブロック１５１ｎ－１を指し示す新しいブロック１５１ｎに割り当てられる。プルーフオブワークの解を作成するために必要とされる、例えばハッシュの形態の、かなりの量の労力は、ブロックチェーンプロトコルのルールに従うという最初のノード１０４の意図を示す。そのようなルールは、前に妥当性確認されたトランザクションと同じ出力の割り当てを行った場合にトランザクションを有効として受け入れること（別名二重使用としても知られている）を行わないことを含む。ブロック１５１は、一旦作成されると、ブロックチェーンネットワーク１０６内のブロックチェーンノード１０４の各々において認識および維持されるので、修正することができない。ブロックポインタ１５５はまた、ブロック１５１に順番を付与する。トランザクション１５２は、ネットワーク１０６内の各ブロックチェーンノード１０４において順序付きブロックに記録されるので、これは、トランザクションの不変の公開台帳を提供する。
【0027】
任意の所与の時間にパズルを解こうと競い合う異なるブロックチェーンノード１０４は、それらがいつ解を探索し始めたかまたはトランザクションが受信された順序に応じて、任意の所与の時間に、まだ公開されていないトランザクションのプール１５４の異なるスナップショットに基づいてそれを行っていてもよいことに留意されたい。誰がそれぞれのパズルを最初に解いても、どのトランザクション１５２が次の新しいブロック１５１ｎにどの順序で含まれるかを定義し、公開されていないトランザクションの現在のプール１５４が更新される。次いで、ブロックチェーンノード１０４は、新たに定義された、公開されていないトランザクションの順序付きプール１５４からブロックを作成しようと競い合い続け、以下同様である。２つのブロックチェーンノード１０４が互いに非常に短い時間内にパズルを解いて、ブロックチェーンの相反する見解がノード１０４間で伝搬される場合に発生し得る任意の「フォーク」を解決するためのプロトコルも存在する。要するに、フォークのどちらのプロングでも最も長く成長した方が、確定的なブロックチェーン１５０となる。同じトランザクションが両方のフォークに現れるので、これがネットワークのユーザまたはエージェントに影響を与えないことに留意されたい。
【0028】
ビットコインブロックチェーン（およびほとんどの他のブロックチェーン）によれば、新しいブロック１０４の構築に成功したノードには、（あるエージェントまたはユーザから別のエージェントまたはユーザにある額のデジタル資産を転送するエージェント間またはユーザ間のトランザクションとは対照的に）追加の定義された量のデジタル資産を分配する新しい特別な種類のトランザクションにおいて、受け入れられた追加の額のデジタル資産を新たに割り当てる能力が与えられる。この特別なタイプのトランザクションは、通常、「コインベーストランザクション」と呼ばれるが、「開始トランザクション（initiation transaction）」または「生成トランザクション（generation transaction）」と称されることもある。これは典型的に、新しいブロック１５１ｎの最初のトランザクションを形成する。プルーフオブワークは、新しいブロックを構築するノードが、この特別なトランザクションが後に償還されることを可能にするプロトコルルールに従うという意図を示す。ブロックチェーンプロトコルルールは、この特別なトランザクションが償還され得る前に、満期期間、例えば１００個のブロックを必要とし得る。多くの場合、通常の（非生成）トランザクション１５２はまた、そのトランザクションが公開されたブロック１５１ｎを作成したブロックチェーンノード１０４にさらに報酬を与えるために、その出力のうちの１つにおいて追加のトランザクション手数料を指定する。この手数料は通常「トランザクション手数料」と呼ばれ、以下で説明される。
【0029】
トランザクション妥当性確認および公開に関与するリソースに起因して、典型的には、ブロックチェーンノード１０４の少なくとも各々は、１つまたは複数の物理サーバユニットで構成されるサーバの形態をとるか、さらにはデータセンタ全体の形態をとる。しかしながら、原則として、任意の所与のブロックチェーンノード１０４は、ユーザ端末または互いにネットワーク化されたユーザ端末のグループの形態をとることができる。
【0030】
各ブロックチェーンノード１０４のメモリは、そのそれぞれの１つまたは複数の役割を実行し、ブロックチェーンノードプロトコルにしたがってトランザクション１５２を処理するために、ブロックチェーンノード１０４の処理装置上で実行されるように構成されたソフトウェアを記憶する。本明細書においてブロックチェーンノード１０４に帰する任意のアクションは、それぞれのコンピュータ機器の処理装置上で実行されるソフトウェアによって実行され得ることが理解されよう。ノードソフトウェアは、アプリケーション層、またはオペレーティングシステム層もしくはプロトコル層などの下位層、またはこれらの任意の組合せにおける１つまたは複数のアプリケーションにおいて実装され得る。
【0031】
消費ユーザの役割を担う複数の当事者１０３の各々のコンピュータ機器１０２もネットワーク１０１に接続されている。これらのユーザは、ブロックチェーンネットワーク１０６と対話し得るが、トランザクションの妥当性確認にもブロックの構築にも参加しない。これらのユーザまたはエージェント１０３のうちのいくつかは、トランザクションの送信者および受信者として機能し得る。他のユーザは、必ずしも送信者または受信者として動作することなくブロックチェーン１５０と対話し得る。例えば、一部の当事者は、ブロックチェーン１５０のコピーを記憶する（例えば、ブロックチェーンノード１０４からブロックチェーンのコピーを取得した）ストレージエンティティとして動作し得る。
【0032】
当事者１０３のうちのいくつかまたはすべては、異なるネットワーク、例えば、ブロックチェーンネットワーク１０６の上にオーバーレイされたネットワークの一部として接続され得る。ブロックチェーンネットワークのユーザ（「クライアント」と呼ばれことが多い）は、ブロックチェーンネットワーク１０６を含むシステムの一部であるといえるが、これらのユーザは、ブロックチェーンノードに要求される役割を果たさないので、ブロックチェーンノード１０４ではない。代わりに、各当事者１０３はブロックチェーンネットワーク１０６と対話してもよく、それによって、ブロックチェーンノード１０６に接続する（すなわち通信する）ことでブロックチェーン１５０を利用し得る。２つの当事者１０３およびそれらのそれぞれの機器１０２、すなわち、第１の当事者１０３ａおよびそのそれぞれのコンピュータ機器１０２ａ、ならびに第２の当事者１０３ｂおよびそのそれぞれのコンピュータ機器１０２ｂは、例示の目的で示されている。そのような当事者１０３およびそれらのそれぞれのコンピュータ機器１０２ははるかに多く存在し、システム１００に参加し得るが、便宜上、それらは図示されていないことが理解されよう。各当事者１０３は、個人または組織であり得る。純粋に例示として、第１の当事者１０３ａは、本明細書ではアリスと呼ばれ、第２の当事者１０３ｂはボブと呼ばれるが、これは限定的なものではなく、本明細書におけるアリスまたはボブへのいかなる言及も、それぞれ「第１の当事者」および「第２の当事者」と置き換えられ得ることが理解されよう。
【0033】
各当事者１０３のコンピュータ機器１０２は、１つまたは複数のプロセッサ、例えば、１つまたは複数のＣＰＵ、ＧＰＵ、他のアクセラレータプロセッサ、特定用途向けプロセッサ、および／またはＦＰＧＡを含むそれぞれの処理装置を備える。各当事者１０３のコンピュータ機器１０２は、メモリ、すなわち、１つまたは複数の非一時的コンピュータ可読媒体の形態のコンピュータ可読ストレージをさらに備える。このメモリは、１つまたは複数のメモリ媒体、例えば、ハードディスクなどの磁気媒体、ＳＳＤ、フラッシュメモリもしくはＥＥＰＲＯＭなどの電子媒体、および／または光ディスクドライブなどの光学媒体を採用する１つまたは複数のメモリユニットを備え得る。各当事者１０３のコンピュータ機器１０２上のメモリは、処理装置上で実行されるように構成された少なくとも１つのクライアントアプリケーション１０５のそれぞれのインスタンスを含むソフトウェアを記憶する。本明細書において所与の当事者１０３に帰する任意のアクションは、それぞれのコンピュータ機器１０２の処理装置上で実行されるソフトウェアを使用して実行され得ることが理解されよう。各当事者１０３のコンピュータ機器１０２は、少なくとも１つのユーザ端末、例えば、デスクトップもしくはラップトップコンピュータ、タブレット、スマートフォン、またはスマートウォッチなどのウェアラブルデバイスを含む。所与の当事者１０３のコンピュータ機器１０２はまた、ユーザ端末を介してアクセスされるクラウドコンピューティングリソースなどの１つまたは複数の他のネットワーク化されたリソースを含み得る。
【0034】
クライアントアプリケーション１０５は、最初に、１つまたは複数の適切なコンピュータ可読ストレージ上で任意の所与の当事者１０３のコンピュータ機器１０２に提供され得、例えば、サーバからダウンロードされ得るか、またはリムーバブルＳＳＤ、フラッシュメモリキー、リムーバブルＥＥＰＲＯＭ、リムーバブル磁気ディスクドライブ、磁気フロッピーディスクもしくはテープ、ＣＤもしくはＤＶＤ ＲＯＭなどの光ディスク、またはリムーバブル光学ドライブなどのリムーバブル記憶デバイス上で提供され得る。
【0035】
クライアントアプリケーション１０５は、少なくとも「ウォレット」機能を備える。これは２つの主要な機能を有する。これらのうちの１つは、それぞれの当事者１０３が、トランザクション１５２を作成し、認可し（例えば署名し）、１つまたは複数のビットコインノード１０４に送信することを可能にして、トランザクション１５２をブロックチェーンノード１０４のネットワーク全体に伝搬させ、それによってブロックチェーン１５０に含まれるようにすることである。もう１つは、それぞれの当事者に、その当事者が現在所有しているデジタル資産の額を報告することである。出力ベースのシステムでは、この第２の機能は、当該当事者に属するブロックチェーン１５０全体に散在している様々なトランザクション１５２の出力において定義された額を照合することを含む。
【0036】
様々なクライアント機能が、所与のクライアントアプリケーション１０５に統合されるものとして説明され得るが、必ずしもこれに限定されるものではなく、代わりに、本明細書で説明される任意のクライアント機能は、例えば、ＡＰＩを介してインターフェースする、または一方が他方へのプラグインである２つ以上の別個のアプリケーション一式において実装され得ることに留意されたい。より一般的には、クライアント機能は、アプリケーション層もしくはオペレーティングシステムなどの下位層、またはこれらの任意の組合せにおいて実装され得る。以下では、クライアントアプリケーション１０５に関して説明するが、これに限定されないことが理解されよう。
【0037】
各コンピュータ機器１０２上のクライアントアプリケーションまたはソフトウェア１０５のインスタンスは、ネットワーク１０６のブロックチェーンノード１０４のうちの少なくとも１つに動作可能に結合される。これにより、クライアント１０５のウォレット機能はトランザクション１５２をネットワーク１０６に送信することができる。クライアント１０５はまた、それぞれの当事者１０３が受信者である任意のトランザクションについてブロックチェーン１５０にクエリを行うためにブロックチェーンノード１０４にコンタクトすることができる（または、実施形態では、ブロックチェーン１５０は、部分的にその公開性（public visibility）を通じてトランザクションにおける信頼を提供する公共施設であるので、実際にブロックチェーン１５０における他の当事者のトランザクションを検査する）。各コンピュータ機器１０２上のウォレット機能は、トランザクションプロトコルにしたがってトランザクション１５２を定式化し、送信するように構成される。上述したように、各ブロックチェーンノード１０４は、ブロックチェーンノードプロトコルにしたがってトランザクション１５２を妥当性確認し、トランザクション１５２をフォワードして、それらをブロックチェーンネットワーク１０６全体に伝搬するように構成されたソフトウェアを実行する。トランザクションプロトコルおよびノードプロトコルは互いに対応し、所与のトランザクションプロトコルは所与のノードプロトコルに従い（go with）、一緒に所与のトランザクションモデルを実装する。ブロックチェーン１５０内のすべてのトランザクション１５２に対して同じトランザクションプロトコルが使用される。ネットワーク１０６内のすべてのノード１０４によって同じノードプロトコルが使用される。
【0038】
所与の当事者１０３、例えばアリスが、ブロックチェーン１５０に含まれるべき新しいトランザクション１５２ｊを送信することを望むとき、アリスは、関連トランザクションプロトコルにしたがって（アリスのクライアントアプリケーション１０５内のウォレット機能を使用して）新しいトランザクションを定式化する。次いで、アリスは、クライアントアプリケーション１０５から、アリスが接続されている１つまたは複数のブロックチェーンノード１０４にトランザクション１５２を送信する。例えば、これは、アリスのコンピュータ１０２に最良に接続されたブロックチェーンノード１０４であり得る。任意の所与のブロックチェーンノード１０４は、新しいトランザクション１５２ｊを受信すると、ブロックチェーンノードプロトコルおよびそのそれぞれの役割にしたがってそれを処理する。これには、新たに受信されたトランザクション１５２ｊが「有効」であるための特定の条件を満たすかを最初にチェックすることが含まれ、その例については、以下でより詳細に説明する。いくつかのトランザクションプロトコルでは、妥当性確認のための条件は、トランザクション１５２に含まれるスクリプトによってトランザクションごとに構成可能であり得る。代替的に、条件は、単にノードプロトコルの組込み特徴であってもよいし、スクリプトとノードプロトコルとの組合せによって定義されてもよい。
【0039】
新たに受信されたトランザクション１５２ｊが、有効であるとみなされるためのテストにパスすることを条件として（すなわち、それが「妥当性確認済み」であることを条件として）、トランザクション１５２ｊを受信する任意のブロックチェーンノード１０４は、そのブロックチェーンノード１０４において維持されるトランザクションの順序付きセット１５４に新たな妥当性確認済みトランザクション１５２を追加する。さらに、トランザクション１５２ｊを受信する任意のブロックチェーンノード１０４は、妥当性確認済みトランザクション１５２をネットワーク１０６内の１つまたは複数の他のブロックチェーンノード１０４に伝搬する。各ブロックチェーンノード１０４は同じプロトコルを適用するので、トランザクション１５２ｊが有効であると仮定すると、これは、ネットワーク１０６全体にわたってすぐに伝搬されることを意味する。
【0040】
所与のブロックチェーンノード１０４において維持される保留中のトランザクションの順序付きプール１５４に承認されると、そのブロックチェーンノード１０４は、新しいトランザクション１５２を含むそれぞれのプール１５４の最新バージョンに対してプルーフオブワークパズルを解こうと競い始める（他のブロックチェーンノード１０４が、トランザクションの異なるプール１５４に基づいてパズルを解こうと試みている可能性があるが、どのノードでも最初に解いたものが、最新のブロック１５１に含まれるトランザクションのセットを定義することを想起されたい。最終的に、ブロックチェーンノード１０４は、アリスのトランザクション１５２ｊを含む順序付きプール１５４の一部についてパズルを解くことになる。）新しいトランザクション１５２ｊを含むプール１５４に対してプルーフオブワークが行われると、それは普遍的にブロックチェーン１５０内のブロック１５１のうちの１つの一部となる。各トランザクション１５２は、先のトランザクションへ戻るポインタを含むので、トランザクションの順序も不変的に記録される。
【0041】
異なるブロックチェーンノード１０４は、最初、所与のトランザクションの異なるインスタンスを受信し得るので、１つのインスタンスが新しいブロック１５１において公開される（この時点で、公開されたインスタンスが唯一の有効なインスタンスであることにすべてのブロックチェーンノード１０４が同意している）までは、どのインスタンスが「有効」であるかについて相反する見解を有する。ブロックチェーンノード１０４が１つのインスタンスを有効として受け入れ、次いで、別のインスタンスがブロックチェーン１５０に記録されていることを発見した場合、そのブロックチェーンノード１０４は、これを受け入れなければならず、最初に受け入れたインスタンス（すなわち、ブロック１５１で公開されていないもの）を破棄する（すなわち、無効として扱う）。
【0042】
いくつかのブロックチェーンネットワークによって運用される代替タイプのトランザクションプロトコルは、アカウントベースのトランザクションモデルの一部として、「アカウントベース」プロトコルと呼ばれ得る。アカウントベースのケースでは、各トランザクションは、過去のトランザクションのシーケンスにおける先行するトランザクションのＵＴＸＯを参照することによってではなく、絶対アカウント残高を参照することによって転送されるべき額を定義する。すべてのアカウントの現在の状態は、ブロックチェーンとは別個にそのネットワークのノードによって記憶され、絶えず更新される。そのようなシステムでは、トランザクションは、アカウントの実行中のトランザクションタリー（「ポジション」とも呼ばれる）を使用して順序付けられる。この値は、送信者によってその暗号署名の一部として署名され、トランザクション参照計算の一部としてハッシュされる。加えて、トランザクションにおけるオプションのデータフィールドも署名され得る。このデータフィールドは、例えば、前のトランザクションＩＤがデータフィールドに含まれている場合、前のトランザクションを指し示し得る。
【0043】
ＵＴＸＯベースのモデル
図２は、例示的なトランザクションプロトコルを示す。これは、ＵＴＸＯベースのプロトコルの一例である。トランザクション１５２（「Ｔｘ」と略記される）は、ブロックチェーン１５０の基本的なデータ構造である（各ブロック１５１は１つまたは複数のトランザクション１５２を含む）。以下では、出力ベースまたは「ＵＴＸＯ」ベースのプロトコルを参照して説明する。しかしながら、これはすべての可能な実施形態に限定されるものではない。例示的なＵＴＸＯベースのプロトコルは、ビットコインを参照して説明されるが、他の例示的なブロックチェーンネットワーク上でも等しく実装され得ることに留意されたい。
図２は、例示的なトランザクションプロトコルを示す。これは、ＵＴＸＯベースのプロトコルの一例である。トランザクション１５２（「Ｔｘ」と略記される）は、ブロックチェーン１５０の基本的なデータ構造である（各ブロック１５１は１つまたは複数のトランザクション１５２を含む）。以下では、出力ベースまたは「ＵＴＸＯ」ベースのプロトコルを参照して説明する。しかしながら、これはすべての可能な実施形態に限定されるものではない。例示的なＵＴＸＯベースのプロトコルは、ビットコインを参照して説明されるが、他の例示的なブロックチェーンネットワーク上でも等しく実装され得ることに留意されたい。
【0044】
ＵＴＸＯベースのモデルでは、各トランザクション（「Ｔｘ」）１５２は、１つまたは複数の入力２０２および１つまたは複数の出力２０３を含むデータ構造を含む。各出力２０３は、未使用トランザクション出力（ＵＴＸＯ）を含み得、これは、（ＵＴＸＯがまだ償還されていない場合）別の新しいトランザクションの入力２０２のソースとして使用され得る。ＵＴＸＯは、デジタル資産の額を指定する値を含む。これは、分散型台帳上のトークンの設定数を表す。ＵＴＸＯはまた、他の情報の中でも、元となるトランザクションのトランザクションＩＤを含み得る。トランザクションデータ構造は、入力フィールド（複数可）２０２および出力フィールド（複数可）２０３のサイズを示すインジケータを含み得るヘッダ２０１も含み得る。ヘッダ２０１はまた、トランザクションのＩＤを含み得る。実施形態では、トランザクションＩＤは、（トランザクションＩＤ自体を除く）トランザクションデータのハッシュであり、ノード１０４にサブミットされる生のトランザクション１５２のヘッダ２０１に記憶される。
【0045】
アリス１０３ａが、当該デジタル資産の額をボブ１０３ｂに転送するトランザクション１５２ｊを作成することを望むとする。図２では、アリスの新しいトランザクション１５２ｊは「Ｔｘ１」とラベル付けされている。これは、シーケンス内の先行するトランザクション１５２ｉの出力２０３においてアリスにロックされたデジタル資産の額をとり、これのうちの少なくとも一部をボブに転送する。先行するトランザクション１５２ｉは、図２では「Ｔｘ０」とラベル付けされている。Ｔｘ０およびＴｘ１は、単なる任意のラベルである。それらは、Ｔｘ０がブロックチェーン１５１内の最初のトランザクションであること、またはＴｘ１がプール１５４内のすぐ次のトランザクションであることを必ずしも意味するものではない。Ｔｘ１は、アリスにロックされた未使用の出力２０３を依然として有する任意の先行する（すなわち先の）トランザクションを指し示すことができる。
【0046】
先行するトランザクションＴｘ０は、アリスが新しいトランザクションＴｘ１を作成した時点では、または少なくともアリスがそれをネットワーク１０６に送信する時点までには、すでに妥当性確認されブロックチェーン１５０のブロック１５１に含まれている可能性がある。それは、その時点でブロック１５１のうちの１つにすでに含まれていてもよいし、順序付きセット１５４で依然として待機していてもよく、このケースでは、すぐに新しいブロック１５１に含まれることになる。代替的に、Ｔｘ０およびＴｘ１を作成してネットワーク１０６に一緒に送信することもできるし、ノードプロトコルが「オーファン」トランザクションのバッファリングを可能にする場合には、Ｔｘ０をＴｘ１の後に送信することさえもできる。トランザクションのシーケンスの文脈において本明細書で使用される「先行する」および「後続する」という用語は、トランザクション内で指定されているトランザクションポインタ（どのトランザクションがどの他のトランザクションを指し示すかなど）によって定義されるシーケンス内のトランザクションの順序を指す。それらは、同様に、「先行するもの（predecessor）」および「後続するもの（successor）」、または「先の（antecedent）」および「後の（descendant）」、「親（parent）」および「子（child）」などと置き換えられ得る。これは、それらの作成、ネットワーク１０６への送信、または任意の所与のブロックチェーンノード１０４への到着の順序を必ずしも意味するものではない。それにもかかわらず、先行するトランザクション（先のトランザクションまたは「親」）を指し示す後続するトランザクション（後のトランザクションまたは「子」）は、親トランザクションが妥当性確認されない限り、妥当性確認されない。親より前にブロックチェーンノード１０４に到着する子は、オーファンとみなされる。それは、ノードプロトコルおよび／またはノード挙動に応じて、親を待つために特定の時間バッファされるかまたは破棄され得る。
【0047】
先行するトランザクションＴｘ０の１つまたは複数の出力２０３のうちの１つは、本明細書ではＵＴＸＯ０とラベル付けされた特定のＵＴＸＯを含む。各ＵＴＸＯは、ＵＴＸＯによって表されるデジタル資産の額を指定する値と、ロックスクリプトとを含み、ロックスクリプトは、後続するトランザクションが妥当性確認され、したがってＵＴＸＯが正常に償還されるために、後続するトランザクションの入力２０２内のロック解除スクリプトが満たさなければならない条件を定義する。典型的には、ロックスクリプトは、その額を特定の当事者（それが含まれるトランザクションの受益者）にロックする。すなわち、ロックスクリプトは、典型的には、後続するトランザクションの入力内のロック解除スクリプトに、先行するトランザクションがロックされる当事者の暗号署名が含まれるという条件を含むロック解除条件を定義する。
【0048】
ロックスクリプト（通称scriptPubKey）は、ノードプロトコルによって認識されるドメイン固有言語で書かれたコードの一部分である。そのような言語の特定の例は、ブロックチェーンネットワークによって使用される「スクリプト（Script）」（大文字Ｓ）と呼ばれる。ロックスクリプトは、トランザクション出力２０３を使用するためにどの情報が必要とされるか、例えばアリスの署名の必要性、を指定する。ロック解除スクリプトはトランザクションの出力に現れる。ロック解除スクリプト（通称scriptSig）は、ロックスクリプト基準を満たすのに必要な情報を提供するドメイン固有言語で書かれたコードの一部分である。例えば、それはボブの署名を含み得る。ロック解除スクリプトは、トランザクションの入力２０２に現れる。
【0049】
つまり、図示の例では、Ｔｘ０の出力２０３内のＵＴＸＯ０は、ＵＴＸＯ０が償還されるために（厳密には、ＵＴＸＯ０を償還しようとする後続するトランザクションが有効となるために）アリスの署名Sig ＰＡを必要とするロックスクリプト[Checksig PA]を含む。[Checksig PA]は、アリスの公開鍵－私有鍵ペアの公開鍵ＰＡの表現（すなわち、ハッシュ）を含む。Ｔｘ１の入力２０２は、（例えば、実施形態ではトランザクションＴｘ０全体のハッシュであるそのトランザクションＩＤ、ＴｘＩＤ０によって）Ｔｘ１を指し示すポインタを含む。Ｔｘ１の入力２０２は、Ｔｘ０の任意の他の可能な出力の中からＵＴＸＯ０を識別するために、Ｔｘ０内のＵＴＸＯ０を識別するインデックスを含む。Ｔｘ１の入力２０２は、アリスが鍵ペアのアリスの私有鍵をデータの所定の部分（暗号では「メッセージ」と呼ばれることもある）に適用することによって作成された、アリスの暗号署名を含むロック解除スクリプト<Sig PA>をさらに含む。有効な署名を提供するためにアリスによって署名される必要があるデータ（または「メッセージ」）は、ロックスクリプトによって、またはノードプロトコルによって、またはこれらの組合せによって定義され得る。
【0050】
新しいトランザクションＴｘ１がブロックチェーンノード１０４に到着すると、ノードはノードプロトコルを適用する。これは、ロックスクリプトおよびロック解除スクリプトを一緒に実行して、ロック解除スクリプトがロックスクリプトで定義されている条件（この条件は１つまたは複数の基準を含み得る）を満たすかどうかをチェックすることを含む。実施形態では、これは２つのスクリプトを連結することを含む：
<Sig PA> <PA> || [Checksig PA]
ここで、「||」は連結を表し、「<…>」はデータをスタックに置くことを意味し、「[…]」はロックスクリプト（この例ではスタックベースの言語）で構成される関数である。同等に、スクリプトは、スクリプトを連結するのではなく、共通スタックを用いて次々に実行され得る。いずれにしても、一緒に実行されると、スクリプトは、Ｔｘ０の出力内のロックスクリプトに含まれるようなアリスの公開鍵ＰＡを使用して、Ｔｘ１の入力内のロック解除スクリプトが、データの予想される部分に署名するアリスの署名を含むことを認証する。この認証を実行するためには、データの予想される部分自体（「メッセージ」）も含まれる必要がある。実施形態では、署名されるデータはＴｘ１の全体を含む（つまり、平文のデータの署名された部分を指定する別個の要素は、すでに本質的に存在するので、含まれる必要がない）。
<Sig PA> <PA> || [Checksig PA]
ここで、「||」は連結を表し、「<…>」はデータをスタックに置くことを意味し、「[…]」はロックスクリプト（この例ではスタックベースの言語）で構成される関数である。同等に、スクリプトは、スクリプトを連結するのではなく、共通スタックを用いて次々に実行され得る。いずれにしても、一緒に実行されると、スクリプトは、Ｔｘ０の出力内のロックスクリプトに含まれるようなアリスの公開鍵ＰＡを使用して、Ｔｘ１の入力内のロック解除スクリプトが、データの予想される部分に署名するアリスの署名を含むことを認証する。この認証を実行するためには、データの予想される部分自体（「メッセージ」）も含まれる必要がある。実施形態では、署名されるデータはＴｘ１の全体を含む（つまり、平文のデータの署名された部分を指定する別個の要素は、すでに本質的に存在するので、含まれる必要がない）。
【0051】
公開－秘密暗号法による認証の詳細は、当業者によく知られている。基本的に、アリスが自身の私有鍵を使用してメッセージに署名した場合、アリスの公開鍵および平文のメッセージが与えられると、ノード１０４などの別のエンティティは、メッセージがアリスによって署名されたものに違いないことを認証することができる。署名は、典型的には、メッセージをハッシュし、ハッシュに署名し、これを署名としてメッセージにタグ付けすることを含み、これにより、公開鍵の任意の保持者が署名を認証することができるようになる。したがって、データの特定の部分またはトランザクションの一部などに署名することへの本明細書におけるいかなる参照も、実施形態では、データのその部分またはトランザクションの一部のハッシュに署名することを意味し得ることに留意されたい。
【0052】
Ｔｘ１内のロック解除スクリプトが、Ｔｘ０のロックスクリプト内で指定されている１つまたは複数の条件を満たす場合（つまり、図示の例では、アリスの署名がＴｘ１内で提供され、認証された場合）、ブロックチェーンノード１０４は、Ｔｘ１が有効であるとみなす。これは、ブロックチェーンノード１０４が、保留中のトランザクションの順序付きプール１５４にＴｘ１を追加することとなることを意味する。ブロックチェーンノード１０４はまた、トランザクションＴｘ１をネットワーク１０６内の１つまたは複数の他のブロックチェーンノード１０４にフォワードして、トランザクションＴｘ１がネットワーク１０６全体に伝搬されるようにする。Ｔｘ１が妥当性確認されてブロックチェーン１５０に含まれると、これは、Ｔｘ０からのＵＴＸＯ０を使用済みとして定義する。Ｔｘ１は、未使用トランザクション出力２０３を使用する場合にのみ有効になり得ることに留意されたい。別のトランザクション１５２によってすでに使用された出力を使用しようとする場合、Ｔｘ１は、他のすべての条件が満たされたとしても無効になる。したがって、ブロックチェーンノード１０４はまた、先行するトランザクションＴｘ０内の参照されたＵＴＸＯがすでに使用済みであるかどうか（すなわち、それが別の有効なトランザクションへの有効な入力をすでに形成したかどうか）をチェックする必要がある。これは、ブロックチェーン１５０がトランザクション１５２に定義された順序を課すことが重要である理由の１つである。実際には、所与のブロックチェーンノード１０４は、どのトランザクション１５２内のどのＵＴＸＯ２０３が使用されたかをマーキングする別個のデータベースを維持し得るが、最終的には、ＵＴＸＯが使用されたかどうかを定義するものは、ブロックチェーン１５０内の別の有効なトランザクションへの有効な入力をすでに形成しているかどうかである。
【0053】
所与のトランザクション１５２のすべての出力２０３において指定された総額が、そのすべての入力２０２によって指し示された総額よりも大きい場合、これは、ほとんどのトランザクションモデルにおいて無効性の別の根拠となる。そのため、そのようなトランザクションは、伝搬されることも、ブロック１５１に含まれることもない。
【0054】
ＵＴＸＯベースのトランザクションモデルでは、所与のＵＴＸＯが全体として使用される必要があることに留意されたい。ＵＴＸＯにおいて使用済みとして定義された額の一部は、別の一部が使用されている間、「残す」ことはできない。しかしながら、次のトランザクションの複数の出力間でＵＴＸＯからの額を分割することはできる。例えば、Ｔｘ０内のＵＴＸＯ０において定義された額を、Ｔｘ１内の複数のＵＴＸＯ間で分割することができる。したがって、アリスが、ＵＴＸＯ０において定義された額のすべてをボブに与えたくない場合、アリスは、リマインダを使用して、Ｔｘ１の第２の出力において自分自身に残りを与えるか、または別の当事者に支払うことができる。
【0055】
実際には、アリスはまた、通常、アリスのトランザクション１０４をブロック１５１に成功裏に含めるビットコインノード１０４に対する手数料を含める必要がある。アリスがそのような手数料を含めない場合、Ｔｘ０は、ブロックチェーンノード１０４によって拒否され得、したがって、技術的に有効であっても、伝搬されず、ブロックチェーン１５０に含まれない可能性がある（ノードプロトコルは、ブロックチェーンノード１０４が望まない場合にトランザクション１５２を受け入れることを強制しない）。いくつかのプロトコルでは、トランザクション手数料は、それ自体の別個の出力２０３を必要としない（すなわち、別個のＵＴＸＯを必要としない）。代わりに、所与のトランザクション１５２の入力（複数可）２０２によって指し示される総額と出力（複数可）２０３で指定されている総額との間の任意の差が、トランザクションを公開するブロックチェーンノード１０４に自動的に与えられる。例えば、ＵＴＸＯ０へのポインタがＴｘ１への唯一の入力であり、Ｔｘ１は唯一の出力ＵＴＸＯ１を有するとする。ＵＴＸＯ０において指定されたデジタル資産の額がＵＴＸＯ１において指定された額よりも大きい場合、その差分は、ＵＴＸＯ１を含むブロックを作成するためのプルーフオブワーク競争に勝つノード１０４によって割り当てられ得る。しかしながら、代替的にまたは追加的に、トランザクション手数料がトランザクション１５２のＵＴＸＯ２０３のうちのそれ自体の１つにおいて明示的に指定され得ることは必ずしも除外されない。
【0056】
アリスおよびボブのデジタル資産は、ブロックチェーン１５０内のどこかで任意のトランザクション１５２においてそれらにロックされたＵＴＸＯから構成される。したがって、典型的には、所与の当事者１０３の資産は、ブロックチェーン１５０全体にわたる様々なトランザクション１５２のＵＴＸＯ全体に散在している。ブロックチェーン１５０内のどこにも、所与の当事者１０３の総残高を定義する数字は記憶されない。クライアントアプリケーション１０５におけるウォレット機能の役割は、それぞれの当事者にロックされ、別の以降のトランザクションでまだ使用されていない様々なＵＴＸＯのすべての値を一緒に照合することである。これは、ビットコインノード１０４のいずれかに記憶されたブロックチェーン１５０のコピーにクエリを行うことによって行うことができる。
【0057】
スクリプトコードは、多くの場合、概略的に（すなわち、正確な言語を使用せずに）表されることに留意されたい。例えば、特定の機能を表すためにオペレーションコード（オペコード）が使用され得る。「OP_...」は、スクリプト言語の特定のオペコードを指す。例として、OP_RETURNは、ロックスクリプトの最初にOP_FALSEが先行するときに、トランザクション内にデータを記憶することができ、それによってデータをブロックチェーン１５０内に不変的に記録することができる、トランザクションの使用不可能な出力を作成するスクリプト言語のオペコードである。例えば、データは、ブロックチェーンに記憶することが望まれる文書を含み得る。
【0058】
典型的には、トランザクションの入力は、公開鍵ＰＡに対応するデジタル署名を含む。実施形態において、これは、楕円曲線ｓｅｃｐ２５６ｋ１を使用するＥＣＤＳＡに基づく。デジタル署名は、データの特定の一部分に署名する。いくつかの実施形態では、所与のトランザクションについて、署名は、トランザクション入力の一部、およびトランザクション出力の一部または全部に署名する。署名された出力の特定の部分は、ＳＩＧＨＡＳＨフラグに依存する。ＳＩＧＨＡＳＨフラグは、通常、どの出力が署名されるかを選択するために署名の最後に含まれる４バイトコードである（したがって、署名時に固定される）。
【0059】
ロックスクリプトは、典型的には、それぞれのトランザクションがロックされる当事者の公開鍵を含むという事実を指して、「scriptPubKey」と呼ばれることがある。ロック解除スクリプトは、典型的には、それが対応する署名を供給するという事実を指して「scriptSig」と呼ばれることがある。しかしながら、より一般的には、ＵＴＸＯが償還されるための条件が署名を認証することを含むことは、ブロックチェーン１５０のすべてのアプリケーションにおいて必須ではない。より一般的には、スクリプト言語を使用して、任意の１つまたは複数の条件を定義することができる。したがって、より一般的な用語「ロックスクリプト」および「ロック解除スクリプト」が好まれ得る。
【0060】
クライアントソフトウェア
図３Ａは、本開示の方式の実施形態を実装するためのクライアントアプリケーション１０５の例示的な実装形態を示す。クライアントアプリケーション１０５は、トランザクションエンジン４０１とユーザインターフェース（ＵＩ）層４０２とを備える。トランザクションエンジン４０１は、クライアント１０５の基礎となるトランザクション関連機能を実装するように構成され、例えば、上述される方式にしたがって、また、以下でさらに詳細に議論されるように、トランザクション１５２を定式化し、トランザクションを１つまたは複数のノード１０４に送信して、ブロックチェーンネットワーク１０６を介して伝搬させる。
図３Ａは、本開示の方式の実施形態を実装するためのクライアントアプリケーション１０５の例示的な実装形態を示す。クライアントアプリケーション１０５は、トランザクションエンジン４０１とユーザインターフェース（ＵＩ）層４０２とを備える。トランザクションエンジン４０１は、クライアント１０５の基礎となるトランザクション関連機能を実装するように構成され、例えば、上述される方式にしたがって、また、以下でさらに詳細に議論されるように、トランザクション１５２を定式化し、トランザクションを１つまたは複数のノード１０４に送信して、ブロックチェーンネットワーク１０６を介して伝搬させる。
【0061】
ＵＩ層４０２は、それぞれのユーザのコンピュータ機器１０２のユーザ入力／出力（Ｉ／Ｏ）手段を介してユーザインターフェースをレンダリングするように構成され、レンダリングには、機器１０２のユーザ出力手段を介してそれぞれのユーザ１０３に情報を出力すること、および機器１０２のユーザ入力手段を介してそれぞれのユーザ１０３から入力を受信することが含まれる。例えば、ユーザ出力手段は、視覚的出力を提供するための１つまたは複数のディスプレイスクリーン（タッチまたは非タッチスクリーン）、オーディオ出力を提供するための１つまたは複数のスピーカ、および／または触覚的出力を提供するための１つまたは複数の触覚出力デバイスなどを含み得る。ユーザ入力手段は、例えば、１つまたは複数のタッチスクリーン（出力手段に使用されるものと同じまたは異なる）の入力アレイ、マウス、トラックパッドまたはトラックボールのような１つまたは複数のカーソルベースのデバイス、スピーチまたは音声入力を受信するための１つまたは複数のマイクロホンおよびスピーチまたは音声認識アルゴリズム、手動または身体ジェスチャーの形態の入力を受信するための１つまたは複数のジェスチャーベースの入力デバイス、または１つまたは複数の機械式ボタン、スイッチまたはジョイスティックなどを含み得る。
【0062】
注：本明細書の様々な機能が、同じクライアントアプリケーション１０５に統合されるものとして説明され得るが、必ずしもこれに限定されるものではなく、代わりに、それらは、例えば、一方が他方へのプラグインであるか、またはＡＰＩ（アプリケーションプログラミングインターフェース）を介してインターフェースする２つ以上の別個のアプリケーション一式において実装され得ることに留意されたい。例えば、トランザクションエンジン４０１の機能が、ＵＩ層４０２とは別個のアプリケーションにおいて実装されてもよし、トランザクションエンジン４０１などの所与のモジュールの機能が２つ以上のアプリケーション間で分割されてもよい。また、説明される機能の一部または全部が、例えば、オペレーティングシステム層で実装され得ることも除外されない。本明細書のどこかで単一のまたは所与のアプリケーション１０５などに言及する場合、これは単なる例であり、より一般的には、説明される機能は任意の形態のソフトウェアで実装され得ることが理解されよう。
【0063】
図３Ｂは、アリスの機器１０２ａ上のクライアントアプリケーション１０５ａのＵＩ層４０２によってレンダリングされ得るユーザインターフェース（ＵＩ）５００の例のモックアップを与える。同様のＵＩが、ボブの機器１０２ｂ上のクライアント１０５ｂによって、または任意の他の当事者のクライアントによってレンダリングされ得ることが理解されよう。
【0064】
例示として、図３Ｂは、アリスの視点からのＵＩ５００を示す。ＵＩ５００は、ユーザ出力手段を介して別個のＵＩ要素としてレンダリングされる１つまたは複数のＵＩ要素５０１、５０２、５０２を備え得る。
【0065】
例えば、ＵＩ要素は、異なる画面上ボタン、またはメニュー内の異なるオプションなどであり得る、１つまたは複数のユーザ選択可能要素５０１を備え得る。ユーザ入力手段は、ユーザ１０３（この場合、アリス１０３ａ）が、画面上のＵＩ要素をクリックするかまたはタッチすること、または所望のオプションの名前を話すことなどによって、オプションのうちの１つを選択するかまたは他の方法で操作することを可能にするように構成される（本明細書で使用される「手動」という用語は、自動と対照をなすことのみを意味するものであり、必ずしも手の使用に限定されないことに留意されたい）。オプションにより、ユーザ（アリス）は、トランザクション１５２を定式化し、トランザクションを１つまたは複数のノード１０４に送信して、ブロックチェーンネットワーク１０６を介して伝搬させることができる。
【0066】
代替的にまたは追加的に、ＵＩ要素は、１つまたは複数のデータ入力フィールド５０２を含んでもよく、これを通じて、ユーザは、トランザクション１５２を定式化し、トランザクションを１つまたは複数のノード１０４に送信して、ブロックチェーンネットワーク１０６を介して伝搬させることができる。これらのデータ入力フィールドは、例えば、画面上のユーザ出力手段を介してレンダリングされ、データは、ユーザ入力手段、例えば、キーボードまたはタッチスクリーンを介してフィールドに入力され得る。代替的に、データを、例えば音声認識に基づいて、口頭で受け取ってもよい。
【0067】
代替的にまたは追加的に、ＵＩ要素は、ユーザに情報を出力するために出力される１つまたは複数の情報要素５０３を含んでもよい。例えば、これ／これらは、画面上または音声でレンダリングされ得る。
【0068】
様々なＵＩ要素をレンダリングし、オプションを選択し、データを入力する特定の手段は重要ではないことが理解されよう。これらのＵＩ要素の機能については、後でより詳細に説明する。図３Ｂに示されるＵＩ５００は、単に図式化されたモックアップであり、実際には、簡潔にするために図示されていない１つまたは複数のさらなるＵＩ要素を備えてもよいことも理解されよう。
【0069】
ゼロ知識証明
上述のように、ゼロ知識証明（ＺＫＰ）は、いかなる秘密データも明らかにすることなく秘密の知識を証明するために使用され得る。一般性を失うことなく、本開示の実施形態は、単純で効率的なＺＫＰを構築するためのｚｋＳＮＡＲＫプロトコルのＧｒｏｔｈ１６様構築を参照して説明されるが、実施形態は、BulletproofおよびPlonkなどの他のＺＫＰにも拡張される。
上述のように、ゼロ知識証明（ＺＫＰ）は、いかなる秘密データも明らかにすることなく秘密の知識を証明するために使用され得る。一般性を失うことなく、本開示の実施形態は、単純で効率的なＺＫＰを構築するためのｚｋＳＮＡＲＫプロトコルのＧｒｏｔｈ１６様構築を参照して説明されるが、実施形態は、BulletproofおよびPlonkなどの他のＺＫＰにも拡張される。
【0070】
ｚｋＳＮＡＲＫ（Zero-Knowledge Succinct Non-Interactive Argument of Knowledge）は、簡潔で、証明が非常に短く検証が容易な知識の非対話式ゼロ知識（ＮＩＺＫ）証明である。ステートメントは、ステートメントの証明を生成するために使用される論理回路に関して表される。最も効率的な構成では、検証者は、単に、一定数のグループ演算を実行する。ｚｋＳＮＡＲＫは、所与の出力について任意の関数Ｆへの
の知識を証明するために使用することができる。これは、線形確率的証明を、双線形ペアリング（bilinear pairing）および離散対数問題（ＤＬＰ：Discrete Logarithm Problem）に基づくゼロ知識技法と組み合わせて使用する。
【数1】
【0071】
演算回路Ｃは、公開入力および出力が与えられた場合に秘密入力のＺＫＰが提供される関数Ｆを表すために使用される。この回路は、乗算ゲートと加算ゲートから構成される。回路全体の出力ではない乗算ゲートの出力は、補助変数とラベル付けされる。
【0072】
ｚｋＳＮＡＲＫプロトコルは、一般に、３つのフェーズ（図４に示される）から構成される。
ａ．セットアップ（信頼できる第三者が鍵生成を実行する）：ステートメントが与えられると、代数回路生成、Ｒ１ＣＳ（Rank-1 Constraint System）、およびＱＡＰ（Quadratic Arithmetic Program）を含むいくつかの内部ステップを経て、証明および検証鍵ペアが計算される。個人情報にアクセスする者は誰でも攻撃を引き起こすことができるので、個人情報は必ず破壊され、二度と出現しない。
ｂ．証明生成（証明者が証明生成を実行する）。公開情報、証明鍵、公開入力およびプライベート入力が与えられると、証明者は、証明を生成し、それを検証者に送る。
ｃ．検証（検証者が検証プロトコルを実行する）：公開情報、検証鍵、および公開入力が与えられると、検証者が検証を実行する。
ａ．セットアップ（信頼できる第三者が鍵生成を実行する）：ステートメントが与えられると、代数回路生成、Ｒ１ＣＳ（Rank-1 Constraint System）、およびＱＡＰ（Quadratic Arithmetic Program）を含むいくつかの内部ステップを経て、証明および検証鍵ペアが計算される。個人情報にアクセスする者は誰でも攻撃を引き起こすことができるので、個人情報は必ず破壊され、二度と出現しない。
ｂ．証明生成（証明者が証明生成を実行する）。公開情報、証明鍵、公開入力およびプライベート入力が与えられると、証明者は、証明を生成し、それを検証者に送る。
ｃ．検証（検証者が検証プロトコルを実行する）：公開情報、検証鍵、および公開入力が与えられると、検証者が検証を実行する。
【0073】
以下に示す表１は、ｚｋＳＮＡＲＫプロトコルのＧｒｏｔｈ１６様構築の各フェーズの入力および出力を示す。
【表1】
【0074】
ｚｋＳＮＡＲＫプロトコルは、以下のプロパティを満たすべきである：
・ 完全性：ステートメントが真であり、検証者と証明者が正直である場合、証明は受け入れられる。
・ 健全性：ステートメントが偽である場合、不正を行う証明者は、無視できる確率を除いて、正直な検証者にそれが真であると確信させることができない。
・ ゼロ知識：ゼロ知識証明は、ステートメントが真であること以外の情報を検証者に明らかにしない。
・ 簡潔：証明は回路サイズよりも短く、検証者は回路サイズよりも少ない数の暗号操作を行わなければならない。
・ 非対話式：証明は、１ステップのみで検証者に送信される。
・ 知識の論証（Arguments of Knowledge）：証明は、計算上健全であると考えられる。すなわち、（量子コンピュータのような）制限のない証明者は、検出されることなく偽のステートメントを証明することができる。
・ 知識：証明者は、実際にウィットネスを知っており、ウィットネスへのアクセス（ステートメントを証明するために必要なプライベート入力）なしに証明を構築することができない。すなわち、証明者と対話し、ウィットネスを出力する抽出アルゴリズムが存在する。
・ 完全性：ステートメントが真であり、検証者と証明者が正直である場合、証明は受け入れられる。
・ 健全性：ステートメントが偽である場合、不正を行う証明者は、無視できる確率を除いて、正直な検証者にそれが真であると確信させることができない。
・ ゼロ知識：ゼロ知識証明は、ステートメントが真であること以外の情報を検証者に明らかにしない。
・ 簡潔：証明は回路サイズよりも短く、検証者は回路サイズよりも少ない数の暗号操作を行わなければならない。
・ 非対話式：証明は、１ステップのみで検証者に送信される。
・ 知識の論証（Arguments of Knowledge）：証明は、計算上健全であると考えられる。すなわち、（量子コンピュータのような）制限のない証明者は、検出されることなく偽のステートメントを証明することができる。
・ 知識：証明者は、実際にウィットネスを知っており、ウィットネスへのアクセス（ステートメントを証明するために必要なプライベート入力）なしに証明を構築することができない。すなわち、証明者と対話し、ウィットネスを出力する抽出アルゴリズムが存在する。
【0075】
証明者は、ｚｋＳＮＡＲＫを使用して「有効な割り当て」（Ｘ，Ｗ）の知識を証明することができ、これは、回路の入力、出力、および補助変数から構成されるベクトルであり、以下のように表記される：
｛ｉｎｉ，ｏｕｔｊ，ａｕｘｋ｝
ここで、ｉ、ｊ、ｋは、有効な割り当てにおける各パラメータの変数の数を示す整数である。有効な割り当てｉｎｉ内の入力は、
から構成されることに留意されたい。有効な割り当ての公開成分Ｘ（すなわち、回路の任意の公開入力およびすべての出力ならびに任意の公開補助変数）と、有効な割り当ての秘密成分Ｗ（すなわち、すべての秘密入力および任意の秘密補助変数）の両方が、証明生成器に供給される。検証者が、有効な割り当ての公開成分Ｘの可視性のみを有することに留意されたい。すなわち、「秘密」という用語は、本明細書では、検証者に知られていないデータを指すために使用される。関数Ｆを、ｚｋＳＮＡＲＫのセットアップフェーズにおいて鍵生成プロトコルが制定される演算回路として定義することによって、セットアップからの出力（すなわち、証明鍵および検証鍵）を使用して、任意の所与の回路の異なる有効な割り当て（Ｘ，Ｗ）について複数の証明を生成することができる。図４は、３つのフェーズのそれぞれの間の入力および出力の流れを示す。
｛ｉｎｉ，ｏｕｔｊ，ａｕｘｋ｝
ここで、ｉ、ｊ、ｋは、有効な割り当てにおける各パラメータの変数の数を示す整数である。有効な割り当てｉｎｉ内の入力は、
【数2】
【0076】
図４において、証明者によって実行される証明生成プロセスに供給される「Ｘ」は、有効な割り当てにおけるすべての公開パラメータ、例えば、関数Ｆへの公開入力「ｘ」、関数Ｆからの公開出力、および任意の公開補助変数を指す。図４において、「Ｗ」は、有効な割り当てにおけるすべての秘密パラメータ、例えば、関数Ｆへの秘密入力「ｗ」、および任意の秘密補助変数を含む。
【0077】
第２の証明生成フェーズの間、証明者は、回路および有効な割り当てに依存する３つの多項式Ａ（ｚ）、Ｂ（ｚ）、Ｃ（ｚ）を計算する。多項式のセットは、ｚの異なる値で回路の制約を符号化するＱＡＰ（Quadratic Arithmetic Program）の一部を形成する。証明者は、未知の値ｚ＝τで制約が満たされることを証明するように求められる。この証明が与えられると、証明者は、（ｚｋＳＮＡＲＫのARgumentプロパティを暗示する）すべての制約の知識を有すると仮定する。証明πは、以下が、回路のみに依存する目標多項式Ｚ（ｚ）によって割り切れるというＱＡＰ可分性条件が満たされる場合に受け入れられる：
Ａ（ｚ）・Ｂ（ｚ）－Ｃ（ｚ）
Ａ（ｚ）・Ｂ（ｚ）－Ｃ（ｚ）
【0078】
多項式は楕円曲線点を使用して隠されることに留意されたい。証明は、以下となるように、ＱＡＰ可分性を保証するために双線形ペアリングｅ（■，■）において使用される点Ａ（τ）・Ｇ、Ｂ（τ）・Ｇ、Ｃ（τ）・Ｇから構成される：
ここで、多項式Ｈ（τ）の知識は証明されなければならない。上記の等式が成り立つ場合、検証者は、証明者が有効な割り当ての知識を有することを知る。検証プロトコルはまた、以下のことをチェックする：
・ 証明者は、Ａ（τ）・Ｇ、Ｂ（τ）・Ｇ、Ｃ（τ）・Ｇを計算するために証明鍵ｐｋを使用した、
・ 証明者は、Ａ（τ）・Ｇ、Ｂ（τ）・Ｇ、Ｃ（τ）・Ｇのそれぞれにおいて同じ有効な割り当てを使用した、
・ 証明者が正しい公開入力ｘ→を宣言した。
【数3】
・ 証明者は、Ａ（τ）・Ｇ、Ｂ（τ）・Ｇ、Ｃ（τ）・Ｇを計算するために証明鍵ｐｋを使用した、
・ 証明者は、Ａ（τ）・Ｇ、Ｂ（τ）・Ｇ、Ｃ（τ）・Ｇのそれぞれにおいて同じ有効な割り当てを使用した、
・ 証明者が正しい公開入力ｘ→を宣言した。
【0079】
第３の検証フェーズは、証明が有効であると判明したか無効であると判明したかに応じて、それぞれ、受け入れ決定または拒否決定を返す。関数のサイズに関わらず、４つの検証計算で使用される証明は、常に８つの楕円曲線点に固定されることに留意されたい。これは、ｚｋＳＮＡＲＫの簡潔性プロパティを満たす。この証明および対応する回路の知識を有する者であれば誰でも計算を検証することができ、非対話的な証明となる。検証者は、秘密に関するいかなる情報も学習せず、正しく計算されなければ証明が成功することは計算上不可能である。すなわち、証明者が正直に行動すること以外に、受け入れられる証明を計算することは計算上不可能である。検証鍵は、検証者が回路を直接使用することなく、所定のステートメント（回路を意味する）が実際に妥当性確認されていることを検証者に保証する。
【0080】
ｚｋＳＮＡＲＫのＧｒｏｔｈ１６様構築が上記で言及されているが、実施形態は、このタイプのＺＫＰに限定されるのではない。特に、ＺＫＰは、マルチパーティ計算（ＭＰＣ）ベースのｚｋＳＮＡＲＫ（例えば、ｚｋＢＯＯ）、ＳＴＡＲＫ、またはBulletproofなどであってもよい。
【0081】
鍵導出プロトコル
１つの例示的な鍵導出プロトコルは、単一のバイナリシードから複数の私有／公開鍵ペアを導出する方法を記述するＢＩＰ３２仕様である。本方法は、ツリー状のデータ構造を形成する鍵の階層的決定論的（ＨＤ）ウォレットを生成する。
１つの例示的な鍵導出プロトコルは、単一のバイナリシードから複数の私有／公開鍵ペアを導出する方法を記述するＢＩＰ３２仕様である。本方法は、ツリー状のデータ構造を形成する鍵の階層的決定論的（ＨＤ）ウォレットを生成する。
【0082】
第１の拡張鍵（マスタ鍵）は、ＨＭＡＣ－ＳＨＡ５１２ハッシュ関数にシードを通すことによって作成される。特に、ＨＤウォレットのマスタ鍵は、以下のステップによって生成される：
【数4】
【0083】
拡張私有マスタ鍵は（ｍ，ｃｍ）と定義される。私有マスタ鍵は、必然的に秘密でなければならない。これは、所望に応じて使用され得る子鍵を導出するために使用される。すべての拡張鍵は、子拡張鍵を導出することができる。拡張鍵は、ＨＤウォレット内の新しい鍵を導出するために使用することができる私有鍵または公開鍵である。拡張私有鍵は、チェーンコードと結合された私有鍵である。対応する拡張公開鍵は、私有鍵を取得し、その対応する公開鍵を計算し、それを同じチェーンコードと結合することによって作成することができる。
【0084】
一例では、親私有鍵を使用して子私有鍵を導出することができ、これは図５に示されている。
【0085】
関数（ｓｋｉ，ｃｉ）←ＣＫＤｐｒｉｖ（（ｓｋｐａｒ，ｃｐａｒ），ｉ）は、拡張親私有鍵（ｓｋｐａｒ，ｃｐａｒ）およびインデックスｉから、拡張子私有鍵（ｓｋｉ，ｃｉ）を以下のように導出する：
【数5】
【0086】
この方法を使用して、単一の親から最大２３２個の子鍵を導出することができる。追加的に、上記の方法において各子を親鍵とすることで、孫鍵を導出することができ、以下同様である。子鍵の世代の深さには制限がない（回復可能性の考慮は別として）。
【0087】
同様に、親公開鍵を使用して子公開鍵を導出することができ、これは図５に示されている。この例では、子公開鍵は、親公開鍵と、親公開鍵がＨＭＡＣ－ＳＨＡ５１２ハッシュ関数への入力として供給されるときに生成されるハッシュ関数出力の第１の部分（ＩＬ）とを使用して生成される。
【0088】
図５に示すように、親私有／公開鍵がＨＭＡＣ－ＳＨＡ５１２ハッシュ関数への入力として供給されるときに生成されるハッシュ関数出力の残りの部分に対応する子チェーンコードＩＲは、子公開／私有鍵が「親になる」ときにＨＭＡＣ－ＳＨＡ５１２ハッシュ関数への親チェーンコード入力として使用され、子鍵を導出するために使用される。
【0089】
親から１つの強化されていない子鍵を導出するのに必要な情報が与えられると、（送信者が）ウォレット所有者（受信者）の代わりに他の子鍵を導出することが可能であり、これにより、両当事者間で必要とされる通信のラウンドを最小限に抑える。しかしながら、このタイプの構成は、ＨＤウォレット（ＢＩＰ３２を含む）サーバを特権エスカレーション攻撃にさらす。
【0090】
すなわち、拡張親公開鍵（ｐｋｐａｒ，ｃｐａｒ）と任意の強化されていない子私有鍵ｓｋｉとが与えられると、攻撃者は、ｓｋｐａｒ＝ｓｋｉ－ＩＬを計算することによって親秘密鍵ｓｋｐａｒを得ることができる。次いで、攻撃者は、強化された親鍵までの（およびそれを含む）鍵導出経路および所与の深度のすべての子鍵を導出し得る。
【0091】
ＨＤウォレット内の導出経路は、「／」で区切られたｎ個の鍵インデックスのｎタプルとして定義される。ＢＩＰ３２デフォルトウォレットレイアウトは、マスタ鍵ｍに続く３層階層を採用し、以下の導出経路によって定義される：
m／account'／change／address_index
m／account'／change／address_index
【0092】
このウォレット構成では、階層データ構造の第１の深さ（account'）にある子鍵が強化される。攻撃者が、強化されていない子私有鍵（changeまたはaddress_indexレベル）の知識を得た場合、攻撃者は、上記の特権エスカレーション攻撃を使用してすべての子鍵の資金にアクセスすることによって、アカウント全体を危険にさらすことができる。
【0093】
証明生成および検証
図６は、子公開鍵の真正性を検証するためのプロセス６００において、検証者コンピュータ機器６０２ａ（コンピューティングデバイス）および証明者コンピュータ機器６０２ｂ（コンピューティングデバイス）によって実行されるステップを示す。
図６は、子公開鍵の真正性を検証するためのプロセス６００において、検証者コンピュータ機器６０２ａ（コンピューティングデバイス）および証明者コンピュータ機器６０２ｂ（コンピューティングデバイス）によって実行されるステップを示す。
【0094】
ステップＳ６０２において、検証者に関連付けられた検証者コンピュータ機器６０２ａは、エンティティに関連付けられた子公開鍵を取得する。検証者コンピュータ機器６０２ａは、いくつかの異なる方法で子公開鍵を取得し得ることが理解されよう。一例では、検証者コンピュータ機器６０２ａは、証明者コンピュータ機器６０２ｂに子公開鍵を要求し、その後、証明者コンピュータ機器６０２ｂから子公開鍵を受信することによって、子公開鍵を取得し得る。
【0095】
ステップＳ６０４において、検証者コンピュータ機器６０２ａは、子公開鍵が真正であることの証明を要求するメッセージを証明者コンピュータ機器６０２ｂに送信する。すなわち、検証者コンピュータ機器６０２ａは、親鍵から子公開鍵を導出するために鍵導出プロトコルが使用されたことの証明を要求する。
【0096】
ステップＳ６０６において、メッセージを受信したことに応答して、証明者コンピュータ機器６０２ｂは、子公開鍵が真正であることを証明する際に使用するためのＺＫＰを生成し、ステップＳ６０８において、その証明を検証者コンピュータ機器６０２ａに送信する。証明者コンピュータ機器６０２ｂは、子公開鍵に関連付けられたエンティティに関連付けられてもよい（すなわち、子公開鍵は、証明者に関連付けられてもよい）。しかしながら、これは必須ではなく、証明者コンピュータ機器６０２ｂは、子公開鍵に関連付けられたエンティティに関連付けられる必要はない。
【0097】
ステップＳ６１０において、検証者コンピュータ機器６０２ａを使用して証明を検証し、証明の検証に成功することによって、検証者は、親鍵から子公開鍵を導出するために鍵導出プロトコルが使用されたことを確信することができ、したがって、ステップＳ６１２において、検証者は、子公開鍵を真正であるとして受け入れる。
【0098】
プロセス６００は、検証者が支払いを証明者に送信し、証明が、子公開鍵から導出された支払いアドレスが真正であることを証明するという文脈で、以下でさらに詳細に説明される。後述するように、本発明の実施形態は、この支払いの状況に限定されない。
【0099】
強化された子鍵導出証明
拡張親公開鍵（ｐｋｐａｒ，ｃｐａｒ）が与えられると、強化されていない子公開鍵ｐｋｉが、以下の式を使用してＢＩＰ３２導出経路に関して正しく導出されたことを証明することができる：
ここで、楕円曲線演算子＋および・は、それぞれ、点加算およびスカラ点乗算を示し、ＨＭＡＣ５１２Ｌは、ＨＭＡＣ関数の出力の左３２バイト（ＩＬ）である。プライバシーの問題を無視すれば、第三者が拡張親公開鍵を知っていることは安全である。この知識は、送信者が、上記の子鍵導出（ＣＫＤ）式を使用して、受信者の代わりに支払いアドレスを導出することができるので、複数のトランザクションが公開鍵の所有者に送信されている場合に有用である。これにより、両当事者間で必要とされる通信のラウンドが低減する。
拡張親公開鍵（ｐｋｐａｒ，ｃｐａｒ）が与えられると、強化されていない子公開鍵ｐｋｉが、以下の式を使用してＢＩＰ３２導出経路に関して正しく導出されたことを証明することができる：
【数6】
【0100】
対照的に、ＨＭＡＣ関数への秘密入力があるため、拡張親公開鍵から強化された子公開鍵ｐｋ’
ｉを導出することはできない：
ここでの鍵導出式は、検証者が、必然的に秘密である親私有鍵ｓｋｐａｒを知る必要があることを示す。
【数7】
【0101】
本明細書では、ＺＫＰを使用して、強化された子鍵の導出を証明する方法を説明する。これにより、第三者は、親私有鍵の知識なしにＣＫＤ計算の正しさを検証すること、すなわち、強化された子公開鍵が所与の親公開鍵から導出されることを証明することができる。
【0102】
この実施形態では、親鍵は、私有親鍵であり、子公開鍵は、強化された子公開鍵である。
【0103】
図７に示される回路Ｃは、強化された子公開鍵ｐｋ’
ｉのためのＢＩＰ３２ ＣＫＤ関数を表し、１つまたは複数の既知の出力が与えられた場合の関数の入力の知識が証明される。図７は、証明生成／検証プロセスにおいてどの入力／出力が公開／秘密であるかを示すために使用される。
【0104】
回路Ｃは、以下の仮定に基づく：
【数8】
【0105】
回路への入力は以下の通りであり：
出力は、子公開鍵ｐｋ’
ｉ ７１０および親公開鍵ｐｋｐａｒ ７１２である。
【数9】
【0106】
証明者コンピュータ機器６０２ｂは、回路Ｃを実行して、有効な割り当てを出力する。すなわち、証明者コンピュータ機器６０２ｂは、上述の入力を回路Ｃに供給して、上述の出力を生成する。
【0107】
回路への有効な割り当て（Ｘ，Ｗ）は、３つの入力（ｓｋｐａｒ，ｃｐａｒ，ｉ）と、２つの出力（ｐｋｐａｒ，ｐｋ’
ｉ）と、（ｓｋｐａｒ || ＩＬ，ｓｋ’
ｉ）を含む補助変数とを含む。
【0108】
図７は、入力が公開であるか秘密（影付きのボックスによって示される）であるか、および指定された出力を生成する関数Ｆ７０８内で行われる計算を示す。関数Ｆ７０８の実行中に生成される補助変数は、図７には明示的に示されていない。
【0109】
大まかに言えば、この有効な割り当てのための回路における計算ステップは、以下の通りである：
【数10】
【0110】
拡張子公開鍵が出力において望まれる場合、チェーンコードｃｉは、ＨＭＡＣ関数の右端の出力ＩＲについて回路のステップ２ｉｂを複製することによって計算され得る。
【0111】
自分の親公開鍵を自分のアイデンティティにンクする証明書を有する認定業者ボブ１０３ｂ（証明者）から高価な製品を購入することをアリス１０３ａ（検証者）が望むシナリオを考える。このシナリオでは、検証者コンピュータ機器６０２ａはアリスのコンピュータ機器１０２ａに対応し、証明者コンピュータ機器６０２ｂはボブのコンピュータ機器１０２ｂに対応する。
【0112】
ボブ１０３ｂは、強化された公開鍵への支払いのみを受け入れるので、アリス１０３ａは、ボブ１０３ｂの代わりに子鍵および結果として生じる支払いアドレスを生成することができない。
【0113】
アリス１０３ａは、未認証の強化された子公開鍵ｐｋ’
ｉから導出される支払いアドレスをボブから（証明者コンピュータ機器６０２ｂから直接、ボブのウォレットサーバから、または何らかの他の手段によって）取得する。ウォレットサーバは、上記で言及されたブロックチェーンノード１０４のうちの１つ、またはブロックチェーンノード１０４のうちの１つに結合されたサーバに対応し得る。ウォレットサーバは、ユーザのウォレット内のすべての鍵を導出して記憶し、次いで、これらの鍵は、支払いアドレスを導出するために使用される。このような鍵は、一度に１つずつ導出されてもよいし、一度に数個ずつ断続的に導出されてもよいことが理解されよう。
【0114】
ステップＳ６０２において、アリス１０３ａはまた、強化された子公開鍵ｐｋ’
ｉを（証明者コンピュータ機器６０２ｂから直接、ボブのウォレットサーバから、または何らかの他の手段によって）取得する。ステップＳ６０４において、アリス１０３ａは、支払いトランザクションを終了する前に、この強化された子公開鍵が真正であることの証明を要求する。
【0115】
ステップＳ６０６において、証明者コンピュータ機器６０２ｂは、強化されたＣＫＤ関数を表す公開回路への有効な割り当てに基づいて証明を生成する。
【0116】
ステップＳ６０６において証明を生成するために、証明者コンピュータ機器６０２ｂは、この例示的な実施形態では、関数Ｆ７０８への公開入力（親チェーンコードｃｐａｒ ７０４および鍵インデックスｉ ７０６）と、関数Ｆ７０８からの公開出力（強化された子公開鍵ｐｋ’
ｉ ７１０および親公開鍵ｐｋｐａｒ ７１２）とを含む証明生成プロセスへの入力「Ｘ」を供給する。
【0117】
ステップＳ６０６において証明を生成するために、証明者コンピュータ機器６０２ｂは、有効な割り当て内のすべての秘密パラメータ、例えば、関数Ｆ７０８への秘密入力（親私有鍵ｓｋｐａｒ ７０２）と任意の秘密補助変数とを含む証明生成プロセスへの入力「Ｗ」をさらに供給する。
【0118】
証明者コンピュータ機器６０２ｂは、証明生成プロセスへの入力として証明鍵ｐｋＦをさらに供給する。
【0119】
証明者コンピュータ機器６０２ｂによって実施される証明生成プロセスは、入力「Ｘ」、「Ｗ」、および証明鍵ｐｋＦを使用して、証明πを生成する。ボブの証明は、アリス１０３ａがボブから取得した強化された公開鍵が、実際にボブの証明された親鍵の子であることを示す。
【0120】
この例では、ＺＫＰは以下のように構成される：
【数11】
【0121】
証明を検証するために、検証者コンピュータ機器６０２ａは、このプロセスは、この例示的な実施形態では、関数Ｆ７０８への公開入力（親チェーンコードｃｐａｒ ７０４および鍵インデックスｉ ７０６）と、関数Ｆ７０８からの公開出力（強化された子公開鍵ｐｋ’
ｉ ７１０および親公開鍵ｐｋｐａｒ ７１２）とを含む証明検証プロセスに証明および入力「Ｘ」を供給する。
【0122】
検証者コンピュータ機器６０２ａは、証明検証プロセスへの入力として、検証鍵ｖｋＦをさらに供給する。
【0123】
検証者コンピュータ機器６０２ａによって実施される証明検証プロセスは、証明、入力「Ｘ」、検証鍵ｖｋＦを使用して、証明πを検証する。証明検証プロセスは、証明が有効であると判明したか無効であると判明したかに応じて、受け入れまたは拒否の決定を出力する。ステップＳ６１０において、ボブの証明を検証することによって、アリス１０３ａは、ＢＩＰ３２導出方法を使用して、親私有鍵ｓｋｐａｒから強化された子公開鍵ｐｋ’
ｉが正しく導出されたことを確信することができる。これは、ボブに対して有する支払いアドレスが実際に正しいものであることをアリス１０３ａに確信させる。
【0124】
検証者（アリス１０３ａ）は、親公開鍵ｐｋｐａｒ（入力「Ｘ」の一部である）のコピーを事前に知っている。いくつかの実施形態では、検証者コンピュータ機器６０２ａは、証明者コンピュータ機器６０２ｂから、証明を生成するために証明者コンピュータ機器６０２ｂによって使用される親公開鍵を受信し得、証明検証に加えて、子公開鍵の真正性を決定することは、証明を生成するために証明者コンピュータ機器６０２ｂによって使用される親公開鍵ｐｋｐａｒが、検証者が事前に知っている親公開鍵のコピーと一致するかどうかにさらに基づき得る。すなわち、証明を生成するために証明者コンピュータ機器６０２ｂによって使用される親公開鍵ｐｋｐａｒが親公開鍵のコピーと一致する場合、これにより、証明者（ボブ１０３ｂ）のアイデンティティが期待されるものであり、子公開鍵が真正であると決定されることをアリス１０３ａに確信させる。
【0125】
この実施形態は、いくつかの公開入力「ｘ」（例えば、親チェーンコードｃｐａｒ ７０４および鍵インデックスｉ ７０６）を含む証明生成および証明検証プロセスにおいて使用される入力「Ｘ」を参照して上述されている。親チェーンコードｃｐａｒ ７０４および鍵インデックスｉ ７０６の一方または両方は、証明生成プロセスにおいて使用される入力「Ｗ」の一部である秘密入力「ｗ」であり得ることが理解されよう。親チェーンコードｃｐａｒ ７０４および鍵インデックスｉ ７０６の各々は、秘密であっても公開であってもよい。
【0126】
強化されたまたは強化されていない子鍵導出証明
強化されているか強化されてないかにかかわらず、異なる拡張鍵の知識は、以下の３つのシナリオをもたらし得る：
１．拡張公開親鍵の知識：攻撃者は、親公開鍵および親チェーンコードの知識を得て、すべての強化されていない子公開鍵を導出することができる。
２．拡張公開親鍵と強化されていない子私有鍵の知識：攻撃者は、特権エスカレーション攻撃を行うことができる。
３．複数の拡張公開子鍵の知識：攻撃者は、拡張シリアル化フォーマットに含まれる４バイトの親指紋の知識を有し、兄弟鍵間の関係を識別することができる。
強化されているか強化されてないかにかかわらず、異なる拡張鍵の知識は、以下の３つのシナリオをもたらし得る：
１．拡張公開親鍵の知識：攻撃者は、親公開鍵および親チェーンコードの知識を得て、すべての強化されていない子公開鍵を導出することができる。
２．拡張公開親鍵と強化されていない子私有鍵の知識：攻撃者は、特権エスカレーション攻撃を行うことができる。
３．複数の拡張公開子鍵の知識：攻撃者は、拡張シリアル化フォーマットに含まれる４バイトの親指紋の知識を有し、兄弟鍵間の関係を識別することができる。
【0127】
３つのシナリオすべてにおいて、ブロックチェーンの公開性は、攻撃者が、使用のパターンを追跡することができる可能性があることを意味する。プライバシー問題に加えて、シナリオ２では、攻撃者は、侵害されたアカウントに関連付けられた資金を盗むことができる。
【0128】
本明細書では、ＺＫＰが強化されていない子公開鍵または強化された子公開鍵のいずれかの正しい導出を証明するように構築される、受信者の拡張親公開鍵を隠す方法を説明する。本明細書で説明される解決策は、特権エスカレーション攻撃に対してＨＤウォレットをセキュアにし、拡張親公開鍵を隠すことによって受信者のプライバシーを守る。
【0129】
図８に示される回路Ｃは、強化された子公開鍵ｐｋ’
ｉまたは強化されていない子公開鍵ｐｋｉのいずれかのためのＢＩＰ３２ ＣＫＤ関数を表し、１つまたは複数の既知の出力が与えられた場合の関数の入力の知識が証明される。図８は、証明生成／検証プロセスにおいてどの入力／出力が公開／秘密であるかを示すために使用される。
【0130】
回路Ｃは、以下の仮定に基づく：
【数12】
【0131】
回路への入力は以下の通りであり：
出力は、以下の通りである：
【数13】
【数14】
【0132】
親公開鍵は、強化されていなくても強化されていてもよい（ｐｋ’
ｐａｒ）。ここでは、簡単にするために表記ｐｋｐａｒが使用される。
【0133】
回路は、公開鍵または私有親鍵のいずれかを入力として取り、それぞれ出力において強化されていないまたは強化された子鍵を導出することができる。両方のタイプの出力に対応するために、私有鍵ｓｋｐａｒを入力として設定することができ、図８の概略図の関数Ｆ８０８の１行目によって示されるように、対応する公開鍵を回路内で導出することができる。
【0134】
図８は、私有鍵ｓｋｐａｒが入力として設定されていることを示しているが、代わりに、公開親鍵ｐｋｐａｒを入力として設定することができる。ただし、これは、出力を、強化されていない子鍵のみに限定する。
【0135】
証明者コンピュータ機器６０２ｂは、回路Ｃを実行して、有効な割り当てを出力する。すなわち、証明者コンピュータ機器６０２ｂは、上述の入力を回路Ｃに供給して、上述の出力を生成する。
【0136】
回路への有効な割り当て（Ｘ，Ｗ）は、３つの入力（ｓｋｐａｒ，ｃｐａｒ，ｉ）と、１つの出力（ｏｕｔ）と、ｐｋｐａｒ，■||ｉ，ＩＬ，（ＩＬ・Ｇ）を含む補助変数とを含み、ここで、
【数15】
【0137】
図８は、入力が公開であるか秘密（影付きのボックスによって示される）であるか、および指定された出力を生成する関数Ｆ８０８内で行われる計算を示す。関数Ｆ８０８の実行中に生成される補助変数は、図８には明示的に示されていない。
【0138】
大まかに言えば、この有効な割り当てのための回路における計算ステップは、以下の通りである：
【数16】
【0139】
拡張子公開鍵が出力（出力はチェーンコードｃｉを含む）において望まれる場合、チェーンコードｃｉは、ＨＭＡＣ関数の右端の出力ＩＲについてステップ２ｉｉｉを複製することによって計算することができる。
【0140】
所与の拡張親鍵について、鍵（公開または私有）とチェーンコードの両方を秘密入力として設定して、入力の知識なしに子鍵の導出を証明することが可能であることを示すことが可能である。したがって、子公開鍵が正しく導出されたことの証明を要求する第三者は、回路への入力の明示的な知識なしに、そのような証明を検証することができる。なぜなら、ｚｋＳＮＡＲＫプロトコルで使用される検証鍵ｖｋＦが、回路にリンクされているからである。したがって、検証者が回路の出力を受け入れるかまたは拒否するのには、（検証鍵ｖｋＦを所有していることによる）回路の知識で十分である。さらに、回路へのすべての入力を秘密として設定することにより、所有者のアイデンティティおよび／または所有者のトランザクション履歴に関する情報が漏洩しないことが保証される。
【0141】
公開入力が望まれる場合、拡張親鍵の一部のみを秘密入力として設定することが可能であるが、拡張親鍵全体は知られていない。すなわち、公開親鍵ｐｋｐａｒが入力として設定される場合、親鍵ｃｐａｒに対応するチェーンコード８０４は、秘密入力として設定される。私有親鍵ｓｋｐａｒが入力として設定される場合、親鍵ｃｐａｒに対応するチェーンコード８０４は、公開または秘密入力として設定され得る。鍵インデックス８０６は、秘密であっても公開であってもよい。
【0142】
ユーザアリス１０３ａが別のユーザボブ１０３ｂに支払いを送信することを望むシナリオを考える。このシナリオでは、検証者コンピュータ機器６０２ａはアリスのコンピュータ機器１０２ａに対応する。
【0143】
アリス１０３ａは、ボブ１０３ｂのための未認証の公開鍵ｐｋ’
ｉを有し、結果として生じる支払いアドレスが真正であるかどうかは不確かである。これは、ステップＳ６０２において（証明者コンピュータ機器６０２ｂから直接、ボブのウォレットサーバから、または何らかの他の手段によって）取得される。
【0144】
ステップＳ６０４において、アリス１０３ａは、支払いトランザクションを終了する前に、この公開鍵が真正であることの証明を要求する。ここで、証明者コンピュータ機器６０２ｂは、ボブ１０３ｂに関連付けられたコンピュータ機器１０２ｂ、またはボブのＢＩＰ３２ウォレットプロバイダに関連付けられたウォレットサーバに対応し得る。以下では、証明者コンピュータ機器６０２ｂがボブのＢＩＰ３２ウォレットプロバイダに関連付けられたウォレットサーバに対応する例を参照する。
【0145】
ステップＳ６０６において、証明者コンピュータ機器６０２ｂは、ＣＫＤ関数を表す公開回路への有効な割り当てに基づいて証明を生成する。
【0146】
ステップＳ６０６において証明を生成するために、証明者コンピュータ機器６０２ｂは、図８に示される例では、関数Ｆ８０８への公開入力は含まず、この例では強化された子公開鍵ｐｋ’
ｉである関数Ｆからの公開出力８１０は含む証明生成プロセスへの入力「Ｘ」に供給する。
【0147】
ステップＳ６０６において証明を生成するために、証明者コンピュータ機器６０２ｂは、有効な割り当ての中のすべての秘密パラメータ、例えば、関数Ｆ８０８への秘密入力（親私有鍵ｓｋｐａｒ ８０２、親チェーンコードｃｐａｒ ８０４、および鍵インデックスｉ ８０６）と、任意の秘密補助変数とを含む証明生成プロセスへの入力「Ｗ」をさらに供給する。
【0148】
証明者コンピュータ機器６０２ｂは、証明生成プロセスへの入力として証明鍵ｐｋＦをさらに供給する。
【0149】
証明者コンピュータ機器６０２ｂによって実施される証明生成プロセスは、入力「Ｘ」、「Ｗ」、および証明鍵ｐｋＦを使用して、証明πを生成する。ボブの証明は、アリス１０３ａがボブから取得した強化された子公開鍵ｐｋ’
ｉが、実際にボブの証明された親鍵の子であることを示す。
【0150】
証明を検証するために、検証者コンピュータ機器６０２ａは、図８に示された例では、関数Ｆ８０８への公開入力は含まず、関数Ｆ８０８からの公開出力（強化された子公開鍵ｐｋ’
ｉ ８１０）は含む証明検証プロセスへの証明および入力「Ｘ」を供給する。
【0151】
検証者コンピュータ機器６０２ａは、証明検証プロセスへの入力として、検証鍵ｖｋＦをさらに供給する。ステップＳ６１０においてボブの証明を検証することによって、アリス１０３ａは、ＢＩＰ３２導出方法を使用して、親私有鍵ｓｋｐａｒから強化された子公開鍵ｐｋ’
ｉが正しく導出されたことを確信することができる。これは、ボブに対して有する支払いアドレスが実際に正しいものであることをアリス１０３ａに確信させる。
【0152】
別の例では、証明者コンピュータ機器６０２ｂは、ボブの拡張親公開鍵（ｐｋｐａｒ，ｃｐａｒ）から構築された有効な割り当てを使用して証明を生成し、強化されていない公開鍵ｐｋｉがウォレットのＣＫＤ関数から正しく導出されたことを証明する。ここで、証明は、入力として親公開鍵を使用して導出されるものに限定され、すなわち、ここでの出力は、強化されていない子公開鍵ｐｋｉである。
【0153】
ウォレットプロバイダの証明πを検証することによって、アリスは、強化されていない子公開鍵ｐｋｉから導出された支払いアドレスが正しいと納得する。
【0154】
ＺＫＰは以下のように構成される：
【数17】
【0155】
この実施形態は、親チェーンコードｃｐａｒ ８０４と鍵インデックスｉ ８０６とを含む証明生成プロセスにおいて使用される入力「Ｗ」を参照して上述されているが、これは一例にすぎず、親チェーンコードｃｐａｒ ８０４と鍵インデックスｉ ８０６のいずれか一方または両方が、証明生成プロセスおよび証明検証プロセスにおいて使用される入力「Ｗ」の一部である公開入力ｘであってもよい。親チェーンコードｃｐａｒ ８０４および鍵インデックスｉ ８０６の各々は、秘密であっても公開であってもよい。
【0156】
アイデンティティがリンクされた子鍵導出証明
典型的な公開鍵インフラストラクチャ（ＰＫＩ）では、認証局（ＣＡ）が、私有鍵－公開鍵ペアの所有権を証明するデジタル証明書を発行する。鍵ペアの所有者は、自身の公開鍵をＣＡに証明してもらうために証明書要求を作成し、対応する私有鍵を使用して要求に署名して、鍵ペアの所有権を証明する。ＣＡは、典型的には、デジタル証明書に署名して発行する前に、アイデンティティ関連情報を検証する。
典型的な公開鍵インフラストラクチャ（ＰＫＩ）では、認証局（ＣＡ）が、私有鍵－公開鍵ペアの所有権を証明するデジタル証明書を発行する。鍵ペアの所有者は、自身の公開鍵をＣＡに証明してもらうために証明書要求を作成し、対応する私有鍵を使用して要求に署名して、鍵ペアの所有権を証明する。ＣＡは、典型的には、デジタル証明書に署名して発行する前に、アイデンティティ関連情報を検証する。
【0157】
ＣＡは信頼できる機関であり、そのデジタル署名は、証明書の真正性および完全性を保証する。以下のアルゴリズムは、デジタル署名の作成および検証を要約したものであり、その入力および出力を以下の表２に列挙する：
Ｉ． 署名－署名者は、デジタル署名アルゴリズムにおいて自身の私有鍵ｓｋを使用して、メッセージｍに署名する。次いで、署名Ｓｉｇ（ｍ）、メッセージｍ、および署名者の公開鍵ｐｋが検証者に送信される。
ＩＩ． 検証－検証者は、署名者の公開鍵ｐｋおよび同じデジタル署名アルゴリズムを使用して、署名Ｓｉｇ（ｍ）を検証し、メッセージｍの真正性を妥当性確認する。
Ｉ． 署名－署名者は、デジタル署名アルゴリズムにおいて自身の私有鍵ｓｋを使用して、メッセージｍに署名する。次いで、署名Ｓｉｇ（ｍ）、メッセージｍ、および署名者の公開鍵ｐｋが検証者に送信される。
ＩＩ． 検証－検証者は、署名者の公開鍵ｐｋおよび同じデジタル署名アルゴリズムを使用して、署名Ｓｉｇ（ｍ）を検証し、メッセージｍの真正性を妥当性確認する。
【表2】
【0158】
ＣＡによって発行された証明書は、メッセージＳｉｇ（ｍ）に対する署名とメッセージｍの両方を含み、以下のように書かれる：
ここで、メッセージｍ＝（ＭｅｔａＤａｔａ，ＰｕｂＫｅｙ，ＡｄｄＤａｔａ）は、ＣＡの鍵ペアにとって適切なデジタル署名アルゴリズム（例えば、楕円曲線鍵ペアの場合のＥＣＤＳＡ）を使用して、ＣＡの私有鍵ｓｋＣＡで署名されるべきデータ構造である。
【数18】
【0159】
証明書は、その内容（メッセージｍ）に対するＣＡの署名を検証することによって妥当性確認することができ、以下のように表される：
ここで、Ｃｅｒｔ内の署名は、署名フェーズと同じ署名アルゴリズムを使用してＣＡの公開鍵ｐｋＣＡで検証される。信頼できるＣＡは、その鍵ペア（ｐｋＣＡ，ｓｋＣＡ）を使用してデータを証明するので、ＣＡの署名を検証することによって、証明書の真正性が保証される。メッセージの完全性は、デジタル署名アルゴリズムによって提供され、これは、典型的には、生データに署名するのではなくメッセージをハッシュし、ハッシュ関数の決定論的プロパティにより、署名後のメッセージの変化が署名を無効にするようにする。
【数19】
【0160】
【0161】
本明細書で説明される実施形態は、任意の特定の証明書規格に限定されないことが理解されよう。
【0162】
ユーザが自身のアイデンティティを自身の公開鍵にリンクすることには、多くの利点がある。１つの単純な例は、ユーザ経験の向上である。人間が読み取り可能な連絡先またはアイデンティティベースの情報を共有することは、公開鍵を構成する１６進数字の長い文字列を共有することよりもはるかに単純である。アイデンティティベースの情報は、比較的記憶しやすく、ユーザ間のトランザクションをよりアクセスしやすくする。
【0163】
重要な利点は、特に、公共のブロックチェーンを介して偽名で取引を行うユーザに対して、マネーロンダリング防止対策を講じる必要性が高まっていることである。例えば、ユーザは、自身のデジタルアイデンティティを証明機関（ＣＡ）に検証してもらうことができる。証明された私有鍵によって署名されたトランザクションは監査が可能であるので、デジタル支払いを受け入れる当事者に保証を提供する。
【0164】
公開鍵の証明は、ＢＩＰ３２などのＨＤウォレットが使用される場合、鍵のウォレット全体を証明することに拡張することができる。ユーザは、マスタ鍵またはアカウント鍵を証明するだけで、その子鍵のすべてが検証済みのアイデンティティに証明可能にリンクされるようにすることができる。
【0165】
本明細書では、子鍵が証明された親公開鍵から導出されることを証明するための方法を説明し、ここで、親鍵はプライバシーを守るために隠される。まず、証明者（アリス）が自身のアイデンティティをＣＡに検証してもらうセットアップフェーズについて説明する。その後、ＺＫＰは、検証者（ボブ）が、証明者のアイデンティティ情報を使用して、そのウォレットサーバに子公開鍵を要求するときに生成される。
【0166】
以下に、証明者（アリス）の親公開鍵ｐｋｐａｒの証明について説明する：
【数21】
【0167】
次に、証明書Ｃｅｒｔの内容を使用して、アイデンティティがリンクされた親鍵ｐｋｐａｒからＺＫＰをどのように生成することができるかについて説明する。
【0168】
図９に示される回路Ｃは、強化された子公開鍵ｐｋ’
ｉまたは強化されていない子公開鍵ｐｋｉのいずれかのためのＢＩＰ３２ ＣＫＤ関数を表し、１つまたは複数の既知の出力が与えられた場合の関数の入力の知識が証明される。図７は、証明生成／検証プロセスにおいてどの入力／出力が公開／秘密であるかを示すために使用される。
【0169】
回路Ｃは、以下の仮定に基づく：
【数22】
【0170】
回路への入力は以下の通りであり：
出力は以下の通りである：
【数23】
【数24】
【0171】
親公開鍵は、強化されていなくても強化されていてもよい（ｐｋ’
ｐａｒ）。ここでは、簡単にするために表記ｐｋｐａｒが使用される。
【0172】
証明者コンピュータ機器６０２ｂは、回路Ｃを実行して、有効な割り当てを出力する。すなわち、証明者コンピュータ機器６０２ｂは、上述の入力を回路Ｃに供給して、上述の出力を生成する。
【0173】
回路への有効な割り当て（Ｘ，Ｗ）は、６つの入力（Ｃｅｒｔ、ｃｐａｒ、ｉ、ｓｋｐａｒ、ｃｐａｒ、alice@email.com、ｐｋＣＡ）と、１つの出力（ｏｕｔ）と、ＡｄｄＤａｔａ，ｐｋｐａｒ，（ｓｋｐａｒ・Ｇ），■||ｉ，ＩＬ，（ＩＬ・Ｇ）を含む補助変数とを含み、ここで
【数25】
【0174】
大まかに言えば、この有効な割り当てのための回路における計算ステップは、以下の通りである：
【数26】
【0175】
拡張子公開鍵が出力（出力はチェーンコードｃｉを含む）において望まれる場合、チェーンコードｃｉは、ＨＭＡＣ関数の右端の出力ＩＲについてステップ２ｉｖを複製することによって計算することができる。
【0176】
回路が強化されていない子鍵のみを出力する場合、第４の入力（ｓｋｐａｒ ９０８）は必要ない。
【0177】
回路Ｃは、まず、証明者の公に知られているアイデンティティデータ、すなわち、アリスの電子メールアドレス（alice@email.com）が、アイデンティティ証明書のＡｄｄＤａｔａフィールドに公開されているものと一致することをチェックする。この公開アイデンティティの知識は、証明されたアイデンティティへの検証可能なリンクを確立し、後者は、証明書のデータ構造（メッセージｍ）内の証明者の親公開鍵ｐｋｐａｒを開示することを回避するために隠される。検証鍵が回路にリンクされているので、検証者は回路によって実行されるチェックについての知識を有することを想起されたい。回路は、証明書内のアイデンティをチェックし、証明書からの証明された公開鍵を使用して、検証者によって知られている出力を導出する。したがって、証明された親鍵の明示的な知識は必要とされない。回路は、公開入力として含まれるＣＡの公開鍵を使用してＣＡの署名を検証することによって証明書を妥当性確認する。署名チェックに合格した場合、回路は、親公開鍵の証明書を解析し、これを使用して、強化されていない子鍵を出力として導出する。強化された子鍵が必要な場合、私有親鍵ｓｋｐａｒ ９０８を、回路への追加の秘密入力として含めなければならない。次に、回路は、ＥＣＳＭサブルーチンを使用して、この私有鍵が証明書内の証明された公開鍵に対応するかどうかをチェックして、その対応する公開鍵を計算しなければならない。回路出力の子鍵は、これらのチェックのすべてが満たされると受け入れられる。上記で言及したチェックは検証鍵に組み込まれ、この検証鍵を使用して証明検証が合格した場合、検証者はこれらのチェックが合格したことを知ることができる。
【0178】
ユーザボブ（検証者）が、アリスの電子メールアドレスのみを使用してアリス（証明者）に支払いを行うことを望むシナリオを考える。このシナリオでは、検証者コンピュータ機器６０２ａは、ボブのコンピュータ機器１０２ａに対応する。証明者コンピュータ機器６０２ｂは、アリス１０３ａに関連付けられたコンピュータ機器１０２ａ、またはアリスのＢＩＰ３２ウォレットプロバイダに関連付けられたウォレットサーバに対応し得る。以下では、証明者コンピュータ機器６０２ｂがアリスのＢＩＰ３２ウォレットプロバイダに関連付けられたウォレットサーバに対応する例を参照する。
【0179】
ボブ１０３ｂは、alice@email.comを使用して、アリスの支払いアドレスをアリスのウォレットサーバ（証明者コンピュータ機器６０２ｂ）に要求し、その後、アリス１０３ａの支払いアドレスをアリスのウォレットサーバから受信する。ステップＳ６０２において、ボブ１０３ｂは、強化されていない子公開鍵ｐｋｉまたは強化された子公開鍵ｐｋ’
ｉ ９１６を（アリスのコンピュータ機器１０２ａから直接、アリスのウォレットサーバから、または他の何らかの手段によって）取得する。
【0180】
ステップＳ６０４において、ボブ１０３ｂは、支払いトランザクションを終了する前に、この公開鍵が真正であることの証明を要求する。
【0181】
ステップＳ６０６において、ウォレットサーバは、ＣＫＤ関数を表す公開回路への有効な割り当てに基づいて証明を生成する。特に、ウォレットサーバは、ボブが、アリスの証明された鍵ｐｋｐａｒにリンクされた有効な子公開鍵を提供されたことを、証明された親公開鍵自体を開示することなく検証するための証明πを生成する。
【0182】
ステップＳ６０６において証明を生成するために、アリスのウォレットサーバ（証明者コンピュータ機器６０２ｂ）は、この例示的な実施形態では、関数Ｆ９１４への公開入力（証明者の電子メールアドレスalice@email.com９１０および発行ＣＡの公開鍵ｐｋＣＡ ９１２）と、関数Ｆ９１４からの公開出力（強化された子公開鍵ｐｋ’
ｉまたは強化されていない子公開鍵ｐｋｉ ９１６）とを含む証明生成プロセスへの入力「Ｘ」を供給する。
【0183】
ステップＳ６０６において証明を生成するために、アリスのウォレットサーバ（証明者コンピュータ機器６０２ｂ）は、有効な割り当て内のすべての秘密パラメータ、例えば、関数Ｆ９１４への秘密入力（受信者の署名済みデジタル証明書Ｃｅｒｔ９０２、親鍵ｃｐａｒ ９０４に対応するチェーンコード、インデックスｉ ９０６、および出力内の強化された鍵の場合は私有親鍵ｓｋｐａｒ ９０８）および任意の秘密の補助変数を含む証明生成プロセスへの入力「Ｗ」をさらに供給する。
【0184】
証明者コンピュータ機器６０２ｂは、証明生成プロセスへの入力として証明鍵ｐｋＦをさらに供給する。
【0185】
証明者コンピュータ機器６０２ｂによって実施される証明生成プロセスは、入力「Ｘ」、「Ｗ」、および証明鍵ｐｋＦを使用して、証明πを生成する。
【0186】
簡単にするために、この例示的な証明に対しては、ここでは、強化されていない子鍵のみを参照する。ウォレットサーバの証明を検証することによって、ボブは、子公開鍵ｐｋｉから導出された支払いアドレスが正しいと納得する。
【0187】
アイデンティティがリンクされたＣＫＤプロトコルは以下の通りである：
【数27】
【0188】
ＺＫＰは以下のように構成される：
【数28】
【0189】
証明を検証するために、検証者コンピュータ機器６０２ａは、この例示的な実施形態では、関数Ｆ９１４への公開入力（証明者の電子メールアドレスalice@email.com ９１０、および発行ＣＡの公開鍵ｐｋＣＡ ９１２）、および関数Ｆからの公開出力（強化された子公開鍵ｐｋ’
ｉまたは強化されていない子公開鍵ｐｋｉ ９１６）を含む証明検証プロセスへの証明および入力「Ｘ」を供給する。
【0190】
検証者コンピュータ機器６０２ａは、証明検証プロセスへの入力として検証鍵ｖｋＦをさらに供給する。
【0191】
検証者コンピュータ機器６０２ａによって実施される証明検証プロセスは、証明、入力「Ｘ」、および検証鍵ｖｋＦを使用して、証明πを検証する。証明検証プロセスは、証明が有効であると判明したか無効であると判明したかに応じて、受け入れまたは拒否の決定を出力する。ステップＳ６１０においてアリスの証明を検証することによって、ボブ１０３ｂは、ＢＩＰ３２導出方法を使用して、証明された親公開鍵から子公開鍵が正しく導出されたことを確信することができる。これは、アリスに対して有する支払いアドレスが実際に正しいものであることをボブ１０３ｂに確信させる。
【0192】
この実施形態は、親チェーンコードｃｐａｒ ９０４と鍵インデックスｉ ９０６とを含む証明生成プロセスにおいて使用される入力「Ｗ」を参照して上述されているが、これは一例にすぎず、親チェーンコードｃｐａｒ ９０４と鍵インデックスｉ ９０６のいずれか一方または両方が、証明生成プロセスおよび証明検証プロセスにおいて使用される入力「Ｘ」の一部である公開入力ｘであってもよい。親チェーンコードｃｐａｒ ９０４および鍵インデックスｉ ９０６の各々は、秘密であっても公開であってもよい。
【0193】
難読化されアイデンティティがリンクされた子鍵導出証明
この実施形態では、ＺＫＰの計算効率を最適化しながら、ウォレットユーザの証明の計算コストを削減しようとする、アイデンティティがリンクされたＣＫＤ証明のための代替プロトコルについて説明する。
この実施形態では、ＺＫＰの計算効率を最適化しながら、ウォレットユーザの証明の計算コストを削減しようとする、アイデンティティがリンクされたＣＫＤ証明のための代替プロトコルについて説明する。
【0194】
上記のセクションは、ユーザ（例えば、証明者として機能するアリス）が、ＣＡで親公開鍵を証明するために従うステップを説明する。この証明プロセスは、期限切れのアイデンティティ証明書を定期的に更新する必要があるユーザに対して、増大する計算コストを発生させる。この実施形態では、証明書発行のための内部サービスを導入することによって、この費用をウォレットサーバに移す。
【0195】
ここで、証明者のウォレットサーバまたは証明者のウォレットサーバと提携した第三者は、信頼できるＣＡから認定を得ることによって、署名機関（ＳＡ）として機能することができる。次いで、ＳＡは、そのＣＡによって証明された鍵ペアを使用してユーザ鍵を証明する。ＣＡ、ＳＡ、およびユーザの間の結果として得られる信頼チェーン（chain of trust）は、署名特権をウォレットサーバに割り当てることにより、ユーザ鍵の広範な証明を可能にし、次いで、ウォレットサーバは、そのユーザに証明書を提供することができる。検証者は、以下を行うことによってこの信頼チェーンを妥当性確認する必要があることに留意されたい：
・ ＳＡのアイデンティティを証明するＣＡの署名を検証すること、および
・ ユーザのアイデンティティを証明するＳＡの署名を検証すること。
・ ＳＡのアイデンティティを証明するＣＡの署名を検証すること、および
・ ユーザのアイデンティティを証明するＳＡの署名を検証すること。
【0196】
上述のセクションでは、ユーザのアイデンティティ証明書は、証明書データ構造内に埋め込まれた親公開鍵が検証中に検証者から隠されるように、回路への秘密入力として設定される。証明の検証とは独立して署名検証を実行することによって、回路のサイズを削減してＺＫＰの計算効率を最適化することが可能である。これは、証明された親鍵が検証者から隠されたままであることを保証するために、追加のステップを必要とする。
【0197】
ここで、ＳＡが、ユーザの親公開鍵を証明書に埋め込む前に難読化することが必要である。より具体的には、ＳＡは、親鍵のハッシュベースのコミットメントを生成し、次いで、これは、ＳＡによって署名されたデータ構造内のユーザのアイデンティティにリンクされる。この署名されたデータ構造のフォーマットは、親公開鍵自体ではなくユーザの親鍵のコミットメントを含むという点で、ＣＡ発行のアイデンティティ証明書とは異なる。
【0198】
コミットメント方式は、送信者（コミッタ）と受信者（検証者）との間で行われる以下の２フェーズプロトコルである。
Ｉ． Ｃｏｍｍｉｔ（コミット）－コミッタは、秘密メッセージｍを知っており、ランダム値ｒを使用してコミットメントＣｏｍｍｉｔ（ｍ，ｒ）を生成する。次に、コミットされた値Ｃｏｍｍｉｔ（ｍ，ｒ）が検証者に送信される。
ＩＩ． Ｏｐｅｎｉｎｇ（オープニング）－コミッタはメッセージｍおよびランダム値ｒを明らかにし、検証者はコミットメントをオープンし、その正当性を妥当性確認することができる。
Ｉ． Ｃｏｍｍｉｔ（コミット）－コミッタは、秘密メッセージｍを知っており、ランダム値ｒを使用してコミットメントＣｏｍｍｉｔ（ｍ，ｒ）を生成する。次に、コミットされた値Ｃｏｍｍｉｔ（ｍ，ｒ）が検証者に送信される。
ＩＩ． Ｏｐｅｎｉｎｇ（オープニング）－コミッタはメッセージｍおよびランダム値ｒを明らかにし、検証者はコミットメントをオープンし、その正当性を妥当性確認することができる。
【0199】
コミットメント方式は、以下の２つのセキュリティプロパティを満たす必要がある：
・ ハイディング（hiding）－コミットフェーズの後、コミットメントは、メッセージｍに関するいかなる情報も、例えば悪意のある検証者に漏らしてはならない。
・ バインディング（binding）－オープンフェーズの間、コミッタは、例えば、コミットメントが異なるメッセージｍ’をオープンする原因となる異なるランダム性ｒ’を送信することによって、メッセージｍを変更することができない。
・ ハイディング（hiding）－コミットフェーズの後、コミットメントは、メッセージｍに関するいかなる情報も、例えば悪意のある検証者に漏らしてはならない。
・ バインディング（binding）－オープンフェーズの間、コミッタは、例えば、コミットメントが異なるメッセージｍ’をオープンする原因となる異なるランダム性ｒ’を送信することによって、メッセージｍを変更することができない。
【0200】
セキュアなコミットメントとは、ハイディングプロパティとバインディングプロパティの両方が満たされているコミットメントのことである。コミットメント方式は、ハッシュ関数またはランダム化された暗号化アルゴリズムを使用することができる。
【0201】
本明細書では、効率のためにハッシュベースのコミットメント方式の使用を参照するが、他のタイプのコミットメント方式が使用されてもよいことが理解されよう。
【0202】
署名機関（ＳＡ）は、ウォレットサーバの代わりに親鍵をアイデンティティにリンクするように機能する信頼できるアフィリエイトであると定義する。ＳＡはまず、証明者の親鍵のハッシュベースのコミットメントを導出し、次いで、それは、デジタル証明書（本明細書では第２のアイデンティティ証明書とも呼ばれる）に似た署名されたデータ構造内の証明者のアイデンティティデータにリンクされる。ＳＡによって発行されるこの署名されたデータ構造は、デジタル証明書に通常含まれる生の親公開鍵の代わりに、ユーザの親公開鍵のハッシュベースのコミットメントを含む。
【0203】
ここで、ＳＡのアイデンティティは、ＣＡがＳＡのデジタル鍵ペアを証明するためのデジタル証明書を発行するセットアップの前に（上述のセクションにおける証明者と同じステップにしたがって）検証されていると仮定する。セットアップ中のすべての計算は、ＳＡの私有鍵ｓｋＳＡを保護し、その攻撃対象領域（attack surface）を減少させるためにオフラインで実行されることに留意されたい。
【数29】
【0204】
上記のステップＩにおける公開鍵の難読化は、ユーザのプライバシーが守られることを保証する。コミットメントを作成する前に、公開親鍵とチェーンコード（ｐｋｐａｒ||ｃｐａｒ）とを連結することによって、完全拡張親鍵も難読化することができる。代替的に、公開鍵およびチェーンコードの２つの別個のコミットメント（ｃｏｍ１，ｃｏｍ２）を、それぞれ２つの別個のランダム値ｒ１，ｒ２∈Ｒ｛０，１｝２２５を使用して計算してもよい。このプロトコルを使用してＣＫＤ証明を求める各ユーザ要求が、コミットメント内に含まれる別個のランダム値ｒにより別個のコミットメントｃｏｍを生成することは注目に値する。
【0205】
この実施形態では、親公開鍵の署名されたコミットメントを使用してＺＫＰを生成する。
【0206】
図１０に示される回路Ｃは、強化された子公開鍵ｐｋ’
ｉまたは強化されていない子公開鍵ｐｋｉのいずれかのためのＢＩＰ３２ ＣＫＤ関数を表し、１つまたは複数の既知の出力が与えられた場合の関数の入力の知識が証明される。図１０は、証明生成／検証プロセスにおいてどの入力／出力が公開／秘密であるかを示すために使用される。
【0207】
回路Ｃは、以下の仮定に基づく：
【数30】
【0208】
回路への入力は以下の通りであり：
出力は、以下の通りである：
【数31】
【数32】
【0209】
親公開鍵は、強化されていなくても強化されていてもよい（ｐｋ’
ｐａｒ）。ここでは、簡単にするために表記ｐｋｐａｒが使用される。
【0210】
証明者コンピュータ機器６０２ｂは、回路Ｃを実行して、有効な割り当てを出力する。すなわち、証明者コンピュータ機器６０２ｂは、上述の入力を回路Ｃに供給して、上述の出力を生成する。
【0211】
回路への有効な割り当て（Ｘ，Ｗ）は、５つの入力（ｓｋｐａｒ、ｃｐａｒ、ｉ、ｒ、alias@nchain.com）と、２つの出力（ｏｕｔｌ、ｍｃｏｍ）と、ｐｋｐａｒ，■||ｉ，ＩＬ，（ＩＬ・Ｇ），ｃｏｍ｝を含む補助変数とを含み、
【数33】
【0212】
図１０は、入力が公開であるか秘密（影付きのボックスによって示される）であるか、および指定された出力を生成する関数Ｆ１０１２内で行われる計算を示す。関数Ｆ１０１２の実行中に生成される補助変数は、図１０には明示的に示されていない。
【0213】
大まかに言えば、この有効な割り当てのための回路における計算ステップは、以下の通りである：
【数34】
【0214】
図１０は、私有鍵ｓｋｐａｒが入力として設定されていることを示しているが、代わりに、公開親鍵ｐｋｐａｒを入力として設定することができる。ただし、これは、出力を、強化されていない子鍵のみに限定する（ステップ２ｉは不要である）。
【0215】
拡張子公開鍵が出力（出力はチェーンコードｃｉを含む）において望まれる場合、チェーンコードｃｉは、ＨＭＡＣ関数の右端の出力ＩＲについてステップ２ｉｉｉを複製することによって計算され得る。
【0216】
図１１ａは、子公開鍵の真正性を検証するためのプロセス６００において、検証者コンピュータ機器６０２ａおよび証明者コンピュータ機器６０２ｂによって実行されるステップを示す。
【0217】
アリス（証明者）のエイリアスalice@nchain.comを使用してアリスに支払いを送信したいユーザボブ（検証者）のシナリオを考える。このシナリオでは、検証者コンピュータ機器６０２ａは、ボブのコンピュータ機器１０２ｂに対応する。以下では、証明者コンピュータ機器６０２ｂがアリスのＢＩＰ３２ウォレットプロバイダに関連付けられたウォレットサーバに対応する例を参照する。この変形例では、証明者コンピュータ機器６０２ｂは、アリスのコンピュータ機器１０２ａに対応してもよい。
【0218】
ステップＳ１１０２において、検証者ボブに関連付けられた検証者コンピュータ機器６０２ａは、アリスのウォレットサーバ（証明者コンピュータ機器６０２ｂ）に、alice@nchain.comにリンクされた支払いアドレス（電子メールアドレス、または証明者に関連付けられた他の任意の一意識別子）を求める要求をサブミットする。
【0219】
ステップＳ１１０４において、アリスのウォレットサーバ（証明者コンピュータ機器６０２ｂ）は、（ＣＡによって発行された）第１のデジタル証明書Ｃｅｒｔを取得する。第１のデジタル証明書Ｃｅｒｔは、ＣＡの署名を含む。
【0220】
ステップＳ１１０６において、アリスのウォレットサーバ（証明者コンピュータ機器６０２ｂ）は、アリスの署名されたコミットメントである第２のデジタル証明書と、アリスの公的に知られているアイデンティティデータ（alice@nchain.com）および難読化された親鍵ｃｏｍを含む（ＳＡによって発行された）エイリアスＳｉｇｎＩＤとを取得する。
【0221】
いくつかの実施形態では、ウォレットサーバ（証明者コンピュータ機器６０２ｂ）は、信頼できるＣＡから認定を得ることによって、署名機関（ＳＡ）として機能することができる。これらの実施形態では、ウォレットサーバは、リモート署名機関デバイスの関与なしにステップＳ１１０４およびＳ１１０６を実行する。
【0222】
他の実施形態では、ウォレットサーバは、リモート署名機関デバイス６０２ｃと通信することによって、ステップＳ１１０４およびＳ１１０６を実行する。これは図１１ｂに示されており、ウォレットサーバは、ステップＳ１１５２において、アイデンティティがリンクされた親鍵を求める要求をリモート署名機関デバイス６０２ｃに送信する。ステップＳ１１５４において、リモート署名機関デバイス６０２ｃは、第１のデジタル証明書Ｃｅｒｔを取得する。リモート署名機関デバイス６０２ｃは、ステップＳ１１５６において、上記で説明した親公開鍵難読化を実行し、ステップＳ１１５８において、第２のデジタル証明書ＳｉｇｎＩＤを生成する。ステップＳ１１５６およびＳ１１５８は、好ましくは、ＳＡの私有鍵ｓｋＳＡを保護し、その攻撃対象領域を減少させるために、セキュリティ上の理由で、リモート署名機関デバイス６０２ｃがオフラインの（インターネットアクセスがない）間に、リモート署名機関デバイス６０２ｃによって実行される。
【0223】
したがって、ウォレットサーバの代わりに機能して、リモート署名機関デバイス６０２ｃは、以下のように、アイデンティティがリンクされたＣＫＤプロトコルを成立させる：
【数35】
【0224】
ステップＳ１１６０において、リモート署名機関デバイス６０２ｃは、第１のデジタル証明書Ｃｅｒｔおよび第２のデジタル証明書ＳｉｇｎＩＤをウォレットサーバ（証明者コンピュータ機器６０２ｂ）に送信する。
【0225】
ステップＳ１１０８において、ウォレットサーバ（証明者コンピュータ機器６０２ｂ）は、ＣＫＤ関数を表す公開回路への有効な割り当てに基づいて証明を生成する。
【0226】
ステップＳ１１０８において証明を生成するために、証明者コンピュータ機器６０２ｂは、この例示的な実施形態では、関数Ｆ１０１２への公開入力（証明者の一意識別子alice@nchain.com １０１０）と、関数Ｆ１０１２からの公開出力（強化されていない子公開鍵ｐｋｉまたは強化された子公開鍵ｐｋ’
ｉ １０１４およびメッセージｍｃｏｍ １０１６）とを含む証明生成プロセスへの入力「Ｘ」を供給する。
【0227】
子公開鍵１０１４は、ウォレットサーバ（証明者コンピュータ機器６０２ｂ）によって計算され得る。代替的に、図１１ｂの例では、子公開鍵１０１４は、リモート署名機関デバイス６０２ｃによって計算され、ステップＳ１１６０ｃにおいてウォレットサーバに供給され得る。
【0228】
例示的な証明における強化されていない公開親および子鍵の例では、この子公開鍵計算は、以下を含む：
【数36】
【0229】
この証明は、所与の子鍵ｐｋｉが、ＳｉｇｎＩＤ内の署名され難読化された親鍵から生成されたことを証明する。
【0230】
ステップＳ１１０８において証明を生成するために、証明者コンピュータ機器６０２ｂは、有効な割り当て内のすべての秘密パラメータ、例えば、関数Ｆ１０１２への秘密入力（私有親鍵ｓｋｐａｒ １００２、親鍵ｃｐａｒに対応するチェーンコード１００４、インデックスｉ １００６、およびランダム値ｒ １００８）と任意の秘密補助変数とを含む証明生成プロセスへの入力「Ｗ」をさらに供給する。
【0231】
証明者コンピュータ機器６０２ｂは、証明生成プロセスへの入力として証明鍵ｐｋＦをさらに供給する。
【0232】
証明の例における強化されていない公開親および子鍵の例では、ウォレットサーバは、以下のようにＺＫＰを構築する：
【数37】
【0233】
ウォレットサーバによって実施される証明生成プロセスは、入力「Ｘ」、「Ｗ」、および証明鍵ｐｋＦを使用して、証明πを生成する。アリスの証明は、ボブに送信される公開鍵が実際にアリスの証明された親鍵の子であることを示す。
【0234】
ステップＳ１１１０において、ウォレットサーバ（証明者コンピュータ機器６０２ｂ）は、第１のデジタル証明書Ｃｅｒｔ、第２のデジタル証明書ＳｉｇｎＩＤ、証明π、およびalice@nchain.comの子鍵を検証者コンピュータ機器６０２ａに送信する。
【0235】
この実施形態では、子公開鍵の真正性を決定することは、複数のステップを含む。
【0236】
ステップＳ１１１２において、検証者コンピュータ機器６０２ａは、証明πを検証する。証明を検証するために、検証者コンピュータ機器６０２ａは、この例示的な実施形態では、関数Ｆ１０１２への公開入力（証明者の一意識別子lice@nchain.com １０１０）と、関数Ｆ１０１２からの公開出力（強化されていない子公開鍵ｐｋｉまたは強化された子公開鍵ｐｋ’
ｉ １０１４およびメッセージｍｃｏｍ １０１６）とを含む証明検証プロセスへの入力「Ｘ」および証明を供給する。
【0237】
検証者コンピュータ機器６０２ａは、証明検証プロセスへの入力として検証鍵ｖｋＦをさらに供給する。
【0238】
検証者コンピュータ機器６０２ａによって実施される証明検証プロセスは、証明、入力「Ｘ」、および検証鍵ｖｋＦを使用して、証明πを検証する。証明検証プロセスは、証明が有効であると判明したか無効であると判明したかに応じて、受け入れまたは拒否の決定を出力する。
【0239】
ｐｋｉの証明を検証することによって、ボブは、第２の出力ｍｃｏｍ内のコミットメントにおける、アイデンティティがリンクされた親鍵の子としてのその真正性を検証する。
【0240】
ステップＳ１１１４において、第２のデジタル証明書ＳｉｇｎＩＤ内の親鍵の難読化バージョンの完全性は、（ｉ）第１のデジタル証明書ＣｅｒｔのＣＡの署名を（ＣＡの公開鍵を使用して）検証し、第２のデジタル証明書ＳｉｇｎＩＤのＳＡの署名を（ＳＡの公開鍵を使用して）検証することによって検証される。ＳＡのアイデンティティ証明書およびアリスの署名されたコミットメントにおける署名を検証することは、ＣＡ、ＳＡ、およびアリスの間の信頼チェーンを確立する。したがって、ボブは、ＳｉｇｎＩＤにおける難読化された親鍵の完全性に満足することができる。
【0241】
これは以下のことを伴う：
【数38】
【0242】
ステップＳ１１１６において、検証者コンピュータ機器６０２ａは、第２のデジタル証明書ＳｉｇｎＩＤにおいて受信されたメッセージｍｃｏｍを検証する。
【0243】
特に、検証者コンピュータ機器６０２ａは、証明を生成するために証明コンピュータデバイスによって使用されるメッセージｍｃｏｍ １０１６を取得する。例えば、検証者コンピュータ機器６０２ａは、証明コンピュータデバイスから（証明を生成するために証明コンピュータデバイスによって使用される）メッセージｍｃｏｍ １０１６を受信し得る。検証者コンピュータ機器６０２ａは、証明を生成するために証明コンピュータデバイスによって使用されるメッセージｍｃｏｍ １０１６が、第２のデジタル証明書ＳｉｇｎＩＤにおいて受信されたメッセージｍｃｏｍと一致することを検証する。
【0244】
ステップ１１１８においてこれら３つの検証ステップが成功裏に行われると、検証者は子公開鍵を真正なものとして受け入れる。次いで、ボブ１０３ｂは、子鍵から導出された支払いアドレスにトランザクションを送信することに進むことができる。
【0245】
この実施形態は、親チェーンコードｃｐａｒ １００４と鍵インデックスｉ１００６とを含む証明生成プロセスにおいて使用される入力「Ｗ」を参照して上記で説明されてきたが、これは一例にすぎず、親チェーンコードｃｐａｒ １００４と鍵インデックスｉ １００６のいずれか一方または両方が、証明生成プロセスおよび証明検証プロセスにおいて使用される入力「Ｘ」の一部である公開入力ｘであってもよい。親チェーンコードｃｐａｒ １００４および鍵インデックス１００６の各々は、秘密であっても公開であってもよい。
【0246】
結論
開示される技法の他の変形形態またはユースケースは、本明細書の開示が与えられると、当業者には明らかになり得る。本開示の範囲は、説明された実施形態によって限定されず、添付の特許請求の範囲によってのみ限定される。
開示される技法の他の変形形態またはユースケースは、本明細書の開示が与えられると、当業者には明らかになり得る。本開示の範囲は、説明された実施形態によって限定されず、添付の特許請求の範囲によってのみ限定される。
【0247】
例えば、上記のいくつかの実施形態は、証明者の電子メールアドレスである証明者の一意識別子を参照して説明されているが、これは一例にすぎず、他の一意識別子（例えば、電話番号または他の連絡先詳細、社会保障番号、ＩＤ番号など）が使用されてもよい。
【0248】
当業者であれば、入力「Ｘ」、「Ｗ」および証明鍵ｐｋＦを使用して証明πを生成する、証明コンピュータデバイスによって実施される証明生成プロセスに含まれるステップが、実施されるＺＫＰの特定のタイプに依存し、そのようなステップが当業者に知られていることを理解するであろう。同様に、当業者であれば、証明、入力「Ｘ」および検証鍵ｖｋＦを使用して証明πを検証する、検証者コンピュータ機器によって実施される証明検証プロセスに含まれるステップが、実施されるＺＫＰの特定のタイプに依存し、そのようなステップが当業者に知られていることを理解するであろう。
【0249】
実施形態は、検証者が証明者に支払いを送信し、証明が、子公開鍵から導出された支払いアドレスが真正であることを証明するという文脈で上記では説明されてきたが、本発明の実施形態は、この支払いの文脈に限定されず、実施形態は、（オンラインアイデンティティを表す）デジタル鍵が、例えば、データトランザクション、スマートコントラクトなどにおいて使用される任意のアプリケーションに拡張される。
【0250】
実施形態は、ＢＩＰ３２鍵導出プロトコルを参照して上記で説明されてきたが、実施形態は、他の鍵導出プロトコルに拡張される。
【0251】
上記のいくつかの実施形態は、ビットコインネットワーク１０６、ビットコインブロックチェーン１５０およびビットコインノード１０４に関して説明されている。しかしながら、ビットコインブロックチェーンはブロックチェーン１５０の１つの特定の例であり、上記の説明は一般に任意のブロックチェーンに適用されてもよいことが理解されよう。すなわち、本発明はビットコインブロックチェーンに限定されるものではない。より一般的には、ビットコインネットワーク１０６、ビットコインブロックチェーン１５０およびビットコインノード１０４への上記の任意の参照は、それぞれブロックチェーンネットワーク１０６、ブロックチェーン１５０およびブロックチェーンノード１０４への参照に置き換えられてもよい。ブロックチェーン、ブロックチェーンネットワークおよび／またはブロックチェーンノードは、上記で説明したようなビットコインブロックチェーン１５０、ビットコインネットワーク１０６およびビットコインノード１０４の説明されたプロパティの一部またはすべてを共有してもよい。
【0252】
本発明の好ましい実施形態では、ブロックチェーンネットワーク１０６はビットコインネットワークであり、ビットコインノード１０４は、ブロックチェーン１５０のブロック１５１を作成、公開、伝搬、および記憶する説明した機能を少なくともすべて実行する。これらの機能のすべてではなく１つまたはいくつかのみを実行する他のネットワークエンティティ（またはネットワーク要素）が存在し得ることは除外されない。すなわち、ネットワークエンティティは、ブロックを作成および公開することなしに、ブロックを伝搬および／または記憶する機能を実行し得る（これらのエンティティが好ましいビットコインネットワーク１０６のノードとみなされないことを想起されたい）。
【0253】
本発明の他の実施形態では、ブロックチェーンネットワーク１０６はビットコインネットワークでなくてもよい。これらの実施形態では、ノードが、ブロックチェーン１５０のブロック１５１を作成、公開、伝搬、および記憶する機能のうちの少なくとも１つまたはすべてではないがいくつかを実行してもよいことは除外されない。例えば、それらの他のブロックチェーンネットワーク上では、「ノード」は、ブロック１５１を作成および公開はするが、それらのブロック１５１を記憶および／または他のノードへの伝搬はしないように構成されたネットワークエンティティを指すために使用され得る。
【0254】
さらにより一般的には、上記の「ビットコインノード」１０４という用語へのいかなる言及も、「ネットワークエンティティ」または「ネットワーク要素」という用語と置き換えラレ絵、そのようなエンティティ／要素は、ブロックを作成、公開、伝搬、および記憶する役割の一部または全部を実行するように構成される。そのようなネットワークエンティティ／要素の機能は、ブロックチェーンノード１０４を参照して上記で説明したものと同じ方法でハードウェアに実装されてもよい。
【0255】
上記の実施形態は、単なる例として説明されていることが理解されよう。より一般的には、以下のステートメントのうちの任意の１つまたは複数による方法、装置、またはプログラムが提供され得る。
【0256】
本開示の態様は、以下の条項を参照して以下に定義される。
［１］エンティティに関連付けられた子公開鍵の真正性を検証するコンピュータ実装方法であって、方法は、コンピューティングデバイス上で実行され、
子公開鍵を取得するステップと、
証明コンピューティングデバイスからゼロ知識証明を受信するステップであって、証明コンピューティングデバイスは、上記エンティティに関連付けられ得る、ステップと、
ゼロ知識証明が有効であることを、証明、子公開鍵、および検証鍵を使用して検証して、鍵導出プロトコルが、親鍵から子公開鍵を導出するために使用されたことを決定するステップと、
検証に基づいて子公開鍵の真正性を決定するステップと
を含む方法。
［２］子公開鍵を取得するステップは、証明コンピューティングデバイスから子公開鍵を受信するステップを含む、条項１に記載のコンピュータ実装方法。
［３］方法は、
子公開鍵が真正であることの証明を求める要求を証明コンピュータデバイスに送信するステップ
を含み、
ゼロ知識証明は、要求に応答して受信される、
条項１または２に記載のコンピュータ実装方法。
［４］親鍵は、私有親鍵であり、子公開鍵は、強化された子公開鍵である、いずれかの先行する条項に記載のコンピュータ実装方法。
［５］親鍵は親公開鍵である、条項１から３のいずれかに記載のコンピュータ実装方法。
［６］私有親鍵に対応する親公開鍵のコピーを取得するステップ
をさらに含み、
ゼロ知識証明が有効であることを検証するステップは親公開鍵をさらに使用する、
条項４に記載のコンピュータ実装方法。
［７］証明を生成するために証明コンピュータデバイスによって使用される親公開鍵を証明コンピュータデバイスから受信するステップ
をさらに含み、
子公開鍵の真正性を決定するステップは、証明を生成するために証明コンピュータデバイスによって使用される親公開鍵が親公開鍵の取得されたコピーと一致するかどうかにさらに基づく、
条項６に記載のコンピュータ実装方法。
［８］親鍵は、認証局によって発行された署名済みデジタル証明書の証明された親公開鍵である、条項６に記載のコンピュータ実装方法。
［９］署名済みデジタル証明書は、エンティティの一意識別子を含み、ゼロ知識証明が有効であることを検証するステップは、エンティティの公開一意識別子が、署名済みデジタル証明書内のエンティティの一意識別子と一致することをチェックするステップを含む、条項８に記載のコンピュータ実装方法。
［１０］署名済みデジタル証明書は、認証局の私有鍵を使用して署名され、ゼロ知識証明が有効であることを検証するステップは、認証局の公開鍵を使用して認証局の署名を検証するステップを含む、条項８または９に記載のコンピュータ実装方法。
［１１］署名機関に関連付けられた第１のアイデンティティ証明書を受信するステップであって、第１のアイデンティティ証明書は、認証局の第１の署名を含む、ステップと、
エンティティに関連付けられた第２のアイデンティティ証明書を受信するステップであって、第２のアイデンティティ証明書は、署名機関の第２の署名とメッセージとを含み、メッセージは、親鍵の難読化バージョンとエンティティの一意識別子とを含む、ステップ
を含み、
ゼロ知識証明が有効であることを検証するステップは、メッセージをさらに使用する、
条項１から５のいずれかに記載のコンピュータ実装方法。
［１２］子公開鍵の真正性を決定するステップは、
認証局の公開鍵を使用して第１の署名を検証し、署名機関の公開鍵を使用して第２の署名を検証することによって、第２のアイデンティティ証明書内の親鍵の難読化バージョンの完全性を検証すること
にさらに基づく、条項１１に記載のコンピュータ実装方法。
［１３］証明を生成するために証明コンピュータデバイスによって使用されるメッセージを取得するステップ
をさらに含み、
子公開鍵の真正性を決定するステップは、証明を生成するために証明コンピュータデバイスによって使用されるメッセージが第２のアイデンティティ証明書内のメッセージと一致することを検証することにさらに基づく、
条項１１または１２に記載のコンピュータ実装方法。
［１４］証明コンピュータデバイスに要求を送信するステップであって、要求は子公開鍵を要求する、ステップと、
要求に応答して、子公開鍵、ゼロ知識証明、第１のアイデンティティ証明書、および第２のアイデンティティ証明書を受信するステップと
をさらに含む、条項１１から１３のいずれかに記載のコンピュータ実装方法。
［１５］エンティティに関連付けられた子公開鍵の真正性の証明を提供するコンピュータ実装方法であって、方法は、コンピューティングデバイス上で実行され、
子公開鍵を導出するために使用される親鍵、子公開鍵、および証明鍵を使用してゼロ知識証明を生成するステップと、
ゼロ知識証明を検証コンピューティングデバイスに送信して、検証コンピューティングデバイスが、親鍵から子公開鍵を導出するために鍵導出プロトコルが使用されたことを証明できるようにするステップと
を含むコンピュータ実装方法。
［１６］親鍵は、ハッシュ関数出力の第１の部分を使用して生成され、方法は、ハッシュ関数出力の残りの部分を使用してゼロ知識証明を生成するステップを含む、条項１５に記載のコンピュータ実装方法。
［１７］方法は、子公開鍵が強化されているか強化されていないかを示す鍵インデックスを使用してゼロ知識証明を生成するステップを含む、条項１５または１６に記載のコンピュータ実装方法。
［１８］親鍵は、検証コンピューティングデバイスに公開されていない親私有鍵であり、子公開鍵は、強化された子公開鍵である、条項１５から１７のいずれかに記載のコンピュータ実装方法。
［１９］親鍵は親公開鍵である、条項１５から１７のいずれかに記載のコンピュータ実装方法。
［２０］方法は、
（ｉ）親公開鍵とエンティティの公に知られている一意識別子とを含み、認証局によって署名され、検証コンピューティングデバイスに公開されていない署名済みデジタル証明書と、（ｉｉ）エンティティの一意識別子と、（ｉｉｉ）認証局に関連付けられた公開鍵とをさらに使用してゼロ知識証明を生成するステップ
を含む、条項１９に記載のコンピュータ実装方法。
［２１］方法は、（ｉｖ）親公開鍵に対応する親私有鍵をさらに使用してゼロ知識証明を生成するステップを含み、子公開鍵は、強化された子公開鍵である、条項２０に記載のコンピュータ実装方法。
［２２］子公開鍵は、強化されていない子公開鍵である、条項１９または２０に記載のコンピュータ実装方法。
［２３］方法は、
署名機関に関連付けられた第１のアイデンティティ証明書を取得するステップであって、第１のアイデンティティ証明書は、認証局の第１の署名を含む、ステップと、
エンティティに関連付けられた第２のアイデンティティ証明書を取得するステップであって、第２のアイデンティティ証明書は、署名機関の第２の署名とメッセージとを含み、メッセージは、親鍵の難読化バージョンとエンティティの一意識別子とを含む、ステップと
を含み、
方法は、親鍵の難読化されたバージョンを生成するために使用されるランダム値と、コンピューティングデバイスに関連付けられたエンティティの一意識別子とをさらに使用してゼロ知識証明を生成するステップを含み、方法は、
第１のアイデンティティ証明書および第２のアイデンティティ証明書を検証コンピューティングデバイスに送信するステップ
をさらに含む、条項１５から１８のいずれかに記載のコンピュータ実装方法。
［２４］コンピューティングデバイスは署名機関として機能し、第２のアイデンティティ証明書を取得するステップは、
ランダム値を使用して親鍵を難読化して、親鍵の難読化されたバージョンを生成するステップと、
署名機関に関連付けられた私有鍵を使用して、親鍵の難読化されたバージョンとエンティティの識別子とを含むメッセージに署名することによって、第２のアイデンティティ証明書を生成するステップと
を含む、条項２３に記載のコンピュータ実装方法。
［２５］第１のアイデンティティ証明書および第２のアイデンティティ証明書を取得するステップは、署名機関に関連付けられたリモートコンピューティングデバイスから第１のアイデンティティ証明書および第２のアイデンティティ証明書を受信するステップを含む、条項２３または２４に記載のコンピュータ実装方法。
［２６］方法は、子公開鍵を検証コンピューティングデバイスに送信するステップを含む、条項２３から２５のいずれかに記載のコンピュータ実装方法。
［２７］方法は、親私有鍵に対応する親公開鍵を検証コンピューティングデバイスに送信するステップを含む、条項１５から１８のいずれかに記載のコンピュータ実装方法。
［２８］鍵導出プロトコルは、親鍵を入力として取るハッシュ関数を含む、いずれかの先行する条項に記載のコンピュータ実装方法。
［２９］鍵導出プロトコルはＢＩＰ３２である、いずれかの先行する条項に記載のコンピュータ実装方法。
［３０］コンピュータプログラムであって、コンピューティングデバイスによって読み取られると、コンピューティングデバイスに、任意の先行する条項に記載の方法を実行させる、コンピュータプログラム。
［３１］コンピュータ可読命令を含む非一時的コンピュータ可読記憶媒体であって、コンピュータ可読命令は、コンピューティングデバイスによって読み取られると、コンピューティングデバイスに、条項１から２９のいずれかに記載の方法を実行させる、非一時的コンピュータ可読記憶媒体。
［３２］プロセッサとメモリとを備えるコンピューティングデバイスであって、メモリは、プロセッサによって実行されると、コンピューティングデバイスに、条項１から２９のいずれかに記載の方法を実行させる命令を記憶する、コンピューティングデバイス。
［１］エンティティに関連付けられた子公開鍵の真正性を検証するコンピュータ実装方法であって、方法は、コンピューティングデバイス上で実行され、
子公開鍵を取得するステップと、
証明コンピューティングデバイスからゼロ知識証明を受信するステップであって、証明コンピューティングデバイスは、上記エンティティに関連付けられ得る、ステップと、
ゼロ知識証明が有効であることを、証明、子公開鍵、および検証鍵を使用して検証して、鍵導出プロトコルが、親鍵から子公開鍵を導出するために使用されたことを決定するステップと、
検証に基づいて子公開鍵の真正性を決定するステップと
を含む方法。
［２］子公開鍵を取得するステップは、証明コンピューティングデバイスから子公開鍵を受信するステップを含む、条項１に記載のコンピュータ実装方法。
［３］方法は、
子公開鍵が真正であることの証明を求める要求を証明コンピュータデバイスに送信するステップ
を含み、
ゼロ知識証明は、要求に応答して受信される、
条項１または２に記載のコンピュータ実装方法。
［４］親鍵は、私有親鍵であり、子公開鍵は、強化された子公開鍵である、いずれかの先行する条項に記載のコンピュータ実装方法。
［５］親鍵は親公開鍵である、条項１から３のいずれかに記載のコンピュータ実装方法。
［６］私有親鍵に対応する親公開鍵のコピーを取得するステップ
をさらに含み、
ゼロ知識証明が有効であることを検証するステップは親公開鍵をさらに使用する、
条項４に記載のコンピュータ実装方法。
［７］証明を生成するために証明コンピュータデバイスによって使用される親公開鍵を証明コンピュータデバイスから受信するステップ
をさらに含み、
子公開鍵の真正性を決定するステップは、証明を生成するために証明コンピュータデバイスによって使用される親公開鍵が親公開鍵の取得されたコピーと一致するかどうかにさらに基づく、
条項６に記載のコンピュータ実装方法。
［８］親鍵は、認証局によって発行された署名済みデジタル証明書の証明された親公開鍵である、条項６に記載のコンピュータ実装方法。
［９］署名済みデジタル証明書は、エンティティの一意識別子を含み、ゼロ知識証明が有効であることを検証するステップは、エンティティの公開一意識別子が、署名済みデジタル証明書内のエンティティの一意識別子と一致することをチェックするステップを含む、条項８に記載のコンピュータ実装方法。
［１０］署名済みデジタル証明書は、認証局の私有鍵を使用して署名され、ゼロ知識証明が有効であることを検証するステップは、認証局の公開鍵を使用して認証局の署名を検証するステップを含む、条項８または９に記載のコンピュータ実装方法。
［１１］署名機関に関連付けられた第１のアイデンティティ証明書を受信するステップであって、第１のアイデンティティ証明書は、認証局の第１の署名を含む、ステップと、
エンティティに関連付けられた第２のアイデンティティ証明書を受信するステップであって、第２のアイデンティティ証明書は、署名機関の第２の署名とメッセージとを含み、メッセージは、親鍵の難読化バージョンとエンティティの一意識別子とを含む、ステップ
を含み、
ゼロ知識証明が有効であることを検証するステップは、メッセージをさらに使用する、
条項１から５のいずれかに記載のコンピュータ実装方法。
［１２］子公開鍵の真正性を決定するステップは、
認証局の公開鍵を使用して第１の署名を検証し、署名機関の公開鍵を使用して第２の署名を検証することによって、第２のアイデンティティ証明書内の親鍵の難読化バージョンの完全性を検証すること
にさらに基づく、条項１１に記載のコンピュータ実装方法。
［１３］証明を生成するために証明コンピュータデバイスによって使用されるメッセージを取得するステップ
をさらに含み、
子公開鍵の真正性を決定するステップは、証明を生成するために証明コンピュータデバイスによって使用されるメッセージが第２のアイデンティティ証明書内のメッセージと一致することを検証することにさらに基づく、
条項１１または１２に記載のコンピュータ実装方法。
［１４］証明コンピュータデバイスに要求を送信するステップであって、要求は子公開鍵を要求する、ステップと、
要求に応答して、子公開鍵、ゼロ知識証明、第１のアイデンティティ証明書、および第２のアイデンティティ証明書を受信するステップと
をさらに含む、条項１１から１３のいずれかに記載のコンピュータ実装方法。
［１５］エンティティに関連付けられた子公開鍵の真正性の証明を提供するコンピュータ実装方法であって、方法は、コンピューティングデバイス上で実行され、
子公開鍵を導出するために使用される親鍵、子公開鍵、および証明鍵を使用してゼロ知識証明を生成するステップと、
ゼロ知識証明を検証コンピューティングデバイスに送信して、検証コンピューティングデバイスが、親鍵から子公開鍵を導出するために鍵導出プロトコルが使用されたことを証明できるようにするステップと
を含むコンピュータ実装方法。
［１６］親鍵は、ハッシュ関数出力の第１の部分を使用して生成され、方法は、ハッシュ関数出力の残りの部分を使用してゼロ知識証明を生成するステップを含む、条項１５に記載のコンピュータ実装方法。
［１７］方法は、子公開鍵が強化されているか強化されていないかを示す鍵インデックスを使用してゼロ知識証明を生成するステップを含む、条項１５または１６に記載のコンピュータ実装方法。
［１８］親鍵は、検証コンピューティングデバイスに公開されていない親私有鍵であり、子公開鍵は、強化された子公開鍵である、条項１５から１７のいずれかに記載のコンピュータ実装方法。
［１９］親鍵は親公開鍵である、条項１５から１７のいずれかに記載のコンピュータ実装方法。
［２０］方法は、
（ｉ）親公開鍵とエンティティの公に知られている一意識別子とを含み、認証局によって署名され、検証コンピューティングデバイスに公開されていない署名済みデジタル証明書と、（ｉｉ）エンティティの一意識別子と、（ｉｉｉ）認証局に関連付けられた公開鍵とをさらに使用してゼロ知識証明を生成するステップ
を含む、条項１９に記載のコンピュータ実装方法。
［２１］方法は、（ｉｖ）親公開鍵に対応する親私有鍵をさらに使用してゼロ知識証明を生成するステップを含み、子公開鍵は、強化された子公開鍵である、条項２０に記載のコンピュータ実装方法。
［２２］子公開鍵は、強化されていない子公開鍵である、条項１９または２０に記載のコンピュータ実装方法。
［２３］方法は、
署名機関に関連付けられた第１のアイデンティティ証明書を取得するステップであって、第１のアイデンティティ証明書は、認証局の第１の署名を含む、ステップと、
エンティティに関連付けられた第２のアイデンティティ証明書を取得するステップであって、第２のアイデンティティ証明書は、署名機関の第２の署名とメッセージとを含み、メッセージは、親鍵の難読化バージョンとエンティティの一意識別子とを含む、ステップと
を含み、
方法は、親鍵の難読化されたバージョンを生成するために使用されるランダム値と、コンピューティングデバイスに関連付けられたエンティティの一意識別子とをさらに使用してゼロ知識証明を生成するステップを含み、方法は、
第１のアイデンティティ証明書および第２のアイデンティティ証明書を検証コンピューティングデバイスに送信するステップ
をさらに含む、条項１５から１８のいずれかに記載のコンピュータ実装方法。
［２４］コンピューティングデバイスは署名機関として機能し、第２のアイデンティティ証明書を取得するステップは、
ランダム値を使用して親鍵を難読化して、親鍵の難読化されたバージョンを生成するステップと、
署名機関に関連付けられた私有鍵を使用して、親鍵の難読化されたバージョンとエンティティの識別子とを含むメッセージに署名することによって、第２のアイデンティティ証明書を生成するステップと
を含む、条項２３に記載のコンピュータ実装方法。
［２５］第１のアイデンティティ証明書および第２のアイデンティティ証明書を取得するステップは、署名機関に関連付けられたリモートコンピューティングデバイスから第１のアイデンティティ証明書および第２のアイデンティティ証明書を受信するステップを含む、条項２３または２４に記載のコンピュータ実装方法。
［２６］方法は、子公開鍵を検証コンピューティングデバイスに送信するステップを含む、条項２３から２５のいずれかに記載のコンピュータ実装方法。
［２７］方法は、親私有鍵に対応する親公開鍵を検証コンピューティングデバイスに送信するステップを含む、条項１５から１８のいずれかに記載のコンピュータ実装方法。
［２８］鍵導出プロトコルは、親鍵を入力として取るハッシュ関数を含む、いずれかの先行する条項に記載のコンピュータ実装方法。
［２９］鍵導出プロトコルはＢＩＰ３２である、いずれかの先行する条項に記載のコンピュータ実装方法。
［３０］コンピュータプログラムであって、コンピューティングデバイスによって読み取られると、コンピューティングデバイスに、任意の先行する条項に記載の方法を実行させる、コンピュータプログラム。
［３１］コンピュータ可読命令を含む非一時的コンピュータ可読記憶媒体であって、コンピュータ可読命令は、コンピューティングデバイスによって読み取られると、コンピューティングデバイスに、条項１から２９のいずれかに記載の方法を実行させる、非一時的コンピュータ可読記憶媒体。
［３２］プロセッサとメモリとを備えるコンピューティングデバイスであって、メモリは、プロセッサによって実行されると、コンピューティングデバイスに、条項１から２９のいずれかに記載の方法を実行させる命令を記憶する、コンピューティングデバイス。
【0257】
命令は、ディスク、ＣＤまたはＤＶＤ－ＲＯＭ、読取り専用メモリ（ファームウェア）のようなプログラムされたメモリなどのキャリア上でまたは光もしくは電気信号キャリアなどのデータキャリア上で提供さ得る。本開示の実施形態を実装するための命令は、Ｃなどの従来のプログラミング言語（解釈またはコンパイルされた）でのソース、オブジェクト、または実行可能コード、またはアセンブリコード、ＡＳＩＣ（特定用途向け集積回路）またはＦＰＧＡ（フィールドプログラマブルゲートアレイ）をセットアップまたは制御するためのコード、またはハードウェア記述言語のためのコードを含み得る。
【図1】
【図2】
【図3A】
【図3B】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11a】
【図11b】
【図12】
【国際調査報告】