特許 7199775 スマートコントラクトに基づくデータ処理方法、データ処理装置、ノード機器、及びコンピュータプログラム

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

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

(11)【特許番号】

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

(45)【発行日】2023-01-06

(54)【発明の名称】スマートコントラクトに基づくデータ処理方法、データ処理装置、ノード機器、及びコンピュータプログラム

(51)【国際特許分類】

   G06F 21/57 20130101AFI20221226BHJP

【ＦＩ】

G06F21/57 320

【請求項の数】 15

(21)【出願番号】P 2021515047

(86)(22)【出願日】2020-07-13

(65)【公表番号】

(43)【公表日】2022-01-11

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

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

(87)【国際公開日】2021-03-04

【審査請求日】2021-03-17

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

(32)【優先日】2019-08-29

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

(73)【特許権者】

【識別番号】517392436

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

(74)【代理人】

【識別番号】100110364

【弁理士】

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

(74)【代理人】

【識別番号】100150197

【弁理士】

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

(72)【発明者】

【氏名】▲張▼ ▲尭▼

(72)【発明者】

【氏名】▲楊▼ ▲韜▼

【審査官】小林 秀和

(56)【参考文献】

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

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

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

【文献】中国特許出願公開第１０９８８９５８９（ＣＮ，Ａ）

【文献】中国特許出願公開第１０７３２９７９４（ＣＮ，Ａ）

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

Ｇ０６Ｆ ２１／５７

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

【請求項1】

コントラクトノードである電子機器が実行する、スマートコントラクトに基づくデータ処理方法であって、
実行ノードから送信された、第１サーバノードに対するファームウェア更新要求を受信するステップであって、前記ファームウェア更新要求には、少なくとも、前記第１サーバノードの更新バージョンパラメータが含まれる、ステップと、
前記ファームウェア更新要求に応じてスマートコントラクトを呼び出し、前記スマートコントラクトに基づいて、ブロックチェーンから、前記第１サーバノードに関連付けられたファームウェアバージョン更新履歴及びファームウェアバージョン配布履歴を取得するステップであって、前記ファームウェアバージョン配布履歴が、コンセンサスメカニズムに基づいて前記ブロックチェーンにおける配布ノードによって決定されたものである、ステップと、
前記ファームウェアバージョン更新履歴、前記ファームウェアバージョン配布履歴、前記更新バージョンパラメータに基づいて、前記ファームウェア更新要求の正当性を決定するステップと、
を含む方法。

【請求項2】

前記スマートコントラクトを呼び出し、前記ブロックチェーンから、前記第１サーバノードに関連付けられたファームウェアバージョン更新履歴及びファームウェアバージョン配布履歴を取得する前記ステップは、
前記スマートコントラクトを呼び出すことにより、前記第１サーバノードの前記ブロックチェーン上のブロックチェーンアドレスを取得するステップであって、前記ブロックチェーンアドレスが、前記ブロックチェーンが前記第１サーバノードの公開鍵情報に基づいてハッシュ計算を行うことにより一意に決定されたものである、ステップと、
前記ブロックチェーンアドレスに基づいて、前記ブロックチェーンから、前記第１サーバノードに関連付けられた第１ブロック及び第２ブロックを取得するステップと、
前記第１ブロックにおいて、第１バージョンパラメータ及び第２バージョンパラメータが付されている過去バージョン更新行動情報を、前記第１サーバノードに関連付けられたファームウェアバージョン更新履歴として決定するステップであって、前記第２バージョンパラメータが、前記第１バージョンパラメータに対してファームウェア更新を行ったバージョンパラメータである、ステップと、
前記第２ブロックにおいて、前記第１サーバノードに関連付けられた過去バージョン配布行動情報をファームウェアバージョン配布履歴として決定するステップと、
を含む請求項１に記載の方法。

【請求項3】

