CN111143381B

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

Info

Publication number: CN111143381B
Application number: CN201911267099.0A
Authority: CN
Inventors: 俞本权
Original assignee: Alipay Hangzhou Information Technology Co Ltd
Current assignee: Alipay Hangzhou Information Technology Co Ltd
Priority date: 2019-12-11
Filing date: 2019-12-11
Publication date: 2023-05-19
Anticipated expiration: 2039-12-11
Also published as: CN111143381A; WO2021114796A1

Abstract

The present description embodiments provide a method for updating a trust point in a multi-layer block chain structure, the multi-layer block chain structure comprising an underlying block chain layer and at least one upper block chain layer, blocks of the underlying block chain layer being generated based on transaction data, upper blocks of the at least one upper block chain layer being generated based at least in part on block information of reference blocks in a lower block chain layer of the upper block chain layer, the trust point indicating a block highest verified underlying block in the underlying block chain layer, the method comprising: determining a verification path between the verified bottom layer block indicated by the current trust point and the target bottom layer block based on the multi-layer block chain structure; verifying, for each block in the verification path, whether a link between the block and a block preceding the block is correct; and updating the target bottom layer block as a trust point when links among all blocks in the verification path are correct.

Description

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

Technical Field

The embodiment of the specification relates to the technical field of blockchains, in particular to a method and a device for updating trust points in a multi-layer block chain structure.

Background

A blockchain network is a decentralized, distributed data storage system that is engaged by 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, and on the other hand, the data written to the blockchain is also difficult to delete and tamper. In addition, in a blockchain-like system, the centralized device may also store data in a manner similar to blockchain storage (which may be considered centralized blockchain storage). In this specification, systems that store data in a blockchain manner, such as blockchain systems and blockchain-like systems, are referred to as blockchain systems.

In a block chain system, block chain data is very large and the amount of data increases over time. In the conventional block chain structure, if operations such as synchronization, verification, or inquiry are to be performed on data stored on a block chain, the data access amount and the operation amount are enormous. Accordingly, a technique capable of improving the operation efficiency on block chain data is demanded.

Disclosure of Invention

In view of the foregoing, embodiments of the present disclosure provide a method and apparatus for updating trust points in a multi-layer block chaining structure.

According to an aspect of embodiments of the present specification, there is provided a method for updating a trust point in a multi-layer block chain structure, the multi-layer block chain structure comprising an underlying block chain layer whose blocks are generated based on transaction data and at least one upper block chain layer whose upper blocks are generated based at least in part on block information of a reference block in a lower block chain layer of the upper block chain layer, the trust point indicating a block-highest verified underlying block in the underlying block chain layer, the method comprising: determining a verification path between the verified bottom layer block indicated by the current trust point and the target bottom layer block based on the multi-layer block chain structure; verifying, for each block in the verification path, whether a link between the block and a block preceding the block is correct; and updating the target bottom layer block as a trust point when links among all blocks in the verification path are correct.

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

Alternatively, in one 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 number of upper block chain layers through which the verification path passes may not exceed the number of first blocks.

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

Alternatively, in one example, the first block number between two adjacent reference blocks of the respective block chain layers may be determined based on block index information indicating indexes of the respective reference blocks and the corresponding upper layer blocks.

Optionally, in one example, determining the verification path between the verified underlying tile indicated by the current trust point and the target underlying tile based on the multi-layer block chain structure may include: the validation path is determined based on block index information indicating indexes between respective reference blocks and corresponding upper layer blocks.

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

Optionally, in one example, verifying whether the target underlying tile is correct may include: acquiring a plurality of target bottom layer block information of the target bottom layer block from a plurality of total nodes in a block chain system; and determining that the target underlying block is correct when there is no less than a quorum of consistent target underlying block information in the plurality of target underlying block information.

Optionally, in one example, verifying that each block in the verification path includes a first hash value generated based at least on the block information of the previous block, verifying whether a link between the block and the previous block of the block may include: performing hash operation based at least in part on the block information of the previous block acquired locally to obtain a second hash value; based on the consistency between the second hash value and the first hash value, whether the link between the block and the previous block is correct is verified.

Alternatively, in one example, the target floor tile may have a block height that is not less than the floor tile to be verified where the transaction to be verified is to be performed with SPV verification.

According to another aspect of embodiments of the present specification, there is also provided an apparatus for updating a trust point in a multi-layer block chain structure including an underlying block chain layer whose blocks are generated based on transaction data and at least one upper block chain layer whose upper blocks are generated based at least in part on block information of a reference block in a lower block chain layer of the upper block chain layer, the trust point indicating a block-highest-most verified underlying block in the underlying block chain layer, the apparatus comprising: a verification path determining unit for determining a verification path between the verified bottom layer block indicated by the current trust point and the target bottom layer block based on the multi-layer block chain structure; a link verification unit for verifying, for each block in the verification path, whether a link between the block and a block preceding the block is correct; and the trust point updating unit is used for updating the target bottom layer block into the trust point when the links among all the blocks in the verification path are correct.

Alternatively, in one example, the verification path determining unit may determine the verification path via at least one upper block chain layer when at least two lower reference blocks exist between the target lower block and the verified lower block.

Alternatively, in one 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 through which the verification path passes may not exceed the number of first blocks.

Optionally, in one example, the verification path determining unit may determine the verification path based on a first block number and a second block number, the first block number being a block number between two adjacent reference blocks of each block chain layer, the second block number being an underlying block number between the target underlying block and the verified underlying block.

Alternatively, in one example, the verification path determination unit may determine the verification path based on block index information indicating indexes between respective reference blocks and corresponding upper layer blocks.

Optionally, in one example, the apparatus may further include: a target bottom layer block verification unit for verifying whether the target bottom layer block is correct; the trust point updating unit updates the target underlying block to a trust point when links between blocks in the verification path are correct and the target block is verified as correct.

Optionally, in one example, the target underlying block verification unit may include: the target bottom layer block information acquisition module acquires a plurality of target bottom layer block information of the target bottom layer block from a plurality of total nodes in the block chain system; and a target underlying block verification module that determines that the target underlying block is correct when there is no less than a quorum of consistent target underlying block information in the plurality of target underlying block information.

Optionally, in one example, each block in the verification path includes a first hash value generated based at least on block information of the previous block, and the path verification unit may include: the hash operation module is used for carrying out hash operation at least partially based on the block information of the previous block acquired locally so as to obtain a second hash value; and the link verification module is used for verifying whether the link between the block and the previous block is correct or not based on the consistency between the second hash value and the first hash value.

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

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

With the method and apparatus of the embodiments of the present specification, when there is a reference block that triggers an upper block chain layer generation condition, a corresponding upper block of the upper block chain layer is generated based at least in part on block information of the reference block, so that a multi-layer block chain structure can be generated. By using the multi-layer block chain structure, when the data in the block chain structure is subjected to related operation, each block of the bottom layer block chain layer does not need to be accessed one by one, so that the data access amount and the operation amount can be reduced, and the operation efficiency is improved.

Drawings

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

FIG. 1 illustrates a schematic diagram of an example of an environment that may be used to perform a method for generating a multi-layer block chaining structure and a method for updating trust points in the multi-layer block chaining structure according to an embodiment of the present disclosure;

FIG. 2 shows a schematic diagram of an example of a system architecture that performs a method for generating a multi-layer block chaining structure and a method for updating trust points in the multi-layer block chaining structure according to an embodiment of the present specification;

FIG. 3 is a flow chart of a method for generating a multi-layer block chain structure according to one embodiment of the present description;

FIG. 4 is a schematic diagram of a multi-layer block chain structure according to one embodiment of the present disclosure;

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

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

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 one embodiment of this specification;

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

FIG. 7 is a flowchart of a method for updating trust points in a multi-tiered block chaining structure according to one embodiment of this disclosure;

FIG. 8 is a flow diagram of a link verification process in a method for updating trust points in a multi-layer block chaining structure according to one embodiment of the present disclosure;

FIG. 9 is a flowchart of a method for updating trust points in a multi-tiered block chaining structure in accordance with another embodiment of the present specification;

FIG. 10 is a flow diagram of a target underlying block verification process in a method for updating trust points in a multi-layer block chaining structure according to one embodiment of the present disclosure;

FIG. 11 is a flow chart of a method of SPV verification of a transaction to be verified according to one embodiment of the present description;

FIG. 12 is a block diagram of a multi-layered block chain structure generation apparatus according to one embodiment of the present disclosure;

FIG. 13 is a block diagram of an apparatus for updating trust points in a multi-tiered block chaining structure according to one embodiment of this disclosure;

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

FIG. 15 is a block diagram of a target underlying block verification unit in the apparatus for updating trust points in a multi-layer block chaining structure shown in FIG. 13;

FIG. 16 is a block diagram of a computing device for implementing a method for generating a multi-layer block chaining structure or a method for updating trust points in a multi-layer block chaining structure according to one embodiment of the present disclosure.

Detailed Description

The subject matter described herein will be discussed below with reference to example embodiments. It should be appreciated that these embodiments are discussed only to enable a person skilled in the art to better understand and thereby practice the subject matter described herein, and are not limiting of the scope, applicability, or examples set forth in the claims. Changes may be made in the function and arrangement of elements discussed without departing from the scope of the embodiments herein. Various examples may omit, replace, or add various procedures or components as desired. In addition, features described with respect to some examples may be combined in other examples as well.

As used herein, the term "comprising" and variations thereof mean open-ended 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," and the like, may refer to different or the same object. Other definitions, whether explicit or implicit, may be included below. Unless the context clearly indicates otherwise, the definition of a term is consistent throughout this specification.

Methods and apparatus for generating a blockchain having a multi-layer structure, and methods and apparatus for updating trust points in the blockchain, according to embodiments of the present specification, will now be described with reference to the accompanying drawings.

A blockchain is a chain data structure that sequentially links and combines data blocks in a temporal order, and cryptographically ensures that the data blocks are not tamperable and counterfeitable. A blockchain includes one or more blocks. Each block in the blockchain is linked to the immediately preceding block in the blockchain by including a cryptographic hash of the preceding block. Each chunk also includes a timestamp, a cryptographic hash of the chunk, and one or more transactions (transactions). The transaction that has been validated by a node of the blockchain network is hashed and forms a Merkle tree. In the Merkle tree, data at leaf nodes is hashed and for each branch of the Merkle tree, all hash values of that branch are concatenated at the root of that branch. The above process is performed for the Merkle tree up to the root node of the entire Merkle tree. The root node of the Merkle tree stores hash values representing all the data in the Merkle tree. When a hash value claims to be a transaction stored in the Merkle tree, a quick verification may be performed by determining whether the hash value is consistent with the Merkle tree structure.

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

In a common blockchain network, the consensus process is controlled by nodes of the consensus network. For example, there may be thousands of entity collaboration processes in a public blockchain network, each entity operating at least one node in the public blockchain network. Thus, a public blockchain network may be considered a public network of participating entities. In some examples, most entities (nodes) must sign each block in order 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. Furthermore, the term "blockchain" does not particularly refer to any particular blockchain.

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

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

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

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

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

The consensus mechanism ensures that all network nodes in the distributed blockchain network execute transactions in the same order and then write the same ledger. The consensus model aims to solve the problem of the Bayesian family. In the bayer problem, components such as servers or network nodes in the distributed blockchain network may fail or deliberately spread erroneous information to other nodes. It is difficult for other network nodes to declare the component as failed and exclude it from the blockchain network because other network nodes need to agree first on which network node failed first.

FIG. 1 illustrates a schematic diagram of an example of an environment 100 that may be used to perform a method for generating a blockchain with a multi-layer structure and a method for updating trust points in a multi-layer blockchain structure in accordance with embodiments of the present description. In some examples, the environment 100 enables entities to participate in the blockchain network 102. As shown in fig. 1, environment 100 includes a network 104, and computing devices/

systems

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

systems

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

systems

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

system

106, 108 may be a separate cloud computing system that includes multiple computers interconnected by the network 104 and that serves 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, notebook computers, tablet devices, smartphones, and the like. In some examples, one or more computer-implemented services for interacting with the blockchain network 102 may be installed on the computing devices/

systems

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

systems

106, 108 act as nodes of first and second entities, respectively, that participate in the blockchain network 102.

Fig. 2 shows a schematic diagram of an example of a system architecture 200 that performs a method for generating a blockchain with a multi-layer structure and a method for updating trust points in the multi-layer blockchain structure in accordance with embodiments of the present description. Examples of system architecture 200 include

participant systems

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

In the illustrated example, each of the

participant systems

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

participant systems

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

The participation of the nodes 214 in the blockchain network 212 may vary. For example, some nodes 214 may participate in the consensus process (e.g., as mineworker 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 store only a partial copy of the blockchain 216. In the example of fig. 2, the

participant systems

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

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

The transaction data is hashed before being stored in the block. The hash processing is a process of converting transaction data (provided as character string data) into a hash value of a fixed length (also provided as character string data). By hashing the transaction data, even slight changes to the transaction data can result in disparate hash values. The hash value is typically generated by hashing the transaction data using a hash function. Examples of hash functions include, but are not limited to, secure Hash Algorithm (SHA) -256, which outputs a 256-bit hash value.

Transaction data for a plurality of transactions may be stored in a chunk after being hashed. For example, two hash values are obtained by hashing two transaction data, and then the obtained two 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 Merkle root hash and is stored in the header of the block. Any transaction change will result in a change in its hash value, ultimately resulting in a change in the Merkle root hash value.

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

The 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 may write a block to the blockchain. That is, mineworker nodes compete in the consensus process to add their blocks to the blockchain. In more detail, the mineworker node periodically collects pending transactions from the pool of transactions (e.g., until a predetermined limit, if any, on the number of transactions that may be included in the block is reached). The transaction pool includes transaction messages from participants in the blockchain network. The miner node creates a tile and adds the transaction to the tile. Before adding a transaction to a block, the miner node checks whether there is a transaction in the block of the blockchain in the transaction to be added. If the transaction has been added to another block, the transaction will be discarded.

The 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 hash) is obtained for all transactions in the block. The Merkle root hash is then added to the block header. The miner also determines the hash value of the latest block in the blockchain (i.e., the last block added to the blockchain). The miner node may also add a random value (noise value) and a time stamp in the block header. During the mining process, the mineworker node attempts to find a hash value that meets the required parameters. The mineworker node continually alters the nonce value until a hash value is found that meets the required parameters.

Each miner in the blockchain network tries to find hash values that meet the required parameters and in this way compete with each other. Finally, one 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, if determined to be correct, verify each transaction in the chunk, accept the chunk, and append the chunk to their blockchain copy. In this way, the global state of the blockchain is agreed upon on all miner nodes within the blockchain network. The above procedure is the POW consensus protocol.

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

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

Asymmetric encryption refers to encryption using a key pair. Each key pair includes a private key that is known only to the corresponding node and a public key that is known to any or all other nodes in the blockchain network. A node may encrypt data using the public key of another node and may decrypt the encrypted data using the private key of the other node. For example, refer again to fig. 1. Party a may encrypt data using party B's public key and send the encrypted data to party B may decrypt the encrypted data (ciphertext) and extract the original data (plaintext) using its private key. Messages encrypted using the public key of a node can only be decrypted using the private key of that node.

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

Although the description above describes a blockchain scenario to which the embodiments of the present specification may be applied, the embodiments of the present specification may also be applied to other blockchain scenarios. For example, the present embodiments may also be applicable to blockchain-like systems. In a blockchain-like system, data may be similarly stored in a block chain structure, unlike in a blockchain-like system, the blockchain data stored in the block chain structure does not need to undergo consensus processing.

