Distributed block chain node state detection method and device and storage medium

Abstract

The invention discloses a distributed block chain node state detection method and device and a storage medium, and relates to the technical field of block chains. The method comprises the following steps: collecting self-inspection information of each node on a distributed block chain; broadcasting the self-checking information of each node to each node except the node; after the ith node receives the self-checking information of the jth node, verifying a signature carried in the self-checking information of the jth node by using the public key of the jth node through the ith node, and obtaining cross-checking information of the ith node to the jth node after the signature verification is passed; and after the cross check information corresponding to each node is broadcasted to each node except the node, consensus is carried out on the cross check information corresponding to each node through each node, and a detection result of each node is obtained. According to the method and the device, the problem of consensus efficiency reduction caused by lack of effective node health condition monitoring in block chain and alliance chain environments in the prior art is solved.

Description

Distributed blockchain node state detection method, device and storage medium Technical Field

[0001] This application relates to the field of blockchain technology, and more specifically, to a method, apparatus, and storage medium for detecting the state of a distributed blockchain node. Background Technology

[0002] Blockchain technology, with its unique distributed ledger mechanism and encryption algorithms, has attracted widespread attention and application in fields such as information security, financial transactions, and supply chain management. Especially in consortium blockchain scenarios, efficient collaboration and data exchange between nodes are crucial for system performance. Unlike public blockchains, which pursue extreme distribution, consortium blockchains typically consist of a pre-determined group of member nodes that collaboratively maintain a shared database through consensus algorithms.

[0003] However, current consortium blockchain systems have significant shortcomings in node health monitoring. Due to the lack of an effective health monitoring mechanism, once a node fails or its performance degrades, other nodes often cannot immediately detect this change and will still attempt to communicate and synchronize data with it. This ineffective interaction may lead to consensus delays, affecting system throughput and the confirmation speed of user transactions.

[0004] There is currently no effective solution to the above problems. Summary of the Invention

[0005] This application provides a method, apparatus, and storage medium for detecting the state of distributed blockchain nodes, in order to at least solve the technical problem of decreased consensus efficiency caused by the lack of effective node health monitoring in existing blockchain and consortium blockchain environments.

[0006] According to one aspect of the embodiments of this application, a method for state detection of distributed blockchain nodes is provided, comprising: collecting self-check information of each node on the distributed blockchain, wherein the self-check information of each node carries the signature of that node; broadcasting the self-check information of each node to all nodes on the distributed blockchain except for that node; after the i-th node of the distributed blockchain receives the self-check information of the j-th node, verifying the signature carried in the self-check information of the j-th node using the public key of the j-th node by the i-th node, and obtaining the cross-check information of the i-th node on the j-th node after the signature verification is successful, wherein the i-th node and the j-th node are any two different nodes in the distributed blockchain; after broadcasting the cross-check information corresponding to each node to all nodes on the distributed blockchain except for that node, reaching a consensus on the cross-check information corresponding to each node through the nodes on the distributed blockchain to obtain the detection result of each node.

[0007] Optionally, self-check information of each node on the distributed blockchain is collected, including: collecting each node's own node identifier, current blockchain height, hash value of the target block, latest received query transaction, and hash value of the transaction execution result, wherein the target block is the block corresponding to the current blockchain height; and signing the node identifier, current blockchain height, hash value of the latest block, latest received query transaction, and hash value of the transaction execution result collected by each node using its private key to obtain the node's self-check information.

[0008] Optionally, the signature carried in the self-check information of the j-th node is verified by the i-th node using the public key of the j-th node, and after the signature verification is successful, the cross-check information of the i-th node on the j-th node is obtained, including: verifying the signature carried in the self-check information of the j-th node using the public key of the j-th node by the i-th node; if the signature verification is successful, parsing the latest query transaction received by the j-th node from the self-check information of the j-th node; performing a hash calculation on the latest query transaction received by the j-th node by the i-th node to obtain a reference hash value; and determining the cross-check information of the i-th node on the j-th node based on the self-check information of the i-th node, the self-check information of the j-th node, and the reference hash value.

[0009] Optionally, based on the self-check information of the i-th node, the self-check information of the j-th node, and the reference hash value, the cross-check information of the i-th node to the j-th node is determined, including: reading the current blockchain height collected by the i-th node from the self-check information of the i-th node to obtain a first reference value; reading the current blockchain height collected by the j-th node from the self-check information of the j-th node to obtain a first comparison value; reading the hash value of the target block collected by the i-th node from the self-check information of the i-th node to obtain a second reference value; reading the hash value of the target block collected by the j-th node from the self-check information of the j-th node to obtain a second comparison value; taking the latest received query transaction determined during the self-check process of the j-th node as the target transaction, and obtaining the hash value of the transaction execution result determined by the j-th node regarding the target transaction to obtain a comparison hash value; and determining the cross-check information of the i-th node to the j-th node based on the first reference value, the first comparison value, the second reference value, the second comparison value, the reference hash value, and the comparison hash value.

[0010] Optionally, based on the first reference value, the first comparison value, the second reference value, the second comparison value, the reference hash value, and the comparison hash value, the cross-check information of the i-th node to the j-th node is determined, including: when the first reference value and the first comparison value are equal, the second reference value and the second comparison value are equal, and the reference hash value and the comparison hash value are equal, the cross-check information of the i-th node to the j-th node is determined to be the first information, wherein the first information indicates that the i-th node judges that the node status of the j-th node is normal.

[0011] Optionally, based on the first reference value, the first comparison value, the second reference value, the second comparison value, the reference hash value, and the comparison hash value, the cross-check information of the i-th node to the j-th node is determined, including: when the first reference value and the first comparison value are equal, the second reference value and the second comparison value are equal, and the reference hash value and the comparison hash value are not equal, the cross-check information of the i-th node to the j-th node is determined to be the second information, wherein the second information indicates that the i-th node judges that the node state of the j-th node is abnormal, and the reason for the abnormality is that the j-th node has a failure during the execution of the smart contract.

[0012] Optionally, based on the first reference value, the first comparison value, the second reference value, the second comparison value, the reference hash value, and the comparison hash value, the cross-check information of the i-th node to the j-th node is determined, including: when the first reference value and the first comparison value are equal, the second reference value and the second comparison value are equal, and the reference hash value and the comparison hash value are not equal, the cross-check information of the i-th node to the j-th node is determined to be the second information, wherein the second information indicates that the i-th node judges that the node state of the j-th node is abnormal, and the reason for the abnormality is that the j-th node has a failure during the execution of the smart contract.

