CN115296812A - Block chain-based high-reliability recovery and check mechanism for electric power data storage nodes - Google Patents
Block chain-based high-reliability recovery and check mechanism for electric power data storage nodes Download PDFInfo
- Publication number
- CN115296812A CN115296812A CN202210713828.6A CN202210713828A CN115296812A CN 115296812 A CN115296812 A CN 115296812A CN 202210713828 A CN202210713828 A CN 202210713828A CN 115296812 A CN115296812 A CN 115296812A
- Authority
- CN
- China
- Prior art keywords
- node
- recovery
- data
- nodes
- recovered
- 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.)
- Pending
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
- H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/14—Error detection or correction of the data by redundancy in operation
- G06F11/1402—Saving, restoring, recovering or retrying
- G06F11/1446—Point-in-time backing up or restoration of persistent data
- G06F11/1458—Management of the backup or restore process
- G06F11/1464—Management of the backup or restore process for networked environments
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/14—Error detection or correction of the data by redundancy in operation
- G06F11/1402—Saving, restoring, recovering or retrying
- G06F11/1446—Point-in-time backing up or restoration of persistent data
- G06F11/1458—Management of the backup or restore process
- G06F11/1469—Backup restoration techniques
-
- G—PHYSICS
- G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
- G16Y—INFORMATION AND COMMUNICATION TECHNOLOGY SPECIALLY ADAPTED FOR THE INTERNET OF THINGS [IoT]
- G16Y10/00—Economic sectors
- G16Y10/35—Utilities, e.g. electricity, gas or water
-
- G—PHYSICS
- G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
- G16Y—INFORMATION AND COMMUNICATION TECHNOLOGY SPECIALLY ADAPTED FOR THE INTERNET OF THINGS [IoT]
- G16Y30/00—IoT infrastructure
- G16Y30/10—Security thereof
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/22—Arrangements for detecting or preventing errors in the information received using redundant apparatus to increase reliability
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/321—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority
- H04L9/3213—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority using tickets or tokens, e.g. Kerberos
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Theoretical Computer Science (AREA)
- Signal Processing (AREA)
- Computer Networks & Wireless Communication (AREA)
- Physics & Mathematics (AREA)
- Computing Systems (AREA)
- Quality & Reliability (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Business, Economics & Management (AREA)
- General Business, Economics & Management (AREA)
- Economics (AREA)
- Development Economics (AREA)
- Accounting & Taxation (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
The invention discloses a high-reliability recovery mechanism of a power data storage node based on a block chain, which comprises the following steps: s101, constructing a data recovery network environment; s102, constructing a data recovery mechanism message; s103, constructing a high-reliability recovery mechanism of the power data storage node based on the block chain; a high reliability verification mechanism for power data storage nodes based on a block chain comprises the following steps: s201, verifying the data block nodes, and distinguishing the nodes to obtain nodes to be recovered, recovery nodes and other nodes; s202, verifying the to-be-recovered node subjected to fault removal on the basis of the data of the recovery node again; the design based on the data recovery mechanism and the design of the verification mechanism solve the problem of low utilization rate of power data storage resources, improve the reliability of power data, and effectively optimize the redundancy backup of data storage nodes and related link resources.
Description
Technical Field
The invention relates to the field of data management of an electric power internet of things, in particular to a high-reliability recovery and verification mechanism of an electric power data storage node based on a block chain.
Background
With the rapid development and application of the power internet of things technology, the number and the service types of the power internet of things are rapidly increased. In this context, power data is increasing rapidly. Because the reliability of the electric power data is the premise of normal operation of the electric power internet of things, the reliable storage of the electric power data is more and more important. Methods of data recovery generally include both local data recovery and distributed data recovery techniques. Distributed data recovery has become the mainstream data recovery technology due to higher reliability and faster recovery performance. In order to reduce the problem of high calculation overhead in the data recovery process, an algorithm for calculating a data copy based on homomorphic encryption is proposed in a document [ Yi M, wei J, song l.efficient integration verification of a duplicated data in a closed computing system [ J ]. Computers & security,2017, 65 ]. In order to solve the problem of low data recovery efficiency in a cloud computing environment, documents [ Shen, chen, maoming, data storage disaster recovery backup simulation [ J ] based on an edge cloud collaborative network, computer simulation, 2021, 38 (05): 380-383+412] propose a dynamic data backup mechanism by analyzing characteristics of a data life cycle and popularity, and effectively reduce resource overhead of data recovery. In order to solve the problem of low data coding efficiency in data recovery, in documents [ Liu C, wang Q, chu X, et al, G-crs: gpu accessed computing required-solomon coding [ J ]. IEEE Transactions on Parallel and Distributed Systems,2018, 29 (7): 1484-1498 ], a GPU technology is adopted to perform erasure coding and bitwise storage on data, and the coding efficiency in the data recovery process is effectively improved. In order to solve the problem of low accuracy in traffic flow data recovery, a traffic flow speed missing data recovery algorithm [ J ] based on grid density technology is constructed in a document [ Zhang Jianzong, doudan, mobile crowd sensing ], a small-sized microcomputer system, 2021, 42 (02): 225-230 ], a traffic network model is constructed based on the grid density technology, data recovery characteristics based on data space-time characteristics are provided, and the accuracy of data recovery is effectively improved. In order to solve the problem of high calculation complexity in data recovery, documents [ Liu Ge, rui Guo Sheng, tian Wen Biao ] adopt a double regular matrix theory to provide a data recovery algorithm by missing data recovery [ J ] based on double regular matrix decomposition, system engineering and electronic technology, 2021, 43 (05): 1191-1197 ], and the efficiency of the data recovery algorithm is better improved. The document [ OSIPOV D, CHOW J H.PMU missing data recovery user decomposition [ J ]. IEEE Transactions on Power Systems,2020, 35 (6): 4554-4563 ] constructs a tensor decomposition model from three aspects of time, position and variables, and improves the accuracy of a data recovery result. In the document [ TAN M, YUAN S P, LI S H, et al. Ultra-short-term induced Power used for executing LSTM based hybrid ensemble learning [ J ]. IEEE Transactions on Power Systems,2020, 35 (4): 2937-2948 ], a data recovery model based on an LSTM network is constructed according to the time series relation of recovery data, the characteristics of subsequent data are analyzed, and the accuracy of data recovery is improved.
As can be known from the existing research, for the problem of how to improve the reliability of the power data, the existing research mainly optimizes the data storage nodes and the redundant backup of the related link resources. Although the reliability of the power data storage resources is improved, the system needs more backup resources and redundant resources, which causes the waste of network resources. In order to solve the problem, the invention provides a high-reliability recovery and verification mechanism of the power data storage node based on the block chain.
Disclosure of Invention
The present invention provides a high reliability recovery and check mechanism for a power data storage node based on a block chain, so as to solve the problems in the background art.
In order to achieve the purpose, the invention provides the following technical scheme:
a high-reliability recovery mechanism of a power data storage node based on a block chain comprises the following steps:
s101, constructing a data recovery network environment;
s102, constructing a data recovery mechanism message;
s103, constructing a high-reliability recovery mechanism of the power data storage node based on the block chain.
Preferably, the method for constructing the network environment in step S101 specifically includes:
the nodes of the power data storage system are divided into a node to be recovered, a recovery node and other nodes:
and (3) the node to be recovered: the power data storage node which has a fault needs to be quickly recovered in order to ensure the normal operation of related power services;
and (4) restoring the node: the node can quickly provide recovery data for the node to be recovered, and the node closer to the node to be recovered is generally selected to improve the efficiency of data recovery;
and other nodes: the power data storage system comprises nodes to be recovered and nodes except the recovery nodes.
Preferably, in step S102, the recovery mechanism message includes a data recovery basic message design, a data recovery request message design, a data block and whole data verification message design, and a data transmission message design:
the data recovery incoming message design comprises basic information, address information and block information;
the data recovery request message design comprises a recovery request, a recovery verification request and a recovery response;
the data block and overall data verification message design comprises an md5 request, an md5 response, an md5 overall verification request and an md5 verification response;
the data transmission message design comprises a data transmission request and a data transmission response.
Preferably, the recovery mechanism process in step S103 needs the participation of the node to be recovered, the recovery node, and other nodes, which is specifically as follows:
s1031, the node to be recovered sends out a data recovery request and is verified;
s1032, the node to be recovered and the recovery node adopt a data block transmission and verification mechanism to carry out block-by-block transmission and verification on data;
s1033, verifying the data as a whole: and after the node to be recovered obtains all data from the recovery node, verifying the data by adopting an md5 overall verification strategy.
Preferably, the specific steps of step S1031 are as follows:
(a) And (3) recovering the request:
the method comprises the steps that a node to be recovered detects that the node is damaged, a recovery process is started, the node to be recovered obtains the number m of healthy nodes on a chain, the number RecvNum of the recovery nodes is set to be m/3, the nodes to be recovered are rounded downwards, the physical distances between the nodes to be recovered and the m nodes are calculated, the RecvNum nodes closest to the node to be recovered can be obtained in a fast-row or small-top-pile construction mode, and the RecvNum nodes are set as the recovery nodes;
(b) And (3) verifying the recovery request:
the recovery node and other nodes receive the recovery request of the node to be recovered, verify whether the node type, the request parameter and the trusted token are correct or not, and after verification, send information of recovery verification to all the recovery nodes for the recovery nodes to verify;
(c) The recovery request is verified by:
the recovery node receives recovery verification information of more than 2m/3 healthy nodes, namely, a request of a node to be recovered can be determined to be legal, the recovery verification meets 2/3, the purpose is to tolerate the existence of a malicious node, the system can still perform effective verification and recovery under the condition that the malicious node exists, and after the recovery node determines that the recovery request of the node to be recovered is legal, a response message can be sent to the node to be recovered, the verification is informed to pass, and the available state of the node is indicated.
Preferably, the specific steps of step S1032 are as follows:
(a) And (3) restoring data transmission:
the method comprises the steps that md5 response information of all recovery nodes is processed by a node to be recovered, a reliable recovery node is selected for each block, a gPC message is constructed, rpc remote calling is executed, data is obtained in a streaming transmission mode, a gPC server, namely a recovery node end, identifies block information transmitted by the node to be recovered, the blocks are divided into data blocks with the size of 64KB again, data transmission is carried out in a streaming mode, and a gPC client, namely the node to be recovered, waits for streaming transmission of the server end and carries out splicing simultaneously after sending a request;
in the transmission process, different recovery nodes can adopt an asynchronous acquisition cooperative downloading mode or a synchronous mode aiming at different blocks, when the available bandwidth of the recovery node is more than or equal to that of the node to be recovered, the necessity of asynchronous cooperative downloading is not used, when the available bandwidth of the recovery node is lower, the cooperative downloading is used, and the cooperative processing of each fragment is started, so that the bandwidth utilization rate of the node end to be recovered can be effectively improved;
the data transfer uses a map structure taking the offset as key, because the offset of each block is independent, the condition that a plurality of blocks have the same offset does not exist, and the concurrent asynchronous data transmission does not cause the map to generate the concurrency problem, so that the common data storage structure can be used;
(b) And md5 data block verification:
the md5 request is the core content of the whole strategy, after the node to be recovered receives the recovery responses of all m/3 recovery nodes, the request is considered legal, all the recovery nodes are currently in an available state, if the node to be recovered does not receive enough recovery responses after overtime, the recovery request is reconstructed, and the recovery nodes which do not respond are skipped;
the method comprises the steps that a node to be recovered sets the number of fragments as the number of recovery nodes, aims to ensure that each recovery node shares three data blocks, assigns three data blocks to each recovery node in a random pool selection mode, sends a request to obtain an md5 value of the data blocks, further ensures that each md5 block can receive three redundant data from three different recovery nodes, compares the three data blocks, selects the most reliable md5 block, and selects the corresponding recovery node as a real data transmission node of the block;
the purpose of sending md5 is to avoid the existence of malicious data nodes, that is, the data of a certain recovery node is tampered, so that the recovered data is incorrect, and the fault tolerance rate of 1/3 malicious nodes is realized by a way of comparing three pieces of data, so that the reliability of final recovery cannot be affected when only one malicious node exists in three nodes of the blocking request, and meanwhile, md5 is transmitted to effectively reduce the network cost, and the recovery node does not need to transmit real data in the verification stage, and only the md5 corresponding to a block needs to be calculated for the verification of the node to be recovered;
and the recovery node receives the md5 request sent by the node to be recovered, calculates the md5 value of the corresponding block and sends the md5 value back to the node to be recovered so as to be verified by the node to be recovered.
Preferably, the specific method of step S1033 is:
and after the data splicing recovery is carried out on the nodes to be recovered, sending verification requests to all the nodes, verifying the validity of the requests by all the nodes, sending back md5 values of the data stored by the nodes, verifying whether the returned md5 values are the same as the spliced recovery data by the nodes to be recovered, and judging the recovery to be successful if the returned md5 values are the same as the spliced recovery data more than 2m + 1.
A high reliability verification mechanism for power data storage nodes based on a block chain comprises the following steps:
s201, verifying the data block nodes, and distinguishing the nodes to obtain nodes to be recovered, recovery nodes and other nodes;
s202, verifying the node to be recovered based on the data of the recovery node again, wherein the node to be recovered is subjected to failure relief.
Preferably, the specific operation method of S201 is:
and carrying out token verification on the basic information of the block node data, the request information of the block node data, the data block and integral verification information of the block node data and the transmission information of the block node data, and realizing effective division of the data block nodes based on the verification result of the information.
Preferably, the specific operation method of S202 is as follows:
and distinguishing the obtained nodes to be recovered based on the judgment of S201, and after data recovery, performing secondary verification, namely verifying the basic information of the block node data, the request information of the block node data, the data block and the integral verification information of the block node data and the transmission information of the block node data after the node is recovered.
Preferably, the S201 and the S202 are iterated for multiple times, so as to improve reliability of the entire verification mechanism, and a specific iterative verification process is as follows:
in the process of policy verification, setting the total number of nodes of the system as N, wherein the number of malicious nodes is M, controlling the number M of the malicious nodes to be less than N/3, and when the number of the malicious nodes is not in a control range, the policy is invalid;
a) Recovery check
A recovery verification step in the recovery nodes, wherein when M < N/3 is satisfied, the response success rate is 100%, the recovery verification step needs to verify the number of correct nodes, and when the total malicious nodes satisfy the control condition, the malicious nodes sending verification information in the recovery verification step do not exceed N/3, and the response success rate is 100%;
b) Restoring a response
The recovery response step, because all recovery nodes specified need to participate in the transmission and verification of data, all recovery nodes must be guaranteed to be correct nodes, as discussed in cases herein:
(1) All malicious nodes do not send recovery responses:
for the block chain data storage system, the probability that the node to be recovered initially is selected to be the malicious node is P 1 ：
Under extreme conditions, i.e. M = N/3, the probability of selecting a malicious node is P 2 ：
Under the general condition, that is, when M =1, the probability of selecting a malicious node is P 3 ：
In consideration of the fact that malicious nodes are few under the common condition, the overall success rate is over 60%.
Universal adaptive malicious node probability function P, associated with M
And when the response recovery step fails, the system automatically throws away the malicious nodes contained currently.
The number of malicious nodes after the first removal is expected to be D 1 ：
The number of malicious nodes after the n-th removal is expected to be D n ：
D n ＝E n (E n-1 (E n-2 (E n-3 (...E 1 (M))))) (6)
After the malicious node is removed, the probability of successful response for n times is P 4 ：
When n increases, P 4 Tending towards 1, the system is guaranteed to verify successfully through an attempt;
(2) All malicious nodes send recovery responses, but the data transmission in the subsequent steps is all wrong:
when a malicious node normally sends a response, the success rate of the step is 100%, the problem of subsequent data transmission is considered, namely, a malicious node exists in the transmission step, the md5 request step verifies the authenticity of data by acquiring data blocks md5 of three nodes, certain possibility exists that a plurality of malicious nodes transmit the same error md5, the node to be recovered is misjudged, the subsequent data splicing is completed, a certain part of the data blocks is malicious data, but the subsequent data blocks can be identified by the verification request of the whole md5, because the whole malicious node does not exceed 1/3 of the total number, when the malicious data exists, the node to be recovered can detect the data error, the recovered data is abandoned, and the request is initiated again.
Preferably, the basic message of the block node data in S201 specifically includes the following:
basic information: the basic information refers to a basic structure which each information needs to contain, the Id is set as a unique identifier of the message, and the content and meaning contained in the basic information are as follows:
MessageId: the independent Id of the message is used for identifying a unique message and is randomly generated each time;
MessageName: the name of the message is used for realizing the service monitoring and forwarding of different messages;
from: the node number of the request is sent;
to: receiving a node number of the request;
timestamp: the time stamp when the message is constructed is used for judging overtime;
address information: the design is mainly aimed at the verification and test of a single-machine pseudo-distributed system, distributed nodes can select the same port to monitor service, and the content and meaning contained in address information are as follows:
IP: the IP address of the node;
port: the tcp service of the node monitors a port, the default of the system is set to be 80xx, and the last two bits are node numbers;
blocking information: the method is used for unified blocking operation, the original request level md5 is empty, the blocking position is determined by the group of Offset and Size, and the subsequent md5 sends back the blocking information carrying md5. The blocking information includes the following contents and meanings:
offset: dividing data offset;
size: the size of the block data;
md5: the data md5 is divided into blocks, two messages in the md5 verification step are requested in a unified manner, and md5 can be null;
preferably, the request message of the block node data in S201 specifically includes the following steps:
and (3) recovering the request: the request is initiated by the node to be recovered actively and used as an entrance of the whole recovery system, the node to be recovered selects one third of the total nodes of the recovery nodes, a nearest recovery node list is obtained through sequencing, and the recovery request is sent to all the nodes, wherein the recovery request comprises the following contents and meanings:
BaseAccess: a basic message;
token: the method comprises the steps that a token is safely admitted to a node to be recovered, and whether a recovery request is legal or not is verified through the token;
BlockList: calculating a selected recovery node list by the nodes to be recovered according to the total node number and the physical distance;
and (3) recovering the checking request: after all the nodes receive the recovery requests sent by the nodes to be recovered, after token verification is carried out, the recovery verification requests are sent to all the recovery nodes to verify whether the recovery requests of the nodes to be recovered are legal or not, and the recovery verification requests comprise the following contents and meanings:
base message: a basic message;
ReqId: id of the recovery request;
isVerify: whether the verification is successful;
RecvBlock: a recovery node sending a validation request;
BlockList: restoring the node list;
and (4) recovering response: all recovery nodes can receive recovery check requests sent by all nodes theoretically, whether token of a node to be recovered passes credibility verification is verified by verifying an isVerify variable, when the isVerify exceeds two thirds, the node to be recovered is proved to be credible, namely recovery response information is sent back, wherein the carried Size is used for informing the actual data Size of the node to be recovered, the Size of blocks can be further calculated by the node to be recovered, the offset of the blocks is used for correctly constructing a selection pool for the blocks, and the recovery response comprises the following contents and meanings:
BaseAccess: a basic message;
ReqId: a message Id of the recovery request;
size: the size of the total data is used for carrying out block calculation when md5 is subsequently requested;
BlockList: restoring the node list;
preferably, the data block and the overall verification message of the block node data in S201 specifically include the following:
the md5 requests: when the nodes to be recovered receive the recovery responses of all the recovery nodes, it is proved that all the recovery nodes pass the verification and can perform data recovery online, at this time, the nodes to be recovered perform block construction through a block algorithm, and send md5 requests to all the recovery nodes, where md5 values of three blocks specified in the services are expected to be obtained, and the content and meaning of the md5 requests are as follows:
BaseAccess: a basic message;
slices: blocking information;
md5 response: the recovery node receives the md5 request, carries out md5 calculation according to the fragments specified in the Slices, splices the fragments into the original Slices structure, and sends back the node to be recovered for the verification of the node to be recovered, wherein the content and meaning of the md5 response are as follows:
BaseAccess: a basic message;
slices: blocking information;
md5 overall authentication request: after data recovery, the node to be recovered sends an md5 verification request to all nodes to obtain md5 values of all nodes, so that no error occurs in data splicing, and the md5 overall verification request contains BaseAccess;
md5 validation response: all nodes send an md5 value back for checking the node to be recovered, where md5 is sent, instead of sending md5 by the node to be recovered, all nodes send back verification information, mainly considering that when a malicious node exists, the verification message sent back by the node may have a problem, so the verification step is transferred to the node to be recovered, and the content and meaning of the md5 verification response are as follows:
BaseAccess: a basic message;
and md5: md5 of node data.
Preferably, the transmission message of the block node data in S201 specifically includes the following:
a data transmission request: the blocks are invisible to the gPCs, the offset and the size of data specified by a protobuf protocol are designed, namely, a protobuf message request is automatically constructed after md5 is verified, the offset and the size corresponding to the blocks are calculated, and the content and the meaning of the data transmission request are as follows:
base message: the content of the BaseAccess constructed by protobuf is the same as that of the BaseAccess in the tcp protocol;
offset: specifying an offset of the transmission data;
size: specifying a size of transmission data;
data transmission response: in the process of processing by the gPC server, the offset and the size of the request are subdivided and divided into 64KB data blocks, the 64KB data are transmitted each time and spliced in the gPC service of the client, a large amount of data stored in a block link point is transmitted in a block streaming transmission mode, and the content and meaning of a data transmission response are as follows:
base message: the content of the BaseAddress constructed by protobuf is the same as that of the BaseAddress in the tcp protocol;
offset: specifying an offset of the transmission data;
size: specifying a size of transmission data;
data: a byte stream of actual data.
Compared with the prior art, the invention has the beneficial effects that:
according to the invention, the power data nodes are divided into the nodes to be recovered, the recovery nodes and other nodes, so that effective data internal use is realized, the uniformity of the recovered nodes is ensured, and the problem of low utilization rate of power data storage resources is solved, the reliability of power data is improved and the redundancy backup of the data storage nodes and related link resources is effectively optimized based on the design of a data recovery mechanism and the design of a verification mechanism.
Drawings
FIG. 1 is a schematic flow chart of a block chain-based high-reliability recovery and verification mechanism for an electrical data storage node according to the present invention;
fig. 2 is a schematic diagram of a high-reliability recovery and check mechanism of a power data storage node based on a block chain.
Detailed Description
The technical solutions will be described clearly and completely in the following with reference to the embodiments of the present invention, and it is obvious that the described embodiments are only a part of the embodiments of the present invention, and not all embodiments. All other embodiments, which can be obtained by a person skilled in the art without making any creative effort based on the embodiments in the present invention, belong to the protection scope of the present invention.
Examples
A high-reliability recovery mechanism of a power data storage node based on a block chain comprises the following steps:
s101, constructing a data recovery network environment;
s102, constructing a data recovery mechanism message;
s103, constructing a high-reliability recovery mechanism of the power data storage node based on the block chain.
Specifically, in step S101, the method for constructing the network environment specifically includes:
the nodes of the power data storage system are divided into a node to be recovered, a recovery node and other nodes:
and (3) the node to be recovered: the power data storage node is a power data storage node which has a fault, and needs to be quickly recovered in order to guarantee the normal operation of related power services;
and (3) restoring the node: the node can quickly provide recovery data for the node to be recovered, and the node closer to the node to be recovered is generally selected to improve the efficiency of data recovery;
and other nodes: the node to be recovered in the power data storage system and the nodes except the recovery node are indicated.
Specifically, in step S102, the mechanism messages are recovered, including data recovery basic message design, data recovery request message design, data block and overall data verification message design, and data transmission message design:
the data recovery incoming message design comprises basic information, address information and block information;
the data recovery request message design comprises a recovery request, a recovery verification request and a recovery response;
the data block and overall data verification message design comprises an md5 request, an md5 response, an md5 overall verification request and an md5 verification response;
the data transmission message design comprises a data transmission request and a data transmission response.
Specifically, the recovery mechanism process in step S103 needs the participation of the node to be recovered, the recovery node, and other nodes, which is specifically as follows:
s1031, the node to be recovered sends out a data recovery request and is verified;
s1032, the node to be recovered and the recovery node adopt a data block transmission and verification mechanism to carry out block-by-block transmission and verification on data;
s1033, verifying the whole data: and after the node to be recovered obtains all data from the recovery node, verifying the data by adopting an md5 overall verification strategy.
Specifically, the specific steps of step S1031 are as follows:
(a) And (3) recovering the request:
the method comprises the steps that a node to be recovered detects that the node is damaged, a recovery process is started, the node to be recovered obtains the number m of healthy nodes on a chain, the number RecvNum of the recovery nodes is set to be m/3, the nodes to be recovered are rounded downwards, the physical distances between the nodes to be recovered and the m nodes are calculated, the RecvNum nodes closest to the node to be recovered can be obtained in a fast-row or small-top-pile construction mode, and the RecvNum nodes are set as the recovery nodes;
(b) And (3) recovery request verification:
the recovery nodes and other nodes receive the recovery requests of the nodes to be recovered, verify whether the node types, the request parameters and the trusted tokens are correct or not, and after the verification is passed, send information of recovery verification to all the recovery nodes so that the recovery nodes can perform verification;
(c) The recovery request is verified by:
the recovery node receives recovery verification information of more than 2m/3 healthy nodes, namely, a request of a node to be recovered can be determined to be legal, the recovery verification meets 2/3, the purpose is to tolerate the existence of a malicious node, the system can still perform effective verification and recovery under the condition that the malicious node exists, and after the recovery node determines that the recovery request of the node to be recovered is legal, a response message can be sent to the node to be recovered, the verification is informed to pass, and the available state of the node is indicated.
Specifically, the specific steps of step S1032 are as follows:
(a) And (3) restoring data transmission:
the method comprises the steps that md5 response information of all recovery nodes is processed by a node to be recovered, a reliable recovery node is selected for each block, a gPC message is constructed, rpc remote calling is executed, data is obtained in a streaming transmission mode, a gPC server, namely a recovery node end, identifies block information transmitted by the node to be recovered, the blocks are divided into data blocks with the size of 64KB again, data transmission is carried out in a streaming mode, and a gPC client, namely the node to be recovered, waits for streaming transmission of the server end and carries out splicing simultaneously after sending a request;
in the transmission process, different recovery nodes can adopt an asynchronous acquisition cooperative downloading mode or a synchronous mode aiming at different blocks, when the available bandwidth of the recovery node is more than or equal to that of the node to be recovered, the necessity of asynchronous cooperative downloading is not used, when the available bandwidth of the recovery node is lower, the cooperative downloading is used, and the cooperative processing of each fragment is started, so that the bandwidth utilization rate of the node end to be recovered can be effectively improved;
the data transfer uses a map structure taking the offset as key, because the offset of each block is independent, the condition that a plurality of blocks have the same offset does not exist, and the concurrent asynchronous data transmission does not cause the map to generate the concurrency problem, so that the common data storage structure can be used;
(b) And md5 data block verification:
the md5 request is the core content of the whole strategy, after the node to be recovered receives the recovery responses of all m/3 recovery nodes, the request is considered legal, all the recovery nodes are currently in an available state, if the node to be recovered does not receive enough recovery responses after overtime, the recovery request is reconstructed, and the recovery nodes which do not respond are skipped;
the method comprises the steps that a node to be recovered sets the number of fragments as the number of recovery nodes, aims to ensure that each recovery node shares three data blocks, assigns three data blocks to each recovery node in a random pool selection mode, sends a request to obtain an md5 value of the data blocks, further ensures that each md5 block can receive three redundant data from three different recovery nodes, compares the three data blocks, selects the most reliable md5 block, and selects the corresponding recovery node as a real data transmission node of the block;
the purpose of sending md5 is to avoid the existence of malicious data nodes, that is, data of a recovery node is tampered, so that the data which is recovered is incorrect, and the fault tolerance rate of 1/3 malicious nodes is realized by means of triple data comparison, so that it is ensured that the reliability of final recovery cannot be affected when only one malicious node exists in three nodes of the blocking request, and meanwhile, md5 transmission effectively reduces the network cost, and the recovery node does not need to transmit real data in the verification stage, and only needs to calculate md5 of the corresponding block for the verification of the node to be recovered;
and the recovery node receives the md5 request sent by the node to be recovered, calculates the md5 value of the corresponding block and sends the md5 value back to the node to be recovered so as to be verified by the node to be recovered.
Specifically, the specific method in step S1033 is:
and after the data splicing recovery is carried out on the nodes to be recovered, sending verification requests to all the nodes, verifying the validity of the requests by all the nodes, sending back md5 values of the data stored by the nodes, verifying whether the returned md5 values are the same as the spliced recovery data by the nodes to be recovered, and judging the recovery to be successful if the returned md5 values are the same as the spliced recovery data more than 2m + 1.
A high reliability verification mechanism for power data storage nodes based on a block chain comprises the following steps:
s201, verifying the data block nodes, and distinguishing the nodes to obtain nodes to be recovered, recovery nodes and other nodes;
s202, verifying the node to be recovered based on the data of the recovery node again, wherein the node to be recovered is subjected to failure relief.
Specifically, the specific operation method of S201 is:
and carrying out token verification on the basic message of the block node data, the request message of the block node data, the data block and integral verification message of the block node data and the transmission message of the block node data, and realizing effective division of the data block nodes based on the verification result of the messages.
Specifically, the specific operation method of S202 is:
and distinguishing the obtained nodes to be recovered based on the judgment of S201, and after data recovery, performing secondary verification, namely verifying the basic information of the block node data, the request information of the block node data, the data block and the integral verification information of the block node data and the transmission information of the block node data after the node recovery.
Specifically, the S201 and the S202 perform multiple iterations, so as to improve the reliability of the whole verification mechanism, and a specific iterative verification process is as follows:
in the process of strategy verification, the total node number of the system is set to be N, wherein the malicious node number is M, the malicious node number M is controlled to be less than N/3, and when the malicious node number is not in the control range, the strategy is invalid;
a) Recovery check
A recovery check step in the recovery nodes, wherein when M is less than N/3, the response success rate is 100%, the recovery check step needs to verify the number of correct nodes, and when the total malicious nodes meet the control condition, the malicious nodes sending check information in the recovery check step do not exceed N/3, and the response success rate is 100%;
b) Restoring the response
The recovery response step, because all recovery nodes specified need to participate in the transmission and verification of data, all recovery nodes must be guaranteed to be correct nodes, as discussed in cases herein:
(1) All malicious nodes do not send recovery responses:
for the block chain data storage system, the probability that the node to be recovered initially is selected to be the malicious node is P 1 ：
Under extreme conditions, i.e. M = N/3, the probability of selecting a malicious node is P 2 ：
Under the general condition, that is, when M =1, the probability of selecting a malicious node is P 3 ：
The number of malicious nodes is considered to be small under the common condition, and the overall success rate is over 60 percent.
Universal malicious node probability function P, associated with M
And when the response recovery step fails, the system automatically discards the malicious nodes contained currently.
The number of malicious nodes after the first removal is expected to be D 1 ：
The number of malicious nodes after the n-th removal is expected to be D n ：
D n ＝E n (E n-1 (E n-2 )(E n-3 (...E 1 (M))))) (6)
After the malicious nodes are removed, the probability of successful response for n times is P 4 ：
When n increases, P 4 Tending towards 1, the system is guaranteed to verify successfully through an attempt;
(2) All malicious nodes send recovery responses, but the data transmission in the subsequent steps is all wrong:
when a malicious node normally sends a response, the success rate of the step is 100%, the problem of subsequent data transmission is considered, namely, a malicious node exists in the transmission step, the md5 request step verifies the authenticity of data by acquiring data blocks md5 of three nodes, certain possibility exists that a plurality of malicious nodes transmit the same error md5, the node to be recovered is misjudged, the subsequent data splicing is completed, a certain part of the data blocks is malicious data, but the subsequent data blocks can be identified by the verification request of the whole md5, because the whole malicious node does not exceed 1/3 of the total number, when the malicious data exists, the node to be recovered can detect the data error, the recovered data is abandoned, and the request is initiated again.
Specifically, the basic message of the block node data in S201 specifically includes the following:
basic information: the basic information refers to a basic structure which each information needs to contain, the Id is set as a unique identifier of the message, and the content and meaning contained in the basic information are as follows:
MessageId: the independent Id of the message is used for identifying a unique message and is randomly generated each time;
MessageName: the name of the message is used for realizing the service monitoring and forwarding of different messages;
from: sending the node number of the request;
to: receiving a node number of the request;
timestamp: the time stamp when the message is constructed is used for judging overtime;
address information: the design is mainly aimed at the verification and test of a single-machine pseudo-distributed system, distributed nodes can select the same port to monitor service, and the content and meaning contained in address information are as follows:
IP: the IP address of the node;
port: the tcp service monitoring port of the node is set as 80xx by default, and the last two bits are node numbers;
blocking information: the method is used for unified blocking operation, the position of the block is empty at the initial request level md5, the block position is determined through the Offset and Size groups, and the subsequent md5 sends back the block information and carries md5. The blocking information includes the following contents and meanings:
offset: dividing data block offset;
size: dividing the data size;
md5: dividing data md5, uniformly requesting two messages of the md5 verification step, wherein md5 can be null;
specifically, the request message of the block node data in S201 specifically includes the following steps:
and (3) recovering the request: the request is initiatively initiated by the nodes to be recovered and used as an entrance of the whole recovery system, the nodes to be recovered select one third of the recovery nodes of the total nodes, a nearest recovery node list is obtained through sequencing, the recovery requests are sent to all the nodes, and the content and meaning of the recovery requests are as follows:
BaseAccess: a basic message;
token: the method comprises the steps that a token is safely admitted to a node to be recovered, and whether a recovery request is legal or not is verified through the token;
BlockList: calculating a selected recovery node list by the nodes to be recovered according to the total node number and the physical distance;
and (3) recovering the checking request: after all nodes receive the recovery requests sent by the nodes to be recovered, after token verification is carried out, the recovery verification requests are sent to all the recovery nodes to verify whether the recovery requests of the nodes to be recovered are legal or not, and the recovery verification requests comprise the following contents and meanings:
BaseAccess: a basic message;
ReqId: id of the recovery request;
isVerify: whether the verification is successful;
RecvBlock: a recovery node sending a validation request;
BlockList: restoring the node list;
and (3) recovering response: all recovery nodes can receive recovery check requests sent by all nodes theoretically, whether token of a node to be recovered passes credibility verification is verified by verifying an isVerify variable, when the isVerify exceeds two thirds, the node to be recovered is proved to be credible, namely recovery response information is sent back, wherein the carried Size is used for informing the actual data Size of the node to be recovered, the Size of blocks can be further calculated by the node to be recovered, the offset of the blocks is used for correctly constructing a selection pool for the blocks, and the recovery response comprises the following contents and meanings:
base message: a basic message;
ReqId: a message Id of the recovery request;
size: the size of the total data is used for carrying out block calculation when md5 is subsequently requested;
BlockList: restoring the node list;
specifically, the data block and the overall verification message of the block node data in S201 specifically include the following:
md5 requests: when the nodes to be recovered receive the recovery responses of all the recovery nodes, it is proved that all the recovery nodes pass the verification and can perform data recovery online, at this time, the nodes to be recovered perform block construction through a block algorithm, and send md5 requests to all the recovery nodes, where md5 values of three blocks specified in the services are expected to be obtained, and the content and meaning of the md5 requests are as follows:
BaseAccess: a basic message;
slices: blocking information;
md5 response: the recovery node receives the md5 request, carries out md5 calculation according to the fragments specified in the Slices, splices the fragments into the original Slices structure, and sends back the node to be recovered for the verification of the node to be recovered, wherein the content and meaning of the md5 response are as follows:
BaseAccess: a basic message;
slices: blocking information;
md5 overall authentication request: after data recovery, the node to be recovered sends an md5 verification request to all nodes to obtain md5 values of all nodes, so that no error occurs in data splicing, and the md5 overall verification request contains BaseAccess;
md5 validation response: all nodes send an md5 value back for checking the node to be recovered, here, md5 is sent, but the node to be recovered does not send md5, all nodes send back verification information, mainly considering that when a malicious node exists, the verification message sent back by the node may have problems, so the verification step is transferred to the node to be recovered, and the content and meaning of the md5 verification response are as follows:
base message: a basic message;
md5: md5 of node data.
Specifically, the transmission message of the block node data in S201 specifically includes the following:
data transmission request: the blocks are invisible to the gPCs, the offset and the size of data specified by a protobuf protocol are designed, namely, a protobuf message request is automatically constructed after md5 is verified, the offset and the size corresponding to the blocks are calculated, and the content and the meaning of the data transmission request are as follows:
BaseAccess: the content of the BaseAccess constructed by protobuf is the same as that of the BaseAccess in the tcp protocol;
offset: specifying an offset of the transmitted data;
size: specifying a size of transmission data;
and (3) data transmission response: in the process of processing by the gPC server, the offset and the size of the request are subdivided, the request is divided into 64KB data blocks, the 64KB data is transmitted each time, the data is spliced in the gPC service of the client, a large amount of data stored in a block link point is transmitted in a block streaming transmission mode, and the content and the meaning of a data transmission response are as follows:
base message: the content of the BaseAccess constructed by protobuf is the same as that of the BaseAccess in the tcp protocol;
offset: specifying an offset of the transmitted data;
size: specifying a size of transmission data;
data: a byte stream of actual data.
Although embodiments of the present invention have been shown and described, it will be appreciated by those skilled in the art that changes, modifications, substitutions and alterations can be made in these embodiments without departing from the principles and spirit of the invention, the scope of which is defined in the appended claims and their equivalents.
Claims (15)
1. A high-reliability recovery mechanism for a power data storage node based on a block chain is characterized by comprising the following steps:
s101, constructing a data recovery network environment;
s102, constructing a data recovery mechanism message;
s103, constructing a high-reliability recovery mechanism of the power data storage node based on the block chain.
2. The mechanism for recovering the high reliability of the block chain-based power data storage node according to claim 1, wherein in step S101, the method for constructing the network environment specifically comprises:
the nodes of the power data storage system are divided into a node to be recovered, a recovery node and other nodes:
and (3) the node to be recovered: the power data storage node which has a fault needs to be quickly recovered in order to ensure the normal operation of related power services;
and (4) restoring the node: the node can quickly provide recovery data for the node to be recovered, and the node closer to the node to be recovered is generally selected to improve the efficiency of data recovery;
and other nodes: the power data storage system comprises nodes to be recovered and nodes except the recovery nodes.
3. The blockchain-based power data storage node high reliability recovery mechanism according to claim 1, wherein in step S102, recovery mechanism messages including data recovery basic message design, data recovery request message design, data block and whole data verification message design, data transmission message design are recovered:
the data recovery incoming message design comprises basic information, address information and block information;
the data recovery request message design comprises a recovery request, a recovery verification request and a recovery response;
the data block and overall data verification message design comprises an md5 request, an md5 response, an md5 overall verification request and an md5 verification response;
the data transmission message design comprises a data transmission request and a data transmission response.
4. The block chain-based power data storage node high-reliability recovery mechanism according to claim 2, wherein the recovery mechanism process in step S103 requires participation of a node to be recovered, a recovery node, and other nodes, and specifically includes the following steps:
s1031, the node to be recovered sends out a data recovery request and is verified;
s1032, the node to be recovered and the recovery node adopt a data block transmission and verification mechanism to carry out block-by-block transmission and verification on data;
s1033, verifying the data as a whole: and after the node to be recovered obtains all data from the recovery node, verifying the data by adopting an md5 overall verification strategy.
5. The mechanism for recovering high reliability of a power data storage node based on a block chain according to claim 4, wherein the specific steps of step S1031 are as follows:
(a) And (3) recovering the request:
the method comprises the steps that a node to be recovered detects that the node is damaged, a recovery process is started, the node to be recovered obtains the number m of healthy nodes on a chain, the number RecvNum of the recovery nodes is set to be m/3, the nodes to be recovered are rounded downwards, the physical distances between the nodes to be recovered and the m nodes are calculated, the RecvNum nodes closest to the node to be recovered can be obtained in a fast-row or small-top-pile construction mode, and the RecvNum nodes are set as the recovery nodes;
(b) And (3) recovery request verification:
the recovery node and other nodes receive the recovery request of the node to be recovered, verify whether the node type, the request parameter and the trusted token are correct or not, and after verification, send information of recovery verification to all the recovery nodes for the recovery nodes to verify;
(c) The recovery request is verified by:
the recovery node receives recovery verification information of more than 2m/3 healthy nodes, namely, a request of a node to be recovered can be determined to be legal, the recovery verification meets 2/3, the purpose is to tolerate the existence of a malicious node, the system can still perform effective verification and recovery under the condition that the malicious node exists, and after the recovery node determines that the recovery request of the node to be recovered is legal, a response message can be sent to the node to be recovered, the verification is informed to pass, and the available state of the node is indicated.
6. The mechanism for high reliability recovery of power data storage nodes based on block chains according to claim 4, wherein the specific steps of the step S1032 are as follows:
(a) And (3) restoring data transmission:
processing md5 response information of all recovery nodes by a node to be recovered, selecting a reliable recovery node for each block, constructing a gPRC message, executing rpc remote call, acquiring data in a streaming transmission mode, identifying block information transmitted by the node to be recovered by a gPRC server, namely the recovery node, dividing the blocks into data blocks with the size of 64KB again, performing data transmission in a streaming mode, and waiting for streaming transmission of the server and splicing the data blocks after a gPRC client, namely the node to be recovered sends a request;
in the transmission process, aiming at different blocks, different recovery nodes can adopt an asynchronous acquisition cooperative downloading mode or a synchronous mode, when the available bandwidth of the recovery node is more than or equal to that of the node to be recovered, the necessity of asynchronous cooperative downloading is not used, when the available bandwidth of the recovery node is lower, the cooperative downloading is used, and the cooperative processing of each block is started, so that the bandwidth utilization rate of the node end to be recovered can be effectively improved;
the data transfer uses a map structure taking the offset as key, because the offset of each block is independent, the condition that a plurality of blocks have the same offset does not exist, and the concurrent asynchronous data transmission does not cause the map to generate the concurrency problem, so that the common data storage structure can be used;
(b) And md5 data block verification:
the md5 request is the core content of the whole strategy, after the node to be recovered receives the recovery responses of all m/3 recovery nodes, the request is considered legal, all the recovery nodes are currently in an available state, if the node to be recovered does not receive enough recovery responses after overtime, the recovery request is reconstructed, and the recovery nodes which do not respond are skipped;
the method comprises the steps that the number of fragments is set as the number of recovery nodes by the nodes to be recovered, the purpose is to ensure that each recovery node shares three data blocks, three data blocks are assigned to each recovery node in a random pool selection mode, a request is sent to obtain an md5 value of each data block, each md5 block can be ensured to receive three redundant data from three different recovery nodes, the nodes to be recovered select the most reliable md5 block by comparing the three data blocks, and the corresponding recovery node is selected as a real data transmission node of the block;
the purpose of sending md5 is to avoid the existence of malicious data nodes, that is, data of a recovery node is tampered, so that the data which is recovered is incorrect, and the fault tolerance rate of 1/3 malicious nodes is realized by means of triple data comparison, so that it is ensured that the reliability of final recovery cannot be affected when only one malicious node exists in three nodes of the blocking request, and meanwhile, md5 transmission effectively reduces the network cost, and the recovery node does not need to transmit real data in the verification stage, and only needs to calculate md5 of the corresponding block for the verification of the node to be recovered;
and the recovery node receives the md5 request sent by the node to be recovered, calculates the md5 value of the corresponding block and sends the md5 value back to the node to be recovered so as to be verified by the node to be recovered.
7. The mechanism for recovering the high reliability of the power data storage node based on the block chain as claimed in claim 4, wherein the specific method of step S1033 is:
and after the data splicing recovery is carried out on the nodes to be recovered, sending verification requests to all the nodes, verifying the validity of the requests by all the nodes, sending back md5 values of the data stored by the nodes, verifying whether the returned md5 values are the same as the spliced recovery data by the nodes to be recovered, and judging the recovery to be successful if the returned md5 values are the same as the spliced recovery data more than 2m + 1.
8. A high reliability verification mechanism for power data storage nodes based on a block chain is characterized by comprising the following steps:
s201, verifying the data block nodes, and distinguishing the nodes to obtain nodes to be recovered, recovery nodes and other nodes;
s202, verifying the node to be recovered based on the data of the recovery node again, wherein the node to be recovered is subjected to failure relief.
9. The mechanism for checking high reliability of power data storage nodes based on block chains according to claim 5, wherein the specific operation method of S201 is as follows:
and carrying out token verification on the basic message of the block node data, the request message of the block node data, the data block and integral verification message of the block node data and the transmission message of the block node data, and realizing effective division of the data block nodes based on the verification result of the messages.
10. The mechanism for checking high reliability of power data storage nodes based on block chain as claimed in claim 5, wherein the specific operation method of S202 is as follows:
and distinguishing the obtained nodes to be recovered based on the judgment of S201, and after data recovery, performing secondary verification, namely verifying the basic information of the block node data, the request information of the block node data, the data block and the integral verification information of the block node data and the transmission information of the block node data after the node recovery.
11. The block chain-based electric power data storage node high reliability check mechanism according to claim 5, wherein S201 and S202 are iterated for a plurality of times, so as to improve reliability of the entire check mechanism, and a specific iterative check process is as follows:
in the process of strategy verification, the total node number of the system is set to be N, wherein the malicious node number is M, the malicious node number M is controlled to be less than N/3, and when the malicious node number is not in the control range, the strategy is invalid;
a) Recovery check
A recovery check step in the recovery nodes, wherein when M is less than N/3, the response success rate is 100%, the recovery check step needs to verify the number of correct nodes, and when the total malicious nodes meet the control condition, the malicious nodes sending check information in the recovery check step do not exceed N/3, and the response success rate is 100%;
b) Restoring a response
The recovery response step, because all recovery nodes specified need to participate in the data transmission and verification, all recovery nodes must be guaranteed to be correct nodes, as discussed in the cases:
(1) All malicious nodes do not send recovery responses:
for the block chain data storage system, the probability that the node to be recovered is initially selected to be the malicious node is P 1 ：
Under extreme conditions, i.e. M = N/3, the probability of selecting a malicious node is P 2 ：
Under the general condition, that is, when M =1, the probability of selecting a malicious node is P 3 ：
In consideration of the fact that malicious nodes are few under the common condition, the overall success rate is over 60%.
Universal adaptive malicious node probability function P, associated with M
And when the response recovery step fails, the system automatically discards the malicious nodes contained currently.
The number of malicious nodes after the first removal is expected to be D 1 ：
The number of malicious nodes after the n-th removal is expected to be D n ：
D n ＝E n (E n-1 (E n-2 (E n-3 (...E 1 (M))))) (6)
After the malicious nodes are removed, the probability of successful response for n times is P 4 ：
When n increases, P 4 Tending towards 1, the system is guaranteed to verify successfully through an attempt;
(2) All malicious nodes send recovery responses, but the data transmission in the subsequent steps is all wrong:
when a malicious node normally sends a response, the success rate of the step is 100%, the problem of subsequent data transmission is considered, namely, the malicious node exists in the transmission step, the md5 request step verifies the authenticity of data by acquiring data blocks md5 of three nodes, the existence of certain possibility that a plurality of malicious nodes transmit the same error md5 results in misjudgment of a node to be recovered, the subsequent data splicing is completed, and a certain part of the data blocks is malicious data, but the subsequent data can be identified through the verification request of the whole md5, because the total number of the whole malicious nodes does not exceed 1/3 of the total number of the whole malicious nodes, when the malicious data exists, the node to be recovered can detect the data error, and then give up the recovered data, and the request is initiated again.
12. The mechanism according to claim 6, wherein the basic message of the block node data in S201 specifically includes the following:
basic information: the basic information refers to a basic structure which each information needs to contain, the Id is set as a unique identifier of the message, and the content and meaning contained in the basic information are as follows:
MessageId: the independent Id of the message is used for identifying a unique message and is randomly generated each time;
MessageName: the name of the message is used for realizing the service monitoring and forwarding of different messages;
from: sending the node number of the request;
to: receiving a node number of the request;
timestamp: the time stamp when the message is constructed is used for judging overtime;
address information: the design is mainly aimed at the verification and test of a single-machine pseudo-distributed system, distributed nodes can select the same port to monitor service, and the content and meaning contained in address information are as follows:
IP: the IP address of the node;
port: the tcp service monitoring port of the node is set as 80xx by default, and the last two bits are node numbers;
blocking information: the method is used for unified blocking operation, the original request level md5 is empty, the blocking position is determined by the group of Offset and Size, and the subsequent md5 sends back the blocking information carrying md5. The content and meaning of the blocking information are as follows:
offset: dividing data offset;
size: dividing the data size;
and md5: and (5) dividing the data md5, unifying two messages for requesting the md5 verification step, wherein md5 can be null.
13. The mechanism according to claim 6, wherein the request message for block node data in S201 includes the following specific steps:
and (3) recovering the request: the request is initiatively initiated by the nodes to be recovered and used as an entrance of the whole recovery system, the nodes to be recovered select one third of the recovery nodes of the total nodes, a nearest recovery node list is obtained through sequencing, the recovery requests are sent to all the nodes, and the content and meaning of the recovery requests are as follows:
BaseAccess: a basic message;
token: the method comprises the steps that a token is safely admitted to a node to be recovered, and whether a recovery request is legal or not is verified through the token;
BlockList: calculating a selected recovery node list by the nodes to be recovered according to the total node number and the physical distance;
and (3) recovering the verification request: after all the nodes receive the recovery requests sent by the nodes to be recovered, after token verification is carried out, the recovery verification requests are sent to all the recovery nodes to verify whether the recovery requests of the nodes to be recovered are legal or not, and the recovery verification requests comprise the following contents and meanings:
BaseAccess: a basic message;
ReqId: id of the recovery request;
isVerify: whether the verification is successful;
RecvBlock: a recovery node sending a validation request;
BlockList: restoring the node list;
and (3) recovering response: all recovery nodes can receive recovery check requests sent by all nodes theoretically, check whether the token of a node to be recovered passes credibility verification by verifying an isVerify variable, prove that the node to be recovered is credible when the isVerify variable exceeds two thirds, namely, send back recovery response information, wherein the carried Size is used for informing the actual data Size of the node to be recovered, further ensuring that the node to be recovered can calculate the Size of blocks, the offset of the blocks and correctly constructing a selection pool for the blocks, and the recovery response comprises the following contents and meanings:
BaseAccess: a basic message;
ReqId: a message Id of the recovery request;
size: the size of the total data is used for carrying out block calculation when md5 is subsequently requested;
BlockList: the node list is restored.
14. The mechanism according to claim 6, wherein the data block and global verification message of the block node data in S201 includes:
md5 requests: when the nodes to be recovered receive the recovery responses of all the recovery nodes, it is proved that all the recovery nodes pass the verification and can perform data recovery online, at the moment, the nodes to be recovered perform block construction through a block algorithm, and send md5 requests to all the recovery nodes, where the md5 requests expect to obtain md5 values of three blocks specified in the services, and the md5 requests include the following contents and meanings:
BaseAccess: a basic message;
slices: blocking information;
md5 response: the recovery node receives the md5 request, carries out md5 calculation according to the fragments specified in the Slices, splices the fragments into the original Slices structure, and sends back the node to be recovered for the verification of the node to be recovered, wherein the content and meaning of the md5 response are as follows:
BaseAccess: a basic message;
slices: blocking information;
md5 overall authentication request: after data recovery, the node to be recovered sends md5 verification requests to all nodes to obtain md5 values of all nodes, so that no error occurs in data splicing, and the md5 overall verification request contains base message;
md5 validation response: all nodes send an md5 value back for checking the node to be recovered, here, md5 is sent, but the node to be recovered does not send md5, all nodes send back verification information, mainly considering that when a malicious node exists, the verification message sent back by the node may have problems, so the verification step is transferred to the node to be recovered, and the content and meaning of the md5 verification response are as follows:
BaseAccess: a basic message;
md5: md5 of node data.
15. The mechanism according to claim 6, wherein the transmission message of the block node data in S201 specifically includes the following:
data transmission request: the blocks are invisible to gPCs, the offset and the size of data specified by a protobuf protocol are designed, namely, a protobuf message request is automatically constructed after md5 is verified, the offset and the size corresponding to the blocks are calculated, and the content and the meaning of the data transmission request are as follows:
BaseAccess: the content of the BaseAddress constructed by protobuf is the same as that of the BaseAddress in the tcp protocol;
offset: specifying an offset of the transmitted data;
size: specifying a size of transmission data;
and (3) data transmission response: in the process of processing by the gPC server, the offset and the size of the request are subdivided, the request is divided into 64KB data blocks, the 64KB data is transmitted each time, the data is spliced in the gPC service of the client, a large amount of data stored in a block link point is transmitted in a block streaming transmission mode, and the content and the meaning of a data transmission response are as follows:
BaseAccess: the content of the BaseAccess constructed by protobuf is the same as that of the BaseAccess in the tcp protocol;
offset: specifying an offset of the transmission data;
size: specifying a size of transmission data;
data: a byte stream of actual data.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210713828.6A CN115296812A (en) | 2022-06-22 | 2022-06-22 | Block chain-based high-reliability recovery and check mechanism for electric power data storage nodes |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210713828.6A CN115296812A (en) | 2022-06-22 | 2022-06-22 | Block chain-based high-reliability recovery and check mechanism for electric power data storage nodes |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN115296812A true CN115296812A (en) | 2022-11-04 |
Family
ID=83821262
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202210713828.6A Pending CN115296812A (en) | 2022-06-22 | 2022-06-22 | Block chain-based high-reliability recovery and check mechanism for electric power data storage nodes |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN115296812A (en) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN116991623A (en) * | 2023-08-30 | 2023-11-03 | 杭州趣链科技有限公司 | Block chain node exception recovery method and device, electronic equipment and storage medium |
-
2022
- 2022-06-22 CN CN202210713828.6A patent/CN115296812A/en active Pending
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN116991623A (en) * | 2023-08-30 | 2023-11-03 | 杭州趣链科技有限公司 | Block chain node exception recovery method and device, electronic equipment and storage medium |
| CN116991623B (en) * | 2023-08-30 | 2024-01-02 | 杭州趣链科技有限公司 | Block chain node exception recovery method and device, electronic equipment and storage medium |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| KR102237219B1 (en) | Achieving consensus among network nodes in a distributed system | |
| TWI705690B (en) | System for changing master node in distributed network | |
| US20220385460A1 (en) | Systems and methods for selecting and utilizing a committee of validator nodes in a distributed system | |
| CN111131209B (en) | Improved efficient consensus method, system, computer device and storage medium | |
| US20180308091A1 (en) | Fairness preserving byzantine agreements | |
| JP7012879B2 (en) | Consensus on storage of shared blockchain data based on error correction code | |
| TWI740575B (en) | Method, system and device for prioritizing shared blockchain data storage | |
| CN112600678B (en) | Data processing method, device, equipment and storage medium | |
| WO2005010689A2 (en) | Secure cluster configuration data set transfer protocol | |
| CN112149105A (en) | Data processing system, method, related device and storage medium | |
| CN112395113B (en) | Practical Bayesian fault-tolerant consensus method and device and readable storage medium | |
| CN114745140B (en) | Urban planning field block chain consensus verification method and system based on aggregation encryption | |
| CN115296812A (en) | Block chain-based high-reliability recovery and check mechanism for electric power data storage nodes | |
| US11307790B2 (en) | Method, device, and computer program product for managing data placement | |
| EP3834116A1 (en) | System and method for accessing a data repository | |
| Li et al. | A framework to support survivable web services | |
| Kang et al. | Blockchain-based high-reliability recovery and verification mechanism for power data storage nodes | |
| Wu et al. | MEChain: A multi-layer blockchain structure with hierarchical consensus for secure EHR system | |
| CN111147575B (en) | Data storage system based on block chain | |
| US11115221B2 (en) | Verifying a rebuilt encoded data slice using slice verification information | |
| CN115733678A (en) | Data recovery method and device | |
| Wang et al. | Defense against sybil attack in blockchain based on improved consensus algorithm | |
| CN114115748B (en) | Intelligent management method based on big data information safety and big data information system | |
| CN116192868B (en) | Parallel Bayesian fault tolerance consensus method and terminal applied to alliance chain | |
| Manevich et al. | Arma: Byzantine Fault Tolerant Consensus with Horizontal Scalability |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |