CN115277733B

CN115277733B - Block head synchronization method and device, electronic equipment and storage medium

Info

Publication number: CN115277733B
Application number: CN202210913959.9A
Authority: CN
Inventors: 朱晓旻; 郭京申; 舒俊宜
Original assignee: Beijing Zhirong Yunhe Technology Co ltd
Current assignee: Beijing Zhirong Yunhe Technology Co ltd
Priority date: 2022-07-29
Filing date: 2022-07-29
Publication date: 2024-02-20
Anticipated expiration: 2042-07-29
Also published as: CN115277733A

Abstract

The application discloses a block head synchronization method, a device, electronic equipment and a storage medium, which belong to the technical field of block chains, and the method comprises the following steps: and recording the last synchronization result through the hash queue, and calculating the newly generated block head between the two times of synchronization, and completing the query operation in the synchronization process by depending on the hash queue. And a block head timing synchronization module designed for BDLedger is adopted to perform timing synchronization on the first synchronization node and the second synchronization node under the conditions of network structure change and the like. The method can solve the problem that some nodes can not receive newly generated block heads under some conditions, thereby ensuring the integrity and consistency of the block head copies of all nodes in the network.

Description

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

Technical Field

The present invention relates to the field of blockchain technologies, and in particular, to a method and apparatus for synchronizing a blockhead, an electronic device, and a storage medium.

Background

With the advantages of the blockchain technique represented by bitcoin, such as decentralization and non-falsification, the blockchain technique is widely used in various fields such as cryptocurrency. And the account book based on single chain is difficult to improve in block rate and expandability because of the limitation of the data structure and the consensus mechanism. The North Dacron team develops a drawing ledger BDLedger for solving the requirement of big data evidence storage based on a DAG block organization structure and a random evidence consensus mechanism. The block head and the block body in the account book are stored separately, the block head is stored in all nodes of the whole network, and the block body is stored in the block producing node, the witness node and the backup node. In the consensus process, in order for all nodes of the whole network to have a backup of the block header, it is necessary to broadcast the newly generated block header to the whole network after the witness process is completed.

Currently, considering the block rate of the ledger and the complex network state in the distributed environment, the block-generating node cannot wait for the return acknowledgements of all nodes, which results in some nodes not receiving newly generated block headers in some cases.

And because of the particularity of the drawing account book, various technologies are relatively immature, and the existing data synchronization mechanism does not well utilize the preamble consistency of BDLedger. Therefore, a practical and efficient block header synchronization mechanism is needed for bdridge.

Disclosure of Invention

The embodiment of the application aims to provide a block header synchronization method, a device, electronic equipment and a storage medium, which can solve the problem that in some cases, some nodes cannot receive newly generated block headers, so that the integrity and consistency of block header copies of all nodes in a network cannot be ensured.

In order to solve the technical problems, the application is realized as follows:

in a first aspect, an embodiment of the present application provides a method for synchronizing a block header, where the method is applied to a first synchronization node in a blockchain, where a hash queue is stored in the blockchain node, and the hash queue is used for a query operation of a synchronization process, and the method includes:

Inquiring the position of a hash value synchronized at the last time in a linked list in the hash queue when a new block producing node or a broken network block producing node restores the network, and identifying a newly generated block based on the position;

selecting a second synchronization node, and sending all newly generated leaf block information of the first synchronization node since the last synchronization to the second synchronization node according to the hash queue;

receiving the leaf block information which is lack by the second synchronous node and the leaf block information which is newly generated by the second synchronous node, wherein the leaf block information which is lack by the second synchronous node and the leaf block information which is newly generated by the second synchronous node are sent by the second synchronous node according to the leaf block information which is newly generated by the first synchronous node;

transmitting the leaf block information of the second synchronization node lacking the leaf block information and the leaf block information of the second synchronization node lacking the first synchronization node to the second synchronization node;

marking the block header shared by the first synchronous node and the second synchronous node;

and sending the unmarked leaf block header to the second synchronization node, and receiving the unmarked leaf block header sent by the second synchronization node so as to complete block header synchronization between the first synchronization node and the second synchronization node.

Optionally, the method further comprises:

transmitting She Ziou block header identifiers in an interactive way with the second synchronous node, and additionally transmitting block generating node ids corresponding to the leaf block headers;

and judging whether the first synchronous node contains the leaf block head or not through account book inquiry.

If the first synchronous node account book does not contain the leaf block header, the first synchronous node does not do any operation;

if the first synchronization node account book contains the leaf block header and the first synchronization node contains the latest block header generated after the leaf block header, marking all block headers between the She Ziou block header and the latest block header as block headers to be updated;

and updating the hash queue according to the block header to be updated, and sending the block header to be updated to the second synchronous node.

Optionally, the identifying the newly generated block based on the location includes:

finding the position of the last synchronized hash in a linked list according to the block hash value in the index structure of the hash queue;

and taking the hash value positioned behind the position as a newly generated block hash value after the last synchronization.

Optionally, the sending, by the hash queue, all newly generated leaf block information of the first synchronization node from the last synchronization to the second synchronization node includes:

and taking out all newly generated block hash values by utilizing the hash queue, and finding out the blocks which are not selected as the preamble block heads by any block heads, namely leaf block information.

Optionally, the block header synchronization mechanism determines whether the non-leaf block header exists in the local ledger based on performing incremental synchronization on the DAG ledger with preamble consistency to complete timing synchronization.

Optionally, the marking operation includes:

the leaf block heads of the two nodes are initially marked;

