Prediction synchronization method and device for global pre-assembled block of block chain

Abstract

The invention discloses a prediction synchronization method and device for a block chain global pre-assembled block, and the method comprises the steps: generating a transaction hash list through a node, generating an identifier of the transaction hash list, and storing a key value pair composed of the identifier and a node I into a distributed hash table network; wherein the identifier is a hash value of the transaction hash list; periodically broadcasting the identifier which appears most frequently in the DHT network, and determining whether the pre-assembled block body is correct or not by the node based on the identifier which appears most frequently and the identifier generated by the node; under the condition that the identifier with the highest occurrence frequency is different from the identifier generated by the node, the node queries the node I P with the identifier with the highest occurrence frequency, obtains a correct transaction list and corrects the local pre-assembled block body; and after the local pre-assembled block body is corrected, re-storing a key value pair formed by the identifier of the corrected node and the node IP into the DHT network to realize global synchronization. According to the method, the prediction accuracy of the pre-assembled block can be improved.

Description

Technical Field

[0001] The present invention relates to the field of blockchain technology, and in particular to a method and device for predicting and synchronizing global pre-assembled blocks of a blockchain. Background Art

[0002] Blockchain is a decentralized, tamper-proof, and secure distributed ledger. It combines distributed storage, peer-to-peer transmission, consensus mechanisms, and cryptography to record transactions and information in a continuously growing chain of blocks, ensuring data security and transparency. Blockchain features include decentralization, immutability, transparency, security, and programmability. Each data block is linked to the previous one, forming a continuous chain that ensures the integrity of the transaction history. Throughput is a key metric for measuring the efficiency of a blockchain system, reflecting its ability to process transactions per unit time. Therefore, improving blockchain throughput has been a hot topic in academic research. One approach to improving blockchain throughput is through "blockless transmission." Specifically, when a new block is mined, the entire block is not immediately transmitted. Instead, nodes predict and assemble the next block in advance, transmitting only key information from the new block, such as the block header and missing transactions. By reducing the need to transmit the entire block, the number of transactions per block can be significantly increased, significantly improving throughput. However, the key to this approach lies in improving the accuracy of pre-assembled blocks. To achieve this, inter-node communication can be used to achieve alignment. However, this alignment is local and may not align with the global state. Therefore, it takes time to achieve global stability, which can lead to a certain degree of lag. Summary of the Invention

[0003] To address the problems existing in the prior art, embodiments of the present application provide a method, apparatus, computing device, computer storage medium, and product containing a computer program for predictive synchronization of global pre-assembled blocks of a blockchain, which can provide a global alignment path for nodes to improve the prediction accuracy of pre-assembled blocks and significantly enhance the throughput of the blockchain network.

[0004] In a first aspect, an embodiment of the present application provides a method for predictive synchronization of global pre-assembled blocks of a blockchain, comprising: a node generates a transaction hash list and an identifier of the transaction hash list, and stores a key-value pair consisting of the identifier and the node IP in a distributed hash table DHT network; wherein the identifier is a hash value of the transaction hash list; the identifier that appears most frequently in the DHT network is periodically broadcast, and the node determines whether the pre-assembled block body is correct based on the identifier that appears most frequently and the identifier generated by the node; when the identifier that appears most frequently is different from the identifier generated by the node, the node queries the IP of the node that holds the identifier that appears most frequently through the DHT network, obtains the correct transaction list, and corrects the local pre-assembled block body; after the local pre-assembled block body is corrected, the key-value pair consisting of the corrected node identifier and the node IP is re-stored in the DHT network to achieve global synchronization.

[0005] In some possible implementations, generating the identifier of the transaction hash list is specifically performed by: performing a hash calculation on each transaction information in the preassembled block to determine a hash value; and calculating an overall hash value after concatenating all hash values ​​in transaction order.

[0006] In some possible implementations, storing the key-value pair consisting of the identifier and the node IP in a distributed hash table DHT network includes: calculating the logical distance according to the Kademli a protocol; the calculation formula of the logical distance is Δd = |K⊕Node ID|, where Δd represents the logical distance, k represents the identifier, and Node ID represents the node position; storing the key-value pair to n nodes with the smallest logical distance, where n≥1.

