Blockchain-based data storage method, device and computer equipment

Abstract

The application relates to a blockchain-based data storage method and device, computer equipment, a storage medium and a computer program product. The method comprises the following steps: acquiring a source file, determining the number of participating nodes in a blockchain, generating a plurality of block encoding data according to the number of participating nodes, and distributing the plurality of block encoding data to each participating node; randomly determining a second number of target verification nodes from the verification nodes, and performing validity verification by each target verification node based on the block encoding data stored by a preset number of participating nodes; receiving feedback information of each target verification node, and determining that the source file has been successfully stored on a chain in the case that the number of feedback information representing that the validity verification is passed reaches a preset threshold; and performing data recovery based on the block encoding data stored in each backup node in response to a recovery operation on the source file. The method can improve the security of the source file.

Description

Technical Field

[0001] This application relates to the field of blockchain technology, and in particular to a blockchain-based data storage method, apparatus, computer equipment, storage medium, and computer program product. Background Technology

[0002] Blockchain is a novel application model of computer technologies, including distributed data storage, peer-to-peer transmission, consensus mechanisms, and cryptographic algorithms. Due to its decentralized, tamper-proof, and autonomous characteristics, blockchain can generate virtual resources that serve as digital credentials for items and records. For example, real-world assets, images, audio, or video can be mapped to virtual resources and published on the blockchain.

[0003] Blockchain technology ensures the immutability and security of virtual resources issued on the chain. However, because the source files of virtual resources are stored on cloud servers, they are at risk of loss, and effective security protection for these source files is not possible. Loss of the source files can render the virtual resources inaccessible or corrupted. Summary of the Invention

[0004] Therefore, it is necessary to provide a data storage method, device, computer equipment, computer-readable storage medium, and computer program product based on blockchain to address the aforementioned technical problems.

[0005] On the one hand, this application provides a data storage method based on blockchain. The method includes:

[0006] Obtain the source file and determine the first number of participating nodes in the blockchain, wherein the participating nodes include at least validator nodes, consensus nodes and backup nodes, and the number of backup nodes exceeds one-third of the first number;

[0007] Based on the first number of participating nodes and the source file, multiple block encoding data are generated, and the multiple block encoding data are distributed to each participating node one by one.

[0008] A second number of target verification nodes are randomly selected from the verification nodes;

[0009] A verification request is sent to each of the target verification nodes to instruct each target verification node to perform validity verification based on the block encoding data stored by a preset number of participating nodes.

[0010] Receive feedback information from each target verification node, and determine that the source file has been successfully stored on the blockchain when the number of feedback information indicating that the validity verification has passed reaches a preset threshold.

[0011] In response to the recovery operation of the source file, data recovery is performed based on the block-coded data stored in each backup node.

[0012] On the other hand, this application also provides a blockchain-based data storage device. The device includes:

[0013] The acquisition module is used to acquire the source file and determine the first number of participating nodes in the blockchain. The participating nodes include at least verification nodes, consensus nodes, and backup nodes, wherein the number of backup nodes exceeds one-third of the first number.

[0014] The generation module is used to generate multiple block encoding data according to the first number of participating nodes and based on the source file, and distribute the multiple block encoding data to each participating node one by one;

[0015] A determining module is used to randomly determine a second number of target verification nodes from the verification nodes;

[0016] The verification module is used to send verification requests to each of the target verification nodes, instructing each of the target verification nodes to perform validity verification based on the block encoding data stored by a preset number of participating nodes.

[0017] The storage module is used to receive feedback information from each target verification node. When the number of feedback information indicating that the validity verification has passed reaches a preset threshold, it is determined that the source file has been successfully stored on the blockchain.

[0018] The recovery module is used to perform data recovery based on the block-coded data stored in each backup node in response to the recovery operation of the source file.

[0019] In some embodiments, the generation module is further configured to divide the source file into blocks to obtain a preset number of block data, the preset number being less than the first number; determine multiple redundant encoded data corresponding to the source file, and generate a first number of block encoded data based on the preset number of block data and the multiple redundant encoded data.

[0020] In some embodiments, the verification request is used to instruct each target verification node to randomly select a preset number of participating nodes, and to restore the file based on the block encoding data stored by the randomly selected preset number of participating nodes, and to determine the restored file signature of the restored file. If the restored file signature is consistent with the source file signature of the source file, the validity verification is determined to be successful.

[0021] In some embodiments, the storage module is further configured to receive feedback information from each target verification node, the feedback information including the verifier signature returned by the target verification node when the validity verification is determined to be passed; and to determine that the source file has been successfully stored on the blockchain when the number of collected verifier signatures reaches a preset threshold.

[0022] In some embodiments, the apparatus further includes a recovery module, configured to, in response to a recovery operation on a source file, randomly determine a target backup node from the backup nodes; and send a source file recovery request to the target backup node to instruct the target backup node to perform data recovery based on the block-coded data stored in each backup node.

[0023] In some embodiments, the source file recovery request is used to instruct the target backup node to obtain block-coded data stored in a preset number of backup nodes, including the target backup node, and to perform data recovery based on the obtained differential-coded data stored in the preset number of backup nodes, so as to obtain the source file.

[0024] In some embodiments, the source file recovery request is used to instruct the target backup node to construct a corresponding intermediate matrix based on the acquired multiple block-coded data, construct a cell matrix based on the intermediate matrix and the corresponding inverse matrix, and process the cell matrix, the intermediate matrix, and the inverse matrix to obtain the recovered source file.

[0025] In some embodiments, the apparatus further includes an issuance module, configured to transmit the source file information of the source file to a consensus node when it is determined that the source file has been successfully stored on the blockchain, so as to instruct the consensus node to verify the issuance of the source file; the source file information includes at least a source file identifier and encrypted source file data; wherein, when the issuance verification is passed, the consensus node marks the source file information and uploads the marked source file information to the blockchain, and the source file information is used to share in the blockchain to realize the issuance of the virtual resource corresponding to the source file.

[0026] In some embodiments, the consensus node verifies the issuance of the source file by means of: verifying whether the source file information has been validated by the verification node through a smart contract, and determining that the issuance verification of the source file has passed if it is determined that the source file information has been validated by the verification node.

[0027] In some embodiments, the blockchain includes a witness network with multiple business nodes and a consensus network with multiple participating nodes. The business nodes are used to obtain encrypted source file data corresponding to the source file from the consensus network and perform business processing based on the encrypted source file data.

[0028] In some embodiments, the device further includes a transaction module, configured to receive a resource transfer request sent by a client, wherein the resource transfer request carries at least a resource identifier of the virtual resource and a wallet address corresponding to the resource recipient; and in response to the resource transfer request, invoke a smart contract to change the address to which the virtual resource corresponding to the resource identifier belongs to the wallet address corresponding to the resource recipient.

