特許 7195684 ブロックチェーンシステムのデータ管理方法、装置、コンピュータプログラム、及び電子機器

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

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

(11)【特許番号】

(24)【登録日】2022-12-16

(45)【発行日】2022-12-26

(54)【発明の名称】ブロックチェーンシステムのデータ管理方法、装置、コンピュータプログラム、及び電子機器

(51)【国際特許分類】

   H04L 9/32 20060101AFI20221219BHJP

   G09C 1/00 20060101ALI20221219BHJP

   G06F 21/64 20130101ALI20221219BHJP

【ＦＩ】

H04L9/32 200B

G09C1/00 640D

G06F21/64

【請求項の数】 14

(21)【出願番号】P 2021510879

(86)(22)【出願日】2019-11-26

(65)【公表番号】

(43)【公表日】2021-12-16

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

(87)【国際公開番号】W WO2020114278

(87)【国際公開日】2020-06-11

【審査請求日】2021-02-26

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

(32)【優先日】2018-12-07

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

(73)【特許権者】

【識別番号】517392436

【氏名又は名称】▲騰▼▲訊▼科技（深▲セン▼）有限公司

(74)【代理人】

【識別番号】100110364

【弁理士】

【氏名又は名称】実広 信哉

(74)【代理人】

【識別番号】100150197

【弁理士】

【氏名又は名称】松尾 直樹

(72)【発明者】

【氏名】李 茂材

(72)【発明者】

【氏名】王 宗友

(72)【発明者】

【氏名】孔 利

(72)【発明者】

【氏名】周 ▲開▼班

(72)【発明者】

【氏名】▲藍▼ ▲虎▼

(72)【発明者】

【氏名】▲時▼ 一防

(72)【発明者】

【氏名】▲楊▼ 常青

(72)【発明者】

【氏名】▲張▼ ▲勁▼松

(72)【発明者】

【氏名】丁 勇

(72)【発明者】

【氏名】朱 耿良

(72)【発明者】

【氏名】▲劉▼ 区城

(72)【発明者】

【氏名】▲陳▼ 秋平

【審査官】行田 悦資

(56)【参考文献】

【文献】特開２００３－０２２００７（ＪＰ，Ａ）

【文献】特開２００５－２１７６７９（ＪＰ，Ａ）

【文献】特開平１０－１３５９４５（ＪＰ，Ａ）

【文献】米国特許出願公開第２０１８／０２８５７６７（ＵＳ，Ａ１）

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

Ｈ０４Ｌ ９／３２

Ｇ０９Ｃ １／００

Ｇ０６Ｆ ２１／６４

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

【請求項1】

記帳ノードサブネットワークと、サービスノードサブネットワークとが含まれるブロックチェーンシステムのデータ管理方法であって、前記記帳ノードサブネットワークには、少なくとも１つのデータブロックをブロックチェーンに記録するよう構成された記帳ノードが含まれ、前記サービスノードサブネットワークには、前記ブロックチェーンに記録された前記少なくとも１つのデータブロックを検証するよう構成されたサービスノードが含まれ、前記少なくとも１つのデータブロックは各々が前記ブロックチェーンへの追加対象の取引データをパッケージ化して生成され、
前記データ管理方法は、
前記記帳ノードサブネットワークにおける記帳ノードが第１データブロックを生成した後、前記第１データブロックのブロックヘッダに、前記第１データブロックの後に生成される第２データブロックのブロックヘッダを検証するための第１鍵情報を追加するステップと、
前記第１データブロックに対応する署名を生成し、前記第１データブロックに対応する署名を前記第１データブロックのブロックヘッダに追加するステップと、
前記第１データブロックのブロックヘッダを前記サービスノードサブネットワークに配布することにより、前記サービスノードサブネットワークにおけるサービスノードが、前記第１データブロックのブロックヘッダに含まれる署名を検証し、検証に合格した場合、前記第１鍵情報を取得して前記第２データブロックのブロックヘッダを検証するようにするステップと、
を含み、
前記第１データブロックのブロックヘッダに、前記第１データブロックの後に生成される第２データブロックのブロックヘッダを検証するための第１鍵情報を追加する前に、
認証センターから、前記第２データブロックに対応する証明書を取得し、取得した前記証明書を前記第１鍵情報とするステップ、及び／又は、
認証センターから、前記第２データブロックに対応する公開鍵及び秘密鍵を取得し、取得した前記公開鍵を前記第１鍵情報とするステップをさらに含む、
ブロックチェーンシステムのデータ管理方法。

【請求項2】

前記第１データブロックのブロックヘッダに、前記第１データブロックの後に生成される第２データブロックのブロックヘッダを検証するための第１鍵情報を追加する前記ステップは、
前記第１データブロックのブロックヘッダに含まれる指定のフィールドに前記第１鍵情報を追加することにより、前記第２データブロックのブロックヘッダを前記第１鍵情報で検証するよう指示するステップを含む、
請求項１に記載のブロックチェーンシステムのデータ管理方法。

【請求項3】

前記第１鍵情報と、前記第１データブロックのブロックヘッダを検証するための鍵情報とが同じである場合、前記指定のフィールドにヌルを設定するステップをさらに含む、
請求項２に記載のブロックチェーンシステムのデータ管理方法。

【請求項4】

前記第１データブロックに対応する署名を生成することは、
前記第１データブロックに対応する署名鍵を取得するステップと、
前記第１データブロックに対応する署名鍵で、前記第１データブロックに含まれるデータに対して署名アルゴリズムを実施することにより、前記第１データブロックに対応する署名を生成するステップと、を含む、
請求項１に記載のブロックチェーンシステムのデータ管理方法。

【請求項5】

前記第１データブロックのブロックヘッダを前記サービスノードサブネットワークに配布した後、
前記記帳ノードサブネットワークにおける記帳ノードが前記第２データブロックを生成した場合、前記第１鍵情報に対応する署名鍵と、前記第２データブロックとに基づいて、前記第２データブロックに対応する署名を生成するステップと、
前記第２データブロックに対応する署名を前記第２データブロックのブロックヘッダに追加し、前記第２データブロックのブロックヘッダを前記サービスノードサブネットワークに配布するステップと、をさらに含む、
請求項１に記載のブロックチェーンシステムのデータ管理方法。

【請求項6】

前記記帳ノードが前記サービスノードサブネットワークにおけるターゲットサービスノードからの、指定のデータブロックに含まれる取引データの取得要求を受信すると、前記ターゲットサービスノードの権限情報を取得するステップと、
前記記帳ノードが前記ターゲットサービスノードの権限情報に基づいて、前記指定のデータブロックに含まれる、前記ターゲットサービスノードに取得権限がある取引データを、前記ターゲットサービスノードに返信するステップと、をさらに含む、
請求項１～５の何れか１項に記載のブロックチェーンシステムのデータ管理方法。

【請求項7】

記帳ノードサブネットワークと、サービスノードサブネットワークとが含まれるブロックチェーンシステムのデータ管理方法であって、前記記帳ノードサブネットワークには、少なくとも１つのデータブロックをブロックチェーンに記録するよう構成された記帳ノードが含まれ、前記サービスノードサブネットワークには、前記ブロックチェーンに記録された前記少なくとも１つのデータブロックを検証するよう構成されたサービスノードが含まれ、前記少なくとも１つのデータブロックは各々が前記ブロックチェーンへの追加対象の取引データをパッケージ化して生成され、前記データ管理方法は、前記サービスノードサブネットワークにおけるサービスノードによって実行され、
前記記帳ノードサブネットワークからの第１データブロックのブロックヘッダを受信するステップであって、前記第１データブロックのブロックヘッダには、署名と、前記第１データブロックの後に生成される第２データブロックのブロックヘッダを検証するための第１鍵情報とが含まれ、前記第１鍵情報は、前記記帳ノードサブネットワークが、認証センターから、前記第２データブロックに対応する証明書を取得し、取得した前記証明書を前記第１鍵情報とし、及び／又は、認証センターから、前記第２データブロックに対応する公開鍵及び秘密鍵を取得し、取得した前記公開鍵を前記第１鍵情報としたものである、ステップと、
前記第１データブロックのブロックヘッダに含まれる署名を検証するステップと、
前記第１データブロックのブロックヘッダに含まれる署名の検証に合格した場合、前記第１鍵情報を取得し、受信される前記第２データブロックのブロックヘッダを前記第１鍵情報で検証するステップと、
を含むブロックチェーンシステムのデータ管理方法。

