IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ エヌチェーン ホールディングス リミテッドの特許一覧

特許7587636プルーフ検証に基づいてオフ・チェーン・データを認証するシステム及び方法
<>
  • 特許-プルーフ検証に基づいてオフ・チェーン・データを認証するシステム及び方法 図1
  • 特許-プルーフ検証に基づいてオフ・チェーン・データを認証するシステム及び方法 図2
  • 特許-プルーフ検証に基づいてオフ・チェーン・データを認証するシステム及び方法 図3
  • 特許-プルーフ検証に基づいてオフ・チェーン・データを認証するシステム及び方法 図4
  • 特許-プルーフ検証に基づいてオフ・チェーン・データを認証するシステム及び方法 図5
  • 特許-プルーフ検証に基づいてオフ・チェーン・データを認証するシステム及び方法 図6
  • 特許-プルーフ検証に基づいてオフ・チェーン・データを認証するシステム及び方法 図7
  • 特許-プルーフ検証に基づいてオフ・チェーン・データを認証するシステム及び方法 図8
  • 特許-プルーフ検証に基づいてオフ・チェーン・データを認証するシステム及び方法 図9
  • 特許-プルーフ検証に基づいてオフ・チェーン・データを認証するシステム及び方法 図10
  • 特許-プルーフ検証に基づいてオフ・チェーン・データを認証するシステム及び方法 図11
  • 特許-プルーフ検証に基づいてオフ・チェーン・データを認証するシステム及び方法 図12
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2024-11-12
(45)【発行日】2024-11-20
(54)【発明の名称】プルーフ検証に基づいてオフ・チェーン・データを認証するシステム及び方法
(51)【国際特許分類】
   H04L 9/32 20060101AFI20241113BHJP
