JP7251035B2

JP7251035B2 - 機密知識の特殊な証明を提供するシステムおよび方法

Info

Publication number: JP7251035B2
Application number: JP2022544416A
Authority: JP
Inventors: ベンヨウセフ、タレク
Original assignee: Dapper Labs Inc
Current assignee: Dapper Labs Inc
Priority date: 2020-07-30
Filing date: 2021-07-30
Publication date: 2023-04-04
Anticipated expiration: 2041-07-30
Also published as: CN115152177B; CA3158874A1; US11824990B2; EP4055773A4; CN115152177A; KR20220088956A; US20220038285A1; AU2021316961B2; EP4055773A1; US20220278844A1; AU2021316961A1; WO2022023816A1; CA3158874C; JP2023504935A; KR102537774B1; US11394550B2

Description

開示されている技術は、一般に、強化されたデータ検証および暗号署名を提供するためのシステムおよび方法に関する。

古典的な暗号署名スキームにおいて、秘密鍵は、署名者によって取り扱われる唯一の秘密データである。対応する公開鍵は、公に知られているデータである。例えば、署名エンティティは、その署名エンティティの秘密鍵を記憶し、対応する公開鍵を任意の他の当事者と共有し得る。

署名されているメッセージは、公開データであり、ちょうど署名者の秘密鍵に対応する公開鍵のように、署名を検証しているいかなる者によっても必要とされる。
検証者エンティティは、メッセージ、公開鍵およびデジタル署名が互いに対応することを検証し得る。検証プロセスは、３つのデータの整合性（すなわち、メッセージ、公開鍵、およびデジタル署名が互いに対応すること）を受け入れる（例えば、「成功」を出力する等）か、または拒否する（例えば、「失敗」を出力する等）。検証プロセスが「成功」を出力した場合、第三者は、秘密の秘密鍵の保持者によってメッセージが署名されている確率が高いと確信する。署名エンティティの秘密鍵を知らずに、そのエンティティによる有効なデジタル署名を生成することは、計算上実行不可能であるという仮定がある。検証者は、署名エンティティの識別が、秘密鍵を保有するエンティティによって達成されるという仮定に依存し得る。いくつかの例において、検証者は、商品またはサービスを、それらのデジタル的に決定された識別の仮定の下で、署名エンティティに対して提供することができる。いくつかの例において、検証者は、署名が使用されたアプリケーションに依存して、検証された情報に応答して、他のアクティビティを行うこと（例えば、署名済みの書類に関する契約／合意／アクションを承認する等）ができる。

共有されているデータを明らかにせずに、共有されているデータから生成された証明を検証するためのシステムおよび方法を提供する。

本明細書において説明されるシステムは、機密知識の特殊な証明（ＳＰｏＣＫ：ＳｐｅｃｉａｌｉｚｅｄＰｒｏｏｆｏｆＣｏｎｆｉｄｅｎｔｉａｌＫｎｏｗｌｅｄｇｅ）スキームを採用する。このスキームは、秘密鍵が依然として秘密であるが、メッセージも秘密であるシナリオを提示する。このスキームは、これらの２つの秘密データを使用して証明を生成するために、説明されるシステム内の証明者によって採用されることが可能である。いくつかの実施形態において、このスキームは、２者以上の当事者が同じ秘密（例えば、秘密メッセージ）を知っていることを示すための公的証明を、２者以上の当事者が提供することを可能にする。いくつかの実施形態において、証明を生成し、２つ以上の証明を検証するプロセスは、非インタラクティブである。いくつかの実施形態において、あらゆる証明は、その証明が証明者の秘密鍵を使用して生成されるので、証明者に対して特殊化される。いくつかの実施形態において、証明は、秘密メッセージを秘密に保ったまま、証明者によって公に明らかにされることが可能である。

証明は、特殊化されていても、または特殊化されていなくてもよい。証明は、その証明が１人の証明者ユーザに対してのみ帰属させられることが可能である場合に、「特殊化されている」。「特殊化された」証明は、証明者ユーザのみによって所有されるデータ（例えば、秘密鍵）を使用することによって生成され得る。「特殊化されていない」証明は、任意の証明者ユーザによって生成されたと主張され、特定の証明者ユーザに対して帰属させられることが可能ではない証明である。

例示的な例において、２人の証明者ユーザＡおよびＢの両方が、秘密を知っており、そのことを検証者ユーザに対して、または公に対してさえ、証明することを欲する。証明者ユーザは、秘密を公に明らかにすることができず（さもなければ、それはもはや秘密ではない）、秘密の特殊化されていない証明を共有することができない。例えば、秘密をハッシュ化し、ハッシュを共有することは、秘密を公に保護するが、任意の当事者が、ハッシュをコピーし、その任意の当事者も秘密を知っていると主張することができる。本開示のいくつかの実施形態において、証明は、その証明を生成したデバイスが、その証明者ユーザに対してのみ帰属可能であるように、生成され得る。本スキームは、２人の証明者ユーザと共に作動し得るが、本スキームは、任意の数の証明者ユーザ全てが同じ秘密を知っていることを示すために、任意の数の証明者ユーザに対して一般化されることが可能である。

一例として、いくつかの実施形態において、証明者ユーザは、秘密メッセージおよびデバイスの秘密鍵を使用して、証明（例えば、機密知識の特殊な証明）を生成してもよい。生成された証明は、１人の証明者ユーザの対応する公開鍵のみを使用して、検証者によって単独で検証されることが可能ではない。これは、メッセージが秘密であり、検証者によって知られていないからである。しかしながら、第２の秘密鍵を保持する第２の当事者（第２の証明者ユーザ）も、同じ秘密メッセージおよびこの第２の秘密鍵を使用して証明（例えば、機密知識の特殊な証明）を生成する場合、検証者は、証明者ユーザの２つの公開鍵を使用して、両方の証明が同じ秘密メッセージから生成されたかどうかを決定することができる。そのような実施形態において、検証者は、秘密メッセージの内容に対してはアクセスしないことになるが、検証プロセスが「成功」を出力した場合、検証者は、両方の証明者ユーザが同じ秘密メッセージを使用したかどうかを決定することができる。

したがって、１つの態様において、本明細書において説明されているものは、共有されているデータを明らかにせずに、共有されているデータから生成された証明を検証するためのコンピュータ実装方法である。本方法は、１つまたは複数のプロセッサによって実行される。本方法は、第１のノードから、第１のノードに関連付けられた第１の秘密鍵と、第１のノードと第２のノードとの間で共有されているデータとから生成された第１の証明を受信する工程と、第２のノードから、共有されているデータと、第２のノードに関連付けられた第２の秘密鍵とから生成された第２の証明を受信する工程と、共有されているデータを明らかにせずに、第１の証明および第２の証明が両方とも、第１の秘密鍵に数学的に関連する第１の公開鍵、および第２の秘密鍵に数学的に関連する第２の公開鍵を用いて、共有されているデータから生成されたことを検証する工程と、第１の証明および第２の証明が両方とも、共有されているデータから生成されたという検証に基づいて、アクションを行う工程とを備える。いくつかの実施形態において、第１の証明および第２の証明は、それぞれ第１のノードおよび第２のノードによって公に明らかにされる。いくつかの実施形態において、アクションは、第１の証明および第２の証明が両方とも、共有されているデータから生成されたという検証を公に明らかにする工程を備える。いくつかの実施形態において、第１の証明は、第１のノードに対してのみ帰属可能である。いくつかの実施形態において、第２の証明は、第２のノードに対してのみ帰属可能である。いくつかの実施形態において、第１の証明または第２の証明は、それぞれの公開鍵のみを用いて検証されることが可能ではない。いくつかの実施形態において、第１の証明および第２の証明は各々、それぞれの秘密鍵を用いて生成された共有されているデータの署名を備える。いくつかの実施形態において、署名は、ＢＬＳ署名スキームに基づく。いくつかの実施形態において、第１の証明および第２の証明の検証は、２つの署名、第１の公開鍵、および第２の公開鍵に基づいたペアリング同等性チェックを備える。いくつかの実施形態において、第１の証明および第２の証明を検証する工程は、ペアリング同等性チェックを備える。いくつかの実施形態において、第１の証明および第２の証明は、非インタラクティブなプロトコルにおいて生成され、検証される。いくつかの実施形態において、共有されているデータは、ブロックチェーン内のブロックの少なくとも１つのトランザクションの実行を証明する実行トレースを備える。いくつかの実施形態において、第１のノードは、実行ノードの計算の正確性を保証するために採用される検証ノードを備える。いくつかの実施形態において、計算は、実行トレースを備える。いくつかの実施形態において、第２のノードは、ブロックの少なくとも１つのトランザクションを実行するために採用される実行ノードを備える。いくつかの実施形態において、検証ノードは、計算が検証されたという証明として、第１の証明をパブリッシュする。いくつかの実施形態において、アクションは、クライアントに対して状態応答を提供する工程を備え、状態応答は、ブロックについての出力に基づいて決定される。いくつかの実施形態において、計算は、並行で独立した手法で、より軽量化された計算検証を可能にするために、チャンクへと分けられる。いくつかの実施形態において、アクションは、チャンクの各々が、実行ノードおよび検証ノードによって、同じ中間結果から整合して生成されることを調停する工程を備える。

別の態様において、本明細書において説明されるものは、共有されているデータを明らかにせずに、共有されているデータから生成された証明を検証するためのシステムである。これらのシステムは、１つまたは複数のプロセッサと、１つまたは複数のプロセッサに対して結合され、命令が記憶されたコンピュータ可読記憶デバイスであって、命令は、１つまたは複数のプロセッサによって実行された場合、１つまたは複数のプロセッサに、動作を行わせる、コンピュータ可読記憶デバイスとを備える。これらの動作は、第１のノードから、第１のノードに関連付けられた第１の秘密鍵と、第１のノードと第２のノードとの間で共有されているデータとから生成された第１の証明を受信する工程と、第２のノードから、共有されているデータと、第２のノードに関連付けられた第２の秘密鍵とから生成された第２の証明を受信する工程と、共有されているデータを明らかにせずに、第１の証明および第２の証明が両方とも、第１の秘密鍵に数学的に関連する第１の公開鍵、および第２の秘密鍵に数学的に関連する第２の公開鍵を用いて、共有されているデータから生成されたことを検証する工程と、第１の証明および第２の証明が両方とも、共有されているデータから生成されたという検証に基づいて、アクションを行う工程とを備える。いくつかの実施形態において、第１の証明および第２の証明は、それぞれ第１のノードおよび第２のノードによって公に明らかにされる。いくつかの実施形態において、アクションは、第１の証明および第２の証明が両方とも、共有されているデータから生成されたという検証を明らかにする工程を備える。いくつかの実施形態において、第１の証明は、第１のノードに対してのみ帰属可能である。いくつかの実施形態において、第２の証明は、第２のノードに対してのみ帰属可能である。いくつかの実施形態において、第１の証明または第２の証明は、それぞれの公開鍵のみを用いて検証されることが可能ではない。いくつかの実施形態において、第１の証明および第２の証明は各々、それぞれの秘密鍵を用いて生成された共有されているデータの署名を備える。いくつかの実施形態において、署名は、ＢＬＳ署名スキームに基づく。いくつかの実施形態において、第１の証明および第２の証明の検証は、２つの署名、第１の公開鍵、および第２の公開鍵に基づいたペアリング同等性チェックを備える。いくつかの実施形態において、第１の証明および第２の証明を検証する工程は、ペアリング同等性チェックを備える。いくつかの実施形態において、第１の証明および第２の証明は、非インタラクティブなプロトコルにおいて生成され、検証される。いくつかの実施形態において、共有されているデータは、ブロックチェーン内のブロックの少なくとも１つのトランザクションの実行を証明する実行トレースを備える。いくつかの実施形態において、第１のノードは、実行ノードの計算の正確性を保証するために採用される検証ノードを備える。いくつかの実施形態において、計算は、実行トレースを備える。いくつかの実施形態において、第２のノードは、ブロックの少なくとも１つのトランザクションを実行するために採用される実行ノードを備える。いくつかの実施形態において、検証ノードは、計算が検証されたという証明として、第１の証明をパブリッシュする。いくつかの実施形態において、アクションは、クライアントに対して状態応答を提供する工程を備え、状態応答は、ブロックについての出力に基づいて決定される。いくつかの実施形態において、計算は、並行で独立した手法で、より軽量化された計算検証を可能にするために、チャンクへと分けられる。いくつかの実施形態において、アクションは、チャンクの各々が、実行ノードおよび検証ノードによって、同じ中間結果から整合して生成されることを調停する工程を備える。

別の態様において、本明細書において説明されるものは、１つまたは複数のプロセッサに対して結合され、命令が記憶された非一時的なコンピュータ可読記憶媒体であって、命令は、１つまたは複数のプロセッサによって実行された場合、１つまたは複数のプロセッサに、動作を行わせる、非一時的なコンピュータ可読記憶媒体である。これらの動作は、第１のノードから、第１のノードに関連付けられた第１の秘密鍵と、第１のノードと第２のノードとの間で共有されているデータとから生成された第１の証明を受信する工程と、第２のノードから、共有されているデータと、第２のノードに関連付けられた第２の秘密鍵とから生成された第２の証明を受信する工程と、共有されているデータを明らかにせずに、第１の証明および第２の証明が両方とも、第１の秘密鍵に数学的に関連する第１の公開鍵、および第２の秘密鍵に数学的に関連する第２の公開鍵を用いて、共有されているデータから生成されたことを検証する工程と、第１の証明および第２の証明が両方とも、共有されているデータから生成されたという検証に基づいて、アクションを行う工程とを備える。いくつかの実施形態において、第１の証明および第２の証明は、それぞれ第１のノードおよび第２のノードによって公に明らかにされる。いくつかの実施形態において、アクションは、第１の証明および第２の証明が両方とも、共有されているデータから生成されたという検証を公に明らかにする工程を備える。いくつかの実施形態において、第１の証明は、第１のノードに対してのみ帰属可能である。いくつかの実施形態において、第２の証明は、第２のノードに対してのみ帰属可能である。いくつかの実施形態において、第１の証明または第２の証明は、それぞれの公開鍵のみを用いて検証されることが可能ではない。いくつかの実施形態において、第１の証明および第２の証明は各々、それぞれの秘密鍵を用いて生成された共有されているデータの署名を備える。いくつかの実施形態において、署名は、ＢＬＳ署名スキームに基づく。いくつかの実施形態において、第１の証明および第２の証明の検証は、２つの署名、第１の公開鍵、および第２の公開鍵に基づいたペアリング同等性チェックを備える。いくつかの実施形態において、第１の証明および第２の証明を検証する工程は、ペアリング同等性チェックを備える。いくつかの実施形態において、第１の証明および第２の証明は、非インタラクティブなプロトコルにおいて生成され、検証される。いくつかの実施形態において、共有されているデータは、ブロックチェーン内のブロックの少なくとも１つのトランザクションの実行を証明する実行トレースを備える。いくつかの実施形態において、第１のノードは、実行ノードの計算の正確性を保証するために採用される検証ノードを備える。いくつかの実施形態において、計算は、実行トレースを備える。いくつかの実施形態において、第２のノードは、ブロックの少なくとも１つのトランザクションを実行するために採用される実行ノードを備える。いくつかの実施形態において、検証ノードは、計算が検証されたという証明として、第１の証明をパブリッシュする。いくつかの実施形態において、アクションは、クライアントに対して状態応答を提供する工程を備え、状態応答は、ブロックについての出力に基づいて決定される。いくつかの実施形態において、計算は、並行で独立した手法で、より軽量化された計算検証を可能にするために、チャンクへと分けられる。いくつかの実施形態において、アクションは、チャンクの各々が、実行ノードおよび検証ノードによって、同じ中間結果から整合して生成されることを調停する工程を備える。

別の態様において、本明細書において説明されるものは、共有されているデータを明らかにせずに、共有されているデータから生成された証明を検証するためのシステムである。これらのシステムは、１つまたは複数のプロセッサと、１つまたは複数のプロセッサに対して結合され、命令が記憶されたコンピュータ可読記憶デバイスであって、命令は、１つまたは複数のプロセッサによって実行された場合、１つまたは複数のプロセッサに、動作を行わせる、コンピュータ可読記憶デバイスとを備える。これらの動作は、複数のノードの各々から、ノード間で共有されているデータと、各ノードに関連付けられたそれぞれの秘密鍵とから生成されたそれぞれの証明を受信する工程と、共有されているデータを明らかにせずに、証明の各々が、秘密鍵のうちの個別の１つに各々が数学的に関連する複数の公開鍵を用いて、共有されているデータから生成されたことを検証する工程と、証明が、共有されているデータから生成されたという検証に基づいて、アクションを行う工程とを備える。いくつかの実施形態において、証明の各々は、それらのそれぞれのノードによって公に明らかにされる。いくつかの実施形態において、アクションは、第１の証明および第２の証明が両方とも、共有されているデータから生成されたという検証を公に明らかにする工程を備える。いくつかの実施形態において、証明の各々は、それぞれの生成ノードに対してのみ帰属可能である。いくつかの実施形態において、証明の各々は、それぞれの公開鍵のみを用いて検証されることが可能ではない。いくつかの実施形態において、証明は各々、それぞれの秘密鍵を用いて生成された、共有されているデータの署名を備える。いくつかの実施形態において、証明の検証は、署名および公開鍵に基づいたペアリング同等性チェックを備える。いくつかの実施形態において、証明を検証する工程は、ペアリング同等性チェックを備える。いくつかの実施形態において、証明は、非インタラクティブなプロトコルにおいて生成され、検証される。いくつかの実施形態において、共有されているデータは、ブロックチェーン内のブロックの少なくとも１つのトランザクションの実行を証明する実行トレースを備える。

別の態様において、本明細書において説明されるものは、共有されているデータを明らかにせずに、共有されているデータから生成された証明を検証するためのコンピュータ実装方法である。本方法は、１つまたは複数のプロセッサによって実行される。本方法は、複数のノードの各々から、ノード間で共有されているデータと、各ノードに関連付けられたそれぞれの秘密鍵とから生成されたそれぞれの証明を受信する工程と、共有されているデータを明らかにせずに、証明の各々が、秘密鍵のうちの個別の１つに各々が数学的に関連する複数の公開鍵を用いて、共有されているデータから生成されたことを検証する工程と、証明が、共有されているデータから生成されたという検証に基づいて、アクションを行う工程とを備える。いくつかの実施形態において、証明の各々は、それらのそれぞれのノードによって公に明らかにされる。いくつかの実施形態において、アクションは、第１の証明および第２の証明が両方とも、共有されているデータから生成されたという検証を公に明らかにする工程を備える。いくつかの実施形態において、証明の各々は、それぞれの生成ノードに対してのみ帰属可能である。いくつかの実施形態において、証明の各々は、それぞれの公開鍵のみを用いて検証されることが可能ではない。いくつかの実施形態において、証明は各々、それぞれの秘密鍵を用いて生成された、共有されているデータの署名を備える。いくつかの実施形態において、証明の検証は、署名および公開鍵に基づいたペアリング同等性チェックを備える。いくつかの実施形態において、証明を検証する工程は、ペアリング同等性チェックを備える。いくつかの実施形態において、証明は、非インタラクティブなプロトコルにおいて生成され、検証される。いくつかの実施形態において、共有されているデータは、ブロックチェーン内のブロックの少なくとも１つのトランザクションの実行を証明する実行トレースを備える。

別の態様において、本明細書において説明されるものは、１つまたは複数のプロセッサに対して結合され、命令が記憶された非一時的なコンピュータ可読記憶媒体であって、命令は、１つまたは複数のプロセッサによって実行された場合、１つまたは複数のプロセッサに、動作を行わせる、非一時的なコンピュータ可読記憶媒体である。これらの動作は、複数のノードの各々から、ノード間で共有されているデータと、各ノードに関連付けられたそれぞれの秘密鍵とから生成されたそれぞれの証明を受信する工程と、共有されているデータを明らかにせずに、証明の各々が、秘密鍵のうちの個別の１つに各々が数学的に関連する複数の公開鍵を用いて、共有されているデータから生成されたことを検証する工程と、証明が、共有されているデータから生成されたという検証に基づいて、アクションを行う工程とを備える。いくつかの実施形態において、証明の各々は、それらのそれぞれのノードによって公に明らかにされる。いくつかの実施形態において、アクションは、第１の証明および第２の証明が両方とも、共有されているデータから生成されたという検証を公に明らかにする工程を備える。いくつかの実施形態において、証明の各々は、それぞれの生成ノードに対してのみ帰属可能である。いくつかの実施形態において、証明の各々は、それぞれの公開鍵のみを用いて検証されることが可能ではない。いくつかの実施形態において、証明は各々、それぞれの秘密鍵を用いて生成された、共有されているデータの署名を備える。いくつかの実施形態において、証明の検証は、署名および公開鍵に基づいたペアリング同等性チェックを備える。いくつかの実施形態において、証明を検証する工程は、ペアリング同等性チェックを備える。いくつかの実施形態において、証明は、非インタラクティブなプロトコルにおいて生成され、検証される。いくつかの実施形態において、共有されているデータは、ブロックチェーン内のブロックの少なくとも１つのトランザクションの実行を証明する実行トレースを備える。いくつかの実施形態において、証明の検証の数は、ノードの数において線形であり、二次関数的ではない。いくつかの実施形態において、証明を検証する工程は、ノードの数よりも１つ少ない検証を必要とする。

本開示による方法は、本明細書において説明される態様および特徴の任意の組み合わせを含むことができることが認識される。すなわち、本開示による方法は、本明細書において特に説明される態様および特徴の組み合わせに限定されず、提供される態様および特徴の任意の組み合わせを含んでもよい。

本開示の１つまたは複数の実施形態の詳細は、添付の図面および以下の説明において記載されている。本開示の他の特徴および利点は、説明および図面から、ならびに特許請求の範囲から、明らかになるであろう。本概要は、本明細書において説明されるいかなる発明の範囲も限定するようには意図されておらず、発明の範囲は、本明細書に添付された特許請求の範囲によってのみ定義される。

１つまたは複数の様々な実施形態による、本明細書において開示されている技術は、以下の図を参照して詳細に説明される。図面は、例示の目的のためにのみ提供されており、開示されている技術の典型的な実施形態または例示的な実施形態を描くに過ぎない。これらの図面は、開示されている技術についての読者の理解を容易にするために提供されており、開示されている技術の広さ、範囲、または適用可能性を限定するものとして考慮されるべきではない。例示の明瞭さおよび簡単さのために、これらの図面は必ずしも縮尺通りに作られているとは限らないことが留意されるべきである。

本開示の様々な実施形態において例示されるような、分散型台帳および／またはブロックチェーン・システムを例示する図。本開示の実装を実行するために採用されることが可能である非限定的な例示的な環境を描く図。説明されるシステムのための非限定的な例示的なアーキテクチャを描く図。スキームの様々な特性を説明する非限定的な例示的なフロー図を描く図。スキームの様々な特性を説明する非限定的な例示的なフロー図を描く図。スキームの様々な特性を説明する非限定的な例示的なフロー図を描く図。スキームの様々な特性を説明する非限定的な例示的なフロー図を描く図。本明細書において説明されるシステムの実施形態によって実装されることが可能である非限定的な例示的なプロセスを描く図。本明細書において説明されるシステムの実施形態によって実装されることが可能である非限定的な例示的なプロセスを描く図。本開示の方法またはシステムを実装するようにプログラムされること、または他の方法で構成されることが可能である非限定的な例示的なコンピュータ・システムを描く図。

