Block synchronization processing method and device, electronic equipment and storage medium

Abstract

The invention discloses a block synchronization processing method and device, electronic equipment and a storage medium. The method comprises the following steps: receiving a block synchronization request sent by a target node; wherein the block synchronization request comprises block fragmentation strategy information; performing data fragmentation on the to-be-synchronized block according to the block fragmentation strategy information to obtain a fragmentation data set, and determining to-be-sent fragmentation data from the fragmentation data set; sending to-be-sent fragmented data to a target node at a target speed according to storage information of a fragmented buffer area in the target node, so that the target node recombines each fragmented data to obtain a to-be-synchronized block after receiving the fragmented data sent by each consensus node, and the block synchronization operation of the target node is completed according to the to-be-synchronized block. According to the method, the operation efficiency of the block chain network can be improved, and the method can be widely applied to other technical fields related to the Internet technology, such as cloud computing, Internet of Vehicles and the like.

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and in particular to a method, device, electronic device and storage medium for processing block synchronization. Background Art

[0002] Blockchain is a new application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanism, encryption algorithm, etc. Usually, the blockchain nodes contained in the blockchain network use consensus protocols to ensure the consistency of the distributed ledgers maintained by each node. However, when a new node joins the blockchain network, the block data in the distributed ledger maintained by the new node lags behind the normal nodes in the blockchain network and cannot participate in the normal consensus process. Therefore, it is necessary to synchronize the block data of the new node with the block data of the normal node to maintain consistency between them.

[0003] In related blockchain technologies, the method of block synchronization is that a node randomly requests block data from one or more nodes in the blockchain in order according to the block height to achieve block synchronization. However, this method requires the new node to continuously send the block height and block number that need to be synchronized to the normal node to request the corresponding synchronization data, resulting in low efficiency of block synchronization. Summary of the invention

[0004] In view of this, an embodiment of the present invention provides a block synchronization processing method, device, electronic device and storage medium, which can speed up the block data sending speed of the consensus node, thereby improving the block synchronization efficiency when a new node joins the blockchain network.

[0005] An aspect of an embodiment of the present invention provides a method for processing block synchronization, comprising the following steps:

[0006] Receive a block synchronization request sent by a target node; wherein the block synchronization request includes block sharding strategy information;

[0007] Performing data sharding on the block to be synchronized according to the block sharding strategy information to obtain a sharding data set, and determining the sharding data to be sent from the sharding data set;

[0008] According to the storage information of the shard buffer in the target node, the shard data to be sent is sent to the target node at the target speed, so that after receiving the shard data sent by each consensus node, the target node reorganizes each shard data to obtain the block to be synchronized, and completes the block synchronization operation of the target node according to the block to be synchronized;

[0009] The shard buffer is used to store each shard data received by the target node.

[0010] On the other hand, an embodiment of the present invention further provides a block synchronization processing device, including:

[0011] The first module is used to receive a block synchronization request sent by a target node; wherein the block synchronization request includes block sharding strategy information;

[0012] The second module is used to perform data sharding on the block to be synchronized according to the block sharding strategy information to obtain a sharding data set, and determine the sharding data to be sent from the sharding data set;

[0013] The third module is used to send the to-be-sent fragmented data to the target node at a target speed according to the storage information of the fragmented buffer in the target node;

[0014] The shard buffer is used to store each shard data received by the target node.

[0015] Optionally, the second module is specifically used for:

[0016] Acquire the height of the block to be synchronized from the block sharding strategy information, and then determine the block to be synchronized according to the height of the block to be synchronized;

[0017] According to the block sharding strategy information, determine the number of fragments to be sharded and fragment attribute information; wherein the fragment attribute information is used to characterize the consensus node to which each shard data belongs;

[0018] According to the number of fragments and the fragment attribute information, data fragmentation is performed on the block to be synchronized to obtain a fragmented data set;

[0019] According to the arrangement order of the consensus nodes in the target blockchain, the shard data to be sent in the shard data sets of each consensus node is determined.

[0020] Optionally, the second module is specifically used for:

[0021] According to the block sharding strategy information, the total number of the consensus nodes and the current block height of the consensus nodes are obtained from the target blockchain;

[0022] Determine the number of fragments to be sharded according to the total number of the consensus nodes;

[0023] According to the block sharding strategy information, each of the sharding data is configured as a sharding header and a sharding content, and used as the fragment attribute information; wherein the sharding header is used to mark the segment order to which the sharding data belongs in the sharding data set; the segment order corresponds to the node order of the consensus node in the target blockchain.

[0024] Optionally, the third module is specifically used for:

[0025] Determine the push speed of the consensus node for the shard data according to the storage information of the shard buffer in the target node, as the target speed;

[0026] Determine the segmentation order of the shard data to be sent by the current consensus node according to the node order of the consensus node in the target blockchain;

[0027] According to the segmentation order, the corresponding sliced ​​data to be sent are determined from the sliced ​​data set, and the sliced ​​data to be sent are sent to the target node according to the target speed.

[0028] Optionally, the third module is specifically used for:

[0029] According to the block sharding strategy information, the sharding buffer is configured; wherein the sharding buffer includes a plurality of sharding buffer queues or one-way linked lists, each of which stores sharding data sent by a corresponding consensus node in the target blockchain;

[0030] According to the amount of shard data stored in the shard buffer queue or the one-way linked list, a target speed at which the corresponding consensus node sends the shard data is generated.

[0031] Optionally, the third module is specifically used for:

[0032] Configuring a static array as the storage capacity of the ring buffer queue;

[0033] Configuring the starting buffer position and the ending buffer position of the circular buffer queue to be the same position;

[0034] A read pointer and a write pointer of the circular buffer queue are configured, wherein the read pointer is used to indicate a position when fragment data is read from the circular buffer queue, and the write pointer is used to indicate a position when fragment data is written to the circular buffer queue.

[0035] Optionally, the third module is specifically used for:

[0036] Obtaining the real-time positions of the read pointer and the write pointer;

[0037] Determining the data storage capacity of the ring buffer queue according to the real-time positions of the read pointer and the write pointer;

[0038] According to the data storage capacity of the ring buffer queue, the target speed is accelerated, decelerated or maintained at the original speed;

[0039] Among them, when the read pointer and the write pointer of the circular buffer queue are at the same position, it indicates that the data storage capacity in the circular buffer queue is empty; when the write pointer of the circular buffer queue is at the next pointer position adjacent to the read pointer, it indicates that the data storage capacity in the circular buffer queue is full.

[0040] Optionally, the third module is specifically used for:

[0041] Obtaining the data storage capacity of the ring buffer queue, and calculating the data storage ratio between the data storage capacity and the total storage capacity of the ring buffer queue;

[0042] When the data storage ratio is less than a first threshold, the target speed is accelerated or maintained at the original speed;

[0043] When the data storage ratio is greater than or equal to the first threshold and less than a second threshold, decelerating the target speed;

[0044] When the data storage ratio is greater than the second threshold, the corresponding consensus node is suspended from sending the shard data.

[0045] On the other hand, an embodiment of the present invention further provides a block synchronization processing method, including:

[0046] Generate a block synchronization request according to the new node joining rule of the target blockchain; wherein the block synchronization request includes block sharding strategy information;

[0047] Sending the block synchronization request to each consensus node in the target blockchain, so that each consensus node executes the above block synchronization processing method after receiving the block synchronization request;

[0048] Receive the shard data sent by each consensus node, reorganize each shard data to obtain the block to be synchronized, and complete the block synchronization operation of the target node according to the block to be synchronized.

[0049] On the other hand, an embodiment of the present invention further provides a block synchronization processing device, including:

[0050] The fourth module is used to generate a block synchronization request according to the new node joining rule of the target blockchain; wherein the block synchronization request includes block sharding strategy information;

[0051] A fifth module is used to send the block synchronization request to each consensus node in the target blockchain, so that each consensus node executes the block synchronization processing method according to any one of claims 1 to 8 after receiving the block synchronization request;

[0052] The sixth module is used to receive the shard data sent by each consensus node, reorganize each of the shard data to obtain the block to be synchronized, and complete the block synchronization operation of the target node according to the block to be synchronized.

[0053] Optionally, the sixth module is specifically used for:

[0054] Obtain shard data at the same block height from each consensus node;

[0055] Obtaining the slice header and slice content of each of the slice data;

[0056] After sorting the shard data of the same block height according to the shard header, the shard contents of each shard data are reorganized in the sorting order to obtain the block to be synchronized.

[0057] Optionally, the device further comprises:

[0058] The seventh module is used to:

[0059] After sending a block synchronization request to each consensus node in the target blockchain, obtaining the connection confirmation information sent back by the corresponding consensus node in real time;

[0060] When no connection confirmation information of the consensus node is received within the preset response time, the consensus node is added to the list of nodes to be connected;

[0061] A new block sharding strategy is created and new block sharding strategy information is generated, and then a block synchronization request is reissued to the consensus node in the list of nodes to be connected until a connection between the target node and the consensus node is established.

[0062] On the other hand, an embodiment of the present invention further provides an electronic device, including a processor and a memory;

[0063] The memory is used to store programs;

[0064] The processor executes the program to implement the above block synchronization processing method.

[0065] On the other hand, an embodiment of the present invention further provides a computer-readable storage medium, wherein the storage medium stores a program, and the program is executed by a processor to implement the aforementioned processing method for block synchronization.

[0066] The embodiment of the present invention also discloses a computer program product or a computer program, which includes a computer instruction stored in a computer-readable storage medium. A processor of a computer device can read the computer instruction from the computer-readable storage medium, and the processor executes the computer instruction, so that the computer device executes the processing method of block synchronization as described above.

[0067] In the embodiment of the present invention, when the target node joins the target blockchain and generates a block synchronization demand, a block synchronization request is generated according to the new node joining rule of the target blockchain, and the block synchronization request is sent to each consensus node in the target blockchain. Each consensus node performs data sharding on the block to be synchronized according to the block sharding strategy information in the block synchronization request to obtain a sharding data set, and determines the sharding data to be sent from the sharding data set. The embodiment of the present invention adopts a method of sending block data in shards, which saves the process in the prior art that the target node needs to repeatedly send synchronization requests to other consensus nodes to obtain synchronization data when performing block synchronization, and only needs to send a block Block synchronization request can make the consensus node continuously send shard data, which helps to improve the block synchronization efficiency; in addition, the embodiment of the present invention sends the shard data to be sent to the target node at the target speed according to the storage information of the shard buffer in the target node, so that after the target node receives the shard data sent by each consensus node, it reorganizes each shard data to obtain the block to be synchronized, and completes the block synchronization operation of the target node according to the block to be synchronized. The embodiment of the present invention controls the transmission speed based on the storage status of the shard buffer, which helps to avoid block congestion in the operation of the blockchain network, helps to appropriately increase the transmission speed of the shard data, and further improves the operation efficiency of the blockchain network. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0069] Figure 1 A flowchart of a block synchronization implementation solution in the prior art;

[0070] Figure 2A A schematic diagram of the structure of a blockchain node system provided by an embodiment of the present invention;

