特開 2022-51652 デジタル資産データパケットの信頼性検証システム

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

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2022051652

(43)【公開日】2022-04-01

(54)【発明の名称】デジタル資産データパケットの信頼性検証システム

(51)【国際特許分類】

   H04L 9/32 20060101AFI20220325BHJP

【ＦＩ】

H04L9/00 675B

H04L9/00 675Z

【審査請求】有

【請求項の数】9

【出願形態】ＯＬ

(21)【出願番号】P 2020217136

(22)【出願日】2020-12-25

(11)【特許番号】

(45)【特許公報発行日】2021-07-28

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

(32)【優先日】2020-09-21

(33)【優先権主張国・地域又は機関】CN

(71)【出願人】

【識別番号】521012474

【氏名又は名称】江蘇傲為控股有限公司

(74)【代理人】

【識別番号】100105924

【弁理士】

【氏名又は名称】森下 賢樹

(72)【発明者】

【氏名】ジェ バイ

(57)【要約】

【課題】本願はデジタル資産データパケットの信頼性検証システムを開示する。
【解決手段】デジタル資産データパケットの操作を実行する異なるメインチェーン又はサブチェーン上の複数のノードを含む複数の実行端末ノードと、統合機能に対応する役割が予め付与された複数の統合ノードと、検証機能に対応する役割が予め付与された複数の検証ノードとを含み、まずは検証ノードが実行端末ノードにデジタル資産データパケットに対する信頼性検証要求を送信し、実行端末ノードが検証要求を受信し、実行端末ノードの各秘密鍵でデータパケットにデジタル署名を行い、検証ノードがデジタル署名を検証し、各デジタル署名が検証をパスした場合、統合ノードがトリガされてデジタル署名を統合し、統合ノードがデジタル署名に対して統合操作を行って統合署名を生成し、検証ノードが統合署名の結果を検証し、検証をパスした場合、データパケットは信頼できる。
【選択図】図４

【特許請求の範囲】

【請求項1】

デジタル資産データパケットの信頼性検証システムであって、
前記デジタル資産データパケットの操作を実行する異なるメインチェーン又はサブチェーン上の複数のノードを含む複数の実行端末ノードと、統合機能に対応する役割が予め付与された複数の統合ノードと、検証機能に対応する役割が予め付与された複数の検証ノードと、を含み、
前記検証ノードは、
前記実行端末ノードにデジタル資産データパケットに対する信頼性検証要求を送信する検証要求ステップを行うように構成され、
前記実行端末ノードは、
前記検証ノードから送信された検証要求を受信する検証受信ステップと、
前記実行端末ノードのそれぞれの秘密鍵で、前記データパケットに少なくとも１つのデジタル署名を行うデジタル署名ステップと、を行うように構成され、
前記検証ノードは、さらに、
前記デジタル署名を検証するデジタル署名検証ステップと、
各前記デジタル署名が検証をパスした場合、前記統合ノードがトリガされて前記デジタル署名を統合する統合トリガステップと、を行うように構成され、
前記統合ノードは、
前記デジタル署名に対して統合操作を行って統合署名を生成する統合署名生成ステップを行うように構成され、
前記検証ノードは、さらに、
前記統合署名を検証し、検証をパスした場合、前記データパケットは信頼できるものである統合署名検証ステップを行うように構成される、
ことを特徴とするデジタル資産データパケットの信頼性検証システム。

【請求項2】

前記実行端末ノードは、さらに、
検証ノードが信頼できるノードであるか否かを判断し、前記検証ノードが信頼できる場合、前記信頼性検証要求を受信し、前記検証ノードが信頼できない場合、前記信頼性検証要求を拒否するノード信頼性判断ステップを行うように構成される、
ことを特徴とする請求項１に記載のデジタル資産データパケットの信頼性検証システム。

【請求項3】

前記統合ノードは、さらに、
前記統合ノードが初めて前記デジタル署名を統合するとき、前記全てのデジタル署名を検証する初回検証ステップと、
前記デジタル署名が全ての検証をパスした場合、初回の統合署名結果を検証し、前記統合署名結果の検証方法は、前記検証ノードにより予め決定される統合結果検証ステップと、を行うように構成される、
ことを特徴とする請求項１に記載のデジタル資産データパケットの信頼性検証システム。

【請求項4】

前記実行端末ノードは、さらに、
前記データパケットに対する前記実行端末ノードの取引操作プロセスに基づいて、ノードの階層に従って前記データパケットの処理プロセス信頼性ツリーを生成する信頼性ツリー生成ステップと、
前記信頼性ツリーにおける各取引操作を暗号化する信頼性ツリー暗号化ステップと、
前記各取引操作を検証し、悪意のある操作があるか否かを判断する信頼性ツリー検証ステップと、
悪意のある操作がある場合う、前記悪意のある操作に対応する実行端末ノードを記録し、プリセットの時間に従って前記信頼性ツリーを段階的に保存する信頼性ツリー保存ステップと、を行うように構成される、
ことを特徴とする請求項１に記載のデジタル資産データパケットの信頼性検証システム。

【請求項5】

前記統合署名は、前記信頼性ツリーに従って前記デジタル署名に対して統合署名を行う、
ことを特徴とする請求項４に記載のデジタル資産データパケットの信頼性検証システム。

【請求項6】