前記ファームウェアバージョン更新履歴、前記ファームウェアバージョン配布履歴、前記更新バージョンパラメータに基づいて、前記ファームウェア更新要求の正当性を決定する前記ステップは、
前記ファームウェアバージョン更新履歴における前記第１バージョンパラメータに基づいて、前記更新バージョンパラメータに対してロールバック検出を行うステップと、
前記第１バージョンパラメータが前記更新バージョンパラメータと同じであることを検出した場合、バージョンロールバックが存在すると決定し、前記ファームウェア更新要求が不正な更新要求であると決定するステップであって、前記不正な更新要求が、前記実行ノードが前記第１サーバノードのバージョン情報に対するファームウェア更新権限を有しないことを示すためのものである、ステップと、
前記第１バージョンパラメータが前記更新バージョンパラメータと異なることを検出した場合、バージョンロールバックが存在しないと決定し、前記更新バージョンパラメータ及び前記ファームウェアバージョン配布履歴に基づいて、前記ファームウェア更新要求の正当性を決定するステップと、
を含む請求項２に記載の方法。

【請求項4】

前記更新バージョンパラメータ及び前記ファームウェアバージョン配布履歴に基づいて、前記ファームウェア更新要求が正当な更新要求であると決定する前記ステップは、
前記ファームウェアバージョン配布履歴に関連付けられた過去バージョン配布行動情報の中から、第１バージョン配布行動情報を取得するステップであって、前記第１バージョン配布行動情報が、前記過去バージョン配布行動情報のうち最大バージョン配布タイムスタンプを有するバージョン配布行動情報である、ステップと、
前記第１バージョン配布行動情報に前記更新バージョンパラメータが含まれていることを検出した場合、前記ファームウェア更新要求が正当な更新要求であると決定するステップと、
を含む請求項３に記載の方法。

【請求項5】

前記ファームウェア更新要求には、前記第１サーバノードの実行バージョンパラメータがさらに含まれ、
前記方法は、
前記第１バージョン配布行動情報に前記更新バージョンパラメータが含まれていないが、前記過去バージョン配布行動情報のうちの第２バージョン配布行動情報に前記更新バージョンパラメータが含まれていることを検出した場合、前記ブロックチェーンから、前記更新バージョンパラメータを使用してファームウェア更新を行ったＭ個（Ｍは２より大きい正の整数）の第２サーバノードを検索するステップと、
前記Ｍ個の第２サーバノードのそれぞれに関連付けられたＭ個の第２サーバノードのバージョン更新行動情報を取得するステップと、
前記Ｍ個の第２サーバノードのバージョン更新行動情報のいずれにも前記実行バージョンパラメータが含まれていることを検出した場合、前記ファームウェア更新要求が正当な更新要求であると決定し、そうでない場合、前記ファームウェア更新要求が不正な更新要求であると決定するステップと、をさらに含む、
請求項４に記載の方法。

【請求項6】

前記ファームウェア更新要求が正当な更新要求であると決定した場合、前記第１サーバノードに対するファームウェア更新のためのフィードバック情報を前記実行ノードに返信するステップであって、前記フィードバック情報が、前記実行ノードに対し、前記第１サーバノードのファームウェアバージョン情報を、前記実行バージョンパラメータにおける実行バージョン情報から、前記更新バージョンパラメータにおける更新バージョン情報に更新するよう指示するためのものである、ステップ、
をさらに含む請求項５に記載の方法。

【請求項7】

前記ファームウェア更新要求が不正な更新要求であることを検出した場合、コントラクトの実行に失敗したと確認し、前記実行ノードに前記不正な更新要求を返却するステップと、
前記実行ノードから送信された、前記第１サーバノードに対する次のファームウェア更新要求を受信すると、前記次のファームウェア更新要求を前記不正な更新要求としてマークするステップであって、前記不正な更新要求は、前記配布ノードに対し、セキュリティ監査を行う時に前記実行ノードに対する警告情報を生成するよう指示するためのものである、ステップと、
をさらに含む請求項５に記載の方法。

【請求項8】

前記警告情報は、前記配布ノードが、前記ブロックチェーンから取得された、前記第１サーバノードのオンチェーン更新バージョンパラメータと、前記第１サーバノードのローカルから収集された更新済みの実行バージョンパラメータとに基づいて、セキュリティ監査を行うことにより取得されたものである、
請求項７に記載の方法。

