CN115277733A

CN115277733A - Block header synchronization method and device, electronic equipment and storage medium

Info

Publication number: CN115277733A
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: 2022-11-01
Anticipated expiration: 2042-07-29
Also published as: CN115277733B

Abstract

The application discloses a block head synchronization method, a block head synchronization device, electronic equipment and a storage medium, and belongs to the technical field of block chains, wherein the method comprises the following steps: and recording the last synchronization result through the Hash queue, calculating a newly generated block head between two times of synchronization, and finishing the query operation in the synchronization process by depending on the Hash queue. And a block head timing synchronization module designed aiming at the 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 problem that some nodes can not receive the newly generated block head under some conditions can be solved, so that the integrity and consistency of the block head copies of each node in the network are ensured.

Description

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

Technical Field

The present invention relates to the field of block chain technology, and in particular, to a method and an apparatus for synchronizing a block header, an electronic device, and a storage medium.

Background

With the advantages of decentralization and non-falsification, the blockchain technology represented by bitcoin is widely applied to various fields such as cryptocurrency. And because of the limitation of the data structure and the consensus mechanism of the single-chain-based ledger, the block production rate and the expandability of the ledger are difficult to improve. The big north rui team develops a schema book BDLedger for solving the big data storage requirement based on a DAG block organization structure and a random witness 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 production node, the witness node and the backup node. In the consensus process, in order to make all nodes in the whole network have backup of the block header, a newly generated block header needs to be broadcasted to the whole network after the witness process is completed.

Currently, in consideration of the block generation rate of the ledger and the complex network state in the distributed environment, the block generation node cannot wait for the return acknowledgement of all nodes, which results in some cases that some nodes cannot receive the newly generated block header.

Due to the particularity of the diagram type account book, various technologies are relatively immature, and the conventional data synchronization mechanism does not well utilize the preorder consistency of the BDLedger. Therefore, a practical and efficient block header synchronization mechanism needs to be designed for BDLedger.

Disclosure of Invention

An object of the embodiments of the present application is to provide a block header synchronization method, an apparatus, an electronic device, and a storage medium, which can solve the problem that in some cases, some nodes cannot receive a newly generated block header, so that integrity and consistency of block header copies of each node in a network cannot be guaranteed.

In order to solve the technical problem, the present application is implemented as follows:

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

when a new block node or a broken network block node recovers the network, inquiring the position of the last time timing synchronization hash value in the linked list in the hash queue, 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 lacked by the second synchronization node and the leaf block information newly generated by the second synchronization node, wherein the leaf block information lacked by the first 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;

sending the second synchronization node missing leaf block information and the second synchronization node leaf block information that the first synchronization node is missing to the second synchronization node;

marking a block header shared by the first synchronization node and the second synchronization node;

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

Optionally, the method further comprises:

interactively transmitting a leaf block head identifier with the second synchronous node, and additionally transmitting a block generation node id corresponding to the leaf block head;

and judging whether the first synchronization node comprises the leaf sub-block header or not through the account book query.

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

if the first synchronization node account book contains the leaf block head and the first synchronization node contains the latest block head generated after the leaf block head, marking all the block heads between the leaf block head and the latest block head as the block head to be updated;

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

Optionally, the identifying a newly generated block based on the location comprises:

finding the position of the last synchronous hash in a chain table according to the block hash value in the index structure of the hash queue;

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

Optionally, the sending, 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 includes:

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

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

Optionally, the marking operation comprises:

initially marking leaf block headers of the two nodes;

marking, among all newly generated local leaf block headers, leaf block headers that are identical to the local leaf block header according to the newly generated leaf block header that the second node has sent;

marking, among all newly generated local leaf block headers, leaf block headers of different local leaf block headers according to the leaf block headers missing from the first synchronization node that the second node has sent;

optionally, the marking operation further comprises:

marking all block headers which have a preamble relation with the leaf blocks in the newly generated blocks according to the blocks which are shared by the first synchronization node and the second synchronization node in the initial marking stage and are leaf blocks in at least one node.