[0013] Optionally, based on the first reference value, the first comparison value, the second reference value, the second comparison value, the reference hash value, and the comparison hash value, the cross-check information of the i-th node to the j-th node is determined, including: if the first reference value and the first comparison value are equal, the second reference value and the second comparison value are not equal, or if the first reference value is greater than the first comparison value, the cross-check information of the i-th node to the j-th node is determined to be third information, wherein the third information indicates that the i-th node judges that the node state of the j-th node is abnormal, and the reason for the abnormality is that the j-th node has made mistakes in the detection of the blockchain height and the judgment of the block.

[0014] Optionally, based on the first reference value, the first comparison value, the second reference value, the second comparison value, the reference hash value, and the comparison hash value, the cross-check information of the i-th node to the j-th node is determined, including: if the first reference value is detected to be less than the first comparison value, the cross-check information of the i-th node to the j-th node is determined to be the fourth information, wherein the fourth information indicates that the node state of the i-th node is suspected to be abnormal and the state judgment result of the i-th node to the j-th node is unreliable.

[0015] Optionally, consensus is reached among the nodes on the distributed blockchain regarding the cross-check information corresponding to each node to obtain the state detection result of each node. This includes: reaching consensus among the nodes on the distributed blockchain regarding the cross-check information corresponding to each node; determining the x-th node as an abnormal node when the x-th node on the distributed blockchain is judged as having an abnormal state by more than a preset number or a preset proportion of nodes, where x is an integer greater than or equal to 1; and performing a restart operation or a disable operation on the determined abnormal node, where the disable operation includes prohibiting it from participating in the consensus process and data processing process of the next round of transactions.

[0016] According to another aspect of the embodiments of this application, a state detection device for distributed blockchain nodes is also provided, comprising: a self-testing unit, used to collect self-testing information of each node in the distributed blockchain, wherein the self-testing information of each node carries the signature of that node; a broadcasting unit, used to broadcast the self-testing information of each node to all nodes in the distributed blockchain except the node itself; a cross-checking unit, used to, after the i-th node in the distributed blockchain receives the self-testing information of the j-th node, verify the signature carried in the self-testing information of the j-th node using the public key of the j-th node by the i-th node, and obtain the cross-checking information of the i-th node on the j-th node after the signature verification is successful, wherein the i-th node and the j-th node are any two different nodes in the distributed blockchain; and a consensus unit, used to, after broadcasting the cross-checking information corresponding to each node to all nodes in the distributed blockchain except the node itself, reach a consensus on the cross-checking information corresponding to each node through the nodes in the distributed blockchain to obtain the detection result of each node.

[0017] According to another aspect of the embodiments of this application, a computer-readable storage medium is also provided, which stores a computer program, wherein when the computer program is executed, the device where the computer-readable storage medium is located executes the above-described distributed blockchain node state detection method.

[0018] According to another aspect of the embodiments of this application, an electronic device is also provided, including one or more processors and a memory, the memory being used to store one or more programs, wherein when one or more programs are executed by one or more processors, the one or more processors cause the one or more processors to execute the above-described distributed blockchain node state detection method.

[0019] According to another aspect of the embodiments of this application, a computer program product is also provided, including a computer program or instructions, which, when executed by a processor, implement the above-described distributed blockchain node state detection method.

[0020] In this application, the state detection method for distributed blockchain nodes first collects the self-check information of each node in the distributed blockchain, wherein each node's self-check information carries its signature; the self-check information of each node is broadcast to all nodes in the distributed blockchain except for the node itself; after the i-th node in the distributed blockchain receives the self-check information of the j-th node, the i-th node uses the public key of the j-th node to verify the signature carried in the self-check information of the j-th node, and after the signature verification is successful, the cross-check information of the i-th node on the j-th node is obtained, wherein the i-th node and the j-th node are any two different nodes in the distributed blockchain; after broadcasting the cross-check information corresponding to each node to all nodes in the distributed blockchain except for the node itself, the nodes in the distributed blockchain reach a consensus on the cross-check information corresponding to each node to obtain the detection result of each node.

[0021] As described above, the distributed blockchain node state detection method of this application first collects the self-check information of each node, and then broadcasts the self-check information of each node to the entire network. Subsequently, the receiving node uses the sender's public key to verify the authenticity and integrity of the signature and executes the corresponding cross-check procedure to obtain cross-check information. Finally, the cross-check information is broadcast to all nodes on the distributed blockchain except the node that received the information, and a consensus algorithm is used to determine the actual state of each node, effectively identifying and isolating abnormal nodes, and improving consensus efficiency and data synchronization speed. This method integrates self-checking, signature verification, cross-checking, and consensus decision-making, providing a guarantee for the high-performance operation of consortium blockchains, and thus solving the technical problem of decreased consensus efficiency caused by the lack of effective node health monitoring in existing blockchain and consortium blockchain environments. Attached Figure Description

[0022] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0023] Figure 1 is a flowchart of an optional distributed blockchain node state detection method according to an embodiment of this application;

[0024] Figure 2 is a schematic diagram of an optional state detection device for a distributed blockchain node according to an embodiment of this application. Detailed Implementation

[0025] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0026] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0027] According to an embodiment of this application, a method for detecting the state of a distributed blockchain node is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0028] According to the embodiments of this application, a distributed blockchain node state detection system (hereinafter referred to as the system) can be used as the execution subject of the distributed blockchain node state detection method of this application embodiment. The distributed blockchain node state detection system can be a software system or an embedded system combining software and hardware. Of course, the method execution subject in the embodiments of this application can also be other forms of execution subject, such as devices or equipment. Those skilled in the art should know that this application does not particularly limit the specific form of the method execution subject.

[0029] Figure 1 is a flowchart of a distributed blockchain node state detection method according to an embodiment of this application. As shown in Figure 1, the method includes the following steps:

[0030] Step S101: Collect the self-check information of each node on the distributed blockchain, wherein the self-check information of each node carries the signature of that node.