[0029] On the other hand, this application also provides a computer device. The computer device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the steps of the above-described blockchain-based data storage method.

[0030] On the other hand, this application also provides a computer-readable storage medium. The computer-readable storage medium stores a computer program thereon, which, when executed by a processor, implements the steps of the above-described blockchain-based data storage method.

[0031] On the other hand, this application also provides a computer program product. The computer program product includes a computer program that, when executed by a processor, implements the steps of the aforementioned blockchain-based data storage method.

[0032] The aforementioned blockchain-based data storage method, device, computer equipment, storage medium, and computer program product ensures the source file is not lost by generating multiple block-encoded data from the source file and distributing it to various participating nodes. This decentralized, block-based storage of the source file guarantees its integrity. After distribution, a subset of target verification nodes are randomly selected to verify the file's validity. Feedback is provided upon successful verification, and once the number of feedback messages reaches a threshold, the source file is considered successfully stored in the blockchain. Even in the event of errors or loss among multiple nodes in the cluster, the decentralized capabilities of multiple nodes can be fully utilized for data recovery. When data recovery is required, it is performed based on the block-encoded data stored on each backup node. Since the number of backup nodes exceeds one-third of the total number of participating nodes, the security and reliability of the source file are effectively guaranteed even if multiple nodes in the blockchain fail. Attached Figure Description

[0033] Figure 1 This is a schematic diagram of the block structure in one embodiment;

[0034] Figure 2 This is an application environment diagram of a blockchain-based data storage method in one embodiment;

[0035] Figure 3 This is a flowchart illustrating a blockchain-based data storage method in one embodiment.

[0036] Figure 4 This is a schematic diagram illustrating the composition of participating nodes in a blockchain in one embodiment;

[0037] Figure 5 This is a schematic diagram illustrating the composition of participating nodes in a blockchain in another embodiment;

[0038] Figure 6A This is a schematic diagram illustrating the principle of a redundancy coding algorithm for generating block-coded data in one embodiment.

[0039] Figure 6B This is a schematic diagram illustrating the principle of data recovery in the event of data loss in one embodiment;

[0040] Figure 6C This is a schematic diagram illustrating the operational principle of source file recovery based on block-coded data in one embodiment;

[0041] Figure 6D This is a schematic diagram illustrating the operational principle of source file recovery based on block-coded data in another embodiment;

[0042] Figure 6E This is a schematic diagram illustrating the operational principle of source file recovery based on block-coded data in another embodiment;

[0043] Figure 7 This is a schematic diagram illustrating the specific process of a blockchain-based data storage method in one embodiment;

[0044] Figure 8 This is a structural block diagram of a blockchain-based data storage device in one embodiment;

[0045] Figure 9 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0046] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0047] Blockchain is a new 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 to generate the next block.

[0048] See Figure 1 , Figure 1 This is an optional schematic diagram of the block structure provided in this embodiment of the invention. Each block includes the hash value of the transaction records stored in this block (the hash value of this block) and the hash value of the previous block. The blocks are connected through hash values ​​to form a blockchain. In addition, the block may also include information such as the timestamp when the block was generated.

[0049] The data storage method based on blockchain involved in the embodiments of the present invention can be applied to a distributed system formed by connecting clients and multiple nodes (any form of computing device in the network, such as servers and user terminals) through network communication.

[0050] Taking this distributed system as an example of a blockchain system, a blockchain system consists of multiple nodes (any form of computing device connected to the network, such as servers and user terminals) and clients, forming a peer-to-peer (P2P) network between the nodes. The P2P protocol is an application layer protocol that runs on top of the Transmission Control Protocol (TCP).

[0051] In a distributed system, any machine, such as a server or terminal, can join as a node. A node comprises a hardware layer, a middleware layer, an operating system layer, and an application layer. In a blockchain system, each node may be involved in functions such as routing, applications, and smart contracts. Nodes communicate with each other through routing. The application functions provided by a node can implement specific business functions according to actual business needs, recording data related to these functions to form record data. This record data carries a digital signature to indicate the source of the task data. The record data is then sent to other nodes in the blockchain system. Upon successful verification of the record data's source and integrity, other nodes add the record data to a temporary block.

[0052] Smart contracts are computerized protocols that, when deployed on a blockchain and executed under certain conditions, can enforce specific terms to transfer or exchange ownership of virtual resources. Of course, smart contracts are not limited to executing transactions; they can also execute contracts that process received information.

[0053] The blockchain-based data storage method provided in this application can be applied to, for example... Figure 2In the illustrated application environment, terminal 202 communicates with server 204 via a network, and server 204 interacts with the distributed system. For example, server 204 interacts with the blockchain system through smart contracts and oracles. The function of the oracle is to write external information into the blockchain, enabling data exchange between the blockchain and the real world. Oracles can help on-chain smart contracts connect to data outside the blockchain network.

[0054] In some embodiments, server 204 acquires the source file uploaded by terminal 202, determines the number of participating nodes in the blockchain, generates a corresponding number of block encoding data, and then distributes the block encoding data to each participating node. Then, server 204 randomly selects a second number of target verification nodes from the verification nodes and sends verification requests to each target verification node to instruct them to perform validity verification. Server 204 determines that the source file has been successfully stored on the blockchain when the number of feedback messages indicating successful validity verification reaches a preset threshold, based on feedback information received from each target verification node. During subsequent data recovery, server 204 responds to the source file recovery operation by performing data recovery based on the block encoding data stored in each backup node to restore the source file. The source file recovery operation can be initiated by terminal 202.

[0055] The terminal 202 can be, but is not limited to, one or more of various desktop computers, laptops, smartphones, tablets, IoT devices, or portable wearable devices. IoT devices can be one or more of smart speakers, smart TVs, smart air conditioners, or smart in-vehicle devices. Portable wearable devices can be one or more of smartwatches, smart bracelets, or head-mounted devices. The server 204 can be a standalone physical server or a server cluster consisting of multiple physical servers. In some embodiments, the terminal may have a client installed, allowing the terminal to upload source files via the client for storage on the blockchain via the server.

[0056] In some embodiments, such as Figure 3 As shown, a blockchain-based data storage method is provided. This method can be executed independently by a terminal or a server, or it can be executed collaboratively by both. The following description uses the application of this method to a server as an example, including the following steps:

[0057] Step S302: Obtain the source file and determine the first number of participating nodes in the blockchain. The participating nodes include at least a verification node, a consensus node, and a backup node, wherein the number of backup nodes exceeds one-third of the first number.