【請求項9】

前記更新バージョンパラメータに対して前記第１サーバノードによって署名された確認情報を受信するステップであって、前記確認情報が、前記実行ノードが前記第１サーバノードのファームウェアバージョン情報の更新を完了したことを示すためのものである、ステップと、
前記第１サーバノードの公開鍵情報で前記確認情報の署名検証を行い、署名検証が成功した場合、前記スマートコントラクトの呼び出しが完了したと決定するステップと、
前記確認情報及び前記ファームウェア更新要求に基づいて、前記第１サーバノードのファームウェアバージョン更新履歴を更新し、前記第１サーバノードのブロックチェーンアドレスに基づいて、更新済みのファームウェアバージョン更新履歴を前記ブロックチェーンに書き込むステップと、
をさらに含む請求項１に記載の方法。

【請求項10】

前記確認情報及び前記ファームウェア更新要求に基づいて、前記第１サーバノードのファームウェアバージョン更新履歴を更新し、前記第１サーバノードのブロックチェーンアドレスに基づいて、更新済みのファームウェアバージョン更新履歴を前記ブロックチェーンに書き込む前記ステップは、
前記ファームウェア更新要求における更新バージョンパラメータ、実行バージョンパラメータを、前記第１サーバノードに関連付けられたファームウェアバージョン更新履歴を構築するための入力情報とするステップと、
前記確認情報に付されている前記更新バージョンパラメータを、前記第１サーバノードに関連付けられたファームウェアバージョン更新履歴を構築するための出力情報とするステップと、
前記入力情報及び前記出力情報に基づいて、前記第１サーバノードに関連付けられたターゲットバージョン更新行動情報を決定し、前記ターゲットバージョン更新行動情報に基づいて、前記第１サーバノードのファームウェアバージョン更新履歴を更新するステップと、
前記第１サーバノードのブロックチェーンアドレスに基づいて、更新済みのファームウェアバージョン更新履歴を前記ブロックチェーンに書き込むステップと、
を含む請求項９に記載の方法。

【請求項11】

コントラクトノードに適用される、スマートコントラクトに基づくデータ処理装置であって、
実行ノードから送信された、第１サーバノードに対するファームウェア更新要求を受信し、前記ファームウェア更新要求には、少なくとも、前記第１サーバノードの更新バージョンパラメータが含まれる要求受信モジュールと、
前記ファームウェア更新要求に応じてスマートコントラクトを呼び出し、前記スマートコントラクトに基づいて、ブロックチェーンから、前記第１サーバノードに関連付けられたファームウェアバージョン更新履歴及びファームウェアバージョン配布履歴を取得し、前記ファームウェアバージョン配布履歴が、コンセンサスメカニズムに基づいて前記ブロックチェーンにおける配布ノードによって決定されたものであるコントラクト呼び出しモジュールと、
前記ファームウェアバージョン更新履歴、前記ファームウェアバージョン配布履歴、前記更新バージョンパラメータに基づいて、前記ファームウェア更新要求の正当性を決定する正当性決定モジュールと、
を含む装置。

【請求項12】

前記コントラクト呼び出しモジュールは、
前記スマートコントラクトを呼び出すことにより、前記第１サーバノードの前記ブロックチェーン上のブロックチェーンアドレスを取得し、前記ブロックチェーンアドレスが、前記ブロックチェーンが前記第１サーバノードの公開鍵情報に基づいてハッシュ計算を行うことにより一意に決定されたものであるアドレス取得ユニットと、
前記ブロックチェーンアドレスに基づいて、前記ブロックチェーンから、前記第１サーバノードに関連付けられた第１ブロック及び第２ブロックを取得するブロック取得ユニットと、
前記第１ブロックにおいて、第１バージョンパラメータ及び第２バージョンパラメータが付されている過去バージョン更新行動情報を、前記第１サーバノードに関連付けられたファームウェアバージョン更新履歴として決定し、前記第２バージョンパラメータが、前記第１バージョンパラメータに対してファームウェア更新を行ったバージョンパラメータである更新履歴決定ユニットと、
前記第２ブロックにおいて、前記第１サーバノードに関連付けられた過去バージョン配布行動情報をファームウェアバージョン配布履歴として決定する配布履歴決定ユニットと、
を含む請求項１１に記載の装置。