[0031] Optionally, the node collects its own information, including the node's ID, the current height of the blockchain, the hash value of the block, the hash value of the most recently received query transaction and its execution result. Then, the system signs the collected self-checking node's ID, the current height of the blockchain, the hash value of the block, the hash value of the most recently received query transaction and its execution result using the node's private key, thereby obtaining the node's self-checking information.

[0032] Optionally, signatures help ensure the integrity and non-repudiation of self-inspection information, providing a foundation of trust for subsequent cross-checks.

[0033] Step S102: Broadcast the self-check information of each node to all nodes on the distributed blockchain except for that node.

[0034] Alternatively, broadcasting refers to sending information to all nodes in the blockchain network. Broadcasting allows all nodes in the network to obtain the latest status of other nodes, providing a more comprehensive information basis for subsequent cross-checking and consensus decisions.

[0035] Step S103: After the i-th node in the distributed blockchain receives the self-check information from the j-th node, the i-th node uses the public key of the j-th node to verify the signature carried in the self-check information of the j-th node. After the signature verification is successful, the i-th node obtains the cross-check information of the j-th node from the j-th node. Here, the i-th node and the j-th node are any two different nodes in the distributed blockchain.

[0036] Optionally, the node health cross-check result is a multi-dimensional data structure, in the form of node health cross-check result = << the checked node id0, corresponding to the health status of node 0, showing the reason for the node's abnormality when it is abnormal / meaningless when it is healthy> ... < the checked node idn, corresponding to the health status of node n, showing the reason for the node's abnormality when it is abnormal / meaningless when it is healthy>, and the node that makes this check result signs all the tuples with its own private key>>.

[0037] Optionally, after receiving the self-check information from the j-th node, the i-th node uses its public key to verify the signature in the j-th node's self-check information to ensure the trustworthiness of the information's source. After successful signature verification, the i-th node executes the query transaction in the j-th node's self-check information, calculates the hash value of the transaction execution result, and compares it with the hash value in the j-th node's self-check information. Simultaneously, it verifies the consistency between the blockchain height and the hash value, thereby assessing the health status of the j-th node and identifying the specific reasons for any anomalies.

[0038] Optionally, through cross-checking, nodes in the blockchain network can accurately assess the health status of other nodes based on verified real information, promptly identify abnormal nodes, reduce invalid data interactions, and improve consensus efficiency.

[0039] Step S104: After broadcasting the cross-check information corresponding to each node to all nodes on the distributed blockchain except for that node, the nodes on the distributed blockchain reach a consensus on the cross-check information corresponding to each node to obtain the detection result of each node.

[0040] Alternatively, consensus refers to the consensus reached by each node in the network through a specific algorithm on a certain piece of information or state.

[0041] Optionally, the i-th node broadcasts its own signed cross-check information to the entire network, and other nodes store and analyze it upon receipt. After all nodes in the network have collected all cross-check information, they analyze the collected information using a consensus algorithm. Based on the judgment results of the majority of nodes, the actual health status of each node is determined, and the final detection result is obtained.

[0042] Optionally, through consensus decision-making, the blockchain network can determine the health status of nodes from the cross-check information of nodes in a short period of time, thereby automatically identifying and isolating abnormal nodes, reducing the negative impact of abnormal nodes on the consensus process, improving consensus efficiency and data synchronization speed, and enhancing the stability and availability of the blockchain network.

[0043] In one optional embodiment, the self-check information of each node on the distributed blockchain is collected, including: collecting each node's own node identifier, current blockchain height, hash value of the target block, latest received query transaction, and hash value of the transaction execution result, wherein the target block is the block corresponding to the current blockchain height; and signing the node identifier, current blockchain height, hash value of the latest block, latest received query transaction, and hash value of the transaction execution result collected by each node using its private key to obtain the node's self-check information.

[0044] Optionally, each node initiates a self-check procedure, collecting its own node identifier, which is typically a unique string or number used to uniquely identify the node within the network. Subsequently, the node reads the current height of the blockchain, i.e., the sequence number of the last block in the current blockchain, and the hash value of the target block corresponding to the current height. The hash value serves as a digest of the block content, used to prove the integrity and consistency of the block data. Optionally, the node can record the hash value of the most recently received query transaction and its execution result. Query transactions are a type of transaction that does not require network consensus, and each node may receive different query transactions; the hash value is a hash calculation based on the query transaction's execution result, used for subsequent cross-validation.

[0045] Optionally, each node uses its own private key to digitally sign the collected node identifier, blockchain height, blockchain hash value, query transaction, and hash value, generating a signature data. Digital signatures not only help ensure the authenticity and integrity of information but also provide a secure verification mechanism for subsequent cross-checking and consensus decisions.

[0046] Optionally, each node can generate self-check information containing its key state information. This self-check information can be encapsulated and protected with a digital signature, which helps ensure the security and trustworthiness of information during network transmission. The generation and signing of self-check information is the basis for subsequent broadcasting, cross-checking, and consensus decision-making. It can effectively identify and isolate abnormal nodes in the network, reduce invalid network interactions and data synchronization, thereby improving consensus efficiency and overall network performance.

[0047] In one optional embodiment, the signature carried in the self-check information of the j-th node is verified by the i-th node using the public key of the j-th node, and the cross-check information of the i-th node on the j-th node is obtained after the signature verification is successful. This includes: verifying the signature carried in the self-check information of the j-th node using the public key of the j-th node by the i-th node; if the signature verification is successful, parsing the latest query transaction received by the j-th node from the self-check information of the j-th node; performing a hash calculation on the latest query transaction received by the j-th node by the i-th node to obtain a reference hash value; and determining the cross-check information of the i-th node on the j-th node based on the self-check information of the i-th node, the self-check information of the j-th node, and the reference hash value.

[0048] Optionally, after receiving the self-check information from the j-th node, the i-th node uses the j-th node's public key to verify the signature in the self-check information, thereby ensuring that the source of the data in the self-check information is trustworthy and that it has not been tampered with during transmission. Signature verification is the core of the digital signature mechanism; the authenticity of the private key signature can be determined by applying the public key.

[0049] Optionally, after signature verification, the i-th node parses the latest query transaction received by the j-th node from the self-check information. The i-th node performs the same execution on the query transaction locally and calculates the hash value of the transaction execution result to obtain a reference hash value. Query transactions are used to monitor node status and do not require network consensus; therefore, the query transactions received by each node may be different, but the hash value of their execution results can be used to verify the health status of the node.