図は、網羅的であるように、または本発明をまさに開示されている形態に限定するようには意図されていない。本発明は、修正および改変と共に実施されることが可能であること、ならびに開示されている技術は、特許請求の範囲およびその均等物によってのみ限定されることが、理解されるべきである。

特に定義されない限り、本明細書において使用される全ての専門用語は、本主題が属する技術分野における当業者によって一般に理解されるのと同じ意味を有する。本明細書および添付の特許請求の範囲において使用される場合、単数形の「ａ」、「ａｎ」、および「ｔｈｅ」は、文脈がそうでないことを明確に指示しない限り、複数形の参照を含む。本明細書における「または」へのいかなる言及も、特に明記されない限り、「および／または」を包含するように意図される。

本明細書において使用される場合、「リアルタイム」という用語は、システムの処理限界、データおよび画像を正確に取得するために必要とされる時間、ならびにデータおよび画像の変化率を考慮して、意図的な遅延なしに、データを送信することまたは処理することを指す。いくつかの例において、「リアルタイム」は、本開示の実施形態の構成要素から取得された情報の提示を説明するために使用される。

本明細書において、「スマート契約」という用語は、デジタル化された環境内の計算イベントおよびアクションを自動的に実行すること、制御すること、または文書化することができるコンピュータ実装命令のセットを指す。いくつかの例において、計算は、計算デバイスのブロックチェーンまたは分散型台帳上で行われ得る。スマート契約の実装は、ブロックチェーン・ネットワーク上で暗号的に署名されたトランザクションを使用して展開され得る。いくつかの例において、スマート契約は、合意の規則およびペナルティーに関連するコンピュータ実装命令のセットを実装する。スマート契約は、これを、情報を入力として扱い、スマート契約において明記された規則を通じて、その入力に対して値を割り当て、それらの規則によって必要とされるコンピュータ実装アクションを自己実行することによって、達成し得る。例えば、スマート契約は、資産が送信先エンティティへ送られるべきかどうか、または資産が送信元エンティティへ返されるべきかどうかを決定し得る。

例示的な例として、スマート契約は、アイテムが受信された場合に支払いを行うようにプログラムされてもよい。このフォーマットにおいて、スマート契約は、コンピュータ・コードとして生成され、システム上（例えば、ブロックチェーンまたは分散型台帳内等）に記憶および複製され、ブロックチェーンを運用するコンピュータのネットワークによって監督され得る。スマート契約は、データを記憶することができる。記憶されたデータは、現実世界の契約のためのロジックを実装するために必要とされる情報、事実、関連付け、残高および任意の他の情報を記録するために使用されることが可能である。いくつかの実施形態において、スマート契約は、バーチャル・マシン内で展開され、記憶され、および実行される。

本明細書において使用される場合、「構成可能性」という用語は、構成要素の相互関係を扱うシステム設計原理を含む。例えば、高度に構成可能なシステムは、特定のユーザ要件を満たすために、様々な組み合わせにおいて選択され、組み立てられることが可能である構成要素を提供する。ブロックチェーンおよびスマート契約のコンテキストにおいて、構成可能性は、複数の独立したスマート契約に関与する動作を共にチェーン化するための能力を含む。構成可能性の最近の例は、ｄＹ／ｄＸであり、ｄＹ／ｄＸは、イーサリアム・ブロックチェーン上に構築される金融派生商品のための分散型プロトコルである。ｄＹ／ｄＸは、担保付き融資を可能にすることによって分散型マージン取引を可能にする。典型的なｄＹ／ｄＸトランザクションは、少なくとも３つの別個のスマート契約、すなわち、コアｄＹ／ｄＸ契約自体と、０ｘのような分散型取引と、ＤＡＩなどの、少なくとも１つのイーサリアムＥＲＣ（ＲｅｑｕｅｓｔｆｏｒＣｏｍｍｅｎｔ）２０トークンとを組み合わせる。

本明細書において使用される場合、「シャーディング」という用語は、一般に、ネットワークを非同期的に相互作用する一連のサブユニットに分割する多種多様なスケーリング提案を指す。本概念は、データベースをよりスケーラブルにするために、データベースにおいて広く使用されてきた。より最近では、シャーディングは、ブロックチェーンにおけるトランザクション速度を改善するために、ブロックチェーンに対して採用されてきた。データベース・コンテキストにおいて、例えば、シャーディングは、データベース内のデータを水平にパーティション化するための方法を含み得る。より一般に、データベースは、「シャード」と呼ばれる小さな部分に分けられており、これらの小さな部分は、共にアグリゲートされた場合に、元のデータベースを形成する。分散型ブロックチェーン・ネットワークにおいて、ネットワークは、中央管理者なしで、ピア・ツー・ピア・フォーマットにおいて接続された一連のノードから成る。ブロックチェーン・システムのいくつかの例において、各ノードは、ネットワークの全ての状態を記憶し、トランザクションの全てを処理する。これは、特に、ビットコインおよびイーサリアム（登録商標）などのプルーフ・オブ・ワーク（ＰｏＷ）・システムにおいて、分散化を通じて高度なセキュリティを提供するが、適法なスケーリング問題につながることがある。例えば、イーサリアム・ネットワーク内のフルノードは、口座残高、ストレージ、および契約コードを含む、ブロックチェーンの全状態を記憶する。残念なことに、参加者の数が線形的に増加するにつれて、参加者間の相互通信オーバーヘッドは、指数関数的な速度で増加する。この限界は、コンセンサスに到達するために必要とされる、ノード間で必要とされる通信に起因する。ネットワーク内のノードは、特別な権限を有しておらず、ネットワーク内のあらゆるノードが、あらゆるトランザクションを記憶し、処理する。結果として、イーサリアムのサイズのネットワークにおいて、高価なガス代およびより長いトランザクション確認時間などの問題は、ネットワークに負担がかかっている場合に、顕著な問題になる。ネットワークは、その部分の総和ではなく、個々のノードと同じくらいの速さであるに過ぎない。そのため、シャーディングは、これらの問題点を緩和するために役立つ。本概念は、ノードのサブセットをシャードへとグループ化することに関与し、シャードは、次に、そのシャードに固有のトランザクションを処理する。このタイプのアーキテクチャの採用は、システムが多くのトランザクションを並行して処理することを可能にする。

本明細書において使用される場合、「コンセンサス・アルゴリズム」または「コンセンサス・プロトコル」という用語は、ノードなどの電子デバイス間でデータの通信および送信がどのように作動するのかを説明する規則のセットを含む。何が真であり、何がブロックチェーン上に記録されなければならないかについて、十分なデバイスが合意している場合、コンセンサスが達成される。したがって、コンセンサス・プロトコルは、世界中に点在されているデバイスが事実上合意に達することを可能にする管理規則であり、ブロックチェーン・ネットワークが破損されることなく機能することを可能にする。

本明細書において使用される場合、「ビザンチン・フォールト・トレランス（ＢＦＴ）・コンセンサス・アルゴリズム」という用語は、分散型システムのコンテキストにおいて、分散型コンピュータ・ネットワーク、例えば、説明されるシステム内のノードのピア・ツー・ピア・ネットワークなどが、望み通りに機能するための、および、そのシステムの悪意ある構成要素（ノード）が障害を起こしたり、または不正確な情報を他のピアへ伝播したりするにもかかわらず、十分なコンセンサスに正確に到達するための能力を含む。その目的は、これらの悪意あるノードが、ネットワークの正確な機能に対して、およびシステム内の誠実なノードによって到達される正しいコンセンサスに対して有する影響を軽減することによって、壊滅的なシステム障害を防ぐことである。

本明細書において使用される場合、「スラッシュ（ｓｌａｓｈ）」という用語は、例えばネットワーク参加者を、ネットワークについて明記された規則に従わないことについて罰することである。罰は、エスクローに預託された、または出資された資金に対して適用される罰金の形態であり得る。

本明細書において使用される場合、当事者（例えば、ノード）間の「インタラクティブなプロトコル」という用語は、当事者が（例えば、質問および回答を通じた）一種の対話においてメッセージを交換する制約を含む。いくつかの実施形態において、メッセージのこの交換は、メッセージを送るために、および受信するために、何らかの形態の同期を必要とする。

本明細書において使用される場合、当事者（例えば、ノード）間の「非インタラクティブなプロトコル」という用語は、当事者の各々が、他者を待たずに、アクションを行うことを可能にする。説明されるシステムのいくつかの実施形態において、ノードは、証明を単独で生成し、その他のノードのいずれからの入力も必要としない。同様に、説明されるシステムのいくつかの実施形態において、検証は、ユーザの最初の証明のみで十分であるので、ユーザとのさらなる議論を必要としない。

図１は、本開示の様々な実施形態において例示されるような、分散型台帳および／またはブロックチェーン・システムを例示する。分散型台帳は、１つまたは複数のコンピューティング・デバイス１０２、１０４、１０６、１０８と、ネットワーク１１０とを備えてもよく、これらは、ピア・ツー・ピア・ネットワークを形成するために使用され得る。いくつかの実施形態において、ネットワーク１１０は、ローカル・エリア・ネットワーク（ＬＡＮ）、広域ネットワーク（ＷＡＮ）、インターネット、または、これらの組み合わせを含み、デバイス（例えば、コンピューティング・デバイス１０２、１０４、１０６、１０８）を接続する。いくつかの実施形態において、ネットワーク１１０は、イントラネット、エクストラネット、または、インターネットと通信するイントラネットもしくはエクストラネットを含む。いくつかの実施形態において、ネットワーク１１０は、通信ネットワークまたはデータネットワークを含む。いくつかの実施形態において、ネットワーク１１０は、有線通信リンクまたは無線通信リンク上でアクセスされることが可能である。

分散型台帳（例えば、ブロックチェーン）は、操作に対するチェックを保つための中央管理者の必要を除去した、異なるロケーションおよび人々にわたって分散された形態で維持される任意のトランザクションまたは契約の台帳として説明されることが可能である。台帳上の全ての情報は、暗号技術を使用してセキュアにかつ正確に記憶され、鍵および暗号署名を使用してアクセスされることが可能である。いったん情報が記憶されると、情報は、ネットワークの規則が管理する不変データベースになる。分散型台帳は、攻撃を成功させるためには、全ての分散されたコピーが同時に攻撃される必要があるので、例えば集中型台帳よりも攻撃することが本質的により困難である。さらに、これらの記録は、単独の当事者による悪意のある変更に対して耐性がある。

効率は、ブロックチェーン空間において観察される２つの実質的な問題に対処する多面的な柱である。第１のものは、プルーフ・オブ・ワーク（ＰｏＷ）であり、ＰｏＷは、その過度な電力の使用および非能率的なリソース割り当てについて、一貫して非難されている。ＰｏＷは、システムをセキュアにするためのオプションとして拒否されている。第２の問題は、たとえ全てのノードがＰｏＷ問題を解決しなくても、全てのノードが全ての状態を保持することを依然として必要とする、プルーフ・オブ・ステーク（ＰｏＳ）ベースのシステムにおいてさえ、ブロックチェーンが動作するために必要とする著しい量の複製労力である。従来のブロックチェーンにおいて、例えば、各ノードは、ブロック製造に関連付けられたあらゆるタスクを行い得る。この複製は、規模についてのネックであるだけではなく、リソースのそれぞれの強みに対して適用されればより良く役割を果たすであろうリソースの不十分な割り当てである。

さらに、自律的で相互運用可能なソフトウェアのエコシステムの長期的な価値は、分散型革命の最も説得力のある成果として実際には位置し得るので、ブロックチェーン技術は、無許可の自律的なソフトウェア・システムを作成し得る。オープンで、消費者規模のブロックチェーン・システムに対する既存の提案の圧倒的多数は、何らかの種類のシャーディングに依存する。シャーディングに対する様々なアプローチは、ネットワークが取り扱うことができるトランザクションの数を適法に増加させ得るが、それらのアプローチは、それらのトランザクションの能力を限定し得る。特に、各トランザクションは、それ自体のシャード内の情報を読み出し、修正することができるに過ぎない。いくつかのシャード化されたブロックチェーン実装において、他のシャードとの通信は、高価で複雑なロッキング動作なしに、非同期的に発生しなければならず、古い情報に基づいて行動するリスクがある。さらに、シャード化されたブロックチェーンに対する既存の提案は、単独のアトミック・トランザクションが複数のシャードと相互作用するための能力を提供しない。例えば、別個のトランザクションは、各シャード上で発行されることがあり、アトミシティ保証が必要とされる場合（例えば、価値の何らかの相互交換がある場合）、ブロックチェーンの上に構築された何らかの種類の複雑なロッキングおよびコミットメントシステムがあり得る。

例示的な分散型台帳は、一般に知られているブロックチェーンである。ブロックチェーンは、例示の目的のために、本開示内で参照される。しかしながら、任意の適当な分散型台帳が本開示の実装において使用されることが可能であることが予期される。ブロックチェーンは、暗号技術を使用してリンクされ、セキュアにされる記録またはブロックの連続的に増加し続けるリストである。ブロックチェーン内の各ブロックは、１つまたは複数のコンテキストにおいて実行されたトランザクション、例えば、有価証券トランザクション、デジタル通貨トランザクション等など、から提供されるトランザクションデータを含んでもよい。いくつかの例において、トランザクションは、現在または将来のいずれかにおいて、通貨、暗号通貨または何らかの他の資産の代わりに、資産、製品またはサービスの交換があるであろうという、バイヤーおよびセラー、サプライヤーおよび消費者、またはプロバイダおよび消費者の間の合意を含む。いくつかの例において、単独のブロックは、複数のトランザクション（例えば、異なる人々による異なる小切手の複数の預け入れ）から提供されるトランザクションデータを含み得る。完了されたブロックにトランザクションの新しいセットが追加されるにつれて、ブロックチェーンは成長し、したがって、トランザクションの台帳を形成し得る。各ブロックは、恒久的な手法でトランザクションデータと共に過去のブロックに対するハッシュ・ポインタおよびタイムスタンプを含み得る。

いくつかの実施形態において、ブロックチェーンのブロック内のトランザクションは、ハッシュ化され、マークル・ツリーへと符号化される（例えば、トランザクションは、マークル・ツリーのリーフ・ノードである）。マークル・ツリー（またはハッシュ・ベースのツリー）は、ハッシュ・リストの一般化であり得るハッシュ・ベースのデータ構造である。マークル・ツリーは、各リーフ・ノードが、ハッシュ値または「ハッシュ」を生成するためにトランザクションに対して適用された暗号ハッシュ関数（ＣＨＦ）の結果であり、各非リーフ・ノードに、その子ノードのラベルの暗号ハッシュがラベル付けされる、ツリー構造を含む。例示的なＣＨＦは、セキュア・ハッシュ・アルゴリズム２５６（ＳＨＡ－２５６）、ＳＨＡ－３、およびメッセージ・ダイジェスト５（ＭＤ５）を特に含む。一般に、ＣＨＦは、入力として情報を受信し、出力としてハッシュ値を提供する。ハッシュ値は、所定の長さとすることができる。例えば、ＳＨＡ－２５６は、２５６ビット（３２バイト、６４文字）のハッシュ値を出力する。いくつかの例において、ハッシュ値は、入力が何であったかを決定するために、ハッシュ値が「非ハッシュ化される」ことが可能ではないという点で、一方向ハッシュ値である。また、マークル・ツリーは、ｋ次元ツリーとして実装されてもよく、ｋ次元ツリーは、各ノードがｋ個以下の子を有するルート付きツリー・データ構造である。例えば、マークル・ツリーは、各ノードが、０個、１個、または２個の子を有し得るバイナリ・ツリーとして実装されてもよい。そのようなバイナリ・ツリーのマークル・ルート（またはルート・ハッシュ）は、１つのハッシュのみが残るまで、ノードの各ペアを繰り返しハッシュ化することによって生成されることが可能である。いくつかの例において、トランザクションの数が奇数である場合、最後のハッシュは、偶数個のリーフ・ノードを作成するために、一度複製され得る。トランザクションのいずれかにおける単一の詳細またはトランザクションの順序が変化する場合、マークル・ルートも変化する。そのため、マークル・ルートは、関連するトランザクションにおける全てのデータを要約し、データの完全性を維持するためにブロック内に記憶されることが可能である。したがって、マークル・ツリーの採用は、特定のトランザクションがセット内に含まれるか否かについての迅速かつ単純なテストを可能にする。

一般に、ブロックは、ブロックチェーン・プロトコルを実行する相互接続されたコンピューティング・デバイスのピア・ツー・ピア・ネットワーク内の１つまたは複数のコンピューティング・デバイスによって線形の経時的な順序でブロックチェーンに対して追加される。つまり、ピア・ツー・ピア・ネットワークは、複数の相互接続されたノードとして説明されることが可能であり、各ノードは、トランザクション（例えば、小切手の預け入れ）の有効性を確認し、リレーするためにクライアントを使用するコンピューティング・デバイスである。各ノードは、ブロックチェーンのコピーを維持し、ブロックチェーンのコピーは、ピア・ツー・ピア・ネットワークへの参加時にノードに対して自動的にダウンロードされる。ブロックチェーン・プロトコルは、ブロックチェーンを更新するセキュアで信頼できる方法を提供し、そのコピーは、中央管理者を使用せずに、ピア・ツー・ピア・ネットワークにわたって分配される。

ブロックチェーン・ネットワーク上の全てのエンティティが、要求されたトランザクションの有効性を確認するために、全ての過去のトランザクション（例えば、預け入れ、引き出し等）を知る必要があり得るので、エンティティは、どのトランザクションがどの順序で実際に発生したのかについて合意し得る。例えば、２つのエンティティが、異なるトランザクション履歴を観察した場合、それらのエンティティは、トランザクションの有効性に関して同じ結論に達することができないことがある。ブロックチェーンは、既に発生したトランザクション、およびどの順序で発生したかに関して、エンティティが合意に達することを可能にする。つまり、および以下でさらに詳細に説明されるように、トランザクションの台帳は、トランザクションをトランザクションの台帳に追加する（例えば、ブロックをブロックチェーンに追加する）ために必要とされる作業の量に基づくように合意される。このコンテキストにおいて、作業は、ピア・ツー・ピア・ネットワーク内の任意の単独のノード（例えば、コンピューティング・デバイス）にとって迅速に完了することは困難だが、ノード（例えば、コンピューティング・デバイス）にとって検証することは比較的簡単なタスクである。

典型的なピア・ツー・ピア・ネットワークは、ブロックチェーン・プロトコルに基づいてブロックをブロックチェーンに追加する、いわゆるマイナー（例えば、コンピューティング・デバイス）を含み得る。一般に、複数のマイナーは、ブロックに追加されるべきトランザクションの有効性を確認し、それらのブロックをブロックチェーンに対して追加させるために競合する（例えば、上記で紹介されたように、作業を行う）。トランザクションの有効性確認は、それぞれのトランザクションに関連付けられたデジタル署名を検証することを含み得る。ブロックがブロックチェーンに対して追加されるためには、マイナーは、トランザクションのそれらの提供されるブロックがピア・ツー・ピア・ネットワークによって受け入れられる前に、ＰｏＷを明示しなければならない。ブロックチェーン・プロトコルは、ＣＨＦに基づくＰｏＷスキームを含む。いくつかの実施形態において、ブロックチェーン・プロトコルは、ＣＨＦへの入力として、複数の情報を必要とすることがある。例えば、ＣＨＦへの入力は、ブロックチェーン内の過去の（最も最近の）ブロックへの参照、作成されるべきブロックに含まれるべきトランザクションの詳細、およびノンス値を含むことができる。

複数のノードは、トランザクションのセットをハッシュ化し、ブロックチェーンに対して追加されるべき次のブロックを提供するために競合し得る。ブロックチェーン・プロトコルは、ブロックチェーンに対して追加されるべきブロックを認定するために閾値ハッシュを提供し得る。例えば、閾値ハッシュは、ハッシュ値が最初に有しなければならないゼロ（０）の予め定義された数を含むことができる（例えば、ハッシュ値の少なくとも最初の４文字は各々０でなければならない）。ゼロの数が多いほど、認定ハッシュ値に到達するのに、より多くの時間を消費する。

いくつかのブロックチェーン・ベースのプラットフォームにおいて、例えば、ブロックを製造する各ノードは、候補ブロックを作成するために複数の工程を経験し得る。例えば、複数のトランザクションが、保留中のトランザクションの公に共有されるプールから選択される。いくつかの実施形態において、選択されたトランザクションは、例えば、線形リスト内の順序で割り当てられる。典型的には、含まれることが可能なトランザクションの最大数を限定するための何らかの機構がある。しかしながら、多くの実施形態において、強制される最小値はない。トランザクションによって特定された計算が行われる。いくつかの実施形態において、各計算は、グローバル共有状態にアクセスすることができ、その共有状態に対する一定の変更を行うことができる。さらに、いくつかの実施形態において、あるトランザクションの入力は、別のトランザクションの出力に依存し得る。そのような実施形態においては、これらの計算が、順番に厳密に行われることが重要である。トランザクションは、それらのトランザクションの処理から結果として得られる最終的なカノニカル状態のスナップショットと組み合わされ得る。結果は、ネットワークの残りの部分へブロードキャストされる。いくつかの実施形態において、「スナップショット」は、カノニカル状態のハッシュであり、例えば、マークル・ツリーのルート・ノードの形態とすることができる。

いくつかの実施形態において、候補ブロックを受信するネットワーク内の各ノードは、トランザクション・リストによって示唆された計算が正確に計算されたことを確認する。これらのノードは、候補ブロックによって特定された順序で計算の各々を繰り返し得る。次いで、ノードは、それらが計算した最終的なカノニカル状態のスナップショットを、元のノードからの候補ブロックにおけるスナップショットと比較する。スナップショットが一致した場合、ブロックは、有効な候補と考慮され得る。

ビットコインなどの、未使用のトランザクション出力（ＵＴＸＯ：ｕｎｓｐｅｎｔｔｒａｎｓａｃｔｉｏｎｏｕｔｐｕｔ）ブロックチェーンにおいては、トークンの転送に成功したトランザクションのみが、ブロックに含まれることが可能である。他方で、イーサリアムのように、状態モデル・ブロックチェーンにおいては、失敗したトランザクションを含めることが有効で（および、一般的でさえ）あり得る。いくつかの実施形態において、これらのトランザクションは、ブロックに含まれるが、（トランザクション手数料の支払いは別として）カノニカル状態を修正しない。したがって、「正確に処理される」トランザクションは、そのトランザクションを始めるユーザによって意図されたことを実際には行わないことがあり得る。

いったん１つまたは複数の有効な候補ブロックが製造されると、ネットワークは、単独の有効な候補について集合的に合意するための何らかのコンセンサス機構を使用し得る。これは、典型的には、現行のブロックチェーンにおける「プルーフ・オブ・ワーク」であるが、「プルーフ・オブ・ステーク」を使用する、将来のネットワーク、または既存のネットワークの発展について、多くの提案がある。本明細書において説明される、分散型計算システムの実施形態は、コンセンサス機構のいずれのファミリーでも同じように十分に作動し、または、インスタント・ファイナリティと結合される場合には、プルーフ・オブ・ステーク・コンセンサスでも同じように十分に作動する。

