Data storage method in blockchain, transaction reading method, node and system

Abstract

A method for storing data in a blockchain, a method for reading a transaction, a blockchain node and a blockchain system, the method for storing data in a blockchain comprises: receiving a data upload request from a user device, the file upload request comprising first data to be uploaded and information of the first data; generating n data blocks, each data block comprising part of the first data and information of the first data; generating n transactions based on the n data blocks; and storing the n transactions in the blockchain.

Description

Technical Field

[0001] The embodiments in this specification belong to the field of blockchain technology, and in particular relate to a method for storing data in a blockchain, a method for reading transactions, nodes, and a blockchain system. Background Technology

[0002] Blockchain is a novel application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanisms, and cryptographic algorithms. In a blockchain system, data blocks are sequentially linked together to form a chain-like data structure, and a distributed ledger is cryptographically guaranteed to be immutable and unforgeable. Due to its decentralized, immutable, and autonomous characteristics, blockchain is receiving increasing attention and application. Summary of the Invention

[0003] The purpose of this invention is to provide a method for storing data in a blockchain to ensure the acquisition of authentic data.

[0004] The first aspect of this specification provides a method for storing data in a blockchain, executed by the first node in the blockchain, including:

[0005] Receive a data upload request from the user equipment, wherein the data upload request includes first data to be uploaded and information about the first data;

[0006] Generate n data blocks, each data block including a portion of the first data and information about the first data;

[0007] n transactions are generated based on the n data blocks;

[0008] The n transactions are stored in the blockchain.

[0009] In one implementation, the n transactions use the user's first account as the sending account, and generating the n transactions based on the n data blocks includes: generating transaction bodies of the n transactions based on the n data blocks; sending the transaction bodies of the n transactions to the user equipment; receiving the user's signature on the n transaction bodies from the user equipment; and obtaining the n transactions based on the n transaction bodies and their signatures.

[0010] In one implementation, the information of the first data includes at least one of the following: the identifier of the first data, the upload time, and the data owner.

[0011] In one implementation, the method further includes: returning a list of hash values ​​of the n transactions to the user device.

[0012] In one embodiment, the method further includes: storing the correspondence between the identifier of the first data and the list of hash values ​​of the n transactions.

[0013] In one implementation, the method further includes: in response to a query request for the first data, reading the n transactions according to a list of hash values ​​of the n transactions; obtaining n data blocks from the n transactions; generating the first data based on the n data blocks; and returning the first data.

[0014] In one implementation, the query request includes a list of hash values ​​for the n transactions.

[0015] In one implementation, the information in the first data further includes a first signature of the user's first account on the first data, and the method further includes obtaining the first signature from the n transactions after generating the first data, and verifying the first data based on the first signature.

[0016] In one implementation, storing the n transactions in the blockchain includes: sending the n transactions to the blockchain to enable execution of the n transactions in the blockchain; in response to the completion of the n transactions, converting the n transactions into k+m shards according to an erasure coding algorithm, wherein the k+m shards include k data shards and m verification shards; and distributing and storing the k+m shards among t second nodes in the blockchain.

[0017] In one implementation, the n transactions belong to at least one block, and the step of converting the n transactions into k+m shards includes converting the n transactions into k+m shards after the execution of the at least one block is completed. The method further includes storing the block header of the at least one block into each second node.

[0018] In one implementation, distributing and storing the k+m shards across t second nodes in the blockchain includes storing at least one of the shards in association with a list of hash values ​​of the n transactions in each second node.

[0019] In one implementation, generating n data blocks based on the first data includes: encoding the first data, dividing the encoded second data into n parts, adding information from the first data to each part, and obtaining the n data blocks.

[0020] A second aspect of this specification provides a method for reading transactions in a blockchain, wherein the blockchain includes t second nodes, and the t second nodes distribute and store k+m shards, wherein the k+m shards include k data shards and m verification shards, and the k+m shards correspond to n transactions. The method includes:

[0021] Read at least k fragments from the k+m fragments from at least a portion of the t second nodes;

[0022] The n transactions are recovered based on the at least k shards.

[0023] In one implementation, each of the second nodes also stores the block header of the block to which the n transactions belong. The method is executed by any of the second nodes, and the method further includes: performing simple payment verification on the target transaction in the block based on at least one of the n transactions and the block header.

[0024] A third aspect of this specification provides a blockchain system, comprising a first node and t second nodes.

