Data processing method based on blockchain network and related products

Abstract

The embodiment of the application provides a data processing method based on a blockchain network and related products, wherein the method comprises the following steps: obtaining a check block of a target block from a service node in a witness network when it is determined that the target block needs to be recovered based on the check block; the check block of the target block stored by the service node is obtained by the service node when the service node synchronizes related block data of the target block from a consensus node in a consensus network, and the check block is used for recovering the target block; determining a data recovery reference matrix based on an encoding matrix and the check block obtained from the service node in the witness network; and recovering the target block based on the data recovery reference matrix and the check block obtained from the service node in the witness network. Through the embodiment of the application, the block can be successfully recovered, and the availability of the recovered block can be effectively ensured.

Description

Technical Field

[0001] This application relates to the field of blockchain technology, and in particular to data processing methods, data processing devices, computer equipment, computer-readable storage media, and computer program products based on blockchain networks. Background Technology

[0002] With the advent of the technological era and the development of the mobile internet, the pace of network transformation is accelerating. The process of achieving information integration within the same or multiple fields and providing clients with comprehensive IT solutions faces new challenges, such as system architecture improvements and shifts in support focus. Therefore, blockchain technology, as a specific implementation of distributed ledgers, is gradually becoming the preferred method for storing and trading data across various fields due to its inherent advantages in data storage and management.

[0003] Blockchain is the foundation of blockchain technology. Essentially, it's a decentralized database, a chain of data blocks linked together using cryptographic methods. Each block contains information about a batch of network transactions, used to verify the validity of the information (anti-counterfeiting) and generate the next block. Blockchains are typically maintained by consensus nodes within the blockchain network. However, due to factors such as storage space (e.g., hard drive) failure, block data maintained by the consensus nodes may be lost. In such cases, the consensus nodes usually need to recover the block data to ensure the integrity of the maintained blockchain. How to achieve block data recovery is currently a hot research topic. Summary of the Invention

[0004] This application provides a data processing method and related products based on a blockchain network, which can successfully recover blocks and effectively guarantee the availability of the recovered blocks.

[0005] On one hand, embodiments of this application provide a data processing method based on a blockchain network, wherein the blockchain network includes a witness network and a consensus network, the witness network is composed of multiple business nodes networked together, the consensus network is composed of multiple consensus nodes networked together, and the witness network and the consensus network are connected by a communication link; the method includes:

[0006] When it is determined that the target block needs to be recovered based on the verification block of the target block, the verification block of the target block is obtained from the business nodes in the witness network; a data recovery reference matrix is ​​determined based on the encoding matrix and the verification block obtained from the business nodes in the witness network; the target block is recovered based on the data recovery reference matrix and the verification block obtained from the business nodes in the witness network; wherein, the target block is a block on the blockchain maintained by the consensus nodes in the consensus network; the verification block of the target block stored by the business node is obtained by the business node when synchronizing the relevant block data of the target block from the consensus nodes in the consensus network; the verification block is obtained by the consensus nodes in the consensus network encoding the target block using the encoding matrix; the verification block is used to recover the target block.

[0007] On one hand, this application provides another data processing method based on a blockchain network, wherein the blockchain network includes a witness network and a consensus network, the witness network is composed of multiple business nodes networked together, the consensus network is composed of multiple consensus nodes networked together, and the witness network and the consensus network are connected by a communication link; the method includes:

[0008] A block synchronization request is sent to the consensus nodes in the consensus network. The block synchronization request carries the synchronization block height and the node identifier of the target business node. The synchronization block height is the block height of the target block to be synchronized, and the target block is a block on the blockchain maintained by the consensus nodes in the consensus network. The block synchronization request is used to request the consensus nodes to return relevant data of the target block. The relevant data of the target block returned by the consensus nodes is received. The relevant data includes the block header of the target block, the transaction data of the target business node that it has access to, and the matching verification block that matches the node identifier among the K verification blocks corresponding to the target block. The K verification blocks are obtained by encoding the target block using an encoding matrix. K is a positive integer greater than 1. The relevant data of the target block is stored. The stored matching verification block is used by the consensus nodes in the consensus network to restore the target block.

[0009] On one hand, this application provides a data processing device applied in a blockchain network, the blockchain network including a witness network and a consensus network, the witness network being composed of multiple business nodes networked together, the consensus network being composed of multiple consensus nodes networked together, and the witness network and the consensus network establishing a communication connection; the device includes:

[0010] The processing unit is configured to obtain the verification block of the target block from the service node in the witness network through the transceiver unit when it is determined that the target block needs to be recovered based on the verification block of the target block.

[0011] The processing unit is also used to determine a data recovery reference matrix based on the encoding matrix and the verification blocks obtained from the service nodes in the witness network;

[0012] The processing unit is further configured to recover the target block based on the data recovery reference matrix and the verification block obtained from the service node in the witness network;

[0013] Wherein, the target block is a block on the blockchain maintained by the consensus nodes in the consensus network; the verification block of the target block stored by the business node is obtained by the business node when synchronizing the relevant block data of the target block from the consensus nodes in the consensus network; the verification block is obtained by the consensus nodes in the consensus network encoding the target block using the encoding matrix; the verification block is used to recover the target block.

[0014] On one hand, this application provides another data processing apparatus, which is applied in a blockchain network. The blockchain network includes a witness network and a consensus network. The witness network is composed of multiple business nodes, and the consensus network is composed of multiple consensus nodes. The witness network and the consensus network are connected by a communication link. The apparatus includes:

[0015] The processing unit is configured to send a block synchronization request to the consensus nodes in the consensus network via the transceiver unit; the block synchronization request carries the synchronization block height and the node identifier of the target business node; the synchronization block height is the block height of the target block to be synchronized, and the target block is a block on the blockchain maintained by the consensus nodes in the consensus network; the block synchronization request is used to request the consensus node to return relevant data of the target block;

[0016] The transceiver unit is further configured to receive relevant data of the target block returned by the consensus node; the relevant data includes the block header of the target block, transaction data of the target business node that has access permissions included in the target block, and matching verification blocks that match the node identifier among the K verification blocks corresponding to the target block; the K verification blocks are obtained by encoding the target block using an encoding matrix; K is a positive integer greater than 1;

[0017] A storage unit is used to store relevant data of the target block; wherein the stored matching and verification block is used by consensus nodes in the consensus network to recover the target block.

[0018] On one hand, this application provides a computer device including a processor, a communication interface, and a memory. The processor, the communication interface, and the memory are interconnected. The memory stores executable program code, and the processor is used to call the executable program code to implement the data processing method based on a blockchain network provided in this application.

[0019] Accordingly, this application also provides a computer-readable storage medium storing instructions that, when executed on a computer, cause the computer to implement the data processing method based on a blockchain network provided in this application.

[0020] Accordingly, this application also provides a computer program product, which includes a computer program or computer instructions. When the computer program or computer instructions are executed by a processor, they implement the data processing method based on a blockchain network provided in this application.

[0021] In this embodiment, the consensus node generates a check block for a block and synchronizes the check block along with the relevant block data to the business node when the business node synchronizes the block. When the consensus node needs to recover a block, it obtains the check block of the block to be recovered from the business node, and the block can be successfully recovered based on the obtained check block. Using this method, even when the consensus network is unavailable and block recovery cannot be completed based on the block data stored by the business node, the block can still be successfully recovered based on the check block stored by the business node, and the availability of the recovered block can be effectively guaranteed. Attached Figure Description

[0022] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0023] Figure 1a This is a schematic diagram of a blockchain structure provided in an embodiment of this application;

[0024] Figure 1b This is a schematic diagram of the architecture of a data sharing system provided in an embodiment of this application;

[0025] Figure 2a This is a schematic diagram of the architecture of a layered blockchain network provided in an embodiment of this application;

[0026] Figure 2b It shows Figure 2a The layered blockchain network shown demonstrates the isolation between transaction data from different business operations.

[0027] Figure 3a The present application illustrates the verification block distribution process according to an embodiment of this application;

[0028] Figure 3b The block recovery process involved in the embodiments of this application is illustrated;

[0029] Figure 4 The flowchart of the verification block generation and storage stage involved in the embodiments of this application is shown;

[0030] Figure 5 This application illustrates the method for generating verification blocks according to an embodiment.

[0031] Figure 6 The flowchart of the block data and verification block synchronization stage involved in the embodiments of this application is shown;

[0032] Figure 7 The flowchart of the block recovery phase involved in the embodiments of this application is shown;

[0033] Figure 8 This is a schematic diagram of a data recovery reference matrix provided in an embodiment of this application;

[0034] Figure 9 This is a schematic diagram of a data matrix provided in an embodiment of this application;

[0035] Figure 10 This is a schematic diagram of the structure of a data processing device provided in an embodiment of this application;

[0036] Figure 11 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Detailed Implementation

[0037] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0038] To better understand the embodiments of this application, some terms and blockchain technology involved in the embodiments of this application will be introduced below.

[0039] Consensus Nodes: Consensus nodes in a blockchain network are responsible for generating blocks. In addition to packaging and executing transactions, consensus nodes are also responsible for reaching consensus with other consensus nodes to update the chain state. Consensus nodes possess all the blockchain data.