前記ノードの階層の確認ステップは、
前記データパケットを初めて操作する実行端末ノードをルートノードとするルートノード確認ステップと、
前記ルートノードを第１階層のノードとして、前記ルートノードの次の階層のノードを第２階層のノードとし、前記第２階層のノードの次の階層のノードを第３階層のノードとし、前記データパケットが経由する全てのノードの記録が完了するまで行うサブノード確認ステップと、を含む、
ことを特徴とする請求項４に記載のデジタル資産データパケットの信頼性検証システム。

【請求項7】

前記デジタル署名ステップは、
前記データパケットのオリジナルデータに対して、ハッシュ計算によりデジタルダイジェストを生成するダイジェスト生成ステップと、
前記データパケットが所在するノードの秘密鍵で前記デジタルダイジェストを暗号化してデジタル署名を得るダイジェスト暗号化ステップと、
前記デジタル署名と前記データパケットのオリジナルデータとを共に前記検証ノードに送信するデジタル署名送信ステップと、を含む、
ことを特徴とする請求項１に記載のデジタル資産データパケットの信頼性検証システム。

【請求項8】

前記デジタル署名の検証方式は、
前記検証ノードと前記実行端末ノードとの間の事前ネゴシエーションによって決定されることができる、
ことを特徴とする請求項１に記載のデジタル資産データパケットの信頼性検証システム。

【請求項9】

前記数個の検証ノードは、信頼できるノードを少なくとも１つ含む、
ことを特徴とする請求項１に記載のデジタル資産データパケットの信頼性検証システム。

【請求項10】

前記検証ノードは、さらに、
前記データパケットが信頼できる場合、前記検証ノードに前記データパケットを保存するデータパケット保存ステップを行うように構成され、
前記データパケット保存ステップは、
前記信頼できるデータパケットを分割して、複数のグループ化データパケットを得るデータパケット分割ステップと、
各前記グループ化データパケットを暗号化するグループ化データパケット暗号化ステップと、
各前記暗号化されたグループ化データパケットを前記検証ノードに保存する暗号化データパケット保存ステップと、を含む、
ことを特徴とする請求項１に記載のデジタル資産データパケットの信頼性検証システム。

【発明の詳細な説明】

【技術分野】

【0001】

本願は、インターネットデータ処理の分野に関し、特にブロックチェーンネットワークに基づくデジタル資産データパケットの信頼性検証システムに関する。

【背景技術】

【0002】

デジタル資産金融システムは、通常、デジタル資産の信頼性などの問題を解決するために、ブロックチェーンをキャリアネットワークとして使用する。例えば、デジタル資産の生成や取引のようなシステムの各機能の実現は、通常、パブリックチェーンの異なるノード又はサブチェーンによって完成される。図１に示す簡単なブロックチェーンネットワークの概略図では、異なるノードは、異なる機能又は操作を実現するために用いられる。図１に示すネットワークＰを１つの簡単なパブリックチェーンと見なすことができ、ここで、ノード１は、デジタル資産の生成を実現するために用いられ、ノード２は、デジタル資産の取引を実現するために用いられる。図２に示す典型的なブロックチェーンネットワークの概略図では、異なる機能又は操作は、異なるサブチェーン、又はサブチェーンのノードによって実現される。図２に示すように、パブリックチェーンＰには、４つのサブチェーンが接続されており、サブチェーン３は、デジタル資産生成サブチェーンとして生成サブチェーンと略称し、サブチェーン４は、デジタル資産取引サブチェーンとして取引サブチェーンと略称し、サブチェーン５は、デジタル資産保存サブチェーンとして保存サブチェーンと略称し、サブチェーン６は、デジタル資産検証サブチェーンとして検証サブチェーンと略称する。図１又は図２において、異なる機能又は操作を実現するためのノードは、ブロックチェーンネットワークの従来の技術メカニズム、通常、例えば選択又は競合メカニズムなどによって決定される。また、図２に示すサブチェーン間のパブリックチェーンを介するクロスチェーン操作については、ここでは議論しない。

【0003】

図２に示すブロックチェーンネットワークは、典型的なデジタル資産金融システムのキャリアネットワークであり、サブチェーンの機能及び操作は、互に関連し、例えば、生成用サブチェーン３に使用されるデータ構造及びメカニズムは、検証サブチェーン６などの他のサブチェーンによって実現される機能に使用されるデータ構造及びメカニズムと相関性があり、そうではなければ、対応する機能又は操作を実現することができない。図２における各サブチェーン間の関係について、図３を参照しながら説明する。

【0004】