[0025] The first node is configured to: receive a data upload request from a user device, the data upload request including first data to be uploaded and information of the first data; generate n data blocks, each data block including partial data of the first data and information of the first data; generate n transactions based on the n data blocks; send the n transactions to the blockchain; in response to the completion of the n transactions, convert the n transactions into k+m shards according to the erasure coding algorithm, the k+m shards including k data shards and m verification shards; and distribute and store the k+m shards among t second nodes in the blockchain.

[0026] Any of the second nodes is used to: read at least k shards from at least a portion of the t second nodes; and recover the n transactions based on the at least k shards.

[0027] The fourth aspect of this specification provides a blockchain node, including:

[0028] A receiving unit is configured to receive a data upload request from a user equipment, wherein the data upload request includes first data to be uploaded and information about the first data.

[0029] A generation unit is used to generate n data blocks, each data block including a portion of the first data and information about the first data; and to generate n transactions based on the n data blocks.

[0030] A storage unit is used to store the n transactions into the blockchain.

[0031] The fifth aspect of this specification provides a blockchain node, including:

[0032] A reading unit is configured to read at least k shards from at least a portion of the t second nodes, wherein the t second nodes distribute and store k+m shards, the k+m shards include k data shards and m verification shards, and the k+m shards correspond to the n transactions;

[0033] A recovery unit is used to recover the n transactions based on the at least k shards.

[0034] A sixth aspect of this specification provides a computer-readable storage medium having a computer program stored thereon, which, when executed in a computer, causes the computer to perform the methods described in the first or second aspect.

[0035] The seventh aspect of this specification provides a blockchain node, including a memory and a processor, wherein the memory stores executable code, and when the processor executes the executable code, it implements the method described in the first or second aspect.

[0036] In the solution provided in the embodiments of this specification, the user-uploaded data is divided into multiple data blocks by blockchain nodes, and the data is stored in the blockchain through multiple transactions, thereby ensuring the acquisition of real data. Attached Figure Description

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

[0038] Figure 1 This is a diagram of a blockchain architecture in one embodiment;

[0039] Figure 2 This is a flowchart illustrating a method for storing files in a blockchain, as described in an embodiment of this specification.

[0040] Figure 3 This is a schematic diagram illustrating the process of generating multiple transactions based on files in a full node, as described in the embodiments of this specification.

[0041] Figure 4 This is a schematic diagram of the block header data structure in the embodiments of this specification;

[0042] Figure 5This is a schematic diagram illustrating the process by which a full node stores transaction shards across multiple light nodes in an embodiment of this specification.

[0043] Figure 6 This is a flowchart illustrating the method for reading transactions from a light node in the embodiments of this specification;

[0044] Figure 7 This is an architecture diagram of a blockchain node in one of the embodiments of this specification;

[0045] Figure 8 This is an architecture diagram of a blockchain node in one of the embodiments of this specification. Detailed Implementation

[0046] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this specification.

[0047] Figure 1 A blockchain architecture diagram from one embodiment is shown. Figure 1 In the blockchain architecture diagram shown, blockchain 100 includes N nodes. Figure 1 The diagram illustrates nodes 1 through 6. The connections between nodes schematically represent P2P (Peer-to-Peer) connections, such as TCP connections, used for data transfer between nodes. These nodes may include full nodes and light nodes. Full nodes store the entire ledger, i.e., the state of all blocks and all accounts. Each full node in the blockchain can produce the same state by executing the same transactions, and each full node stores the same state database. Light nodes have fewer storage and computational resources and typically do not store the entire ledger. For example, a light node may store the block headers of various blocks in the blockchain, allowing it to verify transactions or states in the blockchain using the Simplified Payment Verification (SPV) method. Light nodes can verify whether a transaction is included in a block using the SPV algorithm without downloading the entire blockchain ledger.

[0048] In the blockchain field, a transaction refers to a unit of task executed and recorded within the blockchain. A transaction typically includes a From field, a To field, and a Data field. Specifically, in the case of a transfer transaction, the From field represents the account address initiating the transaction (i.e., initiating a transfer task to another account), the To field represents the account address receiving the transaction (i.e., receiving the transfer), and the Data field includes the transfer amount.

[0049] Blockchain provides the functionality of smart contracts. A smart contract on the blockchain is a contract that can be triggered and executed through transactions within the blockchain system. Smart contracts can be defined in the form of code. Calling a smart contract on the blockchain involves initiating a transaction pointing to the smart contract's address, causing each node in the blockchain to run the smart contract code in a distributed manner.

