JP2023539432A - しきい値署名 - Google Patents

Abstract

デジタル署名のシェアを生成するコンピュータ実装方法であって、各参加者は、第１の共有秘密鍵のそれぞれのシェアを有し、方法は、第１の参加者によって実行され、第１のメッセージを取得することと、少なくとも第１の外部データ項目のハッシュに基づいて第１のデータ項目を生成することと、第１のデータ項目と、各他の参加者によって生成されたそれぞれのデータ項目とに基づいて、エフェメラル秘密鍵の第１のエフェメラル秘密鍵シェアを生成することと、エフェメラル秘密鍵に対応するエフェメラル公開鍵を生成することと、第１のメッセージと、第１のエフェメラル秘密鍵シェアと、第１の共有秘密鍵の第１のシェアと、エフェメラル公開鍵とに基づいて、第１の署名シェアを生成することと、少なくともしきい値数の署名シェアに基づいて第１の署名を生成するために、第１の署名シェアをコーディネータが利用できるようにすることとを含む、方法。

Description

本開示は、デジタル署名のシェア（share）を生成する方法に関する。特に、本方法は、外部データがデジタル署名のシェア内に埋め込まれることを可能にする。

一般に、共有シークレットは、参加者のグループの間で分散されるデータ項目を共有するために使用され得る。各参加者は、シークレットの異なるシェアを有する。通常、シークレットは、特定の数（「しきい値」と呼ばれる）の参加者が、例えば、シークレットを計算するために一緒に組み合わされるように、それぞれのシェアを利用できるようにしたときにのみ、再構築されることができる。

公開鍵暗号法は、鍵のペア、すなわち、秘密鍵の所有者のみに知られている秘密鍵と、対応する秘密鍵に基づいて生成され、秘密鍵のセキュリティを損なうことなく配布され得る公開鍵とを使用する暗号システムの一種である。

公開鍵暗号法は、送信者が受信者の公開鍵（すなわち、受信者のみに知られている秘密鍵に対応する公開鍵）を使用してメッセージを暗号化することを可能にする。そのため、暗号化されたメッセージは、受信者の秘密鍵を使用してのみ復号することができる。

同様に、送信者は、例えば、メッセージが送信者によって送信されていることを証明するために、および／または、送信者がメッセージに同意することを示すために、自身の秘密鍵を使用してメッセージに署名することができる。署名者（すなわち、署名を生成する当事者）は、自身の秘密鍵を使用して、メッセージに基づいてデジタル署名を作成する。メッセージに基づいてデジタル署名を作成することは、メッセージおよび秘密鍵の両方に基づいて署名を生成する関数に、メッセージおよび秘密鍵を供給することを意味する。署名は、メッセージに追加される（例えば、タグ付けされる）か、または他の方法でメッセージに関連付けられる。署名者の対応する公開鍵を有する者であれば、同じメッセージおよびメッセージ上のデジタル署名を使用して、署名が有効に作成されたかどうか、すなわち、署名が実際に署名者の秘密鍵を使用して作成されたかどうかを検証することができる。デジタル署名は、メッセージの真正性を保証するだけでなく、メッセージの完全性および否認防止も保証する。すなわち、デジタル署名は、メッセージが署名で署名されてから変更されていないこと、および署名の作成者が署名を作成したことを将来否定することができないことを証明するために使用することができる。

デジタル署名方式は、典型的に、３つの手順、すなわちアルゴリズムを含む。鍵生成アルゴリズムは、ランダムな秘密鍵および対応する公開鍵を生成するために使用される。署名アルゴリズムは、メッセージと秘密鍵とに基づいて署名を生成するために使用される。検証アルゴリズムは、公開鍵およびメッセージが与えられた場合に、署名が、対応する秘密鍵を使用して、および、署名アルゴリズムにしたがって生成されたかどうかを検証するために使用される。

共有シークレットの一般的な使用は、秘密鍵－公開鍵ペアの共有秘密鍵としての使用である。すなわち、秘密鍵は、単一の参加者では秘密鍵を入手できないように、参加者のグループの間で分散され得る。したがって、単一の参加者がメッセージの有効な署名を生成することはできない。代わりに、署名が生成されるためには、参加者の一部または全部が一緒に秘密鍵を生成しなければならない。

署名を生成するために参加者が自身の秘密鍵シェアを共有する代わりに、参加者は、しきい値署名方式を使用してもよい。しきい値署名方式では、グループ内のしきい値数の参加者は、秘密鍵を参加者が利用できるようにすることなく、共有秘密鍵の個々のシェアを使用して、メッセージに基づいてデジタル署名を作成することができる。ここで、デジタル署名は、署名されるべきメッセージに基づいて生成される署名である。そのような方式では、署名は、しきい値数の参加者が、メッセージに対する署名を生成することに同意する場合にのみ作成することができる。より少ない数の参加者を使用して署名を生成しようとしても、有効な署名は生成されない。したがって、グループによる有効な署名（すなわち、メッセージおよび共有秘密鍵を使用して生成された署名）は、証明可能に、しきい値数の人が署名を生成することに同意していることを意味する。これはまた、秘密鍵を用いて署名を偽造するためには、任意の敵対者がその秘密鍵のしきい値数のシェアを取得する必要があることを意味する。

上述したように、共有シークレットは、共有秘密鍵であり得、参加者のグループの各々は、共有秘密鍵のそれぞれのシェアを有する。しきい値数の参加者は、共有秘密鍵を実際に生成することなく、共有秘密鍵を使用して有効な署名を一緒に生成し得る。公開鍵は、署名を妥当性確認するために、すなわち、少なくともしきい値数の参加者が署名を生成することに同意したことを検証するために、第三者が利用できるようにされ得る。これらの場合、参加者は、自身が署名の生成に寄与したことを証明することができることが望ましい。

本明細書に開示される一態様によれば、デジタル署名のシェアを生成するコンピュータ実装方法であって、参加者のグループの各参加者は、第１の共有秘密鍵のそれぞれのシェアを有し、方法は、グループの第１の参加者によって実行され、第１のメッセージを取得することと、少なくとも第１の外部データ項目のハッシュに基づいて第１のデータ項目を生成することと、エフェメラル秘密鍵（ephemeral private key）の第１のエフェメラル秘密鍵シェアを生成することであって、第１のエフェメラル秘密鍵シェアは、第１のデータ項目と、各他の参加者によって生成されたそれぞれのデータ項目とに基づいて生成される、ことと、エフェメラル秘密鍵に対応するエフェメラル公開鍵（ephemeral public key）を生成することと、第１のメッセージと、第１のエフェメラル秘密鍵シェアと、第１の共有秘密鍵の第１のシェアと、エフェメラル公開鍵とに基づいて、第１の署名シェア（signature share）を生成することと、少なくともしきい値数のそれぞれの署名シェアに基づいて第１の署名を生成するために、第１の署名シェアをコーディネータが利用できるようにすることとを含む方法が提供される。

本明細書で開示される別の態様によれば、デジタル署名が第１の参加者によって部分的に生成されたことを検証するコンピュータ実装方法であって、方法は、検証当事者によって実行され、第１の署名構成要素（signature component）および第２の署名構成要素を含む第１の署名を取得することと、第１の参加者からの候補の第１の外部データ項目と、それぞれのデータ項目に対応する１つまたは複数のそれぞれの公開鍵とを、他の参加者ごとに１つずつ取得することと、候補の第１の外部データ項目のハッシュに基づいて候補の公開鍵を生成することと、候補の公開鍵と、取得された１つまたは複数の公開鍵とに基づいて、候補のエフェメラル公開鍵を生成することと、候補のエフェメラル公開鍵に基づいて候補の第１の署名構成要素を生成することと、候補の第１の署名構成要素が第１の署名構成要素に対応するかどうかに基づいて、第１の署名が第１の参加者によって部分的に生成されたことを検証することとを含む方法が提供される。

第１の参加者は、メッセージに署名するためのデジタル署名のシェアを生成する。ブロックチェーンの文脈では、メッセージは、トランザクションであり得、例えば、署名は、前のトランザクションの出力をロック解除するためにトランザクションの入力に含まれ得る。一般に、メッセージは、任意の形態のメッセージ、例えば文書であり得、必ずしもブロックチェーンに関連する必要はない。署名シェアは、エフェメラル秘密鍵シェア、例えば、１回使用の秘密鍵のシェアに少なくとも部分的に基づいて生成される。エフェメラル秘密鍵シェアは、外部情報、すなわち「外部データ項目」に少なくとも部分的に基づいて生成される。外部データ項目は、第１の参加者の識別子、例えば、名前、住所、電話番号、国民保険番号、パスポート番号、公開鍵などを含み得、および／またはそれに基づいて生成され得る。いくつかの例では、外部データ項目は、第１の参加者によって生成されたデジタル署名である。第１の参加者は、十分な他の署名シェアとともに完全な署名を生成するために、署名シェアをコーディネータが利用できるようにする。コーディネータは、いくつかの例では、第１の参加者であり得る。

一旦生成されると、署名は、共有秘密鍵に対応する公開鍵を使用して検証することができる。しかしながら、それでは、第１の参加者が署名のシェアを生成したことを第１の参加者が検証当事者に証明することはできない。むしろ、第１の参加者のみが、署名シェアを生成するために使用される外部データ項目を知っているので、第１の参加者は、外部データ項目を明らかにし、検証当事者が署名の少なくとも一部（すなわち、「第１の署名構成要素」）を再構築することを可能にすることができる。すなわち、検証当事者は、外部データ項目に基づいて候補の第１の署名構成要素を生成する。再構築された第１の署名構成要素（すなわち、候補の第１の署名構成要素）が第１の署名構成要素と一致すると、検証当事者は、第１の参加者が実際に署名に寄与したことを確信することができる。

本発明は、外部情報が署名に組み込まれること、すなわち、署名内に埋め込まれることを可能にする。外部情報は、第１の参加者によって提供されない限り、検証当事者には知られない。具体的には、外部情報は、署名を導出するために使用される。例えば、第１の参加者は、第１の参加者のアイデンティティにリンクされた公開鍵を、異なる秘密鍵（すなわち、埋め込まれた公開鍵に対応しない共有秘密鍵）を使用して作成された署名に埋め込み得る。これにより、第１の参加者は、自身が署名のシェアを生成したことを証明することができる。

本開示の実施形態の理解を助け、そのような実施形態がどのように実施され得るかを示すために、単なる例として添付の図面を参照する。
ブロックチェーンを実装するためのシステムの概略ブロック図である。 ブロックチェーンに記録され得るトランザクションのいくつかの例を概略的に示す。 クライアントアプリケーションの概略ブロック図である。 図３Ａのクライアントアプリケーションによって提示され得る例示的なユーザインターフェースの概略モックアップである。 本発明の実施形態を実装するための例示的なシステムの概略ブロック図である。 本発明のいくつかの実施形態による、デジタル署名シェアを生成するための例示的な方法を示すフローチャートである。 本発明のいくつかの実施形態による、当事者がデジタル署名シェアを生成したことを検証するための例示的な方法を示すフローチャートである。 本発明のいくつかの実施形態にしたがって生成された例示的なマークルツリーを示す。

例示的なシステムの概要
図１は、ブロックチェーン１５０を実装するための例示的なシステム１００を示す。システム１００は、典型的にはインターネットなどの広域インターネットワークであるパケット交換ネットワーク１０１で構成され得る。パケット交換ネットワーク１０１は、パケット交換ネットワーク１０１内にピアツーピア（Ｐ２Ｐ）ネットワーク１０６を形成するように構成され得る複数のブロックチェーンノード１０４を含む。図示されていないが、ブロックチェーンノード１０４は、ほぼ完全なグラフとして構成され得る。したがって、各ブロックチェーンノード１０４は、他のブロックチェーンノード１０４に高度に接続される。

各ブロックチェーンノード１０４は、ピアのコンピュータ機器を含み、ノード１０４の異なるものは、異なるピアに属する。各ブロックチェーンノード１０４は、１つまたは複数のプロセッサ、例えば、１つまたは複数の中央処理装置（ＣＰＵ）、アクセラレータプロセッサ、特定用途向けプロセッサおよび／またはフィールドプログラマブルゲートアレイ（ＦＰＧＡ）、ならびに特定用途向け集積回路（ＡＳＩＣ）などの他の機器を含む処理装置を備える。各ノードはまた、メモリ、すなわち、１つまたは複数の非一時的コンピュータ可読媒体の形態のコンピュータ可読ストレージを備える。メモリは、１つまたは複数のメモリ媒体、例えば、ハードディスクなどの磁気媒体、ソリッドステートドライブ（ＳＳＤ）、フラッシュメモリもしくはＥＥＰＲＯＭなどの電子媒体、および／または光ディスクドライブなどの光学媒体を採用する１つまたは複数のメモリユニットを備え得る。

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

各ブロック１５１はまた、ブロック１５１への順番を定義するために、チェーン内の前に作成されたブロック１５１を指し示すブロックポインタ１５５を含む。各トランザクション１５２（コインベーストランザクション以外）は、トランザクションのシーケンスへの順序を定義するために、前のトランザクションへ戻るポインタを含む（注意：トランザクション１５２のシーケンスは分岐することが可能である）。ブロック１５１のチェーンは、チェーン内の最初のブロックであった発生ブロック（Ｇｂ：genesis block）１５３までずっと戻る。チェーン１５０内の早期にある１つまたは複数の元のトランザクション１５２は、先行するトランザクションではなく発生ブロック１５３を指し示していた。

