CN109587238B

CN109587238B - Data processing and synchronizing method, device, equipment and storage medium of block chain

Info

Publication number: CN109587238B
Application number: CN201811465309.2A
Authority: CN
Inventors: 荆博
Original assignee: Beijing Baidu Netcom Science and Technology Co Ltd
Current assignee: Beijing Baidu Netcom Science and Technology Co Ltd
Priority date: 2018-12-03
Filing date: 2018-12-03
Publication date: 2021-08-03
Anticipated expiration: 2038-12-03
Also published as: CN109587238A

Abstract

The embodiment of the invention discloses a data processing and synchronizing method, a data processing and synchronizing device, data processing and synchronizing equipment and a storage medium for a block chain. The data processing method of the block chain is applied to the block chain node, and the method comprises the following steps: when the set triggering condition is determined to be met, determining at least one synchronous block to be provided with a check point; calculating the check point identification of the check point according to the data of the synchronous blocks in the block chain; transmitting the check point identification in the block chain network to request other block chain link points to verify and feed back an approval signature; if the received approval signature meets the validation condition, the checkpoint identification and the approval signature are recorded locally corresponding to the sync block. By adopting the technical scheme of the embodiment of the invention, if other nodes need to carry out block synchronization, the synchronous blocks can be obtained according to the check point identification by taking the check point as a unit, the data of the synchronous blocks are directly imported into the local nodes, and the repeated verification is not needed, so that the data synchronization can be accelerated.

Description

Data processing and synchronizing method, device, equipment and storage medium of block chain

Technical Field

Embodiments of the present invention relate to a block chain technology, and in particular, to a method, an apparatus, a device, and a storage medium for processing and synchronizing data of a block chain.

Background

The blockchain is a novel application mode of computer technologies such as distributed data storage, point-to-point transmission, a consensus mechanism and an encryption algorithm.

Typically, each node in a blockchain network maintains the full amount of block data, and the blockchain network continuously generates new blocks, and the amount of data that each node needs to maintain becomes larger and larger over time. Since the block chain belongs to a chain data structure, each block points to the next block, and therefore, the verification of the validity of the data needs to be performed on each block sequentially from the created block.

For a node newly joining the blockchain network, all historical block data needs to be synchronized first and validity check is performed one by one, so that synchronization of the latest block can be started. The historical block data is often large, so the synchronization process takes a long time.

Disclosure of Invention

The embodiment of the invention provides a data processing and synchronizing method, a data processing and synchronizing device, data processing and synchronizing equipment and a storage medium of a block chain, and aims to accelerate synchronization of block data.

In a first aspect, an embodiment of the present invention provides a data processing method for a block chain, where the method is applied to a block chain node, and the method includes:

when the set triggering condition is determined to be met, determining at least one synchronous block to be provided with a check point;

calculating the check point identification of the check point according to the data of the synchronous blocks in the block chain;

transmitting the check point identification in a block chain network to request other block chain link points to verify and feed back an approval signature;

if the received approval signature meets the validation condition, the checkpoint identification and the approval signature are recorded locally corresponding to the synchronization block.

In a second aspect, an embodiment of the present invention further provides a data synchronization method for a block chain, where the method is applied to a block chain node, and the method includes:

initiating a block synchronization request to a check node, and receiving data, check point identification and an approval signature of a synchronization block fed back by the check node, wherein the check point identification is calculated and determined by the check node according to the data of the synchronization block, and the approval signature is fed back to the check node by other nodes for verification of the check point identification;

verifying the authenticity of the checkpoint identification according to the endorsement signature;

if the check point identification is true, verifying the data authenticity of the synchronous block according to the check point identification;

and if the authenticity verification of the data of the synchronous block is passed, storing the data of the synchronous block.

In a third aspect, an embodiment of the present invention further provides a data processing apparatus for a blockchain, where the data processing apparatus is configured in a blockchain node, and the apparatus includes:

the checking block determining module is used for determining at least one synchronous block of a checking point to be created when the setting triggering condition is determined to be met;

the identification calculation module is used for calculating the checkpoint identification of the checkpoint according to the data of the synchronous blocks in the block chain;

the identification transmission module is used for transmitting the check point identification in the block chain network so as to request other block chain link points to carry out verification and feed back an approval signature;

and the recording module is used for locally recording the checkpoint identification and the authorized signature corresponding to the synchronous block if the received authorized signature meets the validation condition.

In a fourth aspect, an embodiment of the present invention further provides a data synchronization apparatus for a block chain, where the data synchronization apparatus is configured in a block chain node, and the apparatus includes:

the communication module is used for initiating a block synchronization request to the inspection node and receiving data, an inspection point identifier and an approval signature of the synchronization block fed back by the inspection node, wherein the inspection point identifier is calculated and determined by the inspection node according to the data of the synchronization block, and the approval signature is fed back to the inspection node after other nodes verify the inspection point identifier;

the identification verification module is used for verifying the authenticity of the check point identification according to the endorsement signature;

the data verification module is used for verifying the data authenticity of the synchronous block according to the check point identification if the check point identification is real;

and the data storage module is used for storing the data of the check block if the data authenticity verification of the synchronous block passes.

In a fifth aspect, an embodiment of the present invention further provides an apparatus, where the apparatus includes:

one or more processors;

storage means for storing one or more programs;

when the one or more programs are executed by the one or more processors, the one or more processors implement the data processing method of the blockchain according to the first aspect, or implement the data synchronization method of the blockchain according to the second aspect.

In a sixth aspect, an embodiment of the present invention further provides a storage medium, on which a computer program is stored, where the computer program, when executed by a processor, implements the data processing method of the blockchain in the first aspect, or implements the data synchronization method of the blockchain in the second aspect.

According to the data processing and synchronization method, device, equipment and storage medium of the block chain provided by the embodiment of the invention, when the local node determines that the set triggering condition is met, the creation operation of the check point is executed, at least one synchronous block of the check point to be created is determined, the check point identification of the check point is calculated based on the data of the synchronous block, the check point identification of other block chain link points is requested to be verified and the authorized signature is fed back, and then under the condition that the received authorized signature meets the validation condition, the incidence relation among the synchronous block, the check point identification and the authorized signature is locally recorded, so that the creation of the check point is completed. If a certain blockchain node needs to perform block synchronization, such as a node newly added to a blockchain network, a check point can be used as a unit to acquire a synchronization block according to a check point identifier, and data of the synchronization block is directly imported into the local node without repeatedly performing check, so that data synchronization can be accelerated.

