JP2020523838A - ネットワークの障害時におけるオフ・ブロックチェーン・チャネルに関して生じるセキュリティ関連脆弱性に対処するためのシステム及び方法 - Google Patents

Abstract

本発明による方法は：エンクレーブ・パブリック・キーを、ノードにおけるＴＥＥに関連するエンクレーブから、ハブに提供するステップ；第１パブリック・キー、第２パブリック・キー、及び第３パブリック・キーでディジタル資産を制限するファンディング・トランザクションをブロックチェーン・ネットワークへブロードキャストすることにより、ハブとのチャネルを設定するステップであって、ディジタル資産の制限は：１）第１パブリック・キーに対応する第１プライベート・キーから生成される第１署名及び第２パブリック・キーに対応する第２プライベート・キーから生成される第２署名の双方；又は２）第３パブリック・キーに対して有効な第３署名により解除され、第３パブリック・キーはグループに関連付けられている、ステップ；エンクレーブ・パブリック・キーで暗号化されたコミットメント・トランザクションを受信するステップ；不具合を検出するステップ；及びエンクレーブからのデータを利用してグループに対してフェイルセーフ活性化リクエストを発行するステップを含む。

Description

本発明は一般に分散された台帳に関し、より詳細にはオフ・ブロックチェーン・チャネル（ｏｆｆ−ｂｌｏｃｋｃｈａｉｎ ｃｈａｎｎｅｌｓ）に関する。本発明は特に、電子通信及び交換の目的で参加者間で設定されたオフ・ブロックチェーン・チャネルの障害時にフェイルセーフ・モードを提供することに関連するが、これに限定されない。そのようなチャネル、及びこれらを介して行われる通信／移転は、攻撃やネットワークでの障害時の利用に関して脆弱的であり得る。

本書では電子的なコンピュータ・ベースの分散型の全ての形態の台帳を含むように用語「ブロックチェーン」を使用する。これらは、ブロックチェーン及びトランザクション・チェーン技術、許可された及び許可されていない台帳、共有台帳、並びにそれらの変形を含むが、これらに限定されない。ブロックチェーン技術の最も広く知られている応用はビットコイン台帳であるが、他のブロックチェーン実装が提案され開発されている。本明細書では、便宜上及び説明の目的でビットコインが参照されるかもしれないが、本発明は、様々なビットコイン・プロトコルで使用することに限定されず、代替的なブロックチェーンの実装及びプロトコルが、本発明の範囲内に属することに留意すべきである。

ブロックチェーンはコンセンサス・ベースの電子台帳であり、これはトランザクション及びその他の情報により構成されるブロックにより構成される、コンピュータ・ベースの非セントラル化された分散システムとして実装される。ビットコインの場合、各トランザクションは、ブロックチェーン・システムの参加者間のディジタル資産のコントロールの移動をエンコードするデータ構造であり、少なくとも１つのインプット及び少なくとも１つのアウトプットを含む。各ブロックは、先行するブロックのハッシュを含み、その結果、それらのブロックは共に、開始以来ブロックチェーンに書き込まれてきた全てのトランザクションについての永続的で変更不可能な記録を作成する。トランザクションは、トランザクションの入力及び出力に組み込まれるスクリプトと呼ばれる小さなプログラムを含み、スクリプトは、トランザクションの出力がどのように誰によってアクセスされ得るかを指定する。ビットコイン・プラットフォームでは、これらのスクリプトはスタック・ベースのスクリプト言語を使用して書かれる。

トランザクションがブロックチェーンに書き込まれるためには、それが「検証済み（ｖａｌｉｄａｔｅｄ）」でなければならない。幾つかのネットワーク・ノードは、マイナーとして振る舞い、各トランザクションが有効であることを保証するために作業を行い、無効なトランザクションはネットワークから拒否される。例えば、ビットコインの場合、ノードにインストールされたソフトウェア・クライアントは、未使用残高（ｕｎｓｐｅｎｔ ｔｒａｎｓａｃｔｉｏｎ ｏｕｔｐｕｔ：ＵＴＸＯ）を参照するトランザクションに対してこの検証作業を実行する。検証は、そのロック及びアンロック・スクリプトを実行することによって実行されてもよい。ロック及びアンロック・スクリプトの実行がＴＲＵＥに評価され、特定の他の条件が満たされる場合、トランザクションは有効であり、トランザクションはブロックチェーンに書き込まれることができる。従ってトランザクションがブロックチェーンに書き込まれるためには、ｉ）トランザクションを受け取るノードによって検証され、トランザクションが有効である場合には、そのノードがそれをネットワーク内の他のノードへ中継すること；及びｉｉ）マイナーによって構築された新しいブロックに追加されること；及びｉｉｉ）採掘されること、即ち、過去のトランザクションの公の台帳に追加されることを要する。トランザクションを事実上不可逆的にする程度に十分な数のブロックがブロックチェーンに追加されると、トランザクションは合意されたと考えられる。

ビットコインを含むブロックチェーン・プロトコル内でのスケーラビリティは、暗号通貨コミュニティの中で多くの議論の的となっている。どのようにしてスケーリングを可能にするかという問題は、様々な技術的課題を提起する。例えば、ブロックチェーン・ネットワークは、台帳に対する全ての状態変更が全ての参加者にブロードキャストされる「ゴシップ・プロトコル」により動作し、状態についてのコンセンサスはゴシップ・プロトコルに基づいて合意されるので、ブロックチェーン・ネットワーク内の全てのノードは、グローバルに発生する全てのトランザクションについて知っていなければならない。トランザクションのこのグローバルな追跡は、少なくともいくつかのブロックチェーン・ネットワークにおけるトランザクションの量又は頻度を制限する可能性がある。例えば、本件執筆時点で実現されているように、ビットコインはＶｉｓａ（登録商標）等の既存の大容量電子決済システムと直接的に置き換わることはできない可能性が高い。実際、ビットコインでＶｉｓａ（登録商標）トランザクションを実行することは、年間４００テラバイトのデータを消費することになると予想されている。既存のブロックチェーン・ネットワークの多くのノードは、この量の帯域幅及びストレージを取り扱うことはできない。

より多くの取引量を収容するために、「支払チャネル（ｐａｙｍｅｎｔ ｃｈａｎｎｅｌｓ）」として知られるオフ・チェーン（即ち、オフ・ブロックチェーン）が提案されている。例えば、「ライティング・ネットワーク（Ｌｉｇｈｔｉｎｇ Ｎｅｔｗｏｒｋ）」と呼ばれるオフ・チェーン支払チャネルは、Ｐｏｏｎ ａｎｄ Ｄｒｙｊａによる「Ｔｈｅ Ｂｉｔｃｏｉｎ Ｌｉｇｈｔｉｎｇ Ｎｅｔｗｏｒｋ：Ｓｃａｌａｂｌｅ Ｏｆｆ−Ｃｈａｉｎ Ｉｎｓｔａｎｔ Ｐａｙｍｅｎｔｓ」（２０１６年１月１４日）において記述されている。ライティング・ネットワークによれば、価値の取引がオフ・ブロックチェーンで生じる。ライティング・ネットワークは、支払チャネルが開設された後に特定の非協力的又は敵対的な行動が生じた場合、オフ・チェーンで以前に交換されたコミットメント・トランザクションがブロックチェーンへブロードキャストされ得る技術を説明している。ライティング・ネットワークは、支払チャネルの現在の状態を反映しない古くなったコミットメント・トランザクションをブロードキャストする参加者のインセンティブを取り除くセーフガードを含む。例えば、支払チャネルの状態を更新するために（例えば、ある参加者から別の者へ価値を移すために）新たなコミットメント・トランザクションが交換される場合、以前のコミットメント・トランザクションに関連付けられるシークレット値が、ある当事者から別の者へ共有される。この値は違反救済トランザクション（ａ ｂｒｅａｃｈ ｒｅｍｅｄｙ ｔｒａｎｓａｃｔｉｏｎ：ＢＲＴ）で使用されてもよい。より詳細には、参加者ノードは、別のノードが古くなったコミットメント・トランザクションをブロードキャストし、古くなったコミットメント・トランザクションで反映される残高をブロックチェーンに約束させようとしていることを検出した場合、参加者ノードはむしろ支払チャネルで全てのディジタル資産を請求するためにその価値を使用し得る。この違反救済方式の下では、コミットメント・トランザクションはロックされ、そのため、コミットメント・トランザクションに対する署名を生成した者（典型的には、ブロックチェーン・ネットワークへコミットメント・トランザクションをブロードキャストする者）は、コミットメント・トランザクションに関連付けられるディジタル資産が使用され得る前に、待機するように要求される。例えば、その当事者は、ディジタル資産を消費することを試みる彼らのトランザクションがブロックチェーンに追加される前に、コミットメント・トランザクションをブロードキャストした後に１０００個のブロックを待機するように要求され得る。この待機する期間は、コミットメント・トランザクションが支払チャネルの現在の状態を反映しない場合に、相手方が違反救済トランザクションを発行することを許容する。

支払チャネルは典型的には、支払チャネルの参加者は価値（又はバリュー）をオフ・チェーンで移すことが可能であるが、彼らが支払チャネルを離れることを希望する場合にはそのような移転をブロックチェーン・ネットワークへ転送することが可能であるように構成される。これは、例えば、ハブ（彼らはそのハブとの支払チャネルを有している）が応答しなくなった場合に生じる。しかしながら、非常に多数の支払チャネルが不具合に陥った場合、ブロックチェーン・ネットワークは、ブロックチェーンに書き込まれるように急に要求された多数のトランザクションを処理するキャパシティを有していないかもしれない。例えば、Ｖｉｓａ（登録商標）ネットワークに匹敵するサイズのハブが不具合に陥った場合、ブロックチェーン・ネットワークは、ブロックチェーン・ネットワークへ急にブロードキャストされる全てのトランザクションを効果的に処理するができないかもしれない。従って、ネットワークで不具合が生じた際にやり取りを処理する能力及びネットワーク回復力（ｎｅｔｗｏｒｋ ｒｅｓｉｌｉｅｎｃｅ）に関連する深刻な技術的問題が存在する。

例えば、ノードが、古くなったコミットメント・トランザクション（即ち、コミットメント・トランザクションは支払チャネルの現在の状態を反映していない）を、そのような不具合の最中にブロックチェーン・ネットワークへブロードキャストした場合、不具合から生じるトランザクションのボトルネックに起因して、古くなったコミットメント・トランザクションが違反救済トランザクションの対象とされることを防ぐほど十分急速に、違反救済トランザクションはブロックチェーン・ネットワークに加えられないかもしれない。従って、支払チャネルは広範囲にわたる不具合の間の攻撃に対して脆弱である可能性がある。

従って電子取引のために当事者間に設定されているリンク又はチャネルを設定するための改善されたセキュリティ技術に対するニーズが存在する。

従って本発明によれば添付の特許請求の範囲に規定されるような方法が提供される。本発明はセキュリティ方法／システムと言及されてもよい。本発明は暗号化されたセキュリティ方法と言及されてもよい。本発明はノード不具合の際にブロックチェーン・ネットワークにおいて回復力を提供することができる。本発明はそのような状況における利己的利用の可能性を防止する又は少なくとも減らすことができる。

以下により詳細に記載されるように、オフ・チェーン転送のチャネルを設定するための技術が説明される。

より詳細には、チャネルのセットアップ中にコングレス又は議会（ａ ｃｏｎｇｒｅｓｓ）が使用される。コングレスは、コングレスに関連するディジタル資産のプール（「コングレス・プール」）に十分なステーク（「メンバ・デポジット」）を提出することにより、ブロックチェーン・ネットワーク内の任意のノードが参加できるノードのグループである。例えば、ノードは、ディジタル通貨（ビットコイン等）、トークン、又はその他のステーク（ｓｔａｋｅ）若しくは価値等のディジタル資産を、コングレスに関するアカウントへ移すことによって、コングレスに参加することができる。コングレスは、部分的には、プライベート・キー・シェアの分散生成を通じて保全され得る。各プライベート・キー・シェアは、トランザクションの部分署名を生成するために、その所有者によって使用され得る。閾値署名方式は、少なくとも閾値数の部分署名を使用して、そのようなトランザクションに関する有効な署名を生成するために使用され得る。メンバ・デポジットは、悪質な行為のために没収される。

有利なことに、コングレスのノードはフェイルセーフ・モードを実現するように構成されてもよく、そのモードではハブが所定のプロトコルに従って動作することを止めた場合に、そのようなノードが（支払）チャネルを閉鎖することができる。例えば、ハブが応答しなくなった場合、コングレスのノードは、チャネルを閉鎖しようとするトランザクションでブロックチェーン・ネットワークが圧倒されるようになるリスクを減らす方法で、支払チャネルを閉鎖するフェイルセーフ・プロトコルを実施することができる。例えば、コングレスは複数の支払チャネルが単独のトランザクションで閉鎖されるバッチ閉鎖を実行してもよい。更に、コングレスは少なくとも幾つかのチャネル閉鎖が遅延させられるように閉鎖することをずらしてもよい。

従って本発明によればコンピュータで実装される方法が提供され得る。コンピュータ実装方法は：エンクレーブ・パブリック・キーを、ノードにおける信頼される実行環境（ａ ｔｒｕｓｔｅｄ ｅｘｅｃｕｔｉｏｎ ｅｎｖｉｒｏｎｍｅｎｔ）に関連するエンクレーブ（ａｎ ｅｎｃｌａｖｅ）から、ハブに提供するステップ；第１パブリック・キー、第２パブリック・キー、及び第３パブリック・キーでディジタル資産を制限するファンディング・トランザクションをブロックチェーン・ネットワークへブロードキャストすることにより、ハブとのチャネルを設定するステップであって、ディジタル資産の制限（ｔｈｅ ｅｎｃｕｍｂｒａｎｃｅ）は：１）第１パブリック・キーに対応する第１プライベート・キーから生成される第１署名及び第２パブリック・キーに対応する第２プライベート・キーから生成される第２署名の双方；又は２）第３パブリック・キーに対して有効な第３署名により解除され、第３パブリック・キーはグループに関連付けられている、ステップ；エンクレーブにおいてコミットメント・トランザクションをハブから受信するステップであって、コミットメント・トランザクションはエンクレーブ・パブリック・キーで暗号化されている、ステップ；ハブの不具合を検出するステップ；及びエンクレーブからのデータであってコミットメント・トランザクションに基づくデータを利用してグループに対してフェイルセーフ活性化リクエストを発行するステップを含む。

チャネルは、「交換チャネル」、「通信チャネル」又は「支払チャネル」のように称されてもよい。参照の便宜上、「支払チャネル」という用語が使用され得る。

幾つかの実装において、フェイルセーフ活性化リクエストは、ブロックチェーン・ネットワークのブロックチェーンに最近追加されたブロックのブロック番号を指定し、グループは、フェイルセーフ活性化リクエストで指定されるブロック番号に基づいて、及びブロックチェーンに最近追加されたブロックの現在のブロック番号に基づいて、満了したと判断されるフェイルセーフ活性化リクエストを無視するように構成される。

幾つかの実装において、方法は更に：フェイルセーフ・モードは実行されていないこと、及びフェイルセーフ活性化リクエストは満了していることを決定するステップ；及び別のフェイルセーフ活性化リクエストをグループに対して発行するステップであって、別のフェイルセーフ活性化リクエストはブロックチェーンに追加された新しい最近のブロックの新しいブロック番号を含む、ステップを含む。

幾つかの実装において、フェイルセーフ活性化リクエストを発行するステップは、ハブの不具合を検出したことに応答して、フェイルセーフ活性化リクエストをオンラインで自動的に投稿するステップを含む。

幾つかの実装において、フェイルセーフ活性化リクエストはチャネルを閉鎖するノードにより提供される手数料を指定する。

幾つかの実装において、方法は、フェイルセーフ活性化リクエストに応じてグループがサイドチェーンを配備した後、サイドチェーンにより他ノードと価値を交換するステップを含む。