いくつかの実施形態において、説明されるスキームを採用することができる例示的なシステムは、高スループットを有し、シャーディングなしのアーキテクチャ・アプローチを提供し、これは、構成可能性をもたらす。いくつかの実施形態において、そのような構成可能性は、より単純なトラストレス・システムの新規な組み合わせを通じて作成されるべき、複雑で新しいトラストレス・システムを提供する。例示的な分散型計算システムは、例えば、分散型アプリケーションをサポートするために、採用されることが可能である。いくつかの実施形態において、例示的な分散型計算システムは、ピア・ツー・ピア・ネットワークを３つの別個のノード・タイプに分割し、各々が、３つのタスク、すなわち、ネットワークに外部からアクセスすること、ネットワークを攻撃から保護すること、およびネットワークの状態を計算することのうちの１つの責任を負う。そのような懸念事項の分離は、ノード専門化を可能にし、ノード専門化は、展開されたシステムのセキュリティおよび分散の可能性を強化しつつ、ネットワークのスループットを劇的に改善する。また、構成可能性は、ソフトウェア再使用の強力な表明になり得るが、アトミシティのない構成可能性は、整合性のない結果（例えば、「望まれない状態」）につながることがある。例示的な分散型計算システムは、各トランザクションに、相互作用することが認証されるカノニカル状態の任意の部分にアトミックにアクセスし、修正するための能力を可能にするスケーリング機構を採用し得る。

上述したように、いくつかの実施形態において、例示的な分散型計算システムは、ネットワーク内のノードを３つの別個の役割、すなわち、アクセス、セキュリティ、および実行へと分割する。この懸念事項の分離は、分散型システムの完全性を特徴付け、支持するアクセス、セキュリティ、信頼性、および検証可能性保証を維持する環境において、同期性を犠牲にせずに、高スループットを可能にすることができる。いくつかの実施形態において、異なるノード・タイプ間のコア関係は、抑制および均衡のうちの１つであり、これは、トランザクションの包含、順序、および出力に関する強いコンセンサスを確実にし、履歴のカノニカル状態を決定する。このアプローチの課題のうちの１つは、ノードの３つの別個のグループを調整し、それらの間の効率的な相互作用を確実にすることである。

いくつかの実施形態において、例示的な分散型計算システムは、マス・マーケット・オーディエンス（例えば、数十億人のアクティブ・ユーザ）に対して利用可能にされ得る、繁栄していて魅力あるエコシステムをサポートするために、トランザクション容量および計算スループットを提供する。いくつかの実施形態において、例示的な分散型計算システムは、１秒あたり１００万以上ものトランザクション（ＴＰＳ：ｔｒａｎｓａｃｔｉｏｎｓｐｅｒｓｅｃｏｎｄ）を取り扱う。

例示的な分散型計算システムは、実用的なユーティリティを犠牲にしないことがある。特に、いくつかの実施形態において、本システムは、スマート契約間の完全同期通信を持続させる。完全同期性は、エラーまたは搾取の傾向のある複雑なロッキング・スキームなしで、契約間通信が、正確性（アトミシティ、整合性、分離、耐久性）についてのＡＣＩＤ保証を保持することを確実にする。つまり、同期性は、１つのスマート契約が、別のスマート契約が正確に実行されると確信し、独立したスマート契約が、安全性を犠牲にせずに、複雑なシステム内へ構成されることを可能にするために必要とされ得る。

長期的で持続的な分散は、例示的な分散型計算システムによって提供される１つの態様であり得る。多くのブロックチェーン対応のシステムが、システムのコア・バリューではなく、任意選択のもの、または表面的なものとして分散を扱う。これは短期的には何らかの迅速な成果をもたらし得るが、それらのシステムは、時間と共に劣化しやすい。さらに、他の明示的なインセンティブなしでは、任意の集中化率を有する有益なシステムは、さらに集中化する傾向がある。例示的な分散型計算システムによって提供される分散の品質は、アクセス、セキュリティ、信頼性、および検証可能性を含む。

いくつかの実施形態において、例示的な分散型計算システムは、（ユーザが自身の使用に対して支払いをすることができるという条件で）固定されたコストでネットワークのシステム・リソースを使用するための能力を通じてアクセスを提供する。そのようなアクセスは、いかなるクラスのユーザがネットワークを使用することも拒否することができる、または何らかのトラフィックを他のものより優先することができる、アクター、またはアクターの妥当なグループがないことをもたらす。

いくつかの実施形態において、例示的な分散型計算システムは、ネットワーク内の各誠実な参加者が他の誠実な参加者と同じ履歴のビューを有すること、および、この履歴的な記録が事後に修正されることが可能ではないことを確実にすることによって、セキュリティを維持する。

信頼性は、システムの規則が一様に適用され、厳密に強制され、予測可能で透明性のある手法でのみ変更されることが可能という確信性を含む。いくつかの実施形態において、例示的な分散型計算システムは、これらの規則をある点で変更することができるアクター、またはアクターの妥当な集団がいないことを、システムのユーザが（例えば、ハード・フォークを通じて）それらの変更をオプトアウトすることを可能にせずに確実にすることによって、信頼性を提供する。

いくつかの実施形態において、例示的な分散型計算システムは、一部または全部のアクション（例えば、プロトコル規則に従った高度なオン・チェーン動作等）の透明性を可能にするという点において検証可能である。そのため、誰でも、例えば、自身の制御下のコンピュータ・リソースを使用して、プロトコル（およびプロトコル内で定義された規則）が正確に従われたことを確認することができる。これは、全てのオン・チェーン・アクティビティを見るための能力を黙示的に含む。例えば、ユーザは、ユーザが提出したトランザクションがチェーン上で正確に実行されたことを検証することができる。

アクセス、セキュリティ、信頼性、および検証可能性の、例示的な分散型計算システムの保証は、分散型環境からのより広範な利益のセットを取り込む。例えば、アクセスを保証することは、誰でもネットワークに参加し、ネットワークが拘束される規則を簡単に理解することができることを確実にするのに役立ち得る。さらに、セキュアなネットワークは、それらの規則を必ず実施し得る。この組み合わせは、ユーザがシステムについて推論することができ、入力の知られているセットを用いて、結果を確実に予測し、最終的に検証する環境を製造し得る。これらの要件は一体となって、完全な分散を達成するために必要とされるロバストな基準、ならびに透明性、自律性、相互運用性、および不変性の関連付けられた利益を提供する。

図２は、本開示の実装を実行するために採用されることが可能である例示的な環境を描く。例示的なシステムは、コンピューティング・デバイス１０２、１０４、１０６、１０８と、ネットワーク１１０とを含み、これらは、ピア・ツー・ピア・ネットワークを形成するために使用され得る。いくつかの実施形態において、ネットワーク１１０は、ローカル・エリア・ネットワーク（ＬＡＮ）、広域ネットワーク（ＷＡＮ）、インターネット、または、これらの組み合わせを含み、デバイス（例えば、コンピューティング・デバイス１０２、１０４、１０６、１０８）を接続する。いくつかの実施形態において、ネットワーク１１０は、イントラネット、エクストラネット、または、インターネットと通信するイントラネットもしくはエクストラネットを含む。いくつかの実施形態において、ネットワーク１１０は、通信ネットワークまたはデータネットワークを含む。いくつかの実施形態において、ネットワーク１１０は、有線通信リンクまたは無線通信リンク上でアクセスされることが可能である。例えば、モバイル・コンピューティング・デバイス（例えば、スマートフォン・デバイス１０２およびタブレット・デバイス１０６）は、セルラー・ネットワークを使用してネットワーク１１０に対してアクセスすることができる。

いくつかの例において、ユーザ１２２～１２８は、分散型計算システムと相互作用するためにエージェント・ソフトウェアを採用するユーザ・エージェントとして作動していてもよい。例えば、ユーザは、それらのそれぞれのデバイス１０２～１０８を採用して、トランザクションを提供し、または説明されるシステム内のノードとして機能してもよい。

いくつかの実施形態において、コンピューティング・デバイス１０２、１０４、１０６、および１０８は、図５に描かれたコンピューティング・デバイス５１０と持続可能に類似している。単純のために、４つのコンピューティング・デバイスが、図１～図２に描かれている。しかしながら、本開示のその実装は、前述されたコンピューティング・デバイスなどの、適当なコンピューティング・デバイスのいずれかにより実現されることができることが予期される。さらに、本開示の実装は、必要に応じて、ピア・ツー・ピア・ネットワーク内のノードとして機能する任意の数のデバイスを採用することができる。

コンピューティング・デバイス１０２、１０４、１０６は各々、任意の適当なタイプのコンピューティング・デバイス、例えば、デスクトップ・コンピュータ、ラップトップ・コンピュータ、ハンドヘルド・コンピュータ、タブレット・コンピュータ、携帯情報端末（ＰＤＡ）、セルラー電話、ネットワーク・アプライアンス、カメラ、スマートフォン、エンハンスト汎用パケット無線サービス（ＥＧＰＲＳ：ｅｎｈａｎｃｅｄｇｅｎｅｒａｌｐａｃｋｅｔｒａｄｉｏｓｅｒｖｉｃｅ）携帯電話、メディア・プレーヤ、ナビゲーション・デバイス、電子メール・デバイス、ゲーム機、または、これらのデバイスもしくは他のデータ・コンピューティング・デバイスのうちの任意の２つ以上の適当な組み合わせなどを含んでもよい。描かれている例において、コンピューティング・デバイス１０２はスマートフォンであり、コンピューティング・デバイス１０４はタブレット・コンピューティング・デバイスであり、コンピューティング・デバイス１０６は、デスクトップ・コンピューティング・デバイスである。

サーバ・コンピューティング・デバイス１０８は、コンピューティング・デバイス１０２～１０６について上述したような、任意の適当なタイプのコンピューティング・デバイス、および、サーバ・クラス・ハードウェアを有するコンピューティング・デバイスを含み得る。いくつかの実施形態において、サーバ・コンピューティング・デバイス１０８は、シームレスなリソースの単独のプールとして動作するために、クラスタ化されたコンピュータおよび構成要素を使用するコンピュータ・システムを含んでもよい。例えば、そのような実装は、データ・センタ、およびクラウド・コンピューティングにおいて使用され得る。いくつかの実施形態において、バック・エンド・システム１３０は、バーチャル・マシンを使用して展開される。

いくつかの実施形態において、コンピューティング・デバイス１０２～１０８は、例示的な分散型計算システム内のノードとして展開され、ピア・ツー・ピア・ネットワークを形成する。例えば、コンピューティング・デバイス１０２～１０８は、図３に例示されるように、形成されたピア・ツー・ピア・ネットワーク内のアクセス・ノード、セキュリティ・ノード、または実行ノードとして、説明される分散型計算において採用され得る。いくつかの実施形態において、形成されたピア・ツー・ピア・ネットワークは、各ネットワークノード（例えば、コンピューティング・デバイス１０２～１０８）が、ネットワーク上の他の全てのノードに直接的にまたは間接的に接続される、分散型ネットワークである。そのため、情報（例えば、トランザクション）は、中央サーバの必要なしに、ノード間で直接共有されることが可能である。いくつかの実施形態において、ノードは、ピア・ツー・ピア・プロトコルを採用して通信する。

いくつかの実施形態において、システムは、コンピューティング・デバイス１０２～１０８の各々上に記憶され得る分散型ブロックチェーンに対応し得る。いくつかの実施形態において、コンピューティング・デバイスのセットは、ブロックチェーンを記憶した。ブロックチェーンは、トランザクションを備えるブロックを含む。いくつかの実施形態において、そのようなトランザクションは、例示的な分散型計算システムによって受信され、検証され、実行される。いくつかの実施形態において、ブロックチェーンに記憶されたトランザクションは、スマート契約を含む。いくつかの実施形態において、スマート契約は、図３に例示されるように、カスタム機能性を用いて拡張され、形成されたピア・ツー・ピア・ネットワーク内の実行ノードによってトランザクションの一部として呼び出され得る。例えば、コンピューティング・デバイス１０２～１０８は、ブロックチェーン上のブロック内で処理され、記憶されるべきトランザクションを受信するために、それぞれのユーザ２２２～２２６によって使用され得る。いくつかの実施形態において、コンピューティング・デバイス１０２～１０８は、スマート契約コードを実行するための実行ランタイムとしてバーチャル・マシンを採用する。例えば、そのような機構は、ある状態から別の状態への遷移を可能にし、すなわち、（トランザクションの数が記憶される）一定のブロックが与えられ、状態ｓが与えられると、計算を行うことは、マシンを新しい状態Ｓ’にする。いくつかの実施形態において、状態遷移機構は、トランザクション関連の口座にアクセスすること、動作を計算すること、およびバーチャル・マシンの状態を更新すること／書き込むことから成る。バーチャル・マシン上で実行されるもの全て（例えば、スマート契約コード）が、その状態を改変し得る。いくつかの実施形態において、ブロックの全てのトランザクションを実行した後、現在の状態が記憶され得る。

図３は、例示的な分散型計算システムのための一般的なアーキテクチャの例を描いており、これは、例えば、図１～図２の例示的な環境を通じて、展開されることが可能である。一般的なアーキテクチャは、クライアント３０２、アクセス・ノード３１０、セキュリティ・ノード３２０、および実行ノード３３０を含み、これらは、図１～図２のデバイス１０２～１０８などのデバイスを通じて展開され得る。いくつかの実施形態において、アクセス・ノード３１０は、クライアント３０２についてのネットワーク利用可能性を維持し、世界状態に関連するクエリに回答する。いくつかの実施形態において、セキュリティ・ノード３２０は、ＢＦＴコンセンサス・アルゴリズムに参加することによってネットワークの安全性を確実にし、これは、ブロックに対して強い保証を提供する。いくつかの実施形態において、実行ノードは、セキュリティ・ノード３２０から受信されるとすぐにブロックを処理する（ファイナライズされたブロック３２５）。いくつかの実施形態において、実行ノードは、セキュリティ・ノード３２０によってファイナライズされた、トランザクション３０５などのトランザクションの結果を決定し、結果として生じた世界状態を記憶するための計算能力を提供することができる。これらの役割のより詳細な解説は、以下に提供される。

いくつかの実施形態において、例示的な分散型計算システムは、図１～図２のブロックチェーンなどの分散型ブロックチェーンを採用する。いくつかの実施形態において、分散型ブロックチェーンのジョブは、多種多様な構成要素機能へと分割されることが可能である。それらの機能のうちのいくつかは、完全に決定論的であり、客観的に正確な出力を有し得、それらのタスクのうちのいくつかは、主観的であり、ネットワーク・レベルのコンセンサスを必要とし得る。分散型ブロックチェーン・システムは、本来主観的であるもの、すなわち、どのトランザクションが、どの順序で、共有される状態に含まれるか（「トランザクション・ログ」）に関してネットワーク・コンセンサスに確実に到達するために、自律的で、リーダなしの、分散型システムを作成することができる。いくつかの実施形態において、そのような主観的なタスクは、トランザクション・ログを指示するための全能の中央管理者、またはカノニカル・トランザクション・ログの共有されるビューを分散型ネットワークが決定することを可能にする多くのコンセンサス・システムのうちの１つ、のいずれかを必要とし得る。ブロックチェーンの２つの他のタスク、すなわち、トランザクション・ログを記憶すること、および、コンセンサス順序でのログの内容の正確な適用から結果として得られる世界状態を決定することは、主観的でなくてもよく、完全に決定論的であってもよい。ブロックチェーンが消費者規模に到達することを防止する主なボトルネックは、この第２のカテゴリに収まる。

いくつかの実施形態において、例示的な分散型計算システムは、決定論的プロセスにおける全てのビザンチン障害が４つの重要な属性、すなわち、検出可能性、帰属可能性、処罰可能性、および訂正可能性を有するように設計される。いくつかの実施形態において、決定論的プロセスは、客観的に正確な出力を有し得る。これは、ネットワーク内の単独の誠実なノードでさえ、決定論的な障害を検出し、不正確に実行されたプロセスの一部を再作成するように他の全ての誠実なノードに対して依頼することによって、他の全ての誠実なノードにエラーを証明することができることを意味する。さらに、いくつかの実施形態において、例示的な分散型計算システムにおける決定論的プロセスは、検証可能なランダム関数（ＶＲＦ：ｖｅｒｉｆｉａｂｌｅｒａｎｄｏｍｆｕｎｃｔｉｏｎ）を使用して、ノードに対して割り当てられ得る。そのため、検出されたいかなるエラーも、そのプロセスの責任を負ったそれらのノードに対して明確に帰属させられることが可能である。いくつかの実施形態において、例示的な分散型計算システムに参加する全てのノードは、決定論的プロセスにおいてさえ、ステークを行わなければならず、ステークは、決定論的プロセスがビザンチン挙動を取ったと判断された場合にスラッシュされ得る。決定論的プロセスにおける全てのエラーが、自明に検出可能であり、かつ、帰属可能であるので、それらのエラーは、スラッシング（ｓｌａｓｈｉｎｇ）により確実に罰せられることが可能である。いくつかの実施形態において、説明されるシステムは、エラーが検出されるとすぐに迅速にエラーを取消す手段を有しなければならない。これは、悪意のあるアクターが、スラッシング・ペナルティーよりも悪意のあるアクターの利益になるエラーを誘発することを阻止する役割を果たす。

説明されるシステムの設計は、多くの参加者がプロセスの非決定論的な部分をサポートするために必要とされ、一方で、はるかに少ない参加者が決定論的プロセスのために必要とされ、なぜならば、それらの参加者の特性が、確定的な検出、および、したがって、プロトコルを遵守しない人々の罰を指示するからであるという洞察によって通知された。したがって、説明されるシステムは、（図３に描かれるような）決定論的プロセスを分離し得、それらを、幅広いオーディエンスによって吟味される、より少ない、より強力な参加者に対して割り当て得る。より少ないノードは、ネットワークの決定論的な要素を、特に計算を実行するために、はるかにより効率的にする。例えば、ある概念実証は、このアプローチが、セキュリティ保障のいかなる劣化もなしに、１００，０００を超えるＴＰＳを達成することができることを示す。５つの大陸上の１１個の異なるデータ・センタ内で実行される３０を超えるノードのヘテロジニアス・ネットワークとしてのテストベッド・セットアップにおける性能のための概念実証。これは、問題がそれらの決定論的な部分と非決定論的な部分とに分離され、それに応じて割り当てられる場合に可能な改善のうちのほんの１つの例である。

いくつかの実施形態において、アクセス・ノード３１０は、例示的な分散型計算システムの外部の世界との情報交換を仲介し得、これは、状態と履歴との両方に関する体系的でタイムリーな通信を確実にするのに役立ち得る。いくつかの実施形態において、アクセス・ノード３１０は、トランザクション・プールを管理すること、および十分に形成されたトランザクション、例えば、クライアント３０２からのトランザクション３０５を収集して、セキュリティ・ノード３２０に対して提供することを課され得る。いくつかの実施形態において、十分に形成されたトランザクションは、トランザクションの保証人からのクレデンシャルを含み得る。いくつかの実施形態において、アクセス・ノード３１０が、十分に形成されたトランザクションを見る場合、アクセス・ノード３１０は、そのトランザクションのテキストをハッシュ化し、２つのこと、すなわち、第１に、トランザクションが十分に形成されていること、および、第２に、トランザクションは、実行ノード３３０がトランザクション・テキストの処理を終了するまで、トランザクション・テキストを記憶することにコミットするであろうこと、を示すためにトランザクションに署名し得る。いくつかの実施形態において、臨界数のアクセス・ノード３１０が、トランザクションをレビューし、トランザクションが十分に形成されていると結論を下した場合、それらは、トランザクションをレビューのためにセキュリティ・ノード３２０へ送信し得る。臨界数のアクセス・ノード３１０は実施形態によって変わり得る。例えば、臨界数のアクセス・ノード３１０は、様々なプロトコル・パラメータに依存し得る。いくつかの例において、少数の悪意のあるアクセス・ノードが、あるトランザクションを優先させること、または他のトランザクションを検閲することによって、ブロックチェーンの完全性を脅かすことができない手法で、臨界数のアクセス・ノード３１０が選ばれ得る。

いくつかの実施形態において、セキュリティ・ノード３２０と実行ノード３３０との両方が、ブロックを構築し、処理した後、アクセス・ノード３１０は、それらの出力（例えば、計算の結果）について実行ノード３３０にクエリを行い得る。いくつかの実施形態において、アクセス・ノード３１０は、実行ノード３３０から受信された、その出力のキャッシュを記憶する。いくつかの実施形態において、アクセス・ノード３１０は、実行ノード３３０に、さらなるダイレクト・クエリを負担させる必要なしに、計算のキャッシュされた結果（例えば、状態応答３４５）をクライアント３０２に対して提供する。いくつかの実施形態において、検証可能なランダム関数（ＶＲＦ）は、実行ノード３３０からのどの出力が、正確に計算されたことをチェックするためにアクセス・ノード３１０がクエリを行い得るかを決定する。最終的に、アクセス・ノード３１０は、実行ノード３３０を「誠実」に保ち得る。これは、説明されるシステムによって提供される分散のアクセス、セキュリティ、および検証可能性基準間の勢力均衡を維持するために実行され得る。システムの提供されるプロトコルおよび基盤となる構造は、高度なビザンチン障害耐性（ＢＦＴ）である。なぜならば、いくつかの実施形態において、アクセス・ノード３１０のプール内に相当な数のビザンチン・エラーがあったとしても、セキュリティ・ノード３２０は、それらが署名したトランザクションがネットワークの臨界量によってレビューされたことを承認することを依然として必要とされるからである。ＢＦＴプロトコルは、少数の悪意のあるアクセス・ノードまたはセキュリティ・ノード（例えば、「少数の」は、何らかの臨界数未満を意味する）からネットワークを保護することができ、その結果、それらは、ネットワークの完全性およびライブネスを脅かすことができない。ノードによる、いかなる意図的な誤りまたは非意図的な誤りも、検出可能であり、修正可能であり、帰属可能であり、ネットワークの残りの部分によって罰することが可能であり得る。

いくつかの実施形態において、アクセス・ノード３１０は、それらのクエリおよびトランザクションがそれぞれ回答され、取り込まれ得るので、公衆と通信するために高レベルの帯域幅およびを低いレイテンシを必要とする。いくつかの実施形態において、アクセス・ノード３１０（例えば、図２のユーザ２２２～２２８）には、それらが保証するあらゆるトランザクションに対して、および、それらが検証に成功した各トランザクション対して、定額料金（または他の報酬）が支払われ得る。いくつかの実施形態において、アクセス・ノード３１０は、十分に形成されていないコレクションをアクセス・ノード３１０が提供した場合、または、アクセス・ノード３１０が保持することになると伝えたトランザクション・テキストを記憶することにアクセス・ノード３１０が失敗した場合、スラッシュされる。