【FI】
H04L9/32 200B
【請求項の数】 12
【外国語出願】
(21)【出願番号】P 2023084283
(22)【出願日】2023-05-23
(62)【分割の表示】P 2020531098の分割
【原出願日】2018-12-12
(65)【公開番号】P2023106528
(43)【公開日】2023-08-01
【審査請求日】2023-05-23
(31)【優先権主張番号】1720946.1
(32)【優先日】2017-12-15
(33)【優先権主張国・地域又は機関】GB
(73)【特許権者】
【識別番号】318001991
【氏名又は名称】エヌチェーン ライセンシング アーゲー
(74)【代理人】
【識別番号】100107766
【弁理士】
【氏名又は名称】伊東 忠重
(74)【代理人】
【識別番号】100070150
【弁理士】
【氏名又は名称】伊東 忠彦
(74)【代理人】
【識別番号】100135079
【弁理士】
【氏名又は名称】宮崎 修
(72)【発明者】
【氏名】コヴァチ,アレグザンドラ
(72)【発明者】
【氏名】マデオ,シモーネ
(72)【発明者】
【氏名】モティリンスキ,パトリック
(72)【発明者】
【氏名】ヴィンセント,ステファヌ
【審査官】中里 裕正
(56)【参考文献】
【文献】国際公開第2016/155804(WO,A1)
【文献】国際公開第2017/008829(WO,A1)
【文献】国際公開第2017/187396(WO,A1)
【文献】国際公開第2017/187398(WO,A1)
【文献】国際公開第2017/187399(WO,A1)
【文献】KUMARESAN, R. and BENTOV, I.,How to Use Bitcoin to Incentivize Correct Computations,CCS '14: Proceedings of the 2014 ACM SIGSAC Conference on Computer and Communications Security,2014年11月,pp.30-41
【文献】SHOKER, A.,Sustainable Blockchain through Proof of eXercise,2017 IEEE 16th International Symposium on Network Computing and Applications (NCA),2017年11月01日,pp.1-9
【文献】BALL, M. et al.,Proof of Useful Work,Cryptology ePrint Archive,Paper 2017/203 ver.20170301:001609,[online],2017年03月01日,pp.1-27,https://eprint.iacr.org/2017/203/20170301:001609,[2022年12月06日検索]
【文献】RITZDORF, H. et al.,TLS-N: Non-repudiation over TLS Enabling Ubiquitous Content Signing for Disintermediation,Cryptology ePrint Archive,Paper 2017/578,[online],2017年06月20日,pp.1-16,https://eprint.iacr.org/2017/578,[2022年12月06日検索]
(58)【調査した分野】(Int.Cl.,DB名)
H04L 9/32
JSTPlus/JMEDPlus/JST7580(JDreamIII)
IEEE Xplore
(57)【特許請求の範囲】
【請求項1】
コンピュータで実行される方法であって:
プルーバー・コンピュータ・システムにおいて、
コンピューティング・エンティティとの暗号で保護された通信セッションを確立するステップ;
ブロックチェーン・ネットワークに公開されているプログラムの実行をコントロールする入力データを含む第1のコミュニケーションを、前記暗号で保護された通信セッションで受信するステップ;
一群のコミュニケーションが前記暗号で保護された通信セッションで生じたことの第1証明を受信するステップであって、前記一群のコミュニケーションは前記第1のコミュニケーションを含む、ステップ;
前記入力データを用いて前記プログラムを実行するステップであって、前記プログラムの実行は、前記プログラムの適正実行のプルーフの生成をもたらす、ステップ;
受信した入力データに少なくとも部分的に基づいて、前記入力データは前記第1のコミュニケーションに含まれていたことの第2証明を生成するステップ;及び
前記ブロックチェーン・ネットワークにおいてマイニングされる、前記プログラムの適正実行のプルーフを他のコンピュータ・システムに提供するステップ;及び
記第1証明及び前記第2証明をクライアント・コンピュータ・システムに提供するステップ;
を実行すること;及び
前記クライアント・コンピュータ・システムにおいて、
前記適正実行のプルーフを生成するために使用される前記入力データは、前記コンピューティング・エンティティから受信されたことを、前記第1証明及び前記第2証明を用いて検証するステップ;及び
前記ブロックチェーン・ネットワークにおいてマイニングされる評判トランザクションを生成するステップであって、前記評判トランザクションは、前記プルーバー・コンピュータ・システムが、前記プログラムを実行するために、前記コンピューティング・エンティティから受信した前記入力データを使用したことのレコードである、ステップ;
を実行することを含む、コンピュータで実行される方法。
【請求項2】
前記第1証明は、マークル・ツリーのルート・ノードに少なくとも部分的に基づく値を有し、前記マークル・ツリーは、前記一群のコミュニケーション及び一群のソルト値から決定される一群のリーフ・ノードを含む、請求項1に記載のコンピュータで実行される方法。
【請求項3】
前記一群のコミュニケーションの各コミュニケーションは、前記コミュニケーションが受信されたか又は送信されたかに基づいて決定される対応する中間ノードを含む、請求項2に記載のコンピュータで実行される方法。
【請求項4】
前記第1証明の値は、少なくとも前記一群のコミュニケーションの時間間隔及び前記マークル・ツリーのルート・ノードから生成される暗号ハッシュ出力に少なくとも部分的に更に基づいている、請求項2又は3に記載のコンピュータで実行される方法。
【請求項5】
前記第2証明は前記マークル・ツリーのマークル・パスに少なくとも部分的に基づいており、前記マークル・パスは前記マークル・ツリーの一群のノードの値を含み、前記一群のノードの値は前記マークル・ツリーの前記ルート・ノードの値を計算するのに十分である、請求項2~4のうちの何れか1項に記載のコンピュータで実行される方法。
【請求項6】
前記マークル・パスの前記一群のノードは、前記マークル・ツリーのそれぞれのリーフではなくルートでもない深さで厳密に1つのノードを含む、請求項5に記載のコンピュータで実行される方法。
【請求項7】
前記プログラムは2人以上の当事者により合意される一群のルールを含み、前記方法は、前記コンピューティング・エンティティを、前記2人以上の当事者のうちの少なくとも1人により信頼される1つ以上のコンピューティング・エンティティから選択するステップを更に含む、請求項1~6のうちの何れか1項に記載のコンピュータで実行される方法。
【請求項8】
前記データはイベントが生じたか否かを示すバイナリ・データを含む、請求項1~7のうちの何れか1項に記載のコンピュータで実行される方法。
【請求項9】
前記データは、前記ブロックチェーンにおける他のデータに基づいて検証することはできない情報を含むデータである、請求項1~8のうちの何れか1項に記載のコンピュータで実行される方法。
【請求項10】
前記第1証明はディジタル署名であり、前記ディジタル署名の真正は前記コンピューティング・エンティティに関連する暗号パブリック鍵を利用して検証可能である、請求項1~9のうちの何れか1項に記載のコンピュータで実行される方法。
【請求項11】
プロセッサ;及び
実行可能な命令を含むメモリ;
を備えるシステムであって、前記命令は、前記プロセッサにより実行された結果として、請求項1~10のうちの何れか1項に記載のコンピュータで実行される方法を前記システムに実行させる、システム。
【請求項12】
実行可能な命令を格納した非一時的なコンピュータ読み取り可能な記憶媒体であって、前記命令は、コンピュータ・システムのプロセッサにより実行された結果として、請求項1~10のうちの何れか1項に記載のコンピュータで実行される方法を前記コンピュータ・システムに少なくとも実行させる、記憶媒体。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は概してブロックチェーン技術に関連し、特にビットコイン・スクリプトで検証することが可能なプルーフ・オブ・カンバセーションを生成すること、更にリコースの場合にも利用することが可能な情報も提供することに関連する。所定のコミュニケーションがカンバセーション中に起こったことの証明は、マークル・ツリーを利用する可能性がある。カンバセーション又はコミュニケーションのデータは、プログラム又はスクリプトを正しく実行するための入力として使用される可能性がある。本発明は、スマート・コントラクトの生成及び実行における利用に特に適しているが、これらに限定されない。
【背景技術】
【0002】
この文献において、用語「ブロックチェーン」は何種類もの電子的なコンピュータ・ベースの分散された台帳のうちの何れを指してもよい。これらはコンセンサス・ベースのブロックチェーン及びトランザクション・チェーン技術、許可型及び非許可型の台帳、共有台帳、及びそれらの変形を含む。ブロックチェーン技術の最も広く知られたアプリケーションはビットコイン台帳であるが、他のブロックチェーン実装も提案され開発されている。便宜上及び説明の目的のために、本願で説明される技術の有用なアプリケーションとしてビットコインが言及されるかもしれないが、ビットコインは、本開示で説明される技術が適用され得る多数のアプリケーションのうちのほんの1つに過ぎない。しかしながら、本発明はビットコイン・ブロックチェーンで使用することに限定されず、非商用アプリケーションを含む代替的なブロックチェーン実装及びプロトコルもまた、本発明の範囲に属することに留意すべきである。例えば、本開示の中で説明される技術は、ブロックチェーンにとって外部のデータを当てにする可能性があるブロックチェーン・ネットワークに公表されているプログラム又はスクリプトの実行に関して、ビットコインと同様な制限を有する他のブロックチェーン実装を利用することにも恩恵を提供するであろう。
【0003】
ブロックチェーンは、ピア・ツー・ピアの電子台帳を指す可能性があり、ブロックで構成されるコンピュータ・ベースの非セントラル化された分散システムとして実装され、ブロックはトランザクション及び他の情報で構成される可能性がある。幾つかの例において、「ブロックチェーン・トランザクション」はデータ及び条件一式を含むフィールド値の構造化された集まりをエンコードする入力メッセージを示し、条件一式の充足は、フィールドのセットに関し、ブロックチェーン・データ構造に書き込まれるために事前に必要なことである。例えば、ビットコインの場合、各々のトランザクションは、ブロックチェーン・システムの参加者間でのディジタル資産のコントロールの移転をエンコードするデータ構造であり、少なくとも1つの入力(インプット)と少なくとも1つの出力(アウトプット)とを含む。幾つかの実施形態において、「ディジタル資産」は、使用する権利に関連付けられるバイナリ・データを指す。ディジタル資産の具体例はビットコイン、イーサ(ether)、及びライトコインを含む。本願において使用される用語「ビットコイン」は、ビットコイン・プロトコルの変形である任意のプロトコルを含むように使用される。幾つかの実装において、ディジタル資産のコントロールを移転することは、ディジタル資産の少なくとも一部を第1エンティティから第2エンティティへ関連付け直すことにより実行されることが可能である。ブロックチェーンの各ブロックは先行するブロックのハッシュを含み、ブロックは先行するブロックと共にチェーン状になり、その発端以来ブロックチェーンに書き込まれてきた全てのトランザクションの永続的な変更できない記録を作る。
【0004】
幾つかの例において、「スタック・ベース・スクリプト言語」は、様々なスタック・ベース又はスタック指向の実行モデル又はオペレーションをサポートするプログラミング言語を指す。即ち、スタック・ベース・スクリプト言語はスタックを利用することができる。スタックでは、値がスタックのトップにプッシュされるか、又はスタックのトップからポップされる(取り出される)ことが可能である。スタックを操作するために実行される様々なオペレーションは、スタックのトップへ又はトップから、1つ以上の値をプッシュ又はポップする結果となる可能性がある。例えば、OP_EQUALオペレーションは、スタックから上位2つのアイテムを取り出し、それらを比較し、結果(例えば、等しければ1、あるいは等しくなければ0)をスタックのトップにプッシュする。OP_PICKのようなスタックに対して実行される他のオペレーションは、スタックのトップ以外の場所からアイテムが選択されることを許容することが可能である。幾つかの本願実施形態で使用される幾つかのスクリプト言語では、メイン・スタック及びオルタネート・スタックという少なくとも2つのスタックが存在する可能性がある。スクリプト言語の幾つかのオペレーションは、あるスタックのトップから別のスタックのトップへアイテムを移動させることが可能である。例えば、OP_TOALTSTACKは、メイン・スタックのトップからオルタネート・スタックのトップへ値を移動させる。スタック・ベースのスクリプト言語は、場合によっては、厳密に後入れ先出し(LIFO)方式でオペレーションのみに限定されない可能性があることに留意すべきである。例えば、スタック・ベースのスクリプト言語は、スタック内のn番目のアイテムをトップにコピー又は移動するオペレーションをサポートしている可能性がある(例えばビットコインではそれぞれOP_PICK及びOP_ROLLである)。スタック・ベースのスクリプト言語で書かれるスクリプトは、ベクトル、リスト、又はスタック等の適切な任意のデータ構造を利用して実装されることが可能な論理スタックにプッシュされる可能性がある。
【0005】
ブロックチェーンに書き込まれるトランザクションのために、「有効性が検証」されなければならない。ネットワーク・ノード(マイニング・ノード)は、各々のトランザクションが有効であることを保証するための作業を実行し、有効でないトランザクションはネットワークから拒否される。ノードは、他のノードと異なる有効性に関する基準を有することが可能である。ブロックチェーンにおける有効性はコンセンサス・ベースであるので、トランザクションは、そのトランザクションが有効であることに過半数のノードが合意する場合に有効であるとみなされる。ノードにインストールされているソフトウェア・クライアントは、部分的に未使用トランザクション・アウトプット(UTXO)を参照するトランザクションに関するこの検証作業を、UTXOロッキング及びアンロッキング・スクリプトを実行することによって実行する。ロッキング及びアンロッキング・スクリプトの実行がTRUEと評価する場合、及び適用可能であるならば他の検証条件が充足される場合に、トランザクションはノードによって有効性が検証される。検証されたトランザクションは他のネットワーク・ノードへ伝搬され、マイニング・ノードはブロックチェーンにトランザクションを含めることを選択することができる。従って、トランザクションがブロックチェーンに書き込まれるためには、i)トランザクションを受信する第1ノードにより検証され---トランザクションが有効であると検証されると、ノードはそれをネットワーク内の他のノードへ中継し;ii)マイニング・ノードにより構築される新たなブロックに追加され;iii)マイニングされる、即ち過去のトランザクションの公の台帳に追加されなければならない。トランザクションを事実上撤回できなくする程度に十分な数のブロックがブロックチェーンに追加された場合に、トランザクションは承認されたものとみなされる。
【0006】
ブロックチェーン技術は、暗号通貨実装の用途に最も広く知られているが、ディジタル起業家は、新しいシステムを実装するために、ビットコインが基礎としている暗号セキュリティ・システムと、ブロックチェーンに格納されることが可能なデータとの両方の活用を検討し始めている。ブロックチェーンが、暗号通貨の領域に限定されない自動化されたタスク及びプロセスに使用されることが可能であるならば、非常に有利であろう。このようなソリューションは、ブロックチェーンの利点(例えば、イベントの永続的な改ざん防止記録、分散処理など)を利用する一方、それらのアプリケーションでの多様性を豊富にすることができるであろう。
【0007】
本開示は、1つ以上のブロックチェーン・ベースのコンピュータ・プログラムの技術的側面を開示する。ブロックチェーン・ベースのコンピュータ・プログラムは、ブロックチェーン・トランザクションに記録された機械読み取り可能で実行可能なプログラムであってもよい。ブロックチェーン・ベースのコンピュータ・プログラムは、結果を生成するために入力を処理することが可能であり、次いで、それらの結果に依存してアクションが実行されることを引き起こすことが可能なルールを含む可能性がある。現在の研究の1つの分野は、「スマート・コントラクト」の実現のためのブロックチェーン・ベースのコンピュータ・プログラムの使用である。自然言語で書かれる伝統的な契約とは異なり、スマート・コントラクトは、機械読み取り可能な契約又は合意の条項の実行を自動化するように設計されたコンピュータ・プログラムである可能性がある。
【0008】
ブロックチェーン関連のもう別の関心領域は、ブロックチェーンにより現実世界のエンティティを表現して移転するための「トークン」(又は「カラード・コイン」)の使用である。潜在的に機密又は秘密のアイテムは、認識可能な意味又は値を有しないトークンによって表すことができる。従って、トークンは、現実世界のアイテムがブロックチェーンから参照されることを可能にする識別子として機能する。
【0009】
実施形態において、特定のエンティティとのやり取りは、スマート・コントラクトの特定のステップでエンコードされることが可能であるが、スマート・コントラクトは別の方法で自動的に実行され、自己強制されることが可能である。これは機械読み取り可能で実行可能である。幾つかの例では、自動実行は、UTXOの移転を可能にするために成功裏に実行されるスマート・コントラクトの実行を指す。なお、このような例では、UTXOの移転を引き起こすことが可能な「エンティティ」は、何らかの秘密情報を証明するように要求されることなく、アンロッキング・スクリプトを作成することが可能なエンティティを指すことに留意されたい。言い換えれば、アンロッキング・トランザクションは、データのソース(例えば、アンロッキング・トランザクションを作成したエンティティ)が暗号シークレット(例えば、プライベート非対称鍵、対称鍵など)に対するアクセスを有することを検証することなく、有効性を検証することが可能である。また、このような例では、自己強制(self-enforcement)は、ブロックチェーン・ネットワークの検証ノードが、制約に従ってアンロッキング・トランザクションを実施させられることを指す。幾つかの例では、UTXOを「アンロッキング」することは、UTXOを参照し、有効として実行するアンロッキング・トランザクションを作成することを指す。
【0010】
ブロックチェーン・トランザクション出力は、ロッキング・スクリプトと、ビットコインのようなディジタル資産の所有権に関する情報とを含む。エンカンブランス(an encumbrance)として言及される可能性もあるロッキング・スクリプトは、UTXOを移転するために満足するように求められる条件を指定することによって、ディジタル資産を「ロック」する。例えば、ロッキング・スクリプトは、関連するディジタル資産をアンロックするために所定のデータがアンロッキング・スクリプトで提供されることを要求することが可能である。ロッキング・スクリプトはビットコインでは「scriptPubKey」としても知られている。ディジタル資産をアンロックするためにデータを提供することを当事者に要求する技術は、ロッキング・スクリプト内にデータのハッシュを埋め込むことを含む。
【0011】
本発明はゼロ・ナレッジ・プルーフ(zero-knowledge proofs)を利用することが可能なブロックチェーンでスマート・コントラクトを実行するためのシステム及び方法として説明されることが可能である。スマート・コントラクトの実行は、トランザクション検証の一部として行われることが可能である。スマート・コントラクトの実行の一部として、現実世界の状態及びイベントに関するデータのような、ブロックチェーン外部のデータ(例えば、オフ・チェーン・データ)へのアクセスを得ることが望ましいかもしれない。本願で説明される技術は、データ・ソースによって提供されるデータが認証され、ブロックチェーン・ネットワークに公開されるスマート・コントラクトのようなプログラム又はスクリプトの実行に利用される場合に利用される可能性がある。ディジタル資産は、幾つかの実施形態において、暗号通貨として使用される可能性があるが、実施形態において、ディジタル資産は、他の状況で追加的又は代替的に使用可能であることが想定されている。本発明は、ディジタル資産のコントロールに適用可能であるが、その性質上、技術的なものであり、ディジタル資産の移転に必ずしも関わらないブロックチェーン・データ構造を利用する他の状況で使用されることが可能であることに留意されたい。
【発明の概要】
【0012】
従って、これらの側面の1つ以上においてブロックチェーン技術を改善する方法及びシステムを提供することが望ましい。そのような改善されたソリューションは今では考案されている。即ち、本発明によれば、添付の特許請求の範囲に規定される方法が提供される。
【0013】
そのような改善されたソリューションは今では考案されている。
【0014】
即ち、本発明によれば、添付の特許請求の範囲に規定されるシステム及び方法が提供される。
【0015】
本発明によれば、ブロックチェーンのノードのためにコンピュータで実行される方法を提供することが可能であり、コンピュータで実行される方法は:
コンピューティング・エンティティとの暗号で保護された通信セッションを確立するステップ;
ブロックチェーン・ネットワークに公開されているプログラムの実行をコントロールする入力データを含むコミュニケーションを、暗号で保護された通信セッションで受信するステップ;
データを含む一群のコミュニケーションが暗号で保護された通信セッションで生じたことの第1証明を受信するステップ;
受信した入力データに少なくとも部分的に基づいて、プログラムの適正実行の
プルーフと、データがデータ・ソースから受信されたことの第2証明とを生成するステップ;
プログラムの適正実行のプルーフを他のコンピュータ・システムに提供するステップを含む。
【0016】
追加的又は代替的に本発明は以下のステップを含むように説明されることが可能であり、そのステップは:
コンピューティング・エンティティとの暗号で保護された通信セッションを確立するステップ;
ブロックチェーン・ネットワークに公開されているプログラムの実行をコントロールする入力データを含むコミュニケーションを、暗号で保護された通信セッションで受信するステップ;
データを含む一群のコミュニケーションが暗号で保護された通信セッションで生じたことの第1証明を受信するステップ;
受信した入力データに少なくとも部分的に基づいて、プログラムの適正実行のプルーフと、データがデータ・ソースから受信されたことの第2証明とを生成するステップ;及び
プログラムの適正実行のプルーフを他のコンピュータ・システムに提供するステップである。
【0017】
第1証明は、マークル・ツリーのルート・ノードに少なくとも部分的に基づく値を有する可能性があり、マークル・ツリーは、一群のコミュニケーション及び一群のソルト値から決定される一群のリーフ・ノードを含む。
【0018】
一群のコミュニケーションのうちのコミュニケーションは、コミュニケーションが受信されたか又は送信されたかに基づいて決定される対応する中間ノードを含む可能性がある。場合によっては、一群のコミュニケーションのうちの各コミュニケーションが、そのような対応する中間ノードを含む。
【0019】
第1証明の値は、少なくともマークル・ツリーのルート・ノードから生成される暗号ハッシュ出力と、一群のコミュニケーションの時間間隔とに少なくとも部分的に基づく。暗号ハッシュ出力の生成に適した暗号ハッシュ・アルゴリズムの具体例は、SHA-256暗号ハッシュ・アルゴリズムである。
【0020】
第2証明は、マークル・ツリーのマークル・パス、マークル・ツリーのノードの集合の値を含むマークル・パス、マークル・ツリーのルート・ノードの値を計算するのに十分なノードの集合の値に少なくとも部分的に基づいていてもよい。
【0021】
好ましくは、マークル・パスのノードの集合は、マークル・ツリーのリーフではなくルートでもない深度各々において、せいぜい1つのノードを含む。場合によっては、マークル・パスは、マークル・ツリーのリーフではなくルートでもない深度各々において、厳密に1つのノードを含む。
【0022】
プログラムは、2人以上の当事者によって合意される一組のルールを含む可能性があり、本方法は、2人当事者のうちの少なくとも1人によって信頼される1つ以上のコンピューティング・エンティティとの暗号で保護された通信を確立するために、コンピューティング・エンティティを選択するステップを含む可能性がある。
【0023】
好ましくは、本方法は、
第1トランザクション・アウトプットと第2トランザクション・アウトプットとを含むブロックチェーン・トランザクションを検出するステップであって、第1トランザクション・アウトプットは第1ロッキング・スクリプトを含み、第1トランザクション・アウトプットに関連する第1ディジタル資産は、アンロッキング・スクリプトによりロック解除され、アンロッキング・スクリプトは:
コンピューティング・エンティティに関連するパブリック鍵と、
期待される値をエンコードするディジタル署名であって、ディジタル署名の真正はパブリック鍵を使用して暗号検証可能であり、期待される値を生成するために認証情報が使用可能である、ディジタル署名とをエンコードしており、
第2トランザクション・アウトプットは適正実行のプルーフの指示をエンコードしている、ステップ;及び、
少なくともパブリック鍵、ディジタル署名、及び認証情報を提供することによって、第1ディジタル資産のロックを解除するステップを含む可能性がある。
【0024】
ブロックチェーン・トランザクションは、更に、
他のコンピュータ・システムに関連付けられたプライベート鍵を使用してディジタル署名されたトランザクション・インプット;
第2アンロッキング・スクリプトを含む第3トランザクション・アウトプットであって、第3トランザクション・アウトプットに関連付けられる第2ディジタル資産は、プライベート鍵を使用してロック解除可能である、第3トランザクション・アウトプット;
を含む可能性があり、第2トランザクション・アウトプットは、他のコンピュータ・システムに関連付けられた識別子を更にエンコードしている。
【0025】
好ましくは、認証情報は、マークル・ツリーのマークル・パスを含み、期待される値は、マークル・ツリーのルート・ノードに少なくとも部分的に基づいている。
【0026】
データは、イベントが発生したか否かを示すバイナリ・データを含んでもよい。
【0027】
データは、ブロックチェーン上の他のデータに基づいて真正が検証可能でない情報を含むデータであってもよい。
【0028】
好ましくは、第1証明はディジタル署名であり、ディジタル署名の真正は、コンピューティング・エンティティに関連する暗号パブリック鍵を使用して検証可能である。
【0029】
また、プロセッサと、実行可能な命令を含むメモリとを備えるシステムを提供することも望ましく、命令は、プロセッサによる実行の結果として、保護が請求される何れかの方法をシステムに実行させる。
【0030】
また、実行可能な命令を格納した非一時的なコンピュータ読み取り可能な記憶媒体を提供することも望ましく、命令は、コンピュータ・システムの1つ以上のプロセッサによる実行の結果として、保護が請求される何れかの方法をコンピュータ・システムに少なくとも実行させる。
【0031】
追加的又は代替的に、本発明は改良されたブロックチェーン・プログラミング・ツール又は支援手段を提供することが可能である。これは、分散された検証可能な計算を促進又は可能にする、改善された効率的で最適化された構成を提供する可能性がある。
【図面の簡単な説明】
【0032】
本発明のこれら及び他の態様は、本願で説明される実施形態から明らかであり、それを参照して解明されるであろう。ここで本発明の実施形態は単なる例示として添付図面を参照して説明される。
【0033】
図1】様々な実施形態が実装されることが可能なブロックチェーン環境を示す。
【0034】
図2】様々な実施形態に従ってプロトコルを実装するために利用されてもよいコンピューティング環境を示す。
【0035】
図3】検証可能な計算の実行に適した環境の図を示す。
【0036】
図4】プログラム又はスクリプトの実行に関連してデータ・ソースから取得されるデータを証明者が利用する環境の例示的な図を示す。
【0037】
図5】プログラム又はスクリプトの実行に利用されるデータ・ソースからデータを取得するためのプロトコルを示す図である。
【0038】
図6】実施形態によるマークル・ツリーの図を示す。
【0039】
図7】実施形態によるマークル・パスの図を示す。
【0040】
図8】種々の実施形態に関連して利用されるプルーフを生成及び検証するプロトコルの図を示す。
【0041】
図9】実施形態による評判トランザクションの図を示す。
【0042】
図10】通信のプルーフを生成するプロセスの説明図である。
【0043】
図11】認証されたデータを利用してプログラム又はスクリプトを実行するプロセスの説明図である。
【0044】
図12】本開示の少なくとも1つの実施形態を実施するために使用されることが可能なコンピューティング・デバイスを示す。
【発明を実施するための形態】
【0045】
先ず、本開示の実施形態によるブロックチェーンに関連する例示的なブロックチェーン・ネットワーク100を示す図1を参照する。実施形態では、例示的なブロックチェーン・ネットワーク100は、ピア・ツー・ピア分散電子デバイスとして実装されるブロックチェーン・ノードを含み、各ノードは、ノード102のオペレータ間で少なくとも部分的に合意されたブロックチェーン・プロトコルに従うオペレーションを実行するソフトウェア及び/又はハードウェアのインスタンスを実行する。幾つかの例において、「ノード」は、ブロックチェーン・ネットワーク間で分散されたピア・ツー・ピア電子デバイスを指す。ブロックチェーン・プロトコルの一例はビットコイン・プロトコルである。
【0046】
幾つかの実施形態では、ノード102は、任意の適切なコンピューティング・デバイスにより構成されることが可能である(例えば、データ・センターにおけるサーバー、クライアント・コンピューティング・デバイス(例えば、デスクトップ・コンピュータ、ラップトップ・コンピュータ、タブレット・コンピュータ、スマートフォンなど)、コンピューティング・リソース・サービス・プロバイダの分散システムにおける複数のコンピューティング・デバイス、又は図8のコンピューティング・デバイス800のような任意の適切な電子クライアント・デバイスにより構成されることが可能である)。幾つかの実施形態では、ノード102は、トランザクション104のような提案されたトランザクションを表すデータメッセージ又はオブジェクトを受信するための入力を有する。幾つかの実施形態では、ノードは、ノードが保持する情報(例えば、トランザクション104の状態の情報)に対してクエリ可能(queryable)である。
【0047】
図1に示すように、幾つかのノード102は、1つ以上の他のノード102に通信的に結合される。このような通信接続は、1つ以上の有線又は無線通信を含むことが可能である。実施形態では、ノード102はそれぞれ、ブロックチェーン内の全てのトランザクションの「台帳(ledger)」の少なくとも一部を維持する。このようにして、台帳は分散された台帳となる。台帳に影響を与えるノードによって処理されるトランザクションは、台帳の完全性が維持されるように、1つ以上の他のノードによって検証可能である。
【0048】
どのノード102が他のどのノードと通信することができるかに関しては、メッセージは転送されるべきであるとブロックチェーン・プロトコルが示すものであると仮定して、例示的なブロックチェーン・ネットワーク100の各ノードが、1つ以上の他のノード102と通信できることで十分であるとすることが可能であり、その結果、ノード間で受け渡されるメッセージは例示的なブロックチェーン・ネットワーク100全体(又はそのうちのかなりの部分)に伝達される。そのようなメッセージの1つは、ノード102Aのような1つのノード102による提案されたトランザクションの公表であってもよく、これはパス106のようなパスに沿って伝搬する。そのような他のメッセージは、ブロックチェーンに含めるために提案された新しいブロックの公表であってもよい。
【0049】
実施形態では、ノード102のうちの少なくとも一部は、暗号問題を解くことのような複雑な計算を実行するマイナー・ノードである。暗号問題を解くマイナー・ノードは、ブロックチェーンのための新しいブロックを作成し、その新しいブロックを他のノード102にブロードキャストする。他のノード102は、マイナー・ノードの作業を検証し、検証に基づいて、そのブロックを(例えば、ブロックチェーンの分散台帳に追加することによって)ブロックチェーンに受け入れる。幾つかの例では、ブロックはトランザクションのグループであり、前のブロックの「フィンガープリント」(例えばハッシュ)とタイムスタンプとでマークされることが多い。このようにして、各ブロックは前のブロックにリンクされることが可能であり、それによりブロックチェーンのブロックをリンクする「チェーン」が生成される。実施形態において、有効なブロックは、ノード102のコンセンサスによってブロックチェーンに追加される。また、幾つかの例では、ブロックチェーンは、検証されたブロックのリストを含む。
【0050】
一実施形態では、ノード102のうちの少なくとも一部は、本開示で説明されるように、トランザクションを検証する検証ノードとして動作する。幾つかの例では、トランザクションは、ディジタル資産(例えば、幾らかのビットコイン)の所有権の証拠(プルーフ)と、ディジタル資産の所有権/支配権(オーナーシップ/コントロール)を受け入れる又は移転するための条件とを提供するデータを含む。幾つかの例において、「アンロッキング・トランザクション」とは、先行するUTXOにより指定されるディジタル資産の少なくとも一部を、ブロックチェーン・アドレスに関連付けられたエンティティに関連付け直す(例えば、所有権又は支配権を移転する)ブロックチェーン・トランザクションを指す。幾つかの例において、「先行するトランザクション」とは、アンロッキング・トランザクションによって参照されるUTXOを含むブロックチェーン・トランザクションを指す。幾つかの実施形態では、トランザクションは、所有権又は支配権が移転される(ロック解除される)前に満たされなければならない条件でトランザクションを制限する「ロックキング・スクリプト」を含む。
【0051】
幾つかの実施形態では、ブロックチェーン・アドレスは、少なくとも一部のディジタル資産の支配権が移転/再関連付けされつつあるエンティティに関連する英数字の文字列である。幾つかの実施形態で実装される幾つかのブロックチェーン・プロトコルでは、エンティティに関連するパブリック鍵とブロックチェーン・アドレスとの間に1対1の対応がある。幾つかの実施形態では、トランザクションの検証は、ロッキング・スクリプト及び/又はアンロッキング・スクリプトで指定された1つ以上の条件を検証することを含む。トランザクション104の検証に成功すると、検証ノードはトランザクション104をブロックチェーンに追加し、それをノード102に拡散する。
【0052】
本願で説明されるシステム及び方法は、ロッキング・スクリプトが検証キーVを変更から保護し、プルーフπの有効性を確認することを可能にし、それにより、トランザクション検証中にブロックチェーンでゼロ・ナレッジ・プロトコルの実行を可能にすることに関する。
【0053】
検証可能な計算は、計算のプルーフの生成を可能にする技術である。実施形態では、このような技術は、入力xに関する関数fの評価を、本願においてプルーバー(a prover)と言及される別のコンピューティング・エンティティにアウトソースするために、クライアントによって利用される。場合によっては、クライアントは演算負担に限りがあり、その結果、クライアントは関数の評価を実行することが不可能であり(例えば、クライアントにとって利用可能な計算リソースを使用する計算の予想されるランタイムが最大許容閾値を超えてしまう場合があり)(但し、必ずしもそうであるとは限らない)、クライアントは、一般に、計算ランタイム、計算コスト(例えば、関数の評価を実行するために計算リソースを割り当てるための財務コスト)などの任意の適切な基準に基づいて、入力xに関する関数の評価を委任する可能性がある。
【0054】
プルーバーは、実施形態においては、本開示の他の箇所でより詳細に説明されているように、ブロックチェーン・ノードのような任意の適切なコンピューティング・エンティティである。実施形態では、プルーバ(例えば、ブロックチェーン・ノード)は、入力xに関して関数fを評価し、出力y及び出力yの正確性のプルーフπを生成し、これらは上述のクライアント及び/又はブロックチェーン・ネットワークの他のノードのような他のコンピューティング・エンティティによって検証されることが可能である。引数とも言及されるプルーフは、実際の計算を実行するよりも速く検証されることが可能であり、即ち、上述のプルーバーによって生成される出力の正確さを判断するために、入力xに対して関数fを再計算する代わりに、プルーフの正確さを検証することによって、計算のオーバーヘッドは削減されることが可能である(例えば、電力オーバーヘッド、電力に関連するコスト、及び実行中の計算リソースを低減することができる)。ゼロ・ナレッジ検証可能な計算において、プルーバーは、そのプルーバーが特定の性質を有する入力を知っていることの証明(an attestation)を、クライアントに提供する。
【0055】
ナレッジについてのゼロ・ナレッジ・プルーフの能率的な変形は、zk_SNARK(Succcinct Non-interactive ARgument of Knowledge)である。実施形態では、全てのペアリング・ベースのzk-SNARKはあるプロセスを含み、そのプロセスにおいて、プルーバーは一般的なグループ・オペレーションを使用して多数のグループ要素を計算し、検証器又はベリファイア(the verifier)が多数のペアリング・プロダクト方程式を使用してプルーフを確認する。実施形態では、線形インタラクティブ・プルーフは有限体で動作し、プルーバー及び検証器のメッセージは、フィールド要素のベクトルを決定するために使用可能な情報を含む、エンコードする、参照するか、又は他の方法で含む。
【0056】
実施形態では、本願で説明されるシステム及び方法は、ブロックチェーンのマイニング・ノードが、計算(例えば、入力xに関する関数fの評価)を1度実行し、出力の正確さを検証するために使用されることが可能なプルーフを生成することを可能にし、ここで、プルーフの正確さを評価することは、関数を評価することよりも演算負担に関して低コストである。この文脈では、オペレーション及びタスクのコスト(即ち、どれだけ高いコストであるか)は、オペレーション又はタスクを実行する計算の複雑さを指すことが可能である。実施形態では、計算の複雑さは、分類アルゴリズムを実行することについての平均計算コスト又は最悪ケースの計算コストを指し、例えば、ヒープソート・アルゴリズム及びクイックソート・アルゴリズムは両方ともO(n logn)という平均計算コストを有するが、クイックソートはO(n)という最悪ケースの計算コストを有する一方、ヒープソートは(n logn)という最悪ケースの計算コストを有する。実施形態では、入力xに関する関数fを評価することについての平均計算コスト及び/又は最悪ケース計算コストは、プルーフの正確性を評価することについてのコストよりも劣る。従って、本願で説明されるシステム及び方法の使用は非常に有利であり、例えば、より演算負担の重い高コストな契約が実行される可能性があり、なぜならそのような契約は、ブロックチェーンを検証するために必要とされる時間を、それに比例しては増加させないからである。更なる利点は、検証器システムの電力消費の低減を含む可能性があり、それによって検証器コンピュータ・システムの効率を改善し、プルーフの正確性を評価する際に、そのような検証器コンピュータ・システムを動作させることに関連するエネルギー・コストを低減する。
【0057】
実施形態では、検証キーV又はその一部は、ゼロ・ナレッジ・プロトコルのセットアップ段階で生成され、プルーフπと共に使用される公開パラメータ、及び入力/出力データから抽出され、プルーバーによって提供される適正計算の主張される正しさのプルーフを検証する。例えば、上記及び下記における詳細な説明で述べられるように、システム及び方法は、検証鍵Vを変更から保護し、プルーフπの有効性を確認するロッキング・スクリプトを可能にし、トランザクション検証中にブロックチェーンでゼロ・ナレッジ・プロトコルの実行を可能にする。従って、本開示は、計算の検証に使用される要素を記憶するためのブロックチェーン・スクリプト(例えば、ビットコイン・ベースのネットワーク)を使用して検証フェーズを実行するシステム及び方法を提供する。
【0058】
図2は、様々な実施形態によるプロトコルを実装するために利用されることが可能なコンピューティング環境200を示す。このプロトコルは、プルーフ・オブ・コレクトネス(proof-of-correctness)を記憶し、「コレクト・バイ・コンストラクション」暗号手法とスマート・コントラクトとを組み合わせるために、ブロックチェーン技術を用いて実装される可能性がある。実施形態では、公的な検証可能な計算スキームは、セットアップ・フェーズ、計算フェーズ、及び検証フェーズの3つのフェーズを含む。
【0059】
セットアップ・フェーズは、計算タスクの実行をアウトソースするために、プロセスの一部として実行されてもよい。後述するように、クライアントは、異なるコンピュータ・システムであってもよい、計算タスクの実行をプルーバーに委任するカスタマー又はクライアント・コンピュータ・システムなどのエンティティを指す可能性がある。一般的に、クライアントは、限定されるわけではないが、計算リソース、計算リソースの不足、タスクを実行するためにクライアント・コンピュータシステムを利用することに関連する経済的コスト、タスクを実行するためにクライアント・コンピュータ・システムを利用することに関連するエネルギー・コストなどを含む様々な理由により、計算タスクの実行を委任する可能性がある(例えば、電力のためにバッテリを当てにするモバイル・デバイス又はラップトップは、計算負担の高いタスクを実行するためにプルーバーを利用し、それによって、電力を節約し、バッテリ駆動デバイスの使用時間を延長することができる)。
【0060】
一実施形態では、セットアップ・フェーズは、クライアント、顧客、組織の従業員、又は他の任意の適切なエンティティが、正しい意味で正式な言語でコントラクトを書くことを含む。コントラクトは、C又はJavaのような高級プログラミング言語で書かれてもよい。一般に、コントラクトは、コンピュータ・システムによって処理されることが可能なフォーマットである、又はそれに変換されることが可能な任意の言語又は構文で表現される可能性がある。実施形態では、限定された目的で、ドメイン固有の言語が型安全性(タイプ・セーフティ)を提供することが可能であり、制限された表現が利用されることが可能である。生成されるソース・コードは、コントラクトの正確な記述である可能性がある。
【0061】
コンパイラ202は、コンピュータ・システムの1つ以上のプロセッサによって実行されると、ソースコード206を入力として受け取り、回路を生成させることをシステムに行わせる実行可能コードを含む、任意のハードウェア、ソフトウェア、又はそれらの組み合わせとすることが可能である。コンパイラ202は、バイナリ・コードのような機械読み取り可能なフォーマットにコンパイルされている命令に基づいて、命令を実行又は遂行するコンピュータ・プログラムを指す可能性がある。コンパイラ202が示されているが、インタプリタ、アセンブラ、及び他の適切なソフトウェア及び/又はハードウェア・コンポーネントが、ソースコードを回路に変換するために利用されてもよいことに留意されたい。実施形態では、回路は、フィールドFからの値を運び、論理ゲート及び/又は演算ゲートに繋ぐワイヤを備える演算回路である。実施形態では、この回路は、元の回路の完全な記述を提供する一組の多項式を含む二次プログラムQ208を生成するためにシステムによって使用される。
【0062】
一実施形態では、コンパイラ202は、プレプロセッサ・ディレクティブ、スタティック・イニシャライザ、グローバル及びローカル関数、ブロック・スコープ変数、配列、データ構造、ポインタ、関数呼び出し、関数オペレータ(例えば、ファンクタ(functors))、条件及びループ、演算及びビットワイズ論理演算子などを含むがこれらに限定されないC又はJavaのようなプログラミング言語の本質的な部分を認識することが可能なものである。実施形態では、コンパイラ202は、プログラミング言語の規格に従うコマンドのセット全体をサポートしていない(これは、ある場合には、再帰的アルゴリズムを禁止する等の、ある種のアルゴリズムがスマート・コントラクトで実行されることを防止するように意図される可能性がある)。実施形態では、コンパイラは、ソース・コードの表現を演算ゲート言語に拡張し、演算回路を生成する。回路の実装は以下の文献により過去に考察されている:Campanelli, M., et al. (2017) in “Zero-Knowledge Contingent Payments Revisited: Attacks and Payments for Services” and by Tillich, S. and Smart, B in “Circuits of Basic Functions Suitable For MPC and FHE.”演算回路は、コンパイラ202又は他の任意の適切なハードウェア、ソフトウェア、又はそれらの組み合わせ(例えば、図2に示されていないソフトウェア・モジュール)によって、二次演算問題(QAP)を構築するために利用される可能性がある。二次プログラムは、実施形態に従って、クライアント(例えば、鍵生成及び検証)及びプルーバー(例えば、計算及びプルーフ生成)のための一組の暗号ルーチンにコンパイルされる。
【0063】
実施形態では、鍵生成器204は、コンピュータ・システムの1つ以上のプロセッサによって実行されると、2次プログラムから評価鍵及び検証鍵をシステムに生成させる実行可能コードを含むハードウェア、ソフトウェア、又はそれらの組み合わせである。二次プログラムとしての計算をエンコードするための技術は次の文献で考察されている:“Quadratic Span Programs and Succinct NIZKs without PCPs” by Gennaro, R., et al.(2013).実施形態では、二次割当問題(QAP)Qは、フィールドFに関して回路Cをエンコードし、m+1個の多項式一式を含む:
V={v(x)},W={w(x)},Y={y(x)}
ここで、0≦k≦mである。ターゲット多項式t(x)も定義される。Fのn個の要素を入力として取り、n’個の要素を出力とする関数fが与えられた場合において(N=n+n’)、{c,...,c}∈Fがfの入力及び出力のグループの有効な指定であり、t(x)でp(x)を割るように係数のリスト{cN+1,...,c}が存在する場合に、Qはfを計算する:
【数1】
従って、実施形態では、h(x)・t(x)=p(x)であるような何らかの多項式h(x)が存在しなければならない。Qのサイズはmであり、その度合いはt(x)の度合いである。
【0064】
実施形態では、演算回路のQAPを構築することは、回路内の各乗算ゲートgに対して任意のルートr∈Fをピックアップし、t(x)=Π(x-r)であるようにターゲット多項式を定義することを含む。実施形態では、インデックスk∈{1...m}は、回路の各入力、乗算ゲートからの各出力に関連付けられている。Vの多項式は各ゲートへの左入力をエンコードし、Wは各ゲートへの右入力をエンコードし、Yは出力をエンコードする。例えば、k番目のワイヤがゲートgに対する左入力である場合にはv(r)=1であり、それ以外はv(r)=0である。従って、特定のゲートg及びそのルートrに関し、先行する方程式は次のように簡略化されることが可能である:
【数2】
ゲートの出力値はその入力の積に等しい。分割可能性検査はdeg(t(x))個の個々の検査に分解され、t(x)のルートr及び各ゲートにつき1つあり、p(r)=0である。加算ゲートと定数乗算ゲートはQAPのサイズや程度に寄与しない。
【0065】
実施形態では、QAPは、フィールドF上で定義され、ここでpは大きな素数である。実施形態では、Fp上のQAPが、加算及び乗算モジュロpにより表現されることが可能な任意の関数を効率的に計算することが望ましい。演算分割ゲートは、[0,2k-1]であるように知られている演算ワイヤa∈Fpを、k個のバイナリ出力ワイヤに変換するように設計されることが可能である。従って、ブール関数は、演算ゲートを用いて表現されることが可能であるという事実に従う。例えば、NAND(a,b)=1-ab である。各々組み込まれるブール・ゲートは、ただ1つの乗算コストしかかからない。更に、split(分割)のような新たなゲートが、スタンドアロンとして定義され、他のゲートとともに構成されることが可能である。[0,2k-1]内にあることが分かっている所与の入力a∈Fpに関し、splitゲートは、Σi-1=aであるようなaのうちの2進桁a,...,aを保持するk個のワイヤを出力し、各々のaは0又は1の何れかである。
【0066】
最後に、全てのプルーバー及び検証器により使用されるべき公開パラメータは、セットアップ・フェーズの一部としてシステムにより生成される。評価鍵Eと検証鍵Vは、クライアントにより選択されたシークレット値を用いて導出されることに留意すべきである。鍵生成器204は、評価鍵E210及び検証鍵V212を生成するために、鍵生成アルゴリズムに関連して二次演算プログラム(QAP)を利用することができる。
【0067】
実施形態では、計算タスクを実行することは、プルーバーによる入力216に関する関数の計算(即ち、f(x)を評価するプロセス)を含む。実施形態において、プルーバーは、クライアントが計算タスクを委任する可能性がある任意の適切なコンピュータ・システムである。入力216は、実施形態では、プルーバーに関連付けられたプライベート鍵を使用して生成されたディジタル署名のような、プルーバーの識別子を証明する情報を含む。実施形態では、プルーバーは、成功の結果として、クライアントがディジタル資産を移転するコンピュータ・システムである。クライアントは、実施形態では、入力x及び評価鍵Eをプルーバーに提供し、プルーバーは、評価モジュール214を使用して、出力y(即ち、y=f(x)であり、入力はxであり、関数はfである)を計算し、評価鍵E210を使用して、プルーフ・オブ・コレクトネス218を生成する。評価モジュールは、実施形態では命令を含むハードウェア及び/又はソフトウェアであり、命令は、コンピュータ・システムの1つ以上のプロセッサによって実行される場合に、コンピュータ・システムに、QAP208の内部回路ワイヤの値を評価させ、QAPの出力yを生成させる。
【0068】
実施形態では、二次プログラムの各多項式v(x)∈Fは、双線形グループ内の要素gvk(s)にマッピングされ、ここでsはクライアントにより選択されるシークレット値であり、gはグループの生成器であり、Fはgの離散対数の体(フィールド)である。実施形態では、所与の入力に対して、プルーバーは、二次プログラムの係数cに対応する内部回路ワイヤの出力及び値を得るために回路を評価する。従って、プルーバーは、gv(s)を得るためにv(s)=Σk∈{m}・v(s)を評価し;w(s)及びy(s)を計算し;h(x)=p(x)/t(x)=Σ・xを計算し;評価鍵におけるh及びgs(i)を利用してgh(s)を計算することが可能である。実施形態では、プルーフ・オブ・コレクトネス218は、(gv(s),gw(s),gy(s),gh(s))を含み、検証器は、p(s)=h(s)・t(s)を検査するために双線形写像を使用する。実施形態では、プルーフπは、後で使用するためにブロックチェーン222に格納されるか、又は、これらの各々と個別的に相互作用することをプルーバーに必要せずに、複数の当事者によって検証されることが可能である。実施形態では、プルーフ・オブ・コレクトネスの回路記憶の評価は、トランザクションのロッキング・スクリプトによって制限されるリソース(例えば、ディジタル資産)をロック解除するために実行されてもよい。
【0069】
実施形態では、プルーフπはブロックチェーン・ネットワークにブロードキャストされ、検証器220はプルーフを検証するために使用される。実施形態では、検証器220は、ブロックチェーン上のノードのような任意の適切なコンピューティング・エンティティである。更に、場合によっては、評価鍵E及び検証鍵Vを生成するのと同じコンピューティング・エンティティが、プルーフを検証することにも更に留意すべきである。実施形態では、ブロックチェーンのノードは、検証鍵E及びプルーフπを使用してロッキング・トランザクションを検証することが可能であり、検証が成功した場合に、コントラクトを有効化する。プロトコルの1つの要件は、プルーバーが、妥当でないプルーフを、たとえ検証鍵Vを知っていたとしても、提供できないことである。従って、このプロトコルでは、共通リファレンス文字列(CRS)は、クライアントにより、又は少なくとも評価鍵E及び検証鍵Vを発行する信頼できる第三者によって生成される。実施形態では、公開される検証鍵Vは、計算を検証するために、任意のコンピューティング・エンティティによって使用されることが可能である。
【0070】
本願で説明される技術を用いて、クライアントは、ブロックチェーン・トランザクションの受信者の識別子などのトランザクション・データを部分的に分かりにくくすることが可能である。実施形態では、アンロッキング・スクリプトは、受信者のアドレス及び受信者のパブリック鍵を公開しない。しかしながら、場合によっては、トランザクションの値(例えば、移転されるディジタル資産の量)がブロックチェーン・ネットワークのノードにとって可視的である可能性がある。実施形態では、上記及び下記の暗号技術は、クライアントがロッキング・スクリプトを二次演算プログラムへ変換し、プルーバーが演算プログラムを解いてプルーフを生成するために利用される。
【0071】
一般に、クライアントは、相手方又はプルーバーに支払うために、P2PK及びP2PKHのような標準トランザクション(例えば、ビットコイン・ベースのブロックチェーン・ネットワークで定義されるような標準トランザクション)を使用することが可能である。例えば、実施形態では、クライアントは、P2PKロッキング・スクリプトを演算回路に変換し、その回路から導出されたパズルを含むロッキング・トランザクションをブロードキャストする。相手方又はプルーバーは、回路を受信し、適切な入力(例えば、クライアントとプルーバーとの間で共有される秘密、又はプルーバーのシークレット鍵を利用して生成されるディジタル署名のような、プルーバーの身元を証明する情報)を提供し、回路を動作させてプルーフ・オブ・コレクトネスπを生成する。実施形態では、プルーフは、リソース(例えば、ディジタル資産)をロック解除するために使用され、更に、相手方又はプルーバーを識別する情報(例えば、相手方又はプルーバーに関連するパブリック鍵及び/又はディジタル署名)が、不明確ではないフォーマットでブロックチェーンに記録されない可能性がある。
【0072】
実施形態において、検証鍵及び対応するプルーフは、上記及び/又は下記の技術に従って生成される。従って、検証器には所与の検証鍵V及びプルーフπが与えられる:
【数3】
その結果、検証器は複数の楕円曲線乗算(例えば、各々の公開入力変数について1つ)及び5ペアのチェックを算出し、それらのうちの1つは追加的なペアリング乗算を含む。
【0073】
所与の検証鍵V、プルーフπ、(a,a,...,a)の下で、t(x)でp(x)を割り、従って(x)=f(xN+1,...,x)であることを検証するために、検証器は次のように処理を進める。先ず、3つのα項全てを検査する:
【数4】
次に、検証器は項βを検査する:
【数5】
最終的に、検証器は分割条件を検査する:
【数6】
【0074】
従って、上述のセクション及び本開示で説明される実施例による表記を考慮すると、検証は、実施形態による以下の要素のペアのチェックのセットを含む:
【数7】
【0075】
図3は、検証可能な計算のパフォーマンスを調整するための図300を示す。クライアント302、プルーバー304、及び検証器306は、ブロックチェーン・ネットワークのノードであってもよい。クライアント302は実行可能コードを含むことが可能な任意の適切なコンピュータ・システムである可能性があり、実行可能コードは、コンピュータ・システムの1つ以上のプロセッサによって実行されると、コンピュータ・システムにスマート・コントラクト308を受信させる。実施形態において、スマート・コントラクト308は、C、C++、又はJavaのようなソース・コードとして高級プログラミング言語でエンコードされている。実施形態では、コンパイラ、インタプリタ、及び/又はアセンブラのようなソフトウェアを利用して、スマート・コントラクト308を演算回路310に変換することが可能であり、演算回路は、体Fからの値を運び、加算及び乗算ゲートに接続する「ワイヤ」から構成される。演算回路は、物理的なワイヤによって接続された一連の物理ゲート(例えば、7400シリーズのゲート、フリップ・フロップ、バッファ、デコーダ、マルチプレクサなどのトランジスタ-トランジスタ論理(TTL)集積回路を使用するもの)を含む物理回路によって実現されることが可能な論理回路を指す可能性があることに留意すべきである。スマート・コントラクト308の実行は、図3及び他の部分の文脈で説明されるが、スマート・コントラクトの利用は、演算回路に変換されることが可能なソース・コードの非限定的な一例に過ぎない。実施形態では、クライアント302は(例えば、単独で、又は他のエンティティと組み合わせて)、一群のオペレーションによって定められるタスクを実行するためのソース・コードを決定し、タスクの実行はプルーバー304に委任される。一般に、検証器306は、例えば、プルーバー304によって生成されたプルーフ・オブ・コレクトネスの妥当性を検証すること等によって、プルーバー304がタスクを正しく実行したことを判断することに関連するタスクを実行することが可能である。
【0076】
実施形態では、クライアント302は、プルーバー304に演算回路310を提供し、データ・プロバイダ318は、プルーバーに回路への入力312を提供する。場合によっては、入力312は、現実世界の状態及びイベントに関するデータなどのデータであってもよい。回路310は、元の回路の完全な記述を提供する一群の多項式を含む二次プログラムQを生成するために使用されてもよい。何れの場合も、プルーバー304は、入力312に関して回路C又は2次プログラムQを実行し、1つ以上の出力中間出力及び1つの最終出力を生成してもよい。幾つかの実施形態では、プルーバーは、出力として、入力ワイヤの回路ワイヤに対する割り当てである{C,x,y}の有効トランスクリプトを得るように期待されており、入力ワイヤに割り当てられる値はxについてのものであり、中間値はCにおける各ゲートの正しい動作に対応し、出力ワイヤに割り当てられる値はyに対応し;求められる出力が正しくない場合(即ち、y≠P(x)である場合)、{C,x,y}に対する有効なトランスクリプトは存在しない。実施形態において、プルーバーは、回路ワイヤの値のサブセットを提供するように期待されており、回路ワイヤの値のうちの選択されるサブセットは、プルーバーにとって事前には分からない。
【0077】
実施形態において、出力y、内部回路ワイヤの値(又はそのサブセット)、及び評価鍵Eは、プルーフ・オブ・コレクトネス316を生成するために使用される。プルーフπは、ブロックチェーンにおいて記憶され、プルーバー304が複数の当事者と個別的に相互作用する必要なしに、複数の当事者によって検証されることが可能である。このようにして、検証器306は、パブリック検証鍵Vとプルーフπとを用いてロッキング・トランザクションを検証し、それによってコントラクトを検証することが可能である。場合によっては、クライアント302は、検証が失敗した場合に、ロッキング・トランザクションによって制限されているディジタル資産を返還要求する可能性がある。場合によっては、検証器306とクライアント302は同じコンピュータ・システムである。
【0078】
図4は本開示の実施形態の図400を示す。具体的には、図4は、データ・ソースによって提供されるデータが認証され、ブロックチェーン・ネットワークに公開されるスマート・コントラクトなどのプログラム又はスクリプトの実行に利用される環境を示す。実施形態において、クライアント402、プルーバー404、及びデータ・プロバイダ406はコンピュータ・システムである。実施形態では、クライアント402は、計算タスクの実行を、本願でプルーバーと言及される別のコンピュータ・システムにアウトソース又は委任するコンピュータ・システムを指す。実施形態において、計算タスクは、機能の評価、スマート・コントラクトの実行などを指す。実施形態では、計算タスクを実行することは、回路及び1つ以上の入力に基づく出力の計算を含み、計算は、クライアントに代わってプルーバーによって実行される。回路は、契約の条項の正式な表現であるソース・コードから生成されることが可能である。
【0079】
本開示の他の箇所でより詳細に説明されるように、ブロックチェーンにおけるスマート・コントラクトの実行のためのプロトコルは、ゼロ・ナレッジ・プルーフを利用する可能性がある。実施形態では、スマート・コントラクトの実行は、トランザクション検証の一部として生じることが可能である。このために、プロトコルのセットアップ・フェーズの間に生成された公開パラメータは、プルーバーによって提供される主張される適正計算証明を検証し、コントラクトの実行の有効性を検証するために、プルーフ及び入力/出力データと共に使用される。コントラクトの実行フェーズは、幾つかの実施形態では、ブロックチェーンにとって外部の入力/出力データを当てにしていてもよい。一般的に言えば、外部データとは、ブロックチェーン上では入手可能できない、又はブロックチェーンを介してアクセス可能なデータからは検証できない情報を指す。外部データは、データ・フィード及びアプリケーション・プログラミング・インターフェース(API)のような種々のソースから取得されることが可能である。外部データは、スマート・コントラクトを取り巻く様々な状況において使用される可能性があり、スマート・コントラクトは例えば:資産及び金融アプリケーション(例えば、金利)のための市場価格フィードへのアクセスを必要とする証券(例えば、金利、デリバティブ、債券)で使用されるスマート・コントラクト、外部データへのアクセスを必要とするピア・ツー・ピア保険スマート・コントラクト(例えば、遅延に対して当事者が保険をかけられているフライト情報、農作物保険のための価格インデックスの代わりに気象データ・フィードを使用する金融デリバティブ契約の天候データ)、出荷に関するGPSデータを必要とする取引スマート・コントラクト、乱数発生器へのアクセスを必要とするギャンブル・コントラクトなどを含むが、これらに限定されない。
【0080】
実施形態では、スマート・コントラクトを実行する時期及び/又は方法を決定することは、現実世界の状態及びイベントに関するデータなどの外部データへのアクセスに依存する。実施形態では、データ・プロバイダ406は、そのようなデータを提供し、場合によっては、スマート・オラクルと言及されてもよい。オラクルによって返されるデータは、当事者によって指定される特定の情報が、指定されるテキスト、又は指定される情報を含むかどうかを示すブーリアン形式のような、様々なフォーマット及びタイプにおけるものとすることが可能である。実施形態では、このデータは、賭け(bets)(例えば、ボクシングの試合の結果のようなバイナリ・イベントの結果)を組織化するために使用されることが可能である。浮動小数点値は、通貨の間の為替レート(暗号通貨を含む)の文脈で使用されることが可能であり、何らかのビットコイン交換のAPIから読み込むことが可能である。この種のデータは、オプションやヘッジ契約を組織化するのに有用であるかもしれない。
【0081】
また、データ・プロバイダ406は、現実世界の状態及びイベントに関するデータなどの外部データを検索及び/又は提供し、外部データをブロックチェーンにとって利用可能にするオラクルと言及されてもよい。オラクルは実行可能なコードを含むコンピューティング・エンティティを指す可能性があり、そのコードは、コンピュータ・システムの1つ以上のプロセッサで実行される場合に、ブロックチェーンとネットワーク(例えば、インターネット)との間の信頼されるリンクとして働くブロックチェーン(例えば、ビットコイン、イーサリアム、及びその他)と互換性のあるデータ及び/又はデータ・フィードを、コンピュータ・システムに生成させる。オラクルは、ウェブサイト、フィード、データベース、及びその他のデータ・ソースからデータを取得して、外部データをブロックチェーンに提供することが可能である。外部データは、例えば温度情報、出荷のGPS座標、航空情報(例えば、飛行状態情報)等を含む可能性がある。
【0082】
実施形態では、プルーバー404は以下のようにしてデータ・プロバイダ406から外部データを取得する:データ・プロバイダ406との暗号で保護された通信セッションを確立し、暗号で保護された通信セッションを介して要求を行い;データ・プロバイダは要求に応じてデータを提供し、プルーバーは、データを受信し、データの受信に応答して、当事者間の通信の証明(an attestation)を要求し、データ・プロバイダは、暗号で保護された通信セッションの間に、プルーバーとデータ・プロバイダとの間の通信の暗号的に検証可能なプルーフπCommunicationsを計算し、データ・プロバイダのプライベート鍵で証明にディジタル署名し;プルーバーは通信のプルーフを受信する。一般的に言えば、通信のプルーフは、クライアントとサーバーとの間(例えば、プルーバーとデータ・プロバイダとの間)で1つ以上の通信が行われたことの暗号的に検証可能な証明である。実施形態では、証明は、クライアントとサーバーとの間の通信の内容を検証するために使用することが可能であるが、場合によっては、例えば、編集された情報を不明瞭な情報(例えば、暗号化された又はハッシュされたフォーマットの情報)で置き換えることによって、又は所定のデフォルト値で置き換えることによって、通信の一部が編集される可能性があることに留意されたい(例えば、情報の開示が法的制限の対象となるような情報である)。実施形態では、証明は、図6に従って説明されるようなマークル・ツリーのルート値に少なくとも部分的に基づいて決定される。実施形態では、証明(例えば、通信のプルーフ)は、データ・プロバイダ406に対してアクセス可能な暗号化プライベート鍵を使用してディジタル署名される。認証当局などのエンティティは、プライベート鍵に対応する暗号パブリック鍵を証明するディジタル証明を発行することが可能である。本開示の範囲において、通信のプルーフは、πCommunicationsという表記を使用して一般的に言及される一方、適正実行のプルーフは、πProver又はよりシンプルにπと言及される可能性があることに留意すべきである。
【0083】
認証当局410は、特定の暗号鍵が特定のエンティティに属することを証明するディジタル証明を生成及び/又は配布するコンピューティング・エンティティを指すことが可能である。例えば、データ・プロバイダのパブリック鍵を含むディジタル証明は、コンピューティング・エンティティによって取得されてもよく、そのようなパブリック鍵は、種々の状況で使用される可能性があり、例えば、データ・プロバイダとの安全な通信のためにデータを暗号化すること、データ・プロバイダによって署名されたとされるディジタル署名の真正を検証こと等のために使用可能である。図4は、クライアント402が認証当局410と信頼関係を有する実施形態を示しているが(例えば、クライアントは、認証当局によって適切に署名及び/又は発行されたディジタル証明を真正であるとして取り扱う)、鍵管理システム又は鍵レジストリのような任意の適切な信頼されたコンピューティング・エンティティが利用される可能性がある。
【0084】
プルーバー404は、図2に関連して上述したような方法でπProverを生成するために入力データを利用する。実施形態では、πProverは後で使用するためにブロックチェーン408上に格納されるか、又はプルーバーがこれらの各々と個別的に相互作用することを必要とせずに、複数の当事者によって検証されることが可能である。例えば、飛行遅延に対する当事者を保証するためのスマート・コントラクトの実行は、入力データとして、公式の航空当局(例えば、米国の連邦航空局又は英国の民間航空当局)から取得される公式の飛行データを当てにすることが可能である。一般的に言えば、入力データは、必ずしも政府筋からのものである必要はなく、スマート・コントラクトの当事者は、入力データが取得される元であるエンティティのリストに合意することが可能であり、従って、データ・ソースは、クライアントがデータを得るために信頼できることを示す任意の適切なコンピューティング・エンティティである可能性がある。クライアントは、異なる入力に対して、信頼できるエンティティについての異なるリストを指定してもよい。信頼できるエンティティのリストは、契約の価値に基づいて選択及び/又は切り詰めることが可能である。
【0085】
プルーバー404は、通信のプルーフをクライアント402に送信することができる。場合によっては、データ・プロバイダ406は、例えばプルーバーからのコマンドに基づいて、通信のプルーフをクライアント402へ送信する可能性がある。先に議論したように、通信のプルーフは、マークル・ツリーのルート値に少なくとも部分的に基づいて導出されることが可能である。例えば、通信のプルーフは、通信が発生した時間インターバルを指定する情報をエンコードすることも可能である。一実施形態では次の通りである:
【数8】
【0086】
換言すれば、通信のプルーフは暗号ハッシュ関数を使用して計算され、マークル・ツリーのルート値(h’final)と通信の時間インターバル(WTime:実施形態では、暗号通信セッションの開始時間と通信のプルーフが要求された時間とをエンコードする)とが暗号ハッシュ関数に入力される。実施形態では、暗号ハッシュ関数の入力は、連結されるか、さもなければ結合される。マークル・ツリーは、WTimeにより示される時間インターバルの間に当事者間でやり取りされた記録に少なくとも部分的に基づいて生成されることが可能である。通信のプルーフは、データ・ソースの暗号プライベート鍵を使用してディジタル署名されることが可能である。実施形態では、カンバセーションが行われる時間は、WTime=[TSessionStart,TProofRequest]として規定され、サーバー(例えば、データ・ソース504)によって生成される通信のプルーフの一部として含まれる。なお、プルーバー404は、通信のプルーフをクライアント402へ送信することに加えて及び/又はその代わりに、そのプルーフを、セキュア・サーバー(例えば、クライアント402に関連するパブリック鍵の下で暗号化される)又はコンピューティング・リソース・サービス・プロバイダのデータ・ストレージ・サービスに記憶することができる。実施形態では、クライアント402は、通信のプルーフをデータ・リポジトリ(例えば、データ・ストレージ・サービス)に記憶し、クライアント404に、データ・リポジトリから通信のプルーフを取得するために使用可能なユニフォーム・リソース識別子(URI)又は他の適切なリファレンスを提供する。例えば、(例えば、何日にもわたって1つ以上の経路に対する飛行データを捕捉することのような)繰り返されるタスクを実行するプルーバー402は、捕捉されたデータを、データ・リポジトリのコンテナに集約し、その結果、クライアントは時間インターバルにわたって(例えば、特定の経路について)過去の飛行データを取得することができる。
【0087】
実施形態では、クライアント402は、通信のプルーフ及び通信のプルーフのディジタル署名を受信する。クライアントは、ディジタル署名がデータ・プロバイダによって署名された主張されていることを確認し、データ・プロバイダに関連するパブリック鍵を取得し(例えば、認証当局410によって発行されるディジタル証明から取得し)、ディジタル署名の真正を検証するためにパブリック鍵を使用することができる。ディジタル署名が真正であると判断された場合、クライアント402は、通信のプルーフがデータ・プロバイダによって生成されたことを信頼し;そうでない場合は、通信のプルーフ及びディジタル署名は破棄される可能性がある。通信のプルーフを検証した後、クライアント402は、図2及び図3に関連して説明したような方法で、プルーフ・オブ・コレクトネスを検証することが可能である。
【0088】
幾つかの実施態様において、クライアント402は、特定のプルーバー404から取得された外部データが正しかったこと(例えば、データはデータ・プロバイダによって提供されたものと同じデータであったこと)を示す評判トランザクションを生成する。評判トランザクションは、プロバイダ404が計算タスクを正しく実行したかどうか、及び/又はプロバイダ404が、データ・プロバイダから受信した外部データを使用してπProverの計算を実行したことに関し、それが偽りなきものであったかどうかの記録として、ブロックチェーン408にマイニングされてもよい。スマート・コントラクトが実行された後、クライアントは、πProverを生成するのに使用された入力データがデータ・プロバイダにより提供されたものであったことを検証するために、πCommunicationsを使用することが可能である。評判トランザクションは、プルーバーにより提供されるサービスのレビューを示すブロックチェーンにマイニングされる可能性があり、肯定的な結果は、プルーバーに正直に行動するインセンティブを与える可能性があり、その後のスマート・コントラクトの実行のためにプルーバーを選択するために使用される可能性がある。評判トランザクションは、πProverで使用される入力データがデータ・プロバイダから来ていることの十分な証拠を提供した上で、プルーバーが評判トランザクションのロックを解除できるようにする第1アンロッキング・スクリプトと、クライアントがレビューを取り消すことを可能にする第2アンロッキング・スクリプトとを含む可能性がある。図4に示される評判トランザクションは、本開示の他の箇所で説明されるもの、例えば図9に関連して以下で説明されるものに従う可能性がある。
【0089】
一般的に言えば、図4の状況においてクライアントは、ターゲット・ソースsrc、時間τ、及びクエリqを指定するリクエストReq(src,τ,q)を作成する。srcがウェブ・サーバーである場合、TLSセッションのような暗号で保護された通信セッションが必要とされる可能性がある。実施形態では、暗号で検証可能な信頼性の保証を提供する、暗号で保護された任意の通信セッションが使用されてもよく、ここで、当事者間のメッセージは、同じシークレット鍵を使用して生成及び検証の双方が行われるメッセージ認証コード(MAC)によって認証される。これは、サーバーとメッセージの受信者とが同じ鍵に同意しなければならないことを意味し、従ってMACを検証することが可能な任意のユーザーは他のメッセージに対してもMACを生成することが可能である。これに対して、ディジタル署名は、特定のメッセージが特定のプライベート鍵の保持者によって署名された、ということを提供することができる。通信を認証するアプローチはTLSSignOnOffと呼ばれる新しいサブ・プロトコルを規定する「TLS Sign」においてHajjeh及びM.Badraによって考察されており、ここで、クライアント及びサーバーは、それらが署名済みデータを送信することを開始又は停止した場合にピアに通知する。停止メッセージの後に、サーバーは、カンバセーションのハッシュを収集し、それに署名する。暗号で保護された通信セッションの記録データを認証するための他の様々なアプローチ(例えば、セッションの記録を保存し、記録された通信の真正性及び/又は完全性を暗号で検証可能な証拠として会話に署名する)が使用されることが可能であり、これについては次の技術文献を参照されたい:“R. Housley and M. Brown, “Transport Layer Security (TLS) Evidence Extensions” and by H. Ritzdorf, K. Wu..st, A. Gervais, G. Felley, and S. Capkun, “TLS-N: Non-repudiation over TLS Enabling Ubiquitous Content Signing for Disintermediation”これらはクライアントがリクエストを作成した場合に始まるエビデンス・ウィンドウを規定し、当事者のうちの一方がエビデンス・ウィンドウを閉じると、メッセージのハッシュ、及びエビデンスの生成のタイムスタンプは、オプションとして機密の記録が隠されて、サーバーにより署名される。
【0090】
図5は、プルーバー502がデータ・ソース504からデータを取得する実施形態の例示的な図500である。実施形態では、プルーバー502とデータ・ソース504との間に暗号で保護された通信セッションが確立される。暗号で保護された通信セッションの具体例は、TLS(Transport Layer Security)及びSSL(Secure Sockets Layer)セッションを含む。暗号で保護された通信セッションは、当事者間の安全な接続を提供するために利用されることが可能である。この状況において、セキュアな接続は、真正性、完全性、プライバシー、又はそれらの任意の組み合わせの暗号で検証可能な保証を指す可能性がある。真正性とは、メッセージの作成者であると主張する者によってメッセージが作成されたという保証を指す可能性がある。完全性とは、受信したメッセージが、メッセージが送信されたときの元の形式から、意図的でも(例えば、悪意のある者によって)又は意図的でなくとも(例えば、送信中の信号の欠落の結果として)変更されなかったという保証を指す可能性がある。機密性とは、送信前のメッセージの一部又は全部の暗号化を指す可能性がある。実施形態では、クライアント(例えば、プルーバー502)とサーバー(例えば、データ・ソース504)とは、ハンドシェイク508と呼ばれる第1フェーズの間に情報を交換し、セキュリティを確保するために、非対称暗号化と対称暗号化とのハイブリッドが行われる。図5に示されるハンドシェイクは、TLSハンドシェイク・プロトコルに従う4ウェイ・ハンドシェイクであってもよい。実施形態では、クライアント(例えば、プルーバー502)は、クライアント・バージョン、セッションid、追加的な拡張による追加機能、又はそれらの組み合わせなどのパラメータを含むClientHelloメッセージを送信する。実施形態では、ハンドシェイクは、カンバセーションのためのプルーフの記録を開始するために、サーバー(例えば、データ・ソース504)への信号のメッセージで始まる。その結果、サーバー(例えば、データ・ソース504)はプルーフ生成に関連する内部状態に入り、この状態は、通信のプルーフを生成するための後続の要求を受け取るまで続く。この内部状態では、データ・ソース504は、暗号で保護された通信セッションを介してやり取りされた、プルーバー502とデータ・ソース504との間の通信の内容(又はその一部)を記録する可能性がある。
【0091】
ハンドシェイクの後(例えば、記録プロトコルの間)、送出メッセージはブロックに分割される一方、到来メッセージは再構築される。実施形態では、暗号で保護された通信セッションの当事者間のカンバセーションは、複数の記録R,...Rを含む。これらの記録は、例えば一組のリーフ・ノードを含むマークル・ツリーを生成することによって、通信のプルーフを生成するために利用されることが可能であり、一組のリーフ・ノードはレコードR,...Rを含む。図5に関連して図示され説明される記録は、図6に関連して説明されるもののようなマークル・ツリーを生成するために使用されることが可能である。
【0092】
実施形態では、記録は、暗号で保護された通信セッションの一部として、プルーバー502とデータ・ソース504との間でカンバセーションを形成するリクエスト(要求)及びレスポンス(応答)を指す。場合によっては、要求及び応答は、必要以上の情報(例えば、プルーバー5-2がスマート・コントラクトの実行に関して必要とする入力データを決定するのに無関係な情報)を含む。実施形態では、サーバー(例えば、データ・ソース504)は、テンプレート(例えば、特定のフィールドを有するJSONノードの形式)で記入する。テンプレートは、ハンドシェイクの間に指定されてもよい。一例として、気象データを得るためのテンプレートは、場所、日付、及び温度に関するフィールドを有する可能性がある。実施形態では、飛行データのリクエストは、飛行状態、フライト識別子、及び日付を含む可能性があり、例えば{“flightInfo”:{“data”:{“id”:“BA886”:[{“validDate”:“2017-11-01T07:00:00+0000”},“status”:“On time”}]}のような形式におけるものである。
【0093】
ハンドシェイクが完了すると、当事者(例えば、プルーバー502及びデータ・プロバイダ504)は、データを含む相互間で記録510を送信することができる。例えば、プルーバー502は、回路を評価し、スマート・コントラクトの実行の一部として出力を生成するための入力として使用することが可能なデータ・プロバイダ504からのデータを要求することができる。プルーバー502が回路を評価するのに十分なデータを受信した後、プルーバーはデータ・プロバイダ504からのセッションのプルーフ512を要求することができる。データ・プロバイダ504は、クライアント(例えば、図3及び図4に関連して説明されるクライアント)と信頼関係を有するコンピュータ・システムであってもよく、クライアントは、データ・プロバイダによって生成及び/又は提供されるデータを信頼し、この状況では、クライアントが他のエンティティからのデータを信頼することは、エンティティから取得したデータをクライアントが正しいものとして受け入れること、及び/又は、有効なセキュリティ証明を有する信頼されるソースから公表されるデータは真正かつ正確であることをクライアントが受け入れることを指す可能性がある。実施形態では、サーバー(例えば、データ・ソース504)は、ハンドシェイク・プロトコルの完了からπCommunicationsを生成する要求が受信されるまでの記録プロトコルの間に当事者間で交換される全ての記録のハッシュ・ルート514から構成される通信516のプルーフを生成する。また、実施形態では、データの実行が、入力が特定の時間に収集されることに左右される等の場合(例えば、特定の日の特定のフライト番号の遅延に対する保護をもたらすフライト保険のスマート・コントラクト)において、WTimeもまた記録と共にハッシュ処理される。
【0094】
実施形態では、クライアント(例えば、プルーバー502)はπCommunicationsを要求し、データ・プロバイダは、連結され、ハッシュされ、データ・ソースのプライベート鍵でディジタル署名された全ての記録及びWTimeのコミットメントから取得されるハッシュ・チェーンの最終値を返す。従って、当事者間で通信される記録に含まれるデータは、スマート・コントラクトの実行で使用されることが可能である。この通信のプルーフπCommunicationsは、初期のスマート・コントラクトにも供給することができ、専用の機能により検証されることが可能であるので、半信半疑のプルーバーの必要性を排除することができる。実施形態では、図6に関連して説明されるような方法で、記録はマークル構造で一緒にハッシュされる。
【0095】
図5に関連して、セッション・クライアントがセッション・サーバーからのプルーフを要求する実施形態が説明されているが、それは必須ではないことに留意すべきであり、本願で説明される技術は、TLSセッションのサーバーがTLSセッションのクライアントからの通信のプルーフを要求するように、適用される可能性もある。
【0096】
図6は、本開示で説明される種々の実施形態に従って構築及び/又は利用される可能性があるマークル・ツリーの例示的な図600である。例えば、そのようなマークル・ツリーは、図2図5に関連して説明される実施形態の状況で構築される可能性がある。
【0097】
実施形態では、クライアント・コンピュータ・システム及びサーバー・コンピュータ・システムは、TLSセッションなどの暗号で保護される通信セッションを確立し、メッセージ(例えば、記録)をやり取りする。セッションの当事者間で通信される1つ以上のレコードR...Rは、例えばハンドシェイク・プロトコルの完了から、サーバーが通信のプルーフを生成するためにクライアントから要求を受け取るまでの指定された期間内に、サーバーによって記録されることが可能である。実施形態では、サーバーは実行可能なコードを含み、コードは、サーバーの1つ以上のプロセッサによって実行されると、サーバーに:クライアントとサーバーとの間で通信の記録を開始する指示を検出すること;暗号で保護された通信により送受信された記録を格納すること;通信のプルーフを生成する指示を検出すること;及び格納された記録に少なくとも部分的に基づいてマークル・ツリーを生成することを行わせる。上述のプロセスに対する種々の代替及び拡張が考えられる。マークル・ツリーは、マークル・ツリーの各リーフ・ノードがデータ・レコードのハッシュであり、少なくとも暗号ハッシュ関数を使用して、非リーフ・ノードの各々が、非リーフ・ノードの子ノードから、少なくとも部分的に基づいて導出されるデータ構造を指す可能性がある。しかしながら、本願に含まれる技術は、マークル・ツリーに類似する構造を利用して、特定のデータの一部がマークル・ツリーの一部であることを検証することが可能であることに留意すべきであり、例えば、実施形態において、本願に含まれる技術はある構造に適用され、その構造において、ツリーのリーフ・ノードはデータ・レコードであり、非リーフ・ノードは、少なくとも暗号化ハッシュ関数を使用して、非リーフ・ノードの子ノードから少なくとも部分的に基づいて導出される。実施形態において、本願で説明されるツリー・データ構造は、バイナリ・ツリーである。図6は、アンバランスなマークル・ツリーの例を示しているが、幾つかの実施形態では、マークル・ツリーのリーフ・ノードは、ツリーのバランスがとれるように又はバランスが実質的にとれるように配置される(例えば、実質的にバランスがとれたツリーは、ツリーの特定の深さに全てのリーフを有することが可能である)ことに留意されたい。
【0098】
実施形態では、マークル・ツリーは、格納された(例えば、サーバーによってRAMのような短期メモリにキャッシュされた)1つ以上のレコードR...Rから生成され、通信のプルーフを生成する指示を検出すると、レコードは、マークル・ツリーのリーフ・ノードとして時系列的に選択される。各レコードは、TLSプレ・マスター・シークレット又はマスター・シークレットのようなハンドシェイク・トラフィック・シークレットから導出される可能性があるランダム・ソルト値とともに暗号ハッシュされる。ソルトは、任意の適切な確率過程を用いて生成される擬似乱数又は乱数である可能性がある。これらのソルトは、それらが特定のマークル・ツリーの状況の中で再利用されないように選択されるか、又は任意の2つのソルトが同じ値である確率が閾値確率を下回るように選択されてもよい。
【0099】
第1ソルトと第1レコードは暗号ハッシュ関数へ入力されることが可能であり、第1ソルトと第1レコードは連結され、(例えば、SHA-256暗号ハッシュ・アルゴリズムを使用して)ハッシュされる。一般的に言えば、暗号ハッシュ関数が示されている場合には、一方向関数のようなプレ・イメージ耐性関数が利用されてもよい。図6に示す例示的な例ではソルトが利用されているが、一般的に言えば、レコードはノンス、初期化ベクトル、及び任意の他の適切な暗号プリミティブで増強されてもよい。第1出力は、第1ソルトと第1レコードとを入力として利用して暗号ハッシュ・アルゴリズムを実行することにより生成される。第1出力は、第1レコードがクライアント又はセッションのサービスによって送信されたかどうかを示す情報でハッシュされる可能性がある。例えば、図6は、クライアントに関連する情報がハッシュ出力の前に付加される実施形態を示しており、この場合においてクライアントはレコードの送信者であり、サービスに関連する情報がハッシュ出力に付加され、この場合においてサービスはレコードの送信者である。前に付加される/後に付加される情報は、任意の適切な情報である可能性があり、固定クライアント値(例えば、ゼロ)及び固定サーバー値(例えば、1)が利用されてもよい:
【数9】
【0100】
実施形態では、ツリー構造は固定され、クライアント又はサービスに関連する値(例えば、送信者に関連するIPアドレス又はMACアドレス)が、マークル・ツリーに前に付加/後に付加される。そのような例(図6には示されていない)では次のようになる:
【数10】
【0101】
暗号で保護された通信セッションを介して送信される追加のレコードは、上述の方法で作成され、ルート・ノード値を生成するために順次一緒にハッシュされることが可能である。図6に示される例では、各ノードは中間ノード値を生成する:
【数11】
一実施形態(図6には示されていない)では:h’R1=hR1である。
【0102】
実施形態では、最終的なハッシュ値は、h’Rlast=H(hRlast-1,hRlast)のように算出され、これはマークル・ツリーのルートである。実施形態では、h’Rlastは通信のプルーフである。実施形態では、h’Rlastは時間インターバル(例えば、WTime,R及びRlastに関するタイムスタンプ)などの追加情報によって増強され、これらは通信のプルーフを形成するために一緒にハッシュされることが可能である。通信のプルーフは、暗号通信セッションのサービスに関連するプライベート鍵によってディジタル署名される可能性があり、そのサービスは、スマート・コントラクト・クライアントによって信頼されるエンティティである(例えば、図3及び図4に関連して説明されているようなものである)。
【0103】
図7は、本開示で説明される種々の実施形態によるマークル・パスの例示的な図700である。マークル・パスは、暗号で保護された通信セッションのクライアントとサービスとの間でカンバセーション中に、特定のレコード(より一般的には、特定のデータ又は情報の特定の部分)が通信されたことの暗号で検証可能な保証を提供するために利用されることが可能である。マークル・パスは、図6に関連して説明されるマークル・ツリーから構成されることが可能であり、図2図5に関連して説明された実施形態の状況で利用されることが可能である。
【0104】
実施形態では、プルーバーは、データ・ソースからデータを受信し、該データを演算回路を解くための入力として使用し、回路の出力に少なくとも部分的に基づいて適正実行のプルーフを生成する。プルーバーは、追加的に、演算回路を解く場合に使用されたデータが、プルーバーとデータ・ソースとの間の一群の通信に含まれていたことの証明を生成することが可能である。実施形態では、証明はマークル・パスであり、マークル・パスは、マークル・ツリーのルート値を計算するのに十分なマークル・ツリーの一群のノード値を含む。マークル・パスは、マークル・ツリーのリーフ・ノード値の全部又は一部を含んでもよいし、又は全く含まなくてもよい。マークル・パスは、マークル・ツリー内のノード値の位置に関する情報を含む可能性がある。ルート・ノード値は、より大きなマークル・ツリーのサブツリーのルート・ノード値である可能性があることに留意すべきである。証明は、プルーフ・オブ・コレクトネスπProverにエンコードされてもよい。
【0105】
実施形態では、コンピューティング・エンティティは、次のようにすることで、特定の通信の内容が2つの他のコンピューティング・エンティティ間の一群の通信に含まれていたことを検証することが可能であり、即ち:信頼されたエンティティのプライベート鍵を使用して生成されたルート・ノード値に対するディジタル署名及びマークル・ツリーのルート・ノード値を、信頼されたエンティティから受信し;信頼されたエンティティのパブリック鍵を使用してディジタル署名の真正を検証し;一群のノード値を含むマークル・パスを受信し(一群のノードのうちのノードは、通信されたと主張される特定の通信に対応する);主張されているルート値を一群のノード値から計算し;及び主張されるルート値を、検証されたルート・ノード値と比較する。
【0106】
図7に示されるマークル・パス702を考察する。これは、実施形態において、図6に関連して説明されるマークル・ツリーに基づいて導出される。図7に示されるマークル・パス702は、特定のレコードRが、(例えば、TLSセッションのような)クライアントとサーバーとの間の一群の通信の一部として含まれていたことを検証するために利用されることができる。マークル・パス702の一群の値は、最終ハッシュ値を生成するために一緒にハッシュされることが可能である。実施形態では、最終的なハッシュ値は、値が一緒にハッシュされた順序を示すマークル・パス内でエンコードされるか、又はそれに関連する追加情報に基づいて生成される。例えば、図7に示されるマークル・パス702は、図7に示されるような最終値hR4=H(H(h’R2,H(0,H(saltC3,R3))),hR4)を計算するために使用されることが可能である。最終値がルート値(例えば、図6のh’Rlast)と一致する場合、コンピューティング・エンティティは、レコードRが、カンバセーションの当事者間の一群の通信ののうちの通信として含まれていたと判断する。
【0107】
一般的に言えば、マークル・パスは、ルート・ノードの値を計算するのに十分なマークル・ツリーの一群のノード(又はこれらのノードの値)を指す可能性がある。ルート・ノードは、図7に示すマークル・ツリーのルート・ノード、又はそのようなツリーのサブツリーであってもよい。図7に示すマークル・パスのようなマークル・パスは、2つのリーフ・ノードの値をエンコードすることが可能であり、リーフ・ノードからルート・ノードまでの間のマークル・ツリーの各々の深さにおいて、正確に1つの値が、マークル・ツリーの正確に1つのノードに対応する。しかしながら、これは必須ではない:別の適切なマークル・パスは、マークル・ツリーの各リーフ・ノードの値を含むが、そのようなマークル・パスは図7に示されるような他のマークル・パスよりも大きなストレージ条件を有する可能性がある。
【0108】
図8は、様々な実施形態に従ってプロトコルを実装するために利用される可能性があるコンピューティング環境の図800を示す。プロトコルは、ブロックチェーン外部のデータに基づいて生成されるプルーフ・オブ・コレクトネスを格納するために、ブロックチェーン技術を使用して実装されてもよい。実施形態では、プルーバー802、データ・ソース804、クライアント806、認証当局808、及びブロックチェーン810は、本開示の他の箇所で説明されるものに従っており、これらの構成要素はコンピューティング・システムとして実装されることが可能である。
【0109】
実施形態では、プルーバー802は実行可能なコードを含むコンピュータ・システムであり、コードは、コンピュータ・システムの1つ以上のプロセッサによって実行されると、コンピュータ・システムにデータ・ソース804からのデータを要求させる。データ・ソース804は、クライアント806と信頼関係を有する任意の適切なコンピューティング・エンティティであるすることが可能である。データは、現実世界のイベント、又は、より一般的にはブロックチェーン上では入手できないデータに関連する可能性がある。要求される可能性のあるデータの例は、特定の日付の航空路線フライトの状況(例えば、遅延、キャンセル、定刻到着など)であってもよい。データ・ソース804は、要求に応じて、要求されたデータを提供することが可能であり、要求は、データグラム、ウェブページ、JSONフォーマットなどの形式で、任意の適切なフォーマットで提供されることが可能である。実施形態では、プルーバーは、データを受信し、データが受信されたと判断したことに応答して、通信のプルーフのための第2要求をデータ・ソース804に提出する。データ・ソース804は、データがデータ・ソースによってプルーバーに提供されたことの暗号的に検証可能な保証を提供する通信のプルーフ812を生成する。通信のプルーフは、データ・ソースのプライベート鍵によってディジタル署名されることが可能であり、ディジタル署名の真正は、データ・ソースに関連付けられたパブリック鍵を使用して検証されてもよい。パブリック鍵を含むディジタル証明は、認証当局808によって発行されてもよい。プルーバー802及びデータ・ソース804は、真正性、完全性、及び機密性の暗号的に検証可能な保証を提供するTLSセッションのような暗号で保護された通信セッション814を介して通信することが可能である。
【0110】
実施形態では、プルーバー802は、スマート・コントラクトの条項をカプセル化するクライアント806から演算回路を受信する。プルーバー802は計算を実行することが可能であり、データの計算は、データ・ソース804から得られるデータに少なくとも部分的に基づいて実行される。プルーバー802は、出力を取得し、ブロックチェーン・ネットワーク810にブロードキャストされて記録される回路の適正実行のプルーフ814を生成し、それによってブロックチェーンのノードがスマート・コントラクトを検証できるようにする。
【0111】
オフ・チェーン・データ(例えば、現実世界のデータ)を含むスマート・コントラクトの実行は、当事者間の異なる信頼度合いに依存する。信頼を獲得するために、プルーバーは、データを生成するために信頼したデータ・ソースとプルーバーとの間で特定のカンバセーションが行われたことを、クライアント(又は、プルーバーが正直かどうかを検証する何らかの他のシステム)に示すことができる。実施形態では、プルーバーは、通信のプルーフ及び演算回路を評価するために使用される入力データを含むレコードを含むマークル・パス(例えば、図7に関連して説明されたようなもの)をクライアントに提供する(818)。クライアントは、マークル・パス及び通信のプルーフを受信し;信頼されるデータ・ソースに関連するパブリック鍵を取得し(例えば、認証当局808からの、データ・ソースのパブリック鍵を含むディジタル証明を要求することによって)、通信のプルーフで生成されるディジタル署名の真正を検証することにより、特定のレコード(又は、レコードのデータ)が、信頼されるデータ・ソースとの通信の一部であったことを検証し(820);マークル・パスからハッシュ出力を生成し;生成されたハッシュ出力が、受信された通信のプルーフと一致することを検証する。このようにして、クライアントは、スマート・コントラクトの入力が信頼されるソースによって提供されたことを判断することができる。
【0112】
実施形態では、クライアントは、本開示の他の箇所で述べられているような方法、及び/又は英国特許出願第171998.5号で述べられている技術を使用して、プルーフ・オブ・コレクトネスを検証する(822)。また、クライアントは評判トランザクションを生成し(824)、これはブロックチェーンに記録され(826)、前述の特定のスマート・コントラクトの実行の遂行において、プルーバーが誠実に行動したかどうかを示すクライアントのレビューをブロックチェーン・ネットワークにブロードキャストすることができる。この文脈では、「正直に」は、プルーバーが、不誠実なエンティティとは異なり、スマート・コントラクトを実行するためにデータ・ソースによって提供されたのと同じデータを使用していることを指す可能性があり、不誠実なエンティティは、スマート・コントラクトを実行するために異なる入力を使用し、それによって、幾つかの実施例ではスマート・コントラクトの実行の結果を別物にしてまう。
【0113】
図9は、図4及び図8に関連して説明される実施形態のような、様々な状況において利用されることが可能な評判トランザクション902の例示的な図900である。実施形態では、評判トランザクションは、プルーバーが正直であるという仮定を伴う一種の事後的なコントラクト実行検証である。このタイプの検証は、実施形態においては、コントラクトの実行に影響を及ぼすものではなく、むしろプルーバーの評判に寄与するメトリックとして利用される。いったんスマート・コントラクトが実行されると、クライアントは、プルーバーを奨励することで、スマート・コントラクト市場のパフォーマンスを向上させるインセンティブにより、プルーバーのサービスを検討する機会を有する。逆に、プルーバーは、彼らがそのように行動するかどうかは、自身の評判や彼らの将来の潜在的なクライアントに直接影響を及ぼすので、正しく行動するようにインセンティブが与えられ、クライアントは彼らの評判(又は評判の欠如)に基づいてプルーバーを選択する可能性がある。
【0114】
実施形態では、クライアント(例えば、図4に関連して説明されるようなもの)は、レビューア904の入力とともにトランザクションを作成する。レビューアの入力は、クライアントのプライベート鍵を使用して署名されたトランザクション入力である可能性がある。一般的に言えば、レビューア入力は、クライアントが評判トランザクションのレビューアであるという公に検証可能な証明を提供する任意の情報であってよい。評判トランザクションは3つの出力を備える。検証906の出力は、パブリック鍵、署名、及びマークル・パスを入力として取る関連するアンロッキング・スクリプトを有する可能性がある。検証時に、マークル・パスは、信頼されたエンティティ(例えば、図4に関連して説明されるデータ・プロバイダ)によって署名され送信されたカンバセーション・プルーフに、レコードが属していることを証明するために使用されることが可能である。一般的に言えば、検証906の出力は、期待される値を生成するために使用可能な認証情報と期待される値とを含むトランザクション出力であり、期待される値はディジタル署名され、ディジタル署名の真正は、上述のように、パブリック鍵を用いて検証可能である。認証情報は、実施形態では、ルート・ハッシュ値を生成するために使用可能なマークル・パスである。第2出力は、クライアントに属するアドレスを含む取り消し908の出力であってもよい。実施形態では、取り消し出力のロック解除は、レビューがキャンセルされるか、又は取り消されることを象徴する。評判トランザクションは、レビュー・メタデータ910を、プルーバーの身元(例えば、プルーバーのアドレス)、プルーバーが実行したスマート・コントラクト、及び肯定的なレビューの指示に関する情報を含む第3トランザクション出力として、レビュー・メタデータ910をエンコードすることも可能である。ビットコイン・ベースの実施形態では、評判メタデータ910は、OP_RETURN出力として実装される。実施形態では、出力は、ディジタル資産の名目上の量(例えば、ダスト値(dust values))を有してもよいし、又は全く値を持たなくてもよい(消費できないOP_RETURN出力の場合である)。ビットコイン・ベースのシステムは、実施形態では、以下に従って実装される評判トランザクションを有する可能性がある:
【表1】
【0115】
OP_CATは2つの文字列を連結するのに相応しい任意のオペコード、ルーチン、コマンド、又はファンクションを指す可能性があることに更に留意すべきである。
【0116】
図10は、通信のプルーフを生成するためのプロセス1000の説明図である。実施形態では、プロセス1000は、ハードウェア、ソフトウェア、又はそれらの組み合わせを使用して実装される。プロセスを実行するために適切なシステムは、図4に関連して説明されたようなデータ・プロバイダを含む。一般的に言えば、プロセス1000を実行するシステムは、スマート・コントラクト又は他の計算タスクの実行を、他のコンピューティング・エンティティに委任するコンピューティング・エンティティによって信頼される任意の適切なシステムであってよい。この文脈において、信頼とは、あるコンピューティング・エンティティが、その信頼されるエンティティから発信された及び/又はそれによってブロードキャストされたデータを、正しいものとして受け入れること、及び/又は、有効なセキュリティ証明とともに、信頼されるソースから公表されたデータは真正かつ正確である、ということを指す可能性がある。
【0117】
実施形態では、プロセス1000を実行するシステムは実行可能なコードを含み、コードは、システムの1つ以上のプロセッサによって実行されると、プルーバーのようなコンピューティング・エンティティとの暗号で保護された通信セッションを、システムに確立させる。クライアントは、スマート・コントラクトの実行で使用されるデータについて信頼できるソースのリストを有する可能性があり、そのリストは(例えば、スマート・コントラクトの一部として、あるいはそれと関連して、あるいはブロックチェーンの他の場所で)公開される可能性がある。暗号で保護された通信セッションの例は、TLSセッションである。
【0118】
システムは、システムと相手方の間の通信の認証を開始するための指示を検出する可能性がある(1004)。指示は、プロトコルの一部として暗黙的に定義される可能性があり、例えば、システムは4ウェイ・ハンドシェイク・プロトコルの完了時に通信の認証を開始する可能性がある。実施形態では、指示は、記録プロトコルによるメッセージとしてシステムによって受信され、メッセージは通信の認証を開始することを示す。認証通信は、2つ以上のコンピューティング・エンティティ間の認証通信及び/又はカンバセーションと言及されてもよいことに留意されたい。通信の認証を開始する指示の一部として、システムは、システムが通信の認証を開始した時間のタイムスタンプを記録してもよい。
【0119】
通信の認証を開始する指示に続いて、システムは、記録プロトコルの一部としてデータを受信及び/又は送信することができ(1006)、通信(又はそこに含まれるデータ)は、データ構造として短期メモリなどの任意の適切なフォーマットで記録される可能性がある。データの受信及び送信に関連して示される積み重なるボックスは、複数のレコードが受信及び送信される可能性があることを示すが、そのことは必須ではなく、一実施形態では単一のレコードが受信及び/又は送信される。
【0120】
実施形態では、システムは、通信の認証を開始する指示を受信した後に、相手との通信の認証を終了する指示を受信する可能性がある(1008)。実施形態では、システムは、認証通信を終了する要求が検出されたときのタイムスタンプを記録する。ある場合には、暗号で保護された通信セッションの終了などによって、終了は暗黙的に検出される。
【0121】
実施形態では、システムは、認証期間中に(即ち、システムが通信の認証を開始して認証を終了するまでの間に)送信及び/又は受信された記録(又はその一部)に基づいて通信のプルーフを生成する(1010)。システムは、図7に関連して説明した方法でマークル・ツリーを生成することによって、通信のプルーフを生成することが可能である。マークル・ツリーのルートは通信のプルーフであるとすることが可能である。実施形態では、通信のプルーフは、認証された通信が発生した時間インターバルをエンコードするマークル・ツリー及びW_timeのルートに基づいて決定される。通信のプルーフは、プライベート鍵を使用してシステムによってディジタル署名されることが可能であり、対応するパブリック鍵は、ディジタル証明を発行する所定の認証当局によりアクセス可能である。実施形態では、システムは、図3図5及び図8に関連して説明されるデータ・プロバイダである。通信のプルーフを生成すると、システムは、通信のプルーフを、セッションの相手(例えば、プルーバー)及び/又は他のエンティティ(例えば、セッション中にプルーバーによって指定されたクライアント)に送信してもよい(1014)。
【0122】
図11は、ブロックチェーン・ネットワークに公開されたスマート・コントラクトのような、認証されたデータを使用してプログラム又はスクリプトを実行するプロセス1100の説明図である。実施形態では、外部データ(例えば、現実世界のイベントに関するデータ)は認証(信頼)されるが、ブロックチェーンから取得可能なデータは認証されない。この文脈で言及されるデータは、スマート・コントラクトで使用される出力を生成するために、演算回路の評価の一部として使用される入力データを指す可能性がある。実施形態では、プロセス1100は、ハードウェア、ソフトウェア、又はそれらの組み合わせを使用して実装される。このプロセスを実行するために相応しいシステムは、図2~4及び8に関連して説明されたもののようなプルーバーを含む。
【0123】
実施形態では、システムは、クライアントに代わってスマート・コントラクトを実行するために、外部データが取得されるべきであると判断する。システムは、データが取得され得る取得元のコンピューティング・エンティティを識別することが可能であり(1102)、コンピューティング・エンティティは、クライアントによって信頼されているエンティティである。クライアントは、スマート・コントラクト又はブロックチェーン上の他の場所における又はそれに関連する信頼されるエンティティのリストを公表することが可能であり、システムは、そこから外部データを取得するために、任意の適切な信頼されるエンティティを選択する。実施形態では、システムは、データ・ソースとの暗号で保護された通信セッションを確立する(1104)。暗号で保護された通信セッションの例は、TLS又はSSLセッションである。
【0124】
実施形態では、システムは、ソースからの外部データを要求し、暗号で保護された通信セッションを介して、データ・ソースからデータを受信する(1106)。外部データは、スマート・コントラクトを取り巻く様々な状況において使用される可能性があり、スマート・コントラクトは、資産及び金融アプリケーション(例えば、金利)に関する市場価格フィードへのアクセスを必要とする証券(例えば、金利、デリバティブ、債券)で使用されるスマート・コントラクト;(例えば、遅延に対して当事者が保険をかけられるフライト情報、農作物保険のための価格インデックスの代わりに、気象データフィードを使用する金融デリバティブ契約の天候データのような)外部データへのアクセスを必要とするピア・ツー・ピア保険スマート・コントラクト;出荷に関するGPSデータを必要とする取引スマート・コントラクト;乱数発生器へのアクセスを必要とするギャンブル・コントラクト等を含むがこれらに限定されない。
【0125】
システムが外部データを受信した後、システムは、暗号で保護された通信セッションの一部として一群の通信が発生したことの第1証明を提供するために、データ・ソースに指示を提供する可能性があり、一群の通信は、システムが信頼されたデータ・ソースから外部データを受信していることを含む。システムは、第1証明を受信することが可能である(1108)。第1証明は、マークル・ツリーのハッシュ・ルートである通信のプルーフであってもよい。第1証明はディジタル署名であってもよく、ディジタル署名の真正は、信頼されるデータ・ソースに関連するパブリック鍵によって検証可能である。
【0126】
実施形態では、システムは、演算回路Cへの入力xとしてデータを使用して証明を生成し(1110)、この回路は、1つ以上の出力yを生成するために2次プログラムを生成するために使用される。実施形態では、システム(例えば、プルーバー)は、入力ワイヤに割り当てられた値はxのものであるように、回路ワイヤに対する値の割り当てである{C,x,y}に対する有効なトランスクリプトを、出力として取得する。また、システムは、演算回路に対する入力として使用されたデータが、信頼されるソースから得られたデータであったことの証明を生成することも可能である。証明は、図6及び7に関連するように、本開示の他の箇所で説明されるようなマークル・パスであってもよい。システムは、スマート・コントラクトの適正実行のプルーフをブロックチェーンにブロードキャストすることができる(1112)。システムは、第2証明(例えば、マークル・パス)、第1証明(即ち、通信のプルーフなどのようなデータ・ソースから受信される証明)、信頼されるエンティティに関連するパブリック鍵、又はそれらの何らかの組み合わせを送信することができる。
【0127】
本開示の文脈において、プレ・イメージ耐性関数は一方向関数を含み、これは、現在の値を求めて計算することは計算上困難ではないかもしれないが、現在の値から前の値を決定するには計算上些細なことではない可能性がある関数を指すことに留意されたい。場合によっては、一方向メンバーシップ関数は、一方向として数学的に証明されてはおらず/証明可能ではないが、それにもかかわらず、関数をプレ・イメージ耐性にする計算が複雑な特性を有する。一方向関数(「有効一方向関数」とも呼ばれる)は:メッセージ認証コード(例えば、ハッシュ・ベースのメッセージ認証コード(HMAC))などの暗号ハッシュ関数、PBKDF2やbcryptなどの鍵派生関数(例えば、パスワードが少なくとも部分的に平文と暗号鍵に基づいているもの)、及び、それらの範囲(可能な出力)よりも大きなドメイン(可能な入力の集合)を有する可能性があるが必ずしもそうではない他の安全なランダム関数を含むが、これらに限定されない。様々な実施形態に適した他の関数は:入力として少なくとも平文及び暗号鍵を受け入れる関数であって、入力をランダムに生成する確率が特定の閾値を下回るようなプレ・イメージ耐性の特性、第2種のプレ・イメージ耐性(入力x1が与えられた場合に、f(x1)=f(x2)であるような異なる入力x2をランダムに生成する確率が特定の閾値を下回るもの)、及び/又は衝突耐性(例えば、同じ出力をもたらす2つの異なる入力の確率が、特定の閾値を下回るもの)を有する関数を含むが、これらに限定されない。
【0128】
図12は、本開示の少なくとも1つの実施形態を実施するために使用されることが可能なコンピューティング・デバイス1200の例示的な簡略化されたブロック図である。様々な実施形態では、コンピューティング・デバイス1200は、上記で説明された任意のシステムを実装するために使用されることが可能である。例えば、コンピューティング・デバイス1200は、データ・サーバー、ウェブ・サーバー、ポータブル・コンピューティング・デバイス、パーソナル・コンピュータ、又は任意の電子コンピューティング・デバイスとして使用するように構成することができる。図12に示されるように、コンピューティング・デバイス1200は、実施形態において、バス・サブシステム1204を介して多数の周辺サブシステムと通信し、かつ動作可能に結合される1つ以上のプロセッサ1202を含むことが可能である。幾つかの実施形態では、これらの周辺サブシステムは、メモリ・サブシステム1208及びファイル/ディスク記憶サブシステム1210と、1つ以上のユーザー・インターフェース入力デバイス1212と、1つ以上のユーザー・インターフェース出力デバイス1214と、ネットワーク・インターフェース・サブシステム1216とを備える記憶サブシステム1206を含む。このような記憶サブシステム1206は、情報の一時的又は長期的な記憶のために使用することができる。
【0129】
幾つかの実施形態では、バス・サブシステム1204は、コンピューティング・デバイス1200の種々の構成要素及びサブシステムが、意図されるように互いに通信することを可能にするメカニズムを提供する。バス・サブシステム1204は、単一のバスとして概略的に示されているが、バス・サブシステムの代替の実施形態は、複数のバスを利用する。幾つかの実施形態では、ネットワーク・インターフェース・サブシステム1216は、他のコンピューティング・デバイス及びネットワークに対するインターフェースを提供する。ネットワーク・インターフェース・サブシステム1216は、幾つかの実施形態では、コンピューティング・デバイス1200からデータを受信し、他のシステムへデータを送信するためのインターフェースとして機能する。幾つかの実施形態では、バス・サブシステム1204は、詳細、検索語などのデータを通信するために利用される。
【0130】
幾つかの実施形態では、ユーザー・インターフェース入力デバイス1212は、キーボード;統合マウス、トラックボール、タッチパッド、又はグラフィックス・タブレットなどのポインティング・デバイス;スキャナ;バーコード・スキャナ;ディスプレイに組み込まれたタッチ・スクリーン;音声認識システム、マイクロ・フォンなどの音声入力デバイス、及びその他の種類の入力デバイスのような1つ以上のユーザー入力デバイス含む。一般に、用語「入力デバイス」の使用は、情報をコンピューティング・デバイス1200に入力するためのあらゆる可能な種類のデバイス及びメカニズムを含むように意図されている。幾つかの実施形態では、1つ以上のユーザー・インターフェース出力デバイス1214は、表示サブシステム、プリンタ、又はオーディオ出力デバイスのような非視覚的ディスプレイなどを含む。幾つかの実施形態では、ディスプレイ・サブシステムは、陰極線管(CRT)、液晶ディスプレイ(LCD)のようなフラットパネル・デバイス、発光ダイオード(LED)ディスプレイ、又は投影その他の表示デバイスを含む。一般に、用語「出力デバイス」の使用は、コンピューティング・デバイス1200から情報を出力するためのあらゆる可能な種類のデバイス及びメカニズムを含むように意図されている。1つ以上のユーザー・インターフェース出力デバイス1214は、例えばユーザー・インターフェースを提示し、説明されたプロセス及びそれらの変形を実行するアプリケーションとのユーザー相互作用を、そのような相互作用が適切である場合に促進するために使用されることが可能である。
【0131】
幾つかの実施形態では、記憶サブシステム1206は、本開示の少なくとも1つの実施形態の機能を提供する基本プログラミング及びデータ構成を記憶するためのコンピュータ読み取り可能な記憶媒体を提供する。アプリケーション(プログラム、コード・モジュール、命令)は、幾つかの実施形態において1つ以上のプロセッサによって実行される場合に、本開示の1つ以上の実施形態の機能を提供し、実施形態では記憶サブシステム1206に記憶される。これらのアプリケーション・モジュール又は命令は、1つ以上のプロセッサ1202によって実行されることが可能である。様々な実施形態では、記憶サブシステム1206は、更に、本開示に従って使用されるデータを記憶するためのリポジトリを提供する。幾つかの実施形態では、記憶サブシステム1206は、メモリ・サブシステム1208及びファイル/ディスク記憶サブシステム1210を含む。
【0132】
実施形態では、メモリ・サブシステム1208は、プログラム実行中に命令及びデータを記憶するためのメイン・ランダム・アクセス・メモリ(RAM)1218、及び/又は固定命令が記憶されることが可能なリード・オンリー・メモリ(ROM)1220などの多数のメモリを含む。幾つかの実施形態では、ファイル/ディスク記憶サブシステム1210は、プログラム及びデータ・ファイルのための非一時的な永続的な(不揮発性の)記憶装置を提供し、ハード・ディスク・ドライブ、関連するリムーバブル媒体を有するフロッピー・ディスク・ドライブ、コンパクト・ディスク・リード・オンリー・メモリ(CD-ROM)ドライブ、光学ドライブ、リムーバブル・メディア・カートリッジ、又は他の同様の記憶媒体を含むことができる。
【0133】
幾つかの実施形態では、コンピューティング・デバイス1200は、少なくとも1つのローカル・クロック1224を含む。幾つかの実施形態では、ローカル・クロック1224は、特定の開始日から発生したティック数を表すカウンタであり、幾つかの実施形態では、コンピューティング・デバイス1200内に一体的に配置される。様々な実施形態では、ローカル・クロック1224は、コンピューティング・デバイス1200のためのプロセッサ及びそこに含まれるサブシステム内のデータ転送を、特定のクロック・パルスで同期させるために使用され、コンピューティング・デバイス1200及びデータ・センター内の他のシステムとの間で同期した動作を調整するために使用されることが可能である。別の実施形態では、ローカル・クロックは、プログラム可能なインターバル・タイマである。
【0134】
コンピューティング・デバイス1200は、ポータブル・コンピュータ・デバイス、タブレット・コンピュータ、ワークステーション、又は以下に説明される他の任意のデバイスを含む、種々の任意の種類のものであるとすることが可能である。更に、コンピューティング・デバイス1200は、幾つかの実施形態では、1つ以上のポート(例えば、USB、ヘッドフォン・ジャック、ライティング・コネクタなど)を介して、コンピューティング・デバイス1200に接続されることが可能な他のデバイスを含むことが可能である。実施形態では、このようなデバイスは、光ファイバ・コネクタを受け入れるポートを含む。従って、幾つかの実施形態では、このデバイスは光信号を電気信号に変換するものであり、電気信号は、処理のために、デバイスを接続するポートを介してコンピューティング・デバイス1200へ伝送される。コンピュータ及びネットワークの絶え間なく変化する性質に起因して、図12に示されるコンピューティング・デバイス1200の説明は、デバイスの好ましい実施形態を説明する目的のための特定の例としてしか意図されていない。図12に示されるシステムより多くの又はより少ない構成要素を有する他の多くの構成も可能である。
【0135】
上述の実施形態は、本発明を限定するものではなく、例示するものであること、及び当業者は、添付の特許請求の範囲によって定義される本発明の範囲から逸脱することなく、多くの代替的な実施形態を設計することが可能であることに留意されたい。特許請求の範囲において、括弧内に置かれる如何なる参照符号も、特許請求の範囲を限定するものとして解釈されないものとする。「備えている」及び「備える」等の言葉は、任意の請求項又は明細書全体において列挙されたもの以外の要素又はステップの存在を除外していない。本明細書において、「備える」は、「含む、又はから構成される」を意味し、「備えている」は「含んでいる、又はから構成されている」を意味する。要素の単独の参照は、そのような要素の複数の参照を除外するものではなく、その逆もまた同様である。本発明は、幾つかの個別的な要素を含むハードウェアによって、及び適切にプログラムされたコンピュータによって実装される可能性がある。幾つかの手段を列挙する装置の請求項において、これらの手段のうちの幾つかは、1つの同一のハードウェア項目によって具体化される可能性がある。特定の複数の事項が相互に異なる従属請求項に記載されているという単なるその事実は、これらの事項の組み合わせが有利に利用できないことを示すものではない。
【0136】
(付記1)
コンピュータで実行される方法であって:
コンピューティング・エンティティとの暗号で保護された通信セッションを確立するステップ;
ブロックチェーン・ネットワークに公開されているプログラムの実行をコントロールする入力データを含むコミュニケーションを、前記暗号で保護された通信セッションで受信するステップ;
前記データを含む一群のコミュニケーションが前記暗号で保護された通信セッションで生じたことの第1証明を受信するステップ;
前記データを利用して前記プログラムを実行するステップであって、前記プログラムの実行は、前記プログラムの適正実行のプルーフの生成をもたらす、ステップ;
受信した前記入力データに少なくとも部分的に基づいて、前記データは前記データ・ソースから受信されたことの第2証明を生成するステップ;及び
前記プログラムの前記適正実行のプルーフを他のコンピュータ・システムに提供するステップ;
を含む、コンピュータで実行される方法。
(付記2)
前記第1証明は、マークル・ツリーのルート・ノードに少なくとも部分的に基づく値を有し、前記マークル・ツリーは、前記一群のコミュニケーション及び一群のソルト値から決定される一群のリーフ・ノードを含む、付記1に記載のコンピュータで実行される方法。
(付記3)
前記一群のコミュニケーションの各コミュニケーションは、前記コミュニケーションが受信されたか又は送信されたかに基づいて決定される対応する中間ノードを含む、付記2に記載のコンピュータで実行される方法。
(付記4)
前記第1証明の値は、少なくとも前記一群のコミュニケーションの時間間隔及び前記マークル・ツリーのルート・ノードから決定される暗号ハッシュ出力に少なくとも部分的に更に基づいている、付記2又は3に記載のコンピュータで実行される方法。
(付記5)
前記第2証明は前記マークル・ツリーのマークル・パスに少なくとも部分的に基づいており、前記マークル・パスは前記マークル・ツリーの一群のノードの値を含み、前記一群のノードの値は前記マークル・ツリーの前記ルート・ノードの値を計算するのに十分である、付記2~4のうちの何れか1項に記載のコンピュータで実行される方法。
(付記6)
前記マークル・パスの前記一群のノードは、前記マークル・ツリーのリーフではなくルートでもない深さで厳密に1つのノードを含む、付記5に記載のコンピュータで実行される方法。
(付記7)
前記プログラムは2人以上の当事者により合意される一群のルールを含み、前記方法は、前記コンピューティング・エンティティを、前記2人以上の当事者のうちの少なくとも1人により信頼される1つ以上のコンピューティング・エンティティから選択するステップを更に含む、付記1~6のうちの何れか1項に記載のコンピュータで実行される方法。
(付記8)
第1ロッキング・スクリプトを含む第1トランザクション・アウトプットと、前記適正実行のプルーフは有効である旨の指示をエンコードする第2トランザクション・アウトプットとを含むブロックチェーン・トランザクションを検出するステップであって、前記第1トランザクション・アウトプットに関連する第1ディジタル資産はアンロッキング・スクリプトによりロック解除可能であり、アンロッキング・スクリプトは:
前記コンピューティング・エンティティに関連するパブリック鍵;
期待される値をエンコードするディジタル署名であって、前記ディジタル署名の真正はパブリック鍵を利用して暗号検証可能である、ディジタル署名;及び
前記期待される値を生成するために使用可能な認証情報;
をエンコードしている、ステップ;及び
少なくとも前記パブリック鍵、前記ディジタル署名、及び前記認証情報を提供することにより、前記第1ディジタル資産をロック解除するステップ;
を更に含む付記1~7のうちの何れか1項に記載のコンピュータで実行される方法。
(付記9)
前記ブロックチェーン・トランザクションは、更に:
前記他のコンピュータ・システムに関連するプライベート鍵を利用してディジタル署名されたトランザクション・インプット;
第2アンロッキング・スクリプトを含む第3トランザクション・アウトプットであって、前記第3トランザクション・アウトプットに関連する第2ディジタル資産は前記プライベート鍵を利用してロック解除可能である、第3トランザクション・アウトプット;
を含み、前記第2トランザクション・アウトプットは、前記他のコンピュータ・システムに関連する識別子を更にエンコードしている、付記8に記載のコンピュータで実行される方法。
(付記10)
前記認証情報はマークル・ツリーのマークル・パスを含み、前記期待される値は前記マークル・ツリーのルート・ノードに少なくとも部分的に基づいている、付記8又は9に記載のコンピュータで実行される方法。
(付記11)
前記データはイベントが生じたか否かを示すバイナリ・データを含む、付記1~10のうちの何れか1項に記載のコンピュータで実行される方法。
(付記12)
前記データは、前記ブロックチェーンにおける他のデータに基づいて検証することはできない情報を含むデータである、付記1~11のうちの何れか1項に記載のコンピュータで実行される方法。
(付記13)
前記第1証明はディジタル署名であり、前記ディジタル署名の真正は前記コンピューティング・エンティティに関連する暗号パブリック鍵を利用して検証可能である、付記1~12のうちの何れか1項に記載のコンピュータで実行される方法。
(付記14)
プロセッサ;及び
実行可能な命令を含むメモリ;
を備えるシステムであって、前記命令は、前記プロセッサにより実行された結果として、付記1~13のうちの何れか1項に記載のコンピュータで実行される方法を前記システムに実行させる、システム。
(付記15)
実行可能な命令を格納した非一時的なコンピュータ読み取り可能な記憶媒体であって、前記命令は、コンピュータ・システムのプロセッサにより実行された結果として、付記1~13のうちの何れか1項に記載のコンピュータで実行される方法を前記コンピュータ・システムに少なくとも実行させる、記憶媒体。
図1
図2
図3
図4
図5
図6
図7
図8
図9
図10
図11
図12