[0007] In some possible implementations, the periodic broadcast of the identifier that appears most frequently in the DHT network includes: a node counting the frequency of occurrence of identifiers in local storage, recording the identifier with the most occurrence as K_localmax; periodically broadcasting a (K_localmax, number of occurrences) message; and nodes receiving the broadcast comparing and updating their local K_localmax and forwarding a larger K value until the entire network converges.

[0008] In some possible implementations, the correcting of the local pre-assembled block body includes: the node sending the transaction hash list H1 of the node to the node holding the identifier that appears the most times; the receiving node compares H1 with the correct list H2, calculates the missing transaction set M=H2-H1 and the redundant transaction set T=H1-H2; returns the missing transaction set M, the redundant transaction set T and the complete transactions corresponding to the missing transaction set M to the node, and the node updates the local transaction hash list.

[0009] In some possible implementations, the node updates the local transaction hash list by adding the missing transaction set M to the transaction hash list H1 and deleting the redundant transaction set T.

[0010] In some possible implementations, the DHT network adopts the Kademlia protocol.

[0011] In a second aspect, an embodiment of the present application provides a device for predictive synchronization of global pre-assembled blocks of a blockchain, comprising: a storage module for a node to generate a transaction hash list, and generate an identifier for the transaction hash list, and store a key-value pair consisting of the identifier and the node IP in a distributed hash table DHT network; wherein the identifier is a hash value of the transaction hash list; a broadcast module for periodically broadcasting the identifier that appears most frequently in the DHT network, and the node determines whether the pre-assembled block body is correct based on the identifier that appears most frequently and the identifier generated by the node; a correction module for, when the identifier that appears most frequently is different from the identifier generated by the node, the node queries the IP of the node that holds the identifier that appears most frequently through the DHT network, obtains the correct transaction list, and corrects the local pre-assembled block body; an update module for, after the local pre-assembled block body is corrected, re-storing the key-value pair consisting of the corrected node identifier and the node IP in the DHT network to achieve global synchronization.

[0012] In a third aspect, an embodiment of the present application provides a computer-readable storage medium comprising computer-readable instructions. When a computer reads and executes the computer-readable instructions, the computer executes the method as described in any one of the first aspects.

[0013] In a fourth aspect, an embodiment of the present application provides a computing device comprising a processor and a memory, wherein the memory stores computer program instructions, and when the computer program instructions are executed by the processor, the method as described in any one of the first aspects is executed.

[0014] In a fifth aspect, an embodiment of the present application provides a product comprising a computer program, which, when the computer program product runs on a processor, enables the processor to execute the method as described in any one of the first aspects. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0016] Figure 1This is a flowchart of a method for predictive synchronization of global pre-assembled blocks of a blockchain provided by an embodiment of the present application;

[0017] Figure 2 This is a schematic diagram of the structure of a device for predictive synchronization of global pre-assembled blocks of a blockchain provided by an embodiment of the present application;

[0018] Figure 3 It is a structural diagram of a computing device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0019] To make the objectives, technical solutions, and advantages of the embodiments of the present invention more clear, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts shall fall within the scope of protection of the present invention.

[0020] The term "and / or" as used herein describes an association between related objects, indicating that three possible relationships exist. For example, "A and / or B" can represent: A exists alone, A and B exist simultaneously, or B exists alone. The symbol " / " as used herein indicates that the related objects are in an "or" relationship, for example, A / B means either A or B.

[0021] The terms "first" and "second" in this specification and claims are used to distinguish different objects rather than to describe a specific order of objects. For example, "first response message" and "second response message" are used to distinguish different response messages rather than to describe a specific order of response messages.

[0022] In the embodiments of this application, words such as "exemplary" or "for example" are used to indicate examples, illustrations, or descriptions. Any embodiment or design described as "exemplary" or "for example" in the embodiments of this application should not be interpreted as being preferred or advantageous over other embodiments or designs. Rather, the use of words such as "exemplary" or "for example" is intended to present the relevant concepts in a concrete manner.