ブロックチェーンノード１０４の各々は、トランザクション１５２を他のブロックチェーンノード１０４にフォワードし、それによってトランザクション１５２をネットワーク１０６全体に伝搬させるように構成される。各ブロックチェーンノード１０４は、ブロック１５１を作成し、同じブロックチェーン１５０のそれぞれのコピーをそれらのそれぞれのメモリに記憶するように構成される。各ブロックチェーンノード１０４はまた、ブロック１５１に組み込まれるのを待っているトランザクション１５２の順序付きセット（またはプール）１５４を維持する。順序付きプール１５４は、「メムプール（mempool）」と呼ばれることが多い。本明細書におけるこの用語は、任意の特定のブロックチェーン、プロトコル、またはモデルに限定することを意図していない。これは、ノード１０４が有効であるとして受け入れたトランザクションの順序付きセットを指し、それに対して、ノード１０４は、同じ出力を使用しようとする他のトランザクションを受け入れないように義務付けられている。

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

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

ビットコインなどの出力ベースのトランザクションプロトコルによれば、個々のユーザまたは組織などの当事者１０３が（手動でまたは当事者によって採用される自動プロセスによって）新しいトランザクション１５２ｊを制定することを望むとき、制定を行う当事者は、新しいトランザクションをそのコンピュータ端末１０２から受信者に送信する。制定を行う当事者または受信者は、最終的に、このトランザクションをネットワーク１０６のブロックチェーンノード１０４の１つまたは複数（これは、現在では、典型的にはサーバまたはデータセンタであるが、原則として他のユーザ端末であってもよい）に送信する。新しいトランザクション１５２ｊを制定する当事者１０３がトランザクションをブロックチェーンノード１０４の１つまたは複数に直接送信し、いくつかの例では、受信者に送信しないことも除外されない。トランザクションを受信するブロックチェーンノード１０４は、ブロックチェーンノード１０４の各々で適用されるブロックチェーンノードプロトコルにしたがって、トランザクションが有効であるかどうかをチェックする。ブロックチェーンノードプロトコルは、典型的には、新しいトランザクション１５２ｊ内の暗号署名が、トランザクション１５２の順序付きシーケンス内で前のトランザクション１５２ｉに依存する予想される署名と一致することをチェックするようにブロックチェーンノード１０４に求める。そのような出力ベースのトランザクションプロトコルでは、これは、新しいトランザクション１５２ｊの入力に含まれる当事者１０３の暗号署名または他の認可が、新しいトランザクションが割り当てる先行するトランザクション１５２ｉの出力において定義される条件と一致することをチェックすることを含み得、この条件は、典型的には、新しいトランザクション１５２ｊの入力における暗号署名または他の認可が、新しいトランザクションの入力がリンクされている前のトランザクション１５２ｉの出力をロック解除することを少なくともチェックすることを含む。条件は、先行するトランザクション１５２ｉの出力に含まれるスクリプトによって少なくとも部分的に定義され得る。代替的に、単にブロックチェーンノードプロトコルのみによって固定されてもよく、またはこれらの組合せによるものであってもよい。いずれにしても、新しいトランザクション１５２ｊが有効である場合、ブロックチェーンノード１０４は、それをブロックチェーンネットワーク１０６内の１つまたは複数の他のブロックチェーンノード１０４にフォワードする。これらの他のブロックチェーンノード１０４は、同じブロックチェーンノードプロトコルにしたがって同じテストを適用し、そして、新しいトランザクション１５２ｊを１つまたは複数のさらなるノード１０４にフォワードし、以下同様である。このようにして、新しいトランザクションはブロックチェーンノード１０４のネットワーク全体に伝搬される。

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

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

最初にパズルを解いたブロックチェーンノード１０４は、これをネットワーク１０６に公表し、後にネットワーク内の他のブロックチェーンノード１０４によって容易にチェックすることができるその解を証拠として提供する（ハッシュに対する解が与えられると、ハッシュの出力が条件を満たすことをチェックすることは簡単である）。この最初のブロックチェーンノード１０４は、ブロックを、このブロックを受け入れる他のノードのしきい値コンセンサスに伝搬し、プロトコルルールを実施する。次いで、トランザクションの順序付きセット１５４は、ブロックチェーンノード１０４の各々によってブロックチェーン１５０内に新しいブロック１５１として記録されるようになる。ブロックポインタ１５５はまた、チェーン内の前に作成されたブロック１５１ｎ－１を指し示す新しいブロック１５１ｎに割り当てられる。プルーフオブワークの解を作成するために必要とされる、例えばハッシュの形態の、かなりの量の労力は、ブロックチェーンプロトコルのルールに従うという最初のノード１０４の意図を示す。そのようなルールは、別名二重支出としても知られている、前に妥当性確認されたトランザクションと同じ出力の割当てを行う場合、トランザクションを有効として受け入れないことを含む。ブロック１５１は、一旦作成されると、ブロックチェーンネットワーク１０６内のブロックチェーンノード１０４の各々において認識および維持されるので、修正することができない。ブロックポインタ１５５はまた、ブロック１５１に順番を付与する。トランザクション１５２は、ネットワーク１０６内の各ブロックチェーンノード１０４において順序付きブロックに記録されるので、これは、トランザクションの不変の公開台帳を提供する。

任意の所与の時間にパズルを解こうと競い合う異なるブロックチェーンノード１０４は、それらがいつ解を探索し始めたかまたはトランザクションが受信された順序に応じて、任意の所与の時間に、まだ公開されていないトランザクションのプール１５４の異なるスナップショットに基づいてそれを行っていてもよいことに留意されたい。誰がそれぞれのパズルを最初に解いても、どのトランザクション１５２が次の新しいブロック１５１ｎにどの順序で含まれるかを定義し、公開されていないトランザクションの現在のプール１５４が更新される。次いで、ブロックチェーンノード１０４は、新たに定義された、公開されていないトランザクションの順序付きプール１５４からブロックを作成しようと競い合い続け、以下同様である。２つのブロックチェーンノード１０４が互いに非常に短い時間内にパズルを解いて、ブロックチェーンの相反する見解がノード１０４間で伝搬される場合に発生し得る任意の「フォーク」を解決するためのプロトコルも存在する。要するに、フォークのどちらのプロングが最も長く成長しても、確定的なブロックチェーン１５０となる。同じトランザクションが両方のフォークに現れるので、これがネットワークのユーザまたはエージェントに影響を与えないことに留意されたい。

ビットコインブロックチェーン（およびほとんどの他のブロックチェーン）によれば、新しいブロック１０４の構築に成功したノードには、（あるエージェントまたはユーザから別のエージェントまたはユーザにある額のデジタル資産を転送するエージェント間またはユーザ間のトランザクションとは対照的に）追加の定義された量のデジタル資産を分配する新しい特別な種類のトランザクションにおいて、受け入れられた追加の額のデジタル資産を新たに割り当てる能力が与えられる。この特別なタイプのトランザクションは、通常、「コインベーストランザクション」と呼ばれるが、「開始トランザクション（initiation transaction）」または「生成トランザクジョン（generation transaction）」と呼ばれることもある。これは典型的に、新しいブロック１５１ｎの最初のトランザクションを形成する。プルーフオブワークは、新しいブロックを構築するノードが、この特別なトランザクションが後に償還されることを可能にするプロトコルルールに従うという意図を示す。ブロックチェーンプロトコルルールは、この特別なトランザクションが償還され得る前に、満期期間、例えば１００個のブロックを必要とし得る。多くの場合、通常の（非生成）トランザクション１５２はまた、そのトランザクションが公開されたブロック１５１ｎを作成したブロックチェーンノード１０４にさらに報酬を与えるために、その出力のうちの１つにおいて追加のトランザクション手数料を指定する。この手数料は通常「トランザクション手数料」と呼ばれ、以下に説明する。

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

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

消費ユーザの役割を果たす複数の当事者１０３の各々のコンピュータ機器１０２もネットワーク１０１に接続されている。これらのユーザは、ブロックチェーンネットワーク１０６と対話し得るが、トランザクションの妥当性確認にもブロックの構築にも参加しない。これらのユーザまたはエージェント１０３のうちのいくつかは、トランザクションの送信者および受信者として動作し得る。他のユーザは、必ずしも送信者または受信者として動作することなくブロックチェーン１５０と対話し得る。例えば、いくつかの当事者は、（例えば、ブロックチェーンノード１０４からブロックチェーンのコピーを取得した）ブロックチェーン１５０のコピーを記憶するストレージエンティティとして動作し得る。

当事者１０３のうちのいくつかまたはすべては、異なるネットワーク、例えば、ブロックチェーンネットワーク１０６の上にオーバーレイされたネットワークの一部として接続され得る。ブロックチェーンネットワークのユーザ（「クライアント」と呼ばれことが多い）は、ブロックチェーンネットワーク１０６を含むシステムの一部であるといえるが、これらのユーザは、ブロックチェーンノードに求められる役割を果たさないので、ブロックチェーンノード１０４ではない。代わりに、各当事者１０３はブロックチェーンネットワーク１０６と対話してもよく、ブロックチェーンノード１０６に接続する（すなわち通信する）ことでブロックチェーン１５０を利用し得る。２つの当事者１０３およびそれらのそれぞれの機器１０２、すなわち、第１の当事者１０３ａおよびそのそれぞれのコンピュータ機器１０２ａ、ならびに第２の当事者１０３ｂおよびそのそれぞれのコンピュータ機器１０２ｂは、例示の目的で示されている。そのような当事者１０３およびそれらのそれぞれのコンピュータ機器１０２ははるかに多く存在し、システム１００に参加し得るが、便宜上、それらは図示されていないことが理解されよう。各当事者１０３は、個人または組織であり得る。純粋に例示として、第１の当事者１０３ａは、本明細書ではアリスと呼ばれ、第２の当事者１０３ｂはボブと呼ばれるが、これは限定的なものではなく、本明細書におけるアリスまたはボブへのいかなる言及も、それぞれ「第１の当事者」および「第２の当事者」と置き換えられ得ることが理解されよう。

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

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

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

様々なクライアント機能が、所与のクライアントアプリケーション１０５に統合されるものとして説明され得るが、必ずしもこれに限定されず、代わりに、本明細書で説明される任意のクライアント機能は、例えば、ＡＰＩを介してインターフェースする、または一方が他方へのプラグインである２つ以上の別個のアプリケーション一式において実装され得ることに留意されたい。より一般的には、クライアント機能は、アプリケーション層もしくはオペレーティングシステムなどの下位層、またはこれらの任意の組合せにおいて実装され得る。以下では、クライアントアプリケーション１０５に関して説明するが、これに限定されないことが理解されよう。

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

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

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

所与のブロックチェーンノード１０４において維持される保留中のトランザクションの順序付きプール１５４に承認されると、そのブロックチェーンノード１０４は、新しいトランザクション１５２を含むそれぞれのプール１５４の最新バージョンに対してプルーフオブワークパズルを解こうと競い始める（他のブロックチェーンノード１０４が、トランザクションの異なるプール１５４に基づいてパズルを解こうと試みている可能性があるが、どのノードでも最初に解いたものが、最新のブロック１５１に含まれるトランザクションのセットを定義することを想起されたい。最終的に、ブロックチェーンノード１０４は、アリスのトランザクション１５２ｊを含む順序付きプール１５４の一部についてパズルを解くことになる。）新しいトランザクション１５２ｊを含むプール１５４に対してプルーフオブワークが行われると、それは普遍的にブロックチェーン１５０内のブロック１５１のうちの１つの一部となる。各トランザクション１５２は、先のトランザクションへ戻るポインタを含むので、トランザクションの順序も不変的に記録される。

異なるブロックチェーンノード１０４は、最初、所与のトランザクションの異なるインスタンスを受信し得るので、１つのインスタンスが新しいブロック１５１において公開される（この時点で、公開されたインスタンスが唯一の有効なインスタンスであることにすべてのブロックチェーンノード１０４が同意している）までは、どのインスタンスが「有効」であるかについて相反する見解を有する。ブロックチェーンノード１０４が１つのインスタンスを有効として受け入れ、次いで、別のインスタンスがブロックチェーン１５０に記録されていることを発見した場合、そのブロックチェーンノード１０４は、これを受け入れなければならず、最初に受け入れたインスタンス（すなわち、ブロック１５１で公開されていないもの）を破棄する（すなわち、無効として扱う）。

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

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

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

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

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

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

ロックスクリプト（通称scriptPubKey）は、ノードプロトコルによって認識されるド主固有言語で書かれたコードの一部分である。そのような言語の特定の例は、ブロックチェーンネットワークによって使用される「スクリプト（Script）」（大文字Ｓ）と呼ばれる。ロックスクリプトは、トランザクション出力２０３を使用するためにどの情報が必要とされるか、例えばアリスの署名の必要性、を指定する。ロック解除スクリプトはトランザクションの出力に現れる。ロック解除スクリプト（通称scriptSig）は、ロックスクリプト基準を満たすのに必要な情報を提供するド主固有言語で書かれたコードの一部分である。例えば、それはボブの署名を含み得る。ロック解除スクリプトは、トランザクションの入力２０２に現れる。

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

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

公開－秘密暗号法による認証の詳細は、当業者によく知られている。基本的に、アリスが自身の秘密鍵を使用してメッセージに署名した場合、アリスの公開鍵および平文のメッセージが与えられると、ノード１０４などの別のエンティティは、メッセージがアリスによって署名されたものに違いないことを認証することができる。署名は、典型的には、メッセージをハッシュし、ハッシュに署名し、これを署名としてメッセージにタグ付けすることを含み、これにより、公開鍵の任意の保持者が署名を認証することができる。したがって、データの特定の部分またはトランザクションの一部などに署名することへの本明細書におけるいかなる参照も、実施形態では、データのその部分またはトランザクションの一部のハッシュに署名することを意味し得ることに留意されたい。

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

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

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

実際には、アリスはまた、通常、アリスのトランザクション１０４をブロック１５１に成功裏に含めるビットコインノード１０４に対する手数料を含める必要がある。アリスがそのような手数料を含めない場合、Ｔｘ₀は、ブロックチェーンノード１０４によって拒否され得、したがって、技術的に有効であっても、伝搬されず、ブロックチェーン１５０に含まれない可能性がある（ノードプロトコルは、ブロックチェーンノード１０４が望まない場合にトランザクション１５２を受け入れることを強制しない）。いくつかのプロトコルでは、トランザクション手数料は、それ自体の別個の出力２０３を必要としない（すなわち、別個のＵＴＸＯを必要としない）。代わりに、所与のトランザクション１５２の入力（複数可）２０２によって指し示される総額と出力（複数可）２０３で指定されている総額との間の任意の差が、トランザクションを公開するブロックチェーンノード１０４に自動的に与えられる。例えば、ＵＴＸＯ₀へのポインタがＴｘ₁への唯一の入力であり、Ｔｘ₁は唯一の出力ＵＴＸＯ₁を有するとする。ＵＴＸＯ₀において指定されたデジタル資産の額がＵＴＸＯ₁において指定された額よりも大きい場合、その差分は、ＵＴＸＯ₁を含むブロックを生成するためのプルーフオブワーク競争に勝つノード１０４によって割り当てられ得る。しかしながら、代替的にまたは追加的に、トランザクション手数料がトランザクション１５２のＵＴＸＯ２０３のうちのそれ自体の１つにおいて明示的に指定され得ることは必ずしも除外されない。

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

スクリプトコードは、多くの場合、概略的に（すなわち、正確な言語を使用せずに）表されることに留意されたい。例えば、特定の機能を表すためにオペレーションコード（オペコード）が使用され得る。「OP_...」は、スクリプト言語の特定のオペコードを指す。例として、ＯＰ＿ＲＥＴＵＲＮは、ロックスクリプトの最初にＯＰ＿ＦＡＬＳＥが先行するときに、トランザクション内にデータを記憶することができ、それによってデータをブロックチェーン１５０内に不変的に記録することができる、トランザクションの使用不可能な出力を作成するスクリプト言語のオペコードである。例えば、データは、ブロックチェーンに記憶することが望まれる文書を含み得る。

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

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

図１に示すように、アリスおよびボブのコンピュータ機器１０２ａ、１２０ｂの各々上のクライアントアプリケーションは、それぞれ、追加の通信機能を含み得る。この追加の機能により、（いずれかの当事者または第三者の扇動で）アリス１０３ａは、ボブ１０３ｂと別個のサイドチャネル１０７を確立することができる。サイドチャネル１０７は、ブロックチェーンネットワークとは別でのデータの交換を可能にする。そこのような通信は、「オフチェーン」通信と呼ばれることがある。例えば、これは、当事者の一方がトランザクションをネットワーク１０６にブロードキャストすることを選択するまで、トランザクションが（まだ）ブロックチェーンネットワーク１０６に登録されることなく、またはチェーン１５０上に進むことなく、アリスとボブとの間でトランザクション１５２を交換するために使用され得る。このようにトランザクションを共有することは、「トランザクションテンプレート」の共有と呼ばれることがある。トランザクションテンプレートは、完全なトランザクションを形成するために必要とされる１つまたは複数の入力および／または出力を欠いていてもよい。代替的にまたは追加的に、サイドチャネル１０７は、鍵、交渉された額または条件、データコンテンツなどの任意の他のトランザクション関連データを交換するために使用され得る。

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

クライアントソフトウェア
図３Ａは、本開示の方式の実施形態を実装するためのクライアントアプリケーション１０５の例示的な実装を示す。クライアントアプリケーション１０５は、トランザクションエンジン４０１およびユーザインターフェース（ＵＩ）層４０２を含む。トランザクションエンジン４０１は、上述した方式にしたがって、および、さらに詳細に簡潔に説明されるように、例えば、トランザクション１５２を定式化し、サイドチャネル３０１上でトランザクションおよび／または他のデータを受信および／または送信し、および／またはトランザクションを１つまたは複数のノード１０４に送信してブロックチェーンネットワーク１０６全般に伝搬させるために、クライアント１０５の基本的なトランザクション関連機能を実装するように構成される。

ＵＩ層４０２は、機器１０２のユーザ出力手段を介してそれぞれのユーザ１０３に情報を出力すること、および機器１０２のユーザ入力手段を介してそれぞれのユーザ１０３から入力を受信することを含む、それぞれのユーザのコンピュータ機器１０２のユーザ入力／出力（Ｉ／Ｏ）手段を介してユーザインターフェースをレンダリングするように構成される。例えば、ユーザ出力手段は、視覚出力を提供するための１つまたは複数のディスプレイスクリーン（タッチスクリーンまたは非タッチスクリーン）、オーディオ出力を提供するための１つまたは複数のスピーカ、および／または触覚出力を提供するための１つまたは複数の触覚出力デバイスなどを含み得る。ユーザ入力手段は、例えば、１つまたは複数のタッチスクリーン（出力手段のために使用されるものと同一または異なる）の入力アレイ、マウス、トラックパッド、またはトラックボールなどの１つまたは複数のカーソルベースのデバイス、発話または音声入力を受信するための１つまたは複数のマイクロホンおよび発話または音声認識アルゴリズム、手動または身体ジェスチャの形態で入力を受信するための１つまたは複数のジェスチャベースの入力デバイス、あるいは１つまたは複数の機械式ボタン、スイッチ、またはジョイスティックなどを含み得る。

本明細書の様々な機能は、同じクライアントアプリケーション１０５に統合されるものとして説明され得るが、これは、必ずしも限定的ではなく、代わりに、それらは、２つ以上の別個のアプリケーション一式で実装され得、例えば、一方が他方へのプラグインであるか、またはＡＰＩ（アプリケーションプログラミングインターフェース）を介してインターフェースしていることに留意されたい。例えば、トランザクションエンジン４０１の機能が、ＵＩ層４０２とは別個のアプリケーションにおいて実装されてもよいし、トランザクションエンジン４０１などの所与のモジュールの機能が、２つ以上のアプリケーション間で分割されてもよい。説明された機能のうちのいくつかまたはすべてが、例えばオペレーティングシステム層で実装され得ることも除外されない。本明細書のどこでも単一のまたは所与のアプリケーション１０５などを参照する場合、これは単なる例であり、より一般的には、説明される機能は任意の形態のソフトウェアで実装され得ることが理解されよう。

図３Ｂは、アリスの機器１０２ａ上のクライアントアプリケーション１０５ａのＵＩ層４０２によってレンダリングされ得るユーザインターフェース（ＵＩ）５００の例のモックアップを与える。同様のＵＩが、クライアント１０５ｂによってボブの機器１０２ｂ上に、または任意の他の当事者の機器上にレンダリングされ得ることが理解されよう。

例示として、図３Ｂは、アリスの視点からのＵＩ５００を示す。ＵＩ５００は、ユーザ出力手段を介して別個のＵＩ要素としてレンダリングされる１つまたは複数のＵＩ要素５０１、５０２、５０２を含み得る。

例えば、ＵＩ要素は、異なるオンスクリーンボタン、またはメニュー内の異なるオプションなどであり得る１つまたは複数のユーザ選択可能要素５０１を含み得る。ユーザ入力手段は、ユーザ１０３（この場合、アリス１０３ａ）が、スクリーン上のＵＩ要素をクリックもしくはタッチすることまたは所望のオプションの名前を言うことなどによって、オプションのうちの１つを選択または他の方法で動作させることを可能にするように構成される（注意：本明細書で使用される「手動」という用語は、自動との対比を意味し、必ずしも１つまたは複数の手の使用に限定されない）。オプションにより、ユーザ（アリス）は、トランザクション内に埋め込まれる署名を生成することができる。

代替的にまたは追加的に、ＵＩ要素は、１つまたは複数のデータ入力フィールド５０２を含み得、それを通して、ユーザは、署名内に埋め込まれるデータを入力することができる。これらのデータ入力フィールドは、ユーザ出力手段、例えばオンスクリーンを介してレンダリングされ、データは、ユーザ入力手段、例えば、キーボードまたはタッチスクリーンを通してフィールドに入力され得る。代替的に、データは、例えば、音声認識に基づいて、口頭で受信され得る。

代替的にまたは追加的に、ＵＩ要素は、ユーザに情報を出力するために出力される１つまたは複数の情報要素５０３を含むことができる。例えば、これ／これらは、スクリーン上にまたは音声でレンダリングされ得る。

様々なＵＩ要素をレンダリングし、オプションを選択し、データを入力する特定の手段は重要ではないことが理解されよう。これらのＵＩ要素の機能については、以下でより詳細に説明する。図３に示されるＵＩ５００は、単に図式化されたモックアップであり、実際には、簡潔にするために図示されていない１つまたは複数のさらなるＵＩ要素を含み得ることも理解されよう。

暗号プレリミナリ（CRYPTOGRAPHY RELIMINARIES）

ＥＣＤＳＡ－楕円曲線群

は、有限体

上の巡回楕円曲線群であり、ｐは素数である。Ｅの要素の数はｎであり、ｎは素数である。Ｇ∈Ｅは、楕円曲線群の生成点であり、以下を意味する：

群演算

は、標準楕円曲線点加算であり、ｉ・Ｇは、Ｇに対する群演算のｉ回の反復を表す：

以下において、文脈上他の意味に解すべき場合を除き、整数に対するすべての演算はモジュロｎである。

楕円曲線デジタル署名アルゴリズム
鍵生成は以下のように行われる：
１）署名用の秘密鍵ｊ∈｛１，…，ｎ－１｝を選択する
２）公開鍵は、Ｙ＝ｊ・Ｇであり、Ｇは、生成点である。

署名アルゴリズムは、秘密鍵ｊメッセージおよびエフェメラル鍵ｋを取り、署名を生成する：
３）ランダムなｋ∈｛１，…，ｎ－１｝（エフェメラル鍵）を選択する
４）Ｒ＝（ｒ_x，ｒ_y）＝ｋ・Ｇ－ＥＣ点を計算する
５）ｒ＝ｒ_x ｍｏｄ ｎを計算する
６）ｒ＝０である場合、ステップ３に進む
７）署名ｓ＝ｋ^-1（ｅ＋ｊｒ）を生成する。ここで、ｅ＝ｈａｓｈ（ｍ）である
８）ｓ＝０である場合、ステップ３に進む
９）［ｒ，ｓ］をメッセージｍの署名として出力する

次いで、検証アルゴリズムは、署名およびメッセージを取り、署名者の公開鍵を使用してｒを再構築し、署名で与えられるｒ値を検証する。
１）ｅ＝ｈａｓｈ（ｍ）を計算する
２）ｋ₁＝ｅｓ^-1 ｍｏｄ ｎおよびｋ₂＝ｒｓ^-1 ｍｏｄ ｎを計算する
３）Ｑ＝（ｑ_x，ｑ_y）＝ｋ₁・Ｇ＋ｋ₂・Ｙを計算する
４）

である場合、署名は有効である
そうでなければ無効である。

署名には以下の表記が使用される：

ここで、［ｒ_Y，ｓ_Y］は、公開鍵Ｙを使用して検証されたときに、有効な署名である。

共同検証可能ランダム秘密分散（ＪＶＲＳＳ）方式
Ｎ人の参加者が、この方式の参加者のうちの少なくとも（ｉ＋１）によってのみ再生成することができる共同シークレットを作成したいと望むと仮定する。共有シークレットを作成するために、以下のステップが行われる：
１）参加者は、各参加者の一意のラベルｉに合意する。各参加者ｉは、（ｔ＋１）個の乱数

を生成し、ここで、∈_Rは、集合

のランダムに生成された要素を意味し、

は、集合｛１，…，ｎ－１｝の表記である。次いで、各参加者は、ｉ＝１，…，Ｎに対して、次数ｔのシークレット多項式（secret polynomial）

を有する。なお、これ以降ｍｏｄ ｎの表記は省略され、整数に対するすべての算術演算はモジュロｎで行われると仮定する。
２）各参加者ｉは、例えば、参加者ｊとのセキュアな通信チャネルだけを使用して、値ｆ_i（ｊ）を参加者ｊに送信する。
３）各参加者ｉは、共有シークレット多項式の自身のプライベートなシークレットシェアを以下のように計算する：

共有シークレットシェアは、形式（ｉ，ａ_i）を有する点であり、ここで、ｉは、方式における参加者ラベルである。ａのシークレットシェアを生成するためのこの方法は、ステップ１～３に説明されるように、本明細書では、参加者ｉについて、ａ_i＝ＪＶＲＳＳ（ｉ）と表記される。「ＪＶＲＳＳ」は、典型的に、「Joint verification random secret sharing」の略であり、ステップ４および５も含むことに留意されたい。しかしながら、本明細書を通して、ＪＶＲＳＳは、少なくともステップ１～３を実行することを意味するものと解釈され、ステップ４および５は、オプションのステップである。

参加者が、共有多項式を生成しているので、参加者はそれぞれ、他の参加者がすべての参加者に正しい情報を共有したこと、およびすべての参加者が同じ共有多項式を有することを検証することができる。これは次のように行われる。
４）各参加者ｉは、ｋ＝０，…，ｔに対して、難読化された係数ａ_ik・Ｇをすべての参加者にブロードキャストする
５）各参加者ｉは、ｆ_j（ｉ）・Ｇを計算し、以下を検証することによって、各参加者ｊが多項式点ｆ_j（ｉ）を正しく計算したことをチェックする：

この式が各多項式に対して成立することをすべての参加者が確認すると、グループは、それらがすべて同じ共有多項式を作成したことを集合的に確信することができる。

共有シークレットの再構成
参加者が、共有多項式のゼロ次である共有シークレットａを再構築したいと望むと仮定する。

の形態のこの多項式上の（ｔ＋１）個の点が与えられると、共有シークレットａを見つけるために、以下が計算され、

これは、「ラグランジュ補間」として知られる一般式から導出される。

公開鍵計算
ＪＶＲＳＳのステップ４で共有されたｊ＝１，…，Ｎに対して、Ｎ個のゼロ次のプライベート多項式係数の公開鍵ａ_i0・Ｇが与えられると、各参加者は、共有シークレットａに対応する

を使用して、共有公開鍵Ｐを計算する。

共有シークレットの加算
例えば、いずれのエンティティも個々のシークレットを知ることなく、Ｎ人の参加者のグループの間で共有される２つの共有シークレットの加算を計算するために、各シークレット多項式が次数ｔを有する場合、以下のステップが行われる：
１）第１の共有シークレットａを生成する。ここで、参加者ｉのシェアは、しきい値が（ｔ＋１）のｉ＝１，…，Ｎに対して、ａ_i＝ＪＶＲＳＳ（ｉ）で与えられる。
２）第２の共有シークレットｂを生成する。ここで、参加者ｉのシェアは、ｂ_i＝ＪＶＲＳＳ（ｉ）で与えられ、しきい値は（ｔ＋１）である。
３）各参加者ｉは、自身の加法的シェア（additive share）を計算する：

４）すべての参加者は、自身の加法的シェアν_iを他のすべての参加者にブロードキャストする。
５）各参加者は、シェアν_iのうちの少なくとも（ｔ＋１）個にわたって補間して、以下を計算する：

共有シークレットの加算のためのこの方法は、参加者ｉについて、ＡＤＤＳＳ（ｉ）と表記され、この結果、各参加者ｉは、ν＝（ａ＋ｂ）を知ることとなる。

共有シークレットの積
Ｎ人の参加者のグループ間で共有される２つの共有シークレットの積を計算するために、各シークレット多項式が次数ｔを有する場合、グループは以下のステップを行う：
１）第１の共有シークレットａを生成する。ここで、参加者ｉのシェアは、ｉ＝１，…，Ｎに対して、ａ_i＝ＪＶＲＳＳ（ｉ）で与えられる。共有シークレット多項式は次数ｔを有し、これは、それを再作成するために（ｔ＋１）人の参加者が必要とされることを意味する。
２）第２の共有シークレットｂを生成する。ここで、参加者ｉのシェアは、ｂ_i＝ＪＶＲＳＳ（ｉ）で与えられ、共有シークレット多項式は、この場合も次数ｔを有する。
３）各参加者は、以下を使用して、自身の乗法的シェア（multiplicative share）μ_iを計算する：

４）すべての参加者は、自身の乗法的シェアμ_iをすべての他の参加者にブロードキャストする。
５）各参加者は、０においてシェアμ_iのうちの少なくとも（２ｔ＋１）個にわたって補間して、以下を計算する：

２つの共有シークレットの積を計算するためのこの方法は、本明細書では、参加者ｉについて、μ＝ａｂ＝ＰＲＯＳＳ（ｉ）と表記される。

共有シークレットの逆数（inverse）
共有シークレットａの逆数を計算するために、以下のステップが行われる：
１）すべての参加者は、共有シークレットの積ＰＲＯＳＳ（ｉ）を計算し、その結果は、μ＝ａｂ ｍｏｄ ｎである。
２）各参加者は、μのモジュラ逆数を計算し、その結果、以下となる：

３）各参加者ｉは、以下を計算することによって、自身の逆数シークレットシェア（inverse secret share）を計算する。

共有シークレットの逆数を計算するためのこの方法は、参加者ｉについて、以下のように表記される：

共有秘密鍵の生成および検証
Ｎ≧２ｔ＋１人の参加者の間の共有秘密鍵ａを計算するために、そのうちのｔ＋１人が署名を作成することが求められる場合、参加者は、上述したように公開鍵計算およびしきい値ｔ＋１を用いてＪＶＲＳＳを実行する。その結果、すべての参加者ｉ＝１，…，Ｎが秘密鍵シェアａ_iと、対応する共有公開鍵Ｐ＝（ａ・Ｇ）とを有する。

エフェメラル鍵シェアの生成
署名において必要とされるような、エフェメラル鍵シェアおよび対応するｒを生成するために、しきい値（ｔ＋１）の共有秘密鍵ａを有するサイズＮのグループは、以下のステップを実行する：
１）共有シークレットの逆数シェア（inverse share）

を生成する。ここで、それを再作成するためには（ｔ＋１）個のシェアが必要とされる。２）各参加者は、以下を計算する。

３）ｋ_iの検証で共有された難読化された係数を使用して、以下を計算する。

４）各参加者ｉは、以下を記憶する。

非最適署名生成
少なくとも２ｔ＋１人の参加者がメッセージに対する署名を作成したいと思っており、参加者のうちの１人がこれを調整することを選択すると仮定する。共有秘密鍵を有するグループによる署名を作成するために、以下のステップが行われる。
１）コーディネータは、少なくとも１つの２ｔ＋１人の参加者に、メッセージに対する署名を要求する。
２）各参加者ｉは、前のセクションで計算されたエフェメラル鍵

を復元する。すべてのユーザは、同じエフェメラル鍵に対応するシェアを使用しなければならない。
３）各参加者は、メッセージダイジェストｅ＝ＳＨＡ－２５６（ＳＨＡ－２５６（ｍｅｓｓａｇｅ））を計算する。
４）各参加者ｉは、自身の署名シェアｓ_ｉを計算する：

ここで、ａ_iは、各参加者の秘密鍵シェアである。
５）各参加者は、自身の署名シェア（ｒ，ｓ_i）をコーディネータに送信する。
６）コーディネータは、２ｔ＋１個の署名シェアを受信すると、

を計算し、この署名を（ｒ，ｓ）として出力する。
７）コーディネータは、標準ＥＣＤＳＡ検証を使用して署名を検証する。これが失敗した場合、シェアのうちの少なくとも１つが誤っているはずであり、署名生成アルゴリズムを再度実行する必要がある。

ディフィーヘルマン（ＤＨ）鍵交換
２つの当事者は、以下の方法で対称シークレット鍵を作成することによって、セキュアな通信チャネルを確立し得る。アリスとボブが共有シークレット鍵（shared secret key）を作成したいと望み、アリスが、公開鍵ＰＫ_A＝ｓｋ_A・Ｇに対応する秘密鍵ｓｋ_A）を知っており、ボブが、ボブの公開鍵ＰＫ_B＝ｓｋ_B・Ｇに対応する秘密鍵ｓｋ_Bを知っていると仮定する。

共有シークレット鍵を見つけるために、以下のステップを行う。
１．アリスは、ディフィーヘルマン鍵ｓｋ_AB＝ｓｋ_A・ＰＫ_Bを計算する。
２．ボブは、ディフィーヘルマン鍵ｓｋ_AB＝ｓｋ_B・ＰＫ_Aを計算する。

共有シークレット鍵を確立するための別の方法は、国際公開第２０１７／１４５０１６号に記載されており、この方法では、事前合意されたメッセージがＤＨ鍵に追加され、新しい鍵が作成される。このメッセージは、送信される新しい通信ごとに変更することができ、決定論的鍵のセットを作成する。例えば、メッセージは、ｍ＝ｈａｓｈ（ｄａｔｅ||ｔｉｍｅ）であり得る。次いで、アリスは、メッセージを使用して秘密鍵ｓｋ_A1＝ ｓｋ_A＋ｈａｓｈ（ｄａｔｅ||ｔｉｍｅ）を生成し、同様に、ボブは、秘密鍵ｓｋ_B1＝ｓｋ_B＋ｈａｓｈ（ｄａｔｅ||ｔｉｍｅ）を生成することができる。そのため、アリスとボブの両方が、共有秘密鍵ｓｋ_AB1＝ｓｋ_A1・ＰＫ_B1＝ｓｋ_B1・ＰＫ_A1を生成することができる。

ＨＤウォレット
階層的決定論的ウォレットは、ビットコイン改善提案３２（ＢＩＰ３２：Bitcoin Improvement Proposal 32）ウォレットがその特定のタイプであり、多くの鍵が単一の入力から導出され得る決定論的ウォレットである。入力は、シードと呼ばれる何らかのランダムエントロピーであり、そこからマスタ鍵が導出される。次いで、マスタ鍵は、図２に示されるように、複数の子鍵を導出するために使用される。

ＢＩＰ３２では、マスタ秘密鍵は、シードのＨＭＡＣ－ＳＨＡ５１２の結果の左の３２バイトであり、または明示的に、それは、

であり、チェーンコードは、

であり、すべての子鍵はこれらから導出することができ、ここで、

は、ＳＨＡ５１２ハッシュ関数を使用するＨＭＡＣである。上記の式において、ｏｐａｄは、ブロックサイズの外側パディングであり、ｉｐａｄは、ブロックサイズの内部パディングである。

ＨＭＡＣは、２つの入力、すなわち、ｃおよびＫを必要とする。簡潔にするために、かつユーザが単一のシードを覚えるまたは記憶することのみを要求されるように、ＢＩＰ３２プロトコルは、第１の入力を文字列「Bitcoin Seed」として設定、すなわち、ｃ＝‘Bitcoin Seed’とする。これは、ＨＤウォレットを生成するための１つの例示的プロトコルであり、異なるプロトコルは、異なる入力、例えば、２つのランダムに生成されたシードを必要とし得ることが理解されよう。言い換えると、文字列「Bitcoin Seed」の使用は、ＨＤウォレットを生成するための必要要件ではない。

親秘密鍵ｓｋ_parentから、強化された子秘密鍵ｓｋ_childを計算するための式は、以下の通りである：

ここで、ｃ_parentは、親チェーンコードであり、０≦ｉｎｄｅｘ＜２³¹は子インデックスであり、ＨＭＡＣ－ＳＨＡ５１２_Lは、ＳＨＡ－５１２ハッシュ関数を用いて計算されたＨＭＡＣ関数の結果の左の３２バイトである。子公開鍵のための対応する式は、この式にベースポイントＧを単純に点乗算（point multiply）することによって導出される。子チェーンコードｃ_childは、ＨＭＡＣ関数の結果の右の３２バイトであると定義される：

親公開鍵ｐｋ_parentおよび親秘密鍵ｓｋ_parentから、強化されていない子秘密鍵ｓｋ_childを計算するための式は以下である：

ここで、ｃ_parentは、親チェーンコードであり、２³¹≦ｉｎｄｅｘ＜２³²は子インデックスであり、ＨＭＡＣ－ＳＨＡ５１２は、ＳＨＡ－５１２ハッシュ関数を用いて計算されたＨＭＡＣ関数である。強化された鍵と同様に、強化されていない鍵の子チェーンコードｃ_childは、ＨＭＡＣ関数の結果の右の３２バイトであると定義される：

この第２のタイプの子鍵により、親公開鍵およびチェーンコードの知識を有する者であれば、以下の式を使用して、子公開鍵を導出することができる：

これを使用して、外部当事者は、必要に応じて様々な支払いアドレスを導出し、通信および記憶の回数を減らすと同時に、鍵の再使用を回避することができる。

一般に、ＨＤウォレットは、秘密鍵－公開鍵ペアの何らかの階層ツリー状構造を生成する必要がある。これにより、１つのシードからすべて再生成することができる多数の鍵ペアが提供される。

しきい値デジタル署名
図４は、本発明のいくつかの実施形態による、デジタル署名を生成するための例示的なシステム４００を示す。システムは、各々が共有秘密鍵のそれぞれのシェアを有する複数の参加者４０１を含む。共有秘密鍵は、秘密分散方式（secret sharing scheme）、例えば、ＪＶＲＳＳまたはＳｈａｍｉｒの秘密分散方式を使用して生成され得る。共有秘密鍵は、ディーラーを伴う方式を使用して、またはディーラーを伴わない方式を使用して生成されていてもよい。図４には３人の参加者のみが示されているが、一般に、システムは任意の数の参加者４０１を含み得る。システムはまた、検証当事者４０２、すなわち署名検証当事者と、コーディネータ４０４とを含む。コーディネータ４０４は、しきい値数の署名シェアに基づいて署名を生成するように構成され、各署名シェアは、それぞれの参加者によって生成される。コーディネータ４０４は、図４では別個のものとして示されているが、いくつかの例では、コーディネータは、参加者のうちの１つ、例えば第１の参加者４０１ａと同じエンティティであってもよい。いくつかの例では、システムは、１つまたは複数のブロックチェーンノード１０４を含む。

各参加者４０１、検証当事者４０２、およびコーディネータ４０４は、それぞれのコンピューティング機器（図示せず）を操作する。各それぞれのコンピューティング機器は、１つまたは複数のプロセッサ、例えば１つまたは複数の中央処理装置（ＣＰＵ）、アクセラレータプロセッサ（ＧＰＵ）、特定用途向けプロセッサ、および／またはフィールドプログラマブルゲートアレイ（ＦＰＧＡ）を含むそれぞれの処理装置を備える。それぞれのコンピューティング機器はまた、メモリ、すなわち、１つまたは複数の非一時的コンピュータ可読媒体の形態のコンピュータ可読ストレージを備え得る。メモリは、１つまたは複数のメモリ媒体、例えば、ハードディスクなどの磁気媒体、ソリッドステートドライブ（ＳＳＤ）、フラッシュメモリもしくはＥＥＰＲＯＭなどの電子媒体、および／または光ディスクドライブなどの光学媒体を採用する１つまたは複数のメモリユニットを備え得る。それぞれのコンピューティング機器は、少なくとも１つのユーザ端末、例えば、デスクトップもしくはラップトップコンピュータ、タブレット、スマートフォン、またはスマートウォッチなどのウェアラブルデバイスを含み得る。代替的にまたは追加的に、それぞれのコンピューティング機器は、ユーザ端末を介してアクセスされるクラウドコンピューティングリソースなどの１つまたは複数の他のネットワーク化されたリソースを含み得る（クラウドコンピューティングリソースは、１つまたは複数のサイトで実装される１つまたは複数の物理サーバデバイスのリソースを含む）。システム４００の当事者によって実行されるものとして説明される任意の行為は、その当事者によって操作されるそれぞれのコンピューティング装置によって実行され得ることが理解されよう。

