Block chain data storage and reading method based on block aggregation coding

Abstract

The invention belongs to the technical field of block chains and erasure codes, and particularly discloses a block chain data storage and reading method based on block aggregation coding, and the method comprises the steps: carrying out the aggregation and coding of a plurality of blocks through the erasure codes according to the block storage characteristics, and obtaining a coding block; performing data recoding on the coding block according to data migration characteristics when the scale of the block chain node changes, and completing block chain data storage; and according to the data reading characteristics of the coding blocks, carrying out block reading by adopting an optimized reading process based on local node downloading, node downloading and remote coding group block downloading. According to the method, the problems of high block chain data storage redundancy and low data processing efficiency when the number of nodes in the system is changed are solved.

Description

Technical Field

[0001] The present invention belongs to the technical fields of blockchain and erasure code, and particularly relates to a blockchain data storage and reading method based on block aggregation coding. Background Art

[0002] As an important breakthrough in core technologies, blockchain represents an important direction for the development of the digital economy and has broad application prospects in various fields such as finance, the Internet of Things, public management, transportation, medical insurance, and education. In the financial field, applying blockchain technology can directly connect users without the intervention of a third-party institution in the transaction process; in the logistics field, applying blockchain technology can realize the traceability query of the whole-process information of goods, thereby reducing logistics costs and optimizing the logistics management process; in the medical insurance field, applying blockchain smart contract technology can enable automatic claims settlement for eligible insurance policies, streamlining the insurance claims settlement process.

[0003] The characteristics of decentralization and data immutability possessed by blockchain provide a highly promising solution for solving different challenges faced in various fields. However, the high-redundancy storage mechanism of existing blockchain systems restricts their further development. In practical applications, to ensure data consistency among nodes in the system, blockchain relies on a storage mechanism where all full nodes save data. Although this method enhances the fault tolerance of data, it also leads to problems such as low storage performance and poor scalability. As of January 2025, the complete Ethereum block data has reached 1089GB, and the overall data volume is still growing at a relatively fast rate. Currently, running a complete Ethereum node requires at least hundreds of GB or even TB-level storage space, resulting in an increasingly higher requirement for the node storage capacity of the system; for consortium blockchains with higher throughput, their throughput can reach hundreds or even thousands of times that of public blockchains. Therefore, the generation speed of block data will also reach an incredible level. After the Ant Blockchain based on the PBFT algorithm has been running stably for one year, the required storage space will reach about 6TB.

[0004] All nodes need to retain a copy of the entire blockchain, which poses a huge storage pressure. Moreover, as the number of blockchain nodes increases, this phenomenon not only fails to be alleviated but instead becomes a major obstacle to the addition of new nodes, seriously affecting the scalability of the blockchain and restricting its further development. To solve the above problems, many studies have attempted to optimize the storage mechanism of the blockchain system in recent years to improve its scalability. Among them, erasure coding, a technology widely used in traditional distributed storage systems in recent years, has begun to be explored for integration into the blockchain system, aiming to significantly improve data storage efficiency while ensuring the consistency of block data. However, although the current solutions using erasure coding technology to optimize the performance of the blockchain system can reduce the storage redundancy of the blockchain system to a certain extent, they still have problems such as low block access efficiency and large cross-node communication overhead. Summary of the Invention

[0005] The purpose of the present invention is to solve the problems of high blockchain data storage redundancy and low data processing efficiency when the number of nodes in the system changes, and a blockchain data storage and reading method based on block aggregation coding is proposed.

[0006] The technical solution of the present invention is as follows: In the first aspect, a blockchain data storage method based on block aggregation coding includes the following steps: According to the block storage characteristics, multiple blocks are aggregated and encoded using erasure coding to obtain encoded blocks; According to the data migration characteristics when the scale of blockchain nodes changes, the encoded blocks are re-encoded to complete the storage of blockchain data.

