JP6788875B2 - ブロック・チェーン間でデジタル資産を転送するシステム - Google Patents

Description

本開示は、ブロック・チェーン間でのデジタル資産の転送と関係し、特にパブリック・チェーンとサイドチェーンとの間で多種多様なデジタル資産を所定の統制ルールの下で転送する処理と関係する。

サイドチェーンとは、ビットコイン・ブロックチェーン等の既存のパブリック・チェーンに側鎖として併設されるブロック・チェーンである。以下、説明の便宜上、ビットコイン等のパブリック・チェーン側を親ＢＣ、側鎖となるサイドチェーン側を側鎖ＢＣと呼ぶ。親ＢＣと側鎖ＢＣとの間での相互作用の一例として、双方向ペグとは、固定の交換レートまたは決定論的な交換レートで、親ＢＣ上の暗号資産を側鎖ＢＣに転送し、その後に元の親ＢＣに戻すためのチェーン間移転機構を指す。従って、双方向ペグ可能な側鎖ＢＣでは、親ＢＣから暗号資産をインポートし、さらに元の親ＢＣに戻すことができる（下記の特許文献１を参照）。

ところで、側鎖ＢＣ側へのペグイン処理の実行の際には、コンセンサス・ルール適用処理に伴って様々な処理の実行が必要となり、これらの処理には、トランザクションの承認や親ＢＣ側でのエクスポートすべき暗号資産のロック処理とロック解除などが含まれる。しかしながら、これらの処理の実行過程において、信頼性が保証されていない不特定のノードがコンセンサス・ルール適用処理に関与できてしまう点が考えられる。

そこで、下記の特許文献２および非特許文献１では、複数の承認者による連合体を組織し、この「承認者の連合」がトランザクション承認などの権限を専有する仕組みである「Federated Peg方式」が開示されている。この方式では、トランザクション承認やエクスポートすべき暗号資産のロック処理などを含む一連の処理を上述した「承認者の連合」によって実現される承認機構に集約し、ＢＣＮ（Blockchain Network）内の不特定のノードに関与させない。こうして、「Federated Peg方式」では、信頼性が保証されていない不特定のノードがコンセンサス・ルール適用処理に関与できなくし、他のノードの計算処理負荷やブロック・チェーン全体にわたる計算量を削減することができる。

特表２０１８−５３３１０３号公報 米国出願公開ＵＳ２０１６／０３３００３４号公報

Block Stream社発行ホワイトペーパー"Enabling Blockchain Innovations with Pegged Sidechains"、Adam Back, Matt Corallo, Luke Dashjr, Mark Friedenbach, Gregory Maxwell, Andrew Miller, Andrew Poelstra, Jorge Timon, and Pieter Wuille,

既存のサイドチェーン技術の実装例においては、ＵＴＸＯ（Unspent Transaction Output）に対応したビットコインを親ＢＣとして側鎖ＢＣとの間で双方向ペグを実行する実装例しかない。つまり、双方向ペグの仕組みは、親ＢＣ側ではUTXO非対応のビットコインを取引するブロック・チェーンでは実装が困難である。同様に、双方向ペグの仕組みは、ビットコイン以外の任意のアルトコイン（Alt Coin）又は任意のトークンを取引可能なブロック・チェーンにおいても実装が困難である。

また、双方向ペク可能なサイドチェーンにおける別の問題点として、双方向ペグによりチェーン間で転送される暗号資産の種類またはペグイン／アウトの要求を送出した要求元が法的、思想的および戦略的な観点から望ましくない場合があり得る。この問題に対処するには、特定の利用者が特定の暗号資産をペグイン／ペグアウトしようとする試みを認容すべきか否かを一定の統制ルールに従って管理することが必要となる。さらに、上記統制ルールに基づく管理を実現するには、ペグイン／アウトの対象となる暗号資産の種別（通貨種別）が認容可能な種別の暗号資産であるか否か又はペグイン／アウトを要求した要求元が認容可能な利用者であるか否かを具体的に判別する仕組みも必要になる。

上記問題点に鑑み、本発明の幾つかの実施形態では、ＵＴＸＯ非対応のビットコインまたはビットコイン以外の任意の暗号資産を取引可能なブロック・チェーンとの間で暗号資産の転送を実現可能な仕組みを得ることを目的とする。また、上記問題点に鑑み、本発明の幾つかの実施形態では、特定の利用者が特定の暗号資産をブロック・チェーン間で転送しようとする試みを認容すべきか否かを一定の統制ルールに従って管理することが可能な仕組みを得ることを目的とする。

（１）本発明の幾つかの実施形態に係るシステムは、送金トランザクションを介したデジタル情報の送受信により資産価値を流通させることが可能な一種類以上の電磁的記録を含むデジタル資産を、ブロック・チェーン間で転送するために、
第１ブロック・チェーン上で所有者が有する第１デジタル資産を第２ブロック・チェーン上に前記所有者が有する第１アドレスにブロック・チェーン間転送により移転する要求を送出する所有者端末と、
多数決による意思決定を行う２つ以上の承認者端末により形成され、第１基準に基づいて前記承認者端末間の互選によりメンバーシップを更新するように構成された連合体と、
を備え、前記要求を検知した前記連合体内の少なくとも一つの前記承認者端末は、
前記多数決による意思決定を前記連合体に開始させ、所定の許認可基準に基づいて前記ブロック・チェーン間転送を許可可能と判断した場合に、前記第１デジタル資産と等価な経済価値を有する第２デジタル資産を新規に発行し、前記ブロック・チェーン間転送を実行し、
前記第２デジタル資産は、デジタル資産の種別に依存せずにトランザクション承認および残高の検証を実行可能な汎用性を有する分散合意形成プロトコルを用いて前記第２ブロック・チェーン側での取引が可能な独自トークンとして発行される、ことを特徴とする。

（２）本発明の別の実施形態では、上記（１）のシステムにおいて、前記所有者端末は、前記承認者端末から前記第１ブロック・チェーン上で指定された第２アドレスに前記第１デジタル資産を転送する第１トランザクションを同報送信し、
前記連合体を構成する少なくとも一つの前記承認者端末は、
前記第２アドレスにて前記第１トランザクションを受信すると、前記所有者端末から通知された前記第１アドレスを送金先とする前記ブロック・チェーン間転送の許否を前記連合体内の前記多数決により決定する投票プロセスを前記連合体に開始させる通信手順を実行し、
前記ブロック・チェーン間転送を許可する場合、前記第１デジタル資産と等価な経済価値を有する前記第２デジタル資産を新規に発行し、前記第２デジタル資産を前記第１アドレスに転送する第２トランザクションを前記第２ブロック・チェーンへと同報送信するように構成される、
ことを特徴とする。

（３）本発明のさらに別の実施形態では、上記（２）のシステムにおいて、前記所有者が前記第１ブロック・チェーン上に有する第３アドレスを送金先として、前記第２デジタル資産を前記第１ブロック・チェーンに戻すブロック・チェーン間転送を求める要求を前記所有者端末から受信した前記承認者端末は、
前記第２デジタル資産を将来にわたって事実上使用不可能にするための資産凍結アドレスを前記第２ブロック・チェーン上に生成し、前記第２デジタル資産を前記資産凍結アドレスに転送する第３トランザクションを同報送信し、
前記資産凍結アドレスにおいて前記第３トランザクションが受信されると、前記所有者端末から通知された前記第３アドレスを送金先として、前記独自トークンのブロック・チェーン間転送を行う第４トランザクションを生成し、
前記連合体内の前記多数決に基づく意思決定のために前記投票プロセスを実行した結果、前記第３トランザクションを許可する場合、前記第３トランザクションを介して前記独自トークンを前記第３アドレスに転送することで、前記第２デジタル資産を前記第１ブロック・チェーンに戻すように構成される、ことを特徴とする。

以上より、本発明の幾つかの実施形態に係るブロック・チェーン間での暗号資産転送方法により克服することができる従来の技術的課題として、以下のようなものが考えられる。上述した「Federated Peg方式」では、承認者の連合体におけるメンバーの選出は、ブロック・チェーンのエコシステム内における健全な統治や信頼性（高いセキュリティー）、公正性の確保を念頭において判断される。具体的には、上記メンバーの選出は、当該エコシステム内における健全な統治のための政策（または統治戦略）や政治的なパワーバランスを強く意識して決定される。

その一方で、ペグイン要求やペグアウト要求を認めるか却下するかの判断基準は、ブロック・チェーン・システムがサポートする機能的な制約（ＵＴＸＯやＳＰＶ証明を実行する機能をサポートしているか否か）や特定の仮想通貨の双方向ペグを機能的にサポートするか否か（双方向ペグの実行時に取り扱い可能な暗号通貨の種類）というような技術的制限によって影響を受ける場合が多々ある。例えば、側鎖ＢＣ側でのＵＴＸＯを用いた残高の検証およびＳＰＶ証明を用いた分散合意形成処理（ブロックの承認など）は、ビットコインのブロック・チェーン・システムでしか実現することができない。逆にアカウント・ベースの分散合意形成処理は、任意のＡｌｔ Ｃｏｉｎブロック・チェーン・システムで実現可能である。また、スマートコントラクト等の機能は、現状では、Ｅｔｈｅｒｅｕｍのような一部のブロック・チェーン・システムでしか実装の実績が無い。

そこで、そのような技術的制限を除去し、政策的な判断基準や安全面、防犯面を考慮した統制ルールだけに基づいてペグイン要求やペグアウト要求を認めるか却下するかの決定を可能とすれば、以下のような利点がある。すなわち、政策または統制ルールを中心に承認者を選定するようにすれば、ペグイン要求やペグアウト要求の許認可基準と承認者連合体のメンバー選出基準との整合性を図ることができる。その結果、ペグイン要求やペグアウト要求の許認可基準をどのように決めるべきかを方向付ける指針が変化する都度、それに合わせて連合体のメンバー選出基準を適応させていくことが可能となる。

以上より、本発明の幾つかの実施形態によれば、ＵＴＸＯ非対応のビットコインまたはビットコイン以外の任意の暗号資産を取引可能なブロック・チェーンとの間で暗号資産の転送を実現することができる。また、本発明の幾つかの実施形態によれば、特定の利用者が特定の暗号資産をブロック・チェーン間で転送しようとする試みを認容すべきか否かを複数の観点に基づく統制ルールに従って管理する仕組みを実現することができる。

その結果、政策または統制ルールを中心に承認者を選定することで、ペグイン要求やペグアウト要求の許認可基準と承認者の連合体のメンバー選出基準との整合性を図ることができる。これにより、ペグイン要求やペグアウト要求の許認可基準をどのように決めるべきかを方向付ける指針が変化する都度、それに合わせて連合体のメンバー選出基準を適応させていくことが可能となる。

本発明の幾つかの実施形態に従い、ペグイン要求の各々に対してペグイン用アドレスを割り当て、新規発行した独自トークンにより親ＢＣから側鎖ＢＣへと暗号資産を転送するシナリオを例示する図である。 本発明の幾つかの実施形態に従い、承認者の連合体が、利用者端末からペグイン要求またはペグアウト要求を受け付け、当該要求の許否を判定するまでのシナリオを例示する図である。 本発明の幾つかの実施形態に従い、承認者の連合体にメンバーとして属する各々の承認者により投票が行われ、連合体による意思決定がなされるシナリオを例示する図である。 本発明の幾つかの実施形態に従い、承認者の連合体にメンバーとして属する各々の承認者により投票が行われ、連合体による意思決定がなされるシナリオを例示する図である。 本発明の幾つかの実施形態に従い、承認者の連合体にメンバーとして属する各々の承認者により投票が行われ、連合体による意思決定がなされるシナリオを例示する図である。 本発明の幾つかの実施形態に従い、承認者の連合体のメンバーシップを更新するシナリオを例示する図である。 本発明の幾つかの実施形態に従い、承認者の連合体のメンバーシップを更新するシナリオを例示する図である。 本発明の幾つかの実施形態に従い、ブロック・チェーン間で暗号資産を転送する方法が実行される基盤となるブロック・チェーン・システムを例示する図である。 本発明の幾つかの実施形態に従い、ブロック・チェーン間で暗号資産を転送する方法が実行される基盤となるブロック・チェーン・システムを例示する図である。 本発明の幾つかの実施形態に従い、ブロック・チェーン間で暗号資産を転送する方法が実行される基盤となるブロック・チェーン・システムを例示する図である。 本発明の幾つかの実施形態に従い、ブロック・チェーン間で暗号資産を転送する方法が実行される基盤となるブロック・チェーン・システムを例示する図である。 本発明の幾つかの実施形態に従い、ブロック・チェーン間で暗号資産を転送する方法が実行される基盤となるブロック・チェーン・システムを例示する図である。 本発明の幾つかの実施形態に係る双方向ペグの機能をソフトウェアおよびハードウェアにより実装するコンピュータ・システムを例示する図である。 本発明の幾つかの実施形態に係る双方向ペグの機能を実装するプラットフォームのアーキテクチャを例示する図である。 本発明の幾つかの実施形態と対比すべき比較例として、従来型の双方向ペグ可能なサイドチェーンとの間での暗号資産の転送シナリオを例示する図である。 本発明の幾つかの実施形態と対比すべき比較例として、従来型の双方向ペグ可能なサイドチェーンとの間での暗号資産の転送シナリオを例示する図である。

＜１＞従来技術（Federated Peg方式）について
本発明の幾つか実施形態に従い、ブロック・チェーン間での暗号資産の転送機構について詳しく述べる前に、本発明の幾つかの実施形態に係る上記転送機構との対比を目的として、図１５のフロー図を参照しながら、従来の「Federated Peg方式」について述べる。非特許文献１によれば、従来の「Federated Peg方式」では、暗号資産のブロック・チェーン間転送のための処理プロセスは、図１５のフローに沿って実行される。以下、できるだけ具体的な説明をするために、図１５に示す処理プロセスは、図１６（ａ）に示すようなブロック・チェーン構造の上で実行されるものと仮定する。

図１６（ａ）を参照すると、このブロック・チェーン構造では、親ＢＣ（図１６（ａ）に示すＭｃｈ）に２つの側鎖ＢＣ（図１６（ａ）に示すＳＣ１とＳＣ２）が併設されている。親ＢＣ（Ｍｃｈ）は、複数のブロックＮ_ｍ（ｑ）（１≦ｑ≦Ｑ）の連鎖として構成される。また、２つの側鎖ＢＣ（ＳＣ１，ＳＣ２）はそれぞれ複数のブロックＮ_Ｓ１（ｐ）（１≦ｐ≦Ｐ）の連鎖として構成されＮ_Ｓ２（ｒ）（１≦ｒ≦Ｒ）の連鎖として構成される。

