Block chain data processing method and device, computer equipment and storage medium

Abstract

The invention relates to a block chain data processing method and device, computer equipment and a storage medium. The method comprises the following steps: receiving a to-be-consensus block sent by a main node so as to enter a consensus process of a current round; obtaining a proposal timestamp from the block; performing calculation based on candidate timestamps corresponding to legal voting information of each node collected by the slave node in a target voting stage in a previous consensus process and current local time of the slave node to obtain a verification timestamp; and under the condition that the distance between the proposal timestamp and the verification timestamp is smaller than a preset range, executing the transaction in the block to obtain an execution result. According to the embodiment of the invention, the verification accuracy of the candidate timestamps is improved.

Description

Technical Field

[0001] The present application relates to the field of blockchain technology, and in particular to a method, apparatus, computer device, storage medium and computer program product for processing blockchain data. Background Art

[0002] With the development of blockchain technology, more and more business systems are beginning to use blockchain technology. Because blockchain has the characteristics of decentralization, transparency and traceability, it provides security for transactions in blockchain. In traditional technology, the master node obtains the local time of the server as the time of block packaging and adds the time to the block, which is also called the on-chain time. On-chain time plays an important role. For example, on-chain time can trace the source and change history of data or information to ensure the authenticity and integrity of the data.

[0003] However, since blockchain is a distributed system, it supports some nodes to do evil, that is, some nodes maliciously write unreasonable time. In related technologies, the nodes verify the rationality of the time range of the chain time, but usually this time range is relatively wide and the accuracy of the proposal time cannot be guaranteed. Summary of the invention

[0004] Based on this, it is necessary to provide a blockchain data processing method, device, computer equipment, storage medium and computer program product that can improve the accuracy of proposal time in response to the above technical problems.

[0005] In a first aspect, the present application provides a method for processing blockchain data. The method comprises:

[0006] Receive the blocks to be agreed upon sent by the master node to enter the current round of consensus process;

[0007] Obtaining a proposal timestamp from the block; wherein the proposal timestamp is calculated based on the candidate timestamp corresponding to the legal voting information of each node collected by the master node in the target voting phase during the previous round of consensus, and the local time of the master node in the packaging phase of the block;

[0008] The verification timestamp is obtained by calculating based on the candidate timestamps corresponding to the legal voting information of each node collected by the slave node in the target voting phase during the previous round of consensus and the current local time of the slave node;

[0009] When the distance between the proposal timestamp and the verification timestamp is less than a preset range, executing the transaction in the block to obtain an execution result;

[0010] The corresponding voting result is obtained based on the execution result, and the local time corresponding to the voting result is obtained as the candidate timestamp corresponding to the current voting stage of the slave node, and the candidate timestamp corresponding to the current voting stage is carried in the voting information corresponding to the current voting stage.

[0011] In a second aspect, the present application also provides a method for processing blockchain data, which is applied to a master node in a blockchain system, and the method includes:

[0012] Obtain a preset number of transactions, and generate blocks to be agreed upon based on the transactions, so as to enter the current round of consensus process;

[0013] Determine the proposal timestamp of the block based on the candidate timestamps corresponding to the legal voting information of each node collected by the master node in the target voting phase during the previous round of consensus, and the local time of the master node in the block packaging phase;

[0014] The proposal timestamp is added to the block, and the block is broadcast to each slave node in the blockchain, so that the slave node calculates the verification timestamp based on the candidate timestamp corresponding to the legal voting information of each node collected by the slave node in the target voting phase of the previous round of consensus, and the current local time of the slave node; the slave node verifies the block based on the candidate timestamp and the verification timestamp.

[0015] In a third aspect, the present application also provides a blockchain data processing device, which is applied to a slave node in a blockchain system, and the device includes:

[0016] The receiving module is used to receive the blocks to be agreed upon sent by the master node, so as to enter the consensus process of the current round;

[0017] A first acquisition module is used to obtain a proposal timestamp from the block; wherein the proposal timestamp is calculated based on the candidate timestamp corresponding to the legal voting information of each node collected by the master node in the target voting phase during the previous round of consensus, and the local time of the master node in the packaging phase of the block;

[0018] A verification timestamp generation module is used to calculate the candidate timestamps corresponding to the legal voting information of each node collected by the slave node in the target voting phase during the previous round of consensus, and the current local time of the slave node to obtain the verification timestamp;

[0019] An execution module, configured to execute the transaction in the block and obtain an execution result when the distance between the proposal timestamp and the verification timestamp is less than a preset range;

[0020] A voting result generation module is used to obtain the corresponding voting result based on the execution result, and obtain the local time corresponding to the voting result as the candidate timestamp corresponding to the current voting stage of the slave node, and the candidate timestamp corresponding to the current voting stage is carried in the voting information corresponding to the current voting stage.

[0021] In one embodiment, the master node is further used for:

[0022] Based on the candidate timestamps corresponding to the legal voting information of each node collected by the master node in the target voting phase during the previous round of consensus, the master node determines the collected candidate timestamps of the master node and the collected candidate timestamps of other nodes respectively;

[0023] Based on the collected candidate timestamps of other nodes and the collected candidate timestamps of the master node, a cumulative time deviation is obtained;

[0024] Based on the accumulated time deviation and the number of other nodes, an average time deviation is obtained;

[0025] The local time of the master node during the packaging phase of the block and the average time deviation are summed to obtain a proposal timestamp.

[0026] In one embodiment, the verification timestamp generation module is further used to:

[0027] Determine the collected candidate timestamps of the slave node and the collected candidate timestamps of other nodes from the candidate timestamps corresponding to the legal voting information of each node collected by the slave node in the target voting phase during the previous round of consensus;

[0028] Obtaining a cumulative time deviation based on the collected candidate timestamps of other nodes and the collected candidate timestamps of the slave node;

[0029] Based on the accumulated deviation and the number of other nodes collected, an average time deviation is obtained;

[0030] The current local time of the slave node and the average time deviation are fused and calculated to obtain a verification timestamp.

[0031] In one embodiment, the blockchain data processing device further includes:

[0032] A first broadcast module, used to broadcast the voting information corresponding to the current voting stage to other nodes in the blockchain system, and receive the voting information corresponding to the current voting stage broadcasted by other nodes;

[0033] A first collection module, used to collect candidate timestamps carried by legal voting information corresponding to the current voting stage broadcasted by each of the other nodes;

[0034] The voting information generation module is used to obtain the voting information corresponding to the next voting stage of the slave node based on the voting results in the voting information corresponding to the current voting stage broadcasted by a preset number of other nodes.

[0035] In one embodiment, the blockchain data processing device further includes:

[0036] An entry module, used to enter the next voting stage; wherein the voting information corresponding to the next voting stage carries the candidate timestamps corresponding to the current voting stage broadcast by each of the other nodes collected by the slave node in the current voting stage;

[0037] A second broadcast module is used to broadcast the voting information corresponding to the next voting stage of the slave node to other nodes in the blockchain system, and receive the voting information corresponding to the next voting stage broadcasted by other nodes;

[0038] The second collection module is used to collect the candidate timestamps carried by the legal voting information corresponding to the next voting stage broadcast by each of the other nodes; until the candidate timestamps carried by the legal voting information corresponding to the target voting stage broadcast by other nodes are collected, the total candidate timestamps collected from the node are obtained.

[0039] In one embodiment, the execution module is further configured to:

[0040] Obtaining nodes and corresponding candidate timestamps from the additional data of the block respectively;

[0041] Compare the candidate timestamp in the additional data with the total candidate timestamps collected by the slave node during the previous round of consensus;

[0042] For candidate timestamps of the same node, when those stored in the additional data are the same as those collected from the slave nodes, and when the distance between the proposal timestamp and the verification timestamp is less than a preset range, the transaction in the block is executed.

[0043] In one embodiment, the execution module is further configured to:

[0044] Obtaining nodes and corresponding candidate timestamps from the additional data of the block respectively;

[0045] Compare the candidate timestamp in the additional data with the total candidate timestamps collected by the slave node during the previous round of consensus;

[0046] For candidate timestamps of the same node, when those stored in the additional data are the same as those collected from the slave nodes, and when the distance between the proposal timestamp and the verification timestamp is less than a preset range, the transaction in the block is executed.

[0047] In one embodiment, the execution module is further configured to:

[0048] The total candidate timestamps in the additional data are stored in a list by matching the nodes with the corresponding candidate timestamps;

[0049] Traverse the nodes in the list, and if there is a candidate timestamp corresponding to the traversed node in the total candidate timestamps collected by the slave node in the previous round of consensus, compare the candidate timestamp of the traversed node with the corresponding candidate timestamp collected by the slave node.

[0050] In one embodiment, the blockchain data processing device further includes: a verification module, wherein the verification module is used to:

[0051] Obtaining nodes and corresponding candidate timestamps from the additional data of the block respectively;

[0052] comparing the candidate timestamps in the additional data with the candidate timestamps collected from the slave nodes;

[0053] In the event that the candidate timestamp of at least one of the same nodes stored in the additional data is inconsistent with that collected from the slave node, the transaction in the block does not need to be executed, and the voting result is determined to be a negative vote.

[0054] In one embodiment, the execution module is further configured to:

[0055] Obtaining the timestamp signature of the node from the additional data of the block respectively; wherein the timestamp signature includes the signature of the proposal timestamp, block height and consensus round;

[0056] The timestamp signature corresponding to each node is verified respectively, and when all verifications are passed and the distance between the proposal timestamp and the verification timestamp is less than a preset range, the transaction in the block is executed.

[0057] In one embodiment, the execution module is further configured to:

[0058] In the event that at least one timestamp signature verification fails, there is no need to execute the transactions in the block, and the voting result is determined to be a negative vote.

[0059] In one embodiment, the apparatus further comprises:

[0060] The entry module is also used to enter the next voting stage and receive voting information corresponding to the next voting stage broadcasted by other nodes; wherein the voting information corresponding to the next voting stage carries the candidate timestamps corresponding to the current voting stage broadcasted by other nodes other than itself collected by the other nodes in the current voting stage, and the corresponding timestamp signature;

[0061] The first verification module is used to verify each of the timestamp signatures respectively; when each of the timestamp signatures is verified, it is determined that the voting information corresponding to the next voting stage broadcast by other nodes is legal voting information, and the candidate timestamps in the legal voting information are collected into a cache.

[0062] In one embodiment, the first verification module is further configured to:

[0063] Get the candidate timestamp of the voting information corresponding to the next voting phase broadcasted by other nodes;

[0064] When the distance between the received candidate timestamp and the current local time of the slave node is within a threshold range, it is determined that the voting information corresponding to the next voting stage broadcast by other nodes is legal voting information.

[0065] In one embodiment, the first verification module is further configured to:

[0066] Obtain candidate timestamps respectively from the voting information corresponding to the next voting phase broadcasted by the other nodes;

[0067] When the candidate timestamp in the voting information corresponding to the next voting stage broadcast by the other nodes exists in the slave node cache, and the candidate timestamp in the cache is equal to the candidate timestamp of the other nodes, and when all the timestamp signatures are verified, it is determined that the voting information corresponding to the next voting stage broadcast by the other nodes is legal voting information.

[0068] In one embodiment, the blockchain data processing device further includes a second verification module, wherein the second verification module is used to:

[0069] Obtain candidate timestamps respectively from the voting information corresponding to the next voting phase broadcasted by the other nodes;

[0070] If the candidate timestamp in the voting information corresponding to the next voting stage broadcasted by the other nodes exists in the slave node cache, and the candidate timestamp in the cache is not equal to the candidate timestamp of the other nodes, it is determined that the voting information corresponding to the next voting stage broadcasted by the other nodes is illegal voting information;

[0071] The illegal voting information is discarded, and the candidate timestamps of the other nodes are deleted from the node cache.

[0072] In one embodiment, the blockchain data processing device also includes a storage module, which is used to store the total candidate timestamps collected by the slave nodes in the consensus process of the current round in the additional data of the block when the block is passed by consensus in the target voting stage.

[0073] In a fourth aspect, the present application further provides a blockchain data processing device, which is applied to a master node in a blockchain system, and the method includes:

[0074] A second acquisition module is used to acquire a preset number of transactions and generate blocks to be agreed upon based on the transactions to enter the current round of consensus process;

[0075] A proposal timestamp generation module, used to determine the proposal timestamp of the block based on the candidate timestamps corresponding to the legal voting information of each node collected by the master node in the target voting phase during the previous round of consensus, and the local time of the master node in the block packaging phase;

[0076] A block generation module is used to add the proposal timestamp to the block and broadcast the block to each slave node in the blockchain, so that the slave node calculates based on the candidate timestamp corresponding to the legal voting information of each node collected by the slave node in the target voting phase of the previous round of consensus, and the current local time of the slave node to obtain a verification timestamp; the slave node verifies the block based on the candidate timestamp and the verification timestamp.

[0077] In a fifth aspect, the present application further provides a computer device, wherein the computer device comprises a memory and a processor, wherein the memory stores a computer program, and when the processor executes the computer program, the method described in any one of the embodiments of the present disclosure is implemented.

[0078] In a sixth aspect, the present application further provides a computer-readable storage medium, wherein a computer program is stored on the computer-readable storage medium, and when the computer program is executed by a processor, the method described in any one of the embodiments of the present disclosure is implemented.