[0023] In the description of the embodiments of the present application, unless otherwise specified, "multiple" means two or more, for example, multiple processing units means two or more processing units, etc.; multiple elements means two or more elements, etc.

[0024] To facilitate understanding of the embodiments of the present application, further explanation will be given below with reference to specific embodiments in conjunction with the accompanying drawings. The embodiments do not constitute a limitation on the embodiments of the present invention.

[0025] First, the technical terms involved in the embodiments of this application are introduced:

[0026] 1. A distributed hash table (DHT), also known as a distributed hash table, is a distributed system architecture for storing and retrieving data. It allows data to be shared across multiple nodes in a network and is stored in a decentralized manner across multiple nodes using a hash function. DHT is a decentralized storage system that efficiently manages key-value data.

[0027] Next, the technical solutions provided in the embodiments of the present application are introduced.

[0028] For example, Figure 1 The flowchart of the method for predicting synchronization of global pre-assembled blocks of a blockchain provided by an embodiment of the present application is shown. Figure 1 As shown, the method may include the following steps:

[0029] S11: The node generates a transaction hash list, calculates the hash value of the transaction hash list, and stores the key-value pair consisting of the hash value and the node IP in the distributed hash table network.

[0030] In this embodiment, in a blockchain network, blockchain nodes need to send their own transaction lists when modifying pre-assembled blocks. Directly sending complete transaction records would consume a significant amount of network traffic. Therefore, each blockchain node generates a transaction hash list when pre-assembling a block, denoted as H. Simultaneously, each node calculates a corresponding hash value based on its own transaction hash list and uses this hash value as a unique identifier, denoted as K. This identifier is used to indicate a specific transaction order. Nodes store key-value pairs in a distributed hash table (DHT) network, where the key is the hash value K and the value is the node IP address. During this process, the DHT network uses the Kademli a protocol to ensure that key-value pairs are stored on the node with the ID closest to K. This approach ensures that the key-value pairs of all nodes that generate the same pre-assembled block (i.e., with the same K value but different IP addresses) are uniformly stored on the same node, making it easier to determine the final standard by counting the number of occurrences of K.

[0031] Specifically, in a blockchain network, when a node needs to make corrections to a pre-assembled block, directly sending complete transaction records would result in a surge in network traffic, impacting overall performance. To address this issue, each node employs an efficient data representation method when pre-assembling a block: generating a transaction hash list. Specifically, a node hashes each transaction contained in its pre-assembled block, generating corresponding transaction hash values. For example, if a node's pre-assembled block contains transactions Tx1, Tx2, and Tx3, it will hash these transactions separately, obtaining t1 = keccak256(Tx1), t2 = keccak256(Tx2), and t3 = keccak256(Tx3). These transaction hash values ​​are combined in a specific order (typically the order in which the transactions appear in the block) to form a complete transaction hash list, denoted as H. This list is essentially a compact representation of all transactions in the block, preserving their uniqueness while significantly reducing the amount of data required.

[0032] In order to further distinguish different transaction hash lists, the node will also generate a unique identifier K based on the list H. This identifier is obtained by performing a secondary hash operation on the entire transaction hash list H, that is, K =

[0033] keccak256(t1+t2+t3). The addition operation here typically concatenates the transaction hash values ​​sequentially into a longer string, which is then hashed. In this way, the K value uniquely represents a specific transaction order. If the preassembled blocks of two nodes are identical (i.e., contain the same transactions in the same order), their K values ​​will be the same; conversely, if the transaction content or order differs, the K values ​​will be different. This design makes the K value a key indicator for determining the consistency of preassembled blocks.