本発明は、ブロックチェーンの文脈での使用のみに限定されないが、以下では、第１の参加者４０１ａを、図１～図３を参照して説明されたアリス１０３ａと同等として説明する。すなわち、いくつかの例では、アリス１０３ａは第１の参加者４０１ａである。検証当事者４０２は、以下ではキャロル４０２と呼ばれる。

これらの実施形態では、アリス４０１ａは、メッセージのための署名のシェアを生成し、自身がその署名シェアを生成したことをキャロル４０２に証明したいと思う。

アリス４０１ａは、署名されるべきメッセージ、例えば、ブロックチェーントランザクション、文書、またはコントラクトなどのうちのいくつかまたは一部を取得する。アリス４０１ａは、自らメッセージを生成してもよいし、アリス４０１ａは、例えば、別の参加者４０１またはコーディネータ４０４からメッセージを受信してもよい。アリス４０１ａは、外部データ項目も取得する。アリス４０１ａは、例えば、名前、パスポート番号、公開鍵などの外部データ項目をすでに有していてもよいし、アリス４０１ａは、外部データ項目を生成してもよい。例えば、以下でより詳細に説明するように、外部データ項目は、アリス４０１ａによって生成された署名（「第２の署名」）であり得る。

アリス４０１ａは、外部データ項目のハッシュに基づいてエフェメラル秘密鍵シェアを生成する。各他の参加者、例えば第２の参加者４０１ｂおよび第３の参加者４０１ｃも、それぞれのエフェメラル秘密鍵シェアを生成する。他の参加者は、それぞれの外部データ項目のハッシュに基づいてそれぞれのエフェメラル秘密鍵シェアを生成することが好ましいが、これは必須ではない。

他の参加者のエフェメラル秘密鍵シェアがそれぞれの外部データ項目に基づくかどうかにかかわらず、各参加者のエフェメラル秘密鍵シェアは、他の参加者によって生成された入力（「データ項目」）に基づいて生成される。すなわち、アリスのエフェメラル秘密鍵シェアは、すべての他の参加者からのそれぞれのデータ項目に基づいて生成され、他の参加者のそれぞれのエフェメラル秘密鍵シェアは、アリスからのデータ項目の関数である。特定の例として、各参加者は、それぞれの外部データ項目に基づくそれぞれのデータ項目（例えば、多項式のゼロ次係数）を生成し得る。プライバシーを保護するために、データ項目は、秘密分散方式を使用して共有され得る。参加者は、参加者が他の参加者のインデックスで評価された多項式を共有する上述したＪＶＲＳＳ方式を使用し得る。ＪＶＲＳＳ方式は、ランダムに生成されるのとは対照的に、外部データ項目に基づいて多項式のゼロ次係数を計算することによってわずかに修正される。これについては以下でより詳細に説明する。

アリスのエフェメラル秘密鍵シェアは、ここではアリスの外部データ項目をハッシュした結果の関数である。外部データ項目のハッシュを生成するために使用されるハッシュ関数は、任意の適切なハッシュ関数、例えば、ＳＨＡ２５６、ＳＨＡ５１２であり得、１つまたは複数のハッシュ関数を複数回適用することを含み得る。例えば、ハッシュ関数は、ダブルハッシュ関数、例えば、ＳＨＡ２５６ｄ（ｘ）＝ＳＨＡ２５６（ＳＨＡ２５６（ｘ））であり得る。

アリス４０１ａによって生成された署名シェアは、エフェメラル秘密鍵シェア、または特定の署名アルゴリズムによっては、エフェメラル秘密鍵シェアの逆数を必要とする。それぞれのエフェメラル秘密鍵シェアがそれぞれの参加者に対してプライベートなままであるために、例えば、アリス１０３ａのみがアリスのそれぞれのエフェメラル秘密鍵シェアを知るように、参加者は、秘密分散方式を使用してそれぞれのエフェメラル秘密鍵シェアを生成し得、すなわち、各参加者は、各々が同じシークレットのシェアを生成するのに十分な情報を他の参加者と共有はするが、シークレット自体を実際に生成することはない。この場合、共有シークレットはエフェメラル秘密鍵である。例えば、参加者は、ＪＶＲＳＳの修正バージョンを使用し得る。ＪＶＲＳＳのステップは上に詳述されている。この修正バージョン（ＪＶＲＳＳ－Ａと呼ぶ）では、ステップ１）において、参加者は、それぞれのプライベート多項式（private polynomial）のゼロ次係数ａ_i0を、それぞれのデータ項目のハッシュ（例えば、ダブルハッシュ）と等しいものとして設定する。他の多項式係数は、通常のＪＶＲＳＳの場合のようにランダムに選択されてもよい。次いで、ＪＶＲＳＳの残りのステップ１）～５）を通常通りに行う。次いで、各参加者は、それぞれのエフェメラル秘密鍵シェアと、難読化されたデータ項目（すなわち、データ項目に対応する公開鍵）のセットとを、他の参加者ごとに１つずつ有する。ＪＶＲＳＳ、またはむしろＪＶＲＳＳ－Ａは、秘密分散方式の特定の例であり、他の方式、例えば、Ｓｈａｍｉｒの秘密分散方式が使用されてもよいことに留意されたい。

アリス４０１ａは、自身のデータ項目に対応する公開鍵を生成する。例えば、これは、」データ項目を生成点で難読化することによって行われる。アリス４０１ａは、各他の参加者４０１からそれぞれの公開鍵を取得し、これらの公開鍵を使用して、エフェメラル秘密鍵に対応するエフェメラル公開鍵を生成する。例えば、参加者は、ＪＶＲＳＳ－Ａを使用して、エフェメラル公開鍵を生成し得る。「エフェメラル公開鍵」は、ここではエフェメラル公開鍵のｘ構成要素（またはｘ座標）の省略表現として使用されていることに留意されたい。

エフェメラル秘密鍵シェアおよびエフェメラル公開鍵（すなわち、共有エフェメラル秘密鍵に対応する公開鍵）を生成した後、アリス４０１ａは、自身の署名シェアを生成することができる。アリスの署名シェアは、メッセージ（例えば、ブロックチェーントランザクション）と、共有秘密鍵のアリスのそれぞれのシェアと、（逆数）エフェメラル秘密鍵シェアと、エフェメラル公開鍵とに基づいて生成される。この場合も同様に、使用されている特定の署名方式に応じて、署名シェアは、エフェメラル秘密鍵の逆数に基づいて生成され得ることに留意されたい。いずれにしても、エフェメラル秘密鍵シェアが外部データ項目に基づいて生成されると仮定すると、その外部データ項目は、ここで、署名シェア内に埋め込まれている。

次いで、アリス４０１ａは、自身の署名シェアをコーディネータ４０４に送信し得、コーディネータは、アリスの署名シェアと、それぞれの参加者４０１によって生成された１つまたは複数のそれぞれの署名シェアとに基づいて第１の署名を生成することができる。コーディネータ４０４は、有効な署名を生成するためにしきい値数の署名シェアを必要とする。上記で簡単に述べたように、アリス４０１ａは、実際にはコーディネータ４０４であってもよい。その場合、アリスは、自身の署名シェアをすでに入手しており、他の参加者４０１からそれぞれの署名シェアを受信する。

したがって、署名は、この時点でアリス４０１ａのみに知られている外部データ項目、例えば個人識別子を組み込む。外部データ項目自体が秘密（secret）である必要はないことに留意されたい。外部データ項目が署名内に埋め込まれるという事実は、最初は秘密に保たれることが好ましいが、これは必須ではない。例えば、外部データ項目は、それ自体１つまたは複数の当事者に知られているが、外部データ項目としてのその使用は知られていない、アリスの証明された公開鍵であってもよい。

アリス４０１ａは、第１の署名のシェアを生成したことを証明するために、署名をキャロル４０２が利用できるようにし得る。例えば、アリス４０１ａは、署名をキャロル４０２に送信してもよいし、アリスは、署名を公開するか、または他の方法でブロードキャストしてもよい。他の例では、キャロル４０２は、異なる当事者、例えばコーディネータ４０４から署名を取得し得る。アリス４０１ａはまた、メッセージをキャロル４０２に送信し得る。署名およびメッセージは、一緒に送信または公開されることが好ましい。

アリス４０１ａはまた、署名と同時に、または異なる時間に、例えば後の時間に、外部データ項目をキャロル４０２が利用できるようにし得る。署名と同じ方法で、または異なる方法で外部データ項目を利用できるようにし得る。例えば、アリス４０１ａは、セキュアな通信チャネルを介して外部データ項目をキャロル４０２に送信し得る。アリス４０１ａが署名シェアを生成したことを検証するために、キャロル４０２は、他の参加者４０１によって生成されたそれぞれのデータ項目に対応するそれぞれの公開鍵（例えば、ゼロ次係数を難読化する公開鍵）を必要とする。アリス４０１は、これらをキャロル４０２に送信し得るか、または他の参加者は、それぞれのエフェメラル公開鍵シェアをキャロル４０２に送信し得る。

上述したように、外部データ項目は、別の署名であり得るか、または少なくとも別の署名を含み得る。その場合、アリス４０１ａは、第２のメッセージを取得し、少なくとも第２のメッセージと「主秘密鍵」とに基づいて第２の署名を生成する。最も広い例では、「主（main）」は、単にラベルとして使用される。すなわち、主秘密鍵は、アリス４０１ａによって所有される任意の秘密鍵であり得る。

アリス４０１は、第２のメッセージの少なくとも一部を自ら生成し得る。追加的にまたは代替的に、アリス４０１ａは、別の当事者、例えばキャロル４０２から、第２のメッセージの少なくとも一部を受信するか、または他の方法で取得し得る。すなわち、キャロル４０２が、第２のメッセージの一部または全部をアリス４０１ａに送信してもよいし、アリス４０１ａおよびキャロル４０２が、第２のメッセージの少なくとも一部に関して事前に合意していてもよい。例えば、アリス４０１ａおよびキャロル４０２は、第２の署名が生成された時間および／またはデータの指示を含めることに合意していてもよい。いくつかの例では、第２のメッセージは、第１のメッセージを含むか、またはそれに基づいて生成され得る。例えば、第２のメッセージは、第１のメッセージの始まりまたは終わりに連結された追加データを有する第１のメッセージを含み得る。

いくつかの例では、各参加者４０１は、同じ第２のメッセージを使用して、それぞれの第２の署名を生成する。すなわち、各参加者４０１は、第２のメッセージと、受け入れ可能な主秘密鍵とに基づいてそれぞれの第２の署名を生成する。

アリス４０１ａは、少なくとも第２の署名をキャロル４０２に送信し得るか、またはアリス４０１ａは、第２の署名を公開し得る。キャロル４０２が第２のメッセージをまだ入手していない場合、アリス４０１ａは、第２のメッセージをキャロル４０２に送信するか、または第２のメッセージを公開し得る。アリス４０１ａはまた、主秘密鍵に対応する主公開鍵をキャロル４０２に送信し得るか、または少なくとも、キャロル４０２が主公開鍵を取得し得る場所、例えば、証明機関によって公開され、主公開鍵がアリス４０１ａにリンクされていることを証明する証明書を記憶している位置を示し得る。

エフェメラル秘密鍵シェアは、少なくとも外部データ項目のハッシュ、例えば第２の署名のダブルハッシュに基づく（すなわち、その関数である）。エフェメラル秘密鍵シェアはまた、ランダムに生成されたソルト値、すなわち、外部データ項目のハッシュに追加された値に基づき得る。より具体的には、アリスのエフェメラル秘密鍵シェアを生成するために使用されるデータ項目は、ソルト値に基づき得る。好ましくは、ソルト値は一度だけ使用され、すなわち、第１の署名の異なるインスタンスを生成するためには異なるソルト値が使用される。これらの例では、アリス４０１ａは、第３のメッセージとソルト値とに基づいて第３の署名を生成し得る。すなわち、ソルト値は、第３の署名を生成するための秘密鍵として使用される。第３のメッセージは、第１のメッセージおよび／または第２のメッセージに基づいて生成され得る。第３のメッセージは、第２のメッセージと同じであってもよい。アリス４０１ａは、第３の署名をキャロル４０２に送信し得る。アリス４０１ａが第３のメッセージを生成した場合、アリスはそれもキャロル４０２に送信し得る。あるいは、キャロル４０２は、第３のメッセージをアリス４０１ａに送信している場合があり、その場合、アリス４０１ａは、それをキャロル４０２に送り返す必要はないが、送り返すことを選択してもよい。

第３の署名を生成する代わりに、アリス１０３ａは、ゼロ知識証明（zero-knowledge proof：ＺＫＰ）を使用してランダムソルト値の知識を証明し得る。当業者は、ＺＫＰ自体に精通しているので、本明細書では詳細に説明しない。例示的なＺＫＰを以下に提供する。

オプションで、アリス４０１ａは、データ項目に対応するそれぞれの公開鍵、すなわち、アリス４０１ａによって生成された公開鍵および他の参加者から取得された公開鍵を使用して、ハッシュツリー、例えばマークルツリーを生成し得る。これらの公開鍵の各々は、ハッシュツリーのそれぞれのリーフハッシュを形成するためにハッシュされる。アリス４０１ａは、結果として得られたハッシュルート（例えば、マークルルート）をキャロル４０２に送信し得るか、またはハッシュルートを公開し得る。同時にまたは後の時間に、アリス４０１ａは、アリスの公開鍵がハッシュツリーの要素であることを証明するために、ハッシュプルーフ（例えば、マークルプルーフ）をキャロル４０２に送信し得る。いくつかの例では、第１のメッセージは、ハッシュルートを含み、したがって、署名シェアを生成する各参加者は、同じハッシュルートを証明する（attest to）。すなわち、それらは、ハッシュルートを生成するために使用された公開鍵を証明する。例示的なハッシュルートを図７に示す。

