CN110598456B

CN110598456B - Data storage method and device, electronic equipment and storage medium

Info

Publication number: CN110598456B
Application number: CN201910906445.9A
Authority: CN
Inventors: 张懿方; 戴传兵; 郭鹏; 洪晓雯
Original assignee: Tencent Technology Shenzhen Co Ltd
Current assignee: Tencent Technology Shenzhen Co Ltd
Priority date: 2019-09-24
Filing date: 2019-09-24
Publication date: 2021-04-30
Anticipated expiration: 2039-09-24
Also published as: CN110598456A

Abstract

The embodiment of the application discloses a data storage method, a data storage device, electronic equipment and a storage medium, wherein the method comprises the following steps: the target light weight node acquires target service data of a target service object and sends the target service data to the full-scale node; generating a target service block corresponding to the target service data by the full-scale node, and adding the target service block to a full-scale block chain; the service blocks in the full block chain are generated by the full nodes according to the service data sent by at least one light weight node and are added to the full block chain; the full-scale node sends a target block head of the target service block to the target lightweight node; the target lightweight node adds a target block header to the local service block chain; the local traffic block chain includes a block header of a traffic block generated by traffic data sent by the target lightweight node to the full-scale node. By the method and the device, the hardware requirement of the block chain node can be reduced, and the data security is improved.

Description

Data storage method and device, electronic equipment and storage medium

Technical Field

The present application relates to the field of computer technologies, and in particular, to a data storage method and apparatus, and a related device.

Background

Blockchains are the fundamental supporting technology for bitcoin, and their realizability has been demonstrated by bitcoin, which has been run to date since 2009. The block chain technology has the outstanding advantage of decentralization, and at present, many decentralization application systems are established based on the block chain technology, such as application systems applied to the fields of data encryption, cloud computing, social media and the like.

In the existing decentralized application system, all the blockchain nodes need to store a complete blockchain and execute a calculation task (for example, verifying data, packing blocks, broadcasting blocks, etc.), and as time goes on, the amount of blockchain data is huge, a large amount of hardware resources need to be consumed to support the operation of the application system, and all the blockchain nodes store the complete blockchain, which may cause data leakage and reduce the security of data.

Disclosure of Invention

The embodiment of the application provides a data storage method, a data storage device and related equipment, which can reduce the hardware requirement of a block chain node and improve the data security.

An embodiment of the present application provides a data storage method, including:

the target light weight node acquires target service data of a target service object and sends the target service data to the full-scale node;

the full-scale node generates a target service block corresponding to the target service data and adds the target service block to a full-scale block chain; the service blocks in the full block chain are generated by the full node according to the service data sent by at least one light weight node and are added to the full block chain; the at least one lightweight node comprises the target lightweight node;

the full-scale node sends a target block head of the target service block to the target lightweight node;

the target lightweight node adds the target block header to a local service block chain; the local service block chain comprises a block header of a service block generated by service data sent by the target lightweight node to the full-scale node.

Wherein, still include:

when the full-scale node receives an audit request aiming at the target service object, the full-scale node acquires the full-scale block chain according to the audit request;

the full-scale node acquires the target service block corresponding to the target service object from the full-scale block chain, and acquires service data to be sent according to the target service block; the service data to be sent is the service data after the encrypted service data is decrypted; the encrypted service data belongs to the target service data;

and the full node performs service audit on the service data to be sent, and generates audit output information corresponding to the audit request according to an audit result.

The acquiring service data to be sent according to the target service block includes:

the full-scale node extracts a block body of the target service block as encrypted service data;

the full-scale node acquires a private key of the target lightweight node;

and the full-amount node decrypts the encrypted service data according to the private key of the target lightweight node to obtain the service data to be sent.

Wherein, still include:

the target light weight node receives the to-be-verified service data of the target service object and determines a fourth hash value of the to-be-verified service data;

the target lightweight node traverses all block heads of the local service block chain;

if the local service block chain has a block head containing the fourth hash value, the target lightweight node determines that the service data to be verified belongs to verified service data;

if the local service block chain does not have a block head containing the fourth hash value, the target lightweight node determines that the service data to be verified belongs to unverified service data.

Wherein, if the local service block chain has a block header containing the fourth hash value, the target lightweight node determines that the service data to be verified belongs to verified service data, including:

if the local service block chain has a block head containing the fourth hash value, the target lightweight node sends a verification request to the full-scale node; the authentication request comprises the fourth hash value;

if the lightweight node receives a verification passing message sent by the full-scale node aiming at the verification request, the target lightweight node determines that the to-be-verified service data belongs to the verified service data; the verification passing message is generated when the full-volume node detects that a traffic block containing the fourth hash value exists on the full-volume block chain and the number of backward adjacent traffic blocks in the full-volume chain to the traffic block containing the fourth hash value is greater than a number threshold.

The method for acquiring the target business data of the target business object by the target lightweight node comprises the following steps:

the target light-weight node acquires service data to be sent of the target service object, and encrypts the service data to be sent according to a public key of the target light-weight node to obtain encrypted service data;

the target light weight node determines a first hash value of the encrypted service data, encrypts the first hash value according to a private key of the target light weight node, and generates a digital signature;

and the target light weight node combines the encrypted service data and the digital signature into the target service data.

The method for acquiring the service data to be sent of the target service object by the target lightweight node includes:

the target lightweight node acquires service data to be detected of the target service object;

the target lightweight node detects the data type of the service data to be detected;

and if the data type is matched with the object authority type of the target service object, the target lightweight node determines the service data to be detected as the service data to be sent.

Wherein the generating, by the full-scale node, a target service block corresponding to the target service data includes:

the full-scale node receives the target service data sent by the target lightweight node; the target service data comprises encrypted service data and a digital signature; the encrypted service data is generated after the service data to be transmitted is encrypted according to the public key of the target lightweight node;

the full-scale node acquires a public key of the target lightweight node, and decrypts the digital signature according to the public key of the target lightweight node to obtain a second hash value;

the full-scale node determines a third hash value of the encrypted service data;

and if the second hash value is the same as the third hash value, the full-scale node generates the target service block according to the encrypted service data.

Another aspect of the embodiments of the present application provides a data storage method, including:

the target light weight node acquires target service data of a target service object and sends the target service data to the full-scale node; the target service data is used for instructing the full-scale node to generate a target service block and adding the target service block to a full-scale block chain; the service blocks in the full block chain are generated by the full node according to the service data sent by at least one light weight node and are added to the full block chain; the at least one lightweight node comprises the target lightweight node;

the target lightweight node receives a target block head of the target service block sent by the full-scale node, and adds the target block head to a local service block chain; the local service block chain comprises a block header of a service block generated by service data sent by the target lightweight node to the full-scale node.

In another aspect, an embodiment of the present application provides a data storage method, including:

the full-scale node receives target service data of a target service object sent by the target lightweight node;

the full-scale node generates a target service block corresponding to the target service data, and adds the target service block to a full-scale block chain; the service blocks in the full block chain are generated by the full node according to the service data sent by at least one light weight node and are added to the full block chain; the at least one lightweight node comprises the target lightweight node;

the full-scale node sends a target block head of the target service block to the target lightweight node; the target block header is used for instructing the target lightweight node to adjust a local service block chain; the local service block chain comprises a block header of a service block generated by service data sent by the target lightweight node to the full-scale node.

Another aspect of the embodiments of the present application provides a data storage device, which is applied to a target light-weight node, and includes:

the acquisition module is used for acquiring target service data of the target service object;

the sending module is used for sending the target service data to a full-scale node; the target service data is used for instructing the full-scale node to generate a target service block and adding the target service block to a full-scale block chain; the service blocks in the full block chain are generated by the full node according to the service data sent by at least one light weight node and are added to the full block chain; the at least one lightweight node comprises the target lightweight node;

the sending module is further configured to receive a target block header of the target service block sent by the full-scale node, and add the target block header to a local service block chain; the local service block chain comprises a block header of a service block generated by service data sent by the target lightweight node to the full-scale node.

Wherein, still include:

the sending module is further configured to receive to-be-verified service data of the target service object, and determine a fourth hash value of the to-be-verified service data;

the traversing module is used for traversing all the block heads of the local service block chain;

a first determining module, configured to determine that the to-be-verified service data belongs to verified service data if a block header including the fourth hash value exists in the local service block chain;

a second determining module, configured to determine that the to-be-verified service data belongs to unverified service data if the local service block chain does not have a block header including the fourth hash value.

The first determining module is specifically configured to, if a chunk header including the fourth hash value exists in the local service chunk chain, send, by the target lightweight node, a verification request to the full-scale node; the verification request comprises the fourth hash value, and if the lightweight node receives a verification passing message sent by the full-scale node aiming at the verification request, the target lightweight node determines that the to-be-verified service data belongs to the verified service data; the verification passing message is generated when the full-volume node detects that a traffic block containing the fourth hash value exists on the full-volume block chain and the number of backward adjacent traffic blocks in the full-volume chain to the traffic block containing the fourth hash value is greater than a number threshold.

Wherein, the obtaining module includes:

an obtaining unit, configured to obtain service data to be sent of the target service object;

and the encryption unit is used for encrypting the service data to be sent according to the public key of the target lightweight node to obtain encrypted service data, determining a first hash value of the encrypted service data, encrypting the first hash value according to the private key of the target lightweight node to generate a digital signature, and combining the encrypted service data and the digital signature into the target service data.

The acquiring unit is specifically configured to acquire service data to be detected of the target service object, detect a data type of the service data to be detected, and determine the service data to be detected as the service data to be detected if the data type matches the object permission type of the target service object.

In another aspect, an embodiment of the present application provides a data storage device, which is applied to a full-scale node, and includes:

the receiving module is used for receiving target business data of the target business object sent by the target lightweight node;

a generating module, configured to generate a target service block corresponding to the target service data;

the receiving module is further configured to add the target service block to a full block chain; the service blocks in the full block chain are generated by the full node according to the service data sent by at least one light weight node and are added to the full block chain; the at least one lightweight node comprises the target lightweight node;

the receiving module is further configured to send a target block header of the target service block to the target lightweight node; the target block header is used for instructing the target lightweight node to adjust a local service block chain; the local service block chain comprises a block header of a service block generated by service data sent by the target lightweight node to the full-scale node.

Wherein, still include:

the receiving module is further configured to, when an audit request for the target service object is received, obtain the full block chain according to the audit request;

the receiving module is further configured to obtain the target service block corresponding to the target service object from the full block chain;

the extraction module is used for acquiring service data to be sent according to the target service block; the service data to be sent is the service data after the encrypted service data is decrypted; the encrypted service data belongs to the target service data;

and the auditing module is used for performing service auditing on the service data to be sent and generating auditing output information corresponding to the auditing request according to an auditing result.

The extracting module is specifically configured to extract a block of the target service block as encrypted service data, obtain a private key of the target lightweight node, and decrypt the encrypted service data according to the private key of the target lightweight node to obtain the service data to be sent.

The generating module is specifically configured to receive the target service data sent by the target lightweight node; the target service data comprises encrypted service data and a digital signature; and acquiring a public key of the target lightweight node, decrypting the digital signature according to the public key of the target lightweight node to obtain a second hash value, determining a third hash value of the encrypted service data, and if the second hash value is the same as the third hash value, generating the target service block according to the encrypted service data.

Another aspect of the embodiments of the present application provides an electronic device, including a memory and a processor, where the memory stores a computer program, and the computer program, when executed by the processor, causes the processor to execute the method as in another aspect of the embodiments of the present application.

Another aspect of the embodiments of the present application provides an electronic device, including a memory and a processor, where the memory stores a computer program, and the computer program, when executed by the processor, causes the processor to execute the method according to another aspect of the embodiments of the present application.

Another aspect of the embodiments of the present application provides a computer storage medium storing a computer program comprising program instructions that, when executed by a processor, perform a method as in another aspect of the embodiments of the present application.

Another aspect of the embodiments of the present application provides a computer storage medium storing a computer program comprising program instructions that, when executed by a processor, perform a method as in yet another aspect of the embodiments of the present application.

The full-quantity nodes in the application store complete service block chains, but the lightweight nodes only store block heads of service blocks related to the lightweight nodes, and different types of block chain nodes store different data, so that data isolation can be realized, the risk of data leakage is reduced, and the safety and the privacy of the data are improved; furthermore, the lightweight node only stores the block head of the block, and the storage space occupied by the block head is far smaller than that occupied by the whole block, so that the hardware requirement on the lightweight node can be reduced, and the hardware resource is saved.

Drawings

In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly described below, it is obvious that the drawings in the following description are only some embodiments of the present application, and for those skilled in the art, other drawings can be obtained according to the drawings without creative efforts.

FIG. 1 is a system architecture diagram of a data storage provided by an embodiment of the present application;

2 a-2 b are schematic diagrams of a data storage scenario provided by an embodiment of the present application;

FIG. 3 is an interaction diagram of a data storage method according to an embodiment of the present application;

fig. 4 is a schematic diagram of a service block provided in an embodiment of the present application;

FIG. 5 is a schematic diagram of a data storage method provided in an embodiment of the present application;

FIG. 6 is an interaction diagram of another data storage method provided by an embodiment of the present application;

FIG. 7 is a schematic flowchart of a data storage method according to an embodiment of the present application;

FIG. 8 is a schematic flow chart diagram illustrating another data storage method according to an embodiment of the present application;

FIG. 9 is a schematic structural diagram of a data storage device according to an embodiment of the present application;

FIG. 10 is a schematic structural diagram of another data storage device provided in an embodiment of the present application;

fig. 11 is a schematic structural diagram of an electronic device according to an embodiment of the present invention;

fig. 12 is a schematic structural diagram of another electronic device according to an embodiment of the present invention.

Detailed Description

The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are only a part of the embodiments of the present application, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present application.

The Block chain (Block chain) is a novel application mode of computer technologies such as distributed data storage, point-To-point transmission (P2P, Peer To Peer), a consensus mechanism, an encryption algorithm and the like. The blockchain is essentially a decentralized database, which is a string of data blocks associated using cryptography, each data block containing one or more transaction messages for verifying the validity (anti-counterfeiting) of the message and generating the next block.

Fig. 1 is a system architecture diagram of a data storage according to an embodiment of the present application. As shown in fig. 1, the data store involves lightweight nodes as well as a full-volume node, where both the lightweight nodes and the full-volume node belong to blockchain nodes. As shown in fig. 1, the lightweight nodes may include a lightweight node 1 and a lightweight node 2; the full-volume nodes may include full-volume node 1, full-volume node 2, full-volume node 3, and full-volume node 4.