[0040] Clearing: The upper-level node synchronizes transactions with the lower-level node according to the permissions of the lower-level node.

[0041] Business Nodes: Business nodes are lightweight nodes in a blockchain network. They are responsible for handling business requests and passing them through to consensus nodes. Business nodes synchronize all block headers and only synchronize transaction data that are visible to the node (i.e., have access to). Business nodes initiate synchronization requests to consensus nodes or their parent nodes, and the consensus nodes or parent nodes clear the block headers and transaction data visible to the business nodes to the business nodes.

[0042] Merkle Tree, Merkle Root: A Merkle tree is a typical binary tree structure consisting of a root node (the Merkle root), a set of intermediate nodes, and a set of leaf nodes. The leaf nodes at the bottom level store data or its hash value, while the other nodes store the hash values ​​of the contents of their two child nodes.

[0043] The Practical Byzantine Fault Tolerance (PBFT) consensus algorithm is a message-passing-based consensus algorithm that achieves consensus through three phases. When there are f Byzantine faulty nodes, if the total number of nodes is greater than or equal to 3f+1, all nodes can still reach eventual consensus (i.e., consensus can be achieved); conversely, if the total number of nodes is less than 3f+1, all nodes cannot reach eventual consensus (i.e., consensus cannot be achieved).

[0044] Erasure coding: Erasure coding technology mainly uses erasure coding algorithms to encode the original data to obtain redundancy, and stores the data and redundancy together to achieve fault tolerance. Its basic idea is to use certain calculations to obtain m redundant elements (check blocks) from n original data elements. For these n+m elements, if any m elements are corrupted (including both original and redundant data), the original n data blocks can be recovered using the corresponding reconstruction algorithm.

[0045] This application relates to blockchain technology. Blockchain is the foundation of blockchain technology, a novel application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanisms, and encryption algorithms. Essentially, a blockchain is a decentralized database, a chain of data blocks linked together using cryptographic methods. Each data block contains information about a batch of network transactions, used to verify the validity of the information (anti-counterfeiting) and generate the next block. A schematic diagram of a blockchain structure can be found [link to schematic diagram]. Figure 1a ,like Figure 1a As shown, Blockchain 101 consists of multiple blocks. The first block of the blockchain is called the genesis block (or simply the genesis block). The genesis block includes a block header and a block body. The block header stores the input information feature value, version number, timestamp, and difficulty value, while the block body stores the input information (including transaction data). The next block after the genesis block takes the genesis block as its parent block. The next block also includes a block header and a block body. The block header stores the input information feature value of the current block, the block header feature value of the parent block, the version number, the timestamp, and the difficulty value, and so on. This ensures that the block data stored in each block of the blockchain is related to the block data stored in the parent block, guaranteeing the security of the input information in the blocks.

[0046] A blockchain can be maintained by blockchain nodes contained within a blockchain network; wherein, a blockchain network can be understood as a data sharing system, referring to a system used for data sharing between blockchain nodes, an exemplary structure of which can be found here. Figure 1b ;like Figure 1b As shown, the data sharing system may include multiple blockchain nodes 102. Each blockchain node 102 can be a server connected to the blockchain network, or a terminal device (such as a client) connected to the blockchain network. The specific form of the blockchain node 102 is not limited here. Each blockchain node 102 in the blockchain network has a corresponding node identifier, and each blockchain node 102 can store the node identifiers of other blockchain nodes 102 in the blockchain network, so that the generated blocks can be broadcast to other blockchain nodes 102 in the data sharing system based on the node identifiers of other blockchain nodes 102. Each blockchain node 102 can maintain a node identifier list, storing the node name and node identifier in the node identifier list; the node identifier list can be found in Table 1.

[0047] Table 1

[0048] Node 1 117.114.151.174 Node 2 117.116.189.145 … … Node X (X is a positive integer) xx.xxx.xxx.xxx

[0049] As shown in Table 1, the node identifier can be an IP (Internet Protocol) address or any other information that can be used to identify the node; for example, the node identifier can also be a binary sequence code (such as 110001110). Table 1 only uses IP addresses as an example. When a block to be verified is generated in the blockchain network, the blockchain nodes running the consensus mechanism (or consensus nodes) reach a consensus on the block to be verified. After successful consensus, the block to be verified is synchronized to all blockchain nodes in the blockchain network through the node identifier in the node identifier list, realizing distributed storage of data in the blockchain network.

[0050] Figure 1b The blockchain network shown is a single-layer blockchain network, meaning that nodes are peer-to-peer and exist within the same network. However, when blockchain networks are used in applications such as those of government or commercial organizations, not all participating nodes have sufficient resources and the necessity to become nodes involved in blockchain consensus. Furthermore, for data security reasons, the common peer-to-peer blockchain deployment method is not suitable when confidential data is involved in the blockchain system. Therefore, a single-layer (i.e., peer-to-peer) blockchain network is not suitable for the aforementioned application scenarios.

[0051] To address the aforementioned issues, embodiments of this application provide a layered blockchain network, such as... Figure 2a As shown, the blockchain network is divided into two layers: a witness network and a consensus network. The witness network consists of multiple business nodes, and the consensus network consists of multiple consensus nodes. A communication connection is established between the witness network and the consensus network. In the witness network, business nodes are lightweight nodes, while consensus nodes in the consensus network are full-scale nodes. Consensus nodes participate in block production and consensus within the consensus network, and each consensus node possesses all the blockchain data, or stores the block data of all blocks on the blockchain. Business nodes execute business logic in the witness network, submit business operations to the consensus network, and synchronize block data from consensus nodes (synchronizing all block headers, and only synchronizing transaction data visible (or accessible) to that node). The witness network and the consensus network operate in different network environments. The witness network is typically in a public network, where business nodes can join or leave relatively freely; while the consensus network is usually deployed in a relatively secure and closed private network, where the joining or leaving of consensus nodes requires consensus from the consensus committee (or all consensus nodes in the consensus network).

[0052] Figure 2a The layered blockchain network shown is a system of consensus nodes + business nodes, which can achieve isolation between transaction data of different businesses, such as... Figure 2bAs shown; in addition to storing all transaction data within the consensus network, consensus nodes also distribute business-related transaction data to business nodes according to their permissions. This layered blockchain design meets industry requirements for transaction confidentiality and also enhances the availability of blockchain data to a certain extent. Even if the consensus network data is untrustworthy or unavailable, the historical transaction data stored on the business nodes can still be queried.

[0053] By dividing a blockchain network into a witness network and a consensus network, the nodes in the blockchain network can be distinguished according to their functions (divided into consensus nodes and business nodes). On the one hand, this enables a layered blockchain network, and only a portion of the nodes in the blockchain network need to serve as consensus nodes, which helps improve consensus efficiency. On the other hand, it allows nodes in different networks to store different data, enabling a data-asymmetric blockchain deployment, which improves data security and confidentiality. Based on these advantages, layered blockchain networks can be applied to application scenarios where single-layer blockchain networks are not suitable.

[0054] for Figure 2a In the layered blockchain network shown, when consensus node A (any consensus node in the consensus network) loses block data (such as transaction data) of block B (any block on the blockchain) due to factors such as storage space (such as hard drive) failure, and needs to recover block B, or when node C joins the consensus network as a consensus node and needs to synchronize all block data (the following explanation uses the synchronization of block B as an example, and the other blocks are similar), if the consensus nodes in the consensus network can reach a consensus at this time, then consensus node A or consensus node C can directly synchronize block B that can pass the consensus from other consensus nodes in the consensus network.

[0055] In a consensus network with 3f+1 consensus nodes, where f is a positive integer greater than or equal to 1, taking f=1 as an example, if two or more consensus nodes are unable to participate in (or complete) consensus due to reasons such as data loss or disconnection, the proportion of nodes capable of participating in consensus cannot exceed a set proportion (e.g., 1 / 2), leading to a failure to reach a consensus, and the consensus network becomes unusable. If the consensus nodes in the consensus network cannot reach a consensus, the correctness (or availability) of block B stored by other consensus nodes cannot be determined, and block B cannot be directly synchronized from other consensus nodes. Since the business nodes in the witness network may store block data of block B, consensus node A or consensus node C can then attempt to obtain all block data of block B from the business nodes in the witness network. If all block data of block B can be obtained from the business nodes in the witness network, block B can be directly restored based on the obtained block data. However, if factors such as the business nodes in the witness network failing to synchronize all block data of block B (for example, the transaction data in block B is not visible to all business nodes, so the business nodes can only synchronize the block header of block B), or the business nodes that originally synchronized block data of block B leaving the blockchain network, resulting in the other business nodes failing to include all block data of block B, cause consensus node A or consensus node C to be unable to obtain all block data of block B from the business nodes in the witness network, then consensus node A or consensus node C will not be able to obtain block B.

[0056] Based on this, this application provides a block recovery scheme that can successfully recover blocks even when the consensus network is unavailable (i.e., the consensus nodes in the consensus network cannot reach a consensus) and the block recovery cannot be completed based on the block data stored by the business nodes in the witness network, and can effectively guarantee the availability (or accuracy) of the recovered blocks.

