特許 6705064 ブロックチェーンノード通信方法および装置

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

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

(11)【特許番号】6705064

(24)【登録日】2020年5月15日

(45)【発行日】2020年6月3日

(54)【発明の名称】ブロックチェーンノード通信方法および装置

(51)【国際特許分類】

   G06F 21/44 20130101AFI20200525BHJP

   H04L 9/32 20060101ALI20200525BHJP

【ＦＩ】

   G06F21/44

   H04L9/00 675B

【請求項の数】11

【全頁数】25

(21)【出願番号】特願2019-540595(P2019-540595)

(86)(22)【出願日】2018年7月26日

(86)【国際出願番号】US2018043927

(87)【国際公開番号】WO2019023475

(87)【国際公開日】20190131

【審査請求日】2019年9月25日

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

(32)【優先日】2017年7月26日

(33)【優先権主張国】CN

【早期審査対象出願】

(73)【特許権者】

【識別番号】510330264

【氏名又は名称】アリババ・グループ・ホールディング・リミテッド

【氏名又は名称原語表記】ＡＬＩＢＡＢＡ ＧＲＯＵＰ ＨＯＬＤＩＮＧ ＬＩＭＩＴＥＤ

(74)【代理人】

【識別番号】100188558

【弁理士】

【氏名又は名称】飯田 雅人

(74)【代理人】

【識別番号】100205785

【弁理士】

【氏名又は名称】▲高▼橋 史生

(72)【発明者】

【氏名】ホンリン・チウ

【審査官】 平井 誠

(56)【参考文献】

【文献】 米国特許第８３９２９８０（ＵＳ，Ｂ１）

【文献】 吉濱 佐知子 Sachiko Yoshihama，ブロックチェーン技術とＩＢＭの取り組み，ＰＲＯＶＩＳＩＯＮ ２０１７ Ｎｏ．９１ Professional Vision for Information Technology，日本，日本アイ・ビー・エム株式会社 IBM Japan,Ltd.，２０１７年 ２月２３日，pp.34-39

【文献】 渡邊 大喜 Hiroki WATANABE，ブロックチェーン基盤技術とその課題 Technology and Challenges of Blockchain Platforms，電子情報通信学会技術研究報告 Ｖｏｌ．１１７ Ｎｏ．１１４ IEICE Technical Report，日本，一般社団法人電子情報通信学会 The Institute of Electronics,Information and Communication Engineers，２０１７年 ６月２９日，第117巻，pp.21-26

【文献】 沖野 健一 KENNICHI OKINO，分散台帳技術のセキュリティ要件：銀行口座振替処理への適用，日本銀行 金融研究所ディスカッション・ペーパー・シリーズ 分散台帳技術のセキュリティ要件：銀行口座振替処理への適用 Ｄｉｓｃｕｓｓｉｏｎ Ｐａｐｅｒ Ｎｏ．２０１７−Ｊ−６ ［ｏｎｌｉｎｅ］，日本銀行，２０１７年 ３月２３日，pp.1-19

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

Ｇ０６Ｆ ２１／４４

Ｈ０４Ｌ ９／３２

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

【請求項1】

ブロックチェーンノード通信方法であって、ブロックチェーンネットワークにおけるブロックチェーンノードはサービスノードを含み、前記サービスノードは認証局(CA)によって送信された証明書を記憶するとともに、前記サービスノードにはCA信頼リストが事前設定され、前記方法は、
第1のブロックチェーンノードによって、第2のブロックチェーンノードによって送信された通信リクエストを受信するステップであって、前記通信リクエストは前記第2のブロックチェーンノードの第2の証明書を含む、ステップと、
前記第2の証明書に対応するCA識別子を判定するステップと、
前記第2の証明書に対応する前記判定されたCA識別子が前記CA信頼リストに含まれるか否かを判定するステップと、
前記判定されたCA識別子が前記CA信頼リストに含まれる場合は、前記第2のブロックチェーンノードへの通信接続を確立するステップ、または、
前記判定されたCA識別子が前記CA信頼リストに含まれない場合は、前記第2のブロックチェーンノードへの前記通信接続の確立をスキップするステップと
を含む方法。

【請求項2】

前記ブロックチェーンノードは、コンセンサスノードをさらに備え、前記コンセンサスノードはCAによって送信された証明書を記憶するとともに、前記コンセンサスノードにはCA信頼リストが事前設定される、請求項1に記載の方法。

【請求項3】

前記ブロックチェーンネットワークにおける前記ブロックチェーンノードは、必ずしも同一ではないCAに対応する、請求項1または2に記載の方法。

【請求項4】

第1のブロックチェーンノードによって、第2のブロックチェーンノードによって送信された通信リクエストを受信する前記ステップは、具体的には、
トランスポートレイヤセキュリティ(TLS)ハンドシェイクプロトコルに基づいて前記第1のブロックチェーンノードによって、前記第2のブロックチェーンノードによって送信された前記通信リクエストを受信するステップ
を含む、請求項1に記載の方法。

【請求項5】

前記第2のブロックチェーンノードへの通信接続を確立する前記ステップは、具体的には、
前記第1のブロックチェーンノードによって、前記第2のブロックチェーンノードに確認リクエストを返信するステップであって、前記確認リクエストは、前記第1のブロックチェーンノードの第1の証明書を含み、前記第2のブロックチェーンノードは、前記第1の証明書および前記第2のブロックチェーンノード内に事前設定されたCA信頼リストに基づいて、前記第1のブロックチェーンノードへの前記通信接続を確立するか否かを判定する、ステップ
を含む、請求項1または2に記載の方法。

【請求項6】

ブロックチェーンノード通信装置であって、前記装置は、
第2のブロックチェーンノードによって送信された通信リクエストを受信するように構成された受信モジュールであって、前記通信リクエストは前記第2のブロックチェーンノードの第2の証明書を含む、受信モジュールと、
前記第2の証明書に対応するCA識別子を判定するように構成された判定モジュールと、
前記第2の証明書に対応する前記判定されたCA識別子がCA信頼リストに含まれるか否かを判定し、前記判定されたCA識別子がCA信頼リストに含まれる場合は、前記第2のブロックチェーンノードへの通信接続を確立し、または、前記判定されたCA識別子がCA信頼リストに含まれない場合は、前記第2のブロックチェーンノードへの前記通信接続の確立をスキップするように構成された判定および実行モジュールと
を備え、
ブロックチェーンネットワークにおけるブロックチェーンノードはサービスノードを含み、前記サービスノードはCAによって送信された証明書を記憶するとともに、前記サービスノードには前記CA信頼リストが事前設定される、装置。

【請求項7】

前記ブロックチェーンノードは、コンセンサスノードをさらに備え、前記コンセンサスノードはCAによって送信された証明書を記憶するとともに、前記コンセンサスノードにはCA信頼リストが事前設定される、請求項6に記載の装置。

【請求項8】

前記ブロックチェーンネットワークにおける前記ブロックチェーンノードは、必ずしも同一ではないCAに対応する、請求項6または7に記載の装置。

【請求項9】

前記受信モジュールは、TLSハンドシェイクプロトコルに基づいて、前記第2のブロックチェーンノードによって送信された前記通信リクエストを受信する、請求項6に記載の装置。

【請求項10】

前記判定および実行モジュールは、前記第2のブロックチェーンノードに確認リクエストを返信し、前記確認リクエストは、前記装置の第1の証明書を含み、前記第2のブロックチェーンノードは、前記第1の証明書および前記第2のブロックチェーンノード内に事前設定されたCA信頼リストに基づいて、前記装置への前記通信接続を確立するか否かを判定する、請求項6または7に記載の装置。

【請求項11】

ブロックチェーンノード通信デバイスであって、1つまたは複数のプロセッサと、メモリとを備え、前記メモリはプログラムを記憶し、前記プログラムは、前記1つまたは複数のプロセッサによって実行されて、
第1のブロックチェーンノードにおいて、第2のブロックチェーンノードによって送信された通信リクエストを受信するステップであって、前記通信リクエストは前記第2のブロックチェーンノードの第2の証明書を含む、ステップと、
前記第2の証明書に対応するCA識別子を判定するステップと、
前記第2の証明書に対応する前記判定されたCA識別子がCA信頼リストに含まれるか否かを判定するステップと、
前記判定されたCA識別子がCA信頼リストに含まれる場合は、前記第2のブロックチェーンノードへの通信接続を確立するステップ、または、
前記判定されたCA識別子がCA信頼リストに含まれない場合は、前記第2のブロックチェーンノードへの前記通信接続の確立をスキップするステップと
を実行し、
ブロックチェーンネットワークにおけるブロックチェーンノードはサービスノードを含み、前記サービスノードはCAによって送信された証明書を記憶するとともに、前記サービスノードには前記CA信頼リストが事前設定される、ブロックチェーンノード通信デバイス。

【発明の詳細な説明】

【技術分野】

【0001】

関連出願の相互参照
本出願は、2017年7月26日出願の中国特許出願第201710617463.6号の優先権を主張し、その全体は参照により本明細書に組み込まれる。

【0002】

本出願は、情報技術の分野に関し、特に、ブロックチェーンノード通信方法および装置に関する。

【背景技術】

【0003】

ブロックチェーン技術の一部門として、コンソーシアムブロックチェーン技術がますます使用されている。コンソーシアムブロックチェーンネットワークにおけるブロックチェーンノードは、サービスノードとコンセンサスノードとを含む。サービスノードは、サービスに参加し、コンセンサスノードは、サービスノードによって送信されたサービスデータを受信し、サービスデータのコンセンサス確認を実施する責任を負う。

【0004】

前述のサービスノードは、コンソーシアムブロックチェーンネットワークに参入している各組織のサービスサーバであり、コンソーシアムブロックチェーンネットワークにおける別のノードと通信するためにソフトウェアがサーバ上にインストールされる(このソフトウェアは、本出願において、「通信プログラム」と称される)。