[0050] Optionally, the i-th node compares the hash value in its self-check information with its own calculated reference hash value, and also compares the current blockchain height with the hash value. Based on the comparison results, the health status of the j-th node is determined. If all comparisons are consistent, the health status of the j-th node is determined to be "normal"; otherwise, depending on the specific inconsistency (such as different transaction execution results, mismatched block heights or hash values), the health status of the j-th node is marked as "abnormal," and the specific reason for the abnormality is recorded. Finally, the i-th node signs the cross-check results with its private key to generate new signature information.

[0051] Optionally, public key verification helps ensure the integrity of information and the credibility of the sender, strengthening the trust foundation of the network. Cross-checking node states using the execution results of query transactions can effectively identify abnormal node conditions, such as smart contract execution problems or block data errors. Public key verification is not limited to direct interaction between two nodes, but rather constructs a view of the health status of all nodes in the blockchain network through broadcasting and extensive verification among nodes in the network, thereby improving consensus efficiency and network stability.

[0052] In one optional embodiment, the cross-check information between the i-th node and the j-th node is determined based on the self-check information of the i-th node, the self-check information of the j-th node, and a reference hash value. This includes: reading the current blockchain height collected by the i-th node from its self-check information to obtain a first reference value; reading the current blockchain height collected by the j-th node from its self-check information to obtain a first comparison value; reading the hash value of the target block collected by the i-th node from its self-check information to obtain a second reference value; reading the hash value of the target block collected by the j-th node from its self-check information to obtain a second comparison value; taking the latest received query transaction determined during the self-check process of the j-th node as the target transaction, and obtaining the hash value of the transaction execution result determined by the j-th node regarding the target transaction to obtain a comparison hash value; and determining the cross-check information between the i-th node and the j-th node based on the first reference value, the first comparison value, the second reference value, the second comparison value, the reference hash value, and the comparison hash value.

[0053] Optionally, the current height of the blockchain, which is the length of the blockchain recorded by the i-th node at the time of its self-check, is extracted from the self-check information of the i-th node and used as the first reference value. This height reflects the synchronization status of the i-th node with the latest block.

[0054] Optionally, the current height of the blockchain of the j-th node is read from its self-check information to obtain the first comparison value, thereby comparing the blockchain synchronization status of the i-th node and the j-th node to determine whether the two are synchronized.

[0055] Optionally, the hash value of the target block, which is the block content digest corresponding to the current height, is read from the self-check information of the i-th node and the j-th node respectively, to obtain the second reference value and the second comparison value. The comparison of hash values ​​is the key to verifying the consistency of blockchain data between the two nodes.

[0056] Optionally, based on the latest query transaction recorded in the self-check information of the j-th node, the i-th node executes the same transaction and calculates the hash value of the transaction execution result, which is used as a reference hash value. This value is used to compare with the hash value of the transaction execution result provided in the self-check information of the j-th node to check the consistency of transaction execution.

[0057] Optionally, after completing data reading and comparison, the j-th node performs a comprehensive analysis based on the first reference value, the first comparison value, the second reference value, the second comparison value, the reference hash value, and the comparison hash value of the j-th node to determine the health status of the j-th node. Specifically, the i-th node first checks whether the first reference value and the first comparison value are equal, and whether the second reference value and the second comparison value match, to determine whether the block synchronization status of the j-th node is normal. If the blockchain height and the target block hash value both match, it indicates that the j-th node and the i-th node are consistent in blockchain synchronization, and the block synchronization status of the j-th node is healthy.

[0058] Optionally, the i-th node then compares the reference hash value with the corresponding hash value of the j-th node to verify whether the transaction execution of the j-th node is accurate. If the two hash values ​​match, it further confirms that the transaction processing module of the j-th node is operating normally and no transaction execution error has occurred.

[0059] Optionally, based on the comparison results, the i-th node forms health assessment information for the j-th node, including the node's status (healthy or abnormal) and the cause of the abnormality in the case of an abnormality (such as a smart contract execution module failure, data synchronization error, etc.). Finally, the i-th node integrates the assessment results into cross-check information and signs it using the i-th node's private key to generate an encrypted cross-check information signature, which helps to ensure the security and integrity of the information.

[0060] In one optional embodiment, determining the cross-check information of the i-th node to the j-th node based on the first reference value, the first comparison value, the second reference value, the second comparison value, the reference hash value, and the comparison hash value includes: when the first reference value and the first comparison value are equal, the second reference value and the second comparison value are equal, and the reference hash value and the comparison hash value are equal, determining the cross-check information of the i-th node to the j-th node as first information, wherein the first information indicates that the i-th node judges that the node status of the j-th node is normal.

[0061] Alternatively, the specific implementation steps are as follows:

[0062] Step 1. Data collection and comparison.

[0063] The i-th node first reads the first reference value, the first comparison value, the second reference value, and the second comparison value from the self-check information broadcast by the j-th node. Furthermore, the i-th node obtains the transaction execution result by executing the query transaction of the j-th node, and performs a hash calculation on the result to obtain a reference hash value; simultaneously, it reads the transaction execution result hash value provided by the j-th node from the self-check information broadcast by the j-th node as the comparison hash value.

[0064] Step 2. Cross-check information determination.

[0065] Under the conditions that the first reference value is equal to the first comparison value, the second reference value is equal to the second comparison value, and the reference hash value is equal to the comparison hash value, the i-th node determines that the j-th node's node state is normal. At this time, the i-th node integrates the determined node state (normal) into part of the node health cross-check result, which is the first information. The generation of the first information indicates that the j-th node is consistent with the i-th node in terms of blockchain height, block content, and transaction execution results. The j-th node is in a healthy state and can continue to participate in the consensus process and data synchronization.

[0066] Step 3. Message signing and broadcasting.

[0067] The i-th node uses its private key to sign the determined cross-check information (including the initial information and other relevant data). The signed cross-check information is then broadcast to other nodes in the blockchain network, enabling all nodes to make consensus adjustments based on the aforementioned information.