[0079] In a seventh aspect, the present application further provides a computer program product, wherein the computer program product comprises a computer program, and when the computer program is executed by a processor, the method described in any one of the embodiments of the present disclosure is implemented.

[0080] The above-mentioned blockchain data processing method, device, computer equipment, storage medium and computer program product determine the proposal timestamp through the candidate timestamps corresponding to the legal voting information of each node collected by the master node in the target voting stage of the previous round of consensus, and the local time of the master node in the packaging stage of the block. Compared with the prior art that directly uses the main body time of the block packaging stage, the embodiment of the present disclosure adds the time of other nodes other than the master node, so that the determined proposal timestamp is closer to the current time of the slave node. When the slave node verifies the proposed timestamp later, it can set a preset range that is narrower than the prior art, which improves the accuracy of the candidate timestamp verification and increases the difficulty of the malicious node to do evil, making it less likely to do evil. And when the local time of the master node continues to lead or lags behind the slave node, the proposal timestamp determined by the present application will not be affected by the above phenomenon. Further, the embodiment of the present disclosure calculates the candidate timestamps corresponding to the legal voting information of each node collected by the slave node in the target voting stage of the previous round of consensus, and the current local time of the slave node to determine the verification timestamp. The timestamp verification is no longer simply done using the local time of the slave node, but is combined with the candidate timestamps collected by the slave node during the previous round of consensus. This helps to further limit the size of the preset range, improve the effectiveness of timestamp verification, and effectively filter out information sent by malicious nodes. BRIEF DESCRIPTION OF THE DRAWINGS

[0081] Figure 1 It is a schematic diagram of the block consensus process in the prior art;

[0082] Figure 2 A schematic diagram of a timestamp verification proposal in the prior art;

[0083] Figure 3 This is an application environment diagram of a method for processing blockchain data in one embodiment;

[0084] Figure 4 A schematic diagram of the structure of a block in an embodiment;

[0085] Figure 5 A schematic diagram of a new block generation process in one embodiment;

[0086] Figure 6 A flowchart of a method for processing blockchain data in one embodiment;

[0087] Figure 7 Schematic diagram of a candidate timestamp collection process in one embodiment;

[0088] Figure 8 A flowchart of a method for processing blockchain data in one embodiment;

[0089] Fig. 9 A flowchart of a method for processing blockchain data in one embodiment;

[0090] Fig.10 A flowchart of a method for processing blockchain data in one embodiment;

[0091] Fig.11 is a schematic diagram of voting information corresponding to a target voting phase in an embodiment;

[0092] Fig.12 is a schematic diagram of a collection list of candidate timestamps in one embodiment;

[0093] Fig.13 is a schematic diagram of voting information corresponding to the current voting stage in an embodiment;

[0094] Fig.14 A flowchart of a method for processing blockchain data in one embodiment;

[0095] Fig.15 A flowchart of a method for processing blockchain data in one embodiment;

[0096] Fig.16 A schematic diagram of a device for processing blockchain data in one embodiment;

[0097] Fig.17 A schematic diagram of a device for processing blockchain data in one embodiment;

[0098] Fig.18 is an internal structure diagram of a computer device in one embodiment;

[0099] Fig.19 FIG. 4 is a diagram showing the internal structure of a computer device in one embodiment. DETAILED DESCRIPTION

[0100] In order to make the purpose, technical solution and advantages of the present application more clearly understood, the present application is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application.

[0101] In order to facilitate those skilled in the art to understand the technical solution provided by the embodiments of the present disclosure, the technical environment in which the technical solution is implemented is described below.

[0102] In the blockchain system, the blockchain is a structure that connects blocks one by one. Each block has an identifier that is used to mark the height of the corresponding block in the blockchain. This identifier is called the block height. Therefore, the block height is an identifier that describes the growth process of a blockchain.

[0103] In the business scenarios of blockchain applications, the time when a block is generated, also known as the on-chain time, has important application value, such as authentication and traceability. The timestamp corresponding to the time when the block is generated is proposed by the master node, and the slave node will verify the received timestamp with the local time. Figure 1 As shown in the figure, when the master node makes a block proposal, it obtains the current time of the system and uses it as the timestamp of the block to be agreed upon. After receiving the block to be agreed upon, each slave node verifies the timestamp in the block to see if the time meets a certain threshold range. For example, refer to Figure 2 As shown in the figure, the threshold range is set to 10 minutes. For any slave node, when the difference between the proposal timestamp in the block and the current time of the slave node is greater than the threshold range, the slave node votes against it; when the difference between the proposal timestamp in the block and the current time of the slave node is less than or equal to the threshold range, the slave node votes in favor. Of course, as an example here, only the impact of the proposal timestamp on the verification result is considered. Back Figure 1 , the nodes in the blockchain broadcast the voting results to other nodes A. Other nodes A gather enough votes, determine the consensus results based on the voting results, and broadcast the consensus results again to other nodes B in the blockchain except itself. Other nodes B further gather enough votes to determine the final consensus results. If the final consensus result is a consensus success, the block will be added to the blockchain. If the final consensus result is a consensus failure, the transactions in the block will be repackaged and the consensus will be re-proposed.

[0104] However, in the above process, since the clock of each node in the blockchain system is independent, the clocks between nodes are also different with a high probability. Therefore, when the slave node verifies the proposal timestamp, the above threshold range is usually set relatively wide, which provides a lot of processing space for malicious nodes, such as some malicious nodes writing unreasonable times. In addition, the master node cannot correct the continuous processing of the leading or lagging state (less than the threshold range), resulting in low efficiency of the blockchain system.

[0105] Based on actual technical requirements similar to those described above, the present application provides a blockchain data processing method, apparatus, computer device, storage medium and computer program product.

[0106] See also Figure 3In the blockchain system shown, the blockchain system 300 refers to a system for sharing data between nodes. The blockchain system may include multiple nodes 301, and the multiple nodes 301 may be various clients or servers in the blockchain system. Each node 301 can receive transactions while performing normal work, and maintain the shared data of the blockchain system based on the received transactions. In order to ensure the intercommunication of information within the blockchain system, there may be an information connection between each node in the blockchain system, and information can be transmitted between nodes through the above information connection. For example, when any node in the blockchain system receives a transaction, the other nodes in the blockchain system obtain the transaction according to the consensus algorithm, and store the transaction as data in the shared data, so that the data stored on all nodes in the blockchain system are consistent.

[0107] Table 1

[0108] Node Name Node ID Node 1 117.114.151.174 Node 2 117.116.189.145 … … Node N 119.123.789.258

[0109] Each node in the blockchain system has a corresponding node identifier, and each node in the blockchain system can store the node identifiers of other nodes in the blockchain system, so that the generated blocks can be broadcast to other nodes in the data sharing system according to the node identifiers of other nodes. Each node can maintain a node identifier list as shown in Table 1, and store the node name and node identifier in the node identifier list accordingly. Among them, the node identifier can be an IP (Internet Protocol, a protocol for interconnecting networks) address and any other information that can be used to identify the node. Table 1 only uses the IP address as an example for illustration.

[0110] Each node in the blockchain system stores the same blockchain. The blockchain consists of multiple blocks, see Figure 4 ,The blockchain consists of multiple blocks. The genesis block includes a block header, a block body, and additional data. The block header stores the block's feature value, proposal timestamp, and others, and the block body stores transactions. Additional data is very important data. Since additional data will not be calculated in the block feature value, the data put in depends entirely on the node itself, which means that nodes are allowed to be different.

[0111] When generating each block in the blockchain, see Figure 5 When the node where the blockchain is located receives the transaction, it verifies the transaction and stores it in the memory pool after verification. It also updates the hash tree used to record the transaction. After that, it updates the update timestamp to the time when the transaction was received, tries different random numbers, and calculates the eigenvalues ​​multiple times so that the calculated eigenvalues ​​can satisfy the following formula:

[0112] SHA256(SHA256(version+prev_hash+merkle_root+ntime+nbits+x)) <TARGET

[0113] Among them, SHA256 is the eigenvalue algorithm used to calculate the eigenvalue; version (version number) is the version information of the relevant block protocol in the blockchain; prev_hash is the block header eigenvalue of the parent block of the current block; merkle_root is the eigenvalue of the transaction; ntime is the update time of the update timestamp; nbits is the current difficulty, which is a fixed value within a period of time and is determined again after exceeding the fixed time period; x is a random number; TARGET is the eigenvalue threshold, which can be determined based on nbits.

[0114] In this way, when the random number that satisfies the above formula is calculated, the information can be stored accordingly, the block header and block body can be generated, and the current block can be obtained. Subsequently, the node where the blockchain is located sends the newly generated block to other nodes in the data sharing system according to the node identification of other nodes in the data sharing system. Other nodes verify the newly generated block and add the newly generated block to the blockchain stored in them after the verification is completed.

[0115] In one embodiment, Figure 6 As shown, a method for processing blockchain data is provided, which is described by taking the method applied to a slave node in a blockchain system as an example, and includes the following steps:

[0116] Step S601, receiving the block to be consensus sent by the master node to enter the current round of consensus process.

[0117] Among them, the master node is a node with special permissions and functions in the blockchain system. The functions of the master node may be different in different blockchain systems. In an exemplary embodiment, the master node can be responsible for generating new blocks and adding them to the blockchain. At the same time, the master node can participate in the consensus process and verify the blocks generated by other nodes to ensure that they comply with the rules and consensus algorithm of the network. Optionally, the master node can be generated from the nodes of the blockchain system by voting or random selection. Correspondingly, the slave node is the node other than the master node in the blockchain system.

[0118] Among them, the block to be agreed upon may include a certain number of transactions obtained by the master node from the memory pool, and after verifying the transactions one by one, the generated blocks are packaged.

[0119] In the specific consensus process, taking the BFT (Byzantine Fault Tolerance) consensus algorithm as an example, refer to Figure 1 As shown, the master node sends the block to be agreed upon to each slave node. After receiving the block to be agreed upon, the slave node verifies the block to be agreed upon, generates voting information for the current voting stage based on the verification result, and broadcasts the voting information to other nodes (including the master node and the slave node) in the blockchain system. The slave node gathers enough voting information, generates secondary voting information, and broadcasts the secondary voting information to other nodes in the blockchain system. The slave node gathers enough votes again and determines the final consensus result based on the secondary voting information. From the master node sending the block to be agreed upon to the slave node to the determination of the final consensus result, a consensus round is realized, and the node will increase one on the basis of the consensus round maintained. In one scenario, the block to be agreed upon is a block with real transactions. When the final consensus result of the block is a consensus success, the block is added to the blockchain. And the node will increase one on the basis of the maintained block height. In another scenario, the block to be agreed upon is an empty block with no transactions. Even if the final consensus result of the empty block is a consensus success, the block will not be added to the blockchain, that is, the block height will not increase. Regardless of whether it is a block with real transactions or an empty block, after the final consensus result is obtained, the consensus round will be increased by one. In the disclosed embodiment, the consensus process of the current round corresponds to the consensus process in progress after receiving the block to be consensus sent by the master node.

[0120] Step S603, obtaining a proposal timestamp from the block; wherein the proposal timestamp is a candidate timestamp corresponding to the legal voting information of each node collected by the master node in the target voting phase during the previous round of consensus, and is calculated based on the local time of the master node in the block packaging phase.

[0121] The previous round of consensus process may include the previous round of consensus process of the current round of consensus process. For example, the current round is t, and the previous round is t-1. In a specific application scenario, if the current round of block a is 1, it means that the previous consensus block b of block a is a block with real transactions. After block b is passed by consensus and stored in the blockchain, the consensus round is set to zero. Therefore, the previous round of consensus process of block a is the consensus process of block b.

[0122] The target voting phase may include any voting phase in a round of consensus process, and may optionally include the last voting phase in a round of consensus process. For example, if there are two voting phases in a round of consensus process, the target voting phase may include the second voting phase. The voting phase may be defined as the period from the initiation of the current voting information to the initiation of the next voting information. Figure 7As shown, assuming that there are two voting stages in a round of consensus process, the current voting stage may include the node initiating the first voting information, the node receiving the first voting information of other nodes, and the node preparing the second voting information. The target voting information may include the node initiating the second voting information, the node receiving the second voting information of other nodes, and the node preparing the consensus result based on the second voting information.

[0123] The legal voting information may include voting information that meets preset requirements or voting information that meets preset verification rules. Specifically, the master node receives voting information from each node during the target voting phase, and verifies each voting information according to preset rules. If the verification passes, the voting information is determined to be legal voting information. Figure 7 As shown, for node A, the corresponding nodes of each legal voting information collected in the target voting stage include node A, node B, and node D. For node B, the corresponding nodes of each legal voting information collected in the target voting stage include node A, node B, and node C. It can be understood that the corresponding nodes of the legal voting information collected by the node in the target voting stage must include the node itself. For example, in the above example, node A receives the voting information of node A, and node B receives the voting information of node B. In the disclosed embodiment, the candidate timestamp of the node may include the candidate timestamp corresponding to any voting stage in a round of consensus process, and may also include the candidate timestamp corresponding to a specific voting stage in a round of consensus process.

