WO2021114796A1

WO2021114796A1 - Method and apparatus for updating trusted point in multi-layer blockchain structure

Info

Publication number: WO2021114796A1
Application number: PCT/CN2020/116042
Authority: WO
Inventors: 俞本权
Original assignee: 支付宝(杭州)信息技术有限公司
Priority date: 2019-12-11
Filing date: 2020-09-18
Publication date: 2021-06-17
Also published as: CN111143381B; CN111143381A

Abstract

A method for updating a trusted point in a multi-layer blockchain structure, the multi-layer blockchain structure comprising a bottom blockchain layer and at least one upper blockchain layer, the blocks of the bottom blockchain layer being generated based on transaction data, and the upper layer blocks of the at least one upper blockchain layer being generated at least partially on the basis of block information of reference blocks in a lower blockchain layer based on the upper blockchain layer, the trusted point indicating a verified bottom layer block with the greatest block height in the bottom blockchain layer, and the method comprising: on the basis of the multi-layer blockchain structure, determining a verification path between the verified bottom layer block indicated by a current trusted point and a target bottom layer block (720); for each block in the verification path, verifying whether the link between said block and the block preceding said block is correct (740); and, when the links between the blocks in the verification path are all correct, updating the target bottom layer block as a trusted point (780).

Description

Method and device for updating trust points in multi-layer block chain structure

Technical field

The embodiments of this specification relate to the field of blockchain technology, in particular, to a method and device for updating trust points in a multi-layer blockchain structure.

Background technique

The blockchain network 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. In addition, in a blockchain-like system, centralized devices can also store data in a manner similar to blockchain storage (which can be regarded as centralized blockchain storage). In this specification, systems that store data in a block-chain manner, such as blockchain systems and quasi-blockchain systems, are called block-chain systems.

In a block chain system, the block chain data is very large, and over time, the amount of data will continue to grow. In the traditional block chain structure, if you want to synchronize, verify, or query the data stored on the block chain, the amount of data access and calculation is huge. Therefore, there is an urgent need for a technology that can improve the operation efficiency of block chain data.

Summary of the invention

In view of the foregoing, the embodiments of this specification provide a method and device for updating trust points in a multi-layer block chain structure.

According to an aspect of the embodiments of the present specification, a method for updating trust points in a multi-layer block chain structure is provided. The multi-layer block chain structure includes a bottom block chain layer and at least one upper block chain layer. The blocks of the underlying block chain layer are generated based on transaction data, and the upper blocks of the at least one upper block chain layer are based at least in part on the benchmarks in the lower block chain layer of the upper block chain layer Generated by the block information of the block, the trust point indicates the verified bottom block with the largest block height in the bottom block chain layer, and the method includes: determining the current block based on the multi-layer block chain structure The verification path between the verified underlying block and the target underlying block indicated by the trust point; for each block in the verification path, the link between the block and the previous block of the block is verified Whether it is correct; and when the link between each block in the verification path is correct, update the target bottom block as a trust point.

Optionally, in an example, based on the multi-layer block chain structure, determining the verification path between the verified underlying block and the target underlying block indicated by the current trust point may include: When there are at least two bottom-level reference blocks between the block and the verified bottom-level block, the verification path is determined via at least one upper-level block chain layer.

Optionally, in an example, the number of first blocks between two adjacent reference blocks in each block chain layer in the multi-layer block chain structure may be equal, and the verification path traverses The number of upper block chain layers may not exceed the first block number.

Optionally, in an example, based on the multi-layer block chain structure, determining the verification path between the verified underlying block indicated by the current trust point and the target underlying block may include: based on the first block number And the second number of blocks to determine the verification path, the first number of blocks is the number of blocks between two adjacent reference blocks of each block chain layer, and the second number of blocks is the number of blocks The number of bottom-layer blocks between the target bottom-layer block and the verified bottom-layer block.

Optionally, in an example, the first number of blocks between two adjacent reference blocks of each block chain layer may be determined based on block index information, and the block index information indicates each The index of the reference block and the corresponding upper block.

Optionally, in an example, based on the multi-layer block chain structure, determining the verification path between the verified underlying block indicated by the current trust point and the target underlying block may include: determining based on block index information For the verification path, the block index information indicates the index between each reference block and the corresponding upper block.

Optionally, in an example, the method may further include: verifying whether the target underlying block is correct. When the links between the blocks in the verification path are correct, updating the target underlying block as a trust point may include: when the links between the blocks in the verification path are correct And when the target block is determined to be correct, the target bottom block is updated as a trust point.

Optionally, in an example, verifying whether the target underlying block is correct may include: obtaining multiple target underlying block information of the target underlying block from multiple full nodes in the blockchain system; and When there is no less than a statutory number of consistent target bottom-layer block information in the multiple target bottom-layer block information, it is determined that the target bottom-layer block is correct.

Optionally, in an example, each block in the verification path includes a first hash value generated at least based on the block information of the previous block, and the block is verified against the previous block of the block. Whether the link between the blocks is correct may include: performing a hash operation based at least in part on the block information of the previous block obtained locally to obtain a second hash value; and based on the second hash value The consistency with the first hash value verifies whether the link between the block and the previous block is correct.

Optionally, in an example, the block height of the target bottom layer block may not be less than the bottom layer block to be verified where the transaction to be verified is to be verified by SPV.

According to another aspect of the embodiments of the present specification, there is also provided an apparatus for updating trust points in a multi-layer block chain structure, the multi-layer block chain structure including a bottom block chain layer and at least one upper block chain layer The blocks of the underlying block chain layer are generated based on transaction data, and the upper blocks of the at least one upper block chain layer are based at least in part on the blocks in the lower block chain layer of the upper block chain layer. Generated by the block information of the reference block, the trust point indicates the verified bottom block with the largest block height in the bottom block chain layer, and the device includes: a verification path determination unit based on the multi-layer block The chain structure determines the verification path between the verified underlying block and the target underlying block indicated by the current trust point; the link verification unit verifies the block and the area for each block in the verification path Whether the link between the previous block of the block is correct; and the trust point update unit, when the link between each block in the verification path is correct, update the target underlying block to the trust point .

Optionally, in an example, the verification path determination unit may determine via at least one upper-level block chain layer when there are at least two bottom-level reference blocks between the target bottom-level block and the verified bottom-level block. The verification path.

Optionally, in an example, the number of first blocks between two adjacent reference blocks in each block chain layer may be equal, and the number of upper block chain layers passed by the verification path may not be the same. Exceeds the number of first blocks.

Optionally, in an example, the verification path determination unit may determine the verification path based on the first block number and the second block number, where the first block number is two adjacent blocks of each block chain layer. The number of blocks between two reference blocks, and the second number of blocks is the number of bottom blocks between the target bottom block and the verified bottom block.

Optionally, in an example, the verification path determination unit may determine the verification path based on block index information, where the block index information indicates an index between each reference block and a corresponding upper-layer block.

Optionally, in an example, the device may further include: a target bottom-level block verification unit, which verifies whether the target bottom-level block is correct; When the links between the two are correct and the target block is verified as correct, the target bottom block is updated as a trust point.

Optionally, in an example, the target bottom-level block verification unit may include: a target bottom-level block information acquisition module, which obtains multiple target bottom-level blocks from multiple full nodes in the blockchain system Target bottom-level block information; and a target bottom-level block verification module for determining that the target bottom-level block is correct when there is no less than a legal number of consistent target bottom-level block information in the multiple target bottom-level block information of.

Optionally, in an example, each block in the verification path includes a first hash value generated at least based on block information of the previous block, and the path verification verification unit may include: hash An arithmetic module, which performs a hash operation based at least in part on the block information of the previous block obtained locally to obtain a second hash value; a link verification module, which is based on the second hash value and the first The consistency between a hash value verifies whether the link between the block and the previous block is correct.

According to another aspect of the embodiments of this specification, there is also provided 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.

According to another aspect of the embodiments of the present specification, there is also provided a non-transitory machine-readable storage medium, which stores executable instructions, which when executed cause the machine to execute the method as described above.

Using the method and device of the embodiment of the present specification, when there is a reference block that triggers the generation condition of the upper block chain layer, the corresponding upper zone of the upper block chain layer is generated based at least in part on the block information of the reference block Block, which can generate a multi-layer block chain structure. Using the multi-layer block chain structure, when performing related operations on the data in the block chain structure, it is not necessary to visit each block of the underlying block chain layer one by one, which can reduce the amount of data access and the amount of calculation to improve the operation effectiveness.