In the embodiments described below, "bottom block chain layer" refers to the lowermost block chain layer of the multi-layer block chain structure, "upper block chain layer" refers to each block chain layer except the bottom block chain layer in the multi-layer structure, and "block chain layer" includes the bottom block chain layer and each upper block chain layer. "bottom layer blocks" refer to blocks in the bottom layer block chain layer, and "upper layer blocks" refer to blocks in the respective upper layer block chain layer. "adjacent upper block chain layer" refers to an adjacent "upper block. "lower layer" refers to the "next layer", e.g. "lower layer block" refers to a block in the next block chain layer of a block chain layer. The "reference block" refers to a block in each block chain layer that satisfies a predetermined condition to trigger generation of a corresponding upper layer block, the "last reference block" refers to a last reference block in the same block chain layer, for example, "reference block" and "last reference block" in the "last reference block of the reference block" refer to adjacent reference blocks in the same block chain layer. "preceding block" or "following block" refers to a block preceding or following a block in the verification path mentioned in this specification, which may be located in the same block chain layer as the preceding or following block, or may be located in a different block chain layer. "block high" refers to where a block is located in the corresponding block chain layer. For example, if the block height of the first block of each block chain layer is defined to be 0, the block height of the third block of the block chain layer may be 2. Similarly, if the block height of the first block of each block chain layer is defined to be 1, the block height of the third block of the block chain layer may be 3. The block heights may be determined in any ordered manner as long as the locations of the respective blocks at the respective block chain layer can be located based on the block heights.

FIG. 3 is a flowchart of a method for generating a multi-layer block chain structure according to one embodiment of the present description.

As shown in FIG. 3, at block 320, the bottom blocks of the bottom block chain layer of the multi-layer block chain structure are generated based on the transaction data. The bottom layer blocks of the bottom layer block chain layer may be generated by any method for generating a block chain structure, for example, the block chain generation method described above with reference to fig. 1 and 2, or the block chain generation method such as bitcoin, ethernet, etc. The respective transaction data may be packaged into the underlying blocks after processing through consensus processing and intelligent contract execution processing by the respective blockchain nodes. In a blockchain-like system, the transaction data that is being uplinked may not undergo consensus processing.

At block 340, it is determined whether there is a reference block in the bottom layer block chain layer that triggers the upper layer block chain layer generation condition. 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 may be determined based on whether the number of blocks between each block in the bottom layer block chain layer and the previous reference block reaches a specified number, and the reference block may be determined based on whether the time interval between the generation time of each block in the bottom layer block chain layer and the generation time of the previous reference block reaches a specified time interval. In this specification, another block is included in determining the number of blocks between the block and the other block.

In determining the reference block, at block 360, responsive to the existence of the reference block in the bottom block chain layer that triggers the upper block chain layer generation condition, a corresponding upper block of the upper block chain layer is generated based at least in part on the block information of the reference block. The multi-layer block chain structure may have one upper block chain layer and may further include a plurality of upper block chain layers. When the multi-layered block chain structure has a plurality of upper block chain layers, after the bottom block chain layer is generated based on the bottom block chain layer, adjacent upper block chain layers may also be generated based on the upper block chain layer successively for each upper block chain layer in the same manner. Specifically, for each upper block chain layer, it may be determined whether or not the upper block chain layer has a reference block that triggers an upper block chain layer generation condition. When there is a reference block that triggers an upper block chain layer generation condition, an adjacent upper block chain layer of the upper block chain layer is generated based at least in part on block information of the reference block. The generation process of the multi-layered block chain structure is described below with reference to fig. 4.

Fig. 4 is a schematic diagram of a multi-layer block chain structure according to one embodiment of the present description. Four block chain layers are schematically shown in fig. 4, but the present embodiment does not limit the number of block chain layers. In FIG. 4, B _ij Representing the jth block of the ith block chain layer, e.g. B ₁₁ Representing the first block of the first block chain layer (i.e., the bottom block chain layer), B ₂₂ Representing a second block of a second block chain layer (i.e., a first upper block chain layer).

In FIG. 4, B ₁₁ For creating a block, the created block refers to the first block of the underlying block chain layer. With the increase of transaction data processed by the block chain system, the blocks B of the bottom block chain layer are sequentially generated ₁₂ To B ₁₁₁ Etc. Each upper block chain layer is generated based on a lower block chain layer of the upper block chain layer. For example, a first upper block chain layer is generated based on the bottom block chain layer, and a second upper block chain layer is generated based on the first upper block chain layer. The first block of each upper block chain layer may be referred to as a header block (e.g., header block B ₂₁ 、B ₃₁ 、B ₄₁ )。

In one example, the first block of each block chain layer may be determined to be the first reference block of the block chain layer (e.g., block B ₁₁ 、B ₂₁ 、B ₃₁ ) Then, a header block (e.g., block B) of an upper block chain layer of the block chain layer is generated based on the reference block ₂₁ 、B ₃₁ 、B ₄₁ ). The header block of the upper block chain layer may be made to include the hash value of the first block of the lower block chain layer of the upper block chain layer for each upper block chain layer. The header blocks of the respective upper block chain layers may also be generated based on the generated blocks, e.g., the header blocks of the respective upper block chain layers may include hash values of the generated blocks. In another example, the header blocks of each upper block chain layer may be multiplexed when they are generated The generation block is created to generate a header block of the upper block chain layer. By having each header block generated based on the creation block, it is possible to quickly locate from the creation block to each upper block chain layer.

Although a case where the head blocks of each upper block chain layer correspond to the created blocks is shown in fig. 4, in another example, a block whose number of blocks with the first block of the block chain layer reaches a specified number of blocks or whose time interval between the generation time and the generation time of the first block reaches a specified time interval may be determined as the first reference block of the block chain layer for each block chain layer. For example, the example shown in fig. 4 may be simply modified such that each upper block chain layer may not include the block B shown in fig. 4 ₂₁ 、B ₃₁ 、B ₄₁ Thereby B shown in FIG. 4 ₂₂ 、B ₃₂ 、B ₄₂ As the first block. As an example, block B of the underlying block chain layer may be ₁₃ The first reference block determined to be the bottom block chain layer may then be based on B ₁₃ To generate a first upper layer block of the first upper layer block chain layer. In this example, the first upper chunk of each upper chunk chain layer may include a hash value of the created chunk to be quickly located from the bottom chunk chain layer to each upper chunk chain layer or from each upper chunk chain layer to the bottom chunk chain layer.

After determining the first reference block of each block chain layer, other reference blocks of each block chain layer may be determined with a specified number of blocks from the previous reference block or a specified time interval between the generation time and the generation time of the previous reference block as a trigger condition. For example, each reference block of each block chain layer may be determined using the procedure described below with reference to fig. 5A to 6B, and an upper layer block may be generated corresponding to the determined reference block. The generation of each block chain layer can be executed in real time and in parallel, and each upper block chain layer generated at a proper time can also be generated according to the occupation condition of the computing resources of the system after each block of the lower block chain layer is generated.

Fig. 5A and 5B illustrate examples of generating an upper block chain layer asynchronously to a lower block chain layer. After each block in each block chain layer is generated, at a proper time (such as when the system resource is abundant), traversing the blocks in the block chain layer, which do not execute the reference block determining process, i.e. one-to-one querying each block, to determine whether the currently queried block is the reference block triggering the generation condition of the upper block chain layer. After the reference block is determined, a corresponding upper layer block of the upper layer block chain layer may be generated. For example, after each bottom layer block is generated, each generated bottom layer block may be traversed for an appropriate period of time to determine a reference block that triggers generation of an upper layer block in the first upper layer 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 one embodiment of the present specification.

As shown in fig. 5A, at block 5A02, for each block chain layer, the number of blocks between the currently queried block and the last reference block of that block chain layer is determined. Then at block 5a04, it is determined whether the number of blocks between the currently queried block and the last reference block reaches a specified number. In the present embodiment, a block between a block and another block includes the other block, and accordingly, the other block should be counted in referring to the number of blocks between the block and the other block. For example, B ₁₁ And B ₁₃ The block between includes B ₁₂ And B ₁₃ Correspondingly, B ₁₁ And B is connected with ₁₃ The number of blocks in between is 2.

If the number of blocks between the current queried block and the last reference block reaches the specified number, then the current queried block is determined to be the reference block at block 5A 06. The number of blocks between the reference blocks of each block chain layer may be set, for example, for the example in fig. 4, the number of blocks between the reference block and the previous reference block may be 2. If the number of blocks between the current queried block and the previous reference block reaches the set specified number, the current queried block can be determined as the reference block.