In a second aspect, an embodiment of the present application provides a block header synchronization apparatus, including:

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

a timing synchronization module: the system comprises a first synchronization node, a second synchronization node and a hash queue, wherein the first synchronization node is used for selecting the 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 a leaf sub-block header shared by the first synchronization node and the second synchronization node;

Optionally, the hash queue module includes:

Optionally, the hash queue module further includes:

initially marking leaf block headers of the two nodes;

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 blocks which are not selected as 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, which includes 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, when executed by the processor, implements the steps of the block header synchronization method according to the first aspect. In a fourth aspect, the present application provides a readable storage medium, on which a program or instructions are stored, which when executed by a processor implement the steps of the block header synchronization method according to the first aspect.

In the embodiment of the application, the last synchronization result is recorded through the hash queue, and the hash queue is used for calculating the block head newly generated between two times of synchronization and finishing the query operation in the synchronization process by depending on the hash queue. And a block head timing synchronization module designed aiming at the 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 problem that some nodes can not receive the newly generated block head under some conditions can be solved, so that the integrity and consistency of the block head copies of each node in the network are ensured.

Drawings

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

fig. 2 is a flowchart illustrating a block header synchronization method according to an embodiment of the present disclosure;

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

FIG. 4 is a block header synchronization mechanism diagram 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 diagram illustrating a hash queue data structure provided by an embodiment of the present application;

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

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

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

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

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

FIG. 12 is a diagram illustrating 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 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 illustrating a block header synchronization method according to an embodiment of the present application;

FIG. 17 is a diagram illustrating an initial synchronization mark result provided by an embodiment of the present application;

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

fig. 19 is a fourth flowchart illustrating a block header synchronization method according to an embodiment of the present application;

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

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

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

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

FIG. 24 is a block header redundancy transmission scheme according to an embodiment of the present application;

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

Detailed Description

The technical solutions in the embodiments of the present application will be described clearly and completely with reference to the drawings in the embodiments of the present application, and it should be understood that the described embodiments are some, but not all embodiments of the present application. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any inventive effort, shall fall within the scope of protection of the present application.

The terms first, second and the like in the description and in the claims of the present application are used for distinguishing between similar elements 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 other sequences than those illustrated or otherwise described herein, and that the terms "first," "second," and the like are generally used herein in a generic sense to distinguish one object from another and not necessarily limit the number of objects, e.g., a first object may be one or more than one. In addition, "and/or" in the specification and the claims means at least one of connected objects, a character "/" generally means that a front and rear related object is in an "or" relationship.

For a better understanding of the embodiments of the present invention, the relevant basic principles and definitions will be described.

Since the advent of blockchains, represented by bitcoins, the blockchains have received a lot of attention from the industry and academia due to their hard-to-tamper, decentralized nature. The single-chain-based account book and the whole-network consensus mechanism restrict the application of the block chain technology in a big data scene due to the problems of low block production rate, difficult expansion and the like. In order to promote TPS of the account book, researchers have proposed a schema book based on a Directed Acyclic Graph (DAG) structure and a new consensus mechanism.

Bdlegger is a schema book developed by north rui team based on DAG block organization structure and Random Witness consensus mechanism nRW (n-Random Witness, n-node Random Witness) to solve the large data storage requirement. 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 production node, the witness node and the backup node. In the consensus process, in order to make all nodes in the whole network have backup of the block headers, a newly generated block header needs to be broadcasted to the whole network after the witness process is completed, but in consideration of the block generation rate of the account book and the complex network state in the distributed environment, the block generation node cannot wait for the return acknowledgement of all nodes, which results in some cases that some nodes cannot receive the newly generated block header. Consider the following several cases that may result in a lost block header:

and the node rejoins after exiting the network. The BDLedger supports nodes to join and leave the network for multiple times, if one node already has part of block headers when leaving the network, all newly generated block headers in the offline period can be lost when the node joins the network again;

