特許 7569602 分散協調を用いるスマートコントラクトの実行

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2024-10-09

(45)【発行日】2024-10-18

(54)【発明の名称】分散協調を用いるスマートコントラクトの実行

(51)【国際特許分類】

   H04L 9/32 20060101AFI20241010BHJP

【ＦＩ】

H04L9/32 200Z

【請求項の数】 10

【外国語出願】

(21)【出願番号】P 2023082663

(22)【出願日】2023-05-19

(62)【分割の表示】P 2020514704の分割

【原出願日】2018-09-14

(65)【公開番号】P2023103434

(43)【公開日】2023-07-26

【審査請求日】2023-05-19

(31)【優先権主張番号】1715423.8

(32)【優先日】2017-09-22

(33)【優先権主張国・地域又は機関】GB

(31)【優先権主張番号】1715701.7

(32)【優先日】2017-09-28

(33)【優先権主張国・地域又は機関】GB

(73)【特許権者】

【識別番号】318001991

【氏名又は名称】エヌチェーン ライセンシング アーゲー

(74)【代理人】

【識別番号】100107766

【弁理士】

【氏名又は名称】伊東 忠重

(74)【代理人】

【識別番号】100070150

【弁理士】

【氏名又は名称】伊東 忠彦

(74)【代理人】

【識別番号】100135079

【弁理士】

【氏名又は名称】宮崎 修

(72)【発明者】

【氏名】フレッチャー，ジョン

(72)【発明者】

【氏名】トレヴェサン，トーマス

【審査官】金沢 史明

(56)【参考文献】

【文献】国際公開第２０１７／１４５０１７（ＷＯ，Ａ１）

【文献】GOLDFEDER, Steven et al.，Escrow Protocols for Cryptocurrencies: How to Buy Physical Goods Using Bitcoin, [online]，2017年06月06日，pp. 1-27，[2022年8月23日検索], インターネット＜URL：https://web.archive.org/web/20170606025204/http://stevengoldfeder.com/papers/escrow.pdf＞

【文献】ZIEGELDORF, J. H. et al.，CoinParty: Secure Multi-Party Mixing of Bitcoins，2015年03月02日，pp.75-86，<DOI:http://dx.doi.org/10.1145/2699026.2699100>

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｈ０４Ｌ ９／０８， ９／３２

Ｇ０６Ｆ ２１／６４

Ｇ０９Ｃ １／００

(57)【特許請求の範囲】

【請求項1】

コンピュータにより実施される方法であって、
取引先の間で条件セットを決定するステップであって、前記条件セットは、以下：
デジタルアセットの第１分配に関連付けられた第１の可能な成り行き、及び、
第１分配と異なる、前記デジタルアセットの第２分配に関連付けられた第２の可能な成り行き、
を含む複数の可能な成り行きを有する、ステップと、
アウトプットとして、コンピュータ実行可能命令に符号化された前記条件セット及び前記デジタルアセットを含む取引先トランザクションを生成するステップと、
第三者から成り行きを受信するステップであって、前記成り行きは前記第１の可能な成り行き又は前記第２の可能な成り行きに対応する、ステップと、
前記取引先トランザクションの前記デジタルアセットの制御を移転するために成り行きトランザクションを生成するステップであって、前記成り行きトランザクションはインプットとして前記成り行きを含む、ステップと、
ブロックチェーンネットワーク内のノードにおいて前記成り行きトランザクションを検証した結果として、前記第１の可能な成り行き又は前記第２の可能な成り行きに従い、前記成り行きに少なくとも部分的に基づき、前記デジタルアセットを前記取引先に分配するステップと、
を含み、
前記方法は、
前記第三者から、前記複数の可能な成り行きに対応する複数の成り行き鍵を受信するステップであって、前記成り行きは前記複数の成り行き鍵のうちの１つに対応する暗号鍵である、ステップと、
前記取引先により決定されたシークレット値を、前記複数の成り行き鍵の各々と結合して、複数の難読化された成り行き鍵を生成するステップと、
前記複数の難読化された成り行き鍵を更に含むよう前記取引先トランザクションを生成するステップと、
前記成り行きトランザクションを検証するステップであって、
前記暗号鍵を前記シークレット値と結合して、成り行き署名鍵を生成するステップと、
前記複数の難読化された成り行き鍵のうちのどれが前記成り行き署名鍵に関連付けられるかに少なくとも部分的に基づき、前記取引先に前記デジタルアセットを分配するステップと、を含むステップと、
を更に含む、コンピュータにより実施される方法。

【請求項2】

前記第三者は、複数のメンバを含むグループである、請求項１に記載のコンピュータにより実施される方法。

【請求項3】

前記成り行きは、前記複数のメンバにより提出された回答の合意の結果である、請求項２に記載のコンピュータにより実施される方法。

【請求項4】

前記複数のメンバを含むメンバの数、及び、前記成り行きを決定するための閾数、を決定するステップ、を更に含み、
前記成り行きは、前記複数のメンバのうちの少なくとも前記閾数により提出された回答に一致する、請求項２に記載のコンピュータにより実施される方法。

【請求項5】

前記成り行きは、前記複数のメンバのうちの少なくとも前記閾数により提出された前記回答に対応する前記閾数の鍵シェアがコミットされるまで、秘密に保たれ、前記鍵シェアは、秘密分散方式に従い決定される、請求項４に記載のコンピュータにより実施される方法。

【請求項6】

前記鍵シェアは、前記複数のメンバによりproof-of-stakeブロックチェーン内のブロックにコミットされる間、秘密に保たれる、請求項５に記載のコンピュータにより実施される方法。

【請求項7】

取引先の間で条件セットを決定するステップは、前記デジタルアセットに、前記取引先のうちの第１パーティにより出資された、前記デジタルアセットの第１の量と、前記取引先のうちの第２パーティにより出資された、前記デジタルアセットの第２の量と、を含めるステップを含む、請求項１乃至６のいずれか一項に記載のコンピュータにより実施される方法。

【請求項8】

前記複数の可能な成り行きのうちの１つは、前記条件セットの期限条件に関連付けられ、
さらに、前記成り行きトランザクションを検証した結果として及び前記期限条件の発生の結果として、前記第１の量を前記第１パーティに、及び前記第２の量を前記第２パーティに、返金するステップ、を更に含む請求項７に記載のコンピュータにより実施される方法。

【請求項9】

システムであって、
プロセッサと、
前記プロセッサによる実行の結果として、前記システムに請求項１乃至８のいずれか一項に記載のコンピュータにより実施される方法を実行させる実行可能命令を含むメモリと、
を含むシステム。

【請求項10】

実行可能命令を記憶した非一時的コンピュータ可読記憶媒体であって、前記実行可能命令は、コンピュータシステムのプロセッサにより実行された結果として、少なくとも、前記コンピュータシステムに、請求項１乃至８のいずれか一項に記載のコンピュータにより実施される方法を実行させる、非一時的コンピュータ可読記憶媒体。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、概して、ブロックチェーン技術に関し、より詳細には、ディーラ不要の秘密分散と楕円曲線演算及び署名の特性との組み合わせを用いるスマートコントラクトに基づくブロックチェーンの実行を制御することに関する。本発明は、さらに、暗号化及数学的技術を利用して、ブロックチェーンネットワークを介して行われる電子的移転に関連してセキュリティを実施する。本発明は、特に、スマートコントラクトにおける使用に適するが、これに限定されない。

【背景技術】

【0002】

本明細書では、用語「ブロックチェーン」は、電子的な、コンピュータに基づく、分散台帳の幾つかの種類のうちの任意のものを表してよい。これらは、総意に基づくブロックチェーン及びトランザクションチェーン技術、許可及び未許可台帳、共有台帳、並びにこれらの変形を含む。最も広く知られている、ブロックチェーン技術の用途は、ビットコイン（Bitcoin）台帳であるが、他のブロックチェーン実装も提案され開発されている。Bitcoinの例は便宜上及び説明の目的で、本開示に記載される技術の有用な用途として言及されることがあるが、Bitcoinは、本開示に記載の技術が適用され得る多数の用途のうちのほんの１つである。しかしながら、留意すべきことに、本発明は、Bitcoinブロックチェーンと共に使用することに限定されず、非商用用途を含む代替（alternative）ブロックチェーン実装及びプロトコルも、本発明の範囲に含まれる。例えば、本開示に記載の技術は、暗号通貨の交換が生じるか否かに関わらず、どんな制約がトランザクションの中で施行できるかに関連するBitcoinと同様の制限を有するブロックチェーン実装を利用するという利点を提供し得る。

【0003】

ブロックチェーンは、コンピュータに基づく非集中型の分散システムとして実装されるピアツーピア電子台帳である。この台帳は、ブロックで構成され、ブロックは、トランザクション及び他の情報で構成されてよい。幾つかの例では、「ブロックチェーントランザクション」は、データ及び条件セットを含むフィールド値の構造化された集合を符号化するインプットメッセージを表す。ここで、条件セットの充足は、フィールドのセットがブロックチェーンデータ構造に書き込まれるための必要条件である。例えば、Bitcoinでは、各トランザクションは、ブロックチェーンシステムの参加者間でのデジタルアセットの制御の移転を符号化するデータ構造であり、少なくとも１つのインプット及び少なくとも１つのアウトプットを含む。幾つかの実施形態では、「デジタルアセット」は、使用する権利に関連付けられたバイナリデータを表す。デジタルアセットの例は、Bitcoin、Ether、及びLitecoinsを含む。幾つかの実装では、デジタルアセットの制御を移転することは、デジタルアセットの少なくとも一部を第１エンティティから第２エンティティに再関連付けすることにより、実行できる。各ブロックは、前のブロックのハッシュを含む。その結果、ブロックは、一緒に繋げられ（chained）、ブロックチェーンの発端以来ブロックチェーンに書き込まれている全てのトランザクションの永久の不変レコードを生成する。トランザクションは、スクリプトとして知られる小さなプログラムを含む。スクリプトは、トランザクションのアウトプットがどのように及び誰によりアクセス可能かを指定する、インプット及びアウトプットを埋め込まれる。Bitcoinプラットフォームでは、これらのスクリプトは、スタックに基づくスクリプト言語を用いて記述される。

【0004】

幾つかの例では、「スタックに基づくスクリプト言語」は、種々のスタックに基づく又はスタック指向の実行モデル及び演算をサポートするプログラミング言語を表す。つまり、スタックに基づくスクリプト言語は、スタックを利用してよい。スタックにより、値は、スタックの一番上にプッシュされ、又はスタックの一番上からポップされ得る。スタックに実行される種々の演算は、値のうちの１つ以上をスタックの一番上にプッシュし又はそこからポップすることをもたらし得る。例えば、OP_EQUAL演算は、上位２個のアイテムをスタックからポップし、それらを比較し、結果（例えば、等しい場合に１、等しくない場合に０）をスタックの一番上にプッシュする。OP_PICKのような、スタックに実行される他の演算は、アイテムがスタックの一番上以外の位置から選択されることを可能し得る。本発明の実施形態のうちの幾つかにより利用される幾つかのスクリプト言語では、少なくとも２つのスタック、つまりメインスタックとオルト（alternate）スタックが存在してよい。スクリプト言語の幾つかの演算は、一方のスタックの一番上からもう一方のスタックの一番上へとアイテムを移動できる。例えば、OP_TOALTSTACKは、メインスタックの一番上からオルトスタックの一番上へと値を移動する。留意すべきことに、スタックに基づくスクリプト言語は、幾つかの場合には、単に厳密な後入れ先出し（last-in-first-out，LIFO）方法に限定されないことがある。例えば、スタックに基づくスクリプト言語は、スタックの中のn番目のアイテムを一番上にコピーする又は移動する演算をサポートしてよい（例えば、BitcoinではそれぞれOP_PICK及びOP_ROLL）。スタックに基づくスクリプト言語で記述されたスクリプトは、ベクトル、リスト、又はスタックのような任意の適切なデータ構造を用いて実装可能な論理スタックにプッシュされてよい。

【0005】

トランザクションがブロックチェーンに書き込まれるためには、「検証」されなければならない。ネットワークノード（マイニングノード）は、無効なトランザクションがネットワークから拒否され、各トランザクションが有効であることを保証するために作業を実行する。ノードは、他のノードと異なる有効性のための基準を有し得る。ブロックチェーンにおける有効性は総意に基づくので、トランザクションは、トランザクションが有効であることにノードの大多数が合意した場合に、有効であると考えられる。ノードにインストールされたソフトウェアクライアントは、未使用トランザクション（unspent transaction, UTXO）ロック及びアンロックスクリプトを実行することにより、UTXOを参照するトランザクションに対してこの検証作業を実行する。ロック及びアンロックスクリプトの実行がTUREと評価し、適用可能ならば他の検証条件が満たされた場合、トランザクションは、ノードにより検証される。検証されたトランザクションが、他のネットワークノードへと伝搬されると、マイニングノードは、ブロックチェーンにトランザクションを含むことを選択できる。したがって、トランザクションがブロックチェーンに書き込まれるためには、トランザクションは、（ｉ）トランザクションを受信した最初のノードにより検証され、トランザクションが検証された場合、該ノードは該トランザクションをネットワーク内の他のノードへ中継し、(ii)マイニングノードにより構築された新しいブロックに追加され、(iii)マイニングされ、つまり過去のトランザクションの公開台帳に追加されなければならない。トランザクションは、実際に取り消し不可能なトランザクションを作成するために十分な数のブロックがブロックチェーンに追加されると、承認されたと考えられる。