【0005】

図1は、コンソーシアムブロックチェーンネットワークを示す構築図である。図1において図示されるように、中空でない円はコンセンサスノードであり、中空の円はサービスノードである。異なるサービスノードは、異なるアプリケーション(APP：Application)のためのサービスを提供する。サービスノードは、APPによって生成されたサービスデータをコンセンサス確認のためにコンセンサスノードに送信する。1つのサービスノードがケータリングアプリケーションに対応するサーバであると仮定すると、別のサービスノードは支払いアプリケーションに対応するサーバである。ユーザは、ケータリングアプリケーションを通じて注文を行った後、支払いアプリケーションを通じて支払いを行うことができ、このように、2つのサービスノードが同一のサービスに参加し得、図1において図示されるように、コンソーシアムブロックチェーンネットワークにサービス関係を登録することができる。

【発明の概要】

【発明が解決しようとする課題】

【0006】

コンソーシアムブロックチェーンネットワークにおいて、各サービスノードは、そのサービスノードが参加するサービスのサービスデータを記憶し、サービスデータは、通常、ユーザのプライベートデータを含む。既存の技術に基づき、より安全な通信方法が必要とされる。

【課題を解決するための手段】

【0007】

本出願の1つまたは複数の実施態様は、既存の技術における、ブロックチェーンネットワークにおけるサービスノードが通信を実施する際に発生し得るプライバシーデータの流出の問題を解決するブロックチェーンノード通信方法を提供する。

【0008】

本出願の1つまたは複数の実施態様は、既存の技術における、ブロックチェーンネットワークにおけるサービスノードが通信を実施する際に発生し得るプライバシーデータの流出の問題を解決するブロックチェーンノード通信装置を提供する。

【0009】

以下の技術的解決は、本出願の実施態様において使用される。

【0010】

ブロックチェーンノード通信方法が提供される。ブロックチェーンネットワークにおけるブロックチェーンノードはサービスノードを含む。サービスノードは認証局(CA：Certificate Authority)によって送信された証明書を記憶するとともに、サービスノードにはCA信頼リストが事前設定される。方法は、第1のブロックチェーンノードによって、第2のブロックチェーンノードによって送信された通信リクエストを受信するステップであって、通信リクエストは第2のブロックチェーンノードの第2の証明書を含む、ステップと、第2の証明書に対応するCA識別子を判定するステップと、第2の証明書に対応する判定されたCA識別子がCA信頼リストに含まれるか否かを判定するステップと、CA識別子がCA信頼リストに含まれる場合は、第2のブロックチェーンノードへの通信接続を確立するステップ、または、CA識別子がCA信頼リストに含まれない場合は、第2のブロックチェーンノードへの通信接続の確立をスキップするステップとを含む。

【0011】

ブロックチェーンノード通信装置が提供され、装置は、第2のブロックチェーンノードによって送信された通信リクエストを受信するように構成された受信モジュールであって、通信リクエストは第2のブロックチェーンノードの第2の証明書を含む、受信モジュールと、第2の証明書に対応するCA識別子を判定するように構成された判定モジュールと、第2の証明書に対応する判定されたCA識別子がCA信頼リストに含まれるか否かを判定し、CA識別子がCA信頼リストに含まれる場合は、第2のブロックチェーンノードへの通信接続を確立し、または、CA識別子がCA信頼リストに含まれない場合は、第2のブロックチェーンノードへの通信接続の確立をスキップするように構成された判定および実行モジュールとを含み、ブロックチェーンネットワークにおけるブロックチェーンノードはサービスノードを含み、サービスノードはCAによって送信された証明書を記憶するとともに、サービスノードにはCA信頼リストが事前設定される。

【0012】

ブロックチェーンノード通信デバイスが提供される。通信デバイスは、1つまたは複数のプロセッサと、メモリとを含む。メモリはプログラムを記憶し、プログラムは1つまたは複数のプロセッサによって実行されて、第1のブロックチェーンノードにおいて、第2のブロックチェーンノードによって送信された通信リクエストを受信するステップであって、通信リクエストは第2のブロックチェーンノードの第2の証明書を含む、ステップと、第2の証明書に対応するCA識別子を判定するステップと、第2の証明書に対応する判定されたCA識別子がCA信頼リストに含まれるか否かを判定するステップと、CA識別子がCA信頼リストに含まれる場合は、第2のブロックチェーンノードへの通信接続を確立するステップ、または、CA識別子がCA信頼リストに含まれない場合は、第2のブロックチェーンノードへの通信接続の確立をスキップするステップとを実施し、ブロックチェーンネットワークにおけるブロックチェーンノードはサービスノードを含み、サービスノードはCAによって送信された証明書を記憶するとともに、サービスノードにはCA信頼リストが事前設定される。

【0013】

本出願の1つまたは複数の実施態様において使用される1つまたは複数の技術的解決は、以下の有益な効果を達成し得る。

【0014】

ブロックチェーンネットワークにおけるサービスノードはCAによって送信された証明書を記憶するとともに、サービスノードにはCA信頼リストが事前設定される。第2のブロックチェーンノードによって送信された通信リクエストを受信すると、第1のブロックチェーンノードは、先ず、通信リクエストに含まれる第2のブロックチェーンノードの第2の証明書に基づいて、第2の証明書に対応するCA識別子を判定し得、次いで、第2の証明書に対応するCA識別子が、CA信頼リストに含まれるか否かを判定し得る。CA識別子がCA信頼リストに含まれる場合は、第1のブロックチェーンノードは第2のブロックチェーンノードへの通信接続を確立し、または、CA識別子がCA信頼リストに含まれない場合は、第1のブロックチェーンノードは第2のブロックチェーンノードへの通信接続を確立しない。本出願の実施態様において提供される方法によると、通信接続を確立する前に、ブロックチェーンネットワークにおけるサービスノードは、事前設定されたCA信頼リストと通信リクエストに含まれる証明書とに基づいて、通信接続を確立するか否かを判定し得、したがって、サービスノードが通信接続を確立し得る対象(例えば、別のサービスノード)を限定することにより、サービスノードによるプライバシーデータの流出の可能性が低減され得、ブロックチェーンネットワークにおいて記憶されるデータの安全性が向上され得る。

【0015】

本明細書において説明される添付の図面は、本出願のさらなる理解を提供するものと意図され、本出願の一部を構成する。本出願の例示的な実施態様および実施態様の説明は、本出願を説明するものと意図され、本出願に対する制限を構成するものではない。

【図面の簡単な説明】

【0016】

【図1】コンソーシアムブロックチェーンネットワークを示す概略的な構築図である。

【図2】本出願の実施態様による、ブロックチェーンノード通信プロセスを示すフローチャートである。

【図3】本出願の実施態様による、コンソーシアムブロックチェーンネットワークを示す概略的な構築図である。

【図4】本出願の実施態様による、CA関係を示す概略的な図である。

【図5】本出願の実施態様による、ブロックチェーンノード通信装置を示す概略的な構造図である。

【図6】本出願の実施態様による、ブロックチェーンノード通信デバイスを示す概略的な構造図である。

【図7】本開示の実施態様による、ブロックチェーンネットワークの安全性を向上させるための、コンピュータによって実現される方法の例を示すフローチャートである。

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

【0017】

コンソーシアムブロックチェーンネットワークにおいて、サービスノードのサービスへの参加に伴いサービスノードによって生成されたサービスデータは、ユーザのプライベートデータを含む。したがって、コンソーシアムブロックチェーンネットワークにおいて、サービスに参加していないサービスノードへのユーザのプライベートデータの流出を防止するために、各サービスノードは、そのサービスノードが参加しているサービスのサービスデータのみを記憶する。

【0018】

しかしながら、例えばサービスへの実際の適用において、そのサービスに参加していないサービスノードAが、通信プログラムを通じて、そのサービスに参加しているサービスノードBと通信接続を確立し得、(データベースクラッキングなどの)技術的手段を使用してサービスノードBに記憶されたサービスデータを盗み得る。すなわち、通信プログラムを通じて通信接続を確立する各サービスノードは、別のサービスノードに記憶されたサービスデータを、これら2つのサービスノードの間に通信が確立可能である場合は、技術的手段を使用して取得し得る。サービスデータはユーザのプライベートデータを含み得るので、本開示は、より安全な通信技術的解決を提供する。

【0019】

本出願の実施態様の目的、技術的解決および利点をより明確にするため、以下において、本出願の技術的解決を、対応する添付の図面および本出願の1つまたは複数の特定の実施態様を参照して、明確に説明する。明らかなことであるが、説明される実施態様は、本出願の実施態様のすべてではなく、本出願の実施態様のうちのいくつかであるにすぎない。本出願の1つまたは複数の実施態様に基づいて、創造的な取り組みなしに当業者によって得られるすべての他の実施態様は、本出願の保護範囲内にあるべきものである。本出願の実施態様において提供される技術的解決が、添付の図面を参照して、以下に詳細に説明される。

【0020】

図2は、本出願の実施態様によるブロックチェーンノード通信プロセスを示す。ブロックチェーンネットワークにおけるブロックチェーンノードはサービスノードを含む。サービスノードは認証局(CA)によって送信された証明書を記憶するとともに、サービスノードにはCA信頼リストが事前設定される。ブロックチェーンノード通信プロセスは、以下のステップを含み得る。

【0021】

S202：第1のブロックチェーンノードが、第2のブロックチェーンノードによって送信された通信リクエストを受信する。

【0022】