[0058] The source file is the data file to be stored on the blockchain. As a data carrier of information resources, the source file can describe virtual or physical objects in different data formats. In some embodiments, the source file can be used to describe virtual resources, typically including related media attachments and content. Taking digital collectibles as an example, digital collectibles can be used to mark ownership of digital items, such as audio, video, game props, or digital artworks, and can also be used to mark ownership of physical assets, such as art collections, real estate certificates, or identity documents. The source file of a virtual resource includes related media attachments and content, such as the name, description, or images of the digital collectible.

[0059] A blockchain has multiple participating nodes, including validator nodes, consensus nodes, and backup nodes. Backup nodes only store block-encoded data and do not participate in consensus or other logic. If the source file is lost, a request to restore the source file can be sent to any backup node. Backup nodes will try their best to restore the data without requesting data from consensus and validator nodes.

[0060] The number of participating nodes in the blockchain network can be determined based on the actual application scenario and is not limited. To ensure the recoverability of the source file after it is stored on the blockchain, the number of backup nodes exceeds one-third of the total number of participating nodes.

[0061] Since consensus nodes and verification nodes have corresponding execution functions, such as executing consensus logic, in some embodiments, data recovery requests are avoided from consensus nodes and verification nodes after the source file is stored on the blockchain. In other words, the recovery file is first requested from the backup node to perform source file recovery. Backup nodes can perform data recovery by requesting data stored by other backup nodes, while minimizing requests to consensus nodes and verification nodes. In cases of attack, loss, or an excessive number of inaccessible backup nodes, a backup node receiving a recovery request can request stored data from the consensus node or verification node to perform source file recovery.

[0062] like Figure 4As shown, multiple consensus nodes, verification nodes, and backup nodes can be set up in the blockchain according to actual needs. It should be noted that, for clarity, the connections between nodes are not shown. Exemplarily, nodes can be connected via P2P (Peer-to-Peer). Specifically, the server obtains the source file uploaded by the client and determines the number of participating nodes in the blockchain (referred to as the first number) to determine the number of copies of the subsequently generated block encoding data. In some embodiments, the client can access the server through its installed application to transfer the source file to the server. Of course, the server can also extract pre-stored source files; the source of the source file is not limited in this embodiment.

[0063] In some scenarios, not all blockchain participants have sufficient resources and the necessity to participate in the blockchain consensus process. Furthermore, due to data security concerns, the common peer-to-peer blockchain deployment approach is not suitable when dealing with security-related data within the blockchain system. Therefore, in some embodiments, the blockchain can be divided into a witness network and a consensus network. Nodes in the witness network primarily perform business execution and do not participate in consensus logic. Instead, they obtain block header data and partially authorized block data from the consensus network through identity authentication. The witness network and the consensus network operate in different network environments; typically, the witness network resides in a public network, while the consensus network resides in a private network.

[0064] like Figure 5 As shown, in some embodiments, the blockchain includes a witness network with multiple business nodes and a consensus network with multiple participating nodes. The business nodes and the consensus network interact through routing boundaries. Participating nodes may include consensus nodes, verification nodes, and backup nodes. The business nodes are used to obtain encrypted source file data corresponding to the source file from the consensus network and perform business processing based on this encrypted data. For example, a business node obtains block header data and hash values ​​from the consensus nodes in the consensus network through authentication, and performs business processing such as virtual resource transfer, transaction, and accounting based on the hash values.

[0065] Step S304: Generate multiple block encoding data according to the first number of participating nodes and based on the source file, and distribute the multiple block encoding data to each participating node one by one.

[0066] Specifically, based on the first number of participating nodes, the server generates a first number of block-encoded data based on the original source file, and distributes this first number of block-encoded data to each participating node. For example, if the participating nodes include A consensus nodes and B verification nodes, the server generates (A+B) block-encoded data based on (A+B) participating nodes. Or, if the participating nodes include A consensus nodes, B verification nodes, and C backup nodes, the server generates (A+B+C) block-encoded data.

[0067] In some embodiments, the server generates block-encoded data based on a source file by copying the source file multiple times, with each copy serving as a block-encoded data unit. Alternatively, the source file can be copied multiple times and encrypted separately, with each encrypted copy serving as a block-encoded data unit. Since blockchain is a decentralized distributed data storage system, to reduce the storage space of all nodes in the cluster and fully utilize the decentralized functionality of multiple nodes, in some embodiments, the server generates block-encoded data based on the source file by dividing the source file into multiple blocks, and generating block-encoded data corresponding to each block. For example, each block can be encrypted to obtain block-encoded data corresponding to each block.

[0068] In some embodiments, the server generates block-coded data based on the source file, which can be done by generating multiple copies of the block-coded data using a redundancy coding algorithm. Compared to multi-copy replication, generating multiple copies of the block-coded data using a redundancy coding algorithm can achieve higher data reliability with less data redundancy.

[0069] Step S306: Randomly select a second number of target verification nodes from the verification nodes.

[0070] After distributing the block-coded data, the server verifies the validity of the block-coded data. In some embodiments, the server receives a request from the client and, in response, randomly selects a second number of target verification nodes from the verification nodes for verification. To ensure the validity of data storage, the second number can be one, two, or more. If all randomly selected target verification nodes can verify and confirm the validity of the block-coded data, it proves that the source file has been successfully stored in a decentralized manner.

[0071] Step S308: Send a verification request to each target verification node to instruct each target verification node to perform validity verification based on the block encoding data stored by a preset number of participating nodes.

[0072] After randomly selecting target verification nodes, the server sends verification requests to each target verification node. Upon receiving the verification request, the target verification node requests the block encoding data stored by other participating nodes, attempts to recover the source file based on the block encoding data stored by other participating nodes, and verifies the recovered source file to determine whether the recovered source file is valid.

[0073] In some embodiments, the verification request is used to instruct each target verification node to randomly select a preset number of participating nodes, and to restore the file based on the block encoding data stored by the randomly selected preset number of participating nodes, and to determine the restored file signature of the restored file. If the restored file signature is consistent with the source file signature of the source file, the validity verification is determined to be successful.

[0074] Specifically, after receiving a verification request, the target verification node randomly requests the stored block encoding data from a preset number of other participating nodes and attempts to recover the data from the source file. For the recovered source file (referred to as the restored file), the target verification node performs validity verification to determine whether the restored file signature matches the source file signature. In some embodiments, the restored file signature and the source file signature can be hash values.

