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

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

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

特開2024-50855ブロックチェーンネットワーク上のタイムリリース暗号化のためのコンピュータにより実施されるシステム及び方法
<>
  • 特開-ブロックチェーンネットワーク上のタイムリリース暗号化のためのコンピュータにより実施されるシステム及び方法 図1
  • 特開-ブロックチェーンネットワーク上のタイムリリース暗号化のためのコンピュータにより実施されるシステム及び方法 図2
  • 特開-ブロックチェーンネットワーク上のタイムリリース暗号化のためのコンピュータにより実施されるシステム及び方法 図3
  • 特開-ブロックチェーンネットワーク上のタイムリリース暗号化のためのコンピュータにより実施されるシステム及び方法 図4
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2024050855
(43)【公開日】2024-04-10
(54)【発明の名称】ブロックチェーンネットワーク上のタイムリリース暗号化のためのコンピュータにより実施されるシステム及び方法
(51)【国際特許分類】
   H04L 9/32 20060101AFI20240403BHJP
【FI】
H04L9/32 200Z
【審査請求】有
【請求項の数】18
【出願形態】OL
【外国語出願】
(21)【出願番号】P 2024017554
(22)【出願日】2024-02-08
(62)【分割の表示】P 2022120410の分割
【原出願日】2018-06-11
(31)【優先権主張番号】1709760.1
(32)【優先日】2017-06-19
(33)【優先権主張国・地域又は機関】GB
【公序良俗違反の表示】
(特許庁注:以下のものは登録商標)
1.UNIX
(71)【出願人】
【識別番号】318001991
【氏名又は名称】エヌチェーン ライセンシング アーゲー
(74)【代理人】
【識別番号】100107766
【弁理士】
【氏名又は名称】伊東 忠重
(74)【代理人】
【識別番号】100070150
【弁理士】
【氏名又は名称】伊東 忠彦
(74)【代理人】
【識別番号】100135079
【弁理士】
【氏名又は名称】宮崎 修
(72)【発明者】
【氏名】トレヴェサン,トーマス
(57)【要約】      (修正有)
【課題】ブロックチェーンネットワーク上の公開暗号鍵を生成し、かつ、指定時間期間の後に対応する秘密暗号鍵へのアクセスを可能にする方法及びシステムを提供する。
【解決手段】ブロックチェーンネットワーク上のエージェントとクライアントとの間のデジタルタイムロックコントラクトは、エージェントからの第1暗号化アセット及びクライアントからの第2暗号化アセットを指定し、第1暗号化アセット及び第2暗号化アセットが、暗号秘密鍵から導出可能なタイムロックパズル値と必要な署名により、設定された時間後に設定されたアドレスへ転送可能になるように構成される。
【選択図】図1
【特許請求の範囲】
【請求項1】
ブロックチェーンネットワークにおいて公開暗号鍵を生成し、指定時間期間の後に対応する秘密暗号鍵へのアクセスを可能にする、コンピュータにより実施される方法であって、前記方法は、前記ブロックチェーンネットワーク上のエージェントアドレスと関連するエージェント署名とを有する、前記ブロックチェーンネットワーク上のエージェントにおいて、
秘密暗号鍵と対応する公開暗号鍵とを生成するステップと、
前記秘密暗号鍵からタイムロックパズルを導出し、タイムロックパズルアウトプットのアウトプットを表す値を計算するステップと、
前記公開暗号鍵、前記秘密暗号鍵の第1ハッシュ、及び前記値の第2ハッシュを、前記ブロックチェーンネットワーク上のクライアントへ送信するステップであって、前記クライアントは、前記ブロックチェーンネットワーク上のクライアントアドレスと関連するクライアント署名とを有する、ステップと、
前記秘密暗号鍵が前記第1ハッシュのプレイメージであるという第1非ゼロ知識証明と、前記値が前記第2ハッシュのプレイメージであるという第2非ゼロ知識証明とを構成し、前記第1非ゼロ知識証明及び前記第2非ゼロ知識証明を前記クライアントへ送信するステップと、
前記第1ハッシュ及び前記第2ハッシュを用いて、前記エージェントと前記クライアントとの間のデジタルタイムロックコントラクトを構成するステップと、
を含み、前記デジタルタイムロックコントラクトは、以下:
(i)前記エージェントが、指定時間ウインドウ内に前記ブロックチェーンネットワークに前記秘密暗号鍵を公開すること、
(ii)前記エージェントが、前記秘密暗号鍵を保持し前記指定時間ウインドウ内に前記ブロックチェーンネットワークに公開するために第1暗号化アセットを提供し、前記第1暗号化アセットは、前記秘密暗号鍵が前記指定時間ウインドウ内に前記ブロックチェーンネットワークに公開されると、前記ブロックチェーンネットワーク上の前記エージェントアドレスに転送可能であること、
(iii)前記クライアントが、前記秘密暗号鍵を保持し前記指定時間ウインドウ内に前記ブロックチェーンネットワークに公開するために第2暗号化アセットを前記エージェントに提供し、前記第2暗号化アセットは、前記秘密暗号鍵が前記指定時間ウインドウ内に前記ブロックチェーンネットワークに公開されると、前記ブロックチェーンネットワーク上の前記エージェントアドレスに転送可能であること、
(iv)前記指定時間ウインドウが開始する前に前記秘密暗号鍵が公開された場合、前記第2暗号化アセットは、前記ブロックチェーンネットワーク上の前記クライアントアドレスに転送可能であること、
(v)前記指定時間ウインドウが終了する前に前記秘密暗号鍵が公開されなかった場合、前記第2暗号化アセットは、前記ブロックチェーンネットワーク上の前記クライアントアドレスに転送可能であること、
を指定する、コンピュータにより実施される方法。
【請求項2】
前記クライアントから、設定された非ゼロ知識証明の結果を受信し、前記結果を使用して前記第1非ゼロ知識証明及び前記第2非ゼロ知識証明を構成するステップ、を更に含む請求項1に記載のコンピュータにより実施される方法。
【請求項3】
前記クライアントは、前記エージェントが前記デジタルタイムロックコントラクトを構成する前に、前記第1非ゼロ知識証明及び前記第2非ゼロ知識証明を検証する、請求項1又は2に記載のコンピュータにより実施される方法。
【請求項4】
ステップ(iv)において、前記クライアント又は他の者は、前記秘密暗号鍵を使用して、前記エージェントの前記第1暗号化アセットを取り込むことができる、請求項1~3のいずれかに記載のコンピュータにより実施される方法。
【請求項5】
ステップ(v)において、前記第1暗号化アセットは、前記ブロックチェーンネットワーク上の前記クライアントアドレスにも転送可能である、請求項1~4のいずれかに記載のコンピュータにより実施される方法。
【請求項6】
前記方法は、前記クライアントがデジタルタイムロックコントラクトを設定したい要望を示す要求を送信することにより、開始される、請求項1~5のいずれかに記載のコンピュータにより実施される方法。
【請求項7】
前記クライアントは、前記第2暗号化アセット及び前記指定時間ウインドウを指定する、請求項6に記載のコンピュータにより実施される方法。
【請求項8】
前記デジタルタイムロックコントラクトは、ブロックチェーンへとマイニングされた後にアクティブになり、前記公開暗号鍵は、データを暗号化するために使用されるよう公衆に利用可能であり、前記データは、前記秘密暗号鍵が公開されるまで、復号できない、請求項1~7のいずれかに記載のコンピュータにより実施される方法。
【請求項9】
前記指定時間ウインドウは、前記指定時間ウインドウが開始する時間t、及び時間期間Δtとして指定され、時間期間Δtの後に前記指定時間ウインドウが終了する、請求項1~8のいずれかに記載のコンピュータにより実施される方法。
【請求項10】
前記第2暗号化アセットは、前記秘密暗号鍵、前記値、及び前記クライアント署名により、いつでも前記クライアントアドレスへ転送可能である、請求項9に記載のコンピュータにより実施される方法。
【請求項11】
前記第2暗号化アセットは、前記秘密暗号鍵及び前記エージェント署名により、時間tの後に、前記エージェントアドレスへ転送可能である、請求項9又は10に記載のコンピュータにより実施される方法。
【請求項12】
前記第2暗号化アセットは、前記クライアント署名により、時間t+Δtの後に、前記クライアントアドレスへ転送可能である、請求項9~11のいずれかに記載のコンピュータにより実施される方法。
【請求項13】
前記第1暗号化アセットは、前記秘密暗号鍵及び前記値を提供することにより、いつでも、任意のアドレスへ転送可能である、請求項9~12のいずれかに記載のコンピュータにより実施される方法。
【請求項14】
前記第1暗号化アセットは、前記秘密暗号鍵及び前記エージェント署名により、時間tの後に、前記エージェントアドレスへ転送可能である、請求項9~13のいずれかに記載のコンピュータにより実施される方法。
【請求項15】
前記第1暗号化アセットは、前記クライアント署名により、時間t+Δtの後に、前記クライアントアドレスへ転送可能である、請求項9~14のいずれかに記載のコンピュータにより実施される方法。
【請求項16】
前記エージェントは、複数のクライアントの各々と共に、前記ステップを複数回実行する、請求項1~15のいずれかに記載のコンピュータにより実施される方法。
【請求項17】
コンピュータ実行可能命令を含むコンピュータ可読記憶媒体であって、前記コンピュータ実行可能命令は、実行されると、プロセッサを、請求項1~16のいずれか一項に記載の方法を実行するよう構成する、コンピュータ可読記憶媒体。
【請求項18】
電子装置であって、
インタフェース装置と、
前記インタフェース装置に結合されたプロセッサと、
前記プロセッサに結合されたメモリであって、前記メモリはコンピュータ実行可能命令を格納し、前記コンピュータ実行可能命令は、実行されると、前記プロセッサを、請求項1~16のいずれか一項に記載の方法を実行するよう構成する、メモリと、
を含む電子装置。
【発明の詳細な説明】
【技術分野】
【0001】
本願明細書は、概して、タイムリリース暗号化のためのデジタルタイムロックコントラクトに関する。本発明は、限定ではないが、特にビットコインブロックチェーンと共に使用することに適する。
【背景技術】
【0002】
本願明細書で、用語「ブロックチェーン」は、あらゆる形式の電子的な、コンピュータに基づく、分散台帳を含むよう使用される。これらは、総意に基づくブロックチェーン及びトランザクションチェーン技術、許可及び未許可台帳、共有台帳、及びそれらの変形を含む。最も広く知られているブロックチェーン技術の用途はビットコイン台帳であるが、他のブロックチェーンの実装が提案され開発されている。ビットコインは便宜上及び説明を目的として本願明細書において言及されるが、本発明はビットコインのブロックチェーンと共に使用することに限定されず、代替のブロックチェーンの実装及びプロトコルが本発明の範囲に含まれることに留意すべきである。
【0003】
ブロックチェーンは、ブロックにより構成される、コンピュータに基づく非集中型の分散型システムとして実装される総意に基づく電子台帳である。また、ブロックはトランザクション及び他の情報により構成される。ビットコインの場合には、各トランザクションは、ブロックチェーンシステム内で参加者間のデジタルアセットの制御の転送を符号化するデータ構造であり、少なくとも1つのインプット及び少なくとも1つのアウトプットを含む。各ブロックは前のブロックのハッシュを含み、ブロックは共にチェーンになって、その発端からブロックチェーンに書き込まれている全てのトランザクションの永久的な変更不可能なレコードを生成する。トランザクションは、そのインプット及びアウトプットに組み込まれたスクリプトとして知られる小さなプログラムを含む。スクリプトは、トランザクションのアウトプットがどのように及び誰によりアクセス可能かを指定する。ビットコインプラットフォーム上で、これらのスクリプトは、スタックに基づくスクリプト言語を用いて記述される。
【0004】
トランザクションがブロックチェーンに書き込まれるために、「検証され」なければならない。幾つかのネットワークノードは、マイナーとしての機能を果たし、各トランザクションが有効であることを保証するために作業を実行し、無効なトランザクションはネットワークから拒否される。例えば、ノードにインストールされたソフトウェアクライアントは、未使用トランザクションアウトプット(unspent transaction outputs:UTXO)を参照するトランザクションに対して、この検証作業を実行する。検証は、そのロック及びアンロックスクリプトを実行することにより実行されてよい。ロック及びアンロックスクリプトの実行が真と評価した場合、及び特定の他の条件が満たされた場合、トランザクションは有効であり、トランザクションはブロックチェーンに書き込まれる。従って、トランザクションがブロックチェーンに書き込まれるためには、トランザクションは、i)トランザクションを受信したノードにより検証され、トランザクションが検証された場合に、ノードは該トランザクションをネットワーク内の他のノードに中継し、ii)マイナーにより構築された新しいブロックに追加し、iii)マイニングされ、つまり過去のトランザクションの公開台帳に追加されなければならない。トランザクションは、充分な数のブロックがブロックチェーンに追加されて、トランザクションが事実上不可逆にされると、確認されたと見なされる。
【0005】
ブロックチェーン技術は、暗号通貨実装の使用で最も広く知られているが、デジタル起業家が、新しいシステムを実装するために、ビットコインの基づく暗号通貨セキュリティシステム、及びブロックチェーンに格納可能なデータの両方の使用を探索し始めている。ブロックチェーンが、暗号通貨の領域に限定されない自動タスク及びプロセスのために使用できれば、非常に有利である。このようなソリューションは、それらの用途において一層多様でありながら、ブロックチェーンの利点(例えば、永久的、イベントの耐タンパレコード、分散プロセス、等)を利用できる。
【0006】
研究の一分野は、「スマートコントラクト(smart contracts)」の実装のためのブロックチェーンの使用である。これらは、機械可読取引又は合意の条件の実行を自動化するために設計されたコンピュータプログラムである。自然言語で記述され得る従来の取引と異なり、スマートコントラクトは、結果を生成するためにインプットを処理できるルールを含み、該結果に依存して動作を実行させることのできる、機械実行可能プログラムである。
【0007】
ブロックチェーンに関連する関心の他の分野は、ブロックチェーンを介する現実世界のエンティティの表現及び転送のための「トークン」(又は「カラードコイン」)の使用である。潜在的に機密な又は秘密のアイテムは、識別可能な意味又は値を有しないトークンにより表現できる。従って、トークンは、現実世界のアイテムをブロックチェーンから参照できるようにする識別子として機能する。
【0008】
前述のように、本願明細書は、概して、タイムリリース暗号化のためのデジタルタイムロックコントラクトに関する。タイムリリース暗号化の基本的目的は、メッセージが現時点では暗号化できるが、将来の何らかの指定された時間まで誰にも復号できないことである。これは、事実上、「将来にメッセージを送る」又はメッセージを「タイムカプセル」に入れる方法である。以下を含む、この種の機能の多くの可能な用途がある。
・秘密ビッドオークション
・鍵エスクロー方式
・受理証不要の投票
・機密データのタイムリリース
・政治的に慎重を期する情報の「デッドマン装置」
【0009】
タイムリリース暗号化システムを実装するための2つの一般的アプローチがあり、これらは1996年のRivest, Shamir、及びWagnerによる着想についての最初の詳細な論文[Rivest1996]に概説された。これらは以下の通りである。
1.「タイムロックパズル」の使用。復号するために時間の掛かる計算作業を必要とする情報の暗号化。
2.将来の指定時間まで、秘密情報を漏らさないことを約束する信頼できるエージェントの使用。
【0010】
これらのアプローチのうちの前者は、第三者の関与を必要としないが、2つの深刻且つ不可避な欠点がある。つまり、第1に、計算ハードウェアの性能差及び未知の将来の技術革新のために、特定のパズルを解くためにどれくらい長く掛かるかを高精度に予測することができないことである。第2に、復号を実行するパーティは、タイムロックの期間全体の間、連続する高コストな計算作業を実行しなければならない。
【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/2017/106.pdf)は、タイムロック暗号化の一例を開示する。開示の使用例では、ユーザは機密書類を暗号化する。復号者は、期限tが経過したかどうかをチェックする機能をトリガするスマートコントラクトへトランザクションを送信することにより、復号鍵へのアクセスを要求する。時間が正しい場合、復号者は鍵を取得する。システムが、特定時間ウインドウ内に要求された場合にのみ復号鍵を利用可能にするような、より高度な機能を提供できることが、提案される。
【0015】
「Secure Multiparty Computations on Bitcoin」(URL: https://eprint.iacr.org/2013/784.pdf)は、ビットコイン通貨を用いるマルチパーティくじ引きのためのプロトコルを開示する。この文献は、ビットコインシステムが、コミッターが彼の秘密を特定時間フレーム内に暴露しなければならない又は罰金を支払わなければならない、定時コミットメントのバージョンを構成するための魅力的な方法を提供することを示す。デポジットは、誠実に振る舞わない参加者によりゲームが早く終わる場合に、没収される参加者により提供される。
【0016】
US2016086175は、資産にアクセスするブロックチェーンシステムを開示する。ルーム(room)は、特定期間の間、部屋を借りたいと望むユーザによりクレジットがデポジットされるアドレスと共に、秘密/公開鍵ペアを有し、これらのデータはトランザクションに含まれる。時間が正しいとき、解錠され、ユーザは部屋に入ることを許可される。部屋が要求された時間の間、利用可能でない場合、返金される部屋へのアクセスを得るために、ユーザにより部屋の提供者に料金が支払われる。
【発明の概要】
【0017】
本願明細書は、タイムリリース暗号化サービスを許可無しパブリックブロックチェーンによりセキュアにすることを可能にするシステム及び方法を記載する。サービスは、公開鍵を生成し、次にサービスのクライアントにより指定された将来の時間に対応する秘密鍵を公開する。このサービスのセキュリティ及び信頼性は、新規なスマートコントラクトシステムから得られ、一例ではビットコインスクリプトとして実装される。これは、秘密鍵を正しい時間に公開することを奨励し、早い又は遅い公開又は鍵の漏洩に不利益をもたらす。サービスは、信頼できない設計である。つまり、クライアントは秘密鍵へのアクセスを与えられないが、彼らは、正しい値がコントラクト内で指定された時間にブロックチェーン上に公開されるという保証と共に、サービスの暗号化アセットを提供するだけである。一例では、これは、トランザクションアウトプットのタイムロック及びハッシュロックと組み合わされたゼロ知識証明により達成される。
【0018】
本発明の第1の態様によると、ブロックチェーンネットワーク上で公開暗号鍵を生成し及び指定時間期間の後に対応する秘密暗号鍵へのアクセスを可能にする、コンピュータにより実施される方法であって、前記方法は、
前記ブロックチェーンネットワーク上のエージェントとクライアントとの間のデジタルタイムロックコントラクトを構成するステップであって、前記エージェントは前記ブロックチェーンネットワーク上のエージェントアドレスと関連するエージェント署名とを有し、前記クライアントは前記ブロックチェーンネットワーク上のクライアントアドレスと関連するクライアント署名とを有し、前記デジタルタイムロックコントラクトは、
(i)前記エージェントが、前記ブロックチェーンネットワーク上の前記公開暗号鍵に対応する前記秘密暗号鍵を保持し、次に前記暗号秘密を前記ブロックチェーンネットワークへ指定時間ウインドウ内に公開すること、
(ii)前記エージェントが、保持するために第1暗号化アセット(例えばデポジット)を提供し、次に前記暗号秘密鍵を前記ブロックチェーンネットワークに前記指定時間ウインドウ内に公開し、前記第1暗号化アセットは、前記暗号秘密鍵が前記ブロックチェーンネットワーク上に前記指定時間ウインドウ内に公開されるとき、前記ブロックチェーンネットワーク上の前記エージェントアドレスへ転送可能であること、
(iii)前記クライアントは、保持するために第2暗号化アセット(例えば料金)を前記エージェントに提供し、次に前記暗号秘密鍵を前記ブロックチェーンネットワークに前記指定時間ウインドウ内に公開し、前記第2暗号化アセットは、前記暗号秘密鍵が前記ブロックチェーンネットワークに前記指定時間ウインドウ内に公開されるとき、前記ブロックチェーンネットワーク上の前記エージェントアドレスへ転送可能であること、
(iv)前記暗号秘密鍵が前記時間ウインドウの始まる前に公開される場合、前記第2暗号化アセットは、前記ブロックチェーンネットワーク上の前記クライアントアドレスへ転送可能であること(前記クライアント又は他の誰かが、前記エージェントの前記第1暗号化アセットを取り込むために前記秘密鍵を使用してよい)、
(v)前記暗号秘密鍵が前記時間ウインドウの終わる前に公開されない場合、前記第2暗号化アセットは前記ブロックチェーンネットワーク上の前記クライアントアドレスへ転送可能であること(前記第1暗号化アセットは、前記ブロックチェーンネットワーク上の前記クライアントアドレスへも転送可能であってよい)、
を指定する、ステップ、
前記ブロックチェーン上でのマイニングのために、前記デジタルタイムロックコントラクトを前記ブロックチェーンネットワークへブロードキャストするステップ、
のうちの一方又は両方を含む、コンピュータにより実施される方法が提供される。
【0019】
前記デジタルタイムロックコントラクトを構成するステップ、及び前記コントラクトをブロードキャストするステップは、同じエンティティにより実行されてよい。しかしながら、これらのステップは異なるエンティティにより実行され得ることも考えられる。ここで、前述の定義は、任意の単一エンティティにより要求されているステップの一方又は両方を指定する。
【0020】
留意すべきことに、ここに記載される本発明は、ビジネスを行うより良い方法として、ブロックチェーンで実装されるタイムロックコントラクトを提供するだけではない。本発明の開始点は、暗号化方法を用いてタイムロックコントラクトを実装することが知られていることである。しかしながら、これらの従来のシステムは技術的問題を有する。従来技術に伴う技術的問題は、それらがセキュアでなく、又はそれらの使用が困難であり計算集約的であり得ることである。これらの問題は生来技術的である。本発明は、セキュアであり且つ利用が容易であり且つ計算効率的なソリューションを提供する。つまり、本発明は、タイムロックコントラクトを信頼不要な方法で実装するために、セキュリティと低計算オーバヘッドを組み合わせるシステムを提供するという観点で、より良いコンピュータシステムを提供する。セキュリティ、使用の容易さ、及び計算効率の組み合わせを提供することは、本発明の技術的貢献である。
【0021】
前記コンピュータにより実施される方法は、前記クライアントが、デジタルタイムロックコントラクトを設定する要望を示す要求を送信することにより、開始され得る。前記クライアントは、前記第2暗号化アセット及び前記タイムウインドウを指定できる。前記エージェントは、次に、前記暗号公開鍵及び暗号秘密鍵ペアを構成できる。前記エージェントは、次に、前記デジタルタイムロックコントラクトも構成できる。前記デジタルタイムロックコントラクトは、前記ブロックチェーンに埋め込まれた後にアクティブになることができ、前記暗号公開鍵は、データを暗号化するために使用されるよう公に利用可能であり、該データは前記暗号秘密鍵が公開されるまで復号できない。
【0022】
前記時間ウインドウは、前記時間ウインドウが始まる時間t及び時間期間Δtとして指定でき、Δtの後に前記時間ウインドウが終わる。前記デジタルタイムロックコントラクトは、以下の転送のうちの1つ以上が可能になるよう構成できる:
前記第2暗号化アセットは、任意の時間に、前記暗号秘密鍵、前記暗号秘密鍵から導出可能なタイムロックパズル値、及び前記クライアント署名により、前記クライアントアドレスへ転送可能である、
前記第2暗号化アセットは、時間tの後に、前記暗号秘密鍵及び前記エージェント署名により、前記エージェントアドレスへ転送可能である、
前記第2暗号化アセットは、時間t+Δtの後に、前記クライアント署名により、前記クライアントアドレスへ転送可能である、
前記第1暗号化アセットは、任意の時間に、前記暗号秘密鍵及び前記暗号秘密鍵から導出可能なタイムロックパズル値を提供することにより、任意のアドレスへ転送可能である、
前記第1暗号化アセットは、時間tの後に、前記暗号秘密鍵及び前記エージェント署名により、前記エージェントアドレスへ転送可能である、
前記第1暗号化アセットは、時間t+Δtの後に、前記クライアント署名により、前記クライアントアドレスへ転送可能である。
【0023】
以上に鑑み、ブロックチェーンネットワーク上で公開暗号鍵を生成し、指定時間期間の後に対応する秘密暗号鍵へのアクセスを可能にする、コンピュータにより実施される方法の別の定義は、
前記ブロックチェーンネットワーク上のエージェントとクライアントとの間のデジタルタイムロックコントラクトを構成するステップであって、前記エージェントは前記ブロックチェーンネットワーク上のエージェントアドレスと関連するエージェント署名とを有し、前記クライアントは前記ブロックチェーンネットワーク上のクライアントアドレスと関連するクライアント署名とを有し、前記デジタルタイムロックコントラクトは、
前記エージェントからの第1暗号化アセット(例えばデポジット)、
前記クライアントからの第2暗号化アセット(例えば料金)、
暗号公開鍵、及び、
前記エージェントが前記暗号公開鍵に対応する暗号秘密鍵を公開すべき時間ウインドウであって、前記時間ウインドウは前記時間ウインドウが始まる時間tと時間期間Δtとにより定められ、前記時間期間Δtの後に前記時間ウインドウが終わる、時間ウインドウ、
を指定し、前記デジタルタイムロックコントラクトは、以下の転送が可能になるよう構成される:
前記第2暗号化アセットは、任意の時間に、前記暗号秘密鍵及び前記暗号鍵から導出可能なタイムロックパズル値、及び前記クライアント署名により、前記クライアントアドレスへ転送可能である、
前記第2暗号化アセットは、時間tの後に、前記暗号秘密鍵及び前記エージェント署名により、前記エージェントアドレスへ転送可能である、
前記第2暗号化アセットは、時間t+Δtの後に、前記クライアント署名により、前記クライアントアドレスへ転送可能である、
前記第1暗号化アセットは、任意の時間に、前記暗号秘密鍵及び前記暗号秘密鍵から導出可能なタイムロックパズル値を提供することにより、任意のアドレスへ転送可能である、
前記第1暗号化アセットは、時間tの後に、前記暗号秘密鍵及び前記エージェント署名により、前記エージェントアドレスへ転送可能である、及び、
前記第1暗号化アセットは、時間t+Δtの後に、前記クライアント署名により、前記クライアントアドレスへ転送可能である、ステップと、
前記デジタルタイムロックコントラクトを、前記ブロックチェーン上でのマイニングのために、前記ブロックチェーンネットワークへブロードキャストするステップと、のうちの一方又は両方を含む。
【0024】
前記エージェントは、複数のクライアントと共に複数のデジタルタイムロックコントラクトに参加してよい。前記エージェントは、前記秘密鍵を保持する単一のエージェントであり得る。代替として、前記エージェントは、それぞれが前記暗号秘密鍵のシェアを保持する複数のエージェントを含んでよい。この場合、前記暗号秘密鍵の導出は、前記複数のエージェントにより提供される閾数の秘密鍵シェアにより有効になる。前記第1暗号化アセット及び前記第2暗号化アセットは、次に前記エージェントの間で分割される。サービスのセキュリティ及び信頼性は、中核のプロトコルを、それぞれ個別のコントラクトを有する独立したサービスプロバイダのグループに拡張し、ディーラー不要のシークレット共有(m-of-n)閾値方式を用いて秘密鍵のタイムリリースを分配することにより、更に強力にできる。従って、サブ閾数の機能不全のサービスプロバイダに対して耐性がある。私達は、任意の料金が支払われる前にコントラクトを解除するために、共有公開鍵に対応する秘密鍵シェアが公開されることをクライアントが証明することを可能にする拡張ゼロ知識証明を記載する。
【0025】
クライアントは、デジタルタイムロックコントラクトに基づき、複数のエンドユーザにサービスを提供できる。例えば、サービスは、秘密ビッドオークション、鍵エスクロー方式、投票方式、機密データのタイムリリース、のうちの1つ以上であってよい。
【0026】
ここに記載のコンピュータにより実施される方法は、コンピュータ実行可能命令を含むコンピュータ可読記憶媒体であって、該命令は実行されると、ここに記載の方法を実行するようプロセッサを構成する、コンピュータ可読記憶媒体を提供することにより実施できる。更に、電子装置であって、インタフェース装置と、前記インタフェース装置に結合されたプロセッサと、前記プロセッサに結合されたメモリであって、前記メモリは、実行されると、ここに記載の方法を実行するよう前記プロセッサを構成するコンピュータ実行可能命令を格納している、メモリと、を含む電子装置が提供され得る。
【0027】
ここに記載の本発明は、前述の背景技術で議論した従来技術にとは異なる。
【0028】
Ethereum Alarm Clockシステムは、エージェントが公開鍵に関連する秘密暗号鍵を保持し、及び次に指定時間ウインドウ内に秘密鍵を公開し、エージェントが適正な時間に秘密暗号鍵を公開することを保証するために、デジタルコントラクトが該システムを管理するために提供されることを開示していない点で、ここに記載のシステムと大きく異なる。更に、従来のシステムは、使用に関連付けられたデータが暗号化される指定時間量の間、公開鍵の使用を可能にせず、次に使用に関連付けられたデータの復号を可能にするために秘密鍵を公開しない。
【0029】
「μchain: How to Forget without Hard Forks」で記載されたシステムも、エージェントが公開鍵に関連する秘密暗号鍵を保持し、及び次に指定時間ウインドウ内に秘密鍵を公開し、エージェントが適正な時間に秘密暗号鍵を公開することを保証するために、デジタルコントラクトが該システムを管理するために提供されることを開示していない点で、ここに記載のシステムと大きく異なると考えられる。従来のシステムは、使用に関連付けられたデータが暗号化される指定時間量の間、公開鍵の使用を可能にせず、次に使用に関連付けられたデータの復号を可能にするために秘密鍵を公開しないと考えられる。ここで、秘密鍵の公開は、適正な時間における公開を保証する条項を前提とする。むしろ、μchainの文献では、復号鍵は、エージェントにより生成されるのではなく、システムのユーザにより生成される。つまり、ユーザは、復号鍵の公開を制御したままであり、従って、システムはユーザを信頼することに依存する。ユーザは、従って、直ちにセキュリティを侵害し得る。
【0030】
同様に、「Secure Multiparty Computations on Bitcoin」及びUS2016086175も、エージェントが公開鍵に関連する秘密暗号鍵を保持し、及び次に指定時間ウインドウ内に秘密鍵を公開し、エージェントが適正な時間に秘密暗号鍵を公開することを保証するために、デジタルコントラクトが該システムを管理するために提供されることを開示していない点で、ここに記載のシステムと大きく異なる。
【図面の簡単な説明】
【0031】
本発明の上述の及び他の態様は、本願明細書に記載される実施形態から明らかであり、それらの実施形態を参照して教示される。本発明の実施形態は、単なる例として添付の図面を参照して以下に説明される。
図1】クライアントとエージェントとの間の通信チャネルの確立後に、クライアントとエージェントとの間でデジタルタイムロックコントラクトを設定する初期化プロトコルのフロー図を示す。
図2】クライアントとエージェントとの間のデジタルタイムロックコントラクトを構成するトランザクションスクリプトの一例を示す。
図3】時間期間に依存するデジタルタイムロックコントラクト及びアウトプットの宛先の概略時系列を示す。
図4】マルチエージェントプロトコルの概略図を示す。
【発明を実施するための形態】
【0032】
ビットコインブロックチェーンの出現は、(ブロックヘッダに記録されるような)現時点における分散型のグローバルな総意、及びコントラクトの信頼不要な(trustless)自動実行(scripts)の両方の存在するシステムをもたらした。これらは、セキュア且つ信頼できるタイムリリース暗号化サービスの実現のために活用可能な独特の特徴である。本願明細書では、私達は、ビットコインスクリプトに基づくスマートコントラクト、及びサービスプロバイダにおける完全な信頼に依存しないゼロ知識証明の組み合わせを利用するタイムリリース暗号化サービスにためのシステムを記載する。更に、私達は、単一の鍵公開に対して複数のエージェントを使用して、分散化を通じてサービスの回復力及びセキュリティを向上するために、プロトコルがディーラー無し閾値方式を用いてどのように拡張可能であるかを示す。
【0033】
特定の構成は、プロトコルを完全に信頼不要にするための知識のゼロ知識証明(zero-knowledge proofs:ZKP)の概念を利用する。方式の部分として使用され得る2つの技術がある。つまり、非対話型証明、及びcut-and-chooseである。
【0034】
非対話型ゼロ知識(Non-interactive zero-knowledge:NIZK)証明は、関与するパーティ間で必要な通信を最小化するので、本願にとって好ましい。しかしながら、それらは、実装が複雑且つ計算コストが高くなり得る。形式上、NIZK証明は、証明者(prover)から検証者(verifier)に直接提供可能であるが、この場合には彼らは信頼できる設定(σ)を必要とする。本願では、検証者は、信頼できる設定を実行し、次にこれを証明者へ送信する。次に、証明者は、証明(π)を計算し、これを検証者へ返送する。
【0035】
第1の適用では、私達は、(検証者に提供される)ハッシュのプレイメージが楕円曲線公開鍵(検証者にも提供される)に対応する秘密鍵と等しいというゼロ知識証明を要求する。この特定のNIZKの数学的構造は、[Fuchsbauer 2008]で詳述される。このNIZK証明は、zk-SNARKS[Lundkvist 2017]により実施可能である。
【0036】
拡張システムを用いる第2の適用では、効率的NIZK証明の構成は興味深い。この場合、ZKPの呼び出したcut-and-chooseの簡易相互作用タイプが利用可能である[Crepeau 2011]。本アプローチでは、証明者は、検証者に、異なるステートメントへの膨大な数のコミットメントを提供する。検証者は、次に、これらのコミットメントの部分集合をランダムに選択し、証明者がそれらを証明するための知識を送信することを要求する。ステートメントのこの部分集合が真であることが示されると、検証者は、残りのステートメントも真である確率が分かる。
【0037】
特定の構成は、ビットコイントランザクションスクリプトの幾つかの標準的特徴を利用して、アウトプットのタイムロック及びハッシュロックの使用を可能にする。
【0038】
ビットコインアウトプットは、(例えば、HASH256オペコードを用いて)指定された値にハッシュするシークレットを提供するよう、アンロックスクリプトが必要とされるように、構成可能である。つまり、アウトプットを使用するために、インプットは、該アウトプットの中で指定された別の値にハッシュする値を提供しなければならない[Maxwell 2016]。
【0039】
アウトプットは、また、何らかの予め指定された将来の時点まで、使用不可能であるように構成可能である。これは、CHECKLOCKTIMEVERIFY(CLTV)オペコードを用いて達成される。該オペコードは、指定されたユニックスエポックタイム(unix epoch time)又は指定されたブロック高に達するまで、トランザクションの使用を防ぐために使用可能である[Todd 2014]。
【0040】
スマートコントラクト構造を保証するために、短いタイムロックパズルの新規な適用が、「レース攻撃(race attack)」を防ぐために利用される。(アウトプットのロックを)設定するために無視できる計算作業しか必要としない連続二乗タイムロックパズル(successive squaring time-lockpuzzle)が使用可能である[Rivest 1996]。設定パラメータを所有しない第2パーティでは、パズルを解除し及びアウトプット値を明らかにするために、設定数の(特定時間量を要する)シリアル計算がインプットに対して実行されなければならない。
【0041】
信頼できるエージェントによる時間公開暗号化方式の1つの構成では、エージェントは、(公開鍵暗号システムを用いる)公開秘密鍵ペアを生成し、情報を暗号化するために使用すべきクライアントの公開鍵を公開し、次に受信者へ送信する。次に、合意した時間で(エージェントにより決定される)、エージェントは、情報を復号するために、秘密鍵を受信者に公開する。この場合、エージェントは、この動作を実行するために完全に信頼され、及び秘密鍵をセキュアに保持する必要がある。
【0042】
Rabin及びThorpe[Rabin 2006]は、鍵生成を何らかの信頼するに値するエージェントのグループの間で分散することにより、この構成のセキュリティ及び障害耐性を拡張するためにシステムを提案した。その結果、パーティのうちの幾つかが不誠実である又は情報漏洩した場合でも、秘密鍵を公開すべき適正な時間であると閾数のエージェントが合意するまで、彼らのうちの誰も完全な秘密鍵を知ることができない。
【0043】
このシステムでは、ネットワーク接続されたエージェント(n)のグループは、ディーラー不要閾(m-of-n)シークレット共有方式を用いて協力して、共有秘密鍵及び対応する共有公開鍵を生成する。該共有公開鍵は、次にクライアントに公開される(クライアントは、次にメッセージを暗号化できる)。閾数(m)のエージェントが、鍵を公開すべき時間に達したことに合意するときのみ、完全な秘密鍵が再構成され、受信者へ送信され得る。
【0044】
シャミアの秘密共有方式(Shamir's secret sharing scheme:SSSS)[Shamir 1979]は、多項式の次数tがt+1個の点の任意の集合に適合できるという概念に基づく。次数tの多項式f(x)は、共有秘密鍵により定数項として形成され(a=f(0))、残りの係数はランダムに選ばれる。曲線上のn個の点は、次に、各参加者に与えられる。m=t+1以上の参加者が次に彼らの点を結合する場合、これらの点に次数tの多項式を適合させる充分な情報があり、aはシークレットとして解明される。この方式は、任意の閾数を有する任意の膨大な数のパーティの間で、単一の秘密鍵の共有を可能にする。
【0045】
標準的なSSSSは、多項式を生成し及び(単一障害点であり、従って信頼不要ではない)シークレットシェアを分散するために、信頼できるディーラーの要件を除去するよう拡張可能である。このディーラー不要SSSSでは、各参加者Piは、彼ら自身のランダムな次数tの多項式fi(x)を生成し、次に、fi(j)を各々の他の参加者Pjへセキュアに送信する。各Piは、次に全ての受信点を加算し、f(i)+f(i)+...+fn(i)、彼らのシークレットシェアSi=f(i)を取得する。これは、共有多項式f(x)上のPi点である。
【0046】
シークレットシェアが生成された後に、共有秘密鍵に対応する(どの参加者も知らない)公開鍵は、(楕円曲線生成器Gにより)以下のように計算される。
【0047】
参加者Piは、彼らの公開鍵シェアをbisi×Gとして計算する。ここで、i=1,...,t+1であり、次式の通りである。
【数1】
【0048】
これらの公開鍵シェアは、次に、ブロードキャストされ、共有公開鍵Aは、次に、単にt+1個のシェアの和として以下のように計算される。
【数2】
【0049】
<単一エージェントプロトコル>
本章は、単一エージェントが時間公開暗号化サービスを提供する場合の構成を記載する。プロトコルは、ビットコイントランザクション及びその生来のスクリプト言語(Script)に関連して記載され、一般性を失わないが、パブリックブロックチェーン及び等価なスクリプト機能を有する任意の暗号化システムに適用可能である。
【0050】
プロトコルは、2つのパーティに直接関連する。
・クライアントは、必要なロックタイム暗号化サービスのパラメータを指定し、そのための料金(F)を支払う。クライアントは、アドレスCAddrを制御する。
・エージェントは、タイムロック暗号化サービスを実行し、正常終了すると料金を受け取る。エージェントは、サービスが適正に実行されない場合に没収されるデポジット(D)を提供する。エージェントは、アドレスAAddrを制御する。
【0051】
図1は、クライアントとエージェントとの間の通信チャネルの確立後に、クライアントとエージェントとの間でデジタルタイムロックコントラクトを設定する初期化プロトコルのフロー図を示す。設定は、以下の通り進行する。
【0052】
1.クライアントは、パブリックフォーラムの中でタイムロックサービスのための要求を提出する。要求は、クライアントアドレス(CAddr)、彼らが支払いたい料金(F)、時間(T)であって、該時間の後に鍵が公開されること彼らが要求する時間(T)、及び必要な待ち時間(Δt)で構成される。
【0053】
2.サービスを実行したいと望むエージェントは、クライアントと連絡を取り、セキュア通信チャネルを確立する。クライアントは、料金のために使用されるべきUTXOのトランザクションIDを送信する。
【0054】
3.エージェントは、次に、ランダム暗号化秘密鍵(EPrivK)及び対応する公開鍵(EPubK)をセキュアに生成する。
【0055】
4.エージェントは、次に、EPrivKから出力されるタイムロックパズルである値tlpEPrivKを計算し、インプットとしてのEPrivKから計算するために、約1時間の連続計算を必要とする(標準的なビットコインブロックチェーントランザクション確認時間である)。
【0056】
5.エージェントは、次に、EPubK、対応する秘密鍵のSHA-256ハッシュH(EPrivK)及びH(tlpEPrivK)をクライアントへ送信する。
【0057】
6.クライアントはNIZK証明設定を実行し:σ←Setup(1256)、結果をエージェントへ送信する。
【0058】
7.エージェントは、証明π←Prove(σ,H(EPrivK),EPubK)、ここでH(EPrivK)のプレイメージはEPubKに対応するECC秘密鍵である、及び、証明π←Prove(σ,H(tlpEPrivK),H(EPrivK))、ここでH(tlpEPrivK)のプレイメージはH(EPrivK)のプレイメージである、を約1時間のタイムロックパズルで構成し、それらをクライアントへ送信する。
【0059】
8.クライアントは、両方の証明を検証する:Verify(σ,H(EPrivK),π)=true及びVerify(σ,H(tlpEPrivK),π)=trueである。
【0060】
9.エージェントは、次に、要求パラメータ、暗号化秘密鍵(EPrivK)のハッシュ、及びtlpEPrivKのハッシュを用いて、タイムロック暗号化スマートコントラクトとして機能するトランザクション(Tx0)を生成する。
【0061】
Tx0は2つのインプットを有する。つまり、クライアント料金(F)UTXO、及びエージェントデポジット(D)UTXOである。
【0062】
Tx0は3つのアウトプットを有する。つまり、料金量のためのアウトプット1、デポジット量のためのアウトプット2、及び暗号化公開鍵メタデータのためのアウトプット3である。
アウトプット1(Output1):
任意の時間における、EPrivK、tlpEPrivK、及びクライアント署名による、クライアントアドレスへの支払(F)。
時間Tの後の、EPrivK、及びエージェント署名による、エージェントアドレスへの支払(F)。
時間T+ΔTの後の、クライアント署名による、クライアントアドレスへの支払(F)。
アウトプット2(Output2):
任意の時間における、EPrivK、及びtlpEPrivKによる、任意のアドレスへの支払(D)。
時間Tの後の、EPrivK、及びエージェント署名による、エージェントアドレスへの支払(D)。
時間T+ΔTの後の、クライアント署名による、クライアントアドレスへの支払(D)。
アウトプット3(Output3):
メタデータとして暗号化公開鍵(EPubK)を含むOP_RETURN。
【0063】
図2は、トランザクション構造全体を示す。図2では、明確化のために、<…PubKey>はOP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFYで置き換えられていることに留意する。ここで、pubKeyHashはアドレスと等価である。アウトプット1及び2は、関連パーティへ送信される及び/又は発行される対応するRedeemスクリプトを有するP2SH(pay-to-script-hash)scriptPubKeyとして実装されてよい。
【0064】
10.エージェントは、トランザクションに署名し、該トランザクションをクライアントへ送信する。
【0065】
11.クライアントは、トランザクションに署名し、該トランザクションをビットコインネットワークへブロードキャストする。
【0066】
12.トランザクションがブロックチェーンに埋め込まれる(mined)と、タイムロックコントラクトが起動される。EPubKは、今や、任意のデータを暗号化するために使用されるよう、公に利用可能である。該データはEPrivKが公開されるまで復号できない。
【0067】
図3は、時間期間に依存するデジタルタイムロックコントラクト及びアウトプットの宛先の概略時系列を示す。コントラクトは、料金及びデポジットの両方を請求するために、エージェントが暗号化秘密鍵(EPrivK)を時間間隔T~T+ΔTの範囲内で公開するよう、設計される。これを行うために、エージェントは、2つのトランザクションTx1(Tx0アウトプット1を使用する)及びTx2(Tx0アウトプット2を使用する)を生成する。アウトプットをアンロックすべきscriptSigは、<EPrivK> <AAddr Pubkey> <AAddr Sig>の両方を含む。Tx1及びTx2は、次に、F及びDの両方をエージェントにより選択されたアドレスに支払う。これらのトランザクションがブロックチェーンに埋め込まれると、EPrivKは、次に、公に公開され、誰にでも使用可能になる。
【0068】
エージェントが時間tの前に誰かにEPrivKを(場合によっては賄賂と引き換えに)漏らすのを妨ぐために、コントラクトは、時間Tの前にEPrivKを知った者がハッシュプレイメージ(及び対応するタイムロックパズルtlpEPrivK、以下のレース攻撃保護を参照する)を署名無しで提供することによりアウトプット2を使用し、次にエージェントデポジット全体を請求できるように、設計される。このパーティは情報漏洩者(leaker)と呼ばれる。これが生じると、クライアントは、次にEPrivKも知り、時間Tの前にscriptSig <EPrivK> <CAddr Pubkey> <CAddr Sig>によりアウトプット1を使用でき、クライアント料金を再請求する。
【0069】
これは、EPrivKをセキュアに保つよう、エージェントに対する強力な奨励構造を提供する。誰か(ハッカーを含む)が時間Tの前にEPrivKを発見した場合、彼らは、エージェントのデポジットを匿名で請求できる。エージェントが時間Tの前に情報漏洩者としてデポジットを請求した(又はそれを可能にした)場合、彼らは、料金を剥奪される(これは、クライアントへ返金される)。従って、料金及びデポジットの値の選択は、システムのセキュリティに影響し、暗号化要求のための理由に対し適切であるべきである。
【0070】
コントラクトは、また、確実にエージェントに時間Tの後、時間T+ΔTの前に(ここでΔTは必要な待ち時間である)、暗号化鍵を公開させるよう設計される。時間T+ΔTの後に、EPrivKが公開されていない場合、クライアントは、アウトプット1及びアウトプット2の両方をアンロックできる(料金を再請求し、更にエージェントのデポジットを補償として取り入れる)。この場合、クライアントは、scriptSig <CAddr Pubkey> <CAddr Sig>により2つのトランザクションTxR1(Tx0アウトプット1を使用する)及びTxR2(アウトプット2を使用する)の両方を生成し、F及びDの両方をクライアントにより選択されたアドレスに支払う。
【0071】
ビットコインスクリプト言語の特性は、(OP_CHECKLOCKTIMEVERIFYにより)アウトプットが特定の時点まで使用されることを防ぐことが可能であるが、ある時点の後にアウトプットが使用されることを防ぐことはできない(該時点の前に、使用可能であった場合)。従って、scriptSigが有効になると、それは永久に有効なままである。これは、EPrivKを提供することにより、誰でもいつでも、時間Tの後でさえ、H(EPrivK)のプレイメージを要求されるだけで、アウトプット2を使用できる、アウトプット2のロックスクリプトに伴う問題を提示する。
【0072】
これは、エージェントに対する「レース二重使用攻撃(race double spending attack)」を可能にし得る。つまり、エージェントがTx1及びTx2をビットコインネットワークに(時間Tの後に)適正にブロードキャストすると、任意のマイナーがそれらのいずれかからEPrivKを抽出し、先ずアウトプット2を使用し及びデポジットを盗むために、彼ら自身のanyone-can-spend(誰でも使用可能)トランザクションをブロックに含め得る(又は他の誰かが自由に取り替え可能である)。
【0073】
この攻撃を防ぐためにここで実装されるソリューションは、常にアウトプット2をアンロックするためにEPrivKと一緒に提供されるべきtlpEPrivK(EPrivKから出力されるタイムロックパズル)に対する追加要件である。誰か(情報漏洩者)が時間Tの前にEPrivKを所有するようになった場合、彼らは、1時間の計算によりtlpEPrivKを内密に決定し、次にデポジットを請求できる(つまりアウトプット2を解除する)。EPrivKがmempoolの中でマイニングされるのを待っているTx1及びTx2に埋め込まれているとき、彼らが(時間Tの後に)最初にEPrivKを取得した場合、彼らがtlpEPrivKを導出する時まで(1時間の計算)、アウトプット2を使用するエージェントトランザクション(Tx2)は、ブロックチェーン内で既に確認されている。レース攻撃保護の結果は、tlpEPrivKが導出に1時間を要するので、デポジットを剥奪されるリスクを伴わずに、エージェントが時間Tの前に1時間未満でEPrivKを公開することが可能であることである。これは、コントラクトの「時間分解能」又は精度を1時間に制限する。
【0074】
<複数エージェントプロトコル>
上述のスマートコントラクトプロトコルは、閾値秘密鍵による複数エージェントの場合に格納可能である。この場合、各エージェントは、彼ら自身のデポジット及び個別料金により、彼ら自身のTx0バージョンを生成する。唯一の違いは、秘密鍵(EPrivK)ハッシュ及び公開鍵(EPubK)が秘密鍵シェアのハッシュ及び共有公開鍵でそれぞれ置き換えられることである。各コントラクトは、独立に実行され、鍵シェアは時間Tの後にブロックチェーン上で明らかにされる。秘密鍵全体を再構成するためには閾数の鍵シェアが必要なので、システムは、サブ閾数のエージェントが機能不全であることに耐え、より重要な及び重大なアプリケーションに対して単一障害点(単一エージェント)を除去する。この拡張プロトコルのために必要な主要な技術的相違点は、ディーラー不要の共有鍵生成、エージェントのグループが彼らの秘密鍵シェアのハッシュのプレイメージが公開された共有公開鍵に対応することを協力して証明することを可能にする、複数パーティゼロ知識証明システム、に関連することである。
【0075】
複数エージェントプロトコルは、次に、以下の参加者に関連する。
・必要なロックタイム暗号化サービスのパラメータを指定し、そのための合計料金(F)を支払う(n個のUTXOの間で分割する)クライアント。クライアントは、アドレスCAddrを制御する。
・n個の独立したエージェントが、サービスを協力して実行し、彼らがプロトコルを正しく実行した場合に、それぞれが料金の一部(F/n)を受け取る。各エージェントは、プロトコルが適正に実行されなかった場合に没収されるデポジット(D)を提供する。各エージェント(i=1,2,...,n)は、アドレスAAddriを制御する。
【0076】
図4は、マルチエージェントプロトコルの概略図を示す。設定は、以下の通り進行する。
【0077】
1.クライアントは、パブリックフォーラムの中でタイムロックサービスのための要求を提出する。要求は、クライアントアドレス(CAddr)、彼らが支払いたい料金(F)、時間(T)であって、該時間の後に鍵が公開されること彼らが要求する時間(T)、必要な待ち時間(Δt)、必要なエージェント数(n)、及び必要な閾(m)で構成される。
【0078】
2.サービスを実行したいと望むn個のエージェントは、クライアントと連絡を取り、セキュア通信チャネルを確立する。クライアントは、料金のために使用されるべきUTXOのトランザクションIDを送信する。
【0079】
3.クライアントは、次に、エージェントの各々の詳細な連絡先をグループにブロードキャストし、各エージェントは、グループ内の各々の他のエージェントと(公開鍵暗号システム又はDiffie-Hellman鍵交換により)セキュアな通信を確立する。
【0080】
4.プレイヤは、次に、閾mでディーラー不要秘密共有プロトコルを共同で実行し、共有鍵EPrivK(暗号化秘密鍵)を生成する。各プレイヤ(i=1,...,n)は、次に鍵シェアsEPrivKiを処理する(EPrivKはいずれのパーティにも知られていない)。
【0081】
5.n人のプレイヤのグループは、次に、各秘密鍵シェアに対する彼らの公開鍵シェアを計算し、これらのシェア(sEPubKi)をグループの残りの者にブロードキャストする。各プレイヤは、次に、対応する共有公開鍵EPubKを独立に計算できる。
【0082】
6.エージェント(i=1,...,n)は、次に、sEPrivKiから出力されるタイムロックパズルである値tlpsEPrivKiを計算し、インプットとしてのsEPrivKiから計算するために、約1時間の連続計算を必要とする。
【0083】
7.エージェント(i=1,...,n)は、次に、EPubK、彼らの対応する秘密鍵のSHA-256ハッシュH(sEPrivKi)及びH(tlpsEPrivKi)をクライアントへ送信する。
【0084】
8.エージェントのグループは、次に、クライアントに、彼らの秘密鍵シェアのハッシュのプレイメージが、閾値mで、EpubKに対応する秘密鍵を再構成するために使用可能であることのゼロ知識証明を協力して提供する。このためのNIZK証明の展開は、相当量の作業であり、極めて高価なことがある。しかしながら、「cut-and-choose」法は、比較的効率的に利用可能である。この場合、n人のエージェントのグループは、ステップ4~7を多数回(N=100~1000)、繰り返す。クライアントは、次に、共有公開鍵のうちの1つをランダムに選択し、グループが残りのN-1個の公開鍵に対する秘密鍵シェアを明らかにすることを要求する。クライアントは、秘密鍵シェアが各共有公開鍵に対応する秘密鍵を再構成できること、及び秘密鍵シェアが送信されたハッシュのプレイメージであること、の両方を確認する。これは、次に、エージェントが不誠実であるという(N-1)/N未満の確率があることを裏付ける。任意のエージェントは、無効鍵シェア又はハッシュを提供することが、プロトコルから除去され置き換えられる(及び処理が繰り返される)ことが分かる。ランダムに選択された共有公開鍵(及び対応する秘密鍵シェアハッシュ)は、次に、n個のトランザクションのためのプロトコルの中で使用される。
【0085】
9.エージェント(i=1,...,n)は、次に、要求パラメータ、暗号化秘密鍵(EPrivK)のハッシュ、及びtlpEPrivKのハッシュを用いて、図1と全く同じ構造のトランザクション(Tx0i)を生成する。
【0086】
各Tx0iは2つのインプットを有する。つまり、クライアント料金シェア(F/n)UTXO、及びエージェントデポジット(D/n)UTXOである。
【0087】
各Tx0iは3つのアウトプットを有する。つまり、(F/n)のためのアウトプット1、Dのためのアウトプット2、及びEPubKメタデータのためのアウトプット3である。
Tx0iアウトプット1(Output1):
sEPrivKi、tlpEPrivK、及びクライアント署名による、任意の時間における、クライアントアドレスへの支払(F/n)。
時間Tの後の、sEPrivKi、及びエージェント署名による、エージェントアドレスへの支払(F/n)。
時間T+ΔTの後の、クライアント署名による、クライアントアドレスへの支払(F/n)。
Tx0iアウトプット2(Output2):
任意の時間における、sEPrivKi、及びtlpsEPrivKiによる、任意のアドレスへの支払(D)。
時間Tの後の、sEPrivKi、及びエージェント署名による、エージェントアドレスへの支払(D)。
時間T+ΔTの後の、クライアント署名による、クライアントアドレスへの支払(D)。
Tx0iアウトプット3(Output3):
メタデータとして暗号化公開鍵(EPubK)を含むOP_RETURN。
【0088】
10.各エージェントは、彼らの対応するトランザクションに署名し、該トランザクションをクライアントへ送信する。
【0089】
11.クライアントは、n個のトランザクションの各々に署名し、それらをビットコインネットワークへブロードキャストする。
【0090】
12.トランザクションがブロックチェーンに埋め込まれると、EPubKは今や任意のデータを暗号化するための使用のために公に入手可能になり、該データは、EPrivKがエージェントにより公開されている閾数(m)の鍵シェアsEPrivKiから明らかにされるまで、復号できない。
【0091】
各々の個別コントラクト(Tx0i)は、前述の単一エージェントコントラクトと同じ方法で実行される。各エージェントは、彼らの鍵シェアが時間Tより前に漏洩した場合、彼らのデポジットを失うリスクがある。彼らは、彼らのデポジット及び彼らの料金シェアを返すよう請求するために、時間Tの後に彼らの鍵シェアを公開することを、それぞれ個々に奨励される。各個別コントラクトの実行は、互いに完全に独立である。このシステムは、次に、サブ閾(n-m)数の参加者が彼らの鍵シェアを適正な時間に公開しないこと、又はそれらを早期に漏洩すること、に対して耐性があり、サービスのセキュリティ又は信頼性を危険に晒さない。彼らの鍵シェアを時間T+ΔTの前に公開しない各エージェントについて、クライアントは、彼らの料金シェア及び機能不全のエージェントデポジットを返すよう請求できる。
【0092】
留意すべきことに、上述の実施形態は、本発明を限定するのではなく、当業者は添付の請求項により定められる本発明の範囲から逸脱することなく多数の代替の実施形態を考案できる。請求項中、括弧内に記載された如何なる参照符号も、請求項を制限すると見なされるべきではない。用語「有する(comprising又はcomprises)」等は、全体としていかなる請求項中に及び明細書に列挙された以外の要素又はステップの存在を排除するものではない。本願明細書において、「有する(comprises)」は「含む(includes)又は構成される(consists of)」を意味し、「有する(comprising)」は「含む(including)又は構成される(including of)」を意味する。要素の単数の参照は、該要素の複数の存在を排除するものではなく、逆も同様である。本発明は、複数の別個の要素を有するハードウェアにより又は適切にプログラムされたコンピュータにより、実施され得る。複数の手段を列挙している装置の請求項では、これらの複数の手段は、1つの同一のハードウェア要素により実装することができる。特定の量が相互に異なる従属請求項に記載されるという事実は、これらの量の組み合わせが有利に用いることができないことを示すものではない。
【0093】
参考文献
[Abliz200]: Abliz,Mehmud,andTaiebZnati."Aguidedtourpuzzlefordenialofserviceprevention."ComputerSecurityApplicationsConference,2009.ACSAC'09.Annual.IEEE,2009.
[Fuchsbauer2008]: Fuchsbauer,Georg,andDavidPointcheval."EncryptingProofsonPairingsandItsApplicationtoAnonymityforSignatures."IACRCryptologyePrintArchive2008(2008):528.
[Lundkvist2017]: https://media.consensys.net/introduction-to-zksnarks-with-examples-3283b554fc3b
[Crepeau2011]: Crepeau,Claude."Cut-and-chooseprotocol."EncyclopediaofCryptographyandSecurity.SpringerUS,2011.290-291.
[Maxwell2016]: https://bitcoincore.org/en/2016/02/26/zero-knowledge-contingent-payments-announcement/
[Todd2014]: https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki
図1
図2
図3
図4
【外国語明細書】