[0124] In a specific implementation, the master node can perform mathematical operations based on the candidate timestamps of the nodes corresponding to the legal voting information collected by the master node in the target voting phase of the previous round of consensus, and the local time in the block packaging phase. In an exemplary embodiment, the average value of the candidate timestamps of the nodes corresponding to the legal voting information collected by the master node in the target voting phase of the previous round of consensus can be calculated, and a deviation is calculated based on the average value and the candidate timestamp of the master node itself, and the deviation is added to the local time of the master node in the block packaging phase. In another exemplary embodiment, the collected candidate timestamps of the master node and the collected candidate timestamps of other nodes are determined respectively. Based on the candidate timestamps of the collected other nodes and the candidate timestamps of the collected master node, the cumulative time deviation is obtained. Based on the cumulative deviation and the number of the other nodes, the average time deviation is obtained. The local time of the master node and the average time deviation are summed to obtain the proposal timestamp. It should be noted that the present disclosure is based on the candidate timestamps of the nodes corresponding to the legal voting information of each node collected by the master node in the target voting phase of the previous round of consensus, and the method of calculating the proposal timestamp by the local time of the master node in the block packaging phase is not limited to the above examples. For example, preset weights are added to the candidate timestamps of specific nodes. Technical personnel in the relevant field may make other changes under the inspiration of the technical essence of this application, but as long as the functions and effects achieved are the same or similar to those of this application, they should be covered within the scope of protection of this application.

[0125] Step S605, calculating based on the candidate timestamps corresponding to the legal voting information of each node collected by the slave node in the target voting phase during the previous round of consensus, and the current local time of the slave node, to obtain a verification timestamp.

[0126] Specifically, the slave node can be obtained by performing mathematical operations based on the candidate timestamp of the node corresponding to the legal voting information collected by the slave node in the target voting stage of the previous round of consensus, and the current local time of the slave node. In an exemplary embodiment, the average value of the candidate timestamps of the node corresponding to the legal voting information collected by the slave node in the target voting stage of the previous round of consensus can be calculated, and a deviation is calculated based on the average value and the candidate timestamp of the slave node itself, and the deviation is added to the current local time of the slave node. In another exemplary embodiment, the collected candidate timestamps of the slave node and the collected candidate timestamps of other nodes are determined respectively. Based on the candidate timestamps of the collected other nodes and the candidate timestamps of the collected slave nodes, the cumulative time deviation is obtained. Based on the cumulative deviation and the number of the other nodes, the average time deviation is obtained. The local time of the master node and the average time deviation are summed to obtain the proposal timestamp. It should be noted that the present disclosure is based on the candidate timestamp of the node corresponding to the legal voting information of each node collected from the slave node in the target voting phase of the previous round of consensus process, and the method of calculating the proposal timestamp from the local time of the slave node in the block packaging phase is not limited to the above examples. For example, a preset weight is added to the candidate timestamp of a specific node. Technical personnel in the relevant field may make other changes under the inspiration of the technical essence of this application, but as long as the functions and effects achieved are the same or similar to those of this application, they should be covered within the scope of protection of this application.

[0127] Step S607, when the distance between the proposal timestamp and the verification timestamp is less than a preset range, execute the transaction in the block to obtain an execution result.

[0128] In the embodiment of the present disclosure, when the distance between the proposal timestamp and the verification timestamp is less than a preset range, the transaction in the block is executed according to the content of the blockchain contract to obtain the execution result. In an exemplary embodiment, a hash operation can also be performed on the execution result to obtain a characteristic value of the execution result, and the characteristic value is verified to be consistent with the characteristic value of the execution result in the block sent by the master node.

[0129] Step S609, obtaining the corresponding voting result based on the execution result, and obtaining the local time corresponding to the voting result as the candidate timestamp corresponding to the current voting stage of the slave node, and the candidate timestamp corresponding to the current voting stage is carried in the voting information corresponding to the current voting stage.

[0130] The voting result may include an affirmative vote or a negative vote (disapproval vote). In an exemplary embodiment, if the execution result verification is passed, the corresponding voting result is an affirmative vote. In an exemplary embodiment, if the execution result verification is not passed, the corresponding voting result is a negative vote. After obtaining the voting result, the local time is obtained from the node as the candidate timestamp of the current voting stage. The candidate timestamp is also used for the voting information corresponding to each voting stage. Figure 7 As shown, for example, in the current voting phase, slave node C sends its voting result and candidate timestamp as one-time voting information to master node A, slave node B, slave node C, and slave node D. In the target voting phase, slave node B sends the candidate timestamps of master node A, slave node B, and slave node C that it has collected, where the candidate timestamp of slave node C can be sent to master node A, master node B, and master node C as one-time voting information.

[0131] The above-mentioned method for processing blockchain data determines the proposal timestamp through the candidate timestamps corresponding to the legal voting information of each node collected by the master node in the target voting stage during the last round of consensus, and the local time of the master node in the packaging stage of the block. Compared with the prior art that directly uses the main body time of the block packaging stage, the embodiment of the present disclosure adds the time of other nodes other than the master node, so that the determined proposal timestamp is closer to the current time of the slave node. When the slave node verifies the proposed timestamp later, it can set a preset range that is narrower than the prior art, which improves the accuracy of the candidate timestamp verification and the difficulty of the malicious node to do evil, making it less likely to do evil. And when the local time of the master node continues to lead or lag behind the slave node, the proposal timestamp determined by the present application will not be affected by the above phenomenon. Further, the embodiment of the present disclosure determines the verification timestamp by calculating the candidate timestamps corresponding to the legal voting information of each node collected by the slave node in the target voting stage during the last round of consensus, and the current local time of the slave node. The timestamp verification is no longer simply done using the local time of the slave node, but is combined with the candidate timestamps collected by the slave node during the previous round of consensus. This helps to further limit the size of the preset range, improve the effectiveness of timestamp verification, and effectively filter out information sent by malicious nodes.

[0132] In one embodiment, reference Figure 8 As shown, the proposal timestamp is calculated based on the timestamp corresponding to the legal voting information of each node collected by the master node in the target voting phase during the previous round of consensus, and the local time of the master node in the block packaging phase, including:

[0133] Step S801, the proposal timestamp is based on the candidate timestamps corresponding to the legal voting information of each node collected by the master node in the target voting phase during the previous round of consensus. The master node determines the collected candidate timestamps of the master node and the collected candidate timestamps of other nodes respectively.

[0134] The target voting phase may include any voting phase in a round of consensus process, and may optionally be the last voting phase in a round of consensus process. Figure 7 As shown, the nodes collected by the master node A in the target voting phase include node A, node B and node D, and the corresponding candidate timestamps are tA, tB, and tD, respectively. From the above candidate timestamps tA, tB, and tD, it is easy to determine the candidate timestamp tA of the master node A and the candidate timestamps tB and tD of other nodes. Among them, tA, tB, and tD can come from the candidate timestamps generated or collected in the previous voting phase.

[0135] In the disclosed embodiment, the candidate timestamps corresponding to the legal voting information of the node include: after receiving the voting information sent by other nodes, the node will perform some preset verification on the voting information, and if the verification passes, the voting information is determined to be legal.

[0136] Step S803, obtaining a cumulative time deviation based on the collected candidate timestamps of other nodes and the collected candidate timestamps of the master node.

[0137] Specifically, the candidate timestamps of other nodes collected are accumulated, for example: tB+tD. The sum of the accumulated processing is subtracted from the candidate timestamp of the master node, for example: (tB+tD-tA) In an exemplary embodiment, in order to more accurately measure the cumulative time deviation, a coefficient is added before the candidate timestamp of the master node, where the coefficient can be taken from the number of other nodes. For example, the cumulative time deviation is: (tB+tD-2tA), where 2 represents the number of tB and tD.

[0138] Step S805: obtaining an average time deviation based on the accumulated time deviation and the number of other nodes.

[0139] Specifically, the accumulated time deviation may be divided by the number of other nodes to obtain the average time deviation, for example: (tB+tD-2tA) / 2.

[0140] Step S807, summing up the local time of the master node during the packaging phase of the block and the average time deviation to obtain a proposal timestamp.

[0141] For example: the local time of the master node is expressed as TA. Combined with the above example, the proposal timestamp is expressed as PTA = TA + (tB + tD - 2tA) / 2. It should be noted that the expression of the proposal timestamp here is only used as an example. In the specific implementation process, the type, number and coefficient of the node can be changed, and this disclosure does not limit this.

[0142] In a specific embodiment, the candidate timestamp of the master node is tA = 2023-07-07 10:10:10; the candidate timestamps of other nodes are tB = 2023-07-07 10:10:11, tD = 2023-07-0710:10:15; the local time of the master node is TA = 2023-07-07 10:10:20. The final fill timestamp calculated in the above manner is PTA = 2023-07-07 10:10:23.

[0143] The above-mentioned blockchain data processing method calculates the deviation between the proposal timestamp of other nodes in the previous round of consensus and the proposal timestamp of the master node, and adds the deviation to the local time of the master node in the packaging stage of the block, which helps to shorten the distance between the proposal timestamp and the local time of other slave nodes, thereby improving the accuracy of the proposal timestamp verification.

[0144] In one embodiment, reference Fig. 9 As shown, the candidate timestamps corresponding to the legal voting information of each node collected by the slave node in the target voting phase during the previous round of consensus and the current local time of the slave node are calculated to obtain the verification timestamp, including:

[0145] Step S901, from the candidate timestamps corresponding to the legal voting information of each node collected by the slave node in the target voting phase during the previous round of consensus, determine the collected candidate timestamps of the slave node and the collected candidate timestamps of other nodes.

[0146] In the embodiments of the present disclosure, the concepts of the target voting stage and the legal voting information have been described in detail in the above embodiments and will not be repeated here. Figure 7 As shown, the nodes collected from the slave node B in the target voting phase include node A, node B and node C, and the corresponding candidate timestamps are tA, tB, and tC, respectively. From the above candidate timestamps tA, tB, and tC, it is relatively easy to determine the candidate timestamp tB of the slave node B, and the candidate timestamps tA and tC of other nodes. Among them, tA, tB, and tC can come from the candidate timestamps generated or collected in the previous voting phase.

[0147] Step S903: Obtain a cumulative time deviation based on the collected candidate timestamps of other nodes and the collected candidate timestamps of the slave node.

[0148] Specifically, the candidate timestamps of other nodes collected are accumulated, for example: tA+tC. The sum of the accumulated processing is subtracted from the candidate timestamp of the master node, for example: (tA+tC-tB) In an exemplary embodiment, in order to more accurately measure the cumulative time deviation, a coefficient is added before the candidate timestamp of the master node, where the coefficient can be taken from the number of other nodes. For example, the cumulative time deviation is: (tA+tC-2tB), where 2 represents the number of tA and tC.

[0149] Step S905: obtaining an average time deviation based on the accumulated deviation and the number of other nodes collected.

[0150] Specifically, the accumulated time deviation may be divided by the number of other nodes to obtain the average time deviation, for example: (tA+tC-2tB) / 2.

[0151] Step S907, performing a fusion calculation on the current local time of the slave node and the average time deviation to obtain a verification timestamp.

[0152] For example, the current local time of node B is expressed as TB. Combined with the above example, the proposed timestamp is expressed as PTA = TB + (tA + tC - 2tB) / 2. It should be noted that the expression for verifying the timestamp here is only used as an example. In the specific implementation process, the type, number and coefficient of the nodes can be changed, and this disclosure does not limit this.

[0153] The above-mentioned method for processing blockchain data calculates the deviation between the proposal timestamp of other nodes in the previous round of consensus and the proposal timestamp of the slave node, and adds the deviation to the current local time of the slave node, which helps to shorten the distance between the verification timestamp and the local time of other nodes in the blockchain, thereby improving the accuracy of the proposal timestamp verification.

[0154] In one embodiment, reference Fig.10 As shown, the local time corresponding to the voting result is obtained as the candidate timestamp corresponding to the current voting stage of the slave node, including;

[0155] Step S1001, broadcast the voting information corresponding to the current voting stage to other nodes in the blockchain system, and receive the voting information corresponding to the current voting stage broadcasted by other nodes from the node.

[0156] Step S1003: Collect candidate timestamps carried by legal voting information corresponding to the current voting stage broadcast by each of the other nodes.

[0157] In an exemplary embodiment, the slave node continuously receives voting information corresponding to the current voting stage broadcast by other nodes, and verifies the received voting information to collect legal voting information corresponding to the current voting stage broadcast by each of the other nodes until the number of other nodes received meets a preset number.

[0158] In an exemplary embodiment, the voting information corresponding to the next voting stage can be referenced Fig.11 As shown, the voting information collects a preset number of other nodes and corresponding timestamps and timestamp signatures. In this example, the voting information corresponding to the next voting stage carries 3 nodes and corresponding timestamps, where the voting content may include the identification information of the block, and the signature of the voting content may include the characteristic value obtained by hashing the identification information.

[0159] Step S1005, based on the legal voting information corresponding to the current voting stage broadcasted by a preset number of other nodes, the voting information corresponding to the next voting stage of the target node is obtained.

[0160] In an exemplary embodiment, reference Figure 7 As shown, the voting information corresponding to the next voting stage of the slave node is broadcast to other nodes in the blockchain system. For example, the voting information broadcast by node A includes the candidate timestamps of nodes A, B, and C, and the voting information broadcast by node D includes the candidate timestamps of nodes B, C, and D.

[0161] In one embodiment, after obtaining the voting information corresponding to the next voting phase of the target node, the method further includes:

[0162] Entering the next voting stage; wherein the voting information corresponding to the next voting stage carries the candidate timestamp in the legal voting information corresponding to the current voting stage broadcasted by each of the other nodes collected by the slave node in the current voting stage;

