Block chain node data exchange method, readable storage medium and equipment

Abstract

The invention discloses a block chain node data exchange method, a readable storage medium and equipment, and the method comprises the steps: carrying out the coding processing of original block data, and obtaining a plurality of block units; and calculating the storage load difference, the block decoding communication overhead and the node reputation of the target block chain node group of each block unit, and determining an optimal block unit allocation scheme with low load difference and low decoding communication overhead among the target block chain nodes. According to the invention, based on the storage load difference, the block decoding communication overhead and the node reputation of the target block chain node group, the optimal block unit allocation scheme of low load difference and low decoding communication overhead between the nodes is determined, and the block units are stored according to the optimal block unit allocation scheme, so that the storage load of the nodes is greatly reduced, and the storage efficiency of the nodes is improved. The problems of unreasonable block unit distribution and overlarge node storage pressure in the current block chain are solved.

Description

Technical Field

[0001] The present invention relates to a blockchain node data exchange method, a readable storage medium and a device, and belongs to the technical field of blockchain. Background Art

[0002] The current blockchain architecture requires each node to store a complete copy of the blockchain. This model is a huge challenge for nodes with limited storage resources. Resource-constrained nodes find it difficult to assume the role of full nodes, resulting in blockchain data being stored in a few high-performance nodes. This not only reduces the degree of decentralization of the blockchain system, but also poses a potential threat to the security of the system. With the increase in transaction volume and the continuous accumulation of data on the blockchain, storage demand has risen sharply, putting significant pressure on the storage capacity of nodes. Summary of the invention

[0003] The purpose of the present invention is to overcome the deficiencies in the prior art and provide a blockchain node data exchange method, a readable storage medium and a device, which greatly reduce the storage load of the node and solve the problems of unreasonable block unit allocation and excessive node storage pressure in the current blockchain.

[0004] In order to solve the above technical problems, the present invention is implemented by adopting the following technical solutions: On one hand, the present invention provides a blockchain node data exchange method, comprising: Encoding the original block data to obtain multiple block units; Calculate the storage load difference, block decoding communication overhead and node reputation of the target blockchain node group for each block unit; Determine the optimal block unit allocation scheme with low load difference and low decoding communication overhead among target blockchain nodes according to the storage load difference, block decoding communication overhead and node reputation of the target blockchain node group; According to the optimal block unit allocation plan, determine the block units that meet the allocation requirements, and store the block units that meet the allocation requirements in the target blockchain node group; Selecting a block unit that meets the decoding requirement from the block units that meet the allocation requirement and are stored in the target blockchain node group; The block units that meet the decoding requirements are decoded to obtain complete original block data.

[0005] Furthermore, the calculation of the storage load difference, block decoding communication overhead and node reputation of the target blockchain node group for each block unit includes: The storage load difference of the target blockchain node group is calculated by the following formula: ; in: Indicates the storage load difference of the target blockchain node group, Indicates the number of nodes in the target blockchain node group; Representation Node The storage load difference is ; Representation Node The relative storage load, , Representation Node i The number of blocks stored, Representation Node The maximum number of storable block units; represents the average relative storage load, ; The block decoding communication overhead is calculated by the following formula: ; in: Represents the average communication overhead of all nodes in the target blockchain node group during the decoding process; Representation Node Request to k The communication overhead of each block unit is k It indicates the number of block units that ensures that the communication overhead during decoding can be reduced. , Representation Node Read to block unit j The communication overhead required, , Indicates a request to a block unit j The set of nodes passed through, Representation Node p With Node q Communication overhead between The node reputation is calculated by the following formula: ; in: Represents the average reputation value of the nodes in the current allocation scheme; Indicates the target blockchain node group, m Indicates the number of coding units generated by encoding the original block data; Set K Indicates the current allocation plan. ; Representation Node i Whether to store a block unit; ; Representation Node i The reputation value, , Indicates the node before the current allocation plan i Reputation value; Representation Node i Performance score during decoding; ; The weight representing the proportion of request response time; The weight representing the proportion of valid block units; Indicates the ratio threshold of valid block units transmitted by the node. If the ratio of valid block units transmitted by the node is greater than , then the node’s reputation value is increased, otherwise, the node’s reputation value is reduced; express The normalized value of Indicates the node under the current allocation scheme i The proportion of the response request time to the response time of all nodes, , Representation node i The average response time, Representation Node j Average response time; express X i The normalized value of X i Indicates that the node is in the decoding process under the current allocation scheme i The proportion of valid block units transmitted, , Representation Node i The number of valid block units during transmission, Representation Node i The total number of block units in transfer process.