[0068] Based on the above steps, taking the health check of four nodes (node ​​0, node 1, node 2, and node 3) as an example, where Nid represents the ID of the node performing the self-check; Ht represents the height of the blockchain; Hs represents the hash value of the blockchain (i.e., the hash value of the block with height Ht); Txq represents the most recent query transaction received by the node. Because query transactions do not require network consensus, each node receives a different query transaction; Hrq represents the hash value of the execution result of the Txq query transaction; and Sig represents the hash value of the node's query result using its private key.<Nid,Ht,Hs,Txq,Hrq> The signature consists of five fields: SC represents the node's self-check result; St represents the health status of the corresponding node (healthy, abnormal); Cs represents the reason for the node's abnormality when St is abnormal, and this field is meaningless when St is healthy; CC represents the result of the node's cross-check of health.

[0069] For example, node 0 records the last received query transaction Txq0, executes this transaction to get the query result Rq0, calculates its hash value Hrq0, reads the current block height Ht0, reads the hash value Hs0 of the highest block, and signs the above data with the private key Kprv0 to get the self-check result Sig0=Sign(node0,Ht0,Hs0,Txq0,Hrq0,Kprv0), resulting in the self-check result SC0=<node0,Ht0,Hs0,Txq0,Hrq0,Sig0>.

[0070] Optionally, each node broadcasts the self-test results to all other nodes in the network: Node 0 sends SC0 to Node 1, Node 2, and Node 3; Node 1 sends SC1 to Node 0, Node 2, and Node 3; Node 2 sends SC2 to Node 0, Node 1, and Node 3; and Node 3 sends SC3 to Node 0, Node 1, and Node 2.

[0071] For example, when node 0 receives SC1=<node 1,Ht1,Hs1,Txq1,Hrq1,Sig1> from node 1, it first verifies the signature using node 1's public key Kpub1. If the signature verification is successful, it executes Txq1 and hashes the result to obtain Hrq1-0.

[0072] Optionally, the above is the first possibility for node 0 to compare whether Ht and Hs of SC1 and SC0 match, and whether Hrq1 and Hrq1-0 match. When Ht1=Ht0, Hs1=Hs0, and Hrq1=Hrq1-0, node 1 is judged to be in a healthy state St1. This is the most common case.

[0073] In one optional embodiment, the cross-check information of the i-th node to the j-th node is determined based on the first reference value, the first comparison value, the second reference value, the second comparison value, the reference hash value, and the comparison hash value. This includes: when the first reference value and the first comparison value are equal, the second reference value and the second comparison value are equal, and the reference hash value and the comparison hash value are not equal, the cross-check information of the i-th node to the j-th node is determined to be second information. The second information indicates that the i-th node judges that the node state of the j-th node is abnormal, and the reason for the abnormality is that the j-th node has a failure during the execution of the smart contract.

[0074] Optionally, when the i-th node detects that the first reference value is equal to the first comparison value and the second reference value is equal to the second comparison value, it indicates that the i-th node and the j-th node are synchronized in terms of blockchain height and block content, and their blockchain states are consistent. However, if the reference hash value is not equal to the comparison hash value at this time, it indicates that the output of the j-th node when executing the smart contract differs from that of other nodes in the network, which usually indicates that the smart contract execution module may be faulty.

[0075] Optionally, in the above scenario, the i-th node determines that the j-th node's state is abnormal, and integrates the information that the abnormality is due to a smart contract execution failure to generate second information. The generation of second information signifies that the i-th node has identified a potential problem with the j-th node, providing a basis for subsequent anomaly handling and network consensus adjustments.

[0076] Optionally, the i-th node uses its private key to sign the second information, generating encrypted signature information to ensure the authenticity and integrity of the information during transmission. The signed cross-check information can be broadcast to other nodes in the blockchain network, enabling all nodes to update the consensus state and handle abnormal nodes based on the cross-check information.

[0077] Optionally, the above is the second possibility for node 0 to compare whether Ht and Hs of SC1 and SC0 match, and to compare whether Hrq1 and Hrq1-0 match. When Ht1=Ht0, Hs1=Hs0, but Hrq1≠Hrq1-0, the state of node 1 is judged to be abnormal, the reason for the abnormality is Cs1=its smart contract execution module is faulty, and the abnormality handling method is to restart the smart contract execution module.

[0078] In one optional embodiment, the cross-check information of the i-th node to the j-th node is determined based on the first reference value, the first comparison value, the second reference value, the second comparison value, the reference hash value, and the comparison hash value. This includes: if the first reference value and the first comparison value are detected to be equal, and the second reference value and the second comparison value are not equal, or if the first reference value is detected to be greater than the first comparison value, the cross-check information of the i-th node to the j-th node is determined to be third information. The third information indicates that the i-th node judges that the node state of the j-th node is abnormal, and the reason for the abnormality is that the j-th node has made errors in the detection of the blockchain height and the judgment of the block.

[0079] Optionally, when the i-th node detects that the first reference value and the first comparison value are equal, but the second reference value and the second comparison value are not equal, it indicates that although the blockchain height reported by the j-th node is the same as that of the i-th node, the highest block content of the j-th node differs from the block content of the i-th node, suggesting that the j-th node may have made an error in processing the block. Similarly, when the i-th node finds that the first reference value is greater than the first comparison value, it indicates that the blockchain height of the j-th node lags behind that of the i-th node, and the j-th node has not synchronized the latest block data. This is also an abnormal situation, meaning that the j-th node has made an error in detecting the blockchain height or obtaining block data.

[0080] Optionally, in the two abnormal situations mentioned above, the i-th node determines the cross-check information as the third information, indicating that the i-th node judges the j-th node's node state to be abnormal, and the reason for the abnormality is that there are errors in the blockchain height detection and block judgment. The generation of the third information is based on the results of numerical comparison and hash verification, accurately pointing out the specific problems that the j-th node may have, and providing direction for subsequent anomaly handling.

[0081] Optionally, the i-th node uses its private key to cryptographically sign the third-party information to maintain its security and authenticity. The signed cross-check information is broadcast to other nodes in the blockchain network, enabling all nodes to adjust the consensus process based on the cross-check information, eliminate abnormal nodes, and simultaneously transmit repair instructions to abnormal nodes.

[0082] Optionally, the above is the third possibility for node 0 to compare whether Ht and Hs of SC1 and SC0 match, and to compare whether Hrq1 and Hrq1-0 match. When Ht1=Ht0, but Hs1≠Hs0, the state of node 1 is judged to be abnormal, the reason for the abnormality is Cs1=block error, and the abnormality handling method is to pull the block of the corresponding height from other nodes.