幾つかの実装において、フェイルセーフ活性化リクエストはエンクレーブ内で生成され、エンクレーブ・パブリック・キーに関連するエンクレーブ・プライベート・キーを利用して署名される。

幾つかの実装において、方法は更に、コミットメント・トランザクションを解読し、チャネルに関連する残高を決定し、違反救済トランザクションに関連する価値を決定するステップを含む。価値は以前のコミットメント・トランザクションに関連する以前のシークレット値である。

幾つかの実装において、方法は更に、フェイルセーフ活性化リクエストに応答して配備されたサイドチェーンのマイナーにサイドチェーン・トランザクションをブロードキャストするステップを含み、サイドチェーン・トランザクションは価値を移転する。

本発明によれば、コンピュータで実現される方法が提供され得る。コンピュータで実現される方法は：ハブとの１つ以上のチャネルに参加している１つ以上のノードにより発行された１つ以上のフェイルセーフ活性化リクエストを検出するステップであって、チャネルは、ブロックチェーン・ネットワークに関連する価値の取引のためのコミットメントがブロックチェーン・ネットワークの外部でやり取りされることを許容し、フェイルセーフ活性化リクエストは、グループに関連するパブリック・キーでディジタル資産を制限するファンディング・トランザクションをブロードキャストすることにより以前にチャネルを開設したノードにより発行されている、ステップ；１つ以上のフェイルセーフ活性化リクエストが所定の基準を満足することを確認するステップ；及び１つ以上のチャネルを閉鎖するトランザクションに対する有効な署名を、グループの他のノードと協力して生成するステップを有する。

上述したように、チャネルは支払チャネル、交換チャネル、又は通信チャネルと呼ばれてもよい。参照の簡便化のため、以後「支払チャネル」という用語を使用する。

幾つかの実装において、フェイルセーフ活性化リクエストが所定の基準を満足することを確認するステップは、そのようなリクエストを発行する個々のノードの残高により重み付けされたフェイルセーフ活性化リクエストの数が閾値を超えていることを確認するステップを含む。

幾つかの実装において、フェイルセーフ活性化リクエストは、各々のフェイルセーフ活性化リクエストが生成されたときにブロックチェーン・ネットワークのブロックチェーンに最近追加されたブロックの個々のブロック番号を指定し、グループは、フェイルセーフ活性化リクエストで指定されるブロック番号に基づいて、及びブロックチェーンに最近追加されたブロックの現在のブロック番号に基づいて、満了したと判断されるフェイルセーフ活性化リクエストを無視するように構成される。

幾つかの実装において、方法は、１つ以上のフェイルセーフ活性化リクエストが所定の基準を満足していることを確認した後であって有効な署名を協力して生成する前に、一時的にサイドチェーンを配備するステップを更に含む。一時的なサイドチェーンは、価値が更に移転されることを許容する。１つ以上のチャネルを閉鎖するトランザクションはまた、サイドチェーンで転送される価値に基づいていてもよい。

幾つかの実装において、プロセッサは信頼される実行環境を含み、コンピュータ実行可能命令は信頼される実行環境の中で実行される。

本発明によれば、電子デバイスが提供され得る。電子デバイスは、インターフェース・デバイスと、インターフェース・デバイスに結合されるプロセッサと、プロセッサに結合されるメモリとを含む。メモリはコンピュータ実行可能命令を保存し、その命令は、実行されると、本明細書で説明される方法を実行するようにプロセッサを構築する。

本発明によれば、コンピュータ読み取り可能な記憶媒体が提供され得る。コンピュータ読み取り可能な記憶媒体はコンピュータ実行可能命令を含み、その命令は実行されると、本明細書で説明される方法を実行するようにプロセッサを構築する。

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

図１は例示的なブロックチェーン・ネットワークのブロック図を示す。

図２は、ブロックチェーン・ネットワーク内のノードとして機能し得る例示的な電子デバイスのブロック図を示す。

図３は、フェイルセーフ活性化リクエストを発行する例示的な方法のフローチャートである。

図４は、コングレスへ参加する例示的な方法のフローチャートである。

図５は、ディジタル資産を没収する例示的な方法のフローチャートである。

図６は、キー・シェアを再配分する例示的な方法のフローチャートである。

図７は、キー・シェアを再配分する例示的な別の方法のフローチャートである。

図８は、デポジットを戻す例示的な方法のフローチャートである。

図９は、支払チャネルに関するフェイルセーフ・モードを実施する例示的な方法のフローチャートである。 図１０は、ゴースト・チェーン（ａ ｇｈｏｓｔ ｃｈａｉｎ）のブロック図である。

ブロックチェーン・ネットワーク
まず、ブロックチェーンに関連する例示的なブロックチェーン・ネットワーク１００をブロック図の形で示す図１を参照する。ブロックチェーン・ネットワークは、パブリック・ブロックチェーン・ネットワークであってもよく、それは、誰でも、招待されることなく、又は他のメンバからの同意なしに、参加することができるピア・ツー・ピアのオープン・メンバーシップ・ネットワークであってよい。ブロックチェーン・ネットワーク１００が動作する基礎となるブロックチェーン・プロトコルのインスタンスを実行する分散電子デバイスは、ブロックチェーン・ネットワーク１００に参加することができる。そのような分散電子デバイスはノード１０２として言及され得る。ブロックチェーン・プロトコルは例えばビットコイン・プロトコルであってもよい。

ブロックチェーン・プロトコルを実行し、ブロックチェーン・ネットワーク１００のノード１０２を形成する電子デバイスは、例えば、デスクトップ・コンピュータ、ラップトップ・コンピュータ、タブレット・コンピュータ、サーバ、スマートフォンのようなモバイル・デバイス、スマート・ウォッチのようなウェアラブル・コンピュータ、又は他の電子デバイスのようなコンピュータを含む種々のタイプのものであってよい。

ブロックチェーン・ネットワーク１００のノード１０２は、有線及び無線通信技術を含み得る適切な通信技術を使用して互いに結合される。このような通信は、ブロックチェーン・ネットワークに関連するプロトコルを遵守する。例えば、ブロックチェーンがビットコイン・ブロックチェーンである場合、ビットコイン・プロトコルが使用されてもよい。

ノード１０２は、ブロックチェーン上の全てのトランザクションのグローバルな台帳を維持する。従ってグローバル台帳は分散された台帳である。各ノード１０２は、グローバル台帳の完全なコピー又は部分的なコピーを記憶することができる。プルーフ・オブ・ワークによって保証されるブロックチェーンの場合、グローバル台帳に影響するノード１０２によるトランザクションは、グローバル台帳の有効性が維持されるように、他のノード１０２によって検証される。ブロックチェーンがプルーフ・オブ・ワークに基づくブロックチェーンである場合、ブロックはまた、ブロックとともに提出されるプルーフ・オブ・ワークを検査することによって検証される。

少なくとも一部のノード１０２は、ブロックチェーン・ネットワーク１００のマイナー１０４として動作する。図１のブロックチェーン・ネットワーク１００は、ブロックチェーンでのトランザクションを促進にするために、マイナー１０４が費用のかかる計算を実行するプルーフ・オブ・ワーク・ブロックチェーンであってもよい。例えば、プルーフ・オブ・ワーク・ブロックチェーンは、暗号の問題を解くことをマイナーに要求することができる。ビットコインでは、マイナー１０４は、ブロックヘッダが、ＳＨＡ−２５６により、現在の難易度によって定義される値よりも小さな数字にハッシュするようなナンスを発見する。プルーフ・オブ・ワーク・アルゴリズムに必要なハッシュ・パワーは、トランザクションの上に所定数のブロックが採掘された後に、トランザクションは事実上不可逆であると考えられることを意味する。暗号問題を解くマイナー１０４は、ブロックチェーンのための新しいブロックを作成し、その新しいブロックを他のノード１０２にブロードキャストする。他のノード１０２は、マイナー１０４が実際に暗号問題を解いており、従ってブロックがブロックチェーンに追加されるべきであることを受け入れる前に、十分なプルーフ・オブ・ワークを示したことを検証する。ブロックは、ノード１０２のコンセンサスによってブロックチェーン（即ち、分散グローバル台帳）に追加される。

プルーフ・オブ・ワークに代わるものとして、ブロックチェーン・ネットワーク１００は、その代わりにプルーフ・オブ・ステーク・ブロックチェーン・ネットワークであってもよい。プルーフ・オブ・ステーク・ブロックチェーン・ネットワークは、コンセンサスを達成するための代替メカニズムを提供する。プルーフ・オブ・ステーク・ブロックチェーン・ネットワークでは、ブロックチェーンはプルーフ・オブ・ワークではなく持分証明（ｐｒｏｏｆ−ｏｆ−ｓｔａｋｅ）によって保全される。プルーフ・オブ・ステークの下では、マイナーはディジタル資産のセキュリティ・デポジット（保証金）を預託し、ブロックを採掘するノードとして選ばれる確率は、セキュリティ・デポジットとして提供されるディジタル資産の量に比例する。プルーフ・オブ・ステーク・ブロックチェーン・システムは、プルーフ・オブ・ワーク・ブロックチェーンで採掘するのに必要な計算費用とエネルギーを回避するために使用されることができる。更に、プルーフ・オブ・ステーク・ブロックチェーンは、プルーフ・オブ・ワーク・ブロックチェーンよりも、より高頻度で、より規則的なブロック作成を可能にし得る。

マイナー１０４によって作成されたブロックは、ノード１０２によってブロックチェーンにブロードキャストされていたトランザクションを含む。例えば、ブロックは、ノード１０２のうちの一方に関連付けられたアドレスからノード１０２のうちの他方に関連付けられたアドレスへのトランザクションを含んでもよい。このようにして、ブロックはあるアドレスから別のアドレスへのトランザクションのレコードとして機能する。トランザクションをブロックに含められることを要求した者は、彼らのパブリック・キーに対応するプライベート・キーを使用してリクエストに署名することによって、トランスファを開始するために（例えば、ビットコインの場合は、ビットコインを使用するために）それらが承認されることを証明する。トランスファは、リクエストが有効に署名されている場合に限り、ブロックに追加されることができる。

ビットコインの場合、パブリック・キーとアドレスとの間に１対１の対応が存在する。即ち、各々のパブリック・キーは、単一のアドレスに関連付けられる。従って、本明細書において、パブリック・キー宛てに又はそこからディジタル資産を移すこと（例えば、パブリック・キーへの支払）及びそのパブリック・キーに関連するアドレス宛てに又はそこからディジタル資産を移すことは、共通のオペレーションを指す。

ブロックチェーン・ネットワーク内の幾つかのノード１０２はマイナーとしては動作せず、その代わりに検証ノードとして参加することができる。トランザクションの検証は、署名の確認、有効なＵＴＸＯへの参照の確認などを含み得る。

図１の例は５つのノード１０２を含み、そのうちの２つはマイナー１０４として参加している。実際には、ノード１０２又はマイナー１０４の数は様々であってよい。多くのブロックチェーン・ネットワークにおいて、ノード１０２及びマイナー１０４の数は、図１に示される数よりもはるかに大きくなり得る。

以下に説明するように、種々のノード１０２は協働して、本明細書でコングレス又は議会（ａ ｃｏｎｇｒｅｓｓ）１１０と呼ばれるグループを形成することができる。図示の例では、３つのノード１０２がコングレス１１０に参加しているように示されている。しかしながら、実際のコングレス１１０のメンバ数は非常に多くなり得る。

コングレス１１０は、オープン・メンバーシップ・グループであってもよく、これは、コングレス１１０に関連するプールへの十分なステークの投入によって、任意のノード１０２が参加し得る。例えば、ノードは、ディジタル通貨（例えば、ビットコイン）、トークン又はその他のステーク若しくは価値のようなディジタル資産を、コングレス１１０に関連するアカウントへ（例えば、グループ・パブリック・アドレス又はグループ・パブリック・キーへ）移すことによって、コングレスに参加することができる。コングレスに参加するノード１０２は、マイニング・ノードと非マイニング・ノードの両方を含むブロックチェーン・ネットワーク内の任意のノードであってもよい。

コングレス１１０は、ノード間のオフ・ブロックチェーン支払チャネル１２０ａ，１２０ｂのセットアップを促進にするために使用されることができる。このオフ・ブロックチェーン支払チャネルは、本明細書では、オフ・チェーン支払チャネル、オフ・チェーン・チャネル、又は支払チャネルと呼ばれてもよい。支払チャネルは、ブロックチェーンから外れた価値の交換を許容する。支払チャネルは、支払チャネルのチャネル状態（即ち、支払チャネルに関与する個々のノードの差引勘定）が何時でもブロックチェーンに対してコミットされることを許容する。即ち、当事者は、複数のオフ・ブロックチェーン・トランザクションにおいて価値を移転することができ、また、ある時点で支払チャネルの現在のチャネル状態を反映するようにブロックチェーンを更新することができる。

実施例では、第１支払チャネル１２０ａは、第１ノード１０２ａ及び第２ノード１０２ｂの２つのノードの間に設定され、第２支払チャネル１２０ｂは、第１ノード１０２ａ及び第３ノード１０２ｃの２つのノードの間に設定される。しかしながら実際にはノード間に支払チャネルが設定されてもよいし、異なる数の支払チャネルが設定されてもよい。支払チャネル１２０ａ、１２０ｂはハブ・アンド・スポーク（ＨＡＳ）構成で設定されてもよく、ＨＡＳ構成では、中央ハブ（例えば、この例では第１ノード１０２ａ）が第２ノード１０２ｂ及び第３ノードの両方と共に支払チャネルを確立する。このＨＡＳ構成は、ハブに接続された任意のノードが、そのハブに接続された任意の他のノードにバリュー・オフ・チェーンを転送するか、又はハブに接続された任意の他のノードからバリュー・オフ・チェーンを受けることを可能にする。例えば、第２ノード１０２ｂは、価値を第３ノード１０２ｃへオフ・チェーンで移したり、第３ノードから価値を受信したりすることができる。ハブは図１に示されるものより多数のノードに接続されてもよい。更に、１つの支払チャネルに関連するハブ又はハブでないノードは、他のハブ又はハブでないノードとの他の支払チャネルを設定することができる。

支払チャネルのセットアップの間に、支払チャネル１２０に関連するノード（例えば、図示の例では、第１支払チャネル１２０ａの場合は第１ノード１０２ａ及び第２ノード１０２ｂ、第２支払チャネル１２０ｂの場合は第１ノード１０２ａ及び第３ノード１０２ｃ）はそれぞれ、支払チャネルに資金提供するような特別な方法でディジタル資産をロックする。セットアップが完了した後、これらのディジタル資産は、以前のコミットメント・トランザクションを効果的に無効にするコミットメント・トランザクション及び「価値」の交換を使用して割り振られてもよい。より具体的には、支払チャネルは、支払チャネルに関連するノードが、コミットメント・トランザクションをやり取りすることを可能にする。コミットメント・トランザクションは、ブロックチェーン・ネットワークに対して（初期）ブロードキャストすることなく、ノードによってやり取りされるトランザクションである。コミットメント・トランザクションは、支払チャネルに関連するディジタル資産の配分を決定する台帳を提供する。この割り振りはチャネル状態と呼ばれてもよい。コミットメント・トランザクションは、支払チャネルに関連する１つのノードによって何時でもブロードキャストされ得る。コミットメント・トランザクションについては次の文献に記載されているように動作し得る：Ｐｏｏｎ ａｎｄ Ｄｒｙｊａ ｉｎ “Ｔｈｅ Ｂｉｔｃｏｉｎ Ｌｉｇｈｔｎｉｎｇ Ｎｅｔｗｏｒｋ： Ｓｃａｌａｂｌｅ Ｏｆｆ−Ｃｈａｉｎ Ｉｎｓｔａｎｔ Ｐａｙｍｅｎｔｓ”， Ｊａｎｕａｒｙ １４， ２０１６ （ｈｅｒｅｉｎａｆｔｅｒ “ｔｈｅ Ｌｉｇｈｔｎｉｎｇ Ｎｅｔｗｏｒｋ”）。しかしながら支払チャネルはライティング・ネットワークで述べられているものとは異なる方法で設定されてもよい。より詳細には、本明細書においてコングレスと称されるノードのグループは、支払チャネルが故障した場合にノードのグループが支援することを許容するセットアップ・プロトコルに関わっていてもよい。そのような不具合は例えばハブの不具合に起因して生じ得る。フェイルセーフ・モードを実施するためにコングレス及びプロトコルにより提供されるフェイルセーフ・モードを含む支払チャネルを設定するプロトコルは、以下において更に詳細に説明される。