[0050] Currently, blockchain has solved the problems of data and evidence verification and tamper-proofing in many industries and fields. However, for on-chain solutions involving large original files such as videos, images, and contracts, it only effectively identifies whether the original data has been tampered with, and cannot meet the requirement of tracing the original authentic file. For example, in some fields, in addition to proving that the data has not been tampered with, it is also necessary to restore the original authentic data after it has been modified. The current solution is to calculate the digital fingerprint (hash or MD5) of multimedia files, store the digital fingerprint in the blockchain, and store the original file on a private file server, cloud file server, or distributed storage system. This is suitable for storing massive amounts of files. File transfer is carried out off-chain, and the file fingerprint is calculated and compared with on-chain information to achieve authenticity. However, this solution has some limitations: on-chain files can be verified, but if the file is modified or the external storage server has a storage error, the consensus node has not stored the file, and the authentic file cannot be guaranteed.

[0051] To address the above issues, this specification provides a blockchain file storage and verification scheme. This specification does not use a third-party storage system, but stores part of the file data through multiple transactions, while putting the entire file on the blockchain. Furthermore, for nodes with low storage performance (such as light nodes), erasure coding (EC) is used for block storage to reduce the storage amount per node.

[0052] Figure 2 This is a flowchart illustrating a method for storing files in a blockchain, as described in an embodiment of this specification. This method can be executed by a full node in the blockchain; the following description uses node 1 as an example.

[0053] like Figure 2 As shown, firstly, in S201, the user equipment sends a file upload request to node 1.

[0054] The user's device has a blockchain client installed. Through this client, the user can call the file upload interface to send file upload requests to nodes in the blockchain.

[0055] The file upload request may include, for example, the file to be uploaded, a file identifier, and a file owner identifier. In one implementation, the owner identifier is the user's blockchain account, and the file upload request may also include the user's signature of the file using the private key corresponding to their blockchain account, for file verification. The file may be an image, video, etc., and may be in binary data format.

[0056] In S203, the node generates n data blocks based on the file.

[0057] Node 1 is a node in the blockchain connected to the user's device; the deployed node code enables it to execute actions such as... Figure 2 The method flow is shown.

[0058] Figure 3 This is a schematic diagram illustrating the process of generating multiple transactions based on files in a full node, as described in the embodiments of this specification. References below... Figure 3 Describe the processing procedure in a full node.

[0059] Files uploaded by user devices are typically large, such as tens of megabytes. However, the size of a transaction in a blockchain is limited by the block size. If the maximum block size is 1MB, files larger than 1MB need to be divided into blocks, meaning the file needs to be divided into n equal blocks, with each block size less than the maximum block size. Specifically, node 1 can first encode the file using a preset encoding algorithm (such as base64 encoding) to obtain the encoded file data. Then, refer to... Figure 3 Node 1 can divide file data into, for example, n file blocks, such as file blocks f1-fn.

[0060] Then, node 1 can add key information about the file, such as file identifier, file owner identifier, and file upload time, to each file block, thereby obtaining n data blocks d1-dn. In one implementation, node 1 can also add the user's signature on the file to each file block for file verification.

[0061] Then, Node 1 can generate n transaction bodies Tx1-Txn. Each transaction body's sending account is, for example, a user's blockchain account, and the data field of the transaction body includes a data block. After generating the n transaction bodies Tx1-Txn, Node 1 can send the n transaction bodies and their transaction hash value list to the user device. The user device can use the transaction hash value list to verify each transaction body and sign each of the n transaction bodies using the private key corresponding to the user account, obtaining the signatures of each of the n transactions, and then sending the signatures of the n transactions to Node 1. Thus, Node 1 generates complete transactions Tx1-Txn. The user device can store the hash value list of the transaction bodies Tx1-Txn for reading transactions Tx1-Txn from the blockchain. In one implementation, Node 1 can store the correspondence between the identifier of transaction Tx1-Txn and its transaction body hash value list, thereby enabling it to read transactions Tx1-Txn in response to user query requests based on this correspondence.

[0062] It is understood that Node 1 is not limited to making the sending account of each transaction the user's blockchain account. For example, Node 1 can also use other preset blockchain accounts as the sending accounts of these transactions.

[0063] In S207, node 1 stores n transactions into the blockchain.