Description of the drawings

By referring to the following drawings, a further understanding of the nature and advantages of the contents of the embodiments of this specification can be achieved. In the drawings, similar components or features may have the same reference signs. The accompanying drawings are used to provide a further understanding of the embodiments of the present invention, and constitute a part of the specification. Together with the following specific implementations, they are used to explain the embodiments of the embodiments of the specification, but do not constitute an example of the embodiments of the specification. limit. In the attached picture:

FIG. 1 shows a schematic diagram of an example of an environment that can be used to perform a method for generating a multi-layer block chain structure and a method for updating trust points in a multi-layer block chain structure 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 generating a multi-layer block chain structure and the method for updating trust points in the multi-layer block chain structure according to an embodiment of the present specification;

Fig. 3 is a flowchart of a method for generating a multi-layer block chain structure according to an embodiment of the present specification;

Fig. 4 is a schematic diagram of a multi-layer block chain structure according to an embodiment of the present specification;

5A is a flowchart of a reference block determination process in a method for generating a multi-layer block chain structure according to an embodiment of the present specification;

FIG. 5B is an example flowchart of the reference block determination process in the method for generating a multi-layer block chain structure according to an embodiment of the present specification;

6A is another example flowchart of the reference block determination process in the method for generating a multi-layer block chain structure according to an embodiment of the present specification;

6B is another example flowchart of the reference block determination process in the method for generating a multi-layer block chain structure according to an embodiment of the present specification;

FIG. 7 is a flowchart of a method for updating trust points in a multi-layer block chain structure according to an embodiment of the present specification;

FIG. 8 is a flowchart of a link verification process in a method for updating a trust point in a multi-layer block chain structure according to an embodiment of the present specification;

FIG. 9 is a flowchart of a method for updating trust points in a multi-layer block chain structure according to another embodiment of the present specification;

FIG. 10 is a flowchart of a target underlying block verification process in a method for updating trust points in a multi-layer block chain structure according to an embodiment of the present specification;

FIG. 11 is a flowchart of a method for performing SPV verification on a transaction to be verified according to an embodiment of the present specification;

FIG. 12 is a structural block diagram of a device for generating a multi-layer block chain structure according to an embodiment of the present specification;

FIG. 13 is a structural block diagram of an apparatus for updating trust points in a multi-layer block chain structure according to an embodiment of the present specification;

FIG. 14 is a structural block diagram of a link verification unit in the device for updating trust points in a multi-layer block chain structure shown in FIG. 13;

FIG. 15 is a structural block diagram of a target bottom-level block verification unit in the device for updating trust points in a multi-layer block chain structure shown in FIG. 13; and

Fig. 16 is a structural block diagram of a computing device for implementing a method for generating a multi-layer block chain structure or a method for updating a trust point in a multi-layer block chain structure according to an embodiment of the present specification.

Detailed ways

The subject described herein will be discussed below with reference to example embodiments. It should be understood that the discussion of these embodiments is only to enable those skilled in the art to better understand and realize the subject described herein, and is not to limit the scope of protection, applicability, or examples set forth in the claims. The function and arrangement of the discussed elements can be changed without departing from the protection scope of the content of the embodiments of this specification. Various examples can omit, substitute, or add various procedures or components as needed. In addition, features described with respect to some examples can also be combined in other examples.

As used herein, 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.

The method and device for generating a blockchain with a multi-layer structure and the method and device for updating trust points in the blockchain of the embodiments of the present specification will now be described with reference to the accompanying drawings.

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. When a hash value claims to be a transaction stored in the Merkle tree, it can be quickly verified by judging whether the hash value is consistent with the structure of 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. As mentioned above, the blockchain network can include a public blockchain network, a private blockchain network, or a consortium blockchain network.

In the public blockchain network, the consensus process is controlled by the nodes of the consensus network. For example, in a public blockchain network, there may be thousands of entities in collaborative processing, and each entity operates at least one node in the public blockchain network. Therefore, the public blockchain network can be considered as a public network of participating entities. In some examples, 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. In addition, the term "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. In order to reach a consensus (for example, agree to add a block to the blockchain), a consensus agreement is implemented in the public blockchain network. Examples of consensus protocols include but are not limited to: proof-of-work (POW), proof-of-stake (POS), and proof-of-authority (POA). In the embodiments of this specification, 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). In 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. In the alliance blockchain network, the consensus process is controlled by authorized nodes. For example, 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. In some examples, each participating entity (node) must sign each block in sequence and add the block to the blockchain. In some examples, 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.

In the embodiments of this specification, the embodiments of the embodiments of this specification are described in detail with reference to the alliance blockchain network. However, it is expected that the embodiments of the embodiments of the present specification can be implemented in any suitable blockchain network.

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 them to the same ledger. The consensus model aims to solve the Byzantine problem. In 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 an environment 100 that can be used to execute a method for generating a blockchain with a multi-layer structure and a method for updating trust points in a multi-layer block chain structure according to an embodiment of the present specification. Schematic of the example. In some examples, the environment 100 enables entities to participate in the blockchain network 102. As shown in FIG. 1, the environment 100 includes a network 104, and computing devices/

systems

106, 108. In some examples, the network 104 may include a local area network (LAN), a wide area network (WAN), the Internet, or a combination thereof, and connect a website, a user device (for example, a computing device), and a back-end system. In some examples, the network 104 may be accessed through a wired and/or wireless communication link. In some examples, 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. Generally, the network 104 represents one or more communication networks. In some cases, the computing devices/

systems

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

system

106, 108 may be a separate cloud computing system, including interconnection through the network 104 Multiple computers and used as a distributed processing system.

In the illustrated example, 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. In some examples, one or more computer-implemented services for interacting with the blockchain network 102 may be installed on the computing device/

system

106, 108. For example, 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) . In the example of FIG. 1, the blockchain network 102 is represented as a peer-to-peer network of nodes, and the computing devices/

systems

106, 108 serve as the nodes of the first entity and the second entity participating in the blockchain network 102, respectively.

FIG. 2 shows an example of a system architecture 200 that executes the method for generating a blockchain with a multi-layer structure and the method for updating trust points in a multi-layer block chain structure according to an embodiment of the present specification Schematic diagram. 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) participates in the blockchain network 212 provided as a peer-to-peer network. The blockchain network 212 includes a plurality of nodes 214, wherein at least some of the nodes 214 record information in the blockchain 216, and the recorded information cannot be changed. Although 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.

In the example shown, 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. As used herein, 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. In the example shown in FIG. 2, the participant corresponds to each node 214. However, one participant can operate multiple nodes 214 within the blockchain network 212, and/or multiple participants can share a single node 214. In some examples, 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 The chain network 212 communicates.

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. In the embodiments of this specification, 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 (for example, assets, products, services, currency, etc.). Transaction data is stored immutably in the blockchain.

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.

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 transaction change 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. During the mining process, 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. Finally, 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 within the blockchain network. The above process is a POW consensus protocol.

In the example provided in Figure 2, 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.

In some blockchain networks, 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. Examples of 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). In 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. For example, refer to Figure 1 again. 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.

Although the block chain scenarios that can be applied to the embodiments of this specification are described above, the embodiments of this specification can also be applied to other block chain scenarios. For example, the embodiments of this specification can also be applied to a blockchain-like system. In the quasi-blockchain system, data can be stored in the same block-chain structure. Unlike the blockchain system, in the quasi-blockchain system, the block-chain data stored in the block-chain structure does not need After consensus processing.

In the embodiments described below, the "bottom block chain layer" refers to the lowermost block chain layer of the multi-layer block chain structure, and the "upper block chain layer" refers to the block except the bottom layer in the multi-layer structure. For each block chain layer other than the chain layer, the "block chain layer" includes the bottom block chain layer and each upper block chain layer. "Bottom block" refers to the block in the bottom block chain layer, and "upper block" refers to the block in each upper block chain layer. "Adjacent upper block chain layer" refers to the adjacent "upper layer block. "Lower layer" refers to the "next layer", for example, "lower block" refers to the next layer of a block chain layer. Blocks in the chain layer. The "base block" refers to the block in each block chain layer that meets the predetermined conditions and triggers the generation of the corresponding upper block. The "previous benchmark block" refers to the block in the same block chain layer. The previous reference block in the "reference block", for example, the "reference block" and "previous reference block" in the "previous reference block of the reference block" refer to adjacent reference blocks in the same block chain layer "Previous block" or "next block" refers to the previous block or the next block of a block in the verification path mentioned in this manual, and the block is or The latter block may be located in the same block chain layer or in a different block chain layer. "Block height" refers to the position of the block in the corresponding block chain layer. For example, if each block chain layer is defined The block height of the first block of the layer is 0, then the block height of the third block of the block chain layer can be 2. Similarly, if the block height of the first block of each block chain layer is defined If the height is 1, the block height of the third block of the block chain layer can be 3. The block height can be determined in any orderly manner, as long as each block can be located in the corresponding block chain layer based on the block height The location is fine.