【0006】

ブロックチェーン技術は、暗号通貨の実装の使用のために最も広く知られているが、デジタル事業家が、Bitcoinの基づく暗号セキュリティシステム及び新しいシステムを実装するためにブロックチェーンに格納できるデータの両方の使用を開発し始めている。ブロックチェーンが、暗号通貨の分野に限定されない自動化タスク及びプロセスのために使用できれば、非常に有利になる。このようなソリューションは、ブロックチェーンの利益（例えば、永久性、イベントの記録の耐タンパ性、分散型処理、等）を利用しながら、それらの用途をより多様化し得る。

【0007】

本開示は、１つ以上のブロックチェーンに基づくコンピュータプログラムの技術的態様を記載する。ブロックチェーンに基づくコンピュータプログラムは、ブロックチェーントランザクション内に記録される機械可読及び実行可能プログラムである。ブロックチェーンに基づくコンピュータプログラムは、結果を生成し、次に該結果に依存してアクションを実行させるためにインプットを処理できるルールを含む。現在の研究の一分野は、「スマートコントラクト」の実装のためのブロックチェーンに基づくコンピュータプログラムの使用である。自然言語で記述され得る伝統的な契約と異なり、スマートコントラクトは、機械可読の契約又は同意の条項の実行を自動化するよう設計されたコンピュータプログラムであってよい。

【0008】

実施形態では、特定のエンティティとの相互作用がスマートコントラクト内の特定のステップで符号化され得るが、その他の場合に、スマートコントラクトは、自動的に及び自己実行され得る。それは、機械可読及び実行可能である。幾つかの例では、自動実行は、UTXOの移転を可能にするために成功裏に実行されるスマートコントラクトの実行を表す。このような例では。UTXOの移転を生じることのできる「エンティティ」は、何らかのシークレットの知識の提供を要求さることなく、アンロックスクリプトを生成できるエンティティを表す。言い換えると、アンロックトランザクションは、データのソース（例えば、アンロックトランザクションを生成したエンティティ）が暗号シークレット（例えば、秘密非対称鍵、対称鍵、等）へのアクセスを有することを検証することなく、検証可能である。また、このような例では、自己執行は、ブロックチェーンネットワークの検証ノードに、制約に従いアンロックトランザクションを執行させることを表す。幾つかの例では、UTXOを「アンロック」すること（UTXOを「使用」することとしても知られる）は、技術的な意味で使用され、UTXOを参照するアンロックトランザクションを生成することを表し、有効であるとして実行する。

【0009】

ブロックチェーントランザクションアウトプットは、ロックスクリプトと、Bitcoinのようなデジタルアセットの所有権に関する情報と、を含む。ロックスクリプトは、債務（encumbrance）とも呼ばれることがあり、UTXOを移転するために充足されることが要求される条件を指定することにより、デジタルアセットを「ロック」する。例えば、ロックスクリプトは、関連付けられたデジタルアセットをアンロックするために、特定のデータがアンロックスクリプト内で提供されることを要求し得る。ロックスクリプトは、Bitcoinでは「scriptPubKey」としても知られる。デジタルアセットをアンロックするためのデータを提供するようパーティに要求する技術は、ロックスクリプト内にデータのハッシュを埋め込むことを含む。しかしながら、これは、ロックスクリプトが生成されるときにデータが未定である（例えば、分からない、固定されない）場合に、問題を生じる。

【0010】

本発明は、検証方法／システムとして、及び／又はブロックチェーントランザクションの検証を制御する制御方法／システムとして、記載され得る。幾つかの実施形態では、検証されたブロックチェーントランザクションは、トランザクションのブロックチェーン上への記録を生じる。これは、幾つかの用途では、ブロックチェーンを介するデジタルアセットの交換又は移転を生じ得る。デジタルアセットは、ブロックチェーンにより管理されるリソースの単位であってよい。デジタルアセットは、幾つかの実施形態では、暗号通貨として使用されてよいが、実施形態において、追加または代替として、デジタルアセットは他の文脈で使用可能である。本発明は、デジタルアセットの制御に適用可能であるが、本来技術的であり、必ずしもデジタルアセットの移転を含まないブロックチェーンデータ構造を利用する他の文脈で使用可能である。

【発明の概要】

【0011】

したがって、上述の態様のうちの１つ以上において、ブロックチェーン技術を向上する方法及びシステムを提供することが望ましい。このような改良されたソリューションがここで考案される。したがって、本発明によると、添付の請求項において定められる方法が提供される。

【0012】

したがって、コンピュータにより実施される方法であって、
取引先の間でスマートコントラクトを決定するステップであって、前記条件セットは、以下：
デジタルアセットの第１分配に関連付けられた第１の可能な成り行き、及び、
第１分配と異なる、前記デジタルアセットの第２分配に関連付けられた第２の可能な成り行き、
を含む複数の可能な成り行きを有する、ステップと、
アウトプットとして、コンピュータ実行可能命令に符号化された前記条件セット及び前記デジタルアセットを含む取引先トランザクションを生成するステップと、
第三者から成り行きを受信するステップであって、前記成り行きは前記第１の可能な成り行き又は前記第２の可能な成り行きに対応する、ステップと、
前記取引先トランザクションの前記デジタルアセットの制御を移転するために成り行きトランザクションを生成するステップであって、前記成り行きトランザクションはインプットとして前記成り行きを含む、ステップと、
ブロックチェーンネットワーク内のノードにおいて前記成り行きトランザクションを検証した結果として、前記第１の可能な成り行き又は前記第２の可能な成り行きに従い、前記成り行きに少なくとも部分的に基づき、前記デジタルアセットを前記取引先に分配するステップと、
を含むコンピュータにより実施される方法を提供することが望ましい。

【0013】

第三者は、複数のメンバを含むグループであってよい。

【0014】

成り行きは、複数のメンバにより提供された回答の合意の結果であってよい。

【0015】

複数のメンバを含むメンバの数が決定されてよい。追加又は代替として、成り行きを決定するための閾数が決定されてよい。成り行きは、複数のメンバのうちの少なくとも閾数により提出された回答が一致することであってよい。

【0016】

成り行きは、複数のメンバにより提出された鍵シェアに少なくとも部分的に基づき決定されてよい。追加又は代替として、鍵シェアは、秘密分散方式に従い決定されてよい。

【0017】

鍵シェアは、複数のメンバにより、proof-of-stakeブロックチェーン内のブロックにコミットされてよい。

【0018】

第２デジタルアセットに関連付けられた少なくとも１つの協調アルゴリズムトランザクションが生成されてよい。追加又は代替として、第２デジタルアセットの制御を移転するために生成された分配トランザクションを検証した結果として、第２デジタルアセットは、第三者に分配されてよい。

【0019】

第２デジタルアセットは、第三者により出資されたデポジット部分を含んでよい。

【0020】

追加又は代替として、第２デジタルアセットは、取引先により出資された分配部分を含んでよい。

【0021】

複数のメンバは、回答が合意に一致しないメンバを含んでよい。追加又は代替として、回答が回答の合意に一致しないことの結果として、第２デジタルアセットの分配は、メンバが分配部分を受信することを除外してよい。

【0022】

前記デジタルアセットは、第１パーティにより出資された、前記デジタルアセットの第１の量と、第２パーティにより出資された、前記デジタルアセットの第２の量と、を含んでよい。

【0023】

複数の可能な成り行きのうちの１つは、条件セットの期限条件に関連付けられてよい。追加又は代替として、さらに、成り行きトランザクションを検証した結果として及び期限条件の発生の結果として、第１の量は第１パーティに返金されてよい。追加又は代替として、さらに、成り行きトランザクションを検証した結果として及び期限条件の発生の結果として、第２の量は第２パーティに返金されてよい。

【0024】

複数の可能な成り行きに対応する複数の秘密成り行き鍵が、第三者から受信されてよい。追加又は代替として、可能な成り行きは、複数の秘密成り行き鍵のうちの１つに対応する暗号鍵であってよい。取引先により決定された秘密値は、複数の成り行き秘密鍵の各々と結合されて、複数の難読化された可能な成り行き鍵を生成してよい。取引先トランザクションは、複数の難読化された秘密鍵を更に含むよう生成されてよい。成り行きトランザクションを検証するステップは、暗号鍵を秘密値と結合して、可能な成り行き署名鍵を生成するステップを含んでよい。追加又は代替として、成り行きトランザクションを検証するステップは、複数の難読化された秘密鍵のうちのどれが可能な成り行き署名鍵に関連付けられるかに少なくとも部分的に基づき、デジタルアセットを取引先に分配するステップを含んでよい。

【0025】

したがって、さらに、コンピュータにより実施される方法であって、
取引先のセットに、条件セットの成り行きを決定することに対する同意を通信するステップであって、条件セットは、第１の可能な成り行きと第２の可能な成り行きとを含む、ステップと、
秘密分散方式を用いて、第１の可能な成り行きに対応する第１秘密鍵シェアと第２の可能な成り行きに対応する第２秘密鍵シェアとを生成するステップと、
デジタルアセットの量を、第１ブロックチェーントランザクションに関連付けられたアドレスに移転するステップと、
成り行きが第１の可能な成り行きであると決定した結果として、特定時間枠内で、第１秘密鍵シェアを開示するステップであって、第１秘密鍵シェアは少なくとも部分的に、取引先のセットにより成り行きを決定するために使用可能である、ステップと、
第１秘密鍵シェアに少なくとも部分的に基づき、第１ブロックチェーントランザクションに関連付けられたデジタルアセットの量を使用するために第２ブロックチェーントランザクションに対して少なくとも部分的に使用可能な署名を生成するステップと、
デジタルアセットの量の制御を得るために、第２ブロックチェーントランザクションをブロックチェーンネットワーク内のノードにおいて検証させるステップと、を含む方法を提供することが望ましい。

【0026】

また、コンピュータにより実施される方法であって、
取引先のセットに、条件セットの成り行きを決定することに対する同意を通信するステップであって、条件セットは、第１の可能な成り行きと第２の可能な成り行きとを含む、ステップと、
秘密分散方式を用いて、第１の可能な成り行きに対応する第１秘密鍵シェアと第２の可能な成り行きに対応する第２秘密鍵シェアとを生成するステップと、
デジタルアセットの量を、第１ブロックチェーントランザクションに関連付けられたアドレスに移転するステップと、
成り行きが第１の可能な成り行きであると決定した結果として、特定時間枠内で、第１秘密鍵シェアを開示するステップであって、第１秘密鍵シェアは少なくとも部分的に、取引先のセットにより成り行きを決定するために使用可能である、ステップと、
第１秘密鍵シェアに少なくとも部分的に基づき、第１ブロックチェーントランザクションに関連付けられたデジタルアセットの量をアンロックするために第２ブロックチェーントランザクションに対して少なくとも部分的に使用可能な署名を生成するステップと、
第２ブロックチェーントランザクションをブロックチェーンネットワーク内のノードにおいて検証させるステップと、を含む方法を提供することが望ましい。

【0027】

第１の可能な成り行きに関連付けられた第１公開鍵、及び第２の可能な成り行きに関連付けられた第２公開鍵が、生成されてよい。追加又は代替として、第１公開鍵及び第２公開鍵は、取引先のセットに提供されてよい。追加又は代替として、第１秘密鍵シェアは、少なくとも部分的に第１秘密鍵シェアを用いて、第１秘密鍵を生成することにより、成り行きを決定するために使用可能であってよい。追加又は代替として、第１秘密鍵シェアは、第１秘密鍵が第１公開鍵に関連付けられていることを決定することにより、成り行きを決定するために使用可能であってよい。

【0028】

秘密分散プロトコルは、ディーラ不要の秘密分散プロトコルであってよい。

【0029】

第１秘密鍵シェアを開示するステップは、第３ブロックチェーントランザクションの中で第１秘密鍵シェアを開示するステップを含んでよい。

【0030】

第３ブロックチェーントランザクションは、proof-of-stakeブロックチェーン内のトランザクションであってよい。

【0031】

特定時間枠は、第２時間枠であってよい。追加又は代替として、第１秘密鍵シェアを開示するステップは、第２時間枠の前の第１時間枠内で、コミットトランザクションの中で第１秘密鍵シェアの暗号ハッシュをコミットするステップを更に含んでよい。追加又は代替として、第３ブロックチェーントランザクションを検証するステップは、第３ブロックチェーントランザクションの中の第１秘密鍵シェアがコミットトランザクションの中の暗号ハッシュに対応することを決定するステップを含んでよい。

【0032】

第１ブロックチェーントランザクションは、取引先のセットのうちのサブセットから移転された第２デジタルアセットの第２の量を更に含んでよい。追加又は代替として、第２デジタルアセットの第２の量の制御は、さらに、第２ブロックチェーントランザクションを検証させるステップの結果として、移転されてよい。

【0033】

第１ブロックチェーントランザクションは、期限条件を更に含んでよい。追加又は代替として、期限条件が満たされた結果として、第２ブロックチェーントランザクションを検証させるステップは、第２デジタルアセットの第２の量の制御を、取引先のセットのうちのサブセットに移転してよい。

【0034】

第２ブロックチェーントランザクションの検証は、グループ暗号鍵を用いて生成されたデジタル署名を検証するステップを含んでよく、グループ暗号鍵は、成り行きを決定することに同意した取引先のグループに関連付けられる。

【0035】