Drawings

Fig. 1 is a flowchart of a data processing method for a block chain according to an embodiment of the present invention;

fig. 2 is a flowchart of a data processing method of a block chain according to a second embodiment of the present invention;

fig. 3 is a flowchart of a data processing method of a block chain according to a third embodiment of the present invention;

fig. 4 is a flowchart of a data synchronization method for a block chain according to a fourth embodiment of the present invention;

fig. 5 is a flowchart of a data synchronization method for a blockchain according to a fifth embodiment of the present invention;

fig. 6 is a schematic structural diagram of a data processing apparatus of a block chain according to a sixth embodiment of the present invention;

fig. 7 is a schematic structural diagram of a data synchronization apparatus for a block chain according to a seventh embodiment of the present invention;

fig. 8 is a schematic structural diagram of an apparatus provided in the eighth embodiment of the present invention.

Detailed Description

The present invention will be described in further detail with reference to the accompanying drawings and examples. It is to be understood that the specific embodiments described herein are merely illustrative of the invention and are not limiting of the invention. It should be further noted that, for the convenience of description, only some of the structures related to the present invention are shown in the drawings, not all of the structures.

Example one

Fig. 1 is a flowchart of a data processing method of a blockchain according to an embodiment of the present invention, which is applicable to a data processing situation in which a check point is created for a synchronization block in a blockchain network, where the created check point is applicable to a scenario in which a certain node, such as a node newly added to the blockchain network, needs to perform block synchronization. The applicable blockchain may be a public chain, a private chain, or a federation chain. The scheme of the embodiment of the invention is applied to the blockchain node, and the method can be executed by a data processing device of the blockchain, and the device can be realized in a software and/or hardware mode and can be integrated in a computing device for bearing the blockchain node. Referring to fig. 1, the method specifically includes:

s110, when the set triggering condition is determined to be met, at least one synchronous block of the check point to be created is determined.

In this embodiment, the setting of the trigger condition refers to a rule that is to be satisfied when a preset node in the blockchain network creates a checkpoint; the set trigger condition may be predetermined at the time of creation of the blockchain, stored in a blockchain created block, i.e., the 0 th block of the blockchain, or stored locally at the node independently of the blockchain; the method can also be added to a certain block of the blockchain based on a voting selection mechanism in the blockchain creation process, for example, the method can be submitted to a blockchain network in the form of an intelligent contract or other forms approved by the blockchain network and stored in a certain block, and the like. For example, the set trigger condition may be configured in the block chain creation block or in the deployment data of the update configuration block. The deployment data refers to nodes participating in the blockchain network, and operation mechanisms including checkpoint creating conditions and the like which need to be locally deployed, and the deployment data can be submitted to the blockchain network in the form of an intelligent contract and stored in a certain block.

Optionally, the condition that the set triggering condition is met may be that the current state of the local blockchain meets a rule of creating a check point in a blockchain created block or in deployment data of an updated configuration block, for example, the current block height of the local blockchain meets a preset block height interval, where the current block height refers to the current number of blocks of the blockchain, such as 100. Other trigger notification mechanisms may also be used to notify the local node to create a checkpoint, and the like, which is not limited in this embodiment.

The check point can also be an archiving point for instructing to archive blocks within a certain interval, such as a predetermined block height interval, where the blocks included in the predetermined block height interval are synchronization blocks. The check point may generally refer to an end position of the synchronization block, and a start position of the synchronization block defaults to a position of a last check point created by the local node. In this embodiment, the check point to be created is the check point to be created by the node of the local computer this time.

For example, determining at least one synchronization block for which a checkpoint is to be created may include: subtracting the set offset block amount and the set detection range block amount from the local latest block height, using the obtained difference sequence number block as the starting block of the synchronization block, and using the starting block plus the set detection range block amount as the ending block of the synchronization block.

In this embodiment, the latest block height refers to the number of blocks currently stored in the local block chain; the offset block amount is set to be the maximum block number of allowable bifurcation preset to prevent bifurcation, such as 6; the set detection range block amount refers to the number of spacer blocks between adjacent check points created by the local node. For example, if the height of the latest block stored locally is 106, the offset block amount is set to be 6, and the detection range block amount is set to be 50, the difference number block is the 51 st block and serves as the starting block, and the difference number block is equivalent to the next block number after the digital difference. If the number of the starting block plus the number of the blocks in the detection range is 100, the 100 th block is the end block, and therefore, the determined synchronization blocks to be checked are: the 51 st block to the 100 th block of the local block chain. If the latest block height is 156, the starting block is 101 th block and the ending block is 150 th block.

Specifically, when the local node detects that the current state of the local block chain meets the provision of creating a check point in the block chain creation block or in the deployment data of the update configuration block, the creation operation of the check point is executed, and at least one synchronization block of which the check point is to be created is determined.

It should be noted that, in this embodiment, by controlling the condition of creating the check point, the phenomenon that the operation of the block chain network is unstable due to the creation being initiated at will by the node in the block chain can be avoided, and it is further ensured that the block data in the block chain has high security.

S120, calculating the check point identification of the check point according to the data of the synchronous blocks in the block chain.

In this embodiment, the data of the synchronization block refers to all data corresponding to the synchronization block, and may include block data stored in the block, data stored locally at the node independently from the block chain, and the like. The checkpoint identifier is a flag for uniquely identifying a certain checkpoint, and may be information representing a synchronization block corresponding to the checkpoint. Optionally, the calculation mode of the check point identifier may be stored in the block chain created block or in the deployment data of the update configuration block, and the local node needs to calculate the check point identifier according to a mode specified in the block chain created block or in the deployment data of the update configuration block; in addition, the local node can also adopt a locally set calculation mode such as a public key and a private key of the local node or a signature algorithm such as SHA256 to calculate the checkpoint identifier.

Specifically, the local node may perform hash operation on the data of the synchronization block in the block chain by using a hash algorithm, such as SHA256, to obtain the checkpoint identifier of the checkpoint. The block head data or the block identification of each synchronous block can be subjected to hash operation to obtain the check point identification of the check point. Different calculation methods determine the verification degree of the data of the synchronization block, and the following embodiments will describe in detail the scheme of determining the checkpoint identifier by different calculation methods.

S130, the checkpoint identity is transmitted in the blockchain network to request other blockchain nodes to verify and feed back an approval signature.

