Blockchain node difference synchronization method, electronic device, and chip system

By processing the transactions and state updates of multiple blocks to be synchronized in parallel, the problem of excessively long synchronization time of blockchain nodes is solved, and a more efficient synchronization process is achieved.

CN119539802BActive Publication Date: 2026-01-23HANGZHOU HIGH-TECH ZONE (BINJIANG) INSTITUTE OF BLOCKCHAIN & DATA SECURITY
View PDF 2 Cites 0 Cited by

Patent Information

Application Number
CN202411450619.2
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2024-10-16
Publication Date
2026-01-23
Estimated Expiration
2044-10-16

AI Technical Summary

Technical Problem

During blockchain node synchronization, especially when the number of blocks differs significantly, the synchronization time is too long and uncontrollable. In existing technologies, serial execution leads to performance dependence on a single core clock frequency and low synchronization efficiency.

Method used

The blockchain node differential synchronization method is adopted, which obtains multiple blocks to be synchronized in parallel based on the block height difference. Transactions and world state updates are executed in parallel by multi-core processors, and the synchronization process is split into multiple stages to process the data of multiple blocks to be synchronized in parallel.

Benefits of technology

It improves the parallel processing capability of blockchain nodes, shortens the synchronization time, improves synchronization efficiency, processes transactions and state updates of multiple blocks to be synchronized in parallel, and reduces the uncontrollability of synchronization time.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN119539802B_ABST
    Figure CN119539802B_ABST
Patent Text Reader

Abstract

The application provides a blockchain node difference synchronization method, an electronic device and a chip system; and relates to the technical field of blockchains. The method comprises the following steps: obtaining a plurality of to-be-synchronized blocks from at least one peer node based on the height difference of blocks of a blockchain; in a data processing stage, performing parallel data processing on the plurality of to-be-synchronized blocks; the parallel data processing comprises executing transactions of the plurality of to-be-synchronized blocks in parallel; in a data updating stage, updating each world state after each to-be-synchronized block is executed according to the data processing result of each to-be-synchronized block; the data processing stage and the data updating stage of one round are used to complete the parallel synchronization processing of the plurality of to-be-synchronized blocks; in the synchronization process, the plurality of to-be-synchronized blocks obtained are processed in parallel, and the synchronization process does not need to be executed in series for each block, the parallel processing capability of a node is improved, the synchronization time is shortened, and the synchronization efficiency is improved.
Need to check novelty before this filing date? Find Prior Art

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of blockchains, and in particular to a blockchain node difference synchronization method, an electronic device, and a chip system. BACKGROUND

[0002] In the process of data synchronization of a blockchain node, a full synchronization mode can be used. For example, the open source Ethereum Geth (Go Ethereum) client written in Go language can be used as a bridge connecting users and the Ethereum network, and can support the full synchronization mode.

[0003] However, in the process of synchronizing the blockchain node using the full synchronization mode, each link is executed in series, and the execution performance completely depends on the single-core frequency. When the difference in the number of blocks between the newly started node and the current highest block in the blockchain network is large, the synchronization time is too long and uncontrollable. SUMMARY

[0004] According to various embodiments of the present application, a blockchain node difference synchronization method, an electronic device, and a chip system are provided, which can improve the parallel processing capability of the system and improve the synchronization efficiency.

[0005] In a first aspect, the present application provides a blockchain node difference synchronization method; the method comprises:

[0006] Based on the block height of the blockchain, a plurality of to-be-synchronized blocks are obtained from at least one peer node; in a data processing stage, parallel data processing is performed on the plurality of to-be-synchronized blocks; the parallel data processing comprises parallel execution of transactions of the plurality of to-be-synchronized blocks; in a data updating stage, each world state after execution of each to-be-synchronized block is updated in parallel according to the data processing result of each to-be-synchronized block; wherein the data processing stage and the data updating stage of one round are used to complete the parallel synchronization processing of the plurality of to-be-synchronized blocks.

[0007] In the above manner, based on the block height difference, a plurality of to-be-synchronized blocks are obtained, and the plurality of to-be-synchronized blocks are processed in parallel. The serial synchronization process of executing transactions and updating states does not need to be performed once for each to-be-synchronized block data. By parallel execution of transactions of the plurality of to-be-synchronized blocks, the blocks are relatively independent, and the execution of the next block transaction does not need to depend on the execution result of the previous block transaction, realizing multi-core parallel batch processing. According to the data processing result of each block, the corresponding world state after execution of each block is updated in parallel, which can improve the parallel processing capability of the node, shorten the synchronization time, and improve the synchronization efficiency. The method has strong usability and practicality.

[0008] In a possible implementation manner of the first aspect, each to-be-synchronized block includes a block header and a block body, and the data processing stage includes a block header stage and a block body stage; the parallel data processing of the plurality of to-be-synchronized blocks includes:

[0009] In the block header stage, the plurality of to-be-synchronized block headers are processed in parallel; after the block header processing is completed, the parallel data processing is performed in the block body stage, to obtain the data processing result of each to-be-synchronized block.

[0010] In a possible implementation manner of the first aspect, the parallel data processing of the plurality of to-be-synchronized block headers includes:

[0011] The plurality of to-be-synchronized block headers are verified in parallel, and the reverse mapping of each block header is calculated in parallel after the verification is passed.

[0012] In a possible implementation manner of the first aspect, the parallel data processing of the plurality of to-be-synchronized block bodies includes:

[0013] The plurality of to-be-synchronized block bodies are verified in parallel, to determine the transaction data of each block body, the transaction data including the number of transactions and the identifier of the transaction; the transactions of the plurality of to-be-synchronized block bodies are executed in parallel according to the identifier and the number, to obtain the transaction execution result corresponding to each to-be-synchronized block; and the global state after each to-be-synchronized block is executed is calculated in parallel based on the transaction execution result corresponding to each to-be-synchronized block, and the global state is taken as the data processing result of each to-be-synchronized block.

[0014] In a possible implementation manner of the first aspect, the data updating stage includes a hash stage; the global state after each to-be-synchronized block is executed is updated in parallel according to the data processing result of each to-be-synchronized block, including:

[0015] In the hash stage, the state data of the hash table after each to-be-synchronized block is executed is updated in parallel based on each data processing result; the state data includes an account address and a storage location; and the global state includes the state data of the hash table.

[0016] In a possible implementation manner of the first aspect, the updating stage further includes a state tree stage; after the hash stage, the method further includes: in the state tree stage, the hash value of the root node corresponding to each to-be-synchronized block is calculated in parallel based on the state data of the hash table, to obtain the state root hash corresponding to each to-be-synchronized block.

[0017] In a possible implementation manner of the first aspect, the updating stage further comprises calling the tracking index stage; after the state number stage, the method further comprises: based on each state root hash, updating transaction execution process data of the plurality of to-be-synchronized blocks in the temporary table in parallel; for the plurality of to-be-synchronized blocks, creating a first reverse index of the transaction execution process data of each to-be-synchronized block in parallel; the first reverse index is used to record the tracking transaction execution process data.

[0018] In a possible implementation manner of the first aspect, the updating stage further comprises: a history index stage, a log index stage, and a transaction search stage; after the calling the tracking index stage, the method further comprises: in the history index stage, based on data of the change set after parallel execution of each to-be-synchronized block in the blockchain, creating a corresponding account and stored history index of each to-be-synchronized block in parallel; in the log index stage, based on data of the log table after parallel execution of each to-be-synchronized block in the blockchain, creating a second reverse index of the event log corresponding to each to-be-synchronized block in parallel; in the transaction search stage, for the block body of the plurality of to-be-synchronized blocks and the transaction data of the plurality of to-be-synchronized blocks in the transaction table, creating a mapping of the transaction data and the transaction hash of each to-be-synchronized block in parallel.