取引先のグループは、第１の可能な成り行きに対応する鍵シェアを開示する取引先の第１サブセットを含んでよい。追加又は代替として、取引先のグループは、第２の可能な成り行きに対応する鍵シェアを開示する取引先の第２サブセットを含んでよい。追加又は代替として、第２の量の制御を移転するステップは、第２の量の制御を、取引先の第２サブセットを除く取引先の第１サブセットに移転するステップを含んでよい。

【0036】

取引先のグループに関連付けられたグループ公開鍵が生成されてよい。追加又は代替として、グループ公開鍵は、取引先のセットに提供されてよい。追加又は代替として、第１ブロックチェーントランザクションは、少なくとも部分的に、グループ公開鍵を用いて生成されてよい。追加又は代替として、第２ブロックチェーントランザクションの検証はグループ暗号鍵が第１ブロックチェーントランザクションのグループ公開鍵に関連付けられていることを決定するステップを含んでよい。

【0037】

グループ秘密鍵シェアは、秘密分散プロトコルを用いて生成されてよい。追加又は代替として、さらに成り行きを決定した結果として、グループ暗号鍵は、グループ秘密鍵シェアに少なくとも部分的に基づき生成されてよい。

【0038】

第１秘密鍵シェアは、取引先のグループの間で分配された複数の第１秘密鍵シェアに属してよい。追加又は代替として、第１秘密鍵シェアは、第１の可能な成り行きに対応してよい。追加又は代替として、成り行きが第１の可能な成り行きになることを決定するステップは、複数の第１秘密鍵シェアのうちの閾数が取引先のグループにより開示されていることを決定するステップを含んでよい。

【0039】

また、システムであって、
プロセッサと、
プロセッサによる実行の結果として、システムに請求項のいずれかに記載の方法を実行させる実行可能命令を含むメモリと、
を含むシステムを提供することが望ましい。

【0040】

また、実行可能命令を記憶した非一時的コンピュータ可読記憶媒体であって、コンピュータシステムの１つ以上のプロセッサによる実行の結果として、コンピュータシステムに請求項のいずれかに記載の方法を実行させる、非一時的コンピュータ可読記憶媒体を提供することが望ましい。

【0041】

本発明は、検証方法／システムとして、及び／又はブロックチェーンを介してデジタルアセットの交換または移転を制御する制御方法／システムとして、記載され得る。幾つかの実施形態では、デジタルアセットは、トークン又は暗号通貨の一部である。いかに説明するように、本発明は、ブロックチェーンネットワークまたはプラットフォームを介して動作を実行する新しい改良された有利な方法のためのセキュア方法／システムとしても記載され得る。

【図面の簡単な説明】

【0042】

本発明の上述の及び他の態様は、本願明細書に記載の実施形態から明らかであり、及びそれを参照して教示される。本発明の実施形態は、単に例として、以下の添付の図面を参照して、以下に記載される。

【図1】種々の実施形態が実施できるブロックチェーン環境を示す。

【図2】一実施形態による、スマートコントラクトの一例を示す。

【図3】一実施形態による、スマートコントラクトを設定する一例を示す。

【図4】一実施形態による、成り行き決定を協調する一例を示す。

【図5】一実施形態による、スマートコントラクト実行の一例を示す。

【図6】一実施形態による、スマートコントラクト及び協調アルゴリズムトランザクションを生成する一例を示す流れ図である。

【図7】一実施形態による、スマートコントラクトを実行する一例を示す流れ図である。

【図8】種々の実施形態が実施できるコンピューティング環境を示す。

【発明を実施するための形態】

【0043】

図１を参照すると、図１は、本開示の一実施形態による、ブロックチェーンに関連付けられた例示的なブロックチェーンネットワーク１００を示す。本実施形態では、例示的なブロックチェーンネットワーク１００は、ブロックチェーンノードを含む。ブロックチェーンノードは、ピアツーピア分散型電子装置として実装され、それぞれが、ブロックチェーンプロトコルに従う、つまり少なくとも部分的にノード１０２のオペレータの間で合意された、動作を実行するソフトウェア及び／又はハードウェアのインスタンスを実行する。幾つかの例では、「ノード」は、ブロックチェーンネットワークの中で分散されたピアツーピア電子装置を表す。ブロックチェーンプロトコルの一例はBitcoinプロトコルである。

【0044】

幾つかの実施形態では、ノード１０２は、任意の適切なコンピューティング装置（例えば、データセンタのサーバによる、クライアントコンピューティング装置（例えば、デスクトップコンピュータ、ラップトップコンピュータ、タブレットコンピュータ、スマートフォン、等）による、コンピューティングリソースサービスプロバイダの分散型システムの中の複数のコンピューティング装置による、又は図８のコンピューティング装置８００のような任意の適切なクライアント装置による）で構成できる。幾つかの実施形態では、ノード１０２は、データメッセージ又は提案されたトランザクション、例えばトランザクション１０４を表すオブジェクトを受信するための入力を有する。幾つかの実施形態では、ノードは、該ノードの維持する情報について、例えばトランザクション１０４の状態の情報について、クエリされることが可能である。

【0045】

図１に示すように、ノード１０２のうちの幾つかは、ノード１０２のうちの他の１つ以上と通信可能に結合される。このような通信可能な結合は、有線又は無線通信のうちの１つ以上を含み得る。本実施形態では、ノード１０２は、それぞれ、ブロックチェーンの中の全てのトランザクションの「台帳」の少なくとも一部を維持する。この方法では、台帳は分散型台帳である。台帳に影響を与えるノードにより処理されたトランザクションは、他のノードのうちの１つ以上により検証可能であり、その結果、台帳の完全性が維持される。

【0046】

どのノード１０２が他のどのノードと通信できるかについては、例示的なブロックチェーンネットワーク１００内のノードの各々が、１つ以上の他のノード１０２と通信できれば十分である。その結果、メッセージが転送されるべきであるとブロックチェーンプロトコルが示す場合に、ノード間で渡されるメッセージは、例示的なブロックチェーンネットワーク１００（又はその何らかの意味のある部分）を通じて伝搬できる。１つのこのようなメッセージは、ノード１０２のうちの１つ、例えばノード１０２Ａにより提案されたトランザクションの発行であってよい。該トランザクションは、次に、パス１０６のようなパスに沿って伝搬してよい。別のこのようなメッセージは、ブロックチェーンに包含されるために提案された新しいブロックの発行であってよい。

【0047】

一実施形態では、ノードのうちの少なくとも幾つかは、複雑な計算、例えば暗号化問題を解くこと、を実行するマイニングノードである。暗号化問題を解くマイニングノードは、ブロックチェーンの新しいブロックを生成し、新しいブロックを他のノード１０２へとブロードキャストする。他のノード１０２は、マイニングノードの作業を検証し、検証すると、（例えば、ブロックをブロックチェーンの分散型台帳に追加することにより）ブロックをブロックチェーンの中へと受け入れる。幾つかの例では、ブロックは、トランザクションのグループであり、タイムスタンプ及び前のブロックの「指紋」（例えばハッシュ）によりマークされることがある。この方法では、各ブロックは、前のブロックにリンクされるようになり、それにより、ブロックチェーン内のブロックをリンクする「チェーン」を生成する。実施形態では、有効なブロックは、ノード１０２の合意によりブロックチェーンに追加される。また、幾つかの例では、ブロックチェーンは、検証されたブロックのリストを含む。

【0048】

一実施形態では、ノード１０２のうちの少なくとも幾つかは、本開示に記載のようにトランザクションを検証する検証ノードとして動作する。幾つかの例では、トランザクションは、デジタルアセット（例えば、Bitcoinの数量）の所有権の証明、及びデジタルアセットの所有権／制御を受け付ける又は移転するための条件を提供するデータを含む。幾つかの例では、「アンロックトランザクション」は、前のトランザクションの未使用UTXOにより示されたデジタルアセットの少なくとも一部を、ブロックチェーンアドレスに関連付けられたエンティティに再関連付けする（例えば、所有権又は制御を移転する）ブロックチェーントランザクションを表す。幾つかの例では、「前のトランザクション」は、アンロックトランザクションにより参照されているUTXOを含むブロックチェーントランザクションを表す。幾つかの実施形態では、トランザクションは、所有権／制御が移転可能になる（「アンロックされる」）前に満たされなければならない条件により、トランザクションを妨げる「ロックスクリプト」を含む。

【0049】

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

【0050】

本開示において言及される演算コードの例は以下を含む。
・OP_CHECKSIG。公開鍵及び署名が、スタックからポップされ、SIGHASHタイプに従いトランザクションフィールドの署名に対して検証される。署名が有効な場合、１が返され、その他の場合に０が返される。
・OP_DUP。一番上のスタックアイテムを複製する。
・OP_ELSE。先行するOP_IF又はOP_NOTIF又はOP_ELSEが実行されなかった場合に、これらのステートメントが実行され、その他の場合に、先行するOP_IF又はOP_NOTIF又はOP_ELSEが実行された場合に、これらのステートメントが実行されない。
・OP_ENDIF。if/elseブロックを終了する。
・OP_IF。一番上のスタック値がFalseではない場合、ステートメントが実行され、一番上のスタック値が除去される。
・OP_CHECKMULTISIG。一致が見つかるまで、第１署名を各々の公開鍵と比較する。次に、次の公開鍵により、一致が見つかるまで、第２署名を各々の残りの公開鍵と比較する。この処理は、全ての署名がチェックされるまで、繰り返される。署名が有効な場合、１が返され、その他の場合に０が返される。
・OP_CHECKLOCKTIMEVERIFY。一番上のスタックアイテムがトランザクションnLockTimeより大きい場合にエラーで終了し、その他の場合に、スクリプト評価が続く。

【0051】

図２は、本発明の例示的な実施形態２００を示す。図２に示すように、例示的な実施形態２００は、スマートコントラクト２０６を生成する取引先２０２Ａ～０２Ｎ（C１～Cn）を含んでよい。スマートコントラクト２０６は、分配２２２と引き換えに回答２１４を客観的に決定するために募集されたメンバ２０４Ａ～０４Ｍ（p１～pm）のグループから受信した回答２１４の合意に依存するデジタルアセット量２２０を分配する。つまり、実施形態では、メンバ２０４Ａ～０４Ｍは共同で、分散型の信頼できる賢人（オラクル、oracle）として動作して、決定問題又は関数問題に対する回答を提供する。幾つかの例では、「オラクル」は、成り行き（outcome）を決定できる入力を提供する外部エージェントを表し、オラクル関連サービスは、Oraclize、TownCrier、及びOrisiサービスを含む。幾つかの実施形態では、メンバ２０４Ａ～０４Ｍは、グループの他のメンバのアイデンティティの知識を有しなくてよく、又はグループの他のメンバにより提供された回答の知識を有しなくてよい。メンバを互いに匿名に保つことにより、メンバ間の共謀の可能性が最小化される。

【0052】

幾つかの実施形態では、取引先２０２Ａ～０２Ｎは、スマートコントラクトの条項に合意した２つ以上のエンティティであってよい。種々の実施形態で、取引先２０２のうちの１つは、個人、個人のグループ、法人、コンピューティング装置、又はスマートコントラクト２０６の条項を決定する又は合意することのできる何らかの他のエンティティである。１つの使用例では、第１取引先はクライアントであり、第２取引先は保険業者である。幾つかの実施形態では、取引先２０２Ａ～０２Ｎのうちの少なくとも１つは、他のエンティティに、スマートコントラクト２０６の成り行きを決定するメンバ２０４Ａ～０４Ｍとして参加することに関心を持たせるための分配として分配２２２を提供する。幾つかの実施形態では、取引先２０２Ａ～０２Ｎのうちの少なくとも１つは、何人のメンバがメンバ２０４Ａ～０４Ｍのグループを構成するかを決定する。種々の実施形態で、メンバは、メンバのうちの完全なメンバ、最小メンバ、又は最大メンバである。グループ内のメンバが多いほど、グループにより提供される回答の合意は信頼性が高くなるべきである。

【0053】

幾つかの実施形態では、メンバ２０４Ａ～０４Ｍは、スマートコントラクト２０６の条件の成り行きを決定できるエンティティのグループである。種々の実施形態で、取引先２０２Ａ～０２Ｎと同様に、メンバのうちの１つは、個人、個人のグループ、法人、ソフトウェアアプリケーション、コンピューティング装置、又はスマートコントラクト２０６の成り行きを決定するために使用可能な回答を提供することのできる何らかの他のエンティティである。上述のように、幾つかの実施形態では、メンバ２０４Ａ～０４Ｍのうちのメンバは、取引先２０２Ａ～０２Ｎにより指定されてよい。一例では、取引先２０２Ａ～０２Ｎは、グループ内に１５個のメンバが存在しなければならないと指定する。

【0054】

一実施形態では、取引先２０２Ａ～０２Ｎは、（例えば、指定時間範囲内で）十分なメンバがグループに参加しなかった場合に、取引先２０２Ａ～０２Ｎによりデポジットされたデジタルアセットのうちの任意の量を返金するために（負のトランザクション分配）、スマートコントラクト２０６を生成する。上述のように、幾つかの実施形態では、メンバ２０４Ａ～０４Ｍは、取引先２０２Ａ～０２Ｎにより上げられた分配２２２により回答２１４を決定することに参加する理由を与えられてよい。幾つかの実施形態では、メンバ２０４Ａ～０４Ｍは、回答の合意に一致する回答を提出し、分配２２２又は分配２２２の何らかの割合（例えば、メンバの数により分割される）を受信する。上述の実施形態のうちの幾つかでは、非合意回答（合意回答に賛成しない回答）を提出するメンバは、彼らの分配２２２又は分配２２２の割合を没収される。他の実施形態では、非合意回答を提出するメンバは、合意に一致する回答を提出するメンバにより受信されるより少ない分配又は小さな割合の分配２２２を受信する。