従来の「Federated Peg方式」によれば、送金トランザクション処理によってデジタル資産ＶＣ１をブロック・チェーン間で転送する処理が、複数の承認者端末Ｆｍ［１］〜Ｆｍ［３］により組織された連合体による統括の下で実行される。上記デジタル資産ＶＣ１は、情報ネットワーク内での送受信により資産価値を流通させることが可能な一種類以上の電磁的記録を含み、親ＢＣ（Ｍｃｈ）から側鎖ＢＣ（図１５に示すＳＣ）に向けたブロック・チェーン間転送は、図１５に示すフローに沿って以下のように実行される。なお、図１３に示す処理フローでは、図１４（ａ）に示す親ＢＣ（Ｍｃｈ）から側鎖ＢＣ（ＳＣ１）に第１デジタル資産ＶＣ１が転送されるものとする。

まず、図１５に示す処理フローは、ステップＳＴ１１から開始し、利用者端末は、親ＢＣ（Ｍｃｈ）内において、第１デジタル資産（VC１）を親ＢＣ（Ｍｃｈ）の出力端点に送信するトランザクションを生成する。続いて、処理フローはステップＳＴ１２に進み、第１デジタル資産（VC１）を出力端点に送信するトランザクションを承認者端末Ｆｍ［ｘ］が受信すると、第２デジタル資産ＶＣ２は施錠処理される。これは、図１６（ｂ）に示すように、ペグインしようとする暗号資産ＶＣ１をロックする処理に相当する。その上で、承認者端末Ｆｍ［ｘ］により第１デジタル資産（ＶＣ１）のハッシュ情報が生成される（”ＳＰＶ証明”の生成に相当する）。このＳＰＶ証明の生成は、第１デジタル資産（ＶＣ１）を認証するのに十分な第１計算量を費やして実行される。これにより、ペグイン対象となるデジタル資産を親ＢＣ（Ｍｃｈ）から側鎖ＢＣ（ＳＣ１）に移転するブロック・チェーン間転送の実際のプロセスが開始される。

続いて、側鎖ＢＣ（ＳＣ１）上の検証サーバにより、前記ハッシュ情報が検証され、前記検証の結果に応じて、承認者端末Ｆｍ［ｘ］により、第１デジタル資産ＶＣ１と等しい資産価値を有する第２デジタル資産ＶＣ２が側鎖ＢＣ（ＳＣ１）上に生成される。続いて、処理フローはステップＳＴ１３に進み、第１デジタル資産（ＶＣ１）の認証が上書きされるイベント（”Re-organization”）の発生の有無を承認者端末Ｆｍ［ｘ］が第１待機期間にわたって監視する。この処理は、第２デジタル資産（ＶＣ２）をロック状態で保持したまま実行され、監視対象となる上記イベントは、”Re-organization”と呼ばれる。

”Re-organization”は、承認者端末Ｆｍ［ｘ］以外のノードが、第２計算量を費やして第１デジタル資産（ＶＣ１）のハッシュ情報を生成し、なおかつ、上記第２計算量が、ステップＳＴ１２にてＳＰＶ証明を生成した際に費やした第１計算量を上回ることにより生じる。そして、”Re-organization”が生じると、承認者端末Ｆｍ［ｘ］以外のノードにより、承認者端末Ｆｍ［ｘ］が有していたトランザクション認証権限が奪取されることとなる。

この第１待機期間の間に、上記第１待機期間の経過後に、上記イベントが生起していなければ、承認者端末Ｆｍ［ｘ］により、施錠状態の第２デジタル資産（ＶＣ２）を解錠して側鎖ＢＣ（ＳＣ１）上で取引可能な状態とする。すなわち、図１５に示す”Contest Period”の満了まで“Re-organization”によるトランザクション認証権限の奪取が無ければ、承認者端末Ｆｍ［ｘ］は、第２デジタル資産（ＶＣ２）を側鎖ＢＣ（ＳＣ１）上で流通可能な状態とする。第２デジタル資産（ＶＣ２）が側鎖ＢＣ（ＳＣ１）上で流通可能な状態となった後に、図１５に示す処理フローは、ステップＳＴ１４に進む。ステップＳＴ１４では、側鎖ＢＣ（ＳＣ１）内で第２デジタル資産ＶＣ２を送金する送金トランザクションが実行される。

一方、ペグイン済みの暗号資産ＶＣ２を親ＢＣ（Ｍｃｈ）側へとペグアウトする処理が開始すると、図１５に示す処理フローはステップＳＴ１５に進む。ステップＳＴ１５では、第２待機期間（Confirmation Period）にわたって”Re-organization”の発生を監視する。これと並行して、第２デジタル資産（ＶＣ２）を側鎖ＢＣ（ＳＣ１）の出力端点に送信するトランザクションが生成され、第２デジタル資産ＶＣ２は施錠処理される。続いて、図１５に示す処理フローはステップＳＴ１６に進み、親ＢＣ（Ｍｃｈ）に対してペグアウトすべき暗号資産ＶＣ２を対象に、承認者端末Ｆｍ［ｘ］により第２デジタル資産（ＶＣ２）のハッシュ情報が生成される（”ＳＰＶ証明”の生成に相当する）。これにより、ペグイン済みのデジタル資産を側鎖ＢＣ（ＳＣ１）から親ＢＣ（Ｍｃｈ）に戻すブロック・チェーン間転送の実際のプロセスが開始される。

続いて、図１５に示す処理フローはステップＳＴ１７に進み、親ＢＣ（Ｍｃｈ）上の検証サーバにより、前記ハッシュ情報が検証されると、イベント（”Re-organization”）の発生の有無を承認者端末Ｆｍ［ｘ］が第３待機期間（Contest Period）にわたって監視する。図１３に示すステップＳＴ１８において第２待機期間の満了前に承認者端末Ｆｍ［ｘ］以外のノードによりトランザクション認証権限の奪取を引き起こすRe-organizationが発生すると、ステップＳＴ１９において第３待機期間は異常中断する。ここで、承認者端末Ｆｍ［ｘ］によりトランザクション承認権限を奪い返すRe-organization（図１５に示すステップＳＴ２０）がさらに引き起こされると、異常中断していた第３待機期間が再開される（ステップＳＴ２１において）。

続いて、第３待機期間が正常に満了すると、ペグアウトされた第１デジタル資産ＶＣ１が親ＢＣ（Ｍｃｈ）上で流通可能な状態とされる。つまり、図１６（ｃ）に示すように、ペグイン済みの暗号資産ＶＣ２を親ＢＣ（Ｍｃｈ）側へとペグアウトするため、暗号資産ＶＣ２をロック解除して側鎖ＢＣ（ＳＣ１）上でリリースする。最後に、図１５に示す処理フローはステップＳＴ２２に進み、親ＢＣ（Ｍｃｈ）内で第１デジタル資産ＶＣ１を送金する送金トランザクションが実行される。

以上より、ＳＰＶ証明に基づくペグイン／ペグアウトのための対称型双方向ペグ（Symmetric two-way peg SPV peg）を使ったアプローチでは、親ＢＣのコインを側鎖ＢＣ側に転送する。そのため、親ＢＣのコインを親チェーン上の特殊なOutputに送ってロックし、ロックされたコインをロック解除できるのはサイドチェーン上のＳＰＶ証明のみである。その際、２つのブロック・チェーンを同期させるには、２つの待機期間”Contest Period”と”Confirmation Period”を定義する必要がある。

既存のサイドチェーン技術の実装例においては、UTXO（Unspent Transaction Output）に対応したビットコインを親ＢＣとして側鎖ＢＣとの間で双方向ペグを実行する実装例しかない。つまり、双方向ペグの仕組みは、親ＢＣ側ではUTXO非対応のビットコインを取引するブロック・チェーンでは実装が困難である。同様に、双方向ペグの仕組みは、ビットコイン以外の任意のアルトコイン（Alt Coin）又は任意のトークンを取引可能なブロック・チェーンにおいても実装が困難である。従って、ブロック・チェーン間転送を使用とするデジタル資産の種別（通貨種別）や転送先のアドレスによっては、ペグインやペグアウトができない場合があり得る。

また、従来の「Federated Peg方式」では、信頼性が保証されていない不特定のノードがコンセンサス・ルール適用処理に関与できてしまうという問題を解決するまたは軽減するという効果が期待される。しかしながら、この問題を従来の「Federated Peg方式」で解決しようとすると、ＢＣＮ（Block-Chain Network）全体から複数の承認者をどのように選出することにより承認者の連合体を形成するかという課題が新たに生じる。以上より、「Federated Peg方式」において、複数の承認者端末Ｆｍ［ｉ］（１≦ｉ≦Ｉ）をどのように選出して承認者端末の連合体を形成すれば、上記問題を最も効果的に解決であるかを考えなければならない。

さらに、双方向ペク可能なサイドチェーンにおける別の問題点として、双方向ペグによりチェーン間で転送される暗号資産の種類またはペグイン／アウトの要求を送出した要求元が法的、思想的および戦略的な観点から望ましくない場合があり得る。この問題に対処するには、特定の利用者が特定の暗号資産をペグイン／ペグアウトしようとする試みを認容すべきか否かを一定の統制ルールに従って管理することが必要となる。さらに、上記統制ルールに基づく管理を実現するには、ペグイン／アウトの対象となる暗号資産の種別（通貨種別）が認容可能な種別の暗号資産であるか否か又はペグイン／アウトを要求した要求元が認容可能な利用者であるか否かを具体的に判別する仕組みも必要になる。

上記問題点に鑑み、本発明の幾つかの実施形態では、UTXO非対応のビットコインまたはビットコイン以外の任意の暗号資産を取引可能なブロック・チェーンとの間で暗号資産の転送を実現可能な仕組みを得ることを目的とする。また、上記問題点に鑑み、本発明の幾つかの実施形態では、特定の利用者が特定の暗号資産をブロック・チェーン間で転送しようとする試みを認容すべきか否かを一定の統制ルールに従って管理することが可能な仕組みを得ることを目的とする。

また、本発明の幾つかの実施形態では、信頼性が保証されていない不特定のノードが分散合意形成処理に関与できないようにするという目的の達成を支援する仕組みを設ける。具体的には、状況に応じて調整可能な選出基準に基づいて複数の承認者Ｆｍ［ｉ］（１≦ｉ≦Ｉ）を選出して連合体を形成する仕組みを設け、選出された承認者Ｆｍ［ｉ］（１≦ｉ≦Ｉ）以外のノードが分散合意形成処理に関与できないようにする。

＜２＞本発明の実施形態
次に、本発明の幾つかの実施形態に従って図１〜図７に示すように構成された例示的なシステムにおいて、構成と動作を詳しく説明する。続いて、本発明の実施形態に関して図１〜図７に示す例示的なシステムと上述した従来式の「Federated Peg方式」との対比検討を交えながら、本発明の幾つかの実施形態に係るシステムの技術的効果について述べる。なお、従来式の「Federated Peg方式」と区別するため、図１〜図７に示す本発明の実施形態に従ってデジタル資産をブロック・チェーン間で転送する仕組みを実現したシステムを、「連合体ゲートウェイ（Federated Gateway）システム」と呼ぶこととする。

以下、図１〜図７を用いて本発明の実施形態に係る「連合体ゲートウェイ（Federated Gateway）システム」について説明するが、以下の二つの点については、従来の「Federated Peg方式」とほぼ同様であるため、詳しい説明は省略する。まず、第１点として、「連合体ゲートウェイ（Federated Gateway）システム」においても、分散合意形成処理のうち、当業者の技術常識に鑑みて必要と考えられる一連の処理は当然に実行される。これら一連の処理には、「Proof of Workの生成」、「トランザクション承認」、「親ＢＣ側でのエクスポートすべき暗号資産のロック処理とロック解除」などが含まれる。また、第２点として、「連合体ゲートウェイ（Federated Gateway）システム」においても、上記の一連の処理を「承認者の連合体」による承認機構に集約して実行させる構成は従来の「Federated Peg方式」と同様である。

図１〜図５は、本発明の幾つかの実施形態に従い、デジタル資産をブロック・チェーン間で転送するように構成されたシステムの例を示している。ここで言うデジタル資産ＶＣ［ａ］〜ＶＣ［ｄ］とは、一種類以上の電磁的記録を含んで構成され、送金トランザクション処理を介した送受信により資産価値をネットワーク上で流通させることが可能なデジタル情報を指して言う。以下、ブロック・チェーン間転送により、所有者が親ＢＣ（Ｍｃｈ）上に所有するデジタル資産ＶＣ［ａ］〜ＶＣ［ｄ］を側鎖ＢＣ（ＳＣ）へと移転し、その後、側鎖ＢＣ（ＳＣ）から親ＢＣ（Ｍｃｈ）上に戻すシナリオに沿って一連の処理が実行されることを前提に説明を行う。

本発明の幾つかの実施形態に従い、図１〜図５に示す「連合体ゲートウェイ（Federated Gateway）システム」は、多数決による意思決定を行う２つ以上の承認者端末Ｆｍ［ｉ］（１≦ｉ≦Ｉ）により形成され、第１基準ＣＲ１に基づいて承認者端末Ｆｍ［ｉ］（１≦ｉ≦Ｉ）間の互選によりメンバーシップを更新するように構成された連合体Ｆｅｄを備える。さらに、図１〜図５に示すシステムにおいては、第１デジタル資産ＶＣ［ａ］〜ＶＣ［ｄ］をそれぞれ所有する４人の所有者Ｕ［ａ］〜Ｕ［ｄ］が情報端末（所有者端末）ＵＴ［ａ］〜ＵＴ［ｄ］から通信回線を介してシステムにアクセスしている。

第１デジタル資産ＶＣ［ａ］〜ＶＣ［ｄ］は、基軸通貨としてブロック・チェーン上で広く流通している仮想通貨またはその他のトークンを含む暗号資産であってもよい。例えば、図１〜図５に示す例においては、第１デジタル資産ＶＣ［ａ］〜ＶＣ［ｄ］は、それぞれ「ビットコイン」、「Ｃｏｕｎｔｅｒｐａｒｔｙ」、「Ｅｔｈｅｒｅｕｍ」および「ＴＵＳＤ」である。このうち、「ビットコイン」は、UTXOに対応したビットコインであり、「Ｃｏｕｎｔｅｒｐａｒｔｙ」、「Ｅｔｈｅｒｅｕｍ」および「ＴＵＳＤ」は、アカウント・ベースの分散合意形成プロトコルに対応した暗号通貨である。

（２−１）ペグイン段階の処理
以下、親ＢＣ（Ｍｃｈ）上の第１デジタル資産ＶＣ［ａ］〜ＶＣ［ｄ］を側鎖ＢＣ（ＳＣ）側に移転（ペグイン）する仕組みについて図１〜図５を参照しながら説明した後、側鎖ＢＣ（ＳＣ）側に移転したデジタル資産を親ＢＣ（Ｍｃｈ）側に戻す（ペグアウト）処理について説明する。また、説明を簡単にするために、所有者端末ＵＴ［ａ］からの要求に応じて第１デジタル資産ＶＣ［ａ］をブロック・チェーン間転送により移転する場合を例にとって説明するが、所有者端末ＵＴ［ｂ］〜ＵＴ［ｄ］からの要求に応じて第１デジタル資産ＶＣ［ｂ］〜ＶＣ［ｄ］をブロック・チェーン間転送により移転する場合も同様である。