本出願の1つまたは複数の実施態様において、コンソーシアムブロックチェーンネットワークにおけるブロックチェーンノードは、相互に通信可能である。サービスノードは、サービスを実行するために通信し得、データを送り得る。サービス実行中に生成されたサービスデータは、コンセンサス確認のためにコンセンサスノードに送信される。コンセンサスノードによってサービスデータが確認された後、サービスデータはブロックチェーンにおいて記憶される。したがって、ブロックチェーンネットワークにおける任意のブロックチェーンノードは、別のブロックチェーンノードによって送信された通信リクエストを受信し得る。説明を容易にするために、本出願の実施態様においては、通信リクエストを受信する例示的ブロックチェーンノードは第1のブロックチェーンノードと称され、通信リクエストを送信するブロックチェーンノードは第2のブロックチェーンノードと称される。加えて、通信リクエストとは、第2のブロックチェーンノードによって送信された通信接続を確立するためのリクエストであり得、第1のブロックチェーンノードは、後続のステップに基づいて、リクエストに応答して第2のブロックチェーンノードへの通信接続を確立するか否かを判定し得る。

【0023】

ブロックチェーンネットワークの構造が、図1において図示され得る。ブロックチェーンノードは、サービスノードとコンセンサスノードとを含み得る。コンセンサスノードであるかまたはサービスノードであるかに関わらず、ブロックチェーンノードは、CAによって送信された証明書を記憶し得、ブロックチェーンノードにはCA信頼リストが事前設定されている。

【0024】

具体的には、サービスノードを例として使用すると、図1のアーキテクチャにおいて図示されるように、コンソーシアムブロックチェーンネットワークには複数のサービス関係が存在し得、各サービス関係は少なくとも2つのサービスノードを含む。上述のように、サービスノードは、コンソーシアムブロックチェーンネットワークに参入する、必ずしも同一ではない組織のサービスサーバであり得る。同一のサービス関係におけるサービスサーバは共同でサービスを実行し、コンセンサス確認のためにコンセンサスノードにサービスデータを送信する(例えば、売り手の銀行、買い手の銀行、さらには中間取引プラットフォームさえもが支払いサービスに参加することがある。したがって、支払いサービスにおいて、3つの組織のサービスサーバが、同一のサービスの異なる手続きにおいて必ずしも同一ではないステップを実施し、最終的に、コンセンサス確認が実施されるべきサービスデータを生成することがある)。説明を容易にするために、すべての後続のサービスノードは、組織のサービスサーバと見なされ得る。

【0025】

加えて、本出願の1つまたは複数の実施態様において、各サービス関係は、1つのCAに対応し、または、同一のサービス関係におけるサービスノードは、同一のCAに対応するものと見なされ得る。サービス関係においてサービスを実行する各サービスノードについて、サービスを実行するこのようなサービスノードを構成するために、先ず、同一性(identity)確認リクエスト(Verification Request)が、サービス関係に対応するCAに送信され得る。同一性確認リクエストは、サービスノードが属する組織を含む。

【0026】

CAは、既存の技術における方法を使用してサービスノードの同一性を確認し得、サービスノードが確認された後、サービスノードの証明書を作成し、この証明書をサービスノードへと返信する。

【0027】

したがって、本出願の1つまたは複数の実施態様において、各サービスノードは証明書を記憶し得る。証明書は、サービスノードに対応するCAによって送信される。既存の技術と同様に、証明書は、サービスノードの識別子を含み得、証明書の公開キーは、証明書を発行したCAの署名を含む。別のブロックチェーンノードもまた、既存の技術における方法を使用した証明書に基づいて、サービスノードの同一性およびサービスノードの証明書を発行したCAの識別子を判定し得る。

【0028】

さらに、第2のブロックチェーンノードが第1のブロックチェーンノードに通信リクエストを送信するとき、通信リクエストは、第2のブロックチェーンノードに記憶された第2の証明書をさらに含み得る。第2の証明書は、第2のブロックチェーンノードに対応するCAによって第2のブロックチェーンノードに対して発行された証明書である。通信リクエストを受信した後、第1のブロックチェーンノードは、第2の証明書に基づいて、第2のブロックチェーンノードの同一性および第2のブロックチェーンノードに対応するCAを判定し得る。

【0029】

さらに、本出願の1つまたは複数の実施態様において、コンソーシアムブロックチェーンネットワークにおけるブロックチェーンノードは、トランスポートレイヤセキュリティ(TLS：Transport Layer Security)を使用して通信接続を確立し得、第2のブロックチェーンノードは、TLSハンドシェイクプロトコル(TLSハンドシェイク)に基づいて、第1のブロックチェーンノードに送信される通信リクエストに対して、第2のブロックチェーンノードの第2の証明書を追加する。

【0030】

各ブロックチェーンノードには、さらにCA信頼リストが設定されることが留意されるべきである。CA信頼リストは、CAによってブロックチェーンノードに送信され得、または、ブロックチェーンノードによって設定され得る。このことは本出願に限定されるわけではない。CA信頼リストがブロックチェーンノードによって設定されるとき、CA信頼リストは、ブロックチェーンノードに対応する組織による要件に基づいて、ブロックチェーンノードに設定される。CA信頼リストがCAによって設定される場合は、CAによって送信される証明書に加えて、ブロックチェーンノードは、CAによって送信されるCA信頼リストをさらに受信し得、CA信頼リストを記憶し得る。CA信頼リストは1つまたは複数のCA識別子を含む。

【0031】

本出願の1つまたは複数の実施態様において、第1のブロックチェーンノードおよび第2のブロックチェーンノードは、コンソーシアムブロックチェーンネットワークにおけるサービスノードまたはコンセンサスノードであり得る。ブロックチェーンノードがコンセンサスノードであるとき、コンセンサスノードは、コンセンサス確認を実施するように構成されたコンセンサスサーバであり得、コンセンサスサーバは、コンソーシアムブロックチェーンに参加する組織によって提供される。すなわち、コンセンサスノードは、任意の組織に属することのない、サービスに参加しないサーバと見なされ得る。もちろん、各サーバ(例えば、各サービスサーバおよび各コンセンサスサーバ)は、別個のデバイスであってよく、または、複数のデバイスを含むシステムであってよい。このことは本出願に限定されるわけではない。

【0032】

S204：第2の証明書に対応するCA識別子を判定する。

【0033】

本出願の1つまたは複数の実施態様において、通信リクエストを受信した後、第1のブロックチェーンノードは、通信リクエストに含まれる第2のブロックチェーンノードの第2の証明書を判定し得、次いで、第2の証明書に対応するCA識別子をさらに判定し得る。

【0034】

具体的には、証明書は、証明書を発行するCAの署名を含むので、通信リクエストに含まれる第2の証明書を判定した後、第1のブロックチェーンノードは、第2の証明書における署名に基づいて、第2のブロックチェーンノードに対して証明書を発行するCAのCA識別子を判定し得る。すなわち、通信リクエストを受信した後、サービスノードは、通信リクエストに含まれる第2の証明書のCA識別子を判定し得る。

【0035】

S206：第2の証明書に対応する判定されたCA識別子がCA信頼リストに含まれるか否かを判定する。イエスである場合はS208を実施し、または、ノーである場合はS210を実施する。

【0036】

本出願の1つまたは複数の実施態様において、コンソーシアムブロックチェーンネットワークにおける各ブロックチェーンノードにはCA信頼リストが設定され、CA信頼リストは1つまたは複数のCA識別子を含む。したがって、第1のブロックチェーンノードは、事前設定されたCA信頼リストにおけるCA識別子に基づいて、第2の証明書に対応するCA識別子が第1のブロックチェーンノードに設定されたCA信頼リストに含まれるか(例えば、CA信頼リストにおけるCA識別子のうちの任意の1つと一致するか)を判定し得る。すなわち、第1のブロックチェーンノードは、第2の証明書に対応するCA識別子が信頼されるか否かを判定する。

【0037】

第2の証明書に対応するCA識別子が事前設定されたCA信頼リストに含まれる場合は、第1のブロックチェーンノードは、CA識別子は信頼されると判定し得、S208を実施し得る。第2の証明書に対応するCA識別子が事前設定されたCA信頼リストに含まれない場合は、第1のブロックチェーンノードは、CA識別子は信頼されないと判定し得、S210を実施し得る。

【0038】

S208：第2のブロックチェーンノードへの通信接続を確立する。

【0039】

本出願の1つまたは複数の実施態様において、CA識別子が信頼されると判定したとき、第1のブロックチェーンノードは、第2のブロックチェーンノードへの通信接続を確立し得る。

【0040】

具体的には、第1のブロックチェーンノードは、第2のブロックチェーンノードへの通信接続を直接的に確立し得る。通信の安全性をさらに確保するために、第1のブロックチェーンノードも、第1のブロックチェーンノードの第1の証明書を第2のブロックチェーンノードに送信し得、第1の証明書における非公開キーを、第2のブロックチェーンノードに送信されるデータを暗号化するために使用し得る。同様に、第1のブロックチェーンノードへとデータを送信するとき、第2のブロックチェーンノードも、第2の証明書における非公開キーを使用してデータを暗号化し得る。

【0041】

さらに、本出願の1つまたは複数の実施態様において、ブロックチェーンネットワークにおけるブロックチェーンノードは、TLSハンドシェイクプロトコルに基づいて通信接続を確立し得る。したがって、第2のブロックチェーンノードへの通信接続を確立することを判定した後、第1のブロックチェーンノードは、さらに、第2のブロックチェーンノードに確認リクエストを返信し得る。

【0042】

具体的には、確認リクエストは、第1のブロックチェーンノードの第1の証明書を含む。第2のブロックチェーンノードもS202からS206を実施して、第1の証明書に対応するCA識別子が第2のブロックチェーンノードに設定されたCA信頼リストに含まれるか否かを判定し得る。イエスである場合は、第2のブロックチェーンノードは、第1のブロックチェーンノードへの通信接続を確立し、または、ノーである場合は、第2のブロックチェーンノードは第1のブロックチェーンノードへの通信接続を確立しない。すなわち、第2のブロックチェーンノードも、第1のブロックチェーンノードの第1の証明書に対応するCA識別子が信頼されるかを確認し得る。イエスである場合は、第2のブロックチェーンノードは、第1のブロックチェーンノードへの通信接続を確立し、または、ノーである場合は、第2のブロックチェーンノードは第1のブロックチェーンノードへの通信接続を確立しない。