Fig. 3 is a flowchart of a method for generating a multi-layer block chain structure according to an embodiment of the present specification.

As shown in FIG. 3, at block 320, the bottom block of the bottom block chain layer of the multi-layer block chain structure is generated based on the transaction data. The underlying block of the underlying block chain layer can be generated by any method that generates a block chain structure. For example, it can be generated using the block chain generation method described above with reference to Figures 1 and 2, or using blocks such as Bitcoin and Ethereum. Chain generation method to generate. Each transaction data can be packaged into the underlying block after the consensus processing of each blockchain node and the smart contract execution processing. In a blockchain-like system, the transaction data on the chain can be processed without consensus.

In block 340, it is determined whether there is a reference block in the underlying block chain layer that triggers the generation condition of the upper block chain layer. The reference block in each block chain layer is a block corresponding to each block in the upper block chain layer. For example, the reference block can be determined based on whether the number of blocks between each block in the underlying block chain layer and the previous reference block reaches a specified number, and it can also be based on the number of blocks in the underlying block chain layer. Whether the time interval between the generation time and the generation time of the previous reference block reaches the specified time interval to determine the reference block. In this specification, when determining the number of blocks between a block and another block, the other block is included.

When the reference block is determined, in block 360, in response to the presence of a reference block in the underlying block chain layer that triggers the generation condition of the upper block chain layer, the upper block is generated based at least in part on the block information of the reference block The corresponding upper block of the chain layer. The multi-layer block chain structure may have an upper block chain layer, and may also include a plurality of upper block chain layers. When a multi-layer block chain structure has multiple upper block chain layers, after the bottom block chain layer is generated based on the bottom block chain layer, the same way can also be used for each upper block chain layer, successively based on The upper block chain layer generates an adjacent upper block chain layer. Specifically, for each upper block chain layer, it can be determined whether the upper block chain layer has a reference block that triggers the generation condition of the upper block chain layer. When there is a reference block that triggers the generation condition of the upper block chain layer, the adjacent upper block chain layer of the upper block chain layer is generated based at least in part on the block information of the reference block. The following describes the generation process of the multi-layer block chain structure with reference to FIG. 4.

Fig. 4 is a schematic diagram of a multi-layer block chain structure according to an embodiment of the present specification. Four block chain layers are schematically shown in FIG. 4, but the embodiment of this specification does not limit the number of block chain layers. In Figure 4, B _ij represents the j-th block of the i-th block chain layer, for example, B ₁₁ represents the first block of the first block chain layer (ie, the underlying block chain layer), and B ₂₂ Represents the second block of the second block chain layer (that is, the first upper block chain layer).

In Figure 4, B ₁₁ is the genesis block, which refers to the first block of the underlying blockchain layer. As the transaction data processed by the block chain system increases, blocks B ₁₂ to B _{111 of the} underlying block chain layer are sequentially generated. Each upper block chain layer is generated based on the lower block chain layer of the upper block chain layer. For example, the first upper block chain layer is generated based on the bottom block chain layer, and the second upper block chain layer is generated based on the first upper block chain layer. The first block of each upper block chain layer can be called a header block (for example, header blocks B ₂₁ , B ₃₁ , B ₄₁ ).

In an example, the first block of each blockchain layer can be determined as the first reference block of the blockchain layer (for example, blocks B ₁₁ , B ₂₁ , B ₃₁ ), and then based on the reference block The block generates the header block of the upper block chain layer of the block chain layer (for example, blocks B ₂₁ , B ₃₁ , B ₄₁ ). For each upper block chain layer, the header block of the upper block chain layer may include the hash value of the first block of the lower block chain layer of the upper block chain layer. The header block of each upper blockchain layer may also be generated based on the genesis block. For example, the header block of each upper blockchain layer may include the hash value of the genesis block. In another example, when the header block of each upper block chain layer is generated, the genesis block can be copied to generate the header block of the upper block chain layer. By generating each header block based on the genesis block, it is possible to quickly locate from the genesis block to each upper block chain layer.

Although Figure 4 shows a situation where the header blocks of each upper block chain layer correspond to the genesis block, in another example, for each block chain layer, the block chain layer can be compared with the block chain layer. The number of blocks between the first block reaches the specified number of blocks or the time interval between the generation time and the generation time of the first block reaches the specified time interval is determined as the first block chain layer. A benchmark block. For example, the example shown in FIG. 4 can be simply modified as follows, that is, each upper block chain layer may not include the blocks B ₂₁ , B ₃₁ , and B ₄₁ shown in FIG. B ₂₂ , B ₃₂ , and B _{42 are} used as the first block. As an example, the block B ₁₃ of the bottom block chain layer can be determined as the first reference block of the bottom block chain layer, and then the first upper zone of the first upper block chain layer _{can be generated based on B 13} Piece. In this example, the first upper block of each upper block chain layer can include the hash value of the genesis block to quickly locate from the bottom block chain layer to each upper block chain layer, or from each The upper block chain layer is positioned to the bottom block chain layer.

After determining the first reference block of each blockchain layer, the number of blocks from the previous reference block can reach the specified number or the interval between the generation time and the generation time of the previous reference block can reach Specify the time interval as the trigger condition to determine other reference blocks of each block chain layer. For example, the process described below with reference to FIG. 5A to FIG. 6B may be used to determine each reference block of each block chain layer, and generate an upper layer block corresponding to the determined reference block. The generation of each block chain layer can be executed in parallel in real time, or after each block of the underlying block chain layer is generated, according to the system's computing resource occupancy, each upper block chain layer generated at the right time .

5A and 5B show an example in which the upper block chain layer is generated asynchronously with the lower block chain layer. After each block in each block chain layer is generated, at an appropriate time (such as when system resources are abundant), traverse the blocks in the block chain layer that have not performed the benchmark block determination process, that is, query one by one Each block is used to determine whether the currently queried block is a reference block that triggers the generation conditions of the upper block chain layer. After the reference block is determined, the corresponding upper block adjacent to the upper block chain layer can be generated. For example, after each low-level block is generated, each generated low-level block may be traversed at a suitable time period to determine the reference block that triggers the generation of the upper-level block in the first upper-level block chain layer.

Fig. 5A is a flowchart of a reference block determination process in a method for generating a multi-layer block chain structure according to an embodiment of the present specification.

As shown in FIG. 5A, in block 5A02, for each block chain layer, the number of blocks between the currently queried block and the previous reference block of the block chain layer is determined. Then in block 5A04, it is determined whether the number of blocks between the currently queried block and the previous reference block reaches the specified number. In the embodiment of this specification, the block between a block and another block includes the other block. Accordingly, when referring to the number of blocks between a block and another block, the The other block is included. For example, the block between _{B 11} and B ₁₃ _{includes B 12} and B ₁₃ , and accordingly, the number of blocks between _{B 11} and B _{13 is 2.}

If the number of blocks between the currently queried block and the previous reference block reaches the specified number, in block 5A06, the currently queried block is determined as the reference block. The number of blocks between the reference blocks of each block chain layer can be set. For example, for the example in FIG. 4, the number of blocks between a reference block and the previous reference block can be 2. If the number of blocks between the currently queried block and the previous reference block reaches the set specified number, the currently queried block can be determined as the reference block.

If the number of blocks between the currently queried block and the previous reference block does not reach the specified number, in block 5A08, the next block of the blockchain layer is regarded as the current queried block, and the above is executed again process.

FIG. 5B is another example flowchart of the reference block determination process in the method for generating a multi-layer block chain structure according to an embodiment of the present specification.

As shown in Fig. 5B, in block 5B02, for each block chain layer, the time interval between the current inquired block of the block chain layer and the generation time of the previous reference block is determined. The generation time of each block can be determined based on the timestamp of the block, for example. Then in block 5B04, it is judged whether the determined time interval reaches the specified time interval.

If the determined time interval reaches the specified time interval, in block 5B06, the currently queried block is determined as the reference block. If the determined time interval does not reach the specified time interval, in block 5B08, the next block of the block chain layer is regarded as the currently queried block, and the above process is executed again.