a block node failure temporarily goes offline resulting in the broadcast block header not being successfully transmitted. In this case, only the node for producing the block and the witness node are used, the backup node stores the block head, and other nodes do not have the backup of the new block head;

the non-consensus node fails and temporarily drops off resulting in a block header that has not received the broadcast. In this case only the failed node does not receive the newly generated block header;

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

Secondly, the timing synchronization process refers to a data synchronization process in the Gossip protocol, and each node in the Fabric can keep the consistency and the integrity of the ledger 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, so that the robustness and the expandability of the network are improved.

The partial and block header synchronization mechanism employed herein is defined as follows:

preamble block and subsequent block: if block B can be reached from block a along an edge in the DAG book, then B is called a preceding block of a and a following block of B. If there is no other block in the path from A to B, then B is said to be the direct preceding block of A and A is the direct succeeding 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 height in the preamble block plus 1.

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

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

During operation of the BDLedger, the schema ledger always satisfies the consistency of the block headers. In the random witness process, if a node receives a block header broadcast but finds that there are no some preamble block headers for the block, the node recursively requests the producing node for the missing preamble block headers until the preamble consistency of the DAG ledger is restored.

Based on the above definitions, a lemma one is proposed: if both DAG ledgers satisfy prologue consistency and the leaf sub-blocks are identical, then the two DAG ledgers are identical.

The technical solutions provided by the embodiments of the present application are described in detail below with reference to the accompanying drawings through specific embodiments and application scenarios thereof.

Fig. 1 is a schematic flow chart of a block header synchronization method provided in an embodiment of the present application, and is applied to a first synchronization node in a block chain, where hash queues are stored in the block chain nodes, and the hash queues are used in query operations in a synchronization process, where the method includes:

and 101, when a new block node or a broken block node recovers the network, inquiring the position of the last time timing synchronization hash value in the hash queue in the linked list, 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 lacked by the second synchronization node and the leaf block information newly generated by the second synchronization node, wherein the leaf block information lacked by the first 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.

Step 104, sending the second synchronization node lacking leaf block information and the second synchronization node lacking leaf block information of the first synchronization node to the second synchronization node.

And 105, marking the leaf sub-block head shared by the first synchronization node and the second synchronization node.

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 the block header synchronization between the first synchronization node and the second synchronization node.

In the embodiment of steps 101 to 106 described above,

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

at 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 chunk header between two synchronizations. Meanwhile, a series of inquiry functions are provided for the timing synchronization process.

In this example, since the last synchronization result is recorded by the hash queue and is used for calculating the newly generated block header between two times of synchronization, the query operation in the synchronization process is completed by relying on the hash queue. And a block head timing synchronization module designed aiming at the 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 problem that some nodes can not receive the newly generated block head under some conditions can be solved, so that the integrity and consistency of the block head copies of each node in the network are ensured.

Further, the hash queue needs to be as follows:

the first requirement is to eliminate redundant storage. If the account book has n block headers and the node has m neighbor nodes, at least the space of O (n) is needed to record the hash of the blocks, and for each neighbor node, the synchronous result also needs to be recorded, the extra space of O (m) is needed, and the total space complexity is O (n + m).

The second requirement is to be able to record the synchronization results of the node and each surrounding neighbor node. Because in the marking phase of the timing synchronization flow, we need to distinguish which block headers have been synchronized in the last timing synchronization and which block headers are newly generated blocks between two synchronizations. 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 the ability to quickly query out the immediate preamble block of a given block. In the marking stage of the timing synchronization process, a forward traversal process is required. When determining which block headers are traversed next time, the direct preamble block of the block traversed this time needs to be queried according to the preamble relation.

A fourth requirement is that the query process minimizes hard disk IO. The timing synchronization has the characteristics of frequent triggering and less number of blocks needing synchronization, so that a local marking stage of a hard disk IO (input/output) can be eliminated, and the timing synchronization can be quickly completed and is in line with the characteristics of high frequency and light weight of the timing synchronization.