【請求項8】

前記第１データブロックのブロックヘッダに含まれる署名を検証するステップは、
前記記帳ノードサブネットワークからの第３データブロックのブロックヘッダを受信するステップであって、前記第３データブロックが、前記第１データブロックの前に生成されたものである、ステップと、
前記第３データブロックのブロックヘッダから、前記第１データブロックのブロックヘッダを検証するための第２鍵情報を取得するステップと、
前記第１データブロックのブロックヘッダに含まれる署名を前記第２鍵情報で検証するステップと、を含む、
請求項７に記載のブロックチェーンシステムのデータ管理方法。

【請求項9】

前記第１データブロックがジェネシスブロックである場合、前記第１データブロックに含まれる署名を所定の鍵情報で検証するステップをさらに含む、
請求項８に記載のブロックチェーンシステムのデータ管理方法。

【請求項10】

前記少なくとも１つのデータブロックの各々は取引データから生成され、前記記帳ノードサブネットワークから配布された前記ブロックヘッダに基づいて、前記記帳ノードサブネットワークにおけるターゲット記帳ノードに、指定のデータブロックに含まれる取引データの取得要求を送信するステップと、
前記ターゲット記帳ノードが前記取得要求に応じて返信した、前記指定のデータブロックに含まれる、ターゲットサービスノードに取得権限がある取引データを受信するステップと、をさらに含む、
請求項７～９の何れか１項に記載のブロックチェーンシステムのデータ管理方法。

【請求項11】

ブロックチェーンシステムのデータ管理装置であって、前記ブロックチェーンシステムには、記帳ノードサブネットワークと、サービスノードサブネットワークとが含まれ、前記記帳ノードサブネットワークには、少なくとも１つのデータブロックをブロックチェーンに記録するよう構成された記帳ノードが含まれ、前記サービスノードサブネットワークには、前記ブロックチェーンに記録された前記少なくとも１つのデータブロックを検証するよう構成されたサービスノードが含まれ、前記少なくとも１つのデータブロックは各々が前記ブロックチェーンへの追加対象の取引データをパッケージ化して生成され、前記データ管理装置は、
前記記帳ノードサブネットワークにおける記帳ノードが第１データブロックを生成した後、前記第１データブロックのブロックヘッダに、前記第１データブロックの後に生成される第２データブロックのブロックヘッダを検証するための第１鍵情報を追加する追加ユニットであって、認証センターから、前記第２データブロックに対応する証明書を取得し、取得した前記証明書を前記第１鍵情報とし、及び／又は、認証センターから、前記第２データブロックに対応する公開鍵及び秘密鍵を取得し、取得した前記公開鍵を前記第１鍵情報とする、追加ユニットと、
前記第１データブロックに対応する署名を生成し、前記第１データブロックに対応する署名を前記第１データブロックのブロックヘッダに追加する生成ユニットと、
前記第１データブロックのブロックヘッダを前記サービスノードサブネットワークに配布することにより、前記サービスノードサブネットワークにおけるサービスノードが、前記第１データブロックのブロックヘッダを検証し、検証に合格した場合、前記第１鍵情報を取得して前記第２データブロックのブロックヘッダを検証するようにする送信ユニットと、
を含むブロックチェーンシステムのデータ管理装置。

【請求項12】

ブロックチェーンシステムのデータ管理装置であって、前記ブロックチェーンシステムには、記帳ノードサブネットワークと、サービスノードサブネットワークとが含まれ、前記記帳ノードサブネットワークには、少なくとも１つのデータブロックをブロックチェーンに記録するよう構成された記帳ノードが含まれ、前記サービスノードサブネットワークには、前記ブロックチェーンに記録された前記少なくとも１つのデータブロックを検証するよう構成されたサービスノードが含まれ、前記少なくとも１つのデータブロックは各々が前記ブロックチェーンへの追加対象の取引データをパッケージ化して生成され、前記サービスノードには、前記データ管理装置が含まれ、前記データ管理装置は、
前記記帳ノードサブネットワークからの第１データブロックのブロックヘッダを受信し、前記第１データブロックのブロックヘッダには、署名と、前記第１データブロックの後に生成される第２データブロックのブロックヘッダを検証するための第１鍵情報とが含まれ、前記第１鍵情報は、前記記帳ノードサブネットワークが、認証センターから、前記第２データブロックに対応する証明書を取得し、取得した前記証明書を前記第１鍵情報とし、及び／又は、認証センターから、前記第２データブロックに対応する公開鍵及び秘密鍵を取得し、取得した前記公開鍵を前記第１鍵情報としたものである、受信ユニットと、
前記第１データブロックのブロックヘッダに含まれる署名を検証する検証ユニットと、
前記第１データブロックのブロックヘッダに含まれる署名の検証に合格した場合、前記第１鍵情報を取得し、受信される前記第２データブロックのブロックヘッダを前記第１鍵情報で検証する取得ユニットと、
を含むブロックチェーンシステムのデータ管理装置。

【請求項13】

請求項７～１０の何れか１項に記載のブロックチェーンシステムのデータ管理方法をデータ管理装置に実現させるコンピュータプログラム。

【請求項14】

電子機器であって、
１つ又は複数のプロセッサと、記憶装置と、を備え、
前記記憶装置には、１つ又は複数のプログラムが記憶され、前記１つ又は複数のプログラムは、前記１つ又は複数のプロセッサによって実行されると、前記１つ又は複数のプロセッサに、請求項７～１０の何れか１項に記載のブロックチェーンシステムのデータ管理方法を実現させる電子機器。

【発明の詳細な説明】

【技術分野】

【0001】

本願は、２０１８年１２月７日に中国特許庁に提出された、出願番号が２０１８１１４９７４５３．４であり、発明の名称が「ブロックチェーンシステムのデータ管理方法、装置、媒体、及び電子機器」である中国特許出願に基づく優先権を主張し、その全ての内容は参照することにより本願に組み込まれる。

【0002】

本願は、コンピュータ及び通信の技術分野に関し、具体的にブロックチェーンシステムのデータ管理方法、装置、媒体、及び電子機器に関する。

【背景技術】

【0003】

ブロックチェーンネットワークは、多数のノードが共同で構成するエンドツーエンドの脱中心化ネットワークである。各ノードは、データベースの完全なコピーを取得することが許可される。つまり、ノード間で各情報が完全に共有され、各ノードは、コンセンサスメカニズムに基づいて、ブロックチェーン全体を共同で維持する。いわゆるコンセンサスメカニズムとは、特別なノードによる投票を通じて、取引の検証及び確認を短期間で完了することである。１つの取引について、利益に関係のない若干のノード間でコンセンサスを達成できる場合、ネットワーク全体でもコンセンサスを達成できると見なすことができる。

【発明の概要】

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

【0004】

ブロックチェーンシステムの１つの適用シナリオでは、ブロックチェーンネットワークにおけるデータをブロックチェーンネットワーク外のサービスノードに送信する必要がある場合がある。このような適用シナリオでは、サービスノードによるデータチェックを便利にするために、サービスノードに送信するデータに署名する必要がある。署名鍵の漏洩により、データが安全ではなくなることを如何に回避するかが、解決すべき技術的問題となっている。

【0005】

本願の実施例では、ブロックチェーンシステムのデータ管理方法、装置、媒体、及び電子機器が提供されているため、少なくとも一定の程度で、ブロックヘッダ検証鍵を柔軟に更新して、ブロックヘッダのデータの安全性を確保することができる。
本願のその他の特徴及び利点は、以下の詳細な説明により明らかになり、又は、部分的に本願の実施により把握される。

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

【0006】

本願の実施例によれば、記帳ノードサブネットワークと、サービスノードサブネットワークとが含まれるブロックチェーンシステムのデータ管理方法が提供されている。前記記帳ノードサブネットワークには、記帳ノードが含まれ、前記サービスノードサブネットワークには、サービスノードが含まれ、前記データ管理方法は、前記記帳ノードサブネットワークにおける記帳ノードが第１データブロックを生成した後、前記第１データブロックのブロックヘッダに、前記第１データブロックの後に生成される第２データブロックのブロックヘッダを検証するための第１鍵情報を追加するステップと、前記第１データブロックに対応する署名を生成し、前記第１データブロックに対応する署名を前記第１データブロックのブロックヘッダに追加するステップと、前記第１データブロックのブロックヘッダを前記サービスノードサブネットワークに配布することにより、前記サービスノードサブネットワークにおけるサービスノードが、前記第１データブロックのブロックヘッダに含まれる署名を検証し、検証に合格した場合、前記第１鍵情報を取得して前記第２データブロックのブロックヘッダを検証するステップと、を含む。

