WO2021135857A1 - 对信任节点信息进行更新的方法及装置 - Google Patents

对信任节点信息进行更新的方法及装置 Download PDF

Info

Publication number
WO2021135857A1
WO2021135857A1 PCT/CN2020/134542 CN2020134542W WO2021135857A1 WO 2021135857 A1 WO2021135857 A1 WO 2021135857A1 CN 2020134542 W CN2020134542 W CN 2020134542W WO 2021135857 A1 WO2021135857 A1 WO 2021135857A1
Authority
WO
WIPO (PCT)
Prior art keywords
node
blockchain
data
trusted
synchronized
Prior art date
Application number
PCT/CN2020/134542
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 WO2021135857A1 publication Critical patent/WO2021135857A1/zh

Links

Images

Classifications

    • 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/1095—Replication or mirroring of data, e.g. scheduling or transport for data synchronisation between network nodes
    • 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/104—Peer-to-peer [P2P] networks
    • H04L67/1074—Peer-to-peer [P2P] networks for supporting data block transmission mechanisms
    • H04L67/1078—Resource delivery mechanisms
    • 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/3236—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 using cryptographic hash functions
    • 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
    • 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, in particular, to a method and device for updating trusted node information used to determine a data synchronization peer node.
  • the blockchain system is a decentralized distributed data storage system involving multiple nodes. Once data is written to the blockchain, 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 updating trusted node information used to determine a data synchronization peer node.
  • a method for updating trusted node information used to determine the data synchronization peer node including: for the data to be synchronized at the first blockchain node, based on the trust
  • the node information is the second blockchain node that is determined by the data to be synchronized as the data synchronization peer node; a data synchronization request message for the data to be synchronized is sent to the second blockchain node to request the data to be synchronized.
  • the second blockchain node obtains the data to be synchronized; and based on the data synchronization response of the second blockchain node to the data synchronization request message, the trusted node information is updated.
  • the trusted node information may include a list of untrusted nodes, and based on the data synchronization response of the second blockchain node to the data synchronization request message, updating the trusted node information may include : When it is determined that the second blockchain node is an untrusted node based on the data synchronization response, the second blockchain node is added to the list of untrusted nodes.
  • the trusted node information may include a list of trusted nodes, and based on the data synchronization response of the second blockchain node to the data synchronization request message, updating the trusted node information may include: When it is determined that the second blockchain node is an untrusted node based on the historical data synchronization response, the second blockchain node will be deleted from the trusted node list.
  • updating the trusted node information may further include: When the node obtains the data to be synchronized or the data to be synchronized received from the second blockchain node fails the verification, it is determined that the second blockchain node is an untrusted node.
  • the method may further include: restoring the second blockchain node determined as an untrusted node to a trusted node based on a trusted node restoration condition.
  • the trusted node recovery condition may include: a predetermined time has elapsed after the second blockchain node is determined to be an untrusted node; and/or the second blockchain node After being determined as an untrusted node, the data to be synchronized after synchronization processing reaches a predetermined amount.
  • the data to be synchronized includes block data to be synchronized.
  • an apparatus for updating trusted node information for determining a data synchronization peer node including: a second blockchain node determining unit for the first blockchain node Based on the trust node information, determine the second blockchain node as the data synchronization peer node for the data to be synchronized based on the trust node information; the data synchronization request sending unit sends to the second blockchain node A data synchronization request message for the data to be synchronized to request to obtain the data to be synchronized from the second blockchain node; a trust node trust update unit based on the second blockchain node for the data synchronization The data synchronization response of the request message updates the trusted node information.
  • the trusted node information may include a list of untrusted nodes
  • the trusted node trust update unit may determine that the second blockchain node is an untrusted node based on the data synchronization response , Adding the second blockchain node to the list of untrusted nodes.
  • the trusted node information may include a list of trusted nodes
  • the trusted node trust update unit may determine that the second blockchain node is an untrusted node based on the historical data synchronization response , The second blockchain node will be deleted from the trusted node list.
  • the trusted node trust update unit may not obtain the to-be-synchronized data from the second blockchain node or the to-be-synchronized data received from the second blockchain node.
  • the synchronization data fails the verification, it is determined that the second blockchain node is an untrusted node.
  • the apparatus may further include: an untrusted node recovery unit, which recovers the second blockchain node determined as an untrusted node to a trusted node based on a trusted node recovery condition.
  • an untrusted node recovery unit which recovers the second blockchain node determined as an untrusted node to a trusted node based on a trusted node recovery condition.
  • the trusted node recovery condition may include: a predetermined time has elapsed after the second blockchain node is determined to be an untrusted node; and/or the second blockchain node After being determined as an untrusted node, the data to be synchronized after synchronization processing reaches a predetermined amount.
  • 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 trusted node information based on the data synchronization response of the second blockchain node as the data synchronization peer node, it is possible to determine the data synchronization for the data to be synchronized based on the trust of the trusted node In the case of the peer node, the untrusted node will not be determined as the data synchronization peer node, which can increase the success rate of receiving the data to be synchronized from the data synchronization peer node, thereby improving the data synchronization efficiency.
  • FIG. 1 shows a schematic diagram of an example of an environment that can be used to perform a method for updating trusted node information according to an embodiment of the present specification
  • Fig. 2 shows a schematic diagram of an example of a system architecture for executing the method for updating trusted node information according to an embodiment of the present specification
  • Fig. 3 is a flowchart for explaining an exemplary application scenario of a method for updating trusted node information according to an embodiment of the present specification
  • Fig. 4 is a flowchart of a method for updating trusted node information according to an embodiment of the present specification
  • FIG. 5 is a flowchart of an example of an untrusted node recovery process in a method for updating trusted node information according to an embodiment of the present specification
  • FIG. 6 is a flowchart of a data synchronization method for trusted node information updated by the method for updating trusted node information according to an embodiment of this specification;
  • Fig. 7 is a structural block diagram of an apparatus for updating trusted node information according to an embodiment of the present specification.
  • Fig. 8 is a structural block diagram of a computing device of a method for updating trusted node information 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 encrypted 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 perform a method for updating trusted node information 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 (eg, 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, laptops, 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 updating trusted node information according to an embodiment of the present specification.
  • An example of the system architecture 200 includes the participant systems 202, 204, and 206 corresponding to the participant A, the participant B, and the 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 (eg, computer, 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 updating trusted node information according to an embodiment of 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 the second blockchain node.
  • 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 blockchain node trusted by the first blockchain node can be determined based on the historical data of the interaction between the first blockchain node and each second blockchain node. For example, the blockchain 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 used as the trusted node.
  • the trusted node information can also be maintained locally, so that the trusted second blockchain node can be determined based on 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 data synchronization 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 data synchronization request message may include the block data information to be synchronized, for example, may include the block height range (for example, 81 to 100) of the block data to be synchronized.
  • the second blockchain node After receiving the block data request message, the second blockchain node assembles multiple block data requested by the data synchronization request message into a response message in block 310 in response to the data synchronization request. 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 data synchronization method of the embodiment of this specification
  • the data synchronization method of this specification can be applied to the synchronization process for any data.
  • the consensus process of block data when each blockchain node lacks consensus messages in part of the consensus phase, and thus requests other blockchain nodes to synchronize the missing consensus messages, the data synchronization method in this manual can also be applied .
  • Fig. 4 is a flowchart of a method for updating trusted node information according to an embodiment of the present specification.
  • the second blockchain node as the data synchronization peer node is determined for the data to be synchronized.
  • the trusted node information may include a list of trusted nodes, and the list of trusted nodes may indicate the trustworthy trusted nodes in the current blockchain system, so that the second node that is the data synchronization peer node can be determined from the trusted nodes indicated by the trusted node list.
  • Blockchain node may include a list of untrusted nodes, and the list of untrusted nodes may indicate untrusted nodes in the current blockchain system.
  • a data synchronization request message for the data to be synchronized is sent to the second blockchain node to request to obtain the data to be synchronized from the second blockchain node.
  • the data to be synchronized may be the block data to be synchronized as described above.
  • the data synchronization request message may include the block height of the block to be synchronized.
  • the second blockchain node may be a faulty node.
  • the second blockchain node may be a malicious node (for example, a Byzantine faulty node) or a faulty node.
  • the first blockchain node can re-determine a new second blockchain node as the data synchronization peer node for the data to be synchronized, and send a message to the determined new second blockchain node.
  • the blockchain node sends a data synchronization request to request the data to be synchronized.
  • the wrong node during the previous data synchronization may still be determined as the data synchronization peer node again. This will cause the first blockchain node to be unable to obtain the correct data to be synchronized again, and cause the first blockchain node to perform the data synchronization process multiple times for the same data to be synchronized. As a result, data synchronization efficiency is low, and node resources are wasted.
  • the trusted node information is updated based on the data synchronization response of the second blockchain node to the data synchronization request message.
  • the second blockchain node is a trusted node. If the second blockchain node is an untrusted node (that is, an error node), the second blockchain node may not send the requested data to be synchronized to the first blockchain node. At this time, if the data to be synchronized is not received after a predetermined time has passed after the data synchronization request message is sent, it can be determined that the second blockchain node is an untrusted node.
  • the second blockchain node may send wrong data to be synchronized to the first blockchain node (for example, when the second blockchain node is a malicious node). At this time, the data to be synchronized obtained by the first blockchain node from the second blockchain node will not be able to pass the local verification at the first blockchain node. In this case, the second blockchain node may also be determined as an untrusted node.
  • the trusted node information includes a trusted node list
  • the second blockchain node can be deleted from the trusted node list if it is determined that the second blockchain node is an untrusted node based on the data synchronization response of the second blockchain node. Therefore, when the data synchronization peer node is determined again for the data to be synchronized, the new data synchronization peer node can be determined from the updated trust section list, thereby improving the success rate when performing data synchronization again.
  • all the blockchain nodes in the blockchain system can be included in the trusted node list. After multiple trusted node update processes, untrusted error nodes will be deleted.
  • the trusted node information includes a list of untrusted nodes
  • the second blockchain node can be added to the untrusted node
  • the blockchain node that has been determined as an untrusted node will not be determined as the data synchronization peer node again, thus improving the time when data synchronization is performed again.
  • the success rate In an example, in the initial state, the list of untrusted nodes may be empty. When an untrusted error node is found during the data synchronization process, the node may be added to the list of untrusted nodes.
  • the error of a blockchain node determined to be an untrusted node can be recovered. For example, if a blockchain node fails to respond to the data synchronization request of the first blockchain node in time due to a failure, it can be restored to a trusted node after the failure of the blockchain node is repaired. In this case, if the trusted node information still excludes the second blockchain node from the data synchronization peer node, it will result in the inability to make full use of the node resources in the blockchain network, which is not conducive to improving the efficiency of data synchronization .
  • Fig. 5 is a flowchart of an example of an untrusted node recovery process in a method for updating trusted node information according to an embodiment of the present specification.
  • the second blockchain node is an untrusted node.
  • the second blockchain node restored as a trusted node may be deleted from the list of untrusted nodes. If the trusted node information includes a trusted node list, the second blockchain node restored as a trusted node can be added to the trusted node list again. As a result, the blockchain nodes that have been recovered from the error state can be used in time to perform data synchronization processing, so as to improve the utilization efficiency of the blockchain node resources, thereby improving the efficiency of data synchronization.
  • Fig. 6 is a flowchart of a data synchronization method of trusted node information updated by the method for updating trusted node information according to an embodiment of the present specification.
  • the second blockchain node as the data synchronization peer node is determined for the data to be synchronized.
  • the trusted node information is updated based on the historical data synchronization response of the historical data synchronization peer node to the historical data synchronization request.
  • the trusted node information can be updated with reference to the content described above with reference to FIGS. 4 and 5.
  • the historical data synchronization peer node is the second blockchain node that is determined to be the data synchronization peer node during the previous data synchronization process.
  • a data synchronization request message for the data to be synchronized is sent to the second blockchain node to request to obtain the data to be synchronized from the second blockchain node. Synchronous Data.
  • the data to be synchronized corresponding to the data synchronization request message is obtained from the second blockchain node.
  • the data to be synchronized can be locally verified, and when the verification is passed, the data to be synchronized can be synchronized to the local. For example, when the obtained block data to be synchronized is verified, the data to be synchronized can be added to the local blockchain.
  • the trusted node information has been updated, when the data synchronization peer node is determined, the possibility that the determined data synchronization peer node is an untrusted node can be reduced, thereby improving the success rate of data synchronization processing. , And improve the efficiency of data synchronization.
  • the trusted node update process and the data synchronization process described in the above embodiments can be performed at the same time. For example, when performing data synchronization for certain data to be synchronized, if the correct data to be synchronized cannot be obtained, the data synchronization peer node in the current round of data synchronization processing can be updated to an untrusted node in the trusted node information. When performing data synchronization processing for the data to be synchronized or subsequent data to be synchronized again, the data synchronization peer node may be determined based on the updated trust node trust.
  • Fig. 7 is a structural block diagram of an apparatus for updating trusted node information according to an embodiment of the present specification.
  • the trusted node updating apparatus includes a second blockchain node determining unit 710, a data synchronization request sending unit 720, and a trusted node trust updating unit 730.
  • the second blockchain node determining unit 710 determines the second blockchain node as the data synchronization peer node for the data to be synchronized based on the trust node information for the data to be synchronized at the first blockchain node.
  • the data synchronization request sending unit 720 sends a data synchronization request message for the data to be synchronized to the second blockchain node to request to obtain the data to be synchronized from the second blockchain node .
  • the trusted node trust updating unit 730 updates the trusted node information based on the data synchronization response of the second blockchain node to the data synchronization request message.
  • the trusted node information may include a list of untrusted nodes.
  • the trusted node trust update unit 730 may add the second blockchain node to the list of untrusted nodes when it is determined that the second blockchain node is an untrusted node based on the data synchronization response.
  • the trusted node trust update unit 730 may determine that the second blockchain node is untrusted when the data to be synchronized is not obtained from the second blockchain node or the data to be synchronized received from the second blockchain node is not verified. node.
  • the trusted node information may include a list of trusted nodes.
  • the trusted node trust update unit 730 may delete the second blockchain node from the trusted node list when it is determined that the second blockchain node is an untrusted node based on the historical data synchronization response.
  • the trusted node update apparatus 700 may further include an untrusted node recovery unit.
  • the untrusted node recovery unit recovers the second blockchain node determined as the untrusted node to the trusted node based on the trusted node recovery condition.
  • the trusted node recovery condition may include a predetermined time after the second blockchain node is determined to be an untrusted node, and may also include the synchronization process after the second blockchain node is determined to be an untrusted node. The data to be synchronized reaches the predetermined amount.
  • the device for updating trusted node information in the embodiments of this specification can be implemented by hardware, or 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 device for generating a block chain with a multi-layer structure in the embodiments of this specification can be implemented by hardware, or 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. In the embodiment of the present specification, the device for generating a blockchain can be realized by using a computing device, for example.
  • Fig. 8 is a structural block diagram of a computing device of a method for updating trusted node information according to an embodiment of the present specification.
  • the computing device 800 includes a processor 810, a memory 820, a memory 830, a communication interface 840, and an internal bus 850, and the processor 810, a memory (for example, a non-volatile memory) 820, a memory 830, and a communication interface 840 are connected together via a bus 850.
  • the computing device 800 may include at least one processor 810 that executes at least one computer-readable instruction (ie, the aforementioned Elements implemented in software).
  • computer-executable instructions are stored in the memory 820, which when executed, cause at least one processor 810 to: for the data to be synchronized at the first blockchain node, based on the trusted node information,
  • the data to be synchronized is determined to be the second blockchain node of the data synchronization peer node; and a data synchronization request message for the data to be synchronized is sent to the second blockchain node to request data synchronization from the second blockchain.
  • the node obtains the data to be synchronized; and updates the trusted node information based on the data synchronization response of the second blockchain node to the data synchronization request message.
  • a program product such as a non-transitory machine-readable medium.
  • the non-transitory machine-readable medium may have instructions (ie, the above-mentioned elements implemented in the form of software), which, when executed by a machine, cause the machine to execute the various embodiments of the embodiments of the present specification described above in conjunction with FIGS. Various operations and functions.
  • 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 Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

本说明书实施例提供了一种对用于确定数据同步对端节点的信任节点信息进行更新的方法，包括：针对第一区块链节点处的待同步数据，基于所述信任节点信息，为所述待同步数据确定作为数据同步对端节点的第二区块链节点；向所述第二区块链节点发送针对所述待同步数据的数据同步请求消息，以请求从所述第二区块链节点获取所述待同步数据；基于所述第二区块链节点针对所述数据同步请求消息的数据同步响应，更新所述信任节点信息。

Description

对信任节点信息进行更新的方法及装置 技术领域
本说明书实施例涉及区块链技术领域，具体地，涉及对用于确定数据同步对端节点的信任节点信息进行更新的方法及装置。
背景技术
区块链系统是一种去中心化的、由多个节点参与的分布式数据存储系统。数据一旦被写入区块链，一方面，意味着数据在区块链网络中被公开，另一方面，写入区块链的数据也难以被删除与篡改。此外，中心化设备也可以采用类似于区块链存储(可以视为中心化的区块链存储)的方式对数据进行存储。
区块链系统中通常存在多个参与节点。已有参与节点之间通过共识协议来确保各自数据的一致性。但是，当出现参与节点出现故障、新参与节点加入或者其他各种原因时，可能导致某参与节点的数据落后于其它正常的参与节点。因而，区块链系统需要通过数据同步协议，来确保落后的参与节点能够使本地所维护的数据追赶上其它正常参与节点，从而参与到正常的共识过程中。当某参与节点发现自己所维护的数据落后于其它正常节点时，可以发起数据同步过程，即向正常参与节点请求其缺少的数据。正常节点在接收到数据请求时，可以将落后的参与节点所请求的数据包括在应答消息中发送给落后参与节点。
发明内容
鉴于上述，本说明书实施例提供了一种对用于确定数据同步对端节点的信任节点信息进行更新的方法及装置。
根据本说明书实施例的一个方面，提供了一种对用于确定数据同步对端节点的信任节点信息进行更新的方法，包括：针对第一区块链节点处的待同步数据，基于所述信任节点信息，为所述待同步数据确定作为数据同步对端节点的第二区块链节点；向所述第二区块链节点发送针对所述待同步数据的数据同步请求消息，以请求从所述第二区块链节点获取所述待同步数据；基于所述第二区块链节点针对所述数据同步请求消息的数据同步响应，更新所述信任节点信息。
可选的，在一个示例中，所述信任节点信息可以包括非信任节点列表，基于所述第二区块链节点针对所述数据同步请求消息的数据同步响应，更新所述信任节点信息可以包括：在基于所述数据同步响应确定出所述第二区块链节点是非信任节点时，将所述第二区块链节点加入所述非信任节点列表。
可选的，在一个示例中，所述信任节点信息可以包括信任节点列表，基于所述第二区块链节点针对所述数据同步请求消息的数据同步响应，更新所述信任节点信息可以包括：在基于所述历史数据同步响应确定出所述第二区块链节点是非信任节点时，将从所述信任节点列表中删除所述第二区块链节点。
可选的，在一个示例中，基于所述第二区块链节点针对所述数据同步请求消息的数据同步响应，更新所述信任节点信息还可以包括：在未从所述第二区块链节点获取到所述待同步数据或从所述第二区块链节点处接收到的待同步数据未通过验证时，确定所述第二区块链节点是非信任节点。
可选的，在一个示例中，所述方法还可以包括：基于信任节点恢复条件，将被确定为非信任节点的所述第二区块链节点恢复为信任节点。
可选的，在一个示例中，所述信任节点恢复条件可以包括：在所述第二区块链节点被确定为非信任节点后经过预定时间；和/或在所述第二区块链节点被确定为非信任节点后，经过同步处理的待同步数据达到预定数量。
可选的，在一个示例中，所述待同步数据包括待同步区块数据。
根据本说明书实施例的另一方面，还提供一种对用于确定数据同步对端节点的信任节点信息进行更新的装置，包括：第二区块链节点确定单元，针对第一区块链节点处的待同步数据，基于所述信任节点信息，为所述待同步数据确定作为数据同步对端节点的第二区块链节点；数据同步请求发送单元，向所述第二区块链节点发送针对所述待同步数据的数据同步请求消息，以请求从所述第二区块链节点获取所述待同步数据；信任节点信任更新单元，基于所述第二区块链节点针对所述数据同步请求消息的数据同步响应，更新所述信任节点信息。
可选的，在一个示例中，所述信任节点信息可以包括非信任节点列表，所述信任节点信任更新单元可以在基于所述数据同步响应确定出所述第二区块链节点是非信任节点时，将所述第二区块链节点加入所述非信任节点列表。
可选的，在一个示例中，所述信任节点信息可以包括信任节点列表，所述信任节 点信任更新单元可以在基于所述历史数据同步响应确定出所述第二区块链节点是非信任节点时，将从所述信任节点列表中删除所述第二区块链节点。
可选的，在一个示例中，所述信任节点信任更新单元可以在未从所述第二区块链节点获取到所述待同步数据或从所述第二区块链节点处接收到的待同步数据未通过验证时，确定所述第二区块链节点是非信任节点。
可选的，在一个示例中，所述装置还可以包括：非信任节点恢复单元，基于信任节点恢复条件，将被确定为非信任节点的所述第二区块链节点恢复为信任节点。
可选的，在一个示例中，所述信任节点恢复条件可以包括：在所述第二区块链节点被确定为非信任节点后经过预定时间；和/或在所述第二区块链节点被确定为非信任节点后，经过同步处理的待同步数据达到预定数量。
根据本说明书实施例的另一方面，还提供一种计算设备，包括：至少一个处理器；以及存储器，所述存储器存储指令，当所述指令被所述至少一个处理器执行时，使得所述至少一个处理器执行如上所述的方法。
根据本说明书实施例的另一方面，还提供一种非暂时性机器可读存储介质，其存储有可执行指令，所述指令当被执行时使得所述机器执行如上所述的方法。
利用本说明书实施例的方法和装置，通过基于作为数据同步对端节点的第二区块链节点的数据同步响应来更新信任节点信息，能够使得在基于信任节点信任来为待同步数据确定数据同步对端节点时，不会将非信任节点确定为数据同步对端节点，由此能够提高从数据同步对端节点接收到待同步数据的成功率，从而提高数据同步效率。
附图说明
通过参照下面的附图，可以实现对于本说明书实施例内容的本质和优点的进一步理解。在附图中，类似组件或特征可以具有相同的附图标记。附图是用来提供对本发明实施例的进一步理解，并且构成说明书的一部分，与下面的具体实施方式一起用于解释本说明书实施例的实施例，但并不构成对本说明书实施例的实施例的限制。
图1示出了可用于执行根据本说明书实施例的对信任节点信息进行更新的方法的环境的示例的示意图；
图2示出了执行根据本说明书实施例的对信任节点信息进行更新的方法的系统架构的示例的示意图；
图3是用于说明根据本说明书实施例的对信任节点信息进行更新的方法的示例性应用场景的流程图；
图4是根据本说明书实施例的对信任节点信息进行更新的方法的流程图；
图5是根据本说明书实施例的对信任节点信息进行更新的方法中的非信任节点恢复过程的示例的流程图；
图6是利用本说明书实施例的对信任节点信息进行更新的方法所更新的信任节点信息的数据同步方法的流程图；
图7是根据本说明书实施例的对信任节点信息进行更新的装置的结构框图；以及
图8是根据本说明书实施例的一个实施例的对信任节点信息进行更新的方法的计算设备的结构框图。
具体实施方式
以下将参考示例实施方式讨论本文描述的主题。应该理解，讨论这些实施方式只是为了使得本领域技术人员能够更好地理解从而实现本文描述的主题，并非是对权利要求书中所阐述的保护范围、适用性或者示例的限制。可以在不脱离本说明书实施例内容的保护范围的情况下，对所讨论的元素的功能和排列进行改变。各个示例可以根据需要，省略、替代或者添加各种过程或组件。另外，相对一些示例所描述的特征在其它例子中也可以进行组合。
如本文中使用的，术语“包括”及其变型表示开放的术语，含义是“包括但不限于”。术语“基于”表示“至少部分地基于”。术语“一个实施例”和“一实施例”表示“至少一个实施例”。术语“另一个实施例”表示“至少一个其他实施例”。术语“第一”、“第二”等可以指代不同的或相同的对象。下面可以包括其他的定义，无论是明确的还是隐含的。除非上下文中明确地指明，否则一个术语的定义在整个说明书中是一致的。
现在结合附图来描述本说明书实施例的对信任节点信息进行更新的方法及装置。
区块链是一种按照时间顺序来将数据区块顺序相连组合而成的链式数据结构，并且以密码学方式保证数据区块不可篡改和不可伪造。区块链包括一个或多个区块。区块链中的每个区块通过包括该区块链中紧接其之前的前一个区块的加密散列而链接到该前一个区块。每个区块还包括时间戳、该区块的加密哈希以及一个或多个交易 (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至图5，对本说明书实施例的数据同步方法的示例进行说明。
图4是根据本说明书实施例的对信任节点信息进行更新的方法的流程图。
如图4所示，在块402，针对第一区块链节点处的待同步数据，基于信任节点信息，为待同步数据确定作为数据同步对端节点的第二区块链节点。信任节点信息可以包括信任节点列表，信任节点列表可以指示当前区块链系统中的值得信任的信任节点，从而可以从信任节点列表所指示的信任节点中确定出作为数据同步对端节点的第二区块链节点。在另一示例中，信任节点信息可以包括非信任节点列表，非信任节点列表可以指示 在当前区块链系统中的不可信节点。在确定第二区块链节点时，非信任节点列表所指示的非信任节点将不会被确定为第二区块链节点。
在确定出第二区块链节点之后，在块404，向第二区块链节点发送针对待同步数据的数据同步请求消息，以请求从第二区块链节点获取待同步数据。待同步数据可以是如上所述的待同步区块数据。在该示例中，数据同步请求消息可以包括待同步区块的块高。第二区块链节点在接收到数据同步请求消息之后，可以从数据同步请求消息中确定出第一区块链节点所请求的待同步数据，并在将该待同步数据组装入应答消息之后发送给第一区块链节点。
在某些情况下，第二区块链节点可能是错误节点，例如，第二区块链节点可能是作恶节点(例如拜占庭错误节点)或是出现故障的节点。当第二区块链节点是错误节点时，将无法从第二区块链节点处获取到待同步数据，或者所获取的待同步数据无法通过第一区块链节点的本地验证。此时，为了顺利地实现数据同步，第一区块链节点可以重新为该待同步数据确定作为数据同步对端节点的新的第二区块链节点，并向所确定出的新的第二区块链节点发送数据同步请求，以请求获取待同步数据。但是，在重新确定第二区块链节点时，在之前执行数据同步时的错误节点仍有可能被再次确定为数据同步对端节点。这将会导致第一区块链节点再次无法获取到正确的待同步数据，并且会导致第一区块链节点针对同样的待同步数据多次执行数据同步过程。因而，会导致数据同步效率低下，并且浪费节点资源。
因而，在向第二区块链节点发送数据同步请求之后，在块406，基于第二区块链节点针对数据同步请求消息的数据同步响应，更新信任节点信息。基于第二区块链节点针对数据同步请求消息的数据同步响应，可以确定出第二区块链节点是否是信任节点。如果第二区块链节点是非信任节点(即错误节点)，第二区块链节点可能不会向第一区块链节点发送所请求的待同步数据。此时，如果在发出数据同步请求消息之后经过预定时间仍未接收到待同步数据，则可以确定第二区块链节点是非信任节点。此外，如果第二区块链节点是非信任节点，第二区块链节点可能会向第一区块链节点发送错误的待同步数据(例如，当第二区块链节点是作恶节点时)。此时，第一区块链节点从第二区块链节点处获取的待同步数据将无法通过第一区块链节点处的本地验证。在这种情况下，也可以将第二区块链节点确定为非信任节点。
在信任节点信息包括信任节点列表的示例中，如果基于第二区块链节点的数据同步响应确定出第二区块链节点是非信任节点，则可以从信任节点列表中删除第二区块链 节点。由此，在再次为该待同步数据确定数据同步对端节点时，可以从更新后的信任节列表中确定新的数据同步对端节点，因而能够提高再次执行数据同步时的成功率。在一个示例中，在初始状态下可以将区块链系统中所有的区块链节点包括在信任节点列表中，经过多次信任节点更新过程之后，不被信任的错误节点将被删除。
在信任节点信息包括非信任节点列表的示例中，如果基于第二区块链节点的数据同步响应确定出第二区块链节点是非信任节点，则可以将第二区块链节点加入非信任节点列表，在再次为该待同步数据确定数据同步对端节点时，已被确定为非信任节点的区块链节点将不会被再次确定为数据同步对端节点，因而能够提高再次执行数据同步时的成功率。在一个示例中，在初始状态下，非信任节点列表可以为空，当在数据同步过程中发现有不被信任的错误节点时，可以将该节点加入非信任节点列表中。
在某些情形下，被确定为非信任节点的区块链节点的错误可以被恢复。例如，如果区块链节点是因为故障未能及时响应第一区块链节点的数据同步请求，当该区块链节点的故障被修复之后即可恢复为信任节点。在这种情况下，如果信任节点信息仍然将第二区块链节点排除在数据同步对端节点之外，将会导致不能充分利用区块链网络中的节点资源，因而不利于提高数据同步效率。
鉴于上述情况，在将第二区块链节点确定为非信任节点之后，可以基于信任节点恢复条件，将被确定为非信任节点的第二区块链节点恢复为信任节点。图5是根据本说明书的一个实施例的对信任节点信息进行更新的方法中的非信任节点恢复过程的示例的流程图。
如图5所示，在块502，确定第二区块链节点是非信任节点。在将第二区块链节点确定为非信任节点之后，在块504，确定在第二区块链节点被确定为非信任节点后是否已经过预定时间。还可以在块504，确定在第二区块链节点被确定为非信任节点后，经过同步处理的待同步数据达到预定数量。例如，在第二区块链节点被确定为非信任节点之后，成功地被同步到本地的待同步区块数据的数量达到100个，则在块506可以将该第二区块链节点恢复为信任节点。
如果信任节点信息包括非信任节点列表，则可以从非信任节点列表中删除被恢复为信任节点的第二区块链节点。如果信任节点信息包括信任节点列表，则可以将被恢复为信任节点的第二区块链节点重新加入到信任节点列表中。由此能够及时利用已从错误状态中恢复的区块链节点来进行数据同步处理，以提高区块链节点资源的利用效率，进而提高数据同步效率。
以下将结合图6来描述利用上述实施例所更新的信任节点信息的应用示例。
图6是利用本说明书实施例的对信任节点信息进行更新的方法所更新的信任节点信息的数据同步方法的流程图。
如图6所示，在块602，针对第一区块链节点处的待同步数据，基于信任节点信息，为待同步数据确定作为数据同步对端节点的第二区块链节点。其中，信任节点信息是基于历史数据同步对端节点针对历史数据同步请求的历史数据同步响应来更新的。可以参照如上述参照图4和图5所描述的内容来更新信任节点信息。历史数据同步对端节点是在之前执行数据同步处理过程中被确定为数据同步对端节点的第二区块链节点。
在确定出针对该待同步数据的第二区块链节点之后，在块604，向第二区块链节点发送针对待同步数据的数据同步请求消息，以请求从第二区块链节点获取待同步数据。
然后，在块606，从第二区块链节点处获取对应于数据同步请求消息的待同步数据。在获取到待同步数据之后，可以对待同步数据进行本地验证，当验证通过时，可以将待同步数据同步到本地。例如，当所获取的待同步区块数据通过验证时，可以将该待同步数据加入到本地的区块链中。
通过该实施例，由于信任节点信息已经过更新，因而在确定数据同步对端节点时，能够降低所确定出的数据同步对端节点是非信任节点的可能性，从而能够提高数据同步处理的成功率，并提高数据同步效率。
在以上实施例中所描述的信任节点更新过程和数据同步过程可以同时执行的。例如，在针对某待同步数据进行数据同步时，如果未能获取到正确的待同步数据，则可以在信任节点信息中将本轮数据同步处理中的数据同步对端节点更新为非信任节点。在再次针对该待同步数据或后续待同步数据执行数据同步处理时，可以基于更新后的信任节点信任来确定数据同步对端节点。
图7是根据本说明书实施例的对信任节点信息进行更新的装置的结构框图。如图7所示，信任节点更新装置包括第二区块链节点确定单元710、数据同步请求发送单元720和信任节点信任更新单元730。
第二区块链节点确定单元710针对第一区块链节点处的待同步数据，基于信任节点信息，为待同步数据确定作为数据同步对端节点的第二区块链节点。在确定出第二区块链节点之后，数据同步请求发送单元720向第二区块链节点发送针对待同步数据的数据同步请求消息，以请求从第二区块链节点获取所述待同步数据。然后，信任节点信任 更新单元730基于第二区块链节点针对数据同步请求消息的数据同步响应，更新信任节点信息。
在一个示例中信任节点信息可以包括非信任节点列表。在该示例中，信任节点信任更新单元730可以在基于数据同步响应确定出第二区块链节点是非信任节点时，将第二区块链节点加入非信任节点列表。信任节点信任更新单元730可以在未从第二区块链节点获取到待同步数据或从第二区块链节点处接收到的待同步数据未通过验证时，确定第二区块链节点是非信任节点。
在另一个示例中，信任节点信息可以包括信任节点列表。在该示例中，信任节点信任更新单元730可以在基于历史数据同步响应确定出第二区块链节点是非信任节点时，将从信任节点列表中删除第二区块链节点。
虽然图7中未示例，信任节点更新装置700还可以还包括非信任节点恢复单元。非信任节点恢复单元基于信任节点恢复条件，将被确定为非信任节点的第二区块链节点恢复为信任节点。在一个示例中，信任节点恢复条件可以包括在第二区块链节点被确定为非信任节点后经过预定时间，还可以包括第二区块链节点被确定为非信任节点后，经过同步处理的待同步数据达到预定数量。
以上参照图1到图7，对根据本说明书实施例的对信任节点信息进行更新的方法及装置的实施例进行了描述。在以上对方法实施例的描述中所提及的细节，同样适用于本说明书实施例的装置的实施例。
本说明书实施例的对信任节点信息进行更新的装置可以采用硬件实现，也可以采用软件或者硬件和软件的组合来实现。本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见。
本说明书实施例的用于生成具有多层结构的区块链的装置可以采用硬件实现，也可以采用软件或者硬件和软件的组合来实现。以软件实现为例，作为一个逻辑意义上的装置，是通过其所在设备的处理器将存储器中对应的计算机程序指令读取到内存中运行形成的。在本说明书实施例中，用于生成区块链的装置例如可以利用计算设备实现。
图8是根据本说明书实施例的一个实施例的对信任节点信息进行更新的方法的计算设备的结构框图。如图8所示，计算设备800包括处理器810、存储器820、内存830、通信接口840和内部总线850，并且处理器810、存储器(例如，非易失性存储器)820、内存830、通信接口840经由总线850连接在一起。根据一个实施例，计算设备800可 以包括至少一个处理器810，该至少一个处理器810执行在计算机可读存储介质(即，存储器820)中存储或编码的至少一个计算机可读指令(即，上述以软件形式实现的元素)。
在一个实施例中，在存储器820中存储计算机可执行指令，其当执行时使得至少一个处理器810：针对第一区块链节点处的待同步数据，基于所述信任节点信息，为所述待同步数据确定作为数据同步对端节点的第二区块链节点；向所述第二区块链节点发送针对所述待同步数据的数据同步请求消息，以请求从所述第二区块链节点获取所述待同步数据；基于所述第二区块链节点针对所述数据同步请求消息的数据同步响应，更新所述信任节点信息。
应该理解，在存储器820中存储的计算机可执行指令当执行时使得至少一个处理器810进行本说明书实施例的各个实施例中以上结合图1-7描述的各种操作和功能。
根据一个实施例，提供了一种例如非暂时性机器可读介质的程序产品。非暂时性机器可读介质可以具有指令(即，上述以软件形式实现的元素)，该指令当被机器执行时，使得机器执行本说明书实施例的各个实施例中以上结合图1-7描述的各种操作和功能。
具体地，可以提供配有可读存储介质的系统或者装置，在该可读存储介质上存储着实现上述实施例中任一实施例的功能的软件程序代码，且使该系统或者装置的计算机或处理器读出并执行存储在该可读存储介质中的指令。
在这种情况下，从可读介质读取的程序代码本身可实现上述实施例中任何一项实施例的功能，因此机器可读代码和存储机器可读代码的可读存储介质构成了本发明的一部分。
可读存储介质的实施例包括软盘、硬盘、磁光盘、光盘(如CD-ROM、CD-R、CD-RW、DVD-ROM、DVD-RAM、DVD-RW、DVD-RW)、磁带、非易失性存储卡和ROM。可选择地，可以由通信网络从服务器计算机上或云上下载程序代码。
上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。
上述各流程和各系统结构图中不是所有的步骤和单元都是必须的，可以根据实际的需要忽略某些步骤或单元。各步骤的执行顺序不是固定的，可以根据需要进行确定。上述各实施例中描述的装置结构可以是物理结构，也可以是逻辑结构，即，有些单元可能由同一物理实体实现，或者，有些单元可能分由多个物理实体实现，或者，可以由多个独立设备中的某些部件共同实现。
在整个本说明书中使用的术语“示例性”意味着“用作示例、实例或例示”，并不意味着比其它实施例“优选”或“具有优势”。出于提供对所描述技术的理解的目的，具体实施方式包括具体细节。然而，可以在没有这些具体细节的情况下实施这些技术。在一些实例中，为了避免对所描述的实施例的概念造成难以理解，公知的结构和装置以框图形式示出。
以上结合附图详细描述了本说明书实施例的实施例的可选实施方式，但是，本说明书实施例的实施例并不限于上述实施方式中的具体细节，在本说明书实施例的实施例的技术构思范围内，可以对本说明书实施例的实施例的技术方案进行多种简单变型，这些简单变型均属于本说明书实施例的实施例的保护范围。
本说明书实施例内容的上述描述被提供来使得本领域任何普通技术人员能够实现或者使用本说明书实施例内容。对于本领域普通技术人员来说，对本说明书实施例内容进行的各种修改是显而易见的，并且，也可以在不脱离本说明书实施例内容的保护范围的情况下，将本文所定义的一般性原理应用于其它变型。因此，本说明书实施例内容并不限于本文所描述的示例和设计，而是与符合本文公开的原理和新颖性特征的最广范围相一致。

Claims (15)

  1. 一种对用于确定数据同步对端节点的信任节点信息进行更新的方法，包括：
    针对第一区块链节点处的待同步数据，基于所述信任节点信息，为所述待同步数据确定作为数据同步对端节点的第二区块链节点；
    向所述第二区块链节点发送针对所述待同步数据的数据同步请求消息，以请求从所述第二区块链节点获取所述待同步数据；以及
    基于所述第二区块链节点针对所述数据同步请求消息的数据同步响应，更新所述信任节点信息。
  2. 如权利要求1所述的方法，其中，所述信任节点信息包括非信任节点列表，基于所述第二区块链节点针对所述数据同步请求消息的数据同步响应，更新所述信任节点信息包括：
    在基于所述数据同步响应确定出所述第二区块链节点是非信任节点时，将所述第二区块链节点加入所述非信任节点列表。
  3. 如权利要求1所述的方法，其中，所述信任节点信息包括信任节点列表，基于所述第二区块链节点针对所述数据同步请求消息的数据同步响应，更新所述信任节点信息包括：
    在基于所述历史数据同步响应确定出所述第二区块链节点是非信任节点时，将从所述信任节点列表中删除所述第二区块链节点。
  4. 如权利要求2或3所述的方法，其中，基于所述第二区块链节点针对所述数据同步请求消息的数据同步响应，更新所述信任节点信息还包括：
    在未从所述第二区块链节点获取到所述待同步数据或从所述第二区块链节点处接收到的待同步数据未通过验证时，确定所述第二区块链节点是非信任节点。
  5. 如权利要求2或3所述的方法，还包括：
    基于信任节点恢复条件，将被确定为非信任节点的所述同步对端节点恢复为信任节点。
  6. 如权利要求5所述的方法，其中，所述信任节点恢复条件包括：
    在所述第二区块链节点被确定为非信任节点后经过预定时间；和/或
    在所述第二区块链节点被确定为非信任节点后，经过同步处理的待同步数据达到预定数量。
  7. 如权利要求1至3中任一所述的方法，其中，所述待同步数据包括待同步区块数据。
  8. 一种对用于确定数据同步对端节点的信任节点信息进行更新的装置，包括：
    第二区块链节点确定单元，针对第一区块链节点处的待同步数据，基于所述信任节点信息，为所述待同步数据确定作为数据同步对端节点的第二区块链节点；
    数据同步请求发送单元，向所述第二区块链节点发送针对所述待同步数据的数据同步请求消息，以请求从所述第二区块链节点获取所述待同步数据；以及
    信任节点信任更新单元，基于所述第二区块链节点针对所述数据同步请求消息的数据同步响应，更新所述信任节点信息。
  9. 如权利要求8所述的装置，其中，所述信任节点信息包括非信任节点列表，所述信任节点信任更新单元在基于所述数据同步响应确定出所述第二区块链节点是非信任节点时，将所述第二区块链节点加入所述非信任节点列表。
  10. 如权利要求8所述的装置，其中，所述信任节点信息包括信任节点列表，所述信任节点信任更新单元在基于所述历史数据同步响应确定出所述第二区块链节点是非信任节点时，将从所述信任节点列表中删除所述第二区块链节点。
  11. 如权利要求9或10所述的装置，其中，所述信任节点信任更新单元在未从所述第二区块链节点获取到所述待同步数据或从所述第二区块链节点处接收到的待同步数据未通过验证时，确定所述第二区块链节点是非信任节点。
  12. 如权利要求9或10所述的装置，还包括：
    非信任节点恢复单元，基于信任节点恢复条件，将被确定为非信任节点的所述第二区块链节点恢复为信任节点。
  13. 如权利要求12所述的装置，其中，所述信任节点恢复条件包括：
    在所述第二区块链节点被确定为非信任节点后经过预定时间；和/或
    在所述第二区块链节点被确定为非信任节点后，经过同步处理的待同步数据达到预定数量。
  14. 一种计算设备，包括：
    至少一个处理器；以及
    存储器，所述存储器存储指令，当所述指令被所述至少一个处理器执行时，使得所述至少一个处理器执行如权利要求1到7中任一所述的方法。
  15. 一种非暂时性机器可读存储介质，其存储有可执行指令，所述指令当被执行时使得所述机器执行如权利要求1到7中任一所述的方法。
PCT/CN2020/134542 2020-01-02 2020-12-08 对信任节点信息进行更新的方法及装置 WO2021135857A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202010000701.0 2020-01-02
CN202010000701.0A CN111212139A (zh) 2020-01-02 2020-01-02 对信任节点信息进行更新的方法及装置

Publications (1)

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

Family

ID=70787346

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2020/134542 WO2021135857A1 (zh) 2020-01-02 2020-12-08 对信任节点信息进行更新的方法及装置

Country Status (2)

Country Link
CN (1) CN111212139A (zh)
WO (1) WO2021135857A1 (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115687527A (zh) * 2022-11-09 2023-02-03 呼和浩特市大旗网络有限公司 一种基于区块链大数据的存储系统
WO2024159781A1 (zh) * 2023-01-31 2024-08-08 腾讯科技（深圳）有限公司 基于区块链网络的数据处理方法、装置、设备及存储介质

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111212139A (zh) * 2020-01-02 2020-05-29 支付宝(杭州)信息技术有限公司 对信任节点信息进行更新的方法及装置
CN112765137B (zh) * 2021-04-07 2021-06-22 暗链科技(深圳)有限公司 基于区块分布式区块链的区块同步方法及电子设备
CN113515535A (zh) * 2021-05-31 2021-10-19 深圳市朝明科技信息有限公司 区块链的电子商务信息变更方法及系统
CN113259118B (zh) * 2021-06-02 2021-09-24 支付宝(杭州)信息技术有限公司 同步节点信息列表的方法
CN114338723B (zh) * 2021-12-31 2024-08-16 支付宝(杭州)信息技术有限公司 一种区块同步方法、装置、电子设备和存储介质
CN114422526B (zh) * 2021-12-31 2024-03-15 支付宝(杭州)信息技术有限公司 一种区块同步方法、装置、电子设备和存储介质
CN114048270B (zh) * 2022-01-14 2022-05-13 北京大学深圳研究生院 区块链数据同步的方法和计算机可读存储介质
CN115314510B (zh) * 2022-07-29 2024-04-05 北京智融云河科技有限公司 区块链节点的同步方法、装置、电子设备和存储介质

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103701939A (zh) * 2014-01-16 2014-04-02 南通大学 数据交换系统及其方法
CN107317842A (zh) * 2017-05-31 2017-11-03 北京大学深圳研究生院 基于ndn的区块链同步方法和装置
CN108848184A (zh) * 2018-06-29 2018-11-20 北京金山安全软件有限公司 一种基于信任机制的区块链节点同步方法及装置
CN108924223A (zh) * 2018-06-29 2018-11-30 北京金山安全软件有限公司 一种区块链的节点同步方法及装置
US20190058582A1 (en) * 2017-08-21 2019-02-21 NIIT Technology Ltd Accessing blockchain data from applications
CN111212139A (zh) * 2020-01-02 2020-05-29 支付宝(杭州)信息技术有限公司 对信任节点信息进行更新的方法及装置

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20190041784A (ko) * 2017-10-13 2019-04-23 주식회사 포스링크 멀티클라우드 환경에서 블록체인 기반의 분산동기화 접근 제어 시스템 및 그 방법
CN109254999B (zh) * 2018-09-18 2023-03-07 百度在线网络技术（北京）有限公司 一种区块链的数据处理方法、装置、设备及介质
CN110442579B (zh) * 2019-08-02 2022-06-28 杭州复杂美科技有限公司 一种状态树数据存储方法、同步方法及设备和存储介质

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103701939A (zh) * 2014-01-16 2014-04-02 南通大学 数据交换系统及其方法
CN107317842A (zh) * 2017-05-31 2017-11-03 北京大学深圳研究生院 基于ndn的区块链同步方法和装置
US20190058582A1 (en) * 2017-08-21 2019-02-21 NIIT Technology Ltd Accessing blockchain data from applications
CN108848184A (zh) * 2018-06-29 2018-11-20 北京金山安全软件有限公司 一种基于信任机制的区块链节点同步方法及装置
CN108924223A (zh) * 2018-06-29 2018-11-30 北京金山安全软件有限公司 一种区块链的节点同步方法及装置
CN111212139A (zh) * 2020-01-02 2020-05-29 支付宝(杭州)信息技术有限公司 对信任节点信息进行更新的方法及装置

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115687527A (zh) * 2022-11-09 2023-02-03 呼和浩特市大旗网络有限公司 一种基于区块链大数据的存储系统
CN115687527B (zh) * 2022-11-09 2023-10-10 北京北纬三十度网络科技有限公司 一种基于区块链大数据的存储系统
WO2024159781A1 (zh) * 2023-01-31 2024-08-08 腾讯科技（深圳）有限公司 基于区块链网络的数据处理方法、装置、设备及存储介质

Also Published As

Publication number Publication date
CN111212139A (zh) 2020-05-29

Similar Documents

Publication Publication Date Title
WO2021135857A1 (zh) 对信任节点信息进行更新的方法及装置
WO2020258831A1 (zh) 用于区块链系统中的主节点切换处理的方法及装置
US11032077B2 (en) Blockchain-based transaction method and apparatus, and remitter device
WO2021135757A1 (zh) 用于执行交易正确性验证的方法及装置
US11128522B2 (en) Changing a master node in a blockchain system
US11614994B2 (en) Method, apparatus and electronic device for blockchain-based transaction consensus processing
US11050549B2 (en) Blockchain-based transaction method and apparatus, and remitter device
TWI740378B (zh) 用於進行交易驗證的方法及裝置
WO2021184885A1 (zh) 用于更新区块链节点处的公钥集合的方法及装置
WO2021135744A1 (zh) 用于区块链节点的数据同步方法及装置
US11126458B2 (en) Method, apparatus, and electronic device for resource allocation based on blockchain
US10951417B2 (en) Blockchain-based transaction verification
US11514446B2 (en) Method and apparatus for starting smart contract, electronic device, and storage medium
WO2021135755A1 (zh) 发送针对数据请求的应答消息的方法及装置、区块链系统
US11386426B2 (en) Invoice invalidation method and apparatus based on blockchain, and electronic device
EP3808030B1 (en) Managing blockchain-based centralized ledger systems
WO2021143364A1 (zh) 获取去中心化应用集群中的交易处理状态的方法及装置
WO2021114796A1 (zh) 用于更新多层块链式结构中的信任点的方法及装置
CN110827034B (zh) 用于发起区块链交易的方法及装置
WO2021114926A1 (zh) 用于生成多层块链式结构的方法及装置
CN111162970B (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: 20909429

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: 20909429

Country of ref document: EP

Kind code of ref document: A1