【0055】

種々の例では、合意は、一致する回答の単純過半数、一致する回答の絶対過半数、閾（例えば、最初の３個の一致する回答が合意回答と考えられる）に達する前に提出された一致する回答の過半数、又は一致する回答の閾数、を表す。幾つかの実施形態では、取引先２０２Ａ～０２Ｎは、合意を決定するための閾を決定する。一例では、取引先２０２Ａ～０２Ｎは、合意に到達するために、メンバ２０４Ａ～０４Ｍのうちの少なくとも６０％が、一致する回答を提出しなければならないと決定する。

【0056】

さらに、幾つかの実施形態では、メンバの各々は、（例えば、デジタルアセットの何らかの量の）デポジットをコミット（commit、委託）する。該デポジットは、メンバ２０４Ａ～０４Ｍに回答を提出するためのさらなる理由を与える。つまり、上述の実施形態では、参加に賛成するが調和を破るメンバは、該メンバのコミットしたデポジットを失う。幾つかの実施形態では、メンバが非合意回答を提出した場合でも、メンバは依然としてデポジットを返金され、メンバは少なくとも参加によってデジタルアセットを失わない。必要なデポジットの量を決定する際に、取引先２０２Ａ～０２Ｎは、、メンバ２０４Ａ～０４Ｍが全く参加しようと望まないほど大きくないが、メンバ２０４Ａ～０４Ｍが彼らのデポジットを返金されるために即座に正確な回答を提供するための理由を与えられるほどデポジットを十分に大きくするようバランスを取る。

【0057】

幾つかの実施形態では、スマートコントラクト２０６は、取引先２０２Ａ～０２Ｎにより合意された条件に従いデジタルアセットの制御を自動的に移転するよう設計されたコンピュータ実行可能命令（例えば、演算コード）のセットである。幾つかの実施形態では、スマートコントラクト２０６は、（例えば、スクリプト言語で記述されたコンピュータ実行可能命令のような）ブロックチェーントランザクションの中に符号化され、ブロックチェーンネットワークの検証ノードによるブロックチェーントランザクションの検証により起動される。実施形態では、ブロックチェーントランザクションに関連付けられたデジタルアセットは、スマートコントラクト２０６の中で指定された条件の充足により償還可能（redeemable）である（例えば得られる）。実施形態では、スマートコントラクト２０６は、ブロックチェーンネットワークの分散型台帳の中の検証されたトランザクションのロックスクリプトに含まれる。この方法では、実行可能命令は不変にされ、スマートコントラクト２０６を含むロックスクリプトの実行の成功は、検証されたトランザクションのデジタルアセットを移転するための前提条件である。

【0058】

さらに、上述のように、実施形態では、スマートコントラクト２０６は条件セットを含み、検証されたトランザクションのUTXOをアンロックすることは、条件セットの充足に依存する。一例では、スマートコントラクト２０６は、ブロックチェーントランザクションのロックスクリプトへのインプットとして、被保険者が保険契約によりカバーされる損失を被ったことの証明を提供すると、保険契約に従い被保険者にデジタルアセットを分配する保険契約である。さらに、幾つかの実施形態では、スマートコントラクト２０６は、複数の可能な成り行きに関連付けられ、スマートコントラクト２０６を含む検証の実行が成功した結果は、特定の成り行きに依存して異なってよい。上述の例では、スマートコントラクト２０６は、少なくとも２つの可能な成り行き：つまり第１の可能な成り行き及び第２の可能な成り行きを有する。第１の可能な成り行きは、被保険者がカバーされた損失を被り、保険契約に従い支払いを受けることである。第２の可能な成り行きは、被保険者が損失を被らず、保険業者はデジタルアセット及び被保険者の保険料払込を維持することである。実施形態では、スマートコントラクト２０６の中のコンピュータ実行可能命令の実行は、スマートコントラクト２０６に、特定の成り行きを証明するデータがロックスクリプトへのインプットとして提供された場合に、可能な成り行きのうちの１つに従い、デジタルアセットを移転させる。

【0059】

幾つかの実施形態では、回答２１４は、スマートコントラクト２０６の中で指定された成り行き条件のうちの１つ以上に対応する回答である。一例として、スマートコントラクトは、支払われるデジタルアセット２２０の量及びどのエンティティにデジタルアセット２２０が支払われるかに影響する複数の条件を含み得る。メンバ２０４Ａ～０４Ｍは、複数の条件のうちのどれが（もしあれば）充足されるかを決定するために使用可能な回答２１４を提出する。幾つかの実施形態では、回答２１４は、暗号鍵又はデジタル署名の形式で提出される。この方法で、充足される条件は、スマートコントラクト２０６の中のどの条件が、メンバ２０４Ａ～０４Ｍの合意により提出された暗号鍵又はデジタル署名に対応するかを決定することにより、決定可能である。

【0060】

幾つかの実施形態では、デジタルアセット２２０は、充足されたスマートコントラクト２０６の特定の条件に従い支払われる、デジタルアセットの量である。つまり、どの特定の条件が充足されるかに依存して、デジタルアセットの量が変化し得る。例えば、第１条件が充足された条件である場合、１０単位のデジタルアセットが特定のエンティティに支払われてよい。一方で、第２条件が充足された条件である場合、２単位のデジタルアセットが同じまたは異なるエンティティに支払われてよい。

【0061】

上述のように、幾つかの実施形態では、分配２２２は、取引先２０２Ａ～０２Ｎのうちの１つ以上により、回答２１４の提供に参加することに同意するためにメンバ２０４Ａ～０４Ｍへの分配として提供されたデジタルアセットの量である。幾つかの実施形態では、分配２２２は、第三者により提供される。

【0062】

本開示では、全ての参加者は、互いに信頼できることを証明し、互いにセキュアな通信チャネルを通じて通信できると想定する。一実施形態では、セキュアな通信は、公開鍵暗号システムまたはDiffie-Hellman鍵交換プロトコルを用いて達成できる。一実施形態では、この方式の各参加者は、少なくとも特定レベルのエントロピにより暗号学的にセキュアな疑似乱数生成器（cryptographically secure pseudorandom number generators, CSPRNG）から導出されるシークレット値（秘密鍵）を生成することが要求される。一実施形態では、Bitcoinプロトコルとの互換性を維持するために、これらの値は２５６ビットの数値である。

【0063】

一実施形態では、特定の機能は、楕円曲線演算を通じて実現される。一実施形態では、楕円曲線（elliptic curve, EC）演算は、公開鍵生成、署名生成、及び署名検証を実行するために現在Bitcoinプロトコルで使用されているSecp２５６k１曲線により定められるパラメータを用いて実行される。曲線パラメータに加えて、Secp２５６k１規格は、生成元G（generator point）及びその次数（order）pを指定する。特に断りのない限り、実施形態では、本開示に記載されるアルゴリズムにおける演算は、モジュロpに対して実行される。また、本開示の特定の実施形態はBitcoinブロックチェーンに関連して提示されるが、概念は楕円曲線署名方式を利用する任意の暗号通貨ブロックチェーンにも適用可能であることに留意する。

【0064】

一実施形態では、参加者の２つの別個のグループが含まれる。つまり、メインコントラクトに対する取引先（Ci）、及びSchelling調整ゲームのような協調アルゴリズムに貢献するメンバ（Pi）である。例えば、Schelling調整ゲームは、２人以上の個人が互いに通信することなく同じ解（「焦点（focal point）」又は「Schellingポイント」とも呼ばれる）に到達しやすい調整ゲームである。この方法では、メンバは、メインコントラクトの成り行きを決定するために正確な入力を提供する分散型のグループオラクルとして機能する。実施形態では、取引先２０２Ａ～０２Ｎは、コントラクトの制御下にある資金を有し、別個のブロックチェーントランザクションの中で分配２２２をメンバに共同で提供する。しかしながら、協調アルゴリズムは、閾数のメンバにより提出されるのと同じ回答を提出するために分配をメンバに提供するので、回答は、必ずしも正しいものではなく、個々のメンバが他のメンバが提出すると考える回答を反映することがあることに留意する。

【0065】

実施形態では、メンバは、別個のブロックチェーントランザクションの中で、メンバが彼らの回答を提出した後に返金可能なセキュリティデポジットをコミットし、彼らの回答が合意回答に一致した場合に、分配又は分配の一部を獲得できる可能性がある。彼らの回答が合意回答に一致しない場合、メンバは、彼らのデポジットを取り戻すことができるが、分配２２２又は分配２２２の一部を受け取ることはできない、又は合意回答を提出したメンバにより受け取られるよりも少ない部分を受け取ることがある。

【0066】

＜コントラクトの設定＞
一実施形態では、メインコントラクト（「取引先コントラクト」とも呼ばれる）は、以下の方法でリンクされた協調アルゴリズム（例えばSchelling協調ゲーム）として実装できる。n個の取引先２０２Ａ～０２Ｎ（C１,C２,...,Cn）が、関連する資金を含む、コントラクトの条項及び条件に合意する。この段階では、合意は正式でなくてよく、トランザクションが署名されるまで資金がコミットされる必要はない。この段階におけるコントラクトの一般的構造は、以下の表１に示される。

【0067】

［表１］

【表1】

【0068】

一実施形態では、第１条件が充足されると、取引先２０２Ａ～０２Ｎは、結果の中で指定されたデジタルアセット（DA）の量Xを受信する。一実施形態では、条件（成り行き）は、明確に指定されなければならず、相互排他的でなければならない。さらに、一実施形態では、また、各条件iについて、量の和Xⁱ _j（j=１,...,n）は、コントラクトに支払われるべき資金に等しい（任意のトランザクションマイニング量を差し引く）。さらに、幾つかの実施形態では、期限条件は、期限期間の後にプロトコルが止まった場合、資金に何が起こるべきかを指定するために指定される。一実施形態では、各取引先C_jは公開鍵PKC_jを有する。

【0069】

図３は、本開示の例示的な実施形態３００を示す。具体的に、図３は、本開示の例示的な実施形態３００の公開鍵設定プロセスの高レベル概略図を示す。例示的な実施形態３００は、コントラクト３０６に合意し及びコントラクトの中の条件に対する成り行きを提供するよう多数のメンバ３０４に要求３０８を出している取引先３０２を含む。図から分かるようjに、要求３０８は、コントラクト条件の定義（Def）、提供される分配（F）、要求されるメンバの数（N）、メンバ当たりの要求されるセキュリティデポジットの量（D）、要求される閾（M）、ゴーストチェーンブロック間隔（ΔT）、及びコミットブロック高（h_B）、のような関連情報を含み得る。取引先のアイデンティティ、及びスマートコントラクトトランザクション３３０により制御されるデジタルアセットの分配は、グループメンバの投票に影響しないように、要求３０８に存在しなくて／与えられなくてよい。

【0070】

例示的な実施形態３００では、取引先は、コントラクト公開鍵３１６も生成する。実施形態では、取引先は、（例えば、電子メール及び／又は他の電子通信により）互いに通信でき、取引先３０２のうちの少なくとも１つは、例えばポータル、オンラインマーケットプレイス、ウェブログ、ピアツーピア通信、又は何らかの他の通信フォーラムを通じてメンバ３０４と通信できる。一実施形態では、十分な（少なくとも要求３０８の中で取引先３０２により指定された数の）メンバがグループの一部になることの合意を伝達した後の時間に、メンバ３０４は、グループ公開鍵３１２及び共有公開鍵３１４を生成することに合意する。例示的な実施形態３０９では、メンバ３０４は、ディーラ不要の秘密分散方式を利用して、グループ公開鍵３１２及び共有公開鍵３１４を生成する。例示的な実施形態３００では、取引先３０２により提供されたコントラクト公開鍵３１６の値は、別個の公開鍵３１４と結合されて、コントラクト条件公開鍵３１８を生成する。

【0071】

例示的な実施形態３００では、取引先トランザクション３３０は、コントラクト条件公開鍵３１８のうちの１つに対応する適切なデジタル署名に基づき決定された成り行きに従い、取引先３０２のうちの１つ以上に分配する。同様に、例示的な実施形態３００では、協調アルゴリズムトランザクション３３２は、（協調アルゴリズムにより）勝者の成り行きを決定すると、分配及びデポジットをメンバ３０４に移転する。

【0072】

以下は、上述のコントラクト設定の例示的な使用例である。例示的な使用例では、保険契約が２つの取引先３０２、つまりクライアント（C_１）及び保険業者（C_２）の間で生成される。クライアントは、本例では、２０１８年４月の間にいつでも、彼のぶどう園で酷い霜の可能性に対して保険を掛けたいと望む。本例では、酷い霜は、「２０１８年４月の一ヶ月中に少なくとも４時間の任意の連続する期間であって、サリー州の地域で気温が－４℃より低く保たれること」として明確に定められる。本例では、保険業者は、クライアントからの３DAの掛け金と引き換えに、酷い霜があった場合に、１０DAを支払うというポリシに合意する。したがって、保険業者はコントラクトに１０DAをコミットし、クライアントはコントラクトに２DAをコミットする。したがって、コントラクトは、以下の表２に示され、１２DAを制御する（保険業者のデポジット及び掛け金）。