スラッシングは、ノード誤動作を妨げ、全体的なネットワーク・セキュリティおよび利用可能性を維持するために、ブロックチェーン・プロトコル（例えば、プルーフ・オブ・ステーク）に組み込まれた機構であり得る。同様に、インセンティブは、プロトコル・セキュリティ、利用可能性、およびネットワーク参加にインセンティブを与えるように設計され得る。スラッシングは、罰の一形態であり、ノードの除去、金銭的ペナルティーおよび／または他の罰を含んでもよい。

いくつかの実施形態において、セキュリティ・ノード３２０は、ブロックチェーンの完全性を確実にするために、ブロック・ファイナリティを達成するべく、説明されるシステムによって採用されるコンセンサス・アルゴリズムに参加する。このコンテキストにおいて、ファイナリティは、臨界的多数によって署名されており、十分に形成されていることと、アクセス・ノード３１０によって記憶されていることとの両方が確認されるトランザクションのファイナライズされたブロック３２５を含む。いくつかの実施形態において、セキュリティ・ノード３２０は、トランザクションの決定論的な出力を知るために必要な順序を設定する候補ブロック３１５に対して迅速に投票することができるので、主としてセキュリティおよび規模に対して貢献する。いくつかの実施形態において、セキュリティ・ノード３２０は、アクセス・ノード３１０によってセキュリティ・ノード３２０へ提出される署名されたトランザクション・ハッシュが、説明されるシステムによって必要とされるような臨界量のアクセス・ノードによって署名されていることの有効性を確認する。いくつかの実施形態において、臨界量のアクセス・ノードは、設定可能な閾値によって決定される。

セキュリティ・ノード３２０によって行われるコンセンサス・アルゴリズム（例えば、プルーフ・オブ・ステーク・アルゴリズム等）は、サブプロトコルであってもよい。コンセンサス・アルゴリズムは、セキュリティ・ノード３２０が、チェーンに追加するべき次のブロックに関して合意する（例えば、「コンセンサス」に到達する）のに役立ち得る。

いくつかの実施形態において、いったんセキュリティ・ノード３２０が、提示されたトランザクションが臨界数のアクセス・ノード３１０によって署名されたという合意に到達することに成功すると、そのトランザクションは、ファイナライズされたブロック３２５とみなされる。説明されるシステム内のプロセスのセキュリティは、基盤となるコンセンサス・アルゴリズムのセキュリティに依存しており、その検討事項のうちのいくつかは、多数の参加者をサポートするための速度および能力である。いくつかの実施形態において、例示的な分散型計算システムによって採用されるコンセンサス・アルゴリズムは、ＣａｓｐｅｒＣＢＣ、Ｔｅｎｄｅｒｍｉｎｔ由来のＳＢＦＴ、ＨｏｔＳｔｕｆｆ、Ｆａｎｔｏｍｅｔｔｅ、または、多くの参加者をサポートするのに十分に適した他のものの変形例を含む。いくつかの実施形態において、ファイナライズされたブロックは、含まれるトランザクションの順序を決定し得る。いくつかの実施形態において、トランザクションの順序付けは、コレクションの順序、およびコレクション内のトランザクションの順序付けに基づく。いくつかの実施形態において、これらの要素の順序付けは、提案するノードによって実行される偽似ランダム・アルゴリズムに対応し得る。

いくつかの実施形態において、セキュリティ・ノード３２０は、臨界数のアクセス・ノード３１０がトランザクションをレビューし、署名したことをチェックするグループであるので、アクセス・ノード３１０に対するチェックポイントを提供する。いくつかの実施形態において、セキュリティ・ノード３２０は、仲間のセキュリティ・ノード３２０によってのみ、とりわけ責任を負わされる。ＰｏＷベースのシステムおよびＰｏＳベースのシステムの共通の懸念事項は、母集団の小さなサブセットが、重要なリソース、例えば、ブロックを製造し、投票するために必要とされるマイニングまたはステークなど、を制御することができるということであり、これはシステムのセキュリティの劣化である。いくつかの実施形態において、参加するための要件を低くすることによって、例示的な分散型計算システムは、例えば、不良なアクターによってビザンチン・カルテルまたは他の共謀アクティビティを調整することを、より困難にまたはより高価にし得る。

いくつかの実施形態において、セキュリティ・ノード３２０は、最小限の帯域幅および計算要件を有して、質素なコンピューティング・デバイス、例えば、スマートフォンまたは低出力ＡＲＭ（登録商標）システムなどでさえ、投票プロセスに参加し、ネットワークの安全性を確実にすることを可能にしてもよい。多くのネットワークは、分散型ネットワークに加わるために実質的なものを通じて、オープンな参加を主張し得る。そのような閾値を維持することは、ネットワークのセキュリティを弱体化させる。セキュリティ・ノード３２０について上述したように、参加要件を低くすることは、調整問題を持続させ、これは、高度なＢＦＴを提供することの中心となり得る。なぜならば、不良なアクターのサブセットがネットワークを破壊することを非常に困難にし得るからである。いくつかの実施形態において、セキュリティ・ノード３２０は、それらがブロックに含めるトランザクションに対して支払いを受け得る。いくつかの実施形態において、コンセンサス・プロセスに参加することは、これらのノードがステークを行うことを必要とし、これは、これらのノードが無効なブロックに署名する場合にスラッシュされ得る。いくつかの実施形態において、無効なブロックは、アクセス・ノード３１０からの臨界数の署名を有しない。

いくつかの実施形態において、実行ノード３３０は、実行ノード３３０に対して提供されるファイナライズされたブロック３２５の出力を計算する。いくつかの実施形態において、実行ノード３３０は、セキュリティ・ノード３２０によってファイナライズされ、提供された可能性がある候補ブロック３１５（例えば、ファイナライズされたブロック３２５）を実行する。いくつかの実施形態において、実行ノード３３０は、セキュリティ・ノード３２０によって実行ノード３３０に対して提供されたハッシュと一致するトランザクション・テキストについてアクセス・ノード３１０にクエリを行う。このデータを用いて、実行ノード３３０は、出力を計算することが可能となり得、これは、いくつかの実施形態において、誠実さを確実にするために、アクセス・ノード３１０のランダムに割り当てられたサブセットによって、後でランダムにクエリを行われる。いくつかの実施形態において、実行ノード３３０は、規模および効率におけるシステムの改善の少なくとも一部に対して責任を負い得る。なぜならば、非常に少数のこれらの強力なコンピュータ・リソースのみが、履歴状態を計算し、記憶するように必要とされるからである。

いくつかの実施形態において、いったん実行ノード３３０のうちの１つが、ファイナライズされたブロック３２５の出力、またはファイナライズされたブロック３２５内のトランザクションのサブセットを計算すると、ハッシュ化されたコミットメントを提示する。ハッシュ化されたコミットメントは、状態コミットメントに対応し得、これは、新しいブロックを実行した後のブロックチェーンの全状態のハッシュであり得る。いくつかの例において、このハッシュ化されたコミットメントは、ブロックチェーンの状態がマークル・ツリーに記憶される場合、マークル・ツリー・ハッシュに対応し得る。いくつかの実施形態において、この出力は、その共同実行者（例えば、例えばＶＲＦによって決定されるような他の実行ノード３３０）もそれらの出力を提出すると、明らかにされ得る。これはノードが互いの作動のなりすましをしていないことを確実にするために重要である。いくつかの実施形態において、いったん実行ノード３３０が、それら自体の回答を提出すると、出力が明らかにされる。いくつかの実施形態において、いったん明らかにされると、出力は、アクセス・ノード３１０によって実行されるランダム・クエリおよびチェックを受ける。いくつかの実施形態において、実行ノード３３０は、比較的低いＢＦＴを有し得る。しかしながら、これは、システムの全体的なセキュリティを損なわない。なぜならば、それらが行うプロセスは決定論的であるからである。例えば、いかなる不良なアクターも、アクセス・ノード３１０によって簡単に検出され、罰せられ得る。

いくつかの実施形態において、ノード（例えば、実行ノード３３０）のこの比較的小さいグループは、プロセッサ速度および帯域幅について最も実質的で技術的な要件を有する。なぜならば、それらは、ネットワークの出力を決定するために必要な計算を実行することまたは行うことを課され得るからである。いくつかの実施形態において、この程度の特殊化を可能にすることは、他の従来の分散型ネットワークと比較した場合、計算コストを少なくとも１０００倍、おそらくはより一層、低減することができる。

いくつかの実施形態において、実行ノード３３０は、ブロックチェーンの全世界状態を計算し、記憶する責任を負うが、実行ノード３３０は、その状態についての全ての外部クエリに回答することを必要とされなくてもよい。いくつかの実施形態において、実行ノード３３０は、アクセス・ノード３１０に対して、それらの出力を確認するために、検証期間中に少なくとも一回、回答し得る。いくつかの実施形態において、このクエリは、アクセス・ノード３１０に対して、上述したような、クライアント３０２からの将来のクエリについての回答（例えば、状態応答３４５）を提供し、これは、実行ノード３３０に将来負担をかける、それらの過剰なクエリを実行ノード３３０から省く。しかしながら、いくつかの実施形態において、実行ノード３３０は、それらの出力についての回答を促されたときにアクセス・ノード３１０に対して提供しない場合、罰され（例えば、スラッシュされ）得る。いくつかの実施形態において、実行ノード３３０は、それらの出力が検証されると、検証期間の終了時に、それらの作業に対して支払いを受け得る。いくつかの実施形態において、実行ノード３３０によって課されるコストは、計算によって変わり、計算が必要とした命令の数に基づく可能性がある。

いくつかの実施形態において、これらの異なるノード・タイプ（例えば、アクセス・ノード３１０、セキュリティ・ノード３２０、および実行ノード３３０）間の共通スレッドは、ネットワークによって保持される状態に対する、それらの関係および権限であり得る。例えば、いくつかの実施形態において、世界状態全体は、計算を行うために、ありとあらゆる実行ノード３３０によって保持され得る。いくつかの実施形態において、いったん実行ノード３３０が計算を実行し、出力を決定すると、それらは世界状態を更新し得、その後、世界状態は、アクセス・ノード３１０によって有効性を確認される。いくつかの実施形態において、実行ノード３３０は、問題の出力状態についてマークル証明を提供しなければならない。この複雑さは、出力の完全性の有効性検証を可能にし得る。

いくつかの実施形態において、アクセス・ノード３１０は、全体的なカノニカル状態３３５の一部を各アクセス・ノード３１０が保持した状態で、最も最近更新されたまたはアクセスされたデータをシャード化された様式でキャッシュし得る（例えば、キャッシュされた状態３４０）。このキャッシュされた状態３４０は、実行ノード３３０がビジー状態であり、回答することができない場合には、ユーザ・クエリに回答する（例えば、回答状態３４５をクライアント３０２に対して提供する）ためにデータが簡単にアクセス可能であることを確実にするのに役立ち得る。回答をより迅速に提供するためのこの能力は、公衆に対してネットワークのアクセスおよび検証可能性を確実にするのに役立つ。いくつかの実施形態において、アクセス・ノード３１０は、トランザクションが処理され、結果が実行ノード３３０によって検証されるまで、トランザクションデータを保持する責任も負う。いくつかの実施形態において、いったん処理されると、トランザクション自体がカノニカル状態３４５の一部になり、アクセス・ノード３１０は、キャッシュされた状態３４０（例えば、トランザクション・テキスト）を記憶することをもはや必要とされない。

いくつかの実施形態において、（例えば、クライアントデバイス３０２のうちの１つによって）トランザクションが生成される場合、トランザクションは、実行されるべき明示的なコードおよび／または明示的なデータ（例えばスマート契約）、ならびにトランザクションに対して支払いを行う口座からのクレデンシャルを含み、これは、トランザクションまたはデータ保持者を生成するユーザ・アカウントとは異なり得る。いくつかの実施形態において、このトランザクションは、ネットワークへ提出され、ネットワークにおいて、トランザクションは、例えばクレデンシャルをチェックするために、アクセス・ノード３１０によって処理される。いくつかの実施形態において、アクセス・ノード３１０は、実行ノード３３０がトランザクションを処理し、それらの出力が検証されるまで、そのトランザクションを保持することにコミットするためにトランザクションに署名する。いくつかの実施形態において、いったん臨界量のアクセス・ノード３１０がトランザクションに署名すると、トランザクションは、２つの事柄、すなわち、１）臨界量のアクセス・ノード３１０がトランザクションを見て、トランザクションを記憶することに合意し、トランザクションが十分に形成されていることを確認したこと、および、２）セキュリティ・ノード３２０は、それらが過去にパブリッシュしたものが無効であったという証明がそれらに提供されない限り、その高さにおける別のブロックを確認しないであろうことを検証するためにセキュリティ・ノード３２０へ送信され得る。

いくつかの実施形態において、セキュリティ・ノード３２０は、ファイナライズされたブロック３２５に関して合意するためにＢＦＴコンセンサス・アルゴリズムに従う。いくつかの実施形態において、いったん候補ブロック３０５がセキュリティ・ノード３２０によってファイナライズされると、ファイナライズされたブロック３２５は、計算のために実行ノード３３０へ送信され得る。いくつかの実施形態において、ＶＲＦは、各ファイナライズされたブロック３２５を計算する責任を負う実行ノード３３０のサブセットを決定するために採用される。いくつかの実施形態において、いったん実行ノード３３０が出力を計算すると、実行ノード３３０は、結果のハッシュ化されたコミットメントを生産する。いくつかの実施形態において、選択されたノード（例えば、決定されたサブセット内の実行ノード）が全て、それらのコミットメントを提出した場合、それらは、非暗号化された結果出力を明らかにし得る。いくつかの実施形態において、この出力が、参加する実行ノード３３０の全てから同じであることを示される場合、アクセス・ノード３１０の各々は、検証されるべき少数のトランザクションを選択するためにＶＲＦを使用する。いくつかの実施形態において、いったん回答がアクセス・ノード３１０に対して提供されると、アクセス・ノード３１０は、その回答を、クライアント３０２からの将来のクエリに回答するためにキャッシュする。例えば、ユーザが、システムから状態を取り出すことを望む場合、それらはアクセス・ノード３１０に対して（例えば、クライアント３０２を通じて）クエリを提起し得る。例えば、クエリは、「このブロック高さにおける、このレジスタのコンテンツは何か？」などの形態であってもよい。いくつかの実施形態において、アクセス・ノード３１０は、それらが保持するキャッシュされた状態を通じてクエリを実現するか、または、それらは、実行ノード３３０に対して出力についてクエリを行うことができる。

いくつかの実施形態において、トランザクション、およびその中に含まれているそれぞれのブロックは、検証期間が終わった後にのみ、カノナイズされた（ｃａｎｏｎｉｚｅｄ）と考慮され得る。いくつかの実施形態において、検証期間中、例えば、結果は、不正確な出力の証明を提出するために、アクセス・ノード３１０と公衆との両方に対してオープンである。いくつかの実施形態において、検証期間は、最大で数時間の長さであり得る。

いくつかの実施形態において、例示的な分散型計算システムのアーキテクチャを上述したように分割することによって、複数の利益、特に、同期性、効率性、および規模が達成され得る。例えば、分散型環境において開発することは、開発者にとって多くの不確実性を伴い、とりわけ重要なことは、書き込むことができる前に変化するデータから読み出すことである。このことを念頭に置くと、強い直列化可能性の保証、すなわち、重複するトランザクションのない、シーケンシャルなスケジュールと等価な結果は、分散型開発環境、例えば、例示的な分散型計算システムによって提供される環境などが提供することができる最も重要なことのうちの１つである。トランザクションの順序にコミットすることによって、トランザクションは、絶対的な順序で実行されたように見えることができ、その結果、スループットを改善するためにいくつかは並列に実行されたとしても、開発者はシステムについて推論することができる。特に、トランザクションがシャード間で移動する場合、いくつかのシステムは、直列化可能性を持続させるためにロッキング機構に頼る。しかしながら、いくつかの実施形態において、実行ノード３３０が出力を決定する前の順序に関する例示的な分散型計算システム・プロトコルの合意は、いったんトランザクションが順序づけられると、その結果について確実性があることを確実にする。

いくつかの実施形態において、リソースを効率的に採用するために、例示的な分散型計算システムは、プルーフ・オブ・ステーク（ＰｏＳ）・ベースのシステムを備えてもよく、できる限り多くの冗長なタスクを除去するように設計される。例えば、古典的なブロックチェーン実装においては、あらゆるノードが、あらゆるトランザクションをレビューし、全ての状態を記憶することを必要とされ得る。決定論的なタスクと非決定論的なタスクとを分割し、それらを、それらのそれぞれの実行に特殊化することができるリソースに対して割り当てることによって、例示的な分散型計算システムのスループットが大幅に改善され得る。

いくつかの実施形態において、アーキテクチャ・レベルで、例示的な分散型計算システムのセキュリティは、１）３つの異なるノード・タイプ間の電力およびアカウンタビリティーの分割、２）コンセンサス・アルゴリズムによってサポートされる高い参加率、および３）、ネットワークのインターフェースとしてのアクセス・ノード３１０を指定することによって提供される。これらの設計要素は、分散型システムが直面することが多い一般的な攻撃の各々に対処するために、異なった姿を現し得る。例示的な分散型計算システムのアクセスおよび検証可能性の要件は、より広いネットワークと公衆との両方がプロセスを検証し、検証期間中にプロセスに異議を唱えることができることを保証する。計算の出力は決定論的であるが、いくつかの実施形態において、いったんその順序がファイナライズされたブロック３２５において設定されると、立証可能なエラーがネットワークへ提出される場合には、検証期間は再計算されるべき状態に留まり、したがって検出可能性についての機会を確実にする。例えば、いくつかの実施形態において、アクセス・ノード３１０は、あらゆるトランザクションに署名して、トランザクションに対する支払いを行うための署名保証人が存在することを確信させ、帰属を保証する。いくつかの実施形態において、全てのノードは、それらがネットワークのその部分から除去された場合にそれらが失うことになる値に関してステークされ、これは、違反があった場合の罰（例えば、スラッシュ化）を確信させる。

ブロックチェーン・コンテキストにおいて、検閲耐性は、あるグループが別のグループによるネットワークへのアクセスを拒否する困難さに対応し得る。そのため、いくつかの実施形態において、アクセス・ノード３１０の役割は、アクセスを保証し、誰でもトランザクションを監査し、提出することができることを確実にすることである。検閲に対抗するために導入されるアーキテクチャ・レベルの方策に加えて、いくつかの実施形態において、セキュリティ・ノード３２０は、トランザクション・ハッシュのみを見てもよい。したがって、そのような実施形態において、セキュリティ・ノード３２０がトランザクションを検閲するためには、セキュリティ・ノード３２０は、その署名者、データ、およびアクションのハッシュを知る必要があることになる。いくつかの実施形態において、セキュリティ・ノードは、一般に、莫大な数の共同参加者によって、説明されるシステムを弱体化することを防止される。したがって、いかなる問題に関する共謀も、調整することが非常に困難になる。

いくつかの実施形態において、セキュリティ・ノード３２０は、二重支出攻撃から保護し得る。例えば、いくつかの実施形態において、このグループへの幅広い参加は、小さいグループが、同じ高さにおける代替的ブロックを引き受け（ｈｏｎｏｒ）ようと共謀するリスクを著しく減少させる。例えば、ノードのこのプールに対してトランザクションのグループが提示される場合、それらは、十分な数のアクセス・ノード３１０がグループに署名することと、そのグループが、その瞬間と将来との両方で、その高さにおいてそれらが引き受けることになる唯一のブロックを形成することとの両方に関してコンセンサスに至る。いくつかの実施形態において、検証期間中に、競合する高さにおけるブロックを拒否するための不正の証明の提出に成功しない限り、提示される他のブロックは、ネットワークによって拒否されることになる。

フロント・ランニング攻撃において、敵対的ノードは、そのトランザクションを別のトランザクションの前に挿入することが有利であると決める。そのような動きは、競合する入札の前により高い入札をすることと同じくらい単純であり、または、その出力を偽って操作するためにトランザクションを戦略的に挿入することと同じくらい功名であり得る。これに対抗するために、いくつかの実施形態において、実行ノード３３０は、トランザクションの順序を計算するためにＶＲＦを行う。これは、トランザクションが既に決定論的に順序づけられた後まで、トランザクションの順序が、知り得るものでもなければ、誰かによって指示されることが可能なものでもないことを確実にする。

いくつかの実施形態において、アクセス・ノード３１０およびセキュリティ・ノード３２０は各々、ブロックに含まれるトランザクションにおける発言権を有する。そのような実施形態において、いずれかのグループが、トランザクションの順序を前もって設定することができる場合、そのことは、それらがその順序を利用し、自身のトランザクションを優先させる機会を提示する。いくつかの実施形態において、実行ノードが、ＶＲＦを実行して、トランザクションのカノニカル順序（カノニカル状態３３５）を明らかにすることを必要とすることによって、ノードはシーケンスを操作することはできない。いくつかの実施形態において、ＶＲＦを決定するために使用されるパラメータは、決定論的であり、セキュリティ・ノード３２０からの出力に依存することになる。

偽の口座およびアクティビティの潜在的な混乱に対する耐性は、ネットワークのスループットを維持するための１つの態様である。なぜならば、そのような悪意のあるトランザクションは、ノードに対して多大な負担を引き起こすことがあるからである。いくつかの実施形態において、ネットワークのインターフェースとして、アクセス・ノード３１０は、トランザクションに署名する口座の各々の残高を認識する。いくつかの実施形態において、トランザクションに対して支払いを行うユーザは、スパムから守るために、トランザクションを提出するための最低限の残高も保持しなければならない。

いくつかの実施形態において、アクセス・ノード３１０によって行われる最初のプロセスは、ブロックに含めるためにセキュリティ・ノード３２０へ提出されるべきトランザクションのリスト、および、トランザクションが発生すべき順序を決定することである。このプロセスは、「純粋なコンセンサス問題」であり、この問題に対する多くの取り得る回答があり、その各々が等しく「正しい」。しかしながら、異なる選択は、異なるカノニカル状態につながることになるので、ネットワークは、単一の回答に関して合意し得る。

いったんトランザクションの順序付けられたリストが合意されると、それらのトランザクションを処理した結果、どのようなカノニカル状態が得られるかに関する、単一の客観的に正確な回答があり得る。例えば、そのトランザクション・リストをエラーなしで処理した任意のノードは、その同じトランザクション・リストを正確に処理した任意の他のノードとまさに同じカノニカル状態に終わり得る。いくつかの例において、ブロックチェーン計算は、それらが他のノードによって検証されることを可能にするために、完全に決定論的であってもよい。したがって、２つの性能プロファイルに関する、２つの問題があり得る。まず、順序付けプロセスは、多種多様なＢＦＴコンセンサス・アルゴリズムによって解決されることが可能である純粋なコンセンサス問題であり得る。いくつかの実施形態において、そのようなプロセスは、コンセンサス・ノード間での多くの通信（例えば、ある閾値よりも多い通信メッセージ）を必要とし得るが、計算的に複雑ではないことがあり得る。このプロセスに関与するノードが多ければ多いほど、チェーンを破壊することがより困難になるので、ネットワーク・セキュリティは、このプロセスから直接もたらされる。第２に、いくつかの実施形態において、計算プロセスは、ネットワークがビジー状態にある場合、計算的に強力なノードを必要とし得るが、多数のノードを必要としない。なぜならば、それらのいずれも、客観的に計算ノードの「作業をチェックする」ことができ、エラーが発生した場合には、エラーを証明することができるからである。いくつかの実施形態において、ノードが、無効な出力を提示する場合、ノードはそのステークの一部または全部を失い、不正確に処理された計算は、誠実なノードにより再実行されることが可能である。上記プロセスの結果は、いくつかの実施形態において、集中化に起因するセキュリティの劣化のない、最大限のスループットを達成することができる単一のシャード化されていないネットワークである。