[0034] Next, the node stores the generated key-value pair (K, node IP) in the distributed hash table (DHT) network. In this embodiment, the DHT network adopts the Kademlia protocol, a widely used DHT implementation method. Its core concept is to determine the storage location of data by logical distance (usually calculated using an XOR operation). Specifically, each DHT node has a unique Node ID, and the key-value pair (K, node IP) will be stored on the node with the closest logical distance between the Node ID and the K value. The logical distance is calculated as Δd = |K⊕Node ID|, where ⊕ represents a bitwise XOR operation. For example, if the K value is 000110, then the key-value pair will be stored on the node with a Node ID of 000110. If this node is unavailable, the system will select the node with the next closest logical distance (such as 000111 or 001000) as the backup storage location. The Node ID of Kademlia is 160 bits in binary. The example here simplifies the Node ID. The biggest advantage of this storage mechanism is that the key-value pairs of all nodes that generate the same pre-assembled block body (i.e., the same K value but different IP addresses) will be centrally stored on the same DHT node or several nearby nodes. In this way, the system can quickly determine the pre-assembled block body standard recognized by most nodes in the network by simply counting the number of times a certain K value appears on these nodes. For example, if K1 appears 100 times and K2 only appears 10 times, then K1 will be identified as the current correct pre-assembled block body identifier. This global statistical method avoids the synchronization delay problem caused by relying on local communication in traditional solutions, and can reach network-wide consensus more quickly. In addition, since the data is stored in a dispersed manner on multiple nodes in the DHT network, there is no risk of single point failure. Even if some nodes go offline or fail, the system can still continue to operate through backup data.

[0035] In this embodiment, each node generates the transaction hash list H and unique identifier K in a completely parallel process. Each node independently completes its own computation without the need for real-time communication with other nodes. A node interacts with other DHT nodes only when a key-value pair needs to be stored in the DHT network. This design significantly reduces the network's real-time communication burden, enabling the system to efficiently process large amounts of transaction data. Furthermore, because both the transaction hash list H and K values ​​are generated based on hash operations, their data size is significantly smaller than the original transaction list, further reducing network transmission and storage overhead.

[0036] S12: Periodically broadcast the hash value that appears most frequently in the distributed hash table. The node determines whether the pre-assembled block is correct based on the hash value that appears most frequently and the hash value stored by the node.

[0037] In this embodiment, each node, as part of a distributed hash table (DHT) network, stores a number of key-value pairs (K, node IP). Each node records the maximum value of K in its local storage and periodically broadcasts a message containing the K value and the number of times it appears (K, number of times). Upon receiving a broadcast message, the node first compares its locally stored K value with the K in the broadcast message, records the maximum value, and forwards it. The node then compares this maximum value with the K value it generates based on the transaction hash list to determine whether its pre-assembled block prediction is correct.

[0038] Specifically, to ensure that all nodes can efficiently reach a global consensus on the state of the pre-assembled block, this embodiment employs a verification mechanism based on periodic broadcasts. This distributed approach allows all nodes in the network to dynamically discover and confirm the pre-assembled block standard currently recognized by the majority. After completing the local pre-assembly of the block and generating the corresponding transaction hash list H and identifier K, each participating node in the network not only stores the key-value pair (K, node IP) in the DHT network, but also continues to participate in a periodic broadcast verification process. This process begins from the local perspective of each node, with each DHT node maintaining a locally stored set of key-value pairs (K, node IP). Due to the characteristics of the DHT, these key-value pairs do not represent the entire network's data. Instead, according to the routing rules of the Kademli a protocol, each node is only responsible for storing the portion of data that is logically close to its Node ID. Nevertheless, this local data already contains sufficient information to support the formation of a global consensus.

[0039] At the beginning of each broadcast cycle, a node first analyzes all key-value pairs stored locally and counts the frequency of occurrence of each K value. This count allows the node to determine the K value that appears most frequently within its storage, denoted as K_localmax. This K_localmax represents the pre-assembled block standard that is most likely to be recognized by the majority of nodes in the network, as observed from the node's local perspective. Note that due to network partitions or information propagation delays, K_localmax values ​​may vary from node to node at the same time. After the count is complete, the node creates a broadcast message containing two key pieces of information: the K_localmax value determined by the node and the number of times that value appears in its local storage. For example, a node might generate a message (K_max = 0x3a5f, count = 15), indicating that it considers the K value 0x3a5f to be the best candidate and that it has appeared 15 times within its storage. This broadcast message is sent to the node's neighbors in the network, typically including several nearest neighbors maintained in its DHT routing table.