ノードとして動作する電子デバイス
図２は、ピア・ツー・ピア・ブロックチェーン・ネットワーク１００（図１）のノード１０２（図１）として機能し得る例示的な電子デバイス２００の構成要素を示すブロック図である。例示的な電子デバイス２００は、処理デバイスとも呼ばれる。電子デバイスは、例えば、デスクトップ・コンピュータ、ラップトップ・コンピュータ、タブレット・コンピュータ、サーバ、スマートフォンのようなモバイル・デバイス、スマート・ウォッチのようなウェアラブル・コンピュータ、又は他のタイプの形態を含む様々な形態をとることができる。

電子デバイス２００は、プロセッサ２１０、メモリ２２０及びインターフェース・デバイス２３０を含む。これらの構成要素は、互いに直接的又は間接的に結合されることが可能であり、互いに通信することができる。例えば、プロセッサ２１０、メモリ２２０及びインターフェース・デバイス２３０は、バス２４０を介して互いに通信することができる。メモリ２２０は、本明細書に記載の機能を実行するための機械読取可能な命令及びデータを含むコンピュータ・ソフトウェア・プログラムを格納する。例えば、メモリは、プロセッサ２１０によって実行されると、本明細書に記載の方法を電子デバイスに実行させるプロセッサ実行可能命令を含み得る。プロセッサ実行可能命令は、プロセッサ２１０によって実行されると、ブロックチェーン・ネットワーク１００（図１）に関連するプロトコルを電子デバイスに実行させる命令を含み得る。例えば、命令は、ビットコイン・プロトコルを実装するための命令を含んでいてもよい。

メモリ２２０は、ブロックチェーン・ネットワーク１００（図１）のグローバル台帳又はその一部を格納することができる。即ち、メモリ２２０は、ブロックチェーンの全てのブロック又はブロックの一部、例えば最新のブロック、又は情報の一部を幾つかのブロックに格納することができる。

メモリ２２０は、図２において単一ブロックで示されているが、実際には電子デバイス２００は複数のメモリ構成要素を含んでいてもよい。メモリ・コンポーネントは、例えば、ＲＡＭ、ＨＤＤ、ＳＳＤ、フラッシュ・ドライブ等を含む種々のタイプのものであってもよい。異なるタイプのメモリが、異なる目的に適しているかもしれない。更に、メモリ２２０はプロセッサ２１０から離れて示されているが、プロセッサ２１０は内蔵メモリを含んでもよい。

図２に示すように、（例えば、コングレス１１０を形成するノード、及び／又は本明細書に記載されるようなフェイルセーフ・モードを提供する支払チャネルに参加するノード等の）幾つかのノード１０２のプロセッサ２１０は、信頼される実行環境（ＴＥＥ）２５０のようなセキュア領域を含んでもよい。ＴＥＥ２５０は、隔離された実行環境であり、電子デバイス２００に対して、隔離された実行、信頼されるアプリケーションの完全性、及び資産の機密性のような追加のセキュリティを提供する。ＴＥＥ２５０は、ＴＥＥ２５０内にロードされたコンピュータ命令及びデータが機密性及び完全性の観点から保護されることを保証する実行空間を提供する。ＴＥＥ２５０は、鍵などの重要なリソースの完全性及び機密性を保護するために使用されてもよい。ＴＥＥ２５０は少なくとも部分的にハードウェア・レベルで実現され、その結果、ＴＥＥ２５０内で実行される命令及びデータは、電子デバイス２００の残りの部分及び電子デバイスの所有者などの外部の者からのアクセス及び操作から保護される。ＴＥＥ２５０内のデータ及び計算は、ＴＥＥ２５０を含むノード１０２を動作させる者から保護される。

ＴＥＥ２５０は、累積的にハッシュしながら、エンクレーブ（ａｎ ｅｎｃｌａｖｅ）をインスタンス化し、そして一度に一つメモリのページを追加するように動作し得る。また、リモート・マシンが、期待されるハッシュを決定及び格納するように、同様のオペレーションが、リモート・マシン（デベロッパ・マシン又は他のマシンであってもよい）上で実行されてもよい。従って、エンクレーブの内容は、エンクレーブが承認済みアルゴリズムを実行していることを保証するために、任意のリモート・マシンによって検証されることが可能である。この検証は、ハッシュを比較することによって実行されてもよい。エンクレーブが完全に構築される場合、それはロックダウンされる。ＴＥＥ２５０でコードを実行し、コードにシークレット（ｓｅｃｒｅｔｓ）を送信することは可能であるが、コードは変更され得ない。最後のハッシュは、認証鍵によって署名され、データ所有者が何らかのシークレットをエンクレーブに送信する前に、データ所有者がそれを確認できるようにされ得る。

コングレス・メンバとして機能するノードによって使用されるＴＥＥ２５０は、コングレス１１０（図１）によって使用されるコングレス・パブリック・キーに関連するプライベート・キー・シェアの機密性及び完全性を保護するために使用され得る。例えば、ＴＥＥ２５０は、プライベート・キー・シェアの生成及び記憶のために使用されてもよい。ＴＥＥ２５０は、ＴＥＥ２５０エンクレーブ内で保持されるプライベート・キー・シェア、又は他のプライベート・キー・シェアに関する情報を、どのメンバも、メンバ間通信又はエンクレーブ間通信から直接的に取得できないことを保証するように意図されている。コングレス・プロトコルもまたＴＥＥの閾値の妥協に対してロバストである。更に、ＴＥＥ２５０は、ノード１０２（図１）によって使用され得るリモート認証（ｒｅｍｏｔｅ ａｔｔｅｓｔａｔｉｏｎ）を可能にし、ＴＥＥ２５０が真正であり且つコングレス１１０又は支払チャネルによって実現されるプロトコルに関して承認されたコンピュータ実行可能命令を実行していることを、他のノード１０２に証明することができる。リモート認証は、特定のコード部分を実行し、エンクレーブにとって内的に、エンクレーブの内部認証キー（本明細書では、エンクレーブ・プライベート・キーと言及されてもよい）によって署名される、コードのハッシュを送ることによってＴＥＥ２５０によって提供されてもよい。

コングレス・メンバとして機能するノードで提供されるＴＥＥ２５０は、以前に電子デバイス２００上でプライベート・キー・シェアを使用したコングレス１１０のメンバがコングレスを離れることを選択した場合に、プライベート・キー・シェアの削除を保証することを証明するために使用され得る。電子デバイス２００は、ＴＥＥ２５０において提供されるリモート認証プロトコルにより、他のコングレス・メンバに削除の認証を提供することができる。メンバが彼らのメンバ・デポジットを引き出すことを許される前に、抹消の証明が必要とされてもよい。即ち、預託金の返還は、メンバのエンクレーブ内で保持されるプライベート・キー・シェアの削除に対する認証を条件とすることができる。

ハブとの支払チャネル１２０ａ，１２０ｂ（図１）に参加するノードで提供されるＴＥＥ２５０は、既存の承認されたコードをノードが実行していることを（例えば、遠隔証明により）ハブが確認することを許容するために使用され得る。更に、ＴＥＥ２５０のエンクレーブは、ハブに提供され得るエンクレーブ・パブリック・キーに関連付けられるエンクレーブ・プライベート・キーを格納する。ハブはエンクレーブへ暗号化されたメッセージを送信するためにエンクレーブ・パブリック・キーを使用し得る。これらの暗号化されたメッセージは、１つ以上のコミットメント・トランザクション、違反救済トランザクション（ａ ｂｒｅａｃｈ ｒｅｍｅｄｙ ｔｒａｎｓａｃｔｉｏｎ：ＢＲＴ）で使用され得る１つ以上の値を含み得る。即ち、その値は古くなったチャネル状態を効果的に無効にする。コミットメント・トランザクション及び価値はエンクレーブによって解読され、他のコンポーネント、システム、又はノードのサブシステム（ノードのメイン・プロセッサ等）に提供されてもよい。ＴＥＥ、より具体的にはＴＥＥ２５０のエンクレーブはまた、万一支払チャネル・ハブが応答しなくなった場合に、フェイルセーフ活性化リクエストを生成するために使用されてもよい。以下で更に詳細に説明されるように、フェイルセーフ活性化リクエストは、エンクレーブに保存されるデータに少なくとも部分的に基づいて生成されてもよい。例えば、フェイルセーフ活性化リクエストは、最新のチャネル状態（支払チャネルにおけるディジタル資産の現在の残高を反映している）に基づいて生成されてもよい。フェイルセーフ活性化リクエストはまた、他の情報、例えばブロックチェーン・ネットワークのブロックチェーンに追加された最新のブロック、及びチャネルを閉鎖する見返りにコングレスに提供される手数料のステートメントを含んでもよい。フェイルセーフ活性化リクエストは、それがエンクレーブによって提供されたものとして確認され得るように、エンクレーブ・プライベート・キーを利用してエンクレーブにより署名される。

ＴＥＥ２５０は、プライベート・キー、ランダム・チャレンジ、又は他のランダム・データを生成するために使用され得る、ＴＥＥのエンクレーブにとって内的なセキュア乱数発生器を備えることができる。ＴＥＥ２５０はまた、外部メモリからデータを読み込むように構成されてもよく、外部メモリにデータを書き込むように構成されてもよい。そのようなデータはエンクレーブ内でのみ保持されるシークレット・キーで暗号化されてもよい。

ＴＥＥ２５０は、信用されたプラットフォーム・モジュール（Ｔｒｕｓｔｅｄ Ｐｌａｔｆｏｒｍ Ｍｏｄｕｌｅ：ＴＰＭ）又はインテル・ソフトウェア・ガード・エクステンション（Ｉｎｔｅｌ Ｓｏｆｔｗａｒｅ Ｇｕａｒｄ Ｅｘｔｅｎｓｉｏｎｓ：ＳＧＸ）のような様々なプラットフォームを使用して実装されることができる。例えば、ＳＧＸはリモート認証をサポートし、これは、参照（ａ ｑｕｏｔｅ）として知られるメンバの所与のハッシュとともに、特定のエンクレーブを実行しているプロセッサから、署名されたステートメントを、エンクレーブが取得することを可能にする。インテル・アテステーション・サービス（Ｉｎｔｅｌ Ａｔｔｅｓｔａｔｉｏｎ Ｓｅｒｖｉｃｅ：ＩＡＳ）等の第三者認証サービスは、これらの署名済みステートメントがＳＧＸ仕様に準拠した真正なＣＰＵ から派生していることを証明し得る。

コングレス・メンバとして活動するノード、及び支払チャネルにおけるハブでない参加者として活動するノードは、ＴＥＥを含み得るが、ハブとして活動する少なくとも幾つかのノードはＴＥＥ２５０を有しないかもしれない。言い換えれば、支払チャネル・ハブとして活動するノードは、フェイルセーフ・モードで（及びフェイルセーフ・モードにより保護されるために）参加するためにＴＥＥを運営するように要求されない。

電子デバイス２００は、ブロックチェーン・ネットワーク１００（図１）内のノード１０２（図１）として機能する。幾つかのノードはコングレス１１０に参加する或いは一員となってもよい。ディジタル通貨、トークン、又はブロックチェーン・ネットワーク１００（図１）によってサポートされる他の持分若しくは価値のようなディジタル資産を、ディジタル資産保有者グループが共同出資（プール）する場合に、コングレス１１０が形成される。コングレスは、例えば、支払チャネルに関連するフェイルセーフ・モードを実施してもよい。例えば、ハブが故障した場合、コングレスは、フェイルセーフ・モードをトリガし、支払チャネルの順序通りの閉鎖を促進してもよく、及び／又は価値の別のオフ・チェーン転送を促進してもよい（即ち、価値のオフ・メインチェーン転送）。

幾つかのノードは、支払チャネルにおけるハブでない参加者として参加することができる。そのようなノードは、例えば、ハブとの又はハブでない他の参加者との支払チャネルを設定することができる。支払チャネルをセットアップする技術は以下において説明され、ハブ又は支払チャネルが故障した場合にフェイルセーフ・モードを実施する技術も説明される。

他のノードは、ハブでない参加者として参加しなくてもよいし、コングレス・メンバとして行動しなくてもよい。そのようなノードは、その代わりに、１つ以上のマイナー、検証者、ハブとして機能してもよいし、或いはブロックチェーン・ネットワークに関連する他の機能を提供してもよい。

支払チャネルへの参加及びチャネル不具合に対する対応
次に、図３を参照すると、支払チャネルに参加し、チャネル不具合に対応するための方法３００が示されている。方法３００は、ブロックチェーン・ネットワークのノード１０２によって実行されてもよい。このようなノード１０２は、方法３００を実現するメモリ２２０（図２）に記憶されたコンピュータ実行可能命令を含んでもよい。このような命令は、プロセッサ２１０（図２）によって実行されると、（図２を参照して説明したタイプの電子デバイス２００のような）ノード１０２に方法３００を実行させる。

オペレーション３０２において、方法３００を実行するノード、及びより具体的には方法を実行するノード１０２におけるＴＥＥ２５０（図２）に関連するエンクレーブは、支払チャネルに含まれるべきハブへ、エンクレーブ・パブリック・キーを提供する。エンクレーブ・パブリック・キーは、エンクレーブで安全に保存されるエンクレーブ・プライベート・キーに関連付けられるパブリック暗号キーである。エンクレーブ・パブリック・キーは、ハブがエンクレーブと直接的に通信することを許容する。即ち、ハブはエンクレーブに対する通信を暗号化するためにエンクレーブ・パブリック・キーを使用する。

エンクレーブ・パブリック・キーは、方法を実行するノードによりハブへ直接的に提供されてもよいし、或いはオペレーション３０４に関連して以下で参照されるファンディング・トランザクションにメタデータとしてエンクレーブ・パブリック・キーを含めることにより、ハブに提供されてもよい。従ってオペレーション３０２及び３０４は図３のフローチャートでは別々のブロックを使用して示されているが、オペレーション３０２は図３の方法３００のオペレーション３０４の一部分として実行されてもよい。

オペレーション３０４において、方法３００を実行するノードはハブとの支払チャネルを確立する（即ち、セットアップする）。より詳細には、支払チャネルは、第１パブリック・キー、第２パブリック・キー、及び第３パブリック・キーでディジタル資産を制限するファンディング・トランザクションを、ブロックチェーン・ネットワークへブロードキャストすることにより設定されてもよく、それにより、ディジタル資産の制限は、１）第１パブリック・キーに対応する第１プライベート・キーから生成される第１署名と第２パブリック・キーに対応する第２プライベート・キーから生成される第２署名との双方；又は２）第３パブリック・キーに対して有効な第３署名単独により取り除かれてもよい。第３パブリック・キーは、コングレス１１０（図１）のようなグループに関連するパブリック・キーである。例えば、第３パブリック・キーはグループ・パブリック・キー（コングレス・パブリック・キーと言及されてもよい）であってもよい。第１パブリック・キーは方法３００を実行するノードに関連付けられ、第２パブリック・キーは、セットアップされるべき支払チャネルにおける参加者であるハブのような他のノードに関連付けられる。