[0057] The block recovery scheme provided in this application mainly includes, as follows: Figure 3a The check block distribution process shown and as follows Figure 3b The diagram illustrates the process of recovering a block using verification blocks. Consensus nodes generate verification blocks for each block on the blockchain. When business nodes synchronize block data normally from the consensus node, in addition to synchronizing the relevant transaction data and block header for a given block, they also need to synchronize the verification block for that block. When a consensus node needs to recover a block using verification blocks, it requests verification blocks from the business nodes. After collecting a sufficient number of verification blocks, it can successfully recover the block data based on the obtained verification blocks.

[0058] Using the example of recovering block B above, the block recovery scheme provided in this application embodiment is illustrated below. The main processing flow is as follows: After each consensus node in the consensus network puts block B on the chain, it encodes block B using an encoding matrix to obtain K verification blocks of block B, where K is a positive integer greater than 1. These K verification blocks are used to recover block B. Then, all or part of the K verification blocks are stored. When a block synchronization request for block B is received from a business node in the witness network, the block header of block B and the transaction data that the business node has access to in block B are obtained. The matching verification block that matches the node identifier of the business node among the K verification blocks of block B is also obtained. Then, the block header of block B, the transaction data that the business node has access to in block B, and the matching verification block are sent to the business node, and the business node stores the received data. When consensus node A needs to recover block B or consensus node C needs to synchronize block B, and the consensus network is unavailable, and the block data stored by the business nodes in the witness network cannot complete the recovery of block B, consensus node A or consensus node C can obtain the various verification blocks of block B from the business nodes in the witness network. Then, based on the encoding matrix and the various verification blocks of block B obtained from the business nodes in the witness network, a data recovery reference matrix is ​​determined. Finally, based on the data recovery reference matrix and the obtained verification blocks of block B, block B can be successfully recovered.

[0059] The above provides a brief overview of the block recovery scheme provided in the embodiments of this application. The following section provides a detailed description of the block recovery scheme (i.e., the data processing method described below).

[0060] The data processing method provided in this application embodiment is based on Figure 2a The layered blockchain network implementation shown includes three stages: the verification block generation and storage stage, the block data and verification block synchronization stage, and the block recovery stage. The processing flow of each stage is explained in detail below.

[0061] The first phase, checksum generation and storage, is executed by the target consensus node (which can be any consensus node in the consensus network). Please refer to [link to relevant documentation]. Figure 4 , Figure 4 The illustration shows the processing flow of the verification block generation and storage stage included in the data processing method provided in the embodiments of this application. The verification block generation and storage stage includes, but is not limited to, the following steps:

[0062] S401. Serialize the first block and split the serialization result into N data blocks.

[0063] In this embodiment, the first block is any block on the blockchain (i.e., the blockchain maintained by consensus nodes in the consensus network), and N is a positive integer greater than 1. Serialization processing refers to decomposing data into a byte stream. After the first block is serialized, the byte stream obtained from the serialization process is split into D1, D2, ..., D... N There are a total of N data blocks. The serialized byte stream can be split into N data blocks according to equal data volume, or it can be split according to unequal data volume. This application embodiment does not limit the splitting method.

[0064] It should be noted that data block D i The subscript (i being any number from 1 to N) can represent the order of the corresponding data block in the serialization result. For example, the data block identified as D1 is the first data block in the serialization result; of course, data block D... i The index can also be independent of the order of the corresponding data blocks in the serialization result. For example, the data block identified as D3 is the first data block in the serialization result.

[0065] S402. Combine the N data blocks obtained from the splitting into an N*1 data block matrix. The data block matrix is ​​as follows: Figure 5 As shown in 504.

[0066] S403. Encode the data block matrix using the encoding matrix to obtain the encoding result; the encoding result includes K parity blocks and N data blocks obtained by splitting; K is a positive integer greater than 1.

[0067] In this embodiment, the encoding matrix can be constructed based on the Vandermonde matrix, and any W*H submatrix of the encoding matrix is ​​invertible. The encoding matrix can be formed by concatenating an N*N identity matrix and a K*N encoding parameter matrix. The form of the encoding matrix can be as follows: Figure 5 As shown in 501, this includes the N*N identity matrix shown in 502, and the K*N encoding parameter matrix shown in 503, and the M... 11 M 12 M KN The specific values ​​of the total K*N encoding parameters are defined by the target consensus node itself, as long as the defined values ​​ensure that any W*H submatrix of the encoding matrix is ​​invertible. Here, W is a positive integer greater than or equal to 1 and less than or equal to K+N, H is a positive integer greater than or equal to 1 and less than or equal to N, and W and H can be equal or unequal; K can be equal to N or unequal to N.