[0071] Figure 2B A schematic diagram of a blockchain structure provided by an embodiment of the present invention;

[0072] Figure 2C A schematic diagram of a process of generating a new block provided by an embodiment of the present invention;

[0073] Figure 3A A schematic diagram of a scenario of data interaction in a block synchronization processing system provided by an embodiment of the present invention;

[0074] Figure 3BA schematic diagram of a streaming protocol preparation process provided by an embodiment of the present invention;

[0075] Figure 4 A flowchart of a block synchronization processing method provided by an embodiment of the present invention;

[0076] Figure 5 A schematic diagram of slicing and sending a synchronization block according to a streaming protocol provided by an embodiment of the present invention;

[0077] Figure 6 A schematic diagram of a process of block data sharding provided by an embodiment of the present invention;

[0078] Figure 7 A schematic diagram of the structure of a ring buffer provided by an embodiment of the present invention;

[0079] Figure 8 A schematic diagram of a process flow for adjusting the push speed of sharded data provided by an embodiment of the present invention;

[0080] Fig. 9 A flowchart of another block synchronization processing method provided by an embodiment of the present invention;

[0081] Fig.10 A schematic diagram of a process for a target node to reorganize shard data according to an embodiment of the present invention;

[0082] Fig.11 A modular schematic diagram of a block synchronization processing device provided by an embodiment of the present invention;

[0083] Fig.12 A modular schematic diagram of another block synchronization processing device provided by an embodiment of the present invention;

[0084] Fig.13 A schematic diagram of the structure of an electronic device provided by an embodiment of the present invention;

[0085] Fig.14 A schematic diagram of a computer system structure block diagram of an electronic device implementing an embodiment of the present application is provided in accordance with an embodiment of the present invention. DETAILED DESCRIPTION

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

[0087] It should be understood that in the description of the embodiments of the present invention, the meaning of multiple (or multiple) is more than two, greater than, less than, and exceeding are understood to exclude the number itself, and above, below, and within are understood to include the number itself. If there is a description of "first", "second", etc., it is only used for the purpose of distinguishing technical features, and cannot be understood as indicating or implying relative importance or implicitly indicating the number of the indicated technical features or implicitly indicating the order of the indicated technical features.

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

[0089] Before further describing the embodiments of the present invention in detail, the nouns and terms involved in the embodiments of the present invention are described. The nouns and terms involved in the embodiments of the present invention are applicable to the following interpretations:

[0090] Blockchain: A distributed ledger technology in the field of information technology, generally composed of consensus, transaction blocks, state data storage, and cryptographic identity security. Since the ledger is stored in a distributed manner and the blocks are agreed upon, it has the characteristics of being tamper-proof, traceable, and jointly maintainable.

[0091] Smart contract: A program that runs on the blockchain. Unlike ordinary programs, smart contracts must ensure that the results of running in every node of the blockchain network are exactly the same, so that any node can verify whether the results of the smart contract execution in the block are correct.

[0092] Blockchain node: usually refers to the computer in the blockchain network, that is, any computer (including mobile phones, etc.) connected to the blockchain network is called a node.

[0093] Supernode: usually refers to a node in some blockchain networks that has higher rights and interests or has obtained some kind of certification, thus obtaining a higher level of authority than other nodes. Supernodes are usually more credible and usually have more voting rights in the blockchain network.

[0094] In related technologies, in order to ensure the continuity of blocks, the block synchronization of blockchain nodes often selects a synchronization node and synchronizes new nodes in sequence according to their block heights. The specific process can be referred to Figure 1 ,include:

[0095] 1. When a new node joins the blockchain network, the node manager module of the new node can broadcast its own block height to other nodes in real time. At the same time, the new node can receive node messages from other nodes through the node manager module.

[0096] 2. From these node messages, the new node can obtain the current block height of each consensus node.

[0097] 3. When the block height of the new node is the latest block height, the new node does not need to perform block synchronization. When the block height of the new node is lower than the latest height of any node on the blockchain, block synchronization is required and the number of blocks that the new node needs to synchronize is calculated.

[0098] 4. After obtaining the number of blocks that need to be synchronized, the new node can select any consensus node or a super node and send a block synchronization request to the consensus node or super node.

[0099] 5. Based on the block synchronization request, the selected consensus node or super node sends the synchronization block to the new node.

[0100] 6. After receiving the synchronization block sent by the consensus node or super node, the new node can verify the block transaction data.

[0101] 7. After successful verification, the new node can complete block synchronization and submit the synchronized blocks to the local database.

[0102] As can be seen from the above, in the block synchronization method in the related art, when the new node lags behind many blocks, since the blocks need to be synchronized before they are placed, a large number of lagging blocks may be generated during synchronization. These lagging blocks will greatly reduce the efficiency of block processing and pushing.

[0103] The block synchronization method provided in the embodiment of the present invention can be applied to a blockchain network, wherein the blockchain network may include multiple nodes, and a communication connection can be established between each of the multiple nodes.

[0104] It is understandable that the above-mentioned node connection does not limit the connection method, and can be directly or indirectly connected through wired communication, directly or indirectly connected through wireless communication, or through other connection methods, which are not limited in this application.

[0105] Combine the following Figure 2A-2C The blockchain network provided by an embodiment of the present invention is schematically illustrated.

[0106] See also Figure 2AThe data sharing system shown, the data sharing system 100 refers to a system for sharing data between nodes, and the data sharing system may include multiple nodes such as 101a, 101b, 101c and 101d. 101a, 101b, 101c and 101d can refer to each client in the data sharing system. 101a, 101b, 101c and 101d can receive input information when performing normal work, and maintain the shared data in the data sharing system based on the received input information. In order to ensure the information intercommunication within the data sharing system, there can be an information connection between each node in the data sharing system, and the nodes can transmit information through the above information connection. For example, when any node in the data sharing system receives input information, other nodes in the data sharing system can obtain the input information according to the consensus algorithm, and store the input information as data in the shared data, so that the data stored on all nodes in the data sharing system are consistent.

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

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

[0109] Table 1

[0110] Each node in the data sharing system stores the same blockchain. The blockchain consists of multiple blocks, see Figure 2B The blockchain consists of multiple blocks. The genesis block includes a block header and a block body. The block header stores the input information characteristic value, version number, timestamp and difficulty value, and the block body stores the input information; the next block of the genesis block takes the genesis block as the parent block, and the next block also includes a block header and a block body. The block header stores the input information characteristic value of the current block, the block header characteristic value, version number, timestamp and difficulty value of the parent block, and so on, so that the block data stored in each block in the blockchain is associated with the block data stored in the parent block, ensuring the security of the input information in the block.

[0111] When generating each block in the blockchain, see Figure 2CWhen the node where the blockchain is located receives the input information, it verifies the input information. After the verification is completed, the input information is stored in the memory pool and the hash tree used to record the input information is updated. After that, the update timestamp is updated to the time when the input information is received, and different random numbers are tried to calculate the eigenvalue multiple times so that the calculated eigenvalue can satisfy the following formula:

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

[0113] Among them, SHA256 is the eigenvalue algorithm used to calculate the eigenvalue; version (version number) is the version information of the relevant block protocol in the blockchain; prev_hash is the block header eigenvalue of the parent block of the current block;

[0114] merkle_root is the characteristic value of the input information; ntime is the update time of the update timestamp; nbits is the current difficulty, which is a fixed value within a period of time and is determined again after exceeding the fixed time period; x is a random number; TARGET is the characteristic value threshold, which can be determined based on nbits.

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

[0116] It should be understood that smart contracts can be run on the nodes of the data sharing system. Smart contracts are code implementations that are executed when certain conditions are met. Developers can define the contract logic through programming languages ​​and publish it to the blockchain (smart contract registration). According to the logic of the contract terms, they call keys or other events to trigger execution and complete the contract logic. At the same time, they also provide the function of upgrading and canceling smart contracts.

[0117] It can be understood that a block is a data packet that carries transaction data (i.e., transaction business) on the blockchain network. It is a data structure marked with a timestamp and the hash value of the previous block. The block is verified by the network's consensus mechanism and the transactions in the block are determined.

[0118] It is understandable that the processing method for block synchronization provided in the embodiment of the present invention can be applied to any computer device with data processing and computing capabilities, and this computer device can be various types of terminals or servers. When the computer device in the embodiment of the present invention is a server, the server is an independent physical server, or a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, CDN (Content Delivery Network), and big data and artificial intelligence platforms. Optionally, the terminal is a smart phone, a tablet computer, a laptop computer, a desktop computer, etc., but is not limited to this.

[0119] It should be further explained that the terminals involved in the embodiments of the present invention include but are not limited to smart phones, computers, intelligent voice interaction devices, smart home appliances, vehicle terminals and aircraft, etc. The embodiments of the present invention can be applied to various scenarios, including but not limited to cloud technology, artificial intelligence, smart transportation and assisted driving, etc.

[0120] It should be understood that the consensus node in the embodiment of the present application can be any existing node in the blockchain network. The target node is any newly added node in the blockchain network. Therefore, the embodiment of the present application can refer to any new node newly connected to the blockchain network as a target node, and any existing node in the blockchain network can be a consensus node.

[0121] For ease of understanding, further reference is made to Figure 3A and Figure 3B , Figure 3A is a schematic diagram of an application scenario of a block synchronization processing method according to an embodiment of the present invention, and Figure 3B Schematic diagram of the preparation process of the push protocol in the embodiment of the present invention. Figure 3A The target node 101 shown can be any node newly connected to the blockchain network (such as Figure 2A 101a), or a node that is temporarily disconnected from the blockchain network due to a fault and then reconnected, and the consensus node 102 is any one or more nodes in the blockchain network (multiple nodes such as Figure 2A101b, 101c and 101d in the protocol). The consensus node 102 may include any one or more nodes that access the blockchain network earlier than the target node, or may include a super node that has higher rights and interests than other consensus nodes, or has a higher level of authority, or has obtained some kind of certification and has a higher credibility. Both the target node 101 and the consensus node 102 may have their own node manager module. When the target node 101 establishes a connection with other nodes, the node manager module will first prepare the push protocol. After the push protocol is configured, it will send a connection request to all consensus nodes in the protocol. If the target node is successfully connected to the consensus node, the consensus node can send data to the target node according to the content of the protocol. If the connection fails, the consensus node that failed to connect will be kicked out of the list, and the protocol will be re-prepared before trying to connect to the consensus node. After the connection is successful, since the target node may not have participated in the consensus before the blockchain network, the block height of the target node may be inconsistent with the other block heights of the blockchain. When it is determined that its own block height is inconsistent and block synchronization is required, the target node can send a synchronization request to other consensus nodes in the blockchain through the established push protocol. The consensus node can send the blocks to be synchronized to the target node according to the push protocol. The target node receives the blocks to be synchronized, integrates them, and finally completes the synchronization of the blocks.

[0122] It should be noted that in Figure 3B In the process, the node manager can be responsible for collecting the information of the consensus nodes that can synchronize data. The information of the consensus node can mainly include the current block height of the consensus node, the synchronization stability coefficient of the node, and the node status.

[0123] The push protocol can be used when the consensus node and the new node are handshaking to establish a connection. When the new node takes out a batch of consensus nodes in normal state from the node manager, it needs to prepare the push protocol data before initiating a connection establishment request to the consensus node. The push protocol may include but is not limited to the starting height of the synchronization block (such as Figure 3B The total number of nodes participating in the push (such as Figure 3B nodes in the ) and the current consensus node is responsible for pushing the shard index (such as Figure 3B in the index).

[0124] Different from TCP connection establishment, Figure 3A The push stream connection between the target node 101 and the consensus node 102 can be established on the basis of the TCP protocol. Therefore, the consensus node of the present invention and the new node do not need to go through three-way handshake and other operations, and only need to directly send the push stream protocol to perform block synchronization processing. After receiving the push stream protocol, the consensus node can send block data to the new node according to the push stream protocol.

[0125] For further information, please refer to Figure 4 , Figure 4 The present invention provides a flowchart of a block synchronization processing method provided in an embodiment of the present invention. The method can be executed by any one or more consensus nodes including super nodes in the blockchain network.

[0126] For ease of understanding, the embodiment of the present invention takes the method executed by any consensus node as an example for explanation. The block synchronization processing method may at least include the following steps S401 to S405.

[0127] S401. Receive a block synchronization request sent by a target node; wherein the block synchronization request includes block sharding strategy information.

[0128] It should be noted that the target node can be any node newly connected to the blockchain network, or a node that is temporarily disconnected and reconnected to the blockchain network. The block synchronization request indicates a request sent to the consensus node after the target node determines that block synchronization is required. The block sharding strategy information can be a collection of information in the push protocol that represents the block height of the block to be synchronized, information that represents the number of nodes participating in the synchronization, and information that represents the sequence number of the shards sent by the consensus node. The block synchronization request can be a request for block synchronization initiated by the target node based on the difference between the block parameters of the consensus node and its own block parameters. When the consensus node receives the block synchronization request sent by the target node through the protocol, it can also receive block sharding strategy information such as information representing the block height, information representing the number of nodes participating in the synchronization, and information representing the sequence number of the shards sent by the consensus node.

[0129] It should be understood that, taking the distributed system as a blockchain system as an example, a blockchain can be formed by multiple nodes (any form of computing devices connected to the network, such as servers and target object terminals) and clients. In a distributed system, any machine such as a server and a terminal can join and become a node, and a node can include a hardware layer, an intermediate layer, an operating system layer, and an application layer.

[0130] It is understandable that the functions involved in each node in the blockchain system may include:

[0131] 1) Routing: a basic function of a node, used to support communication between nodes.

[0132] In addition to the routing function, the node can also have the following functions:

[0133] 2) Applications, which are deployed in the blockchain to implement specific businesses (such as transactions) according to actual business needs, record data related to the implementation of functions to form record data, carry digital signatures in the record data to indicate the source of the task data, and send the record data to other nodes in the blockchain system for other nodes to add the record data to the temporary block when they successfully verify the source and integrity of the record data.

[0134] For example, the services implemented by the application include:

[0135] 2.1) Wallet, used to provide the function of trading digital assets, including initiating transactions (i.e., sending the transaction record of the current transaction to other nodes in the blockchain system. After successful verification by other nodes, as a response to acknowledge the validity of the transaction, the transaction record data is stored in the temporary block of the blockchain; of course, the wallet also supports querying the remaining digital assets in the electronic currency address.

[0136] 2.2) Shared ledger, used to provide functions such as storage, query and modification of account data, and send the record data of the operation on the account data to other nodes in the blockchain system. After other nodes verify the validity, as a response to acknowledge the validity of the account data, the record data will be stored in a temporary block, and a confirmation can also be sent to the node that initiated the operation.

[0137] 2.3) Smart contracts are computerized protocols that can execute the terms of a contract. They are implemented by deploying code on a shared ledger that is executed when certain conditions are met. The code is used to complete automated transactions based on actual business needs, such as querying the logistics status of the goods purchased by the buyer and transferring the buyer's electronic currency to the merchant's address after the buyer signs for the goods. Of course, smart contracts are not limited to executing contracts for transactions, but can also execute contracts for processing received information.

[0138] 3) Blockchain, including a series of blocks that are connected to each other in the order of their generation. Once a new block is added to the blockchain, it will not be removed. The block records the record data submitted by the nodes in the blockchain system.

[0139] In an embodiment of the present invention, when a target node is added to a blockchain network or a target node is reconnected to a blockchain network, the target node may first prepare a data push protocol, which may include the number of consensus nodes, the index value of each consensus node, and policy information such as the height of the block to be synchronized. After the push protocol is configured, the new node may send a block synchronization request to all consensus nodes in the protocol, and send the push protocol to all consensus nodes at the same time. Based on the communication connection between the consensus node and the target node, the consensus node may receive a block synchronization request from the target node and obtain block sharding strategy information.

[0140] S402, sharding the block to be synchronized according to the block sharding strategy information to obtain a sharding data set, and determining the sharding data to be sent from the sharding data set.

[0141] It should be noted that, in an embodiment of the present invention, the block to be synchronized may be the block height difference between the target node and any consensus node in the blockchain network. The block height difference may include a section of block data formed by the node consensus process in which the target node did not participate before accessing the blockchain network. The shard data set is a set of several shard data obtained by the consensus node in a certain sharding manner. The shard data to be sent may include the shard data sorted according to a certain strategy in the shard data set. After receiving the block sharding strategy information from the target node, the consensus node may determine the shard data set according to the number of nodes in the block sharding strategy information and the block height to be synchronized. The consensus node determines the shard data to be sent to the target node in each consensus node based on the information representing the shard sequence number that the consensus node should send.

[0142] In the embodiment of the present invention, the consensus node can determine the number of consensus nodes according to the block sharding strategy information sent by the target node. According to the number of consensus nodes, the block to be synchronized is sharded to obtain a sharding data set, and according to the segmentation information obtained from the strategy information, the sharding data to be sent can be determined from the sharding data set.

[0143] It is understandable that the number of consensus nodes in the block sharding strategy information in the embodiment of the present invention can be any value. After the new node establishes a connection with the consensus node, the push protocol between the new node and the consensus node can also be determined, and correspondingly, the number of consensus nodes that can be synchronized and the number of shards of the blocks to be synchronized are determined.

[0144] It is easy to understand that the transmission protocol of the shard data between the target node and the consensus node of the embodiment of the present invention can adopt the push stream protocol. The push stream protocol is based on the TCP protocol. Therefore, the push stream protocol no longer needs to go through operations such as three-way handshakes. The target node only needs to directly send the push stream protocol to the consensus node. After receiving the push stream protocol, the consensus node begins to send the shard data to the target node according to the push stream protocol. The embodiment of the present invention adopts the block shard sending method to send the block data corresponding to the block height difference between the consensus node and the new node to the new node in blocks, which can save the new node from repeatedly sending synchronization requests to obtain synchronization data, and help improve the efficiency of block synchronization.

[0145] S403. According to the storage information of the shard buffer in the target node, the shard data to be sent is sent to the target node at the target speed, so that after receiving the shard data sent by each consensus node, the target node reorganizes each shard data to obtain the block to be synchronized, and completes the block synchronization operation of the target node according to the block to be synchronized.

[0146] It should be noted that after the consensus node receives the synchronization request from the target node, it will start to push the block's shard data to the target node in a certain order according to the content defined by the protocol established when the nodes are connected. When multiple consensus points push shard data to the target node at the same time, the target node will reorganize the shard data at a speed lower than the speed at which the data shards arrive, causing data congestion.

[0147] It should be noted that the target node may include at least one shard buffer, which may be used to store the shard data pushed by each consensus node through the push method defined by the push stream protocol. The target speed may be a better push speed for the consensus node to push the shard data to the shard buffer of the target node. The target speed may be dynamically adjusted according to the amount of information stored in the shard buffer. The amount of information stored in the shard buffer may characterize the difference between the speed at which the target node reassembles the shard data and the speed at which the data shards arrive. Over a period of time, when the amount of information stored in the shard buffer continues to increase, it may be determined that the speed at which the target node reassembles the shard data is lower than the speed at which the data shards arrive. When the amount of information stored in the shard buffer is 0 or is continuously decreasing, it may be determined that the speed at which the target node reassembles the shard data is higher than the speed at which the data shards arrive. When the amount of information stored in the shard buffer remains unchanged, it may be determined that the speed at which the target node reassembles the shard data is equal to the speed at which the data shards arrive.

[0148] In the embodiment of the present invention, since the speed at which the target node reorganizes the shard data is fixed, the consensus node uses the adjusted target speed to push the shard data to the buffer of the target node, so that the shard data can be buffered after entering the target node, without causing data congestion. The consensus node can first send the shard data of each consensus node to the shard buffer of the target node at the target speed, and then the target node can reorganize the shard data of each consensus node in time to obtain the block to be synchronized, and finally complete the synchronization operation of the target node.

[0149] It can be understood that the embodiments of the present invention can control the transmission speed of shard data transmitted by each consensus node based on the storage status of the shard buffer, which can help avoid blockage in the operation of the blockchain network or help to appropriately increase the transmission speed of the block data, and can further improve the operation efficiency of the blockchain network.

[0150] In some possible embodiments, the step of performing data sharding on the synchronized block according to the block sharding strategy information to obtain a sharded data set, and determining the sharded data to be sent from the sharded data set in step S402 may include but is not limited to steps S4021 to S4024.

[0151] Step S4021: Obtain the height of the block to be synchronized from the block sharding strategy information, and then determine the block to be synchronized according to the height of the block to be synchronized.

[0152] It should be noted that in the blockchain network, the block height of the consensus node is the number of times the formula node reaches consensus. In the consensus mechanism, each time the consensus node uploads a data packet, each node of the blockchain will reach a consensus. The data packet corresponding to each consensus is a newly added block, and the number of consensuses can correspond to the height of the newly added block. The height of the block to be synchronized can be the height difference between the consensus node and the target node. The block to be synchronized can be the block data corresponding to the height of the block to be synchronized.

[0153] In an embodiment of the present invention, after the target node joins the blockchain network, the target node can broadcast its own block height to the consensus node in real time, or it can receive the heartbeat sent by other consensus nodes that can synchronize blocks, thereby obtaining the current block height of each consensus node. The target node can calculate the difference between its own block height and the block height of each consensus node based on its own block height and the block height of each consensus node, obtain the height of the block to be synchronized and send it to the formula node. According to the height of the block to be synchronized, the consensus node can extract the corresponding block to be synchronized from the blockchain.

[0154] For example, when the block height of the target node is 2, the corresponding blocks are block0 and block1, and the block height of the consensus node is 10, the corresponding blocks are block0 to block9. Then the consensus node can determine that the height of the block to be synchronized is 8, and correspondingly, the blocks to be synchronized are block2-block9.

[0155] It is understandable that the block height of the target node can be any height N, the corresponding blocks are block0 and blockN-1, and the block height of the consensus node can also be any value Y greater than the block height of the target node.

[0156] Step S4022: Determine the number of fragments to be fragmented and the fragment attribute information according to the block fragmentation strategy information; wherein the fragment attribute information is used to characterize the consensus node to which each fragment data belongs.

[0157] It should be noted that the number of fragments to be sharded can be the number of shards of the synchronization block to be sharded in each consensus node. The fragment attribute information can be used to characterize the specific consensus node to which the shard data belongs among all consensus points.

[0158] In an embodiment of the present invention, the block sharding strategy information may include the number of nodes to be synchronized, and each consensus node may determine the number of shards to be synchronized for the block to be synchronized based on the number of nodes of the common consensus node. The block sharding strategy information may include fragment attribute information representing the consensus node to which the shard data belongs, and each consensus node may determine the consensus node corresponding to each shard data in each shard data based on the fragment attribute information.

[0159] It can be understood that each consensus node in the embodiment of the present invention can correspond one-to-one to each fragment attribute information, and each fragment attribute information can be different from each other.

[0160] Step S4023: Segment the data of the block to be synchronized according to the number of segments and segment attribute information to obtain a segmented data set.

[0161] It should be noted that the number of fragments of the shard data can determine the number of shards of the block to be synchronized, and the fragment attribute information can determine the consensus node corresponding to the shard.

[0162] In an embodiment of the present invention, after the consensus node establishes a streaming protocol with the target node, each consensus node may be set with an index information, and the index information enables the target node to quickly find the corresponding consensus node. Each index information may correspond to a fragment attribute information. Each consensus node may divide the block to be synchronized into a number of shard data equal to the number of fragments to form a shard data set. Each shard data may correspond to a fragment attribute information, and each fragment attribute information may correspond to an index information, and the index information is used to determine the order in which the consensus node sends the shard data.

[0163] Step S4024: Determine the shard data to be sent from the shard data sets of each consensus node according to the arrangement order of the consensus nodes in the target blockchain.

[0164] It should be noted that, in the embodiment of the present invention, each consensus node of the target blockchain may have a node ID, and the consensus nodes may be sorted according to the node ID, and the sorted consensus nodes may be assigned one-to-one corresponding index information, and the index information may be a specific index value. The index value may be determined according to the power of the input and output and the relevant calculation formula. Therefore, according to the index information, the consensus node may determine the shard data to be sent by itself.

[0165] Exemplarily, there are three consensus nodes A, B and C, then the shard data set of the consensus nodes can be composed of 3 shard data. When the order of consensus nodes A, B and C is determined to be B, A, C according to the node ID, then the index information corresponding to nodes B, A and C can be determined to be 1, 2 and 3, then the order of the shard data of the three consensus nodes can be determined, which is specifically B sending the first shard data, A sending the second shard data and C sending the third shard data. Each shard data can be configured with a shard attribute information before sending, and the shard attribute information corresponds to the shard index one by one.

[0166] It should be noted that the IDs of the consensus nodes are different from each other, and the embodiments of the present invention can obtain different sorting methods according to different sorting rules. The specific sorting method and sorting rules are not limited here.

[0167] For example, refer to Figure 5 , Figure 5 A schematic diagram of a method for slicing and sending a synchronization block according to a streaming protocol provided by an embodiment of the present invention. Figure 5 In the consensus reception list maintained by the node manager, the target node builds the block sharding strategy information, that is, the push streaming protocol, and sends the block synchronization request carrying the sharding strategy information to the consensus node. The sharding strategy information includes the height of the block to be synchronized (such as Figure 5 height in), the number of consensus nodes participating in the push (such as Figure 5 nodes in the ) and the current consensus node is responsible for pushing the shard index (such as Figure 5 The block to be synchronized can be determined by the difference between the consensus node and the target node. According to the number of consensus nodes participating in the push, the block to be synchronized can be divided into three shard data segments, and each node is given a corresponding index value. According to this index value, the consensus node participating in the push can send the shard data corresponding to its own index value. Figure 5 In the example, consensus node 1 corresponding to index value 1 can send the first segment of shard data to the target node. Consensus node 2 corresponding to index value 2 can send the second segment of shard data to the target node. Consensus node 3 corresponding to index value 3 can send the third segment of shard data to the target node.

[0168] It can be understood that the embodiment of the present invention describes the process of consensus nodes performing block data sharding based on the sharding strategy. This process uses the block shard sending method, which can save the new node from repeatedly sending synchronization requests to obtain synchronization data, and can help improve the efficiency of block synchronization.

[0169] In some possible embodiments, the step of determining the number of fragments to be fragmented and fragment attribute information according to the block fragmentation strategy information in step S4022 may include but is not limited to steps S40221 to S40223.

[0170] S40221. According to the block sharding strategy information, obtain the total number of consensus nodes and the current block height of the consensus nodes from the target blockchain.

[0171] It should be noted that in a blockchain network, the number of consensus nodes can be all nodes in the blockchain network, or any number of nodes in the network. The specific number of nodes can be determined by the block sharding strategy information, and each consensus node can have the same block height.

[0172] In an embodiment of the present invention, when a target node accesses a blockchain network, the consensus node can determine N consensus nodes from a large number of nodes according to the block sharding strategy information. At the same time, the consensus node can obtain the current block height according to internal data transmission, and obtain the block height of the target node through interaction with the target node. The block to be synchronized can be determined by the current block height of the consensus node and the block height of the target node.

[0173] S40222. Determine the number of fragments to be sharded based on the total number of consensus nodes.

[0174] In an embodiment of the present invention, the consensus nodes may correspond one-to-one to the fragments to be sharded, and the total number of consensus nodes may be the same as the number of fragments to be sharded.

[0175] Exemplarily, when the consensus node determines that there are 4 consensus nodes that have received the synchronization request, the 4 consensus nodes can serve as nodes for sending shards. Since the fragments to be sharded correspond one-to-one to the consensus nodes, the consensus node can determine that the number of fragments to be sharded is 4, that is, the consensus node can divide the block to be sharded into 4 fragments.

[0176] S40223. According to the block sharding strategy information, each shard data is configured as a shard header and shard content, and used as fragment attribute information. The shard header is used to mark the segment order of the shard data in the shard data set; the segment order corresponds to the node order of the consensus node in the target blockchain.

[0177] It should be noted that the shard header of each shard data can be used to mark the segment order of the corresponding shard data in the shard data set. Each shard data can be represented by one or more bytes, and when there are multiple bytes, these bytes can be different. Each segment order corresponds to the node order of the consensus node in the target blockchain.

[0178] In an embodiment of the present invention, each consensus node can configure each shard data into a shard header and shard content according to the block sharding strategy information. The shard header can correspond to the index value corresponding to the consensus node one by one. The shard header can determine the segment order and the node order of the consensus node in the target blockchain.

[0179] For example, when consensus node A is determined to be the first in the target blockchain through the consensus node ID, the shard data sent by node A is the first segment of the block to be shared. It should be noted that the node order of the consensus node on the blockchain can be determined based on the node identity information or node ID. When the node identity information or node ID changes, the node order changes, and correspondingly, the order of subsequent block segments can also change.

[0180] For example, refer to Figure 6 , Figure 6 A schematic diagram of a process flow of block data sharding provided by an embodiment of the present invention, in Figure 6 In the example, after the target node is added to the blockchain network, the push protocol is completed. The push protocol may include shard index 1, shard index 2, shard index 3, and shard index 4. The four consensus nodes for block synchronization are Figure 6 Node 1, Node 2, Node 3 and Node 4 in the block to be synchronized are Figure 6 In block1-block10, the four consensus nodes are sorted by node ID as node 1, node 2, node 3, and node 4. After the push protocol is established, shard index 1 can correspond to node 1, shard index 2 can correspond to node 2, shard index 3 can correspond to node 3, and shard index 4 can correspond to node 4. According to the number of consensus nodes and the blocks to be synchronized, consensus nodes 1, 2, 3, and 4 can all shard block1-block10 into four segments of data, corresponding to Figure 6In the above table, there are slice1 (slice 1), slice2, slice3 and slice4. Since consensus node 1 can correspond to slice index 1, consensus node 1 can take out slice1 from the four data segments of slice1, slice2, slice3 and slice4 and install it with a slice header and send it to the target node. Similarly, consensus node 2 can correspond to slice index 2, consensus node 3 can correspond to slice index 3 and consensus node 4 can correspond to slice index 4. Consensus node 2, consensus node 3 and consensus node 4 can take out slice2, slice3 and slice4 respectively and install different slice headers, and finally obtain the slice data to be sent and send it to the target node. The target node can integrate all the received slice data to be sent, and finally reorganize to obtain the blocks block1-block10 to be synchronized, and block the blocks to be synchronized to complete the block synchronization operation of the blockchain.

[0181] It should be noted that in the above embodiment, consensus node 1 can also correspond to shard index 2 or shard index 3 due to ID sorting. Correspondingly, when consensus node 1 corresponds to shard index 2, consensus node 1 can take out slice 2 from the four data segments of slice 1, slice 2, slice 3 and slice 4 and install the data header. The specific shard index corresponding to each consensus node may vary depending on the ID of the consensus node.

[0182] It is understandable that the embodiment of the present invention further elaborates on the specific implementation process of data sharding by consensus nodes based on the sharding strategy. The consensus node of the embodiment of the present invention can obtain the total number of consensus nodes and the block height of the consensus nodes from the target blockchain through the block sharding strategy information, and determine the number of fragments to be sharded according to the block height and the number of consensus nodes. At the same time, each shard data can be configured as a shard header and shard content according to the block sharding strategy information, so that the shard data can be sent to the target node through multiple consensus node shards. The target node can reorganize and restore the shard content through the shard header, and finally obtain the data of the block to be synchronized. The embodiment of the present invention can improve the accuracy of data transmission while also improving the efficiency of data transmission.

[0183] In some possible embodiments, the step of sending the to-be-sent shard data to the target node at the target speed according to the storage information of the shard buffer in the target node in step S403 may include but is not limited to steps S4031 to S4033.

[0184] S4031. According to the storage information of the shard buffer in the target node, determine the push speed of the consensus node for the shard data as the target speed.

[0185] It should be noted that the shard buffer of the target node can be used to store shard data from all consensus nodes. The storage information may include but is not limited to the data stored in the shard buffer and its data capacity. The stored data can be stored in the shard buffer in the form of a data array. The target speed can be the speed at which the consensus node pushes the shard data to the shard buffer, where the target speed can be adjusted.

[0186] In an embodiment of the present invention, the consensus node can adjust the push speed of the shard data through different push modes. During the push process of the shard data, the capacity of each shard buffer is limited, that is, it can buffer a certain amount of storage data. Each shard data can occupy a certain storage space. The push speed of the shard data of the consensus node is adjusted according to the storage space occupied by the shard data in the shard buffer and the data in the shard buffer, and the adjusted push speed of the shard data is used as the target speed.

[0187] S4032. Determine the segmentation order of the shard data to be sent by the current consensus node according to the node order of the consensus node in the target blockchain.

[0188] It should be noted that the node order can represent the order in which the consensus node sends the shard data. Each consensus node can correspond to an identity information or ID. According to the ID, the index value of a consensus node can be determined, and each index value can correspond to the node order of each consensus node in the blockchain. Since the node order in the blockchain corresponds to the segmentation order of the shard data, the segmentation order of the shard data to be sent by the current consensus node can be determined according to the node order.

[0189] Exemplarily, since the node order can be the same as the segmentation order of the shard data, when there are three nodes, namely node E, node F and node G, after sorting according to the node ID, the corresponding node order is node E as the first order, node F as the second order and node G as the third order. Correspondingly, node E can send the first segment of shard data to be sent, node F can send the second segment of shard data to be sent, and node G can send the third segment of shard data to be sent.

[0190] It can be understood that the above embodiment is only for illustrative purposes. Node E, node D and node F in the above embodiment can be any three consensus nodes in the blockchain network, and their corresponding order can be adjusted. The specific order is not limited here.

[0191] S4033. According to the segmentation order, determine the corresponding slice data to be sent from the slice data set, and send the slice data to be sent to the target node according to the target speed.

[0192] It should be noted that the shard data set may include multiple shard data to be sent, each shard data may include a shard header, the shard header may correspond to a segment order, and the consensus node may determine the corresponding shard data to be sent from the shard data set.

[0193] In an embodiment of the present invention, when several shard data in a shard data set of a consensus node need to be sent, the shard headers of these shard data can determine the segmentation order. According to the specific segmentation order, the consensus node can send several shard data to be sent in the shard data set in sequence. At the same time, during the sending process, the consensus node can send the shard data to be sent to the target node in sequence at a target speed adjusted according to the real-time length of the shard buffer queue of the target node and the maximum storage capacity of the shard buffer.

[0194] It is understandable that the embodiment of the present invention can dynamically adjust the speed of the consensus node pushing the shard data through the length of the shard buffer queue and the maximum storage capacity of the shard buffer, and determine the segmentation order of the shard data to be sent by the current consensus node according to the node order of the consensus node in the target blockchain; finally, according to the segmentation order and the dynamically adjusted push speed, the shard data to be sent is sent to the target node. The embodiment of the present invention pushes the shard data in the segmentation order, which can improve the accuracy of data push, and the embodiment of the present invention can dynamically adjust the speed of the shard data, further reduce the congestion of the shard data, and improve the push efficiency of the shard data.

[0195] In some possible embodiments, in step S4031, the push speed of the consensus node for the shard data is determined based on the storage information of the shard buffer in the target node. The target speed step may include but is not limited to steps S40311 to S40312.

[0196] S40311. Configure a shard buffer according to the block sharding strategy information. The shard buffer may include multiple shard buffer queues or one-way linked lists, each of which may store shard data sent by a corresponding consensus node in the target blockchain.

[0197] It should be noted that the storage information of the shard buffer can be stored in the form of a shard buffer queue or a one-way linked list, and each shard buffer queue or one-way linked list can correspond to the shard data sent by a corresponding consensus node in the storage target blockchain.

[0198] In the embodiment of the present application, according to the block sharding strategy information, the consensus node can determine all consensus nodes involved in pushing sharding data, each consensus node can correspond to a segment of sharding data, and each sharding buffer queue or a one-way linked list can correspond to one or more segments of sharding data. Each sharding buffer or one-way linked list can be used to temporarily store all sharding data from the corresponding consensus node.

[0199] S40312. Generate a target speed for the corresponding consensus node to send shard data based on the amount of shard data stored in the shard buffer queue or the one-way linked list.

[0200] It should be noted that the shard buffer queue and the one-way linked list may include a number of shard data, which may constitute the real-time length of the shard buffer queue and the one-way linked list, and the real-time length of the shard buffer queue and the one-way linked list may represent the amount of shard data stored in the shard buffer queue or the one-way linked list. Each shard buffer has a maximum length that can buffer the shard buffer queue.

[0201] In an embodiment of the present invention, the consensus node can adjust the push speed of the shard data according to the real-time length of the shard buffer queue or the one-way linked list and the maximum length of the shard buffer queue that the shard buffer can buffer.

[0202] It is understandable that the consensus node of the embodiment of the present invention can generate a corresponding push speed based on the queue storage status of the buffer and control the speed of pushing the shard data. This supports dynamic speed changes and can flexibly adjust the push speed according to the status of the buffer queue to ensure the stability and continuity of the pushed data.

[0203] In some possible embodiments, the step of determining the push speed of the consensus node for the shard data as the target speed according to the storage information of the shard buffer in the target node in step S4031 may also include but not limited to step S40313, where step S40313 is to configure the shard buffer queue as a ring buffer queue. Step S40313 may include steps S403131 to S403133.

[0204] S403131. Configure a static array as the storage capacity of the ring buffer queue.

[0205] It should be noted that the shard buffer queue can usually be configured as a ring buffer queue. The ring buffer queue can select a ringbuffer, also known as a circular queue. A circular queue is a data structure that can be used to represent a fixed-size and head-to-tail connected buffer, which can be used to cache data streams.

[0206] It should be noted that the ring buffer can have the following usage characteristics:

[0207] 1. When a data element is read out, the remaining data elements do not need to move their storage locations.

[0208] 2. The capacity (length) of the buffer is generally fixed, and a static array can be used as a buffer without repeatedly applying for memory.

[0209] 3. Because the buffer is a ring with the head and tail connected, the write operation may overwrite the data that has not been read in time. Therefore, when the data is full, new data cannot be written into it.

[0210] 4. Buffer empty or full judgment: The buffer can only store length-1 data at most. When the write pointer is located one bit after the read pointer, it means that the queue is full. When the read pointer and the write pointer are at the same position, it means that the buffer is empty.

[0211] 5. When pointer operations can be performed concurrently, atomic operations can be used to ensure the execution order.

[0212] In an embodiment of the present invention, the consensus node can configure a static data group as a buffer, where the corresponding information is sent to the target node, and the target node can form a circular buffer with corresponding storage capacity. The present application can use a static data group as a buffer without repeatedly applying for memory, thereby improving the efficiency of data processing.

[0213] S403132. Configure the starting buffer position and the ending buffer position of the ring buffer queue to be the same position.

[0214] It should be noted that each ring buffer queue has a corresponding starting buffer position and ending buffer position. The starting buffer position of each ring buffer queue can be any position in the buffer area, and the ending buffer position of each ring buffer queue can also be any position in the buffer area.

[0215] In an embodiment of the present invention, the starting buffer position and the ending buffer position of the circular buffer queue can be configured as the same position. By configuring the starting buffer position and the ending buffer position of the circular buffer queue as the same position, the circular buffer queue forms a circular buffer connected end to end. The circular buffer connected end to end can avoid the situation where new data can still be written into the buffer when the data is full, and can improve the accuracy of data reading and writing.

[0216] S403133. Configure the read pointer and write pointer of the ring buffer queue.

[0217] It should be noted that each ring buffer queue may have a corresponding read pointer and write pointer, and the read pointer may be used to indicate the position when reading slice data from the ring buffer queue, and the write pointer of the ring buffer queue is used to indicate the position when writing slice data to the ring buffer queue.

[0218] It is understandable that the data in the ring buffer can only store length-1 data at most. When the write pointer is located one bit after the read pointer, it means that the queue is full at this time. When the read pointer and the write pointer are at the same position, it means that the buffer data is empty. Exemplarily, when the storage length of the ring buffer is a, the ring buffer can only store a-1 data, where is a positive integer.

[0219] It should be noted that the role of the buffer queue in the shard buffer of the prior art is to cache the data shards pushed from the consensus node in a certain order. Based on this purpose, there are many solutions in the prior art to achieve this function. For example: using a queue based on an array, adding new data shards from the end of the array, and obtaining shards from the head of the array, the above-mentioned function of caching the data shards pushed from the consensus node in a certain order can be achieved. Or it can also be achieved based on a one-way linked list. However, these solutions may have a problem in concurrent scenarios, that is, the queue needs to be locked to ensure the safety of the thread.

[0220] It can be understood that the embodiment of the present invention can improve the performance problem caused by locking by constructing a ring buffer queue as the buffer of the target node of the present invention, and can also ensure the safety of the thread without locking the queue.

[0221] In some possible embodiments, the step of generating a target speed for the corresponding consensus node to send shard data based on the amount of shard data stored in the shard buffer queue in step S40312 may include but is not limited to steps S403121 to S403123.

[0222] S403121. Obtain the real-time positions of the read pointer and the write pointer.

[0223] In the embodiment of the present invention, it is understood that the position of the read pointer can be any address of the ring buffer, and the write pointer can also be any address of the ring buffer. As data is continuously written into the ring buffer, the position of the write pointer can change, and as data is continuously read from the ring buffer, the real-time position of the read pointer can also change.

[0224] S403122. Determine the data storage capacity of the circular buffer queue according to the real-time positions of the read pointer and the write pointer. When the read pointer and the write pointer of the circular buffer queue are at the same position, it indicates that the data storage capacity in the circular buffer queue is empty; when the write pointer of the circular buffer queue is at the next pointer position adjacent to the read pointer, it indicates that the data storage capacity in the circular buffer queue is full.

[0225] It should be noted that the real-time positions of the read pointer and the write pointer are at the same position, which can indicate that the reading and writing of the ring buffer queue data are at the same position, which can indicate that the data storage capacity in the ring buffer queue is 0. When the write pointer of the ring buffer queue is at the next pointer position adjacent to the read pointer, it can indicate that the data storage capacity in the ring buffer queue is full.

[0226] In an embodiment of the present invention, the real-time position of the read pointer can reflect the position where the data in the ring buffer is read out, and further can reflect the speed at which the data is read out, while the real-time position of the write pointer can reflect the position where the data in the ring buffer is written out, and further can obtain the speed at which the data is written. When the data reading speed is different from the writing speed, the buffer queue of the ring buffer will change continuously. Therefore, the data storage capacity of the ring buffer queue can be inferred based on the positions of the read pointer and the write pointer.

[0227] S403123. According to the data storage capacity of the ring buffer queue, the target speed is accelerated, decelerated, or maintained at the original speed.

[0228] It should be noted that speeding up, slowing down or maintaining the original speed of the target speed can occur in two consecutive push processes. In the process of the consensus node continuously pushing data to the new node at a certain push speed, due to the uneven number of shard data, the speed of writing shard data into the cache may be greater than, less than or equal to the push speed of the current process, so it is necessary to adjust the push speed of the next block data push process.

[0229] In an embodiment of the present invention, the data storage capacity of the circular buffer queue varies due to the uneven speed of the current streaming process. When the data storage capacity of the circular buffer queue increases to a certain threshold, the target speed is accelerated. When the data storage capacity of the circular buffer queue decreases to a certain threshold, the target speed is decelerated. When the data storage capacity of the circular buffer queue remains unchanged, the target speed can be decelerated.

[0230] For example, refer to Figure 7 , Figure 7 A schematic diagram of the structure of a ring buffer provided by an embodiment of the present invention. Figure 7 It can be seen that the ring buffer is a fixed-size buffer, such as Figure 7The buffer size shown is 0X16, where the last address 0X16 is connected to the start 0X00. According to the amount of shard data stored in the shard buffer queue, the target speed of the corresponding consensus node when sending the shard data is generated. This process can obtain the real-time position of the read pointer (701 in the figure) and the write pointer (702 in the figure). According to the real-time position of the read pointer 701 and the write pointer 702, the data storage capacity of the ring buffer queue can be determined; according to the data storage capacity of the ring buffer queue, the target node speeds up, slows down or maintains the original speed.

[0231] It can be understood that the implementation of the present invention can dynamically increase or decrease the target speed based on the ring buffer queue, improve the stability of the streaming process, and further improve the efficiency of blockchain data transmission.

[0232] In some possible embodiments, step S403123 speeds up, slows down, or maintains the original speed of the target speed according to the data storage capacity of the circular buffer queue. This step may include but is not limited to steps S4031231 to S4031234.

[0233] S4031231. Obtain the data storage capacity of the ring buffer queue, and calculate the data storage ratio between the data storage capacity and the total storage capacity of the ring buffer queue.

[0234] In the embodiment of the present invention, the adjustment strategy of increasing, decreasing or keeping the streaming speed constant can be determined by the data storage ratio between the data storage capacity of the ring buffer queue and the total storage capacity of the ring buffer queue. The embodiment of the present invention can determine different adjustments for different data storage ratios.

[0235] S4031232: When the data storage ratio is less than a first threshold, the target speed is accelerated or maintained at the original speed.

[0236] In the embodiment of the present invention, it can be understood that the adjustment of speed is a dynamic process. During the adjustment period, the first threshold can be used to characterize the situation where there is relatively little data in the shard buffer. When the data in the shard buffer is less than the first threshold, it can indicate that the remaining space in the buffer is relatively large, and more shard data can be stored. The first threshold can be any value less than the integer 1. Exemplarily, the first threshold can be 1 / 2. When the data storage ratio is less than 1 / 2, it means that the remaining space of the consensus node in the shard buffer exceeds 1 / 2. At this time, the consensus node can speed up the target speed of the shard data or maintain the original speed.

[0237] S4031233. When the data storage ratio is greater than or equal to the first threshold and less than the second threshold, the target speed is decelerated.

[0238] In the embodiment of the present invention, it can be understood that the second threshold can be used to characterize the data in the shard buffer, exceeding a certain data capacity value, which is larger than the data capacity value corresponding to the first threshold. When the data in the shard buffer is greater than the second threshold, the remaining space in the shard buffer is relatively small, close to the maximum capacity of the shard buffer, and the process of sending shard data by the corresponding consensus node needs to be suspended. Exemplarily, the first threshold can be 1 / 2, and the second threshold can be 3 / 4. When the data storage ratio is greater than or equal to 1 / 2 and less than or equal to 3 / 4, the target speed is decelerated.

[0239] S4031234. When the data storage ratio is greater than the second threshold, suspend the corresponding consensus node from sending shard data.

[0240] In the embodiment of the present invention, it can be understood that when the data in the shard buffer is greater than the second threshold, the remaining space in the shard buffer is relatively small and close to the maximum capacity of the shard buffer. At this time, the corresponding consensus node can suspend the process of sending shard data. Exemplarily, the second threshold can be 3 / 4. When the data storage ratio is greater than 3 / 4, it means that the remaining space of the consensus node in the shard buffer exceeds 3 / 4. At this time, the data in the shard buffer is relatively crowded, and the consensus node can suspend the process of sending shard data.

[0241] It should be noted that when the data storage ratio is equal to 1 / 2, the consensus node can slow down the target speed or maintain the original speed.

[0242] For example, refer to Figure 8 , Figure 8 A schematic diagram of a shard data push speed adjustment process provided by an embodiment of the present invention. Figure 8 As can be seen, the shard buffer can include data shards pushed from the four consensus nodes Q1, Q2, Q3 and Q4, and maintains four buffer queues. Each buffer queue has a fixed length, for example, up to 100 shards can be cached. During an adjustment cycle, when the shard buffer receives a data shard and puts it into the buffer queue, it calculates the length of the current queue. If the queue length exceeds 3 / 4 of the maximum length, the consensus node is notified to suspend streaming; if the length exceeds 1 / 2 but does not exceed 3 / 4, the consensus node is notified to use low-speed streaming; if the length is less than 1 / 2, normal streaming is used. If the current streaming mode is already an established mode, the consensus node will not be notified.

[0243] It is understandable that when a ring queue is implemented by using a ring buffer, the speed can be controlled by first defining a deceleration pointer and a speed-up pointer. The deceleration pointer can calculate the pointer position when the data capacity reaches 3 / 4 at any time based on the position of the read pointer. The speed-up pointer can calculate the pointer position when the data capacity reaches 1 / 4 at any time based on the position of the read pointer. Therefore, it is only necessary to judge when the write pointer reaches the position of the deceleration pointer when writing data, and change to a low-speed push mode; when the write pointer reaches the position of the speed-up pointer, change to a normal push mode; when the buffer is full (the write pointer is located next to the read pointer), change to stop pushing. It is understandable that by setting the specific positions of the deceleration and speed-up pointers, the subsequent target node can determine whether it is necessary to notify the consensus node to adjust the push speed of the shard data by detecting the position of the read pointer, which can further improve the data processing efficiency.

[0244] It is understandable that the embodiments of the present invention can control the target speed of the sharded data by setting different specific thresholds according to different storage situations, thereby reducing data congestion when the block data is pushed and streaming, and further improving the efficiency of data pushing and streaming.

[0245] On the other hand, please refer to Fig. 9 , Fig. 9 The flowchart of a block synchronization processing method provided in an embodiment of the present invention is shown in FIG. The method can be executed with any node newly connected to the blockchain network, or any new node that is temporarily disconnected and reconnected to the blockchain network as the target node.

[0246] It is understandable that a node newly connected to the blockchain network may be a new node that has never participated in any consensus process of the blockchain network before access, and a new node that is temporarily disconnected and reconnected to the blockchain network may be a new node that has participated in any one or more consensus processes of the previous blockchain network, but did not participate in the most recent consensus process due to node failure, network failure, etc. Both types of nodes have a height difference with the blocks corresponding to the consensus nodes of the blockchain network, that is, there are blocks that need to be synchronized.

[0247] For ease of understanding, the embodiment of the present invention takes the method being executed by any node newly connected to the blockchain network as an example for explanation. The block synchronization processing method may at least include the following steps S901 to S903.

[0248] S901. Generate a block synchronization request according to the new node joining rules of the target blockchain.

[0249] In an embodiment of the present invention, the new node joining rule may be a rule for defining the joining of a new node, which may include but is not limited to the number of consensus nodes in the streaming protocol, the consensus node index information, and the information of the block to be synchronized. After the new node accesses the target blockchain, the new node can receive the heartbeat sent by the consensus nodes of other syncable blocks from the target blockchain, and the new node can obtain the current block height of each consensus node based on the heartbeat. When the block height of the new node itself is equal to the current block height of the consensus node, there is no need to synchronize the block of the new node. When the block height of the new node itself is less than the current block height of the consensus node, the new node can generate a block synchronization request.

[0250] S902. Send a block synchronization request to each consensus node in the target blockchain, so that each consensus node executes the aforementioned block synchronization processing method after receiving the block synchronization request.

[0251] In an embodiment of the present invention, the new node can send a block synchronization request to each consensus node in the target blockchain. After receiving the block synchronization request, each consensus node can use the above-mentioned block synchronization processing method to send the block shard to the new node. In the process of the new node receiving the block shard, the new node can notify the consensus node through the data storage capacity of the shard buffer to dynamically adjust its block shard pushing speed to reduce data congestion during the block shard pushing process.

[0252] S903, receiving the shard data sent by each consensus node, reorganizing each shard data to obtain the block to be synchronized, and completing the block synchronization operation of the target node according to the block to be synchronized.

[0253] In the embodiment of the present invention, each shard data may carry information indicating that it belongs to a certain block and information indicating that it belongs to a certain node. Based on this information, the new node reorganizes each shard data according to the set reorganization strategy, and completes the block synchronization operation of the target node according to the block to be synchronized.

[0254] In some possible embodiments, the step of receiving the shard data sent by each consensus node in step S903 and reorganizing each shard data to obtain the block to be synchronized may include but is not limited to steps S9031 to S9033.

[0255] S9031. Obtain the shard data at the same block height sent by each consensus node.

[0256] It should be noted that the shard data can be several shard data of the same block height, the specific number of shard data can be determined by the consensus node, and the shard data can be obtained through the connection established between each consensus node and the target node.

[0257] In an embodiment of the present invention, the target node can form a data interaction process with the consensus node through a signal connection. The target node can obtain the shard data of each consensus node at the same block height through the established push streaming protocol. The target node obtains the shard data at the same height and can reorganize the shard data.

[0258] S9032. Obtain the slice header and slice content of each slice data.

[0259] It should be noted that each shard data may include but is not limited to a shard header and shard content. The shard header of the embodiment of the present invention may determine the number of segments of the shard data in the entire block to be synchronized, and the shard content may be the specific content of a certain segment of shard data.

[0260] S9033. After sorting the shard data of the same block height according to the shard header, reorganize the shard contents of each shard data in the sorted order to obtain the block to be synchronized.

[0261] In an embodiment of the present invention, the target node can obtain the shard data at the same block height issued by each consensus node, extract the respective shard headers from each shard data and parse them, obtain the number of segments of the shard content corresponding to the shard header in the block to be synchronized, and sort the shard data at the same height according to their respective shard headers. The target node can then reorganize the shard data in the sorted order.

[0262] For example, refer to Fig.10 , Fig.10 A schematic diagram of a process for a target node to reorganize shard data provided by an embodiment of the present invention. The new node can obtain shard data at the same block height (block1-block10) from each consensus node from the shard buffer. Fig.10 The shards 1, 2, 3 and 4 in the data may correspond to the shard data sent by consensus node 1, consensus node 2, consensus node 3 and consensus node 4 respectively. The data header of each shard data is used to identify the segment number to which the shard data to be reassembled belongs, and the data body is the actual data of the shard data to be reassembled. After the four shards of data body 1, data body 2, data body 3 and data body 4 are assembled, the complete data of the current data segment is obtained, that is, the complete data of block1-block10 is obtained. After the data is assembled, it can be placed in the order of the height of block1-block10 to complete the block synchronization process.

[0263] It is understandable that in the embodiment of the present invention, when a new node receives all the fragments of the same segment, data assembly begins. The segment to which the current fragment belongs is identified by the 4 bytes of the header of each fragment, and then the content after the header is removed is spliced ​​into a complete data in the order of the fragments, thereby improving the efficiency of blockchain data reorganization and the accuracy of the reorganized data.

[0264] In some possible embodiments, the block synchronization processing method of the present invention may also include but is not limited to steps S904 to S906.

[0265] S904. After sending a block synchronization request to each consensus node in the target blockchain, the connection confirmation information sent back by the corresponding consensus node is obtained in real time.

[0266] In an embodiment of the present invention, the confirmation connection information may be a processed data that can be transmitted between the target node and the consensus node. The target node may obtain the connection confirmation information sent back by the corresponding consensus node according to the protocol between the target node and each consensus node. After the target node sends a block synchronization request to each consensus node in the target blockchain, the target node may obtain the connection confirmation information sent back by the corresponding consensus node in real time.

[0267] S905. When no connection confirmation information of the consensus node is received within the preset response time, the consensus node is added to the list of nodes to be connected.

[0268] It is understandable that the preset response time can be any preset time. The target node can detect the reception time of the connection confirmation information received from the consensus node. According to the time difference between the time of issuing the block synchronization request and the time of receiving the connection confirmation information and the preset response time, it is determined whether the consensus and node are connected and confirmed. If not confirmed, the consensus node can be added to the list of nodes to be connected. The consensus node added to the list of nodes to be connected can be used for the next connection.

[0269] S906. Create a new block sharding strategy and generate new block sharding strategy information, and then re-issue a block synchronization request to the consensus node in the list of nodes to be connected until the connection between the target node and the consensus node is established.

[0270] In an embodiment of the present invention, after the new node issues a block synchronization request to each consensus node in the target blockchain, the connection confirmation information sent back by each corresponding consensus node can be obtained in real time. When the new node does not receive the connection confirmation information of the consensus node within the preset response time, the consensus node can be added to the list of nodes to be connected. The new node can re-create a new block sharding strategy and generate new block sharding strategy information, and then re-issue a block synchronization request to the consensus node in the list of nodes to be connected, and try to establish a new connection with the consensus node in the list of nodes to be connected, and repeat the attempt until the new node is successfully connected to the consensus node.

[0271] It can be understood that the embodiments of the present invention can improve and update the sharding strategy according to the success or failure of establishing a connection between the target node and the consensus node, and finally achieve the establishment of a connection relationship between the consensus node and the target node. By repeatedly connecting, the stability of blockchain data transmission can be improved.

[0272] In some optional embodiments, a block synchronization process of the present invention can be completed by a new node and three synchronization nodes of the blockchain network, wherein the new node is the target node.

[0273] In the embodiment of the present invention, the three nodes may be node 1, node 2, and node 3, respectively, and the blocks to be synchronized are block0-blockN.

[0274] When a new node is added to the blockchain network, the node manager of the new node, Mou Kui, can receive heartbeats sent from other formula nodes that can synchronize blocks, and the heartbeats can be accompanied by the block height of each consensus node.

[0275] When the new node establishes a connection with the target node, the new node will first prepare the push protocol. The push protocol may include 3 consensus nodes responsible for the push protocol, namely consensus node 1, consensus node 2 and consensus node 3, and the corresponding index values ​​of consensus node 1, consensus node 2 and consensus node 3, as well as the block heights of blocks block0-blockN that need to be synchronized. After the target node configures the protocol, it will send block synchronization requests to consensus node 1, consensus node 2 and consensus node 3 in the protocol. After the connection is established, consensus node 1, consensus node 2 and consensus node 3 can shard the blocks to be synchronized according to the content of the protocol to obtain shard 1, shard 2 and shard 3, and add the shard header of the shard, and determine the sending order of each shard as node 1 is responsible for sending shard 1 of the block that needs to be synchronized, node 2 is responsible for sending shard 2 of the block that needs to be synchronized, and node 3 is responsible for sending shard 3 of the block that needs to be synchronized, and the shard data with the shard header is sent to the new node in order.

[0276] When a new node receives shard data, it can store the shard data in its own ring buffer first and adjust the speed at which the consensus node pushes the shard by detecting the read pointer position of the ring buffer. When the read pointer of the ring buffer is at a position where the ring buffer data capacity reaches 3 / 4, the new node can notify the consensus node to suspend the push of shard data. When the read pointer of the ring buffer is at a position between 1 / 2 and 3 / 4 of the ring buffer data capacity, the new node can notify the consensus node to reduce the push speed of the shard data. When the read pointer of the ring buffer is at a position where the ring buffer data capacity is less than 1 / 2, the new node can notify the consensus node to increase the push speed of the shard data.

[0277] The new node obtains shard 1 with shard header, shard 2 with shard header, and shard 3 with shard header from its own ring buffer. The new node can determine the position of the shard data in the original block that needs to be synchronized based on the shard header of the shard data, and reorganize the shard data into block0-blockN in sequence according to the original position, and write block0-blockN into the local storage of the blockchain in the order of block height.

[0278] On the other hand, refer to Fig.11 The embodiment of the present invention further provides a block synchronization processing device 1100, which may include:

[0279] The first module 1110 is used to receive a block synchronization request sent by a target node; wherein the block synchronization request includes block sharding strategy information.

[0280] The second module 1120 is used to perform data sharding on the block to be synchronized according to the block sharding strategy information, obtain a sharding data set, and determine the sharding data to be sent from the sharding data set.

[0281] The third module 1130 is used to send the to-be-sent slice data to the target node at a target speed according to the storage information of the slice buffer in the target node; wherein the slice buffer is used to store each slice data received by the target node.

[0282] Combined with Fig.11, the specific implementation process of the data processing device provided by the present invention is described. First, the first module 1110 can receive a block synchronization request sent by a target node, wherein the block synchronization request can include block sharding strategy information; then, the second module 1120 can perform data sharding on the block to be synchronized according to the block sharding strategy information, and can obtain a sharding data set, and determine the sharding data to be sent from the obtained sharding data set; finally, the third module 1130 can send the sharding data to be sent to the target node at a target speed according to the storage information of the sharding buffer in the target node; wherein the sharding buffer can be used to store each sharding data received by the target node.

[0283] On the other hand, an embodiment of the present invention further provides a block synchronization processing device 1200, which may include:

[0284] The fourth module 1210 is used to generate a block synchronization request according to the new node joining rule of the target blockchain; wherein the block synchronization request includes block sharding strategy information.

[0285] The fifth module 1220 is used to send a block synchronization request to each consensus node in the target blockchain, so that each consensus node executes the aforementioned block synchronization processing method after receiving the block synchronization request.

[0286] The sixth module 1230 is used to receive the shard data sent by each consensus node, reorganize each shard data to obtain the block to be synchronized, and complete the block synchronization operation of the target node according to the block to be synchronized.

[0287] Combined with Fig.12 , the specific implementation process of the data processing device provided by the present invention is described. First, the fourth module 1210 can generate a block synchronization request according to the new node joining rule of the target blockchain; wherein the block synchronization request can include block sharding strategy information; then, the fifth module 1220 can issue a block synchronization request to each consensus node in the target blockchain, so that each consensus node performs the aforementioned block synchronization processing method after receiving the block synchronization request; finally, the sixth module 1230 can receive the sharding data issued by each consensus node, reorganize each sharding data to obtain a block to be synchronized, and complete the block synchronization operation of the target node according to the block to be synchronized.

[0288] On the other hand, Fig.13As shown, an embodiment of the present invention further provides an electronic device 1300, which may include at least one processor 1310 and may also include at least one memory 1320. The memory 1320 may be used to store at least one program, and the processor 1210 may execute the program to execute the aforementioned block synchronization processing method; take a processor 1310 and a memory 1320 as an example.

[0289] The processor 1310 and the memory 1320 may be connected via a bus or in other ways.

[0290] The memory 1320 can be used as a non-transient computer-readable storage medium, which can be used to store non-transient software programs and non-transient computer executable programs. In addition, the memory 1320 may include a high-speed random access memory, and may also include a non-transient memory, such as at least one disk storage device, a flash memory device, or other non-transient solid-state storage device. In some embodiments, the memory 1320 may include a memory remotely arranged relative to the processor, and these remote memories may be connected to the device via a network. Examples of the above-mentioned network may include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0291] The system embodiments described above are merely illustrative, and the units described as separate components may or may not be physically separated, that is, they may be located in one place or distributed on multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the present embodiment.