[0040] When a node receives a broadcast message from another node, it performs a comparison and update process. First, the node compares the received K_max with the locally recorded K_localmax. The comparison criterion is the number of occurrences of these two K values ​​within their respective ranges. If the number of occurrences of the received K_max is greater than the number of occurrences of the local K_localmax, the node updates its own K_localmax to the received K_max and updates the number of occurrences accordingly. The node then forwards this broadcast message to its neighboring nodes. This design ensures that the most representative K value is always propagated in the network, and through multi-hop propagation, it can eventually cover the entire network.

[0041] S13: When the hash value that appears the most times is different from the hash value stored by the node, the node queries the IP of the node holding the hash value that appears the most times through the distributed hash table network, obtains the correct transaction list and corrects the local pre-assembled block body.

[0042] In this embodiment, when a node discovers, through a periodic broadcast mechanism, that its self-generated pre-assembled block identifier K is inconsistent with the network's mainstream K_max, it triggers the pre-assembled block correction process. If an error is detected in its own pre-assembled block, the node will correct it through the Distributed Host Information (DHT) network. First, the node queries the DHT network for a node that stores K key-value pairs. K here can be obtained from broadcast messages or local storage. After finding the target node, it obtains the IP addresses of all nodes that generated K values. If these nodes are able to generate K values, their predicted blocks are correct and can be used as references. The closest node is selected from all eligible nodes and sent its own incorrect transaction hash list H1. Upon receiving H1, the node with the correct prediction compares it with its own generated transaction hash list H2, calculates the missing transaction set M and the excess transaction set T, and sends the result to the node that made the incorrect prediction. Upon receiving this data, the node updates its own transaction list, adding the missing transaction set M to its list of known transactions and removing the transactions in the excess transaction set T from its list, thus completing the pre-assembled block correction.

[0043] Specifically, the pre-assembled block correction process begins with a node self-checking phase. Each participating node regularly compares its self-generated K value with the prevailing K_max obtained through the broadcast mechanism. This comparison typically occurs after the node has processed the most recent broadcast message, at which point its understanding of the network consensus state has been updated. If a mismatch between K and K_max is detected, the node initiates a correction process to maintain consistency with the network. Notably, this error detection is fully distributed, with each node making independent decisions. This ensures that the system as a whole is not impacted by the failure or malicious behavior of a single node. Upon detecting an inconsistency, the node first locates the set of nodes holding the correct pre-assembled block information through the Distributed Host-Host (DHT) network. Using K_max as the key, the node initiates a query request to the DHT network. According to the Kademli a protocol, this request is routed to the nodes whose Node IDs are logically closest to K_max. These nodes store the IP addresses of all nodes that generated K_max values. The DHT network returns a list of IP addresses corresponding to nodes that can provide the correct pre-assembled block information. In order to improve the efficiency of subsequent interactions, the node that initiates the correction request will select the node closest to itself in the network topology from this list as the interaction object. This proximity selection strategy can significantly reduce the delay of subsequent communications.

[0044] After selecting a target node, the node requiring correction does not directly request the complete transaction list. Instead, it sends its own transaction hash list, H1, to the selected correct node. This list, H1, is a sequence of hash values ​​for all transactions in the node's current preassembled block. As mentioned earlier, it is much lighter than simply sending the raw transaction data. Upon receiving H1, the correct node systematically compares it with its own correct transaction hash list, H2. This comparison involves calculating the difference between the two sets: first, the missing transaction set M (the hashes of transactions present in H2 but not in H1) is calculated; then, the excess transaction set T (the hashes of transactions present in H1 but not in H2) is calculated. This calculation can be performed efficiently by indexing the two hash tables, with algorithmic complexity being essentially linear. This difference comparison ensures that only the discrepancies, rather than the complete transaction list, need to be transmitted between nodes, saving significant network bandwidth when the number of transactions is large.

[0045] After the correct node completes the difference calculation, it returns the result to the node requesting the correction. The returned data packet contains three key components: the first is the missing transaction set M, which is the transaction hash list that the requester needs to supplement; the second is the redundant transaction set T, which is the transaction hash identifier that the requester needs to remove; and the third is the complete transaction data corresponding to the missing transaction set M. This data structure design provides sufficient correction information while avoiding unnecessary data transmission. Notably, the returned complete transaction data only includes the missing parts, rather than the entire block's transactions, which further optimizes network utilization. Furthermore, to ensure data integrity and authenticity, all transmitted information is accompanied by a corresponding digital signature to prevent tampering during transmission.