After receiving the service data of the target object, the lightweight node sends the service data to the full-scale node, 1 accounting full-scale node is selected from the full-scale node 1, the full-scale node 2, the full-scale node 3 and the full-scale node 4 based on a consensus algorithm, the accounting full-scale node generates a block of the service data and broadcasts the generated block to the rest full-scale nodes, and all the full-scale nodes update the respectively maintained full-scale block chains; meanwhile, the accounting total node also sends the block header of the generated block to the lightweight node sending the service data, and the lightweight node adds the block header to the local service block chain.

Subsequently, when the target object needs to verify whether a certain service data is added to the full block chain, whether a certain service data is added to the full block chain may be determined according to the block header in the local block chain.

The lightweight node shown in fig. 1 may be a mobile phone, a tablet computer, a notebook computer, a palm computer, a Mobile Internet Device (MID), a wearable device, or the like; the full number of nodes may be better performing servers.

Fig. 2 a-2 b below illustrate how to construct a full blockchain and how to construct a service blockchain, taking as an example the lightweight node 1 and the accounting node as the full-volume node 1.

Please refer to fig. 2 a-2 b, which are schematic views illustrating a scenario of data storage according to an embodiment of the present application. As shown in fig. 2a, currently, a service block chain including 2 block headers is stored in a local file of the lightweight node 1, and the lightweight node 1 acquires service data of a service object having a binding relationship with the lightweight node 1. The lightweight node 1 transmits the traffic data to the full-scale node 1. The full-scale node 1 is a block generation node selected from a plurality of full-scale nodes (including the full-scale node 1, the full-scale node 2, the full-scale node 3 and the full-scale node 4) based on a consensus algorithm (the consensus algorithm may include a PoW workload certification algorithm, a PoS equity certification algorithm, a byzantine fault-tolerant algorithm, or the like).

Here, in the full-scale node 1, the full-scale node 2, the full-scale node 3, and the full-scale node 4, an identical full-scale block chain is stored, and at this time, the full-scale block chain includes 3 blocks, each block includes a block body and a block header, and it is noted that the service block chain includes only a block header.

The full-volume node 1 takes the service data as the block 10d, calculates the hash value of the service data (i.e. the hash value of the block in fig. 2 a) based on a hash algorithm (the hash algorithm may include SHA256, MD5, SHA1, etc.), and obtains the hash value of the last block in the current full-volume block chain (i.e. the hash value of the parent block in fig. 2 a). The full node combines the hash value of the parent block, the hash value of the block, and the current timestamp into a block header 10c, and may combine the block header 10c and the block 10d into a block 10 e. To this end, the quantum node 1 generates a block 10e corresponding to the traffic data, and the block 10e is composed of a block header 10c and a block body 10 d.

As shown in fig. 2b, the full node 1 broadcasts the block 10e to the full nodes 2, 3 and 4, and the full nodes 2, 3 and 4 add the block 10e broadcasted by the full node 1 to the respective stored full block chains, so that the respective stored full block chains of the full nodes 1, 2, 3 and 4 are synchronized. As shown in fig. 2b, the updated full-size block chain includes 4 blocks, and the 4 blocks include a newly generated block 10 e.

The full-scale node 1 sends the block header 10c in the block 10e to the light-weight node 1, the light-weight node 1 adds the block header 10c to the service block chain, the updated service block chain includes 3 block headers, and the 3 block headers include the newly generated block header 10 c.

It should be noted that the full-scale node 1 only transmits the block header 10c to the lightweight node 1 that transmits the traffic data, and does not transmit the block header to the remaining lightweight nodes (e.g., the lightweight nodes 2), so that each lightweight node stores only the block header of the traffic data transmitted by itself to the full-scale node, and the block headers of the traffic data transmitted by other lightweight nodes are not stored.

Subsequently, when the lightweight node 1 needs to verify whether a certain service data is added to the full block chain, it may search whether a block head containing the hash value of the service data to be verified exists by calculating the hash value of the service data to be verified, traversing all block heads on the service block chain, and if not, indicating that the service data to be verified is not added to the full block chain; if the verification request exists, the lightweight node 1 sends the verification request to the full-scale nodes (any full-scale node can be any one of the full-scale nodes here), and the verification request carries the hash value of the service data to be verified.

If the full-volume node finds that a block containing the hash value of the service data to be verified exists on the full-volume block chain, and a plurality of blocks (for example, 6 or more blocks) exist in the block containing the hash value of the service data to be verified subsequently on the full-volume block chain, it indicates that the block containing the hash value of the service data to be verified has been acknowledged by the full-volume block chain.

The total node may return a verification passing message to the lightweight node 1, and after receiving the verification passing message, the lightweight node 1 may determine that the service data to be verified has been added to the total block chain, which is colloquially speaking, that the service data to be verified has been successfully uplink.

Subsequently, when the full amount of nodes need to audit the service data, the service data can be acquired from the full amount of block chains, the content of the service data can be automatically audited, audit output information is output, and the reliability of the audit result can be ensured depending on the non-tamper property of the block chains.

Please refer to fig. 3, which is an interaction schematic diagram of a data storage method provided in an embodiment of the present application, where the embodiment describes a specific process of the data storage method through an interaction between a target lightweight node and a full-scale node, and as shown in fig. 3, the data storage method may include the following steps:

step S101, a target light weight node acquires target service data of a target service object and sends the target service data to a full-scale node.

Specifically, the data storage method can be applied to tax authorities, import and export tax return authorities, customs, data receiving platforms, upstream and downstream enterprises and the like; the terminal devices (e.g., servers) having a binding relationship with the tax bureau, the terminal devices having a binding relationship with the import/export tax return bureau, the terminal devices having a binding relationship with the customs, and the terminal devices where the data receiving platform is located may be referred to as full-volume nodes (e.g., full-volume node 1, full-volume node 2, full-volume node 3, and full-volume node 4 in the embodiment corresponding to fig. 1), and the terminal devices having a binding relationship with upstream and downstream enterprises (e.g., sales enterprises, principle providers, logistics companies, etc.) may be referred to as light-weight nodes (e.g., light-weight node 1 and light-weight node 2 in the embodiment corresponding to fig. 1); all the above-mentioned full-scale nodes and all the light-weight nodes belong to the same blockchain system, in the blockchain system, only the full-scale nodes can participate in the consensus (i.e. generating a block, broadcasting a block, updating the full-scale blockchain, etc.), and the light-weight nodes do not need to participate in the consensus.

The following embodiments are described with reference to one lightweight node (referred to as a target lightweight node, such as the lightweight node 1 in the corresponding embodiment of fig. 2 a-2 b described above) and a full-volume node (such as the full-volume node 1, the full-volume node 2, the full-volume node 3, and the full-volume node 4 in the corresponding embodiment of fig. 2 a-2 b described above) as examples:

the business object having a binding relationship with the target lightweight node is called a target business object, and the target lightweight node acquires business data to be uplink (called target business data) of the target object. The business object may be a raw material supplier, a goods producer, a goods seller, or a logistics company, and the corresponding business data may be a raw material purchase list, a goods production pipeline video, a goods sale list, or a logistics LBS (Location Based Service) data.

In order to ensure the security of the service data, the target lightweight node may also encrypt the target service data and generate a digital signature, and then send the encrypted target service data and the digital signature. The following is a detailed description:

the target light weight node acquires service data to be sent of the target service object, and acquires a Public Key (Public Key) of the target light weight node, wherein the Public Key of the target light weight node can also be understood as the Public Key of the target object.