上述したように、本発明の実施形態は、ブロックチェーン１５０との併用に限定されない。しかしながら、そのようなものでは、第１のメッセージは、ブロックチェーントランザクションであり得る。例えば、アリス４０１ａは、ブロックチェーントランザクションの一部または全部、例えばトランザクションの１つまたは複数の入力および／または１つまたは複数の出力に署名するために使用される署名のシェアを生成し得る。次いで、コーディネータ４０４は、アリスが署名していないトランザクションの入力に第１の署名を含め得る。トランザクションは、異なる当事者、例えばボブ１０３ｂおよび／またはキャロル４０２にロックされた出力を含み得、例えば、出力は、ボブ１０３ｂによって所有される公開鍵にロックされたpay-to-public-key（Ｐ２ＰＫ）またはpay-to-public-key-hash（Ｐ２ＰＫＨ）出力であり得る。第２のメッセージは、トランザクションを含み得る。第２のメッセージは、ブロックチェーン１５０に関するデータ、例えば、トランザクションが生成されたときのブロックチェーンの現在のブロック高さを含み得る。これらの例では、アリス４０１ａまたはコーディネータ４０４は、ブロックチェーン１５０へのトランザクションを送信することによって、第１のメッセージをキャロル４０２が利用できるようにし得、そこから、キャロル４０２がアクセスし得る。これは図４に示されている。ハッシュルートは、ブロックチェーントランザクションの出力に含まれ得る。

図５は、本発明のいくつかの実施形態による、署名シェアを生成するためにアリス４０１ａによって行われ得るステップの例示的なシーケンスを示す。ステップのいくつかが異なる順序で実行され得ることは理解されよう。ステップＳ５０１において、アリス４０１ａは、第１のメッセージ、例えば、ブロックチェーントランザクションを取得する。ステップＳ５０２において、アリス４０１ａは、外部データ項目、例えば、第２の署名を取得する。ステップＳ５０３において、アリス４０１ａは、外部データ項目に基づいて、例えば、第２の署名のハッシュに基づいて、エフェメラル秘密鍵シェアを生成する。ステップＳ５０４において、アリス４０１ａは、共有エフェメラル秘密鍵に対応するエフェメラル公開鍵を生成する。ステップＳ５０５において、アリス４０１ａは、署名シェアを生成し、ステップＳ５０６において、アリスは、それをコーディネータ４０４に送信する。コーディネータ４０４が署名を生成し、それをキャロル４０２が利用できるようにした後、アリス４０１ａは、少なくとも外部データ項目をキャロル４０２に送信する。

次に、検証当事者であるキャロル４０２が行うアクションについて説明する。キャロル４０２は、アリス４０１ａに、アリス４０１ａが第１の署名のシェアを生成したことを証明してもらいたい。キャロル４０２は、第１の署名を取得する。アリス４０１ａが第１の署名をキャロル４０２に送信し得るか、または第１の署名は、公的に入手可能であり、例えば、ブロックチェーン１５０上に記録され得る。第１の署名がブロックチェーントランザクションの入力に含まれる場合、キャロル４０２は、トランザクションから第１の署名を抽出することによって第１の署名を取得する。キャロル４０２はまた、アリス４０１ａから候補の外部データ項目を取得する。ここで、「候補（の）（candidate）」は、アリス４０１ａが、第１の署名内に、すなわちそれぞれの署名シェアに埋め込まれていると主張する外部データ項目を指すために使用される。実際にそうである場合、候補の外部データ項目は、上述した外部データ項目と同じである。しかしながら、この時点で、キャロル４０２は、そうであることを確認することができないので、「候補の」としている。

キャロル４０２は、候補の外部データ項目を使用して、候補のエフェメラル公開鍵を生成する。これを行うために、キャロルは、アリスの外部データ項目（または、第１のデータ項目が外部データ項目だけでなくそれ以外にも基づいて生成される場合は第１のデータ項目）を取得し、対応する公開鍵を生成する。キャロル４０２はまた、他の参加者のデータ項目に対応する公開鍵を取得する。キャロル４０２は、候補を使用して候補のエフェメラル公開鍵を生成し、公開鍵を取得する。候補のエフェメラル公開鍵は、第１の構成要素および第２の構成要素、例えば、ｘ値およびｙ値を含む。

キャロル４０１によって取得された第１の署名は、第１の署名構成要素および第２の署名構成要素を含む。アリス４０１ａが第１の署名に寄与したことを検証するために、キャロル４０２は、候補の第１の署名構成要素を候補のエフェメラル公開鍵の第１の構成要素と比較する。それらが一致する場合、キャロル４０２は、アリス４０１ａが実際に第１の署名のシェアを生成したことを確信することができる。すなわち、候補のエフェメラル公開鍵の第１の構成要素（候補の第１の署名構成要素と同等のｘ構成要素を含む）と第１の署名構成要素とが一致するためには、候補の外部データ項目は、アリスの署名シェアを生成するために使用された外部データ項目でなければならない。アリス４０１ａがキャロル４０２に候補の外部データ項目を提供したので、これは、アリス４０１ａが署名のシェアを生成したことを証明する。このプロセスは、図６のステップＳ６０１～Ｓ６０５に示されている。

キャロル４０２はまた、対応する公開鍵に対して妥当性確認されたとき、第１の署名が有効な署名であることを検証し得る。第１の署名がブロックチェーントランザクションに署名するために使用され、そのトランザクションがブロックチェーンに記録されている場合、キャロル４０１は、第１の署名が有効な署名であると仮定し得る（すなわち、署名が有効でなかった場合、トランザクションはブロックチェーンノードによって受け入れられていなかったであろう）。しかしながら、キャロル４０１は、使用されているロック解除スクリプトが署名チェックを含むことを依然として検証し得る（すなわち、ブロックチェーンノードがトランザクション妥当性確認中に署名に対して署名チェックを実行したことを確認するために）。これを行うために、キャロル４０１は、使用されたトランザクションのロック解除スクリプトがＯＰ＿ＣＨＥＣＫＳＩＧスクリプトを含むことをチェックし得る。

アリスの観点から本発明の実施形態を説明する際に上述したように、外部データ項目は、それ自体が、署名、すなわち第２の署名であってもよい。この場合、キャロル４０２は、例えばアリス４０１ａから、第２のメッセージを取得し、例えば、証明された公開鍵などの、アリス４０１ａによって提供されるかまたは他の方法でアリス４０１ａにリンクされた公開鍵を使用して検証されたときに、第２の署名が有効な署名であることを検証し得る。

アリス４０１ａが、第１の署名を生成するために使用されるエフェメラル秘密鍵シェアを生成するためにソルト値を使用した場合、アリス４０１ａは、ソルト値に対応する公開鍵をキャロル４０２に提供し得る。次いで、キャロル４０２は、「ソルト公開鍵」に基づいて、例えば、候補のエフェメラル公開鍵シェアとソルト公開鍵との組合せに基づいて、候補の第１の署名構成要素を生成し得る。上記組合せのｘ値は、候補の第１の署名構成要素を生成するために使用され得る。一例を以下にさらに提供する。これらの例では、アリス４０１ａはまた、キャロル４０２に第３の署名および第３のメッセージを提供し得る。キャロル４０２は、ソルト公開鍵を使用して検証されたときに、第３の署名が有効な署名であることを検証し得る。別のオプションの特徴として、アリス４０１ａは、アリス４０１ａがソルト値を知っていることを検証するためにキャロル４０２が使用し得るＺＫＰをキャロル４０２に提供し得る。

以下に、ディーラーを伴わないＥＣＤＳＡしきい値署名で使用されるシークレットシェアにアイデンティティデータを埋め込む具体的な例を説明する。

Ｎ人の参加者Ａ₁，…，Ａ_Nのグループは、しきい値署名グループを形成することに同意する。修正されたＪＶＲＳＳ（ＪＶＲＳＳ－Ａ）を実行するために必要なデータを生成するために、ｉ∈｛１，…，Ｎ｝に対して、各参加者４０１が秘密鍵ｓｋ_Ai（「主秘密鍵」）と、対応する公開鍵ＰＫ_Ai＝ｓｋ_Ai・Ｇとを有すると仮定する。公開鍵ＰＫ_Aiは、証明された公開鍵であってもよいし、証明された公開鍵から導出されてもよい。

グループは、公開されており、後の時点で証明（attestation）に使用される証明メッセージＭ_attest（「第２のメッセージ」）に合意する。各グループメンバ４０１は、証明メッセージに署名して、「第２の署名」（すなわち、外部データ項目）を生成する：

各参加者４０１はまた、自身の署名の（ダブル）ハッシュ

を計算し、これを、生成点を用いて難読化する：

署名およびハッシュされたデータは、しきい値秘密分散および証明アルゴリズムの両方で使用される。

Ｎ人の参加者間の共有シークレットは、秘密分散方式、例えば、上述したＪＶＲＳＳ法を使用して生成することができる。ＪＶＲＳＳ－Ａ変形の場合、アルゴリズムは、ゼロ次（ｙ切片）を規定することによって修正される。以下の修正を加えて、ＪＶＲＳＳのステップ１）～５）に従う。

ステップ１）において、各参加者４０１は、（値をランダムに選択するのではなく）自身のプライベート多項式のゼロ次を計算する：

他のすべての多項式係数はランダムに選択される。

Ｎ人の参加者間の共有シークレットの逆数は、上述したＩＮＶＳＳ方法を使用して計算することができる。ＩＮＶＳＳを使用することで、Ｎ個のグループエフェメラル鍵と、２ｔ＋１個の逆数シェアを生成することができる。証明セットアップを使用することによって、ＩＮＶＳＳは、ＩＤ埋込みを組み込むように修正される。これは単に、共有エフェメラル秘密鍵ｋ（むしろ、完全な秘密鍵自体は実際には生成されないので、共有エフェメラル秘密鍵のシェア）を生成するために、参加者４０１が、通常のＪＶＲＳＳの代わりにＪＶＲＳＳ－Ａ法を使用するようにするためのものである。

参加者はまた、多項式のゼロ次に対応する公開鍵を使用してマークルツリーを作成する。参加者は、以下のステップを行う。
１．各参加者４０１は、ＪＶＲＳＳ－Ａ法ｒ_i0＝ｋ_i0・Ｇからの参加者の難読化された係数を使用して、以下のマークルツリーおよび対応するマークルルートＲを計算することができ、ここで、各参加者４０１は、それらの署名の（ダブル）ハッシュに基づいて生成されたそれぞれのデータ項目ｋ_i0と、データ項目に対応するそれぞれの公開鍵ｒ_i0とを有する。
２．次いで、参加者４０１は、この値をすべての参加者４０１にブロードキャストすることによって、全員が同じマークルルートを有することを確認することができる。その後、このマークルルートは、対応するエフェメラル鍵を使用して署名されるメッセージに含まれ得る。

セットアップ：Ｎ人の独立した参加者Ａ₁，…，Ａ_Nは、しきい値秘密分散グループへの参加に同意する。その参加者らはまた、将来の証明を可能にするトラストレスセットアップを使用することに同意する。参加者は、Ｎ人の参加者のグループのための証明メッセージセットアップを使用するとともに（ｒ_i0の和に基づいて）証明メッセージ依存グループエフェメラル鍵ｒを生成する。証明メッセージが、署名されているトランザクションになることをグループが望む場合、このステップは、一旦メッセージが知られると、署名の作成中に完了される必要があることに留意されたい。

各参加者４０１は、ＪＶＲＳＳに従って、秘密鍵シェアａ_i＝ＪＶＲＳＳ（ｉ）を計算する。公開鍵は、プライベート多項式の難読化されたゼロ次値を加算することによって計算される：

しきい値公開鍵および秘密鍵シェア導出は修正されないことに留意されたい。秘密鍵シェア導出は、証明なしでＪＶＲＳＳに従うべきである。

２ｔ＋１人の参加者Ａ₁，…，Ａ_2t+1のサブセットが、ＰＫ_Bに支払うトランザクションに署名したいと望む。

その参加者らは、署名入力の一部として、証明メッセージ依存エフェメラル鍵ｒを使用して、上述した「非最適署名生成」のステップ１）～７）に従う。代わりに最適な署名生成方法が使用されてもよいことに留意されたい。以下に概要を示す。

すべての署名参加者４０１がトランザクションＴｘ’_threshold（以下の表を参照）について合意する。

各参加者４０１は、メッセージダイジェストｅ＝ＳＨＡ－２５６ｄ（Ｔｘ’_threshold）を計算する。

各参加者４０１は、署名シェア

を計算し、ここで、

（それぞれのエフェメラル秘密鍵シェアの逆数）およびｒ（共有エフェメラル秘密鍵に対応する公開鍵）は、上述した方法を使用して導出される。

コーディネータ４０４は、署名シェアを収集し、補間する：

出力（「第１の署名」）は、［ｒ，ｓ］であり、トランザクションは署名することができる（完全なトランザクションについては以下の表を参照）。

参加者Ａ₁，…，Ａ_Nのアイデンティティは、この時点で、エフェメラル鍵ｒに埋め込まれており、したがって、第１の署名に埋め込まれている。Ｍ_attest（これは、提供されてもよいし、公に知られていてもよい）が与えられると、参加者４０１は、自身がしきい値グループのメンバであることを証明することができる。

アリス４０１ａが、秘密アイデンティティ鍵ｓｋ_A1を有する参加者Ａ₁であると仮定する。値Ｍ_attestは公開されており、アリス４０１ａは、第２の署名を生成することができる：

グループ公開エフェメラル鍵ｒを生成するためのアルゴリズムを実行した結果、アリスはまた、各データ項目に対応する公開鍵

と、Ｔｘ_thresholdに埋め込まれる対応するマークルルートＲとを保持する。

検証者４０２は、第１の署名［ｒ，ｓ］を有するＴｘ_thresholdおよび参加者の数Ｎを知る。

証明プルーフを実行するために、アリス４０１ａは、最初に、検証者であるキャロル４０２に下記を提供する：

キャロル（検証者）は、候補のエフェメラル公開鍵（ｘ構成要素およびｙ構成要素を含む）を計算する：

また、候補のエフェメラル公開鍵のｘ構成要素に基づいて候補の第１の署名構成要素を計算する：