[0007] Preferably, the erasure coding uses RS code; the step of aggregating and encoding multiple blocks using erasure coding according to the block storage characteristics to obtain encoded blocks is specifically as follows: Perform encoding operations using RS code, and set the encoding parameters as , , where and represent the encoding parameters, represents the total number of nodes, represents the upper limit of the number of malicious nodes tolerated, and every blocks are packed and encoded as a block set; Each node stores every newly consensus block in its local cache. In response to detecting that the number of blocks in the local cache reaches , the node takes out blocks to form a block set and encodes the block set.

[0008] Preferably, the encoding of the block set is specifically as follows: Using the maximum block size in the same block set as the standard, the remaining blocks are extended to the same size as the largest block by padding with zeros at the end, generating check blocks of the same size, and then obtaining blocks of the same size as a coding group, and assigning a unique and incrementally increasing identifier epoch to this coding group; Sort all nodes through the general information of each node; Utilize the epoch common to all nodes and the current number of nodes to initialize the pseudo-random number generator; Generate the same natural number sequence for all nodes through the initialized pseudo-random number generator, and the natural number sequence contains 1 to in total natural numbers. Each node selects one block in this coding group for storage. If the natural number is ranked at the th position in the sequence, it means that the node ranked stores the th block in the coding group, and delete the remaining blocks in the block set where the selected block is located.

[0009] Preferably, when the scale of the blockchain nodes changes, the total number of nodes changes, and there are two cases for the upper limit of the tolerated number of malicious nodes changing and remaining unchanged.

[0010] Preferably, when the access of new nodes causes the upper limit of the tolerated number of malicious nodes to change, the data of the coded blocks is re-coded, specifically: At the new node side, broadcast a block request for the current coding round to the original nodes. In response to the original nodes receiving blocks, re-code to generate new check data blocks; calculate the storage location of the check data blocks through pseudo-random numbers, and in the broadcast process of the next round of re-coding, send the check data blocks to the target nodes storing the check data blocks through the new nodes; At the original node side, in response to the broadcast information of the new nodes, check whether the broadcast information correctly contains the signatures of the previous nodes, and return the corresponding blocks stored locally in this coding round and the signatures of this node; if the original nodes need to store the check data blocks calculated by the new nodes in the previous round, check whether the broadcast information contains the check data blocks and store them; Recursively re-code the historical blocks according to each coding round of the blocks until all data is processed.

[0011] Preferably, when the exit of nodes causes the upper limit of the tolerated number of malicious nodes When there is a change, the data of the encoding block is re-encoded, specifically as follows: At the node to be exited, send the block data of the current encoding round stored locally to all other nodes; At all other nodes, in response to the block data of the node to be exited, send a response to the node to be exited. The node storing the verification block updates the local verification block data according to the block data and adds the hash of the updated verification block data to the response; At the node to be exited, in response to the responses of all nodes, broadcast the hash of the verification block data among them to all other nodes; At all other nodes, in response to the broadcast message of the node to be exited, store the block hash locally and send a response to the node to be exited; Recursively re-encode the historical blocks according to each encoding round of the blocks until all data is processed.

[0012] Preferably, when a new node joins and the upper limit of the tolerated number of malicious nodes remains unchanged, the data of the encoding block is re-encoded, specifically as follows: The new node sends a broadcast message to request all blocks of each round from all existing nodes; In response to the broadcast message sent by the new node, the existing nodes return the blocks; The new node stores the corresponding blocks, sends the corresponding blocks to the nodes storing the verification data blocks through the new node, sends the blocks of the current round received by the new node to the target nodes that need to perform block exchange through the new node, and sends the response signatures of the previous round of all nodes through the new node; In response to the information of the new node, the nodes storing the verification data blocks perform an update operation on the stored verification data blocks of the current round; The target nodes that need to perform block exchange return the replacement blocks, and determine whether the broadcast message contains the response signatures of the previous round of nodes. If it contains, sign and respond; if not, do not respond; Recursively re-encode the historical blocks according to each encoding round of the blocks until all data is processed; When a node exits and the upper limit of the tolerated number of malicious nodes remains unchanged, the data of the encoding block is re-encoded, specifically as follows: The node to be exited sends a broadcast message to send all blocks of each round to all other nodes; In response to the broadcast information of the node to be exited, send responses received for the block data through all other nodes; In response to the responses of all other nodes, send a broadcast message through the node to be exited, notifying the nodes storing the verification blocks to perform calculation processing on the original verification blocks; Based on the received block data, the nodes storing the verification blocks update the original verification blocks locally and broadcast the hash of the new verification block data.

