特許 7436580 ブロックチェーンネットワーク上のタイムリリース暗号化のためのコンピュータにより実施されるシステム及び方法

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

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

(11)【特許番号】

(24)【登録日】2024-02-13

(45)【発行日】2024-02-21

(54)【発明の名称】ブロックチェーンネットワーク上のタイムリリース暗号化のためのコンピュータにより実施されるシステム及び方法

(51)【国際特許分類】

   H04L 9/32 20060101AFI20240214BHJP

   H04L 9/08 20060101ALI20240214BHJP

【ＦＩ】

H04L9/32 200Z

H04L9/08 A

H04L9/08 F

【請求項の数】 14

【外国語出願】

(21)【出願番号】P 2022120410

(22)【出願日】2022-07-28

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

【原出願日】2018-06-11

(65)【公開番号】P2022141947

(43)【公開日】2022-09-29

【審査請求日】2022-07-28

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

(32)【優先日】2017-06-19

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

(73)【特許権者】

【識別番号】318001991

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

(74)【代理人】

【識別番号】100107766

【弁理士】

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

(74)【代理人】

【識別番号】100070150

【弁理士】

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

(74)【代理人】

【識別番号】100135079

【弁理士】

【氏名又は名称】宮崎 修

(72)【発明者】

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

【審査官】行田 悦資

(56)【参考文献】

【文献】特表２０１３－５０６３８８（ＪＰ，Ａ）

【文献】特開２００６－１２９３４０（ＪＰ，Ａ）

【文献】米国特許出願公開第２００８／０３１０６２７（ＵＳ，Ａ１）

【文献】PUDDU, I. et al.，μchain: How to Forget without Hard Forks，2017年02月10日，pp.1-21，Cryptology ePrint Archive: Report 2017/106，［令和4年2月8日検索］，インターネット<URL:https://eprint.iacr.org/2017/106>

【文献】三島 貴務，ブロックチェーンを用いた電子契約プロトコル，電子情報通信学会技術研究報告，日本，一般社団法人電子情報通信学会，2017年06月01日，第117巻，第79号，pp.31-35

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

Ｈ０４Ｌ ９／３２

Ｈ０４Ｌ ９／０８

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

【請求項1】

ブロックチェーンネットワークにおいて公開暗号鍵を生成し、指定時間期間の後に対応する秘密暗号鍵へのアクセスを可能にする、コンピュータにより実施される方法であって、前記方法は処理リソースにより実施され、前記方法は、
前記ブロックチェーンネットワーク上のエージェントとクライアントとの間のデジタルタイムロックコントラクトを構成するステップであって、前記エージェントは前記ブロックチェーンネットワーク上のエージェントアドレスと関連するエージェント署名とを有し、前記クライアントは前記ブロックチェーンネットワーク上のクライアントアドレスと関連するクライアント署名とを有し、前記デジタルタイムロックコントラクトは、
前記エージェントからの第１暗号化アセット、
前記クライアントからの第２暗号化アセット、
暗号公開鍵、
前記エージェントが前記暗号公開鍵に対応する暗号秘密鍵を公開すべき時間ウインドウであって、前記時間ウインドウは、前記時間ウインドウが開始する時間ｔと、前記時間ウインドウが終了する時間期間Δtとにより定義される、時間ウインドウ、
を指定し、
前記デジタルタイムロックコントラクトは、以下の転送が可能であるように構成され：
前記第２暗号化アセットが、前記暗号秘密鍵、前記暗号秘密鍵から導出可能なタイムロックパズル値、及び前記クライアント署名により、いつでも前記クライアントアドレスへ転送可能である、
前記第２暗号化アセットが、前記暗号秘密鍵及び前記エージェント署名により、時間tの後に、前記エージェントアドレスへ転送可能である、
前記第２暗号化アセットは、前記クライアント署名により、時間t+Δtの後に、前記クライアントアドレスへ転送可能である、
前記第１暗号化アセットは、前記暗号秘密鍵、及び前記暗号秘密鍵から導出可能なタイムロックパズル値を提供することにより、いつでも任意のアドレスへ転送可能である、
前記第１暗号化アセットは、前記暗号秘密鍵及び前記エージェント署名により、時間tの後に、前記エージェントアドレスへ転送可能である、
前記第１暗号化アセットは、前記クライアント署名により、時間t+Δtの後に、前記クライアントアドレスへ転送可能である、ステップを含む方法。

【請求項2】

前記第１暗号化アセットは、前記エージェントからのデポジットである、請求項１に記載の方法。

【請求項3】

前記第２暗号化アセットは、前記クライアントからの手数料である、請求項１又は２に記載の方法。

【請求項4】

前記エージェントは、複数のクライアントと、複数のデジタルタイムロックコントラクトに参加する、請求項１～３のいずれかに記載の方法。

【請求項5】

前記エージェントは、前記暗号秘密鍵を保持する単一のエージェントを含む、請求項１～４のいずれかに記載の方法。

【請求項6】

前記エージェントは、各々が前記暗号秘密鍵のシェアを保持する複数のエージェントを含む、請求項１～４のいずれかに記載の方法。

【請求項7】

前記第１暗号化アセット及び前記第２暗号化アセットは、前記複数のエージェントの間で分割され、
前記暗号秘密鍵の導出は、閾数の秘密鍵シェアが前記複数のエージェントにより提供されることにより実施される、請求項６に記載の方法。

【請求項8】

前記方法は、
ブロックチェーン上でマイニングするために、前記ブロックチェーンネットワークへ、前記デジタルタイムロックコントラクトをブロードキャストするステップを更に含む請求項１～７のいずれかに記載の方法。

【請求項9】

前記デジタルタイムロックコントラクトは、前記ブロックチェーン内にマイニングされた後にアクティブになり、前記暗号公開鍵は、データを暗号化するために使用されるよう公衆に利用可能であり、前記データは、前記暗号秘密鍵が公開されるまで、復号できない、請求項８に記載の方法。

【請求項10】

前記方法は、前記クライアントがデジタルタイムロックコントラクトを設定したい要望を示す要求を送信することにより開始される、請求項１～８のいずれかに記載の方法。

【請求項11】

前記エージェントは、前記暗号公開鍵及び前記暗号秘密鍵のペアを構成する、請求項１～９のいずれかに記載の方法。

【請求項12】

前記時間ウインドウは、前記時間ウインドウが開始する時間t、及び前記時間ウインドウが終了する時間期間Δtとして指定される、請求項１～１１のいずれかに記載の方法。

【請求項13】

コンピュータ実行可能命令を含むコンピュータ可読記憶媒体であって、前記コンピュータ実行可能命令は、実行されると、プロセッサを、請求項１～１２のいずれか一項に記載の方法を実行するよう構成する、コンピュータ可読記憶媒体。

【請求項14】

電子装置であって、
インタフェース装置と、
前記インタフェース装置に結合されたプロセッサと、
前記プロセッサに結合されたメモリであって、前記メモリはコンピュータ実行可能命令を格納し、前記コンピュータ実行可能命令は、実行されると、前記プロセッサを、請求項１～１２のいずれか一項に記載の方法を実行するよう構成する、メモリと、
を含む電子装置。

【発明の詳細な説明】