marking the same leaf block header of the local leaf block header according to the newly generated She Ziou block header sent by the second node in all newly generated local She Ziou block headers;

among all newly generated local She Ziou block heads, marking different leaf block heads of the local leaf block heads according to She Ziou block heads which are lack of the first synchronous node and are sent by the second node;

optionally, the marking operation further includes:

And marking all block heads in the newly generated blocks, which have a preamble relation with the block with the leaf, according to the blocks which are common to the first synchronous node and the second synchronous node in the initial marking stage and are the leaf in at least one node.

In a second aspect, an embodiment of the present application provides a tile head synchronization device, including:

a hash queue module: when a new block producing node or a broken network block producing node restores the network, inquiring the position of a hash value synchronized at the last time in a linked list in the hash queue, and identifying a newly generated block based on the position;

a timing synchronization module: the first synchronization node is used for selecting a second synchronization node, and sending all newly generated leaf block information of the first synchronization node since the last synchronization to the second synchronization node according to the hash queue;

marking the leaf block head shared by the first synchronous node and the second synchronous node;

Optionally, the hash queue module includes:

Optionally, the hash queue module further includes:

the leaf block heads of the two nodes are initially marked;

optionally, the hash queue module further includes:

Optionally, the timing synchronization module includes:

Optionally, the timing synchronization module further includes: and taking out all newly generated block hash values by utilizing the hash queue, and finding out the blocks which are not selected as the preamble block heads by any block heads, namely leaf block information.

In a third aspect, an embodiment of the present application provides an electronic device, including a processor, a memory, and a program or an instruction stored on the memory and executable on the processor, where the program or the instruction implements the steps of the block header synchronization method according to the first aspect when executed by the processor.

In a fourth aspect, embodiments of the present application provide a readable storage medium having stored thereon a program or instructions which, when executed by a processor, implement the steps of the tile head synchronization method according to the first aspect.

In the embodiment of the application, the last synchronization result is recorded through the hash queue and is used for calculating the newly generated block head between two times of synchronization, and meanwhile, the query operation in the synchronization process is completed by depending on the hash queue. And a block head timing synchronization module designed for BDLedger is adopted to perform timing synchronization on the first synchronization node and the second synchronization node under the conditions of network structure change and the like. The method can solve the problem that some nodes can not receive newly generated block heads under some conditions, thereby ensuring the integrity and consistency of the block head copies of all nodes in the network.

Drawings

Fig. 1 is a flowchart of a block header synchronization method according to an embodiment of the present application;

fig. 2 is a schematic flow chart of a block header synchronization method according to an embodiment of the present application;

FIG. 3 is a schematic diagram of a LinkedHashMap provided in an embodiment of the present application;

FIG. 4 is a schematic diagram of a class diagram of a block header synchronization mechanism according to an embodiment of the present disclosure;

FIG. 5 is a schematic diagram of a hash queue node data structure provided in an embodiment of the present application;

FIG. 6 is a schematic diagram of a hash queue data structure provided in an embodiment of the present application;

FIG. 7 is a schematic diagram of a hash queue index data structure provided in an embodiment of the present application;

FIG. 8 is a schematic diagram of a message structure of an initial flow stage 1 of a hash queue according to an embodiment of the present application;

FIG. 9 is a schematic diagram of a message structure of an initial flow stage 2 of a hash queue according to an embodiment of the present application;

fig. 10 is a schematic diagram of a message structure of an initial flow stage 3 of a hash queue according to an embodiment of the present application;

FIG. 11 is a schematic diagram of a phase 1 message structure provided by an embodiment of the present application;

FIG. 12 is a schematic diagram of a phase 2 message structure provided by an embodiment of the present application;

FIG. 13 is a schematic diagram of a SyncWorker data structure provided by an embodiment of the present application;

FIG. 14 is a schematic diagram of algorithm 2 provided by an embodiment of the present application;

FIG. 15 is a schematic diagram of algorithm 3 provided by an embodiment of the present application;

FIG. 16 is a second flowchart of a block header synchronization method according to the embodiment of the present application;

FIG. 17 is a schematic diagram of initial syncMark results provided by an embodiment of the present application;

FIG. 18 is a third flowchart of a block header synchronization method according to the embodiment of the present application;

FIG. 19 is a flowchart of a block header synchronization method according to an embodiment of the present disclosure;

FIG. 20 is a schematic view of an initial mark 1 provided in an embodiment of the present application;

FIG. 21 is a schematic view of an initial mark 2 provided in an embodiment of the present application;

FIG. 22 is a schematic illustration of marker propagation provided by an embodiment of the present application;

fig. 23 is a schematic diagram of a transport block header stage provided in an embodiment of the present application;

FIG. 24 is a block header redundancy transmission schematic diagram provided in an embodiment of the present application;

fig. 25 is a schematic diagram of a block header synchronization device according to an embodiment of the present application.

Detailed Description

The following description of the embodiments of the present application will be made clearly and fully with reference to the accompanying drawings, in which it is evident that the embodiments described are some, but not all, of the embodiments of the present application. All other embodiments, which can be made by one of ordinary skill in the art based on the embodiments herein without making any inventive effort, are intended to be within the scope of the present application.

The terms first, second and the like in the description and in the claims, are used for distinguishing between similar objects and not necessarily for describing a particular sequential or chronological order. It is to be understood that the terms so used are interchangeable under appropriate circumstances such that the embodiments of the application are capable of operation in sequences other than those illustrated or otherwise described herein, and that the objects identified by "first," "second," etc. are generally of a type and do not limit the number of objects, for example, the first object may be one or more. Furthermore, in the description and claims, "and/or" means at least one of the connected objects, and the character "/", generally means that the associated object is an "or" relationship.