In this embodiment, the authorized signature is obtained by verifying the checkpoint identifier by using other block link nodes, signing the checkpoint identifier by using a key such as a private key, and feeding back the checkpoint identifier to the local node. Optionally, the endorsement signature may include a checkpoint identifier signed by another blockchain node key, such as a private key, a key of another blockchain node, such as a public key, and a node identifier. The node identifier is a mark for uniquely identifying the identity of a link point of a certain block, and may be a node ID or a network IP address.

Specifically, after the local node calculates the checkpoint identifier of the checkpoint according to the data of the synchronization block in the block chain, the local node may transmit the checkpoint identifier in the block chain network to request other block chain nodes to verify the checkpoint identifier and feed back an approval signature. After receiving the check point identification sent by the local node, other block chain nodes can adopt the same calculation mode as the local node to calculate the check point identification of the check point, compare the calculated check point identification with the received check point identification, and if the check point identification is not consistent with the received check point identification, check point identification verification failure information can be sent to the block chain network or no operation is carried out; if the check point identification is consistent with the check point identification, the check point identification is signed by adopting a secret key such as a private key, and then the check point identification signed by the private key and the node public key are taken as approved signatures and fed back to the local node; the local node receives the endorsement signature fed back by other block chain nodes.

S140, if the received approval signature meets the validation condition, the checkpoint identifier and the approval signature are locally recorded corresponding to the sync block.

In this embodiment, the validation condition is that the feedback condition of the recognizable signature meets the preset requirement, that is, the recognition of the check point by other nodes meets the preset requirement. Specifically, the relative proportion or absolute number of the recognizable signatures may be preset, for example, the number of the recognizable signatures is greater than half of the total number of nodes in the blockchain network. In order to further control the authority of creating the check point, optionally, the validation condition may also be configured in the block chain creation block or in the deployment data of the update configuration block, so as to ensure that the validation condition is difficult to be tampered and is transparent.

Specifically, after receiving the authorized signatures fed back by the link points of other blocks, the node of the local node may send the number of nodes inquiring the validity of the communication certificate to the CA authentication center to obtain the number of nodes participating in the block chain network, or obtain the number of nodes participating in the block chain network by inquiring from a locally maintained table of node identification identifiers; then obtaining an effective condition from the block chain creation block, or traversing from the current block to the front to obtain the effective condition, and determining whether the received approved signature meets the effective condition or not based on the effective condition; if the approved signature meets the validation condition, establishing an incidence relation among the synchronous block, the checkpoint identification and the approved signature locally, storing the incidence relation in a locally pre-stored checkpoint index table or a current block, and the like, and further completing the creation operation of the checkpoint; if the signature is not qualified to be effective, the check point identification is invalid, and the local node can abandon the creation of the check point.

According to the technical scheme provided by the embodiment of the invention, when the local node confirms that the set triggering condition is met, the creation operation of the check point is executed, at least one synchronous block of the check point to be created is confirmed, the check point identification of the check point is calculated based on the data of the synchronous block, the check point identification of other block chain link points is requested to be verified and the authorized signature is fed back, and then under the condition that the received authorized signature meets the validation condition, the incidence relation among the synchronous block, the check point identification and the authorized signature is locally recorded, so that the creation of the check point is completed. If other nodes need to perform block synchronization, such as nodes newly added to the block chain network, the check point can be used as a unit, the synchronization block is obtained according to the check point identifier, the data of the synchronization block is directly imported into the local nodes, and the check is not required to be repeatedly executed, so that the data synchronization can be accelerated, and a new idea is provided for the data synchronization of the block chain.

Example two

Fig. 2 is a flowchart of a data processing method of a blockchain according to a second embodiment of the present invention, and this embodiment further explains the calculation of the checkpoint identifier of the checkpoint according to the data of the sync block in the blockchain based on the above embodiments. Referring to fig. 2, the method specifically includes:

s210, when the set triggering condition is determined to be met, at least one synchronous block of the check point to be created is determined.

S220, exporting the block data of the synchronous blocks in the block chain and the local table data to form a synchronous block file.

In this embodiment, the block data refers to data stored in a block, and the local table data refers to data stored locally at a node independently from a block chain. For example, the chunk data may include a chunk body and a chunk header, where the chunk header is used to store a previous chunk identifier, a timestamp for creating the chunk, a random number, a target hash, a root of a merkel tree created by transaction data in the chunk, and the like; the block body is used to store the transaction data itself. The data volume of the operating function, the execution result, the transaction historical data and the like of the intelligent contract is relatively huge, and the data volume of the transaction output data which is not spent is relatively small. Therefore, preferably in this embodiment, the chunk is used to store the non-spent transaction output data; the local table data is used for storing the execution function and execution result of the intelligent contract, and is used for storing transaction history data and the like.

The unspent Transaction output data, that is, utxo (unspent Transaction output) data, is a basic unit of digital money Transaction, and is a data structure including Transaction data and an execution code, or, in other words, an address such as encrypted digital money that has been received by the account B but not spent yet. Funds can be changed into a piece of digital structure (also called a Transaction, or a trade order) by the input and output of the trade based on the UTXO data. Correspondingly, the transaction history data is the digital currency that has been spent. The running function refers to a function related in the process of running the code segment corresponding to the intelligent contract, and specifically includes a function written in the intelligent contract, a function having a dynamic binding relationship and called in running, and the like. And the execution result is the result output after the code segment corresponding to the intelligent contract is operated.

Specifically, after determining at least one synchronization block to be checked, the local node may export block data of the synchronization block in the block chain and local table data, and perform serialization processing to form a synchronization block file. The sync block file is used to represent data information of a sync block corresponding to the check point, and optionally, one or more sync block files may be used.

For example, exporting the chunk data and the local table data of the sync chunk in the chunk chain, forming the sync chunk file may include: exporting the block data of the synchronous block in the block chain and the local table data to form a synchronous block file; or respectively exporting the block data of the synchronous blocks in the block chain and the local table data according to the data type table to form a plurality of synchronous block files.

In this embodiment, the data type refers to the type of the data of the sync block; the UTXO data, the smart contract data (data corresponding to the execution function and execution result of the smart contract), and the transaction history data may be included. For convenience of management, data types can be classified and stored, and data of the same type is stored in the same data table, that is, one data type table stores one type of data, and the number of the data type tables represents the number of types of data. Therefore, the local node can directly export the block data of the synchronous block in the block chain and the local table data, and generate a synchronous block file after processing; and according to the data type table, exporting data in the data type table to form a synchronous block file, and further forming a plurality of synchronous block files.