If the number of blocks between the current queried block and the last reference block does not reach the designated number, then at block 5A08, the next block of the block chain layer is taken as the current queried block, and the above process is performed again.

Fig. 5B is another example flowchart of a reference block determination process in a method for generating a multi-layer block chain structure according to one embodiment of this specification.

As shown in fig. 5B, at block 5B02, for each block chain layer, a time interval between the generation time of the currently queried block and the last reference block of that block chain layer is determined. The generation time of each block may be determined based on the time stamp of the block, for example. Then, at block 5B04, it is determined whether the determined time interval has reached a specified time interval.

If the determined time interval reaches the specified time interval, the currently queried block is determined to be a reference block at block 5B 06. If the determined time interval does not reach the specified time interval, the next block of the block chain layer is taken as the current queried block at block 5B08, and the above procedure is performed again.

Fig. 6A and 6B illustrate an example of generating an upper block chain layer in synchronization with an underlying block chain layer. The method can monitor the blocks in each block chain layer, and when each block chain layer is monitored to have a new block added, the method determines whether the new block is a reference block triggering the generation condition of the upper block chain layer. For full nodes, the newly added block may be a new block, and for lightweight nodes, the newly added block may also be a block obtained from the full nodes. Each block at a lightweight node may include only a block header. The lightweight nodes can locally generate upper block chain layers and upper blocks, and can acquire each upper block chain layer from the total 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 one embodiment of this specification.

As shown in fig. 6A, at blocks 6A02 and 6A04, it is monitored whether each block chain layer has a new block added.

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

If the determined number of blocks reaches the specified number, then the new block is taken as the reference block for the corresponding block chain layer at block 6A 12. If the determined number of blocks does not reach the specified number, then the block chain layer continues to be snooped.

Fig. 6B is another example flowchart of a reference block determination process in a method for generating a multi-layer block chain structure according to one embodiment of this specification.

As shown in fig. 6B, at blocks 6B02 and 6B04, it is monitored whether new blocks are generated for each block chain layer.

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

If the determined time interval reaches the specified number, the new block is taken as the reference block of the corresponding block chain layer at block 6B 12. If the determined time interval does not reach the specified number, then the block chain layer continues to be listened to.

Taking fig. 4 as an example, in the multi-layer block chain structure, the reference block of the bottom layer block chain layer is B ₁₁ 、B ₁₃ 、B ₁₅ And the reference block of the first upper block chain layer is B ₂₁ 、B ₂₃ 、B ₂₅ And the reference block of the second upper block chain layer is B ₃₁ 、B ₃₃ Etc.

In the embodiment of the present disclosure, when determining the reference blocks based on whether the number of blocks between the reference block and the previous reference block reaches the specified number, the number of blocks before two adjacent reference blocks in the same block chain layer may be the same or different, and the specified number corresponding to each block chain layer may be the same or different. In addition, when the reference blocks are determined based on the time intervals between the generation times, the generation time intervals before the adjacent two reference blocks of the same block chain layer may be the same or different, and the designated time intervals corresponding to the respective block chain layers may be the same or different. In one example, the specified number or specified time interval corresponding to each reference block of each block chain layer may be the same, or the specified number or specified time interval corresponding to each reference block of each block chain layer may be the same for each block chain layer. When the specified number or the specified time interval corresponding to each reference block of the block chain layer is the same, the specified number or the specified time interval corresponding to each block chain layer can be determined based on a predetermined rule. For example, the number of blocks between adjacent reference blocks of each block chain layer may be incremented in an arithmetic progression. Therefore, the quick positioning among the block chain layers can be realized based on the appointed number or the appointed time interval corresponding to each reference block.

After determining the reference block, a corresponding block of an upper block chain layer of the block chain layer may be generated based on block information of at least a part of blocks from a first block of the block chain layer to all blocks of the reference block. For the bottom block chain layer, the first block is the creation block, and for each upper block chain layer, the first block is the head block of the corresponding upper block chain layer. The tile information may be a hash value of each tile or tile content, or may be part of the content of a tile (e.g., a hash value and a timestamp of the tile or a hash value of a parent tile of the tile and a hash value of the tile). Thus, each block chain layer can be linked with a corresponding lower block chain layer, and link verification can be performed based on the corresponding block information.

In one example, the generated upper layer block may include a hash value of the reference block. Referring to fig. 4, block B of the first upper block chain layer ₂₂ May include a reference block B ₁₃ Is used to generate the hash value of (a). In another example, for each block chain layer, the block contents of the first block of the block chain layer to all blocks of the reference block may be hashed A hash value is calculated and included in the upper layer block corresponding to the reference block. Referring to fig. 4, in generating block B ₂₃ In this case, the slave B can ₁₁ To B ₁₅ Hash the contents of all blocks of (a) to obtain a hash value, and then make block B ₂₃ Including the hash value. In another example, for each block chain layer, hash values of all blocks from a first block to a reference block of the block chain layer may be hashed to obtain a hash value, and an upper block corresponding to the reference block may include the hash value. As shown, the slave B can be paired ₁₁ To B ₁₅ Hash the hash value of all blocks to obtain a hash value, and then let block B ₂₃ Including the hash value. In another example, for each block chain layer, the hash value may be obtained by hashing the contents of the first block of the block chain layer and the reference block, and the block of the upper block chain layer corresponding to the reference block may include the hash value. As shown in fig. 4, for reference block B ₁₅ Can be relative to B ₁₁ And B ₁₅ Hash the block content or hash value of (a) to obtain a hash value, and then make the corresponding block content or hash value correspond to B ₁₅ The generated upper layer block B ₂₃ Including the hash value. Further, the upper layer block generated corresponding to the corresponding reference block may further include a plurality of hash values determined using the above example.

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

In another example, the block index information of the reference block and the corresponding upper layer block may also be stored. The block index information facilitates positioning between the various block chain layers. The block index information may be, for example, a reference block or a block height of an upper layer block corresponding to the reference block. The block index information may be included in a reference block, and the reference block may include a field that does not participate in a hash value operation of the reference block, and a block height of a corresponding upper layer block may be written into the field after the upper layer block is generated. The block index information may be included in an upper layer block corresponding to the reference block. For example, the block header of the upper layer block may be made to include a reference block high field, and when the corresponding upper layer block is generated, the block high of the corresponding reference block may be written into the reference block high field. The block index information may also be included in a next block of the upper layer block corresponding to the reference block. The block height of the reference block of the upper layer block may be written into the block header of the next block when the next block of the upper layer block is generated. In another example, an index database may be further provided, and when an upper layer block is generated corresponding to the reference block, block index information of the upper layer block and the reference block may be stored in the index database.

The application of the multi-layered block chain structure generated in the embodiment of the present specification will be described below with reference to fig. 7 to 11. The following embodiments may 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 chaining structure according to one embodiment of the present description. The trust point indicates the highest block-level verified bottom-level block in the bottom-level block chain. The trust point indicates that among the bottom level blocks stored at the node, the bottom level blocks indicated from the originating block to the trust point have been verified, i.e., the bottom level blocks are trusted blocks. The initial value of the trust point may be an originating block, e.g., for lightweight nodes that have never performed block verification, the trust point points to the originating block. The trust point may be stored at the lightweight node, which may update the trust point to the verified underlying block that is highest in the current block after performing a batch of block verifications, e.g., may store the block height or hash value of the verified underlying block that is highest in the current block in the trust point field. As an application of the trust point, when the lightweight node performs SPV verification on a transaction to be verified, if the underlying block where the transaction to be verified is located before the trust point (i.e., the underlying block is a trusted underlying block that has been verified), the existence of the transaction to be verified may be verified, and after the existence verification passes, it may be determined that the transaction to be verified has been executed correctly.

As shown in FIG. 7, at block 720, a verification path between the verified underlying block indicated by the current trust point and the target underlying block is determined based on the multi-layer block chain structure. The lightweight node may obtain, from the full-scale node, blocks of each block chaining layer between the verified block indicated by the current trust point and the target underlying block when the trust point needs to be updated, and add the obtained blocks to each block chaining layer locally. The lightweight node may then determine a validation path based on the locally stored multi-tier block chain structure. Referring to FIG. 4, the current trust point may point to block B of the underlying block chain layer ₁₄ . The target underlying block may be, for example, B in FIG. 4 ₁₁₂ 。

