CN111211876B

CN111211876B - Method and device for sending response message aiming at data request and block chain system

Info

Publication number: CN111211876B
Application number: CN202010002463.7A
Authority: CN
Inventors: 陈锐
Original assignee: Alipay Hangzhou Information Technology Co Ltd
Current assignee: Alipay Hangzhou Information Technology Co Ltd
Priority date: 2020-01-02
Filing date: 2020-01-02
Publication date: 2021-10-12
Anticipated expiration: 2040-01-02
Also published as: CN111211876A; WO2021135755A1

Abstract

An embodiment of the present specification provides a method for sending a response message for a data request, including: responding to a data request aiming at a plurality of data, and assembling at least one piece of data to be sent in each piece of data to be sent into a batch response message aiming at each piece of data to be sent in the plurality of data; determining whether the current batch response message meets a current checkpoint condition; when the current batch response message meets the current check point condition, determining the current batch response message as a current check point, and determining whether the size of the current batch response message exceeds a preset threshold value; and when the size of the current batch response message exceeds the preset threshold value, sending the batch response message corresponding to the previous check point to a data request sender.

Description

Method and device for sending response message aiming at data request and block chain system

Technical Field

The embodiments of the present specification relate to the field of blockchain technology, and in particular, to a method and an apparatus for sending a response message for a data request, and a blockchain system.

Background

The blockchain system is a decentralized, distributed data storage system that is participated in by multiple nodes. Once data is written to the blockchain on each node, on one hand, it means that the data is disclosed in the blockchain network, and on the other hand, the data written to the blockchain is also difficult to delete and tamper with. In addition, the centralized facility may also store data in a manner similar to blockchain storage (which may be considered centralized blockchain storage).

There are typically multiple participating nodes in a blockchain system. The consistency of respective data is ensured among the existing participating nodes through a consensus protocol. However, when a participating node fails, a new participating node joins, or other various reasons occur, data of a participating node may be caused to lag other normal participating nodes. Therefore, the blockchain system needs to use a data synchronization protocol to ensure that the laggard participating nodes can make the locally maintained data catch up with other normal participating nodes, thereby participating in the normal consensus process. When a participating node finds that the data maintained by itself lags behind other normal nodes, it can initiate a data synchronization process, i.e. request the normal participating nodes for the missing data. The regular node may send the data requested by the laggard participating node to the laggard participating node in a reply message when receiving the data request.

Disclosure of Invention

In view of the foregoing, embodiments of the present specification provide a method and an apparatus for sending a response message to a data request, and a block chain system.

According to an aspect of embodiments of the present specification, there is provided a method for transmitting a response message to a data request, including: responding to a data request aiming at a plurality of data, and assembling at least one piece of data to be sent in each piece of data to be sent into a batch response message aiming at each piece of data to be sent in the plurality of data; determining whether the current batch response message meets a current checkpoint condition; when the current batch response message meets the current check point condition, determining the current batch response message as a current check point, and determining whether the size of the current batch response message exceeds a preset threshold value; and when the size of the current batch response message exceeds the preset threshold value, sending the batch response message corresponding to the previous check point to a data request sender.

Optionally, in another example, the method may further include: storing the current batch response message when the size of the current batch response message does not exceed the predetermined threshold; and deleting the stored batch response message corresponding to the previous check point.

Optionally, in another example, the checkpoint condition corresponding to each checkpoint may be generated based on the amount of data to be sent that has been assembled into the batch response message.

Optionally, in another example, the difference between the number of data to be sent corresponding to each check point and the previous check point may be increased.

Optionally, in another example, when the number of the determined check points does not exceed the predetermined number, the difference between the number of the data to be transmitted corresponding to each check point and the previous check point may be incremented, and/or when the number of the determined check points exceeds the predetermined number, the difference between the number of the data to be transmitted corresponding to each check point and the previous check point may be decremented.

Alternatively, in another example, the data request sender may include a block link point behind data in a block chain system, the data request may include a block data synchronization request, and the data may include block data missing at the block link point.

According to another aspect of embodiments of the present specification, there is also provided an apparatus for transmitting a response message to a data request, including: the batch response message assembling unit is used for responding to a data request aiming at a plurality of data, and assembling at least one data to be sent in each data to be sent into a batch response message aiming at each data to be sent in the plurality of data; the check point determining unit is used for determining that the current batch response message meets the current check point condition and determining the current batch response message as the current check point when the current batch response message meets the current check point condition; a message size determining unit that determines whether the size of the current batch response message exceeds a predetermined threshold; and the batch response message sending unit is used for sending the batch response message corresponding to the previous check point to the data request sender when the size of the current batch response message exceeds the preset threshold.

Optionally, in another example, the apparatus may further include: a batch response message storage unit that stores the current batch response message when the size of the current batch response message does not exceed the predetermined threshold; and the batch response message deleting unit deletes the stored batch response message corresponding to the previous check point.

According to another aspect of embodiments herein, there is also provided a blockchain system, including: a first blockchain node that, upon determining that predetermined data is absent with respect to a second blockchain node, transmits a data request for the absent plurality of predetermined data to the second blockchain node; and a second blockchain node comprising an apparatus as described above.

Alternatively, in another example, the data request may include a block data synchronization request, and the predetermined data may include block data missing at the first block link point.

According to another aspect of embodiments of the present specification, there is also provided a computing device including: at least one processor; and a memory storing instructions that, when executed by the at least one processor, cause the at least one processor to perform the method as described above.

According to another aspect of embodiments herein, there is also provided a non-transitory machine-readable storage medium storing executable instructions that, when executed, cause the machine to perform the method as described above.