【0007】

本願の実施例によれば、記帳ノードサブネットワークと、サービスノードサブネットワークとが含まれるブロックチェーンシステムのデータ管理方法が提供されている。前記記帳ノードサブネットワークには、記帳ノードが含まれ、前記サービスノードサブネットワークには、サービスノードが含まれ、前記データ管理方法は、前記サービスノードサブネットワークにおけるサービスノードによって実行され、前記記帳ノードサブネットワークからの第１データブロックのブロックヘッダを受信するステップであって、前記第１データブロックのブロックヘッダには、署名と、前記第１データブロックの後に生成される第２データブロックのブロックヘッダを検証するための第１鍵情報とが含まれる、ステップと、前記第１データブロックのブロックヘッダに含まれる署名を検証するステップと、前記第１データブロックのブロックヘッダに含まれる署名の検証に合格した場合、前記第１鍵情報を取得し、受信される前記第２データブロックのブロックヘッダを前記第１鍵情報で検証するステップと、を含む。

【0008】

本願の実施例によれば、記帳ノードサブネットワークと、サービスノードサブネットワークとが含まれるブロックチェーンシステムのデータ管理装置が提供されている。前記記帳ノードサブネットワークには、記帳ノードが含まれ、前記サービスノードサブネットワークには、サービスノードが含まれ、前記データ管理装置は、前記記帳ノードサブネットワークにおける記帳ノードが第１データブロックを生成した後、前記第１データブロックのブロックヘッダに、前記第１データブロックの後に生成される第２データブロックのブロックヘッダを検証するための第１鍵情報を追加する追加ユニットと、前記第１データブロックに対応する署名を生成し、前記第１データブロックに対応する署名を前記第１データブロックのブロックヘッダに追加する生成ユニットと、前記第１データブロックのブロックヘッダを前記サービスノードサブネットワークに配布することにより、前記サービスノードサブネットワークにおけるサービスノードが、前記第１データブロックのブロックヘッダに含まれる署名を検証し、検証に合格した場合、前記第１鍵情報を取得して前記第２データブロックのブロックヘッダを検証する送信ユニットと、を含む。

【0009】

本願の実施例によれば、記帳ノードサブネットワークと、サービスノードサブネットワークとが含まれるブロックチェーンシステムのデータ管理装置が提供されている。前記記帳ノードサブネットワークには、記帳ノードが含まれ、前記サービスノードサブネットワークには、サービスノードが含まれ、前記サービスノードには、前記データ管理装置が含まれ、前記データ管理装置は、前記記帳ノードサブネットワークからの第１データブロックのブロックヘッダを受信し、前記第１データブロックのブロックヘッダには、署名と、前記第１データブロックの後に生成される第２データブロックのブロックヘッダを検証するための第１鍵情報とが含まれる受信ユニットと、前記第１データブロックのブロックヘッダに含まれる署名を検証する検証ユニットと、前記第１データブロックのブロックヘッダに含まれる署名の検証に合格した場合、前記第１鍵情報を取得し、受信される前記第２データブロックのブロックヘッダを前記第１鍵情報で検証する取得ユニットと、を含む。

【0010】

本願の実施例によれば、コンピュータプログラムを記憶したコンピュータ可読媒体が提供されており、前記コンピュータプログラムは、プロセッサによって実行されると、上記の実施例に記載のブロックチェーンシステムのデータ管理方法を実現させる。

【0011】

本願の実施例によれば、電子機器が提供されており、前記電子機器は、１つ又は複数のプロセッサと、記憶装置と、を備え、前記記憶装置には、１つ又は複数のプログラムが記憶され、前記１つ又は複数のプログラムは、前記１つ又は複数のプロセッサによって実行されると、前記１つ又は複数のプロセッサに、上記の実施例に記載のブロックチェーンシステムのデータ管理方法を実現させる。

【発明の効果】

【0012】

本願のいくつかの実施例で提供された構成では、第１データブロックのブロックヘッダに、第１データブロックの後に生成される第２データブロックのブロックヘッダを検証するための第１鍵情報を追加し、第１データブロックに対応する署名を第１データブロックのブロックヘッダに追加した後、第１データブロックのブロックヘッダをサービスノードサブネットワークに配布することにより、サービスノードサブネットワークにおけるサービスノードが、第１データブロックのブロックヘッダに含まれる署名を検証した後、第１データブロックのブロックヘッダから、第２データブロックのブロックヘッダを検証するための第１鍵情報を取得することができ、つまり、前のデータブロックのブロックヘッダによって、次のデータブロックのブロックヘッダを検証するために使用される鍵情報を指示することができ、ブロックヘッダ検証鍵を柔軟に更新するという目的が達成され、鍵交換が柔軟ではないことによる不便が回避され、固定鍵の使用によりデータが安全ではない恐れがあるという問題も回避される。また、本願の実施例の構成では、前のデータブロックのブロックヘッダの検証に合格した場合にのみ、次のデータブロックのブロックヘッダを検証するために使用される鍵情報を取得することができるので、ブロックヘッダのデータの安全性も効果的に確保することができる。

【0013】

理解すべきものとして、上記の一般的な説明及び以下の詳細な説明は、例示的で解釈的なものにすぎず、本願を制限するものではない。

【0014】

ここでの図面は、明細書に組み込まれて、本明細書の一部を構成し、本願に適合する実施例を示し、明細書とともに本願の原理を解釈するために使用される。明らかに、以下の説明における図面は本願のいくつかの実施例を示しているにすぎず、当業者にとって、創造的な労働をせずに、これらの図面から他の図面を得ることもできる。

【図面の簡単な説明】

【0015】

【図1】本願の実施例が適用されるブロックチェーンシステムのシステムアーキテクチャの模式図を示す。

【図2】本願の実施例が適用されるブロックチェーンシステムのシステムアーキテクチャの模式図を示す。

【図3】本願の実施例が適用されるブロックチェーンシステムのシステムアーキテクチャの模式図を示す。

【図4】本願の一実施例によるブロックチェーンシステムのデータ管理方法のフローチャートを模式的に示す。

【図5】本願の一実施例によるデータブロックのコンセンサスのフローチャートを模式的に示す。

【図6】本願の一実施例による第１データブロックに対応する署名を生成することのフローチャートを模式的に示す。

【図7】本願の一実施例によるデータブロックのブロックヘッダの構造の模式図を示す。

【図8】本願の一実施例による第１データブロックのブロックヘッダをサービスノードサブネットワークに配布することのフローチャートを模式的に示す。

【図9】本願の一実施例による第１データブロックのブロックヘッダをサービスノードサブネットワークに配布することのフローチャートを模式的に示す。

【図10】本願の一実施例による第１データブロックのブロックヘッダを、送信ノードから最も近いサービスノードに送信することのフローチャートを模式的に示す。

【図11】本願の一実施例によるブロックチェーンシステムのデータ管理方法のフローチャートを模式的に示す。

【図12】本願の一実施例によるブロックチェーンシステムのデータ管理方法のフローチャートを模式的に示す。

【図13】本願の一実施例によるブロックチェーンシステムのデータ管理方法のフローチャートを模式的に示す。

【図14】本願の一実施例によるブロックチェーンシステムのデータ管理方法のフローチャートを模式的に示す。

【図15】本願の一実施例によるブロックチェーンシステムのデータ管理装置のブロック図を模式的に示す。

【図16】本願の一実施例によるブロックチェーンシステムのデータ管理装置のブロック図を模式的に示す。

【図17】本願の実施例を実現することに好適な電子機器のコンピュータシステムの構成の模式図を示す。

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

【0016】

図面を参照して、例示的な実施形態をより完全に説明する。しかしながら、例示的な実施形態は、様々な形式で実施されることができ、ここで説明される模範例に限定されるものとして理解されるべきではない。逆に、これらの実施形態を提供することにより、本願がより全面的かつ完全になり、例示的な実施形態の構想が全面的に当業者に伝えられる。

【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】

本願の一実施例では、図６に示すように、ステップＳ４２０において第１データブロックに対応する署名を生成することは、以下のステップを含む。

【0049】