スキーマの例示的な統合
いくつかの実施形態において、上記の例示的な分散型計算システムは、パイプライン型アーキテクチャ、およびネットワーク内のノードの役割の分離に基づいて、ある閾値よりも大きいスループットを達成するブロックチェーンを備える。上述したように、ブロック内のトランザクションの実行は、実行ノード３３０によって行われる。いくつかの実施形態において、説明される証明スキーム（例えば、機密知識の特殊な証明）の統合は、（例えば、ユーザとして作用する）計算の正確性を保証するために、検証ノード（図示せず）と称される、別のタイプのノードによって再実行される実行を含むことができる。これらのノード、すなわち、実行ノード３３０と検証ノードとの両方の各々による実行プロセスは、実行トレースをもたらし、実行トレースは、ブロックのトランザクションを実行した証明として考慮されることが可能である。

実行トレースは、ブロック・トランザクションの実行をトレースする一連の工程を備えることができる。工程の識別は、ブロックチェーン状態への書き込み、およびブロックチェーン状態からの書き込みを含むことができる。

いくつかの実施形態において、検証ノードが、計算を検証する正しいジョブをしており、高価なチェックをスキップすることによって、実行ノード３３０の結果の有効性を確認していないことを確実にするために、証明スキームの統合は、各検証ノードに、実行トレースを知っていることの証明をパブリッシュするように強制する。実行トレース自体をパブリッシュすることは、いかなる検証ノードもそれらがトランザクションを計算したと主張することをもたらす。したがって、実行トレースは、シナリオ内の秘密であり、保護されたままでなければならない。実行ノード３３０および検証ノードは、実行トレース（例えば、証明）を知っているという特殊な証明をパブリッシュする。

いくつかの実施形態において、コンセンサス・ノードとして作用するアクセス・ノード３１０は、全ての証明を収集し、それらが全て同じ実行トレースから生成されたことを検証する。プロトコルは、実行トレースを正確に計算する誠実な検証ノードの閾値があることを確かめるので、検証が有効である場合、実行トレースは有効であるはずである。検証におけるいかなる不整合も検出可能であり、不誠実な当事者に対して帰属可能である。

いくつかの実施形態において、検証ノードは、トランザクションを並行な手法で再計算し、一方で、コンセンサス・ノード３１０は、上記に説明された証明を使用して、結果の安全性を保証する。いくつかの実施形態において、上記に説明された例示的な分散型計算システムは、簡潔で効率的なスキームを実装するためのプロセスまたはプロトコルを採用する。このプロセスは、スキームの正式な一般的な説明およびそのセキュリティ定義に従って本明細書において説明される。いくつかの実施形態において、プロセスは、ボネ・リン・シャチャム（ＢＬＳ：Ｂｏｎｅｈ－Ｌｙｎｎ－Ｓｈａｃｈａｍ）署名スキームに基づいた構造を含む。以下の説明は、このスキームについての適当な計算仮定の下でのセキュリティの証明を提供する。

いくつかの実施形態において、実行ノード３３０は、ファイナライズされたブロック内の全てのトランザクションの重い計算を行う。説明されるプロセスは、ブロック・トランザクションを再計算することに対して検証ノードを割り当てることによって、障害のある結果を検出し、帰属させるための機構を導入する。いくつかの実施形態において、この計算は、並行で独立した手法における、より軽い計算検証を可能にするために、チャンクへと分けられる。いくつかの実施形態において、コンセンサス・ノード３１０は、ブロック結果にコミットし、計算が大部分の検証ノードによって検証されたことを確かめる。いくつかの実施形態において、説明されるＢＬＳベースのプロセス実現は、中間結果がチャンク全体を実行することによるよりも安価に導出されることが可能ではないと仮定して、チャンク計算の中間結果を、そのチャンクのトランザクションを実行した証明として採用することに関与する。

いくつかの例において、チャンクは、チャンク化アルゴリズムを使用して分けられる。チャンク化アルゴリズムは、チャンクが同等の計算時間を有するように、ブロックをチャンクに分け得る。いくつかの例において、検証ノードは、チャンクのおかげで、より軽い、並行で独立した手法でブロックを計算する。

いくつかの実施形態において、実行ノード３３０は、各ブロック・チャンクの計算中間結果に対するコミットメントとして証明を提供し、検証ノードは、それらが検証する各チャンクのそれら自体の中間結果に対するコミットメントとして別の証明を提供する。いくつかの実施形態において、コンセンサス・ノード３１０の役割は、各チャンクの証明が同じ中間結果から一貫して生成されていることを確認することによって仲裁することである。単独の誠実な検証ノードは、チャンク計算における障害のある結果をプロトコルが検出することを可能にする。このプロセスは、ブロック計算が高い確率で正確であることを保証する。採用されるプロセスは、「怠惰な」検証ノードが、それらがチャンクを再計算したと主張することを防止するが、中間結果を計算した任意の当事者との共謀を防止または検出しない。しかしながら、誠実な結果から証明を生成する単独の非共謀ノードは、コンセンサス・ノード３１０が他の障害のある証明を見出すのを支援するのに十分である。

いくつかの実施形態において、ＢＬＳベースのプロセスは、当事者が、２つ以上の署名が同じ秘密メッセージに、その秘密自体についてさらに学習することなく、署名済みであることをチェックすること（例えば、ペアリング同等性チェック）を可能にするスキームを含む。いくつかの実施形態において、ＢＬＳベースのプロセス構造は、例示的な分散型計算システム内で採用されるスキームによって必要とされる特性を越えた、いくつかの洗練された特性も特に提供する。

検証者のジレンマとの関係
いくつかの例において、システムは、検証者のジレンマを軽減することに役立つことができる。検証者のジレンマは、いくつかの参加ノードが他のノードの作業を検証することになっている、分散型システムにおいて生じ得る。さらに、検証者に対する補償がその速度と共に（統計的に）増加し、かつ、検証者がチェックしている結果が１に十分に近い確率で正確であるシステムの場合、大抵のブロックチェーンは、ノードができる限り高速で実行し、かつ正確な結果を伝えるための組み込まれたインセンティブを有する。検証者が、それらの作業に対して補償される場合であっても、全ての結果を盲目的に承認することは、そのような環境において依然として最も有益な戦略となり得る。なぜならば、この戦略は、時間を節約するだけでなく、ハードウェアについての費用および検証作業のためのエネルギーも節約するからである。また、そのような戦略を採用するノードは、長期的には、悪意のあるアクターに対するネットワークのレジリエンスを弱体化させる。

いくつかの実施形態において、説明されるシステムは、検証者のジレンマを、そのアーキテクチャを通じて軽減する。具体的には、いくつかの実施形態において、検証ノードは、それらに対して割り当てられたチャンクの実行トレースを検証ノードが知っていることを証明しなければならず、検証ノードは、誤った結果を承認するとスラッシュされ、誤った結果をチェックする少数の誠実な検証ノードは、誤った結果を生成した実行ノード、および、それを承認した全ての検証ノードをスラッシュするのに十分である。

問題の理論的／数学的な抽象化
Ｇ_１およびＧ_２を、２つの巡回群とし、ｇ_１およびｇ_２を、それぞれＧ_１およびＧ_２のジェネレータとする。計算ｃｏ－Ｄｉｆｆｉｅ－Ｈｅｌｌｍａｎ（ｃｏ－ＣＤＨ：Ｃｏｍｐｕｔａｔｉｏｎａｌｃｏ－Ｄｉｆｆｉｅ－Ｈｅｌｌｍａｎ）問題は、

を与えられると、ｇ_１ ^ｘｙを計算することである。ｃｏ－ＣＤＨ仮定は、ｃｏ－ＣＤＨ問題を無視できない確率で解く確率的多項式時間アルゴリズムは存在しないというものである。

関連する問題は、分割可能な計算ｃｏ－ＤｉｆｆｉｅＨｅｌｌｍａｎ問題（ｃｏ－ＤＣＤＨ：ＤｉｖｉｓｉｂｌｅＣｏｍｐｕｔａｔｉｏｎａｌｃｏ－ＤｉｆｆｉｅＨｅｌｌｍａｎｐｒｏｂｌｅｍ）であり、

を与えられると、

を計算する。ｃｏ－ＤＣＤＨ仮定は、ｃｏ－ＣＤＨ問題に同様に定義される。２つの仮定は等価であることが示される。

補題１
（Ｇ_１、Ｇ_２）におけるｃｏ－ＤＣＤＨ仮定およびｃｏ－ＣＤＨ仮定は等価である。
証明。ｃｏ－ＤＣＤＨ問題を解く敵対的Ａは、ｃｏ－ＣＤＨ問題も解き、その逆も然りであることが示される。

・ｃｏ－ＣＤＨ＝＞ｃｏ－ＤＣＤＨ：
Ａは、ｃｏ－ＤＣＤＨ課題

を与えられ、ｃｏ－ＣＤＨソルバー・アルゴリズムへのアクセスを有する。

Ａ_ｃｏ－ｃＤＨは、Ｇ_１×Ｇ_２における任意のランダムな（ｒ_１，ｒ_２）について

である。

Ａは、

を計算し、これは、

を出力し、ｃｏ－ＤＣＤＨ課題を解く。

・ｃｏ－ＣＤＨ＜＝ｃｏ－ＤＣＤＨ
Ａは、ｃｏ－ＣＤＨ課題

を与えられ、ｃｏ－ＤＣＤＨソルバー・アルゴリズムへのアクセスを有する。

Ａ_ｃｏ－ＤＣＤＨは、Ｇ_１×Ｇ_２における任意のランダムな（ｒ_１，ｒ_２）について

である。

Ａは、

を計算し、これは、

を出力し、ｃｏ－ＣＤＨ課題を解く。

２つの問題は等価であり、したがって、２つの仮定も等価である。
ＢＬＳ署名
ＢＬＳ署名のスキームの簡単なレビューとして、Ｇ_１、Ｇ_２およびＧ_Ｔを素数位数ｐの３つの巡回群とし、ただし、（Ｇ_１、Ｇ_２）は、双線形群ペアである。ｅを効率的に計算可能な非縮退ペアリングｅ：Ｇ_１×Ｇ_２→Ｇ_Ｔとし、Ｈをハッシュ関数Ｈ：｛０，１｝^＊→Ｇ_１（ランダム・オラクルとしてモデル化）とする。乗法表記法が３つの群のために使用される。署名スキームは、以下のように定義される。

・ＢＬＳＫｅｙＧｅｎ（）→（ｓｋ，ｐｋ）、ただし、

および

・ＢＬＳ－Ｓｉｇｎ（ｓｋ，ｍ）→σ、ただし、σ←Ｈ（ｍ）^ｓｋ∈Ｇ_１
・ＢＬＳ－Ｖｅｒｉｆｙ（ｐｋ，ｍ，ａ）→ｖ∈｛ＯＫ，ＦＡＩＬ｝、ただし、ｖは、ｅ（Ｈ（ｍ），ｐｋ）の場合にはＯＫであり、その他の場合にはＦＡＩＬである。

ダン・ボネー（ＤａｎＢｏｎｅｈ）、ベン・リン（ＢｅｎＬｙｎｎ）、およびホヴァブ・シャッハム（ＨｏｖａｖＳｈａｃｈａｍ）、ヴェイル・ペアリングからの短い署名（ＳｈｏｒｔｓｉｇｎａｔｕｒｅｓｆｒｏｍｔｈｅＷｅｉｌｐａｉｒｉｎｇ）、ＩｎＡＳＩＡＣＲＹＰＴ、２００１年１２月（以下、ボネーら）は、署名スキームが、ランダム・オラクルにおいて、および（Ｇ_１、Ｇ_２）におけるｃｏ－ＣＤＨ仮定の下で、選ばれたメッセージ攻撃の下で既存の偽造に対してセキュアであることを証明した。

登録鍵および秘密鍵モデルの知識
トーマス・リステンパー（ＴｈｏｍａｓＲｉｓｔｅｎｐａｒｔ）およびスコット・ヤイレック（ＳｃｏｔｔＹｉｌｅｋ）、所有の証明の威力：ｒｏｇｕｅ－ｋｅｙ攻撃に対するマルチパーティ署名のセキュア化（Ｔｈｅｐｏｗｅｒｏｆｐｒｏｏｆｓ－ｏｆ－ｐｏｓｓｅｓｓｉｏｎ：Ｓｅｃｕｒｉｎｇｍｕｌｔｉｐａｒｔｙｓｉｇｎａｔｕｒｅｓａｇａｉｎｓｔｒｏｇｕｅ－ｋｅｙａｔｔａｃｋｓ）、ＩｎＥＵＲＯＣＲＹＰＴ、２００７年５月（以下、リステンパーら）は、登録鍵モデルを定義しており、これは、プロトコルＲ＝（Ｒｅｇ－Ｐｒｏｖｅ、Ｒｅｇ－Ｖｅｒｉｆｙ）である。

・Ｒｅｇ－Ｐｒｏｖｅ（ｓｋ，ｐｋ）→πは、登録証明を生成する。
・Ｒｅｇ－Ｖｅｒｉｆｙ（ｐｋ，π）→｛ＯＫ，ＦＡＩＬ｝は、ｐｋについて証明が有効である場合にはＯＫを出力し、その他の場合にはＦＡＩＬを出力する。

鍵登録が必要とされない場合、（Ｒｅｇ－Ｐｒｏｖｅ，Ｒｅｇ－Ｖｅｒｉｆｙ）は、以下のような空関数と置換されることが可能である。すなわち、いかなる入力に対しても、Ｒｅｇ－Ｐｒｏｖｅは、空の文字列を出力し、Ｒｅｇ－Ｖｅｒｉｆｙは、ＯＫを出力する。

以下のＢＬＳ署名セクションに基づく証明においては、当事者が、当事者の公開鍵に対応する秘密の知識を証明する鍵登録プロトコルのクラスが考慮され、これは、秘密鍵の知識（ＫＯＳＫ：ｋｎｏｗｌｅｄｇｅｏｆｓｅｃｒｅｔｋｅｙ）モデルと呼ばれる。このモデルにおいては、全ての当事者が、関数Ｒ_ＫＯＳＫ＝（ＫＯＳＫ－Ｐｒｏｖｅ，ＫＯＳＫ－Ｖｅｒｉｆｙ）へのアクセスを有し、これは、それぞれ証明を生成し、検証する。

このモデルをインスタンス化するために、当事者は、当事者の秘密の知識のゼロ知識証明（ＺＫＰＫ：ｚｅｒｏ－ｋｎｏｗｌｅｄｇｅｐｒｏｏｆｏｆｋｎｏｗｌｅｄｇｅ）を使用することを必要とされる。ＺＫＰＫに基づく鍵登録プロトコルは、基盤となるＺＫＰＫから継承する、２つの付加的なアルゴリズム、すなわち、ＫＯＳＫ－ＳｉｍｕｌａｔｅとＫＯＳＫ－Ｅｘｔｒａｃｔとを提供する。

・ＫＯＳＫ－Ｓｉｍｕｌａｔｅ（ｐｋ）→πは、証明検証のために使用されるランダム性へのアクセスを与えられると、実際の証明と計算上判別不能な証明を出力するシミュレータである。

・ＫＯＳＫ－Ｅｘｔｒａｃｔ（ｐｋ，π）→ｓｋは、説得力のある証明からｓｋを出力するために、πを生成した当事者と相互作用する（特に、巻き戻す）抽出器である。
シミュレーションおよび抽出は、ＺＫＰＫについての標準的な概念であるため、それらは、より正式には定義されない。

証明スキーム
例示的な分散型計算システムにおいて、誠実な実行ノードおよび検証ノードは、それらのステーキング秘密鍵と、本明細書において機密知識と称される秘密とを使用して、証明を生成する。コンセンサス・ノードは、実行ノードおよび検証ノードによって生成された証明を、対応する公開鍵を使用して検証する。検証プロセスは、全ての証明が同じ機密知識に基づいて生成されたことを確実にすべきである。このユース・ケースに基づいて、スキームの一般的な定義が与えられる。

スキーム定義
定義１
機密知識の特殊な証明は、４つのアルゴリズムを含み得る。

・ＳＰ－Ｓｅｔｕｐ（１^λ）→ｐｐ。パブリック・パラメータｐｐを生成し、これは、残りのアルゴリズムへの黙示的入力である。
・

秘密鍵と公開鍵とのペアを出力する。

・ＳＰ－Ｐｒｏｖｅ（ｓｋ，ｍ）→ａ。秘密鍵ｓｋの下でメッセージｍについての証明を生成する。
・ＳＰ－Ｖｅｒｉｆｙ（ｐｋ_ａ，σ_ａ，ｐｋ_ｂ，σ_ｂ）→ｖ∈｛ＯＫ，ＦＡＩＬ｝。ｐｋ_ａに対応する秘密ｓｋ_ａについて、および同様に、ｐｋ_ｂに対応する秘密ｓｋ_ｂについて、
∃ｍ：ＳＰ－Ｐｒｏｖｅ（ｓｋ_ａ，ｍ）＝σ_ａ∧ＳＰ－Ｐｒｏｖｅ（ｓｋ_ｂ，ｍ）＝σ_ｂ
の場合にはＯＫを返し、せいぜい無視できる確率のときを除き、その他の場合にはＦＡＩＬを返す。

証明が、同じ機密知識から誠実に生成される場合、ＳＰ－Ｖｅｒｉｆｙは、高い確率でＯＫを出力することを必要とされ、これは、スキームの正確性を定義する。
定義２
正確性。スキームは、

の場合には正確であり、ただし、ｎｅｇｌ（λ）は、セキュリティ・パラメータλにおいて無視できる関数である。

本スキームは、上記の登録鍵モデル・セクションにおいても定義されている。この場合において、正確性の条件は、登録鍵に対してのみ成立する。
ＳＰ－Ｖｅｒｉｆｙ定義は、σ^－ _ａおよびσ^－ _ｂと整合するメッセージｍの存在のみを必要とする。この定義は、２つの当事者に対しては十分であるが、それを３つ以上の当事者に対して拡大することは、より繊細である。理由を理解するために、ｓｋ_ａおよびｓｋ_ｂの所有者が秘密ｍ_１を共有し、一方で、ｓｋ_ａおよびｓｋ_ｃの所有者が秘密のｍ_２を共有する場合を考慮する。ＳＰ－Ｖｅｒｉｆｙの定義によって、ＳＰ－Ｖｅｒｉｆｙ（ｐｋ_ａ，σ_ａ，ｐｋ_ｂ，σ_ｂ）およびＳＰ－Ｖｅｒｉｆｙ（ｐｋ_ａ，σ_ａ，ｐｋ_ｃ，σ_ｃ）は両方とも、ｍ_１≠ｍ_２の場合であっても、ＯＫを出力し得る。結果として、これらの２つのチェックは、ｓｋ_ｂおよびｓｋ_ｃの所有者が任意の秘密を共有することを保証するのには十分ではない。

しかしながら、例示的な分散型計算システムにおいて、検証プロセスは、ｓｋ_ａ、ｓｋ_ｂ、およびｓｋ_ｃの保持者全てが同じ秘密知識ｍを共有すること（および、３より大きいグループについても同様）を確実にするために採用されることが可能であることを思い出されたい。この特性を反映するために、スキームについての強い推移性が定義される。

定義３
強い推移性。全ての整数ｎ≧３について、全ての有効な鍵ペア（ｓｋ_１，ｐｋ_１），．．．．，（ｓｋ_ｎ，ｐｋ_ｎ）について、および全ての証明σ_１，．．．，σ_ｎについて、以下の特性が満たされる場合、スキームは強い推移性を満たす。

全てのｉについて、ＳＰ－Ｐｒｏｖｅ（ｓｋ_ｉ，ｍ）＝σ_ｉとなるメッセージｍが存在する場合、全ての証明σ_ｉは互いに検証し合い、すなわち、全ての１≦ｉについて、ｊ≦ｎ，ｊ，ＳＰ－Ｖｅｒｉｆｙ（ｐｋ_１，σ_１，ｐｋ_ｉ，σ_ｉ）＝ｓｕｃｃｅｓｓである。

強い推移性の定義は、複数の証明が同じ基準証明σ_ｉを検証する場合、これらの証明が互いに検証するべきであるだけでなく（推移性）、これらの証明（基準証明を含む）全てが生成され得るメッセージｍが存在すると述べている。

例示的な分散型計算システムにおいて、実行ノードは、基準証明を生成し、一方で、複数の証明は、異なる検証ノードによって生成される。強い推移性を満たすスキームの場合、全てのノードが同じ秘密知識を共有することを確実にするためには、全ての証明を単一の実行ノードの証明に対して検証すれば十分である。

スキーム・セキュリティ
コンセンサス・ノードは、ＳＰ－Ｖｅｒｉｆｙアルゴリズムを実行するために、２つの証明および対応する鍵以外に、機密知識についてのいかなる情報も必要としない。直観的に、機密知識は、ブロックを実行した当事者を除いて、ネットワーク内の全ての当事者に対して秘密のままであるべきである。これは、証明が機密知識を回復することを可能にするべきでないことを意味する。

より具体的には、スキームは、秘密知識を回復するか、またはその知識へのアクセスなしに証明を偽造する、悪意のあるアクターに対して耐性があるべきである。例示的な分散型計算システムにおいて、そのような攻撃は、秘密を知っていると主張しながら、コストのかかるブロック実行をスキップしようとする「怠惰な」検証ノードによって仕かけられ得る。攻撃者は、例えば、障害のある結果に対して、より多くの「投票」を蓄積するために、別のノードに代わって証明を偽造しようと試みることもある。

直観的に、証明を生成することは、２つの秘密、すなわち、鍵ｓｋとメッセージｍとを知っていることを必要とする。この直観は、２つのセキュリティ・ゲームを介して以下に定式化され、各々が挑戦者Ｃと敵対者Ａとの間のものである。第１のゲーム、すなわち、知識偽造は、怠惰なノードが、機密知識ｍを知らずに、それ自体の鍵の下で証明を偽造する能力をモデル化する。第２のゲーム、すなわち、鍵偽造は、悪意のあるノードが、対応する秘密鍵を知らずに、別のノードの公開鍵の下で何らかの選ばれたｍについての証明を作成する能力をモデル化する。これらのゲームは、鍵登録スキーム（Ｒｅｇ－Ｐｒｏｖｅ，Ｒｅｇ－Ｖｅｒｉｆｙ）を仮定して定義されており、これは、登録が必要とされない場合、空のスキームになり得る。

定義４
知識偽造ゲーム。
・セットアップ。Ｃはランダムなメッセージ

をサンプリングする。

・クエリ。ＡはＣに対して任意の数のクエリを行う。そのような各クエリについて、Ｃは新しい鍵