[0292] Specifically, Fig.14 The structure block diagram of a computer system for implementing an electronic device according to an embodiment of the present application is schematically shown.

[0293] It should be noted that Fig.14 The computer system 1400 of the electronic device shown is only an example and should not bring any limitation to the functions and scope of use of the embodiments of the present application.

[0294] like Fig.14As shown, the computer system 1400 includes a central processing unit 1401 (CPU), which can perform various appropriate actions and processes according to the program stored in the read-only memory 1402 (ROM) or the program loaded from the storage part 1408 to the random access memory 1403 (RAM). In the random access memory 1403, various programs and data required for system operation can also be stored. The central processing unit 1401, the read-only memory 1402 and the random access memory 1403 can be connected to each other through a bus 1404. An input / output interface 1405 (Input / Output interface, i.e., I / O interface) can also be connected to the bus 1404.

[0295] The following components connected to the input / output interface 1405 may include an input section 1406 such as a keyboard, a mouse, etc.; an output section 1407 such as a cathode ray tube (CRT), a liquid crystal display (LCD), etc., and a speaker, etc.; a storage section 1408 including a hard disk, etc.; and a communication section 1409 which may include a network interface card such as a local area network card, a modem, etc. The communication section 1409 may perform communication processing via a network such as the Internet. A drive 1410 may also be connected to the input / output interface 1405 as needed. A removable medium 1411, such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc., may be installed on the drive 1410 as needed, so that a computer program read therefrom may be installed into the storage section 1408 as needed.