Optionally, the data of the synchronization block in this embodiment may be stored based on a database in the form of Level DB. Therefore, if the local node derives the block data and the local table data of the synchronization block in the block chain according to the data type table to form a plurality of synchronization block files, the name of each synchronization block file can be determined according to the Level DB table name, the block chain name, the data type, and the like. For example, the sync block file name is: block chain name + data type (UTXO data/smart contract data/transaction history data) + Level DB table name. If the local node exports the block data of the synchronous block in the block chain and the local table data to form a synchronous block file, the name of the synchronous block file can be directly determined according to the block chain name and the Level DB table name.

In summary, the data used for calculating the checkpoint identifier in the embodiment of the present invention is not limited to only the data stored on the blockchain itself, and may also include local table data associated with the blockchain. The storage classification of the local table data is not limited to the above three types, and may be each storage table determined based on the storage architecture requirement.

S230, according to the data in the synchronous block file, the check point identification of the check point is calculated.

Specifically, the local node may calculate the checkpoint identifier according to the data in the synchronization block file, in a manner specified in the block chain creation block or in the deployment data of the update configuration block, or in a calculation manner set locally by the local node. For example, a hash algorithm may be used to perform a hash operation on the data in the synchronization block file to obtain a hash value, and the hash value is used as a checkpoint identifier of the checkpoint.

In this embodiment, the number of the sync block files is different, and the manner of determining the checkpoint identifier based on the sync block files is different. For example, calculating a checkpoint identification for a checkpoint may include, based on data in the sync chunk file: and calculating a hash value according to the data in the synchronous block file as the check point identification. Specifically, the local node may calculate a hash value for the data in the synchronization block file by using a hash algorithm, and use the hash value as the checkpoint identifier.

The method can also be as follows: and respectively calculating the hash value of each synchronous block file, establishing a Meckel tree according to each hash value of the file, and taking the root of the Meckel tree as a check point identifier. In this embodiment, the file hash value is obtained by calculating a hash value based on data in one sync block file. Specifically, the local node can respectively calculate the file hash value of each synchronous block file by adopting a hash algorithm, then generate a Merkel tree by adopting a Merkel tree algorithm according to each file hash value, and take the root of the Merkel tree as a check point identifier.

In addition, a hash value may be calculated from the chunk header data of the sync chunk as the checkpoint identifier. Specifically, the local node may obtain the block identifier of each synchronization block from the block header of each synchronization block, then connect the block identifiers of each synchronization block together as an integral identifier according to the serial number sequence of each synchronization block, and calculate a hash value for the integral identifier to obtain a check point identifier; the hash value of the block head data of each synchronous block can be calculated, then the Merkel tree is generated by adopting the Merkel tree algorithm according to the hash values, and the root of the Merkel tree is used as the check point identifier. In this embodiment, the way of calculating the checkpoint identifier based on the block header data of the synchronization block is more suitable for the lightweight node of the local non-storage block chain of the node to perform data verification of the subsequent synchronization block.

S240, the checkpoint identity is transmitted in the blockchain network to request other blockchain nodes to verify and feed back an approval signature.

And S250, if the received approval signature meets the validation condition, locally recording the checkpoint identification and the approval signature corresponding to the synchronous block.

It should be noted that, in this embodiment, by exporting the block data of the synchronization block and the local table data as a whole, that is, synchronizing the block file, the node that subsequently joins the block chain network can directly import the synchronization block file into the local area when performing block chain synchronization, thereby ensuring that not only the block data stored in the block can be synchronized, but also the data that is locally stored in the node depending on the block chain but independent of the block chain can be synchronized together, that is, ensuring the integrity of the synchronized block chain and at the same time accelerating the synchronization speed.

According to the technical scheme provided by the embodiment of the invention, after determining at least one synchronous block of the check point to be created, the local node can export the block data and the local table data of the synchronous block in the block chain and perform serialization processing to form a synchronous block file; and calculating the check point identification of the check point based on the data of the synchronous block file, requesting other block chain link points to verify the check point identification and feeding back an authorized signature, and then locally recording the incidence relation among the synchronous block, the check point identification and the authorized signature under the condition that the received authorized signature meets the validation condition, thereby completing the creation of the check point. If other nodes need to perform block synchronization, such as nodes newly added to the blockchain network, the synchronization block can be acquired according to the checkpoint identifier by taking the checkpoint as a unit, and the data of the synchronization block is directly imported into the local nodes without repeatedly performing verification, so that the data synchronization can be accelerated.

EXAMPLE III

Fig. 3 is a flowchart of a data processing method of a blockchain according to a third embodiment of the present invention, and in this embodiment, based on the above embodiments, if the received endorsement signature meets the validation condition, the checkpoint identifier and the endorsement signature are locally recorded corresponding to the sync block for explanation. Referring to fig. 3, the method specifically includes:

s310, when the set triggering condition is determined to be met, at least one synchronous block of the check point to be created is determined.

S320, calculating the check point identification of the check point according to the data of the synchronous blocks in the block chain.

S330, the checkpoint identity is transmitted in the blockchain network to request other blockchain nodes to verify and feed back an approval signature.

Optionally, the endorsement signature may include a checkpoint identifier signed by another blockchain node key, such as a private key, a key of another blockchain node, such as a public key, a node identifier, and the like.

S340, obtain the check point id signed by the private key of the other blockchain node from the received authorized signature, and obtain the public key of the other blockchain node.

Specifically, after receiving the authorized signatures fed back by other block link points, for each authorized signature, the local node may obtain, from the authorized signature, a checkpoint identifier signed by a private key of a certain block link point and a public key of the block link node, and then identify, by using the public key of the block link node, the checkpoint identifier signed by using the private key of the block link point to obtain a checkpoint identifier; comparing the obtained check point identification with the locally calculated check point identification, and if the check point identification is consistent with the locally calculated check point identification, indicating that the check point identification is valid; if not, the check point mark is invalid.

And S350, if the checkpoint identification of the signature is verified to be valid through the public key, determining that the approved signature is valid.

Specifically, for each check point identifier signed by the private key of a block chain link point, if the local node verifies that the check point identifier signed by the private key of the block chain link point is valid through the public key of a certain block chain node, the approved signature fed back by the block chain link point is determined to be valid; otherwise, determining that the authorized signature fed back by the block link point is invalid.

And S360, if the number of the valid authorized signatures meets the validation condition, locally recording the checkpoint identification and the authorized signatures corresponding to the synchronous blocks.