[0006] Furthermore, the method of determining an optimal block unit allocation scheme with low load difference and low decoding communication overhead between target blockchain nodes according to the storage load difference, block decoding communication overhead and node reputation of the target blockchain node group includes: Construct an optimization problem based on the storage load differences, block decoding communication overhead, and node reputation of the target blockchain node group; Based on Markov decision making, the optimization problem is mapped to an observable virtual state space; Construct a reward function with the optimization goal of maximizing the reduction of load difference and decoding communication overhead; Based on the reward function, the optimal block unit allocation scheme with low load difference and low decoding communication overhead between nodes is determined in the observable virtual space.

[0007] Furthermore, the optimization problem is constructed according to the storage load difference, block decoding communication overhead and node reputation of the target blockchain node group, including: The optimization problem is expressed as: st ; ; in: represents the optimal block unit allocation scheme; Indicates the storage load difference of the target blockchain node group; Represents the average communication overhead of all nodes in the target blockchain node group during the decoding process; Represents the average reputation value of the nodes in the current allocation scheme; Indicates the minimum threshold of the average reputation value; Representation Node i The number of stored block units; Representation Node i The maximum number of block units that can be stored; Indicates the number of block units that a node can request; Indicates the number of block units that ensures that the communication overhead during decoding can be reduced; Indicates the number of coding units generated by encoding the original block data.

[0008] Furthermore, the Markov decision-making method maps the optimization problem to an observable virtual state space, including: The node status group is represented by the following formula: in: Indicates the storage status of all nodes in the target blockchain node group; Represents the nodes in the target blockchain node group, r Indicates the number of nodes in the target blockchain node group; The allocation action group is expressed as follows: in: Represents all possible combinations of block units and nodes; Indicates the number of possible block unit allocation schemes ， ; Indicates i block unit allocation action, (1 ≤i≤f ).

[0009] Furthermore, the reward function is constructed with the optimization goal of maximizing the reduction of load difference and decoding communication overhead, including: The reward function is constructed as follows:

[0010] in: The instant reward of the allocation scheme is calculated based on the node load difference and communication overhead as indicators; A weight representing the difference in storage load; represents the weight of decoding communication overhead; L Indicates the difference in storage load of the target blockchain node group; Represents the average communication overhead of all nodes in the target blockchain node group during the decoding process; Indicates the number of block units that a node can request; Indicates the number of block units that ensures that the communication overhead during decoding can be reduced.

[0011] Furthermore, the selecting of a block unit that meets the decoding requirement from the block units that meet the allocation requirement and are stored in the target blockchain node group comprises: Get the block units stored in the target blockchain node group; The acquired block units are verified, and the block units are retained or discarded based on the verification results until the number of block units meets the decoding requirements.

[0012] Furthermore, the obtained block units are verified, and the block units are retained or discarded based on the verification results until the number of block units meets the decoding requirements, including: The Merkle root of a block unit is calculated by the following formula: in: Represents a block unit The hash value of , and Represents a block unit The hash value in the Merkle path; Represents a hash value With hash value The upper layer hash value after combined calculation; Represents a hash value With hash value The upper layer hash value after combined calculation; Represents a block unit of Merkel's roots; The Merkle root of the block unit is compared with the real Merkle root stored in the block header. If the Merkle root of the block unit matches the real Merkle root, the block unit is retained, otherwise the block unit is discarded and the next block unit is verified until the number of block units meets the decoding requirements.

[0013] On the other hand, the present invention provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the blockchain node data exchange method as described above.

[0014] The present invention also provides a computer device, comprising: A memory for storing instructions; The processor is used to execute the instructions so that the device implements the blockchain node data exchange method as described above.

[0015] Compared with the prior art, the present invention has the following beneficial effects: 1. The present invention determines the optimal block unit allocation scheme with low load difference and low decoding communication overhead between nodes based on the storage load difference, block decoding communication overhead and node reputation of the target blockchain node group, stores the block units according to the optimal block unit allocation scheme, greatly reduces the storage load of the node, solves the problems of unreasonable block unit allocation and excessive node storage pressure in the current blockchain, and selects block units that meet the decoding requirements from the block units stored according to the optimal block unit allocation scheme, thereby ensuring the integrity of the original data.