In one example, the trust point may be updated as the SPV is validated for the transaction to be validated, and the target floor tile may be determined based on the floor tile to be validated for the transaction to be validated. Fig. 8 is a flow chart of a method of SPV verification of a transaction to be verified according to one embodiment of the present description.

Referring to FIG. 8, at block 802, a block of the bottom layer to be verified is determined in which the transaction to be verified is located. When a lightweight node wants to know whether a transaction is executed correctly, the underlying block where the transaction is located can be obtained from the full-scale node. The full-scale node may send the block height of the underlying block where the transaction is located to the lightweight node. The lightweight node may then SPV verify the transaction. SPV verification may include correctness verification and presence verification (or referred to as presence attestation). The correctness verification may be performed by verifying the integrity of the link from the originating block to the underlying block to be verified, for proving that the transaction to be verified is correct. Presence verification for verifying that the transaction to be verified is indeed present in the block to be verified may be performed based on any presence verification method. For example, a query path of a transaction to be verified in the MPT tree may be obtained based on the MPT tree, and whether the transaction root hash is consistent with the transaction root hash in the chunk header may be verified based on the data nodes of each MPT tree in the obtained query path, and when the two are consistent, it may be determined that the transaction to be verified is actually present in the underlying chunk to be verified.

After determining the underlying block to be verified, at block 804, a determination is made as to whether the underlying block to be verified is located before a trust point. That is, it is determined whether the underlying block to be verified is a trusted underlying block. Whether the transaction to be verified is prior to the trust point may be determined by comparing the block height of the block to be verified with the verified bottom layer block height to which the trust point points.

When the bottom layer block to be verified is positioned in front of the trust point, the link between the creation block and the bottom layer block to be verified where the transaction to be verified is positioned is correct. Thus, at block 808, a proof of existence may be made for the transaction to be validated, and at block 810, a determination may be made as to whether the proof of existence passed. When the underlying block to be verified is not located before the trust point, the trust point may be updated to a target underlying block with a block height not less than the underlying block to be verified at block 806 using the trust point update method described in embodiments of the present disclosure. At this time, any bottom layer block with a block height not smaller than the bottom layer block where the transaction to be verified is located can be used as the target bottom layer block. After updating the trust point, a proof of existence may be made for the transaction to be verified at block 808.

If the presence document passes, then at block 812, it may be determined that the transaction to be validated has been performed correctly. If the presence document does not pass, then at block 814, it may be determined that the transaction to be validated was not performed correctly.

The verification path refers to the path from the current trust point verification to the target underlying block. The validation path may be via any block chaining layer. For example, as shown in FIG. 4, from the current trust point TP to the target floor block B ₁₁₂ The verification path between them may be B ₁₅ →B ₂₃ →B ₃₂ →B ₃₃ →B ₂₅ →B ₂₆ →B ₁₁₁ →B ₁₁₂ 。

The verification path may be determined via only the bottom block chain layer, and may also be determined via at least one upper block chain layer. Since at least one block is spaced between two adjacent reference blocks of each block chain layer, an upper block of the block chain layer corresponds to a block that is "skipped" by the spacing. Thus, when determining the verification path through 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 (i.e., the path that passes the least block) may be selected as the verification path from all paths between the verified underlying block and the target underlying block to which the current trust point points.

In determining a verification path through an upper block chain layer, there is a path loss when ascending 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, there may be a case where the number of blocks through which a path passes increases due to rising or falling between block chain layers. Thus, if the number of blocks between the verified underlying block and the target underlying block indicated by the current trust point is small, the verification path may be longer than the verification path determined only by the underlying block chain layer if the verification path is longer through the upper block chain layer. Thus, in one example, the validation path may be determined via at least one upper block chaining layer when there are at least two bottom reference blocks before the validated bottom block indicated by the current trust point and the target bottom block. In another example, the number of floor blocks between the determined target floor block and the verified floor block indicated by the current trust point may be greater than the first predetermined number. Thus, the number of bottom level blocks between the target bottom level block and the verified bottom level block to which the current trust point points is sufficiently large that the verification path can be determined via at least one upper block chaining layer each time the trust point is updated. When the number of bottom layer blocks between the target bottom layer block and the verified bottom layer block indicated by the current trust point is greater than a second predetermined number (the second predetermined number is not less than the first predetermined number), the verification path can be determined through a plurality of upper layer block chain layers, so that the number of blocks included in the verification path can be reduced as much as possible, and the verification efficiency can be improved.

The verification path can be determined based on a first block number and a second block number, the first block number being a block between two adjacent reference blocks of each block chain layerThe second number of blocks is the number of bottom blocks between the target bottom block and the verified bottom block. In one example, there may be the same number of blocks between two adjacent reference blocks in each block chain layer, i.e. the number of first blocks between two adjacent reference blocks is equal. In this example, assuming that the first block number is N, the number of bottom blocks existing between two adjacent blocks in the L-layer block chain layer is N ^L-1 And each. For example, referring to FIG. 4, there is 2 between two adjacent blocks in the second block chain layer (i.e., the first upper block chain layer) ^2-1 And the bottom layer blocks. The rising point of the block chain layer through which the verification path passes may be determined based on the first block number and the second block number, and for each block through which the verification path passes, if a block subsequent to the block is a block of the block chain layer of the adjacent upper layer, the block is referred to as the rising point. The sequence number (% represents remainder operation) of the block corresponding to the rising point of the L-th block chain layer in the verification path in the L-th block chain layer is:

X+[N-(X-1)％N]％N，

Wherein B is _LX Is the first block of the L-th block chain layer in the verification path. For example, in the verification path shown in FIG. 4, for the second block chain layer (i.e., the first upper block chain layer), the rising point is 3+ [2- (3-1)% 2]%2, the result is 3, i.e. X has a value of 3, so the third block B in the second block chain layer ₂₃ Is the rising point.

The drop point of each block chain layer through which the verification path passes may also be determined based on the first block number and the second block number. For each block through which the verification path passes, if the block subsequent to the block is a block of the lower block chain layer, the block is referred to as a drop point. Assume that the verified block indicated by the current trust point is B _1j (the j-th block of the bottom layer block chain layer), the target bottom layer block is B _1k (the kth block of the bottom layer block chain layer). The sequence number of the block corresponding to the descent point in the L-th layer block chain layer is:

(k-k％N)/N ^L-1

if a block meets both the rising point and the falling pointUnder the condition, the block is determined as the falling point (e.g. B ₃₃ )。

