WO2021135755A1 - 发送针对数据请求的应答消息的方法及装置、区块链系统 - Google Patents

发送针对数据请求的应答消息的方法及装置、区块链系统 Download PDF

Info

Publication number
WO2021135755A1
WO2021135755A1 PCT/CN2020/132054 CN2020132054W WO2021135755A1 WO 2021135755 A1 WO2021135755 A1 WO 2021135755A1 CN 2020132054 W CN2020132054 W CN 2020132054W WO 2021135755 A1 WO2021135755 A1 WO 2021135755A1
Authority
WO
WIPO (PCT)
Prior art keywords
data
response message
checkpoint
batch response
blockchain
Prior art date
Application number
PCT/CN2020/132054
Other languages
English (en)
French (fr)
Inventor
陈锐
Original Assignee
支付宝(杭州)信息技术有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 支付宝(杭州)信息技术有限公司 filed Critical 支付宝(杭州)信息技术有限公司
Publication of WO2021135755A1 publication Critical patent/WO2021135755A1/zh

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/1607—Details of the supervisory signal
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/546—Message passing systems or structures, e.g. queues
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
    • H04L9/0643—Hash functions, e.g. MD5, SHA, HMAC or f9 MAC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/04—Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1097—Protocols in which an application is distributed across nodes in the network for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees

Definitions

  • the embodiments of this specification relate to the field of blockchain technology, specifically, to a method and device for sending a response message for a data request, and a blockchain system.
  • the blockchain system is a decentralized distributed data storage system involving multiple nodes. Once data is written to the blockchain on each node, on the one hand, it means that the data is disclosed in the blockchain network. On the other hand, the data written to the blockchain is also difficult to delete and tamper with.
  • centralized devices can also store data in a manner similar to blockchain storage (which can be regarded as centralized blockchain storage).
  • the embodiments of this specification provide a method and device for sending a response message for a data request, and a blockchain system.
  • a method for sending a response message for a data request including: responding to a data request for a plurality of data, for each data to be sent in the plurality of data, Assemble at least one of the data to be sent into a batch response message; determine whether the current batch response message meets the current checkpoint condition; when the current batch response message meets the current checkpoint condition, add The current batch response message is determined as the current checkpoint, and it is determined 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 predetermined threshold, Send the batch response message corresponding to the previous checkpoint to the sender of the data request.
  • the method may further include: when the size of the current batch response message does not exceed the predetermined threshold, storing the current batch response message; and deleting the stored The batch response message corresponding to the previous checkpoint.
  • 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.
  • the difference between the amount of data to be sent corresponding to each checkpoint and the previous checkpoint may be incremental.
  • the difference between the number of data to be sent corresponding to each checkpoint and the previous checkpoint may be incremental, and/ Or when the number of determined checkpoints exceeds a predetermined number, the difference between the respective checkpoints and the amount of data to be sent corresponding to the previous checkpoint may be decreasing.
  • the data request sender may include a blockchain node whose data is behind in the blockchain system, the data request may include a block data synchronization request, and the data may include all State the missing block data at the node of the blockchain.
  • an apparatus for sending response messages for data requests including: a batch response message assembling unit, which responds to data requests for multiple data and responds to the multiple data requests. For each to-be-sent data in the data, at least one of the to-be-sent data is assembled into a batch response message; the checkpoint determination unit determines that the current batch response message meets the current checkpoint conditions, and is When the current batch response message meets the current checkpoint condition, determining the current batch response message as the current checkpoint; a message size determining unit determines whether the size of the current batch response message exceeds a predetermined threshold; And a batch response message sending unit, when the size of the current batch response message exceeds the predetermined threshold, sends the batch response message corresponding to the previous checkpoint to the data request sender.
  • the device may further include: a batch response message storage unit, which stores the current batch when the size of the current batch response message does not exceed the predetermined threshold. Response message; and a batch response message deletion unit, which deletes the stored batch response message corresponding to the previous checkpoint.
  • 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.
  • a blockchain system including: a first blockchain node, when the first blockchain node determines that it lacks predetermined data relative to the second blockchain node , Sending a data request for a plurality of missing predetermined data to the second blockchain node; and the second blockchain node includes the device as described above.
  • the data request may include a block data synchronization request
  • the predetermined data may include block data lacking at the first blockchain node
  • a computing device including: at least one processor; and a memory, the memory stores instructions, and when the instructions are executed by the at least one processor, the At least one processor executes the method as described above.
  • a non-transitory machine-readable storage medium which stores executable instructions, which when executed cause the machine to execute the method as described above.
  • the batch response message by assembling at least one of the data to be sent into the batch response message, it is determined whether the current batch response message is a checkpoint, and the current batch When the message is a checkpoint, it is determined whether 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, thereby Not only can the size of the sent response message be as close to the predetermined threshold as possible without exceeding the predetermined threshold, so as to improve the efficiency of network resource utilization, but it can also reduce the amount of computation consumed for determining the size of the response message.
  • FIG. 1 shows a schematic diagram of an example of an environment that can be used to execute a method for sending a response message for a data request according to an embodiment of the present specification
  • FIG. 2 shows a schematic diagram of an example of a system architecture that executes the method for sending a response message for a data request according to an embodiment of the present specification
  • FIG. 3 is a flowchart for explaining an exemplary application scenario of the method for sending a response message for a data request according to this specification
  • Fig. 4 is a flowchart of a method for sending a response message for a data request according to an embodiment of the present specification
  • Fig. 5 is a flowchart of a method for sending a response message for a data request according to another embodiment of the present specification
  • 6A and 6B are flowcharts for explaining checkpoints in a method for sending a response message for a data request according to an embodiment of the present specification
  • Fig. 7 is a structural block diagram of an apparatus for sending a response message for a data request according to an embodiment of the present specification
  • Fig. 8 is a structural block diagram of a blockchain system according to an embodiment of the present specification.
  • Fig. 9 is a structural block diagram of a computing device for implementing a method for sending a response message for a data request according to an embodiment of the present specification.
  • the term “including” and its variations mean open terms, meaning “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”, etc. may refer to different or the same objects. Other definitions can be included below, whether explicit or implicit. Unless clearly indicated in the context, the definition of a term is consistent throughout the specification.
  • Blockchain is a chain data structure that connects and combines data blocks sequentially in chronological order, and cryptographically ensures that the data blocks cannot be tampered with or forged.
  • the blockchain includes one or more blocks. Each block in the blockchain is linked to the previous block by including the cryptographic hash of the immediately preceding block in the blockchain. Each block also includes a timestamp, a cryptographic hash of the block, and one or more transactions.
  • the transaction that has been verified by the nodes of the blockchain network is hashed and a Merkle tree is formed. In the Merkle tree, the data at the leaf nodes is hashed, and for each branch of the Merkle tree, all the hash values of the branch are concatenated at the root of the branch.
  • the above processing is performed on the Merkle tree until the root node of the entire Merkle tree.
  • the root node of the Merkle tree stores hash values representing all data in the Merkle tree.
  • Blockchain is a data structure used to store transactions.
  • the blockchain network is a network of computing nodes used to manage, update and maintain one or more blockchain structures.
  • the blockchain network can include a public blockchain network, a private blockchain network, or a consortium blockchain network.
  • the consensus process is controlled by the nodes of the consensus network.
  • the public blockchain network can be considered as a public network of participating entities.
  • most entities nodes must sign each block in sequence, and add the signed block to the blockchain of the blockchain network.
  • Examples of public blockchain networks may include specific peer-to-peer payment networks.
  • blockchain does not specifically refer to any particular blockchain.
  • the public blockchain network supports public transactions. Public transactions are shared among all nodes in the public blockchain network and stored in the global blockchain.
  • a global blockchain refers to a blockchain that is replicated across all nodes.
  • consensus protocols include but are not limited to: proof-of-work (POW), proof-of-stake (POS), and proof-of-authority (POA).
  • POW is used as a non-limiting example.
  • Private blockchain networks are provided for specific entities.
  • the read and write permissions of each node in the private blockchain network are strictly controlled. Therefore, a private blockchain network is usually also called a permissioned network, which restricts who is allowed to participate in the network and the level of network participation (for example, only in certain transaction situations).
  • a private blockchain network various types of access control mechanisms can be used (for example, existing participants vote to add new entities, regulatory agencies control permissions, etc.).
  • the alliance blockchain network is private among participating entities.
  • the consensus process is controlled by authorized nodes.
  • a consortium composed of several (for example, 10) entities (for example, financial institutions, insurance companies) can operate a consortium blockchain network, and each entity operates at least one node in the consortium blockchain network. Therefore, the consortium blockchain network can be considered as a private network of participating entities.
  • each participating entity node
  • each block may be signed by a subset of participating entities (nodes) (for example, at least 7 entities), and the block may be added to the blockchain.
  • Blockchain is a tamper-proof shared digital ledger that records transactions in a public or private peer-to-peer network.
  • the ledger is distributed to all member nodes in the network, and the history of asset transactions that occurred in the network is permanently recorded in the block.
  • the consensus mechanism ensures that all network nodes in the distributed blockchain network execute transactions in the same order and then write to the same ledger.
  • the consensus model aims to solve the Byzantine problem.
  • components such as servers or network nodes in the distributed blockchain network may malfunction or deliberately spread wrong information to other nodes. Since other network nodes need to reach a consensus on which network node fails first, it is difficult for other network nodes to declare the component failure and exclude it from the blockchain network.
  • FIG. 1 shows a schematic diagram of an example of an environment 100 that can be used to execute a method for sending a response message to a data request according to an embodiment of the present specification.
  • the environment 100 enables entities to participate in the blockchain network 102.
  • the environment 100 includes a network 104, and computing devices/systems 106, 108.
  • the network 104 may include a local area network (LAN), a wide area network (WAN), the Internet, or a combination thereof, and connect a website, a user device (for example, a computing device), and a back-end system.
  • the network 104 may be accessed through a wired and/or wireless communication link.
  • the computing devices/systems 106 and 108 communicate with each other through the network 104, and communicate with the blockchain network 102 through the network 104, and the nodes (or node devices) in the blockchain network 102 pass through The network 104 communicates.
  • the network 104 represents one or more communication networks.
  • 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, including interconnection through the network 104 Multiple computers and used as a distributed processing system.
  • each of the computing devices/systems 106, 108 may include 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, notebook computers, tablet devices, smart phones, etc.
  • one or more computer-implemented services for interacting with the blockchain network 102 may be installed on the computing device/system 106, 108.
  • the computing device/system 106 may be installed with the services of the first entity (for example, user A), for example, the first entity is used to manage transactions with one or more other entities (for example, other users). Management system.
  • the computing device/system 108 may be installed with services of a second entity (for example, user B), for example, a transaction management system used by the second entity to manage transactions with one or more other entities (for example, other users) .
  • a second entity for example, user B
  • a transaction management system used by the second entity to manage transactions with one or more other entities (for example, other users) .
  • the blockchain network 102 is represented as a peer-to-peer network of nodes, and the computing devices/systems 106, 108 serve as the nodes of the first entity and the second entity participating in the blockchain network 102, respectively.
  • FIG. 2 shows a schematic diagram of an example of a system architecture 200 that executes the method for sending a response message to a data request according to an embodiment of the present specification.
  • An example of the system architecture 200 includes participant systems 202, 204, 206 corresponding to participant A, participant B, and participant C, respectively.
  • Each participant eg, user, enterprise
  • the blockchain network 212 includes a plurality of nodes 214, wherein at least some of the nodes 214 record information in the blockchain 216, and the recorded information cannot be changed.
  • a single blockchain 216 is schematically shown within the blockchain network 212, multiple copies of the blockchain 216 may be provided, and multiple copies are maintained in the blockchain network 212, as described in detail later of.
  • each participant system 202, 204, 206 is provided by participant A, participant B, and participant C, or provided as participant A, participant B, and participant C, respectively. And it serves as the corresponding node 214 in the blockchain network 212.
  • a node generally refers to a single system (for example, a computer, a server) connected to the blockchain network 212 and enables corresponding participants to participate in the blockchain network.
  • the participant corresponds to each node 214.
  • one participant can operate multiple nodes 214 within the blockchain network 212, and/or multiple participants can share a single node 214.
  • the participant systems 202, 204, 206 use protocols (e.g., Hypertext Transfer Protocol Security (HTTPS)) and/or use remote procedure calls (RPC) to communicate with the blockchain network 212, or through the blockchain
  • HTTPS Hypertext Transfer Protocol Security
  • RPC remote procedure calls
  • the degree of participation of the node 214 in the blockchain network 212 may vary. For example, some nodes 214 may participate in the consensus process (eg, as miner nodes that add blocks to the blockchain 216), while other nodes 214 do not participate in the consensus process. As another example, some nodes 214 store a complete copy of the blockchain 216, while other nodes 214 only store a partial copy of the blockchain 216. In the example of Figure 2, the participant systems 202, 204, 206 each store a complete copy of the blockchain 216 216', 216", 216"'.
  • a blockchain (for example, the blockchain 216 in FIG. 2) is composed of a series of blocks, and each block stores data.
  • Examples of data may include transaction data representing transactions between two or more participants.
  • transactions are used as a non-limiting example, and it is expected that any appropriate data can be stored in the blockchain (for example, documents, images, videos, audios).
  • Examples of transactions may include, but are not limited to, the exchange of valuable things (eg, assets, products, services, currency, etc.).
  • Transaction data is stored immutably in the blockchain.
  • hash Before storing in the block, hash the transaction data. Hashing is the process of converting transaction data (provided as string data) into a fixed-length hash value (also provided as string data). After the transaction data is hashed, even a slight change in the transaction data will result in a completely different hash value.
  • the hash value is usually generated by hashing 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.
  • SHA Secure Hash Algorithm
  • the transaction data of multiple transactions can 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 the Merkle root hash and is stored at the head of the block. Any change in the transaction will cause its hash value to change, and eventually the Merkle root hash value will change.
  • the block is added to the blockchain through a consensus protocol.
  • Multiple nodes in the blockchain network participate in the consensus protocol and add blocks to the blockchain after competition.
  • Such nodes are called miner nodes (or accounting nodes).
  • the POW introduced above serves as a non-limiting example.
  • Miner nodes perform a consensus process to add transactions (corresponding blocks) to the blockchain. Although multiple miner nodes participate in the consensus process, only one miner node can write a block to the blockchain. In other words, miner 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 (for example, until a predetermined limit on the number of transactions that can be included in the block is reached, if any). The transaction pool includes transaction messages from participants in the blockchain network. Miner nodes create blocks and add transactions to the blocks. Before adding the transaction to the block, the miner node checks whether there is a transaction in the block of the blockchain among the transactions to be added. If the transaction has been added to another block, the transaction will be discarded.
  • the miner node generates a block header, hashes all transactions in the block, and combines the hash values in pairs to generate further hash values until a single hash value (Merkle root) is obtained for all transactions in the block. Hash). Then, add the Merkle root hash to the block header.
  • the miner also determines the hash value of the latest block in the blockchain (ie, the last block added to the blockchain). Miner nodes can also add random values (noune values) and timestamps to the block header.
  • the miner node tries to find a hash value that meets the required parameters. The miner node keeps changing the nonce value until it finds a hash value that meets the required parameters.
  • Every miner in the blockchain network tries to find a hash value that meets the required parameters and competes with each other in this way.
  • a miner node finds a hash value that meets the required parameters and advertises the hash value to all other miner nodes in the blockchain network.
  • Other miner nodes verify the hash value, and if it is determined to be correct, verify each transaction in the block, accept the block, and attach the block to their copy of the blockchain. In this way, the global state of the blockchain is agreed upon on all miner nodes in the blockchain network.
  • the above process is a POW consensus protocol.
  • participant A wants to send a certain amount of funds to participant B.
  • Participant A generates a transaction message and sends the transaction message to the blockchain network, and the transaction message is added to the transaction pool.
  • Each miner node in the blockchain network creates a block, obtains transactions from the transaction pool, and adds the transaction to the block. In this way, the transaction issued by participant A is added to the block of the miner node.
  • cryptography is implemented to maintain the privacy of transactions. For example, if two nodes want to maintain the privacy of the transaction so that other nodes in the blockchain network cannot learn the details of the transaction, the node can encrypt the transaction data.
  • encryption methods include, but are not limited to, symmetric encryption and asymmetric encryption.
  • Symmetric encryption refers to the encryption process that uses a single key to encrypt (generate ciphertext based on plaintext) and decrypt (generate plaintext based on ciphertext).
  • symmetric encryption multiple nodes can use the same key, so each node can encrypt/decrypt transaction data.
  • Asymmetric encryption refers to the use of key pairs for encryption.
  • Each key pair includes a private key and a public key.
  • the private key is only known to the corresponding node, and the public key is known to any or all other nodes in the blockchain network.
  • a node can use another node's public key to encrypt data, and can use another node's private key to decrypt the encrypted data.
  • Participant A can use the public key of participant B to encrypt data and send the encrypted data to participant B.
  • Participant B can use its private key to decrypt the encrypted data (ciphertext) and extract the original data (plain text). Messages encrypted with the public key of the node can only be decrypted with the private key of the node.
  • Asymmetric encryption is used to provide digital signatures, which enables participants in a transaction to confirm other participants in the transaction and the validity of the transaction. For example, a node can digitally sign a message, and another node can confirm that the message was sent by the node based on the digital signature of participant A. Digital signatures can also be used to ensure that messages are not tampered with during transmission. For example, refer to Figure 1 again. Participant A will send a message to participant B. Participant A generates a hash value of the message, and then uses its private key to encrypt the hash value to generate a digital signature. Participant A attaches the digital signature to the message, and sends the message with the digital signature to participant B.
  • Participant B uses the public key of participant A to decrypt the digital signature, thereby decrypting the corresponding hash value. Participant B hashes the received message to obtain another hash value, and then compares the two hash values. If the hash value is the same, participant B can confirm that the message is indeed from participant A and has not been tampered with.
  • Fig. 3 is a flowchart for explaining an exemplary application scenario of a method for sending a response message to a data request according to the present specification.
  • the first blockchain node may send a highest block request message to the second blockchain node to request to determine the highest block information stored at the second blockchain node.
  • the first blockchain node may be any participating node in the blockchain system, and the second blockchain node may be any participating node except the first blockchain node.
  • the second blockchain node may send the locally stored highest block information to the first blockchain node in response to the highest block request message.
  • each blockchain node in the blockchain system may periodically broadcast the highest block request message to other blockchain nodes.
  • other blockchain nodes monitor the highest block request message, they can send the block height of the highest block stored locally to the sender of the highest block request message.
  • the block height is used to indicate the order of each block in the blockchain. For example, each block can be numbered sequentially from the genesis block (that is, the first block in the blockchain), and this number can be used as the block height of the corresponding block.
  • each blockchain node may periodically send the highest block request message to one or more second blockchain nodes that it trusts.
  • the second block chain node trusted by the first block chain node can be determined based on the historical data of the interaction between the first block chain node and each other block chain node. For example, the block chain node with the shortest message response delay can be selected or The blockchain node with the highest verification pass rate of the data received from the other party is regarded as the trusted node.
  • the trusted node information can also be maintained locally, so that other trusted blockchain nodes can be obtained from the trusted node information.
  • data lag means that for a certain type of data (such as block data in this example), the type of data stored at a certain blockchain node is missing relative to other blockchain nodes. For example, if the highest block information of the second blockchain node indicates that the block height of the highest block at the second blockchain node is 100, and the block height of the highest block at the first blockchain node is 80, It indicates that the block data at the first blockchain node lags behind the second blockchain node.
  • Lagging nodes can be blockchain nodes that have joined the blockchain network but have missing data due to failures or network delays, or they can be new nodes that have joined the blockchain network.
  • the first block chain node sends a block data request message to the second block chain node to request the locally missing block data.
  • the process of completing local block data to be consistent with other blockchain nodes can be referred to as a block synchronization data process.
  • the block data at the first blockchain node is completed from a block with a block height of 80 to a block with a block height of 100
  • the process consistent with the second blockchain node is Block data synchronization process.
  • the block data request message may include block data information to be synchronized, for example, may include the block height range of the block to be synchronized (for example, 81 to 100).
  • the second block chain node After receiving the block data request message, the second block chain node assembles multiple block data requested by the block data request message into a response message in block 310 in response to the block data request message. Since the size of a single message is usually limited in the blockchain network (for example, a single message is limited to no more than 16M), the second blockchain node can assemble the response message in batches, that is, when a response message cannot be used When sending all the block data to be synchronized to the first block chain node, the block data to be synchronized requested by the first block chain node may be grouped into multiple batch response messages.
  • the second blockchain node After the response message is assembled, in block 312, the second blockchain node sends the assembled response message to the first blockchain node.
  • each batch of response messages can be sent to the first blockchain node.
  • Block data verification may include verification processes such as block data integrity verification to verify whether the received block data is correct.
  • the block data verification process can be performed using any verification method known in the art, for example, it can be performed by verifying the signature data in the block data.
  • the first block chain node adds the verified block data to the local block chain to realize the block data synchronization process.
  • FIG. 3 uses the block data synchronization process as an example to describe the application scenario of the response message sending method of the embodiment of this specification
  • the response message sending method of this specification can be applied to response messages for arbitrary data.
  • the response message in this manual can also be sent method.
  • Fig. 4 is a flowchart of a method for sending a response message to a data request according to an embodiment of the present specification.
  • the data may be, for example, the data to be synchronized as described above, and the data request may be, for example, a block data synchronization request for the block data to be synchronized.
  • the current batch response message After assembling the data to be sent into the batch response message, in block 404, it is determined whether the current batch response message satisfies the current checkpoint condition. When the current checkpoint condition is met, at block 406, the current batch response message is determined as the current checkpoint.
  • the checkpoint conditions corresponding to each checkpoint can be determined based on the generation order of the data to be sent. For example, taking block data as an example, checkpoint conditions corresponding to each checkpoint can be generated based on the block height of each block. After the block data to be sent whose block height meets the predetermined condition are assembled into the batch response message, the current batch response message can be used as the current checkpoint.
  • the predetermined condition may be set as "the block height is an integer multiple of a certain value", for example.
  • the checkpoint conditions 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.
  • the checkpoint condition corresponding to each checkpoint can be set to be an integer multiple of a certain value (for example, 3) of the data to be sent assembled into the batch response message.
  • a certain value for example, 3
  • the current checkpoint condition is "the number of data to be sent that has been assembled into the current batch of response messages reaches (N+1) ⁇ 3 ".
  • the current batch response message is determined as the current checkpoint. Then, at block 408, it is determined whether the size of the current batch response message exceeds a predetermined threshold.
  • the current batch response message may be subjected to predetermined processing, and then the batch size should be determined based on the processing result. For example, after the current batch response message is serialized and encoded, the current batch response message size can be determined based on the number of bytes in the encoding result.
  • the serialized encoding can be implemented by using any encoding algorithm such as RLP encoding, for example.
  • the predetermined threshold may be, for example, a limitation on the size of a single message in a network (for example, a blockchain network).
  • the batch response message corresponding to the previous checkpoint is sent to the data request sender.
  • the checkpoint condition is agreed upon when the batch response message is assembled, so that when the assembled batch response message meets the checkpoint condition, it is determined whether the size of the batch response message exceeds a predetermined threshold.
  • the process of determining the size of the batch response message usually involves a series of calculation processes (such as a serialization encoding process), the determination of the batch response message usually consumes a certain amount of calculation resources.
  • the size of the batch response message is determined when the checkpoint condition is met, that is, during the assembly process of the batch response message, if the assembled batch response message does not reach the checkpoint , There is no need to perform the process of determining the size of the batch response message, so the number of times of determining the size of the batch response message can be reduced, thereby avoiding the frequent operation of determining the message size and causing the load to be too high.
  • Fig. 5 is a flowchart of a method for sending a response message to a data request according to another embodiment of the present specification.
  • each data to be sent in response to a data request for multiple data, for each data to be sent in the multiple data, each data to be sent is sequentially assembled into a batch response message. Then, after assembling each to-be-sent data into a batch response message, in block 504, it is determined whether the current batch response message meets the current checkpoint condition, and if so, in block 506, the current batch response message is determined as Current checkpoint. Then, at block 508, it is determined whether the size of the current batch response message exceeds a predetermined threshold. When the size of the current batch response message exceeds the predetermined threshold, in block 510, the batch response message corresponding to the previous checkpoint is sent to the data request sender.
  • the current batch response message corresponding to the current checkpoint is stored.
  • the current batch of response messages can be stored in the cache.
  • the batch response message corresponding to each checkpoint does not exceed the predetermined threshold
  • the batch response message corresponding to the checkpoint is stored, so that when the size of the batch response message corresponding to the next checkpoint exceeds the predetermined threshold, it can be stored Read the batch response message corresponding to the previous checkpoint in the space and send it to the sender of the data request message.
  • the stored batch response message corresponding to the previous checkpoint is deleted. If the batch response message corresponding to the current checkpoint does not exceed the predetermined threshold, then it can be determined that the batch response message from the previous checkpoint will not be sent to the data request message sender as the assembly result of the batch response message. You can delete the batch response message corresponding to the previous checkpoint to free up storage space.
  • FIGS. 6A and 6B are flowcharts for explaining checkpoints in a method for sending a response message to a data request according to an embodiment of the present specification.
  • the difference between the amount of data to be sent corresponding to each checkpoint and the previous checkpoint may be increasing.
  • the checkpoint conditions corresponding to checkpoints 1 to 4 are that the number of data to be sent assembled into the batch response message reaches 2, 4, 8, and 16, respectively.
  • the difference between checkpoints 2 to 4 and the amount of data to be sent corresponding to the previous checkpoint is 2, 4, and 8, respectively.
  • the growth rate of the amount of data to be sent that has been assembled into the batch response message corresponding to each checkpoint is increasing.
  • the assembled batch response message can reach the predetermined threshold as soon as possible, thereby reducing the number of checkpoints determined, and thus reducing the number of checkpoints.
  • the amount of operations performed In an example, after the reference value is determined, an integer power of the reference value may be used as the number of assembled data to be sent corresponding to each check point.
  • the difference between each checkpoint and the amount of data to be sent corresponding to the previous checkpoint is incremental, and it can also be at the determined checkpoint.
  • the difference between the number of data to be sent corresponding to each checkpoint and the previous checkpoint is decreasing.
  • the checkpoint conditions corresponding to checkpoints 1 to 6 are that the number of data to be sent assembled into the batch response message reaches 2, 4, 9, 13, 16, and 18 respectively.
  • the difference between checkpoints 2 to 5 and the amount of data to be sent corresponding to the previous checkpoint is 2, 5, 4, 3, and 2, respectively.
  • the growth rate of the number of assembled data to be sent corresponding to each checkpoint is increasing.
  • the data of the determined checkpoint reaches 4
  • the number of data corresponding to each checkpoint is increased.
  • the growth rate of the assembled data to be sent is decreasing.
  • the difference between each checkpoint and the number of assembled data to be sent corresponding to the previous checkpoint is a fixed value.
  • Fig. 7 is a structural block diagram of an apparatus for sending a response message to a data request according to an embodiment of the present specification.
  • the response message sending device 700 includes a batch response message assembly unit 710, a checkpoint determination unit 720, a message size determination unit 730, a batch response message storage unit 740, a batch response message deletion unit 750, and a batch Reply message sending unit 760.
  • the batch response message assembling unit 710 In response to a data request for multiple data, the batch response message assembling unit 710 assembles at least one of the to-be-sent data into a batch response message for each of the multiple data to be sent.
  • the checkpoint determination unit 720 determines whether the size of the current batch response message exceeds a predetermined threshold, and when the current batch response message meets the current checkpoint condition, determines the current batch response message as the current checkpoint.
  • the checkpoint conditions corresponding to each checkpoint are 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 response message exceeds a predetermined threshold. When the size of the current batch response message exceeds the predetermined threshold, the batch response message sending unit 740 sends the batch response message corresponding to the previous checkpoint to the data request sender.
  • the batch response message storage unit 750 stores the current batch response message.
  • the batch response message deleting unit 760 deletes the stored batch response message corresponding to the previous checkpoint.
  • the units in FIG. 7 are not all necessary constituent elements, and some of the units may not be included in some embodiments.
  • the batch response message storage unit may not be included, and the batch response message deletion unit may also not be included.
  • Fig. 8 is a structural block diagram of a blockchain system according to an embodiment of the present specification. 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 When determining that the first blockchain node 810 lacks predetermined data relative to the second blockchain node, it sends a data request for the missing multiple predetermined data to the second blockchain node.
  • the data request may be a block data synchronization request, and the predetermined data may be the missing block data at the first blockchain node 810.
  • the second blockchain node 820 includes the above response message sending device to assemble a plurality of predetermined data requested by the first blockchain node 810 into a response message and send it to the first blockchain node 810.
  • the apparatus for sending a response message to a data request in the embodiment of the specification 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, and the same or similar parts among the various embodiments are referred to each other.
  • the apparatus for sending a response message to a data request in the embodiment of the specification may be implemented by hardware, or may be implemented by software or a combination of hardware and software.
  • Taking software implementation as an example as a logical device, it is formed by reading the corresponding computer program instructions in the memory into the memory through the processor of the device where it is located.
  • the device for generating a blockchain can be realized by using a computing device, for example.
  • Fig. 9 is a structural block diagram of a computing device for implementing a method for sending a response message for a data request according to an embodiment of the present specification.
  • the computing device 900 includes a processor 910, a memory 920, a memory 930, a communication interface 940, and an internal bus 950, and the processor 910, a memory (for example, a non-volatile memory) 920, a memory 930, and a communication interface 940 are connected together via a bus 950.
  • the computing device 900 may include at least one processor 910 that executes at least one computer-readable instruction (ie, the aforementioned Elements implemented in software).
  • a computer-executable instruction is stored in the memory 920, which when executed causes at least one processor 910 to respond to a data request for a plurality of data, for each data to be sent in the plurality of data, Assemble at least one of the data to be sent into the batch response message; determine whether the size of the current batch response message exceeds a predetermined threshold, and when the current batch response message meets the current checkpoint conditions, all The current batch response message is determined as the current checkpoint, and it is determined 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 predetermined threshold, the The batch response message corresponding to the previous checkpoint is sent to the sender of the data request.
  • a program product such as a non-transitory machine-readable medium.
  • the non-transitory machine-readable medium may have instructions (that is, the above-mentioned elements implemented in the form of software), which when executed by a machine, cause the machine to execute the above described in conjunction with FIGS. 1-8 in the various embodiments of the embodiments of this specification.
  • instructions that is, the above-mentioned elements implemented in the form of software
  • a system or device equipped with a readable storage medium may be provided, and the software program code for realizing the function of any one of the above-mentioned embodiments is stored on the readable storage medium, and the computer or device of the system or device The processor reads and executes the instructions stored in the readable storage medium.
  • the program code itself read from the readable medium can realize the function of any one of the above embodiments, so the machine readable code and the readable storage medium storing the machine readable code constitute the present invention a part of.
  • Examples of readable storage media include floppy disks, hard disks, magneto-optical disks, optical disks (such as CD-ROM, CD-R, CD-RW, DVD-ROM, DVD-RAM, DVD-RW, DVD-RW), magnetic tape, Volatile memory card and ROM.
  • the program code can be downloaded from a server computer or cloud via a communication network.
  • the device structure described in the foregoing embodiments may be a physical structure or a logical structure, that is, some units may be implemented by the same physical entity, or some units may be implemented by multiple physical entities, or may be implemented by multiple physical entities. Some components in independent devices are implemented together.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Theoretical Computer Science (AREA)
  • Signal Processing (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Power Engineering (AREA)
  • Computing Systems (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Computer And Data Communications (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

本说明书实施例提供了一种用于发送针对数据请求的应答消息的方法，包括：响应于针对多个数据的数据请求，针对所述多个数据中的各个待发送数据，将所述各个待发送数据中的至少一个待发送数据组装入批次应答消息；确定当前的批次应答消息是否满足当前检查点条件；在当前的批次应答消息满足当前检查点条件时，将所述当前的批次应答消息确定为当前检查点，并确定所述当前的批次应答消息的大小是否超过预定阈值；以及在所述当前的批次应答消息的大小超过所述预定阈值时，将前一检查点所对应的批次应答消息发送给数据请求发送方。

Description

发送针对数据请求的应答消息的方法及装置、区块链系统 技术领域
本说明书实施例涉及区块链技术领域，具体地，涉及发送针对数据请求的应答消息的方法及装置、区块链系统。
背景技术
区块链系统是一种去中心化的、由多个节点参与的分布式数据存储系统。数据一旦被写入每个节点上的区块链，一方面，意味着数据在区块链网络中被公开，另一方面，写入区块链的数据也难以被删除与篡改。此外，中心化设备也可以采用类似于区块链存储(可以视为中心化的区块链存储)的方式对数据进行存储。
区块链系统中通常存在多个参与节点。已有参与节点之间通过共识协议来确保各自数据的一致性。但是，当出现参与节点发生故障、新参与节点加入或者其他各种原因时，可能导致某参与节点的数据落后于其它正常的参与节点。因而，区块链系统需要通过数据同步协议，来确保落后的参与节点能够使本地所维护的数据追赶上其它正常参与节点，从而参与到正常的共识过程中。当某参与节点发现自己所维护的数据落后于其它正常节点时，可以发起数据同步过程，即向正常参与节点请求其缺少的数据。正常节点在接收到数据请求时，可以将落后的参与节点所请求的数据包括在应答消息中发送给落后参与节点。
发明内容
鉴于上述，本说明书实施例提供了一种发送针对数据请求的应答消息的方法及装置、区块链系统。
根据本说明书实施例的一个方面，提供了一种用于发送针对数据请求的应答消息的方法，包括：响应于针对多个数据的数据请求，针对所述多个数据中的各个待发送数据，将所述各个待发送数据中的至少一个待发送数据组装入批次应答消息；确定当前的批次应答消息是否满足当前检查点条件；在当前的批次应答消息满足当前检查点条件时，将所述当前的批次应答消息确定为当前检查点，并确定所述当前的批次应答消息的大小是否超过预定阈值；以及在所述当前的批次应答消息的大小超过所述预定阈值时，将前一检查点所对应的批次应答消息发送给数据请求发送方。
可选的，在另一示例中，所述方法还可以包括：在所述当前的批次应答消息的大小未超过所述预定阈值时，存储所述当前的批次应答消息；以及删除所存储的前一检查点所对应的批次应答消息。
可选的，在另一示例中，各个检查点所对应的检查点条件可以是基于已被组装入所述批次应答消息的待发送数据数量生成的。
可选的，在另一示例中，所述各个检查点与前一检查点所对应的待发送数据数量之差可以是递增的。
可选的，在另一示例中，在所确定的检查点的数量未超过预定数量时，所述各个检查点与前一检查点所对应的待发送数据数量之差可以是递增的，和/或在所确定的检查点的数量超过预定数量时，所述各个检查点与前一检查点所对应的待发送数据数量之差可以是递减的。
可选的，在另一示例中，所述数据请求发送方可以包括区块链系统中的数据落后的区块链节点，所述数据请求可以包括区块数据同步请求，所述数据可以包括所述区块链节点处缺少的区块数据。
根据本说明书实施例的另一方面，还提供一种用于发送针对数据请求的应答消息的装置，包括：批次应答消息组装单元，响应于针对多个数据的数据请求，针对所述多个数据中的各个待发送数据，将所述各个待发送数据中的至少一个待发送数据组装入批次应答消息；检查点确定单元，确定当前的批次应答消息满足当前检查点条件，并在所述当前的批次应答消息满足当前检查点条件时，将所述当前的批次应答消息确定为当前检查点；消息大小确定单元，确定所述当前的批次应答消息的大小是否超过预定阈值；以及批次应答消息发送单元，在所述当前的批次应答消息的大小超过所述预定阈值时，将前一检查点所对应的批次应答消息发送给数据请求发送方。
可选的，在另一示例中，所述装置还可以包括：批次应答消息存储单元，在所述当前的批次应答消息的大小未超过所述预定阈值时，存储所述当前的批次应答消息；以及批次应答消息删除单元，删除所存储的前一检查点所对应的批次应答消息。
可选的，在另一示例中，各个检查点所对应的检查点条件可以是基于已被组装入所述批次应答消息的待发送数据数量生成的。
根据本说明书实施例的另一方面，还提供一种区块链系统，包括：第一区块链节点，所述第一区块链节点在确定相对于第二区块链节点缺少预定数据时，向所述第二区 块链节点发送针对所缺少的多个预定数据的数据请求；以及第二区块链节点，包括如上所述的装置。
可选的，在另一示例中，所述数据请求可以包括区块数据同步请求，所述预定数据可以包括所述第一区块链节点处缺少的区块数据。
根据本说明书实施例的另一方面，还提供一种计算设备，包括：至少一个处理器；以及存储器，所述存储器存储指令，当所述指令被所述至少一个处理器执行时，使得所述至少一个处理器执行如上所述的方法。
根据本说明书实施例的另一方面，还提供一种非暂时性机器可读存储介质，其存储有可执行指令，所述指令当被执行时使得所述机器执行如上所述的方法。
利用本说明书实施例的方法和装置，通过在将各个待发送数据中的至少一个待发送数据组装入批次应答消息后，确定当前的批次应答消息是否是检查点，并在当前的批次消息是检查点时，确定当前的批次应答消息是否超过预定阈值，在当前的批次应答消息超过预定阈值时，将前一检查点所对应的批次应答消息发送给数据请求发送方，从而不仅能够使所发送的应答消息的大小在不超过预定阈值的情况下，尽量接近预定阈值，以提高网络资源利用效率，而且还能够减少因确定应答消息大小所消耗的运算量。
附图说明
通过参照下面的附图，可以实现对于本说明书实施例内容的本质和优点的进一步理解。在附图中，类似组件或特征可以具有相同的附图标记。附图是用来提供对本发明实施例的进一步理解，并且构成说明书的一部分，与下面的具体实施方式一起用于解释本说明书实施例的实施例，但并不构成对本说明书实施例的实施例的限制。
图1示出了可用于执行根据本说明书实施例的用于发送针对数据请求的应答消息的方法的环境的示例的示意图；
图2示出了执行根据本说明书实施例的用于发送针对数据请求的应答消息的方法的系统架构的示例的示意图；
图3是用于说明根据本说明书的用于发送针对数据请求的应答消息的方法的示例性应用场景的流程图；
图4是根据本说明书的一个实施例的用于发送针对数据请求的应答消息的方法的流程图；
图5是根据本说明书的另一实施例的用于发送针对数据请求的应答消息的方法的流程图；
图6A和图6B是用于说明根据本说明书实施例的用于发送针对数据请求的应答消息的方法中的检查点的流程图；
图7是根据本说明书实施例的用于发送针对数据请求的应答消息的装置的结构框图；
图8是根据本说明书实施例的区块链系统的结构框图；以及
图9是根据本说明书实施例的用于实现用于发送针对数据请求的应答消息的方法的计算设备的结构框图。
具体实施方式
以下将参考示例实施方式讨论本文描述的主题。应该理解，讨论这些实施方式只是为了使得本领域技术人员能够更好地理解从而实现本文描述的主题，并非是对权利要求书中所阐述的保护范围、适用性或者示例的限制。可以在不脱离本说明书实施例内容的保护范围的情况下，对所讨论的元素的功能和排列进行改变。各个示例可以根据需要，省略、替代或者添加各种过程或组件。另外，相对一些示例所描述的特征在其它例子中也可以进行组合。
如本文中使用的，术语“包括”及其变型表示开放的术语，含义是“包括但不限于”。术语“基于”表示“至少部分地基于”。术语“一个实施例”和“一实施例”表示“至少一个实施例”。术语“另一个实施例”表示“至少一个其他实施例”。术语“第一”、“第二”等可以指代不同的或相同的对象。下面可以包括其他的定义，无论是明确的还是隐含的。除非上下文中明确地指明，否则一个术语的定义在整个说明书中是一致的。
现在结合附图来描述本说明书实施例的用于发送针对数据请求的应答消息的方法及装置、区块链系统。
区块链是一种按照时间顺序来将数据区块顺序相连组合而成的链式数据结构，并且以密码学方式保证数据区块不可篡改和不可伪造。区块链包括一个或多个区块。区块链中的每个区块通过包括该区块链中紧接其之前的前一个区块的加密哈希而链接到该前一个区块。每个区块还包括时间戳、该区块的加密哈希以及一个或多个交易 (transaction)。对已经被区块链网络的节点验证的交易进行哈希处理并形成Merkle树。在Merkle树中，对叶节点处的数据进行哈希处理，并且针对Merkle树的每个分支，在该分支的根处级联该分支的所有哈希值。针对Merkle树执行上述处理，直到整个Merkle树的根节点。Merkle树的根节点存储代表该Merkle树中的所有数据的哈希值。当一个哈希值声称是Merkle树中存储的交易时，可以通过判断该哈希值是否与Merkle树的结构一致来进行快速验证。
区块链是用于存储交易的数据结构。区块链网络是用于管理、更新和维护一个或多个区块链结构的计算节点网络。如上所述，区块链网络可以包括公有区块链网络、私有区块链网络或联盟区块链网络。
在公有区块链网络中，共识过程由共识网络的节点控制。例如，在公有区块链网络中可以存在成千上万个实体协作处理，每个实体操作该公有区块链网络中的至少一个节点。因此，公有区块链网络可以被认为是参与实体的公有网络。在一些示例中，大多数实体(节点)必须按序对每个区块进行签名，并且将签名后的区块添加到区块链网络的区块链中。公有区块链网络的示例可以包括特定对等支付网络。此外，术语“区块链”不特别指代任何特定的区块链。
公有区块链网络支持公有交易。公有交易在公有区块链网络内的所有节点之间共享，并且存储在全局区块链中。全局区块链是指跨所有节点复制的区块链。为了达成共识(例如，同意向区块链添加区块)，在公有区块链网络内实现共识协议。共识协议的示例包括但不限于：工作量证明(POW，proof-of-work)，权益证明(POS，proof-of-stake)和权威证明(POA，proof-of-authority)。在本说明书实施例中，采用POW作为非限制性示例。
私有区块链网络被提供来用于特定实体。私有区块链网络中的各个节点的读写权限被严格控制。因此，私有区块链网络通常也称为许可网络，其对允许谁参与网络以及的网络参与水平(例如，仅在某些交易情形下)进行限制。在私有区块链网络中，可以使用各种类型的访问控制机制(例如，现有参与方对添加新实体进行投票，监管机构控制许可等)。
联盟区块链网络在参与实体之间是私有的。在联盟区块链网络中，共识过程由授权节点控制。例如，由若干个(例如，10个)实体(例如，金融机构、保险公司)组成的联盟可以操作联盟区块链网络，每个实体操作该联盟区块链网络中的至少一个节点。因此，联盟区块链网络可以被认为是参与实体的私有网络。在一些示例中，每个参与实 体(节点)必须按序对每个区块进行签名，并将该区块添加到区块链。在一些示例中，可以由参与实体(节点)的子集(例如，至少7个实体)来对每个区块进行签名，并将该区块添加到区块链。
在本说明书实施例中参考联盟区块链网络来详细描述本说明书实施例的实施例。然而，可以预期，本说明书实施例的实施例可以在任何适合的区块链网络中实现。
区块链是防篡改的共享数字分类账，其在公有或私有对等网络中记录交易。分类账被分发到网络中的所有成员节点，并且网络中发生的资产交易历史记录被永久记录在区块中。
共识机制确保分布式区块链网络中的所有网络节点按照相同的顺序执行交易，并且随后写入相同的分类账。共识模型旨在解决拜占庭问题。在拜占庭问题中，分布式区块链网络中的比如服务器或网络节点的组件可能会出现故障，或者故意向其他节点传播错误的信息。由于其他网络节点需要首先就哪个网络节点首先失败达成共识，从而其他网络节点很难将该组件声明失败并将其排除出区块链网络。
图1示出了可用于执行根据本说明书实施例的发送针对数据请求的应答消息的方法的环境100的示例的示意图。在一些示例中，环境100使得实体能够参与区块链网络102。如图1所示，环境100包括网络104、和计算设备/系统106、108。在一些示例中，网络104可以包括局域网(LAN)，广域网(WAN)，因特网或其组合，并且连接网站、用户设备(例如，计算设备)和后端系统。在一些示例中，可以通过有线和/或无线通信链路来访问网络104。在一些示例中，计算设备/系统106、108通过网络104相互通信，以及通过网络104实现与区块链网络102之间的通信，以及区块链网络102中的节点(或，节点设备)通过网络104来进行通信。通常，网络104表示一个或多个通信网络。在一些情况下，计算设备/系统106、108可以是云计算系统(未示出)的节点，或者每个计算设备/系统106、108可以是单独的云计算系统，其包括通过网络104互连的多个计算机并且用作分布式处理系统。
在所说明的示例中，计算设备/系统106、108中的每个可以包括能够参与作为区块链网络102中的节点的任何合适的计算系统。计算设备/系统的示例包括但不限于，服务器、台式计算机、笔记本电脑、平板电脑设备和智能手机等。在一些示例中，计算设备/系统106、108上可以安装有用于与区块链网络102交互的一个或多个计算机实现的服务。例如，计算设备/系统106可以上可以安装有第一实体(例如，用户A)的服务，比如，第一实体用于管理其与一个或多个其他实体(例如，其他用户)的交易的交易管理 系统。计算设备/系统108可以上可以安装有第二实体(例如，用户B)的服务，比如，第二实体用于管理其与一个或多个其他实体(例如，其他用户)的交易的交易管理系统。在图1的示例中，区块链网络102被表示为节点的对等网络，并且计算设备/系统106、108分别作为参与区块链网络102的第一实体和第二实体的节点。
图2示出了执行根据本说明书实施例的发送针对数据请求的应答消息的方法的系统架构200的示例的示意图。系统架构200的示例包括分别与参与方A、参与方B和参与方C对应的参与方系统202、204、206。每个参与方(例如，用户，企业)参与被提供来作为对等网络的区块链网络212。区块链网络212包括多个节点214，其中，节点214中的至少一些节点在区块链216中记录信息，并且所记录的信息不可更改。尽管在区块链网络212内示意性地示出了单个区块链216，但是可以提供区块链216的多个副本，并且在区块链网络212中维护多个副本，如稍后详细描述的。
在所示出的示例中，每个参与方系统202、204、206分别由参与方A、参与方B和参与方C提供，或者被提供来作为参与方A、参与方B和参与方C，并且充当区块链网络212内的对应节点214。如这里所使用的，节点通常是指连接到区块链网络212的单个系统(例如，计算机、服务器)，并且使得相应的参与方能够参与区块链网络。在图2示出的示例中，参与方对应于每个节点214。然而，一个参与方可以操作区块链网络212内的多个节点214，和/或多个参与方可以共享单个节点214。在一些示例中，参与方系统202、204、206使用协议(例如，超文本传输协议安全(HTTPS))和/或使用远程过程调用(RPC)来与区块链网络212通信，或者通过区块链网络212进行通信。
节点214在区块链网络212的参与度可以不同。例如，一些节点214可以参与共识过程(例如，作为将区块添加到区块链216的矿工节点)，而其他节点214不参与共识过程。作为另一示例，一些节点214存储区块链216的完整副本，而其他节点214仅存储区块链216的部分副本。在图2的示例中，参与方系统202、204、206各自存储区块链216的完整副本216'、216”、216”'。
区块链(例如，图2中的区块链216)由一连串的区块组成，每个区块存储数据。数据的示例可以包括表示两个或更多参与方之间的交易的交易数据。在本说明书实施例中，交易被使用来作为非限制性示例，可以预期的是，任何适当的数据都可以存储在区块链中(例如，文档、图像、视频、音频)。交易的示例可以包括但不限于交换有价值的东西(例如，资产、产品、服务和货币等)。交易数据被不可更改地存储在区块链中。
在存储在区块中之前，对交易数据进行哈希处理。哈希处理是将(作为字符串数 据提供的)交易数据转换为固定长度的哈希值(也被作为字符串数据提供)的过程。通过对交易数据进行哈希处理后，即使交易数据出现轻微更改，也会导致得到完全不同的哈希值。哈希值通常是通过使用哈希函数来对交易数据进行哈希处理而生成的。哈希函数的示例包括但不限于安全散列算法(SHA)-256，其输出256比特的哈希值。
多个交易的交易数据可以在被哈希化之后存储在区块中。例如，对两个交易数据进行哈希处理得到两个哈希值，然后，对所得到的两个哈希值再次进行哈希处理以得到另一哈希值。重复该过程，直到对于要存储在区块中的所有交易，得到单个哈希值。该哈希值被称为Merkle根哈希，并且被存储在区块的头部。任何交易的更改都会导致其哈希值发生变化，最终导致Merkle根哈希值发生变化。
通过共识协议来将区块添加到区块链中。区块链网络中的多个节点参与共识协议，并且经过竞争之后将区块添加到区块链中。这样的节点被称为矿工节点(或记账节点)。以上介绍的POW用作非限制性示例。
矿工节点执行共识过程来将交易(所对应的区块)添加到区块链。虽然多个矿工节点参与共识过程，但只有一个矿工节点可以将区块写入区块链。也就是说，矿工节点在共识过程中竞争以将其区块添加到区块链中。更详细地，矿工节点周期性地从交易池中收集待处理的交易(例如，直到达到在区块中可以包括的交易数量的预定限制，如果有的话)。交易池包括来自区块链网络中的参与方的交易消息。矿工节点创建区块，并将交易添加到区块中。在将交易添加到区块之前，矿工节点检查待添加的交易中是否存在区块链的区块中具有的交易。如果该交易已被添加到另一个区块中，则该交易将被丢弃。
矿工节点生成区块头，对区块中的所有交易进行哈希处理，并且成对地组合哈希值以生成进一步的哈希值，直到针对区块中的所有交易得到单个哈希值(Merkle根哈希)。然后，将Merkle根哈希添加到区块头中。矿工还确定区块链中的最新区块(即，添加到区块链的最后一个区块)的哈希值。矿工节点还可以在区块头中添加随机数值(noune值)和时间戳。在挖掘过程中，矿工节点尝试找到满足所需参数的哈希值。矿工节点不断更改nonce值，直到找到满足所需参数的哈希值。
区块链网络中的每个矿工都试图找到满足所需参数的哈希值，并且以这种方式彼此竞争。最终，一个矿工节点找到满足所需参数的哈希值，并将该哈希值通告给区块链网络中的所有其他矿工节点。其他矿工节点验证哈希值，如果确定为正确，则验证区块中的每个交易，接受该区块，并将该区块附加到它们的区块链副本中。以这种方式，区 块链的全局状态在区块链网络内的所有矿工节点上达成一致。上述过程是POW共识协议。
在图2所提供的示例中，参与方A想要向参与方B发送一定数量的资金。参与方A生成交易消息，并将交易消息发送到区块链网络，该交易消息被增加到交易池中。区块链网络中的每个矿工节点创建区块，并从交易池中获取交易，并将交易添加到区块。按照这种方式，参与方A所发布的交易被添加到矿工节点的区块中。
在一些区块链网络中，实施密码技术来维护交易的隐私性。例如，如果两个节点想要保持交易私密性，使得区块链网络中的其他节点不能获悉交易细节，则节点可以对交易数据进行加密处理。加密方法的示例包括但不限于对称加密和非对称加密。对称加密是指使用单个密钥进行加密(根据明文生成密文)和解密(根据密文生成明文)的加密过程。在对称加密中，多个节点可以使用相同的密钥，因此每个节点都可以对交易数据进行加密/解密。
非对称加密是指使用密钥对来进行加密。每个密钥对包括私钥和公钥，私钥仅对于相应节点是已知的，并且公钥对于区块链网络中的任何或所有其他节点是已知的。节点可以使用另一个节点的公钥来加密数据，并且可以使用其他节点的私钥来解密经过加密的数据。例如，再次参考图1。参与方A可以使用参与方B的公钥来加密数据，并将加密数据发送给参与方B.参与方B可以使用其私钥来解密加密数据(密文)并提取原始数据(明文)。使用节点的公钥加密的消息，只能使用该节点的私钥解密。
非对称加密用于提供数字签名，这使得交易中的参与方能够确认交易中的其他参与方以及交易的有效性。例如，节点可以对消息进行数字签名，而另一个节点可以根据参与方A的数字签名确认消息是由该节点发送的。数字签名还可以用于确保消息在传输过程中不被篡改。例如，再次参考图1。参与方A将向参与方B发送消息。参与方A生成消息的哈希值，然后使用其私钥对哈希值进行加密来生成数字签名。参与方A将该数字签名附加到消息，并将具有数字签名的消息发送给参与方B。参与方B使用参与方A的公钥解密数字签名，从而解密出对应的哈希值。参与方B对所接收的消息进行哈希处理以得到另一哈希值，然后比较两个哈希值。如果哈希值相同，则参与方B可以确认该消息确实来自参与方A，并且未被篡改。
图3是用于说明根据本说明书的用于发送针对数据请求的应答消息的方法的示例性应用场景的流程图。
如图3所示，在302，第一区块链节点可以向第二区块链节点发送最高区块请求消息，以请求确定第二区块链节点处所存储的最高区块信息。第一区块链节点可以是区块链系统中的任意参与节点，第二区块链节点可以是除第一区块链节点的任意参与节点。
然后，在块304，第二区块链节点可以响应于最高区块请求消息，向第一区块链节点发送本地存储的最高区块信息。
在一个示例，区块链系统中的各个区块链节点可以周期性地向其它区块链节点广播最高区块请求消息。其它区块链节点在监听到最高区块请求消息时，可以将本地所存储的最高区块的块高发送给最高区块请求消息的发送方。块高用于指示各个区块在区块链中的顺序。例如，可以从创世区块(即区块链中的第一个区块)起顺序地为各个区块进行编号，该编号可以作为相应区块的块高。
在另一示例中，各个区块链节点可以向其所信任的一个或多个第二区块链节点周期性地发送最高区块请求消息。第一区块链节点所信任的第二区块链节点可以基于第一区块链节点与各个其它区块链节点的交互历史数据来确定，例如可以选取消息响应延迟最短的区块链节点或者从对方所接收的数据的验证通过率最高的区块链节点以作为信任节点。此外，还可以在本地维护信任节点信息，从而可以从信任节点信息中获取所信任的其它区块链节点。
第一区块链节点在接收到第二区块链节点所发送的最高区块信息时，在306，基于所收到的最高区块信息和第一区块链节点处的最高区块信息，来确定本地的区块数据是否落后于第二区块链节点。在本说明书中，数据落后是指，针对某一类数据(如本示例中的区块数据)，某区块链节点处存储的该类数据相对于其它区块链节点出现缺失。例如，如果第二区块链节点的最高区块信息表明第二区块链节点处的最高区块的块高为100，而第一区块链节点处的最高区块的块高为80，则表明第一区块链节点处的区块数据落后于第二区块链节点。在本说明书中，本地所拥有的某类数据相于出其它区块链节点出现缺失的区块链节点可以被称为落后节点。落后节点可以是已加入区块链网络但由于故障或网络延迟等原因出现数据缺失的区块链节点，还可以是新加入区块链网络的节点。
当确定区块数据落后于第二区块链节点时，在308，第一区块链节点向第二区块链节点发送区块数据请求消息，以请求获取本地缺失的区块数据。在本说明书中，将本地的区块数据补全至与其它区块链节点一致的过程可以称为区块同步数据过程。例如，在上述示例中，将第一区块链节点处的区块数据从块高为80的区块补全至块高为100的 区块，以与第二区块链节点一致的过程即区块数据同步过程。在区块数据请求消息中，可以包括待同步区块数据信息，例如可以包括待同步区块的块高范围(例如81至100)。
第二区块链节点在接收到区块数据请求消息之后，在块310，响应于区块数据请求消息，将区块数据请求消息所请求的多个区块数据组装入应答消息。由于区块链网络中通常对单个消息的大小进行了限制(例如限制为单个消息不超过16M)，因而第二区块链节点可以分批次组装应答消息，即，当无法在利用一个应答消息将全部待同步区块数据发送给第一区块链节点时，可以将第一区块链节点所请求的待同步区块数据分组组装入多个批次应答消息中。
在应答消息组装完成之后，在块312，第二区块链节点将所组装的应答消息发送给第一区块链节点。在分批次组装应答消息时，可以将各个批次应答消息发送给第一区块链节点。
第一区块链节点接收到应答消息之后，在314，对应答消息中的区块数据进行验证，并在316，确定区块数据是否验证通过。区块数据验证可以包括区块数据完整性验证等验证过程，以验证所接收到的区块数据是否正确。区块数据验证过程可以采用本领域公知的任意验证方法来执行，例如可以通过验证区块数据中的签名数据来进行。在区块数据验证通过时，在318，第一区块链节点将验证通过的区块数据加入到本地的区块链中，以实现区块数据同步过程。
虽然图3中以区块数据同步过程为例对本说明书实施例的应答消息发送方法的应用场景进行了描述，但是本说明书的应答消息发送方法可以适用于针对任意数据的应答消息。例如，在区块数据的共识过程中，当各个区块链节点缺少部分共识阶段的共识消息，从而向其它区块链节点请求同步所缺少的共识消息时，也可以适用本说明书的应答消息发送方法。
以下参考图4至图6B，对第二区块链节点所执行的应答消息发送方法的示例进行说明。
图4是根据本说明书的一个实施例的用于发送针对数据请求的应答消息的方法的流程图。
如图4所示，在块402，响应于针对多个数据的数据请求，针对多个数据中的各个待发送数据，将各个待发送数据中的至少一个待发送数据组装入批次应答消息。数据例如可以是如上所述的待同步数据，数据请求例如可以是针对待同步区块数据的区块数据 同步请求。
在将各个待发送数据组装入批次应答消息之后，在块404，确定当前的批次应答消息是否满足当前检查点条件。在满足当前检查点条件时，在块406，将当前的批次应答消息确定为当前检查点。各个检查点所对应的检查点条件可以基于待发送数据的生成顺序来确定。例如，以区块数据为例，可以基于各个区块的块高来生成各个检查点对应的检查点条件。可以在块高满足预定条件的待发送区块数据被组装入批次应答消息之后，将当前的批次应答消息作为当前检查点。预定条件例如可以设置为“块高是某数值的整数倍”。
在另一示例中，各个检查点所对应的检查点条件可以是基于已组装入批次应答消息的待发送数据数量来生成的。例如，可以将各个检查点对应的检查点条件设置为组装入批次应答消息的待发送数据数量达到某数值(例如3)的整数倍。在该示例中，当组装入批次应答消息的待发送数据数量为达到3时为第一个检查点，达到6时为第二个检查点，依次类推。在该示例中，如果针对本批次应答消息已确定了N个检查点，那么当前检查点条件为“已组装入当前的批次应答消息的待发送数据数量达到(N+1)×3个”。
在当前的批次应答消息满足当前检查点条件时，在块406，将当前的批次应答消息确定为当前检查点。然后，在块408，确定当前的批次应答消息的大小是否超过预定阈值。在确定当前的批次应答消息大小时，可以对当前的批次应答消息进行预定处理之后，基于处理结果来确定批次应大消息大小。例如，可以在将当前的批次应答消息进行序列化编码之后，基于编码结果中的字节数来确定当前的批次应答消息大小。序列化编码例如可以采用RLP编码等任意编码算法来实现。预定阈值例如可以是网络(例如区块链网络)中对单个消息大小的限制。
在当前的批次应答消息的大小超过预定阈值时，在块410，将前一检查点所对应的批次应答消息发送给数据请求发送方。
由于网络层对消息的大小存在限制，如果所组装的应答消息超过网络限制，所组装的应答消息将无法成功发送给数据请求发送方。然而，如果所组装的应答消息大小过小，将会导致网络资源浪费。利用本实施例，通过在组装批次应答消息时，约定检查点条件，从而在已组装的批次应答消息满足检查点条件时，确定批次应答消息的大小是否超过预定阈值。由此，既避免了所组装的应答消息超过网络限制的可能，又能够使批次应答消息尽可能地接近网络限制，从而能够充分利用网络资源。
此外，由于在确定批次应答消息大小的过程中通常涉及一系列运算过程(例如序列化编码过程)，因而确定批次应答消息通常会耗费一定的运算资源。在本实施例中，对于批次应答消息大小的确定是在满足检查点条件时进行的，也就是说，在批次应答消息的组装过程中，如果所组装的批次应答消息未达到检查点，则不需要执行批次应答消息大小的确定过程，因而还能够减小确定批次应答消息大小的次数，从而避免因频繁地进行消息大小确定的运算而导致负载过高。
在当前检查点对应的当前的批次应答消息大小超过预定阈值时，可以使批次应答消息回滚到前一检查点时的状态，从而得到前一检查点对应的批次应答消息。在另一示例中，可以如图5所示在批次应答消息的大小未超过阈值时，对各个检查点所对应的批次应答消息进行存储。图5是根据本说明书的另一实施例的用于发送针对数据请求的应答消息的方法的流程图。
如图5所示，在块502，响应于针对多个数据的数据请求，针对多个数据中的各个待发送数据，依次将各个待发送数据组装入批次应答消息。然后在将每个待发送数据组装入批次应答消息之后，在块504，确定当前的批次应答消息是否满足当前检查点条件，如果满足则在块506，将当前的批次应答消息确定为当前检查点。然后，在块508，确定当前的批次应答消息的大小是否超过预定阈值。在当前的批次应答消息的大小超过预定阈值时，在块510，将前一检查点所对应的批次应答消息发送给数据请求发送方。
在当前的批次应答消息的大小未超过预定阈值时，在块512，存储当前检查点所对应的当前的批次应答消息。在一个示例中，可以将当前的批次应答消息存储在缓存中。通过在各个检查点所对应的批次应答消息没有超过预定阈值时，存储该检查点对应的批次应答消息，从而当后一检查点对应的批次应答消息大小超过预定阈值时，能够从存储空间中读取在前检查点所对应的批次应答消息，以发送给数据请求消息发送方。
然后，在块514，删除所存储的前一检查点所对应的批次应答消息。如果当前检查点所对应的批次应答消息未超过预定阈值，那么可以确定前一检查点的批次应答消息不会被作为本批次应答消息的组装结果来发送给数据请求消息发送方，因而可以删除前一检查点对应的批次应答消息，以释放存储空间。
以下，参考图6A和图6B对各个检查点对应的检查点条件的示例进行描述。图6A和图6B是用于说明根据本说明书实施例的用于发送针对数据请求的应答消息的方法中的检查点的流程图。
在一个示例中，各个检查点与前一检查点所对应的待发送数据数量之差可以是递增的。如图6A所示，检查点1至4所对应的检查点条件分别是组装入批次应答消息的待发送数据数量达到2个、4个、8个、16个。检查点2至4与其前一检查点所对应的待发送数据数量之差分别是2、4、8。在该示例中，各个检查点所对应的已组装入批次应答消息的待发送数据数量的增长速度是递增的。通过使各个检查点对应的待发送数据数量以递增的速度增长，能够使所组装的批次应答消息尽快达到预定阈值，从而能够减少所确定的检查点的数量，并由此能够减少在检查点所执行的运算量。在一个示例中，可以在确定基准数值之后以该基准数值的整数次幂作为各个检查点对应的已组装的待发送数据数量。
在另一示例中，可以在所确定的检查点的数量未超过预定数量时，各个检查点与前一检查点所对应的待发送数据数量之差是递增的，还可以在所确定的检查点的数量超过预定数量时，各个检查点与前一检查点所对应的待发送数据数量之差是递减的。如图6B所示，检查点1至6所对应的检查点条件分别是组装入批次应答消息的待发送数据数量达到2个、4个、9个、13个、16个、18个。检查点2至5与其前一检查点所对应的待发送数据数量之差分别是2、5、4、3、2。在所确定的检查点数量未超过时，各个检查点所对应的已组装的待发送数据数量的增长速度是递增的，在所确定的检查点的数据达到4时，各个检查点所对应的已组装的待发送数据数量的增长速度是递减的。通过该示例，能够在减小批次应答消息的检查点数量的同时，还能够尽可能地使批次应答消息的大小接近网络限制，从而不仅能减少检查点带来的运算量，还能最大限度地提高网络资源利用率。
此外，还可以使得在已组装的待发送数据数量的增长速度进入递减状态后经过预定数量的检查点之后，或者在相对于前一检查点的已组装待发送数据数量的增长量低于预定数量时，使各个检查点与前一检查点对应的已组装的待发送数据数量之差是固定值。
图7是根据本说明书实施例的用于发送针对数据请求的应答消息的装置的结构框图。如图7所示，应答消息发送装置700包括批次应答消息组装单元710、检查点确定单元720、消息大小确定单元730、批次应答消息存储单元740、批次应答消息删除单元750和批次应答消息发送单元760。
批次应答消息组装单元710响应于针对多个数据的数据请求，针对多个数据中的各个待发送数据，将各个待发送数据中的至少一个该待发送数据组装入批次应答消息。检查点确定单元720确定当前的批次答消息的大小是否超过预定阈值，并在在当前的批 次应答消息满足当前检查点条件时，将当前的批次应答消息确定为当前检查点。各个检查点所对应的检查点条件是基于已被组装入批次应答消息的待发送数据数量生成的。
消息大小确定单元730确定当前的批次应答消息的大小是否超过预定阈值。在所述当前的批次应答消息的大小超过所述预定阈值时，批次应答消息发送单元740将前一检查点所对应的批次应答消息发送给数据请求发送方。
在当前的批次应答消息的大小未超过预定阈值时，批次应答消息存储单元750存储当前的批次应答消息。批次应答消息删除单元760删除所存储的前一检查点所对应的批次应答消息。
图7中的各个单元并不都是必要组成元素，在某些实施例中可以不包括其中的部分单元。例如可以不包括批次应答消息存储单元，还可以不包括批次应答消息删除单元。
图8是根据本说明书实施例的区块链系统的结构框图。如图8所示，区块链系统800包括第一区块链节点810和第二区块链节点820。
第一区块链节点810在确定相对于第二区块链节点缺少预定数据时，向第二区块链节点发送针对所缺少的多个预定数据的数据请求。数据请求可以是区块数据同步请求，预定数据可以是第一区块链节点810处缺少的区块数据。第二区块链节点820包括如上的应答消息发送装置，以将第一区块链节点810所请求的多个预定数据组装入应答消息并发送给第一区块链节点810。
以上参照图1到图8，对根据本说明书实施例的发送针对数据请求的应答消息的方法及装置和区块链系统的实施例进行了描述。在以上对方法实施例的描述中所提及的细节，同样适用于本说明书实施例的装置的实施例。
本说明书实施例的发送针对数据请求的应答消息的装置可以采用硬件实现，也可以采用软件或者硬件和软件的组合来实现。本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见。
本说明书实施例的发送针对数据请求的应答消息的装置可以采用硬件实现，也可以采用软件或者硬件和软件的组合来实现。以软件实现为例，作为一个逻辑意义上的装置，是通过其所在设备的处理器将存储器中对应的计算机程序指令读取到内存中运行形成的。在本说明书实施例中，用于生成区块链的装置例如可以利用计算设备实现。
图9是根据本说明书实施例的用于实现用于发送针对数据请求的应答消息的方法的计算设备的结构框图。如图9所示，计算设备900包括处理器910、存储器920、内 存930、通信接口940和内部总线950，并且处理器910、存储器(例如，非易失性存储器)920、内存930、通信接口940经由总线950连接在一起。根据一个实施例，计算设备900可以包括至少一个处理器910，该至少一个处理器910执行在计算机可读存储介质(即，存储器920)中存储或编码的至少一个计算机可读指令(即，上述以软件形式实现的元素)。
在一个实施例中，在存储器920中存储计算机可执行指令，其当执行时使得至少一个处理器910：响应于针对多个数据的数据请求，针对所述多个数据中的各个待发送数据，将各个待发送数据中的至少一个待发送数据组装入批次应答消息；定当前的批次答消息的大小是否超过预定阈值，并在当前的批次应答消息满足当前检查点条件时，将所述当前的批次应答消息确定为当前检查点，并确定所述当前的批次应答消息的大小是否超过预定阈值；以及在所述当前的批次应答消息的大小超过所述预定阈值时，将前一检查点所对应的批次应答消息发送给数据请求发送方。
应该理解，在存储器920中存储的计算机可执行指令当执行时使得至少一个处理器910进行本说明书实施例的各个实施例中以上结合图1-8描述的各种操作和功能。
根据一个实施例，提供了一种例如非暂时性机器可读介质的程序产品。非暂时性机器可读介质可以具有指令(即，上述以软件形式实现的元素)，该指令当被机器执行时，使得机器执行本说明书实施例的各个实施例中以上结合图1-8描述的各种操作和功能。
具体地，可以提供配有可读存储介质的系统或者装置，在该可读存储介质上存储着实现上述实施例中任一实施例的功能的软件程序代码，且使该系统或者装置的计算机或处理器读出并执行存储在该可读存储介质中的指令。
在这种情况下，从可读介质读取的程序代码本身可实现上述实施例中任何一项实施例的功能，因此机器可读代码和存储机器可读代码的可读存储介质构成了本发明的一部分。
可读存储介质的实施例包括软盘、硬盘、磁光盘、光盘(如CD-ROM、CD-R、CD-RW、DVD-ROM、DVD-RAM、DVD-RW、DVD-RW)、磁带、非易失性存储卡和ROM。可选择地，可以由通信网络从服务器计算机上或云上下载程序代码。
上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执 行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。
上述各流程和各系统结构图中不是所有的步骤和单元都是必须的，可以根据实际的需要忽略某些步骤或单元。各步骤的执行顺序不是固定的，可以根据需要进行确定。上述各实施例中描述的装置结构可以是物理结构，也可以是逻辑结构，即，有些单元可能由同一物理实体实现，或者，有些单元可能分由多个物理实体实现，或者，可以由多个独立设备中的某些部件共同实现。
在整个本说明书中使用的术语“示例性”意味着“用作示例、实例或例示”，并不意味着比其它实施例“优选”或“具有优势”。出于提供对所描述技术的理解的目的，具体实施方式包括具体细节。然而，可以在没有这些具体细节的情况下实施这些技术。在一些实例中，为了避免对所描述的实施例的概念造成难以理解，公知的结构和装置以框图形式示出。
以上结合附图详细描述了本说明书实施例的实施例的可选实施方式，但是，本说明书实施例的实施例并不限于上述实施方式中的具体细节，在本说明书实施例的实施例的技术构思范围内，可以对本说明书实施例的实施例的技术方案进行多种简单变型，这些简单变型均属于本说明书实施例的实施例的保护范围。
本说明书实施例内容的上述描述被提供来使得本领域任何普通技术人员能够实现或者使用本说明书实施例内容。对于本领域普通技术人员来说，对本说明书实施例内容进行的各种修改是显而易见的，并且，也可以在不脱离本说明书实施例内容的保护范围的情况下，将本文所定义的一般性原理应用于其它变型。因此，本说明书实施例内容并不限于本文所描述的示例和设计，而是与符合本文公开的原理和新颖性特征的最广范围相一致。

Claims (13)

  1. 一种用于发送针对数据请求的应答消息的方法，包括：
    响应于针对多个数据的数据请求，针对所述多个数据中的各个待发送数据，将所述各个待发送数据中的至少一个待发送数据组装入批次应答消息；
    确定当前的批次应答消息是否满足当前检查点条件；
    在所述当前的批次应答消息满足当前检查点条件时，将所述当前的批次应答消息确定为当前检查点，并确定所述当前的批次应答消息的大小是否超过预定阈值；以及
    在所述当前的批次应答消息的大小超过所述预定阈值时，将前一检查点所对应的批次应答消息发送给数据请求发送方。
  2. 如权利要求1所述的方法，还包括：
    在所述当前的批次应答消息的大小未超过所述预定阈值时，存储所述当前的批次应答消息；以及
    删除所存储的前一检查点所对应的批次应答消息。
  3. 如权利要求1所述的方法，其中，各个检查点所对应的检查点条件是基于已被组装入所述批次应答消息的待发送数据数量生成的。
  4. 如权利要求3所述的方法，其中，所述各个检查点与前一检查点所对应的待发送数据数量之差是递增的。
  5. 如权利要求3所述的方法，其中，在所确定的检查点的数量未超过预定数量时，所述各个检查点与前一检查点所对应的待发送数据数量之差是递增的，和/或
    在所确定的检查点的数量超过预定数量时，所述各个检查点与前一检查点所对应的待发送数据数量之差是递减的。
  6. 如权利要求1所述的方法，其中，所述数据请求发送方包括区块链系统中的数据落后的区块链节点，所述数据请求包括区块数据同步请求，所述数据包括所述区块链节点处缺少的区块数据。
  7. 一种用于发送针对数据请求的应答消息的装置，包括：
    批次应答消息组装单元，响应于针对多个数据的数据请求，针对所述多个数据中的各个待发送数据，将所述各个待发送数据中的至少一个待发送数据组装入批次应答消息；
    检查点确定单元，确定当前的批次应答消息是否满足当前检查点条件，并在所述当前的批次应答消息满足当前检查点条件时，将所述当前的批次应答消息确定为当前检查点；
    消息大小确定单元，确定所述当前的批次应答消息的大小是否超过预定阈值；以及
    批次应答消息发送单元，在所述当前的批次应答消息的大小超过所述预定阈值时，将前一检查点所对应的批次应答消息发送给数据请求发送方。
  8. 如权利要求7所述的装置，还包括：
    批次应答消息存储单元，在所述当前的批次应答消息的大小未超过所述预定阈值时，存储所述当前的批次应答消息；以及
    批次应答消息删除单元，删除所存储的前一检查点所对应的批次应答消息。
  9. 如权利要求7所述的装置，其中，各个检查点所对应的检查点条件是基于已被组装入所述批次应答消息的待发送数据数量生成的。
  10. 一种区块链系统，包括：
    第一区块链节点，所述第一区块链节点在确定相对于第二区块链节点缺少预定数据时，向所述第二区块链节点发送针对所缺少的多个预定数据的数据请求；以及
    第二区块链节点，包括如权利要求7-9中任一所述的装置。
  11. 如权利要求10所述的区块链系统，其中，所述数据请求包括区块数据同步请求，所述预定数据包括所述第一区块链节点处缺少的区块数据。
  12. 一种计算设备，包括：
    至少一个处理器；以及
    存储器，所述存储器存储指令，当所述指令被所述至少一个处理器执行时，使得所述至少一个处理器执行如权利要求1到6中任一所述的方法。
  13. 一种非暂时性机器可读存储介质，其存储有可执行指令，所述指令当被执行时使得所述机器执行如权利要求1到6中任一所述的方法。
PCT/CN2020/132054 2020-01-02 2020-11-27 发送针对数据请求的应答消息的方法及装置、区块链系统 WO2021135755A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202010002463.7A CN111211876B (zh) 2020-01-02 2020-01-02 发送针对数据请求的应答消息的方法及装置、区块链系统
CN202010002463.7 2020-01-02

Publications (1)

Publication Number Publication Date
WO2021135755A1 true WO2021135755A1 (zh) 2021-07-08

Family

ID=70789577

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2020/132054 WO2021135755A1 (zh) 2020-01-02 2020-11-27 发送针对数据请求的应答消息的方法及装置、区块链系统

Country Status (2)

Country Link
CN (1) CN111211876B (zh)
WO (1) WO2021135755A1 (zh)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111211876B (zh) * 2020-01-02 2021-10-12 支付宝(杭州)信息技术有限公司 发送针对数据请求的应答消息的方法及装置、区块链系统
CN114338574B (zh) * 2021-12-07 2024-01-30 哈尔滨工业大学 一种即时通讯方法、管理节点及系统

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105653652A (zh) * 2015-12-28 2016-06-08 上海瀚银信息技术有限公司 一种数据同步方法及系统
US20180039667A1 (en) * 2016-08-05 2018-02-08 Chicago Mercantile Exchange Inc. Systems and methods for blockchain rule synchronization
CN109886690A (zh) * 2019-03-06 2019-06-14 上海共链信息科技有限公司 一种区块链同步账本的方法
CN110363663A (zh) * 2019-07-12 2019-10-22 深圳前海微众银行股份有限公司 基于区块链的数据批量处理方法、装置、设备及存储介质
CN111211876A (zh) * 2020-01-02 2020-05-29 支付宝(杭州)信息技术有限公司 发送针对数据请求的应答消息的方法及装置、区块链系统

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10046228B2 (en) * 2016-05-02 2018-08-14 Bao Tran Smart device
US20180285839A1 (en) * 2017-04-04 2018-10-04 Datient, Inc. Providing data provenance, permissioning, compliance, and access control for data storage systems using an immutable ledger overlay network
CN107423152B (zh) * 2017-04-24 2019-05-21 杭州趣链科技有限公司 一种区块链共识节点自动恢复方法
US10938567B2 (en) * 2017-09-12 2021-03-02 Kadena Llc Parallel-chain architecture for blockchain systems
CN109729053A (zh) * 2017-10-31 2019-05-07 北京国双科技有限公司 内外网间数据的交互方法及装置
CN108335207B (zh) * 2018-02-14 2020-08-04 阿里巴巴集团控股有限公司 资产管理方法及装置、电子设备
CN110310107B (zh) * 2018-03-20 2023-12-12 华为技术有限公司 基于区块链的结算方法、区块链节点和客户端
CN109118230B (zh) * 2018-08-29 2022-04-05 众安信息技术服务有限公司 基于区块链的信息处理方法和装置
CN109189859B (zh) * 2018-09-20 2020-10-16 百度在线网络技术（北京）有限公司 区块链网络中的节点初始化方法和装置
CN109542888B (zh) * 2018-12-03 2020-12-01 百度在线网络技术（北京）有限公司 区块链的数据修改和同步方法、装置、设备及存储介质
CN109587238B (zh) * 2018-12-03 2021-08-03 百度在线网络技术（北京）有限公司 区块链的数据处理和同步方法、装置、设备及存储介质
CN113421166A (zh) * 2019-01-03 2021-09-21 创新先进技术有限公司 基于区块链的资产清分方法及装置、电子设备
CN110071876B (zh) * 2019-04-28 2023-04-28 创新先进技术有限公司 一种基于区块链的数据传输方法、装置及电子设备

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105653652A (zh) * 2015-12-28 2016-06-08 上海瀚银信息技术有限公司 一种数据同步方法及系统
US20180039667A1 (en) * 2016-08-05 2018-02-08 Chicago Mercantile Exchange Inc. Systems and methods for blockchain rule synchronization
CN109886690A (zh) * 2019-03-06 2019-06-14 上海共链信息科技有限公司 一种区块链同步账本的方法
CN110363663A (zh) * 2019-07-12 2019-10-22 深圳前海微众银行股份有限公司 基于区块链的数据批量处理方法、装置、设备及存储介质
CN111211876A (zh) * 2020-01-02 2020-05-29 支付宝(杭州)信息技术有限公司 发送针对数据请求的应答消息的方法及装置、区块链系统

Also Published As

Publication number Publication date
CN111211876A (zh) 2020-05-29
CN111211876B (zh) 2021-10-12

Similar Documents

Publication Publication Date Title
WO2020258831A1 (zh) 用于区块链系统中的主节点切换处理的方法及装置
WO2021135857A1 (zh) 对信任节点信息进行更新的方法及装置
US11614994B2 (en) Method, apparatus and electronic device for blockchain-based transaction consensus processing
US11128522B2 (en) Changing a master node in a blockchain system
US11698840B2 (en) Transaction consensus processing method and apparatus for blockchain and electronic device
US11032077B2 (en) Blockchain-based transaction method and apparatus, and remitter device
CN111062716B (zh) 生成区块链签名数据的方法及装置、区块链交易发起系统
WO2021135757A1 (zh) 用于执行交易正确性验证的方法及装置
WO2021184885A1 (zh) 用于更新区块链节点处的公钥集合的方法及装置
TWI732620B (zh) 用於管理基於區塊鏈的中心化帳本系統的方法、系統及裝置
US11283627B2 (en) Method and apparatus for generating blockchain transaction
TWI740378B (zh) 用於進行交易驗證的方法及裝置
WO2021135744A1 (zh) 用于区块链节点的数据同步方法及装置
US10951417B2 (en) Blockchain-based transaction verification
CN111837359A (zh) 管理基于区块链的中心化账本系统
EP3808030B1 (en) Managing blockchain-based centralized ledger systems
CN111226248A (zh) 管理基于区块链的中心化账本系统
US20220067715A1 (en) Method and apparatus for starting smart contract, electronic device, and storage medium
CN111183427A (zh) 管理基于区块链的中心化账本系统
WO2021135755A1 (zh) 发送针对数据请求的应答消息的方法及装置、区块链系统
WO2021143364A1 (zh) 获取去中心化应用集群中的交易处理状态的方法及装置
CN110827034B (zh) 用于发起区块链交易的方法及装置
CN111144894B (zh) Utxo处理方法及装置
CN111143381B (zh) 用于更新多层块链式结构中的信任点的方法及装置
WO2021114926A1 (zh) 用于生成多层块链式结构的方法及装置

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 20909678

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 20909678

Country of ref document: EP

Kind code of ref document: A1