JP7285840B2 - プルーフ検証に基づいてオフ・チェーン・データを認証するシステム及び方法 - Google Patents

Description

本発明は概してブロックチェーン技術に関連し、特にビットコイン・スクリプトで検証することが可能なプルーフ・オブ・カンバセーションを生成すること、更にリコースの場合にも利用することが可能な情報も提供することに関連する。所定のコミュニケーションがカンバセーション中に起こったことの証明は、マークル・ツリーを利用する可能性がある。カンバセーション又はコミュニケーションのデータは、プログラム又はスクリプトを正しく実行するための入力として使用される可能性がある。本発明は、スマート・コントラクトの生成及び実行における利用に特に適しているが、これらに限定されない。

この文献において、用語「ブロックチェーン」は何種類もの電子的なコンピュータ・ベースの分散された台帳のうちの何れを指してもよい。これらはコンセンサス・ベースのブロックチェーン及びトランザクション・チェーン技術、許可型及び非許可型の台帳、共有台帳、及びそれらの変形を含む。ブロックチェーン技術の最も広く知られたアプリケーションはビットコイン台帳であるが、他のブロックチェーン実装も提案され開発されている。便宜上及び説明の目的のために、本願で説明される技術の有用なアプリケーションとしてビットコインが言及されるかもしれないが、ビットコインは、本開示で説明される技術が適用され得る多数のアプリケーションのうちのほんの１つに過ぎない。しかしながら、本発明はビットコイン・ブロックチェーンで使用することに限定されず、非商用アプリケーションを含む代替的なブロックチェーン実装及びプロトコルもまた、本発明の範囲に属することに留意すべきである。例えば、本開示の中で説明される技術は、ブロックチェーンにとって外部のデータを当てにする可能性があるブロックチェーン・ネットワークに公表されているプログラム又はスクリプトの実行に関して、ビットコインと同様な制限を有する他のブロックチェーン実装を利用することにも恩恵を提供するであろう。

ブロックチェーンは、ピア・ツー・ピアの電子台帳を指す可能性があり、ブロックで構成されるコンピュータ・ベースの非セントラル化された分散システムとして実装され、ブロックはトランザクション及び他の情報で構成される可能性がある。幾つかの例において、「ブロックチェーン・トランザクション」はデータ及び条件一式を含むフィールド値の構造化された集まりをエンコードする入力メッセージを示し、条件一式の充足は、フィールドのセットに関し、ブロックチェーン・データ構造に書き込まれるために事前に必要なことである。例えば、ビットコインの場合、各々のトランザクションは、ブロックチェーン・システムの参加者間でのディジタル資産のコントロールの移転をエンコードするデータ構造であり、少なくとも１つの入力（インプット）と少なくとも１つの出力（アウトプット）とを含む。幾つかの実施形態において、「ディジタル資産」は、使用する権利に関連付けられるバイナリ・データを指す。ディジタル資産の具体例はビットコイン、イーサ（ｅｔｈｅｒ）、及びライトコインを含む。本願において使用される用語「ビットコイン」は、ビットコイン・プロトコルの変形である任意のプロトコルを含むように使用される。幾つかの実装において、ディジタル資産のコントロールを移転することは、ディジタル資産の少なくとも一部を第１エンティティから第２エンティティへ関連付け直すことにより実行されることが可能である。ブロックチェーンの各ブロックは先行するブロックのハッシュを含み、ブロックは先行するブロックと共にチェーン状になり、その発端以来ブロックチェーンに書き込まれてきた全てのトランザクションの永続的な変更できない記録を作る。

幾つかの例において、「スタック・ベース・スクリプト言語」は、様々なスタック・ベース又はスタック指向の実行モデル又はオペレーションをサポートするプログラミング言語を指す。即ち、スタック・ベース・スクリプト言語はスタックを利用することができる。スタックでは、値がスタックのトップにプッシュされるか、又はスタックのトップからポップされる（取り出される）ことが可能である。スタックを操作するために実行される様々なオペレーションは、スタックのトップへ又はトップから、１つ以上の値をプッシュ又はポップする結果となる可能性がある。例えば、ＯＰ＿ＥＱＵＡＬオペレーションは、スタックから上位２つのアイテムを取り出し、それらを比較し、結果（例えば、等しければ１、あるいは等しくなければ０）をスタックのトップにプッシュする。ＯＰ＿ＰＩＣＫのようなスタックに対して実行される他のオペレーションは、スタックのトップ以外の場所からアイテムが選択されることを許容することが可能である。幾つかの本願実施形態で使用される幾つかのスクリプト言語では、メイン・スタック及びオルタネート・スタックという少なくとも２つのスタックが存在する可能性がある。スクリプト言語の幾つかのオペレーションは、あるスタックのトップから別のスタックのトップへアイテムを移動させることが可能である。例えば、ＯＰ＿ＴＯＡＬＴＳＴＡＣＫは、メイン・スタックのトップからオルタネート・スタックのトップへ値を移動させる。スタック・ベースのスクリプト言語は、場合によっては、厳密に後入れ先出し（ＬＩＦＯ）方式でオペレーションのみに限定されない可能性があることに留意すべきである。例えば、スタック・ベースのスクリプト言語は、スタック内のｎ番目のアイテムをトップにコピー又は移動するオペレーションをサポートしている可能性がある（例えばビットコインではそれぞれＯＰ＿ＰＩＣＫ及びＯＰ＿ＲＯＬＬである）。スタック・ベースのスクリプト言語で書かれるスクリプトは、ベクトル、リスト、又はスタック等の適切な任意のデータ構造を利用して実装されることが可能な論理スタックにプッシュされる可能性がある。

ブロックチェーンに書き込まれるトランザクションのために、「有効性が検証」されなければならない。ネットワーク・ノード（マイニング・ノード）は、各々のトランザクションが有効であることを保証するための作業を実行し、有効でないトランザクションはネットワークから拒否される。ノードは、他のノードと異なる有効性に関する基準を有することが可能である。ブロックチェーンにおける有効性はコンセンサス・ベースであるので、トランザクションは、そのトランザクションが有効であることに過半数のノードが合意する場合に有効であるとみなされる。ノードにインストールされているソフトウェア・クライアントは、部分的に未使用トランザクション・アウトプット（ＵＴＸＯ）を参照するトランザクションに関するこの検証作業を、ＵＴＸＯロッキング及びアンロッキング・スクリプトを実行することによって実行する。ロッキング及びアンロッキング・スクリプトの実行がＴＲＵＥと評価する場合、及び適用可能であるならば他の検証条件が充足される場合に、トランザクションはノードによって有効性が検証される。検証されたトランザクションは他のネットワーク・ノードへ伝搬され、マイニング・ノードはブロックチェーンにトランザクションを含めることを選択することができる。従って、トランザクションがブロックチェーンに書き込まれるためには、ｉ）トランザクションを受信する第１ノードにより検証され－－－トランザクションが有効であると検証されると、ノードはそれをネットワーク内の他のノードへ中継し；ｉｉ）マイニング・ノードにより構築される新たなブロックに追加され；ｉｉｉ）マイニングされる、即ち過去のトランザクションの公の台帳に追加されなければならない。トランザクションを事実上撤回できなくする程度に十分な数のブロックがブロックチェーンに追加された場合に、トランザクションは承認されたものとみなされる。

ブロックチェーン技術は、暗号通貨実装の用途に最も広く知られているが、ディジタル起業家は、新しいシステムを実装するために、ビットコインが基礎としている暗号セキュリティ・システムと、ブロックチェーンに格納されることが可能なデータとの両方の活用を検討し始めている。ブロックチェーンが、暗号通貨の領域に限定されない自動化されたタスク及びプロセスに使用されることが可能であるならば、非常に有利であろう。このようなソリューションは、ブロックチェーンの利点（例えば、イベントの永続的な改ざん防止記録、分散処理など）を利用する一方、それらのアプリケーションでの多様性を豊富にすることができるであろう。

本開示は、１つ以上のブロックチェーン・ベースのコンピュータ・プログラムの技術的側面を開示する。ブロックチェーン・ベースのコンピュータ・プログラムは、ブロックチェーン・トランザクションに記録された機械読み取り可能で実行可能なプログラムであってもよい。ブロックチェーン・ベースのコンピュータ・プログラムは、結果を生成するために入力を処理することが可能であり、次いで、それらの結果に依存してアクションが実行されることを引き起こすことが可能なルールを含む可能性がある。現在の研究の１つの分野は、「スマート・コントラクト」の実現のためのブロックチェーン・ベースのコンピュータ・プログラムの使用である。自然言語で書かれる伝統的な契約とは異なり、スマート・コントラクトは、機械読み取り可能な契約又は合意の条項の実行を自動化するように設計されたコンピュータ・プログラムである可能性がある。

ブロックチェーン関連のもう別の関心領域は、ブロックチェーンにより現実世界のエンティティを表現して移転するための「トークン」（又は「カラード・コイン」）の使用である。潜在的に機密又は秘密のアイテムは、認識可能な意味又は値を有しないトークンによって表すことができる。従って、トークンは、現実世界のアイテムがブロックチェーンから参照されることを可能にする識別子として機能する。

実施形態において、特定のエンティティとのやり取りは、スマート・コントラクトの特定のステップでエンコードされることが可能であるが、スマート・コントラクトは別の方法で自動的に実行され、自己強制されることが可能である。これは機械読み取り可能で実行可能である。幾つかの例では、自動実行は、ＵＴＸＯの移転を可能にするために成功裏に実行されるスマート・コントラクトの実行を指す。なお、このような例では、ＵＴＸＯの移転を引き起こすことが可能な「エンティティ」は、何らかの秘密情報を証明するように要求されることなく、アンロッキング・スクリプトを作成することが可能なエンティティを指すことに留意されたい。言い換えれば、アンロッキング・トランザクションは、データのソース（例えば、アンロッキング・トランザクションを作成したエンティティ）が暗号シークレット（例えば、プライベート非対称鍵、対称鍵など）に対するアクセスを有することを検証することなく、有効性を検証することが可能である。また、このような例では、自己強制（ｓｅｌｆ－ｅｎｆｏｒｃｅｍｅｎｔ）は、ブロックチェーン・ネットワークの検証ノードが、制約に従ってアンロッキング・トランザクションを実施させられることを指す。幾つかの例では、ＵＴＸＯを「アンロッキング」することは、ＵＴＸＯを参照し、有効として実行するアンロッキング・トランザクションを作成することを指す。

ブロックチェーン・トランザクション出力は、ロッキング・スクリプトと、ビットコインのようなディジタル資産の所有権に関する情報とを含む。エンカンブランス（ａｎ ｅｎｃｕｍｂｒａｎｃｅ）として言及される可能性もあるロッキング・スクリプトは、ＵＴＸＯを移転するために満足するように求められる条件を指定することによって、ディジタル資産を「ロック」する。例えば、ロッキング・スクリプトは、関連するディジタル資産をアンロックするために所定のデータがアンロッキング・スクリプトで提供されることを要求することが可能である。ロッキング・スクリプトはビットコインでは「ｓｃｒｉｐｔＰｕｂＫｅｙ」としても知られている。ディジタル資産をアンロックするためにデータを提供することを当事者に要求する技術は、ロッキング・スクリプト内にデータのハッシュを埋め込むことを含む。

本発明はゼロ・ナレッジ・プルーフ（ｚｅｒｏ－ｋｎｏｗｌｅｄｇｅ ｐｒｏｏｆｓ）を利用することが可能なブロックチェーンでスマート・コントラクトを実行するためのシステム及び方法として説明されることが可能である。スマート・コントラクトの実行は、トランザクション検証の一部として行われることが可能である。スマート・コントラクトの実行の一部として、現実世界の状態及びイベントに関するデータのような、ブロックチェーン外部のデータ（例えば、オフ・チェーン・データ）へのアクセスを得ることが望ましいかもしれない。本願で説明される技術は、データ・ソースによって提供されるデータが認証され、ブロックチェーン・ネットワークに公開されるスマート・コントラクトのようなプログラム又はスクリプトの実行に利用される場合に利用される可能性がある。ディジタル資産は、幾つかの実施形態において、暗号通貨として使用される可能性があるが、実施形態において、ディジタル資産は、他の状況で追加的又は代替的に使用可能であることが想定されている。本発明は、ディジタル資産のコントロールに適用可能であるが、その性質上、技術的なものであり、ディジタル資産の移転に必ずしも関わらないブロックチェーン・データ構造を利用する他の状況で使用されることが可能であることに留意されたい。

従って、これらの側面の１つ以上においてブロックチェーン技術を改善する方法及びシステムを提供することが望ましい。そのような改善されたソリューションは今では考案されている。即ち、本発明によれば、添付の特許請求の範囲に規定される方法が提供される。

そのような改善されたソリューションは今では考案されている。

即ち、本発明によれば、添付の特許請求の範囲に規定されるシステム及び方法が提供される。

本発明によれば、ブロックチェーンのノードのためにコンピュータで実行される方法を提供することが可能であり、コンピュータで実行される方法は：
コンピューティング・エンティティとの暗号で保護された通信セッションを確立するステップ；
ブロックチェーン・ネットワークに公開されているプログラムの実行をコントロールする入力データを含むコミュニケーションを、暗号で保護された通信セッションで受信するステップ；
データを含む一群のコミュニケーションが暗号で保護された通信セッションで生じたことの第１証明を受信するステップ；
受信した入力データに少なくとも部分的に基づいて、プログラムの適正実行の
プルーフと、データがデータ・ソースから受信されたことの第２証明とを生成するステップ；
プログラムの適正実行のプルーフを他のコンピュータ・システムに提供するステップを含む。

追加的又は代替的に本発明は以下のステップを含むように説明されることが可能であり、そのステップは：
コンピューティング・エンティティとの暗号で保護された通信セッションを確立するステップ；
ブロックチェーン・ネットワークに公開されているプログラムの実行をコントロールする入力データを含むコミュニケーションを、暗号で保護された通信セッションで受信するステップ；
データを含む一群のコミュニケーションが暗号で保護された通信セッションで生じたことの第１証明を受信するステップ；
受信した入力データに少なくとも部分的に基づいて、プログラムの適正実行のプルーフと、データがデータ・ソースから受信されたことの第２証明とを生成するステップ；及び
プログラムの適正実行のプルーフを他のコンピュータ・システムに提供するステップである。

第１証明は、マークル・ツリーのルート・ノードに少なくとも部分的に基づく値を有する可能性があり、マークル・ツリーは、一群のコミュニケーション及び一群のソルト値から決定される一群のリーフ・ノードを含む。

一群のコミュニケーションのうちのコミュニケーションは、コミュニケーションが受信されたか又は送信されたかに基づいて決定される対応する中間ノードを含む可能性がある。場合によっては、一群のコミュニケーションのうちの各コミュニケーションが、そのような対応する中間ノードを含む。