[0163] Broadcasting the voting information corresponding to the next voting stage of the slave node to other nodes in the blockchain system, and receiving the voting information corresponding to the next voting stage broadcasted by other nodes;

[0164] Collect the candidate timestamps carried by the legal voting information corresponding to the next voting stage broadcast by each of the other nodes; until the candidate timestamps carried by the legal voting information corresponding to the target voting stage broadcast by other nodes are collected, the total candidate timestamps collected by the slave node are obtained.

[0165] Specifically, the voting information corresponding to the next voting stage broadcasted by other nodes is received, and the candidate timestamps carried by the legal voting information corresponding to the next voting stage broadcasted by each of the other nodes are collected. For example, node A carries the candidate timestamps of nodes A, B, and C in the voting information corresponding to the next voting stage, and broadcasts it to other nodes in the blockchain; node D carries the candidate timestamps of nodes B, C, and D in the voting information corresponding to the next voting stage, and broadcasts it to other nodes in the blockchain. And so on, until the candidate timestamps carried by the legal voting information corresponding to the target voting stage broadcasted by other nodes are collected, the total candidate timestamps collected from the nodes are obtained. For example: refer to Fig.12 As shown, the total candidate timestamps collected by node A are as follows Fig.12 As shown in the list, it includes the candidate timestamps of nodes A, B, and C collected in the voting information corresponding to the current voting stage, as well as the candidate timestamps of nodes A, B, and D collected in the next voting stage (or target voting stage) and the candidate timestamps of each node carried by nodes A, B, and D respectively.

[0166] The present disclosure carries the candidate timestamp in the voting information of each voting stage. As the voting information is broadcast, the node has the opportunity to collect the candidate timestamps of as many nodes as possible in the blockchain node, thereby providing data support for the verification of the candidate timestamp, the verification timestamp and the candidate timestamp of each node.

[0167] In one embodiment, the master node is further used to add the total candidate timestamps collected in the previous round of consensus process to the additional data of the block, and when the distance between the proposal timestamp and the verification timestamp is less than a preset range, execute the transaction in the block, including:

[0168] From the additional data of the block, nodes and corresponding candidate timestamps are obtained respectively.

[0169] The candidate timestamps in the additional data are compared with the total candidate timestamps collected from the slave nodes.

[0170] For candidate timestamps of the same node, when those stored in the additional data are the same as those collected from the slave nodes, and when the distance between the proposal timestamp and the verification timestamp is less than a preset range, the transaction in the block is executed.

[0171] Specifically, when the master node packages the block to be agreed upon, it adds the total candidate timestamps collected by the master node in the previous round of consensus process to the additional data of the block. The slave node receives the block to be agreed upon, and obtains the node and the corresponding candidate timestamp from the additional data of the block. In an exemplary embodiment, the additional data contains the candidate timestamp t1 of node B, and the total candidate timestamps collected from the slave node also contain the candidate timestamp t2 of node B. The candidate timestamp t1 and the candidate timestamp t2 can be compared. If the two are the same, the comparison of the candidate timestamp of the next node is continued. In an exemplary embodiment, the additional data contains the candidate timestamp of node B, and the total candidate timestamps collected from the slave node do not contain the candidate timestamp of node B. In this case, there is no need to verify the candidate timestamp of node B, and the verification of the next node is continued.

[0172] In the specific implementation process, when the comparison results of the candidate timestamps of all the same nodes are consistent, and the distance between the proposal timestamp and the verification timestamp is less than the preset range, the transaction in the block is executed. For example, the nodes A, C, G, E, K stored in the attachment data and the candidate timestamps A, C, G, E, F stored in the slave node, where nodes A, C, G are nodes stored by both, respectively compare the nodes A, C, G stored in the attachment data with the nodes A, C, G stored in the slave node to see if they are the same. If all are the same, the transaction in the block is executed.

[0173] The above embodiment can verify the legitimacy of the block and prevent the node from doing evil by verifying the candidate timestamp in the additional data in the block and the candidate timestamp stored in the slave node.

[0174] In one embodiment, comparing the candidate timestamp in the additional data with the total candidate timestamps collected by the slave node during the previous round of consensus includes:

[0175] The total candidate timestamps in the additional data are stored in a list by matching the nodes with the corresponding candidate timestamps.

[0176] Traverse the nodes in the list, and if there is a candidate timestamp corresponding to the traversed node in the total candidate timestamps collected by the slave node in the previous round of consensus, compare the candidate timestamp of the traversed node with the corresponding candidate timestamp collected by the slave node.

[0177] The list may include a map data structure or a data data structure in a key-value manner, for example, the nodes are stored in the key of the list, and the corresponding candidate timestamps are stored in the value of the list. In an exemplary embodiment, each node in the list, such as the C1 node, is traversed. When the C1 node also exists in the total candidate timestamps collected from the node, the candidate timestamp corresponding to the traversed C1 node and the candidate timestamp corresponding to the C1 node stored from the node are compared. When the two candidate timestamps are the same, the traversal continues to the next node, such as C2. When the C2 node does not exist in the total candidate timestamps collected from the node, the traversal continues to the next node, such as C3. And so on, until the last node in the list is traversed.

[0178] In the above embodiment, the total candidate timestamps in the additional data are stored in a list by matching nodes and corresponding candidate timestamps, each node in the list is traversed in turn, and the candidate timestamp corresponding to the node is compared with the candidate timestamps collected from the node in the previous round of consensus process. In this way, the verification of each candidate timestamp in the additional data can be realized more efficiently.

[0179] In one embodiment, when the distance between the proposal timestamp and the verification timestamp is less than a preset range, executing the transaction in the block, the method further includes:

[0180] From the additional data of the block, nodes and corresponding candidate timestamps are obtained respectively.

[0181] The candidate timestamps in the additional data are compared with the candidate timestamps collected from the slave nodes.

[0182] In the event that the candidate timestamp of at least one of the same nodes stored in the additional data is inconsistent with that collected from the slave node, the transaction in the block does not need to be executed, and the voting result is determined to be a negative vote.

[0183] Specifically, a block to be agreed upon is received from a node, and the node and the corresponding candidate timestamp are obtained from the additional data of the block. In an exemplary embodiment, the additional data contains a candidate timestamp t1 of node E, and the total candidate timestamps collected from the node also contain a candidate timestamp t2 of node E. Candidate timestamp t1 and candidate timestamp t2 can be compared. If the two are different, there is no need to execute the transaction in the block, and the voting result is determined to be a negative vote. In an exemplary embodiment, the additional data contains a candidate timestamp of node F, and there is no candidate timestamp of node F in the total candidate timestamps collected from the node. There is no need to verify the candidate timestamp of node F, and the verification of the next node can be continued.

[0184] In the specific implementation process, when the value of at least one node in the candidate timestamps of all the same nodes in the additional data is different from the value stored in the slave node, there is no need to execute the transaction in the block, and the voting result is determined to be a negative vote. For example, the nodes A, C, G, E, K stored in the attached data and the candidate timestamps A, C, G, E, F stored in the slave node, where nodes A, C, G are nodes stored by both, respectively compare the nodes A, C, G stored in the additional data with the nodes A, C, G stored in the slave node to see if they are the same. If at least one timestamp node is different, there is no need to execute the transaction in the block, and the voting result is determined to be a negative vote.

[0185] In the specific implementation process, the total candidate timestamps in the additional data can also be stored in a list by matching the nodes and the corresponding candidate timestamps, and each node in the list, such as the C1 node, is traversed in turn. When the C1 node also exists in the total candidate timestamps collected from the node, the candidate timestamp corresponding to the traversed C1 node and the candidate timestamp corresponding to the C1 node stored from the node are compared. When the two candidate timestamps are the same, continue to traverse the next node, such as C2. When there is no C2 node in the total candidate timestamps collected from the node, continue to traverse the next node, such as C3; when the candidate timestamp of node C3 stored from the node is different from the candidate timestamp of the traversed node C3. There is no need to execute the transactions in the block, and the voting result is determined to be a negative vote.

[0186] The above embodiment verifies the candidate timestamp in the additional data of the block and the candidate timestamp stored by the slave node, and casts a negative vote when the candidate timestamp of at least one of the same nodes stored in the additional data is inconsistent with that stored by the slave node. The embodiment of the present disclosure can verify the legitimacy of the block and prevent nodes from doing evil.

[0187] In one embodiment, the master node is further used to add the total candidate timestamps collected in the previous round of consensus process and the timestamp signature corresponding to each candidate timestamp to the additional data of the block, and execute the transaction in the block when the distance between the proposal timestamp and the verification timestamp is less than a preset range, including:

[0188] The timestamp signature of the node is obtained respectively from the additional data of the block; wherein the timestamp signature includes the signature of the proposal timestamp, block height and consensus round.

[0189] The timestamp signature corresponding to each node is verified respectively, and when all verifications are passed and the distance between the proposal timestamp and the verification timestamp is less than a preset range, the transaction in the block is executed.

[0190] Specifically, refer to Fig.12 As shown, when the master node stores the total candidate timestamps collected in the previous round of consensus process into the attachment data, it also stores the timestamp signature corresponding to each candidate timestamp in the attachment data. The timestamp signature includes the node's signature on the proposal timestamp, block height, and consensus round. In an exemplary embodiment, refer to Fig.13 As shown, in the current round of consensus process, the timing of generating a timestamp signature may include: after obtaining the local time corresponding to the voting result as the candidate timestamp corresponding to the current voting stage of the slave node, the proposal timestamp and block height in the current round of consensus process, the signature of the consensus round, together with the candidate timestamp, are carried in the voting information corresponding to the current voting stage.

[0191] In an exemplary embodiment, a node can perform a hash operation on the three pieces of information, namely, the proposal timestamp, block height, and consensus round, and encrypt them using its own private key to obtain a first eigenvalue as a timestamp signature. The timestamp signature corresponding to each node is verified separately. In an exemplary embodiment, a slave node can perform a hash operation on the three pieces of information, namely, the proposal timestamp, block height, and consensus round, and encrypt them using a public key to obtain a second eigenvalue. If the first eigenvalue is consistent with the second eigenvalue, the timestamp signature is verified.

[0192] After the timestamp signatures of all nodes in the additional data are verified, and the distance between the proposal timestamp and the verification timestamp is less than a preset range, the transactions in the block are executed.

[0193] In the above embodiment, the timestamp signature is added to the additional data of the block, so that after receiving the block to be agreed upon from the node, the timestamp signature in the block is verified. Only when all the timestamp signatures are verified, can the transaction in the block be executed. Compared with the prior art, the embodiment of the present disclosure adds the verification of the timestamp signature of each node, which helps to strengthen the verification mechanism of the legitimacy of the block. Furthermore, in the implementation of the present disclosure, the timestamp signature is a signature for the proposal timestamp, block height and consensus round, rather than just a signature for the proposal timestamp, so as to prevent the node from using the signature of the proposal timestamp to do evil. The signatures of the three types of information, namely the proposal timestamp, block height and consensus round, increase the cost of evil for the evil node, which can effectively prevent the node from doing evil.

[0194] In one embodiment, after respectively verifying each of the timestamp signatures, the method further includes:

[0195] In the event that at least one timestamp signature verification fails, there is no need to execute the transactions in the block, and the voting result is determined to be a negative vote.

[0196] Specifically, the node can perform a hash operation on the three pieces of information, namely the proposal timestamp, block height, and consensus round, and encrypt them using its own private key to obtain a first eigenvalue as a timestamp signature. The timestamp signature corresponding to each node is verified separately. In an exemplary embodiment, the slave node can perform a hash operation on the three pieces of information, namely the proposal timestamp, block height, and consensus round, and encrypt them using a public key to obtain a second eigenvalue. If the first eigenvalue is inconsistent with the second eigenvalue, the timestamp signature verification fails.

[0197] In the specific implementation process, the timestamp signature and the timestamp verification in the above embodiment can be used in combination to strengthen the legitimacy verification of the block. The nodes and the corresponding candidate timestamps and timestamp signatures are matched and stored in the list, and each node in the list is traversed in turn, such as the C1 node. When the C1 node also exists in the total candidate timestamps collected from the node, the candidate timestamp corresponding to the traversed C1 node and the candidate timestamp corresponding to the C1 node stored from the node are compared. When the two candidate timestamps are the same; continue to verify the timestamp signature of the C1 node, and when the timestamp signature verification passes, continue to traverse the next node, such as C2. When there is no C2 node in the total candidate timestamps collected from the node, continue to verify the timestamp signature of the C2 node, and when the timestamp signature verification passes, continue to traverse the next node, such as C3. When the timestamp signature verification of node C3 fails. There is no need to execute the transaction in the block, and the voting result is determined to be a negative vote. It should be noted that the order of the timestamp signature verification in the embodiment of the present disclosure and the timestamp verification in the above embodiment can be unlimited, and the timestamp signature can also be verified first, and then the timestamp can be verified. Furthermore, regardless of whether there is a node in the attached data among the slave nodes, the timestamp signature of the node can be verified.

[0198] The disclosed embodiment adds the verification of the timestamp signature of each node, which helps to strengthen the verification mechanism of the legitimacy of the block and can effectively prevent nodes from doing evil.

[0199] In one embodiment, after obtaining the corresponding voting result based on the execution result, and obtaining the local time corresponding to the voting result as the candidate timestamp corresponding to the current voting stage of the slave node, the method further includes:

[0200] Step S1401, enter the next voting stage, and receive voting information corresponding to the next voting stage broadcast by other nodes; wherein the voting information corresponding to the next voting stage carries the candidate timestamps corresponding to the current voting stage broadcast by other nodes other than itself collected by the other nodes in the current voting stage, and the corresponding timestamp signature.

[0201] Specifically, entering the next voting stage, e.g. Figure 7 In the next voting phase, the next voting phase is also the target voting phase. In the next voting phase, the voting information of the nodes will still be aggregated, that is, the voting information corresponding to the next voting phase broadcasted by other nodes will be received. Fig.11 As shown, the voting information corresponding to the next voting stage includes the candidate timestamps corresponding to the current voting stage broadcast by other nodes except the node itself collected by the node in the current voting stage and the corresponding timestamp signatures.

[0202] In the disclosed embodiment, the timestamp signature may include a signature of the proposal timestamp, block height, and consensus round, for example, Figure 7 As shown, the voting information corresponding to the next voting stage sent by node A is received from node C, and the voting information carries the candidate timestamps and timestamp signatures of node A, node B and node C respectively.

[0203] Step S1403: verify each of the timestamp signatures respectively.

[0204] Specifically, for example, in the above example, the timestamp signatures of node A, node B, and node C are verified respectively. Taking the timestamp signature of node A as an example, the slave node can perform a hash operation on the three information of proposal timestamp, block height, and consensus round, and encrypt it using the public key to obtain a characteristic value. The characteristic value is compared with the timestamp signature of node A. If the two are consistent, the timestamp signature of node A is verified. In an exemplary embodiment, if the two verifications are inconsistent, the timestamp signature of node A fails to be verified. Among them, the timestamp signature of node A can include performing a hash operation on the three information of proposal timestamp, block height, and consensus round, and encrypting it using the private key of the original node.

[0205] Step S1405, when all the timestamp signatures are verified, it is determined that the voting information corresponding to the next voting stage broadcast by other nodes is legal voting information, and the candidate timestamps in the legal voting information are collected into a cache.

[0206] In the embodiment of the present disclosure, when all the timestamp signatures are verified, the voting information corresponding to the next voting stage broadcast by other nodes is determined to be legal voting information. In the above example, the voting information corresponding to the next voting stage sent by node A received from node C carries the candidate timestamps and timestamp signatures of node A, node B and node C respectively. Among them, when all the timestamp signatures are verified, it means that the timestamp signature of node A is verified, the timestamp signature of node B is verified, and the timestamp signature of node C is verified.

[0207] In the above embodiment, the timestamp signature in the voting information corresponding to the next voting stage is verified, and when all the timestamp signatures are verified, the voting information is determined to be legal voting information. Compared with the prior art, the embodiment of the present disclosure adds the verification of the timestamp signature of each node, which helps to strengthen the verification mechanism of the timestamp signature in the voting information corresponding to the next voting stage. Furthermore, in the implementation of the present disclosure, the timestamp signature is a signature for the proposal timestamp, block height and consensus round, rather than just a signature for the proposal timestamp, so as to prevent the node from using the signature of the proposal timestamp to do evil in the next voting stage. The signatures of the three types of information, namely the proposal timestamp, block height and consensus round, increase the cost of evil for the malicious node, which can effectively prevent the node from doing evil.

[0208] In one embodiment, when all the timestamp signatures are verified, determining that the voting information corresponding to the next voting phase broadcasted by other nodes is legal voting information includes:

[0209] Get the candidate timestamp of the voting information corresponding to the next voting phase broadcasted by other nodes;

[0210] When the distance between the received candidate timestamp and the current local time of the slave node is within the threshold range and each of the timestamp signatures is verified, it is determined that the voting information corresponding to the next voting stage broadcast by other nodes is legal voting information.

[0211] Specifically, receive the candidate timestamp of the voting information corresponding to the next voting phase broadcasted by other nodes, where other nodes can refer to Figure 7 As shown, the voting information corresponding to the next voting stage sent by node A is received from node C, and the voting information corresponding to the next voting stage sent by node B is also received from node C, and the voting information corresponding to the next voting stage sent by node C is received. For node C, other nodes may include node A, node B and node C. Taking node A as an example, when node C receives the voting information corresponding to the next voting stage sent by node A, the candidate timestamp of node A is obtained from the voting information corresponding to the next voting stage, and the candidate timestamp of node A is verified with the current local time of the slave node. In one example, if the distance between the two is within a preset range, the voting information corresponding to the next voting stage sent by node A is legal voting information. In another example, if the distance between the two is outside the preset range, the voting information corresponding to the next voting stage sent by node A is illegal voting information, the voting information is discarded, and node A and the corresponding candidate timestamp in the local cache are deleted.

[0212] In the specific implementation process, the verification content of this embodiment can be used together with the verification of the candidate timestamp in the above embodiment, wherein the present application does not restrict the verification order of the verification of this embodiment and the verification of the candidate timestamp in the above embodiment. That is, the verification content of this embodiment can be verified first and then the verification of the candidate time in the above embodiment can be verified, or the verification of the candidate time in the above embodiment can be verified first and then the verification content of this embodiment can be verified.

[0213] In one embodiment, when all the timestamp signatures are verified, determining that the voting information corresponding to the next voting phase broadcasted by other nodes is legal voting information includes:

[0214] The candidate timestamps are obtained respectively from the voting information corresponding to the next voting stage broadcasted by the other nodes.

[0215] When the candidate timestamp in the voting information corresponding to the next voting stage broadcast by the other nodes exists in the slave node cache, and the candidate timestamp in the cache is equal to the candidate timestamp of the other nodes, and when all the timestamp signatures are verified, it is determined that the voting information corresponding to the next voting stage broadcast by the other nodes is legal voting information.

[0216] Specifically, for example, the voting information corresponding to the next voting stage sent by node A is received from node C, and the voting information carries the candidate timestamps of node A, node B and node C respectively. Prior to this, the voting information corresponding to the next voting stage sent by node B is received from node C, and the voting information carries the candidate timestamps of node A, node B and node C respectively. And the voting information corresponding to the next voting stage sent by node B is verified to be legal voting information and stored in the cache of node C. Node C verifies each candidate timestamp in the voting information corresponding to the next voting stage sent by node A, for example, whether the candidate timestamp of node A sent by node A is consistent with the candidate timestamp of node A sent by node B; whether the candidate timestamp of node B sent by node A is consistent with the candidate timestamp of node B sent by node B; whether the candidate timestamp of node C sent by node A is consistent with the candidate timestamp of node C sent by node B.

[0217] Furthermore, if the cache does not store the node carried in the voting information corresponding to the next voting stage sent by node A, the carried node may not be verified.

[0218] In an exemplary embodiment, when all node timestamps are verified, the voting information corresponding to the next voting phase broadcast by other nodes is determined to be legal voting information, and the candidate timestamps of each node in the legal voting information are stored in a cache.

[0219] In the above embodiment, the timestamp in the voting information corresponding to the next voting stage is verified, and when all timestamps are verified, the voting information is determined to be legal voting information. Compared with the prior art, the embodiment of the present disclosure adds the verification of the timestamp of each node, which helps to strengthen the verification mechanism of the timestamp in the voting information corresponding to the next voting stage.

[0220] In one embodiment, after verifying each of the timestamp signatures respectively, the method further comprises:

[0221] The candidate timestamps are obtained respectively from the voting information corresponding to the next voting stage broadcasted by the other nodes.

[0222] When the candidate timestamp in the voting information corresponding to the next voting stage broadcast by the other nodes exists in the slave node cache, and the candidate timestamp in the cache is not equal to the candidate timestamp of the other nodes, it is determined that the voting information corresponding to the next voting stage broadcast by the other nodes is illegal voting information.

[0223] The illegal voting information is discarded, and the candidate timestamps of the other nodes are deleted from the node cache.

[0224] Specifically, for example, the voting information corresponding to the next voting stage sent by node A is received from node C, and the voting information carries the candidate timestamps of node A, node B and node C respectively. Prior to this, the voting information corresponding to the next voting stage sent by node B is received from node C, and the voting information carries the candidate timestamps of node A, node B and node C respectively. And the voting information corresponding to the next voting stage sent by node B is verified to be legal voting information and stored in the cache of node C. Node C verifies each candidate timestamp in the voting information corresponding to the next voting stage sent by node A, for example, whether the candidate timestamp of node A sent by node A is consistent with the candidate timestamp of node A sent by node B; whether the candidate timestamp of node B sent by node A is consistent with the candidate timestamp of node B sent by node B; whether the candidate timestamp of node C sent by node A is consistent with the candidate timestamp of node C sent by node B.

[0225] In an exemplary embodiment, if the candidate timestamp of at least one of the above-mentioned nodes A, B and C is inconsistent with the voting information corresponding to the next voting stage sent by node A and the cache from node C, it is determined that the voting information corresponding to the next voting stage sent by node A is illegal voting information, the voting information is deleted, and the corresponding node and candidate timestamp in the cache from node C are deleted.

[0226] In the above embodiment, the timestamp in the voting information corresponding to the next voting stage is verified, and if at least one timestamp verification fails, the voting information is determined to be illegal. Compared with the prior art, the embodiment of the present disclosure adds the verification of the timestamp of each node, which helps to strengthen the verification mechanism of the timestamp in the voting information corresponding to the next voting stage.

[0227] In one embodiment, the corresponding voting result is obtained in the execution result, and the local time corresponding to the voting result is obtained as the candidate timestamp corresponding to the current voting stage of the slave node, and then the following is further included:

[0228] When the block is passed by consensus in the target voting phase, the total candidate timestamps collected from the slave nodes are stored in the additional data of the block.

[0229] In the disclosed embodiment, for example, in the target voting phase, voting information of M nodes is received, and voting information of N nodes is passed by consensus. For example, if N / M meets the preset ratio requirement, it is determined that the block is successfully agreed upon. For example, if N / M meets the preset ratio requirement, it is determined that the block is successfully agreed upon. In the case that the block is successfully agreed upon, the total candidate timestamps collected from the nodes are stored in the additional data of the block.

[0230] When the block is passed by consensus in the target voting phase, the total candidate timestamps collected from the slave nodes are stored in the additional data of the block. For example, when a node loses power or crashes, memory data may be lost, and the additional data stored in the block helps to store data safely.

[0231] In one embodiment, reference Fig.14 As shown, a method for processing blockchain data is applied to a master node in a blockchain system, and the method includes:

[0232] Step S1401, obtaining a preset number of transactions, and generating blocks to be agreed upon based on the transactions to enter the current round of consensus process.

[0233] Among them, the master node is a node with special permissions and functions in the blockchain system. In different blockchain systems, the functions of the master node may be different. In an exemplary embodiment, the master node may be responsible for generating new blocks and adding them to the blockchain. At the same time, the master node can participate in the consensus process, verify the blocks generated by other nodes, and ensure that they comply with the rules and consensus algorithm of the network. Optionally, the master node can be generated from the nodes of the blockchain system by voting or random selection. Correspondingly, the slave node is a node other than the master node in the blockchain system. Among them, the block to be agreed upon may include the master node obtaining a certain number of transactions from the memory pool, verifying the transactions one by one, and packaging the generated blocks.

[0234] Step S1403, based on the candidate timestamps corresponding to the legal voting information of each node collected by the master node in the target voting phase during the previous round of consensus, and the local time of the master node in the block packaging phase, determine the proposal timestamp of the block.

[0235] The previous round of consensus process may include the previous round of consensus process of the current round of consensus process. For example, the current round is t, and the previous round is t-1. In a specific application scenario, if the current round of block a is 1, it means that the previous consensus block b of block a is a block with real transactions. After block b is passed by consensus and stored in the blockchain, the consensus round is set to zero. Therefore, the previous round of consensus process of block a is the consensus process of block b.

[0236] The target voting phase may include any voting phase in a round of consensus process, and may optionally include the last voting phase in a round of consensus process. For example, if there are two voting phases in a round of consensus process, the target voting phase may include the second voting phase. The voting phase may be defined as the period from the initiation of the current voting information to the initiation of the next voting information. Figure 7 As shown, assuming that there are two voting stages in a round of consensus process, the current voting stage may include the node initiating the first voting information, the node receiving the first voting information of other nodes, and the node preparing the second voting information. The target voting information may include the node initiating the second voting information, the node receiving the second voting information of other nodes, and the node preparing the consensus result based on the second voting information.

[0237] The legal voting information may include voting information that meets preset requirements or voting information that meets preset verification rules. Specifically, the master node receives voting information from each node during the target voting phase, and verifies each voting information according to preset rules. If the verification passes, the voting information is determined to be legal voting information. Figure 7As shown, for node A, the corresponding nodes of each legal voting information collected in the target voting stage include node A, node B, and node D. For node B, the corresponding nodes of each legal voting information collected in the target voting stage include node A, node B, and node C. It can be understood that the corresponding nodes of the legal voting information collected by the node in the target voting stage must include the node itself. For example, in the above example, node A receives the voting information of node A, and node B receives the voting information of node B. In the disclosed embodiment, the candidate timestamp of the node may include the candidate timestamp corresponding to any voting stage in a round of consensus process, and may also include the candidate timestamp corresponding to a specific voting stage in a round of consensus process.

