(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2022-12-22
(45)【発行日】2023-01-05
(54)【発明の名称】クロスブロックチェーン認証方法および装置
(51)【国際特許分類】
G06F 21/64 20130101AFI20221223BHJP
【FI】
G06F21/64
【外国語出願】
(21)【出願番号】P 2021071906
(22)【出願日】2021-04-21
(62)【分割の表示】P 2020529630の分割
【原出願日】2019-03-29
【審査請求日】2021-05-21
(31)【優先権主張番号】201810291256.0
(32)【優先日】2018-04-03
(33)【優先権主張国・地域又は機関】CN
(73)【特許権者】
【識別番号】520015461
【氏名又は名称】アドバンスド ニュー テクノロジーズ カンパニー リミテッド
(74)【代理人】
【識別番号】100188558
【氏名又は名称】飯田 雅人
(74)【代理人】
【識別番号】100205785
【氏名又は名称】▲高▼橋 史生
(72)【発明者】
【氏名】ホンリン・チウ
【審査官】小林 秀和
(56)【参考文献】
【文献】中国特許出願公開第107742210(CN,A)
【文献】米国特許出願公開第2016/0330034(US,A1)
【文献】中国特許出願公開第107231299(CN,A)
【文献】特開2017-204070(JP,A)
(58)【調査した分野】(Int.Cl.,DB名)
G06F 21/64
(57)【特許請求の範囲】
【請求項1】
クロスブロックチェーン認証のためのコンピュータ実装方法であって、
引受クライアントによって、クロスチェーン
クライアントから第1のデータを取り出すステップであって、前記引受クライアントが第1のブロックチェーンに対応し、前記引受クライアントが発行クライアントとは異なり、前記クロスチェーンクライアントが前記引受クライアントと独立して相互接続され、前記第1のブロックチェーンが、メインチェーンとして使用される第2のブロックチェーンにアンカーされるサイドチェーンとして使用される、ステップと、
前記引受クライアントによって前記第2のブロックチェーンから、認証されるべき第2のデータを受信するステップであって、前記第2のデータが前記第1のデータとは異なる、ステップと、
前記引受クライアントによって、前記第1のデータと前記第1のブロックチェーンに対して設定されたデータ認証ルールとに基づいて前記第2のデータを認証するステップと
を備える、コンピュータ実装方法。
【請求項2】
前記第1のデータを取り出すステップが、
前記引受クライアントによって引受として、クロスチェーンインタラクションエンドに対して引受要求を開始するステップであって、前記引受要求が、引受条件を前記クロスチェーンインタラクションエンドに通知するために使用される、ステップと、
前記クロスチェーンインタラクションエンドを使用して前記引受条件に基づいて、前記発行クライアントから前記引受条件を満足する前記第2のブロックチェーン上の前記第1のデータを要求するステップと、
前記引受を使用して、前記発行クライアントによって発行され、かつ前記引受条件を満足する前記第2のブロックチェーン上の前記第1のデータを取り出すステップと
を備える、請求項1に記載のコンピュータ実装方法。
【請求項3】
前記第1のデータが、前記第2のブロックチェーン上の各ブロックのブロックヘッダデータを含む、請求項2に記載のコンピュータ実装方法。
【請求項4】
前記第2のデータを認証するステップが、
前記第2のデータが前記第2のブロックチェーン上の前記ブロックに含まれているかどうかを決定するために、認証データソースとして使用する前記第1のデータと、前記第1のブロックチェーンに対して設定された前記データ認証ルールとに基づいて前記第2のデータに対して簡易支払検証(SPV)データ認証を行うステップ
を備える、請求項3に記載のコンピュータ実装方法。
【請求項5】
前記第2のデータに対してSPVデータ認証を行うステップが、
前記第2のデータのハッシュ値を計算するステップと、
前記第2のデータを含む前記第2のブロックチェーン上のターゲットブロックのMerkleツリー上の前記第2のデータのMerkle認証経路を取り出すステップと、
計算されたハッシュ値として、前記第2のデータの前記ハッシュ値と前記Merkle認証経路上の各ノードのハッシュ値とに基づいて前記ターゲットブロックのブロックヘッダのハッシュ値を計算するステップと、
前記計算されたハッシュ値が、前記認証データソースとして使用される前記第1のデータに記憶された前記ターゲットブロックの前記ブロックヘッダのハッシュ値と一致しているかどうかを判定するステップと、
前記ターゲットブロックの前記ブロックヘッダの前記計算されたハッシュ値が、前記認証データソースとして使用される前記第1のデータに記憶された前記ターゲットブロックの前記ブロックヘッダの前記ハッシュ値と一致していると判定したことに応答して、前記第2のデータが前記第2のブロックチェーン上の前記ブロックに含まれていると判定するステップと
を備える、請求項4に記載のコンピュータ実装方法。
【請求項6】
前記引受クライアントが前記第1のブロックチェーン上のノードデバイスに対応し、前記発行クライアントが前記第2のブロックチェーン上のノードデバイスに対応する、請求項1に記載のコンピュータ実装方法。
【請求項7】
前記第2のデータが、トランザクション、状態、およびイベントのうちの1つを含み、
認証データソースとして使用する前記第1のデータが、前記第1のブロックチェーンおよび前記第2のブロックチェーンによってサポートされるデータ認証プロトコルに依存し、
前記
データ認証ルールが、前記第2のブロックチェーン上に記録されている特定のタイプのデータに依存する認証ロジックを含む、
請求項1に記載のコンピュータ実装方法。
【請求項8】
非一時的コンピュータ可読記憶媒体であって、
引受クライアントによって、クロスチェーン
クライアントから第1のデータを取り出すことであって、前記引受クライアントが第1のブロックチェーンに対応し、前記引受クライアントが発行クライアントとは異なり、前記クロスチェーンクライアントが前記引受クライアントと独立して相互接続され、前記第1のブロックチェーンが、メインチェーンとして使用される第2のブロックチェーンにアンカーされるサイドチェーンとして使用される、取り出すことと、
前記引受クライアントによって前記第2のブロックチェーンから、認証されるべき第2のデータを受信することであって、前記第2のデータが前記第1のデータとは異なる、受信することと、
前記引受クライアントによって、前記第1のデータと前記第1のブロックチェーンに対して設定されたデータ認証ルールとに基づいて前記第2のデータを認証することと
を備える動作を実行するようにコンピュータシステムによって実行可能な1つまたは複数の命令を記憶する、非一時的コンピュータ可読記憶媒体。
【請求項9】
前記第1のデータを取り出すことが、
前記引受クライアントによって引受として、クロスチェーンインタラクションエンドに対して引受要求を開始することであって、前記引受要求が、引受条件を前記クロスチェーンインタラクションエンドに通知するために使用される、ことと、
前記クロスチェーンインタラクションエンドを使用して前記引受条件に基づいて、前記発行クライアントから前記引受条件を満足する前記第2のブロックチェーン上の前記第1のデータを要求することと、
前記引受を使用して、前記発行クライアントによって発行され、かつ前記引受条件を満足する前記第2のブロックチェーン上の前記第1のデータを取り出すことと
を備える、請求項8に記載の非一時的コンピュータ可読記憶媒体。
【請求項10】
前記第1のデータが、前記第2のブロックチェーン上の各ブロックのブロックヘッダデータを含む、請求項9に記載の非一時的コンピュータ可読記憶媒体。
【請求項11】
前記第2のデータを認証することが、
前記第2のデータが前記第2のブロックチェーン上の前記ブロックに含まれているかどうかを決定するために、認証データソースとして使用する前記第1のデータと、前記第1のブロックチェーンに対して設定された前記データ認証ルールとに基づいて前記第2のデータに対して簡易支払検証(SPV)データ認証を行うこと
を備える、請求項10に記載の非一時的コンピュータ可読記憶媒体。
【請求項12】
前記第2のデータに対してSPVデータ認証を行うことが、
前記第2のデータのハッシュ値を計算することと、
前記第2のデータを含む前記第2のブロックチェーン上のターゲットブロックのMerkleツリー上の前記第2のデータのMerkle認証経路を取り出すことと、
計算されたハッシュ値として、前記第2のデータの前記ハッシュ値と前記Merkle認証経路上の各ノードのハッシュ値とに基づいて前記ターゲットブロックのブロックヘッダのハッシュ値を計算することと、
前記計算されたハッシュ値が、前記認証データソースとして使用される前記第1のデータに記憶された前記ターゲットブロックの前記ブロックヘッダのハッシュ値と一致しているかどうかを判定することと、
前記ターゲットブロックの前記ブロックヘッダの前記計算されたハッシュ値が、前記認証データソースとして使用される前記第1のデータに記憶された前記ターゲットブロックの前記ブロックヘッダの前記ハッシュ値と一致していると判定したことに応答して、前記第2のデータが前記第2のブロックチェーン上の前記ブロックに含まれていると判定することと
を備える、請求項11に記載の非一時的コンピュータ可読記憶媒体。
【請求項13】
前記引受クライアントが前記第1のブロックチェーン上のノードデバイスに対応し、前記発行クライアントが前記第2のブロックチェーン上のノードデバイスに対応する、請求項8に記載の非一時的コンピュータ可読記憶媒体。
【請求項14】
前記第2のデータが、トランザクション、状態、およびイベントのうちの1つを含み、
認証データソースとして使用する前記第1のデータが、前記第1のブロックチェーンおよび前記第2のブロックチェーンによってサポートされるデータ認証プロトコルに依存し、
前記
データ認証ルールが、前記第2のブロックチェーン上に記録されている特定のタイプのデータに依存する認証ロジックを含む、
請求項8に記載の非一時的コンピュータ可読記憶媒体。
【請求項15】
コンピュータ実装システムであって、
1つまたは複数のコンピュータと、
前記1つまたは複数のコンピュータに相互動作可能に接続され、かつ1つまたは複数の命令を記憶する有形の非一時的記憶媒体を有する、1つまたは複数のコンピュータメモリデバイスと
を備え、前記命令が前記1つまたは複数のコンピュータによって実行されたとき、
引受クライアントによって、クロスチェーン
クライアントから第1のデータを取り出すことであって、前記引受クライアントが第1のブロックチェーンに対応し、前記引受クライアントが発行クライアントとは異なり、前記クロスチェーンクライアントが前記引受クライアントと独立して相互接続され、前記第1のブロックチェーンが、メインチェーンとして使用される第2のブロックチェーンにアンカーされるサイドチェーンとして使用される、取り出すことと、
前記引受クライアントによって前記第2のブロックチェーンから、認証されるべき第2のデータを受信することであって、前記第2のデータが前記第1のデータとは異なる、受信することと、
前記引受クライアントによって、前記第1のデータと前記第1のブロックチェーンに対して設定されたデータ認証ルールとに基づいて前記第2のデータを認証することと
を備える動作を実行させる、コンピュータ実装システム。
【請求項16】
前記第1のデータを取り出すことが、
前記引受クライアントによって引受として、クロスチェーンインタラクションエンドに対して引受要求を開始することであって、前記引受要求が、引受条件を前記クロスチェーンインタラクションエンドに通知するために使用される、ことと、
前記クロスチェーンインタラクションエンドを使用して前記引受条件に基づいて、前記発行クライアントから前記引受条件を満足する前記第2のブロックチェーン上の前記第1のデータを要求することと、
前記引受を使用して、前記発行クライアントによって発行され、かつ前記引受条件を満足する前記第2のブロックチェーン上の前記第1のデータを取り出すことと
を備える、請求項15に記載のコンピュータ実装システム。
【請求項17】
前記第1のデータが、前記第2のブロックチェーン上の各ブロックのブロックヘッダデータを含む、請求項16に記載のコンピュータ実装システム。
【請求項18】
前記第2のデータを認証することが、
前記第2のデータが前記第2のブロックチェーン上の前記ブロックに含まれているかどうかを決定するために、認証データソースとして使用する前記第1のデータと、前記第1のブロックチェーンに対して設定された前記データ認証ルールとに基づいて前記第2のデータに対して簡易支払検証(SPV)データ認証を行うこと
を備える、請求項17に記載のコンピュータ実装システム。
【請求項19】
前記第2のデータに対してSPVデータ認証を行うことが、
前記第2のデータのハッシュ値を計算することと、
前記第2のデータを含む前記第2のブロックチェーン上のターゲットブロックのMerkleツリー上の前記第2のデータのMerkle認証経路を取り出すことと、
計算されたハッシュ値として、前記第2のデータの前記ハッシュ値と前記Merkle認証経路上の各ノードのハッシュ値とに基づいて前記ターゲットブロックのブロックヘッダのハッシュ値を計算することと、
前記計算されたハッシュ値が、前記認証データソースとして使用される前記第1のデータに記憶された前記ターゲットブロックの前記ブロックヘッダのハッシュ値と一致しているかどうかを判定することと、
前記ターゲットブロックの前記ブロックヘッダの前記計算されたハッシュ値が、前記認証データソースとして使用される前記第1のデータに記憶された前記ターゲットブロックの前記ブロックヘッダの前記ハッシュ値と一致していると判定したことに応答して、前記第2のデータが前記第2のブロックチェーン上の前記ブロックに含まれていると判定することと
を備える、請求項18に記載のコンピュータ実装システム。
【請求項20】
前記引受クライアントが前記第1のブロックチェーン上のノードデバイスに対応し、前記発行クライアントが前記第2のブロックチェーン上のノードデバイスに対応する、請求項15に記載のコンピュータ実装システム。
【発明の詳細な説明】
【技術分野】
【0001】
関連出願の相互参照
本出願は、その全体が参照により組み込まれている、2018年4月3日に出願した、中国特許出願第201810291256.0号に対する優先権を主張する。
【0002】
本明細書の1つまたは複数の実施形態は、ブロックチェーン技術の分野に関し、詳細には、クロスブロックチェーン認証方法および装置、ならびに電子デバイスに関する。
【背景技術】
【0003】
分散型台帳技術とも称する、ブロックチェーン技術は、いくつかのコンピューティングデバイスが「会計処理」に連携して関与して分散データベース全体を維持管理する、新興技術である。ブロックチェーン技術は、分散化および透明性を特徴としており、各コンピューティングデバイスは、データベース内のデータを記録し得るし、データは、コンピューティングデバイス間で迅速に同期され得る。したがって、ブロックチェーン技術を使用して、分散システムを確立し、自動実行のためにブロックチェーンの分散データベースに様々な実行プログラムを記録することは、多くの分野に広く適用されている。
【発明の概要】
【課題を解決するための手段】
【0004】
本明細書は、クロスブロックチェーン認証方法を提供しており、方法は、引受クライアント、発行クライアント、およびクロスチェーンクライアントを含む、クロスブロックチェーンインタラクションシステムに適用され、引受クライアントは、第1のブロックチェーンに対応し、発行クライアントは、第2のブロックチェーンに対応し、クロスチェーンクライアントは、引受クライアントと独立して相互接続され、発行クライアントおよび方法は、引受クライアントによって、クロスチェーンクライアントを使用して、認証データソースとしてデータを使用するために、発行クライアントによって発行された第2のブロックチェーン上のデータを取得するステップと、第2のブロックチェーンから未認証のデータを受信するステップと、認証データソースと第1のブロックチェーンに対して設定されたデータ認証ルールとに基づいて未認証のデータに対してデータ認証を行うステップとを含む。
【0005】
必要に応じて、引受クライアントによって、クロスチェーンクライアントを使用して、認証データソースとしてデータを使用するために、発行クライアントによって発行された第2のブロックチェーン上のデータを取得するステップは、引受クライアントによって、クロスチェーンインタラクションエンドに対して引受要求を開始するステップであって、引受要求は、クロスチェーンインタラクションエンドが、引受条件に基づいて、発行クライアントからの引受条件を満足する第2のブロックチェーン上のデータを要求するように、引受条件をクロスチェーンインタラクションエンドに通知するために使用される、ステップと、引受クライアントによって、認証データソースとしてデータを使用するために、発行クライアントによって発行されるとともに引受条件を満足する第2のブロックチェーン上のデータを取得するステップとを含む。
【0006】
必要に応じて、認証データソースは、第2のブロックチェーン上の各ブロックのブロックヘッダデータを含む。
【0007】
必要に応じて、認証データソースと第1のブロックチェーンに対して設定されたデータ認証ルールとに基づいて未認証のデータに対してデータ認証を行うステップは、未認証のデータが第2のブロックチェーン上のブロックに含まれているかどうかを決定するために、認証データソースと第1のブロックチェーンに対して設定されたデータ認証ルールとに基づいて未認証のデータに対してSPVデータ認証を行うステップを含む。
【0008】
必要に応じて、認証データソースと第1のブロックチェーンに対して設定されたデータ認証ルールとに基づいて未認証のデータに対してSPVデータ認証を行うステップは、未認証のデータのハッシュ値を計算するステップと、未認証のデータを含む第2のブロックチェーン上のターゲットブロックのMerkleツリー上の未認証のデータのMerkle認証経路を取得するステップと、未認証のデータのハッシュ値とMerkle認証経路上の各ノードのハッシュ値とに基づいてターゲットブロックのブロックヘッダのハッシュ値を計算するステップと、ターゲットブロックのブロックヘッダのものであるとともに認証データソースに記憶されているハッシュ値とターゲットブロックのブロックヘッダの計算されたハッシュ値が一致しているかどうかを決定するステップと、一致している場合には、未認証のデータが第2のブロックチェーン上のブロックに含まれていると決定するステップとを含む。
【0009】
必要に応じて、引受クライアントは、第1のブロックチェーン上のノードデバイスに対応し、発行クライアントは、第2のブロックチェーン上のノードデバイスに対応する。
【0010】
本明細書は、クロスブロックチェーン認証装置をさらに提供しており、装置は、引受クライアント、発行クライアント、およびクロスチェーンクライアントを含む、クロスブロックチェーンインタラクションシステムに適用され、引受クライアントは、第1のブロックチェーンに対応し、発行クライアントは、第2のブロックチェーンに対応し、クロスチェーンクライアントは、引受クライアントと独立して相互接続され、発行クライアントおよび装置は、クロスチェーンクライアントを使用して、認証データソースとしてデータを使用するために、発行クライアントによって発行された第2のブロックチェーン上のデータを取得するように構成される、獲得モジュールと、第2のブロックチェーンから未認証のデータを受信するように構成される、受信モジュールと、認証データソースと第1のブロックチェーンに対して設定されたデータ認証ルールとに基づいて未認証のデータに対してデータ認証を行うように構成される、認証モジュールとを含む。
【0011】
必要に応じて、獲得モジュールは、クロスチェーンインタラクションエンドに対して引受要求を開始することであって、引受要求は、クロスチェーンインタラクションエンドが、引受条件に基づいて、発行クライアントからの引受条件を満足する第2のブロックチェーン上のデータを要求するように、引受条件をクロスチェーンインタラクションエンドに通知するために使用される、ことと、認証データソースとしてデータを使用するために、発行クライアントによって発行されるとともに引受条件を満足する第2のブロックチェーン上のデータを取得することとをするように構成される。
【0012】
必要に応じて、認証データソースは、第2のブロックチェーン上の各ブロックのブロックヘッダデータを含む。
【0013】
必要に応じて、認証モジュールは、未認証のデータが第2のブロックチェーン上のブロックに含まれているかどうかを決定するために、認証データソースと第1のブロックチェーンに対して設定されたデータ認証ルールとに基づいて未認証のデータに対してSPVデータ認証を行うように構成される。
【0014】
必要に応じて、認証モジュールは、未認証のデータのハッシュ値を計算することと、未認証のデータを含む第2のブロックチェーン上のターゲットブロックのMerkleツリー上の未認証のデータのMerkle認証経路を取得することと、未認証のデータのハッシュ値とMerkle認証経路上の各ノードのハッシュ値とに基づいてターゲットブロックのブロックヘッダのハッシュ値を計算することと、ターゲットブロックのブロックヘッダのものであるとともに認証データソースに記憶されているハッシュ値とターゲットブロックのブロックヘッダの計算されたハッシュ値が一致しているかどうかを決定し、一致している場合には、未認証のデータが第2のブロックチェーン上のブロックに含まれていると決定することとをするようにさらに構成される。
【0015】
必要に応じて、引受クライアントは、第1のブロックチェーン上のノードデバイスに対応し、発行クライアントは、第2のブロックチェーン上のノードデバイスに対応する。
【0016】
本明細書は、プロセッサと、マシン実行可能命令を記憶するように構成されたメモリとを含む、電子デバイスをさらに提供している。メモリに記憶されているとともにブロックチェーンベースのクロスブロックチェーン認証制御ロジックに対応するマシン実行可能命令を読み込み実行することによって、プロセッサは、クロスチェーンクライアントを使用して、認証データソースとしてデータを使用するために、発行クライアントによって発行された第2のブロックチェーン上のデータを取得することと、第2のブロックチェーンから未認証のデータを受信することと、認証データソースと第1のブロックチェーンに対して設定されたデータ認証ルールとに基づいて未認証のデータに対してデータ認証を行うこととをするように構成される。
【0017】
上記の実施形態に従って、引受クライアントは、第1のブロックチェーンと第2のブロックチェーンとに独立して相互接続されているクロスチェーンクライアントを使用して、認証データソースとしてデータを使用するために、発行クライアントによって発行された第2のブロックチェーン上のデータを取得する。さらに、第2のブロックチェーンから未認証のデータを受信すると、引受クライアントは、認証データソースと第1のブロックチェーンに対して設定されたデータ認証ルールとに基づいて未認証のデータに対してデータ認証を行い得る。クロスチェーンクライアントは、引受および発行によって第1のブロックチェーンと第2のブロックチェーンとの間でデータを同期するために使用され得るし、同期されたデータは、ピアブロックチェーンからのデータを認証するために認証データソースとして使用される。したがって、互いに切り離されている場合に、異なるブロックチェーンは、ピアブロックチェーン上のデータを検証し、非侵襲的サイドチェーンアンカー処理を実施して、別のブロックチェーンにさらに効率的にアンカーされるとともに低複雑性かつ高拡張性のクロスチェーンネットワークを確立することができる。
【図面の簡単な説明】
【0018】
【
図1】例示的な実施形態による、クロスブロックチェーンインタラクションシステムを図示している概略アーキテクチャ図である。
【
図2】例示的な実施形態による、別のクロスブロックチェーンインタラクションシステムを図示している概略アーキテクチャ図である。
【
図3】例示的な実施形態による、クロスブロックチェーン認証方法を図示しているフローチャートである。
【
図4】例示的な実施形態による、未認証のトランザクションに対して行われるSPV認証を図示しているフローチャートである。
【
図5】例示的な実施形態による、クロスブロックチェーン関連転送システムを図示している概略構造図である。
【
図6】例示的な実施形態による、電子デバイスを図示している概略構造図である。
【
図7】例示的な実施形態による、クロスブロックチェーン認証装置を図示しているブロック図である。
【
図8】本開示の実施形態による、クロスブロックチェーン認証のためのコンピュータ実施方法の例を図示しているフローチャートである。
【発明を実施するための形態】
【0019】
サイドチェーン技術は、あるブロックチェーンがメインチェーンとして使用され、その後、サイドチェーンをメインチェーンに基づいて進展する技術であり、サイドチェーンアンカー処理がサイドチェーンとメインチェーンとの間で実施される。
【0020】
サイドチェーンは、メインチェーンからのデータを認証し得るブロックチェーンである。例えば、トランザクション、ブロック、または別の形式のブロックチェーンデータがメインチェーン上のブロックに含まれているかどうかが、サイドチェーン上で検証され得る。別のブロックチェーン上のデータを認証し得るブロックチェーンを他のブロックチェーンのサイドチェーンと称する。それに対応するように、サイドチェーンアンカー処理は、サイドチェーンがメインチェーンからのデータを認証する性能を有することができるようにサイドチェーン上で認証基底(通常、認証データソースと認証ルールとを含む)を設定するプロセスである。
【0021】
本明細書は、互いに切り離されている場合に、異なるブロックチェーンが非侵襲的サイドチェーンアンカー処理を実施することができるように、引受および発行モデルに基づいたサイドチェーンアンカー処理フレームワークを提供することを目的としている。
【0022】
実施中には、引受クライアント、発行クライアント、およびクロスチェーンクライアントを含む、クロスブロックチェーンインタラクションシステムが確立されていてもよい。引受クライアントは、第1のブロックチェーンに対応し、発行クライアントは、第2のブロックチェーンに対応し、クロスチェーンクライアントは、引受クライアンと発行クライアントとに独立して相互接続され得る。
【0023】
引受クライアントは、第2のブロックチェーンのデータについてクロスチェーンクライアントを引き受け、クロスチェーンクライアントを使用して、認証データソースとしてデータを使用するために、発行クライアントによって発行された第2のブロックチェーン上のデータを取得し得る。
さらに、第2のブロックチェーンから未認証のデータを受信すると、引受クライアントは、認証データソースと第1のブロックチェーンに対して設定されたデータ認証ルールとに基づいて未認証のデータに対してデータ認証を行い得る。
【0024】
上記の技術的ソリューションにおいては、クロスチェーンクライアントは、引受および発行によって第1のブロックチェーンと第2のブロックチェーンとの間でデータを同期するために使用され得るし、同期されたデータは、ピアブロックチェーンからのデータを認証するために認証データソースとして使用される。したがって、互いに切り離されている場合に、異なるブロックチェーンは、ピアブロックチェーン上のデータを検証し、非侵襲的サイドチェーンアンカー処理を実施して、別のブロックチェーンにさらに効率的にアンカーされるとともに低複雑性かつ高拡張性のクロスチェーンネットワークを確立することができる。
【0025】
特定の適用シナリオを参照して特定の実施形態を使用して本明細書を以下で説明している。
【0026】
図1を参照すれば、
図1は、例示的な実施形態による、クロスブロックチェーンインタラクションシステムを図示している概略アーキテクチャ図である。
【0027】
図1に示しているように、クロスブロックチェーンインタラクションシステムは、発行および引受モデルに基づいて確立されたサイドチェーンアンカー処理フレームワークであり得るし、次のような、第1のブロックチェーンと、第2のブロックチェーンとを含み得る。
【0028】
第1のブロックチェーンは、本明細書における引受クライアントに対応しているアンカー処理チェーン(サイドチェーンとして使用され得る)であり、それに対応するように、第2のブロックチェーンは、本明細書における発行クライアントに対応している被アンカー処理チェーン(メインチェーンとして使用され得る)である。
【0029】
本明細書では、「第1のブロックチェーン」および「第2のブロックチェーン」は異なるブロックチェーンの間で区別するためだけに使用されていることに留意されたい。第1のブロックチェーンは、概して、サイドチェーンとして使用され得るブロックチェーンの一種であり、第2のブロックチェーンは、概して、メインチェーンとして使用され得るブロックチェーンの一種である。あるブロックチェーンが「第1のブロックチェーン」であるか「第2のブロックチェーン」であるかが指定されているわけではない。
【0030】
引受クライアントは、第1のブロックチェーンに対応し、第2のブロックチェーンからの第1のブロックチェーンが引き受けるデータを保持するように構成される。
【0031】
図1に示しているように、ある実施形態においては、引受クライアントは、第1のブロックチェーン上のノードデバイスに対応し得るし、ノードデバイスに対応するメッセージキューを保持するように構成される。メッセージキューは、ノードデバイスが引き受けるデータを含む。
【0032】
例えば、引受クライアントは、第1のブロックチェーン上でスマートコントラクトを使用して実施されるクライアントソフトウェアコンポーネントであり得る、または、引受クライアントと相互接続されたノードデバイスの固有の拡張性能に基づいて実施されるクライアントソフトウェアコンポーネントであり得る。
【0033】
別の実施形態においては、引受クライアントは、第1のブロックチェーンから独立した、デバイス、ノード、プラットフォームなどの上に構成され得るし、実施されたブリッジインターフェースを使用して第1のブロックチェーンにブリッジされる。
【0034】
発行クライアントは、第2のブロックチェーンに対応し、コンセンサスを経て完了した第2のブロックチェーン上のデータを取得および発行するように構成される。
【0035】
例えば、実施中には、発行クライアントは、第2のブロックチェーン指向データクエリサービスを提供するためにブリッジインターフェースを実装し得るし、第2のブロックチェーンにブリッジされる。ブロックチェーンの分散型台帳機能に基づいて、第2のブロックチェーン上のすべてのノードデバイスが、完全な台帳データ、すなわち、コンセンサスによって同一のコンテンツを有するブロックチェーン台帳を維持管理し得る。発行クライアントは、クロスチェーンインタラクションエンドがメッセージを取得するように、発行されることが許可されたメッセージをブロックチェーン台帳から取得し得る。
【0036】
ある実施形態においては、発行クライアントは、第2のブロックチェーン上のノードデバイスに対応し得る。別の実施形態においては、発行クライアントは、第2のブロックチェーンから独立した、デバイス、ノード、プラットフォームなど上に構成され得る。別の実施形態においては、発行クライアントは、第2のブロックチェーン上のノードデバイス上に構成され得る。
【0037】
クロスチェーンインタラクションエンドは、ブリッジインターフェースを使用して、第1のブロックチェーンと第2のブロックチェーンとに独立して相互接続され、実施されたデータ転送ロジックに基づいて第1のブロックチェーンと第2のブロックチェーンとの間のクロスチェーンデータ同期を実施する。ある実施形態においては、クロスチェーンインタラクションエンドは、引受クライアントによって開始された引受要求を受信し得る。引受要求は、引受条件を含み、引受条件は、関連する引受要件をクロスチェーンインタラクションエンドに通知するために使用される。クロスチェーンインタラクションエンドは、引受クライアントによって保持されているデータ状態についてクエリを行うために引受クライアントに対して状態クエリメッセージを開始し、引受クライアントによって返信されたデータ状態に基づいて、引受クライアントによって保持されているデータが引受条件を満足するデータを含んでいるかどうかを決定し得る。
【0038】
例えば、実施中には、引受クライアントは、第1のブロックチェーン上のノードデバイスに対応し、ノードデバイスに対応するメッセージキューを保持して、ノードデバイスが引き受けるデータを保持し得る。そのようなケースでは、クロスチェーンインタラクションエンドは、メッセージキューのキュー状態についてクエリを行うために引受クライアントに対して状態クエリメッセージを開始し、メッセージキューのものであるとともに引受クライアントによって返信されるキュー状態に基づいて、メッセージキューが引受条件を満足するメッセージを含んでいるかどうかを決定し得る。
【0039】
引受クライアントによって保持されているデータが引受条件を満足するデータを含んでいる場合には、クロスチェーンインタラクションエンドは、再びデータを取得する必要はない。引受クライアントによって保持されているデータが引受条件を満足するデータを含んでいない場合には、クロスチェーンインタラクションエンドは、発行クライアントから引受条件を満足するデータを取得する必要がある。例えば、クロスチェーンエンドは、発行クライアントから引受条件を満足するデータを要求し得るし、引受クライアントによって保持されているデータを更新するために、引受クライアントに、発行クライアントによって返信されたデータを送信する。
【0040】
本明細書では、クロスチェーンインタラクションエンドは、発行クライアントと引受クライアントとの間でデータを転送するためだけに使用され、転送されたデータを持続的に記憶するまたは転送されたデータのデータ状態を保持する必要はない。ある実施形態においては、クロスチェーンインタラクションエンドは、第1のブロックチェーンおよび第2のブロックチェーンから独立した、デバイス、ノード、プラットフォームなど上に構成され得る。別の実施形態においては、クロスチェーンインタラクションエンドは、第1のブロックチェーン上のノードデバイス上にまたは第2のブロックチェーン上のノードデバイス上に構成され得る。
【0041】
さらに、
図2を参照されたい。実際の適用においては、複数の互いに独立したクロスチェーンインタラクションエンドが引受クライアントと発行クライアントとの間で構成され得る。換言すれば、引受クライアントおよび発行クライアントは、複数の独立したクロスチェーンインタラクションエンド、例えば、
図2に示したクロスチェーンインタラクションエンド1とクロスチェーンインタラクションエンド2とに独立して相互接続され得る。
【0042】
そのため、あるクロスチェーンインタラクションエンドがサービス妨害攻撃などに見舞われている場合には、サービス妨害攻撃に見舞われているクロスチェーンインタラクションエンドによって扱われているサービスを、別のクロスチェーンインタラクションエンドに速やかにハンドオーバすることができる。例えば、
図2に示しているように、クロスチェーンインタラクションエンド1がサービス妨害攻撃に見舞われている場合には、引受クライアントが、クロスチェーンインタラクションエンド2を使用して、発行クライアントによって発行されたメッセージを変わらず取得することができるように、クロスチェーンインタラクションエンド1によって扱われているサービスを、クロスチェーンインタラクションエンド2に即座にハンドオーバすることができる。
【0043】
上記の実施形態においては、発行および引受モデルに基づいて確立されたクロスブロックチェーンインタラクションシステムにおいて、発行クライアントおよび引受クライアントに独立してブリッジされているクロスチェーンインタラクションエンドは、発行および引受情報交換モードを使用して、第1のブロックチェーンと第2のブロックチェーンとの間のデータを同期するために使用される。したがって、第1のブロックチェーンと第2のブロックチェーンとの間でデータを切り離すことができ、第1のブロックチェーンおよび第2のブロックチェーンは、データ直接交換してデータ同期を完遂する必要はない。加えて、クロスチェーンインタラクションエンドが発行クライアントと引受クライアントとの間で使用されているため、発行クライアントおよび引受クライアントは、サービスという観点では切り離されており、そのため、発行クライアントおよび引受クライアントを開発する際の困難を大幅に低減している。例えば、発行クライアントに関連しているサービスロジックを第1のブロックチェーンに基づいて実施する必要はなく、引受クライアントに関連しているサービスロジックを第2のブロックチェーンに基づいて実施する必要はなく、発行クライアントに関連しているサービスロジックおよび引受クライアントに関連しているサービスロジックは、第1のブロックチェーンおよび第2のブロックチェーン上でそれぞれ実施することだけが必要である。
【0044】
図3を参照すれば、
図3は、本明細書の実施形態による、クロスブロックチェーン認証方法を示している。方法は、
図1に示したクロスブロックチェーンインタラクションシステム内の引受クライアントに適用され、以下のステップを含む。
【0045】
ステップ302: 引受クライアントが、クロスチェーンクライアントを使用して、認証データソースとしてデータを使用するために、発行クライアントによって発行された第2のブロックチェーン上のデータを取得する。
【0046】
ステップ304: 第2のブロックチェーンから未認証のデータを受信する。
【0047】
ステップ306: 認証データソースと第1のブロックチェーンに対して設定されたデータ認証ルールとに基づいて未認証のデータに対してデータ認証を行う。
【0048】
本実施形態において説明したブロックチェーンは、サイドチェーンとして使用され得るとともに別のブロックチェーンネットワークにアンカーされる任意のタイプのブロックチェーンネットワークを含み得る。
【0049】
例えば、あるシナリオでは、ブロックチェーンは、いくつかのメンバブロックチェーンを含むコンソーシアムブロックチェーン内の任意のメンバブロックチェーンであり得る。コンソーシアムブロックチェーンでは、各メンバブロックチェーンは、別のメンバブロックチェーンにアンカーされるようにサイドチェーンとして使用され得る。
【0050】
未認証のデータは、第1のブロックチェーン上のブロックに記録されている任意の形式のデータを含み得る。例えば、未認証のデータは、ランザクション(転送)、状態、およびイベントを含み得るがこれらに限定されない。
【0051】
本明細書では、第2のブロックチェーンに対応する認証基底は、引受クライアントが第2のブロックチェーン上のデータを認証することができるように、引受クライアントに設定され得るし、第1のブロックチェーンは、サイドチェーンとして使用されるとともに第2のブロックチェーンにアンカーされる。
【0052】
引受クライアントにおいて指定される認証基底は、通常、認証データソースと認証ルールとの2つの要素を含む。
【0053】
認証データソースは、第1のブロックチェーン上に記憶されているすべてのブロックのすべてまたは一部のデータを含み得る。
【0054】
認証データソースに含まれる特定のコンテンツが、通常、第1のブロックチェーンおよび第2のブロックチェーンによってサポートされているデータ認証プロトコルに依存していることに留意されたい。
【0055】
例えば、第1のブロックチェーンおよび第2のブロックチェーンが、簡易支払検証(SPV)認証プロトコルをサポートしている。そのようなシナリオでは、引受クライアントにおいて指定された認証データソースは、第2のブロックチェーン上に記憶されているすべてのブロックのブロックヘッダデータのみを含み得る。
【0056】
別の例では、第1のブロックチェーンおよび第2のブロックチェーンが、オラクル(Oracle)プロトコルをサポートしている。そのようなシナリオでは、引受クライアントにおいて指定された認証データソースは、第2のブロックチェーン上で選択された信頼できるノード(当局ノードとも称する)が第2のブロックチェーン上のデータに署名する際に使用される秘密鍵に対応する公開鍵または公開鍵のセットを含み得る。
【0057】
認証ルールは、第2のブロックチェーン上のデータを認証するための認証ロジックを含む。認証ルールに含まれる認証ロジックのタイプが、通常、第2のブロックチェーン上に記録されている特定のタイプのデータに依存していることに留意されたい。
【0058】
例えば、実際の適用においては、第2のブロックチェーン上のデータは、トランザクション、状態、およびイベントを含み得るがこれらに限定されない。それに対応するように、認証ルールは、トランザクション認証ロジック、ブロック認証ロジック、状態認証ロジック、およびイベント認証ロジックを含み得るがこれらに限定されない。加えて、認証ルールに含まれる認証ロジックの特定のコンテンツは、通常、第1のブロックチェーンによってサポートされているデータ認証プロトコルおよび第2のブロックチェーンに依存している。
【0059】
例えば、第1のブロックチェーンおよび第2のブロックチェーンは、SPVプロトコルをサポートしている。そのようなシナリオでは、引受クライアントにおいて指定された認証ルールに含まれる認証ロジックは、第2のブロックチェーンから引受クライアントによって取り出された未認証のデータが第2のブロックチェーン上のブロックに含まれているかどうかを認証するための認証ロジックであり得る。未認証のデータが第2のブロックチェーン上のブロックに含まれている場合には、未認証のデータに対する認証は成功である。
【0060】
別の例では、第1のブロックチェーンおよび第2のブロックチェーンが、Oracleプロトコルをサポートしている。そのようなシナリオでは、引受クライアントにおいて指定された認証ルールに含まれる認証ロジックは、第2のブロックチェーン上で選択された信頼できるノードが第2のブロックチェーン上のデータに署名する際に使用される秘密鍵に対応する指定の公開鍵または公開鍵のセットに基づいて、第2のブロックチェーンから引受クライアントによって取り出された未認証のデータにおいて搬送された署名を検証するための認証ロジックであり得る。未認証のデータにおいて搬送された署名が信頼できるノードの有効な署名である場合には、未認証のデータに対する認証は成功である。
【0061】
引受クライアントが第2のブロックチェーン上のデータを認証するプロセスを、第1のブロックチェーンおよび第2のブロックチェーンの両方がSPVプロトコルをサポートしており、未認証のデータが第2のブロックチェーン上のブロックに記録されているトランザクションである例を使用して詳細に以下に説明する。
【0062】
本実施形態においては、第1のブロックチェーンがサイドチェーンとして使用されるとともにメインチェーンとして使用される第2のブロックチェーンにアンカーされている場合には、第2のブロックチェーンに対応する認証基底は、引受クライアントに設定され得る。
【0063】
第2のブロックチェーン上のトランザクションを認証するために使用される認証ルールは、引受クライアントに設定され得る。SPVプロトコルについて、認証ルールは、未認証のトランザクションが第2のブロックチェーン上のブロックに含まれているかどうかを認証するための認証ロジックを含み得る。
【0064】
加えて、引受クライアントは、クロスチェーンインタラクションエンドを使用して発行クライアントとのクロスチェーンインタラクションを行い、第2のブロックチェーン上の各ブロックのものであるとともに発行クライアントによって発行されたブロックヘッダデータを取得して、認証データソースとしてブロックヘッダデータを使用し得る。
【0065】
実施中には、引受クライアントは、クロスチェーンインタラクションエンドに対して引受要求を開始し得るし、引受要求は、引受要件を示す引受条件を含み得る。SPVプロトコルについて、認証データソースは、第2のブロックチェーン、すなわち、第2のブロックチェーン上のブロックのブロックヘッダを含む「シンプルブロックチェーン」上の各ブロックのブロックヘッダデータであり得る。それに対応するように、引受要求において搬送された引受条件によって示される引受要件は、第2のブロックチェーン上の各ブロックのブロックヘッダデータを取得する要件であり得る。
【0066】
引受要求を取得した後に、クロスチェーンインタラクションエンドは、引受要求をパースし、引受要求において搬送された引受条件によって示される引受要件を取得し得る。
【0067】
引受クライアントから引受要件を取得した後に、クロスチェーンインタラクションエンドは、引受クライアントに対して状態クエリメッセージを開始して引受クライアントによって保持されているデータ状態についてクエリを行い、引受クライアントによって返信されたデータ状態に基づいて、引受クライアントによって保持されているデータが第2のブロックチェーン上のブロックのブロックヘッダを含むシンプルブロックチェーンを含んでいるかどうかを決定し得る。
【0068】
例えば、引受クライアントがメッセージキューを使用して引き受けたデータを保持する場合には、クロスチェーンインタラクションエンドは、引受クライアントに対して状態クエリメッセージを開始してメッセージキューのキュー状態についてクエリを行い、メッセージキューのものであるとともに引受クライアントによって返信されたキュー状態に基づいて、引受クライアントによって保持されているデータが第2のブロックチェーン上のブロックのブロックヘッダを含むシンプルブロックチェーンを含んでいるかどうかを決定し得る。
【0069】
引受クライアントによって保持されているデータが第2のブロックチェーン上のブロックのブロックヘッダを含むシンプルブロックチェーンを含んでいる場合には、クロスチェーンインタラクションエンドは、再び第2のブロックチェーン上の各ブロックのブロックヘッダデータを取得する必要はない。
【0070】
引受クライアントによって保持されているデータが第2のブロックチェーン上のブロックのブロックヘッダを含むシンプルブロックチェーンを含んでいない場合には、クロスチェーンインタラクションエンドは、発行クライアントから第2のブロックチェーン上の各ブロックのブロックヘッダデータを取得する必要がある。例えば、クロスチェーンインタラクションエンドは、データ同期要求を発行クライアントに送信して発行クライアントからの第2のブロックチェーン上の各ブロックのブロックヘッダデータを要求し、発行クライアントによって返信されたデータを引受クライアントに送信して、引受クライアントによって保持されているデータを更新し得る。
【0071】
当然のことながら、実際の適用においては、クロスチェーンインタラクションエンドが、上記で示した状態クエリプロセスを使用して、新規ブロックが第2のブロックチェーンに追加されたと決定した場合には、クロスチェーンインタラクションエンドは、上記で説明したデータ同期方法を使用して引受クライアントに第2のブロックチェーン上の新たに追加されたブロックのブロックヘッダデータを送信して、時宜を得た方法で、引受クライアントによって保持されているデータを更新し得る。
【0072】
本実施形態においては、第2のブロックチェーン上の各ブロックのブロックヘッダデータを受信した後に、引受クライアントは、受信したブロックヘッダデータをさらに認証して、受信したブロックヘッダデータが有効であるかどうかを決定し得る。受信したブロックヘッダデータを認証するために使用される認証ルールはまた、引受クライアントに事前設定され得るが、ブロックヘッダデータの有効性を認証するための認証ルールに対応する認証ロジックは本明細書において限定されない。
【0073】
例えば、ある実施形態においては、第1のブロックチェーンおよび第2のブロックチェーンは、プルーフ・オブ・ワークコンセンサス機構を使用し、プルーフ・オブ・ワークの「マイニング」の困難性に対応する乱数(Nonce)は、通常、ブロックヘッダに記録されている。そのようなケースでは、引受クライアントは、乱数に基づいてプルーフ・オブ・ワーク計算を行い、その後、計算結果に基づいてブロックヘッダデータの有効性を検証し得る。
【0074】
別の例では、別の実施形態においては、いくつかの信頼できるノードが第2のブロックチェーン上で選択され、信頼できるノードは、発行クライアントによって発行されたブロックヘッダデータに署名し得るし、引受クライアントは、信頼できるノードの公開鍵を使用して署名を認証して、受信したブロックヘッダデータが有効であるかどうかを決定し得る。
【0075】
受信したブロックヘッダデータの有効性を認証した後に、引受クライアントは、認証データソースとして受信データをローカルで記憶および設定し得る。その後、第2のブロックチェーンから未認証のトランザクションを受信すると、引受クライアントは、設定された認証ルールおよび認証データソースに基づいて未認証のトランザクションに対してSPVデータ認証を行って、未認証のトランザクションが第2のブロックチェーン上のブロックに含まれているかどうかを決定し得る。
【0076】
実際の適用においては、第2のブロックチェーンから引受クライアントによって受信された未認証のトランザクションは、発行クライアントによって実際に発行されるとともに、クロスチェーンインタラクションエンドを使用して発行クライアントとのクロスチェーンインタラクションを行うことによって引受クライアントによって受信される、トランザクション、または、トランザクション認証を開始したユーザによって手動で提示される、トランザクションであり得る。実施形態は本明細書において限定されない。
【0077】
図4を参照すれば、
図4は、本明細書の実施形態による、未認証のトランザクションに対して行われるSPV認証を図示しているフローチャートである。以下の実行ステップを含む。
【0078】
ステップ402: 未認証のトランザクションのハッシュ値を計算する。
【0079】
未認証のトランザクションに対してSPV認証を行うステップが、第2のブロックチェーン上の未認証のトランザクションを含むターゲットブロックのものであるとともにターゲットブロックのMerkleツリー上のMerkle認証経路上の各ノードのハッシュ値に基づいて逆向きの計算を行うことによって得られるハッシュ値と未認証のトランザクションのハッシュ値が同一であるかどうかを検証するプロセスであることに留意されたい。
【0080】
したがって、未認証のトランザクションに対してSPV認証を行う前に未認証のトランザクションのハッシュ値をまず計算する必要がある。未認証のトランザクションのハッシュ値を計算する具体的なプロセスは本実施形態では省略する。
【0081】
ステップ404: 未認証のトランザクションを含む第2のブロックチェーン上のターゲットブロックのMerkleツリー上の未認証のトランザクションのMerkle認証経路を取得する。
【0082】
ブロックチェーン上のブロックは、通常、ブロックヘッダとブロック本体(トランザクションを含む)との2つの要素を含む。ブロックに記録されているトランザクションは、通常、トランザクションのハッシュ値の形式でMerkleツリーを形成する。Merkleツリー上では、ブロックに記録されている各トランザクションのハッシュ値は、リーフノードとして使用される。2つの隣接トランザクションのハッシュ値が連結され、その後、結果が前段のレベルにある中継ノードのハッシュ値を取得するためにハッシュ化され、その後、すべての中継ノード間の2つの隣接ノードのハッシュ値が連結され、結果がまたさらに前段のレベルにある中継ノードのハッシュ値を取得するためにハッシュ化され、以下同様である。Merkleツリーのルートノードのハッシュ値が、複数回行われるレベルごとの計算の後に最終的に取得される。ハッシュ値は、ブロックヘッダのハッシュ値として使用され得る。ルートノードおよびリーフノードに加えて、Merkleツリーは、中間計算プロセスにおいて計算されたハッシュ値に対応するいくつかの中継ノードをさらに含む。
【0083】
ブロックに記録されているトランザクションのハッシュ値がMerkleツリーを形成する具体的なプロセスは本明細書において限定されない。本明細書の技術的ソリューションを実施する場合には、当業者は関連技術における説明を参照し得る。
【0084】
ブロックチェーン上の各ブロック内のMerkleツリー上のルートノード、すなわち、ブロックヘッダのハッシュ値は、通常、ブロックヘッダに記録されている。Merkleツリー上のルートノード以外の中継ノードおよびリーフノードはブロック本体に記憶されている。
【0085】
Merkle認証経路は、トランザクションのハッシュ値がMerkleツリー上でレベルごとにトラバースする経路上のノードに対応する兄弟ノード(すなわち、隣接ノード)を含む経路である。トランザクションに対してSPV認証を行うプロセスでは、トランザクションのMerkle認証経路は、トランザクションのMerkleツリー上のルートノードに対応するハッシュ値を逆向きに計算するための計算パラメータとして使用され得る。
【0086】
Merkle認証経路は、トランザクション認証を開始したユーザによって手動で提示され得る、または、クロスチェーンインタラクションエンドを使用して発行クライアントとクロスチェーンインタラクションを行うことによってアクティブクエリ処理により引受クライアントによって取得され得ることに留意されたい。
【0087】
ある方法では、ユーザが第1のブロックチェーン上の引受クライアント上で第2のブロックチェーンからのトランザクションを認証することを要求する場合には、ユーザは、認証パラメータとして第2のブロックチェーン上のトランザクションを含むターゲットブロックのMerkleツリー上のトランザクションのMerkle認証経路を使用し、引受クライアントにMerkle認証経路を提示し得る。
【0088】
別の方法では、引受クライアントが、未認証のトランザクションに対応するMerkle認証経路について実際にクエリを行い取得するために、クロスチェーンインタラクションエンドを使用して発行クライアントとのクロスチェーンインタラクションを行う場合には、発行クライアントはまず、未認証のトランザクションのハッシュ値に基づいて第2のブロックチェーン上のトランザクションのブロックを探し出し得る。
【0089】
トランザクションのハッシュ値に基づいてトランザクションのブロックを探し出すプロセスは本明細書では省略する。例えば、関連技術においては、Bloomフィルタが、トランザクションのハッシュ値のブロックを探し出すために、デプロイされている。未認証のトランザクションのブロックを探し出した後に、未認証のトランザクションのハッシュ値のMerkle認証経路が、探し出したブロックのMerkleツリーからさらに特定され得るし、その後、Merkle認証経路が、引受クライアントに送信される。
【0090】
ステップ406: 未認証のトランザクションのハッシュ値およびMerkle認証経路上の各ノードのハッシュ値に基づいてターゲットブロックのブロックヘッダのハッシュ値を計算する。
【0091】
未認証のトランザクションのMerkle認証経路を取得した後に、引受クライアントは、SPVプロトコルにおいて指定された計算プロセスに基づいて、ターゲットブロックのブロックヘッダのハッシュ値(すなわち、ターゲットブロックのMerkleツリー上のルートノードのハッシュ値)を計算し得る。
【0092】
例えば、SPVプロトコルに基づいて、未認証のトランザクションのハッシュ値とMerkle認証経路上にあるとともに未認証のトランザクションのノードに対応する兄弟ノードのハッシュ値とを連結し、結果が前段のレベルにある中継ノードのハッシュ値を取得するためにハッシュ化され、その後、中継ノードのハッシュ値とMerkle認証経路上の中継ノードに対応する兄弟ノードのハッシュ値とを連結し、結果がさらに前段のレベルにある中継ノードのハッシュ値を取得するためにハッシュ化され、ルートノードのハッシュ値が計算されるまで、換言すれば、第2のブロックチェーン上の未認証のトランザクションのターゲットブロックのブロックヘッダのハッシュ値が取得されるまで、以下同様である。
【0093】
ステップ408: ターゲットブロックのブロックヘッダのものであるとともに認証データソースに記憶されているハッシュ値とターゲットブロックのブロックヘッダの計算されたハッシュ値が一致しているかどうかを決定し、一致している場合には、未認証のトランザクションが第2のブロックチェーン上のブロックに含まれていると決定する。
【0094】
第2のブロックチェーン上の未認証のトランザクションのターゲットブロックのブロックヘッダのハッシュ値を計算した後に、引受クライアントは、ターゲットブロックのブロックヘッダの計算されたハッシュ値をターゲットブロックのブロックヘッダ上のものであるとともにローカルに設定された認証データソースに記憶されているハッシュ値とマッチングし得る。2つのハッシュ値が一致している場合には、未認証のトランザクションが第2のブロックチェーン上のブロックに含まれており、未認証のトランザクションに対する認証は成功であり、または、2つのハッシュ値が一致していない場合には、未認証のトランザクションは第2のブロックチェーン上のブロックに含まれておらず、未認証のトランザクションに対する認証は失敗である。
【0095】
未認証のトランザクションに対する認証が成功であると、引受クライアントは、第1のブロックチェーン上の未認証のトランザクションに関連している動作をトリガし得る。
【0096】
理解を容易にするために、クロスブロックチェーン関連転送シナリオを説明のための例として使用している。
【0097】
図5を参照すれば、
図5は、例示的な実施形態による、クロスブロックチェーン関連転送システムを図示している概略構造図である。
図5に示しているように、ユーザAがブロックチェーン1上にアカウントA1とブロックチェーン2上にアカウントA2とを独立して有しており、ユーザBがブロックチェーン1上にアカウントB1とブロックチェーン2上にアカウントB2とを独立して有していると仮定する。ブロックチェーン1上のアカウントA1およびアカウントB1は、あるタイプのアセットオブジェクト(例えば、人民元)を維持管理するために使用され、ブロックチェーン2上のアカウントA2およびアカウントB2は、別のタイプのアセットオブジェクト(例えば、セキュリティ)を維持管理するために使用される。ユーザAがセキュリティをユーザBに販売することを希望した場合には、次のような、指定の数量のセキュリティアセットがアカウントA2からアカウントB2に転送され、その後、指定の額の人民元がアカウントB1からアカウントA1に転送される、関連転送ロジックを使用し得る。
【0098】
転送プロセスにおける信頼性を改善するために、対応するスマートコントラクトは、2つの上記の転送プロセスを自動的に完遂し、ユーザの手動の転送プロセスにおける意図的なまたは意図的ではない転送量エラー、遅延などを回避し、転送プロセスが迅速かつ正確に完遂されることを保証するために、ブロックチェーン1およびブロックチェーン2上で独立して設定され得る。
【0099】
本明細書の技術的ソリューションに基づけば、上記で説明したプロセスに基づいて、ブロックチェーン1は、サイドチェーンとして使用され得るし、メインチェーンとして使用されるブロックチェーン2にアンカーされる。そのようなケースでは、ユーザは、実行のための入力としてスマートコントラクトに、指定の数量のセキュリティアセットがブロックチェーン2上でアカウントA2からアカウントB2に転送される、完遂されたトランザクションを提示し得る。そして、引受クライアント(例えば、SPVウォレット)は、ブロックチェーン2上の設定された認証データソース(すなわち、ブロックヘッダデータを含むシンプルブロックチェーン)に基づいて、トランザクションがブロックチェーン2上のブロックに含まれているかどうかを認証し得る。認証が成功した場合には、上記のスマートコントラクトは、指定の額の人民元がブロックチェーン1上でアカウントB1からアカウントA1に転送されるトランザクションをトリガするために起動され得る。
【0100】
引受クライアントが、第1のブロックチェーンと第2のブロックチェーンとに独立して相互接続されているクロスチェーンクライアントを使用して、認証データソースとしてデータを使用するために、発行クライアントによって発行された第2のブロックチェーン上のデータを取得することを上記の実施形態から理解できよう。さらに、第2のブロックチェーンから未認証のデータを受信すると、引受クライアントは、認証データソースと第1のブロックチェーンに対して設定されたデータ認証ルールとに基づいて未認証のデータに対してデータ認証を行い得る。クロスチェーンクライアントは、引受および発行によって第1のブロックチェーンと第2のブロックチェーンとの間でデータを同期するために使用され得るし、同期されたデータは、ピアブロックチェーンからのデータを認証するために認証データソースとして使用される。したがって、互いに切り離されている場合に、異なるブロックチェーンは、ピアブロックチェーン上のデータを検証し、非侵襲的サイドチェーンアンカー処理を実施して、別のブロックチェーンにさらに効率的にアンカーされるとともに低複雑性かつ高拡張性のクロスチェーンネットワークを確立することができる。
【0101】
上記の方法の実施形態に対応しており、本明細書は、クロスブロックチェーン認証装置の実施形態をさらに提供する。本明細書におけるクロスブロックチェーン認証装置の実施形態は、電子デバイスに適用され得る。装置の実施形態は、ソフトウェア、ハードウェア、またはハードウェアとソフトウェアとの組合せによって実施され得る。ソフトウェア実施形態を例として使用する。ロジック装置として、装置は、装置が位置している電子デバイスのプロセッサによって実行するためにメモリに不揮発性メモリ内の対応するコンピュータプログラム命令を読み込むことによって形成される。ハードウェアに関しては、
図6に示しているように、
図6は、本明細書における、クロスブロックチェーン認証装置が位置している電子デバイスを図示しているハードウェア構造図である。
図6に示したプロセッサ、メモリ、ネットワークインターフェース、および不揮発性メモリに加えて、本実施形態において装置が位置している電子デバイスは、通常、電子デバイスの実際の機能に基づいた他のハードウェアをさらに含み得る。簡潔にするために詳細は省略する。
【0102】
図7は、本明細書の例示的な実施形態による、クロスブロックチェーン認証装置を図示しているブロック図である。
【0103】
図7を参照すれば、クロスブロックチェーン認証装置70は、
図6に示した電子デバイスに適用され得るし、電子デバイスは、引受クライアント、発行クライアント、およびクロスチェーンクライアントを含む、クロスブロックチェーンインタラクションシステムに位置している。引受クライアントは、第1のブロックチェーンに対応し、発行クライアントは、第2のブロックチェーンに対応し、クロスチェーンクライアントは、引受クライアントと発行クライアントとに独立して相互接続される。装置70は、獲得モジュール701、受信モジュール702、および認証モジュール703を含む。
【0104】
獲得モジュール701は、クロスチェーンクライアントを使用して、認証データソースとしてデータを使用するために、発行クライアントによって発行された第2のブロックチェーン上のデータを取得するように構成される。
【0105】
受信モジュール702は、第2のブロックチェーンから未認証のデータを受信するように構成される。
【0106】
認証モジュール703は、認証データソースと第1のブロックチェーンに対して設定されたデータ認証ルールとに基づいて未認証のデータに対してデータ認証を行うように構成される。
【0107】
本実施形態においては、獲得モジュール701は、クロスチェーンインタラクションエンドに対して引受要求を開始することであって、引受要求は、クロスチェーンインタラクションエンドが、引受条件に基づいて、発行クライアントからの引受条件を満足する第2のブロックチェーン上のデータを要求するように、引受条件をクロスチェーンインタラクションエンドに通知するために使用される、ことと、認証データソースとしてデータを使用するために、発行クライアントによって発行されるとともに引受条件を満足する第2のブロックチェーン上のデータを取得することとをするように構成される。
【0108】
本実施形態においては、認証データソースは、第2のブロックチェーン上の各ブロックのブロックヘッダデータを含む。
【0109】
本実施形態においては、認証モジュール703は、未認証のデータが第2のブロックチェーン上のブロックに含まれているかどうかを決定するために、認証データソースと第1のブロックチェーンに対して設定されたデータ認証ルールとに基づいて未認証のデータに対してSPVデータ認証を行うように構成される。
【0110】
本実施形態においては、認証モジュール703は、未認証のデータのハッシュ値を計算することと、未認証のデータを含む第2のブロックチェーン上のターゲットブロックのMerkleツリー上の未認証のデータのMerkle認証経路を取得することと、未認証のデータのハッシュ値とMerkle認証経路上の各ノードのハッシュ値とに基づいてターゲットブロックのブロックヘッダのハッシュ値を計算することと、ターゲットブロックのブロックヘッダのものであるとともに認証データソースに記憶されているハッシュ値とターゲットブロックのブロックヘッダの計算されたハッシュ値が一致しているかどうかを決定し、一致している場合には、未認証のデータが第2のブロックチェーン上のブロックに含まれていると決定することとをするようにさらに構成される。
【0111】
本実施形態においては、引受クライアントは、第1のブロックチェーン上のノードデバイスに対応し、発行クライアントは、第2のブロックチェーン上のノードデバイスに対応する。
【0112】
装置内の各モジュールの機能および役割の実施プロセスについては、上記の方法における対応するステップの実施プロセスを参照されたい。簡潔にするために詳細はここでは省略する。
【0113】
装置の実施形態は、方法の実施形態に基本的に対応しているため、関連する部分については、方法の実施形態における関連する説明を参照されたい。上記で説明した装置の実施形態は一例に過ぎない。別個の部分として説明したモジュールは、物理的に別個のものであってもなくてもよいし、モジュールとして表示した部分は、物理モジュールであってもなくてもよいし、1つのロケーションに配置されてもよいし、または複数のネットワークモジュールに分散されてもよい。本明細書におけるソリューションの目的を実現するために実際のニーズに基づいてモジュールの一部またはすべてを選択することができる。当業者は、創造的努力無しで本明細書の実施形態を理解および実施できよう。
【0114】
上記の実施形態において説明したシステム、装置、またはモジュールは、コンピュータチップまたはエンティティを使用して実装され得る、または、ある機能を有する製品を使用して実装され得る。典型的な実施形態デバイスは、コンピュータであり、コンピュータは、パーソナルコンピュータ、ラップトップコンピュータ、セルラ電話、カメラ電話、スマートフォン、携帯情報端末、メディアプレーヤ、ナビゲーションデバイス、電子メール送受信デバイス、ゲームコンソール、タブレットコンピュータ、ウェアラブルデバイス、またはこれらのデバイスの任意の組合せであり得る。
【0115】
上記の方法の実施形態に対応しており、本明細書は、電子デバイスの実施形態をさらに提供する。電子デバイスは、引受クライアント、発行クライアント、およびクロスチェーンクライアントを含む、クロスブロックチェーンインタラクションシステムに位置しており、引受クライアントは、第1のブロックチェーンに対応し、発行クライアントは、第2のブロックチェーンに対応し、クロスチェーンクライアントは、引受クライアントと独立して相互接続され、発行クライアントおよび電子デバイスは、プロセッサと、マシン実行可能命令を記憶するように構成されたメモリとを含み、プロセッサとメモリとは、通常、内部バスを使用して互いに接続されている。別の可能な実施形態においては、デバイスは、別のデバイスまたはコンポーネントと通信するために、外部インターフェースをさらに含み得る。
【0116】
本実施形態においては、メモリに記憶されているとともにクロスブロックチェーン認証制御ロジックに対応するマシン実行可能命令を読み込み実行することによって、プロセッサは、クロスチェーンクライアントを使用して、認証データソースとしてデータを使用するために、発行クライアントによって発行された第2のブロックチェーン上のデータを取得することと、第2のブロックチェーンから未認証のデータを受信することと、認証データソースと第1のブロックチェーンに対して設定されたデータ認証ルールとに基づいて未認証のデータに対してデータ認証を行うこととをするように構成される。
【0117】
本実施形態においては、メモリに記憶されているとともにクロスブロックチェーン認証制御ロジックに対応するマシン実行可能命令を読み込み実行することによって、プロセッサは、クロスチェーンインタラクションエンドに対して引受要求を開始することであって、引受要求は、クロスチェーンインタラクションエンドが、引受条件に基づいて、発行クライアントからの引受条件を満足する第2のブロックチェーン上のデータを要求するように、引受条件をクロスチェーンインタラクションエンドに通知するために使用される、ことと、プロセッサによって実施される引受クライアントによって、認証データソースとしてデータを使用するために、発行クライアントによって発行されるとともに引受条件を満足する第2のブロックチェーン上のデータを取得することとをするように構成される。
【0118】
本実施形態においては、メモリに記憶されているとともにクロスブロックチェーン認証制御ロジックに対応するマシン実行可能命令を読み込み実行することによって、プロセッサは、未認証のデータが第2のブロックチェーン上のブロックに含まれているかどうかを決定するために、認証データソースと第1のブロックチェーンに対して設定されたデータ認証ルールとに基づいて未認証のデータに対してSPVデータ認証を行うように構成される。
【0119】
本実施形態においては、メモリに記憶されているとともにクロスブロックチェーン認証制御ロジックに対応するマシン実行可能命令を読み込み実行することによって、プロセッサは、未認証のデータのハッシュ値を計算することと、未認証のデータを含む第2のブロックチェーン上のターゲットブロックのMerkleツリー上の未認証のデータのMerkle認証経路を取得することと、未認証のデータのハッシュ値とMerkle認証経路上の各ノードのハッシュ値とに基づいてターゲットブロックのブロックヘッダのハッシュ値を計算することと、ターゲットブロックのブロックヘッダのものであるとともに認証データソースに記憶されているハッシュ値とターゲットブロックのブロックヘッダの計算されたハッシュ値が一致しているかどうかを決定し、一致している場合には、未認証のデータが第2のブロックチェーン上のブロックに含まれていると決定することとをするように構成される。
【0120】
当業者は、本明細書を検討しここで本開示を実施した後であれば、本明細書の別の実施形態ソリューションを容易に把握し得よう。本明細書は、本明細書の任意の変形、使用、または適合をカバーすることを意図しており、これらの変形、使用、または適合は、本明細書の一般的な原理に従っており、本明細書の技術分野において開示していない一般常識または従来の技法を含む。本明細書および実施形態は例としてみなされるものに過ぎず、本明細書の実際の範囲および精神は以下の特許請求の範囲によって示されている。
【0121】
本明細書は上記で説明し図面に示したものと寸分違わぬ構造に限定されず、本明細書の範囲から逸脱しない限り様々な修正および変更をなし得ることを理解されたい。本明細書の範囲は、添付の特許請求の範囲のみによって限定される。
【0122】
上記の説明は、本明細書の望ましい実施形態に過ぎず、本明細書を限定することは意図していない。本明細書の精神および原理から逸脱することなくなされた任意の修正、均等物との置換、または改良は、本明細書の保護範囲に含まれるものとする。
【0123】
図8は、本開示の実施形態による、クロスブロックチェーン認証のためのコンピュータ実施方法の例を図示しているフローチャート800である。提示を明確にするために、以下の説明は、本説明における他の図に即して方法800を一般的に説明している。しかしながら、方法800が、例えば、任意のシステム、環境、ソフトウェア、およびハードウェアによって、または、必要に応じて、システムと、環境と、ソフトウェアと、ハードウェアとの組合せによって、行われ得ることは理解されよう。いくつかの実施形態においては、方法800の様々なステップは、並行して、組み合わせて、ループして、または任意の順序で動作され得る。
【0124】
802において、クロスブロックチェーンインタラクションシステムのクロスチェーンクライアントを使用して引受クライアントによってデータを取り出す。データは、例えば、トランザクション、状態、またはイベントであり得る。データは、発行クライアントによって発行された第2のブロックチェーンから取り出される。データは、例えば、認証データソースとして使用される。クロスブロックチェーンインタラクションシステムは、引受クライアント、発行クライアント、およびクロスチェーンクライアントを含む。引受クライアントは、第1のブロックチェーンに対応し、第2のブロックチェーンから第1のブロックチェーンが引き受けるデータを保持するように構成される。引受クライアントは、例えば、第1のブロックチェーン上のノードデバイスに対応し得る、ここで、ノードデバイスは、ノードデバイスに対応するメッセージキューを保持するように構成される。発行クライアントは、第2のブロックチェーンに対応し、コンセンサスを経て完了した第2のブロックチェーン上のデータを取得および発行するように構成され得る。クロスチェーンクライアントは、引受クライアントと独立して相互接続される。発行クライアントおよび第1のブロックチェーンは、メインチェーンとして使用される第2のブロックチェーンにアンカーされるサイドチェーンとして使用される。例として、
図1のクロスブロックチェーンインタラクションシステムを参照すれば、データを、クロスブロックチェーンインタラクションシステムのクロスチェーンクライアントを使用して
図1の引受クライアントによって取り出し得る。
図1のクロスブロックチェーンインタラクションシステムは、例えば、発行および引受モデルに基づいて確立されたサイドチェーンアンカー処理フレームワークであり得る。データは、
図1の発行クライアントによって発行された
図1の第2のブロックチェーンから取り出され得る。
図1のクロスブロックチェーンインタラクションシステムは、
図1の引受クライアントおよび
図1の発行クライアントを含む。クロスチェーンクライアントエンドは、
図1の発行クライアントと
図1の引受クライアントとの間のインタラクションを処理し得る。引受クライアントは、
図1の第1のブロックチェーンに対応し得るし、発行クライアントは、
図1の第2のブロックチェーンに対応し得る。クロスチェーンクライアントは、引受クライアンと独立して相互接続され得る。発行クライアントおよび第1のブロックチェーンは、メインチェーンとして使用される第2のブロックチェーンにアンカーされるサイドチェーンとして使用され得る。いくつかの実施形態においては、引受クライアントは、例えば、第1のブロックチェーン上のノードデバイスに対応し得る。いくつかの実施形態においては、発行クライアントは、例えば、第2のブロックチェーン上のノードデバイスに対応し得る。
【0125】
いくつかの実施形態においては、データを取り出すステップは引受要求の使用を含み得る。例えば、
図1の引受クライアントによって開始された引受要求は、
図1のクロスチェーンインタラクションエンドに送信され得る。引受要求は、引受条件をクロスチェーンインタラクションエンドに通知するために使用され得る。要求は、クロスチェーンインタラクションエンドが、引受条件に基づいて、
図1の発行クライアントからの引受条件を満足する
図1の第2のブロックチェーン上のデータを要求するようにトリガし得る。
図1の発行クライアントによって発行されるとともに引受条件を満足する
図1の第2のブロックチェーン上のデータを、認証データソースとしてデータを使用するために、
図1の引受クライアントを使用して取り出し得る。例えば、認証データソースは、
図1の第2のブロックチェーン上の各ブロックのブロックヘッダデータを含み得る。いくつかの実施形態においては、認証データソースは、
図1の第1のブロックチェーンおよび
図1の第2のブロックチェーンによってサポートされているデータ認証プロトコルに依存し得る。
【0126】
いくつかの実施形態においては、認証ルールは、第2のブロックチェーン上に記録されている特定のタイプのデータに依存する認証ロジックを含み得る。例えば、ブロックチェーンネットワーク内の各ブロックチェーン(
図1のクロスブロックチェーンインタラクションシステムの第2のブロックチェーンなど)は、ブロックチェーンによって使用されるデータのタイプなどに基づいて、ブロックチェーンに固有の認証ルールを有し得る。802から、方法800は804に進む。
【0127】
804において、第2のブロックチェーンから未認証のデータを受信する。例えば、
図1のクロスブロックチェーンインタラクションシステム内の第2のブロックチェーンからのデータは、
図1のクロスブロックチェーンインタラクションシステム内の発行クライアントにおいて受信され得る。804から、方法800は806に進む。
【0128】
806において、認証データソースと第1のブロックチェーンに対して設定されたデータ認証ルールとに基づいて未認証のデータに対してデータ認証が行われる。例えば、
図1のクロスブロックチェーンインタラクションシステムは、
図1のクロスブロックチェーンインタラクションシステム内の第2のブロックチェーンから受信したデータに対してデータ認証を行い得る。
【0129】
いくつかの実施形態においては、認証データソースと第1のブロックチェーンに対して設定されたデータ認証ルールとに基づいて未認証のデータに対してデータ認証を行うステップは、簡易支払検証(SPV)データ認証を行うステップを含み得る。例えば、SPVデータ認証は、認証データソースと
図1の第1のブロックチェーンに対して設定されたデータ認証ルールとに基づいて未認証のデータに対して行われ得る。例えば、SPVデータ認証は、未認証のデータが第2のブロックチェーン上のブロックに含まれているかどうかを決定し得る。
【0130】
いくつかの実施形態においては、認証データソースと第1のブロックチェーンに対して設定されたデータ認証ルールとに基づいて未認証のデータに対してSPVデータ認証を行うステップはハッシュ値の使用を含み得る。例えば、未認証のデータのハッシュ値が計算され得る。未認証のデータを含む第2のブロックチェーン上のターゲットブロックのMerkleツリー上の未認証のデータのMerkle認証経路を取り出し得る。例えば、未認証のデータのハッシュ値とMerkle認証経路上の各ノードのハッシュ値とに基づいて、ターゲットブロックのブロックヘッダのハッシュ値を計算し得る。認証データソースに記憶されているターゲットブロックのブロックヘッダ中のハッシュ値とターゲットブロックのブロックヘッダの計算されたハッシュ値が一致しているかどうかを決定し得る。認証データソースに記憶されているターゲットブロックのブロックヘッダ中のハッシュ値とターゲットブロックのブロックヘッダの計算されたハッシュ値が一致していると決定したことに応答して、未認証のデータが第2のブロックチェーン上のブロックに含まれていると決定し得る。806の後に、方法800は停止する。
【0131】
本開示は、クロスブロックチェーン認証に関する。詳細には、方法は、次のような、引受クライアントによって、クロスチェーンクライアントを使用して、認証データソースとしてデータを使用するために、発行クライアントによって発行された第2のブロックチェーン上のデータを取得するステップと、第2のブロックチェーンから未認証のデータを受信するステップと、認証データソースと第1のブロックチェーンに対して設定されたデータ認証ルールとに基づいて未認証のデータに対してデータ認証を行うステップとを含む。方法およびデバイスの利点は、互いに切り離されている場合に、異なるブロックチェーンがピアブロックチェーン上のデータを検証することができることにある。異なるブロックチェーンは、その後、非侵襲的サイドチェーンアンカー処理を実施して、別のブロックチェーンに効率的にアンカーするとともに低複雑性かつ高拡張性のクロスチェーンネットワークを確立し得る。簡易支払検証(SPV)データ認証は、認証データソースと第1のブロックチェーンに対して設定されたデータ認証ルールとに基づいて未認証のデータに対して行われ得る。SPVデータ認証は、未認証のデータが第2のブロックチェーン上のブロックに含まれているかどうかを決定するために使用され得る。未認証のデータに対するSPVデータ認証は、未認証のデータのハッシュ値、MerkleツリーのMerkle認証経路上の各ノードのハッシュ値、およびターゲットブロックのブロックヘッダに記憶されているハッシュ値の使用を含み得る。
【0132】
本明細書において説明した実施形態および動作は、本明細書において開示した構造またはそれらのうちの1つまたは複数の組合せを含む、デジタル電子回路の形式で、またはコンピュータソフトウェア、ファームウェア、もしくはハードウェアの形式で実装され得る。動作は、1つまたは複数のコンピュータ可読記憶デバイス上に記憶されるまたは他のソースから受信されるデータに対してデータ処理装置によって行われる動作として実装され得る。データ処理装置、コンピュータ、またはコンピューティングデバイスは、例として、プログラマブルプロセッサ、コンピュータ、システム・オン・チップ、または前述したもののうちの複数もしくは組合せを含む、処理データのための装置、デバイス、マシンを含み得る。装置は、例えば、中央処理ユニット(CPU)、フィールドプログラマブルゲートアレイ(FPGA)、または特定用途向け集積回路(ASIC)といった、特殊用途ロジック回路を含み得る。装置はまた、例えば、プロセッサファームウェア、プロトコルスタック、データベース管理システム、オペレーティングシステム(例えばオペレーティングシステムもしくはオペレーティングシステムの組合せ)、クロスプラットフォームランタイム環境、仮想マシン、またはそれらのうちの1つもしくは複数の組合せを構成するコードといった、当該コンピュータプログラムのための実行環境を作成するコードを含み得る。装置および実行環境は、ウェブサービス、分散コンピューティング、およびグリッドコンピューティングインフラなどといった、様々な異なるコンピューティングモデルインフラを実現し得る。
【0133】
コンピュータプログラム(例えば、プログラム、ソフトウェア、ソフトウェアアプリケーション、ソフトウェアモジュール、ソフトウェアユニット、スクリプト、またはコードとしても知られる)は、コンパイル型またはインタプリタ型言語、宣言型または手続き型言語を含む、任意の形式のプログラミング言語で書かれ得るし、スタンドアロンプログラムとして、またはモジュール、コンポーネント、サブルーチン、オブジェクト、もしくはコンピューティング環境における使用に適した他のユニットとしてといったことを含む、任意の形式でデプロイされ得る。プログラムは、他のプログラムまたはデータを保持しているファイルの一部(例えば、マークアップ言語ドキュメントに記憶されている1つまたは複数のスクリプト)に、当該のプログラム専用の単一のファイルに、または複数の協調ファイル(例えば、1つまたは複数のモジュール、サブプログラム、またはコードの一部を記憶するファイル)に記憶され得る。コンピュータプログラムは、1つのコンピュータ上で、または、1つのサイトに位置しもしくは複数のサイトにわたって分散され、通信ネットワークによって相互接続された、複数のコンピュータ上で実行され得る。
【0134】
コンピュータプログラムの実行のためのプロセッサは、例として、汎用および特殊用途マイクロプロセッサの両方、ならびに任意の種類のデジタルコンピュータの任意の1つまたは複数のプロセッサを含む。一般的に、プロセッサは、リードオンリーメモリもしくはランダムアクセスメモリまたはその両方から命令およびデータを受信することになる。コンピュータの必須の要素は、命令に従ってアクションを行うためのプロセッサと、命令およびデータを記憶するための1つまたは複数のメモリデバイスとである。一般的に、コンピュータはまた、データを記憶するための1つまたは複数のマスストレージデバイスを含むことになる、または、そのようなマスストレージデバイスからデータを受信もしくはそのようなマスストレージデバイスにデータを送信もしくはその両方を行うことが動作可能なように結合されることになる。コンピュータは、例えば、モバイルデバイス、携帯情報端末(PDA)、ゲームコンソール、全地球測位システム(GPS)受信機、またはポータブルストレージデバイスといった、別のデバイスに組み込まれ得る。コンピュータプログラム命令およびデータを記憶するのに適したデバイスは、例として、半導体メモリデバイス、磁気ディスク、および光磁気ディスクといった、不揮発性メモリ、媒体、およびメモリデバイスを含む。プロセッサおよびメモリは、特殊用途ロジック回路によって補完され得る、またはそれに組み込まれ得る。
【0135】
モバイルデバイスは、ハンドセット、ユーザ機器(UE)、モバイル電話(例えば、スマートフォン)、タブレット、ウェアラブルデバイス(例えば、スマートウォッチおよびスマートメガネ)、人体内部の埋め込みデバイス(例えば、バイオセンサ、人工内耳)、または他のタイプのモバイルデバイスを含み得る。モバイルデバイスは、様々な通信ネットワーク(以下で説明)と無線で(例えば、無線周波数(RF)信号を使用して)通信し得る。モバイルデバイスは、モバイルデバイスの現在の環境の特性を決定するためのセンサを含み得る。センサは、カメラ、マイクロフォン、近接センサ、GPSセンサ、モーションセンサ、加速度計、照度センサ、水分センサ、ジャイロスコープ、コンパス、気圧計、指紋センサ、顔認識システム、RFセンサ(例えば、Wi-Fiおよびセルラ無線)、熱センサ、または他のタイプのセンサを含み得る。例えば、カメラは、可動または固定レンズ、フラッシュ、画像センサ、および画像プロセッサを有する、前面または背面カメラを含み得る。カメラは、顔および/または虹彩認識のために細部をキャプチャすることが可能なメガピクセルカメラであり得る。データプロセッサ、およびメモリに記憶されているまたはリモートでアクセスされる認証情報とともに、カメラは、顔認識システムを形成し得る。顔認識システム、または、例えば、マイクロフォン、モーションセンサ、加速度計、GPSセンサ、もしくはRFセンサといった、1つまたは複数のセンサが、ユーザ認証のために使用され得る。
【0136】
ユーザとのインタラクションを提供するために、実施形態は、例えば、情報を表示するための液晶ディスプレイ(LCD)または有機発光ダイオード(OLED)/仮想現実(VR)/拡張現実(AR)ディスプレイと、ユーザがコンピュータに入力を提供することを可能にするタッチスクリーン、キーボード、およびポインティングデバイスといった、表示デバイスと入力デバイスとを有するコンピュータ上で実施され得る。同様に、他の種類のデバイスがユーザとのインタラクションを提供するために使用され得る。例えば、ユーザに提供されるフィードバックは、例えば、視覚フィードバック、聴覚フィードバック、または触覚フィードバックといった任意の形式の感覚フィードバックであり得るし、ユーザからの入力は、音響、音声、または触覚入力を含む任意の形式で受信され得る。加えて、コンピュータは、ユーザによって使用されるデバイスにドキュメントを送信することおよびユーザによって使用されるデバイスからドキュメントを受信することによって、例えば、ユーザのクライアントデバイス上のウェブブラウザから受信した要求に応答してウェブブラウザにウェブページを送信することによって、ユーザとのインタラクションを行い得る。
【0137】
実施形態は、任意の形式または媒体の有線または無線デジタルデータ通信(またはその組合せ)、例えば、通信ネットワークによって相互接続されたコンピューティングデバイスを使用して実施され得る。相互接続されたデバイスの例としては、通信ネットワークを介して通常はやりとりする、一般的に互いにリモートに存在するクライアントとサーバとがある。例えば、モバイルデバイスといった、クライアントは、購入、売却、支払、贈与、送付、もしくは貸付のトランザクションを行うもしくはこれらを許可するサーバとのトランザクションを、またはそのようなサーバを介したトランザクションを、それ自身で実行し得る。そのようなトランザクションは、アクションとレスポンスとが時間的にほぼ同じであるリアルタイムであり得る。例えば、個人が、アクションとレスポンスとが実質的に同時に知覚し、個人のアクションの後のレスポンスについての時間差が1ミリ秒(ms)または1秒(s)未満である、またはレスポンスは、システムの処理限界を考慮しつつも意図的な遅延は有していない。
【0138】
通信ネットワークの例としては、ローカルエリアネットワーク(LAN)、無線アクセスネットワーク(RAN)、メトロポリタンエリアネットワーク(MAN)、およびワイドエリアネットワーク(WAN)を含む。通信ネットワークは、インターネット、別の通信ネットワーク、または通信ネットワークの組合せのすべてまたは一部を含み得る。情報は、ロング・ターム・エボリューション(LTE)、5G、IEEE802、インターネットプロトコル(IP)、または他のプロトコルもしくはプロトコルの組合せを含む、様々なプロトコルおよび標準に準拠した通信ネットワーク上で送信され得る。通信ネットワークは、接続されたコンピューティングデバイス間で、音声、ビデオ、生体、もしくは認証データ、または他の情報を送信し得る。
【0139】
別個の実施形態として説明した特徴を、組合せで、単一の実施形態で実施し得る一方で、単一の実施形態として説明した特徴を、複数の実施形態で、独立して、または任意の適切なサブコンビネーションで実施し得る。特定の順序で説明および主張した動作は、その特定の順序を必要とするものとして理解されるべきではないし、図示した動作のすべてを行う必要があると理解すべきではない(いくつかの動作がオプションであり得る)。必要に応じて、マルチタスク処理または並列処理(またはマルチタスク処理と並列処理との組合せ)が行われ得る。
【符号の説明】
【0140】
70 クロスブロックチェーン認証装置
701 獲得モジュール
702 受信モジュール
703 認証モジュール