[0013] The beneficial effects of the present invention are: The present invention uses erasure codes to encode and store blocks, and designs different block re-encoding processes for scenarios with changes in the number of nodes, having lower data transmission volume and data processing latency, and improving the usability of the method as a whole.

[0014] In a second aspect, a method for reading blockchain data based on block aggregation encoding includes the following steps: According to the data reading characteristics of the encoded blocks, adopt an optimized reading process based on local node download, node download, and off-site encoded group block download to read the blocks.

[0015] Preferably, the data reading characteristics of the encoded blocks include three types: uncoded cache, local storage, or cross-node acquisition; The encoded blocks with uncoded cache complete block reading through local node download; The encoded blocks with local storage complete block reading by downloading through off-site nodes; The encoded blocks that need cross-node acquisition complete block reading through off-site encoded group block download.

[0016] Preferably, according to the data reading characteristics of the encoded blocks, the blocks are read through an optimized reading process, specifically: In response to a request from a client for a block Verify whether the difference between the height of the current latest block and the height of the block is less than or equal to the remainder of the current latest block index divided by If so, it indicates that the block is an uncoded cache block, retrieve and return the block from the local cache; If the difference between the height of the current latest block and the height of the block is greater than the remainder of the current latest block index divided by then the block does not belong to the latest upcoming encoded block group, use the height of the block to determine the current encoding round, and calculate the block Position in its encoding round; Calculate the node for locating the actual storage block ; If the block is a local storage block located at the local node, retrieve and return the block from the node status database ; If the block is a block that needs to be obtained across nodes, send a request to the target node of the storage block and start a timer; If there is no response from the target node before the timer expires, or due to network latency, the block fails to arrive in time, then broadcast a request to the entire network to seek other nodes to obtain the remaining blocks of the storage block in the same encoding group.

[0017] The beneficial effects of the present invention are: The present invention uses erasure codes to encode and store blocks, and designs an optimized reading process for block acquisition, so as to further improve the block reading efficiency and achieve efficient data processing on the premise of ensuring the reduction of block storage redundancy. Description of the Drawings

[0018] Figure 1 The figure shows a flowchart of a blockchain data storage method based on block aggregation encoding provided in Embodiment 1 of the present invention.

[0019] Figure 2 The figure shows a schematic diagram of the principle of block data aggregation encoding storage based on erasure code technology provided in Embodiment 1 of the present invention.

[0020] Figure 3 The figure shows a schematic diagram of the data re-encoding process when the blockchain expansion causes a change in f provided in Embodiment 1 of the present invention.

[0021] Figure 4 The figure shows a schematic diagram of the data migration process when the blockchain expansion causes f to remain unchanged provided in Embodiment 1 of the present invention.

[0022] Figure 5 The figure shows a schematic diagram of the data re-encoding process when the blockchain expansion causes f to remain unchanged provided in Embodiment 1 of the present invention.

[0023] Figure 6 The figure shows a schematic diagram of the data migration process when the blockchain expansion causes f to remain unchanged provided in Embodiment 1 of the present invention. Detailed Embodiments

[0024] The exemplary embodiments of the present invention will now be described in detail with reference to the accompanying drawings. It should be understood that the embodiments shown and described in the drawings are merely exemplary, intended to illustrate the principles and spirit of the present invention, and not to limit the scope of the present invention.

[0025] Example 1: As Figure 1 shown, a blockchain data storage method based on block aggregation coding includes the following steps: S1. According to the block storage characteristics, use erasure codes to aggregate and encode multiple blocks to obtain encoded blocks; S2. According to the data migration characteristics when the scale of blockchain nodes changes, perform data re-encoding on the encoded blocks to complete the storage of blockchain data.

