JP7398000B2 - ブロックチェーンに基づくデータ検出方法及び装置並びにコンピュータ装置及びプログラム - Google Patents

ブロックチェーンに基づくデータ検出方法及び装置並びにコンピュータ装置及びプログラム Download PDF

Info

Publication number
JP7398000B2
JP7398000B2 JP2022539369A JP2022539369A JP7398000B2 JP 7398000 B2 JP7398000 B2 JP 7398000B2 JP 2022539369 A JP2022539369 A JP 2022539369A JP 2022539369 A JP2022539369 A JP 2022539369A JP 7398000 B2 JP7398000 B2 JP 7398000B2
Authority
JP
Japan
Prior art keywords
verification
consensus node
block
consensus
target
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2022539369A
Other languages
English (en)
Other versions
JP2023509889A (ja
Inventor
ヤン,チャンチン
Original Assignee
テンセント・テクノロジー・(シェンジェン)・カンパニー・リミテッド
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by テンセント・テクノロジー・(シェンジェン)・カンパニー・リミテッド filed Critical テンセント・テクノロジー・(シェンジェン)・カンパニー・リミテッド
Publication of JP2023509889A publication Critical patent/JP2023509889A/ja
Application granted granted Critical
Publication of JP7398000B2 publication Critical patent/JP7398000B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/1097Protocols in which an application is distributed across nodes in the network for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/12Applying verification of the received information
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/08Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0876Network architectures or network communication protocols for network security for authentication of entities based on the identity of the terminal or configuration, e.g. MAC address, hardware or software configuration or device fingerprint
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/55Detecting local intrusion or implementing counter-measures
    • G06F21/554Detecting local intrusion or implementing counter-measures involving event detection and direct action
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/10Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/10Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/101Access control lists [ACL]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Power Engineering (AREA)
  • Software Systems (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Debugging And Monitoring (AREA)
  • Databases & Information Systems (AREA)
  • Storage Device Security (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Data Mining & Analysis (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Quality & Reliability (AREA)

Description

本出願は、2020年05月21日に中国専利局に出願した、出願番号が202010433284.9である中国特許出願に基づく優先権を主張するものであり、その全内容を参照によりここに援用する。
本出願は、ブロックチェーンの技術分野に関し、特に、ブロックチェーンに基づくデータ検出方法及び装置並びにコンピュータ装置及びプログラムに関する。
コンピュータネットワークの継続的な発達に伴い、ブロックチェーンに関する技術はますます成熟してきている。ブロックチェーンに関する適用シナリオでは、1つのブロックをチェーンにアップロード(配置ともいう)するときに、コンセンサスノードが該ブロックを検証することが要され、ほとんどのコンセンサスノードの該ブロックにする検証に合格(パス(pass)ともいう)した場合にのみ、該ブロックはチェーンにアップロードすることができる。
関連技術では、1つのブロックチェーンネットワークに通常複数のコンセンサスノードがあり、該複数のコンセンサスノードには悪意のあるコンセンサスノードが存在する場合がある。該悪意のあるコンセンサスノードは偽トランザクションデータを含む異常ブロックを生成し、該異常ブロックをチェーンにアップロードするように要求することができ、また、悪意のあるコンセンサスノードは異なる異常ブロックをチェーンにアップロードするように継続的に送信して要求することができる。ブロックチェーンネットワークのコンセンサスメカニズムによれば、異常ブロックは通常検証に合格することができない。しかし、悪意のあるコンセンサスノードが継続的に異常ブロックを提出してチェーンへのアップロードを要求しようとすると、異常ブロックが検証に合格したことを避けることができないため、ブロックチェーンネットワークのネットワークセキュリティが低下する恐れがある。
本出願の実施例は、少なくとも、ブロックチェーンネットワークのネットワークセキュリティを向上させることができる、ブロックチェーンに基づくデータ検出方法及び装置並びにコンピュータ装置及びプログラムを提供することを課題とする。
本出願の実施例では、目標(ターゲット)コンセンサスノードが実行する、ブロックチェーンに基づくデータ検出方法が提供され、それは、
検証待ちブロックに対する少なくとも2つのコンセンサスノードのそれぞれのブロック検証結果を取得し;
前記検証待ちブロックに対する少なくとも2つのコンセンサスノードのそれぞれのブロック検証結果のうち、合法(legal)検証結果の第一の数(第一数量)及び違法(illegal(不正ともいう))検証結果の第二の数(第二数量)をカウントし;
第一の数及び第二の数に基づいて、検証待ちブロックについての目標検証結果を決定し、目標検証結果は合法検証結果又は違法検証結果であり;
目標検証結果と、検証待ちブロックに対する少なくとも2つのコンセンサスノードのそれぞれのブロック検証結果とを比較し、比較結果に基づいて各コンセンサスノードに対応する過去検証異常回数に対してそれぞれ更新を行い、目標コンセンサスノードによりカウントされる各コンセンサスノードの目標検証異常回数を取得し;及び
目標コンセンサスノードによりカウントされる各コンセンサスノードの目標検証異常回数に基づいて、少なくとも2つのコンセンサスノードのうちの異常コンセンサスノードを決定するステップを含む。
本出願の実施例では、目標コンセンサスノードに適用される、ブロックチェーンに基づくデータ検出装置がさらに提供され、それは、
検証待ちブロックに対する少なくとも2つのコンセンサスノードのそれぞれのブロック検証結果を取得するように構成される結果取得モジュール;
検証待ちブロックに対する少なくとも2つのコンセンサスノードのそれぞれのブロック検証結果のうち、合法検証結果の第一の数及び違法検証結果の第二の数をカウントするように構成される数量統計モジュール;
第一の数及び第二の数に基づいて、検証待ちブロックについての目標検証結果を決定するように構成される結果決定モジュールであって、目標検証結果は合法検証結果又は違法検証結果である、結果決定モジュール;
目標検証結果と、検証待ちブロックに対する少なくとも2つのコンセンサスノードのそれぞれのブロック検証結果とを比較し、比較結果に基づいて各コンセンサスノードに対応する過去検証異常回数に対してそれぞれ更新を行い、目標コンセンサスノードによりカウントされる各コンセンサスノードの目標検証異常回数を取得するように構成される回数決定モジュール;及び
目標コンセンサスノードによりカウントされる各コンセンサスノードの目標検証異常回数に基づいて、少なくとも2つのコンセンサスノードのうちの異常コンセンサスノードを決定するように構成されるノード決定モジュールを含む。
そのうち、結果取得モジュールは、
検証待ちブロックを生成するように構成されるブロック生成ユニット;
検証待ちブロックを各コンセンサスノードにブロードキャストし、各コンセンサスノードが待ちブロックに対してブロック検証を行うようにさせるように構成されるブロードキャストユニット;及び
検証待ちブロックに対する各コンセンサスノードのブロック検証結果を取得するように構成される結果取得ユニットを含む。
そのうち、結果決定モジュールは、
第一の数が第二の数よりも大きいときに、合法検証結果を目標検証結果と決定するように構成される第一結果決定ユニット;及び
第一の数が第二の数よりも小さいときに、違法検証結果を目標検証結果と決定するように構成される第二結果決定ユニットを含む。
そのうち、数量統計モジュールは、
各コンセンサスノードに対応するブロック検証票数をそれぞれ取得するように構成される票数取得ユニット;
検証待ちブロックに対する少なくとも2つのコンセンサスノードのそれぞれのブロック検証結果のうち、ブロック検証結果が合法検証結果であるコンセンサスノードを第一コンセンサスノードと決定するように構成される第一ノード決定ユニット;
検証待ちブロックに対する少なくとも2つのコンセンサスノードのそれぞれのブロック検証結果のうち、ブロック検証結果が違法検証結果であるコンセンサスノードを第二コンセンサスノードと決定するように構成される第二ノード決定ユニット;及び
第一コンセンサスノードに対応するブロック検証票数の和(合計)を第一の数と決定し、第二コンセンサスノードに対応するブロック検証票数の和(合計)を第二の数と決定するように構成される数量決定ユニットを含む。
そのうち、目標コンセンサスノードは少なくとも2つのコンセンサスノードにより投票メカニズムに基づいて投票することで決定され、
データ検出装置は、さらに、
検証待ちブロックのブロック高さを取得し、ブロック高さと検証開始高さとの間の高度差を取得するように構成される高度差取得モジュールであって、検証開始高さとは、投票メカニズムに基づいて目標コンセンサスノードが投票で決定されたときに、目標コンセンサスノードが持つブロックの最高ブロック高さを指す、高度差取得モジュール;及び
高度差が高度差閾値よりも大きいときに、各コンセンサスノードに投票要求を送信し、各コンセンサスノードが投票要求及び投票メカニズムに基づいて目標コンセンサスノードに対して再び投票を行うようにさせるために構成される再投票モジュールを含む。
そのうち、回数決定モジュールは、
目標検証結果と、検証待ちブロックに対する少なくとも2つのコンセンサスノードのそれぞれのブロック検証結果とを比較するように構成される結果比較ユニット;
検証待ちブロックに対する少なくとも2つのコンセンサスノードのそれぞれのブロック検証結果のうち、目標検証結果とは異なるブロック検証結果に対応するコンセンサスノードを衝突コンセンサスノードと決定するように構成される衝突決定ユニット;
少なくとも2つのコンセンサスノードのうち、衝突コンセンサスノード以外のコンセンサスノードをマッチングコンセンサスノードと決定するように構成されるマッチング決定ユニット;及び
衝突コンセンサスノードに対応する過去検証異常回数に単位異常回数を増やし、衝突コンセンサスノードに対応する目標検証異常回数を取得し、マッチングコンセンサスノードに対応する過去検証異常回数をマッチングコンセンサスノードに対応する目標検証異常回数と決定するように構成される回数決定ユニットを含み、
検証待ちブロックが先行ブロックを有しないときに、各コンセンサスノードに対応する過去検証異常回数は何れもデフォルト初期回数であり、検証待ちブロックが先行ブロックを有するときに、各コンセンサスノードに対応する過去検証異常回数は、先行ブロックに対する少なくとも2つのコンセンサスノードのブロック検証結果に基づいて得られた各コンセンサスノードの検証異常回数である。
そのうち、ノード決定モジュールは、
目標コンセンサスノードによりカウントされる各コンセンサスノードの目標検証異常回数のうち、回数(数値)が異常回数閾値よりも大きい目標検証異常回数に対応するコンセンサスノードを審査待ちコンセンサスノードと決定するように構成される審査待ちユニット;
各コンセンサスノードによりカウントされる審査待ちコンセンサスノードの目標検証異常回数を取得するように構成される回数取得ユニット;及び
各コンセンサスノードによりカウントされる審査待ちコンセンサスノードの目標検証異常回数が前記異常コンセンサスノードの決定条件を満足するときに、審査待ちコンセンサスノードを異常コンセンサスノードと決定するように構成される異常決定ユニットを含む。
そのうち、異常決定ユニットは、
各コンセンサスノードによりそれぞれカウントされる審査待ちコンセンサスノードの目標検証異常回数のうち、回数(数値)が異常回数閾値よりも大きい目標検証異常回数に対応するコンセンサスノードのノード数を取得するように構成されるノード数量取得サブユニット;及び
ノード数と、少なくとも2つのコンセンサスノードのノード総数との間の比率が比率閾値よりも大きいときに、前記各コンセンサスノードによりカウントされる前記審査待ちコンセンサスノードの目標検証異常回数が前記異常コンセンサスノードの決定条件を満足すると決定するように構成される異常決定サブユニットを含む。
そのうち、データ検出装置はさらに、
ノード数と、少なくとも2つのコンセンサスノードのノード総数との間の比率が比率閾値以下であるときに、前記各コンセンサスノードによりカウントされる前記審査待ちコンセンサスノードの目標検証異常回数が前記異常コンセンサスノードの決定条件を満足しないと決定し、審査待ちコンセンサスノードを正常コンセンサスノードと決定するように構成される。
そのうち、データ検出装置はさらに、
各コンセンサスノードに異常コンセンサスノードをブロードキャストし、各コンセンサスノードが異常コンセンサスノードをノードブラックリストに追加するようにさせるように構成され、
ノードブラックリストは、異常コンセンサスノードにより開始されるブロックトランザクションを受信することを拒否するために用いられる。
本出願の実施例では、記憶器及び処理器を含むコンピュータ装置がさらに提供され、記憶器にはコンピュータプログラムが記憶されており、コンピュータプログラムは処理器により実行されるときに、本出願の実施例により提供される上述のブロックチェーンに基づくデータ検出方法を実現する。
本出願の実施例ではさら、コンピュータ可読記憶媒体が提供され、該コンピュータ可読記憶媒体にはコンピュータプログラムが記憶されており、該コンピュータプログラムはプログラム命令を含み、該プログラム命令は処理器により実行されるときに本出願の実施例により提供される上述ブロックチェーンに基づくデータ検出方法を実現する。
本出願の実施例では、検証待ちブロックに対する少なくとも2つのコンセンサスノードのそれぞれのブロック検証結果を取得し;検証待ちブロックに対する少なくとも2つのコンセンサスノードのそれぞれのブロック検証結果のうち、合法検証結果の第一の数及び違法検証結果の第二の数をカウントし;第一の数及び第二の数に基づいて、検証待ちブロックについての目標検証結果を決定し、目標検証結果は合法検証結果又は違法検証結果であり;目標検証結果と、検証待ちブロックに対する少なくとも2つのコンセンサスノードのそれぞれのブロック検証結果との比較を行い、比較結果に基づいて各コンセンサスノードにそれぞれ対応する過去検証異常回数に対して更新を行い、目標コンセンサスノードによりカウントされる各コンセンサスノードの目標検証異常回数を取得し;及び、目標コンセンサスノードによりカウントされる各コンセンサスノードの目標検証異常回数に基づいて、少なくとも2つのコンセンサスノードのうちの異常コンセンサスノードを決定する。このようにして、少なくとも2つのコンセンサスノードのうちから異常コンセンサスノードを検出することができ、ブロックチェーンネットワークにおける異常コンセンサスノードを自発的に発見することで、その後、該異常コンセンサスノードに対して対応する処理(例えば、ブラックリストに追加する処理)を行い、ブロックチェーンネットワークのネットワークセキュリティを向上させることができる。
本出願の実施例により提供されるネットワークアーキテクチャを示す図である。 本出願の実施例により提供されるデータ検出のシナリオを示す図である。 本出願の実施例により提供されるブロックチェーンに基づくデータ検出方法のフローチャートである。 本出願の実施例により提供される検証異常回数取得のシナリオを示す図である。 本出願の実施例により提供される異常コンセンサスノード検出のシナリオを示す図である。 本出願の実施例により提供される異常コンセンサスノードをキックアウトする方法のフローチャートである。 本出願の実施例により提供されるブロックチェーンに基づくデータ検出装置の構成を示す図である。 本出願の実施例により提供されるコンピュータ装置の構成を示す図である。
以下、本出願の図面と併せて本出願における技術案を明確かつ完全に説明する。明らかのように、説明される実施例は本出願の一部の実施例に過ぎず、すべての実施例ではない。本出願の実施例に基づいて、当業者が創造性のある労働をせずに取得したすべての他の実施例も本出願の保護範囲に属する。
また、以下の説明では、“幾つかの実施例”のような表現があり、それはすべての可能な実施例のサブセットを指すが、理解すべきは、“幾つかの実施例”はすべての可能な実施例の同じサブセット又は異なるサブセットであっても良く、かつ矛盾の無い限り、互いに組み合わせることができるということである。
さらに、本出願に使用される用語“第一/第二/第三”は、類似した対象を区別するためにのみ用いられ、対象についての特定の順序を表さない。理解すべきは、“第一/第二/第三”は、許可される場合、特定の順序又は前後の順序を交換することで、ここで説明される本出願の実施例がここで図示又は説明される以外の順序に従って実施されるようにさせることができるということである。
ブロックチェーン(Blockchain)は分散型データストレージ、ポイントツーポイント伝送、コンセンサスメカニズム、暗号化アルゴリズムなどのコンピュータ技術の新しい応用モードである。ブロックチェーンは本質的に1つの分散型(decentralization)データベースであり、暗号学的方法を使用して関連付けられるように生成される一連のデータブロックであり、各データブロックは1バッチのネットワークトランザクションの情報を含み、その情報の有効性(偽造防止)を検証し、かつ次の1つのブロックを生成するために用いられる。ブロックチェーンはブロックチェーンの基盤プラットフォーム、プラットフォームプロダクトサービス層及び応用サービス層を含んでも良い。1つのブロックチェーンネットワークには複数の(即ち、少なくとも2つの)コンセンサスノードが含まれても良く、該複数のコンセンサスノードは、ブロックチェーンネットワークにおいて生成されるブロックに対してコンセンサスを得ることで、生成されるブロックをチェーンにアップロードすることができるかを決定するために用いられる。実際の適用シナリオでは、ブロックチェーンネットワークにおける複数のコンセンサスノードに異常コンセンサスノードが存在し、該異常コンセンサスノードがブロックチェーンネットワークのネットワークセキュリティを脅かす可能性がある。そのため、本出願の実施例では、主に、如何にブロックチェーンネットワークの複数のコンセンサスノードのうちの異常コンセンサスノードを検出するかについて説明し、具体的には以下を参照する。
図1を参照し、それは本出願の実施例により提供されるネットワークアーキテクチャを示す図である。図1に示すように、該ネットワークアーキテクチャを示す図に示されているのは1つのブロックチェーンネットワークであっても良く、該ブロックチェーンネットワークには複数のコンセンサスノード及び複数の業務ノードが含まれても良く、該複数のコンセンサスノード及び該複数の業務ノードはすべてブロックチェーンネットワークにおけるブロックチェーンノードである。そのうち、上述の複数のコンセンサスノードはノード集合106aにおけるコンセンサスノード101a、コンセンサスノード102a、コンセンサスノード103a、コンセンサスノード104a及びコンセンサスノード105aであり得る。上述の複数の業務ノードはノード集合109aにおける業務ノード107a、業務ノード108aなどの複数の業務ノードを含み得る。なお、本出願の実施例における複数とは2つ又は2つ以上を指す。
実際には、ブロックチェーンネットワークにおけるコンセンサスノードもブロックチェーンネットワークにおける業務ノードであり、理解すべきは、コンセンサスノードはブロックチェーンネットワークにおけるすべての業務ノードのうちから選択される、ブロックをパッケージ化し、かつブロックに対してコンセンサスを得る能力を有するブロックチェーンノードであるということである。図1におけるネットワークアーキテクチャを示す図では、ノード集合106aにおけるブロックチェーンノード(上述のコンセンサスノード101a、コンセンサスノード102a、コンセンサスノード103a、コンセンサスノード104a及びコンセンサスノード105aを含む)はブロックチェーンネットワークにおけるコンセンサスノードであり、ノード集合109aにおけるブロックチェーンノード(上述の業務ノード107a、業務ノード108aなどの複数の業務ノードを含む)はブロックチェーンネットワークの中でコンセンサスノード以外のブロックチェーンノードである。ブロックチェーンネットワークにおけるコンセンサスノードは、業務ノード(図1のネットワークアーキテクチャを示す図におけるすべてのブロックチェーンノードを含む)により生成されるトランザクションデータをブロックにパッケージ化し、そして、該ブロックに対してすべてのコンセンサスノードの間でコンセンサス検証を行うことができ、また、検証に合格したブロックをチェーンにアップロードすることができ、検証に合格しないブロックをチェーンにアップロードすることができない。
幾つかの実施例において、上述の図1のネットワークアーキテクチャを示す図における1つのブロックチェーンノードとは1つのサーバー、複数のサーバー、端末装置などを指しても良い。そのうち、ブロックチェーンノードを構成するサーバーは独立した物理サーバーであっても良く、複数の物理サーバーからなるサーバー群又は分散システムであっても良く、さらにクラウド・コンピューティング・サービスを提供するクラウドサーバーであっても良い。端末装置はスマートフォン、タブレットパソコン、ノートパソコン、デスクトップコンピュータ、スマートスピーカー、スマートウォッチなどであり得るが、これらに限定されない。端末装置とサーバーは有線又は無線通信の方式で直接又は間接的に接続されても良いが、本出願はこれについて限定しない。
本出願の実施例はさらにクラウドセキュリティに関する技術分野に関する。そのうち、クラウドセキュリティ(Cloud Security)とは、クラウド・コンピューティング・ビジネス・モデル・アプリケーションに基づくセキュリティソフトウェア、ハードウェア、ユーザー、機構、セキュリティ・クラウド・プラットフォームの総称を指す。クラウドセキュリティは并列処理、グリッドコンピューティング、未知ウイルスの動作判断などの新しいテクノロジーや概念を融合(統合)しており、網状の大量のクライアントによってネットワークにおけるソフトウェア動作の異常を監視し、インターネット上のトロイや悪意のあるプログラムの最新情報を取得し、サービス端に送信して自動分析や処理を行ってもらい、そして、ウイルスやトロイに対しての解決案を各クライアントにデリバリする。
クラウドセキュリティの主な研究の方向性は次のとおりであり、即ち、1.クラウドコンピューティングセキュリティ:主に、如何にクラウド自体及びクラウド上の各種のアプリケーションのセキュリティ、例えば、クラウドコンピュータシステムセキュリティ、ユーザーデータの安全なストレージ及び分離、ユーザーアクセス認証、情報伝送セキュリティ、ネットワーク攻撃保護、コンプライアンス監査などを保障するかを研究し;2.セキュリティインフラストラクチャのクラウド化:主に、如何にクラウドコンピューティングを採用してセキュリティインフラストラクチャリソースの新しい構築及び統合を行い、セキュリティ保護メカニズムを最適化するかを研究し、例えば、クラウドコンピューティング技術による超大規模なセキュリティイベントの構築、情報の収集及びプラットフォームの処理を含み、これにより、膨大な情報の収集や相関分析を実現し、ネットワーク全体のセキュリティイベントの把握・制御能力及びリスクの制御・回避能力を向上させ;3.クラウドセキュリティサービス:主に、クラウドコンピューティングプラットフォームに基づいてユーザーに提供する様々なセキュリティサービス、例えば、アンチウイルスサービスなどを研究する。
そのうち、本出願は主にクラウドセキュリティの技術分野におけるクラウドセキュリティサービスに関する。該クラウドセキュリティサービスは本出願では主に、ブロックチェーンネットワークにおける複数のコンセンサスノードのうちの異常コンセンサスノードを検出し、検出した異常コンセンサスノードをブロックする処理を行うことで、より安全なクラウドサービスをユーザーに提供するように具現化される。該クラウドサービスは、例えば、ユーザーにより提出されるトランザクションデータに対してコンセンサスを得てチェーンにアップロードすることができる。
本出願では、如何に各コンセンサスノードのブロックに対する検証結果に基づいて、ブロックチェーンネットワークにおける複数のコンセンサスノードのうちの異常コンセンサスノード(悪意のあるコンセンサスノード(malicious node)又は単に悪意コンセンサスノードと称されても良い)を見つけるかを重点的に説明し、具体的には以下の図2に対応する実施例で説明されるプロセスを参照する。
図2を参照し、それは本出願により提供されるデータ検出のシナリオを示す図である。図2に示すように、ここで上述の図1におけるコンセンサスノード101a、コンセンサスノード102a、コンセンサスノード103a、コンセンサスノード104a及びコンセンサスノード105aのうちの異常コンセンサスノードを検出することを例として説明する。まず、コンセンサスノード101a、コンセンサスノード102a、コンセンサスノード103a、コンセンサスノード104a及びコンセンサスノード105aは互いに投票してリーダーコンセンサスノード(目標コンセンサスノードとも呼ばれる)を選出することができ、該リーダーコンセンサスノードは、すべてのコンセンサスノードのうちの不審(疑わしい)コンセンサスノードを発見し、すべてのコンセンサスノードをリードして該不審コンセンサスノードに対してアービトレーション(仲裁)を開始(発起)し、そして、アービトレーション結果に基づいて該不審コンセンサスノードをブロックチェーンネットワークからキックアウトする必要があるかを判断するために用いられる。ここで、コンセンサスノード101aはリーダーコンセンサスノードとして選出されているとする。
幾つかの実施例において、1つのブロックに対してコンセンサスを得る度に、各コンセンサスノードは何れも各コンセンサスノードのブロックに対しての検証結果に基づいて、各コンセンサスノードの検証異常回数をカウントすることができ、各コンセンサスノードによりカウントされた各コンセンサスノードの検証異常回数を目標検証異常回数と称しても良い。そのうち、毎回、1つのブロックに対してコンセンサスを得た後に、対応ブロックに対応する各コンセンサスノードの目標検証異常回数をカウントして取得することができ;後の1つのブロックに対応する各コンセンサスノードの目標検証異常回数が前(直前)の1つのブロックに対応する各コンセンサスノードの目標検証異常回数をもとに更新することで取得され、前の1つのブロックに対応する各コンセンサスノードの目標検証異常回数を後の1つのブロックに対応する各コンセンサスノードの過去検証異常回数と称することができる。ここで、コンセンサスノード101aがブロックsに対してコンセンサスを得た後に各コンセンサスノードの目標検証異常回数をカウントすることを例にとって説明する。理解すべきは、各コンセンサスノードが各コンセンサスノードの目標検証異常回数をカウントするプロセスはコンセンサスノード101aが各コンセンサスノードの目標検証異常回数をカウントするプロセスと同じであり、また、各ブロックのコンセンサス結果に基づいて更新することで各コンセンサスノードの検証異常回数を取得する原理もブロックsのコンセンサス結果に基づいて更新することで各コンセンサスノードの検証異常回数を取得する原理と同じであるということである。具体的には以下を参照する。
ブロックsに対してコンセンサスを得るときに、各コンセンサスノードは何れもブロックsに対して検証を行うことができ、各コンセンサスノードは何れも自分がブロックsに対して検証を行った後の検証結果を取得することができる。該検証結果は合法検証結果及び違法検証結果を含み得る。そのうち、合法検証結果はブロックsに対しての合法性検証に合格したことを指示するために用いられ、違法検証結果はブロックsに対しての合法性検証に合格しなかったことを指示するために用いられる。実際の実施にあたって、1つのブロックに複数のトランザクションデータがあっても良いため、或るコンセンサスノードがブロックsに対して検証を行って合法検証結果を取得したことは、該コンセンサスノードは、ブロックsに含まれるトランザクションデータはすべて本物で信頼できるということを検証したことを表す。逆に、或るコンセンサスノードがブロックsに対して検証を行って違法検証結果を取得することは、該コンセンサスノードは、ブロックsには偽りのトランザクションデータが含まれており、即ち、ブロックsに含まれるトランザクションデータは偽物で信頼できないということを検証したことを表す。コンセンサスノード101aは、他のコンセンサスノードがブロックsに対して検証を行った後の検証結果を取得することができる。コンセンサスノード101aは、取得したすべてのコンセンサスノードのブロックsに対してのコンセンサス結果のうち、合法検証結果の数及び正検証結果の数をカウントすることができる。合法検証結果の数が正検証結果の数よりも大きいときに、合法検証結果をブロックsについての目標検証結果とすることができる。逆に、合法検証結果の数が違法検証結果の数よりも小さいときに、違法検証結果をブロックsについての目標検証結果とすることができる。該目標検証結果は、ブロックチェーンネットワークにおけるすべてのコンセンサスノードによってブロックsに対して検証を行うことで得られる最終検証結果である。
一例として、コンセンサスノード101aは、コンセンサスノード102aのブロックsに対しての検証結果、コンセンサスノード103aのブロックsに対しての検証結果、コンセンサスノード104aのブロックsに対しての検証結果、及びコンセンサスノード105aのブロックsに対しての検証結果を取得することができる。仮に、コンセンサスノード101aのブロックsに対しての検証結果が違法検証結果であり、コンセンサスノード101aが取得した、コンセンサスノード102aのブロックsに対しての検証結果が違法検証結果であり、コンセンサスノード101aが取得した、コンセンサスノード103aのブロックsに対しての検証結果が違法検証結果であり、コンセンサスノード101aが取得した、コンセンサスノード104aのブロックsに対しての検証結果が合法検証結果であり、コンセンサスノード101aが取得した、コンセンサスノード105aのブロックsに対しての検証結果が合法検証結果であるとする。この場合、コンセンサスノード101aが取得したすべてのコンセンサス結果のうち、違法検証結果の数が3であり、合法検証結果の数が2であり、違法検証結果の数3が合法検証結果の数2よりも大きいため、コンセンサスノード101aは違法検証結果をブロックsの目標検証結果とすることができる。
そのうち、コンセンサスノード101aが最初に記録した、各コンセンサスノードの初期の検証異常回数をデフォルト初期回数と称しても良く、該デフォルト初期回数は事前設定されても良く、例えば、0に設定され得る。コンセンサスノード101aは各コンセンサスノードのブロックsに対しての検証結果と目標検証結果との比較を行うことができ、比較によって、或るコンセンサスノード(例えば、コンセンサスノード102a)のブロックsに対しての検証結果がブロックsの目標検証結果とは異なることを得たときに、コンセンサスノード101aはコンセンサスノード102aの初期の検証異常回数に1を加算してコンセンサスノード102aの目標検証異常回数を取得することができる。比較によって、或るコンセンサスノード(例えば、コンセンサスノード103a)のブロックsに対しての検証結果がブロックsの目標検証結果と同じであることを得たときに、コンセンサスノード101aはコンセンサスノード103aの初期の検証異常回数を不変に維持し、即ち、コンセンサスノード103aの初期の検証異常回数をコンセンサスノード103aの目標検証異常回数とすることができる。理解すべきは、コンセンサスノード101aが各コンセンサスノードによってブロックsの次の1つのブロックの検証結果に基づいて各コンセンサスノードの検証異常回数を更新するときに、ブロックsの検証結果に基づいて更新された後の各コンセンサスノードの検証異常回数をこのときの各コンセンサスノードの初期の検証異常回数とすることができるということである。換言すれば、前(直前)の1つのブロックの検証結果に基づいて更新された後の各コンセンサスノードの検証異常回数は、その次の1つのブロックの検証結果に基づいて各コンセンサスノードの検証異常回数を更新するときに各コンセンサスノードの初期の検証異常回数である。
幾つかの実施例において、ブロックsの1つ前のブロックをブロックsの先行ブロックと呼んでも良く、コンセンサスノード101aがリーダーコンセンサスノードとされている間(期間)に、ブロックsがブロックチェーンネットワークにおいてコンセンサスを得ようとする1番目のブロックである場合、このときに、ブロックsは先行ブロックを有しない。コンセンサスノード101aがリーダーコンセンサスノードとされている間に、ブロックsがブロックチェーンネットワークにおいてコンセンサスを得ようとする1番目のブロックでない場合、ブロックsは先行ブロックを有する。ブロックsが先行ブロックを有しない場合、このときに、各コンセンサスノードの過去検証異常回数は設定された各コンセンサスノードのデフォルト初期回数(例えば、0)である。ブロックsが先行ブロックを有する場合、このときに、各コンセンサスノードの過去検証異常回数は、各コンセンサスノードによってブロックsの先行ブロックの検証結果に基づいて得られた各コンセンサスノードの目標検証異常回数であり、即ち、ブロックsに対応する各コンセンサスノードの過去検証異常回数は、ブロックsの先行ブロックに対応する各コンセンサスノードの目標検証異常回数である。そのうち、各コンセンサスノードによってブロックsの先行ブロックの検証結果に基づいて該先行ブロックに対応する各コンセンサスノードの目標検証異常回数を取得するプロセスは、各コンセンサスノードによってブロックsの検証結果に基づいてブロックsに対応する各コンセンサスノードの目標検証異常回数を取得するプロセスと同じである。
幾つかの実施例において、1つの単位時間を設定しても良く、例えば、該単位時間は1時間、1日、1週間などであり得る。該単位時間内でコンセンサスを得る必要のある複数のブロックを生成しても良く、コンセンサスノード101aが各ブロックの検証結果に基づいて更新することで各コンセンサスノードの目標検証異常回数を取得するプロセスは上述のコンセンサスノード101aがブロックsの検証結果に基づいて更新することで各コンセンサスノードの目標検証異常回数を取得するプロセスと同じである。そうすると、該単位時間の後に、コンセンサスノード101aは該単位時間内のすべてのブロックの検証結果に基づいて各コンセンサスノードの検証異常回数に対して更新を行った後の最終結果を取得することができ、即ち、該単位時間内でコンセンサスを得る最後の1つのブロックに対応する各コンセンサスノードの目標検証異常回数を取得することができる。
例えば、ここでコンセンサスノード101aが取得した最終結果は結果101bであっても良い。結果101bは、コンセンサスノード101aが最終的に記録した、コンセンサスノード101aについての目標検証異常回数が5回、コンセンサスノード101aが最終的に記録した、コンセンサスノード102aについての目標検証異常回数が10回、コンセンサスノード101aが最終的に記録した、コンセンサスノード103aについての目標検証異常回数が15回、コンセンサスノード101aが最終的に記録した、コンセンサスノード104aについての目標検証異常回数が21回、コンセンサスノード101aが最終的に記録した、コンセンサスノード105aについての目標検証異常回数が17回であることを含む。
そのうち、1つの異常回数閾値を設定しても良く、例えば、該異常回数閾値を20回と設定することができ、該異常回数閾値は、単位時間内でコンセンサスノードの目標検証異常回数が正常範囲内にある最大値を表す。仮に異常回数閾値が20回であるとする場合、ステップ102bにおいて、コンセンサスノード101aは、コンセンサスノード104aの目標検証異常回数即ち21回が異常回数閾値即ち20回よりも大きいことを検出した。なお、コンセンサスノード102a、コンセンサスノード103a、コンセンサスノード104a及びコンセンサスノード105aは何れも上述のコンセンサスノード101aと同様のプロセスで、各コンセンサスノードの単位時間内の目標検証異常回数を記録することができる。言い換えれば、各コンセンサスノードは何れも自分がカウントした各コンセンサスノードの目標検証異常回数を記録することができ、各コンセンサスノードは何れも結果101bと類似した結果を記録することができる。コンセンサスノード101aにより、コンセンサスノード104aの目標検証異常回数が異常回数閾値よりも大きいと検出されたときに、コンセンサスノード101aは他のコンセンサスノードからこのときに他のコンセンサスノードがカウントしたコンセンサスノード104aの目標検証異常回数を取得することができる。
例えば、コンセンサスノード101aはコンセンサスノード102aが記録したコンセンサスノード104aの目標検証異常回数を取得することができ、コンセンサスノード101aはコンセンサスノード103aが記録したコンセンサスノード104aの目標検証異常回数を取得することができ、コンセンサスノード101aはコンセンサスノード104aが記録した、コンセンサスノード104aについての目標検証異常回数を取得することができ、コンセンサスノード101aはコンセンサスノード105aが記録したコンセンサスノード104aの目標検証異常回数を取得することができる。
幾つかの実施例において、コンセンサスノード101aは、カウントされた各コンセンサスノードの目標検証異常回数のうち、回数が異常回数閾値よりも大きい目標検証異常回数に対応するコンセンサスノードを審査待ちコンセンサスノードと決定し;各コンセンサスノードによりカウントされる審査待ちコンセンサスノードの目標検証異常回数を取得し;各コンセンサスノードによりカウントされる審査待ちコンセンサスノードの目標検証異常回数が異常コンセンサスノードの決定条件を満足したときに、審査待ちコンセンサスノードを異常コンセンサスノードと決定することができる。
ここで、コンセンサスノード101aは以下のような方式で各コンセンサスノードによりカウントされる審査待ちコンセンサスノードの目標検証異常回数が異常コンセンサスノードの決定条件を満足したかを判断することができる。
各コンセンサスノードによりそれぞれカウントされる審査待ちコンセンサスノードの目標検証異常回数のうち、回数が異常回数閾値よりも大きい目標検証異常回数に対応するコンセンサスノードのノード数を取得し、そして、該ノード数と、少なくとも2つのコンセンサスノードのノード総数との間の比率を取得し;該比率が比率閾値よりも大きい場合、各コンセンサスノードによりカウントされる審査待ちコンセンサスノードの目標検証異常回数が異常コンセンサスノードの決定条件を満足したと決定し;そうでない場合、異常コンセンサスノードの決定条件を満足しないと決定する。
幾つかの実施例において、コンセンサスノード101aは各コンセンサスノードが記録した目標検証異常回数を取得した後に、以下のような方式でコンセンサスノードが異常コンセンサスノードであるかを判定することができ、即ち、ステップ103bを実行することができ、ステップ103bは次のことを含んでも良い。
コンセンサスノード101aは、取得した、各コンセンサスノードが記録したコンセンサスノード104aの目標検証異常回数のうち、異常回数閾値を超えた目標検証異常回数に対応するコンセンサスノードのノード数をカウントする。ここでさらに1つのノード数閾値を設定しても良く、該ノード数がノード数閾値よりも大きい場合、コンセンサスノード104aが異常コンセンサスノードであると判定し(即ち、結果104bを得る);該ノード数が該ノード数閾値以下である場合、コンセンサスノード104aが異常コンセンサスノードではなく、正常コンセンサスノードであると判定する(即ち、結果105bを得る)。コンセンサスノード101aによりコンセンサスノード104aが異常コンセンサスノードであると判定されたときに、コンセンサスノード101aは他のコンセンサスノード(コンセンサスノード102a、コンセンサスノード103a、コンセンサスノード104a及びコンセンサスノード105aを含む)にコンセンサスノード104aをブロードキャストすることで、他のコンセンサスノードがコンセンサスノード104aをノードブラックリストに追加するようにさせると同時に、コンセンサスノード101aはコンセンサスノード104aを自分のノードブラックリストにも追加する(即ち、ステップ106b)。
各コンセンサスノードがコンセンサスノード104aをノードブラックリストに追加した後に、コンセンサスノード104aをブロックチェーンネットワークからキックアウトしたことを意味し、その後、ブロックチェーンネットワークにおけるコンセンサスノードはコンセンサスノード104aにより開始されるブロックトランザクションを受信することができず、該ブロックトランザクションはブロックをチェーンにアップロードする要求などであっても良い。理解すべきは、各コンセンサスノードがコンセンサスノード104aをノードブラックリストに追加した後に、図1におけるコンセンサスノードのネットワークアーキテクチャ(コンセンサスノード101a、コンセンサスノード102a、コンセンサスノード103a、コンセンサスノード104a及びコンセンサスノード105aを含む)が図2におけるコンセンサスノードのネットワークアーキテクチャ107b(コンセンサスノード101a、コンセンサスノード102a、コンセンサスノード103a及びコンセンサスノード105aを含む)に変わったことに相当する。
本出願の実施例により提供される方法を採用することで、ブロックチェーンネットワークにおける複数のコンセンサスノードのうちの異常コンセンサスノードを自発的に発見し、該異常コンセンサスノードをブロックチェーンネットワークからキックアウトすることができるため、ブロックチェーンネットワークのネットワークセキュリティを保障することができる。
図3を参照し、それは本出願の実施例により提供されるブロックチェーンに基づくデータ検出方法のフローチャートである。図3に示すように、該方法は以下のステップを含んでも良い。
ステップS101:目標コンセンサスノードが検証待ちブロックに対する少なくとも2つのコンセンサスノードのそれぞれのブロック検証結果を取得する。
幾つかの実施例において、目標コンセンサスノードはブロックチェーンネットワークにおける任意の1つのコンセンサスノードであっても良い。そのうち、ブロックチェーンネットワークには複数の(少なくとも2つの)コンセンサスノードがあっても良く、目標コンセンサスノードはブロックチェーンネットワークにおけるすべてのコンセンサスノードにより投票メカニズムに基づいて投票することで選出され得る。一例として、投票メカニズムは次のとおりであっても良い。即ち、1つのコンセンサスノードが2票を持ち、各コンセンサスノードが1票を自分に投じ、1票を他の任意の1つのコンセンサスノードに投じることができる。最後に、各コンセンサスノードの総得票数をカウントし、総得票数が最も高いコンセンサスノードを目標コンセンサスノードとする。例えば、仮に、ブロックチェーンネットワークにコンセンサスノード1、コンセンサスノード2及びコンセンサスノード3があり、コンセンサスノード1がコンセンサスノード1及びコンセンサスノード2に投票し、コンセンサスノード2がコンセンサスノード2及びコンセンサスノード1に投票し、コンセンサスノード3がコンセンサスノード3及びコンセンサスノード1に投票しているとする。この場合、コンセンサスノード1の得票数が3票であり、コンセンサスノード2の得票数が2票であり、コンセンサスノード3の得票数が1票であるため、コンセンサスノード1を目標コンセンサスノードとすることができる。
ブロックチェーンネットワークにおいてコンセンサスを得る必要のあるブロックを検証待ちブロックと総称しても良い。目標コンセンサスノードは1つの単位時間を設定しても良く、該単位時間の開始時間は目標コンセンサスノードが投票により決定された時点であっても良く、該単位時間の時間長は1時間、1日、1週間などであっても良い。該単位時間の時間長は実際の応用シナリオに基づいて決定され得るが、これに限定されない。該単位時間内でブロックチェーンネットワークにおいて複数の検証待ちブロックを生成することができ、前の1つの検証待ちブロックがすべてのコンセンサスノードにより検証された後にのみ次の1つの検証待ちブロックに対しての検証が開始され得る。検証待ちブロックに対してコンセンサスを得るときに、すべてのコンセンサスノードは該検証待ちブロックを検証する必要があり、各コンセンサスノードは該検証待ちブロックを検証した後に何れも検証待ちブロックについてのブロック検証結果を取得することができ、該ブロック検証結果は検証結果と略称されても良い。毎回、1つの検証待ちブロックに対してコンセンサスを得た後に、目標コンセンサスノードはすべての他のコンセンサスノードの該検証待ちブロックに対してのブロック検証結果を取得することができる。
各コンセンサスノードの1つの検証待ちブロックに対してのブロック検証結果を取得することを例にして説明を行う。目標コンセンサスノードは検証待ちブロックを生成することができ、目標コンセンサスノードは生成した該検証待ちブロックを他の各コンセンサスノードにブロードキャストすることができる。他のコンセンサスノードは目標コンセンサスノードによりブロードキャストされた検証待ちブロックを取得し、該検証待ちブロックに対してブロック検証を行い、該検証待ちブロックについてのブロック検証結果を取得することができる。各コンセンサスノードは検証待ちブロックについてのブロック検証結果を取得した後に何れも自分が取得したブロック検証結果を他のコンセンサスノードにブロードキャストすることができる。そのため、すべてのコンセンサスノードは各コンセンサスノードの検証待ちブロックに対してのブロック検証結果を把握することができる。よって、目標コンセンサスノードは各コンセンサスノードの検証待ちブロックに対してのブロック検証結果を取得することもできる。
そのうち、理解すべきは、検証待ちブロックは目標コンセンサスノードにより生成することができるだけでなく、目標コンセンサスノード以外の他のコンセンサスノードにより生成することもできるということである。同様に、検証待ちブロックが他のコンセンサスノードにより生成された場合、検証待ちブロックを生成したコンセンサスノードにより、生成された検証待ちブロックを他のコンセンサスノード(ここで目標コンセンサスノードを含む)にブロードキャストして検証してもらう。このような場合、目標コンセンサスノードは同様に他のコンセンサスノードの検証待ちブロックに対してのブロック検証結果を取得することができる。
ステップS102:検証待ちブロックに対する少なくとも2つのコンセンサスノードのそれぞれのブロック検証結果のうち、合法検証結果の第一の数及び違法検証結果の第二の数をカウントする。
幾つかの実施例において、目標コンセンサスノードは各コンセンサスノードの検証待ちブロックに対してのブロック検証結果に基づいて、各コンセンサスノードの目標検証異常回数をカウントすることができる。そのうち、各コンセンサスノードの目標検証異常回数は各コンセンサスノードが異常コンセンサスノードであるかを判断するために用いられる。以下、如何に1つの検証待ちブロックのブロック検証結果に基づいて、各コンセンサスノードの目標検証異常回数を取得するかを例として説明を行う。理解すべきは、各検証待ちブロックのブロック検証結果に基づいて各コンセンサスノードの目標検証異常回数を取得する原理は同じであるということである。
そのうち、コンセンサスノードが検証待ちブロックに対して検証を行うことで取得したブロック検証結果は合法検証結果であっても良く、又は違法検証結果であっても良い。1つのコンセンサスノードが1つの検証待ちブロックに対して検証を行った後に取得したブロック検証結果は合法検証結果及び違法検証結果のうちの任意の1つの検証結果である。合法検証結果は、コンセンサスノードの検証待ちブロックに対しての検証に合格したことを表し、違法検証結果は、コンセンサスノードの検証待ちブロックに対しての検証に合格しなかったことを表す。1つの検証待ちブロックに複数のトランザクションデータが含まれても良いため、1つの検証待ちブロックに対しての検証に合格したことは、該検証待ちブロック内のトランザクションデータはすべて本物で信頼できるトランザクションデータであるということが検証されたことを表し;逆に、1つの検証待ちブロックに対しての検証に合格しなかったことは、該検証待ちブロック内のトランザクションデータには偽物で信頼できないトランザクションデータが存在するということが検証されたことを表す。
目標コンセンサスノードは、各コンセンサスノード(目標コンセンサスノードを含み、すべてのコンセンサスノードを指す)が検証待ちブロック(1つを指す)に対して検証を行った後のブロック検証結果のうち、合法検証結果の数及び違法検証結果の数をカウントすることができる。カウントした合法検証結果の数を第一の数と称し、カウントした違法検証結果の数を第二の数と称しても良い。一例として、仮に、コンセンサスノード1、コンセンサスノード2及びコンセンサスノード3があり、コンセンサスノード1の検証待ちブロックに対してのブロック検証結果が合法検証結果であり、コンセンサスノード2の検証待ちブロックに対してのブロック検証結果が違法検証結果であり、コンセンサスノード3の検証待ちブロックに対してのブロック検証結果が違法検証結果であるとする場合、合法検証結果の第一の数は1であり、違法検証結果の数は2である。
上述のプロセスにおいて、各コンセンサスノードの持つブロック検証票数が何れもデフォルトで1票である。幾つかの実施例において、ブロックチェーンネットワークにおける各コンセンサスノードは異なるブロック検証票数を有しても良い。例えば、システムは各コンセンサスノードの異なる権威性(authoritativeness)に基づいて各コンセンサスノードのためにブロック検証票数を割り当ても良く、コンセンサスノードの権威性が高いほど、コンセンサスノードのブロック検証票数が多くなる。例えば、仮に、コンセンサスノード1、コンセンサスノード2、コンセンサスノード3、コンセンサスノード4及びコンセンサスノード5があり、コンセンサスノード1、コンセンサスノード2、コンセンサスノード3、コンセンサスノード4及びコンセンサスノード5の権威性が順次高くなるとする場合、コンセンサスノード1、コンセンサスノード2、コンセンサスノード3、コンセンサスノード4及びコンセンサスノード5のブロック検証票数は順次1、2、3、4及び5であっても良い。
そのうち、合法検証結果の第一の数及び違法検証結果の第二の数をカウントするときに、各コンセンサスノードのブロック検証票数に基づいて得ることができる。例えば、すべてのコンセンサスノードのうち、検証待ちブロックに対してのブロック検証結果が合法検証結果であるコンセンサスノードを第一コンセンサスノードと称し;コンセンサスノードのうち、検証待ちブロックに対してのブロック検証結果が違法検証結果であるコンセンサスノードを第二コンセンサスノードと称することができる。すべての第一コンセンサスノードに対応するブロック検証票数を合計して1つの合計値を取得し、そして、該合計値を合法検証結果についての第一の数とすることができる。また、すべての第二コンセンサスノードに対応するブロック検証票数を合計して1つの合計値を取得し、そして、該合計値を違法検証結果についての第二の数とすることができる。
一例として、仮に、コンセンサスノード1、コンセンサスノード2、コンセンサスノード3、コンセンサスノード4及びコンセンサスノード5のブロック検証票数が順次1、2、3、4及び5であっても良く、そのうち、コンセンサスノード1、コンセンサスノード2及びコンセンサスノード3が検証待ちブロックに対して検証を行った後に得たブロック検証結果はすべて違法検証結果であり、コンセンサスノード4及びコンセンサスノード5が検証待ちブロックに対して検証を行った後に得たブロック検証結果はすべて合法検証結果であるとする。この場合、第一コンセンサスノードはコンセンサスノード1、コンセンサスノード2及びコンセンサスノード3を含み、第二コンセンサスノードはコンセンサスノード4及びコンセンサスノード5を含み、そうすると、合法検証結果の第一の数は1+2+3=6であり、違法検証結果の第二の数は4+5=9である。
ステップS103:第一の数及び第二の数に基づいて、検証待ちブロックについての目標検証結果を決定し、目標検証結果は合法検証結果又は違法検証結果である。
幾つかの実施例において、カウントした上述の合法検証結果の第一の数が違法検証結果の第二の数よりも大きいときに、目標コンセンサスノードは合法検証結果を検証待ちブロックの目標検証結果とすることができる。カウントした上述の合法検証結果の第一の数が違法検証結果の第二の数よりも小さいときに、目標コンセンサスノードは違法検証結果を検証待ちブロックの目標検証結果とすることができる。該目標検証結果は、目標コンセンサスノードがカウントした、すべてのコンセンサスノードの検証待ちブロックに対しての最終検証結果を表す。
ステップS104:目標検証結果と、検証待ちブロックに対する少なくとも2つのコンセンサスノードのそれぞれのブロック検証結果とを比較し、比較結果に基づいて各コンセンサスノードに対応する過去検証異常回数に対してそれぞれ更新を行い、目標コンセンサスノードによりカウントされる各コンセンサスノードの目標検証異常回数を取得する。
幾つかの実施例において、検証待ちブロックが複数あっても良く、かつ前の1つの検証待ちブロックに対しての検証が完成した後にのみ、次の1つの検証待ちブロックに対しての検証を開始し得る。そのため、本実施例では目標コンセンサスノードは各コンセンサスノードの各検証待ちブロックに対してのブロック検証結果に基づいて更新することで各検証待ちブロックの目標検証異常回数を得ることができる。各検証待ちブロックに対応するブロック検証結果に基づいて更新することで得られた各コンセンサスノードの検証異常回数は何れも目標検証異常回数と称されても良い。また、各検証待ちブロックに対応するブロック検証結果に基づいて更新することで各コンセンサスノードの目標検証異常回数を取得するときに、すべては各コンセンサスノードの過去検証異常回数をもとに更新を行うのである。複数の検証待ちブロックに検証待ちブロックsが含まれ、かつ目標コンセンサスノードが投票によりリーダーコンセンサスノードとされている間に、検証待ちブロックsがブロックチェーンネットワークにおいて生成される1番目の検証待ちブロックである場合、検証待ちブロックsが先行ブロック(即ち、前の1つのブロック)を有しないことを表し、このときに、各コンセンサスノードの過去検証異常回数は最初に設定される各コンセンサスノードのデフォルト初期回数であり、該デフォルト初期回数は0であっても良い。目標コンセンサスノードが投票によりリーダーコンセンサスノードとされている間に、検証待ちブロックsがブロックチェーンネットワークにおいて生成される1番目の検証待ちブロックでない場合、検証待ちブロックsが先行ブロックを有することを表し、このときに、各コンセンサスノードの過去検証異常回数は検証待ちブロックsの先行ブロックに対応するブロック検証結果に基づいて得られた各コンセンサスノードの目標検証異常回数である。
よって、各コンセンサスノードの検証待ちブロックsに対してのブロック検証結果に基づいて更新することで各コンセンサスノードの目標検証異常回数を得るときに、検証待ちブロックsに対応する比較結果に基づいて、検証待ちブロックsの先行ブロックに対応するブロック検証結果をもとに得られた各コンセンサスノードの目標コンセンサスノードを更新することで、検証待ちブロックsに対応する各コンセンサスノードの目標コンセンサスノードを取得するのである。
更新のプロセスは以下のとおりである。
目標コンセンサスノードが最初に記録した各コンセンサスノードの過去検証異常回数(即ち、デフォルト初期回数)はすべて0である。目標コンセンサスノードは、各コンセンサスノードの検証待ちブロックに対してのブロック検証結果が目標検証結果と同じであるかを比較し、目標コンセンサスノードの比較により得られた、ブロック検証結果が目標検証結果とは異なるコンセンサスノードを衝突コンセンサスノードと称して良い。目標コンセンサスノードの比較により得られた、ブロック検証結果が目標検証結果と同じであるコンセンサスノードをマッチングコンセンサスノードと称しても良い。衝突コンセンサスノードに対応する過去検証異常回数に単位異常回数を加算することで、衝突コンセンサスノードの目標検証異常回数を取得することができる。そのうち、単位異常回数は事前設定されても良く、例えば、1であっても良い。マッチングコンセンサスノードに対応する過去検証異常回数を直接、マッチングコンセンサスノードの目標検証異常回数とすることができる。なお、次の1つの検証待ちブロックのブロック検証結果を使用して各コンセンサスノードの目標検証異常回数を取得するときに、前(直前)の1つの検証待ちブロックのブロック検証結果に基づいて得られた各コンセンサスノードの目標検証異常回数を各コンセンサスノードの過去検証異常回数とするのである。
一例として、図4を参照し、それは本出願の実施例により提供される検証異常回数取得のシナリオを示す図である。図4に示すように、領域101cに示されているのは目標コンセンサスノードが最初に記録した各コンセンサスノード(目標コンセンサスノードを含んでも良い)の過去検証異常回数であり、すべては0である。目標コンセンサスノードはコンセンサスノード1、コンセンサスノード2、コンセンサスノード3、コンセンサスノード4及びコンセンサスノード5のうちの任意の1つのコンセンサスノードであっても良い。領域101cには、コンセンサスノード1の最初の過去検証異常回数が0、コンセンサスノード2の最初の過去検証異常回数が0、コンセンサスノード3の最初の過去検証異常回数が0、コンセンサスノード4の最初の過去検証異常回数が0、コンセンサスノード5の最初の過去検証異常回数が0であることが示されている。
続いて、検証待ちブロック1に対してコンセンサスを得るときに、目標コンセンサスノードが取得した、コンセンサスノード1の検証待ちブロック1に対するブロック検証結果は合法検証結果であり、コンセンサスノード2の検証待ちブロック1に対するブロック検証結果は合法検証結果であり、コンセンサスノード3の検証待ちブロック1に対するブロック検証結果は違法検証結果であり、コンセンサスノード4の検証待ちブロック1に対するブロック検証結果は違法検証結果であり、コンセンサスノード5の検証待ちブロック1に対するブロック検証結果は合法検証結果である。仮に、各コンセンサスノードのブロック検証票数が何れも1であるとすると、検証待ちブロック1の合法検証結果についての第一の数は3であり、検証待ちブロック1の違法検証結果についての第二の数は2である。この場合、第一の数3が第二の数2よりも大きいので、検証待ちブロック1の目標検証結果は合法検証結果である。
このときに、各コンセンサスノードの過去検証異常回数は領域101cに示されている回数である。コンセンサスノード1、コンセンサスノード2及びコンセンサスノード5が検証した、検証待ちブロック1についてのブロック検証結果がすべて検証待ちブロック1の目標検証結果と同じであるため、領域101cにおけるコンセンサスノード1の過去検証異常回数0を直接、コンセンサスノード1の目標検証異常回数とし、領域101cにおけるコンセンサスノード2の過去検証異常回数0を直接、コンセンサスノード2の目標検証異常回数とし、領域101cにおけるコンセンサスノード5の過去検証異常回数0を直接、コンセンサスノード5の目標検証異常回数とすることができる。
仮に、単位異常回数が1回であるとし、コンセンサスノード3及びコンセンサスノード4が検証した、検証待ちブロック1についてのブロック検証結果が何れも検証待ちブロック1の目標検証結果とは異なるので、領域101cにおけるコンセンサスノード3の過去検証異常回数0に単位異常回数1を加算した結果1をコンセンサスノード3の目標検証異常回数とすることができる。領域101cにおけるコンセンサスノード4の過去検証異常回数0に単位異常回数1に加算した結果1をコンセンサスノード4の目標検証異常回数とすることができる。
よって、検証待ちブロック1に対応するブロック検証結果に基づいて得られた各コンセンサスノードの目標検証異常回数は領域102cに示されている回数であり、領域102cに示されている各コンセンサスノードの目標検証異常回数は次のとおりであり、即ち、コンセンサスノード1の目標検証異常回数は0、コンセンサスノード2の目標検証異常回数は0、コンセンサスノード3の目標検証異常回数は1、コンセンサスノード4の目標検証異常回数は1、コンセンサスノード5の目標検証異常回数は0である。
続いて、検証待ちブロック2が検証待ちブロック1の次の1つの検証待ちブロックであり、即ち、検証待ちブロック1は検証待ちブロック2の先行ブロックである。そのうち、コンセンサスノード1の検証待ちブロック2に対するブロック検証結果は合法検証結果、コンセンサスノード2の検証待ちブロック2に対するブロック検証結果は合法検証結果、コンセンサスノード3の検証待ちブロック2に対するブロック検証結果は違法検証結果、コンセンサスノード4の検証待ちブロック2に対するブロック検証結果は合法検証結果、コンセンサスノード5の検証待ちブロック2に対するブロック検証結果は合法検証結果である。よって、検証待ちブロック2の合法検証結果についての第一の数が4、検証待ちブロック2の違法検証結果についての第二の数が1であるので、検証待ちブロック2の目標検証結果は合法検証結果である。
このときに、領域102cに示されている各コンセンサスノードの目標検証異常回数を各コンセンサスノードの過去検証異常回数とするのである。よって、コンセンサスノード1、コンセンサスノード2、コンセンサスノード4及びコンセンサスノード5の検証待ちブロック2に対するブロック検証結果が何れも検証待ちブロック2の目標検証結果と同じであるため、領域102cにおけるコンセンサスノード1の過去検証異常回数0をコンセンサスノード1のこのときの目標検証異常回数とし、領域102cにおけるコンセンサスノード2の過去検証異常回数0をコンセンサスノード2のこのときの目標検証異常回数とし、領域102cにおけるコンセンサスノード4の過去検証異常回数1をコンセンサスノード4のこのときの目標検証異常回数とし、領域102cにおけるコンセンサスノード5の過去検証異常回数0をコンセンサスノード5のこのときの目標検証異常回数とすることができる。
コンセンサスノード3の検証待ちブロック2に対してのブロック検証結果が検証待ちブロック2の目標検証結果とは異なるので、領域102cにおけるコンセンサスノード3の過去検証異常回数1に単位異常回数1を加算して2を取得し、そして、2をコンセンサスノード3のこのときの目標検証異常回数とすることができる。
よって、検証待ちブロック2に対応するブロック検証結果に基づいて得られた各コンセンサスノードの目標検証異常回数は領域103cに示されている回数であり、領域103cに示されている各コンセンサスノードの目標検証異常回数は次のとおりであり、即ち、コンセンサスノード1の目標検証異常回数は0、コンセンサスノード2の目標検証異常回数は0、コンセンサスノード3の目標検証異常回数は2、コンセンサスノード4の目標検証異常回数は1、コンセンサスノード5の目標検証異常回数は0である。
続いて、検証待ちブロック3が検証待ちブロック2の次の1つの検証待ちブロックであり、即ち、検証待ちブロック2は検証待ちブロック3の先行ブロックである。そのうち、コンセンサスノード1の検証待ちブロック3に対するブロック検証結果は合法検証結果であり、コンセンサスノード2の検証待ちブロック3に対するブロック検証結果は合法検証結果であり、コンセンサスノード3の検証待ちブロック3に対するブロック検証結果は違法検証結果であり、コンセンサスノード4の検証待ちブロック3に対するブロック検証結果は合法検証結果であり、コンセンサスノード5の検証待ちブロック3に対するブロック検証結果は違法検証結果である。よって、検証待ちブロック3の合法検証結果についての第一の数が3、検証待ちブロック3の違法検証結果についての第二の数が2であるため、検証待ちブロック3の目標検証結果は合法検証結果である。
このときに、領域103cに示されている各コンセンサスノードの目標検証異常回数を各コンセンサスノードの過去検証異常回数とするのである。よって、コンセンサスノード1、コンセンサスノード2及びコンセンサスノード4の検証待ちブロック3に対するブロック検証結果がすべて検証待ちブロック3の目標検証結果と同じであるので、領域103cにおけるコンセンサスノード1の過去検証異常回数0をコンセンサスノード1のこのときの目標検証異常回数とし、領域103cにおけるコンセンサスノード2の過去検証異常回数0をコンセンサスノード2のこのときの目標検証異常回数とし、領域103cにおけるコンセンサスノード4の過去検証異常回数1をコンセンサスノード4のこのときの目標検証異常回数とすることができる。
コンセンサスノード3及びコンセンサスノード5の検証待ちブロック3に対するブロック検証結果がすべて検証待ちブロック3の目標検証結果とは異なるため、領域103cにおけるコンセンサスノード3の過去検証異常回数2に単位異常回数1を加算して3を取得し、そして、3をコンセンサスノード3のこのときの目標検証異常回数とし、領域103cにおけるコンセンサスノード5の過去検証異常回数0に単位異常回数1を加算して1を取得し、そして、1をコンセンサスノード5のこのときの目標検証異常回数とすることができる。
よって、検証待ちブロック3に対応するブロック検証結果に基づいて得られた各コンセンサスノードの目標検証異常回数は領域104cに示されている回数であり、領域104cに示されている各コンセンサスノードの目標検証異常回数は次のとおりであり、即ち、コンセンサスノード1の目標検証異常回数は0、コンセンサスノード2の目標検証異常回数は0、コンセンサスノード3の目標検証異常回数は3、コンセンサスノード4の目標検証異常回数は1、コンセンサスノード5の目標検証異常回数は1である。同様に、検証待ちブロック3の後に検証待ちブロックがさらにある場合、その後の検証待ちブロックに対応するブロック検証結果に基づいて各コンセンサスノードの目標検証異常回数を得る原理は上述のプロセスで説明された原理と同じである。
ステップS105:目標コンセンサスノードによりカウントされる各コンセンサスノードの目標検証異常回数に基づいて、少なくとも2つのコンセンサスノードのうちの異常コンセンサスノードを決定する。
幾つかの実施例において、目標コンセンサスノードは、自分がカウントした各コンセンサスノードの目標検証異常回数に基づいて、ブロックチェーンネットワークにおける複数のコンセンサスノードのうちの異常コンセンサスノードを検証することができ、該異常コンセンサスノードはブロックチェーンネットワークのネットワークセキュリティを脅かすことができる。そのうち、目標コンセンサスノードが複数のコンセンサスノードのうちの異常コンセンサスノードを検出するに使用する各コンセンサスノードの目標検証異常回数は何れも現在カウントされた各コンセンサスノードの最新の目標検証異常回数である。例えば、仮に、上述の図4における検証待ちブロック3が現在に最も近い時間に生成及び検証された1つの検証待ちブロックであり、即ち、このときに、検証待ちブロック3の後に次の1つの検証待ちブロックがないとする場合、目標コンセンサスノードは、領域104cに示されている各コンセンサスノードの目標検証異常回数に基づいて、このときに、複数のコンセンサスノードに異常コンセンサスノードが存在するかを判断することができる。
目標コンセンサスノードはカウントされた各コンセンサスノードの最新の目標検証異常回数をリアルタイムで検出することができ、単位時間(上述のステップS101における単位時間)内(単位時間の終了時刻に達する前の任意の1つの時刻であっても良い)で、目標コンセンサスノードが記録した或るコンセンサスノードの目標検証異常回数が異常回数閾値よりも大きいことを発見したときに、目標コンセンサスノードは該コンセンサスノードを審査待ちコンセンサスノードとすることができる。そのうち、理解すべきは、ブロックチェーンネットワークにおける各コンセンサスノードは何れも自ら各コンセンサスノードの目標検証異常回数をカウントすることができ、各コンセンサスノードが各コンセンサスノードの目標検証異常回数をカウントするプロセスは上述の目標コンセンサスノードが各コンセンサスノードの目標検証異常回数をカウントするプロセスと同じであるということである。よって、理解すべきは、各コンセンサスノードは何れも審査待ちコンセンサスノードの目標検証異常回数をカウントしているということである。
目標コンセンサスノードは他のコンセンサスノードからこのときにそれぞれカウントされた審査待ちコンセンサスノードの目標検証異常回数を取得することができる。そのうち、目標コンセンサスノードが他のコンセンサスノードから審査待ちコンセンサスノードについての目標検証異常回数を得るときに、取得したのは現在他のコンセンサスノードがカウントした最新の審査待ちコンセンサスノードの目標検証異常回数でもある。一例として、ブロックチェーンネットワークにおいて目標コンセンサスノード以外にコンセンサスノード1、コンセンサスノード2及びコンセンサスノード3がさらにある場合、目標コンセンサスノードは、コンセンサスノード1がカウントした最新の審査待ちコンセンサスノードの目標検証異常回数、コンセンサスノード2がカウントした最新の審査待ちコンセンサスノードの目標検証異常回数、及びコンセンサスノード3がカウントした最新の審査待ちコンセンサスノードの目標検証異常回数を取得することができる。
目標コンセンサスノードは、取得した、各コンセンサスノードによりカウントされた審査待ちコンセンサスノードの目標検証異常回数のうち、回数が異常回数閾値よりも大きい目標検証異常回数に対応するコンセンサスノードのノード数をカウントすることができる。一例として、ブロックチェーンネットワークにおけるコンセンサスノードが目標コンセンサスノード、コンセンサスノード1、コンセンサスノード2及びコンセンサスノード3を含み、そのうち、目標コンセンサスノード、コンセンサスノード1及びコンセンサスノード2によりカウントされた審査待ちコンセンサスノードの目標検証異常回数がすべて異常回数閾値よりも大きく、コンセンサスノード3がカウントした審査待ちコンセンサスノードの目標検証異常回数が異常回数閾値よりも小さい場合、目標コンセンサスノードがカウントすることで得た上述のノード数は3である。
目標コンセンサスノードはさらに、上述のカウントしたノード数と、すべてのコンセンサスノードのノード総数との間の比率を取得することができ、該比率が比率閾値よりも大きい場合、目標コンセンサスノードは該審査待ちコンセンサスノードを異常コンセンサスノードと判定することができる。該比率が該比率閾値以下の場合、目標コンセンサスノードは該審査待ちコンセンサスノードを正常コンセンサスノードと判定することができる。そのうち、上述の比率閾値は実際の状況に応じて事前設定されても良く、例えば、比率閾値は1/2であっても良く、これは、半数を超えたコンセンサスノードがカウントした審査待ちコンセンサスノードの目標検証異常回数がすべて異常回数閾値よりも大きい場合、審査待ちコンセンサスノードが異常コンセンサスノードであると判定することができるということを意味する。
そのうち、各コンセンサスノードは何れも1つのノードブラックリストをメンテナンスすることができ、ノードブラックリストに追加されたコンセンサスノードは対応するコンセンサスノードにトランザクションを開始することができず、該トランザクションは或るブロックをチェーンにアップロードするように要求するトランザクションであっても良い。例えば、コンセンサスノード1がコンセンサスノード2を自分のノードブラックリストに追加した場合、コンセンサスノード2はコンセンサスノード1にトランザクションを開始することができない。目標コンセンサスノードにより審査待ちコンセンサスノードが異常コンセンサスノードであると判定された場合、目標コンセンサスノードは該異常コンセンサスノードを他の各コンセンサスノードにブロードキャストすることで、他の各コンセンサスノードが何れも該異常コンセンサスノードをノードブラックリストに追加するようにさせ、また、目標コンセンサスノードも該異常コンセンサスノードを自分のノードブラックリストに追加する。各コンセンサスノードがすべて異常コンセンサスノードをノードブラックリストに追加した場合、該異常コンセンサスノードがブロックチェーンネットワークからキックアウトされていることを表す。異常コンセンサスノードをブロックチェーンネットワークからキックアウトすることにより、ブロックチェーンネットワークのネットワークセキュリティを向上させることができる。
幾つかの実施例において、目標コンセンサスノードが、各コンセンサスノードによりカウントされた審査待ちコンセンサスノードの目標検証異常回数に基づいて、審査待ちコンセンサスノードが正常コンセンサスノードであると判定したときに、この場合、その後、単位時間内で目標コンセンサスノードによりカウントされた審査待ちコンセンサスノードの目標検証異常回数に1回増やす(これは事前設定されても良く、例えば、2回増やしても良い)度に、目標コンセンサスノードは、再び、他のコンセンサスノードからそれぞれカウントされた審査待ちコンセンサスノードについての目標検証異常回数を取得し、そして、取得した他のコンセンサスノードによりそれぞれカウントされた審査待ちコンセンサスノードについての目標検証異常回数に基づいて、審査待ちコンセンサスノードが異常コンセンサスノードであるかを判断することができる。このプロセスは上述の単位時間の終了時刻まで継続的に行われ得る。
幾つかの実施例において、目標コンセンサスノードにより、上述の単位時間の終止時刻に達していると検出されたときに、目標コンセンサスノードは今までカウントした各コンセンサスノードの目標検証異常回数をクリアし、各コンセンサスノードの目標検証異常回数を0にリセットすることができる。目標コンセンサスノードはさらに、他のコンセンサスノードに、その今までカウントした各コンセンサスノードの目標検証異常回数をも0にリセットするように通知することができる。各コンセンサスノードによりカウントされた各コンセンサスノードの目標検証異常回数を0にリセットした後に、各コンセンサスノードは該リセットの時刻を次の1つの単位時間の開始時刻とし、再び各コンセンサスノードの目標検証異常回数のカウントを開始し、そして、該次の1つの単位時間内で、目標コンセンサスノードにより再び複数のコンセンサスノードのうちの異常コンセンサスノードを検出することができる。検出のプロセスは上述のプロセスと同じである。
幾つかの実施例において、本実施例における実行主体である目標コンセンサスノードについて、所定期間の後に再び投票することにより選出することができる。そのうち、該所定期間は事前設定の時間長であっても良く、トランザクション待ちブロックのブロック高さに基づいて決定されても良い。例えば、目標コンセンサスノードが投票により決定された時刻を開始時刻とし、該開始時刻から24時間(5時間、30時間などであっても良い)に達した時点に、ブロックチェーンネットワークにおけるすべてのコンセンサスノードが再び投票メカニズムに基づいて投票を行うことで新しい目標コンセンサスノードを選出しても良い。実際には、再び投票することにより選出される新しい目標コンセンサスノードは元の目標コンセンサスノードでる可能性もある。
あるいは、目標コンセンサスノードは検証待ちブロック(該検証待ちブロックは該目標コンセンサスノードが異常コンセンサスノードを検出する期間に生成するブロックである)の最高ブロック高さを検出することができ、該最高ブロック高さと検証開始高さとの間の高度差が高度差閾値(事前設定されても良い)以上であるときに、目標コンセンサスノードは他のコンセンサスノードに投票要求を送信することで、ブロックチェーンネットワークにおけるすべてのコンセンサスノードが該投票要求及び投票メカニズムに基づいて再び投票することで新しい目標コンセンサスノードを選出するようにさせることができる。そのうち、上述の検証開始高さとは、目標コンセンサスノードがすべてのコンセンサスノードの投票により決定された時刻に、目標コンセンサスノードの台帳に存在するブロックの最高ブロック高さを指す。
一例として、目標コンセンサスノードが投票により決定されたときに所持するブロックの最高ブロック高さが10であり、目標コンセンサスノードが投票により決定された時点を開始時刻とし、その後、所定時間を経過して新しい20個のブロック(該20個のブロックは何れも検証待ちブロックである)が生成される。このときに、目標コンセンサスノードが所持するブロックはトータルで10+20=30個であり、即ち、検証待ちブロックの最高ブロック高さは30であり、検証開始高さは10であり、上述の高度差は20である。高度差閾値が20である場合、目標コンセンサスノードは他のコンセンサスノードに投票要求を送信することで、再び投票することで新しい目標コンセンサスノードを選出するようにさせることができる。
図5を参照し、それは本出願の実施例により提供される異常コンセンサスノード検出のシナリオを示す図である。図5に示すように、仮に、目標コンセンサスノードがコンセンサスノード1であり、目標コンセンサスノードによりカウントされた各コンセンサスノードの目標検証異常回数が領域101dに示されており、次のとおりであり、即ち、コンセンサスノード1の目標検証異常回数が5回、コンセンサスノード2の目標検証異常回数が10回、コンセンサスノード3の目標検証異常回数が13回、コンセンサスノード4の目標検証異常回数が16回、コンセンサスノード5の目標検証異常回数が11回であるとする。異常回数閾値が15回である場合、目標コンセンサスノードはそのカウントしたコンセンサスノード4の目標検証異常回数が異常回数閾値を超えたことを検出することができ、このときに、目標コンセンサスノードはコンセンサスノード4を審査待ちコンセンサスノードとすることができる(ステップ102dのようである)。
続いて、目標コンセンサスノードは、コンセンサスノード2からコンセンサスノード2がカウントしたコンセンサスノード4の目標検証異常回数、コンセンサスノード3からコンセンサスノード3がカウントしたコンセンサスノード4の目標検証異常回数、コンセンサスノード4からコンセンサスノード4がカウントしたコンセンサスノード4の目標検証異常回数、コンセンサスノード5からコンセンサスノード5がカウントしたコンセンサスノード4の目標検証異常回数を取得することができる。ここで、目標コンセンサスノードが取得した、各コンセンサスノードによりカウントされたコンセンサスノード4の目標検証異常回数は領域103dに示されており、次のとおりであり、即ち、コンセンサスノード1が記録したコンセンサスノード4の目標検証異常回数は16回、コンセンサスノード2が記録したコンセンサスノード4の目標検証異常回数は18回、コンセンサスノード3が記録したコンセンサスノード4の目標検証異常回数は16回、コンセンサスノード4が記録したコンセンサスノード4の目標検証異常回数は6回、コンセンサスノード5が記録したコンセンサスノード4の目標検証異常回数は17回である。そうすると、目標検証異常回数が異常回数閾値15よりも大きいコンセンサスノードのノード数は4であり(コンセンサスノード1、コンセンサスノード2、コンセンサスノード3及びコンセンサスノード5を含む)、該ノード数とコンセンサスノードのノード総数5と間の比率は4/5であり、仮に、比率閾値が1/2であるとすると、4/5が1/2よりも大きいので、目標コンセンサスノードは、コンセンサスノード4が異常コンセンサスノードであると判定することができる(ステップ106dのようである)。目標コンセンサスノードはコンセンサスノード4を他のコンセンサスノードにブロードキャストすることで、各コンセンサスノードが何れもコンセンサスノード4を自分のノードブラックリストに追加するようにさせることができ(ステップ107dのようである)、これにより、コンセンサスノード4をブロックチェーンネットワークからキックアウトする目的を達成することができる。
本出願の実施例を適用することにより、少なくとも2つのコンセンサスノードのうちから異常コンセンサスノードを検出することができ、ブロックチェーンネットワークにおける異常コンセンサスノードを自発的に発見し、その後、該異常コンセンサスノードに対して対応する処理(例えば、ブラックリストに追加する処理)を行うことで、ブロックチェーンネットワークのネットワークセキュリティを向上させることができる。
図6を参照し、それは本出願の実施例により提供される異常コンセンサスノードをキックアウトする方法のフローチャートである。図6に示すように、該方法は以下のステップを含んでも良い。
ステップS201:ブロックチェーンネットワークにおけるコンセンサスノードがブロックをパッケージ化する。
幾つかの実施例において、ブロックチェーンネットワークにおける任意の1つのコンセンサスノードがブロックをパッケージ化することができ、ここで、ブロックパッケージ化操作を行うコンセンサスノードを目標コンセンサスノードと称し、パッケージ化されたブロックを検証待ちブロックとする。
ステップS202:ブロックをブロードキャストする。
幾つかの実施例において、検証待ちブロックをパッケージ化するコンセンサスノードは、パッケージ化された検証待ちブロックを他のコンセンサスノードにブロードキャストすることで、他のコンセンサスノードがブロードキャストされた検証待ちブロックに対してブロック検証を行うようにさせることができ、また、ブロック検証が行われた後に、検証待ちブロックについてのブロック検証結果を得ることができる。
ステップS203:他のノード検証結果を収集する。
幾つかの実施例において、目標コンセンサスノードはブロックチェーンネットワークにおける他のコンセンサスノードの検証待ちブロックに対する検証結果(即ち、ブロック検証結果)を収集することができる。
ステップS204:他のノードの検証結果に基づいて、ブロックに対してコンセンサスを得ていると判断した場合、ブロックを提出し、そうでない場合、ブロックを提出しない。
幾つかの実施例において、上述プロセスは1つのブロックに対してコンセンサスを得るプロセスであり、コンセンサスを得ていることとは、半数を超えたコンセンサスノードの検証待ちブロックに対してのブロック検証結果が合法検証結果であることを指す。目標コンセンサスノードにより、検証待ちブロックに対してコンセンサスを得ていると検出された場合、目標コンセンサスノードは検証待ちブロックをチェーンにアップロードし、即ち、自分の台帳に追加することができる。目標コンセンサスノードにより、検証待ちブロックに対してのコンセンサスを取得しなかったと検出された場合、目標コンセンサスノードは検証待ちブロックをチェーンにアップロードすることができない。
ステップS205:各ノードの投票結果をカウントする。
幾つかの実施例において、ステップS205はステップS204と並列した1つのステップであり、ここで、各ノードの投票結果をカウントするとは、各コンセンサスノードの検証待ちブロックに対するブロック検証結果をカウントすることを指す。目標コンセンサスノードは、各コンセンサスノードの検証待ちブロックに対するブロック検証結果に基づいてカウントすることで各コンセンサスノードの目標検証異常回数を得ることができる。このプロセスについては上述のステップS101-ステップS104を参照することができる。
ステップS206:単位時間内に異常なノード検証結果があるかどうかを検出する。
幾つかの実施例において、目標コンセンサスノードは、単位時間内にカウントされた各コンセンサスノードの目標検証異常回数のうち、異常回数閾値よりも大きい検証異常回数があるかを検出することができる。ある場合、異常回数閾値よりも大きい目標検証異常回数に対応するコンセンサスノードのノード検証結果は異常であり、該コンセンサスノードは上述の審査待ちコンセンサスノードとすることができる。
ステップS207:ノードのシンセリティー・アービトレーション(sincerity
arbitration)を開始する。
幾つかの実施例において、シンセリティー・アービトレーションを開始することは投票を開始することであり、目標コンセンサスノードは他のコンセンサスノードに投票を要求し、即ち、審査待ちコンセンサスノードが異常コンセンサスノードであるかについての投票をリクエストすることができる。
ステップS208:他のノードのアービトレーション結果を取集する。
幾つかの実施例において、上述のシンセリティー・アービトレーションの実現方式は次のとおりであり、即ち、目標コンセンサスノードが他のコンセンサスノードによりカウントされた該審査待ちコンセンサスノードについての目標検証異常回数を取得し、目標コンセンサスノードは各コンセンサスノードによりカウントされた審査待ちコンセンサスノードについての目標検証異常回数に基づいて、複数のコンセンサスノードに異常コンセンサスノードがあるかを判断することができる。
ステップS209:コンセンサスを得る。
幾つかの実施例において、目標コンセンサスノードがカウントすることによって、大部分のコンセンサスノード(例えば、半数を超えたコンセンサスノード)によりカウントされた審査待ちコンセンサスノードの目標検証異常回数がすべて異常回数閾値よりも大きいことを得た場合、コンセンサスノードの間でコンセンサスが得られており、審査待ちコンセンサスノードが異常コンセンサスノードであることが合意されていることを意味する。
ステップS210:ブロードキャストすることで悪意ノードをキックアウトする。
幾つかの実施例において、悪意ノードは異常コンセンサスノードであり、目標コンセンサスノードは他のコンセンサスノードに異常コンセンサスノード(即ち、上述の審査待ちコンセンサスノード)をブロードキャストすることで、各コンセンサスノードが何れも該異常コンセンサスノードをノードブラックリストに追加するようにさせ、これにより、異常コンセンサスノードをブロックチェーンネットワークからキックアウトする目的を達成することができる。
本出願の実施例を適用することにより、少なくとも2つのコンセンサスノードのうちから異常コンセンサスノードを検出することができ、ブロックチェーンネットワークにおける異常コンセンサスノードを自発的に発見し、その後、該異常コンセンサスノードに対して対応する処理(例えば、ブラックリストに追加する処理)を行うこと、ブロックチェーンネットワークのネットワークセキュリティを向上させることができる。
図7を参照し、それは本出願の実施例により提供されるブロックチェーンに基づくデータ検出装置の構成を示す図である。幾つかの実施例において、該ブロックチェーンに基づくデータ検出装置はソフトウェア、例えば、コンピュータ装置で実行される1つのコンピュータプログラム(プログラムコードを含む)により実現されても良く、例えば、該ブロックチェーンに基づくデータ検出装置は1つのアプリケーションソフトウェアであっても良い。もちろん、該装置はさらに、ハードウェア、例えば、ハードウェア復号化プロセッサ形式の処理器により実現されても良く、例えば、ハードウェア復号化プロセッサ形式の処理器は1つ又は複数のASIC(Application
Specific Integrated Circuit)、DSP、PLD(Programmable Logic Device)、CPLD(Complex Programmable Logic Device)、FPGA(Field-Programmable Gate Array)又は他の電子素子を採用しても良く、また、幾つかの実施例において、該装置はさらに、ソフトウェアとハードウェアの組み合わせの方式で実現されても良い。
該データ検出装置は本出願の実施例により提供される方法における対応ステップを実行することができる。該データ検出装置はさらに目標コンセンサスノードに設けられても良く、図7に示すように、該データ検出装置1は結果取得モジュール11、数量統計モジュール12、結果決定モジュール13、回数決定モジュール14及びノード決定モジュール15を含んでも良い。
結果取得モジュール11は、検証待ちブロックに対する少なくとも2つのコンセンサスノードのそれぞれのブロック検証結果を取得するように構成される。
数量統計モジュール12は、検証待ちブロックに対する少なくとも2つのコンセンサスノードのそれぞれのブロック検証結果のうち、合法検証結果の第一の数及び違法検証結果の第二の数をカウントするように構成される。
結果決定モジュール13は、第一の数及び第二の数に基づいて、検証待ちブロックについての目標検証結果を決定するように構成され、目標検証結果は合法検証結果又は違法検証結果である。
回数決定モジュール14は、目標検証結果と、検証待ちブロックに対する少なくとも2つのコンセンサスノードのそれぞれのブロック検証結果とを比較し、比較結果に基づいて各コンセンサスノードに対応する過去検証異常回数に対してそれぞれ更新を行い、目標コンセンサスノードによりカウントされる各コンセンサスノードの目標検証異常回数を取得するように構成される。
ノード決定モジュール15は、目標コンセンサスノードによりカウントされる各コンセンサスノードの目標検証異常回数に基づいて、少なくとも2つのコンセンサスノードのうちの異常コンセンサスノードを決定するように構成される。
そのうち、結果取得モジュール11、数量統計モジュール12、結果決定モジュール13、回数決定モジュール14及びノード決定モジュール15の機能の実現方式について図3に対応する実施例におけるステップS101-ステップS105を参照することができるため、ここではその詳しい説明を省略する。
そのうち、結果取得モジュール11はブロック生成ユニット111、ブロードキャストユニット112及び結果取得ユニット113を含む。
ブロック生成ユニット111は、検証待ちブロックを生成するように構成される。
ブロードキャストユニット112は、検証待ちブロックを各コンセンサスノードにブロードキャストし、各コンセンサスノードが検証待ちブロックに対してブロック検証を行うようにさせるように構成される。
結果取得ユニット113は、検証待ちブロックに対する各コンセンサスノードのブロック検証結果を取得するように構成される。
そのうち、ブロック生成ユニット111、ブロードキャストユニット112及び結果取得ユニット113の機能の実現方式について図3に対応する実施例におけるステップS101を参照することができるから、ここではその詳しい説明を省略する。
そのうち、結果決定モジュール13は第一結果決定ユニット131及び第二結果決定ユニット132を含む。
第一結果決定ユニット131は、第一の数が第二の数よりも大きいときに、合法検証結果を目標検証結果と決定するように構成される。
第二結果決定ユニット132は、第一の数が第二の数よりも小さいときに、違法検証結果を目標検証結果と決定するように構成される。
そのうち、第一結果決定ユニット131及び第二結果決定ユニット132の機能の実現方式について図3に対応する実施例におけるステップS103を参照することができるので、ここではその詳しい説明を省略する。
そのうち、数量統計モジュール12は票数取得ユニット121、第一ノード決定ユニット122、第二ノード決定ユニット123及び数量決定ユニット124を含む。
票数取得ユニット121は、各コンセンサスノードに対応するブロック検証票数をそれぞれ取得するように構成される。
第一ノード決定ユニット122は、検証待ちブロックに対する少なくとも2つのコンセンサスノードのそれぞれのブロック検証結果のうち、ブロック検証結果が合法検証結果であるコンセンサスノードを第一コンセンサスノードと決定するように構成される。
第二ノード決定ユニット123は、検証待ちブロックに対する少なくとも2つのコンセンサスノードのそれぞれのブロック検証結果のうち、ブロック検証結果が違法検証結果であるコンセンサスノードを第二コンセンサスノードと決定するように構成される。
数量決定ユニット124は、第一コンセンサスノードに対応するブロック検証票数の和(合計)を第一の数と決定し、第二コンセンサスノードに対応するブロック検証票数の和(合計)を第二の数と決定するように構成される。
そのうち、票数取得ユニット121、第一ノード決定ユニット122、第二ノード決定ユニット123及び数量決定ユニット124の機能の実現方式について図3に対応する実施例におけるステップS102を参照することができるので、ここではその詳しい説明を省略する。
そのうち、目標コンセンサスノードは少なくとも2つのコンセンサスノードにより投票メカニズムに基づいて投票することで決定され得る。
データ検出装置1はさらに高度差取得モジュール16及び再投票モジュール17を含む。
高度差取得モジュール16は、検証待ちブロックのブロック高さを取得し、ブロック高さと検証開始高さとの間の高度差を取得するように構成され、検証開始高さとは、投票メカニズムに基づいて目標コンセンサスノードが投票で決定されたときに目標コンセンサスノードが所持するブロックの最高ブロック高さを指す。
再投票モジュール17は、高度差が高度差閾値よりも大きいときに、各コンセンサスノードに投票要求を送信し、各コンセンサスノードが投票要求及び投票メカニズムに基づいて目標コンセンサスノードに対して再び投票を行うようにさせるように構成される。
そのうち、高度差取得モジュール16及び再投票モジュール17の機能の実現方式について図3に対応する実施例におけるステップS105を参照することができるため、ここではその詳しい説明を省略する。
そのうち、回数決定モジュール14は結果比較ユニット141、衝突決定ユニット142、マッチング決定ユニット143及び回数決定ユニット144を含む。
結果比較ユニット141は、目標検証結果と、検証待ちブロックに対する少なくとも2つのコンセンサスノードのそれぞれのブロック検証結果とを比較するように構成される。
衝突決定ユニット142は、検証待ちブロックに対する少なくとも2つのコンセンサスノードのそれぞれのブロック検証結果のうち、目標検証結果とは異なるブロック検証結果に対応するコンセンサスノードを衝突コンセンサスノードと決定するように構成される。
マッチング決定ユニット143は、少なくとも2つのコンセンサスノードのうち、衝突コンセンサスノード以外のコンセンサスノードをマッチングコンセンサスノードと決定するように構成される。
回数決定ユニット144は、衝突コンセンサスノードに対応する過去検証異常回数に単位異常回数を増やし、衝突コンセンサスノードに対応する目標検証異常回数を取得し、また、マッチングコンセンサスノードに対応する過去検証異常回数をマッチングコンセンサスノードに対応する目標検証異常回数と決定するように構成され、検証待ちブロックが先行ブロックを有しないときに、各コンセンサスノードに対応する過去検証異常回数は何れも、デフォルト初期回数であり、検証待ちブロックが先行ブロックを有するときに、各コンセンサスノードに対応する過去検証異常回数は、先行ブロックに対する少なくとも2つのコンセンサスノードのブロック検証結果に基づいて得られる各コンセンサスノードの検証異常回数である。
そのうち、結果比較ユニット141、衝突決定ユニット142、マッチング決定ユニット143及び回数決定ユニット144の機能の実現方式について図3に対応する実施例におけるステップS104を参照することができるから、ここではその詳しい説明を省略する。
そのうち、ノード決定モジュール15は審査待ちユニット151、回数取得ユニット152及び異常決定ユニット153を含む。
審査待ちユニット151は、目標コンセンサスノードによりカウントされる各コンセンサスノードの目標検証異常回数のうち、回数が異常回数閾値よりも大きい目標検証異常回数に対応するコンセンサスノードを審査待ちコンセンサスノードと決定するように構成される。
回数取得ユニット152は、各コンセンサスノードによりカウントされる審査待ちコンセンサスノードの目標検証異常回数を取得するように構成される。
異常決定ユニット153は、各コンセンサスノードによりそれぞれカウントされる審査待ちコンセンサスノードの目標検証異常回数が前記異常コンセンサスノードの決定条件を満足したときに、審査待ちコンセンサスノードを異常コンセンサスノードと決定するように構成される。
そのうち、審査待ちユニット151、回数取得ユニット152及び異常決定ユニット153の機能の実現方式について図3に対応する実施例におけるステップS105を参照することができるため、ここではその詳しい説明を省略する。
そのうち、異常決定ユニット153はノード数量取得サブユニット1531及び異常決定サブユニット1532を含む。
ノード数量取得サブユニット1531は、各コンセンサスノードによりそれぞれカウントされる審査待ちコンセンサスノードの目標検証異常回数のうち、回数が異常回数閾値よりも大きい目標検証異常回数に対応するコンセンサスノードのノード数を得るように構成される。
異常決定サブユニット1532は、ノード数と、少なくとも2つのコンセンサスノードのノード総数との間の比率が比率閾値よりも大きいときに、前記各コンセンサスノードによりカウントされる前記審査待ちコンセンサスノードの目標検証異常回数が前記異常コンセンサスノードの決定条件を満足すると決定するように構成される。
そのうち、ノード数量取得サブユニット1531及び異常決定サブユニット1532の機能の実現方式について図3に対応する実施例におけるステップS105を参照することができるので、ここではその詳しい説明を省略する。
そのうち、データ検出装置1はさらに次のように構成され、即ち、ノード数と、少なくとも2つのコンセンサスノードのノード総数との間の比率が比率閾値以下であるときに、前記各コンセンサスノードによりカウントされる前記審査待ちコンセンサスノードの目標検証異常回数が前記異常コンセンサスノードの決定条件を満足しないと決定し、審査待ちコンセンサスノードを正常コンセンサスノードと決定する。
そのうち、データ検出装置1はさらに次のように構成され、即ち、各コンセンサスノードに異常コンセンサスノードをブロードキャストし、各コンセンサスノードが異常コンセンサスノードをノードブラックリストに追加するようにさせ、ノードブラックリストは、異常コンセンサスノードにより開始されるブロックトランザクションを受信することを拒否するために用いられる。
本出願の実施例を適用することにより、少なくとも2つのコンセンサスノードのうちから異常コンセンサスノードを検出することができ、ブロックチェーンネットワークにおける異常コンセンサスノードを自発的に発見し、その後、該異常コンセンサスノードに対して対応する処理(例えば、ブラックリストに追加する処理)を行うことで、ブロックチェーンネットワークのネットワークセキュリティを向上させることができる。
図8を参照し、それは本出願の実施例により提供されるコンピュータ装置の構成を示す図である。該コンピュータ装置は本出願の実施例における目標コンセンサスノードとすることができ、図8に示すように、コンピュータ装置1000は処理器1001、ネットワークインターフェース1004及び記憶器1005を含んでも良く、また、コンピュータ装置1000はさらにユーザーインターフェース1003及び少なくとも1つの通信バス1002を含んでも良い。そのうち、通信バス1002はこれらのコンポーネントの間の接続や通信を実現するために用いられる。そのうち、ユーザーインターフェース1003はディスプレイ(Display)やキーボード(Keyboard)を含んでも良く、オプションとして、ユーザーインターフェース1003はさらに有線インターフェースや無線インターフェースを含んでも良い。ネットワークインターフェース1004は有線インターフェースや無線インターフェース(例えば、WI-FIインターフェース)を含んでも良い。記憶器1005は高速RAM記憶器であっても良く、不揮発性記憶器(non-volatile memory)、例えば、少なくとも1つの磁気ディスク記憶器であっても良い。記憶器1005はさらに前述の処理器1001から離れた少なくとも1つの記憶装置であっても良い。図8に示すように、コンピュータ記憶媒体としての記憶器1005にはオペレーティングシステム、ネットワーク通信モジュール、ユーザーインターフェースモジュール及びデバイス制御アプリケーションプログラムが含まれても良い。
図8に示すコンピュータ装置1000では、ネットワークインターフェース1004はネットワーク通信機能を提供することができ、ユーザーインターフェース1003は主にユーザーのために入力用のインターフェースを提供するために用いられ、処理器1001は記憶器1005に記憶されたデバイス制御アプリケーションプログラムを呼び出すことで、上述の図3に対応する実施例におけるデータ検出方法を実現するために用いられ得る。理解すべきは、本出願で説明されるコンピュータ装置1000は前述の図7に対応する実施例におけるデータ検出装置1を実現することもできるということであるが、ここではその詳しい説明を省略する。また、ここでは同じ方法を採用することによる有利な効果の説明についても省略する。
ここで留意されたいのは、本出願はさらにコンピュータ可読記憶媒体も提供するということであり、コンピュータ可読記憶媒体には前述のデータ検出装置1が実行するコンピュータプログラムを記憶しており、該コンピュータプログラムはプログラム命令を含み、処理器は該プログラム命令を実行するときに、上述の図3に対応する実施例におけるデータ検出方法を実現することができる。なお、ここではその詳しい説明を省略する。また、ここでは同じ方法を採用することによる有利な効果の説明についても省略する。さらに、本出願によるコンピュータ記憶媒体の実施例における未記載の技術的細部についても本出願における方法の実施例の説明を参照することができる。
当業者が理解すべきは、上述の方法の実施例における全部又は一部のフローはコンピュータプログラムにより関連するハードウェアに命令を送ることで完成することができ、上述のプログラムはコンピュータ可読取記憶媒体に記憶することができ、該プログラムは実行されるときに上述の各方法の実施例のフローを含むことができるということができる。そのうち、上述の記憶媒体は磁気ディスク、光ディスク、リードオンリーメモリ(Read-Only Memory、ROM)、ランダムアクセスメモリ(Random Access Memory、RAM)などであっても良い。
以上、本出願の好ましい実施例を説明したが、本出願はこの実施例に限定されず、本出願の趣旨を離脱しない限り、本出願に対するあらゆる変更は本出願の技術的範囲に属する。

Claims (15)

  1. 目標コンセンサスノードが実行する、ブロックチェーンに基づいてデータを検出する方法であって、
    検証待ちブロックに対する少なくとも2つのコンセンサスノードのそれぞれのブロック検証結果を取得するステップ;
    前記検証待ちブロックに対する前記少なくとも2つのコンセンサスノードのそれぞれのブロック検証結果のうち、合法検証結果の第一の数及び違法検証結果の第二の数をカウントするステップ;
    前記第一の数及び前記第二の数に基づいて前記検証待ちブロックについての目標検証結果を決定するステップであって、前記目標検証結果は前記合法検証結果又は前記違法検証結果である、ステップ;
    前記目標検証結果と、前記検証待ちブロックに対する前記少なくとも2つのコンセンサスノードのそれぞれのブロック検証結果とを比較し、比較結果に基づいて、各コンセンサスノードに対応する過去検証異常回数に対してそれぞれ更新を行い、前記目標コンセンサスノードによりカウントされる前記各コンセンサスノードの目標検証異常回数を取得するステップ;及び
    前記目標コンセンサスノードによりカウントされる前記各コンセンサスノードの目標検証異常回数に基づいて、前記少なくとも2つのコンセンサスノードのうちの異常コンセンサスノードを決定するステップを含む、方法。
  2. 請求項1に記載の方法であって、
    前記検証待ちブロックに対する少なくとも2つのコンセンサスノードのそれぞれのブロック検証結果を取得するステップは、
    前記検証待ちブロックを生成するステップ;及び
    前記検証待ちブロックを前記各コンセンサスノードにブロードキャストし、前記各コンセンサスノードが前記検証待ちブロックに対してブロック検証を行うようにさせるステップ;及び
    前記検証待ちブロックに対する前記各コンセンサスノードのブロック検証結果を取得するステップを含む、方法。
  3. 請求項1に記載の方法であって、
    前記第一の数及び前記第二の数に基づいて前記検証待ちブロックについての目標検証結果を決定するステップは、
    前記第一の数が前記第二の数よりも大きいときに、前記合法検証結果を前記目標検証結果と決定するステップ;及び
    前記第一の数が前記第二の数よりも小さいときに、前記違法検証結果を前記目標検証結果と決定するステップを含む、方法。
  4. 請求項1に記載の方法であって、
    前記検証待ちブロックに対する前記少なくとも2つのコンセンサスノードのそれぞれのブロック検証結果のうち、合法検証結果の第一の数及び違法検証結果の第二の数をカウントするステップは、
    前記各コンセンサスノードに対応するブロック検証票数をそれぞれ取得するステップ;
    前記検証待ちブロックに対する前記少なくとも2つのコンセンサスノードのそれぞれのブロック検証結果のうち、ブロック検証結果が前記合法検証結果であるコンセンサスノードを第一コンセンサスノードと決定するステップ;
    前記検証待ちブロックに対する前記少なくとも2つのコンセンサスノードのそれぞれのブロック検証結果のうち、ブロック検証結果が前記違法検証結果であるコンセンサスノードを第二コンセンサスノードと決定するステップ;及び
    前記第一コンセンサスノードに対応するブロック検証票数の合計を前記第一の数と決定し、前記第二コンセンサスノードに対応するブロック検証票数の合計を前記第二の数と決定するステップを含む、方法。
  5. 請求項1に記載の方法であって、
    前記目標コンセンサスノードは前記少なくとも2つのコンセンサスノードにより投票メカニズムに基づいて投票することで決定され、
    前記方法は、さらに、
    前記検証待ちブロックのブロック高さを取得し、前記ブロック高さと検証開始高さとの間の高度差を取得するステップであって、前記検証開始高さとは、前記投票メカニズムに基づいて前記目標コンセンサスノードが投票で決定されたときに、前記目標コンセンサスノードが有するブロックの最高ブロック高さを指す、ステップ;及び
    前記高度差が高度差閾値よりも大きいときに、前記各コンセンサスノードに投票要求を送信し、前記各コンセンサスノードが前記投票要求及び前記投票メカニズムに基づいて前記目標コンセンサスノードに対して再び投票を行うようにさせるステップを含む、方法。
  6. 請求項1に記載の方法であって、
    前記比較結果に基づいて各コンセンサスノードに対応する過去検証異常回数に対してそれぞれ更新を行い、前記目標コンセンサスノードによりカウントされる前記各コンセンサスノードの目標検証異常回数を取得するステップは、
    前記目標検証結果と、前記検証待ちブロックに対する前記少なくとも2つのコンセンサスノードのそれぞれのブロック検証結果とを比較するステップ;
    前記検証待ちブロックに対する前記少なくとも2つのコンセンサスノードのそれぞれのブロック検証結果のうち、前記目標検証結果とは異なるブロック検証結果に対応するコンセンサスノードを衝突コンセンサスノードと決定するステップ;
    前記少なくとも2つのコンセンサスノードのうち、前記衝突コンセンサスノード以外のコンセンサスノードをマッチングコンセンサスノードと決定するステップ;及び
    前記衝突コンセンサスノードに対応する過去検証異常回数に単位異常回数を増やし、前記衝突コンセンサスノードに対応する目標検証異常回数を取得し、前記マッチングコンセンサスノードに対応する過去検証異常回数を前記マッチングコンセンサスノードに対応する目標検証異常回数と決定するステップを含み、
    前記検証待ちブロックが先行ブロックを有しないときに、前記各コンセンサスノードに対応する過去検証異常回数は何れもデフォルト初期回数であり、前記検証待ちブロックが先行ブロックを有するときに、前記各コンセンサスノードに対応する過去検証異常回数は、前記先行ブロックに対する前記少なくとも2つのコンセンサスノードのブロック検証結果に基づいて得られた前記各コンセンサスノードの検証異常回数である、方法。
  7. 請求項1に記載の方法であって、
    前記目標コンセンサスノードによりカウントされる前記各コンセンサスノードの目標検証異常回数に基づいて、前記少なくとも2つのコンセンサスノードのうちの異常コンセンサスノードを決定するステップは、
    前記目標コンセンサスノードによりカウントされる前記各コンセンサスノードの目標検証異常回数のうち、回数が異常回数閾値よりも大きい目標検証異常回数に対応するコンセンサスノードを審査待ちコンセンサスノードと決定するステップ;
    前記各コンセンサスノードによりカウントされる前記審査待ちコンセンサスノードの目標検証異常回数を取得するステップ;及び
    前記各コンセンサスノードによりカウントされる前記審査待ちコンセンサスノードの目標検証異常回数が前記異常コンセンサスノードの決定条件を満足するときに、前記審査待ちコンセンサスノードを前記異常コンセンサスノードと決定するステップを含む、方法。
  8. 請求項7に記載の方法であって、さらに、
    前記各コンセンサスノードによりそれぞれカウントされる前記審査待ちコンセンサスノードの目標検証異常回数のうち、回数が前記異常回数閾値よりも大きい目標検証異常回数に対応するコンセンサスノードのノード数を取得するステップ;及び
    前記ノード数と、前記少なくとも2つのコンセンサスノードのノード総数との間の比率が比率閾値よりも大きいときに、前記各コンセンサスノードによりカウントされる前記審査待ちコンセンサスノードの目標検証異常回数が前記異常コンセンサスノードの決定条件を満足すると決定するステップを含む、方法。
  9. 請求項8に記載の方法であって、さらに、
    前記ノード数と、前記少なくとも2つのコンセンサスノードのノード総数との間の比率が前記比率閾値以下であるときに、前記各コンセンサスノードによりカウントされる前記審査待ちコンセンサスノードの目標検証異常回数が前記異常コンセンサスノードの決定条件を満足しないと決定し、前記審査待ちコンセンサスノードを正常コンセンサスノードと決定するステップを含む、方法。
  10. 請求項1に記載の方法であって、さらに、
    前記各コンセンサスノードに前記異常コンセンサスノードをブロードキャストし、前記各コンセンサスノードが前記異常コンセンサスノードをノードブラックリストに追加するようにさせるステップであって、前記ノードブラックリストは、前記異常コンセンサスノードにより開始されるブロックトランザクションの受信を拒否するために用いられる、ステップを含む、方法。
  11. 目標コンセンサスノードに設けられる、ブロックチェーンに基づいてデータを検出する装置であって、
    検証待ちブロックに対する少なくとも2つのコンセンサスノードのそれぞれのブロック検証結果を取得するように構成される結果取得モジュール;
    前記検証待ちブロックに対する前記少なくとも2つのコンセンサスノードのそれぞれのブロック検証結果のうち、合法検証結果の第一の数及び違法検証結果の第二の数をカウントするように構成される数量統計モジュール;
    前記第一の数及び前記第二の数に基づいて前記検証待ちブロックについての目標検証結果を決定するように構成される結果決定モジュールであって、前記目標検証結果は前記合法検証結果又は前記違法検証結果である、結果決定モジュール;
    前記目標検証結果と、前記検証待ちブロックに対する前記少なくとも2つのコンセンサスノードのそれぞれのブロック検証結果とを比較し、比較結果に基づいて各コンセンサスノードに対応する過去検証異常回数に対してそれぞれ更新を行い、前記目標コンセンサスノードによりカウントされる前記各コンセンサスノードの目標検証異常回数を取得するように構成される回数決定モジュール;及び
    前記目標コンセンサスノードによりカウントされる前記各コンセンサスノードの目標検証異常回数に基づいて、前記少なくとも2つのコンセンサスノードのうちの異常コンセンサスノードを決定するように構成されるノード決定モジュールを含む、装置。
  12. 請求項11に記載の装置であって、
    前記結果取得モジュールは、
    前記検証待ちブロックを生成するように構成されるブロック生成ユニット;
    前記検証待ちブロックを前記各コンセンサスノードにブロードキャストし、前記各コンセンサスノードが前記検証待ちブロックに対してブロック検証を行うように構成されるブロードキャストユニット;及び
    前記検証待ちブロックに対する前記各コンセンサスノードのブロック検証結果を取得するように構成される結果取得ユニットを含む、装置。
  13. 請求項11に記載の装置であって、
    前記結果決定モジュールは、
    前記第一の数が前記第二の数よりも大きいときに、前記合法検証結果を前記目標検証結果と決定するように構成される第一結果決定ユニット;及び
    前記第一の数が前記第二の数よりも小さいときに、前記違法検証結果を前記目標検証結果と決定するように構成される第二結果決定ユニットを含む、装置。
  14. 処理器と、前記処理器に接続される記憶器とを含むコンピュータ装置であって、
    前記記憶器にはコンピュータプログラムが記憶されており、
    前記処理器は、前記コンピュータプログラムを実行することにより、請求項1乃至10のうちの何れか1項に記載の方法を実現するように構成される、コンピュータ装置。
  15. コンピュータに、請求項1乃至10のうちの何れか1項に記載の方法を実行させるためのプログラム。
JP2022539369A 2020-05-21 2021-04-21 ブロックチェーンに基づくデータ検出方法及び装置並びにコンピュータ装置及びプログラム Active JP7398000B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
CN202010433284.9 2020-05-21
CN202010433284.9A CN111343208B (zh) 2020-05-21 2020-05-21 基于区块链的数据检测方法、装置及计算机可读存储介质
PCT/CN2021/088624 WO2021233048A1 (zh) 2020-05-21 2021-04-21 基于区块链的数据检测方法、装置及计算机可读存储介质

Publications (2)

Publication Number Publication Date
JP2023509889A JP2023509889A (ja) 2023-03-10
JP7398000B2 true JP7398000B2 (ja) 2023-12-13

Family

ID=71187577

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2022539369A Active JP7398000B2 (ja) 2020-05-21 2021-04-21 ブロックチェーンに基づくデータ検出方法及び装置並びにコンピュータ装置及びプログラム

Country Status (5)

Country Link
US (1) US20220272105A1 (ja)
JP (1) JP7398000B2 (ja)
KR (1) KR102578019B1 (ja)
CN (1) CN111343208B (ja)
WO (1) WO2021233048A1 (ja)

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111343208B (zh) * 2020-05-21 2020-08-14 腾讯科技(深圳)有限公司 基于区块链的数据检测方法、装置及计算机可读存储介质
CN112200578A (zh) * 2020-09-23 2021-01-08 裴俊伟 基于区块链的金融业务校验方法和金融业务校验平台
CN112202875B (zh) * 2020-09-28 2024-07-02 北京八分量信息科技有限公司 基于区块链节点权重进行安全检测的方法、装置及相关产品
CN113312333A (zh) * 2020-10-24 2021-08-27 曹青青 基于区块链和云计算的安全服务更新方法及云计算中心
CN114615002B (zh) * 2020-12-03 2024-02-27 中国移动通信集团设计院有限公司 运营商关键基础设施被控识别方法及系统
CN113177196A (zh) * 2021-04-29 2021-07-27 广东粤信智能科技有限公司 一种基于区块链的数据标准验证方法、存储介质及系统
CN113868216B (zh) * 2021-12-03 2022-02-22 中国信息通信研究院 区块链监测方法及装置
CN114385761B (zh) * 2022-03-23 2022-07-12 支付宝(杭州)信息技术有限公司 一种基于共识系统的共识数据存储、获取方法及装置
JPWO2024004485A1 (ja) * 2022-06-30 2024-01-04
JPWO2024009650A1 (ja) * 2022-07-04 2024-01-11
CN117081861B (zh) * 2023-10-16 2023-12-26 北京亚大通讯网络有限责任公司 基于区块链的智能合约数据管理系统

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107508680A (zh) 2017-07-26 2017-12-22 阿里巴巴集团控股有限公司 数字证书管理方法、装置及电子设备
JP2020512708A (ja) 2017-03-30 2020-04-23 ▲騰▼▲訊▼科技(深▲セン▼)有限公司 分散システム、メッセージ処理方法、ノード、クライアント及び記憶媒体

Family Cites Families (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107590738A (zh) * 2017-08-24 2018-01-16 阿里巴巴集团控股有限公司 选择共识节点的处理方法、装置及服务器
CN107579848B (zh) * 2017-08-30 2020-08-25 上海保险交易所股份有限公司 实用拜占庭容错共识机制中动态更改共识节点的方法
US20190333030A1 (en) * 2018-04-30 2019-10-31 Bank Of America Corporation Blockchain-based digital token utilization
CN109086619A (zh) * 2018-07-05 2018-12-25 广东天泽汇通科技有限公司 基于区块链的停车信用调整方法及其装置、电子设备
CN109002297B (zh) * 2018-07-16 2020-08-11 百度在线网络技术(北京)有限公司 共识机制的部署方法、装置、设备和存储介质
CN109034851B (zh) * 2018-09-05 2022-03-08 深圳正品创想科技有限公司 基于区块链的商品防伪溯源方法及其装置、区块链节点
CN109218311B (zh) * 2018-09-18 2021-09-03 北京京东尚科信息技术有限公司 区块链的结块方法、区块链的节点和区块链
US11729186B2 (en) * 2018-10-04 2023-08-15 Research Foundation Of The City University Of New York Blockchain architecture for computer security applications
CN110232634A (zh) * 2019-06-05 2019-09-13 湖南道业信息科技有限公司 区块链共识方法、区块链共识系统和计算机可读存储介质
CN110247774A (zh) * 2019-06-28 2019-09-17 深圳市网心科技有限公司 一种区块链数据的共识方法及相关设备
CN110443712B (zh) * 2019-08-09 2021-04-20 腾讯科技(深圳)有限公司 合约冲突检测方法、装置、可读存储介质和计算机设备
CN110932892B (zh) * 2019-11-21 2022-05-31 腾讯科技(深圳)有限公司 基于区块链的信息预警方法、装置、相关节点及存储介质
CN111444211B (zh) * 2020-03-26 2021-07-13 腾讯科技(深圳)有限公司 区块链共识节点校验方法、装置、设备以及存储介质
CN111343208B (zh) * 2020-05-21 2020-08-14 腾讯科技(深圳)有限公司 基于区块链的数据检测方法、装置及计算机可读存储介质

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2020512708A (ja) 2017-03-30 2020-04-23 ▲騰▼▲訊▼科技(深▲セン▼)有限公司 分散システム、メッセージ処理方法、ノード、クライアント及び記憶媒体
CN107508680A (zh) 2017-07-26 2017-12-22 阿里巴巴集团控股有限公司 数字证书管理方法、装置及电子设备

Also Published As

Publication number Publication date
CN111343208A (zh) 2020-06-26
JP2023509889A (ja) 2023-03-10
US20220272105A1 (en) 2022-08-25
KR20220091560A (ko) 2022-06-30
CN111343208B (zh) 2020-08-14
KR102578019B1 (ko) 2023-09-14
WO2021233048A1 (zh) 2021-11-25

Similar Documents

Publication Publication Date Title
JP7398000B2 (ja) ブロックチェーンに基づくデータ検出方法及び装置並びにコンピュータ装置及びプログラム
CN107566124B (zh) 基于哈希运算的共识建立方法、区块链系统及存储介质
JP2021523476A (ja) 準安定ビザンチン合意
US20230037932A1 (en) Data processing method and apparatus based on blockchain network, and computer device
Wang et al. Capacity of blockchain based Internet-of-Things: Testbed and analysis
KR20210006934A (ko) 블록 체인 합의 방법, 어카운팅 노드 및 노드
WO2022217807A1 (zh) 区块链共识节点选择方法、装置、计算机设备和存储介质
EP3270317A1 (en) Dynamic security module server device and operating method thereof
CN110602217A (zh) 基于区块链的联盟管理方法、装置、设备及存储介质
CN112182113B (zh) 区块链共识方法、系统、电子设备及存储介质
CN111885050A (zh) 基于区块链网络的数据存储方法、装置、相关设备及介质
Kairaldeen et al. Data integrity time optimization of a blockchain IoT smart home network using different consensus and hash algorithms
CN111680282B (zh) 基于区块链网络的节点管理方法、装置、设备及介质
CN111431908A (zh) 一种访问处理方法、装置及可读存储介质
Araujo Rodriguez et al. Program-aware fuzzing for MQTT applications
CN112995236A (zh) 一种物联网设备安全管控方法、装置和系统
Reno et al. Solving blockchain trilemma using off‐chain storage protocol
CN112181599B (zh) 模型训练方法、装置及存储介质
CN112261427B (zh) 恶意节点的识别方法及装置、电子设备
Wang et al. Internet of things
KR20210077136A (ko) 블록 체인 네트워크 시스템의 동작 방법
CN112906171B (zh) 一种综合能源系统可信协同优化方法及仿真平台
KR20180078764A (ko) 차량 단말기에서 실행 가능한 애플리케이션의 테스트를 통한 검증 절차를 제공하고 상기 애플리케이션이 마켓 포털 서버에 등록되도록 지원하는 방법, 이를 이용하는 개발자 포털 서버 및 애플리케이션 관리 서버
CN115801292A (zh) 访问请求的鉴权方法和装置、存储介质及电子设备
CN111492360A (zh) 使用先进网络决策平台检测并减缓伪造认证对象攻击

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20220627

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20230704

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20230911

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20231121

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20231201

R150 Certificate of patent or registration of utility model

Ref document number: 7398000

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150