まず、図１に示すシステムの動作について説明すると、第１デジタル資産ＶＣ［ａ］の所有者Ｕ［ａ］は、端末ＵＴ［ａ］を操作して、第１デジタル資産ＶＣ［ａ］をブロック・チェーン間転送により親ＢＣ（Ｍｃｈ）から側鎖ＢＣ（ＳＣ）上に移転する要求ＲＱを送出する。その後、この要求ＲＱは、図２を参照しながら詳しく後述する待ち行列（キューイング機構）ＰＣＭと関連付けられたアドレスＱＡに着信することとなる。すると、この要求ＲＱがアドレスＱＡに着信したことを示すイベントが、連合体Ｆｅｄ内の承認者端末Ｆｍ［１］〜Ｆｍ［３］の何れか一つ以上により検出される（図２に示すステップＳＴ０１）。以下、説明を簡単にするために、連合体Ｆｅｄを構成する承認者端末Ｆｍ［ｉ］（１≦ｉ≦Ｉ）の中で、この要求ＲＱの着信を検出した承認者端末をＦｍ［ｘ］と表記する。

ここで、上記要求ＲＱをアドレスＱＡに送出する際に、端末ＵＴ［ａ］は、側鎖ＢＣ（ＳＣ）上に所有者Ｕ［ａ］が有する第１アドレス（図５に示すＷＡ［ａ，１］）を送金先として指定する送金先指定処理を行う。ここで、図５に示すように、親ＢＣ（Ｍｃｈ）から側鎖ＢＣ（ＳＣ）へのブロック・チェーン間転送を行う際の送金先となる第１アドレスＷＡ［ａ，１］は、側鎖ＢＣ（ＳＣ）上の入金先として所有者Ｕ［ａ］が有しているウォレット・アドレス（図５）である。その上で、この送金先指定処理の一例として、所有者端末ＵＴ［ａ］は、以下の動作を実行するようにしてもよい。

まず最初に、親ＢＣ（Ｍｃｈ）上に所有者Ｕ［ａ］が有する第１デジタル資産ＶＣ［ａ］を承認者端末Ｆｍ［ｘ］へと転送する第１トランザクションＴｘ［ａ，１］（図２）を生成する。続いて、第１トランザクションＴｘ［ａ，１］に対して、第１アドレスＷＡ［ａ，１］を側鎖ＢＣ（ＳＣ）上の送金先として埋め込むことで、ブロック・チェーン間転送における送金先として第１アドレスＷＡ［ａ，１］を指定する。最後に、この第１トランザクションＴｘ［ａ，１］を連合体Ｆｅｄに属する承認者端末Ｆｍ［ｘ］が受信すると、承認者端末Ｆｍ［ｘ］に第１アドレスＷＡ［ａ，１］が通知されることとなる（図５に示すＰ１）。

また、例示的な実施形態では、所有者端末ＵＴ（ａ）が第１トランザクションＴｘ［ａ，１］（図２）を生成した後に、第１トランザクションＴｘ［ａ，１］を承認者端末Ｆｍ［ｘ］に受信させる処理は、以下のように実行されてもよい。まず、連合体Ｆｅｄを構成する少なくとも一つの承認者端末Ｆｍ［ｘ］は、親ＢＣ（Ｍｃｈ）上の第１デジタル資産ＶＣ［ａ］を側鎖ＢＣ（ＳＣ）上に移転する要求ＲＱが所有者端末ＵＴ（ａ）から送出され、アドレスＱＡに着信したことを検出する。続いて、承認者端末Ｆｍ［ｘ］は、所有者Ｕ［ａ］に固有の第２アドレス（図１に示す一時預金用ウォレット・アドレスＩＡ［ａ］）を親ＢＣ（Ｍｃｈ）上に作成して所有者端末ＵＴ［ａ］に割り当てる（図１に示すステップＳＴ００）。所有者端末ＵＴ［ａ］は、連合体Ｆｅｄを構成する承認者端末Ｆｍ［ｘ］に要求ＲＱを送出した後に、第２アドレスＩＡ［ａ］を割り当てられたことを検知すると、第２アドレスＩＡ［ａ］を宛先として第１トランザクションＴｘ［ａ，１］を同報送信する。

なお、第２アドレスＩＡ［ａ］は、ブロック・チェーン間転送の対象となる第１デジタル資産ＶＣ［ａ］をロックされた状態のまま預かっておく場所である。通常の場合、第２アドレスＩＡ［ａ］では、第１デジタル資産ＶＣ［ａ］が側鎖ＢＣ（ＳＣ）上へ転送され、側鎖ＢＣ（ＳＣ）から親ＢＣ（Ｍｃｈ）側に戻されるまでの間、第１デジタル資産ＶＣ［ａ］が使用不可の状態で保持される。ただし、以下において図２および図３を用いて詳しく述べるように、承認者端末Ｆｍ［ｉ］（１≦ｉ≦ｍ）の連合体Ｆｅｄは、所有者端末ＵＴ［ａ］から要求された上記ブロック・チェーン間転送を許可しないと決定する場合がある。この場合には、ブロック・チェーン間転送を試みる対象であった第１デジタル資産ＶＣ［ａ］は、第２アドレスＩＡ［ａ］への返金処理の対象となり、返金処理の完了後には、第１デジタル資産ＶＣ［ａ］はロックが解除されて再び使用可能となる。従って、上記要求ＲＱは、ブロック・チェーン間転送の対象となるデジタル資産を保持する一次預金用アドレスの割り当てを承認者端末Ｆｍ［ｘ］に求めるアドレス割り当て要求であると解釈することも可能である。

こうして、第１トランザクションＴｘ［ａ，１］は、承認者端末Ｆｍ［ｘ］によって親ＢＣ（Ｍｃｈ）上に割り当てられた第２アドレスＩＡ［ａ］に向けて第１デジタル資産ＶＣ［ａ］を転送する。他の所有者Ｕ［ｂ］〜Ｕ［ｄ］が所有する第１デジタル資産ＶＣ［ｂ］〜ＶＣ［ｄ］のブロック・チェーン間転送を要求する場合についても上記と同様の手順が実行される。すなわち、承認者端末Ｆｍ［ｘ］によって親ＢＣ（Ｍｃｈ）上に作成された第２アドレスＩＡ［ｂ］〜ＩＡ［ｄ］が所有者端末ＵＴ［ｂ］〜ＵＴ［ｄ］に割り当てられる。最後に、所有者端末ＵＴ［ｂ］〜ＵＴ［ｄ］が生成した第１トランザクションＴｘ［ｂ，１］〜Ｔｘ［ｄ，１］により第２アドレスＩＡ［ｂ］〜ＩＡ［ｄ］に向けて第１デジタル資産ＶＣ［ｂ］〜ＶＣ［ｄ］をそれぞれ転送する。

上記要求ＲＱの着信を検知した連合体Ｆｅｄ内の少なくとも一つの承認者端末Ｆｍ［ｘ］は、第２アドレスＷＡ［２］にて第１トランザクションＴｘ［ａ，１］を受信すると、所有者端末ＵＴ［ａ］から通知された第１アドレスＷＡ［１］を送金先として識別する。続いて、承認者端末Ｆｍ［ｘ］は、第１デジタル資産ＶＣ［ａ］を側鎖ＢＣ（ＳＣ）に向けて移転させるブロック・チェーン間転送を許可すべきか否かを決定する投票プロセスを開始するための手順を起動する。具体的には、承認者端末Ｆｍ［ｘ］は、ブロック・チェーン間転送を許可すべきか否かを連合体Ｆｅｄ内の多数決により意思決定する投票プロセスを連合体Ｆｅｄに開始させる通信手順を実行する。

所有者端末ＵＴ［ａ］から第１トランザクションＴｘ［ａ，１］を受信した承認者端末Ｆｍ［ｘ］により、ブロック・チェーン間転送の許否を連合体Ｆｅｄ内の多数決により決定する投票プロセスが開始されると、まず、連合体Ｆｅｄ内にて投票に参加するメンバーの選出が行われる。具体的には、上記投票プロセスが開始されると、第１基準ＣＲ１に基づいて上記投票プロセスに参加する他の複数の承認者端末ＵＴ［ｉ］（１≦ｉ≦ｍ）を選出する選出プロセスが開始される（図２に示すステップＳＴ０３）。図２に示す例においては、承認者端末Ｆｍ［ｉ］（１≦ｉ≦ｍ）を選出する選出プロセスは、以下のように実施されてもよい。

図２を参照すると、第１トランザクションＴｘ［ａ，１］を受信した承認者端末Ｆｍ［ｘ］は、投票に参加するのを待っている承認者端末Ｆｍ［ｊ］（１≦ｊ≦Ｍ）の中から以下の手法により投票に参加させる承認者端末Ｆｍ［ｉ］（１≦ｉ≦ｍ）を選出する。例えば、承認者端末Ｆｍ［ｘ］は、着信した第１トランザクションＴｘ［ａ，１］を第１基準ＣＲ１に基づいて審査する。続いて、承認者端末Ｆｍ［ｘ］は、着信した第１トランザクションＴｘ［ａ，１］を審査した結果に基づいて複数の承認者端末Ｆｍ［ｊ］（１≦ｊ≦Ｍ）の中から連合体Ｆｅｄ内での投票に参加させるメンバーを選出する。

具体的には、投票に参加させるメンバーは、親ＢＣ（Ｍｃｈ）上の待ち行列（キュー）ＰＣＭ（図２）内で投票に参加するのを待っている複数の承認者端末Ｆｍ［ｊ］（１≦ｊ≦Ｍ）の中から上述した審査の結果に鑑みて適切と判断されたものが選出される。待ち行列ＰＣＭ（図２）内で投票への参加を待っている複数の承認者端末Ｆｍ［ｊ］（１≦ｊ≦Ｍ）の中から投票への参加メンバーを選出する仕組みは、キューイング機構に従って決定論的に行われ、待ち行列ＰＣＭには、投票への参加メンバーとなり得る複数の承認者端末Ｆｍ［ｊ］（１≦ｊ≦Ｍ）が決定論的なプロセスによって選ばれ、配置される。

図２に示す例では、待ち行列ＰＣＭ（図２）内で投票への参加を待っている複数の承認者端末Ｆｍ［ｊ］（１≦ｊ≦Ｍ）の中から連合体Ｆｅｄ内での投票に参加させるメンバーを選出する手順は、以下のように実行されてもよい。例えば、承認者端末Ｆｍ［ｘ］は、待ち行列ＰＣＭ（図２）内で投票への参加を待っている複数の承認者端末Ｆｍ［ｊ］（１≦ｊ≦Ｍ）の各々を第１基準ＣＲ１に基づいて審査する。そして、承認者端末Ｆｍ［ｘ］は、審査結果をもとに適切と判断した承認者端末Ｆｍ［ｉ］（１≦ｉ≦ｍ）を連合体Ｆｅｄ内での投票に参加させるメンバーとして選出する。

また、別の例では、承認者端末Ｆｍ［ｘ］は、連合体Ｆｅｄを構成する既存の承認者端末Ｆｍ［ｊ’］（１≦ｊ’≦Ｍ’）のうち、待ち行列ＰＣＭ（図２）に登録すべきものを第１基準ＣＲ１に基づいて選定する。代替的に、承認者端末Ｆｍ［ｘ］は、待ち行列ＰＣＭ内で投票への参加を待っている複数の承認者端末Ｆｍ［ｊ］（１≦ｊ≦Ｍ）の待ち行列ＰＣＭ内での並び順を第１基準ＣＲ１に基づいて調整する。その上で、承認者端末Ｆｍ［ｘ］は、ＦＩＦＯアルゴリズムに従って待ち行列ＰＣＭから取り出した承認者端末Ｆｍ［ｉ］（１≦ｉ≦ｍ）を連合体Ｆｅｄ内での投票に参加させるメンバーとして選出する。

続いて、第１トランザクションＴｘ［ａ，１］の検出を契機として第１基準ＣＲ１に基づいて複数の承認者端末Ｆｍ［ｉ］（１≦ｉ≦ｍ）が選出されると、連合体Ｆｅｄに属するいずれかの承認者Ｆｍ［ｙ］は投票開始メッセージを他の承認者端末Ｆｍ［ｋ］（ｋ≠ｙ）に同時送信することで、投票プロセスを開始する。このとき、仮に承認者端末Ｆｍ［ｙ］が一番最初に投票開始メッセージを同時送信した場合は、その他の承認者端末Ｆｍ［ｋ］（ｋ≠ｙ）はその投票プロセスが完了するまで投票開始メッセージを送信することは出来なくなる。

この投票プロセスが開始すると、承認者端末Ｆｍ［ｉ］（１≦ｉ≦ｍ）が多数決による意思決定を行うことで、ブロック・チェーン間転送を許可するか否かが判断される。その際、投票参加メンバーとして選出された承認者端末Ｆｍ［ｉ］（１≦ｉ≦ｍ）の各々は、着信した第１トランザクションＴｘ［ａ，１］を以下のようにして審査し、この審査の結果に応じて同意または反対を表す投票メッセージＶＴを同報送信する（図２に示すステップＳＴ０２）。

例えば、承認者端末Ｆｍ［ｉ］（１≦ｉ≦ｍ）の各々は、ブロック・チェーン間転送を許可するか否かを判断するのに利用可能な許認可基準となる以下のような一覧表（図２および図４に示す一覧表ＬＴ［Ａ］〜ＬＴ［Ｅ］など）を事前に設定しておくようにしてもよい。ここで、図２および図４に示す一覧表ＬＴ［Ａ］〜ＬＴ［Ｅ］は、ブロック・チェーン間転送の対象となるデジタル資産の種別（ビットコイン、Ｅｔｈｅｒｅｕｍ、Ｃｏｕｎｔｅｒｐａｒｔｙなどの通貨種別）とブロック・チェーン間転送の送金先アドレスから成るペアのうち、ブロック・チェーン間転送を許可すべきペアを列挙した許可リストおよびブロック・チェーン間転送を禁止すべきペアを列挙した禁止リストを含んで構成される。

また、図２に示す代替的な実施形態に従うならば、一覧表ＬＴ［Ａ］およびＬＴ［Ｂ］は、以下のようなデータ構造として構成されてもよい。図２に示すように、一覧表ＬＴ［Ａ］およびＬＴ［Ｂ］の各々には、一つ以上のエントリーが含まれている。各エントリーは、一覧表ＬＴ［Ａ］およびＬＴ［Ｂ］にそれぞれ対応する承認者端末Ｆｍ［ｘ１］およびＦｍ［ｘ２］の通信機能がサポートしている一つ以上のブロック・チェーン・プロトコルの属性を記述している。例えば、図２に示す一覧表ＬＴ［Ａ］には、「Asset Protocol A」と表記されるエントリーと、「Asset Protocol B」と表記されるエントリーと、が含まれている。また、図２に示す一覧表ＬＴ［Ｂ］には、「Asset Protocol A」と表記されるエントリーと、「Asset Protocol C」と表記されるエントリーと、が含まれている。