[0075] For example, the target verification node performs data recovery based on the block-coded data stored by other participating nodes and compares the hash value of the recovered source file with the hash value of the original source file. If they match, the source file has been successfully stored. If they do not match, it indicates that data loss or errors have occurred, and the source file has failed to be stored. The target verification node can return a verification failure message to the server to indicate that storage has failed. The server can then redistribute the block-coded data or regenerate the block-coded data, etc.

[0076] Step S310: Receive feedback information from each target verification node. If the number of feedback messages that represent the validity verification has reached a preset threshold, determine that the source file has been successfully stored on the blockchain.

[0077] Once the target verification node has recovered the data and verified the validity of the recovered source file, it sends feedback to the server to indicate that the verification was successful, meaning the validity verification has passed. In some embodiments, the feedback information includes, but is not limited to, a notification message or a signature.

[0078] If the number of feedback messages collected by the server reaches a preset threshold, it means that multiple target verification nodes have successfully verified the validity of the decentralized storage source file. Since the target verification nodes are randomly selected, if feedback messages indicating that the validity verification has been passed can be obtained by selecting any target verification node, it can be determined that the source file has been successfully stored in the blockchain.

[0079] Step S312: In response to the recovery operation of the source file, data recovery is performed based on the block-coded data stored in each backup node.

[0080] Once the source file has been successfully stored on the blockchain (i.e., stored on-chain), a request can be made to backup nodes for data recovery. This recovery operation can be initiated proactively by the client or automatically if a node error or data loss is detected in the blockchain. For example, if the source file is lost, the server can send a request to any backup node to recover the file.

[0081] Specifically, in response to a recovery operation on the source file, the server requests data recovery from the backup nodes. Upon receiving the request, the backup nodes can perform data recovery based on the block-encoded data stored on each backup node to restore the source file.

[0082] In some embodiments, the requested backup node may request the stored block encoding data from multiple other backup nodes based on a copy of the block encoding data it has stored. After obtaining a sufficient number of copies of the block encoding data, it performs data recovery to restore the original file.

[0083] In other embodiments, the requested backup node may also request a sufficient number of block-coded data from multiple other backup nodes and perform data recovery accordingly to restore the original file.

[0084] In some cases, the requested backup node may also request the stored block-encoded data from one or more of the consensus nodes or validator nodes to perform data recovery.

[0085] In the aforementioned blockchain-based data storage method, by generating multiple block-encoded data from the source file and distributing them to various participating nodes, the decentralized block storage of the source file ensures that it is not lost. After distribution, a subset of target verification nodes are randomly selected to verify the validity of the file. Feedback is provided upon successful verification, and once the number of feedback messages reaches a threshold, it can be determined that the source file has been successfully stored in the blockchain. Even if multiple nodes in the cluster experience errors or data loss, the decentralized capabilities of multiple nodes can be fully utilized for data recovery. When data recovery is required, it is performed based on the block-encoded data stored on each backup node. Since the number of backup nodes exceeds one-third of the total number of participating nodes, the security and reliability of the source file can be effectively guaranteed even if multiple nodes in the blockchain fail.

[0086] In some embodiments, generating multiple block-coded data based on a source file according to a first number of participating nodes includes: dividing the source file into blocks to obtain a preset number of block data, the preset number being less than a first number; determining multiple redundant coded data corresponding to the source file, and generating a first number of block-coded data based on the preset number of block data and the multiple redundant coded data.

[0087] Specifically, the server divides the acquired source file into a preset number of blocks, such as n blocks. For the same source file, the server also generates multiple redundant encoded data, such as m redundant encoded data. For example, the redundant encoded data can be a Vandermonde matrix or a Cauchy matrix. The server associates the block data with the redundant encoded data to obtain a first number of block encoded data. For example, the first number is the sum of the block data and the redundant encoded data.

[0088] Therefore, by cutting large blocks of data into several data blocks, redundant calculations are performed on these data blocks. The results of the redundant calculations, along with the data blocks themselves, are used to store and write the large block of data. Because redundant calculations are introduced for the data blocks, even if a small number of data blocks are lost, the lost data blocks can be recovered through the results of the redundant calculations.

[0089] For example, such as Figure 6AAs shown, when generating redundant encoded data, the server treats the input data as a vector D = (D1, D2, ..., Dn), and the encoded data as a vector (D1, D2, ..., Dn, C1, C2, ..., Cm). The upper part of the encoding matrix B is an n x n identity matrix, and the lower part is an m x n matrix, such as a Vandermonde matrix or a Cauchy matrix. Any n*n submatrix of the encoding matrix B is invertible. The server divides the source file into n data blocks (n is a positive integer) and calculates m redundant blocks (m is a positive integer) through a redundancy encoding algorithm. The data blocks (i.e., block data) and redundant blocks (i.e., redundant encoded data) serve as the block encoded data of the source file. The server then distributes each (n+m) block encoded data to the participating nodes for storage. By storing the source file in a decentralized manner using block encoded data, only n block encoded data are needed to restore the original source file. Therefore, as long as the number of damaged participating nodes does not exceed m, the source file can be guaranteed not to be lost.

[0090] In the above embodiments, by dividing the source file into blocks and generating corresponding redundant codes, the decentralized function of multiple nodes is fully utilized to store the source file in fragments, reducing the storage space of all nodes in the cluster. Even if a certain number of nodes in the cluster fail or data is lost, the source data can still be guaranteed not to be lost.

[0091] In some embodiments, the feedback information is the validator signature of the target validator node, which indicates that the target validator node has determined that the source file has passed validity verification. Accordingly, receiving feedback information from each target validator node, and determining that the source file has been successfully stored on the blockchain when the number of feedback information indicating that the validity verification has passed reaches a preset threshold, includes: receiving feedback information from each target validator node, the feedback information including the validator signature returned by the target validator node when the validity verification has passed; and determining that the source file has been successfully stored on the blockchain when the number of collected validator signatures reaches a preset threshold.

[0092] Specifically, the target verification node recovers the data based on the block-coded data stored by other participating nodes and performs validity verification. If the verification passes, the target verification node sends a validator signature to the server. For example, the target verification node recovers the data based on the block-coded data stored by other participating nodes and compares the hash value of the recovered source file with the hash value of the original source file. If they match, the validity verification is deemed successful, and the target verification node generates a validator signature corresponding to itself. Once the server has collected enough validator signatures, it indicates that the source file has been successfully stored in the blockchain.

[0093] In the above embodiments, the target verification node returns the verifier signature to indicate that the source file has been successfully stored. After collecting enough verifier signatures, it is confirmed that the source file has indeed been successfully stored on the blockchain. Thus, the security of the source file is guaranteed through a decentralized storage method.