By using the method and the device in the embodiment of the present specification, after at least one piece of data to be sent in each piece of data to be sent is assembled into a batch response message, it is determined whether the current batch response message is a checkpoint, and when the current batch response message is a checkpoint, it is determined whether the current batch response message exceeds a predetermined threshold, and when the current batch response message exceeds the predetermined threshold, the batch response message corresponding to the previous checkpoint is sent to the data request sender, so that not only can the size of the sent response message approach the predetermined threshold as much as possible under the condition that the size of the sent response message does not exceed the predetermined threshold, so as to improve the utilization efficiency of network resources, but also reduce the amount of operation consumed by determining the size of the response message.

Drawings

A further understanding of the nature and advantages of the contents of the embodiments of the present specification may be realized by reference to the following drawings. In the drawings, similar components or features may have the same reference numerals. The accompanying drawings, which are included to provide a further understanding of the embodiments of the invention and are incorporated in and constitute a part of this specification, illustrate embodiments of the invention and together with the detailed description serve to explain the embodiments of the invention. In the drawings:

FIG. 1 depicts a schematic diagram of an example of an environment that may be used to perform a method for sending a reply message to a data request according to embodiments of the present specification;

fig. 2 shows a schematic diagram of an example of a system architecture to perform a method for sending a reply message to a data request according to an embodiment of the present specification;

FIG. 3 is a flow chart illustrating an exemplary application scenario of a method for sending a reply message to a data request in accordance with the present specification;

FIG. 4 is a flow diagram of a method for sending a reply message to a data request in accordance with one embodiment of the present description;

FIG. 5 is a flow diagram of a method for sending a reply message to a data request according to another embodiment of the present description;

FIG. 6 is a flow diagram illustrating a checkpoint in a method for sending a reply message to a data request according to one embodiment of the present description;

FIG. 7 is a block diagram of an apparatus for sending a reply message to a data request according to one embodiment of the present description;

FIG. 8 is a block diagram of a blockchain system according to one embodiment of the present description; and

fig. 9 is a block diagram of a computing device for implementing a method for sending a reply message to a data request according to one of the embodiments of the present specification.

Detailed Description

The subject matter described herein will be discussed with reference to example embodiments. It should be understood that these embodiments are discussed only to enable those skilled in the art to better understand and thereby implement the subject matter described herein, and are not intended to limit the scope, applicability, or examples set forth in the claims. Changes may be made in the function and arrangement of elements discussed without departing from the scope of the embodiments of the disclosure. Various examples may omit, substitute, or add various procedures or components as needed. In addition, features described with respect to some examples may also be combined in other examples.

As used herein, the term "include" and its variants mean open-ended terms in the sense of "including, but not limited to. The term "based on" means "based at least in part on". The terms "one embodiment" and "an embodiment" mean "at least one embodiment". The term "another embodiment" means "at least one other embodiment". The terms "first," "second," and the like may refer to different or the same object. Other definitions, whether explicit or implicit, may be included below. The definition of a term is consistent throughout the specification unless the context clearly dictates otherwise.

A method and an apparatus for sending a response message to a data request, and a block chain system according to embodiments of the present specification are now described with reference to the drawings.

The block chain is a chain data structure formed by connecting and combining data blocks according to a time sequence, and the data blocks are guaranteed to be not falsifiable and not forged in a cryptographic mode. A block chain includes one or more blocks. Each chunk in the chain of chunks is linked to the immediately preceding chunk in the chain of chunks by including a cryptographic hash of the preceding chunk. Each chunk also includes a timestamp, a cryptographic hash of the chunk, and one or more transactions (transactions). Transactions that have been verified by nodes of the blockchain network are hashed and form a Merkle tree. In a Merkle tree, data at leaf nodes is hashed and, for each branch of the Merkle tree, all hash values of the branch are concatenated at the root of the branch. The above process is performed for the Merkle tree up to the root node of the entire Merkle tree. The root node of the Merkle tree stores a hash value representing all the data in the Merkle tree. When a hash value claims to be a transaction stored in the Merkle tree, a quick verification can be performed by determining whether the hash value is consistent with the structure of the Merkle tree.

A blockchain is a data structure used to store transactions. A blockchain network is a network of computing nodes used to manage, update and maintain one or more blockchain structures. As described above, the blockchain network may include a public blockchain network, a private blockchain network, or a federated blockchain network.

In a public blockchain network, the consensus process is controlled by nodes of the consensus network. For example, there may be thousands of entity co-processes in a public blockchain network, each entity operating at least one node in the public blockchain network. Thus, a public blockchain network may be considered a public network of participating entities. In some examples, most entities (nodes) must sign each chunk in sequence and add the signed chunk to the blockchain of the blockchain network. An example of a public blockchain network may include a particular peer-to-peer payment network. Furthermore, the term "blockchain" does not particularly refer to any particular blockchain.

Public blockchain networks support public transactions. Public transactions are shared among all nodes within a public blockchain network and are stored in a global blockchain. A global blockchain refers to a blockchain that is replicated across all nodes. To achieve consensus (e.g., agree to add blocks to a blockchain), a consensus protocol is implemented within a public blockchain network. Examples of consensus protocols include, but are not limited to: proof of work (POW), proof of rights (POS), and proof of authority (POA). In the embodiments of the present specification, POW is taken as a non-limiting example.

A private blockchain network is provided for a particular entity. The read-write authority of each node in the private blockchain network is strictly controlled. Thus, private blockchain networks, also commonly referred to as licensed networks, limit who is allowed to participate in the network and the level of network participation (e.g., only in certain transaction scenarios). In private blockchain networks, various types of access control mechanisms may be used (e.g., existing participants voting for adding new entities, regulatory body controlled permissions, etc.).