【0043】

通信接続を確立するとき、第1のブロックチェーンノードおよび第2のブロックチェーンノードは、既存の技術におけるTLSハンドシェイクプロセスと類似したプロセスを使用して通信において使用されるキーを判定し得、このキーを使用して、送られるデータを暗号化し得る。もちろん、TLSハンドシェイクプロセスは比較的成熟した技術である。本出願においては、詳細は説明されない。

【0044】

S210：第2のブロックチェーンノードへの通信接続の確立をスキップする。

【0045】

本出願の1つまたは複数の実施態様において、第2の証明書に対応するCA識別子が第1のブロックチェーンノードに設定されたCA信頼リストに含まれないと判定すると、第1のブロックチェーンノードは、第2のブロックチェーンノードへの通信接続を確立しないことを判定し得る。加えて、第1のブロックチェーンノードが、第2のブロックチェーンノードに確認リクエストを送信する必要はなくてよい。

【0046】

図2において図示されるブロックチェーンノード通信方法によると、ブロックチェーンネットワークにおけるサービスノードはCAによって送信された証明書を記憶するとともに、サービスノードにはCAによって送信されたCA信頼リストが設定されることが分かる。加えて、ブロックチェーンネットワークにおけるコンセンサスノードも、CAによって送信された証明書を記憶し得るとともに、CAによって送信されたCA信頼リストが設定され得る。第2のブロックチェーンノードによって送信された通信リクエストを受信すると、ブロックチェーンネットワークにおける第1のブロックチェーンノードは、先ず、通信リクエストに含まれる第2のブロックチェーンノードの第2の証明書に基づいて、第2の証明書に対応するCA識別子を判定し得、次いで、事前設定されたCA信頼リストにおけるCA識別子に基づいて、第2の証明書に対応するCA識別子が信頼されるか否かを判定し得る。イエスである場合は、第1のブロックチェーンノードは第2のブロックチェーンノードへの通信接続を確立し、または、ノーである場合は、第1のブロックチェーンノードは第2のブロックチェーンノードへの通信接続を確立しない。本開示の1つまたは複数の実施態様において提供される方法によると、通信接続を確立する前に、ブロックチェーンネットワークにおけるサービスノードは、事前設定されたCA信頼リストと通信リクエストに含まれる証明書とに基づいて、通信接続を確立するか否かを判定し得る。したがって、サービスノードが通信接続を確立し得る対象(例えば、別のサービスノード)を限定することにより、サービスノードによるプライバシーデータの流出の可能性が低減され得、ブロックチェーンネットワークにおいて記憶されるデータの安全性を向上させ得る。

【0047】

加えて、図2において図示されるブロックチェーンノード通信方法は、サービスノードおよびコンセンサスノードの両方に適用可能であり、サービスノードのための通信接続確立プロセスとコンセンサスノードのための通信接続確立プロセスとの間に違いはない。通信接続を確立するかは、ノードに記憶された証明書および事前設定されたCA信頼リストだけに基づいて判定され得る。第1のブロックチェーンノードは、サービスノードまたはコンセンサスノードであり得る。同様に、第2のブロックチェーンノードは、サービスノードまたはコンセンサスノードであり得る。もちろん、コンセンサスノードは、通常、サービスノードによって送信される、コンセンサス確認が実施されるべきデータを受信するようにのみ構成されるので、第2のブロックチェーンノードは、通常、サービスノードである。このことは本出願の実施態様に限定されるわけではない。

【0048】

さらに、例として図1において図示されるブロックチェーンネットワークを使用すると、各ブロックチェーンノードが1つのCAに対応し、同一のサービス関係におけるブロックチェーンノードが同一のCAに対応し得るとき、コンソーシアムブロックチェーンネットワークのアーキテクチャは図3のように図示され得る。各サービス関係はCA(すなわち、図3における点線の円)を含むことが分かる。CAは、関係している各サービスノードに対して証明書を発行するように構成される。加えて、複数のCAがコンセンサスノードにおいて存在し得、異なるコンセンサスノードに対して証明書を発行し得る。各サービスノードは、コンセンサス確認が実施されるべきデータを異なるコンセンサスノードに対して送信し得る。同一のCAによって発行された証明書を有するコンセンサスノードが、データにコンセンサス確認を実施する。1つのブロックチェーンノードが複数のCAによって送信された証明書を受信し得、このようなブロックチェーンノードには、1つまたは複数のCA信頼リストが設定され得ることが留意されるべきである。別のブロックチェーンノードに通信リクエストを送信するとき、任意の証明書が通信リクエストに追加され得る。このことは本出願に限定されるわけではない。

【0049】

加えて、複数グループのコンセンサスノードが個別にコンセンサス確認を実施する既存のブロックチェーン、例えば、Cordaプロトコルに基づくブロックチェーンにおいて、コンセンサスノードに記憶されたブロックチェーンは必ずしも同一ではないので、コンセンサスノードがコンセンサス確認が実施されるべき同一のサービスデータにコンセンサス確認を実施した後に得られる結果は異なり得る。したがって、ブロックチェーンにおいてデータを転送するための方法(これは、Cordaプロトコルにおいてはnotary転送と称される)が存在し得る。本開示の1つまたは複数の実施態様において、同じ方法が、異なるコンセンサスノードにおいてデータを転送するために使用され得る。本開示においては、詳細は説明されない。もちろん、代替的に、本開示の1つまたは複数の実施態様において、コンセンサスノードの証明書は、ただ1つのCAよって発行されてよい。このことは本開示に限定されるわけではない。

【0050】

さらに、既存の技術における複数のCAの間での相互の信頼はルートCAによって支援されることを必要とするので、各ブロックチェーンノードに設定されたCA信頼リストを、TLSハンドシェイクプロトコルにおいて通信接続を確立するか否かを判定するために使用可能とするために、図4が参照され得る。図4は、本出願の実施態様によるCA関係を示す概略的な図である。ルートCAは、サードパーティCAであり得、コンソーシアムブロックチェーンCAは、サードパーティCAによって発行された証明書に基づいて作成され得る。コンソーシアムブロックチェーンCAは、ブロックチェーンノードのCAに対して証明書を発行し(例えば、第1のCA、第2のCAおよび第3のCAに対して証明書を発行する)、最終的に、ブロックチェーンノードのCAが、ブロックチェーンノード証明書をブロックチェーンに対して送信する(例えば、第1のCAは、ブロックチェーンノード証明書1〜nを発行し、第2のCAは、ブロックチェーンノード証明書m〜pを発行し、ノード証明書は、必ずしも同一ではないブロックチェーンノードに送信され得る)。もちろん、証明書に基づく証明書信頼チェーンは比較的成熟した技術である。本出願の実施態様においては、詳細は説明されない。

【0051】

本開示の1つまたは複数の実施態様において提供される方法のステップは、1つのデバイスによって実施されてよく、または方法は異なるデバイスによって実施されてよいことが留意されるべきである。例えば、S202およびS204がデバイス1によって実施され、S206がデバイス2によって実施されてよい。別の例として、S202がデバイス1によって実施され、S204およびS206がデバイス2によって実施されてよい。本開示の特定の実施態様が上記において説明された。他の実施態様も添付の特許請求の範囲の範囲内にある。いくつかの場合おいて、特許請求の範囲において説明されるアクションまたはステップは、実施態様における順序とは異なる順序で実施され得、それでもなお所望の結果が達成され得る。加えて、添付の図面において描かれるプロセスは、所望の結果を達成するために、必ずしも特定の実行順序を必要としない。いくつかの実施態様において、マルチタスクおよび並行処理が有利であり得る。

【0052】

図2において図示されるブロックチェーンノード通信プロセスに基づいて、本出願の実施態様は、図5において図示されるブロックチェーンノード通信装置をさらに提供する。

【0053】

図5は、本出願の実施態様による、ブロックチェーンノード通信装置を示す概略的な構造図である。ブロックチェーンノード通信装置は、第2のブロックチェーンノードによって送信された通信リクエストを受信するように構成された受信モジュール302であって、ブロックチェーンネットワークにおけるブロックチェーンノードはサービスノードを含み、サービスノードはCAによって送信された証明書を記憶するとともに、サービスノードにはCA信頼リストが事前設定される、受信モジュール302を含み、装置は、第2の証明書に対応するCA識別子を判定するように構成された判定モジュール304と、第2の証明書に対応する判定されたCA識別子がCA信頼リストに含まれるか否かを判定し、イエスである場合は、第2のブロックチェーンノードへの通信接続を確立し、または、ノーである場合は、第2のブロックチェーンノードへの通信接続の確立をスキップするように構成された判定および実行モジュール306とをさらに含む。

【0054】

ブロックチェーンノードはコンセンサスノードをさらに含み、コンセンサスノードはCAによって送信された証明書を記憶するとともに、コンセンサスノードにはCA信頼リストが事前設定される。

【0055】

ブロックチェーンネットワークにおけるブロックチェーンノードはCAに対応するが、これらのCAは同一ではない。

【0056】

受信モジュール302は、TLSハンドシェイクプロトコルに基づいて、第2のブロックチェーンノードによって送信された通信リクエストを受信する。

【0057】

判定および実行モジュール306は、第2のブロックチェーンノードに確認リクエストを返信し、確認リクエストは、装置の第1の証明書を含み、第2のブロックチェーンノードは、第1の証明書および第2のブロックチェーンノード内に事前設定されたCA信頼リストに基づいて、装置への通信接続を確立するか否かを判定する。

【0058】