[0064] Specifically, Node 1 first sends n transactions to the blockchain, broadcasting these n transactions within the blockchain. Multiple consensus nodes in the blockchain can reach a consensus on these n transactions, and after successful consensus, each full node in the blockchain executes these n transactions. Here, the consensus nodes are full nodes. After executing the n transactions, each full node generates at least one block based on these n transactions. Each block includes a block header and a block body. The block body of the at least one block includes the n transactions.

[0065] Figure 4 This is a schematic diagram of the block header data structure in the embodiments of this specification. For example... Figure 4As shown, the block header of each block in the blockchain includes several fields, such as the previous block hash (prev Hash in the diagram), the nonce, the timestamp, the block number, the state tree root hash (State_Root), the transaction tree root hash (Transaction_Root), and the receipt tree root hash (Receipt_Root). The Prev Hash in the block header points to the previous block, which is the block hash value of the previous block (i.e., the hash value of the block header). In this way, the blockchain achieves locking of the previous block by the next block through the block header. Specifically, state_root is the value of the root node of the state tree (state trie) composed of the states of all accounts in the current block, such as an MPT tree (Merkle Patricia Tree). Transaction_Root is the value of the root node of the transaction tree composed of all transactions included in the current block.

[0066] Node 1 stores n transactions in the blockchain by storing at least one of the aforementioned blocks in the block database. The at least one block may also include other transactions besides the n transactions.

[0067] In S209, the user equipment sends a file query request to node 1.

[0068] In one implementation, as described above, node 1 stores the correspondence between the file identifier of the aforementioned file and the transaction hash list of n transactions. In this case, the file identifier of the file to be queried may be included in the file query request.

[0069] In another implementation, as described above, the user equipment stores a list of transaction hashes for n transactions corresponding to the file, so that the file query request may include the list of transaction hashes for the n transactions.

[0070] In S213, node 1 reads n transactions based on the transaction hash list.

[0071] In the first scenario described above, Node 1 can obtain the transaction hash list of n transactions corresponding to the file to be queried, based on the correspondence between the file identifier and the transaction hash list stored locally. In the second scenario, Node 1 can obtain the transaction hash list of n transactions corresponding to the file from the file query request.

[0072] After obtaining a list of transaction hashes for n transactions, Node 1 can read the transaction corresponding to each hash value from the block database, such as... Figure 3 As shown, the transaction includes data block di.

[0073] In S213, node 1 obtains n data blocks from n transactions.

[0074] After reading n transactions as described above, node 1 obtains data block di from each transaction, thereby obtaining n data blocks d1-dn.

[0075] In S215, node 1 generates a file based on n data blocks.

[0076] Node 1 obtains n file blocks f1-fn from n data blocks, concatenates the n file blocks f1-fn together, and decodes the concatenated data using a preset decoding algorithm to generate a file.

[0077] Node 1 can also retrieve file information from any data block, verifying whether the account sending the file query request is the file owner listed in the file information. Node 1 can also retrieve the file signature from the file information and use the user account's public key to verify the generated file based on the file signature, thereby verifying the correctness and integrity of the generated file.

[0078] In S215, node 1 returns the file to the user device.

[0079] In addition to storing at least one block in itself, Node 1 can also store at least one block in multiple light nodes. Since light nodes have limited storage resources, in cases where the data volume of the n transactions is large, Node 1 can store the block header of each block in each light node. Simultaneously, Node 1 can convert the n transactions into multiple shards based on the EC algorithm and distribute these shards across multiple light nodes.

[0080] According to the EC algorithm, m check fragments can be calculated based on k data fragments. These k+m fragments can be stored in different light nodes. When it is necessary to read k data fragments, only at least k fragments need to be read from the k+m fragments to recover the data fragments. That is, the loss of any m fragments from the k+m fragments is allowed.

[0081] Figure 5 This is a schematic diagram illustrating the process by which a full node stores transaction shards across multiple light nodes in an embodiment of this specification.

[0082] like Figure 5 As shown, after a full node (e.g., node 1) completes the execution of at least one block including transactions Tx1-Txn, it can divide transactions Tx1-Txn into k data fragments. Specifically, transactions Tx1-Txn can be concatenated into a single data set, and this data set can be divided into k parts, thus obtaining k data fragments. In one implementation, each transaction can be treated as a data fragment, i.e., k = n.