Step 1012, when a new block node or a broken block node recovers the network, querying the position of the last time timing synchronization hash value in the linked list in the hash queue, and identifying a newly generated block based on the position.

Further, a neighbor node is selected at regular time to perform a synchronization process depending on a selection algorithm, and synchronization requests sent by other nodes are processed. Relying on the Hash queue to perform query operation in the synchronization process;

in this embodiment, each timing synchronization depends on the result of the last timing synchronization, so for each book in a node, it is necessary to maintain the synchronization results with all neighboring nodes and record which block headers are newly generated block headers. If a node records synchronized and newly generated chunk hashes for all ledgers for each neighbor node, then the overhead of storage can be significant. Assuming that there are n block headers in a certain account book of a node and the node has m neighbor nodes, the node needs to store n × m additional hashes, which are obviously recorded m times, and the additional storage overhead is at least 0 (n × m). Thus, a hash queue data structure is designed herein to record the result of the last synchronization and eliminate the hash of the redundant storage.

In this embodiment, since the last synchronization result is recorded by the hash queue and is used for calculating a newly generated block header between two times of synchronization, the query operation in the synchronization process is completed by relying on the hash queue. And a block head timing synchronization module designed aiming at the 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 problem that some nodes can not receive the newly generated block head under some conditions can be solved, so that the integrity and consistency of the block head copies of each node in the network are ensured.

Further, the hash queue needs to be as follows:

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

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

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

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

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

The SyncWorker class is used for realizing a synchronization process, and stores the last synchronization result by relying on a HashQueue class, and performs network communication with other nodes by relying on a p2pService class.

Three classes of HashQueue, hashQueueNode and HashQueueIndex are related implementation of the Hashqueue, and are mainly used for storing results of last synchronization of all SyncWorkers and providing necessary query service for a synchronization process.

Optionally, the step 102 includes:

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

optionally, the hash queue is formed by hash queue nodes, and a 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, so as to help calculate the incremental data between two synchronizations, and almost all query operations in the synchronization process need to be completed by relying on the hash queue.

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

Optionally, as shown in fig. 7, the hash queue index stores the last synchronization position of the node with a neighbor node.

Optionally, the hash queue related interface is as follows:

push hash (hashblockackhash): adding a hash datum to the tail of the hash queue, and maintaining the map and the doubly linked list of the hash queue at the same time.

GetNewGenerated hashes (peerId string), a hash of all newly generated chunk headers obtained since the last synchronization. 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 (peerIdstring) obtains the hash queue index of the incoming node.

AddSyncPeer (peerId string, initIndex hashQueueNode) adds a new sync node to the hash queue.

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

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

Contains (hash BlockHash) determines whether a hash queue Contains a chunk hash. Whether the hash is contained can be directly judged by using a map structure in the hash queue.

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

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 timestamp in a hash queue index expires and is too long from the last synchronization, an initialization procedure of a hash queue is required.

The hash queue initialization process is divided into 2 stages, namely a stage of exchanging leaf nodes and a stage of exchanging block headers, and a node A is assumed to be a node initiating an initialization request, and a node B is assumed to be a node receiving the initialization request. The implementation of the hash queue initialization procedure is described below with reference to the message body structure of three transmissions.

Optionally, in stage 1, node a sends all local leaf chunk header hashes, and a 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 node a, the node B may determine, by comparing with the node in the local ledger, that the node a lacks a leaf block header existing in the node B and the local lacking leaf block header, and a message body sent by the node B is as shown in fig. 9.

Figure 10 is a diagram illustrating a stage 3 message structure of an initial flow of a hash queue according to an embodiment of the present application,

optionally, stage 3: the node A receives the leaf block hash of the node B, can also judge which block heads are lacked by the node B, and sends the lacked blocks of the node B to the node B. The structure of the message body 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 following introduces message body structures of each stage of the timing synchronization process and provides pseudo code implementation of the requester and the responder.

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

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

Optionally, in the above embodiments of steps 101-106, after the synchronization node selection is completed, the two nodes need to perform a timing synchronization process. Timing synchronization is mainly accomplished by SyncWorker class. With the main fields shown in figure 13.