具体的には、ブロックチェーンノード通信装置は、ブロックチェーンノード内に位置し得る。ブロックチェーンノードは、コンソーシアムブロックチェーンネットワークにおけるサービスノードまたはコンセンサスノードであり得る。このことは本開示に限定されるわけではない。加えて、コンソーシアムブロックチェーンネットワークにおけるコンセンサスノードは、コンソーシアムのメンバー(組織)によって提供されるサーバであってもよいので、ブロックチェーンノードはコンセンサスサーバであってよい。もちろん、代替的に、ブロックチェーンノードがサービスノードであるとき、サービスノードは組織のサービスサーバであってもよい。

【0059】

加えて、サーバ(例えば、サービスサーバまたはコンセンサスサーバ)は、別個のデバイスであってよく、または、分散サーバなど、複数のデバイスを含むシステムであってよい。しかしながら、サーバが1つのデバイスであるか2つ以上のデバイスであるかに関わらず、コンソーシアムブロックチェーンネットワークにおけるサーバは、ブロックチェーンノードと見なされ得る。

【0060】

図2において図示されるブロックチェーンノード通信プロセスに基づいて、本出願の実施態様は、図6において図示されるブロックチェーンノード通信デバイスをさらに提供する。

【0061】

図6は、本出願の実施態様による、ブロックチェーンノード通信デバイスを示す概略的な構造図である。通信デバイスは、1つまたは複数のプロセッサと、メモリとを含む。メモリはプログラムを記憶し、プログラムは、1つまたは複数のプロセッサによって実行されて、第1のブロックチェーンノードにおいて、第2のブロックチェーンノードによって送信された通信リクエストを受信するステップであって、通信リクエストは第2のブロックチェーンノードの第2の証明書を含む、ステップと、第2の証明書に対応するCA識別子を判定するステップと、第2の証明書に対応する判定されたCA識別子がCA信頼リストに含まれるか否かを判定するステップと、イエスである場合は、第2のブロックチェーンノードへの通信接続を確立するステップ、または、ノーである場合は、第2のブロックチェーンノードへの通信接続の確立をスキップするステップとを実施する。

【0062】

ブロックチェーンネットワークにおけるブロックチェーンノードはサービスノードを含む。サービスノードはCAによって送信された証明書を記憶するとともに、サービスノードにはCA信頼リストが事前設定される。

【0063】

加えて、ブロックチェーンノードはコンセンサスノードであり得、ブロックチェーンノード通信デバイスを使用して別のブロックチェーンノードへの通信接続を確立するとき、同一のステップを実施する。

【0064】

1990年代には、技術の向上が、ハードウェアの向上(例えば、ダイオード、トランジスタ、またはスイッチなどの回路の構造の向上)であるか、または、ソフトウェアの向上(方法手順の向上)であるかは明確に区別され得た。しかしながら、技術が発展するにつれて、現在の多くの方法手順における向上は、ハードウェア回路構造の直接的な向上であると見なされ得る。設計者は、通常、向上された方法手順をハードウェア回路にプログラムし、対応するハードウェア回路構造を得る。したがって、方法手順は、ハードウェア実体モジュールを使用することによって向上され得る。例えば、プログラマブル論理デバイス(PLD：Programmable Logic Device)(例えば、フィールドプログラマブルゲートアレイ(FPGA：Field Programmable Gate Array))はそのような集積回路であり、プログラマブル論理デバイスの論理機能は、デバイスのプログラミングを通じてユーザにより決定される。設計者は、チップ製造者に特定用途向け集積回路チップを設計および製作することを要求することなく、デジタルシステムをPLDに「一体化」するようにプログラミングを実施する。加えて、プログラミングは、多くの場合、手作業で集積回路チップを作成するのではなく、「論理コンパイラ」ソフトウェアを修正することにより実施される。このことは、プログラム開発およびコンパイルのために使用されるソフトウェアコンパイラに類似している。しかしながら、コンパイルする前のオリジナルコードも、ハードウェア記述言語(HDL：Hardware Description Language)と称される特定のプログラミング言語で記述される。Advanced Boolean Expression Language(ABEL)、Altera Hardware Description Language(AHDL)、Confluence、Cornell University Programming Language(CUPL)、HDCal、Java(登録商標) Hardware Description Language(JHDL)、Lava、Lola、MyHDL、PALASM、およびRuby Hardware Description Language(RHDL)などの多くのHDLが存在する。現在、Very-High-Speed Integrated Circuit Hardware Description Language(VHDL)およびVerilogが最も広く使用されている。当業者は、方法手順が、いくつかの説明されたハードウェア記述言語を使用することによって論理的にプログラムされ、集積回路にプログラムされることで、論理的方法手順を実施するハードウェア回路は容易に得られることも、理解すべきである。

【0065】

コントローラは、任意の適切なやり方において実現され得る。例えば、コントローラは、マイクロプロセッサ、プロセッサ、または、プロセッサ(またはマイクロプロセッサ)によって実行され得るコンピュータ可読プログラムコード(例えば、ソフトウェアまたはファームウェア)を記憶するコンピュー可読媒体、論理ゲート、スイッチ、特定用途向け集積回路(ASIC：Application-Specific Integrated Circuit)、プログラマブル論理コントローラ、もしくは埋込型マイクロコントローラであり得る。コントローラの例としては、以下のマイクロコントローラ、すなわち、ARC 625D、Atmel AT91SAM、Microchip PIC18F26K20、またはSilicon Labs C8051F320が挙げられるが、これらに限定されるものではない。メモリコントローラも、メモリの制御論理の一部として実現され得る。当業者は同様に承知していることであろうが、コントローラは、純粋なコンピュータ可読プログラムコードとして実現され得、方法におけるステップは、コントローラが、論理ゲート、スイッチ、特定用途向け集積回路、プログラマブル論理コントローラ、埋込型マイクロコントローラなどの形態で同一の機能を実現し得るように、論理的にプログラムされ得る。したがって、コントローラは、ハードウェアコンポーネントと見なされ得、コントローラにおける様々な機能を実現するように構成された装置もまた、ハードウェアコンポーネントにおける構造と見なされ得る。代替的に、様々な機能を実現するように構成された装置は、方法またはハードウェアコンポーネントにおける構造を実現し得るソフトウェアモジュールと見なされ得る。

【0066】

前述の実施態様において示されたシステム、装置、モジュール、またはユニットは、コンピュータチップまたは実体を使用することによって実現され得、または、特定の機能を有する製品を使用することによって実現され得る。具体的には、コンピュータは、例えば、パーソナルコンピュータ、ラップトップコンピュータ、携帯電話、カメラ電話、スマートフォン、パーソナルデジタルアシスタント、メディアプレイヤ、ナビゲーションデバイス、電子メールデバイス、ゲームコンソール、タブレットコンピュータ、ウェアラブルデバイス、またはこれらのデバイスのうちの任意のものの組合せであり得る。

【0067】

説明を容易にするために、説明される装置は、機能を様々なユニットに分割することによって説明される。もちろん、本出願が実現されるとき、各ユニットの機能は、1つまたは複数のソフトウェアおよび/またはハードウェアにおいて実現されてよい。

【0068】

当業者は、本開示の実施態様は、方法、システム、またはコンピュータプログラム製品として提供され得ることを理解するべきである。したがって、本開示は、ハードウェアのみの実施態様、ソフトウェアのみの実施態様、または、ソフトウェアとハードウェアとの組合せによる実施態様の形態を使用し得る。加えて、本開示は、コンピュータで使用可能なプログラムコードを含むコンピュータで使用可能な1つまたは複数の記憶媒体(磁気ディスクメモリ、コンパクトディスク読み取り専用メモリ(CD-ROM：compact disc read-only memory)、光学的メモリが挙げられるが、これらに限定されない)上で実現されるコンピュータプログラム製品の形態を使用し得る。

【0069】

本開示は、本開示の実施態様に基づく方法、デバイス(システム)、およびコンピュータプログラム製品のフローチャートおよび/またはブロック図を参照して説明される。フローチャートおよび/またはブロック図における各手順および/または各ブロック、ならびにフローチャートおよび/またはブロック図における手順および/またはブロックの組合せを実現するために、コンピュータプログラム命令が使用され得ることが理解されるべきである。これらのコンピュータプログラム命令は、汎用コンピュータ、専用コンピュータ、埋込型プロセッサ、または別のプログラマブルデータ処理デバイスのプロセッサに提供されてマシンを生成することができ、命令はコンピュータまたは別のプログラマブルデータ処理デバイスのプロセッサによって実行され、フローチャートにおける1つまたは複数の手順、および/またはブロック図における1つまたは複数のブロックにおいて、指定された機能を実現するための装置を生成する。

【0070】

これらのコンピュータプログラム命令は、特定のやり方で動作するようにコンピュータまたは別のプログラマブルデータ処理デバイスに命令し得るコンピュータ可読メモリに記憶され得、コンピュータ可読メモリに記憶された命令は、命令装置を含むアーチファクトを生成する。命令装置は、フローチャートにおける1つまたは複数の手順、および/またはブロック図における1つまたは複数のブロックにおいて、特定の機能を実現する。

【0071】

これらのコンピュータプログラム命令は、コンピュータまたは別のプログラマブルデータ処理デバイスにロードされ得、コンピュータまたは別のプログラマブルデバイス上で一連の動作およびステップが実施され、コンピュータによって実現される処理を生成する。したがって、コンピュータまたは別のプログラマブルデバイス上で実行される命令は、フローチャートにおける1つまたは複数の手順、および/またはブロック図における1つまたは複数のブロックにおいて、指定された機能を実現するためのステップを提供する。

【0072】

典型的な構成においては、コンピューティングデバイスは、1つまたは複数のプロセッサ(CPU)、入力/出力インターフェース、ネットワークインターフェース、およびメモリを含む。

【0073】

メモリとしては、読み取り専用メモリ(ROM)もしくはフラッシュメモリなどのコンピュータ可読媒体における揮発性メモリ、ランダムアクセスメモリ(RAM：Random Access Memory)、および/または不揮発性メモリなどが挙げられる。メモリは、コンピュータ可読媒体の一例である。

【0074】

コンピュータ可読媒体としては、任意の方法または技術を使用することによって情報を記憶し得る持続的、非持続的、可動性、および非可動性の媒体が挙げられる。情報は、コンピュータ可読命令、データ構造、プログラムモジュール、または他のデータであり得る。コンピュータ記憶媒体の例としては、相変化RAM(PRAM：Phase change RAM)、スタティックRAM(SRAM：Static RAM)、ダイナミックRAM(DRAM：Dynamic RAM)、他のタイプのRAM、ROM、電気的消去可能プログラマブル読み取り専用メモリ(EEPROM：Electrically Erasable Programmable Read-Only Memory)、フラッシュメモリもしくは別のメモリ技術、コンパクトディスク読み取り専用メモリ(CD-ROM)、デジタル多用途ディスク(DVD：Digital Versatile Disc)もしくは別の光学的記憶装置、磁気テープ、磁気ディスク記憶装置、別の磁気記憶デバイス、または任意の他の非伝送媒体が挙げられるが、これらに限定されない。コンピュータ記憶媒体は、コンピューティングデバイスによってアクセスされ得る情報を記憶するために使用され得る。本出願において説明されるように、コンピュータ可読媒体は、一時的媒体、例えば変調データ信号および搬送波を含まない。

【0075】

「含む(include)」、「備える(comprise)」という用語、またはそれらの任意の他の変形は、非排他的な包含をカバーするものと意図され、一連の要素を含むプロセス、方法、物品、またはデバイスは、これらの要素を含むだけでなく、明示的に列挙されていない他の要素も含み、または、そのようなプロセス、方法、物品、またはデバイスに固有の要素をさらに含むことが、さらに留意されるべきである。「〜を含む」とされる要素は、それ以上の制約なしに、その要素を含むプロセス、方法、物品、またはデバイスにおける追加的な同一要素の存在を排除するものではない。

【0076】

当業者は、本出願の実施態様は、方法、システム、またはコンピュータプログラム製品として提供され得ることを理解するべきである。したがって、本出願は、ハードウェアのみの実施態様、ソフトウェアのみの実施態様、または、ソフトウェアとハードウェアとの組合せによる実施態様の形態を使用し得る。加えて、本出願は、コンピュータで使用可能なプログラムコードを含むコンピュータで使用可能な1つまたは複数の記憶媒体(磁気ディスクメモリ、CD-ROM、光学的メモリが挙げられるが、これらに限定されない)上で実現されるコンピュータプログラム製品の形態を使用し得る。

【0077】

本出願は、プログラムモジュールなどのコンピュータによって実行されるコンピュータ実行可能命令の一般的な文脈で説明され得る。概して、プログラムモジュールは、特定のタスクを実行するかまたは特定の抽象データタイプを実現するルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含む。本出願は、分散コンピューティング環境においても実践され得る。これらの分散コンピューティング環境においては、タスクは、通信ネットワークを使用して接続された遠隔処理デバイスによって実行される。分散コンピューティング環境においては、プログラムモジュールは、記憶デバイスを含むローカルのおよび遠隔のコンピュータ記憶媒体に位置し得る。

【0078】

本出願における実施態様は、漸進的な方法で説明される。実施態様における同一のまたは類似の部分については、実施態様への参照がなされ得る。各実施態様は、他の実施態様との差異に焦点を当てている。特に、システムの実施態様は方法の実施態様と類似しており、したがって、簡潔に説明されている。関連する部分については、方法の実施態様における関連する説明への参照がなされ得る。

【0079】

前述の説明は、本出願の単なる実施態様であり、本出願を限定するものと意図されるものではない。当業者は、本出願に対して様々な修正および変更を行い得る。本出願の精神および原理の範囲内においてなされる任意の修正、均等な置換、改良などは、本出願の特許請求の範囲の保護範囲内にある。

【0080】

図7は、本開示の実施態様による、ブロックチェーンネットワークの安全性を向上させるための、コンピュータによって実現される方法700の例を示すフローチャートである。表現を明白にするために、以下の説明は、概して、本説明の他の図面の文脈において方法700を説明する。しかしながら、方法700は、必要に応じて、例えば、任意のシステム、環境、ソフトウェア、およびハードウェア、またはシステム、環境、ソフトウェア、およびハードウェアの組合せによって実施され得ることは理解されよう。いくつかの実施態様において、方法700の様々なステップは、並行的に、組み合わされて、ループ状に、または任意の順序で実行され得る。

【0081】

概して、分散レッジャーは、中央管理者または中央データ記憶装置なしに複数のノードにわたって広がった、複製、共有、同期されたデジタルデータのコンセンサスである。分散レッジャーのコピーは、分散レッジャーネットワークのノードの間で複製され、共有される。複製および共有は、分散レッジャーの特性に弾力性を与え、権限のない改変からの保護を提供する。ブロックチェーンネットワークは、分散レッジャーの一例である。

【0082】

概して、ブロックチェーンネットワークは、「許可不要制(permission-less)」または「許可制(permissioned)」であり得る。許可不要制のブロックチェーンネットワークにおいては、ブロックチェーンへのアクセスは制限されない。しかしながら、制限されないアクセスのせいで、許可不要制ブロックチェーンは、財務データ、オンライン取引データ、個人識別情報または占有データ(proprietary data)などの機密データまたはプライベートデータを含むブロックチェーン取引においては限定的な適用となり得る。その一方で、「許可制」のブロックチェーンは、中央の信頼済みパーティまたはコンソーシアムの形態の参加者のグループによって、所有、制御および管理され得る。「許可制」のブロックチェーンの例としては、コンソーシアムブロックチェーンネットワークおよびプライベートブロックチェーンネットワークが挙げられる。

【0083】

コンソーシアムブロックチェーンネットワークにおいて、コンソーシアムの一部である信頼された、または厳しく検査された参加者またはノードだけが、ブロックチェーンの制御および維持への参加を許可される。ブロックチェーンのコピーは、コンソーシアムブロックチェーンネットワークの各ノードによって保持され得、ブロックチェーンへのアクセスは、コンソーシアムノードだけに限定される。コンソーシアムノードの間でのブロックチェーンのこのような制御された共有は、機密データまたはプライベートデータを含む分散レッジャー取引を記録するために使用され得る。

【0084】

コンソーシアムブロックチェーンネットワークによって記憶され得る機密データまたはプライベートデータのせいで、このようなブロックチェーンネットワークのノードはハッキングの企ての対象となり得る。特定のハッキング方法は、プライベートデータまたは機密データを含むブロックチェーンに進入して潜在的にアクセスを獲得するハッキングの企てのために、例えば、悪意あるノードとコンソーシアムノードとの間で通信セッションが確立されることを必要とするだけである。コンソーシアムブロックチェーンネットワークの各ノードは、機密データまたはプライベートデータを含むブロックチェーンのコピーを含むため、およびハッキング方法は絶えることなく進化し、ゼロデイ脆弱性が晒され続けているため、コンソーシアムブロックチェーンネットワークなどのブロックチェーンネットワークのノードへの通信セッションの確立を制御することが必要とされる。公開キー証明書および信頼リストを使用して通信セッションの確立へのこのような制御を達成することが可能であり得る。

【0085】

702において、複数のCA識別子を含む第1の認証局(CA)信頼リストが、ブロックチェーンネットワークの第1のノードによって取得される。CAは、公開キー証明書を発行する実体である。公開キー証明書は、時にはデジタル証明書または同一性証明書としても知られ、典型的には、オンライン取引のパーティによって、その同一性を認証するときに使用され、概して、公開キー基盤(PKI：public key infrastructure)暗号技術に基づく。ブロックチェーンの各ノードは、概して、その同一性を認証するため、およびブロックチェーンに追加されるべきブロックに暗号化された署名を付与するために使用される関連公開キー証明書を有する。公開キー証明書は、証明書を発行したCAによってデジタル署名され、それによって、公開キー証明書の名前付き実体の真実性を証明する。このように、公開キー証明書を提示するパーティの同一性を認証するタスクは、公開キー証明書を発行するCAが担う。故に、発行CAの保全性または信頼性は、証明書をベースとしたデジタル同一性確認スキームの保全性を維持するために重要である。

【0086】

概して、悪意あるパーティは、自身がCAであるかのようにふるまい、悪意あるパーティが成りすまそうとする任意の実体であると主張する公開キー証明書に自分で署名する。このように、公開キー証明書の信頼性を確認するやり方の1つは、信頼されたルート認証局から問題の公開キー証明書を発行したCAまでの信頼のチェーンが正当であると検証することである。例えばブロックチェーンノード証明書1から第1のCA、コンソーシアムブロックチェーンCA、ルートCAまで確立された信頼のチェーンなどの、信頼のチェーンの例が図4において示される。いくつかの場合において、信頼のチェーンは比較的長くなり得、結果的に信頼のチェーンの正当性の検証に伴う特定の処理時間が発生する。信頼のチェーンが比較的短い場合であっても、正当性の検証の各試みは有限量の処理時間を要する。大きなボリューム、短い待ち時間、高スループットまたはそれらの組合せを必要とするブロックチェーン適用例においては、信頼のチェーンの正当性の検証に伴うこのような処理時間は、結果的にシステムのパフォーマンスを低下させることがある。

【0087】