[0068] In one embodiment, encoding the data block matrix using an encoding matrix can be achieved by matrix multiplication of the encoding matrix and the data block matrix. For example... Figure 5 As shown, after multiplying the encoding matrix 501 and the data block matrix 504, the encoding result shown in 505 is obtained. This encoding result is an (N+K)*1 matrix, where the first N elements are the N data blocks D1, D2, ..., D of the first block. N The last K elements of the matrix are the check blocks C1, C2, ..., C3 generated for these N data blocks. K Each check block C i (i is any one of 1-k) are all generated based on a row element of the above encoding parameter matrix and the N data blocks. For example, the parity block C1 is based on the first row element (M) of the encoding parameter matrix. 11 M 12 M 1N ) and data block matrices (D1, D2, ..., D N This is obtained by comparing the parity block C1 with the first row element (M) of the encoding parameter matrix. 11 M 12 M 1N There is a corresponding relationship. The other cases are similar and will not be elaborated here.

[0069] S404. Store all or part of the K parity blocks.

[0070] In this embodiment, the target consensus node can store all K verification blocks of the first block. However, when K is large (e.g., 100000), storing all K verification blocks of the first block requires a large amount of storage space. Furthermore, each consensus node in the consensus network generates K verification blocks for the first block using the above method. If each consensus node stores all K verification blocks of the first block, it will cause data redundancy. To save storage space and reduce data redundancy, the K verification blocks of the first block can be distributed and stored across multiple consensus nodes in the consensus network. In this case, the target consensus node only needs to store a portion of the K verification blocks of the first block.

[0071] In one implementation, if the consensus network consists of G (G is a positive integer greater than 1) consensus nodes, then G can be used as the value of K, i.e., K is equal to G. The target consensus node can determine from the K check blocks of the first block the check block whose permutation identifier matches the target consensus node's permutation identifier in the consensus network, and only stores this matching check block. For example, check block C... iThe subscript of the check block is its permutation identifier, used to indicate the order of the check block among the K check blocks. Consensus nodes in the consensus network also have permutation identifiers to indicate their permutation order. Assuming the permutation identifier of the target consensus node indicates that its permutation order in the consensus network is 2, then the target consensus node can use check block C2 as the matching check block and only store check block C2. Using this method, each consensus node in the consensus network stores one check block from the K check blocks of the first block, and different consensus nodes store different check blocks for the first block.

[0072] In one embodiment, K is equal to G, and N is also equal to G, that is, K, N, and G are all equal. In addition, W is also equal to H.

[0073] It should be noted that steps S401-S404 can be executed by the target consensus node after it puts the first block on the chain (or stores it on the blockchain).

[0074] In one embodiment, after determining the K check blocks of the first block, a hash calculation can be performed on each of the K check blocks to obtain K hash values. Then, a Merkle tree is constructed based on the calculated K hash values, and the root of the constructed Merkle tree (Merkle root) is added to the block header of the second block. The second block is the next block on the blockchain after the first block, i.e., a block whose height is 1 greater than the first block. It should be noted that the Merkle root can be added to the block header of the second block after obtaining the second block but before putting the second block on the chain. In this case, the above steps can be performed by the target consensus node. Alternatively, the Merkle root can be added to the block header of the second block during the generation of the second block. In this case, the Merkle root can also participate in the calculation of the hash value of the second block header. In this case, the above steps are performed by the block-producing node of the second block (which can be the target consensus node or other consensus nodes in the consensus network).

[0075] It should be noted that each consensus node in the consensus network executes steps S401-S404 for each block on the blockchain to generate and store the verification block for each block. For the specific implementation details, please refer to the description above; they will not be repeated here. Furthermore, different consensus nodes use the same encoding matrix for the same block; however, the encoding matrix used for different blocks can be the same or different.

[0076] II. The block data and verification block synchronization phase is jointly executed by the target business node in the witness network (which can be any business node in the witness network) and the target consensus node in the consensus network. Please refer to [link / reference]. Figure 6 , Figure 6 The illustration shows the processing flow of the block data and check block synchronization stage included in the data processing method provided in this application embodiment. The block data and check block synchronization stage includes, but is not limited to, the following steps:

[0077] S601. The target service node sends a block synchronization request to the target consensus node in the consensus network. The block synchronization request carries the synchronization block height and the node identifier of the target service node.

[0078] In this embodiment, the target consensus node can be any consensus node in the consensus network, or it can be the consensus node in the consensus network that is closest to the target business node. "Closest" can refer to the shortest distance or the shortest communication time. The target consensus node can also be a consensus node in the consensus network that the target business node has access to. The synchronization block height is the block height of the target block that needs to be synchronized. The target block is a block on the blockchain maintained by the consensus node in the consensus network. The block synchronization request is used to request the target consensus node to return relevant data for the target block.

[0079] S602. The target consensus node responds to the block synchronization request and determines a matching block on the blockchain that matches the height of the synchronization block.

[0080] In this embodiment, the target consensus node can query the blockchain for blocks with a block height equal to the synchronization block height, and identify these blocks as matching blocks. These matching blocks are the target blocks that the aforementioned target business node needs to synchronize.

[0081] S603, The target consensus node obtains the block header of the matching block and the transaction data that the target business node has access to in the matching block.

[0082] In this embodiment of the application, the target consensus node obtains the block header of the matching block and detects whether there is any transaction data in the transaction data included in the block body of the matching block that the target business node has access to. If it does, the target business node obtains the transaction data that it has access to from the block body of the matching block; otherwise, if it does not, the transaction data is not obtained.

[0083] S604. The target consensus node obtains the matching verification block that matches the node identifier of the target business node from among the K verification blocks corresponding to the matching block.

[0084] In this embodiment, the K verification blocks corresponding to the matching block are generated and stored in the consensus nodes of the consensus network during the aforementioned verification block generation and storage phase. The target consensus node can determine a value V based on the node identifier of the target service node, and then generate the K verification blocks C1, C2, ..., C1 corresponding to the matching block.K The check block whose index value is the same as the value V is determined to be the matching check block. If the target consensus node itself stores the matching check block, it directly retrieves the matching check block from its own storage space; otherwise, if the target consensus node itself does not store the matching check block, it retrieves the matching check block from other consensus nodes in the consensus network.

[0085] In one embodiment, the numerical value V is calculated as shown in the following formula:

[0086] V = Hash(id) mod K

[0087] Where id represents the node identifier of the target business node, Hash represents hash operation, and mod represents modulo operation; the above formula means that the value V is obtained by dividing the hash value of the node identifier id by the value K and taking the remainder.

[0088] Using the above method, when different business nodes in the witness network synchronize block data of the target block (i.e., the matching block), the different check blocks of the target block can be identified. This allows the K check blocks (all or part) of the target block to be distributed and stored across multiple business nodes in the witness network. This ensures that when the target block needs to be recovered based on the check blocks later, a sufficient number of check blocks of the target block can be obtained from the business nodes of the witness network, thereby guaranteeing a high success rate for target block recovery.

[0089] S605, the target consensus node sends the block header of the matching block, the transaction data that the target business node has access to in the matching block, and the matching verification block to the target business node.

[0090] S606. The target business node stores the block header of the matching block (i.e., the target block), the transaction data that the target business node has access to, and the matching verification block included in the matching block.

[0091] In one embodiment, before storing the matching verification block, the block header of a reference block synchronized from consensus nodes in the consensus network is obtained. The reference block is the next block on the blockchain after the target block (i.e., the matching block), meaning the block height is one greater than the target block. The block header of the reference block includes the root of a Merkle tree constructed based on the K verification blocks corresponding to the target block. The method of adding this root to the block header of the reference block can be referred to the relevant description above, and will not be repeated here. Then, it is checked whether the matching verification block matches the root of the Merkle tree included in the reference block. If they match, the matching verification block is stored, which ensures the accuracy of the stored verification block. The stored matching verification block is used by consensus nodes in the consensus network to recover the target block.

[0092] In one implementation, the target consensus node can also obtain the Merkle path of the matching check block, i.e., the path from the root node to the node corresponding to the matching check block in the Merkle tree constructed based on the K check blocks corresponding to the target block; and send the Merkle path of the matching check block to the target service node. At this time, the target service node can check whether the matching check block and its Merkle path match the root of the Merkle tree included in the reference block. If they match, the node stores the matching check block and its Merkle path.

[0093] Additionally, it's important to note that multiple (or even every) business nodes in the witness network synchronize relevant data for each block on the blockchain using the aforementioned method. If a business node lacks access to the transaction data in a block, it only synchronizes the block header and the K checksums of that block that match the business node's identifier. Conversely, if a business node has access to the transaction data in a block, it synchronizes the block header, the accessed transaction data, and the K checksums of that block that match the business node's identifier. Based on this, the block data (all or part) and the K checksums of each block on the blockchain can be distributed and stored across multiple business nodes in the witness network. This effectively ensures that a sufficient number of usable checksums can be obtained from the business nodes of the witness network when block recovery is subsequently required, thus guaranteeing a high success rate for block recovery.

[0094] III. The block recovery phase is jointly executed by the target consensus node in the consensus network and the business nodes in the witness network. The target consensus node can be a consensus node in the consensus network that has lost block data due to factors such as storage space (e.g., hard drive) failure and needs to recover the blocks; or it can be a newly joined consensus node that needs to synchronize all block data. Please refer to [link to relevant documentation]. Figure 7 , Figure 7 The illustration shows the processing flow of the block recovery stage included in the data processing method provided in this application embodiment. The block recovery stage includes, but is not limited to, the following steps:

[0095] S701. When it is determined that the target block needs to be recovered based on the verification block of the target block, the verification block of the target block is obtained from the service node in the witness network.

[0096] In this embodiment, the target block is the block that needs to be recovered, which can be any block on the blockchain. If it is detected that the target consensus node needs to recover the target block, and the proportion of abnormal consensus nodes in the consensus network exceeds a set proportion, and the business nodes in the witness network have not stored all the block data of the target block, then it is determined that the target block needs to be recovered based on the verification block of the target block. Abnormal consensus nodes refer to consensus nodes that cannot participate in (or complete) consensus due to reasons such as data loss or disconnection. The set proportion can be, for example, 1 / 2 or 1 / 3, etc., and the value of the set proportion can be determined according to the consensus rules. When the proportion of consensus nodes that cannot participate in consensus exceeds the set proportion, it indicates that the consensus nodes in the consensus network cannot reach a consensus, and the consensus network is in an unavailable state. At this time, the correctness (or availability) of the target block stored by other consensus nodes cannot be determined, and the target block cannot be directly synchronized from other consensus nodes. Meanwhile, if all the block data of the target block cannot be obtained from the business nodes in the witness network, then the only way to recover the target block is to use the verification block of the target block.

[0097] When it is determined that the target block needs to be recovered based on its checksum, the target consensus node obtains the checksum from the service nodes in the witness network. Specifically, the target consensus node broadcasts a checksum retrieval request to the service nodes in the witness network, which may include the block height of the target block. Upon receiving the request, the service nodes in the witness network check if they have the checksum stored. If they do, they send the stored checksum to the target consensus node.

[0098] In one implementation, the verification block retrieval request, in addition to indicating the need to retrieve the verification block of the target block, also indicates the need to retrieve the block header of the reference block. The reference block is the next block on the blockchain after the target block, i.e., a block whose height is one greater than the target block; the block header of the reference block includes the root of a Merkle tree constructed based on the K verification blocks corresponding to the target block. After obtaining the verification block of the target block and the block header of the reference block from the business nodes in the witness network, the target consensus node checks whether the verification block matches the root of the Merkle tree included in the block header of the reference block. If they match, the verification block is determined to be valid and can be used to recover the target block; otherwise, if they do not match, the verification block is discarded. This improves the correctness of the recovered target block and avoids useless repetitive operations, thus improving the recovery efficiency of the target block.

[0099] In another implementation, the verification block retrieval request, in addition to indicating the need to retrieve the verification block of the target block and the block header of the reference block, also indicates the need to retrieve the Merkle path of the verification block of the target block. This Merkle path is the path from the root node to the node corresponding to the verification block in the Merkle tree constructed based on the K verification blocks corresponding to the target block. It is obtained by the business node when synchronizing the block data of the target block from the consensus node. After obtaining the verification block of the target block, the Merkle path of the verification block, and the block header of the reference block from the business node in the witness network, the target consensus node checks whether the verification block and its Merkle path match the root of the Merkle tree included in the block header of the reference block. If they match, the verification block is determined to be valid and can be used to recover the target block; otherwise, if they do not match, the verification block is discarded.

[0100] S702. Determine the data recovery reference matrix based on the encoding matrix and the verification blocks obtained from the service nodes in the witness network.

[0101] In this embodiment, the data recovery reference matrix is ​​determined based on the encoding matrix and the valid verification blocks obtained from the service nodes in the witness network.

[0102] Method 1: When all K check blocks of the target block are obtained from the business node in the witness network, and all K check blocks are valid, the matrix elements corresponding to the K check blocks are obtained from the encoding matrix corresponding to the target block, and the data recovery reference matrix is ​​determined based on the obtained matrix elements corresponding to the K check blocks.

[0103] As mentioned earlier, each of the K check blocks C i (where i is any one of 1-K) are all generated based on a row of elements in the encoding parameter matrix included in the encoding matrix and N data blocks of the target block, such as Figure 5 As shown, for example, the check block C1 is based on the first row element (M) of the encoding parameter matrix. 11 M 12 M 1N ) and data block matrices (D1, D2, ..., D N This is obtained by comparing the parity block C1 with the first row element (M) of the encoding parameter matrix. 11 M 12 M 1N There is a correspondence. That is to say, the matrix elements in the encoding matrix that correspond to the K parity blocks are elements in the encoding parameter matrix included in the encoding matrix, and the encoding parameter matrix (such as...) can be directly used to... Figure 5 503 in the matrix is ​​identified as the data recovery reference matrix.

[0104] Here, the encoding parameter matrix is ​​a submatrix of the encoding matrix, thus determining a reversible data recovery reference matrix. In one embodiment, K and N are equal, in which case the determined data recovery reference matrix is ​​a K*K (or N*N) submatrix of the encoding matrix, effectively ensuring the reversibility of the data recovery reference matrix. In other feasible embodiments, K and N can be equal to M (the number of consensus nodes in the consensus network).

[0105] Method 2: When only X (X < K) valid check blocks out of the K check blocks of the target block are obtained from the business nodes in the witness network, the target block is obtained from other consensus nodes in the consensus network (any consensus node that stores the complete target block). Since the consensus nodes in the consensus network cannot reach a consensus at this time, the correctness (or availability) of the target block stored by other consensus nodes cannot be determined, so the target block obtained from other consensus nodes cannot be used directly. After obtaining the target block stored by other consensus nodes, the obtained target block is serialized, and the serialization result is split into N data blocks (the splitting method needs to be consistent with the splitting method of the target block in the check block generation and storage stage); KX data blocks are randomly selected from the N split data blocks, and then the matrix elements corresponding to the X check blocks and the KX data blocks are obtained from the encoding matrix corresponding to the target block, and the data recovery reference matrix is ​​determined based on the obtained matrix elements corresponding to the X check blocks and the KX data blocks.

[0106] In one embodiment, it can be based on the verification block C i (i is any one of 1-K) and the row elements of the encoding parameter matrix included in the encoding matrix, obtain the row elements corresponding to the X parity blocks in the encoding parameter matrix; based on the KX data blocks in the data block matrix composed of N data blocks (i.e., the data block matrix composed of N data blocks for the target block in the parity block generation and storage stage, such as...) Figure 5 The 504 in the code refers to the row position in an N*1 data block matrix composed of N data blocks during the check block stage of determining the target block. This allows us to obtain the N*N identity matrix (e.g., ...) included in the encoding matrix. Figure 5 The corresponding row elements in 502) are used; then the data recovery reference matrix is ​​determined based on the row elements corresponding to the X check blocks in the obtained encoding parameter matrix and the row elements corresponding to the KX data blocks in the N*N identity matrix.