ステップＳ６１０で、前記第１データブロックに対応する署名鍵を取得する。
本願の一実施例では、第１データブロックがジェネシスブロックである場合、第１データブロックに対応する署名鍵は、所定の鍵情報であってもよいが、第１データブロックがジェネシスブロックではない場合、第１データブロックに対応する署名鍵は、前のデータブロックにより指示された鍵情報に対応する必要がある。ここで、ブロックチェーンにおいて最初に構築されるブロックは、ジェネシスブロックと呼ばれる。具体的には、図７に示すように、データブロック１のブロックヘッダにより、データブロック２のブロックヘッダの検証に公開鍵Ａを使用することが指示され、データブロック２のブロックヘッダにより、データブロック３のブロックヘッダの検証に公開鍵Ｂを使用することが指示され、データブロック３のブロックヘッダにより、データブロック４のブロックヘッダの検証に公開鍵Ｃを使用することが指示される。この場合、データブロック２に対応する署名鍵が、公開鍵Ａに対応する秘密鍵Ａであるため、秘密鍵Ａで署名し、同様に、データブロック３に対応する署名鍵が、公開鍵Ｂに対応する秘密鍵Ｂであるため、秘密鍵Ｂで署名する。

【0050】

ステップＳ６２０で、前記第１データブロックに対応する署名鍵で、前記第１データブロックに含まれるデータに対して署名アルゴリズムを実施することにより、第１データブロックに対応する署名を生成する。
本願の一実施例では、署名アルゴリズムは、メッセージダイジェストアルゴリズム、及びダイジェスト暗号化方法などであってもよい。

【0051】

引き続いて図４を参照すると、ステップＳ４３０で、前記第１データブロックのブロックヘッダを前記サービスノードサブネットワークに配布することにより、前記サービスノードサブネットワークにおけるサービスノードが、前記第１データブロックのブロックヘッダを検証し、検証に合格した場合、前記第１鍵情報を取得して前記第２データブロックのブロックヘッダを検証するようにする。

【0052】

本願の一実施例では、図８に示すように、ステップＳ４３０において第１データブロックのブロックヘッダをサービスノードサブネットワークに配布する過程は、以下のステップを含む。
ステップＳ８１０で、第１データブロックのブロックヘッダを前記サービスノードサブネットワークにおける指定のサービスノードに送信する。
ステップＳ８２０で、前記指定のサービスノードによって、前記第１データブロックのブロックヘッダを前記サービスノードサブネットワークにおける他のサービスノードにブロードキャストする。

【0053】

該実施例は、図２に示すブロックチェーンシステムのシステムアーキテクチャに適用される。該システムアーキテクチャでは、サービスノードサブネットワークにおける１つのサービスノードを代行ノードとして、ブロードキャスト方式で、サービスノードサブネットワークにおける全てのサービスノードにデータブロックのブロックヘッダを送信することができる。該実施例の利点は、ブロックヘッダをサービスノードサブネットワークにおける全てのサービスノードに迅速に通知できることにある。

【0054】

サービスノードサブネットワークは、図２に示すメッセージブロードキャストの通信方式以外に、図１及び図３に示すようなＰ２Ｐ型のネットワーク通信方式を採用してもよい。Ｐ２Ｐのサービスノードサブネットワークでは、代行ノードが、ブロックヘッダをその周囲のサービスノードに送信し、サービスノードサブネットワークにおける全てのサービスノードが該ブロックヘッダを受信するまで、該ブロックヘッダを受信したサービスノードが、ブロックヘッダを該サービスノードの周囲の他のサービスノードに送信してもよい。

【0055】

Ｐ２Ｐネットワーキング形式の一実施例では、図９に示すように、第１データブロックのブロックヘッダをサービスノードサブネットワークに配布する過程は、以下のステップを含む。
ステップＳ９１０で、第１データブロックのブロックヘッダを前記サービスノードサブネットワークにおける指定のサービスノードに送信する。
ステップＳ９２０で、前記指定のサービスノードを送信ノードとして、前記第１データブロックのブロックヘッダを、前記送信ノードから最も近いサービスノードに送信し、前記サービスノードサブネットワークにおけるサービスノードのいずれも前記第１データブロックのブロックヘッダを受信するまで、前記第１データブロックのブロックヘッダを受信したサービスノードを送信ノードとして、継続的に送信を行う。

【0056】

ステップＳ９２０において、ブロックヘッダを既に受信したサービスノードが同じブロックヘッダを繰り返して受信することは意味がないため、各サービスノードは、ブロックヘッダの送信先である次のサービスノードを決定する際に、自ノードから最も近いサービスノードへ優先して送信すること（伝送待機時間を短縮するために）に加えて、該ブロックヘッダを受信していないサービスノードに伝送すべきであることも考慮する必要がある。このように、各サービスノードそれぞれは、ブロックヘッダを１つのサービスノードに送信するだけでよく、この１つのサービスノードは、該ブロックヘッダを受信していない他のサービスノードのうち、自ノードから最も近いサービスノードである。このようにして、ノードからノードへのブロックヘッダの安全な配布が完了するとともに、１つのサービスノードへの配布負担の集中が回避され、負荷分散が実現される。

【0057】

本願の一実施例では、図１０に示すように、ステップＳ９２０において第１データブロックのブロックヘッダを、送信ノードから最も近いサービスノードに送信する過程は、以下のステップを含んでもよい。
ステップＳ１０１０で、前記サービスノードサブネットワークにおける前記送信ノード以外の他のサービスノードと前記送信ノードとの距離を決定する。
ステップＳ１０２０で、前記第１データブロックのブロックヘッダを、前記送信ノードから最も近いサービスノードに送信し、ここで、前記第１データブロックのブロックヘッダを受信したサービスノードが、以前に第１データブロックのブロックヘッダを既に受信した場合、前記送信ノードに拒否メッセージをフィードバックする。
ステップＳ１０３０で、前記拒否メッセージを受信すると、受け入れメッセージを受信するまで、前記距離の近い順に、前記第１データブロックのブロックヘッダを他のサービスノードに継続的に送信する。

【0058】

本願の一実施例では、ステップＳ１０１０において、前記サービスノードサブネットワークにおける前記送信ノード以外の他のサービスノードと前記送信ノードとの距離を決定することは、サービスノードサブネットワークにおける他のサービスノードからブロードキャストされた測位情報を周期的に（例えば、５秒毎に）受信し、最後に受信した、各他のサービスノードからブロードキャストされた測位情報と、送信ノードの測位情報とに基づいて、各他のサービスノードと前記送信ノードとの距離を算出することを含んでもよい。

【0059】

本願の一実施例では、測位情報は、各サービスノードが自ノードの測位システム（例えば、ノードに実装されたＧＰＳシステム）から取得したサービスノードの位置情報である。サービスノードは、自ノードに実装された測位システムから、自ノードの測位情報を取得して、サービスノードサブネットワークにおける他のサービスノードに周期的に（例えば、５秒毎に）ブロードキャストする。送信ノードも、自ノードの測位システムから、自ノードの測位情報を取得することができる。測位情報のブロードキャスト及び更新が周期的であり、周期が短いため、送信ノードが最後に受信した、各他のサービスノードからブロードキャストされた測位情報を、各他のサービスノードの現在の測位情報と見なすことができる。このように、最後に受信した、各他のサービスノードからブロードキャストされた測位情報と、送信ノードの測位情報とに基づいて、各他のサービスノードと前記送信ノードとの距離を算出することができる。

【0060】

算出された上記距離に基づいて、全ての他のサービスノードのうち、送信ノードとの距離が最も小さい他のサービスノードを見つけることができるが、該他のサービスノードは、該ブロックヘッダを既に受信した可能性がある。このため、本願の実施例では、ブロックヘッダを受信した他のサービスノードが受け入れメッセージ又は拒否メッセージを送信することにより、ブロックヘッダをあるサービスノードに繰り返して送信することが回避される。ここで、受け入れメッセージ又は拒否メッセージであるかの相違点は、受け入れメッセージ又は拒否メッセージを表すために、ある特定の識別フィールドには、異なる文字又は文字列が設定されることにある。このように、送信ノードは、受信したメッセージにおける該特定の識別フィールドを識別することにより、受信したメッセージが受け入れメッセージであるか、それとも拒否メッセージであるかを識別することができる。受け入れメッセージである場合は、該ブロックヘッダを受信したサービスノードが、以前に該ブロックヘッダを受信したことがないため、該ブロックヘッダを受け入れたことを表す。拒否メッセージである場合は、該ブロックヘッダを受信したサービスノードが、以前に該ブロックヘッダを受信したことがあるため、該ブロックヘッダを拒否したことを表す。送信ノードは、拒否メッセージを受信すると、自ノードから２番目に近い他のサービスノードを見つけて、該他のサービスノードにブロックヘッダを送信し、該他のサービスノードからフィードバックされたのが拒否メッセージであるか、それとも受け入れメッセージであるかを判断する必要があり、依然として拒否メッセージである場合、自ノードから３番目に近い他のサービスノードを見つけて、該他のサービスノードにブロックヘッダを送信し、該他のサービスノードからフィードバックされたのが拒否メッセージであるか、それとも受け入れメッセージであるかの判断を行う必要がある。つまり、拒否メッセージを受信すると、受け入れメッセージを受信するまで、送信ノードとの距離の近い順に、ブロックヘッダを他のサービスノードに継続的に送信する。