第１証明の値は、少なくともマークル・ツリーのルート・ノードから生成される暗号ハッシュ出力と、一群のコミュニケーションの時間間隔とに少なくとも部分的に基づく。暗号ハッシュ出力の生成に適した暗号ハッシュ・アルゴリズムの具体例は、ＳＨＡ－２５６暗号ハッシュ・アルゴリズムである。

第２証明は、マークル・ツリーのマークル・パス、マークル・ツリーのノードの集合の値を含むマークル・パス、マークル・ツリーのルート・ノードの値を計算するのに十分なノードの集合の値に少なくとも部分的に基づいていてもよい。

好ましくは、マークル・パスのノードの集合は、マークル・ツリーのリーフではなくルートでもない深度各々において、せいぜい１つのノードを含む。場合によっては、マークル・パスは、マークル・ツリーのリーフではなくルートでもない深度各々において、厳密に１つのノードを含む。

プログラムは、２人以上の当事者によって合意される一組のルールを含む可能性があり、本方法は、２人当事者のうちの少なくとも１人によって信頼される１つ以上のコンピューティング・エンティティとの暗号で保護された通信を確立するために、コンピューティング・エンティティを選択するステップを含む可能性がある。

好ましくは、本方法は、
第１トランザクション・アウトプットと第２トランザクション・アウトプットとを含むブロックチェーン・トランザクションを検出するステップであって、第１トランザクション・アウトプットは第１ロッキング・スクリプトを含み、第１トランザクション・アウトプットに関連する第１ディジタル資産は、アンロッキング・スクリプトによりロック解除され、アンロッキング・スクリプトは：
コンピューティング・エンティティに関連するパブリック鍵と、
期待される値をエンコードするディジタル署名であって、ディジタル署名の真正はパブリック鍵を使用して暗号検証可能であり、期待される値を生成するために認証情報が使用可能である、ディジタル署名とをエンコードしており、
第２トランザクション・アウトプットは適正実行のプルーフの指示をエンコードしている、ステップ；及び、
少なくともパブリック鍵、ディジタル署名、及び認証情報を提供することによって、第１ディジタル資産のロックを解除するステップを含む可能性がある。

ブロックチェーン・トランザクションは、更に、
他のコンピュータ・システムに関連付けられたプライベート鍵を使用してディジタル署名されたトランザクション・インプット；
第２アンロッキング・スクリプトを含む第３トランザクション・アウトプットであって、第３トランザクション・アウトプットに関連付けられる第２ディジタル資産は、プライベート鍵を使用してロック解除可能である、第３トランザクション・アウトプット；
を含む可能性があり、第２トランザクション・アウトプットは、他のコンピュータ・システムに関連付けられた識別子を更にエンコードしている。

好ましくは、認証情報は、マークル・ツリーのマークル・パスを含み、期待される値は、マークル・ツリーのルート・ノードに少なくとも部分的に基づいている。

データは、イベントが発生したか否かを示すバイナリ・データを含んでもよい。

データは、ブロックチェーン上の他のデータに基づいて真正が検証可能でない情報を含むデータであってもよい。

好ましくは、第１証明はディジタル署名であり、ディジタル署名の真正は、コンピューティング・エンティティに関連する暗号パブリック鍵を使用して検証可能である。

また、プロセッサと、実行可能な命令を含むメモリとを備えるシステムを提供することも望ましく、命令は、プロセッサによる実行の結果として、保護が請求される何れかの方法をシステムに実行させる。

また、実行可能な命令を格納した非一時的なコンピュータ読み取り可能な記憶媒体を提供することも望ましく、命令は、コンピュータ・システムの１つ以上のプロセッサによる実行の結果として、保護が請求される何れかの方法をコンピュータ・システムに少なくとも実行させる。

追加的又は代替的に、本発明は改良されたブロックチェーン・プログラミング・ツール又は支援手段を提供することが可能である。これは、分散された検証可能な計算を促進又は可能にする、改善された効率的で最適化された構成を提供する可能性がある。

本発明のこれら及び他の態様は、本願で説明される実施形態から明らかであり、それを参照して解明されるであろう。ここで本発明の実施形態は単なる例示として添付図面を参照して説明される。

様々な実施形態が実装されることが可能なブロックチェーン環境を示す。

様々な実施形態に従ってプロトコルを実装するために利用されてもよいコンピューティング環境を示す。

検証可能な計算の実行に適した環境の図を示す。

プログラム又はスクリプトの実行に関連してデータ・ソースから取得されるデータを証明者が利用する環境の例示的な図を示す。

プログラム又はスクリプトの実行に利用されるデータ・ソースからデータを取得するためのプロトコルを示す図である。

実施形態によるマークル・ツリーの図を示す。

実施形態によるマークル・パスの図を示す。

種々の実施形態に関連して利用されるプルーフを生成及び検証するプロトコルの図を示す。

実施形態による評判トランザクションの図を示す。

通信のプルーフを生成するプロセスの説明図である。

認証されたデータを利用してプログラム又はスクリプトを実行するプロセスの説明図である。

本開示の少なくとも１つの実施形態を実施するために使用されることが可能なコンピューティング・デバイスを示す。

先ず、本開示の実施形態によるブロックチェーンに関連する例示的なブロックチェーン・ネットワーク１００を示す図１を参照する。実施形態では、例示的なブロックチェーン・ネットワーク１００は、ピア・ツー・ピア分散電子デバイスとして実装されるブロックチェーン・ノードを含み、各ノードは、ノード１０２のオペレータ間で少なくとも部分的に合意されたブロックチェーン・プロトコルに従うオペレーションを実行するソフトウェア及び／又はハードウェアのインスタンスを実行する。幾つかの例において、「ノード」は、ブロックチェーン・ネットワーク間で分散されたピア・ツー・ピア電子デバイスを指す。ブロックチェーン・プロトコルの一例はビットコイン・プロトコルである。

幾つかの実施形態では、ノード１０２は、任意の適切なコンピューティング・デバイスにより構成されることが可能である（例えば、データ・センターにおけるサーバー、クライアント・コンピューティング・デバイス（例えば、デスクトップ・コンピュータ、ラップトップ・コンピュータ、タブレット・コンピュータ、スマートフォンなど）、コンピューティング・リソース・サービス・プロバイダの分散システムにおける複数のコンピューティング・デバイス、又は図８のコンピューティング・デバイス８００のような任意の適切な電子クライアント・デバイスにより構成されることが可能である）。幾つかの実施形態では、ノード１０２は、トランザクション１０４のような提案されたトランザクションを表すデータメッセージ又はオブジェクトを受信するための入力を有する。幾つかの実施形態では、ノードは、ノードが保持する情報（例えば、トランザクション１０４の状態の情報）に対してクエリ可能（ｑｕｅｒｙａｂｌｅ）である。

図１に示すように、幾つかのノード１０２は、１つ以上の他のノード１０２に通信的に結合される。このような通信接続は、１つ以上の有線又は無線通信を含むことが可能である。実施形態では、ノード１０２はそれぞれ、ブロックチェーン内の全てのトランザクションの「台帳（ｌｅｄｇｅｒ）」の少なくとも一部を維持する。このようにして、台帳は分散された台帳となる。台帳に影響を与えるノードによって処理されるトランザクションは、台帳の完全性が維持されるように、１つ以上の他のノードによって検証可能である。

どのノード１０２が他のどのノードと通信することができるかに関しては、メッセージは転送されるべきであるとブロックチェーン・プロトコルが示すものであると仮定して、例示的なブロックチェーン・ネットワーク１００の各ノードが、１つ以上の他のノード１０２と通信できることで十分であるとすることが可能であり、その結果、ノード間で受け渡されるメッセージは例示的なブロックチェーン・ネットワーク１００全体（又はそのうちのかなりの部分）に伝達される。そのようなメッセージの１つは、ノード１０２Ａのような１つのノード１０２による提案されたトランザクションの公表であってもよく、これはパス１０６のようなパスに沿って伝搬する。そのような他のメッセージは、ブロックチェーンに含めるために提案された新しいブロックの公表であってもよい。

実施形態では、ノード１０２のうちの少なくとも一部は、暗号問題を解くことのような複雑な計算を実行するマイナー・ノードである。暗号問題を解くマイナー・ノードは、ブロックチェーンのための新しいブロックを作成し、その新しいブロックを他のノード１０２にブロードキャストする。他のノード１０２は、マイナー・ノードの作業を検証し、検証に基づいて、そのブロックを（例えば、ブロックチェーンの分散台帳に追加することによって）ブロックチェーンに受け入れる。幾つかの例では、ブロックはトランザクションのグループであり、前のブロックの「フィンガープリント」（例えばハッシュ）とタイムスタンプとでマークされることが多い。このようにして、各ブロックは前のブロックにリンクされることが可能であり、それによりブロックチェーンのブロックをリンクする「チェーン」が生成される。実施形態において、有効なブロックは、ノード１０２のコンセンサスによってブロックチェーンに追加される。また、幾つかの例では、ブロックチェーンは、検証されたブロックのリストを含む。

一実施形態では、ノード１０２のうちの少なくとも一部は、本開示で説明されるように、トランザクションを検証する検証ノードとして動作する。幾つかの例では、トランザクションは、ディジタル資産（例えば、幾らかのビットコイン）の所有権の証拠（プルーフ）と、ディジタル資産の所有権／支配権（オーナーシップ／コントロール）を受け入れる又は移転するための条件とを提供するデータを含む。幾つかの例において、「アンロッキング・トランザクション」とは、先行するＵＴＸＯにより指定されるディジタル資産の少なくとも一部を、ブロックチェーン・アドレスに関連付けられたエンティティに関連付け直す（例えば、所有権又は支配権を移転する）ブロックチェーン・トランザクションを指す。幾つかの例において、「先行するトランザクション」とは、アンロッキング・トランザクションによって参照されるＵＴＸＯを含むブロックチェーン・トランザクションを指す。幾つかの実施形態では、トランザクションは、所有権又は支配権が移転される（ロック解除される）前に満たされなければならない条件でトランザクションを制限する「ロックキング・スクリプト」を含む。

幾つかの実施形態では、ブロックチェーン・アドレスは、少なくとも一部のディジタル資産の支配権が移転／再関連付けされつつあるエンティティに関連する英数字の文字列である。幾つかの実施形態で実装される幾つかのブロックチェーン・プロトコルでは、エンティティに関連するパブリック鍵とブロックチェーン・アドレスとの間に１対１の対応がある。幾つかの実施形態では、トランザクションの検証は、ロッキング・スクリプト及び／又はアンロッキング・スクリプトで指定された１つ以上の条件を検証することを含む。トランザクション１０４の検証に成功すると、検証ノードはトランザクション１０４をブロックチェーンに追加し、それをノード１０２に拡散する。

本願で説明されるシステム及び方法は、ロッキング・スクリプトが検証キーＶ_Ｋを変更から保護し、プルーフπの有効性を確認することを可能にし、それにより、トランザクション検証中にブロックチェーンでゼロ・ナレッジ・プロトコルの実行を可能にすることに関する。

検証可能な計算は、計算のプルーフの生成を可能にする技術である。実施形態では、このような技術は、入力ｘに関する関数ｆの評価を、本願においてプルーバー（ａ ｐｒｏｖｅｒ）と言及される別のコンピューティング・エンティティにアウトソースするために、クライアントによって利用される。場合によっては、クライアントは演算負担に限りがあり、その結果、クライアントは関数の評価を実行することが不可能であり（例えば、クライアントにとって利用可能な計算リソースを使用する計算の予想されるランタイムが最大許容閾値を超えてしまう場合があり）（但し、必ずしもそうであるとは限らない）、クライアントは、一般に、計算ランタイム、計算コスト（例えば、関数の評価を実行するために計算リソースを割り当てるための財務コスト）などの任意の適切な基準に基づいて、入力ｘに関する関数の評価を委任する可能性がある。

プルーバーは、実施形態においては、本開示の他の箇所でより詳細に説明されているように、ブロックチェーン・ノードのような任意の適切なコンピューティング・エンティティである。実施形態では、プルーバ（例えば、ブロックチェーン・ノード）は、入力ｘに関して関数ｆを評価し、出力ｙ及び出力ｙの正確性のプルーフπを生成し、これらは上述のクライアント及び／又はブロックチェーン・ネットワークの他のノードのような他のコンピューティング・エンティティによって検証されることが可能である。引数とも言及されるプルーフは、実際の計算を実行するよりも速く検証されることが可能であり、即ち、上述のプルーバーによって生成される出力の正確さを判断するために、入力ｘに対して関数ｆを再計算する代わりに、プルーフの正確さを検証することによって、計算のオーバーヘッドは削減されることが可能である（例えば、電力オーバーヘッド、電力に関連するコスト、及び実行中の計算リソースを低減することができる）。ゼロ・ナレッジ検証可能な計算において、プルーバーは、そのプルーバーが特定の性質を有する入力を知っていることの証明（ａｎ ａｔｔｅｓｔａｔｉｏｎ）を、クライアントに提供する。

ナレッジについてのゼロ・ナレッジ・プルーフの能率的な変形は、ｚｋ＿ＳＮＡＲＫ（Ｓｕｃｃｃｉｎｃｔ Ｎｏｎ－ｉｎｔｅｒａｃｔｉｖｅ ＡＲｇｕｍｅｎｔ ｏｆ Ｋｎｏｗｌｅｄｇｅ）である。実施形態では、全てのペアリング・ベースのｚｋ－ＳＮＡＲＫはあるプロセスを含み、そのプロセスにおいて、プルーバーは一般的なグループ・オペレーションを使用して多数のグループ要素を計算し、検証器又はベリファイア（ｔｈｅ ｖｅｒｉｆｉｅｒ）が多数のペアリング・プロダクト方程式を使用してプルーフを確認する。実施形態では、線形インタラクティブ・プルーフは有限体で動作し、プルーバー及び検証器のメッセージは、フィールド要素のベクトルを決定するために使用可能な情報を含む、エンコードする、参照するか、又は他の方法で含む。

実施形態では、本願で説明されるシステム及び方法は、ブロックチェーンのマイニング・ノードが、計算（例えば、入力ｘに関する関数ｆの評価）を１度実行し、出力の正確さを検証するために使用されることが可能なプルーフを生成することを可能にし、ここで、プルーフの正確さを評価することは、関数を評価することよりも演算負担に関して低コストである。この文脈では、オペレーション及びタスクのコスト（即ち、どれだけ高いコストであるか）は、オペレーション又はタスクを実行する計算の複雑さを指すことが可能である。実施形態では、計算の複雑さは、分類アルゴリズムを実行することについての平均計算コスト又は最悪ケースの計算コストを指し、例えば、ヒープソート・アルゴリズム及びクイックソート・アルゴリズムは両方ともＯ（ｎ ｌｏｇｎ）という平均計算コストを有するが、クイックソートはＯ（ｎ^２）という最悪ケースの計算コストを有する一方、ヒープソートは（ｎ ｌｏｇｎ）という最悪ケースの計算コストを有する。実施形態では、入力ｘに関する関数ｆを評価することについての平均計算コスト及び／又は最悪ケース計算コストは、プルーフの正確性を評価することについてのコストよりも劣る。従って、本願で説明されるシステム及び方法の使用は非常に有利であり、例えば、より演算負担の重い高コストな契約が実行される可能性があり、なぜならそのような契約は、ブロックチェーンを検証するために必要とされる時間を、それに比例しては増加させないからである。更なる利点は、検証器システムの電力消費の低減を含む可能性があり、それによって検証器コンピュータ・システムの効率を改善し、プルーフの正確性を評価する際に、そのような検証器コンピュータ・システムを動作させることに関連するエネルギー・コストを低減する。