図２に示すサブチェーン３は、デジタル資産生成サブチェーンの例示として、デジタル資産を生成するプラットフォームを担うためのデジタル資産生成ノード３１と、公平性、評価、デューデリジェンス、担保などのプラットフォームを担うための他のノード３２、３３、３４、３５と、を含み、各プラットフォームは、複数のノードからなる端末ノードで構成される１つ又は複数のサブチェーンをリンクする。図３を参照し、図３は、図２に示すブロックチェーンネットワークによって担われるデジタル資産金融システムのサブチェーン同士の関係図であり、デジタル資産生成ノード３１によって生成されたデジタル資産データパケットＡは、ノード３２、３３、３４、３５に伝送され、デジタル資産データパケットＡの一部の属性ｂ１、ｂ２、ｂ３、ｂ４を生成するために用いられ、例えば評価値、公平性事項、デューデリジェンスデータ、担保事項などのデータを表現するために用いられ、これらの属性ｂ１、ｂ２、ｂ３、ｂ４は、ノード３１によって加工された後、デジタル資産データパケットＡの属性Ｂを形成する。前記デジタル資産データパケットＡと前記属性Ｂは共に取引可能なデジタル資産データパケットＤを形成し、取引サブチェーン４の取引の検証、又は保存サブチェーン５の保存に使用するように提供するため、前記デジタル資産データパケットＤは、ノード３１によって取引サブチェーン４と保存サブチェーン５に送信される。又は、前記デジタル資産データパケットＤは、ノード３１によって保存サブチェーン５に送信され、取引サブチェーン４がサブチェーン５から取引可能なデジタル資産データパケットＤを取得する。勿論、前記デジタル資産データパケットＤは、サブチェーン５に保存されるか、又は取引サブチェーン４によって取引されるためには、信頼性を備える必要がある。

【0005】

しかしながら、例えばノード障害、ノードが攻撃されるなどの様々な理由により、ブロックチェーンネットワークは、デジタル資産データパケットの信頼性を保証することができなくなり、即ち、保存サブチェーン５に保存されたデジタル資産データパケットが完全な信頼性を有することを保証することをできない。信頼性を保証する方法とは、デジタル資産データパケットが検証に耐えることができるということである。通常、任意のプラットフォーム又は任意のブロックチェーンノードは、信頼できるノードを介して、あるデジタル資産データパケットに対する検証要求を開始し、デジタル資産データパケットの各検証用サブ項目をさらに検証する。例えば、図２において、ノード３２、３３、３４、３５は、いずれも多くの端末によって同じ時間帯又は異なる時間帯にディフサーブ（Ｄｉｆｆｅｒｅｎｔｉａｔｅｄ Ｓｅｒｖｉｃｅｓ）が提供される可能性がある。つまり、デジタル資産データパケットＡの一部の属性ｂ１、ｂ２、ｂ３又はｂ４は、いずれも複数の端末の協働操作の結果である可能性がある。従って、デジタル資産データパケットの信頼性は、各端末操作の信頼性によって実現され、デジタル資産データパケットの信頼性を検証することは、各端末操作の信頼性を検証することである。通常、全ての端末の操作結果、即ち最終的に形成された属性Ｂ又はデジタル資産データパケットＤに対してハッシュ署名を行い、こうすると、検証を実行するノードは、属性Ｂ又はデジタル資産データパケットＤに対するハッシュ計算により、属性Ｂ又はデジタル資産データパケットＤの信頼性に関する結論を得るが、勿論、これは、属性Ｂ又はデジタル資産データパケットＤの形成プロセス及び出所の信頼性を保証することができない。

【0006】

改良方法として、前記属性Ｂ又はデジタル資産データパケットＤのオペレーターに対して検証操作を行い、検証操作は、通常、前記属性Ｂ又はデジタル資産データパケットＤが生成された後の不確定タイミングに検証要求が生成されるため、このような方法を使用して、オペレーターを１名ずつ追跡して検証するには、複雑な検索や削除/選択の操作が必要であり、関連するブロックチェーンのサービスノードが多く、データ量が大きいため、消費されるリソースが多く、効率が低いことになる。

【発明の概要】

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

【0007】

本願は、上記の技術的問題に基づいて、デジタル資産データパケットの信頼性検証システムを提供し、本願が解決しようとする問題は、リソース消費が少なく、効率が高いデジタル資産データパケットの信頼性検証システムを提供することである。

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

【0008】

デジタル資産データパケットの信頼性検証システムは、前記デジタル資産データパケットの操作を実行する異なるメインチェーン又はサブチェーン上の複数のノードを含む複数の実行端末ノードと、統合機能に対応する役割が予め付与された複数の統合ノードと、検証機能に対応する役割が予め付与された複数の検証ノードと、を含む。

【0009】

前記検証ノードは、
実行端末ノードにデジタル資産データパケットに対する信頼性検証要求を送信する検証要求ステップを行うように構成される。

【0010】

前記実行端末ノードは、
前記検証ノードから送信された検証要求を受信する検証受信ステップと、
実行端末ノードのそれぞれの秘密鍵で、前記データパケットに少なくとも１つのデジタル署名を行うデジタル署名ステップと、を行うように構成される。

【0011】

前記検証ノードは、さらに、
前記デジタル署名を検証するデジタル署名検証ステップと、
各前記デジタル署名が検証をパスした場合、統合ノードがトリガされて前記デジタル署名を統合する統合トリガステップと、を行うように構成される。

【0012】

前記統合ノードは、
前記デジタル署名に対して統合操作を行って統合署名を生成する統合署名生成ステップを行うように構成される。

【0013】

前記検証ノードは、さらに、
前記統合署名を検証し、検証をパスした場合、前記データパケットは信頼できるものである統合署名検証ステップを行うように構成される。

【発明の効果】

【0014】