[0107] For example, suppose X is K-3, and these X check blocks are the first X check blocks C1, C2, ..., C3 out of the K check blocks of the target block. X At this point, KX is 3. Assume the three randomly selected data blocks are D2, D...N-1 and D N The determined data recovery reference matrix is ​​as follows: Figure 8 As shown in 801, the data recovery reference matrix 801 includes two parts: 802 and 803. 802 is composed of... Figure 5 Data blocks D2 and D in the identity matrix shown in Figure 502 N-1 and D N The corresponding second, (N-1), and Nth row elements constitute 803. Figure 5 The coding parameter matrix shown in Figure 503 contains data block check blocks C1, C2, ..., C1. X The elements in the first to the Xth rows are composed of the corresponding elements.

[0108] The data recovery reference matrix determined using the above method is a submatrix of the encoding matrix, therefore it is an invertible matrix. In one embodiment, K and N are equal, in which case the determined data recovery reference matrix is ​​a K*K (or N*N) submatrix of the encoding matrix, effectively ensuring the invertibility of the data recovery reference matrix. In other feasible embodiments, K and N can be equal to G (the number of consensus nodes in the consensus network).

[0109] S703. The target block is recovered based on the data recovery reference matrix and the verification block obtained from the business nodes in the witness network.

[0110] In this embodiment of the application, the target block is recovered based on the data recovery reference matrix and the valid verification blocks obtained from the service nodes in the witness network.

[0111] Corresponding to the two implementation methods for determining the data recovery reference matrix mentioned above, step S702 also has two implementation methods:

[0112] Method 1: After determining the data recovery reference matrix using the above method 1, determine the inverse matrix of the data recovery reference matrix, and then recover the target block based on the inverse matrix of the data recovery reference matrix and the K verification blocks of the obtained target block.