Specifically, the local node may determine the number of nodes participating in the blockchain network, and then obtain an effective condition from a blockchain created block, or traverse forward from the current block to obtain an effective condition, and determine whether the number of valid recognizable signatures meets the relative proportion or absolute number specified in the effective condition based on the effective condition; if the check point identification is matched with the signature, establishing an incidence relation among the synchronous block, the check point identification and the authorized signature locally, and storing the incidence relation in a locally pre-constructed check point index table or a current block, and the like; if not, the check point identification is invalid, and the local node can abandon the creation of the check point.

According to the technical scheme provided by the embodiment of the invention, when the local node is determined to meet the set triggering condition, the creation operation of the check point is executed, at least one synchronous block of the check point to be created is determined, the check point identification of the check point is calculated based on the data of the synchronous block, and the check point identification is verified and fed back by requesting other block chain link points; and then, the validity of the received authorized signature is determined, and under the condition that the valid authorized signature meets the validation condition, the incidence relation among the synchronous block, the check point identification and the authorized signature is locally recorded, the authority created by the check point is further controlled, and the block data in the block chain is ensured to have high safety. If other nodes need to perform block synchronization, such as nodes newly added to the block chain network, the check point can be used as a unit, the synchronization block is obtained according to the check point identifier, the data of the synchronization block is directly imported into the local nodes, and the check is not required to be repeatedly executed, so that the data synchronization can be accelerated, and a new idea is provided for the data synchronization of the block chain.

Example four

Fig. 4 is a flowchart of a data synchronization method for a blockchain according to a fourth embodiment of the present invention, where this embodiment is applicable to a situation where a node in a blockchain network performs block synchronization, and is particularly applicable to a scenario where a node newly joining the blockchain network performs block synchronization based on a check point in the blockchain network. The checkpoint in this embodiment may be created by using the scheme in the above embodiment. The scheme of the embodiment of the invention is applied to the blockchain node, and the method can be executed by a data synchronization device of the blockchain, and the device can be realized in a software and/or hardware mode and can be integrated in a computing device bearing the blockchain node. Referring to fig. 4, the method specifically includes:

s410, a block synchronization request is sent to the checking node, and the data of the synchronization block, the checking point identification and the approval signature fed back by the checking node are received.

In this embodiment, the check node is a block link point where a check point has been locally constructed or stored in a node in the block link network, and the corresponding check node identifier is a block link point identifier; the block synchronization request refers to a request generated when a node in a block chain network needs to perform block chain synchronization, and the block synchronization request may include a node identifier, and may also include a synchronization block to be synchronized, an identifier of each synchronization block, and the like. Optionally, generating the block synchronization request may include: if the blockchain node is a node newly added into the blockchain, or the blockchain of the blockchain node lacks part or all blocks due to communication quality or other factors such as malicious attack and the like, the blockchain needs to be downloaded locally and synchronously, and a blockchain synchronization request is generated. Optionally, the block synchronization request may be initiated by the block link node itself to the check node; or a request initiated to the check node when the current block generation node or other authority node detects that other block link points need to perform block chain synchronization, and the like. In this embodiment, it is preferable that the blockchain node itself initiates a block synchronization request to the check node.

The check point identification is determined by the check node according to the data calculation of the synchronous block, and the signature is approved to be verified by other nodes and fed back to the check node. The data of the sync block refers to all data corresponding to the sync block, and may include block data stored in the block, data stored locally at the node independent of the block chain, and the like. Exemplary, the data of the sync block may include: a sync block file derived from block data of sync blocks in the block chain and the local table data; or a plurality of synchronous block files respectively derived from the block data of the synchronous blocks in the block chain and the local table data according to the data type table. The block data comprises a block body and a block head, wherein the block body is used for storing the non-expense transaction output data; the local table data is used for storing the operation function and the execution result of the intelligent contract and storing the transaction history data.

Specifically, when the block chain node needs to perform block chain synchronization, a block synchronization request can be initiated to a check node in the block chain network; the check node receives a block synchronization request initiated by a block chain node, can search in a locally stored check point index table according to the identification of a synchronization block required in the block synchronization request, and feeds back the data of the synchronization block, the check point identification and an authorized signature to the block chain node if a check point meeting the requirement exists; if the checking point which meets the requirement does not exist locally in the checking node, a checking point which meets the requirement of the block chain node point can be created temporarily, and the data, the checking point identification and the authorized signature of the synchronous block are fed back to the block chain node point. Wherein, the checkpoint index table stores the association relationship among the checkpoint identifier, the sync block and the authorized signature.

It should be noted that a check point corresponds to a group of sync blocks, check point identifiers and authorized signatures, and the number of sync blocks, check point identifiers and authorized signatures received by the blockchain node may be multiple groups. For example, the synchronous blocks required by the local node are the data of the 0 th block to the 200 th block, and the synchronous blocks corresponding to the check point a constructed by the check node are the 0 th block to the 100 th block; the sync blocks corresponding to the check point B are the 101 th block to the 200 th block, and at this time, the local node receives two sets of sync blocks, a check point id and an approval signature. Alternatively, the plurality of sets of synchronization blocks, checkpoint identifications and approval signatures may originate from the same checkpoint or from multiple checkpoints.

Exemplary, before initiating the block synchronization request to the checking node, the method may further include: the blockchain node determines the identity of the blockchain node (check node) in the blockchain network that has constructed the checkpoint. Specifically, the block link points may send check point acquisition requests to the block chain network, and then, according to feedback from other block chain nodes, use the block link points where check points have been constructed as check nodes, and initiate block synchronization requests to corresponding check nodes according to check node identifiers.

And S420, verifying the authenticity of the check point identifier according to the approved signature.

In this embodiment, when the check node creates the check point, the check point identifier needs to be transmitted in the blockchain network to request other blockchain link points to verify the check point identifier and feed back an approval signature. Thus, the block link points can verify the authenticity of the checkpoint identity based on the number of recognizable signatures fed back by the check node. Specifically, the block link points determine the number of recognizable signatures fed back by the check nodes and the number of nodes participating in the block link network; then, according to the approved signature data and the number of the nodes of the blockchain network, whether the ratio of the number of the recognizable signatures to the number of the nodes participating in the blockchain network is larger than a set ratio value or not or whether the absolute difference value of the number of the recognizable signatures to the number of the nodes participating in the blockchain network is larger than a set number or not is determined; if any one of the conditions is met, determining that the checkpoint identification is true; if the check point identification fed back by the check node is not valid, that is, the check point identification is not true.