【0061】

該ブロックヘッダをまだ受信していない他のサービスノードのうち、送信ノードから最も近いサービスノードを見つけるための他の実施形態は、配信進捗記録サーバを維持することである。ある他のサービスノードは、ブロックヘッダを受信するたびに、配信進捗記録サーバに記録要求を送信し、記録要求には、該サービスノードの識別子と、ブロックヘッダの識別子（例えば、その中のマークルツリーのルート）とが含まれ、配信進捗記録サーバは、該サービスノードの識別子と、ブロックヘッダの識別子とを対応付けて記憶する。送信ノードは、該ブロックヘッダをまだ受信していない他のサービスノードのうち、送信ノードから最も近いサービスノードを決定しようとすると、まず、配信進捗記録サーバに要求を送信する。配信進捗記録サーバは、サービスノードサブネットワークにおける、該ブロックヘッダを受信していないサービスノードの識別子を検索して（全てのサービスノードの識別子リストから、ブロックヘッダの識別子と対応付けて記憶されたサービスノードの識別子を除去する）、送信ノードに送信する。送信ノードは、該ブロックヘッダを受信していないこれらのサービスノードの中から、送信ノードとの距離が最も小さいサービスノードを決定する。これに比べて、上記のように、距離が最も近い他のサービスノードにブロックヘッダを送信することにより、ブロックヘッダを受信した他のサービスノードが、自ノードが以前に該ブロックヘッダを受信したか否かに応じて、受け入れメッセージ又は拒否メッセージを送信するような方式では、設置されたサーバが１つ少なくなり、ネットワークのリソースが節約され、ネットワークの輻輳が回避される。

【0062】

前述の実施例の構成によれば、本願の一実施例では、図１１に示すように、本願の一実施例によるブロックチェーンシステムのデータ管理方法は、以下のステップを含む。

【0063】

ステップＳ１１１０で、記帳ノードサブネットワークにおける記帳ノードが前記第２データブロックを生成した場合、前記第１鍵情報に対応する署名鍵と、前記第２データブロックとに基づいて、前記第２データブロックに対応する署名を生成する。

【0064】

本願の一実施例では、第１鍵情報は、第２データブロックを検証するための鍵情報であり、第１鍵情報に対応する署名鍵は、第２データブロックに署名するための鍵である。具体的には、図７に示すように、データブロック２に対応する署名鍵は、公開鍵Ａに対応する秘密鍵Ａであり、データブロック３に対応する署名鍵は、公開鍵Ｂに対応する秘密鍵Ｂである。

【0065】

ここで、データブロックを生成する過程、及び、第２データブロックに対応する署名を生成する過程は、前述の実施例の構成を参照すればよいが、ここでは説明を省略する。

【0066】

ステップＳ１１２０で、前記第２データブロックに対応する署名を前記第２データブロックのブロックヘッダに追加し、前記第２データブロックのブロックヘッダを前記サービスノードサブネットワークに配布する。

【0067】

ここで、第２データブロックに対応する署名を第２データブロックのブロックヘッダに追加する過程、及び、第２データブロックのブロックヘッダをサービスノードサブネットワークに配布する過程は、前述の実施例の構成を参照すればよいが、ここでは説明を省略する。

【0068】

前述の実施例の構成によれば、本願の一実施例では、図１２に示すように、本願の一実施例によるブロックチェーンシステムのデータ管理方法は、以下のステップＳ１２１０及びステップＳ１２２０を含む。以下、詳しく説明する。

【0069】

ステップＳ１２１０で、前記サービスノードサブネットワークにおけるターゲットサービスノードからの、指定のデータブロックに含まれる取引データの取得要求を受信すると、前記ターゲットサービスノードの権限情報を取得する。

【0070】

本願の実施例では、サービスノードの権限情報とは、サービスノードには、データブロックにおけるどの取引データを取得する権限があるか、どの取引データを取得する権限がないかを示す情報である。本願の一実施例では、権限情報における権限は、
閲覧が許可される取引データに対応する、ブロックチェーンへの追加を要求したサービスノードと、
閲覧が許可される取引データに対応する取引タイプと、
閲覧が許可される取引データに対応する、ブロックチェーンへの追加期間とのうちの１つ又は複数を含む。

【0071】

ここで、閲覧が許可される取引データに対応する、ブロックチェーンへの追加を要求したサービスノードとは、どのサービスノードがブロックチェーンへの追加を要求した取引データの閲覧が許可されるかの権限である。本願の一実施例では、サービスノードが、自ノードがブロックチェーンへの追加を要求した取引データのみを閲覧できると規定してもよい。サービスノードＡがあるとすると、その権限情報には、閲覧が許可される取引データに対応する、ブロックチェーンへの追加を要求したサービスノードが、サービスノードＡ自身であると規定され得る。このように、サービスノードＡ自身がブロックチェーンへの追加を要求したデータブロックのみは、サービスノードＡによって閲覧されることが可能である。他の実施例では、サービスノードが、自ノード及びそれに所属する全ての機関のサービスノードがブロックチェーンへの追加を要求した取引データを閲覧できると規定してもよい。例えば、サービスノードＡがあり、それに所属する機関のサービスノードにＡ１～Ａ７がある。このように、サービスノードＡの、閲覧が許可される取引データに対応する、ブロックチェーンへの追加を要求したサービスノードは、サービスノードＡ及びサービスノードＡ１～Ａ７であるため、サービスノードＡ及びサービスノードＡ１～Ａ７の何れのサービスノードがブロックチェーンへの追加を要求したデータブロックも、サービスノードＡによって閲覧されることが可能である。

【0072】

閲覧が許可される取引データに対応する取引タイプとは、どの取引タイプの取引データの閲覧が許可されるかの権限である。データブロックの取引データには、取引タイプが付されている。取引タイプは、例えば、発票取引、サプライチェーン金融取引、法定デジタル通貨取引などであってもよい。発票取引では、地方税務機関のサービスノードは、その管轄範囲内の発票に関する全ての取引データの閲覧が許可され得るので、データブロックにおける発票に関する全ての取引データを地方税務機関のサービスノードに返信してもよい。サプライチェーン金融取引では、銀行のサービスノードは、その管轄範囲内のサプライチェーン金融に関する全ての取引データの閲覧が許可され得るので、データブロックにおけるサプライチェーン金融に関する全ての取引データを銀行のサービスノードに返信してもよい。法定デジタル通貨取引では、法定デジタル通貨の発行機関のサービスノードは、その管轄範囲内の法定デジタル通貨流通に関する全ての取引データの閲覧が許可され得るので、データブロックにおける法定デジタル通貨に関する全ての取引データを法定デジタル通貨の発行機関のサービスノードに返信してもよい。

【0073】

閲覧が許可される取引データに対応する、ブロックチェーンへの追加期間とは、どの期間にブロックチェーンへ追加された取引データの閲覧が許可されるかの権限である。例えば、サービスノードＡが、直近１年間にブロックチェーンへ追加された取引データのみを閲覧できると規定してもよい。

【0074】

これらの権限を組み合わせて使用してもよい。例えば、閲覧が許可される取引データに対応する、ブロックチェーンへの追加を要求したサービスノードと、閲覧が許可される取引データに対応する、ブロックチェーンへの追加期間とを組み合わせて使用してもよい。サービスノードＡがあるとすると、それに所属する機関のサービスノードにＡ１～Ａ７があり、その権限データには、サービスノードＡが、直近１年間にブロックチェーンへ追加された、サービスノードＡ、サービスノードＡ１～Ａ７の取引データを取得できると規定され得る。