For clarity of description of embodiments of the present invention, related bases and definitions are described herein.

Blockchains represented by bitcoin have been widely paid attention to in industry and academia because of their difficulty in tampering and decentralization. The problems of low block production rate, difficulty in expansion and the like of the account book and the whole network consensus mechanism based on single chains restrict the application of the blockchain technology in a big data scene. To promote ledger TPS, researchers have proposed a patterned ledger based on directed acyclic graph (DAG, directed acyclic graph) structure and a new consensus mechanism.

BDLedger is a patterned ledger developed by North Dacron Rayleigh team based on DAG block organization and Random Witness nRW (n-Random Witness) to solve the requirement of big data evidence. The block head and the block body in the account book are stored separately, the block head is stored in all nodes of the whole network, and the block body is stored in the block producing node, the witness node and the backup node. In the consensus process, in order to make all nodes of the whole network have backup of block headers, newly generated block headers need to be broadcast to the whole network after the witness process is completed, but considering the block production rate of the account book and the complex network state in the distributed environment, the block production nodes cannot wait for the return confirmation of all nodes, which results in that some nodes cannot receive the newly generated block headers in some cases. Consider the following cases that may lead to lost block headers:

the node rejoins after exiting the network. The BDLedger supporting node joins and exits the network for many times, if one node has partial block heads when exiting the network, all newly generated block heads during the offline period are deleted when joining the network again;

the failure of the block-producing node temporarily drops the line, which results in the unsuccessful transmission of the broadcast block header. In this case, only the block-producing node and the witness node are provided, the backup node stores the block head, and other nodes do not have the backup of the new block head;

The failure of the non-consensus node temporarily drops the line resulting in a block header that does not receive the broadcast. In this case, only the failed node does not receive the newly generated block header;

the broadcast block header stage employs unreliable transport protocols. nRW the consensus process does not require what protocol is used for the broadcast process, which may use unreliable transport protocols in order to guarantee TPS. If a packet loss occurs during the network transmission, some nodes cannot receive the newly generated block header.

Secondly, the timing synchronization process refers to a data synchronization process in the Gossip protocol, and each node in Fabric can keep the consistency and the integrity of account book data by using a data synchronization mechanism realized by the Gossip protocol. The Gossip protocol can tolerate a dynamically changing network structure and can propagate messages at the speed of an exponential function, thereby improving the robustness and expandability of the network.

The parts employed herein are defined in relation to the block header synchronization mechanism as follows:

the preamble block and the following block: if block B can be reached from block A along an edge in the DAG ledger, then B is referred to as the leading block of A and A is referred to as the trailing block of B. If there are no other blocks in the path from A to B, then B is said to be the direct predecessor block of A, and A is the direct successor block of B.

Block height: the height of the created block is 1, and the heights of the rest blocks except the created block are the maximum value of the heights in the preamble blocks plus 1.

DAG height: DAG height is defined as the maximum block height in the graph.

Preamble consistency: if for any block A in the DAG ledger, all preamble blocks of A exist in the DAG ledger, then the DAG ledger is said to satisfy the preamble consistency.

In the BDLedger operation process, the drawing ledger always meets the consistency of the block head preamble. In the random witness consensus process, if a node receives a broadcast block header, but finds that some preamble block headers of the block are not available, the node recursively requests the missing preamble block header from the block-generating node until the preamble consistency of the DAG ledger is restored.

Proposing lemma one based on the definition above: if both DAG ledgers satisfy the preamble consistency and the leaf blocks are identical, then both DAG ledgers are identical.

The technical scheme provided by the embodiment of the application is described in detail through specific embodiments and application scenes thereof with reference to the accompanying drawings.

Fig. 1 is a flow chart of a block header synchronization method provided in an embodiment of the present application, which is applied to a first synchronization node in a blockchain, where a hash queue is stored in the blockchain node, and the hash queue is used for a query operation in a synchronization process, and the method includes:

And step 101, when a new block producing node or a network-broken block producing node restores the network, inquiring the position of the hash value synchronized at the last time in the linked list in the hash queue, and identifying a newly generated block based on the position.

Step 102, selecting a second synchronization node, and sending all newly generated leaf block information of the first synchronization node since the last synchronization to the second synchronization node according to the hash queue.

Step 103, receiving the leaf block information lacking in the second synchronization node and the leaf block information newly generated by the second synchronization node, where the leaf block information lacking in the second synchronization node and the leaf block information newly generated by the second synchronization node are sent by the second synchronization node according to the leaf block information newly generated by the first synchronization node.

And step 104, sending the leaf block information of the second synchronous node lacking the leaf block information and the leaf block information of the second synchronous node lacking the first synchronous node to the second synchronous node.

And 105, marking the leaf block head shared by the first synchronous node and the second synchronous node.

And step 106, sending the unmarked leaf block header to the second synchronization node, and receiving the unmarked leaf block header sent by the second synchronization node so as to complete block header synchronization between the first synchronization node and the second synchronization node.

In the embodiments of steps 101 to 106 described above,

optionally, referring to fig. 2, the steps 101 to 106 include:

in step 1011, a hash queue is designed to record the result of the last synchronization for each neighbor node.

In this embodiment, the hash queue is used to calculate the newly generated block header between two syncs. And a series of inquiry functions are provided for the timing synchronization process.