In this embodiment, the timing synchronization module is implemented as a work coroutine associated with one book, each book is associated with one SyncWorker instance, and a synchronization service is started in the starting process of the book. Because all functions of the timing synchronization module are triggered in a timing mode or are triggered after receiving a synchronization request, the timing synchronization module does not need to provide any interface for the outside.

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

In this embodiment, since the timing synchronization module not only needs to actively initiate a synchronization process with the neighboring node, but also needs to receive a request from the neighboring node, a function of processing a synchronization request needs to be implemented. And the p2p layer transmits the synchronization request to the SyncWorker corresponding to the account book according to the account book name in the stream multiplexing protocol.

Alternatively, pseudo code for handling a synchronization request is shown in FIG. 15.

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

step 201, a leaf sub-block head identifier is interactively transmitted with the second synchronization node, and a block production node id corresponding to the leaf sub-block head is additionally transmitted.

In this embodiment, referring to fig. 17, which is a schematic diagram of an initial synchronization mark result provided in an embodiment of the present application, leaf block header information is exchanged. Similar to 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 not only need to transmit the identification of a leaf node, but also need to attach a block generation node id corresponding to the head of the leaf sub-block. The content to be transmitted is as follows:

a- > B is a block head 7 and a block production node B;

b- > A, a block head 2, a block production node A, a block head 6, a block production node B, a block head 12 and a block production node C.

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

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

whether the block header is contained in the node A is judged through the account book query.

Step 203, if the first synchronization node ledger does not include the leaf sub-block header, the first synchronization node does not perform any operation.

In this embodiment, if the node a account does not include the block header, which indicates that the node B includes the updated block header generated by X, the node B inevitably includes the block header generated by X that the node a sends to the node B, and the node a does not do anything.

Step 204, if the first synchronization node book includes the leaf sub-block header and the first synchronization node includes the latest block header generated after the leaf sub-block header, all block headers between the leaf sub-block header and the latest block header are marked as block headers to be updated.

In this embodiment, if node a includes this block header in the ledger and node a has block header y generated by X that is more recent than this block header, then all block headers between X and y are marked as block headers to be transmitted. The calculation process of node B is the same as that of node a, and the blocks that need to be transmitted by both nodes are marked through 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 the embodiment, the blocks required by the two nodes are marked by utilizing the information of the block generating nodes to accurately calculate, and the blocks required to be transmitted are quickly locked, so that redundant block headers are not generated in the transmission process.

Further, the purpose of the initial synchronization is to construct information of "last synchronization" based on the timing synchronization, 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 end of the queue at the beginning of synchronization.

Generally, the above procedure of initial synchronization needs to go through a disk IO. If the leaf block and the node id of the generated block are put into the memory and are continuously updated along with the generation of the new block, the DAG accounts of the two nodes are completely the same, and the DAG may not pass through the disk IO. Because the initial synchronization process is oriented to a scene that two nodes are never synchronized or one node is offline and reconnected, the difference of the account book data of the two nodes is large. The local computation overhead, especially the overhead of disk IO, is significant. Since the account book does not have an interface for querying the block according to the block generation node, in stage 2, the query operation "query the block generated by the block generation node X between the block X and the block y" needs to start from the block y, query all the direct preamble block headers thereof, find the block header generated by the node X, and continue querying the block header until the block header X is found. The greater the number of blocks between block X and block y resulting from X, 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 computation 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:

and 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.

And 1014, taking the hash value behind the position as the newly generated block hash value after the last synchronization.

Optionally, in this embodiments 1013-1014, the overall structure of the hash queue is similar to the linked hashmap, the structure of the linked hashmap is as shown in fig. 3, the linked hashmap stores all the entries of the hash table in one doubly linked list according to the insertion order, and each node adds the overhead of two pointers, but not only can perform the query operation in the time of O (1), but also can traverse all the stored entries according to the insertion order.