[0026] In this embodiment, the present invention first packs multiple blocks into a block set and encodes the block set using the RS code. Subsequently, when the encoding is completed, a single node only stores one block in the set and deletes the remaining blocks to achieve the purpose of improving storage efficiency. The complete process is as Figure 2 shown, and the specific step S1 is as follows: The erasure code uses the RS code; the step of using the erasure code to aggregate and encode multiple blocks according to the block storage characteristics to obtain encoded blocks is specifically as follows: Perform encoding operations using the RS code, and set the encoding parameters as , , where and represent the encoding parameters, represents the total number of nodes, represents the upper limit of the number of malicious nodes tolerated, and every blocks are packed and encoded as a block set; Each node stores each newly consensus block in the local cache. In response to detecting that the number of blocks in the local cache reaches , the node takes out blocks to form a block set and encodes the block set. Specifically: Using the maximum block size in the block set as the standard, extend the remaining blocks to the same size by padding 0 at the end to generate check blocks of the same size, and then obtain blocks of the same size as an encoding group, and assign it a unique identifier epoch that increases step by step.

[0027] Since there are a large number of access requests for block data in the blockchain system, and the generated check blocks are meaningless 01 sequences, when a node storing check blocks receives a block request, it needs to forward the request to other nodes, which indirectly increases the load of the node. Therefore, in order to balance the number of check blocks stored by each node, the present invention first sorts all nodes according to general information such as the IP of each node, and this sorting can automatically reach a consensus among all nodes. Subsequently, a pseudo-random number generator is used to determine how blocks of a coding group are stored in the system on nodes, and uses the epoch common to all nodes and the current number of nodes to initialize the pseudo-random number generator. All nodes can generate an identical natural number sequence, which contains 1 to natural numbers in total. If the natural number is ranked at the th position in the sequence, it means that the node ranked will store the th block in this coding group. Each node selects a block in this coding group for storage according to the corresponding rule between the natural number and the ranking , and deletes the remaining blocks in the block set where the selected block is located. By this approach, all nodes can store different blocks in this coding group, and the storage positions of the coding blocks are completely random, ensuring the load balance among nodes.

[0028] When applying erasure codes to the blockchain system, while reducing storage redundancy, it is necessary to ensure the security and recoverability of each block. Since all blocks are stored only once, the settings of the coding parameters and need to be consistent with the tolerance quantity of malicious nodes in the PBFT protocol. Since the PBFT protocol can tolerate at most malicious or down nodes in the whole network, for a block coding group, the coding parameters should also be set to tolerate at most blocks lost or damaged, so that the size of r can be obtained that needs to be set at least as , the size of is at most

[0029] Only considering when adding erasure codes, the present invention can reduce the data storage complexity from to , that is, the storage consumption of data does not show an obvious linear change with the increase in the number of nodes, and is only related to the size of the entire network block data volume.

[0030] In this embodiment, in the step S2, when the scale of the blockchain nodes changes, the total number of nodes changes, and the upper limit of the number of malicious nodes tolerated There are two cases of change and non-change. Specifically, when a node joins or exits the system, the quantity change is divided into multiple types, and the availability of the block data after the node quantity change is ensured by migrating the internal data of the node or re-encoding.

[0031] When the number of nodes in the system changes, it indicates that there are cases of dynamic joining or exiting of nodes in the blockchain network, which will involve a large amount of data transmission and requires replication of the entire network data; in addition, the introduction of existing erasure codes into the research of blockchain will further increase the data transmission volume during the processing of network changes, usually reaching several times or even dozens of times the entire network data volume. Based on this, the embodiments of the present invention analyze the data migration and re-encoding rules when the number of nodes changes, so as to reduce the data transmission volume involved in this process and improve the operation efficiency of the blockchain.

[0032] When a node joins in the embodiment of the present invention, the total number of nodes in the entire network will increase by one, but the maximum number of malicious nodes that can be tolerated is divided into two cases of change and non-change (it should be noted that in the embodiment of the present invention, the situation where the newly added node crashes during the re-encoding process is regarded as successfully joining the blockchain).