【技術分野】

【0001】

本願明細書は、概して、タイムリリース暗号化のためのデジタルタイムロックコントラクトに関する。本発明は、限定ではないが、特にビットコインブロックチェーンと共に使用することに適する。

【背景技術】

【0002】

本願明細書で、用語「ブロックチェーン」は、あらゆる形式の電子的な、コンピュータに基づく、分散台帳を含むよう使用される。これらは、総意に基づくブロックチェーン及びトランザクションチェーン技術、許可及び未許可台帳、共有台帳、及びそれらの変形を含む。最も広く知られているブロックチェーン技術の用途はビットコイン台帳であるが、他のブロックチェーンの実装が提案され開発されている。ビットコインは便宜上及び説明を目的として本願明細書において言及されるが、本発明はビットコインのブロックチェーンと共に使用することに限定されず、代替のブロックチェーンの実装及びプロトコルが本発明の範囲に含まれることに留意すべきである。

【0003】

ブロックチェーンは、ブロックにより構成される、コンピュータに基づく非集中型の分散型システムとして実装される総意に基づく電子台帳である。また、ブロックはトランザクション及び他の情報により構成される。ビットコインの場合には、各トランザクションは、ブロックチェーンシステム内で参加者間のデジタルアセットの制御の転送を符号化するデータ構造であり、少なくとも１つのインプット及び少なくとも１つのアウトプットを含む。各ブロックは前のブロックのハッシュを含み、ブロックは共にチェーンになって、その発端からブロックチェーンに書き込まれている全てのトランザクションの永久的な変更不可能なレコードを生成する。トランザクションは、そのインプット及びアウトプットに組み込まれたスクリプトとして知られる小さなプログラムを含む。スクリプトは、トランザクションのアウトプットがどのように及び誰によりアクセス可能かを指定する。ビットコインプラットフォーム上で、これらのスクリプトは、スタックに基づくスクリプト言語を用いて記述される。

【0004】

トランザクションがブロックチェーンに書き込まれるために、「検証され」なければならない。幾つかのネットワークノードは、マイナーとしての機能を果たし、各トランザクションが有効であることを保証するために作業を実行し、無効なトランザクションはネットワークから拒否される。例えば、ノードにインストールされたソフトウェアクライアントは、未使用トランザクションアウトプット（unspent transaction outputs：UTXO）を参照するトランザクションに対して、この検証作業を実行する。検証は、そのロック及びアンロックスクリプトを実行することにより実行されてよい。ロック及びアンロックスクリプトの実行が真と評価した場合、及び特定の他の条件が満たされた場合、トランザクションは有効であり、トランザクションはブロックチェーンに書き込まれる。したがって、トランザクションがブロックチェーンに書き込まれるためには、トランザクションは、ｉ）トランザクションを受信したノードにより検証され、トランザクションが検証された場合に、ノードは該トランザクションをネットワーク内の他のノードに中継し、ｉｉ）マイナーにより構築された新しいブロックに追加し、ｉｉｉ）マイニングされ、つまり過去のトランザクションの公開台帳に追加されなければならない。トランザクションは、充分な数のブロックがブロックチェーンに追加されて、トランザクションが事実上不可逆にされると、確認されたと見なされる。

【0005】

ブロックチェーン技術は、暗号通貨実装の使用で最も広く知られているが、デジタル起業家が、新しいシステムを実装するために、ビットコインの基づく暗号通貨セキュリティシステム、及びブロックチェーンに格納可能なデータの両方の使用を探索し始めている。ブロックチェーンが、暗号通貨の領域に限定されない自動タスク及びプロセスのために使用できれば、非常に有利である。このようなソリューションは、それらの用途において一層多様でありながら、ブロックチェーンの利点（例えば、永久的、イベントの耐タンパレコード、分散プロセス、等）を利用できる。

【0006】

研究の一分野は、「スマートコントラクト（smart contracts）」の実装のためのブロックチェーンの使用である。これらは、機械可読取引又は合意の条件の実行を自動化するために設計されたコンピュータプログラムである。自然言語で記述され得る従来の取引と異なり、スマートコントラクトは、結果を生成するためにインプットを処理できるルールを含み、該結果に依存して動作を実行させることのできる、機械実行可能プログラムである。

【0007】

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

【0008】

前述のように、本願明細書は、概して、タイムリリース暗号化のためのデジタルタイムロックコントラクトに関する。タイムリリース暗号化の基本的目的は、メッセージが現時点では暗号化できるが、将来の何らかの指定された時間まで誰にも復号できないことである。これは、事実上、「将来にメッセージを送る」又はメッセージを「タイムカプセル」に入れる方法である。以下を含む、この種の機能の多くの可能な用途がある。
・秘密ビッドオークション
・鍵エスクロー方式
・受理証不要の投票
・機密データのタイムリリース
・政治的に慎重を期する情報の「デッドマン装置」

【0009】

タイムリリース暗号化システムを実装するための２つの一般的アプローチがあり、これらは１９９６年のRivest, Shamir、及びWagnerによる着想についての最初の詳細な論文[Rivest１９９６]に概説された。これらは以下の通りである。
１．「タイムロックパズル」の使用。復号するために時間の掛かる計算作業を必要とする情報の暗号化。
２．将来の指定時間まで、秘密情報を漏らさないことを約束する信頼できるエージェントの使用。

【0010】

これらのアプローチのうちの前者は、第三者の関与を必要としないが、２つの深刻且つ不可避な欠点がある。つまり、第１に、計算ハードウェアの性能差及び未知の将来の技術革新のために、特定のパズルを解くためにどれくらい長く掛かるかを高精度に予測することができないことである。第２に、復号を実行するパーティは、タイムロックの期間全体の間、連続する高コストな計算作業を実行しなければならない。

【0011】

後者のアプローチは、公開のタイミングにおいて正確且つ精密である潜在能力を有し、また、任意のパーティに高価な計算を実行することを要求しない。しかしながら、正しい時間に正しい鍵を公開するために、信頼されなければならない第三者エージェントに依存する。正しく動作を実行するようエージェントが効果的に奨励されない限り、エージェントにおける信頼は、従って重大である。

【0012】

ブロックチェーンネットワーク上のタイムロック暗号化に関する背景情報は、以下に纏められる。

【0013】

「Ethereum Alarm Clock」は、ユーザが、デポジットを提供した後に、スケジューリングされた時間期間にトランザクションを実行できることを提供する。例えば以下のURLを参照する：docs.ethereum－alarm－clock.com/en/latest/claiming.html#claim－deposit;及びhttps://github.com/pipermerriam/ethereum－alarm－clock/commits/master/docs/claiming.rst。これは、後の時点における及び特定時間ウインドウの間のイベントのスケジューリングを可能にする。さらに、実行者は、デポジットを取り戻すことができるが、指定時間ウインドウ内に実行が行われなかった場合にはデポジットを喪失し得る。支払は、また、スケジューリングされた時間にトランザクションを実行するアカウントに支払われるサービスに含まれる。

【0014】