をサンプリングし、登録証明π←Ｒｅｇ－Ｐｒｏｖｅ（ｓｋ_ｉ，ｐｋ_ｉ）および証明σ_ｉ←ＳＰ－Ｐｒｏｖｅ（ｓｋ_ｉ，ｍ）を計算し、（ｐｋ_ｉ，π_ｉ，σ_ｉ）をＡへ送る。

・出力。敵対者は、（ｐｋ_ａ、π_ａ、σ_ａ）を出力し、

の場合、ゲームに勝利する。

定義５
鍵偽造のゲーム。
・セットアップ。Ｃは、

をサンプリングし、π←Ｒｅｇ－Ｐｒｏｖｅ（ｓｋ_ｃ，ｐｋ_ｃ）を計算し、（ｐｋ_ｃ，π_ｃ）をＡへ送る。Ｃは、２つのリスト、すなわち、最初は空であるＬ_ｍ、およびタプル（ｓｋ_ｃ，ｐｋ_ｃ）を最初に含有するＬ_ｋも初期化する。

・クエリ。Ａは、任意の数の２つのタイプのクエリを任意の順序で行い得る。
－Ｑ１：Ａは、（ｍ_ｉ，ｐｋ_ｑ）をＣへ送る。Ｃは、ｐｋ＝ｐｋｇであるＬ_ｋにおいて、最初のタプル（ｓｋ、ｐｋ）を取り出す。そのようなタプルがない場合、Ｃは⊥を返す。そうでない場合、Ｃは、σ_ｉ←ＳＰ－Ｐｒｏｖｅ（ｓｋ_ｉ，ｍ_ｉ）を計算し、σ_ｉをＡへ送る。最終的に、ｐｋ＝ｐｋ_ｃである場合、Ｃはｍ_ｉｍｉをリストＬ_ｍに対して追加する。

－Ｑ２：Ａは、空のクエリをＣへ送り、Ｃは、

をサンプリングし、リストＬ_ｋに対して（ｓｋ_ｉ，ｐｋ_ｉ）、π_ｉ←Ｒｅｇ－Ｐｒｏｖｅ（ｓｋ_ｉ，ｐｋ_ｉ）を計算し、（ｐｋ_ｉ，π_ｉ）をＡへ送る。

・出力。Ａは、（ｍ_ｏ，σ_ａ，ｐｋ_ｏ）を出力し、

の場合、勝利する。

敵対者が機密知識または秘密鍵のいずれも有していない場合を取り込むために、第３のゲームを定義してもよい。この場合は、攻撃者が秘密またはターゲットの鍵のいずれも知らない場合に、ターゲット・ノードが何らかの秘密に対するアクセスを有すると主張するために、例示的な分散型計算システム内で証明を偽造することに対応する。この偽造は、２つの他のゲームよりも明らかに困難である。そのような偽物に成功するアルゴリズムを有する敵対者は、他の２つのゲームのいずれかに簡単に勝利し得る。したがって、このゲームは考慮されない。

定義６
偽造不可能性。せいぜい無視できる確率のときを除き、確率的多項式時間敵対者Ａが知識偽造に勝利しない場合、スキームは、知識偽造に対してセキュアである。せいぜい無視できる確率のときを除き、確率的多項式時間敵対者Ａが鍵偽造に勝利しない場合、スキームは、鍵偽造に対してセキュアである。スキームが知識偽造と鍵偽造との両方に対してセキュアである場合、スキームは偽造不可能である。

スキームのもう一つの特性、すなわち頑強性が定義される。直観的に、証明σ_ｂおよび２つの公開鍵ｐｋ_ａおよびｐｋ_ｂについて、（σ_ｂ、ｐｋ_ｂ、ｐｋ_ａ）を検証する証明ａ_ａを与えられると、（σ_ｂ、ｐｋ_ｂ、ｐｋ_ａ）も検証する別個の証明σ’_ａを生産することは実行不可能である。上記の例示的な分散型計算システムなどの、様々なシステムを介したスキームの実装は、この特性を有することを必要としないが、実際には、頑強性は、繊細な攻撃を除去することができる。

定義７
頑強性。全ての確率的多項式時間敵対者Ａについて、

の場合、スキームは頑強性である。

頑強性に関連する、わずかにより強い概念は、独自性である。
定義８－独自性
全ての証明σ_ａについて、ならびに全ての公開鍵ｐｋ_ａおよびｐｋ_ｂについて、ＳＰ－Ｖｅｒｉｆｙ（ｐｋ_ａ，σ_ａ，ｐｋ_ｂ，σ_ｂ）＝ＯＫとなる一意の証明ａｂが存在する場合、スキームは独自性を満たす。

必然的帰結１
独自性を満たすスキームは、頑強性でもある。
ＢＬＳ署名に基づくスキーム
このセクションにおいて、スキームがＢＬＳ署名を用いて実装され、定義される。これは、ＢＬＳ－ＳＰｏＣＫスキーム、すなわち、本明細書において論じられている機密知識の特殊な証明スキームを用いてＢＬＳ署名を組み込むことと称され得る。

定義９
ＢＬＳ－ＳＰｏＣＫは、４つのアルゴリズム、すなわち、ＢＳＰ－Ｓｅｔｕｐ、ＢＳＰ－ＫｅｙＧｅｎ、ＢＳＰ－ＰｒｏｖｅおよびＢＳＰ－Ｖｅｒｉｆｙを備える。

・ＢＳＰ－Ｓｅｔｕｐ（１^λ）→ｐｐ_ＢＬＳ：以下を含むパブリック・パラメータを出力する。
－生成器ｇ_１およびｇ_２をそれぞれ用いるｐ次の双線形群ペア（Ｇ_１，Ｇ_２）。

－ｐ次のターゲット・グループＧ_Ｔ。
－非縮退ペアリングｅ：Ｇ_１×Ｇ_２→Ｇ_Ｔ。
－ハッシュ関数Ｈ：｛０，１｝^＊→ランダム・オラクルとしてモデル化されたＧ_１
・ＢＳＰ－ＫｅｙＧｅｎ（）→（ｓｋ、ｐｋ）：（ｓｋ，ｐｋ）←ＢＳＰ－ＫｅｙＧｅｎ（）∈（Ｚ_ｐ×Ｇ_２）を出力する。

・ＢＳＰ－Ｐｒｏｖｅ（ｓｋ，ｍ）→σ：σ←ＢＳＰ－Ｓｉｇｎ（ｓｋ，ｍ）∈Ｇ_１を出力する。
言いかえれば、σは、秘密鍵ｓｋの下でのメッセージｍのＢＬＳ署名である。

・ＢＳＰ－Ｖｅｒｉｆｙ（ｐｋ_ａ，σ_ａ，ｐｋ_ｂ，σ_ｂ）→ｖ∈｛ＯＫ，ＦＡＩＬ｝：ｅ（σ_ａ，ｐｋ_ｂ）＝ｅ（σ_ｂ，ｐｋ_ａ）の場合、ＯＫを出力する。
それ以外の場合、ＦＡＩＬを出力する。

そのため、検証は、本明細書において論じられているペアリング特徴を使用することを含む、ペアリング同等性チェックを使用して行われ得る。
補題２
ＢＬＳ－ＳＰｏＣＫスキームは、正確なスキームである。

証明。任意のメッセージｍ、および鍵ペア（ｓｋ_ａ，ｐｋ_ａ）、（ｓｋ_ｂ，ｐｋ_ｂ）について、ｅの定義によって、以下が提供される。

これは、ｅ（ＢＳＰ－Ｐｒｏｖｅ（ｓｋ_ａ，ｍ），ｐｋ_ｂ）＝ｅ（ＢＳＰ－Ｐｒｏｖｅ（ｓｋ_ｂ，ｍ），ｐｋ_ａ）であり、定義２を満たすことを意味する。

補題３
ＢＬＳ－ＳＰｏＣＫスキームは、強い推移性を満たす。
証明。整数ｎを３より大きいものとし、ｎ個の有効な鍵ペアのセットを（ｓｋ_１，ｐｋ_１），．．．，（ｓｋ_ｎ，ｐｋ_ｎ）、およびｎ個の証明のセットをσ_１、．．．σ_ｎとし、それにより、
∀ｉ∈｛２，．．．，ｎ｝：ＢＳＰ－Ｖｅｒｉｆｙ（ｐｋ_１，σ_１，ｐｋ_ｉ，σ_ｉ）＝ＯＫ
ペアリングｅの双線形性によって、およびＧ_Ｔは素数位の巡回群であるので、全ての１≦ｉ≦ｎについて、

が導出され、したがって、

である。その場合、

は、Ｈ（ｍ）＝ｈを満たす何らかのメッセージｍが存在するＧ_１における要素である。メッセージｍは、全ての１≦ｉ≦ｎについて、

を明らかに満たし、これは強い推移性を確立する。

必然的帰結２
ＢＬＳ－ＳＰｏＣＫスキームは、独自性（定義８）を満たす。
証明。ｐｋ_ａ，ｐｋ_ｂ∈Ｇ_２およびσ_ａ∈Ｇ_１とする。σ_ａ、ｐｋ_ａ、およびｐｋ_ｂを検証するＧ_１の要素は、

と書かれ得ることに留意されたい。したがって、σは、ｐｋ_ａおよびｐｋ_ｂを検証するＧ_１の一意の要素である。

必然的帰結３
ＢＬＳ－ＳＰｏＣＫスキームは、頑強性ではない。
セキュリティ証明
このセクションにおいて、ＢＬＳ－ＳＰｏＣＫスキームは、定義６におけるような偽造に対してセキュアであることを示される。ＢＬＳ－ＳＰｏＣＫは、個々の対数についてシュノア（Ｓｃｈｎｏｒｒ）の知識のゼロ知識証明を使用して、ＫＯＳＫモデルにおいてインスタンス化されることが、仮定される。

定理１
ＢＬＳ－ＳＰｏＣＫスキームは、ＫＯＳＫモデルにおける（Ｇ_１，Ｇ_２）におけるｃｏ－ＣＤＨ仮定の下での知識偽造に対してセキュアである。

証明。知識偽造を見破る敵対者Ａ_ｋｎｏｗは、ｃｏ－ＤＣＤＨ（および、したがって、ｃｏ－ＣＤＨ；補題１）を見破るためのブラック・ボックスとして使用されることが可能であることが示される。そうするために、知識偽造ゲームの場合には挑戦者として、およびｃｏ－ＤＣＤＨゲームの場合は敵対者として作用するアルゴリズムＣ_ｋｎｏｗが構築される。

初めに、Ｃ_ｋｎｏｗは、ｃｏ－ＤＣＤＨ課題

を要求する。Ａのクエリの各々について、Ｃ_ｋｎｏｗは、

をサンプリングし、

、

、およびπ_ｉ←ＫＯＳＫ－Ｓｉｍｕｌａｔｅ（ｐｋ_ｉ）を設定し、（ｐｋ_ｉ，π_ｉ，σ_ｉ）をＡへ送る。最後に、Ａ_ｋｎｏｗは、（ｐｋ_ａ，π_ａ，σ_ａ）により応答し、Ｃ_ｋｎｏｗは、ＫＯＳＫ－Ｖｅｒｉｆｙ（ｐｋ_ａ，π_ａ）＝ＦＡＩＬの場合、または

の場合、アボートする。

Ａ_ｋｎｏｗが知識偽造を見破るという仮定Ｃ_ｋｎｏｗによって、無視できない確率で起こる、Ｃがアボートしないということを仮定する。その場合、Ｃ_ｋｎｏｗは、まず、ｓｋ_ａ←ＫＯＳＫ－Ｅｘｔｒａｃｔ（π_ａ）を計算し、次いで、ｃｏ－ＤＣＤＨゲームについて

を回答することによって、ｃｏ－ＤＣＤＨゲームに勝利する。

これが作用する理由を理解するために、何らかのｉについてＢＳＰ－ＶｅｒｉｆｙがＯＫを返したので、ｅ（σ_ａ，ｐｋ_ｉ）＝ｅ（σ_ｉ，ｐｋ_ａ）が提供され、これは、

を意味し、したがって、

、すなわち、正確なｃｏ－ＤＣＤＨの回答である。さらに、全てのｐｋ_ｉ、π_ｉ、およびσ_ｉは、実際の知識偽造ゲームにおけるように分散され、ｓｋ_ｉ＝ｙ・ｒ_ｉは、ｐｋ_ｉに対応する一様にランダムな秘密鍵であり、

およびπ_ｉは、ＫＯＳＫ－Ｓｉｍｕｌａｔｅの定義によって、ＫＯＳＫ照明から判別不能である。

したがって、Ｃ_ｋｎｏｗは、ちょうどＡ_ｋｎｏｗが勝利したときに、ｃｏ－ＤＣＤＨゲームに勝利し、ＫＯＳＫ－Ｓｉｍｕｌａｔｅは、説得力のあるπ_ｉを出力し、ＫＯＳＫ－Ｅｘｔｒａｃｔは、ｓｋ_ａを出力する。ＫＯＳＫ－ＳｉｍｕｌａｔｅおよびＫＯＳＫ－Ｅｘｔｒａｃｔは、定義によって圧倒的な確率で成功するので、Ｃ_ｋｎｏｗは、無視できない確率でｃｏ－ＤＣＤＨゲームに勝利する。補題１によって、これは、ｃｏ－ＣＤＨが困難であるという仮定と矛盾するので、Ａ_ｋｎｏｗは、無視できない確率で知識偽造に勝利することができない。

定理２
いくつかの例において、ＢＬＳ－ＳＰｏＣＫスキームは、（Ｇ_１，Ｇ_２）におけるｃｏ－ＣＤＨ仮定の下で、ランダム・オラクル・モデルにおける鍵偽造に対してセキュアである。

証明。鍵偽造ゲームに勝利するためには、Ａは、メッセージｍ_ｏについてＢＬＳ－ＳＰｏＣＫ証明σ_ｏを偽造しなければならず、それにより、何らかの誠実に生成された鍵ペア（ｐｋ，ｓｋ）について、σ_ｏは、ｐｋ_ｃ、ｐｋ、およびＢＳＰ－Ｐｒｏｖｅ（ｓｋ，ｍ_ｏ）を検証する。ＢＬＳ－ＳＰｏＣＫ証明の独自性によって、

でなければならず、これは鍵ペア（ｓｋ_ｃ，ｐｋ_ｃ）に対するＢＬＳ署名メッセージｍ_ｏである。言いかえれば、鍵偽造に勝利することは、ｍ_ｏについてＢＬＳ署名を偽造することを必要とする。ボネーらは、ランダム・オラクル・モデルにおいて、および（Ｇ_１，Ｇ_２）についてのｃｏ－ＣＤＨ仮定の下で、選ばれたメッセージについての存在的偽造に対するＢＬＳ署名のセキュリティ（すなわち、ＥＵＦ－ＣＭＡセキュリティ）を証明しており、これは定理を証明する。

必然的帰結４
いくつかの例において、ＢＬＳ－ＳＰｏＣＫスキームは、ＫＯＳＫにおいて偽造不可能であり、（Ｇ_１，Ｇ_２）におけるｃｏ－ＣＤＨ仮定の下でランダム・オラクル・モデルであり得る。

図４～図７は、システムおよび／または証明スキームの様々な上述した特性を説明する例示的なフロー図を描く。フローチャートは、ユーザ、すなわち、アリス、ボブおよびイブと、検証者、すなわち、オスカーとを描く。ユーザは、ユーザのそれぞれの秘密鍵（ｓｋ＿ａ、ｓｋ＿ｂ、ｓｋ＿ｅ）を用いて（ユーザが共有されているメッセージ（ｍ）に対するアクセスを有する場合には、共有されているメッセージ（ｍ）も用いて）証明（ｐ＿ａ、ｐ＿ｂ、ｐ＿ｅ）を生成する。検証者は、提供される証明を検証するためにＶｅｒｉｆｙ関数を採用する。いくつかの実施形態において、ユーザおよび検証者は各々、図１～図２に描かれたコンピューティング・デバイス１０２、１０４、１０６、１０８、および図１０に描かれたコンピューティング・デバイス１０１０などのコンピューティング・デバイスを採用して、上記に詳細に説明されたような、それぞれのＰｒｏｏｆ関数またはＶｅｒｉｆｙ関数を実行する。例えば、ユーザおよび検証者は、上述した例示的な分散型計算システムなどのシステムにおいて、ノードとして動作していてもよい。

いくつかの例において、Ｖｅｒｉｆｙ関数は、（例えば、図５に例示される）推移性に対応し得る。推移性定義は、同じ基準証明σ_ｉに対する複数の証明の検証が行われた場合、これら複数の証明の互いに対する検証が行われたとするべきであるだけでなく（推移性）、これらの証明（基準証明を含む）全ての生成元となったメッセージｍが存在することを述べている。Ｖｅｒｉｆｙ関数ならびに認証および検証におけるその使用に関する付加的な情報は、図４～図７に（例えば、「Ｖｅｒｉｆｙ（）」等として）例示される。

図４は、スキームの正確性特性を示すフローチャートを描く。描かれるように、証明者ユーザ、すなわち、アリスおよびボブは、システムにおける、彼らのそれぞれの秘密鍵（ｓｋ＿ａ、ｓｋ＿ｂ）、秘密データ（ｍ）、および他の公開鍵に対するアクセスを有する（知っている）。Ｐｒｏｏｆ関数を使用して、証明者ユーザは各々、彼らのそれぞれの秘密鍵（ｓｋ＿ａ、ｓｋ＿ｂ）および秘密データ（ｍ）を用いて、秘密データ（ｍ）の知識の特殊な証明（ｐ＿ａ、ｐ＿ｂ）を生成する。検証者、すなわちオスカーは、システムにおける、これらの生成された特殊な証明（ｐ＿ａ、ｐ＿ｂ）および他の公開鍵に対するアクセスを有する。オスカーは、秘密データ（ｍ）に対するアクセスを特に有しない。証明者ユーザの各々について、提供される特殊な証明（ｐ＿ａ、ｐ＿ｂ）およびそれぞれの公開鍵（ｐｋ＿ａ、ｐｋ＿ｂ）を用いてＶｅｒｉｆｙ関数を採用して、オスカーは、秘密データ（ｍ）のコンテンツについての知識を獲得せずに、証明者ユーザが同じ秘密データ（ｍ）を共有しているかどうかを決定することができる。提供される特殊な証明（ｐ＿ａ、ｐ＿ｂ）が、Ｖｅｒｉｆｙ関数を介して検証されない場合（例えば、証明が、同じ秘密データを使用して生成されなかったため、または公開鍵（ｐｋ＿ａ、ｐｋ＿ｂ）が、特殊な証明を生成するために採用されたユーザのそれぞれの秘密鍵（ｐ＿ａ、ｐ＿ｂ）と一致しないため）、提供される特殊な証明（ｐ＿ａ、ｐ＿ｂ）は、オスカーに何も確信させない。

図５は、スキームの強い推移性特性を示すフローチャートを描く。描かれるように、証明者ユーザ、すなわちアリスおよびＢｏｂ＿ｉ（Ｂｏｂ＿１～Ｂｏｂ＿ｎ）は、システムにおける、彼らのそれぞれの秘密鍵（ｓｋ＿ａ、ｓｋ＿ｂ１～ｓｋ＿ｂｎ）、秘密データ（ｍ）、および他の公開鍵に対するアクセスを有する（知っている）。Ｐｒｏｏｆ関数を使用して、証明者ユーザは各々、彼らのそれぞれの秘密鍵（ｓｋ＿ａ、ｓｋ＿ｂ１～ｓｋ＿ｂｎ）および秘密データ（ｍ）を用いて、秘密データ（ｍ）の特殊な証明（ｐ＿ａ、ｐ＿ｂ１～ｐ＿ｂｎ）を生成する。検証者、すなわちオスカーは、システムにおける、これらの生成された特殊な証明（ｐ＿ａ、ｐ＿ｂ１～ｐ＿ｂｎ）および他の公開鍵に対するアクセスを有する。オスカーは、秘密データ（ｍ）に対するアクセスを特に有しない。証明者ユーザの各々について、提供される特殊な証明（ｐ＿ａ、ｐ＿ｂ１～ｐ＿ｂｎ）およびそれぞれの公開鍵（ｐｋ＿ａ、ｐｋ＿ｂ１～ｐｋ＿ｂｎ）を用いてＶｅｒｉｆｙ関数を採用して、オスカーは、秘密データ（ｍ）のコンテンツについての知識を獲得せずに、証明者ユーザＢｏｂ＿１～Ｂｏｂ＿ｎの各々が、証明者ユーザであるアリスと同じ秘密データ（ｍ）を共有しているかどうかを決定することができる。提供される特殊な証明（ｐ＿ａ、ｐ＿ｂｉ）が、Ｖｅｒｉｆｙ関数を介して検証されない場合、提供される特殊な証明（ｐ＿ａ、ｐ＿ｂｉ）は、アリスおよび特定のＢｏｂ＿ｉに関して、オスカーに何も確信させなかったことになる。

図６は、スキームの知識偽造不可能性特性を示すフローチャートを描く。描かれるように、証明者ユーザ、すなわちアリスおよびイブは、システムにおける、彼らのそれぞれの秘密鍵（ｓｋ＿ａ、ｓｋ＿ｅ）および他の公開鍵に対するアクセスを有する（知っている）。しかしながら、アリスのみが、秘密データ（ｍ）に対するアクセスを有しており、イブは、秘密データ（ｍ）に対するアクセスを有しない。Ｐｒｏｏｆ関数を使用して、アリスは、自身の秘密鍵（ｓｋ＿ａ）および秘密データ（ｍ）を用いて、特殊な証明、すなわち（ｐ＿ａ）を生成する。イブは、秘密データ（ｍ）に対するアクセスを有しないので、イブは、自身の秘密鍵（ｐ＿ｅ）を用いて、悪意のあるＰｒｏｏｆ関数を介して、証明、すなわち（ｐ＿ｅ）を生成する（例えば、イブは、イブが秘密データ（ｍ）に対してアクセスを有するとオスカーを騙して信じさせようと試みている）。検証者、すなわちオスカーは、システムにおける、これらの生成された特殊な証明（ｐ＿ａ、ｐ＿ｅ）および他の公開鍵に対するアクセスを有する。オスカーは、秘密データ（ｍ）に対するアクセスを特に有しない。証明者ユーザの各々について、提供される特殊な証明（ｐ＿ａ、ｐ＿ｅ）およびそれぞれの公開鍵（ｐｋ＿ａ、ｐｋ＿ｅ）を用いて、Ｖｅｒｉｆｙ関数を採用して、オスカーは、秘密データ（ｍ）のコンテンツについての知識を獲得せずに、証明者ユーザが、同じ秘密データ（ｍ）を共有しているかどうかを決定することができる。描かれたユース・ケースにおいて、提供される特殊な証明（ｐ＿ａ、ｐ＿ｅ）は、アリスおよびイブが同じ秘密データ（ｍ）に対するアクセスを有するとオスカーに確信させない。