[0296] The embodiment of the present invention also discloses a computer program product or a computer program, which may include computer instructions stored in a computer-readable storage medium. A processor of a computer device may read the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computer device executes Figure 4 The method shown.

[0297] According to an embodiment of the present application, the processes described in each method flow chart can be implemented as a computer software program. For example, an embodiment of the present application includes a computer program product, which includes a computer program carried on a computer readable medium, and the computer program contains program code for executing the method shown in the flow chart. In such an embodiment, Fig.14The computer program may be downloaded and installed from a network through the communication section 1409, and / or installed from the removable medium 1311. When the computer program is executed by the central processor 1401, various functions defined in the system of the present application are executed.

[0298] In some selectable embodiments, the function / operation mentioned in the block diagram may not occur in the order mentioned in the operation diagram. For example, depending on the function / operation involved, the two boxes shown in succession can actually be executed substantially simultaneously or the boxes can sometimes be executed in reverse order. In addition, the embodiment presented and described in the flow chart of the present invention is provided by way of example, for the purpose of providing a more comprehensive understanding of technology. The disclosed method is not limited to the operation and logic flow presented herein. Selectable embodiments are expected, wherein the order of various operations is changed and the sub-operation of a part for which is described as a larger operation is performed independently.

[0299] In addition, although the present invention is described in the context of functional modules, it should be understood that, unless otherwise specified, one or more of the functions and / or features described may be integrated into a single physical device and / or software module, or one or more functions and / or features may be implemented in separate physical devices or software modules. It is also understood that a detailed discussion of the actual implementation of each module is unnecessary for understanding the present invention. More specifically, in view of the properties, functions, and internal relationships of the various functional modules in the device disclosed herein, the actual implementation of the module will be understood within the conventional skills of the engineer. Therefore, those skilled in the art can implement the present invention set forth in the claims without excessive experimentation using ordinary techniques. It is also understood that the specific concepts disclosed are merely illustrative and are not intended to limit the scope of the present invention, which is determined by the full scope of the appended claims and their equivalents.