このように、ファンディング・トランザクションは、支払チャネルの二人の当事者が、ファンディング・トランザクションに関連するディジタル資産に対する制限を相互に取り除くことができるように設定されるか、又は単独に動作するコングレスが制限を取り除くことができる。即ち、ファンディング・トランザクションは、次の２つの方法のうちの１つで制限が除去され得るように設定される。支払チャネルに対する当事者が協力することを希望する場合、彼ら双方がそれぞれのプライベート・キー（即ち、第１パブリック・キー及び第２パブリック・キーに関連付けられるプライベート・キー）を使用して、制限付きのディジタル資産を消費するトランザクションに対する署名を生成する場合、制限は取り除かれる可能性がある。このシナリオの下では、それら有効な署名は一緒になって制限を取り除く。制限が除去され得る第２の方法は、コングレスの複数のメンバが協力して、閾値署名方式に従って有効な署名をコングレスに代わって生成することである。閾値署名方式については、コングレスの詳細な議論において詳細に説明される。一般に、閾値署名方式は、少なくとも閾値数のキー・シェアをコントロールする多数のコングレス・メンバ・ノードの協調を必要とする。コングレスは持分の預託によって保護されているので、彼らがコングレス・プロトコルに反する行為をした場合、コングレスのメンバ・ノードはその持分の没収の危険にさらされる。例えば、コングレス・メンバが、オペレーション３０４のファンディング・トランザクションに関連するディジタル資産を効果的に盗むトランザクションに部分的な署名を寄与した場合、コングレス・メンバは、少なくとも閾値数のキー・シェアをコントロールする誠実なコングレス・メンバによって、彼らのデポジットが取り消されるリスクがある。

オペレーション３０２の説明で上述したように、方法３００のオペレーション３０４でブロードキャストされるファンディング・トランザクションは、方法を実行するノードのＴＥＥに関連するパブリック・キーを、ファンディング・トランザクションのメタデータとして含み得る。例えば、エンクレーブ・パブリック・キーは、ファンディング・トランザクションにおけるメタデータとして指定されてもよい。

支払チャネルを設定した後、方法３００を実行するノードは支払チャネルによりハブに接続され、その支払チャネルは、ハブ・アンド・スポーク支払ネットワークの１つのスポークを形成し、且つ他の「スポーク」によりハブに接続される他のノードと及び必要ならばハブ自身と価値を交換し得る。例えば、ノードは今や、ハブによりトークンを（オペレーション３０６において）転送することにより、オフ・チェーンで他のハブでないノードと価値を移転することができる。より具体的には、以前のコミットメント・トランザクションを無効にする１つ以上の「値」及びコミットメント・トランザクションのハブとの交換により、価値は転送され得る。コミットメント・トランザクションは、暗号化された形式で方法３００を実行するノードのエンクレーブで受信され得る。例えば、受信したコミットメント・トランザクションはエンクレーブ・パブリック・キーで暗号化されていてもよく、それにより、コミットメント・トランザクションはエンクレーブ内で安全なままである。従ってエンクレーブはハブにより送信された全てのコミットメント・トランザクションを見ることができ、従って最新のチャネル状態に常に気付く。エンクレーブはコミットメント・トランザクションを解読し、チャネルに関連する残高を確認し、違反救済トランザクションに関連する価値を確認することができる。この値は以前のコミットメント・トランザクションに関連する以前のシークレット値であり、その値は、（ハブのような）相手方が、古くなったコミットメント・トランザクションをブロックチェーン・ネットワークへブロードキャストすることを試みることにより、プロトコルに違反する場合に、違反救済トランザクションで使用され得る。

コミットメント・トランザクションは、一般に、ライティング・ネットワークで記述された方法で交換することができる。コミットメント・トランザクションは、前のチャネル状態を事実上無効にする値と共に交換することができる。つまり、その値は、より古いコミットメント・トランザクションを事実上利用不可能にする。不誠実な参加者による古い（即ち、現在のものではない）コミットメント・トランザクションをブロードキャストしようとする如何なる試みも賢明でないことを証明し、なぜなら、以前のチャネル状態を無効にする値が正直な参加者によって使用され、（例えば、チャネル内の全ての資金を主張する（ｃｌａｉｍｉｎｇ）ことによって）不正な参加者にペナルティを科すことができるためである。

支払チャネルが意図されるように機能し続ける場合、支払チャネルは、支払チャネルに対する当事者の相互の合意により、いつでも閉鎖されることが可能である。支払チャネルに資金提供するために使用されたファンディング・トランザクションは、支払チャネルの両当事者（例えば、方法３００を実行するノード及びハブ）が、２−ｏｆ−２マルチシグネチャ・プロトコルで協力することにより、ディジタル資産に対する制限を取り除くことができるように構成されていたことを想起されたい。従って、これらのノードは、支払チャネルをクローズし、且つファンディング・トランザクションによって以前に制限されていたディジタル資産を再分配するであろうトランザクションのために、それぞれの署名を生成するように協力することができる。即ち、これらのノードは、必然的にコミットメント・トランザクションに依存する必要なしに、支払チャネルの現在の状態を考慮した方法で資金を簡易に再配分することができる。しかしながら、相手方が非協力的になり、そのようなトランザクションに署名することを拒否する場合、コミットメント・トランザクションが必要とされ得る。

上述したように、支払チャネルは特定の状況で不具合になる場合があり、それはオペレーション３０８で検出され得る。例えば、ハブは故障するかもしれず、そのような不具合はオペレーション３０８でノードにより検出され得る。ハブの不具合は、例えば、チャネルを更新するリクエストに応じて、期待されるコミットメント・トランザクションをエンクレーブに提供することにハブが失敗した場合に、検出され得る。

ハブの不具合を検出したことに応答して、ノードはオペレーション３１０においてフェイルセーフ活性化リクエストをグループ（即ち、第３パブリック・キーに関連するグループ又はコングレス）に対して発行し得る。フェイルセーフ活性化リクエストは、ハブの不具合を検出したことに応答して、オンラインでフェイルセーフ活性化リクエストを自動的に送ることにより、グループに対して発行されてもよい。例えば、フェイルセーフ活性化リクエストは、フェイルセーフ活性化リクエストに関する中央リポジトリとして機能するウェブサーバであって、グループのメンバ・ノードが監視するように構成されているウェブサーバへ提出されてもよい。フェイルセーフ活性化リクエストは、エンクレーブ内で生成され、エンクレーブ・パブリック・キーに関連するエンクレーブ・プライベート・キーを使用して署名され得る。 フェイルセーフ活性化リクエストはエンクレーブからのデータを使用してグループに対して発行される。例えば、フェイルセーフ活性化リクエストを生成するために使用されるデータは、オペレーション３０６の間に受信されるコミットメント・トランザクションに基づいていてもよい。例えば、フェイルセーフ活性化リクエストは現在の状態の署名されたステートメントを含んでいてもよい。支払チャネルの現在の状態は、支払チャネルの残高であり、ステータス、状態又は残高は、支払チャネルに関連する最近のコミットメント・トランザクションが考慮される場合に、ディジタル資産の割り振りを決める。

フェイルセーフ活性化リクエストはまた他の情報を含んでもよい。例えば、フェイルセーフ活性化リクエストは、支払チャネルをクローズにするためにノードにより提供される手数料を指定してもよい。フェイルセーフ活性化リクエストはまた、タイムスタンプ等のフレッシュネス・データを含み得る。タイムスタンプ又はその他のフレッシュネス・データは、フェイルセーフ活性化リクエストがＴＥＥにより生成又は発行された日及び／又は時間を指定することができる。代替的に、タイムスタンプは、ブロックチェーン・ネットワークのブロックチェーンに追加された最新のブロックのブロック番号を指定してもよい。フェイルセーフ活性化リクエストを処理するノードのグループは、タイムスタンプに基づいて、満了したと判断されるフェイルセーフ活性化リクエストを無視するように構成され得る。例えば、タイムスタンプが最新のブロック番号として表現される場合、グループは、フェイルセーフ活性化リクエストで指定されているブロック番号に基づいて、及びブロックチェーンに追加された最新のブロックの現在のブロック番号に基づいて、満了したと判断されるフェイルセーフ活性化リクエストを無視することができる。即ち、グループは、フェイルセーフ活性化リクエストが発行されて以来経過したブロック数に基づいて、フェイルセーフ活性化リクエストの鮮度を評価してもよい。

方法３００を実行するノードは、（オペレーション３１２においてノードにより決定されるように）満了した場合、及びフェイルセーフ・モードが実行されていない場合、及び支払チャネルが暫定的に回復していない場合、（オペレーション３１４において）フェイルセーフ活性化リクエストを再発行するように構成され得る。即ち、グループがフェイルセーフ・モードを実行していない場合であり支払チャネルが実施不可能のままである場合、オペレーション３１４において満了したフェイルセーフ活性化リクエストが再発行されてもよい。より具体的には、別のフェイルセーフ活性化リクエストがグループに対して発行されてもよい。別のフェイルセーフ活性化リクエストは、ブロックチェーンに追加された新しい最新のブロックに対するブロック番号等の新しい鮮度情報を含む。

フェイルセーフ・モードがコングレスにより活性化された後（以下において詳細に説明されるように、十分なフェイルセーフ活性化リクエストを観察したことに応答して）、コングレスは支払チャネルを閉鎖することができる。例えば、コングレスのノードは、オペレーション３０４において制限されるディジタル資産に影響を及ぼすトランザクションに対する署名を生成するように協調することができる。署名は、オペレーション３０４の説明で上述した第３パブリック・キーに対して有効である。即ち、署名はディジタル資産を制限したグループ／コングレス・パブリック・キーに対して有効である。支払チャネルは、ファンディング・トランザクションに含まれる資産に対する管理をコングレスが引き受けることを許容するように設定されていたので、支払チャネルが故障した場合、コングレスはトランザクションをクローズすることを促進することができる。

少なくとも幾つかの例において、閉鎖トランザクションをブロックチェーン・ネットワークへブロードキャストすることにより、チャネルが閉鎖される前に、フェイルセーフ活性化リクエストに応答して（及びより具体的には、フェイルセーフ・モードをトリガする程度に十分な多数のフェイルセーフ活性化リクエストに応答して）、一時的なサイドチェーンが配備されてもよい。一時的なサイドチェーンはゴースト・チェーン（ａ ｇｈｏｓｔ ｃｈａｉｎ）と言及されてもよく、以下において詳細に説明される。一時的なサイドチェーンは、サイドチェーンにより他のノードと価値を交換するために（例えば、移転又は受信するために）、方法３００のオペレーション３１６において、ノードにより使用され得る。例えば、フェイルセーフ活性化リクエストに応答して配備されたサイドチェーンのマイナーへ、サイドチェーン・トランザクションをブロードキャストすることにより、ノードは、価値を他のノードへ移すことができる。サイドチェーン・トランザクションは価値を他のノードへ又は他のノードから移す。即ち、サイドチェーン・トランザクションは、ノードに関連するディジタル資産の残高を効果的に更新する。サイドチェーンは、故障したハブとの支払チャネルを以前に設定した他のノードに関する他の「スポーク」（即ち、他の支払チャネル）を介して、価値を転送する又は価値を受信するために使用され得る。従って、サイドチェーンは、ハブに以前に接続されていたノードが、互いに取引を続けることを許容する一方、クローズされる各自のチャネルをそれらが待機する。チャネルをクローズする別のリクエストはフェイルセーフが活性化された後は要求されなくてもよく；フェイルセーフ活性化リクエストを発行した全てのチャネルは、サイドチェーンが終了すると閉鎖される。

サイドチェーンが配備される場合、メイン・ブロックチェーン（メインチェーンと言及されてもよい）に対する支払チャネルの状態を引き受けるように、ノードは、後にコングレスへリクエストを発行してもよい。コングレスのノードは、次いで、残高に影響する任意のサイドチェーン・トランザクションを説明するトランザクションを閉鎖するために、有効な署名を生成するように協調することができる。従って、（例えば、ハブの故障に起因して）支払チャネルが故障した場合、コングレスのメンバであるノードのグループは、支払チャネルの閉鎖を促進するように協力し得る。コングレス及びコングレスの様々な機能については以下において詳細に説明される。

コングレス及び閾値署名
コングレス１１０は、ブロックチェーン・ネットワークで動作する許可された又は許可されていないノード１０２のグループであってもよい。即ち、コングレス１１０には、ブロックチェーン・ネットワーク１００（図１）内のノード１０２（図１）が（例えば、ブロックチェーン内の情報の少なくとも一部を監視し格納する任意のノードが）加入し得る。コングレス１１０に参加するために、ノード１０２は、コングレス１１０に関連するディジタル資産プールへ（即ち、コングレスの他のメンバに関連する、１つ以上のディジタル資産に関連するパブリック・グループ・アドレスへ）１つ以上のディジタル資産を移す。このディジタル資産プールは、コングレス・プールと言及されてもよい。例えば、ノード１０２は、コングレス・プールに関連するアドレスへ（即ち、パブリック・グループ・アドレスと呼ばれてもよい「コングレス・アドレス」へ）そのようなディジタル資産を転送（即ち、デポジット）することによって、コングレス１１０に参加することができる。ディジタル資産は、コングレス・パブリック・キーと呼ばれる単一のパブリック・キーによるグループ閾値署名の管理下に置かれる。コングレス・メンバは、配布により生成されたプライベート・キー・シェア（即ち、そのようなプライベート・キー・シェアを保持するさまざまなノードで生成されるプライベート・キー・シェア）を保持する。保有されるシェア（持ち分）の数は、プールに預託された額に比例してもよい。

コングレス１１０によって管理されるディジタル資産は、コングレス・アドレスへ（即ち、コングレスに関連するパブリック・キーであるコングレス・パブリック・キーへ）移される如何なるディジタル資産も含み、閾値署名方式の管理下に置かれる。閾値署名方式の下では、メンバ各自の総プライベート・キー持ち分保有量が閾値を超えるメンバー・グループは、ディジタル資産がコングレス１１０の管理から離れて移転されることを可能にする有効な署名を生成するために必要とされる。即ち、コングレス１１０によって管理されるディジタル資産の任意の発信転送に対して有効な署名を生成するために、少なくとも閾値数のプライベート・キー・シェアが使用されなければならない。

コングレス・パブリック・キーは、プライベート・キー・シェアの見返りとしてコングレス１１０のメンバによってコングレス・プールに預けられたディジタル資産、及び、プライベート・キー・シェアを取得すること以外の理由で預けられている（即ち、コングレス・パブリック・キーにより制限される）コングレス１１０のメンバ及び非メンバによってコングレス・プールに関連するアドレスに預けられた任意のディジタル資産（即ち、コングレスの完全な、部分的な又は条件付きの管理下に置かれている）を制限する。非メンバ又はメンバは、様々な理由により、コングレス・パブリック・キーでディジタル資産を制限することができる。例えば、図３を参照して上述したように、支払チャネルのためのファンディング・トランザクションは、コングレス・パブリック・キーを用いてディジタル資産を制限することができる。そのようなディジタル資産（即ち、支払チャネルを開設するために使用されるディジタル資産）をコングレス・パブリック・キーで制限することにより、仮に支払チャネルが故障した場合（例えば、支払チャネルに関連するハブが応答しなくなった場合）、コングレスはフェイルセーフ・モードを実装することができる。

同じコングレス・パブリック・キーが、メンバのデポジット（即ち、プライベート・キーに対する見返りにコングレス・メンバによって提供されるディジタル資産）と、他の目的でメンバ又は非メンバにより提供されるディジタル資産との両方を制限し得るので、コングレス・パブリック・キーに対する少なくとも幾らかのデポジットは、デポジットの種類を示すための特別なフラグで合図されてもよい。例えば、コングレス・アドレスへディジタル資産を移転するトランザクションは、行われたデポジットの性質を示すフラグ、識別子又は他の属性を含むことができる。例えば、コングレスへ参加すること又はコングレス・メンバーシップにおける出資額を増やすことを目的としない、ディジタル資産をコングレス・アドレスへ移すトランザクションは、デポジットが別の目的で行われていることを示す特別な識別子を含むことができる。このような識別子は、プライベート・キー・シェア生成を管理する場合に、コングレス１１０に関連するノード１０２によって使用されてもよい（これについては、以下で詳細に説明される）。より詳細には、グループに参加する目的でディジタル資産を預託＼制限するノード１０２は、（ディジタル資産の預託を行うことの結果として）コングレス１１０に関するプライベート・キー・シェアを割り振られる一方、他の目的で（例えば、支払チャネルを開設するために）ディジタル資産を制限する他のノード１０２は、コングレスに関するコングレス・プライベート・キー（即ち、コングレス・パブリック・キーに対応するもの）を保有しないかもしれない。