[0046] Upon receiving this data, the node requesting the correction immediately begins updating its local preassembled block. First, based on the returned missing transaction set M, the node inserts these transactions into the local transaction list in the correct order. Then, based on the excess transaction set T, the node removes transactions that should not exist from the local list. In some possible embodiments, the updated transaction list needs to be validated, for example, to check whether dependencies between transactions are satisfied or whether transactions comply with the constraints of the current blockchain state. After completing these updates, the node recalculates the transaction hash list H and identifier K and verifies that the new K value is consistent with K_max to ensure the correctness of the correction operation.

[0047] S14: After the local pre-assembled block is corrected, the key-value pair consisting of the corrected hash value and the node IP is stored back into the distributed hash table network to achieve global synchronization.

[0048] In this embodiment, after completing the pre-assembled block correction process, the node needs to resynchronize the updated state to the DHT network. The node reassembles the pre-assembled block based on the new transaction list, obtains the correct pre-assembled block, and generates a new K value. The latest (K, node IP) is then stored in the DHT network to further ensure global synchronization consistency and provide correction services for other nodes with inaccurate predictions.

[0049] Specifically, after a node successfully corrects its pre-assembled block, it first recalculates its transaction hash list H and the corresponding identifier K. This calculation process is identical to the initial generation process, ensuring that the same transaction list always produces the same K value. Notably, because the correction process has ensured that the transaction list is consistent with the mainstream network, the newly calculated K value should theoretically match the K_max previously obtained through broadcast. This matching verification is a critical quality assurance step. If the calculation results are inconsistent, it indicates that there may be an error in the correction process. The node will immediately roll back the changes and restart the correction process.

[0050] During the DHT network update process, a node generates a new key-value pair (K_max, node IP) and stores it in the DHT. This operation is similar to the initial storage process and is routed to the appropriate storage node via the Kademli a protocol. This step has a dual meaning: on the one hand, it updates the node's registration information in the DHT network, indicating that it can now also provide correct pre-assembled blocks; on the other hand, it strengthens the statistical weight of K_max in the network, making this standard value more stable. It is particularly worth noting that the high fault tolerance of distributed systems ensures that even if a node temporarily goes offline or fails during the correction process, the system can ensure that the overall operation is not affected, and other correct nodes can continue to provide services.

[0051] The above is an introduction to the method for predictive synchronization of global pre-assembled blocks of the blockchain provided by an embodiment of the present application. The unique identifier of the transaction hash list is generated by the node, and the node information with the same K value is centrally stored through the DHT. The node regularly broadcasts the K value with the most occurrences, and gradually converges to the global standard. If the node finds that its own K value is inconsistent with the global K value, it obtains the correct transaction list through the DHT for correction. The corrected node updates the K value and synchronizes it to the DHT to maintain global consistency. This method provides an efficient global synchronization mechanism for all nodes by introducing the storage and search method of the distributed hash table (DHT), significantly improving the node synchronization efficiency and enhancing the accuracy of the pre-assembled block body. This provides important support for achieving block-free transmission and improving the throughput of the blockchain network.

[0052] It is understandable that the size of the sequence number of each step in the above-mentioned embodiments does not mean the order of execution, and the execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present application. In addition, in some possible implementations, the steps in the above-mentioned embodiments can be selectively executed according to actual conditions, and can be partially executed or fully executed, which is not limited here. All or part of any features of any embodiment of the present application can be freely and arbitrarily combined without contradiction. The combined technical solution is also within the scope of the present application.

[0053] Based on the method in the above embodiment, the embodiment of the present application also provides a device for predictive synchronization of global pre-assembled blocks of blockchain. For example, Figure 2 The schematic diagram of the structure of a device for predicting synchronization of global pre-assembled blocks of a blockchain is shown. Figure 2 As shown, the device 200 for predictive synchronization of global pre-assembled blocks of the blockchain includes: a storage module 201, a broadcast module 202, a correction module 203, and an update module 204.