The public Key corresponds to a Private Key (Private Key), the public Key and the Private Key are paired, the Private Key can encrypt data, the public Key can decrypt the encrypted data, and the public Key can encrypt data and the Private Key can decrypt the encrypted data. Generally, public keys and private keys are different, and data encryption by using the public key and the private key belongs to an asymmetric encryption mode.

Because the full-scale node and the light-weight nodes are in a management and managed relationship, the full-scale node holds the public key and the private key of all the light-weight nodes.

The target light weight node encrypts the service data to be sent according to the public key of the target light weight node, and the obtained data is called encrypted service data, wherein the encryption algorithm can be an RSA encryption algorithm.

The target lightweight node computes a hash value, referred to as a first hash value, of the encrypted traffic data according to a hash hashing algorithm (which may include SHA256, MD5, or SHA 1).

Among other things, hash algorithms are a way to create small digital "fingerprints" from any kind of data. The hash function compresses the data into a summary, so that the data volume becomes small, and the format of the data is fixed. This function mixes the data shuffled and recreates a fingerprint called a hash value. The hash value is typically represented by a short string of random letters and numbers.

And the target lightweight node encrypts the first hash value according to the private key of the target lightweight node to obtain the digital signature of the target lightweight node. And the target lightweight node combines the digital signature and the encrypted business data into target business data.

Subsequently, the target lightweight node sends the target service data to all the full-scale nodes, or the target lightweight node sends the target service data to the full-scale node where the data receiving platform is located, where the full-scale node where the data receiving platform is located is dedicated to receive the service data sent by the lightweight node (that is, the full-scale node where the data receiving platform is located is the accounting full-scale node).

Further, the types of the service data that can be sent by different service objects are different, for example, if the service object is a logistics company, the service data that can be sent by the service object through the lightweight node can only be data related to a logistics location, and other service data logistics companies, such as product production, product sales, and the like, do not have authority to send, so the lightweight node needs to detect the data type of the service data to be sent of the target service object, and only if the detected data type matches the authority of the target service object, the target lightweight node subsequently sends the service data to be sent to the full-scale node. The following is a detailed description:

the target light weight node obtains service data to be detected of a target service object, and obtains a data classification model, wherein the service data to be detected may be data with a time dimension (for example, the data to be detected is also video data), the data classification model may be a classification model trained based on a Recurrent Neural Network (RNN) or a Long Short-Term Memory Network (LSTM), or a classification model trained based on a Convolutional Neural Network (CNN).

The data classification model can comprise an input layer, a coding layer and a classifier, wherein the input layer is used for adjusting the data format and the data size of the service data to be detected; the device comprises a coding layer, a classifier and a target light weight node, wherein the coding layer is used for coding service data to be detected to obtain hidden feature vectors of the service data to be detected, the classifier is used for determining the matching probability between the hidden feature vectors and various data types in a data classification model, and the target light weight node can take the data type corresponding to the maximum matching probability as the data type of the service data to be detected; the target lightweight node can also use the data type with the matching probability greater than the probability threshold as the data type of the service data to be detected.

Wherein, the data types in the data classification model can include: logistics data type, commodity production activity data type, commodity sales activity data type, raw material purchasing activity data type and the like.

The target lightweight node acquires the object authority type of the target service object, and if the data type of the service data to be detected is the same as the object authority type of the target service object, the target lightweight node can determine the service data to be detected as the service data to be detected; if the data type of the service data to be detected is different from the object authority type of the target service object, the target lightweight node can generate a prompt message, and the prompt message is used for prompting that the service data to be detected of the target service object is not matched with the own authority type.

Step S102, the full-scale node generates a target service block corresponding to the target service data and adds the target service block to a full-scale block chain; the service blocks in the full block chain are generated by the full node according to the service data sent by at least one light weight node and are added to the full block chain; the at least one lightweight node comprises the target lightweight node.

Specifically, if all the full-scale nodes receive the target service data, because there are a plurality of full-scale nodes, a full-scale node with an accounting authority may be selected from all the full-scale nodes based on a consensus algorithm, where the consensus algorithm may include: a PoW (Proof of Work) algorithm, a PoS (Proof of Stake) algorithm, or a byzantine fault-tolerant algorithm, etc.

Optionally, if all the full-scale nodes receive the target service data, one full-scale node may be arbitrarily selected from the multiple full-scale nodes as the full-scale node having the accounting authority.

If only the target service data is received by the full-scale node where the data receiving platform is located, the full-scale node where the data receiving platform is located can be directly used as the full-scale node with the accounting authority.

The selected full-scale node with the accounting authority generates a service block (such as the block 10e in the corresponding embodiment of fig. 2 a-2 b) according to the target service data, which is called a target service block, the newly generated target service block is added to a full-scale block chain maintained by the full-scale node with the accounting authority, and the full-scale node with the accounting authority broadcasts the newly generated target service deblocking to the rest full-scale nodes.

All the full-scale nodes respectively maintain a same full-scale block chain, the full-scale block chain comprises one or more service blocks, and the full-scale block chain added with the target service block contains the target service block. The service blocks on the full-scale blockchain are generated by the full-scale node according to the service data sent by one or more light-weight nodes and added to the full-scale blockchain (the target light-weight node also belongs to the one or more light-weight nodes), in other words, different light-weight nodes send different service data to the full-scale node, and the blocks are generated by the full-scale node and added to the full-scale blockchain, that is, the sources of the service data corresponding to the service blocks on the full-scale blockchain are different light-weight nodes.

The following describes how the full-scale node with the accounting authority generates the target service block in detail: the full-scale node receives the target service data sent by the target lightweight node, and as known from the foregoing, the target service data includes encrypted service data and a digital signature of the target lightweight node, and the encrypted service data is generated by encrypting the service data to be sent according to the public key of the target lightweight node.

And the full-scale node acquires the public key of the target lightweight node, decrypts the digital signature in the target service data, and obtains a second hash value.

And the full-amount node calculates a hash value of the encrypted service data in the target service data according to a hash algorithm, and the hash value is called a third hash value.

It should be noted that the hash algorithm used for determining the third hash value is the same as the hash algorithm used for determining the first hash value by the target lightweight node.

The full-scale node detects whether the second hash value and the third hash value are the same, if the second hash value and the third hash value are different, it indicates that the encrypted service data is tampered in the process of being transmitted from the target lightweight node to the full-scale node, or the target lightweight node initiating the transmission behavior does not have a real private key (it indicates that the target lightweight node fails to verify the identity), and the full-scale node may generate an illegal data prompt message and send the message to the target lightweight node to prompt the target lightweight node that the transmission fails.

If the second hash value and the third hash value are the same, it indicates that the encrypted service data is not tampered during the transmission from the target lightweight node to the full-scale node, and the target lightweight node initiating the transmission action has a true private key (indicating that the target lightweight node passes the authentication), the full-scale node may use the encrypted service data as a block (such as the block 10d in the embodiment corresponding to fig. 2 a-2 b), calculate a hash value of the encrypted service data based on a hash algorithm, and combine the calculated hash value, a block hash value of the last service block in the current full-scale block chain, and a current timestamp into a block header (such as the block header 10c in the embodiment corresponding to fig. 2 a-2 b). And the full-scale node combines the block head and the block body into a target service block.

Please refer to fig. 4, which is a schematic diagram of service blocks provided in this embodiment, each service block includes a block body and a block header, where the block header further includes a hash value of a previous service block, a hash value of the block body of the current service block, and a time stamp. Multiple service blocks may be connected to form a full service block chain in the sequence before and after the service block is generated and in the hash value referencing the last service block.