【請求項13】

前記正当性決定モジュールは、
前記ファームウェアバージョン更新履歴における前記第１バージョンパラメータに基づいて、前記更新バージョンパラメータに対してロールバック検出を行うロールバック検出ユニットと、
前記第１バージョンパラメータが前記更新バージョンパラメータと同じであることを検出した場合、バージョンロールバックが存在すると決定し、前記ファームウェア更新要求が不正な更新要求であると決定し、前記不正な更新要求が、前記実行ノードが前記第１サーバノードのバージョン情報に対するファームウェア更新権限を有しないことを示すためのものである不正決定ユニットと、
前記第１バージョンパラメータが前記更新バージョンパラメータと異なることを検出した場合、バージョンロールバックが存在しないと決定し、前記更新バージョンパラメータ及び前記ファームウェアバージョン配布履歴に基づいて、前記ファームウェア更新要求の正当性を決定する正当性決定ユニットと、
を含む請求項１２に記載の装置。

【請求項14】

プロセッサとメモリとを備えるノード機器であって、
前記プロセッサが前記メモリに接続され、前記メモリがプログラムコードを記憶し、前記プロセッサが、前記プログラムコードを呼び出すことにより、請求項１～１０のいずれか1項に記載の方法を実行するノード機器。

【請求項15】

請求項１～１０のいずれか１項に記載の方法を電子機器に実行させるコンピュータプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本願は、２０１９年８月２９日に国家知識産権局に提出された、出願番号が２０１９１０８０８３５１．８であり、発明の名称が「スマートコントラクトに基づくデータ処理方法、機器、及び記憶媒体」である中国特許出願に基づく優先権を主張し、その全ての内容は参照することにより本願に組み込まれる。

【0002】

本願は、インターネットの技術分野に関し、特にスマートコントラクトに基づくデータ処理方法、機器、及び記憶媒体に関する。

【背景技術】

【0003】

サーバファームウェア（Ｆｉｒｍｗａｒｅ）とは、サーバの消去可能なプログラマブル読み出し専用メモリ（ＥＰＲＯＭ）又は電気的消去可能プログラマブル読み出し専用メモリ（ＥＥＰＲＯＭ）に書き込まれるプログラムである。理解すべきものとして、サーバファームウェアは、相応のオペレーティングシステムにおける、ハードウェアデバイスの基本的なパラメータ及びプログラムを記憶でき、そのオペレーティングシステムに最下層の最も直接的なハードウェア制御を提供できる。

【0004】

現在、サーバ運用保守担当者は、オフライン分析、帯域内ネットワークやシステム管理割り込みなどのファームウェア更新方法によって、サーバのファームウェア（例えば、基本入出力システム（ＢＩＯＳ：Ｂａｓｉｃ Ｉｎｐｕｔ Ｏｕｔｐｕｔ Ｓｙｓｔｅｍ）のファームウェア）を更新し、このオペレーティングシステムに新機能を追加したり、このオペレーティングシステムの異常を修復したりすることができる。

【発明の概要】

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

【0005】

本願の実施例は、ファームウェア更新のセキュリティ及び信頼性を向上させることができる、スマートコントラクトに基づくデータ処理方法、機器、及び記憶媒体を提供する。

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

【0006】

本願の実施例では、コントラクトノードである電子機器が実行する、スマートコントラクトに基づくデータ処理方法が提供されている。前記方法は、
実行ノードから送信された、第１サーバノードに対するファームウェア更新要求を受信するステップであって、前記ファームウェア更新要求には、少なくとも、前記第１サーバノードの更新バージョンパラメータが含まれる、ステップと、
前記ファームウェア更新要求に応じてスマートコントラクトを呼び出し、前記スマートコントラクトに基づいて、ブロックチェーンから、前記第１サーバノードに関連付けられたファームウェアバージョン更新履歴及びファームウェアバージョン配布履歴を取得するステップであって、前記ファームウェアバージョン配布履歴が、コンセンサスメカニズムに基づいて前記ブロックチェーンにおける配布ノードによって決定されたものである、ステップと、
前記ファームウェアバージョン更新履歴、前記ファームウェアバージョン配布履歴、前記更新バージョンパラメータに基づいて、前記ファームウェア更新要求の正当性を決定するステップと、を含む。

【0007】

本願の実施例では、コントラクトノードに適用される、スマートコントラクトに基づくデータ処理装置が提供されている。前記装置は、
実行ノードから送信された、第１サーバノードに対するファームウェア更新要求を受信し、前記ファームウェア更新要求には、少なくとも、前記第１サーバノードの更新バージョンパラメータが含まれる要求受信モジュールと、
前記ファームウェア更新要求に応じてスマートコントラクトを呼び出し、前記スマートコントラクトに基づいて、ブロックチェーンから、前記第１サーバノードに関連付けられたファームウェアバージョン更新履歴及びファームウェアバージョン配布履歴を取得し、前記ファームウェアバージョン配布履歴が、コンセンサスメカニズムに基づいて前記ブロックチェーンにおける配布ノードによって決定されたものであるコントラクト呼び出しモジュールと、
前記ファームウェアバージョン更新履歴、前記ファームウェアバージョン配布履歴、前記更新バージョンパラメータに基づいて、前記ファームウェア更新要求の正当性を決定する正当性決定モジュールと、を含む。

【0008】

本願の実施例では、プロセッサとメモリとを備えるノード機器が提供されており、
前記プロセッサが前記メモリに接続され、前記メモリがプログラムコードを記憶し、前記プロセッサが、前記プログラムコードを呼び出すことにより、
実行ノードから送信された、第１サーバノードに対するファームウェア更新要求を受信するステップであって、前記ファームウェア更新要求には、少なくとも、前記第１サーバノードの更新バージョンパラメータが含まれる、ステップと、
前記ファームウェア更新要求に応じてスマートコントラクトを呼び出し、前記スマートコントラクトに基づいて、ブロックチェーンから、前記第１サーバノードに関連付けられたファームウェアバージョン更新履歴及びファームウェアバージョン配布履歴を取得するステップであって、前記ファームウェアバージョン配布履歴が、コンセンサスメカニズムに基づいて前記ブロックチェーンにおける配布ノードによって決定されたものである、ステップと、
前記ファームウェアバージョン更新履歴、前記ファームウェアバージョン配布履歴、前記更新バージョンパラメータに基づいて、前記ファームウェア更新要求の正当性を決定するステップと、を実行する。

【0009】

本願の実施例では、コンピュータプログラムを記憶したコンピュータ記憶媒体が提供されており、前記コンピュータプログラムには、プログラム命令が含まれ、前記プログラム命令が、プロセッサによって実行されると、本願の実施例のいずれか１つに記載の方法を実行させる。

【0010】

本願の実施例の構成をより明確に説明するために、以下、実施例の説明に必要な図面を簡単的に紹介する。明らかに、以下の説明における図面は本願のいくつかの実施例を示しているにすぎず、当業者にとって、創造的な労働をせずに、これらの図面から他の図面を得ることもできる。

【図面の簡単な説明】

【0011】

【図1】本願の実施例で提供されたブロックチェーンネットワークのトポロジ構造の構造模式図である。

【図2】本願の実施例で提供されたスマートコントラクトに基づくデータ処理方法の手順の模式図である。

【図3】本願の実施例で提供されたネストされたハッシュチェーンのブロック構造の模式図である。

【図4a】本願の実施例で提供されたバージョン配布制御の模式図である。

【図4b】本願の実施例で提供されたバージョン配布制御の模式図である。

【図5】本願の実施例で提供されたスマートコントラクトに基づく別のデータ処理方法の手順の模式図である。

【図6】本願の実施例で提供されたバージョン配布行動情報の取得の模式図である。