「μchain: How to Forget without Hard Forks」(URL: https://eprint.iacr.org/２０１７/１０６.pdf)は、タイムロック暗号化の一例を開示する。開示の使用例では、ユーザは機密書類を暗号化する。復号者は、期限tが経過したかどうかをチェックする機能をトリガするスマートコントラクトへトランザクションを送信することにより、復号鍵へのアクセスを要求する。時間が正しい場合、復号者は鍵を取得する。システムが、特定時間ウインドウ内に要求された場合にのみ復号鍵を利用可能にするような、より高度な機能を提供できることが、提案される。

【0015】

「Secure Multiparty Computations on Bitcoin」(URL: https://eprint.iacr.org/２０１３/７８４.pdf)は、ビットコイン通貨を用いるマルチパーティくじ引きのためのプロトコルを開示する。この文献は、ビットコインシステムが、コミッターが彼の秘密を特定時間フレーム内に暴露しなければならない又は罰金を支払わなければならない、定時コミットメントのバージョンを構成するための魅力的な方法を提供することを示す。デポジットは、誠実に振る舞わない参加者によりゲームが早く終わる場合に、没収される参加者により提供される。

【0016】

US２０１６０８６１７５は、資産にアクセスするブロックチェーンシステムを開示する。ルーム（room）は、特定期間の間、部屋を借りたいと望むユーザによりクレジットがデポジットされるアドレスと共に、秘密／公開鍵ペアを有し、これらのデータはトランザクションに含まれる。時間が正しいとき、解錠され、ユーザは部屋に入ることを許可される。部屋が要求された時間の間、利用可能でない場合、返金される部屋へのアクセスを得るために、ユーザにより部屋の提供者に料金が支払われる。

【発明の概要】

【0017】

本願明細書は、タイムリリース暗号化サービスを許可無しパブリックブロックチェーンによりセキュアにすることを可能にするシステム及び方法を記載する。サービスは、公開鍵を生成し、次にサービスのクライアントにより指定された将来の時間に対応する秘密鍵を公開する。このサービスのセキュリティ及び信頼性は、新規なスマートコントラクトシステムから得られ、一例ではビットコインスクリプトとして実装される。これは、秘密鍵を正しい時間に公開することを奨励し、早い又は遅い公開又は鍵の漏洩に不利益をもたらす。サービスは、信頼できない設計である。つまり、クライアントは秘密鍵へのアクセスを与えられないが、彼らは、正しい値がコントラクト内で指定された時間にブロックチェーン上に公開されるという保証と共に、サービスの暗号化アセットを提供するだけである。一例では、これは、トランザクションアウトプットのタイムロック及びハッシュロックと組み合わされたゼロ知識証明により達成される。

【0018】

本発明の第１の態様によると、ブロックチェーンネットワーク上で公開暗号鍵を生成し及び指定時間期間の後に対応する秘密暗号鍵へのアクセスを可能にする、コンピュータにより実施される方法であって、前記方法は、
前記ブロックチェーンネットワーク上のエージェントとクライアントとの間のデジタルタイムロックコントラクトを構成するステップであって、前記エージェントは前記ブロックチェーンネットワーク上のエージェントアドレスと関連するエージェント署名とを有し、前記クライアントは前記ブロックチェーンネットワーク上のクライアントアドレスと関連するクライアント署名とを有し、前記デジタルタイムロックコントラクトは、
（ｉ）前記エージェントが、前記ブロックチェーンネットワーク上の前記公開暗号鍵に対応する前記秘密暗号鍵を保持し、次に前記暗号秘密を前記ブロックチェーンネットワークへ指定時間ウインドウ内に公開すること、
（ｉｉ）前記エージェントが、保持するために第１暗号化アセット（例えばデポジット）を提供し、次に前記暗号秘密鍵を前記ブロックチェーンネットワークに前記指定時間ウインドウ内に公開し、前記第１暗号化アセットは、前記暗号秘密鍵が前記ブロックチェーンネットワーク上に前記指定時間ウインドウ内に公開されるとき、前記ブロックチェーンネットワーク上の前記エージェントアドレスへ転送可能であること、
（ｉｉｉ）前記クライアントは、保持するために第２暗号化アセット（例えば料金）を前記エージェントに提供し、次に前記暗号秘密鍵を前記ブロックチェーンネットワークに前記指定時間ウインドウ内に公開し、前記第２暗号化アセットは、前記暗号秘密鍵が前記ブロックチェーンネットワークに前記指定時間ウインドウ内に公開されるとき、前記ブロックチェーンネットワーク上の前記エージェントアドレスへ転送可能であること、
(iv)前記暗号秘密鍵が前記時間ウインドウの始まる前に公開される場合、前記第２暗号化アセットは、前記ブロックチェーンネットワーク上の前記クライアントアドレスへ転送可能であること（前記クライアント又は他の誰かが、前記エージェントの前記第１暗号化アセットを取り込むために前記秘密鍵を使用してよい）、
(v)前記暗号秘密鍵が前記時間ウインドウの終わる前に公開されない場合、前記第２暗号化アセットは前記ブロックチェーンネットワーク上の前記クライアントアドレスへ転送可能であること（前記第１暗号化アセットは、前記ブロックチェーンネットワーク上の前記クライアントアドレスへも転送可能であってよい）、
を指定する、ステップ、
前記ブロックチェーン上でのマイニングのために、前記デジタルタイムロックコントラクトを前記ブロックチェーンネットワークへブロードキャストするステップ、
のうちの一方又は両方を含む、コンピュータにより実施される方法が提供される。

【0019】

前記デジタルタイムロックコントラクトを構成するステップ、及び前記コントラクトをブロードキャストするステップは、同じエンティティにより実行されてよい。しかしながら、これらのステップは異なるエンティティにより実行され得ることも考えられる。ここで、前述の定義は、任意の単一エンティティにより要求されているステップの一方又は両方を指定する。

【0020】

留意すべきことに、ここに記載される本発明は、ビジネスを行うより良い方法として、ブロックチェーンで実装されるタイムロックコントラクトを提供するだけではない。本発明の開始点は、暗号化方法を用いてタイムロックコントラクトを実装することが知られていることである。しかしながら、これらの従来のシステムは技術的問題を有する。従来技術に伴う技術的問題は、それらがセキュアでなく、又はそれらの使用が困難であり計算集約的であり得ることである。これらの問題は生来技術的である。本発明は、セキュアであり且つ利用が容易であり且つ計算効率的なソリューションを提供する。つまり、本発明は、タイムロックコントラクトを信頼不要な方法で実装するために、セキュリティと低計算オーバヘッドを組み合わせるシステムを提供するという観点で、より良いコンピュータシステムを提供する。セキュリティ、使用の容易さ、及び計算効率の組み合わせを提供することは、本発明の技術的貢献である。

【0021】

前記コンピュータにより実施される方法は、前記クライアントが、デジタルタイムロックコントラクトを設定する要望を示す要求を送信することにより、開始され得る。前記クライアントは、前記第２暗号化アセット及び前記タイムウインドウを指定できる。前記エージェントは、次に、前記暗号公開鍵及び暗号秘密鍵ペアを構成できる。前記エージェントは、次に、前記デジタルタイムロックコントラクトも構成できる。前記デジタルタイムロックコントラクトは、前記ブロックチェーンに埋め込まれた後にアクティブになることができ、前記暗号公開鍵は、データを暗号化するために使用されるよう公に利用可能であり、該データは前記暗号秘密鍵が公開されるまで復号できない。

【0022】

前記時間ウインドウは、前記時間ウインドウが始まる時間t及び時間期間Δtとして指定でき、Δtの後に前記時間ウインドウが終わる。前記デジタルタイムロックコントラクトは、以下の転送のうちの１つ以上が可能になるよう構成できる：
前記第２暗号化アセットは、任意の時間に、前記暗号秘密鍵、前記暗号秘密鍵から導出可能なタイムロックパズル値、及び前記クライアント署名により、前記クライアントアドレスへ転送可能である、
前記第２暗号化アセットは、時間tの後に、前記暗号秘密鍵及び前記エージェント署名により、前記エージェントアドレスへ転送可能である、
前記第２暗号化アセットは、時間t＋Δtの後に、前記クライアント署名により、前記クライアントアドレスへ転送可能である、
前記第１暗号化アセットは、任意の時間に、前記暗号秘密鍵及び前記暗号秘密鍵から導出可能なタイムロックパズル値を提供することにより、任意のアドレスへ転送可能である、
前記第１暗号化アセットは、時間tの後に、前記暗号秘密鍵及び前記エージェント署名により、前記エージェントアドレスへ転送可能である、
前記第１暗号化アセットは、時間t＋Δtの後に、前記クライアント署名により、前記クライアントアドレスへ転送可能である。

【0023】

以上に鑑み、ブロックチェーンネットワーク上で公開暗号鍵を生成し、指定時間期間の後に対応する秘密暗号鍵へのアクセスを可能にする、コンピュータにより実施される方法の別の定義は、
前記ブロックチェーンネットワーク上のエージェントとクライアントとの間のデジタルタイムロックコントラクトを構成するステップであって、前記エージェントは前記ブロックチェーンネットワーク上のエージェントアドレスと関連するエージェント署名とを有し、前記クライアントは前記ブロックチェーンネットワーク上のクライアントアドレスと関連するクライアント署名とを有し、前記デジタルタイムロックコントラクトは、
前記エージェントからの第１暗号化アセット（例えばデポジット）、
前記クライアントからの第２暗号化アセット（例えば料金）、
暗号公開鍵、及び、
前記エージェントが前記暗号公開鍵に対応する暗号秘密鍵を公開すべき時間ウインドウであって、前記時間ウインドウは前記時間ウインドウが始まる時間tと時間期間Δtとにより定められ、前記時間期間Δtの後に前記時間ウインドウが終わる、時間ウインドウ、
を指定し、前記デジタルタイムロックコントラクトは、以下の転送が可能になるよう構成される：
前記第２暗号化アセットは、任意の時間に、前記暗号秘密鍵及び前記暗号鍵から導出可能なタイムロックパズル値、及び前記クライアント署名により、前記クライアントアドレスへ転送可能である、
前記第２暗号化アセットは、時間tの後に、前記暗号秘密鍵及び前記エージェント署名により、前記エージェントアドレスへ転送可能である、
前記第２暗号化アセットは、時間t＋Δtの後に、前記クライアント署名により、前記クライアントアドレスへ転送可能である、
前記第１暗号化アセットは、任意の時間に、前記暗号秘密鍵及び前記暗号秘密鍵から導出可能なタイムロックパズル値を提供することにより、任意のアドレスへ転送可能である、
前記第１暗号化アセットは、時間tの後に、前記暗号秘密鍵及び前記エージェント署名により、前記エージェントアドレスへ転送可能である、及び、
前記第１暗号化アセットは、時間t＋Δtの後に、前記クライアント署名により、前記クライアントアドレスへ転送可能である、ステップと、
前記デジタルタイムロックコントラクトを、前記ブロックチェーン上でのマイニングのために、前記ブロックチェーンネットワークへブロードキャストするステップと、のうちの一方又は両方を含む。

【0024】

前記エージェントは、複数のクライアントと共に複数のデジタルタイムロックコントラクトに参加してよい。前記エージェントは、前記秘密鍵を保持する単一のエージェントであり得る。代替として、前記エージェントは、それぞれが前記暗号秘密鍵のシェアを保持する複数のエージェントを含んでよい。この場合、前記暗号秘密鍵の導出は、前記複数のエージェントにより提供される閾数の秘密鍵シェアにより有効になる。前記第１暗号化アセット及び前記第２暗号化アセットは、次に前記エージェントの間で分割される。サービスのセキュリティ及び信頼性は、中核のプロトコルを、それぞれ個別のコントラクトを有する独立したサービスプロバイダのグループに拡張し、ディーラー不要のシークレット共有（m－of－n）閾値方式を用いて秘密鍵のタイムリリースを分配することにより、更に強力にできる。したがって、サブ閾数の機能不全のサービスプロバイダに対して耐性がある。私達は、任意の料金が支払われる前にコントラクトを解除するために、共有公開鍵に対応する秘密鍵シェアが公開されることをクライアントが証明することを可能にする拡張ゼロ知識証明を記載する。

【0025】

クライアントは、デジタルタイムロックコントラクトに基づき、複数のエンドユーザにサービスを提供できる。例えば、サービスは、秘密ビッドオークション、鍵エスクロー方式、投票方式、機密データのタイムリリース、のうちの１つ以上であってよい。

【0026】

ここに記載のコンピュータにより実施される方法は、コンピュータ実行可能命令を含むコンピュータ可読記憶媒体であって、該命令は実行されると、ここに記載の方法を実行するようプロセッサを構成する、コンピュータ可読記憶媒体を提供することにより実施できる。さらに、電子装置であって、インタフェース装置と、前記インタフェース装置に結合されたプロセッサと、前記プロセッサに結合されたメモリであって、前記メモリは、実行されると、ここに記載の方法を実行するよう前記プロセッサを構成するコンピュータ実行可能命令を格納している、メモリと、を含む電子装置が提供され得る。

【0027】

ここに記載の本発明は、前述の背景技術で議論した従来技術にとは異なる。

【0028】

Ethereum Alarm Clockシステムは、エージェントが公開鍵に関連する秘密暗号鍵を保持し、及び次に指定時間ウインドウ内に秘密鍵を公開し、エージェントが適正な時間に秘密暗号鍵を公開することを保証するために、デジタルコントラクトが該システムを管理するために提供されることを開示していない点で、ここに記載のシステムと大きく異なる。さらに、従来のシステムは、使用に関連付けられたデータが暗号化される指定時間量の間、公開鍵の使用を可能にせず、次に使用に関連付けられたデータの復号を可能にするために秘密鍵を公開しない。

【0029】

「μchain: How to Forget without Hard Forks」で記載されたシステムも、エージェントが公開鍵に関連する秘密暗号鍵を保持し、及び次に指定時間ウインドウ内に秘密鍵を公開し、エージェントが適正な時間に秘密暗号鍵を公開することを保証するために、デジタルコントラクトが該システムを管理するために提供されることを開示していない点で、ここに記載のシステムと大きく異なると考えられる。従来のシステムは、使用に関連付けられたデータが暗号化される指定時間量の間、公開鍵の使用を可能にせず、次に使用に関連付けられたデータの復号を可能にするために秘密鍵を公開しないと考えられる。ここで、秘密鍵の公開は、適正な時間における公開を保証する条項を前提とする。むしろ、μchainの文献では、復号鍵は、エージェントにより生成されるのではなく、システムのユーザにより生成される。つまり、ユーザは、復号鍵の公開を制御したままであり、したがって、システムはユーザを信頼することに依存する。ユーザは、したがって、直ちにセキュリティを侵害し得る。

【0030】

同様に、「Secure Multiparty Computations on Bitcoin」及びUS２０１６０８６１７５も、エージェントが公開鍵に関連する秘密暗号鍵を保持し、及び次に指定時間ウインドウ内に秘密鍵を公開し、エージェントが適正な時間に秘密暗号鍵を公開することを保証するために、デジタルコントラクトが該システムを管理するために提供されることを開示していない点で、ここに記載のシステムと大きく異なる。

【図面の簡単な説明】

【0031】

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

【図1】クライアントとエージェントとの間の通信チャネルの確立後に、クライアントとエージェントとの間でデジタルタイムロックコントラクトを設定する初期化プロトコルのフロー図を示す。

【図2】クライアントとエージェントとの間のデジタルタイムロックコントラクトを構成するトランザクションスクリプトの一例を示す。

【図3】時間期間に依存するデジタルタイムロックコントラクト及びアウトプットの宛先の概略時系列を示す。

【図4】マルチエージェントプロトコルの概略図を示す。

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

【0032】

ビットコインブロックチェーンの出現は、（ブロックヘッダに記録されるような）現時点における分散型のグローバルな総意、及びコントラクトの信頼不要な（trustless）自動実行（scripts）の両方の存在するシステムをもたらした。これらは、セキュア且つ信頼できるタイムリリース暗号化サービスの実現のために活用可能な独特の特徴である。本願明細書では、私達は、ビットコインスクリプトに基づくスマートコントラクト、及びサービスプロバイダにおける完全な信頼に依存しないゼロ知識証明の組み合わを利用するタイムリリース暗号化サービスにためのシステムを記載する。さらに、私達は、単一の鍵公開に対して複数のエージェントを使用して、分散化を通じてサービスの回復力及びセキュリティを向上するために、プロトコルがディーラー無し閾値方式を用いてどのように拡張可能であるかを示す。

【0033】

特定の構成は、プロトコルを完全に信頼不要にするための知識のゼロ知識証明（zero－knowledge proofs：ZKP）の概念を利用する。方式の部分として使用され得る２つの技術がある。つまり、非対話型証明、及びcut－and－chooseである。

【0034】

非対話型ゼロ知識（Non－interactive zero－knowledge：NIZK）証明は、関与するパーティ間で必要な通信を最小化するので、本願にとって好ましい。しかしながら、それらは、実装が複雑且つ計算コストが高くなり得る。形式上、NIZK証明は、証明者（prover）から検証者（verifier）に直接提供可能であるが、この場合には彼らは信頼できる設定（σ）を必要とする。本願では、検証者は、信頼できる設定を実行し、次にこれを証明者へ送信する。次に、証明者は、証明（π）を計算し、これを検証者へ返送する。

【0035】

第１の適用では、私達は、（検証者に提供される）ハッシュのプレイメージが楕円曲線公開鍵（検証者にも提供される）に対応する秘密鍵と等しいというゼロ知識証明を要求する。この特定のNIZKの数学的構造は、［Fuchsbauer ２００８］で詳述される。このNIZK証明は、zk－SNARKS［Lundkvist ２０１７］により実施可能である。

【0036】

拡張システムを用いる第２の適用では、効率的NIZK証明の構成は興味深い。この場合、ZKPの呼び出したcut－and－chooseの簡易相互作用タイプが利用可能である［Crepeau ２０１１］。本アプローチでは、証明者は、検証者に、異なるステートメントへの膨大な数のコミットメントを提供する。検証者は、次に、これらのコミットメントの部分集合をランダムに選択し、証明者がそれらを証明するための知識を送信することを要求する。ステートメントのこの部分集合が真であることが示されると、検証者は、残りのステートメントも真である確率が分かる。

【0037】

特定の構成は、ビットコイントランザクションスクリプトの幾つかの標準的特徴を利用して、アウトプットのタイムロック及びハッシュロックの使用を可能にする。

【0038】

ビットコインアウトプットは、（例えば、HASH２５６オペコードを用いて）指定された値にハッシュするシークレットを提供するよう、アンロックスクリプトが必要とされるように、構成可能である。つまり、アウトプットを使用するために、インプットは、該アウトプットの中で指定された別の値にハッシュする値を提供しなければならない［Maxwell ２０１６］。

【0039】

アウトプットは、また、何らかの予め指定された将来の時点まで、使用不可能であるように構成可能である。これは、CHECKLOCKTIMEVERIFY(CLTV)オペコードを用いて達成される。該オペコードは、指定されたユニックスエポックタイム（unix epoch time）又は指定されたブロック高に達するまで、トランザクションの使用を防ぐために使用可能である［Todd ２０１４］。

【0040】

スマートコントラクト構造を保証するために、短いタイムロックパズルの新規な適用が、「レース攻撃（race attack）」を防ぐために利用される。（アウトプットのロックを）設定するために無視できる計算作業しか必要としない連続二乗タイムロックパズル（successive squaring time－lockpuzzle）が使用可能である［Rivest １９９６］。設定パラメータを所有しない第２パーティでは、パズルを解除し及びアウトプット値を明らかにするために、設定数の（特定時間量を要する）シリアル計算がインプットに対して実行されなければならない。

【0041】

信頼できるエージェントによる時間公開暗号化方式の１つの構成では、エージェントは、（公開鍵暗号システムを用いる）公開秘密鍵ペアを生成し、情報を暗号化するために使用すべきクライアントの公開鍵を公開し、次に受信者へ送信する。次に、合意した時間で（エージェントにより決定される）、エージェントは、情報を復号するために、秘密鍵を受信者に公開する。この場合、エージェントは、この動作を実行するために完全に信頼され、及び秘密鍵をセキュアに保持する必要がある。

【0042】

Rabin及びThorpe［Rabin ２００６］は、鍵生成を何らかの信頼するに値するエージェントのグループの間で分散することにより、この構成のセキュリティ及び障害耐性を拡張するためにシステムを提案した。その結果、パーティのうちの幾つかが不誠実である又は情報漏洩した場合でも、秘密鍵を公開すべき適正な時間であると閾数のエージェントが合意するまで、彼らのうちの誰も完全な秘密鍵を知ることができない。

【0043】

このシステムでは、ネットワーク接続されたエージェント（n）のグループは、ディーラー不要閾（m－of－n）シークレット共有方式を用いて協力して、共有秘密鍵及び対応する共有公開鍵を生成する。該共有公開鍵は、次にクライアントに公開される（クライアントは、次にメッセージを暗号化できる）。閾数（m）のエージェントが、鍵を公開すべき時間に達したことに合意するときのみ、完全な秘密鍵が再構成され、受信者へ送信され得る。

【0044】

シャミアの秘密共有方式（Shamir's secret sharing scheme：SSSS）［Shamir １９７９］は、多項式の次数tがt＋１個の点の任意の集合に適合できるという概念に基づく。次数tの多項式f(x)は、共有秘密鍵により定数項として形成され（a_０＝f(０)）、残りの係数はランダムに選ばれる。曲線上のn個の点は、次に、各参加者に与えられる。m＝t＋１以上の参加者が次に彼らの点を結合する場合、これらの点に次数tの多項式を適合させる充分な情報があり、a_０はシークレットとして解明される。この方式は、任意の閾数を有する任意の膨大な数のパーティの間で、単一の秘密鍵の共有を可能にする。

【0045】

標準的なSSSSは、多項式を生成し及び（単一障害点であり、したがって信頼不要ではない）シークレットシェアを分散するために、信頼できるディーラーの要件を除去するよう拡張可能である。このディーラー不要SSSSでは、各参加者P_iは、彼ら自身のランダムな次数tの多項式f_i(x)を生成し、次に、f_i(j)を各々の他の参加者P_jへセキュアに送信する。各P_iは、次に全ての受信点を加算し、f_１(i)＋f_２(i)＋．．．＋f_n(i)、彼らのシークレットシェアS_i＝f(i)を取得する。これは、共有多項式f(x)上のP_i点である。

【0046】

シークレットシェアが生成された後に、共有秘密鍵に対応する（どの参加者も知らない）公開鍵は、（楕円曲線生成器Gにより）以下のように計算される。

【0047】

参加者P_iは、彼らの公開鍵シェアをb_is_i×Gとして計算する。ここで、i＝１，．．．，t＋１であり、次式の通りである。

【数1】

【0048】

これらの公開鍵シェアは、次に、ブロードキャストされ、共有公開鍵Aは、次に、単にt＋１個のシェアの和として以下のように計算される。

【数2】

【0049】

＜単一エージェントプロトコル＞
本章は、単一エージェントが時間公開暗号化サービスを提供する場合の構成を記載する。プロトコルは、ビットコイントランザクション及びその生来のスクリプト言語（Script）に関連して記載され、一般性を失わないが、パブリックブロックチェーン及び等価なスクリプト機能を有する任意の暗号化システムに適用可能である。

【0050】

プロトコルは、２つのパーティに直接関連する。
・クライアントは、必要なロックタイム暗号化サービスのパラメータを指定し、そのための料金（F）を支払う。クライアントは、アドレスCAddrを制御する。
・エージェントは、タイムロック暗号化サービスを実行し、正常終了すると料金を受け取る。エージェントは、サービスが適正に実行されない場合に没収されるデポジット（D）を提供する。エージェントは、アドレスAAddrを制御する。

【0051】

図１は、クライアントとエージェントとの間の通信チャネルの確立後に、クライアントとエージェントとの間でデジタルタイムロックコントラクトを設定する初期化プロトコルのフロー図を示す。設定は、以下の通り進行する。

【0052】

１．クライアントは、パブリックフォーラムの中でタイムロックサービスのための要求を提出する。要求は、クライアントアドレス（CAddr）、彼らが支払いたい料金（F）、時間（T）であって、該時間の後に鍵が公開されること彼らが要求する時間（T）、及び必要な待ち時間（Δt）で構成される。

【0053】

２．サービスを実行したいと望むエージェントは、クライアントと連絡を取り、セキュア通信チャネルを確立する。クライアントは、料金のために使用されるべきUTXOのトランザクションIDを送信する。

【0054】

３．エージェントは、次に、ランダム暗号化秘密鍵（EPrivK）及び対応する公開鍵（EPubK）をセキュアに生成する。

【0055】

４．エージェントは、次に、EPrivKから出力されるタイムロックパズルである値tlpEPrivKを計算し、インプットとしてのEPrivKから計算するために、約１時間の連続計算を必要とする（標準的なビットコインブロックチェーントランザクション確認時間である）。

【0056】

５．エージェントは、次に、EPubK、対応する秘密鍵のSHA－２５６ハッシュH(EPrivK)及びH(tlpEPrivK)をクライアントへ送信する。

【0057】

６．クライアントはNIZK証明設定を実行し：σ←Setup(１^２５６)、結果をエージェントへ送信する。

【0058】

７．エージェントは、証明π_１←Prove(σ,H(EPrivK),EPubK)、ここでH(EPrivK)のプレイメージはEPubKに対応するECC秘密鍵である、及び、証明π_２←Prove(σ,H(tlpEPrivK),H(EPrivK))、ここでH(tlpEPrivK)のプレイメージはH(EPrivK)のプレイメージである、を約１時間のタイムロックパズルで構成し、それらをクライアントへ送信する。

【0059】

８．クライアントは、両方の証明を検証する：Verify(σ,H(EPrivK),π_１)=true及びVerify(σ,H(tlpEPrivK),π_２)=trueである。

【0060】

９．エージェントは、次に、要求パラメータ、暗号化秘密鍵(EPrivK)のハッシュ、及びtlpEPrivKのハッシュを用いて、タイムロック暗号化スマートコントラクトとして機能するトランザクション（Tx０）を生成する。

【0061】

Tx０は２つのインプットを有する。つまり、クライアント料金（F）UTXO、及びエージェントデポジット（D）UTXOである。

【0062】

Tx０は３つのアウトプットを有する。つまり、料金量のためのアウトプット１、デポジット量のためのアウトプット２、及び暗号化公開鍵メタデータのためのアウトプット３である。
アウトプット１（Output１）：
任意の時間における、EPrivK、tlpEPrivK、及びクライアント署名による、クライアントアドレスへの支払い（F）。
時間Tの後の、EPrivK、及びエージェント署名による、エージェントアドレスへの支払い（F）。
時間T＋ΔTの後の、クライアント署名による、クライアントアドレスへの支払い（F）。
アウトプット２（Output２）：
任意の時間における、EPrivK、及びtlpEPrivKによる、任意のアドレスへの支払い（D）。
時間Tの後の、EPrivK、及びエージェント署名による、エージェントアドレスへの支払い（D）。
時間T＋ΔTの後の、クライアント署名による、クライアントアドレスへの支払い（D）。
アウトプット３（Output３）：
メタデータとして暗号化公開鍵（EPubK）を含むOP_RETURN。

【0063】

図２は、トランザクション構造全体を示す。図２では、明確化のために、＜…PubKey＞はOP_DUP OP_HASH１６０ <pubKeyHash> OP_EQUALVERIFYで置き換えられていることに留意する。ここで、pubKeyHashはアドレスと等価である。アウトプット１及び２は、関連パーティへ送信される及び／又は発行される対応するRedeemスクリプトを有するP２SH(pay－to－script－hash)scriptPubKeyとして実装されてよい。

【0064】

１０．エージェントは、トランザクションに署名し、該トランザクションをクライアントへ送信する。

【0065】

１１．クライアントは、トランザクションに署名し、該トランザクションをビットコインネットワークへブロードキャストする。

【0066】

１２．トランザクションがブロックチェーンに埋め込まれる（mined）と、タイムロックコントラクトが起動される。EPubKは、今や、任意のデータを暗号化するために使用されるよう、公に利用可能である。該データはEPrivKが公開されるまで復号できない。

【0067】

図３は、時間期間に依存するデジタルタイムロックコントラクト及びアウトプットの宛先の概略時系列を示す。コントラクトは、料金及びデポジットの両方を請求するために、エージェントが暗号化秘密鍵（EPrivK）を時間間隔T～T＋ΔTの範囲内で公開するよう、設計される。これを行うために、エージェントは、２つのトランザクションTx１（Tx０アウトプット１を使用する）及びTx２（Tx０アウトプット２を使用する）を生成する。アウトプットをアンロックすべきscriptSigは、<EPrivK> <AAddr Pubkey> <AAddr Sig>の両方を含む。Tx１及びTx２は、次に、F及びDの両方をエージェントにより選択されたアドレスに支払う。これらのトランザクションがブロックチェーンに埋め込まれると、EPrivKは、次に、公に公開され、誰にでも使用可能になる。

【0068】

エージェントが時間tの前に誰かにEPrivKを（場合によっては賄賂と引き換えに）漏らすのを妨ぐために、コントラクトは、時間Tの前にEPrivKを知った者がハッシュプレイメージ（及び対応するタイムロックパズルtlpEPrivK、以下のレース攻撃保護を参照する）を署名無しで提供することによりアウトプット２を使用し、次にエージェントデポジット全体を請求できるように、設計される。このパーティは情報漏洩者（leaker）と呼ばれる。これが生じると、クライアントは、次にEPrivKも知り、時間Tの前にscriptSig <EPrivK> <CAddr Pubkey> <CAddr Sig>によりアウトプット１を使用でき、クライアント料金を再請求する。

【0069】

これは、EPrivKをセキュアに保つよう、エージェントに対する強力な奨励構造を提供する。誰か（ハッカーを含む）が時間Tの前にEPrivKを発見した場合、彼らは、エージェントのデポジットを匿名で請求できる。エージェントが時間Tの前に情報漏洩者としてデポジットを請求した（又はそれを可能にした）場合、彼らは、料金を剥奪される（これは、クライアントへ返金される）。したがって、料金及びデポジットの値の選択は、システムのセキュリティに影響し、暗号化要求のための理由に対し適切であるべきである。

【0070】

コントラクトは、また、確実にエージェントに時間Tの後、時間T＋ΔTの前に（ここでΔTは必要な待ち時間である）、暗号化鍵を公開させるよう設計される。時間T＋ΔTの後に、EPrivKが公開されていない場合、クライアントは、アウトプット１及びアウトプット２の両方をアンロックできる（料金を再請求し、さらにエージェントのデポジットを補償として取り入れる）。この場合、クライアントは、scriptSig <CAddr Pubkey> <CAddr Sig>により２つのトランザクションTxR１（Tx０アウトプット１を使用する）及びTxR２（アウトプット２を使用する）の両方を生成し、F及びDの両方をクライアントにより選択されたアドレスに支払う。

【0071】

ビットコインスクリプト言語の特性は、（OP_CHECKLOCKTIMEVERIFYにより）アウトプットが特定の時点まで使用されることを防ぐことが可能であるが、ある時点の後にアウトプットが使用されることを防ぐことはできない（該時点の前に、使用可能であった場合）。したがって、scriptSigが有効になると、それは永久に有効なままである。これは、EPrivKを提供することにより、誰でもいつでも、時間Tの後でさえ、H(EPrivK)のプレイメージを要求されるだけで、アウトプット２を使用できる、アウトプット２のロックスクリプトに伴う問題を提示する。

【0072】

これは、エージェントに対する「レース二重使用攻撃（race double spending attack）」を可能にし得る。つまり、エージェントがTx１及びTx２をビットコインネットワークに（時間Tの後に）適正にブロードキャストすると、任意のマイナーがそれらのいずれかからEPrivKを抽出し、先ずアウトプット２を使用し及びデポジットを盗むために、彼ら自身のanyone－can－spend（誰でも使用可能）トランザクションをブロックに含め得る（又は他の誰かが自由に取り替え可能である）。

【0073】

この攻撃を防ぐためにここで実装されるソリューションは、常にアウトプット２をアンロックするためにEPrivKと一緒に提供されるべきtlpEPrivK（EPrivKから出力されるタイムロックパズル）に対する追加要件である。誰か（情報漏洩者）が時間Tの前にEPrivKを所有するようになった場合、彼らは、１時間の計算によりtlpEPrivKを内密に決定し、次にデポジットを請求できる（つまりアウトプット２を解除する）。EPrivKがmempoolの中でマイニングされるのを待っているTx１及びTx２に埋め込まれているとき、彼らが（時間Tの後に）最初にEPrivKを取得した場合、彼らがtlpEPrivKを導出する時まで（１時間の計算）、アウトプット２を使用するエージェントトランザクション（Tx２）は、ブロックチェーン内で既に確認されている。レース攻撃保護の結果は、tlpEPrivKが導出に１時間を要するので、デポジットを剥奪されるリスクを伴わずに、エージェントが時間Tの前に１時間未満でEPrivKを公開することが可能であることである。これは、コントラクトの「時間分解能」又は精度を１時間に制限する。

【0074】

＜複数エージェントプロトコル＞
上述のスマートコントラクトプロトコルは、閾値秘密鍵による複数エージェントの場合に格納可能である。この場合、各エージェントは、彼ら自身のデポジット及び個別料金により、彼ら自身のTx０バージョンを生成する。唯一の違いは、秘密鍵（EPrivK）ハッシュ及び公開鍵（EPubK）が秘密鍵シェアのハッシュ及び共有公開鍵でそれぞれ置き換えられることである。各コントラクトは、独立に実行され、鍵シェアは時間Tの後にブロックチェーン上で明らかにされる。秘密鍵全体を再構成するためには閾数の鍵シェアが必要なので、システムは、サブ閾数のエージェントが機能不全であることに耐え、より重要な及び重大なアプリケーションに対して単一障害点（単一エージェント）を除去する。この拡張プロトコルのために必要な主要な技術的相違点は、ディーラー不要の共有鍵生成、エージェントのグループが彼らの秘密鍵シェアのハッシュのプレイメージが公開された共有公開鍵に対応することを協力して証明することを可能にする、複数パーティゼロ知識証明システム、に関連することである。

【0075】

複数エージェントプロトコルは、次に、以下の参加者に関連する。
・必要なロックタイム暗号化サービスのパラメータを指定し、そのための合計料金（F）を支払う（n個のUTXOの間で分割する）クライアント。クライアントは、アドレスCAddrを制御する。
・n個の独立したエージェントが、サービスを協力して実行し、彼らがプロトコルを正しく実行した場合に、それぞれが料金の一部（F／n）を受け取る。各エージェントは、プロトコルが適正に実行されなかった場合に没収されるデポジット（D）を提供する。各エージェント（i＝１，２，．．．，n）は、アドレスAAddr_iを制御する。

【0076】

図４は、マルチエージェントプロトコルの概略図を示す。設定は、以下の通り進行する。

【0077】

１．クライアントは、パブリックフォーラムの中でタイムロックサービスのための要求を提出する。要求は、クライアントアドレス（CAddr）、彼らが支払いたい料金（F）、時間（T）であって、該時間の後に鍵が公開されること彼らが要求する時間（T）、必要な待ち時間（Δt）、必要なエージェント数（n）、及び必要な閾（m）で構成される。

【0078】

２．サービスを実行したいと望むn個のエージェントは、クライアントと連絡を取り、セキュア通信チャネルを確立する。クライアントは、料金のために使用されるべきUTXOのトランザクションIDを送信する。

【0079】

３．クライアントは、次に、エージェントの各々の詳細な連絡先をグループにブロードキャストし、各エージェントは、グループ内の各々の他のエージェントと（公開鍵暗号システム又はDiffie－Hellman鍵交換により）セキュアな通信を確立する。

【0080】

４．プレイヤは、次に、閾mでディーラー不要秘密共有プロトコルを共同で実行し、共有鍵EPrivK（暗号化秘密鍵）を生成する。各プレイヤ（i＝１，．．．，n）は、次に鍵シェアsEPrivKiを処理する（EPrivKはいずれのパーティにも知られていない）。

【0081】

５．n人のプレイヤのグループは、次に、各秘密鍵シェアに対する彼らの公開鍵シェアを計算し、これらのシェア（sEPubKi）をグループの残りの者にブロードキャストする。各プレイヤは、次に、対応する共有公開鍵EPubKを独立に計算できる。

【0082】

６．エージェント（i＝１，．．．，n）は、次に、sEPrivKiから出力されるタイムロックパズルである値tlpsEPrivKiを計算し、インプットとしてのsEPrivKiから計算するために、約１時間の連続計算を必要とする。

【0083】

７．エージェント（i＝１，．．．，n）は、次に、EPubK、彼らの対応する秘密鍵のSHA－２５６ハッシュH(sEPrivKi)及びH(tlpsEPrivKi)をクライアントへ送信する。

【0084】

８．エージェントのグループは、次に、クライアントに、彼らの秘密鍵シェアのハッシュのプレイメージが、閾値mで、EpubKに対応する秘密鍵を再構成するために使用可能であることのゼロ知識証明を協力して提供する。このためのNIZK証明の展開は、相当量の作業であり、極めて高価なことがある。しかしながら、「cut－and－choose」法は、比較的効率的に利用可能である。この場合、n人のエージェントのグループは、ステップ４～７を多数回（N＝１００～１０００）、繰り返す。クライアントは、次に、共有公開鍵のうちの１つをランダムに選択し、グループが残りのN－１個の公開鍵に対する秘密鍵シェアを明らかにすることを要求する。クライアントは、秘密鍵シェアが各共有公開鍵に対応する秘密鍵を再構成できること、及び秘密鍵シェアが送信されたハッシュのプレイメージであること、の両方を確認する。これは、次に、エージェントが不誠実であるという（N－１）／N未満の確率があることを裏付ける。任意のエージェントは、無効鍵シェア又はハッシュを提供することが、プロトコルから除去され置き換えられる（及び処理が繰り返される）ことが分かる。ランダムに選択された共有公開鍵（及び対応する秘密鍵シェアハッシュ）は、次に、n個のトランザクションのためのプロトコルの中で使用される。

【0085】

９．エージェント（i＝１，．．．，n）は、次に、要求パラメータ、暗号化秘密鍵(EPrivK)のハッシュ、及びtlpEPrivKのハッシュを用いて、図１と全く同じ構造のトランザクション（Tx０i）を生成する。

【0086】

各Tx０iは２つのインプットを有する。つまり、クライアント料金シェア（F／n）UTXO、及びエージェントデポジット（D／n）UTXOである。

【0087】

各Tx０iは３つのアウトプットを有する。つまり、（F／n）のためのアウトプット１、Dのためのアウトプット２、及びEPubKメタデータのためのアウトプット３である。
Tx０iアウトプット１（Output１）：
sEPrivKi、tlpEPrivK、及びクライアント署名による、任意の時間における、クライアントアドレスへの支払い（F／n）。
時間Tの後の、sEPrivKi、及びエージェント署名による、エージェントアドレスへの支払い（F／n）。
時間T＋ΔTの後の、クライアント署名による、クライアントアドレスへの支払い（F／n）。
Tx０iアウトプット２（Output２）：
任意の時間における、sEPrivKi、及びtlpsEPrivKiによる、任意のアドレスへの支払い（D）。
時間Tの後の、sEPrivKi、及びエージェント署名による、エージェントアドレスへの支払い（D）。
時間T＋ΔTの後の、クライアント署名による、クライアントアドレスへの支払い（D）。
Tx０iアウトプット３（Output３）：
メタデータとして暗号化公開鍵（EPubK）を含むOP_RETURN。

【0088】

１０．各エージェントは、彼らの対応するトランザクションに署名し、該トランザクションをクライアントへ送信する。

【0089】

１１．クライアントは、n個のトランザクションの各々に署名し、それらをビットコインネットワークへブロードキャストする。

【0090】

１２．トランザクションがブロックチェーンに埋め込まれると、EPubKは今や任意のデータを暗号化するための使用のために公に入手可能になり、該データは、EPrivKがエージェントにより公開されているる閾数（m）の鍵シェアsEPrivKiから明らかにされるまで、復号できない。

【0091】

各々の個別コントラクト（Tx０i）は、前述の単一エージェントコントラクトと同じ方法で実行される。各エージェントは、彼らの鍵シェアが時間Tより前に漏洩した場合、彼らのデポジットを失うリスクがある。彼らは、彼らのデポジット及び彼らの料金シェアを返すよう請求するために、時間Tの後に彼らの鍵シェアを公開することを、それぞれ個々に奨励される。各個別コントラクトの実行は、互いに完全に独立である。このシステムは、次に、サブ閾（n－m）数の参加者が彼らの鍵シェアを適正な時間に公開しないこと、又はそれらを早期に漏洩すること、に対して耐性があり、サービスのセキュリティ又は信頼性を危険に晒さない。彼らの鍵シェアを時間T＋ΔTの前に公開しない各エージェントについて、クライアントは、彼らの料金シェア及び機能不全のエージェントデポジットを返すよう請求できる。

【0092】

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

【0093】

参考文献
[Abliz２００]: Abliz,Mehmud,andTaiebZnati."Aguidedtourpuzzlefordenialofserviceprevention."ComputerSecurityApplicationsConference,２００９.ACSAC'０９.Annual.IEEE,２００９.
[Fuchsbauer２００８]: Fuchsbauer,Georg,andDavidPointcheval."EncryptingProofsonPairingsandItsApplicationtoAnonymityforSignatures."IACRCryptologyePrintArchive２００８(２００８):５２８.
[Lundkvist２０１７]: https://media.consensys.net/introduction－to－zksnarks－with－examples－３２８３b５５４fc３b
[Crepeau２０１１]: Crepeau,Claude."Cut－and－chooseprotocol."EncyclopediaofCryptographyandSecurity.SpringerUS,２０１１.２９０－２９１.
[Maxwell２０１６]: https://bitcoincore.org/en/２０１６/０２/２６/zero－knowledge－contingent－payments－announcement/
[Todd２０１４]: https://github.com/bitcoin/bips/blob/master/bip－００６５.mediawiki

【図1】

【図2】

【図3】

【図4】