[0016] 2. The present invention verifies the acquired block units through the Merkle root, and compares the Merkle root of the block unit with the real Merkle root stored in the block header. If the Merkle root of the block unit matches the real Merkle root, the block unit is retained, otherwise the block unit is discarded and the next block unit is verified until the number of block units meets the decoding requirements. Compared with the existing homomorphic encryption and certificateless aggregate signature, the verification process in the present invention only involves hash calculation, which reduces the computing cost and storage requirements. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] Figure 1 This is a flow chart of a blockchain node data exchange method according to an embodiment of the present invention; Figure 2 It is a block unit collection node topology diagram of a blockchain node data exchange method according to an embodiment of the present invention; Figure 3 This is a schematic diagram comparing the encoding and decoding time of a blockchain node data exchange method according to an embodiment of the present invention and an existing method; Figure 4 This is a block storage overhead comparison diagram of a blockchain node data exchange method under different encoding schemes according to an embodiment of the present invention; Figure 5 This is a block recovery overhead comparison diagram of a blockchain node data exchange method under different encoding schemes according to an embodiment of the present invention; Figure 6This is a comparison chart of storage overheads of a blockchain node data exchange method according to an embodiment of the present invention and an existing method under different numbers of nodes; Figure 7 This is a block decoding communication delay comparison diagram of a blockchain node data exchange method according to an embodiment of the present invention and an existing method under different numbers of nodes; Figure 8 This is a block decoding communication delay comparison diagram of a blockchain node data exchange method according to an embodiment of the present invention and an existing method under different malicious node ratios; Fig. 9 This is a comparison chart of the number of request messages under different numbers of nodes between a blockchain node data exchange method according to an embodiment of the present invention and an existing method; Fig.10 This is a comparison chart of the number of request messages under different malicious nodes between a blockchain node data exchange method according to an embodiment of the present invention and an existing method; Fig.11 This is a comparison diagram of data recovery delay on a single node under different numbers of nodes between a blockchain node data exchange method according to an embodiment of the present invention and an existing method; Fig.12 This is a comparison chart of transaction throughputs between a blockchain node data exchange method according to an embodiment of the present invention and an existing method under different numbers of nodes. DETAILED DESCRIPTION

[0018] The present invention will be further described below in conjunction with the accompanying drawings. The following embodiments are only used to more clearly illustrate the technical solution of the present invention, and cannot be used to limit the protection scope of the present invention. Example

[0019] like Figure 1 As shown, a blockchain node data exchange method includes: The original block data is encoded to obtain multiple block units. When a new block is generated on the blockchain, it will be encoded. However, when the first block is generated on the blockchain, the blockchain will initialize a random allocation scheme and will not allocate block units. After that, when a new block is generated on the blockchain, the block first goes through the block encoding stage and then is stored according to an optimal allocation scheme.

[0020] Calculate the storage load difference, block decoding communication overhead and node reputation of the target blockchain node group. Specifically, the storage load difference of the target blockchain node group is calculated by the following formula: ;in: Indicates the storage load difference of the target blockchain node group, Indicates the number of nodes in the target blockchain node group; Representation Node The storage load difference is ; Representation Node The relative storage load, , Representation Node i The number of blocks stored, Representation Node The maximum number of storable block units; represents the average relative storage load, ; The block decoding communication overhead is calculated by the following formula: ;in: Represents the average communication overhead of all nodes in the target blockchain node group during the decoding process; Representation Node Request to k The communication overhead of each block unit is k It indicates the number of block units that ensures that the communication overhead during decoding can be reduced. , Representation Node Read to block unit j The communication overhead required, , Indicates a request to a block unit j The set of nodes passed through, Representation Node p With Node q Communication overhead between The node reputation is calculated by the following formula: ;in: Represents the average reputation value of the nodes in the current allocation scheme; Indicates the target blockchain node group, m Indicates the number of coding units generated by encoding the original block data; Set K Indicates the current allocation plan. ; Representation Node i Whether to store a block unit; ; Representation Node i The reputation value.

[0021] According to the storage load difference, block decoding communication overhead and node reputation of the target blockchain node group, the optimal block unit allocation scheme with low load difference and low decoding communication overhead between nodes is determined. Specifically: According to the storage load difference, block decoding communication overhead and node reputation of the target blockchain node group, an optimization problem is constructed, including: The optimization problem is expressed as: st

