CN112883117B

CN112883117B - Data synchronization method, equipment and computer readable storage medium

Info

Publication number: CN112883117B
Application number: CN202110268813.9A
Authority: CN
Inventors: 李茂材; 王宗友; 时一防; 蓝虎
Original assignee: Tencent Technology Shenzhen Co Ltd
Current assignee: Tencent Technology Shenzhen Co Ltd
Priority date: 2020-12-24
Filing date: 2020-12-24
Publication date: 2022-03-15
Anticipated expiration: 2040-12-24
Also published as: CN112287033B; CN112287033A; CN112883117A

Abstract

The embodiment of the application discloses a data synchronization method, data synchronization equipment and a computer readable storage medium, wherein the method comprises the following steps: acquiring a data synchronization request comprising a node identifier and a block identifier; acquiring synchronous transaction data in the synchronous block according to the block identification, and acquiring a target data set comprising read data or result data; determining a target synchronous read transaction execution function aiming at the transaction detail data according to the contract information and the data synchronous request; determining a synchronous data set according to the transaction detail data, the node identification and the target synchronous read transaction execution function; and acquiring verification data, and returning the synchronous transaction data, the verification data and the synchronous data set to the light node, so that the light node verifies the validity of the to-be-verified result data corresponding to the synchronous transaction data and the transaction detail data according to the verification data and the synchronous data set. By adopting the method and the device, the space cost of the light node can be reduced, and the validity of the synchronized data can be ensured.

Description

Data synchronization method, equipment and computer readable storage medium

The present application is a divisional application of chinese patent application filed 24/12/2020 and having application number 202011544909.5 entitled "a data synchronization method, apparatus, and computer readable storage medium", the entire contents of which are incorporated herein by reference.

Technical Field

The present application relates to the field of internet technologies, and in particular, to a data synchronization method, device, and computer-readable storage medium.

Background

With the rapid development of network technology and the emphasis of governments and enterprises on data security, the blockchain has received great attention and application.

The block chain comprises a full amount of nodes and light nodes, wherein the full amount of nodes have full amount of data and participate in accounting consensus, and the light nodes mainly perform service execution and do not participate in accounting consensus, but obtain block header data and part of authorized visible block data from the consensus network in an identity authentication mode. Therefore, the node of the whole quantity needs to broadcast the block header of the new block which is identified by the Peer-to-Peer (P2P) network layer, so that the light node performs data synchronization on the new block.

In the existing data synchronization technology, such as an ethernet workshop, an Enterprise Operating System (EOS), and the like, when a light node requests data in a synchronization block from a full node, the full node returns the synchronization block to the light node, and then the light node retains the data needed by itself in the synchronization block. Obviously, the transmission of the sync block has a defect of large amount of sync data, which may increase the space cost of the light node.

In addition, in the prior art, the light node cannot perform self-check on the acquired data, and if a bad behavior exists in the blockchain network, the light node cannot determine the accuracy of the acquired data, so that the validity of the synchronized data cannot be guaranteed.

Disclosure of Invention

Embodiments of the present application provide a data synchronization method, device, and computer-readable storage medium, which can not only reduce the space cost of a light node, but also ensure the validity of synchronized data.

An aspect of the present application provides a data synchronization method, including:

acquiring a data synchronization request sent by a light node; the data synchronization request comprises a node identification of the light node and a block identification of the synchronization block;

acquiring synchronous transaction data in the synchronous block according to the block identification, and acquiring a target data set associated with the synchronous transaction data; the synchronized transaction data includes transaction detail data and contract information for executing smart contracts for the transaction detail data; the target data set comprises read data or result data obtained when executing the transaction detail data based on the contract information;

determining a target synchronous read transaction execution function aiming at the transaction detail data according to the contract information and the data synchronous request;

determining a synchronous data set from the target data set according to the transaction detail data, the node identification and the target synchronous read transaction execution function;

and acquiring verification data corresponding to the synchronous transaction data from the synchronous block, and returning the synchronous transaction data, the verification data and the synchronous data set to the light node, so that the light node verifies the validity of the to-be-verified result data corresponding to the synchronous transaction data and the transaction detail data according to the verification data and the synchronous data set.

sending a data synchronization request carrying a block identifier to a full-scale node so that the full-scale node acquires synchronous transaction data, verification data and a synchronous data set according to the data synchronization request and the block identifier; the synchronous transaction data is data in a synchronous block determined by the full-scale node according to the block identification, and comprises transaction detail data and contract information of an intelligent contract used for executing the transaction detail data; the synchronous data set is a set determined by the full-volume nodes from the target data set according to the transaction detail data, the node identification of the light node and the target synchronous read transaction execution function; the target synchronous read transaction execution function is a function for transaction detail data determined by the full-scale node according to the contract information and the data synchronous request; the target data set is a set which is associated with the synchronous transaction data and comprises read data or result data obtained by the full-scale nodes when executing the transaction detail data based on the contract information;

acquiring synchronous transaction data, verification data and a synchronous data set sent by a full amount of nodes;

and verifying the validity of the to-be-verified result data corresponding to the synchronous transaction data and the transaction detail data according to the verification data and the synchronous data set.

An aspect of the present application provides a data synchronization apparatus, including:

the first acquisition module is used for acquiring a data synchronization request sent by the light node; the data synchronization request comprises a node identification of the light node and a block identification of the synchronization block;

the second acquisition module is used for acquiring synchronous transaction data in the synchronous block according to the block identifier and acquiring a target data set associated with the synchronous transaction data; the synchronized transaction data includes transaction detail data and contract information for executing smart contracts for the transaction detail data; the target data set comprises read data or result data obtained when executing the transaction detail data based on the contract information;

the first determining module is used for determining a target synchronous read transaction executing function aiming at the transaction detail data according to the contract information and the data synchronous request;

the second determining module is used for determining a synchronous data set from the target data set according to the transaction detail data, the node identification and the target synchronous read transaction executing function;

and the second acquisition module is used for acquiring verification data corresponding to the synchronous transaction data from the synchronous block and returning the synchronous transaction data, the verification data and the synchronous data set to the light node, so that the light node verifies the legality of the to-be-verified result data corresponding to the synchronous transaction data and the transaction detail data according to the verification data and the synchronous data set.

Wherein, the second acquisition module includes:

a first acquisition unit, configured to acquire a candidate data set associated with the synchronous transaction data from the full-scale database; the candidate data set comprises read data and result data obtained when executing the transaction detail data based on the contract information;

a capacity comparison unit for comparing the data capacity of the read data with the data capacity of the result data;

a first determining unit, configured to determine the read data as a target data set if the data capacity of the read data is smaller than the data capacity of the result data;

the first determining unit is further configured to determine the result data as the target data set if the data capacity of the read data is equal to or greater than the data capacity of the result data.

Wherein, the first determining module comprises:

a second obtaining unit, configured to obtain a contract name and a transaction execution function name in the contract information; the contract name is used for representing the name of an intelligent contract for executing the transaction detail data, and the transaction execution function name is used for representing the name of a transaction execution function called by the intelligent contract and used for executing the transaction detail data;

the third acquisition unit is used for acquiring a synchronous read name according to the data synchronous request and determining the synchronous read transaction execution function name according to the transaction execution function name and the synchronous read name;

and the second determining unit is used for determining a target synchronous read transaction execution function in the intelligent contract according to the synchronous read transaction execution function name.

Wherein, the second determining module comprises:

the third determining unit is used for determining the synchronous authority of the light node for the synchronous transaction data according to the node identification and the target synchronous read transaction executing function; the synchronous authority comprises a synchronous legal authority and a synchronous illegal authority;

the return failure unit is used for returning data synchronization failure information to the light node if the synchronization authority of the light node aiming at the synchronous transaction data is a synchronous illegal authority;

and the fourth determining unit is used for determining a synchronous data set from the target data set according to the transaction detail data, the node identification and the target synchronous read transaction executing function if the synchronous authority of the light node for the synchronous transaction data is a synchronous legal authority.

Wherein the fourth determination unit includes:

the first determining subunit is used for determining an existing data set which is stored by the light node and is associated with the transaction detail data according to the transaction detail data, the node identification and the target synchronous read transaction executing function;

and the second determining subunit is used for filtering the existing data set from the target data set and determining the filtered target data set as a synchronous data set.

Wherein, the third acquisition module includes:

a fourth obtaining unit, configured to obtain the transaction state tree and the result state tree from the synchronization block; the transaction state tree is a transaction Mercker tree generated based on the transaction detail data; the result state tree is a result merkel tree generated based on the result data;

a fifth obtaining unit, configured to obtain transaction verification data from the transaction state tree based on the transaction detail data, and obtain result verification data from the result state tree based on the result data;

a fifth determining unit for determining the transaction verification data and the result verification data as verification data.

Wherein, the data synchronizer further comprises:

the fourth acquisition module is used for acquiring the transaction detail data in the block to be linked and calling a transaction execution function in the intelligent contract for executing the transaction detail data;

the fifth acquisition module is used for acquiring historical transaction data aiming at the transaction detail data according to the transaction execution function and determining the historical transaction data as read data;

the transaction executing function module is used for executing a transaction executing function according to the read data and the transaction detail data to obtain a transaction executing result of the transaction detail data;

and the block uplink module is used for performing uplink processing on the block to be uplink according to the transaction detail data and the transaction execution result.

Wherein, the block uplink module comprises:

the first generation unit is used for generating result data according to the transaction execution result when the transaction detail data and the transaction execution result are both identified;

the second generation unit is used for generating a transaction state tree according to the transaction detail data, generating a result state tree according to the result data, and adding the transaction state tree and the result state tree to the block to be linked;

a sixth determining unit, configured to determine the block to be linked with the transaction status tree and the result status tree as a synchronization block, and add the synchronization block to the block chain;

and the third generating unit is used for generating a target data set according to the read data and the result data and storing the target data set in the full database.

the sending request module is used for sending a data synchronization request carrying the block identifier to the full-scale node so that the full-scale node can acquire synchronous transaction data, verification data and a synchronous data set according to the data synchronization request and the block identifier; the synchronous transaction data is data in a synchronous block determined by the full-scale node according to the block identification, and comprises transaction detail data and contract information of an intelligent contract used for executing the transaction detail data; the synchronous data set is a set determined by the full-volume nodes from the target data set according to the transaction detail data, the node identification of the light node and the target synchronous read transaction execution function; the target synchronous read transaction execution function is a function for transaction detail data determined by the full-scale node according to the contract information and the data synchronous request; the target data set is a set which is associated with the synchronous transaction data and comprises read data or result data obtained by the full-scale nodes when executing the transaction detail data based on the contract information;

the data acquisition module is used for acquiring synchronous transaction data, verification data and a synchronous data set sent by the full-scale nodes;

and the verification data module is used for verifying the validity of the to-be-verified result data corresponding to the synchronous transaction data and the transaction detail data according to the verification data and the synchronous data set.

Wherein, verify the data module, include:

the acquisition information unit is used for acquiring a contract name and a transaction execution function name in the contract information; the contract name is used for representing the name of an intelligent contract for executing the transaction detail data of the full-scale node, and the transaction execution function name is used for representing the name of a transaction execution function called by the intelligent contract and used for executing the transaction detail data;

the first determining unit is used for acquiring a synchronous writing name according to the synchronous data set and the synchronous transaction data and determining a synchronous writing transaction execution function name according to the transaction execution function name and the synchronous writing name;

the second determining unit is used for determining a target synchronous write transaction execution function in the intelligent contract according to the synchronous write transaction execution function name;

and the second determining unit is also used for verifying the validity of the to-be-verified result data corresponding to the synchronous transaction data and the transaction detail data according to the target synchronous writing transaction execution function, the synchronous data set and the verification data.

Wherein the second determining unit includes:

the determining set subunit is used for determining an existing data set aiming at the transaction detail data in the light node book according to the node identification, the transaction detail data and the target synchronous writing transaction execution function;

the target set subunit is used for merging the existing data set and the synchronous data set to obtain a target data set;

and the verification data subunit is used for verifying the validity of the to-be-verified result data corresponding to the synchronous transaction data and the transaction detail data according to the target data set and the verification data.

Wherein, verify the data subunit, include:

the first verification subunit is used for determining the result data as to-be-verified result data corresponding to the transaction detail data if the target data set is the result data, obtaining a first to-be-verified root hash according to the transaction detail data, the to-be-verified result data and the verification data, and verifying the validity of the synchronous transaction data and the to-be-verified result data according to the first to-be-verified root hash;

the first determining subunit is used for determining a transaction executing function according to the name of the transaction executing function if the target data set is read data;

the second determining subunit is used for inputting the read data and the transaction detail data into a transaction executing function to obtain a to-be-verified transaction executing result of the transaction detail data, and generating to-be-verified result data according to the to-be-verified transaction executing result;

and the second verification subunit is used for obtaining a second root hash to be verified according to the transaction detail data, the result data to be verified and the verification data, and verifying the validity of the synchronous transaction data and the result data to be verified according to the second root hash to be verified.

Wherein the verification data comprises transaction verification data and result verification data; the first root hash to be verified comprises a transaction root hash to be verified and a root hash of a result to be verified;

the second verification subunit is specifically configured to obtain a transaction root hash to be verified according to the transaction detail data and the transaction verification data, and obtain a result root hash to be verified according to the result data to be verified and the result verification data;

the second verification subunit is further specifically configured to obtain a chunk header for the synchronization chunk, and obtain a verified transaction root hash and a verified result root hash from the chunk header;

the second verification subunit is further specifically configured to compare the transaction root hash to be verified with the verified transaction root hash, and compare the root hash to be verified with the root hash to be verified;

the second verification subunit is further specifically configured to determine that the synchronous transaction data is illegal data if the hash of the transaction root to be verified is different from the hash of the verified transaction root, and determine that the synchronous transaction data is legal data if the hash of the transaction root to be verified is the same as the hash of the verified transaction root;

the second verification subunit is further specifically configured to determine that the result data to be verified is illegal data if the root hash of the result to be verified is different from the root hash of the result already verified, and determine that the result data to be verified is legal data if the root hash of the result to be verified is the same as the root hash of the result already verified;

the second verification subunit is further specifically configured to, when the synchronous transaction data is legal data and the data of the result to be verified is legal data, perform associated storage on the data of the result to be verified and the synchronous transaction data.

One aspect of the present application provides a computer device, comprising: a processor, a memory, a network interface;

the processor is connected to the memory and the network interface, wherein the network interface is used for providing a data communication function, the memory is used for storing a computer program, and the processor is used for calling the computer program to enable the computer device to execute the method in the embodiment of the application.

An aspect of the present embodiment provides a computer-readable storage medium, in which a computer program is stored, where the computer program is adapted to be loaded by a processor and to execute the method in the present embodiment.

An aspect of an embodiment of the present application provides a computer program product or a computer program, where the computer program product or the computer program includes computer instructions, and the computer instructions are stored in a computer-readable storage medium; the processor of the computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions to cause the computer device to perform the method in the embodiment of the present application.

In the embodiment of the application, when a data synchronization request for a certain block (namely, a synchronization block) sent by a light node is acquired, the application does not return the whole synchronization block to the light node, and the synchronization transaction data in the synchronization block is acquired first, and then a target data set for the synchronization transaction data is acquired, wherein the synchronization transaction data comprises transaction detail data and contract information of an intelligent contract for executing the transaction detail data; according to contract information and a data synchronization request, a target synchronous read transaction execution function aiming at transaction detail data can be determined; based on the node identification and the target synchronous read transaction execution function, the synchronous data set can be determined from the target data set, the data synchronized to the light node is perfected, the data transmission quantity can be reduced, and therefore the space cost of the light node can be reduced; further, verification data is obtained, and the synchronous transaction data, the verification data and the synchronous data set are sent to the light node, and since the synchronous data set comprises read data or result data obtained when transaction detail data are executed based on contract information, the light node can accurately obtain to-be-verified result data corresponding to the transaction detail data through the synchronous data set, and therefore the light node can accurately verify the validity of the synchronous transaction data and the to-be-verified result data through the verification data and the synchronous data set.

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 according to an embodiment of the present application;

fig. 2 is a schematic flowchart of a data synchronization method according to an embodiment of the present application;

fig. 3 is a schematic view of a data consensus provided in an embodiment of the present application;

FIG. 4 is a schematic diagram of a data consensus scenario provided by an embodiment of the present application;

fig. 5 is a schematic flowchart of a data synchronization method according to an embodiment of the present application;

fig. 6 is a schematic view of a data synchronization scenario provided in an embodiment of the present application;

fig. 7 is a schematic view of a data synchronization scenario provided in an embodiment of the present application;

fig. 8 is a schematic flowchart of a data synchronization method according to an embodiment of the present application;

fig. 9 is a schematic view of a scenario of data self-checking provided in an embodiment of the present application;

fig. 10 is a schematic flowchart of a data synchronization method according to an embodiment of the present application;

FIG. 11 is a schematic diagram of a scenario of a target data store according to an embodiment of the present application;

fig. 12 is a schematic structural diagram of a data synchronization apparatus according to an embodiment of the present application;

fig. 13 is a schematic structural diagram of a data synchronization apparatus according to an embodiment of the present application;

FIG. 14 is a schematic structural diagram of a computer device according to an embodiment of the present disclosure;

fig. 15 is a schematic structural diagram of a computer device according to an embodiment of the present application.

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.

For ease of understanding, the following brief explanation of partial nouns is first made:

1. block chains: in a narrow sense, a block chain is a chain data structure taking a block as a basic unit, and the transaction history acquired before is verified by using a digital abstract in the block, so that the block chain is suitable for the requirements of tamper resistance and expandability in a distributed accounting scene; in a broad sense, blockchain also refers to distributed accounting techniques implemented by blockchain architecture, including distributed consensus, privacy and security protection, peer-to-peer communication techniques, network protocols, intelligent contracts, and the like. The goal of the blockchain is to implement a distributed data record ledger that allows only additions and not deletions. The basic structure of the ledger bottom layer is a linear linked list. The linked list is composed of a series of 'blocks', the Hash (Hash) value of the previous block is recorded in the subsequent block, and whether each block (and the transaction in the block) is legal or not can be quickly checked by calculating the Hash value. If a node in the network proposes to add a new block, a consensus has to be established for the block via a consensus mechanism.

2. Hash (hash) value: also called information characteristic value or characteristic value, a hash value is generated by converting input data of an arbitrary length into a password by a hash algorithm and fixedly outputting, and original input data cannot be retrieved by decrypting the hash value, which is a one-way encryption function. In a blockchain, each block (except the original block) contains the hash value of the succeeding block, which is referred to as the parent block of the current block. Hash values are the core foundation and most important aspect of the potential in blockchain technology, which preserves the authenticity of the record and view data, as well as the integrity of the blockchain as a whole.

3. Intelligent contract: is a computer protocol intended to propagate, validate or execute contracts in an informational manner. In a blockchain system, an intelligent contract is a code that each node of the blockchain can understand and execute, and can execute any logic and obtain a result. In practical applications, intelligent contracts are managed and tried through transactions on blockchains. Each transaction corresponds to a Remote Procedure Call (RPC) request to the blockchain system. If the smart contract is said to correspond to an executable program, the blockchain corresponds to the operating system that provides the runtime environment. A blockchain may contain a plurality of contracts, distinguished by contract account number (ID), identification number, or name.

4. Contract management: management operations such as deployment, upgrade, and deletion may be divided. The execution logic of a contract is changed by creating or modifying code in the blockchain system that specifies the contract (i.e., an intelligent contract, which is described below as an intelligent contract) by initiating a transaction (request).

5. Contract execution: by initiating a transaction, the user may invoke a contract that has been deployed on the blockchain. Each node in the block chain system runs the same contract respectively. For contracts that require data to be read, the node's own ledger is accessed. Finally, the nodes mutually verify whether the execution results are consistent (consensus), and if the execution results are consistent, the nodes store necessary results into respective accounts and return the results to the user.

6. Reading and writing set: the contract records the operation of the node account data during execution. The data read from the ledger and the data to be written into the ledger are respectively divided into a read set and a write set when the intelligent contract is executed.

7. Full node and light node: the block chain network comprises a full node and a light node, wherein the full node has all data, the light node has partial data, but the light node still needs to verify that the data synchronized from the full node is true and reliable. The application example is that the tax administration is a full node, the provincial tax administration is a light node, and the city tax administration is also a light node. The highest court is the full node and the local court is the light node. Banks are full nodes, enterprises are light nodes, and so on. As long as the traffic has an unequal relationship, a full number of nodes and light nodes are needed in the system to protect data privacy.

8. Merkel Tree (Merkle Tree): also commonly referred to as Hash trees (Hash trees) or state trees. As the name implies, is a tree that stores hash values. The leaf of the Merkle tree is a hash value of a data block, and the data block includes a file or a collection of files, in this embodiment, the data block may be understood as a block, and the file may include transaction detail data or a transaction execution result of the transaction detail data in the block, or a result data corresponding to the transaction detail data.

When blockchains are used in some scenarios of government or commercial establishments, not all participating nodes (which may include full and light nodes) in the blockchain have sufficient resources and necessity to be consensus nodes of the blockchain. For the security of data, when related data of personal privacy or national security are involved in the blockchain system, the common blockchain deployment manner of data pair is not applicable. Therefore, the method can ensure the privacy of the data and can properly disclose the data.

Referring to fig. 1, fig. 1 is a schematic diagram of a system architecture according to an embodiment of the present disclosure. As shown in fig. 1, the system architecture may be a blockchain network 10, wherein the blockchain network 10 may include a witness network 10a and a consensus network 10 b; the nodes in the witness network 10a may be referred to as light nodes, which possess partial data, and the light nodes mainly perform service execution, do not participate in accounting consensus, and obtain the block header data and partial authorization visible block data (including the above synchronous transaction data) from the consensus network 10b by means of identity authentication. The consensus network 10b may also be referred to as a core network, and the nodes in the consensus network 10b may be referred to as full-scale nodes, which possess full-scale data. The witness network 10a and the consensus network 10b are in different network environments, and generally speaking, the witness network 10a is in a public network and the consensus network 10b is in a private network, and the two interact through a routing boundary.

Referring again to fig. 1, witness network 10a may include light node 101a, light node 102a, light nodes 103a, …, light node 104 a. It is understood that the witness network 10a may include one or more witness networks, and in practical applications, one or more types of witness networks may be set due to different application scenarios, and the number of witness networks will not be limited herein. The witness network 10a described above may include one or more light nodes, and the number of light nodes will not be limited herein.

Referring again to fig. 1, consensus network 10b may include a quorum node 101b, a quorum node 102b, a quorum node 103b, …, and a quorum node 104 b. It is understood that the above-mentioned consensus network 10b may include one or more consensus networks, and in practical applications, one or more types of consensus networks may be set due to different application scenarios, and the number of the consensus networks will not be limited herein. The consensus network 10b may include one or more quorum nodes, where the number of quorum nodes is not limited.

Each node (including the light nodes in the witness network 10a and the full nodes in the consensus network 10 b) may receive data sent from the outside during normal operation, perform block uplink processing based on the received data, and may also send data to the outside. In order to ensure data intercommunication between the nodes, there may be a data connection between each node, for example, there may be a data connection between the light node 101a and the light node 102a, a data connection between the light node 101a and the light node 103a, and a data connection between the full node 101b and the full node 104 b.

Further, it is seen that there is a data connection between the network 10a and the consensus network 10b, for example, there is a data connection between the light node 101a and the full node 102b, a data connection between the light node 101a and the full node 103b, and a data connection between the full node 101b and the light node 104 a.

It will be appreciated that data or block transfers between nodes may be via the data connections described above. The block chain network 10 may implement data connection between nodes based on node identifiers, each node in the block chain network 10 has a node identifier corresponding thereto, and each node may store node identifiers of other nodes having a connection relationship with itself, so that the acquired data or the generated block is broadcast to other nodes according to the node identifiers of other nodes in the following, for example, a node identifier list shown in table 1 may be maintained in the light node 101a, and the node identifier list stores node names and node identifiers of other nodes.

TABLE 1

Node name	Node markSign board
		Light node
102a	117.114.151.174
		Light node 103a	117.116.189.145
…	…
		Light node 104a	119.123.789.258
Full quantum node 101b	117.114.151.183
		Quantum node 102b	117.116.189.125
Quantum node 103b	119.250.485.362
		Quantum node 104b	119.123.789.369

The node identifier may be an Internet Protocol (IP) address and any other information that can be used to identify a node in the blockchain network 10, and only the IP address is used as an example in table 1.

Assuming that the node identifier of the light node 101a is 117.116.156.425, the light node 101a may send a data synchronization request to the full-scale node 101b through the node identifier 117.114.151.183, and the full-scale node 101b may know that the data synchronization request is sent by the light node 101a through the node identifier 117.116.156.425; similarly, the light node 101a may send the transaction data a to the light node 103a through the node identifier 117.116.189.145, and the light node 103a may know that the transaction data a is sent by the light node 101a through the node identifier 117.116.156.425, and thus, data transmission between other nodes is also performed, and thus, details are not repeated.

It should be understood that the data connection is not limited to the connection manner, and may be directly or indirectly connected through a wired communication manner, may be directly or indirectly connected through a wireless communication manner, and may also be connected through other connection manners, which is not limited herein.

The light node 101a, the light node 102a, the light nodes 103a, …, the light node 104a, the full node 101b, the full node 102b, the full nodes 103b, …, and the full node 104b in fig. 1 may include a mobile phone, a tablet computer, a notebook computer, a palm computer, a smart audio, a mobile internet device (MID, mobile internet device), a POS (Point Of Sales) machine, a wearable device (e.g., a smart watch, a smart bracelet, etc.), and the like.

It is understood that the data synchronization method provided by the embodiments of the present application can be executed by a computer device, which includes, but is not limited to, a light node (which may be a terminal or a server) or a full-scale node (which may be a terminal or a server). The server may be an independent physical server, a server cluster or a distributed system formed by a plurality of physical servers, or a cloud server providing basic cloud computing services such as a cloud service, a cloud database, cloud computing, a cloud function, cloud storage, a network service, cloud communication, middleware service, a domain name service, a security service, a CDN, a big data and artificial intelligence platform, and the like. The terminal may be, but is not limited to, a smart phone, a tablet computer, a laptop computer, a desktop computer, a smart speaker, a smart watch, and the like. The terminal and the server may be directly or indirectly connected through wired or wireless communication, and the application is not limited herein.

Further, please refer to fig. 2, and fig. 2 is a schematic flowchart of a data synchronization method according to an embodiment of the present application. The data synchronization method may be executed by the full-scale node or the light node described in fig. 1, or may be executed by both the full-scale node and the light node. As shown in fig. 2, the data synchronization process may include the following steps.

Step S101, acquiring a data synchronization request sent by a light node; the data synchronization request includes a node identification of the light node and a block identification of the synchronization block.

Specifically, transaction detail data in a block to be linked up is obtained, and a transaction execution function in an intelligent contract for executing the transaction detail data is called; acquiring historical transaction data aiming at the transaction detail data according to a transaction execution function, and determining the historical transaction data as read data; executing a transaction executing function according to the read data and the transaction detail data to obtain a transaction executing result of the transaction detail data; and performing uplink processing on the block to be uplink processed according to the transaction detail data and the transaction execution result.

The specific process of performing uplink processing on the to-be-uplink block may include: when the transaction detail data and the transaction execution result are both identified, generating result data according to the transaction execution result; generating a transaction state tree according to the transaction detail data, generating a result state tree according to the result data, and adding the transaction state tree and the result state tree to the block to be linked; and determining the block to be uplink added with the transaction state tree and the result state tree as a synchronous block, and adding the synchronous block to the block chain.

Optionally, the read data and the result data are respectively compared with the historical data set; the historical data set comprises historical reading data or historical result data corresponding to historical transaction detail data stored in the full database; if a historical data set which is the same as the read data exists and a historical data set which is the same as the result data exists, performing reading mark processing on the historical data set which is the same as the read data, determining the historical data set carrying a reading mark as a first data set, performing writing mark processing on the historical data set which is the same as the result data, and determining the historical data set carrying a writing mark as a second data set; determining the first data set and the second data set as target data sets, and storing the target data sets and the transaction detail data in a full database in an associated manner; and if the historical data set identical to the read data does not exist and the historical data set identical to the result data does not exist, determining the read data and the result data as a target data set, and storing the target data set and the transaction detail data in a full-scale database in an associated manner.

Referring to fig. 3, fig. 3 is a schematic view of a data consensus scenario provided in an embodiment of the present application. As shown in fig. 3, the full-measure node 30a obtains a to-be-uplink block 30b, wherein the to-be-uplink block 30b may be a to-be-identified block generated by other full-measure nodes in the blockchain network, or a to-be-exited block generated by a light node in the blockchain network, and the origin of the to-be-uplink block 30b is not limited herein. It is understood that the embodiments of the present application only describe the transaction root hash in the block header (i.e., the hash value H in fig. 3)_Y(1234) And the resulting root hash (i.e., hash value H in fig. 3)_G(1234) In actual application, the block header stores basic data such as a version number, a timestamp, a difficulty value and the like, and may also store other related data.

Referring to fig. 3 again, the wholesale node 30a obtains the transaction detail data in the to-be-linked block 30b, i.e. transaction 1, transaction 2, transaction 3, …, and transaction n in fig. 3, performs a sequence consensus on transaction 1, transaction 2, transaction 3, …, and transaction n, and performs a transaction execution result consensus on transaction 1, transaction 2, transaction 3, …, and transaction n when the sequence consensus passes, which may be described as follows. The full-scale node 30a first calls a transaction execution function in the smart contract 30c for executing transaction detail data according to the function name, as shown in fig. 3, the function for executing transaction 1 is transaction execution function 1, the function for executing transaction 2 is transaction execution function 2, the function for executing transaction 3 is transaction execution function 3, …, and the function for executing transaction n is transaction execution function n. It is understood that the functions (including the functions corresponding to the function name 1, the function name 2, the function name 3, …, and the function name n, respectively) may be called under the same intelligent contract or under different intelligent contracts, for example, the function corresponding to the function name 1 (i.e., the transaction execution function 1) and the function corresponding to the function name 2 (i.e., the transaction execution function 2) are called in the intelligent contract B, and the function corresponding to the function name 3 (i.e., the transaction execution function 3) and the function corresponding to the function name n (i.e., the transaction execution function n) are called in the intelligent contract V.

The full-volume node 30a acquires historical transaction data for the transaction detail data according to the transaction execution function, and determines the historical transaction data as read data; as shown in fig. 3, the historical transaction data 1 of the transaction 1 is acquired by the transaction execution function 1, the historical transaction data 2 of the transaction 2 is acquired by the transaction execution function 2, the historical transaction data 3, … of the transaction 3 is acquired by the transaction execution function 3, and the historical transaction data n of the transaction n is acquired by the transaction execution function n. For example, transaction 1 is that party a transfers 10 dollars to party b through his own account, transaction execution function 1 is a transfer execution function, historical transaction data 1 is the remaining 20 dollars on party a account, and transaction execution result 1 for transaction 1 may be 20-10 dollars, i.e., 10 dollars on party a account after transaction 1 is executed.

In the above, the relation between the transaction detail data, the historical transaction data, and the transaction execution result is described simply by taking the transaction 1 as an example, so that the transaction execution result 2 of the transaction 2 can be obtained according to the transaction 2, the historical transaction data 2, and the transaction execution function 2, the transaction execution result 3, … of the transaction 2 can be obtained according to the transaction 3, the historical transaction data 3, and the transaction execution function 3, and the transaction execution result n of the transaction n can be obtained according to the transaction n, the historical transaction data n, and the transaction execution function n.

Referring to fig. 4, fig. 4 is a schematic view of a data consensus scenario provided in an embodiment of the present application. Wherein, the full-scale node 40a in fig. 4 may be identical to the full-scale node 30a in fig. 3, and assuming that n in fig. 3 is equal to 4, the full-scale node 40a may obtain the data to be identified 40c in fig. 4. The data to be consensus 40c may include the associated transaction 1, transaction execution result 1, and function name 1, the associated transaction 2, transaction execution result 2, and function name 2, the associated transaction 3, transaction execution result 3, and function name 3, and the associated transaction 4, transaction execution result 4, and function name 4.

Referring to fig. 4 again, the quorum node 40a first performs hash calculation on transaction 1 (equivalent to Y1 in fig. 4), transaction 2 (equivalent to Y2 in fig. 4), transaction 3 (equivalent to Y3 in fig. 4), and transaction 4 (equivalent to Y4 in fig. 4), respectively, to obtain the hash value H of transaction 1_Y(1) Transaction 2 hash value H_Y(2) Transaction 3 hash value H_Y(3) And a hash value H for transaction 4_Y(4) (ii) a Then the hash value H is compared_Y(1) And a hash value H_Y(2) Carrying out Hash operation to obtain a Hash value H comprising the two Hash values_Y(12) For the hash value H_Y(3) And a hash value H_Y(4) Carrying out Hash operation to obtain a Hash value H comprising the two Hash values_Y(34) (ii) a Finally, the hash value H is paired_Y(12) And a hash value H_Y(34) Carrying out Hash operation to obtain a Hash value H_Y(12) And a hash value H_Y(34) Hash value of (H)_Y’(1234) The hash value H_Y’(1234) A root hash for the transaction to be verified for the data to be consensus 40 c.

Similarly, the full-scale node 40a first performs hash calculation on the transaction execution result 1 (equivalent to G1 in fig. 4), the transaction execution result 2 (equivalent to G2 in fig. 4), the transaction execution result 3 (equivalent to G3 in fig. 4), and the transaction execution result 4 (equivalent to G4 in fig. 4), respectively, to obtain the hash value H of the transaction execution result 1_G(1) Hash value H of transaction execution result 2_G(2) Hash value H of transaction execution result 3_G(3) And a hash value H of the transaction execution result 4_G(4) (ii) a Then the hash value H is compared_G(1) And a hash value H_G(2) Carrying out Hash operation to obtain a Hash value H comprising the two Hash values_G(12) For the hash value H_G(3) And a hash value H_G(4) Carrying out Hash operation to obtain a Hash value H comprising the two Hash values_G(34) (ii) a Finally, the hash value H is paired_G(12) And a hash value H_G(34) Carrying out Hash operation to obtain a Hash value H_G(12) And hahaValue of Hi H_G(34) Hash value of (H)_G’(1234) The hash value H_G’(1234) Is root hash of the to-be-verified result of the to-be-consensus data 40 c.

It is understood that the embodiment of the present application describes 4 transactions as an example, and does not represent the number of transactions in an actual application scenario.

Full quantum node 40a hashes value H_Y’(1234) And hash value H in fig. 3_Y(1234) Comparing, if the two are the same, determining that the transaction consensus of the data to be agreed 40c passes, otherwise, failing to pass; similarly, the full-scale node 40a will hash value H_G’(1234) And hash value H in fig. 3_G(1234) And comparing, wherein if the two are the same, the result consensus of the data to be consensus 40c can be determined to pass, otherwise, the result consensus fails. Referring back to fig. 3, when the transaction detail data and the transaction execution result both pass, the full-scale node 30a generates result data according to the transaction execution result.

It is understood that, in the embodiment of the present application, the description is made by taking the case where the result data includes the transaction execution result, as well as the following. In an actual application scenario, the result data includes, but is not limited to, a transaction execution result, and a range of the result data may be set according to the scenario.

Fig. 5 is a flowchart illustrating a data synchronization method according to an embodiment of the present application, where the method may be performed by any node in a blockchain network. As shown in fig. 5, the data synchronization method may include the following steps.

Step S1, each node RPC layer obtains a user request, which is also called a transaction.

Step S2, the nodes broadcast the transaction with each other, and one node packs several transactions into a block and broadcasts to other nodes. The selection of the out-of-block nodes may include a leader (leader) out of a block, a rotation out of a block, a competition out of a block, and the like, depending on the consensus algorithm.

In step S3, after all nodes receive the block, they start to execute the transaction in the block. At the logical computing layer, the transaction parameters are parsed and contracts are executed. During execution, it may be necessary to read data in the store (i.e., read data), such as node 1 in the example of fig. 5, to read historical transaction data from the store.

After the contract is executed in step S4, the nodes check the execution results (i.e., the transaction execution results) with each other. The checking method may be to organize the execution result or the stored change into a result merkle tree, put a result tree root (i.e., a result root hash) into the block header, and finally check that the hash of each node block is consistent.

Step S5, after the consensus is successful, each node stores the data related to the block, which mainly includes the block header, all transactions included in the block, the contract execution result, and the like.

The detailed process of steps S1-S5 can refer to step S101 in the embodiment corresponding to fig. 2, and will not be described herein again.

Step S102, synchronous transaction data in the synchronous block is obtained according to the block identification, and a target data set associated with the synchronous transaction data is obtained; the synchronized transaction data includes transaction detail data and contract information for executing smart contracts for the transaction detail data; the target data set includes read data or result data derived in executing the transaction detail data based on the contract information.

Specifically, a candidate data set associated with the synchronous transaction data is obtained from a full-scale database; the candidate data set comprises read data and result data obtained when executing the transaction detail data based on the contract information; comparing the data capacity of the read data with the data capacity of the result data; if the data capacity of the read data is smaller than that of the result data, determining the read data as a target data set; and if the data capacity of the read data is equal to or larger than that of the result data, determining the result data as a target data set.

Referring to fig. 6, fig. 6 is a schematic view of a data synchronization scenario provided in an embodiment of the present application. As shown in fig. 6, the full-scale node 60a may determine the synchronization block 607b requested by the light node in the full-scale book 60b according to the block identifier sent by the light node, where the block identifier may be the block height of the synchronization block 607b, the block hash of the synchronization block 607b, or other identifiers that may characterize the synchronization block 607 b.

The full-scale node 60a obtains the synchronous transaction data 60c in the synchronization block 607b, and the synchronous transaction data 60c may include the transaction 1 and the contract information 1 stored in association, the transaction 2 and the contract information 2 stored in association, the transaction 3 and the contract information 3, … stored in association, and the transaction n and the contract information n stored in association in fig. 6.

Referring to fig. 6 again, after the full-scale node 60a acquires the synchronous transaction data 60c, it needs to acquire a target data set 60f corresponding to the synchronous transaction data 60c, so that the light node can execute a transaction execution function according to the target data set 60f and the transaction detail data. The full volume node 60a first obtains the full volume database 60d and then obtains the historical data set 60g in the full volume database 60d, as shown in fig. 6, the historical data set 60g may include read data 1& result data 1, read data 2& result data 2, read data 3& result data 3, read data 4& result data 4, read data 5& result data 5, …, read data n & result data n, where the symbol "&" represents the associated storage.

As can be seen from the description in step S101, the full-volume node stores the target data set and the transaction detail data in association with each other in the full-volume database, so here, the full-volume node 60a may match the transaction detail data (including transaction 1, transaction 2, transaction 3, …, transaction n in fig. 6) in the synchronous transaction data 60c with the transaction detail data in the full-volume database 60d, and according to the matching result, may determine the candidate data set 60e of the synchronous transaction data 60 c. Assuming that the target data set of transaction 1 is read data 1& result data 1; the target data set of transaction 2 is read data 2& result data 2, the target data set of transaction 3 is read data 3& result data 3, …, and the target data set of transaction n is read data n & result data n.

The full-volume node 60a does not need to send the read data and the result data of the transaction detail data to the light node, the light node can verify whether the synchronous transaction data sent by the full-volume node 60a and the to-be-verified result data corresponding to the transaction detail data are legal or not according to the read data or the result data, so that the full-volume node 60a can compare the data capacity of the read data 1 and the result data 1 of the transaction 1, and if the data capacity of the result data 1 is smaller, the result data 1 is determined as a target data set of the transaction 1; similarly, the full-scale node 60a may compare the data capacity of the read data 2 and the result data 2 of the transaction 2, and if the data capacity of the read data 2 is smaller, determine the read data 2 as the target data set of the transaction 2; the full-volume node 60a may compare the data capacity of the read data 3 and the result data 3 of the transaction 3, and if the data capacity of the result data 3 is smaller, determine the result data 3 as a target data set of the transaction 3; by analogy, a target data set 60f is generated.

The full database 60d may be regarded as an electronic file cabinet, which is a place for storing electronic files (the electronic files in the present application may refer to a target data set and transaction detail data), and the full node 60a may perform operations such as adding, querying, updating, and deleting on the target data set and the transaction detail data in the files. A "database" is a collection of data that is stored together in a manner that can be shared by multiple users, has as little redundancy as possible, and is independent of the application.

And step S103, determining a target synchronous read transaction execution function aiming at the transaction detail data according to the contract information and the data synchronous request.

Specifically, acquiring a contract name and a transaction execution function name in contract information; the contract name is used for representing the name of an intelligent contract for executing the transaction detail data, and the transaction execution function name is used for representing the name of a transaction execution function called by the intelligent contract and used for executing the transaction detail data; acquiring a synchronous reading name according to the data synchronous request, and determining a synchronous reading transaction execution function name according to the transaction execution function name and the synchronous reading name; and determining a target synchronous read transaction execution function in the intelligent contract according to the synchronous read transaction execution function name.

For ease of understanding, step S103 and step S104 below will be described by taking transaction 1 and contract information 1 in fig. 6 as an example, and the determination of the target synchronous read transaction execution function of other transactions and the corresponding synchronous data set thereof may be referred to the following description, and are not described one by one.

Referring to fig. 7, fig. 7 is a schematic view of a data synchronization scenario provided in an embodiment of the present application. As shown in fig. 7, transaction 1 may include account 1111 transferring 10-dollars to account 2222, where the smart contract performing transaction 1 may be a transfer contract, assuming the contract name of the transfer contract is transfer; in executing transaction 1, the transaction execution function called by the transfer contract is the transfer execution function, and the function name of the transfer execution function (i.e., the transaction execution function name) is assumed to be the transfer. Assume that read data 1 for transaction 1 leaves 20 elements for account 1111 and result data 1 for transaction 1 leaves 10 elements for account 1111.

When the full-scale node 60a acquires the data synchronization request sent by the light node, the synchronous read name is acquired according to the request, and the full-scale node 60a may determine a target synchronous read transaction execution function, that is, the synchronous read transfer execution function illustrated in fig. 7, in the transfer contract according to the synchronous read name and the transfer execution function. It can be understood that, in the embodiment of the present application, the transfer execution function and the synchronous read transfer execution function are called in the same intelligent contract (i.e., the transfer contract illustrated in fig. 7), and in actual application, the transaction execution function and the synchronous read transaction execution function may not be called in the same intelligent contract, and the specific calling situation may be set according to an actual scenario.

And step S104, determining a synchronous data set from the target data set according to the transaction detail data, the node identification and the target synchronous read transaction execution function.

Specifically, according to the node identification and the target synchronous read transaction execution function, the synchronous authority of the light node for the synchronous transaction data is determined; the synchronous authority comprises a synchronous legal authority and a synchronous illegal authority; if the synchronous authority of the light node aiming at the synchronous transaction data is a synchronous illegal authority, returning data synchronization failure information to the light node; and if the synchronous authority of the light node for the synchronous transaction data is a synchronous legal authority, determining a synchronous data set from the target data set according to the transaction detail data, the node identification and the target synchronous read transaction execution function.

The specific process of determining the synchronous data set from the target data set may include: determining an existing data set which is stored by the light node and is associated with the transaction detail data according to the transaction detail data, the node identification and the target synchronous read transaction execution function; and filtering the existing data set from the target data set, and determining the filtered target data set as a synchronous data set.

Referring to fig. 7 again, it is assumed that the node identifier 60h of the light node is 117.114.151.174, and the full node 60a may call a synchronous read transfer execution function according to a target synchronous read transaction execution function (i.e., the synchronous read transfer execution function illustrated in fig. 7), and determine a synchronization authority of the light node for synchronous transaction data according to the synchronous read transfer execution function and the node identifier 60h, it should be understood that, in this embodiment of the present application, a method for determining the synchronization authority is not limited, the synchronization authority may be determined by the node identifier of the light node, the synchronization authority may be determined by the node type of the light node, or other methods may be described in this embodiment of the present application, taking the node identifier as an example.

Fig. 7 illustrates that the synchronization authority of the light node for the synchronous transaction data is a synchronization legal authority, i.e., 117.114.151.174 in fig. 7 that the authority of the synchronous transaction 1 is legal. At this time, the full-volume node 60a may determine, according to transaction 1, the node identification 60h, and the synchronous read transfer execution function, that the light node has stored an existing data set associated with transaction 1, such as account 1111 remaining 20 elements as illustrated in fig. 7; assuming that the target data set 1 is the read data 1 of transaction 1, in conjunction with step S103, it is known that the read data 1 is the remaining 20 metadata of the account 1111, the existing data set is filtered from the target data set, and it is known that the synchronous data set is an empty set.

Obviously, through the synchronous read transaction execution function, the full-scale node 60a may determine the existing data set of the light node for the transaction detail data, so as to delete the target data set (i.e. filter the existing data set), and obtain the synchronous data set.

Optionally, the total number of nodes may further determine an additional data set required by the light node according to the target synchronous read transaction execution function, where the target data set does not include the additional data set, and therefore the additional data set is merged with the target data set to obtain a synchronous data set returned to the light node.

Step S105, obtaining verification data corresponding to the synchronous transaction data from the synchronization block, and returning the synchronous transaction data, the verification data, and the synchronous data set to the light node, so that the light node verifies the validity of the to-be-verified result data corresponding to the synchronous transaction data and the transaction detail data according to the verification data and the synchronous data set.

Specifically, a transaction state tree and a result state tree are obtained from the synchronization block; the transaction state tree is a transaction Mercker tree generated based on the transaction detail data; the result state tree is a result merkel tree generated based on the result data; acquiring transaction verification data from the transaction state tree based on the transaction detail data, and acquiring result verification data from the result state tree based on the result data; the transaction verification data and the result verification data are determined to be verification data.

The synchronization block includes a state tree (e.g., the transaction state tree and the result state tree illustrated in fig. 4), so that the node of the full quantum may obtain verification data of the synchronized transaction data from the synchronization block, where the transaction verification data may correspond to the transaction hash value in the transaction state tree and the result verification data may correspond to the result hash value in the result state tree. Referring to fig. 4 again, the transaction state tree, the result state tree and the transaction 1 in fig. 4 are taken as an example for description, and for the transaction 1, the transaction verification data may include the hash value H in the transaction state tree_Y(2) And a hash value H_Y(34) The result verification data may include a hash value H in the result state tree_G(2) And hahaValue of Hi H_G(34)。