After determining the rising and falling points in each block chain layer, the blocks between the rising and falling points 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 ₁₅ 、B ₂₃ The drop points are respectively B ₃₃ And B ₂₆ 。

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 shortest path between the verified bottom layer block pointed by the current trust point and the target bottom layer block, the maximum number of layers of the passed block chain layer can be made not to exceed the number of first blocks. For example, taking fig. 4 as an example, the verification path B determined by the above embodiment ₁₅ →B ₂₃ →B ₃₂ →B ₃₃ →B ₂₅ →B ₂₆ →B ₁₁₁ →B ₁₁₂ Comprising 8 blocks. If the maximum number of block chain layers passed by the verification path is not more than the first block number (i.e. 2) of the two adjacent reference blocks, the maximum number of block chain layers passed by the verification path is the second block chain layer (i.e. 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 blocks. That is, the verification path is shortened with respect to the case when the number of passing block chain layers exceeds the first interval block number.

For the case where the first block numbers between adjacent two reference blocks in the respective block chain layers are not equal, the first block numbers may be determined based on the block index information. Because the block index information includes the index relation between the reference block and the corresponding upper layer block, the reference block in each layer of block chain layer between the verified bottom layer block and the target bottom layer block can be determined based on the block index information, and the first block number between two adjacent reference blocks in each layer of block chain layer can be determined. After determining the first block number, when determining the verification path through the upper block chain layer, blocks of each layer block chain layer that should be included in the verification path may be calculated based on the first block number between the adjacent two reference blocks and the second block number between the verified bottom layer block and the target bottom layer block.

If the number of blocks between two adjacent reference blocks is not exactly equal, a verification path may be determined based on block index information indicating indexes between each reference block and a corresponding previous layer block. The reference block in each block chain layer may be determined based on the block index, and then after rising to each upper block chain layer, whether the next block of the block chain layer has reached or exceeded the target bottom layer block may be determined heuristically. If the bottom block is reached or exceeded, the block chain layer is discarded and the block chain layer is lowered to the lower block chain layer to continue searching.

Since index relationships between the respective reference blocks and the corresponding upper layer blocks are stored in the block index information, it is possible to determine whether the respective upper layer blocks in the upper layer block chain layer have actually exceeded the target lower layer block based on the block index information. For example, the block index information may be included in each reference block, and each reference block may include an upper layer block index field, for example, a block height or hash value of an upper layer block corresponding to the reference block may be written into the upper layer block index field of the reference block. When determining the verification path, each bottom layer block can be queried from the verified bottom layer block pointed by the current trust point, when the index field of the upper layer block of the queried block is empty, the queried block is not the reference block of the corresponding block chain layer, and when the index field of the upper layer block is not empty, the queried block is indicated to be the 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 the query is continued by ascending to the adjacent upper layer block chain layer. When the upper block chain layer is queried, if it is determined that a certain upper block is a reference block in the corresponding upper block chain layer, because the upper block comprises an index of a corresponding lower block, whether a bottom block capable of being positioned by the upper block exceeds a target bottom block can be determined based on the index of the corresponding lower block. If the target bottom layer block is not exceeded, the block chain layer can be continuously lifted to the upper layer block chain layer, and if the target bottom layer block is exceeded, the block chain layer is rolled back to the previous upper layer block of the upper layer block chain layer and is lowered to the lower layer block chain layer. After dropping 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, it may be continued to determine whether the next block of the dropped lower block exceeds the target bottom block. If the next block does not exceed the target underlying block, then the next block of the underlying block may be determined to be a block in the verification path. If the next block of the lower level block has exceeded the target lower level block, then the descent continues until the lower level block chain is descended. And executing the process until the target bottom layer block is queried, and determining the verification path.

After determining the verification path, at block 740, for each block in the verification path, it is verified whether the link between that block and the previous block is correct. The link verification process may be determined based on the link relationships between the various tiles. For the blocks in the same chain layer in the verification path, a parent hash is stored in each block, so that whether the link between each block and the previous block is correct can be verified based on the block information of the previous block. For example, taking the verification path indicated by the solid arrow in FIG. 4 as an example, B ₁₄ And B ₁₅ 、B ₃₂ And B ₃₃ Respectively positioned at the bottom layer block chain layer and the second upper layer block chain layer, B ₁₄ Is B ₁₅ Parent block of B ₃₂ Is B ₃₃ Is included in the parent block of (a). Thus can be based on B ₁₅ Parent hash sum B in (B) ₁₄ Validating B by block information ₁₄ And B is connected with ₁₅ Whether the link between them is correct. For adjacent blocks located at different block chain layers, since an upper layer block is generated based on a corresponding reference block of a lower layer, it is possible to verify whether a link between the two adjacent blocks is correct based on block information of the corresponding reference block. Taking the verification path shown in FIG. 4 as an example, B ₁₅ And B is connected with ₂₃ 、B ₃₂ Respectively located at different positionsBlock chain layer, B ₁₅ Is B ₂₃ Reference block, B of (a) ₂₃ Is B ₃₂ Is included in the reference block of (a). Due to B ₂₃ Is based at least on B ₁₅ B of block information generation of (a) ₃₂ Is based at least on B ₂₃ Generated based on block information of B ₁₅ And B ₂₃ Validating B by block information ₁₅ And B ₂₃ Previous link and based on B ₂₃ And B ₃₂ Validating B by block information ₂₃ And B ₃₂ A previous link. A specific link verification process will be described below with reference to fig. 9.

It should be noted that, the link verification process between the blocks in the verification path may be performed after the verification path is determined, or may be performed during the verification path is determined. For example, for the verification path shown in FIG. 4, a determination B may be made ₁₄ The next block (i.e. B) ₁₅ ) At the time, verify B ₁₄ And B is connected with ₁₅ Links between them, then determine B ₁₅ Is the next block of the block. At determination B ₁₅ The next block (i.e. B) ₂₃ ) Thereafter, verify B ₁₅ And B is connected with ₂₃ A link between them. In the determining process of the verification path and the link verification process, when the link before any two blocks is incorrect, the link in the verification path can be determined to be incorrect.

Then, at block 760, it is determined whether the links between the various blocks in the validation path are all correct. When the links between the blocks in the validation path are all correct, the trust point is updated to indicate the target underlying block at block 780.

Each block in the verification path may have stored therein a first hash value generated based at least on block information of a previous block. The first hash value may be a parent hash of the block if a previous block of the block is at the same block chaining layer as the block. The first hash value may be obtained by hashing based at least in part on block information of a previous block if the previous block is at a different block chaining layer than the block. At this time, the link verification may be performed using an example as shown in fig. 9. Fig. 9 is a flow diagram of a link verification process in a method for updating trust points in a blockchain in accordance with an embodiment of the present description.

As shown in fig. 9, at block 902, a hash operation is performed based at least on the block information of the previous block to obtain a second hash value. Then, at block 804, a determination is made as to whether the resulting second hash value is consistent with the first hash value in the block. When the two agree, at block 906, it is determined that the link between the block and the previous block is correct. When the two are not identical, it is determined at block 908 that the link between the block and the previous block is incorrect.

When the previous block of the block and the block are located in the same block chain layer, a hash operation can be performed on the block header of the previous block to obtain a second hash value. The second hash value may then be compared for consistency with the parent hash in the chunk. For example, taking the verification path indicated by the solid arrow in FIG. 4 as an example, due to B ₁₄ Is B ₁₅ And thus can be used for B ₁₄ Performing hash operation on the block information of (a) to obtain a hash value, and comparing the obtained hash value with B ₁₅ Consistency of the parent hash stored in the storage. When the two are consistent, B can be determined ₁₄ And B ₁₅ The link between them is correct.

When the previous block of the block and the block are located in different block chain layers, the previous block is a reference block of the block, and thus a hash operation can be performed based at least in part on the block information of the previous block to obtain a second hash value. For example, the upper layer block may include a hash value of the corresponding reference block. In this example, if a previous block of a block in the verification path is located in the lower block chain layer, the block information of the previous block may be hashed to obtain the second hash value. With B in the verification path shown in FIG. 4 ₁₅ And B is connected with ₂₃ For example, can be applied to B ₁₅ Performing hash operation on the block header of the block to obtain a second hash value. The resulting second hash value may then be compared to B ₂₃ B stored in (B) ₁₅ Whether the hash values of (a) are consistent, if so, then B can be determined ₁₅ And B ₂₃ The link between them is correct. For another example, when an upper layer block is generated corresponding to a reference block, it is possible to perform a hash operation on block information of all blocks from a first block to the reference block in a block chain layer in which the reference block is located, and store the obtained hash value as a first hash value in the generated upper layer block. In this example, if a previous block of a block in the verification path is located in the lower block chain layer, hash operations may be performed on all block information from a first block to the previous block in the block chain layer in which the previous block is located to obtain the second hash value. With B in the verification path shown in FIG. 4 ₁₅ And B is connected with ₂₃ For example, can be applied to B ₁₁ 、B ₁₂ 、B ₁₃ 、B ₁₄ And B ₁₅ Performing a hash operation on the block information of (b) to obtain a second hash value. The resulting hash value may then be compared to B ₂₃ The first hash value stored in the database, if the two hash values are consistent, B can be determined ₁₅ And B is connected with ₂₃ The link between them is correct.

After the links between the blocks in the verification path are verified as correct, the correctness of the target underlying block may also be verified. The correctness of the target underlying block may be performed by verifying whether it has passed the full network consensus. FIG. 10 is a flowchart of a method for updating trust points in a blockchain in accordance with another embodiment of the present specification.