[0022] ; in: represents the optimal block unit allocation scheme; Indicates the storage load difference of the target blockchain node group; Represents the average communication overhead of all nodes in the target blockchain node group during the decoding process; Represents the average reputation value of the nodes in the current allocation scheme; Indicates the minimum threshold of the average reputation value; Representation Node i The number of stored block units; Representation Node i The maximum number of block units that can be stored; Indicates the number of block units that a node can request; Indicates the number of coding units generated by encoding the original block data; It should be noted that during the block decoding process, the node needs to request block units from other nodes. The malicious behavior of the node will affect the decoding of the block. This embodiment sets a reputation score for each node, which reflects the credibility of the node, and sets a minimum threshold for the average reputation. , allocation plans below this threshold will not be adopted. During each block decoding process, the behavior of each node is recorded, including but not limited to response time, whether the correct block unit is provided, whether there is delay or denial of service, etc., and their reputation scores are updated according to the behavior of the nodes; for example, if a node can always respond quickly and provide correct block units, its reputation score is increased; if the node exhibits malicious behavior, its reputation score is reduced; according to the reputation score, the node's opportunity to participate in future block unit storage is adjusted. Nodes with high reputation will have more opportunities to participate in storage, while nodes with low reputation will be excluded. The reputation value of the node is updated by the following formula: ; Indicates the node before the current allocation plan i Reputation value; Representation Node i Performance score during decoding; ; The weight representing the proportion of request response time; The weight representing the proportion of valid block units; Indicates the ratio threshold of valid block units transmitted by the node. If the ratio of valid block units transmitted by the node is greater than , then the node’s reputation value is increased, otherwise, the node’s reputation value is reduced; express The normalized value of Indicates the node under the current allocation scheme i The proportion of the response request time to the response time of all nodes, , Representation node i The average response time, Representation Node j Average response time; express X i The normalized value of X i Indicates that the node is in the decoding process under the current allocation scheme i The proportion of valid block units transmitted, , Representation Node i The number of valid block units during transmission, Representation Node i The total number of block units in transfer process.

[0023] Based on Markov decision making, the optimization problem is mapped to an observable virtual state space, including: The node status group is represented by the following formula: in: Indicates the storage status of all nodes in the target blockchain node group; Represents the nodes in the target blockchain node group, r Indicates the number of nodes in the target blockchain node group; The allocation action group is expressed as follows:

[0024] in: Represents all possible combinations of block units and nodes; Indicates the number of possible block unit allocation schemes ， ; Indicates i block unit allocation action, (1 ≤i≤f ); With the optimization goal of maximizing the reduction of load difference and decoding communication overhead, a reward function is constructed, including: The reward function is constructed as follows: in: The instant reward of the allocation scheme is calculated based on the node load difference and communication overhead as indicators; A weight representing the difference in storage load; represents the weight of decoding communication overhead; L Indicates the difference in storage load of the target blockchain node group; Represents the average communication overhead of all nodes in the target blockchain node group during the decoding process; Indicates the number of block units that a node can request; Indicates the number of block units that ensures that the communication overhead during decoding can be reduced; Based on the reward function, the optimal block unit allocation scheme with low load difference and low decoding communication overhead between nodes is determined in the observable virtual space.

[0025] storing the block units according to the optimal block unit allocation scheme; Among the block units stored in the target blockchain node group, select the block units that meet the decoding requirements, specifically: Get the block units stored in the target blockchain node group. When a node needs to obtain complete block data, it needs to request enough block units from other nodes in the same group to decode the block. Figure 2 As shown, taking node A as an example in a node group, node A wants to obtain complete block data. Assuming that node A must request at least 3 block units, node A sends a request to nodes B and C. Nodes B and C each store a block unit, then nodes B and C transmit the block unit to node A. However, since the minimum number of block units is not met, node B sends a request to node C, and node C sends a request to nodes E and F. Since node C has already received the request, node C does not respond to node B's request. After receiving the request, since nodes E and F do not store block units, node E sends a request to nodes D and G, and node F sends a request to node G. After receiving the request, node G returns the requested block unit according to the message path. At this time, node A has met the requirements for decoding the block.

[0026] Verify the obtained block units, and retain or discard the block units based on the verification results until the number of block units meets the decoding requirements, including: calculating the Merkle root of the block unit by the following formula:

[0027] in: Represents a block unit The hash value of , and Represents a block unit The hash value in the Merkle path; Represents a hash value With hash value The upper layer hash value after combined calculation; Represents a hash value With hash value The upper layer hash value after combined calculation; Represents a block unit of Merkel's roots; The Merkle root of the block unit is compared with the real Merkle root stored in the block header. If the Merkle root of the block unit matches the real Merkle root, the block unit is retained, otherwise the block unit is discarded and the next block unit is verified until the number of block units meets the decoding requirements.