A federation blockchain network is private between participating entities. In a federated blockchain network, the consensus process is controlled by an authorizing node. For example, a federation consisting of several (e.g., 10) entities (e.g., financial institutions, insurance companies) may operate a federated blockchain network, each entity operating at least one node in the federated blockchain network. Thus, a federated blockchain network can be considered a private network of participating entities. In some examples, each participating entity (node) must sign each chunk in sequence and add the chunk to the chain of chunks. In some examples, each tile may be signed by a subset of participating entities (nodes) (e.g., at least 7 entities) and added to the tile chain.

Embodiments of the present specification embodiments are described in detail with reference to a federated blockchain network in the present specification embodiments. However, it is contemplated that embodiments of the present specification can be implemented in any suitable blockchain network.

Blockchains are tamper-resistant shared digital ledgers that record transactions in public or private peer-to-peer networks. The ledger is distributed to all member nodes in the network and asset transaction histories occurring in the network are permanently recorded in blocks.

The consensus mechanism ensures that all network nodes in the distributed blockchain network perform transactions in the same order and then write the same ledger. The consensus model aims at solving the byzantine problem. In the byzantine problem, components such as servers or network nodes in a distributed blockchain network may fail or intentionally propagate erroneous information to other nodes. Other network nodes have difficulty declaring the component as a failure and excluding it from the blockchain network because they need to agree first on which network node failed first.

Fig. 1 illustrates a schematic diagram of an example of an environment 100 that may be used to perform a method of sending a reply message to a data request according to embodiments of the present specification. In some examples, environment 100 enables entities to participate in blockchain network 102. As shown in FIG. 1, environment 100 includes a network 104, and computing devices/

systems

106, 108. In some examples, the network 104 may include a Local Area Network (LAN), a Wide Area Network (WAN), the internet, or a combination thereof, and connects websites, user devices (e.g., computing devices), and backend systems. In some examples, network 104 may be accessed through wired and/or wireless communication links. In some examples, computing devices/

systems

106, 108 communicate with each other over network 104, as well as with blockchain network 102 over network 104, and nodes (or node devices) in blockchain network 102 communicate over network 104. In general, the network 104 represents one or more communication networks. In some cases, the computing devices/

systems

106, 108 may be nodes of a cloud computing system (not shown), or each computing device/

system

106, 108 may be a separate cloud computing system that includes multiple computers interconnected by the network 104 and functions as a distributed processing system.

In the illustrated example, each of the computing devices/

systems

106, 108 may comprise any suitable computing system capable of participating as a node in the blockchain network 102. Examples of computing devices/systems include, but are not limited to, servers, desktop computers, laptops, tablet devices, smartphones, and the like. In some examples, one or more computer-implemented services may be installed on the computing devices/

systems

106, 108 for interacting with the blockchain network 102. For example, the computing device/system 106 may have installed thereon a service of a first entity (e.g., user a), such as a transaction management system used by the first entity to manage its transactions with one or more other entities (e.g., other users). The computing device/system 108 may have installed thereon a service of a second entity (e.g., user B), such as a transaction management system used by the second entity to manage its transactions with one or more other entities (e.g., other users). In the example of fig. 1, the blockchain network 102 is represented as a peer-to-peer network of nodes, and the computing devices/

systems

106, 108 act as nodes for first and second entities participating in the blockchain network 102, respectively.

Fig. 2 shows a schematic diagram of an example of a system architecture 200 that performs a method of sending a reply message to a data request according to an embodiment of the present specification. An example of system architecture 200 includes

participant systems

202, 204, 206 corresponding to participant a, participant B, and participant C, respectively. Each participant (e.g., user, enterprise) participates in blockchain network 212, which is provided as a peer-to-peer network. The blockchain network 212 includes a plurality of nodes 214, wherein at least some of the nodes 214 record information in blockchain 216, and the recorded information is not alterable. Although a single blockchain 216 is schematically shown within blockchain network 212, multiple copies of blockchain 216 may be provided and maintained in blockchain network 212, as described in detail later.

In the illustrated example, each

participant system

202, 204, 206 is provided by or as participant a, participant B, and participant C, respectively, and acts as a corresponding node 214 within the blockchain network 212. As used herein, a node generally refers to a single system (e.g., computer, server) that is connected to the blockchain network 212 and enables the respective participants to participate in the blockchain network. In the example shown in fig. 2, a participant corresponds to each node 214. However, one participant may operate multiple nodes 214 within blockchain network 212, and/or multiple participants may share a single node 214. In some examples, the

participant systems

202, 204, 206 communicate with the blockchain network 212 using a protocol (e.g., hypertext transfer protocol secure (HTTPS)) and/or using Remote Procedure Calls (RPCs), or communicate over the blockchain network 212.