Referring back to fig. 4, it will be appreciated that the verification data returned to the light node may comprise corresponding verification data for each transaction detail data, for example for transaction 1, which verification data may comprise a hash value H_Y(2) And a hash value H_Y(34) And, a hash value H_G(2) And a hash value H_G(34) For transaction 2, its verification data may include a hash value H_Y(1) And a hash value H_Y(34) And, a hash value H_G(1) And a hash value H_G(34) (ii) a Verification data for all transaction detail data may also be included, for example for transaction 1 and transaction 2, which may include a hash value H_Y(34) And a hash value H_G(34)。

Further, the full-amount node returns the synchronous transaction data, the verification data and the target data set to the light node, so that the light node verifies the validity of the synchronous transaction data and the to-be-verified result data corresponding to the transaction detail data according to the verification data and the target data set. For a specific process of the light node self-checking the validity of the to-be-verified result data corresponding to the transaction detail data of the synchronous transaction data, please refer to the embodiment corresponding to fig. 8 below.

In the embodiment of the application, when a data synchronization request for a certain block (namely, a synchronization block) sent by a light node is acquired, the application does not return the whole synchronization block to the light node, and the synchronization transaction data in the synchronization block is acquired first, and then a target data set for the synchronization transaction data is acquired, wherein the synchronization transaction data comprises transaction detail data and contract information of an intelligent contract for executing the transaction detail data; according to contract information and a data synchronization request, a target synchronous read transaction execution function aiming at transaction detail data can be determined; based on the node identification and the target synchronous read transaction execution function, the synchronous data set can be determined from the target data set, the data synchronized to the light node is perfected, the data transmission quantity can be reduced, and therefore the space cost of the light node can be reduced; further, verification data is obtained, and the synchronous transaction data, the verification data and the synchronous data set are sent to the light node, and since the synchronous data set comprises read data or result data obtained when transaction detail data are executed based on contract information, the light node can accurately obtain to-be-verified result data corresponding to the transaction detail data through the synchronous data set, and therefore the light node can accurately verify the validity of the synchronous transaction data and the to-be-verified result data through the verification data and the synchronous data set. Furthermore, the light nodes can execute intelligent contracts with only partial data (not the entire sync block), perform business logic operations on the data, and handle complex business. In the process, each node (including light nodes and full nodes) with unequal data can execute the contract, so that the capability of intelligent contracts is fully exerted while the data privacy is protected, and the accuracy of the data can be determined.

Further, please refer to fig. 8, and fig. 8 is a schematic flowchart of a data synchronization method according to an embodiment of the present application. The data synchronization method may be executed by the full-scale node or the light node described in fig. 1, or may be executed by both the full-scale node and the light node. As shown in fig. 8, the data synchronization process includes the following steps:

step S201, sending a data synchronization request carrying a block identifier to a full-scale node, so that the full-scale node acquires synchronous transaction data, verification data and a synchronous data set according to the data synchronization request and the block identifier; the synchronous transaction data is data in a synchronous block determined by the full-scale node according to the block identification, and comprises transaction detail data and contract information of an intelligent contract used for executing the transaction detail data; the synchronous data set is a set determined by the full-volume nodes from the target data set according to the transaction detail data, the node identification of the light node and the target synchronous read transaction execution function; the target synchronous read transaction execution function is a function for transaction detail data determined by the full-scale node according to the contract information and the data synchronous request; the target data set is a set of read data or result data associated with the synchronous transaction data and including the full-scale nodes derived in executing the transaction detail data based on the contract information.

The specific process of step S201 may refer to the description in the embodiment corresponding to fig. 2, and is not described herein again.

Step S202, synchronous transaction data, verification data and synchronous data sets sent by the full-volume nodes are obtained.

Specifically, please refer to fig. 9, and fig. 9 is a schematic view of a data self-checking scenario provided in the embodiment of the present application. As shown in FIG. 9, the light node 80b obtains the synchronized transaction data sent by the quorum node 80a (i.e., transaction 4 in FIG. 9)&Contract information 4), verification data (i.e., H (3), H (12), and H (5678) in fig. 9), and a set of synchronization data (i.e., transaction execution result 4 in fig. 9). Wherein the verification data H (3) may comprise a hash value H_Y(3) And a hash value H_G(3) The verification data H (12) may include a hash value H_Y(12) And a hash value H_G(12) The verification data H (5678) may include a hash value H_Y(5678) And a hash value H_G(5678) The above hash value H_Y(3) Hash value H_Y(12) And a hash value H_Y(5678) Respectively, the transaction hash value in the transaction Mercker certification tree, the above-mentioned hash value H_G(3) Hash value H_G(12) And a hash value H_G(5678) Respectively, the result hash values in the result merkel certification tree. Similarly, any hash value H (E) in the Merck's syndrome tree 80c of FIG. 9 (understood as the combination of the transaction Merck's syndrome tree and the resulting Merck's syndrome tree) may include the transaction hash value H_Y(E) And a resulting hash value H_G(E) And E equals 1, 2, 3, …, 8.

Step S203, verifying the validity of the synchronous transaction data and the data to be verified corresponding to the transaction detail data according to the verification data and the synchronous data set.

Specifically, acquiring a contract name and a transaction execution function name in contract information; the contract name is used for representing the name of an intelligent contract for executing the transaction detail data of the full-scale node, and the transaction execution function name is used for representing the name of a transaction execution function called by the intelligent contract and used for executing the transaction detail data; acquiring a synchronous writing name according to the synchronous data set and the synchronous transaction data, and determining a synchronous writing transaction execution function name according to the transaction execution function name and the synchronous writing name; determining a target synchronous write transaction execution function in the intelligent contract according to the synchronous write transaction execution function name; and verifying the validity of the synchronous transaction data and the data to be verified corresponding to the transaction detail data according to the target synchronous writing transaction execution function, the synchronous data set and the verification data.

The specific process of verifying the validity of the to-be-verified result data corresponding to the synchronous transaction data and the transaction detail data may include: determining an existing data set aiming at the transaction detail data in the light node account book according to the node identification, the transaction detail data and the target synchronous writing transaction execution function; and merging the existing data set and the synchronous data set to obtain a target data set.

And if the target data set is result data, determining the result data as to-be-verified result data corresponding to the transaction detail data, obtaining a first to-be-verified root hash according to the transaction detail data, the to-be-verified result data and the verification data, and verifying the validity of the synchronous transaction data and the to-be-verified result data according to the first to-be-verified root hash. If the target data set is read data, determining a transaction execution function according to the name of the transaction execution function; inputting the read data and the transaction detail data into a transaction execution function to obtain a to-be-verified transaction execution result of the transaction detail data, and generating to-be-verified result data according to the to-be-verified transaction execution result; and obtaining a second root hash to be verified according to the transaction detail data, the result data to be verified and the verification data, and verifying the validity of the synchronous transaction data and the result data to be verified according to the second root hash to be verified.

Wherein the verification data comprises transaction verification data and result verification data; the first root hash to be verified comprises a transaction root hash to be verified and a root hash of a result to be verified; the specific process of obtaining the first root hash to be verified according to the transaction detail data, the result data to be verified and the verification data, and verifying the validity of the synchronous transaction data and the result data to be verified according to the first root hash to be verified may include: according to the transaction detail data and the transaction verification data, obtaining a transaction root hash to be verified, and according to the result data to be verified and the result verification data, obtaining a result root hash to be verified; acquiring a block head aiming at the synchronous block, and acquiring a verified transaction root hash and a verified result root hash from the block head; comparing the transaction root hash to be verified with the verified transaction root hash, and comparing the root hash of the result to be verified with the root hash of the result to be verified; if the hash of the transaction root to be verified is different from the hash of the verified transaction root, determining that the synchronous transaction data is illegal data, and if the hash of the transaction root to be verified is the same as the hash of the verified transaction root, determining that the synchronous transaction data is legal data; if the root hash of the result to be verified is different from the root hash of the result already verified, determining that the data of the result to be verified is illegal data, and if the root hash of the result to be verified is the same as the root hash of the result already verified, determining that the data of the result to be verified is legal data; and when the synchronous transaction data is legal data and the data of the result to be verified is legal data, performing associated storage on the data of the result to be verified and the synchronous transaction data.

The specific process of verifying the validity of the synchronous transaction data and the to-be-verified result data corresponding to the transaction detail data according to the second to-be-verified root hash may include: acquiring a block head aiming at the synchronous block, and acquiring a verified transaction root hash and a verified result root hash from the block head; comparing the transaction root hash to be verified with the verified transaction root hash, if the transaction root hash to be verified is different from the verified transaction root hash, determining that the synchronous transaction data is illegal data, and at the moment, no longer comparing the root hash to be verified with the root hash to be verified; if the hash of the transaction root to be verified is the same as the hash of the verified transaction root, determining that the synchronous transaction data is legal data; further, comparing the root hash of the result to be verified with the root hash of the verified result, if the root hash of the result to be verified is different from the root hash of the verified result, determining that the data of the result to be verified is illegal data, if the root hash of the result to be verified is the same as the root hash of the verified result, determining that the data of the result to be verified is legal data, and storing the data of the result to be verified and the synchronous transaction data in a correlation manner.

For a specific process of determining the target synchronous write transaction execution function in the intelligent contract, refer to the detailed description of step S103 in the embodiment corresponding to fig. 2 for determining the target synchronous read transaction execution function, and the two function determination processes are the same, so details are not described here.

After the light node determines the target synchronous write-based transaction execution function, the target synchronous write-transaction execution function is executed according to the node identifier and the transaction detail data, so as to obtain an existing data set of the light node for the transaction detail data, as described above by taking the transaction 1 in step S104 in the embodiment corresponding to fig. 2 as an example, the existing data set is 20 remaining elements in the account 1111. The target data set returned to the light node by the full node is an empty set, the target data set and the existing data set are merged, and the obtained target data set is the same as the existing data set, namely, the account 1111 has 20 elements.

For the target data set to be result data (for example, the transaction execution result 4 in fig. 9), the light node does not need to execute the transaction detail data in the synchronous transaction data, and the result data sent by the full-amount node is to-be-verified result data of the transaction detail data. The light node may verify the validity of the synchronized transaction data based on the result data, the verification data, and the transaction detail data. Referring again to fig. 9, the light node 80b may be configured to perform the hash H according to transaction 4_Y(3) Hash value H_Y(12) Hash value H_Y(5678) A transaction merkel verification tree in merkel verification tree 80c is generated. The light node 80b first performs a hash operation on the transaction 4 to obtain a hash value H_Y(4) According to the hash value H_Y(4) And a hash value H_Y(3) The hash value H can be obtained_Y(34) Then according to the hash value H_Y(34) And a hash value H_Y(12) The hash value H can be obtained_Y(1234) And finally according to the hash value H_Y(1234) And verifying hash value H in data_Y(5678) The hash value H can be obtained_Y(12345678), the hash value H_Y(12345678) is the transaction root hash to be verified.

Similarly, the light node 80b may execute the result 4 and the hash value H according to the transaction_G(3) Hash value H_G(12) Hash value H_G(5678) The resulting merkel proof tree in merkel proof tree 80c is generated. The light node 80b first performs a hash operation on the result 4 (which is equal to the transaction execution result 4) to obtain a hash value H_G(4) According to the hash value H_G(4) And a hash value H_G(3) The hash value H can be obtained_G(34) Then according to the hash value H_G(34) And a hash value H_G(12) The hash value H can be obtained_G(1234) And finally according to the hash value H_G(1234) And verifying hash value H in data_G(5678) The hash value H can be obtained_G(12345678), the hash value H_G(12345678) is the root hash of the result to be verified.