【0073】

［表２］

【表2】

【0074】

したがって、酷い霜が発生したという条件により、クライアントは１０DAを受け取り、保険業者は２DAを受け取る。一方で、酷い霜が発生しないという条件により、クライアントは資金を受け取らず、一方で、保険業者は元の１０DAに２DAの掛け金を足したもの、全部で１２DAを取り戻す。いずれの条件も明確に実証されず、期限条件が生じた場合、クライアントは２DAの掛け金を返金され、保険業者は同様に１０DAの支払いを返金される。イベントに関して曖昧さがない場合、期限条件が冗長でなければならないことに留意する。期限は、プロトコルが決定を提供できない場合に、資金が失われることを防ぐために存在し、本例では、各パーティへの返金を出すだけである。また、実施形態では、取引先は、コントラクトの実行のための分配、及びこの分配を誰が支払うかに合意すること、及び分配のために選択される量は、必要なセキュリティ及び条件の性質に依存し得ることに留意する。

【0075】

実施形態では、取引先のうちの１つ（又は彼らの代表として動作する第三者／サービス）は開放型市場（又は公開フォーラムに）要求を提出する。該要求は、コントラクト条件の定義（Def）、提供される分配（F）、要求されるメンバの数（N）、メンバ当たりの要求されるセキュリティデポジットの量（D）、要求される閾（M）、ゴーストチェーンブロック間隔（ΔT）、及びコミットブロック高（h_B）を指定する。実施形態では、ゴーストチェーンブロック間隔は、ブロックがゴーストチェーンブロックチェーンにコミットされる頻度を表す。また、実施形態では、コミットブロック高は、ゴーストチェーンの中のブロックの数を表す。

【0076】

したがって、上述の例示的な使用例では、保険業者は、０．２DAの分配を提供し、１０人のメンバのグループが以下の２つの成り行きのうちの１つを提出することを要求する。
１．成り行き＃１：「２０１８年４月の一ヶ月で、英国サリー州の地域のどこかで、少なくとも４時間の間、連続して、気温が－４℃より下に保たれる」
２．成り行き＃２：「条件１を除く何らかの他の成り行き」

【0077】

例示的な使用例では、保険業者及びクライアントは、６の閾に合意する。つまり、１０人のメンバのうちの少なくとも６人による合意が、上述の条件のうちのどれが充足されたかを述べる。本例では、メンバは、それぞれ０．１DAのデポジットを提出することを要求される。結果として、利用可能なメンバは、成り行きの定義を吟味し、条件を評価する彼らの能力（例えば、彼らが直接又は間接的に（つまりニュース／インターネットを介して）必要な情報へのアクセスを有するかどうか）、可能な儲け（F）、及び必要なデポジットに基づき彼らが参加したいかどうかを決定できる。メンバは、彼らが受諾したことを取引先に通信し、デポジットを含む認証したUTXO及び通信のための公開アドレスを含む。

【0078】

十分な数（N）のメンバが（P_i）が要求の受諾を伝達すると、一実施形態では、取引先は、彼らの通信アドレスをメンバのグループに分配する。実施形態では、メンバ及び取引先は、次に、セキュアなピアツーピア通信チャネルを互いに確立できる。実施形態では、メンバグループは、閾Mによるディーラ不要の秘密分散プロトコルを実行して、コントラクト条件／成り行き（IPKⁱ）の各々についてグループ公開鍵（GPK）及び個別公開鍵（及び関連する個別鍵シェア）を生成する。そして、これらの公開鍵は、取引先へ送信される。

【0079】

実施形態では、メンバは、シークレット鍵を共有する方法を使用する。その結果、各メンバは、（未だ知られていない）シークレット鍵のシェアを有する。シークレット鍵それ自体は、閾数のシェアから計算できる（ここで、閾は、メンバの数より少ない又はそれに等しい）。したがって、シークレット鍵はいかなる単一のパーティにも知られていないが、メンバのグループは、セキュアなマルチパーティ計算により、未だ知られていないシークレット鍵に対応する楕円公開鍵を決定できる。本方法では、ブロックチェーンアウトプットは、信頼不要の方法で共有グループ鍵の制御下に置くことができ、秘密鍵は、閾数のメンバの協力を通じて決定できる（又は署名が生成される）。

【0080】

幾つかの実施形態では、この目的のためにシャミアの秘密分散法（Shamir’s Secret Sharing scheme, SSSS）が使用される。SSSSは、次数tの多項式がt＋１個の（閾）点の任意の集合に適合し得るという概念に基づく。次数tの多項式f(x)は、定数項としての共有鍵（a_０＝f(０)）を有し形成され、残りの係数はランダムに選ばれる。グループ内のメンバの数に等しい数の、曲線上の点が、各メンバに与えられる。点を結合するメンバの数が、（t＋１）以上である場合、これらの点に次数tの多項式を適合するために十分な情報があり、a_０はシークレットとして開示される。実施形態では、この方式は、任意の閾により任意の多数のメンバの間で単一の秘密鍵の共有を可能にする。

【0081】

標準的なSSSSは、多項式を生成し及びシークレットシェアを分配するために、信頼できるディーラの要件を除去することに拡張できる。これは、信頼できるディーラへの依存を除去する。このディーラ不要のSSSSでは、各メンバ（P_i）は、彼ら自身のランダムな次数tの多項式f_i(x)を生成し、次にf_i(x)を各々の他の参加者P_iへセキュアに送信する。各P_iは、次に、全ての受信した点を加算して、共有された多項式f(x)上のP_i点である、彼らのシークレットシェアs_i=f(i)を得る。

【0082】

シークレットシェアが生成された後、（どのメンバも未だ知らない）共有秘密鍵に対応する公開鍵（A）は、楕円曲線生成元Gにより以下のように計算される。参加者P_i、i=１,...,t、は、彼らの公開鍵シェアをb_is_i×Gとして計算し、ここで次の通りである。

【数1】

【0083】

これらの公開鍵シェアは、次に、全てのメンバにブロードキャストされ、共有公開鍵Aは次にt+１個のシェアの和として単純に計算される。

【数2】

【0084】

楕円曲線暗号（ECC）の数学的特性が本開示で利用されることに留意する。ECC演算は、次数pの発生元点Gにより定義できる。ランダム秘密鍵（a）が選択されると（１～pの間）、公開鍵（A）が以下の点乗算（point multiplication）により導出できる。
A=a×G

【0085】

さらに、点乗算の基本的特性により、次の通りである。
(a+r)×G=a×G+r×G
ここで、rはノンスである。実施形態では、この特性は、楕円曲線署名へのランダムブラインドノンス（random blinding nonces）を利用するために使用できる。また、本開示では、楕円曲線デジタル署名アルゴリズム方式は、種々の実施形態において、グループが完全な秘密鍵を再構成することなく閾数の鍵シェアを用いてトランザクションに共同で署名することを可能にするために使用される。

【0086】

上述の例示的な使用例を更に続けると、１０人のメンバのグループが、（上述のように合意された、６の閾を有する）ディーラ不要のSSSSプロトコルを３回、共同で実行する。１０人のメンバのグループは、グループ公開鍵（GPK）及び２つの成り行き公開鍵（IPK^１及びIPK^２）を生成する。結果として、各メンバjは、次に、３個のシークレット鍵シェア（GPriv_j、IPriv_j ^１、IPriv_j ^２）を所有する。グループ公開鍵は、さらに、メンバ３０４が、彼らのデポジットを送信するためのブロックチェーンアドレスを決定することを可能にする。

【0087】

一実施形態では、取引先３０２は、次に、ランダムブラインドノンス（R_B）に合意する。実施形態では、選択された値は、全ての取引先により格納されるが、メンバグループから秘密に保たれる。一実施形態では、取引先は、次に、R_Bについて対応する楕円曲線公開鍵を計算する。
PKR=R_B×G
PKRの値は、次に、コントラクト公開鍵の各々に加算される。
IPKⁱ _R=IPKⁱ+PKR

【0088】

したがって、本例では、取引先３０２は、コントラクト条件公開鍵３１８を計算し、IPK^１ _R=IPK^１+PKR、及びIPK^２ _R=IPK^２+PKR、以下同様である。本方法では、公開鍵３１４は、ランダムブラインドノンス（R_B）の使用により難読化される。その結果、取引先３０２以外のエンティティ、例えばメンバ３０４が、取引先トランザクション３３０の中で使用されたコントラクト条件公開鍵３１８のいずれかを、メンバ３０４の生成した別個の公開鍵３１４にリンクできる可能性が非常に低くなる。この方法では、取引先トランザクション３３０（及びそれが含む量）は匿名のままであり、メンバ３０４により行われる決定は、コントラクトトランザクションの詳細（例えば、問題となっているデジタルアセットの量）の知識による影響から隔離される。

【0089】

本例では、２つのトランザクションが、取引先３０２の合意により生成された。つまり、取引先トランザクション３３０（TxC）及び協調アルゴリズムトランザクション３３２（TxS）である。一実施形態では、取引先トランザクション３３０は、インプットとして、取引先３０２からのコントラクト資金を有する。また、一実施形態では、取引先トランザクション３３０は、コントラクトの成り行きに依存して、取引先３０２の一方又は両方に支払可能なそれぞれの量のための別個のアウトプットを有する（例えば、それぞれユニークな値Xⁱ _j）。したがって、これらのUTXOの各々は、条件及び期限条件に依存して、それぞれの取引先に分配する。また、幾つかの例では、アウトプットは、取引先３０２のメンバではない第三者に支払うために構成され得ることに留意しなければならない。幾つかの実施形態では、アウトプット制約が、２of２マルチ署名機能として実装される。

【0090】

例示的な使用例の取引先トランザクション３２０の中の条件の一例は、表３に示される。

【0091】

［表３］

【表3】

【0092】

例示的な使用例のスクリプトは、表４に示される。

【0093】

［表４］

【表4】

【0094】

一実施形態では、協調アルゴリズムトランザクション３３２は、インプットとして、メンバデポジットの各々からのN個のUTXO、及び取引先からの分配を構成するUTXOを有する。幾つかの実施形態では、２個のUTXOがあり、図４に関連して記載したように、一方はデポジットを含むグループ公開鍵（GPK）からの署名によりアンロックでき、他方は、GPKからの署名により又は期限切れ後の取引先の署名によりアンロックできる。

【0095】

実施形態では、閾数のグループメンバは、グループ秘密鍵（GPriv）を明示的に決定することなく、GPrivに対応する署名を共同で生成することができる。実施形態では、署名は、GPrivから直接生成された署名と区別できないが、実施には、閾署名方式により秘密鍵シェア(GPriv_j)から直接生成され得る。この方法では、GPrivは、いかなる時点においても決定される必要がないが、それに対応する署名は、閾数の秘密鍵シェア(GPriv_j)から決定できる。

【0096】

上述の実施形態では、閾数のグループメンバが第１UTXO（デポジット）の移転に合意する（及び共同で署名を生成する）。上述の実施形態では、閾数のグループメンバは、また、分配を請求するために共同で署名を生成できるが、可能なせいか秘密鍵のうちの１つに対応する追加署名を生成kできる。このような実施形態では、グループメンバが、合意に達することにより成り行き秘密鍵のうちの１つを再構成できない場合、彼らは分配を請求できず、分配は、期限切れの後に取引先に返される。

【0097】

幾つかの実施形態では、グループメンバは、閾数の彼らの秘密鍵シェア(GPpriv_j)が、完全な秘密鍵を再構成することなく、いつでも（例えばディーラ不要の秘密分散プロトコルの部分として）（GPK）に対応する有効な署名を生成し得るか否かをチェックできることに留意する。このような実施形態では、閾数のグループメンバは、デポジットをいつでも回収できるが、勝者の成り行き鍵（winning outcome key）を生成することにおいて彼らの役割を果たさなかった場合には、分配を没収されるだろう。例示的な使用例の協調アルゴリズムトランザクション３３２のインプット及びアウトプットの一例は、表５に示される。

【0098】

［表５］

【表5】

【0099】

一実施形態では、協調アルゴリズムトランザクション３３２は、分配を提供する取引先３０２により署名され、次に、今度はメンバ３０４の各々により署名されるようにメンバグループへ送信される。実施形態では、各インプットが署名されると、協調アルゴリズムトランザクションは、ブロックチェーンネットワークへブロードキャストされる。幾つかの実施形態では、協調アルゴリズムトランザクション３３２が署名されるまで、任意の参加者がプロトコルを止める（又は協調に失敗する）ことができ、資金は危険な状態に置かれない。一実施形態では、協調アルゴリズムトランザクション３３２がブロックチェーン上で承認（confirm）されると、各取引先は、次に、取引先トランザクション３３０への彼らのそれぞれのインプットに署名して、それをブロックチェーンネットワークにブロードキャストする。実施形態では、取引先トランザクション３３０がブロックチェーン内で承認されると、取引先コントラクトが起動されてよい。

【0100】