[0019] In a possible implementation manner of the first aspect, the method further comprises: in the process of executing the first control flow, receiving and storing all to-be-synchronized blocks sent by one or more peer nodes; based on data exchange between the first control flow and the second control flow, in the process of executing the second control flow, obtaining a first quantity of to-be-synchronized blocks from all to-be-synchronized blocks, and performing parallel synchronization processing on the first quantity of to-be-synchronized blocks; after the synchronization of the first quantity of to-be-synchronized blocks is completed, performing parallel synchronization processing on a second quantity of to-be-synchronized blocks from all to-be-synchronized blocks, until all to-be-synchronized blocks are synchronized; the second quantity is less than or equal to the first quantity; in the process of performing parallel synchronization on the first quantity and the second quantity of to-be-synchronized blocks, based on the first control flow, continue to receive and store all to-be-synchronized blocks sent by one or more peer nodes in the next stage.

[0020] In a possible implementation manner of the first aspect, the method further comprises: when receiving a synchronization request sent by a lagging node, based on a block height difference of the blockchain, sending one or more to-be-synchronized blocks to the lagging node.

[0021] In a second aspect, the present application provides a blockchain node difference synchronization device, which comprises:

[0022] A data acquisition unit is configured to acquire a plurality of to-be-synchronized blocks from at least one peer node based on a block height difference of the blockchain.

[0023] a parallel processing unit, configured to perform parallel data processing on the plurality of to-be-synchronized blocks in a data processing stage; the parallel data processing comprises performing transactions of the plurality of to-be-synchronized blocks in parallel;

[0024] a state updating unit, configured to update each world state after each of the to-be-synchronized blocks is executed in parallel according to a data processing result of each of the to-be-synchronized blocks in a data updating stage; and

[0025] In a third aspect, the present application provides an electronic device, comprising at least one processor, and a memory connected to the at least one processor in communication; wherein the memory stores a computer program executed by the at least one processor, and the computer program is executed by the at least one processor to enable the at least one processor to execute the method of any one of the first aspect.

[0026] In a fourth aspect, the present application provides a chip system applied to an electronic device, the chip system comprising one or more processors, and the one or more processors are configured to call computer instructions to enable the electronic device to execute the method of the first aspect.

[0027] In a fifth aspect, the present application provides a computer readable storage medium, which stores a computer program, and the computer program is executed by a processor to implement the method of the first aspect.

[0028] In a sixth aspect, the present application provides a computer program product, which enables an electronic device to execute the method of the first aspect when the computer program product is run on the electronic device.

[0029] It can be understood that the beneficial effects of the second aspect to the sixth aspect can be referred to the related description of the first aspect, and will not be repeated here. BRIEF DESCRIPTION OF DRAWINGS

[0030] In order to more clearly illustrate the technical solutions of the embodiments of the present application or the prior art, the following will briefly introduce the drawings needed to be used in the embodiments or prior art description. Obviously, the drawings in the following description are only some embodiments of the present application, and for those skilled in the art, other drawings can also be obtained without creative labor on the basis of these drawings.

[0031] Figure 1 The system architecture schematic diagram of the application scenario provided by the embodiments of the present application;

[0032] Figure 2A flowchart of a blockchain node difference synchronization method provided by an embodiment of the present application is shown in FIG. 1.

[0033] Figure 3 A schematic diagram of an overall synchronization flow architecture provided by an embodiment of the present application is shown in FIG. 2.

[0034] Figure 4 A schematic diagram of parallel execution of transactions and parallel update of a world state for multiple to-be-synchronized blocks provided by an embodiment of the present application is shown in FIG. 3.

[0035] Figure 5 A structural schematic diagram of a blockchain node difference synchronization device provided by an embodiment of the present application is shown in FIG. 4.

[0036] Figure 6 A structural schematic diagram of an electronic device provided by an embodiment of the present application is shown in FIG. 5. DETAILED DESCRIPTION

[0037] The embodiments of the technical solutions of the present application will be described in detail below with reference to the accompanying drawings. The following embodiments are only used to more clearly illustrate the technical solutions of the present application, and therefore only serve as examples, and cannot limit the protection scope of the present application.

[0038] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which the present application belongs; the terms used herein are only for the purpose of describing specific embodiments and are not intended to limit the present application; the terms "include" and "have" and any variations thereof in the specification and claims of the present application and the above description of drawings are intended to cover non-exclusive inclusion.

[0039] In the description of the embodiments of the present application, the technical terms "first", "second", etc. are only used to distinguish different objects, and cannot be understood as indicating or implying relative importance or implicitly indicating the number, specific order or primary and secondary relationship of the indicated technical features. In the description of the embodiments of the present application, the meaning of "multiple" is two or more, unless otherwise explicitly and specifically limited.

[0040] Reference herein to "an embodiment" means that a particular feature, structure, or characteristic described in connection with the embodiment can be included in at least one embodiment of the present application. The appearance of the phrase in various places in the specification does not necessarily all refer to the same embodiment, nor is it necessarily independent or alternative to other embodiments. It is explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0041] In the description of the embodiments of the present application, the term "and / or" is only to describe the association relationship of the associated objects, which means that there can be three relationships, for example, A and / or B, which can represent the three cases of A alone, A and B together, and B alone. In addition, the character " / " in this paper generally represents that the front and rear associated objects are a "or" relationship.

[0042] In the blockchain network, the nodes with low block height (for example, newly started nodes) perform block synchronization through the client to ensure the consistency of the blockchain network. For example, the Ethereum blockchain node client software Geth (Go Ethereum) performs the block synchronization process in the full synchronization mode, which involves downloading block headers, verifying block headers, then downloading complete blocks, performing transaction verification of the blocks and updating the world state, and completing the synchronization process. The falling behind node repeatedly executes the above process for each block until it is synchronized to the latest block.

[0043] As shown in Figure 1 The system architecture diagram of the application scenario provided by the embodiments of the present application is shown. In the blockchain network, there are a plurality of nodes, for example, node 1 to node N (N is an integer greater than 1), each node maintains a corresponding number of blocks, for example, block 1 to block n (n is an integer greater than 3). There are some nodes in the blockchain network whose block height is lower than the current latest block height of the blockchain network, for example, the started node 1, whose corresponding block height is 3; the current latest block height of other nodes is n (i.e. the current latest block height of the blockchain network is n). The falling behind node needs to synchronize data so that the block height is consistent with that of other nodes, thereby ensuring the consistency of the blockchain network.

[0044] Because the process of block synchronization in the related technical solution verifies the block header, the block transaction verification and updates the world state, which is a serial synchronization for each block, that is, the above synchronization process is performed for the last block, after the synchronization is completed, the above synchronization process is performed for the current block, and then the synchronization of the next block is performed; in this way, the above synchronization process is serially executed for each block, that is, the synchronization of the next block depends on the synchronization result of the last block, and the execution performance of the synchronization process completely depends on the single core frequency performance of the processor; when the number of blocks between the block height of the falling behind node and the current latest block height is large, it will result in slow block synchronization speed and uncontrollable synchronization time.