Receiving the leaf block information lacking in the second synchronization node and the leaf block information newly generated by the second synchronization node, wherein the leaf block information lacking in the first 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;

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

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

In this embodiment, each account book of the neighbor node of the node corresponds to one hash queue index structure, and 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 at the front of the position is the block hash that has completed synchronization, and the hash at the back is the newly generated block hash between two synchronizations. In the actual synchronization process, the hash after indexing can be taken out at one time and put into a HashSet, the block hash in the HashSet is not the block which is synchronized, and the HashSet is released after synchronization is completed. Since the number of blocks generated between two timing synchronizations is not large, the time complexity of the operation of determining whether a block is a newly generated block or not can be reduced to O (1) by using the method and changing the time space.

Optionally, the steps 101 to 106 include:

the block header synchronization mechanism judges whether the non-leaf block header exists in the local ledger or not according to the incremental synchronization of the DAG ledger with the preamble consistency so as to complete timing synchronization.

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

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

Step 1052, among all newly generated local leaf block headers, marking the same leaf block header of the local leaf block headers according to the newly generated leaf block header that the second node has sent.

Step 1053, among all newly generated local leaf block headers, marking different leaf block headers of the local leaf block headers according to the leaf block headers which are sent by the second node and are lacked by the first synchronization node.

Optionally, step 105 further includes:

step 1054, according to the blocks which are shared by the first synchronization node and the second synchronization node and are leaves in at least one node in the initial marking stage, marking all block headers which have a preamble relation with the blocks which are leaves in the newly generated blocks.

In the embodiment of steps 1051 to 1054, reference is made to fig. 20, which is a schematic diagram of an initial marker 1 provided in the embodiment of the present application, where the initial marker only occurs in leaf block headers of two nodes, and the initial marker identifies redundant block headers according to the block header information in

stages

1 and 2. For node a, the block header that satisfies the following condition needs to be initially marked.

The initial mark includes: leaf sub-block header in node B already existing locally. The leaf block header in node B is not necessarily the leaf block header in node a. Therefore, node a needs to check if there is a block header sent from node B received in the first stage in all the locally generated block headers and if so, mark this block. The labeling results are shown in FIG. 20.

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

Further, for the node B, the same principle also needs to be performed for initial marking of the above two nodes. After the initial marking stage, a block header that is common to both node a and node B and is a leaf block header in at least one node is marked.

In the present embodiment, referring to fig. 22, according to the preamble consistency, if a certain block header in node B exists in node a, preamble block headers of all the block headers in node B exist in node a. Blocks that are common to nodes a and B and that are leaves in at least one node have been identified in the tagging phase. From these block headers, we can mark all block headers in the newly generated block that have a preamble relationship with these blocks, and these block headers are also redundant block headers existing in 2 nodes at the same time. The result of the tagging after the tag propagation phase is complete is shown in fig. 22.

The third stage needs to query the newly generated block for repeated leaf block headers and query all blocks with preamble relations. For the node a, querying repeated leaf block headers needs to calculate which block headers already exist in the node B according to the information received from the node B, perform intersection operation with a local hash queue, and perform marking. Because each item in the hash queue records the block hash of the preamble of the block head, all the blocks which are newly generated and have preamble relation with the marked block can be inquired forward step by step in the DAG by the preamble relation recorded by the hash queue until the block head which is not newly generated is found.

In the present embodiment, referring to the first three stages of fig. 23, we have marked the block determined to be the redundant block header, and all the unmarked block headers in the newly generated block are transmitted. As shown in fig. 23, the fourth stage transmits all the triangular blocks in the diagram. The block header that needs to be transmitted is as follows:

a- > B is a block head 2, a block head 6 and a block head 7;

b- > A block head 8.

In the fourth stage, a difference set needs to be made between the newly generated block and the marked block in the two nodes, and the difference set can also be converted into an operation on the hash queue.

The above four stages require 6 network communications, and partial network transmissions can be combined through optimization. In addition, as can be seen from the analysis of the query operations 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 block, so that it is feasible to perform all the query operations in the memory during the timing synchronization process.

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

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