[0033] When the number of nodes changes, it will cause the total number of nodes in the system to change. When a new node is added to the system, it will increase by one, that is , but the upper limit of the number of malicious nodes tolerated may have two cases of change and non-change, that is, only when , the addition of a node will cause the system state to change to , where , and when or , the increase in the number of nodes by one will only cause to change, while remains unchanged.

[0034] The addition of a node causes to change, and the change means that for each block in the coding group, a parity block needs to be added. Therefore, after a new node is added, all nodes need to calculate a new parity block for each original block in the coding group and store it on the new node. In order to balance the distribution of the parity blocks, the new node needs to probabilistically exchange blocks with other nodes.

[0035] Specifically, since the operation is performed on the check block when there is a change, and the check block can be immediately calculated, generated, or deleted, compared with the case where it remains unchanged, the change is relatively simple when there is a change. When a new node is added, it needs to request blocks from all other nodes and perform encoding. For each encoding round, a new check data block is generated. Subsequently, in order to maintain the uniform distribution of the check data blocks, it needs to randomly exchange the blocks of this encoding round with an existing node. The specific process is as Figure 3 shown.

[0036] The recoding protocol performs cyclic recoding on the historical blocks according to each encoding round of the blocks until all data is processed: At the new node side, the new node broadcasts a block request for the current encoding round to the remaining nodes (attaching the signatures of the previous corresponding nodes). Due to the PBFT protocol, it can ensure that at least correct blocks are received. After the node receives blocks, it starts to recode, generates a new check data block, and calculates the storage location of the block through a pseudo-random number. Subsequently, in the broadcast process of the next round of recoding, the new node simultaneously sends the check block to the target node that should store the check block; At the existing node side, when an existing node receives the broadcast information from the new node, it first checks whether the signatures of the previous nodes are correctly included inside, and then returns the corresponding block stored locally in this encoding round and the signature of this node; at the same time, if the node needs to store the check data block calculated by the new node in the previous round, it also checks whether the broadcast information contains the check data block and stores it.

[0037] When the upper limit of the tolerated number of malicious nodes changes due to the exit of a new node, the data of the encoded blocks is recoded specifically as follows: At the node to be exited, it sends the block data of the current encoding round stored locally to all other nodes; all other nodes send responses to the node to be exited after receiving the block data. The nodes storing the check blocks need to update the local check block data according to the block data and add the hash of the updated check block data to the response; after the node to be exited receives responses from nodes, it broadcasts the hash of the check block data among them to all other nodes; after all other nodes receive the broadcast message, they store the block hash locally and send responses to the node to be exited; cyclic recoding is performed on the historical blocks according to each encoding round of the blocks until all data is processed.

[0038] Among them, in order to enable all nodes in the network to reach a consensus on the storage location of the newly calculated parity blocks in each coding round, the present invention uses (Epoch, ) as the seed of the pseudo-random number generator to generate the storage location of the new parity blocks in this round in a uniform distribution. In addition, in order to enable nodes to verify the correctness of the newly calculated parity data blocks in each re-coding round, all nodes in the network pre-calculate the parity blocks (0-2) that may be used in the future when encoding and storing each new consensus block, but do not store their block bodies, and only store their block headers to cope with subsequent verification behaviors.

[0039] Node joining When unchanged, no new blocks need to be added when unchanged. It is only to redistribute the whole network data stored on nodes to +1 nodes, that is, for each block in the coding group, a new real block needs to be added to its real block set. A simple approach is to take a real block from the next coding group and add it to this coding group. However, this approach will cause a large number of block migrations among nodes; while the present invention replaces the newly added real block with a blank block in each coding group, and the blank blocks of each coding group are randomly distributed on different nodes to complete the uniform distribution of the whole network block data. Subsequently, the newly consensus blocks will be filled into the blank blocks in sequence. Specifically: Remaining unchanged is essentially equivalent to the data migration of real blocks and the recalculation of coded blocks. When the number of nodes increases from 7 to 8, as Figure 4 shown, the change of block data can be regarded as distributing the real blocks in every ( ) coding rounds under seven nodes to every ( ) coding rounds under eight nodes, and modifying the parity data blocks in these ( ) coding rounds. And in order to ensure the uniform distribution of parity data blocks, the newly added node needs to randomly exchange blocks with the original nodes.