[0045] In view of the problem that the synchronization time is too long and uncontrollable in the data synchronization process of the blockchain, the embodiment of the present application provides a blockchain node difference synchronization method. The lagging node divides the synchronization process into stages for the blocks to be synchronized. In the execution process of each stage after the division, multiple Go coroutines are called to process the data of multiple blocks to be synchronized in parallel, fully giving the performance of the multi-core processor. In each round of the synchronization process, multiple blocks to be synchronized can be processed in parallel in batches, improving the synchronization speed.

[0046] The specific implementation process of the blockchain node difference synchronization method provided by the present application is further introduced below through an embodiment.

[0047] As shown in Figure 2 , the flowchart of the blockchain node difference synchronization method provided by the embodiment of the present application, the execution subject of the method can be the lagging node shown in Figure 1 , and the method can include the following steps:

[0048] S201, based on the block height difference of the blockchain, obtaining multiple blocks to be synchronized from at least one peer node.

[0049] In some embodiments, the lagging node can communicate with other nodes in the blockchain network to obtain the current latest block height of the blockchain network. When the lagging node compares the block height and finds that there is a block height difference with the latest block height, based on the block height difference of the blockchain, the lagging node sends a data request to one or more peer nodes to request the block data of the peer nodes, i.e., the blocks to be synchronized.

[0050] For example, based on the block height difference, the lagging node can obtain all the blocks to be synchronized from the peer nodes, or based on the processing performance of the lagging node, obtain a part of all the blocks to be synchronized; for example, the latest block height of the blockchain is 2n, and the block height of the lagging node is 1, then the lagging node can obtain the blocks to be synchronized from block 2 to block 2n from the peer nodes, or first obtain the blocks to be synchronized from block 2 to block n, and then obtain the blocks to be synchronized from block n+1 to block 2n in the next synchronization.

[0051] Wherein, after the lagging node obtains the blocks to be synchronized from the peer nodes, the lagging node can store the blocks to be synchronized, so as to facilitate the fast reading of the blocks to be synchronized in the subsequent data synchronization process, avoid repeated requests to the peer nodes, and improve the data transmission efficiency.

[0052] For example, the blockchain synchronization process can include two parts of the control flow, as Figure 3The first control flow and the second control flow are shown. The first control flow is implemented based on a network communication module of the lagging node, and the second control flow is implemented based on a synchronization execution module of the lagging node. The first control flow is a process in which the lagging node obtains a to-be-synchronized block from one or more peer nodes based on the network communication module. The lagging node sends a data request based on a communication connection interface (or the network communication module) with other peer nodes to obtain the to-be-synchronized block, or obtains the to-be-synchronized block (such as a new block) by receiving a broadcast from a peer node.

[0053] In the blockchain network, nodes constantly exchange block information to ensure the synchronization and consistency of the entire network. The network communication module described above can be based on a sentry component to implement data transmission between the lagging node and other peer nodes. For example, Figure 3 As shown, the lagging node is responsible for receiving a newly generated block (New Block) and block headers (Block Headers) and block bodies (Block Bodies) requested from other peer nodes based on the communication mechanism of a point-to-point network (p2p network) via a sentry component, which is driven by data from peer nodes. The sentry component is a mechanism responsible for monitoring, managing, or assisting communication between nodes to ensure smooth operation and efficient communication between nodes in the blockchain network.

[0054] The new block can be a to-be-synchronized block broadcasted by a peer node to the lagging node via a P2P network, and the lagging node can receive the new block by listening to broadcast messages in the network. When the lagging node discovers that the block is behind the latest block height in the blockchain network through block height comparison, the lagging node can also actively send a data request to a peer node (a node updated to the latest block height or a node with a higher block height than the lagging node) to obtain the to-be-synchronized block. For example, Figure 3 As shown, the lagging node can send a data request to a peer node to request data of block headers (Block Headers) and data of block bodies (Block Bodies), respectively.

[0055] For example, the block header can include metadata of the block, such as block height, timestamp, hash value of the previous block (i.e., parent block hash), and state root (summary of hash values of all transactions in the block, such as Merkle root), etc. The block body can include all transaction data in the block, i.e., a record for recording actual data operations on the chain.

[0056] In the first control flow described above, for the block header phase and the block body phase of the second control flow, after verifying the block header and the block body, the lagging node can also obtain the verified block header (GetBlock Header) and the block body (Get Block Body) based on the point-to-point network via the sentry component, as shown inFigure 3 As shown by the dashed line in FIG. 9, the successfully validated block header and block body are confirmed to other nodes in the blockchain network by the sentinel component, and the validated block header and block body are saved in the blockchain copy, keeping data consistent with other nodes in the blockchain network.

[0057] S202, in the data processing phase, parallel data processing is performed on the plurality of to-be-synchronized blocks; the parallel data processing includes parallel execution of transactions of the plurality of to-be-synchronized blocks.

[0058] In the embodiments of the present application, when parallel data processing is performed on the plurality of to-be-synchronized blocks, the transactions in each to-be-synchronized block are executed in parallel. In the execution process of the transactions of the plurality of to-be-synchronized blocks, the conventional execution process sequentially executes the height of each block and updates the world state in sequence according to the block height, for example, the transactions of the first block (e.g., block 3) are executed first, and the corresponding world state 3 is updated after the execution of the transactions of the first block (e.g., block 3); based on the execution result of the transactions of the first block (e.g., block 3), the transactions of the second block (e.g., block 4) are executed, and then the corresponding world state 4 is updated. Unlike the conventional transaction execution process, in the embodiments of the present application, the transactions of the plurality of to-be-synchronized blocks are executed in parallel based on the system multi-core processing mechanism; for example, all the transactions in the plurality of to-be-synchronized blocks are replayed in parallel; thereby, when the transactions of the blocks are executed, the blocks are independent of each other and are executed in parallel, thereby improving the synchronization efficiency.

[0059] In some embodiments, each to-be-synchronized block includes a block header and a block body, and the data processing phase includes a block header phase and a block body phase; the parallel data processing of the plurality of to-be-synchronized blocks includes:

[0060] In the block header phase, the plurality of to-be-synchronized block headers are processed in parallel, and after the block header processing is completed, in the block body phase, the plurality of to-be-synchronized block bodies are processed in parallel to obtain the data processing result for each to-be-synchronized block.

[0061] In some embodiments, as shown in FIG. 10, there is a data exchange mechanism between the first control flow and the second control flow, such as block header exchange (Block Header Exchange) and block body exchange (Block Body Exchange). Figure 3

[0062] For example, in the block header phase (Headers Stage) of the second control flow, the data of the block header of the to-be-synchronized block is obtained through the block header exchange mechanism. As shown in FIG. 11, the data of the block header of the to-be-synchronized block is obtained through the block header exchange mechanism. Figure 4 ​As shown in (a) of FIG. 1, in the Headers Stage, the block headers (e.g., block header 1 to block header n) of the plurality of to-be-synchronized blocks (e.g., to-be-synchronized block 1 to to-be-synchronized block n) are verified in parallel. As shown in (b) of FIG. 1, after the block header verification is successful, the verified block header (GetBlock Header) can also be returned to the sentinel component. Based on the peer-to-peer network of the sentinel component, the lagging node confirms the successfully verified block header to other nodes in the blockchain network and stores it to a replica, realizing data exchange of the block header. Figure 3