Optionally, the encrypted service data after being encrypted is directly uplinked, because the full-scale node holds the private key of the target lightweight node, the full-scale node may also decrypt the encrypted service data based on the private key of the target lightweight node to obtain service data to be sent, similarly, the full-scale node takes the service data to be sent as a block, combines the hash value of the service data to be sent, the block hash value of the last service block in the current full-scale block chain, and the current timestamp into a block header, and combines the block (i.e., the service data to be sent) and the block header into the target service block.

Step S103, the total node sends the target block header of the target service block to the target lightweight node.

Specifically, the full-scale node takes the block header of the generated target service block as the target block header. The full-scale node with accounting authority may send the target block header to the target lightweight node, or any one of the full-scale nodes may send the target block header to the target lightweight node.

Step S104, the target lightweight node adds the target block head to a local service block chain; the local service block chain comprises a block header of a service block generated by service data sent by the target lightweight node to the full-scale node.

Specifically, the target lightweight node receives a target block header sent by the full-scale node, and adds the target block header to a local service block chain (such as the service block chain in the embodiment corresponding to fig. 2 a-2 b) stored locally, where the local service block chain includes a plurality of block headers, the plurality of block headers are used for the target lightweight node to send service data to the full-scale node, and after the full-scale node generates a service block, the full-scale node returns the block header of the generated service block to the target lightweight node, and the target lightweight node is added to the local service block chain.

Summarizing the above process, no matter the number of the full-scale nodes, each full-scale node stores the same full-scale block chain, the full-scale block chain comprises a plurality of service blocks, and the service data of the service blocks are from different light-weight nodes; the local service block chain stored locally by each light weight node is different, the local service block chain only comprises the block head of the service block, and the light weight node only stores the block head of the service block of the service data sent by the light weight node.

The following is an example: please refer to fig. 5, which is a schematic diagram of a data storage method according to an embodiment of the present application, where there are a lightweight node 1, a lightweight node 2, a full-volume node 1, a full-volume node 2, and a full-volume node 3. Firstly, a lightweight node 1 sends service data 1 and service data 2 to a full-scale node, and the full-scale node correspondingly generates a service block 1 and a service block 2; next, the lightweight node 2 transmits the service data 3 to the full-scale node, and the full-scale node generates the service block 3. Then a full-volume block chain containing traffic block 1, traffic block 2 and traffic block 3 is stored in full-volume node 1, full-volume node 2 and full-volume node 3; in the lightweight node 1, a local service block chain is stored, which contains a block header of the service block 1 and a block header of the service block 2; in the lightweight node 2, a local service block chain is stored containing the block header of the service block 3.

That is, the lightweight nodes only store the block headers associated with themselves, ensuring isolation of data and protecting privacy between different lightweight nodes.

Optionally, how the full-volume node uses the full-volume blockchain is described below: when a tax bureau (or an import/export tax return bureau or a customs bureau) worker needs to check whether service data uploaded by a target service object meets tax return requirements, the worker can execute a checking operation on the target service object through a full-scale node (for example, click an object identifier of the target service object), the full-scale node responds to the operation to generate a checking request aiming at the target service object, and the full-scale node acquires a stored full-scale block chain according to the checking request.

The full-quantity node inquires the block height of a service block corresponding to the target service object in a block object record table, wherein the block object record table comprises a plurality of record tuples, and each record tuple comprises a block height and a service object; the block height refers to the height of a traffic block generated by traffic data sent by a traffic object through a lightweight node in the entire chain of full-volume blocks in which the block height is unique and exclusive.

And the full volume node determines a service block corresponding to the block height in the full volume block chain as a target service block corresponding to the target service object according to the block height inquired in the block object record table.

As can be seen from the foregoing, the target service data includes encrypted service data and a digital signature, and if encrypted service data is added to the full block chain, the block body of the target service block is the encrypted service data. The full-scale node reads the block body of the target service block as encrypted service data, and decrypts the encrypted service data according to the private key of the target light-scale node to obtain service data to be sent;

if the service data to be sent is added to the full block chain, the block of the target service block is the service data to be sent, and at this time, the full node directly takes the block of the target service block as the service data to be sent.

The full-scale node can identify a service scene and a service behavior of the service data to be sent, extract a service scene set and a service behavior set in the audit request, if the service scene of the service data to be sent can hit the service scene set in the audit request, that is, the service scene of the service data to be sent belongs to the service scene set in the audit request, and the service behavior of the service data to be sent can hit the service behavior set in the audit request, the full-scale node can determine that the audit result of the target service object is that the audit is passed, and then the full-scale node generates audit-passed output information according to the audit result that the audit is passed; the output information of the audit pass belongs to the audit output information.

If the service scene of the service data to be sent can not hit the service scene set in the audit request, or the service behavior of the service data to be sent can not hit the service behavior set in the audit request, the full-scale node can determine that the audit result of the target service object is that the audit is not passed, and then the full-scale node generates audit rejection output information according to the audit result that the audit is not passed; the audit veto output information belongs to the audit output information.

Please refer to fig. 6, which is an interaction diagram of another data storage method provided in the embodiment of the present application, where the data storage method includes the following steps:

step S201, the target lightweight node acquires target service data of the target service object, and sends the target service data to the full-scale node.

Step S202, the full-scale node generates a target service block corresponding to the target service data and adds the target service block to a full-scale block chain; the service blocks in the full block chain are generated by the full node according to the service data sent by at least one light weight node and are added to the full block chain; the at least one lightweight node comprises the target lightweight node.

Step S203, the total node sends the target block header of the target service block to the target lightweight node.

Step S204, the target lightweight node adds the target block head to a local service block chain; the local service block chain comprises a block header of a service block generated by service data sent by the target lightweight node to the full-scale node.

The specific implementation manner of steps S201 to S204 may refer to steps S101 to S104 in the embodiment corresponding to fig. 3, which is not described herein again.

The foregoing embodiments describe how the full-scale node constructs the full-scale blockchain, how each lightweight node constructs its own local service blockchain, and how the full-scale node audits the service data on the full-scale blockchain. How the lightweight node performs uplink verification on the service data based on the local service block chain will be described in detail below.

Step S205, the target lightweight node receives the service data to be verified, determines a fourth hash value of the service data to be verified, and the target lightweight node traverses all block headers of the local service block chain.

Specifically, spv (simple payment verification) nodes in bitcoin are used for "payment verification", that is, verifying whether a certain transaction is on the blockchain and how many confirmations are obtained.

The lightweight node in the present application can be similar to the spv node in the bitcoin, and can also verify whether a certain service data is linked up and get a plurality of small acknowledgements. The following description takes the target lightweight node as an example to verify the to-be-verified service data of the target service object (the target lightweight node and the target service object have a binding relationship):

and the target light weight node receives the service data to be verified of the target service object, which is called as the service data to be verified. And calculating a hash value of the service data to be verified based on a hash algorithm, namely a fourth hash value.

And the target lightweight node traverses all the block heads of the local service block chain and detects whether the block head containing the fourth hash value exists on the local service block chain.

Step S206, if the local service block chain has a block header containing the fourth hash value, the target lightweight node determines that the service data to be verified belongs to verified service data.

Specifically, if a block header containing the fourth hash value exists in the local service block chain, the target lightweight node sends an authentication request to the full-scale nodes, where the authentication request carries the fourth hash value, and if the number of the full-scale nodes is more than one, the target lightweight node may send an authentication request to any one full-scale node, or send an authentication request to the full-scale node that generates the block header containing the fourth hash value. The full node traverses all the service blocks in the full block chain and detects whether the service block containing the fourth hash value is stored or not;