＜コントラクトの実行＞
一実施形態では、取引先トランザクション３３０が承認された後に、メンバ３０４は、要求３０８の中の条件／条項で指定された時間期間が終了する後まで、待機する。一実施形態では、メンバ３０４は、次に、ゴーストチェーンのような別個のブロックチェーンを利用して、彼らの投票を記録する。幾つかの例では、「ゴーストチェーン」は、メンバのグループによりマイニングされるproof-of-stakeブロックチェーンを表す。ここで、該メンバのデポジットは、グループ鍵（GPK）を介して協調アルゴリズムトランザクションにコミットされる。つまり、作業を実行することに対して与えられる分配に関心のあるマイニングノードによりトランザクションが確証される、proof-of-workに基づくブロックチェーン（例えばBitcoin）と異なり、ゴーストチェーンのproof-of-stakeブロックチェーンでは、参加者は、ゴーストチェーンの中で生成されるデポジット（例えば、彼ら自身のデジタルアセットのうちの何らかの量の彼らの「掛け金（stake）」）を回収することに関心を示してよい。

【0101】

伝統的なブロックチェーンとは対照的に、ゴーストチェーンは、１つ以上の基準、目標、又は指定された目的の実行又は充足により、終了し、消失し、及び／又は満了するよう構成できる。つまり、幾つかの実施形態では、ゴーストチェーンは、その目的が達成されるともはや使用されない単一目的のブロックチェーンである。幾つかの実施形態では、ゴーストチェーンは、ゴーストチェーンがその目的、基準、又は目標のために展開され又は生成されたときに生成された最初のブロック（「ジェネシスブロック」とも呼ばれる）を含む。

【0102】

幾つかの実施形態では、ゴーストチェーンにより利用されるproof-of-stake合意アルゴリズムは、規則的なブロック時間、タイムスタンプされたブロック、及び枝分かれの可能性の特性を有し得る。幾つかの実施形態では、ブロック分配は（「マイニング量」）、所定のレートで分配（F）から支払われる。幾つかの実施形態では、マイニング分配は、ブロックを確証することのごく少量のコストにより、低くなり得る。幾つかの実施形態では、協調アルゴリズムは、十分なスクリプト能力及びブロックチェーンを認識する簡易支払い検証（single payment verification, SPV）証明があれば、協調アルゴリズムトランザクションにより、ブロックチェーン上で（つまり、ゴーストチェーンの代わりに）完全に行うことができる。このようなブロックチェーンプラットフォームの一例は、Ethereumである。

【0103】

一実施形態では、ゴーストチェーンブロックは、幾つかの例では要求の中で指定されるΔTの間隔で生成される。幾つかの実施形態では、ΔTの値は、コンタクトの所望の解決速度、及びメンバ３０４からの所望の応答時間に基づき選択される。一実施形態では、メンバ３０４の各々は、取引先コントラクトにより求められる結果の決定に達する。上述の例示的な使用例を用いると、メンバ３０４の各々は、２０１８年４月の一ヶ月に酷い霜が発生したか否かの決定を行う。メンバ３０４の必ずしも全員が同じ決定に達しない可能性を許容すると（例えば、メンバのうちの何人かは、不正な情報を有することがあり、又は故意でなく若しくは故意に誤った解答を提出することがある）、決定が結果として受け入れられるためには、閾数Mのメンバ３０４が同じ決定に到達する必要があるだけである。

【0104】

図４は、本開示の例示的な実施形態４００を示す。具体的に、図４は、本開示の一実施形態のスマートコントラクト設定の高レベル概略図を示す。図から分かるように,図４は、とびとびにゴーストチェーン４３４にコミットされるトランザクション４３８を含む。幾つかの実施形態では、ゴーストチェーン４３４は、協調アルゴリズムにおける投票を記録するために生成された一時的なproof-of-stakeサイドチェーンであってよい。幾つかの実施形態では、トランザクション４３８は、ゴーストチェーン４３４のブロックに埋め込まれたブロックチェーントランザクションである。幾つかの実施形態では、各々の連続するブロックは、ゴーストチェーン内の前のブロックの暗号ハッシュであるハッシュ４３６を含む。ハッシュ４３６は、ゴーストチェーン４３４の中のブロックをリンクする。

【0105】

実施形態では、コミット方式は、値を他者から隠したままにしながら、メンバが特定の値を予めコミットすることを可能にする。値は、コミットされると、後の段階で開示され得る。この方法では、グループのメンバは、彼らがコミットした後に値を変更できないが、値は、他のメンバに開示されず、この方法では、セキュアな投票プロトコルとして使用できる。

【0106】

通常、コミット方式は、２つの段階で生じ得る。つまり、メンバにより値が選択されコミットされるコミット段階、及び、メンバにより値が開示されコミットと一致することが承認される開示段階である。通常、セキュアなコミット方式は、コミットされた値に関する任意の情報がコミット段階の後に開示されることを防ぐために、ランダムブラインドノンスに依存してよい。しかしながら、本開示では、コミットされた値は、既にランダムに生成された鍵であってよい。したがって、コミットプロトコルは、単にセキュアなハッシュ関数を利用することにまで縮小できる。

【0107】

したがって、本開示の匿名投票プロトコルでは、コミット段階で、各メンバは、彼らがコミットしたいと望む値を（例えば、SHA２５６を用いて）ハッシュし、ハッシュをグループに開示し、開示段階で、各メンバは、次にハッシュのプレイメージ（コミットされた値）をグループに開示し、グループが各ハッシュを検証する。この方法では、グループは、グループの残りのうちのどれくらいが投票しているかを予め知ることなく、投票にコミットできる。

【0108】

したがって、一実施形態では、要求の中で指定されたブロック高（h_B）で、メンバ（例えば、図３のメンバ３０４）の各々は、彼らが個別に決定したコントラクト結果に対応する条件／条項公開鍵の秘密鍵シェア（i番目の条件のメンバjの秘密鍵シェアIPrivⁱ _j）にコミット４２４を提出する。一実施形態では、各メンバは、彼らのそれぞれのコミット４２４に署名し、コミットはゴーストチェーンに埋め込まれる。実施形態では、各コミットは、決定された結果に対応するそれぞれのメンバの秘密鍵シェアの単純なハッシュ（例えば、Secure Hash Algorithm, SHA２５６）であり得る。秘密鍵シェアをハッシュすることにより、書くメンバの投票は、後述する開示段階まで、秘密に保たれる。この方法では、１人のメンバの投票が別のメンバの投票に影響を与える危険性は最小化される。

【0109】

一実施形態では、各メンバは、次に、彼らのコミットした鍵シェア４２６（IPrivⁱ _j）を提出する。次に、この鍵シェアは、次のブロック（h_B+１）に埋め込まれる。幾つかの実施形態では、各グループメンバにより保持される鍵シェア４２６は、上述のような、秘密分散方式に従い決定された、完全な秘密鍵のシェアである。このような秘密分散方式では、少なくとも閾数の鍵シェア４２６を取得することが、完全な秘密鍵４２８を算術的に決定させることができる。一実施形態では、このブロックが検証されると、閾数Mのメンバが１つの特定の成り行きに対応する鍵シェアを提出している場合、勝者の（winning）成り行き公開鍵（IPK^w）に対応する勝者の完全な秘密鍵４２８（IPriv^w）（例えば、図３の別個の公開鍵３１４のうちの１つ）は容易に決定でき、公に開示される（wは勝者の成り行きインデックスである）。幾つかの実施形態では、勝者の完全な秘密鍵４２８は、取引先に送信されスマートコントラクトトランザクションの中に符号化された勝者の公開鍵（例えば、別個の公開鍵３１４のうちの１つ）の相対物である暗号鍵である。

【0110】

例示的な実施形態では、コミット高（h_B）は、ブロックx-１であり、コミットされた鍵シェア４２６（メンバjの成り行き秘密鍵のシェア）は、ブロックxで開示される。開示の後に、閾数の勝者の秘密鍵シェアは、勝者の完全な秘密鍵４２８を決定することを可能にする。

【0111】

図５は、本開示の例示的な実施形態５００を示す。具体的に、図５は、図４について成り行きが決定された後の、図３において設定されたスマートコントラクトの実行の高レベル概略図を示す。例示的な実施形態５００は、取引先トランザクション５３０Ａをアンロックする成り行きトランザクション５３０Ｂに署名することにより、勝者の完全な秘密鍵５２８に関連付けられた成り行きに従い、デジタルアセット５２０の量を収集する取引先５０２を含む。例示的な実施形態５００は、さらに、取引先５０２に勝者の完全な秘密鍵５２８を提供するために分配として協調アルゴリズムトランザクション５３２Ａをアンロックする分配トランザクション５３２Ｂに署名することにより、アウトプット５２２を介して分配及びデポジットを収集するグループのメンバ５０４を含む。

【0112】

幾つかの実施形態では、取引先５０２は、図２の取引先２０２と同様である。幾つかの実施形態では、メンバ５０４は、図２のメンバ２０４と同様である。幾つかの実施形態では、署名５１８Ａは、各メンバ５０４が彼らの分配及びデポジットを受け取るための、メンバ５０４の共同デジタル署名である。幾つかの実施形態では、署名５１８Ｂは、取引先のデジタル署名であり、デジタル署名は、勝者の完全な秘密鍵５２８及びランダムブラインドノンス５１６を結合することにより形成された完全な成り行き署名鍵５２６を用いて生成される。

【0113】

幾つかの実施形態では、勝者の完全な秘密鍵５２８は、図４の勝者の完全な秘密鍵４２８と同様である。幾つかの実施形態では、ランダムブラインドノンス５１６は、コントラクト条件公開鍵を難読化するために、図６の６１２で生成されたノンスと同じである。幾つかの実施形態では、完全な成り行き署名鍵５２６は、楕円曲線演算を用いてランダムブラインドノンス５１６と結合された勝者の完全な秘密鍵４２８である。その結果、スマートコントラクトの成り行きは、完全な成り行き署名鍵５２６を、取引先トランザクション５３０Ａのロックスクリプトの、スマートコントラクト内の取引先コントラクト条件公開鍵と照合することにより、決定できる。

【0114】

幾つかの実施形態では、デジタルアセット５２０は、署名５１８Ｂが検証されることによる、スマートコントラクトの勝者の成り行きに従う、取引先トランザクション５３０の中で予めロックされたデジタルアセットの分配である。幾つかの実施形態では、アウトプット５２２は、署名５１８Ｂの検証により、メンバ５０４に支払い可能な少なくとも１つの協調アルゴリズムトランザクションの中の予めロックされたデジタルアセットを反映する。幾つかの実施形態では、取引先トランザクション５３０Ａは、図２のスマートコントラクト２０６のようなスマートコントラクトを含む、図３の取引先トランザクション３３０と同様のブロックチェーントランザクションである。幾つかの実施形態では、成り行きトランザクション５３０Ｂは、スマートコントラクトの決定した成り行きに従い、取引先トランザクション５３０Ａの適切なデジタルアセットを償還する／請求するために作成されるブロックチェーントランザクションである。

【0115】

幾つかの実施形態では、協調アルゴリズムトランザクション５３２Ａは、分配及びメンバ５０４のデポジット５２２を含む、図３の協調アルゴリズムトランザクション３３２と同様のブロックチェーントランザクションである。幾つかの実施形態では、分配トランザクション５３２Ｂは、メンバ５０４のデポジット及び分配を請求するために彼らにより生成されたブロックチェーントランザクションである。勝者の完全な秘密鍵４２８を決定した結果として、勝者の秘密鍵シェアをコミットするメンバが決定可能である。一実施形態では、ゴーストチェーンの合意アルゴリズムは、「勝者である」メンバ（つまり、合意に投票したメンバ）を識別し、分配トランザクション５３２Ｂ（TxF）は、（例えば、閾署名方式により）閾数（m）のメンバによりGPKを使用して署名された分配を勝者であるメンバに支払うために、グループにより又はグループのメンバにより、生成される。実施形態では、メンバは、勝者の完全な秘密鍵４２８を、分配トランザクション５３２Ｂのメタデータに埋め込んだ。

【0116】

幾つかの実施形態では、メンバのデポジットは、また、分配トランザクション５３２Ｂを検証した結果として、返済される。幾つかの実施形態では、メンバ５０４のデポジットは、協調アルゴリズムトランザクション５３２からの異なるトランザクションにコミットされる。上述の実施形態のうちの幾つかでは、返金トランザクション（TxD）は、グループのためにグループにより、又は各メンバのデポジットを返金するためにグループのメンバにより、生成される。幾つかの実施形態では、特定のゴーストチェーンの合意ルールを破ったメンバは、彼らのデポジットを他のメンバの間で分配させる。実施形態では、分配トランザクション及び返金トランザクションは、次に、ブロックチェーンネットワークにブロードキャストされる。

【0117】

クライアント及び保険業者が、２０１８年４月中のいつでもクライアントのぶどう園における酷い霜の可能性に対してクライアントの保険を引き受ける保険契約に合意する上述の使用例を一例として用いると、メンバグループは、ΔT＝１日のブロック生成時間により、２０１８年５月の初日にゴーストチェーンをインスタンス化する。使用例では、h_Bは５に設定され、結果として５月５日に、メンバ（例えば、図３のメンバ３０４）は、５月５日に彼らの署名したコミットメント（例えばコミット４２４）を提出する。続くΔT、５月６日に、メンバの各々は、彼らのコミットメントを開示するために、鍵シェア（例えば４２６）を提出する。

【0118】

例示的な使用例では、１０人のメンバ５０４のうちの９人が、IPK^１の彼らのシェアをコミットし、メンバ５０４のうちの１人が、IPK^２の彼らのシェアをコミットした（例えば、反対意見のメンバの情報源が誤りであった）。本例では、メンバグループは、IPriv^１が閾数（６）のコミットメントから再構成できると決定し、次にどのメンバが勝者のシェア（９）にコミットしたかを識別できる。一実施形態では、メンバグループ（勝者のサブセット）の閾数は、次に、分配を９人の勝者に支払い全てのメンバデポジット（手数料及びデポジット５２２）を返すトランザクション５３２を生成できる。