そして、ｒ’＝ｒであること（すなわち、候補の第１の署名構成要素が第１の署名構成要素と一致すること）をチェックする。

キャロルはまた、［ｒ，ｓ］が、グループ公開鍵ＰＫ（ここで、ＰＫ＝ａ．Ｇである）を使用して妥当性確認されたときに、有効な署名であることを検証する。

以下では、マークルプルーフ証明について説明する。キャロル４０２はマークルルートＲを知っていると仮定する。アリスは、マークルプルーフを生成して、

が、Ｒによって表される集合の要素であることを立証する。アリス４０１ａは、セットアップ中に他のグループメンバからすべてのエフェメラル鍵シェアを受信し終わっているので、マークルツリー全体を再生成してプルーフを生成することができることに留意されたい。

検証者がすべての参加者を訪ね、共有エフェメラル秘密鍵ｋを作成するのに十分な情報を入手し、次いで、その結果を署名とともに使用して共有秘密鍵を導出するという攻撃がある。これを防止するために、アリス４０１ａは、秘密のソルト値を含めることができる。明示的に、ゼロ次の参加者ｉのエフェメラル鍵は以下のように設定され得る：

次いで、アリス４０１ａは、ゼロ知識証明を提供することによって、またはｗで生成された署名を提供することによって、これの知識を証明することができる。このソルトは秘密にしておくべきである。

この方法は、メッセージがトランザクションであることに関連して説明されているが、署名が行われるメッセージは、これに限定される必要はないことに留意されたい。

以下は、説明される方法のいくつかのセキュリティ面の考察である。

エフェメラル鍵シェアｋ_A1をマスクするためのソルト値の使用は、スプーフィング攻撃に対する保護として機能する。仮にエフェメラル鍵が第１のトランザクション署名のみに依存する場合（追加のランダム性なし）、敵対者は、アリス（証明者）から受信した情報を単に保持することによって他者にプルーフをリプレイすることが可能であり得、元のトランザクション署名者を、プルーフを見ただけの人と区別することを困難にする。

署名対署名マップにおいて１回限りのシークレット値の使用を採用することで、すべての秘密鍵が安全であるだけでなく、敵対者がアリス４０１ａになりすますために取得したいかなる情報も使用することができないことが保証される。したがって、この方法は、キャロル（検証者）４０２が正直な当事者であることも信頼できる当事者であることも必要としない。

しきい値署名者プルーフは、マークルプルーフが提供されない限り、スプーフィングに対して脆弱であり得る。マークルプルーフが証明の一部として含まれていない場合、および証明メッセージが公に知られている場合、非グループメンバは、プルーフデータをリバースエンジニアリングすることができる。

イブ（盗聴者）が、（ｘ’，ｙ’）（ここで、ｒ’＝ｘ’ ｍｏｄ ｎ）と、グループ証明メッセージＭ_attestとを知っている場合、イブは、自分自身の秘密鍵ｓｋ_Eを取って、署名

を生成することができる。

次いで、イブは、Ｕ＝（ｘ’，ｙ’）－ＳＨＡ２５６ｄ（［ｒ_E，ｓ_E］）・Ｇを計算することができ、Ｕを部分Ｕ₁，Ｕ₂，…，Ｕ_N-1（ここで、Ｕ＝Ｕ₁＋…＋Ｕ_Nである）に自明に分割する。

イブは、計算されたデータを使用して、自身がグループ署名イベントの参加者であったと装うことができる。実際のグループ署名者から秘密情報が漏洩することはないが、第三者が、グループ署名イベントに参加したと装うことはできる。

グループによって署名されたメッセージにマークルルートを含めることによって、このスプーフィングが不可能になる。

結論
開示された技法の他の変形または使用事例は、本明細書の開示が与えられると、当業者には明らかになり得る。本開示の範囲は、記載された実施形態によって限定されず、添付の特許請求の範囲によってのみ限定される。

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

本発明の好ましい実施形態では、ブロックチェーンネットワーク１０６は、ビットコインネットワークであり、ビットコインノード１０４は、ブロックチェーン１５０のブロック１５１を作成し、公開し、伝搬し、記憶するという説明した機能のすべてを少なくとも実行する。これらの機能のうちの１つまたはいくつかのみを実行し、すべては実行しない他のネットワークエンティティ（またはネットワーク要素）が存在し得ることは除外されない。すなわち、ネットワークエンティティは、ブロックを作成および公開することなく、ブロックを伝搬および／または記憶する機能を実行し得る（これらのエンティティは、好ましいビットコインネットワーク１０６のノードとはみなされないことを想起されたい）。

本発明の好ましくない実施形態では、ブロックチェーンネットワーク１０６は、ビットコインネットワークでない可能性がある。これらの実施形態では、ノードが、ブロックチェーン１５０のブロック１５１を作成し、公開し、伝搬し、記憶するという機能のうちの少なくとも１つまたはいくつかを実行し、すべては実行しない可能性があることは除外されない。例えば、それらの他のブロックチェーンネットワーク上で、「ノード」は、ブロック１５１を作成して公開するが、それらのブロック１５１を記憶および／または他のノードに伝搬しないように構成されるネットワークエンティティを指すために使用され得る。

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

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

ステートメント１．デジタル署名のシェアを生成するコンピュータ実装方法であって、参加者のグループの各参加者は、第１の共有秘密鍵のそれぞれのシェアを有し、方法は、グループの第１の参加者によって実行され、
第１のメッセージを取得することと、
少なくとも第１の外部データ項目のハッシュに基づいて第１のデータ項目を生成することと、
エフェメラル秘密鍵の第１のエフェメラル秘密鍵シェアを生成することであって、第１のエフェメラル秘密鍵シェアは、第１のデータ項目と、各他の参加者によって生成されたそれぞれのデータ項目とに基づいて生成される、ことと、
エフェメラル秘密鍵に対応するエフェメラル公開鍵を生成することと、
第１のメッセージと、第１のエフェメラル秘密鍵シェアと、第１の共有秘密鍵の第１のシェアと、エフェメラル公開鍵とに基づいて、第１の署名シェアを生成することと、
少なくともしきい値数のそれぞれの署名シェアに基づいて第１の署名を生成するために、第１の署名シェアをコーディネータが利用できるようにすることと
を含む方法。

外部データ項目は、第１の当事者の識別子、例えば、名前、住所、電話番号、国民保険番号、パスポート番号、公開鍵などを含み得る。

好ましくは、第１の署名は、ＥＣＤＳＡ署名である。「エフェメラル公開鍵」は、「エフェメラル公開鍵のｘ構成要素」の省略表現として使用される。

好ましくは、各他の参加者は、同じ方法で、それぞれの外部データ項目に基づいて、それぞれのエフェメラル公開鍵シェアを生成する。

ステートメント２．第１のエフェメラル秘密鍵シェアを生成することは、他の参加者の各々との秘密分散方式を実行することを含む、ステートメント１に記載の方法。

ステートメント３．秘密分散方式は、共同検証可能秘密分散（ＪＶＲＳＳ）方式である、ステートメント２に記載の方法。

より正確には、秘密分散方式は、各参加者がランダムな多項式係数を生成する代わりに、各参加者が第１の外部データ項目のハッシュとしてゼロ次係数を設定するＪＶＲＳＳ方式の修正バージョンであり得る。ランダムな多項式係数は、真にランダムまたは擬似ランダムであり得る（例えば、任意に選択され得る）。

ステートメント４．第１のデータ項目は、第１の多項式のゼロ次係数であり、ＪＶＲＳＳ方式は、
第１の多項式のそれぞれのインスタンスを他の参加者の各々に送信することであって、第１の多項式のそれぞれのインスタンスは、それぞれの参加者のそれぞれのインデックスに基づいて生成される、ことと、
各他の参加者からそれぞれの多項式を取得することであって、それぞれの多項式は、第１の参加者のそれぞれのインデックスと、他の参加者によって生成されたそれぞれのデータ項目とに基づいて生成される、ことと
を含む、ステートメント３に記載の方法。

ステートメント５．エフェメラル秘密鍵に対応するエフェメラル公開鍵を生成することは、
第１のデータ項目に対応する第１の公開鍵を生成することと、
各他の参加者から、その他の参加者によって生成されたそれぞれのデータ項目に対応するそれぞれの公開鍵を取得することと、
を含む、先行ステートメントのいずれかに記載の方法。

ステートメント６．第１の参加者が第１の署名を生成したことを証明するために、第１の外部データ項目と、それぞれのデータ項目に対応する取得されたそれぞれの公開鍵とを検証当事者が利用できるようにすることを含む、ステートメント５に記載の方法。

ステートメント７．第１のメッセージを取得することは、第１のメッセージを生成することを含み、方法は、第１のメッセージを検証当事者が利用できるようにすることを含む、先行ステートメントのいずれかに記載の方法。

ステートメント８．
第２のメッセージを取得することと、
少なくとも第２のメッセージと第１の参加者の主秘密鍵とに基づいて第２の署名を生成することと
を含み、外部データ項目は第２の署名を含む、
先行ステートメントのいずれかに記載の方法。

ステートメント９．各参加者は、同じ第２のメッセージに基づいて、それぞれの外部データ項目を生成する、ステートメント８に記載の方法。

ステートメント１０．第１の参加者の主秘密鍵は、第１の参加者のアイデンティティにリンクされた主公開鍵に対応する、ステートメント８またはステートメント９に記載の方法。

ステートメント１１．第１の共有秘密鍵の第１のシェアは、秘密分散方式を使用して生成される、先行ステートメントのいずれかに記載の方法。

例えば、ＪＶＲＳＳである。

ステートメント１２．第１の参加者はコーディネータであり、方法は、
少なくともしきい値数のそれぞれの署名シェアを受信することと、
第１の署名構成要素および第２の署名構成要素を含む第１の署名を生成することと
を含み、第１の署名構成要素は、エフェメラル公開鍵に基づいて生成され、第２の署名構成要素は、少なくともしきい値数のそれぞれの署名シェアに基づいて生成される、先行ステートメントのいずれかに記載の方法。

ステートメント１３．第１のデータ項目は、ランダムソルト値に基づいて生成される、先行ステートメントのいずれかに記載の方法。

ステートメント１４．方法は、ランダムソルト値の知識を証明するためのゼロ知識証明を検証当事者に提供することを含む、ステートメント１３に記載の方法。

ステートメント１５．ランダムソルト値は秘密鍵であり、方法は、
第３のメッセージを取得することと、
少なくともランダムソルト値と第３のメッセージとに基づいて第３の署名を生成することと、
ランダムソルト値に対応する公開鍵を使用して検証されたときに、第３の署名が第３のメッセージの有効な署名であることを証明するために、第３の署名と、第３のメッセージと、ランダムソルト値に対応する公開鍵とを検証当事者が利用できるようにすることと
を含む、ステートメント１３またはステートメント１４に記載の方法。

ステートメント１６．第３のメッセージは第２のメッセージを含む、ステートメント１５に記載の方法。

例えば、第３のメッセージは、第２のメッセージと同じであってもよい。

ステートメント１７．
ハッシュツリーのルートハッシュを生成することであって、それぞれのデータ項目に対応する各それぞれの公開鍵が、ハッシュツリーのそれぞれのリーフハッシュを生成するためにハッシュされる、ことと、
ハッシュツリーのルートを参加者のうちの１つまたは複数および／または検証当事者に送信することと
を含む、先行ステートメントのいずれかに記載の方法。

ステートメント１８．第１のデータ項目に対応する第１の公開鍵がハッシュツリーの要素であることを検証するために、ハッシュプルーフを検証当事者に送信することを含む、ステートメント１５に記載の方法。

好ましくは、ハッシュツリーはマークルツリーであり、ハッシュルートはマークルルートであり、ハッシュプルーフはマークルプルーフである。

ステートメント１９．第１のメッセージは、ブロックチェーントランザクションの少なくとも一部を含む、先行ステートメントのいずれかに記載の方法。

例えば、第１の署名は、ブロックチェーントランザクションに署名するために使用され得る。

ステートメント２０．ブロックチェーントランザクションはハッシュルートを含む、ステートメント１８およびステートメント１９の方法。

ステートメント２１．ブロックチェーントランザクションは、第１の署名を含む、ステートメント１９またはステートメント２０に記載の方法。

ステートメント２２．第１のメッセージを検証当事者が利用できるようにすることは、ブロックチェーントランザクションをブロックチェーンネットワークに送信することを含む、ステートメント１９から２１のいずれかに記載の方法。

ステートメント２３．外部データ項目のハッシュは、外部データ項目のダブルハッシュである、先行ステートメントのいずれかに記載の方法。

ステートメント２４．デジタル署名が第１の参加者によって部分的に生成されたことを検証するコンピュータ実装方法であって、方法は、検証当事者によって実行され、
第１の署名構成要素および第２の署名構成要素を含む第１の署名を取得することと、
第１の参加者からの候補の第１の外部データ項目と、それぞれのデータ項目に対応する１つまたは複数のそれぞれの公開鍵とを、他の参加者ごとに１つずつ取得することと、
候補の第１の外部データ項目のハッシュに基づいて候補の公開鍵を生成することと、
候補の公開鍵と、取得された１つまたは複数の公開鍵とに基づいて、候補のエフェメラル公開鍵を生成することと、
候補のエフェメラル公開鍵に基づいて候補の第１の署名構成要素を生成することと、
候補の第１の署名構成要素が第１の署名構成要素に対応するかどうかに基づいて、第１の署名が第１の参加者によって部分的に生成されたことを検証することと
を含む方法。

ステートメント２５．第１の署名は第１のメッセージに署名し、方法は、
第１の署名を生成するために使用された共有秘密鍵に対応する共有公開鍵を取得することと、
第１の公開鍵を使用して検証されたときに、第１の署名が第１のメッセージの有効な署名であることを検証することと
を含む、ステートメント２４に記載の方法。