そして、各エントリーには、対応するブロック・チェーン・プロトコルによって送金や残高の確認が可能な一つ以上のデジタル資産の種別（通貨種別）が「Supported Assets」の欄に列挙されている。さらに、各エントリーには、ブロック・チェーン間転送における送金先のアドレスのうち、対応するブロック・チェーン・プロトコルによる送金や残高の確認が禁止されている一つ以上のアドレスが「Black Listed Addresses」の欄に列挙されている。

図２に示す一覧表ＬＴ［Ａ］およびＬＴ［Ｂ］が上記のようなデータ構造を有することにより、個々のブロック・チェーン間転送を許可するか否かを以下のとおりに判定することが可能となる。すなわち、側鎖ＢＣ（ＳＣ）側の送金先となる第１アドレスＷＡ［ａ，１］および第１デジタル資産ＶＣ［ａ］の通貨種別から成るペアを、一覧表と照合する。その結果、投票プロセスに参加する何れかの承認者端末Ｆｍ［ｉ”］は、照合結果から以下の事項を判定することが可能である。

まず、投票プロセスに参加する何れかの承認者端末Ｆｍ［ｉ”］が実行可能な一つ以上のブロック・チェーン・プロトコルのうち、ブロック・チェーン間転送の対象となるデジタル資産の通貨種別をサポートするプロトコルがあるか否かが判定可能となる。さらに、ブロック・チェーン間転送の対象となるデジタル資産の送金先アドレスが、送金処理に用いられるブロック・チェーン・プロトコルを利用する場合に送金先として禁止されているアドレスでないか否かを判定することが可能である。

以上より、送金先となる第１アドレスＷＡ［ａ，１］および第１デジタル資産ＶＣ［ａ］の通貨種別から成るペアを、一覧表と照合した結果に応じて、個々のブロック・チェーン間転送を許可するか否かが判定可能となる。なお、一例においては、図２および図４に示す一覧表ＬＴ［Ａ］〜ＬＴ［Ｅ］は、一人以上の承認者が承認者端末Ｆｍ［ｉ］（１≦ｉ≦ｍ）を操作することで端末内に設定したポリシー制御データに基づいて作成されてもよい。この場合、上記ポリシー制御データは、ブロック・チェーン間転送の許認可基準を記述することにより、承認者端末Ｆｍ［ｉ］（１≦ｉ≦ｍ）の端末動作を制御するデータである。このとき、ブロック・チェーン間転送の許認可基準は、複数のブロック・チェーンを跨ってデジタル資産が流通するエコシステムの統治に関する政策的要請に整合するように決められる。

図４に示す例では、承認者端末Ｆｍ［１］およびＦｍ［２］には、上述した許可リストと禁止リストを含む一覧表ＬＴ［Ｄ］とＬＴ［Ｃ］がそれぞれ事前に設定されている。また、承認者端末Ｆｍ［３］には、上述した許可リストと禁止リストを含む一覧表ＬＴ［Ｅ］が事前に設定されている。さらに、図４に示す例では、承認者端末Ｆｍ［１］は、親ＢＣ（Ｍｃｈ）上のフルノードＮｆ［Ｍｃｈ，２］および側鎖ＢＣ（ＳＣ）上のフルノードＮｆ［ＳＣ，２］と通信可能に接続され、承認者端末Ｆｍ［２］は、親ＢＣ（Ｍｃｈ）上のフルノードＮｆ［Ｍｃｈ，１］および側鎖ＢＣ（ＳＣ）上のフルノードＮｆ［ＳＣ，１］と通信可能に接続されている。また、承認者端末Ｆｍ［３］は、親ＢＣ（Ｍｃｈ）上のフルノードＮｆ［Ｍｃｈ，３］および側鎖ＢＣ（ＳＣ）上のフルノードＮｆ［ＳＣ，３］と通信可能に接続されている。

以上のような構成により、親ＢＣ（Ｍｃｈ）と側鎖ＢＣ（ＳＣ）の間でブロック・チェーン間転送を行う際に、承認者端末Ｆｍ［１］〜Ｆｍ［３］は、親ＢＣ（Ｍｃｈ）および側鎖ＢＣ（ＳＣ）と必要な情報やデータをやり取りすることができる。その上で、承認者端末Ｆｍ［ｉ］（１≦ｉ≦ｍ）の各々は、側鎖ＢＣ（ＳＣ）側の送金先となる第１アドレスＷＡ［ａ，１］および第１デジタル資産ＶＣ［ａ］の通貨種別から成るペアを、上記一覧表（図４に示すＬＴ［Ｃ］〜ＬＴ［Ｅ］など）と照合する。次に、承認者端末Ｆｍ［ｉ］（１≦ｉ≦ｍ）の各々は、この照合結果に応じて、個々のブロック・チェーン間転送に対し、同意および反対の何れか一方を表す投票メッセージＶＴを同報送信してもよい。

以上のようにして承認者端末Ｆｍ［ｉ］（１≦ｉ≦ｍ）による多数決に基づいて上述した投票の結果が得られる（図３に示すステップＳＴ０４）。この投票の結果、ブロック・チェーン間転送を許可すると決定する場合、承認者端末Ｆｍ［ｉ］（１≦ｉ≦ｍ）の中の少なくとも一つの承認者端末Ｆｍ［ｙ］は、以下の処理を実行することで、ブロック・チェーン間転送を完了させる。

まず、承認者端末Ｆｍ［ｙ］は、第１デジタル資産ＶＣ［ａ］と等価な経済価値を有する第２デジタル資産ＷＣ［ａ］（図１）を新規に発行する（図１）。その際、第２デジタル資産ＷＣ［ａ］は、デジタル資産の通貨種別に依存せずにトランザクション承認および残高の検証を実行可能な汎用性を有する分散合意形成プロトコルを用いて側鎖ＢＣ（ＳＣ）側での取引が可能な独自トークンＴｋ（図１）として発行される。その上で、承認者端末Ｆｍ［ｙ］は、独自トークンＴｋ（図１）を第１アドレスＷＡ［ａ，１］に転送する第２トランザクションＴｘ［ａ，２］（図３）を側鎖ＢＣ（ＳＣ）へと同報送信する（図５に示すＰ３）。

具体的には、独自トークンＴｋの側鎖ＢＣ（ＳＣ）に転送する第２トランザクションＴｘ［ａ，２］が多数決に基づく投票により許可されると、第２トランザクションＴｘ［ａ，２］は投票プロセスに参加した承認者端末Ｆｍ［ｉ］（１≦ｉ≦ｍ）によって電子署名される。そして、電子署名された第２トランザクションＴｘ［ａ，２］を側鎖ＢＣ（ＳＣ）側へと同報送信する。以上により、第２トランザクションＴｘ［ａ，２］を実行した結果として（図５に示すＰ３）、デジタル資産の側鎖ＢＣ（ＳＣ）側へのブロック・チェーン間転送が完了する（図３に示すステップＳＴ０５）。

他方、承認者端末Ｆｍ［ｉ］（１≦ｉ≦ｍ）による上述した投票の結果、所有者端末ＵＴ［ａ］から要求された第１デジタル資産ＶＣ［ａ］のブロック・チェーン間転送を許可しないと決定した場合には、図３に示すトランザクションＴｘ［ａ，３］が返金処理として実行される。このトランザクションＴｘ［ａ，３］では、第２アドレスＩＡ［ａ］にて保持されている第１デジタル資産ＶＣ［ａ］の所有者Ｕ［ａ］への返金処理が行われ、第１デジタル資産ＶＣ［ａ］のロックが解除されて使用可能な状態となる。

また、図２に示す例示的な一実施形態では、投票プロセスに参加する複数の承認者端末Ｆｍ［ｉ］（１≦ｉ≦ｍ）を選出する処理は、上述した許可リストと禁止リストを含む一覧表（図２に示すＬＴ［Ａ］とＬＴ［Ｂ］など）を用いて以下のように実行されてもよい。ここで、図２に示す例では、承認者端末Ｆｍ［１］およびＦｍ［２］には、上述した許可リストと禁止リストを含む一覧表ＬＴ［Ａ］がそれぞれ事前に設定されている。また、承認者端末Ｆｍ［３］には、上述した許可リストと禁止リストを含む一覧表ＬＴ［Ｂ］が事前に設定されている。その上で、まず、承認者端末Ｆｍ［ｘ］は、着信した第１トランザクションＴｘ［ａ，１］から側鎖ＢＣ（ＳＣ）側の送金先となる第１アドレスＷＡ［ａ，１］を抽出する。さらに、承認者端末Ｆｍ［ｘ］は、着信した第１トランザクションＴｘ［ａ，１］から、ブロック・チェーン間転送の対象となる第１デジタル資産ＶＣ［ａ］の通貨種別を検出する（図２に示すステップＳＴ０２）。

続いて、承認者端末Ｆｍ［ｘ］は、送金先となる第１アドレスＷＡ［ａ，１］および第１デジタル資産ＶＣ［ａ］の通貨種別から成るペアを、上記一覧表（図２に示すＬＴ［Ａ］やＬＴ［Ｂ］など）と照合する。次に、承認者端末Ｆｍ［ｘ］は、この照合結果に応じて待ち行列ＰＣＭ内で投票への参加を待っている複数の承認者端末Ｆｍ［ｊ］（１≦ｊ≦Ｍ）の中から適切な端末を投票への参加メンバーとして選出する。その際、上記一覧表（図２に示すＬＴ［Ａ］やＬＴ［Ｂ］など）との照合結果に応じて待ち行列ＰＣＭ内の承認者端末Ｆｍ［ｊ］（１≦ｊ≦Ｍ）の中から投票への参加メンバーを選出する処理は、例えば、以下のように実行されてもよい。

まず、承認者端末Ｆｍ［ｘ］は、待ち行列ＰＣＭ内で投票への参加を待っている承認者端末Ｆｍ［ｊ］（１≦ｊ≦Ｍ）にそれぞれ設定されている上記一覧表を読み出す。続いて、送金先となる第１アドレスＷＡ［ａ，１］および第１デジタル資産ＶＣ［ａ］の通貨種別の何れか一方に一致するエントリーを一覧表中に全く含まない端末を不適切な端末として投票への参加メンバーから除外する。逆に、承認者端末Ｆｍ［ｘ］は、待ち行列ＰＣＭ内の承認者端末Ｆｍ［ｊ］（１≦ｊ≦Ｍ）のうち、投票への参加メンバーから除外されずに残った端末を以下のように取り扱う。すなわち、送金先となる第１アドレスＷＡ［ａ，１］および第１デジタル資産ＶＣ［ａ］の通貨種別の何れか一方に一致するエントリーが一覧表中により多く含まれている端末を、他の端末よりも優先的に投票への参加メンバーとして選出する。

以上より、図２〜図４に示す実施形態では、上記の許可リストと禁止リストを含む一覧表（図２および図４に示す一覧表ＬＴ［Ａ］〜ＬＴ［Ｅ］など）は、投票に参加するメンバーの選出基準である第１基準ＣＲ１を具現化したものと見做せる。従って、承認者端末Ｆｍ［ｘ］は、投票に参加するメンバーの選出基準である第１基準ＣＲ１として、上記の許可リストと禁止リストを含む一覧表を用いることで、承認者端末Ｆｍ［ｉ］（１≦ｉ≦ｍ）を選出するようにしてもよい。

同様に、図２〜図４に示す実施形態では、上記の許可リストと禁止リストを含む一覧表は、個々のブロック・チェーン間転送を許可するか否かを判定する許認可基準となる第２基準ＣＲ２を具現化したものと見做せる。従って、承認者端末Ｆｍ［ｘ］は、個々のブロック・チェーン間転送の許否を決定する際、上記の許可リストと禁止リストを含む一覧表を第２基準ＣＲ２（許認可基準）として用いることで、個々のブロック・チェーン間転送を許可するか否かを決定するようにしてもよい。

以上より、この第２トランザクションＴｘ［ａ，２］を承認者端末Ｆｍ［ｙ］が実行することにより、親ＢＣ（Ｍｃｈ）上の第２デジタル資産ＷＣ［ａ］を側鎖ＢＣ（ＳＣ）へと移転させることが可能となる。その際、承認者端末Ｆｍ［ｙ］が上記ブロック・チェーン間転送を実行する際に用いられる分散合意形成プロトコルの一例として、アカウント・ベースのプロトコルを用いてもよい。ここで、アカウント・ベースのプロトコルは、基軸通貨として流通する任意の暗号通貨に対応した分散合意形成プロトコルであり、デジタル資産の通貨種別に依存せずにトランザクション承認および残高の検証を実行可能な汎用性を有するプロトコルである。

そして、この実施形態では、第２デジタル資産ＷＣ［ａ］は、第１デジタル資産ＶＣ［ａ］に対応する上記アカウント・ベースの分散合意形成プロトコルを用いて側鎖ＢＣ（ＳＣ）側での取引が可能な独自トークンＴｋとして発行される。さらに、この実施形態では、上記アカウント・ベースの分散合意形成プロトコルを用いて側鎖ＢＣ（ＳＣ）側での取引が可能な独自トークンＴｋは、調整可能な可変レートにより既存の暗号通貨と交換可能な未流通のデジタル資産であってもよい。

（２−２）ペグアウト段階の処理
図１〜図５を用いて上述したブロック・チェーン間転送は、親ＢＣ（Ｍｃｈ）上の第１デジタル資産ＶＣ［ａ］〜ＶＣ［ｄ］を側鎖ＢＣ（ＳＣ）側に移転する仕組みであり、非特許文献１では親ＢＣ（Ｍｃｈ）を起点とするペグインと呼ばれている。他方、側鎖ＢＣ（ＳＣ）側に一旦ペグインしたデジタル資産を親ＢＣ（Ｍｃｈ）上に戻すブロック・チェーン間転送は、非特許文献１においてペグアウトと呼ばれ、図５に示す例では、第１デジタル資産ＶＣ［ａ］を対象とするペグインとペグアウトの両者のシナリオが示されている。