[0238] In a specific implementation, the master node can perform mathematical operations based on the candidate timestamps of the nodes corresponding to the legal voting information collected by the master node in the target voting phase of the previous round of consensus, and the local time in the block packaging phase. In an exemplary embodiment, the average value of the candidate timestamps of the nodes corresponding to the legal voting information collected by the master node in the target voting phase of the previous round of consensus can be calculated, and a deviation is calculated based on the average value and the candidate timestamp of the master node itself, and the deviation is added to the local time of the master node in the block packaging phase. In another exemplary embodiment, the collected candidate timestamps of the master node and the collected candidate timestamps of other nodes are determined respectively. Based on the candidate timestamps of the collected other nodes and the candidate timestamps of the collected master node, the cumulative time deviation is obtained. Based on the cumulative deviation and the number of the other nodes, the average time deviation is obtained. The local time of the master node and the average time deviation are summed to obtain the proposal timestamp. It should be noted that the present disclosure is based on the candidate timestamps of the nodes corresponding to the legal voting information of each node collected by the master node in the target voting phase of the previous round of consensus, and the method of calculating the proposal timestamp by the local time of the master node in the block packaging phase is not limited to the above examples. For example, preset weights are added to the candidate timestamps of specific nodes. Technical personnel in the relevant field may make other changes under the inspiration of the technical essence of this application, but as long as the functions and effects achieved are the same or similar to those of this application, they should be covered within the scope of protection of this application.

[0239] Step S1405, adding the proposal timestamp to the block, and broadcasting the block to each slave node in the blockchain, so that the slave node calculates based on the candidate timestamp corresponding to the legal voting information of each node collected by the slave node in the target voting phase of the previous round of consensus, and the current local time of the slave node to obtain a verification timestamp; the slave node verifies the block based on the candidate timestamp and the verification timestamp.

[0240] Specifically, the slave node can be obtained by performing mathematical operations based on the candidate timestamp of the node corresponding to the legal voting information collected by the slave node in the target voting stage of the previous round of consensus, and the current local time of the slave node. In an exemplary embodiment, the average value of the candidate timestamps of the node corresponding to the legal voting information collected by the slave node in the target voting stage of the previous round of consensus can be calculated, and a deviation is calculated based on the average value and the candidate timestamp of the slave node itself, and the deviation is added to the current local time of the slave node. In another exemplary embodiment, the collected candidate timestamps of the slave node and the collected candidate timestamps of other nodes are determined respectively. Based on the candidate timestamps of the collected other nodes and the candidate timestamps of the collected slave nodes, the cumulative time deviation is obtained. Based on the cumulative deviation and the number of the other nodes, the average time deviation is obtained. The local time of the master node and the average time deviation are summed to obtain the proposal timestamp. It should be noted that the present disclosure is based on the candidate timestamp of the node corresponding to the legal voting information of each node collected from the slave node in the target voting phase of the previous round of consensus process, and the method of calculating the proposal timestamp from the local time of the slave node in the block packaging phase is not limited to the above examples. For example, a preset weight is added to the candidate timestamp of a specific node. Technical personnel in the relevant field may make other changes under the inspiration of the technical essence of this application, but as long as the functions and effects achieved are the same or similar to those of this application, they should be covered within the scope of protection of this application.

[0241] The above-mentioned method for processing blockchain data determines the proposal timestamp through the candidate timestamps corresponding to the legal voting information of each node collected by the master node in the target voting stage during the last round of consensus, and the local time of the master node in the packaging stage of the block. Compared with the prior art that directly uses the main body time of the block packaging stage, the embodiment of the present disclosure adds the time of other nodes except the master node, so that the determined proposal timestamp is closer to the current time of the slave node, so that when the slave node verifies the proposed timestamp, it can set a preset range that is narrower than the prior art, which improves the accuracy of candidate timestamp verification and increases the difficulty of malicious nodes to do evil, making it less likely to do evil. And when the local time of the master node continues to lead or lags behind the slave node, the proposal timestamp determined by the present application will not be affected by the above phenomenon. Further, the embodiment of the present disclosure calculates the candidate timestamps corresponding to the legal voting information of each node collected by the slave node in the target voting stage during the last round of consensus, and the current local time of the slave node to determine the verification timestamp. The timestamp verification is no longer simply done using the local time of the slave node, but is combined with the candidate timestamps collected by the slave node during the previous round of consensus. This helps to further limit the size of the preset range, improve the effectiveness of timestamp verification, and effectively filter out information sent by malicious nodes.

[0242] The method of the present application can be applied to the application scenario of transfer transactions. Among them, the transfer transaction may include the sender, the receiver, and the transfer amount, etc. In the prior art, in the block to be consensus received, the proposal timestamp in the block is verified, wherein the proposal timestamp is the local time of the master node in the packaging stage of the block. In the method of the present application, the proposal timestamp is a candidate timestamp corresponding to the legal voting information of each node collected by the master node in the target voting stage of the previous round of consensus, and is calculated based on the local time of the master node in the packaging stage of the block, taking into account the candidate timestamp of the slave node, so that the verification of the proposal timestamp is more reasonable.

[0243] refer to Fig.14 As shown, the slave node receives the block to be agreed upon from the master node and performs the following processing:

[0244] The timestamp verification phase specifically includes: receiving the block sent by the master node, and obtaining the additional data in the block. The total candidate timestamps in the additional data are stored in a list by matching the nodes and the corresponding candidate timestamps. The nodes in the list are traversed, and when the candidate timestamp corresponding to the traversed node exists in the total candidate timestamps collected by the slave node in the previous round of consensus, the candidate timestamp of the traversed node is compared with the corresponding candidate timestamp collected by the slave node. Among them, the list may include a map data structure or a data data structure in a key-value manner, for example, the node is stored in the key of the list, and the corresponding candidate timestamp is stored in the value of the list. In an exemplary embodiment, each node in the list, such as the C1 node, is traversed, and when the C1 node also exists in the total candidate timestamps collected by the slave node, the candidate timestamp corresponding to the traversed C1 node and the candidate timestamp corresponding to the C1 node stored by the slave node are compared. If the two candidate timestamps are the same, continue to traverse the next node, such as C2. If the C2 node does not exist in the total candidate timestamps collected by the slave node, continue to traverse the next node, such as C3. And so on, until the last node in the list is traversed. In one scenario, for the candidate timestamps of the same node, when those stored in the additional data and those collected from the slave nodes are the same, and when the distance between the proposal timestamp and the verification timestamp is less than a preset range, the transaction in the block is executed. In another scenario, when at least one candidate timestamp of the same node stored in the additional data and those collected from the slave nodes are inconsistent, there is no need to execute the transaction in the block, and the voting result is determined to be a negative vote.

[0245] The verification phase of the timestamp signature, specifically, refer to Fig.12 As shown, when the master node stores the total candidate timestamps collected in the previous round of consensus process into the attachment data, it also stores the timestamp signature corresponding to each candidate timestamp in the attachment data. The timestamp signature includes the node's signature on the proposal timestamp, block height, and consensus round. In an exemplary embodiment, refer to Fig.13As shown, in the consensus process of the current round, the timing of generating a timestamp signature may include: after obtaining the local time corresponding to the voting result as the candidate timestamp corresponding to the current voting stage of the slave node, the proposal timestamp and block height and consensus round signature in the consensus process of the current round are carried in the voting information corresponding to the current voting stage together with the candidate timestamp. In an exemplary embodiment, the node can perform a hash operation through the three information of the proposal timestamp, block height and consensus round, encrypt it with its own private key, and obtain a first eigenvalue as the timestamp signature. The timestamp signature corresponding to each node is verified respectively. In an exemplary embodiment, the slave node can perform a hash operation through the three information of the proposal timestamp, block height and consensus round, encrypt it with the public key, and obtain a second eigenvalue. If the first eigenvalue is consistent with the second eigenvalue, the timestamp signature is verified. In an exemplary embodiment, the slave node can perform a hash operation through the three information of the proposal timestamp, block height and consensus round, encrypt it with the public key, and obtain a second eigenvalue. If the first eigenvalue is inconsistent with the second eigenvalue, the timestamp signature is verified.

[0246] In the specific implementation process, the timestamp signature and the timestamp verification in the above embodiment can be used in combination to strengthen the legitimacy verification of the block. The nodes and the corresponding candidate timestamps and timestamp signatures are matched and stored in the list, and each node in the list is traversed in turn, such as the C1 node. When the C1 node also exists in the total candidate timestamps collected from the node, the candidate timestamp corresponding to the traversed C1 node and the candidate timestamp corresponding to the C1 node stored from the node are compared. When the two candidate timestamps are the same; continue to verify the timestamp signature of the C1 node, and when the timestamp signature verification passes, continue to traverse the next node, such as C2. When there is no C2 node in the total candidate timestamps collected from the node, continue to verify the timestamp signature of the C2 node, and when the timestamp signature verification passes, continue to traverse the next node, such as C3. When the timestamp signature verification of node C3 fails. There is no need to execute the transaction in the block, and the voting result is determined to be a negative vote. It should be noted that the order of the timestamp signature verification in the embodiment of the present disclosure and the timestamp verification in the above embodiment can be unlimited, and the timestamp signature can also be verified first, and then the timestamp can be verified. Furthermore, regardless of whether there is a node in the attached data among the slave nodes, the timestamp signature of the node can be verified.

[0247] In the comparison phase of the proposal timestamp and the verification timestamp, the proposal timestamp is obtained from the block; wherein the proposal timestamp is calculated based on the candidate timestamp corresponding to the legal voting information of each node collected by the master node in the target voting phase of the previous round of consensus, and the local time of the master node in the block packaging phase. In an exemplary embodiment, the collected candidate timestamps of the master node and the collected candidate timestamps of other nodes are determined respectively. Based on the collected candidate timestamps of other nodes and the collected candidate timestamps of the master node, the cumulative time deviation is obtained. Based on the cumulative deviation and the number of other nodes, the average time deviation is obtained. The local time of the master node and the average time deviation are summed to obtain the proposal timestamp. The slave node can be obtained by performing mathematical operations based on the candidate timestamps of the nodes corresponding to the legal voting information collected by the slave node in the target voting phase of the previous round of consensus, and the current local time of the slave node. In an exemplary embodiment, the collected candidate timestamps of the slave nodes and the collected candidate timestamps of other nodes are determined respectively. Based on the candidate timestamps of the other nodes collected and the candidate timestamps of the slave nodes collected, a cumulative time deviation is obtained. Based on the cumulative deviation and the number of the other nodes, an average time deviation is obtained. The local time of the master node and the average time deviation are summed to obtain a proposal timestamp.

[0248] In the stage of generating voting results and voting information for the next stage, when the distance between the proposal timestamp and the verification timestamp is less than a preset range, the transactions in the block are executed to obtain the execution results. Based on the execution results, the corresponding voting results are obtained, and the local time corresponding to the voting results is obtained as the candidate timestamp corresponding to the current voting stage of the slave node, and the candidate timestamp corresponding to the current voting stage is carried in the voting information corresponding to the current voting stage. Among them, the voting results may include affirmative votes or negative votes (disapproval votes). In an exemplary embodiment, when the execution result verification is passed, the corresponding voting result is an affirmative vote. In an exemplary embodiment, when the execution result verification is not passed, the corresponding voting result is a negative vote. After obtaining the voting results, the local time is obtained from the node as the candidate timestamp for the current voting stage.

[0249] refer to Fig.15 As shown in the figure, after receiving the voting information corresponding to the target voting stage from the node, the following stages of processing are performed:

[0250] The target voting phase is the timestamp verification phase of the receiving node. Specifically, e.g. Figure 7In the next voting phase, the next voting phase is also the target voting phase. In the next voting phase, the voting information of the nodes will still be aggregated, that is, the voting information corresponding to the next voting phase broadcasted by other nodes will be received. Fig.11 As shown, the voting information corresponding to the next voting stage includes the candidate timestamps corresponding to the current voting stage broadcast by other nodes other than the node itself collected by the node in the current voting stage and the corresponding timestamp signature. In the embodiment of the present disclosure, the timestamp signature may include the signature of the proposal timestamp, block height and consensus round, for example, refer to Figure 7 As shown, the voting information corresponding to the next voting stage sent by node A received from node C carries the candidate timestamps and timestamp signatures of node A, node B and node C respectively. Specifically, for example, in the above example, the timestamp signatures of node A, node B and node C are verified respectively. Taking the timestamp signature of node A as an example, the slave node can perform a hash operation on the three information of proposal timestamp, block height and consensus round, and encrypt it using the public key to obtain the characteristic value. The characteristic value is compared with the timestamp signature of node A. If the two are consistent, the timestamp signature of node A is verified. In an exemplary embodiment, if the two are inconsistent, the timestamp signature of node A is not verified. Among them, the timestamp signature of node A can include performing a hash operation on the three information of proposal timestamp, block height and consensus round, and encrypting it using the private key of the original node. When each of the timestamp signatures is verified, it is determined that the voting information corresponding to the next voting stage broadcast by other nodes is legal voting information, and the candidate timestamps in the legal voting information are collected into the cache.