6A and 6B show an example in which the upper block chain layer is generated in synchronization with the lower block chain layer. It is possible to monitor the blocks in each block chain layer. When a new block is added to each block chain layer, it is determined whether the new block is a reference block that triggers the generation conditions of the upper block chain layer. For full nodes, the newly added block can be a newly generated block, and for light nodes, the newly added block can also be a block obtained from the full node. Each block at the lightweight node may only include the block header. Lightweight nodes can locally generate upper-level block chain layers and upper-level blocks, and can also obtain upper-level block chain layers from all nodes.

Fig. 6A is another example flowchart of a reference block determination process in a method for generating a multi-layer block chain structure according to an embodiment of the present specification.

As shown in Fig. 6A, in blocks 6A02 and 6A04, each block chain layer is monitored to see if there are new blocks added.

When a new block is added to a certain block chain layer, in block 6A08, the number of blocks between the new block and the previous reference block is determined. Then, in block 6A10, it is judged whether the determined number of blocks has reached the specified number.

If the determined number of blocks reaches the specified number, in block 6A12, the new block is the reference block of the corresponding block chain layer. If the determined number of blocks does not reach the specified number, then continue to monitor the block chain layer.

FIG. 6B is another example flowchart of the reference block determination process in the method for generating a multi-layer block chain structure according to an embodiment of the present specification.

As shown in Figure 6B, in blocks 6B02 and 6B04, each block chain layer is monitored to see if there is a new block generated.

When a new block is generated in a certain block chain layer, in block 6B08, the time interval between the generation time of the new block and the generation time of the previous reference block is determined. Then, in block 6B10, it is judged whether the determined time interval has reached a specified number.

If the determined time interval reaches the specified number, in block 6B12, the new block is the reference block of the corresponding block chain layer. If the determined time interval does not reach the specified number, then continue to monitor the block chain layer.

Taking Figure 4 as an example, in the multi-layer block chain structure, the reference block of the bottom block chain layer is B ₁₁ , B ₁₃ , B _15, etc., and the reference block of the first upper block chain layer is B ₂₁ , B ₂₃ , B _25, etc., the reference block of the second upper block chain layer is B ₃₁ , B ₃₃ and so on.

It should be noted that, in the embodiment of this specification, when the reference block is determined based on whether the number of blocks between the previous reference block and the previous reference block reaches the specified number, two adjacent reference blocks of the same block chain layer The number of blocks before the block can be the same or different, and the designated number corresponding to each block chain layer can be the same or different. In addition, when the reference block is determined based on the time interval between the generation times, the generation time interval before two adjacent reference blocks of the same block chain layer may be the same or different. Each block chain layer corresponds to The specified time interval can be the same or different. In an example, the specified number or specified time interval corresponding to each reference block of each block chain layer can be made the same, or for each block chain layer, each reference block of the block chain layer can be made to correspond to The specified number or specified time interval are the same. When the designated number or designated time interval corresponding to each reference block of the block chain layer is the same, the designated number or designated time interval corresponding to each block chain layer can also be determined based on a predetermined rule. For example, the number of blocks between adjacent reference blocks of each block chain layer can be increased in an arithmetic sequence. As a result, based on the specified number or specified time interval corresponding to each reference block, rapid positioning between each block chain layer can be realized.

After the reference block is determined, the upper layer of the block chain layer can be generated based on the block information of at least some of the blocks from the first block of the block chain layer to the reference block The corresponding block of the block chain layer. For the underlying block chain layer, the first block is the genesis block, and for each upper block chain layer, the first block is the head block of the corresponding upper block chain layer. Block information can be the hash value of each block or the content of the block, or part of the content of the block (such as the hash value and timestamp of the block or the hash of the parent block of the block) Value and the hash value of the block). In this way, each block chain layer can be linked to the corresponding lower block chain layer, and link verification can be performed based on the corresponding block information.

In an example, the generated upper-level block may include the hash value of the reference block. Referring to FIG. 4, the block B _{22 of the} first upper block chaining layer may include the hash value of the reference block B _13. In another example, for each block chain layer, the block content of all blocks from the first block of the block chain layer to the reference block can be hashed to obtain the hash value, and the The upper block corresponding to the reference block includes the hash value. Referring to FIG. 4, when generating block B ₂₃ , the block content of all blocks from B ₁₁ to B ₁₅ may be hashed to obtain a hash value, and then block B _{23 may} include the hash value. In another example, for each block chain layer, the hash value of all blocks from the first block of the block chain layer to the reference block can be hashed to obtain the hash value, and The upper block corresponding to the reference block includes the hash value. As shown in the figure, _{the hash value of all blocks from B 11} to B ₁₅ may be hashed to obtain a hash value, and then block B _{23 may} include the hash value. In another example, for each block chain layer, the first block of the block chain layer and the block content or hash value of the reference block can also be hashed to obtain the hash value, and use The block corresponding to the upper block chain layer of the reference block includes the hash value. As shown in Figure 4, for the reference block B ₁₅ , the block content or hash value of B ₁₁ and B ₁₅ can be hashed to obtain the hash value, and then the upper block generated by _{B 15} B ₂₃ includes the hash value. In addition, the upper-level block generated corresponding to the corresponding reference block may also include multiple hash values determined using the above example.

In addition, the blocks of the upper block chain layer generated by the respective reference blocks of each block chain layer may also have block attributes with a known block chain structure. For example, the upper block of each upper block chain layer may include the hash value of the previous upper block (parent block) of the upper block.

In another example, the block index information of the reference block and the corresponding upper block can also be stored. Block index information helps to locate between each block chain layer. The block index information may be, for example, the block height of the reference block or the upper block corresponding to the reference block. The block index information can be included in the reference block. The reference block can include fields that do not participate in the hash value operation of the reference block. After the corresponding upper block is generated, the block height of the upper block can be Write this field. The block index information can be included in the upper block corresponding to the reference block. For example, the block header of the upper layer block may include a reference block block height field, and when the corresponding upper layer block is generated, the block height of the corresponding reference block is written into the reference block block height field. The block index information may also be included in the next block of the upper block corresponding to the reference block. When generating the next block of the upper block, the block height of the reference block of the upper block may be written into the block header of the next block. In another example, an index database can also be set. When the upper block is generated corresponding to the reference block, the block index information of the upper block and the reference block can be stored in the index database.

Hereinafter, the application of the multi-layer block chain structure generated by the embodiment of this specification will be explained with reference to FIGS. 7 to 11. The following embodiments can be used for lightweight nodes in a blockchain system.

Fig. 7 is a flowchart of a method for updating trust points in a multi-layer block chain structure according to an embodiment of the present specification. The trust point indicates the verified bottom block with the largest block height in the bottom block chain layer. The trust point means that among the underlying blocks stored at the node, all the underlying blocks from the genesis block to the underlying blocks indicated by the trust point have passed verification, that is, these underlying blocks are trusted blocks. The initial value of the trust point can be the genesis block. For example, for a lightweight node that has never performed block verification, the trust point points to the genesis block. The trust point can be stored at the lightweight node. After performing a batch of block verification, the lightweight node can update the trust point to point to the highest verified underlying block of the current block, for example, in the trust point field Store the block height or hash value of the verified underlying block with the largest current block height. As an application of the trust point, when the lightweight node performs SPV verification for the transaction to be verified, if the underlying block of the transaction to be verified is located before the trust point (that is, the underlying block is a verified and trusted underlying block ), the existence proof of the transaction to be verified can be performed, and after the verification of the existence proof is passed, it is determined that the transaction to be verified has been executed correctly.

As shown in FIG. 7, at block 720, based on the multi-layer block chain structure, the verification path between the verified underlying block and the target underlying block indicated by the current trust point is determined. Lightweight nodes can obtain each block chain layer block between the verified block indicated by the current trust point and the target underlying block from the full node when the trust point needs to be updated, and add the obtained block to In each local block chain layer. Then, the lightweight node can determine the verification path based on the locally stored multi-layer block chain structure. Referring to Figure 4, the current trust point can point to the block B _{14 of the} underlying blockchain layer. The target bottom layer block can be, for example, B ₁₁₂ in FIG. 4.

In one example, the trust point can be updated when the SPV verification of the transaction to be verified is performed, and the target underlying block can be determined based on the underlying block to be verified where the transaction to be verified is located. Fig. 8 is a flowchart of a method for performing SPV verification on a transaction to be verified according to an embodiment of the present specification.