ステートメント２６．候補の外部データ項目は第２の署名である、ステートメント２４またはステートメント２５に記載の方法。

ステートメント２７．第２の署名は第２のメッセージに署名し、方法は、
第２の署名を生成するために使用された秘密鍵に対応する第２の公開鍵を取得することと、
第２の公開鍵を使用して検証されたときに、第２の署名が第２のメッセージの有効な署名であることを検証することと
を含む、ステートメント２４から２６のいずれかに記載の方法。

ステートメント２８．候補の公開鍵は、ランダムソルト値に基づいて生成され、方法は、
ランダムソルト値の知識を証明するためのゼロ知識証明を受信することと、
第１の参加者がランダムソルト値の知識を有することを検証することと
を含む、ステートメント２４またはステートメント２７に記載の方法。

ステートメント２９．候補の公開鍵は、ランダムソルト値に基づいて生成され、方法は、
第３のメッセージを取得することと、
第３の署名を取得することと、
ランダムソルト値に対応する公開鍵を使用して検証されたときに、第３の署名が第３のメッセージの有効な署名であることを検証することと
を含む、ステートメント２４から２８のいずれかに記載の方法。

ステートメント３０．
ハッシュプルーフおよびハッシュルートを取得することであって、第１のメッセージはハッシュルートを含む、ことと、
ハッシュプルーフに基づいて、候補の第１のエフェメラル公開鍵シェアが、ハッシュルートを含むハッシュツリーの要素であることを検証することと
を含む、ステートメント２４から２９のいずれかに記載の方法。

ステートメント３１．第１の署名は、第１の当事者から受信される、ステートメント２４から３０のいずれかに記載の方法。

ステートメント３２．第１のメッセージは、第１の参加者から受信される、ステートメント２４から３１のいずれかに記載の方法。

ステートメント３３．第１のメッセージは、検証当事者によって生成される、ステートメント２４から３１のいずれかに記載の方法。

ステートメント３４．第１のメッセージは、ブロックチェーントランザクションの少なくとも一部を含む、ステートメント２４から３３のいずれかに記載の方法。

ステートメント３５．第１のメッセージを取得することは、ブロックチェーンからブロックチェーントランザクションを取得することを含む、ステートメント３４に記載の方法。

ステートメント３６．第１の署名を取得することは、ブロックチェーントランザクションから第１の署名を抽出することを含む、ステートメント３５に記載の方法。

ステートメント３７．ブロックチェーントランザクションの入力は、第１の署名を含み、方法は、
ブロックチェーントランザクションの入力によって参照される前のブロックチェーントランザクションの出力が署名検証スクリプトを含むことを検証すること
を含む、ステートメント３３から３６のいずれかに記載の方法。

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

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

本明細書で開示される別の態様によれば、第１の参加者および検証当事者のアクションを含む方法が提供され得る。

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

Claims (39)

1. デジタル署名のシェアを生成するコンピュータ実装方法であって、参加者のグループの各参加者は、第１の共有秘密鍵のそれぞれのシェアを有し、前記方法は、前記グループの第１の参加者によって実行され、
   第１のメッセージを取得することと、
   少なくとも第１の外部データ項目のハッシュに基づいて第１のデータ項目を生成することと、
   エフェメラル秘密鍵の第１のエフェメラル秘密鍵シェアを生成することであって、前記第１のエフェメラル秘密鍵シェアは、前記第１のデータ項目と、各他の参加者によって生成されたそれぞれのデータ項目とに基づいて生成される、ことと、
   前記エフェメラル秘密鍵に対応するエフェメラル公開鍵を生成することと、
   前記第１のメッセージと、前記第１のエフェメラル秘密鍵シェアと、前記第１の共有秘密鍵の第１のシェアと、前記エフェメラル公開鍵とに基づいて、第１の署名シェアを生成することと、
   少なくともしきい値数のそれぞれの署名シェアに基づいて第１の署名を生成するために、前記第１の署名シェアをコーディネータが利用できるようにすることと
   を含む方法。
2. 前記第１のエフェメラル秘密鍵シェアを生成することは、前記他の参加者の各々との秘密分散方式を実行することを含む、請求項１に記載の方法。
3. 前記秘密分散方式は、共同検証可能秘密分散（ＪＶＲＳＳ）方式である、請求項２に記載の方法。
4. 前記第１のデータ項目は、第１の多項式のゼロ次係数であり、前記ＪＶＲＳＳ方式は、
   前記第１の多項式のそれぞれのインスタンスを前記他の参加者の各々に送信することであって、前記第１の多項式の前記それぞれのインスタンスは、前記それぞれの参加者のそれぞれのインデックスに基づいて生成される、ことと、
   各他の参加者からそれぞれの多項式を取得することであって、前記それぞれの多項式は、前記第１の参加者のそれぞれのインデックスと、前記他の参加者によって生成された前記それぞれのデータ項目とに基づいて生成される、ことと
   を含む、請求項３に記載の方法。
5. 前記エフェメラル秘密鍵に対応する前記エフェメラル公開鍵を生成することは、
   前記第１のデータ項目に対応する第１の公開鍵を生成することと、
   各他の参加者から、その他の参加者によって生成された前記それぞれのデータ項目に対応するそれぞれの公開鍵を取得することと
   を含む、請求項１から４のいずれか一項に記載の方法。
6. 前記第１の参加者が前記第１の署名を生成したことを証明するために、前記第１の外部データ項目と、前記それぞれのデータ項目に対応する前記取得されたそれぞれの公開鍵とを検証当事者が利用できるようにすることを含む、請求項５に記載の方法。
7. 前記第１のメッセージを取得することは、前記第１のメッセージを生成することを含み、前記方法は、前記第１のメッセージを前記検証当事者が利用できるようにすることを含む、請求項１から６のいずれか一項に記載の方法。
8. 第２のメッセージを取得することと、
   少なくとも前記第２のメッセージと前記第１の参加者の主秘密鍵とに基づいて第２の署名を生成することと
   を含み、前記外部データ項目は前記第２の署名を含む、
   請求項１から７のいずれか一項に記載の方法。
9. 各参加者は、同じ第２のメッセージに基づいて、それぞれの外部データ項目を生成する、請求項８に記載の方法。
10. 前記第１の参加者の前記主秘密鍵は、前記第１の参加者のアイデンティティにリンクされた主公開鍵に対応する、請求項８または９に記載の方法。
11. 前記第１の共有秘密鍵の前記第１のシェアは、秘密分散方式を使用して生成される、請求項１から１０のいずれか一項に記載の方法。
12. 前記第１の参加者は前記コーディネータであり、前記方法は、
    少なくとも前記しきい値数のそれぞれの署名シェアを受信することと、
    第１の署名構成要素および第２の署名構成要素を含む前記第１の署名を生成することと
    を含み、前記第１の署名構成要素は、前記エフェメラル公開鍵に基づいて生成され、前記第２の署名構成要素は、少なくとも前記しきい値数のそれぞれの署名シェアに基づいて生成される、請求項１から１１のいずれか一項に記載の方法。
13. 前記第１のデータ項目は、ランダムソルト値に基づいて生成される、請求項１から１２のいずれか一項に記載の方法。
14. 前記方法は、前記ランダムソルト値の知識を証明するためのゼロ知識証明を前記検証当事者に提供することを含む、請求項１３に記載の方法。
15. 前記ランダムソルト値は秘密鍵であり、前記方法は、
    第３のメッセージを取得することと、
    少なくとも前記ランダムソルト値と前記第３のメッセージとに基づいて第３の署名を生成することと、
    前記ランダムソルト値に対応する前記公開鍵を使用して検証されたときに、前記第３の署名が前記第３のメッセージの有効な署名であることを証明するために、前記第３の署名と、前記第３のメッセージと、前記ランダムソルト値に対応する公開鍵とを前記検証当事者が利用できるようにすることと
    を含む、請求項１３または１４に記載の方法。
16. 前記第３のメッセージは前記第２のメッセージを含む、請求項１５に記載の方法。
17. ハッシュツリーのルートハッシュを生成することであって、前記それぞれのデータ項目に対応する各それぞれの公開鍵が、前記ハッシュツリーのそれぞれのリーフハッシュを生成するためにハッシュされる、ことと
    前記ハッシュツリーの前記ルートを前記参加者のうちの１つまたは複数および／または前記検証当事者に送信することと
    請求項１から１６のいずれか一項に記載の方法。
18. 前記第１のデータ項目に対応する前記第１の公開鍵が前記ハッシュツリーの要素であることを検証するために、ハッシュプルーフを前記検証当事者に送信することを含む、請求項１５に記載の方法。
19. 前記第１のメッセージは、ブロックチェーントランザクションの少なくとも一部を含む、請求項１から１８のいずれか一項に記載の方法。
20. 前記ブロックチェーントランザクションは前記ハッシュルートを含む、請求項１８および１９に記載の方法。
21. 前記ブロックチェーントランザクションは、前記第１の署名を含む、請求項１９または２０に記載の方法。
22. 前記第１のメッセージを前記検証当事者が利用できるようにすることは、前記ブロックチェーントランザクションを前記ブロックチェーンネットワークに送信することを含む、請求項１９から２１のいずれか一項に記載の方法。
23. 前記外部データ項目の前記ハッシュは、前記外部データ項目のダブルハッシュである、請求項１から２２のいずれか一項に記載の方法。
24. デジタル署名が第１の参加者によって部分的に生成されたことを検証するコンピュータ実装方法であって、前記方法は、検証当事者によって実行され、
    第１の署名構成要素および第２の署名構成要素を含む第１の署名を取得することと、
    前記第１の参加者からの候補の第１の外部データ項目と、それぞれのデータ項目に対応する１つまたは複数のそれぞれの公開鍵とを、他の参加者ごとに１つずつ取得することと、
    前記候補の第１の外部データ項目のハッシュに基づいて候補の公開鍵を生成することと、
    前記候補の公開鍵と、前記取得された１つまたは複数の公開鍵とに基づいて、候補のエフェメラル公開鍵を生成することと、
    前記候補のエフェメラル公開鍵に基づいて候補の第１の署名構成要素を生成することと、
    前記候補の第１の署名構成要素が前記第１の署名構成要素に対応するかどうかに基づいて、前記第１の署名が前記第１の参加者によって部分的に生成されたことを検証することと
    を含む方法。
25. 前記第１の署名は第１のメッセージに署名し、前記方法は、
    前記第１の署名を生成するために使用された共有秘密鍵に対応する共有公開鍵を取得することと、
    前記第１の公開鍵を使用して検証されたときに、前記第１の署名が前記第１のメッセージの有効な署名であることを検証することと
    請求項２４に記載の方法。
26. 前記候補の外部データ項目は第２の署名である、請求項２４または２５に記載の方法。
27. 前記第２の署名は第２のメッセージに署名し、前記方法は、
    前記第２の署名を生成するために使用された秘密鍵に対応する第２の公開鍵を取得することと、
    前記第２の公開鍵を使用して検証されたときに、前記第２の署名が前記第２のメッセージの有効な署名であることを検証することと
    を含む、請求項２４から２６のいずれか一項に記載の方法。
28. 前記候補の公開鍵は、ランダムソルト値に基づいて生成され、前記方法は、
    前記ランダムソルト値の知識を証明するためのゼロ知識証明を受信することと、
    前記第１の参加者が前記ランダムソルト値の知識を有することを検証することと
    を含む、請求項２４または２７に記載の方法。
29. 前記候補の公開鍵は、ランダムソルト値に基づいて生成され、前記方法は、
    第３のメッセージを取得することと、
    第３の署名を取得することと、
    前記ランダムソルト値に対応する公開鍵を使用して検証されたときに、前記第３の署名が前記第３のメッセージの有効な署名であることを検証することと
    を含む、請求項２４から２８のいずれか一項に記載の方法。
30. ハッシュプルーフおよびハッシュルートを取得することであって、前記第１のメッセージは前記ハッシュルートを含む、ことと、
    前記ハッシュプルーフに基づいて、前記候補の第１のエフェメラル公開鍵シェアが、前記ハッシュルートを含むハッシュツリーの要素であることを検証することと
    を含む、請求項２４から２９のいずれか一項に記載の方法。
31. 前記第１の署名は、前記第１の当事者から受信される、請求項２４から３０のいずれか一項に記載の方法。
32. 前記第１のメッセージは、前記第１の参加者から受信される、請求項２４から３１のいずれか一項に記載の方法。
33. 前記第１のメッセージは、前記検証当事者によって生成される、請求項２４から３１のいずれか一項に記載の方法。
34. 前記第１のメッセージは、ブロックチェーントランザクションの少なくとも一部を含む、請求項２４から３３のいずれか一項に記載の方法。
35. 前記第１のメッセージを取得することは、前記ブロックチェーンから前記ブロックチェーントランザクションを取得することを含む、請求項３４に記載の方法。
36. 前記第１の署名を取得することは、前記ブロックチェーントランザクションから前記第１の署名を抽出することを含む、請求項３５に記載の方法。
37. 前記ブロックチェーントランザクションの入力は、前記第１の署名を含み、前記方法は、
    前記ブロックチェーントランザクションの前記入力によって参照される前のブロックチェーントランザクションの出力が署名検証スクリプトを含むことを検証すること
    を含む、請求項３３から３６のいずれか一項に記載の方法。
38. コンピュータ機器であって、
    １つまたは複数のメモリユニットを備えるメモリと、
    １つまたは複数の処理ユニットを備える処理装置と
    を備え、前記メモリは、前記処理装置上で実行されるように構成されたコードを記憶し、前記コードは、前記処理装置上にあるときに、請求項１から３７のいずれか一項に記載の方法を実行するように構成される、
    コンピュータ機器。
39. コンピュータ可読ストレージ上に具現化されたコンピュータプログラムであって、１つまたは複数のプロセッサ上で実行されると、請求項１から３７のいずれか一項に記載の方法を実行するように構成されたコンピュータプログラム。

Images