上記の技術的解決手段によれば、本願に係るデジタル資産データパケットの信頼性検証システムは、デジタル資産データパケットの操作を実行する異なるメインチェーン又はサブチェーン上の複数のノードを含む複数の実行端末ノードと、統合機能に対応する役割が予め付与された複数の統合ノードと、検証機能に対応する役割が予め付与された複数の検証ノードと、を含み、まずは検証ノードが実行端末ノードにデジタル資産データパケットに対する信頼性検証要求を送信し、実行端末ノードが検証要求を受信し、実行端末ノードのそれぞれの秘密鍵でデータパケットにデジタル署名を行い、検証ノードがデジタル署名を検証し、各デジタル署名が検証をパスした場合、統合ノードがトリガされてデジタル署名を統合し、統合ノードがデジタル署名に対して統合操作を行って統合署名を生成し、検証ノードが統合署名の結果を検証し、検証をパスした場合、前記データパケットは信頼できるものである。統合署名は、検証を１回のみパスすればよいため、署名検証のコストを大幅低減させ、実行端末ノードの保存スペースに対する占有を節約することができる。

【0015】

本願の実施例や従来技術の技術的解決手段をより明瞭に説明するために、以下、実施例に必要な図面について簡単に説明するが、以下に記載した図面は、単に本願の実施例の一部にすぎず、当業者であれば、創造的な働き無しで、これらの図面に基づいて他の図面を得ることもできることは明らかである。

【図面の簡単な説明】

【0016】

【図1】簡単なブロックチェーンネットワークの例示図である。

【図2】典型的なブロックチェーンネットワークの例示図である。

【図3】図２に示すブロックチェーンネットワークによって担われるデジタル資産金融システムのサブチェーン同士間の関係図である。

【図4】デジタル資産データパケットの信頼性検証プロセスの概略図である。

【図5】データパケットの取引操作中に形成された信頼性ツリーの概略図である。

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

【0017】

本願の目的、技術的解決手段及び利点をより明確にするために、以下、本願の具体的な実施例及び対応の図面を参照しながら、本願の技術的解決手段について明確且つ完全に説明する。記載された実施例は、本願の一部の実施例にすぎず、全ての実施例ではないことは明らかである。本願の実施例に基づいて、当業者の創造的な働き無しで取得される他の実施例の全ては、いずれも本願の保護範囲に属する。以下、図面を参照しながら、本願の各実施例にて提供される技術的解決手段について詳細に説明する。

【0018】

インターネット技術の発展と応用に伴い、電子マネー、Ｑコイン、オンラインゲーム、幾つかのアプリケーションソフトウェアなどのデジタル資産が登場し、人々の生産と生活に溶け込みつつあり、インターネット時代の不可欠な構成部分となっている。これらは、企業や個人に所有されるか、又は管理され、電子データ形態で存在し、一定の価値があるか、又は経済的利益をもたらすことが期待される様々なリソースをデジタル資産と総称する。デジタル資産は、日常生活のよく見られるのであり、例えば、デジタル資産の一般的な表現形態には、映画のチケット、ゲーム内装備、有料コースウェア、有料音楽、スター投票、仮想ポイントなどがあり、デジタル資産が主に関連する分野において、よく見られるものは、文学、映画、ゲーム、アニメーション、金融などの分野がある。

【0019】

パケット（Ｐａｃｋｅｔ）は、ＴＣＰ／ＩＰプロトコル通信伝送におけるデータ単位であり、一般に「データパケット」とも呼ばれ、デジタル資産データパケットとは、デジタル資産がデータパケットの形態でインターネットに存在するのを指す。デジタル資産データパケットの信頼性を保証するために、通常、ブロックチェーンをキャリアネットワークとして使用するが、デジタル資産データパケットの取引プロセスにおいて、多くの中間プロセスデータが生成され、例えば、ブロックチェーンネットワーク上で、メインチェーン上のあるノードがデジタル資産データパケットに対して取引を開始し、当該取引操作プロセスで、メインチェーン上の複数のサブチェーンを経て、サブチェーン上のいくつかのノードを経た次の階層のノードがあり、つまり、デジタル資産データパケットは、取引の全般プロセスにおいて、多くの端末ノードを経由し、且つ大量のプロセスデータが生成され、デジタル資産データパケット全体の信頼性を保証するために、プロセスデータ全部を検証する必要があり、一般的な方法としては追跡検証方法であるが、取引中に関連するブロックチェーンサービスノードが多く、データ量が多いため、検証中に消費するリソースが多く、効率が低下する。

【0020】

本願に係るデジタル資産データパケットの信頼性検証システムは、複数の実行端末ノード、複数の統合ノード及び複数の検証ノードを含む。実行端末ノードは、デジタル資産データパケットの操作を実行する異なるメインチェーン又はサブチェーン上の複数のノードを含み、ブロックチェーン内のあるノードがデジタル資産データパケット（以下、データパケットと略称する）に対して取引操作を行う場合、このノードが実行端末ノードであり、通常、１つのデータパケットの取引操作は多くのノードを経由するため、対応して実行端末ノードの数も多い。統合ノードは、統合機能に対応する役割が予め付与されたノードであり、統合ノードは、主に分散している署名を統合し、複数の署名を統合して１つの統合署名とし、それは、１つの取引の複数の署名、又は複数の取引のそれぞれの参加者の公開鍵（ｐｕｂｌｉｃ ｋｅｙ）と署名とを１つの公開鍵と署名とに統合することができ、全体の統合プロセスは不可見であり、検証する際に１回の検証のみで済む。検証ノードは、検証機能に対応する役割が予め付与されたノードであり、主に、データパケットの取引プロセスにおけるノードの信頼性及び署名の信頼性を検証し、ブロックチェーン上のあるノードが一体どのノードであるかは、予め付与された機能の役割に依存し、１つのノードが、実行端末ノードでありながらも、統合ノード及び検証ノードであることもでき、実行端末ノード、検証ノード及び統合ノードの数に対しては限定しないが、複数の検証ノードには少なくとも１つの信頼できるノードが含まれ、これを基に、デジタル資産データパケットに対する信頼性検証要求を開始する。