if the service block containing the fourth hash value does not exist in the full block chain, the full node sends a verification failure message to the target lightweight node, and the target lightweight node can determine that the service data to be verified is not added to the full block chain according to the verification failure message, namely that the service data to be verified belongs to unverified service data.

If the service block containing the fourth hash value exists in the full block chain, the full node can send a verification passing message to the target lightweight node, and the target lightweight node can determine that the service data to be verified is added to the full block chain according to the verification passing message, that is, the service data to be verified belongs to the verified service data.

Further, if a service block containing the fourth hash value exists in the full block chain, the full node takes the service block containing the fourth hash value as an auxiliary service block. The full-scale node detects the number of service blocks backward adjacent to the auxiliary service block on the full-scale block chain, wherein the block heights of the service blocks backward adjacent to the auxiliary service block are all larger than the block height of the auxiliary service block.

The total node obtains a preset number threshold (the number threshold may be equal to 6), if the number of service blocks backward adjacent to the auxiliary service block is greater than the preset number threshold, it is indicated that the auxiliary service block is confirmed by a plurality of subsequent service blocks (that is, the total block chain acknowledges the existence of the auxiliary service block), the total node may send a verification passing message to the target lightweight node, and the target lightweight node may determine, according to the verification passing message, that the service data to be verified has been added to the total block chain, that is, the service data to be verified belongs to the verified service data.

The reason why the multiple service blocks exist behind the auxiliary service block needs to be verified is that the situation that the full block chain is forked (the reason for forking the block chain may be that protocols are incompatible due to protocol upgrade and may also be "double flower"), and if multiple service blocks exist behind the subsequent auxiliary service block, it is stated that the full block chain where the auxiliary service block is located is the longest legal branch chain.

If the number of the service blocks backward adjacent to the auxiliary service block is less than or equal to the preset number threshold, it is indicated that the auxiliary service block is not confirmed by the subsequent service blocks, so that the full-scale node sends a verification failure message to the target lightweight node, and the target lightweight node can determine that the service data to be verified is not added to the full-scale block chain according to the verification failure message, that is, the service data to be verified belongs to the unverified service data.

Step S207, if the local service block chain does not have a block header containing the fourth hash value, the target lightweight node determines that the service data to be verified belongs to unverified service data.

Specifically, if the local service block chain does not have a block header containing the fourth hash value, the target lightweight node may determine that the service data to be verified is not added to the full block chain, that is, the service data to be verified belongs to unverified service data.

Optionally, the local service blockchain and the full-size blockchain may be used to query target service data on the full-size blockchain, in addition to verifying whether a certain service data is uplink-linked. The specific process is as follows:

and the target light weight node responds to the query operation and generates a query request according to the target block head, wherein the query request carries the target block head.

And the target lightweight node sends the query request to the full-scale node, the full-scale node traverses the full-scale block chain, a target service block containing a target block head is searched on the full-scale block chain, target service data in the target service block is read, and the full-scale node returns the target service data to the target lightweight node.

The target business data corresponding to the target block head is searched through the target block head, and the query request can be generated according to the block hash value of the target business block by determining the block hash value of the target business block; the query here carries the chunk hash value of the target service chunk.

Similarly, the target lightweight node sends the query request to the full-scale node, the full-scale node traverses the full-scale block chain, a target service block corresponding to the block hash value of the target service block is searched on the full-scale block chain, similarly, target service data in the target service block is read, and the full-scale node returns the target service data to the target lightweight node.

By adopting the mode, the light weight node can acquire the service data stored on the whole block chain through the whole node, and the service data acquired by the light weight node can be ensured not to be falsified by relying on the non-falsification of the block chain, so that the reliability of the service data acquired by the light weight node is improved.

Please refer to fig. 7, which is a flowchart illustrating a data storage method according to an embodiment of the present application, where the embodiment describes a specific process of the data storage method from a target lightweight node side:

step S301, a target light weight node acquires target service data of a target service object and sends the target service data to a full-scale node; the target service data is used for instructing the full-scale node to generate a target service block and adding the target service block to a full-scale block chain; the service blocks in the full block chain are generated by the full node according to the service data sent by at least one light weight node and are added to the full block chain; the at least one lightweight node comprises the target lightweight node.

Specifically, the target lightweight node acquires service data (referred to as target service data) of the target service object, and sends the target service data to the full-scale nodes in the block chain network. The target service data is used for instructing the full-scale node to generate a service block (called a target service block) corresponding to the target service block and add the generated target service block to a full-scale block chain, wherein the full-scale block chain comprises a plurality of service blocks, and the plurality of service blocks are generated by service data sent by different lightweight nodes and are added to the full-scale block chain.

Step S302, the target lightweight node receives a target block head of the target service block sent by the full-scale node, and adds the target block head to a local service block chain; the local service block chain comprises a block header of a service block generated by service data sent by the target lightweight node to the full-scale node.

Specifically, the target lightweight node receives a block header (referred to as a target block header) of a target service block sent by the full-scale node, and adds the target block header to a local service block chain of the target lightweight node; the local service block chain comprises a plurality of block heads, the plurality of block heads are used for sending a plurality of service data to the full-scale node by the target lightweight node, and the full-scale node correspondingly generates the block heads of the service blocks.

The specific process of the target lightweight node adding the target block header to the local service block chain may participate in step S103 in the above embodiment corresponding to fig. 3.

Please refer to fig. 8, which is a schematic flow chart of another data storage method provided in the embodiment of the present application, and the embodiment describes a specific process of the data storage method from a full node side:

step S401, the total node receives the target business data of the target business object sent by the target light-weight node.

Step S402, the full-scale node generates a target service block corresponding to the target service data, and adds the target service block to a full-scale block chain; the service blocks in the full block chain are generated by the full node according to the service data sent by at least one light weight node and are added to the full block chain; the at least one lightweight node comprises the target lightweight node.

Specifically, the target service data includes encrypted service data and a digital signature, after the full-scale node passes the verification of the digital signature, the encrypted service data is used as a block, a hash value of the encrypted service data is calculated based on a hash algorithm, and the full-scale node combines the calculated hash value, a block hash value of a last service block in a current full-scale block chain, and a current timestamp into a block header. And the full node combines the block head and the block body into a target service block, and adds the target service block to a full block chain.

The specific process of checking the digital signature by the full node and generating the target service block may join step S102 in the embodiment corresponding to fig. 3.

Step S403, the total node sends a target block header of the target service block to the target lightweight node; the target block header is used for instructing the target lightweight node to adjust a local service block chain; the local service block chain comprises a block header of a service block generated by service data sent by the target lightweight node to the full-scale node.

Specifically, the full-scale node takes a block head of the target service block as a target block head, and sends the target block head to the target lightweight node, the target block head is used for instructing the target lightweight node to add the target block head to the local service block chain, the local service block chain comprises a plurality of block heads, the plurality of block heads are used for sending a plurality of service data to the full-scale node by the target lightweight node, and the full-scale node correspondingly generates the block head of the service block.

The full-quantity nodes in the system store complete service block chains, but the lightweight nodes only store block heads of service blocks related to the lightweight nodes, and different types of block chain nodes store different data, so that data isolation can be realized, the risk of data leakage is reduced, and the safety and the privacy of the data are improved; furthermore, the lightweight node only stores the block head of the block, and the storage space occupied by the block head is far smaller than that occupied by the whole block, so that the hardware requirement on the lightweight node can be reduced, and the hardware resource is saved.