Referring back to fig. 9, the light node 80b obtains the chunk header of the sync chunk from the P2P network, then obtains the verified transaction root hash and the verified result root hash in the chunk header, and hashes the transaction root to be verified (i.e., the hash value H)_Y(12345678)) and the verified transaction root hash, if the to-be-verified transaction root hash is different from the verified transaction root hash, determining that the synchronous transaction data (including transaction 4) is illegal data, and if the to-be-verified transaction root hash is the same as the verified transaction root hash, determining that the synchronous transaction data is legal data.

Root hashing the result to be verified (i.e., hash value H)_G(12345678)) and the root hash of the verified result, if the root hash of the result to be verified is not the same as the root hash of the verified result, determining that the result data (such as the result 4 in fig. 9) is illegal data, and if the root hash of the result to be verified is the same as the root hash of the verified result, determining that the result data is legal data. When the synchronous transaction data is legal data and the result data is legal data, the light node 80b stores the result data in association with the synchronous transaction data.

For the target data set which is read data, the light node needs to execute a transaction execution function corresponding to the contract information according to the read data and the transaction detail data to generate a to-be-verified transaction execution result of the transaction detail data, and then generates to-be-verified result data corresponding to the transaction detail data according to the to-be-verified transaction execution result. Since the transaction detail data is already executed by the full-volume node, the read data can cover all data in the contract execution process, so that the contract can still be executed under the condition that the light node only has partial data. After the transaction execution result to be verified is obtained, the self-checking process of the light node is basically consistent with the self-checking process according to the result data, and therefore details are not repeated here.

As can be seen from the above, the light nodes can synchronize contract data of any logic and can self-check the correctness of the data. It can be understood that, in the embodiment of the present application, the light node self-checking to-be-verified result data and the synchronous transaction data are taken as an example for description, and in practical application, the light node may set the self-checking to-be-verified result data or the synchronous transaction data or both according to a scene, where a self-checking range of the light node is not limited herein.

Further, for ease of understanding, please refer to fig. 10, where fig. 10 is a schematic flowchart of a data synchronization method provided in an embodiment of the present application. The data synchronization method may be executed by the light node or the full-scale node described in fig. 1, or may be executed by both the light node and the full-scale node. As shown in fig. 10, the data synchronization process includes the following steps:

step 1, synchronize block B.

Specifically, the block header of the block B is broadcast over the entire network, and after the light node receives the block header, the light node sends a data synchronization request to the full-scale node to synchronize data in the block B.

The execution of the intelligent contract can be divided into two parts of code and data, the code represents a logic service, and the whole service participants can see, so that the light nodes of the same service have the code. The core problem to be solved is the data problem, mainly including the following two problems: 1. how the full-scale nodes distinguish and distribute correct data to the light nodes; 2. block chains tolerate doing bad, then how the light nodes self-check to determine that the data returned by the full number of nodes has not been tampered with. Please see steps 2-8 below.

Step 2, reading the transaction in the block B.

Specifically, the data is divided into two parts, transaction detail data and contextual transaction data. The transaction detail data is stored in the block, is final state data and cannot be modified, and the full amount of nodes can be directly returned to the light nodes. The context transaction data (equivalent to the target data set in the above) mainly refers to some transient data, such as account balance before transfer or account balance after transfer, and the balance changes every moment along with the increase of blocks and the execution of transactions; therefore, when the light node synchronizes to the block B, the full amount of nodes should be able to read or calculate the account balance when the blockchain network is processed to the block B, rather than the latest account balance.

The embodiment of the application provides a general data synchronization method, which needs to process a contract but does not change the property that the contract itself can realize any logic. The full-scale node stores the read data or/and the result data in the full-scale database, please refer to fig. 11 together, and fig. 11 is a schematic view of a scenario of target data storage according to an embodiment of the present application. As shown in fig. 11, the data set to be stored 90e in the quorum node 90a may include read data 1, read data 2, read data 3, …, read data n, and result data 1, result data 2, result data 3, …, result data n. Assuming that the read data 1 is historical transaction data of the transaction 1, and the result data 1 is a transaction execution result of the transaction 1; the read data 2 is historical transaction data of the transaction 2, and the result data 2 is a transaction execution result of the transaction 2; the read data 3 is historical transaction data of the transaction 3, and the result data 3 is a transaction execution result of the transaction 3; …, the read data n is the historical transaction data of transaction n, and the result data n is the transaction execution result of transaction n.

Feasible scheme 1: the read data 1& result data 1& transaction 1, the read data 2& result data 2& transaction 2, the read data 3& result data 3& transaction 3, …, and the read data n & result data n & transaction n are respectively stored in association in the full-scale database 90 b.

Feasible scheme 2: comparing the data capacity of the read data 1 with that of the result data 1, and if the data capacity of the read data 1 is smaller than that of the result data 1, storing the read data 1& transaction 1 in the full database 90b in a related manner; if the data capacity of the read data 1 is equal to or larger than the data capacity of the result data 1, the result data 1& transaction 1 association is stored in the full-volume database 90 b. The generation of the target data sets of the other transactions is also the same, and the description is not repeated herein.

Feasible scheme 3: referring to fig. 11 again, the full-scale node 90a compares the data set 90e to be stored with the historical data set 90c in the full-scale database 90b, and stores the data set 90e to be stored according to the comparison result. The historical data set 90c includes a historical data set 1, a historical data set 2, a historical data set 3, …, and a historical data set N.

As shown in fig. 11, if the read data 1 is equal to the historical data set 1 and the result data 1 is equal to the historical data set 2 in the comparison result, the historical data set 1 is read and marked to obtain (historical data set 1)^{1 read}Wherein the read flag "1 read" may characterize the historical data set 1 as read data for transaction 1; the historical data set 2 is subjected to writing and marking processing to obtain (the historical data set 2)^{1 write}Where the write flag "1 write" may characterize the historical data set 2 as the outcome data for transaction 1.

Since the other data in the data set to be stored 90e is not the same as the historical data set, it needs to be stored in the full database 90b, as shown in fig. 11, the new historical data set 90d includes the historical data set 1 carrying the read tag for transaction 1, the historical data set 2 carrying the write tag for transaction 1, the historical data sets 3 and …, the historical data set N, the read data 2& result data 2, the read data 3& result data 3 and …, and the read data N & result data N.

Feasible scheme 4: randomly determining a target data set, and if the read data is determined to be the target data set, storing the read data and the transaction detail data in a full database in an associated manner; and if the result data is determined to be the target data set, the result data and the transaction detail data are stored in the full-scale database in an associated mode.

It is understood that, in practical application, the above 3 schemes can be mixed to generate a new feasible scheme, which is not limited herein.

And 3, analyzing the contract and the method called in the transaction.

And 4, executing a synchronous read transaction execution function corresponding to the contract.

Specifically, for the transaction execution function in the contract, two functions need to be defined, which are a synchronous read transaction execution function and a synchronous write transaction execution function respectively. Wherein, the synchronous read transaction execution function is executed by a synchronized node (such as a full node), determines the synchronous authority of a synchronizing party (such as a light node) to the data in the synchronous block B, and generates the data to be returned.

And 5, returning a result, including transaction and data.

In particular, the results may include synchronized transaction data, verification data, and a set of synchronized data.

a) For partial transaction, the transaction itself contains data, such as deposit certificate and invoice, the original transaction parameters already contain all information of the invoice, a target data set is not needed, the synchronous read transaction execution function only determines the synchronous authority of the light node, and the returned synchronous transaction data is an empty set.

b) For the situation that the capacity of the read data or the result data is large, the total number of nodes can determine the existing data set of the light node according to the synchronous read transaction execution function, then the synchronous data set required by the light node is returned according to the target data set and the existing data set, and then the synchronous node continues to operate according to the synchronous transaction data to obtain the real result data.

c) The complete target data set may also be returned.

According to the method, the user can customize according to the complexity of the business of the user by reading the data, the result data and synchronously reading the transaction execution function, and storage is saved. The synchronous read transaction execution function and the synchronous write transaction execution function are written by a user, so that the maximum flexibility is realized.

And 6, receiving the transaction and the data, and executing a synchronous write transaction execution function corresponding to the contract.

Specifically, the step corresponds to step 5, the light node determines an existing data set according to a synchronous write transaction execution function, and then merges the existing data set with a synchronous data set returned by the full-volume node to obtain a target data set.

And 7, verifying whether the result is consistent with the certificate or not.

And 8, storing the transaction and execution result.

Step 7 and step 8 may refer to the embodiments respectively corresponding to fig. 2 and fig. 8, and are not described herein again.

Further, please refer to fig. 12, where fig. 12 is a schematic structural diagram of a data synchronization apparatus according to an embodiment of the present application. The data synchronization means may be a computer program (including program code) running on a computer device, for example, the data synchronization means is an application software; the apparatus may be used to perform the corresponding steps in the methods provided by the embodiments of the present application. As shown in fig. 12, the data synchronization apparatus 1 may include: a first obtaining module 11, a second obtaining module 12, a first determining module 13, a second determining module 14, and a second obtaining module 15.

A first obtaining module 11, configured to obtain a data synchronization request sent by a light node; the data synchronization request comprises a node identification of the light node and a block identification of the synchronization block;

the second obtaining module 12 is configured to obtain synchronous transaction data in the synchronous block according to the block identifier, and obtain a target data set associated with the synchronous transaction data; the synchronized transaction data includes transaction detail data and contract information for executing smart contracts for the transaction detail data; the target data set comprises read data or result data obtained when executing the transaction detail data based on the contract information;

a first determining module 13, configured to determine a target synchronous read transaction executing function for the transaction detail data according to the contract information and the data synchronization request;

a second determining module 14, configured to determine a synchronous data set from the target data set according to the transaction detail data, the node identifier, and the target synchronous read transaction executing function;

the second obtaining module 15 is configured to obtain verification data corresponding to the synchronous transaction data from the synchronous block, and return the synchronous transaction data, the verification data, and the synchronous data set to the light node, so that the light node verifies the validity of the to-be-verified result data corresponding to the synchronous transaction data and the transaction detail data according to the verification data and the synchronous data set.

For specific functional implementation manners of the first obtaining module 11, the second obtaining module 12, the first determining module 13, the second determining module 14, and the second obtaining module 15, reference may be made to steps S101 to S105 in the corresponding embodiment of fig. 2, which is not described herein again.

Referring again to fig. 12, the second obtaining module 12 may include: a first acquiring unit 121, a capacity comparing unit 122, and a first determining unit 123.

A first obtaining unit 121, configured to obtain a candidate data set associated with the synchronous transaction data from the full-size database; the candidate data set comprises read data and result data obtained when executing the transaction detail data based on the contract information;

a capacity comparison unit 122 for comparing the data capacity of the read data with the data capacity of the result data;

a first determining unit 123, configured to determine the read data as a target data set if the data capacity of the read data is smaller than the data capacity of the result data;

the first determining unit 123 is further configured to determine the result data as the target data set if the data capacity of the read data is equal to or greater than the data capacity of the result data.

For specific functional implementation manners of the first obtaining unit 121, the capacity comparing unit 122, and the first determining unit 123, reference may be made to step S102 in the corresponding embodiment of fig. 2, which is not described herein again.

Referring again to fig. 12, the first determining module 13 may include: a second acquisition unit 131, a third acquisition unit 132, and a second determination unit 133.

A second obtaining unit 131, configured to obtain a contract name and a transaction execution function name in the contract information; the contract name is used for representing the name of an intelligent contract for executing the transaction detail data, and the transaction execution function name is used for representing the name of a transaction execution function called by the intelligent contract and used for executing the transaction detail data;

a third obtaining unit 132, configured to obtain a synchronous read name according to the data synchronization request, and determine a synchronous read transaction execution function name according to the transaction execution function name and the synchronous read name;

the second determining unit 133 is configured to determine a target synchronous read transaction executing function in the smart contract according to the synchronous read transaction executing function name.