【0021】

図４を参照すると、図４は、デジタル資産データパケットの信頼性検証プロセスの概略図であり、本願のデジタル資産データパケットの信頼性検証システムは、次の通りである。

【0022】

検証ノードは、
実行端末ノードにデジタル資産データパケットに対する信頼性検証要求を送信する検証要求ステップを行うように構成される。

【0023】

なお、検証ノードが実行端末ノードに対して信頼性検証要求を開始する前に、実行端末ノードは、さらに、ノード信頼性の判断ステップを実行する必要があり、即ち、実行端末ノードは、検証ノードが信頼できるノードであるか否かを判断し、本願では、具体的な判断方法について特に限定せず、検証ノードが信頼できる場合、信頼性検証要求を受信し、即ち、検証ノードがデジタル資産データパケットの信頼性を検証することができ、検証ノードが信頼できない場合、例えば、以前に、データを修正したか、又は悪意を持ってノードに偽装したなどの信頼できない行為が発生したことがある場合、実行端末ノードは、検証ノードの信頼性検証要求を拒否し、即ち、検証ノードがデジタル資産データパケットに対する信頼性検証プロセスを実行できない。

【0024】

実行端末ノードは、
検証ノードから送信された検証要求を受信し、実行端末ノードが、検証ノードは信頼できるノードであると判断した場合、検証ノードから送信された検証要求を受信する検証受信ステップと、
実行端末ノードのそれぞれの秘密鍵（ｐｒｉｖａｔｅ ｋｅｙ）でデータパケットに対して少なくとも１つのデジタル署名を行うデジタル署名ステップと、
を行うように構成される。
初期のデータパケットは、取引開始の直後に１つ以上の実行端末ノードに割り当てられる可能性も、分割されて異なる実行端末ノードに割り当てられる可能性もある。ブロックチェーンは、実行端末ノード及びそれぞれの取引、各段階の信頼性を保証するために、主にデジタル署名を使用して権限の制御を実現し、各実行端末ノードのデータパケット取引に対して、各実行端末ノードの秘密鍵を使用してデジタル署名を行い、秘密鍵に対応する公開鍵を公開し、デジタル署名に秘密鍵を使用することは、改ざん防止メカニズムを有するため、取引開始者の正当なアイデンティティを識別し、悪意のあるノードがアイデンティティを偽装することを防ぎ、より一層、第三者による取引の改ざんを防ぐことができる。

【0025】

デジタル署名は、電子署名とも呼ばれ、特定のアルゴリズムにより従来の物理署名と同様の効果が実現される。デジタル署名は、署名コンテンツを暗号学分野関連のアルゴリズムで処理して、取得した署名を表すための文字列である。暗号学分野では、１セットのデジタル署名アルゴリズムは、通常、署名と署名検証との２つの演算を含み、データに署名した後、従来の物理署名のように専門的な手段で認証する必要なく、セットの署名検証方法で検証すればよい。

【0026】

デジタル署名は、通常、非対称暗号化アルゴリズムを使用し、即ち、ノードごとには１ペアの秘密鍵と公開鍵とが必要であり、いわゆる秘密鍵とは、個人のみが所有できる鍵であり、署名時に秘密鍵を使用する必要がある。物理署名の筆跡と同様に、同じ列のデータに対する異なる秘密鍵の署名は完全に異なる。デジタル署名は、一般に、付加的情報としてオリジナルメッセージに添付されて、メッセージ送信者のアイデンティティを証明する。公開鍵は、誰でも取得可能な鍵であり、署名を検証するには公開鍵が必要であり、公開鍵は誰でも取得できるため、全てのノードでアイデンティティの正当性を確認することができる。

【0027】

デジタル署名は、具体的に、ダイジェスト生成ステップと、ダイジェスト暗号化ステップと、デジタル署名送信ステップと、を含む。

【0028】

ダイジェスト生成ステップでは、データパケットのオリジナルデータに対して、ハッシュ計算によりデジタルダイジェストを生成する。本願では、デジタル資産データパケットの初期データに対してハッシュ計算を行って、デジタルダイジェストを生成する。

【0029】

ダイジェスト暗号化ステップでは、データパケットが所在するノードの秘密鍵を用いてデジタルダイジェストを暗号化して、デジタル署名を得る。本願では、デジタル署名が所在する実行端末ノードの秘密鍵を用いて生成したデジタルダイジェストを暗号化する。

【0030】

デジタル署名送信ステップでは、デジタル署名とデータパケットのオリジナルデータとを共に検証ノードに送信する。

【0031】

検証ノードは、さらに、デジタル署名検証ステップと、統合トリガステップと、を行うように構成される。

【0032】

デジタル署名検証ステップでは、実行端末ノードのデジタル署名結果を検証し、デジタル署名の検証方式は、検証ノードと実行端末ノードとの間の事前ネゴシエーションによって決定されることができ、本願ではこれに対して具体的に限定しない。