図７は、スキームの鍵偽造不可能性特性を示すフローチャートを描く。描かれるように、証明者ユーザ、すなわちアリスおよびイブは、システムにおける秘密データ（ｍ）および他の公開鍵に対するアクセスを有する（知っている）。しかしながら、アリスは、秘密鍵（ｓｋ＿ａ）に対するアクセスを有し、一方で、イブは、ボブの秘密鍵（ｐｋ＿ｂ）に対するアクセスを有しない。Ｐｒｏｏｆ関数を使用して、アリスは、自身の秘密鍵（ｓｋ＿ａ）および秘密データ（ｍ）を用いて、特殊な証明、すなわち（ｐ＿ａ）を生成する。イブは、ボブの秘密鍵に対するアクセスを有しないので、イブは、秘密データ（ｍ）を用いて悪意のあるＰｒｏｏｆ関数を介して、証明、すなわちｐ＿ｂ’を生成する（例えば、イブは、ボブが秘密データ（ｍ）に対するアクセスを有するとオスカーを騙して信じさせようと試みている）。検証者、すなわちオスカーは、システムにおける、これらの生成された特殊な証明（ｐ＿ａ、ｐ＿ｂ’）および他の公開鍵に対するアクセスを有する。オスカーは、秘密データ（ｍ）に対するアクセスを特に有しない。提供される特殊な証明（ｐ＿ａ、ｐ＿ｂ’）、ならびにアリスに関連付けられた公開鍵（ｐｋ＿ａ）およびボブに関連付けられた公開鍵（ｐｋ＿ｂ）を用いて、Ｖｅｒｉｆｙ関数を採用して、オスカーは、秘密データ（ｍ）のコンテンツについての知識を獲得せずに、アリスとボブとの両方が秘密データ（ｍ）に対するアクセスを有するかどうかを決定することができる。描かれたユース・ケースにおいて、提供される特殊な証明（ｐ＿ａ、ｐ＿ｂ’）は、アリスおよびボブが同じ秘密データ（ｍ）に対するアクセスを有するとオスカーに確信させない。

図８は、例示的な分散型計算システムにおいて（例えば、図３において説明されたような）様々なノードによって実装されることが可能である例示的なプロセス８００のフローチャートを描く。本プロセスは、システムが、共有されているデータを明らかにせずに、共有されているデータをどのように使用して証明を検証するかを示し得る。本プロセスは、必要に応じて、任意の他の適切なシステム、環境、ソフトウェア、およびハードウェア、または、システム、環境、ソフトウェア、およびハードウェアの組み合わせによって行われ得る。いくつかの実施形態において、本プロセスの様々な動作は、並行して、組み合わせて、ループで、または任意の順序で、実行されることが可能である。

８０２において、第１の証明が、第１のノードから受信され、第１の証明は、第１のノードに関連付けられた第１の秘密鍵と、第１のノードと第２のノードとの間で共有されているデータとから生成される。８０２から、プロセス８００は８０４へ進む。

８０４において、第２の証明が、第２のノードから受信され、第２の証明は、共有されているデータと、第２のノードに関連付けられた第２の秘密鍵とから生成される。８０４から、プロセス８００は８０６へ進む。

８０６において、第１の証明および第２の証明が両方とも、共有されているデータから生成されたことが、共有されているデータを明らかにせずに検証される。証明は、第１の秘密鍵に数学的に関連する第１の公開鍵と、第２の秘密鍵に数学的に関連する第２の公開鍵とを使用して検証される。いくつかの実施形態において、第１の証明は、第１のノードに対してのみ帰属可能である。いくつかの実施形態において、第２の証明は、第２のノードに対してのみ帰属可能である。いくつかの実施形態において、第１の証明または第２の証明は、それぞれの公開鍵のみを用いて検証されることが可能ではない。いくつかの実施形態において、第１の証明および第２の証明は各々、それぞれの秘密鍵を用いて生成された、共有されるデータの署名を含む。いくつかの実施形態において、署名は、ＢＬＳ署名スキームに基づく。いくつかの実施形態において、第１の証明および第２の証明の検証は、２つの署名、第１の公開鍵、および第２の公開鍵に基づいたペアリング同等性チェックを含む。いくつかの実施形態において、第１の証明および第２の証明を検証することは、ペアリング同等性チェックを含む。いくつかの実施形態において、第１の証明および第２の証明は、非インタラクティブなプロトコルにおいて生成され、検証される。８０６から、プロセス８００は８０８へ進む。

８０８において、第１の証明および第２の証明が両方とも、共有されるデータから生成されているという検証に基づいて、アクションが行われる。いくつかの実施形態において、第１の証明および第２の証明は、それぞれ第１のノードおよび第２のノードによって公に明らかにされる。いくつかの実施形態において、アクションは、第１の証明の検証および第２の証明が両方とも、共有されているデータから生成されたことを公に明らかにすることを含む。いくつかの実施形態において、共有されるデータは、ブロックチェーン内のブロックの少なくとも１つのトランザクションの実行を証明する実行トレースを含む。いくつかの実施形態において、第１のノードは、実行ノードの計算の正確性を保証するために採用される検証ノードを備える。いくつかの実施形態において、計算は、実行トレースを含む。いくつかの実施形態において、第２のノードは、ブロックの少なくとも１つのトランザクションを実行するために採用される実行ノードを備える。いくつかの実施形態において、検証ノードは、計算が検証されたという証明として、第１の証明をパブリッシュする。いくつかの実施形態において、アクションは、クライアントに対して状態応答を提供することを含み、状態応答は、ブロックについての出力に基づいて決定される。いくつかの実施形態において、計算は、チャンクへと分けられて、並行で独立した手法で、より軽い計算検証が可能になる。いくつかの実施形態において、アクションは、チャンクの各々が、実行ノードおよび検証ノードによって、同じ中間結果から整合して生成されることを調停することを含む。８０８から、プロセス８００は終了する。

図９は、例示的な分散型計算システムにおいて（例えば、図３において説明されたような）様々なノードによって実装されることが可能である例示的なプロセス９００のフローチャートを描く。本プロセスは、システムが、共有されているデータを明らかにせずに、共有されているデータをどのように使用して証明を検証するかを示し得る。本プロセスは、必要に応じて、任意の他の適切なシステム、環境、ソフトウェア、およびハードウェア、または、システム、環境、ソフトウェア、およびハードウェアの組み合わせによって行われ得る。いくつかの実施形態において、本プロセスの様々な動作は、並行して、組み合わせて、ループで、または任意の順序で、実行されることが可能である。

９０２において、証明が、複数のノードの各々から受信され、各証明は、ノード間で共有されているデータと、各ノードに関連付けられたそれぞれの秘密鍵とから生成される。いくつかの実施形態において、証明の各々は、それらのそれぞれのノードによって公に明らかにされる。いくつかの実施形態において、証明の各々はそれぞれの生成するノードにのみ帰着可能である。いくつかの実施形態において、証明の各々は、それぞれの公開鍵のみを用いて検証されることが可能ではない。いくつかの実施形態において、共有されるデータは、ブロックチェーン内のブロックの少なくとも１つのトランザクションの実行を証明する実行トレースを含む。９０２から、プロセス９００は９０４へ進む。

９０４において、証明の各々は、共有されているデータを明らかにせずに、共有されているデータから生成されたものとして検証される。証明は、各々が秘密鍵のそれぞれの１つに数学的に関連する、複数の公開鍵を使用して検証される。いくつかの実施形態において、証明は各々、それぞれの秘密鍵を用いて生成された、共有されているデータの署名を含む。いくつかの実施形態において、証明の検証は、署名および公開鍵に基づいたペアリング同等性チェックを含む。いくつかの実施形態において、署名は、ＢＬＳ署名スキームに基づく。いくつかの実施形態において、証明を検証することは、ペアリング同等性チェックを含む。いくつかの実施形態において、証明は、非インタラクティブなプロトコルにおいて生成され、検証される。いくつかの実施形態において、証明の検証の数は、ノードの数において線形であり、二次関数的ではない。いくつかの実施形態において、証明を検証することは、ノードの数より１つ少ない検証を必要とする。９０４から、プロセス９００は９０６へ進む。

９０６において、証明の検証が、共有されるデータから生成されていることに基づいて、アクションが行われる。いくつかの実施形態において、アクションは、第１の証明の検証および第２の証明が両方とも、共有されるデータから生成されたことを公に明らかにすることを含む。９０６から、プロセス９００は終了する。

いくつかの実施形態において、本明細書において説明されるプラットフォーム、システム、媒体、および方法は、コンピューティング・デバイス、プロセッサ、またはこれらの使用を含む。さらなる実施形態において、コンピューティング・デバイスは、デバイスの機能を実行する、１つまたは複数のハードウェア中央処理ユニット（ＣＰＵ）または汎用グラフィック処理ユニット（ＧＰＵ）を含む。またさらなる実施形態において、コンピューティング・デバイスは、実行可能な命令を行うように構成されたオペレーティング・システムをさらに備える。いくつかの実施形態において、コンピューティング・デバイスは、コンピュータ・ネットワークに対して任意選択で接続される。さらなる実施形態において、コンピューティング・デバイスは、ワールド・ワイド・ウェブに対してアクセスするように、インターネットに対して任意選択で接続される。またさらなる実施形態において、コンピューティング・デバイスは、クラウド・コンピューティング・インフラストラクチャに対して任意選択で接続される。他の実施形態において、コンピューティング・デバイスは、イントラネットに対して任意選択で接続される。他の実施形態において、コンピューティング・デバイスは、データ記憶デバイスに対して任意選択で接続される。

本明細書における説明に従って、適当なコンピューティング・デバイスは、非限定的な例として、クラウド・コンピューティング・リソース、サーバ・コンピュータ、サーバ・クラスタ、デスクトップ・コンピュータ、ラップトップ・コンピュータ、ノート型コンピュータ、サブノート型コンピュータ、ネットブック・コンピュータ、ネットパッド・コンピュータ、ハンドヘルド・コンピュータ、モバイル・スマートフォン、およびタブレット・コンピュータを含む。当業者は、本明細書において説明されるシステムにおける使用のために多くのスマートフォンが適していることを認識するであろう。当業者は、本明細書において説明されるシステムにおける使用のために、任意選択のコンピュータ・ネットワーク接続性を有する、選択したテレビ受像機、ビデオ・プレーヤ、およびデジタル音楽プレーヤが適していることも認識するであろう。適当なタブレット・コンピュータは、当業者に知られている、ブックレット、スレート、および可変の構成を有するタブレット・コンピュータを含む。

いくつかの実施形態において、コンピューティング・デバイスは、実行可能な命令を行うように構成されたオペレーティング・システムを含む。オペレーティング・システムは、例えば、プログラムおよびデータを含むソフトウェアであり、これは、デバイスのハードウェアを管理し、アプリケーションの実行のためのサービスを提供する。当業者は、適当なサーバ・オペレーティング・システムが、非限定的な例として、ＦｒｅｅＢＳＤ、ＯｐｅｎＢＳＤ、ＮｅｔＢＳＤ（登録商標）、Ｌｉｎｕｘ（登録商標）、Ａｐｐｌｅ（登録商標）ＭａｃＯＳＸＳｅｒｖｅｒ（登録商標）、Ｏｒａｃｌｅ（登録商標）、Ｓｏｌａｒｉｓ（登録商標）、ＷｉｎｄｏｗｓＳｅｒｖｅｒ（登録商標）、およびＮｏｖｅｌｌ（登録商標）ＮｅｔＷａｒｅ（登録商標）を含むことを認識するであろう。当業者は、適当なパーソナル・コンピュータ・オペレーティング・システムが、非限定的な例として、Ｍｉｃｒｏｓｏｆｔ（登録商標）Ｗｉｎｄｏｗｓ（登録商標）、Ａｐｐｌｅ（登録商標）ＭａｃＯＳＸ（登録商標）、ＵＮＩＸ（登録商標）、およびＧＮＵ／Ｌｉｎｕｘ（登録商標）などのＵＮＩＸのようなオペレーティング・システムを含むことを認識するであろう。いくつかの実施形態において、オペレーティング・システムは、クラウド・コンピューティングによって提供される。当業者は、適当なモバイル・スマートフォン・オペレーティング・システムが、非限定的な例として、Ｎｏｋｉａ（登録商標）Ｓｙｍｂｉａｎ（登録商標）ＯＳ、Ａｐｐｌｅ（登録商標）ｉＯＳ（登録商標）、ＲｅｓｅａｒｃｈＩｎＭｏｔｉｏｎ（登録商標）ＢｌａｃｋＢｅｒｒｙＯＳ（登録商標）、Ｇｏｏｇｌｅ（登録商標）Ａｎｄｒｏｉｄ（登録商標）、Ｍｉｃｒｏｓｏｆｔ（登録商標）ＷｉｎｄｏｗｓＰｈｏｎｅ（登録商標）ＯＳ、Ｍｉｃｒｏｓｏｆｔ（登録商標）ＷｉｎｄｏｗｓＭｏｂｉｌｅ（登録商標）ＯＳ、Ｌｉｎｕｘ（登録商標）、およびＰａｌｍ（登録商標）ＷｅｂＯＳ（登録商標）を含むことも認識するであろう。

いくつかの実施形態において、コンピューティング・デバイスは、ストレージおよび／またはメモリ・デバイスを含む。ストレージおよび／またはメモリ・デバイスは、一時的にまたは恒久的に、データまたはプログラムを記憶するために使用される、１つまたは複数の物理的装置である。いくつかの実施形態において、デバイスは、揮発性メモリであり、記憶された情報を維持するために電力を必要とする。いくつかの実施形態において、デバイスは、不揮発性メモリであり、コンピューティング・デバイスが電力供給されない場合、記憶された情報を保持する。さらなる実施形態において、不揮発性メモリは、フラッシュ・メモリを含む。いくつかの実施形態において、不揮発性メモリは、ダイナミック・ランダム・アクセス・メモリ（ＤＲＡＭ）を含む。いくつかの実施形態において、不揮発性メモリは、強誘電体ランダム・アクセス・メモリ（ＦＲＡＭ（登録商標））を含む。いくつかの実施形態において、不揮発性メモリは、相変化型ランダム・アクセス・メモリ（ＰＲＡＭ）を含む。他の実施形態において、デバイスは、非限定的な例として、ＣＤ－ＲＯＭ、ＤＶＤ、フラッシュ・メモリ・デバイス、磁気ディスク・ドライブ、磁気テープ・ドライブ、光ディスク・ドライブ、およびクラウド・コンピューティング・ベースのストレージを含むストレージ・デバイスである。さらなる実施形態において、ストレージおよび／またはメモリ・デバイスは、本明細書において開示されているデバイスなどのデバイスの組み合わせである。

いくつかの実施形態において、コンピューティング・デバイスは、ユーザへ視覚情報を送るためのディスプレイを含む。いくつかの実施形態において、ディスプレイは、ブラウン管（ＣＲＴ）である。いくつかの実施形態において、ディスプレイは、液晶ディスプレイ（ＬＣＤ）である。さらなる実施形態において、ディスプレイは、薄膜トランジスタ液晶ディスプレイ（ＴＦＴ－ＬＣＤ）である。いくつかの実施形態において、ディスプレイは、有機発光ダイオード（ＯＬＥＤ）ディスプレイである。様々なさらなる実施形態において、ＯＬＥＤディスプレイは、パッシブ・マトリクスＯＬＥＤ（ＰＭＯＬＥＤ）ディスプレイ、またはアクティブ・マトリクスＯＬＥＤ（ＡＭＯＬＥＤ）ディスプレイである。いくつかの実施形態において、ディスプレイは、プラズマ・ディスプレイである。他の実施形態において、ディスプレイは、ビデオ・プロジェクターである。また他の実施形態において、ディスプレイは、コンピュータと通信する頭部装着型ディスプレイ、例えば、仮想現実（ＶＲ）ヘッドセットなどである。さらなる実施形態において、適当なＶＲヘッドセットは、非限定的な例として、ＨＴＣＶｉｖｅ、ＯｃｕｌｕｓＲｉｆｔ、ＳａｍｓｕｎｇＧｅａｒＶＲ、ＭｉｃｒｏｓｏｆｔＨｏｌｏＬｅｎｓ、ＲａｚｅｒＯｐｅｎ－ＳｏｕｒｃｅＶｉｒｔｕａｌＲｅａｌｉｔｙ（ＯＳＶＲ）、ＦＯＶＥＶＲ、ＺｅｉｓｓＶＲＯｎｅ、ＡｖｅｇａｎｔＧｌｙｐｈ、ＦｒｅｅｆｌｙＶＲｈｅａｄｓｅｔ等を含む。またさらなる実施形態において、ディスプレイは、本明細書において開示されているデバイスなどのデバイスの組み合わせである。

いくつかの実施形態において、コンピューティング・デバイスは、ユーザからの情報を受信するための入力デバイスを含む。いくつかの実施形態において、入力デバイスは、キーボードである。いくつかの実施形態において、入力デバイスは、非限定的な例として、マウス、トラックボール、トラック・パッド、ジョイスティック、ゲーム・コントローラ、またはスタイラスを含むポインティング・デバイスである。いくつかの実施形態において、入力デバイスは、タッチ画面またはマルチタッチ・スクリーンである。他の実施形態において、入力デバイスは、音声または他のサウンド入力を取り込むためのマイクロフォンである。他の実施形態において、入力デバイスは、動きまたは視覚入力を取り込むためのビデオ・カメラまたは他のセンサである。さらなる実施形態において、入力デバイスは、Ｋｉｎｅｃｔ、ＬｅａｐＭｏｔｉｏｎ等である。またさらなる実施形態において、入力デバイスは、本明細書において開示されているデバイスなどのデバイスの組み合わせである。

本開示のプラットフォーム、システム、媒体、および方法を実装するために使用されることが可能であるコンピュータ制御システムが、本明細書において提供される。図１０は、本開示のプラットフォーム、システム、媒体、および方法を実装するようにプログラムされることまたは別の方法で構成されることが可能である例示的なコンピューティング・デバイス１０１０を描く。例えば、コンピューティング・デバイス１０１０は、図１～図２に描かれたコンピューティング・デバイス１０２、１０４、１０６、１０８に関する説明などのようにプログラムされ、または別の方法で構成されることが可能である。

描かれた実施形態において、コンピューティング・デバイス１０１０は、ＣＰＵ（本明細書においては「プロセッサ」および「コンピュータ・プロセッサ」ともいう）１０１２を含み、これは、任意選択で、シングル・コア、マルチ・コア・プロセッサ、または並列処理のための複数のプロセッサである。コンピューティング・デバイス１０１０は、メモリまたはメモリ・ロケーション１０１７（例えば、ランダム・アクセス・メモリ、読み出し専用メモリ、フラッシュ・メモリ）、電子ストレージ・ユニット１０１４（例えば、ハードディスク）、１つまたは複数の他のシステムと通信するための通信インターフェース１０１５（例えば、ネットワーク・アダプタ）、および周辺デバイス１０１６、例えば、キャッシュ、他のメモリ、データ・ストレージまたは電子ディスプレイ・アダプターなども含む。

いくつかの実施形態において、メモリ１０１７、ストレージ・ユニット１０１４、通信インターフェース１０１５、および周辺デバイス１０１６は、マザーボードなどの通信バス（実線）を通じてＣＰＵ１０１２と通信する。ストレージ・ユニット１０１４は、データを記憶するためのデータ・ストレージ・ユニット（またはデータ・リポジトリ）を含む。コンピューティング・デバイス１０１０は、通信インターフェース１０１５の支援により、図１～図２に描かれたネットワーク１１０などのコンピュータ・ネットワークに対して任意選択で動作可能に結合される。いくつかの実施形態において、コンピューティング・デバイス１０１０は、説明されるプラットフォーム内で展開されるバックエンド・サーバとして構成される。

いくつかの実施形態において、ＣＰＵ１０１２は、機械可読命令のシーケンスを実行することができ、これは、プログラムまたはソフトウェアにおいて具現化されることが可能である。命令は、メモリ１０１７などのメモリ・ロケーションにおいて記憶され得る。命令は、ＣＰＵ１０１２に対して向けられることが可能であり、これは、続いて、本開示の方法を実装するようにＣＰＵ１０１２をプログラムすること、または別の方法で構成することができる。ＣＰＵ１０１２によって行われる動作の例は、フェッチ、デコード、実行、およびライト・バックを含むことができる。いくつかの実施形態において、ＣＰＵ１０１２は、集積回路などの回路の一部である。コンピューティング・デバイス１０１０の１つまたは複数の他の構成要素は、任意選択で、回路内に含まれることが可能である。いくつかの実施形態において、回路は、特定用途向け集積回路（ＡＳＩＣ）またはフィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）である。

いくつかの実施形態において、ストレージ・ユニット１０１４は、ファイル、例えば、ドライバ、ライブラリおよび保存されたプログラムなどを記憶することができる。いくつかの実施形態において、ストレージ・ユニット１０１４は、データ、例えば、検出ロジック、企業が遭遇した様々な脅威の分析、脅威を軽減するために行われたトリアージに関するメタデータ、偽陽性、および性能メトリック等などを記憶する。いくつかの実施形態において、コンピューティング・デバイス１０１０は、イントラネットまたはインターネットを通じて通信するリモート・サーバに位置するなど、外部にある、１つまたは複数の付加的なデータ・ストレージ・ユニットを含む。

いくつかの実施形態において、コンピューティング・デバイス１０１０は、ネットワークを通じて、１つまたは複数のリモート・コンピュータ・システムと通信する。例えば、コンピューティング・デバイス１０１０は、リモート・コンピュータ・システムと通信することができる。リモート・コンピュータ・システムの例は、図１～図２に描かれるような、パーソナル・コンピュータ（例えば、ポータブルＰＣ）、スレートもしくはタブレットＰＣ（例えば、Ａｐｐｌｅ（登録商標）ｉＰａｄ（登録商標）、Ｓａｍｓｕｎｇ（登録商標）ＧａｌａｘｙＴａｂ等）、スマートフォン（例えば、Ａｐｐｌｅ（登録商標）ｉＰｈｏｎｅ（登録商標）、Ａｎｄｒｏｉｄ対応デバイス、Ｂｌａｃｋｂｅｒｒｙ（登録商標）等）、または携帯情報端末を含む。いくつかの実施形態において、ユーザは、図１～図２に描かれたようなネットワークを介して、コンピューティング・デバイス１０１０に対してアクセスすることができる。

いくつかの実施形態において、本明細書において説明されるようなプラットフォーム、システム、媒体、および方法は、コンピューティング・デバイス１０１０の電子ストレージ・ロケーション上、例えば、メモリ１０１７または電子ストレージ・ユニット１０１４上などに記憶された機械（例えば、コンピュータ・プロセッサ）実行可能なコードとして実装される。いくつかの実施形態において、ＣＰＵ１０１２は、コードを実行するように適合されている。いくつかの実施形態において、機械実行可能なコードまたは機械可読コードは、ソフトウェアの形態で提供される。いくつかの実施形態において、使用期間中に、コードは、ＣＰＵ１０１２によって実行される。いくつかの実施形態において、コードは、ストレージ・ユニット１０１４から取り出され、ＣＰＵ１０１２による即時アクセスのためにメモリ１０１７上に記憶される。いくつかの状況において、電子ストレージ・ユニット１０１４は除外され、機械実行可能な命令は、メモリ１０１７上に記憶される。いくつかの実施形態において、コードは、プリコンパイルされる。いくつかの実施形態において、コードは、ランタイム期間中にコンパイルされる。コードは、コードがプリコンパイルされた状態またはコンパイルされたままの状態で実行することを可能にするために選択され得るプログラミング言語において供給されることが可能である。