The node 214 may have different participation in the blockchain network 212. For example, some nodes 214 may participate in the consensus process (e.g., as miners' nodes that add tiles to the blockchain 216), while other nodes 214 do not participate in the consensus process. As another example, some nodes 214 store a full copy of blockchain 216, while other nodes 214 store only partial copies of blockchain 216. In the example of fig. 2, the

participant systems

202, 204, 206 each store a complete copy 216', 216 "' of the chain of blocks 216.

A block chain (e.g., block chain 216 in fig. 2) consists of a series of blocks, each of which stores data. Examples of data may include transaction data representing transactions between two or more parties. In the present specification embodiments, transactions are used as non-limiting examples, and it is contemplated that any suitable data may be stored in the blockchain (e.g., documents, images, video, audio). Examples of transactions may include, but are not limited to, exchanging things of value (e.g., assets, products, services, and currency, etc.). Transaction data is unalterably stored in the blockchain.

The transaction data is hashed prior to storage in the block. The hash process is a process of converting transaction data (provided as character string data) into a hash value of a fixed length (also provided as character string data). After the transaction data is subjected to the hash processing, even if slight change occurs in the transaction data, completely different hash values can be obtained. The hash value is typically generated by hashing the transaction data using a hash function. Examples of hash functions include, but are not limited to, Secure Hash Algorithm (SHA) -256, which outputs a 256-bit hash value.

Transaction data for a plurality of transactions may be stored in the block after being hashed. For example, two transaction data are hashed to obtain two hash values, and then the two obtained hash values are hashed again to obtain another hash value. This process is repeated until a single hash value is obtained for all transactions to be stored in the block. This hash value is called a Merkle root hash and is stored at the head of the chunk. Any change to a transaction will cause its hash value to change, eventually causing the Merkle root hash value to change.

The blocks are added to the block chain by a consensus protocol. Multiple nodes in a blockchain network participate in a consensus protocol and add blocks to the blockchain after contention. Such nodes are referred to as miner nodes (or accounting nodes). The POW introduced above is used as a non-limiting example.

The miner node performs a consensus process to add the transaction (the corresponding tile) to the chain of tiles. Although multiple miner nodes participate in the consensus process, only one miner node may write a block into the blockchain. That is, the miners nodes compete in the consensus process to add their blocks to the blockchain. In more detail, the miner node periodically collects pending transactions from the transaction pool (e.g., until a predetermined limit, if any, on the number of transactions that may be included in the block is reached). The transaction pool includes transaction messages from participants in the blockchain network. The miner node creates a block and adds the transaction to the block. Before adding a transaction to a block, the miner node checks whether there is a transaction in the block of the blockchain in the transaction to be added. If the transaction has been added to another block, the transaction will be discarded.

The mineworker node generates a chunk header, hashes all transactions in the chunk, and combines the hash values in pairs to generate further hash values until a single hash value (Merkle root hash) is obtained for all transactions in the chunk. The Merkle root hash is then added to the chunk header. The miners also determine the hash value of the latest chunk in the blockchain (i.e., the last chunk added to the blockchain). The mineworker node may also add a random value (a noune value) and a timestamp in the block header. During the mining process, the miners' nodes attempt to find hash values that satisfy the required parameters. The mineworker node continually changes the nonce value until a hash value is found that meets the required parameters.

Each miner in the blockchain network attempts to find a hash value that satisfies the required parameters and competes with each other in this manner. Finally, one miner node finds a hash value that satisfies the required parameters and advertises the hash value to all other miner nodes in the blockchain network. Other miners nodes verify the hash value, and if determined to be correct, verify each transaction in the block, accept the block, and append the block to their blockchain copy. In this way, the global state of the blockchain is made consistent across all miner nodes within the blockchain network. The above process is a POW consensus protocol.

In the example provided in fig. 2, party a wants to send a certain amount of funds to party B. Party a generates a transaction message and sends the transaction message to the blockchain network, which is added to the transaction pool. Each mineworker node in the blockchain network creates a block and obtains transactions from the transaction pool and adds the transactions to the block. In this manner, the transaction issued by party a is added to the block of the miner node.

In some blockchain networks, cryptographic techniques are implemented to maintain privacy of transactions. For example, if two nodes want to maintain transaction privacy so that other nodes in the blockchain network cannot learn the transaction details, the nodes may encrypt the transaction data. Examples of encryption methods include, but are not limited to, symmetric encryption and asymmetric encryption. Symmetric encryption refers to an encryption process that uses a single key for both encryption (to generate ciphertext from plaintext) and decryption (to generate plaintext from ciphertext). In symmetric encryption, multiple nodes may use the same key, so each node may encrypt/decrypt transaction data.

Asymmetric encryption refers to encryption using a key pair. Each key pair comprises a private key and a public key, the private key being known only to the respective node, and the public key being known to any or all other nodes in the blockchain network. A node may encrypt data using a public key of another node and may decrypt the encrypted data using a private key of the other node. For example, refer again to fig. 1. Party a may encrypt data using party B's public key and send the encrypted data to party B. Messages encrypted using a node's public key can only be decrypted using the node's private key.

Asymmetric encryption is used to provide a digital signature that enables a party in a transaction to confirm the validity of other parties in the transaction and the transaction. For example, a node may digitally sign a message, and another node may confirm that the message was sent by the node based on the digital signature of party a. Digital signatures can also be used to ensure that messages are not tampered with during transmission. For example, refer again to fig. 1. Party a will send a message to party B. Party a generates a hash value of the message and then encrypts the hash value using its private key to generate a digital signature. Party a attaches the digital signature to the message and sends the message with the digital signature to party B. Party B decrypts the digital signature using party a's public key, thereby decrypting the corresponding hash value. Party B hashes the received message to get another hash value and then compares the two hash values. If the hash values are the same, party B can confirm that the message is indeed from party A and has not been tampered with.

Fig. 3 is a flowchart for explaining an exemplary application scenario of a method for transmitting a response message to a data request according to the present specification.

As shown in fig. 3, a first block link point may send a highest block request message to a second block link point to request a determination of the highest block information stored at the second block link point, at 302. The first blockchain node may be any participating node in the blockchain system, and the second blockchain node may be any participating node other than the first blockchain node.

The second block-link point may then send the locally stored highest block information to the first block-link point in response to the highest block request message, at block 304.

In one example, each blockchain node in the blockchain system may periodically broadcast the highest blockchain request message to other blockchain nodes. When other blockchain nodes listen to the highest block request message, the locally stored block height of the highest block can be sent to the sender of the highest block request message. The block height is used to indicate the order of the blocks in the block chain. For example, each block may be numbered sequentially from the starting block (i.e., the first block in the block chain), which may be the block height of the corresponding block.

In another example, each blockchain node may periodically send a highest block request message to one or more second blockchain nodes that it trusts. The second blockchain link point trusted by the first blockchain node may be determined based on the interaction history data of the first blockchain link point and each of the other blockchain nodes, for example, the blockchain link point with the shortest message response delay or the blockchain node with the highest verification passing rate of the data received from the other party may be selected as the trusted node. In addition, the trust node information can be maintained locally, so that other trusted blockchain nodes can be acquired from the trust node information.

Upon receiving the highest block information sent by the second blockchain node, the first blockchain node determines whether the local block data lags the second blockchain node based on the received highest block information and the highest block information at the first blockchain link point, at 306. In this specification, data lag means that, for a certain type of data (e.g., block data in this example), the type of data stored at a certain block link point is missing with respect to other block link points. For example, if the highest block information of the second block chain node indicates that the block height of the highest block at the second block link point is 100 and the block height of the highest block at the first block link point is 80, it indicates that the block data at the first block link point lags behind the second block chain node. In this specification, a block link point where some type of locally owned data is missing from other block link nodes may be referred to as a laggard node. The laggard nodes can be the blockchain nodes which are added into the blockchain network and have data loss due to faults or network delay and the like, and can also be the nodes newly added into the blockchain network.

When it is determined that the block data lags behind the second block chain node, the first block chain node sends a block data request message to the second block chain node to request acquisition of locally missing block data at 308. In this specification, a process of complementing local block data to be consistent with other blockchain nodes may be referred to as a block synchronization data process. For example, in the above example, the block data at the first block link point is complemented from a block with a block height of 80 to a block with a block height of 100 to coincide with the process of the second block link point, i.e., the block data synchronization process. In the chunk data request message, data information of the chunk to be synchronized may be included, and for example, a chunk height range (e.g., 81 to 100) of the chunk to be synchronized may be included.

The second blockchain node, after receiving the blockdata request message, assembles a plurality of blockdata requested by the blockdata request message into a response message in response to the blockdata request message at block 310. Since the size of a single message is usually limited in the blockchain network (for example, the size of a single message is limited to be not more than 16M), the second blockchain node may assemble the response message in batches, that is, when all the block data to be synchronized cannot be transmitted to the first blockchain node by using one response message, the block data to be synchronized requested by the first blockchain node may be assembled into a plurality of batch response messages.

After the acknowledgement message assembly is complete, the second blockchain node sends the assembled acknowledgement message to the first blockchain node at block 312. When the response messages are assembled in batches, the respective batch response messages may be sent to the first blockchain node.

After the first block link node receives the reply message, the block data in the reply message is verified at 314, and a determination is made as to whether the block data verifies at 316. The block data verification may include a verification process such as block data integrity verification to verify whether the received block data is correct. The block data verification process may be performed by any verification method known in the art, for example, by verifying the signature data in the block data. When the block data is verified, the first block link node adds the verified block data to the local block chain at 318 to implement the block data synchronization process.

Although an application scenario of the response message transmission method according to the embodiment of the present specification is described in fig. 3 by taking a block data synchronization procedure as an example, the response message transmission method of the present specification may be applied to a response message for arbitrary data. For example, in the block data consensus process, when each block node lacks a consensus message in a partial consensus phase, and requests other block nodes to synchronize the missing consensus message, the response message transmission method of the present specification may be applied.

An example of the response message transmission method performed by the second blockchain node is explained below with reference to fig. 4 to 6.

Fig. 4 is a flow diagram of a method for sending a reply message to a data request according to one embodiment of the present description.

As shown in fig. 4, in response to a data request for a plurality of data, for each data to be sent in the plurality of data, the data to be sent is assembled into a batch response message at block 402. The data may be, for example, data to be synchronized as described above, and the data request may be, for example, a tile data synchronization request for the data of the blocks to be synchronized.

After assembling each data to be sent into the batch response message, at block 404, it is determined whether the current batch response message satisfies the current checkpoint condition. Upon satisfaction of the current checkpoint condition, at block 406, the current batch reply message is determined to be a checkpoint. The checkpoint condition corresponding to each checkpoint may be determined based on the generation order of the data to be transmitted. For example, taking the tile data as an example, the checkpoint condition corresponding to each checkpoint may be generated based on the block height of each tile. The current batch response message can be used as the current check point after the block data to be sent with the block height meeting the predetermined condition is assembled into the batch response message. The predetermined condition may be set to, for example, "the block height is an integer multiple of a certain value".

In another example, the checkpoint condition for each checkpoint may be generated based on the amount of data to be sent that has been assembled into the batch response message. For example, the checkpoint condition corresponding to each checkpoint may be set to be an integer multiple of a certain number (e.g., 3) of data to be sent assembled into the batch response message. In this example, the number of data to be sent assembled into the batch response message is the first checkpoint when it reaches 3, the second checkpoint when it reaches 6, and so on. In this example, if N checkpoints have been determined for the present batch of response messages, the current checkpoint condition is that "the number of data to be sent assembled into the current batch of response messages reaches (N +1) × 3".

When the current batch response message satisfies the current checkpoint condition, the current batch response message is determined to be the current checkpoint at block 406. Then, at block 408, a determination is made whether the size of the current batch reply message exceeds a predetermined threshold. When determining the current batch response message size, the batch response message size may be determined based on the processing result after predetermined processing may be performed on the current batch response message. For example, the size of the current batch response message may be determined based on the number of bytes in the encoding result after the current batch response message is encoded in a serialized manner. The serialization coding can be implemented using any coding algorithm, such as RLP coding, for example. The predetermined threshold may be, for example, a limit on the size of a single message in a network (e.g., a blockchain network).

When the size of the current batch response message exceeds the predetermined threshold, the batch response message corresponding to the previous checkpoint is sent to the data request sender at block 410.

Since the network layer has a limit on the size of the message, if the assembled response message exceeds the network limit, the assembled response message cannot be successfully sent to the data request sender. However, if the assembled reply message is too small in size, it will result in wasted network resources. With the present embodiment, by agreeing on the checkpoint condition when assembling the batch response message, it is determined whether the size of the batch response message exceeds the predetermined threshold when the assembled batch response message satisfies the checkpoint condition. Thus, the possibility that the assembled response message exceeds the network limit is avoided, and the batch response message is close to the network limit as much as possible, so that the network resource can be fully utilized.

In addition, since a series of operations (e.g., a serialization encoding process) is usually involved in determining the size of the batch response message, determining the batch response message usually consumes a certain amount of computational resources. In this embodiment, the determination of the size of the batch response message is performed when the checkpoint condition is satisfied, that is, in the assembly process of the batch response message, if the assembled batch response message does not reach the checkpoint, the determination process of the size of the batch response message does not need to be performed, so that the number of times of determining the size of the batch response message can be reduced, and the excessive load caused by frequently performing the operation of determining the size of the message can be avoided.

When the size of the current batch response message corresponding to the current check point exceeds a predetermined threshold, the batch response message can be rolled back to the state of the previous check point, so as to obtain the batch response message corresponding to the previous check point. In another example, when the size of the batch response message does not exceed the threshold, the batch response message corresponding to each checkpoint may be stored as shown in fig. 5. Fig. 5 is a flow diagram of a method for sending a reply message to a data request according to another embodiment of the present description.

As shown in fig. 5, in block 502, in response to a data request for a plurality of data, for each data to be sent in the plurality of data, each data to be sent is sequentially assembled into a batch response message. Then after assembling each data to be sent into the batch response message, at block 504, it is determined whether the current batch response message satisfies the current checkpoint condition, and if so, at block 506, the current batch response message is determined to be a checkpoint. Then, at block 508, a determination is made whether the size of the current batch reply message exceeds a predetermined threshold. When the size of the current batch response message exceeds the predetermined threshold, the batch response message corresponding to the previous checkpoint is sent to the data request sender at block 510.

When the size of the current batch response message does not exceed the predetermined threshold, at block 512, the current batch response message corresponding to the current checkpoint is stored. In one example, the current batch reply message may be stored in a cache. When the batch response message corresponding to each check point does not exceed the preset threshold, the batch response message corresponding to the check point is stored, so that when the size of the batch response message corresponding to the next check point exceeds the preset threshold, the batch response message corresponding to the previous check point can be read from the storage space to be sent to the data request message sender.

Then, at block 514, the stored batch reply message corresponding to the previous checkpoint is deleted. If the batch response message corresponding to the current check point does not exceed the predetermined threshold, it can be determined that the batch response message of the previous check point is not sent to the data request message sender as the assembly result of the batch response message, and thus the batch response message corresponding to the previous check point can be deleted to release the storage space.

Hereinafter, an example of the checkpoint condition corresponding to each checkpoint is described with reference to fig. 6. Fig. 6 is a flowchart for explaining a checkpoint in a method for transmitting a response message to a data request according to one embodiment of the present specification.

In one example, the difference between the number of data to be sent for each checkpoint and the previous checkpoint may be incremented. As shown in part (a) of fig. 6, the number of data to be sent assembled into the batch response message is 2, 4, 8, and 16 for the checkpoint conditions corresponding to checkpoints 1 to 4, respectively. The differences between the numbers of data to be transmitted corresponding to checkpoints 2 to 4 and the previous checkpoint are 2, 4 and 8 respectively. In this example, the rate of increase of the amount of data to be sent assembled into the batch response message for each checkpoint is incremented. By increasing the number of data to be sent corresponding to each check point at an increasing rate, the assembled batch response messages can reach the predetermined threshold value as soon as possible, so that the number of determined check points can be reduced, and the amount of computation performed at the check points can be reduced accordingly. In one example, the number of assembled data to be transmitted may be set to the integral power of the reference value after the reference value is determined, as the number of assembled data to be transmitted corresponding to each check point.

In another example, when the number of the determined check points does not exceed the predetermined number, the difference between each check point and the number of data to be transmitted corresponding to the previous check point may be incremented, and when the number of the determined check points exceeds the predetermined number, the difference between each check point and the number of data to be transmitted corresponding to the previous check point may be decremented. As shown in part (B) of fig. 6, the number of data to be sent assembled into the batch response message is 2, 4, 9, 13, 16, and 18 for the check points 1 to 6, respectively. The differences between the numbers of data to be transmitted corresponding to checkpoints 2 to 5 and the previous checkpoint are 2, 5, 4, 3 and 2, respectively. When the number of the determined check points does not exceed the number of the check points, the increase speed of the number of the assembled data to be sent corresponding to each check point is increased, and when the number of the determined check points reaches 4, the increase speed of the number of the assembled data to be sent corresponding to each check point is decreased. By the example, the number of the check points of the batch response messages can be reduced, and the size of the batch response messages can be close to the network limit as much as possible, so that the calculation amount caused by the check points can be reduced, and the utilization rate of network resources can be improved to the maximum extent.

In addition, after a predetermined number of check points pass after the increase rate of the number of the assembled data to be transmitted enters a decreasing state, or when the increase amount of the number of the assembled data to be transmitted relative to the previous check point is lower than the predetermined number, the difference between the number of the assembled data to be transmitted of each check point and the previous check point may be a fixed value.

Fig. 7 is a block diagram of an apparatus for transmitting a response message to a data request according to one embodiment of the present specification. As shown in fig. 7, the response message transmitting apparatus 700 includes a batch response message assembling unit 710, a checkpoint determining unit 720, a message size determining unit 730, a batch response message storing unit 740, a batch response message deleting unit 750, and a batch response message transmitting unit 760.

In response to the data request for the multiple data, the batch response message assembling unit 710 assembles at least one piece of data to be sent in each piece of data to be sent into the batch response message for each piece of data to be sent in the multiple pieces of data. The checkpoint determining unit 720 determines whether the size of the current batch response message exceeds a predetermined threshold and determines the current batch response message as the current checkpoint when the current batch response message satisfies the current checkpoint condition. The checkpoint condition corresponding to each checkpoint is generated based on the amount of data to be sent that has been assembled into the batch response message.

The message size determining unit 730 determines whether the size of the current batch reply message exceeds a predetermined threshold. When the size of the current batch response message exceeds the predetermined threshold, the batch response message sending unit 760 sends the batch response message corresponding to the previous checkpoint to the data request sender.

The batch reply message storage unit 740 stores the current batch reply message when the size of the current batch reply message does not exceed the predetermined threshold. The batch response message deleting unit 750 deletes the stored batch response message corresponding to the previous checkpoint.

The various elements of fig. 7 are not necessarily all required components and some elements may not be included in some embodiments. For example, the batch reply message storage unit may not be included, and the batch reply message deletion unit may not be included.

Fig. 8 is a block diagram of a blockchain system according to one embodiment of the present description. As shown in fig. 8, the blockchain system 800 includes a first blockchain node 810 and a second blockchain node 820.

The first blockchain node 810, upon determining that predetermined data is absent with respect to the second blockchain node, transmits a data request for the absent plurality of predetermined data to the second blockchain node. The data request may be a block data synchronization request and the predetermined data may be block data that is missing at the first blockchain node 810. The second blockchain node 820 includes the above response message transmitting means to assemble the plurality of predetermined data requested by the first blockchain node 810 into a response message and transmit to the first blockchain node 810.

Embodiments of a method and apparatus for sending a response message to a data request and a blockchain system according to embodiments of the present specification are described above with reference to fig. 1 to 8. The details mentioned in the above description of the method embodiments apply equally to the embodiments of the device of the embodiments of the present description.

The apparatus for sending a response message to a data request according to the embodiments of the present disclosure may be implemented by hardware, or may be implemented by software, or a combination of hardware and software. The various embodiments in this specification are described in a progressive manner, with like reference to each other.

The apparatus for sending a response message to a data request according to the embodiments of the present disclosure may be implemented by hardware, or may be implemented by software, or a combination of hardware and software. The software implementation is taken as an example, and is formed by reading corresponding computer program instructions in the storage into the memory for operation through the processor of the device where the software implementation is located as a logical means. In embodiments of the present specification, the means for generating the blockchain may be implemented, for example, using a computing device.

Fig. 9 is a block diagram of a computing device for implementing a method for sending a reply message to a data request according to one of the embodiments of the present specification. As shown in fig. 9, the computing device 900 includes a processor 910, a storage 920, a memory 930, a communication interface 940, and an internal bus 950, and the processor 910, the storage (e.g., non-volatile storage) 920, the memory 930, and the communication interface 940 are connected together via the bus 950. According to one embodiment, computing device 900 may include at least one processor 910, the at least one processor 910 executing at least one computer-readable instruction (i.e., an element described above as being implemented in software) stored or encoded in a computer-readable storage medium (i.e., memory 920).

In one embodiment, computer-executable instructions are stored in the memory 920 that, when executed, cause the at least one processor 910 to: responding to a data request aiming at a plurality of data, and assembling at least one piece of data to be sent in each piece of data to be sent into a batch response message aiming at each piece of data to be sent in the plurality of data; determining whether the size of a current batch response message exceeds a predetermined threshold, and when the current batch response message meets the current check point condition, determining the current batch response message as a current check point, and determining whether the size of the current batch response message exceeds the predetermined threshold; and when the size of the current batch response message exceeds the preset threshold value, sending the batch response message corresponding to the previous check point to a data request sender.

It should be appreciated that the computer-executable instructions stored in the memory 920, when executed, cause the at least one processor 910 to perform the various operations and functions described above in connection with fig. 1-8 in the various embodiments of the present specification.

According to one embodiment, a program product, such as a non-transitory machine-readable medium, is provided. A non-transitory machine-readable medium may have instructions (i.e., elements described above as being implemented in software) that, when executed by a machine, cause the machine to perform various operations and functions described above in connection with fig. 1-8 in various ones of the embodiments of the present specification.

Specifically, a system or apparatus may be provided which is provided with a readable storage medium on which software program code implementing the functions of any of the above embodiments is stored, and causes a computer or processor of the system or apparatus to read out and execute instructions stored in the readable storage medium.

In this case, the program code itself read from the readable medium can realize the functions of any of the above-described embodiments, and thus the machine-readable code and the readable storage medium storing the machine-readable code form part of the present invention.

Examples of the readable storage medium include floppy disks, hard disks, magneto-optical disks, optical disks (e.g., CD-ROMs, CD-R, CD-RWs, DVD-ROMs, DVD-RAMs, DVD-RWs), magnetic tapes, nonvolatile memory cards, and ROMs. Alternatively, the program code may be downloaded from a server computer or from the cloud via a communications network.

The foregoing description has been directed to specific embodiments of this disclosure. Other embodiments are within the scope of the following claims. In some cases, the actions or steps recited in the claims may be performed in a different order than in the embodiments and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some embodiments, multitasking and parallel processing may also be possible or may be advantageous.

Not all steps and elements in the above flows and system structure diagrams are necessary, and some steps or elements may be omitted according to actual needs. The execution order of the steps is not fixed, and can be determined as required. The apparatus structures described in the above embodiments may be physical structures or logical structures, that is, some units may be implemented by the same physical entity, or some units may be implemented by a plurality of physical entities, or some units may be implemented by some components in a plurality of independent devices.

The term "exemplary" used throughout this specification means "serving as an example, instance, or illustration," and does not mean "preferred" or "advantageous" over other embodiments. The detailed description includes specific details for the purpose of providing an understanding of the described technology. However, the techniques may be practiced without these specific details. In some instances, well-known structures and devices are shown in block diagram form in order to avoid obscuring the concepts of the described embodiments.

Although the embodiments of the present disclosure have been described in detail with reference to the accompanying drawings, the embodiments of the present disclosure are not limited to the specific details of the embodiments, and various simple modifications may be made to the technical solutions of the embodiments of the present disclosure within the technical concept of the embodiments of the present disclosure, and all of them fall within the scope of the embodiments of the present disclosure.

The previous description of the contents of the embodiments of the present specification is provided to enable any person skilled in the art to make or use the contents of the embodiments of the present specification. Various modifications to the disclosure of the embodiments herein will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other variations without departing from the scope of the embodiments herein. Thus, the present specification embodiments are not intended to be limited to the examples and designs described herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method for sending a reply message to a data request, comprising:

responding to a data request aiming at a plurality of data, and assembling at least one piece of data to be sent in each piece of data to be sent into a batch response message aiming at each piece of data to be sent in the plurality of data;

determining whether the current batch response message meets a current checkpoint condition;

when the current batch response message meets the current check point condition, determining the current batch response message as a current check point, and determining whether the size of the current batch response message exceeds a predetermined threshold; and

when the size of the current batch response message exceeds the preset threshold value, sending the batch response message corresponding to the previous check point to a data request sender,

wherein the current checkpoint condition comprises at least one of:

the block height is an integer multiple of a specified value;

the quantity of the data to be sent assembled into the batch response message reaches the integral multiple of a set numerical value;

the difference between the number of the data to be sent corresponding to each check point and the previous check point is increased progressively; and

and when the number of the determined check points exceeds the preset number, the difference between each check point and the number of the data to be sent corresponding to the previous check point is decreased progressively.

2. The method of claim 1, further comprising:

storing the current batch response message when the size of the current batch response message does not exceed the predetermined threshold; and

and deleting the stored batch response message corresponding to the previous check point.

3. The method of claim 1, wherein the checkpoint condition for each checkpoint is generated based on the amount of data to be sent that has been assembled into the batch response message.

4. The method of claim 3, wherein a difference between the number of data to be transmitted for each checkpoint and a previous checkpoint is incremented.

5. The method according to claim 3, wherein, when the number of the determined check points does not exceed a predetermined number, the difference between the number of data to be transmitted corresponding to the respective check point and the previous check point is incremented, and/or

And when the number of the determined check points exceeds the preset number, the difference between each check point and the number of the data to be sent corresponding to the previous check point is decreased.

6. The method of claim 1, wherein the data request sender comprises a block link point behind data in a block chain system, the data request comprises a block data synchronization request, and the data comprises block data missing at the block link point.

7. An apparatus for sending a reply message to a data request, comprising:

the batch response message assembling unit is used for responding to a data request aiming at a plurality of data, and assembling at least one data to be sent in each data to be sent into a batch response message aiming at each data to be sent in the plurality of data;

the check point determining unit is used for determining whether the current batch response message meets the current check point condition or not, and determining the current batch response message as the current check point when the current batch response message meets the current check point condition;

a message size determining unit that determines whether the size of the current batch response message exceeds a predetermined threshold; and

a batch response message sending unit, which sends the batch response message corresponding to the previous check point to the data request sender when the size of the current batch response message exceeds the predetermined threshold value,

wherein the current checkpoint condition comprises at least one of:

the block height is an integer multiple of a specified value;

8. The apparatus of claim 7, further comprising:

a batch response message storage unit that stores the current batch response message when the size of the current batch response message does not exceed the predetermined threshold; and

and the batch response message deleting unit deletes the stored batch response message corresponding to the previous check point.

9. The apparatus of claim 7, wherein the checkpoint condition for each checkpoint is generated based on an amount of data to be sent that has been assembled into the batch response message.

10. A blockchain system, comprising:

a first blockchain node that, upon determining that predetermined data is absent with respect to a second blockchain node, transmits a data request for the absent plurality of predetermined data to the second blockchain node; and

a second blockchain node comprising an apparatus as claimed in any one of claims 7 to 9.

11. The blockchain system of claim 10, wherein the data request includes a blockdata synchronization request and the predetermined data includes missing blockdata at the first blockchain link.

12. A computing device, comprising:

at least one processor; and

a memory storing instructions that, when executed by the at least one processor, cause the at least one processor to perform the method of any of claims 1 to 6.

13. A non-transitory machine-readable storage medium storing executable instructions that, when executed, cause the machine to perform the method of any of claims 1-6.