[0083] Next, Node 1 generates m verification shards based on k data shards. Then, Node 1 distributes the k+m shards to, for example, t light nodes, where t is less than or equal to k+m. Each light node can store at least one of the k+m shards. When distributing shards to light nodes, Node 1 can send a list of transaction hashes for transactions Tx1-Txn along with the shards, allowing the light nodes to store the shards in association with the transaction hash list. Simultaneously, Node 1 also stores the block headers of at least one block in each light node. If the at least one block also includes other transactions with smaller amounts of data, Node 1 also sends these smaller transactions to the light nodes. Thus, when performing SPV verification on a target transaction in the at least one block, each light node can obtain any transaction in that block and perform SPV verification on the target transaction.

[0084] Figure 6 This is a flowchart illustrating the method for reading transactions from a light node in an embodiment of this specification. This method can be executed by any one of the t light nodes; it is understood that this method can also be executed by all nodes, and this is not limited here. The following description uses light node 1 executing this method as an example.

[0085] like Figure 6 As shown, in S601, light node 1 reads at least k shards from at least some of the t light nodes.

[0086] When a light node receives a verification request from a user device for a target transaction in a target block (e.g., block B1), assuming block B1 contains the aforementioned n transactions, and may also contain other transactions with smaller amounts of data, as described above, light node 1-t stores k+m shards, and each light node stores the aforementioned k+m shards in association with a list of hash values ​​for the n transactions. Light node 1 can read at least one shard from its own stored k+m shard account based on the list of hash values ​​for the aforementioned n transactions, and can also read at least one shard from other light nodes using the list of hash values ​​for the aforementioned n transactions. Light node 1 can stop reading other shards once it has read at least k shards.

[0087] In S603, light node 1 recovers n transactions based on at least k shards.

[0088] Taking k=n as an example, where each data shard is one of transactions Tx1-Txn, if light node 1 reads n data shards from various light nodes, then light node 1 directly obtains n transactions. If light node 1 reads p data shards and q verification shards from various light nodes, where p+q=n, then light node 1 can recover n transactions based on the EC algorithm using p data shards and q verification shards.

[0089] After recovering n transactions, light node 1 can perform SPV verification on the target transaction based on these n transactions and the transaction root in the block header corresponding to these n transactions. Specifically, after receiving the hash value of the target transaction from block B1 from the user equipment, light node 1 can calculate the value of the root node of the transaction tree based on the transaction tree of multiple transactions in block B1, the hash value of the target transaction, and the transactions associated with the transaction tree path of the target transaction. The associated transactions may include at least one of the n transactions. Then, light node 1 compares the calculated root node value with the Transaction_Root in the block header of block B1. If they match, the SPV verification of the target transaction passes.

[0090] Figure 7 This is an architecture diagram of a blockchain node according to an embodiment of this specification. The blockchain node is used to perform actions such as... Figure 2 The method shown includes:

[0091] Receiving unit 71 is configured to receive a data upload request from a user equipment, wherein the file upload request includes first data to be uploaded and information about the first data;

[0092] The generation unit 72 is used to generate n data blocks, each data block including a portion of the first data and information of the first data; and to generate n transactions based on the n data blocks;

[0093] Storage unit 73 is used to store the n transactions into the blockchain.

[0094] In one implementation, the n transactions use the user's first account as the sending account, and the generation unit 72 is specifically used to: generate transaction bodies of n transactions based on the n data blocks; send the transaction bodies of the n transactions to the user equipment; receive the user's signature on the n transaction bodies from the user equipment; and obtain the n transactions based on the n transaction bodies and their signatures.

[0095] In one implementation, the information of the first data includes at least one of the following: the identifier of the first data, the upload time, and the data owner.

[0096] In one implementation, the blockchain node further includes a return unit for returning a list of hash values ​​of the n transactions to the user device.

[0097] In one embodiment, the storage unit is further configured to store the correspondence between the identifier of the first data and the list of hash values ​​of the n transactions.

[0098] In one implementation, the blockchain node further includes:

[0099] A reading unit is configured to, in response to a query request for the first data, read the n transactions according to the list of hash values ​​of the n transactions;

[0100] The acquisition unit is used to acquire n data blocks from the n transactions;

[0101] The generation unit is also configured to generate the first data based on the n data blocks;

[0102] The return unit is also used to return the first data.

[0103] In one implementation, the query request includes a list of hash values ​​for the n transactions.