[0054] The storage module 201 is configured to generate a transaction hash list at a node, generate an identifier for the transaction hash list, and store a key-value pair consisting of the identifier and the node IP address in a distributed hash table (DHT) network; wherein the identifier is a hash value of the transaction hash list;

[0055] A broadcast module 202 is configured to periodically broadcast the identifier that appears most frequently in the DHT network, and the node determines whether the pre-assembled block is correct based on the identifier that appears most frequently and the identifier generated by the node;

[0056] Correction module 203, configured to, when the identifier with the most occurrences is different from the identifier generated by the node, query the IP address of the node holding the identifier with the most occurrences through the DHT network, obtain the correct transaction list, and correct the locally pre-assembled block body;

[0057] The updating module 204 is used to store the modified key-value pair consisting of the node identifier and the node IP into the DHT network again after the local pre-assembled block body is modified to achieve global synchronization.

[0058] It should be understood that the above-mentioned device is used to execute the method in the above-mentioned embodiment. The implementation principle and technical effect of the corresponding program module in the device are similar to those described in the above-mentioned method. The working process of the device can refer to the corresponding process in the above-mentioned method and will not be repeated here.

[0059] The present application also provides a computing device 300. Figure 3 As shown, computing device 300 includes a bus 302, a processor 304, a memory 306, and a communication interface 308. Processor 304, memory 306, and communication interface 308 communicate with each other via bus 302. Computing device 300 can be a server or a terminal device. It should be understood that this application does not limit the number of processors and memories in computing device 300.

[0060] The bus 302 may be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus. The bus may be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 3 The fact that only one line is used in the figure does not mean that there is only one bus or only one type of bus. Bus 304 may include a path for transmitting information between various components of computing device 300 (eg, memory 306, processor 304, communication interface 308).

[0061] The processor 304 may include any one or more processors such as a central processing unit (CPU), a graphics processing unit (GPU), a microprocessor (MP), or a digital signal processor (DSP).

[0062] The memory 306 may include volatile memory, such as random access memory (RAM). The processor 304 may also include non-volatile memory, such as read-only memory (ROM), flash memory, hard disk drive (HDD), or solid state drive (SSD).

[0063] Memory 306 stores executable program code. Processor 304 executes the executable program code to implement the functions of storage module 201, broadcast module 202, correction module 203, and update module 204, respectively, thereby implementing all or part of the steps of the method in the above-described embodiment. In other words, memory 306 stores instructions for executing all or part of the steps of the method in the above-described embodiment.

[0064] Alternatively, the memory 306 stores executable code, and the processor 304 executes the executable code to respectively implement the functions of the aforementioned apparatus 200 for predictive synchronization of global pre-assembled blocks of a blockchain, thereby implementing all or part of the steps in the above-described embodiment method. In other words, the memory 306 stores instructions for executing all or part of the steps in the above-described embodiment method.

[0065] The communication interface 308 uses a transceiver module such as, but not limited to, a network interface card or a transceiver to implement communication between the computing device 300 and other devices or a communication network.

[0066] Based on the methods in the above embodiments, an embodiment of the present application provides a computer-readable storage medium, which stores a computer program. When the computer program runs on a processor, the processor executes the methods in the above embodiments.

[0067] Based on the methods in the above embodiments, an embodiment of the present application provides a computer program product. When the computer program product runs on a processor, the processor executes the methods in the above embodiments.

[0068] It is understood that the processor in the embodiments of the present application may be a central processing unit (CPU), or may be other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field programmable gate arrays (FPGA), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. The general-purpose processor may be a microprocessor or any conventional processor.

[0069] The method steps in the embodiments of the present application can be implemented by hardware or by a processor executing software instructions. The software instructions can be composed of corresponding software modules, which can be stored in random access memory (RAM), flash memory, read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), registers, hard disks, mobile hard disks, CD-ROMs or any other form of storage medium known in the art. An exemplary storage medium is coupled to the processor so that the processor can read information from the storage medium and write information to the storage medium. Of course, the storage medium can also be a component of the processor. The processor and the storage medium can be located in an ASIC.