[0028] The selected block units are decoded to obtain complete original block data.

[0029] In order to evaluate the performance of the method proposed in this embodiment, some representative block coding storage models are selected for comparison, namely BSUE, BFT-DSN and PartitionChain; BSUE: This method improves storage reliability by storing blocks in node groups, and reduces storage overhead by block encoding. However, the random allocation of data units and coding units in this model leads to high block decoding costs; BFT-DSN: Combines storage weighted BFT consistency with erasure coding, and combines homomorphic fingerprinting and weighted threshold signatures for decentralized verification. BFT-DSN achieves comparable performance in terms of storage cost and latency, and superior performance in terms of Byzantine resilience; PartitionChain: uses aggregate signatures as proof of encoded data, which saves storage costs and gets rid of trusted third parties. It divides each block into smaller blocks for encoding to reduce the amount of data transmitted for each block when decoding the block. Comparative evaluation is conducted through the following indicators: encoding time, decoding time, storage overhead, recovery delay, and transaction throughput: Encoding time and decoding time: set up Indicates encoding time. Indicates the decoding time; Coding time Indicates the difference between the time when the blockchain system starts encoding the block and the time when the encoding is successful; decoding time Indicates the difference between the time when the blockchain system starts decoding a block and the time when the decoding is successful; like Figure 3 As shown, when m When the values ​​are the same, kThe larger the value, the shorter the encoding time. k When the values ​​are the same, m The smaller the value, the shorter the encoding time. k =3, m =2 and k =4, m =2, the encoding time is shorter, 19.96ms and 20.03ms respectively. k =5, m =4, the longest encoding time is 41.41ms, which is about 107% longer than the previous two. m When the values ​​are the same, k The larger the value, the longer the decoding time. k When the values ​​are the same, m The larger the value, the shorter the decoding time. k =3, m =2 and k =4, m =2, the decoding time is 10.76ms and 10.82ms respectively. k =5, m =2, the decoding time is 11.73ms.

[0030] Block storage overhead: Block storage overhead refers to the storage space occupied by a single block stored on a blockchain node. S Represents the block storage overhead: ; Indicates the size of the block, Indicates the number of groups storing the block; like Figure 4 As shown, when k =5, m =2, the minimum storage overhead of the block is 3.89MB. k =4, m =2 and k =3, m =2, the storage overhead of the block is 4.35MB and 5.32MB respectively; in summary, when k =4, m =2 when storage overhead ratio k =3, m =2 reduces 18.2%, encoding and decoding consumption ratio k =5, m =2 decreased by 32.2% and 4.8% respectively; like Figure 5 As shown, when m When the values ​​are the same, k The larger the value, the smaller the recovery cost. k When the values ​​are the same, mThe larger the value, the smaller the recovery cost. k =5, m =4, the ratio of the minimum recovery overhead to the original data volume is 0.4, but the encoding and decoding time and storage overhead under this scheme are high, and the communication cost of recovering data will increase because the data is distributed on multiple nodes; like Figure 6 As shown in the figure, the number of nodes is set to 30, 40, 50, 60, 70 and 80 respectively. The centralized allocation algorithm proposed by BFT-DSN attempts to store the decoded block units on as few nodes as possible. However, to ensure the reliability of storage, the block units have to be backed up and stored on multiple nodes, which invisibly increases the overhead of block storage. Similarly, PartitionChain combines the erasure code mechanism with Byzantine fault tolerance. Although this improves the fault tolerance of the blockchain system, the encoded block units still need to be backed up and stored on multiple nodes to ensure the reliability of block storage. The method proposed in this example and BSUE divide the nodes into multiple groups, and the encoded block backup is stored in multiple groups instead of backing up in each group, which effectively reduces the overhead of block storage while ensuring the reliability and integrity of the data.

[0031] Recovery delay: Decoding communication delay: A block is stored in a node group, and the average communication overhead of all nodes in the group decoding the block; Data recovery delay: This patent hopes that the proposed method can restore the lost data on the node in the shortest time after the node fails to prevent permanent loss. Let G represent the data recovery delay:

[0032] Indicates the time point when decoding is successful. Indicates the time point when decoding is requested; like Figure 7 As shown, the malicious node ratio is set to 0.1, and the number of nodes is set to 30, 40, 50, 60, 70, and 80 respectively. As the number of nodes increases, the block decoding delay increases; like Figure 8 As shown, the number of nodes is set to 80, and the proportion of malicious nodes is set to 0.1, 0.2, 0.3, and 0.4 respectively. As the proportion of malicious nodes increases, the block decoding communication delay increases; When a node needs a complete block, the node needs to read at least k block units from other nodes (including itself) to decode the original block; BFT-DSN does not consider the difference in communication delay between nodes. As the number of nodes increases, nodes may frequently send and receive messages with nodes with longer communication delays, which increases the communication delay; BUSE divides nodes with small communication delay differences into the same group to reduce communication overhead, but since not all nodes in each group have established connections, nodes need to forward request messages multiple times to obtain a sufficient number of block units; PartitionChain designs a reputation ranking mechanism to regularly detect dishonest behavior of nodes and punish malicious nodes, so as the proportion of malicious nodes increases, the block decoding delay remains stable; The method proposed in this embodiment continuously optimizes storage allocation during the learning process, and reduces the communication delay by limiting the communication delay of request data. It takes into account both the storage efficiency of data and the communication delay of block decoding, and effectively solves the problem of excessive block decoding overhead; like Fig. 9 As shown, the malicious node ratio is set to 0.1, and the number of nodes is set to 30, 40, 50, 60, 70, and 80. As the number of nodes increases, the number of request messages increases; like Fig.10 As shown, the number of nodes is set to 80, and the proportion of malicious nodes is set to 0.1, 0.2, 0.3, and 0.4 respectively. As the proportion of malicious nodes increases, the number of request messages increases; The centralized allocation algorithm proposed by BFT-DSN does not consider the detection of malicious nodes. When the proportion of malicious nodes increases, the number of request messages increases and the communication complexity is greatly increased. PartitionChain divides each block into smaller blocks for encoding, which reduces the transmission delay of a single data volume. BUSE takes malicious nodes into consideration to reduce the invalidation of block data due to the behavior of malicious nodes. Since the nodes are not fully connected, the reception and transmission of messages need to be forwarded by multiple nodes, resulting in the number of request messages of PartitionChain and BUSE increasing as the proportion of malicious nodes increases. The allocation method proposed in this embodiment calculates the reward of the node according to the performance of the node during the learning process. When the node behaves maliciously, the optimized allocation algorithm will consider using the node for storage tasks less often. The increase in the proportion of malicious nodes greatly reduces the impact of the method proposed in this embodiment. Therefore, the method proposed in this embodiment can achieve the minimum number of message requests under different malicious node proportions. like Fig.11 As shown in the figure, when a node fails (abnormal or offline), all block data stored in the node will fail, and the failed data needs to be restored and stored in a new node; BFT-DSN uses a centralized allocation algorithm to allocate block units to nodes to reduce block storage overhead. When data on a single node fails, a data unit of the node is restored from k The total size read and transferred on nodes is The centralized allocation algorithm does not consider the communication delay between nodes, resulting in a large amount of data transmitted during data recovery and a large communication overhead; BUSE groups nodes according to the communication delay between nodes, and nodes with small communication delay differences are grouped into the same group. When performing data recovery, the communication overhead between nodes is reduced, but the total amount of data transmitted remains unchanged; PartitionChain divides each block into smaller blocks and encodes each block to reduce the amount of data transmitted during data recovery, but the lack of an allocation algorithm requires complex communication between nodes to read the required data; the method proposed in this embodiment takes into account the differences in connection and communication delay between nodes, and allocates block units to corresponding nodes for storage through an allocation algorithm that is continuously optimized during learning, so that the data recovery communication complexity is greatly reduced and is always stable at around 100ms. Therefore, the method proposed in this embodiment achieves lower data recovery delay than the comparative method.

[0033] Transaction throughput: Throughput refers to the number of transactions processed per unit time. T The transaction throughput of the blockchain network is: Indicates the number of transactions processed in the blockchain network. Indicates the time it takes to process a transaction in the blockchain network; like Fig.12 As shown, BFT-DSN combines erasure codes and threshold signatures. Although the threshold signature algorithm can ensure the verifiability of block units, this work is very time-consuming. To reduce computational complexity, PartitionChain divides each block into smaller blocks according to the size of a single block before encoding, so it can achieve a higher transaction throughput than BFT-DSN. The method proposed in this embodiment and BSUE divide the nodes into several node groups. The communication delay of nodes in each node group is low, and the encoding and storage of blocks occur in parallel in the node group. The encoded block units can be quickly stored on the corresponding nodes. Therefore, the transaction throughput of the method proposed in this embodiment and BSUE is higher than that of BFT-DSN and PartitionChain.