[0083] In an optional embodiment, cross-check information of the $i$-th node with respect to the $j$-th node is determined based on a first reference value, a first control value, a second reference value, a second control value, a reference hash value, and a control hash value, including: when it is detected that the first reference value is less than the first control value, determining the cross-check information of the $i$-th node with respect to the $j$-th node as fourth information, where the fourth information indicates that the node status of the $i$-th node is suspected to be abnormal, and the status judgment result of the $i$-th node with respect to the $j$-th node is untrustworthy.

[0084] Optionally, when the $i$-th node detects that the first reference value is less than the first control value, it indicates that the blockchain data synchronization status of the $i$-th node lags behind that of the $j$-th node, or the $i$-th node fails to accurately capture the latest status in the network. In this case, the health monitoring mechanism of the $i$-th node may not be sufficient to provide a trustworthy node status judgment because its own data status lags behind the network, and it may miss key block updates or consensus changes.

[0085] Optionally, in response to the above situation, when the $i$-th node determines the cross-check information as fourth information, it indicates that the node status of the $i$-th node is suspected to be abnormal, and the status judgment result of the $i$-th node with respect to the $j$-th node is untrustworthy. The generation of the fourth information alerts all nodes in the network about potential problems with the $i$-th node, indicating that additional verification or adjustment may be required in future consensus processes and data synchronization to ensure the health and efficiency of network operation.

[0086] Optionally, although the fourth information indicates that the status judgment of the $i$-th node is untrustworthy, it is still encrypted and signed using the private key of the $i$-th node to ensure the authenticity and integrity of the information itself. The signed fourth information will be broadcast to the network as feedback on the current status of the $i$-th node, prompting other nodes to take corresponding measures in consensus and data interaction, such as temporarily ignoring the data or transactions of the $i$-th node until its status is confirmed or it self-recovers.

[0087] Optionally, the above is the fourth possibility for node 0 to compare whether Ht and Hs of SC1 and SC0 match, and whether Hrq1 and Hrq1-0 match. When Ht1≠Ht0, there are two sub-cases:

[0088] In the first sub-case, if Ht1 < Ht0, it is determined that the status of node 1, St1 = abnormal, the reason for the abnormality, Cs1 = the block is incorrect, and the abnormal handling method is to pull the block corresponding to the height from other nodes.

[0089] In the second sub-case, if Ht1 > Ht0, it is determined that the status of node 0 itself may be abnormal. First, pull the block data after Ht1 from other nodes, and then re-judge after the pulling is completed.

[0090] In one optional embodiment, consensus is reached among the nodes on the distributed blockchain on the cross-check information corresponding to each node to obtain the state detection result of each node. This includes: reaching consensus among the nodes on the distributed blockchain on the cross-check information corresponding to each node; determining the x-th node as an abnormal node when the x-th node on the distributed blockchain is judged as having an abnormal node state by more than a preset number or a preset proportion of nodes, where x is an integer greater than or equal to 1; and performing a restart operation or a disable operation on the determined abnormal node, wherein the disable operation includes prohibiting it from participating in the consensus process and data processing process of the next round of transactions.

[0091] Optionally, in a distributed blockchain network, each node (such as the i-th node) generates cross-check information for other nodes, including but not limited to first information, second information, third information, and fourth information, which represent the i-th node's judgment on the health status of the j-th node.

[0092] Optionally, to ensure the accuracy of anomaly detection, a threshold needs to be set, that is, how many nodes must agree on the judgment before a node's status is considered reliable. The preset number or proportion can be flexibly set according to the network size and security requirements. For example, in a network with 10 nodes, the preset proportion might be 60%, meaning that at least 6 nodes must unanimously determine that a node is abnormal before it is considered an abnormal node.

[0093] Optionally, consensus is reached among the nodes on the distributed blockchain regarding the cross-check information corresponding to each node. Specifically, the i-th node broadcasts its cross-check information to the entire network, and other nodes compare and verify the received information with their own generated cross-check information, determining the state detection result of each node through a consensus algorithm. When the x-th node (x is an integer greater than or equal to 1) on the distributed blockchain is judged to be in an abnormal state by more than a preset number or a preset proportion of nodes, the network consensus confirms that the x-th node is an abnormal node.

[0094] Optionally, nodes identified as abnormal will be restarted, attempting to restore them to normal operating status by restarting relevant modules or the entire node. Alternatively, a disabling operation may be performed. For abnormal nodes, disabling includes preventing them from participating in the consensus process and data processing in the next round of transactions, to avoid negatively impacting network consensus and data synchronization. When a disabling operation is performed, the abnormal node will be temporarily isolated, no longer receiving or processing transaction data in the network or participating in consensus decisions, until its status returns to normal and it is re-confirmed as a healthy node through network consensus.

[0095] Optionally, for example, nodes 0, 1, 2, and 3 broadcast the cross-check results of all node health, CC0, CC1, CC2, and CC3, generated by each node to all other nodes.

[0096] Optionally, after each node collects the cross-check results of all node health broadcasts from other nodes, it uses a consensus algorithm to determine the consensus health of the corresponding node based on the St field. For example, for node 0, if 3 St=abnormal values ​​are collected, the node is considered to be in an abnormal state and is excluded from the consensus process. This can be done by not forwarding data to this node in the next round of transactions, or by not waiting for a response from this node, in order to avoid abnormal nodes causing negative impacts on the consensus process.

[0097] Furthermore, after collecting the cross-check results of all node health broadcasts from other nodes, each node uses the consensus algorithm to determine the cause of its abnormal state based on the Cs field if it determines that it is in an abnormal state. For example, for node 0, if it collects 3 Cs = consensus module abnormal, it restarts the consensus module to attempt to restore normal operation and prevent the problem from persisting.

[0098] Figure 2 is a schematic diagram of an optional state detection device for a distributed blockchain node according to an embodiment of this application. According to another aspect of an embodiment of this application, a state detection device for a distributed blockchain node is also provided, including: a self-testing unit 201, a broadcasting unit 202, a cross-checking unit 203, and a consensus unit 204.