【0075】

本願の一実施例では、ターゲットサービスノードから送信された取得要求に含まれるターゲットサービスノードの識別情報に基づいて、ターゲットサービスノードの認証情報を取得し、そして、該認証情報に基づいて、ターゲットサービスノードの権限情報を取得してもよい。ここで、サービスノードの認証情報は、サービスノードが事前に登録により取得した情報であってもよい。例えば、サービスノードは、記帳ノードサブネットワークに登録要求を送信してもよい。そして、記帳ノードサブネットワークは、該サービスノードに対応するネットワーク加入契約を取得し、さらに、該ネットワーク加入契約をデータブロックに入れ、該データブロックをブロックチェーンに追加することができる。該ネットワーク加入契約には、該サービスノードの認証情報及び権限情報が含まれる。ブロックチェーン上のデータブロックにおける全ての内容が記帳ノードにとって完全に閲覧可能であるため、記帳ノードは、サービスノードからの、該データブロックにおける取引データの要求を受信すると、要求元のサービスノードの識別情報に基づいて、ブロックチェーンにおいて該サービスノードの識別情報と対応付けて記憶されたネットワーク加入契約を見つけ、さらに該ネットワーク加入契約から権限情報を読み取ることができる。

【0076】

ステップＳ１２２０で、ターゲットサービスノードの権限情報に基づいて、前記指定のデータブロックに含まれる、前記ターゲットサービスノードに取得権限がある取引データを、前記ターゲットサービスノードに返信する。

【0077】

本願の実施例では、データブロックを生成した後、記帳ノードは、ブロックヘッダのみをサービスノードサブネットワークにおける各サービスノードに送信し、各サービスノードは、データブロックにおけるブロックボディーの各取引データを取得することができず、取引データの隠蔽が実現される。サービスノードは、データブロックにおける取引データを取得しようとすると、データブロックにおける取引データの取得要求を記帳ノードに送信する必要がある。記帳ノードは、サービスノードに閲覧権限がある取引データ（例えば、サービスノードに関連する取引データ、又はサービスノードに所属する機関に関連する取引データ）のみを、閲覧のためにサービスノードに送信するが、閲覧権限がない取引データ（例えば、他のサービスノードに関連する取引データ）に対して、サービスノードによる閲覧を禁止する。これにより、サービスノードは、それに関連する取引データを取得することができるとともに、他のサービスノードに関連する取引データが漏洩されるという問題を回避することができる。

【0078】

図１３は、本願の一実施例によるブロックチェーンシステムのデータ管理方法のフローチャートを模式的に示す。図１～図３に示すように、該ブロックチェーンシステムには、記帳ノードサブネットワーク２と、サービスノードサブネットワーク１とが含まれ、前記記帳ノードサブネットワークには、データブロックをブロックチェーンに記録する記帳ノードが含まれ、前記サービスノードサブネットワークには、記帳ノードによってブロックチェーンに記録されたデータブロックを検証するサービスノードが含まれる。図１３に示すブロックチェーンシステムのデータ管理方法は、サービスノードサブネットワークにおけるサービスノードによって実行されてもよい。図１３に示すように、該ブロックチェーンシステムのデータ管理方法は、少なくとも、ステップＳ１３１０～ステップＳ１３３０を含む。以下、詳しく紹介する。

【0079】

ステップＳ１３１０で、前記記帳ノードサブネットワークからの第１データブロックのブロックヘッダを受信し、前記第１データブロックのブロックヘッダには、署名と、前記第１データブロックの後に生成される第２データブロックのブロックヘッダを検証するための第１鍵情報とが含まれる。

【0080】

本願の一実施例では、記帳ノードサブネットワークが第１データブロックを生成する過程、及び、第１データブロックのブロックヘッダをサービスノードサブネットワークに配布する過程は、上記実施例で詳しく説明されており、ここでは説明を省略する。
ステップＳ１３２０で、前記第１データブロックのブロックヘッダに含まれる署名を検証する。

【0081】

本願の一実施例では、前述の実施例に記載されたように、第１データブロックがジェネシスブロックである場合、第１データブロックに含まれる署名を所定の鍵情報で検証してもよい。第１データブロックがジェネシスブロックではない場合、記帳ノードサブネットワークからの第３データブロックのブロックヘッダを受信してもよい。ここで、第３データブロックは、第１データブロックの前に生成されたものである。そして、第３データブロックのブロックヘッダから、第１データブロックのブロックヘッダを検証するための第２鍵情報を取得し、さらに、第１データブロックのブロックヘッダに含まれる署名を該第２鍵情報で検証する。

【0082】

具体的には、図７に示すように、データブロック１のブロックヘッダにより、データブロック２のブロックヘッダの検証に公開鍵Ａを使用することが指示され、データブロック２のブロックヘッダにより、データブロック３のブロックヘッダの検証に公開鍵Ｂを使用することが指示され、データブロック３のブロックヘッダにより、データブロック４のブロックヘッダの検証に公開鍵Ｃを使用することが指示される。この場合、データブロック２のブロックヘッダに含まれる署名を、データブロック１のブロックヘッダにより指示された公開鍵Ａで検証してもよい。同様に、データブロック３のブロックヘッダに含まれる署名を、データブロック２のブロックヘッダにより指示された公開鍵Ｂで検証する。

【0083】

ステップＳ１３３０で、前記第１データブロックのブロックヘッダに含まれる署名の検証に合格した場合、前記第１鍵情報を取得し、受信される前記第２データブロックのブロックヘッダを前記第１鍵情報で検証する。

【0084】

図１３に示す実施例の構成では、前のデータブロックのブロックヘッダの検証に合格した場合にのみ、次のデータブロックのブロックヘッダを検証するために使用される鍵情報を取得することができるので、ブロックヘッダのデータの安全性を確保することができるとともに、ブロックヘッダ検証鍵を柔軟に更新するという目的を達成することもでき、鍵交換が柔軟ではないことによる不便が回避され、固定鍵の使用によりデータが安全ではない恐れがあるという問題も回避される。

【0085】

前述の実施例の構成によれば、本願の一実施例では、図１４に示すように、本願の一実施例によるブロックチェーンシステムのデータ管理方法は、以下のステップを含む。

【0086】

ステップＳ１４１０で、前記記帳ノードサブネットワークから配布された前記ブロックヘッダに基づいて、前記記帳ノードサブネットワークにおけるターゲット記帳ノードに、指定のデータブロックに含まれる取引データの取得要求を送信する。

【0087】

本願の一実施例では、サービスノードは、記帳ノードサブネットワークから配布されたブロックヘッダを受信すると、該ブロックヘッダに基づいて、記帳ノードサブネットワークにおいて新たなデータブロックが生成されたことを決定することができ、さらに、指定のデータブロックに含まれる取引データの取得要求をターゲット記帳ノードに送信することができる。ここで、ターゲット記帳ノードは、記帳ノードサブネットワークにおける何れか１つの記帳ノードであってもよく、記帳ノードサブネットワークにおける、取得要求を送信したサービスノードから最も近い１つの記帳ノードであってもよく、取得要求を送信したサービスノードに対応する１つの記帳ノードであってもよい。

【0088】

ステップＳ１４２０で、前記ターゲット記帳ノードが前記取得要求に応じて返信した、前記指定のデータブロックに含まれる、前記ターゲットサービスノードに取得権限がある取引データを受信する。

【0089】

ここで、記帳ノードは、サービスノードから送信された取得要求を受信すると、該サービスノードの権限情報を取得することができ、さらに、該権限情報に基づいて、該サービスノードに取得権限がある取引データを取得することができる。この過程は、上記実施例で説明されているため、ここでは説明を省略する。

【0090】

以下、本願の装置実施例を紹介する。該装置は、本願の上記実施例におけるブロックチェーンシステムのデータ管理方法を実行するために使用することができる。本願の装置実施例に披露されていない細部について、本願の上記のブロックチェーンシステムのデータ管理方法の実施例を参照されたい。

【0091】