[0063] Correspondingly, in the Bodies Stage of the second control flow, the data of the block bodies of the to-be-synchronized blocks is obtained through the block body exchange mechanism. As shown in (a) of FIG. 2, in the Bodies Stage, the block bodies (e.g., block body 1 to block body n) of the plurality of to-be-synchronized blocks (e.g., to-be-synchronized block 1 to to-be-synchronized block n) are processed in parallel. As shown in (b) of FIG. 2, after the parallel processing of the block bodies is completed, the verified block bodies (GetBlock bodies) can also be returned to the sentinel component. Based on the peer-to-peer network of the sentinel component, the lagging node confirms the successfully verified block bodies to other nodes in the blockchain network and stores them to a replica, realizing data exchange of the block bodies. Figure 4 Figure 3

[0064] Exemplarily, the process of parallel synchronization processing of the plurality of to-be-synchronized block headers includes parallel verification of the header information of the plurality of to-be-synchronized block headers and parallel persistent storage of the header information. The header information of the block header includes block height, hash value, total difficulty, etc. The process of verifying the header information includes verification of the block height, hash value, and total difficulty. When the header information is stored in parallel, the hash of the header information is calculated and the hash of the header information is stored persistently.

[0065] Exemplarily, the process of parallel processing of the plurality of to-be-synchronized block bodies includes, based on the parallel verification result of the block header, obtaining the plurality of to-be-synchronized block bodies corresponding to the specification block hash, parallel data processing of the plurality of to-be-synchronized block bodies, and persistent storage of the actual data of the plurality of to-be-synchronized block bodies to the disk. After the verification is passed, the stored information is the transaction height and the transaction identifier included in each block body. The transaction height includes the identifier of the starting transaction and the transaction number, and the transaction identifier is stored in the RLP encoding of the transaction.

[0066] ​​​Based on the above data exchange mechanism, data congestion of the first control flow is avoided, and after the first control flow obtains the block data, the first control flow stores the block data, so that the second control flow can continuously extract data from the storage unit of the first control flow with the execution of the synchronization, thereby reducing the consumption of unlimited memory in the block synchronization process and the delay caused by repeated requests and data transmission of the lagging node.

[0067] In some embodiments, the plurality of block headers to be synchronized are processed in parallel, including: performing parallel verification on the plurality of block headers to be synchronized, and performing parallel calculation of the reverse mapping of each block header after the verification is passed.

[0068] For example, the parallel verification process of the plurality of block headers to be synchronized can include hash value verification, proof of work verification, timestamp verification, and parent block hash verification. The hash value (such as the Merkle root hash) in the block header is a cryptographic digest of all transactions in the block. During hash value verification, the node recalculates the Merkle tree of all transactions in the block and compares whether the root hash is consistent with the Merkle root hash in the block header. If they are consistent, the verification is passed. The value of the random number is calculated randomly to perform proof of work verification. The timestamp in the block header records the generation time of the block. By checking whether the timestamp in the block header is within a predetermined reasonable range (such as greater than the timestamp of the previous block and less than the current time plus a certain time threshold), the timestamp in the block header is verified to be reasonable. The parent block hash in the block header is a reference to the previous block header. By checking whether the parent block hash of the current block header is consistent with the hash value of the previous block header, the parent block hash verification is achieved.

[0069] For example, the lagging node performs parallel synchronization processing on the block headers of the plurality of blocks to be synchronized based on the synchronization execution module. The header information of the block header includes the block height, the hash value, and the total difficulty (TD). The hash of the header information is calculated, and the calculated hash result is persistently stored.

[0070] For example, after the plurality of block headers to be synchronized are verified in parallel, the height hash of the block header is calculated, the detailed data of the block header is stored through the block header (Headers) table, and each block header is uniquely identified by its height and hash. The height is used to represent the position of the block in the block chain, which is counted from the genesis block; the hash value of the block header is used to represent the unique identification of the block header; the height and the block header hash are stored by using the encoding mode of serialized data, such as the Recursive Length Prefix (RLP) encoding mode based on the block header information for persistent storage.

[0071] The total difficulty of the block header (HeadersTD) table is used to persistently store the RLP encoding of the total difficulty contained in the block header, track the total difficulty of each block; the total difficulty is the cumulative value of all blockchain difficulties from the genesis block to the current block in the blockchain, which is used to prevent replay attacks and ensure the continuity of the blockchain data. Among them, the block height in the HeadersTD table corresponds to the height in the Headers table, which represents the position of the block; the hash in the HeadersTD table corresponds to the hash in the Headers table, which represents the hash of the block header.

[0072] The block header specification (HeaderCanonical) table is used to maintain the canonical path of the blockchain, i.e. the longest and heaviest (calculated by total difficulty) chain, by storing the hash of the block height; for example, when the chain forks, the canonical blockchain is determined by the table; thus, on the block height, the hash value of the block on the canonical blockchain is ensured, ensuring the canonical and continuity of the blockchain.

[0073] As shown in the example of Figure 3 In the parallel processing of multiple block headers to be synchronized, the block hash stage (Block Hashes Stage) is also included, which calculates the reverse mapping of the block headers of multiple blocks to be synchronized in parallel and persists the reverse mapping to the database. Compared with the traditional method of calculating the reverse mapping once after executing one block each time, the present application calculates the reverse mapping of the block headers of multiple blocks to be synchronized in parallel after parallel verification of the block headers of multiple blocks to be synchronized, thereby improving the synchronization processing efficiency of the blocks by splitting, reorganizing and parallel processing of multiple blocks to be synchronized.

[0074] The reverse mapping of the block header is a reverse indexing mechanism based on the block header to locate the block itself. Each block in the blockchain has a unique hash value, which is obtained by encrypting the content of the block header through a hash algorithm. The reverse mapping stores the mapping relationship between the block header hash value and the actual data of the corresponding block header. When searching for a block header corresponding to a specific hash value, the actual data of the associated block header can be located by reverse mapping through the hash index without traversing the entire blockchain.

[0075] Correspondingly, the reverse mapping of the block header is persisted to the database to ensure the reliability and persistence of the data. At the same time, the database can provide efficient data retrieval and query capabilities to support fast positioning and access to block headers and related information.

[0076] After the block header is verified, the header information of the block header is persisted based on the above data table, so that the node can quickly verify the new block, ensure that the new block meets the specifications and historical records of the blockchain, and thus maintain the safety and stability of the entire network. Compared with the traditional scheme in which the persistence of each data table is performed after the entire block synchronization is completed, the application can perform parallel persistence of the header information of the plurality of to-be-synchronized block headers to the above data table after the plurality of to-be-synchronized block headers are verified, thereby improving the synchronization efficiency by splitting and reorganizing the synchronization process.

[0077] In some embodiments, the plurality of to-be-synchronized block bodies are processed in parallel to obtain a data processing result for each to-be-synchronized block, including:

[0078] S2021, the plurality of to-be-synchronized block bodies are verified in parallel to determine the transaction data of each block body, and the transaction data includes the number of transactions and the identification of the transactions.

[0079] As shown in Figure 3 , the process of parallel processing of the plurality of to-be-synchronized block bodies includes a block body stage (Bodies Stage). In this stage, based on the verification result of the plurality of to-be-synchronized block headers, the synchronization execution module of the lagging node can request the network communication module for the block body corresponding to the standard block hash. The standard block hash refers to a hash value conforming to the format of the block chain hash algorithm.

[0080] The process of parallel verification of the plurality of to-be-synchronized block bodies can include transaction signature verification, transaction order and dependency verification, and Merkle tree verification, etc. The lagging node checks whether the signature of each transaction in the block is valid through the public key to achieve transaction signature verification; in the blockchain network, there can be a dependency relationship between transactions (such as the calling relationship in the smart contract), and by checking whether the dependency relationship is correctly handled, the transaction order and dependency verification is achieved to ensure the correctness of the order and logic of the transactions.

[0081] As shown in Figure 3 , after the block body stage, there is also a sender stage (Sender Stage). Since the sender field is not recorded in the transactions of the block body, the field is the address derived from the private key that signs a transaction, which will be needed in the logic of the blockchain node, therefore, in the process of synchronizing the block, by processing the digital signature of the transaction, the public key is recovered, the lagging node can calculate the sender of each transaction in the block body, i.e. the aforementioned address, and persistently store the address.

[0082] S2022, according to the identification and the number, the transactions of the plurality of to-be-synchronized block bodies are executed in parallel to obtain a transaction execution result corresponding to each to-be-synchronized block.

[0083] For example, such as Figure 4 As shown in Figure (b), each block body (e.g., block body 1 to block body n) contains multiple transactions. The block body phase includes the process of persistently storing the block body data, which includes the transaction height and transaction identifiers for each block body. The transaction height includes the start transaction identifier and the number of transactions. Transactions in a block body include transactions that have occurred in historical blocks or transactions from new blocks.

[0084] like Figure 3 As shown, the block synchronization process also includes a transaction execution stage; as... Figure 4 As shown in Figure (b), lagging nodes replay transactions in parallel for the transaction data contained in each block. This means that the blockchain virtual machine re-executes all transactions in each block sequentially, including transaction verification, transaction execution, and state transitions. Transaction verification includes checking the transaction format, signature, account balance, etc., to ensure the transaction is valid. Transaction execution involves executing the contract code within the transaction in the virtual machine, including transfers and contract calls. State transitions update the blockchain state based on the transaction execution results, such as account balances and contract states.

[0085] In this embodiment, the replay of transactions involves parallel processing of transactions in multiple blocks to be synchronized. That is, transactions in block body 1 to block body n are executed in parallel, and the transaction execution results corresponding to each block body (such as transaction execution result 1 to transaction execution result n) are obtained in parallel. Instead of executing one block before executing the next block, the synchronization processing efficiency can be greatly improved.

[0086] S2023: Based on the transaction execution results corresponding to each block to be synchronized, the global state after each block to be synchronized is calculated in parallel and used as the data processing result of each block to be synchronized.

[0087] For example, such as Figure 4 As shown in Figure (b), for multiple blocks to be synchronized, after executing all transactions in each block body, the global state (plain state) of the blockchain (i.e., the global state corresponding to each block to be synchronized, such as global state 1 to global state n) is calculated based on the transaction execution results (e.g., transaction execution result 1 to transaction execution result n). This global state can include account state, contract state, and global parameters. Specifically, account state includes the balance of all accounts, the value of the random number, contract code, and storage; contract state is the internal state of the smart contract, including variable values ​​and storage; global parameters include block height, difficulty value, and timestamp.

[0088] Accordingly, after calculating the global state, the global state is persisted to disk as the data processing result for each block to be synchronized; for example, the transaction logs (or event logs) during the synchronization process are stored in the log table, and the changed data records during the synchronization process are stored in the change set.

[0089] S203, during the data update phase, based on the data processing results of each block to be synchronized, the world state after each block to be synchronized is updated in parallel.

[0090] In some embodiments, after the lagging node completes block synchronization and calculates the global state corresponding to each block in parallel, such as... Figure 4 As shown in Figure (a), the world state of the blockchain is updated in parallel based on the global state, that is, the world state (e.g., world state 1 to world state n) is updated in parallel after each block to be synchronized is executed. This world state stores the current value of all ledger states in the blockchain network, which may include, for example, account balances, smart contract bytecode, smart contract custom data, etc.

[0091] For example, lagging nodes calculate the global state in parallel based on the transaction execution results of each block to be synchronized, and update their internal world state database accordingly. This ensures that after lagging nodes have completed the transactions in blocks with the same identifier, their states are completely consistent, meaning that the updated world state of each node in the blockchain network remains consistent.

[0092] The world state can be tracked using a version number; each time a node updates the world state, the corresponding version number increments synchronously. The world state data is persistently stored in a database to ensure data reliability and recoverability.

[0093] In some embodiments, the data update phase includes a hash phase; based on the data processing results for each block to be synchronized, the world state after each block to be synchronized is updated in parallel, including:

[0094] During the hashing phase, based on the result of each data processing step, the state data in the hash table after each block to be synchronized is updated in parallel; the state data includes the account address and storage location; the world state includes the state data of the hash table.

[0095] For example, such as Figure 3As shown, the second control flow further includes a Hashed Stage, in which, by reading the new change records in the change set (generated based on the synchronization result), the account address of the new account and the storage location are determined, and the account address and the storage location are persisted into a hash table. The account address of the new account is a unique string used to identify the new account in the blockchain network, and the storage location is the specific location of the state data of the account address in the underlying storage structure of the blockchain.

[0096] In some embodiments, the updating stage further includes a State Tree Stage; after the Hashed Stage, the method further includes: in the State Tree Stage, based on the state data of the hash table, calculating the hash value of the root node corresponding to each to-be-synchronized block in parallel to obtain the state root hash corresponding to each to-be-synchronized block.

[0097] As shown in the example, Figure 3 As shown, after the Hashed Stage, the State Tree Stage (Trie Stage) is further included. In this stage, the state data of the blockchain is stored based on the Merkle tree structure; the state root hash is calculated based on the state data of the hash table, and the storage state of the Merkle tree structure is constructed and updated. The state root hash is the hash value of the root node of the Merkle tree, which represents a snapshot of the complete state of the blockchain at a certain time; by calculating the state root hash, it is ensured that the lagging node reaches the same world state as other nodes after block synchronization and state update.

[0098] In some embodiments, the updating stage further includes a Call Trace Index Stage; after the State Tree Stage, the method further includes: in the Call Trace Index Stage, based on each state root hash, updating the transaction execution process data of the plurality of to-be-synchronized blocks in the temporary table in parallel; for the plurality of to-be-synchronized blocks, creating a first reverse index of the transaction execution process data of each to-be-synchronized block in parallel; the first reverse index is used to record and track the transaction execution process data.

[0099] As shown in the example, Figure 3 As shown, after the State Tree Stage, the second control flow further includes a Call Trace Index Stage (Call Trace Index Stage). In the Call Trace Index Stage, the data in the temporary table of the blockchain network is processed, the transaction execution process data in the temporary table is updated based on the execution process of the transaction in each block, and a first reverse index is created; the transaction execution process data in the temporary table is recorded and tracked through the first reverse index, such as tracking contract calls, transaction execution paths, etc.

[0100] The first reverse index can be a reverse index created for the transaction execution process data in the temporary table, between the transaction and the called smart contract. That is, the smart contract called by the transaction and the execution result can be queried through the reverse index; or a reverse index can be created for the contract call chain, that is, the call relationship between smart contracts can be traced through the reverse index to indicate the transaction execution path, etc.

[0101] Accordingly, a first inverse index is formed by establishing a mapping relationship between the keywords corresponding to transactions and smart contracts, and the document location information of those keywords; by establishing a mapping relationship between keywords and document location information, fast retrieval and querying are achieved.