[0251] In the verification phase of the candidate timestamp, the candidate timestamps of the voting information corresponding to the next voting phase broadcast by other nodes are received. Other nodes can refer to Figure 7As shown, the voting information corresponding to the next voting stage sent by node A is received from node C, and the voting information corresponding to the next voting stage sent by node B is also received from node C, and the voting information corresponding to the next voting stage sent by node C is received. For node C, other nodes may include node A, node B and node C. Taking node A as an example, when node C receives the voting information corresponding to the next voting stage sent by node A, the candidate timestamp of node A is obtained from the voting information corresponding to the next voting stage, and the candidate timestamp of node A is verified with the current local time of the slave node. In one example, if the distance between the two is within a preset range, the voting information corresponding to the next voting stage sent by node A is legal voting information. In another example, if the distance between the two is outside the preset range, the voting information corresponding to the next voting stage sent by node A is illegal voting information, the voting information is discarded, and node A and the corresponding candidate timestamp in the local cache are deleted.

[0252] During the storage stage of the candidate timestamps of each node, when the block is passed by consensus during the target voting stage, the total candidate timestamps collected from the nodes are stored in the additional data of the block. In the disclosed embodiment, for example, in the target voting stage, voting information from M nodes is received, of which voting information from N nodes is passed by consensus. For example: if N / M meets the preset ratio requirement, it is determined that the block is successfully reached by consensus. For example: if N / M meets the preset ratio requirement, it is determined that the block is successfully reached by consensus. When the block is successfully reached by consensus, the total candidate timestamps collected from the nodes are stored in the additional data of the block.

[0253] It should be understood that, although the various steps in the flowcharts involved in the above-mentioned embodiments are displayed in sequence according to the indication of the arrows, these steps are not necessarily executed in sequence according to the order indicated by the arrows. Unless there is a clear explanation in this article, the execution of these steps does not have a strict order restriction, and these steps can be executed in other orders. Moreover, at least a part of the steps in the flowcharts involved in the above-mentioned embodiments can include multiple steps or multiple stages, and these steps or stages are not necessarily executed at the same time, but can be executed at different times, and the execution order of these steps or stages is not necessarily to be carried out in sequence, but can be executed in turn or alternately with other steps or at least a part of the steps or stages in other steps.

[0254] Based on the same inventive concept, the embodiment of the present application also provides a blockchain data processing device for implementing the blockchain data processing method involved above. The implementation scheme for solving the problem provided by the device is similar to the implementation scheme recorded in the above method, so the specific limitations in the one or more blockchain data processing device embodiments provided below can refer to the limitations of the blockchain data processing method above, and will not be repeated here.

[0255] In one embodiment, Fig.16 As shown, a blockchain data processing device is applied to a slave node in a blockchain system, and the device 1600 includes:

[0256] The receiving module 1601 is used to receive the block to be consensus sent by the master node to enter the consensus process of the current round;

[0257] The first acquisition module 1603 is used to obtain a proposal timestamp from the block; wherein the proposal timestamp is calculated based on the candidate timestamp corresponding to the legal voting information of each node collected by the master node in the target voting phase during the previous round of consensus, and the local time of the master node in the packaging phase of the block;

[0258] The verification timestamp generation module 1605 is used to calculate the candidate timestamps corresponding to the legal voting information of each node collected by the slave node in the target voting phase during the previous round of consensus, and the current local time of the slave node to obtain the verification timestamp;

[0259] An execution module 1607 is used to execute the transaction in the block and obtain an execution result when the distance between the proposal timestamp and the verification timestamp is less than a preset range;

[0260] The voting result generation module 1609 is used to obtain the corresponding voting result based on the execution result, and obtain the local time corresponding to the voting result as the candidate timestamp corresponding to the current voting stage of the slave node, and the candidate timestamp corresponding to the current voting stage is carried in the voting information corresponding to the current voting stage.

[0261] In one embodiment, the master node is further used for:

[0262] Based on the candidate timestamps corresponding to the legal voting information of each node collected by the master node in the target voting phase during the previous round of consensus, the master node determines the collected candidate timestamps of the master node and the collected candidate timestamps of other nodes respectively;

[0263] Based on the collected candidate timestamps of other nodes and the collected candidate timestamps of the master node, a cumulative time deviation is obtained;

[0264] Based on the accumulated time deviation and the number of other nodes, an average time deviation is obtained;

[0265] The local time of the master node during the packaging phase of the block and the average time deviation are summed to obtain a proposal timestamp.

[0266] In one embodiment, the verification timestamp generation module is further used to:

[0267] Determine the collected candidate timestamps of the slave node and the collected candidate timestamps of other nodes from the candidate timestamps corresponding to the legal voting information of each node collected by the slave node in the target voting phase during the previous round of consensus;

[0268] Obtaining a cumulative time deviation based on the collected candidate timestamps of other nodes and the collected candidate timestamps of the slave node;

[0269] Based on the accumulated deviation and the number of other nodes collected, an average time deviation is obtained;

[0270] The current local time of the slave node and the average time deviation are fused and calculated to obtain a verification timestamp.

[0271] In one embodiment, the blockchain data processing device further includes:

[0272] A first broadcast module, used to broadcast the voting information corresponding to the current voting stage to other nodes in the blockchain system, and receive the voting information corresponding to the current voting stage broadcasted by other nodes;

[0273] A first collection module, used to collect candidate timestamps carried by legal voting information corresponding to the current voting stage broadcasted by each of the other nodes;

[0274] The voting information generation module is used to obtain the voting information corresponding to the next voting stage of the slave node based on the voting results in the voting information corresponding to the current voting stage broadcasted by a preset number of other nodes.

[0275] In one embodiment, the blockchain data processing device further includes:

[0276] An entry module, used to enter the next voting stage; wherein the voting information corresponding to the next voting stage carries the candidate timestamps corresponding to the current voting stage broadcast by each of the other nodes collected by the slave node in the current voting stage;

[0277] A second broadcast module is used to broadcast the voting information corresponding to the next voting stage of the slave node to other nodes in the blockchain system, and receive the voting information corresponding to the next voting stage broadcasted by other nodes;

[0278] The second collection module is used to collect the candidate timestamps carried by the legal voting information corresponding to the next voting stage broadcast by each of the other nodes; until the candidate timestamps carried by the legal voting information corresponding to the target voting stage broadcast by other nodes are collected, the total candidate timestamps collected from the node are obtained.

[0279] In one embodiment, the execution module is further configured to:

[0280] Obtaining nodes and corresponding candidate timestamps from the additional data of the block respectively;

[0281] Compare the candidate timestamp in the additional data with the total candidate timestamps collected by the slave node during the previous round of consensus;

[0282] For candidate timestamps of the same node, when those stored in the additional data are the same as those collected from the slave nodes, and when the distance between the proposal timestamp and the verification timestamp is less than a preset range, the transaction in the block is executed.

[0283] In one embodiment, the execution module is further configured to:

[0284] Obtaining nodes and corresponding candidate timestamps from the additional data of the block respectively;

[0285] Compare the candidate timestamp in the additional data with the total candidate timestamps collected by the slave node during the previous round of consensus;

[0286] For candidate timestamps of the same node, when those stored in the additional data are the same as those collected from the slave nodes, and when the distance between the proposal timestamp and the verification timestamp is less than a preset range, the transaction in the block is executed.

[0287] In one embodiment, the execution module is further configured to:

[0288] The total candidate timestamps in the additional data are stored in a list by matching the nodes with the corresponding candidate timestamps;

[0289] Traverse the nodes in the list, and if there is a candidate timestamp corresponding to the traversed node in the total candidate timestamps collected by the slave node in the previous round of consensus, compare the candidate timestamp of the traversed node with the corresponding candidate timestamp collected by the slave node.

[0290] In one embodiment, the blockchain data processing device further includes: a verification module, wherein the verification module is used to:

[0291] Obtaining nodes and corresponding candidate timestamps from the additional data of the block respectively;

[0292] comparing the candidate timestamps in the additional data with the candidate timestamps collected from the slave nodes;

[0293] In the event that the candidate timestamp of at least one of the same nodes stored in the additional data is inconsistent with that collected from the slave node, the transaction in the block does not need to be executed, and the voting result is determined to be a negative vote.

[0294] In one embodiment, the execution module is further configured to:

[0295] Obtaining the timestamp signature of the node from the additional data of the block respectively; wherein the timestamp signature includes the signature of the proposal timestamp, block height and consensus round;

[0296] The timestamp signature corresponding to each node is verified respectively, and when all verifications are passed and the distance between the proposal timestamp and the verification timestamp is less than a preset range, the transaction in the block is executed.

[0297] In one embodiment, the execution module is further configured to:

[0298] In the event that at least one timestamp signature verification fails, there is no need to execute the transactions in the block, and the voting result is determined to be a negative vote.

[0299] In one embodiment, the apparatus further comprises:

[0300] The entry module is also used to enter the next voting stage and receive voting information corresponding to the next voting stage broadcasted by other nodes; wherein the voting information corresponding to the next voting stage carries the candidate timestamps corresponding to the current voting stage broadcasted by other nodes other than itself collected by the other nodes in the current voting stage, and the corresponding timestamp signature;

[0301] The first verification module is used to verify each of the timestamp signatures respectively; when each of the timestamp signatures is verified, it is determined that the voting information corresponding to the next voting stage broadcast by other nodes is legal voting information, and the candidate timestamps in the legal voting information are collected into a cache.

[0302] In one embodiment, the first verification module is further configured to:

[0303] Get the candidate timestamp of the voting information corresponding to the next voting phase broadcasted by other nodes;

[0304] When the distance between the received candidate timestamp and the current local time of the slave node is within a threshold range, it is determined that the voting information corresponding to the next voting stage broadcast by other nodes is legal voting information.

[0305] In one embodiment, the first verification module is further configured to:

[0306] Obtain candidate timestamps respectively from the voting information corresponding to the next voting phase broadcasted by the other nodes;

[0307] When the candidate timestamp in the voting information corresponding to the next voting stage broadcast by the other nodes exists in the slave node cache, and the candidate timestamp in the cache is equal to the candidate timestamp of the other nodes, and when all the timestamp signatures are verified, it is determined that the voting information corresponding to the next voting stage broadcast by the other nodes is legal voting information.

[0308] In one embodiment, the blockchain data processing device further includes a second verification module, wherein the second verification module is used to:

[0309] Obtain candidate timestamps respectively from the voting information corresponding to the next voting phase broadcasted by the other nodes;

[0310] If the candidate timestamp in the voting information corresponding to the next voting stage broadcasted by the other nodes exists in the slave node cache, and the candidate timestamp in the cache is not equal to the candidate timestamp of the other nodes, it is determined that the voting information corresponding to the next voting stage broadcasted by the other nodes is illegal voting information;

[0311] The illegal voting information is discarded, and the candidate timestamps of the other nodes are deleted from the node cache.

[0312] In one embodiment, the blockchain data processing device also includes a storage module, which is used to store the total candidate timestamps collected by the slave nodes in the consensus process of the current round in the additional data of the block when the block is passed by consensus in the target voting stage.

[0313] In one embodiment, Fig.17 As shown, a blockchain data processing device is applied to a slave node in a blockchain system, and the device 1700 includes:

[0314] The second acquisition module 1701 is used to acquire a preset number of transactions and generate blocks to be agreed upon based on the transactions to enter the current round of consensus process;

[0315] The proposal timestamp generation module 1703 is used to determine the proposal timestamp of the block based on the candidate timestamps corresponding to the legal voting information of each node collected by the master node in the target voting phase during the previous round of consensus, and the local time of the master node in the block packaging phase;

[0316] The block generation module 1705 is used to add the proposal timestamp to the block and broadcast the block to each slave node in the blockchain, so that the slave node calculates the verification timestamp based on the candidate timestamp corresponding to the legal voting information of each node collected by the slave node in the target voting phase of the previous round of consensus and the current local time of the slave node; the slave node verifies the block based on the candidate timestamp and the verification timestamp.

[0317] Each module in the above-mentioned blockchain data processing device can be implemented in whole or in part by software, hardware, or a combination thereof. Each of the above-mentioned modules can be embedded in or independent of the processor in the computer device in the form of hardware, or can be stored in the memory in the computer device in the form of software, so that the processor can call and execute the operations corresponding to each of the above modules.

[0318] In one embodiment, a computer device is provided. The computer device may be a server, and its internal structure diagram may be as follows: Fig.18 As shown. The computer device includes a processor, a memory, an input / output interface (Input / Output, referred to as I / O) and a communication interface. Among them, the processor, the memory and the input / output interface are connected through a system bus, and the communication interface is connected to the system bus through the input / output interface. Among them, the processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program and a database. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The database of the computer device is used to store the processing data of blockchain data. The input / output interface of the computer device is used to exchange information between the processor and an external device. The communication interface of the computer device is used to communicate with an external terminal through a network connection. When the computer program is executed by the processor, a method for processing blockchain data is implemented.

[0319] In one embodiment, a computer device is provided. The computer device may be a terminal, and its internal structure diagram may be as follows: Fig.19As shown. The computer device includes a processor, a memory, an input / output interface, a communication interface, a display unit and an input device. Among them, the processor, the memory and the input / output interface are connected through a system bus, and the communication interface, the display unit and the input device are connected to the system bus through the input / output interface. Among them, the processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system and a computer program. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The input / output interface of the computer device is used to exchange information between the processor and the external device. The communication interface of the computer device is used to communicate with an external terminal in a wired or wireless manner, and the wireless method can be implemented through WIFI, a mobile cellular network, NFC (near field communication) or other technologies. When the computer program is executed by the processor, a method for processing blockchain data is implemented. The display unit of the computer device is used to form a visually visible image, and can be a display screen, a projection device or a virtual reality imaging device. The display screen can be a liquid crystal display screen or an electronic ink display screen. The input device of the computer device can be a touch layer covered on the display screen, or a button, trackball or touchpad set on the computer device casing, or an external keyboard, touchpad or mouse, etc.