Further, the first stage B- > a and second stage B- > a transfer processes may be merged: after the node B receives the leaf chunk information of the node a, it can already calculate which leaf chunks in the node a are missing from the node B, and can send these chunk hashes to the node a together with the newly generated leaf chunk hash of the node B itself. The two stages can be combined. The data that needs to be transmitted are as follows:

b- > a B leaf blocks (block 1, block 4, block 8), B missing a leaf blocks (block 7).

Further, the second stage a- > B and fourth stage 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 absent from the node B, and the marking stage of the node a can be completed, so that the block possibly absent from the node B and the leaf block hash information of the node B absent from the node a can be sent to the node B together. The data that needs to be transmitted are as follows:

a- > B Block header data (Block 2, block 6, block 7), A missing B leaf Block (Block 7)

Further, the fourth phase B- > a transmission process is unchanged: the node B receives the hash of the leaf block missing from the node A, and can smoothly complete the marking process, thereby calculating the block missing from the node A and transmitting the blocks to the node A. The data that needs to be transmitted are as follows:

b- > A block header data (block 8).

Therefore, a total of 4 data transmissions are required to complete the synchronization process.

In this embodiment, not only the number of transmissions can be optimized, but also the header of the redundant transmission can be optimized. Since neither the redundant block header node a nor node B is marked, both the block header node a and node B are sent to the other. We can eliminate the transmission of half of the redundant block header while utilizing the above transmission times optimization. After the node B receives the information sent by the node a for the second time, the node a may send the information, but the block headers already existing in the node B are marked additionally, so that the redundant blocks are not transmitted again, and half of the redundant block header data transmission is eliminated.

In this embodiment, referring to fig. 24, for example, in the above synchronization process, since only two blocks that are missing from each other actually need to be transmitted in the synchronization process of node a and node B, in the actual synchronization process, we have transmitted not only the block header but also the block header identifier, i.e. the block hash. This section will therefore perform redundant transport analysis separately for the chunk hash and the chunk header.

For the chunk hash, since it is not data that we really need to synchronize, all the chunk hashes can be regarded as redundantly transmitted data. In phase 1, the hash of all leaf sub-blocks of two nodes needs to be transmitted, and in phase 2, the hash of leaf nodes missing from each other needs to be transmitted. In the worst case, node a may miss all leaf block headers of node B, and node B may also miss all leaf block headers of node a, and at this time, stage 2 may also transmit hashes of all leaf blocks of two nodes. Let the number of leaf block heads of node a be m, and the number of leaf block heads of node B be n, and the worst case block hash number for redundant transmission be 2 x (m + n). Due to the limitation of a preamble block selection mechanism, the number of leaf sub-blocks in a DAG account does not exceed the number of nodes in a network, so that the upper limits of m and n are the number of nodes in the network, and are not excessively large, the space occupied by block hash is small, and is 32 bytes in the current BDLedger, and the block hash overhead of redundant transmission is small overall.

For the block header, the phenomenon of redundant transmission occurs only in the following cases: node a and node B both have the same block header O, and node a and a leaf node in the node B ledger that has a subsequent relationship with block O do not intersect, node O will be redundantly transmitted. As shown in fig. 10, both nodes AB have a block header O, but are not marked as square blocks during marking, and are redundantly transmitted during block transmission.

Since the number of ledger leaf blocks does not diverge too much. The newly generated blocks between two timing synchronizations are not too many, and the number of the leaf block headers lost due to network abnormality is not too many. When blocks with a subsequent relationship to O are generated and successfully received by node a and node B, the redundancy of the O blocks is eliminated. The proportion of the redundant transmitted block header during synchronization is also low, as can be seen in the experimental results described later.