実施形態では、検証キーＶ_Ｋ又はその一部は、ゼロ・ナレッジ・プロトコルのセットアップ段階で生成され、プルーフπと共に使用される公開パラメータ、及び入力／出力データから抽出され、プルーバーによって提供される適正計算の主張される正しさのプルーフを検証する。例えば、上記及び下記における詳細な説明で述べられるように、システム及び方法は、検証鍵Ｖ_Ｋを変更から保護し、プルーフπの有効性を確認するロッキング・スクリプトを可能にし、トランザクション検証中にブロックチェーンでゼロ・ナレッジ・プロトコルの実行を可能にする。従って、本開示は、計算の検証に使用される要素を記憶するためのブロックチェーン・スクリプト（例えば、ビットコイン・ベースのネットワーク）を使用して検証フェーズを実行するシステム及び方法を提供する。

図２は、様々な実施形態によるプロトコルを実装するために利用されることが可能なコンピューティング環境２００を示す。このプロトコルは、プルーフ・オブ・コレクトネス（ｐｒｏｏｆ－ｏｆ－ｃｏｒｒｅｃｔｎｅｓｓ）を記憶し、「コレクト・バイ・コンストラクション」暗号手法とスマート・コントラクトとを組み合わせるために、ブロックチェーン技術を用いて実装される可能性がある。実施形態では、公的な検証可能な計算スキームは、セットアップ・フェーズ、計算フェーズ、及び検証フェーズの３つのフェーズを含む。

セットアップ・フェーズは、計算タスクの実行をアウトソースするために、プロセスの一部として実行されてもよい。後述するように、クライアントは、異なるコンピュータ・システムであってもよい、計算タスクの実行をプルーバーに委任するカスタマー又はクライアント・コンピュータ・システムなどのエンティティを指す可能性がある。一般的に、クライアントは、限定されるわけではないが、計算リソース、計算リソースの不足、タスクを実行するためにクライアント・コンピュータシステムを利用することに関連する経済的コスト、タスクを実行するためにクライアント・コンピュータ・システムを利用することに関連するエネルギー・コストなどを含む様々な理由により、計算タスクの実行を委任する可能性がある（例えば、電力のためにバッテリを当てにするモバイル・デバイス又はラップトップは、計算負担の高いタスクを実行するためにプルーバーを利用し、それによって、電力を節約し、バッテリ駆動デバイスの使用時間を延長することができる）。

一実施形態では、セットアップ・フェーズは、クライアント、顧客、組織の従業員、又は他の任意の適切なエンティティが、正しい意味で正式な言語でコントラクトを書くことを含む。コントラクトは、Ｃ又はＪａｖａのような高級プログラミング言語で書かれてもよい。一般に、コントラクトは、コンピュータ・システムによって処理されることが可能なフォーマットである、又はそれに変換されることが可能な任意の言語又は構文で表現される可能性がある。実施形態では、限定された目的で、ドメイン固有の言語が型安全性（タイプ・セーフティ）を提供することが可能であり、制限された表現が利用されることが可能である。生成されるソース・コードは、コントラクトの正確な記述である可能性がある。

コンパイラ２０２は、コンピュータ・システムの１つ以上のプロセッサによって実行されると、ソースコード２０６を入力として受け取り、回路を生成させることをシステムに行わせる実行可能コードを含む、任意のハードウェア、ソフトウェア、又はそれらの組み合わせとすることが可能である。コンパイラ２０２は、バイナリ・コードのような機械読み取り可能なフォーマットにコンパイルされている命令に基づいて、命令を実行又は遂行するコンピュータ・プログラムを指す可能性がある。コンパイラ２０２が示されているが、インタプリタ、アセンブラ、及び他の適切なソフトウェア及び／又はハードウェア・コンポーネントが、ソースコードを回路に変換するために利用されてもよいことに留意されたい。実施形態では、回路は、フィールドＦからの値を運び、論理ゲート及び／又は演算ゲートに繋ぐワイヤを備える演算回路である。実施形態では、この回路Ｃは、元の回路Ｃの完全な記述を提供する一組の多項式を含む二次プログラムＱ２０８を生成するためにシステムによって使用される。

一実施形態では、コンパイラ２０２は、プレプロセッサ・ディレクティブ、スタティック・イニシャライザ、グローバル及びローカル関数、ブロック・スコープ変数、配列、データ構造、ポインタ、関数呼び出し、関数オペレータ（例えば、ファンクタ（ｆｕｎｃｔｏｒｓ））、条件及びループ、演算及びビットワイズ論理演算子などを含むがこれらに限定されないＣ又はＪａｖａのようなプログラミング言語の本質的な部分を認識することが可能なものである。実施形態では、コンパイラ２０２は、プログラミング言語の規格に従うコマンドのセット全体をサポートしていない（これは、ある場合には、再帰的アルゴリズムを禁止する等の、ある種のアルゴリズムがスマート・コントラクトで実行されることを防止するように意図される可能性がある）。実施形態では、コンパイラは、ソース・コードの表現を演算ゲート言語に拡張し、演算回路を生成する。回路の実装は以下の文献により過去に考察されている：Ｃａｍｐａｎｅｌｌｉ， Ｍ．， ｅｔ ａｌ． （２０１７） ｉｎ “Ｚｅｒｏ－Ｋｎｏｗｌｅｄｇｅ Ｃｏｎｔｉｎｇｅｎｔ Ｐａｙｍｅｎｔｓ Ｒｅｖｉｓｉｔｅｄ： Ａｔｔａｃｋｓ ａｎｄ Ｐａｙｍｅｎｔｓ ｆｏｒ Ｓｅｒｖｉｃｅｓ” ａｎｄ ｂｙ Ｔｉｌｌｉｃｈ， Ｓ． ａｎｄ Ｓｍａｒｔ， Ｂ ｉｎ “Ｃｉｒｃｕｉｔｓ ｏｆ Ｂａｓｉｃ Ｆｕｎｃｔｉｏｎｓ Ｓｕｉｔａｂｌｅ Ｆｏｒ ＭＰＣ ａｎｄ ＦＨＥ．”演算回路は、コンパイラ２０２又は他の任意の適切なハードウェア、ソフトウェア、又はそれらの組み合わせ（例えば、図２に示されていないソフトウェア・モジュール）によって、二次演算問題（ＱＡＰ）を構築するために利用される可能性がある。二次プログラムは、実施形態に従って、クライアント（例えば、鍵生成及び検証）及びプルーバー（例えば、計算及びプルーフ生成）のための一組の暗号ルーチンにコンパイルされる。

実施形態では、鍵生成器２０４は、コンピュータ・システムの１つ以上のプロセッサによって実行されると、２次プログラムから評価鍵及び検証鍵をシステムに生成させる実行可能コードを含むハードウェア、ソフトウェア、又はそれらの組み合わせである。二次プログラムとしての計算をエンコードするための技術は次の文献で考察されている：“Ｑｕａｄｒａｔｉｃ Ｓｐａｎ Ｐｒｏｇｒａｍｓ ａｎｄ Ｓｕｃｃｉｎｃｔ ＮＩＺＫｓ ｗｉｔｈｏｕｔ ＰＣＰｓ” ｂｙ Ｇｅｎｎａｒｏ， Ｒ．， ｅｔ ａｌ．（２０１３）．実施形態では、二次割当問題（ＱＡＰ）Ｑは、フィールドＦに関して回路Ｃをエンコードし、ｍ＋１個の多項式一式を含む：
Ｖ＝｛ｖ_ｋ（ｘ）｝，Ｗ＝｛ｗ_ｋ（ｘ）｝，Ｙ＝｛ｙ_ｋ（ｘ）｝
ここで、０≦ｋ≦ｍである。ターゲット多項式ｔ（ｘ）も定義される。Ｆのｎ個の要素を入力として取り、ｎ’個の要素を出力とする関数ｆが与えられた場合において（Ｎ＝ｎ＋ｎ’）、｛ｃ_１，．．．，ｃ_Ｎ｝∈Ｆ^Ｎがｆの入力及び出力のグループの有効な指定であり、ｔ（ｘ）でｐ（ｘ）を割るように係数のリスト｛ｃ_Ｎ＋１，．．．，ｃ_ｍ｝が存在する場合に、Ｑはｆを計算する：

従って、実施形態では、ｈ（ｘ）・ｔ（ｘ）＝ｐ（ｘ）であるような何らかの多項式ｈ（ｘ）が存在しなければならない。Ｑのサイズはｍであり、その度合いはｔ（ｘ）の度合いである。

実施形態では、演算回路のＱＡＰを構築することは、回路内の各乗算ゲートｇに対して任意のルートｒ_ｇ∈Ｆをピックアップし、ｔ（ｘ）＝Π_ｇ（ｘ－ｒ_ｇ）であるようにターゲット多項式を定義することを含む。実施形態では、インデックスｋ∈｛１．．．ｍ｝は、回路の各入力、乗算ゲートからの各出力に関連付けられている。Ｖの多項式は各ゲートへの左入力をエンコードし、Ｗは各ゲートへの右入力をエンコードし、Ｙは出力をエンコードする。例えば、ｋ番目のワイヤがゲートｇに対する左入力である場合にはｖ_ｋ（ｒ_ｇ）＝１であり、それ以外はｖ_ｋ（ｒ_ｇ）＝０である。従って、特定のゲートｇ及びそのルートｒ_ｇに関し、先行する方程式は次のように簡略化されることが可能である：

ゲートの出力値はその入力の積に等しい。分割可能性検査はｄｅｇ（ｔ（ｘ））個の個々の検査に分解され、ｔ（ｘ）のルートｒ_ｇ及び各ゲートにつき１つあり、ｐ（ｒ_ｇ）＝０である。加算ゲートと定数乗算ゲートはＱＡＰのサイズや程度に寄与しない。

実施形態では、ＱＡＰは、フィールドＦ_ｐ上で定義され、ここでｐは大きな素数である。実施形態では、Ｆｐ上のＱＡＰが、加算及び乗算モジュロｐにより表現されることが可能な任意の関数を効率的に計算することが望ましい。演算分割ゲートは、［０，２^ｋ－１］であるように知られている演算ワイヤａ∈Ｆｐを、ｋ個のバイナリ出力ワイヤに変換するように設計されることが可能である。従って、ブール関数は、演算ゲートを用いて表現されることが可能であるという事実に従う。例えば、ＮＡＮＤ（ａ，ｂ）＝１－ａｂ である。各々組み込まれるブール・ゲートは、ただ１つの乗算コストしかかからない。更に、ｓｐｌｉｔ（分割）のような新たなゲートが、スタンドアロンとして定義され、他のゲートとともに構成されることが可能である。［０，２^ｋ－１］内にあることが分かっている所与の入力ａ∈Ｆｐに関し、ｓｐｌｉｔゲートは、Σ^ｋ２^ｉ－１ａ_ｉ＝ａであるようなａのうちの２進桁ａ_１，．．．，ａ_ｋを保持するｋ個のワイヤを出力し、各々のａ_ｉは０又は１の何れかである。

最後に、全てのプルーバー及び検証器により使用されるべき公開パラメータは、セットアップ・フェーズの一部としてシステムにより生成される。評価鍵Ｅ_Ｋと検証鍵Ｖ_Ｋは、クライアントにより選択されたシークレット値を用いて導出されることに留意すべきである。鍵生成器２０４は、評価鍵Ｅ_Ｋ２１０及び検証鍵Ｖ_Ｋ２１２を生成するために、鍵生成アルゴリズムに関連して二次演算プログラム（ＱＡＰ）を利用することができる。

実施形態では、計算タスクを実行することは、プルーバーによる入力２１６に関する関数の計算（即ち、ｆ（ｘ）を評価するプロセス）を含む。実施形態において、プルーバーは、クライアントが計算タスクを委任する可能性がある任意の適切なコンピュータ・システムである。入力２１６は、実施形態では、プルーバーに関連付けられたプライベート鍵を使用して生成されたディジタル署名のような、プルーバーの識別子を証明する情報を含む。実施形態では、プルーバーは、成功の結果として、クライアントがディジタル資産を移転するコンピュータ・システムである。クライアントは、実施形態では、入力ｘ及び評価鍵Ｅ_Ｋをプルーバーに提供し、プルーバーは、評価モジュール２１４を使用して、出力ｙ（即ち、ｙ＝ｆ（ｘ）であり、入力はｘであり、関数はｆである）を計算し、評価鍵Ｅ_Ｋ２１０を使用して、プルーフ・オブ・コレクトネス２１８を生成する。評価モジュールは、実施形態では命令を含むハードウェア及び／又はソフトウェアであり、命令は、コンピュータ・システムの１つ以上のプロセッサによって実行される場合に、コンピュータ・システムに、ＱＡＰ２０８の内部回路ワイヤの値を評価させ、ＱＡＰの出力ｙを生成させる。

実施形態では、二次プログラムの各多項式ｖ_ｋ（ｘ）∈Ｆは、双線形グループ内の要素ｇ^{ｖｋ（ｓ）}にマッピングされ、ここでｓはクライアントにより選択されるシークレット値であり、ｇはグループの生成器であり、Ｆはｇの離散対数の体（フィールド）である。実施形態では、所与の入力に対して、プルーバーは、二次プログラムの係数ｃ_ｉに対応する内部回路ワイヤの出力及び値を得るために回路を評価する。従って、プルーバーは、ｇ^ｖ（ｓ）を得るためにｖ（ｓ）＝Σ_{ｋ∈｛ｍ｝}ｃ_ｋ・ｖ_ｋ（ｓ）を評価し；ｗ（ｓ）及びｙ（ｓ）を計算し；ｈ（ｘ）＝ｐ（ｘ）／ｔ（ｘ）＝Σ^ｄｈ_ｉ・ｘ^ｉを計算し；評価鍵におけるｈ_ｉ及びｇ^ｓ（ｉ）を利用してｇ^ｈ（ｓ）を計算することが可能である。実施形態では、プルーフ・オブ・コレクトネス２１８は、（ｇ^ｖ（ｓ），ｇ^ｗ（ｓ），ｇ^ｙ（ｓ），ｇ^ｈ（ｓ））を含み、検証器は、ｐ（ｓ）＝ｈ（ｓ）・ｔ（ｓ）を検査するために双線形写像を使用する。実施形態では、プルーフπは、後で使用するためにブロックチェーン２２２に格納されるか、又は、これらの各々と個別的に相互作用することをプルーバーに必要せずに、複数の当事者によって検証されることが可能である。実施形態では、プルーフ・オブ・コレクトネスの回路記憶の評価は、トランザクションのロッキング・スクリプトによって制限されるリソース（例えば、ディジタル資産）をロック解除するために実行されてもよい。