As shown in Fig. 8, at block 802, the underlying block to be verified where the transaction to be verified is located is determined. When a lightweight node wants to know whether a transaction is executed correctly, it can obtain the underlying block of the transaction from the full node. The full node can send the block height of the underlying block of the exchange to the light node. Then, the lightweight node can perform SPV verification on the transaction. SPV verification can include correctness verification and existence verification (or called existence proof). Correctness verification can be performed by verifying the integrity of the link from the genesis block to the underlying block to be verified, and is used to prove that the transaction to be verified is correct. Existence verification is used to prove that the transaction to be verified does exist in the block to be verified, and can be performed based on any existence proof method. For example, it is possible to obtain the query path of the transaction to be verified in the MPT tree based on the MPT tree, and to verify whether the transaction tree root hash is consistent with the transaction tree root hash in the block header based on the obtained data nodes of each MPT tree in the query path When the two are consistent, it can be determined that the transaction to be verified does exist in the underlying block to be verified.

After the bottom layer block to be verified is determined, in block 804, it is determined whether the bottom layer block to be verified is located before the trust point. That is, it is determined whether the underlying block to be verified is a trusted underlying block. It can be determined by comparing the block height of the block to be verified with the block height of the verified underlying block pointed to by the trust point to determine whether the transaction to be verified is located before the trust point.

When the underlying block to be verified is located before the trust point, it indicates that the link from the genesis block to the underlying block to be verified where the exchange to be verified is located is correct. Therefore, at block 808, the existence proof of the transaction to be verified can be performed, and at block 810, it is determined whether the existence proof is passed. When the underlying block to be verified is not before the trust point, in block 806, the trust point update method described in the embodiment of this specification can be used to update the trust point to a target underlying block whose block height is not less than the underlying block to be verified . At this time, any underlying block whose block height is not less than the underlying block where the transaction to be verified is located can be used as the target underlying block. After the trust point is updated, at block 808, the existence proof of the transaction to be verified can be performed.

If the proof of existence is passed, it can be determined in block 812 that the transaction to be verified has been executed correctly. If the proof of existence is not passed, it can be determined in block 814 that the transaction to be verified was not executed correctly.

The verification path refers to the path from the current trust point to the target underlying block. The verification path can go through any blockchain layer. For example, as shown in Figure 4, the verification path from the current trust point TP to the target underlying block B ₁₁₂ _{can be B 15} → B ₂₃ → B ₃₂ → B ₃₃ → B ₂₅ → B ₂₆ → B ₁₁₁ → B ₁₁₂ .

The verification path can be determined only via the underlying block chain layer, or via at least one upper block chain layer. Since there is at least one block between two adjacent reference blocks of each block chain layer, the upper block of the block chain layer is equivalent to "skipping" the spaced block. Thus, when the verification path is determined via at least one upper block chain layer, the number of blocks in the verification path can be reduced, thereby improving the verification efficiency. The shortest path (that is, the path with the least number of blocks) can be selected as the verification path from all the paths between the verified bottom-level block pointed to by the current trust point and the target bottom-level block.

When the verification path is determined via the upper block chain layer, there is a path loss when rising from each block chain layer to the upper block chain layer or descending from the upper block chain layer to the lower block chain layer. That is, due to the ascent or descent between the blockchain layers, the number of blocks through which the path passes may increase. Therefore, when the number of blocks between the verified bottom-layer block indicated by the current trust point and the target bottom-layer block is less, if the upper-layer block chain layer is passed, the verification path may be more than that of only the bottom-layer block chain layer. The determined verification path must be long. Therefore, in an example, when there are at least two underlying reference blocks before the verified underlying block and the target underlying block indicated by the current trust point, the verification path can be determined via at least one upper block chain layer. In another example, the number of underlying blocks between the determined target underlying block and the verified underlying block indicated by the current trust point may be greater than the first predetermined number. Therefore, the number of bottom-layer blocks between the target bottom-layer block and the verified bottom-layer block pointed to by the current trust point is large enough, so that the verification path can be determined through at least one upper-level block chain layer each time the trust point is updated. . When the number of underlying blocks between the target underlying block and the verified underlying block indicated by the current trust point is greater than the second predetermined number (the second predetermined number is not less than the first predetermined number), multiple upper blockchains can be used The formula layer determines the verification path, so that the number of blocks included in the verification path can be reduced as much as possible to improve the verification efficiency.

The verification path can be determined based on the first block number and the second block number. The first block number is the number of blocks between two adjacent reference blocks of each block chain layer, and the second block number is The number of bottom-level blocks between the target bottom-level block and the verified bottom-level block. In an example, the same number of blocks may exist between two adjacent reference blocks in each block chain layer, that is, the number of first blocks between two adjacent reference blocks is the same. In this example, assuming that the number of first blocks is N, the number of underlying blocks existing between two adjacent blocks in the L-th ^{block chain layer is N L-1.} ^{For example, referring to FIG. 4, there are 2 2-1} bottom-level blocks between adjacent two blocks in the second block-chain layer (ie, the first upper-level block-chain layer). The ascending point of the blockchain layer through which the verification path passes can be determined based on the first block number and the second block number. For each block passed by the verification path, if the next block of the block is adjacent The upper block chain layer is called the rising point. In the verification path, the sequence number of the block corresponding to the rising point of the L-th block-chain layer in the L-th block-chain layer is (% represents the remainder operation):

X+[N-(X-1)%N]%N,

Among them, B _LX is the first block of the L-th blockchain layer in the verification path. For example, in the verification path shown in Figure 4, for the second block chain layer (that is, the first upper block chain layer), the rising point is 3+[2-(3-1)%2]%2 , The calculation result is 3, that is, the value of X is 3, so the third block B ₂₃ in the second block chain layer is the rising point.

The drop point of each block chain layer passed by the verification path can also be determined based on the first block number and the second block number. For each block passed by the verification path, if the next block of the block is a block of the lower block chain layer, the block is called a drop point. Assume that the verified block indicated by the current trust point is B _1j (the jth block of the underlying blockchain layer), and the target bottom block is B _1k (the kth block of the underlying blockchain layer). Then the sequence number of the block corresponding to the descending point in the L-th block chain layer is:

(kk%N)/N ^L-1

If a block meets the conditions of the rising point and the falling point at the same time, the block is determined as the falling point (such as B ₃₃ ).

After determining the ascending point and descending point in each block chain layer, the blocks between the ascending point and the falling point in the block chain layer are all blocks in the verification path. In the example shown in Fig. 4, the determined rising points are B ₁₅ and B ₂₃ respectively, and the falling points are B ₃₃ and B _{26 respectively} .

When the number of first blocks between two adjacent blocks in each block chain layer is equal, in order to make the determined verification path be the one between the verified underlying block pointed to by the current trust point and the target underlying block The shortest path between the two can make the maximum number of blockchain layers passed by not exceeding the number of first blocks. For example, taking FIG. 4 as an example, the verification path B ₁₅ → B ₂₃ → B ₃₂ → B ₃₃ → B ₂₅ → B ₂₆ → B ₁₁₁ → B ₁₁₂ determined by the above embodiment includes 8 blocks. If the maximum number of blockchain layers passed by the verification path does not exceed the first block number (ie 2) of the two adjacent reference blocks, the maximum number of layers passed by the verification path is the second block chain Type layer (that is, the first upper block chain layer), then the determined verification path will be B ₁₅ → B ₂₃ → B ₂₄ → B ₂₅ → B ₂₆ → B ₁₁₁ → B ₁₁₂ , the verification path includes 7 areas Piece. That is, the verification path is shortened compared to the case when the number of blockchain layers passed exceeds the number of blocks in the first interval.

For the case where the first block number between two adjacent reference blocks in each block chain layer is not equal, the first block number can be determined based on block index information. Since the block index information includes the index relationship between the reference block and the corresponding upper block, the block chain layer between the verified bottom block and the target bottom block can be determined based on the block index information And determine the first number of blocks between two adjacent reference blocks in each layer of the block chain layer. After the first block number is confirmed, when the verification path is determined through the upper block chain layer, it can be based on the first block number between two adjacent reference blocks and the verified bottom block and the target bottom zone. The second number of blocks between blocks is calculated and the blocks of each layer of the block chain layer should be included in the verification path.