コングレス１１０は、メンバのデポジットの全部又は一部を没収する脅しによって協力的な行動が強制される自治グループとして振る舞うことができる。非協力的又は悪意のあるメンバは、多数の正直なメンバによる協力的なプロトコルへの参加によって、そのようなディジタル資産を没収される可能性がある。更に、コングレス・メンバがコングレス１１０の退会を希望する場合、彼らは彼らのメンバ・デポジットを引き出すことができる（即ち、コングレス１１０がメンバのデポジットをそのメンバのパーソナル・アドレスへ戻すように転送することを要求する）。しかしながら、資金の引き出しは、有効なディジタル署名を生成するために必要な閾値を超える多数のプライベート・キー・シェアが、グループのメンバに関連付けられるＴＥＥｓ（即ち、コングレス）によって、引き出しを承認するための部分的な署名を生成するために使用される場合にのみ実行される。

コングレス１１０によって実装される閾値署名方式は、種々のタイプのものであり得る。少なくとも閾値数のプライベート・キー・シェアが有効な署名を生成することに貢献する限り、閾値署名方式はｎ人の当事者間で署名権限の分配を可能にする。閾値より小さな如何なる部分集合も、有効な署名を生成することはできず、署名に関する如何なる有用な情報も生成できない。より詳細には、各当事者は、プライベート署名キーのシェア（持ち分）を管理し、閾値数のキー・シェアが、部分署名の組み合わせによる有効な署名を生成するために使用されなければならない。閾値未満のキー・シェアの如何なる部分集合も、部分署名の組み合わせによる有効な署名を生成することはできない。

閾値署名方式は楕円曲線ディジタル署名アルゴリズム（ＥＣＤＳＡ）方式であってもよい。例えば、ＥＣＤＳＡ方式は、次の文献でＩｂｒａｈｉｍ ｅｔ ａｌ．によって提案されるタイプのものであってもよい：“Ａ ｒｏｂｕｓｔ ｔｈｒｅｓｈｏｌｄ ｅｌｌｉｐｔｉｃ ｃｕｒｖｅ ｄｉｇｉｔａｌ ｓｉｇｎａｔｕｒｅ ｐｒｏｖｉｄｉｎｇ ａ ｎｅｗ ｖｅｒｉｆｉａｂｌｅ ｓｅｃｒｅｔ ｓｈａｒｉｎｇ ｓｃｈｅｍｅ”， ２００３ ＥＩＩＩ ４６ｔｈ Ｍｉｄｗｅｓｔ Ｓｙｍｐｏｓｉｕｍ ｏｎ Ｃｉｒｃｕｉｔｓ ａｎｄ Ｓｙｓｔｅｍｓ， １：２７６−２８０ （２００３）．この閾値署名方式は、楕円曲線暗号ベースのアルゴリズムであるディジタル署名方式の拡張であり、ｎ個のキー・シェア・ホルダの当事者からのｔ＋１個のキー・シェアがプライベート・キーを再構成するために必要とされる。この方式は、プライベート・キーを再構築する必要なしに、また、如何なる者も他者に各自のキー・シェアを明らかにする必要なしに、有効な署名を構築するために使用され得る。

ｔ＋１個のキー・シェアがシークレット（ｔｈｅ ｓｅｃｒｅｔ）を再構築するために十分なので、この技術による許容可能な敵の最大数はｔである。Ｉｂｒａｈｉｍ ｅｔ ａｌ．のモデルにおいて、敵対者は、シークレット・シェアを保有する当事者を買収し、そのシークレット・シェアへアクセスする存在（ａｎ ｅｎｔｉｔｙ）である。敵対者は様々なタイプのものであり得る。例えば、ビザンチン問題の敵対者は、プロトコルに参加するふりをする一方、実際には誤った情報を送る敵対者である。Ｉｂｒａｈｉｍによって提案されるＥＣＤＳＡ方式は、ｔ＜＝ｎ／４までの悪意の敵対者に対してロバストである。このロバスト性はｔ＜＝ｎ／３に上げることができるが、より多くの複雑さという代償を払うことになる。

Ｉｂｒａｈｉｍ ｅｔ ａｌ．のＥＣＤＳＡ方式は、ｔ＜＝ｎ／３の不完全敵対者（ｈａｌｔｉｎｇ ａｄｖｅｒｓａｒｉｅｓ）を止めることに対してロバストである。不完全敵対者は、買収された当事者がプロトコルに参加すること、又は、途中で参加を止めることができる。

このＥＣＤＳＡ方式は、悪意のある又は非協力的な者を識別するためにノード１０２により使用され得る種々のメカニズムを含む。例えば、検証可能なシークレット・シェアリング（ｖｅｒｉｆｉａｂｌｅ ｓｅｃｒｅｔ ｓｈａｒｉｎｇ：ＶＳＳ）は、Ｓｈａｍｉｒのシークレット・シェアリング（ＳＳＳ）に必要な多項式を共有するために使用され得る。ＳＳＳは、シークレットが複数の部分的に分割され、各参加者に各自固有の部分で提供されるシークレット共有の形態である。これらの部分はシークレットを再構築するために使用され得る。矛盾するシェアが様々なノード１０２に提供される場合、又はシェアが全てのノードにブロードキャストされるブラインド・シェアとは異なるノードに秘密裏に送られる場合に、悪意のあるノード１０２又はメンバを識別するために、ＶＳＳがノード１０２によって使用され得る。矛盾するシェアは、ノード１０２の内のうちの何れかによって識別され得る。シークレットの共有は、ノード１０２が各自のシェアを矛盾のないものとして検証することを可能にする補助情報を含めることによって、検証可能にされ得る。

個々のノードへの誤ったシェア（即ち、ブロードキャストされる盲目的シェアとは異なるシェア）の送信は、そのシェアの意図された受信ノードによって識別され得る。ノードへ秘密に送られる誤ったシェアの識別は、公に検証可能なシークレット・シェアリング（Ｐｕｂｌｉｃａｌｌｙ Ｖｅｒｉｆｉａｂｌｅ Ｓｅｃｒｅｔ Ｓｈａｒｉｎｇ：ＰＶＳＳ）の技術を使用して公に検証可能にすることができる。このような技術は、ＰＶＳＳが使用されず、誤ったシェアの受信者がオフラインであるか又は誤ったシェアが送信されたときにネットワークのかなりの部分から切断される場合に発生し得る不正な送信者の識別における考えられる遅延を回避し得る。

異なるノードに誤ったシェアを提供する等の不適切な行動は、悪意のある行動を抑止するために、コングレス１１０によって対処され得る。例えば、ノード１０２（図１）が悪意のある者として他のノード１０２によって識別される場合、閾値（例えばｔ＋１）を超える多数のノード１０２（即ち、コングレス・メンバに関連するノード）は、悪意のある者にペナルティを科すように協働し得る。例えば、ノード１０２は、悪意のある者によってコングレスに預け入れられたディジタル資産（例えば、ディジタル通貨、トークン又はその他のステーク（ｓｔａｋｅ）又は価値）に関わる行動をとることができる。例えば、コングレスは、ディジタル通貨、トークン、ステーク又は価値を、使用不可能アドレス（ａｎ ｕｎｓｐｅｎｄａｂｌｅ ａｄｄｒｅｓｓ）へ移すことによって焼却する（ｂｕｒｎ）ことができ、あるいは、コングレスは、悪意のある者への返却を許可しない決定について合意に達することによって、そのようなディジタル資産を没収することができる。また、誤った行動をするノードではないノード１０２はまた、誤った行動をするノードを排除するために協働することによって（例えば、キー・シェアを実質的に無効にすることによって；例えば、コングレス・プロトコルに参加することからノードを排除することによって、又は、プライベート・キーを共有し直して、誤った行動をするノードにシェアを割り当てないことによって）、誤った行動を止めることができる。

上述のＥＣＤＳＡ技術は、ＴＥＥの使用によって強化され得る。例えば、Ｉｂｒａｈｉｍ ｅｔ ａｌ．に基づく閾値ＥＣＤＳＡ署名技術は、ここではビザンチン敵対者と呼ばれる強力な形態の敵対者を想定している。この種の敵は、横暴に行動する可能性があり、例えば、署名プロセスへ参加することを拒否したり途中で止めたりするだけでなく、正直に参加するふりをして、誤った情報を送信し得る。しかしながら、ＴＥＥを使用し、シークレット・プライベート・キー・シェアが保存されているＴＥＥのエンクレーブ内で署名するために使用されるデータを生成することによって、追加のセキュリティが提供される可能性があり、なぜならエンクレーブが多数不正アクセスされる可能性は極めて低いからである。各ＴＥＥが１つのキー・シェアだけしか割り当てられないならば、例えば、危険にさらされる可能性のあるＴＥＥの数は、ｎが十分に大きいと仮定すると、ビザンチン問題の敵に対するロバスト性の閾値に近づかないように合理的に予想され得る。これは、キー・シェアの総数に対して少数の悪意のある敵対者にたいして耐性があるならば、プロトコルが安全であることを可能にする。

例えば、コングレスの全てのノードがＴＥＥを有する場合、ＴＥＥの製造者が買収されない限り、エンクレーブに保存されたシークレットの獲得は、ノードに対する物理的なアクセスに限り、そして多大な労力と費用をかける場合に限って達成され得る。このような製造者レベルの買収は、扱いやすいようものであると予想される。例えば、もし製造者が、多くのパブリック・キーが真のＴＥＥに対応すると誤って主張するならば、彼らはプライベート・キー・シェアへの直接的なアクセスを得て、潜在的に攻撃を開始するかもしれない。しかしながら、そのような攻撃は、製造者が他のノードからの支援なしに有効な署名を生成することを許容する程度に十分な数のキー・シェアを必要とすることになる。これは、総ステークのうちの大部分を蓄積することを意味し、法外に高価であると予想され得る。更に、攻撃を実行することによって、必然的に莫大な保有持分の価値の内のかなりの割合が損なわれることになる。

ＴＥＥが使用される場合、「損なわれたノード（Ａ ｃｏｒｒｕｐｔｅｄ ｎｏｄｅ）」に対するプロトコルのロバスト性を考察することは有用である。損なわれたノードは、ＴＥＥの外部のハードウェアは損なわれているが、ＴＥＥの完全性は損なわれていないようなノードである。損なわれたノードは、エンクレーブがどの情報を受信してどの情報を受信しないかに対するコントロールを有し得る。特に、損なわれたノードは停止するかもしれず、即ち、プロトコルへの参加を控えるかもしれない。プロトコルに提供される情報が、エンクレーブで秘密に保持されるプライベート・キーによって署名されるように要求される場合（対応するパブリック・キーは認証プロセスの際に認証される）、プライベート・キーは、エンクレーブそれ自体と同程度に信頼できる。従って、損なわれたノードは、任意の（認証された）情報をプロトコルへ送ることはできず、エンクレーブを停止させるか、又はエンクレーブを欺いて不適切に動作させるよう試みることによって、例えば古くなった情報を提供することによって、妨害を試みることしかできないであろう。その結果、損なわれたノードに関し、攻撃が成功するには、完全な署名を生成するために十分な数の部分的な署名の収集を必要とする。ＴＥＥに関し、Ｉｂｒａｈｉｍ ｅｔ ａｌ．のプロトコルは２ｔの損なわれたノードに対してロバストである。ｎ−２ｔ＞＝２ｔ＋１の場合、署名が生成され得るので、サイズ２ｔ＋１＜＝（ｎ＋１）／２のキー・シェアの適格なサブセットであれば十分である。従って、ＴＥＥが使用される場合、閾値署名方式の閾値は、損なわれたノードの存在下で有効な署名を生成するために、キー・シェアの５０％以上の数であるように設定され得る。

他の閾値署名方式が使用されてもよい。例えば、閾値署名方式は、以下の文献で提案されているタイプのＥＣＤＳＡ閾値方式であってもよい：Ｇｏｌｄｆｅｄｅｒ ｅｔ ａｌ．，“Ｓｅｃｕｒｉｎｇ Ｂｉｔｃｏｉｎ Ｗａｌｌｅｔｓ Ｖｉａ ａ Ｎｅｗ ＤＳＡ／ＥＣＤＳＡ ｔｈｒｅｓｈｏｌｄ ｓｉｇｎａｔｕｒｅ ｓｃｈｅｍｅ”，（２０１５）．このプロトコルは、ｔ＋１人の当事者が有効な署名を生成することを可能にする。その結果、有効な署名を生成するために敵対者がコントロールしなければならないキー・シェアの数は、敵対者がプライベート・キーを再構築するために所有しなければならないキー・シェアの数に等しい。この技術は、有効な署名を生成するために満場一致が要求される場合に、効率的な方式を提供することができる。最も一般的な場合、この方式は、コングレス・メンバ数ともに指数関数的に増えるスペース要件を課し、なぜなら任意の閾値に対して、ｎのうちｔ＋１プレーヤーの任意の可能なサブセットに対して、プロトコル全体を繰り返す必要があるからである。従って、ｎ及びｔ双方が大きな値である場合、多数のキー・シェアが格納される必要がある。このようなストレージ要件を緩和するために、標準ビットコイン・マルチシグネチャが、閾値署名と組み合わせられことができる。特に、ディジタル資産は、各プライベート・キーが複数のシェアに分割されるように、マルチ署名を使用してロックされることが可能である。この技術は、大規模なコングレスを、スペース要件の観点からより効率的にするであろう。スケーリング特性はまた、多数の参加者のためのスキームを、より小さな当事者サイズから、複数のレベルで、反復的に構成することによって改善され得る。例えば、閾値署名方式は次の文献の技術と組み合わせられることが可能である：Ｃｏｈｅｎ ｅｔ ａｌ．，Ｅｆｆｉｃｉｅｎｔ Ｍｕｌｔｉｐａｒｔｙ Ｐｒｏｔｏｃｏｌｓ ｖｉａ Ｌｏｇ−Ｄｅｐｔｈ Ｔｈｒｅｓｈｏｌｄ Ｆｏｒｍｕｌａｅ（２０１３），Ａｄｖａｎｃｅｓ ｉｎ Ｃｒｙｐｔｏｌｏｇｙ − ＣＲＹＰＴＯ ２０１３ ｐｐ １８５−２０２．

非ＥＣＤＳＡ署名方式を含む他の閾値方式が使用されてもよい。例えば、Ｓｃｈｎｏｒｒ方式に基づく閾値方式が、コングレス１１０を実現するためにノード１０２により使用されてもよい。

ブロックチェーン・ネットワーク１００（図１）におけるノード１０２は、選択された閾値署名方式に基づいてコングレス・プロトコルを実装することができる。このようなノード１０２は、コングレス・プロトコルを実装するメモリ２２０（図２）に記憶されるコンピュータ実行可能命令を含んでもよい。このような命令は、プロセッサ２１０（図２）によって実行されると、ノード１０２（図２を参照して説明したタイプの電子デバイス２００のようなもの）に、コングレス・プロトコルの１つ以上の方法を実行させる。そのような方法は、図４〜９の方法４００、５００、６００、７００、８００、９００のうちの何れか１つ又は組み合わせを含み得る。従って、コングレス・プロトコルは、図４〜９の方法４００、５００、６００、７００、８００、９００のうちの１つ以上を含み得る。この方法は、他のコングレス・メンバと関連する他のノードと協力するノードによって実行され得る。