In this example, since the last synchronization result is recorded through the hash queue and used to calculate the newly generated block header between two syncs, the query operation in the synchronization process is completed depending on the hash queue. And a block head timing synchronization module designed for BDLedger is adopted to perform timing synchronization on the first synchronization node and the second synchronization node under the conditions of network structure change and the like. The method can solve the problem that some nodes can not receive newly generated block heads under some conditions, thereby ensuring the integrity and consistency of the block head copies of all nodes in the network.

Further, the demands of the hash queue are as follows:

the first requirement is to eliminate redundant storage. If there are n block headers in the ledger and m neighbor nodes in the node, then at least O (n) space is needed to record the hashes of these blocks, and for each neighbor node, O (m) additional space is needed, with the total spatial complexity being O (n+m) needed.

A second requirement is to be able to record the synchronization results of the node and each surrounding neighbor node. Because during the mark phase of the timing synchronization process, we need to distinguish which block headers have been synchronized in the last timing synchronization and which block headers are newly generated blocks between the two syncs. It is necessary to quickly determine whether a given block header has been completed synchronously or a newly generated block header.

A third requirement is that the direct preamble block of a given block can be queried quickly. In the mark phase of the timing synchronization flow, a forward traversal process is required. When determining which block heads are traversed next, the direct preamble blocks of the traversed block need to be queried according to the preamble relation.

The fourth requirement is to reduce the hard disk IO as much as possible for the inquiry process. The timing synchronization is characterized in that the triggering is more frequent, the number of blocks to be synchronized is less, so that the local marking stage of the hard disk IO (input/output) can be eliminated, and the timing synchronization method accords with the characteristics of high frequency and light weight of the timing synchronization.

Step 1012, when a new block producing node or a broken network block producing node restores the network, inquiring the position of the hash value synchronized at the last time in the linked list in the hash queue, and identifying the newly generated block based on the position.

Further, the neighbor nodes are selected at regular time according to the selection algorithm to carry out the synchronization flow, and synchronization requests sent by other nodes are processed. Performing query operation in the synchronization process by depending on the hash queue;

in this embodiment, each timing synchronization depends on the result of the last timing synchronization, so for each ledger in a node, it is necessary to maintain its synchronization results with all neighbor nodes and record which block headers are newly generated. If a node records synchronized block hashes and newly generated block hashes for all the ledgers of each neighbor node, the overhead of storage may be significant. Assuming that there are n block headers in a certain account of a node and that the node has m neighbor nodes, the node needs to store n×m hashes additionally, where these hashes are obviously repeatedly recorded in m shares, and the additional storage overhead is at least 0 (n×m). The data structure of the hash queue is designed to record the result of the last synchronization and eliminate redundantly stored hashes.

In this embodiment, since the last synchronization result is recorded through the hash queue and used to calculate the newly generated block header between two synchronizations, the query operation in the synchronization process is completed depending on the hash queue. And a block head timing synchronization module designed for BDLedger is adopted to perform timing synchronization on the first synchronization node and the second synchronization node under the conditions of network structure change and the like. The method can solve the problem that some nodes can not receive newly generated block heads under some conditions, thereby ensuring the integrity and consistency of the block head copies of all nodes in the network.

Further, the demands of the hash queue are as follows:

The overall structure of the hash queue is similar to LinkedHashMapo LinkedHashMap, as shown in fig. 3, linkedhassmap stores all the items of the hash table in a doubly linked list according to the insertion sequence, and each node increases the overhead of two pointers, but can execute the query operation in the time of O (1) and traverse all the stored items according to the insertion sequence.

Figure 4 is a schematic diagram of a class diagram of a block header synchronization mechanism provided in an embodiment of the present application,

optionally, the related class diagram of the block header synchronization mechanism is shown in fig. 4, and for brevity and clarity of the class diagram, only methods and fields related to the synchronization mechanism are shown in each class.

The dagLedger class is an abstraction of an account book, and each account book is associated with a synchronous coroutine.

The SyncWorker class is the realization of the synchronization flow, depends on the HashQuue class to store the last synchronization result, and depends on the p2pService class to perform network communication with other nodes.

The HashQueue, hashQueueNode, hashQueueIndex three classes are related implementations of hash queues, the main purpose of which is to store the results of all syncworks last syncs and to provide the necessary query services for the synchronization flow.

Optionally, the step 102 includes:

in this embodiment, fig. 5 is a schematic diagram of a hash queue node data structure provided in an embodiment of the present application,

alternatively, the hash queue is formed by hash queue nodes, and the data structure of each hash queue node is shown in fig. 5. The hash queue is a core data structure in the whole synchronization process, and can store the last synchronization position of two nodes, thereby helping to calculate incremental data between two synchronizations, and almost all inquiry operations in the synchronization process need to be completed by depending on the hash queue.

Alternatively, the data structure of the hash queue is shown in fig. 6.

Alternatively, as shown in fig. 7, the hash queue index holds the position of the last synchronization of a node with a certain neighbor node.

Optionally, the hash queue related interface is as follows:

PutHash (hashBlockHash): adding a piece of hash data to the tail of the hash queue requires maintaining the map and the doubly linked list of the hash queue at the same time.

GetNewGeneratedHashes (peerId string) the hash of all newly generated tile headers since the last synchronization is obtained. And returning all hash queue nodes indexed to the tail of the queue by using the hash queue index.

UpdateSyncedIndex (peeridstring), index hashQueueNode) updates the hash queue index after synchronization is complete.

GetSyncedIndex (peerId string), obtaining the hash queue index of the incoming node.

AddSyncPeer (initIndex hashQueueNode) adds a new synchronization node to the hash queue.