And S430, if the check point identification is true, verifying the data authenticity of the synchronous block according to the check point identification.

Specifically, under the condition that the check point identifier is determined to be true, the block chain node may calculate the check point identifier in the same calculation manner as the check node according to the data of the synchronization block fed back by the check node, and compare the calculated check point identifier with the check point identifier fed back by the check node, if the check point identifier is consistent with the check point identifier fed back by the check node, it is determined that the data of the synchronization block is true, that is, the check node does not make a false or falsify the data of the synchronization block, and the like; if the data of the synchronization block is inconsistent with the data of the synchronization block, a verification request comprising the data of the synchronization block can be sent to the block chain network to request other block chain nodes to calculate and feed back the check point identification according to the data of the synchronization block, and whether the block chain node is calculated incorrectly or the data of the synchronization block fed back by the check node is incorrect and the like are confirmed according to the feedback result.

For example, verifying the authenticity of the data of the sync block according to the checkpoint identification may be: calculating a hash value according to the data in the synchronous block file, taking the hash value as a check point identifier, and comparing the check point identifier with the received check point identifier to verify the authenticity of the data; or respectively calculating file hash values of the synchronous block files, establishing a Merkel tree according to the file hash values, and comparing the root of the Merkel tree serving as a check point identifier with the received check point identifier to verify the authenticity of the data. If the local node is a lightweight node, a hash value can be calculated according to the block header data of the synchronous block and used as a check point identifier to be compared with the received check point identifier so as to verify the authenticity of the data and the like.

S440, if the authenticity of the data of the sync block is verified, the data of the sync block is stored.

Specifically, if the chunk node verifies that the data of the synchronization chunk is real according to the checkpoint identifier, the data of the synchronization chunk associated with the checkpoint identifier may be directly imported to the local node. In addition, if the block synchronization request is initiated by the current block generation node, after the authenticity of the data of the synchronization block is verified, the current block generation node may directly feed back the data of the synchronization block to the node that needs the synchronization block chain, so that the node introduces the data of the synchronization block into the local node to complete block chain synchronization.

It should be noted that, if some blocks are not synchronized after the block chain node stores the data of the synchronized block, the block chain node needs to synchronize the remaining blocks one by one until the newest block is reached.

According to the technical scheme provided by the embodiment of the invention, when block chain synchronization is required to be carried out on the block chain nodes, a block synchronization request can be initiated to the checking node so as to request the checking node to feed back data, a checking point identifier and an authorized signature of the synchronization block; then, verifying the authenticity of the received check point identification according to the approval signature fed back by the check node, and verifying the data authenticity of the synchronization block again according to the check point identification under the condition that the check point identification is real; and finally storing the data of the synchronous block when the authenticity verification of the data of the synchronous block passes. According to the scheme, if other nodes need to perform block synchronization if the nodes newly add in the block chain network, the data of the synchronization block associated with the check point identifier can be directly imported into the local nodes by taking the check point as a unit without repeatedly performing check, so that the synchronization speed is accelerated while the integrity of the synchronous block chain is ensured, and a new idea is provided for data synchronization of the block chain.

EXAMPLE five

Fig. 5 is a flowchart of a method for synchronizing data of a blockchain according to a fifth embodiment of the present invention, which further explains the authenticity of the checkpoint identifier according to the endorsement signature verification based on the foregoing embodiments. Referring to fig. 5, the method specifically includes:

s510, a block synchronization request is sent to the checking node, and the data of the synchronization block, the check point identifier and the authorization signature fed back by the checking node are received.

The check point identification is determined by calculation of the check node according to the data of the synchronous block, and the signature is approved to be verified by other nodes and fed back to the check node. Optionally, the endorsement signature may include a checkpoint identifier signed by another blockchain node key, such as a private key, a key of another blockchain node, such as a public key, a node identifier, and the like. The number of the recognizable signatures associated with one checkpoint identifier is multiple.

S520, the public key of other nodes corresponding to each approved signature is obtained from the check node.

Specifically, the block chain node acquires the public keys of other corresponding nodes from each authorized signature fed back by the check node, and then adopts the public keys of other nodes to identify the check point identifier signed by the private key of other nodes to obtain the check point identifier; comparing the obtained check point identification with the check point identification fed back by the check node, and if the check point identification is consistent with the check point identification, indicating that the check point identification is valid; if not, the check point mark is invalid.

S530, if the checkpoint identification signed by the private key of the other node is valid through public key verification, the approved signature is determined to be valid.

Specifically, if a block chain node verifies that a check point identifier signed by a private key of a block chain link point is valid through a public key of a certain block chain node, it is determined that an approved signature corresponding to the block chain link point is valid; otherwise, determining that the authorized signature corresponding to the block link point is invalid.

And S540, if the number of the valid recognizable signatures meets the validation condition, determining the authenticity of the checkpoint identification.

Specifically, the block link points may first determine the number of nodes participating in the block link network, and then obtain an effective condition from a block in which the block link is created, or traverse forward from the current block to obtain an effective condition, and determine whether the number of valid recognizable signatures matches the relative proportion or the absolute number specified in the effective condition based on the effective condition; if so, determining that the check point identifier fed back by the check node is real; if not, the check point mark is invalid, and the block chain node can give up performing the block chain synchronization operation according to the data of the synchronization block fed back by the check node.

And S550, if the check point identification is true, verifying the data authenticity of the synchronous block according to the check point identification.

S560, if the authenticity of the data of the sync block is verified, the data of the sync block is stored.

EXAMPLE six

Fig. 6 is a schematic structural diagram of a data processing apparatus of a block chain according to a sixth embodiment of the present invention, where the apparatus may be configured in a block chain node, and may execute the data processing method of the block chain according to the first, second, and third embodiments of the present invention, and has functional modules and beneficial effects corresponding to the execution method. As shown in fig. 6, the apparatus includes:

a check block determination module 610, configured to determine at least one synchronization block for which a check point is to be created when it is determined that the set trigger condition is met;

an identifier calculating module 620, configured to calculate a checkpoint identifier of a checkpoint according to data of a synchronization block in the block chain;

an identifier transmission module 630, configured to transmit the checkpoint identifier in the blockchain network to request other blockchain link points to perform verification, and feed back an approval signature;

a recording module 640, configured to locally record the checkpoint identity and the approval signature corresponding to the sync block if the received approval signature meets the validation condition.