[0094] In some embodiments, the method further includes: in response to a recovery operation on the source file, randomly determining a target backup node from the backup nodes; sending a source file recovery request to the target backup node to instruct the target backup node to perform data recovery based on the block-coded data stored on each backup node other than the target backup node.

[0095] When source file recovery is required, the server responds to the source file recovery operation by randomly determining a target backup node from the backup nodes. In some embodiments, the source file recovery request is used to instruct the target backup node to obtain block-coded data stored in a preset number of backup nodes, including the target backup node, and to perform data recovery based on the distinguished coded data stored in the preset number of backup nodes to obtain the source file.

[0096] Specifically, the target backup node can randomly select other backup nodes and obtain their block encoding data to perform data recovery. In some embodiments, the target backup node can also perform data recovery based on its own stored block encoding data and the block encoding data stored by other backup nodes. Thus, by using the block encoding data stored by backup nodes, which constitute more than one-third of the total number of nodes, data recovery can be performed based on the backup nodes' block encoding data, ensuring the recoverability of the source files.

[0097] For example, the server randomly selects at least one backup node and designates it as the target backup node. The server sends a source file recovery request to the target backup node, and upon receiving the request, the target backup node recovers the data by requesting the stored block-encoded data from other backup nodes.

[0098] In the above embodiments, by setting a certain number of backup nodes, the decentralized nature of multiple nodes is fully utilized. As long as there are more than 1 / 3 of the valid nodes, the source file data can be restored, thus ensuring the security of the source file.

[0099] In some embodiments, the steps for data recovery by the target backup node include: constructing a corresponding intermediate matrix based on the acquired multiple block-coded data, constructing a cell matrix based on the intermediate matrix and the corresponding inverse matrix, and processing based on the cell matrix, the intermediate matrix, and the inverse matrix to obtain the recovered source file.

[0100] To facilitate understanding, the following explanation is illustrated with diagrams. Assume that data from m nodes is lost, such as... Figure 6B As shown in the diagram, if D1, D4, and C2 are lost, the original data D1 to Dn needs to be recovered from the remaining n block encoded data. The target backup node, based on the acquired remaining n block encoded data, removes the corresponding row vectors in the encoding matrix B to form a new matrix, i.e., the intermediate matrix B', as shown below. Figure 6C and Figure 6D As shown. The result of multiplying the intermediate matrix B' by the vector D is the encoded data for the remaining n blocks. Since any n rows of the encoding matrix B are invertible, the intermediate matrix B' has an inverse matrix (B'-1), and the product of the intermediate matrix B' and its inverse matrix (B'-1) is the unit matrix I, as shown. Figure 6E As shown. Therefore, based on the cell matrix, intermediate matrix, and inverse matrix, the target backup node performs mathematical transformations according to the equation relating the product of cell matrix I and the original block-coded data to the product of the inverse matrix B' and the remaining n block-coded data. For example... Figures 6D to 6E By performing equation operations, the complete block encoding data can be obtained, and the source file can then be recovered.

[0101] Therefore, by storing the source file in a decentralized manner using block-encoded data, only n blocks of encoded data are needed to restore the original source file. As long as the number of damaged participating nodes does not exceed m, the source file can be guaranteed not to be lost.

[0102] After the source file has been stored on the blockchain, the corresponding virtual resources (such as digital collectibles) can be issued. To this end, in some embodiments, the method further includes: upon confirming that the source file has been successfully stored on the blockchain, transmitting the source file information to a consensus node to instruct the consensus node to verify the issuance of the source file; the source file information includes at least a source file identifier and encrypted source file data; wherein, upon successful issuance verification, the consensus node annotates the source file information and uploads the annotated source file information to the blockchain, and the source file information is used for sharing within the blockchain to realize the issuance of the virtual resources corresponding to the source file.

[0103] The source file information includes, but is not limited to, one or more of the following: the source file itself, the source file identifier, or encrypted source file data. The source file identifier is a unique identifier used to distinguish the source file from other source files. Encrypted source file data may include, for example, the hash value of the source file.

[0104] Specifically, once the source file has been successfully stored on the blockchain, the server transmits the source file information to the consensus node, instructing the node to verify its issuance. For example, the server transmits the source file identifier and hash value to the consensus node, which then verifies the verifier's signature for issuance verification. If the consensus node determines the verifier's signature is authentic and valid, and the issuance verification is successful, it annotates the source file information and uploads the annotated information to the blockchain, thus issuing the corresponding digital collectible on-chain.

[0105] In some embodiments, consensus nodes may annotate source file information by signing it. Consensus nodes may also specify in smart contracts that digital collectibles stored across the network using block-encoded data possess enhanced security. Thus, by having consensus nodes verify the issuance and, upon successful verification, completing the on-chain issuance of digital collectibles, the reliability and security of the digital collectibles are further guaranteed.

[0106] In some embodiments, the consensus node verifies the issuance of source files by means of: verifying, through a smart contract, whether the source file information has been validated by the verification node; and, if it is determined that the source file information has been validated by the verification node, determining that the issuance verification of the source file has passed. Specifically, the consensus node verifies, through a smart contract, whether the source file information has indeed been validated by the verification node. If the smart contract verification confirms that the source file information has been validated by the verification node, the consensus node determines that the issuance verification of the source file has passed. Therefore, issuing digital collectibles after completing decentralized network storage of the source files ensures that the metadata of the digital collectibles is not lost, thus providing high security.

[0107] In another embodiment, the consensus node's verification of the source file's issuance further includes: obtaining consensus data corresponding to the source file, which is obtained by encrypting the source file's encrypted data; decrypting the consensus data to obtain the source file's verification encrypted data; comparing the verification encrypted data with the source file's encrypted data in the source file's transaction information; and determining that the verification encrypted data matches the source file's encrypted data, thus confirming that the source file's issuance verification has passed. For example, the server encrypts the hash value of the source file and uses it as the source file's consensus data, then sends the consensus data to the consensus node. The consensus node then decrypts the consensus data to obtain the verification encrypted data, i.e., the decrypted hash value. The consensus node then compares the decrypted hash value with the source file's actual hash value; if they match, the consensus node determines that the source file's issuance verification has passed.

[0108] After the virtual resources are issued, virtual resource transactions can be conducted based on the issued virtual resources. In some embodiments, the above method further includes: receiving a resource transfer request sent by a client, the resource transfer request carrying at least a resource identifier of the virtual resource and the wallet address corresponding to the resource recipient; in response to the resource transfer request, invoking a smart contract to change the address to which the virtual resource belongs, corresponding to the resource identifier, to the wallet address corresponding to the resource recipient.