【0033】

統合トリガステップでは、各デジタル署名がそれぞれ検証をパスした場合、統合ノードがトリガされてデジタル署名を統合して、統合署名を生成する。統合署名は、１つの実行端末ノード又は複数の実行端末ノードの複数のデジタル署名データを統合して、実行端末ノードに対応する統合署名データを生成したものであり、即ち、複数のユーザが複数のメッセージにそれぞれ署名した複数の署名を、１つの短い署名に統合することができる。

【0034】

統合ノードは、
デジタル署名に対して統合操作を行って、統合署名を生成する統合署名生成ステップを行うように構成され、統合署名は、付加的性質を持つデジタル署名であり、圧縮とバッチ処理の性質を有し、実際の運用において、より有利な要因として、統合署名は検証できるものでありかつ１回の検証のみで済み、即ち、初めて複数のデジタル署名を統合して統合署名を生成する際に、関連する全てのデジタル署名及びデジタル署名が統合された後の統合署名に対して検証する必要があり、一たび初回検証をパスすると、以後再検証する際に、そのうちのデジタル署名を検証する必要がなく、最後に生成された統合署名結果のみを検証すればよいということである。統合署名のルールは、統合署名の結果が検証をパスすれば、統合署名を生成する各デジタル署名がいずれも検証をパスすることを意味する。

【0035】

検証ノードは、さらに、
統合署名を検証し、検証をパスした場合、データパケットは信頼できるものである統合署名検証ステップを行うように構成される。

【0036】

統合署名の検証には、１つは、初めて統合署名を行う際に、統合署名に関連する全てのデジタル署名を検証する場合と、もう１つは、統合署名を初期化する際に統合署名を検証する場合との２つの場合がある。具体的には次のとおりである。

【0037】

初回検証ステップでは、統合ノードがデジタル署名に対して統合署名を初めて行う場合、全てのデジタル署名を検証する必要がある。デジタル署名の検証方式を予め決定することができ、例えば、デジタル署名データの検証方式は、送信者の秘密鍵でダイジェスト情報を暗号化し、オリジナルテキストとともに受信者に伝送し、受信者は自分の公開鍵で暗号化されたダイジェスト情報を復号化し、続いて、ＨＡＳＨ関数を用いて受信したオリジナルテキストに対してダイジェスト情報を生成し、復号化されたダイジェスト情報と比較する。同じであると、受信した情報が完全なものであり、伝送中に修正されていないことを意味し、そうでないと、情報が修正されたことを意味するため、デジタル署名は、情報の完全性を検証することができる。なお、初めて統合署名を行うときのみに、全てのデジタル署名データを検証する必要があり、初回の検証をパスした後、その後では、全てのデジタル署名データを検証する必要がなく、統合署名の結果を検証するのみでよい。

【0038】

統合結果検証ステップでは、初回統合署名において、全てのデジタル署名が検証をパスした場合、初回統合署名の結果を検証するか、又は、実際の運用において、統合署名を初期化する際に、初期化認証を行う必要があり、ここでの初期化には、例えば、データパケットの取引が担われるシステムが日々パワーオン起動したり、システムを再起動したりするなどの場合が含まれ、統合署名結果の検証方式は、検証ノードにより予め決定されることができる。例えば、統合署名結果は、各デジタル署名データの積であってもよく、検証ノードは、統合した署名に対して検証を１回行うだけで、統合署名に係るデジタル署名が、指定された実行端末ノードがデータパケット及び関連の属性、段階に対してそれぞれ行った署名からのものであるか否かを確信することができ、署名の検証及び伝送効率を大幅向上させることができる。統合署名結果は、ユーザが実際のニーズに応じてカスタマイズした他のアルゴリズムであってもよく、本願では具体的に限定しない。

【0039】

デジタル署名に対して１つずつ追跡検証を行うことと比較して、統合署名は検証を１回だけパスすればよいため、署名の検証コストを大幅低減させることができ、また、複数の署名を１つの署名に統合したため、実行端末ノードの保存スペースに対する占有を大幅節約することができ、デジタル署名に対して統合署名を行う目的は、リソース消費が少なく、効率の高いデジタル資産データパケットの信頼性検証システムを提供することである。

【0040】

データパケットの取引プロセスをより明確に記録するために、実行端末ノードは、さらに、信頼性ツリー生成ステップと、信頼性ツリー暗号化ステップと、信頼性ツリー検証ステップと、信頼性ツリー保存ステップと、を行うように構成される。

【0041】

信頼性ツリー生成ステップでは、データパケットに対する実行端末ノードの取引操作プロセスに基づいて、ノードの階層に応じてデータパケットの処理プロセスの信頼性ツリーを生成し、ここでの信頼性ツリーとは、データパケットが経由した全ての実行端末ノードの操作プロセスを言う。図５を参照し、図５は、データパケットの取引操作中に形成された信頼性ツリーの概略図である。本実施例において、ノードの階層の確認方法は、まずは、ルートノードを確認し、データパケットを初めて操作する実行端末ノードをルートノードとし、次には、サブノードを確認し、確認方法としては、ルートノードを第１階層のノードとし、ルートノードの次の階層のノードを第２階層のノードとするのであり、図５を参照すると、初期データパケットの実行端末ノードがルートノードである。この実施例において、初期データパケットを、データパケット０とデータパケット１とに分割し、第２階層のノードには、この２つのグループ化データパケットをそれぞれ操作する２つの実行端末ノードがあり、同様に、第２階層のノードの次の階層のノードを第３階層のノードとし、第３階層のノードでは、データパケット０をさらにデータパケット０１、データパケット０２、データパケット０３の３つのデータパケットに分割し、データパケット１をさらにデータパケット１１及びデータパケット１２の２つのデータパケットに分割し、即ち、対応して図５の第３階層のノードは５つあり、データパケットが経由した全ての実行端末ノードを記録するまで、このように分割し続ける。