以下、図５に示す例を用いて、側鎖ＢＣ（ＳＣ）側に第１デジタル資産ＶＣ［ａ］をペグインした後に、一旦ペグインしたデジタル資産を親ＢＣ（Ｍｃｈ）上に戻すブロック・チェーン間転送（ペグアウト）が実行される際のシナリオについて説明する。このシナリオは、連合体Ｆｅｄを構成する複数の承認者端末Ｆｍ［ｋ］（１≦ｋ≦Ｎ）の中で、ペグアウトの要求ｒｑを所有者端末ＵＴ［ａ］から受信した承認者端末Ｆｍ［ｘ’］を実行主体として実行される。ここで、上記要求ｒｑは、所有者Ｕ［ａ］が側鎖ＢＣ（ＳＣ）上に有する第２デジタル資産ＷＣ［ａ］を、親ＢＣ（Ｍｃｈ）上に戻すブロック・チェーン間転送を求める要求である。さらに、この場合のブロック・チェーン間転送は、所有者Ｕ［ａ］が親ＢＣ（Ｍｃｈ）上に有する第３アドレス（図５に示すＷＡ［ａ，３］）を送金先として、所有者Ｕ［ａ］が側鎖ＢＣ（ＳＣ）側に一旦ペグインしたデジタル資産を親ＢＣ（Ｍｃｈ）に戻す操作に相当する。

なお、不正防止と信頼性の観点から言うならば、一旦ペグインしたデジタル資産を親ＢＣ（Ｍｃｈ）に戻すペグアウトでは、ペグイン開始時に第１デジタル資産ＶＣ［ａ］のロックを行った承認者端末Ｆｍ［ｘ”］が上記ｒｑを検出し、その後の一連の処理の起点となるようにするのが好適である。以下、図５を参照しながら、側鎖ＢＣ（ＳＣ）側にペグイン済みのデジタル資産を親ＢＣ（Ｍｃｈ）上に戻すブロック・チェーン間転送（ペグアウト）が実行される際のシナリオを詳しく説明する。

また、例示的な一実施形態では、所有者端末ＵＴ［ａ］が、承認者端末Ｆｍ［ｘ’］に対して、側鎖ＢＣ（ＳＣ）側の送金先である第３アドレスＷＡ［ａ，３］を通知する仕組みは、以下のように実現されてもよい。まず、所有者端末ＵＴ［ａ］は、第２デジタル資産ＷＣ［ａ］を資産凍結アドレスＸＡ［ａ］へと転送する第３トランザクションＴｘ［ａ，４］に対して、第３アドレスＷＡ［ａ，３］を親ＢＣ（Ｍｃｈ）上の送金先として埋め込む。続いて、所有者端末ＵＴ［ａ］は、第３アドレスＷＡ［ａ，３］を含む第３トランザクションＴｘ［ａ，４］を資産凍結アドレスＸＡ［ａ］へと送信する。

上記要求ｒｑを受信した承認者端末Ｆｍ［ｘ’］は、第２デジタル資産ＷＣ［ａ］を将来にわたって事実上使用不可能にするための資産凍結アドレス（図５に示すＸＡ［ａ］）を側鎖ＢＣ（ＳＣ）上に生成する。その上で、連合体Ｆｅｄ内の多数決に基づく意思決定のために、複数の承認者端末Ｆｍ［ｈ］（１≦ｈ≦ｎ）により投票プロセス（図１〜図４を用いて上述したものと同様）が実行される。この投票プロセスが実行された結果、第３トランザクションＴｘ［ａ，４］を許可する場合、連合体Ｆｅｄ内の承認者端末Ｆｍ［ｙ’］は、第２デジタル資産ＷＣ［ａ］と等価な経済価値を有する独自トークンＴｋ’を新規に発行する。

さらに、承認者端末Ｆｍ［ｙ’］は、独自トークンＴｋ’のブロック・チェーン間転送を行う第４トランザクションＴｘ［ａ，５］を生成する。ここで、第４トランザクションＴｘ［ａ，５］では、所有者端末ＵＴ［ａ］から通知された第３アドレスＷＡ［ａ，３］が送金先として指定されている。最後に、承認者端末Ｆｍ［ｘ’］は、第４トランザクションＴｘ［ａ，５］を介して独自トークンＴｋ’を第３アドレスＷＡ［ａ，３］に転送する（図５に示すＰ４）。

これと並行して、承認者端末Ｆｍ［ｘ’］は、第２デジタル資産ＷＣ［ａ］を資産凍結アドレスＸＡ［ａ］に転送する第３トランザクションＴｘ［ａ，４］を同報送信する。その後、側鎖ＢＣ（ＳＣ）上の資産凍結アドレスＸＡ［ａ］において第３トランザクションＴｘ［ａ，４］が受信されると、資産凍結アドレスＸＡ［ａ］に転送された第２デジタル資産ＷＣ［ａ］は、将来にわたって事実上使用不可能とされる。

この独自トークンＴｋ’は、デジタル資産の通貨種別に依存せずにトランザクション承認および残高の検証を実行可能な汎用性を有する分散合意形成プロトコルを用いて親ＢＣ（Ｍｃｈ）側での取引が可能なデジタル資産として発行される。さらに、承認者端末Ｆｍ［ｙ’］が独自トークンＴｋ’を側鎖ＢＣ（ＳＣ）から親ＢＣ（Ｍｃｈ）へとペグアウトする際に用いられる分散合意形成プロトコルの一例として、アカウント・ベースのプロトコルを用いてもよい。ここで、アカウント・ベースのプロトコルは、基軸通貨として流通する任意の暗号通貨に対応した分散合意形成プロトコルであり、デジタル資産の通貨種別に依存せずにトランザクション承認および残高の検証を実行可能な汎用性を有するプロトコルである。

そして、この実施形態では、第２デジタル資産ＷＣ［ａ］は、第１デジタル資産ＶＣ［ａ］に対応する上記アカウント・ベースの分散合意形成プロトコルを用いて側鎖ＢＣ（ＳＣ）側での取引が可能な独自トークンＴｋ’として発行される。さらに、この実施形態では、上記アカウント・ベースの分散合意形成プロトコルを用いて側鎖ＢＣ（ＳＣ）側での取引が可能な独自トークンＴｋ’は、調整可能な可変レートにより既存の暗号通貨と交換可能な未流通のデジタル資産であってもよい。以上により、所有者Ｕ［ａ］が側鎖ＢＣ（ＳＣ）上に有する第２デジタル資産ＷＡ［ａ］を親ＢＣ（Ｍｃｈ）側に戻すペグアウトが実現可能となる。

（２−３）連合体を構成するメンバーシップの更新
次に、多数決による意思決定を行う２つ以上の承認者端末Ｆｍ［ｉ］（１≦ｉ≦Ｉ）により形成され連合体Ｆｅｄに関し、構成員たる承認者端末Ｆｍ［ｉ］（１≦ｉ≦Ｉ）のメンバーシップを更新する仕組みについて図６および図７を参照しながら述べる。図６および図７に示す例では、第１基準に基づいて承認者端末Ｆｍ［ｉ］（１≦ｉ≦Ｉ）同士の間の互選により連合体Ｆｅｄの構成員たる承認者端末Ｆｍ［ｉ］（１≦ｉ≦Ｉ）のメンバーシップが以下のようにして更新される。

新規の側鎖ＢＣ（ＳＣ）の開始時において連合体Ｆｅｄを構成する初期メンバーとなる承認者端末Ｆｍ［ｈ］（１≦ｈ≦Ｈ）については、側鎖ＢＣ（ＳＣ）を開始したブロック・チェーン利用者Ｕ［０］が信頼する人の中から合理的に分散された形で決定することができる。しかしながら、その後は既存の承認者端末Ｆｍ［ｉ］（１≦ｉ≦Ｉ）を評価し、連合体Ｆｅｄを形成する承認者端末Ｆｍ［ｉ］（１≦ｉ≦Ｉ）のメンバーシップを変更可能なメカニズムが必要になる。これは、連合体Ｆｅｄに属する既存の承認者端末Ｆｍ［ｉ］（１≦ｉ≦Ｉ）によって、新しい承認者端末Ｆｍ［ｚ１］を新規メンバーとして受け入れる（図６に示すシナリオ）か、または既存の承認者端末Ｆｍ［ｚ２］を連合体Ｆｅｄから排除する（図７に示すシナリオ）かを多数決に基づいて決定する投票ＶＴによって実現可能である。

次に、連合体Ｆｅｄ内での投票ＶＴによって連合体Ｆｅｄを構成するメンバーシップを更新する際に、新しい承認者端末Ｆｍ［ｚ１］を新規メンバーとして受け入れるシナリオについて図６を用いて詳しく説明する。図６（ａ）に示すシナリオでは、端末利用者Ｕ［ｙ］が操作する端末ＵＴ［ｙ］には、図２に示す一覧表ＬＴ［Ａ］およびＬＴ［Ｂ］と同様のデータ構造を有する一覧表ＬＴ［Ｇ］が事前に設定されているものとする。また、図６（ａ）に示すシナリオの開始時には、連合体Ｆｅｄを構成する既存のメンバーを複数の承認者端末Ｆｍ［ｋ］（１≦ｋ≦ｎ）と表記することとする。

図６（ａ）に示すシナリオが開始されると、端末ＵＴ［ｙ］は、待ち行列（キュー）ＰＣＭに関連付けられたアドレスＹＡ「ｙ」を宛先として参加要求トランザクションＴｘ［ｙ，６］を実行する（図６に示すステップＳＴ２１）。今、複数の承認者端末Ｆｍ［ｋ］（１≦ｋ≦ｎ）の一つである承認者端末Ｆｍ［ｙ”］が、アドレスＹＡ［ｙ］への参加要求トランザクションＴｘ［ｙ，６］の着信を検知したと想定して、この先の説明を行う。参加要求トランザクションＴｘ［ｙ，６］の実行に伴い、端末ＵＴ［ｙ］は、自身に関連付けられた一覧表ＬＴ［Ｇ］に含まれるエントリー情報を親ＢＣ（Ｍｃｈ）内の全ノードに対して広告する。図２および図４を用いて上述したように、各々のエントリー情報には、端末ＵＴ［ｙ］がサポート可能なブロック・チェーン・プロトコルの種別、プロトコル種別毎にサポート可能なデジタル資産の種別とプロトコル種別毎に禁止された送金先のアドレスが列挙されている。

一方、承認者端末Ｆｍ［ｙ”］は、連合体Ｆｅｄ内の他のメンバーである承認者端末Ｆｍ［ｋ］（ｋ≠ｋ”，１≦ｋ≦ｎ）に対して、新規メンバーの参加要求に応じた投票プロセスの開始を告知するメッセージを同報送信する（図６に示すステップＳＴ２３）。その後、上述した投票プロセスが開始すると、承認者端末Ｆｍ［ｋ］（１≦ｋ≦ｎ）の各々は、端末ＵＴ［ｙ］について親ＢＣ（Ｍｃｈ）内で広告された上記エントリー情報に基づいて端末ＵＴ［ｙ］を評価する（図６に示すステップＳＴ２２）。これにより、承認者端末Ｆｍ［ｋ］（１≦ｋ≦ｎ）の各々は、端末ＵＴ［ｙ］が連合体Ｆｅｄの新規メンバーとして充分な好適性を有しているかを判断し、判断の結果に応じて参加要求に同意又は反対の投票ＶＴを行う（図６（ｂ））。そして、図６（ｂ）に示す投票の結果、端末ＵＴ［ｙ］を連合体Ｆｅｄの新規メンバーとして参加させることを最終的に決定した場合には、端末ＵＴ［ｙ］は、連合体Ｆｅｄの新規メンバーＦｍ［ｚ１］として登録される（図６（ｂ）に示すステップＳＴ２４）。

一例においては、承認者端末Ｆｍ［ｋ］（１≦ｋ≦ｎ）の各々は、以下のような基準に基づいて端末ＵＴ［ｙ］が連合体Ｆｅｄの新規メンバーとして充分な好適性を有しているか否かを判断するようにしてもよい。
（イ）端末ＵＴ［ｙ］が多種多様なブロック・チェーン・プロトコルを実行可能であるか（一覧表ＬＴ［Ｇ］に含まれるエントリー情報の数が多いか）？
（ロ）端末ＵＴ［ｙ］が多種多様なデジタル資産を取り扱い可能であるか？
（ハ）プロトコル種別毎に禁止された送金先アドレスの集合について、既存のメンバーである承認者端末Ｆｍ［ｋ］（１≦ｋ≦ｎ）との間で重複部分が多いか？

なお、上記（ハ）に例示するように、プロトコル種別毎に禁止された送金先アドレスの集合について、既存のメンバーである承認者端末Ｆｍ［ｋ］（１≦ｋ≦ｎ）と端末ＵＴ［ｙ］との間で重複部分が少ないならば、それは高い確率で以下を示唆すると考えられる。すなわち、複数のブロック・チェーンを跨いで適切な統治を行うための政策に関し、既存の連合体Ｆｅｄと端末ＵＴ［ｙ］との間で意見の隔たりが大きいことを示唆していると考えられる。以上より、連合体Ｆｅｄを構成する承認者端末Ｆｍ［ｋ］（１≦ｋ≦ｎ）は、ブロック・チェーンの統治政策に関し、既存の連合体Ｆｅｄと端末ＵＴ［ｙ］との間で意見が相違するか否かを考慮して端末ＵＴ［ｙ］の連合体Ｆｅｄへの参加の可否を判断することが可能となる。

以上のように、図６および図７を用いて上述した実施形態では、代替的な実施形態では、連合体Ｆｅｄの構成員として適切な承認者端末［ｃ］を選定する基準は、各端末に関連付けられた一覧表ＬＴ［Ｇ］に含まれるエントリー情報に基づいていた。しかしながら、本発明の幾つかの実施形態では、連合体Ｆｅｄを構成する承認者端末Ｆｍ［ｉ］（１≦ｉ≦Ｉ）のメンバーシップを更新する際に、連合体Ｆｅｄの構成員をより一般化された基準により選出することも可能である。すなわち、連合体Ｆｅｄの構成員として適切な承認者端末［ｃ］を選定する基準である第１基準ＣＲ１は、以下のようにして設定されてもよい。

まず、一人以上の承認者の端末操作により、連合体Ｆｅｄの既存の構成員たる承認者端末Ｆｍ［ｉ］（１≦ｉ≦Ｉ）には、以下のようなポリシー制御データが事前に入力される。上記ポリシー制御データは、複数のブロック・チェーンを跨ってデジタル資産が流通するエコシステムの統治に関する政策的要請を記述し、端末の動作に対するポリシー制御を行うのに用いるデータである。続いて、連合体Ｆｅｄの構成員たる承認者端末Ｆｍ［ｉ］（１≦ｉ≦Ｉ）内において、上記ポリシー制御データに整合する基準が第１基準ＣＲ１として生成され、端末内に設定される。最後に、この第１基準ＣＲ１に基づいて承認者端末Ｆｍ［ｉ］（１≦ｉ≦Ｉ）同士の間の互選により連合体Ｆｅｄを構成するメンバーシップを更新するように構成される。