As shown in fig. 10, at block 1002, a verification path between a verified underlying block indicated by a current trust point and a target underlying block is determined based on a multi-layer block chain structure. After determining the verification path, at block 1004, for each block in the verification path, it is verified whether the link between that block and the block preceding the block is correct. Then at block 1006, a determination is made as to whether the links between the various blocks in the path are verified as being correct.

If the links between each block and the previous block are verified as correct, then at block 1008, a determination is made as to whether the target underlying block is correct. The example shown in fig. 11 can be referred to verify that the target underlying tile is correct.

FIG. 11 is a flow diagram of a target underlying block verification process in a method for updating trust points in a multi-layer block chaining structure according to one embodiment of the present disclosure.

As shown in FIG. 11, at block 1102, a plurality of target underlying block information for a target underlying block is obtained from a plurality of full volume nodes in a blockchain system.

Then, at block 1104, when there is no less than a quorum of consistent target underlying block information in the plurality of target underlying block information, the target underlying block is determined to be correct. When there is no less than a quorum of consistent target underlying block information, it can be determined that the target underlying block has been fully network-aware and, thus, can be determined to be correct.

When the target underlying block is determined to be correct, the trust point is updated to indicate the target underlying block at block 1010. If the links between each block of the verification path and the previous block are not exactly correct or the target underlying block is determined to be incorrect, then the target underlying block is indicated as a non-trusted block. In this case, the target underlying block may be redetermined and the trust point update process performed.

When the multi-layer block chain structure is applied to a centralized blockchain-like system, after each block in each bottom layer block chain layer is generated, the block can be sent to a trusted third party server, and the third party server can use a private key of the third party server to carry out signature authentication on the block. When verifying whether the target bottom layer block is correct, the signature for the target bottom layer block can be obtained from the third party server, then the obtained signature of the target bottom layer block is verified by using the public key of the third party server, and when the verification is passed, the target bottom layer block can be determined to be correct.

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

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

The bottom block chain layer generation 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 generation unit 1220 generates an upper block chain layer based on the lower block chain layer according to the upper block chain layer generation condition. The upper block chain layer generation unit 1220 includes a reference block determination module 1221 and an upper block chain layer generation module 1222. The reference block determination module 1221 determines whether there is a reference block in the bottom layer block chaining layer that triggers the upper layer block chaining layer generation condition. The upper layer block chain layer generation condition may include that the number of blocks between the reference block and the previous reference block reaches a specified number, and may further include that a time interval between the generation time of the reference block and the generation time of the previous reference block reaches a specified time interval.

In one example, the reference block determining unit 1220 may traverse blocks in respective block chain layers in the multi-layer block chain structure to determine a reference block satisfying an upper block chain layer generation condition. In another example, the reference block determining unit 1220 may determine whether a newly generated block is a reference block satisfying an upper block chain layer generation condition for each block chain layer in the block chain.

The upper block chain layer generation module 1222 generates a corresponding upper block of the upper block chain layer based at least in part on block information of a reference block that triggers an upper block chain layer block generation condition in response to the existence of the reference block in the lower block chain layer.

The multi-layer block chain structure may include a plurality of upper block chain layers. In this example, the upper block chain layer generation unit 1220 may generate an adjacent upper block chain layer of 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. Specifically, the reference block determining module 1221 may determine, for each upper block chain layer, whether or not there is a reference block in the upper block chain layer that triggers an upper block chain layer generation condition. When there is a reference block that triggers an upper block chain layer generation condition, the upper block chain layer generation module 1222 may generate a corresponding upper block of an adjacent upper block chain layer of the upper block chain layer based at least in part on block information of the reference block.

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

The blockchain generating device may further include a blockindex information storage unit (not shown in the drawings). The block index information storage unit stores block index information of a reference block and a corresponding upper layer block. In one example, the block index information storage unit may store the block index information in the reference block or an upper block corresponding to the reference block, and may also store the block index information in a next block of the upper block. In another example, the block index information storage unit may further store the block index information in an index database.

FIG. 13 is a block diagram of an apparatus for updating trust points in a multi-layer block chaining structure according to one embodiment of the present description. As shown in fig. 13, the trust point updating apparatus 1300 includes a verification path determining unit 1310, a link verifying unit 1320, a target underlying block verifying unit 1330, and a trust point updating unit 1340.

The verification path determination unit 1310 determines a verification path between the verified underlying block indicated by the current trust point and the target underlying block 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 block chain layer when there are reference blocks of at least two bottom block chain layers between the target bottom block and the verified bottom block.

In one example, the first number of blocks between two adjacent reference blocks in each block chain layer may be equal, and the number of upper block chain layers through which the verification path passes may not exceed the first number of blocks.

In one example, the verification path determining unit 1310 may determine the verification path based on a first block number, which is a block number between two adjacent reference blocks of each block chain layer, and a second block number, which is a block number between the target underlying block and the verified underlying block. The first number of interval blocks between adjacent two reference blocks of each block chain layer may be determined based on the block index information.

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

After determining the verification path, the link verification unit 1320 verifies, for each block in the verification path, whether the link between the block and the block preceding the block is correct. The target underlying block verification unit 1330 verifies whether the target underlying block is correct. The trust point updating unit 1340 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 correct.

In another example, the trust point updating means may not include the target underlying block verification unit 1330. In this example, the trust point updating unit 1340 may update the target underlying block as a trust point when the links between the blocks in the verification path are all correct.

Fig. 14 is a block diagram of a link verification unit in the apparatus for updating a trust point of a 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 chunk in the validation path includes a first hash value of a previous chunk.

The hash module 1321 performs a hash operation based at least in part on the locally acquired block information of the previous block to obtain a 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 block diagram of a target underlying block verification unit in the apparatus for updating trust points in a multi-layer block chaining structure shown in fig. 13. As shown in fig. 15, the target underlying block verification unit 1330 includes a hash operation module 1331 and a link verification module 1332.

The target underlying block information acquisition module 1321 acquires a plurality of target underlying block information for a target underlying block from a plurality of full nodes in the blockchain system. The target underlying block verification module 1322 determines whether the target underlying block is correct when there is no less than a quorum of consistent target underlying block information in the plurality of target underlying block information.

Embodiments of a method and apparatus for generating a multi-layered block chain structure according to embodiments of the present specification are described above with reference to fig. 1 to 6 and 12, and trust point updating methods and apparatuses are described with reference to fig. 7 to 11, 13 to 15. The details mentioned in the above description of the method embodiments apply equally to the embodiments of the device of the present description embodiments.

The multi-layer block chain structure generating device and the trust point updating device in the embodiments of the present disclosure may be implemented by using hardware, or may be implemented by using software or a combination of hardware and software. The various embodiments in this specification are described in a progressive manner, with identical and similar parts being referred to each other.

The multi-layer block chain structure generating device and the trust point updating device in the embodiments of the present disclosure may be implemented by using hardware, or may be implemented by using software or a combination of hardware and software. Taking software implementation as an example, the device in a logic sense is formed by reading corresponding computer program instructions in a memory into the memory by a processor of the device where the device is located. In the embodiment of the present specification, the multi-layered block chain structure generating means and the trust point updating means may be implemented using a computing device, for example.

FIG. 16 is a block diagram of a computing device for implementing a multi-tier block chaining structure generation method or a trust point update method in accordance with one embodiment of the present description. As shown in fig. 16, computing device 1600 includes a processor 1610, a memory 1620, a memory 1630, a communication interface 1640, and an internal bus 1650, and processor 1610, memory (e.g., non-volatile memory) 1620, memory 1630, and communication interface 1640 are connected together via bus 1650. According to one embodiment, the computing device 1600 may include at least one processor 1610, the at least one processor 1610 executing at least one computer readable instruction (i.e., elements described above implemented in software) stored or encoded in a computer readable storage medium (i.e., memory 1620).

In one embodiment, computer-executable instructions are stored in memory 1620 that, when executed, cause at least one processor 1610 to: generating blocks of a bottom block chain layer in the multi-layer block chain structure based on the transaction data; and generating an upper block chain layer based on the bottom block chain layer according to the upper block chain layer generation conditions, wherein generating the upper block chain layer based on the bottom block chain layer according to the upper block chain layer generation conditions comprises: determining whether a reference block triggering the generation condition of the upper block chain layer exists in the lower block chain layer; in response to a reference block in the bottom block chain layer existing that triggers an upper block chain layer generation condition, a corresponding upper block of the upper block chain layer is generated based at least in part on block information of the reference block.