[0034] In summary, in terms of experimental performance of storage overhead, communication delay and number of request messages during decoding, data recovery delay and transaction throughput, the method proposed in this embodiment has the best overall performance.

[0035] Example 2 A computer-readable storage medium stores a computer program, which, when executed by a processor, implements the steps of the following method: Encoding the original block data to obtain multiple block units; Calculate the storage load difference, block decoding communication overhead and node reputation of the target blockchain node group; Determine the optimal block unit allocation scheme with low load difference and low decoding communication overhead between nodes based on the storage load difference, block decoding communication overhead and node reputation of the target blockchain node group; storing the block units according to the optimal block unit allocation scheme; Select a block unit that meets the decoding requirements from the block units stored in the target blockchain node group; The selected block units are decoded to obtain complete original block data.

[0036] Example 3 A computer device comprising: A memory for storing instructions; The processor is configured to execute the instructions so that the device performs the steps of implementing the following method: Encoding the original block data to obtain multiple block units; Calculate the storage load difference, block decoding communication overhead and node reputation of the target blockchain node group; Determine the optimal block unit allocation scheme with low load difference and low decoding communication overhead between nodes based on the storage load difference, block decoding communication overhead and node reputation of the target blockchain node group; storing the block units according to the optimal block unit allocation scheme; Select a block unit that meets the decoding requirements from the block units stored in the target blockchain node group; The selected block units are decoded to obtain complete original block data.

[0037] Those skilled in the art will appreciate that the embodiments of the present application may be provided as methods, systems, or computer program products. Therefore, the present application may take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. Moreover, the present application may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage CD-ROM, optical storage, etc.) containing computer-usable program codes.

[0038] The present application is described with reference to the flowcharts of the methods, devices (systems), and computer program products according to the embodiments of the present application. It should be understood that each process in the flowchart can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the process in the flowchart. Figure 1 A process or multiple processes or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0039] These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 A function specified in a process or multiple processes.

[0040] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for implementing the process. Figure 1 The steps of a specified function in a process or multiple processes.

[0041] The embodiments of the present invention are described above in conjunction with the accompanying drawings, but the present invention is not limited to the above-mentioned specific implementation methods. The above-mentioned specific implementation methods are merely illustrative and not restrictive. Under the enlightenment of the present invention, ordinary technicians in this field can also make many forms without departing from the scope of protection of the purpose of the present invention and the claims, which all fall within the protection of the present invention.

Claims

1. A blockchain node data exchange method, characterized in that: include: Encoding the original block data to obtain multiple block units; Calculate the storage load difference, block decoding communication overhead and node reputation of the target blockchain node group for each block unit; Determine the optimal block unit allocation scheme with low load difference and low decoding communication overhead among target blockchain nodes according to the storage load difference, block decoding communication overhead and node reputation of the target blockchain node group; According to the optimal block unit allocation plan, determine the block units that meet the allocation requirements, and store the block units that meet the allocation requirements in the target blockchain node group; Selecting a block unit that meets the decoding requirement from the block units that meet the allocation requirement and are stored in the target blockchain node group; The block units that meet the decoding requirements are decoded to obtain complete original block data.

2. The blockchain node data exchange method according to claim 1, characterized in that: The calculation of the storage load difference, block decoding communication overhead and node reputation of the target blockchain node group for each block unit includes: The storage load difference of the target blockchain node group is calculated by the following formula: in: Indicates the storage load difference of the target blockchain node group, Indicates the number of nodes in the target blockchain node group; Indicates the storage load difference of the nodes, ; Representation Node The relative storage load, , Representation Node i The number of blocks stored, Representation Node The maximum number of storable block units; represents the average relative storage load, ; The block decoding communication overhead is calculated by the following formula: ;in: Represents the average communication overhead of all nodes in the target blockchain node group during the decoding process; Representation Node Request to k The communication overhead of each block unit is k It indicates the number of block units that ensures that the communication overhead during decoding can be reduced. , Representation Node Read to block unit j The communication overhead required, , Indicates a request to a block unit j The set of nodes passed through, Representation Node p With Node q Communication overhead between The node reputation is calculated by the following formula: ;in: Represents the average reputation value of the nodes in the current allocation scheme; Indicates the target blockchain node group, m Indicates the number of coding units generated by encoding the original block data; Set K Indicates the current allocation plan. ; Representation Node i Whether to store a block unit; ; Representation Node i The reputation value, , Indicates the node before the current allocation plan i Reputation value; Representation Node i Performance score during decoding; ; The weight representing the proportion of request response time; The weight representing the proportion of valid block units; Indicates the ratio threshold of valid block units transmitted by the node. If the ratio of valid block units transmitted by the node is greater than , then the node's reputation value is increased, otherwise, the node's reputation value is reduced; express The normalized value of Indicates the node under the current allocation scheme i The proportion of the response request time to the response time of all nodes, , Representation node i The average response time, Representation Node j Average response time; express X i The normalized value of X i Indicates that the node is in the decoding process under the current allocation scheme i The proportion of valid block units transmitted, , Representation Node i The number of valid block units during transmission, Representation Node i The total number of block units in transfer process.