【図7】本願の実施例で提供されたファームウェアバージョン更新履歴の構築の模式図である。

【図8】本願の実施例で提供された配布ノードを介したセキュリティ監査の模式図である。

【図9】本願の実施例で提供されたスマートコントラクトに基づくデータ処理装置の構成の模式図である。

【図10】本願の実施例で提供されたノード機器の構成の模式図である。

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

【0012】

以下、本願の実施例の図面を参照しながら、本願の実施例の構成を明確かつ完全に説明するが、明らかなように、説明する実施例は、本願の実施例の一部にすぎず、全ての実施例ではない。当業者が創造的な労働をせずに本願の実施例から得る全ての他の実施例は、本願の保護範囲に属する。

【0013】

現在、サーバメーカーの公式サイトで提供されているファームウェアが全てオープンダウンロード状態にあるので、運用保守担当者は、どのファームウェア更新方法を使用しても、サーバメーカーの公式サイトから該当機種のファームウェアをダウンロードし、使用するファームウェア更新方法のステップに従ってファームウェアのアップグレード操作を実行することができる。したがって、ファームウェア更新に使用されるファームウェアのデータが不正に侵入・改ざんされると、このオペレーティングシステムの最下層のセキュリティ保護を深刻に脅かすことになり、言い換えれば、従来のファームウェア更新方法では、ファームウェア更新のセキュリティ及び信頼性を確保できない。

【0014】

図１は、本願の実施例で提供されたブロックチェーンネットワークのトポロジ構造の構造模式図である。図１に示すブロックチェーンネットワークのトポロジ構造は、企業イントラネットに大規模なサーバがあるような適用シナリオに適用できる。図１に示すように、このブロックチェーンネットワークのトポロジ構造は、図１に示す配布層１００と、コントラクト層２００と、実施層３００とを含んでもよい。

【0015】

図１に示すように、前記配布層１００に位置するノードは、配布ノードと呼ぶことができ、具体的には、図１に示す配布ノード１０ａ、配布ノード１０ｂ、及び配布ノード１０ｃを含んでもよい。理解すべきものとして、この配布層１００には、他の配布ノード（図１には示されていない）も含まれてもよい。図１に示すように、コントラクト層２００に位置するノードは、コントラクトノードと総称することができる。コントラクトノードは、ブロックチェーンにおいて、ブロックチェーンに記憶されたスマートコントラクトを呼び出して実行することができるノードと理解できる。具体的には、このコントラクト層２００には、図１に示すコントラクトノード２０ａ及びコントラクトノード２０ｂが含まれてもよい。図１に示すように、実施層３００に位置するノードは、主に２種類のノードから構成され、この２種類のノードのうち、１種類のノードは実行ノードと呼ぶことができ、もう１種類のノードはサーバノードと呼ぶことができる。ここで、実行ノードは、具体的には、図１に示す実行ノード３０ａ及び実行ノード３０ｂを含んでもよい。同様に、サーバノードは、具体的には、図１に示すサーバノード４０ａ、サーバノード４０ｂ、及びサーバノード４０ｃを含んでもよい。

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

【表1】

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

第１情報決定ユニット６０１は、前記ファームウェア更新要求における更新バージョンパラメータ、実行バージョンパラメータを、前記第１サーバノードに関連付けられたファームウェアバージョン更新履歴を構築するための入力情報とし、
第２情報決定ユニット６０２は、前記確認情報に付されている前記更新バージョンパラメータを、前記第１サーバノードに関連付けられたファームウェアバージョン更新履歴を構築するための出力情報とし、
更新行動決定ユニット６０３は、前記入力情報及び前記出力情報に基づいて、前記第１サーバノードに関連付けられたターゲットバージョン更新行動情報を決定し、前記ターゲットバージョン更新行動情報に基づいて、前記第１サーバノードのファームウェアバージョン更新履歴を更新し、
履歴書き込みユニット６０４は、前記サーバノードのブロックチェーンアドレスに基づいて、更新済みのファームウェアバージョン更新履歴を前記ブロックチェーンに書き込む。