If the number of blocks between two adjacent reference blocks is not completely equal, the verification path can also be determined based on the block index information. The block index information indicates the distance between each reference block and the corresponding upper-level block. index. The reference block in each block chain layer can be determined based on the block index, and then after rising to each upper block chain layer, the next block of the block chain layer can be determined by heuristics. Reach or exceed the target underlying block. If it reaches or exceeds the underlying block, then discard the block chain layer and descend to the lower block chain layer to continue searching.

Since the block index information stores the index relationship between each reference block and the corresponding upper block, it can be determined based on the block index information whether each upper block in the upper block chain layer has actually exceeded the target The bottom layer. For example, the block index information may be included in each reference block, and each reference block may include an upper block index field. For example, the block height or hash value of the upper block corresponding to the reference block may be written Enter the upper block index field of the reference block. When determining the verification path, each underlying block can be queried from the verified underlying block pointed to by the current trust point. When the upper block index field of the queried block is empty, it indicates that the queried block is not the corresponding block chain When the index field of the upper-level block is not empty, it indicates that the queried block is a reference block. At this time, the upper-layer block corresponding to the queried block can be determined based on the upper-layer block index information, and then ascending to the adjacent upper-layer block chain layer to continue the query. When querying in the upper block chain layer, if it is determined that a certain upper block is the reference block in the corresponding upper block chain layer, since the upper block includes the index of the corresponding lower block, it can be based on the corresponding lower block The index of determines whether the bottom-layer block that the upper-layer block can locate has exceeded the target bottom-layer block. If it does not exceed the target bottom block, it can continue to rise to the upper block chain layer, if it exceeds the target bottom block, it will fall back to the previous upper block of the upper block chain layer and drop to the lower block chain. Floor. After descending to the lower block chain layer of the upper block chain layer, if the lower block chain layer is still the upper block chain layer, you can continue to determine whether the next block of the lower block that has fallen to exceeds Target bottom block. If the next block does not exceed the target bottom block, the next block of the bottom block can be determined as the block in the verification path. If the next block of the lower-level block has exceeded the target bottom-level block, it will continue to descend until it reaches the bottom-level blockchain. Perform the above process until the target underlying block is queried to determine the verification path.

After the verification path is determined, in block 740, for each block in the verification path, it is verified whether the link between the block and the previous block is correct. The link verification process can be determined based on the link relationship between each block. For the blocks in the same block chain layer in the verification path, each block stores the parent hash, so the chain between each block and the previous block can be verified based on the block information of the previous block Is the path correct? For example, taking the verification path indicated by the solid arrow in Figure 4 as an example, B ₁₄ and B ₁₅ , B ₃₂ and B ₃₃ are located at the bottom block chain layer and the second upper block chain layer, respectively, B ₁₄ is the B ₁₅ The parent block, B ₃₂ is the parent block of B _33. Thus a block may be based on the information in the hash and the parent B ₁₅ B ₁₄ to verify the link between B ₁₄ and B ₁₅ are correct. For adjacent blocks located in different blockchain layers, since the upper block is generated based on the corresponding reference block of the lower layer, the block information of the corresponding reference block can be used to verify the relationship between the two adjacent blocks The link is correct. In order to verify the path shown in FIG. 4 for example, B ₁₅ and B _23, B ₃₂ are located at different layers of the chain block, B ₁₅ is the reference block B _23, B ₂₃ B ₃₂ of the block is the reference. Since the block B ₂₃ is based on at least information generated B _15, B ₃₂ is block information based on at least B ₂₃ is generated, and thus the information may be based on the block B ₁₅ and B ₂₃ to B ₁₅ and verified prior to B ₂₃ link, based on information of the block B ₂₃ and B ₃₂ to verify that the link prior to B ₂₃ and B _32. The specific link verification process will be described below with reference to FIG. 9.

It should be noted that the verification process of the link between each block in the verification path may be executed after the verification path is determined, or may be executed during the process of determining the verification path. For example, for the verification path shown in Figure 4, when determining the next block of _{B 14} _{(ie B 15} ), verify the link between _{B 14} and B ₁₅ and then determine the next block of _{B 15} . After determining _{the next block of B 15} (ie, B ₂₃ ), the link between _{B 15} and B _{23 is verified.} In the process of determining the verification path and the link verification process, when the link before any two blocks is incorrect, it can be determined that the link in the verification path is incorrect.

Then, at block 760, it is determined whether the links between each block in the verification path are correct. When the link between each block in the verification path is correct, at block 780, the trust point is updated to indicate the target underlying block.

Each block in the verification path may store a first hash value generated at least based on block information of the previous block. If the previous block of the block is in the same block chain layer as the block, the first hash value may be the parent hash of the block. If the previous block of the block and the block are located in a different block chain layer, the first hash value may be obtained by performing a hash operation based at least in part on the block information of the previous block. At this time, the example shown in FIG. 9 can be used for link verification. Fig. 9 is a flowchart of a link verification process in a method for updating a trust point in a blockchain according to an embodiment of the present specification.

As shown in FIG. 9, in block 902, a hash operation is performed at least based on the block information of the previous block to obtain the second hash value. Then, in block 904, it is determined whether the obtained second hash value is consistent with the first hash value in the block. When the two are consistent, at block 906, it is determined that the link between the block and the previous block is correct. When the two are inconsistent, at block 908, it is determined that the link between the block and the previous block is incorrect.

When the previous block of the block and the block are in the same block chain layer, the block header of the previous block can be hashed to obtain the second hash value. Then, the consistency of the second hash value and the parent hash in the block can be compared. For example, taking the verification path indicated by the solid arrow in Figure 4 as an example, since B ₁₄ is the parent block of B ₁₅ _{, the block information of B 14} can be hashed to obtain the hash value and compare all The obtained hash value is consistent with the parent hash stored in _{B 15.} When the two are consistent, it can be determined that the link between _{B 14} and B _{15 is correct.}

When the previous block of the block and the block are located in different block chain layers, the previous block is the reference block of the block, so it can be performed based at least in part on the block information of the previous block Hash operation to obtain the second hash value. For example, the upper block may include the hash value of the corresponding reference block. In this example, if the previous block of a certain block in the verification path is located in the lower block chain layer, the block information of the previous block can be hashed to obtain the second hash value. _{Taking B 15} and B ₂₃ in the verification path shown in FIG. 4 as an example, the _{block header of B 15} may be hashed to obtain the second hash value. Then, it can be compared whether the obtained second hash value is consistent with the hash value of B ₁₅ _{stored in B 23.} If the two are consistent, it can be determined that the link between _{B 15} and B _{23 is correct.} For another example, when the upper block is generated corresponding to the reference block, the block information from the first block to the reference block in the block chain layer where the reference block is located can be performed. Hash operation, and store the obtained hash value as the first hash value in the generated upper block. In this example, if the previous block of a block in the verification path is located in the lower block chain layer, the first block in the block chain layer where the previous block is located can be compared to the previous block. All block information of the block is hashed to obtain the second hash value. _{Taking B 15} and B ₂₃ in the verification path shown in FIG. 4 as an example, _{the block information of B 11} , B ₁₂ , B ₁₃ , B ₁₄ and B ₁₅ can be hashed to obtain the second hash value . Then, the obtained hash value can be compared with _{the first hash value stored in B 23} , and if the two are consistent, it can be determined that the link between _{B 15} and B _{23 is correct.}

After the link between each block in the verification path is verified as correct, the correctness of the target underlying block can also be verified. The correctness of the target underlying block can be executed by verifying whether it has passed the consensus of the entire network. Fig. 10 is a flowchart of a method for updating trust points in a blockchain according to another embodiment of the present specification.

As shown in FIG. 10, at block 1002, based on the multi-layer block chain structure, the verification path between the verified underlying block and the target underlying block indicated by the current trust point is determined. After the verification path is determined, in block 1004, for each block in the verification path, it is verified whether the link between the block and the previous block of the block is correct. Then in block 1006, it is judged whether the links between each block in the verification path are all verified as correct.

If the links between each block and the previous block are all verified as correct, then in block 1008, it is determined whether the target underlying block is correct. You can refer to the example shown in FIG. 11 to verify whether the target underlying block is correct.

Fig. 11 is a flowchart of a target underlying block verification process in a method for updating trust points in a multi-layer block chain structure according to an embodiment of the present specification.

As shown in FIG. 11, at block 1102, multiple target bottom-level block information of the target bottom-level block is obtained from multiple full nodes in the blockchain system.

Then, in block 1104, when there is no less than a statutory number of consistent target bottom-layer block information in the multiple target bottom-layer block information, it is determined that the target bottom-layer block is correct. When there is no less than a statutory number of consistent target bottom-level block information, it can be determined that the target bottom-level block has passed the consensus of the entire network, and thus it can be determined that it is correct.