GetMaxIndex (): and obtaining the maximum value of the index of the current hash queue, and returning to the tail of the hash queue.

Size (): the number of hash queue nodes is obtained. The size field of the hash queue is returned directly.

Contains (hash BlockHash) it is determined whether a block hash is included in the hash queue. Whether the hash is included can be directly determined by using the map structure in the hash queue.

In addition to the above interface, after the synchronization module obtains the newly generated block hash, the hash queue node may be used to query the preamble block of the block, thereby implementing the tag propagation flow.

In this embodiment, referring to fig. 8, if a node initiating synchronization does not have hash queue index information of a peer node, or a time stamp in the hash queue index expires, an initialization procedure of the hash queue is required since the last synchronization.

The hash queue initialization flow is divided into 2 phases, namely a leaf node phase and a block head phase, and it is assumed that a node A is a node initiating an initialization request and a node B is a node receiving the initialization request. The implementation of the hash queue initialization procedure is described below in connection with the message body structure of three transmissions.

Alternatively, stage 1, node A sends all She Ziou chunk hashes locally, and the message body structure sent by node A is shown in FIG. 17.

Figure 9 is a schematic diagram of a hash queue initial flow stage 2 message structure provided in an embodiment of the present application,

optionally, stage 2: after receiving the leaf block hash of the a node, the B node can determine that the a node lacks a She Ziou block header existing in the B node and a She Ziou block header lacking locally by comparing with the nodes in the local ledger, and the message body sent by the B node is shown in fig. 9.

Figure 10 is a schematic diagram of a hash queue initial flow stage 3 message structure provided in an embodiment of the present application,

optionally, stage 3: the node A receives the node B leaf block hash, and can also judge which block heads the node B lacks, and send the block lacking by the node B to the node B. The message body structure sent by node a is shown in fig. 10.

Fig. 11 is a schematic diagram of a phase 1 message structure provided in an embodiment of the present application, and fig. 12 is a schematic diagram of a phase 2 message structure provided in an embodiment of the present application.

In this embodiment, the timing synchronization process is a core process of the block header synchronization mechanism, and the message body structures of each stage of the timing synchronization process are described below, and pseudo code implementation of the requester and the responder is provided.

Alternatively, it is still assumed that node a is the node that initiated the synchronization request and node B is the node that receives the synchronization request. After optimization of the transmission process, four data transmissions are required for both nodes. For convenience of explanation hereinafter, the four transmission processes are divided into two "request-response" phases. The data sent by node a to node B twice is referred to as request phase 1 and request phase 2 in sequence, and the data sent by node B to node a twice is referred to as response phase 1 and response phase 2 in sequence. The two-stage message structure is shown in fig. 11 and fig. 12, respectively:

further, after the synchronization node selection is completed, the two nodes need to perform a timing synchronization process. Timing synchronization is mainly accomplished by the syncworkbench class.

Alternatively, in the embodiments of steps 101-106 described above, the two nodes need to perform a timing synchronization process after the synchronization node selection is completed. Timing synchronization is mainly accomplished by the syncworkbench class. Wherein the main fields are shown in fig. 13.

In this embodiment, the timing synchronization module is implemented as an associated working protocol of an account book, each account book being associated with a SyncWorker instance, and the synchronization service being initiated during the initiation of the account book. Since all functions of the timing synchronization module are timing triggers or passive triggers after receiving a synchronization request, the timing synchronization module does not need to provide any interface to the outside.

Alternatively, the timing synchronization requester pseudocode is as shown in FIG. 14.

In this embodiment, the timing synchronization module is required to not only actively initiate a synchronization procedure with the neighboring node, but also receive a request from the neighboring node, so that a function of processing the synchronization request needs to be implemented. The synchronous request is processed by using a flow multiplexing interface in p2p, a Handler is bound for the SyncWorker of each account book, and the p2p layer transmits the synchronous request to the SyncWorker of the corresponding account book according to the account book name in the flow multiplexing protocol.

Alternatively, pseudocode for processing the synchronization request is shown in FIG. 15.

Optionally, referring to fig. 16, the method further includes:

step 201, interactively transmitting She Ziou block header identifiers with the second synchronization node, and additionally transmitting block generating node ids corresponding to the leaf block headers.

In this embodiment, reference is made to fig. 17, which is a schematic diagram of the initial synchronization mark result provided in the embodiment of the present application, and She Ziou pieces of header information are exchanged. Similar to the timing synchronization, the first step of the initial synchronization procedure also exchanges leaf block header information for node a and node B. In the initial synchronization process, two nodes need to transmit the identification of the leaf node and attach the block generating node id corresponding to the leaf block head. The content to be transmitted is as follows:

a- > B, block head 7, block producing node B;

b- > A block header 2 is the block-producing node A, block header 6 is the block-producing node B, and block header 12 is the block-producing node C.

Step 202, determining whether the first synchronization node includes the leaf block header through ledger wall query.

In the present embodiment, referring to fig. 17, a node a is taken as an example. After receiving the leaf block header information of B, the node a sets the block-producing node of each leaf block header X as X, and performs the following operations:

and judging whether the node A contains the block header or not through account book inquiry.

In step 203, if the first synchronization node ledger does not include the leaf block header, the first synchronization node does not perform any operation.

In this embodiment, if the node a account book does not include the block header, it is described that the node B includes the updated block header generated by the X, and the node B must include the block header generated by the X sent to the node B by the node a, and the node a does not perform any operation.