[0102] In some embodiments, the update phase further includes: a history index phase, a log index phase, and a transaction lookup phase; after invoking the tracking index phase, the method further includes: in the history index phase, creating a historical index of the account and storage corresponding to each block to be synchronized in parallel based on the change set data after each block to be synchronized is executed in parallel in the blockchain; in the log index phase, creating a second reverse index of the event log corresponding to each block to be synchronized in parallel based on the log table data after each block to be synchronized is executed in parallel in the blockchain; in the transaction lookup phase, creating a mapping between the transaction data and transaction hash of each block to be synchronized in parallel for the block bodies of multiple blocks to be synchronized and the transaction data of multiple blocks to be synchronized in the transaction table.

[0103] For example, such as Figure 3 As shown, after the call trace index stage, the second control flow also includes the history index stage; after the history index stage, it also includes the log index stage; and after the log index stage, it also includes the transaction lookup stage.

[0104] In the historical indexing phase, after updating the data in the temporary table, the state data in the change set is processed. Corresponding historical indexes are created for the accounts and storage in the change set to record the historical data of the world state. These historical indexes are used to query the historical values ​​of account balances, contract states, or other state variables.

[0105] Accordingly, after the history index is created, the data in the log table is processed in the log index stage. The data in the log table includes event log related data. For the event log, a second reverse index is created; the second reverse index is used to store the mapping relationship between the keywords of the event log and the location information in the disk. By extracting the event information (such as transfer, contract creation, contract call, and the like) in the event log, standardizing the event information, extracting the keywords in the event information, taking the keywords as the keys of the index, and establishing a mapping relationship between the keywords and all location information (such as log identification ID, timestamp, block height, and the like) of the keywords in the event log, the mapping relationship is stored in the form of a reverse index, and the keywords can be quickly located to the related event log.

[0106] For example, after the reverse index of the event log is created, the data in the block body and the transaction table is processed in the transaction lookup stage (Tx Lookup Stage), and the lookup mapping of the transaction hash is persisted; the existence of the transaction is quickly verified, and the transaction details are looked up.

[0107] It should be noted that, in the traditional block synchronization process, the blocks are sequentially synchronized in order, and the process of updating the world state needs to be executed once for each block in series. When the number of different blocks is large, the synchronization time will be very long. In the embodiments of the present application, a plurality of to-be-synchronized blocks are processed in parallel, and then the parallel synchronization processing results of the batch of blocks in one round are used to update the storage state in parallel. Once the synchronization execution round is completed, the synchronization processing of the plurality of to-be-synchronized blocks is completed, and the synchronization time is shortened.

[0108] In some embodiments, the method further includes:

[0109] In the process of executing the first control flow, all to-be-synchronized blocks sent by one or more peer nodes are received and stored; based on the data exchange between the first control flow and the second control flow, in the process of executing the second control flow, a first number of to-be-synchronized blocks in all to-be-synchronized blocks are obtained, and parallel synchronization processing is performed on the first number of to-be-synchronized blocks; after the synchronization of the first number of to-be-synchronized blocks is completed, parallel synchronization processing is performed on a second number of to-be-synchronized blocks in all to-be-synchronized blocks, until all to-be-synchronized blocks are synchronized; the second number is less than or equal to the first number; in the process of performing parallel synchronization on the first number and the second number of to-be-synchronized blocks, based on the first control flow, the next stage of all to-be-synchronized blocks sent by the one or more peer nodes are continuously received and stored.

[0110] For example, the network communication module of the lagging node is responsible for data interaction with other peer nodes. The lagging node can obtain the latest block height of the blockchain network, request all blocks to be synchronized based on the difference between the latest block height and its own block height, and store all blocks to be synchronized. The synchronization execution module, based on the parallel computing capability of the processor, extracts the block headers and corresponding block bodies of multiple blocks to be synchronized from the network communication module during the synchronization execution process, and performs a parallel synchronization process. In the initial round of synchronization, a first number of blocks are extracted from the stored blocks to be synchronized and synchronized; in the second round of synchronization, a second number of blocks are extracted from the stored blocks to be synchronized and synchronized.

[0111] The second quantity is less than or equal to the first quantity. That is, in the synchronization process of multiple rounds, the number of blocks to be synchronized in each round will decrease, until there is finally one block to be synchronized, thus completing the synchronization process of the blockchain.

[0112] In addition, in the second control flow, while the synchronization execution module is synchronizing the blocks to be synchronized, the network communication module can continue to obtain the blocks to be synchronized in the blockchain network, thereby reducing the request latency during the synchronization process; since the synchronization execution module continuously extracts the blocks to be synchronized from the network communication module, memory consumption can be reduced.

[0113] In some embodiments, the method further includes:

[0114] Upon receiving a synchronization request from a lagging node, one or more blocks to be synchronized are sent to the lagging node based on the block height difference in the blockchain.

[0115] For example, when there are other lagging nodes whose block height is lower than its own current block, it can also receive synchronization requests sent by other lagging nodes and send one or more blocks to be synchronized to other lagging nodes based on the block height of the blockchain.

[0116] Through the embodiments of this application, the node full synchronization process is split, and the blocks to be synchronized are processed in parallel batches, releasing the parallel processing capability of the server's multi-core processors, and batch processing of similar tasks (such as various stages of the synchronization process), optimizing the latency and performance pressure in each stage, and greatly improving the synchronization rate.

[0117] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. 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 this application.

[0118] Corresponding to the blockchain node differential synchronization method provided in the above embodiments, such asFigure 5 As shown, the embodiments of the present application provide a blockchain node difference synchronization device. For ease of illustration, only parts related to the embodiments of the present application are shown.

[0119] The device comprises:

[0120] The data acquisition unit 51 is configured to acquire a plurality of to-be-synchronized blocks from at least one peer node based on a block height difference of a blockchain.

[0121] The parallel processing unit 52 is configured to perform parallel data processing on the plurality of to-be-synchronized blocks in a data processing stage. The parallel data processing comprises parallel execution of transactions of the plurality of to-be-synchronized blocks.

[0122] The state updating unit 53 is configured to update each world state after execution of each to-be-synchronized block in parallel according to a data processing result of each to-be-synchronized block in a data updating stage.

[0123] The data processing stage and the data updating stage of one round are configured to complete the parallel synchronization processing of the plurality of to-be-synchronized blocks.

[0124] In a possible implementation, each to-be-synchronized block comprises a block header and a block body, and the data processing stage comprises a block header stage and a block body stage. The parallel processing unit 52 is further configured to perform parallel data processing on the plurality of block headers in the block header stage, and perform parallel data processing on the plurality of block bodies in the block body stage after the processing of the block headers is completed, to obtain the data processing result of each to-be-synchronized block.

[0125] In a possible implementation, the parallel processing unit 52 is further configured to perform parallel verification on the plurality of block headers, and perform parallel calculation of the reverse mapping of each block header after the verification is passed.

[0126] In a possible implementation, the parallel processing unit 52 is further configured to perform parallel verification on the plurality of block bodies, determine transaction data of each block body, perform the transactions of the plurality of block bodies in parallel according to the transaction data, obtain a transaction execution result corresponding to each to-be-synchronized block, and perform parallel calculation of a global state after execution of each to-be-synchronized block based on the transaction execution result corresponding to each to-be-synchronized block, and take the global state as the data processing result of each to-be-synchronized block.

[0127] In a possible implementation, the data updating stage comprises a hash stage. The state updating unit 53 is further configured to update state data after execution of each to-be-synchronized block in a hash table in parallel based on each data processing result in the hash stage. The state data comprises an account address and a storage location. The world state comprises the state data of the hash table.