また、連合体Ｆｅｄ内での投票ＶＴによって、連合体Ｆｅｄを構成するメンバーシップを更新する際に、既存の承認者端末Ｆｍ［ｚ２］を連合体Ｆｅｄから排除するシナリオについて図７を用いて詳しく説明する。図７（ａ）に示すシナリオの開始時には、連合体Ｆｅｄを構成する既存のメンバーを複数の承認者端末Ｆｍ［ｋ］（１≦ｋ≦ｎ）と表記することとする。複数の承認者端末Ｆｍ［ｋ］（１≦ｋ≦ｎ）は、各端末の動作状態を端末同士の間で相互に監視し続け、連合体Ｆｅｄの構成員として不適格な端末を発見した場合には、連合体Ｆｅｄ内の全メンバーに広告する。

具体的には、以下のような点で連合体Ｆｅｄの構成員として不適格な端末Ｆｍ［ｚ２］が連合体Ｆｅｄ内に発見された場合には、その端末Ｆｍ［ｚ２］の識別情報が連合体Ｆｅｄ内の全メンバーに広告される。例えば、連合体Ｆｅｄに属する複数の承認者端末Ｆｍ［ｋ］（１≦ｋ≦ｎ）の中で一定以上の期間にわたって休眠状態にある端末は、連合体Ｆｅｄの構成員として不適格と見なされる。また、親ＢＣ（Ｍｃｈ）との間で通信接続が非アクティブな状態が一定以上の期間にわたって続いている端末もまた、連合体Ｆｅｄの構成員として不適格と見なされる。

上記のような不適格な端末Ｆｍ［ｚ２］が連合体Ｆｅｄ内で発見されると、図６を用いて上述したものと同様の投票プロセスが開始され、承認者端末Ｆｍ［ｋ］（１≦ｋ≦ｎ）の各々は、連合体Ｆｅｄの構成員としての端末Ｆｍ［ｚ２］の不適格性を評価する。その結果、承認者端末Ｆｍ［ｋ］（１≦ｋ≦ｎ）の各々は、連合体Ｆｅｄの構成員として端末Ｆｍ［ｚ２］の不適格か否かを判断し、判断の結果に応じて端末Ｆｍ［ｚ２］を連合体Ｆｅｄの構成員から除外することに対し、同意又は反対の投票ＶＴを行う（図７（ａ））。そして、図７（ａ）に示す投票の結果、端末Ｆｍ［ｚ２］を連合体Ｆｅｄの構成員から除外することを最終的に決定した場合には、端末Ｆｍ［ｚ２］は、連合体Ｆｅｄの構成員から除外される（図７（ｂ））。

以上より、非特許文献１記載の「Federated Peg方式」における連合体を構成するメンバーには予め決められている既定の承認者端末が選任されている。その結果、非特許文献１記載の「Federated Peg方式」では、新規の承認者端末を必要に応じてその都度選出する仕組みや手順は設けられていない。これに対し、本発明の幾つかの実施形態に係る「Federated Gatewayシステム」では、連合体Ｆｅｄ内で投票に参加する既存のメンバーＦｍ［ｉ］（１≦ｉ≦ｍ）が投票を行う。そして、投票結果に従って新規メンバーとなる承認者端末Ｆｍ［ｚ１］を選出する。

このように連合体内で投票権を持つ既存メンバーの投票により新規メンバーを選出する上記仕組みは、本発明の幾つかの実施形態に係る「Federated Gatewayシステム」では、オンチェーン上での仕組みとして実行される。このオンチェーンでの仕組みによって、新規の承認者端末ｆｍ［ｚ１］の選出基準が明確化され、新たな承認者端末Ｆｍ［ｚ１］の追加や既存の承認者端末Ｆｍ［ｚ２］の削除が決定されるプロセスの透明性が保たれる。

（２−４）本発明の実施形態に係るシステムが有する技術的メリット
続いて、本発明の実施形態に関して図１〜図５に示す「Federated Gatewayシステム」と上述した従来式の「Federated Peg方式」との対比検討を交えながら、本発明の実施形態に係る「Federated Gatewayシステム」の技術的効果について述べる。親ＢＣ（Ｍｃｈ）から側鎖ＢＣ（ＳＣ）内に移転された暗号資産とそのトランザクションにおける信頼性は、パブリック・チェーン側での信頼性保証能力に全面的に依存しており、側鎖ＢＣ（ＳＣ）自身が当該信頼性を保証することはない。また、既存の親ＢＣ（Ｍｃｈ）に併設される側鎖ＢＣ（ＳＣ）の従来からの利用目的としては、以下のものが考えられる。

（ａ）親ＢＣ（Ｍｃｈ）での既存の実装や動作ルールをほとんど変更せずに新規なスクリプト機能拡張を追加することを目的として、サイドチェーン側で新たなスクリプト機能拡張を実装する（例えば、ビットコインではスマートコントラクトを実行可能なスクリプト処理を実現できないので、サイドチェーン側で販売者と購入者との間の非公開型のスマートコントラクト処理を扱う）。
（ｂ）ビットコイン等の親ＢＣ（Ｍｃｈ）からのトランザクション・データの正当性を「双方向ペグ」を通じて検証する際に、（高価で高い処理能力を持つハードウェアを必要とする）フルノード上でしか実行できないＰｏＷ証明（Proof of work）ではなく、スマートフォンのような軽量クライアント上でも実行可能なＳＰＶ証明（Simplified Payment Verification Proof）に基づいて正当性を検証できるようにする。

その一方で、従来の「サイドチェーン技術」および従来の「Federated Peg方式」には以下に挙げるような問題点がある。
（Ａ）従来のサイドチェーン技術およびFederated Peg方式を実装した例としては、親ＢＣ（Ｍｃｈ）と側鎖ＢＣ（ＳＣ）との間でＵＴＸＯに対応したビットコインを転送する双方向ペグ機能の実装例しかない。つまり、親ＢＣ側ではアカウント・ベースの分散合意形成プロトコルにより送金が可能な任意の暗号資産を取引可能なＢＣＮを実現することができない。特に、従来の実装例（非特許文献１）では、UTXOに対応したビットコインを親ＢＣと側鎖ＢＣとの間で双方向ペグを実行する実装例しかない。また、双方向ペグの仕組みは、親ＢＣ側ではUTXO非対応のビットコインを取引するブロック・チェーンでは実装が困難である。同様に、双方向ペグの仕組みは、ビットコイン以外の任意のアルトコイン（Alt Coin）又は任意のトークンを取引可能なブロック・チェーンにおいても実装が困難である。

（Ｂ）既存のサイドチェーン技術に基づいて親ＢＣに側鎖ＢＣを併設したシステムでは、単一ブロック・チェーン内の正当性検証や分散合意形成ルールの適用に加え、ブロック・チェーン間での双方向ペグに際しての正当性検証や分散合意形成ルール適用のメカニズムを実装することが必要になる。また、単一の暗号資産が事実上は複数のブロック・チェーンと関連付けられていて、各ブロック・チェーンもまた、ブロック・チェーン毎に複数の異なる暗号資産を扱えるようになっている結果、暗号資産の管理や取引監視がそれだけ複雑化し、難しくなる。また、ユーザ端末上のウォレット機能の実装に関しても、複数の異なる仮想通貨や任意の様々なトークンを種類の違いを意識せずに（同じユーザ・インターフェースや同じユーザ操作性で）同時にサポートできるようになっていない（非特許文献１を参照）。

（Ｃ）親ＢＣではなく、特定の側鎖ＢＣを採掘した方が儲かる場合には、仮想通貨の採掘者はその側鎖ＢＣの採掘に注力する。その結果、親ＢＣ側に対してComputing Powerを提供するノードが不足するという状況が生じ得る。その場合、親ＢＣ側においてブロック・チェーンの維持と成長に必要なComputing Power供給量の深刻な欠乏状況が発生し得る（非特許文献１を参照）。
また、従来の「Federated Peg方式」では、側鎖ＢＣ上にペグインされたビットコインと親ＢＣ上のビットコインは一対一で対応しているため、側鎖ＢＣ上でトランザクションを実行する際に課金される手数料もビットコインで請求や決済をすることとなる。その結果、ビットコインの価格の上下はそのまま側鎖ＢＣ内における手数料価格に反映されブロック・チェーン・システムの運用管理者による政策的な調整が困難となる。

（Ｄ）双方向ペク可能なサイドチェーンにおける別の問題点として、双方向ペグによりチェーン間で転送される暗号資産の種類またはペグイン／アウトの要求を送出した要求元が法的、思想的および戦略的な観点から望ましくない場合があり得る。この問題に対処するには、特定の利用者が特定の暗号資産をペグイン／ペグアウトしようとする試みを認容すべきか否かを一定の統制ルールに従って管理することが必要となる。さらに、上記統制ルールに基づく管理を実現するには、ペグイン／アウトの対象となる暗号資産の種別が認容可能な暗号資産であるか否か又はペグイン／アウトを要求した要求元が認容可能な利用者であるか否かを具体的に判別する仕組みも必要になる。

これに対し、本発明の幾つかの実施形態に係る「Federated Gatewayシステム」では、ペグインの対象となるデジタル資産の通貨種別やペグイン実行のためのプロトコルに関し、承認者端末Ｆｍ［ｉ１］およびＦｍ［ｉ２］がサポートする通貨種別やプロトコルが互いに異なる可能性がある。そのため、それぞれ異なるプロトコルに対応した異なる通貨種別が混在した状態でも個々のブロック・チェーン間転送要求を適切に取り扱う仕組みを提供する必要がある。従って、従来の「Federated Peg方式」では、全ての承認者端末はビットコインのみを取り扱うため単純であるが、本発明の幾つかの実施形態に係る「Federated Gatewayシステム」では、異種プロトコルに対応した異なる通貨種別が混在した状況に対処可能なより高度な仕組みを以下のように実現している。

すなわち、本発明の幾つかの実施形態に係る「Federated Gatewayシステム」では、多数決による意思決定を図１〜図５に示す連合体Ｆｅｄに開始させる。その後、連合体Ｆｅｄ内の多数決により所定の許認可基準に基づいてブロック・チェーン間転送を許可すべきかを判断する。その結果、許可可能と判断した場合に、第１デジタル資産ＶＣ［ｕ］（ｕ＝ａ，ｂ，ｃ，ｄ）と等価な経済価値を有する第２デジタル資産ＷＣ［ｕ］を新規に発行し、ブロック・チェーン間転送を実行する。この第２デジタル資産ＷＣ［ｕ］は、デジタル資産の種別に依存せずにトランザクション承認および残高の検証を実行可能な汎用性を有する分散合意形成プロトコルを用いて側鎖ＢＣ（ＳＣ）側での取引が可能な独自トークンＴｋとして発行される。

以上より、本発明の幾つかの実施形態によれば、ＵＴＸＯ非対応のビットコインまたはビットコイン以外の任意の暗号資産を取引可能なブロック・チェーンとの間で暗号資産の転送を実現することができる。また、本発明の幾つかの実施形態によれば、特定の利用者が特定の暗号資産をブロック・チェーン間で転送しようとする試みを認容すべきか否かを複数の観点に基づく統制ルールに従って管理する仕組みを実現することができる。特に、図２および図４に示す実施形態によれば、各々の承認者端末に設定されている許可リストと禁止リストに基づいてブロック・チェーン間転送における個々の送金先や転送対象となるデジタル資産の種別が許可可能であるか否かが判定可能である。

その結果、政策または統制ルールを中心に承認者を選定することで、ペグイン要求やペグアウト要求の許認可基準と承認者の連合体のメンバー選出基準との整合性を図ることができる。これにより、ペグイン要求やペグアウト要求の許認可基準をどのように決めるべきかを方向付ける指針が変化する都度、それに合わせて連合体のメンバー選出基準を適応させていくことが可能となる。

なお、この独自トークンＴｋは、デジタル資産の種別に依存せずにトランザクション承認および残高の検証を実行可能な汎用性を有する分散合意形成プロトコルを用いて親ＢＣ（Ｍｃｈ）側での取引が可能なデジタル資産として発行される。その際、承認者端末Ｆｍ［ｙ］が上記ブロック・チェーン間転送を実行する際に用いられる分散合意形成プロトコルの一例として、アカウント・ベースのプロトコルを用いてもよい。ここで、アカウント・ベースのプロトコルは、基軸通貨として流通する任意の暗号通貨に対応した分散合意形成プロトコルであり、デジタル資産の種別に依存せずにトランザクション承認および残高の検証を実行可能な汎用性を有するプロトコルである。

そして、この実施形態では、第２デジタル資産ＷＣ［ａ］は、第１デジタル資産ＶＣ［ａ］に対応する上記アカウント・ベースの分散合意形成プロトコルを用いて側鎖ＢＣ（ＳＣ）側での取引が可能な独自トークンＴｋとして発行される。さらに、この実施形態では、上記アカウント・ベースの分散合意形成プロトコルを用いて側鎖ＢＣ（ＳＣ）側での取引が可能な独自トークンＴｋとして、調整可能な可変レートにより既存の暗号通貨と交換可能な未流通のデジタル資産を採用することができる。

＜３＞ブロック・チェーンの基本機能を実装するソフトウェアとハードウェア
ところで、図１〜図７を参照しながら上述したブロック・チェーン間転送システムでは、各々の所有者が有するデジタル資産の取引内容の正当性に関する分散合意形成およびデジタル資産の所有者の認証などの基本的な仕組みを実現することが必要となる。一般に、上述した分散合意形成の処理には、トランザクションへの電子署名、トランザクション承認および残高の検証に関してノード間で行われる処理が含まれる。そこで、これら基本的な仕組みが、どのようなハードウェア構成の上で実行され、ソフトウェアによる具体的な情報処理としてどのように実現されるかについて、図８〜図１４を用いて説明する。

図８に示す実装例では、ブロック・チェーンによって複数のブロックを保持するネットワーク１が設けられ、ネットワーク１には、複数のノード３ａ〜３ｃが含まれる。複数のノード３ａ〜３ｃは、例えばプロセッサやメモリを有するコンピュータである。またネットワーク１には、複数の端末装置２ａ，２ｂ，２ｃが接続され、端末装置２ａは、デジタル資産４ａに対する電子証明書の発行を希望するユーザ８が使用し、端末装置２ｂ，２ｃは、システムの管理者９ａ，９ｂが使用する。

ユーザ８が、デジタル資産４ａの所有者がユーザ８であることを証する電子証明書の発行を希望する場合、ユーザ８は、端末装置２ａにデジタル資産４ａを入力し、端末装置２ａに、デジタル資産４ａのネットワーク１への登録を指示する。すると端末装置２ａは、ユーザ８が所有するデジタル資産４ａを含むブロック４（第１ブロック）を作成する。ブロック４には、ユーザ８のデジタル資産４ａをユーザ８の秘密鍵で暗号化することで作成した電子署名４ｂが含まれる。また、ブロック４に、ユーザ８を一意に特定する識別子を含めてもよい。