[0040] Same as the situation of change, the present invention also recodes the historical blocks in a cyclic manner according to each coding round of the blocks until all data is processed, Figure 5 The following is the detailed process of the protocol: The newly added node sends a broadcast message to request all blocks of each round from all the other nodes; The other nodes return the blocks after receiving the broadcast message; The newly added node stores the corresponding blocks (obtains After a response), and send messages to all other nodes (send the corresponding block to the node storing the verification block in this round, send the block received by the new node in this round to the target node that needs to perform block exchange, and send the response signatures of the nodes in the previous round to all nodes); The response signatures of the nodes; All nodes perform corresponding operations and responses after receiving the messages (the verification nodes in this round perform update operations on the verification blocks stored in this round after receiving the blocks in this round, the target nodes that need to perform block exchange return the replacement blocks, and all nodes determine whether the broadcast message contains The response signatures of the nodes in the previous round, and if so, perform signature and response).

[0041] When the upper limit of the number of malicious nodes tolerated by the new node exits Remains unchanged, the data of the encoded block is re-encoded, specifically: After a node exits, send a broadcast message and send all blocks of each Round to all other nodes; Other nodes send responses to the received block data; The node to exit sends a broadcast message to notify the node storing the verification block to perform calculation processing on the original verification block; The node storing the verification block updates the original verification block locally based on the received block data and broadcasts the hash of the new verification block data.

[0042] Embodiment 2: On the basis of Embodiment 1, the embodiment of the present invention further provides a method for reading blockchain data based on block aggregation encoding, which is used to read the blockchain data stored by the blockchain data storage method described in Embodiment 1. The method for reading blockchain data based on block aggregation encoding includes the following steps: According to the data reading characteristics of the encoded block, an optimized reading process based on local node download, node download, and cross-regional encoded group block download is adopted to read the block.

[0043] The data reading characteristics of the encoded block include three types: uncoded cache, local storage, or cross-node acquisition; the encoded block with uncoded cache completes block reading through local node download; the encoded block with local storage completes block reading through node download; the encoded block that needs to be acquired across nodes completes block reading through cross-regional encoded group block download.

[0044] The original high data redundancy of the blockchain can not only ensure the state consistency among nodes, but also maximize the speed of reading block data. After introducing erasure codes, blocks are encoded and stored, and each node only stores some blocks of the whole chain. Therefore, when a node needs to obtain information about blocks that are not stored, it needs to download the blocks through cross-node network communication, resulting in communication delay problems. To solve this problem, the present invention redesigned the reading process of blocks, and achieved the goal of nodes normally obtaining blocks through two methods: direct acquisition and calculation and repair. To respond to external block access requests, embodiments of the present invention complete the response to block requests through three target block download methods, including local node download, remote node download, and remote encoded group block download. Since the encoded storage based on erasure codes will lead to inconsistent block storage locations, the key to block reading is to calculate the storage location of the target block according to information such as block height and encoding round, and finally obtain the block through the corresponding target block download method.

[0045] Figure 6 Shows the detailed steps for a node to process a block access request. When a node receives a request for a block from a client, the system first verifies that the difference (Height - height) between the height (Height) of the latest block in the current system and the height (height) of the block is greater than the remainder of the division of the index of the latest block by [Height % (n - f)]. If so, it indicates that the block has not been encoded and stored yet and exists in the local caches of all formal nodes, and the node directly retrieves and returns the block from the local cache; If the difference between the height of the current latest block and the height of the block is greater than the remainder of the division of the index of the latest block by , it indicates that the block does not belong to the latest block group to be encoded. The system will use the height (height) of the block to determine the current encoding round , and calculate the position of the block in its encoding round through , where represents the block position, and represents the modulo operation; Calculate to locate the node where the actual stored block is located; If the block is a local storage block located at the local node, retrieve and return the block from the node status database; If the block If it is a block that needs to be obtained across nodes, a request is sent to the target node storing the block, and a timer is started; if there is no response from the target node before the timer expires, or due to network latency, the block fails to arrive in time, then this node broadcasts the request to the entire network to seek other nodes to obtain the remaining blocks of the encoding group where the stored block is located.