For specific functional implementation manners of the second obtaining unit 131, the third obtaining unit 132, and the second determining unit 133, reference may be made to step S103 in the corresponding embodiment of fig. 2, which is not described herein again.

Referring again to fig. 12, the second determining module 14 may include: a third determination unit 141, a return failure unit 142, and a fourth determination unit 143.

A third determining unit 141, configured to determine, according to the node identifier and the target synchronous read transaction execution function, a synchronization authority of the light node for the synchronous transaction data; the synchronous authority comprises a synchronous legal authority and a synchronous illegal authority;

a return failure unit 142, configured to return data synchronization failure information to the light node if the synchronization permission of the light node for the synchronous transaction data is a synchronous illegal permission;

a fourth determining unit 143, configured to determine, if the synchronization permission of the light node for the synchronous transaction data is a synchronization legal permission, a synchronous data set from the target data set according to the transaction detail data, the node identifier, and the target synchronous read transaction execution function.

The specific functional implementation manners of the third determining unit 141, the return failure unit 142, and the fourth determining unit 143 may refer to step S104 in the corresponding embodiment of fig. 2, which is not described herein again.

Referring again to fig. 12, the fourth determining unit 143 may include: a first determination subunit 1431 and a second determination subunit 1432.

A first determining subunit 1431, configured to determine, according to the transaction detail data, the node identifier, and the target synchronous read transaction execution function, an existing data set associated with the transaction detail data and stored in the light node;

a second determining subunit 1432, configured to filter an existing data set from the target data set, and determine the filtered target data set as a synchronous data set.

The specific functional implementation manners of the first determining subunit 1431 and the second determining subunit 1432 may refer to step S104 in the embodiment corresponding to fig. 2, which is not described herein again.

Referring to fig. 12 again, the third obtaining module 15 may include: a fourth acquisition unit 151, a fifth acquisition unit 152, and a fifth determination unit 153.

A fourth obtaining unit 151, configured to obtain the transaction status tree and the result status tree from the synchronization block; the transaction state tree is a transaction Mercker tree generated based on the transaction detail data; the result state tree is a result merkel tree generated based on the result data;

a fifth obtaining unit 152, configured to obtain transaction verification data from the transaction status tree based on the transaction detail data, and obtain result verification data from the result status tree based on the result data;

a fifth determining unit 153 for determining the transaction verification data and the result verification data as the verification data.

For specific functional implementation manners of the fourth obtaining unit 151, the fifth obtaining unit 152, and the fifth determining unit 153, reference may be made to step S105 in the embodiment corresponding to fig. 2, which is not described herein again.

Referring again to fig. 12, the data synchronization apparatus 1 may further include: a fourth acquisition module 16, a fifth acquisition module 17, an execute function module 18, and a block uplink module 19.

A fourth obtaining module 16, configured to obtain transaction detail data in the block to be linked, and invoke a transaction execution function in an intelligent contract for executing the transaction detail data;

a fifth obtaining module 17, configured to obtain historical transaction data for the transaction detail data according to the transaction execution function, and determine the historical transaction data as read data;

the execution function module 18 is used for executing the transaction execution function according to the read data and the transaction detail data to obtain a transaction execution result of the transaction detail data;

and a block uplink module 19, configured to perform uplink processing on the to-be-uplink block according to the transaction detail data and the transaction execution result.

The specific functional implementation manners of the fourth obtaining module 16, the fifth obtaining module 17, the execution function module 18, and the block uplink module 19 may refer to step S101 in the corresponding embodiment of fig. 2, and are not described herein again.

Referring to fig. 12 again, the block uplink module 19 may include: a first generating unit 191, a second generating unit 192, a sixth determining unit 193, and a third generating unit 194.

A first generating unit 191 configured to generate result data according to the transaction execution result when the transaction detail data and the transaction execution result both agree;

a second generating unit 192, configured to generate a transaction state tree according to the transaction detail data, generate a result state tree according to the result data, and add the transaction state tree and the result state tree to the to-be-uplink block;

a sixth determining unit 193, configured to determine the to-be-uplink block to which the transaction status tree and the result status tree are added as a synchronization block, and add the synchronization block to the block chain;

the third generating unit 194 is configured to generate a target data set according to the read data and the result data, and store the target data set in the full database.

For specific functional implementation manners of the first generating unit 191, the second generating unit 192, the sixth determining unit 193, and the third generating unit 194, reference may be made to step S101 in the corresponding embodiment of fig. 2, which is not described herein again.

Further, please refer to fig. 13, where fig. 13 is a schematic structural diagram of a data synchronization apparatus according to an embodiment of the present application. The data synchronization means may be a computer program (including program code) running on a computer device, for example, the data synchronization means is an application software; the apparatus may be used to perform the corresponding steps in the methods provided by the embodiments of the present application. As shown in fig. 13, the data synchronization apparatus 2 may include: a request sending module 21, a data acquiring module 22 and a data verifying module 23.

A sending request module 21, configured to send a data synchronization request carrying a block identifier to a full-scale node, so that the full-scale node obtains synchronous transaction data, verification data, and a synchronous data set according to the data synchronization request and the block identifier; the synchronous transaction data is data in a synchronous block determined by the full-scale node according to the block identification, and comprises transaction detail data and contract information of an intelligent contract used for executing the transaction detail data; the synchronous data set is a set determined by the full-volume nodes from the target data set according to the transaction detail data, the node identification of the light node and the target synchronous read transaction execution function; the target synchronous read transaction execution function is a function for transaction detail data determined by the full-scale node according to the contract information and the data synchronous request; the target data set is a set which is associated with the synchronous transaction data and comprises read data or result data obtained by the full-scale nodes when executing the transaction detail data based on the contract information;

the data acquisition module 22 is configured to acquire synchronous transaction data, verification data, and a synchronous data set sent by a full amount of nodes;

and the verification data module 23 is configured to verify the validity of the to-be-verified result data corresponding to the synchronous transaction data and the transaction detail data according to the verification data and the synchronous data set.

For specific functional implementation manners of the request sending module 21, the data obtaining module 22, and the data verifying module 23, reference may be made to steps S201 to S203 in the embodiment corresponding to fig. 8, which is not described herein again.

Referring again to fig. 13, the verification data module 23 may include: an acquisition information unit 231, a first determination unit 232, and a second determination unit 233.

An acquisition information unit 231 for acquiring a contract name and a transaction execution function name in the contract information; the contract name is used for representing the name of an intelligent contract for executing the transaction detail data of the full-scale node, and the transaction execution function name is used for representing the name of a transaction execution function called by the intelligent contract and used for executing the transaction detail data;

a first determining unit 232, configured to obtain a synchronous write name according to the synchronous data set and the synchronous transaction data, and determine a synchronous write transaction execution function name according to the transaction execution function name and the synchronous write name;

a second determining unit 233, configured to determine, according to the synchronous write transaction execution function name, a target synchronous write transaction execution function in the intelligent contract;

the second determining unit 233 is further configured to verify the validity of the to-be-verified result data corresponding to the synchronous transaction data and the transaction detail data according to the target synchronous write transaction execution function, the synchronous data set, and the verification data.

For specific functional implementation manners of the information obtaining unit 231, the first determining unit 232, and the second determining unit 233, reference may be made to step S203 in the embodiment corresponding to fig. 8, which is not described herein again.

Referring again to fig. 13, the second determining unit 233 may include: a determine set subunit 2331, a target set subunit 2332, and a verify data subunit 2333.

A determining set subunit 2331, configured to determine an existing data set for the transaction detail data in the light node ledger according to the node identifier, the transaction detail data, and the target synchronous write transaction execution function;

a target set subunit 2332, configured to merge an existing data set and a synchronous data set to obtain a target data set;

the verification data subunit 2333 is configured to verify the validity of the to-be-verified result data corresponding to the synchronous transaction data and the transaction detail data according to the target data set and the verification data.

The specific functional implementation manners of the determining set sub-unit 2331, the target set sub-unit 2332, and the verifying data sub-unit 2333 may refer to step S203 in the embodiment corresponding to fig. 8, which is not described herein again.

Referring again to fig. 13, the verification data subunit 2333 may include: a first verifying sub-unit 23331, a first determining sub-unit 23332, a second determining sub-unit 23333, and a second verifying sub-unit 23334.

A first verification subunit 23331, configured to, if the target data set is result data, determine the result data as to-be-verified result data corresponding to the transaction detail data, obtain a first to-be-verified root hash according to the transaction detail data, the to-be-verified result data, and the verification data, and verify the legitimacy of the synchronous transaction data and the to-be-verified result data according to the first to-be-verified root hash;

a first determining subunit 23332, configured to determine, if the target data set is read data, a transaction executing function according to the transaction executing function name;

the second determining subunit 23333 is configured to input the read data and the transaction detail data into the transaction execution function, obtain a to-be-verified transaction execution result of the transaction detail data, and generate to-be-verified result data according to the to-be-verified transaction execution result;

the second verifying sub-unit 23334 is configured to obtain a second root hash to be verified according to the transaction detail data, the result data to be verified, and the verification data, and verify the validity of the synchronous transaction data and the result data to be verified according to the second root hash to be verified.

The specific functional implementation manners of the first verifying sub-unit 23331, the first determining sub-unit 23332, the second determining sub-unit 23333 and the second verifying sub-unit 23334 may refer to step S203 in the embodiment corresponding to fig. 8, which is not described herein again.

Referring again to fig. 13, the verification data includes transaction verification data and result verification data; the first root hash to be verified comprises a transaction root hash to be verified and a root hash of a result to be verified;

a second verification subunit 23334, configured to obtain a root hash of the transaction to be verified according to the transaction detail data and the transaction verification data, and obtain a root hash of the result to be verified according to the result data to be verified and the result verification data;

a second verification subunit 23334, which is further configured to obtain a chunk header for the sync chunk, and obtain a verified transaction root hash and a verified result root hash from the chunk header;

the second verification sub-unit 23334 is further configured to compare the transaction root hash to be verified with the verified transaction root hash, and compare the root hash of the result to be verified with the root hash of the result to be verified;

the second verification subunit 23334 is further specifically configured to determine that the synchronous transaction data is illegal data if the transaction root hash to be verified is different from the verified transaction root hash, and determine that the synchronous transaction data is legal data if the transaction root hash to be verified is the same as the verified transaction root hash;

the second verification sub-unit 23334 is further specifically configured to determine that the result data to be verified is illegal data if the root hash of the result to be verified is different from the root hash of the result already verified, and determine that the result data to be verified is legal data if the root hash of the result to be verified is the same as the root hash of the result already verified;

the second verifying sub-unit 23334 is further specifically configured to perform associated storage on the data to be verified and the synchronous transaction data when the synchronous transaction data is legal data and the data to be verified is legal data.

The specific functional implementation manner of the second verifier sub-unit 23334 may refer to step S203 in the embodiment corresponding to fig. 8, which is not described herein again.

Further, please refer to fig. 14, fig. 14 is a schematic structural diagram of a computer device according to an embodiment of the present application. As shown in fig. 14, the computer device 1000 may be a full-scale node in the corresponding embodiment of fig. 2, and the computer device 1000 may include: at least one processor 1001, such as a CPU, at least one network interface 1004, a user interface 1003, memory 1005, at least one communication bus 1002. Wherein a communication bus 1002 is used to enable connective communication between these components. The user interface 1003 may include a Display (Display) and a Keyboard (Keyboard), and the network interface 1004 may optionally include a standard wired interface and a wireless interface (e.g., WI-FI interface). The memory 1005 may be a high-speed RAM memory or a non-volatile memory (non-volatile memory), such as at least one disk memory. The memory 1005 may optionally also be at least one storage device located remotely from the aforementioned processor 1001. As shown in fig. 14, a memory 1005, which is a kind of computer storage medium, may include an operating system, a network communication module, a user interface module, and a device control application program.