In another embodiment, computer-executable instructions are stored in memory 1620 that, when executed, cause at least one processor 1610 to: determining a verification path between the verified bottom layer block indicated by the current trust point and the target bottom layer block based on the multi-layer block chain structure; verifying, for each block in the verification path, whether a link between the block and a block preceding the block is correct; and updating the target bottom layer block as a trust point when links among all blocks in the verification path are correct.

It should be appreciated that the computer-executable instructions stored in the memory 1620, when executed, cause the at least one processor 1610 to perform the various operations and functions described above in connection with fig. 1 through 6 and 12, or the various operations and functions described with reference to fig. 7 through 11, 13 through 15, in various embodiments of the present specification.

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 (i.e., elements implemented in software as described above) that, when executed by a machine, cause the machine to perform the various operations and functions described above in connection with fig. 1 through 6 and 12, or the various operations and functions described with reference to fig. 7 through 11, 13 through 15, in various embodiments of the present specification.

In particular, a system or apparatus provided with a readable storage medium having stored thereon software program code implementing the functions of any of the above embodiments may be provided, and a computer or processor of the system or apparatus may be caused to read out and execute instructions stored in the readable storage medium.

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

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

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

Not all steps or units in the above-mentioned flowcharts and system configuration diagrams are necessary, and some steps or units may be omitted according to actual needs. The order of execution of the steps is not fixed and may be determined as desired. The apparatus structures described in the above embodiments may be physical structures or logical structures, that is, some units may be implemented by the same physical entity, or some units may be implemented by multiple physical entities, or may be implemented jointly by some components in multiple independent devices.

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

The alternative implementation manner of the embodiment of the present specification is described in detail above with reference to the accompanying drawings, but the embodiment of the present specification is not limited to the specific details of the foregoing implementation manner, and various simple modifications may be made to the technical solutions of the embodiment of the present specification within the scope of the technical concept of the embodiment of the present specification, and these simple modifications all fall within the protection scope of the embodiment of the present specification.

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

Claims

1. A method for updating a trust point in a multi-layer block chain structure comprising an underlying block chain layer, blocks of the underlying block chain layer being generated based on transaction data, and at least one upper block chain layer, upper blocks of the at least one upper block chain layer being generated based at least in part on block information of reference blocks in a lower block chain layer of the upper block chain layer, the trust point indicating a block-highest, verified underlying block in the underlying block chain layer,

The method comprises the following steps:

determining a verification path between the verified bottom layer block indicated by the current trust point and the target bottom layer block based on the multi-layer block chain structure;

verifying, for each block in the verification path, whether a link between the block and a block preceding the block is correct; and

and updating the target bottom layer block as a trust point when links among all blocks in the verification path are correct.

2. The method of claim 1, wherein determining a verification path between a verified underlying tile indicated by a current trust point and a target underlying tile based on the multi-layer block chain structure comprises:

the verification path is determined via at least one upper block chain layer when there are at least two bottom reference blocks between the target bottom block and the verified bottom block.

3. The method of claim 2, wherein a first number of blocks between adjacent two reference blocks in each block chain layer in the multi-layer block chain structure is equal, the number of upper block chain layers through which the verification path passes not exceeding the first number of blocks.

4. The method of claim 2, wherein determining a verification path between the verified underlying tile indicated by the current trust point and the target underlying tile based on the multi-layer block chain structure comprises:

The verification path is determined based on a first number of blocks, which is the number of blocks between two adjacent reference blocks of each block chain layer, and a second number of blocks, which is the number of bottom layer blocks between the target bottom layer block and the verified bottom layer block.

5. The method of claim 4, wherein a first number of blocks between adjacent two reference blocks of the respective block chain layers is determined based on block index information indicating indexes of the respective reference blocks and corresponding upper layer blocks.

6. The method of claim 1, wherein determining a verification path between a verified underlying tile indicated by a current trust point and a target underlying tile based on the multi-layer block chain structure comprises:

the validation path is determined based on block index information indicating indexes between respective reference blocks and corresponding upper layer blocks.

7. The method of claim 1, further comprising:

verifying whether the target underlying block is correct,

when links between blocks in the verification path are correct, updating the target underlying block to a trust point includes:

And updating the target bottom layer block as a trust point when links among all blocks in the verification path are correct and the target bottom layer block is verified to be correct.

8. The method of claim 7, wherein verifying whether the target floor tile is correct comprises:

acquiring a plurality of target bottom layer block information of the target bottom layer block from a plurality of total nodes in a block chain system; and

and when consistent target bottom layer block information not lower than the legal quantity exists in the target bottom layer block information, determining that the target bottom layer block is correct.

9. The method of claim 1, wherein each block in the verification path includes a first hash value generated based at least on block information of the previous block, verifying whether a link between the block and the previous block of the block is correct includes:

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

based on the consistency between the second hash value and the first hash value, whether the link between the block and the previous block is correct is verified.

10. The method of any of claims 1-9, wherein the target floor tile has a block height that is not less than a floor tile to be verified in which a transaction to be verified to be SPV verified is to be performed.

11. An apparatus for updating a trust point in a multi-layer block chain structure, the multi-layer block chain structure comprising an underlying block chain layer and at least one upper block chain layer, blocks of the underlying block chain layer generated based on transaction data, upper blocks of the at least one upper block chain layer generated based at least in part on block information of reference blocks in a lower block chain layer of the upper block chain layer, the trust point indicating a block highest verified underlying block in the underlying block chain layer,

the device comprises:

a verification path determining unit for determining a verification path between the verified bottom layer block indicated by the current trust point and the target bottom layer block based on the multi-layer block chain structure;

a link verification unit for verifying, for each block in the verification path, whether a link between the block and a block preceding the block is correct; and

and the trust point updating unit is used for updating the target bottom layer block into the trust point when the links among all the blocks in the verification path are correct.

12. The apparatus of claim 11, wherein the verification path determination unit determines the verification path via at least one upper block chain layer when there are at least two bottom reference blocks between the target bottom block and the verified bottom block.

13. The apparatus of claim 12, wherein a first number of blocks between two adjacent reference blocks in each block chain layer is equal, the number of upper block chain layers through which the verification path passes does not exceed the first number of blocks.

14. The apparatus of claim 12, wherein the verification path determining unit determines the verification path based on a first block count and a second block count, the first block count being a block count between two adjacent reference blocks of each block chain layer, the second block count being a floor block count between the target floor block and the verified floor block.

15. The apparatus of claim 14, wherein a first number of blocks between two adjacent reference blocks of the respective block chain layer is determined based on block index information indicating indexes of the respective reference blocks and corresponding upper layer blocks.

16. The apparatus of claim 11, wherein the verification path determining unit determines the verification path based on block index information indicating indexes between respective reference blocks and corresponding upper layer blocks.

17. The apparatus of claim 11, further comprising:

a target bottom layer block verification unit for verifying whether the target bottom layer block is correct;

the trust point updating unit updates the target underlying block to a trust point when links between blocks in the verification path are correct and the target underlying block is verified to be correct.

18. The apparatus of claim 17, wherein the target underlying block verification unit comprises:

the target bottom layer block information acquisition module acquires a plurality of target bottom layer block information of the target bottom layer block from a plurality of total nodes in the block chain system; and

and the target bottom layer block verification module determines that the target bottom layer block is correct when consistent target bottom layer block information not lower than the legal quantity exists in the target bottom layer block information.

19. The apparatus of claim 11, wherein each block in the verification path includes a first hash value generated based at least on block information of the previous block, the link verification unit comprising:

The hash operation module is used for carrying out hash operation at least partially based on the block information of the previous block acquired locally so as to obtain a second hash value;

and the link verification module is used for verifying whether the link between the block and the previous block is correct or not based on the consistency between the second hash value and the first hash value.

20. A computing device, comprising:

at least one processor; and

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

21. A machine-readable storage medium storing executable instructions that when executed cause the machine to perform the method of any one of claims 1 to 10.