実施形態では、プルーフπはブロックチェーン・ネットワークにブロードキャストされ、検証器２２０はプルーフを検証するために使用される。実施形態では、検証器２２０は、ブロックチェーン上のノードのような任意の適切なコンピューティング・エンティティである。更に、場合によっては、評価鍵Ｅ_Ｋ及び検証鍵Ｖ_Ｋを生成するのと同じコンピューティング・エンティティが、プルーフを検証することにも更に留意すべきである。実施形態では、ブロックチェーンのノードは、検証鍵Ｅ_Ｋ及びプルーフπを使用してロッキング・トランザクションを検証することが可能であり、検証が成功した場合に、コントラクトを有効化する。プロトコルの１つの要件は、プルーバーが、妥当でないプルーフを、たとえ検証鍵Ｖ_Ｋを知っていたとしても、提供できないことである。従って、このプロトコルでは、共通リファレンス文字列（ＣＲＳ）は、クライアントにより、又は少なくとも評価鍵Ｅ_Ｋ及び検証鍵Ｖ_Ｋを発行する信頼できる第三者によって生成される。実施形態では、公開される検証鍵Ｖ_Ｋは、計算を検証するために、任意のコンピューティング・エンティティによって使用されることが可能である。

本願で説明される技術を用いて、クライアントは、ブロックチェーン・トランザクションの受信者の識別子などのトランザクション・データを部分的に分かりにくくすることが可能である。実施形態では、アンロッキング・スクリプトは、受信者のアドレス及び受信者のパブリック鍵を公開しない。しかしながら、場合によっては、トランザクションの値（例えば、移転されるディジタル資産の量）がブロックチェーン・ネットワークのノードにとって可視的である可能性がある。実施形態では、上記及び下記の暗号技術は、クライアントがロッキング・スクリプトを二次演算プログラムへ変換し、プルーバーが演算プログラムを解いてプルーフを生成するためために利用される。

一般に、クライアントは、相手方又はプルーバーに支払うために、Ｐ２ＰＫ及びＰ２ＰＫＨのような標準トランザクション（例えば、ビットコイン・ベースのブロックチェーン・ネットワークで定義されるような標準トランザクション）を使用することが可能である。例えば、実施形態では、クライアントは、Ｐ２ＰＫロッキング・スクリプトを演算回路に変換し、その回路から導出されたパズルを含むロッキング・トランザクションをブロードキャストする。相手方又はプルーバーは、回路を受信し、適切な入力（例えば、クライアントとプルーバーとの間で共有される秘密、又はプルーバーのシークレット鍵を利用して生成されるディジタル署名のような、プルーバーの身元を証明する情報）を提供し、回路を動作させてプルーフ・オブ・コレクトネスπを生成する。実施形態では、プルーフは、リソース（例えば、ディジタル資産）をロック解除するために使用され、更に、相手方又はプルーバーを識別する情報（例えば、相手方又はプルーバーに関連するパブリック鍵及び／又はディジタル署名）が、不明確ではないフォーマットでブロックチェーンに記録されない可能性がある。

実施形態において、検証鍵及び対応するプルーフは、上記及び／又は下記の技術に従って生成される。従って、検証器には所与の検証鍵Ｖ_Ｋ及びプルーフπが与えられる：

その結果、検証器は複数の楕円曲線乗算（例えば、各々の公開入力変数について１つ）及び５ペアのチェックを算出し、それらのうちの１つは追加的なペアリング乗算を含む。

所与の検証鍵Ｖ_Ｋ、プルーフπ、（ａ_１，ａ_２，．．．，ａ_Ｎ）の下で、ｔ（ｘ）でｐ（ｘ）を割り、従って（ｘ）＝ｆ（ｘ_Ｎ＋１，．．．，ｘ_ｍ）であることを検証するために、検証器は次のように処理を進める。先ず、３つのα項全てを検査する：

次に、検証器は項βを検査する：

最終的に、検証器は分割条件を検査する：

従って、上述のセクション及び本開示で説明される実施例による表記を考慮すると、検証は、実施形態による以下の要素のペアのチェックのセットを含む：

図３は、検証可能な計算のパフォーマンスを調整するための図３００を示す。クライアント３０２、プルーバー３０４、及び検証器３０６は、ブロックチェーン・ネットワークのノードであってもよい。クライアント３０２は実行可能コードを含むことが可能な任意の適切なコンピュータ・システムである可能性があり、実行可能コードは、コンピュータ・システムの１つ以上のプロセッサによって実行されると、コンピュータ・システムにスマート・コントラクト３０８を受信させる。実施形態において、スマート・コントラクト３０８は、Ｃ、Ｃ＋＋、又はＪａｖａのようなソース・コードとして高級プログラミング言語でエンコードされている。実施形態では、コンパイラ、インタプリタ、及び／又はアセンブラのようなソフトウェアを利用して、スマート・コントラクト３０８を演算回路３１０に変換することが可能であり、演算回路は、体Ｆからの値を運び、加算及び乗算ゲートに接続する「ワイヤ」から構成される。演算回路は、物理的なワイヤによって接続された一連の物理ゲート（例えば、７４００シリーズのゲート、フリップ・フロップ、バッファ、デコーダ、マルチプレクサなどのトランジスタ－トランジスタ論理（ＴＴＬ）集積回路を使用するもの）を含む物理回路によって実現されることが可能な論理回路を指す可能性があることに留意すべきである。スマート・コントラクト３０８の実行は、図３及び他の部分の文脈で説明されるが、スマート・コントラクトの利用は、演算回路に変換されることが可能なソース・コードの非限定的な一例に過ぎない。実施形態では、クライアント３０２は（例えば、単独で、又は他のエンティティと組み合わせて）、一群のオペレーションによって定められるタスクを実行するためのソース・コードを決定し、タスクの実行はプルーバー３０４に委任される。一般に、検証器３０６は、例えば、プルーバー３０４によって生成されたプルーフ・オブ・コレクトネスの妥当性を検証すること等によって、プルーバー３０４がタスクを正しく実行したことを判断することに関連するタスクを実行することが可能である。

実施形態では、クライアント３０２は、プルーバー３０４に演算回路３１０を提供し、データ・プロバイダ３１８は、プルーバーに回路への入力３１２を提供する。場合によっては、入力３１２は、現実世界の状態及びイベントに関するデータなどのデータであってもよい。回路３１０は、元の回路の完全な記述を提供する一群の多項式を含む二次プログラムＱを生成するために使用されてもよい。何れの場合も、プルーバー３０４は、入力３１２に関して回路Ｃ又は２次プログラムＱを実行し、１つ以上の出力中間出力及び１つの最終出力を生成してもよい。幾つかの実施形態では、プルーバーは、出力として、入力ワイヤの回路ワイヤに対する割り当てである｛Ｃ，ｘ，ｙ｝の有効トランスクリプトを得るように期待されており、入力ワイヤに割り当てられる値はｘについてのものであり、中間値はＣにおける各ゲートの正しい動作に対応し、出力ワイヤに割り当てられる値はｙに対応し；求められる出力が正しくない場合（即ち、ｙ≠Ｐ（ｘ）である場合）、｛Ｃ，ｘ，ｙ｝に対する有効なトランスクリプトは存在しない。実施形態において、プルーバーは、回路ワイヤの値のサブセットを提供するように期待されており、回路ワイヤの値のうちの選択されるサブセットは、プルーバーにとって事前には分からない。

実施形態において、出力ｙ、内部回路ワイヤの値（又はそのサブセット）、及び評価鍵Ｅ_Ｋは、プルーフ・オブ・コレクトネス３１６を生成するために使用される。プルーフπは、ブロックチェーンにおいて記憶され、プルーバー３０４が複数の当事者と個別的に相互作用する必要なしに、複数の当事者によって検証されることが可能である。このようにして、検証器３０６は、パブリック検証鍵Ｖ_Ｋとプルーフπとを用いてロッキング・トランザクションを検証し、それによってコントラクトを検証することが可能である。場合によっては、クライアント３０２は、検証が失敗した場合に、ロッキング・トランザクションによって制限されているディジタル資産を返還要求する可能性がある。場合によっては、検証器３０６とクライアント３０２は同じコンピュータ・システムである。

図４は本開示の実施形態の図４００を示す。具体的には、図４は、データ・ソースによって提供されるデータが認証され、ブロックチェーン・ネットワークに公開されるスマート・コントラクトなどのプログラム又はスクリプトの実行に利用される環境を示す。実施形態において、クライアント４０２、プルーバー４０４、及びデータ・プロバイダ４０６はコンピュータ・システムである。実施形態では、クライアント４０２は、計算タスクの実行を、本願でプルーバーと言及される別のコンピュータ・システムにアウトソース又は委任するコンピュータ・システムを指す。実施形態において、計算タスクは、機能の評価、スマート・コントラクトの実行などを指す。実施形態では、計算タスクを実行することは、回路及び１つ以上の入力に基づく出力の計算を含み、計算は、クライアントに代わってプルーバーによって実行される。回路は、契約の条項の正式な表現であるソース・コードから生成されることが可能である。

本開示の他の箇所でより詳細に説明されるように、ブロックチェーンにおけるスマート・コントラクトの実行のためのプロトコルは、ゼロ・ナレッジ・プルーフを利用する可能性がある。実施形態では、スマート・コントラクトの実行は、トランザクション検証の一部として生じることが可能である。このために、プロトコルのセットアップ・フェーズの間に生成された公開パラメータは、プルーバーによって提供される主張される適正計算証明を検証し、コントラクトの実行の有効性を検証するために、プルーフ及び入力／出力データと共に使用される。コントラクトの実行フェーズは、幾つかの実施形態では、ブロックチェーンにとって外部の入力／出力データを当てにしていてもよい。一般的に言えば、外部データとは、ブロックチェーン上では入手可能できない、又はブロックチェーンを介してアクセス可能なデータからは検証できない情報を指す。外部データは、データ・フィード及びアプリケーション・プログラミング・インターフェース（ＡＰＩ）のような種々のソースから取得されることが可能である。外部データは、スマート・コントラクトを取り巻く様々な状況において使用される可能性があり、スマート・コントラクトは例えば：資産及び金融アプリケーション（例えば、金利）のための市場価格フィードへのアクセスを必要とする証券（例えば、金利、デリバティブ、債券）で使用されるスマート・コントラクト、外部データへのアクセスを必要とするピア・ツー・ピア保険スマート・コントラクト（例えば、遅延に対して当事者が保険をかけられているフライト情報、農作物保険のための価格インデックスの代わりに気象データ・フィードを使用する金融デリバティブ契約の天候データ）、出荷に関するＧＰＳデータを必要とする取引スマート・コントラクト、乱数発生器へのアクセスを必要とするギャンブル・コントラクトなどを含むが、これらに限定されない。

実施形態では、スマート・コントラクトを実行する時期及び／又は方法を決定することは、現実世界の状態及びイベントに関するデータなどの外部データへのアクセスに依存する。実施形態では、データ・プロバイダ４０６は、そのようなデータを提供し、場合によっては、スマート・オラクルと言及されてもよい。オラクルによって返されるデータは、当事者によって指定される特定の情報が、指定されるテキスト、又は指定される情報を含むかどうかを示すブーリアン形式のような、様々なフォーマット及びタイプにおけるものとすることが可能である。実施形態では、このデータは、賭け（ｂｅｔｓ）（例えば、ボクシングの試合の結果のようなバイナリ・イベントの結果）を組織化するために使用されることが可能である。浮動小数点値は、通貨の間の為替レート（暗号通貨を含む）の文脈で使用されることが可能であり、何らかのビットコイン交換のＡＰＩから読み込むことが可能である。この種のデータは、オプションやヘッジ契約を組織化するのに有用であるかもしれない。

また、データ・プロバイダ４０６は、現実世界の状態及びイベントに関するデータなどの外部データを検索及び／又は提供し、外部データをブロックチェーンにとって利用可能にするオラクルと言及されてもよい。オラクルは実行可能なコードを含むコンピューティング・エンティティを指す可能性があり、そのコードは、コンピュータ・システムの１つ以上のプロセッサで実行される場合に、ブロックチェーンとネットワーク（例えば、インターネット）との間の信頼されるリンクとして働くブロックチェーン（例えば、ビットコイン、イーサリアム、及びその他）と互換性のあるデータ及び／又はデータ・フィードを、コンピュータ・システムに生成させる。オラクルは、ウェブサイト、フィード、データベース、及びその他のデータ・ソースからデータを取得して、外部データをブロックチェーンに提供することが可能である。外部データは、例えば温度情報、出荷のＧＰＳ座標、航空情報（例えば、飛行状態情報）等を含む可能性がある。

実施形態では、プルーバー４０４は以下のようにしてデータ・プロバイダ４０６から外部データを取得する：データ・プロバイダ４０６との暗号で保護された通信セッションを確立し、暗号で保護された通信セッションを介して要求を行い；データ・プロバイダは要求に応じてデータを提供し、プルーバーは、データを受信し、データの受信に応答して、当事者間の通信の証明（ａｎ ａｔｔｅｓｔａｔｉｏｎ）を要求し、データ・プロバイダは、暗号で保護された通信セッションの間に、プルーバーとデータ・プロバイダとの間の通信の暗号的に検証可能なプルーフπ_{Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ}を計算し、データ・プロバイダのプライベート鍵で証明にディジタル署名し；プルーバーは通信のプルーフを受信する。一般的に言えば、通信のプルーフは、クライアントとサーバーとの間（例えば、プルーバーとデータ・プロバイダとの間）で１つ以上の通信が行われたことの暗号的に検証可能な証明である。実施形態では、証明は、クライアントとサーバーとの間の通信の内容を検証するために使用することが可能であるが、場合によっては、例えば、編集された情報を不明瞭な情報（例えば、暗号化された又はハッシュされたフォーマットの情報）で置き換えることによって、又は所定のデフォルト値で置き換えることによって、通信の一部が編集される可能性があることに留意されたい（例えば、情報の開示が法的制限の対象となるような情報である）。実施形態では、証明は、図６に従って説明されるようなマークル・ツリーのルート値に少なくとも部分的に基づいて決定される。実施形態では、証明（例えば、通信のプルーフ）は、データ・プロバイダ４０６に対してアクセス可能な暗号化プライベート鍵を使用してディジタル署名される。認証当局などのエンティティは、プライベート鍵に対応する暗号パブリック鍵を証明するディジタル証明を発行することが可能である。本開示の範囲において、通信のプルーフは、π_{Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ}という表記を使用して一般的に言及される一方、適正実行のプルーフは、π_{Ｐｒｏｖｅｒ}又はよりシンプルにπと言及される可能性があることに留意すべきである。