Further, please refer to fig. 9, which is a schematic structural diagram of a data storage device according to an embodiment of the present application. As shown in fig. 9, the data storage apparatus 1 may be applied to the target lightweight node in the embodiments corresponding to fig. 1 to 7, and the data storage apparatus 1 may include: the device comprises an acquisition module 11 and a sending module 12.

An obtaining module 11, configured to obtain target service data of a target service object;

a sending module 12, configured to send the target service data to a full-scale node; the target service data is used for instructing the full-scale node to generate a target service block and adding the target service block to a full-scale block chain; the service blocks in the full block chain are generated by the full node according to the service data sent by at least one light weight node and are added to the full block chain; the at least one lightweight node comprises the target lightweight node;

the sending module 12 is further configured to receive a target block header of the target service block sent by the full-scale node, and add the target block header to a local service block chain; the local service block chain comprises a block header of a service block generated by service data sent by the target lightweight node to the full-scale node.

For specific functional implementation manners of the obtaining module 11 and the sending module 12, reference may be made to step S101, step S103 to step S104 in the embodiment corresponding to fig. 3, which is not described herein again.

Referring to fig. 9, the data storage device 1 may include an obtaining module 11, a sending module 12, and may further include: a traversal module 13, a first determination module 14 and a second determination module 15.

The sending module 12 is further configured to receive to-be-verified service data of the target service object, and determine a fourth hash value of the to-be-verified service data;

a traversing module 13, configured to traverse all block headers of the local service block chain;

a first determining module 14, configured to determine that the to-be-verified service data belongs to verified service data if a block header including the fourth hash value exists in the local service block chain;

a second determining module 15, configured to determine that the to-be-verified service data belongs to unverified service data if the local service block chain does not have a block header including the fourth hash value;

a first determining module 14, configured to send, by the target lightweight node, a verification request to the full-scale node if a chunk header including the fourth hash value exists in the local service chunk chain; the verification request comprises the fourth hash value, and if the lightweight node receives a verification passing message sent by the full-scale node aiming at the verification request, the target lightweight node determines that the to-be-verified service data belongs to the verified service data; the verification passing message is generated when the full-volume node detects that a traffic block containing the fourth hash value exists on the full-volume block chain and the number of backward adjacent traffic blocks in the full-volume chain to the traffic block containing the fourth hash value is greater than a number threshold.

The specific processes of the traversing module 13, the first determining module 14 and the second determining module 15 can refer to steps S205 to S207 in the corresponding embodiment of fig. 6.

Referring to fig. 9, the obtaining module 11 may include: an acquisition unit 111 and an encryption unit 112.

An obtaining unit 111, configured to obtain service data to be sent of the target service object;

an encrypting unit 112, configured to encrypt the service data to be sent according to the public key of the target lightweight node to obtain encrypted service data, determine a first hash value of the encrypted service data, encrypt the first hash value according to the private key of the target lightweight node to generate a digital signature, and combine the encrypted service data and the digital signature into the target service data;

the obtaining unit 111 is specifically configured to obtain to-be-detected service data of the target service object, detect a data type of the to-be-detected service data, and determine the to-be-detected service data as the to-be-detected service data if the data type matches the object permission type of the target service object.

The specific functional implementation manners of the obtaining unit 111 and the encrypting unit 112 may refer to step 101 in the embodiment corresponding to fig. 3, which is not described herein again.

Further, please refer to fig. 10, which is a schematic structural diagram of another data storage device according to an embodiment of the present application. As shown in fig. 10, the data storage device 2 may be applied to the full-scale nodes in the embodiments corresponding to fig. 1 to fig. 7, and the data storage device 2 may include: a receiving module 21 and a generating module 22.

A receiving module 21, configured to receive target service data of a target service object sent by a target lightweight node;

a generating module 22, configured to generate a target service block corresponding to the target service data;

the receiving module 21 is further configured to add the target service block to a full-size block chain; the service blocks in the full block chain are generated by the full node according to the service data sent by at least one light weight node and are added to the full block chain; the at least one lightweight node comprises the target lightweight node;

the receiving module 21 is further configured to send a target block header of the target service block to the target lightweight node; the target block header is used for instructing the target lightweight node to adjust a local service block chain; the local service block chain comprises a block head of a service block generated by service data sent by the target lightweight node to the full-scale node;

a generating module 22, specifically configured to receive the target service data sent by the target lightweight node; the target service data comprises encrypted service data and a digital signature; and acquiring a public key of the target lightweight node, decrypting the digital signature according to the public key of the target lightweight node to obtain a second hash value, determining a third hash value of the encrypted service data, and if the second hash value is the same as the third hash value, generating the target service block according to the encrypted service data.

For specific functional implementation of the receiving module 21 and the generating module 22, reference may be made to step S102 in the embodiment corresponding to fig. 3, which is not described herein again.

Referring to fig. 10, the data storage apparatus 1 may include a receiving module 21 and a generating module 22, and may further include: an extraction module 23 and an audit module 24.

The receiving module 21 is further configured to, when an audit request for the target service object is received, obtain the full block chain according to the audit request;

the receiving module 21 is further configured to obtain the target service block corresponding to the target service object from the full block chain;

the extracting module 23 is configured to obtain service data to be sent according to the target service block; the service data to be sent is the service data after the encrypted service data is decrypted; the encrypted service data belongs to the target service data;

the auditing module 24 is configured to perform service auditing on the service data to be sent, and generate auditing output information corresponding to the auditing request according to an auditing result;

the extracting module 23 is specifically configured to extract the block of the target service block as encrypted service data, obtain the private key of the target lightweight node, and decrypt the encrypted service data according to the private key of the target lightweight node to obtain the service data to be sent.

The specific processes of the extracting module 23 and the auditing module 24 can refer to step S103 in the embodiment corresponding to fig. 3.

Further, please refer to fig. 11, which is a schematic structural diagram of an electronic device according to an embodiment of the present invention. The target lightweight node in the embodiments corresponding to fig. 1 to fig. 7 may be an electronic device 1000, as shown in fig. 11, where the electronic device 1000 may include: a user interface 1002, a processor 1004, an encoder 1006, and a memory 1008. Signal receiver 1016 is used to receive or transmit data via cellular interface 1010, WIFI interface 1012. The encoder 1006 encodes the received data into a computer-processed data format. The memory 1008 has stored therein a computer program by which the processor 1004 is arranged to perform the steps of any of the method embodiments described above. The memory 1008 may include volatile memory (e.g., dynamic random access memory DRAM) and may also include non-volatile memory (e.g., one time programmable read only memory OTPROM). In some examples, the memory 1008 can further include memory located remotely from the processor 1004, which can be connected to the electronic device 1000 via a network. The user interface 1002 may include: a keyboard 1018, and a display 1020.

In the electronic device 1000 shown in fig. 11, the processor 1004 may be configured to call the memory 1008 to store a computer program to implement:

acquiring target service data of a target service object, and sending the target service data to a full-scale node; the target service data is used for instructing the full-scale node to generate a target service block and adding the target service block to a full-scale block chain; the service blocks in the full block chain are generated by the full node according to the service data sent by at least one light weight node and are added to the full block chain; the at least one lightweight node comprises the target lightweight node;