In the computer device 1000 shown in fig. 14, the network interface 1004 may provide a network communication function; the user interface 1003 is an interface for providing a user with input; and the processor 1001 may be used to invoke a device control application stored in the memory 1005 to implement:

It should be understood that the computer device 1000 described in this embodiment of the present application may perform the description of the data synchronization method in the embodiments corresponding to fig. 2, fig. 5, fig. 8, and fig. 10, and may also perform the description of the data synchronization apparatus 1 in the embodiment corresponding to fig. 12, which is not described herein again. In addition, the beneficial effects of the same method are not described in detail.

Further, please refer to fig. 15, where fig. 15 is a schematic structural diagram of a computer device according to an embodiment of the present application. As shown in fig. 15, the computer device 2000 may be the light node in the embodiment corresponding to fig. 8, and the computer device 2000 may include: the processor 2001, the network interface 2004 and the memory 2005, the computer device 2000 may further include: a user interface 2003, and at least one communication bus 2002. The communication bus 2002 is used to implement connection communication between these components. The user interface 2003 may include a Display (Display) and a Keyboard (Keyboard), and the optional user interface 2003 may further include a standard wired interface and a standard wireless interface. The network interface 2004 may optionally include a standard wired interface, a wireless interface (e.g., WI-FI interface). The memory 2005 may be a high-speed RAM memory, or may be a non-volatile memory (e.g., at least one disk memory). The memory 2005 may optionally also be at least one memory device located remotely from the aforementioned processor 2001. As shown in fig. 15, the memory 2005 which is a kind of computer-readable storage medium may include therein an operating system, a network communication module, a user interface module, and a device control application program.

In the computer device 2000 shown in fig. 15, the network interface 2004 may provide a network communication function; and the user interface 2003 is primarily used to provide an interface for user input; and processor 2001 may be used to invoke the device control application stored in memory 2005 to implement:

It should be understood that the computer device 2000 described in this embodiment of the present application may perform the description of the data synchronization method in the embodiments corresponding to fig. 2, fig. 5, fig. 8, and fig. 10, and may also perform the description of the data synchronization apparatus 2 in the embodiment corresponding to fig. 13, which is not described herein again. In addition, the beneficial effects of the same method are not described in detail.

An embodiment of the present application further provides a computer-readable storage medium, where a computer program is stored in the computer-readable storage medium, where the computer program includes program instructions, and when the program instructions are executed by a processor, the data synchronization method provided in each step in fig. 2, fig. 5, fig. 8, and fig. 10 is implemented, which may specifically refer to the implementation manner provided in each step in fig. 2, fig. 5, fig. 8, and fig. 10, and is not described herein again. In addition, the beneficial effects of the same method are not described in detail.

The computer-readable storage medium may be the data synchronization apparatus provided in any of the foregoing embodiments or an internal storage unit of the computer device, such as a hard disk or a memory of the computer device. The computer readable storage medium may also be an external storage device of the computer device, such as a plug-in hard disk, a Smart Memory Card (SMC), a Secure Digital (SD) card, a flash card (flash card), and the like, provided on the computer device. Further, the computer-readable storage medium may also include both an internal storage unit and an external storage device of the computer device. The computer-readable storage medium is used for storing the computer program and other programs and data required by the computer device. The computer readable storage medium may also be used to temporarily store data that has been output or is to be output.

Embodiments of the present application also provide a computer program product or computer program comprising computer instructions stored in a computer-readable storage medium. The processor of the computer device reads the computer instruction from the computer-readable storage medium, and executes the computer instruction, so that the computer device can perform the description of the data synchronization method in the embodiments corresponding to fig. 2, fig. 5, fig. 8, and fig. 10, which is not described herein again. In addition, the beneficial effects of the same method are not described in detail.

The terms "first," "second," and the like in the description and in the claims and drawings of the embodiments of the present application are used for distinguishing between different objects and not for describing a particular order. Furthermore, the terms "comprises" and any variations thereof, are intended to cover non-exclusive inclusions. For example, a process, method, apparatus, product, or apparatus that comprises a list of steps or elements is not limited to the listed steps or modules, but may alternatively include other steps or modules not listed or inherent to such process, method, apparatus, product, or apparatus.

Those of ordinary skill in the art will appreciate that the elements and algorithm steps of the examples described in connection with the embodiments disclosed herein may be embodied in electronic hardware, computer software, or combinations of both, and that the components and steps of the examples have been described in a functional general in the foregoing description for the purpose of illustrating clearly the interchangeability of hardware and software. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the implementation. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.

The method and the related apparatus provided by the embodiments of the present application are described with reference to the flowchart and/or the structural diagram of the method provided by the embodiments of the present application, and each flow and/or block of the flowchart and/or the structural diagram of the method, and the combination of the flow and/or block in the flowchart and/or the block diagram can be specifically implemented by computer program instructions. These computer program instructions may 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, create means for implementing the functions specified in the flowchart flow or flows and/or block or blocks of the block diagram. These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block or blocks of the block diagram. These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block or blocks.

The above disclosure is only for the purpose of illustrating the preferred embodiments of the present application and is not to be construed as limiting the scope of the present application, so that the present application is not limited thereto, and all equivalent variations and modifications can be made to the present application.

Claims

1. A method of data synchronization, comprising:

acquiring a data synchronization request sent by a light node; the data synchronization request comprises a block identification of a synchronization block requested by the light node;

acquiring synchronous transaction data in the synchronous block according to the block identification, and acquiring a target data set associated with the synchronous transaction data from a full database; the synchronized transaction data includes transaction detail data; the target data set comprises a first data set carrying a read tag and a second data set carrying a write tag; the reading marks are used for representing that the first data set is the same as the reading data corresponding to the transaction detail data, and the writing marks are used for representing that the second data set is the same as the result data corresponding to the transaction detail data;

determining a synchronous data set from the target data set according to the data synchronization request;

and acquiring verification data corresponding to the synchronous transaction data from the synchronous block, and returning the synchronous transaction data, the verification data and the synchronous data set to the light node, so that the light node verifies the legality of to-be-verified result data corresponding to the synchronous transaction data and the transaction detail data according to the verification data and the synchronous data set.

2. The method of claim 1, wherein the data synchronization request comprises a node identification of the light node; the synchronized transaction data includes transaction detail data and contract information for executing a smart contract for the transaction detail data;

the determining a synchronized data set from the target data set according to the data synchronization request includes:

and determining the synchronous data set from the target data set according to the transaction detail data, the node identification and the target synchronous read transaction execution function.

3. The method of claim 2, wherein determining a target synchronous read transaction execution function for the transaction detail data based on the contract information and the data synchronization request comprises:

acquiring a contract name and a transaction execution function name in the contract information; wherein the contract name is used for characterizing the name of the intelligent contract for executing the transaction detail data, and the transaction execution function name is used for characterizing the name of a transaction execution function called by the intelligent contract for executing the transaction detail data;

acquiring a synchronous reading name according to the data synchronous request, and determining a synchronous reading transaction execution function name according to the transaction execution function name and the synchronous reading name;

and determining a target synchronous read transaction execution function in the intelligent contract corresponding to the synchronous read transaction execution function name.

4. The method of claim 2, wherein determining a synchronized data set from the target data set according to the transaction detail data, the node identification, and the target synchronized read transaction execution function comprises:

determining the synchronization authority of the light node aiming at the synchronous transaction data according to the node identification and the target synchronous read transaction execution function; the synchronous authority comprises a synchronous legal authority and a synchronous illegal authority;

if the synchronous authority of the light node for the synchronous transaction data is the synchronous illegal authority, returning data synchronization failure information to the light node;

and if the synchronous authority of the light node for the synchronous transaction data is the synchronous legal authority, determining the synchronous data set from the target data set according to the transaction detail data, the node identification and the target synchronous read transaction execution function.

5. The method of claim 4, wherein determining the synchronized data set from the target data set according to the transaction detail data, the node identification, and the target synchronized read transaction execution function comprises:

determining an existing data set which is stored by the light node and is associated with the transaction detail data according to the transaction detail data, the node identification and the target synchronous read transaction execution function;

and filtering the existing data set from the target data set, and determining the filtered target data set as the synchronous data set.

6. The method of claim 5, wherein determining the filtered target data set as the synchronized data set comprises:

determining an additional data set of the light node aiming at the transaction detail data according to the node identification and the target synchronous read transaction execution function; the target data set does not include the additional data set;

and merging the additional data set and the filtered target data set to obtain the synchronous data set.

7. The method of claim 1, wherein the synchronized transaction data includes transaction detail data; the outcome data is generated based on a transaction execution outcome; generating the transaction execution result when the full-scale node executes the transaction detail data;

the obtaining of the verification data corresponding to the synchronous transaction data from the synchronous block includes:

acquiring a transaction state tree and a result state tree from the synchronization block; the transaction state tree is a transaction Mercker tree generated based on the transaction detail data; the result state tree is a result merkel tree generated based on the result data;

obtaining transaction verification data from the transaction status tree based on the transaction detail data, and obtaining result verification data from the result status tree based on the result data;

determining the transaction verification data and the result verification data as verification data.

8. The method of claim 7, wherein obtaining transaction verification data from the transaction status tree based on the transaction detail data and obtaining result verification data from the result status tree based on the result data comprises:

acquiring a transaction hash value in the transaction state tree according to the transaction detail data, and acquiring a result hash value in the result state tree according to the result data;

and determining the transaction hash value as the transaction verification data, and determining the result hash value as the result verification data.

9. The method of claim 1, further comprising:

acquiring transaction detail data in a block to be linked, and calling a transaction execution function in an intelligent contract for executing the transaction detail data;

acquiring historical transaction data aiming at the transaction detail data according to the transaction execution function, and determining the historical transaction data as read data;

executing the transaction executing function according to the read data and the transaction detail data to obtain a transaction executing result of the transaction detail data;

and performing uplink processing on the block to be uplink processed according to the transaction detail data and the transaction execution result.

10. The method according to claim 9, wherein said uplink processing the to-be-uplink block according to the transaction detail data and the transaction execution result comprises:

when the transaction detail data and the transaction execution result are both identified, generating the result data according to the transaction execution result;

generating a transaction state tree according to the transaction detail data, generating a result state tree according to the result data, and adding the transaction state tree and the result state tree to the block to be uplink;

determining a block to be uplink added with the transaction state tree and the result state tree as the synchronization block, and adding the synchronization block to a block chain;

and generating the target data set according to the read data and the result data, and storing the target data set in a full database.

11. The method of claim 10, wherein generating the target data set from the read data and the result data, storing the target data set in a full-scale database, comprises:

comparing the read data and the result data with the historical data set respectively; the historical data set comprises historical reading data or historical result data corresponding to historical transaction detail data stored in the full database;

if a historical data set which is the same as the read data exists and a historical data set which is the same as the result data exists, performing reading mark processing on the historical data set which is the same as the read data, determining the historical data set carrying a reading mark as a first data set, performing writing mark processing on the historical data set which is the same as the result data, and determining the historical data set carrying a writing mark as a second data set;

determining the first data set and the second data set as target data sets, and storing the target data sets and the transaction detail data in a full database in an associated manner;

and if the historical data set identical to the read data does not exist and the historical data set identical to the result data does not exist, determining the read data and the result data as a target data set, and storing the target data set and the transaction detail data in a full-scale database in an associated manner.

12. A computer device, comprising: a processor, a memory, and a network interface;

the processor is connected with the memory and the network interface, wherein the network interface is used for providing data communication functions, the memory is used for storing a computer program, and the processor is used for calling the computer program to enable the computer device to execute the method of any one of claims 1 to 11.

13. A computer-readable storage medium, in which a computer program is stored which is adapted to be loaded and executed by a processor to cause a computer device having said processor to carry out the method of any one of claims 1 to 11.