認証当局４１０は、特定の暗号鍵が特定のエンティティに属することを証明するディジタル証明を生成及び／又は配布するコンピューティング・エンティティを指すことが可能である。例えば、データ・プロバイダのパブリック鍵を含むディジタル証明は、コンピューティング・エンティティによって取得されてもよく、そのようなパブリック鍵は、種々の状況で使用される可能性があり、例えば、データ・プロバイダとの安全な通信のためにデータを暗号化すること、データ・プロバイダによって署名されたとされるディジタル署名の真正を検証こと等のために使用可能である。図４は、クライアント４０２が認証当局４１０と信頼関係を有する実施形態を示しているが（例えば、クライアントは、認証当局によって適切に署名及び／又は発行されたディジタル証明を真正であるとして取り扱う）、鍵管理システム又は鍵レジストリのような任意の適切な信頼されたコンピューティング・エンティティが利用される可能性がある。

プルーバー４０４は、図２に関連して上述したような方法でπ_{Ｐｒｏｖｅｒ}を生成するために入力データを利用する。実施形態では、π_{Ｐｒｏｖｅｒ}は後で使用するためにブロックチェーン４０８上に格納されるか、又はプルーバーがこれらの各々と個別的に相互作用することを必要とせずに、複数の当事者によって検証されることが可能である。例えば、飛行遅延に対する当事者を保証するためのスマート・コントラクトの実行は、入力データとして、公式の航空当局（例えば、米国の連邦航空局又は英国の民間航空当局）から取得される公式の飛行データを当てにすることが可能である。一般的に言えば、入力データは、必ずしも政府筋からのものである必要はなく、スマート・コントラクトの当事者は、入力データが取得される元であるエンティティのリストに合意することが可能であり、従って、データ・ソースは、クライアントがデータを得るために信頼できることを示す任意の適切なコンピューティング・エンティティである可能性がある。クライアントは、異なる入力に対して、信頼できるエンティティについての異なるリストを指定してもよい。信頼できるエンティティのリストは、契約の価値に基づいて選択及び／又は切り詰めることが可能である。

プルーバー４０４は、通信のプルーフをクライアント４０２に送信することができる。場合によっては、データ・プロバイダ４０６は、例えばプルーバーからのコマンドに基づいて、通信のプルーフをクライアント４０２へ送信する可能性がある。先に議論したように、通信のプルーフは、マークル・ツリーのルート値に少なくとも部分的に基づいて導出されることが可能である。例えば、通信のプルーフは、通信が発生した時間インターバルを指定する情報をエンコードすることも可能である。一実施形態では次の通りである：

換言すれば、通信のプルーフは暗号ハッシュ関数を使用して計算され、マークル・ツリーのルート値（ｈ’_{ｆｉｎａｌ}）と通信の時間インターバル（Ｗ_Ｔｉｍｅ：実施形態では、暗号通信セッションの開始時間と通信のプルーフが要求された時間とをエンコードする）とが暗号ハッシュ関数に入力される。実施形態では、暗号ハッシュ関数の入力は、連結されるか、さもなければ結合される。マークル・ツリーは、Ｗ_Ｔｉｍｅにより示される時間インターバルの間に当事者間でやり取りされた記録に少なくとも部分的に基づいて生成されることが可能である。通信のプルーフは、データ・ソースの暗号プライベート鍵を使用してディジタル署名されることが可能である。実施形態では、カンバセーションが行われる時間は、Ｗ_Ｔｉｍｅ＝［Ｔ_{ＳｅｓｓｉｏｎＳｔａｒｔ}，Ｔ_{ＰｒｏｏｆＲｅｑｕｅｓｔ}］として規定され、サーバー（例えば、データ・ソース５０４）によって生成される通信のプルーフの一部として含まれる。なお、プルーバー４０４は、通信のプルーフをクライアント４０２へ送信することに加えて及び／又はその代わりに、そのプルーフを、セキュア・サーバー（例えば、クライアント４０２に関連するパブリック鍵の下で暗号化される）又はコンピューティング・リソース・サービス・プロバイダのデータ・ストレージ・サービスに記憶することができる。実施形態では、クライアント４０２は、通信のプルーフをデータ・リポジトリ（例えば、データ・ストレージ・サービス）に記憶し、クライアント４０４に、データ・リポジトリから通信のプルーフを取得するために使用可能なユニフォーム・リソース識別子（ＵＲＩ）又は他の適切なリファレンスを提供する。例えば、（例えば、何日にもわたって１つ以上の経路に対する飛行データを捕捉することのような）繰り返されるタスクを実行するプルーバー４０２は、捕捉されたデータを、データ・リポジトリのコンテナに集約し、その結果、クライアントは時間インターバルにわたって（例えば、特定の経路について）過去の飛行データを取得することができる。

実施形態では、クライアント４０２は、通信のプルーフ及び通信のプルーフのディジタル署名を受信する。クライアントは、ディジタル署名がデータ・プロバイダによって署名された主張されていることを確認し、データ・プロバイダに関連するパブリック鍵を取得し（例えば、認証当局４１０によって発行されるディジタル証明から取得し）、ディジタル署名の真正を検証するためにパブリック鍵を使用することができる。ディジタル署名が真正であると判断された場合、クライアント４０２は、通信のプルーフがデータ・プロバイダによって生成されたことを信頼し；そうでない場合は、通信のプルーフ及びディジタル署名は破棄される可能性がある。通信のプルーフを検証した後、クライアント４０２は、図２及び図３に関連して説明したような方法で、プルーフ・オブ・コレクトネスを検証することが可能である。

幾つかの実施態様において、クライアント４０２は、特定のプルーバー４０４から取得された外部データが正しかったこと（例えば、データはデータ・プロバイダによって提供されたものと同じデータであったこと）を示す評判トランザクションを生成する。評判トランザクションは、プロバイダ４０４が計算タスクを正しく実行したかどうか、及び／又はプロバイダ４０４が、データ・プロバイダから受信した外部データを使用してπ_{Ｐｒｏｖｅｒ}の計算を実行したことに関し、それが偽りなきものであったかどうかの記録として、ブロックチェーン４０８にマイニングされてもよい。スマート・コントラクトが実行された後、クライアントは、π_{Ｐｒｏｖｅｒ}を生成するのに使用された入力データがデータ・プロバイダにより提供されたものであったことを検証するために、π_{Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ}を使用することが可能である。評判トランザクションは、プルーバーにより提供されるサービスのレビューを示すブロックチェーンにマイニングされる可能性があり、肯定的な結果は、プルーバーに正直に行動するインセンティブを与える可能性があり、その後のスマート・コントラクトの実行のためにプルーバーを選択するために使用される可能性がある。評判トランザクションは、π_{Ｐｒｏｖｅｒ}で使用される入力データがデータ・プロバイダから来ていることの十分な証拠を提供した上で、プルーバーが評判トランザクションのロックを解除できるようにする第１アンロッキング・スクリプトと、クライアントがレビューを取り消すことを可能にする第２アンロッキング・スクリプトとを含む可能性がある。図４に示される評判トランザクションは、本開示の他の箇所で説明されるもの、例えば図９に関連して以下で説明されるものに従う可能性がある。

一般的に言えば、図４の状況においてクライアントは、ターゲット・ソースｓｒｃ、時間τ、及びクエリｑを指定するリクエストＲｅｑ（ｓｒｃ，τ，ｑ）を作成する。ｓｒｃがウェブ・サーバーである場合、ＴＬＳセッションのような暗号で保護された通信セッションが必要とされる可能性がある。実施形態では、暗号で検証可能な信頼性の保証を提供する、暗号で保護された任意の通信セッションが使用されてもよく、ここで、当事者間のメッセージは、同じシークレット鍵を使用して生成及び検証の双方が行われるメッセージ認証コード（ＭＡＣ）によって認証される。これは、サーバーとメッセージの受信者とが同じ鍵に同意しなければならないことを意味し、従ってＭＡＣを検証することが可能な任意のユーザーは他のメッセージに対してもＭＡＣを生成することが可能である。これに対して、ディジタル署名は、特定のメッセージが特定のプライベート鍵の保持者によって署名された、ということを提供することができる。通信を認証するアプローチはＴＬＳＳｉｇｎＯｎＯｆｆと呼ばれる新しいサブ・プロトコルを規定する「ＴＬＳ Ｓｉｇｎ」においてＨａｊｊｅｈ及びＭ．Ｂａｄｒａによって考察されており、ここで、クライアント及びサーバーは、それらが署名済みデータを送信することを開始又は停止した場合にピアに通知する。停止メッセージの後に、サーバーは、カンバセーションのハッシュを収集し、それに署名する。暗号で保護された通信セッションの記録データを認証するための他の様々なアプローチ（例えば、セッションの記録を保存し、記録された通信の真正性及び／又は完全性を暗号で検証可能な証拠として会話に署名する）が使用されることが可能であり、これについては次の技術文献を参照されたい：“Ｒ． Ｈｏｕｓｌｅｙ ａｎｄ Ｍ． Ｂｒｏｗｎ， “Ｔｒａｎｓｐｏｒｔ Ｌａｙｅｒ Ｓｅｃｕｒｉｔｙ （ＴＬＳ） Ｅｖｉｄｅｎｃｅ Ｅｘｔｅｎｓｉｏｎｓ” ａｎｄ ｂｙ Ｈ． Ｒｉｔｚｄｏｒｆ， Ｋ． Ｗu^..ｓｔ， Ａ． Ｇｅｒｖａｉｓ， Ｇ． Ｆｅｌｌｅｙ， ａｎｄ Ｓ． Ｃａｐｋｕｎ， “ＴＬＳ－Ｎ： Ｎｏｎ－ｒｅｐｕｄｉａｔｉｏｎ ｏｖｅｒ ＴＬＳ Ｅｎａｂｌｉｎｇ Ｕｂｉｑｕｉｔｏｕｓ Ｃｏｎｔｅｎｔ Ｓｉｇｎｉｎｇ ｆｏｒ Ｄｉｓｉｎｔｅｒｍｅｄｉａｔｉｏｎ”これらはクライアントがリクエストを作成した場合に始まるエビデンス・ウィンドウを規定し、当事者のうちの一方がエビデンス・ウィンドウを閉じると、メッセージのハッシュ、及びエビデンスの生成のタイムスタンプは、オプションとして機密の記録が隠されて、サーバーにより署名される。

図５は、プルーバー５０２がデータ・ソース５０４からデータを取得する実施形態の例示的な図５００である。実施形態では、プルーバー５０２とデータ・ソース５０４との間に暗号で保護された通信セッションが確立される。暗号で保護された通信セッションの具体例は、ＴＬＳ（Ｔｒａｎｓｐｏｒｔ Ｌａｙｅｒ Ｓｅｃｕｒｉｔｙ）及びＳＳＬ（Ｓｅｃｕｒｅ Ｓｏｃｋｅｔｓ Ｌａｙｅｒ）セッションを含む。暗号で保護された通信セッションは、当事者間の安全な接続を提供するために利用されることが可能である。この状況において、セキュアな接続は、真正性、完全性、プライバシー、又はそれらの任意の組み合わせの暗号で検証可能な保証を指す可能性がある。真正性とは、メッセージの作成者であると主張する者によってメッセージが作成されたという保証を指す可能性がある。完全性とは、受信したメッセージが、メッセージが送信されたときの元の形式から、意図的でも（例えば、悪意のある者によって）又は意図的でなくとも（例えば、送信中の信号の欠落の結果として）変更されなかったという保証を指す可能性がある。機密性とは、送信前のメッセージの一部又は全部の暗号化を指す可能性がある。実施形態では、クライアント（例えば、プルーバー５０２）とサーバー（例えば、データ・ソース５０４）とは、ハンドシェイク５０８と呼ばれる第１フェーズの間に情報を交換し、セキュリティを確保するために、非対称暗号化と対称暗号化とのハイブリッドが行われる。図５に示されるハンドシェイクは、ＴＬＳハンドシェイク・プロトコルに従う４ウェイ・ハンドシェイクであってもよい。実施形態では、クライアント（例えば、プルーバー５０２）は、クライアント・バージョン、セッションｉｄ、追加的な拡張による追加機能、又はそれらの組み合わせなどのパラメータを含むＣｌｉｅｎｔＨｅｌｌｏメッセージを送信する。実施形態では、ハンドシェイクは、カンバセーションのためのプルーフの記録を開始するために、サーバー（例えば、データ・ソース５０４）への信号のメッセージで始まる。その結果、サーバー（例えば、データ・ソース５０４）はプルーフ生成に関連する内部状態に入り、この状態は、通信のプルーフを生成するための後続の要求を受け取るまで続く。この内部状態では、データ・ソース５０４は、暗号で保護された通信セッションを介してやり取りされた、プルーバー５０２とデータ・ソース５０４との間の通信の内容（又はその一部）を記録する可能性がある。

ハンドシェイクの後（例えば、記録プロトコルの間）、送出メッセージはブロックに分割される一方、到来メッセージは再構築される。実施形態では、暗号で保護された通信セッションの当事者間のカンバセーションは、複数の記録Ｒ_１，．．．Ｒ_ｉを含む。これらの記録は、例えば一組のリーフ・ノードを含むマークル・ツリーを生成することによって、通信のプルーフを生成するために利用されることが可能であり、一組のリーフ・ノードはレコードＲ_１，．．．Ｒ_ｉを含む。図５に関連して図示され説明される記録は、図６に関連して説明されるもののようなマークル・ツリーを生成するために使用されることが可能である。

実施形態では、記録は、暗号で保護された通信セッションの一部として、プルーバー５０２とデータ・ソース５０４との間でカンバセーションを形成するリクエスト（要求）及びレスポンス（応答）を指す。場合によっては、要求及び応答は、必要以上の情報（例えば、プルーバー５－２がスマート・コントラクトの実行に関して必要とする入力データを決定するのに無関係な情報）を含む。実施形態では、サーバー（例えば、データ・ソース５０４）は、テンプレート（例えば、特定のフィールドを有するＪＳＯＮノードの形式）で記入する。テンプレートは、ハンドシェイクの間に指定されてもよい。一例として、気象データを得るためのテンプレートは、場所、日付、及び温度に関するフィールドを有する可能性がある。実施形態では、飛行データのリクエストは、飛行状態、フライト識別子、及び日付を含む可能性があり、例えば｛“ｆｌｉｇｈｔＩｎｆｏ”：｛“ｄａｔａ”：｛“ｉｄ”：“ＢＡ８８６”：［｛“ｖａｌｉｄＤａｔｅ”：“２０１７－１１－０１Ｔ０７：００：００＋００００”｝，“ｓｔａｔｕｓ”：“Ｏｎ ｔｉｍｅ”｝］｝のような形式におけるものである。