端末装置２ａは、作成したブロック４の登録要求を、ネットワーク１内の複数のブロック・チェーン・ノード３ａ〜３ｃのうちの１台に送信する。複数のブロック・チェーン・ノード３ａ〜３ｃは、ブロック４の登録要求に応じて、ブロック４をブロック・チェーンによって分散して保持する。複数の第２の端末装置２ｂ，２ｃは、ネットワーク１から、デジタル資産４ａを含むブロック４，４−１（第２ブロック）を、承認対象ブロックとして取得する。そして複数の第２の端末装置２ｂ，２ｃは、管理者９ａ，９ｂからの入力に応じて、デジタル資産４ａの登録承認を示す電子署名５ａ，５ｎと承認対象ブロック４，４−１とを含むブロック４−１，４−２を作成する。すなわち承認対象ブロック４，４−１に電子署名５ａ，５ｎを付加したものが、新たなブロック４−１，４−２となる。

例えば、管理者９ａ，９ｂは、承認対象ブロック４，４−１に含まれるデジタル資産４ａの所有者がユーザ８であることを、オフラインなどの別の手続きによって確認し、確認できた場合に、登録承認の入力を行う。そして複数の第２の端末装置２ｂ，２ｃは、ブロック４−１，４−２の登録要求を、ネットワーク１へ出力する。複数のブロック・チェーン・ノード３ａ〜３ｃは、ブロック４−１，４−２の登録要求に応じて、ブロック４−１，４−２をブロック・チェーンによって分散して保持する。

保持したブロック４，４−１，４−２のなかに、包含する電子署名５ａ，５ｎの数が所定数に達した署名数充足ブロックがある場合、そのことを、複数のノード３ａ〜３ｃのうちの１台が検出する。図１の例では、ノード３ｃが、ブロック４−２が署名数充足ブロックであると検出したものとする。するとノード３ｃは、デジタル資産４ａの所有者がユーザ８であることを証明する電子証明書６とブロック４−２とを含むブロック４−３（第３ブロック）を作成する。

例えばノード３ｃは、スマートコントラクトを含む証明書発行部７を有している。証明書発行部７は、デジタル資産４ａに対して、証明書発行部７の電子署名６ａ（有効化用電子署名）を付与し、電子証明書６とする。なお証明書発行部７の電子署名６ａは、ノード３ｃの電子署名でもある。そして複数のノード３ａ〜３ｃが、作成されたブロック４−３をブロック・チェーンによって分散して保持する。このように、電子証明書６が付与されたブロック４−３がブロック・チェーンによって分散して保持されることで、デジタル資産４ａが有効化され、任意のユーザが、自身の使用する端末装置を用いてブロック４−３を参照できる。また、ブロック４−３内に含まれている電子証明書６により、ブロック４−３に含まれているデジタル資産４ａの所有者がユーザ８であることを確認できる。

例えば、デジタル資産４ａを使用するユーザが使用する端末装置（図示せず）は、ノード３ａ〜３ｃから、ノード３ａ〜３ｃ自身の公開鍵（証明書発行部７の公開鍵）を取得し、端末装置は、取得した公開鍵により電子証明書６の正当性を検証する。例えば端末装置は、電子証明書６に含まれる電子署名を取得した公開鍵で復号し、復号したデータとデジタル資産４ａとが一致する場合、電子証明書６が正しいと判断する。端末装置は、正しく検証できた場合、デジタル資産４ａの所有者がユーザ８であると判断でき、ブロック４−３にユーザ８の識別子が含まれていれば、デジタル資産４ａの所有者が、その識別子で示されるユーザ８であることが分かる。デジタル資産４ａがユーザ８の公開鍵であれば、デジタル資産４ａを使用するユーザは、ユーザ８の識別子を宛先として送信するデータを、その公開鍵で暗号化することで、データを安全にユーザ８に送信することができる。

ユーザ８は、有効化したデジタル資産４ａを、ユーザ８の意思で無効化できる。例えば、端末装置２ａは、ユーザ８からデジタル資産４ａの破棄を指示する入力を受け付けたことに応じて、破棄を示すフラグとブロック４−３とを含むブロックの登録要求を、ネットワーク１へ出力する。複数のノード３ａ〜３ｃは、その登録要求に応じて、該当ブロックをブロック・チェーンによって分散して保持する。また複数のノード３ａ〜３ｃのうちのいずれか１台が、保持したブロックに破棄を示すフラグが含まれることを検出すると、ノード３ａ〜３ｃは、そのブロックに含まれる情報に対するノード自身の電子署名（無効化用電子署名）とそのブロックとを含むブロックを生成する。そして複数のノード３ａ〜３ｃが、生成したブロックをブロック・チェーンによって分散して保持する。

破棄を示すフラグを含むブロックに、いずれかのブロック・チェーン・ノードが電子署名をすることで、該当ブロックに含まれるデジタル資産４ａは無効となる。このように、デジタル資産４ａを無効化する際には、ユーザ８が、破棄を示すブロックの登録手続きをするだけでよく、管理者の手間をかけずに済む。その結果、デジタル資産４ａを迅速に無効化することができる。

なお、端末装置２ａは、ユーザ８から、証明対象情報４ａの破棄を指示する入力の受信時に生成するブロックに、ブロック４−３内の情報を、ユーザ８の秘密鍵で暗号化した電子署名（所有者電子署名）を含めてもよい。複数のノード３ａ〜３ｃは、登録要求に応じて保持したブロックに破棄を示すフラグが含まれることを検出すると、ユーザ８の電子署名を、ユーザ８の公開鍵（所有者公開鍵）で復号する。続いて、復号されたデータとブロック４−３内の情報とを比較し、一致すれば、ユーザ８の電子署名が正当であると判断する。電子署名が正当であることが確認できた場合、複数のノード３ａ〜３ｃは、そのブロックに含まれる情報に対するノード自身の電子署名とそのブロックとを含むブロックを生成し、ブロック・チェーンによって分散して保持する。このように、デジタル資産４ａの破棄を示すブロックに、ユーザ８の電子署名を付加し、その電子署名を検証した後にデジタル資産４ａを無効化することで、ユーザ８以外の第三者によりデジタル資産４ａが無効化されることを抑止することができる。

次にＢＣＮ（Blockchain Network）における電子証明書の発行と管理を、集中管理するサーバを用いずに実現する実装例について図９を用いて説明する。以下、電子証明書を、単に証明書と呼ぶこととし、ＢＣＮは、幾つかのノードがダウンしても電子情報を受け渡すことができ、高い可用性が実現されている。図９に示す実装例では、ネットワークスイッチ３１〜３５を介して、複数のノード２００，２００ａ〜２００ｆが接続されている。ノード２００，２００ａ〜２００ｆのそれぞれは、ＢＣＮ上の１ノードとして機能するコンピュータである。また図９に示すネットワークには、複数の端末装置１００，１００ａ〜１００ｃが接続されている。複数の端末装置１００，１００ａ〜１００ｃは、ネットワークを介した取引を行うユーザ４１，４２、またはネットワークの管理者５１，５２が使用するコンピュータである。

図１０は、図８の実装例に用いる端末装置１００（１００ａ〜１００ｃ）のハードウェアの一構成例を示しており、端末装置１００（１００ａ〜１００ｃ）は、プロセッサ１０１によって装置全体が制御されている。プロセッサ１０１には、バス１０９を介してメモリ１０２と複数の周辺機器が接続されている。メモリ１０２は、端末装置１００の主記憶装置として使用される。メモリ１０２には、プロセッサ１０１に実行させるプログラムが読み込まれると共に、プロセッサ１０１による処理に必要な各種データが格納される。バス１０９に接続されている周辺機器には、ＯＳのプログラム、アプリケーションプログラム、および各種データが格納され、データの書き込みおよび読み出しを行うストレージ装置１０３が含まれる。また、上記周辺機器には、グラフィック処理装置１０４、入力インタフェース１０５、光学ドライブ装置１０６、機器接続インタフェース１０７およびネットワークインタフェース１０８が含まれる。

グラフィック処理装置１０４は、プロセッサ１０１からの命令に従って、画像をモニタ２１の画面に表示する。入力インタフェース１０５は、キーボード２２やマウス２３から送られてくる信号をプロセッサ１０１に送信する。光学ドライブ装置１０６は、光ディスク２４に記録されたデータの読み取りを行う。機器接続インタフェース１０７は、端末装置１００に周辺機器を接続するための通信インタフェースであり、メモリ装置２５やメモリリーダライタ２６を接続することができる。メモリ装置２５は、機器接続インタフェース１０７と通信可能な記録媒体であり、メモリリーダライタ２６は、メモリカード２７に対してデータの読み書きを行う。ネットワークインタフェース１０８は、ネットワークスイッチ３１を介して、外部との間でデータの送受信を行う。ノード２００，２００ａ〜２００ｆ、端末装置２ａ〜２ｃおよびノード３ａ〜３ｃのハードウェア構成も同様である。

端末装置１００，１００ａ〜１００ｃまたはノード２００，２００ａ〜２００ｆは、例えばコンピュータ読み取り可能な記録媒体に記録されたプログラムを実行することにより、それぞれの処理機能を実現する。例えば、上記プログラムをストレージ装置１０３（または光ディスク２４、メモリ装置２５、メモリカード２７など）に格納しておき、プロセッサ１０１は、このプログラムをメモリ１０２にロードし、プログラムを実行する。このプログラムは、例えばプロセッサ１０１からの制御により、ストレージ装置１０３にインストールされた後、実行可能となる。

図８および図９に示す実装例では、このようなハードウェア構成のシステムを用いて、ブロック・チェーンを用いた証明書の発行や管理が行われる。図１１は、図８および図９に示すＢＣＮの一例を示しており、２つのＢＣＮ（６０，６１）が設けられている。ＢＣＮ（６０）は、電子情報の取引に関するブロック６０ａ，６０ｂ保存用のブロック・チェーン・ネットワークである。ＢＣＮ（６１）は、証明書に関するブロック６１ａ，６１ｂを保存するのに用いるＢＣＮである。

以下、ＢＣＮ（６０，６１）に関する処理を実施するために、端末装置とノードが有する機能について説明する。図１２は、端末装置とノードが有する機能の一例を示すブロック図であり、ユーザ４１が使用する端末装置１００は、ＯＳ（１１０）とＷｅｂブラウザ（１２０）とを有している。Ｗｅｂブラウザ（１２０）は、公開鍵の登録要求や参照を行う証明書利用部１２１を有し、証明書利用部１２１は、公開鍵の登録要求の送信処理、公開鍵の破棄要求の送信処理、他のユーザの公開鍵の使用処理などを実行する。管理者５１が使用する端末装置１００ａは、ＯＳ（１１０ａ）とＷｅｂブラウザ（１２０ａ）とを有し、Ｗｅｂブラウザ（１２０ａ）は、証明書の発行手続きを行う証明書管理部１２２ａを有している。

ノード２００は、ＯＳ２１０、Ｗｅｂサーバ２２０、およびブロック・チェーン・サブシステム２３０を有している。ブロック・チェーン・サブシステム２３０は、２つのＢＣＮ（６０，６１）を介して、ブロックの配布および保持を行う。例えばブロック・チェーン・サブシステム２３０は、ブロック記憶部２３１を有しており、端末装置１００または他のブロック・チェーン・ノード２００ａから取得したブロックを、ブロック記憶部２３１に格納する。またブロック・チェーン・サブシステム２３０は、ＢＣＮ（６１）上での証明書の発行や無効化を行うスマートコントラクト２３２を有している。

同様にノード２００ａは、ＯＳ（２１０ａ）、Ｗｅｂサーバ２２０ａ、およびブロック・チェーン・サブシステム２３０ａを有している。ブロック・チェーン・サブシステム２３０ａは、ブロックを保持するためのブロック記憶部２３１ａや、証明書の発行や無効化を行うスマートコントラクト２３２ａを有している。ブロック・チェーン参加者であるユーザ４１は、端末装置１００を用いて、ＢＣＮ（６０）を介して取引を行うと共に、ＢＣＮ（６１）を介して、証明書による本人証明を行う。管理者５１は、端末装置１００ａを用いて、ＢＣＮ（６０）で保持される電子情報の管理や、ＢＣＮ（６１）で保持される証明書の発行および管理を行う。

例えばユーザ４１は、端末装置１００を用いて、リファレンスフラグ「０」（登録）の値と公開鍵とを含むデータを作成し、そのデータに自分の秘密鍵で電子署名を行う。電子署名を行うとは、署名対象のデータまたはそのデータのハッシュ値を、秘密鍵で暗号化することである。以下、電子署名を行うことで生成される暗号化されたデータを、単に「署名」と呼ぶ。そしてユーザ４１は、端末装置１００ａを用いて、署名付きのデータを、ＢＣＮ（６１）上に登録する。この際、秘密鍵は、各参加者が保持しておく。管理者５１は、端末装置１００ａを用いて、証明書発行前（リファレンスフラグが「０」）のブロックに自分の署名を付与したデータを作成する。そして管理者５１は、端末装置１００ａを用いて、作成したデータを、ＢＣＮ（６１）上に登録する。

ブロック・チェーン・ネットワーク６１上のスマートコントラクト２３２，２３２ａは、規定数以上の数の承認を得たブロックを確認した場合に、そのブロックのリファレンスフラグを「０」より大きい値「１」（有効）に変更する。さらにスマートコントラクト２３２，２３２ａは、そのブロックにスマートコントラクト２３２，２３２ａの署名を付与したブロックを生成する。そしてスマートコントラクト２３２，２３２ａは、生成したブロックを、公開鍵証明書として新たに、ブロック・チェーン・サブシステム２３０，２３０ａに登録することを要求する。

ユーザ４１に電子情報を送信する他のユーザは、ＢＣＮ（６１）上に登録された、値が「０」より大きいリファレンスフラグの証明書に含まれる公開鍵を、ユーザ４１へ送る情報の暗号化に使用する。ユーザ４１の公開鍵の証明書の無効化は、ユーザ４１がリファレンスフラグの値を「−１」（無効）にしたデータに電子署名を行い、ブロック・チェーン・サブシステム２３０に登録を要求する。スマートコントラクト２３２は、このリファレンスフラグの値が「−１」のブロックを読み込み、ユーザ４１自身が登録したかを署名によって検証する。スマートコントラクト２３２は、検証できれば、そのブロックにスマートコントラクト２３２自身の署名を付けて、ブロック・チェーン・サブシステム２３０に登録する。これにより、管理者５１の手を煩わせずに、証明書を無効化できる。

＜４＞ブロック・チェーン・システムを構築する情報処理システム基盤
一方、図８〜図１２を用いて上述したブロック・チェーンの基本的な仕組み（トランザクションの電子署名、承認、残高の検証等）は、クラウド・コンピューティング基盤やサーバ・クラスタ等を情報処理基盤として用いて実現されることが多い。そこで、図１３および図１４に示すシステム実装例では、図８〜図１２を用いて上述したブロック・チェーンの基本的な仕組みを実装したクラウド・コンピューティング基盤やサーバ・クラスタ等に対して、利用者の情報端末が通信接続可能なシステムを実現している。このシステムでは、利用者の情報端末からシステム内で提供されるブロック・チェーン関連機能にアクセスすることを可能にしている。また、図１３および図１４に示すシステム実装例は、Multi-Tier構成のＷｅｂサイトと同様に、複数のサーバ装置により情報処理に関する多層構造を実現した情報システムとして構成されている。