3. The blockchain node data exchange method according to claim 1, characterized in that: The method of determining an optimal block unit allocation scheme with low load difference and low decoding communication overhead among target blockchain nodes according to the storage load difference, block decoding communication overhead and node reputation of the target blockchain node group includes: Construct an optimization problem based on the storage load differences, block decoding communication overhead, and node reputation of the target blockchain node group; Based on Markov decision making, the optimization problem is mapped to an observable virtual state space; Construct a reward function with the optimization goal of maximizing the reduction of load difference and decoding communication overhead; Based on the reward function, the optimal block unit allocation scheme with low load difference and low decoding communication overhead between nodes is determined in the observable virtual space.

4. The blockchain node data exchange method according to claim 3 is characterized in that: According to the storage load difference, block decoding communication overhead and node reputation of the target blockchain node group, an optimization problem is constructed, including: The optimization problem is expressed as: st ； ;in: represents the optimal block unit allocation scheme; Indicates the storage load difference of the target blockchain node group; Represents the average communication overhead of all nodes in the target blockchain node group during the decoding process; Represents the average reputation value of the nodes in the current allocation scheme; Indicates the minimum threshold of the average reputation value; Representation Node i The number of stored block units; Representation Node i The maximum number of block units that can be stored; Indicates the number of block units that a node can request; Indicates the number of block units that ensures that the communication overhead during decoding can be reduced; Indicates the number of coding units generated by encoding the original block data.

5. The blockchain node data exchange method according to claim 3 is characterized in that: The Markov decision-making method maps the optimization problem to an observable virtual state space, including: The node status group is represented by the following formula: ; in: Indicates the storage status of all nodes in the target blockchain node group; Represents the nodes in the target blockchain node group, r Indicates the number of nodes in the target blockchain node group; The allocation action group is expressed as follows: ; in: Represents all possible combinations of block units and nodes; Indicates the number of possible block unit allocation schemes ， ; Indicates i block unit allocation action, (1 ≤i≤f ).

6. The blockchain node data exchange method according to claim 3, characterized in that: The reward function is constructed with the optimization goal of maximizing the reduction of load difference and decoding communication overhead, including: The reward function is constructed as follows: ； in: The instant reward of the allocation scheme is calculated based on the node load difference and communication overhead as indicators; A weight representing the difference in storage load; represents the weight of decoding communication overhead; L Indicates the difference in storage load of the target blockchain node group; Represents the average communication overhead of all nodes in the target blockchain node group during the decoding process; Indicates the number of block units that a node can request; Indicates the number of block units that ensures that the communication overhead during decoding can be reduced.

7. The blockchain node data exchange method according to claim 1, characterized in that: The step of selecting a block unit that meets the decoding requirement from the block units that meet the allocation requirement and are stored in the target blockchain node group includes: Get the block units stored in the target blockchain node group; The acquired block units are verified, and the block units are retained or discarded based on the verification results until the number of block units meets the decoding requirements.

8. The blockchain node data exchange method according to claim 7, characterized in that: The obtaining block units are verified, and the block units are retained or discarded based on the verification results until the number of block units meets the decoding requirements, including: The Merkle root of a block unit is calculated by the following formula: in: Represents a block unit The hash value of , and Represents a block unit The hash value in the Merkle path; Represents a hash value With hash value The upper layer hash value after combined calculation; Represents a hash value With hash value The upper layer hash value after combined calculation; Represents a block unit of Merkel's roots; The Merkle root of the block unit is compared with the real Merkle root stored in the block header. If the Merkle root of the block unit matches the real Merkle root, the block unit is retained, otherwise the block unit is discarded and the next block unit is verified until the number of block units meets the decoding requirements.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the blockchain node data exchange method as described in any one of claims 1 to 8 is implemented.

10. A computer device, characterized in that: include: A memory for storing instructions; A processor is used to execute the instruction so that the device implements the blockchain node data exchange method as described in any one of claims 1 to 8.

Images