図１５は、本願の一実施例によるブロックチェーンシステムのデータ管理装置のブロック図を模式的に示す。図１～図３に示すように、該ブロックチェーンシステムには、記帳ノードサブネットワーク２と、サービスノードサブネットワーク１とが含まれ、前記記帳ノードサブネットワークには、データブロックをブロックチェーンに記録する記帳ノードが含まれ、前記サービスノードサブネットワークには、記帳ノードによってブロックチェーンに記録されたデータブロックを検証するサービスノードが含まれる。ここで、記帳ノードサブネットワーク２における記帳ノード２１には、図１５に示すデータ管理装置が含まれてもよく、又は、記帳ノードサブネットワーク及びサービスノードサブネットワークと接続された代行ノード（例えば、図１～図３に示す代行ノード１２、又は、記帳ノードサブネットワーク及びサービスノードサブネットワークから独立したノード）には、図１５に示すデータ管理装置が含まれてもよい。

【0092】

図１５に示すように、本願の一実施例によるブロックチェーンシステムのデータ管理装置１５００は、追加ユニット１５０２と、生成ユニット１５０４と、送信ユニット１５０６と、を含む。

【0093】

ここで、追加ユニット１５０２は、前記記帳ノードサブネットワークにおける記帳ノードが第１データブロックを生成した後、前記第１データブロックのブロックヘッダに、前記第１データブロックの後に生成される第２データブロックのブロックヘッダを検証するための第１鍵情報を追加し、生成ユニット１５０４は、前記第１データブロックに対応する署名を生成し、前記第１データブロックに対応する署名を前記第１データブロックのブロックヘッダに追加し、送信ユニット１５０６は、前記第１データブロックのブロックヘッダを前記サービスノードサブネットワークに配布することにより、前記サービスノードサブネットワークにおけるサービスノードが、前記第１データブロックのブロックヘッダに含まれる署名を検証し、検証に合格した場合、前記第１鍵情報を取得して前記第２データブロックのブロックヘッダを検証する。

【0094】

本願の一実施例では、追加ユニット１５０２は、前記第１データブロックのブロックヘッダに含まれる指定のフィールドに前記第１鍵情報を追加することにより、前記第２データブロックのブロックヘッダを前記第１鍵情報で検証するよう指示するように構成される。

【0095】

本願の一実施例では、追加ユニット１５０２は、前記第１鍵情報と、前記第１データブロックのブロックヘッダを検証するための鍵情報とが同じである場合、前記指定のフィールドにヌルを設定するように構成される。

【0096】

本願の一実施例では、前記ブロックチェーンシステムのデータ管理装置１５００は、認証センターから、前記第２データブロックに対応する証明書を取得し、取得した前記証明書を前記第１鍵情報とし、及び／又は、認証センターから、前記第２データブロックに対応する公開鍵及び秘密鍵を取得し、取得した前記公開鍵を前記第１鍵情報とする第１取得ユニットをさらに含む。

【0097】

本願の一実施例では、生成ユニット１５０４は、前記第１データブロックに対応する署名鍵を取得し、前記第１データブロックに対応する署名鍵で、前記第１データブロックに含まれるデータに対して署名アルゴリズムを実施することにより、前記第１データブロックに対応する署名を生成するように構成される。

【0098】

本願の一実施例では、生成ユニット１５０４は、さらに、前記記帳ノードサブネットワークにおける記帳ノードが前記第２データブロックを生成した場合、前記第１鍵情報に対応する署名鍵と、前記第２データブロックとに基づいて、前記第２データブロックに対応する署名を生成し、前記追加ユニットは、さらに、前記第２データブロックに対応する署名を前記第２データブロックのブロックヘッダに追加し、前記送信ユニット１５０６は、さらに、前記第２データブロックのブロックヘッダを前記サービスノードサブネットワークに配布する。

【0099】

本願の一実施例では、前記ブロックチェーンシステムのデータ管理装置１５００は、前記サービスノードサブネットワークにおけるターゲットサービスノードからの、指定のデータブロックに含まれる取引データの取得要求を受信すると、前記ターゲットサービスノードの権限情報を取得する第２取得ユニットをさらに含み、前記送信ユニット１５０６は、さらに、前記ターゲットサービスノードの権限情報に基づいて、前記指定のデータブロックに含まれる、前記ターゲットサービスノードに取得権限がある取引データを、前記ターゲットサービスノードに返信する。

【0100】

図１６は、本願の一実施例によるブロックチェーンシステムのデータ管理装置のブロック図を模式的に示す。図１～図３に示すように、該ブロックチェーンシステムには、記帳ノードサブネットワーク２と、サービスノードサブネットワーク１とが含まれ、記帳ノードサブネットワーク２には、記帳ノード２１が含まれ、サービスノードサブネットワーク１には、サービスノード１１が含まれる。ここで、サービスノードサブネットワーク１におけるサービスノード１１には、図１６に示すデータ管理装置が含まれてもよい。

【0101】

図１６に示すように、本願の一実施例によるブロックチェーンシステムのデータ管理装置１６００は、受信ユニット１６０２と、検証ユニット１６０４と、取得ユニット１６０６と、を含む。

【0102】

ここで、受信ユニット１６０２は、前記記帳ノードサブネットワークからの第１データブロックのブロックヘッダを受信し、前記第１データブロックのブロックヘッダには、署名と、前記第１データブロックの後に生成される第２データブロックのブロックヘッダを検証するための第１鍵情報とが含まれ、検証ユニット１６０４は、前記第１データブロックのブロックヘッダに含まれる署名を検証し、取得ユニット１６０６は、前記第１データブロックのブロックヘッダに含まれる署名の検証に合格した場合、前記第１鍵情報を取得し、受信される前記第２データブロックのブロックヘッダを前記第１鍵情報で検証する。

【0103】

本願の一実施例では、検証ユニット１６０４は、前記記帳ノードサブネットワークからの第３データブロックのブロックヘッダを受信し、前記第３データブロックのブロックヘッダから、前記第１データブロックのブロックヘッダを検証するための第２鍵情報を取得し、前記第１データブロックのブロックヘッダに含まれる署名を前記第２鍵情報で検証するように構成され、ここで、前記第３データブロックは、前記第１データブロックの前に生成されたものである。

【0104】

本願の一実施例では、検証ユニット１６０４は、前記第１データブロックがジェネシスブロックである場合、前記第１データブロックに含まれる署名を所定の鍵情報で検証するように構成される。

【0105】

本願の一実施例では、前記ブロックチェーンシステムのデータ管理装置１６００は、前記記帳ノードサブネットワークから配布された前記ブロックヘッダに基づいて、前記記帳ノードサブネットワークにおけるターゲット記帳ノードに、指定のデータブロックに含まれる取引データの取得要求を送信する送信ユニットをさらに含み、前記受信ユニット１６０２は、さらに、前記ターゲット記帳ノードが前記取得要求に応じて返信した、前記指定のデータブロックに含まれる、前記ターゲットサービスノードに取得権限がある取引データを受信する。

【0106】

図１７は、本願の実施例を実現することに好適な電子機器のコンピュータシステムの構成の模式図を示す。

【0107】

説明すべきものとして、図１７に示す電子機器のコンピュータシステム１７００は、一例にすぎず、本願の実施例の機能及び使用範囲にいかなる制限も与えるべきではない。

【0108】

図１７に示すように、コンピュータシステム１７００は、中央処理装置（ＣＰＵ：Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１７０１を含み、ＣＰＵ１７０１は、読み出し専用メモリ（ＲＯＭ：Ｒｅａｄ－Ｏｎｌｙ Ｍｅｍｏｒｙ）１７０２に記憶されたプログラム、又は、記憶部１７０８からランダムアクセスメモリ（ＲＡＭ：Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）１７０３にロードされたプログラムに基づいて、各種の適当な動作及び処理、例えば、上記実施例における方法を実行することができる。ＲＡＭ１７０３には、システム動作に必要な各種のプログラム及びデータがさらに含まれる。ＣＰＵ１７０１、ＲＯＭ１７０２、及びＲＡＭ１７０３は、バス１７０４を介して互いに接続される。入力／出力（Ｉ／Ｏ：Ｉｎｐｕｔ／Ｏｕｔｐｕｔ）インタフェース１７０５もバス１７０４に接続される。

【0109】