[0099] The system includes a self-checking unit 201, which collects self-checking information from each node in the distributed blockchain, wherein each node's self-checking information carries its signature; a broadcasting unit 202, which broadcasts each node's self-checking information to all nodes in the distributed blockchain except the node in question; a cross-checking unit 203, which, after the i-th node receives the j-th node's self-checking information, verifies the signature carried in the j-th node's self-checking information using the j-th node's public key, and obtains the i-th node's cross-checking information for the j-th node after the signature verification is successful, wherein the i-th node and the j-th node are any two different nodes in the distributed blockchain; and a consensus unit 204, which, after broadcasting the cross-checking information corresponding to each node to all nodes in the distributed blockchain except the node in question, reaches a consensus on the cross-checking information corresponding to each node through the nodes in the distributed blockchain to obtain the detection result of each node.

[0100] Optionally, the self-checking unit 201 includes: a collection subunit, used to collect the node identifier, current blockchain height, hash value of the target block, latest received query transaction, and hash value of the transaction execution result of each node, wherein the target block is the block corresponding to the current blockchain height; and a signing subunit, used to sign the node identifier, current blockchain height, hash value of the latest block, latest received query transaction, and hash value of the transaction execution result collected by each node using its private key, to obtain the self-checking information of that node.

[0101] Optionally, the cross-checking unit 203 includes: a verification subunit, used to verify the signature carried in the self-checking information of the j-th node using the public key of the j-th node through the i-th node; a parsing subunit, used to parse the latest query transaction received by the j-th node from the self-checking information of the j-th node if the signature verification is successful; a hash calculation subunit, used to perform hash calculation on the latest query transaction received by the j-th node through the i-th node to obtain a reference hash value; and a determination subunit, used to determine the cross-checking information of the i-th node on the j-th node based on the self-checking information of the i-th node, the self-checking information of the j-th node, and the reference hash value.

[0102] Optionally, the determining subunit includes: a first reference value module, used to read the current blockchain height collected by the i-th node from the self-check information of the i-th node to obtain a first reference value; a first comparison value module, used to read the current blockchain height collected by the j-th node from the self-check information of the j-th node to obtain a first comparison value; a second reference value module, used to read the hash value of the target block collected by the i-th node from the self-check information of the i-th node to obtain a second reference value; a second comparison value module, used to read the hash value of the target block collected by the j-th node from the self-check information of the j-th node to obtain a second comparison value; a comparison hash value module, used to take the latest received query transaction determined during the self-check process of the j-th node as the target transaction, and obtain the hash value of the transaction execution result determined by the j-th node regarding the target transaction to obtain a comparison hash value; and a determining module, used to determine the cross-check information of the i-th node on the j-th node based on the first reference value, the first comparison value, the second reference value, the second comparison value, the reference hash value, and the comparison hash value.

[0103] Optionally, the determining module includes: when the first reference value and the first control value are equal, the second reference value and the second control value are equal, and the reference hash value and the control hash value are equal, determining the cross-check information of the i-th node to the j-th node as the first information, wherein the first information indicates that the i-th node judges that the node status of the j-th node is normal.

[0104] Optionally, the determining module includes: a determining second information submodule, used to determine the cross-check information of the i-th node to the j-th node as the second information when the first reference value and the first comparison value are equal, the second reference value and the second comparison value are equal, and the reference hash value and the comparison hash value are not equal. The second information indicates that the i-th node judges that the node state of the j-th node is abnormal, and the reason for the abnormality is that the j-th node has failed during the execution of the smart contract.

[0105] Optionally, the determining module includes: a third information determining submodule, used to determine the cross-check information of the i-th node to the j-th node as third information when the first reference value and the first control value are equal, the second reference value and the second control value are not equal, or when the first reference value is greater than the first control value. The third information indicates that the i-th node judges the j-th node's node state to be abnormal, and the reason for the abnormality is that the j-th node has made mistakes in the detection of the blockchain height and the judgment of the block.

[0106] Optionally, the determining module includes: a determining fourth information submodule, used to determine the cross-check information of the i-th node to the j-th node as the fourth information when the first reference value is detected to be less than the first control value, wherein the fourth information represents that the node state of the i-th node is suspected to be abnormal and the state judgment result of the i-th node to the j-th node is unreliable.

[0107] Optionally, consensus unit 204 includes: an anomaly determination subunit, used to reach consensus on the cross-check information corresponding to each node through the nodes on the distributed blockchain, and to determine the x-th node as an abnormal node when the x-th node on the distributed blockchain is judged as having an abnormal node state by more than a preset number or a preset proportion of nodes, where x is an integer greater than or equal to 1; and a disable subunit, used to perform a restart operation or a disable operation on the determined abnormal node, wherein the disable operation includes prohibiting participation in the consensus process and data processing process of the next round of transactions.

[0108] According to another aspect of the embodiments of this application, a computer-readable storage medium is also provided, which stores a computer program, wherein when the computer program is executed, the device where the computer-readable storage medium is located executes the above-described distributed blockchain node state detection method.

[0109] According to another aspect of the embodiments of this application, an electronic device is also provided, including one or more processors and a memory, the memory being used to store one or more programs, wherein when one or more programs are executed by one or more processors, the one or more processors cause the one or more processors to execute the above-described distributed blockchain node state detection method.

[0110] According to another aspect of the embodiments of this application, a computer program product is also provided, including a computer program or instructions, which, when executed by a processor, implement the above-described distributed blockchain node state detection method.

[0111] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0112] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0113] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units can be a logical functional division, and in actual implementation, there may be other division methods. For instance, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling, direct coupling, or communication connection may be through some interfaces; the indirect coupling or communication connection between units or modules may be electrical or other forms.

[0114] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0115] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0116] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.

[0117] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A method for detecting the state of a distributed blockchain node, characterized in that, include: The process involves collecting self-check information from each node on the distributed blockchain, where each node's self-check information carries its signature; broadcasting each node's self-check information to all other nodes on the distributed blockchain; after the i-th node receives the j-th node's self-check information, the i-th node verifies the signature carried in the j-th node's self-check information using the j-th node's public key, and after successful signature verification, obtaining the i-th node's cross-check information for the j-th node, where the i-th node and the j-th node are any two different nodes on the distributed blockchain; after broadcasting the cross-check information corresponding to each node to all other nodes on the distributed blockchain, the nodes on the distributed blockchain reach a consensus on the cross-check information corresponding to each node to obtain the detection result of each node.