In step 204, if the first synchronization node account book includes the leaf block header and the first synchronization node includes the latest block header generated after the leaf block header, all the block headers between the She Ziou block header and the latest block header are marked as the block header to be updated.

In this embodiment, if node a includes the block header in the account book and node a has a block header y generated by X newer than the block header, all the block headers between X and y are marked as the block header to be transmitted. The calculation process of the node B is the same as that of the node a, and the blocks required to be transmitted by both nodes are marked after the local calculation process, and the result is shown in fig. 17.

Step 205, updating the hash queue according to the block header to be updated, and sending the block header to be updated to the second synchronization node.

In this embodiment, since the blocks required by both nodes are marked by using the block-generating node information to perform accurate calculation, the blocks required to be transmitted are quickly locked, so that there is no block header for redundant transmission in the transmission process.

Further, the purpose of the initial synchronization is to build the information of the "last synchronization" for the timing synchronization as a basis, so that the hash queue needs to be updated after the synchronization is completed, as in the timing synchronization. The hash queue index is moved to the tail of the queue at the beginning of the synchronization.

In general, the above initial synchronization process needs to go through the disk IO. Assuming that the leaf block and its block-generating node id are put into the memory and updated continuously with the generation of the new block, the disk IO may not be passed under the condition that the two node DAG ledgers are identical. Because the initial synchronization flow is oriented to the scene that two nodes are never synchronized or one of the nodes is disconnected and reconnected, the data difference of the two nodes account book is larger. The overhead of local computation, especially disk IO, is quite large. Since the ledger does not have an interface for querying blocks according to the block-producing node, in stage 2, the query operation of "query blocks X to y, blocks generated by the block-producing node X" needs to query all direct preamble block headers thereof from the block y, find the block header generated by the node X, and continue to query the block header until the block header X is found. The greater the number of blocks generated by X between block X and block y, the greater the query overhead. In the case of initial synchronization caused by node offline reconnection, we can simply consider that the number of blocks generated by X between block X and block y is determined by the offline time, that is, the local computational overhead of the initial synchronization process is related to the unsynchronized time of the two nodes.

Optionally, referring to fig. 18, the step 101 includes:

step 1013, finding the position of the last synchronized hash in the linked list according to the block hash value in the index structure of the hash queue.

Step 1014 takes the hash value located after the position as the newly generated block hash value after the last synchronization.

Alternatively, in the present embodiment 1013-1014, the overall structure of the hash queue is similar to LinkedHashMap, linkedHashMap, as shown in fig. 3, linkedhassmap stores all the entries of the hash table in a doubly linked list according to the insertion order, and each node adds two pointers to the overhead, but not only performs the query operation at the time of O (1), but also traverses all the stored entries according to the insertion order.

Optionally, the step 102 includes: and taking out all newly generated block hash values by utilizing the hash queue, and finding out the blocks which are not selected as the preamble block heads by any block heads, namely leaf block information.

In this embodiment, since each account book of the neighboring node of the node corresponds to a hash queue index structure, the position of the last synchronized hash in the linked list can be found according to the block hash in the index structure. The hash located in front of the position is the block hash that has completed the synchronization, and the hash located in back is the newly generated block hash between the two syncs. In the actual synchronization process, the hashes after indexing can be taken out at one time and put into one HashSet, the hashes of the blocks in the HashSet are the blocks which have completed synchronization, and the HashSet is released after the synchronization is completed. Since the number of blocks generated between the two timing synchronization is not large, the method can be used for judging whether a block is a newly generated block or not by using space time exchange, and the time complexity of the operation is reduced to O (1).

Optionally, the steps 101 to 106 include:

the block header synchronization mechanism determines whether the non-leaf block header is in incremental synchronization with the local ledger according to the DAG ledger with preamble consistency to complete timing synchronization.

Optionally, referring to fig. 19, the step 105 includes:

step 1051, initially marking the leaf tile heads of the two nodes.

In step 1052, the same leaf chunk header as the local leaf chunk header is marked according to the newly generated She Ziou chunk header that has been sent by the second node, among all newly generated local She Ziou chunk headers.

In step 1053, among all the newly generated local She Ziou block headers, different leaf block headers of the local leaf block header are marked according to She Ziou block headers missing from the first synchronization node that the second node has sent.

Optionally, the step 105 further includes:

and 1054, marking all the block heads in the newly generated block, which are in a preamble relation with the block with the leaf, according to the block which is common to the first synchronization node and the second synchronization node in the initial marking stage and is the leaf in at least one node.

In the embodiments of steps 1051 to 1054 described above, referring to fig. 20, an initial flag 1 provided in the embodiment of the present application is shown, where the initial flag only occurs in She Ziou block headers of two nodes, and the initial flag identifies redundant block headers according to the block header information in stages 1 and 2. For node a, the block header satisfying the following condition needs to be initially marked.

The initial mark includes: she Ziou block header in node B already locally present. The leaf block header in node B is not necessarily the leaf block header in node a. Thus, node a needs to check, among all newly generated block headers locally, whether there is a block header received from node B in the first stage, and if so, mark the block. The labeling results are shown in FIG. 20.

In this embodiment, reference is made to the local She Ziou block header already present in node B of fig. 21. Node a needs to check all leaf blocks locally and if not present in the block header sent from the second stage node B, marks this block header. The labeling results are shown in FIG. 21.

Further, for node B, the same shall be true for both nodes. After the initial marking phase, the block header, which is common to node a and node B and is a She Ziou block header in at least one node, is marked.