[0104] In one implementation, the information in the first data further includes a first signature of the user's first account on the first data, and the acquisition unit is further configured to, after generating the first data, obtain the first signature from the n transactions and verify the first data based on the first signature.

[0105] In one embodiment, the storage unit is specifically used for:

[0106] Send the n transactions to the blockchain so that the n transactions are executed in the blockchain;

[0107] In response to the completion of the n transactions, the n transactions are converted into k+m shards according to the erasure coding algorithm, and the k+m shards include k data shards and m verification shards;

[0108] The k+m shards are distributed and stored in t second nodes in the blockchain.

[0109] In one implementation, the n transactions belong to at least one block, and the storage unit is specifically used to convert the n transactions into k+m shards after the at least one block is executed, and to store the block header of the at least one block in each second node.

[0110] In one implementation, the storage unit is further configured to store at least one of the shards in association with a list of hash values ​​of the n transactions in each of the second nodes.

[0111] In one embodiment, the generation unit is specifically used to: encode the first data, divide the encoded second data into n parts, add the information of the first data to each part, and obtain the n data blocks.

[0112] Figure 8 This is an architecture diagram of a blockchain node according to an embodiment of this specification. The blockchain node is used to perform actions such as... Figure 6 The method shown includes:

[0113] The reading unit 81 is used to read at least k shards from at least some of the t second nodes, wherein the t second nodes distribute and store k+m shards, the k+m shards include k data shards and m verification shards, and the k+m shards correspond to the n transactions;

[0114] Recovery unit 82 is used to recover the n transactions based on the at least k shards.

[0115] In one implementation, each of the second nodes further stores the block headers of the blocks to which the n transactions belong, wherein the blockchain node is any one of the second nodes, and the blockchain node further includes:

[0116] The verification unit is used to perform simple payment verification on the target transaction in the block based on at least one of the n transactions and the block header.

[0117] This specification also provides a computer-readable storage medium having a computer program stored thereon, which, when executed in a computer, causes the computer to perform actions such as... Figure 2 The method shown.

[0118] This specification also provides a computer-readable storage medium having a computer program stored thereon, which, when executed in a computer, causes the computer to perform actions such as... Figure 6 The method shown.

[0119] This specification also provides a blockchain node, including a memory and a processor. The memory stores executable code, and when the processor executes the executable code, it implements... Figure 2 The method shown.

[0120] This specification also provides a blockchain node, including a memory and a processor. The memory stores executable code, and when the processor executes the executable code, it implements... Figure 6 The method shown.

[0121] In the solutions provided in the embodiments of this specification, user-uploaded data is divided into multiple data blocks by blockchain nodes, and the data is stored in the blockchain through multiple transactions, thereby ensuring the acquisition of authentic data. Furthermore, for light nodes with limited storage resources, the embodiments of this specification use the EC algorithm to distribute the transactions in the block across multiple light nodes in the form of shards. This allows light nodes to obtain shards from various light nodes and recover the transactions, thus enabling SPV verification of the target transaction.

[0122] This specification also provides a computer-readable storage medium storing a computer program thereon, which, when executed in a computer, causes the computer to perform actions such as... Figure 3 The method shown.

[0123] This specification also provides a computing device, including a memory and a processor, wherein the memory stores executable code, and when the processor executes the executable code, it implements, as described above. Figure 3 The method shown.

[0124] In the 1990s, improvements to a technology could be clearly distinguished as either hardware improvements (e.g., improvements to the circuit structure of diodes, transistors, switches, etc.) or software improvements (improvements to the methodology). However, with technological advancements, many methodological improvements today can be considered direct improvements to the hardware circuit structure. Designers almost always obtain the corresponding hardware circuit structure by programming the improved methodology into the hardware circuit. Therefore, it cannot be said that a methodological improvement cannot be implemented using hardware physical modules. For example, a Programmable Logic Device (PLD) (such as a Field Programmable Gate Array (FPGA)) is such an integrated circuit whose logic function is determined by the user programming the device. Designers can program and "integrate" a digital system onto a PLD themselves, without needing chip manufacturers to design and manufacture dedicated integrated circuit chips. Furthermore, nowadays, instead of manually manufacturing integrated circuit chips, this programming is mostly implemented using "logic compiler" software. Similar to the software compiler used in program development, the original code before compilation must be written in a specific programming language, called a Hardware Description Language (HDL). There are many HDLs, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, and RHDL (Ruby Hardware Description Language). Currently, the most commonly used are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should understand that by simply performing some logic programming on the method flow using one of these hardware description languages ​​and programming it into an integrated circuit, the hardware circuit implementing the logical method flow can be easily obtained.