コングレスへの加入
次にコングレスへ参加する方法４００を示す図４を参照する。この方法は、既存のコングレスに参加するために実行されることができる。即ち、方法４００は、以前に開始されたコングレスに参加するために使用されてもよい。

図４の方法４００は、オペレーション４０２において、コングレス・パブリック・キーを取得することを含む。コングレス・パブリック・キーは、コングレスの既存のメンバである者から取得されてもよいし、あるいは例えばブロックチェーン・ネットワーク１００（図１）の外側で動作する第三者システムを含む第三者から取得されてもよい。例えば、コングレス・パブリック・キーは、公のインターネット経由でアクセス可能な公のウェブサーバから入手されてもよい。更なる例として、コングレス・パブリック・キーはブロックチェーン上で監視されることが可能であり；例えば、ディジタル資産をコングレス・パブリック・キーへ移す少なくとも幾つかのトランザクションに含まれるメタデータに基づいて監視されてもよい。

方法４００を実行するノード１０２は、ノード１０２に関連付けられたプライベート・アカウントからコングレス・アドレス（即ち、コングレス・パブリック・キーに関連付けられたアドレス）へディジタル資産のトランザクションをブロードキャストすることによって、オペレーション４０４においてコングレス・パブリック・キーに支払を行う。より詳細には、ノード１０２は、コングレス・パブリック・キーに関連付けられたパブリック・グループ・アドレスへ、１つ以上のディジタル資産を移すトランザクションをブロードキャストする。パブリック・グループ・アドレスは、コングレス・プールのアドレスである。コングレス・プールは、コングレスの他のメンバに関連する他のディジタル資産を含む。従って、オペレーション４０４におけるトランザクションは、一旦マイナー１０４（図１）によってブロックに追加され、ブロックが確認された後に、他のメンバからのディジタル資産を含むコングレス・プールに移転される。パブリック・グループ・アドレスは、コングレスへ参加することを希望する者からの転送と、コングレスへ参加することを希望しない者からの転送との両方を受け取ることができる。コングレスに参加することを望まない者は、コングレス・プールへディジタル資産を転送し、それによりそのようなディジタル資産は、コングレスにより使用される閾値署名方式を用いて、全体的、部分的又は条件付きで管理され得る。例えば、図３を参照して上述したように、コングレス・パブリック・キーは、支払チャネルを開設するファンディング・トランザクションに関連するディジタル資産を制限することができる。

オペレーション４０４におけるトランザクションは、ディジタル資産を転送する者がコングレスへ参加することを希望していること、及びそのような目的のためにデポジットが行われていることを示すフラグ、識別子又は他の属性を含むことができる。

コングレス・プールにディジタル資産を預託した後、方法４００を実行するノード１０２は、オペレーション４０６において、プライベート・キー・シェアを受信する。次に、ノード１０２は、プロトコルの単一インスタンスを実行することによって、オペレーション４０８においてプライベート・キー・シェアを再生成する。プライベート・キー・シェアの生成は、ノード１０２のＴＥＥ内で実行されてもよい。

オペレーション４０８において、ノード１０２は閾値署名方式で使用されるべきプライベート・キー・シェアを生成し、その方式では少なくとも閾値数のプライベート・キー・シェアがコングレスに代わってトランザクションに関して有効な署名を生成するために使用されなければならない。他のプライベート・キー・シェアの保有者は、コングレスの他のメンバであり、パブリック・グループ・アドレスへ各自のディジタル資産を移すことにより許可された又は許可されていない方法でコングレスに参加している。

オペレーション４０７において、プライベート・キー・シェアを再生成するために、既存のコングレス・メンバは、キー・シェアを更新するために協力することができる。例えば、ノード１０２は、次数がｔで定数項ゼロのランダム多項式ｆ^０ _ｎ＋１（ｘ）を生成することができる。次いで、ノード１０２は、ポイントｆ^０ _ｎ＋１（ｎ＋１）を計算し、これをそれらのプライベート・キー・シェアとして設定することができる。次いで、ノード１０２は、この多項式（ｉ）ｆ^０ _ｎ＋１（ｉ）におけるポイントを既存のコングレス・メンバの各々に配分することができる（ｉ＝１，．．．，ｎ）。次に、各々の既存のコングレス・メンバ（ｉ＝１，．．．，ｎ）は、新しいプライベート・キー・シェアを取得するために、受信した値を既存のプライベート・キー・シェアに加える。今やノード１０２は他の全てのメンバと同等なプライベート・キー・シェアを有し、対応するパブリック・キーは変更されないままである。上述したように、閾値署名方式は、楕円曲線ディジタル署名アルゴリズム又はＳｃｈｎｏｒｒスキームに基づく閾値方式を含む種々のタイプのものであってもよい。

プライベート・キー・シェアは、ＴＥＥ２５０（図２）内で生成されることが可能であり、ノード１０２で安全に格納され得る。例えば、プライベート・キー・シェアはＴＥＥ２５０に格納されてもよい。

プライベート・キー・シェアが各ノードによって生成された後、以前のコングレス・パブリック・キーの管理下にある資金（例えば、元のコングレス・パブリック・キーに関連付けられるパブリック・グループ・アドレスに移された資金）は、（閾値署名方式の下で有効な署名を生成するのに十分な数のグループ・ノードの協力を通じて）新しいプライベート・キー・シェアに関連付けられる新しいコングレス・パブリック・キーへ転送され得る。しかしながら、他の実施形態では、ノードは、新しいコングレス・パブリック・キーが定義されることを要求しない方法で、コングレスに参加してもよい。その代わりに、同じコングレス・パブリック・キーが使用されてもよく、コングレス・ノードに関連付けられるＴＥＥは、コングレスに参加するノードが、既存のコングレス・パブリック・キーに対応するプライベート・キー・シェアを生成できるように協調するために使用されてもよい。

プライベート・キー・シェアがオペレーション４０８で生成された後、それは方法４００のオペレーション４１０で使用され得る。プライベート・キー・シェアは、メンバによってブロードキャストされ得るパブリック・グループ・アドレスから、トランザクションに対して有効な署名を協調的に生成するために使用され得る。即ち、プライベート・キー・シェアは、署名生成に貢献するために、閾値署名方式で使用され得る。閾値署名方式の下で、コングレスの閾値数のプライベート・キー・シェアは、ディジタル資産がコングレスから遠くへ移転されることを可能にする有効な署名を生成するために、それぞれのメンバによって使用されるように要求される。方法５００を実行するノード１０２は、ストレージからプライベート・キー・シェアを検索し、署名生成に貢献するためにプライベート・キー・シェアを使用することができる。十分な数の他のコングレス・メンバはまた、署名生成に貢献するために各自のプライベート・キーを使用する場合、署名が生成され、有効な発信トランザクションがブロードキャストされてもよい。ブロックチェーン・ネットワーク１００のマイナー１０４（図１）が、ブロックチェーン・ネットワーク１００内のノード１０２のコンセンサスによってブロックチェーンに追加される採掘済みブロックにトランザクションを追加し、ブロックが確認されると、発信トランザクションは完了する。この時点で、トランザクションで示されるディジタル資産は最早コングレス・パブリック・キーにより制限されない可能性がある。即ち、そのようなディジタル資産は最早コングレス・パブリック・キーによって制限されない可能性がある。

オペレーション４０８におけるプライベート・キー・シェアの使用は、ノード１０２のＴＥＥ内で実行されてもよい。ＴＥＥはプライベート・キー・シェアを保護し、その結果、システムの他の部分やメンバ自身が、プライベート・キー・シェア等のエンクレーブに保存される如何なるデータにもアクセスできないようにする。更に、ＴＥＥの完全性が維持されていることを仮定すると、メンバのデポジットが返還される前にプライベート・キーの削除を証明しなければならないので、メンバがデポジットの返還を希望する場合にはプライベート・キーのコピーを保持することはできない点で、ＴＥＥはプライベート・キーを保護する。更に、コングレスがプルーフ・オブ・ステーク・サイドチェーンの結合された検証者セット（a bonded validator set）として働く場合にＴＥＥを利用することは、トランザクションが実際に署名されるべきサイドチェーンに関してコンセンサスが達成される場合であってその場合に限り、部分的な署名が（ノードに対してＴＥＥにより）提供されることも保証できる。

オペレーション４１０におけるトランザクションは、コングレス・プールにこれらのディジタル資産を最初に預託した者へディジタル資産を戻すように転送することができる。即ち、転送は、ディジタル資産を預託者に返還することができる。転送はまたディジタル資産を他の場所へ移すことができる。例えば、ディジタル資産は、第三者へ又は使用不可能アドレスへ移されてもよい。場合によっては、支払チャネルを開設するためのファンディング・トランザクションにおいて、コングレス・パブリック・キーにより制限されていた１つ以上のディジタル資産が、コングレスの承認でトランザクションによって再分配され得る。

ディジタル資産の没収
次に、図５を参照すると、ディジタル資産を没収する例示的な方法５００が示されている。図５の方法５００は、以前にコングレスに参加したノード１０２によって実行されてもよく、そのノードは図４の方法４００を実行するのと同じノードであってもよい。方法５００は、図４の方法４００のオペレーション４０８の後に実行されることが可能であり、そのため、方法５００を実行するノード１０２は、図５の方法５００が実行される場合に、プライベート・キー・シェアに既にアクセスしている。

オペレーション５０２では、ノード１０２は、悪意のある者による悪意のある活動を検出する。悪意のある者はコングレスの他のメンバである。悪意のある活動は、ノード１０２が、コングレスのメンバが所定のプロトコル又は基準に違反していると判断した場合に検出される。例えば、コングレスのメンバであるノードが、コングレスの他のメンバに、悪い情報（即ち、虚偽の情報、矛盾する情報、許容できない情報）を報告する場合、そのメンバは悪意のあるメンバであると考えられてよい。更なる具体例として、コングレスのメンバであるノードが、コングレス・パブリック・キーにより制限されるディジタル資産（支払チャネルを開設するためにファンディング・トランザクションでコングレス・パブリック・キーにより制限されるディジタル資産など）を不正で詐欺的に別の場所へ転送するトランザクションを提案する場合、他の誠実なノードは、不正なノードのメンバ・デポジットにペナルティを科すように動作することができる。

オペレーション５０３では、悪意のある活動を検出したことに応答して、ノード１０２は、コングレスの他のノードと協力して、悪意のある者であるメンバを一時停止にすることができる。即ち、コングレスは、悪意のある者を、コングレスへの更なる参加から除外することができる。

全てノード１０２が事前に所定のプロトコル又は基準に従って動作することを確実にするために、コングレス・プールへのメンバのデポジットは、没収（ｃｏｎｆｉｓｃａｔｉｏｎ）の対象となり得る。没収は、没収されたと見なされるメンバ・デポジットの返還を永続的に妨げることを意味する。悪意のある活動に起因して返却されないメンバ・デポジットを形成するディジタル資産は、コングレス・プールに残されるかもしれないが返還はされず、速やかに又は将来的に別の使用不可能アドレスへ転送され、又は没収される可能性があり、没収の性質は、コングレスがサイドチェーンに設定される保証バリデータ（承認者）として機能するか否かに依存する。例えば、オペレーション５０４において、悪意のある者による悪意のある活動を検出したことに応答して、方法５００を実行するノード１０２は、プライベート・キー・シェアを使用して、没収トランザクションにおいて部分的な署名を提供することができる。即ち、ノードは、悪意のある者によってパブリック・グループ・アドレスに（即ち、コングレス・プールに）以前に移されたディジタル資産の少なくとも一部を没収するために、コングレスの他のノードと協力する。即ち、グループ・メンバーが所定のプロトコル又は基準に違反していることに気付いたことに応答して、プライベート・キー・シェアが、そのグループ・メンバーに関連付けられ且つコングレス・プールに保持される１つ以上のディジタル資産のトランザクションの承認に貢献するために利用される。

閾値署名方式は、コングレス・パブリック・キーと共に使用されるので、単独で行動する個々のノードは、他のコングレス・メンバのディジタル資産のデポジットを、コングレス・プールから別の場所へ（例えば、使用不可能アドレスへ）移すことはできない。むしろ、他のアドレスへディジタル資産を移すために有効な署名を生成するために、各自それぞれのメンバにより、閾値数のプライベート・キー・シェアが使用される場合、又は少なくとも閾値数のプライベート・キー・シェアを有するメンバのグループが（オペレーション５０３で）メンバを一時停止にするコンセンサスに達した場合に限り、ディジタル資産は転送によって没収されることが可能であり、これは、一時停止させられているメンバからの如何なる引き出し要求も、自動的に無視されることを引き起こす。ディジタル資産が転送により没収される場合、ディジタル資産が転送され得る他のアドレスは、使用不可能アドレスに関連付けられてもよい。例えば、他のアドレスは、誰もがそのアドレスのパブリック・キーに結び付くディジタル資産にアクセスできないように、プライベート・キーが存在しないアドレスであってもよい。ディジタル資産が使用不可能アドレスへ移される場合、それらは、コングレスの何れのメンバによっても、又は実際にはブロックチェーン・ネットワーク１００内の何れのノードによっても、最早使用できないので、焼却されたと考えられてよい。

従って、オペレーション５０４において、ノードは、使用不可能アドレスへのトランザクションの有効な署名を生成するために、コングレスの他のメンバと協力して、プライベート・キー・シェアを使用することによって、ディジタル資産を没収することができる。

更に、幾つかの実装において、コングレスは、保証承認者のセットとして機能することが可能であり、プルーフ・オブ・ステーク・サイドチェーン（以下においてより詳細に説明されるゴーストチェーンを含む）を確実にし、このサイドチェーンはブロードキャスト・チャネルとして使用され得る。例えば、メンバが悪意を持って行動したことのコンセンサスが、サイドチェーンにおけるコングレス・メンバにより到達され得る。このコンセンサスは、悪意のある活動についての有罪の証拠を含むサイドチェーン・トランザクションの確認に対応し得る。コンセンサスに到達した場合、悪意のあるメンバにより行われるメンバ・デポジットを引き出す如何なるリクエストも否定され、そのデポジットは没収されたものとみなされる。没収されたディジタル資産の全部又は一部は、将来のいずれかの時点で焼却され得る。即ち、後の時点で、（悪意のあるメンバを含まない）閾値数のメンバが協力して、没収したディジタル資産の使用不可能アドレスへの転送を承認することができる。むしろ、ディジタル資産の一部又は全部が、メンバの不正行為の証拠を提供したノードに報酬として送られてもよい。

コングレスは、ディジタル資産の預託によりブロックチェーン・ネットワーク１００の任意のノード１０２によって参加してよいオープンなグループであるので、グループ・メンバーシップは周期的に変化してもよい。そのような変更が生じると、プライベート・キー・シェアの配分が更新され得る。

新しいパブリック・アドレスを使用したプライベート・キー・シェア配分の更新
図６を参照すると、プライベート・キー・シェア配分を更新する方法例６００が示されている。方法６００は、ブロックチェーン・ネットワークの他のノードと協調するブロックチェーン・ネットワーク１００のノード１０２によって実行されてもよい。

方法６００のオペレーション６０２において、ノード１０２は、再配布リクエストを検出し、これは要求であり、その要求を満たすためには、キー・シェアの再配布を必要とする。例えば、ノード１０２は、将来の新たなメンバがディジタル資産をパブリック・グループ・アドレスに移したこと、又は既存のメンバがメンバ・デポジットの引き出しを要求したことを検出するかもしれない。

ディジタル資産は、コングレスへの参加を要求する又はコングレスへの関与を増加させることを要求するノードによって、及びコングレスへの参加を要求していないが、別の目的（例えば、後述するようにディジタル資産をサイドチェーンへ移すこと）のためにコングレスへディジタル資産を移している他のノードによって、パブリック・グループ・アドレス（即ち、コングレスプール）へ移され得る。オペレーション６０２において、ノード１０２は、パブリック・グループ・アドレスに対するディジタル資産の少なくとも幾つかのトランザクションに含まれる１つ以上の属性を使用して、コングレス・メンバ（即ち、他の目的ではなくコングレスに参加するためにコングレス・パブリック・キーへディジタル資産を移す者）を識別することができる。例えば、特定のトランザクションは、トランザクションにおける属性を利用する特別なトランザクションとしてフラグを立ててもよい。そのような属性（又は属性の存在又は不存在）は、移転が行われる目的を示してもよい。例えば、転送がコングレスへ参加することを要求していない場合、フラグがトランザクションに含められてもよい。