Illustratively, the recording module 640 may be specifically configured to:

acquiring check point identification signed by private keys of other block chain nodes from the received approved signature, and acquiring public keys of other block chain nodes;

if the checkpoint identification of the signature is verified to be valid through the public key, determining that the approved signature is valid;

if the number of valid authorized signatures meets the validation condition, the checkpoint identification and the authorized signature are recorded locally corresponding to the sync block.

For example, the identity calculation module 620 may include:

the file forming unit is used for exporting the block data of the synchronous blocks in the block chain and the local table data to form a synchronous block file;

and the identification calculation unit is used for calculating the check point identification of the check point according to the data in the synchronous block file.

Illustratively, the file forming unit may be specifically configured to:

exporting the block data of the synchronous block in the block chain and the local table data to form a synchronous block file; or

And respectively exporting the block data of the synchronous blocks in the block chain and the local table data according to the data type table to form a plurality of synchronous block files.

Illustratively, the tile data comprises a tile volume for storing the non-spent transaction output data and a tile header; the local table data is used for storing the operation function and the execution result of the intelligent contract and storing the transaction history data.

For example, the identification calculation unit may be specifically configured to:

calculating a hash value according to the data in the synchronous block file as a check point identifier; or

And respectively calculating the hash value of each synchronous block file, establishing a Meckel tree according to each hash value of the file, and taking the root of the Meckel tree as a check point identifier.

For example, the trigger condition and the validation condition are set and configured in the block chain creation block or in the deployment data of the update configuration block.

Illustratively, the check block determination module 610 may be specifically configured to:

subtracting the set offset block amount and the set detection range block amount from the local latest block height, using the obtained difference sequence number block as the starting block of the synchronization block, and using the starting block plus the set detection range block amount as the ending block of the synchronization block.

EXAMPLE seven

Fig. 7 is a schematic structural diagram of a data synchronization apparatus for a block chain according to a seventh embodiment of the present invention, where the apparatus may be configured in a block chain node, and may execute the data synchronization method for the block chain according to the fourth and fifth embodiments of the present invention, and has corresponding functional modules and beneficial effects of the execution method. As shown in fig. 7, the apparatus includes:

the communication module 710 is configured to initiate a block synchronization request to the inspection node, and receive data of the synchronization block, an inspection point identifier, and an approval signature fed back by the inspection node, where the inspection point identifier is calculated and determined by the inspection node according to the data of the synchronization block, and the approval signature is fed back to the inspection node by other nodes for verification of the inspection point identifier;

an identity verification module 720 for verifying the authenticity of the checkpoint identity based on the endorsement signature;

the data verification module 730 is configured to verify data authenticity of the synchronization block according to the checkpoint identifier if the checkpoint identifier is true;

the data storage module 740 is configured to store the data of the sync block if the authenticity of the data of the sync block is verified.

Illustratively, the identity verification module 720 is specifically configured to:

acquiring the public keys of other nodes corresponding to the approved signatures from the check nodes;

if the checkpoint identification signed by the private key of the other node is valid through public key verification, confirming that the approved signature is valid;

and if the number of the valid recognizable signatures meets the validation condition, determining the authenticity of the checkpoint identification.

Exemplary, the data of the sync block may include:

a sync block file derived from block data of sync blocks in the block chain and the local table data; or

And a plurality of synchronous block files are respectively derived from the block data of the synchronous blocks in the block chain and the local table data according to the data type table.

Illustratively, the data verification module 730 may be specifically configured to:

calculating a hash value according to the data in the synchronous block file, taking the hash value as a check point identifier, and comparing the check point identifier with the received check point identifier to verify the authenticity of the data; or

And respectively calculating file hash values of the synchronous block files, establishing a Meckel tree according to the file hash values, and comparing the root of the Meckel tree serving as a check point identifier with the received check point identifier to verify the authenticity of the data.

Example eight

Fig. 8 is a schematic structural diagram of an apparatus according to an eighth embodiment of the present invention. FIG. 8 illustrates a block diagram of an exemplary device 12 suitable for use in implementing embodiments of the present invention. The device 12 shown in fig. 8 is only an example and should not bring any limitation to the function and scope of use of the embodiments of the present invention. Device 12 is typically a computing device that assumes the functionality of a blockchain network node.

As shown in FIG. 8, device 12 is in the form of a general purpose computing device. The components of device 12 may include, but are not limited to: one or more processors or processing units 16, a system memory 28, and a bus 18 that couples various system components including the system memory 28 and the processing unit 16.

Bus 18 represents one or more of any of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, and a processor or local bus using any of a variety of bus architectures. By way of example, such architectures include, but are not limited to, Industry Standard Architecture (ISA) bus, micro-channel architecture (MAC) bus, enhanced ISA bus, Video Electronics Standards Association (VESA) local bus, and Peripheral Component Interconnect (PCI) bus.

Device 12 typically includes a variety of computer system readable media. Such media may be any available media that is accessible by device 12 and includes both volatile and nonvolatile media, removable and non-removable media.

The system memory 28 may include computer system readable media in the form of volatile memory, such as Random Access Memory (RAM)30 and/or cache memory 32. Device 12 may further include other removable/non-removable, volatile/nonvolatile computer system storage media. By way of example only, storage system 34 may be used to read from and write to non-removable, nonvolatile magnetic media (not shown in FIG. 8, and commonly referred to as a "hard drive"). Although not shown in FIG. 8, a magnetic disk drive for reading from and writing to a removable, nonvolatile magnetic disk (e.g., a "floppy disk") and an optical disk drive for reading from or writing to a removable, nonvolatile optical disk (e.g., a CD-ROM, DVD-ROM, or other optical media) may be provided. In these cases, each drive may be connected to bus 18 by one or more data media interfaces. System memory 28 may include at least one program product having a set (e.g., at least one) of program modules that are configured to carry out the functions of embodiments of the invention.

A program/utility 40 having a set (at least one) of program modules 42 may be stored, for example, in system memory 28, such program modules 42 including, but not limited to, an operating system, one or more application programs, other program modules, and program data, each of which examples or some combination thereof may comprise an implementation of a network environment. Program modules 42 generally carry out the functions and/or methodologies of the described embodiments of the invention.

