▶ エヌイーシー ラボラトリーズ ヨーロッパ ゲーエムベーハーの特許一覧
特許7554840フェデレーテッドブロックチェーンのための信頼の基点をブートストラップすること
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2024-09-11
(45)【発行日】2024-09-20
(54)【発明の名称】フェデレーテッドブロックチェーンのための信頼の基点をブートストラップすること
(51)【国際特許分類】
H04L 9/32 20060101AFI20240912BHJP
【ＦＩ】
H04L9/32 200Z
【請求項の数】
17
(21)【出願番号】P 2022552463
(86)(22)【出願日】2020-03-25
(65)【公表番号】
(43)【公表日】2023-05-11
(86)【国際出願番号】 EP2020058259
(87)【国際公開番号】W WO2021190740
(87)【国際公開日】2021-09-30
【審査請求日】2023-01-16
(73)【特許権者】
【識別番号】517451940
【氏名又は名称】エヌイーシー ラボラトリーズ ヨーロッパ ゲーエムベーハー
(74)【代理人】
【識別番号】100108453
【弁理士】
【氏名又は名称】村山 靖彦
(74)【代理人】
【識別番号】100110364
【弁理士】
【氏名又は名称】実広 信哉
(74)【代理人】
【識別番号】100133400
【弁理士】
【氏名又は名称】阿部 達彦
(72)【発明者】
【氏名】ガッサン・カラメ
(72)【発明者】
【氏名】セバスティアン・アンドレイナ
(72)【発明者】
【氏名】ウェンティン・リ
【審査官】青木 重徳
(56)【参考文献】
【文献】特表２０２０－５０３５８３（ＪＰ，Ａ）
【文献】特表２０２０－５０８５９４（ＪＰ，Ａ）
【文献】国際公開第２０１９／１８６７４７（ＷＯ，Ａ１）
【文献】米国特許出願公開第２０１９／０２２０６０３（ＵＳ，Ａ１）
【文献】淵田 康之，特集：イノベーションと金融 ブロックチェーンと金融取引の革新，野村資本市場クォータリー，日本，株式会社野村資本市場研究所，2015年11月01日，第１９巻第２号（通巻７４号），pp.11-35
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｈ０４Ｌ ９／３２
(57)【特許請求の範囲】
【請求項1】
異なるブロックチェーンからのノード間の信頼された通信をサポートするための方法であって、複数のブロックチェーンの間の信頼をブートストラップするためのブートストラッピングサービスを使用するステップであり、前記複数のブロックチェーンが、複数のフェデレーテッドブロックチェーンであり、前記ブートストラッピングサービスが前記複数のブロックチェーンの各々のコンセンサス構成に関する情報を記録し、前記コンセンサス構成に関する前記情報は、コンセンサスプロトコルの種類を含む、ステップを含む、方法。
【請求項2】
前記コンセンサス構成に関する前記情報は、プロトコル構成およびパラメータならびに前記ブロックチェーンのバリデータノードの識別情報をさらに含む、請求項1に記載の方法。
【請求項3】
前記複数のブロックチェーンにおける第1のブロックチェーンが、前記ブートストラッピングサービスから得られる、前記複数のブロックチェーンにおける第2のブロックチェーンのコンセンサス構成に関する情報に基づいて、前記第2のブロックチェーンのトランザクションを検証する、前記ブートストラッピングサービスを通じたトランザクション検証を更に含む、請求項1または2に記載の方法。
【請求項4】
異なるブロックチェーンからのノード間の信頼された通信をサポートするための方法であって、
複数のブロックチェーンの間の信頼をブートストラップするためのブートストラッピングサービスを使用するステップであり、前記複数のブロックチェーンが、複数のフェデレーテッドブロックチェーンであり、前記ブートストラッピングサービスが前記複数のブロックチェーンの各々のコンセンサス構成に関する情報を記録する、ステップを含み、
前記ブートストラッピングサービスが、前記複数のブロックチェーンのうちの所与のブロックチェーンへの新たなバリデータノードの参加によって引き起こされる、前記所与のブロックチェーンの前記コンセンサス構成の変更を記録する、方法。
【請求項5】
（※３３）
前記ブートストラッピングサービスによって、前記所与のブロックチェーンから更新されたコンセンサス構成を前記所与のブロックチェーンの対応するファイナリティプルーフと共に受信するステップと、
前記ブートストラッピングサービスによって、前記記録した元のコンセンサス構成に基づいて前記更新されたコンセンサス構成の前記ファイナリティプルーフを検証するステップと、
前記検証が成功である場合、前記ブートストラッピングサービスによって、前記更新されたコンセンサス構成を記録するステップと
を更に含む、請求項4に記載の方法。
【請求項6】
異なるブロックチェーンからのノード間の信頼された通信をサポートするための方法であって、
複数のブロックチェーンの間の信頼をブートストラップするためのブートストラッピングサービスを使用するステップであり、前記複数のブロックチェーンが、複数のフェデレーテッドブロックチェーンであり、前記ブートストラッピングサービスが前記複数のブロックチェーンの各々のコンセンサス構成に関する情報を記録し、ステップを含み、
前記ブートストラッピングサービスが、前記複数のブロックチェーンに加えられるために確立されるいかなる新たなブロックチェーンも前記新たなブロックチェーンのコンセンサス構成と共に記録する、方法。
【請求項7】
前記ブートストラッピングサービスによって、確立されるべき新たなブロックチェーンの第1のバリデータノードによって送信される、確立されるべき前記新たなブロックチェーンの第1の登録要求を受信するステップであり、前記登録要求が、少なくとも前記新たなブロックチェーンの前記コンセンサス構成を前記新たなブロックチェーンの前記バリデータノードの識別情報と共に含む、ステップと、前記ブートストラッピングサービスによって、確立されるべき前記新たなブロックチェーンに対して新たなレコードを追加するステップであり、前記新たなレコードが、前記新たなブロックチェーンの現状を保留として明記する、ステップと、
を更に含む、請求項6に記載の方法。
【請求項8】
前記ブートストラッピングサービスによって、第2のまたは任意の更なるバリデータノードによって送信される、前記新たなブロックチェーンの第2のまたは任意の更なる登録要求を受信するステップと、前記ブートストラッピングサービスによって、各受信した登録要求に対して、確立されるべき前記新たなブロックチェーンの前記コンセンサス構成に基づいて、それらの登録要求を送信したバリデータノードのリストが完全であるかどうかを判定するステップと、
を更に含む、請求項7に記載の方法。
【請求項9】
前記ブートストラッピングサービスによって、それらの登録要求を既に送信したバリデータノードの前記リストが完全であると判定される場合、確立されるべき前記新たなブロックチェーンの状態を保留から準備完了へ更新するステップと、そうでなければ、その登録要求を送信した前記バリデータノードをリストに加えて更なる登録要求を待つステップと、
を更に含む、請求項8に記載の方法。
【請求項10】
異なるブロックチェーンからのノード間の信頼された通信をサポートするための方法であって、
複数のブロックチェーンの間の信頼をブートストラップするためのブートストラッピングサービスを使用するステップであり、前記複数のブロックチェーンが、複数のフェデレーテッドブロックチェーンであり、前記ブートストラッピングサービスが前記複数のブロックチェーンの各々のコンセンサス構成に関する情報を記録する、ステップを含み、
前記方法が、
前記複数のブロックチェーンの第1のブロックチェーンによって、前記複数のブロックチェーンの第2のブロックチェーンにトランザクションを前記トランザクションの前記第1のブロックチェーンのファイナリティプルーフと共に伝送することによって、前記第2のブロックチェーンとクロスチェーントランザクションを開始するステップと、
前記第2のブロックチェーンによって、前記第1のブロックチェーンのコンセンサス構成に関する情報を前記ブートストラッピングサービスに要求するステップと、
前記ブートストラッピングサービスによって、前記第1のブロックチェーンのコンセンサス構成に関する前記要求された情報を前記第2のブロックチェーンに返すステップと、
前記第2のブロックチェーンによって、前記第1のブロックチェーンのコンセンサス構成に基づいて前記トランザクションの前記第1のブロックチェーンのファイナリティプルーフを検証し、そして前記検証が成功である場合前記トランザクションを承認するステップと
を更に含む、方法。
【請求項11】
異なるブロックチェーンからのノード間の信頼された通信をサポートするためのシステムであって、複数のブロックチェーンの間の信頼をブートストラップするためのブートストラッピングサービスであり、前記複数のブロックチェーンが、複数のフェデレーテッドブロックチェーンであり、前記ブートストラッピングサービスが前記複数のブロックチェーンの各々のコンセンサス構成に関する情報を記録するように構成され、前記コンセンサス構成に関する前記情報は、コンセンサスプロトコルの種類を含む、ブートストラッピングサービスを備える、システム。
【請求項12】
異なるブロックチェーンからのノード間の信頼された通信をサポートするためのシステムであって、
複数のブロックチェーンの間の信頼をブートストラップするためのブートストラッピングサービスであり、前記複数のブロックチェーンが、複数のフェデレーテッドブロックチェーンであり、前記ブートストラッピングサービスが前記複数のブロックチェーンの各々のコンセンサス構成に関する情報を記録するように構成される、ブートストラッピングサービスを備え、
前記ブートストラッピングサービスが、前記複数のブロックチェーンのうちの所与のブロックチェーンへの新たなバリデータノードの参加によって引き起こされる前記所与のブロックチェーンの前記コンセンサス構成の変更を記録するように構成される、システム。
【請求項13】
異なるブロックチェーンからのノード間の信頼された通信をサポートするためのシステムであって、
複数のブロックチェーンの間の信頼をブートストラップするためのブートストラッピングサービスであり、前記複数のブロックチェーンが、複数のフェデレーテッドブロックチェーンであり、前記ブートストラッピングサービスが前記複数のブロックチェーンの各々のコンセンサス構成に関する情報を記録するように構成される、ブートストラッピングサービスを備え、
前記ブートストラッピングサービスが、前記複数のブロックチェーンに加えられるために確立されるいかなる新たなブロックチェーンも前記新たなブロックチェーンのコンセンサス構成と共に記録するように構成される、システム。
【請求項14】
前記ブートストラッピングサービスが、前記複数のブロックチェーンの第1のブロックチェーンに、前記複数のブロックチェーンの前記第1のブロックチェーンからの要求に応じて、前記複数のブロックチェーンの第2のブロックチェーンのコンセンサス構成に関する情報を提供することによって異なるブロックチェーン間のクロスチェーントランザクションをサポートするように構成される、請求項11から13のいずれか一項に記載のシステム。
【請求項15】
前記ブートストラッピングサービスが信頼されたサードパーティを含む、請求項11から14のいずれか一項に記載のシステム。
【請求項16】
前記ブートストラッピングサービスが複製状態の複製システムを含む、請求項11から15のいずれか一項に記載のシステム。
【請求項17】
コンピュータに請求項1から10のうちのいずれか一項に記載の方法を実行させるためのコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、異なるブロックチェーンからのノード間の信頼された通信をサポートするための方法およびシステムに関する。
【背景技術】
【0002】
ブロックチェーン技術は、支払システム、アイデンティティマネジメントおよびサプライチェーンマネジメントなどの多くのユースケースにおいて広く検討および採用されてきた。これらのブロックチェーンユースケースの大部分がパーミッションベースであるので、それらは、それぞれの他のチェーンによってアクセスできないそれら自身のプライベートな台帳を維持する。しかしながら、異なるブロックチェーンにおけるノードが、しばしば一部の情報を共有する必要があり、実際に、ブロックチェーンの今日の高まる要件の1つが、それらが互いと通信する必要があるということである。より詳細には、異なるブロックチェーンからのノードが情報を交換するまたは資産を移転することを許可するフェデレーテッドブロックチェーン(Federated Blockchain)を形成する必要がある。
【0003】
フェデレーテッドブロックチェーンが互いと通信するための最大の課題は、それらがそれぞれの他のブロックチェーンによって使用されるコンセンサスプロトコルを想定または信頼しなければならないということである。現状技術では、サテライトチェーン(例えば、W. Li、A. Sforzin、S. FedorovおよびG. O. Karame、「Towards scalable and private industrial blockchains」、in Proceedings of the ACM Workshop on Blockchain、2017に記載されている)ならびにサイドチェーン(例えば、A. Back、M. Corallo、L. Dashjr、M. Friedenbach、G. Maxwell、A. Miller、A. Poelstra、J. TimonおよびP. Wuille、「Enabling Blockchain Innovations with Pegged Sidechains」、2014に記載されている。[オンライン]入手先:http://www.opensciencereview.com/papers/123/enablingblockchain-innovations-with-pegged-sidechains)など、フェデレーテッドブロックチェーンの幾つかの解決策を提案している。
【0004】
前述のチェーンは、それらが通常あらゆるクロスチェーントランザクションを検証するためにメインチェーンまたは親チェーンを関与させ、そうでなければ、それらは、それらが通信するその他のチェーンのコンセンサス構成を前提とするまたは信頼するので、サテライトチェーンまたはサイドチェーンと呼ばれる。例えば、ペグサイドチェーンについてのA. Backらによる上述の著述に紹介されるクロスチェーントランザクションは、常に親チェーンを関与させる。その上、それは、親チェーンの他にサイドチェーンもPoWコンセンサスプロトコルを使用することだけを前提としており、サイドチェーンが異なるコンセンサスプロトコルを使用してよいことは考えていない。
【0005】
別の関連技術は、バルカン(例えば、F. Gai、C. Grajales、J. NiuおよびC. Feng、「A Secure Consensus Protocol for Sidechains arXiv:1906.06490v1」、arXiv preprint arXiv:1906.06490、2019に記載されている)と称されており、それがチェーンのコンセンサスプロトコルとしてBFTを前提とすることを除いては、同様の制限を有する。両解決策において、親チェーンまたはメインチェーンは、サイドチェーン中の資産トランザクションに絶えず関与している。
【0006】
W. Liらによる上述の著述に紹介されるサテライトチェーンは、いかなる「メインチェーン」も関与させることなくクロスチェーン資産移転を許可し、そしてそれは、サテライトチェーンによって使用されるいかなるコンセンサスプロトコルも想定していない。しかしながら、以上の解決策のいずれも、サテライトチェーンまたはサイドチェーンが、別のサテライトチェーンからのいずれの受信したトランザクションのファイナリティプルーフも検証する前提条件である、互いのコンセンサス構成を検証する手段を提供していない。
【先行技術文献】
【非特許文献】
【0007】
【文献】W. Li、A. Sforzin、S. FedorovおよびG. O. Karame、「Towards scalable and private industrial blockchains」、in Proceedings of the ACM Workshop on Blockchain、2017
【文献】A. Back、M. Corallo、L. Dashjr、M. Friedenbach、G. Maxwell、A. Miller、A. Poelstra、J. TimonおよびP. Wuille、「Enabling Blockchain Innovations with Pegged Sidechains」、2014
【文献】F. Gai、C. Grajales、J. NiuおよびC. Feng、「A Secure Consensus Protocol for Sidechains arXiv:1906.06490v1」、arXiv preprint arXiv:1906.06490、2019
【発明の概要】
【発明が解決しようとする課題】
【0008】
したがって本発明の目的は、ブロックチェーンがメインチェーンの関与なしで互いの中のトランザクションのファイナリティプルーフを確認できるというように、異なるブロックチェーンからのノード間の信頼された通信をサポートするための方法およびシステムを改善して更に発展させることである。
【課題を解決するための手段】
【0009】
本発明に従って、前述の目的は、異なるブロックチェーンからのノード間の信頼された通信をサポートするための方法であって、一群のフェデレーテッドブロックチェーンのブロックチェーンの間の信頼をブートストラップするためのブートストラッピングサービスを使用するステップであり、ブートストラッピングサービスがフェデレーテッドブロックチェーンのセキュリティパラメータを記録し、セキュリティパラメータがフェデレーテッドブロックチェーンのコンセンサス構成に関する情報を含む、ステップを含む、方法によって達成される。
【0010】
更には、上述の目的は、異なるブロックチェーンからのノード間の信頼された通信をサポートするためのシステムであって、一群のフェデレーテッドブロックチェーンのブロックチェーンの間の信頼をブートストラップするためのブートストラッピングサービスであり、ブートストラッピングサービスがフェデレーテッドブロックチェーンのセキュリティパラメータを記録するように構成され、セキュリティパラメータがフェデレーテッドブロックチェーンのコンセンサス構成に関する情報を含む、ブートストラッピングサービスを備える、システムによって達成される。
【0011】
本発明によれば、フェデレーテッドブロックチェーンのセキュリティパラメータを記録するように構成され、セキュリティパラメータが特にフェデレーテッドブロックチェーンのコンセンサス構成に関する情報を含む、ブートストラッピングサービスが、フェデレーテッドブロックチェーンの間の信頼をブートストラップする確実かつ効率的な仕方で活用できることが認識されている。この点では、ブートストラッピングサービスは、クロスチェーントランザクション検証の基礎としての役割をし得る。実施形態によれば、ブートストラッピングサービスは、システムにおけるその他のブロックチェーンの全てのコンセンサス構成を維持するように構成されてよく、そしてノードが他のブロックチェーンのコンセンサス情報を登録、更新および照会することを許可してよく、その結果クロスチェーントランザクションのファイナリティプルーフは信頼できる方式で検証できる。本発明がブートストラッピングサービスに対する信頼を必要とするのに対して、それは、あらゆるクロスチェーントランザクションを検証するためにメインチェーンを関与させることは必要としない。
【0012】
実施形態によれば、ブートストラッピングサービスは複数ブロックチェーンに対して作用し得るが、これらが一群のフェデレーテッドブロックチェーンを構成する。例えば、ブロックチェーンがブートストラッピングサービスに登録してフェデレーションに参加できることが規定されてよい。一般に、本開示の文脈では、ブロックチェーン(以降時に簡潔にチェーンとして表される)は、或る分散コンセンサスプロトコルを通じて、共同して分散台帳を維持する複数ノードから成るピアツーピアオーバーレイネットワークである。台帳の内容は、ブロックチェーンネットワークがノード破損に対して堅牢性を提供するようにノードの間で複製される。トランザクションとしても言及されるメッセージがノードの間で伝搬されて、台帳の状態を更新する。台帳を能動的に維持するノードは、それらが台帳を更新するためにトランザクションを確認してコンセンサスプロセスに投票するので、バリデータ(Validator)として表される。台帳の更新を受動的に得るだけであるその他のノードは非バリデータと呼ばれる。
【0013】
実施形態によれば、ブートストラッピングサービスによって記録されるセキュリティパラメータは、フェデレーテッドブロックチェーンの全てのチェーンバリデータのIDおよびフェデレーテッドブロックチェーンのコンセンサス構成に関する情報を含み得るが、これらに限定されない。後者は、基底コンセンサスアルゴリズムの種類およびプロトコル構成パラメータ(例えば、PoWにおける承認長、BFTおよびCFTにおけるフォールトトレランスおよびネットワークサイズ)に関する情報を含み得る。
【0014】
一実施形態によれば、ブートストラッピングサービスにおいて包括的な情報ベースを作成するために、ブートストラッピングサービスがフェデレーテッドブロックチェーンのコンセンサス構成の全ての変更を記録することが規定されてよい。
【0015】
特に、コンセンサス構成のそのような変更は、フェデレーテッドブロックチェーンのいずれかへの新たなバリデータノードの参加によって引き起こされ得る。これらの場合には、ブートストラッピングサービスは、フェデレーテッドブロックチェーンから更新されたコンセンサス構成を、ブロックチェーンの対応するファイナリティプルーフと共に受信するように構成されてよい。更には、ブートストラッピングサービスは、更新されたコンセンサス構成の受信したファイナリティプルーフを、その特定のブロックチェーンに対して記録された元のコンセンサス構成に基づいて検証するように構成されてよい。検証が成功である場合、ブートストラッピングサービスは、削除されてよい元のコンセンサス構成の代わりに更新されたコンセンサス構成を記録してよい。
【0016】
一実施形態によれば、ブートストラッピングサービスにおいて情報ベースの包括性を更に強化するために、ブートストラッピングサービスは、一群のフェデレーテッドブロックチェーン内に確立されるいかなる新たなブロックチェーンも新たなブロックチェーンのコンセンサス構成と共に記録するように構成されてよい。
【0017】
これらの場合には、ブートストラッピングサービスは、確立されるべき新たなブロックチェーンの第1のバリデータノードによって送信されてよい、確立されるべき新たなブロックチェーンの第1の登録要求を受信するように構成されてよい。実施形態によれば、登録要求は、少なくとも新たなブロックチェーンのコンセンサス構成を新たなブロックチェーンのバリデータノードの識別情報と共に含んでよい。この文脈では、ノードがIDおよび新たなチェーンのコンセンサス構成に関してオフラインで同意したかもしれないことが留意されるべきである。ブートストラッピングサービスは、確立されるべき新たなブロックチェーンに対して新たなレコードを追加するように更に構成されてよく、新たなレコードは、新たなブロックチェーンの現状を保留として明記する。
【0018】
ブートストラッピングサービスが新たなブロックチェーンの第2のまたは任意の更なる登録要求(第2のまたは任意の更なるバリデータノードによって送信される)を受信すると、それは、各受信した登録要求に対して、確立されるべき新たなブロックチェーンのコンセンサス構成に基づいて、それらの登録要求を送信したバリデータノードのリストが既に完全であるか否かを判定してよい。それらの登録要求を既に送信したバリデータノードのリストが完全であると判定される場合、ブートストラッピングサービスは、新たなブロックチェーンの状態を保留から準備完了へ更新してよい。そうでなければ、ブートストラッピングサービスは、その登録要求を送信したバリデータノードをリストに加えて更なる登録要求を待ってよい。
【0019】
本発明の実施形態によれば、ブートストラッピングサービスは、第1のブロックチェーンが特定のトランザクションに関する第1のブロックチェーンのファイナリティプルーフを検証することを可能にするために、第2のブロックチェーンのコンセンサス構成に関する第1のブロックチェーン情報を提供することによって、フェデレーテッドブロックチェーンの記録したコンセンサス構成を使用してよい。そのような文脈では、ブートストラッピングサービスは、特定のチェーンBがフェデレーションの別のチェーンAに一部の資産を移転し、そして特定のトランザクションがチェーンBにおいてファイナライズされることをチェーンAに証明することを可能にする。
【0020】
この点では、一実施形態によれば、フェデレーテッドブロックチェーンの第1のブロックチェーンが、フェデレーテッドブロックチェーンの第2のブロックチェーンにトランザクションをトランザクションの第1のブロックチェーンのファイナリティプルーフと共に伝送することによって、第2のブロックチェーンとクロスチェーントランザクションを開始してよい。第2のブロックチェーンは、次いで第1のブロックチェーンのコンセンサス構成に関する情報をブートストラッピングサービスに要求してよい。ブートストラッピングサービスは、第1のブロックチェーンのコンセンサス構成に関する要求された情報を第2のブロックチェーンに返すように構成されてよい。最後に、第2のブロックチェーンは、次いで第1のブロックチェーンのコンセンサス構成に基づいて、トランザクションの第1のブロックチェーンのファイナリティプルーフを検証し、そして検証が成功である場合トランザクションを承認してよい。
【0021】
実施形態によれば、ブートストラッピングサービスは信頼されたサードパーティでよい。この場合、信頼サードパーティの証明書がシステムに参加または関与している全てのフェデレーテッドブロックチェーンの全ての(バリデータ)ノードによって知られておりかつ信頼されていることが想定されてよい。
【0022】
代替実施形態によれば、ブートストラッピングサービスは、ブロックチェーンなどの、例えば複製状態を活用する分散システムでよい。この場合、分散ブートストラッピングサービスのコンセンサス構成が予め定められておりかつシステムに参加または関与している全てのフェデレーテッドブロックチェーンの全ての(バリデータ)ノードによって知られていることが想定されてよい。
【0023】
有利な仕方で本発明の教示を設計して更に発展させる手段が幾つかある。この目的で、一方では従属請求項が、他方では図によって例示される、例としての本発明の好適な実施形態の以下の説明が参照されることになる。図の助けによる本発明の好適な実施形態の説明に関連して、一般に好適な実施形態および本教示の更なる発展が説明されることになる。
【図面の簡単な説明】
【0024】
【図1】本発明の実施形態に従う新たなノードがブロックチェーンに参加することに応じたブートストラッピングサービスにおけるブロックチェーンコンセンサス構成更新を例示する概要図である。
【図2】本発明の実施形態に従うブートストラッピングサービスを通じて新たなブロックチェーンを確立および登録するプロセスを例示する概要図である。
【図3】本発明の実施形態に従うブートストラッピングサービスを通じて2つのブロックチェーン間のトランザクションを達成するプロセスを例示する概要図である。
【発明を実施するための形態】
【0025】
本発明の実施形態は、フェデレーテッドブロックチェーンが互いと通信するために、それらが他のブロックチェーンによって使用されるコンセンサスプロトコルを想定または信頼しなければならないという理解に基づいている。これは、別のブロックチェーンにおいてトランザクションが決済されたことを検証するためには、受け側チェーンがネットワーク定数サイズならびに送り側チェーンのコンセンサスプロトコル種類およびパラメータを知る必要があるからである。より詳細には、トランザクションのファイナリティまたは決済は、対応するブロックチェーンによって採用されるコンセンサスプロトコルに依存する。例えば、ブロックチェーンがそのコンセンサスプロトコルとして実用的ビザンチンフォールトトレランス(PBFT)を使用し、かつ定数サイズが、fをネットワークにおける障害ノードの耐性として、2f+1ノードである場合。そこで、トランザクションのファイナリティプルーフを受けるブロックチェーンは、送り側ブロックチェーンにおける確認ノードの数が少なくともn=3f+1であるかどうか、およびファイナリティプルーフが確認ノードからの少なくともf+1の有効署名を含むかどうかを調べる必要がある。このことは、これらのブロックチェーンがネットワークおよびコンセンサスプロトコル構成についての情報を共有しておらず、その上に、この情報を検証するためにこれらのブロックチェーンの間の確立された信頼がないので、非常に難しい場合がある。
【0026】
これらの課題に対処するために、本発明の実施形態は、フェデレーテッドブロックチェーンの間の信頼をブートストラップすることを意図する方法およびシステムを提供し、これらは次いで、例えばクロスチェーントランザクション検証の基礎としての役割をし得る。実施形態によれば、本方法および本システムはブートストラッピングサービスを使用しまたは備えており、これはブロックチェーンのフェデレーションに関与するブロックチェーンの全てのコンセンサス構成を維持するように構成されてよい。ブートストラッピングサービスは、ノードがブロックチェーンのコンセンサス情報を登録、更新および照会することを許可してよく、その結果クロスチェーントランザクションのファイナリティプルーフは信頼できる方式で検証できる。
【0027】
一部の実施形態において、ブートストラッピングサービス1は、ブロックチェーン4のノード3との対話を許可する、例えばメッセージを送受信するための入出力インタフェース2、1つまたは複数のプロセッサ(図示せず)、およびメモリ(すなわちコンピュータ可読記憶媒体)を少なくとも備えてよい。当業者によって認められるであろうように、挙げた部品の間の通信/対話を可能にするために、それらは、場合により本明細書に具体的には言及されない更なる機能部品またはモジュールと共に、バスシステムを用いて相互接続されてよい。
【0028】
1つまたは複数のプロセッサは、例えば、マイクロプロセッサ、コンピューティングデバイスの中央処理ユニット(CPU)および/または任意の他の専用の特別目的プロセッサもしくは適切なプログラマブルデバイスを含み得る。プロセッサは、とりわけ、本明細書に記載されるプロセスおよび方法に関連したコンピュータ実行可能命令をメモリから取り出して実行するように構成されてよい。実施形態において、コンピュータ実行可能命令はローカルに記憶されており、ハードドライブまたはフラッシュドライブなどの非一時的コンピュータ可読媒体からアクセスされる。リードオンリメモリ(ROM)が、プロセッサを初期化するためのコンピュータ実行可能命令を含んでよい一方で、プロセッサによって実行される命令をロードおよび処理するためにランダムアクセスメモリ(RAM)が展開されてよい。更には、ブートストラッピングサービス1を有線ネットワークまたはセルラネットワークにおよびローカルエリアネットワークまたは、インターネットなどのワイドエリアネットワークに接続するネットワークインタフェース(図示せず)が設けられてよい。
【0029】
本発明の一部の実施形態において、ブートストラッピングサービス1は、信頼されたサードパーティによって運営されてよい。この場合、ブートストラッピングサービス1の証明書がシステムにおける全てのノード3によって、すなわちシステムに参加または関与しているフェデレーテッドブロックチェーン4の全てのノード3によって知られておりかつ信頼されていることが前提とされる。本発明の代替実施形態によれば、ブートストラッピングサービス1は、ブロックチェーンなどの複製状態を持つ分散システムの形態で実装されてよい。この場合、分散ブートストラッピングサービス1のコンセンサス構成が予め定められておりかつシステムにおける全てのノード3によって、すなわちシステムに参加または関与しているフェデレーテッドブロックチェーン4の全てのノード3によって知られていることが前提とされる。詳細には、分散ブートストラッピングサービス1のコンセンサス構成は、基底コンセンサスプロトコルの種類、例えばPoW(プルーフオブワーク)、BFT(ビザンチンフォールトトレランス)、CFT(クラッシュフォールトトレランス)、プロトコルパラメータ(例えば、PoWにおける承認長、BFTおよびCFTにおけるフォールトトレランスおよびネットワークサイズ)、ならびにチェーンバリデータのIDを含んでよく、ID情報はノード3の接続情報の他にその証明書を含んでよい。
【0030】
本発明の実施形態によれば、ブートストラッピングサービス1は、その具体的な実装に関係なく、システムにおける全てのチェーン4のコンセンサス構成情報を維持する。新たなブロックチェーン4のコンセンサス構成のレコードは(CID, <pending_validator_list>, cfg, status)の形態でよい。CIDはチェーンIDを表し、システム内で一意であり、pending_validator_listは、新たなチェーン4が確立される前に新たなチェーン4を登録したノード3を記録し、cfgはチェーン4のコンセンサス構成を含み、そしてチェーン4のstatusはPENDING/READYであることができる。
【0031】
図1は、新たなノード3(図1にaと表される)がバリデータとして既存のチェーン4(図1にAと表される)に参加する場合にブートストラッピングサービス1のレコードを更新するためのプロセスを例示する。チェーンAのコンセンサス構成がcfgAとしてブートストラッピングサービス1に既に登録されている(チェーンIDがCIDAで)ことが前提とされる。
【0032】
ステップS110で図示されるように、ブロックチェーンAに参加するために、ノードaはブロックチェーンAに要求トランザクションJoin(IDa, CIDA, isValidator)を送信する。トランザクションは、aの証明書の対応する秘密鍵によって署名される。用語isValidatorは、ノードaが、ブロックチェーンAのコンセンサス構成に影響し得る、バリデータとしてチェーンAに参加したいかどうかを示すブール値である。
【0033】
ステップS120で、チェーンAのバリデータノード3はノードaの参加要求に対して投票する。バリデータノード3がこの動作で同意すれば、それらはそのコンセンサス構成の更新バージョンcfg'Aおよび対応するプルーフを生成する。更新された構成は、新たなバリデータaのID情報の他に、もしあればプロトコルパラメータへの変更を含んでよい。構成更新のプルーフは基底コンセンサスプロトコルに依存する。例えば、更新前のコンセンサスプロトコル構成がn=4かつf=1のPBFTであれば、プルーフはチェーンAにおけるバリデータの少なくとも2つの署名を含む。
【0034】
ステップS130で、チェーンAは、その更新されたコンセンサス構成cfg'Aの他にステップS120で生成したそのプルーフをトランザクションUpdate(CIDA, cfg'A)としてブートストラッピングサービス1に送信する。ブートストラッピングサービス1は、最初にチェーンAの元のコンセンサス構成cfgAを調べる。次いでそれは、cfgAに基づいてcfg'Aのプルーフを検証する。このトランザクションが決済されると、ブートストラッピングサービス1は、チェーンAに対してそのレコードを(CIDA, cfg'A, READY)として更新するが、READYはチェーンの状態である。
【0035】
一実施形態によれば、ブートストラッピングサービス1が、上記したように分散システムとして実装される場合、Updateメッセージの確認はブートストラッピングサービス1システムのバリデータノードによって実施されてよく、そしてチェーン状態は分散台帳に維持されてよい。
【0036】
図1に関連して記載されたプロセスは、ブートストラッピングサービス1のレコード/台帳(実装に依存する)が常に更新される、すなわちレコード/台帳が、システムに参加または関与している全てのフェデレーテッドブロックチェーンの適用可能なコンセンサス構成についての更新された情報を常に含むことを保証する。
【0037】
図2は、ブートストラッピングサービス1がどのように任意の新たなブロックチェーンの作成について通知されるか、およびそのような新たなブロックチェーンをどのようにブートストラッピングサービス1のレジスタに登録できるかを例示する本発明の一実施形態に係る例証的なプロセスを描く。より詳細には、図2は、図2にxおよびyと表される例証的なノードによって表現される一群のノード3がブートストラッピングサービス1において新たなチェーン4(図2にBと表される)を確立および登録するシナリオを例示する。例示される実施形態において、ノードxおよびy(または、一般用語で、新たなチェーン作成に参加する全てのノード)が新たなチェーンBのIDおよびコンセンサス構成に関して(CIDB, cfgB)としてオフラインで同意したことが前提とされる。
【0038】
最初に、ステップS210で図示されるように、ノードxがブートストラッピングサービス1に、チェーンIDがCIDBおよびコンセンサス構成cfgBでかつIDがIDxのノードxがバリデータノード3である新たなブロックチェーンに対する新たなレコードを開くようにブートストラッピングサービス1に命令すると意図される、トランザクションNew(IDx, CIDB, isValidator, cfgB)を送信する。コンセンサス構成cfgBがチェーンBにおけるバリデータのIDを含むことが想起されるべきである。
【0039】
ステップS220で、ブートストラッピングサービス1は、最初にトランザクションの署名を確認し、次いでIDxがcfgBに含まれるかどうかを調べる。更に、ブートストラッピングサービス1は、実装に応じて、そのレコード内でまたはその台帳内でCIDBについての情報を調べる。チェーンBがまだ登録されていないので、ブートストラッピングサービス1は単にそのレコード/台帳にレコード(CIDB, cfgB, <IDx>, PENDING)を追加する。一方、ブートストラッピングサービス1は、ノードxに要求されたチェーンの現状をStatus(CIDB, <IDx>, PENDING)として返す。
【0040】
ステップS230で図示されるように、別のノード3、すなわちノードyがブートストラッピングサービス1にトランザクションNew(IDy, CIDB, isValidator, cfgB)を送信する。実際には、このステップが、新たなチェーンBの作成に参加する全てのノード3によって実施されることが留意されるべきである。
【0041】
ステップS220と同様に、ステップS240で、ブートストラッピングサービス1は、トランザクション署名を確認し、そしてIDyがcfgBに含まれるかどうかを調べる。次いで、ブートストラッピングサービス1は、レコード(CIDB, cfgB, <IDx>, PENDING)を取り出して、受信した構成cfgBが新たなチェーンBに対して一致しているかどうかを比較する。
【0042】
バリデータノード3のリストが完全であれば、ブートストラッピングサービス1は、S240aで図示されるように、チェーンBの状態を(CIDB, cfgB, READY)として更新し、そしてそれを全ての創設ノードに伝搬し、そうでなければ、それは、S240bで図示されるように、新たなノードyを(CIDB, cfgB, <IDx, IDy>, PENDING)としてリストに加え、更なるチェーン登録要求を待つ。
【0043】
図1および図2に関連して記載されたプロセスは、ブートストラッピングサービス1が既存のブロックチェーン4のコンセンサス構成変更(例えば、それぞれのバリデータノード3の編成の変更による)でも新たなブロックチェーン4およびそれらのそれぞれのコンセンサス構成でも絶えず更新されるように定期的に実施されてよい。それに基づいて、図3は、ブートストラッピングサービス1を通じて実現されるクロスチェーントランザクションのプロセスの例証的な実施形態を例示する。
【0044】
例示される実施形態によれば、図3にチェーンAおよびチェーンBと表される2つのチェーン4がブートストラッピングサービス1を通じてクロスチェーントランザクションを達成するものであるが、チェーンBが一部の資産を移転したく、そしてそれが或るトランザクションTxがチェーンBにおいてファイナライズされることをチェーンAに証明したいことが想定される。本開示の文脈では、用語「トランザクション」は最も広い意味で理解されるべきであり、そして本明細書に記載される方法に従ってブートストラッピングサービス1を実装および活用することによって、本明細書に明示的に言及されるものと異なる他のクロスチェーントランザクションが同様に達成され得る。特に、当業者によって認められるであろうように、トランザクションは、ほんの数例を挙げると、金融取引以外にも、財産交換、サプライチェーンに関与するエンティティおよび選挙における投票についてのデータを含み得る。
【0045】
S310で図示されるように、第1のステップで、チェーンBは、トランザクションTxをそのチェーンアイデンティティ(CIDB)およびトランザクションTxのそのファイナリティプルーフ(proofB)と共に、例えば形式(Tx, CIDB, proofB)のメッセージでチェーンAに送信する。
【0046】
次のステップで、S320で図示されるように、チェーンAは、ブートストラッピングサービス1にチェーンBのコンセンサス構成を照会する。一実施形態によれば、これは、ブートストラッピングサービス1にメッセージInquire(CIDB)を送信することによって達成されてよい。
【0047】
ブートストラッピングサービス1は、すなわち図1および図2に関連して上記した手順の結果として、そのレコード/台帳に要求された情報を維持する。したがって、チェーンAからの照会を受けると、ブートストラッピングサービス1は、そのレコード/台帳からチェーンBの要求されたコンセンサス構成情報を取り出して、この情報を、例えばステップS330で図示されるように形式Info(CIDB, cfgB)のメッセージを送信することを介して、チェーンAに返す。実施形態によれば、ブートストラッピングサービス1から受信されるこのコンセンサス構成情報がチェーンAにおけるバリデータノード3にキャッシュされることが規定されてよく、その結果繰り返される照会を回避できる。
【0048】
最後に、ステップS340で、チェーンAは、ステップ330でブートストラッピングサービス1から受信されたコンセンサス構成cfgBを活用することによって、ステップS310でチェーンBから受信された入力Txに基づいてファイナリティプルーフproofBを検証する。確認が合格すれば、チェーンBからチェーンAへの資産移転は承認される。そうでなければ、資産移転は否定または拒絶されることになる。
【0049】
本明細書に記載される本発明の多くの変更および他の実施形態が、上記説明および関連図面に提示される教示の利益を有する本発明に関係する当業者に想到するであろう。したがって、本発明が開示された具体的な実施形態に限定されないこと、ならびに変更および他の実施形態が添付の請求項の範囲内に含まれると意図されることが理解されるはずである。具体的な用語が本明細書に利用されるが、それらは一般的かつ描写的な意味で使用されるだけであり限定の目的ではない。
【符号の説明】
【0050】
1 ブートストラッピングサービス
2 入出力インタフェース
3 ノード
4 ブロックチェーン
2 入出力インタフェース
3 ノード
4 ブロックチェーン
【図1】
【図2】
【図3】