オペレーション６０２においてリクエストを検出したことに応答して、その実現には、オペレーション６０４において、キー・シェアの再配布を必要とし、図４の方法４００のオペレーション４０８においてプライベート・キー・シェアが生成されたのと同様な方法で、新しいプライベート・キー・シェアがノード１０２によって生成される。コングレスの他のメンバ・ノードもまた各自のプライベート・キー・シェアを生成する。これらのプライベート・キー・シェアは、新しいコングレス・パブリック・キーの閾値署名方式と共に使用され得る。この時点でコングレスを去るメンバは、オペレーション６０４の間に新たなプライベート・キー・シェアを生成せず、また、彼らは新しいコングレス・パブリック・キーと共に使用するためのプライベート・キー・シェアを割り当てられないので、彼らはコングレスに参加する資格を失い、もはやコングレス・メンバとは考えられない。

更に、再配布リクエスト（これは要求であり、その履行には、キー・シェアの再配布を必要とする）を検出したことに応答して、オペレーション６０６において、ノード１０２は、他のコングレス・メンバと協力して、パブリック・グループ・アドレス内の全てのディジタル資産を、新しいパブリック・キーに関連する新しいパブリック・アドレス（その後、新しいコングレス・パブリック・キーとなる）へ移す。

従って、図６の方法６００によれば、デポジットの配分が変化する場合、又はデポジットを引き出すことに対してメンバからリクエストが受信される場合、プライベート・キー・シェアが再生成され、コングレスの支配下にある全てのディジタル資産が、新しいパブリック・キーへ移されることが可能である。コングレスのメンバーシップが更新され得る頻度は、ブロックチェーン・ネットワーク１００のブロック時間によって制限される。多くのアプリケーションは少ない頻度で（即ち、プルーフ・オブ・ワーク機構でブロックが採掘される頻度と比較して低い頻度で）リバランス（又は資産再配分）を行うことを必要とするだけであろう。

既存のパブリック・グループ・アドレスを維持しつつプライベート・キー・シェア再配分を更新する
次に、図７を参照すると、プライベート・キー・シェア配分を更新する別の例示的な方法７００が示されている。方法７００は、ブロックチェーン・ネットワーク１００の他のノードと協力して、ブロックチェーン・ネットワーク１００のノード１０２によって実行されてもよい。

図７の方法７００では、コングレス・パブリック・キーは、メンバ・デポジットの配分が変化する度に変化しない。新しいキー・シェアを割り当てるリクエストが検出されると（オペレーション７０２。これは、パブリック・グループ・アドレスへのディジタル資産のデポジットにより発生する可能性がある）、ノード１０２は、コングレスの他のメンバと協働して、同じパブリック・キーに対する新しいプライベート・キー・シェアを（オペレーション７０４において）グループの新しいメンバへ発行する。コラボレーションするノードの数は、少なくとも、閾値署名方式の下でディジタル署名を生成するために必要とされる閾値数である。オペレーション７０４において、他のキー・シェアは同じままである一方、追加のキー・シェアが割り当てられてもよい。これは（閾値署名方式の）閾値の変更を必要とするかもしれないが、実際にはその変更は僅かであろう。あるいは、オペレーション８０４において、他のキー・シェアが新しくされる一方、追加のキー・シェアが割り当てられてもよい。そのような更新は、前世代の任意のキー・シェアの削除に対する証明によって達成されるように要求される。この場合、同じ閾値を維持する一方、新しいシェアが割り当てられてもよい（ＳＳＳの場合、これは、増加した次数についての新たな多項式における共有を含む）。

オペレーション７０２において、ノード１０２は、パブリック・グループ・アドレスに対するディジタル資産のトランザクションの少なくとも幾つかに含まれる１つ以上の属性を使用して、コングレス・メンバ（即ち、他の目的ではなくコングレスに参加するためにコングレス・パブリック・キーへディジタル資産を移した者）を識別することができる。例えば、特定のトランザクションは、トランザクションにおける属性を使用して特別なトランザクションとしてフラグを立ててもよい。そのような属性（又はその存在又は不存在）は、移転が行われる目的を示してもよい。例えば、移転がコングレスに参加することを要求していない場合に、フラグがトランザクションに含まれてもよい。

メンバが方法７００を使用するコングレスを去る場合、彼らは各自のプライベート・キー・シェアを確実に削除することができる。旧メンバのプライベート・キー・シェアが使用不可能であることを保証するために、コングレスのメンバは、特別なＴＥＥを有するノード１０２を使用するように要求され得る。ＴＥＥは、ハードウェア・レベルで実現されるアーキテクチャであり、その中で実行される命令及びデータが、システムの残りの部分からのアクセス及び操作に対して保護されることを保証する。ＴＥＥは、コングレスの他ノードのような外的な者に対してシステムの完全性を検証するために使用され得るリモート認証チャレンジに応答するハードウェア・メカニズムを使用してもよい。

各メンバ・ノードは、集積回路レベルでハードウェアを危険にさらすことなく、ホスト・システムに対してアクセスできないままである１つ以上のランダム・シークレット値を生成するように構成される認証されたＴＥＥを使用することができる。このようにして生成されたシークレット値は、プライベート・キー・シェアの分散生成（例えば、図４の方法４００のオペレーション４１０）において使用される。このシークレット値は、コングレスのセットアップ段階で共有パブリック・キーを確立するためにも使用され得る。セットアップ・プロトコルに関連する計算は、ＴＥＥエンクレーブ内で実行されるので、何れのメンバ又は元メンバも、メンバ間通信又はその他の任意の方法から、各自自身又は他のプライベート・キー・シェアに関する情報を導出するはできない。ＴＥＥ内のエンクレーブは、ＴＥＥエンクレーブが真正であること、及び承認されたコンピュータ読取可能な命令を実行していることを他ノードに証明するために使用され得るリモート認証プロトコルが実行されることを可能にする。

グループ変更に関連する計算は、ＴＥＥエンクレーブ内で実行される。例えば、ＳＳＳの目的のために新たな多項式を計算する際に使用され得る新たなセキュア・ランダム・シークレットの生成は、ＴＥＥエンクレーブで実行される。

ＴＥＥエンクレーブはまた、メンバ・デポジットが返還され得る前に、もはや使用されない以前のシークレット及び以前のキー・シェアが確実に削除されることを保証することを目的としている。より詳細には、メンバ・デポジットを返却させるために、認証プロトコルは、ＴＥＥエンクレーブがキー・シェアの削除を公的に証明することを要求し得る。各ノード１０２は、このような認証を、リモート認証プロトコルにより他ノードで必要な削除が発生したことのコンファメーションとして解釈することができる。従って、方法８００は、コングレスを去ったメンバのＴＥＥ内で以前に保持されていたプライベート・キー・シェアが、そのメンバに関連するノードから削除されていることを確認することを含んでもよい。この確認は、プライベート・キー・シェアの削除の認証を受けることによって実行されてもよい。従って、コングレスを離れたメンバのＴＥＥ内で以前に保持されていたプライベート・キー・シェアの削除に対する認証を得るために、リモート認証プロトコルが使用されてもよい。

図６の方法６００及び図７の方法７００はそれぞれ、様々な利点を提供する。例えば、図６の方法６００は、セキュアな削除を当てにせず、信頼できるハードウェアを当てにする必要もない。しかしながら、図６の方法６００はそのようなハードウェアによる恩恵を得ることが可能であり、なぜならある状況では、そのようなハードウェアは、キー・シェアの悪意のプーリングをより起こりにくくすることができるからである。

図７の方法７００は、メンバーシップが変更されるたびに、新しいコングレス・パブリック・キーの下でディジタル資産を再ロックする必要を回避する。更に、ある状況では、方法７００は図６の方法６００よりも早期にメンバーシップを更新してもよく、なぜなら図７の方法７００の下では、ディジタル資産が新しいパブリック・キーへ移されないので、全てのディジタル資産を新しいパブリック・キーへ移動させるためにトランザクションがブロックチェーンに追加されることを要しないからである。即ち、パブリック・キーは変化しないので、ディジタル資産の新しいパブリック・キーへの移転を確認するために生成される幾つかのブロックを待つ必要なしに、図７の方法７００を用いてメンバーシップが更新され得る。

コングレスからの退会
前述したように、グループ・メンバーは、時々、コングレスを立ち去ることを要求することがあり、グループ・メンバーがコングレスから退会する場合、彼らがコングレス・プールに預け入れたディジタル資産は、彼らに返却され得る。ここで図８を参照すると、デポジットを返却する例示的な方法８００が、フローチャート形式で示されている。この方法は、コングレスの他のノード１０２と協力してノード１０２によって実行され得る。

方法８００のオペレーション８０２において、ノード１０２は、コングレス・メンバである要求者から引き出しリクエストを受信する。引き出しリクエストはまた退会リクエストと言及されてもよい。引き出しリクエストは、要求者により以前に預託され且つコングレスによって現在管理されているディジタル資産を引き出す要求である。この要求は、要求者によって全てコングレス・メンバにブロードキャストされていてもよい。

リクエストを受信したことに応答して、ノード１０２は、オペレーション８０４において、決定された基準に対してリクエストを評価する。このような基準は予め定められた基準であってもよい。グループ・メンバーシップが変化するたびにコングレス・パブリック・キーが変更されないコングレス・プロトコルに従って、コングレスが動作するならば、オペレーション８０４において、ノード１０２は、プライベート・キー・シェアが要求者によって削除されていることを確認することができる。そのような確認は、ＴＥＥに関連するリモート認証プロトコルを利用して得られてもよい。

コングレス・プロトコルが、メンバーシップが変わる場合にコングレス・パブリック・キーが変更されるものである場合、プライベート・キー・シェアは最早有効ではないので、ノード１０２はプライベート・キー・シェアの削除を確認しないかもしれない。その代わりに、新たなコングレス・パブリック・キーが使用されるかもしれないし、コングレスの管理下にある他のディジタル資産が新しいコングレス・パブリック・キーに移されるかもしれない。

オペレーション８０４において、評価は、ゴースト・チェーンが現在展開されているか否かを考慮してもよい。ゴースト・チェーンが展開されている場合、引き出しリクエストは、ゴースト・チェーン動作終了まで満足されないかもしれない。即ち、ゴースト・チェーンで採掘しているコングレス・メンバは、少なくともゴースト・チェーンが終了するまで、ディジタル資産の彼らの「ステーク」を引き出すことを妨げられる。

ノード１０２が評価に基づいて引き出しリクエストを承認する場合、オペレーション８０６において、ノードは、ディジタル資産の引き出しを促す。即ち、ノード１０２は、ディジタル署名を協調的に生成するためにそのプライベート・キー・シェアを使用し、また要求者によって以前に預託されたディジタル資産を要求者へ移すためにディジタル署名を使用する。例えば、ディジタル資産はアドレスへ返送されてもよく、ディジタル資産はそのアドレスから以前に受信されている。オペレーション８０６は、閾値署名方式に従って実行され、その結果、少なくとも閾値数のコングレス・メンバがその引き出しを承認した場合にのみ、引き出しは成し遂げられる。オペレーション８０６は、退会することを望むメンバが一定期間活動を停止した後に実行される。この待機期間は、各自のメンバ・デポジットの返還のためのプロトコルが実行されている場合に、メンバが誤った行動に従事してしまうことを防止する。

コングレス・プロトコルは、多数のさまざまな目的に使用され得る。コングレスは、様々な機能を実行するための安全なメカニズムを提供する。コングレスは、信頼を失うことなく機能することができ、ディジタル資産の所有権を管理することができる。

コングレス・プロトコルは、例えば、ゴースト・チェーンを実装するために使用されることが可能であり、その場合、コングレス・プロトコルはゴースト・チェーン・プロトコルと言及されてもよい。

ハブ・フェイルセーフとしてのコングレス
次に、図９を参照すると、フェイルセーフ・モードを実施する例示的な方法９００が、フローチャート形式で示されている。方法９００は、コングレス１１０のメンバである他のノード１０２と協働して、コングレス１１０のメンバであるノード１０２によって実行されることができる。即ち、方法９００は、上述したように、メンバ・デポジットのコングレス・プールへのデポジットにより、コングレスに既に加盟しているノード１０２によって実行される。従って、方法９００を実行するノード１０２は、図９の方法９００を実行する前に上述したように、プライベート・キー・シェアを取得している。

オペレーション９０２において、ノード１０２はハブとの支払チャネルに参加する１つ以上のノードにより発行された１つ以上のフェイルセーフ活性化リクエストを検出する。支払チャネルは、ブロックチェーン・ネットワークに関連する価値の交換のコミットメントが、ブロックチェーン・ネットワーク外部でやり取りされることを許容する。例えば、上述したように、価値はコミットメント・トランザクションを利用して交換されることが可能であり、（潜在的な違反救済トランザクションに対する）価値は何時でもブロックチェーンに引き渡されることが可能である。

フェイルセーフ活性化リクエストは、図３特に図３の方法のオペレーション３０４に関連して上述したようなファンディング・トランザクションをブロードキャストすることにより支払チャネルを以前に開設したノードにより発行されたリクエストである。ファンディング・トランザクションはコングレス・パブリック・キーで（即ち、コングレスを形成するノードのグループに関連するパブリック・キーで）ディジタル資産を制限する。より具体的には、図３に関連して上述したように、各々のファンディング・トランザクションは３つの別々のパブリック・キーでディジタル資産を制限し、それにより、その制限は一緒に動作している支払チャネルに関連する双方のノードにより、又は単独で活動するコングレスにより取り除かれることが可能である。

フェイルセーフ活性化リクエストは、図３の方法３００のオペレーション３１０に関連して説明したタイプのものであってもよい。図３の説明で言及したように、フェイルセーフ活性化リクエストは、フェイルセーフ活性化リクエストに関する中央リポジトリとして動作するウェブサーバへ提出されてもよい。従って、図９の方法９００を実行するノードはフェイルセーフ活性化リクエストに関するウェブサーバを監視してもよい。

各々のフェイルセーフ活性化リクエストは、故障しているハブに接続されるノードのリクエストにおいてエンクレーブ内で生成され、エンクレーブ・パブリック・キーに関連するエンクレーブ・プライベート・キーを利用して署名される。フェイルセーフ活性化リクエストは支払チャネルの状態を指定することができる。支払いチャネルの状態は支払チャネルの残高であり、状態又は残高は、（最新のコミットメント・トランザクションにより反映されるように）支払チャネルの最新の状態が考慮される場合に、ディジタル資産の割り振りを決める。フェイルセーフ活性化リクエストはまた他の情報を含んでいてもよい。例えば、フェイルセーフ活性化リクエストは、支払チャネルをクローズするためにノードにより提示される手数料を指定してもよい。フェイルセーフ活性化リクエストはまた、タイムスタンプ等のフレッシュネス・データを含んでもよい。タイムスタンプ又は他のフレッシュネス・データは、フェイルセーフ活性化リクエストが生成又は発行された日及び／又は時間を指定することができる。代替的に、タイムスタンプはブロックチェーン・ネットワークのブロックチェーンに追加された最近のブロックのブロック番号を指定してもよい。