[0046] Due to the characteristics of PBFT, this node can receive at least valid block data or verification data from the system, and the requested block can be decoded and restored using these data. Once the block is successfully decoded, the system will temporarily cache it locally and return it to the client.

[0047] Those of ordinary skill in the art will realize that the embodiments described herein are to assist the reader in understanding the principles of the present invention, and it should be understood that the protection scope of the present invention is not limited to such specific statements and embodiments. Those of ordinary skill in the art can make various other specific deformations and combinations without departing from the essence of the present invention based on the technical revelations disclosed in the present invention, and these deformations and combinations are still within the protection scope of the present invention.​

Claims

1. A blockchain data storage method based on block aggregation encoding, characterized in that, Including the following steps: According to the block storage characteristics, use erasure codes to aggregate and encode multiple blocks to obtain encoded blocks; According to the data migration characteristics when the scale of blockchain nodes changes, perform data re-encoding on the encoded blocks to complete blockchain data storage.

2. The blockchain data storage method based on block aggregation coding according to claim 1, wherein The erasure code uses the RS code; the step of using erasure codes to aggregate and encode multiple blocks according to the block storage characteristics to obtain encoded blocks is specifically: Perform an encoding operation using RS code, and set the encoding parameters as , , where and represent the encoding parameters, represents the total number of nodes, represents the upper limit of the number of malicious nodes tolerated. Pack and encode every blocks as a block set. Store each block of the latest consensus in the local cache through a node. In response to detecting that the number of blocks in the local cache reaches , take out blocks through the node to form a block set, and encode the block set.

3. The blockchain data storage method based on block aggregation coding according to claim 2, wherein The step of encoding the block set is specifically: Using the maximum block size in the same block set as the standard, the remaining blocks are extended to the same size as the largest block by padding 0s at the end to generate check blocks of the same size, and then obtain blocks of the same size as a coding group, and assign a unique and incrementally increasing identifier epoch to this coding group; Sort all nodes through the general information of each node; Use the epoch common to all nodes and the current number of nodes Initialize the pseudo-random number generator; Generate the same natural number sequence for all nodes through an initialized pseudo-random number generator, where the natural number sequence contains 1 to a total of natural numbers. Each node selects a block in the encoding group for storage. The natural number ranked at the th position in the sequence indicates that the node ranked stores the th block in the encoding group, and deletes the remaining blocks in the block set where the selected block is located.

4. The blockchain data storage method based on block aggregation coding according to claim 1, wherein When the scale of the blockchain nodes changes, the total number of nodes changes, and the upper limit of the tolerated number of malicious nodes has two cases: changing and remaining unchanged.

5. The blockchain data storage method based on block aggregation coding according to claim 4, characterized in that, The upper limit of the tolerable number of malicious nodes caused by the access of new nodes When it changes, the data of the encoded block is re-encoded, specifically as follows: At the new node end, broadcast a block request for the current coding round to the original nodes. In response to the original nodes receiving blocks, re-encode to generate new parity data blocks; Calculate the storage location of the verification data block through a pseudo-random number. During the broadcast process of the next round of re-encoding, the new node sends the verification data block to the target node storing the verification data block; At the original node end, in response to the broadcast information of the new node, check whether the signature of the previous round of nodes is correctly included in the broadcast information, and return the corresponding block stored locally in this coding round and the signature of this node; If the original node needs to store the verification data block calculated by the new node in the previous round, check whether the broadcast information contains the verification data block and store it; Perform cyclic re-encoding on historical blocks according to each encoding round of the blocks until all data is processed.