[0070] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When implemented using software, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the process or function described in the embodiment of the present application is generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted via the computer-readable storage medium. The computer instructions can be transmitted from one website, computer, server or data center to another website, computer, server or data center via a wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) method. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more available media integrated. The available medium can be a magnetic medium (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid state drive (SSD)).

[0071] It will be understood that the various numerical numbers involved in the embodiments of the present application are merely distinctions for the convenience of description and are not intended to limit the scope of the embodiments of the present application.

Claims

1. A method for predicting and synchronizing global pre-assembled blocks of a blockchain, characterized in that: The method comprises: The node generates a transaction hash list and an identifier for the transaction hash list, and stores a key-value pair consisting of the identifier and the node IP address in a distributed hash table (DHT) network; wherein the identifier is a hash value of the transaction hash list; Periodically broadcast the identifier that appears most frequently in the DHT network. Nodes determine whether the pre-assembled block is correct based on the identifier that appears most frequently and the identifier generated by the node. When the identifier with the most occurrences is different from the identifier generated by the node, the node queries the IP address of the node holding the identifier with the most occurrences through the DHT network, obtains the correct transaction list, and corrects the local pre-assembled block body; After the local pre-assembled block is corrected, the key-value pair consisting of the corrected node identifier and node IP is stored back into the DHT network to achieve global synchronization.

2. The method according to claim 1, characterized in that The identifier for generating the transaction hash list is specifically: Perform hash calculation on each transaction information in the pre-assembled block to determine the hash value; Calculate the overall hash value by concatenating all hash values ​​in transaction order.

3. The method according to claim 1, characterized in that The storing of the key-value pair consisting of the identifier and the node IP in a distributed hash table DHT network includes: The logical distance is calculated according to the Kademli a protocol; the calculation formula of the logical distance is Δd = |K⊕Node ID|, where Δd represents the logical distance, k represents the identifier, and Node ID represents the node location; Store the key-value pairs to the n nodes with the smallest logical distance, where n ≥ 1.

4. The method according to claim 1, wherein The identifiers that appear most frequently in the periodically broadcast DHT network include: The node counts the frequency of occurrence of the identifier in the local storage and records the one with the highest number of occurrences as K_loca lmax; Broadcast (K_loca lmax, number of occurrences) messages regularly; The nodes receiving the broadcast compare and update their local K_loca lmax and forward the larger K value until the entire network converges.

5. The method according to claim 1, wherein The modifying of the local pre-assembled block body comprises: The node sends its transaction hash list H1 to the node holding the identifier that appears the most times; The receiving node compares H1 with the correct list H2, and calculates the missing transaction set M = H2 - H1 and the excess transaction set T = H1 - H2; The missing transaction set M, the redundant transaction set T, and the complete transactions corresponding to the missing transaction set M are returned to the node, and the node updates the local transaction hash list.

6. The method according to claim 5, characterized in that The node updates the local transaction hash list, specifically: The missing transaction set M is added to the transaction hash list H1, and the redundant transaction set T is deleted.

7. The method according to claim 1, characterized in that The DHT network adopts the Kademli a protocol.

8. A prediction and synchronization device for global pre-assembled blocks of blockchain, characterized in that: The device comprises: A storage module is configured to generate a transaction hash list at a node, generate an identifier for the transaction hash list, and store a key-value pair consisting of the identifier and the node IP address in a distributed hash table (DHT) network; wherein the identifier is a hash value of the transaction hash list; The broadcast module is used to periodically broadcast the identifier that appears most frequently in the DHT network. The node determines whether the pre-assembled block is correct based on the identifier that appears most frequently and the identifier generated by the node. The correction module is used to query the IP address of the node holding the most frequently appearing identifier through the DHT network when the identifier with the most frequently appearing identifier is different from the identifier generated by the node, obtain the correct transaction list, and correct the local pre-assembled block body; The update module is used to store the key-value pair consisting of the corrected node identifier and node IP back into the DHT network after the local pre-assembled block body is corrected to achieve global synchronization.

Images