[0125] The controller can be implemented in any suitable manner. For example, it can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicon Labs C8051F320. A memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also recognize that, in addition to implementing the controller in purely computer-readable program code form, the same functionality can be achieved by logically programming the method steps to make the controller take the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers. Therefore, such a controller can be considered a hardware component, and the means included therein for implementing various functions can also be considered as structures within the hardware component. Alternatively, the means for implementing various functions can be considered as both software modules implementing the method and structures within the hardware component.

[0126] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or physical entities, or by products with certain functions. A typical implementation device is a server system. Of course, this application does not exclude the possibility that, with the future development of computer technology, the computer implementing the functions of the above embodiments can be, for example, a personal computer, a laptop computer, an in-vehicle human-machine interaction device, a cellular phone, a camera phone, a smartphone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or any combination of these devices.

[0127] While one or more embodiments of this specification provide the operational steps of the methods described in the embodiments or flowcharts, more or fewer operational steps may be included based on conventional or non-inventive means. The order of steps listed in the embodiments is merely one possible order of execution among many steps and does not represent the only possible order. In actual device or end product execution, the methods shown in the embodiments or drawings may be executed sequentially or in parallel (e.g., in a parallel processor or multi-threaded processing environment, or even a distributed data processing environment). The terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, product, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, product, or apparatus. Without further limitations, the presence of other identical or equivalent elements in the process, method, product, or apparatus that includes the elements is not excluded. For example, the use of terms such as "first," "second," etc., is to denote names and does not indicate any particular order.

[0128] For ease of description, the above devices are described in terms of function, divided into various modules. Of course, when implementing one or more of these specifications, the functions of each module can be implemented in one or more software and / or hardware components, or a module that performs the same function can be implemented by a combination of multiple sub-modules or sub-units. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, indirect coupling or communication connection between devices or units, and may be electrical, mechanical, or other forms.

[0129] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0130] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0131] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0132] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0133] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0134] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage, graphene storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0135] Those skilled in the art will understand that one or more embodiments of this specification can be provided as a method, system, or computer program product. Therefore, one or more embodiments of this specification may take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, one or more embodiments of this specification may take the form of a computer program product implemented on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0136] One or more embodiments of this specification can be described in the general context of computer-executable instructions, such as program modules, that are executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform a particular task or implement a particular abstract data type. One or more embodiments of this specification can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In a distributed computing environment, program modules can reside in local and remote computer storage media, including storage devices.

[0137] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, system embodiments are basically similar to method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments. In the description of this specification, the terms "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of this specification. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described can be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification and the features of different embodiments or examples.

[0138] The above description is merely an embodiment of one or more embodiments of this specification and is not intended to limit the scope of this specification. Various modifications and variations can be made to the one or more embodiments of this specification by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this specification should be included within the scope of the claims.

Claims

1. A method for storing data in a blockchain, executed by the first node in the blockchain, comprising: Receive a data upload request from the user equipment, wherein the data upload request includes first data to be uploaded and information about the first data; Generate n data blocks, each data block including a portion of the first data and information about the first data; n transactions are generated based on the n data blocks, and the n data blocks correspond one-to-one with the n transactions. Each transaction includes the data block corresponding to that transaction. A hash value list is generated based on the n transactions, and the correspondence between the identifier of the first data and the hash value list is stored. The hash value list is stored in each light node of the blockchain and is used to retrieve the n transactions from the blockchain. The n transactions are stored in the blockchain.

2. The method according to claim 1, wherein the n transactions use the user's first account as the sending account, and generating n transactions based on the n data blocks includes: A transaction body of n transactions is generated based on the n data blocks; Send the transaction bodies of the n transactions to the user equipment; Receive user signatures for n transaction entities from the user equipment; The n transactions are obtained based on the n transaction bodies and their signatures.

3. The method according to claim 1 or 2, wherein the information of the first data includes at least one of the following: the identifier of the first data, the upload time, and the data owner.

4. The method according to claim 1 or 2, further comprising: The list of hash values ​​of the n transactions is returned to the user device.

5. The method according to claim 4, further comprising: In response to a query request for the first data, the n transactions are read based on the list of hash values ​​of the n transactions; Obtain n data blocks from the n transactions; The first data is generated based on the n data blocks; Return the first data.