【0120】

ここで、前記第１情報決定ユニット６０１、第２情報決定ユニット６０２、更新行動決定ユニット６０３、履歴書き込みユニット６０４の具体的な実現形態については、上記図２に対応する実施例におけるファームウェアバージョン更新履歴の説明を参照すればよく、ここでは詳しく説明しない。

【0121】

ここで、前記要求受信モジュール１０、コントラクト呼び出しモジュール２０、正当性決定モジュール３０の具体的な実現形態については、上記図２に対応する実施例におけるステップＳ１０１～ステップＳ１０３の説明を参照すればよく、ここでは詳しく説明しない。本願の実施例では、確認受信モジュール４０、署名検証モジュール５０、及び履歴更新モジュール６０の具体的な実現形態については、上記図５に対応する実施例におけるステップＳ２０１～ステップＳ２０８の説明を参照すればよく、ここでは詳しく説明しない。

【0122】

本願の実施例では、第１端末は、実行ノードから送信された、第１サーバノードに対するファームウェア更新要求を受信すると、スマートコントラクトを呼び出し、実行ノードによって開始されたファームウェア更新要求に対してスマート更新管理制御を行うことで、ファームウェア更新のセキュリティを確保することができる。ここで、該ファームウェア更新要求には、該第１サーバノードに対するファームウェア更新に使用される予定の更新バージョンパラメータが含まれてもよい。さらに、コントラクトノードは、ブロックチェーンから、第１サーバノードに関連付けられたファームウェアバージョン更新履歴及びファームウェアバージョン配布履歴を取得でき、取得したファームウェアバージョン更新履歴及びファームウェアバージョン配布履歴に基づいて、該ファームウェア更新要求における更新バージョンパラメータに対してコントラクト検出を行え、コントラクト検出結果を満たすファームウェア更新要求を正当な更新要求として決定でき、逆に、コントラクト検出結果を満たさないファームウェア更新要求を不正な更新要求として決定できる。ここから分かるように、コントラクトノードは、該第１サーバノードの最下層ファームウェアに対する全ての更新操作について、スマートコントラクトにより、正当なファームウェア更新操作と不正なファームウェア更新操作とを効果的に区別することができる。これにより、ファームウェア更新の信頼性を向上させる。

【0123】

さらに、本願の実施例で提供されたノード機器の構成の模式図である図１０を参照されたい。図１０に示すように、前記ノード機器１０００は、上記図１に対応する実施例におけるコントラクトノード２０ａに適用できる。前記ノード機器１０００は、プロセッサ１００１と、ネットワークインタフェース１００４と、メモリ１００５とを含んでもよい。また、前記ノード機器１０００は、ユーザインタフェース１００３、及び少なくとも１つの通信バス１００２をさらに含んでもよい。ここで、通信バス１００２は、これらのコンポーネント間の接続・通信を実現するために用いられる。ここで、ユーザインタフェース１００３は、ディスプレイ（Ｄｉｓｐｌａｙ）、キーボード（Ｋｅｙｂｏａｒｄ）を含んでもよい。ユーザインタフェース１００３は、標準的な有線インタフェース、無線インタフェースをさらに含んでもよい。本願の実施例では、ネットワークインタフェース１００４は、標準的な有線インタフェース、無線インタフェース（例えば、ＷＩ－ＦＩインタフェース）を含んでもよい。メモリ１００５は、高速ＲＡＭメモリであってもよいし、例えば、少なくとも１つのディスクメモリのような不揮発性メモリ（ｎｏｎ－ｖｏｌａｔｉｌｅ ｍｅｍｏｒｙ）であってもよい。本願の実施例では、メモリ１００５は、上記プロセッサ１００１から離れて配置された少なくとも１つの記憶装置であってもよい。図１０に示すように、コンピュータ記憶媒体としてのメモリ１００５には、オペレーティングシステム、ネットワーク通信モジュール、ユーザインタフェースモジュール、及び機器制御アプリケーションが含まれてもよい。

【0124】