【0042】

信頼性ツリー暗号化ステップでは、信頼性ツリーにおける各取引操作を暗号化し、本願では、具体的な暗号化方法については特に限定しない。

【0043】

信頼性ツリー検証ステップでは、各実行端末ノードの取引操作を検証して、悪意のある操作があるか否かを判断する。

【0044】

信頼性ツリー保存ステップでは、悪意のある操作がある場合、悪意のある操作に対応する実行端末ノードを記録し、当該実行端末ノードの操作が信頼できないことを示し、後続で、統合署名の検証に失敗することがある場合、この悪意のあるノードが検証に失敗した可能性が多く、各実行端末ノードの暗号化及び検証プロセスを記録し、プリセットの時間に従って信頼性ツリーを段階的に保存し、例えば、信頼性ツリーをデータパケットの取引が完了した後に保存したり、データパケットの取引プロセス中で段階的に保存したりすることができ、データパケットの取引の煩雑さに応じて予め設定することができる。

【0045】

本願は、信頼性ツリーを生成する上記の実施例に基づいて、信頼性ツリーに従ってデジタル署名に対して統合署名を行うこともできる。なお、統合署名は、１つのユーザ、即ち１つの実行端末ノードの複数のデジタル署名に対して統合署名を行ってもよいし、複数のユーザ、即ち複数の実行端末ノードの複数のデジタル署名に対して統合署名を行ってもよく、信頼性ツリー保存ステップにおいて、悪意のある操作に対応する実行端末ノードの記録を済み、信頼性ツリーを基に統合署名を構築し、一たび統合署名の検証に失敗すると、最初に検索すべきものは悪意のある操作記録がある実行端末ノードであり、こうすると、１つずつ調査して排除、追跡する作業を省き、効率が大幅向上し、信頼性ツリーを介しても、データパケット全体の処理プロセスを明瞭に示すことができる。

【0046】

信頼性ツリーにデータパケット全体の取引プロセスを記載した後、検証ノードは、さらに、データパケット保存ステップを行うように構成される。

【0047】

データパケット保存ステップでは、データパケットが信頼できる場合、即ち統合署名に対する検証ノードの検証結果がパスである場合、このデータパケットを検証ノードに保存し、このときのデータパケットは信頼できるものであるデータパケットであり、保存したデータパケットには、デジタル署名及び統合署名の操作が含まれ、具体的には、データパケット保存ステップは、
信頼できるデータパケットを分割して、複数のグループ化データパケットを得るデータパケット分割ステップと、
各グループ化データパケットを暗号化するグループ化データ暗号化ステップと、
後で使用するために各暗号化されたグループ化データパケットを検証ノードに保存する暗号化データパケット保存ステップと、を含む。

【0048】

上記の技術的解決手段から分かるように、本願に係るデジタル資産データパケットの信頼性検証システムは、デジタル資産データパケットの操作を実行する異なるメインチェーン又はサブチェーン上の複数のノードを含む複数の実行端末ノードと、統合機能に対応する役割が予め付与された複数の統合ノードと、検証機能に対応する役割が予め付与された複数の検証ノードと、を含み、まずは検証ノードが実行端末ノードにデジタル資産データパケットに対する信頼性検証要求を送信し、実行端末ノードが検証要求を受信し、実行端末ノードのそれぞれの秘密鍵でデータパケットにデジタル署名を行い、検証ノードがデジタル署名を検証し、各デジタル署名が検証をパスした場合、統合ノードがトリガされてデジタル署名を統合し、統合ノードがデジタル署名に対して統合操作を行って統合署名を生成し、検証ノードが統合署名の結果を検証し、検証をパスした場合は、前記データパケットは信頼できるものである。統合署名は、毎回、全てのデジタル署名を検証する必要がなく、検証を１回のみパスすればよいため、署名検証のコストを大幅低減させ、また、複数の署名を１つの署名に統合するため、実行端末ノードの保存スペースに対する占有を大幅節約することができ、リソース消費が少なく、且つ効率の高いデジタル資産データパケットの信頼性検証システムを提供する。同時に、実行端末ノードは、さらに、信頼性ツリー生成ステップを行うように構成され、一たび統合署名の検証に失敗すると、最初に検索すべきものは悪意のある操作記録がある実行端末ノードであり、こうすると、１つずつ調査して排除、追跡する作業を省き、効率が大幅向上し、信頼性ツリーを介しても、データパケット全体の処理プロセスを明瞭に示すことができる。

【図1】

【図2】

【図3】

【図4】

【図5】

【手続補正書】

【提出日】2021-01-18

【手続補正1】

【補正対象書類名】特許請求の範囲

【補正対象項目名】全文

【補正方法】変更

【補正の内容】

【特許請求の範囲】

【請求項1】