ハンドシェイクが完了すると、当事者（例えば、プルーバー５０２及びデータ・プロバイダ５０４）は、データを含む相互間で記録５１０を送信することができる。例えば、プルーバー５０２は、回路を評価し、スマート・コントラクトの実行の一部として出力を生成するための入力として使用することが可能なデータ・プロバイダ５０４からのデータを要求することができる。プルーバー５０２が回路を評価するのに十分なデータを受信した後、プルーバーはデータ・プロバイダ５０４からのセッションのプルーフ５１２を要求することができる。データ・プロバイダ５０４は、クライアント（例えば、図３及び図４に関連して説明されるクライアント）と信頼関係を有するコンピュータ・システムであってもよく、クライアントは、データ・プロバイダによって生成及び／又は提供されるデータを信頼し、この状況では、クライアントが他のエンティティからのデータを信頼することは、エンティティから取得したデータをクライアントが正しいものとして受け入れること、及び／又は、有効なセキュリティ証明を有する信頼されるソースから公表されるデータは真正かつ正確であることをクライアントが受け入れることを指す可能性がある。実施形態では、サーバー（例えば、データ・ソース５０４）は、ハンドシェイク・プロトコルの完了からπ_{Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ}を生成する要求が受信されるまでの記録プロトコルの間に当事者間で交換される全ての記録のハッシュ・ルート５１４から構成される通信５１６のプルーフを生成する。また、実施形態では、データの実行が、入力が特定の時間に収集されることに左右される等の場合（例えば、特定の日の特定のフライト番号の遅延に対する保護をもたらすフライト保険のスマート・コントラクト）において、Ｗ_Ｔｉｍｅもまた記録と共にハッシュ処理される。

実施形態では、クライアント（例えば、プルーバー５０２）はπ_{Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ}を要求し、データ・プロバイダは、連結され、ハッシュされ、データ・ソースのプライベート鍵でディジタル署名された全ての記録及びＷ_Ｔｉｍｅのコミットメントから取得されるハッシュ・チェーンの最終値を返す。従って、当事者間で通信される記録に含まれるデータは、スマート・コントラクトの実行で使用されることが可能である。この通信のプルーフπ_{Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ}は、初期のスマート・コントラクトにも供給することができ、専用の機能により検証されることが可能であるので、半信半疑のプルーバーの必要性を排除することができる。実施形態では、図６に関連して説明されるような方法で、記録はマークル構造で一緒にハッシュされる。

図５に関連して、セッション・クライアントがセッション・サーバーからのプルーフを要求する実施形態が説明されているが、それは必須ではないことに留意すべきであり、本願で説明される技術は、ＴＬＳセッションのサーバーがＴＬＳセッションのクライアントからの通信のプルーフを要求するように、適用される可能性もある。

図６は、本開示で説明される種々の実施形態に従って構築及び／又は利用される可能性があるマークル・ツリーの例示的な図６００である。例えば、そのようなマークル・ツリーは、図２～図５に関連して説明される実施形態の状況で構築される可能性がある。

実施形態では、クライアント・コンピュータ・システム及びサーバー・コンピュータ・システムは、ＴＬＳセッションなどの暗号で保護される通信セッションを確立し、メッセージ（例えば、記録）をやり取りする。セッションの当事者間で通信される１つ以上のレコードＲ_１．．．Ｒ_ｉは、例えばハンドシェイク・プロトコルの完了から、サーバーが通信のプルーフを生成するためにクライアントから要求を受け取るまでの指定された期間内に、サーバーによって記録されることが可能である。実施形態では、サーバーは実行可能なコードを含み、コードは、サーバーの１つ以上のプロセッサによって実行されると、サーバーに：クライアントとサーバーとの間で通信の記録を開始する指示を検出すること；暗号で保護された通信により送受信された記録を格納すること；通信のプルーフを生成する指示を検出すること；及び格納された記録に少なくとも部分的に基づいてマークル・ツリーを生成することを行わせる。上述のプロセスに対する種々の代替及び拡張が考えられる。マークル・ツリーは、マークル・ツリーの各リーフ・ノードがデータ・レコードのハッシュであり、少なくとも暗号ハッシュ関数を使用して、非リーフ・ノードの各々が、非リーフ・ノードの子ノードから、少なくとも部分的に基づいて導出されるデータ構造を指す可能性がある。しかしながら、本願に含まれる技術は、マークル・ツリーに類似する構造を利用して、特定のデータの一部がマークル・ツリーの一部であることを検証することが可能であることに留意すべきであり、例えば、実施形態において、本願に含まれる技術はある構造に適用され、その構造において、ツリーのリーフ・ノードはデータ・レコードであり、非リーフ・ノードは、少なくとも暗号化ハッシュ関数を使用して、非リーフ・ノードの子ノードから少なくとも部分的に基づいて導出される。実施形態において、本願で説明されるツリー・データ構造は、バイナリ・ツリーである。図６は、アンバランスなマークル・ツリーの例を示しているが、幾つかの実施形態では、マークル・ツリーのリーフ・ノードは、ツリーのバランスがとれるように又はバランスが実質的にとれるように配置される（例えば、実質的にバランスがとれたツリーは、ツリーの特定の深さに全てのリーフを有することが可能である）ことに留意されたい。

実施形態では、マークル・ツリーは、格納された（例えば、サーバーによってＲＡＭのような短期メモリにキャッシュされた）１つ以上のレコードＲ_１．．．Ｒ_ｉから生成され、通信のプルーフを生成する指示を検出すると、レコードは、マークル・ツリーのリーフ・ノードとして時系列的に選択される。各レコードは、ＴＬＳプレ・マスター・シークレット又はマスター・シークレットのようなハンドシェイク・トラフィック・シークレットから導出される可能性があるランダム・ソルト値とともに暗号ハッシュされる。ソルトは、任意の適切な確率過程を用いて生成される擬似乱数又は乱数である可能性がある。これらのソルトは、それらが特定のマークル・ツリーの状況の中で再利用されないように選択されるか、又は任意の２つのソルトが同じ値である確率が閾値確率を下回るように選択されてもよい。

第１ソルトと第１レコードは暗号ハッシュ関数へ入力されることが可能であり、第１ソルトと第１レコードは連結され、（例えば、ＳＨＡ－２５６暗号ハッシュ・アルゴリズムを使用して）ハッシュされる。一般的に言えば、暗号ハッシュ関数が示されている場合には、一方向関数のようなプレ・イメージ耐性関数が利用されてもよい。図６に示す例示的な例ではソルトが利用されているが、一般的に言えば、レコードはノンス、初期化ベクトル、及び任意の他の適切な暗号プリミティブで増強されてもよい。第１出力は、第１ソルトと第１レコードとを入力として利用して暗号ハッシュ・アルゴリズムを実行することにより生成される。第１出力は、第１レコードがクライアント又はセッションのサービスによって送信されたかどうかを示す情報でハッシュされる可能性がある。例えば、図６は、クライアントに関連する情報がハッシュ出力の前に付加される実施形態を示しており、この場合においてクライアントはレコードの送信者であり、サービスに関連する情報がハッシュ出力に付加され、この場合においてサービスはレコードの送信者である。前に付加される／後に付加される情報は、任意の適切な情報である可能性があり、固定クライアント値（例えば、ゼロ）及び固定サーバー値（例えば、１）が利用されてもよい：

実施形態では、ツリー構造は固定され、クライアント又はサービスに関連する値（例えば、送信者に関連するＩＰアドレス又はＭＡＣアドレス）が、マークル・ツリーに前に付加／後に付加される。そのような例（図６には示されていない）では次のようになる：

暗号で保護された通信セッションを介して送信される追加のレコードは、上述の方法で作成され、ルート・ノード値を生成するために順次一緒にハッシュされることが可能である。図６に示される例では、各ノードは中間ノード値を生成する：

一実施形態（図６には示されていない）では：ｈ’_Ｒ１＝ｈ_Ｒ１である。

実施形態では、最終的なハッシュ値は、ｈ’_{Ｒｌａｓｔ}＝Ｈ（ｈ_{Ｒｌａｓｔ－１}，ｈ_{Ｒｌａｓｔ}）のように算出され、これはマークル・ツリーのルートである。実施形態では、ｈ’_{Ｒｌａｓｔ}は通信のプルーフである。実施形態では、ｈ’_{Ｒｌａｓｔ}は時間インターバル（例えば、Ｗ_Ｔｉｍｅ，Ｒ_１及びＲ_ｌａｓｔに関するタイムスタンプ）などの追加情報によって増強され、これらは通信のプルーフを形成するために一緒にハッシュされることが可能である。通信のプルーフは、暗号通信セッションのサービスに関連するプライベート鍵によってディジタル署名される可能性があり、そのサービスは、スマート・コントラクト・クライアントによって信頼されるエンティティである（例えば、図３及び図４に関連して説明されているようなものである）。

図７は、本開示で説明される種々の実施形態によるマークル・パスの例示的な図７００である。マークル・パスは、暗号で保護された通信セッションのクライアントとサービスとの間でカンバセーション中に、特定のレコード（より一般的には、特定のデータ又は情報の特定の部分）が通信されたことの暗号で検証可能な保証を提供するために利用されることが可能である。マークル・パスは、図６に関連して説明されるマークル・ツリーから構成されることが可能であり、図２～図５に関連して説明された実施形態の状況で利用されることが可能である。

実施形態では、プルーバーは、データ・ソースからデータを受信し、該データを演算回路を解くための入力として使用し、回路の出力に少なくとも部分的に基づいて適正実行のプルーフを生成する。プルーバーは、追加的に、演算回路を解く場合に使用されたデータが、プルーバーとデータ・ソースとの間の一群の通信に含まれていたことの証明を生成することが可能である。実施形態では、証明はマークル・パスであり、マークル・パスは、マークル・ツリーのルート値を計算するのに十分なマークル・ツリーの一群のノード値を含む。マークル・パスは、マークル・ツリーのリーフ・ノード値の全部又は一部を含んでもよいし、又は全く含まなくてもよい。マークル・パスは、マークル・ツリー内のノード値の位置に関する情報を含む可能性がある。ルート・ノード値は、より大きなマークル・ツリーのサブツリーのルート・ノード値である可能性があることに留意すべきである。証明は、プルーフ・オブ・コレクトネスπ_{Ｐｒｏｖｅｒ}にエンコードされてもよい。

実施形態では、コンピューティング・エンティティは、次のようにすることで、特定の通信の内容が２つの他のコンピューティング・エンティティ間の一群の通信に含まれていたことを検証することが可能であり、即ち：信頼されたエンティティのプライベート鍵を使用して生成されたルート・ノード値に対するディジタル署名及びマークル・ツリーのルート・ノード値を、信頼されたエンティティから受信し；信頼されたエンティティのパブリック鍵を使用してディジタル署名の真正を検証し；一群のノード値を含むマークル・パスを受信し（一群のノードのうちのノードは、通信されたと主張される特定の通信に対応する）；主張されているルート値を一群のノード値から計算し；及び主張されるルート値を、検証されたルート・ノード値と比較する。

図７に示されるマークル・パス７０２を考察する。これは、実施形態において、図６に関連して説明されるマークル・ツリーに基づいて導出される。図７に示されるマークル・パス７０２は、特定のレコードＲ_３が、（例えば、ＴＬＳセッションのような）クライアントとサーバーとの間の一群の通信の一部として含まれていたことを検証するために利用されることができる。マークル・パス７０２の一群の値は、最終ハッシュ値を生成するために一緒にハッシュされることが可能である。実施形態では、最終的なハッシュ値は、値が一緒にハッシュされた順序を示すマークル・パス内でエンコードされるか、又はそれに関連する追加情報に基づいて生成される。例えば、図７に示されるマークル・パス７０２は、図７に示されるような最終値ｈ_Ｒ４＝Ｈ（Ｈ（ｈ’_Ｒ２，Ｈ（０，Ｈ（ｓａｌｔ_Ｃ３，Ｒ３））），ｈ_Ｒ４）を計算するために使用されることが可能である。最終値がルート値（例えば、図６のｈ’_{Ｒｌａｓｔ}）と一致する場合、コンピューティング・エンティティは、レコードＲ_３が、カンバセーションの当事者間の一群の通信ののうちの通信として含まれていたと判断する。

一般的に言えば、マークル・パスは、ルート・ノードの値を計算するのに十分なマークル・ツリーの一群のノード（又はこれらのノードの値）を指す可能性がある。ルート・ノードは、図７に示すマークル・ツリーのルート・ノード、又はそのようなツリーのサブツリーであってもよい。図７に示すマークル・パスのようなマークル・パスは、２つのリーフ・ノードの値をエンコードすることが可能であり、リーフ・ノードからルート・ノードまでの間のマークル・ツリーの各々の深さにおいて、正確に１つの値が、マークル・ツリーの正確に１つのノードに対応する。しかしながら、これは必須ではない：別の適切なマークル・パスは、マークル・ツリーの各リーフ・ノードの値を含むが、そのようなマークル・パスは図７に示されるような他のマークル・パスよりも大きなストレージ条件を有する可能性がある。

図８は、様々な実施形態に従ってプロトコルを実装するために利用される可能性があるコンピューティング環境の図８００を示す。プロトコルは、ブロックチェーン外部のデータに基づいて生成されるプルーフ・オブ・コレクトネスを格納するために、ブロックチェーン技術を使用して実装されてもよい。実施形態では、プルーバー８０２、データ・ソース８０４、クライアント８０６、認証当局８０８、及びブロックチェーン８１０は、本開示の他の箇所で説明されるものに従っており、これらの構成要素はコンピューティング・システムとして実装されることが可能である。

実施形態では、プルーバー８０２は実行可能なコードを含むコンピュータ・システムであり、コードは、コンピュータ・システムの１つ以上のプロセッサによって実行されると、コンピュータ・システムにデータ・ソース８０４からのデータを要求させる。データ・ソース８０４は、クライアント８０６と信頼関係を有する任意の適切なコンピューティング・エンティティであるすることが可能である。データは、現実世界のイベント、又は、より一般的にはブロックチェーン上では入手できないデータに関連する可能性がある。要求される可能性のあるデータの例は、特定の日付の航空路線フライトの状況（例えば、遅延、キャンセル、定刻到着など）であってもよい。データ・ソース８０４は、要求に応じて、要求されたデータを提供することが可能であり、要求は、データグラム、ウェブページ、ＪＳＯＮフォーマットなどの形式で、任意の適切なフォーマットで提供されることが可能である。実施形態では、プルーバーは、データを受信し、データが受信されたと判断したことに応答して、通信のプルーフのための第２要求をデータ・ソース８０４に提出する。データ・ソース８０４は、データがデータ・ソースによってプルーバーに提供されたことの暗号的に検証可能な保証を提供する通信のプルーフ８１２を生成する。通信のプルーフは、データ・ソースのプライベート鍵によってディジタル署名されることが可能であり、ディジタル署名の真正は、データ・ソースに関連付けられたパブリック鍵を使用して検証されてもよい。パブリック鍵を含むディジタル証明は、認証当局８０８によって発行されてもよい。プルーバー８０２及びデータ・ソース８０４は、真正性、完全性、及び機密性の暗号的に検証可能な保証を提供するＴＬＳセッションのような暗号で保護された通信セッション８１４を介して通信することが可能である。