2. The distributed blockchain node state detection method according to claim 1, characterized in that, Collecting self-check information from each node on the distributed blockchain includes: collecting each node's own node identifier, current blockchain height, hash value of the target block, latest received query transaction, and hash value of the transaction execution result, wherein the target block is the block corresponding to the current blockchain height; and signing the node identifier, current blockchain height, hash value of the latest block, latest received query transaction, and hash value of the transaction execution result collected by each node using its private key to obtain the node's self-check information.

3. The distributed blockchain node state detection method according to claim 1, characterized in that, The process involves the i-th node verifying the signature carried in the self-check information of the j-th node using the public key of the j-th node, and obtaining the cross-check information of the i-th node on the j-th node after the signature verification is successful. This includes: verifying the signature carried in the self-check information of the j-th node using the public key of the j-th node; if the signature verification is successful, parsing the latest query transaction received by the j-th node from the self-check information of the j-th node; performing a hash calculation on the latest query transaction received by the j-th node by the i-th node to obtain a reference hash value; and determining the cross-check information of the i-th node on the j-th node based on the self-check information of the i-th node, the self-check information of the j-th node, and the reference hash value.

4. The distributed blockchain node state detection method according to claim 3, characterized in that, Based on the self-check information of the i-th node, the self-check information of the j-th node, and the reference hash value, the cross-check information of the i-th node on the j-th node is determined, including: reading the current blockchain height collected by the i-th node from the self-check information of the i-th node to obtain a first reference value; reading the current blockchain height collected by the j-th node from the self-check information of the j-th node to obtain a first comparison value; and reading the hash value of the target block collected by the i-th node from the self-check information of the i-th node to obtain a second reference value. The hash value of the target block collected by the j-th node is read from the self-check information of the j-th node to obtain the second reference value; the latest received query transaction determined during the self-check process of the j-th node is taken as the target transaction, and the hash value of the transaction execution result of the target transaction determined by the j-th node is obtained to obtain the reference hash value; based on the first reference value, the first reference value, the second reference value, the second reference value, the reference hash value, and the reference hash value, the cross-check information of the i-th node on the j-th node is determined.

5. The distributed blockchain node state detection method according to claim 4, characterized in that, Based on the first reference value, the first comparison value, the second reference value, the second comparison value, the reference hash value, and the comparison hash value, the cross-check information of the i-th node to the j-th node is determined, including: when the first reference value and the first comparison value are equal, the second reference value and the second comparison value are equal, and the reference hash value and the comparison hash value are equal, the cross-check information of the i-th node to the j-th node is determined to be first information, wherein the first information indicates that the i-th node judges that the node status of the j-th node is normal.

6. The distributed blockchain node state detection method according to claim 4, characterized in that, Based on the first reference value, the first comparison value, the second reference value, the second comparison value, the reference hash value, and the comparison hash value, the cross-check information of the i-th node to the j-th node is determined, including: when the first reference value and the first comparison value are equal, the second reference value and the second comparison value are equal, and the reference hash value and the comparison hash value are not equal, the cross-check information of the i-th node to the j-th node is determined to be second information, wherein the second information indicates that the i-th node judges that the node state of the j-th node is abnormal, and the reason for the abnormality is that the j-th node has failed during the execution of the smart contract.

7. The distributed blockchain node state detection method according to claim 4, characterized in that, Based on the first reference value, the first comparison value, the second reference value, the second comparison value, the reference hash value, and the comparison hash value, the cross-check information of the i-th node to the j-th node is determined, including: when the first reference value and the first comparison value are detected to be equal, and the second reference value and the second comparison value are not equal, or when the first reference value is detected to be greater than the first comparison value, the cross-check information of the i-th node to the j-th node is determined to be third information, wherein the third information indicates that the i-th node judges that the node state of the j-th node is abnormal, and the reason for the abnormality is that the j-th node has made errors in the detection of blockchain height and block judgment.

8. The distributed blockchain node state detection method according to claim 4, characterized in that, Based on the first reference value, the first comparison value, the second reference value, the second comparison value, the reference hash value, and the comparison hash value, the cross-check information of the i-th node to the j-th node is determined, including: when the first reference value is detected to be less than the first comparison value, the cross-check information of the i-th node to the j-th node is determined to be fourth information, wherein the fourth information indicates that the node state of the i-th node is suspected to be abnormal, and the state judgment result of the i-th node to the j-th node is unreliable.

9. The state detection method for distributed blockchain nodes according to claim 1, characterized in that, The consensus is reached among the nodes on the distributed blockchain regarding the cross-check information corresponding to each node to obtain the state detection result of each node. This includes: reaching a consensus among the nodes on the distributed blockchain regarding the cross-check information corresponding to each node; if the x-th node on the distributed blockchain is judged to be in an abnormal state by more than a preset number or a preset proportion of nodes, the x-th node is determined to be an abnormal node, where x is an integer greater than or equal to 1; and performing a restart operation or a disable operation on the determined abnormal node, wherein the disable operation includes prohibiting it from participating in the consensus process and data processing process of the next round of transactions.

10. A state detection device for a distributed blockchain node, characterized in that, include: A self-checking unit is used to collect self-checking information from each node on the distributed blockchain, wherein the self-checking information of each node carries the signature of that node; a broadcasting unit is used to broadcast the self-checking information of each node to all nodes on the distributed blockchain except for the node in question; a cross-checking unit is used to, after the i-th node receives the self-checking information of the j-th node, verify the signature carried in the self-checking information of the j-th node using the public key of the j-th node, and obtain the cross-checking information of the i-th node on the j-th node after the signature verification is successful, wherein the i-th node and the j-th node are any two different nodes on the distributed blockchain; a consensus unit is used to, after broadcasting the cross-checking information corresponding to each node to all nodes on the distributed blockchain except for the node in question, reach a consensus on the cross-checking information corresponding to each node through all nodes on the distributed blockchain to obtain the detection result of each node.

11. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, wherein when the computer program is executed, the device containing the computer-readable storage medium performs the state detection method for a distributed blockchain node as described in any one of claims 1 to 9.

12. An electronic device, characterized in that, It includes one or more processors and a memory, the memory being used to store one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors cause the one or more processors to perform the state detection method for a distributed blockchain node according to any one of claims 1 to 9.

13. A computer program product, characterized in that, It includes a computer program or instructions that, when executed by a processor, implement the state detection method for a distributed blockchain node as described in any one of claims 1 to 9.

Images