該ノード機器１０００のネットワークインタフェース１００４は、ブロックチェーンにおける他のノード機器（例えば、アプリケーションサーバ）に接続されてもよく、ユーザインタフェース１００３は、ディスプレイ（Ｄｉｓｐｌａｙ）、キーボード（Ｋｅｙｂｏａｒｄ）を含んでもよい。図１０に示すノード機器１０００において、ネットワークインタフェース１００４は、ネットワーク通信機能を提供することができ、ユーザインタフェース１００３は、主に、ユーザに入力インタフェースを提供するものであり、プロセッサ１００１は、メモリ１００５に記憶されたアプリケーションを呼び出すことにより、
実行ノードから送信された、第１サーバノードに対するファームウェア更新要求を受信するステップであって、前記ファームウェア更新要求には、少なくとも、前記第１サーバノードの更新バージョンパラメータが含まれる、ステップと、
前記ファームウェア更新要求に応じてスマートコントラクトを呼び出し、前記スマートコントラクトに基づいて、ブロックチェーンから、前記第１サーバノードに関連付けられたファームウェアバージョン更新履歴及びファームウェアバージョン配布履歴を取得するステップであって、前記ファームウェアバージョン配布履歴が、コンセンサスメカニズムに基づいて前記ブロックチェーンにおける配布ノードによって決定されたものである、ステップと、
前記ファームウェアバージョン更新履歴、前記ファームウェアバージョン配布履歴、前記更新バージョンパラメータに基づいて、前記ファームウェア更新要求の正当性を決定するステップと、を実現するために用いられてもよい。

【0125】

理解すべきものとして、本願の実施例に説明されたノード機器１０００は、上記の対応する実施例における前記スマートコントラクトに基づくデータ処理方法についての説明を実現することができ、上記の対応する実施例における前記スマートコントラクトに基づくデータ処理装置１についての説明を実現することもできるが、ここでは説明を省略する。また、同様の方法による有益な効果についても、説明を省略する。

【0126】

また、ここで指摘すべきものとして、本願の実施例では、コンピュータ記憶媒体も提供されており、前記コンピュータ記憶媒体には、上記で言及されたスマートコントラクトに基づくデータ処理装置１が実行するコンピュータプログラムが記憶され、前記コンピュータプログラムには、プログラム命令が含まれ、前記プロセッサは、前記プログラム命令を実行すると、上記の対応する実施例における前記スマートコントラクトに基づくデータ処理方法についての説明を実現することができるため、ここでは説明を省略する。また、同様の方法による有益な効果についても、説明を省略する。本願に係るコンピュータ記憶媒体の実施例に開示されていない技術的詳細については、本願の方法の実施例の説明を参照されたい。

【0127】

当業者であれば理解できるように、上記実施例の方法における全部又は一部の手順は、コンピュータプログラムによって関連ハードウェアに指示することにより実現されてもよい。前記プログラムは、コンピュータ読み取り可能な記憶媒体に記憶されてもよい。該プログラムは、実行されると、上記のような各方法の実施例の手順を含むことができる。ここで、前記記憶媒体は、磁気ディスク、光ディスク、読み出し専用メモリ（ＲＯＭ：Ｒｅａｄ－Ｏｎｌｙ Ｍｅｍｏｒｙ）、又はランダムアクセスメモリ（ＲＡＭ：Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）などであってもよい。

【0128】

上記で開示されたのは、本願の好ましい実施例にすぎず、もちろん、これをもって本願の特許範囲を限定することはできないので、本願の特許請求の範囲に基づいて行われる均等な変更も本願の保護範囲内に含まれる。

【符号の説明】

【0129】

１０ａ 配布ノード
１０ｂ 配布ノード
１０ｃ 配布ノード
２０ａ コントラクトノード
２０ｂ コントラクトノード
３０ａ 実行ノード
３０ｂ 実行ノード
４０ａ サーバノード
４０ｂ サーバノード
４０ｃ サーバノード
１００ 配布層
２００ コントラクト層
３００ 実施層

【図1】

【図2】

【図3】

【図4a】

【図4b】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】