実施形態では、プルーバー８０２は、スマート・コントラクトの条項をカプセル化するクライアント８０６から演算回路を受信する。プルーバー８０２は計算を実行することが可能であり、データの計算は、データ・ソース８０４から得られるデータに少なくとも部分的に基づいて実行される。プルーバー８０２は、出力を取得し、ブロックチェーン・ネットワーク８１０にブロードキャストされて記録される回路の適正実行のプルーフ８１４を生成し、それによってブロックチェーンのノードがスマート・コントラクトを検証できるようにする。

オフ・チェーン・データ（例えば、現実世界のデータ）を含むスマート・コントラクトの実行は、当事者間の異なる信頼度合いに依存する。信頼を獲得するために、プルーバーは、データを生成するために信頼したデータ・ソースとプルーバーとの間で特定のカンバセーションが行われたことを、クライアント（又は、プルーバーが正直かどうかを検証する何らかの他のシステム）に示すことができる。実施形態では、プルーバーは、通信のプルーフ及び演算回路を評価するために使用される入力データを含むレコードを含むマークル・パス（例えば、図７に関連して説明されたようなもの）をクライアントに提供する（８１８）。クライアントは、マークル・パス及び通信のプルーフを受信し；信頼されるデータ・ソースに関連するパブリック鍵を取得し（例えば、認証当局８０８からの、データ・ソースのパブリック鍵を含むディジタル証明を要求することによって）、通信のプルーフで生成されるディジタル署名の真正を検証することにより、特定のレコード（又は、レコードのデータ）が、信頼されるデータ・ソースとの通信の一部であったことを検証し（８２０）；マークル・パスからハッシュ出力を生成し；生成されたハッシュ出力が、受信された通信のプルーフと一致することを検証する。このようにして、クライアントは、スマート・コントラクトの入力が信頼されるソースによって提供されたことを判断することができる。

実施形態では、クライアントは、本開示の他の箇所で述べられているような方法、及び／又は英国特許出願第１７１９９８．５号で述べられている技術を使用して、プルーフ・オブ・コレクトネスを検証する（８２２）。また、クライアントは評判トランザクションを生成し（８２４）、これはブロックチェーンに記録され（８２６）、前述の特定のスマート・コントラクトの実行の遂行において、プルーバーが誠実に行動したかどうかを示すクライアントのレビューをブロックチェーン・ネットワークにブロードキャストすることができる。この文脈では、「正直に」は、プルーバーが、不誠実なエンティティとは異なり、スマート・コントラクトを実行するためにデータ・ソースによって提供されたのと同じデータを使用していることを指す可能性があり、不誠実なエンティティは、スマート・コントラクトを実行するために異なる入力を使用し、それによって、幾つかの実施例ではスマート・コントラクトの実行の結果を別物にしてまう。

図９は、図４及び図８に関連して説明される実施形態のような、様々な状況において利用されることが可能な評判トランザクション９０２の例示的な図９００である。実施形態では、評判トランザクションは、プルーバーが正直であるという仮定を伴う一種の事後的なコントラクト実行検証である。このタイプの検証は、実施形態においては、コントラクトの実行に影響を及ぼすものではなく、むしろプルーバーの評判に寄与するメトリックとして利用される。いったんスマート・コントラクトが実行されると、クライアントは、プルーバーを奨励することで、スマート・コントラクト市場のパフォーマンスを向上させるインセンティブにより、プルーバーのサービスを検討する機会を有する。逆に、プルーバーは、彼らがそのように行動するかどうかは、自身の評判や彼らの将来の潜在的なクライアントに直接影響を及ぼすので、正しく行動するようにインセンティブが与えられ、クライアントは彼らの評判（又は評判の欠如）に基づいてプルーバーを選択する可能性がある。

実施形態では、クライアント（例えば、図４に関連して説明されるようなもの）は、レビューア９０４の入力とともにトランザクションを作成する。レビューアの入力は、クライアントのプライベート鍵を使用して署名されたトランザクション入力である可能性がある。一般的に言えば、レビューア入力は、クライアントが評判トランザクションのレビューアであるという公に検証可能な証明を提供する任意の情報であってよい。評判トランザクションは３つの出力を備える。検証９０６の出力は、パブリック鍵、署名、及びマークル・パスを入力として取る関連するアンロッキング・スクリプトを有する可能性がある。検証時に、マークル・パスは、信頼されたエンティティ（例えば、図４に関連して説明されるデータ・プロバイダ）によって署名され送信されたカンバセーション・プルーフに、レコードが属していることを証明するために使用されることが可能である。一般的に言えば、検証９０６の出力は、期待される値を生成するために使用可能な認証情報と期待される値とを含むトランザクション出力であり、期待される値はディジタル署名され、ディジタル署名の真正は、上述のように、パブリック鍵を用いて検証可能である。認証情報は、実施形態では、ルート・ハッシュ値を生成するために使用可能なマークル・パスである。第２出力は、クライアントに属するアドレスを含む取り消し９０８の出力であってもよい。実施形態では、取り消し出力のロック解除は、レビューがキャンセルされるか、又は取り消されることを象徴する。評判トランザクションは、レビュー・メタデータ９１０を、プルーバーの身元（例えば、プルーバーのアドレス）、プルーバーが実行したスマート・コントラクト、及び肯定的なレビューの指示に関する情報を含む第３トランザクション出力として、レビュー・メタデータ９１０をエンコードすることも可能である。ビットコイン・ベースの実施形態では、評判メタデータ９１０は、ＯＰ＿ＲＥＴＵＲＮ出力として実装される。実施形態では、出力は、ディジタル資産の名目上の量（例えば、ダスト値（ｄｕｓｔ ｖａｌｕｅｓ））を有してもよいし、又は全く値を持たなくてもよい（消費できないＯＰ＿ＲＥＴＵＲＮ出力の場合である）。ビットコイン・ベースのシステムは、実施形態では、以下に従って実装される評判トランザクションを有する可能性がある：

ＯＰ＿ＣＡＴは２つの文字列を連結するのに相応しい任意のオペコード、ルーチン、コマンド、又はファンクションを指す可能性があることに更に留意すべきである。

図１０は、通信のプルーフを生成するためのプロセス１０００の説明図である。実施形態では、プロセス１０００は、ハードウェア、ソフトウェア、又はそれらの組み合わせを使用して実装される。プロセスを実行するために適切なシステムは、図４に関連して説明されたようなデータ・プロバイダを含む。一般的に言えば、プロセス１０００を実行するシステムは、スマート・コントラクト又は他の計算タスクの実行を、他のコンピューティング・エンティティに委任するコンピューティング・エンティティによって信頼される任意の適切なシステムであってよい。この文脈において、信頼とは、あるコンピューティング・エンティティが、その信頼されるエンティティから発信された及び／又はそれによってブロードキャストされたデータを、正しいものとして受け入れること、及び／又は、有効なセキュリティ証明とともに、信頼されるソースから公表されたデータは真正かつ正確である、ということを指す可能性がある。

実施形態では、プロセス１０００を実行するシステムは実行可能なコードを含み、コードは、システムの１つ以上のプロセッサによって実行されると、プルーバーのようなコンピューティング・エンティティとの暗号で保護された通信セッションを、システムに確立させる。クライアントは、スマート・コントラクトの実行で使用されるデータについて信頼できるソースのリストを有する可能性があり、そのリストは（例えば、スマート・コントラクトの一部として、あるいはそれと関連して、あるいはブロックチェーンの他の場所で）公開される可能性がある。暗号で保護された通信セッションの例は、ＴＬＳセッションである。

システムは、システムと相手方の間の通信の認証を開始するための指示を検出する可能性がある（１００４）。指示は、プロトコルの一部として暗黙的に定義される可能性があり、例えば、システムは４ウェイ・ハンドシェイク・プロトコルの完了時に通信の認証を開始する可能性がある。実施形態では、指示は、記録プロトコルによるメッセージとしてシステムによって受信され、メッセージは通信の認証を開始することを示す。認証通信は、２つ以上のコンピューティング・エンティティ間の認証通信及び／又はカンバセーションと言及されてもよいことに留意されたい。通信の認証を開始する指示の一部として、システムは、システムが通信の認証を開始した時間のタイムスタンプを記録してもよい。

通信の認証を開始する指示に続いて、システムは、記録プロトコルの一部としてデータを受信及び／又は送信することができ（１００６）、通信（又はそこに含まれるデータ）は、データ構造として短期メモリなどの任意の適切なフォーマットで記録される可能性がある。データの受信及び送信に関連して示される積み重なるボックスは、複数のレコードが受信及び送信される可能性があることを示すが、そのことは必須ではなく、一実施形態では単一のレコードが受信及び／又は送信される。

実施形態では、システムは、通信の認証を開始する指示を受信した後に、相手との通信の認証を終了する指示を受信する可能性がある（１００８）。実施形態では、システムは、認証通信を終了する要求が検出されたときのタイムスタンプを記録する。ある場合には、暗号で保護された通信セッションの終了などによって、終了は暗黙的に検出される。

実施形態では、システムは、認証期間中に（即ち、システムが通信の認証を開始して認証を終了するまでの間に）送信及び／又は受信された記録（又はその一部）に基づいて通信のプルーフを生成する（１０１０）。システムは、図７に関連して説明した方法でマークル・ツリーを生成することによって、通信のプルーフを生成することが可能である。マークル・ツリーのルートは通信のプルーフであるとすることが可能である。実施形態では、通信のプルーフは、認証された通信が発生した時間インターバルをエンコードするマークル・ツリー及びＷ＿ｔｉｍｅのルートに基づいて決定される。通信のプルーフは、プライベート鍵を使用してシステムによってディジタル署名されることが可能であり、対応するパブリック鍵は、ディジタル証明を発行する所定の認証当局によりアクセス可能である。実施形態では、システムは、図３～図５及び図８に関連して説明されるデータ・プロバイダである。通信のプルーフを生成すると、システムは、通信のプルーフを、セッションの相手（例えば、プルーバー）及び／又は他のエンティティ（例えば、セッション中にプルーバーによって指定されたクライアント）に送信してもよい（１０１４）。

図１１は、ブロックチェーン・ネットワークに公開されたスマート・コントラクトのような、認証されたデータを使用してプログラム又はスクリプトを実行するプロセス１１００の説明図である。実施形態では、外部データ（例えば、現実世界のイベントに関するデータ）は認証（信頼）されるが、ブロックチェーンから取得可能なデータは認証されない。この文脈で言及されるデータは、スマート・コントラクトで使用される出力を生成するために、演算回路の評価の一部として使用される入力データを指す可能性がある。実施形態では、プロセス１１００は、ハードウェア、ソフトウェア、又はそれらの組み合わせを使用して実装される。このプロセスを実行するために相応しいシステムは、図２～４及び８に関連して説明されたもののようなプルーバーを含む。

実施形態では、システムは、クライアントに代わってスマート・コントラクトを実行するために、外部データが取得されるべきであると判断する。システムは、データが取得され得る取得元のコンピューティング・エンティティを識別することが可能であり（１１０２）、コンピューティング・エンティティは、クライアントによって信頼されているエンティティである。クライアントは、スマート・コントラクト又はブロックチェーン上の他の場所における又はそれに関連する信頼されるエンティティのリストを公表することが可能であり、システムは、そこから外部データを取得するために、任意の適切な信頼されるエンティティを選択する。実施形態では、システムは、データ・ソースとの暗号で保護された通信セッションを確立する（１１０４）。暗号で保護された通信セッションの例は、ＴＬＳ又はＳＳＬセッションである。

実施形態では、システムは、ソースからの外部データを要求し、暗号で保護された通信セッションを介して、データ・ソースからデータを受信する（１１０６）。外部データは、スマート・コントラクトを取り巻く様々な状況において使用される可能性があり、スマート・コントラクトは、資産及び金融アプリケーション（例えば、金利）に関する市場価格フィードへのアクセスを必要とする証券（例えば、金利、デリバティブ、債券）で使用されるスマート・コントラクト；（例えば、遅延に対して当事者が保険をかけられるフライト情報、農作物保険のための価格インデックスの代わりに、気象データフィードを使用する金融デリバティブ契約の天候データのような）外部データへのアクセスを必要とするピア・ツー・ピア保険スマート・コントラクト；出荷に関するＧＰＳデータを必要とする取引スマート・コントラクト；乱数発生器へのアクセスを必要とするギャンブル・コントラクト等を含むがこれらに限定されない。

システムが外部データを受信した後、システムは、暗号で保護された通信セッションの一部として一群の通信が発生したことの第１証明を提供するために、データ・ソースに指示を提供する可能性があり、一群の通信は、システムが信頼されたデータ・ソースから外部データを受信していることを含む。システムは、第１証明を受信することが可能である（１１０８）。第１証明は、マークル・ツリーのハッシュ・ルートである通信のプルーフであってもよい。第１証明はディジタル署名であってもよく、ディジタル署名の真正は、信頼されるデータ・ソースに関連するパブリック鍵によって検証可能である。

実施形態では、システムは、演算回路Ｃへの入力ｘとしてデータを使用して証明を生成し（１１１０）、この回路は、１つ以上の出力ｙを生成するために２次プログラムを生成するために使用される。実施形態では、システム（例えば、プルーバー）は、入力ワイヤに割り当てられた値はｘのものであるように、回路ワイヤに対する値の割り当てである｛Ｃ，ｘ，ｙ｝に対する有効なトランスクリプトを、出力として取得する。また、システムは、演算回路に対する入力として使用されたデータが、信頼されるソースから得られたデータであったことの証明を生成することも可能である。証明は、図６及び７に関連するように、本開示の他の箇所で説明されるようなマークル・パスであってもよい。システムは、スマート・コントラクトの適正実行のプルーフをブロックチェーンにブロードキャストすることができる（１１１２）。システムは、第２証明（例えば、マークル・パス）、第１証明（即ち、通信のプルーフなどのようなデータ・ソースから受信される証明）、信頼されるエンティティに関連するパブリック鍵、又はそれらの何らかの組み合わせを送信することができる。

本開示の文脈において、プレ・イメージ耐性関数は一方向関数を含み、これは、現在の値を求めて計算することは計算上困難ではないかもしれないが、現在の値から前の値を決定するには計算上些細なことではない可能性がある関数を指すことに留意されたい。場合によっては、一方向メンバーシップ関数は、一方向として数学的に証明されてはおらず／証明可能ではないが、それにもかかわらず、関数をプレ・イメージ耐性にする計算が複雑な特性を有する。一方向関数（「有効一方向関数」とも呼ばれる）は：メッセージ認証コード（例えば、ハッシュ・ベースのメッセージ認証コード（ＨＭＡＣ））などの暗号ハッシュ関数、ＰＢＫＤＦ２やｂｃｒｙｐｔなどの鍵派生関数（例えば、パスワードが少なくとも部分的に平文と暗号鍵に基づいているもの）、及び、それらの範囲（可能な出力）よりも大きなドメイン（可能な入力の集合）を有する可能性があるが必ずしもそうではない他の安全なランダム関数を含むが、これらに限定されない。様々な実施形態に適した他の関数は：入力として少なくとも平文及び暗号鍵を受け入れる関数であって、入力をランダムに生成する確率が特定の閾値を下回るようなプレ・イメージ耐性の特性、第２種のプレ・イメージ耐性（入力ｘ１が与えられた場合に、ｆ（ｘ１）＝ｆ（ｘ２）であるような異なる入力ｘ２をランダムに生成する確率が特定の閾値を下回るもの）、及び／又は衝突耐性（例えば、同じ出力をもたらす２つの異なる入力の確率が、特定の閾値を下回るもの）を有する関数を含むが、これらに限定されない。