[0113] In one implementation, the K parity blocks of the acquired target block are arranged into a K*1 data matrix (e.g., Figure 9 As shown in Figure 901, the data block matrix (D1, D2, ..., D3) is obtained by multiplying the inverse matrix of the data recovery reference matrix with the check block matrix. N Then, based on the data block matrix (D1, D2, ..., D...), N This will allow you to recover the complete target block.

[0114] Method 2: After determining the data recovery reference matrix using Method 2, determine the inverse matrix of the data recovery reference matrix, and then recover the target block based on the inverse matrix of the data recovery reference matrix, the X check blocks of the target block obtained, and the KX data blocks of the target block obtained randomly.

[0115] In one embodiment, the KX data blocks of the randomly obtained target block and the X check blocks of the obtained target block are arranged into a K*1 data matrix (e.g., Figure 9 As shown in Figure 902 (corresponding to the example determined in Method 2 above), the inverse matrix of the data recovery reference matrix is ​​multiplied by the check block matrix to obtain the data block matrix (D1, D2, ..., D) consisting of N data blocks of the target block. N Then, based on the data block matrix (D1, D2, ..., D...), N This will allow you to recover the complete target block.

[0116] In one implementation, to ensure the accuracy of the recovered target block, it can be checked whether the target block recovered based on the inverse matrix of the data recovery reference matrix, X check blocks, and KX data blocks is consistent with the target block obtained from the consensus nodes in the consensus network. If they are consistent, the target block recovery is considered successful. Conversely, if they are inconsistent, it indicates that the target block obtained from other consensus nodes is incorrect, and the recovered target block is also incorrect (or even impossible to recover at all). In this case, the target block stored by other consensus nodes (different from the previous ones) can be obtained again, and the target block can be recovered using the above method until the recovered target block is consistent with the target block obtained from the consensus nodes. In other feasible implementations, the target blocks stored by multiple consensus nodes can be obtained each time, and the block with the largest proportion among the obtained target blocks can be processed. For example, if the target blocks stored by 5 consensus nodes are obtained, and four of them are the same while the other block is different, the same block is processed. This can ensure the accuracy of the obtained target blocks to a certain extent, thereby ensuring the success of the target block recovery.

[0117] The above recovery principle is shown in the following formula:

[0118] P′=P*L′

[0119] P′*L′ (-1) =P*L′*L′ (-1) =P*(L′*L′) (-1) ) = P

[0120] Where P represents the data block matrix consisting of N data blocks of the block; P′ represents the data matrix formed by arranging the K parity blocks obtained in method 1 above, or the data matrix formed by arranging the KX randomly obtained data blocks and the X parity blocks obtained in method 2 above; L represents the data recovery reference matrix determined above, L′ (-1) Let L' be the inverse matrix of L, and L'*L' be the inverse matrix of L. (-1) It is the identity matrix. P′=P*L′, such as using Figure 8 The data recovery reference matrix shown is multiplied by, as Figure 5 The data block matrix consisting of N data blocks shown in Figure 504 can be used to obtain the following... Figure 9 The data matrix shown in Figure 902 is formed by arranging KX randomly obtained data blocks and X obtained check blocks.

[0121] Using the above method, the target consensus node can recover all its missing blocks. When the target consensus node is a newly joined consensus node, it can also complete the synchronization of all blocks on the blockchain.

[0122] Based on a layered blockchain network, this application provides a solution for ensuring the availability of blockchain data based on erasure coding. This solution can ensure that confidential transactions on the blockchain are not exposed to any nodes other than the consensus nodes (business nodes can only synchronize transactions they can see). It can also successfully recover blocks based on the verification blocks stored by business nodes when the consensus network is unavailable and the blocks cannot be recovered based on the block data stored by the business nodes. Furthermore, it can effectively guarantee the availability of the recovered blocks.

[0123] It should be noted that the execution entity used to perform the steps in the above method embodiments can be hardware, software, or a combination of both. Furthermore, in the specific embodiments of this application, data related to blockchain, blocks, block headers, block bodies, and transaction data are involved, and all data used is authorized by the user. When the above embodiments of this application are applied to specific products or technologies, the data used must obtain user permission or consent, and the collection, use, and processing of related data must comply with the relevant laws, regulations, and standards of the relevant countries and regions.

[0124] Please see Figure 10 , Figure 10This is a schematic diagram of a data processing device provided in an embodiment of this application. The device described in this embodiment includes a processing unit 1001, a transceiver unit 1002, and a storage unit 1003. This data processing device is applied in a blockchain network, which includes a witness network and a consensus network. The witness network is composed of multiple business nodes, and the consensus network is composed of multiple consensus nodes. The witness network and the consensus network are connected by a communication link.

[0125] In a feasible embodiment, the data processing device may be a target consensus node corresponding to the consensus network described above, wherein:

[0126] The processing unit 1001 is used to obtain the verification block of the target block from the service node in the witness network through the transceiver unit 1002 when it is determined that the target block needs to be recovered based on the verification block of the target block.

[0127] The processing unit 1001 is further configured to determine a data recovery reference matrix based on the encoding matrix and the verification blocks obtained from the service nodes in the witness network;

[0128] The processing unit 1001 is further configured to recover the target block based on the data recovery reference matrix and the verification block obtained from the service node in the witness network;

[0129] Wherein, the target block is a block on the blockchain maintained by the consensus nodes in the consensus network; the verification block of the target block stored by the business node is obtained by the business node when synchronizing the relevant block data of the target block from the consensus nodes in the consensus network; the verification block is obtained by the consensus nodes in the consensus network encoding the target block using the encoding matrix; the verification block is used to recover the target block.

[0130] In one embodiment, the processing unit 1001 is further configured to determine that the target block needs to be restored based on the verification block of the target block if it is detected that the target block needs to be restored, and the proportion of abnormal consensus nodes in the consensus network exceeds a set proportion, and the service nodes in the witness network have not stored all the block data of the target block.

[0131] In one embodiment, the target block has K check blocks, where K is a positive integer greater than 1; the processing unit 1001 determines a data recovery reference matrix based on the encoding matrix and the check blocks obtained from the service nodes in the witness network, and when recovering the target block based on the data recovery reference matrix and the check blocks obtained from the service nodes in the witness network, it is specifically used for:

[0132] When K verification blocks of the target block are obtained from the service nodes in the witness network, the matrix elements corresponding to the K verification blocks are obtained from the encoding matrix; a data recovery reference matrix is ​​determined based on the obtained matrix elements corresponding to the K verification blocks, and the inverse matrix of the data recovery reference matrix is ​​determined; the target block is recovered based on the inverse matrix of the data recovery reference matrix and the K verification blocks.

[0133] When X verification blocks of the target block are obtained from the service nodes in the witness network, the target block is obtained from the consensus nodes in the consensus network; X is a positive integer less than K; the obtained target block is serialized, and the serialization result is split into N data blocks; N is a positive integer greater than 1; KX data blocks are obtained from the N split data blocks; the matrix elements corresponding to the X verification blocks and the KX data blocks are obtained from the encoding matrix, and a data recovery reference matrix is ​​determined based on the obtained matrix elements corresponding to the X verification blocks and the KX data blocks; the inverse matrix of the data recovery reference matrix is ​​determined, and the target block is recovered based on the inverse matrix of the data recovery reference matrix, the X verification blocks, and the KX data blocks.

[0134] In one embodiment, the processing unit 1001 is further configured to: detect whether the target block recovered based on the inverse matrix of the data recovery reference matrix, the X check blocks, and the KX data blocks is consistent with the target block obtained from the consensus node in the consensus network; if consistent, then determine that the target block recovery is successful.

[0135] In one embodiment, the target block has K check blocks, where K is a positive integer greater than 1. The processing unit 1001 is further configured to: obtain the block header of a reference block from a service node in the witness network through the transceiver unit 1002; the reference block is the next block on the blockchain after the target block, and the block header of the reference block includes the root of a Merkle tree constructed based on the K check blocks corresponding to the target block; discard check blocks in the obtained target block that do not match the root of the Merkle tree included in the block header of the reference block. That is to say: the subsequent process is to determine a data recovery reference matrix based on the encoding matrix and the obtained check blocks that match the root of the Merkle tree included in the block header of the reference block, and to recover the target block based on the data recovery reference matrix and the obtained check blocks that match the root of the Merkle tree included in the block header of the reference block.

[0136] In one embodiment, the processing unit 1001 is further configured to: serialize the first block and split the serialization result into N data blocks; the first block is any block on the blockchain; N is a positive integer greater than 1; form an N*1 data block matrix from the split N data blocks; encode the data block matrix using the encoding matrix to obtain an encoding result; the encoding result includes K check blocks and the split N data blocks; K is a positive integer greater than 1; and store all or part of the check blocks in the K check blocks through the storage unit 1003.

[0137] In one embodiment, the consensus network is composed of G consensus nodes, where G is a positive integer greater than 1, and K is equal to G. When the processing unit 1001 stores all or part of the K verification blocks in the storage unit 1003, it is specifically used to: determine from the K verification blocks a matching verification block whose arrangement identifier matches the arrangement identifier of the data processing device (or the target consensus node) in the consensus network; and store the matching verification block in the storage unit 1003.

[0138] In one embodiment, the processing unit 1001 is further configured to: perform hash calculation on each of the K verification blocks to obtain K hash values; construct a Merkle tree based on the K hash values, and add the root of the constructed Merkle tree to the block header of the second block; the second block is the next block after the first block on the blockchain.

[0139] In one embodiment, the transceiver unit 1002 is further configured to receive a block synchronization request sent by a target service node, the block synchronization request carrying the synchronization block height and the node identifier of the target service node; the target service node is any service node in the witness network;

[0140] The processing unit 1001 is further configured to: determine a matching block on the blockchain that matches the height of the synchronization block, and obtain the block header of the matching block and the transaction data included in the matching block that the target business node has access to; and obtain the matching verification block among the K verification blocks that matches the node identifier.

[0141] The transceiver unit 1002 is further configured to send the block header of the matching block, the transaction data with access permissions, and the matching verification block to the target business node.

[0142] In a feasible embodiment, the data processing device may be a target service node corresponding to the witness network described above, wherein:

[0143] The processing unit 1001 is used to send a block synchronization request to the consensus nodes in the consensus network through the transceiver unit 1002; the block synchronization request carries the synchronization block height and the node identifier of the data processing device (or the target business node); the synchronization block height is the block height of the target block to be synchronized, and the target block is a block on the blockchain maintained by the consensus nodes in the consensus network; the block synchronization request is used to request the consensus node to return the relevant data of the target block;

[0144] The transceiver unit 1002 is further configured to receive relevant data of the target block returned by the consensus node; the relevant data includes the block header of the target block, transaction data that the data processing device (or target business node) has access to in the target block, and matching verification blocks that match the node identifier among the K verification blocks corresponding to the target block; the K verification blocks are obtained by encoding the target block using an encoding matrix; K is a positive integer greater than 1;

[0145] Storage unit 1003 is used to store relevant data of the target block; wherein the stored matching and verification block is used by the consensus nodes in the consensus network to recover the target block.

[0146] In one embodiment, the transceiver unit 1002 is further configured to receive a verification block acquisition request for the target block sent by a target consensus node in the consensus network; the verification block acquisition request is broadcast by the target consensus node to the service nodes in the witness network when it determines that the target block needs to be recovered based on the verification block of the target block;

[0147] The processing unit 1001 is further configured to send the matching check block corresponding to the stored target block to the consensus node through the transceiver unit 1002, so that the target consensus node can recover the target block based on the matching check block.

[0148] In one embodiment, the processing unit 1001 is further configured to: obtain the block header of a reference block synchronized from a consensus node in the consensus network, wherein the reference block is the next block after the target block on the blockchain, and the block header of the reference block includes the root of a Merkle tree constructed based on K check blocks corresponding to the target block; if the matching check block in the related data matches the root of the Merkle tree included in the block header of the reference block, then the matching check block is stored through the storage unit 1003.

[0149] It is understood that the functions of each functional unit of the data processing device described in the embodiments of this application can be specifically implemented according to the methods in the above method embodiments, and the specific implementation process can be referred to the relevant descriptions in the above method embodiments, which will not be repeated here.

[0150] In this embodiment, the consensus node generates a check block for a block and synchronizes the check block along with the relevant block data to the business node when the business node synchronizes the block. When the consensus node needs to recover a block, it obtains the check block of the block to be recovered from the business node, and the block can be successfully recovered based on the obtained check block. Using this method, even when the consensus network is unavailable and block recovery cannot be completed based on the block data stored by the business node, the block can still be successfully recovered based on the check block stored by the business node, and the availability of the recovered block can be effectively guaranteed.

[0151] In feasible embodiments, the data processing device provided in this application can be implemented in software. The data processing device can be stored in a memory and can be software in the form of programs and plug-ins. It includes a series of units, including a processing unit, a communication unit, and a storage unit. The processing unit, communication unit, and storage unit are used to implement the data processing method based on a blockchain network provided in this application.

[0152] In other feasible embodiments, the data processing device provided in this application embodiment can also be implemented in a combination of hardware and software. As an example, the data processing device provided in this application embodiment can be a processor in the form of a hardware decoding processor, which is programmed to execute the data processing method based on the blockchain network provided in this application embodiment. For example, the processor in the form of a hardware decoding processor can adopt one or more application specific integrated circuits (ASICs), DSPs, programmable logic devices (PLDs), complex programmable logic devices (CPLDs), field-programmable gate arrays (FPGAs), or other electronic components.

[0153] Please see Figure 11 , Figure 11This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. The computer device described in this embodiment includes: a processor 1101, a communication interface 1102, and a memory 1103. The processor 1101, communication interface 1102, and memory 1103 can be connected via a bus or other means; this embodiment takes a bus connection as an example.

[0154] The processor 1101 (or CPU (Central Processing Unit)) is the computing and control core of the computer device. It can parse various instructions and process various data within the computer device. For example, the CPU can parse power-on / off commands sent by the user and control the computer device to perform power-on / off operations; it can also transmit various interactive data between internal structures of the computer device. The communication interface 1102 may optionally include standard wired interfaces or wireless interfaces (such as Wi-Fi, mobile communication interfaces, etc.), and is controlled by the processor 1101 for sending and receiving data. The memory 1103 is the storage device in the computer device, used to store programs and data. It is understood that the memory 1103 here can include the computer device's built-in memory, or it can include extended memory supported by the computer device. The memory 1103 provides storage space for the computer device's operating system, which may include, but is not limited to, Android, iOS, Windows Phone, etc., and this application does not limit this.

[0155] In this embodiment of the application, the computer device is applied in a blockchain network, which includes a witness network and a consensus network. The witness network is composed of multiple business nodes networked together, and the consensus network is composed of multiple consensus nodes networked together. The witness network and the consensus network establish a communication connection.

[0156] In a feasible embodiment, the computer device may be a target consensus node corresponding to the consensus network described above, wherein the processor 1101 performs the following operations by running executable program code in the memory 1103:

[0157] When it is determined that the target block needs to be recovered based on the verification block of the target block, the verification block of the target block is obtained from the service node in the witness network through the communication interface 1102; a data recovery reference matrix is ​​determined based on the encoding matrix and the verification block obtained from the service node in the witness network; the target block is recovered based on the data recovery reference matrix and the verification block obtained from the service node in the witness network.

[0158] Wherein, the target block is a block on the blockchain maintained by the consensus nodes in the consensus network; the verification block of the target block stored by the business node is obtained by the business node when synchronizing the relevant block data of the target block from the consensus nodes in the consensus network; the verification block is obtained by the consensus nodes in the consensus network encoding the target block using the encoding matrix; the verification block is used to recover the target block.

[0159] In one embodiment, the processor 1101 is further configured to: if it is detected that the target block needs to be restored, and the proportion of abnormal consensus nodes in the consensus network exceeds a set proportion, and the service nodes in the witness network have not stored all the block data of the target block, then determine that the target block needs to be restored based on the verification block of the target block.

[0160] In one embodiment, the target block has K check blocks, where K is a positive integer greater than 1; the processor 1101 determines a data recovery reference matrix based on the encoding matrix and the check blocks obtained from the service nodes in the witness network, and when recovering the target block based on the data recovery reference matrix and the check blocks obtained from the service nodes in the witness network, it is specifically used for:

[0161] When K verification blocks of the target block are obtained from the service nodes in the witness network, the matrix elements corresponding to the K verification blocks are obtained from the encoding matrix; a data recovery reference matrix is ​​determined based on the obtained matrix elements corresponding to the K verification blocks, and the inverse matrix of the data recovery reference matrix is ​​determined; the target block is recovered based on the inverse matrix of the data recovery reference matrix and the K verification blocks.

[0162] When X verification blocks of the target block are obtained from the service nodes in the witness network, the target block is obtained from the consensus nodes in the consensus network; X is a positive integer less than K; the obtained target block is serialized, and the serialization result is split into N data blocks; N is a positive integer greater than 1; KX data blocks are obtained from the N split data blocks; the matrix elements corresponding to the X verification blocks and the KX data blocks are obtained from the encoding matrix, and a data recovery reference matrix is ​​determined based on the obtained matrix elements corresponding to the X verification blocks and the KX data blocks; the inverse matrix of the data recovery reference matrix is ​​determined, and the target block is recovered based on the inverse matrix of the data recovery reference matrix, the X verification blocks, and the KX data blocks.

[0163] In one embodiment, the processor 1101 is further configured to: detect whether the target block recovered based on the inverse matrix of the data recovery reference matrix, the X check blocks, and the KX data blocks is consistent with the target block obtained from the consensus node in the consensus network; if consistent, then determine that the target block recovery is successful.

[0164] In one embodiment, the target block has K check blocks, where K is a positive integer greater than 1; the processor 1101 is further configured to: obtain the block header of a reference block from a business node in the witness network via a communication interface 1102; the reference block is the next block on the blockchain after the target block, and the block header of the reference block includes the root of a Merkle tree constructed based on the K check blocks corresponding to the target block; discard check blocks in the obtained target block that do not match the root of the Merkle tree included in the block header of the reference block. That is to say: subsequently, a data recovery reference matrix is ​​determined based on the encoding matrix and the obtained check blocks that match the root of the Merkle tree included in the block header of the reference block, and the target block is recovered based on the data recovery reference matrix and the obtained check blocks that match the root of the Merkle tree included in the block header of the reference block.

[0165] In one embodiment, the processor 1101 is further configured to: serialize the first block and split the serialization result into N data blocks; the first block is any block on the blockchain; N is a positive integer greater than 1; form an N*1 data block matrix from the split N data blocks; encode the data block matrix using the encoding matrix to obtain an encoding result; the encoding result includes K check blocks and the split N data blocks; K is a positive integer greater than 1; and store all or part of the check blocks in the K check blocks through the memory 1103.

[0166] In one embodiment, the consensus network is composed of G consensus nodes, where G is a positive integer greater than 1, and K is equal to G. When the processor 1101 stores all or part of the K verification blocks in the memory 1103, it is specifically used to: determine from the K verification blocks a matching verification block whose arrangement identifier matches the arrangement identifier of the computer device (or the target consensus node) in the consensus network; and store the matching verification block in the memory 1103.

[0167] In one embodiment, the processor 1101 is further configured to: perform hash calculation on each of the K verification blocks to obtain K hash values; construct a Merkle tree based on the K hash values, and add the root of the constructed Merkle tree to the block header of the second block; the second block is the next block on the blockchain after the first block.

[0168] In one embodiment, the processor 1101 is further configured to: receive a block synchronization request sent by a target business node via a communication interface 1102, the block synchronization request carrying a synchronization block height and a node identifier of the target business node; the target business node is any business node in the witness network; determine a matching block on the blockchain that matches the synchronization block height, and obtain the block header of the matching block and the transaction data included in the matching block that the target business node has access to; obtain the matching verification block among the K verification blocks that matches the node identifier; and send the block header of the matching block, the transaction data with access to the matching block, and the matching verification block to the target business node via the communication interface 1102.

[0169] In a feasible embodiment, the computer device may be a target service node corresponding to the witness network described above, wherein the processor 1101 performs the following operations by running executable program code in the memory 1103:

[0170] A block synchronization request is sent to the consensus nodes in the consensus network through communication interface 1102; the block synchronization request carries the synchronization block height and the node identifier of the computer device (or target business node); the synchronization block height is the block height of the target block to be synchronized, and the target block is a block on the blockchain maintained by the consensus nodes in the consensus network; the block synchronization request is used to request the consensus nodes to return the relevant data of the target block;

[0171] The system receives relevant data about the target block returned by the consensus node through communication interface 1102. The relevant data includes the block header of the target block, transaction data that the computer device (or target business node) has access to in the target block, and matching verification blocks that match the node identifier among the K verification blocks corresponding to the target block. The K verification blocks are obtained by encoding the target block using an encoding matrix. K is a positive integer greater than 1.

[0172] The relevant data of the target block is stored in the memory 1103; wherein the stored matching verification block is used by the consensus nodes in the consensus network to recover the target block.

[0173] In one embodiment, the processor 1101 is further configured to: receive, via the communication interface 1102, a verification block acquisition request for the target block sent by a target consensus node in the consensus network; the verification block acquisition request is broadcast by the target consensus node to the service nodes in the witness network when it determines that the target block needs to be recovered based on the verification block of the target block;

[0174] The target consensus node sends the matching check block corresponding to the stored target block to the consensus node through the communication interface 1102, so that the target consensus node can recover the target block based on the matching check block.

[0175] In one embodiment, the processor 1101 is further configured to: obtain the block header of a reference block synchronized from a consensus node in the consensus network, the reference block being the next block after the target block on the blockchain, the block header of the reference block including the root of a Merkle tree constructed based on K check blocks corresponding to the target block; if the matching check block in the related data matches the root of the Merkle tree included in the block header of the reference block, then the matching check block is stored in the memory 1103.

[0176] In specific implementation, the processor 1101, communication interface 1102 and memory 1103 described in the embodiments of this application can implement the data processing method based on the blockchain network in the above method embodiments. The specific implementation process can be referred to the relevant descriptions in the above method embodiments, which will not be repeated here.

[0177] In this embodiment, the consensus node generates a check block for a block and synchronizes the check block along with the relevant block data to the business node when the business node synchronizes the block. When the consensus node needs to recover a block, it obtains the check block of the block to be recovered from the business node, and the block can be successfully recovered based on the obtained check block. Using this method, even when the consensus network is unavailable and block recovery cannot be completed based on the block data stored by the business node, the block can still be successfully recovered based on the check block stored by the business node, and the availability of the recovered block can be effectively guaranteed.

[0178] This application also provides a computer-readable storage medium storing a computer program that, when run on a computer, enables the computer to implement the data processing method based on a blockchain network as described in this application. The specific implementation method can be found in the preceding description and will not be repeated here.

[0179] This application also provides a computer program product, which includes a computer program or computer instructions. When executed by a processor, the computer program or computer instructions implement the data processing based on a blockchain network as described in this application embodiment. Specific implementation details can be found in the preceding description and will not be repeated here.

[0180] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to this application.

[0181] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, which may include: a flash drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk, etc.

[0182] The above-disclosed embodiments are only some of the embodiments of this application, and should not be construed as limiting the scope of this application. Therefore, any equivalent changes made in accordance with the claims of this application shall still fall within the scope of this application.

Claims

1. A data processing method based on a blockchain network, characterized in that, The blockchain network includes a witness network and a consensus network operating in different network environments. The witness network consists of multiple business nodes, and the consensus network consists of multiple consensus nodes. The witness network and the consensus network are connected. Consensus nodes store block data for all blocks on the blockchain. Business nodes synchronize relevant block data from the consensus nodes. The relevant block data includes the block header and transaction data that the business nodes have access to. The method includes: When it is determined that the target block needs to be recovered based on the verification block of the target block, the verification block of the target block is obtained from the business node in the witness network; wherein, the target block is a block on the blockchain maintained by the consensus node in the consensus network; the verification block of the target block stored by the business node is obtained by the business node when synchronizing the relevant block data of the target block from the consensus node in the consensus network, and is the matching verification block that matches the node identifier of the business node among the K verification blocks corresponding to the target block; the K verification blocks are obtained by the consensus node in the consensus network encoding the target block using an encoding matrix, and are used to recover the target block; When X verification blocks of the target block are obtained from the service nodes in the witness network, the target block is obtained from the consensus nodes in the consensus network; X is a positive integer less than K. The obtained target block is serialized, and the serialization result is split into N data blocks; KX data blocks are obtained from the N data blocks. Obtain the matrix elements corresponding to the X check blocks and the KX data blocks from the encoding matrix, and determine the data recovery reference matrix based on the obtained matrix elements corresponding to the X check blocks and the KX data blocks; The inverse matrix of the data recovery reference matrix is ​​determined, and the target block is recovered based on the inverse matrix of the data recovery reference matrix, the X check blocks, and the KX data blocks.

2. The method as described in claim 1, characterized in that, The method further includes: If it is detected that the target block needs to be restored, and the proportion of abnormal consensus nodes in the consensus network exceeds a set proportion, and the service nodes in the witness network have not stored all the block data of the target block, then it is determined that the target block needs to be restored based on the verification block of the target block.

3. The method as described in claim 1 or 2, characterized in that, The method further includes: When K verification blocks of the target block are obtained from the service nodes in the witness network, the matrix elements corresponding to the K verification blocks are obtained from the encoding matrix; The data recovery reference matrix is ​​determined based on the matrix elements corresponding to the K verification blocks obtained, and the inverse matrix of the data recovery reference matrix is ​​determined. The target block is recovered based on the inverse matrix of the data recovery reference matrix and the K check blocks.

4. The method as described in claim 1 or 2, characterized in that, The method further includes: The target block recovered based on the inverse matrix of the data recovery reference matrix, the X verification blocks, and the KX data blocks is checked to see if it is consistent with the target block obtained from the consensus node in the consensus network. If they match, then the target block has been successfully restored.

5. The method as described in claim 1 or 2, characterized in that, The method further includes: Obtain the block header of the reference block from the business nodes in the witness network; the reference block is the next block after the target block on the blockchain, and the block header of the reference block includes the root of a Merkle tree constructed based on the K check blocks corresponding to the target block; Discard any check blocks in the target block whose check blocks do not match the root of the Merkle tree included in the block header of the reference block.

6. The method as described in claim 1, characterized in that, The method further includes: The first block is serialized, and the serialization result is split into N data blocks; the first block is any block on the blockchain; N is a positive integer greater than 1. The N data blocks obtained from the split are combined into an N... A data block matrix of 1; The data block matrix is ​​encoded using the encoding matrix to obtain an encoding result; the encoding result includes K parity blocks and N data blocks obtained by splitting; K is a positive integer greater than 1; Store all or part of the K check blocks.

7. The method as described in claim 6, characterized in that, The consensus network consists of a network of G consensus nodes, where G is a positive integer greater than 1, and K is equal to G; the storage of all or part of the K verification blocks includes: From the K verification blocks, determine the matching verification blocks whose arrangement identifiers match the arrangement identifiers of the target consensus node in the consensus network; Store the matching verification block.

8. The method as described in claim 6, characterized in that, The method further includes: Perform a hash calculation on each of the K check blocks to obtain K hash values; A Merkle tree is constructed based on the K hash values, and the root of the constructed Merkle tree is added to the block header of the second block; the second block is the next block after the first block on the blockchain.

9. The method according to any one of claims 6-8, characterized in that, The method further includes: Receive a block synchronization request sent by a target service node, the block synchronization request carrying the synchronization block height and the node identifier of the target service node; the target service node is any service node in the witness network; Determine a matching block on the blockchain that matches the height of the synchronization block, and obtain the block header of the matching block and the transaction data included in the matching block that the target business node has access to. Obtain the matching verification block among the K verification blocks that matches the node identifier; The block header of the matching block, the transaction data with access permissions, and the matching verification block are sent to the target business node.

10. A data processing method based on a blockchain network, characterized in that, The blockchain network includes a witness network and a consensus network operating in different network environments. The witness network consists of multiple business nodes, and the consensus network consists of multiple consensus nodes. The witness network and the consensus network are connected. Consensus nodes store block data for all blocks on the blockchain. Business nodes synchronize relevant block data from the consensus nodes. The relevant block data includes the block header and transaction data that the business nodes have access to. The method includes: A block synchronization request is sent to the consensus nodes in the consensus network; the block synchronization request carries the synchronization block height and the node identifier of the target business node; the synchronization block height is the block height of the target block to be synchronized, and the target block is a block on the blockchain maintained by the consensus nodes in the consensus network; the block synchronization request is used to request the consensus node to return the relevant data of the target block; The system receives relevant data about the target block returned by the consensus node. The relevant data includes the block header of the target block, transaction data that the target business node has access to in the target block, and matching verification blocks that match the node identifier among the K verification blocks corresponding to the target block. The K verification blocks are obtained by encoding the target block using an encoding matrix. K is a positive integer greater than 1. The relevant data of the target block is stored; wherein the stored matching and verification block is used by the consensus nodes in the consensus network to recover the target block; Specifically, when the consensus node determines that the target block needs to be recovered based on the verification blocks of the target block, and obtains X verification blocks of the target block from the service nodes in the witness network, where X is less than K, the consensus node will serialize the target block obtained from the consensus network, obtain KX data blocks from the N data blocks obtained by splitting the serialization result, obtain the matrix elements corresponding to the X verification blocks and the KX data blocks from the encoding matrix, determine the data recovery reference matrix based on the obtained matrix elements, determine the inverse matrix of the data recovery reference matrix, and recover the target block based on the inverse matrix, the X verification blocks, and the KX data blocks.

11. The method as described in claim 10, characterized in that, The method further includes: The system receives a verification block retrieval request for the target block from a target consensus node in the consensus network. The verification block retrieval request is broadcast by the target consensus node to the service nodes in the witness network when it determines that the target block needs to be recovered based on the verification block of the target block. The matching check block corresponding to the stored target block is sent to the consensus node so that the target consensus node can recover the target block based on the matching check block.

12. The method as described in claim 10 or 11, characterized in that, The method further includes: Obtain the block header of a reference block synchronized from consensus nodes in the consensus network. The reference block is the next block after the target block on the blockchain. The block header of the reference block includes the root of a Merkle tree constructed based on the K check blocks corresponding to the target block. If the matching check block in the relevant data matches the root of the Merkle tree included in the block header of the reference block, then the matching check block is stored.

13. A data processing apparatus, characterized in that, It includes a unit for performing the data processing method based on a blockchain network as described in any one of claims 1-9, or includes a unit for performing the data processing method based on a blockchain network as described in any one of claims 10-12.

14. A computer device, characterized in that, include: The system includes a processor, a communication interface, and a memory, which are interconnected. The memory stores executable program code, and the processor is used to call the executable program code to implement the data processing method based on a blockchain network as described in any one of claims 1-9, or to implement the data processing method based on a blockchain network as described in any one of claims 10-12.

15. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that, when executed on a computer, cause the computer to implement the data processing method based on a blockchain network as described in any one of claims 1-9, or to implement the data processing method based on a blockchain network as described in any one of claims 10-12.

16. A computer program product, characterized in that, The computer program product includes a computer program or computer instructions, which, when executed by a processor, implement the data processing method based on a blockchain network as described in any one of claims 1-9, or implement the data processing method based on a blockchain network as described in any one of claims 10-12.

Images