As can be seen from the timing synchronization process in the foregoing, the flow of timing synchronization has no special requirement on the DAG form of the ledger, but in order to determine whether the non-leaf block header exists in the local ledger, it is necessary that the DAG has preamble consistency. Meanwhile, because the block head synchronization algorithm is incremental synchronization, it is also necessary to determine which block heads are generated between two times of synchronization, and the data structure of the hash queue is adopted to quickly find the increment. Therefore, the block header synchronization mechanism in this document is essentially to perform incremental synchronization on the DAG structure with preamble consistency, and is also applicable to perform incremental synchronization on other DAG ledgers with preamble consistency.

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

A timing synchronization module 502, configured to select a second synchronization node, and send 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;

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

initially marking leaf block headers of the two nodes;

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

marking all block heads which have a preamble relation with the blocks which are leaves in the newly generated blocks according to the blocks which are shared by the first synchronization node and the second synchronization node in the initial marking stage and are leaves in at least one node.

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

if the first synchronization node book comprises the leaf sub-block head and the first synchronization node comprises a latest block head generated after the leaf sub-block head, marking all the block heads between the leaf sub-block head and the latest block head as block heads to be updated;

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, the element defined by the phrases "comprising a" \8230; "does not exclude the presence of additional identical elements in the process, method, article, or apparatus that comprises the element. Further, it should be noted that the scope of the methods and apparatuses in the embodiments of the present application is not limited to performing the functions in the order illustrated or discussed, but may include performing the functions in a substantially simultaneous manner or in a reverse order based on the functions recited, e.g., the described methods may be performed in an order different from that described, and various steps may be added, omitted, or combined. Additionally, features described with reference to certain examples may be combined in other examples.

Through the above description of the embodiments, those skilled in the art will clearly understand that the above embodiment method can be implemented by software plus a necessary general hardware platform, and certainly can also be implemented by hardware, but in many cases, the former is a better embodiment. Based on such understanding, the technical solutions of the present application may be substantially or partially embodied in the form of a software product stored in a storage medium (e.g., ROM/RAM, magnetic disk, optical disk), and including instructions for enabling a terminal (e.g., a mobile phone, a computer, a server, an air conditioner, or a network device) to execute the method according to the embodiments of the present application.

While the present embodiments have been described with reference to the accompanying drawings, it is to be understood that the invention is not limited to the precise embodiments described above, which are meant to be illustrative and not restrictive, and that various changes may be made therein by those skilled in the art without departing from the scope of the invention as defined by the appended claims.

Claims

1. A block head synchronization method is applied to a first synchronization node in a block chain, wherein a hash queue is stored in the block chain node, and the hash queue is used for query operation of a synchronization process, and the method comprises the following steps:

sending the second synchronization node missing leaf block information and the second synchronization node leaf block information that the first synchronization node lacks to the second synchronization node;

2. The method of claim 1, further comprising:

interactively transmitting a leaf sub-block head identifier with the second synchronous node, and additionally transmitting a block generation node id corresponding to the leaf sub-block head;

judging whether the first synchronization node comprises the leaf sub-block head or not through the account book query;

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

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

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

4. The method of claim 1, wherein 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 comprises:

5. The method of claim 1, wherein the block header synchronization method relies on incrementally synchronizing a DAG ledger with prologue consistency to complete timing synchronization.

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

initially marking leaf block headers of the two nodes;

in all newly generated local leaf block headers, marking a leaf block header different from the local leaf block header according to the leaf block header missing from the first synchronization node that the second node has sent.

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

marking all block headers in the newly generated blocks, which have a preamble relation with the blocks which are leaves, according to the blocks which are shared by the first synchronization node and the second synchronization node in the initial marking stage and are leaves in at least one node.

8. A block header synchronization apparatus, comprising:

the hash queue module is used for inquiring the position of the last time timing synchronization hash value in a linked list when a new block node appears or a broken network block node recovers 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;

9. An electronic device comprising a processor, a memory, and a program or instructions stored on the memory and executable on the processor, the program or instructions when executed by the processor implementing the steps of the block header synchronization method according to any one of claims 1 to 7.

10. A readable storage medium, on which a program or instructions are stored, which program or instructions, when executed by a processor, carry out the steps of the block header synchronization method according to any one of claims 1 to 7.