いくつかの実施形態において、コンピューティング・デバイス１０１０は、電子ディスプレイ１０３５を含むこと、または電子ディスプレイ１０３５と通信することができる。いくつかの実施形態において、電子ディスプレイ１０３５は、ユーザ・インターフェース（ＵＩ）１０４０を提供する。

いくつかの実施形態において、本明細書において開示されているプラットフォーム、システム、媒体、および方法は、任意選択でネットワーク接続されたコンピューティング・デバイスのオペレーティング・システムによって実行可能な命令を含むプログラムが符号化された、１つまたは複数の非一時的なコンピュータ可読記憶媒体を含む。さらなる実施形態において、コンピュータ可読記憶媒体は、コンピューティング・デバイスの有形の構成要素である。またさらなる実施形態において、コンピュータ可読記憶媒体は、コンピューティング・デバイスから任意選択で除去可能である。いくつかの実施形態において、コンピュータ可読記憶媒体は、非限定的な例として、ＣＤ－ＲＯＭ、ＤＶＤ、フラッシュ・メモリ・デバイス、ソリッド・ステート・メモリ、磁気ディスク・ドライブ、磁気テープ・ドライブ、光ディスク・ドライブ、クラウド・コンピューティング・システムおよびサービスを含む分散コンピューティング・システム等を含む。いくつかの場合において、プログラムおよび命令は、恒久的に、実質的に恒久的に、半恒久的に、または非一時的に、媒体に符号化される。

いくつかの実施形態において、本明細書において開示されているプラットフォーム、システム、媒体、および方法は、少なくとも１つのコンピュータ・プログラム、またはその使用を含む。コンピュータ・プログラムは、１つまたは複数の特定されたタスクを行うために書き込まれる、コンピューティング・デバイスのＣＰＵにおいて実行可能な命令のシーケンスを含む。コンピュータ可読命令は、特定のタスクを行う、または特定の抽象データ・タイプを実装するプログラム・モジュール、例えば、関数、オブジェクト、アプリケーション・プログラミング・インターフェース（ＡＰＩ）、データ構造等などとして実装され得る。本明細書において提供される本開示に照らして、当業者は、コンピュータ・プログラムが様々な言語の様々なバージョンにおいて書かれ得ることを認識するであろう。

コンピュータ可読命令の機能性は、様々な環境において、所望に応じて組み合わされ、または分散され得る。いくつかの実施形態において、コンピュータ・プログラムは、命令の１つのシーケンスを含む。いくつかの実施形態において、コンピュータ・プログラムは、命令の複数のシーケンスを含む。いくつかの実施形態において、コンピュータ・プログラムは、１つのロケーションから提供される。他の実施形態において、コンピュータ・プログラムは、複数のロケーションから提供される。様々な実施形態において、コンピュータ・プログラムは、１つまたは複数のソフトウェア・モジュールを含む。様々な実施形態において、コンピュータ・プログラムは、部分的にまたは全体的に、１つもしくは複数のウェブ・アプリケーション、１つもしくは複数のモバイル・アプリケーション、１つもしくは複数のスタンドアロン・アプリケーション、１つもしくは複数のウェブ・ブラウザ・プラグイン、拡張機能、アドイン、もしくはアドオン、または、これらの組み合わせを含む。

いくつかの実施形態において、コンピュータ・プログラムは、ウェブ・アプリケーションを含む。本明細書において提供される本開示に照らして、当業者は、ウェブ・アプリケーションが、様々な実施形態において、１つまたは複数のソフトウェア・フレームワークおよび１つまたは複数のデータベース・システムを利用することを認識するであろう。いくつかの実施形態において、ウェブ・アプリケーションは、ソフトウェア・フレームワーク、例えば、Ｍｉｃｒｏｓｏｆｔ（登録商標）の．ＮＥＴまたはＲｕｂｙｏｎＲａｉｌｓ（ＲｏＲ）上などで作成される。いくつかの実施形態において、ウェブ・アプリケーションは、非限定的な例として、リレーショナル・データベース・システム、非リレーショナル・データベース・システム、オブジェクト指向データベース・システム、連想データベース・システム、およびＸＭＬデータベース・システムを含む、１つまたは複数のデータベース・システムを利用する。さらなる実施形態において、適切なリレーショナル・データベース・システムは、非限定的な例として、Ｍｉｃｒｏｓｏｆｔ（登録商標）ＳＱＬＳｅｒｖｅｒ、ｍｙＳＱＬ（商標）、およびＯｒａｃｌｅ（登録商標）を含む。当業者は、ウェブ・アプリケーションが、様々な実施形態において、１つまたは複数の言語の１つまたは複数のバージョンにおいて書かれることも認識するであろう。ウェブ・アプリケーションは、１つまたは複数のマークアップ言語、プレゼンテーション定義言語、クライアント側スクリプト言語、サーバ側コーディング言語、データベース・クエリ言語、または、これらの組み合わせにおいて書かれ得る。いくつかの実施形態において、ウェブ・アプリケーションは、マークアップ言語、例えば、ハイパーテキスト・マークアップ言語（ＨＴＭＬ）、拡張可能なハイパーテキスト・マークアップ言語（ＸＨＴＭＬ）、または拡張可能なマークアップ言語（ＸＭＬ）などにおいて、ある程度まで書かれる。いくつかの実施形態において、ウェブ・アプリケーションは、カスケーディング・スタイル・シート（ＣＳＳ）などのプレゼンテーション定義言語において、ある程度まで書かれる。いくつかの実施形態において、ウェブ・アプリケーションは、クライアント側スクリプト言語、例えば、非同期ＪａｖａＳｃｒｉｐｔ（登録商標）およびＸＭＬ（ＡＪＡＸ：ＡｓｙｎｃｈｒｏｎｏｕｓＪａｖａＳｃｒｉｐｔａｎｄＸＭＬ）、Ｆｌａｓｈ（登録商標）ＡｃｔｉｏｎＳｃｒｉｐｔ、ＪａｖａＳｃｒｉｐｔ、またはＳｉｌｖｅｒｌｉｇｈｔ（登録商標）などにおいて、ある程度まで書かれ得る。いくつかの実施形態において、ウェブ・アプリケーションは、サーバ側コーディング言語、例えば、アクティブ・サーバ・ページ（ＡＳＰ）、ＣｏｌｄＦｕｓｉｏｎ（登録商標）、Ｐｅｒｌ、Ｊａｖａ（登録商標）、ＪａｖａＳｅｒｖｅｒＰａｇｅｓ（ＪＳＰ）、ＨｙｐｅｒｔｅｘｔＰｒｅｐｒｏｃｅｓｓｏｒ（ＰＨＰ）、Ｐｙｔｈｏｎ（商標）、Ｒｕｂｙ、Ｔｃｌ、Ｓｍａｌｌｔａｌｋ、ＷｅｂＤＮＡ（登録商標）、またはＧｒｏｏｖｙなどにおいて、ある程度まで書かれる。いくつかの実施形態において、ウェブ・アプリケーションは、構造化クエリ言語（ＳＱＬ）などのデータベース・クエリ言語において、ある程度まで書かれる。いくつかの実施形態において、ウェブ・アプリケーションは、ＩＢＭ（登録商標）ＬｏｔｕｓＤｏｍｉｎｏ（登録商標）などの企業サーバ製品を一体化する。いくつかの実施形態において、ウェブ・アプリケーションは、メディア・プレーヤ要素を含む。様々なさらなる実施形態において、メディア・プレーヤ要素は、非限定的な例として、Ａｄｏｂｅ（登録商標）Ｆｌａｓｈ（登録商標）、ＨＴＭＬ５、Ａｐｐｌｅ（登録商標）ＱｕｉｃｋＴｉｍｅ（登録商標）、Ｍｉｃｒｏｓｏｆｔ（登録商標）Ｓｉｌｖｅｒｌｉｇｈｔ（登録商標）、Ｊａｖａ（商標）、およびＵｎｉｔｙ（登録商標）を含む、多くの適切なマルチメディア技術のうちの１つまたは複数を利用する。

いくつかの実施形態において、コンピュータ・プログラムは、モバイル・コンピューティング・デバイスに対して提供されるモバイル・アプリケーションを含む。いくつかの実施形態において、モバイル・アプリケーションは、モバイル・アプリケーションが製造されるときにモバイル・コンピューティング・デバイスに対して提供される。他の実施形態において、モバイル・アプリケーションは、本明細書において説明されるコンピュータ・ネットワークを介して、モバイル・コンピューティング・デバイスに対して提供される。

本明細書において提供される本開示を考慮して、モバイル・アプリケーションは、本技術分野において知られているハードウェア、言語、および開発環境を使用して、当業者に知られている技法によって作成される。当業者は、モバイル・アプリケーションがいくつかの言語において書かれることを認識するであろう。適切なプログラミング言語は、非限定的な例として、Ｃ、Ｃ＋＋、Ｃ＃、オブジェクティブＣ、Ｊａｖａ（商標）、ＪａｖａＳｃｒｉｐｔ、Ｐａｓｃａｌ、ＯｂｊｅｃｔＰａｓｃａｌ、Ｐｙｔｈｏｎ（商標）、Ｒｕｂｙ、ＶＢ．ＮＥＴ、ＷＭＬ、およびＣＳＳありもしくはＣＳＳなしのＸＨＴＭＬ／ＨＴＭＬ、または、これらの組み合わせを含む。

適切なモバイル・アプリケーション開発環境は、いくつかのソースから利用可能である。市販の開発環境は、非限定的な例として、ＡｉｒｐｌａｙＳＤＫ、ａｌｃｈｅＭｏ、Ａｐｐｃｅｌｅｒａｔｏｒ（登録商標）、Ｃｅｌｓｉｕｓ、Ｂｅｄｒｏｃｋ、ＦｌａｓｈＬｉｔｅ、．ＮＥＴＣｏｍｐａｃｔＦｒａｍｅｗｏｒｋ、Ｒｈｏｍｏｂｉｌｅ、およびＷｏｒｋＬｉｇｈｔＭｏｂｉｌｅＰｌａｔｆｏｒｍを含む。他の開発環境は、非限定的な例として、Ｌａｚａｒｕｓ、ＭｏｂｉＦｌｅｘ、ＭｏＳｙｎｃ、およびＰｈｏｎｅｇａｐを含めて、コストなしで利用可能である。また、モバイルデバイス製造業者は、非限定的な例として、ｉＰｈｏｎｅおよびｉＰａｄ（ｉＯＳ）ＳＤＫ、Ａｎｄｒｏｉｄ（商標）ＳＤＫ、ＢｌａｃｋＢｅｒｒｙ（登録商標）ＳＤＫ、ＢＲＥＷＳＤＫ、Ｐａｌｍ（登録商標）ＯＳＳＤＫ、ＳｙｍｂｉａｎＳＤＫ、ｗｅｂＯＳＳＤＫ、およびＷｉｎｄｏｗｓ（登録商標）ＭｏｂｉｌｅＳＤＫを含む、ソフトウェア開発者キットを流通させている。

当業者は、非限定的な例として、Ａｐｐｌｅ（登録商標）ＡｐｐＳｔｏｒｅ、Ｇｏｏｇｌｅ（登録商標）Ｐｌａｙ、ＣｈｒｏｍｅＷｅｂＳｔｏｒｅ、ＢｌａｃｋＢｅｒｒｙ（登録商標）ＡｐｐＷｏｒｌｄ、ＰａｌｍデバイスのためのＡｐｐＳｔｏｒｅ、ｗｅｂＯＳのためのＡｐｐＣａｔａｌｏｇ、Ｗｉｎｄｏｗｓ（登録商標）ＭａｒｋｅｔｐｌａｃｅｆｏｒＭｏｂｉｌｅ、Ｎｏｋｉａ（登録商標）デバイスのためのＯｖｉＳｔｏｒｅ、Ｓａｍｓｕｎｇ（登録商標）Ａｐｐｓ、および任天堂（登録商標）ＤＳｉショップを含む、いくつかの商業フォーラムが、モバイル・アプリケーションの流通のために利用可能であることを認識するだろう。

いくつかの実施形態において、本明細書において開示されているプラットフォーム、システム、媒体、および方法は、ソフトウェア、サーバ、および／もしくはデータベース・モジュール、または、これらの使用を含む。本明細書において提供される本開示を考慮して、ソフトウェア・モジュールは、本技術分野において知られている機械、ソフトウェア、および言語を使用して、当業者に知られている技法によって作成される。本明細書において開示されているソフトウェア・モジュールは、多くの手法において実装される。様々な実施形態において、ソフトウェア・モジュールは、ファイル、コードのセクション、プログラミング・オブジェクト、プログラミング構造、または、これらの組み合わせを含む。さらなる様々な実施形態において、ソフトウェア・モジュールは、複数のファイル、コードの複数のセクション、複数のプログラミング・オブジェクト、複数のプログラミング構造、または、これらの組み合わせを含む。様々な実施形態において、１つまたは複数のソフトウェア・モジュールは、非限定的な例として、ウェブ・アプリケーション、モバイル・アプリケーション、およびスタンドアロン・アプリケーションを備える。いくつかの実施形態において、ソフトウェア・モジュールは、１つのコンピュータ・プログラムまたはアプリケーション内にある。他の実施形態において、ソフトウェア・モジュールは、１つを超えるコンピュータ・プログラムまたはアプリケーション内にある。いくつかの実施形態において、ソフトウェア・モジュールは、１つの機械上にホストされる。他の実施形態において、ソフトウェア・モジュールは、１つを超える機械上にホストされる。さらなる実施形態において、ソフトウェア・モジュールは、クラウド・コンピューティング・プラットフォーム上にホストされる。いくつかの実施形態において、ソフトウェア・モジュールは、１つのロケーションにおける、１つまたは複数の機械上にホストされる。他の実施形態において、ソフトウェア・モジュールは、１つを超えるロケーションにおける、１つまたは複数の機械上にホストされる。

いくつかの実施形態において、本明細書において開示されているプラットフォーム、システム、媒体、および方法は、１つもしくは複数のデータベース、またはその使用を含む。本明細書において提供される本開示を考慮して、当業者は、多くのデータベースがデータ記録の記憶および取り出しに適していることを認識するであろう。様々な実施形態において、適切なデータベースは、非限定的な例として、リレーショナル・データベース、非リレーショナル・データベース、オブジェクト指向データベース、オブジェクト・データベース、エンティティ関係モデル・データベース、連想データベース、およびＸＭＬデータベースを含む。さらに非限定的な例は、ＳＱＬ、ＰｏｓｔｇｒｅＳＱＬ、ＭｙＳＱＬ、ＭｏｎｇｏＤＢ、Ｏｒａｃｌｅ、ＤＢ２、およびＳｙｂａｓｅを含む。いくつかの実施形態において、データベースはウェブ・ベースである。またさらなる実施形態において、データベースは、クラウド・コンピューティング・ベースである。他の実施形態において、データベースは、１つまたは複数のローカルのコンピュータ・ストレージ・デバイスに基づく。

Claims

共有されているデータを明らかにせずに、前記共有されているデータから生成される証明を検証するためのコンピュータ実装方法であって、前記コンピュータ実装方法は、
第１のノードから、前記第１のノードに関連付けられた第１の秘密鍵と、前記第１のノードと第２のノードとの間で共有されているデータとから生成された第１の証明を、コンピュータが受信する工程と、
前記第２のノードから、前記共有されているデータと、前記第２のノードに関連付けられた第２の秘密鍵とから生成された第２の証明を、前記コンピュータが受信する工程と、
前記共有されているデータを明らかにせずに、前記第１の証明および前記第２の証明が両方とも、前記第１の秘密鍵に数学的に関連する第１の公開鍵、および前記第２の秘密鍵に数学的に関連する第２の公開鍵を用いて、前記共有されているデータから生成されたことを、前記コンピュータが検証する工程と、
前記第１の証明および前記第２の証明が両方とも、前記共有されているデータから生成されたという前記検証に基づいて、前記コンピュータがアクションを行う工程と
を含み、
前記第１の証明および前記第２の証明は各々、それぞれの前記秘密鍵を用いて生成された、前記共有されているデータの署名を含み、
前記署名は、ボネ・リン・シャチャム（ＢＬＳ）署名スキームに基づき、
前記第１の証明および前記第２の証明の前記検証は、２つの前記署名、前記第１の公開鍵、および前記第２の公開鍵に基づいたペアリング同等性チェックを含む、コンピュータ実装方法。
前記第１の証明および前記第２の証明は、それぞれ前記第１のノードおよび前記第２のノードによって公に明らかにされる、請求項１に記載のコンピュータ実装方法。
前記アクションは、前記第１の証明および前記第２の証明が両方とも、前記共有されているデータから生成されたという前記検証を公に明らかにする工程を含む、請求項１に記載のコンピュータ実装方法。
前記第１の証明は、前記第１のノードに対してのみ帰属可能であり、前記第２の証明は、前記第２のノードに対してのみ帰属可能である、請求項１に記載のコンピュータ実装方法。
前記第１の証明および前記第２の証明は、非インタラクティブなプロトコルにおいて生成され、検証される、請求項１に記載のコンピュータ実装方法。
前記共有されているデータは、ブロックチェーン内のブロックの少なくとも１つのトランザクションの実行を証明する実行トレースを含む、請求項１に記載のコンピュータ実装方法。
前記第１のノードは、実行ノードの計算の正確性を保証するために採用される検証ノードを含み、前記計算は、前記実行トレースを含む、請求項６に記載のコンピュータ実装方法。
前記第２のノードは、前記ブロックの前記少なくとも１つのトランザクションを実行するために採用される前記実行ノードを含み、前記検証ノードは、前記計算が検証されたという証明として、前記第１の証明をパブリッシュする、請求項７に記載のコンピュータ実装方法。
前記アクションは、クライアントに対して状態応答を提供する工程を含み、前記状態応答は、前記ブロックについての出力に基づいて決定される、請求項７に記載のコンピュータ実装方法。
前記計算は、並行で独立した手法で計算検証を可能にするために、チャンクへと分けられ、前記アクションは、前記チャンクの各々が、前記実行ノードおよび前記検証ノードによって、同じ中間結果から整合して生成されることを調停する工程を含む、請求項７に記載のコンピュータ実装方法。
コンピュータによって実行された場合、前記コンピュータに、請求項１から１０のいずれか一項に記載のコンピュータ実装方法を実行させる、コンピュータプログラム。
共有されているデータを明らかにせずに、前記共有されているデータから生成された証明を検証するためのシステムであって、前記システムは、
１つまたは複数のプロセッサと、
前記１つまたは複数のプロセッサに対して結合され、命令が記憶されたコンピュータ可読記憶デバイスであって、前記命令は、前記１つまたは複数のプロセッサによって実行された場合、前記１つまたは複数のプロセッサに、
第１のノードから、前記第１のノードに関連付けられた第１の秘密鍵と、前記第１のノードと第２のノードとの間で共有されているデータとから生成された第１の証明を受信する工程と、
前記第２のノードから、前記共有されているデータと、前記第２のノードに関連付けられた第２の秘密鍵とから生成された第２の証明を受信する工程と、
前記共有されているデータを明らかにせずに、前記第１の証明および前記第２の証明が両方とも、前記第１の秘密鍵に数学的に関連する第１の公開鍵、および前記第２の秘密鍵に数学的に関連する第２の公開鍵を用いて、前記共有されているデータから生成されたことを検証する工程と、
前記第１の証明および前記第２の証明が両方とも、前記共有されているデータから生成されたという前記検証に基づいて、アクションを行う工程と
を含む動作を行わせる、
コンピュータ可読記憶デバイスとを含み、
前記第１の証明および前記第２の証明は各々、それぞれの前記秘密鍵を用いて生成された、前記共有されているデータの署名を含み、
前記署名は、ボネ・リン・シャチャム（ＢＬＳ）署名スキームに基づき、
前記第１の証明および前記第２の証明の前記検証は、２つの前記署名、前記第１の公開鍵、および前記第２の公開鍵に基づいたペアリング同等性チェックを含む、システム。
前記アクションは、前記第１の証明および前記第２の証明が両方とも、前記共有されているデータから生成されたという前記検証を公に明らかにする工程を含む、請求項１２に記載のシステム。
前記共有されているデータは、ブロックチェーン内のブロックの少なくとも１つのトランザクションの実行を証明する実行トレースを含み、前記第１のノードは、実行ノードの計算の正確性を保証するために採用される検証ノードを含み、前記計算は、前記実行トレースを含み、前記第２のノードは、前記ブロックの前記少なくとも１つのトランザクションを実行するために採用される前記実行ノードを含む、請求項１２に記載のシステム。
前記計算は、並行で独立した手法で、より軽量化された計算検証を可能にするために、チャンクへと分けられ、前記アクションは、前記チャンクの各々が、前記実行ノードおよび前記検証ノードによって、同じ中間結果から整合して生成されることを調停する工程を含む、請求項１４に記載のシステム。
１つまたは複数のプロセッサに対して結合され、命令が記憶された、１つまたは複数の非一時的なコンピュータ可読記憶媒体であって、前記命令は、前記１つまたは複数のプロセッサによって実行された場合、前記１つまたは複数のプロセッサに、
複数のノードの各々から、前記ノード間で共有されているデータと、各ノードに関連付けられたそれぞれの秘密鍵とから生成されたそれぞれの証明を受信する工程と、
前記共有されているデータを明らかにせずに、前記証明の各々が、前記秘密鍵のうちの個別の１つに各々が数学的に関連する複数の公開鍵を用いて、前記共有されているデータから生成されたことを検証する工程と、
前記証明が、前記共有されているデータから生成されたという前記検証に基づいて、アクションを行う工程とを含む動作を実行させ、
前記証明は各々、それぞれの前記秘密鍵を用いて生成された、前記共有されているデータの署名を含み、
前記署名は、ボネ・リン・シャチャム（ＢＬＳ）署名スキームに基づき、
前記証明の前記検証は、前記署名、および前記公開鍵に基づいたペアリング同等性チェックを含む、１つまたは複数の非一時的なコンピュータ可読記憶媒体。
前記証明の各々は、それぞれのノードによって公に明らかにされる、請求項１６に記載のコンピュータ可読記憶媒体。
前記アクションは、前記証明のそれぞれが両方とも、前記共有されているデータから生成されたという前記検証を公に明らかにする工程を含む、請求項１６に記載のコンピュータ可読記憶媒体。
前記証明の各々は、それぞれを生成した前記ノードに対してのみ帰属可能である、請求項１６に記載のコンピュータ可読記憶媒体。
前記証明は、非インタラクティブなプロトコルにおいて生成され、検証される、請求項１６に記載のコンピュータ可読記憶媒体。
前記共有されているデータは、ブロックチェーン内のブロックの少なくとも１つのトランザクションの実行を証明する実行トレースを含む、請求項１６に記載のコンピュータ可読記憶媒体。
前記証明の検証の数は、前記ノードの数において線形であり、二次関数的ではない、請求項１６に記載のコンピュータ可読記憶媒体。
前記証明を検証する工程は、ノードの数よりも１つ少ない検証を必要とする、請求項１６に記載のコンピュータ可読記憶媒体。