[0109] Specifically, the client initiating the transaction sends a resource transfer request to the server. This request includes at least the resource identifier of the virtual resource to be traded and the wallet address of the resource recipient in the blockchain. Each resource identifier represents a specific virtual resource. Based on the received resource transfer request, the server invokes a smart contract to execute the virtual resource transaction. That is, through the blockchain, the smart contract changes the address of the virtual resource corresponding to the resource identifier (i.e., the address of the initiating party) to the wallet address of the resource recipient. This transfers ownership of the virtual resource from the initiating party to the resource recipient, completing the virtual resource transaction.

[0110] Therefore, virtual resource transactions based on source files stored in a decentralized, block-based manner have higher security and credibility. The virtual resources traded can avoid the risk of loss, thus making the transactions more secure and reliable.

[0111] In some scenarios, not all blockchain participants have sufficient resources and the necessity to participate in the blockchain consensus process. Furthermore, due to data security concerns, the common peer-to-peer blockchain deployment approach is not suitable when dealing with security-related data within the blockchain system. Therefore, in some embodiments, the blockchain can be divided into a witness network and a consensus network. Nodes in the witness network primarily perform business execution and do not participate in consensus logic. Instead, they obtain block header data and partially authorized block data from the consensus network through identity authentication. The witness network and the consensus network operate in different network environments; typically, the witness network resides in a public network, while the consensus network resides in a private network.

[0112] Therefore, in some embodiments, the blockchain includes a witness network with multiple business nodes and a consensus network with multiple participating nodes. The business nodes and the consensus network interact through routing boundaries. Participating nodes may include consensus nodes, verification nodes, and backup nodes. The business nodes are used to obtain encrypted source file data corresponding to the source file from the consensus network and perform business processing based on this encrypted data. For example, a business node obtains block header data and hash values ​​from the consensus nodes in the consensus network through authentication, and performs business processing such as virtual resource transfer, transaction, and accounting based on the hash values.

[0113] Therefore, based on the blockchain network architecture including the witness network and the consensus network, the above method can also be as follows: After confirming that the source file has been successfully stored on the blockchain, the server sends the source file information to the business nodes in the witness network, and the business nodes forward it to the consensus nodes in the consensus network, instructing the consensus nodes to verify the release of the source file. Specific steps and processes are detailed in the aforementioned embodiments and will not be repeated here. By isolating the witness network and the consensus network, the security of the data stored by the participating nodes in the consensus network can be further guaranteed.

[0114] This application also provides an application scenario in which the aforementioned blockchain-based data storage method is applied. Specifically, the application of this blockchain-based data storage method in this scenario is as follows: The server obtains the source file uploaded by the client, determines the number of participating nodes in the blockchain, generates a corresponding number of block-coded data, and distributes it. After the block-coded data is distributed, the client requests verification through the server, and the server randomly determines multiple target verification nodes to perform verification. That is, the target verification node attempts to recover the data by obtaining the block-coded data of other participating nodes and compares the hash values ​​for validity verification. If the validity verification passes, the target verification node returns the verifier signature. When the client collects enough verifier signatures, it is determined that the source file has been successfully stored on the chain. The client then transmits the source file information to the consensus node for on-chain issuance of virtual resources. When it is necessary to recover the source file of the virtual resources later, the client can send a recovery request to the server. The server responds to the recovery operation of the source file by restoring it based on the block-coded data stored in each backup node, thereby recovering the source file. Of course, it is not limited to this. The blockchain-based data storage provided in this application can also be applied to other application scenarios, and there are no restrictions here.

[0115] Therefore, by distributing and storing the source files of virtual resources as block-encoded data across various blockchain nodes, and verifying their validity through a random number of verification nodes, the source files are considered securely stored on the chain if verification passes. This ensures that the source files are not lost, providing high security. Even in the event of node errors or data loss within the cluster, the security of the source files remains guaranteed. Furthermore, by storing block-encoded data, it is not necessary for each node to store the complete source file, thus saving storage resources for each node.

[0116] In a specific example, such as Figure 7 As shown, the aforementioned blockchain-based data storage method may include the following steps: The client sends the source file to be stored on the blockchain to the backend server. The backend server determines the number X of participating nodes (including consensus nodes, verification nodes, and backup nodes), generates X copies of block-encoded data accordingly, and distributes them to each node, for example, by broadcasting to each node. After the block-encoded data distribution is completed, the client requests the verification nodes to perform validity verification. The backend server randomly selects Y verification nodes (target verification nodes) to perform validity verification. For each target verification node y, it randomly requests block-encoded data from other participating nodes and attempts to recover the source file based on the block-encoded data sent by at least three other participating nodes. It then compares the hash value of the recovered source file with the original hash value of the source file. If they match, the target verification node generates a validator signature and transmits the validator signature to the client, for example, by returning it to the backend server, or by the backend server sending it to the client. Based on the number of validator signatures collected, when enough validator signatures are collected, the client sends the source file information to the consensus node through the backend server, and the consensus node verifies the validity of the validator signature. If verification passes, the virtual resources corresponding to the source file will be issued. At the time of issuance, virtual resources that have been stored across the entire network using block-coded data will be specifically marked in the smart contract as having higher security.

[0117] In one scenario, the blockchain is divided into a witness network and a consensus network. When enough validator signatures are collected, the client sends the source file information to the business node via the backend server. The business node then forwards the information to the consensus node via routing, and the consensus node performs subsequent operations. In some embodiments, the source file of the virtual resource can also be backed up off-chain.

[0118] Therefore, since the source files of virtual resources are stored off-chain and are at risk of loss, storing them in a decentralized, block-based manner, such as through block-encoded data storage, ensures that the source files of virtual resources are not lost, even if a certain number of nodes in the cluster fail or data is lost. Furthermore, since virtual resources may exist in various formats such as images, audio, and video, they occupy a significant amount of storage space. Backing up the source files on each node would consume a large amount of storage space, while storing only a few copies in the cluster carries the risk of data corruption or loss. The above method further reduces the storage space required for all data storage nodes in the cluster and fully utilizes the decentralized capabilities of multiple nodes; as long as more than one-third of the nodes remain active, data can be recovered.

[0119] It should be understood that although the steps in the flowcharts of the above embodiments are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the above embodiments may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0120] Based on the same inventive concept, this application also provides a blockchain-based data storage device for implementing the blockchain-based data storage method described above. The solution provided by this device is similar to the implementation described in the above method; therefore, the specific limitations in one or more embodiments of the blockchain-based data storage device provided below can be found in the limitations of the blockchain-based data storage method described above, and will not be repeated here.

[0121] In some embodiments, such as Figure 8 As shown, a blockchain-based data storage device 800 is provided, including: an acquisition module 801, a generation module 802, a determination module 803, a verification module 804, a storage module 805, and a recovery module 806. Wherein:

[0122] The acquisition module 801 is used to acquire the source file and determine the first number of participating nodes in the blockchain. The participating nodes include at least verification nodes, consensus nodes and backup nodes, wherein the number of backup nodes exceeds one-third of the first number.

[0123] The generation module 802 is used to generate multiple block encoding data according to the first number of participating nodes and based on the source file, and distribute the multiple block encoding data to each participating node one by one.

[0124] The determination module 803 is used to randomly determine a second number of target verification nodes from the verification nodes.

[0125] The verification module 804 is used to send verification requests to each target verification node, instructing each target verification node to perform validity verification based on the block encoding data stored by a preset number of participating nodes.

[0126] The storage module 805 is used to receive feedback information from each target verification node. When the number of feedback messages that represent the validity verification has reached a preset threshold, it is determined that the source file has been successfully stored on the blockchain.

[0127] The recovery module 806 is used to perform data recovery based on the block-coded data stored in each backup node in response to the recovery operation of the source file.

[0128] In some embodiments, the generation module is further configured to divide the source file into blocks to obtain a preset number of block data, the preset number being less than a first number; determine multiple redundant encoded data corresponding to the source file, and generate a first number of block encoded data based on the preset number of block data and the multiple redundant encoded data.

[0129] In some embodiments, the verification request is used to instruct each target verification node to randomly select a preset number of participating nodes, and to restore the file based on the block encoding data stored by the randomly selected preset number of participating nodes, and to determine the restored file signature of the restored file. If the restored file signature is consistent with the source file signature of the source file, the validity verification is determined to be successful.

[0130] In some embodiments, the storage module is further configured to receive feedback information from each target verification node, including the verifier signature returned by the target verification node when the validity verification is confirmed to be successful; and to determine that the source file has been successfully stored on the blockchain when the number of collected verifier signatures reaches a preset threshold.

[0131] In some embodiments, the recovery module is further configured to, in response to a recovery operation on the source file, randomly determine a target backup node from the backup nodes; and send a source file recovery request to the target backup node to instruct the target backup node to perform data recovery based on the block-coded data stored on each backup node other than the target backup node.

[0132] In some embodiments, the source file recovery request is used to instruct the target backup node to obtain the block-coded data stored in a preset number of backup nodes, including the target backup node, and to perform data recovery based on the obtained differential-coded data stored in the preset number of backup nodes to obtain the source file.

[0133] In some embodiments, the source file recovery request is used to instruct the target backup node to construct a corresponding intermediate matrix based on the acquired multiple block-coded data, construct a cell matrix based on the intermediate matrix and the corresponding inverse matrix, and process the cell matrix, intermediate matrix, and inverse matrix to obtain the recovered source file.

[0134] In some embodiments, the apparatus further includes an issuance module, configured to transmit the source file information of the source file to the consensus node when it is determined that the source file has been successfully stored on the blockchain, so as to instruct the consensus node to verify the issuance of the source file; the source file information includes at least a source file identifier and encrypted source file data; wherein, when the issuance verification is passed, the consensus node marks the source file information and uploads the marked source file information to the blockchain, and the source file information is used to share in the blockchain to realize the issuance of the virtual resources corresponding to the source file.

[0135] In some embodiments, the consensus node verifies the issuance of the source file by: verifying through a smart contract whether the source file information has been validated by the verification node; and if it is determined that the source file information has been validated by the verification node, determining that the issuance verification of the source file has passed.

[0136] In some embodiments, the blockchain includes a witness network with multiple business nodes and a consensus network with multiple participating nodes. The business nodes are used to obtain encrypted source file data corresponding to the source file from the consensus network and perform business processing based on the encrypted source file data.

[0137] In some embodiments, the device further includes a transaction module for receiving a resource transfer request sent by a client, wherein the resource transfer request carries at least a resource identifier of the virtual resource and a wallet address corresponding to the resource recipient; and in response to the resource transfer request, calling a smart contract to change the address to which the virtual resource corresponding to the resource identifier belongs to the wallet address corresponding to the resource recipient.

[0138] The modules in the aforementioned blockchain-based data storage device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device, or stored in the memory of a computer device as software, so that the processor can invoke and execute the operations corresponding to each module.

[0139] In some embodiments, a computer device is provided, which may be a server as described in the foregoing embodiments, and its internal structure diagram may be as follows. Figure 9 As shown, this computer device includes a processor, memory, input / output interfaces (I / O), and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides the environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The database stores source file data. The I / O interfaces are used for exchanging information between the processor and external devices. The communication interface is used for communicating with external terminals via a network connection. When the computer program is executed by the processor, it implements a blockchain-based data storage method.

[0140] Those skilled in the art will understand that Figure 9 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0141] In some embodiments, a computer device is also provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above method embodiments.

[0142] In some embodiments, a computer-readable storage medium is provided having a computer program stored thereon that, when executed by a processor, implements the steps in the above method embodiments.

[0143] In some embodiments, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in the above method embodiments.

[0144] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc., and are not limited to these.

[0145] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0146] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A data storage method based on blockchain, characterized in that, The method includes: Obtain the source file and determine the first number of participating nodes in the blockchain, wherein the participating nodes include at least validator nodes, consensus nodes and backup nodes, and the number of backup nodes exceeds one-third of the first number; The source file is divided into blocks to obtain a preset number of block data, where the preset number is less than the first number; Determine multiple redundant encoded data corresponding to the source file, and generate a first number of block encoded data based on the preset number of block data and the multiple redundant encoded data; Distribute the first number of block-coded data to each participating node; A second number of target verification nodes are randomly selected from the verification nodes; A verification request is sent to each of the target verification nodes to instruct each target verification node to perform validity verification based on the block-coded data stored by no less than a preset number of participating nodes. Receive feedback information from each target verification node, and determine that the source file has been successfully stored on the blockchain when the number of feedback information indicating that the validity verification has passed reaches a preset threshold. In response to the recovery operation of the source file, data recovery is performed based on the block-coded data stored in each backup node.

2. The method according to claim 1, characterized in that, The verification request is used to instruct each target verification node to randomly select no less than a preset number of participating nodes, and to restore the file based on the block encoding data stored by the randomly selected no less than a preset number of participating nodes, and to determine the restored file signature. If the restored file signature is consistent with the source file signature of the source file, the validity verification is determined to be successful.

3. The method according to claim 1, characterized in that, The step of receiving feedback information from each target verification node, and determining that the source file has been successfully stored on the blockchain when the number of feedback messages indicating successful validity verification reaches a preset threshold, includes: Receive feedback information from each target verification node, the feedback information including the verifier signature returned by the target verification node when the validity verification is determined to be successful; If the number of validator signatures collected reaches a preset threshold, it is determined that the source file has been successfully stored on the blockchain.