[0300] If the functions are implemented in the form of software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art or the part of the technical solution, can be embodied in the form of a software product. The computer software product is stored in a storage medium, including several instructions for a computer device (which can be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the methods described in each embodiment of the present invention. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), disk or optical disk, etc., which can store program codes.

[0301] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as an ordered list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by an instruction execution system, device or apparatus (such as a computer-based system, a system including a processor, or other system that can fetch instructions from an instruction execution system, device or apparatus and execute instructions), or in conjunction with such instruction execution systems, devices or apparatuses. For the purposes of this specification, "computer-readable medium" can be any device that can contain, store, communicate, propagate or transmit a program for use by an instruction execution system, device or apparatus, or in conjunction with such instruction execution systems, devices or apparatuses.

[0302] More specific examples of computer-readable media (a non-exhaustive list) include the following: an electrical connection with one or more wires (electronic device), a portable computer disk case (magnetic device), a random access memory (RAM), a read-only memory (ROM), an erasable and programmable read-only memory (EPROM or flash memory), an optical fiber device, and a portable compact disk read-only memory (CDROM). In addition, the computer-readable medium may even be a paper or other suitable medium on which the program is printed, since the program may be obtained electronically, for example, by optically scanning the paper or other medium, followed by editing, deciphering or, if necessary, processing in another suitable manner, and then stored in a computer memory.

[0303] It should be understood that the various parts of the present invention can be implemented by hardware, software, firmware or a combination thereof. In the above-mentioned embodiments, a plurality of steps or methods can be implemented by software or firmware stored in a memory and executed by a suitable instruction execution system. For example, if implemented by hardware, as in another embodiment, it can be implemented by any one of the following technologies known in the art or their combination: a discrete logic circuit having a logic gate circuit for implementing a logic function for a data signal, a dedicated integrated circuit having a suitable combination of logic gate circuits, a programmable gate array (PGA), a field programmable gate array (FPGA), etc.

[0304] In the description of this specification, the description with reference to the terms "one embodiment", "some embodiments", "examples", "specific examples", or "some examples" means that the specific features, structures, materials or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of the present invention. In this specification, the schematic representation of the above terms does not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described may be combined in any one or more embodiments or examples in a suitable manner.

[0305] Although the embodiments of the present invention have been shown and described, it will be appreciated by those skilled in the art that various changes, modifications, substitutions and variations may be made to the embodiments without departing from the principles and spirit of the present invention, and that the scope of the present invention is defined by the claims and their equivalents.

[0306] The above is a specific description of the preferred implementation of the present invention, but the present invention is not limited to the described embodiments. Those skilled in the art may make various equivalent modifications or substitutions without violating the spirit of the present invention. These equivalent modifications or substitutions are all included in the scope defined by the claims of this application.

Claims

1. A method for processing block synchronization, characterized in that: include: Receive a block synchronization request sent by a target node; wherein the block synchronization request includes block sharding strategy information; Performing data sharding on the block to be synchronized according to the block sharding strategy information to obtain a sharding data set, and determining the sharding data to be sent from the sharding data set; According to the storage information of the shard buffer in the target node, the shard data to be sent is sent to the target node at the target speed, so that after receiving the shard data sent by each consensus node, the target node reorganizes each shard data to obtain the block to be synchronized, and completes the block synchronization operation of the target node according to the block to be synchronized; The shard buffer is used to store each shard data received by the target node.

2. A block synchronization processing method according to claim 1, characterized in that: The step of performing data sharding on the block to be synchronized according to the block sharding strategy information to obtain a sharding data set, and determining sharding data to be sent from the sharding data set includes: Acquire the height of the block to be synchronized from the block sharding strategy information, and then determine the block to be synchronized according to the height of the block to be synchronized; According to the block sharding strategy information, determine the number of fragments to be sharded and fragment attribute information; wherein the fragment attribute information is used to characterize the consensus node to which each shard data belongs; According to the number of fragments and the fragment attribute information, data fragmentation is performed on the block to be synchronized to obtain a fragmented data set; According to the arrangement order of the consensus nodes in the target blockchain, the shard data to be sent in the shard data sets of each consensus node is determined.

3. A block synchronization processing method according to claim 2, characterized in that: The determining the number of fragments to be fragmented and fragment attribute information according to the block fragmentation strategy information includes: According to the block sharding strategy information, the total number of the consensus nodes and the current block height of the consensus nodes are obtained from the target blockchain; Determine the number of fragments to be sharded according to the total number of the consensus nodes; According to the block sharding strategy information, each of the sharding data is configured as a sharding header and a sharding content, and used as the fragment attribute information; wherein the sharding header is used to mark the segment order to which the sharding data belongs in the sharding data set; the segment order corresponds to the node order of the consensus node in the target blockchain.

4. A block synchronization processing method according to claim 1, characterized in that: The step of sending the to-be-sent slice data to the target node at a target speed according to the storage information of the slice buffer in the target node includes: Determine the push speed of the consensus node for the shard data according to the storage information of the shard buffer in the target node, as the target speed; Determine the segmentation order of the shard data to be sent by the current consensus node according to the node order of the consensus node in the target blockchain; According to the segmentation order, the corresponding sliced ​​data to be sent are determined from the sliced ​​data set, and the sliced ​​data to be sent are sent to the target node according to the target speed.

5. A block synchronization processing method according to claim 4, characterized in that: The step of determining the push speed of the consensus node for the shard data as the target speed according to the storage information of the shard buffer in the target node includes: According to the block sharding strategy information, the sharding buffer is configured; wherein the sharding buffer includes a plurality of sharding buffer queues or one-way linked lists, each of which stores sharding data sent by a corresponding consensus node in the target blockchain; According to the amount of shard data stored in the shard buffer queue or the one-way linked list, a target speed at which the corresponding consensus node sends the shard data is generated.

6. A block synchronization processing method according to claim 5, characterized in that: The method further comprises the step of configuring the fragment buffer queue as a ring buffer queue, the step comprising: Configuring a static array as the storage capacity of the ring buffer queue; Configuring the starting buffer position and the ending buffer position of the circular buffer queue to be the same position; A read pointer and a write pointer of the circular buffer queue are configured, wherein the read pointer is used to indicate a position when fragment data is read from the circular buffer queue, and the write pointer is used to indicate a position when fragment data is written to the circular buffer queue.

7. A block synchronization processing method according to claim 6, characterized in that: The step of generating a target speed at which a corresponding consensus node sends the shard data according to the amount of shard data stored in the shard buffer queue includes: Obtaining the real-time positions of the read pointer and the write pointer; Determining the data storage capacity of the ring buffer queue according to the real-time positions of the read pointer and the write pointer; According to the data storage capacity of the ring buffer queue, the target speed is accelerated, decelerated or maintained at the original speed; Among them, when the read pointer and the write pointer of the circular buffer queue are at the same position, it indicates that the data storage capacity in the circular buffer queue is empty; when the write pointer of the circular buffer queue is at the next pointer position adjacent to the read pointer, it indicates that the data storage capacity in the circular buffer queue is full.

8. A block synchronization processing method according to claim 7, characterized in that: The processing of speeding up, slowing down or maintaining the original speed of the target speed according to the data storage amount of the ring buffer queue includes: Obtaining the data storage capacity of the ring buffer queue, and calculating the data storage ratio between the data storage capacity and the total storage capacity of the ring buffer queue; When the data storage ratio is less than a first threshold, the target speed is accelerated or maintained at the original speed; When the data storage ratio is greater than or equal to the first threshold and less than a second threshold, decelerating the target speed; When the data storage ratio is greater than the second threshold, the corresponding consensus node is suspended from sending the shard data.

9. A method for processing block synchronization, characterized in that: include: Generate a block synchronization request according to the new node joining rule of the target blockchain; wherein the block synchronization request includes block sharding strategy information; Sending the block synchronization request to each consensus node in the target blockchain, so that each consensus node executes the block synchronization processing method according to any one of claims 1 to 8 after receiving the block synchronization request; Receive the shard data sent by each consensus node, reorganize each shard data to obtain the block to be synchronized, and complete the block synchronization operation of the target node according to the block to be synchronized.

10. A block synchronization processing method according to claim 9, characterized in that: The receiving of the shard data sent by each consensus node and reorganizing each of the shard data to obtain a block to be synchronized includes: Obtain shard data at the same block height from each consensus node; Obtaining the slice header and slice content of each of the slice data; After sorting the shard data of the same block height according to the shard header, the shard contents of each shard data are reorganized in the sorting order to obtain the block to be synchronized.

11. A block synchronization processing method according to claim 9, characterized in that: The method further comprises: After sending a block synchronization request to each consensus node in the target blockchain, obtaining the connection confirmation information sent back by the corresponding consensus node in real time; When no connection confirmation information of the consensus node is received within the preset response time, the consensus node is added to the list of nodes to be connected; A new block sharding strategy is created and new block sharding strategy information is generated, and then a block synchronization request is reissued to the consensus node in the list of nodes to be connected until a connection between the target node and the consensus node is established.

12. A block synchronization processing device, characterized in that: include: The first module is used to receive a block synchronization request sent by a target node; wherein the block synchronization request includes block sharding strategy information; The second module is used to perform data sharding on the block to be synchronized according to the block sharding strategy information to obtain a sharding data set, and determine the sharding data to be sent from the sharding data set; The third module is used to send the to-be-sent fragmented data to the target node at a target speed according to the storage information of the fragmented buffer in the target node; The shard buffer is used to store each shard data received by the target node.

13. A block synchronization processing device, characterized in that: include: The fourth module is used to generate a block synchronization request according to the new node joining rule of the target blockchain; wherein the block synchronization request includes block sharding strategy information; A fifth module is used to send the block synchronization request to each consensus node in the target blockchain, so that each consensus node executes the block synchronization processing method according to any one of claims 1 to 8 after receiving the block synchronization request; The sixth module is used to receive the shard data sent by each consensus node, reorganize each of the shard data to obtain the block to be synchronized, and complete the block synchronization operation of the target node according to the block to be synchronized.

14. An electronic device, characterized in that: including a processor and a memory; The memory is used to store programs; The processor executes the program to implement the method according to any one of claims 1 to 11.

15. A computer-readable storage medium, characterized in that: The storage medium stores a program, and the program is executed by a processor to implement the method according to any one of claims 1 to 11.

16. A computer program product comprising a computer program, characterized in that When the computer program is executed by a processor, the method according to any one of claims 1 to 11 is implemented.

Images