[0128] In a possible implementation, the data updating stage further includes a state tree stage; and the state updating unit 53 is further configured to, in the state tree stage, calculate, based on the hash table-based state data, hash values of root nodes corresponding to each of the to-be-synchronized blocks in parallel, to obtain state root hashes corresponding to each of the to-be-synchronized blocks.

[0129] In a possible implementation, the data updating stage further includes a call tracking index stage; and the state updating unit 53 is further configured to, in the call tracking index stage, update, based on each of the state root hashes, transaction execution process data of the plurality of to-be-synchronized blocks in the temporary table in parallel; and create, for the plurality of to-be-synchronized blocks, a first reverse index of the transaction execution process data of each of the to-be-synchronized blocks in parallel; the first reverse index is used to record the tracking transaction execution process data.

[0130] In a possible implementation, the data updating stage further includes a history index stage, a log index stage, and a transaction searching stage; and the state updating unit 53 is further configured to, in the history index stage, create, based on data of the change set after parallel execution of each of the to-be-synchronized blocks in the blockchain, a history index of an account corresponding to each of the to-be-synchronized blocks and stored; in the log index stage, create, based on data of the log table after parallel execution of each of the to-be-synchronized blocks in the blockchain, a second reverse index of event logs corresponding to each of the to-be-synchronized blocks; and in the transaction searching stage, create, for block bodies of the plurality of to-be-synchronized blocks and transaction data of the plurality of to-be-synchronized blocks in the transaction table, a mapping of the transaction data of each of the to-be-synchronized blocks and a transaction hash.

[0131] In a possible implementation, the data obtaining unit 51 is further configured to, in the process of executing the first control flow, receive and store all to-be-synchronized blocks sent by one or more peer nodes; and the parallel processing unit 52 is further configured to, based on data exchange between the first control flow and the second control flow, obtain, in the process of executing the second control flow, a first quantity of to-be-synchronized blocks from all the to-be-synchronized blocks, and perform parallel synchronization processing on the first quantity of to-be-synchronized blocks; after synchronization of the first quantity of to-be-synchronized blocks is completed, perform parallel synchronization processing on a second quantity of to-be-synchronized blocks from all the to-be-synchronized blocks, until all the to-be-synchronized blocks are synchronized; the second quantity is less than or equal to the first quantity; and the data obtaining unit 51 is further configured to, in the process of performing parallel synchronization on the first quantity and the second quantity of to-be-synchronized blocks, continue to receive and store, based on the first control flow, all to-be-synchronized blocks sent by the one or more peer nodes in the next stage.

[0132] In a possible implementation, the apparatus further includes a data sending unit configured to, when receiving a synchronization request sent by a lagging node, send one or more to-be-synchronized blocks to the lagging node based on a difference in block height of the blockchain.

[0133] Through the embodiments of this application, the headers of multiple blocks to be synchronized are processed in parallel during the synchronization process, and the bodies of multiple blocks to be synchronized are processed in parallel. It is not necessary to perform a serial synchronization process for each block of data to be synchronized each time. By performing parallel batch processing of multiple blocks to be synchronized and then uniformly updating the status, the parallel processing capability of the node can be improved, the synchronization time can be shortened, and the synchronization efficiency can be improved.

[0134] Figure 6 A schematic diagram of the hardware structure of electronic device 6 is shown.

[0135] like Figure 6 As shown, the electronic device 6 of this embodiment includes: at least one processor 60 ( Figure 6 (Only one is shown in the image), a memory 61, which stores a computer program 62 that can run on the processor 60. When the processor 60 executes the computer program 62, it implements the steps in the above method embodiments, for example... Figure 2 S201 to S203 are shown. Alternatively, when the processor 60 executes the computer program 62, it implements the functions of each module / unit in the above-described device embodiments.

[0136] It is understood that the structures illustrated in the embodiments of this application do not constitute a specific limitation on the electronic device 6. In other embodiments of this application, the electronic device 6 may include more or fewer components than illustrated, or combine some components, or split some components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0137] The electronic device 6 may include, but is not limited to, a processor 60 and a memory 61. Those skilled in the art will understand that... Figure 6 This is merely an example of electronic device 6 and does not constitute a limitation on electronic device 6. It may include more or fewer components than shown, or combine certain components, or different components. For example, the electronic device may also include input transmitting devices, network access devices, buses, etc.

[0138] The processor 60 can be a central processing unit (CPU), and can also be other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA) or other programmable logic devices, discrete gates or transistor logic, discrete hardware components, etc. The general-purpose processor can be a microprocessor or the processor can also be any conventional processor.

[0139] The processor 60 can also be provided with a memory for storing instructions and data. In some embodiments, the memory in the processor 60 is a cache memory. The memory can store instructions or data that have just been used or are frequently used by the processor 60. If the processor 60 needs to use the instructions or data again, the instructions or data can be directly called from the memory. This avoids repeated access and reduces the waiting time of the processor 60, thereby improving the efficiency of the system.

[0140] The memory 61 can be an internal storage unit of the electronic device 6, such as a hard disk or a memory of the electronic device 6, in some embodiments. The memory 61 can also be an external storage device of the electronic device 6, such as a plug-in hard disk, a smart media card (SMC), a secure digital (SD) card, a flash card, etc. provided on the electronic device 6. Further, the memory 61 can include both the internal storage unit and the external storage device of the electronic device 6. The memory 61 is used to store an operating system, an application program, a boot loader, data, and other programs, such as program codes of computer programs, etc. The memory 61 can also be used to temporarily store data that has been transmitted or is to be transmitted.

[0141] In addition, each functional unit in each of the embodiments of the present application can be integrated in one processing unit, or each unit can exist physically separately, or two or more units can be integrated in one unit. The integrated unit can be realized in the form of hardware or in the form of a software functional unit.

[0142] It should be noted that the structure of the electronic device described above is only illustrative, and based on different application scenarios, other physical structures can also be included, and the physical structure of the electronic device is not limited herein.

[0143] In the above embodiments, the description of each embodiment focuses on different aspects, and the parts not described or recorded in a certain embodiment can be referred to the relevant description of other embodiments.

[0144] The chip system is applied to an electronic device, and the chip system includes one or more processors configured to invoke computer instructions to enable the electronic device to implement the steps in the above various method embodiments.

[0145] The computer readable storage medium stores a computer program, and the computer program is executed by a processor to implement the steps in the above various method embodiments.

[0146] The computer program product, when running on an electronic device, enables the electronic device to implement the steps in the above various method embodiments.

[0147] The integrated modules / units, if realized in the form of software function units and sold or used as independent products, can be stored in a computer readable storage medium. Based on this understanding, all or part of the processes in the above embodiments can also be completed by a computer program instructing related hardware, and the computer program can be stored in a computer readable storage medium. The computer program, when executed by a processor, can implement the steps in the above various method embodiments. The computer program includes computer program code, which can be in the form of source code, object code, executable files or some intermediate forms. The computer readable medium can include any entity or device capable of carrying computer program code, recording medium, U disk, mobile hard disk, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signal, telecommunication signal and software distribution medium, etc.

[0148] The above apparatus, electronic device, chip system, computer storage medium and computer program product provided by the embodiments of the present application are all used to execute the above methods, and thus the beneficial effects they can achieve can refer to the beneficial effects of the above methods, which will not be repeated here.