【0119】

＜取引先グループ＞
一実施形態では、勝者の成り行き公開鍵（IPK^w）に対応する勝者の完全な秘密鍵５２８（例えば、図４の勝者の完全な秘密鍵４２８）（IPriv^w）は、メンバグループにより開示される。一実施形態では、取引先５０２（例えば、図３の取引先３０２）又は「勝者である」取引先のいずれかが、ランダムブラインドノンス５１６を、この値に追加して、完全な成り行きの署名鍵５２６を取得する。
IPriv^w _R=IPriv^w+R_B

【0120】

実施形態では、この値は、次に、署名５１８B（及びそれら自身の公開鍵からの署名と一緒に）を生成して、勝者の成り行きに対応する取引先トランザクション５３０（例えば、図３の取引先トランザクション５３０）のアウトプット５２２を請求するために、「勝者である」取引先５０２により使用できる。例示的な使用例では、取引先は、酷い霜の成り行きが客観的に生じたことをメンバの同意から決定することにより協調アルゴリズムが生成した勝者の完全な秘密鍵５２８（IPriv^１）を知る。結果として、保険契約は、分配を移転する。例示的な使用例では、取引先５０２の各々（例えば、取引先３０２の各々）は、ランダムブラインドノンス５１６（R_B）をIPriv^１に追加して、完全な成り行き署名鍵５２６（IPriv^１ _R）を取得する。この値は、次に、取引先トランザクション５３０の対応するアウトプット５２２Ｂを移転するための署名５１８Ｂを生成するために、各取引先の秘密鍵と共に使用できる。

【数3】

【0121】

図６は、種々の実施形態による、スマートコントラクト及び協調アルゴリズムトランザクションを生成するプロセス６００の一例を示す流れ図である。プロセス６００（又は記載された任意の他のプロセス、又はそれらのプロセスの変形及び／又は結合）の一部又は全部は、実行可能命令及び／又は他のデータにより構成される１つ以上のコンピュータシステムの制御下で実行でき、１つ以上のプロセッサ上で共同で実行する実行可能命令として実装されてよい。実行可能命令及び／又は他のデータは、非一時的コンピュータ可読記憶媒体に格納され得る（例えば、磁気、光、又はフラッシュ媒体に永久的に記憶されたコンピュータプログラム）。

【0122】

例えば、プロセス６００の一部又は全部は、１つ以上のコンピューティング装置（例えば、データセンタのサーバによる、クライアントコンピューティング装置による、コンピューティングリソースサービスプロバイダの分散型システムの中の複数のコンピューティング装置による、又は図８のコンピューティング装置８００のような任意の適切なクライアント装置による）により実行できる。プロセス６００は、一連の演算を含み、２つ以上の取引先が、スマートコントラクトの要件及び協調アルゴリズムトランザクションのパラメータに合意し、スマートコントラクトの成り行きを決定するためにメンバのグループと連携し、スマートコントラクト及び協調アルゴリズムトランザクションを生成する。

【0123】

幾つかの実施形態では、６０２で、図２の取引先２０２のような２つ以上の取引先は、スマートコントラクトのパラメータを決定する。例えば、取引先は、取引先の各々がスマートコントラクトトランザクションにコミットするデジタルアセット（例えば、Bitcoin）の量、条件セット、並びに、条件の各々が充足されると支払うべきデジタルアセットの量及び彼らが誰に支払うかについて合意に達してよい。より具体的な例として、合意は、３つの取引先（Alice, Bob, Carol）の間で達成される。ここで、スマートコントラクトトランザクションに、デジタルアセットのうち、Aliceは量X_１をコミットし、Bobは量X_２をコミットし、Carolは量X_３をコミットする。

【0124】

本例では、合意される条件セットは、第１条件が満たされた場合であり、Aliceはスマートコントラクトのコミットされたデジタルアセットの６０％を受け取り、Bobはコミットされたデジタルアセットの３０％を受け取り、Carolはコミットされたデジタルアセットの１０％を受け取る。代替として、第２条件が満たされた場合、Bob及びCarolは、それぞれ、はコミットされたデジタルアセットの５０％を受け取る（Aliceは何も得ない）。更に代替として、第３条件が満たされた場合、Aliceの夫Ted（スマートコントラクトにデジタルアセットをコミットしていない）は、スマートコントラクトのデジタルアセットの１００％を相続する。第４条件として、指定時間枠の間に第１、第２、及び第３条件が満たされなかった場合、Bob、Carol、及びAliceは、彼らのコミットしたデジタルアセットを返金され得る。

【0125】

幾つかの実施形態では、６０４で、取引先は、どの条件が満たされたかを決定するために、グループオラクルとして動作するメンバの特性を決定する。つまり、取引先は、メンバが成り行きを決定することに参加することに同意する理由を提供するためにどれだけ多くのデジタルアセットを分配として提供すべきか、グループに必要なメンバの数、メンバの各々がセキュリティデポジットとしていくらコミットしなければならないか、及び合意としての資格を得るために一致する投票の数の閾、について合意に達する。一例では、Bob、Carol、及びAliceは、１０単位のデジタルアセットを、スマートコントラクトの特定の成り行きに合意するグループの最大１０人のメンバの各々に提供すること、合意回答と考えられるためにグループからの少なくとも６個の回答が一致しなければならないこと、に合意する。本例では、Bob、Carol、及びAliceは、グループの各メンバが見返りとして０．１単位のデジタルアセットをコミットすることを要求する。

【0126】

幾つかの実施形態では、６０６で、取引先は、協調アルゴリズムトランザクションのタイミングパラメータ、例えばグループメンバが彼らの回答をコミットするゴーストチェーンのブロック高及びブロック間隔を決定する。例えば、ブロック高（例えば、ブロックチェーン内に存在すべきブロックの数）は、５に指定され、ブロック間隔は１日に指定され、特定の時間で開始する。これは、グループメンバに、彼らの決定を提出するために、開始時間の後の５日間（１日×５）を与える。５番目のブロックで、グループメンバは、彼らの署名したコミットメントを提出し、翌日、彼らは彼らのコミットメントを開示する。

【0127】

幾つかの実施形態では、６０８で、取引先は、図３の要求３０８と同様である、グループメンバに対する要求を提出する。つまり、要求は、コントラクト条件の定義、提供される分配、求められるメンバの数、メンバ毎に要求されるセキュリティデポジットの量、合意回答に対する一致する投票の必要な閾、ゴーストチェーンブロック間隔及びコミットメントブロック高（h_B）、のような情報を含み得る。上述のように、要求は、ウェブサイトフォーラム、掲示板、ピアツーピアアプリケーション、又はオンラインマーケットプレイスのような、そのような要求を提出する／記入するのに適する任意のフォーラム又は通信媒体で提出され／記入されてよい。

【0128】

幾つかの実施形態では、６１０で、グループのメンバは、スマートコントラクトの成り行きを決定する際に、彼らの合意を参加者に伝達する。幾つかの実施形態では、合意の伝達は、要求が提出された／記入されたフォーラムと同じまたは同様のフォーラムを通じて行われる。他の実施形態では、合意の伝達は、取引先のうちの１つ以上への直接通信を通じて（例えば、要求の中の通信リンクを介して）実行される。

【0129】

幾つかの実施形態では、６１２で、グループメンバシップ要件が満たされたことの通知を受信した後に、取引先は、スマートコントラクトトランザクションの中の成り行きを難読化するランダムブラインドノンスを生成する。ランダムブラインドノンスは、種々の方法で決定されてよい。例えば、一方の取引先は、ランダムブラインドノンスを生成し、他方のパーティ又は複数のパーティは一方のパーティに承認／賛成を伝達し得る。代替として,各パーティは、ランダムブラインドノンスの一部を生成し、生成した部分の全部が、数学的アルゴリズムに従い結合されて、ランダムブラインドノンスを形成する。

【0130】

幾つかの実施形態では、６１４で、取引先は図３のコントラクト公開鍵３１６と同様の、スマートコントラクトの公開鍵を生成し／合意する。実施形態では、公開鍵は、ランダムブラインドノンスに対応する（例えば、ブラインドノンスが秘密鍵であり、公開鍵がブラインドノンスに対する楕円曲線公開鍵である）。幾つかの実施形態では、コントラクト公開鍵は、６１６でメンバにより生成された成り行き公開鍵の各々と結合される。６１６では、グループメンバは、グループ公開鍵、及び、コントラクトの結果の各々について成り行き公開鍵、を生成することに留意する。グループ公開鍵及び成り行き鍵は、上述のようにディーラ不要の秘密分散プロトコルを用いて生成されてよいことに留意する。各グループメンバは、成り行き公開鍵に対応する秘密鍵シェアを有してよい。秘密鍵シェアは、図６の６０４で取引先により指定された一致する投票の数の閾を勝者の成り行きの成り行き公開鍵に対応する完全な秘密鍵を再生成するために必要な鍵シェアの数として用いて、本開示に記載のように秘密分散プロトコルを用いて生成されてよい。実施形態では、グループメンバは、グループ公開鍵、及び成り行き公開鍵を、取引先に、６０８－１２で確立された通信媒体を介して提供する。

【0131】

幾つかの実施形態では、６１８で、取引先のうちの少なくとも１つは、６１６でメンバグループにより生成された成り行き公開鍵の各々を６１２で生成されたランダムブラインドノンスと結合することにより、コントラクト条件公開鍵を生成する。この方法では、コントラクト条件公開鍵は、６２０で生成されたスマートコントラクトトランザクションの中で、グループメンバから隠される。幾つかの実施形態では、６２０で、スマートコントラクトトランザクションが、取引先により生成され署名され、取引先の各々が合意した資金（例えば、デジタルアセットの量）と共にブロックチェーンにコミットされることに留意する。スマートコントラクトトランザクションは、コントラクトの成り行きに依存して、一方又は両方の取引先に支払い可能な量の各々について、別個のUTXOを有してよい。

【0132】

最終的に、幾つかの実施形態では、６２２で、取引先は、図３の協調アルゴリズムトランザクション３３２と同様の協調アルゴリズムトランザクションを生成する。幾つかの実施形態では、協調アルゴリズムトランザクションは、UTXOとして、グループメンバからのデポジットを含む。該デポジットは、グループメンバが彼らの回答を提出した後に又は期限切れの後に、６１６でメンバグループにより生成されたグループ公開鍵からの署名により支払われてよい。幾つかの実施形態では、協調アルゴリズムトランザクションは、追加又は代替として、グループ公開鍵を使用することによる署名により又は期限切れ後の取引先の署名によりアンロック可能な、取引先により提供された分配を含んでよい。幾つかの実施形態では、UTXOは、同じ協調アルゴリズムトランザクションの中にあってよい。一方、他の実施形態では、UTXOは別個のトランザクションの中にあってよい。６０２－２２で実行された動作のうちの１つ以上は、並行を含む種々の順序及び組み合わせで実行できることに留意する。

【0133】

図７は、種々の実施形態による、スマートコントラクトを実行するプロセス７００の一例を示す流れ図である。プロセス７００（又は記載された任意の他のプロセス、又はそれらのプロセスの変形及び／又は結合）の一部又は全部は、実行可能命令及び／又は他のデータにより構成される１つ以上のコンピュータシステムの制御下で実行でき、１つ以上のプロセッサ上で共同で実行する実行可能命令として実装されてよい。実行可能命令及び／又は他のデータは、非一時的コンピュータ可読記憶媒体に格納され得る（例えば、磁気、光、又はフラッシュ媒体に永久的に記憶されたコンピュータプログラム）。

【0134】

例えば、プロセス７００の一部又は全部は、１つ以上のコンピューティング装置（例えば、データセンタのサーバによる、クライアントコンピューティング装置による、コンピューティングリソースサービスプロバイダの分散型システムの中の複数のコンピューティング装置による、又は図８のコンピューティング装置８００のような任意の適切なクライアント装置による）により実行できる。プロセス７００は一連の動作を含み、ここで、メンバは、彼らの回答鍵シェア（answer key shares）をコミット及び開示し、閾数の一致する回答が存在する場合には、合意回答に関連付けられた秘密成り行き鍵が決定でき、それから完全な成り行き署名鍵が計算できる。

【0135】

幾つかの実施形態では、開始時間が始まった後に、グループメンバの各々は、スマートコントラクトトの成り行きに関して特定の時間枠内で決定を行う。特定の時間枠は、図４のゴーストチェーン４３４のようなゴーストチェーンのブロック高及びブロック間隔に依存してよい。上述の例では、５のブロック高及び１日のブロック間隔が、グループメンバの解答を決定するために、グループメンバに５日間を与える。

【0136】

時間期間の終わりに、幾つかの実施形態では、７０２で、グループメンバの各々は、彼ら自身の決定した回答に対応する鍵シェアを、図４の混みと４２４として示ゴーストチェーン内のブロックにコミットする。これは、図４のコミット４２４として示される。上述のように、各グループメンバは、特定の回答のグループメンバの鍵シェアの単純なハッシュ（例えば、SHA-２５６）として、回答を提出してよい。幾つかの実施形態では、グループメンバの必ずしも全員が、彼らの回答を同じブロック内で提出する必要がないことに留意する。例えば、グループメンバが５日間のうちの３日目に彼／彼女の回答に到達した場合、該グループメンバは、彼らの回答を３番目のブロックで提出してよい。