デジタル資産データパケットの信頼性検証システムであって、
前記デジタル資産データパケットの操作を実行する異なるメインチェーン又はサブチェーン上の複数のノードを含む複数の実行端末ノードと、統合機能に対応する役割が予め付与された複数の統合ノードと、検証機能に対応する役割が予め付与された複数の検証ノードと、を含み、
前記検証ノードは、
前記実行端末ノードにデジタル資産データパケットに対する信頼性検証要求を送信する検証要求ステップを行うように構成され、
前記実行端末ノードは、
前記検証ノードから送信された検証要求を受信する検証受信ステップと、
前記実行端末ノードのそれぞれの秘密鍵で、前記データパケットに少なくとも１つのデジタル署名を行うデジタル署名ステップと、を行うように構成され、
前記検証ノードは、さらに、
前記デジタル署名を検証するデジタル署名検証ステップと、
各前記デジタル署名が検証をパスした場合、前記統合ノードがトリガされて前記デジタル署名を統合する統合トリガステップと、を行うように構成され、
前記統合ノードは、
前記デジタル署名に対して統合操作を行って統合署名を生成する統合署名生成ステップを行うように構成され、
前記統合ノードは、さらに、
前記統合ノードが初めて前記デジタル署名を統合するとき、前記全てのデジタル署名を検証する初回検証ステップと、
前記デジタル署名が全ての検証をパスした場合、初回の統合署名結果を検証し、前記統合署名結果の検証方法は、前記検証ノードにより予め決定される統合結果検証ステップと、を行うように構成され、
前記検証ノードは、さらに、
前記統合署名を検証し、検証をパスした場合、前記データパケットは信頼できるものである統合署名検証ステップを行うように構成される、
ことを特徴とするデジタル資産データパケットの信頼性検証システム。

【請求項2】

前記実行端末ノードは、さらに、
検証ノードが信頼できるノードであるか否かを判断し、前記検証ノードが信頼できる場合、前記信頼性検証要求を受信し、前記検証ノードが信頼できない場合、前記信頼性検証要求を拒否するノード信頼性判断ステップを行うように構成される、
ことを特徴とする請求項１に記載のデジタル資産データパケットの信頼性検証システム。

【請求項3】

前記実行端末ノードは、さらに、
前記データパケットに対する前記実行端末ノードの取引操作プロセスに基づいて、ノードの階層に従って前記データパケットの処理プロセス信頼性ツリーを生成する信頼性ツリー生成ステップと、
前記信頼性ツリーにおける各取引操作を暗号化する信頼性ツリー暗号化ステップと、
前記各取引操作を検証し、悪意のある操作があるか否かを判断する信頼性ツリー検証ステップと、
悪意のある操作がある場合う、前記悪意のある操作に対応する実行端末ノードを記録し、プリセットの時間に従って前記信頼性ツリーを段階的に保存する信頼性ツリー保存ステップと、を行うように構成される、
ことを特徴とする請求項１に記載のデジタル資産データパケットの信頼性検証システム。

【請求項4】

前記統合署名は、前記信頼性ツリーに従って前記デジタル署名に対して統合署名を行う、
ことを特徴とする請求項３に記載のデジタル資産データパケットの信頼性検証システム。

【請求項5】

前記ノードの階層の確認ステップは、
前記データパケットを初めて操作する実行端末ノードをルートノードとするルートノード確認ステップと、
前記ルートノードを第１階層のノードとして、前記ルートノードの次の階層のノードを第２階層のノードとし、前記第２階層のノードの次の階層のノードを第３階層のノードとし、前記データパケットが経由する全てのノードの記録が完了するまで行うサブノード確認ステップと、を含む、
ことを特徴とする請求項３に記載のデジタル資産データパケットの信頼性検証システム。

【請求項6】

前記デジタル署名ステップは、
前記データパケットのオリジナルデータに対して、ハッシュ計算によりデジタルダイジェストを生成するダイジェスト生成ステップと、
前記データパケットが所在するノードの秘密鍵で前記デジタルダイジェストを暗号化してデジタル署名を得るダイジェスト暗号化ステップと、
前記デジタル署名と前記データパケットのオリジナルデータとを共に前記検証ノードに送信するデジタル署名送信ステップと、を含む、
ことを特徴とする請求項１に記載のデジタル資産データパケットの信頼性検証システム。

【請求項7】

前記デジタル署名の検証方式は、
前記検証ノードと前記実行端末ノードとの間の事前ネゴシエーションによって決定されることができる、
ことを特徴とする請求項１に記載のデジタル資産データパケットの信頼性検証システム。

【請求項8】

前記数個の検証ノードは、信頼できるノードを少なくとも１つ含む、
ことを特徴とする請求項１に記載のデジタル資産データパケットの信頼性検証システム。

【請求項9】

前記検証ノードは、さらに、
前記データパケットが信頼できる場合、前記検証ノードに前記データパケットを保存するデータパケット保存ステップを行うように構成され、
前記データパケット保存ステップは、
前記信頼できるデータパケットを分割して、複数のグループ化データパケットを得るデータパケット分割ステップと、
各前記グループ化データパケットを暗号化するグループ化データパケット暗号化ステップと、
各前記暗号化されたグループ化データパケットを前記検証ノードに保存する暗号化データパケット保存ステップと、を含む、
ことを特徴とする請求項１に記載のデジタル資産データパケットの信頼性検証システム。