CN115065689B - Alliance chain block data storage method and system based on historical evaluation - Google Patents
Alliance chain block data storage method and system based on historical evaluation Download PDFInfo
- Publication number
- CN115065689B CN115065689B CN202210650385.0A CN202210650385A CN115065689B CN 115065689 B CN115065689 B CN 115065689B CN 202210650385 A CN202210650385 A CN 202210650385A CN 115065689 B CN115065689 B CN 115065689B
- Authority
- CN
- China
- Prior art keywords
- node
- nodes
- block
- data
- aggregation
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
- 238000000034 method Methods 0.000 title claims abstract description 61
- 238000011156 evaluation Methods 0.000 title claims abstract description 35
- 238000013500 data storage Methods 0.000 title claims description 17
- 238000003860 storage Methods 0.000 claims abstract description 53
- 230000008569 process Effects 0.000 claims abstract description 28
- 230000007246 mechanism Effects 0.000 claims abstract description 16
- 238000013210 evaluation model Methods 0.000 claims abstract description 15
- 230000003993 interaction Effects 0.000 claims abstract description 8
- 230000002776 aggregation Effects 0.000 claims description 73
- 238000004220 aggregation Methods 0.000 claims description 73
- 230000002159 abnormal effect Effects 0.000 claims description 37
- 230000009191 jumping Effects 0.000 claims description 17
- 238000012544 monitoring process Methods 0.000 claims description 14
- 238000009826 distribution Methods 0.000 claims description 13
- 238000010606 normalization Methods 0.000 claims description 10
- 230000006870 function Effects 0.000 claims description 9
- 238000000605 extraction Methods 0.000 claims description 5
- 230000000737 periodic effect Effects 0.000 claims description 4
- 238000004364 calculation method Methods 0.000 claims description 3
- 238000004806 packaging method and process Methods 0.000 claims description 3
- 238000002474 experimental method Methods 0.000 description 7
- 238000010586 diagram Methods 0.000 description 6
- 239000011159 matrix material Substances 0.000 description 6
- 238000004891 communication Methods 0.000 description 5
- 239000012634 fragment Substances 0.000 description 4
- 230000006872 improvement Effects 0.000 description 4
- 230000006399 behavior Effects 0.000 description 3
- 230000006835 compression Effects 0.000 description 3
- 238000007906 compression Methods 0.000 description 3
- 238000011161 development Methods 0.000 description 3
- 238000005457 optimization Methods 0.000 description 3
- 238000012795 verification Methods 0.000 description 3
- 230000009286 beneficial effect Effects 0.000 description 2
- 230000005540 biological transmission Effects 0.000 description 2
- 238000012937 correction Methods 0.000 description 2
- 238000005304 joining Methods 0.000 description 2
- 238000004458 analytical method Methods 0.000 description 1
- 238000013459 approach Methods 0.000 description 1
- 230000008901 benefit Effects 0.000 description 1
- 230000001186 cumulative effect Effects 0.000 description 1
- 238000012217 deletion Methods 0.000 description 1
- 230000037430 deletion Effects 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 230000002708 enhancing effect Effects 0.000 description 1
- 238000012854 evaluation process Methods 0.000 description 1
- 238000013467 fragmentation Methods 0.000 description 1
- 238000006062 fragmentation reaction Methods 0.000 description 1
- 238000012858 packaging process Methods 0.000 description 1
- 238000004321 preservation Methods 0.000 description 1
- 230000004044 response Effects 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
- 230000001360 synchronised effect Effects 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/104—Peer-to-peer [P2P] networks
-
- 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/004—Arrangements for detecting or preventing errors in the information received by using forward error control
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/14—Network analysis or design
- H04L41/145—Network analysis or design involving simulating, designing, planning or modelling of a network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/104—Peer-to-peer [P2P] networks
- H04L67/1044—Group management mechanisms
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/104—Peer-to-peer [P2P] networks
- H04L67/1074—Peer-to-peer [P2P] networks for supporting data block transmission mechanisms
- H04L67/1078—Resource delivery mechanisms
- H04L67/108—Resource delivery mechanisms characterised by resources being split in blocks or fragments
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1095—Replication or mirroring of data, e.g. scheduling or transport for data synchronisation between network nodes
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1097—Protocols in which an application is distributed across nodes in the network for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]
-
- 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
-
- 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/3247—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 digital signatures
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
- H04L2209/34—Encoding or coding, e.g. Huffman coding or error correction
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Physics & Mathematics (AREA)
- Computing Systems (AREA)
- Mathematical Physics (AREA)
- Theoretical Computer Science (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
The invention provides a method and a system for storing alliance chain block data based on historical evaluation, wherein the method comprises the following steps: step S1, establishing a collaborative storage model based on erasure codes, distributing all nodes in a network into a plurality of collaborative groups according to roles, and performing collaborative block storage by using erasure codes among the nodes in each collaborative group; step S2, continuously recording interaction states of other nodes in a preset period through each node, and summarizing service quality of each node according to an evaluation model; and step S3, summarizing the scoring lists and forming global node score ordering, and randomly distributing nodes by adopting a password lottery mode. The invention processes the corresponding relation between the nodes and the data blocks based on the node allocation mechanism of the historical evaluation, can identify the nodes with better running state and grant higher storage authority, and simultaneously evaluates the nodes by combining with the service quality, and allocates the nodes by periodically summarizing the evaluation and utilizing the password lottery algorithm.
Description
Technical Field
The invention relates to a block data storage method, in particular to a historical evaluation-based alliance chain block data storage method, and further relates to an alliance chain block data storage system adopting the historical evaluation-based alliance chain block data storage method.
Background
The cost of use for operators is constantly increasing due to the non-tamperable nature of blockchains. The storage mechanism affects the cost of the deployment of the blockchain application, and the high storage cost becomes a core element for restricting the development of the blockchain application. Sun Zhixin et al in an overview, divide existing schemes into two basic types, under-chain storage and on-chain storage, based on data storage locations, where blockchain nodes hold all blockdata in an on-chain storage model, while under-chain storage stores portions of the data outside of the blockchain system, with nodes having only a few descriptive information and external storage indices.
The on-chain storage can be subdivided into four models of light nodes, compression coding, fragmentation and erasure coding, and the off-chain storage can be divided into two models of IPFS and DHT. The covr is an improved decentralised, unlicensed light node protocol, and the main contribution is to propose a fraud proof protocol to let the verifying node quickly interpret that a block includes illegal transactions, and combine the parity check code with the merkel tree to ensure that a complete block is obtained even if all information cannot be downloaded. Alexander et al propose a snapshot-based bit coin data encoding model, where the system periodically snapshots the block data and stores it in a new block, which is connected to the backbone and forms a special double-chain architecture. LightChain is the first fully decentralized, unlicensed, scalable blockchain architecture based on DHT, with the key point that every node has an opportunity to participate fairly in the consensus cycle of the next cycle. LightChain uses a hop-based DHT addressing strategy, each node uses a numeric ID or name ID as a unique identification of the hop, and at most only O (logn) times are needed for any messaging.
While it is more desirable to reduce the amount of storage for nodes that maintain network operation, light nodes cannot meet the above requirements, IPFS-based schemes require relatively high costs while publicizing the data within the federation, and DHT schemes are also unsuitable for federation chain environments where the number of nodes is relatively small and risk data security. There is therefore a need for a solution that considers the federated chain environment from the compression coding and erasure coding model. The erasure code can recover all original data without all fragments, and the characteristic is very suitable for the Bayesian environment with malicious and fault nodes. The frequency of block access queries generated early is typically very low, but each node still stores the full amount of block transaction data, which creates storage pressure for the node. The storage scheme combined with the erasure codes can enable the node to store only one fragment of the transaction set, and complete block transaction information can be recovered in real time when needed.
If a node is able to always exhibit better operation during operation, this results in the allocation of data blocks to that node each time. This imbalance of allocation can create two problems, firstly because of having multiple rounds of data blocks, the data request load of the node is significantly higher than other nodes, affecting the normal operation of the node; second, since the allocation results are predictable, the node is more vulnerable to attack, since higher revenue is more easily obtained from the attack on the node. Therefore, the node also needs to consider the requirements of load balancing and random selection in the process of selecting and pulling.
Among them, zhang Yao of university of electronic technology proposes a local storage optimization method study of blockchain. The flow of using the method in a federated chain is shown in FIG. 2. The flow comprises four nodes including a common node, a light node, a common node and a central node. The network is divided into three network layers of a P2P network, a consensus network and a packet network, wherein the packet and the consensus network are contained in the P2P network. Each node is connected in a P2P network, and the consensus node and the lightweight nodes are distributed in respective packet networks. The complete blockchain is distributed across the P2P network, while the coded slices of data are valid only within the packet network.
The system flow of local storage of such a blockchain is as follows:
(1) And adding into the system. Each member node may be selected to be either a regular node or a lightweight node when joining the federation chain. If the node is selected to be a light node, the node is not different from the node of the common alliance chain, the node is not grouped, the complete block information is required to be downloaded, and the local storage cannot be optimized. If the node chooses to be a lightweight node, a packet request will be sent to the hub node.
(2) And (5) grouping the requests. The node is selected to be a lightweight node and a request is sent to the central node. After receiving the request, the central node allocates the node to the group with less members according to the current group state, and returns the address of the leading node of the group and the corresponding coding matrix to the application node. At this time, the central node broadcasts a special transaction to the whole network, wherein the transaction comprises the application grouping node address and the corresponding consensus node address after grouping. Only the central node can send the special transaction type containing the node grouping information, the central node can only send the special transaction, and cannot send the common transaction. The transaction is verified by the common node of the whole network, the node in the transaction is verified to be present, and the special transaction which is verified successfully is packaged into a block to be used as a grouping certificate.
(3) And adding the packet. After obtaining the address and the coding matrix of the leading node of a certain group from the central node, the application node sends an application to the corresponding consensus node, and after verifying the address and the coding matrix, the consensus node confirms the network connection and returns the address information of the group member node. The application node is added to the network topology of the encoded transmission. After joining the packet, the node also needs to synchronize complete block history data from the whole network through the P2P network (the node obtains the history block, which does not involve the code slice, is communication at the whole network level of the system).
(4) Coding and slice deletion. After the complete block data is synchronized, the nodes encode the block data according to the grouped encoding matrix to obtain encoded data slices of each block, and the original block data is deleted. According to the self storage performance, part of the coded data slices are deleted randomly, so that the light node is formed.
(5) Slice acquisition when a node needs to acquire historical transaction data, the node in the group acquires the encoded slice. In (3) it is accepted that the group leader consensus node has returned to the requesting node a list of other lightweight node members in the group during the group request phase. The node initiates an application to the nodes in the list to acquire the coding slice. The node receiving the data acquisition application retrieves the local data and transmits the required data slice. In the federation chain, the group membership number problem after grouping is considered. If the number of members is too small, the number of slices of a block reserved in the packet may be smaller than the number of slices required for reconstruction, so that the block cannot be decoded and reconstructed. In this case, the chunk complete data may be obtained from the leader nodes of the group, as each leader consensus node of the group has complete chunk data.
(6) After receiving enough coded data slices, the block reconstruction carries out data reconstruction operation through the inverse matrix of the coding matrix according to the slice marks. And obtaining complete block data after completion.
In the existing block chain local storage mode, the corresponding relation between the erasure codes and the nodes is not set, so that a certain coding slice is possibly deleted by all the nodes at the same time, the original block cannot be coded and reconstructed, and the risk of data loss exists, and the practicability is influenced. And the total memory size of such a scheme increases linearly with block height, an important consideration is needed to balance the two types of requirements of security and storage.
Another approach is a BFT-Store based architecture, a blockchain storage engine with a bayer-type fault tolerance on one node. The client submits a Transaction (TXs) to the blockchain, which is packaged in blocks for the nodes to agree on. Each block after network consensus is then written to BFT-Store for storage. The client reads the block by sending a request to a node in the BFT-Store. The function of the BFT-Store can be divided into two functions: block coding and block reading.
Block coding, BFT-Store architecture uses (n-2 f,2 f) -RS to code blocks. Every n-2f are represented as { B ] 1 ,…,B n-2f The original blocks of } are encoded to generate 2f parity. The original n-2f blocks and 2f parity then make up n slices with { C 1 ,…,C n-2f ,…,C n And } represents. Can be { C 1 ,…,C n-2f ,…,C n Any n-2f slices in the block are decrypted to obtain n-2f original blocks. The n slices are distributed over n nodes, where each node retains a unique slice. Thus, each node stores only one small segment rather than the entire blockchain. In an unsafe environment, no trusted third party encodes the blocks and distributes the blocks. BFT-Store requires each node to independently encode a block without any network communication. Block B 1 ~B n-2f Is generated by blockchain consensus so that all honest nodes will get the same block. Each node maintains a block buffer to buffer newly generated blocks in the encoded groups prior to encoding. After each collection of n-2f slices from the consensus, each node encodes these into n slices, selects one from among them for local preservation, and deletes the other slices to improve space efficiency.
Block reading for reading a block B i The client sends its request to a node P, called the delegated node. At BFIn T-Store, node P reads block B i And are faced with different situations. Comprising the following steps: (1) If node P is block B i Then node P may read B locally i And sent directly to the client. If block B i In the block buffer of P, node P may process the request locally. (2) If node P is not block B i Can pull B from its target node P i . Honest node P' will use RO method to B i Transmitted back to P. (3) If the malicious target node P' responds to the node P being empty or abnormal, the node P forcefully recovers all the blocks B through RS decoding 1 ~B n-2f . To this end, node P broadcasts a request to all nodes, and other nodes send back slices they store in the same code group. Once n-2f correct slices are collected, node P will recover B by RS decoding 1 ~B n-2f And directly restore block B i To the client. As an optimization of RD case, if a node has cached block B i In its buffer, block B will be directly processed i Instead of the slice being sent to node P, node P is prevented from decoding.
BFT-Store uses a threshold signature as a proof of a slice. Specifically, each node broadcasts the signatures of all slices in the encoded set after encoding, and when n-2f signatures are collected for each slice, the signatures are aggregated into a single signature by (n, n-2 f) ts. When requested, each node sends a threshold signature back with the slice. Thus, the node can ensure that at least the n-2f node once verified through this slice by verifying the threshold signature. Of the n-2f nodes (n-2 f-f=n-3 f+.gtoreq.1), at least one honest node verifies passing the slice. Thus, even if a node is known to a slice in advance, it can still check the correctness of that slice.
However, one major disadvantage of this model based on BFT-Store is that there is no reasonable allocation to data blocks, where the original block transaction information is stored, and where the integrated encoding results, where the information cannot be directly extracted, are stored. If the node that owns the data block exhibits an abnormal state, then the only data stored on it runs the risk of recovering the data by encoding, and the normal node that holds the encoded block is unable to avoid this overhead.
Disclosure of Invention
The technical problem to be solved by the invention is to provide a coalition chain block data storage method based on historical evaluation, which can realize reasonable distribution of nodes, promote and ensure the running state of a system. On the basis, a alliance chain block data storage system adopting the alliance chain block data storage method based on historical evaluation is further provided.
In this regard, the present invention provides a method for storing federated chain block data based on historical evaluation, comprising:
step S1, establishing a collaborative storage model based on erasure codes, distributing all nodes in a network into a plurality of collaborative groups according to roles, and jointly maintaining one backup of block account book data by all nodes in each collaborative group; and the nodes in each cooperative group use erasure codes to perform cooperative block storage;
Step S2, continuously recording interaction states of other nodes in a preset period through each node, summarizing service quality of each node according to an evaluation model, and obtaining a grading list of each node to the other nodes;
and S3, summarizing the scoring lists and forming global node score sorting, randomly distributing nodes by adopting a password lottery mode, and then sorting the nodes according to the number of times of lottery, wherein the nodes with the same number of times are sorted according to the number of the scoring values.
In the step S1, the nodes are divided into common nodes and common nodes, wherein the common nodes comprise accounting nodes, voting nodes and aggregation nodes, the common nodes represent blocks for receiving, forwarding and storing broadcast of the common nodes, and the common nodes are connected with the accounting nodes in a network manner; the accounting nodes are used for packaging and storing the transactions received by the accounting nodes into a blockchain, and each accounting node has the same writing capacity, and the accounting nodes are connected with the voting nodes in a network manner; the voting nodes vote on the transaction set of each billing node, and the voting nodes are connected with the aggregation nodes in a network manner; the aggregation node gathers the endorsed votes from the voting nodes for each transaction set and forms a final block header broadcast to the whole network.
A further development of the invention is that said step S2 comprises the sub-steps of:
step S201, calculating initial service quality according to the ability of the node to process the request in unit time;
step S202, increasing the periodic weight to update the service quality;
step S203, performing linear normalization operation on the service quality of each node to obtain the service quality after linear normalization.
A further improvement of the present invention is that in the step S201, the formula is usedCalculating an initial quality of service qos, where n t Representing the total number of data requests of the node to another node, n r Represents n t The number of successful replies received in the secondary request, n r And n t The ratio of (2) represents the probability that the node can normally respond to the request; rtt represents the link state service capability between nodes, +.>Represents the average number of link state service capacity rtts, k represents the sequence number of the heartbeat packet, i represents the node sequence number, rtt k Representing the link state service capacity corresponding to the kth heartbeat packet; in said step S202, the formula ∈ ->Updating the service quality to obtain updated service quality qos, wherein qos t The quality of service of the t-th cycle is represented, t represents the cycle number, q represents the previous cycle Impact weight, 0<q<1, a step of; in step S203, by the formula +.>Performing linear normalization operation on the quality of service qos updated in step S202, where qos max And qos min Respectively represent the maximum and minimum of quality of service qos in all node scores, qos norm Representing the quality of service score of the node.
A further development of the invention is that said step S3 comprises the sub-steps of:
step S301, forming a scoring list by each node in the cooperative group and transmitting the scoring list to the aggregation node in the last block consensus of the node allocation period;
step S302, the aggregation node judges whether the node allocation is effective or not, if yes, the step S303 is skipped, and if not, the aggregation node is rotated;
step S303, writing the global scoring list into the transaction through the aggregation node;
step S304, judging whether the number of abnormal nodes determined by the aggregation node is less than 2f, if yes, selecting normal nodes for storing the coding blocks based on the adoption of a password lottery algorithm, and jumping to step S305, if not, ending after distributing the coding blocks, wherein f represents the preset upper limit of the number of malicious nodes of the cooperative group;
step S305, forming the drawing messages into drawing convergence messages within a limited time, transmitting the drawing convergence messages to at least 2f+1 voting nodes of the aggregation nodes, and writing all messages into a broadcasting whole network in the transaction.
A further improvement of the present invention is that said step S302 comprises the sub-steps of:
step S3021, judging whether the aggregation node collects at least 2f+1 messages in the collaboration group, if yes, determining that the allocation is valid, jumping to step S3022, and if not, jumping to step S3023;
step S3022, performing statistical arrangement on all score lists through the aggregation node, and performing statistical arrangement according to a formulaScoring node i, wherein Score i Representing the final score, qos, of node i i Representing quality of service score for the ith node, n i Representing the number of cycles that node i historically has been co-allocated to a data block;
step S3023, returning to the allocation of the preset number of times, and if the allocation is still invalid, switching the aggregation node, and then jumping to step S3021.
A further improvement of the present invention is that said step S304 comprises the sub-steps of:
step S3041, judging whether the number of abnormal nodes determined by the aggregation node is less than 2f, if yes, jumping to step S3042, if not, determining that all the coding blocks can be allocated, and ending after allocation;
step S3042, selecting and extracting the node storing the code block from the normal nodes based on the password lottery algorithm capable of verifying the random function, wherein each node judges whether the node is in the normal node range identified by the aggregation node, the node in the normal node range participates in the distribution process, and the node i independently performs Score by taking P as probability i Bernoulli simulated drawing experiment B (Score) i The method comprises the steps of carrying out a first treatment on the surface of the p) and using the number of times in the extraction as a ranking principle, distributing the nodes with high ranking, and ending after distribution.
The invention further improves that the method also comprises a step S4, wherein the step S4 is used for migrating the data in the disconnection state to a normal node for storage, and the implementation process is as follows:
step S401, the aggregation node monitors the history status of the nodes in each cooperative group in real time, and when a certain node continues S abnor The monitoring periods are all evaluated as abnormal states, the aggregation node starts the reassignment process of the data block stored in the node, and the latest S is migrated in each monitoring period abnor And stopping reassigning the data blocks when the nodes are recovered to be normal in the next monitoring period, otherwise, continuing to migrate S abnor The data blocks are not stored until the node in abnormal state does not store any data blockThe normal state includes a downtime state or a malicious state, S abnor The upper limit of the cycle number of the node in an abnormal state preset by the system is represented;
step S402, the aggregation node writes malicious nodes and data block information needing to be reassigned into a block and broadcasts the block to the whole network, and other nodes monitor whether the aggregation node initiates a reassignment flow in time; comparing voting with information published by the aggregation node after the same calculation is carried out by the voting node;
Step S403, the node is used for responding to data reading before returning to normal and having the corresponding coding block again; and continuously storing the coding blocks in a preset time after the nodes newly allocated to the data blocks acquire the data blocks, and if the coding blocks are not successfully acquired, sending a request to (n-2 f) nodes and calculating erasure codes to obtain the coding blocks, wherein n represents the number of the nodes.
A further improvement of the present invention is that said step S401 comprises the sub-steps of:
step S4011, the node monitors the history status of the nodes in each cooperative group in real time, and when a certain node continues S abnor When all the monitoring periods are evaluated as abnormal states, jumping to step S4012;
step S4012, obtaining the block height corresponding to the node data block, and migrating the stored latest S abnor A number of data blocks;
step S4013, judging whether the node state is recovered to be normal in a monitoring period, if so, stopping migrating the data block, otherwise, jumping to step S4014;
step S4014, determining whether the abnormal node still retains the data block, if yes, returning to step S4012, and if not, stopping migrating the data block.
The invention also provides a alliance chain block data storage system based on the historical evaluation, which adopts the alliance chain block data storage method based on the historical evaluation and comprises the following steps:
The collaborative storage model building module builds a collaborative storage model based on erasure codes, distributes all nodes in a network into a plurality of collaborative groups according to roles, and jointly maintains a backup of block ledger data for all nodes in each collaborative group; and the nodes in each cooperative group use erasure codes to perform cooperative block storage;
the node evaluation model building module is used for continuously recording interaction states of other nodes in a preset period through each node, summarizing service quality of each node according to the evaluation model and obtaining a grading list of each node to the other nodes;
the node allocation mechanism building module is used for summarizing the scoring lists and forming global node score ordering, randomly allocating nodes in a password drawing mode, and then ordering the nodes according to the number of times of drawing, wherein the nodes with the same number of times are ordered according to the number of the evaluation values;
and the abnormal node data redistribution mechanism building module is used for migrating the data in the disconnection state to the normal node for storage.
Compared with the prior art, the invention has the beneficial effects that: the method can identify the nodes with better running state and grant higher data block storage authority, meanwhile, the method also combines factors such as reading service performance and communication quality to evaluate, establishes a node evaluation model, and completes the distribution between the erasure code blocks and the nodes by periodically summarizing and evaluating the nodes and utilizing a password lottery algorithm, thereby enabling the nodes with normal performance and better service in the history evaluation to continuously have the data blocks to respond to the reading request quickly, solving the distribution problem between the erasure code blocks and the nodes in the prior art, and greatly improving and guaranteeing the performance of the alliance chain block data storage system. On the basis, the system automatically completes dynamic reassignment of the node data block after the node fails by using an abnormal node data reassignment mechanism, and data in a disconnection state is migrated to a normal node for storage, so that the rationality and the high efficiency of node assignment are further improved.
Drawings
FIG. 1 is a schematic workflow diagram of one embodiment of the present invention;
FIG. 2 is a schematic workflow diagram of a prior art local storage optimization system for a blockchain;
FIG. 3 is a schematic diagram of a network model of one embodiment of the present invention;
FIG. 4 is a schematic diagram of an embodiment of the present invention based on erasure codes;
FIG. 5 is a schematic diagram of a node assignment workflow in combination with cryptographic drawing in accordance with one embodiment of the present invention;
FIG. 6 is a schematic workflow diagram of abnormal node data reassignment in accordance with one embodiment of the present invention.
Detailed Description
Preferred embodiments of the present invention will be described in further detail below with reference to the accompanying drawings.
The data block stores original block transaction information, and the code block stores comprehensive code results which can not directly extract information. If the node that owns the data block exhibits an abnormal state, then the only data stored on it runs the risk of recovering the data by encoding, and the normal node that holds the encoded block is unable to avoid this overhead. One solution is to assign data blocks to nodes that are more likely to function properly, while assigning encoded blocks to nodes that are more likely to be abnormal. And if a node can always show better running state during running, the data block is allocated to the node every time.
The blockchain is a distributed peer-to-peer network architecture, nodes are in an equal relationship of mutual distrusting, and more reasonable selection results can be analyzed only through mutual historical evaluation results. This imbalance in distribution can create two problems. Firstly, because the data blocks with multiple rounds are possessed, the data request load of the node is obviously higher than that of other nodes, and the normal operation of the node is affected; second, since the allocation results are predictable, the node is more vulnerable to attack, since higher revenue is more easily obtained from the attack on the node. Therefore, the node also needs to consider the requirements of load balancing and random selection in the process of selecting and pulling.
Therefore, how to build a reasonable node allocation mechanism has obvious beneficial effects and significance for enhancing the collaborative block storage model. Since the data in the block header is read frequently, this example only fragments the block body in which the transaction is stored.
Specifically, as shown in fig. 1, this example provides a method for storing federated chain block data based on historical evaluation, including:
step S1, establishing a collaborative storage model based on erasure codes, distributing all nodes in a network into a plurality of collaborative groups according to roles, and jointly maintaining one backup of block account book data by all nodes in each collaborative group; and the nodes in each cooperative group use erasure codes to perform cooperative block storage;
Step S2, continuously recording interaction states of other nodes in a preset period through each node, summarizing service quality of each node according to an evaluation model, and obtaining a grading list of each node to the other nodes;
and S3, summarizing the scoring lists and forming global node score sorting, randomly distributing nodes by adopting a password lottery mode, and then sorting the nodes according to the number of times of lottery, wherein the nodes with the same number of times are sorted according to the number of the scoring values.
As shown in fig. 3, in step S1 of this example, the nodes are first divided into common nodes and common nodes, where the common nodes are used for maintaining the normal operation of the common algorithm and are required to bear the responsibility given by the algorithm, and the common nodes are used for passively receiving, forwarding and storing the blocks broadcasted by the common nodes. The common node comprises an accounting node, a voting node and an aggregation node, the common node represents a block for receiving, forwarding and storing broadcast of the common node, and the common node is in network connection with the accounting node; the ordinary node has the capability of reading only in the network, has the right to acquire the block in the system and the responsibility of forwarding the message to the neighbor node, and can only forward the transaction to the accounting node instead of its packaging process but cannot have any effect on the block generation. The accounting nodes are used for packaging and storing the received transactions into the blockchain, and each accounting node has the same writing capability, and is connected with the voting nodes in a network mode. In a round of consensus, voting nodes vote on a collection of transactions for each billing node, only widely accepted transactions being written to the blockchain network, the voting nodes being in network connection with the aggregation node. During each round of consensus period, the aggregation node collects the approved votes of the voting nodes for each transaction set and forms a final block header broadcast to the whole network.
As shown in fig. 4, assuming that there are n nodes in total, where there are at most x unresponsive nodes, RS codes with threshold value (n-x, x) can be used in the collaborative storage, where the RS codes refer to Reed-Solomon codes, also called erasure codes, so that a client can contact n-x nodes that are active at any time to recover the original data, that is, to satisfy the reading security of the data. For any block, each node generates n blocks independently using RS code encodingIncluding n-x data blocksX coding blocks->The data block is equal proportion division of original data, a certain amount of transaction information is recorded, the coding block can only be used for restoring redundant data, each node only stores one erasure code block (the data block or the coding block), and all other block information is deleted independently, when necessary, any n-x blocks can be requested to restore the zone block, and therefore the theoretical maximum compression rate of the zone block is 1/(n-x).
In order to still be able to retrieve transactions after the fragment is saved, the present example preferably records the presence information of all transactions within each data block by means of a bloom filter, which has the advantage that typically no more than one percent of the storage is required to determine the presence of a transaction. The node records the hash of each transaction in a bloom filter before the block body is fragmented, each node in the cooperation group corresponds to one bloom filter, and in order to ensure that the obtained erasure code blocks are correct, the erasure code blocks refer to a plurality of file slices generated by the original blocks through an erasure code algorithm, and the node also needs to store the hash value of each erasure code block into the additional attribute of the block head.
In this example, all nodes in the network are allocated to a plurality of collaboration groups according to roles, and all nodes in each collaboration group together maintain a backup of the block ledger data. And the nodes in the cooperative group are stored in blocks by using the principle of erasure codes, and the nodes are matched with each other to acquire the block data which is not stored. In order to better distribute the data blocks, the method also provides a node evaluation model combined with the service quality to score the performance of the nodes on the basis of the collaborative storage based on the erasure codes. After scoring, each node has a scoring list for other nodes, and then gathers the lists in a transaction form to form global node score ordering, and meanwhile, the nodes are randomly distributed by adopting a password lottery algorithm.
Step S2 in this example is used to build a node evaluation model combined with the service quality. The evaluation of the nodes to other nodes in the collaboration group represents the trust degree of the nodes to the future normal data reading and storing service, each node in the system continuously records the interaction state with other nodes in a period, and the score summary table of each node is summarized according to the evaluation model, as shown in the table 1 below.
Table 1 schematic table of node score list
Node sequence number | Status of | Scoring of |
0 | Normal state | 0.7 |
1 | Normal state | 0.5 |
2 | Downtime of the engine | 0 |
3 | Malicious intent | 0 |
…… | …… | …… |
Nodes have three possible states in the system, namely Normal (Normal), downtime (Crash) and malicious (Evil). The node first evaluates the state s in which the other nodes are located i (s i E { Normal, crash, evil }), a malicious state is indicated if other nodes produce a malicious behavior once in a round of cycles. The definition of malicious behavior includes four types of cases: (1) When data stored by other nodes are requested, the data returned by the nodes are different from the local data abstract; (2) In any block generation process in the period, the transaction set, the vote or the block header message generated by the node cannot be verified; (3) For voting nodes, the voting node generates a sum-majority vote in a block voteDisagreement of opinion; (4) A node may also be considered a malicious node if it can reply normally to a heartbeat packet and can send other messages than a data request response normally. The node in the down state does not respond to any request from the user.
The nodes without malicious behaviors and downtime are regarded as normal nodes, if f malicious nodes and f downtime nodes can be detected exactly, the erasure code blocks can be allocated at the moment, but in practical application, the number of the malicious nodes and the number of the downtime nodes are smaller than the above, so that the normal nodes are required to be divided in this example.
Preferably, the step S2 in this example includes the following substeps:
step S201, calculating initial service quality according to the ability of the node to process the request in unit time;
step S202, increasing the periodic weight to update the service quality;
step S203, performing linear normalization operation on the service quality of each node to obtain the service quality after linear normalization.
Specifically, in step S201 of this example, the formula is usedCalculating an initial quality of service qos, wherein the quality of service qos represents the capability of a node to process requests in unit time, and normal nodes are ordered by the quality of service qos; n is n t Representing the total number of data requests of the node to another node, n r Represents n t The number of successful replies received in the secondary request, n r And n t The ratio of (2) represents the probability that the node can normally respond to the request; rtt represents the link state service capability between nodes, +.>Represents the average number of link state service capacity rtts, k represents the sequence number of the heartbeat packet, i represents the node sequence number, rtt k And indicating the link state service capacity corresponding to the kth heartbeat packet. ServiceThe quality qos is equivalent to the number of times that data can be successfully requested by a certain node in unit time, and if no data request is performed between the quality qos and the certain node in the period, the average probability of successful reading of other nodes can be used for replacing the data request.
Step S201 described in this example is applicable to single-cycle evaluation, but the single-cycle evaluation is used to identify that all the historic performances of the nodes are not comprehensive enough and are easily interfered by malicious nodes, so that the present example preferably performs overall analysis on the performances of each cycle. Taking timeliness into consideration, the new period occupies a larger weight and is more accurate to the evaluation result, so the example sets the weight of the new period on the overall influence to 1, and the proportion of the previous period on the overall influence becomes q times of the period, wherein 0<q<1, assuming that the current t-th cycle is present, in the step S202, the formula is passedUpdating the quality of service to obtain updated quality of service qos taking into account periodic factors, wherein qos t The quality of service of the t-th cycle is represented, t represents the cycle number, and q represents the impact weight of the previous cycle.
In order to make the quality of service scores of different nodes have the same dimension, and avoid that the malicious score of a certain node affects the global evaluation, the example also performs a linear normalization operation on the quality of service score of each node, in the step S203, the method passes through the formulaPerforming linear normalization operation on the quality of service qos updated in step S202, where qos max And qos min Respectively represent the maximum and minimum of quality of service qos in all node scores, qos norm Representing quality of service scores, qos, for nodes norm The value range is [0,1 ]]And sorting the nodes according to the score.
Step S3 in this example is used to establish a node allocation mechanism in combination with the cryptographic lottery algorithm. After the statistics in step S2, each node has a scoring list for other nodes, and in step S3, each list is summarized in a transaction form to form a global node score ordering, and meanwhile, the nodes are randomly allocated in a password lottery algorithm mode, and the specific flow of this example is shown in fig. 5. Step S3 in this example includes steps S301 to S305.
In step S301, the consensus of r rounds of system is regarded as a node allocation period, and each node in the collaborative group forms a scoring list and sends the scoring list to the aggregation node in the last block consensus of the node allocation period; the format is as follows<Score<StateTable{s 0 ,s 1 ,…,s i } i∈n ,ScoreTable{qos 0 ,qos 1 ,…,qos i } i∈n ,h,i th ,Sign>>Wherein StateTable is a state table for recording whether a node is normal, down or malicious, scoreTable is a scoring table representing the quality of service of the node, h represents the block height when sending a message, i th Representing at this time at the ith th The distribution period of each node, sign is the signature of the corresponding node on the message, n represents the number of nodes in the node cooperation group, s i Representing the state in which the i-th node is located, state s i Including normal, down, or malicious states, i representing the node sequence number, qos i Representing the quality of service score of the i-th node.
In the step S302, the aggregation node determines whether the node allocation is valid, if yes, it jumps to step S303, otherwise, it returns to rotate the aggregation node; more specifically, the step S302 includes sub-steps S3021 to S3023. In step S3021, it is determined whether the aggregation node collects at least 2f+1 messages in the cooperative group, if yes, it is determined that the allocation is valid, and the process jumps to step S3022, if not, the process jumps to step S3023; f represents the upper limit of the number of malicious nodes in the cooperative group security setting; the aggregation node is rotated on the assumption that no allocation result is formed under a plurality of consensus rotations.
After checking that the message itself is valid, the aggregation node will statistically sort through all scoring lists. First, all nodes are finally classified according to states, and malicious or downtime nodes need at least f+1 nodes to agree on, and the final scores of the nodes are regarded as 0. The other nodes are all considered normal nodes even though there may still be hidden malicious nodes in them. In order to eliminate the influence of scoring of malicious nodes as much as possible, the embodiment preferably selects the median as the evaluation index, because the number of the normal nodes is larger than that of the malicious nodes, even if the malicious nodes cooperatively score very high or very low under extreme conditions, the feedback of the intermediate data as the normal nodes can be ensured.
In addition to quality of service, load balancing when nodes process requests needs to be fully considered. The nodes storing the data blocks need to take on more system responsibilities and they will accept more data read requests than the nodes storing the encoded blocks. Thus, a node storing fewer data blocks should have more opportunities in the next allocation, with n i Representing the number of cycles that node i historically has been co-assigned to a data block, in said step S3022, all scoring lists are statistically sorted by said aggregate node and formulated by the formulaScoring node i, wherein Score i Representing the final score, qos, of node i i Representing quality of service score for the ith node, n i Representing the number of cycles that node i historically has been co-allocated to a data block.
At the same time the aggregation node writes the generated global scoring table < StateTable, scoreTable > into the transaction to ensure that all nodes will eventually read the configuration information.
In step S3023 of the present example, the allocation is returned to the preset number of times, and if the allocation is still invalid, the aggregation node is rotated and then the process goes to step S3021. The preset times can be set and adjusted in a self-defined mode according to actual conditions and requirements.
In step S303, the global score list is written into the transaction by the aggregation node. Other nodes are acceptingAfter information issued by the aggregation nodes is gathered, firstly, the numbers of the downtime nodes and the malicious nodes in the state table are judged, and if the numbers are equal to 2f, all the coding blocks can be distributed. At this time, abnormal node ordering {0,1,2, …,2f-1} is performed according to the node public key, and the code block number c allocated by the node i The relation with the node number i is: c i =(Hash(BlockHeader h ) % 2f+i) mod 2f, where Block Header h Representing the block header of the previous height h of the current consensus, hash represents a Hash function. For data block number d i The same formula is used for the allocation of the normal node sequence number i (i e {0,1,2, …, n-2f }).
In step S304, it is determined whether the number of abnormal nodes determined by the aggregation node is less than 2f, if yes, the node storing the code block needs to be selected from the normal nodes, in this example, the normal node storing the code block is selected based on the cryptographic lottery algorithm, and step S305 is skipped, if not, the code block is allocated and then ended, where f represents an upper limit of the number of malicious nodes preset by the cooperative group.
Step S304 in this example includes the following sub-steps:
Step S3041, judging whether the number of abnormal nodes determined by the aggregation node is less than 2f, if yes, jumping to step S3042, if not, determining that all the coding blocks can be allocated, and ending after allocation;
step S3042, selecting and extracting the node storing the code block from the normal nodes based on the password lottery algorithm capable of verifying the random function, wherein each node judges whether the node is in the normal node range identified by the aggregation node, the node in the normal node range participates in the distribution process, and the node i independently performs Score by taking P as probability i Bernoulli simulated drawing experiment B (Score) i The method comprises the steps of carrying out a first treatment on the surface of the p) and using the number of times in the extraction as a ranking principle, distributing the nodes with high ranking, and ending after distribution.
More specifically, the present example preferably employs a VRF (Verifiable Random Funcition, verifiable random function) based cryptographic lottery algorithm that ensures that the result chosen in a single lottery is random, whereas the probability of nodes being chosen after multiple lottery tends to its fractional ratio.
In the verifiable random function, for a set of determined public-private key pairs < PK, SK >, the VRF may generate a deterministic, non-speculative random number (r) and a proof data (pi) using a Source and private key (SK), and the process may be expressed as: < r, pi > ++VRF (Source, SK). For a given private key SK and Source, only a unique random number r can be generated, thus verifying from the public key PK, the random number r, and the proof data pi whether the random number r was generated by the private key SK, and whether the random number r was generated by the Source, this process can be expressed as: BOOL≡VRF_VERIFY (Source, PK, r). The importance of VRFs is that the random number generator cannot deliberately manipulate the result, nor can others guess the random number result but can believe that the number was randomly generated by the generator.
Each node needs to judge whether the node is in the normal node range which is confirmed by the aggregation node, and the nodes in the range further participate in the distribution process. Node i independently performs Score with P as probability i Bernoulli simulated drawing experiment B (Score) i The method comprises the steps of carrying out a first treatment on the surface of the p) and using the number of times in the extraction as a ranking principle, the nodes with high ranking allocate data blocks for storage. In order to ensure the independent random characteristic of the Bernoulli experiment, the node judges an integer interval [ j, j+1 ] of the Bernoulli cumulative distribution curve in which the random number R falls by using a uniform random number R (R is more than or equal to 0 and less than or equal to 1) generated by the VRF as the input of a drawing experiment, and takes the integer interval downward rounding result j as the times in drawing the drawing experiment. For the same probability P, the larger the drawing base is, the more the number of the drawing is, and then the node with the high score under the same input random number R is selected. Because the random number result of each drawing is uncontrollable, an attacker cannot predict the ranking result of a single time, but the average value of the random number r under multiple times tends to be 0.5, which ensures that nodes with high scores under multiple times have higher pulling weights. The system uses a Block of previous height h h As a source of random numbers. The pseudo code of the implementation process is as follows:
In step S305 of this example, the drawing message < sort < R, pi, j, i, sign > is formed into a drawing convergence message within a defined time, and is sent to at least 2f+1 voting nodes of the aggregation node, where i represents a node sequence number. All messages are written to the transaction broadcast full network.
After exceeding the limit time, the voting node will form all the lottery messages received by itself into a lottery aggregate messageAnd the messages are sent to the aggregation node, and the aggregation node needs to receive at least 2f+1 lottery converged messages from different voting nodes and write all the messages into a transaction to broadcast the whole network. Since the aggregation node has a malicious possibility, it can actively refuse to receive any node message, thereby controlling the result of allocation. However, through two rounds of message passing, the drawing information successfully sent to the voting node must be sent to the aggregation node, and since the system has f malicious nodes at most, any drawing information successfully sent must exist in the transaction broadcasted by the aggregation node, otherwise the aggregation node cannot generate a valid transaction and causes the aggregation node to rotate.
After other nodes receive the transaction, the signature legitimacy and uniqueness of each drawing convergence message are required to be independently verified, then all the drawing messages are extracted and validity verification is carried out, the nodes are required to verify the legitimacy of the random number by using proof information pi, and the corresponding Bernoulli experiment drawing times value is independently obtained to be compared with the numerical value published by the drawing messages, and the pseudo code of the verification process is as follows:
Algorithm 2 verification of the drawing result (Verifying Sortition Result)
Then, sorting the nodes according to the number of times of extraction, wherein the nodes with the same number of times are sorted according to the size of the evaluation value, the first n-2f nodes are selected to allocate the data blocks, the other nodes allocate the coding blocks, and the data block number d i The relation with the node number i is: d, d i =(Hash(BlockHeader h )%(n-2f)+i)mod(n-2f)。
It should be noted that, this example further preferably includes step S4, where the step S4 is used to migrate the data in the disconnection state to the normal node for saving, as shown in fig. 6, and the implementation process includes steps S401 to S403.
In step S401 of this example, the aggregation node monitors the history status of the nodes in each collaboration group in real time, and when a certain node continues S abnor Each monitoring period is evaluated as abnormal, and the aggregation node will initiate a reassignment process for the node's stored data block. The system obtains the corresponding block height { h } of the abnormal node data block 1 ,h 2 ,…,h cnt In order to avoid the system burden caused by simultaneous transmission of excessive data, only the nearest S is migrated in each monitoring period abnor And stopping reassigning the data blocks when the nodes are recovered to be normal in the next monitoring period, otherwise, continuing to migrate S abnor The data blocks are not stored until the node in the abnormal state comprises a downtime state or a malicious state abnor And the upper limit of the cycle number of the node preset by the system in an abnormal state is indicated.
The aggregation node recalculates the nodes corresponding to and stored in the data blocks, obtains all normal nodes according to the result of the last evaluation, counts the total number of the nodes and a grading list of the code blocks stored in the corresponding heights, sorts the normal nodes according to the grading height, and the number i of the new nodes and the height d of the data blocks i The relation of (2) is:
as shown in fig. 6, the step S401 in this example preferably includes the following substeps:
step S4011, the node monitors the history status of the nodes in each cooperative group in real time, and when a certain node continues S abnor When all the monitoring periods are evaluated as abnormal states, jumping to step S4012;
step S4012, obtaining the block height corresponding to the node data block, and migrating the stored latest S abnor A number of data blocks;
step S4013, judging whether the node state is recovered to be normal in a monitoring period, if so, stopping migrating the data block, otherwise, jumping to step S4014;
step S4014, determining whether the abnormal node still retains the data block, if yes, returning to step S4012, and if not, stopping migrating the data block.
In step S402 of the present embodiment, the aggregation node writes malicious nodes and data block information to be reassigned into a block and broadcasts the block to the whole network, and other nodes monitor whether the aggregation node initiates a reassignment flow in time; the aggregation node that is not entitled will be revoked by an additional mechanism, i.e. the aggregation node that has not initiated the reassignment procedure within the set time will do the revocation process. After the same calculation is carried out by the voting node, the voting node compares the information published by the aggregation node with the information published by the aggregation node to prevent the aggregation node from cheating to additionally reassign the data blocks of the normal node.
The normal node can perceive the information of the data block newly allocated by itself through the newly generated block, and the node is obtained by encoding the (n-2 f) blocks which are requested to survive because the original information is not available. If a plurality of data blocks with high correspondence need to be reassigned, the normal nodes can send the data blocks to each other through a proper communication mechanism to ensure that the codes are used only once. The normal node that completed all data block requests will advertise the full network, and the other nodes modify their own block to node correspondence and will relocate the read request to the new node.
In the example, in step S403, the node is configured to respond to data reading before returning to normal and having the corresponding code block again; and continuously storing the coding blocks in a preset time after the nodes newly allocated to the data blocks acquire the data blocks, if the coding blocks are not successfully acquired, sending a request to (n-2 f) nodes, and calculating erasure codes to obtain the coding blocks, wherein n represents the number of the nodes in the cooperative group.
After the abnormal node returns to normal again in the future, the new generated block information can be acquired to inquire that the stored data block is reassigned. Because each node in the system needs to store different erasure code blocks to ensure data security, the node can only respond to data reading before re-owning the corresponding encoding blocks and cannot normally participate in the system consensus process. The node newly allocated to the data block can continue to store the code block for a period of time after acquiring the data block, namely, the preset time which can be modified and set according to the actual situation, during which the node returning to normal has a probability of directly acquiring the code block, otherwise, it needs to request (n-2 f) nodes and calculate the erasure code to obtain the code block. Returning to normal node data should complete responsibility for consensus mechanism requirements within a preset time frame after meeting security requirements to avoid continuing to be marked as an abnormal node, which has more weight in the future to save newly generated data blocks.
The present example also provides a system for storing coalition chain block data based on historical evaluation, which adopts the method for storing coalition chain block data based on historical evaluation as described above, and includes:
the collaborative storage model building module builds a collaborative storage model based on erasure codes, distributes all nodes in a network into a plurality of collaborative groups according to roles, and jointly maintains a backup of block ledger data for all nodes in each collaborative group; and the nodes in each cooperative group use erasure codes to perform cooperative block storage;
the node evaluation model building module is used for continuously recording interaction states of other nodes in a preset period through each node, summarizing service quality of each node according to the evaluation model and obtaining a grading list of each node to the other nodes;
the node allocation mechanism building module is used for summarizing the scoring lists and forming global node score ordering, randomly allocating nodes in a password drawing mode, and then ordering the nodes according to the number of times of drawing, wherein the nodes with the same number of times are ordered according to the number of the evaluation values;
and the abnormal node data redistribution mechanism building module is used for migrating the data in the disconnection state to the normal node for storage.
In summary, the node allocation mechanism based on the history evaluation processes the correspondence between the nodes and the data blocks, can identify the node with better running state and grant higher data block storage authority, and meanwhile, evaluates the node by combining factors such as reading service performance and communication quality, and establishes a node evaluation model, and the nodes are periodically summarized and evaluated and distributed by using a password lottery algorithm to complete the erasure correction code and the allocation among the nodes, so that the nodes with normal performance and better service in the history evaluation can continuously have the data blocks to quickly respond to the reading request, the allocation problem between the erasure correction code and the nodes in the prior art is well solved, and the performance of the alliance chain block data storage system is greatly improved and ensured. On the basis, the system automatically completes dynamic reassignment of the node data block after the node fails by using an abnormal node data reassignment mechanism, and data in a disconnection state is migrated to a normal node for storage, so that the rationality and the high efficiency of node assignment are further improved.
The foregoing is a further detailed description of the invention in connection with the preferred embodiments, and it is not intended that the invention be limited to the specific embodiments described. It will be apparent to those skilled in the art that several simple deductions or substitutions may be made without departing from the spirit of the invention, and these should be considered to be within the scope of the invention.
Claims (6)
1. A method for storing federated chain block data based on historical evaluation, comprising:
step S1, establishing a collaborative storage model based on erasure codes, distributing all nodes in a network into a plurality of collaborative groups according to roles, and jointly maintaining one backup of block account book data by all nodes in each collaborative group; and the nodes in each cooperative group use erasure codes to perform cooperative block storage;
step S2, continuously recording interaction states of other nodes in a preset period through each node, summarizing service quality of each node according to an evaluation model, and obtaining a grading list of each node to the other nodes;
step S3, summarizing the scoring lists and forming global node score sorting, randomly distributing nodes by adopting a password drawing mode, and then sorting the nodes according to the number of times of drawing, wherein the nodes with the same number of times are sorted according to the number of the evaluation values;
in the step S1, the nodes are firstly divided into a common node and an ordinary node, wherein the common node comprises an accounting node, a voting node and an aggregation node, the ordinary node represents a block for receiving, forwarding and storing the broadcast of the common node, and the ordinary node is connected with the accounting node in a network manner; the accounting nodes are used for packaging and storing the transactions received by the accounting nodes into a blockchain, and each accounting node has the same writing capacity, and the accounting nodes are connected with the voting nodes in a network manner; the voting nodes vote on the transaction set of each billing node, and the voting nodes are connected with the aggregation nodes in a network manner; the aggregation node collects the approval votes of the voting node for each transaction set and forms a final block head broadcast to the whole network;
Said step S2 comprises the sub-steps of:
step S201, calculating initial service quality according to the ability of the node to process the request in unit time;
step S202, increasing the periodic weight to update the service quality;
step S203, carrying out linear normalization operation on the service quality of each node to obtain the service quality after linear normalization;
in the step S201, the formula is passedCalculating initial quality of service ∈>Wherein->Representing the total number of data requests from the node to another node in common, +.>Representation->The number of times a reply was successfully accepted in the secondary request, +.>And->The ratio of (2) represents the probability that the node can normally respond to the request;Representing the link state service capability between nodes, < > and the like>Representing Link State service capability->Average number of->Sequence number representing heartbeat packet->Represents node number,/->Indicate->The link state service capability corresponding to the sub-heartbeat packet;
in the step S202, the formula is passedUpdating the quality of service to obtain updated quality of service +.>Wherein->Indicate->Quality of service for each cycle, +.>Indicates the cycle number>Influence weight representing the previous cycle, +.>The method comprises the steps of carrying out a first treatment on the surface of the In step S203, by the formula +. >The updated service quality of step S202 +.>Performing linear normalization operation, wherein ∈>And->Representing the quality of service in the scores of all nodes, respectively>Maximum and minimum of>A quality of service score representing the node;
said step S3 comprises the sub-steps of:
step S301, forming a scoring list by each node in the cooperative group and transmitting the scoring list to the aggregation node in the last block consensus of the node allocation period;
step S302, the aggregation node judges whether the node allocation is effective or not, if yes, the step S303 is skipped, and if not, the aggregation node is rotated;
step S303, writing the global scoring list into the transaction through the aggregation node;
step S304, judging whether the number of abnormal nodes determined by the aggregation node is smaller than the number of abnormal nodesIf yes, selecting a normal node for storing the coding block based on the adoption of a password lottery algorithm, and jumping to the step S305, if not, ending after distributing the coding block, wherein the step S is ended, and the step S is ended after distributing the coding block>Representing the preset malicious node quantity upper limit of the cooperative group;
step S305, forming the lottery message into a lottery aggregate message within a limited time, and transmitting the lottery aggregate message to at least an aggregation nodeAnd the voting nodes write all the messages into the whole broadcasting network in the transaction.
2. The historical evaluation-based federation chain block data storage method according to claim 1, wherein the step S302 comprises the sub-steps of:
step S3021, determining whether the aggregation node collects at least in the collaboration groupIf yes, determining that the allocation is valid, jumping to a step S3022, and if not, jumping to a step S3023;
step S3022, performing statistical arrangement on all score lists through the aggregation node, and performing statistical arrangement according to a formulaNode->Scoring, wherein->Representing node->Is the final score of->Indicate->The quality of service score for the individual nodes,representing node->The number of cycles historically co-allocated to the data block;
step S3023, returning to the allocation of the preset number of times, and if the allocation is still invalid, switching the aggregation node, and then jumping to step S3021.
3. The method for storing federated chain block data based on historical evaluation as recited in claim 2, wherein said step S304 comprises the sub-steps of:
step S3041, judging whether the number of abnormal nodes determined by the aggregation node is smaller thanIf yes, jumping to step S3042, if not, determining that all the coding blocks can be allocated, and ending after allocation;
Step S3042, selecting and extracting the node storing the code block from the normal nodes based on the password lottery algorithm capable of verifying the random function, wherein each node judges whether the node is in the normal node range identified by the aggregation node, and the node in the normal node range participates in the distribution processTo->For probability independent +.>Bernoulli simulated lottery experiment->And using the number of times in the extraction as a ranking principle, distributing the nodes with high ranks, and ending after the distribution.
4. The method for storing federated chain block data based on historical evaluation according to claim 1, further comprising step S4, wherein the step S4 is used for migrating the data in the disconnection state to a normal node for storage, and the implementation process is as follows:
step S401, the aggregation node monitors the history status of the nodes in each collaboration group in real time, and when a certain node is continuousThe monitoring periods are all evaluated as abnormal states, the aggregation node starts the reassignment process of the data block stored in the node, and the latest +.>The data blocks stop reassigning when the nodes are recovered to normal in the next monitoring period, otherwise, the data blocks continue to migrate +.>The data blocks are not stored until the node in the abnormal state comprises a downtime state or a malicious state, and the node in the abnormal state is in no more than any data block >The upper limit of the cycle number of the node in an abnormal state preset by the system is represented;
step S402, the aggregation node writes malicious nodes and data block information needing to be reassigned into a block and broadcasts the block to the whole network, and other nodes monitor whether the aggregation node initiates a reassignment flow in time; comparing voting with information published by the aggregation node after the same calculation is carried out by the voting node;
step S403, the node is used for responding to data reading before returning to normal and having the corresponding coding block again; the node newly allocated to the data block continues to store the code block within a preset time after acquiring the data block, and if the code block is not successfully acquired, a request is sent toIndividual nodes and computes erasure codes to obtain encoded blocks,nthe number of nodes is indicated.
5. The method for storing federated chain block data based on historical evaluation as recited in claim 4, wherein said step S401 comprises the sub-steps of:
step S4011, the node monitors the history status of the nodes in each cooperative group in real time, when a certain nodeIndividual node continuityWhen all the monitoring periods are evaluated as abnormal states, jumping to step S4012;
step S4012, obtaining the block height corresponding to the node data block, and migrating the latest stored block height A number of data blocks;
step S4013, judging whether the node state is recovered to be normal in a monitoring period, if so, stopping migrating the data block, otherwise, jumping to step S4014;
step S4014, determining whether the abnormal node still retains the data block, if yes, returning to step S4012, and if not, stopping migrating the data block.
6. A historic-based federated chain block data storage system employing the historic-based federated chain block data storage method of any one of claims 1 to 5, and comprising:
the collaborative storage model building module builds a collaborative storage model based on erasure codes, distributes all nodes in a network into a plurality of collaborative groups according to roles, and jointly maintains a backup of block ledger data for all nodes in each collaborative group; and the nodes in each cooperative group use erasure codes to perform cooperative block storage;
the node evaluation model building module is used for continuously recording interaction states of other nodes in a preset period through each node, summarizing service quality of each node according to the evaluation model and obtaining a grading list of each node to the other nodes;
The node allocation mechanism building module is used for summarizing the scoring lists and forming global node score ordering, randomly allocating nodes in a password drawing mode, and then ordering the nodes according to the number of times of drawing, wherein the nodes with the same number of times are ordered according to the number of the evaluation values;
and the abnormal node data redistribution mechanism building module is used for migrating the data in the disconnection state to the normal node for storage.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202210650385.0A CN115065689B (en) | 2022-06-10 | 2022-06-10 | Alliance chain block data storage method and system based on historical evaluation |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202210650385.0A CN115065689B (en) | 2022-06-10 | 2022-06-10 | Alliance chain block data storage method and system based on historical evaluation |
Publications (2)
Publication Number | Publication Date |
---|---|
CN115065689A CN115065689A (en) | 2022-09-16 |
CN115065689B true CN115065689B (en) | 2024-04-02 |
Family
ID=83201314
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202210650385.0A Active CN115065689B (en) | 2022-06-10 | 2022-06-10 | Alliance chain block data storage method and system based on historical evaluation |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN115065689B (en) |
Families Citing this family (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN117376352B (en) * | 2023-10-07 | 2024-03-12 | 山东山科智能科技有限公司 | Block chain-based Internet of things system |
Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN110427433A (en) * | 2019-08-08 | 2019-11-08 | 上海中通吉网络技术有限公司 | A kind of block chain common recognition method and storage medium |
US10769135B1 (en) * | 2019-08-20 | 2020-09-08 | Alibaba Group Holding Limited | Blockchain data storage based on shared nodes and error correction code |
CN112232619A (en) * | 2020-07-27 | 2021-01-15 | 上海树图区块链研究院 | Block output and sequencing method, node and block chain network system of alliance chain |
CN114139203A (en) * | 2021-12-03 | 2022-03-04 | 成都信息工程大学 | Block chain-based heterogeneous identity alliance risk assessment system and method and terminal |
CN114331395A (en) * | 2021-12-22 | 2022-04-12 | 南京航空航天大学 | Erasure code based block chain data grouping storage optimization structure and method |
CN114594911A (en) * | 2022-03-13 | 2022-06-07 | 西安电子科技大学 | Block chain data storage system and method based on under-chain erasure code distributed storage |
-
2022
- 2022-06-10 CN CN202210650385.0A patent/CN115065689B/en active Active
Patent Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN110427433A (en) * | 2019-08-08 | 2019-11-08 | 上海中通吉网络技术有限公司 | A kind of block chain common recognition method and storage medium |
US10769135B1 (en) * | 2019-08-20 | 2020-09-08 | Alibaba Group Holding Limited | Blockchain data storage based on shared nodes and error correction code |
CN112232619A (en) * | 2020-07-27 | 2021-01-15 | 上海树图区块链研究院 | Block output and sequencing method, node and block chain network system of alliance chain |
CN114139203A (en) * | 2021-12-03 | 2022-03-04 | 成都信息工程大学 | Block chain-based heterogeneous identity alliance risk assessment system and method and terminal |
CN114331395A (en) * | 2021-12-22 | 2022-04-12 | 南京航空航天大学 | Erasure code based block chain data grouping storage optimization structure and method |
CN114594911A (en) * | 2022-03-13 | 2022-06-07 | 西安电子科技大学 | Block chain data storage system and method based on under-chain erasure code distributed storage |
Non-Patent Citations (1)
Title |
---|
基于纠删码的区块链存储优化;樊玉琦等;《计算机学报》;第45卷(第04期);全文 * |
Also Published As
Publication number | Publication date |
---|---|
CN115065689A (en) | 2022-09-16 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN110868440B (en) | Block chain male chain | |
CN114079660B (en) | High-performance distributed storage block data, time stamp, cross-chain communication and data collaboration method | |
US12093247B2 (en) | Blockchain system and method | |
US20230239157A1 (en) | Network for improved verification speed with tamper resistant data | |
CN110140116B (en) | Method and apparatus for a distributed database enabling event deletion | |
CN109150972B (en) | Working method of consensus mechanism of double-layer partitioned efficient block chain | |
US11930113B2 (en) | Blockchain hybrid consensus-based system for maintaining domain name information | |
CN111131209A (en) | Improved efficient consensus method, system, computer device and storage medium | |
CN113141414B (en) | Grouped multi-chain asynchronous consensus method for block chain nodes in CNFS protocol | |
CN111935207A (en) | Block chain system consensus method based on improved C4.5 algorithm | |
CN112615847B (en) | Data sharing and privacy protection method based on block chain | |
CN113726913B (en) | Backbone node access method and block chain system | |
CN112116349B (en) | High-throughput-rate-oriented random consensus method and device for drawing account book | |
Buchnik et al. | Fireledger: A high throughput blockchain consensus protocol | |
CN113626875B (en) | Knowledge graph file storage method for block chain fragment enabling | |
CN115065689B (en) | Alliance chain block data storage method and system based on historical evaluation | |
CN112039837B (en) | Electronic evidence preservation method based on block chain and secret sharing | |
CN114862397B (en) | Double-decoupling block chain distributed method based on double-chain structure | |
CN115664682A (en) | Consensus method for sharing medical data based on alliance chain master-slave multi-chain | |
WO2024153001A1 (en) | Data processing method and apparatus based on hierarchical chain network, and device and medium | |
CN107454162A (en) | A kind of system for improving cloud computing environment reliability | |
CN111311263B (en) | Local safety accounting method for block chain node | |
CN111865601A (en) | Vehicle networking trust management method and system based on block chain | |
Wang et al. | Optimizing Read Performance in Lightweight Blockchain with Cooperative Storage Scheme | |
CN116015674B (en) | Bayesian-and-busy-family-error-resistant node consensus method based on threshold signature |
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 | ||
GR01 | Patent grant | ||
GR01 | Patent grant |