信頼のチェーンの正当性の検証に伴う処理時間を減少させる1つのやり方は、信頼され得るCA識別子のリストを含むCA信頼リストを取得することである。CA信頼リストに含まれるCAを信頼することによって、全体的な信頼のチェーンの正当性の検証が回避され得、それに伴う処理時間を減少または除去し得る。CA信頼リストは、様々なやり方によって取得され得る。例えば、ブロックチェーンノードには、CA信頼リストが事前設定され得る。事前設定の例としては、ブロックチェーンノード上で記憶および運用されるブロックチェーンソフトウェアにCA信頼リストのコピーを含むこと、およびCA信頼リストのコピーを、ブロックチェーンノードに物理的にインストールされた安全なハードウェアモジュールに記憶することが挙げられる。安全なハードウェアモジュールは、読み取り専用記憶装置であってよく、これは、悪意ある手段によってCAリストを遠隔から編集しようとする企てを低減するために有益であり得る。別の例としては、CA信頼リストは、特定のブロックチェーンノードの公開キー証明書を発行し、したがって特定のブロックチェーンノードによって信頼されたCAから受信され得る。CAが証明書を発行したノードへのCAによるCA信頼リストの配布は、CA信頼リストの管理および更新を円滑化するために有利であり得る。故に、いくつかの実施態様において、複数のCA識別子を含む第1のCA信頼リストの取得は、第1のノードに第1のCA信頼リストを事前設定すること、または、第1のノードに関連するCAから第1のCA信頼リストを受信することのうちの一方によって実施され得る。方法700は、702から704へと進む。

【0088】

704において、ブロックチェーンネットワークの第2のノードの公開キー証明書を備える通信リクエストは、ブロックチェーンネットワークの第1のノードによって第2のノードから受信される。このステップは、図2のS202に類似し得る。通信リクエストとは、一般に、第2のネットワークノードと通信しようとする第1のネットワークノードの意図を中継するネットワーク上で交換されるリクエストまたはメッセージを指す。ブロックチェーンネットワークの安全対策の一部として、ブロックチェーンネットワークのノード間の通信は、典型的には、暗号化を使用して安全化される。暗号化プロセスを容易化し、通信のリクエストを行うノードの同一性を確証するために、通信リクエストは、リクエストを行うノードの公開キー証明書を含む。通信リクエストのフォーマットおよび内容は、標準されてよく、または、実施態様に固有のものであってよい。

【0089】

トランスポートレイヤセキュリティ(TLS)プロトコルおよびその前任のセキュアソケットレイヤ(SSL：secure socket layer)プロトコルは、ネットワークの2つのノードの間でのネットワーク上での安全な通信を実施する際に広く使用されるプロトコルである。TLSおよびSSLプロトコルは、安全な通信セッションを開始するために使用されるハンドシェイク手順を有する。ハンドシェイク手順の一部として、2つのネットワークノードの間で、標準化された手順を通じて公開キー証明書が交換される。このように、いくつかの実施態様において、第2のノードの公開キー証明書を備える通信リクエストを、ブロックチェーンネットワークの第1のノードによって第2のノードから受信するステップは、第1のノードによって第2のノードから、トランスポートレイヤセキュリティ(TLS)ハンドシェイクプロトコルに従って通信リクエストを受信するステップを含む。方法700は、704から706へと進む。

【0090】

706において、受信された公開キー証明書からの第1のCA識別子が判定される。このステップは、図2のS204に類似し得る。公開キー証明書は、概して、X.509規格などの適切な規格によって規定された標準化されたフォーマットの様々な情報を含む。発行者名、すなわち証明書を発行したCAの名前は、公開キー証明書の標準的なフィールドの1つである。このように、公開キー証明書内に含まれる発行者名は、例えば、CA識別子として使用され得る。別の例としては、認証局キー識別子(AKI：authority key identifier)または発行CAのデジタル署名などの、発行CAに関連するアルファベットでない識別情報が、CA識別子として使用され得る。概して、特定の公開キー証明書を発行したCAを識別するために使用可能な公開キー証明書内に含まれる任意の情報が、CA識別子として使用され得る。加えて、証明書は、主体名フィールドも含み、これは、公開キー証明書の所有者の名前または識別情報である。方法700は、706から708へと進む。

【0091】

708において、第1のCA識別子が第1のCA信頼リストの複数のCA識別子のうちの1つと一致するかが判定される。このステップは、図2のS206に類似し得る。一致の判定は、例えば、受信された公開キー証明書から判定された第1のCA識別子と第1のCA信頼リストのエントリとの正確な一致(例えば、ビットごとの比較を通じて)を検索することによって実施され得る。第1のCA識別子が第1のCA信頼リストの複数のCA識別子のうちの1つと一致すると判定された場合は、方法700は710に進む。そうではなく、第1のCA識別子が第1のCA信頼リストの複数のCA識別子のうちの1つと一致しないと判定された場合は、方法700は712に進む。

【0092】

710において、通信リクエストは第1のノードによって承認される。このステップは、図2のS208に類似し得る。通信リクエストが第1のノードによって承認されると、第1のノードは、第1のノードと第2のノードとの間に通信セッションを確立し得る。確立された通信セッションは、TLSによって安全化された通信セッションなどの暗号化された通信セッションであり得る。通信セッションが確立されると、第1および第2のノードの間でデータが流れ得、確立された通信セッション上でブロックチェーン取引が実施され得る。

【0093】

いくつかの実施態様において、第1のノードによる承認の後、通信セッションの確立の前に、追加的なステップが実施され得る。例えば、通信リクエストを開始した第2のノードもまた、2つのノードの間で通信セッションを確立する前に、第1のノードの相互的同一性確認を実施することを望むかもしれない。同一性のこのような相互の確認は、ブロックチェーンネットワークの全体的安全性を向上させ得る。このように、いくつかの実施態様において、第2のノードは、複数のCA識別子を含む第2のCA信頼リストを備え、第1のノードによって通信リクエストを承認するステップは、第1のノードによって第2のノードへと、第1のノードの公開キー証明書を備える確認リクエストを送るステップを含む。確認リクエストは、例えば、TLSまたはSSLプロトコルなどの通信プロトコルに従って送られ得る。このような実施態様において、方法700は、第2のノードによって、受信された第1のノードの公開キー証明書から第2のCA識別子を判定するステップと、第2のCA識別子が第2のノードの第2のCA信頼リストの複数のCA識別子のうちの1つと一致するか否かを判定するステップと、第2のCA識別子が第2のCA信頼リストの複数のCA識別子のうちの1つと一致するとの判定に応じて、第1のノードとの通信セッションを確立するステップと、第2のCA識別子が第2のCA信頼リストの複数のCA識別子のうちの1つと一致しないとの判定に応じて、第2のノードによって、第1のノードとの通信セッションの確立を拒否するステップとをさらに備える。第2のノードによる確認プロセスの詳細は、ステップ706およびステップ708に類似し得る。

【0094】

712において、通信リクエストは第1のノードによって拒否される。このステップは、図2のS210に類似し得る。第1のCA識別子が第1のCA信頼リストの複数のCA識別子のうちの1つと一致しないとき、通信リクエストは悪意あるノードからのもの、またはブロックチェーンネットワークによって基準セットに従ってその同一性が確認され得ないノードからのものであるかもしれないので、第1のノードは通信リクエストを拒否する。通信リクエストを拒否する際に、第1のノードは様々なアクションを実施し得、または、様々なアクションの実施を保留し得る。例えば、第1のノードは、単に、この通信リクエストに関してさらなるアクションを行わない。別の例としては、第1のノードは、「通信リクエスト拒否」メッセージを第2のノードに送信し得る。なおも別の例としては、第1のノードは、第2のノードのネットワーク識別子(例えば、MACアドレスまたはIPアドレス)を、疑わしい活動を監視するためのウォッチリスト、またはその通信リクエストが拒否された第2のノードからの任意のさらなる通信リクエストをブロックするブラックリストへと追加し得る。

【0095】

概して、ブロックチェーンネットワークの異なるノードは、異なるCAによって発行された公開キー証明書を有し得る。例えば、CAはコンソーシアムブロックチェーンネットワークの一部であり得、あるタイプのブロックチェーン取引を実施するノードのための公開キー証明書は、第1のCAによって発行され得、異なるタイプのブロックチェーン取引を実施するノードのための公開キー証明書は、第1のCAとは異なる第2のCAによって発行され得る。このように、いくつかの実施態様において、第2のノードの公開キー証明書の第1のCA識別子は、第1のノードの公開キー証明書の第2のCA識別子とは異なる。異なる取引タイプについて別個のCAを実現することは、ブロックチェーンネットワークの1つの特定の動作に任意のあり得る安全性違反が含まれているときに、違反がブロックチェーンネットワークの他の動作に広がることを防止するために有利であり得る。

【0096】

いくつかの実施態様において、方法700のブロックチェーンネットワークは、コンソーシアムブロックチェーンネットワークである。

【0097】

概して、ブロックチェーンネットワークは、ブロックチェーンネットワークの様々なノードにわたって分散されたブロックチェーンのコピーにわたってコンセンサス確認を実施するように構成された1つまたは複数のコンセンサスノードを含む。このように、いくつかの実施態様において、通信リクエストを受信するブロックチェーンネットワークの第1のノード、または通信リクエストを送る第2のノードは、コンセンサスノードである。

【0098】

710または712の後、方法700は停止する。

【0099】

本明細書において開示される方法および装置は、不審なまたは悪意あるCAによって与えられる安全性への脅威を緩和することによって、ブロックチェーンネットワークの安全性を向上させ得る。その同一性が信頼されるCAによって証明されることのないノードとの通信セッションの確立を拒否することによって、コンソーシアムブロックチェーンのノードの安全性が、CA信頼リストを利用しないノードにわたって向上され得る。さらに、公開キー証明書の信頼のチェーンの確認に伴う処理時間が減少されるので、開示される方法および装置を実現するブロックチェーンネットワークのパフォーマンスは、従来のブロックチェーンのパフォーマンスよりも優秀であり得る。

【0100】

本明細書において説明される実施形態および動作は、デジタル電子回路において、または、本明細書において開示される構造を含むコンピュータソフトウェア、ファームウェア、ハードウェアにおいて、またはそれらのうちの1つまたは複数の組合せにおいて実現され得る。動作は、1つまたは複数のコンピュータ可読記憶デバイスに記憶されたデータまたは他のソースから受信されたデータに対してデータ処理装置によって実施される動作として実現され得る。データ処理装置、コンピュータ、またはコンピューティングデバイスは、データを処理するための装置、デバイス、およびマシンを包含し得、例としては、プログラマブルプロセッサ、コンピュータ、チップ上のシステム、または前述のもののうちの複数のもの、もしくはその組合せが挙げられる。装置は、特殊用途論理回路、例えば、中央処理ユニット(CPU)、フィールドプログラマブルゲートアレイ(FPGA)、または特定用途向け集積回路(ASIC)を含み得る。装置は、問題のコンピュータプログラムのための実行環境を作り出すコード、例えば、プロセッサファームウェア、プロトコルスタック、データベース管理システム、オペレーティングシステム(例えば、1つのオペレーティングシステムまたはオペレーティングシステムの組合せ)、クロスプラットフォームランタイム環境、仮想マシン、またはそれらのうちの1つまたは複数の組合せを構築するコードも含み得る。装置および実行環境は、ウェブサービス、分散コンピューティングおよびグリッドコンピューティング基盤などの様々な異なるコンピューティングモデル基盤を実現し得る。

【0101】

コンピュータプログラム(例えば、プログラム、ソフトウェア、ソフトウェアアプリケーション、ソフトウェアモジュール、ソフトウェアユニット、スクリプト、またはコードとしても知られる)は、コンパイラ型またはインタープリタ型言語、宣言型または手続き型言語などのプログラム言語の任意の形態によって記述され得、スタンドアロンプログラムとして、またはモジュール、コンポーネント、サブルーチン、オブジェクト、もしくはコンピューティング環境における使用に適した他のユニットとしてなどの任意の形態に展開され得る。プログラムは、他のプログラムまたはデータ(例えば、マークアップ言語文書に記憶された1つまたは複数のスクリプト)を保持するファイルの一部分に、または問題のプログラム専用の単一のファイルに、または複数の協調的なファイル(例えば、1つまたは複数のモジュール、サブプログラム、またはコードの一部を記憶するファイル)に記憶され得る。コンピュータプログラムは、1つのコンピュータ上で、または1つの場所に位置する複数のコンピュータもしくは複数の場所にわたって分散されて通信ネットワークによって相互接続された複数のコンピュータ上で実行され得る。

【0102】

コンピュータプログラムの実行のためのプロセッサとしては、例えば、汎用および特殊用途向けマイクロプロセッサの両方、および任意の種類のデジタルコンピュータの任意の1つまたは複数のプロセッサが挙げられる。概して、プロセッサは、読み取り専用メモリ、またはランダムアクセスメモリ、またはその両者から命令およびデータを受信する。コンピュータの本質的な要素は、命令に従ってアクションを実施するためのプロセッサ、ならびに命令およびデータを記憶するための1つまたは複数のメモリデバイスである。概して、コンピュータは、データを記憶するための1つまたは複数の大容量記憶デバイスも含むか、またはデータをこれから受信するためまたはこれに送信するためまたはその両方のために、これに動作可能に結合される。コンピュータは、別のデバイス、例えば、モバイルデバイス、パーソナルデジタルアシスタント(PDA：Personal Digital Assistant)、ゲームコンソール、グローバルポジショニングシステム(GPS：Global Positioning System)受信機、または可搬型記憶デバイスに埋め込まれ得る。コンピュータプログラム命令およびデータを記憶するために適したデバイスとしては、不揮発性メモリ、媒体およびメモリデバイスがあり、例として、例えば、半導体メモリデバイス、磁気ディスクおよび光磁気ディスクが挙げられる。プロセッサおよびメモリは、特殊用途論理回路によって補完され得、またはこれに組み込まれ得る。

【0103】

モバイルデバイスとしては、ハンドセット、ユーザ機器(UE：User Equipment)、モバイル電話(例えば、スマートフォン)、タブレット、ウェアラブルデバイス(例えば、スマートウォッチ、およびスマート眼鏡)、人間の体内のインプラントデバイス(例えば、バイオセンサ、人工内耳)、または他のタイプのモバイルデバイスが挙げられる。モバイルデバイスは、様々な(以下において説明される)通信ネットワークと無線で(例えば、高周波(RF：Radio Frequency)信号を使用して)通信し得る。モバイルデバイスは、モバイルデバイスの現在の環境の特性を判定するためのセンサを含み得る。センサとしては、カメラ、マイクロホン、近接センサ、GPSセンサ、モーションセンサ、加速度計、環境光センサ、湿度センサ、ジャイロスコープ、コンパス、気圧計、指紋センサ、顔認識システム、RFセンサ(例えば、Wi-Fiおよびセル無線)、熱センサ、または他のタイプのセンサが挙げられる。例えば、カメラとしては、可動式または固定式のレンズ、フラッシュ、画像センサ、および画像プロセッサを有した前面または背面カメラが挙げられる。カメラは、顔および/または虹彩認識のための詳細を撮影可能なメガピクセルカメラであってよい。カメラは、データプロセッサおよびメモリに記憶されたもしくは遠隔からアクセスされる認証情報とともに、顔認識システムを形成し得る。顔認識システムまたは1つまたは複数のセンサ、例えば、マイクロホン、モーションセンサ、加速度計、GPSセンサまたはRFセンサは、ユーザ認証に使用され得る。

【0104】

ユーザとの相互作用を提供するために、実施形態は、ディスプレイデバイスおよび入力デバイス、例えば、ユーザに対して情報を表示するための液晶ディスプレイ(LCD：Liquid Crystal Display)または有機発光ダイオード(OLED：Organic Light-Emitting Diode)/仮想現実(VR：Virtual-Reality)/拡張現実(AR：Augmented-Reality)ディスプレイ、およびユーザがコンピュータに対して入力を提供し得るようにするためのタッチスクリーン、キーボードおよびポインティングデバイスを有するコンピュータ上に実現され得る。他の種類のデバイスが同じようにユーザとの相互作用を提供するために使用され得、例えば、ユーザに提供されるフィードバックは、任意の形態の感覚的フィードバック、例えば、視覚的フィードバック、音響的フィードバック、触覚的フィードであってよく、ユーザからの入力は、音響、発話または触覚的入力などの任意の形態で受信されてよい。加えて、コンピュータは、例えば、ユーザのクライアントデバイス上のウェブブラウザに対して、ウェブブラウザから受信したリクエストに応答して、ウェブページを送信することによってなど、ユーザによって使用されるデバイスに対して文書を送信することによって、またはそのようなデバイスから文書を受信することによってユーザと相互作用してよい。

【0105】

実施形態は、有線または無線のデジタルデータ通信(またはその組合せ)の任意の形態または媒体、例えば通信ネットワークによって相互接続されたコンピューティングデバイスを使用して実現され得る。相互接続されたデバイスの例としては、典型的には通信ネットワークを通じて相互作用する、概して相互に離間されたクライアントおよびサーバが挙げられる。クライアント、例えば、モバイルデバイスは、それ自体が、サーバとともに、またはサーバを通じて取引を行い得、例えば、購入、売却、支払い、贈与、送信、または貸付取引を実施し、またはこれらを認可する。このような取引は、アクションおよびレスポンスが時間的に近接するようにリアルタイムで行われ得る。例えば、個人は、アクションとレスポンスとが実質的に同時的に発生していると知覚し、個人のアクションに続くレスポンスの時間差は1ミリ秒(ms)未満もしくは1秒(s)未満であるか、またはレスポンスは、システムの処理限界を考慮にいれて、意図的な遅延なしに行われる。

【0106】

通信ネットワークの例としては、ローカルエリアネットワーク(LAN：Local Area Network)、無線アクセスネットワーク(RAN：Radio Access Network)、メトロポリタンエリアネットワーク(MAN：Metropolitan Area Network)、およびワイドエリアネットワーク(WAN：Wide Area Network)が挙げられる。通信ネットワークは、インターネットのすべてまたは一部、別の通信ネットワーク、または通信ネットワークの組合せを含み得る。情報は、Long Term Evolution(LTE)、5G、IEEE802、Internet Protocol(IP)もしくは他のプロトコルまたはプロトコルの組合せなどの様々なプロトコルおよび基準に従って通信ネットワーク上で送られ得る。通信ネットワークは、接続されたコンピューティングデバイスの間で、音声、ビデオ、生体データもしくは認証データ、または他の情報を、送り得る。

【0107】

別個の実施態様として説明される特徴は、単一の実施態様において組み合わされて実現され得、単一の実施態様として説明される特徴は、複数の実施態様において、別個に、または任意の適切な副次的組合せとして実現され得る。特定の順序において説明および特許請求される動作は、そのような特定の順序を必要とするものと理解されるべきではなく、すべての示された動作が必ず実施されなければならないと理解されるべきでもない(いくつかの動作は任意選択的であり得る)。必要に応じて、マルチタスクまたは並行処理(またはマルチタスクと並行処理の組合せ)が実施され得る。

【符号の説明】

【0108】

302 受信モジュール
304 判定モジュール
306 判定および実行モジュール

【要約】

ブロックチェーンネットワークの第2のブロックチェーンノードによって送信された通信リクエストは、第1のブロックチェーンノードによって受信され、通信リクエストは第2のブロックチェーンノードの第2の証明書を含み、ブロックチェーンネットワークは、認証局(CA)によって送信された証明書を記憶するとともにCA信頼リストが事前設定されたサービスノードを含む。第2の証明書に対応するCA識別子が判定される。第2の証明書に対応する判定されたCA識別子がCA信頼リストに含まれるか否かが判定される。イエスである場合は、第2のブロックチェーンノードへの通信接続が確立される。ノーである場合は、第2のブロックチェーンノードへの通信接続の確立はスキップされる。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】