[0149] It should be understood that the above description is only to help the person skilled in the art better understand the embodiments of the present application, and is not intended to limit the scope of the embodiments of the present application. Various equivalent modifications or changes can be made to the embodiments of the above-described detection method according to the above-described examples given by those skilled in the art, for example, some steps in each of the above-described embodiments of the detection method can be unnecessary, or some steps can be newly added, etc. Or a combination of any two or more embodiments. Such modifications, changes or combinations also fall within the scope of the embodiments of the present application.

[0150] It should also be understood that the ways, cases, categories and divisions of embodiments in the present application are only for the convenience of description and should not be construed as special limitations. The features in various ways, categories, cases and embodiments can be combined without contradiction.

[0151] It should also be understood that in various embodiments of the present application, the terms and / or descriptions of different embodiments are consistent and can be mutually referred to if there is no special description and no logical conflict. The technical features in different embodiments can be combined to form new embodiments according to their inherent logical relationship.

[0152] Those of ordinary skill in the art can realize that the units and algorithm steps of the examples described in combination with the embodiments disclosed herein can be realized in electronic hardware or a combination of computer software and electronic hardware. Whether the functions are realized in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of the present application.

[0153] In the embodiments provided in the present application, it should be understood that the disclosed apparatus / network device and method can be implemented in other ways. For example, the apparatus / network device embodiments described above are only schematic. The division of the modules or units is only a logical function division, and there can be another division in actual implementation. For example, a plurality of units or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the coupling or direct coupling or communication connection between the units shown or discussed can be indirect coupling or communication connection through some interface, device or unit, and can be electrical, mechanical or in other forms.

[0154] The units described as separate components can or can not be physically separated, and the components shown as units can or can not be physical units, i.e. they can be located in one place, or distributed on a plurality of network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the embodiments of the present application.

[0155] The above-described embodiments are only used to illustrate the technical solutions of the present application, rather than limit them; although the present application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that they can still modify the technical solutions recorded in the foregoing embodiments, or make equivalent replacements for some technical features; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the embodiments of the present application, and should be included in the protection scope of the present application.

[0156] Finally, it should be noted that the above-described is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto, any change or replacement within the technical scope disclosed by the present application should be covered in the protection scope of the present application. Therefore, the protection scope of the present application should be subject to the protection scope of the claims.

Claims

1. A method for synchronizing differential data among blockchain nodes, characterized in that, The method includes: Based on the block height difference of the blockchain, multiple blocks to be synchronized are obtained from at least one peer node; During the data processing phase, multiple blocks to be synchronized are processed in parallel; the parallel data processing includes executing transactions of multiple blocks to be synchronized in parallel. During the data update phase, based on the data processing results of each block to be synchronized, each world state after the execution of each block to be synchronized is updated in parallel. The data processing phase and the data update phase in one round are used to complete the parallel synchronization processing of multiple blocks to be synchronized; the differential synchronization process of blockchain nodes includes a first control flow and a second control flow, and the method further includes: During the execution of the first control flow, all blocks to be synchronized sent by one or more peer nodes are received and stored; based on the data exchange between the first control flow and the second control flow, during the execution of the second control flow, a first number of blocks to be synchronized are obtained from all the blocks to be synchronized, and parallel synchronization processing is performed on the first number of blocks to be synchronized; after the first number of blocks to be synchronized is synchronized, parallel synchronization processing is performed on a second number of blocks to be synchronized from all the blocks to be synchronized, until all the blocks to be synchronized are synchronized; the second number is less than or equal to the first number.

2. The method according to claim 1, characterized in that, Each block to be synchronized includes a block header and a block body; the data processing stage includes a block header stage and a block body stage; the parallel data processing of multiple blocks to be synchronized includes: In the block header stage, multiple block headers are processed in parallel. After the block header processing is completed, in the block body stage, multiple block bodies are processed in parallel to obtain the data processing result for each block to be synchronized.

3. The method according to claim 2, characterized in that, The parallel data processing of multiple block headers includes: Multiple block headers are verified in parallel, and the reverse mapping of each block header is calculated in parallel after the verification is successful.

4. The method according to claim 2, characterized in that, The parallel data processing of multiple blocks to obtain data processing results for each block to be synchronized includes: Parallel verification is performed on multiple blocks to determine the transaction data of each block, wherein the transaction data includes the number of transactions and the identifier of each transaction; Based on the identifier and the quantity, the transactions of multiple blocks are executed in parallel to obtain the transaction execution result corresponding to each block to be synchronized; Based on the transaction execution result corresponding to each block to be synchronized, the global state after each block to be synchronized is calculated in parallel, and the global state is used as the data processing result of each block to be synchronized.

5. The method according to claim 1, characterized in that, The data update phase includes a hash phase; The step of updating each world state in parallel after the completion of each of the synchronized blocks, based on the data processing results of each synchronized block, includes: During the hashing phase, based on each data processing result, the state data in the hash table after each block to be synchronized is updated in parallel. The state data includes the account address and storage location; the world state includes the state data of the hash table.

6. The method according to claim 5, characterized in that, The data update phase further includes a state tree phase; after the hash phase, the method further includes: During the state tree stage, based on the state data of the hash table, the hash value of the root node corresponding to each block to be synchronized is calculated in parallel to obtain the state root hash corresponding to each block to be synchronized.

7. The method according to claim 6, characterized in that, The data update phase also includes a phase for calling the tracking index; After the state number phase, the method further includes: During the call tracing indexing phase, transaction execution process data for multiple blocks to be synchronized are updated in parallel in a temporary table based on each state root hash. For multiple blocks to be synchronized, a first inverse index is created in parallel for the transaction execution process data of each block to be synchronized; the first inverse index is used to record and track the transaction execution process data.

8. The method according to claim 7, characterized in that, The data update phase further includes: a historical indexing phase, a log indexing phase, and a transaction lookup phase; after the call tracing indexing phase, the method further includes: During the historical indexing phase, based on the change set data after each block to be synchronized is executed in parallel in the blockchain, a historical index of the account and storage corresponding to each block to be synchronized is created in parallel. During the log indexing phase, based on the data in the log table after each block to be synchronized has been executed in parallel in the blockchain, a second reverse index of the event log corresponding to each block to be synchronized is created in parallel. During the transaction lookup phase, for the block bodies of multiple blocks to be synchronized and the transaction data of multiple blocks to be synchronized in the transaction table, a mapping between the transaction data and the transaction hash of each block to be synchronized is created in parallel.

9. The method according to any one of claims 1 to 8, characterized in that, The method further includes: During the parallel synchronization of the first and second number of blocks to be synchronized, the system continues to receive and store all blocks to be synchronized in the next stage sent by one or more peer nodes based on the first control flow.

10. An electronic device, characterized in that, The electronic device includes at least one processor and a memory communicatively connected to the at least one processor; wherein the memory stores a computer program executed by the at least one processor to enable the at least one processor to perform the method of any one of claims 1 to 9.

11. A chip system, characterized in that, The chip system is applied to an electronic device, the chip system including one or more processors, the one or more processors being used to invoke computer instructions to cause the electronic device to perform the method as described in any one of claims 1 to 9.

12. A computer program product, characterized in that, When the computer program product is run on an electronic device, it causes the electronic device to perform the method of any one of claims 1 to 9.

Citation Information

Patent Citations

  • Data processing method and device based on block chain system

    CN110008206A

  • Block chain total data synchronization method and device, equipment, medium and product

    CN118535640A