Ｉ／Ｏインタフェース１７０５には、キーボード、マウスなどを含む入力部１７０６と、例えば、陰極線管（ＣＲＴ：Ｃａｔｈｏｄｅ Ｒａｙ Ｔｕｂｅ）、液晶ディスプレイ（ＬＣＤ：Ｌｉｑｕｉｄ Ｃｒｙｓｔａｌ Ｄｉｓｐｌａｙ）など、及びスピーカーなどを含む出力部１７０７と、ハードディスクなどを含む記憶部１７０８と、例えば、ローカルエリアネットワーク（ＬＡＮ：Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）カード、モデムなどのネットワークインタフェースカードを含む通信部１７０９とが接続される。通信部１７０９は、インターネットのようなネットワークを介して、通信処理を実行する。ドライバー１７１０も、必要に応じて、Ｉ／Ｏインタフェース１７０５に接続される。例えば、磁気ディスク、光ディスク、磁気光学ディスク、半導体メモリなどの取り外し可能な媒体１７１１は、必要に応じて、ドライバー１７１０に取り付けられる。これにより、取り外し可能な媒体１７１１から読み取られたコンピュータプログラムは、必要に応じて、記憶部１７０８にインストールされる。

【0110】

特に、本願の実施例によれば、以下、フローチャートを参照して説明される過程は、コンピュータソフトウェアプログラムとして実現されてもよい。例えば、本願の実施例は、コンピュータ可読媒体に搭載されたコンピュータプログラムが含まれるコンピュータプログラム製品を含み、該コンピュータプログラムには、フローチャートに示される方法を実行するためのプログラムコードが含まれる。このような実施例では、該コンピュータプログラムは、通信部１７０９によって、ネットワークからダウンロード及びインストールされ、及び／又は、取り外し可能な媒体１７１１からインストールされてもよい。該コンピュータプログラムは、中央処理装置（ＣＰＵ）１７０１によって実行されると、本願のシステムで限定された各種の機能を実行させる。

【0111】

説明すべきものとして、本願の実施例に示されるコンピュータ可読媒体は、コンピュータ可読信号媒体又はコンピュータ可読記憶媒体、あるいは、上記の両者の任意の組み合わせであってもよい。コンピュータ可読記憶媒体は、例えば、電気、磁気、光、電磁気、赤外線、又は半導体のシステム、装置、又はデバイス、あるいは、上記の任意の組み合わせであってもよいが、これらに限定されない。コンピュータ可読記憶媒体のより具体的な例は、１つ又は複数の導線がある電気接続、ポータブルコンピュータ磁気ディスク、ハードディスク、ランダムアクセスメモリ（ＲＡＭ）、読み出し専用メモリ（ＲＯＭ）、消去可能プログラマブル読み出し専用メモリ（ＥＰＲＯＭ：Ｅｒａｓａｂｌｅ Ｐｒｏｇｒａｍｍａｂｌｅ Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、フラッシュメモリ、光ファイバー、ポータブルコンパクトディスク読み出し専用メモリ（ＣＤ－ＲＯＭ：Ｃｏｍｐａｃｔ Ｄｉｓｃ Ｒｅａｄ－Ｏｎｌｙ Ｍｅｍｏｒｙ）、光記憶デバイス、磁気記憶デバイス、あるいは、上記の任意の適切な組み合わせを含んでもよいが、これらに限定されない。本願では、コンピュータ可読記憶媒体は、プログラムを含み又は記憶した任意の有形の媒体であってもよく、該プログラムは、命令実行システム、装置、又はデバイスによって使用されるか、あるいは、これらと組み合わせて使用されてもよい。一方、本願では、コンピュータ可読信号媒体は、ベースバンドで又はキャリアの一部として伝播されるデータ信号を含んでもよく、該データ信号には、コンピュータ可読プログラムコードが搭載される。このような伝播されるデータ信号は、電磁気信号、光信号、又は上記の任意の適切な組み合わせを含むがこれらに限定されない様々な形態をとることができる。コンピュータ可読信号媒体は、コンピュータ可読記憶媒体以外の任意のコンピュータ可読媒体であってもよく、該コンピュータ可読媒体は、命令実行システム、装置、又はデバイスによって使用されるか、あるいは、これらと組み合わせて使用されるためのプログラムを送信、伝播、又は伝送することができる。コンピュータ可読媒体に含まれるプログラムコードは、無線、有線等、又は上記の任意の適切な組み合わせを含むがこれらに限定されない任意の適切な媒体で伝送されてもよい。

【0112】

図面中のフローチャート及びブロック図は、本願の各種の実施例によるシステム、方法、及びコンピュータプログラム製品の実現可能なシステムアーキテクチャ、機能、及び動作を図示している。この点で、フローチャート又はブロック図における各ブロックは、モジュール、プログラムセグメント、又はコードの一部を表すことができ、上記モジュール、プログラムセグメント、又はコードの一部には、所定の論理機能を実現するための１つ又は複数の実行可能命令が含まれる。別の注意すべきものとして、代替としてのいくつかの実現では、ブロックに記載された機能は、図面に記載された順序とは異なる順序で行われてもよい。例えば、連続して示される２つのブロックは、実際には、基本的に並行して実行される場合があり、関連する機能によっては、逆の順序で実行される場合もある。別の注意すべきものとして、ブロック図又はフローチャートにおける各ブロック、及び、ブロック図又はフローチャートにおけるブロックの組み合わせは、所定の機能又は動作を実行するための専用の、ハードウェアに基づくシステムで実現されてもよく、あるいは、専用ハードウェアとコンピュータ命令との組み合わせで実現されてもよい。

【0113】

本願の実施例の説明に係るユニットは、ソフトウェアで実現されてもよく、ハードウェアで実現されてもよく、説明されたユニットは、プロセッサに設置されてもよい。ここで、これらのユニットの名称は、ある場合には該ユニット自体を限定するものではない。

【0114】

別の態様として、本願では、コンピュータ可読媒体も提供されており、該コンピュータ可読媒体は、上記実施例で説明された電子機器に含まれるものであってもよいし、該電子機器に組み立てされることなく単独で存在するものであってもよい。上記コンピュータ可読媒体には、１つ又は複数のプログラムが搭載され、上記１つ又は複数のプログラムは、該電子機器によって実行されると、該電子機器に、上記実施例に記載の方法を実現させる。

【0115】

注意すべきものとして、上記の詳細な説明では、動作を実行するための機器の若干のモジュール又はユニットが言及されているが、このような分割は強制的ではない。実際には、本願の実施形態によれば、上述した２つ以上のモジュール又はユニットの特徴及び機能は、１つのモジュール又はユニットに具体化されてもよい。逆に、上述した１つのモジュール又はユニットの特徴及び機能は、複数のモジュール又はユニットによって具体化されるように、さらに分割されてもよい。

【0116】

上記の実施形態の説明によれば、当業者には容易に理解されるように、ここで説明された例示的な実施形態は、ソフトウェアによって実現されてもよいし、ソフトウェアと必要なハードウェアとの組み合わせによって実現されてもよい。このため、本願の実施形態による構成は、ソフトウェア製品の形で具現されてもよい。該ソフトウェア製品は、不揮発性記憶媒体（ＣＤ－ＲＯＭ、Ｕディスク、モバイルハードディスクなどであってもよい）又はネットワークに記憶されてもよく、コンピュータ機器（パーソナルコンピュータ、サーバ、タッチ端末、又はネットワーク機器などであってもよい）に、本願の実施形態による方法を実行させる若干の命令を含む。

【0117】

当業者は、明細書を考慮して、ここで開示された出願を実施した後、本願の他の実施形態を容易に想到し得る。本願は、本願の任意の変形、用途、又は適応的な変更が包括されることを趣旨とする。これらの変形、用途、又は適応的な変更は、本願の一般的な原理に従い、本願に開示されていない本技術分野における技術常識又は慣用の技術的手段を含む。

【0118】

理解すべきものとして、本願は、上記で説明されて図面に示された精確な構造に限定されるものではなく、その範囲から逸脱することなく様々な修正及び変更が可能である。本願の範囲は、添付の特許請求の範囲によってのみ制限される。

【符号の説明】

【0119】

１ サービスノードサブネットワーク
２ 記帳ノードサブネットワーク
１１ サービスノード
１２ 代行ノード
２１ 記帳ノード
１５００ データ管理装置
１５０２ 追加ユニット
１５０４ 生成ユニット
１５０６ 送信ユニット
１６００ データ管理装置
１６０２ 受信ユニット
１６０４ 検証ユニット
１６０６ 取得ユニット
１７００ コンピュータシステム
１７０１ ＣＰＵ
１７０２ ＲＯＭ
１７０３ ＲＡＭ
１７０４ バス
１７０５ Ｉ／Ｏインタフェース
１７０６ 入力部
１７０７ 出力部
１７０８ 記憶部
１７０９ 通信部
１７１０ ドライバー
１７１１ 取り外し可能な媒体

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】