receiving a target block head of the target service block sent by the full-scale node, and adding the target block head to a local service block chain; the local service block chain comprises a block header of a service block generated by service data sent by the target lightweight node to the full-scale node.

It should be understood that the electronic device 1000 described in the embodiment of the present invention may perform the description of the data storage method in the embodiment corresponding to fig. 1 to fig. 7, and may also perform the description of the data storage device 1 in the embodiment corresponding to fig. 8, which is not described herein again. In addition, the beneficial effects of the same method are not described in detail.

Further, here, it is to be noted that: an embodiment of the present invention further provides a computer storage medium, and the computer storage medium stores the aforementioned computer program executed by the data storage device 1, and the computer program includes program instructions, and when the processor executes the program instructions, the description of the data storage method in the embodiment corresponding to fig. 1 to 7 can be performed, so that details are not repeated here. In addition, the beneficial effects of the same method are not described in detail. For technical details not disclosed in the embodiments of the computer storage medium to which the present invention relates, reference is made to the description of the method embodiments of the present invention.

Further, please refer to fig. 12, which is a schematic structural diagram of another electronic device according to an embodiment of the present invention. The full-scale node in the embodiments corresponding to fig. 1 to fig. 7 may be an electronic device 1000, as shown in fig. 12, where the electronic device 1000 may include: a user interface 1002, a processor 1004, an encoder 1006, and a memory 1008. Signal receiver 1016 is used to receive or transmit data via cellular interface 1010, WIFI interface 1012. The encoder 1006 encodes the received data into a computer-processed data format. The memory 1008 has stored therein a computer program by which the processor 1004 is arranged to perform the steps of any of the method embodiments described above. The memory 1008 may include volatile memory (e.g., dynamic random access memory DRAM) and may also include non-volatile memory (e.g., one time programmable read only memory OTPROM). In some examples, the memory 1008 can further include memory located remotely from the processor 1004, which can be connected to the electronic device 1000 via a network. The user interface 1002 may include: a keyboard 1018, and a display 1020.

In the electronic device 1000 shown in fig. 12, the processor 1004 may be configured to call the memory 1008 to store a computer program to implement:

receiving target business data of a target business object sent by a target lightweight node;

generating a target service block corresponding to the target service data, and adding the target service block to a full block chain; the service blocks in the full block chain are generated by the full node according to the service data sent by at least one light weight node and are added to the full block chain; the at least one lightweight node comprises the target lightweight node;

sending a target block header of the target service block to the target lightweight node; the target block header is used for instructing the target lightweight node to adjust a local service block chain; the local service block chain comprises a block header of a service block generated by service data sent by the target lightweight node to the full-scale node.

It should be understood that the electronic device 1000 described in the embodiment of the present invention may perform the description of the data storage method in the embodiment corresponding to fig. 1 to fig. 7, and may also perform the description of the data storage device 2 in the embodiment corresponding to fig. 9, which is not described herein again. In addition, the beneficial effects of the same method are not described in detail.

Further, here, it is to be noted that: an embodiment of the present invention further provides a computer storage medium, and the computer storage medium stores the aforementioned computer program executed by the data storage device 2, and the computer program includes program instructions, and when the processor executes the program instructions, the description of the data storage method in the embodiment corresponding to fig. 1 to 7 can be performed, so that details are not repeated here. In addition, the beneficial effects of the same method are not described in detail. For technical details not disclosed in the embodiments of the computer storage medium to which the present invention relates, reference is made to the description of the method embodiments of the present invention.

It will be understood by those skilled in the art that all or part of the processes of the methods of the embodiments described above can be implemented by a computer program, which can be stored in a computer-readable storage medium, and when executed, can include the processes of the embodiments of the methods described above. The storage medium may be a magnetic disk, an optical disk, a Read-Only Memory (ROM), a Random Access Memory (RAM), or the like.

The above disclosure is only for the purpose of illustrating the preferred embodiments of the present invention, and it is therefore to be understood that the invention is not limited by the scope of the appended claims.

Claims

1. A data storage method is applied to a management node and is characterized by comprising the following steps:

the target lightweight node adds the target block header to a local service block chain; the local service block chain comprises a block head of a service block generated by service data sent by the target lightweight node to the full-scale node, the local service block chain of the target lightweight node is used for storing the block head of a block related to the target lightweight node, and the block head in the local service block chain of each lightweight node is different.

2. The method of claim 1, further comprising:

3. The method of claim 2, wherein the obtaining service data to be sent according to the target service block comprises:

the full-scale node acquires a private key of the target lightweight node;

4. The method of claim 1, further comprising:

5. The method of claim 4, wherein the determining, by the target lightweight node, that the to-be-verified service data belongs to verified service data if a chunk header containing the fourth hash value exists in the local service chunk chain comprises:

if the lightweight node receives a verification passing message sent by the full-scale node aiming at the verification request, the target lightweight node determines that the to-be-verified service data belongs to the verified service data; the verification passing message is generated when the full-volume node detects that a traffic block containing the fourth hash value exists on the full-volume block chain and the number of traffic blocks backward adjacent to the traffic block containing the fourth hash value in the full-volume block chain is greater than a number threshold.

6. The method of claim 1, wherein the target lightweight node obtaining target business data for a target business object comprises:

7. The method of claim 6, wherein the obtaining, by the target lightweight node, service data to be sent of the target service object comprises:

8. The method of claim 1, wherein the quorum node generates a target traffic block corresponding to the target traffic data, comprising:

the full-scale node receives the target service data sent by the target lightweight node; the target service data comprises encrypted service data and a digital signature;

9. A method of storing data, comprising:

the target lightweight node receives a target block head of the target service block sent by the full-scale node, and adds the target block head to a local service block chain; the local service block chain comprises a block head of a service block generated by service data sent by the target lightweight node to the full-scale node, the local service block chain of the target lightweight node is used for storing the block head of a block related to the target lightweight node, and the block head in the local service block chain of each lightweight node is different.

10. A method of storing data, comprising:

the full-scale node sends a target block head of the target service block to the target lightweight node; the target block header is used for instructing the target lightweight node to adjust a local service block chain; the local service block chain comprises a block head of a service block generated by service data sent by the target lightweight node to the full-scale node, the local service block chain of the target lightweight node is used for storing the block head of a block related to the target lightweight node, and the block head in the local service block chain of each lightweight node is different.

11. A data storage device applied to a target light weight node is characterized by comprising:

the sending module is further configured to receive a target block header of the target service block sent by the full-scale node, and add the target block header to a local service block chain; the local service block chain comprises a block head of a service block generated by service data sent by the target lightweight node to the full-scale node, the local service block chain of the target lightweight node is used for storing the block head of a block related to the target lightweight node, and the block head in the local service block chain of each lightweight node is different.

12. A data storage device for use with a quantum node, comprising:

the receiving module is further configured to send a target block header of the target service block to the target lightweight node; the target block header is used for instructing the target lightweight node to adjust a local service block chain; the local service block chain comprises a block head of a service block generated by service data sent by the target lightweight node to the full-scale node, the local service block chain of the target lightweight node is used for storing the block head of a block related to the target lightweight node, and the block head in the local service block chain of each lightweight node is different.

13. An electronic device comprising a memory and a processor, the memory storing a computer program that, when executed by the processor, causes the processor to perform the steps of the method according to any one of claims 1-10.

14. A computer storage medium, characterized in that the computer storage medium stores a computer program comprising program instructions which, when executed by a processor, perform the method according to any one of claims 1-10.