オペレーション９０４において、方法９００を実行するノードは、フェイルセーフ活性化リクエストを評価する。例えば、ノードは、各々のフェイルセーフ活性化リクエストの鮮度を評価してもよい。コングレスのノードは、満了している（即ち、十分に現在のものであるとは考えられない）フェイルセーフ活性化リクエストを無視するように構成されることが可能であり、各々のフェイルセーフ活性化リクエストは、タイムスタンプ等のフレッシュネス情報を含んでもよく、それは個々のフェイルセーフ活性化リクエストが満了したか否かをノードが判断することを可能にする。例えば、フレッシュネス情報は、フェイルセーフ活性化リクエストを提出したノードにより観察された最新のブロック番号であってもよく、グループは、フェイルセーフ活性化リクエストで指定されるブロック番号に基づいて、及びブロックチェーンに追加された最新のブロックの現在のブロック番号に基づいて、満了したと判断されたフェイルセーフ活性化リクエストを無視することができる。即ち、各々のフェイルセーフ活性化リクエストは、フェイルセーフ活性化リクエストが生成された場合にブロックチェーン・ネットワークのブロックチェーンに追加された最新のブロックの個々のブロック番号を指定することが可能であり、グループ（即ち、コングレスのノード）は、フェイルセーフ活性化リクエストで指定されるブロック番号に基づいて、及びブロックチェーンに追加された最新のブロックの現在のブロック番号に基づいて、満了したと判断されたフェイルセーフ活性化リクエストを無視するように構成される。方法９００を実行するノードは、従って、フェイルセーフ活性化リクエストが発行されて以来経過したブロック数に基づいて、フェイルセーフ活性化リクエストの鮮度にアクセスすることができる。この数は、所定の閾値又は他の基準と比較され、所与のフェイルセーフ活性化リクエストが満了したか否かを判断することができる。例えば、その基準は、フェイルセーフ活性化リクエストが、「待機期間」と比較して小さなブロック数だけ前に発行されているというものであり、フェイルセーフ活性化リクエストが発行された後その待機期間の間にＴＥＥは支払チャネルにおいて処理を行わない。

各々のフェイルセーフ活性化リクエストは、本方法を実行するノードにより特定の支払チャネルに、及びより具体的には支払チャネルを開設するために使用されるファンディング・トランザクションにマッピングされ得る。ノードは所与のフェイルセーフ活性化リクエストに関連するファンディング・トランザクションを識別することができ、なぜならファンディング・トランザクションは、フェイルセーフ活性化リクエストを署名するために使用されるエンクレーブ・プライベート・キーに対応するエンクレーブ・パブリック・キーを含むからである。

オペレーション９０４において、方法９００を実行するノードは、フェイルセーフ活性化リクエストが所定の基準を満足していること、及びそれに応じてオペレーション９０６においてフェイルセーフ・モードを実施することを決定することができる。

所定の基準は、十分な数のフェイルセーフ活性化リクエスト（即ち、満了していない十分な数のフェイルセーフ活性化リクエスト）が受信されることを要求し得る。フェイルセーフ活性化リクエストの十分性は閾値を参照して判断されてもよい。例えば、所定の基準は、フェイルセーフ活性化リクエストの十分な数が（そのようなリクエストを発行する個々のノードの残高により重み付けされる）、所定の閾値を超えることを要求してもよい。

オペレーション９０６において、方法９００を実行するノードは、コングレスの他のノードと協力して、フェイルセーフ・モードを実施する。そのようにする際に、ノードは、コングレスの他のノードと協力して、フェイルセーフ活性化リクエストに関連する支払チャネルを閉鎖する。支払チャネルを閉鎖するために、メインチェーン・トランザクションが準備及び提案され、コングレスに代わって有効な署名を生成するのに十分なコングレスの複数のノードにより、部分的な署名が提案されたトランザクションに追加される。トランザクションはブロックチェーン・ネットワークにブロードキャストされる。このトランザクションは、支払チャネルを開設したファンディング・トランザクションにおけるコングレス・パブリック・キーにより以前に制限されていたディジタル資産を再分配する。より具体的には、ディジタル資産は、関連するフェイルセーフ活性化リクエストで示されるように、支払チャネルの状態に基づいて再分配される。

支払チャネルを閉鎖するトランザクションは、複数のフェイルセーフ活性化リクエストに関連する複数の支払チャネルを閉鎖することができる。即ち、コングレスのノードは、１つのトランザクションで複数の支払チャネルのバッチ閉鎖を実行することができる。そのようなバッチ閉鎖はメイン・ブロックチェーン・ネットワーク（即ち、メインチェーン）の負担を減らす。コングレスのノードは、例えばスタガード閉鎖トランザクションを含む、ブロックチェーン・ネットワークの他の負荷バランス手段を実施することができる。例えば、コングレス・ノードは、メイン・ブロックチェーン・ネットワークに対する混乱を引き起こし得るレベルを超えて負荷が増大しないことを保証するために、支払チャネルを閉鎖する少なくとも幾つかのトランザクションをブロードキャストするまで待機する。

支払チャネルを閉鎖するために、コングレスの複数のノードは、支払チャネルを閉鎖するトランザクションに有効な署名を協力して生成する。この署名プロセスを促進するために、コングレスのノードにより、一時的なサイドチェーンが配備されてもよい。この一時的なサイドチェーンは、ゴースト・チェーンと呼ばれてもよい。閉鎖するトランザクションの署名を促進することに加えて、ゴースト・チェーンはまた、故障したハブに接続された支払チャネルに対して以前に当事者であったノード間で、価値の別のやり取りを許容してもよい。即ち、コングレスのノードが、支払チャネルを閉鎖するトランザクションについて有効な署名を協力して生成する前に、ゴースト・チェーンと呼ばれる一時的なサイドチェーンが配備されてもよい。一時的なサイドチェーンは、ハブに接続されたノード間で価値が更に移転されることを許容し得る。従って、支払チャネルが最終的に閉鎖される場合に、支払チャネルを閉鎖するトランザクションは、フェイルセーフ活性化リクエストに記載されているような支払チャネルにおける初期残高とサイドチェーンで転送される値とに基づいている。

次に例示的なゴースト・チェーンが説明される。

ゴースト・チェーン
図１０を次に参照すると、ブロックチェーン１００２とゴースト・チェーン１００４とが示されている。ブロックチェーン１００２は、ブロック・ベースで分散されるプルーフ・オブ・ワーク台帳である。ゴースト・チェーン１００４は、ブロック・ベースで分散されるプルーフ・オブ・ステーク分散台帳であり、支払チャネルに関連するハブが故障した場合に、支払チャネルを閉鎖することを促進するために使用されることが可能である。

ゴースト・チェーンは、ゴースト・チェーンのマイナーがコングレスのメンバであるプルーフ・オブ・ステーク・ブロックチェーンである。即ち、コングレスのメンバは、ゴースト・チェーンで採掘することを許可されている。プルーフ・オブ・ワーク・ブロックチェーン・ネットワークにおける彼らのメンバ・デポジットは、彼らがゴースト・チェーンで採掘することを可能にする彼らのステークとして機能し、何れかのメンバが採掘するように選ばれる確率は、彼らのデポジットの相対的な量に比例する。

ゴースト・チェーン１００４は図９の方法９００のオペレーション９０６で配備され；即ち、フェイルセーフ・モードが実施されるときである。ゴースト・チェーンは、ゴースト・チェーンの以前のインスタンス化からの最終ブロック（ターミナル・ブロックとも言及される）であるジェネシス・ブロック（ａ ｇｅｎｅｓｉｓ ｂｌｏｃｋ）とともにインスタンス化（具体化）され得る。このブロックは、ジェネシス支払に関する情報を含むことができる。ジェネシス支払は、ゴースト・チェーンの以前の配備に基づいて未だ行われていないディジタル資産の移転である。

トランザクションに対する有効な署名を生成するためにマイナーにより多数のブロックがゴースト・チェーンに追加され、その効果は支払チャネルを閉鎖すること、又は不具合のある支払チャネルに関連するノード間で価値を更に移すことである（例えば、これらのノードは「スポーク」を介して故障したハブに接続され得る）。より具体的には、閾値署名方式に従って有効な署名が生成されるまで、ノードは、各自のプライベート・キー・シェアを利用して、提案されたトランザクションに部分署名を追加する。

支払チャネルを閉鎖するために、トランザクション（閉鎖トランザクションと言及されてもよい）が構築され、署名される（以下において詳細に説明される）。このトランザクションは、その効果が支払チャネルの状態に基づいて（及び少なくとも幾つかのケースでは、ゴースト・チェーンで生じる価値の何らかの更なるトランザクションに基づいて）メイン・ブロックチェーン１００２で資金を分散することであろう。トランザクションはまた、ゴースト・チェーンのマイナーに報いるため及びジェネシス支払を行うために資金を分配する。

全ての支払チャネルが閉鎖された後、ゴースト・チェーン１００４は終了する。ゴースト・チェーン１００４は終了するので、典型的なブロックチェーンとは異なり、それは終了ブロックを有する。終了ブロックは、ゴースト・チェーンの次のイタレーションで作成されるジェネシス支払の記録を含むように準備され得る。ジェネシス支払は参加者にインセンティブを与える。より具体的には、支払チャネル閉鎖に参加したが、ゴースト・チェーンのその反復の間に彼らの参加の見返りにディジタル資産の移転を受けていないノードは（例えば、閉鎖トランザクションは彼らの参加の前に準備されているので）、ターミナル・ブロックで参照されることが可能であり、それにより彼らはゴースト・チェーンの次の反復でディジタル資産を受けることになる。

上述の例は、ビットコインで利用可能なオペレーション・コードを参照しているが、本明細書で説明される方法はまた、他のタイプのブロックチェーン・ネットワークと共に使用され得る。

上述の方法は、一般に、ノードで実行されるように説明されてきたが、方法の特徴は、他のノードとの協調を当てにし、他の場所で実行されることが可能である。

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

Claims (16)

1. ノードにおける信頼される実行環境に関連するエンクレーブからエンクレーブ・パブリック・キーをハブに提供するステップ；
   第１パブリック・キー、第２パブリック・キー、及び第３パブリック・キーでディジタル資産を制限するファンディング・トランザクションをブロックチェーン・ネットワークへブロードキャストすることにより、前記ハブとのチャネルを設定するステップであって、前記ディジタル資産の制限は：１）前記第１パブリック・キーに対応する第１プライベート・キーから生成される第１署名及び前記第２パブリック・キーに対応する第２プライベート・キーから生成される第２署名の双方；又は２）前記第３パブリック・キーに対して有効な第３署名により解除されることが可能であり、前記第３パブリック・キーはグループに関連付けられている、ステップ；
   前記エンクレーブにおいてコミットメント・トランザクションを前記ハブから受信するステップであって、前記コミットメント・トランザクションは前記エンクレーブ・パブリック・キーで暗号化されている、ステップ；
   前記ハブの不具合を検出するステップ；及び
   前記エンクレーブからのデータであって前記コミットメント・トランザクションに基づくデータを利用して前記グループに対してフェイルセーフ活性化リクエストを発行するステップ；
   を有する方法。
2. 前記フェイルセーフ活性化リクエストは、前記ブロックチェーン・ネットワークのブロックチェーンに追加された最近のブロックのブロック番号を指定し、前記グループは、前記フェイルセーフ活性化リクエストで指定される前記ブロック番号に基づいて、及び前記ブロックチェーンに追加された最近のブロックの現在のブロック番号に基づいて、満了したと判断されるフェイルセーフ活性化リクエストを無視するように構成される、請求項１に記載の方法。
3. フェイルセーフ・モードは実行されていないこと、及び前記フェイルセーフ活性化リクエストは満了していることを決定するステップ；及び
   別のフェイルセーフ活性化リクエストを前記グループに対して発行するステップであって、前記別のフェイルセーフ活性化リクエストは前記ブロックチェーンに追加された新しい最近のブロックの新しいブロック番号を含む、ステップ；
   を含む請求項２に記載の方法。
4. 前記フェイルセーフ活性化リクエストを発行するステップは、前記ハブの不具合を検出したことに応答して、前記フェイルセーフ活性化リクエストをオンラインで自動的に送るステップを含む、請求項１−３のうち何れか１項に記載の方法。
5. 前記フェイルセーフ活性化リクエストは前記チャネルを閉鎖するために前記ノードにより提示される手数料を指定する、請求項１−４のうち何れか１項に記載の方法。
6. 前記フェイルセーフ活性化リクエストに応じて前記グループがサイドチェーンを配備した後、前記サイドチェーンにより他のノードと価値を交換するステップを更に含む請求項１−５のうち何れか１項に記載の方法。
7. 前記フェイルセーフ活性化リクエストは前記エンクレーブ内で生成され、前記エンクレーブ・パブリック・キーに関連するエンクレーブ・プライベート・キーを利用して署名される、請求項１−６のうち何れか１項に記載の方法。
8. 前記コミットメント・トランザクションを解読し、前記チャネルに関連する残高を決定し、違反救済トランザクションに関連する価値を決定するステップであって、前記価値は以前のコミットメント・トランザクションに関連する以前のシークレット値である、ステップを更に有する請求項１−７のうち何れか１項に記載の方法。
9. 前記フェイルセーフ活性化リクエストに応答して配備されたサイドチェーンのマイナーにサイドチェーン・トランザクションをブロードキャストするステップであって、前記サイドチェーン・トランザクションは価値を移転する、ステップを更に有する請求項１−８のうち何れか１項に記載の方法。
10. ハブとの１つ以上のチャネルに参加している１つ以上のノードにより発行された１つ以上のフェイルセーフ活性化リクエストを検出するステップであって、前記チャネルは、ブロックチェーン・ネットワークに関連する価値の取引のためのコミットメントが前記ブロックチェーン・ネットワークの外部でやり取りされることを許容し、前記フェイルセーフ活性化リクエストは、グループに関連するパブリック・キーでディジタル資産を制限するファンディング・トランザクションをブロードキャストすることにより以前にチャネルを開設したノードにより発行されている、ステップ；
    前記１つ以上のフェイルセーフ活性化リクエストが所定の基準を満足することを確認するステップ；及び
    前記１つ以上のチャネルを閉鎖するトランザクションに対する有効な署名を、前記グループの他のノードと協力して生成するステップ；
    を有する方法。
11. 前記フェイルセーフ活性化リクエストが所定の基準を満足することを確認するステップが、そのリクエストを発行する個々のノードの残高により重み付けされたフェイルセーフ活性化リクエストの数が閾値を超えていることを確認するステップを含む、請求項１０に記載の方法。
12. 前記フェイルセーフ活性化リクエストは、各々のフェイルセーフ活性化リクエストが生成されたときに前記ブロックチェーン・ネットワークの前記ブロックチェーンに追加された最近のブロックの個々のブロック番号を指定し、前記グループは、前記フェイルセーフ活性化リクエストで指定される前記ブロック番号に基づいて、及び前記ブロックチェーンに追加された最近のブロックの現在のブロック番号に基づいて、満了したと判断されるフェイルセーフ活性化リクエストを無視するように構成される、請求項１０又は１１に記載の方法。
13. 前記１つ以上のフェイルセーフ活性化リクエストが所定の基準を満足していることを確認した後であって前記有効な署名を協力して生成する前に、一時的なサイドチェーンを配備するステップであって、前記一時的なサイドチェーンは、価値が更に移転されることを許容し、１つ以上のチャネルを閉鎖する前記トランザクションはまた、前記サイドチェーンで転送される前記価値に基づいている、ステップを更に有する請求項１０、１１又は１２に記載の方法。
14. 実行されると請求項１−１３のうち何れか１項に記載の方法を実行するようにプロセッサを構築するコンピュータ実行可能命令を有するコンピュータ読み取り可能な記憶媒体。
15. インターフェース・デバイス；
    前記インターフェース・デバイスに結合されるプロセッサ；
    前記プロセッサに結合されるメモリであって、前記メモリは、実行されると請求項１−１３のうち何れか１項に記載の方法を実行するように前記プロセッサを構築するコンピュータ実行可能命令を保存している、メモリ；
    を有する電子デバイス。
16. 前記プロセッサは信頼される実行環境を含み、前記コンピュータ実行可能命令は前記信頼される実行環境で実行される、請求項１５に記載の電子デバイス。