When the target underlying block is determined to be correct, at block 1010, the trust point is updated to indicate the target underlying block. If the link between each block of the verification path and the previous block is not completely correct or the target underlying block is determined to be incorrect, it indicates that the target underlying block cannot be trusted. In this case, the target underlying block can be re-determined and the trust point update process can be performed.

When the multi-layer block chain structure is applied to a centralized blockchain-like system, after each block in each underlying block chain layer is generated, the block can be sent to a trusted third-party server. The three-party server can use its private key to sign and authenticate the block. When verifying whether the target underlying block is correct, you can obtain the signature of the target underlying block from the third-party server, and then use the public key of the third-party server to verify the signature of the obtained target underlying block. Make sure that the target underlying block is correct.

Through this embodiment, the credibility of the updated trust point can be further ensured.

Fig. 12 is a structural block diagram of a device for generating a multi-layer block chain structure according to an embodiment of the present specification. As shown in FIG. 12, the multi-layer block chain structure generating device 1200 includes a bottom block chain layer generating unit 1210 and an upper block chain layer generating unit 1220.

The bottom block chain layer generating unit 1210 generates blocks of the bottom block chain layer in the multi-layer structure based on the transaction data. The upper block chain layer generating unit 1220 generates the upper block chain layer based on the lower block chain layer according to the upper block chain layer generation conditions. The upper block chain layer generating unit 1220 includes a reference block determining module 1221 and an upper block chain layer generating module 1222. The reference block determination module 1221 determines whether there is a reference block that triggers the generation condition of the upper block chain layer in the underlying block chain layer. The upper block chain layer generation condition may include the number of blocks between the reference block and the previous reference block reaching a specified number, and may also include the generation time of the reference block and the generation time of the previous reference block The time interval reaches the specified time interval.

In one example, the reference block determination module 1221 may traverse the blocks in each block chain layer in the multi-layer block chain structure to determine the reference block that meets the generation conditions of the upper block chain layer. In another example, the reference block determination module 1221 may determine whether the newly generated block is a reference block that meets the generation conditions of the upper block chain layer for each block chain layer in the blockchain.

The upper block chain layer generation module 1222 responds to the presence of a reference block in the lower block chain layer that triggers the block generation condition of the upper block chain layer, and generates the upper block chain layer based at least in part on the block information of the reference block. The corresponding upper block of the layer.

The multi-layer block chain structure may include a plurality of upper block chain layers. In this example, the upper block chain layer generating unit 1220 can generate the upper block chain layer based on the upper block chain layer according to the same or different upper block chain layer generation conditions for each upper block chain layer. The adjacent upper block chain layer. Specifically, the reference block determination module 1221 may determine whether there is a reference block in the upper block chain layer that triggers the generation condition of the upper block chain layer for each upper block chain layer. When there is a reference block that triggers the generation condition of the upper block chain layer, the upper block chain layer generation module 1222 may generate the adjacent upper block of the upper block chain layer based at least in part on the block information of the reference block The corresponding upper block of the chain layer.

In an example, the upper block chain layer generation module 1222 may also generate the block information based on the block information of at least part of all blocks from the first block of each block chain layer to the reference block. The corresponding block of the adjacent upper block chain layer of the block chain layer.

The block chain generation device may also include a block index information storage unit (not shown in the drawings). The block index information storage unit stores the block index information of the reference block and the corresponding upper block. In an example, the block index information storage unit may store the block index information in the reference block or the upper block corresponding to the reference block, and may also store the block index information in the next block of the upper block. Block. In another example, the block index information storage unit may also store the block index information in the index database.

Fig. 13 is a structural block diagram of an apparatus for updating trust points in a multi-layer block chain structure according to an embodiment of the present specification. As shown in FIG. 13, the trust point update device 1300 includes a verification path determination unit 1310, a link verification unit 1320, a target bottom layer block verification unit 1330, and a trust point update unit 1340.

The verification path determination unit 1310 determines the verification path between the verified bottom-level block and the target bottom-level block indicated by the current trust point based on the multi-layer block chain structure. In one example, the verification path determination unit 1310 may determine the verification path via at least one upper-level block chain layer when there are at least two base-level block-chain-type reference blocks between the target bottom-level block and the verified bottom-level block. .

In an example, the number of first blocks between two adjacent reference blocks in each block chain layer may be equal, and the number of upper block chain layers passed by the verification path may not exceed the first zone Number of blocks.

In an example, the verification path determination unit 1310 may determine the verification path based on the first block number and the second block number, where the first block number is the difference between two adjacent reference blocks of each block chain layer. Block number, the second block number is the number of blocks between the target bottom block and the verified bottom block. The number of first interval blocks between two adjacent reference blocks of each block chain layer may be determined based on block index information.

In another example, the verification path determination unit 1310 may also determine the verification path based on block index information.

After the verification path is determined, the link verification unit 1320 verifies whether the link between the block and the previous block in the verification path is correct for each block in the verification path. The target bottom block verification unit 1330 verifies whether the target bottom block is correct. The trust point update unit 1340 updates the target bottom block as the trust point when the link between each block in the verification path is correct and the target block is correct.

In another example, the trust point update apparatus may not include the target underlying block verification unit 1330. In this example, the trust point update unit 1340 may update the target underlying block to the trust point when the link between each block in the verification path is correct.

FIG. 14 is a structural block diagram of the link verification unit in the device for updating the trust point of the multi-layer block chain structure shown in FIG. 13. As shown in FIG. 14, the link verification unit 1320 includes a hash operation module 1321 and a link verification module 1322. In this example, each block in the verification path includes the first hash value of the previous block.

The hash operation module 1321 performs a hash operation based at least in part on the block information of the previous block obtained locally to obtain the second hash value. The link verification module 1322 verifies whether the link between the block and the previous block is correct based on the consistency between the second hash value and the first hash value.

FIG. 15 is a structural block diagram of a target bottom-level block verification unit in the device for updating trust points in a multi-layer block chain structure shown in FIG. 13. As shown in FIG. 15, the target bottom layer block verification unit 1330 includes a hash operation module 1321 and a link verification module 1322.

The target bottom block information acquisition module 1331 obtains multiple target bottom block information of the target bottom block from multiple full nodes in the blockchain system. The target bottom block verification module 1332 determines whether the target bottom block is correct when there is no less than a statutory number of consistent target bottom block information in the multiple target bottom block information.

1 to 6 and 12, the method and apparatus for generating a multi-layer block chain structure according to the embodiments of the present specification are described above, and the trust points are described with reference to FIGS. 7 to 11 and 13 to 15. The update method and device are described. The details mentioned in the above description of the method embodiment are also applicable to the embodiment of the device in the embodiment of this specification.

The multi-layer block chain structure generation device and the trust point update device in the embodiments of the present specification can be implemented by hardware, or can 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 multi-layer block chain structure generation device and the trust point update device in the embodiments of the present specification can be implemented by hardware, or can 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 by the processor of the device where it is located. In the embodiment of the present specification, the multi-layer block chain structure generating device and the trust point updating device can be realized by using a computing device, for example.

Fig. 16 is a structural block diagram of a computing device for implementing a multi-layer block chain structure generation method or a trust point update method according to an embodiment of the present specification. As shown in FIG. 16, the computing device 1600 includes a processor 1610, a memory 1620, a memory 1630, a communication interface 1640, and an internal bus 1650, and a processor 1610, a memory (for example, a non-volatile memory) 1620, a memory 1630, and a communication interface The 1640 are connected together via a bus 1650. According to one embodiment, the computing device 1600 may include at least one processor 1610 that executes at least one computer-readable instruction (ie, the aforementioned Elements implemented in software).

In one embodiment, computer-executable instructions are stored in the memory 1620, which, when executed, cause at least one processor 1610 to: generate blocks of the underlying block chain layer in the multi-layer block chain structure based on transaction data; and according to The upper block chain layer generation conditions are based on the lower block chain layer to generate the upper block chain layer, wherein, according to the upper block chain layer generation conditions, the upper block chain layer is generated based on the bottom block chain layer including: determining the bottom block chain Whether there is a reference block that triggers the generation condition of the upper block chain layer in the type layer; in response to the presence of a reference block in the underlying block chain layer that triggers the generation condition of the upper block chain layer, the area based at least in part on the reference block Block information to generate the corresponding upper block of the upper block chain layer.