[0320] Those skilled in the art will understand that Fig.19 The structure shown in the figure is only a block diagram of a part of the structure related to the solution of the present application, and does not constitute a limitation on the computer device to which the solution of the present application is applied. The specific computer device may include more or fewer components than those shown in the figure, or combine certain components, or have a different arrangement of components.

[0321] Those skilled in the art can understand that all or part of the processes in the above-mentioned embodiment methods can be completed by instructing the relevant hardware through a computer program, and the computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to the memory, database or other medium used in the embodiments provided in the present application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetoresistive random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. As an illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM). The database involved in each embodiment provided in this application may include at least one of a relational database and a non-relational database. Non-relational databases may include distributed databases based on blockchains, etc., but are not limited to this. The processor involved in each embodiment provided in this application may be a general-purpose processor, a central processing unit, a graphics processor, a digital signal processor, a programmable logic device, a data processing logic device based on quantum computing, etc., but are not limited to this.

[0322] The technical features of the above embodiments may be combined arbitrarily. To make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0323] The above-described embodiments only express several implementation methods of the present application, and the descriptions thereof are relatively specific and detailed, but they cannot be understood as limiting the scope of the present application. It should be pointed out that, for a person of ordinary skill in the art, several variations and improvements can be made without departing from the concept of the present application, and these all belong to the protection scope of the present application. Therefore, the protection scope of the present application shall be subject to the attached claims.

Claims

1. A method for processing blockchain data, characterized in that: Applied to a slave node in a blockchain system, the method comprises: Receive the blocks to be agreed upon sent by the master node to enter the current round of consensus process; Obtaining a proposal timestamp from the block; wherein the proposal timestamp is calculated based on the candidate timestamp corresponding to the legal voting information of each node collected by the master node in the target voting phase during the previous round of consensus, and the local time of the master node in the packaging phase of the block; The verification timestamp is obtained by calculating based on the candidate timestamps corresponding to the legal voting information of each node collected by the slave node in the target voting phase during the previous round of consensus and the current local time of the slave node; When the distance between the proposal timestamp and the verification timestamp is less than a preset range, executing the transaction in the block to obtain an execution result; The corresponding voting result is obtained based on the execution result, and the local time corresponding to the voting result is obtained as the candidate timestamp corresponding to the current voting stage of the slave node, and the candidate timestamp corresponding to the current voting stage is carried in the voting information corresponding to the current voting stage.

2. The method according to claim 1, characterized in that The proposal timestamp is calculated based on the timestamp corresponding to the legal voting information of each node collected by the master node in the target voting phase during the previous round of consensus, and the local time of the master node in the block packaging phase, including: The proposal timestamp is based on the candidate timestamps corresponding to the legal voting information of each node collected by the master node in the target voting phase during the previous round of consensus. The master node determines the collected candidate timestamps of the master node and the collected candidate timestamps of other nodes respectively; Based on the collected candidate timestamps of other nodes and the collected candidate timestamps of the master node, a cumulative time deviation is obtained; Based on the accumulated time deviation and the number of other nodes, an average time deviation is obtained; The local time of the master node during the packaging phase of the block and the average time deviation are fused and calculated to obtain a proposal timestamp.

3. The method according to claim 1, characterized in that The candidate timestamps corresponding to the legal voting information of each node collected by the slave node in the target voting phase during the previous round of consensus and the current local time of the slave node are calculated to obtain the verification timestamp, including: Determine the collected candidate timestamps of the slave node and the collected candidate timestamps of other nodes from the candidate timestamps corresponding to the legal voting information of each node collected by the slave node in the target voting phase during the previous round of consensus; Obtaining a cumulative time deviation based on the collected candidate timestamps of other nodes and the collected candidate timestamps of the slave node; Based on the accumulated deviation and the number of other nodes collected, an average time deviation is obtained; The current local time of the slave node and the average time deviation are fused and calculated to obtain a verification timestamp.

4. The method according to claim 1, characterized in that: After obtaining the local time corresponding to the voting result as the candidate timestamp corresponding to the current voting stage of the slave node, it also includes: The slave node broadcasts the voting information corresponding to the current voting stage to other nodes in the blockchain system, and receives the voting information corresponding to the current voting stage broadcasted by other nodes; Collecting candidate timestamps carried by legal voting information corresponding to the current voting phase broadcasted by each of the other nodes; Based on the legal voting information corresponding to the current voting stage broadcasted by a preset number of other nodes, the voting information corresponding to the next voting stage of the slave node is obtained.

5. The method according to claim 4, characterized in that After obtaining the voting information corresponding to the next voting phase of the slave node, the method further includes: Entering the next voting stage; wherein the voting information corresponding to the next voting stage carries the candidate timestamp in the legal voting information corresponding to the current voting stage broadcasted by each of the other nodes collected by the slave node in the current voting stage; Broadcasting the voting information corresponding to the next voting stage of the slave node to other nodes in the blockchain system, and receiving the voting information corresponding to the next voting stage broadcasted by other nodes; Collect the candidate timestamps carried by the legal voting information corresponding to the next voting stage broadcast by each of the other nodes; until the candidate timestamps carried by the legal voting information corresponding to the target voting stage broadcast by other nodes are collected, the total candidate timestamps collected by the slave node are obtained.

6. The method according to claim 1, characterized in that The master node is further used to add the total candidate timestamps collected in the previous round of consensus process to the additional data of the block, and execute the transaction in the block when the distance between the proposal timestamp and the verification timestamp is less than a preset range, including: Obtaining nodes and corresponding candidate timestamps from the additional data of the block respectively; Compare the candidate timestamp in the additional data with the total candidate timestamps collected by the slave node during the previous round of consensus; For candidate timestamps of the same node, when those stored in the additional data are the same as those collected from the slave nodes, and when the distance between the proposal timestamp and the verification timestamp is less than a preset range, the transaction in the block is executed.

7. The method according to claim 6, characterized in that Comparing the candidate timestamp in the additional data with the total candidate timestamps collected by the slave node during the previous round of consensus, including: The total candidate timestamps in the additional data are stored in a list by matching the nodes with the corresponding candidate timestamps; Traverse the nodes in the list, and if there is a candidate timestamp corresponding to the traversed node in the total candidate timestamps collected by the slave node in the previous round of consensus, compare the candidate timestamp of the traversed node with the corresponding candidate timestamp collected by the slave node.

8. The method according to claim 1, characterized in that When the distance between the proposal timestamp and the verification timestamp is less than a preset range, executing the transaction in the block, the method further includes: Obtaining nodes and corresponding candidate timestamps from the additional data of the block respectively; comparing the candidate timestamps in the additional data with the candidate timestamps collected from the slave nodes; In the event that the candidate timestamp of at least one of the same nodes stored in the additional data is inconsistent with that collected from the slave node, the transaction in the block does not need to be executed, and the voting result is determined to be a negative vote.

9. The method according to claim 1, characterized in that: The master node is further used to add the total candidate timestamps collected in the previous round of consensus process and the timestamp signature corresponding to each candidate timestamp to the additional data of the block, and execute the transaction in the block when the distance between the proposal timestamp and the verification timestamp is less than a preset range, including: Obtaining the timestamp signature of the node from the additional data of the block respectively; wherein the timestamp signature includes the signature of the proposal timestamp, block height and consensus round; The timestamp signature corresponding to each node is verified respectively, and when all verifications are passed and the distance between the proposal timestamp and the verification timestamp is less than a preset range, the transaction in the block is executed.

10. The method according to claim 9, characterized in that After verifying each of the timestamp signatures respectively, the method further comprises: In the event that at least one timestamp signature verification fails, there is no need to execute the transactions in the block, and the voting result is determined to be a negative vote.

11. The method according to claim 1, characterized in that: After obtaining the corresponding voting result based on the execution result, and obtaining the local time corresponding to the voting result as the candidate timestamp corresponding to the current voting stage of the slave node, the method further includes: Enter the next voting stage, and receive voting information corresponding to the next voting stage broadcasted by other nodes; wherein the voting information corresponding to the next voting stage carries the candidate timestamps corresponding to the current voting stage broadcasted by other nodes other than itself collected by the other nodes in the current voting stage, and the corresponding timestamp signature; Verifying each of the timestamp signatures respectively; When all the timestamp signatures are verified, the voting information corresponding to the next voting stage broadcast by other nodes is determined to be legal voting information, and the candidate timestamps in the legal voting information are collected into a cache.

12. The method according to claim 11, characterized in that When all the timestamp signatures are verified, the voting information corresponding to the next voting phase broadcasted by other nodes is determined to be legal voting information, including: Get the candidate timestamp of the voting information corresponding to the next voting phase broadcasted by other nodes; When the distance between the received candidate timestamp and the current local time of the slave node is within a threshold range, it is determined that the voting information corresponding to the next voting stage broadcast by other nodes is legal voting information.

13. The method according to claim 11, characterized in that When all the timestamp signatures are verified, the voting information corresponding to the next voting phase broadcasted by other nodes is determined to be legal voting information, including: Obtain candidate timestamps respectively from the voting information corresponding to the next voting phase broadcasted by the other nodes; When the candidate timestamp in the voting information corresponding to the next voting stage broadcast by the other nodes exists in the slave node cache, and the candidate timestamp in the cache is equal to the candidate timestamp of the other nodes, and when all the timestamp signatures are verified, it is determined that the voting information corresponding to the next voting stage broadcast by the other nodes is legal voting information.

14. The method according to claim 11, characterized in that After verifying each of the timestamp signatures separately, the method further comprises: Obtain candidate timestamps respectively from the voting information corresponding to the next voting phase broadcasted by the other nodes; If the candidate timestamp in the voting information corresponding to the next voting stage broadcasted by the other nodes exists in the slave node cache, and the candidate timestamp in the cache is not equal to the candidate timestamp of the other nodes, it is determined that the voting information corresponding to the next voting stage broadcasted by the other nodes is illegal voting information; The illegal voting information is discarded, and the candidate timestamps of the other nodes are deleted from the node cache.

15. A method for processing blockchain data, characterized in that: Applied to a master node in a blockchain system, the method comprises: Obtain a preset number of transactions, and generate blocks to be agreed upon based on the transactions, so as to enter the current round of consensus process; Determine the proposal timestamp of the block based on the candidate timestamps corresponding to the legal voting information of each node collected by the master node in the target voting phase during the previous round of consensus, and the local time of the master node in the block packaging phase; The proposal timestamp is added to the block, and the block is broadcast to each slave node in the blockchain, so that the slave node calculates the verification timestamp based on the candidate timestamp corresponding to the legal voting information of each node collected by the slave node in the target voting phase of the previous round of consensus, and the current local time of the slave node; the slave node verifies the block based on the candidate timestamp and the verification timestamp.

16. A blockchain data processing device, characterized in that: Applied to a slave node in a blockchain system, the device comprises: The receiving module is used to receive the blocks to be agreed upon sent by the master node, so as to enter the consensus process of the current round; A first acquisition module is used to obtain a proposal timestamp from the block; wherein the proposal timestamp is calculated based on the candidate timestamp corresponding to the legal voting information of each node collected by the master node in the target voting phase during the previous round of consensus, and the local time of the master node in the packaging phase of the block; A verification timestamp generation module is used to calculate the candidate timestamps corresponding to the legal voting information of each node collected by the slave node in the target voting phase during the previous round of consensus, and the current local time of the slave node to obtain the verification timestamp; An execution module, configured to execute the transaction in the block and obtain an execution result when the distance between the proposal timestamp and the verification timestamp is less than a preset range; A voting result generation module is used to obtain the corresponding voting result based on the execution result, and obtain the local time corresponding to the voting result as the candidate timestamp corresponding to the current voting stage of the slave node, and the candidate timestamp corresponding to the current voting stage is carried in the voting information corresponding to the current voting stage.

17. A blockchain data processing device, characterized in that: Applied to a master node in a blockchain system, the device comprises: A second acquisition module is used to acquire a preset number of transactions and generate blocks to be agreed upon based on the transactions to enter the current round of consensus process; A proposal timestamp generation module, used to determine the proposal timestamp of the block based on the candidate timestamps corresponding to the legal voting information of each node collected by the master node in the target voting phase during the previous round of consensus, and the local time of the master node in the block packaging phase; A block generation module is used to add the proposal timestamp to the block and broadcast the block to each slave node in the blockchain, so that the slave node calculates based on the candidate timestamp corresponding to the legal voting information of each node collected by the slave node in the target voting phase of the previous round of consensus, and the current local time of the slave node to obtain a verification timestamp; the slave node verifies the block based on the candidate timestamp and the verification timestamp.

18. A computer device comprising a memory and a processor, wherein the memory stores a computer program, wherein: When the processor executes the computer program, the processor implements the steps of the method according to any one of claims 1 to 14 or the steps of the method according to claim 15.

19. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the computer program implements the steps of the method according to any one of claims 1 to 14 or the steps of the method according to claim 15.

20. A computer program product comprising a computer program, characterized in that When the computer program is executed by a processor, the computer program implements the steps of the method according to any one of claims 1 to 14 or the steps of the method according to claim 15.

Images