【0137】

幾つかの実施形態では、７０４で、ゴーストチェーン内の次のブロックで、メンバが彼らのコミットメントを開示する。これは、図４の開示４２６に示され、開示のハッシュを前のコミットのハッシュと比較することにより検証できる。幾つかの実施形態では、７０６で、有効な成り行き秘密鍵に対応する秘密鍵を構成するために鍵シェアの数が十分か否かが決定される。十分でない場合、７０８で、取引先は、彼らの資金を回収してよく、メンバは、彼らのデポジットを返金されてよい。このような例では、幾つかの実施形態で、合意回答に達しなかったので、メンバは、分配を受け取らなくてよく、又は少ない分配を受け取ってよい。

【0138】

あるいは、幾つかの実施形態では、７１０で、勝者の成り行き秘密鍵が生成される。勝者の回答を提出したメンバは、７１２で、分配を収集しメンバデポジットを返金するために生成された、図５の分配トランザクション５３２Ｂのようなトランザクションに共同で署名できる。勝者の成り行き秘密鍵は、グループにより取引先に提供されてよい。この取引先は、７１４で、勝者の成り行き秘密鍵を、ランダムブラインドノンスと結合して、完全な成り行き署名鍵（例えば、図５の完全な成り行き署名鍵５２６）を生成してよい。

【0139】

幾つかの実施形態では、７１６で、取引先の各々は、成り行きトランザクション５２０Ｂと同様の成り行きトランザクションに、彼ら自身の秘密鍵を用いて生成した署名、及び完全な成り行き署名鍵を用いて生成した署名、を用いて署名でき、それにより、図６の６０２で合意したようなスマートコントラクトの成り行きに適する資金を請求する。７０２-１６で実行された動作のうちの１つ以上は、並行を含む種々の順序及び組み合わせで実行できることに留意する。

【0140】

開示の実施形態を説明する文脈で、特に断りのない限り、「命令」が通常助けなしに実行する動作（例えば、データの送信、計算、等）を実行する実行可能命令（コード、アプリケーション、エージェント、等とも呼ばれる）に関する表現の使用は、命令が機械により実行され、それにより機械に特定の動作を実行させることを示す。

【0141】

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

【0142】

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

【0143】

幾つかの実施形態では、ユーザインタフェース入力装置８１２は、キーボード、統合型マウス、トラックボール、タッチパッド、又はグラフィックタブレットのような指示装置、スキャナ、バーコードスキャナ、ディスプレイに組み込まれたタッチスクリーン、音声認識システム、マイクロフォンのようなオーディオ入力装置、及び他の種類の入力装置のような、１つ以上のユーザ入力装置を含む。通常、用語「入力装置」の使用は、コンピューティング装置８００に情報を入力する全ての可能な種類の装置及びメカニズムを含むことを意図する。幾つかの実施形態では、１つ以上のユーザインタフェース出力装置８１４は、ディスプレイサブシステム、プリンタ、又はオーディオ出力装置のような非視覚的ディスプレイ、等を含む。幾つかの実施形態では、ディスプレイサブシステムは、陰極線管（CRT）、液晶ディスプレイ（LCD）、発光ダイオード（LED）ディスプレイ、又はプロジェクションのような平面装置、又は他のディスプレイ装置を含む。通常、用語「出力装置」の使用は、コンピューティング装置８００から情報を出力する全ての可能な種類の装置及びメカニズムを含むことを意図する。１つ以上のユーザインタフェース出力装置８１４は、例えば、ユーザインタフェースを提示して、ここに記載したプロセス及び変形を実行するアプリケーションとのユーザ相互作用が適切であるとき、そのような相互作用を実現するために使用できる。

【0144】

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

【0145】

実施形態では、メモリサブシステム８０８は、プログラム実行中に命令及びデータを記憶するための主ランダムアクセスメモリ（RAM）８１８、及び／又は固定命令が格納できる読み出し専用メモリ（ROM）８２０のような多数のメモリを含む。幾つかの実施形態では、ファイル／ディスク記憶サブシステム８１０は、プログラム及びデータファイルのための非一時的持続性（不揮発性）記憶を提供し、ハードディスクドライブ、関連する取り外し可能媒体と一緒のフロッピディスクドライブ、コンパクトディスク読み出し専用メモリ（CD-ROM）ドライブ、光ドライブ、取り外し可能媒体カートリッジ、又は他の同様の記憶媒体を含み得る。

【0146】

幾つかの実施形態では、コンピューティング装置８００は、少なくとも１つのローカルクロック８２４を有する。ローカルクロック８２４は、幾つかの実施形態では、特定の開始日から刻んだ時の数を表すカウンタを表し、幾つかの実施形態では、コンピューティング装置８００の内部に配置される。種々の実施形態では、ローカルクロック８２４は、コンピューティング装置８００及びそれに含まれるサブシステムのためのプロセッサ内のデータ転送を特定のクロックバルスで同期化するために使用され、コンピューティング装置８００とデータセンタ内の他のシステムとの間の動機動作を調整するために使用できる。別の実施形態では、ローカルクロックは、プログラム可能な内部タイマである。

【0147】

コンピューティング装置８００は、ポータブルコンピュータ装置、タブレットコンピュータ、ワークステーション、又は後述する任意の他の装置を含む種々のタイプのうちの任意のものであってよい。さらに、コンピューティング装置８００は、幾つかの実施形態では、１つ以上のポート（例えば、USB、ヘッドフォンジャック、光コネクタ、等）を通じてコンピューティング装置８００に接続可能な別の装置を含み得る。実施形態では、このような装置は、光ファイバコネクタを受けるよう構成されるポートを含む。したがって、幾つかの実施形態では、この装置は、光信号を、処理のために装置を接続するポートを通じてコンピューティング装置８００に送信される電気信号に変換するよう構成される。コンピュータ及びネットワークの絶えず変化する特性により、図８に示したコンピューティング装置８００の説明は、装置の好適な実施形態を説明する目的の特定の例としてのみ意図される。図８に示したシステムより多くの又は少ないコンポーネントを有する多くの他の構成が可能である。

【0148】

明細書及び図面は、したがって、限定的意味ではなく説明的であると考えられるべきである。しかしながら、これらへの種々の変更及び変化が、特許請求の範囲に記載された発明の範囲から逸脱することなく行われてよいことが明らかである。同様に、他の変形は、本開示の範囲内にある。したがって、開示の技術は種々の変更及び代替構成を受けるが、その特定の図示の実施形態が図示され、詳細に上述された。しかしながら、本発明を開示の１又は複数の特定の形式に限定する意図はなく、反対に、添付の特許請求の範囲に定められるように、本発明の範囲に包含される全ての変更、代替構成、均等物をカバーすることを意図する。

【0149】

開示の実施形態を記載する文脈における用語「a」及び「an」、「the」及び同様の参照は（特に以下の特許請求の範囲の文脈では）、文脈上特に示され又は明確に否定されない限り、単数及び複数の両方をカバーすることを意図する。用語「有する」、「含む」（comprising、having、including、containing）等は、特に断りのない限り、制限のない用語（つまり、「含むがそれに限定されない」を意味する）と考えられるべきである。用語「接続される（connected）」は、未修飾であり物理的接続を参照するとき、仲介物がない場合でも、部分的または全体的に含まれる、付加される、又は一緒に結合されると考えられるべきである。本開示における値の範囲の記載は、特に断りのない限り、単に、その範囲に含まれる各々の個別の値を個々に参照することの簡略表記法として機能し、各別個の値は個々に記載されたように本明細書に組み込まれると考えられるべきである。用語「セット又は集合」（例えば、「アイテムのセット」）又は「サブセット又は部分集合」の使用は、特に断りのない限り又は文脈上否定されない限り、１つ以上の構成要素を含む空ではない集合であると考えられるべきである。さらに、特に断りのない限り又は文脈上否定されない限り、対応するセットの用語「サブセット」は、必ずしも、対応するセットの真部分集合を示さず、サブセット及び対応するセットは等しくてもよい。

【0150】

結合的言語、例えば「A、B、及びCのうちの少なくとも１つ」又は「A、B及びCのうちの少なくとも１つ」は、特に断りのない限り又は文脈上特に明確に否定されない限り、通常、アイテム、用語、等が、A又はB又はCのいずれか、又はA及びB及びCのセットのうちの空でない任意のサブセットであり得ることを表すために使用されると文脈上理解される。例えば、３人のメンバを有するセットの説明のための例では、結合的フレーズ「A、B、及びCのうちの少なくとも１つ」又は「A、B及びCのうちの少なくとも１つ」は、以下のセット{A}、{B}、{C}、{A,B}、{A,C}、{B,C}、{A,B,C}のいずれかを表す。したがって、このような結合的言語は、通常、特定の実施形態が少なくとも１つのA、少なくとも１つのB、及び少なくとも１つのCがそれぞれ存在することを必要とすることを意味することを意図しない。

【0151】

記載のプロセスの動作は、特に断りのない限り又は文脈上明確に否定されない限り、任意の適切な順序で実行できる。記載のプロセス（又は変形及び／又はそれらの結合）は、実行可能命令により構成された１つ以上のコンピュータシステムの制御下で実行でき、ハードウェア又はその組み合わせにより１つ以上のプロセッサ上で連携して実行するコード（例えば、実行可能命令、１つ以上のコンピュータプログラム又は１つ以上のアプリケーション）として実装できる。幾つかの実施形態では、コードは、コンピュータ可読記憶媒体に、例えば１つ以上のプロセッサにより実行可能な複数の命令を有するコンピュータプログラムの形式で格納できる。幾つかの実施形態では、コンピュータ可読記憶媒体は、非一時的である。

【0152】

任意の及び全ての例の使用、又は提供された例示的な言語（例えば「のような（such as）」）は、単に、本発明の実施形態をより良好に解明することを意図しており、特に断りのない限り本発明の範囲に限定を課すものではない。明細書中のいかなる言語も、任意の請求されない要素を本発明の実施に必須であることを示すと考えられるべきではない。

【0153】

本発明を実施するために発明者に知られたベストモードを含む本開示の実施形態が記載された。種々のこれらの実施形態は、前述の説明を読むことにより、当業者に明らかになる。発明者は、当業者がこのような変形を適切に利用することを期待し、発明者は、本開示の実施形態が特に記載されたものと異なる方法で実施されることを意図する。したがって、本開示の範囲は、適用される法により許容されるように、添付の特許請求の範囲に記載された主題の全ての変更及び均等物を含む。さらに、それらの全ての可能な変形における上述の要素の任意の組み合わせは、特に断りのない限り又は文脈上特に明確に否定されない限り、本開示の範囲により包含される。

【0154】

刊行物、特許出願、及び特許を含む全ての引用された文献は、参照により、各文献が個々に及び具体的に示されたように、及びその全体が記載されたように、ここに組み込まれる。

【0155】

上述の実施形態は、本発明を限定するのではなく、説明すること、及び当業者は添付の特許請求の範囲により定められる本発明の範囲から逸脱することなく多くの代替的実施形態を考案できることに留意すべきである。特許請求の範囲において、括弧内の任意の参照符号は、請求項を限定することを意図しない。用語「有する」及び「含む」（comprising、comprises）等は、任意の請求項又は明細書全体に列挙されたもの以外の要素またはステップの存在を排除しない。本願明細書では、「有する」は「有する又は構成される」を意味し、「含む」は「含む又は構成される」を意味する。要素の単数の参照は、該要素の複数の参照を排除しない。逆も同様である。本発明は、幾つかの別個の要素を含むハードウェアにより、及び適切にプログラムされたコンピュータにより、実装できる。幾つかの手段を列挙する装置クレームでは、これらの手段のうちの幾つかは、１つの同じハードウェアアイテムにより具現化できる。単に特定の手段が相互に異なる従属請求項に記載されるという事実は、これらの手段の組み合わせが有利に使用されないことを示さない。

【0156】

＜まとめ＞
本開示に記載し示唆した新規な技術は、ブロックチェーンデータ構造の中に格納されたデータの完全性を保障するというブロックチェーンの特性を崩壊させずに、ブロックチェーンの機能を拡張する。例えば、これらの技術は、特に、検証の条件がレコードに埋め込まれたブロックチェーントランザクションの中で定義されるデジタルレコード検証の分野で、ブロックチェーン上のトラストレスな方法で、現実世界のイベントに関する正確な客観的情報を取得するための方法を実行し及び行うことにより、コンピューティングの分野を向上する。さらに、本開示に記載され示唆された技術は、一時的なproof-of-stakeブロックチェーンを利用して、スマートコントラクトの成り行きを決定するために分散型の信頼できるオラクルとして動作するようにされた参加者の投票を管理することにより、ブロックチェーンネットワークの中でスマートコントラクトの実行を向上し得る。

【0157】

さらに、本開示に記載され示唆された技術は、成り行きを決定するようにされた参加者からスマートコントラクトを難読化することにより、それにより、取引先のプライバシーを維持し、参加者が成り行きプロトコルを転覆させるために共謀する理由を除去し、具体的にスマートコントラクトの成り行きを操作するリスクと共に生じる問題を克服するために、必然的にコンピュータ技術に根ざす。さらに、Schelling協調のようなゲーム理論の概念を利用することにより、匿名の参加者は、プロトコルに正確な情報を提供する理由を与えられ得る。

【符号の説明】

【0158】

１００ ブロックチェーンネットワーク
１０２ ノード
１０４ トランザクション

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】