6. The method according to claim 5, wherein the query request includes a list of hash values ​​of the n transactions.

7. The method according to claim 5, wherein the information of the first data further includes a first signature of the first account of the user on the first data, and the method further includes, after generating the first data, obtaining the first signature from the n transactions, and verifying the first data based on the first signature.

8. The method according to claim 1 or 2, wherein storing the n transactions in the blockchain comprises: Send the n transactions to the blockchain so that the n transactions are executed in the blockchain; In response to the completion of the n transactions, the n transactions are converted into k+m shards according to the erasure coding algorithm, and the k+m shards include k data shards and m verification shards; The k+m shards are distributed and stored in t second nodes in the blockchain.

9. The method according to claim 8, wherein the n transactions belong to at least one block, and the step of converting the n transactions into k+m shards comprises, after completing the execution of the at least one block, converting the n transactions into k+m shards. The method further includes: The block header of the at least one block is stored in each of the second nodes.

10. The method according to claim 8, wherein distributing and storing the k+m shards into t second nodes in the blockchain comprises storing at least one of the shards in association with a list of hash values ​​of the n transactions in each second node.

11. The method according to claim 1 or 2, wherein generating n data blocks based on the first data comprises: The first data is encoded, and the encoded second data is divided into n parts. The information of the first data is added to each part to obtain the n data blocks.

12. A method for reading transactions in a blockchain, wherein the blockchain includes t second nodes, and the t second nodes distribute and store k+m shards, the k+m shards including k data shards and m verification shards, the k+m shards corresponding to n transactions, the n transactions corresponding one-to-one with n data blocks, each transaction including a corresponding data block, and each data block including a portion of first data; the method includes: Based on the list of hash values ​​stored in the second node corresponding to the identifier of the first data, at least k fragments from the k+m fragments are read from at least a portion of the t second nodes; The n transactions are recovered based on the at least k shards.

13. The method according to claim 12, wherein each second node further stores the block header of the block to which the n transactions belong, the method is executed by any second node, and the method further comprises: Simple payment verification is performed on the target transaction in the block based on at least one of the n transactions and the block header.

14. A blockchain system comprising a first node and t second nodes, The first node is configured to: receive a data upload request from a user equipment, wherein the data upload request includes first data to be uploaded and information about the first data; Generate n data blocks, each data block including a portion of the first data and information about the first data; n transactions are generated based on the n data blocks, and the n data blocks correspond one-to-one with the n transactions. Each transaction includes the data block corresponding to that transaction. A hash value list is generated based on the n transactions, and the correspondence between the identifier of the first data and the hash value list is stored. The hash value list is stored in each light node of the blockchain and is used to retrieve the n transactions from the blockchain; send the n transactions to the blockchain; in response to the completion of the n transactions, the n transactions are converted into k+m shards according to the erasure coding algorithm, the k+m shards include k data shards and m verification shards; the k+m shards are distributed and stored in t second nodes in the blockchain. Any of the second nodes is used to: read at least k shards from at least a portion of the t second nodes; and recover the n transactions based on the at least k shards.

15. A blockchain node, comprising: A receiving unit is configured to receive a data upload request from a user equipment, wherein the data upload request includes first data to be uploaded and information about the first data. A generation unit is used to generate n data blocks, each data block including a portion of the first data and information of the first data; n transactions are generated based on the n data blocks, and the n data blocks correspond one-to-one with the n transactions. Each transaction includes the data block corresponding to that transaction. A hash value list is generated based on the n transactions, and the correspondence between the identifier of the first data and the hash value list is stored. The hash value list is stored in each light node of the blockchain and is used to retrieve the n transactions from the blockchain. A storage unit is used to store the n transactions into the blockchain.

16. A blockchain node, comprising: The reading unit is configured to read at least k shards from at least a portion of the t second nodes from a list of hash values ​​stored in the second nodes corresponding to the identifiers of the first data. The t second nodes distribute and store the k+m shards, which include k data shards and m verification shards. Each k+m shard corresponds to n transactions; each n transaction corresponds one-to-one with n data blocks, and each transaction includes a corresponding data block, with each data block including a portion of the first data. A recovery unit is used to recover the n transactions based on the at least k shards.

17. A computer-readable storage medium having a computer program stored thereon, which, when executed in a computer, causes the computer to perform the method of any one of claims 1-13.

Images