In the present embodiment, if a certain block header in node B exists in node a according to the preamble consistency with reference to fig. 22, all the preamble block headers of the block header in node B exist in node a. The block that is common to nodes a and B and that is a leaf in at least one node has been confirmed in the marking phase. We can start from these block heads, mark all the newly generated blocks with the block heads in the preamble relation to these blocks, and these block heads are also redundant block heads that exist in 2 nodes at the same time. After the marker propagation phase is completed, the results of the markers are shown in fig. 22.

The third stage needs to query the repeated She Ziou blocks and query all the blocks with the preamble relation among the newly generated blocks. For node a, the query of duplicate leaf block heads requires that it be computed from the information received from B which block heads already exist in B and marked again by intersection with the local hash queue. Since each item in the hash queue records the preamble block hash of the block header, all newly generated blocks with the preamble relation with the marked blocks can be queried forward step by step in the DAG graph through the preamble relation recorded by the hash queue until the block header which is not newly generated is found.

In this embodiment, referring to the first three stages of fig. 23, we have marked the blocks determined to be redundant block heads, and all unmarked block heads among the newly generated blocks are transmitted. As shown in fig. 23, all triangle blocks in the fourth stage transmission diagram. The block header to be transmitted is as follows:

a- > B, block header 2, block header 6, block header 7;

b- > a, block header 8.

The fourth stage needs to make difference sets on the newly generated block and the marked block in the two nodes, and can be converted into operation on the hash queue.

The above four phases require 6 network communications, and partial network transmissions may be combined by optimization. Furthermore, as can be seen from the analysis of the query operation at each stage, all the query operations can be converted into operations on the hash queue, and all the queries can be performed only in the newly generated partial blocks, so that it is feasible to perform all the query operations in the memory during the timing synchronization process.

Optionally, the four stages required are specifically set forth in the timing synchronization flow design, where the first stage and the second stage need to transmit hashes of related leaf nodes to support the marking process of the third stage, and the fourth stage needs to transmit the block header missing by the other side of the synchronization node. Except for the third stage, all three stages require two nodes to transmit data to each other, so 6 data transmissions are required. It is readily apparent that some of the data transmissions may be combined. The optimization procedure will be described below taking the synchronization procedure of the AB node as an example, assuming that the a node initiates a synchronization request to the B node. The state before synchronization of the two nodes is shown in fig. 20.

Further, the first stage a- > B transmission process is unchanged: node a sends itself all newly generated leaf chunk hashes since the last synchronization to node B. The data to be transmitted are as follows: a- > B, block 5, block 7.

Further, the first stage B- > a and second stage B- > a transfer processes may be combined: after the node B receives the leaf block information of the node a, it can calculate which leaf blocks in the node a are missing by the node B, and these block hashes can be sent to the node a together with the newly generated leaf block hashes of the node B itself. So that the two phases can be combined. The data to be transmitted are as follows:

b- > a leaf block of B (block 1, block 4, block 8), a leaf block of B lacking (block 7).

Further, the second phase a- > B and fourth phase a- > B transfer processes may be combined: the node A receives the leaf block information of the node B and the leaf block hash of the node A which is missing in the node B, and can complete the marking stage of the node A, so that the block possibly missing by the node B and the leaf block hash information of the node B which is missing in the node A can be sent to the node B together. The data to be transmitted are as follows:

a- > B-block header data (block 2, block 6, block 7), B leaf block lacking a (block 7) further, fourth stage B- > a transmission process is unchanged: the node B can successfully complete the marking process after receiving the leaf block hash missing from the node A, thereby calculating the block missing from the node A and transmitting the block to the node A. The data to be transmitted are as follows:

B- > a: block header data (block 8).

Thus, a total of only 4 data transfers are required to complete the synchronization process.

In this embodiment, not only the number of transmissions may be optimized, but we may also optimize the block header of the redundant transmission. Since neither the redundant block header node a nor node B will be marked, both block header node a and node B will be sent to each other. We can eliminate half of the transmission of the redundant block header while optimizing with the above number of transmissions. After the node B receives the information sent by the node a for the second time, the node a can send the information, but the block heads already existing in the node B are additionally marked, so that redundant blocks cannot be retransmitted once, and half of redundant block head data transmission is eliminated.

In this embodiment, referring to fig. 24, the above synchronization process is taken as an example, since only two blocks missing from each other are actually required to be transmitted in the synchronization process of the node a and the node B, in the actual synchronization process, we transmit not only the block header but also the block header identifier, that is, the block hash. This section will therefore perform redundancy transmission analysis on the block hash and the block header, respectively.

For block hashes, all block hashes can be considered as redundantly transmitted data, since they are not data that we really need to synchronize. In phase 1, it is necessary to transmit hashes of all leaf blocks of two nodes, and in phase 2, it is necessary to transmit hashes of leaf nodes missing each other. In the worst case, node a would miss all She Ziou blocks of node B, and node B would miss all She Ziou blocks of node a, at which time phase 2 would also transmit hashes of all leaf blocks of both nodes. Let the She Ziou block header number of node a be m, the She Ziou block header number of node B be n, and the worst-case number of block hashes for redundant transmissions be 2 x (m+n). Because the number of the leaf blocks in the DAG ledger does not exceed the number of nodes in the network due to the limitation of a preamble block selection mechanism, the upper limits of m and n are the number of the nodes in the network, the nodes are not excessively huge, the space occupied by the block hash is small, and the current BDLedger is 32 bytes, so that the total block hash overhead of redundant transmission is small.