図１３に示すように、システム５００は、通信経路５０６を通ってバックエンド・システム５０４にアクセスする必要がある一つ以上のアプリケーション５０２を有する。バックエンド・システム５０４は、例えば、ＢＣＮ（Blockchain Network）を構成する一つ以上の構成要素５０４（５０４Ａ、５０４Ｂ、．．．、５０４Ｎ）を有し、一つ以上のアプリケーションは、ＢＣＮを構成する一つ以上の構成要素にアクセスする。各アプリケーション５０２は、コンピュータ装置によって実行することができ、各コンピュータ装置は、公知の通信及びデータプロトコル及びＡＰＩを用いて、通信経路５０６を通ってバックエンド・システム５０４に接続してこれと対話することができる。例えば、各コンピュータ装置は、アプリケーション５０２を実行してＢＣＮの構成要素との対話を実行することができる。

バックエンド・システム５０４及びＢＣＮの構成要素５０４は、一つ以上の計算リソースを用いて実施することができ、通信経路５０６を介して一つ以上のデータ供給源５０８と接続することができる。バックエンド・システム５０４及びＢＣＮの構成要素５０４は、各データ供給源のための標準規格、プロトコル、及び／又はＡＰＩを用いて、データ供給源１０８と通信することができ、アプリケーション５０２は、ＢＣＮの構成要素５０４（５０４Ａ〜５０４Ｎ）にアクセスすることができる。

各アプリケーション５０２のアプリケーションスタックの実施例を図２に示す。各アプリケーションスタックは、アプリケーション層５０２Ａと、サービス層５０２Ｂと、データ層５０２Ｃとを含む。リソース識別子、デジタル資産署名、及び認可承諾のみがブロック・チェーン内に格納されるので、リソース自身の処理やリソースにアクセスする処理は、関与するアプリケーションが行う。

図１４に示す例では、アプリケーション層５０２Ａは、ＡＰＩレジストリと、アクター・レジストリと、サービス・レジストリと、製品レジストリと、データ・レジストリ及び変換と、イベントと、ワークフローと、認可及び委任とを含む。サービス層５０２Ｂは、ブロック・チェーン・トランザクションと、データ配信要素と、ネットワークノード管理と、アクセス制御とを含む。データレイヤ５０２Ｃは、ピアツーピアファイル転送と、グラフデータ格納と、識別子管理と、暗号化及び鍵管理要素とを含む。ブロックデータベースの構造及び関係を図１４の下半分に示す。図示するように、各ブロック・ヘッダ３００は、分散型データベースのデータの一部分、及びブロック・ハッシュ、及びマークル・ルートを保持し、ブロック・トランザクション及びこれと対応するデータに関係付けられる。

Ｍｃｈ 親ＢＣ（パブリック・チェーン）
ＳＣ（ＳＣ１，ＳＣ２） 側鎖ＢＣ（サイドチェーン）
Ｔｘ［ｕ，ｖ］（ｕ＝１，…，μ，ｖ＝１，…，γ） トランザクション
Ｆｍ［ｉ］（１≦ｉ≦Ｉ） 承認者端末
Ｆｅｄ 承認者端末の連合体
ＵＴ［ｉ］（１≦ｉ≦Ｉ） 利用者端末（所有者端末）
Ｕ［ｉ］（１≦ｉ≦Ｉ） 利用者（デジタル資産の所有者）
ＶＣ［ａ］，ＶＣ［ｂ］，ＶＣ［ｃ］，ＶＣ［ｄ］，ＶＣ１ 第１デジタル資産
ＷＣ［ａ］，ＷＣ［ｂ］，ＷＣ［ｃ］，ＷＣ［ｄ］，ＶＣ２ 第２デジタル資産
ＶＴ 投票
ＩＡ［ｉ］（１≦ｉ≦Ｉ） 一次預金用アドレス
ＷＡ［ｉ，ｊ］（１≦ｉ≦Ｉ，１≦ｊ≦Ｊ） 送金先アドレス
ＸＡ［ｉ］ 資産凍結アドレス
ＱＡ，ＹＡ アドレス
ＰＣＭ 待ち行列（キュー）
１ ネットワーク
２ａ，２ｂ，２ｃ 端末装置
３ａ，３ｂ，３ｃ ノード
４，４−１，４−２，４−３ ブロック
４ａ 証明対象情報
４ｂ，５ａ，５ｎ，６ａ 電子署名
６ 電子証明書
７ 証明書発行部
８ ユーザ
９ａ，９ｂ 管理者
１００ 端末装置
１０１ プロセッサ
１０２ メモリ
１０４ グラフィック処理装置
１０５ 入力インタフェース
１０６ 光学ドライブ装置
２００，２００ａ〜２００ｆ ノード
３００ ブロック・ヘッダ
５００ システム
５０２ アプリケーション
５０２Ａ アプリケーション層
５０２Ｂ サービス層
５０２Ｃ データ層
５０４ バックエンド・システム
５０６ 通信経路
５０４（５０４Ａ，…，５０４Ｎ） ＢＣＮ（Ｂｌｏｃｋｃｈａｉｎ Ｎｅｔｗｏｒｋ）
５０８ データ供給源

Claims (10)

1. 送金トランザクションを介したデジタル情報の送受信により資産価値を流通させることが可能な一種類以上の電磁的記録を含むデジタル資産を、ブロック・チェーン間で転送するシステムにおいて、
   第１ブロック・チェーン上で所有者が有する第１デジタル資産を第２ブロック・チェーン上に前記所有者が有する第１アドレスにブロック・チェーン間転送により移転する要求を送出する所有者端末と、
   多数決による意思決定を行う２つ以上の承認者端末により形成された連合体、と、
   を備え、前記要求を検知した前記連合体内の少なくとも一つの前記承認者端末は、
   投票開始メッセージを他の承認者端末に同報送信することで前記多数決による意思決定を前記連合体に開始させ、前記承認者端末にあらかじめ設定された、ブロック・チェーン間転送の対象となるデジタル資産の種別とブロック・チェーン間転送の送金先アドレスとから成るペアのうちブロック・チェーン間転送を許可すべきペアを列挙した許可リストおよびブロック・チェーン間転送を禁止すべきペアを列挙した禁止リストを含む所定の許認可基準に基づいて前記ブロック・チェーン間転送を許可可能と判断した場合に、前記第１デジタル資産と等価な経済価値を有する第２デジタル資産を新規に発行して前記第１アドレスに同報送信して前記ブロック・チェーン間転送を実行し、
   前記第２デジタル資産は、デジタル資産の種別に依存せずにトランザクション承認および残高の検証を実行可能な汎用性を有する分散合意形成プロトコルを用いて前記第２ブロック・チェーン側での取引が可能な独自トークンとして発行され、
   前記連合体の承認者端末のそれぞれは、待ち行列中の新たな承認者端末を新規メンバーとして受け入れるかを前記第１ブロックチェーン内で広告されたエントリー情報と第１基準とに基づいて決定の上で同報送信して前記連合体の多数決により該連合体のメンバーシップを更新するように構成され、
   前記第１基準とは端末が多種多様なブロック・チェーン・プロトコルを実行可能であるか、端末が多種多様なデジタル資産を取り扱い可能であるか、またはプロトコル種別毎に禁止された送金先アドレスの集合について、既存のメンバー である承認者端末との間で重複部分が多いかの少なくとも１つである、ことを特徴とするシステム。
2. 前記所有者端末は、前記承認者端末から前記第１ブロック・チェーン上で指定された第２アドレスに前記第１デジタル資産を転送する第１トランザクションを同報送信し、
   前記連合体を構成する少なくとも一つの前記承認者端末は、
   前記第２アドレスにて前記第１トランザクションを受信すると、前記所有者端末から通知された前記第１アドレスを送金先とする前記ブロック・チェーン間転送の許否を前記連合体内の前記多数決により決定する投票プロセスを前記連合体に開始させる通信手順を実行し、
   前記ブロック・チェーン間転送を許可する場合、前記第１デジタル資産と等価な経済価値を有する前記第２デジタル資産を新規に発行し、前記第２デジタル資産を前記第１アドレスに転送する第２トランザクションを前記第２ブロック・チェーンへと同報送信するように構成される、
   ことを特徴とする請求項１記載のシステム。
3. 前記所有者が前記第１ブロック・チェーン上に有する第３アドレスを送金先として、前記第２デジタル資産を前記第１ブロック・チェーンに戻すブロック・チェーン間転送を求める要求を前記所有者端末から受信した前記承認者端末は、
   前記第２デジタル資産を将来にわたって事実上使用不可能にするための資産凍結アドレスを前記第２ブロック・チェーン上に生成し、前記第２デジタル資産を前記資産凍結アドレスに転送する第３トランザクションを同報送信し、
   前記資産凍結アドレスにおいて前記第３トランザクションが受信されると、前記所有者端末から通知された前記第３アドレスを送金先として、前記独自トークンのブロック・チェーン間転送を行う第４トランザクションを生成し、
   前記連合体内の前記多数決に基づく意思決定のために前記投票プロセスを実行した結果、前記第３トランザクションを許可する場合、前記第３トランザクションを介して前記独自トークンを前記第３アドレスに転送することで、前記第２デジタル資産を前記第１ブロック・チェーンに戻すように構成される、
   ことを特徴とする請求項２に記載のシステム。
4. 複数のブロック・チェーンを跨ってデジタル資産が流通するエコシステムの統治に関する政策的要請を記述し、対応するブロック・チェーン・プロトコルによって送金や残高の確認が可能な一つ以上のデジタル資産の種別と、ブロック・チェーン間転送における送金先のアドレスのうち対応するブロック・チェーン・プロトコルによる送金や残高の確認が禁止されている一つ以上のアドレスとが含まれるポリシー制御データを一つ以上の前記承認者端末に対して入力する端末操作が一人以上の承認者によって行われると、
   前記承認者端末は、前記ポリシー制御データに整合した前記許認可基準となる一覧表を設定し、前記第２ブロック・チェーン側の送金先となる前記第１アドレスおよび前記第１デジタル資産の種別を、前記一覧表に従って審査することで、前記ブロック・チェーン間転送を許可するか否かを判断し、
   前記一覧表は、ブロック・チェーン間転送の対象となる前記デジタル資産の種別とブロック・チェーン間転送の送金先となるアドレスから成るペアのうち、ブロック・チェーン間転送を許可すべき前記ペアを列挙した許可リストおよびブロック・チェーン間転送を禁止すべき前記ペアを列挙した禁止リストを含んで構成される、
   ことを特徴とする請求項１乃至請求項３の何れか一項に記載されたシステム。
5. 複数のブロック・チェーンを跨ってデジタル資産が流通するエコシステムの統治に関する政策的要請を記述し、対応するブロック・チェーン・プロトコルによって送金や残高の確認が可能な一つ以上のデジタル資産の種別と、ブロック・チェーン間転送における送金先のアドレスのうち対応するブロック・チェーン・プロトコルによる送金や残高の確認が禁止されている一つ以上のアドレスとが含まれるポリシー制御データを一つ以上の前記承認者端末に対して入力する端末操作が一人以上の承認者によって行われると、前記ポリシー制御データに整合する基準が前記第１基準として設定され、
   前記第１基準に基づいて前記承認者端末間の多数決によりメンバーシップを更新するように構成される、
   ことを特徴とする請求項１乃至請求項４の何れか一項に記載されたシステム。
6. 前記ブロック・チェーン間転送の許否を前記連合体内の前記多数決により決定する投票プロセスが開始すると、前記所有者端末から前記第１トランザクションを受信した前記承認者端末は、ブロック・チェーン間転送の対象となるデジタル資産の種別とブロック・チェーン間転送の送金先アドレスとから成るペアのうちブロック・チェーン間転送を許可すべきペアを列挙した許可リストおよびブロック・チェーン間転送を禁止すべきペアを列挙した禁止リストを含む第２基準に基づいて前記投票プロセスに参加する他の承認者端末を選出するプロセスを実行し、
   前記投票プロセスにおいて前記第２基準に基づいて選出された複数の前記承認者端末が多数決による意思決定を行うことで、前記ブロック・チェーン間転送を許可するか否かが判断される、
   ことを特徴とする請求項２に記載されたシステム。
7. 前記デジタル資産の種別に依存せずにトランザクション承認および残高の検証を実行可能な汎用性を有する前記分散合意形成プロトコルは、基軸通貨として流通する任意の暗号通貨に対応したアカウント・ベースのプロトコルを用いて実現され、
   前記第２デジタル資産は、前記第１デジタル資産に対応する前記アカウント・ベースのプロトコルを用いて前記第２ブロック・チェーン側での取引が可能な前記独自トークンとして発行され、調整可能な可変レートにより既存の暗号通貨と交換可能な未流通のデジタル資産である、
   ことを特徴とする請求項１乃至請求項４の何れか一項に記載されたシステム。
8. 前記連合体を構成する少なくとも一つの前記承認者端末は、
   前記第１ブロック・チェーン上の前記第１デジタル資産を前記第２ブロック・チェーン上の前記第１アドレスを送金先として移転する前記要求を前記所有者端末から受信した際、前記所有者に固有の前記第２アドレスを前記第１ブロック・チェーン上に作成して前記所有者端末に割り当て、
   前記所有者端末は、前記連合体を構成する少なくとも一つの前記承認者端末に前記要求を送出した後、前記承認者端末から前記第１ブロック・チェーン上で割り当てられた前記第２アドレスに前記第１デジタル資産を転送する前記第１トランザクションを同報送信する、
   ことを特徴とする請求項２に記載されたシステム。
9. 前記連合体を構成する少なくとも一つの前記承認者端末は、前記第１トランザクションの受信に応じて、前記第１デジタル資産をロックし、前記第１デジタル資産がロックされた状態は、ブロック・チェーン間転送により前記第２ブロック・チェーンに移転された前記独自トークンが、逆向きのブロック・チェーン間転送により前記第１ブロック・チェーンに戻されるまで維持される
   ことを特徴とする請求項２または８に記載されたシステム。
10. 前記所有者が有する前記第１デジタル資産を前記所有者端末から前記承認者端末へと転送する前記第１トランザクションに対して、前記第１アドレスを前記第２ブロック・チェーン上の送金先として埋め込むことにより、前記第１アドレスを前記連合体に属する少なくとも一つの前記承認者端末に通知し、
    前記第２デジタル資産を前記資産凍結アドレスへと転送する前記第３トランザクションに対して、前記第３アドレスを前記第１ブロック・チェーン上の送金先として埋め込むことにより、前記第３アドレスを前記連合体に属する少なくとも一つの前記承認者端末に通知する、
    ことを特徴とする請求項３に記載されたシステム。