Device 12 may also communicate with one or more external devices 14 (e.g., keyboard, pointing device, display 24, etc.), with one or more devices that enable a user to interact with device 12, and/or with any devices (e.g., network card, modem, etc.) that enable device 12 to communicate with one or more other computing devices. Such communication may be through an input/output (I/O) interface 22. Also, the device 12 may communicate with one or more networks (e.g., a Local Area Network (LAN), a Wide Area Network (WAN), and/or a public network, such as the Internet) via the network adapter 20. As shown, the network adapter 20 communicates with the other modules of the device 12 via the bus 18. It should be understood that although not shown in the figures, other hardware and/or software modules may be used in conjunction with device 12, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems, among others.

The processing unit 16 executes programs stored in the system memory 28 to execute various functional applications and data processing, such as data processing of the blockchain and/or data synchronization method of the blockchain provided by the embodiments of the present invention.

Example nine

The ninth embodiment of the present invention further provides a computer-readable storage medium, on which a computer program is stored, where the computer program, when executed by a processor, can implement the data processing of the blockchain and/or the data synchronization of the blockchain described in the foregoing embodiments. The computer readable storage medium may be configured on a blockchain node.

Computer storage media for embodiments of the invention may employ any combination of one or more computer-readable media. The computer readable medium may be a computer readable signal medium or a computer readable storage medium. A computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the foregoing. More specific examples (a non-exhaustive list) of the computer readable storage medium would include the following: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device.

A computer readable signal medium may include a propagated data signal with computer readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated data signal may take many forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A computer readable signal medium may also be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device.

Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.

Computer program code for carrying out operations for aspects of the present invention may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Smalltalk, C + + or the like and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer through any type of network, including a Local Area Network (LAN) or a Wide Area Network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet service provider).

It is to be noted that the foregoing is only illustrative of the preferred embodiments of the present invention and the technical principles employed. It will be understood by those skilled in the art that the present invention is not limited to the particular embodiments described herein, but is capable of various obvious changes, rearrangements and substitutions as will now become apparent to those skilled in the art without departing from the scope of the invention. Therefore, although the present invention has been described in greater detail by the above embodiments, the present invention is not limited to the above embodiments, and may include other equivalent embodiments without departing from the spirit of the present invention, and the scope of the present invention is determined by the scope of the appended claims.

Claims

1. A method for processing data of a blockchain, the method being applied to a blockchain node, the method comprising:

when the set triggering condition is determined to be met, determining at least one synchronous block to be provided with a check point; the check point is used for indicating the archiving processing of the blocks within the preset block height interval;

2. The method of claim 1, wherein recording the checkpoint identification and the endorsement signature locally corresponding to the sync block if the received endorsement signature meets the validation criteria comprises:

determining that the endorsement signature is valid if the checkpoint identification of the signature is verified to be valid by the public key;

if the number of valid authorized signatures meets the validation condition, the checkpoint identification and authorized signatures are recorded locally corresponding to the sync block.

3. The method of claim 1, wherein computing a checkpoint identification for the checkpoint from data for a sync block in a block chain comprises:

exporting the block data of the synchronous block in the block chain and the local table data to form a synchronous block file;

and calculating the check point identification of the check point according to the data in the synchronous block file.

4. The method of claim 3, wherein exporting the chunk data and the local table data of the sync chunk in the chunk chain to form a sync chunk file comprises:

And respectively exporting the block data of the synchronous blocks in the block chain and the local table data according to a data type table to form a plurality of synchronous block files.

5. The method of claim 3, wherein:

the block data comprises a block body and a block header, the block body for storing non-spent transaction output data;

the local table data is used for storing the operation function and the execution result of the intelligent contract and storing transaction history data.

6. The method of claim 4, wherein computing a checkpoint identification for the checkpoint from data in the sync block file comprises:

calculating a hash value according to the data in the synchronous block file to serve as the check point identification; or

And respectively calculating the hash value of each synchronous block file, establishing a Meckel tree according to each file hash value, and taking the root of the Meckel tree as the check point identifier.

7. The method of claim 1, wherein:

the set triggering condition and the effective condition are configured in the block chain creation block or the deployment data of the update configuration block.

8. The method of claim 1, wherein determining at least one synchronization block for which a checkpoint is to be created comprises:

9. A data synchronization method of a block chain is applied to a block chain node and comprises the following steps:

initiating a block synchronization request to a check node, and receiving data of a synchronization block fed back by the check node, a check point identifier and an approval signature, wherein the check point identifier is calculated and determined by the check node according to the data of the synchronization block, and the approval signature is fed back to the check node by other nodes for verifying the check point identifier; the check point is used for indicating the archiving processing of the blocks within the preset block height interval;

10. The method of claim 9, wherein verifying the authenticity of the checkpoint identification based on the endorsement signature comprises:

acquiring the public keys of other nodes corresponding to the approved signatures from the check node;

if the checkpoint identification signed by the private key of the other node is valid through the public key verification, determining that the approved signature is valid;

and if the number of the valid recognizable signatures meets the validation condition, determining the authenticity of the check point identification.

11. The method of claim 9, wherein the data of the sync block comprises:

a sync block file derived from block data of sync blocks in the block chain and local table data; or

12. The method of claim 11, wherein:

13. The method of claim 11, wherein verifying data authenticity of the sync block based on the checkpoint identification comprises:

14. A data processing apparatus of a block chain, configured in a block chain node, the apparatus comprising:

the checking block determining module is used for determining at least one synchronous block of a checking point to be created when the setting triggering condition is determined to be met; the check point is used for indicating the archiving processing of the blocks within the preset block height interval;

15. An apparatus for data synchronization of a blockchain, configured in a blockchain node, the apparatus comprising:

the communication module is used for initiating a block synchronization request to the inspection node and receiving data of the synchronization block fed back by the inspection node, an inspection point identifier and an approval signature, wherein the inspection point identifier is calculated and determined by the inspection node according to the data of the synchronization block, and the approval signature is fed back to the inspection node by other nodes for verification of the inspection point identifier; the check point is used for indicating the archiving processing of the blocks within the preset block height interval;

and the data storage module is used for storing the data of the synchronous block if the authenticity verification of the data of the synchronous block passes.

16. An electronic device, characterized in that the device comprises:

one or more processors;

storage means for storing one or more programs;

when executed by the one or more processors, cause the one or more processors to implement a method of data processing for a blockchain as in any of claims 1-8, or to implement a method of data synchronization for a blockchain as in any of claims 9-13.

17. A computer-readable storage medium, on which a computer program is stored which, when being executed by a processor, carries out a method for data processing of a blockchain according to any one of claims 1 to 8 or a method for data synchronization of a blockchain according to any one of claims 9 to 13.