In another embodiment, computer-executable instructions are stored in the memory 1620, which when executed, cause at least one processor 1610 to: based on a multi-layer block chain structure, determine the verified underlying block and target indicated by the current trust point The verification path between the underlying blocks; for each block in the verification path, verify whether the link between the block and the previous block of the block is correct; and when each of the verification paths When the links between the blocks are all correct, update the target bottom block as a trust point.

It should be understood that the computer-executable instructions stored in the memory 1620, when executed, cause at least one processor 1610 to perform the various operations and functions described above in conjunction with FIGS. 1 to 6 and 12 in the various embodiments of the embodiments of this specification, or Various operations and functions are described with reference to Figures 7 to 11 and 13 to 15.

According to one embodiment, a program product such as a non-transitory machine-readable medium is provided. 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 various embodiments of the embodiments of this specification. The various operations and functions described in 12, or the various operations and functions described with reference to FIGS. 7 to 11 and 13 to 15.

Specifically, 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.

In this case, the program code itself read from the readable medium can implement 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. Alternatively, the program code can be downloaded from the server computer or the cloud via the communication network.

The foregoing describes specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps described in the claims can be performed in a different order than in the embodiments and still achieve desired results. In addition, the processes depicted in the drawings do not necessarily require the specific order or sequential order shown in order to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

Not all steps and units in the above processes and system structure diagrams are necessary, and some steps or units can be omitted according to actual needs. The order of execution of each step is not fixed and can be determined as needed. 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.

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

The above describes in detail the optional implementation manners of the embodiments of the embodiments of this specification with reference to the accompanying drawings. However, the embodiments of the embodiments of this specification are not limited to the specific details in the above-mentioned embodiments. Within the scope of the conception, a variety of simple modifications can be made to the technical solutions of the embodiments of the embodiments of the present specification, and these simple modifications all belong to the protection scope of the embodiments of the embodiments of the present specification.

The foregoing description of the content of the embodiments of this specification is provided to enable any person of ordinary skill in the art to implement or use the content of the embodiments of this specification. It is obvious to a person of ordinary skill in the art that various modifications made to the content of the embodiments of this specification are obvious, and the general principles defined herein can also be used without departing from the scope of protection of the content of the embodiments of this specification. Apply to other variants. Therefore, the contents of the embodiments of this specification are not limited to the examples and designs described herein, but are consistent with the widest scope that conforms to the principles and novel features disclosed herein.

Claims

A method for updating trust points in a multi-layer block chain structure, the multi-layer block chain structure includes a bottom block chain layer and at least one upper block chain layer, the area of the bottom block chain layer The block is generated based on transaction data, and the upper block of the at least one upper block chain layer is generated based at least in part on the block information of the reference block in the lower block chain layer of the upper block chain layer. The trust point indicates the verified bottom block with the largest block height in the bottom block chain layer,

The method includes:

Based on the multi-layer block chain structure, determine the verification path between the verified underlying block indicated by the current trust point and the target underlying block;

For each block in the verification path, verify whether the link between the block and the previous block of the block is correct; and

When the links between the blocks in the verification path are correct, the target bottom block is updated as a trust point.
The method of claim 1, wherein, based on the multi-layer block chain structure, determining the verification path between the verified bottom-layer block and the target bottom-layer block indicated by the current trust point comprises:

When there are at least two bottom-level reference blocks between the target bottom-level block and the verified bottom-level block, the verification path is determined via at least one upper-level block chain layer.
The method according to claim 2, wherein the first block number between two adjacent reference blocks in each block chain layer in the multi-layer block chain structure is equal, and the verification path is The number of upper block chain layers passed does not exceed the number of the first block.
The method according to claim 2, wherein, based on the multi-layer block chain structure, determining the verification path between the verified bottom-layer block indicated by the current trust point and the target bottom-layer block comprises:

The verification path is determined based on the first number of blocks and the second number of blocks. The first number of blocks is the number of blocks between two adjacent reference blocks of each block chain layer. The number of two blocks is the number of bottom blocks between the target bottom block and the verified bottom block.
The method according to claim 4, wherein the first number of blocks between two adjacent reference blocks of each block chain layer is determined based on block index information, and the block index information indicates The index of each reference block and the corresponding upper block.
The method of claim 1, wherein, based on the multi-layer block chain structure, determining the verification path between the verified bottom-layer block and the target bottom-layer block indicated by the current trust point comprises:

The verification path is determined based on block index information, and the block index information indicates the index between each reference block and the corresponding upper block.
The method of claim 1, further comprising:

Verify that the target underlying block is correct,

When the links between the blocks in the verification path are correct, updating the target bottom layer block to a trust point includes:

When the links between the blocks in the verification path are correct and the target block is determined to be correct, the target bottom block is updated as a trust point.
8. The method of claim 7, wherein verifying whether the target underlying block is correct comprises:

Obtain multiple target bottom-level block information of the target bottom-level block from multiple full nodes in the blockchain system; and

When there is no less than a legal number of consistent target bottom block information in the multiple target bottom block information, it is determined that the target bottom block is correct.
The method of claim 1, wherein each block in the verification path includes a first hash value generated at least based on the block information of the previous block, and verifying the difference between the block and the block Whether the link between the previous block is correct includes:

Performing a hash operation based at least in part on the block information of the previous block obtained locally to obtain a second hash value;

Based on the consistency between the second hash value and the first hash value, it is verified whether the link between the block and the previous block is correct.
The method according to any one of claims 1-9, wherein the block height of the target bottom layer block is not less than the bottom layer block to be verified where the transaction to be verified is to be verified by SPV.
A device for updating trust points in a multi-layer block chain structure. The multi-layer block chain structure includes a bottom block chain layer and at least one upper block chain layer. The block is generated based on transaction data, and the upper block of the at least one upper block chain layer is generated based at least in part on the block information of the reference block in the lower block chain layer of the upper block chain layer. The trust point indicates the verified bottom block with the largest block height in the bottom block chain layer,

The device includes:

The verification path determination unit, based on the multi-layer block chain structure, determines the verification path between the verified underlying block and the target underlying block indicated by the current trust point;

The link verification unit, for each block in the verification path, verifies whether the link between the block and the previous block of the block is correct; and

The trust point update unit, when the links between the blocks in the verification path are correct, update the target bottom layer block to the trust point.
The device of claim 11, wherein the verification path determination unit passes through at least one upper-level block chain layer when there are at least two bottom-level reference blocks between the target bottom-level block and the verified bottom-level block. Determine the verification path.
The device according to claim 12, wherein the number of first blocks between two adjacent reference blocks in each block chain layer is equal, and the number of upper block chain layers passed by the verification path Does not exceed the number of first blocks.
The apparatus of claim 12, wherein the verification path determination unit determines the verification path based on a first block number and a second block number, and the first block number is adjacent to each block chain layer The number of blocks between two reference blocks, and the second number of blocks is the number of bottom blocks between the target bottom block and the verified bottom block.
The device of claim 14, wherein the first number of blocks between two adjacent reference blocks of each block chain layer is determined based on block index information, and the block index information indicates The index of each reference block and the corresponding upper block.
11. The apparatus of claim 11, wherein the verification path determination unit determines the verification path based on block index information, and the block index information indicates an index between each reference block and a corresponding upper block.
The apparatus of claim 11, further comprising:

The target bottom block verification unit verifies whether the target bottom block is correct;

The trust point update unit updates the target underlying block as a trust point when the links between the blocks in the verification path are correct and the target block is verified as correct.
The apparatus of claim 17, wherein the target bottom layer block verification unit comprises:

The target bottom block information acquisition module, which obtains multiple target bottom block information of the target bottom block from multiple full nodes in the blockchain system; and

The target bottom-level block verification module determines that the target bottom-level block is correct when there is no less than a statutory number of consistent target bottom-level block information in the multiple target bottom-level block information.
11. The device of claim 11, wherein each block in the verification path includes a first hash value generated at least based on block information of the previous block, and the path verification verification unit includes:

A hash operation module that performs a hash operation based at least in part on the block information of the previous block obtained locally to obtain a second hash value;

The link verification module verifies whether the link between the block and the previous block is correct based on the consistency between the second hash value and the first hash value.
A computing device including:

At least one processor; and

A memory, where the memory stores instructions, and when the instructions are executed by the at least one processor, the at least one processor executes the method according to any one of claims 1 to 10.
A machine-readable storage medium that stores executable instructions that when executed causes the machine to execute the method according to any one of claims 1 to 10.