図１２は、本開示の少なくとも１つの実施形態を実施するために使用されることが可能なコンピューティング・デバイス１２００の例示的な簡略化されたブロック図である。様々な実施形態では、コンピューティング・デバイス１２００は、上記で説明された任意のシステムを実装するために使用されることが可能である。例えば、コンピューティング・デバイス１２００は、データ・サーバー、ウェブ・サーバー、ポータブル・コンピューティング・デバイス、パーソナル・コンピュータ、又は任意の電子コンピューティング・デバイスとして使用するように構成することができる。図１２に示されるように、コンピューティング・デバイス１２００は、実施形態において、バス・サブシステム１２０４を介して多数の周辺サブシステムと通信し、かつ動作可能に結合される１つ以上のプロセッサ１２０２を含むことが可能である。幾つかの実施形態では、これらの周辺サブシステムは、メモリ・サブシステム１２０８及びファイル／ディスク記憶サブシステム１２１０と、１つ以上のユーザー・インターフェース入力デバイス１２１２と、１つ以上のユーザー・インターフェース出力デバイス１２１４と、ネットワーク・インターフェース・サブシステム１２１６とを備える記憶サブシステム１２０６を含む。このような記憶サブシステム１２０６は、情報の一時的又は長期的な記憶のために使用することができる。

幾つかの実施形態では、バス・サブシステム１２０４は、コンピューティング・デバイス１２００の種々の構成要素及びサブシステムが、意図されるように互いに通信することを可能にするメカニズムを提供する。バス・サブシステム１２０４は、単一のバスとして概略的に示されているが、バス・サブシステムの代替の実施形態は、複数のバスを利用する。幾つかの実施形態では、ネットワーク・インターフェース・サブシステム１２１６は、他のコンピューティング・デバイス及びネットワークに対するインターフェースを提供する。ネットワーク・インターフェース・サブシステム１２１６は、幾つかの実施形態では、コンピューティング・デバイス１２００からデータを受信し、他のシステムへデータを送信するためのインターフェースとして機能する。幾つかの実施形態では、バス・サブシステム１２０４は、詳細、検索語などのデータを通信するために利用される。

幾つかの実施形態では、ユーザー・インターフェース入力デバイス１２１２は、キーボード；統合マウス、トラックボール、タッチパッド、又はグラフィックス・タブレットなどのポインティング・デバイス；スキャナ；バーコード・スキャナ；ディスプレイに組み込まれたタッチ・スクリーン；音声認識システム、マイクロ・フォンなどの音声入力デバイス、及びその他の種類の入力デバイスのような１つ以上のユーザー入力デバイス含む。一般に、用語「入力デバイス」の使用は、情報をコンピューティング・デバイス１２００に入力するためのあらゆる可能な種類のデバイス及びメカニズムを含むように意図されている。幾つかの実施形態では、１つ以上のユーザー・インターフェース出力デバイス１２１４は、表示サブシステム、プリンタ、又はオーディオ出力デバイスのような非視覚的ディスプレイなどを含む。幾つかの実施形態では、ディスプレイ・サブシステムは、陰極線管（ＣＲＴ）、液晶ディスプレイ（ＬＣＤ）のようなフラットパネル・デバイス、発光ダイオード（ＬＥＤ）ディスプレイ、又は投影その他の表示デバイスを含む。一般に、用語「出力デバイス」の使用は、コンピューティング・デバイス１２００から情報を出力するためのあらゆる可能な種類のデバイス及びメカニズムを含むように意図されている。１つ以上のユーザー・インターフェース出力デバイス１２１４は、例えばユーザー・インターフェースを提示し、説明されたプロセス及びそれらの変形を実行するアプリケーションとのユーザー相互作用を、そのような相互作用が適切である場合に促進するために使用されることが可能である。

幾つかの実施形態では、記憶サブシステム１２０６は、本開示の少なくとも１つの実施形態の機能を提供する基本プログラミング及びデータ構成を記憶するためのコンピュータ読み取り可能な記憶媒体を提供する。アプリケーション（プログラム、コード・モジュール、命令）は、幾つかの実施形態において１つ以上のプロセッサによって実行される場合に、本開示の１つ以上の実施形態の機能を提供し、実施形態では記憶サブシステム１２０６に記憶される。これらのアプリケーション・モジュール又は命令は、１つ以上のプロセッサ１２０２によって実行されることが可能である。様々な実施形態では、記憶サブシステム１２０６は、更に、本開示に従って使用されるデータを記憶するためのリポジトリを提供する。幾つかの実施形態では、記憶サブシステム１２０６は、メモリ・サブシステム１２０８及びファイル／ディスク記憶サブシステム１２１０を含む。

実施形態では、メモリ・サブシステム１２０８は、プログラム実行中に命令及びデータを記憶するためのメイン・ランダム・アクセス・メモリ（ＲＡＭ）１２１８、及び／又は固定命令が記憶されることが可能なリード・オンリー・メモリ（ＲＯＭ）１２２０などの多数のメモリを含む。幾つかの実施形態では、ファイル／ディスク記憶サブシステム１２１０は、プログラム及びデータ・ファイルのための非一時的な永続的な（不揮発性の）記憶装置を提供し、ハード・ディスク・ドライブ、関連するリムーバブル媒体を有するフロッピー・ディスク・ドライブ、コンパクト・ディスク・リード・オンリー・メモリ（ＣＤ－ＲＯＭ）ドライブ、光学ドライブ、リムーバブル・メディア・カートリッジ、又は他の同様の記憶媒体を含むことができる。

幾つかの実施形態では、コンピューティング・デバイス１２００は、少なくとも１つのローカル・クロック１２２４を含む。幾つかの実施形態では、ローカル・クロック１２２４は、特定の開始日から発生したティック数を表すカウンタであり、幾つかの実施形態では、コンピューティング・デバイス１２００内に一体的に配置される。様々な実施形態では、ローカル・クロック１２２４は、コンピューティング・デバイス１２００のためのプロセッサ及びそこに含まれるサブシステム内のデータ転送を、特定のクロック・パルスで同期させるために使用され、コンピューティング・デバイス１２００及びデータ・センター内の他のシステムとの間で同期した動作を調整するために使用されることが可能である。別の実施形態では、ローカル・クロックは、プログラム可能なインターバル・タイマである。

コンピューティング・デバイス１２００は、ポータブル・コンピュータ・デバイス、タブレット・コンピュータ、ワークステーション、又は以下に説明される他の任意のデバイスを含む、種々の任意の種類のものであるとすることが可能である。更に、コンピューティング・デバイス１２００は、幾つかの実施形態では、１つ以上のポート（例えば、ＵＳＢ、ヘッドフォン・ジャック、ライティング・コネクタなど）を介して、コンピューティング・デバイス１２００に接続されることが可能な他のデバイスを含むことが可能である。実施形態では、このようなデバイスは、光ファイバ・コネクタを受け入れるポートを含む。従って、幾つかの実施形態では、このデバイスは光信号を電気信号に変換するものであり、電気信号は、処理のために、デバイスを接続するポートを介してコンピューティング・デバイス１２００へ伝送される。コンピュータ及びネットワークの絶え間なく変化する性質に起因して、図１２に示されるコンピューティング・デバイス１２００の説明は、デバイスの好ましい実施形態を説明する目的のための特定の例としてしか意図されていない。図１２に示されるシステムより多くの又はより少ない構成要素を有する他の多くの構成も可能である。

上述の実施形態は、本発明を限定するものではなく、例示するものであること、及び当業者は、添付の特許請求の範囲によって定義される本発明の範囲から逸脱することなく、多くの代替的な実施形態を設計することが可能であることに留意されたい。特許請求の範囲において、括弧内に置かれる如何なる参照符号も、特許請求の範囲を限定するものとして解釈されないものとする。「備えている」及び「備える」等の言葉は、任意の請求項又は明細書全体において列挙されたもの以外の要素又はステップの存在を除外していない。本明細書において、「備える」は、「含む、又はから構成される」を意味し、「備えている」は「含んでいる、又はから構成されている」を意味する。要素の単独の参照は、そのような要素の複数の参照を除外するものではなく、その逆もまた同様である。本発明は、幾つかの個別的な要素を含むハードウェアによって、及び適切にプログラムされたコンピュータによって実装される可能性がある。幾つかの手段を列挙する装置の請求項において、これらの手段のうちの幾つかは、１つの同一のハードウェア項目によって具体化される可能性がある。特定の複数の事項が相互に異なる従属請求項に記載されているという単なるその事実は、これらの事項の組み合わせが有利に利用できないことを示すものではない。

Claims (15)

1. コンピュータで実行される方法であって：
   コンピューティング・エンティティとの暗号で保護された通信セッションを確立するステップ；
   ブロックチェーン・ネットワークに公開されているプログラムの実行をコントロールする入力データを含む第１のコミュニケーションを、前記暗号で保護された通信セッションで受信するステップ；
   一群のコミュニケーションが前記暗号で保護された通信セッションで生じたことの第１証明を受信するステップであって、前記一群のコミュニケーションは前記第１のコミュニケーションを含む、ステップ；
   前記データを利用して前記プログラムを実行するステップであって、前記プログラムの実行は、前記プログラムの適正実行のプルーフの生成をもたらす、ステップ；
   受信した前記入力データに少なくとも部分的に基づいて、前記入力データは前記第１のコミュニケーションに含まれていたことの第２証明を生成するステップ；及び
   前記プログラムの前記適正実行のプルーフを他のコンピュータ・システムに提供するステップ；
   を含み、前記第１証明及び前記第２証明は前記入力データが前記コンピューティング・エンティティから受信されたことを確認するために使用することが可能である、コンピュータで実行される方法。
2. 前記第１証明は、マークル・ツリーのルート・ノードに少なくとも部分的に基づく値を有し、前記マークル・ツリーは、前記一群のコミュニケーション及び一群のソルト値から決定される一群のリーフ・ノードを含む、請求項１に記載のコンピュータで実行される方法。
3. 前記一群のコミュニケーションの各コミュニケーションは、前記コミュニケーションが受信されたか又は送信されたかに基づいて決定される対応する中間ノードを含む、請求項２に記載のコンピュータで実行される方法。
4. 前記第１証明の値は、少なくとも前記一群のコミュニケーションの時間間隔及び前記マークル・ツリーのルート・ノードから決定される暗号ハッシュ出力に少なくとも部分的に更に基づいている、請求項２又は３に記載のコンピュータで実行される方法。
5. 前記第２証明は前記マークル・ツリーのマークル・パスに少なくとも部分的に基づいており、前記マークル・パスは前記マークル・ツリーの一群のノードの値を含み、前記一群のノードの値は前記マークル・ツリーの前記ルート・ノードの値を計算するのに十分である、請求項２～４のうちの何れか１項に記載のコンピュータで実行される方法。
6. 前記マークル・パスの前記一群のノードは、前記マークル・ツリーのリーフではなくルートでもない深さで厳密に１つのノードを含む、請求項５に記載のコンピュータで実行される方法。
7. 前記プログラムは２人以上の当事者により合意される一群のルールを含み、前記方法は、前記コンピューティング・エンティティを、前記２人以上の当事者のうちの少なくとも１人により信頼される１つ以上のコンピューティング・エンティティから選択するステップを更に含む、請求項１～６のうちの何れか１項に記載のコンピュータで実行される方法。
8. 第１ロッキング・スクリプトを含む第１トランザクション・アウトプットと、前記適正実行のプルーフは有効である旨の指示をエンコードする第２トランザクション・アウトプットとを含むブロックチェーン・トランザクションを検出するステップであって、前記第１トランザクション・アウトプットに関連する第１ディジタル資産はアンロッキング・スクリプトによりロック解除可能であり、アンロッキング・スクリプトは：
   前記コンピューティング・エンティティに関連するパブリック鍵；
   期待される値をエンコードするディジタル署名であって、前記ディジタル署名の真正はパブリック鍵を利用して暗号検証可能である、ディジタル署名；及び
   前記期待される値を生成するために使用可能な認証情報；
   をエンコードしている、ステップ；及び
   少なくとも前記パブリック鍵、前記ディジタル署名、及び前記認証情報を提供することにより、前記第１ディジタル資産をロック解除するステップ；
   を更に含む請求項１～７のうちの何れか１項に記載のコンピュータで実行される方法。
9. 前記ブロックチェーン・トランザクションは、更に：
   前記他のコンピュータ・システムに関連するプライベート鍵を利用してディジタル署名されたトランザクション・インプット；
   第２アンロッキング・スクリプトを含む第３トランザクション・アウトプットであって、前記第３トランザクション・アウトプットに関連する第２ディジタル資産は前記プライベート鍵を利用してロック解除可能である、第３トランザクション・アウトプット；
   を含み、前記第２トランザクション・アウトプットは、前記他のコンピュータ・システムに関連する識別子を更にエンコードしている、請求項８に記載のコンピュータで実行される方法。
10. 前記認証情報はマークル・ツリーのマークル・パスを含み、前記期待される値は前記マークル・ツリーのルート・ノードに少なくとも部分的に基づいている、請求項８又は９に記載のコンピュータで実行される方法。
11. 前記データはイベントが生じたか否かを示すバイナリ・データを含む、請求項１～１０のうちの何れか１項に記載のコンピュータで実行される方法。
12. 前記データは、前記ブロックチェーンにおける他のデータに基づいて検証することはできない情報を含むデータである、請求項１～１１のうちの何れか１項に記載のコンピュータで実行される方法。
13. 前記第１証明はディジタル署名であり、前記ディジタル署名の真正は前記コンピューティング・エンティティに関連する暗号パブリック鍵を利用して検証可能である、請求項１～１２のうちの何れか１項に記載のコンピュータで実行される方法。
14. プロセッサ；及び
    実行可能な命令を含むメモリ；
    を備えるシステムであって、前記命令は、前記プロセッサにより実行された結果として、請求項１～１３のうちの何れか１項に記載のコンピュータで実行される方法を前記システムに実行させる、システム。
15. 実行可能な命令を格納した非一時的なコンピュータ読み取り可能な記憶媒体であって、前記命令は、コンピュータ・システムのプロセッサにより実行された結果として、請求項１～１３のうちの何れか１項に記載のコンピュータで実行される方法を前記コンピュータ・システムに少なくとも実行させる、記憶媒体。

Images