4. The method according to claim 1, characterized in that, The method further includes: In response to the recovery operation of the source file, a target backup node is randomly determined from the backup nodes; A source file recovery request is sent to the target backup node to instruct the target backup node to perform data recovery based on the block-coded data stored by each backup node.

5. The method according to claim 4, characterized in that, The source file recovery request is used to instruct the target backup node to obtain block-coded data stored in a preset number of backup nodes, including the target backup node, and to perform data recovery based on the obtained preset number of backup nodes' block-coded data to obtain the source file.

6. The method according to claim 5, characterized in that, The source file recovery request is used to instruct the target backup node to construct a corresponding intermediate matrix based on the acquired multiple block encoding data, construct a cell matrix based on the intermediate matrix and the corresponding inverse matrix, and process the cell matrix, the intermediate matrix, and the inverse matrix to obtain the recovered source file.

7. The method according to claim 1, characterized in that, The method further includes: If it is determined that the source file has been successfully stored on the blockchain, the source file information of the source file is transmitted to the consensus node to instruct the consensus node to issue and verify the source file; the source file information includes at least the source file identifier and the encrypted source file data; In this process, once the issuance verification is passed, the consensus node marks the source file information and uploads the marked source file information to the blockchain. The source file information is used to share in the blockchain to realize the issuance of the virtual resources corresponding to the source file.

8. The method according to claim 7, characterized in that, The consensus node verifies the issuance of the source file by means of: verifying whether the source file information has been validated by the verification node through a smart contract; and determining that the issuance verification of the source file has passed if it is determined that the source file information has been validated by the verification node.

9. The method according to claim 7, characterized in that, The method further includes: Receive a resource transfer request sent by the client, wherein the resource transfer request carries at least the resource identifier of the virtual resource and the wallet address corresponding to the resource recipient; In response to the resource transfer request, a smart contract is invoked to change the address of the virtual resource corresponding to the resource identifier to the wallet address corresponding to the resource recipient.

10. The method according to any one of claims 1 to 9, characterized in that, The blockchain includes a witness network with multiple business nodes and a consensus network with multiple participating nodes. The business nodes are used to obtain encrypted source file data corresponding to the source file from the consensus network and perform business processing based on the encrypted source file data.

11. A blockchain-based data storage device, characterized in that, The device includes: The acquisition module is used to acquire the source file and determine the first number of participating nodes in the blockchain. The participating nodes include at least verification nodes, consensus nodes, and backup nodes, wherein the number of backup nodes exceeds one-third of the first number. The generation module is used to divide the source file into blocks to obtain a preset number of block data, the preset number being less than the first number; determine multiple redundant encoded data corresponding to the source file, and generate a first number of block encoded data based on the preset number of block data and the multiple redundant encoded data; and distribute the first number of block encoded data to each participating node. A determining module is used to randomly determine a second number of target verification nodes from the verification nodes; The verification module is used to send verification requests to each of the target verification nodes, so as to instruct each of the target verification nodes to perform validity verification based on the block encoding data stored by no less than a preset number of participating nodes; The storage module is used to receive feedback information from each target verification node. When the number of feedback information indicating that the validity verification has passed reaches a preset threshold, it is determined that the source file has been successfully stored on the blockchain. The recovery module is used to perform data recovery based on the block-coded data stored in each backup node in response to the recovery operation of the source file.

12. The blockchain-based data storage device according to claim 11, characterized in that, The verification request is used to instruct each target verification node to randomly select no less than a preset number of participating nodes, and to restore the file based on the block encoding data stored by the randomly selected no less than a preset number of participating nodes, and to determine the restored file signature. If the restored file signature is consistent with the source file signature of the source file, the validity verification is determined to be successful.

13. The blockchain-based data storage device according to claim 11, characterized in that, The storage module is also used to receive feedback information from each target verification node, including the verifier signature returned by the target verification node when the validity verification is confirmed to be passed; and to determine that the source file has been successfully stored on the blockchain when the number of collected verifier signatures reaches a preset threshold.

14. The blockchain-based data storage device according to claim 11, characterized in that, The recovery module is also configured to, in response to a recovery operation on the source file, randomly determine a target backup node from the backup nodes; and send a source file recovery request to the target backup node to instruct the target backup node to perform data recovery based on the block-coded data stored in each backup node.

15. The blockchain-based data storage device according to claim 14, characterized in that, The source file recovery request is used to instruct the target backup node to obtain block-coded data stored in a preset number of backup nodes, including the target backup node, and to perform data recovery based on the obtained preset number of backup nodes' block-coded data to obtain the source file.

16. The blockchain-based data storage device according to claim 15, characterized in that, The source file recovery request is used to instruct the target backup node to construct a corresponding intermediate matrix based on the acquired multiple block encoding data, construct a cell matrix based on the intermediate matrix and the corresponding inverse matrix, and process the cell matrix, the intermediate matrix, and the inverse matrix to obtain the recovered source file.

17. The blockchain-based data storage device according to claim 11, characterized in that, The device further includes an issuance module, used to transmit the source file information of the source file to a consensus node when it is determined that the source file has been successfully stored on the blockchain, so as to instruct the consensus node to verify the issuance of the source file; the source file information includes at least a source file identifier and encrypted source file data; wherein, when the issuance verification is passed, the consensus node marks the source file information and uploads the marked source file information to the blockchain, and the source file information is used to share in the blockchain to realize the issuance of the virtual resources corresponding to the source file.

18. The blockchain-based data storage device according to claim 17, characterized in that, The consensus node verifies the issuance of the source file by means of: verifying whether the source file information has been validated by the verification node through a smart contract; and determining that the issuance verification of the source file has passed if it is determined that the source file information has been validated by the verification node.

19. The blockchain-based data storage device according to claim 17, characterized in that, The device further includes a transaction module for receiving a resource transfer request sent by a client. The resource transfer request carries at least a resource identifier of the virtual resource and a wallet address corresponding to the resource recipient. In response to the resource transfer request, a smart contract is invoked to change the address of the virtual resource corresponding to the resource identifier to the wallet address corresponding to the resource recipient.

20. The blockchain-based data storage device according to any one of claims 11 to 19, characterized in that, The blockchain includes a witness network with multiple business nodes and a consensus network with multiple participating nodes. The business nodes are used to obtain encrypted source file data corresponding to the source file from the consensus network and perform business processing based on the encrypted source file data.

21. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 10.

22. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 10.

23. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 10.

Images