6. The blockchain data storage method based on block aggregation encoding according to claim 4, wherein The upper limit of the malicious node tolerance quantity caused by the node exit When it changes, data re-encoding is performed on the encoded block, specifically as follows: At the end of the node to be exited, send the block data of the current encoding round stored locally to all other nodes; At all other node ends, in response to the block data of the node to be exited, send a response to the node to be exited. The node storing the verification block updates the local verification block data according to the block data and adds the hash of the updated verification block data to the response; At the node end to be exited, in response to the node responses of all other nodes, broadcast the hash of the verification block data therein to all other nodes; At all other node ends, in response to the broadcast message of the node to be exited, store the block hash locally and send a response to the node to be exited; Perform cyclic re-encoding on historical blocks according to each encoding round of the blocks until all data is processed.

7. The blockchain data storage method based on block aggregation encoding according to claim 4, wherein New node access, upper limit of the tolerated number of malicious nodes When unchanged, data re-encoding is performed on the encoded block, specifically: Send broadcast information through the new node and request all blocks of each round from all original nodes ; In response to the broadcast information sent by the new node, return the block through the original node; Use a new node to store the corresponding block, and send the corresponding block to the node storing the verification data block through the new node. Send the block received in this round by the new node to the target node that needs to perform block exchange through the new node, and send the response signatures of the previous round of nodes to all nodes; In response to the information of the new node, the node storing the verification data block performs an update operation on the stored verification data block of this round; Return a replacement block through the target node that needs to perform a block swap, and determine whether the broadcast message contains response signatures of the previous round of nodes. If it contains, perform signature and response. If not, do not respond; Perform cyclic re-encoding on historical blocks according to each encoding round of the blocks until all data is processed; Node exits, the upper limit of the tolerated number of malicious nodes When remaining unchanged, perform data re-encoding on the encoded block, specifically as follows: Send broadcast messages through the node to be exited, and send all blocks of each round to all other nodes; round; In response to the broadcast information of the node to be exited, send a response indicating that the block data has been received through all other nodes; In response to the responses of all other nodes, send a broadcast message through the node to be exited to notify the node storing the verification block to perform calculation processing on the original verification block; Based on the received block data, the node storing the verification block updates the original verification block locally and broadcasts the hash of the new verification block data.

8. A blockchain data reading method for the blockchain data storage method based on block aggregation encoding according to any one of claims 1-7, characterized in that, Including the following steps: According to the data reading characteristics of the encoded blocks, adopt an optimized reading process based on local node download, node download, and cross-region encoded group block download for block reading.

9. The blockchain data reading method of the blockchain data storage method based on block aggregation coding according to claim 8, characterized in that The data reading characteristics of the encoded blocks include three types: uncoded cache, local storage, or cross-node acquisition; The encoded blocks in the uncoded cache are read through local node download; The encoded blocks stored locally are read through cross-region node download; The encoded blocks that need to be cross-node acquired are read through cross-region encoded group block download.

10. The blockchain data reading method of the blockchain data storage method based on block aggregation coding according to claim 8, wherein The step of performing block reading through an optimized reading process according to the data reading characteristics of the encoded blocks is specifically: In response to a client's request for a block , verify whether the difference between the height of the current latest block and the height of the block is less than or equal to the remainder of the division of the current latest block index by . If so, it indicates that the block is an uncoded cached block, retrieve and return the block from the local cache; If the difference between the height of the current latest block and the height of block is greater than the remainder of the division of the current latest block index by , then block does not belong to the latest block group to be encoded. Determine the current encoding round using the height of block , and calculate the position of block in its encoding round; Nodes for calculating and locating actual storage blocks ; If the block is a local storage block located at the local node, retrieve and return the block from the node status database ; If the block is a block that needs to be obtained across nodes, then send a request to the target node storing the block and start a timer; If the target node does not respond before the timer expires, or due to network latency, the block fails to arrive in time, then broadcast a request to the entire network to seek other nodes to obtain the remaining blocks of the storage block in the encoding group.

Images