For the block header, the phenomenon of redundant transmission occurs only if: node a has the same block header O as node B and there is no intersection between node a and the leaf node in the node B ledger that has a subsequent relationship with block O, node O will be transmitted redundantly. As shown in fig. 10, both nodes have a block header O, but are not marked as square blocks during marking, and are redundantly transmitted during transmitting blocks.

Since the number of ledger-leaf blocks does not diverge too much. The number of newly generated blocks between the two timing synchronization is not too large, and the number of She Ziou block heads lost due to network abnormality is not too large. When a block with a successor relationship to O is generated and successfully received by node a and node B, the redundancy of the O block is eliminated. The proportion of redundant transmitted block heads during synchronization will be low, as will be seen in more detail in the experimental results that follow.

As can be seen from the timing synchronization process above, the flow of timing synchronization has no special requirement on the DAG morphology of the ledger, but in order to determine whether a non-leaf tile header is present in the local ledger, DAGs are required to have preamble consistency. Meanwhile, since the block header synchronization algorithm is incremental synchronization, it is also necessary to determine which block headers are generated between two synchronizations, and the data structure of the hash queue is adopted to quickly find the increment. Thus, the block header synchronization mechanism herein essentially performs incremental synchronization on DAG structures with preamble consistency, and is equally applicable to incremental synchronization on other DAG ledgers with preamble consistency.

Fig. 25 is a schematic diagram of a block header synchronization device according to an embodiment of the present application. The device comprises: the hash queue module 501 is configured to, when a new block-producing node or a network-broken block-producing node appears and the network is restored, query the hash queue for the position of the hash value synchronized last time in the linked list, and identify a newly generated block based on the position.

A timing synchronization module 502, configured to select a second synchronization node, and send, to the second synchronization node, all newly generated leaf block information of the first synchronization node since the last synchronization according to the hash queue;

Optionally, the hash queue module 501 is further configured to:

the leaf block heads of the two nodes are initially marked;

optionally, the hash queue module 501 is further configured to:

Optionally, the timing synchronization module 502 is further configured to:

It should be noted that, in this document, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one … …" does not exclude the presence of other like elements in a process, method, article, or apparatus that comprises the element. Furthermore, it should be noted that the scope of the methods and apparatus in the embodiments of the present application is not limited to performing the functions in the order shown or discussed, but may also include performing the functions in a substantially simultaneous manner or in an opposite order depending on the functions involved, e.g., the described methods may be performed in an order different from that described, and various steps may also be added, omitted, or combined. Additionally, features described with reference to certain examples may be combined in other examples.

From the above description of the embodiments, it will be clear to those skilled in the art that the above-described embodiment method may be implemented by means of software plus a necessary general hardware platform, but of course may also be implemented by means of hardware, but in many cases the former is a preferred embodiment. Based on such understanding, the technical solution of the present application may be embodied essentially or in a part contributing to the prior art in the form of a software product stored in a storage medium (such as ROM/RAM, magnetic disk, optical disk), including several instructions for causing a terminal (which may be a mobile phone, a computer, a server, an air conditioner, or a network device, etc.) to perform the method described in the embodiments of the present application.

The embodiments of the present application have been described above with reference to the accompanying drawings, but the present application is not limited to the above-described embodiments, which are merely illustrative and not restrictive, and many forms may be made by those of ordinary skill in the art without departing from the spirit of the present application and the scope of the claims, which are also within the protection of the present application.

Claims

1. A method for synchronizing a block header, the method being applied to a first synchronization node in a blockchain, the first synchronization node having a hash queue stored therein, the hash queue being used for a query operation of a synchronization process, the method comprising:

selecting a second synchronization node, and sending all newly generated leaf block information of the first synchronization node since the last synchronization to the second synchronization node according to the hash queue; the second synchronization node is a neighbor node of the first synchronization node;

2. The method according to claim 1, wherein the method further comprises:

judging whether the first synchronous node contains the leaf block head or not through account book inquiry;

3. The method of claim 1, wherein the identifying the newly generated tile based on the location comprises:

4. The method of claim 1, wherein said sending all newly generated leaf block information by the first synchronization node to the second synchronization node in accordance with the hash queue since a last synchronization comprises:

5. The method of claim 1, wherein the block header synchronization method performs timing synchronization based on incremental synchronization of DAG ledgers with preamble consistency.

6. The method of claim 1, wherein the marking operation comprises:

initially marking leaf block heads of the first synchronization node and the second synchronization node;

Marking the same leaf block header of the local leaf block header according to the newly generated She Ziou block header sent by the second synchronous node in all newly generated local She Ziou block headers;

among all newly generated local She Ziou block heads, different leaf block heads of the local leaf block head are marked according to She Ziou block heads which are lack of the first synchronous node and are sent by the second synchronous node.

7. The method of claim 6, wherein the marking operation further comprises:

8. A block header synchronization apparatus, comprising:

the hash queue module is used for inquiring the position of the hash value synchronized at the last time in the linked list in the hash queue when a new block producing node or a broken network block producing node restores the network, and identifying a newly generated block based on the position;

the timing synchronization module is used for selecting a second synchronization node, and sending all newly generated leaf block information of the first synchronization node since the last synchronization to the second synchronization node according to the hash queue; the second synchronization node is a neighbor node of the first synchronization node;

9. An electronic device comprising a processor, a memory and a program or instruction stored on the memory and executable on the processor, which when executed by the processor, implements the steps of the tile head synchronization method of any one of claims 1-7.

10. A readable storage medium, wherein a program or instructions is stored on the readable storage medium, which when executed by a processor, implements the steps of the tile head synchronization method of any one of claims 1-7.